特表 2025-522452 高度テレビシステム委員会（ＡＴＳＣ）３．０システムにおける置換可能コンテンツの難読化

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2025-07-15

(54)【発明の名称】高度テレビシステム委員会（ＡＴＳＣ）３．０システムにおける置換可能コンテンツの難読化

(51)【国際特許分類】

   H04N 21/443 20110101AFI20250708BHJP

   H04N 21/6332 20110101ALI20250708BHJP

   H04H 20/28 20080101ALI20250708BHJP

   H04H 40/18 20080101ALI20250708BHJP

【ＦＩ】

H04N21/443

H04N21/6332

H04H20/28

H04H40/18

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024573651

(86)(22)【出願日】2023-05-31

(85)【翻訳文提出日】2024-12-13

(86)【国際出願番号】 IB2023055596

(87)【国際公開番号】W WO2023242663

(87)【国際公開日】2023-12-21

(31)【優先権主張番号】63/366,527

(32)【優先日】2022-06-16

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】17/935,076

(32)【優先日】2022-09-23

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＵＮＩＸ

２．ＪＡＶＡＳＣＲＩＰＴ

(71)【出願人】

【識別番号】000002185

【氏名又は名称】ソニーグループ株式会社

(74)【代理人】

【識別番号】100092093

【弁理士】

【氏名又は名称】辻居 幸一

(74)【代理人】

【識別番号】100109070

【弁理士】

【氏名又は名称】須田 洋之

(74)【代理人】

【識別番号】100067013

【弁理士】

【氏名又は名称】大塚 文昭

(74)【代理人】

【識別番号】100141553

【弁理士】

【氏名又は名称】鈴木 信彦

(74)【代理人】

【識別番号】100151987

【弁理士】

【氏名又は名称】谷口 信行

(72)【発明者】

【氏名】クリフト グラハム

(72)【発明者】

【氏名】フェイ ルーク

【テーマコード（参考）】

5C164

【Ｆターム（参考）】

5C164FA04

5C164FA11

5C164FA25

5C164MA05S

5C164TB22P

5C164UB38S

5C164UB51P

(57)【要約】

次世代放送テレビサービスをロバストに配信する上で、高度テレビシステム委員会（ＡＴＳＣ）３．０テレビプロトコルのＲＣの側面を隠す技術について説明する。このように、ＲＣの再生に必要な情報を挿入の発生直前に配信する（３０４）ことによってスキップ戦略を阻止することができる。
【選択図】図３

【特許請求の範囲】

【請求項1】

デジタルテレビシステムであって、
セグメントタイムラインシグナリングを有するデジタルテレビコンテンツの少なくとも１つの受信機を備え、前記受信機は命令をプログラムされており、前記命令は、
置換用コンテンツ（ＲＣ）に関する情報であって、前記ＲＣを再生するための開始時刻を含まない情報、又はデジタルテレビ放送局によって提供される放送アプリケーション（アプリ）のみが読み取ることができる形態で前記開始時刻を含む情報を受け取り、
前記開始時刻の直前に前記開始時刻の指示を受け取り、
前記開始時刻に前記ＲＣを再生する、
ように前記受信機を構成する、
ことを特徴とするシステム。

【請求項2】

前記命令は、
ダイナミック・アダプティブ・ストリーミング・オーバー・ハイパーテキスト・トランスファー・プロトコル（ＨＴＴＰ）（ＤＡＳＨ）メディアプレゼンテーション記述（ＭＰＤ）セグメントタイムラインタイムベースデータ構造で前記情報を受け取る、
ように実行可能である、請求項１に記載のシステム。

【請求項3】

前記情報は、メタデータのみを含んで、コンテンツ、又は置換すべきコンテンツの前記開始時刻又は継続時間を含まない早期利用可能期間（ＥＡＰ）内に受け取られる、
請求項２に記載のシステム。

【請求項4】

前記命令は、前記開始時刻の指示をコンピュータネットワークから受け取るように実行可能である、
請求項３に記載のシステム。

【請求項5】

前記情報は、メタデータのみを含んでコンテンツを含まず、前記放送局アプリのみが読み取ることができる形態で前記開始時刻の指示を含む、早期利用可能期間（ＥＡＰ）内に受け取られる、
請求項２に記載のシステム。

【請求項6】

前記命令は、少なくとも前記開始時刻の指示を前記放送局アプリから受信機アプリにおいて非暗号化形態で受け取って、前記開始時刻に前記ＲＣを再生するように前記受信機アプリを構成するよう実行可能である、
請求項５に記載のシステム。

【請求項7】

前記命令は、前記開始時刻の指示をＤＡＳＨ期間に含まれるイベントストリーム通知で受け取るように実行可能である、
請求項１に記載のシステム。

【請求項8】

前記命令は、
それぞれの拡張マークアップ言語（ＸＭＬ）リンキング言語（ＸＬｉｎｋ）にそれぞれが関連し、各ＸＬｉｎｋがそれぞれの継続時間に関連する、複数の早期使用可能期間（ＥＡＰ）を受け取り、
前記ＲＣの継続時間に関連するＸＬｉｎｋを含む前記ＥＡＰを選択する、
ように実行可能である、請求項２に記載のシステム。

【請求項9】

デジタルテレビシステムであって、
放送デジタルテレビコンテンツの少なくとも１つのソースと、
命令を構成された少なくとも１つのプロセッサと、
を備え、前記命令は、
置換用コンテンツ（ＲＣ）に関する情報であって、前記ＲＣを再生するための開始時刻を含まない情報、又はデジタルテレビ放送局によって提供される放送アプリケーション（アプリ）のみが読み取ることができる形態で前記開始時刻を含む情報を、少なくとも１つの受信機が前記情報を使用して前記ＲＣの挿入を準備し、前記ＲＣの挿入準備後に前記開始時刻の指示を受け取ることによって前記ＲＣを再生できるように、ダイナミック・アダプティブ・ストリーミング・オーバー・ハイパーテキスト・トランスファー・プロトコル（ＨＴＴＰ）（ＤＡＳＨ）メディアプレゼンテーション記述（ＭＰＤ）メディアプレゼンテーション記述（ＭＰＤ）セグメントタイムラインタイムベースデータ構造で前記受信機に送信する、
ように実行可能である、
ことを特徴とするデジタルテレビシステム。

【請求項10】

前記情報は、メタデータのみを含んでコンテンツ又は開始時刻を含まない早期利用可能期間（ＥＡＰ）内に送信される、
請求項９に記載のデジタルテレビシステム。

【請求項11】

前記命令は、コンピュータネットワークを使用して前記開始時刻の指示を前記受信機に送信するように実行可能である、
請求項１０に記載のデジタルテレビシステム。

【請求項12】

前記情報は、メタデータのみを含んでコンテンツを含まず、前記受信機内の放送局アプリのみが読み取ることができる形態で前記開始時刻を含む、早期利用可能期間（ＥＡＰ）内に送信される、
請求項９に記載のデジタルテレビシステム。

【請求項13】

前記命令は、前記開始時刻の指示をＤＡＳＨ期間に含まれるイベントストリーム通知で送信するように実行可能である、
請求項９に記載のデジタルテレビシステム。

【請求項14】

前記命令は、
それぞれの拡張マークアップ言語（ＸＭＬ）リンキング言語（ＸＬｉｎｋ）にそれぞれが関連し、各ＸＬｉｎｋがそれぞれの継続時間に関連する、複数の早期使用可能期間（ＥＡＰ）を前記受信機に送信し、
前記ＲＣの継続時間に関連するＸＬｉｎｋを含む前記ＥＡＰを前記受信機が選択できるように前記受信機に長さの指示を送信する、
ように実行可能である、請求項９に記載のデジタルテレビシステム。

【請求項15】

デジタルテレビシステムにおいて、
置換用コンテンツ（ＲＣ）に関する情報であって、前記ＲＣを再生するための開始時刻を含まない情報、又はデジタルテレビ放送局によって提供される放送アプリケーション（アプリ）のみが読み取ることができる形態で前記開始時刻を含む情報を受け取ることと、
前記ＲＣに関する情報を受け取った後に前記開始時刻を受け取ることと、
前記開始時刻に前記ＲＣを再生することと、
を含むことを特徴とする方法。

【請求項16】

ダイナミック・アダプティブ・ストリーミング・オーバー・ハイパーテキスト・トランスファー・プロトコル（ＨＴＴＰ）（ＤＡＳＨ）メディアプレゼンテーション記述（ＭＰＤ）セグメントタイムラインタイムベースデータ構造で前記情報を受け取ることを含む、
請求項１５に記載の方法。

【請求項17】

メタデータのみを含んでコンテンツ又は前記開始時刻の指示を含まない早期利用可能期間（ＥＡＰ）内に前記情報を受け取ることを含む、
請求項１６に記載の方法。

【請求項18】

前記開始時刻の指示をコンピュータネットワークから受け取ることを含む、
請求項１７に記載の方法。

【請求項19】

メタデータのみを含んでコンテンツを含まず、前記放送局アプリのみが読み取ることができる形態で前記開始時刻を含む、早期利用可能期間（ＥＡＰ）内に前記情報を受け取ることと、
前記開始時刻を前記放送局アプリから受信機アプリにおいて非暗号化形態で受け取って、前記開始時刻に前記ＲＣを再生するように前記受信機アプリを構成することと、
を含む、請求項１６に記載の方法。

【請求項20】

前記開始時刻の指示をＤＡＳＨ期間に含まれるイベントストリーム通知で受け取ることを含む、
請求項１６に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、デジタルテレビを対象とする、必然的にコンピュータ技術に根ざした技術的進歩に関し、具体的には高度テレビシステム委員会（ＡＴＳＣ）３．０に関する。

【背景技術】

【0002】

高度テレビシステム委員会（ＡＴＳＣ）３．０規格群は、Ａ／３００に示されている、次世代放送テレビを配信するための数多くの業界技術標準の組である。ＡＴＳＣ３．０は、超高精細テレビから無線電話機までの数多くの受信装置に対するテレビ放送メディア（ｔｅｌｅｖｉｓｅｄ ｍｅｄｉａ）、双方向サービス、非リアルタイムデータ配信、及び的を絞った広告（ｔａｉｌｏｒｅｄ ａｄｖｅｒｔｉｓｉｎｇ）などの幅広いデータサービスの提供をサポートする。ＡＴＳＣ３．０は、（「オーバージエア（Ｏｖｅｒ ｔｈｅ Ａｉｒ）」と呼ばれる）放送コンテンツと（「オーバーザトップ（Ｏｖｅｒ ｔｈｅ Ｔｏｐ）」と呼ばれる）関連するブロードバンド配信コンテンツ及びサービスとの間の協調も取りまとめる。本明細書で使用する「サービス」という用語は、ＡＴＳＣ３．０ではユーザに提示される一群のメディアコンポーネント全体であると定義されており、コンポーネントは複数のメディアタイプのものであることができる。サービスは、連続的又は断続的であることができる。サービスはリアルタイム又は非リアルタイムであり、リアルタイムサービスは一連のＴＶ番組から成る。ＡＴＳＣ３．０は、技術の進化と共にいずれかの関連する技術標準を全面的に見直す必要なく容易に進歩を組み込むことができるような柔軟性を有するように設計されている。本原理は、以下に示すような進歩に関する。

【発明の概要】

【課題を解決するための手段】

【0003】

本原理は、ＡＴＳＣ３．０広告の開始時刻及び継続時間を難読化して、受信機が放送局のビジネスモデルにとって不都合な広告スキップ戦略を採用するのを妨げることに関する。

【0004】

本明細書で理解されるように、ＡＴＳＣ３．０は、メディアプレゼンテーション記述（ＭＰＤ）を規定する国際標準ＩＳＯ／ＩＥＣ２３００９－１に記載されるようなダイナミック・アダプティブ・ストリーミング・オーバー・ハイパーテキスト・トランスファー・プロトコル（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）（ＤＡＳＨ））を使用してテレビコンテンツを提供することができる。ＡＴＳＣ３．０には、２つのタイプの動的ライブＭＰＤを使用して、リアルタイムで符号化され配信されるコンテンツを容易にすることに加え、いくつかのコンテンツを特定のユーザに合わせた置換用コンテンツ（ＲＣ）に置き換えることを可能にすることが規定されている。第１のタイプの動的ライブＭＰＤは、セグメントテンプレートに基づくセグメント命名規則（ｓｅｇｍｅｎｔ ｎａｍｉｎｇ ｃｏｎｖｅｎｔｉｏｎ）、及び増分的付番スキーム（ｉｎｃｒｅｍｅｎｔａｌ ｎｕｍｂｅｒｉｎｇ ｓｃｈｅｍｅ）を使用し、これらはコンテンツの再生時に継続的に更新されることを必要とすることも又はしないこともあり、符号化ストリームのいわゆる「ライブエッジ」に存在する利用可能なセグメントの番号、従って名前を正しく推測するために、放送に同期した受信機上のクロックを必要とする。動的ライブＭＰＤのセグメント付番テンプレートタイプは、オーバージエア（ＯＴＡ）で配信されるコンテンツに適しており、デコーダのクロックをＯＴＡ放送のクロックと同期させてスタンバイ状態で維持することもできる。

【0005】

第２のタイプの動的ライブＭＰＤは、セグメントタイムテンプレートを使用してセグメント名にセグメントの開始時刻のプレゼンテーションタイムスタンプ（ｐｒｅｓｅｎｔａｔｉｏｎ ｔｉｍｅｓｔａｍｐ：ＰＴＳ）を明示的に含めるとともに、受信機上で再生可能なセグメントのみをリストする。第２のタイプの動的ライブＭＰＤは、同期したブロードキャストクロックが利用可能でない場合、又はセグメントのライブエンコーディングによってセグメントの継続時間が変動して事前によく分からない場合にオーバーザトップ（ＯＴＴ）でライブ配信されるセグメントに特に適している。セグメントタイムラインは、ＤＡＳＨ ＭＰＤのセグメントタイムライン（ＳｅｇｍｅｎｔＴｉｍｅｌｉｎｅ）要素に表される。セグメント番号テンプレートのインデックスモードとは異なり、動的ライブセグメントタイムテンプレート内の明示的に定義されたセグメントは、常に受信機がこれを利用できなければならず、従ってリスト内の最後のセグメントは、クロック同期を必要としないライブエッジであることが知られている。従って、この第２のタイプの動的ライブＭＰＤは、受信機クロックが技術的な理由で放送局クロックと同期しておらず（或いは同期可能でもなく）、特にストリーム内のセグメントが放送チャンネル内のクロックと正確に同期せずにＯＴＴで配信されている場合の課題に対処する。最初に特定のチャンネルに同調した受信機は、単純にＭＰＤ内の情報からライブエッジを取り出すことによってそこから直ちに再生を開始することができる。

【0006】

従って、１つの態様では、高度テレビシステム委員会（ＡＴＳＣ）３．０システムなどのデジタルテレビシステムが、セグメントタイムラインシグナリングを有するデジタルテレビコンテンツの少なくとも１つの受信機を含む。放送ストリームは、置換可能なコンテンツの期間を含むが、コンテンツを再生する必要がある開始時刻、置換すべきコンテンツの継続時間の指示、又はコンテンツがいつ置換されるかについての指示に関する情報を初期には含まない、セグメントタイムラインベースのＭＰＤを使用するように構成される。ＡＴＳＣ３．０システムでは、ＡＴＳＣ３．０に定められるメカニズムを通じてストリーム内のメタデータを取り出してメタデータをアプリに配信できる放送局アプリケーション（アプリ）を受け取って開始することができ、通常、メタデータはアプリのみに知られているスキームで難読化される。アプリは、開始時刻及び継続時間がどうなっているかをメタデータから解釈するとともに、ＲＣをダウンロードしてキャッシュするように受信機に命令するのに適した時刻、及びＲＣを再生できるＭＰＤ期間を受信機が準備するのに適した時刻を知ることができる。通常、この最後のステップはＲＣの再生開始時刻の直前である。

【0007】

実装例では、命令が、ダイナミック・アダプティブ・ストリーミング・オーバー・ハイパーテキスト・トランスファー・プロトコル（ＨＴＴＰ）（ＤＡＳＨ）メディアプレゼンテーション記述（ＭＰＤ）セグメントタイムラインタイムベースデータ構造で情報を受け取るように実行可能であることができる。ＲＣに関する情報は、拡張可能マークアップ言語（ＸＭＬ）リンキング言語（ＸＬｉｎｋ）メタデータのみを含んでコンテンツ、コンテンツの継続時間及び／又は開始時刻を含まない、ＩＳＯ／ＩＥＣ ２３００９－１（ＤＡＳＨ）に記載されている早期利用可能期間（Ｅａｒｌｙ Ａｖａｉｌａｂｌｅ Ｐｅｒｉｏｄ：ＥＡＰ）内に受け取ることができる。このような事例では、放送局アプリが、将来の時点でコンテンツを置き換えるのに必要な開始時刻及びコンテンツ継続時間を受け取るために、コンピュータネットワークを利用してメタデータを解釈することができる。

【0008】

或いは、ＲＣに関する情報は、ＸＬｉｎｋのみを含んでコンテンツを含まず、放送局アプリのみが読み取ることができる形態で開始時刻及び／又はコンテンツの長さを含む、早期利用可能期間（ＥＡＰ）内に受け取ることもできる。このような事例では、命令が、開始時刻及びコンテンツの長さを受信機アプリにおいて放送局アプリから非暗号化形態で受け取って、開始時刻にＲＣを再生するように受信機アプリを構成するよう実行可能であることができる。

【0009】

さらに、命令は、開始時刻及び／又はコンテンツ継続時間の指示を、ＸＬｉｎｋを含むＥＡＰの前のＤＡＳＨ期間に含まれるイベントストリーム通知で受け取るように実行可能であることもできる。

【0010】

いくつかの例では、置換すべきコンテンツのそれぞれの継続時間に関連するＸＬｉｎｋをそれぞれが含む複数の早期利用可能期間（ＥＡＰ）。命令は、開始時刻の指示を受け取ることに応答して、ＲＣの継続時間に関連するＸＬｉｎｋを含むＥＡＰを選択するように実行可能であることができる。

【0011】

別の態様では、デジタルテレビシステムが、放送デジタルテレビコンテンツの少なくとも１つのソースと、ダイナミック・アダプティブ・ストリーミング・オーバー・ハイパーテキスト・トランスファー・プロトコル（ＨＴＴＰ）（ＤＡＳＨ）メディアプレゼンテーション記述（ＭＰＤ）セグメントタイムラインデータ構造で少なくとも１つの受信機に情報を送信するように実行可能な命令を構成された少なくとも１つのプロセッサとを含む。情報は、置換用コンテンツ（ＲＣ）に関連するとともに、ＲＣを再生する開始時刻及び／又は置換すべきコンテンツの継続時間を含まず、或いは受信機がこの情報を使用してＲＣの挿入を準備し、ＲＣの挿入準備後に開始時刻の指示を受け取ることによってＲＣを再生できるように、デジタルテレビ放送局によって提供される放送アプリケーション（アプリ）のみが読み取ることができる形態で開始時刻及び／又は継続時間を含むことができる。デジタルテレビロジックは、置換可能コンテンツを自ら選択し（クライアント側コンテンツ交換）、又は放送局アプリケーションによる選択を可能にする（サーバ側コンテンツ交換）ことができる。

【0012】

別の態様では、デジタルテレビシステムにおいて、方法が、置換用コンテンツ（ＲＣ）に関する情報であって、ＲＣを再生するための開始時刻又は置換すべきコンテンツの継続時間を含まない情報、又はデジタルテレビ放送局によって提供される放送アプリケーション（ａｐｐ）のみが読み取ることができる形態で開始時刻及び継続時間を含む情報を受け取ることを含む。方法は、この情報を使用してＲＣの挿入を準備し、ＲＣに関する情報を受け取った後に開始時刻の非暗号化指示を受け取ることを含む。開始時刻にＲＣが再生される。

【0013】

本出願の詳細は、その構造及び動作の両方に関し、同様の要素を同様の参照符号で示す添付図面を参照することで最も良く理解することができる。

【図面の簡単な説明】

【0014】

【図1】高度テレビシステム委員会（ＡＴＳＣ）３．０システムのブロック図である。

【図2】図１に示す装置のコンポーネントを示すブロック図である。

【図3】全体的ロジック例をフローチャートフォーマット例で示す図である。

【図4】早期利用可能期間（ＥＡＰ）ベースのロジック例をフローチャートフォーマット例で示す図である。

【図5】イベントストリームベースのロジック例をフローチャートフォーマット例で示す図である。

【図6】ＲＣ開始時刻が空白のままであるＤＡＳＨマニフェストファイルの一部の例を示す図である。

【図7】放送局アプリのみが復号して読むことができるようにＲＣ開始時刻が暗号化されたＤＡＳＨマニフェストファイルの一部の例を示す図である。

【発明を実施するための形態】

【0015】

本開示は、高度テレビシステム委員会（ＡＴＳＣ）３．０テレビの技術的進歩に関する。本明細書におけるシステムは、互いにデータを交換できるように放送及び／又はネットワークを介して接続されたＡＴＳＣ３．０ソースコンポーネント及びクライアントコンポーネントを含むことができる。クライアントコンポーネントは、テレビ（例えば、スマートＴＶ、インターネット対応ＴＶ）、ラップトップ及びタブレットコンピュータなどのパーソナルコンピュータ、並びにスマートフォン及び後述するさらなる例を含むモバイル装置などの１又は２以上のコンピュータ装置を含むことができる。これらのクライアント装置は、様々な動作環境で動作することができる。例えば、クライアントコンピュータの一部は、一例としてＭｉｃｒｏｓｏｆｔ社のオペレーティングシステム、又はＵｎｉｘオペレーティングシステム、或いはＡｐｐｌｅ Ｃｏｍｐｕｔｅｒ社又はＧｏｏｇｌｅ社によって製造されたＡｎｄｒｏｉｄ（登録商標）などのオペレーティングシステムを採用することができる。これらの動作環境は、Ｍｉｃｒｏｓｏｆｔ社、Ｇｏｏｇｌｅ社又はＭｏｚｉｌｌａによって作成されたブラウザ、或いは後述するインターネットサーバによってホストされたウェブサイトにアクセスできるその他のブラウジングプログラムなどの１又は２以上のブラウジングプログラムを実行するために使用することができる。

【0016】

ＡＴＳＣ３．０ソースコンポーネントは、放送送信コンポーネントと、インターネットなどのネットワークを介したデータ放送及び／又はデータ送信を行うようにソースコンポーネントを構成する命令を実行する１又は２以上のプロセッサを含むことができるサーバ及び／又はゲートウェイとを含むことができる。クライアントコンポーネント及び／又はローカルＡＴＳＣ３．０ソースコンポーネントとしては、Ｓｏｎｙ ＰｌａｙＳｔａｔｉｏｎ（登録商標）などのゲーム機、パーソナルコンピュータなどを具体例として挙げることができる。

【0017】

クライアントとサーバとの間では、ネットワークを介して情報を交換することができる。この目的及びセキュリティのために、サーバ及び／又はクライアントは、ファイヤウォール、ロードバランサ、一時ストレージ、及びプロキシ、並びに真正性及びセキュリティを高めるその他のネットワークインフラを含むことができる。

【0018】

本明細書で使用する命令とは、システム内で情報を処理するためのコンピュータ実装ステップのことを意味する。命令は、ソフトウェア、ファームウェア又はハードウェアに実装することができ、システムのコンポーネントが請け負うあらゆるタイプのプログラムステップを含むことができる。

【0019】

プロセッサは、アドレス回線、データ回線及び制御回線などの様々な回線、並びにレジスタ及びシフトレジスタによってロジックを実行できる従来の汎用シングルチップ又はマルチチッププロセッサであることができる。

【0020】

フローチャートによって説明するソフトウェアモジュール、及び本明細書におけるユーザインターフェイスは、様々なサブルーチン、手続きなどを含むことができる。本開示を限定することなく、特定のモジュールによって実行されるものとして開示するロジックは、他のソフトウェアモジュールに再分配し、及び／又は単一のモジュールに組み合わせ、及び／又は共有可能なライブラリ内で利用することもできる。フローチャートフォーマットを使用することもできるが、ソフトウェアは状態機械又はその他の論理的方法として実装することもできると理解されたい。

【0021】

本明細書で説明する本原理は、ハードウェア、ソフトウェア、ファームウェア又はこれらの組み合わせとして実装することができ、従って例示的なコンポーネント、ブロック、モジュール、回路及びステップについてはこれらの機能面から説明する。

【0022】

上記で示唆したものに加え、論理ブロック、モジュール及び回路は、汎用プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、又は特定用途向け集積回路（ＡＳＩＣ）などの他のプログラマブルロジックデバイス、離散ゲート又はトランジスタロジック、離散ハードウェアコンポーネント、又は本明細書で説明する機能を実行するように設計されたこれらのいずれかの組み合わせを使用して実装又は実行することができる。プロセッサは、コントローラ、状態機械、又はコンピュータ装置の組み合わせによって実装することができる。

【0023】

以下で説明する機能及び方法は、ソフトウェアで実装した場合、以下に限定するわけではないが、ハイパーテキストマークアップ言語（ＨＴＭＬ）－５、Ｊａｖａ（登録商標）／Ｊａｖａｓｃｒｉｐｔ、Ｃ＃、Ｃ＋＋などの適当な言語で書くことができ、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、電気的に消去可能でプログラム可能なリードオンリメモリ（ＥＥＰＲＯＭ）、コンパクトディスクリードオンリメモリ（ＣＤ－ＲＯＭ）、又はデジタル多用途ディスク（ＤＶＤ）などの他の光ディスクストレージ、磁気ディスクストレージ、又は取り外し可能なサムドライブなどを含む他の磁気ストレージ装置などのコンピュータ可読記憶媒体に記憶し、又はこれらを通じて伝送することができる。ある接続は、コンピュータ可読媒体を構築することができる。このような接続は、一例として、光ファイバ、同軸線、デジタル加入者回線（ＤＳＬ）及びツイストペア線を含む有線ケーブルを含むことができる。

【0024】

１つの実施形態に含まれるコンポーネントは、他の実施形態においていずれかの適切な組み合わせで使用することができる。例えば、本明細書において説明する及び／又は図に示す様々なコンポーネントのいずれかは、組み合わせ、置き換え、又は他の実施形態から除外することができる。

【0025】

「Ａ、Ｂ及びＣのうちの少なくとも１つを有するシステム（同様に、「Ａ、Ｂ又はＣのうちの少なくとも１つを有するシステム」、及び「Ａ、Ｂ、Ｃのうちの少なくとも１つを有するシステム」）」は、Ａのみ、Ｂのみ、Ｃのみ、ＡとＢの両方、ＡとＣの両方、ＢとＣの両方、及び／又はＡとＢとＣ全てなどを有するシステムを含む。

【0026】

図１を参照すると、「放送局設備」１０として表記するＡＴＳＣ３．０ソースコンポーネントの例が、典型的には１対多の関係で直交周波数分割多重（ＯＦＤＭ）を介してＡＴＳＣ３．０テレビなどの複数の受信機１４にテレビデータを無線で放送するオーバージエア（ＯＴＡ）設備１２を含むことができる。１又は２以上の受信機１４は、Ｂｌｕｅｔｏｏｔｈ（登録商標）、低エネルギーＢｌｕｅｔｏｏｔｈ、その他の近距離無線通信（ＮＦＣ）プロトコル、赤外線（ＩＲ）などによって実装できる、典型的には無線である短距離リンク１８を介してリモコン装置、タブレットコンピュータ及び携帯電話機などの１又は２以上のコンパニオンデバイス１６と通信することができる。

【0027】

また、受信機１４のうちの１つ又は２つ以上は、インターネットなどの有線及び／又は無線ネットワークリンク２０を介して放送局設備１０のオーバーザトップ（ＯＴＴ）設備２２と、典型的には１対１の関係で通信することもできる。ＯＴＡ設備１２は、ＯＴＴ設備２２と同じ位置に存在することができ、或いは放送局設備１０の両設備１２、２２は、互いに離れて適切な手段を通じて互いに通信することもできる。いずれにせよ、受信機１４は、同調したＡＴＳＣ３．０テレビサービスを介してＡＴＳＣ３．０テレビ信号をＯＴＡで受信することも、或いはテレビを含む関連コンテンツをＯＴＴ（ブロードバンド）経路経由で受信することもできる。なお、本明細書の全ての図において説明するコンピュータ装置は、図１及び図２の様々な装置について示すコンポーネントの一部又は全部を含むことができる。

【0028】

次に図２を参照すると、図１に示すコンポーネントの詳細を見ることができる。図２には、ハードウェアとソフトウェアとの組み合わせによって実装できるプロトコルスタックを示す。後述するように、放送局は、図２に示す放送局側のために適宜に修正されたＡＴＳＣ３．０プロトコルスタックを使用して、（本明細書では「ブロードバンド」及び「オーバーザトップ」（ＯＴＴ）と呼ぶ）コンピュータネットワークと、（本明細書では「放送」及び「オーバージエア」（ＯＴＡ）と呼ぶ）無線放送とを介して１又は２以上の番組要素を配信するハイブリッドサービス配信を送信することができる。

【0029】

放送局設備１０は、本明細書で説明するいずれかのメモリ又はストレージなどの１又は２以上のコンピュータ記憶媒体２０２にアクセスして最上位のアプリケーション層２０４において１又は２以上のソフトウェアアプリケーションを提供する１又は２以上のプロセッサ２００を含むことができる。アプリケーション層２０４は、ランタイム環境で動作する、例えばＨＴＭＬ５／Ｊａｖａｓｃｒｉｐｔで書かれた１又は２以上のソフトウェアアプリケーションを含むことができる。限定するわけではないが、アプリケーションスタック２０４のアプリケーションは、リニアＴＶアプリケーション、インタラクティブサービスアプリケーション、コンパニオンスクリーンアプリケーション、個人化アプリケーション、緊急アラートアプリケーション、及び使用報告アプリケーションを含むことができる。通常、アプリケーションは、ビデオコーディング、オーディオコーディング及びランタイム環境を含む、視聴者が体験する要素を表すソフトウェアで具現化される。一例として、ユーザによるダイアログの制御、代替オーディオトラックの使用、並びに正規化及びダイナミックレンジなどのオーディオパラメータの制御などを可能にするアプリケーションを提供することができる。

【0030】

アプリケーション層２０４の下位にはプレゼンテーション層２０６が存在する。プレゼンテーション層２０６は、受信機に実装された時に無線で放送されたオーディオビデオコンテンツを復号して１又は２以上のディスプレイ及びスピーカ上で再生するメディア処理ユニット（ＭＰＵ）２０８と呼ばれる放送オーディオビデオ再生装置を放送（ＯＴＡ）側に含む。ＭＰＵ２０８は、国際標準化機構（ＩＳＯ）ベースメディアファイルフォーマット（ＢＭＦＦ）データ表現２１０、及び高効率ビデオコーディング（ＨＥＶＣ）のビデオを、例えばドルビーオーディオ圧縮（ＡＣ）－４フォーマットのオーディオで提示するように構成される。ＩＳＯ ＢＭＦＦは、「セグメント」とプレゼンテーションメタデータとに分割される時間ベースのメディアファイルのための一般的ファイル構造である。基本的に、各ファイルは、それぞれがタイプ及び長さを有する一群のネスト化オブジェクト（ｎｅｓｔｅｄ ｏｂｊｅｃｔｓ）である。ＭＰＵ２０８は、暗号解読を容易にするために、放送側暗号化メディア拡張（ｅｎｃｒｙｐｔｅｄ ｍｅｄｉａ ｅｘｔｅｎｓｉｏｎ：ＥＭＥ）／共通暗号化（ｃｏｍｍｏｎ ｅｎｃｒｙｐｔｉｏｎ：ＣＥＮＣ）モジュール２１２にアクセスすることができる。

【0031】

図２には、放送側において、プレゼンテーション層２０６が、アプリケーション層２０４にアクセス可能な非リアルタイム（ＮＲＴ）コンテンツ２１８を配信するために、動画専門家集団（ＭＰＥＧ）メディア転送プロトコル（ＭＭＴＰ）シグナリングモジュール２１４、又は単方向トランスポートを介したリアルタイムオブジェクト配信（ｒｅａｌ－ｔｉｍｅ ｏｂｊｅｃｔ ｄｅｌｉｖｅｒｙ ｏｖｅｒ ｕｎｉｄｉｒｅｃｔｉｏｎａｌ ｔｒａｎｓｐｏｒｔ：ＲＯＵＴＥ）シグナリングモジュール２１６のいずれかを含むシグナリングモジュールを含むことができることをさらに示す。ＮＲＴコンテンツは、限定するわけではないが、記憶された置換用広告を含むことができる。

【0032】

ブロードバンド（ＯＴＴ又はコンピュータネットワーク）側では、受信機によって実装された場合、プレゼンテーション層２０６が、インターネットからのオーディオビデオコンテンツを復号して再生するために、１又は２以上のダイナミック・アダプティブ・ストリーミング・オーバー・ハイパーテキスト・トランスファー・プロトコル（ＨＴＴＰ）（ＤＡＳＨ）プレーヤ／デコーダ２２０を含むことができる。この目的のために、ＤＡＳＨプレーヤ２２０は、ブロードバンド側のＥＭＥ／ＣＥＮＣモジュール２２２にアクセスすることができる。ＤＡＳＨコンテンツは、ＩＳＯ／ＢＭＦＦフォーマットのＤＡＳＨセグメント２２４として提供することができる。

【0033】

プレゼンテーション層２０６のブロードバンド側は、放送側と同様に、ファイル２２６内にＮＲＴコンテンツを含むとともに、再生シグナリングを提供するシグナリングオブジェクト２２８を含むことができる。

【0034】

プロトコルスタック内のプレゼンテーション層２０６の下位にはセッション層２３０が存在する。セッション層２３０は、放送側にＭＭＴＰプロトコル２３２又はＲＯＵＴＥプロトコル２３４のいずれかを含む。なお、ＡＴＳＣ標準は、伝送にＭＰＥＧ ＭＭＴを使用するオプションを提供するが、ここには示していない。

【0035】

セッション層２３０は、ブロードバンド側にＨＴＴＰ－ｓｅｃｕｒｅ（ＨＴＴＰ（Ｓ））として実装できるＨＴＴＰプロトコル２３６を含む。セッション層２３０のブロードバンド側は、ＨＴＴＰプロキシモジュール２３８及びサービスリストテーブル（ＳＬＴ）２４０を採用することもできる。ＳＬＴ２４０は、基本サービスリストを構築して放送コンテンツのブートストラップ発見を提供するために使用されるシグナリング情報のテーブルを含む。「ＲＯＵＴＥシグナリング」テーブルには、ＲＯＵＴＥトランスポートプロトコルによってユーザデータグラムプロトコル（ＵＤＰ）を介して配信されるメディアプレゼンテーション記述（ＭＰＤ）が含まれる。

【0036】

プロトコルスタック内のセッション層２３０の下位には、低遅延かつ損失耐性のある（ｌｏｓｓ－ｔｏｌｅｒａｔｉｎｇ）接続を確立するためのトランスポート層２４２が存在する。トランスポート層２４２は、放送側ではＵＤＰ２４４を使用し、ブロードバンド側では伝送制御プロトコル（ＴＣＰ）２４６を使用する。

【0037】

プロトコルスタックは、トランスポート層２４２の下位にネットワーク層２４８も含む。ネットワーク層２４８は、ＩＰパケット通信のために両方の側においてインターネットプロトコル（ＩＰ）を使用し、放送側ではマルチキャスト配信が典型的であり、ブロードバンド側ではユニキャストが典型的である。

【0038】

ネットワーク層２４８の下位には、両方の側に関連するそれぞれの物理媒体上で通信を行うための放送送信／受信設備２５２及び（単複の）コンピュータネットワークインターフェイス２５４を含む物理層２５０が存在する。物理層２５０は、機械アクセスコード（ＭＡＣ）フォーマットを関連する媒体上での伝送に適するように変換して、受信機における誤り訂正を可能にする順方向誤り訂正機能を追加するとともに、変調及び復調機能を組み込むために変調及び復調モジュールを含むことができる。物理層２５０は、長距離送信及び帯域幅効率向上のためにビットをシンボルに変換する。物理層２５０は、通常、ＯＴＡ側には直交周波数分割多重（ＯＦＤＭ）を使用して無線でデータを放送する無線放送送信機を含み、ＯＴＴ側にはインターネットを介してデータを送信するコンピュータ送信コンポーネントを含む。

【0039】

ブロードバンド側では、プロトコルスタック内の様々なプロトコル（ＨＴＴＰ／ＴＣＰ／ＩＰ）を通じて送信されるＤＡＳＨ業界フォーラム（ＤＡＳＨ Ｉｎｄｕｓｔｒｙ Ｆｏｒｕｍ：ＤＡＳＨ－ＩＦ）プロファイルを使用することができる。ＩＳＯ ＢＭＦＦに基づくＤＡＳＨ－ＩＦプロファイル内のメディアファイルは、放送配信及びブロードバンド配信の両方のための配信、メディアカプセル化及び同期フォーマットとして使用することができる。

【0040】

通常、各受信機１４は、放送局設備のプロトコルスタックと相補的なプロトコルスタックを含む。

【0041】

図１の受信機１４は、図２に示すように、（ＴＶモニタにオーディオビジュアル表示を提供するセットトップボックスと同等の）ＡＴＳＣ３．０ＴＶチューナ２５６を有するインターネット対応ＴＶを含むことができる。受信機１４内のソフトウェアアーキテクチャは、Ａｎｄｒｏｉｄ（登録商標）オペレーティングシステムに基づくことができる。或いは、受信機１４は、コンピュータ化されたインターネット対応（「スマート」）電話機、タブレットコンピュータ、ノートブックコンピュータ、及びウェアラブルコンピュータ装置などによって実装することもできる。それにもかかわらず、本明細書で説明する受信機１４及び／又は他のコンピュータは、本原理を実施する（例えば、他の装置と通信して本原理を実施し、本明細書で説明するロジックを実行し、本明細書で説明する他のいずれかの機能及び／又は動作を実行する）ように構成されると理解されたい。

【0042】

従って、受信機１４は、このような原理を実施するために、図１に示すコンポーネントの一部又は全部によって構築することができる。例えば、受信機１４は、高精細又は超高精細「４Ｋ」又はそれ以上のフラットスクリーンによって実装され、ディスプレイ上のタッチを介してユーザ入力信号を受け取るタッチ対応型であることも又はそうでないこともできる１又は２以上のディスプレイ２５８を含むことができる。受信機１４は、本原理に従ってオーディオを出力するための１又は２以上のスピーカ２６０と、例えば受信機１４を制御する可聴コマンドを受信機１４に入力するための、例えばオーディオ受信機／マイクなどの少なくとも１つのさらなる入力装置２６２とを含むこともできる。受信機１４の例としては、１又は２以上のプロセッサ２６６の制御下でインターネット、ＷＡＮ、ＬＡＮ、ＰＡＮなどの少なくとも１つのネットワークを介して通信するための１又は２以上のネットワークインターフェイス２６４をさらに挙げることができる。従って、インターフェイス２６４は、限定するわけではないがメッシュネットワークトランシーバなどの無線コンピュータネットワークインターフェイスの一例であるＷｉ－Ｆｉトランシーバであることができる。インターフェイス２６４は、以下に限定するわけではないが、Ｂｌｕｅｔｏｏｔｈ（登録商標）トランシーバ、Ｚｉｇｂｅｅ（登録商標）トランシーバ、赤外線通信協会（ＩｒＤＡ）トランシーバ、無線ＵＳＢトランシーバ、有線ＵＳＢ、有線ＬＡＮ、電力線又はＭｕｌｔｉｍｅｄｉａ ｏｖｅｒ Ｃｏａｘ Ａｌｌｉａｎｃｅ（ＭｏＣＡ）であることができる。プロセッサ２６６は、例えば画像の提示及び入力の受信を行うようにディスプレイ２５８を制御することなどの、本明細書で説明した受信機１４の他の要素を含めて本原理を実施するように受信機１４を制御すると理解されたい。さらに、ネットワークインターフェイス２６４は、例えば有線又は無線モデム又はルータ、或いは無線電話トランシーバ又は上述したＷｉ－Ｆｉトランシーバなどの他の適切なインターフェイスであることができる。

【0043】

上記に加えて、受信機１４は、別のＣＥ装置に（有線接続を使用して）物理的に接続するための、高精細マルチメディアインターフェイス（ＨＤＭＩ(登録商標)）ポート又はＵＳＢポートなどの１又は２以上の入力ポート２６８、及び／又は受信機１４にヘッドフォンを接続して受信機１４からヘッドフォンを通じてユーザにオーディオを提示するためのヘッドフォンポートを含むこともできる。例えば、入力ポート２６８は、有線又は無線を介してオーディオビデオコンテンツのケーブル又は衛星ソースに接続することができる。従って、ソースは、独立した又は統合されたセットトップボックス又は衛星受信機であることができる。或いは、ソースは、ゲーム機又はディスクプレーヤであることもできる。

【0044】

受信機１４は、いくつかの事例では受信機のシャーシ内にスタンドアロン装置として、受信機のシャーシの内部又は外部の、オーディオビデオ（ＡＶ）プログラムを再生するためのパーソナルビデオ録画装置（ＰＶＲ）又はビデオディスクプレーヤとして、或いは取り外し可能記憶媒体として具現化される、一時的信号ではないディスクベースストレージ又はソリッドステートストレージなどの１又は２以上のコンピュータメモリ２７０をさらに含むことができる。また、いくつかの実施形態では、受信機１４が、例えば少なくとも１つの衛星又は携帯電話タワーから地理的位置情報を受け取ってこの情報をプロセッサ２６６に提供し、及び／又は受信機１４がプロセッサ２６６と共に配置される高度を決定するように構成された、限定するわけではないが、携帯電話受信機、全地球測位衛星（ＧＰＳ）受信機、及び／又は高度計などの位置又は場所受信機２７２を含むこともできる。しかしながら、例えば３次元全てにおいて受信機１４の位置を決定するために、本原理に従って携帯電話受信機、ＧＰＳ受信機及び／又は高度計以外の別の好適な位置受信機を使用することもできると理解されたい。

【0045】

受信機１４の説明を続けると、いくつかの実施形態では、受信機１４が、本原理に従って写真／画像及び／又はビデオを収集するために、熱探知カメラ、ウェブカメラなどのデジタルカメラ、及び／又は受信機１４に統合されてプロセッサ２６６によって制御可能なカメラのうちの１つ又は２つ以上を含むことができる１又は２以上のカメラ２７４を含むことができる。また、受信機１４には、Ｂｌｕｅｔｏｏｔｈ（登録商標）及び／又はＮＦＣ技術を使用して他の装置と通信するためのＢｌｕｅｔｏｏｔｈ（登録商標）トランシーバ２７６又は他の近距離通信（ＮＦＣ）要素をそれぞれ含めることもできる。ＮＦＣ要素例は、無線周波数識別（ＲＦＩＤ）要素であることができる。

【0046】

さらに、受信機１４は、プロセッサ２６６に入力を提供する（加速度計、ジャイロスコープ、サイクロメータ又は磁気センサ及びこれらの組み合わせなどのモーションセンサなどの）１又は２以上の補助センサ２７８、リモコン装置からＩＲコマンドを受け取るための赤外線（ＩＲ）センサ、光学センサ、速度及び／又はケイデンスセンサ（ｃａｄｅｎｃｅ ｓｅｎｓｏｒ）、（ジェスチャコマンドを検知するための）ジェスチャセンサなどを含むこともできる。無線リモコンからコマンドを受け取るためにＩＲセンサ２８０を設けることもできる。受信機１４に電力を供給するためにバッテリ（図示せず）を設けることもできる。

【0047】

コンパニオンデバイス１６は、上述した受信機１４に関連して示した要素の一部又は全部を含むことができる。

【0048】

本明細書で説明する方法は、プロセッサ、好適に構成された特定用途向け集積回路（ＡＳＩＣ）又はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）モジュール、又は当業者が理解するであろう他のいずれかの便利な方法によって実行されるソフトウェア命令として実装することができる。ソフトウェア命令は、採用する場合にはＣＤ ＲＯＭ又はフラッシュドライブなどの非一時装置に具現化することができる。或いは、ソフトウェアコード命令は、無線信号又は光信号などの一時的構成で、又はインターネットを介したダウンロードを通じて具現化することもできる。

【0049】

図３に進む前に、ＡＴＳＣ３．０ではＡＶコンテンツの送信にＭＰＥＧ ＤＡＳＨが使用され、このコンテンツは、広告などの置換用コンテンツ（ＲＣ）、又はユーザ個人向け置換（ｕｓｅｒ ｐｅｒｓｏｎａｌｉｚｅｄ ｒｅｐｌａｃｅｍｅｎｔ）を意図されたコンテンツを含むことができる。（ＡＴＳＣ Ａ／３４４で述べられているように）ＡＴＳＣ３．０は、ＸＬｉｎｋタグを含む多期間（Ｍｕｌｔｉ ｐｅｒｉｏｄｓ）を使用してこのようなＲＣの位置をシグナリングする。しかしながら、本明細書で理解されるように、これによってクライアントが容易にスキップできるＲＣの位置が予め知られてしまう恐れがあり、放送局のビジネスモデルにとっては不都合である。本原理は、ＤＡＳＨマニフェストファイル内のジャストインタイム（ｊｕｓｔ ｉｎ ｔｉｍｅ：ＪＩＴ）情報を配信するＭＰＥＧ ＤＡＳＨ ＭＰＤのセグメントタイムライン要素を活用することができる（ＭＰＤは、追加セグメント毎に更新される）。ＪＩＴ情報は、新たな期間の高度な知識を最終最後の瞬間まで防ぎ、「悪質な」受信機による浅はかなＲＣ置換戦略を排除する。ＸＬｉｎｋは、アプリケーションがクライアント受信機を呼び出してコンテンツをキャッシュし、既存のコンテンツを置き換える準備をする必要があることを放送局アプリケーション（放送局から供給され、クライアント受信機のＨＴＭＬ５サービス上で動作するアプリケーション）に伝える早期通知（ｅａｒｌｙ ｎｏｔｉｆｉｃａｔｉｏｎｓ）であると理解する。ＸＬｉｎｋは置換すべき期間に付随しているので、ＸＬｉｎｋが置換すべきコンテンツのＲＣ開始時刻及び／又は継続時間を平文で（ｉｎ ｔｈｅ ｃｌｅａｒ）含んでいた場合、ＸＬｉｎｋの高度な知識によってスキップが可能になることがある。

【0050】

これを解決するために、以下でさらに説明するように開始時刻を有していない早期期間内にＸＬｉｎｋを送信することができる。ＤＡＳＨでは、この期間が早期利用可能期間（ＥＡＰ）として知られており、ＩＳＯ／ＩＥＣ ２３００９－１を参照されたい。ＥＡＰは、期間（Ｐｅｒｉｏｄ）タグ内にメタデータを有することができるが、置換すべきコンテンツの開始時刻又は継続時間を有しておらず、或いは少なくとも開始時刻又は継続時間を平文で、すなわち非暗号化又は非難読化形態で有していない。従って、セグメントタイムラインを使用すると、ＥＡＰの開始時刻を（最近のＭＰＤ更新を含む）ＪＩＴで明らかにするだけでよいので、ＲＣをスキップする戦略を実行する時間が不十分になる。ＸＬｉｎｋ自体は、コンテンツ置換の準備時間を可能にするためにいつでもＥＡＰを使用して明らかにすることができる。

【0051】

次に図３を参照する。ブロック３００から開始して、特定の受信機の特定のユーザに合わせた置換用ａｄなどの置換用コンテンツ（ＲＣ）に関する情報を、受信機が記憶する時刻よりもかなり前に放送局から送信する。この置換用コンテンツは、受信機がフェッチする時刻よりもかなり前に（キャッシュされたａｄ置換システム内で）利用可能にすることもできる。実施形態例では、この情報がＸＬｉｎｋを含むことができる。ただし、この情報は、置換すべきコンテンツのＲＣの開始時刻及び継続時間を含んでおらず、少なくとも開始時刻の非暗号化又は非難読化バージョンを含んでいない。

【0052】

ブロック３０２に進み、ブロック３０４において放送局アプリ以外の受信機のコンポーネントに対してＲＣの開始時刻の直前に開始時刻が明らかになるように待機期間（又は番組ガイド又は放送スタジオ設備からのトリガー）を入力する。一般に、開始時刻は、ＲＣに関する情報が明らかになったしばらく後に明らかにされ、不正を受けた受信機がスキップ戦略を実行する時間が不十分であるように、開始時刻のわずか数ミリ秒前又は数秒前に明らかにすることができる。置換すべきコンテンツの開始時刻及び／又は継続時間は、開始時刻／継続時間を帯域外で受信機に送信すること、又は本明細書で説明する他の技術によって明らかにすることができ、或いは開始時刻／継続時間は、暗号化された又は別様に難読化された形態の開始時刻／継続時間を放送局アプリがＸＬｉｎｋと共に受信し、受信機の残りのコンポーネントに開始時刻の直前まで開始時刻／継続時間の平文指示を単純に提供しないことによって明らかにすることもできる。

【0053】

図４に具体的方法を示す。ブロック４００から開始して、置換すべきコンテンツの暗号化された開始時刻と、必要な場合には暗号化された継続時間とを含むそれぞれのＸＬｉｎｋと共に１又は２以上のＥＡＰを送信する。ブロック４０２において、受信機がＸＬｉｎｋを解決するのに必要なコンポーネントにＸＬｉｎｋを提供し、ただし開始時刻／継続時間は提供せずにＲＣ挿入に備える。ブロック４０４において、放送局アプリが開始時刻を復号することができるが、これを受信機の他のコンポーネントと共有することはしない。ブロック４０５において、放送局アプリが、受信機にＯＴＡでコンテンツをキャッシュするように、或いはＯＴＴからフェッチしてキャッシュし、キャッシングを伴わずにＯＴＴサーバから別様にコンテンツを利用できるように命令し、その後に適切な時点でこのＸＬｉｎｋを含む期間を置換する命令を受け渡すことによってコンテンツ置換を準備することができる。ブロック４０６において、放送局が、その後に新たな再生期間になるＥＡＰ内でＲＣの開始時刻を受信機に明らかにする。ブロック４０７において、受信機が、予め命令を受けていればこの期間をＲＣ期間に置き換える。

【0054】

ブロック４０８は、複数のＥＡＰを使用できることを示しており、各ＥＡＰは、ＸＬｉｎｋｓを復号することによって放送局アプリのみが把握する独自の継続時間を有する。換言すれば、それぞれが独自のＸＬｉｎｋを有し、それぞれが異なるタイプ又は継続時間のＲＣのキャッシュを可能にする複数のＥＡＰをＤＡＳＨマニフェストファイルでシグナリングすることで、最終的に置換する必要があるコンテンツに応じて放送局がどのＥＡＰに後続のオーバージエアＡＶセグメントを追加するかをＪＩＴで選択できるようにすることができる。この選択がｘｌｉｎｋ通知されたキャッシュ済みの置換用コンテンツに一致する場合、受信機はこの時点でこれを置き換える。

【0055】

ブロック４１０は、ＲＣ期間が当初のものであるかそれとも置換されたものであるかにかかわらず開始時刻に受信機によって再生されることを示す。

【0056】

図５に別の方法を示す。タイプ継続時間（ｔｙｐｅ ｄｕｒａｔｉｏｎ）及び開始時刻の指示を含むＲＣ情報の一部又は全部をイベントストリーム通知で搬送して受信機に送信する。ＤＡＳＨイベントストリーム通知の詳細は、ＡＴＳＣ Ａ／３４４において見出すことができる。イベントストリーム通知は、直ぐに出現する予定の置換可能コンテンツのタイプ及び継続時間を（ＡＴＳＣ３．０シグナリング法を使用して）放送局アプリにシグナリングするために、現在の再生期間に追加される。放送局アプリは、この情報を通知された後に、ブロック５０２においてＲＣをキャッシュすることができる。クライアント受信機は、置換開始時刻がいつ発生するかをブロック５０４におけるＪＩＴまで知らずに、ブロック５０６において開始時刻にＲＣを再生することを許可する。

【0057】

図６に、データを有していない開始時刻６０２を含むセグメントタイムライン期間６００を示す。期間６００は、ＸＬｉｎｋなどのメタデータのみを含んでおり、コンテンツを含んでいない。期間６００は、置換すべきコンテンツの継続時間を省略することもできる。

【0058】

一方で、図７には、暗号化された開始時刻７０２を含むセグメントタイムライン期間７００を示す。期間７００は、ＸＬｉｎｋなどのメタデータのみを含んでおり、コンテンツを含んでいない。期間７００は、置換すべきコンテンツの継続時間を暗号化形態で含むこともできる。

【0059】

ＤＡＳＨマニフェストは継続的にかつ適切な時点でリフレッシュする必要があるため、セグメントタイムラインはコンテンツを隠蔽するのに理想的である。セグメントタイムラインは、ライブＴＶの一時停止も可能にする技術であるクライアント受信機の録画及び再生に重い負担をかける。一時停止及び録画は、クライアントがより高度なコンテンツの知識を可能にできる方法であるが、セグメントタイムラインはこれを重荷にする。

【0060】

本明細書の技術は、ＡＴＳＣ３．０、及び場合によってはＤＡＳＨ ＩＯＰを通じて実装することができる。クライアント実装は、クライアント受信機がＭＰＥＧ ＤＡＳＨメインスタンダードからのＥＡＰをセグメントタイムラインモードでサポートすることを必要とすることができる。

【0061】

以下では、さらに詳細な多期間セグメントタイムラインＤＡＳＨマニフェストファイルについて説明し、放送局アプリのみが解釈できるように意図されたｘｌｉｎｋメタデータを含むＥＡＰを示す。受信機は、ｘｌｉｎｋの最初の時点でこのｘｌｉｎｋを放送局アプリに通知すると予想され、この結果、放送局アプリは、何をするか、ＯＴＴをキャッシュするか、ＯＴＡをキャッシュするか、ライブＯＴＴ置換に備えるか、又は何も置換しないかを決定する。その後、放送局アプリは、必要に応じてキャッシュ動作を実行して期間置換に備えるように受信機に命令する。

【0062】

次に、ＥＡＰがこの期間の開始時刻に沿ってＯＴＡで配信される最新のセグメントを含む空でない期間に取って代わられる多期間動的ＭＰＤ（ｍｕｌｔｉ－ｐｅｒｉｏｄ ｄｙｎａｍｉｃ ＭＰＤ）について説明する。放送局アプリは、この期間を置換用コンテンツのための代替期間に置き換えるように受信機に命令しておくことができる。期間を置き換えるように命令されていない受信機は、通常通りにこの期間内への再生を継続する。第２の期間に最新の「ライブ」セグメントが追加されている間、第１の期間からは古いセグメントが消える。受信機は、過去にＲＣのためのｘＬｉｎｋについて伝えられ、この期間を置き換えるように予め命令され、今や置換可能コンテンツの再生に使用されている期間内の開始時刻が分かっているので、受信機上では、ＯＴＡで配信されているセグメントの代わりに置換済みのコンテンツが確実に再生されるようにＭＰＤが編集される。この中の第３のＭＰＤでは、期間ｉｄ ｐ１４を有する別の多期間が、放送局が追加を開始する新たな期間になる。期間ｉｄ ｐ１３及びｐ１４は開始時刻を有しており、これらの間の差分は、シームレスな再生のために置換されたコンテンツと正確に一致すべきｐ１３の継続時間を定める。この一致を保証するために、放送局アプリが解釈できるようにｘＬｉｎｋ内で継続時間を符号化しておくか、或いは放送局アプリがＯＴＴサーバに接触して継続時間を取得することができる。

【0063】

置換可能コンテンツを含む期間が経過し、この時点でライブポイント（ｌｉｖｅ ｐｏｉｎｔ）に新たな交換不能期間（ｎｏｎ ｒｅｐｌａｃｅａｂｌｅ Ｐｅｒｉｏｄ）が出現する。

【0064】

いくつかの実施形態例を参照しながら本原理について説明したが、これらの実施形態は限定的であるように意図するものではなく、本明細書において特許請求する主題は様々な別の構成を用いて実装することもできると理解されるであろう。

【符号の説明】

【0065】

３００ 置換コンテンツ情報を送信
３０２ 開始直前まで待機
３０４ 開始時刻を明示
３０６ 再生

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【国際調査報告】