JP5189135B2 - 双方向アプリケーションの記録および再生の制御方法およびシステム - Google Patents

Description

本発明は、デジタル放送のシステムおよび方法に関し、特に、双方向アプリケーションを含む番組の制御および再生に関する。

双方向テレビシステムは、多くの受信契約者に双方向コンテンツとともに通常のテレビに音声および映像番組を送信するための手段を提供する。このようなシステムによって放送される番組には、テレビ音声および映像、静止画像、テキスト、双方向グラフィック、データ、実行可能なアプリケーション、ロケータ、メタデータおよびその他多くのコンポーネントを組み込むことができる。このため、双方向テレビ番組の双方向コンテンツには、アプリケーションコード、音声および映像関連データ、制御信号、追加音声および映像、静止画像、テキスト、生データ、インターネットアドレスおよびその他多種多様な情報を含めることができる。

アプリケーションコードまたはテレビ番組に関連する情報などの双方向コンテンツは、多くの場合受信機に送信するか、オンデマンドで遠隔地にある１つ以上のサーバから取り出すかまたはローカルに格納する。オンデマンド双方向システムにおいて、クライアントからサーバへ要求を送信して、次のサーバから双方向コンテンツを取り出す際のリターンパスが必要である。双方向コンテンツをいったんサーバから取り出すと、受信機は補助コンテンツを受信して、視聴覚番組と同時に同一画面に表示するか、別の方法として、例えば、視聴覚番組と置き換えて表示する。さらに別の方法として、第２の装置（例えば、パソコン、ＰＤＡ、ウェブタブレット、ウェブフォン等）を用いて補助コンテンツを提示できる。さらに、双方向アプリケーションは放送番組と同じ伝送サービスを介して要求に応じて取り出し、送信できるが、また別のネットワークから取り出して受信機に送信することもできる。例えば、従来型ケーブルシステムを介して視聴覚番組を受信している間に、オンライン情報提供者、例えば、インターネットから双方向アプリケーションを取り出して受信できる。

通常の双方向コンテンツの放送では、繰り返し方式で双方向コンテンツを放送する。つまり、最初に一つ一つの情報を放送し、そして二度目にそれぞれを伝送するというふうに、である。このサイクルは、双方向データを、例えば、１０秒ごとに伝送するように繰り返される。このようにして放送する情報は、いわゆる「カルーセル」を生成する。カルーセルを構成する一連の情報は前もって準備してもよいし、または「通信中」に決めてもよい。

放送システム（例えば、双方向テレビシステム）は、カルーセル方式で情報を送信し、これによりシステム内の受信機は、受信機からサーバまでのリターンパスが無くてもカルーセル内の特定情報を選択的に取得できる。特定の受信機が特定の情報が必要な場合、その情報が次に放送されるまで単に待ってからその情報を取得する。その情報が周期的に放送されなかった場合、受信機はサーバにその情報を送信するように要求しなければならず、このためにリターンパスが必要となる。システム内の他の受信機も同様に動作し、各受信機の必要とする情報が放送されるのを待ってから、その情報のみを使用する。情報の放送にカルーセル方式を採用することにより、システムの各受信機をサーバと接続する必要が無くなり、さらにサーバは個々の情報の要求を処理しなくて済む。

必要な情報が周期的に放送されていない場合、受信機は、適切なモデムを備えていれば、いわゆるリターンパスを使用してサーバに情報の送信要求ができる。システム内の他の受信機は同様に動作可能であり、各受信機の必要とする情報が放送されるのを待ってから、その情報のみを使用する。

多くの場合、カルーセル内の情報またはデータオブジェクトは組み合わせて単一番組を形成することを前提とする。例えば、双方向視聴者参加テレビゲームは、音声、映像および、ユーザが質問に回答して互いと競わせるアプリケーションコードなどの双方向コンテンツを組み合わせている場合がある。アプリケーションコードは、例えば、視聴者参加型クイズ番組のデータとともにダウンロードするか、あるいは、例えば、データ処理用装置またはホームネットワーク内でアクセス可能な場所などローカルに置くことができる。別の拡張機能の例として、音声および映像を、最新株価を画面下部のバナーに挿入するアプリケーションコードと組み合わせているニュース番組がある。（種々の番組にも可能であり、なにか特別の番組に音声、映像およびアプリケーションコードのすべてが含まれる必要はない。）番組は、音声と双方向データのみ（例えば、双方向ラジオ番組）または双方向データのみを含む場合がある（例えば、音声または映像ストリームを含まない双方向天気予報番組）。

近年、パーソナルビデオレコーダ（ＰＶＲ）など種々の録音および再生装置の開発および商品化により、放送番組の視聴者は、番組を受信と同時にモニタしている際に、映像番組の「早送り」、「巻き戻し」、「再生」または「一時停止」ができる。これらのシステムは一般的に、ほぼ完全な品質を保持した視聴覚番組の格納および番組の再生を行うために、ハードディスクなどの記憶装置を用いる。

典型的なＰＶＲにおける制御装置は、例えば、断片的な記録番組のアドレスを記憶装置に保持することにより、これらを適切な順序で再度組み立てて再生できる。視聴覚表示はユーザとのやりとりにより制御される。制御装置は、視聴者から受信する命令に応答する。上記に記載のこれら種々の所望の機能を導入するための記憶装置の制御方法は、当技術分野においてよく知られている。

現行の双方向テレビシステムの問題は、視聴者がやりとりによって視聴覚表示を制御するため、視聴者が双方向アプリケーションの拡張機能を用いてやりとりすることを要求すれば、視聴者がよそ見をしていても視聴覚番組は継続する。このように視聴者は、例えば、双方向テレビアプリケーションとのやりとりを通じて、直ぐに番組の停止を具体的に命令し、その後に番組の鑑賞を再開したいと指示しない限り、視聴者はコマーシャルの全体あるいは一部を見逃してしまう場合がある。画面上のコマーシャルが再生し続けていても、視聴者は今では他のことに興味を示してしまっている。

したがって、視聴者が再生中の視聴覚番組の素材を逃すことなく双方向アプリケーションとのやりとりを可能にするシステムおよび方法が必要となる。

もう一つの問題は、現行のＰＶＲシステムは「トリック」モードを使用して拡張プログラミングを処理するようには設計されていないということである。ＰＶＲ技術の導入前、アプリケーションは常に放送と同時に実行され、一定で標準的な速さで進む番組の一部であると仮定して問題はなかった。したがって、多くの既存アプリケーションは、はっきりとまたは暗黙のうちにこれらの事実が真実であるという仮定を盛り込んでおり、当初の放送と異なる時間または速さ、例えば、トリック操作モードで再生した場合は正常に再生できない。トリック操作モードとは、基本的に標準順方向再生と異なる速さまたは方向でのすべての操作を指す。これには、再生位置を別の再生位置に設定することも含む。これらの条件は完全な二者択一の操作ではない。これらのパラメータを変更しても対処できるアプリケーションがあり、またできないものもある（例えば、双方向アプリケーションは早送りできても巻き戻しはできない、または双方向アプリケーションは後日再生できても一定速度で再生するという条件付である）かもしれない。

さらに、いくつかの双方向アプリケーションは、これらの変更が何時またどのように起きるかを制御できる場合、つまり、自ら一時停止、再生、巻き戻しおよび早送りキーの操作ができる場合に限って、これらの変更に対処できる。これは、整合性を保証するため、あるいは特定のビジネスモデル（例えば、コマーシャルを早送りできる権利を得るために追加料金を支払う）に対応させるためであり、ネットワークが動き制御する際の目的とは食い違う。しかし、このようなネットワークを用いてでも、ネットワークのトリックモード処理を任せられるアプリケーションはわずかである。

さらに番組は、番組全体を通してあらゆる状態にある異なる双方向アプリケーションを含むことがあるため、特別再生モードで番組の一部を飛ばして進んだとしても、これらのアプリケーションが適切な状態を維持していることが必要である。さらに、アプリケーションは他のデータオブジェクトとやりとりすることがあるため、特別再生モードでは発生しない信号を発生する必要がある。

アプリケーションが、すべての再生位置／速度の変更に関する適切な通知を受信さえすれば、特殊モードを適切に処理するアプリケーションを書くことができる。しかし、これにはアプリケーション開発者にかなりの負担がかかり、すべての開発者が進んで全特殊モードをサポートするわけではない。したがってシステムは、トリックモードを処理できないアプリケーションも扱えるように対応しなければならない。

また現行のＰＶＲシステムのさらに別の問題は、可変速度ストリームの記録では「トリック」モードの使用を適切に組み込むことができないことである。トリックモードの使用には通常、記録媒体上のデータ再生時間と位置との対応を示すメタデータが必要となる。例えば、利用者が番組中の３０秒先の位置へジャンプするトリックモードの使用を所望する場合、記録媒体中の行き先を示すメタデータが必要となる。

通常では、再生時間からストリームオフセット（またはファイル位置）までのマップを保持することにより記録媒体上のデータ再生時間と位置の対応を把握する。その結果、ファイル全体へのランダムアクセス能力は、時間およびオフセットのテーブルを維持することによって向上する。ここで、ストリーム中の時間ＴにアクセスするためにはファイルをオフセットＯから再生する必要がある。したがって、ファイルはストリーム用のＴ（ｉ）とＯ（ｉ）の組を順に並べたリストを有すると考えられる。通常、ストリームが意図した再生速度と同じ速度で送信される場合は、このように順に並べられたリストをセットトップボックス内に構築することは難しくない。Ｔ（ｉ）とＯ（ｉ）は１つの公式に従って対応するからである。しかし、ストリームが可変速度で「ドリップ」している場合には、この対応は一定でない。したがって、可変速度で記憶される番組では、記憶媒体上のデータの再生時間と位置との対応を割り出す必要がある。

本発明は上記およびその他の問題を解決するために、視聴覚番組を、番組を自動的に遅延またはタイムシフトさせて視聴者の要求するやりとりが可能となるように、標準的な期間だけ自由に変更できるような記憶装置に使用するシステムおよび方法を提供する。本発明は、視聴者が、コードおよびデータを含む双方向アプリケーションとのやりとりを始めると、音声、映像および／またはその他のコンテンツの再生を制御するシステムを提供する。視聴者がいったんやりとりを終了すると、番組は先の切れた所から開始する。

本発明は、コードおよびデータを含む双方向アプリケーションが、視聴覚番組と同じサービスの一部として受信局へ放送されようと、ローカル記憶装置から取り出されようと、または別途要求して放送サーバまたはオンライン情報提供者から取り出されようと関係ない。さらに、本発明は上記の組み合わせをも対象とし、これらにおいて双方向コンテンツは双方向コードとともにあるいは別々に受信局（ＰＶＲ等）のローカル記憶装置、外部記憶装置、ホームネットワークの機器、放送局、ＬＡＮ、プライベートネットワーク、インターネットまたはその他のオンライン情報提供者から取り出される。

本発明の方法において、セットトップボックスの中にまたはセットトップボックスに外付けしてもよいローカル記憶装置を用いて、または放送を受信して番組を再生する。受信局はコードおよびコンテンツデータを含む双方向アプリケーションの再生を始める。視聴者からの、双方向アプリケーションとのやりとりを要求するコマンドの受信をもって、番組の表示が自動的に停止する。放送番組の場合、番組記録開始コマンドを記憶装置に送信する。記録番組の場合、記憶装置は視聴覚番組と関連するデータ出力を中止する命令を受信する。さらに記憶装置は、後の呼び出しのために視聴覚番組が停止した記憶場所にポインタを保持する。視聴者の双方向番組とのやりとりが終了次第、受信局は視聴覚番組の再生を自動的に再開する。

したがって、本発明の他の一つの目的は、視聴者の双方向アプリケーションとのやりとりにより、受信局で受信されると同時に再生される放送番組の自動的なタイムシフトおよび、その後に視聴者とのやりとりが終了すると放送番組が再開することを提供することである。

本発明のさらに他の一つの目的は、視聴者の双方向アプリケーションとのやりとりにより、受信局の記憶装置から再生される事前記録番組の自動的なタイムシフトおよび、その後視聴者のやりとりが完了すると放送番組が再開することを提供することである。

本発明のさらなる一つの目的は、双方向アプリケーションが処理できる「トリック」モード再生オプションの種類を決定するためのシステムおよび方法を提供することである。システムは好適に、それ自体の再生オプションをいくつかの双方向アプリケーションに処理できるようにする。代わりにまたはさらに、システムは好適に、双方向アプリケーションとともに使用が承認されている再生オプションを判断し、ユーザにこれらの承認されたオプションへのアクセスを許可するように設定されている。

本発明のまたさらなる一つの目的は、双方向アプリケーションと関連するネットワークのＰＶＲ機能の処理方法に柔軟性を与えることである。

本発明のもう一つの目的は、可変速度でドリップする記憶コンテンツ再生時間とコンテンツの記憶媒体内での位置との対応を確認するために受信機の必要とする処理を簡素化する方法を提供することである。

上記のおよびその他の態様と利点は引き続き明らかになろうが、以下に詳述する説明および請求項の構造と動作の細部にあり、本願明細書の一部を構成する添付の図面を参照するが、本願明細書全体を通して同一の参照符号は同一部品を指す。

双方向テレビシステムの機能ブロック図を示す。 カルーセルと対応するデータストリームの構造を示す。 双方向アプリケーションを含む記録番組の一再生制御方法のフロー図を示す。 １つ以上の事象がある場合の本方法による実施形態のフロー図を示す。 記録システムによる、アプリケーションを含む記録コンテンツの要求の処理手法のフロー図を示す。 記録アプリケーションの再生開始方法のフロー図を示す。 データストリームとして番組を受信するように設定したシステム内のアプリケーション検知のフロー図を示す。 アプリケーションを含む番組再生の制御方法を示す図である。 アプリケーションの再生処理方法を示すフロー図である。 システムによるトリックモード要求シグナルの処理方法を示す図である。 可変速度でドリップするストリームの時間およびオフセット関係を決定するための第１のプロセスを示す。 可変速度でドリップするストリームの時間およびオフセット関係を決定するための第２のプロセスを示す。 可変速度でドリップするストリームの時間およびオフセット関係を決定するための第３のプロセスを示す。

パーソナルビデオレコーダ（ＰＶＲ）は、視聴者の命令によって選択したテレビ番組を記録できる。次に視聴者は記録した番組をいつ視聴するか決定できる。さらに、一般にＰＶＲは視聴者にいくつかの「トリック」モードを使用可能にする。このようなトリックモードの一つでは、生放送録画中に一時停止および巻き戻しができる。記録した部分は後に視聴するか、または飛ばしてリアルタイム放送に追いついてもよい。別のＰＶＲ使用方法として可能なのは、事前に記録した一つのテレビ番組を再生している間に別の番組を記録することである。一般にＰＶＲは、命令により再生できるよう、圧縮ビデオ信号をハードディスクドライブなどの記憶装置に記録することによってこれらの離れ技をこなす。

一般に、記憶装置は視聴者システムの一部である。これらを、視聴者の受信機／セットトップボックスに組み込むかまたは視聴者システムの別のコンポーネントの一部としてもよい。別の方法では、記憶装置を視聴者システムから離した配置にしてもよい。いわゆる「ネットワークＰＶＲ」は、記憶装置を離れた場所、例えば放送者のいる場所に配置して機能する。そしてユーザは、ネットワークを通じて放送者と通信することにより再生を制御できる。記録番組はネットワークまたは別の媒体を通じて視聴者に提供される。本明細書中に記載の多くの実施形態は、視聴者のいる場所に配置し、視聴者セットトップボックスに組み込んだＰＶＲを特定に参照する。これらの実施形態は、単なる例示でしかない。多くの原理は、テレビ番組の記録および再生の制御に使用するネットワークＰＶＲおよびその他の記憶装置にも同様に適用できる。

双方向テレビシステムは、双方向コンテンツとともに通常のテレビ番組を多くの受信契約者に配信するための媒体を提供する。これらのシステムによって放送される番組には、テレビ音声および映像、静止画像、テキスト、データ、ロケータ、メタデータ、双方向グラフィックスやアプリケーションおよびその他多くのコンポーネントが組み込まれている。したがって、双方向テレビ信号の双方向アプリケーションは、アプリケーションコード、音声および映像に関連するデータ、制御信号、生データ、インターネットアドレスおよびその他多くの情報を含むことができる。本明細書は、双方向プログラミングをＰＶＲシステムに組み込むシステムおよび方法を開示している。

図１に示す双方向テレビシステムの機能ブロック図を参照する。一般に双方向テレビシステムは、放送局１００、および放送媒体１０４により放送局１００と連結する受信局１０２を備える。この図において、放送媒体１０４として衛星放送ネットワークを表示している。その他の実施形態では放送媒体１０４として、ケーブル、電気通信、ＭＭＤＳ（マイクロ波）および地上波放送媒体を備える。放送局１００は、番組を形成するデータを提供する番組ソース１０２に連結する。番組ソース１０２は、データをケーブルヘッドエンドに放送するオペレーションセンタであってもよい。

受信局１０６は、好適に記録装置１０８に連結する受信機を含む。一般に受信局１０６は、テレビ１１０に接続するセットトップボックスに組み込まれている。別の方法として、受信局１０６をテレビに組み込んでもよい。受信局は、テレビを代用しているコンピュータ用モニタを有するＰＣであってもよい。また、テレビを用いて主番組を映し、ＰＣ（またはＰＤＡ、インターネット電話等）を用いてコードおよびデータを含む双方向アプリケーションを再生する、通称「ツーボックス（ｔｗｏ ｂｏｘ）」構成としてもよい。いずれにしても、本発明は当分野において知られているいずれの受信装置に限定することなくすべての受信装置を対象とし、これらを動作できる。

受信局１０６には、制御装置（例えば、マイクロプロセッサ）、記憶装置および受信した双方向テレビ信号を選択してデコードするために必要なその他のコンポーネントが組み込まれている。セットトップボックス等の受信局１０６の基本的な構成要素および特徴は知られているため、ここではそれらについては詳しく説明しない。記憶装置１０８は、当業者にその動作が知られている従来のパーソナルビデオレコーダ（ＰＶＲ）である。

一般的に、セットトップボックスは、必要な双方向機能を最小費用で提供するように設計されている。そのため、通常は記憶容量が限定され、大容量記憶装置（例えば、ハードディスクドライブ）を持たない。メモリは、双方向アプリケーションを実行するために十分であるが、アプリケーションを無期限に格納するには適していない。このため、通常、アプリケーションは、実行されなくなるとメモリに残らない。

セットトップボックスのメモリが、いくつかの双方向アプリケーションを格納できるだけ十分な大きさであったとしても、大量の音声または映像データ、アプリケーションコードまたはその他の情報を収容するには小さ過ぎる場合がある。本発明の一実施形態において、セットトップボックスの限られたメモリに入りきらない番組を記録するために十分な記憶容量を提供する記録装置１０８は、セットトップボックスに連結する。記録装置１０８は、ハードディスクドライブ、書き込み可能なＤＶＤドライブまたは光ディスクドライブなど、あらゆる適切な記憶装置を備えることができる。これは、セットトップボックス内にあっても、外付け接続にしてもよい。記録装置１０８は、セットトップボックスから取り外し可能でも不可能でもよい。

双方向テレビ番組と関連した、アプリケーションコードまたはコンテンツなどの双方向アプリケーションは、当業者に知られている多くの方法により受信局１０６で検索できる。双方向コンテンツおよび／またはコードは、先に受信局１０６の記憶装置内に常駐していてもよい。双方向コンテンツおよび／またはコードを、放送局１００に格納して、受信局１０６へ主要視聴覚番組とともにあるいはその一部として放送されてもよく、これについては下記の「カルーセリング」と関連してさらに詳しく説明する。別の方法で、双方向コンテンツを双方向コードとは異なる場所に格納でき、双方向コードが実行されると、いくつかの場所のうち、放送局１００、オンライン情報提供者１１２、ホームネットワークのサーバから双方向コンテンツを取り出せる。例えば、双方向コンテンツは、オンライン情報提供者１１２（例えば、インターネット、ウェブ、イントラネット、公衆ネットワーク、プライベートネットワーク等）と関連したサーバに格納でき、視聴覚番組の再生中に受信局から取り出せる。例えば、番組は、抽出して双方向コンテンツおよび／またはコードにアクセスするために受信局１０６が使用するトリガーを番組内に含むか伴う。このような実施形態の一つにおいて、トリガーはオンライン情報提供者ネットワークの１つ以上のサイトのアドレスまたは基準アドレスであってもよい。双方向番組を取り出すために、これらのトリガーを自動的にまたはユーザの命令によって受信局１０６のデータストリームから所定の時間にまたは受信して抽出すると、トリガーはオンライン情報提供者１１２サイトとの通信リンクを設定するために使用できる。

上述のように、双方向アプリケーションは繰り返し形式で放送することもできる。つまり、各情報は最初に放送され、次にそれらはそれぞれ送信される、という具合に続く。この周期は、各双方向データが例えば、１０秒ごとに送信されるように繰り返される。このようにして放送される情報の断片は、いわゆる「カルーセル」を形成する。カルーセルを形成する一連の情報は事前に準備してもよいし、または「通信中」に決定してもよい。

放送システム（例えば、双方向テレビシステム）は、カルーセル方式で情報を送信し、これによりシステム内の受信機は、受信機からサーバまでのリターンパスが無くてもカルーセル内の特定情報を選択的に取得できる。特定の受信機が特定の情報を必要とする場合、その情報が次に放送されるまで単に待ってからその情報を取得する。その情報が周期的に放送されなかった場合、受信機はサーバにその情報を送信するように要求しなければならず、このためにリターンパスが必要となる。システム内の他の受信機も同様に動作し、各受信機の必要とする情報が放送されるのを待ってから、その情報だけを使用する。情報の放送にカルーセル方式を採用することにより、システムの各受信機をサーバと接続する必要が無くなり、さらにサーバは個々の情報の要求を処理しなくて済む。

一実施形態において、放送局から受信局へ放送される番組のデータオブジェクトは、番組の格納に使用するものと同一ソースに記憶される。データオブジェクトは個別に格納しても（例えば、独立してアクセス可能なファイルとして）、あらかじめ構成されたデータストリームとして格納してもよい。番組のデータオブジェクトが独立したファイルとして格納されている場合、放送局はこれらが順次放送されるように番組ソースから取り出す。番組があらかじめ構成されたデータストリームとして格納されている場合、ストリームが実際に格納されている状態で放送できる。番組データは圧縮してもよく、データには双方向テレビシステムの使用する制御情報を付加することができる。次に放送局は、番組データおよびその他すべての追加情報を、放送媒体を通じて送信できるように適切なフォーマットに変換する。この特定の実施形態において、データは、デジタル衛星ネットワークを通じて送信できるパケットにフォーマットする。これらのパケットは、送信用にその他のパケットとともに多重化できる。

放送局はカルーセル内にある番組のデータオブジェクトを周期的に受信局に転送する。このようにして各データが繰り返し転送されるようなデータストリームができる。放送媒体（本実施形態においては、デジタル衛星ネットワーク）は、異なる多くのチャンネルをサポートでき、異なるカルーセル（および対応するデータストリーム）をこれらのチャンネルで同時に放送できる。受信局がデータストリームを受信すると、データストリームに収容されている番組を直ちに再生しても記録してもよい。番組をすぐに再生する場合、受信局はデータストリームを変換してデータオブジェクトに戻し、これらを番組に必要な形で使用する。番組を格納する場合、これらを個別データオブジェクトに分解して、一組のファイルとして格納するか、または受信した状態でのデータストリームとして格納する。番組を格納する場合、番組は記録装置に送信される。すぐに再生するしないにかかわらず、番組は格納できる。

図２に示す受信機に転送するカルーセルの構造（および対応するデータストリーム）を参照する。カルーセル２４は、データオブジェクト２１から２３およびカルーセル情報２０を備える。データオブジェクト２１から２３は、上記の番組と同一ソースから取り出す。カルーセル情報２０は放送局に提供され、その中には、例えば、カルーセルＩＤおよびバージョン番号、カルーセルの有効範囲、カルーセル用ファイルアクセステーブルまたはディレクトリおよびその他の種々の情報（この情報の一部、例えば、有効範囲のデータはすぐに消費される番組には必要でない）を含む。放送局はカルーセル情報２０およびデータオブジェクト２１から２３を順次転送する。カルーセル２４転送の第１の状態を２５で示す。放送局が第１のカルーセル２４転送を完了すると、２６に示すように再度転送する。２５から２９に示す一連のカルーセル２４の周期的な転送はデータストリーム３０を形成する。カルーセルの転送はいつまでも繰り返される。

上述のように、番組を構成するデータオブジェクトには、アプリケーションコード、音声および映像データ、制御信号、生データおよびその他の種類の情報を含むことができる。番組を即時消費する（すなわち、ユーザに提供する）場合、ストリームからデータオブジェクトを抽出するためにデータを解析する必要がある。必要なデータオブジェクトを抽出して番組を再生する。データオブジェクトは番組で規定する通りに使用する。例えば、実行しなければならないアプリケーションを起動すると、ユーザに提供しなければならないすべての音声および映像データが再生または表示され、生成しなければならないすべての信号を発生する。番組は、通常はテレビを介してユーザに提供され、消費される。番組がユーザへ即時に提供されるか否かにかかわらず、すぐに格納することもできる。記録装置は、番組を「ありのまま」（すなわち、放送信号で受信するものと実質的に同一のデータストリームとして）または、個別にアクセスまたは更新できる一組のファイルとして格納できる。いずれの場合も、記録番組を再生できる。本システムおよび方法を、記録番組を視聴する際にトリックモード等の再生機能の使用を容易および／または可能にするために採用する。本システムおよび方法の利点を説明するために番組の構造を調べることが有用であろう。

《番組から双方向アプリケーションへの切替え》
図３は、双方向アプリケーションを含む記録番組の一再生制御方法を説明するフロー図である。本方法は、「視聴覚」番組に関して説明する。しかし、本発明は、視聴覚コンテンツを含む番組に限定されず、数あるコンポーネントの中でも以下の、音声、映像、グラフィックス、データ、テキスト、メタデータ、双方向アプリケーション、ロケータ、いずれをも個別にまたは組み合わせて含むことができる。

再び図３の特に事前記録番組において、番組を記録装置に記録した後に、３００で再生を開始する。双方向アプリケーションが事前記録番組の一部として含まれている場合、３０２において受信機はアプリケーションを検知するように設定されている。番組内のアプリケーション検知方法は、番組の格納方法による。

アプリケーションがデータストリームとして記録されている場合、受信機は記憶装置から再生される一連のデータストリームを調べてアプリケーションを検知する。ストリームにアプリケーションが存在することを示す情報が含まれている場合、受信機はこの情報を検知し、結果としてアプリケーションを検知する。次に、３０４でアプリケーションを起動する。

番組が一組のファイルとして記録されている場合、番組内のアプリケーション検知方法は異なる。番組の再生を開始すると、受信機は格納されているファイルを調べる。一実施形態において、アプリケーションファイルには、対応するアプリケーションの有効性を規定した情報を含む。受信機は、各アプリケーションの有効性を現在の再生インデックスと比較する。現在の再生インデックスが特定アプリケーションの有効範囲内にあれば、そのアプリケーションが検知されたと考えられ、起動される。

別の方法では、双方向番組は、事前記録番組から完全に分離していてもよい。例えば、前述の一方法により双方向アプリケーションへアクセスして起動することを許すトリガーを事前記録番組から検知する。例えば、コードおよびデータを含むことができる双方向アプリケーションを、受信機のローカル記憶装置内、放送局またはオンライン情報提供者サイトに格納することができる。双方向アプリケーションが放送局に格納されている場合、例えば、リターンパスからサーバを介して要求を送信し、放送局のアプリケーションにアクセスしなければならず、続いて、双方向アプリケーションを検知して起動する場所である受信機へ放送する。また別の実施形態において、双方向アプリケーションが利用できることを示すアイコンまたは別の表示が視聴者に提示される。視聴者が命令すると、双方向アプリケーションをローカル（すなわち、受信局内の記憶装置）または外部記憶装置（放送局またはオンライン情報提供者を含む受信局から離れて配置された記憶装置）から取り出して、起動することができる。

さらに別の実施形態において、いくつかのアプリケーションが受信機または受信機に接続する消費者電子機器に常駐することがある。この場合、ことによるとユーザの介入さえも必要無く自動的に起動するアプリケーションは、ストリーム内のデータタイプで決定されることがある。このようなアプリケーションおよび関連データの典型的な例は、ウェブブラウザおよびいくつかのｘｍｌのデータであろう。

再び図３において、アプリケーションを番組内で検知または、内部または外部記憶装置から個別に取り出した場合、双方向アプリケーションは３０４で起動する。いったん起動すると、視聴者は、双方向アプリケーションの一部として提示されるオプションを選択することによって、プレゼンテーションとのやりとりを選択できる。例えば、視聴者は、映像番組のグラフィックスオーバーレイの一部として提示される質問に対する予想回答を選択できる。例えば、コマーシャルが表示されている時、ユーザに、そのコマーシャルで提示している商品の詳しい情報が必要かどうかを尋ねるグラフィックスオーバーレイを提示し、その質問に視聴者が肯定的な反応を示すことができる。別の場合、視聴者に対して改良コンテンツが入手可能であることを示すアイコンを画面上に提示できる。視聴者は、数ある方法の中でもリモコンまたはキーボードのキーを押下することによって、または、受信局内の音声認識コンポーネントに処理される音声命令を発することによって、ただしこれらに限定されない当技術分野で知られているいかなる手段を用いて応答してもよい。

３０６でシステムが視聴者命令をいったん検知すると、双方向アプリケーションに割り込み指示を送信できる。つまり、制御タスクまたは別のシステム固有のもしくは放送のプロセスが、双方向アプリケーションに向けられたキーイベントの通知を受信できる。例えば、いくつかのシステムで、受信機に複数のアプリケーションが存在する場合がある。これらのうちいくつかのアプリケーションはそれ自体で実行でき（受信機内の特定プロセッサ用の実行コードからなる）、その他はインタープリタまたは仮想マシンを利用して実行する。制御タスクとは、ネットワークオペレータまたは家庭用電化製品メーカが供給する特定タイプのアプリケーションである。いずれの場合も、制御タスクの主目的は、「ポリシー」を決定することである。制御タスクの下すことのできる決定の例には、（１）どの事象を他のどのアプリケーションへ送信するか、またどの事象を直接処理するか、（２）どのアプリケーションにチューナまたはモデムなどの特定周辺装置へのアクセスを許可するか、および（３）リソースが不足する場合に特定アプリケーションを停止するか否か、がある。これらは、ネットワークオペレータおよび／または家庭用電化製品メーカが制御タスクを介して設定を所望する処理のほんの数例でしかない。いずれにしても、制御タスクはそれ自体がまたはインタープリタもしくは仮想マシン内で実行できる。

図３において、視聴者のやりとりを検知した後に、視聴覚番組が生放送または記録番組であるかの判断を３０８で行う。視聴覚番組を受信しながら再生する場合に、放送番組が記憶装置にまだ記録されていないなら、３１０で視聴覚番組の記録を開始するように受信局から記憶装置に命令が送信される。放送番組の記録が継続している場合、視聴者がやりとりを始めた記憶装置内の映像および／または音声の読み出し位置がシステムによって保持される。

放送番組に関し図３において、３１２で受信機内のプロセッサから音声、映像および／またはデータデコーダへ番組の再生を停止するよう命令が送信され、結果として画面から映像を消しスピーカからの音声コンテンツの再生を止める。もちろん、記憶装置から事前記録番組の再生を停止すると、番組再生を停止した場合と同じ結果をもたらす。

双方向番組と関連する、グラフィックス、テキスト、静止画像、声および／または音声のすべてのコンテンツは、好適には画面またはスピーカで継続して再生される。双方向アプリケーションが映像または音声データを含む場合、このシステムは好適にコンテンツをなるべく中断することなく継続して再生することを確実にする手段を持つ。双方向再生を確実にする方法の一つに、視聴者にどのコンテンツを「一時停止」およびどのコンテンツを継続して再生するべきコンテンツかを示すメタデータの利用を通して行うものがある。メタデータは、システムの利用に供するコンテンツのセグメントと関連付けられる。このメタデータは、受信局で信号方式の情報の一部、コンテンツの一部またはアプリケーションの一部として受信することができる。別の方法で、受信局はあるイベントの状態および制御フローを示すイベント情報テーブルなどの表を取り出すことができる。

別の実施形態において、双方向アプリケーションを用いたユーザとのやりとりの途中で番組を一時停止する代わりに、番組は双方向アプリケーションとともに繰り返し再生される。例えば、双方向アプリケーションがコマーシャル番組中に現れると、アプリケーションを含むコマーシャルはアプリケーションとともに継続再生でき、コマーシャルが終了すると、番組は一時停止またはコマーシャルの先頭にループバックして、視聴者がアプリケーションとやりとりしている間に再度再生できる。

図３において、次のステップ３１６では、ユーザが双方向アプリケーションとのやりとりを止めた時を検知する。これは、双方向アプリケーションが出口ルーチンを呼び出すことによって、または視聴者からセッション終了をする意図を示す命令を受信することによって達成される。一般に、コンピュータプログラムは有限または無限（ネットワーク信号、キーの押下などが送信されるまで待機している場合）の長さで書くことができる。一般に有限なアプリケーションは、プログラマがルーチンから出る特定の呼出しまたは、アプリケーションの終了を知らせる単純な構文を含ませることで終了する。後者の場合、プログラムのコンパイルまたは解釈が実行されると、出口ルーチンを呼出すランタイムライブラリが埋め込まれている。一般的に、出口ルーチンは、オペレーティングシステムまたはミドルウェアが、アプリケーションの使用したリソースの返還を要求できるようにオペレーティングシステムに折り返す。本発明で、オペレーティングシステムまたはミドルウェアの出口ルーチンに伴うこの処理の一部は、映像および／または他の双方向アプリケーションを再開することもできる（図４参照）。視聴者が出口を制御する一例は、次の通りである。視聴者は、双方向アプリケーションのコマーシャルからある製品の追加情報を取得している場合がある。完了すると、双方向アプリケーションは画面上に質問または「終了」アイコンを提示でき、これを視聴者は例えば、リモコンのキーを押下してクリックできる。別の方法では、視聴者に一定期間やりとりできるようにする。視聴者がこの一定期間内にやりとりしない場合、システムはユーザがやりとりを止めたことを検知する。当技術分野において理解されているように、視聴者が双方向アプリケーションとのやりとりを止めた時期を判断する方法は多い。

再度図３を参照すると、３１６においてシステムが視聴者とのやりとりを停止したことをいったん検知すると、番組を取得するよう命令が記憶装置に送信される。好適に、記憶装置内の映像および／または音声の読出し位置はシステムによって維持されている。例えば、３１８で番組は停止した同じ点（すなわち、当初番組が「一時停止」した場所）から画面上への再生を再開できる。別の方法で、イベント情報テーブルまたは、例えば、視聴者に記録番組の部分を選択できるようにする視聴者のリモコン操作により、制御命令が自動的に示すあらゆる点から番組を再生できる。

図４に示す通り、本発明はさらに「入れ子形記録」にも適する。この場合、例えば、視聴者がテレビ番組を伴うアプリケーションとやりとりし、コマーシャルを視聴してコマーシャルの宣伝する製品の追加情報を要求する。情報を要求した後に、視聴者はコマーシャルまたは番組に戻ることができる。ここで、戻る位置はネットワークオペレータ、コンテンツ提供者、受信機の実行するソフトウェア提供者または顧客のデフォルト設定による。例えば、４００で、視聴者は双方向アプリケーションを含むことのできる視聴覚番組を視聴する場合がある。４０２で、視聴者は双方向アプリケーションの起動を選択できる。４０４で、例えば、双方向アプリケーションを含む新しい双方向番組Ｂが検知されると、番組は開始し、場合によっては番組Ａとピクチャインピクチャまたは隣り合った画面配置で視聴者に表示される。

この点で、番組Ａを伴う双方向アプリケーションを「一時停止」できる。例えば、４０６で、視聴者が双方向アプリケーションＢとやりとりすることを選択すると、システムは自動的に番組Ａを停止する場合がある。４０６でシステムが視聴者のやりとりを検知すると、受信局は自動的に番組Ａの再生を止め、事実上番組Ａを「一時停止」し、場合によっては４０８で番組Ａに関連するアプリケーションをも一時停止する。ここで、現在視聴者は視聴覚番組Ｂを視聴しており、これに含まれている別の双方向アプリケーションＣは次に４１０で起動する。そのとき４１２で、視聴者が双方向アプリケーションＣとのやりとりを要求する指示を出すと、４１４で、番組Ｂは自動的に再生を止め、事実上「一時停止」する。すると、４１６で、システムは番組（アプリケーション）Ｃを実行する。４１８で受信局が、視聴者の双方向アプリケーションＣとのやりとりが停止したと判断すると、先の４２０で一時停止した点から番組Ａまたは番組Ｂを再生、または番組Ａを伴う双方向アプリケーションを自動的に再開して視聴者に画面表示する。

《双方向アプリケーションの再生オプション》
番組に含まれているアプリケーションは、例えば、ＰＶＲまたはその他の記憶装置を用いて番組を記録した場合に問題を引き起こすことがある。これは、いくつかの番組は最初の放送にだけ作動するように設計されているからである。さらにシステムは、アプリケーションを含む記録番組の再生中に利用できる特別な「トリックモード」を処理するように設計されていない場合がある。

図５は、記録システムが、アプリケーションを含むコンテンツの記録を要求する際の処理方法を示すフロー図である。上述のように、いくつかの番組は放送された当初だけ作動するように設計されている。そのため、このようなアプリケーションは記録されない。したがって、アプリケーションのデータはそのアプリケーションの記録が許されているか否かのインジケータを含む場合がある。このようなインジケータが存在しない場合、アプリケーションの記録を要求しても、実行されない。このインジケータを上述のカルーセル情報２０またはストリーム内のその他のデータに含むことができる。例えば、番組がＭＰＥＧ規格トランスポートを用いて放送されている場合、ＰＭＴ内の記述子を用いて記録を許す信号を発信できる。

図５において、５００で、アプリケーションを含むコンテンツの記録要求を出す。次に５０２で、記録システムのソフトウェアが、アプリケーションの記録が許可されているか否かを判定するために確認を行う。アプリケーションの記録が許可されていない場合、５０４で、システムはアプリケーションを記録しない。あるいは、システムは前述にかかわらず、アプリケーションの記録を許可するべきかどうかを判定できる。しかし、システムはなお、アプリケーションを含まない番組コンテンツを記録する場合がある。アプリケーションの記録が許可されている場合、５０６で、システムはアプリケーションを記録する。

図６は上述の双方向テレビシステムが、記録アプリケーションの再生を開始するために採用する一手法を示すフロー図である。番組を記録装置に記録した後に、６００で番組の再生を開始する。受信機は、６０２で記録データ内のアプリケーションを検知するように設定されている。番組内のアプリケーションを検知すると、６０４でアプリケーションを起動する。番組内でのアプリケーション検知方法は、番組の格納方法による。

図７は、データストリーム形式の番組を受信するように設定されているシステム内のアプリケーション検知方法を示すフロー図である。アプリケーションがデータストリーム形式で記録されている場合、受信機は７０２で記録装置から再生される一連のデータストリームを調べてアプリケーションを検知する。アプリケーションが使用可能であることを示す情報がストリームに含まれている場合、受信機はこの情報を検知し、７０４でアプリケーションを検知する。アプリケーションが使用可能なら、７０６で起動する。

データストリーム形式であろうと一組のファイル形式であろうと、番組が格納されている場合、番組が再生されている間はアプリケーションの検知が継続して行われる。したがって、新しいアプリケーションを検知すると、それらを起動する。受信機の能力と受信機の動作環境に実装されているポリシーは、別のアプリケーションの起動による現在実行中のアプリケーションへの影響を左右する。上述のように、好適に、新しいアプリケーションを起動すると、番組および／または他のアプリケーションは一時停止する。第２のアプリケーション実行中に、第１のアプリケーションを記憶装置からアンロードする必要がある場合も、無い場合もある。受信機が１つ以上のアプリケーションを同時に実行できるなら、第１のアプリケーション実行中に第２のアプリケーションを実行できる。しかし、受信機は１つ以上のアプリケーションを同時に実行することを禁止するポリシーを採用できる。このため受信機は、第１と第２のアプリケーションの両方を実行できても、第２のアプリケーションを起動する際に第１のアプリケーションを強制終了または、中断する場合がある。

上述のように、ユーザは番組を再生する際に番組をただ順序通りに再生する（すなわち、通常の再生モード）よりも、特別再生モードを使用したいと思うことがある。特別再生モードには、早送り、スローモーションおよび巻戻し、さらにジャンプ、シークおよび一時停止機能を含むトリックモードが含まれる。特別再生モードを使用した場合、番組は第１の状態（例えば、特定グラフィックスを表示中）にあるアプリケーションの第１の点からアプリケーションが第２の状態（例えば、別のグラフィックを表示中）にあると考えられる第２の点へと移動する。番組の第１と第２の点との間の部分が再生（実行）されないために、通常アプリケーションの状態を修正する特定信号およびイベントに出会わない。このため、特別再生モードを利用したアプリケーションの動作の結果が、特別再生モードを停止した後の番組内での位置と対応することを確実にしなければならない。多くの場合アプリケーションの作成者は、アプリケーションをいくつかのまたはすべてのトリックモードに対応するように作成するが、他のトリックモードは信号がないと好ましくない動作を起こすことがある。

図８は、アプリケーションを含む番組の再生制御方法を示す。双方向アプリケーションと関連するテレビ番組は、視聴者の都合に合わせて再生するために記録装置８００に格納される。システムソフトウェア８０２は、通常この種の装置に関連するすべての機能、例えば、周辺機器およびサブシステム用制御ドライバを装備し、これとともにオペレーティングシステムも装備する。図８は３つのサブコンポーネントを示し、具体的には、コンテンツの再生を制御する再生ドライバ８０４、アプリケーション８０６の性能情報を保持するレジストリ８０８およびシステムのポリシー決定を行う管理コンポーネント８１０である。管理コンポーネント８１０は、アプリケーションとして、システムへのサードパーティ拡張機能としてまたはシステム自体への組み込みを含むいくつかの方法で装備できる。アプリケーション８０６はシステムソフトウェア８０２と連結し、その機能と権限を登録する。

登録した機能には、その時点で処理できるトリックモードの種類を含む。これは、アプリケーションの記述に情報を格納する静的機構として実現できる。（上述のカルーセル情報２０またはストリーム内のその他のデータの中に情報が格納される。例えば、ＭＰＥＧ規格トランスポートを用いて番組を放送している場合、ＰＭＴ内の記述子を用いて記録許可信号を送ることができる。）。この場合、システムは機能を読込んで適宜登録する。アプリケーションはいまの機能を変更するために、別の方法で（または静的機構に加えて）、システムが備えるインターフェイスを使用してアプリケーションを実行しながら処理できるトリックモードを変更する動的処理でもよい。このため、巻戻しを全くしないで、番組の特定部分を通じて早送りのみ処理するかもしれない。このような動作の動的な変更は、システム内で使用可能なすべての再生モードに適用できる。

システムに登録された権限には、視聴者からのトリックモード実行要求処理権を含む。一般に視聴者は、リモコン（他の機器でも構わない）の「早送り」キーの押下により早送りを指示する。視聴者のキー押下による発生信号は２通りの方法、システムが適宜トリックモードを呼び出すか、またはアプリケーションへ伝達されてアプリケーションに処理が任される（記録番組の早送りでない場合がある）。前者は動作に一貫性をもたらすが、後者はアプリケーションによってシステムの動作性能を向上できる。多くの放送者は一貫性に強い関心を示し、トリックモードの要求するアプリケーション処理を制御したがるため、これらの信号の発生はアプリケーションに与えられた動作能力となる。

この権限のシステムへの登録は、いくつかの方法で実行できる。これは上述のカルーセル情報２０に記述できる。署名済みアプリケーションディレクトリでのアプリケーション許可に関する詳細な説明は、米国特許第５，６２５，６９３号明細書「双方向テレビシステムにおける転送アプリケーションを認証する装置および方法」（その全体が教示する内容を援用する。）を参照されたい。別の方法で、アプリケーションはアプリケーションの利用を許可する資格を登録できる。資格を利用した権限の設定に関する詳細な説明は、米国特許第６，１４８，０８１号明細書「双方向テレビアプリケーション用セキュリティモデル」（その全体が教示する内容を援用する。）を参照されたい。さらに別の方法で、権限はＳＴＢのメモリに常駐できる。これらは、例えば、通常ＨＢＯまたは有料映画などの有料サービスへのアクセス制御に使用する限定受信方式で配信できる。さらに、アプリケーションがこれらの信号処理権を有していても、これらの処理を所望しない場合があるので、追加ステップを用いて、許可アプリケーションがシステムにトリックモード要求信号をアプリケーション宛に送信するよう求め、その後システムがそれらの信号処理を再開するように要求できる。

図８には、システムソフトウェア８０２と連結し、さらにアプリケーション８０６と通信する再生ドライバ８０４を示す。ドライバ８０４は、一定間隔でまたは状況の変化により、またその他の選択した時点でアプリケーション８０６に現状を示すメッセージを送る。具体的なメッセージは、例えば、「普通再生」、「早送り」、「１０倍で早送り」、「停止」等である。

管理コンポーネント８１０はさらにそれ自体の基準で、アプリケーション８０６の機能を無効にできる。例えば、アプリケーション８０６は早送り可能と登録していても管理コンポーネント８１０は何らかの理由で再生ドライバ８０４にその機能を無効にするよう登録できるように、いくつかの機能を異なる時点で無効にできる。

図９は、アプリケーションの再生方法を示すフロー図である。まず、９００で再生を開始すると９０２でアプリケーションが起動する。再生開始後、９０４でアプリケーションの初期機能一式が登録される。次にアプリケーションの実行を開始する。９０６での連続実行中に、アプリケーションはいくつかの方法（割込み、ポーリング、共用記憶域等）で再生ドライバからその状態に関するメッセージを受信する。これに対するアプリケーションの動作は作成者の所望する作用によって変わる。例えば、いくつかのアプリケーションは、早送り操作中にすべてのグラフィックオーバーレイの除去を選択して、標準再生が再開して新しいデータをストリームから取得した後にはオーバーレイ要素を再表示しない場合がある。別の方法で、トリック実行中にほとんどの「標準」アプリケーションが使用できない状態での独占的な使用を目的とした別の種類のアプリケーションを設計できる。例えば、早送りブックマークアプリケーションにおいて、ユーザが早送りでテレビ番組を視聴し、早送り映像コンテンツが「面白い」場合に選択を押す。再生速度、再生インデックスの位置等に関する情報を使用して、再生ドライバからアプリケーションに送信され、印付きの場面から次の印付き場面へ迅速に動くための、他のメタデータと関連したブックマークリストを構築できる。例えば、高速でフットボールの試合全体を試写し、すべてのロングパスプレーに最も近い位置に印を付けることができる。アプリケーションは、プレーの開始と終了の正確な時間のメタデータと組み合わせてロングパスプレーのリストを作成できる。

ある状態を維持するためには生データを受信する必要があるアプリケーションも存在することに注意されたい。特別再生モードを使用してアプリケーションを番組再生中の特定の位置に移動させた場合、番組を普通再生モードに戻した後にアプリケーションが適切な状態にあることを確認するよう注意されたい。これらの対応は、記録および再生を前提として作成されたアプリケーションの場合、および、記録および再生を前提としないで作成されたアプリケーションの場合の２つの異なるケースにあてはまる。

第１のケースの場合、アプリケーションは特別再生モードを使用して記録および再生する可能性があることを知って製造されている。このようなアプリケーションは、これらの特別再生モードからの通知を受け取り、収容するように設計されている。例えば、アプリケーションは番組再生における現在位置を判断するために質問を生成するように構成される。次にアプリケーションは、番組内での位置に応じてその内部状態を設定できる。第２のケースの場合、アプリケーションを受信と同時に消費することを前提として製造されている。番組が普通再生モードで進む場合を除き、このアプリケーションは番組内のある位置から他の位置へジャンプするようには設計されていない。いずれの場合も当時のアプリケーションには処理できないトリックモードが要求される可能性がある。

図１０は、第１のケースでの処理を示す図である。まず、視聴者は１０００でトリックモードを要求する。次に１００２で、トリックモードの要求があれば、システムはアプリケーションにトリックモード要求信号（キー押下）処理権を有するかを判断する。権限があれば、１００４で信号をアプリケーションに送信し、その状況の処理はアプリケーションに任せられる。システムがトリックモード信号を処理できるなら、１００６で、アプリケーションが要求の特定トリックモード信号をその時点で処理できるかを判断する。できるなら、１００８で要求は普通に処理される。アプリケーションはトリックモードをその時点では処理できないと登録されている場合、１０１０で管理コンポーネントはこの決定を受け、適切な対応をとる。管理コンポーネントの選択肢１０１２には、アプリケーションを強制終了してトリックモードを可能にする、トリックモード要求を無視してアプリケーションを実行する、およびトリックモードを実行するがアプリケーションの実行も継続する、を含む（がこれらに限定されない）。管理コンポーネントはアプリケーションを強制終了すれば、トリックモードをいったん起動してアプリケーションを再開する選択肢がさらに与えられる。

アプリケーションが終了すると、情報（例えば、状態情報）を記録装置などの固定記憶装置に保存できる。アプリケーションを終了してメモリから取り出したなら、番組が新しい位置にジャンプした後に、再度データストリームからダウンロードして再開しなければならない。

《可変速度ストリームの記録》
番組ストリームは、利用可能バンド幅によって決まる速度で転送できる。これは放送した状態で番組を視聴する場合は、システムを一定のフレーム速度で再生できるために問題とならない。しかし、ストリームを再生前にＰＶＲまたはその他の記憶装置に記録した場合、再生時にストリームの可変速度による問題が生じることがある。具体的に、ユーザはＰＶＲで再生すれば放送を一定に前進スキップまたは後退スキップ、または早送りまたはその逆でのストリーム再生を可能にするトリックモードを利用できる。可変速度コンテンツにトリックモードを使用するには、一般に記録媒体上データの再生時間と位置との対応を示すメタデータが必要となる。

図１１から図１３を参照して下記に説明するように、このメタデータは、種々の方法で生成できる。

図１１は、可変ドリップストリームでの時間とオフセット関係を判断する第１の処理を示す。図１１に示すシステムは、送信機１１００および受信装置機１１０２を含む。図１１に示す例では、３つのデータストリーム（Ａ，Ｂ，Ｃ）が放送ネットワークを通じてＰＶＲのポピュレーションへドリップしている。ＴとＯを含むテーブルは各映像番組とともに受信機へドリップする。図１１には映像がゆっくりと流れる前にテーブル１１０４全体が送信されるケースを示す。しかし、テーブル１１０４も同様にゆっくりドリップできることを理解されたい。さらに、簡単化のために、図１１は３つのストリームすべてに１つのテーブル１１０４を示すが、テーブル１１０４は各ストリーム用にいくつかのＴとＯの対を有することができ、また複数のテーブルを送信できる。解析エンジン１１０６がこの表を作成し、サーバ側にある標準再生時間と、個別ストリーム（映像、音声等）またはドリップされる混合トランスポート／番組ストリームでの深さ（例えば、バイト単位で）との対応を示すインデックスを計算する。テーブルには時間およびオフセット計算結果に加え、番組コンテンツに関するその他の情報を含むことができる。例えば、テーブルはコンテンツの視聴制限レートを含むことができる。これによりシステムは、視聴者が視聴権を持たないデータの記録および／または再生を阻止することができる。一般的にストリームは、後の利用のために記録するという明確な目的を持ってドリップされるため、放送者はどのストリームの情報を計算するかが分かることに気づかれたい。この対応（例えば、テーブル）は、トランスポート／番組ストリームとともにメタデータとして放送される。また、テーブルは戻りチャネルを介して個別に送信できる。好適に、１１０８で３つのデータストリームを多重化して、テーブルの情報を最初にまたは最後に、「ドリップ」してテーブルを放送する。

受信機側のセットトップボックスは、ドリップした音声／映像／デジタル／磁気ディスクデータ（ストリームデータ）１１１０を受信し、デマルチプレックス１１１２し、記憶装置１１１４に記録する。このとき、各ストリーム、または混合トランスポート／番組ストリームでのそれぞれの深さおよび記録媒体での位置が保持される。放送時間と深さとの対応１１１６も記録媒体に記録する。記録した混合トランスポート／番組ストリームは、当初放送したものと同一でなくてもよいことに注意されたい。また、データを記録媒体に連続して格納する必要はなく、例えば、（ページ化、セグメント化した）仮想記憶テーブルに類似したものを使用できることに注意されたい。トリックモード、例えば、早送り、巻き戻し等が要求されると、ジャンプ先の標準再生時間が決定される。この後に深さを調べ、この深さを使用して位置決定してコンテンツを取出す。別の実施形態において、受信機は、２方向通信リンクを介してオンラインサーバからテーブルの情報を引き出すことができる（図示せず）。テーブルは上記以外の形式でも構わないことに気づかれたい。例えば、ハッシュ構造と同様にその他のデータ構造を利用できる。

図１２は、可変ドリップストリームでの時間とオフセット関係を判断する第２の処理を示す。構造は図１１に示す実施形態のものと同じである。しかし本実施形態では、解析エンジン１１０６はタイムスタンプエンジンの再生１２００で置き換えられている。この構成要素は、映像番組１２０２とともに多重化されてドリップするタイムスタンプパケットを生成し、１２０４で、パケット内データを受信機側でのＴとＯの対を生成するために使用する。放送ストリームの映像番組が双方向アプリケーションを含む場合、双方向アプリケーションにもタイムスタンプが付加される。

図１２に示す実施形態は、番組データ（個別ストリームまたは混合トランスポート／番組ストリーム）内で混合する放送と、混合するデータの標準再生時間を示すタイムスタンプ情報を含む。本手法を実施するための２つの代替手法は、ａ）個別ストリームのいずれかがそのパケットに番組参照クロック（ＰＣＲ）情報を含むことを確実にする、または、ｂ）標準再生時間を保持するために指定番組に追加ストリーム（ＭＰＥＧトランスポートを使用するときは別のパケットＩＤ（ＰＩＤ）である）を含ませることである。後者の場合、標準再生時間と別のストリームデータへのオフセットとの対応を示す高品質マッピングを確実にする頻度でそのストリームを他のストリームに多重化するが、情報収拾のオーバヘッドが問題となるほどの頻度では行わない。例えば、ＭＰＥＧベースのストリームでは、タイムベースを含むパケットが混合体で頻繁に発生することを確実にすることが必要である。

セットトップボックスにおいて、ドリップした音声／映像／デジタル／磁気ディスクデータを受信および記録した際にタイムベース情報を含むコンテンツを検知すると、必ずその保管とともに標準再生時間およびオフセットデータのマッピングにエントリが追加される。ＭＰＥＧトランスポートに個別ストリームを使用する場合、通常はタイムベースストリームのＰＩＤをフィルタしてデータ収集を補助するハードウェアがある。

トリックモードが要求されると、システムは標準再生時間内でのジャンプ先の位置を決定する。この後に、深さを調べ、その深さを使用して位置決定してコンテンツを取り出す。

図１３は、可変ドリップストリームでの時間とオフセット関係を判断する第３の処理を示す。本実施形態の構造は図１１および図１２の実施形態に類似する。本実施形態において、エンコーダで実行するアルゴリズムも直接または同等に受信機で実行できる。第３の実施形態では、ＰＶＲがドリップした番組を格納し、引き続きテーブルを構築するための解析処理を行う。この機能を実施するための一手法は以下の通りである。ドリップした番組を記録する。セットトップボックス（注意：通常通り、セットトップボックスのコンポーネントおよび機能はテレビまたは他の消費者電子機器（ＣＥ）に組み込むことができる）が使用中でなければ、テーブル１３００を構築するために標準再生時間と記録媒体での位置との対応を計算できるよう、音声／映像を標準速度（ただし、テレビには表示しない）で「再生」できる。その後、この対応はトリックモードに使用できる。受信機側でのテーブル作成のための他の方法も使用できる。

本発明の別実施形態において、記録中に視聴者がわずかの間チャンネルを変えたため、または放送エラーのためにストリームを記録しそこなった場合、例えば、記録できなかった部分は戻りチャンネルを通じて後に要求、または予定されている再放送から、テレビを消した状態で取得できる。

さらに別の実施形態において、受信機は、画面に映像を表示することなく標準速度で（「空き時間」に）映像を再生できる。このようにして対応を、例えば、映像に特定時間刻みの印を付ける専用ハードウェアを用いて計算する。これにより、トリックモードが使用できるまで映像（の少なくとも一部）を再生しなければならないという欠点を克服できる。

本発明の多くの特徴および利点は詳細な説明から明らかであり、また、添付の請求項は、本発明の真の精神と範囲に含まれる本発明のすべての特徴および利点に及ぶことを意図する。さらに、当業者は容易に多くの改良および変更を思いつくであろうから、本発明を例示および説明した通りの構造および動作に限定することを望まない。したがって、すべての適切な改良および同等物は、本発明の範囲に含まれることを告げる。

本発明は、発明を実施するための最良の形態を添付の図面とともに参照することによってより良い理解が得られるであろう。

２０ カルーセル情報
２１〜２３ データオブジェクト
２４〜２９ カルーセル
３０ データストリーム
１００ 放送局
１０２ 番組ソース
１０４ 放送媒体
１０６ 受信局
１０８ 記録装置
１１０ テレビ
１１２ オンライン情報提供者
８００ 記録装置
８０２ システムソフトウェア
８０４ 再生ドライバ
８０６ アプリケーション
８０８ レジストリ
８１０ 管理コンポーネント
１１０４ テーブル
１１０６ 解析エンジン
１１１４ 記憶装置
１１１６ 放送時間と深さとの対応
１１００ 転送装置
１２００ タイムスタンプエンジンの再生

Claims (19)

1. アプリケーションを含んだ番組の記録方法であって、
   前記番組を記録するためのリクエストを受信することと、
   前記リクエストに応じて、
   前記アプリケーションの記録が許可されているか否かを示すインジケータが前記アプリケーションと関連付けられたデータに含まれているか否かを判断し、
   前記アプリケーションと関連付けられた前記データが前記インジケータを含み、かつ、前記アプリケーションの記録が許可されていることを前記インジケータが示すと判断したことに応じて、前記アプリケーションとともに前記番組を記録し、
   前記アプリケーションと関連付けられた前記データが前記インジケータを含まないと判断したことに応じて、前記アプリケーションなしで前記番組を記録し、
   前記アプリケーションと関連付けられた前記データが前記インジケータを含み、前記インジケータが前記アプリケーションの記録が許可されていないことを示すと判断したことに応じて、前記アプリケーションなしで前記番組を記録することと、
   を含む方法。
2. 前記アプリケーションと関連付けられた前記データに含まれている、前記アプリケーションが記録不可能であることを示す前記インジケータの受信に基づいて、とるべき対応を判断することをさらに含む請求項１に記載の方法。
3. 前記アプリケーションが放送局から転送されたカルーセル情報の一部として記録可能か否かに関する指示を受信することをさらに含む請求項１に記載の方法。
4. 前記アプリケーションは対話型アプリケーションを含む請求項１に記載の方法。
5. １つ以上のトリックプレイモード中に、前記番組の通常の再生モード中に予想される信号または事象が発生していないにもかかわらず、前記アプリケーションの動作が継続するように前記番組の前記１つ以上のトリックプレイモード中に前記アプリケーションを動作させることをさらに含む請求項１に記載の方法。
6. 新規のアプリケーションとして前記アプリケーションを開始する前に先に実行しているアプリケーションを一時停止させることをさらに含む請求項１に記載の方法。
7. 前記アプリケーションの実行中は別のアプリケーションの実行を禁止することをさらに含む請求項１に記載の方法。
8. 前記番組を再生することと、
   前記アプリケーションの状態を示すメッセージを再生ドライバから前記アプリケーションで受信すること
   をさらに含む請求項１に記載の方法。
9. 前記アプリケーションで、前記アプリケーションの状態に依存する対応をとることをさらに含む請求項８に記載の方法。
10. 割込み、ポーリング、または共有メモリの１つ以上を介して前記メッセージを受信することを含む請求項８に記載の方法。
11. 前記番組再生することと、
    前記番組内の位置に従って、前記アプリケーションと関連付けられた状態情報を設定すること
    をさらに含む請求項１に記載の方法。
12. 前記アプリケーションのトリックプレイモード機能を前記アプリケーションで登録することをさらに含む請求項１に記載の方法。
13. 前記アプリケーションを開始することと、
    前記アプリケーションを終了させる指示を受信することと、
    前記アプリケーションを終了させる前に前記アプリケーションと関連付けられた状態情報を、前記アプリケーションで保管すること
    をさらに含む請求項１に記載の方法。
14. アプリケーションを含む番組を記録するシステムであって、
    記憶装置と、
    制御ユニットであって、
    前記番組を記録するためのリクエストを受信することと、
    前記リクエストに応じて、
    前記アプリケーションの記録が許可されているか否かを示すインジケータが前記アプリケーションと関連付けられたデータに含まれているか否かを判断し、
    前記アプリケーションと関連付けられた前記データが前記インジケータを含み、かつ、前記アプリケーションの記録が許可されていることを前記インジケータが示すと判断したことに応じて、前記アプリケーションとともに前記番組を記録し、
    前記アプリケーションと関連付けられた前記データが前記インジケータを含まないと判断したことに応じて、前記アプリケーションなしで前記番組を記録し、
    前記アプリケーションと関連付けられた前記データが前記インジケータを含み、前記インジケータが前記アプリケーションの記録が許可されていないことを示すと判断したことに応じて、前記アプリケーションなしで前記番組を記録することと、
    を行う制御ユニットと、
    を備えるシステム。
15. 前記記憶装置はパーソナルコンピュータ、パーソナルビデオレコーダ、テレビ、またはセットアップボックスの一部を形成する請求項１４に記載のシステム。
16. 前記記憶装置は、前期番組を受信した際の前記番組のフォーマットと略同一のフォーマットで、または個別にアクセス可能なファイル一式を含んだフォーマットで記録された番組として前記番組を格納する請求項１４に記載のシステム。
17. 前記番組と前記アプリケーションを再生可能な再生ドライバレイヤと、
    前記アプリケーションに使用可能な複数のトリックプレイモードの表示を提供するレジストリレイヤと、
    をさらに含む請求項１４に記載のシステム。
18. 前記番組と関連付けられた再生指標を前記アプリケーションと関連付けられた有効範囲と比較し、前記再生指標が前記有効範囲内にあるときに前記アプリケーションを開始する受信機をさらに含む請求項１４に記載のシステム。
19. 前記アプリケーションが対話型アプリケーションを含む請求項１４に記載のシステム。

Images