JP2017520954A - Ｍｐｅｇ−２プライベートセクションで視聴覚コンテンツストリームをカプセル化するための方法、ｍｐｅｇ−２トランスポートストリームで多重送信されるようにｍｐｅｇ−２プライベートセクションで視聴覚コンテンツをカプセル化するためのデバイス、デジタルｔｖ用対話型アプリケーション、ユーザデバイス、視聴覚コンテンツおよび／またはデータを伝送するための方法、ならびにデータネットワーク用通信プロトコル - Google Patents

Abstract

本発明は、デジタルＴＶ放送信号をチューニングする能力がないユーザデバイスに視聴覚コンテンツおよび／またはデータを配信するための方法に関する。この方法は、かかる視聴覚コンテンツおよび／またはデータをＭＰＥＧ−２プライベートセクション内でカプセル化すること、その後、デジタルＴＶ信号によって多重化かつ伝送することから成る。方法は、デジタルＴＶ受信機で実行される時、視聴覚コンテンツおよび／またはデータで構成されているＭＰＥＧ−２プライベートセクションをデジタルＴＶ信号から抽出する、および、ローカルエリアネットワーク接続（ＬＡＮ）を使用して、これらの視聴覚コンテンツおよび／またはデータを、デジタルＴＶ受信機が接続されるのと同じローカルエリアネットワーク（ＬＡＮ）に接続される他のユーザデバイスに再送する。また、ＭＰＥＧ−２プライベートセクション内でカプセル化された視聴覚コンテンツおよび／またはデータの伝送を可能にするデバイスについて記載される。【選択図】図２

Description

本発明は、デジタルＴＶ放送の方法、デバイス、および対話型アプリケーション、ならびに、デジタルＴＶのチューニングリソースを有さない放送分野のユーザデバイスに関する。特に、本発明は、既に入手可能なデータ放送技術を使用して、放送デジタルＴＶによって、デジタル信号をチューニングするためのリソースを有さないユーザデバイスへのコンテンツおよび／またはデータの伝送を可能にするデジタルＴＶ放送の方法、デバイスならびに対話型アプリケーションに関する。

特許出願の国際公開第２０１３／１０４０４４号パンフレットは、インターネットアクセス付きまたは無しの複数の携帯型ユーザデバイスと、デジタルＴＶ受信機によって受信されるデジタルＴＶ信号におけるコンテンツとを同期させるための技法を記載している。さらに、この文献は、ＩＳＯ１３８１８−６に記載されるように、ＤＳＭＣＣデータ（またはオブジェクト）カルーセルを使用して、放送デジタルＴＶ信号における対話型アプリケーションの伝送方法を記載している。この対話型アプリケーションは、デジタルＴＶミドルウェアとしても知られているデータ放送実行環境内のデジタルＴＶ受信機によって復号されかつ実行され、かかる実行環境において利用可能なＡＰＩを使用して、デジタルＴＶ受信機が接続される同じローカルエリアネットワーク（ＬＡＮ）に接続される他のデバイスを見出し、かつ、それら他のデバイスへ、ＤＳＭＣＣデータ（またはオブジェクト）カルーセルにおける対話型アプリケーションと共に伝送されているコンテンツを転送する。また、放送局によって送られるコンテンツと、ユーザデバイスに示されるコンテンツとを同期するためのこの方法による能力が記載されている。ユーザデバイスは、とりわけ、コンパニオンデバイスとしても知られている、第二画面アプリケーションを作動させているタブレットまたはスマートフォンなどの第二画面デバイスであってよい。

この技法の不利点は、ユーザデバイスに配信できるコンテンツの全体のサイズは、ＤＳＭＣＣデータカルーセルで伝送できるもののサイズと関連して制限されることである。また、利用可能なコンテンツおよびコンテンツの同期の応答時間は、ＤＳＭＣＣデータカルーセル更新のダウンロードを完了するためにデジタルＴＶ受信機によって必要とされる、普通は１０秒以上の時間によって限定される。これらの制限は、例えば１０秒を上回るビデオファイルといった非常に長い視聴覚コンテンツか、さらには、例えばライブビデオストリームといったライブコンテンツの配信を実行不可能にする。

ＩＳＯ１３８１８−１ではＭＰＥＧ−２システム、とりわけ、ＭＰＥＧ−２プライベートセクションについて定めている。ＭＰＥＧ−２プライベートセクションは、デジタルＴＶ用ＭＰＥＧ−２トランスポートストリームに含まれ得るデータ構造である。ＰＳＩとして知られているこれらの構造のセットは、通常は、オーディオ、ビデオ、字幕、クローズドキャプション、ＤＳＭＣＣカルーセルおよびストリームイベント、対話型アプリケーション信号方式などのエレメンタリストリーム、または、電子番組ガイド（ＥＰＧ）を供給するチャンネルプログラミング情報といった、サービスおよびそれらのコンポーネントをリスト化しかつ特定するＭＰＥＧ−２トランスポートストリームを記述するメタデータを含むために使用される。これらの構造は、識別子として、ｐａｃｋｅｔ＿ｉｄ（ＰＩＤ）およびｔａｂｌｅ＿ｉｄ（ＴＩＤ）を有する。ＰＩＤおよびＴＩＤのいくつかの値は、デジタルＴＶシステムにおける特定機能のために確保されるが、いくつかの他の確保されない識別子は、任意の他のタイプの情報の伝送用に使用できる。図３は、ＭＰＥＧ−２プライベートセクションの構造について詳述している。ＭＰＥＧ−２プライベートセクション構造の最大サイズは４０９５バイトまでに限定される。

デジタルＴＶのいくつかの対話型システムは、対話型アプリケーションがデジタルＴＶ受信機によって受信されるＭＰＥＧ−２トランスポートストリームからＭＰＥＧ−２プライベートセクション構造を抽出することを可能にするためのＡＰＩまたは機構を含むことも、当業者には既知である。例として、ＡＰＩのｏｒｇ．ｄａｖｉｃ．ｍｐｅｇ．ｓｅｃｔｉｏｎｓは、Ｇｌｏｂａｌｌｙ Ｅｘｅｃｕｔａｂｌｅ ＭＨＰ（ＧＥＭ）、またはＡＢＮＴ（ブラジル国標準機関）標準 ＮＢＲ １５６０６−６に定められるＡＰＩのｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇに基づくシステムに存在することが言える。

近年では、タブレットおよびスマートフォンなどの携帯型デバイスの数の増加に伴って、第二画面デバイスまたは第二画面アプリケーションの概念はエンターテインメント分野、特にＴＶ分野で高まっている。一般的に、第二画面による解決策は、ユーザが、ＴＶ受信機に表示されるメインコンテンツ、すなわち、第一画面を補足する視聴覚コンテンツおよび／またはデータにアクセスできるようにする。これらの解決策のいくつかは、インターネットアクセスが補足コンテンツを検索しかつ表示するために第二画面デバイスを利用可能であるかに左右される。このタイプの解決策の不利点は、サーバのインフラストラクチャおよび帯域幅が大量の同時に行われるアクセス、例えば、１２００万以上もの同時に行われるアクセスを確実にサポートできるように、送信側で投資およびメンテナンスに高額を費やす場合があることである。他方で、メインＴＶコンテンツが伝送される同デジタルＴＶ信号放送においてこれらの補足コンテンツを利用可能にすることははるかに経済的効率が良い。後述される図１は、インターネットを通して補足コンテンツをユーザデバイスにて利用可能にするための方法の概要を示す。

本発明は、デジタルＴＶ信号放送を受信する能力がないユーザデバイスにデジタルＴＶ信号放送で伝送される視聴覚コンテンツおよび／またはデータを配信するための、方法、ＭＰＥＧ−２プライベートセクションカプセル化デバイス、対話型アプリケーション、ネットワーク用通信プロトコル、および他の機構に関する。

いくつかの実装形態では、本発明による、デジタルＴＶ信号放送を受信する能力がないユーザデバイスに視聴覚コンテンツおよび／またはデータを配信するための方法は、視聴覚コンテンツをユーザデバイスにおいて再現できるフォーマットに適応させる（またはトランスコーディングする）ためのデバイスを含む。これらの適応処理は、例えば、解像度およびビデオのアスペクト比、オーディオおよびビデオビットレート、ならびに、オーディオおよびビデオ符号化の調整を含むことができる。

本発明によるいくつかの実装形態では、方法は、適応させた視聴覚コンテンツおよび／またはデータをＭＰＥＧ−２プライベートセクションでカプセル化し、かつ、デジタルＴＶ信号放送で伝送されるようにＭＰＥＧ−２トランスポートストリームでの後の多重送信のためにＭＰＥＧ−２トランスポートストリームパケットのストリームでシリアル化するためのＭＰＥＧ−２プライベートセクションカプセル化デバイスを含む。

本発明によるいくつかの実装形態では、デジタルＴＶ信号放送で伝送される同ＭＰＥＧ−２トランスポートストリームにおいて、デジタルＴＶ受信機による実行用の対話型アプリケーションは多重化されかつ伝送される。予想できるように、このＭＰＥＧ−２トランスポートストリームは、メインＴＶコンテンツ、すなわち、オーディオ、ビデオ、クローズドキャプション／字幕なども含む。

本発明によるいくつかの実装形態では、デジタルＴＶ受信機はＴＶセットまたはセットトップボックスとすることができる。デジタルＴＶ受信機は、デジタルＴＶ信号放送にチューニングする時、ＭＰＥＧ−２トランスポートストリームを復号し、かつ、デジタルＴＶ受信機の画面およびスピーカーにおいて、オーディオ、ビデオ、クローズドキャプション／字幕であるメインＴＶコンテンツを再現する。あるいは、セットトップボックスの場合、これらのコンテンツは対応するオーディオおよびビデオ出力から出力される。さらには、デジタルＴＶ受信機は、対話型アプリケーションをその受信機の実行範囲内で、または、ＭＨＰ、Ｇｉｎｇａなどの対話型デジタルＴＶミドルウェア内で復号かつ実行する。対話型アプリケーションは、視聴覚コンテンツおよび／またはデータをＭＰＥＧ−２トランスポートストリームからカプセル化するＭＰＥＧ−２プライベートセクションを抽出するための実行環境で利用可能なＡＰＩを使用する。これらのＡＰＩの例として、Ｇｌｏｂａｌｌｙ Ｅｘｅｃｕｔａｂｌｅ ＭＨＰ（ＧＥＭ）仕様、またはブラジル標準ＡＢＮＴ ＮＢＲ １５６０６−６によって指定されるＡＰＩのｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇに基づくシステムの、ＡＰＩのｏｒｇ．ｄａｖｉｃ．ｍｐｅｇ．ｓｅｃｔｉｏｎｓが挙げられ得る。

本発明によるいくつかの実装形態では、デジタルＴＶ受信機はローカルエリアネットワーク（ＬＡＮ）に接続される。このＬＡＮは、有線（イーサネット）、無線（ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎまたは同様のものなど）、または、有線および無線の両方のタイプの組み合わせとすることができる。

本発明によるいくつかの実装形態では、対話型アプリケーションおよびユーザデバイスによって、これらの間で同じＬＡＮに接続される時の通信のために、ＩＰネットワークに基づいて、ネットワーク用通信プロトコルが実装される必要がある。

本発明によるいくつかの実装形態では、ネットワーク用通信プロトコルは、対話型アプリケーションおよびユーザデバイスが同じＬＡＮにおける互いの存在を認識できるようにする発見機構を提供する。

本発明によるいくつかの実装形態では、この発見機構は、対話型アプリケーションがその存在をユーザデバイスに通知すること、ユーザデバイスがそのデバイス各々の存在を対話型アプリケーションに通知すること、または、これら両方の任意の組み合わせを必要とする場合がある。

本発明によるいくつかの実装形態では、ネットワーク用通信プロトコルは、視聴覚コンテンツ通知機構、および、ユーザデバイスが対話型アプリケーションを通して利用可能であるコンテンツを認識できるようにするデータ通知機構を提供する。これらの機構のいくつかの実装形態では、対話型アプリケーションがかかるコンテンツの利用可能性を通知すること、ユーザデバイスが一定時間内で利用可能であるコンテンツについて対話型アプリケーションに問い合わせすること、または、これらの任意の組み合わせが必要とされる場合がある。

本発明によるいくつかの実装形態では、ネットワーク用通信プロトコルは、ユーザデバイスが、ＭＰＥＧ−２トランスポートストリームから抽出された視聴覚コンテンツおよび／またはデータを配信するように対話型アプリケーションに要求できるようにする視聴覚コンテンツ要求機構およびデータ要求機構を提供する。

本発明によるいくつかの実装形態では、ネットワーク用通信プロトコルは、ユーザデバイスが、ＭＰＥＧ−２トランスポートストリームから抽出された視聴覚コンテンツおよび／またはデータをユーザデバイスに配信できるようにする視聴覚コンテンツ配信機構およびデータ配信機構を提供することができる。

本発明によるいくつかの実装形態では、ユーザデバイスは、対話型アプリケーションによって配信された視聴覚コンテンツおよび／またはデータを受信できるものとし、かつ、復号プロセス、処理および解釈を行って、そのデバイスの各々の画面およびスピーカーで視聴覚コンテンツおよび／もしくはデータを再生するならびに／または呈示することができるものとする。

本発明によるいくつかの実装形態では、ユーザデバイスは、タブレット、スマートフォン、パーソナルコンピュータ、および、ＬＡＮに接続でき、かつ、画面、およびスピーカーまたはヘッドフォンなどのオーディオ出力を有する任意の他のデバイス、または、これらの要素の任意の組み合わせであってよい。

本発明によるいくつかの実装形態では、ユーザデバイスは、本明細書に記載される動き、機能性、およびプロトコルをサポートするための１つまたは複数のアプリケーションを実行することができる。

インターネットを使用してユーザデバイスに補足コンテンツを配信するための既存の方法の概要を示すブロック図である。 デジタルＴＶのチューニング能力がないユーザデバイスに視聴覚コンテンツおよび／またはデータを配信するための方法の概要を示すブロック図である。 デジタルＴＶ信号放送のチューニング能力がないユーザデバイスに視聴覚コンテンツおよび／またはデータを配信するための伝送プロセスを示すブロック図である。 ＭＰＥＧ−２プライベートセクションの論理構造を示す図である。 図５は、各機構を概略の説明図である。 図６は、各機構の詳細な説明図である。

技術的問題点
本発明の目的は、デジタルＴＶ信号放送を受信する能力がないユーザデバイスにデジタルＴＶ信号放送で伝送される視聴覚コンテンツおよび／またはデータを配信するための手段を提供することである。ユーザデバイスの例には、メイン画面またはメインデバイスとしても知られているデジタルＴＶ受信機に再生されるメインＴＶコンテンツを補足するコンテンツにアクセスするために第二画面デバイスとして使用されるタブレットまたはスマートフォンを挙げることができる。このような補足コンテンツは、例えば、ビデオクリップおよび／もしくはオーディオ、ライブビデオ放送などの視聴覚コンテンツ、または、例えば、テキスト、写真、統計データなどのデータであってよい。通常、補足コンテンツは、メインＴＶコンテンツに関連があるものとすることができるが、これは必要条件ではない。

かかるユーザデバイスにおいてデジタルＴＶ信号放送を受信する能力がないことによって、一般的に、補足コンテンツはインターネット接続によって受信される。

図１は、コンテンツ制作者（４００）が、デジタルＴＶ受信機（４１２）の画面およびスピーカーにおいて再現されるメインＴＶコンテンツであるデジタルＴＶ信号放送（４１０）を生成しかつ伝送するデジタルＴＶ放送局（４０４）にメインＴＶコンテンツ（４０２）を送信する状況を示す。並行して、コンテンツ制作者（４００）は、通常は、視聴覚コンテンツおよび／またはデータ（４１４）である補足コンテンツを、インターネット（４２０）に接続されるデジタルＴＶ放送局からサーバ（４１６）へ配信する。ユーザデバイス（４２２）は、補足コンテンツ（４１８）をデジタルＴＶ放送局のサーバ（４１６）へと要求し、かつ、このコンテンツをこれらデバイスの各々の画面に呈示する。要求されるデジタルＴＶ放送局のサーバの帯域幅（４２４）およびサーバ（４１６）は、補足コンテンツ（４１８）を要求するユーザデバイス（４２２）の数に従って増加する。よって、このタイプのコンテンツを配信するためにインターネットを使用すると、以下の欠点は不可避である。

ａ．局のそばにおけるサーバブロードバンドおよびサーバインフラストラクチャへの投資は、補足コンテンツにアクセスするユーザ数に比例して増加する。

ｂ．配信の信頼性およびユーザ体験は、ユーザのインターネットの帯域幅および品質によって影響を受ける可能性がある。

加えて、対話型ＴＶとしても知られている上述されるシステムのデータ放送において使用されるカルーセル技法には、ＤＳＭＣＣデータカルーセルまたはＤＳＭＣＣオブジェクトカルーセルプロトコル（ＩＳＯ１３８１８−６）を使用する大きなファイルまたはライブビデオコンテンツといったビデオコンテンツを配信できないという、カルーセルで送られる最大サイズのコンテンツに関連する限界がある。

本発明は、ユーザのインターネットアクセスの利用可能性との独立した関係を保障しつつ、信頼できる配信および保証されたユーザ体験と共に、追加の費用がかからずに、上述されるようなインターネットを使用したコンテンツ配信の欠点を回避して、デジタルＴＶ信号放送で使用されない帯域幅を使用した補足コンテンツの配信を可能にする。

技術的解決策−概要
本発明は、ライブオーディオまたはビデオストリームを含む、時間またはサイズが限定されることのないオーディオまたはビデオストリームなどの補足コンテンツの配信を可能にする。

図２は本発明の概要を示す。コンテンツ制作（１００）のプロセスは、オーディオ、ビデオ、字幕および／またはクローズドキャプション、ならびに、通常は従来のデジタルＴＶ信号放送サービスによって生成される任意の他のコンテンツを含むメインＴＶコンテンツ（１０２）をもたらす。加えて、コンテンツ制作（１００）は、ユーザデバイスにおける再生用の視聴覚コンテンツ（１０４）とも呼ばれる補足コンテンツをもたらす。デジタルＴＶ信号放送（１１０）からの視聴覚コンテンツおよび／またはデータ（１０４）を抽出すること、および、このようなコンテンツおよび／またはデータをユーザデバイスに転送することができる対話型アプリケーション（１０６）も提供される。デジタルＴＶ放送局（１０８）は、メインＴＶコンテンツ（１０２）、視聴覚コンテンツおよび／またはデータ（１０４）、ならびに対話型アプリケーション（１０６）を含むデジタルＴＶ信号放送を生成しかつ伝送する。

デジタルＴＶ受信機（１１２）は、ＭＰＥＧ−２トランスポートストリームを復号し、かつ、メインＴＶコンテンツ、すなわちオーディオ、ビデオ、クローズドキャプション／字幕などを再現するためにデジタルＴＶ信号放送をチューニングするか、あるいは、セットトップボックスの場合、コンテンツは各オーディオおよびビデオ出力から出力される。

デジタルＴＶ受信機はまた、対話型アプリケーション（１１８）をその受信機の実行環境（１１６）内で復号かつ実行する。実行環境の例には、ＭＨＰ、Ｇｉｎｇａなどの対話型デジタルＴＶミドルウェアを挙げることができる。対話型アプリケーション（１１８）は、カプセル化された視聴覚コンテンツおよび／またはデータ（１２０）で構成されているＭＰＥＧ−２プライベートセクションをＭＰＥＧ−２トランスポートストリームから抽出するための実行環境（１１６）で利用可能なＡＰＩを使用する。これらのＡＰＩの例として、Ｇｌｏｂａｌｌｙ Ｅｘｅｃｕｔａｂｌｅ ＭＨＰ（ＧＥＭ）仕様、およびブラジル標準ＡＢＮＴ ＮＢＲ １５６０６−６によって指定されるｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇのＡＰＩに基づくシステムで利用可能なＡＰＩのｏｒｇ．ｄａｖｉｃ．ｍｐｅｇ．ｓｅｃｔｉｏｎｓが挙げられ得る。

しかしながら、デジタルＴＶ受信機（１１２）を、有線（例えばイーサネット）、無線（例えばＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎネットワークまたは同様のものなど）、または、有線および無線の両方のタイプの組み合わせとすることができるＬＡＮ（１２２）に接続させる必要があると言わざるをえない。

また、ユーザデバイス（１２６）が視聴覚コンテンツおよび／またはデータを受信しかつ再現できるようにするために、これらデバイスは、デジタルＴＶ受信機（１１２）と同じＬＡＮ（１２２）で接続される必要がある。例として、ユーザデバイス（１２６）は、タブレット、スマートフォン、パーソナルコンピュータ、または、ＬＡＮ（１２２）に接続でき、かつ、画面、および／または、スピーカーまたはヘッドフォンなどのオーディオ出力を有する任意の他のデバイスとすることができる。いくつかの実装形態では、ユーザデバイス（１２６）は、本発明によってこれらデバイスによるものである動き、機能性およびプロトコルを実装するために１つまたは複数のアプリケーションをホストとして処理しかつ実行できる。

技術的解決策−放送局側
本発明のプロセスにおいて入力されるのは、現状技術のコンテンツ制作（２００）ワークフローによって生成されるコンテンツである。コンテンツ制作（２００）は、オーディオ、ビデオ、字幕、クローズドキャプション、および、一般的に従来のデジタルＴＶ放送サービスのために生成されることが多い任意の他のコンテンツを含むメインＴＶコンテンツ（２０２）をもたらす。さらに、コンテンツ制作（２００）は、ユーザデバイスにおける再生用の視聴覚コンテンツ（２０４）とも呼ばれる補足コンテンツをもたらす。

コンテンツ制作（２００）によってもたらされるような、ユーザデバイスにおける再生用の視聴覚コンテンツ（２０４）の場合、ユーザデバイスにおいて再現されるように、または、小さなチャンクに分けて伝送されるように適応させる必要があり、トランスコーダデバイス（２０６）は、視聴覚コンテンツを再符号化するために使用される。かかる適応処理は、例えば、ビデオ解像度およびそのアスペクト比、オーディオおよびビデオビットレート、ならびに、オーディオおよびビデオ符号化の調整、および、視聴覚コンテンツをストリームとして送信可能なフォーマットに変換する必要がある可能性がある任意の他の調整を含むことができる。ストリームとして送信できるフォーマットの例として、ＭＰＥＧ−２トランスポートストリームプロトコル、ＲＴＰ／ＲＴＰＳ、ＨＬＳなどで使用されるものの任意のものが挙げられ得る。トランスコーダデバイス（２０６）は、ユーザデバイスにおいて再生されるように適応された視聴覚コンテンツ（２０８）を出力する。このステップは、コンテンツ制作（１００）によってもたらされる視聴覚コンテンツ（２０８）が、既に、ユーザデバイスにおいて再生されるのに、かつ、ストリーム形式で伝送されるのに適したフォーマットである場合は無視できる。

ユーザデバイスにおいて再生されるように既に適応させている視聴覚コンテンツ（２０８）は、その後、ＭＰＥＧ−２プライベートセクションカプセル化デバイス（２１２）によってＭＰＥＧ−２プライベートセクションでカプセル化される。ＭＰＥＧ−２プライベートセクションカプセル化デバイス（２１２）は、以下のステップから成る方法を使用してＭＰＥＧ−２プライベートセクションのシーケンスを生成する。

ａ．既定値を、ｔａｂｌｅ＿ｉｄのフィールドに割り当てる。

ｂ．連続的にインクリメントさせる値を、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドに割り当てる。

ｃ．ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドの値がｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドに割り当てられた（０から２５５までの）既定値に達する度に、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのシーケンスは０でリスタートされる。

ｄ．ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのシーケンスがリスタートされる度に、連続的にインクリメントさせる値を、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドに割り当てる。

ｅ．ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドの値が（１から３１までの）このフィールドの最大既定値に達する度に、シーケンスは（０からｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒの最大既定値−１までの）既定の初期値でリスタートされる。

ｆ．ＭＰＥＧ−２プライベートセクションに対して定められた最大既定サイズ（大抵の場合、最大既定サイズは４０９５バイト）を超えないように、規則正しく、できるだけ多くの視聴覚コンテンツ（２０８）のチャンクまたはパッケージをこのフィールド内に収めるように、ＭＰＥＧ−２プライベートセクションのｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅのフィールドに追加する。

ｇ．ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈおよびＣＲＣのフィールドに対して値を計算しかつ設定する。

ｈ．ＭＰＥＧ−２トランスポートストリームパケット（２１４）のシーケンスにおけるＭＰＥＧ−２プライベートセクションを分割し、かつ、それらの全てに、ｐａｃｋｅｔ＿ｉｄ（ＰＩＤ）のフィールドに対する同じ既定値を設定する。

ｉ．生成されたＭＰＥＧ−２トランスポートストリームパケット（２１４）をＭＰＥＧ−２トランスポートストリームマルチプレクサ（２２２）に配信する。

（ａ）から（ｉ）までのステップが継続的に繰り返される間、視聴覚コンテンツは利用可能である。

上記の本願発明による方法のステップ（ｆ）の変形例によって、視聴覚コンテンツのチャンクまたはパッケージを、生成されるＭＰＥＧ−２プライベートセクションの現在のものと次のものとの間で分割することができ、ＭＰＥＧ−２プライベートセクションが可能とされる最大サイズを有する限り適用可能となる（ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈのフィールド−通常は４０９５バイト）。このアプローチは、より少ないＭＰＥＧ−２プライベートセクションでより多くの視聴覚コンテンツのチャンクおよびパッケージを配信させることができるため、より効果的である。

本発明によるいくつかの実装形態では、トランスコーダデバイスは、後にＭＰＥＧ−２プライベートセクションカプセル化デバイスによってＭＰＥＧ−２プライベートセクションでカプセル化される、ＲＴＰ制御パッケージ、ＲＴＰおよびＲＴＰセッション記述子パッケージで構成されているストリームのフォーマットでユーザデバイスに呈示するように適応させた視聴覚コンテンツを提供することができる。

本発明による他の実装形態では、トランスコーダデバイスは、後にＭＰＥＧ−２プライベートセクションカプセル化デバイスによってＭＰＥＧ−２プライベートセクションでカプセル化される、ＭＰＥＧ−２トランスポートストリームパッケージで構成されているストリームのフォーマットでユーザデバイスに呈示するように適応される視聴覚コンテンツを提供できる。

ユーザデバイスに呈示するように適応された視聴覚コンテンツ（２０８）に加えて、ＭＰＥＧ−２プライベートセクションカプセル化デバイス（２１２）は、ユーザデバイスによって解釈できる包括的なデータ（２１０）のチャンクまたは構造で構成されているＭＰＥＧ−２プライベートセクションを生成することができる。カプセル化プロセスは、ユーザデバイスに呈示するために適応された視聴覚コンテンツ（２０８）について説明されるものと全く同じである。

さらに、デジタルＴＶ受信機による実行用の対話型アプリケーション（２１６）は、対話型アプリケーションのエンコーダデバイス（２１８）によって符号化される。

メインＴＶコンテンツＴＶ（２０２）、符号化された対話型アプリケーション（２２０）、およびＭＰＥＧ−２プライベートセクションでカプセル化された視聴覚コンテンツおよび／またはデータ（２１４）は、デジタルＴＶ信号放送で伝送される（２２６）のに適したＭＰＥＧ−２トランスポートストリーム信号（２２４）を生成することになるＭＰＥＧ−２トランスポートストリームマルチプレクサ（２２２）へ転送される。最後に、デジタルＴＶ伝送デバイス（２２６）はデジタルＴＶ信号放送を伝送する。これらの伝送信号の例として、地上波ＴＶ無線周波数信号、衛星ＴＶ信号、またはケーブルＴＶ信号が挙げられ得る。

技術的解決策−受信側
デジタルＴＶ受信機（１１２）は、デジタルＴＶ信号放送にチューニングし、ＭＰＥＧ−２トランスポートストリームを復号し、メインＴＶコンテンツ、すなわち、オーディオ、ビデオ、クローズドキャプション／字幕などをこの受信機の画面およびスピーカ（１１４）で再現する。あるいは、セットトップボックスの場合、画像および音は、それぞれのオーディオおよびビデオ出力から出力される。

デジタルＴＶ受信機はまたは、その実行環境（１１６）内で対話型アプリケーション（１１８）を復号しかつ実行する。実行環境は、例えば、ＭＨＰ、Ｇｉｎｇａなどの対話型デジタルＴＶミドルウェアとすることができる。対話型アプリケーション（１１８）は、実行環境（１１６）で利用可能なＡＰＩを使用して、ＭＰＥＧ−２トランスポートストリームから、視聴覚コンテンツおよび／またはカプセル化データ（１２０）で構成されているＭＰＥＧ−２プライベートセクションを抽出する。これらＡＰＩの例として、Ｇｌｏｂａｌｌｙ Ｅｘｅｃｕｔａｂｌｅ ＭＨＰ（ＧＥＭ）仕様、またはＡＢＮＴ ＮＢＲ １５６０６−６において指定されるＡＰＩのｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇに基づくシステムにおいて利用可能なＡＰＩのｏｒｇ．ｄａｖｉｃ．ｍｐｅｇ．ｓｅｃｔｉｏｎｓが挙げられ得る。

デジタルＴＶ受信機（１１２）はＬＡＮ（１２２）に接続される必要がある。このＬＡＮ（１２２）は、有線（例えばイーサネット）、無線（ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎネットワークまたは同様のものなど）、または、有線および無線の両方のタイプの組み合わせとすることができる。

また、ユーザデバイス（１２６）は、視聴覚コンテンツおよび／またはデータを受信しかつ再現するために、デジタルＴＶ受信機（１１２）と同じＬＡＮ（１２２）で接続されなければならない。例として、ユーザデバイス（１２６）は、タブレット、スマートフォン、パーソナルコンピュータ、または、ＬＡＮ（１２２）に接続でき、かつ、画面、および／または、スピーカーまたはヘッドフォンなどのオーディオ出力を有する任意の他のデバイスとすることができる。いくつかの実装形態では、ユーザデバイス（１２６）は、本発明によってこれらデバイスによるものである動き、機能性および通信プロトコルを実装するために１つまたは複数のアプリケーションをホストとして処理しかつ実行できる。

デジタルＴＶ受信機（１１２）で実行されている対話型アプリケーション（１１８）、およびユーザデバイス（１２６）は、共通のデータネットワーク用通信プロトコルを使用して互いに通信する。かかるデータネットワーク用通信プロトコルは、全てのユーザデバイスおよび対話型アプリケーションによって実装される。データネットワーク用通信プロトコルは、対話型アプリケーションおよびユーザデバイスの発見、視聴覚コンテンツ通知、データ通知、視聴覚コンテンツ要求、データ要求、視聴覚コンテンツ配信、およびデータ配信のための機構を含む。

データネットワーク用通信プロトコルを使用して、ユーザデバイス（１２６）は、
ａ．対話型アプリケーションの存在を認識し、
ｂ．視聴覚コンテンツの利用可能性を認識し、
ｃ．データの利用可能性を認識し、
ｄ．視聴覚コンテンツの配信を対話型アプリケーション（１１８）に要求し、
ｅ．データの配信を対話型アプリケーション（１１８）に要求し、
ｆ．視聴覚コンテンツ（１２４）を対話型アプリケーション（１１８）から受信し、
ｇ．データ（１２４）を対話型アプリケーション（１１８）から受信する。

ユーザデバイス（１２６）は、それら各々の画面および／またはスピーカーにおいて、受信された視聴覚コンテンツおよび／またはデータを復号し、処理し、再現する。

技術的解決策−対話型アプリケーションとユーザデバイスとの間のネットワーク用通信プロトコル
デジタルＴＶ受信機（１１２）およびユーザデバイス（１２６）において実行される対話型アプリケーション（１１８）は、それらの間の通信を可能にするネットワーク用通信プロトコルを実装しなければならない。対話型アプリケーション（１１８）が実行される全てのユーザデバイス（１２６）およびデジタルＴＶ受信機（１１２）は同じＬＡＮ（１２２）に接続される。データネットワーク用通信プロトコルは、とりわけ、図６に示されるような以下の機構を企図する場合がある。

ａ．発見（５０４）：対話型アプリケーション（５００）およびユーザデバイス（５０２）が同じＬＡＮに接続される時に互いの存在を認識できるようにするための機構。

ｂ．視聴覚コンテンツ通知（５０６）：ユーザデバイス（５０２）が、対話型アプリケーション（５００）を通して提供されかつユーザデバイスによって消費されることになる視聴覚コンテンツの利用可能性を認識できるようにする機構。

ｃ．データ通知（５０８）：ユーザデバイス（５０２）が、対話型アプリケーション（５００）を通して提供されかつユーザデバイスによって消費されることになるデータの利用可能性を認識できるようにする機構。

ｄ．視聴覚コンテンツの要求（５１０）：ユーザデバイス（５０２）が視聴覚コンテンツを配信するように対話型アプリケーション（５００）に要求できるようにする機構。

ｅ．データの要求（５１２）：ユーザデバイス（５０２）がデータを配信するように対話型アプリケーション（５００）に要求できるようにする機構。

ｆ．視聴覚コンテンツの配信（５１４）：対話型アプリケーション（５００）からユーザデバイス（５０２）へ視聴覚コンテンツを配信するための機構。

ｇ．データの配信（５１６）：対話型アプリケーション（５００）からユーザデバイス（５０２）へデータを配信するための機構。

データネットワーク用通信プロトコルは、ＵＤＰデータグラム（二地点間ＵＤＰデータグラム、一地点対多地点ＵＤＰデータグラム、および放送ＵＤＰデータグラム）およびＴＣＰ接続の任意の組み合わせを使用したメッセージ交換として実装可能である。

本発明による種々の実装形態では、通信プロトコルは、対話型アプリケーション（５００）によって、ユーザデバイス（５０２）によって、またはそれらのうちの任意の１つによって開始されるように設計されてよい。

視聴覚コンテンツおよび／またはデータを配信するための機構の実装形態は、ＭＰＥＧ−２トランスポートストリームから抽出される未処理のＭＰＥＧ−２プライベートセクションの配信を考慮することができる。あるいは、視聴覚コンテンツおよび／またはデータを配信するための機構の実装形態は、ＭＰＥＧ−２トランスポートストリームから抽出されるＭＰＥＧ−２プライベートセクションを復号／処理し、かつ、ＭＰＥＧ−２プライベートセクションのヘッダーおよびＣＲＣを廃棄して、カプセル化された視聴覚コンテンツおよび／またはデータのみをユーザデバイス（５０２）に配信するために、デジタルＴＶ受信機で実行されている対話型アプリケーション（５００）を考慮することができる。

ユーザデバイスの場合、記載される、データネットワーク用通信プロトコルの実装形態は、ユーザデバイスに内蔵可能であるか、ユーザデバイスにおいてインストールされかつ実行される１つまたは複数のユーザアプリケーションによって実装可能である。

技術的解決策−全般的な利点
ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドおよびｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドの値を定めるために使用される方法は、視聴覚コンテンツ（２０８）および／またはデータ（２１０）の新しいパッケージまたはパケットの継続的な配信を可能にする。ＭＰＥＧ−２プライベートセクションでカプセル化されたかかるチャンクおよびパッケージ（２１４）の有効期限は、一般的に非常に短く、ユーザデバイス（１２６）によって即座に処理されかつ廃棄されることが考えられる。ユーザデバイス（１２６）が利用可能ではないか視聴覚コンテンツの配信を要求していない場合、対話型アプリケーション（１１８）はかかるパッケージまたはパケットを即座に廃棄する。このために、本発明による方法はまた、ライブ視聴覚コンテンツ放送に適用可能である。

実施例
以降、上記で詳述されるような、本発明の方法、デバイス、プロトコル、および対話型アプリケーションの実装例が論証される。しかしながら、このような実施例は、他の形式の実装形態が当業者には想起可能であるため、本発明の範囲および限界を限定するものと考えられるべきではない。

実装例−放送側
実施例１−ＲＴＰストリームを使用した視聴覚コンテンツの符号化
放送システムは、ブラジルのデジタルＴＶシステムＩＳＤＢ−Ｔに従って構築され、かつ、局の伝送ワークフローに容易に統合される。

メインＴＶコンテンツは、Ｈ．２６４およびＭＰＥＧ−４ ＡＡＣそれぞれの符号化方式を使用したビデオおよびオーディオストリームとすることができ、クローズドキャプションも含まれ得る。電子番組ガイド（ＥＰＧ）用のデータ、および他のサービス情報（ＳＩ）メタデータは、ＡＢＮＴ ＮＢＲ １５６０３の規格に従って生成できかつ含まれ得る。

対話型アプリケーションは、Ｇｉｎｇａミドルウェア規格（ＡＢＮＴ ＮＢＲ １５６０６）に従って開発でき、ＡＢＮＴ ＮＢＲ １５６０６−６で指定されるＡＰＩのｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇを使用して、ＭＰＥＧ−２プライベートセクションをデジタルＴＶ信号放送に含まれるＭＰＥＧ−２トランスポートストリームから抽出することができる。ネットワーク用通信プロトコルは、Ｇｉｎｇａミドルウェア規格（ＡＢＮＴ ＮＢＲ １５６０６−４）にも含まれる、Ｐｅｒｓｏｎａｌ Ｂａｓｉｓ Ｐｒｏｆｉｌｅ １．２．１で指定されるｊａｖａ．ｎｅｔパッケージによって提供されるＡＰＩで実装できる。

対話型アプリケーションエンコーダデバイスは、ＤＳＭＣＣオブジェクトカルーセルプロトコルでＧｉｎｇａアプリケーションを符号化するために使用されるＧｉｎｇａ対話式プレイアウトデバイスで実装されてよい。

ＭＰＥＧ−２トランスポートストリームの多重化および放送は、従来のＩＳＤＢ−ＴデジタルＴＶ放送で既に使用されているのと同じ機器を使用して行われ得る。

コンテンツ制作プロセスによってもたらされるユーザデバイスのための視聴覚コンテンツは、ＦｕｌｌＨＤビデオおよびオーディオストリームとすることができ、事前録画またはライブ放送でき、ビデオおよびオーディオそれぞれに対して、Ｈ．２６４およびＭＰＥＧ−４ ＡＡＣの符号化方式を使用して符号化可能である。ビットレートは、ＦｕｌｌＨＤフォーマットに対する高品質放送を可能にする任意の値を有することができる（例えば、１３Ｍｂｐｓ）。

トランスコーダデバイスは、ＦｕｌｌＨＤビデオを、ユーザデバイスによって再現されるのに適した解像度、符号化、ビットレート、およびフレームレートに再符号化する（例えば、７２０×３６２、Ｈ．２６４、１５ｆｐｓ）。同様に、オーディオは、ユーザデバイスにおいて再生されるのに適切なフォーマット、ビットレート、サンプルレート、および符号化に再符号化される（例えば、ＭＰＥＧ−４ ＡＡＣ ＨＥ）。全ビットレートは５００Ｋｂｐｓに低減される。適応させたストリームは、ＲＴＰパッケージおよびＲＴＰ制御パッケージで構成されている、ＲＴＰストリームとしてＲＴＰ／ＲＴＳＰプロトコルを使用してトランスコーダデバイスによって生成される。トランスコーダデバイスはまた、ＲＴＰセッション記述子のタイプのデータ構造を生成する。

ＭＰＥＧ−２プライベートセクションカプセル化デバイスは、トランスコーダデバイスによって生成された、ＲＴＳＰストリームパッケージ、ＲＴＰ制御パッケージ、およびＲＴＰセッション記述子を受信し、かつ、ｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅのフィールドにおいてＲＴＰ／ＲＴＳＰパッケージを加えてＭＰＥＧ−２プライベートセクションを生成する。生成されたＭＰＥＧ−２プライベートセクションは、ＭＰＥＧ−２トランスポートストリームパケットのシーケンスとしてＭＰＥＧ−２トランスポートストリームマルチプレクサに転送され、最終的に、デジタルＴＶ信号放送に挿入される。

実施例２−ＭＰＥＧ−２トランスポートストリームのストリームを使用した視聴覚コンテンツの符号化
実施例１から導き出される他の実装例では、トランスコーダデバイスは、ＦｕｌｌＨＤビデオを、ユーザデバイスによって再生されるのに適した解像度、コード化、ビットレート、およびフレームレートに再符号化する（例えば、７２０×３６２、Ｈ．２６４、１５ｆｐｓ）。同様に、オーディオは、ユーザデバイスにおいて再生されるのに適切なフォーマット、ビットレート、サンプルレート、および符号化に再符号化される（例えば、ＭＰＥＧ−４ ＡＡＣ ＨＥ）。全ビットレートは５００Ｋｂｐｓに低減される。適応させたストリームは、ストリームを復号するために必要とされるＰＳＩを含む、ＭＰＥＧ−２トランスポートストリームのシーケンスで構成されているストリームとしてＭＰＥＧ−２トランスポートストリームプロトコルを使用してトランスコーダデバイスによって生成される。

ＭＰＥＧ−２プライベートセクションカプセル化デバイスは、トランスコーダデバイスによって生成されるＭＰＥＧ−２トランスポートストリームパケットのシーケンスのストリームを受信し、かつ、ｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅのフィールドにおいてＭＰＥＧ−２トランスポートストリームパケットを加えてＭＰＥＧ−２プライベートセクションを生成する。生成されたＭＰＥＧ−２プライベートセクションは、ＭＰＥＧ−２トランスポートストリームパケットのシーケンスとしてＭＰＥＧ−２トランスポートストリームマルチプレクサに転送され、最終的に、デジタルＴＶ信号放送に挿入される。

実装例−受信側
デジタルＴＶ受信機の実装例として、ＡＢＮＴ ＮＢＲ １５６０６に従ったＧｉｎｇａ対話型ミドルウェアサポートも含むＩＤＳＢ−ＴデジタルＴＶサービスをチューニングしかつ復号することができ、イーサネットインターフェイスまたはＷｉ−ＦｉによってＬＡＮに接続できるＴＶ装置またはセットトップボックスのどちらかが考えられ得る。

前の節で説明したように、インストールされ、かつ、ＩＳＤＢ−ＴデジタルＴＶ信号放送で放送されているＧｉｎｇａ対話型アプリケーションによって実施される同じデータネットワーク用通信プロトコルを実装するアプリケーションを実行している、任意のユーザのスマートフォンまたはタブレットなどの、使用できる様々なユーザデバイスがあることは強調されるべきである。このアプリケーションは、ＭＰＥＧ−２プライベートセクションでカプセル化されて配信されている視聴覚コンテンツをユーザが選択しかつ再現することができるようにするユーザインターフェイスを有することができる。通常、この機能性は、第二画面アプリケーションといったより一層複雑なアプリケーションの一部とすることが可能である。

実装例−対話型アプリケーションとユーザデバイスとの間のデータネットワーク用通信プロトコル
対話型アプリケーションは、Ｇｉｎｇａミドルウェア仕様、ＡＢＮＴ ＮＢＲ １５６０６規格に従って開発できる。データネットワーク用通信プロトコルは、ブラジルＡＢＮＴ ＮＢＲ １５６０６−４規格のように、Ｇｉｎｇａミドルウェア仕様の一部でもあるＰｅｒｓｏｎａｌ Ｂａｓｉｓ Ｐｒｏｆｉｌｅ１．２．１において指定されるｊａｖａ．ｎｅｔパッケージで利用可能なＡＰＩで実装できる。

ユーザデバイスで実行されるアプリケーションの場合、データネットワーク用通信プロトコルは、かかるプラットフォーム（例えば、ｉＯＳおよびアンドロイド）で利用可能なネットワークアクセスＡＰＩを使用して実装できる。

この例では、発見機構は、図６のａに示されるように、１０秒ごとに放送ＵＤＰデータグラムとしてメッセ−ジを送信する対話型アプリケーション（６００）によって実装されてよい。

この例では、視聴覚コンテンツおよびデータ通知機構は、図６のａに示されるように、対話型アプリケーション（６００）が、１０秒ごとに放送ＵＤＰデータグラムとして視聴覚コンテンツおよび利用可能なデータについての情報ならびに詳細で構成されているメッセージを送信するように実装できる。

視聴覚コンテンツ要求機構およびデータ要求機構は、図６のｂに示されるように、ユーザデバイス（６０２）において実行されるアプリケーションが、二地点間ＵＤＰデータグラムとして、対話型アプリケーション（６００）へ、通知された視聴覚コンテンツおよび／またはデータの配信を要求するメッセージ（６１２）を送信するように実装可能である。それぞれのユーザデバイスは、５秒ごとにこのメッセージ（６１２）を送信しなければならない。対話型アプリケーション（６００）がある一定時間（例えば１０秒）に所与のユーザデバイス（６０２）におけるこのメッセージ（６１２）の受信を停止する場合、対話型アプリケーション（６００）は、ユーザデバイス（６０２）が視聴覚コンテンツおよび／またはデータの受信にもはや関心がなく、この所与のユーザデバイス（６０２）への配信を停止しようとしていることを推定する。

視聴覚コンテンツ配信機構およびデータ配信機構は、図６のｃに示されるように、対話型アプリケーション（６００）がかかる配信を前に要求していたそれぞれのユーザデバイス（６０２）に対して視聴覚コンテンツおよび／またはデータで構成されているメッセージ（６１６）を送信するように実装できる。これらのメッセージ（６１６）は二地点間ＵＤＰデータグラムとしてＬＡＮを通して送信できる。メッセージ（６１６）は、ＡＰＩのｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇによってＭＰＥＧ−２トランスポートストリームから抽出されたそれぞれのＭＰＥＧ−２プライベートセクション（６１４）に対して送られたものとすることができ、このようなＭＰＥＧ−２プライベートセクションのコンテンツ全てを伝えることができる。

この解決策の他の実装例では、視聴覚コンテンツ要求機構およびデータ要求機構は、ユーザデバイスにおいて実行されるアプリケーションが対話型アプリケーションとのＴＣＰ接続を確立するように実装可能である。このＴＣＰ接続が確立されると、視聴覚コンテンツおよび／またはデータ配信はＴＣＰ接続がオープンされる時間で生じることになる。この場合、対話型アプリケーションは、このＴＣＰ接続によって視聴覚コンテンツおよび／またはデータで構成されているメッセージを送信することになる。メッセージは、ＡＰＩのｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇによってＭＰＥＧ−２トランスポートストリームから抽出されたそれぞれのＭＰＥＧ−２プライベートセクションに対して送られたものとすることができ、このようなＭＰＥＧ−２プライベートセクションのコンテンツ全てを伝えることができる。ＴＣＰ接続は、視聴覚コンテンツおよび／またはデータの配信に割り込まざるを得ないことを対話型アプリケーションに示して、ユーザデバイスによってクローズされてよい。

本発明は、デジタルＴＶ放送の分野の方法、デバイス、および対話型アプリケーション、ならびに、デジタルＴＶのチューニングリソースを有さないユーザデバイスに関する。特に、本発明は、既に入手可能なデータ放送技術を使用して、放送デジタルＴＶ信号によって、デジタル信号をチューニングするためのリソースを有さないユーザデバイスへのコンテンツおよび／またはデータの伝送を可能にするデジタルＴＶ放送の分野の方法、デバイスならびに対話型アプリケーションに関する。

特許出願の国際公開第２０１３／１０４０４４号パンフレットは、インターネットアクセス付きまたは無しの複数の携帯型ユーザデバイスと、デジタルＴＶ受信機によって受信されるデジタルＴＶ信号におけるコンテンツとを同期させるための技法を記載している。さらに、この文献は、ＩＳＯ１３８１８−６に記載されるように、ＤＳＭＣＣデータ（またはオブジェクト）カルーセルを使用して、放送デジタルＴＶ信号における対話型アプリケーションの伝送方法を記載している。この対話型アプリケーションは、デジタルＴＶミドルウェアとしても知られているデータ放送実行環境内のデジタルＴＶ受信機によって復号されかつ実行され、かかる実行環境において利用可能なＡＰＩを使用して、デジタルＴＶ受信機が接続される同じローカルエリアネットワーク（ＬＡＮ）に接続される他のデバイスを見出し、かつ、それら他のデバイスへ、ＤＳＭＣＣデータ（またはオブジェクト）カルーセルにおける対話型アプリケーションと共に伝送されているコンテンツを転送する。また、放送局によって送られるコンテンツと、ユーザデバイスに示されるコンテンツとを同期するためのこの方法による能力が記載されている。ユーザデバイスは、多くの場合、コンパニオンデバイスとしても知られている、第二画面アプリケーションを作動させているタブレットまたはスマートフォンなどの第二画面デバイスであってよい。

この技法の不利点は、ユーザデバイスに配信できるコンテンツの全体のサイズが、ＤＳＭＣＣデータカルーセルで伝送できるもののサイズに制限されることである。また、利用可能なコンテンツおよびコンテンツの同期の応答時間は、ＤＳＭＣＣデータカルーセル更新のダウンロードを完了するためにデジタルＴＶ受信機によって必要とされる、普通は１０秒以上の時間によって限定される。これらの制限は、例えば１０秒を上回るビデオファイルといった非常に長い視聴覚コンテンツか、さらには、例えばライブビデオストリームといったライブコンテンツの配信を実行不可能にする。

ＩＳＯ１３８１８−１規格ではＭＰＥＧ−２システム、とりわけ、ＭＰＥＧ−２プライベートセクションについて定めている。ＭＰＥＧ−２プライベートセクションは、デジタルＴＶ用ＭＰＥＧ−２トランスポートストリームに含まれ得るデータ構造である。ＰＳＩとして知られているこれらの構造のセットは、通常は、オーディオ、ビデオ、字幕、クローズドキャプション、ＤＳＭＣＣカルーセルおよびストリームイベント、対話型アプリケーション信号方式などのエレメンタリストリーム、または、電子番組ガイド（ＥＰＧ）を供給するチャンネルプログラミング情報といった、サービスおよびそれらのコンポーネントをリスト化しかつ特定するＭＰＥＧ−２トランスポートストリームを記述するメタデータを含むために使用される。これらの構造は、識別子として、ｐａｃｋｅｔ＿ｉｄ（ＰＩＤ）およびｔａｂｌｅ＿ｉｄ（ＴＩＤ）を有する。ＰＩＤおよびＴＩＤのいくつかの値は、デジタルＴＶシステムにおける特定機能のために確保されるが、いくつかの他の確保されない識別子は、任意の他のタイプの情報の伝送用に使用できる。図３は、ＭＰＥＧ−２プライベートセクションの構造について詳述している。ＭＰＥＧ−２プライベートセクション構造の最大サイズは４０９５バイトまでに限定される。

デジタルＴＶのいくつかの対話型システムは、対話型アプリケーションがデジタルＴＶ受信機によって受信されるＭＰＥＧ−２トランスポートストリームからＭＰＥＧ−２プライベートセクション構造を抽出することを可能にするためのＡＰＩまたは機構を含むことも、当業者には既知である。例として、ＡＰＩのｏｒｇ．ｄａｖｉｃ．ｍｐｅｇ．ｓｅｃｔｉｏｎｓは、Ｇｌｏｂａｌｌｙ Ｅｘｅｃｕｔａｂｌｅ ＭＨＰ（ＧＥＭ）、またはブラジル標準ＡＢＮＴ ＮＢＲ １５６０６−６に定められるＡＰＩのｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇに基づくシステムに存在することが言える。

近年では、タブレットおよびスマートフォンなどの携帯型デバイスの数の増加に伴って、第二画面デバイスまたは第二画面アプリケーションの概念はエンターテインメント分野、特にＴＶ分野で高まっている。一般的に、第二画面による解決策は、ユーザが、ＴＶ受信機に表示されるメインコンテンツ、すなわち、第一画面を補足する視聴覚コンテンツおよび／またはデータにアクセスできるようにする。これらの解決策の多くは、インターネットアクセスが補足コンテンツを検索しかつ表示するために第二画面デバイスを利用可能であるかに左右される。このタイプの解決策の不利点は、サーバのインフラストラクチャおよび帯域幅が大量の同時に行われるアクセス、例えば、１２００万以上もの同時に行われるアクセスを確実にサポートできるように、放送局側で投資およびメンテナンスに高額を費やす場合があることである。他方で、メインＴＶコンテンツが伝送される同デジタルＴＶ信号放送においてこれらの補足コンテンツを提供することははるかに経済的効率が良い。後述される図１は、インターネットを通して補足コンテンツをユーザデバイスに配信するための方法の概要を示す。

本発明は、デジタルＴＶ信号放送を受信する能力がないユーザデバイスにデジタルＴＶ信号放送で伝送される視聴覚コンテンツおよび／またはデータを配信するための、方法、ＭＰＥＧ−２プライベートセクションカプセル化デバイス、対話型アプリケーション、データネットワーク用通信プロトコル、および他の機構に関する。

いくつかの実装形態では、本発明による、デジタルＴＶ信号放送を受信する能力がないユーザデバイスに視聴覚コンテンツおよび／またはデータを配信するための方法は、視聴覚コンテンツをユーザデバイスにおいて再現できるフォーマットに適応させる（またはトランスコーディングする）ためのデバイスを含む。これらの適応処理は、例えば、ビデオの解像度およびアスペクト比、オーディオおよびビデオビットレート、ならびに、オーディオおよびビデオ符号化の調整を含むことができる。

本発明によるいくつかの実装形態では、方法は、適応させた視聴覚コンテンツおよび／またはデータをＭＰＥＧ−２プライベートセクションでカプセル化し、かつ、デジタルＴＶ信号放送で伝送されるようにＭＰＥＧ−２トランスポートストリームでの後の多重送信のためにＭＰＥＧ−２トランスポートストリームパケットのストリームでシリアル化するためのＭＰＥＧ−２プライベートセクションカプセル化デバイスを含む。

本発明によるいくつかの実装形態では、デジタルＴＶ信号放送で伝送される同ＭＰＥＧ−２トランスポートストリームにおいて、デジタルＴＶ受信機による実行用の対話型アプリケーションは多重化されかつ伝送される。予想できるように、このＭＰＥＧ−２トランスポートストリームは、メインＴＶコンテンツ、すなわち、オーディオ、ビデオ、クローズドキャプション／字幕なども含む。

本発明によるいくつかの実装形態では、デジタルＴＶ受信機はＴＶセットまたはセットトップボックスとすることができる。デジタルＴＶ受信機は、デジタルＴＶ信号放送にチューニングする時、ＭＰＥＧ−２トランスポートストリームを復号し、かつ、デジタルＴＶ受信機の画面およびスピーカーにおいて、オーディオ、ビデオ、クローズドキャプション／字幕であるメインＴＶコンテンツを再現する。あるいは、セットトップボックスの場合、これらのコンテンツは対応するオーディオおよびビデオ出力から出力される。さらには、デジタルＴＶ受信機は、対話型アプリケーションをその受信機の実行範囲内で、または、ＭＨＰ、Ｇｉｎｇａなどの対話型デジタルＴＶミドルウェア内で復号かつ実行する。対話型アプリケーションは、視聴覚コンテンツおよび／またはデータをＭＰＥＧ−２トランスポートストリームからカプセル化するＭＰＥＧ−２プライベートセクションを抽出するための実行環境で利用可能なＡＰＩを使用する。これらのＡＰＩの例として、Ｇｌｏｂａｌｌｙ Ｅｘｅｃｕｔａｂｌｅ ＭＨＰ（ＧＥＭ）仕様、またはブラジル標準ＡＢＮＴ ＮＢＲ １５６０６−６によって指定されるＡＰＩのｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇに基づくシステムの、ＡＰＩのｏｒｇ．ｄａｖｉｃ．ｍｐｅｇ．ｓｅｃｔｉｏｎｓが挙げられ得る。

本発明によるいくつかの実装形態では、デジタルＴＶ受信機はローカルエリアネットワーク（ＬＡＮ）に接続される。このＬＡＮは、有線（イーサネット）（イーサネットは登録商標。以下同じ）は、無線（ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎまたは同様のものなど）、または、有線および無線の両方のタイプの組み合わせとすることができる。

本発明によるいくつかの実装形態では、対話型アプリケーションおよびユーザデバイスによって、これらの間で同じＬＡＮに接続される時の通信のために、ＩＰネットワークに基づいて、データネットワーク用通信プロトコルが実装される必要がある。

本発明によるいくつかの実装形態では、データネットワーク用通信プロトコルは、対話型アプリケーションおよびユーザデバイスが同じＬＡＮにおける互いの存在を認識できるようにする発見機構を提供する。

本発明によるいくつかの実装形態では、この発見機構は、対話型アプリケーションがその存在をユーザデバイスに通知すること、ユーザデバイスがそのデバイス各々の存在を対話型アプリケーションに通知すること、または、これら両方の任意の組み合わせを必要とする場合がある。

本発明によるいくつかの実装形態では、データネットワーク用通信プロトコルは、視聴覚コンテンツ通知機構、および、ユーザデバイスが対話型アプリケーションを通して利用可能であるコンテンツを認識できるようにするデータ通知機構を提供する。これらの機構のいくつかの実装形態では、対話型アプリケーションがかかるコンテンツの利用可能性を通知すること、ユーザデバイスが一定時間内で利用可能であるコンテンツについて対話型アプリケーションに問い合わせすること、または、これらの任意の組み合わせが必要とされる場合がある。

本発明によるいくつかの実装形態では、データネットワーク用通信プロトコルは、ユーザデバイスが、ＭＰＥＧ−２トランスポートストリームから抽出された視聴覚コンテンツおよび／またはデータを配信するように対話型アプリケーションに要求できるようにする視聴覚コンテンツ要求機構およびデータ要求機構を提供する。

本発明によるいくつかの実装形態では、データネットワーク用通信プロトコルは、対話型アプリケーションが、ＭＰＥＧ−２トランスポートストリームから抽出された視聴覚コンテンツおよび／またはデータをユーザデバイスに配信できるようにする視聴覚コンテンツ配信機構およびデータ配信機構を提供することができる。

本発明によるいくつかの実装形態では、ユーザデバイスは、対話型アプリケーションによって配信された視聴覚コンテンツおよび／またはデータを受信できるものとし、かつ、復号プロセス、処理および解釈を行って、そのデバイスの各々の画面およびスピーカーで視聴覚コンテンツおよび／もしくはデータを再生するならびに／または呈示することができるものとする。

本発明によるいくつかの実装形態では、ユーザデバイスは、タブレット、スマートフォン、パーソナルコンピュータ、および、ＬＡＮに接続でき、かつ、画面、およびスピーカーまたはヘッドフォンなどのオーディオ出力を有する任意の他のデバイス、または、これらの要素の任意の組み合わせであってよい。

本発明によるいくつかの実装形態では、ユーザデバイスは、本明細書に記載される動き、機能性、およびプロトコルをサポートするための１つまたは複数のアプリケーションを実行することができる。

インターネットを使用してユーザデバイスに補足コンテンツを配信するための既存の方法の概要を示すブロック図である。 デジタルＴＶ信号放送のチューニング能力がないユーザデバイスに視聴覚コンテンツおよび／またはデータを配信するための方法の概要を示すブロック図である。 デジタルＴＶ信号放送のチューニング能力がないユーザデバイスに視聴覚コンテンツおよび／またはデータを配信するための伝送プロセスを示すブロック図である。 ＭＰＥＧ−２プライベートセクションの論理構造を示す図である。 図５は、各機構を概略の説明図である。 図６は、各機構の詳細な説明図である。

技術的問題点
本発明の目的は、デジタルＴＶ信号放送を受信する能力がないユーザデバイスにデジタルＴＶ信号放送で伝送される視聴覚コンテンツおよび／またはデータを配信するための手段を提供することである。ユーザデバイスの例には、メイン画面またはメインデバイスとしても知られているデジタルＴＶ受信機に再生されるメインＴＶコンテンツを補足するコンテンツにアクセスするために第二画面デバイスとして使用されるタブレットまたはスマートフォンを挙げることができる。このような補足コンテンツは、例えば、ビデオクリップおよび／もしくはオーディオ、ライブビデオ放送などの視聴覚コンテンツ、または、例えば、テキスト、写真、統計データなどのデータであってよい。通常、補足コンテンツは、メインＴＶコンテンツに関連があるものとすることができるが、これは必要条件ではない。

かかるユーザデバイスにおいてデジタルＴＶ信号放送を受信する能力がないことによって、一般的に、補足コンテンツはインターネット接続によって受信される。

図１は、コンテンツ制作者（４００）が、デジタルＴＶ受信機（４１２）の画面およびスピーカーにおいて再現されるメインＴＶコンテンツであるデジタルＴＶ信号放送（４１０）を生成しかつ伝送するデジタルＴＶ放送局（４０４）にメインＴＶコンテンツ（４０２）を送信する状況を示す。並行して、コンテンツ制作者（４００）は、通常は、視聴覚コンテンツおよび／またはデータ（４１４）である補足コンテンツを、インターネット（４２０）に接続されるデジタルＴＶ放送局のサーバ（４１６）へ配信する。ユーザデバイス（４２２）は、補足コンテンツ（４１８）をデジタルＴＶ放送局のサーバ（４１６）から取り込み、かつ、このコンテンツをこれらデバイスの各々の画面に呈示する。要求されるデジタルＴＶ放送局のサーバの帯域幅（４２４）およびサーバ（４１６）は、補足コンテンツ（４１８）を要求するユーザデバイス（４２２）の数に従って増加する。よって、このタイプのコンテンツを配信するためにインターネットを使用すると、以下の欠点は不可避である。
ａ．局のそばにおけるブロードバンドおよびサーバインフラストラクチャへの投資は、補足コンテンツにアクセスするユーザ数に比例して増加する。
ｂ．配信の信頼性およびユーザ体験は、ユーザ側のインターネットアクセスの帯域幅および品質によって影響を受ける可能性がある。

加えて、対話型ＴＶとしても知られている上述されるシステムのデータ放送において使用されるカルーセル技法には、ＤＳＭＣＣデータカルーセルまたはＤＳＭＣＣオブジェクトカルーセルプロトコル（ＩＳＯ１３８１８−６）を使用するビデオコンテンツまたはライブビデオコンテンツといった大きなファイルを配信できないという、カルーセルで送られる最大サイズのコンテンツに関連する限界がある。

本発明は、ユーザ側のインターネットアクセスの利用可能性に関係なく、信頼できる配信および保証されたユーザ体験と共に、追加の費用がかからずに、上述されるようなインターネットを使用したコンテンツ配信の欠点を回避して、デジタルＴＶ信号放送で使用されない帯域幅を使用した補足コンテンツの配信を可能にする。

技術的解決策−概要
本発明は、ライブオーディオまたはビデオストリームを含む、継続時間またはサイズが限定されることのないオーディオまたはビデオストリームなどの補足コンテンツの配信を可能にする。

図２は本発明の概要を示す。コンテンツ制作（１００）のプロセスは、オーディオ、ビデオ、字幕および／またはクローズドキャプション、ならびに、通常は従来のデジタルＴＶ信号放送サービスによって生成される任意の他のコンテンツを含むメインＴＶコンテンツ（１０２）をもたらす。加えて、コンテンツ制作（１００）は、ユーザデバイスにおける再生用の視聴覚コンテンツ（１０４）とも呼ばれる補足コンテンツをもたらす。ＭＰＥＧ−２トランスポートストリームとして符号化されるデジタルＴＶ信号放送（１１０）の視聴覚コンテンツおよび／またはデータ（１０４）を抽出すること、および、このようなコンテンツおよび／またはデータをユーザデバイスに転送することができる対話型アプリケーション（１０６）も提供される。デジタルＴＶ放送局（１０８）は、メインＴＶコンテンツ（１０２）、視聴覚コンテンツおよび／またはデータ（１０４）、ならびに対話型アプリケーション（１０６）を含むデジタルＴＶ信号放送を生成しかつ伝送する。

デジタルＴＶ受信機（１１２）は、ＭＰＥＧ−２トランスポートストリームを復号し、かつ、メインＴＶコンテンツ、すなわちオーディオ、ビデオ、クローズドキャプション／字幕などを再現するためにデジタルＴＶ信号放送をチューニングするか、あるいは、セットトップボックスの場合、コンテンツは各オーディオおよびビデオ出力から出力される。

デジタルＴＶ受信機はまた、対話型アプリケーション（１１８）をその受信機の実行環境（１１６）内で復号かつ実行する。実行環境の例には、ＭＨＰ、Ｇｉｎｇａなどの対話型デジタルＴＶミドルウェアを挙げることができる。対話型アプリケーション（１１８）は、カプセル化された視聴覚コンテンツおよび／またはデータ（１２０）で構成されているＭＰＥＧ−２プライベートセクションをＭＰＥＧ−２トランスポートストリームから抽出するための実行環境（１１６）で利用可能なＡＰＩを使用する。これらのＡＰＩの例として、Ｇｌｏｂａｌｌｙ Ｅｘｅｃｕｔａｂｌｅ ＭＨＰ（ＧＥＭ）仕様、およびブラジル標準ＡＢＮＴ ＮＢＲ １５６０６−６によって指定されるｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇのＡＰＩに基づくシステムで利用可能なＡＰＩのｏｒｇ．ｄａｖｉｃ．ｍｐｅｇ．ｓｅｃｔｉｏｎｓが挙げられ得る。

デジタルＴＶ受信機（１１２）を、有線（例えばイーサネット）、無線（例えばＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎネットワークまたは同様のものなど）、または、有線および無線の両方のタイプの組み合わせとすることができるＬＡＮ（１２２）に接続させる必要がある。

また、ユーザデバイス（１２６）が視聴覚コンテンツおよび／またはデータを受信しかつ再現できるようにするために、これらデバイスは、デジタルＴＶ受信機（１１２）と同じＬＡＮ（１２２）で接続される必要がある。例として、ユーザデバイス（１２６）は、タブレット、スマートフォン、パーソナルコンピュータ、または、ＬＡＮ（１２２）に接続でき、かつ、画面、および／または、スピーカーまたはヘッドフォンなどのオーディオ出力を有する任意の他のデバイスとすることができる。いくつかの実装形態では、ユーザデバイス（１２６）は、本発明によってこれらデバイスによるものである動き、機能性およびプロトコルを実装するために１つまたは複数のアプリケーションをホストとして処理しかつ実行できる。

技術的解決策−放送局側
本発明のプロセスにおいて入力されるのは、現状技術のコンテンツ制作（２００）ワークフローによって生成されるコンテンツである。コンテンツ制作（２００）は、オーディオ、ビデオ、字幕、クローズドキャプション、および、一般的に従来のデジタルＴＶ放送サービスのために生成されることが多い任意の他のコンテンツを含むメインＴＶコンテンツ（２０２）をもたらす。さらに、コンテンツ制作（２００）は、ユーザデバイスにおける再生用の視聴覚コンテンツ（２０４）とも呼ばれる補足コンテンツをもたらす。

コンテンツ制作（２００）によってもたらされるような、ユーザデバイスにおける再生用の視聴覚コンテンツ（２０４）の場合、ユーザデバイスにおいて再現されるように、または、小さなチャンクに分けて伝送されるように適応させる必要があり、トランスコーダデバイス（２０６）は、視聴覚コンテンツを再符号化するために使用される。かかる適応処理は、例えば、ビデオ解像度およびそのアスペクト比、オーディオおよびビデオビットレート、ならびに、オーディオおよびビデオ符号化の調整、および、視聴覚コンテンツをストリームとして送信可能なフォーマットに変換する必要がある可能性がある任意の他の調整を含むことができる。ストリームとして送信できるフォーマットの例として、ＭＰＥＧ−２トランスポートストリームプロトコル、ＲＴＰ／ＲＴＰＳ、ＨＬＳなどで使用されるものの任意のものが挙げられ得る。トランスコーダデバイス（２０６）は、ユーザデバイスにおいて再生されるように適応された視聴覚コンテンツ（２０８）を出力する。このステップは、コンテンツ制作（１００）（２００）によってもたらされる視聴覚コンテンツが、既に、ユーザデバイスにおいて再生される（２０８）のに、かつ、ストリーム形式で伝送されるのに適したフォーマットである場合は無視できる。

ユーザデバイスにおいて再生されるように既に適応させている視聴覚コンテンツ（２０８）は、その後、ＭＰＥＧ−２プライベートセクションカプセル化デバイス（２１２）によってＭＰＥＧ−２プライベートセクションでカプセル化される。ＭＰＥＧ−２プライベートセクションカプセル化デバイス（２１２）は、以下のステップから成る方法を使用してＭＰＥＧ−２プライベートセクションのシーケンスを生成する。
ａ．既定値を、ｔａｂｌｅ＿ｉｄのフィールドに割り当てる。
ｂ．連続的にインクリメントさせる値を、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドに割り当てる。
ｃ．ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドの値がｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドに割り当てられた（０から２５５までの）既定値に達する度に、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのシーケンスは０でリスタートされる。
ｄ．ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのシーケンスがリスタートされる度に、連続的にインクリメントさせる値を、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドに割り当てる。
ｅ．ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドの値が（１から３１までの）このフィールドの最大既定値に達する度に、シーケンスは（０からｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒの最大既定値−１までの）既定の初期値でリスタートされる。
ｆ．ＭＰＥＧ−２プライベートセクションに対して定められた最大既定サイズ（大抵の場合、最大既定サイズは４０９５バイト）を超えないように、規則正しく、できるだけ多くの視聴覚コンテンツ（２０８）のチャンクまたはパッケージをこのフィールド内に収めるように、ＭＰＥＧ−２プライベートセクションのｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅのフィールドに追加する。
ｇ．ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈおよびＣＲＣのフィールドに対して値を計算しかつ設定する。
ｈ．ＭＰＥＧ−２トランスポートストリームパケット（２１４）のシーケンスにおけるＭＰＥＧ−２プライベートセクションを分割し、かつ、それらの全てに、ｐａｃｋｅｔ＿ｉｄ（ＰＩＤ）のフィールドに対する同じ既定値を設定する。
ｉ．生成されたＭＰＥＧ−２トランスポートストリームパケット（２１４）をＭＰＥＧ−２トランスポートストリームマルチプレクサ（２２２）に配信する。

（ａ）から（ｉ）までのステップが継続的に繰り返される間、視聴覚コンテンツは利用可能である。

上記方法のステップ（ｆ）の変形例によって、視聴覚コンテンツのチャンクまたはパッケージを、生成されるＭＰＥＧ−２プライベートセクションの現在のものと次のものとの間で分割することができ、適用可能となる度に、ＭＰＥＧ−２プライベートセクションが可能とされる最大サイズを有する限り適用可能となる（ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈのフィールド−通常は４０９５バイト）。このアプローチは、より少ないＭＰＥＧ−２プライベートセクションでより多くの視聴覚コンテンツのチャンクおよびパッケージを配信させることができるため、より効果的である。

本発明によるいくつかの実装形態では、トランスコーダデバイスは、後にＭＰＥＧ−２プライベートセクションカプセル化デバイスによってＭＰＥＧ−２プライベートセクションでカプセル化される、ＲＴＰ制御パッケージ、ＲＴＰおよびＲＴＰセッション記述子パッケージで構成されているストリームのフォーマットでユーザデバイスに呈示するように適応させた視聴覚コンテンツを提供することができる。

本発明による他の実装形態では、トランスコーダデバイスは、後にＭＰＥＧ−２プライベートセクションカプセル化デバイスによってＭＰＥＧ−２プライベートセクションでカプセル化される、ＭＰＥＧ−２トランスポートストリームパッケージで構成されているストリームのフォーマットでユーザデバイスに呈示するように適応される視聴覚コンテンツを提供できる。

ユーザデバイスに呈示するように適応された視聴覚コンテンツ（２０８）に加えて、ＭＰＥＧ−２プライベートセクションカプセル化デバイス（２１２）は、ユーザデバイスによって解釈できる包括的なデータ（２１０）のチャンクまたは構造で構成されているＭＰＥＧ−２プライベートセクションを生成することができる。カプセル化プロセスは、ユーザデバイスに呈示するために適応された視聴覚コンテンツ（２０８）について説明されるものと全く同じである。

さらに、デジタルＴＶ受信機による実行用の対話型アプリケーション（２１６）は、対話型アプリケーションのエンコーダデバイス（２１８）によって符号化される。

メインＴＶコンテンツＴＶ（２０２）、符号化された対話型アプリケーション（２２０）、およびＭＰＥＧ−２プライベートセクションでカプセル化された視聴覚コンテンツおよび／またはデータ（２１４）は、デジタルＴＶ信号放送で伝送される（２２６）のに適したＭＰＥＧ−２トランスポートストリーム信号（２２４）を生成することになるＭＰＥＧ−２トランスポートストリームマルチプレクサ（２２２）へ転送される。最後に、デジタルＴＶ伝送デバイス（２２６）はデジタルＴＶ信号放送を伝送する。これらの伝送信号の例として、地上波ＴＶ無線周波数信号、衛星ＴＶ信号、またはケーブルＴＶ信号が挙げられ得る。

技術的解決策−受信側
デジタルＴＶ受信機（１１２）は、デジタルＴＶ信号放送にチューニングし、ＭＰＥＧ−２トランスポートストリームを復号し、メインＴＶコンテンツ、すなわち、オーディオ、ビデオ、クローズドキャプション／字幕などをこの受信機の画面およびスピーカ（１１４）で再現する。あるいは、セットトップボックスの場合、画像および音は、それぞれのオーディオおよびビデオ出力から出力される。

デジタルＴＶ受信機はまたは、その実行環境（１１６）内で対話型アプリケーション（１１８）を復号しかつ実行する。実行環境は、ＭＨＰ、Ｇｉｎｇａなどの対話型デジタルＴＶミドルウェアとすることができる。対話型アプリケーション（１１８）は、実行環境（１１６）で利用可能なＡＰＩを使用して、ＭＰＥＧ−２トランスポートストリームから、視聴覚コンテンツおよび／またはカプセル化データ（１２０）で構成されているＭＰＥＧ−２プライベートセクションを抽出する。これらＡＰＩの例として、Ｇｌｏｂａｌｌｙ Ｅｘｅｃｕｔａｂｌｅ ＭＨＰ（ＧＥＭ）仕様、またはＡＢＮＴ ＮＢＲ １５６０６−６において指定されるＡＰＩのｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇに基づくシステムにおいて利用可能なＡＰＩのｏｒｇ．ｄａｖｉｃ．ｍｐｅｇ．ｓｅｃｔｉｏｎｓが挙げられ得る。

デジタルＴＶ受信機（１１２）はＬＡＮ（１２２）に接続される必要がある。このＬＡＮ（１２２）は、有線（例えばイーサネット）、無線（ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎネットワークまたは同様のものなど）、または、有線および無線の両方のタイプの組み合わせとすることができる。

また、ユーザデバイス（１２６）は、視聴覚コンテンツおよび／またはデータを受信しかつ再現するために、デジタルＴＶ受信機（１１２）と同じＬＡＮ（１２２）で接続されなければならない。例として、ユーザデバイス（１２６）は、タブレット、スマートフォン、パーソナルコンピュータ、または、ＬＡＮ（１２２）に接続でき、かつ、画面、および／または、スピーカーまたはヘッドフォンなどのオーディオ出力を有する任意の他のデバイスとすることができる。いくつかの実装形態では、ユーザデバイス（１２６）は、本発明によってこれらデバイスによるものである動き、機能性および通信プロトコルを実装するために１つまたは複数のアプリケーションをホストとして処理しかつ実行できる。

デジタルＴＶ受信機（１１２）で実行されている対話型アプリケーション（１１８）、およびユーザデバイス（１２６）は、共通のデータネットワーク用通信プロトコルを使用して互いに通信する。かかるデータネットワーク用通信プロトコルは、全てのユーザデバイスおよび対話型アプリケーションによって実装される。データネットワーク用通信プロトコルは、対話型アプリケーションおよびユーザデバイスの発見、視聴覚コンテンツ通知、データ通知、視聴覚コンテンツ要求、データ要求、視聴覚コンテンツ配信、およびデータ配信のための機構を含む。

データネットワーク用通信プロトコルを使用して、ユーザデバイス（１２６）は、
ａ．対話型アプリケーションの存在を認識し、
ｂ．視聴覚コンテンツの利用可能性を認識し、
ｃ．データの利用可能性を認識し、
ｄ．視聴覚コンテンツの配信を対話型アプリケーション（１１８）に要求し、
ｅ．データの配信を対話型アプリケーション（１１８）に要求し、
ｆ．視聴覚コンテンツ（１２４）を対話型アプリケーション（１１８）から受信し、
ｇ．データ（１２４）を対話型アプリケーション（１１８）から受信する。

ユーザデバイス（１２６）は、それら各々の画面および／またはスピーカーにおいて、受信された視聴覚コンテンツおよび／またはデータを復号し、処理し、再現する。

技術的解決策−対話型アプリケーションとユーザデバイスとの間のデータネットワーク用通信プロトコル
デジタルＴＶ受信機（１１２）およびユーザデバイス（１２６）において実行される対話型アプリケーション（１１８）は、それらの間の通信を可能にするデータネットワーク用通信プロトコルを実装しなければならない。対話型アプリケーション（１１８）が実行される全てのユーザデバイス（１２６）およびデジタルＴＶ受信機（１１２）は同じＬＡＮ（１２２）に接続される。データネットワーク用通信プロトコルは、とりわけ、図６に示されるような以下の機構を企図する場合がある。
ａ．発見（５０４）：対話型アプリケーション（５００）およびユーザデバイス（５０２）が同じＬＡＮに接続される時に互いの存在を認識できるようにするための機構。
ｂ．視聴覚コンテンツ通知（５０６）：ユーザデバイス（５０２）が、対話型アプリケーション（５００）を通して提供されかつユーザデバイスによって消費されることになる視聴覚コンテンツの利用可能性を認識できるようにする機構。
ｃ．データ通知（５０８）：ユーザデバイス（５０２）が、対話型アプリケーション（５００）を通して提供されかつユーザデバイスによって消費されることになるデータの利用可能性を認識できるようにする機構。
ｄ．視聴覚コンテンツの要求（５１０）：ユーザデバイス（５０２）が視聴覚コンテンツを配信するように対話型アプリケーション（５００）に要求できるようにする機構。
ｅ．データの要求（５１２）：ユーザデバイス（５０２）がデータを配信するように対話型アプリケーション（５００）に要求できるようにする機構。
ｆ．視聴覚コンテンツの配信（５１４）：対話型アプリケーション（５００）からユーザデバイス（５０２）へ視聴覚コンテンツを配信するための機構。
ｇ．データの配信（５１６）：対話型アプリケーション（５００）からユーザデバイス（５０２）へデータを配信するための機構。

データネットワーク用通信プロトコルは、ＵＤＰデータグラム（二地点間ＵＤＰデータグラム、一地点対多地点ＵＤＰデータグラム、および放送ＵＤＰデータグラム）およびＴＣＰ接続の任意の組み合わせを使用したメッセージ交換として実装可能である。

本発明による種々の実装形態では、通信プロトコルは、対話型アプリケーション（５００）によって、ユーザデバイス（５０２）によって、またはそれらのうちの任意の１つによって開始されるように設計されてよい。

視聴覚コンテンツおよび／またはデータを配信するための機構の実装形態は、ＭＰＥＧ−２トランスポートストリームから抽出される未処理のＭＰＥＧ−２プライベートセクションの配信を考慮することができる。あるいは、視聴覚コンテンツおよび／またはデータを配信するための機構の実装形態は、ＭＰＥＧ−２トランスポートストリームから抽出されるＭＰＥＧ−２プライベートセクションを復号／処理し、かつ、ＭＰＥＧ−２プライベートセクションのヘッダーおよびＣＲＣを廃棄して、カプセル化された視聴覚コンテンツおよび／またはデータのみをユーザデバイス（５０２）に配信するために、デジタルＴＶ受信機で実行されている対話型アプリケーション（５００）を考慮することができる。

ユーザデバイスの場合、記載される、データネットワーク用通信プロトコルの実装形態は、ユーザデバイスに内蔵可能であるか、ユーザデバイスにおいてインストールされかつ実行される１つまたは複数のユーザアプリケーションによって実装可能である。

技術的解決策−全般的な利点
ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドおよびｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドの値を定めるために使用される方法は、視聴覚コンテンツ（２０８）および／またはデータ（２１０）の新しいチャンクまたはパッケージの継続的な配信を可能にする。ＭＰＥＧ−２プライベートセクションでカプセル化されたかかるチャンクおよびパッケージ（２１４）の有効期限は、一般的に非常に短く、ユーザデバイス（１２６）によって即座に処理されかつ廃棄されることが考えられる。ユーザデバイス（１２６）が利用可能ではないか視聴覚コンテンツの配信を要求していない場合、対話型アプリケーション（１１８）はかかるチャンクまたはパッケージを即座に廃棄する。このために、本発明による方法はまた、ライブ視聴覚コンテンツ放送に適用可能である。

実施例
以降、上記で詳述されるような、本発明の方法、デバイス、プロトコル、および対話型アプリケーションの実装例が論証される。しかしながら、このような実施例は、他の形式の実装形態が当業者には想起可能であるため、本発明の範囲および限界を限定するものと考えられるべきではない。

実装例−放送側
実施例１−ＲＴＰストリームを使用した視聴覚コンテンツの符号化
放送システムは、ブラジルのデジタルＴＶシステムＩＳＤＢ−Ｔに従って構築され、かつ、局の伝送ワークフローに容易に統合される。

メインＴＶコンテンツは、Ｈ．２６４およびＭＰＥＧ−４ ＡＡＣそれぞれの符号化方式を使用したビデオおよびオーディオストリームとすることができ、クローズドキャプションも含まれ得る。電子番組ガイド（ＥＰＧ）用のデータ、および他のサービス情報（ＳＩ）メタデータは、ＡＢＮＴ ＮＢＲ １５６０３の規格に従って生成できかつ含まれ得る。

対話型アプリケーションは、Ｇｉｎｇａミドルウェア規格（ＡＢＮＴ ＮＢＲ １５６０６）に従って開発でき、ＡＢＮＴ ＮＢＲ １５６０６−６で指定されるＡＰＩのｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇを使用して、ＭＰＥＧ−２プライベートセクションをデジタルＴＶ信号放送に含まれるＭＰＥＧ−２トランスポートストリームから抽出することができる。データネットワーク用通信プロトコルは、Ｇｉｎｇａミドルウェア規格（ＡＢＮＴ ＮＢＲ １５６０６−４）にも含まれる、Ｐｅｒｓｏｎａｌ Ｂａｓｉｓ Ｐｒｏｆｉｌｅ １．２．１で指定されるｊａｖａ．ｎｅｔパッケージによって提供されるＡＰＩで実装できる。

対話型アプリケーションエンコーダデバイスは、ＤＳＭＣＣオブジェクトカルーセルプロトコルでＧｉｎｇａアプリケーションを符号化するために使用されるＧｉｎｇａ対話式プレイアウトデバイスで実装されてよい。

ＭＰＥＧ−２トランスポートストリームの多重化および放送は、従来のＩＳＤＢ−ＴデジタルＴＶ放送で既に使用されているのと同じ機器を使用して行われ得る。

コンテンツ制作プロセスによってもたらされるユーザデバイスのための視聴覚コンテンツは、ＦｕｌｌＨＤビデオおよびオーディオストリームとすることができ、事前録画またはライブ放送でき、ビデオおよびオーディオそれぞれに対して、Ｈ．２６４およびＭＰＥＧ−４ ＡＡＣの符号化方式を使用して符号化可能である。ビットレートは、ＦｕｌｌＨＤフォーマットに対する高品質放送を可能にする任意の値を有することができる（例えば、１３Ｍｂｐｓ）。

トランスコーダデバイスは、ＦｕｌｌＨＤビデオを、ユーザデバイスによって再現されるのに適した解像度、符号化、ビットレート、およびフレームレートに再符号化する（例えば、７２０×３６２、Ｈ．２６４、１５ｆｐｓ）。同様に、オーディオは、ユーザデバイスにおいて再生されるのに適切なフォーマット、ビットレート、サンプルレート、および符号化に再符号化される（例えば、ＭＰＥＧ−４ ＡＡＣ ＨＥ）。全ビットレートは５００Ｋｂｐｓに低減される。適応させたストリームは、ＲＴＰパッケージおよびＲＴＰ制御パッケージで構成されている、ＲＴＰストリームとしてＲＴＰ／ＲＴＳＰプロトコルを使用してトランスコーダデバイスによって生成される。トランスコーダデバイスはまた、ＲＴＰセッション記述子のタイプのデータ構造を生成する。

ＭＰＥＧ−２プライベートセクションカプセル化デバイスは、トランスコーダデバイスによって生成された、ＲＴＳＰストリームパッケージ、ＲＴＰ制御パッケージ、およびＲＴＰセッション記述子を受信し、かつ、ｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅのフィールドにおいてＲＴＰ／ＲＴＳＰパッケージを加えてＭＰＥＧ−２プライベートセクションを生成する。生成されたＭＰＥＧ−２プライベートセクションは、ＭＰＥＧ−２トランスポートストリームパケットのシーケンスとしてＭＰＥＧ−２トランスポートストリームマルチプレクサに転送され、最終的に、デジタルＴＶ信号放送に挿入される。

実施例２−ＭＰＥＧ−２トランスポートストリームのストリームを使用した視聴覚コンテンツの符号化
実施例１から導き出される他の実装例では、トランスコーダデバイスは、ＦｕｌｌＨＤビデオを、ユーザデバイスによって再生されるのに適した解像度、コード化、ビットレート、およびフレームレートに再符号化する（例えば、７２０×３６２、Ｈ．２６４、１５ｆｐｓ）。同様に、オーディオは、ユーザデバイスにおいて再生されるのに適切なフォーマット、ビットレート、サンプルレート、および符号化に再符号化される（例えば、ＭＰＥＧ−４ ＡＡＣ ＨＥ）。全ビットレートは５００Ｋｂｐｓに低減される。適応させたストリームは、ストリームを復号するために必要とされるＰＳＩを含む、ＭＰＥＧ−２トランスポートストリームのシーケンスで構成されているストリームとしてＭＰＥＧ−２トランスポートストリームプロトコルを使用してトランスコーダデバイスによって生成される。

ＭＰＥＧ−２プライベートセクションカプセル化デバイスは、トランスコーダデバイスによって生成されるＭＰＥＧ−２トランスポートストリームパケットのシーケンスのストリームを受信し、かつ、ｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅのフィールドにおいてＭＰＥＧ−２トランスポートストリームパケットを加えてＭＰＥＧ−２プライベートセクションを生成する。生成されたＭＰＥＧ−２プライベートセクションは、ＭＰＥＧ−２トランスポートストリームパケットのシーケンスとしてＭＰＥＧ−２トランスポートストリームマルチプレクサに転送され、最終的に、デジタルＴＶ信号放送に挿入される。

実装例−受信側
デジタルＴＶ受信機の実装例として、ＡＢＮＴ ＮＢＲ １５６０６に従ったＧｉｎｇａ対話型ミドルウェアサポートも含むＩＤＳＢ−ＴデジタルＴＶサービスをチューニングしかつ復号することができ、イーサネットインターフェイスまたはＷｉ−ＦｉによってＬＡＮに接続できるＴＶ装置またはセットトップボックスのどちらかが考えられ得る。

前の節で説明したように、インストールされ、かつ、ＩＳＤＢ−ＴデジタルＴＶ信号放送で放送されているＧｉｎｇａ対話型アプリケーションによって実施される同じデータネットワーク用通信プロトコルを実装するアプリケーションを実行している、任意のユーザのスマートフォンまたはタブレットなどの、使用できる多くのユーザデバイスがあることは強調されるべきである。このアプリケーションは、ＭＰＥＧ−２プライベートセクションでカプセル化されて配信されている視聴覚コンテンツをユーザが選択しかつ再現することができるようにするユーザインターフェイスを有することができる。通常、この機能性は、第二画面アプリケーションといったより一層複雑なアプリケーションの一部とすることが可能である。

実装例−対話型アプリケーションとユーザデバイスとの間のデータネットワーク用通信プロトコル
対話型アプリケーションは、Ｇｉｎｇａミドルウェア仕様、ＡＢＮＴ ＮＢＲ １５６０６規格に従って開発できる。データネットワーク用通信プロトコルは、ブラジルＡＢＮＴ ＮＢＲ １５６０６−４規格のように、Ｇｉｎｇａミドルウェア仕様の一部でもあるＰｅｒｓｏｎａｌ Ｂａｓｉｓ Ｐｒｏｆｉｌｅ１．２．１において指定されるｊａｖａ．ｎｅｔパッケージで利用可能なＡＰＩで実装できる。

ユーザデバイスで実行されるアプリケーションの場合、データネットワーク用通信プロトコルは、かかるプラットフォーム（例えば、ｉＯＳおよびアンドロイド）で利用可能なネットワークアクセスＡＰＩを使用して実装できる。

この例では、発見機構は、図６のａに示されるように、１０秒ごとに放送ＵＤＰデータグラムとしてメッセ−ジを送信する対話型アプリケーション（６００）によって実装されてよい。

この例では、視聴覚コンテンツおよびデータ通知機構は、図６のａに示されるように、対話型アプリケーション（６００）が、１０秒ごとに放送ＵＤＰデータグラムとして視聴覚コンテンツおよび利用可能なデータについての情報ならびに詳細で構成されているメッセージを送信するように実装できる。

視聴覚コンテンツ要求機構およびデータ要求機構は、図６のｂに示されるように、ユーザデバイス（６０２）において実行されるアプリケーションが、二地点間ＵＤＰデータグラムとして、対話型アプリケーション（６００）へ、通知された視聴覚コンテンツおよび／またはデータの配信を要求するメッセージ（６１２）を送信するように実装可能である。それぞれのユーザデバイスは、５秒ごとにこのメッセージ（６１２）を送信しなければならない。対話型アプリケーション（６００）がある一定時間（例えば１０秒）に所与のユーザデバイス（６０２）からのこのメッセージ（６１２）の受信を停止する場合、対話型アプリケーション（６００）は、ユーザデバイス（６０２）が視聴覚コンテンツおよび／またはデータの受信にもはや関心がなく、この所与のユーザデバイス（６０２）への配信を停止しようとしていることを推定する。

視聴覚コンテンツ配信機構およびデータ配信機構は、図６のｃに示されるように、対話型アプリケーション（６００）がかかる配信を前に要求していたそれぞれのユーザデバイス（６０２）に対して視聴覚コンテンツおよび／またはデータで構成されているメッセージ（６１６）を送信するように実装できる。これらのメッセージ（６１６）は二地点間ＵＤＰデータグラムとしてＬＡＮを通して送信できる。メッセージ（６１６）は、ＡＰＩのｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇによってＭＰＥＧ−２トランスポートストリームから抽出されたそれぞれのＭＰＥＧ−２プライベートセクション（６１４）に対して送られたものとすることができ、このようなＭＰＥＧ−２プライベートセクションのコンテンツ全てを伝えることができる。

この解決策の他の実装例では、視聴覚コンテンツ要求機構およびデータ要求機構は、ユーザデバイスにおいて実行されるアプリケーションが対話型アプリケーションとのＴＣＰ接続を確立するように実装可能である。このＴＣＰ接続が確立されると、視聴覚コンテンツおよび／またはデータ配信はＴＣＰ接続がオープンされる時間で生じることになる。この場合、対話型アプリケーションは、このＴＣＰ接続によって視聴覚コンテンツおよび／またはデータで構成されているメッセージを送信することになる。メッセージは、ＡＰＩのｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇによってＭＰＥＧ−２トランスポートストリームから抽出されたそれぞれのＭＰＥＧ−２プライベートセクションに対して送られたものとすることができ、このようなＭＰＥＧ−２プライベートセクションのコンテンツ全てを伝えることができる。ＴＣＰ接続は、視聴覚コンテンツおよび／またはデータの配信に割り込まざるを得ないことを対話型アプリケーションに示して、ユーザデバイスによってクローズされてよい。

Claims (12)

1. 視聴覚コンテンツストリームをＭＰＥＧ−２プライベートセクションでカプセル化するための方法であって、規則正しく生成されるように、
   ａ．既定値を、ｔａｂｌｅ＿ｉｄのフィールドに入れるステップと、
   ｂ．連続的にインクリメントした値をｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドに入れるステップと、
   ｃ．前記ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドの値がｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドに入れられた既定値（０から２５５まで）に達する時に、前記ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのシーケンスは０でリスタートされるステップと、
   ｄ．前記ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドのシーケンスがリスタートされる時に、連続的にインクリメントされる値をｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドに入れるステップと、
   ｅ．前記ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドの値が該フィールドの最大既定値（１から３１まで）に達する時に、前記ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドのシーケンスは初期既定値（０から前記ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒの最大既定値−１まで）でリスタートされるステップと、
   ｆ．前記ＭＰＥＧ−２プライベートセクションの最大既定サイズを超えないように、規則正しく、できるだけ多くの前記視聴覚コンテンツのチャンクまたはパッケージを、前記ＭＰＥＧ−２プライベートセクションのｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅのフィールド内に収まるように、該フィールドに追加するステップと、
   ｇ．ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈおよびＣＲＣのフィールドに計算した値を入れるステップと、
   ｈ．ＭＰＥＧ−２トランスポートストリームのパケット［２１４］のシーケンスにおける前記ＭＰＥＧ−２プライベートセクションを分割し、該分割したもの全てについてｐａｃｋｅｔ＿ｉｄ（ＰＩＤ）のフィールドに同じ既定値を入れるステップと、
   を含むことを特徴とする方法。
2. 前記視聴覚コンテンツストリームは、ＲＴＰ制御パッケージ、ＲＴＰパッケージ、ＲＴＳＰパッケージ、またはそれらの組み合わせを含む、ことを特徴とする請求項１に記載の方法。
3. 前記ＭＰＥＧ−２プライベートセクションの一部は、ＲＴＰセッション記述子で構成される、ことを特徴とする請求項２に記載の方法。
4. 前記視聴覚コンテンツストリームは、前記ＭＰＥＧ−２トランスポートストリームのパッケットのストリームに含まれる、ことを特徴とする請求項１に記載の方法。
5. ＭＰＥＧ−２トランスポートストリームで多重送信されるように視聴覚コンテンツをＭＰＥＧ−２プライベートセクションでカプセル化するためのデバイスであって、請求項１、２、３、または、４のいずれか１項の方法によって実装される、ことを特徴とする、デバイス。
6. ＩＰベースのローカルエリアネットワーク用の通信プロトコルであって、前記通信プロトコルを実装し、ＬＡＮに接続されるデジタルＴＶ受信機、同じＬＡＮに接続され、同じ前記通信プロトコルを実装する他のユーザデバイスにおいて、実行され、前記通信プロトコルは機構を提供し、前記機構は、
   （ａ）発見機構であって、前記対話型アプリケーションおよび前記ユーザデバイスが同じローカルエリアネットワークに接続される時に互いの存在を認識させる機構と、
   （ｂ）視聴覚コンテンツ通知機構であって、前記ユーザデバイスに、前記対話型アプリケーションを通して提供され、かつ、前記ユーザデバイスによって消費される視聴覚コンテンツの利用可能性を認識させる機構と、
   （ｃ）データ通知機構であって、前記ユーザデバイスに、前記対話型アプリケーションを通して提供され、かつ、前記ユーザデバイスによって消費されることになるデータの利用可能性を認識させる機構と、
   （ｄ）視聴覚コンテンツの要求機構であって、前記ユーザデバイスに、視聴覚コンテンツを配信するように前記対話型アプリケーションに要求させる機構と、
   （ｅ）データの要求機構であって、前記ユーザデバイスに、データを配信するように前記対話型アプリケーションに要求させる機構と、
   （ｆ）視聴覚コンテンツの配信機構であって、前記対話型アプリケーションから前記ユーザデバイスへ視聴覚コンテンツを配信する機構と、
   （ｇ）データの配信機構であって、前記対話型アプリケーションから前記ユーザデバイスへデータを配信する機構と、を含むことを特徴とする、通信プロトコル。
7. 前記機構は、二地点間データグラムＵＤＰ、一地点対多地点ＵＤＰデータグラム、放送ＵＤＰデータグラム、ＴＣＰ接続、またはこれらの技術の組み合わせとして送信されるメッセージとして実装できることを特徴とする、請求項６に記載のデータネットワーク用通信プロトコル。
8. 前記通信プロトコルの実装は、他のユーザデバイス、または、該ユーザデバイスにおいて実行される１つまたは複数のアプリケーションによって、行われることを特徴とする、請求項６に記載のデータネットワーク用通信プロトコル。
9. デジタルＴＶ用対話型アプリケーションであって、デジタルＴＶ放送信号において送信され、デジタルＴＶ受信機において実行される前記アプリケーションは、
   （ａ）請求項６のネットワーク通信プロトコルを実装し、
   （ｂ）前記デジタルＴＶ受信機にて利用可能な機構を使用して、ＭＰＥＧ−２プライベートセクションを前記デジタルＴＶ信号放送のＭＰＥＧ−２トランスポートストリームから抽出し、
   （ｃ）請求項６または７のネットワーク通信プロトコルを使用して、ローカルエリアネットワーク（ＬＡＮ）に接続される他のユーザデバイスに、デジタルＴＶ放送信号に含まれる前記ＭＰＥＧ−２トランスポートストリームから抽出された前記ＭＰＥＧ−２プライベートセクションに含まれるコンテンツの全てまたは一部を配信する、
   ことを特徴とする、デジタルＴＶ用対話型アプリケーション。
10. ユーザデバイス、または、ユーザデバイスと１つまたは複数のアプリケーションとの組み合わせであって、前記ユーザデバイスは、
    （ａ）ＩＰベースのローカルエリアネットワークに有線または無線接続によって接続され、
    （ｂ）請求項６、７及び８のネットワーク通信プロトコルを実装し、
    （ｃ）同じローカルエリアネットワークに接続されたデジタルＴＶ受信機において実行される請求項９の対話型アプリケーションから配信される視聴覚コンテンツの受信、復号、処理、および、再生を可能にする、ユーザデバイス。
11. 視聴覚コンテンツおよび／またはデータを配信するための方法であって、デジタルＴＶ信号放送を通じて、デジタルＴＶ信号放送をチューニングする能力がないユーザデバイスに、データを送信し、
    （ａ）視聴覚コンテンツのストリームを、請求項１、２、３、４の方法によって、ＭＰＥＧ−２プライベートセクションでカプセル化し、または、一体化してトランスポートストリームによってデジタルＴＶ放送信号を構成する、ステップと、
    （ｂ）デジタルＴＶ信号放送を形成するＭＰＥＧ−２トランスポートストリーム内のＭＰＥＧ−２プライベートセクションを多重送信するステップと、
    （ｃ）少なくとも請求項９に記載される機能性を実装する前記対話型アプリケーションを前記デジタルＴＶ信号放送に含めるステップと、
    （ｄ）デジタルＴＶ受信機でチューニングする時に、前記デジタルＴＶ信号放送を、有線または無線によってローカルエリアネットワーク（ＬＡＮ）に接続されたデジタルＴＶ受信機によって行われる、
    ｉ．前記デジタルＴＶ信号を復号し、かつ、前記デジタルＴＶ受信機においてメインＴＶコンテンツを再現するステップと、
    ｉｉ．前記デジタルＴＶ受信機の実行環境において、前記デジタルＴＶ信号放送内で受信される前記対話型アプリケーションを実行するステップと、
    （ｅ）対話型アプリケーションが、請求項６及び７のネットワーク通信プロトコルを用いて、同じローカルエリアネットワーク（ＬＡＮ）に接続されるユーザデバイスを捜索し、前記視聴覚コンテンツおよび／または前記データの利用可能性を通知するステップと、
    （ｆ）同じローカルエリアネットワーク（ＬＡＮ）に接続されるユーザデバイスが、請求項６、７及び８のネットワーク通信プロトコルを用いて、前記視聴覚コンテンツおよび／または前記データの配信を前記対話型アプリケーションに要求するステップと、
    （ｇ）対話型アプリケーションが、請求項６及び７のネットワーク通信プロトコルを用いて、配信を要求した前記ユーザデバイスに、前記視聴覚コンテンツおよび／または前記データを配信するステップと、
    （ｈ）前記視聴覚コンテンツおよび／または前記データの配信を前記対話型アプリケーションに要求する前記ユーザデバイスは、請求項６、７及び８のネットワーク通信プロトコルを用いて、要求される前記視聴覚コンテンツおよび／または前記データを、復号、処理、および再生するステップと、を含むことを特徴とする方法。
12. 前記ＴＶ信号放送は、地上波、衛星、または有線によるものである、請求項１１に記載の方法。