JP5789854B2 - メディア処理方法及びアレンジメント - Google Patents

Description

関連出願データ

米国において、本出願は仮出願61/167,828（2009年4月8日出願）、61/160,660（2009年3月16日出願）、61/152,226（2009年2月12日出願）に対する優先権を主張しており、これらの仮出願は、参照することにより本願に含まれる。

本技術は、携帯電話やその他の携帯デバイスに関し、より正確にはこれらのデバイスが（電子的、物理的な）メディアコンテンツや他のシステム（例えばテレビ、デジタルビデオレコーダー、電子プログラムガイド）と連動した使用に関する。

（はじめに）
本技術は、今回の出願人が過去の特許出願の中で開示した技術に基づいており、そこからさらに拡張したものである。従って、読者には下記出願（参照することにより本願に含まれる）が示される。下記出願は、出願人が本技術を適用しようとするアレンジメントを詳述するのに役立ち、本願の開示内容を技術的に補完するものである。

出願番号12/271,772（2008年11月14日出願）「コンテンツのインタラクション方法と携帯用デバイスを採用したシステム」
出願番号61/150,235（2009年2月5日出願）「別画面とウィジェット」
出願番号61/157,153（2009年3月3日出願）「一般公開からのナローキャスティング及び関連の方法」
出願番号12/484,115（2009年6月12日出願）「コンテンツ処理の方法とシステム」

これらの過去の特許出願では、携帯電話がユーザー環境を見聞きする方法と、その環境からコンテンツ（メディアオブジェクトや物理オブジェクトなど）を識別する方法についての詳細が示されている。これによって、ユーザーエクスペリエンスの補完が行えるように携帯電話を利用することができる。

本願の開示では、多種多様なさらなる改善と新しい革新を記載する。例えば、下記で詳述する技術の一面においては、携帯電話はユーザー環境を見聞きする必要がない。多くの場合、推測できれば十分である。携帯電話や他のデバイスは、さまざまな要素（日時、ユーザーの場所、テレビの位置、ユーザーの視聴履歴、他のプロファイルデータ、EPGデータなど。）に基づいて、ユーザーが何らかの状況に置かれていれば、その状況をうまく推測することができるのである。（ピッツバーグ・スティーラーズの熱狂的なファンならおそらく、スティーラーズの試合中はテレビの前にいるはずである。）

最初の推測を行うと、その仮説を確定もしくは反証するために、任意で追加情報を探すことができる。例えば、音声や映像を抽出する。これらは、他の情報がなければ映像番組を特定するには不十分であるが、最初の推測を強化（または反証）するには十分である。一方、携帯電話は単に、ユーザーに対して確認のための質問を1つ以上投げかけることができる。例えば「今テレビを見ているのですか？」「スティーラーズの試合をテレビで見ているのですか？」「番組Xと番組Yのどちらを見ているのですか？（またはどちらも見ていないのですか？）」のように。

他のアレンジメントでは、視聴活動の事実が最初に推測される。例えば、（GPSなどによって）テレビシステムと携帯電話の位置が両方特定でき、携帯電話がテレビから10フィート以内のところにあるのが分かった場合、その距離の近さのみで、ユーザーがテレビを見ているのだと推測できる。携帯電話が肯定的な推測を行うと、次に、（現在のEPGデータ、ユーザー履歴、プロファイルなどを参照して、ホームネットワークのディスクドライブにアクセスすることで、または、以前の携帯電話メモリにキャッシュすることで）どんな番組が放送されているかの推測を行うことができる。テレビシステムが対象までの距離を決定すると、テレビの電源は入っているのか、どんな番組が放送されているかがわかるようになる。次にユーザーに示すべき補助コンテンツを見つけられるように、テレビはこのような情報を携帯電話に送信することができる。

このおおよその状況をもとに、携帯電話はユーザーに対して補完的なエクスペリエンスを再び提供することができる。

意図された映像の表示を乱すことなく、利用可能な補助コンテンツを表示する方法の一つが、メインの映像番組を一時停止することである。（一時停止は、ユーザー主導で行うか、補助コンテンツが識別されたとき、あるいは利用可能になったときにシステムが行う。）携帯電話あるいはメイン画面上に、グラフィック制御が表示される。ユーザーは、ここから見たい補助コンテンツを選択する。このグラフィック制御には、利用可能な補助コンテンツを示すアイコンなどがある。一時停止中の画面上のコンテンツに合わせて、選択肢が変化する。（例えば、一時停止中の画面にジョン・ウェインが映っていれば、利用可能なコンテンツとしてジョン・ウェインの経歴や彼が出演している他の映像が表示される。一瞬後に画面にロナルド・レーガンが映ると、今度はロナルド・レーガンの経歴や彼が出演している他の映像が利用可能なコンテンツとして表示されるのである。）

希望する場合には、携帯電話のモーションセンサーが特定の動きを示したとき（あるいはどんな動きを示したときにも）映像のメイン表示を一時停止するように携帯電話をプログラムすることもできる。例えば、携帯電話が待ち受け状態から使用状態（着信したときに応答するなど）に移行したことを感知すると、テレビの表示は自動的に一時停止する。補助コンテンツが（携帯電話や他の場所に）表示された場合も同様に、テレビの表示は自動的に一時停止する。

アレンジメントによっては、ユーザーのテレビシステムと関連づけるように、ユーザーの携帯電話を登録している。例えば、TiVoデジタルビデオレコーダーでは、データ構造が、関連づけられた携帯電話の識別子（電話番号など）を保存できる。映像番組（テキスト通知、補助コンテンツ、映像コンテンツ自体など）に関連する情報を、テレビシステムから関連づけられた携帯電話に送ることができる。

この登録された携帯電話には、補助コンテンツを表示できるモードがある――例えばWatchingTVモードである。（この状態は、AppleのBonjourプロトコルなどによって関連づけられたテレビシステムに対して、携帯電話が示すものである）ユーザーの携帯電話がWatchingTVモードになっている場合、過去の視聴履歴、録画履歴、お気に入りデータなどに基づいて、ユーザーは番組を視聴しているところだと推測できる。この推測に基づいて、補助コンテンツを携帯電話に提供することができる。

他のアレンジメントにおいては、WatchingTVモードは必要ない。利用可能な番組やユーザーデータをもとに、情報を携帯電話に送ることができる。ユーザーはその情報を画面に表示するかを選択できる。

ユーザーが家から離れた場所にいることが（ユーザーの携帯電話から定期的にホームネットワークに提供される位置情報などを参照して）分かった場合、システムはユーザーの現在地点からお気に入りのプログラム（過去の視聴履歴や録画履歴を参照して決定したもの）にアクセスする方法を見極め、その情報をユーザーの携帯電話に送ることができる。

同様に、ユーザーが興味を持つ可能性がある今後の番組（ユーザーの現在位置に合わせたもの）をユーザーに知らせるために通知を送ることもできる。

TiVoによって現在は実装されていないが、複数のユーザーをサポートできるようにTiVoの設計を切り替えることができる。ユーザーごとのお気に入り視聴データを保存し、履歴や他のプロファイルデータを記録できるのである。各ユーザーは、TiVoのデバイスに登録された関連する携帯電話を1つ以上持つことができる。テレビシステムは起動しているがユーザーに特別な宣告がなされていない場合、システムは（ジャンル、タイトル、概要などのコンテンツメタデータとユーザーごとに保存されたデータとを比較したり、日時を検討したり、関連する携帯電話の現在位置を決定したり、携帯電話とシステムとの距離を識別したり、特定のユーザーを感知できるカメラで撮影した画像データに顔認識の技術を適用したりすることなどの）さまざまな要素から、ユーザー識別の推測を行う。すると、システムは推測したユーザー識別に合わせて操作を行うことができる。

携帯電話が「別画面」として機能することが、今後認められるようになるだろう。他の人が部屋でテレビを見ている間は、ユーザーは携帯電話でやり取りすることができる。フルスクリーンのエクスペリエンスに対するオーバーレイなどの妨害に邪魔されることもない。同様に、他の人が自分の携帯電話を使ってやり取りすることもできる。自分の選んだ補助コンテンツを楽しむことも（また、テキストメッセージや他のコンテンツをグループ内の他の人とやりとりすることも）できる。しかしながら、グループは共通の大画面や物理的な環境の共有されたエクスペリエンスを持つ。

（一部の実装形態では、グループは2箇所以上の場所から仮想的に集まることができる。1箇所で、主要画面を使って同じ映像コンテンツを同時に見ることもできるが、それぞれが自分の別画面（グループの他のメンバーとのオンラインでのソーシャルインタラクションなど）を使って互いに交流し合うこともできる。携帯電話は会議電話モードにすると同時に動作して、グループ内の他の人と話したり、他の人の会話を聞いたりすることができる。）

グループの2人以上のメンバーが別画面エクスペリエンスに（物理的または仮想的に）集まると、そのメンバーの携帯電話間で情報を共有することができる。視覚的なコンテンツ情報を他の携帯電話と共有するかどうかの通知を、各ユーザーはオプションとして設定することができる。このオプションを設定すると、グループのメンバーは他のメンバーの別画面エクスペリエンスに「合わせる」（または全員が同じ別画面エクスペリエンスを共有する）ことができる。

他の実装例では、コンテンツを表示するのに携帯電話を使用する必要はない。その代わりに携帯電話が簡単にできるのは、他のシステムに情報を提供することである。例えば、ユーザーの場所を特定したり、カレンダーアプリケーションを参照して、ユーザーが忙しいかどうか特定したり、ユーザーがじっとしているか移動中かを示したり、あるディスプレイシステムの近くにいるユーザーを特定したりすることなどができる。このような情報に基づいて、他のシステムは行う操作を決めることができる。

ユーザーが携帯電話に表示されたコンテンツをより見やすいようにテレビ画面に転送することが簡単にできる実施形態もある。逆に、ユーザーはテレビに表示されたコンテンツを持ち運べるように携帯電話に転送することもできる。この転送は、映像番組の再生中やゲームのプレイ中に行うことができる。その場合、中断時点から再開することができる。

当技術の別の側面としては、ユーザーがプロット指示や音声入力や登場人物名などを投稿することで娯楽コンテンツに参加し、より魅力的で夢中になれるユーザーエクスペリエンスを生み出すことができることが挙げられる。

当技術の他の側面においては、番組中心のコンテンツディレクトリは、ネットワークノードが伝える情報によって作成される。このネットワークノードは、ネットワークデータベースに（から）送られるコンテンツトラフィックを感知、識別するものである。さまざまなコンテンツレジストリ（ウェブサイト、テレビネットワーク、P2Pシステムなど）が広がっているので、このようなディレクトリによって携帯電話のユーザーは希望するコンテンツを入手できるソースの違い（スケジュールに応じて利用できるものや、オンデマンドで利用できるものがある）を区別することができる。アプリケーションによっては、ディレクトリ情報がユーザーにとって透過的であり、希望するコンテンツのソースを識別できるようにしたものもある。アプリケーションソフトウェアは、このコンテンツから例えばコンテキストや保存されたプロファイルデータに合わせて、ダウンロードするコンテンツを選択することができる。

上記は、この技術がもたらす新たな利点のほんの一部である。上記およびその他の機能・利点は、本明細書により詳細に明示される。付属の図とともに参照されたい。

本技術の側面を組み込んだ実装例の要素である。 本技術の実装で使用可能なデジタル映像レコーダーシステムの構成図で、保存されたデータを含んでいる。 本技術の実装で使用可能な携帯電話の構成図である。 主要コンテンツを補助コンテンツと関連付けるデータベースから抽出した記録を示したものである。 番組ディレクトリデータベースを自動的に作成する説明的アレンジメントの側面を示したものである。 番組ディレクトリデータベースを自動的に作成する説明的アレンジメントの側面を示したものである。 番組ディレクトリデータベースを自動的に作成する説明的アレンジメントの側面を示したものである。 番組ディレクトリデータベースを自動的に作成する説明的アレンジメントの側面を示したものである。

（詳細な説明）
本技術における実装形態では、ユーザーの個人用の画面（携帯電話など）上のコンテンツを提供する。個人用の画面は、別の画面（通常、より大きな画面）上で利用可能なコンテンツを補完するものである。

説明の便宜上、より大きな画面上で利用可能なコンテンツを主要コンテンツ、個人用の画面（「別画面」ともいう）上で表示されるコンテンツを補助コンテンツと呼ぶ。補助コンテンツの例として、音声や映像、ウェブページやその他のテキストデータ、アプリケーションプログラムやソフトウェアウィジェットなどが挙げられる。（状況によっては、ユーザーは補助コンテンツをより関連付けたものとすることもできる。また、状況によっては、主要コンテンツを参照せずに補助コンテンツを見ることもできる。）

図1を参照すると、本技術の実施形態10にはテレビシステム12や複数の別画面デバイス14、16、18を含むことができる。

テレビシステム12には、セットトップボックス20、衛星受信機22、デジタルビデオレコーダー（DVR）24、テレビ受信機/モニタ26、BlueRayデバイス28やその他の一つ以上のコンポーネント30（コンピュータ、Slingboxデバイス、Apple TVデバイス、iPod、Boxeeメディアセンターソフトウェアなど）などの要素が含まれている。

主要コンテンツは、あらゆるコミュニケーションチャンネル36によってテレビシステム12に送られる。コミュニケーションチャンネルの例としては、衛星放送、ケーブル放送、有線・ワイヤレスのインターネット、放送などが挙げられる。通常、コンテンツ配信元32（Comcast、DirectTV、テレビネットワークやテレビ局など）が、さまざまなコンテンツソース34（映画会社、コンテンツネットワーク、スポーツチームなど）から、コミュニケーションチャンネル36での配信のためにコンテンツを集める。他の会社（Apple iTunesストア、NetFlix、Google、YouTube、Hulu、ピアツーピアネットワークなど）も、コンテンツ配信元としての役割を果たしている。

補助コンテンツも同様に、あらゆるコミュニケーションチャンネル38によって送られる。インターネット40を使うことが多い。補助コンテンツの場合も、数種類のソースが発信を行う。その中には主要コンテンツを提供している同じ要素もあれば、別のソース（FlickrやWikipediaなどのウェブサイト、広告業者、Apple Appストアのベンダー、ソーシャルネットワーク上の友人やその他の人など）もある。補助コンテンツに、関連するソフトウェアウィジェットが含まれる例もある。詳細は特許出願番号61/150,235に記載されている。

ある特定の実施形態では、補助コンテンツはインターネット40を通じてユーザーの自宅に送信され、ホームネットワーク44を通ってルーター42から別画面デバイス14、16にワイヤレスに送られる。（デスクトップコンピュータ46などのホームネットワークを使って、別画面のコンテンツを有線のデバイスに配信することもできるが、一般的ではない。）

典型的なDVR 24を図2に示している。ネットワーク接続50（ホームネットワーク44などに接続されている）も含まれる。DVRには、映像コンテンツが配信される入力52や、電話接続54もある。入力52は、衛星受信機、セットトップボックスやアンテナなどのデバイスと接続できる。映像コンテンツがネットワーク接続50を通じてDVRに配信される場合は、この入力を外すこともできる。電話入力は、電子プログラムガイド（EPG）データやその他の説明書を定期的にダウンロードするために、DVRがデータセンターに電話できるよう接続されている。前掲の説明と同様、このようなデータが映像やネットワーク入力を通じて配信される場合は、入力54を外すこともできる。

図中のDVRにはプロセッサ56、ユーザーインターフェイス58（物理的制御と画面上のメニュー/制御の両方が含まれる）、リモコン60、データ保管62も含まれている。データ保管62には半導体とディスクの両方が含まれる。図中のデータ保管所60には、オペレーティングシステムソフトウェア、ユーザーインターフェイスソフトウェア、アプリケーションプログラムに加えて、EPGデータ、ソフトウェアウィジェット（特許出願番号61/150,235を参照）などのデータやソフトウェアプログラムモジュールと保存された映像データも含まれている。

また、データ保管所60にはさまざまなユーザー固有データも保存されている。この中には、記録済みプログラム、ユーザープロファイルデータ、ユーザーの携帯電話データだけでなく、記録すべき番組を列挙するスケジュールデータも含まれている。ユーザープロファイルデータに含まれているのは、番組視聴履歴、番組記録履歴、年間購読や他の常設の記録指示書、特定の番組に関するビューワーランキングや投票、視聴の好みを示したその他のデータなどの、さまざまな情報である。プロファイルデータには、郵便番号、ユーザーの年齢や性別、ユーザーが属する姻戚関係や社会集団などの人口学的な情報も含むことができる。

より洗練された実施形態では、様々なデータ保管所からプロファイルデータにアクセスすることができ、プロファイルデータにユーザーのウェブ閲覧履歴や他の情報ソースを含めることも可能である。この情報ソースには、ユーザーが関わりを持ってアクセスの痕跡を残したあらゆるデータ形式が含まれる。例えば、Googleの検索履歴、ウェブページのキャッシュ、cookies、メールのアーカイブ、ExpediaやOrbitzでの旅行予約、iTunesでの音楽コレクション、ケーブルテレビ加入、Netflixの映画視聴と配信待ち、携帯電話請求書、クレジットカード請求書、AmazonやEBayでの購入データ、GPS追跡情報、ソーシャルネットワーク上の友人やデータや行動、FlickrやPicasaなどの写真サイトやYouTubeなどの映像サイトでの閲覧や投稿、このような記録が残された時間帯などである。（このようなデータを「デジタルライフ履歴」と呼ぶ。）

さらに、ユーザーの家族や友人やユーザーと人口学的に類似した他人のデジタルライフ履歴データも参照される（これらのデータについてはすべて、適切に匿名化やプライバシー保護措置がとられる）。
DVR24にはさらに、場所を特定することができるモジュールもついている。例えば、GPSレシーバーである。

図3は、典型的な携帯電話14である。マイク、カメラ70、プロセッサ72、ディスプレイまたはタッチスクリーン74、物理的ユーザーインターフェイス、場所決めモジュール、メモリが含まれている。メモリには、オペレーティングシステムのソフトウェア、ユーザーインターフェイスソフトウェア、その他の機能的ソフトウェアモジュール、ウィジェットソフトウェアなどが保存される。

携帯電話には、DVRに関連して記載した一モジュールを採用可能である。

本技術の別実施形態によれば、ユーザーが今見ているかもしれない（あるいは今後見る）1つ以上の特定のテレビ番組を区別できるような推測（または推論、予想）を行うためのコンテキスト情報と連動して、ユーザプロファイルデータが使われる。コンテキスト情報にはユーザー位置も含まれる。また、ユーザーがその場所にとどまっているのか、移動中なのかという情報も含まれている。加えて/代わりに、コンテキスト情報は電子プログラムガイド（EPG）からのテレビ番組スケジュール情報でもよいし、および/または現在日時でもよい。

説明用の例として、プロファイル情報が以下の人物像を作る場合を考えてみたい。そのユーザーはピッツバーグ・スティーラーズの熱狂的なファンで、他にもプロフットボールの試合をたくさん見る。毎週Monday Night Footballを観戦している。また、そのユーザーはテレビで放送されているオレゴン大学のバスケットボールの試合をほとんど見ているし、時にはいくつかのゴルフも観戦している。自宅のテレビは、ほとんどいつもESPNに合わせている。

位置情報は、緯度と経度からユーザーの場所を特定できる。出願番号12/484,115において規定される地理位置情報サービス（YahooのGeoPlanetサービスなど）の1つを使った位置探索によって、ユーザーがオレゴン州ポートランドのSEホーソン通りにあるクロードスポーツバーにいることが分かる。また、位置データが一定時間動かないことも分かる。これによって、ユーザーが単にバーの前を車で通りすぎただけでないことが分かる。

他のデータがない場合、ユーザーはおそらくバーのテレビでスポーツ番組を見ている、とシステムは推論する。プロファイルデータによって、ユーザーがスポーツのテレビ放送に興味を持っていることが示されている。GoogleサーチがポートランドのSEホーソン通りにあるクロードスポーツバーを調べると、スポーツとテレビに関連する参照情報（「大画面」「衛星」「チャンネル」「フットボール」など）でいっぱいのウェブページが見つかる。推測エンジンはこれらの事実を入力して、保存された一連の法則から入力事項に関連したものを選り分け、法則間に対立する部分があれば解決し、1つ以上の推測を出力用に導き出す（例えば、このユーザーはおそらくテレビを見ている。そして、テレビではおそらくスポーツコンテンツが映し出されているだろう、という具合に）。

(本技術を採用しているこれらや他のコンテキストには、人工知能技術を適用することができる。人工知能の分野の1つが、自然言語処理（NLP）である。NLP技術は、クロードスポーツバーのウェブページで見つかった用語などの情報を理解するために使うことができる。特許7,383,169には、辞書や言語の他の大きな著作がNLP技術によって世界の「常識」などの情報の手に負えないソースとして役立つ語彙知識ベースを収集する方法が詳述されている。Wikipediaもこのような知識ベースの基礎として役立つ参照ソースである。このような常識的な知識を、ここで記載されている処理に適用することができる。）

より多くの情報がある場合、システムはユーザーの行動について、より正確な（あるいはより確信のある）推測を行うことができる。例えば、これが11月の月曜日の夜であることが分かれば、ユーザーがESPNのMonday Night Footballを見ていると推測できる。オレゴン大学がバスケットボールの試合をしているのが火曜日の夜ならば、ユーザーはその試合を放送している何らかのネットワークでｓのバスケットボールの試合を見ていると推測できる。

11月の月曜日の夜でかつオレゴン大学のバスケットボールチームの試合がテレビで放送されている場合は、アルゴリズムは「ユーザーが見ているのはMonday Night Footballなのかオレゴン大学のバスケットボールの試合なのか」という対立項に対処するために、他の経験則やプロファイルデータを適用する。推測エンジンは、ユーザーの過去の視聴履歴などのデータから、ユーザーがバスケットボールの試合を見ている可能性が70％で、フットボールの試合を見ている可能性が30％だと推測することができる。

システムはこの推測に基づいて、ユーザーの携帯電話に対して以前参照した特許出願に記載された種類などの対応する補助コンテンツを識別する。2つ以上の異なる補助コンテンツの選択肢（サムネイルまたはアイコン形式、静的またはストリーミングなど）が表示されるため、ユーザーはここから選択することができる。これらの選択肢には、例えば、試合中のフットボールのチームのNFLでの成績、攻撃中のクォーターバックを追いかけるカメラ映像、またはクォーターバックが次に行うプレイをユーザーに予想させるインタラクティブなゲームなどがある。

このシステムが確率的な結果（フットボールの可能性が70％で、バスケットボールの可能性が30％、というように）を出力すると、それに伴い、ユーザーに示されるコンテンツや選択肢が重み付けされる。

同様に、推測の確信度も、システムがユーザーに提供するコンテンツや選択肢に影響を与える。例えば、ユーザーがゴルフを見ているという確信が10％しかなければ、システムはゴルフ関連の補助コンテンツを推奨することはないだろう。代わりに、より一般的にユーザーのプロファイルに適したデフォルトの補助コンテンツ（フットボールのスティーラーズやバスケットボールのオレゴン大学の最近の試合のハイライト、次の試合の解説、ESPNヘッドラインなど）を提供する。

一部の実装形態では、システムはユーザーに1つ以上の質問をして、システムの推測を確認する。例えば、システムはユーザーの携帯電話にテキストメッセージを送信して「オレゴン大学のバスケットボールの試合を見ているのですか？」と尋ねる。または、ユーザーの携帯電話のアプリケーションプログラムが同様の質問をする。この質問に対するユーザーの回答に従って、ユーザに提示する補助コンテンツ（またはコンテンツの選択肢）が合わせられる。

携帯電話は、このような質問でユーザーの邪魔をするのではなく、ユーザー環境から音声や視覚情報を（携帯電話のマイクやカメラなどから）取得し、電子透かしによる解読やフィンガープリント抽出などの技術によって推測を確かめることも簡単にできる。

テレビの音声には通常、送信前にコンテンツ配信元（KOINテレビなど）によって挿入されたNielsenの電子透かし信号がついている。透かしは、ソースIDとタイムスタンプという2種類の情報を繰り返し運ぶ。ソースIDには2つの部分がある。1つ目は、通常CBS、ESPNなどのコンテンツが配信されたネットワークを識別する。2つ目はKOINテレビやウエストポートランドのComcastケーブルなどのローカルアウトレットを識別する。タイムスタンプは、送信日時を付与するインクリメントを行う時計である。透かしを挿入するエンコーダーは、Nielsen社がテレビ消費を追跡するのを補助する既存ネットワークの一部である。Nielsenは、日時によって地域別市場や国別ネットワークごとに、各チャンネルの番組編成を記載するデータベースを維持している。このデータベースには、Tribune Media社及び／またはTV Guideなどの業者が作成する番組ガイド情報が入力される。

慣例的な透かし使用モデルでは、透かしから未知のテレビ番組を識別する。この場合、データベースへのクエリとして透かしのID/タイムスタンプが入力され、データベースはその時点のテレビソースがで放送されている番組を識別する出力データを返す。

本アプリケーションの場合は、少し異なる。なぜなら可能性のある番組に対する推測が、すでに行われているからである。このような場合、予測される番組を識別する情報は、データベースへのクエリを行ってソースID（と任意で、番組の予定放送時間を示すタイムスタンプデータ）を読み込むために使われる。次に、ユーザー環境からキャプチャーされた音声に対して、読み込んだソースIDと一致しているかを確認する。（技術的に、未知の透かしが存在するかどうかを識別するために音声を分析するよりも、1つ以上の予測された透かしが存在するかどうかを決定するために音声を分析する方が簡単である。）

システムは、当初の送信時の番組時間帯において、ユーザー環境で利用可能なコンテンツが存在していることを推定する。それゆえ、予測される番組を現在送信している一つ以上のソースを識別するために、データベースにクエリを行う。例えば、Monday Night FootballはESPNと地元の放送局が放送している。そこで、これらのソースに対するソースIDをデータベースから取得し、これらのソースIDの一つに関連する透かしが存在するかどうか決定するために、ユーザー環境の周囲の音声を分析する。存在すれば、推測が確認されたことになる。（録画されたコンテンツに対しても、より広い候補番組の範囲を考慮しなければならないものの、同様のアプローチが可能である。）

上述のように、コンテンツを識別（または確認）するもう一つのアプローチは、フィンガープリントである。フィンガープリントは、識別のために未知のメディアコンテンツの特徴と既知のメディアコンテンツをマッチングすることによって機能する。また、システムがすでにコンテンツの識別に関する推測を行っているため、現在のコンテキストの方が通常のコンテキストよりも簡単である。そのため、推測を確定する目的で行う、予測した番組が一致しているかを確認するためにキャプチャーされた音声（または画像）が簡単に分析される。（例えば、予想された番組のフィンガープリントが抽出された音声と一致しているかを確認できる。これは、仮想的に無限の可能性の中から抽出されたコンテンツを識別するのにフィンガープリント技術を使うよりも簡単な作業である。）

さらに別のアレンジメントにおいては、抽出された音声や画像に対して、ユーザーが他の行動をとっているのではなくテレビを見ていることが、簡単に確認できる。例えば、テレビの音声には、2人の人が会話している際のスペクトル分布などとは区別できるスペクトル分布がよくある。テレビの音声は、平均出力を上げて人間の聴覚が最も正確に反応できる範囲にエネルギーを集中できるように、帯域制限や圧縮（制限）をかけていることが多い。同様に、TV映像には視覚的に独特の特徴がある。CRTテレビモニタには、可視スペクトルにおいて特徴的なピークを生み出すカラー蛍光体が使われている。テレビ画面は、固定の割合でリフレッシュされる。その割合によって、画像は自然の景色と区別できる。ユーザーが話し合いをしていたりフットボールの試合を生で見ていたりするのではなく、テレビを見ていることを確認できるように、この特徴や他の特徴を使うことができる。

ある実装では、上述の処理はユーザーの携帯電話内のプロセッサ72と関連アプリケーションソフトウェアによって行われる。他の実装では、この処理はユーザーのDVR、ケーブル会社のサーバー、クラウド、またはほかの場所で行われる（あるいはこれらのプロセッサ間で分散される）。

ユーザーは自宅から離れた街に出掛けていることもある。ユーザーの位置は、GPSなどによってわかる。しかし、家から離れた街で視聴可能なテレビ番組は、通常ユーザーの携帯電話や自宅のDVRが追跡しているものとは異なっているかもしれない。このような場合、家から離れた街でコンテンツの入手可能性とそのスケジュールを決定するために、システムはTV GuideのウェブサイトやTribune Media社からのデータ（あるいは下記に記載するProgram Directory Database）などのオンラインリソースを使うことができる。ユーザーの位置とプロファイル情報に加えて、家から離れた街で入手できる番組編成が分かれば、システムはここでもユーザーが現在見ている（あるいはこれから見る）特定の番組を推測することができる。

ユーザーの予測した視聴活動の情報は、ユーザーの自宅（リモートデバイスによって決定された場合）に送り返される。ここで情報は保存されるか、必要とされる特定のアプリケーションとして使われる。ユーザーが視聴活動を確認した場合、その情報もユーザーの自宅のネットワークと連結したデータ保管所などに同様に記録することができる。

ここで記載したアレンジメントは、ユーザーが現在視聴しているコンテンツを推測し、その結果に基づいて動作する。ユーザーが今後視聴する（あるいは視聴したいと興味を持つかもしれない）コンテンツを推測する場合も、同様の手順を使うことができる。すると即座に（または後程）、補助コンテンツや通知がユーザーに送られる。

特定の実装は、ユーザーの場所を示すデータ（ユーザーの携帯電話の場所など）を受け取る。そして、ユーザーに関するプロファイルデータと連動して、ユーザーが見たいかもしれない今後のテレビ番組を1つ以上識別する。次に、その今後のテレビ番組についての通知をユーザー（の携帯電話など）に送る。ユーザーがその番組を見ている（あるいはこれから見る）場合、ボタンや信号を押すように、通知は案内することができる。また、ユーザーが家から離れた場所にいる場合、通知をカスタマイズするために、ユーザーの現在地におけるメディア市場からの番組編成データを使うことができる。

このプロファイルデータは、ユーザーの自宅DVRが特定の時間に特定の番組を録画するよう設定されていることを示す情報と同じくらい簡単なものである。例えば、ユーザーは以前に、自宅で「年間購読」を設定するためにTiVoデバイスのユーザーインターフェイスを操作して、バスケットボールのミネソタ・ティンバーウルブスの試合中継をすべて記録するようデバイスを設定したかもしれない。システムはユーザーに対して、試合のたびに、もしくはあらかじめ短い間隔（5、15、60分など）で、これから試合が放送されるという通知を送ることができる。（図2に示すDVRのように、DVRはユーザーの携帯電話の番号を把握しているので、テキストメッセージや音声通知などでこのような通知を送ることができる。）

特定の番組を視聴していることをユーザーが確認する（あるいは、音声サンプリングなどの他の方法によって視聴を確認する）と、そのことがネットワークやコンテンツ作成者やその他の団体に中継され、これによって、彼らは補助コンテンツを補完するものを提供することができる。例えば、ユーザーは、フットボールの試合に出場する選手や、リアリティテレビ番組において島から締め出される人を決めるオンライン投票への参加に招待されることがある。そのため主要コンテンツの結果は、ある程度、補助コンテンツへの視聴者の参加度に左右される。（この特徴の詳細については、後述する）別の例では、オバマ大統領が長らくピッツバーグ・スティーラーズのファンである、というようなトリビアが不定期にユーザーに表示される。ユーザーのプロファイルデータがネットワークなどで共有されると、ネットワークは意味のある補助コンテンツと視聴者をうまく結び付けられるようになる。

いくつかの実施形態によっては、ユーザーは自分の携帯電話に視聴用の決まった番組を送信するように要求することで、通知に答えることができる。

ユーザーがテレビ番組を視聴していることを推測できるのと同様に、ユーザーが視聴を中止したことも推測することができる。例えば、携帯電話によって音声や映像データを感知することで、この推測が可能となる。加えて/代わりに、（加速計を使ったり、携帯電話の視界に映る特徴の動きを感知することによって）携帯電話の動きを感知することもできる。

視聴者がテレビの視聴をやめたのが明らかな場合、関連する動作が行われる。1つは、視聴者が後で視聴を再開できるように、番組を一時停止することである。もう1つは、コンテンツの見逃した部分についての情報を視聴者に送ることである。ここにはキーフレーム、映像ハイライト、テキスト概要などが含まれる。これらの1つ以上が見逃したコンテンツの録画版と結びつく。

前述のとおり、DVRデータ保管所やホームネットワークの他の場所への登録データによって、1つ以上の携帯電話は特定のテレビシステムと関連づけられる。それにより、システムと1つ以上の関連づけられた携帯電話の間で、情報を共有することができる。

特定のアレンジメントでは、夫婦の両方が家族のTiVoシステムに登録された携帯電話を持っている。各携帯電話に、夫婦それぞれのTiVoプロファイル（お気に入り、視聴履歴、映像録画、年間購読などを含む）を入れることができる。

与えられた番組に関連付けられているのが夫婦のどちらなのかが明らかな場合もある。例えば、ある番組がどちらかの指示で録画されていて、2人の録画一覧に表示されているとする。テレビが録画された番組を流す時、テレビは番組の録画予約を行った人に対して、補助コンテンツ（あるいは補助コンテンツの入手可能性に関するメッセージ）を示す。

また、番組と関連付けられるのが夫婦のどちらなのか（あるいは両方なのか）が曖昧な場合もある。土曜日の午後、誰かがテレビをつけてゴルフ放送に切り替えたとする。見ているのは誰だろうか。様々なヒューリスティックが適用されうる。

1つは、過去の録画履歴を分析することである。妻の録画一覧にゴルフ番組が入っているが、夫の録画一覧には入っていなければ、システムは見ているのが妻だと推測することができる。そのため、妻の携帯電話にデータを送る。他のプロファイルデータも同様の効果のために使うことができる。

別のアプローチは、夫婦どちらか（あるいは両方）の携帯電話の場所を感知することである。テレビの近くにあるどちらか（あるいは両方）の携帯電話に対して、データを送ることができる。

携帯電話はBonjourプロトコルを起動して、その携帯電話が誰なのか（夫婦のどちらの持ち物なのかなど）、何をしているのかを、ホームネットワークの他のデバイスに対して通知する。テレビはこの放送を受信して、これに基づいてテレビを見ている携帯電話を特定することができる。

他にもさまざまなアレンジメントを採用することができる。例えば、テレビシステムには視聴者を識別するためのカメラや顔認証アルゴリズムが備えられている。これは携帯電話が自分で地元のセルサイトに対して識別を行うことによって送る定期的な送信を監視することができる。あるいは、テレビシステムは単に、ゴルフを見ているかどうかを夫婦のどちらかに尋ねることもできる。訊かれた相手が「はい」と答えた場合は、その人に対して補助コンテンツの情報を送ることができる。「いいえ」と答えた場合は、もう一人に対して補助コンテンツの情報を送ることができる。

ここまで述べてきた例では、テレビシステムは積極的な役割を果たしている。補助コンテンツを提供できるように、視聴者を識別しようとしているのである。他のアレンジメントでは、テレビシステムが異なる働きをする。ユーザーは、補助コンテンツや他のインタラクティビティに興味があることを示すために、（WatchingTVアプリケーションを起動するなどして）携帯電話を操作する。すると、携帯電話とテレビシステムの間で論理的な関連付けが行われる。この関連付けはアドホックで、データレジストリなどに過去保存された情報によって決めることができる。

このアドホックの例としては、位置決定、地域のワイヤレスネットワークからのBonjour放送、透かしや周囲の音声/映像など他の独特な特徴から、携帯電話が自分がテレビの近くにいることを感知するというものがある。（テレビシステムは、そのテレビが放送するコンテンツ内にエンコードされたデジタルの透かしを解読することで、識別を行う。そこでは、透かしが特定のテレビシステムの識別子を運んでいる。）論理的な関連付けが行われると、ユーザーの楽しみのために、テレビに表示されている主要コンテンツと関係する補助コンテンツが提供される。（他の場合のように、補助コンテンツはユーザーのプロファイルや場所に左右される。）

他の場合では、データレジストリなどに過去保存された情報によって論理的な関連づけが決定される。例の1つが、ユーザーのホームTiVoシステムに登録されている携帯電話である。ユーザーが、関連するテレビシステムの近くにいない場合もある。その場合でも、ユーザーの携帯電話は関連するテレビシステムを参照して、関連情報をユーザーに示すことができる。提示された情報には、テレビシステムの状況や、そのシステム上で視聴または記録されている番組名を単に含む。あるいは、関連システムで現在処理されている（または以前保存された）コンテンツに関連する補助映像やウェブコンテンツを含むこともできる。（ここで、他の実施形態と同様に、携帯電話はユーザーが複数の選択肢から選ぶことのできるメニューを示すことができる。利用可能な補助コンテンツが複数ある場合は、ユーザーが選択できるコンテンツ（映像を含む）のサムネイルビューがメニューに含まれる）

別画面の補助コンテンツがアプリケーションに応じて主要コンテンツの一部あるいはすべてになるということを認識する必要がある。例えば、前述の状況で（ユーザーがホームDVRに録画される番組についての通知を受け取る場合）、補助コンテンツは、主要コンテンツを再構成してユーザーの携帯電話画面に表示させるために流し込んだものとなる。携帯電話のユーザーインターフェイスは、携帯電話のタッチスクリーンインターフェイス上で関連操を行うことで作動するコンテンツの利用可能性を知らせることができる。

この実施形態や他の実施形態では、1つ以上の携帯電話や別画面に対して補助コンテンツの提供や命令を指示することで、ユーザーは補助コンテンツの提供に反応することができる。従って、ティンバーウルブスの試合が始まっているという通知がユーザーの携帯電話に届くと、ユーザーは自分のラップトップに補助コンテンツを転送したり、ティンバーウルブスのファンであるクラスメートの携帯電話にその補助コンテンツを提供したりすることもできる。このような中継は、ユーザーの携帯電話から（近くの別画面デバイスへのBlueToothや、より遠くのデバイスに対してはWifiとインターネットを使って）ワイヤレスに行われる。代わりにBonjourプロトコルを採用し、ホームネットワーク（あるいはその他のネットワーク）のすべてのデバイスから受け取ったデータを送信することもできる。

ある実施形態では、補助コンテンツを配信処理におけるアップストリームノード（図1のサーバー34の一つやユーザーのホームDVR 12など）から指定場所に配信するようにユーザーの携帯電話が指示する。

ユーザーと関係のある人（ソーシャルネットワーク上で「友達」の状態にある人など）や物理的な距離が近い人やユーザーの電話帳や共通のネットワーク上にいる人と、コンテンツを共有することができる。

共有されたコンテンツは、相手の携帯電話上でウィンドウなどのディスプレイ画面の一部分に表示することができる。相手がウィンドウを選択すると、そのディスプレイをフルスクリーン表示することができる。表示画面のすべてに同時にそのコンテンツが表示されるのが望ましい。

いくつかの実施形態によっては、番組通知を複数の人に送って、要求があれば各々が補助コンテンツを利用できるように、DVRをプログラムすることもできる。

ユーザーがテレビを見ていることを推測するためには、ユーザーの場所を完全に知らなくてもいい。他のアレンジメントでは、ユーザーがテレビの近くにいるという単なる事実が推測され、それに応じて動作することができる。

距離が近いことを推測するさまざまな技術には、上述の通り、テレビからの音声や画像のうち、他の音声や画像と異なっている特徴を検出するものがある。テレビや他の映像機器から排出される空電の量が少ないことも検出できる（NTSCテレビのカラーバーストオシレーター、テレビ画面のリフレッシュレート、映像スキャンの周波数など）。テレビからのBonjourプロトコル送信も利用できる。

逆に、テレビは、携帯電話からセルラーネットワークに定期的に送信される近距離RF信号、近くのルーターに送られる近距離WiFi信号、BlueToothの信号、Bonjourプロトコルの送信などによって、近くにある携帯電話の存在を検出することができる。テレビシステムはこのような送信から携帯電話を識別することができる。そして、テレビとの距離が近いことが確認できると、ユーザーが見ている可能性が最も高いテレビのコンテンツについて推測することができる。

ユーザーと映像画面の距離が近いことが確認できると、ユーザーのプロファイルデータに合わせて、補助コンテンツをユーザーに提供することができる。

今後登場する地理位置アレンジメント（詳細は下記に記載）などによって、最終的には、すべてのデバイスが自分の位置を把握する日がやってくるだろう。これらのデバイスは、この情報を（ワイヤレスやBonjourなどによって）ローカルデバイスと共有したり、位置データを他のデバイスがアクセスできるネットワークデータ保管所に投稿したりすることができる。このような環境では、ユーザーの携帯電話はその場所を把握し、近くの（マップ形式で表示される）電子デバイスを識別することができる。携帯電話の近くにテレビモニタが見つかると、システムはユーザーはテレビを見ているのだと推測することができる。（「近く」とは、提供されるアプリケーションごとの要件による。10フィートを「近く」とする場合もあるし、20フィートの場合もある。Jumbotronの映像モニタの場合は、10または100ヤードを近くとみなしている。）

次世代の映像システムは、表示しているコンテンツを識別するデータを（ワイヤレスに、またはBonjourで、あるいはネットワークデータ保管場所に）発行することができる。そのような場合にはもう、コンテンツの推測を行う必要はなくなる。映像機器が、その情報を明確に利用できるようにするのである。本技術を使ったシステムは、このような情報にアクセスして、情報（と任意でプロファイルデータ）を基に、近くのユーザーの携帯電話に対して関連する補助コンテンツを提供することができる。

このような場合は、前述の通り、近くの画面に表示されている映像コンテンツをユーザーが実際に見ているかどうかなどを、システムは確認しようとする。このような確認は1回だけではなく、繰り返し求められる。

このような例のすべてにおいて、ユーザーの携帯電話に補助コンテンツを表示する必要はない。主要コンテンツと共に大画面（ウィンドウなど）に表示するか、他の場所に配信してもよい。

ユーザーに情報やコンテンツを提供するだけではなく（あるいは提供するのではなく）、携帯電話は他のシステムに情報を簡単に提供することもできる。例えば携帯電話は、ユーザーの場所を特定したり、カレンダーアプリケーションを参照してユーザーが忙しいかどうか特定したり、ユーザーがじっとしているか移動中かを示したり、ユーザーが特定のディスプレイシステムの近くにいることを特定したりすることができる。次世代の携帯電話は、ユーザーが寝ているのか食事中なのかなどの生物学的指標を伝えることもできる。すると他のシステムは、それらの情報に合うようにシステムを適用させる。

例えば、空港ラウンジのテレビシステムによってJane Doe（より正確に言うと、彼女の携帯電話）が近くでじっとしていることが感知される。するとテレビシステムはJane Doeのプロファイル情報を（携帯電話やオンラインリソースなどから）読み込んで、例えば、現在のLPGAゴルフトーナメントなど最も興味のある映像番組を識別するするとテレビは自動的に、彼女の待っている間に該当番組を表示する。Jane Doeが立ち去ってJohn Smithが腰かけると、テレビは同じようにチャンネルをCNBCに切り替えるのである。

主要プログラムを選択するのではなく（あるいは選択するだけでなく）、このようなシステムは近くのユーザーに対して、特定の興味のある補助コンテンツを識別することもできる。例えば、John Doeの携帯電話は、WiFiネットワークやBlueToothを介して、彼がデフォルトにしているYahoo Financeポートフォリオの株式銘柄（株式の金額ではない）を利用可能にする。テレビシステムは、CNBC画面上に自動的に小型画面を重ねて、現在のこれらの株価をスクロールで表示することができる。

このように、本技術に基づいた携帯電話がユーザー環境に対応できる間は、ユーザー環境もユーザーに対応することができるのである。

（補助コンテンツの追記）
主要コンテンツの特定の項目により利用可能になった補助コンテンツの項目は、主要コンテンツ（ＥＳＰＮのような映像ネットワークなど）のプロバイダ、または他のネットワークまたは商業団体が選択することができる。しかし、代替手段として、ソーシャルネットワークの形態などで、補助コンテンツをクラウドソースにより特定する方法がある。

ソーシャルネットワークは事前に定義することも（Ｆａｃｅｂｏｏｋの友人のJohn Doe、オレゴン州ポートランドの高校時代の友人など）、アドホックにすることもできる（今夜のティンバーウルブズの試合をたった今視聴している人物なら誰でも、など）。

個人ユーザーは独自の補助コンテンツを探す場合がある。たとえば、高校生がジェームズ・ボンドの映画を視聴すると、アストンマーチンのホームページ、または英国のＭI６として知られる秘密情報局のホームページを閲覧するかもしれない。定年退職者が同じ映画を視聴すれば、Ｗｉｋｉｐｅｄｉａのページで「ステアでなく、シェイクで」を閲覧する傾向があるかもしれない。あるいは、タンカレージンのホームページを閲覧するかもしれない。
同様に、バスケットボールプレイヤーであるケビン・ラブの母校に在籍する高校生がＮＢＡのミネソタティンバーウルブズのバスケットボールを見れば、ケビンの統計データが掲載されているＮＢＡ．ｃｏｍのページに移動する、またはケビンがバスケットボールのバックボードを破壊する、伝説的な高校時代の試合をＹｏｕＴｕｂｅの映像で視聴するかもしれない。

このような選択を記載したデータは、公的にアクセス可能なデータベースで収集することができ、関連するコンテンツを他者が特定できるリソースとして機能することができる。補助コンテンツの各項目は、（１）閲覧ユーザーのプロフィール情報、および（２）関連づけられたコンテンツを特定する情報、に関連づけられる。

実装方式のひとつに、共通の属性を使用してデータをグループ化できる、リレーショナルデータベースを導入する方式がある。そのようなデータベースにおけるデータの配置図を図4に示す。

当然ながら、これは単なるサンプリングである。データベースは、他のデータを含む、または他のデータにアクセスできることが望ましい。ここで言う他のデータには、コンテンツの各項目に関連付けられたメタデータを含む。項目は、ジャンル、役者、キーワード記述子、ＩＳＡＮ（国際標準視聴覚番号）とＤＯＩ（デジタルオブジェクト識別子）の両方またはいずれか、日付、などにより分類している。電話番号のエリアコードおよび市外局番、ＩＰアドレス（またはドメイン）および前述のプロフィール情報などの各ユーザーの追加プロフィールデータを提供することもできる。

このデータは他の方法でもデータマイニングできる。ＭI６の公式サイトを自主的に閲覧する人物は、映画『ゴールドフィンガー』などを見たいという考えに駆り立てられるかもしれない。ウェブブラウザは表示されたコンテンツ上にサイドバーを一時的に重ね合わせ、「このページに興味を持ったユーザーは、以下のサイトにも興味を持っています。＜他のコンテンツの識別＞」という通知を表示することができる。

このようなデータベースは、個別のコンピュータでホストでき、または多くの異なるプラットフォームで配信（または複製、またはその両方）することが可能である。ピアツーピアのアレンジメントは、データベースのさまざまなパーツがさまざまなユーザーのコンピュータ上に存在する状態で導入できる。

このようなデータベースは、記載事項を明確に付け加え、注記を付けるユーザーにより、Ｗｉｋｉの形態で管理できる。他の代替手段は、Ｇｏｏｇｌｅのようなベンダがデータを蓄積する方法である。この場合、新しいサービス（「ＭｅｄｉａＧｕｉｄｅ」など）を提供でき、そこに主要コンテンツ（テレビ番組など）の所定の項目で最も多く消費されている補助コンテンツ（ウェブページ）の格付けリストが記載される。

すでに、Ｇｏｏｇｌｅ Toolbarの製品に賛同するユーザーは、アクセスしたウェブサイトを特定するデータをＧｏｏｇｌｅに提供している。Ｇｏｏｇｌｅ Toolbarを強化し、ウェブ閲覧時のユーザーの環境に存在するメディアコンテンツを特定するデータをＧｏｏｇｌｅに提供することもできる（バックグラウンドメディアデータ収集モード）。

メディアコンテンツは、本明細書および参考として組み込まれた文書に詳細を記載した、電子透かし技術、フィンガープリントなどを含む多様な手法により特定できる。Ｇｏｏｇｌｅ Toolbarはコンテンツを完全に特定できる（捕捉した音声の透かしを解読するなどにより）、または捕捉した音声（または映像）に単純に幾つかの処理を施し、処理したデータをＧｏｏｇｌｅのサーバーに転送することで、フィンガープリントのような特定タスクを完了することができる。（音声を不鮮明にするなどにより、処理を行う際に個人を特定できる情報を削除することが望ましい。このような処理の一種がウィナーフィルタリング、つまり音声振幅の瞬間的な値から音声振幅の短期的平均値を減算する方法である。その他に、音声中に存在する特定の目印のタイミングと周波数を抽出する方法がある。その例は、Ｓｈａｚａｍ社の特許７、３５９、８８９に詳細が記載されているとおりである。）

周辺メディアは、高い確実性を持って特定する必要はない。不完全なデータまたは状況に基づく推測（本明細書の他の部分で説明したとおり）で十分な場合がほとんどである。このようなデータが大量に収集されたときは殊更である。主要コンテンツとそれに伴う正確に特定された主要コンテンツに基づいた補助コンテンツの関連付けは、集団化し、明らかなパターンが浮かび上がる傾向がある。たとえば、オプラが司会を務めるテレビ番組の視聴者の多くは、ＯｐｒａｈＢｏｏｋ Ｃｌｕｂのウェブページおよびオプラの番組に出演するパーソナリティのウェブページにアクセスするかもしれない。ＣＮＢＣの視聴者の多くは、ウォールストリートジャーナルのウェブサイトおよびＹａｈｏｏＦｉｎａｎｃｅのウェブサイトにアクセスするかもしれない。対照的に、特定に失敗したコンテンツに基づいた関連付けは集団化されない。つまり、それらのコンテンツは検索結果の上位に出現するような頻度で発生しない。従って、正しく特定されたメディアが２０％足らずであっても、または時として２％であっても、有用な関連付けは徐々に出現してくる。

他の実施形態では、推測または判断が必要とされない。つまり、テレビシステムまたは配信／レンダリングチェーンの別の場所にあるデバイスにより、主要コンテンツが明確に特定される。たとえば、ＴｉＶｏボックスはテレビ画面に何のコンテンツを配信しているか把握し、この特定データをＧｏｏｇｌｅ Toolbarが使えるようにすることができる。特定の実施形態では、ＴｉＶｏシステムのソフトウェアがＢｏｎｊｏｕｒプロトコルを導入し、ホームネットワーク内の他のデバイスに、現在表示されている映像の特定情報を通知する。Ｇｏｏｇｌｅ Toolbarのソフトウェアはこの送信内容を受信し、同じ内容をＧｏｏｇｌｅに転送する（アクセスしたウェブページを特定するデータを転送する場合と同様）。

クエリモードでは、予定されたＭｅｄｉａＧｕｉｄｅサービスが主要コンテンツの識別子を入力データとして使い、データベースから特定した対応する補助コンテンツの格付けした記載事項を出力データとして提供する。入力識別子は、オプラまたはCNBCなど、ユーザーが入力したキーワードの場合がある。代替手段として、ユーザーのデバイス（Ｇｏｏｇｌｅ Toolbarに関連付けられたモジュールなど）が周囲の音声を単純にサンプリングし（ユーザーコマンドに応じて、または自動的に）、関連付けられた識別子をサービスに提供することができる。これらの識別子はテキストのキーワード（番組のタイトルなど）、または特定の番組（透かしペイロード、音声または映像フィンガープリントその他など）に関連付けられた他の識別子であってもよい。実施形態によっては、捕捉した音声データまたは処理済みの音声データを入力データとして提出することができる。Ｇｏｏｇｌｅサーバーは、この音声データに基づいて主要コンテンツを特定し、対応する補助コンテンツの格付けされた識別情報に応えることができる。

さらに他の実施形態では、上述のとおり、テレビシステムまたは配信／レンダリングチェーンの別の場所にあるデバイスにより、主要コンテンツが明確に特定される。

このようなＭｅｄｉａＧｕｉｄｅのクエリの結果は、Ｇｏｏｇｌｅのウェブ検索結果と同様の、よく知られたフォーマットで表示することができる。データベースから得られたハイパーリンク付の検索結果が画面の大部分を満たす。画面の端にはスポンサードリンクを表示することができる。たとえば、Trailblazersのバスケットボール番組に基づいてたメディアクエリに対する検索結果のページの右上に、Ｎｉｋｅ社が有償で自社のエアジョーダンのウェブページへのリンクを表示させることができる。

主要コンテンツと補助コンテンツの関連データの初回コーパスを収集したら、そのシステムをクエリモードで使用することにより、メディア関連データをさらに収集することが可能になる。ＧｏｏｇｌｅToolbarは、異なる主要（周辺）メディアが存在するときに、どの補助コンテンツの検索結果が選択されたかを把握することができる。この情報はＧｏｏｇｌｅに送られ、将来その主要メディアコンテンツに基づいて検索が行われると、それを通知することができる。

メディアデータ収集モードの間でデモグラフィック（年齢、性別、郵便番号など）データがわかっている場合、ユーザーのデモグラフィックにあわせて検索結果をカスタマイズすることができる。たとえば、ポートランド在住の１９歳の男性により、Trailblazersのバスケットボールの試合に基づいてＭｅｄｉａＧｕｉｄｅでクエリが実行された場合、同様のプロフィールを持つ他のユーザーが消費する、最も人気のある補助コンテンツを報告することができる。

単純詳細アレンジメントが、コンテンツ消費の慎重なスクリプト記述という通常の形態からの脱却であることが認識されるであろう。歴史的に、広告代理店およびコンテンツネットワークのような商業団体は、主要コンテンツと補助コンテンツを組み合わせていた（テレビ放送と関連するコマーシャルを考慮のこと）。本アプローチでは、これとは対照的に、実際のユーザーの活動を調査することで豊富な情報を取り出し、適切なコンテンツのペアリングを恣意的ではなく有機的に確立する。

Ｇｏｏｇｌｅの提供物に関する文脈で説明したが、いくつでも特定の実装を行うことが当然可能である。ポケットベルの大きさのデバイスであり、視聴者調査を目的として周辺メディアを感知するＰｅｒｓｏｎａｌＰｅｏｐｌｅ Ｍｅｔｅｒ（ＰＰＭ）を採用した事例もある（Ｎｉｅｌｓｅｎ社特許公開番号２００９００７０９７、およびＡｒｂｉｔｒｏｎ社特許６,８７１,１８０および７,２２２，０７１などを参照）。視聴者調査会社は、このような測定を行うため、個人を採用して埋め合わせている。これと同じ個人が、自身のウェブブラウザにソフトウェアをインストールし、アクセスしたウェブサイトとアクセス日時を報告するために採用される場合がある。次に、個人のウェブサイトのデータおよびＰＰＭのデータを時間的に関連付け、ウェブコンテンツと放送コンテンツの間の関連性を確立することができる。

同様に、Ｇｏｏｇｌｅ Toolbarのソフトウェアを使用する代わりに、ネットワーク接続したメディア監視デバイスにより、このようなデータ収集を達成できる。その一例は、Ｎｉｅｌｓｅｎの特許公開番号２００８０３２０５０８に記載されているとおりである。

本明細書に記載の技術は、テレビおよびその他のコンテンツの視聴者測定を強化するものであることが認識されるであろう。このようなシステムのオペレータは、世界中のメディア消費状況に関するリアルタイムの情報を受信する。ＮｉｅｌｓｅｎおよびＡｒｂｉｔｒｏｎで使用されるような視聴者分析技術を導入することができる。

さらに、詳細なシステムは視聴者情報に関する他の側面、つまり同時消費コンテンツに関する情報を提供する。これは、広告代理店にとって特に役立つ可能性がある。

従来のテレビ視聴者測定調査では追跡できない、たとえば頻繁に休暇旅行に行く層などの特定のデモグラフィックに対して、自社の製品の販売を促進したい企業を考えてみる。かつては、望ましいデモグラフィックに対する実質的な代表層として、たとえば４９歳から６４歳までの年収１０万ドル以上の人物など、別の測定基準を使用していた。しかし、これでは十分ではなく、関連性のない番組を特定する、または関連する番組の特定に失敗することが多かった。

しかし、ウェブサイトへのアクセスデータと対にすることで、テレビ視聴者測定は新しい意味を持つことになった。対象のグループのデモグラフィック代表層を特定する代わりに、広告主は対象のグループにとって役に立つウェブサイト、たとえばＥｘｐｅｄｉａ、Ｔｒａｖｅｌｏｃｉｔｙ、Ｐｒｉｃｅｌｉｎｅ、Ｈｏｔｗｉｒｅなどにより、単純詳細データベースでクエリを実行する。この操作モードでは、データベースはそのようなサイトにアクセスしている間に最も多く視聴されているテレビ番組の名前を返す。望ましい視聴者のデモグラフィックを提供するテレビ番組が、簡単にそして明確に特定される。

オフロード用オートバイの愛好者に人気のあるテレビ番組に広告を出したい会社があれば、その会社はＦｏｕｒｗｈｅｅｌｅｒ、ＯｆｆｒｏａｄｅｒｓおよびＰｉｒａｔｅ４ｘ４といったウェブサイトに関連付けられたテレビ番組について、データベースでクエリを実行する。アルツハイマー病患者のいる家族が視聴するテレビ番組に広告を出したい会社があれば、その会社はアルツハイマー病協会のウェブサイトを閲覧している間に最も多く視聴されているテレビ番組について、データベースでクエリを実行する。オンラインゲームの愛好者が視聴するテレビ番組であれば、その会社はユーザーが有名なゲームサイト（Ｗｏｒｌｄｏｆ Ｗａｒｃｒａｆｔなど）にアクセスしている間に放送しているテレビ番組をデータベースから検索する。

このようなアプローチは、テレビの視聴者測定の精度を大きく発展させるものである。視聴者は、年齢、居住地、年収、学歴などの一般的なデモグラフィックだけで分類されることがなくなり、彼らの興味の対象が明らかになる。これらの事実は、同一の隣人から個人を統計的に区別するものである。また、このような興味の対象を収集することは、アンケートでは信頼性に疑問があり実現できなかったが、ウェブ閲覧の実際の習慣を参照することで可能になった。

周辺メディアに関する情報は、他の方法でも活用できる。そのひとつが、ｃｏｏｋｉｅに関する情報である。ｃｏｏｋｉｅは、ウェブサイトがその表示を返すユーザーに向けて、表示内容を調整するために使用されてきた。ユーザーの過去の活動または興味に基づいて、表示する情報をカスタマイズするなどの例がある。同様に、現在ユーザーが表示しているテレビ番組に関する情報を、ユーザーが閲覧するウェブサイトに中継し、その情報に従ってウェブサーバーがその表示内容を変化させることができる。スポーツ番組（ＥＳＰＮのコンテンツなど）が視聴者の環境で検出され、ユーザーがニューヨークタイムズのウェブサイトに移動すると、同社のウェブサーバーがスポーツニュースを目立つように表示することができる。これと同様に、テレビ番組「ＷａｓｈｉｎｇｔｏｎＷｅｅｋ ｉｎＲｅｖｉｅｗ」がユーザーの環境で再生されている場合、ニューヨークタイムズのウェブサイトは、ユーザーが最初に開くページに国内ニュースを目立たせることができる。

これは、従来のｃｏｏｋｉｅを使用して実装する必要はない。他のデータ交換アレンジメントも活用できる。データ交換アレンジメントのひとつが、ＨＴＴＰパケットのヘッダーデータである。ヘッダーデータは、ニューヨークタイムズのウェブサイトに送られ、ページをロードするように依頼する。ヘッダーデータはすでに、ユーザーがそこから移動したばかりのウェブサイト（参照ページ）を特定するデータなど、多様な情報を運んでいる。ユーザーの環境で現在再生中のテレビ番組を特定するデータを運ぶこともできるので、情報を受ける側のウェブサイトは、データに従ってそのコンテンツを変化させることができる。

本実施形態では、他の場合と同様、テレビ番組を特定するデータはあらゆる形式を取ることができる。ＩＳＡＮ識別子、時間／チャンネルデータ、音声データなどを含む、リモート検出器が透かしまたはフィンガープリントデータ、復元した透かしデータまたはフィンガープリントデータ、ＴｉＶｏシステムのＥＰＧ座標、テキストタイトルデータ（ＥＰＧのものなど）等を認識できるものなどがその例である。

（有機的に編集された番組ディレクトリ）
番組ガイドの概念は古く、テレビの黎明期、そしてＴＶガイド誌の創刊にまで遡る。ＴＶガイド誌には格子上の構造が用いられ、列には時間（通常は３０分間隔）、行にはチャンネルが表示されている。

多数のチャンネルを特徴とするケーブルネットワークの開発により、この格子型の形式は変化し、スクロールできる画面上のガイドに変化した。これは、この目的のためだけに、ケーブルチャネル上に元々は配信されていた。

その後、この分野には数多くの技術開発が進められたが、時間／チャンネルの格子型の形式は定着している。

ＴＶガイド誌、および後の電子版の番組ガイドのスケジュールデータは、伝統的に多大な労働力を要するプロセスにより作成されている。ＴＶガイド誌、そして後にはＴｒｉｂｕｎｅＭｅｄｉａ Ｓｅｒｖｉｃｅｓの事務員がテレビネットワークおよび個別のテレビ局に定期的に電話をかけ、次週の番組放送スケジュールに関する情報を取得した。土壇場で番組が変更される場合（これが起こることはやむを得ない）、番組ガイドは誤った情報を記載することとなった。

本技術の態様に従って、発明者は番組をチャンネルに介在させることをやめる時期が来たと確信している。消費者はディスプレイ画面を所有しており、そこでコンテンツが好きなように表示される（ＴＶ放送、ケーブル、ウェブストリーム、ｉＴｕｎｅｓ、ＮｅｔＦｌｉｘ、ピアツーピアネットワークなどを問わず）。体系化した原理としてのチャンネルは、時を経てその有用性を失っている。（チャンネルを参照することでコンテンツを特定することは、自宅のドアに郵便物を配達する郵便局員の名前を参照して郵便物を特定することと等しい。また、インターネットのノードを通じてデータの伝送経路を参照することでウェブページを特定することと等しい。）コンテンツがどのように消費者の画面に到達するかは、二次的な関心事項にも満たない。

この技術の態様を実装した実施形態は、コンテンツが利用可能な複数の代替ソースを詳細に明記する番組中心のディレクトリを参照することができる。消費者は、希望のチャンネルを指定する代わりに希望の番組を指定する。自動化システムはディレクトリを参照しながら、利用可能なソースの中から選択し、希望するコンテンツを画面上に表示する。消費者が関与する必要はほとんどない。

特定の実施形態では、システムはユーザーの嗜好およびプロフィールデータを組み合わせた経験則および規則の蓄積を採用し、異なるソースからコンテンツを選択する。ユーザーは、ストリーミングからコンテンツをダウンロードする、有償ではなく無償コンテンツ、コマーシャルなし、１０２４ｘ ７６８以上の解像度、無許可のソースを配信しないなど、好みや要件を表明する。このような嗜好の一部は、すべてのコンテンツタイプに適用できる。そうでない場合は、特定のコンテンツのタイプに適合させる（劇場映画およびスポーツ、１０２４ｘ ７６８以上の解像度を希望する、放送中のイベントおよびコメディ、７２０ｘ ４８０以上の解像度を希望する、有償コンテンツ、コマーシャル不要など）。嗜好／要件は、特定の順番で適用することができる（可能であれば、常にユーザーの第一嗜好を実行する。その嗜好を満たすことで、他の嗜好が満たせなくなることも問わない、など）。代替手段として、さまざまな相対的な重要度に嗜好を一致させることができる。最終的な選択は、すべての関連する嗜好と重要度を考慮し、各代替案が全体のなかでスコア付けされた後に行われる。

規則／経験則がユーザーに意思決定を委ねる場合がある。たとえば、規則により、０．９９ドルを超えるコンテンツの支払いを自動的に承認しないことを規定できる（劇場公開から２週間以内の映画の場合、２．９９ドル）。次に、ユーザーは電話または別のＵＩを通じて、支払いを認証するか指定することができる。

別の場合では、ユーザーは好みのプロバイダの注文一覧を指定することができる。Ｈｕｌｕから取得する（利用できる場合）、でなければＹｏｕｔｕｂｅから取得する（利用できる場合）、でなければｉＴｕｎｅｓから取得する（利用できる場合）、でなければユーザーにオプションを提示し、手動で選択してもらう。

図５はテレビ番組 Ｄａｉｌｙ Ｓｈｏｗのエピソードに対応するデータベース記録を示している。ここで示すデータ構造は、番組に関する情報を与え、番組を視聴できるさまざまなソースを一覧表示する。ウェブソースの場合もあれば、ＴＶソースの場合もある。Ｐ２Ｐネットワーク（Ｌｉｍｅｗｉｒｅ）からの場合もある。

一覧表示された各コンテンツアウトレットに付随するのは、コンテンツに関する追加情報（メタデータ）であり、そのアウトレットが使用する識別子（Ｈｕｌｕの場合７７９７３）、コンテンツのＩＳＡＮ番号（利用できる場合）、アウトレットから利用可能なコンテンツに関する情報などがある。

アウトレットによっては、利用可能な情報はコンテンツが「オンデマンド」で利用可能であることを示す。この情報はさらに、そのアウトレットからコンテンツが最初に利用可能になった日時を指定することも、利用できなくなる予定日時を指定することもできる。

たとえば、サンプルＤａｉｌｙ ＳｈｏｗのエピソードがＣｏｍｅｄｙ Ｃｅｎｔｒａｌ（番組の当初の配信ネットワーク）で視聴可能になるのは当初の放送日時（つまり６月１５日の午後８時）であり、当初の放送から５週を経過する前の日曜日の深夜まで視聴できる。番組のコピーはＨｕｌｕに提供されるが、１時間は放映が禁止される。つまり、午後９時まではそのソースから視聴することはできず、視聴できるのは３０日間に限定される。

テレビ放送の場合、データ構造は任意の長さのリストに対するポインタを含み、当初の放送およびすべての計画された番組の再放送を詳細に記述する。従って、ＣｏｍｅｄｙＣｅｎｔｒａｌのＴＶ番組は、当初の午後８時の放送時間に放映され、その後１０時半、翌朝７時半などに再放送される（表示したデータ記録では、すべての時間は太平洋標準時である）。

図５の情報を含む同一のデータベース、あるいは他のデータベースには、テレビネットワークとチャンネルをマッピングするデータ構造が含まれる。たとえば、ＣｏｍｅｄｙＣｅｎｔｒａｌのチャンネル番号はＤｉｓｈ Ｎｅｔｗｏｒｋでは１０７であり、Ｃｏｍｃａｓｔでは５５である。このような情報を参照することで、ユーザーのシステムは希望の番組を異なる配信システム上で配置することができる。

図６はソースデータの収集方法を示す。コンテンツ作成者は、どこに配信されてもコンテンツからデジタル処理で抽出できる、固有の識別子を備えたコンテンツの各項目を提供する。デジタル透かし技術が好ましいが、フィンガープリント照合も使用することができる。識別子はデータベースにコンテンツのメタデータと共に保存される。次に、そのコンテンツはテレビネットワーク、ウェブサイトなど、１つ以上の受信者に配信される。

コンテンツの受信者は透かし（またはフィンガープリント、あるいはその両方）検出器（図６で三角形で表示する）を搭載し、コンテンツ固有の識別子を読み取り、報告を発行してデータベースに返す。（Ｄｉｇｉｍａｒｃの特許公開番号２００７２０８７１１などから、このような透かし／フィンガープリント検出器に関する追加情報を参照のこと。）各受信者は、受信者を特定する情報、たとえば使用目的の明細などを報告に加えることが望ましい。これらの明細には、スケジュールデータ（コンテンツの放送日時、ウェブからダウンロード可能になる日時、利用できなくなる日時など）を含むことができる。他の情報を含むこともできる。たとえば、コンテンツを視聴できるフォーマット、受信者のシステムがコンテンツに割り当てた識別子など。従って、データベースにはコンテンツの保存場所と共に、その他の受信者が与える情報すべても記録される。

認定配信者のコンテンツ取り込みポイントに検出器を配置することに加え、検出器（図６の三角形）を別の場所に置き、意図しない配信先に情報が漏れるような場所でそのコンテンツを特定することもできる。たとえば、個人がウェブサイトからコンテンツをダウンロードし、それをＰ２Ｐネットワークサイトに再投稿する場合がある。インターネットのノードの検出器はＰ２Ｐのトラフィックを感知し、Ｐ２Ｐネットワークをコンテンツの代替ソースとして特定する情報をデータベースに提出することができる。

図７はコンテンツ作成者（映画スタジオなど）のプロセスの一部をより詳しく明記する。このコンテンツは元々映画またはデジタル取り込みにより作成されたものである。製作チームが下見フィルムを見直し、編集が行われる。コンテンツが映画を元にしたものであれば、映画をスキャンしてデジタル形式にする。

次に、コンテンツは、スタジオが割り当てた識別子によりデジタル透かしを付与される。（アレンジメントによっては、下見フィルムの作成時など、これより前にコンテンツに透かしを付けることがある。）透かし識別子は、スタジオのデータベースにコンテンツのメタデータに関連付けられて保存される。（代替手段として、あるいは追加手段として、フィンガープリントデータをコンテンツから抽出し、関連付けられたメタデータと共にスタジオのデータベースに同様に保存される。）映画の印刷物およびデジタル映画のファイルが作成され、配信される。

コンテンツ作成プロセスは、劇場用公開資料の作成で終了ではない。何十ものその他のカットまたはコンテンツの形式、またはその両方が作成される。例を挙げれば、テレビ（標準画質と高画質の両方）、映像オンデマンド、飛行機での上映、ＤＶＤの発売、ＭＰＥＧ２、ＡｄｏｂｅＦｌａｓｈ、Ｗｉｎｄｏｗｓ Ｍｅｄｉａ Ｆｏｒｍａｔなどを含む多様なフォーマットでのウェブビデオなどがある。コンテンツは外部のコード変換会社（Ｒｈｏｚｅｔ／Ｈａｒｍｏｎｉｃなど）に送られ、さらに他のフォーマットでファイルが作成されることもある。

透かしデータを追加し、連続的な層を形成できるような多様な透かしがあれば望ましい。このような場合、コンテンツが変更されるたびに、次の異なる透かしが適用される。これらの識別子も同様に、スタジオのデータベースに他の関連情報（カットおよびフォーマットに関するものなど）と共に保存される。

通常、スタジオのデータベースには大量の機密情報が含まれる。そのため、公に配信するために適したデータの一部（番組タイトル、あらすじ、上映時間、透かし／フィンガープリント情報など）が異なるデータベースに送られる場合がある。図７は、これを番組ディレクトリデータベースとして示したものである。これは図６のデータベースであり、コンテンツが利用可能となるすべてのソースを特定する報告を収集する場所である。これは業界団体（ＭＰＡＡなど）または契約サービスプロバイダ（ＳｅｃｕｒｅＰａｔｈなど）が管理する場合もある。

他の配置では、適した保護メカニズムにより、限定的な目的を持つ部外者にのみ、スタジオの内部データベースの一部へのアクセスを許可することができる。このような場合、図６のデータベースは多様な部分からなる連合データベースで構成され、異なるスタジオおよび別のコンテンツ作成者が維持を担当する。外部データベースと内部データベースを組み合わせて使用することもできる。

図８はコンテンツ配信元（テレビネットワークの配信会社、ＣＢＳなど）の視点からシステムを詳しく記載したものである。コンテンツはメタデータと共に映画スタジオから配信会社のコンテンツ取り込みサーバーに到着する。メタデータ（通常、ヘッダーデータなどの「帯域外の」情報または添付ファイルである）はコンテンツのタイトル、あらすじ、上映時間、フォーマットの明細、ファイルサイズ、公開日を詳細化する。コンテンツおよびメタデータの両方が、ネットワークの内部デジタル資産管理システムに登録（「チェックイン」）される。

ネットワークは、内部の管理情報を詳しく記述する独自のメタデータを、チェックインしたコンテンツに関連付けてデジタル資産管理システムに追加する。独自のメタデータには、コンテンツの放送予定日時、ウェブ公開予定日時、社内識別子などを含む。

コンテンツ作成者との契約上の要件（配信契約の一部として、など）を遵守するため、チェックインプロセスの一環として、コンテンツ配信元は内部データベースで認証し、保存したメタデータの少なくとも一部（スケジュール情報を含む）を番組ディレクトリデータベースに送る。メタデータはそこでコンテンツに関連付けられて保存される。

同様に、先だって提供された情報が変更された場合、または新しいスケジュール情報が有効になった場合（追加放送日、コンテンツがウェブから削除される予定日など）には、契約上、コンテンツ配信元は番組ディレクトリデータベースをコンピュータ上で更新することが求められる場合がある。

このようなアレンジメントにより、コンテンツが最初に作成され、次に配信され、変更が発生するたびに異なる組織が情報を与えることで番組ディレクトリデータベースは有機的に成長する。予定されたコンテンツ配信元から離れた監視ノードが与える情報により、番組ディレクトリデータベースが補完されることで、多様なソースが配信するコンテンツの視聴可否かに関する、圧倒的な情報の集まりとなる。そして、これらの情報はすべて自動的に編集される。さらに、既知の電子番組ガイドでは翌週または１０日間の視聴情報を記載することが一般的であるが、これをはるかに超える期間の視聴情報を詳しく記載する。

コンテンツのアウトレットがコンテンツを受信しても、その時点では配信スケジュールが決定していない場合がある。それでもなお、コンテンツはアウトレットのコンテンツ取り込みポイントで透かし／フィンガープリント検出器により検知され、そのアウトレットで保管されているコンテンツの記録（および検出日時）を番組ディレクトリデータベースに入力することができる。

このような番組ディレクトリデータベースは、本明細書の別の場所でＥＰＧ用に説明した方法で活用することができる。たとえば、携帯電話のアプリケーションでデータベースを検索して希望するコンテンツを探し、それをダウンロードするスケジュールを立てることができる。ユーザーが興味のある番組をサンプルとして抽出すると、データベースを少し調べるだけで、番組の完全なコピーを視聴できる多数のアウトレットとスケジュールを瞬時に示すことができる。番組全体のダウンロードは、その場で行うことも、後にスケジュール化することもできる。

ユーザーは、『Ｆｒｉｅｎｄｓ』や『Ｈｏｕｓｅ』などのシリーズ番組の特定のエピソードなど、すでに見た番組に遭遇する（およびユーザーの携帯電話が抽出する）ことがある。番組を特定する携帯電話のソフトウェアアプリケーションは、番組ディレクトリデータベースまたは別の場所から、サンプルとしたシリーズ番組の全エピソードを呼び出し、その一覧を（番組のあらすじと共に）ユーザーに提示することができる。ユーザーは現在再生しているエピソードを視聴したいと思わないかもしれない（すでに視聴したので）が、同一のシリーズ番組のエピソードでまだ視聴していない１つ以上のエピソード（再放送のエピソード、未放送のエピソードを含む）については、視聴する、または後でダウンロードすることを選択する場合がある。従って、再放送番組に当たった場合、同じシリーズの別のエピソードを見るようにユーザーに手配を促すことができる。番組ディレクトリデータベースはこのときに視聴する別のエピソードを特定し、探すことを容易にする。（一部の実施形態では、ユーザーがダウンロードし、視聴した、シリーズ番組のエピソードすべてを特定するファイルを編集することができる。これは、連続テレビ番組の中で、まだ見ていないエピソードを特定する準備ができている参照先として機能できる。）

ＥＰＧの既知のユーザーインターフェースのパラダイムを、ここで説明する番組ディレクトリデータベースに結び付けて導入することができる。たとえば、ユーザーは特定の番組またはジャンルをお気に入りとして特定することができる。このような番組は、ユーザーがカスタマイズしたデータベースコンテンツの表示で、より目立つように特徴付けることができる。

ユーザーインターフェースによっては、視覚的なアイコンまたはサムネイルを番組に付け、それらの番組をアイコンで表示することができる。主題は一貫しているがバージョンが違う番組を導入し、ウェブベース、ストリーミング、ダウンロード、課金型、高画質など、コンテンツの視聴可否の多様な形態を示すことができる。たとえば、すべて同じ基本的な絵を使用したアイコンを特定の番組に使用し、縁取りのスタイルを変えることで、番組のバージョン違いであることを示すことができる。このようなアイコンは、異なる番組に対応するフォルダで整理される。特定の番組のフォルダにも、このような番組に関連付けられた補助コンテンツ示すアイコンを含むことができる（登場人物の情報、ＮＧ集、スタジオ観覧チケットの獲得を目指すコンテスト、ウィジェットなど）。本明細書の別の場所で説明したとおり、ユーザーは番組に意見を提出する機会が提供される（構想の決定、登場人物の行動および動機付けに対するものなど）。そのため、番組フォルダにはこのような意見を提出するためのアプリケーションを起動するアイコンをひとつ以上含むことができる。

同じコンテンツに異なるフォーマット化を行ったバージョンは、単一の番組入力の元（フォルダとして表示されるなど）、ユーザーに表示されたとおりに番組ディレクトリデータベースでひとつにまとめることが望ましい。（現在のチャンネル中心型ＥＰＧ表示とは異なり、ＥＳＰＮおよびＥＳＰＮ−ＨＤなどのように、同じ放送の高画質版と標準画質版という完全に異なる入力がユーザーに表示されない場合がある。）

番組ディレクトリデータベースのコンテンツがユーザーに表示されるユーザインターフェースは、ユーザーが定義したお気に入りフォルダに加え、特別番組、最新のニュース速報、専用のフォルダはないがユーザーが興味を持ちそうな他の番組のフォルダを含む場合がある。

実施形態によっては、番組ディレクトリデータベースの情報は正確さのため、定期的、または継続的に確認される。たとえば、Ｎｉｅｌｓｅｎが提供するモニタリングサービスでは、現地のテレビチャンネルをサンプリングし、番組が示されたスケジュール通りに視聴できているかを確認する。もし視聴できない場合、データベース記録にエラーの可能性ありとフラグが付けられ、追跡活動を実行し、ディレクトリ内の他の関連する誤りを是正し、同様のエラーが再発しないことを確実にする。このようなモニタリングサービスは、ウェブ上でのコンテンツの視聴可否についても同様に確認できる。番組ディレクトリデータベースで特定のコンテンツを所有することが示されているウェブアウトレットで、そのコンテンツが視聴できなくなったことがわかったら、それに応じてデータベース記録を修正することができる。

透かし／フィンガープリント検出器を、公的なコンテンツのアウトレットではなく、コンテンツ配信ワークフローの別の場所に配置することができる。たとえば、コード変換、字幕、ＤＶＤ認証サービスを提供する会社は、その取り込みサービスに検出器を使用し、コンテンツの受信時にそのコンテンツを報告することができる。これらの報告は番組ディレクトリデータベースで記録されるが、これらの報告へのアクセスはコンテンツの元の作成会社（スタジオなど）に限定される。代替手段として、このような検出器はコンテンツの元の作成者のプライベートデータベースに、このようなコンテンツを報告することができる。

さらに別のバージョンとして、ユーザーの携帯電話から、番組ディレクトリデータベースに提供するコンテンツ報告を生成することができる。たとえば、インターネットを閲覧しているユーザーが特定のソーシャルネットワークウェブサイトからＦｒｉｅｎｄｓのエピソードをたまたま見つけた場合、この事実は番組ディレクトリデータベースに報告され、そのウェブサイトをこのコンテンツの代替アウトレットとして追加することができる（すでに記載されていなければ）。同様に、ユーザーが（上述のとおり、ソースＩＤおよびタイムスタンプにより透かしエンコードを行うことができる）テレビ放送を抽出した場合、コンテンツが透かしまたはフィンガープリントにより特定され、この情報が番組ディレクトリデータベースに報告され、データベースの精度の確認と視聴者調査目的のいずれかまたは両方が行われる。

（没入型コンテンツ）
近年、テレビ番組は、過去数十年来の『くつろいで見る』受け身の娯楽から、『前のめりで見る』娯楽への転換期を迎えており、ジェリー・スプリンガーの挑戦的な番組のように、視聴者をしてほとんどテレビに向かって叫ばせるほどになっている。

さらに、いくつかの新興技術によって、３Ｄテレビの到来が約束されており、視聴者はさらにテレビに釘付けになりそうである。しかし一方では、頭痛を引き起こしたり、てんかんの発作を誘発したりといった、ユーザーの実体験上の現実的な問題によって、そのような身体的な没入体験の可能性は、実質的には制約を受けそうである。

本技術の出願人が好ましいと考えるのは、３Ｄその他の仮想現実体験がもたらす現実感の喪失は経験させずに、ユーザーにより大きな没入感を与え得る技術である。

本技術におけるこの側面によって、ユーザーは、主として関連する携帯電話アプリケーションが提供するユーザーインターフェースを通じて、テレビその他のコンテンツ番組において、登場人物、筋書きおよび背景に、直接参加式に参画していくように仕向けられる。

ある特定のアレンジメントにおいては、視聴者が集団か個人かを問わず、番組が視聴者からの影響を受けるという側面がある。例えば、ユーザーは、特定の個人プロファイル情報を、自らの携帯電話からコンテンツの作成者または配信元に対して、開示することを選択できる。その情報により、ある特定の番組が、トラックのオーナー(またはワインの愛飲家)から非常に高い視聴率を稼いでいることが分かった場合、トラック会社(またはワインブランド)は、その番組の制作および/または広告スポンサーとして特別な扱いとなり、番組のコンテンツやＣＭは、そのような視聴者に対応して形作られていくことになる。このような適合化が、ほとんどリアルタイムで生じる事例もある。例えば、現時点のコンテキストに基づいて、広告が動的に挿入される例である。Googleの AdWordsが、ウェブの検索結果に広告をマッチさせるのが、ちょうどこれにあたる。その他のアレンジメントにおいては、視聴者のプロファイル情報は、番組脚本家に提供され、その情報は、筋書きその他の番組の内容を、そのユーザーのプロファイル情報に適合させるために用いられる。

バドワイザービールの愛飲家の視聴率が高い番組の場合、ミラー・ビール会社は、番組中の販促のために、喜んで割増広告料を支払うだろう。

テレビやオンラインのコンテンツは、World of Warcraftなど、多人数参加型のオンラインロールプレイングゲーム(MMORPGs)から学ぶところが多いかも知れない。それらのゲームでは、プレイヤーを集めたチーム(『ギルド』)が、才能、ツールその他の資質を集合的に共有し、それがチームの成否を左右することになる。エンターテインメントコンテンツの視聴者についてもどうようである。視聴者の集合的な構成および特質を活用して、コンテンツの筋書き、登場人物に対する動機づけおよびその成否、広告などに影響を及ぼすことができる。

異なる視聴者が、番組の配役において、異なる登場人物に自らを結びづける。例えば、Friendsという番組において、ある視聴者はPhoebeに、また別の視聴者はMonicaに、さらに別の視聴者はChandlerに、他の視聴者はRossにといった具合に、自らを重ねて、自らの携帯電話のユーザーインターフェースを通じ、情報を入力したとする。すると、それぞれの番組キャラクターは、ある点においては、視聴者の代役として、その点に対応する視聴者の一面を演じることができるのである。視聴者が提供できるのは、提案、忠告、決断などであり、それらが登場人物の反応に影響を及ぼすか、あるいは筋書きの紆余曲折を引き起こす。(視聴者は、Chandlerに対し、彼がMonicaに求婚するのはまだ早い、と呼びかけることもできる。)

ある特定のアレンジメントにおいては、番組の最初の製作段階で、代わりの筋書きをいくつか用意しておくことも可能である(子供向け図書のChoose Your own Adventureシリーズは、これと同じことをやっている)。携帯電話を通じて表現される視聴者の感情に基づいて、筋書きは異なった展開を見せて進むかも知れない(例えば、番組のそれぞれ異なった場面において、複数の局面が撮られており、そのうち一つが流されるなど)。

また別のアレンジメントにおいては、視聴者からのフィードバックが番組制作者に提供され、そのようなフィードバックに基づいて次回のエピソードの筋書きが仕立てられる。

時に視聴者は、番組のそれぞれの登場人物について判定を行う機会を与えられることもある。例えば、The Moleという番組では、共通の目的のために登場人物が配役されているが、その中には、妨害工作を行う二重スパイが含まれており、彼はグループを欺くために、正体を隠していなければならない。各エピソードの最後において、視聴者は、誰がスパイであるかについての自分の判定を投票することができる。視聴者の票が最も少なかった登場人物は、次回のエピソードの配役から外すこともできる。

さらに別のアレンジメントにおいては、実際の登場人物や生放送に対して、視聴者からのフィードバック、手がかり、動機づけ、または指示がそのまま伝えられ、それに対応した演技が行われることになる。ある生のお笑い番組では、視聴者が提案する内容や課題が、即興的なコメディ寸劇の題材となり、コメディの本篇後に数分間、それらの提案された寸劇が編集されて演じられる。

Broadwayの素晴らしい俳優たちは、それぞれのパフォーマンスにおいて、そこに訪れるある特定の観客に対してのみ反応してしまう感覚について語っている。リリー・トムリンのようなコメディアンは、自らのパフォーマンスを、目の前の特定の観客に対してあからさまに順応させてしまう。携帯電話のインターフェースは、それほどの即時性や親密性を提供するものではないが、視聴するユーザーに見合ったパフォーマンスを実現するための、大きな躍進のステップとなり得るものである。(加速計、磁力計、マルチタッチのユーザーインターフェースなどを装備する携帯電話は、フィードバックを提供する能力において、テレビやリモコンなどの過去に出回っている他のデバイスよりもはるかに優れている。)それによって、台本に書かれた要素と視聴者に依存する要素の両方を組み入れた、電子コンテンツの新たなハイブリッドが実現可能になる。

番組作りが完全に統一されたものになればなるほど、番組の筋書きやコンテンツを即座に作り込み、ユーザーのフィードバックを反映させることが容易になる。つまり、コンピューター生成画像の映像で作られた番組の方が、生身の俳優や物理的なセットの番組に比べて、リアルタイムの視聴者提案に基づいた、よりダイナミックな筋書きを構築できることになる。(例：Chandlerのようなキャラクターが、Monicaのようなキャラクターにプロポーズしようと向かった途中で地下鉄に乗り遅れ、夜になって彼女が帰ってしまった後にようやくたどり着くという羽目になる―これはすべて視聴者提案によるCGI台本に基づく筋書きである。あるいは、多くの視聴者メンバーが携帯電話を動かす方向ｋによって、アクション系の登場人物が次に手を伸ばして掴むのが、左の腰にある剣なのか、右側にある杖なのかが左右される。)人気アニメ制作会社のPixarは、非常に長い時間をかけてアニメ化およびレンダリングを行うが、テレビや携帯電話の画面に必要とされる解像度はそれよりもっと低い。ムーアの法則に従い、処理能力が引き続き飛躍的に向上していくとすれば、視聴者反応型のアニメおよびレンダリングも実現化される。

いくつかのアレンジメントにおいては、全部または一部の視聴者からの入力内容に基づいて確立された行動や動機づけを有するアバターが、1名または複数名番組に登場する。(例：南北戦争での戦いをフィーチャーしたコンテンツには、南部の視聴者からの入力内容に対応して、南部連合軍のヒーローであるアバターを登場させることもできるし、北部からの入力内容に対応して、北部連邦軍のヒーローのアバターを登場させることもできる。)

(動機づけのコントロールについては、すでに言及されている。たった一つの動機づけが、その結果として、幾通りものアクションを決定付けることがある。例えば、あるヒーローの動機づけが、命を賭してでも乙女を救い出すことだったとしても、次のシーンで続くアクションは論理的には無数にある。また、そのヒーローの動機づけが、ライバルを倒し、それを語り継ぐために生き延びることだったとしたら、さらに異なる種類の無数のアクションが論理的に可能である。状況によっては、キャラクターの動機づけに関する視聴者の入力を受ける方が、個々のアクションに関して視聴者の入力を受けるよりも望ましいこともあるかも知れない。)

参加している視聴者の名前および/または位置を、そのコンテンツ入力と一緒に提供することも可能である。番組において、そのような名前を物語に組み入れることもできる。(例：Monicaのアパートに到着した際に、Chandlerに次のように言わせることもできる。「エレベーターで上がってくる時、Tonyという奴と一緒だったよ。ポートランドから来たんだってさ。僕のオーラが見えたらしいよ。不安定に見えたって言ってたな。僕のオーラは不安定だと思うかい？」) また、参加視聴者からの入力によって、サブプロットが展開していくこともある。

視聴者のアバターが番組に登場している場合、参加視聴者メンバー間で最も一般的な名前をそれに付けることもできる。これにより、コンテンツに対する視聴者の親近感が増す。あるいは、他の方法でアバターに名前を付けることもできる。例えば、質問に正解した最初の視聴者の名前などである。また、視聴者メンバーの名前をとってアバターを名付ける代わりに、何かしらの競技に勝った視聴者メンバーに対して、彼または彼女の好きな名前をアバターに付ける特権を与えるというやり方もある。

視聴者が回答可能な修辞的疑問、または登場人物同士の問いかけを台本に盛り込んで筋書きをつくることもできる。(「明日のChandlerとのデートにこの赤いドレスを着ていくべきかしら。ちょっと過激かも知れないけど」。)視聴者の反応次第では、彼女は赤いドレスを着るかも知れないし、着ないかも知れない(そして彼女は、決断に際して「Tony」からのアドバイスを信頼するかも知れない)。

場合によっては、視聴者は声(音響)による指示、またはその他の音響による入力を提示することもできる。そのような音響による入力は、コンテンツのサウンドトラックに組み込まれ、視聴者の参加意識をさらに高めることになる。(人混みのシーンのサウンドトラックは、視聴者メンバーたちが、自らの携帯電話を通して送ってくる何十または何百という音声トラックの重ね録りによって構成することが可能である。)

当然ながら、その提案内容が物語の展開に採用された(またはその音声が盛り込まれた)視聴者メンバーは、自らがそれに参画していることを誇りに思うだろう。それによって、彼または彼女は、オフィスでの井戸端会議などで自慢話をする権利を与えられたことになる。

本技術の別の側面によれば、古代ローマで剣闘士の勝敗を示すために用いられた『サムアップ』または『サムダウン』の合図を、携帯電話を用いて出すことも可能である。しかしこの場合、判定を下すのは、皇帝の代わりに、集合的な視聴者ということになる。

この『サムアップ』または『サムダウン』の合図は、電話が正しく上を向いている時にそれを振る、または電話が下を向いている時に振る、もしくは他の手振りや動作を行うなど、様々なユーザーインターフェースの制御方法を用いて、入力することが可能である。

ある視聴者が、ゲーム番組の一番手の出場者に支持を示す合図を送り、二番手の出場者に不支持を示す合図を送れば、番組プロデューサーが最初の出場者を勝たせる可能性が、より高まるかも知れない。

動作によって携帯電話に合図をインプットし、筋書きを展開させていくという使用法は、劇場でのアクション映画上映の際などの大観衆の場において、素晴らしい効果を発揮し得る。観客は、剣でそうするように、突いたり刺したりする動作をして、ヒーローがスクリーン上の悪者を倒すのを助けることになるかも知れない。ここでも、観客の参加によって、異なる結果を生みながら戦いを展開させていくことができる。(例えば、予め制作されている二種類のエンディングのうち、どちらか一方を選択する、または、即座に画像処理された別のコンピューターグラフィックスのシーケンスを映し出すなどである。)

また別の側面では、携帯電話は、コンサートのような生演奏会場での入力装置として活用される。観客は、演奏者に対して、演奏して欲しい曲を携帯電話で知らせることができ、アンコール曲を提案することもできる。コンサートの主催者は、そのような情報入力を可能にするソフトウェア・アプリケーションをリリースし、その機能を有効にする目的で、ユーザーに対してeメールアドレスの提供(およびその他のデモグラフィックデータの随意提供)を求める可能性もある。もちろん、そうすることによって、もちろん催者は貴重なマーケティング資源を獲得することになる。観客がコンサートの演奏者との一体感を示すために灯すライターの炎は、コンサートの観客の持つ携帯電話画面の光に置き換わるかも知れない。

さらに別の側面においては、上述した特徴(例えば、ユーザーの入力情報をコンテンツのプログラミングに反映させること)は、他のルートに行くデータによって、さらに完全なものになり得る。すなわち、コンテンツ番組からユーザーの携帯電話へ、というデータの流れである。コンテンツには電子透かしやその他の符号化されたデータが含まれることがあり、それらはユーザーの携帯電話とコンテンツの同期動作の引き金となる。これには、本明細書に詳述され、かつ参照としての組み込まれた、様々な形式の補助コンテンツが含まれることもある。ユーザーによる入力が、コンテンツにおいてそれに反応するアクションを誘発し、それがさらに補助にコンテンツにおいて、それに反応するアクションを引き起こし、それらのアクションが行きつ戻りつするという、相互作用が発生することもある。

前述のようなアレンジメントによって、ユーザーは、コンテンツの展開に伴い、自らがそれに入り込み、その行為や見解は、番組の動向および筋書きの展開に影響していくことになる。過去数十年来の、受け身的な、くつろいだ視聴スタイル、または、いくつかの現行番組がもたらした、テレビに吠える視聴スタイルに代わって、視聴者は、今までにない方法によって、番組に対する支配権を掌握している。つまり、携帯電話を用いた身振りその他の交流方法によって、より全面的な参画体験、そして没入体験を味わっている。

（画面切替）
本技術のさらに別の側面に従えば、ユーザーは極めて単純な方法で、小さな画面(例えば携帯電話画面)から手近な大画面(例えばテレビ画面)へのコンテンツの切り替え、またはその反対の切り替えができる。

ある形式において、この方法は、移行先の画面に指示を送ることによって、現行の画面で現在進行中の体験をユーザーがそのまま継続できるようにするユーザーインターフェースのコントロール機能を含む(例：娯楽コンテンツのレンダリングなど)。ウェブコンテンツに対しては、YouTubeからの映像ダウンロードのように、例えば、映像およびバッファ・コンテンツの中の現行ポイントの詳細などの、映像再生アプリケーションの状態データとともに、携帯電話からウェブサイトにポインターを送る。映像ゲームに対しても同様に、現在の状態を示す情報を、携帯電話からテレビ型コンピューターのプロセッサーに送ることができる。これにより、現在の状態からの再始動が可能になる。

いくつかの実装においては、Bonjourプロトコルを使用することで送信が有効となるものもある。これにより、受け側のプロセッサーに対して、送信に利用できる情報を伝達し、その受け側のプロセッサーが情報を引き継ぐように誘導するのである。

いくつかの例においては、表示中の画面から別のデバイスの画面にコンテンツを『プッシュ型』配信するよりも、むしろ送り先デバイスと現在表示中のデバイス間での通信を可能にすることで、コンテンツの『プル型』配信を行う。
他のアプリケーションにおいて、最初に表示されるコンテンツは、Javaアプリケーションのコントロール下にある場合がある。例えば、BlueRayディスクと共に提供されるBDJアプリケーション、またはケーブル会社の双方向サービスにより提供されるTru2Wayアプリケーションなどである。そのようなコンテンツを別の画面に表示させるには、受け側のコンピューターにも対応するJavaアプリケーションを導入し、送信が必要となる時点で、その実行状態を、送信元コンピューターの実行状態に基づいて初期化する。

そのようなJavaアプリケーションは、視聴者がゲーム番組を楽しめることができるプログラムである。ゲーム番組には、例えばWho Wants to Be a Millionaire(出場者は、２倍の賞金か、もしくは賞金無しの回答をするための質問数を選択する)や、Dealor No Deal(出場者は、全体の賞金額が分かっている一群の箱の中から、賞金額の分からない箱を一箱選ぶ。それ以外の箱の中身は引き続き暴露されていき、消去法のプロセスの中で、選んだ箱の中に賞金が入っているかどうか分かってくる。消去法のプロセスが続いている間、親は金額が変動する現金取引を、その出場者に対して持ちかける)などがある。

そのようなコンテンツ番組を見ている視聴者は、(例えば、本明細書の他の部分で述べられているアレンジメントを用いた補助コンテンツとして)そのゲームのJava対応版を受け取るかどうか選択することができる。そのJavaバージョンは、放映中のエピソードに特有のパラメーターを用いてロードされる(そして定期的にアップデートされる)。エピソードの途中のどの時点においても、視聴者はゲームの通常の展開を停止させ、Javaアプリケーションを用いたゲームを最後まで試してみることができる。そして視聴者は、彼または彼女のゲームの結果と、テレビ放映された出場者の結果とを比較してみることができる。

(番組のオリジナルコンテンツは、Javaバージョンが起動された時点で、自動的に停止させることもできる。)停止に際しては、TiVoの停止オペレーションが採用され、配信中のコンテンツをローカルディスクまたはリモートディスクに一時バッファすることができる。また、オリジナルゲームを、ケーブルまたはオンラインをソースとするオンデマンドモードで配信することも可能である。この場合、タウンロードの流れを停止させる指示を出すだけで、簡単に停止作業は完了し、後から再開させることもできる。

もう一つの事例として、家庭用ＰＣでWorld of Warcraftをプレイしていて、その後バスに乗ってからもそのゲームを続けたいと思っている人のことを考えてみよう。ユーザーの携帯電話上で、コンテンツ転送のユーザーインターフェース制御の操作を行うことにより、ゲームの状態情報はその電話に転送され(その時点でまだ提供されていなかった場合はゲームソフトウェアも一緒に送られ)、プレイヤーは、小さな画面でゲームの続きを再開することができる。

また、大画面でゲームをプレイ、またはコンテンツを視聴している人の携帯電話に、友達からコンテンツ(例えば画像)が送られてきたと考えてみよう。送られてきたコンテンツをじっくり見るために、ユーザーは携帯電話のインターフェース(または大画面のインターフェース)のコントロール部を操作し、大画面のコンテンツを自動的に停止させ、その代わりに携帯電話に送られてきた情報を大画面に表示することができる。大画面で画像を閲覧してから、友人にコメントを返信するために、ユーザーはメッセージ用アプリケーションを、大画面のまま起動させることができる。UIコントロールの別の操作を行うことで、オリジナルコンテンツの大画面での表示を再開できる。

ユーザーは、画像や映像の閲覧、映像メッセージ、読み出し、コントロール/セットアップなどの数多くの操作において、大画面の使用を望むこともある。その大画面表示は、携帯電話のユーザーインターフェースの拡張機能となる。この可能性を念頭において、携帯電話に送られるコンテンツを作成することができる。例えば、コンテンツを制御するユーザーインターフェースに「画面転送」ボタンを取り入れるなどである。

ここやその他で詳述されたアレンジメントでは、ほとんどの関連処理(例えば、ゲームのプレイ、ユーザーインターフェースの操作など)において、クラウドリソースを活用し、画面切替を促進することが可能である。クラウドリソースは、大画面および小画面デバイスのUIコントロールから送られてくるユーザー入力情報を受け取り、同時にそれに対応するMPEGストリームを作成し、送り先デバイスに送信し、ユーザーにレンダリングされる。例えば、携帯電話などのデバイスでコマンドを発したユーザーは、あたかもその携帯電話がユーザーのコマンドに反応したかのように、直ちにそれに対応する画面表示を見ることができる。実際には、反応しているのはクラウド処理であり、ユーザーは単に遠隔生成された応答としての映像を視聴しているだけである。クラウド内で処理を行うことにより、そして携帯電話(または大画面の処理装置)を単に入出力を行う周辺機器として用いることにより、画面切替が容易になる。クラウド内で作成されたMPEGストリームは、ユーザー入力に反応し、指定されたローカルデバイスまで単に送り込まれる。

Worldof Warcraftのゲームに戻ると、ユーザは習慣としてそのプログラムをコントロールする。しかし、ユーザーの入力情報は、クラウドプロセッサーに送られ、そのクラウドプロセッサーがゲームとの通信を行い、対応するMPEGストリームをユーザーのPCに返しているのである。ユーザーがそのゲームをバスの中に持ち込みたい場合は、遠隔コンピューティングされたMPEGストリームの行先を、単純にユーザーの携帯電話へと切り替えるだけである。

ユーザーの携帯電話に友人から送られてきた画像(例えばJPEG画像)を閲覧する場合は、JPEG画像は解凍され、携帯電話に送られた映像フレームとして表示される。ユーザーが、ユーザーインターフェースコントロールを操作して、次の画像へ進むまで、1枚の画像が継続表示される。このコマンドは、クラウドプロセッサーまで中継され、クラウドプロセッサーは、次の画像を一連の映像フレームとして表示する。ユーザーが大画面に切り替えて閲覧したい場合には、目的とする画面へと、MPEGストリームのルートを単純に変更するだけである。

そのようなアレンジメントによって、ユーザーは、コンテンツの小画面表示と大画面表示との間の切り替えを行うことができる。そして、もし望むならば、娯楽コンテンツの直線的な展開を中断させ、コンテンツに関わる活動に積極的に関与していくことを選ぶこともできる。

（追加情報）
Googleは近ごろ、従来の電話システムに対して多数の改善を加えたGoogleVoiceを発表した。VonageおよびSkypeもまた、一歩進んだ電話機能を提供する。このような機能を、本技術のアプリケーションと接続して使用することが可能である。

例えば、そのようなサービスによって、メディア・リマインダー伝達のために、ユーザーの電話をどう活用するかについて、ルールを確立することができる。そのサービスを利用すれば、例えば、月曜日から木曜日の午後8時から午後10時までの間、および金曜日から日曜日の午前9時から午後11時までの間に限り、テレビ番組のリマインダーの送信を可能にし、ただしユーザーの現時点の居場所が、映画館または仕事場であると識別された場合は無効にする、などのアレンジが可能である。

GoogleVoiceの他の諸機能も同様に採用可能である。そのうちの一つはユーザーの位置特定である。ユーザーがGoogle Voiceを設定し、そのオフィス、住宅、およびビーチハウスの電話のベルが鳴るようにした上で、ビーチハウスの電話の呼び出しに応えた場合に、このユーザーの位置情報が生成される。この情報は、ここで詳述されている位置情報サービス(他の位置情報サービスも同様)と共に用いることができる。

GoogleVoiceが提供するテキスト書き換えサービスは、主要コンテンツまたは補助コンテンツの音声を既知のアレンジメント(eメール、SMSメール、FAXなど)としてユーザーに提供可能なテキストに書き換えるために用いることが可能である。ユーザーが、自分の好みに応じて、異なる部分を取捨選択したり吟味したりできるテキスト形式は、ある種の使用状況においては、音声形式よりも優れたデータ形式である。

ユーザー情報に関しては、常にプライバシーに対する懸念が生じる。当然ながら、本技術は、ユーザーのプライバシー保護に対する然るべき尊重を伴って、実装されるべきである。いくつかのアレンジメントにおいて、ユーザーは、多かれ少なかれ、情報をシェアする機会を与えられる。それによって、詳述されている様々なシステムの機能性を高めることも、低めることもある。

携帯電話以外のデバイスについても、記載されているアレンジメントに関連して使用することができる。いくつかの実施形態においては、情報やコンテンツがそれらのデバイスに直接送られる。他の形態においては、携帯電話がデータを受信し、WiFi、BluetoothまたはBonjourなどを用いて、他のデバイス(例えば、身近にあるデバイス、または共通ネットワーク関連デバイス)にそれを中継する。

ユーザーのプロファイルデータには、そのユーザーがテレビ番組のどの分野に興味があるか(または興味がないか)を示すデータが含まれていることがある。ある実施形態においては、このプロファイルデータはEPG内のチャンネル(または番組・ディレクトリ・データベース内の番組)の形をとるが、データに含まれるチャンネルもあれば、外されるチャンネルもある。(恐らくＥSPNは含まれ、Home Shopping Networkは外されている。)また、ユーザーのプロファイルデータは、そのユーザーが所属する社会集団を示すこともある。例えば、ファンタジーフットボールリーグやフェイスブックグループなどの集団である。その集団のメンバーとなっている事実のみでなく、グループ会員情報、活動情報についての付加情報が、潜在的興味の主要コンテンツおよび補助コンテンツを識別するために、使用されることがある。(あるユーザーのファンタジーフットボールチームの中に、NFLの4チームの選手が含まれている場合、そのユーザーは、それら4チームのうちいずれかの試合が行われる際に、TiVoシステムのホームからテキスト通知を受信することに興味があるかも知れない。)

広告主について語られることはほとんどないが、彼等にも重要な役割があることは疑いない。一つは、プログラミングのためのスポンサーを引き受けるという伝統的な役割である。もう一つは、番組作りを含む補助コンテンツのプロバイダーとしての役割である。

Apple社iPhoneのAppストアからダウンロード可能なディスカウントアプリを提供しているピザのチェーン店のケースについて考えてみよう。ある視聴者が、そのピザチェーン店がスポンサーになっている特定のコンテンツを視聴している場合、そのアプリを使えば、20ドルのピザの注文に対して10ドルのディスカウントが受けられるとする。スポンサーとなっているコンテンツをその視聴者が開いたことを携帯電話が検知し、それによってその視聴者はディカウントを受ける資格を得る。携帯電話はユーザーの居場所を知っているため、ピザチェーン店の最寄りの支店を識別し、視聴証明をその店に送付し、支払と配達の手続きをすることができる。

本技術の特定の実施形態においては、推論が用いられることもある。推論により、確率的結果を割り出すことができる。例えば、あるシステムは、ユーザーがSeahawksゲームを視聴している確率は60％で、そのユーザーがTrailblazersゲームを視聴している確率は40％であるという結論を出すかも知れない。補助コンテンツの選択も同様に重み付けされる。例えば、別画面コンテンツ上のメニューによってユーザーに提示される5つのオプションのうち3つはSeahawksまたはフットボールに関連するものかも知れないし、5つのうち2つはTrailblazersまたはバスケットボールに関するものかも知れない。

いくつかの実施形態においては、家庭および外出先でユーザーがその視聴活動において何を選び取っているかについて追跡され、その結果は、例えば、ユーザーのホームネットワークに接続されたディスクまたはメモリーなどのデータストアに収集されるか、Nielsen、GoogleまたはComcastなどのサービスプロバイダーによって保守される。この収集データストアは、それを中心として当該ユーザー向けの補助コンテンツの決定が行われる中枢となり得るものである。いくつかのアレンジメントには、ユーザーによって選択される補助コンテンツに関する情報も含まれる。収集されたデータは、プロファイルデータの情報源としてのみでなく、それなしでは漠然としていたかも知れない将来コンテキストにおけるユーザーの活動を見定める補助手段としても、その役割を果たし得るものである。

然るべき許可があれば、ユーザーの消費活動に適合した補助コンテンツを提供するために、そのような情報は、リアルタイムでまたは折に触れて、コンテンツのプロバイダーおよびその他の当事者間で共有されることがある。いくつかの実施形態において、そのような情報は、そのユーザーに対する特定のコンテンツの提供に関与している当事者間でのみ共有される。例えば、ユーザーのESPN番組の視聴に関する情報はESPNのみによって共有される。その他の実施形態における情報は、より幅広い階層の当事者間で共有される。この後者のアレンジメントの例としては、ESPNフットボールゲームに対応する補助コンテンツを、CBS、NBC、ABCおよびFOXが提供できるようにすることも可能である。

(また、そのように収集された情報は、視聴者測定業者により共有されることもある。)

別画面に対しては、様々なネットワークが、いずれも違った方針を持っている。FOX、NBC、ESPNはいずれも、類似した主要コンテンツに対して、相違した補助コンテンツを持っている。

ユーザーが視聴している(または将来的に視聴する)可能性のある番組を推定することが明細書に述べられているが、いくつかの番組に対して同様の推定が可能である。ユーザーに確認を求めれば、いくつかの番組のうちから、ユーザーが視聴中の1番組を識別することができるかも知れない。

本明細書において、譲受人の過去の特許出願との関連について前述されているが、それは繰り返し適用可能なものである。これらの開示部分は全体として読むべきものであり、さらに全体として解釈されるべきものである。それぞれの特徴は、他の特徴と結びつくというのが、出願人の意図である。よって、例えば、出願番号第 61/150,235号に詳述されているウィジェット関連技術を採用しているアレンジメントは、実装されたときに、本出願に詳述されている特徴およびアレンジメントを含む可能性がある。またその逆も同様である。空港のテレビモニターの音声サンプリングによって、家のDVRに同じまたは先行する番組を録画させる機能は、出願番号第12/271,772号に詳述されているが、同様に、クラウドソースのデータベースにクエリーを実行して関連する補助コンテンツを特定することが可能であり、これは本明細書に詳述されている。様々な補助コンテンツを携帯電話にプッシュ型配信し、ユーザーはその携帯を使って矢印キーでスクロールするという方法は、出願番号第12/484,115号に詳述されているが、これは、本出願で詳述されているように、本アプリケーションの環境に基づいて、ユーザーが現在使っているコンテンツについて推定するシステムに採用することが可能である。コンテンツ認識タスクまたはコンポーネントタスクを、場合によっては逆オークションにより、外部のサービスプロバイダーに委託することは、出願番号第12/484,115号に詳述されているが、これも同様に、ここに述べられている技術の実施形態において採用することが可能である。等々。これらのことから、本出願において開示されている方法、エレメント、およびコンセプトは、関連出願に詳述されている方法、エレメント、およびコンセプトに結びついているということを理解しなければならない。そのうちいくつかは本明細書において取り立てて詳述されているものの、あまりに多数の配列や組合せがあるために、その多くはまた述べられていない。しかしながら、これらすべての組合せを実行したとしても、提供されている示唆から当業者にとっては、それらは決して難しいものではない。

DVRは通常、家庭での使用を基本とするデバイスである。しかし、必ずしもそうである必要はない。本技術の実施形態においては、あらゆる種類の記録装置を、場所を選ばずに使用できる。(例えばケーブルテレビは、ケーブル配信システムの前処理で実際の録画を行うというDVRサービスを提供している。)

図.1は、別画面の補助コンテンツが、主要コンテンツとは別に提供されている状態を示すものであるが、他のアレンジメントにおいては、それらは一緒に提供されるか、または同じ配信システムを用いて提供される。

いくつかの実装例では、他者に対するユーザーの接近度を用いて、そのユーザーの行動を推定することが可能である。例えば、ユーザーが、仕事後のバスケットボールリーグの仲間と接近している場合は、その要素によって、そのユーザーが、(3月であれば)バスケットボールの試合を観戦している可能性、または(11月であれば)フットボールの試合を観戦している可能性が高まる。対照的に、ユーザーが自分の妻に接近している場合、さらにそれが月曜日から木曜日の夜である場合、その要素が示すのは、そのユーザーがComedy CentralのDaily Showを視聴しているかも知れないということである。接近度は、例えばBluetoothシグナルまたは位置情報の対比などによって、電子的に検知することが可能である。

すでに示したように、ある特定の実装に必要なものが何であるかによって、物理的な接近度の持つ意味合いも変わってくる。物理的に近接しているという意味は、一定の距離(例えば10ヤード、または100ヤード)内であること、共通の建屋内であること、共通ネットワークサービスによって提供された線内であること、WiFiやBlueToothのような近距離無線通信サービスのエリア内であることなど、アプリケーションによって様々である。

本明細書はテレビ番組にも言及している。しかしそれは、制作方法や配信方法を問わず、あらゆる映像コンテンツを対象とすることを意図した簡潔なものである。例えば、あるテレビ番組は、多数の異なるネットワークを経由して、複数の消費者に一斉に配信される伝統的な番組かも知れない。または、ウェブ放送、YouTube、Hulu、ビデオ・オン・デマンド(NetFlixなど)、Boxee、DVD、劇場上映などの別の形式で提供されるコンテンツかも知れない。

コンテンツのプログラマーは、先を見据えて、高度なメディア体験のライブラリーを作成することもできる。そのライブラリーは、個々のユーザー向けにカスタマイズされ、基本的なコンテンツのテーマ(例えばバスケットボールの試合)を持ち、そこにおいてはユーザーによる補助的体験(補助コンテンツ)の動的選択および自由検索が行われる。より高度な没入型レンダリングシステムと、より高性能なユーザーインターフェースによって、テレビ画面および携帯電話のパラダイムは、その影が薄くなっていくかも知れない。あるユーザーは、ジェッツのフットボール試合の解説者として、ハワード・コセルのアバターを選択し、そのアバターに、細かい点まで踏みこんだ実況解説をさせるかも知れない。また別のユーザーは、白髪のジョー・ネイマスに、サイドラインから実況させることを単に選ぶだけかも知れない。

番組・ディレクトリ・データベースにも既に言及している。細分化および自動化された技術によってデータがひとたびコンパイルされると、それは、本明細書の他の部分で説明されている技術に従い、EPGおよびその他現行EPGの先行技術として知られるものに関連して、提供、使用および流布される。EPG技術の先行技術は、本明細書では詳述されていない。さらなる詳細について、読者は既存文献を参照されたい。(既存文献には、Davisおよびその他の特許である5,559,548、5,576,755、5,585,866、5,589,892、5,635,978、5,781,246、5,822,123、5,986,650、6,016,141、6,141,488、6,275,268、6,275,648、6,331,877、6,418,556、6,604,240および6,771,317、ならびにEPGに関する透かし技術の使用に関連する本発明者に対する特許である7,263,202が含まれる。)

本技術については、主要映像コンテンツを補完するための補助コンテンツの提供というコンテキストにおいて記述されているが、同じ原理は他のもの、例えば周囲の状況および/またはその環境に反応する他のデバイスなどにも適用可能である。よって、例えば、補助コンテンツは、物理的対象を含むあらゆる対象に関連付けることができる。本書に記載した原理を用いて、関連コンテンツのメニューの提供を受けるのは、エッフェル塔の写真を撮っているユーザーかも知れないし、または紙パック入り牛乳かも知れない。

先に詳述したアレンジメントのうちのいくつかは、より大きな概念、すなわちユーザーの環境に対応したコンテンツの提供を援護する技術という特殊なケースであることが認識されるだろう。

研究者の中には、我々の日常体験のすべてがデジタル形式で記録される日が来ると予見する者もいる。実際に、Microsoftのゴードン・ベルは、自らの技術であるCyberAll, SenseCamおよびMyLifeBitsを用いて、最近の生活記録をデジタルアーカイブに蓄積している。ベルのアーカイブに保存されているのは、すべての電話通信記録、日常生活の映像、視聴したすべてのテレビとラジオの録画・録音、開いたすべてのウェブページのアーカイブ、訪れたすべての場所の地図データ、自らの睡眠時無呼吸を評価するための睡眠ポリグラフ、等々である。(さらなる詳細については、例えば下記を参照のこと。ベルのデジタル生活、サイエンティフィック・アメリカン、2007年3月号；ゲメル、MyLifeBits：あらゆるものに対する個人データベース、マイクロソフト・リサーチのテクニカル・レポート MSR-TR-2006-23；ゲメル、個人生活の保存のための受動記録とそれに伴う諸問題、個人体験の継続的保存および検索に関する最初のACMワークショップの記録 (CARPE '04), pp. 48-55；ウィルキンスン, これだけは覚えておいて、ニューヨーカー誌、2007年5月27日。その他、下記からの引用も参照のこと。ゴードン・ベルのMicrosoft Researchウェブページ、およびCARPE(Capture, Archival & Retrieval of Personal Experiences)ウェブページのためのACM SpecialInterest Groupウェブページ。)

より実用的な事例は、音声を頻繁に(例えば、連続毎秒5000サンプル；または毎秒10,000サンプルを毎分12秒継続など)サンプリングすることによって、携帯電話でユーザーの日常体験を記録することである。これらのサンプルは、さらなるクエリーを実施するために、ユーザーの明示的要求に基づき、ユーザーの自宅に送られることもある。または、ユーザーが自宅に持ち帰り、それに基づいて別な作業を行うためのデータをそこから得ることも可能である。

レストランにいる間に、自分のお気に入りの歌を耳にしたユーザーのケースを考察してみよう。後に彼女は物理的に、またはワイヤレスにより、自分の携帯電話とラップトップコンピューターを接続し、コンピューター上でGoogle Toolbarを起動させる。(または携帯電話でGoogle Toolbarを起動させることもできる。)Google Toolbarが過去の検索履歴を保持している一方で、携帯電話には過去の体験の履歴が残っている。Google Toolbar提供のタスクのためにユーザーインターフェースを用いることにより、そのユーザーは、(例えば、タイムスタンプ、GPS位置タグなどによって)迅速にその日の音声サンプルを自由検索でき、そしてレストランで記録されたサンプルを見つけることができるのである。そしてGoogle Toolbarは、特定された音声を処理して、タイトル名やアーティスト名およびアルバム名など、その歌のメタデータを返す。(Shazamなどの)競合するサービスとは異なり、ユーザーは、サンプリングされた履歴によって過去の体験を後から掘り返すことができる。ずっと後になってから、記録された情報が興味の対象となった例もある。

別のアレンジメントにおいては、すべてのサンプル音声が(記録された時点、または後になってから)Googleに送られる。Googleは検索を開始し、その結果に基づき音声データに注記を付ける(またはその結果を提供する)。それは、例えば、メタデータ、音声からテキストへの変換データ、音声認識可能な言葉(およびNLPなどにより要約されたコンセプト)に対応したウィキペディアおよび他のウェブ・リソースへのリンクなどである。ユーザーが後に音声データをレビューする際、この増強された情報は直ちに利用可能となる。

効果を上げるために、クラウドソーシングおよび位置情報を採用してもよい。例えば、Googleは、GPSデータおよびタイムスタンプにより照合した結果、同じ時間にそのレストランにいた何十人もの客を、そのユーザーとして識別してしまうかも知れない。そのユーザーの音声状態の特性をより完璧に明らかにするため、これらの他の客から記録した音声を、そのユーザーから記録した音声と関連付けて考察する(例えば、別の電話で不定期的に記録された音声サンプルをつなぎ合わせて、連続した音声の流れをつくることもある)。Googleは、この音声の寄せ集めデータを分析して、より多くの優れた情報を生み出すことが可能であり、さらに、例えばそれぞれのユーザーがレストランにいた時間帯に従って、この情報をユーザーが利用できるようにすることも可能である。

また別の実装においては、他の客たちの音声データのGoogle 分析結果を利用することも可能である。この場合、それが、その客たちが明示的に要求した調査であるか、またはGoogleが独自に行った分析であるかは問わない。レストランで、隣の席の人がチョコレートスフレをオーダーしたとする。すると、その品名は、Googleサーチにおいて、データマイニング作業の一環としてレストラン名と結びつけて認識され、そのサーチ結果は、3年前にグルメ雑誌に公開されたそのデザートに対するそのレストランのレシピを明らかにするかも知れない。そのような情報は、それが別の客のテーブルで記録された音声に基づく情報であったとしても、ユーザーに提供されるサーチ結果の中に盛り込まれる。同様に、レストランのメニューも、繰り返し話される料理名に基づいて再編成することができるが、その際、料理名は、分析ソフトにより、発話された文脈上の前後関係と共に認識される(例えば、音声的手掛かりとなる「ご注文を伺ってもよろしいでしょうか」の後に続いているなど)。さらに、そのレストランを訪れたことがあることが、(そこで音声データが記録されたかどうかにかかわらず)GPSデータによって明らかになっているすべてのユーザーに対して、そのメニューは利用可能となる。

さらに別のアレンジメントにおいては、記録された音声は継続的にGoogleに提供され、即座に分析される。Googleは分析結果を元のユーザーの携帯電話に流し、そのデータはそこにバッファされ、レビューされる。(中には通常より長い時間を要する分析もあるため、厳密な日付順に従ってデータフローを返信できるとは限らないが、データの返送は、それが対応する部分の音声の抜粋を示すタイムスタンプに関連付けて実施されるため、情報を適切な順序で提供することが可能になる。)ユーザーは、記録された情報の検閲、およびGoogleから戻ってきた対応情報の内容確認の目的で、どの時点においても、(恐らくは、iPodでAppleが用いており、特許公開番号20080174570に詳述されている"cover flow"インターフェースのような、一時的に配列されたデータに適合したユーザーインターフェースを用いることによって)自らの体験を巻き戻して振り返ることが可能になる。

(上記に詳述したアレンジメントにおいて、客たちが共通の環境下(すなわちレストラン)にいるという事実は、上述のGeoPlanetサービスなどの地理位置情報データベース上の、各々の緯度／経度の座標軸を調べることで突き止められる。所在地住所や商号など、機能的精細度のレベルが低い情報に対しては、客の緯度／軽度の座標軸はすべて同じ位置に一致するようになっている。)

Bonjourについては、様々なことが言及されている。Bonjourは、Appleのサービス発見プロトコルであるZeroconfの実装時の商標名である。Bonjourは、マルチキャスト・ドメイン・ネーム・システムのサービス記録を活用して、デバイスをローカルネットワーク上に配置し、それぞれが提供しているサービスを識別するものである。このソフトウェアは、AppleのMAC OS Xオペレーティング・システムに組み込まれている。また、AppleのiPhoneにおいて、"Remote"アプリケーションにも含まれており、そこではWiFiを経由して、iTunesライブラリーへの接続を確立する。(TiVoは、Bonjourを活用して、デジタル・ビデオテープ・レコーダーおよび共有メディアライブラリーを配置する。)

Bonjourサービスは、オペレーティング・システムで行われるよりも、むしろ主として標準的なTCP/IPコールを用いて、アプリケーション層で実装されている。サービス発見のコア構成要素であるBonjourマルチキャストDNS応答システムのソース・コードは、Appleが作成したものであり、ダーウィン・オープンソース・プロジェクトの一環として利用可能である。そのプロジェクトは、Mac OS X、Linux、*BSD、SolarisおよびWindowsなど、幅広い範囲のプラットフォームに対応する応答デーモンを構築するためのソース・コードを提供するものである。さらに、Appleは、Javaライブラリーのほか、Bonjour for Windowsと呼ばれる、ユーザーがインストール可能なサービス一式を提供している。

ここに示されているように、Bonjourを活用すれば、それは本技術の実装において様々な機能を果たすことが可能になる。例えば、DVRにおいてもBonjourを使用して、1つ以上のパケットを、周期的(例えば毎秒または数秒ごと)にホームネットワークのサブネットに発信することによって、表示中(または記録中)の番組を識別することができ、さらにその番組に対応する補助コンテンツを識別することができる。また、EPGデータに基づくとともに、それまでの記録一覧に基づき、現時点で選択可能な他の番組の詳細情報のほか、自らの位置、正規登録ユーザー、提供する機能/サービスについても、識別が可能になる。応答システムからDVRに対して、さらなる情報またはコンテンツを要求できるよう、これらのBonjourブロードキャストはいずれも、DVRのIPアドレスを含んでいる。さらに、携帯電話からも同様に、状況、表示中のコンテンツ、位置、利用可能な機能／サービス、ユーザーのプロファイルデータなどを識別できる情報を送信することができる。

他のソフトウェアは、それに代わって、またはそれに加えて、デバイス間のデータの交換のために用いることができる。Universal Plug and Play (UPnP) ならびにその後継のDevices Profile for Web Services (DPWS)などの事例を含む。その他に、設定が不要なネットワークサービスを実現するプロトコルもある。デバイスは、これらプロトコルを通じて、他のデバイスおよび共有コンテンツなどに対して、自らを接続および識別し、かつ使用可能な機能を告示することが可能になる。

当業者は、そのようなソフトウェア・ツールには精通していると考えられる。
本技術は、特定の実装形態において、共有画面で集団的なグループ視聴体験をしている視聴者たちの妨げになることなく、複数の視聴者による個人用画面での個人的な視聴体験を可能にするということが認められるだろう。本技術の最終的な結果は、個人がそれぞれ異なる観点から健全な集団的経験に対し寄与していく中で、社会経験が豊富になっていくことである。

（最終的注記）
本発明の原理を図面による例を用いた説明・解説してきたが、本技術は限定的なものではないことが理解できる。

例えば、携帯電話に参照が送られると、本技術があらゆるデバイスとのユーティリティを発見することが認識されるであろう（携帯デバイスと固定型デバイス）。PDA、オーガナイザ、携帯型音楽プレーヤー、デスクトップコンピュータ、着用可能型コンピュータ、サーバーなどはすべて本書に記載した原理を活用することができる。特に想定携帯電話には、AppleのiPhone、GoogleのAndroid対応携帯電話（T-Mobile 用にHTC Corp が製造したG1 phoneなど）がある。「携帯電話」とは、厳密に携帯や電話と言えないものも含め、このようなすべてのデバイスを含むものとする。

(そのタッチインターフェースを含む、iPhoneの詳細はAppleの特許出願20080174570に示されている)

説明の便宜上、本明細書に記載されるコンセプトは通常単独で解説されている。ただし、これらのコンセプトはほとんど無限の組み合わせ(参照として付属の文書内で詳述されるコンセプトを含む)が可能で、例えば、携帯電話もしくはシステムは、詳述された解説機能の複製を採用することも可能である。かかる組み合わせは、明らかに本出願の開示に当てはまるものである。

明細書および図面が、データを 装置内に保存してあるままに解説している一方で、これは説明のみのものである。データはあらゆる場所に(「クラウド」ストレージでさえ)保存が可能で、随時随所に提供できる。同様に、様々なオペレーションが特定の装置によって実施される様に説明されている。ただし、プロセスも随所で実施し、結果を随時利用することが出来る。故に、オペレーション実行中の携帯電話、またはDVRに保存されているデータのみに対する参照のみが解説されている。無論、他のアレンジメントを使用することも可能である。

本出願人は、特許文献内の関連のシステムおよび技術について膨大な量の情報を出版しており、その作品は当業者にはなじみ深いものとなっている特許6,590,996、6,947,571および、特許公開出願20070156726が含まれている。

コンテンツの識別もしくは信号に透かし技術を採用しているアレンジメントがある一方で同一もしくは類似の機能がフィンガープリントに基づく方法もしくは帯域外技術(例、VBI信号法)によって実現されることも少なくない。いくつかの実装によっては、バーコードやその他の公然のコード、RFIDチップ、その他の識別技術を採用することもある。

完全なシステムとして公開されているものの、詳述したアレンジメントのサブコンビネーションも個別に想定している。

本明細書では特定の動作指示や特定のエレメント組み合わせを説明のための実装例で説明したが、その他の想定される方法でも動作を再指示できる（省略や追加などが可能）こと、およびその他の組み合わせで一部のエレメントを省略したり追加できることなどが認識されるであろう。

本開示で参照した携帯電話およびその他デバイスの設計は、当業者にとってなじみのあるものである。上述の通り、各々は典型的に、1つ以上のプロセッサ、 メモリー(例、RAM)、ストレージ(例、ディスクまたはフラッシュメモリー)、ユーザーインターフェース(例、キーパッド、TFT LCD またはOLEDディスプレイ、タッチセンサーや他の動作センサー、カメラや他の光学センサー 、マイク等をグラフィカルユーザーインターフェースを提供するためにソフトウェアのインストラクションと併せて含める)、これらのエレメント間の相互接続(例、バス)および他のデバイスと通信するための1つ以上のインターフェース (GSM、CDMA、W-CDMA、CDMA2000、TDMA、EV-DO、HSDPA、WiFi、WiMaxまたはBluetooth等の無線および/またはイーサネットローカルエリアネットワーク、 T-1インターネット接続等の有線を含む)を含んでいる。

本明細書に詳述しているプロセスおよびシステムコンポーネントは、マイクロプロセッサ (例、32-bit RISCプロセッサのARMシリーズ)、グラフィック処理ユニット (GPUs)、デジタル信号プロセッサ(例、TexasInstruments TMS320シリーズのデバイス)を含む様々なプログラム可能プロセッサ用の汎用プロセッサとして実装可能である。これらのインストラクションはソフトウェア、ファームウェアなどとして実装可能である。これらのインストラクションは、プログラム可能ロジックデバイス、FPGA（Xilinx Virtexシリーズのデバイスなど）、アプリケーション固有の回路などのプロセッサを含む多彩なプロセッサ回路形式に導入することも可能である（デジタル、アナログ、アナログ/デジタル混合回路）。インストラクションの実行はプロセッサ間で配信可能で、デバイス内のプロセッサ間またはデバイスネットワーク間でパラレルにすることも可能である。コンテンツ信号データの転換も、様々なプロセッサおよびメモリデバイス間で配信可能である。「プロセッサ」または「モジュール」に対する参照は、特定の型式の実装を要求するためではなく、機能を参照していると理解されるべきである。

詳述した機能導入のためのソフトウェアインストラクションは、本出願に記載した記述から、当業者によって手軽に作成できる（C、C++、Visual Basic、Java、Python、Tel、Perl、Scheme、Rubyなどで記述）。 本技術に基づく携帯電話、DVRおよびその他のデバイスには、様々な機能および動作を実行するためのソフトウェアモジュールを含めることができる。

特に、各デバイスは、ハードウェアデバイスと汎用機能に対するインターフェースとなるオペレーティングシステムソフトウェアを含み、ユーザーの求める特定のタスクの実行のために選択的に起動するアプリケーションソフトウェアも含んでいる。既知のブラウザソフトウェア、通信用ソフトウェア、およびメディア処理ソフトウェアは、ここで詳述される多くの用途に適用が可能である。ソフトウェアは一般的に、電磁、光学ディスク、メモリーカード、ROM等の有形的表現媒体を介する1つ以上のデータストラクチャー内に、インストラクションとして保存される。実装例には、組み込みシステムとして実装されるもの−オペレーティングシステムとアプリケーションソフトウェアがユーザーには区別が出来ない(例、携帯電話で一般的)専用コンピューターシステム−がある。本明細書に詳述する機能は、オペレーティングシステム、アプリケーションソフトウェアおよび/または組み込みシステムソフトウェアに実装することが可能である。

様々な機能は様々なデバイスに実装が可能である。例えば、携帯電話がリモートサーバーと通信するシステムでは、様々なタスクがそれぞれのデバイスで専用的に実行されるか、デバイス間で分担して実施することが出来る。コンテンツの識別はかかるタスクの一例に過ぎない。ゆえに、デバイスが実行するオペレーションの説明は限定的ではなく典型的なものであることが理解されるべきで、他のデバイスによるオペレーションの実行、またはデバイス間での共有も考えられる。

オペレーションは、厳密に識別可能なハードウェアで単独で実行される必要はない。正しくは、オペレーションの中には他の装置(例、クラウド・コンピューティング)に委ねることが出来るものもあり、それらはその実行を、さらに一般的で匿名のシステムに任せている。当該の分散システムは、大規模(例、世界中のコンピューティングリソースを伴う)、またはローカル(例、携帯デバイスがBluetooth通信を通じて近傍のデバイスを認識し、タスクに一つ以上の近傍デバイスを含める)であることができる。

詳述したコンテンツ信号の処理（画像信号、音声信号など）にはこれらの信号の多彩な物理形式への転換も含まれていることが認識されるであろう。画像・映像（物理スペースを移動し物理オブジェクトを描く電磁場形式）は、カメラまたはその他のキャプチャ機器を使用して物理オブジェクトからキャプチャ、またはコンピューティングデバイスから生成することができる。同様に、物理媒体を移動する音声圧力波は音声トランスデューサ（マイクなど）にキャプチャし電子信号（デジタルまたはアナログ形式）に変換可能である。これらの信号は通常電子デジタル形式で処理され上述のコンポーネントおよびプロセスを実装するが、電子、光学、磁気、電磁波形式などその他の物理形式でキャプチャ、処理、転送、保存も可能である。コンテンツ信号は、信号および関連情報の様々なデータ構造表現の処理・生成中にさまざまな方法でさまざまな目的のために転送される。そして、検索、ソート、読み込み、書き込み、読み取り中にメモリ内のデータ構造信号が転換される。この信号は、ディスプレイまたは音声トランスデューサ（スピーカー）を介してキャプチャ、転送、保存、出力の際にも転換される。

GPSデータに参照を行った。このことは、あらゆる位置関連の情報の略語と理解するべきで、必ずしも地球位置システム衛星に由来する必要はない。例として、一般的にデバイス間で交換される無線信号に依る位置データの生成に適当な他の技術(WiFi、携帯等が挙げられる)。複数の通信デバイスがある場合には、非常に正確な時間・位置情報が取得できる参照先システムからの信号自体（および不完全なデジタルクロック信号）である。かかる技術については、国際特許出願公開文書W008/073347に詳述されている。当業者は、到達時間の技術に基づくもの、放送用ラジオ、テレビ塔の位置 (Rosumが提供する様な) および WiFiノード (Skyhook Wirelessが提供し、iPhoneが採用している)等に基づくものを含む、いくつかの他の位置推定技術に精通するであろう。

地形データが一般的に緯度経度のデータから構成される一方で、それは代替的にそれ以上か以下か、もしくは異なるデータで構成されることがある。例として、磁力計で得られる磁気方位、もしくはジャイロその他のセンサーで得られる傾斜情報等の方位情報を含むことがあるそれはまた、デジタル高度システムで得られる、標高情報を含むこともある。

タッチスクリーン・インターフェース−動作インターフェースの一形態、を参照した。現行技術の実装に使用され得る動作インターフェースの他の形態は、携帯電話の動きを感知し、−キャプチャした画像内の特徴の動きを追跡して作動する。当該の動作インターフェースのさらなる情報は、Digimarcの特許 6,947,571に詳述されている。

上述のように、透かし技術を様々な実施形態に使用することができる。透すかしのエンコード/デコードの技術は、例として、Digimarcの特許6,614,914、6,590,996および6,122,403、Nielsenの特許 6,968,564および7,006,555、およびArbitronの特許5,450,490、5,764,763、6,862,355および6,845,360に詳述されている。

Digimarcは、現行の課題に関連して様々な特許出願を行ってきている。例として、特許出願公開文書20070156726,20080049971, および 20070266252, および Sharma 他による2008年5月22日付の係属中の出願12/125,840 を参照のこと。

コンテンツのフィンガープリント化も、様々な実施形態に使用されている。音声フィンガープリント法の例は、特許出願公開文書20070250716、20070174059 および20080300011 (Digimarc)、20080276265、20070274537および 20050232411 (Nielsen)、20070124756 (Google)、7,516,074 (Auditude)、および6,990,453および7,359,889 (共にShazam)に詳述されている。画像/映像のフィンガープリント法の例は、特許出願公開文書7,020,304 (Digimarc)、7,486,827 (Seiko-Epson)、20070253594 (Vobile)、20080317278 (Thomson)および20020044659 (NEC)に詳述されている。

図は、典型的なものを意味し、限定的な意味は持たない。例として、それらは単一のデータベースが使用できる際に、複数のデータベースを示すことがある（逆もあり）。同様に、図示されたブロック間のいくつかのリンクは−明瞭な表示とするために−示されていない。

コンテキストデータが、動作をさらに強調するために詳細な実施形態を通じて使用されることがある。例として、プロセスは元となるデバイスが携帯電話かその他の型式のデバイスであるか、周囲温度が30度か80度か、場所、およびユーザー特有の他のデータに依存することがある。

ここで解説する技術の無数のバリエーションやコンビネーションを、明確に紹介することは不可能である。出願人は、本明細書のコンセプトがそれ自体として、また、既存のものとも組み合わせ、代用、交換可能であることを認識し、意図している。さらに、詳述した技術は、効果を増すためにその他の技術（現在のもの、将来のもの）に含めることができることも認識されるであろう。

本明細書を不必要に長いものにすることなく包括的な開示を行うため、出願人は本明細書において様々な文書・特許情報開示への参照をつけた。（これらの文書は、その特定の内容について引用した場合であっても全部を参照している。）これらの参照では、本書で詳述したアレンジメントと一体化可能な技術や示唆を開示している。

上述した実施形態における特定エレメントや機能の組み合わせは説明目的のみであり、本出願および参照として付属の文書内の、他の示唆とのこれらの示唆の互換や置き換えも、特に構想、意図されたものである。

申請者は、このアレンジメントのいくつかについては特に下記を想定する。

Ａ．携帯電話の位置を示す位置データにアクセスするステップと、
前記携帯電話のユーザーのテレビ視聴設定に関連したプロファイルデータにアクセスするステップと、
少なくとも前記位置データおよび前記プロファイルデータを参照することで、前記ユーザーが現在視聴している、または将来視聴する特定の映像コンテンツを推定するステップと、
を含む方法。

前記携帯電話から前記ユーザーに前記推定した映像コンテンツに関連する補足情報を表示するステップ、
を更に含む、Ａに記載の方法。

前記携帯電話のユーザインタフェースを介して、前記ユーザーが前記特定の映像コンテンツを視聴しているかどうかを問い合わせるステップ、
を更に含む、Ａに記載の方法。

ユーザーが肯定の反応を行った場合に、前記携帯電話から前記ユーザーに特定の番組に関連した補足情報を提供するステップ、
を更に含む、Ａ１に記載の方法。

前記ユーザーがテレビの画面で前記特定の映像コンテンツを視聴しながら、前記携帯電話の画面で前記補足情報を閲覧する、Ａ２に記載の方法。

前記ユーザーがテレビの画面で前記特定の映像コンテンツを視聴せずに、前記携帯電話の画面で前記補足情報を閲覧する、Ａ２に記載の方法。

前記示された位置を含むメディアマーケットで現在利用可能な複数のテレビ番組を識別するEPGデータを取得するステップと、
前記ユーザーが現在視聴している、または将来視聴する特定のテレビ番組を評価するために、前記プロファイルデータに基づいて前記識別されたテレビ番組を評価するステップと、
を更に含む、Ａに記載の方法。

前記プロファイルデータは、前記ユーザーの過去のテレビ視聴履歴に関連するデータを含む、Ａに記載の方法。

前記携帯電話の位置モジュールから前記位置データにアクセスするステップと、
前記携帯電話のプロセッサを使用して前記特定のテレビ番組の推定を行うステップと、
を更に含む、Ａに記載の方法。

前記ユーザーに関連づけられたホームネットワーク内のデバイスの推定についての情報を送信するステップ、
を更に含む、Ａに記載の方法。

Ｂ．携帯電話の位置を示す位置データにアクセスするステップと、
前記携帯電話のユーザーのテレビ視聴設定に関連したプロファイルデータにアクセスするステップと、
少なくとも前記位置データおよび前記プロファイルデータを参照することで、前記ユーザーが視聴したい一つ以上の今後のテレビ番組を識別するステップと、
前記携帯電話を使用して前記今後のテレビ番組をユーザーに通知するステップと、
を含む方法。

Ｃ．テレビと携帯電話とが近くにあるかどうかを判断するステップと、
前記携帯電話のユーザーのテレビ視聴設定に関連したプロファイルデータにアクセスするステップと、
前記判断するステップと前記アクセスするステップとに基づき、前記携帯電話のユーザーインターフェースを使用してテレビ番組に関連する補足情報を前記ユーザーに提供するステップと、
を含む方法。

前記携帯電話のユーザーインターフェースを介して、前記ユーザーが前記識別されたテレビ番組を視聴しているかどうかを問い合わせるステップと、
ユーザーが肯定の反応を行った場合に、前記補足情報を提供するステップと、
を更に含む、Ｃに記載の方法。

前記判断するステップは、判断の際に前記携帯電話の位置についての位置データを参照する、Ｃに記載の方法。

前記判断するステップは、判断の際に前記テレビの位置についての位置データを参照する、Ｃに記載の方法。

前記判断するステップは、判断の際に前記携帯電話によってキャプチャされた音声又は画像情報を参照する、Ｃに記載の方法。

Ｄ．ユーザープロファイル情報とEPGデータとを参照することで、ユーザーのテレビ視聴行動を推定するステップと、
ユーザー環境から音声または画像データを感知するために携帯電話を使用するステップと、
前記感知したデータに基づいて前記推定を再評価するステップと、
を含む方法。

前記推定するステップは、前記ユーザーが視聴している一つ以上のテレビ番組を推定する、Ｄに記載の方法。

前記推定するステップは、前記ユーザーが特定のテレビ番組を視聴しているかどうかを推定する、Ｄに記載の方法。

再評価するステップは、繰り返し前記推定を再評価する、Ｄに記載の方法

Ｅ．ユーザープロファイルデータを評価するステップと、
EPGデータを評価するステップと、
ユーザー環境から音声または画像データを感知するステップと、
前記音声または前記画像データを参照することで、ユーザーが視聴しているテレビ番組を推定するステップと、
を含む方法。

Ｅ．ポータブルデバイスのユーザーインターフェースを介して、前記ユーザーが前記推定されたテレビ番組を視聴しているかどうかを問い合わせるステップと、
前記ユーザーが肯定の反応を行った場合に、前記ポータブルデバイスにテレビ番組に関連した補足情報を提供するステップと、
を含む方法。

Ｆ．テレビ番組を予約するようにDVRをプログラミングするステップと、
前記番組の予約時間の前に、前記DVRに関連付けられた携帯電話にリマインダーを送るステップと、
を含む方法。

Ｆ１．前記携帯電話が家から離れていることを判断するステップと、
離れた場所で前記番組が利用可能になる時を判断するステップと、
離れた場所での前記番組利用可能性について事前にリマインダーを送るステップと、
を更に含む、Ｆに記載の方法。

Ｇ．テレビ番組を録画するようにDVRをプログラミングするステップと、
前記DVRに関連付けられた携帯電話に前記テレビ番組に関連したリマインダーを送るステップと、
前記携帯電話のユーザーインターフェースを介して入力されたユーザーコマンドに反応して、前記携帯電話の画面に少なくともテレビ番組の一部を表示するステップと、
を含む方法。

Ｈ．携帯電話とテレビシステムとを使用した方法であって、
前記テレビシステムに関連付けられた電子ユーザーインターフェースを使用して、ユーザーが興味を持つ今後のテレビ番組を識別するステップと、
ユーザーの携帯電話に前記テレビ番組に関連したリマインダーを送るステップと、
を含む方法。

前記携帯電話のユーザーインターフェースを介して入力されたユーザーコマンドに反応して、前記携帯電話の画面に少なくとも前記テレビ番組の一部を表示するステップ、
を更に含む、Ｈに記載の方法。

前記ユーザーが関連している一つ以上の他の携帯電話に前記テレビ番組の少なくとも一部を送るステップ、
を更に含む、Ｈに記載の方法。

WiFiやBluetoothを含むワイヤレスで前記他の携帯電話に前記テレビ番組の少なくとも一部を送るステップ、
を更に含む、Ｈに記載の方法。

前記ユーザーの携帯電話の近くにある前記他の携帯電話に前記テレビ番組の少なくとも一部を送るステップ、
を更に含む、Ｈに記載の方法。

前記ユーザーの携帯電話に関連して登録された他の携帯電話に前記テレビ番組の少なくとも一部を送るステップ、
を更に含む、Ｈに記載の方法。

Ｊ．ユーザーの携帯電話に関わる方法であって、
前記ユーザーが興味を持っている、または興味を持つ可能性のあるテレビ番組を識別するステップと、
前記携帯電話のユーザーインターフェースを介して、前記ユーザーが識別されたテレビ番組を視聴しているかどうかを問い合わせるステップと、
を含む方法。

前記ユーザーが肯定の反応を行った場合に、前記識別された番組に関連した補足情報を前記携帯電話に提供するステップ、
を更に含む、Ｊに記載の方法。

前記携帯電話を使用して音声または画像データを感知するステップと、
前記ユーザーが識別された前記テレビ番組の視聴をやめたかどうかを前記音声または画像データから推測するステップと、
を更に含む、Ｊに記載の方法。

前記携帯電話の動きを感知するステップと、
前記感知した音声または画像データ、および前記感知した動きから、前記ユーザーが前記テレビから離れたことを推測するステップと、
を更に含む、Ｊに記載の方法。

前記ユーザーが戻ってから前記番組を再開できるようにテレビ画面を一時停止するステップ、
を更に含む、Ｊに記載の方法。

Ｋ．過去に利用可能であった曖昧なデータを参照することで、ユーザーの現在のテレビ視聴活動を推定するステップと、
前記推定を確認または反証するための現在のデータをユーザーの携帯電話からさらに取得するステップと、
を含む方法。

前記データは、前記推定を確認または反証するユーザー入力で構成される、Ｋに記載の方法。

前記データは、前記携帯電話から抽出された音声または画像データで構成される、Ｋに記載の方法。

ユーザーの携帯電話に推定されたテレビ視聴行動に関連した補足コンテンツを提供するステップと、
を更に備える、Ｋに記載の方法。

Ｌ．ユーザーの携帯電話に関わる方法であって、
テレビ番組が完了する前に、前記ユーザーが視聴をやめたことを示すデータを感知するステップと、
前記ユーザーの視聴停止の影響を和らげるため、前記テレビ番組に関連した行動を取るステップと、
を含む方法。

前記ユーザーが前記テレビ視聴エリアに戻ってから前記番組を再開することができるように、前記テレビ画面の一時停止するステップ、
を更に含むＬに記載の方法。

前記ユーザー不在時に放送された前記テレビ番組の抜粋に関連した情報を前記ユーザーの携帯電話に送るステップ、
を更に含むＬに記載の方法。

Ｍ．ユーザーの携帯電話に関わる方法であって、
デジタル映像レコーダーに関連付けられたデータストアから、前記ユーザーのためのワイヤレスコンタクト情報と、前記ユーザーに関連する映像番組データとにアクセスするステップと、
少なくとも前記映像番組データの一部に基づいて、前記ユーザーへの警告を生成するステップと、
前記ワイヤレスコンタクト情報を利用して、前記ユーザーへの警告通知を転送するステップと、
を含む方法。

前記アラート通知は、前記携帯電話画面での関連映像の視聴を前記ユーザに許可するデータを含む、Ｍに記載の方法。

前記アラート通知は、前記ユーザーの興味がある映像番組に関連したソフトウェアウィジェットの実行前記ユーザに許可するデータを含む、Ｍに記載の方法。

前記デジタル映像レコーダーは、ホームネットワークに結合され、前記データストアも前記ホームネットワークに結合されている、Ｍに記載の方法。

Ｎ．ユーザーの携帯電話に関わる方法であって、
映像システムの表示画面に映像番組を表示するステップと、
前記携帯電話と前記映像システムとを互いに関連付ける登録データを呼出すステップと、
前記登録データを参照することで、前記表示画面に表示されている前記映像番組を補完するために、携帯電話に補足コンテンツの転送するステップと、
を含む方法。

映像システムに複数のユーザーに関連するデータが含まれる、Ｎに記載の方法。

前記複数のユーザーのうちどのユーザーが表示されている映像を見ている可能性が高いかを識別するステップと、
前記識別されたユーザーに関連付けられた携帯電話に補足コンテンツを転送するステップと、
を更に含む、Ｎに記載の方法。

前記ユーザーデータは、少なくとも前記ユーザーのいずれかについては、プロファイル情報または映像視聴情報で構成され、
前記識別するステップでは、どのユーザーが現在の映像を視聴している可能性が高いかを識別するための、前記ユーザーデータに基づいた映像番組についての評価情報が含まれる、Ｎに記載の方法。

補足コンテンツを転送する前に、前記識別されたユーザーに補足コンテンツの利用可能性について警告するために、前記携帯電話にメッセージを送信するステップと、
を更に含む、Ｎに記載の方法。

前記メッセージは、前記現在の映像番組の所有者による情報を含む、Ｎに記載の方法。

Ｐ．ユーザーの携帯電話で別画面アプリケーションを起動するステップと、
前記携帯電話とテレビシステムとの間の論理的関連付けを判断するステップと、
前記起動するステップと判断するステップとの結果、前記携帯電話の画面上に、前記テレビシステムの画面上に表示されているコンテンツに関連する別画面補足コンテンツを表示するステップと、
を含む方法。

前記携帯電話に、前記テレビシステムを関連付ける情報を持つデータレジストリをチェックすることで、論理的関連付けを判断するステップ、
を更に備えるＰに記載の方法。

前記テレビシステムの前記画面に表示されているコンテンツが早くに配布され、タイムシフト視聴のために前記テレビシステムに録画される、Ｐに記載の方法。

別画面補足コンテンツも、前記ユーザーの地理的位置に関連している、Ｐに記載の方法。

別画面補足コンテンツが、メモリに保存されたユーザー設定データの一部に基づいて選択される、Ｐに記載の方法。

Ｒ．ユーザーの携帯電話に対し、当該ユーザーに関連付けられたテレビシステムに問い合わせを行わせ、前記携帯電話の画面上に前記テレビシステムによって処理中の映像番組のタイトルを含む情報を表示させる指示を格納する、コンピュータによる読み取り可能な記憶媒体。

前記映像番組に関連付けられた補足コンテンツデータを受信させ、前記ユーザーへの前記補足コンテンツを表示させる指示を更に格納する、Ｒに記載の記憶媒体。

前記映像番組に関連付けられた複数の補足コンテンツ項目のメニューをユーザーに表示させ、前記複数の補足コンテンツ項目のうちどれを前記ユーザーに表示すべきかを示すユーザー入力を受信させる指示を更に格納する、Ｒに記載の記憶媒体。

Ｓ．デジタル映像レコーダーに関連付けられた番組一覧から、ユーザーの関心のある番組を識別するステップと、
ユーザーが家から離れた最初の場所にいることを判断するステップと、
前記ユーザーの携帯電話に前記関心のある番組に関するリマインダーを送信するステップと、
を含む方法。

前記最初の場所から前記ユーザーが前記番組にどのようにアクセスするかについての情報を判断するステップと、
前記最初の場所で前記ユーザーに前記情報を送信するステップと、
を更に含む、Ｓに記載の方法。

前記最初の場所で利用可能な映像に対応したEPGデータを問い合わせるステップ、
を更に含む、Ｓに記載の方法。

前記ユーザーの関心のある前記番組に関連している補足コンテンツについての情報を前記携帯電話へ送信するステップと、
を更に含む、Ｓに記載の方法。

Ｔ．テレビシステムの画面に映像コンテンツを表示ステップと、
ユーザーのポーズコマンドに基づいて表示を一時停止するステップと、
を含み、
前記ユーザーのポーズコマンドは、前記ユーザーが前記映像コンテンツに関連した補足コンテンツを選択することができるグラフィカルコントロールも表示させる、方法。

前記補足コンテンツが、前記ユーザーのポーズコマンド時に前記テレビ画面に映っているものに関連する背景情報を提供する、Ｔに記載の方法。

前記グラフィカルコントロールが、前記テレビシステムの前記画面に表示される、Ｔに記載の方法。

前記グラフィカルコントロールが、ユーザーの携帯電話の前記画面に表示される、Ｔに記載の方法。

補足コンテンツでのユーザー選択に対応したデータを受信するステップと、
ユーザーの携帯電話上で前記補足コンテンツを表示するステップと、
を更に含む、Ｔに記載の方法。

Ｕ．テレビシステムの画面に動的映像コンテンツを表示するステップと、
携帯電話の画面上に、動的補足コンテンツ、前記映像コンテンツに関連している前記補足コンテンツを表示するステップと、
一回のユーザーのポーズコマンドで両方の表示を一時停止するステップと、
を備える方法。

Ｖ．テレビシステムの画面に動的映像コンテンツを表示するステップと、
携帯電話が安静位置から使用位置に動いたことを感知するステップと、
前記感知によって、前記テレビシステム画面での前記映像コンテンツ表示を一時停止させるステップと、
を含む方法。

前記感知するステップは、電話着信があったときに、前記携帯電話が安静位置から動いたことを感知する、Ｖに記載の方法。

Ｗ．最初のデバイスで、複数の映像コンテンツストリームからデータをサンプリングするステップと、
前記抽出したデータを参照することで、前記複数コンテンツストリームのうち３つ以上を識別するステップと、
ユーザープロファイルデータに参照することで、ユーザーに潜在的に関心のある前記識別コンテンツストリームの２つ以上を識別するステップと、
携帯電話の画面に前記２つ以上のストリームからの抜粋を空間的に近接して表示するステップと、
ユーザー選択に応じて、ユーザー視聴のために前記携帯電話の画面に前記２つ以上のストリームを表示するステップと、
を含む方法。

前記最初のデバイスが、前記ユーザーの携帯電話で構成される、Ｗに記載の方法。

前記最初のデバイスが、変調RF信号のレシーバーで構成される、Ｗに記載の方法。

Ｘ．最初のユーザーの携帯電話に関わる方法であって、
最初のユーザーからの指示を受信し、前記最初のユーザーの携帯電話とその他の一つ以上の携帯電話との間で画像コンテンツ情報の共有を許可するオプションを設定するステップと、
前記最初のユーザーの携帯電話に画像コンテンツを表示するステップと、
前記最初のユーザーの携帯電話からコンテンツ関連データを転送するステップと、
前記最初のユーザーの携帯電話への表示と同期して、同じ画像コンテンツを第２のユーザーの電話に表示するステップと、
を含む方法。

前記最初のユーザーの携帯電話から一人以上の他のユーザーの携帯電話にコンテンツ関連データを転送するステップ、
を更に含む、Ｘに記載の方法。

前記画像コンテンツが前記第２のユーザーの電話の表示画面のサブ部分に表示される、Ｘに記載の方法。

前記転送されたコンテンツ関連データが、前記最初のユーザー及び前記第２のユーザーの両方の携帯電話によって前記画像コンテンツが取得されたリモートコンピュータサーバーを識別する、Ｘに記載の方法。

前記転送されたコンテンツ関連データが、圧縮映像データで構成される、Ｘに記載の方法。

前記コンテンツ関連データが、ホームネットワークのデータサービスディスカバリープロトコルによって転送され、最初の携帯電話と第２の携帯電話がともに同じホームネットワークに結合される、Ｘに記載の方法。

Ｙ．ユーザーが持ち運んでいるポータブルデバイスを参照することで、前記ユーザー位置を判断するステップと、
前記判断されたユーザー位置近くのテレビシステムを識別するステップと、
前記ユーザーに対応したプロファイルデータに従って前記テレビシステムの操作の一面を制御するステップと、
を含む方法。

Ｚ．第２の別のコンテンツがユーザーにレンダリングされているときに、前記ユーザーにレンダリングされている第１のコンテンツを識別するステップであって、前記コンテンツの一つはテレビ画面に表示されているエンターテインメントコンテンツで構成され、前記コンテンツのもう一つは第２の画面にレンダリングされるウェブコンテンツで構成される、識別するステップと、
データベースに関連付けて、前記第１のコンテンツと前記第２のコンテンツとに関連するデータを保存するステップと、
前記第１のコンテンツを識別するデータで前記データベースにクエリーを行うことで、関連付けられた前記第２のコンテンツを識別するデータを取得するステップと、
を含む方法。

前記ユーザーに対応するプロファイルデータを、前記第１のコンテンツと前記第２のコンテンツとに関連する前記データに関連付けるステップと、
を更に含み、
前記クエリーを行うことは、クエリーを行うユーザーのプロファイルデータを用いてクエリーを行うことを含む、Ｚに記載の方法。

ＡＡ．第１のユーザーが持ち運んだ第１のポータブルデバイスで周辺音声のサンプルをキャプチャするステップと、
第２のユーザーが持ち運んだ第２のポータブルデバイスで周辺音声のサンプルをキャプチャするステップと、
前記第１のポータブルデバイスと前記第２のポータブルデバイスとに関連付いた位置データを参照することで、周辺音声のサンプルキャプチャ時に、前記第１のポータブルデバイスと前記第２のポータブルデバイスとが共通の環境にいたことを判断するステップと、
前記第１のポータブルデバイスと前記第２のポータブルデバイスによってサンプリングされた周辺音声に対応したデータを組み合わせ、分析することで、関連する第１の情報を生成するステップと、
前記第１の情報を参照することで、データ構造から、関連付けられた第２の情報を取得するステップと、
前記第２の情報の少なくとも一部を、前記第１のユーザーに提供するステップと、
を含み、
前記第１のユーザーに提供された前記情報は、少なくとも部分的には、前記第２のユーザーが持ち運んだ第２のポータブルデバイスでキャプチャされた周辺音声に基づく、方法。

前記第１の情報が歌を識別するデータで構成され、前記第２の情報が前記識別された歌に関連付けられたアーティスト情報で構成される、ＡＡに記載の方法。

前記第１の情報が一つ以上の語句から構成され、前記第２の情報が前記第１の情報に基づくインターネット検索の結果から構成される、ＡＡに記載の方法。

ＡＢ．複数の分散したコンピュータノードでデジタルの透かしまたはフィンガープリント技術を使用して自動的に検出した映像エンターテインメントコンテンツを示す、前記複数の分散したコンピュータノードからレポートデータを受信するステップと、
前記コンピュータノードの少なくともいくつかから、前記検出された映像エンターテインメントコンテンツの公共の利用可能性（public availability）を詳述するスケジュールデータを、１つ以上のコンテンツ配信元が追加的に受信するステップと、
ユーザー指定の映像コンテンツを視聴目的で入手することを可能にするソースとスケジュールとを詳述する番組中心型ディレクトリの形式で、前記データの少なくともいくらかをユーザーに提示するステップと、
を含む方法。

前記番組中心型ディレクトリは、前記ユーザー指定の映像コンテンツを視聴目的で入手する少なくとも２種類のアウトレットを識別し、
前記アウトレットの種類は、テレビネットワーク、ウェブサイトおよびピア・ツー・ピアネットワークから成るグループから選択される、ＡＢに記載の方法。

ＡＣ．映像エンターテインメントコンテンツの配信元において、ソースから映像エンターテインメントコンテンツを受信するステップと、
前記受信した映像エンターテインメントコンテンツから、デジタルの透かしまたはフィンガープリント識別データを検出するステップと、
前記検出した識別データに参照することで、前記配信元における当該のコンテンツの存在を、リモート番組ディレクトリデータベースに報告するステップと、
前記映像エンターテインメントコンテンツが公共で利用可能になるスケジュールを指定するスケジュール情報を、前記リモート番組ディレクトリデータベースに報告するステップと、
当該報告により、公共で利用することができる番組ディレクトリデータベースの自動編集によって、映像エンターテインメントコンテンツを取得するためのソースとスケジュールを識別することが可能になる、方法。

ＡＤ．有形の記憶媒体に保存されたデータ構造であって、前記データ構造により、適当なプログラミング指示によって構成されたプロセッサに対してコンテンツディレクトリを作成させ、前記コンテンツディレクトリは映像エンターテインメントコンテンツのタイトルを詳述し、前記コンテンツから複数のソースを取得することができ、前記ディレクトリは更に当該コンテンツの一次的な利用可能性を詳述するスケジュール情報を詳述し、前記ディレクトリからの情報は、ディスプレイ画面上でのユーザへの提示のために、前記ソースの一つから映像エンターテインメントコンテンツを取得するために利用される、データ構造。

ＡＥ．第１の画面から第２の画面に映像ゲームコンテンツを転送する方法であって、前記画面の一つがユーザーの携帯電話の一部を形成し、前記第１の画面が前記第１の画面に関連付いた第１のプロセッサを有し、前記第２の画面が前記第２の画面に関連付いた第２のプロセッサを有する方法が、
前記第１の画面と前記第２の画面とから区別されるリモートプロセッサ上で映像ゲームソフトウェアを実行するステップと、
前記の映像ゲームソフトウェアの実行からの出力を映像ストリームに変換するステップと、
前記第１の画面上に表示するために、前記映像ストリームを前記第１のプロセッサに送信するステップと、
前記ゲームプレーに関連して前記第１のプロセッサでユーザー入力を受信し、また、前記ユーザ入力を前記リモートプロセッサに送信するステップと、
ユーザー指示に対応して、前記送信した映像ストリームの送信先を、前記第１のプロセッサから前記第２のプロセッサに変更するステップと、
前記ユーザーが、ゲームのプレー中に、ゲームプレーを携帯電話の画面と別の画面との間で転送することができる、方法。

ＡＦ．映像エンターテインメントコンテンツを第１の画面から第２の画面に転送するシステムであって、
前記画面のうちの一つ、及び関連するプロセッサを含む携帯電話と、
前記第２の画面と関連する第２のプロセッサと、
前記第１の画面から前記第２の画面への映像エンターテインメントコンテンツの転送を開始するためにユーザーが作動させることのできるユーザーインターフェースコントロールを表示するための前記プロセッサの内の一つを設定する指示を格納するメモリと、
前記のユーザーインターフェースコントロールに反応して、前記第１の画面から前記第２の画面に映像エンターテインメントコンテンツを転送する手段と、
を備えるシステム。

ＡＧ．ユーザーを映像エンターテインメントコンテンツ内に参加させる方法であって、
映像エンターテインメントコンテンツを前記ユーザーに対して表示するステップと、
ユーザーの携帯電話を介して入力されるユーザー入力を受信するステップと、
前記受信したユーザ入力に応じて前記映像エンターテインメントコンテンツを適応させるステップと、
を含む方法。

前記ユーザー入力が音声を含む、ＡＧに記載の方法。

前記ユーザー入力が音声を含み、前記コンテンツに前記音声の少なくとも一部を含むことで、映像エンターテインメントコンテンツが適応される、ＡＧに記載の方法。

前記ユーザー入力が、前記携帯電話のユーザーの動作によって生じる身振り入力を含む、ＡＧに記載の方法

例えば、エミュレートされた行動を実行するためのプロセッサやモジュールを使用して、上述のＡ〜ＡＧに含まれる方法を実行する装置及びシステム。

一以上のコンピューターデバイスに対して上述のＡ〜ＡＧに含まれる方法を実行させる指示が保存されるディスク、メモリー及び他の有形媒体。

ここに示す技術を応用可能な多様な実装の観点から、特定の詳細アレンジメントはあくまで一例であり特許請求の範囲として記載された技術の範囲を限定するものではないことが理解されるべきである。むしろ、形式・機能におけるかかるバリエーションはすべて同等に下記の特許請求の範囲に含まれる。

Claims (5)

1. データベースが、複数の個人それぞれに対し、主要画面で見る主要エンターテインメントコンテンツの項目と、前記個人が前記主要画面で前記主要エンターテインメントコンテンツを見ながら第２の携帯デバイス画面で見るために前記個人が選択した二次的コンテンツの項目とに関する情報を収集するステップと、
   前記データベースが、第１の消費者が見ている主要エンターテインメントコンテンツの項目を示すデータを受信するステップであって、前記第１の消費者は前記複数の個人それぞれとは異なる、ステップと、
   前記データベースが、前記複数の個人それぞれに対して収集された情報に基づいて、前記第１の消費者が見ている前記主要エンターテインメントの項目と連動して第２の携帯デバイス画面で表示する二次的コンテンツの１つ以上の項目を提案するデータを送信するステップと、
   を含む方法。
2. 前記送信されるデータは、前記第１の消費者に関するプロファイル情報にさらに基づく、
   ことを特徴とする請求項１に記載の方法。
3. 前記収集した情報は、個人が見るために選択した二次的コンテンツであって前記主要エンターテインメントコンテンツのプロバイダによって提案されていない二次的コンテンツの少なくとも１つの項目を識別する、
   ことを特徴とする請求項１に記載の方法。
4. 画面とマイクとを備えた、ネットワーク接続した携帯装置であって、
   周囲の音声をマイクでサンプリングして、主要画面を通してユーザが見ている主要エンターテインメントコンテンツに対応する識別データを生成し、
   前記主要エンターテインメントコンテンツに関するデータをリモートシステムに送信し、
   前記携帯装置の画面に二次的コンテンツを表示し、
   前記二次的コンテンツに関するデータを前記リモートシステムに送信するように構成され、
   全体として、どのような主要コンテンツと連動してユーザがどのような二次的コンテンツを一般的に見ているかを識別することができるように、リモートシステムにデータを提供する、
   ことを特徴とする携帯装置。
5. テレビシステムと第２のデバイスとを用いる方法であり、前記テレビシステムと前記第２のデバイスとはそれぞれ画面を含み、前記テレビシステムの前記画面はユーザにテレビ番組を表示する、方法であって、
   前記第２のデバイスが、ユーザの選択したウェブページが前記第２のデバイスの画面に表示されることを要求するために、ウェブサイトに情報を送信するステップと、
   前記第２のデバイスが、前記ウェブサイトから提供されたウェブページ情報を受信し、前記ウェブページを前記第２のデバイスの画面に表示するステップと、
   を含み、
   前記第２のデバイスが前記ウェブサイトに送信する情報は、前記ユーザに表示されている前記テレビ番組を特定するデータを含み、
   前記ウェブサイトから受信する前記ウェブページ情報は、前記ユーザに表示されているテレビ番組に基づいてカスタマイズされており、
   前記ウェブサイトから提供された前記受信したウェブページ情報は、前記ユーザが第１テレビ番組又は第２テレビ番組のどちらを見ているかにより異なり、
   前記ウェブサイトは、ニュースウェブサイトであり、
   前記テレビ番組は、スポーツの試合を含み、
   前記ウェブサイトから受信する前記ウェブページ情報は、スポーツニュースをより目立たせるようにカスタマイズされる、
   方法。

Images