発明のより容易な理解を助け、発明の実施例を示す添付の図面が、下記の記載と共に本発明の原理を説明するために提供される。
本明細書で使われる用語としては、本発明においての機能を考慮したうえ、できるだけ現在広く使われている一般的な用語を選択したが、これは、当該分野に従事する技術者の意図、慣例又は新しい技術の出現などによって変更されてもよい。また、特定の場合、出願人が任意に選定した用語もあり、その場合には、該当する発明の説明の部分においてその意味を記載するものとする。したがって、本明細書で使われる用語は、単純な用語の名称ではなく、その用語が持つ実質的な意味と本明細書の全般にわたる内容に基づいて解釈されなければならいということは明らかである。
本明細書において、メディア時間は、オーディオ/ビデオ又はオーディオコンテンツアイテムの再生(playout)においていずれかの地点を参照するパラメータを表す。ACRは、自動コンテンツ認識(Automatic Content Recognition)を表す。AMTは、活性化メッセージテーブル(Activation Messages Table)を表す。APIは、アプリケーションプログラミングインターフェース(Application Programming Interface)を表す。DAEは、宣言的応用環境(Declarative Application Environment)を表す。DOは、宣言的客体(Declarative Object)を表す。FLUTEは、単方向送信を通したファイル伝達(File Delivery over Unidirectional Transport)を表す。GPSは、位置確認システム(Global Positioning System)を表す。HTTPは、ハイパーテキスト送信プロトコル(Hypertext Transfer Protocol)を表す。IPは、インターネットプロトコル(Internet Protocol)を表す。IPTVは、インターネットプロトコルテレビ(Internet Protocol Television)を表す。iTVは、双方向テレビ(Interactive Television)を表す。MIMEは、インターネットメディアタイプ(Internet Media Type)を表す。NDOは、NRT宣言的客体(NRT Declarative Object)を表す。NRTは、非実時間(Non−Real Time)を表す。SMTは、サービスマップテーブル(Service Map Table)を表す。SSCは、サービスシグナリングチャネル(Service Signaling Channel)を表す。TDOは、トリガーされた宣言的客体(Triggered Declarative Object)を表す。TPTは、TDOパラメータテーブル(TDO Parameters Table)を表す。UDOは、非結合宣言的客体(Unbound Declarative Object)を表す。UPnPは、ユーザープラグアンドプレイ(User Plugand Play)を表す。URIは、統合リソース識別子(Uniform Resource Identifier)を表す。URLは、リソース位置表示子(Uniform Resource Locator)を表す。XMLは、拡張性生成言語(eXtensible Markup Language)を表す。TFTは、テキストフラグメントテーブル(Text Fragment Table)を表す。詳細な内容は後述する。
この明細書で、DO、TDO、NDO、UDOは次のような意味を有することができる。
DO(Declarative Object)は、双方向アプリケーション(例えば、HTML、JavaScript、CSS、XML及びマルチメディアファイル)を構成するコレクション(collection)であってもよい。
トリガーされた双方向付加データサービスによって開始された宣言的客体又はトリガーによって開始されたDOによって実行されたDOなどを指定するために“トリガーされた宣言的客体(TDO)”を使用する。
トリガーされた双方向データサービスではなくNRTサービスの一部として実行された宣言的客体を表すために、“NRT宣言的客体”(NDO)という用語を使用する。
パッケージ型アップ(Packaged App)のようにサービスに結合されない宣言的客体、リンクによって実行されたDO、又はそのようなDOによって実行されたDOなどを表すために“非結合宣言的客体(UDO)”という用語を使用する。
“リンク”は、現在のTVプログラム又はNRTサービスに関連するオンライン情報又は機能を提供するウェブサイトを示す放送局提供URLである。
“パッケージ型アップ”は、放送局が視聴者に提供しようとする情報又は機能を提供し、視聴者がダウンロードして設置できる一つのファイルとしてまとめられた放送局提供宣言的客体(DO)である。
その詳細は後述する。
この明細書で、時間ベースメッセージ(time base message)は、時間ベーストリガー及びその等価物を含む。したがって、“時間ベースメッセージ”と“時間ベーストリガー”と同じ意味で使われてもよい。
この明細書で、活性化メッセージは、活性化トリガー及び/又はAMT内の活性化エレメントのような、活性化を引き起こす全ての情報伝達を含む。
図1は、一般的な放送ストリームの一実施例を示す図である。
一般的な放送ストリームはTVプログラムのシーケンスで構成されている。各TVプログラムは、基本となるショー(show)で構成され、ショーは一般的に広告及び/又は他の介在物(interstitial material)によって分離されたブロックに分けられる。
同図では、放送ストリームに、ショーA(Show A)セグメント、広告1(Ad1)、広告2(Ad2)、ショーB(Show B)セグメントなどが順次に含まれている。各ショーをなすセグメントをショー材料、広告を介在物と呼ぶことができる。
各ショー又は介在物は、それと関連している双方向付加データサービスを有しても有さなくてもよい。
本明細書では、統合ユニットとして放送局によって扱われる双方向付加サービスの一部を表すために“双方向サービスセグメント”、又は単純に“セグメント”という用語を使用する。双方向サービスセグメントは一般的に単一ショー又は1個の介在物と関連するが、必ずしもそうでない。
このような双方向付加データサービスを実行するための2つのモデルがあり得る。直接実行モデルとトリガーされた宣言的客体(Triggered Declarative Object、TDO)モデルがそれである。
直接実行モデルでは、仮想チャネルが選択されると直ちに宣言的客体(Declarative Object、DO)は自動で開始され得る。宣言的客体は、スクリーン上の特定位置での画面の生成、世論調査の実行、他の特殊DOの開始などのように、オーディオ−ビデオプログラムと同期化される双方向特徴の提供のための具体的な指示事項を得るために、インターネットを介してバックエンド(backend)サーバーと通信することができる。
TDOモデルでは、TDOの開始、TODの終了、又はTDOによる一部作業の誘発のようにTDOイベントを開始するために信号を放送ストリームで伝達したり又はインターネットを介して伝達することができる。これらのイベントは、特定時間に開始され、一般的にオーディオ−ビデオプログラムと同期化される。TDOが開始されると、プログラムされた双方向特徴を提供することができる。
TDOモデルの基本概念は、TDOを構成するファイル及びある動作を取るためにTDOによって用いられるデータファイルはいずれも、その大きさによって受信機に伝達されるには一定量の時間がかかるということである。双方向エレメントに対するユーザ経験は、コンテンツの放送前に作成(author)されてもよいが、ある振舞いは、プログラム内のイベント、例えば、商業広告セグメントの発生と同時に起きるように注意して時間を決めなければならない。
TDOモデルでは、宣言的客体、関連しているデータ、スクリプト、テキスト及びグラフィックの伝達を、双方向イベントの再生に対する特定タイミングのシグナリングと区別する。
双方向イベントのタイミングを設定するエレメントはトリガー(Trigger)である。
一つのセグメント内で用いられるTDOとトリガーによって開始される関連TDOイベントに関する情報は、“TDOパラメータテーブル”(TPT)と呼ばれるデータ構造によって提供される。
図2は、既に生成されたコンテンツの場合に、トリガータイミングの一実施例を示す図である。
トリガーは、シグナリングを識別し、双方向イベントの再生タイミングを設定する機能を担うシグナリングエレメントである。
トリガーには、双方向サービスに関連するセグメントに対するメディア時間を示す役割を担う時間ベーストリガーと、双方向サービスに関連するアプリケーションのイベント発生時間を示す役割を担う活性化トリガーの2種類があり得る。
トリガーは、双方向サービスの支援のために、タイミングに関連する様々な機能を果たすことができる。トリガーはその機能によって多機能的であってもよく、特定トリガーインスタンス(instance)は、次の機能のうち一つ以上を行うことができる。
1.TPT(放出ストリーム内のFLUTEセッション、インターネットサーバー、又はこれら両者を介して接近可能なTPT)の位置をシグナリングする。
2.次のプログラムセグメントに対する双方向コンテンツがプリロード(pre−load)されることを示す。
3.関連しているオーディオ/ビデオコンテンツ又はオーディオコンテンツの現在メディア時間を示す。
4.TPT内特定双方向イベントを参照し、当該イベントが現在又は特定の未来のメディア時間に実行されなければならないということを知らせる。
5.需要が最大となることを避けるために、インターネットサーバーに対する接続が特定の時間区間上でランダムに分散されることを示す。
図2は、2つのプログラミングセグメントと関連して伝達されるトリガーを示す。この例では、2つのセグメントとも“予め生成”されるが、これは、コンテンツがライブコンテンツではなく、双方向エレメントはポストプロダクション(post−production)で追加されたことを意味する。
図示のように、プログラミングセグメント1の発生前の短い時間に“プリロード(pre−load)”トリガーが伝達されて、受信機と関連しているTPT及びー方向コンテンツを取得できる機会を受信機に許容することができる。万一、プリロードトリガーが送信されないと、受信機は、コンテンツを取得するために該当のセグメント内で会う最初のトリガーを用いると考えることができる。
図示のように、トリガーはSegment1を通して送信されて、当該セグメントに関する現在メディア時間(図では“m”と表記)を示すことができる。当該チャネルに会うトリガーが双方向コンテンツを同期化して取得できるようにするためにメディア時間トリガーの周期的な伝達が必要なことがある。
Segment2の開始直前に当該セグメントに対するプリロードトリガーが送信される。
予め生成されたコンテンツ(非ライブ(non−live)コンテンツ)の場合、受信機が最初のトリガーを処理した後に取得できるTPTは、当該セグメントに対する双方向経験の全てのエレメントのタイミングを定義することができる。当該受信機とTDOが双方向エレメントを再生するようにするために必要なものは、メディアタイミングの知識であってもよい。このTPTはメディア時間に関して双方向イベントを記述することができる。
図3は、ライブコンテンツの場合に、トリガータイミングの一実施例を示す図である。
ライブコンテンツの場合にも、TPTは、互いに異なる双方向イベントに関連するデータ及び情報を含むが、放送中にプログラム内の動作が展開するまでは、そのようなイベントの再生タイミングは知られないことがある。このようなライブの場合、トリガーの“イベント−タイミング(event−timing)”機能が活用される。このモードでトリガーは、特定の双方向イベントが新しい特定メディア時間値に再設定(re−timed)されることを知らせることができる。又は、トリガーは、あるイベントが直ちに実行されることを示すこともできる。
図3で、Segment 3に対する各トリガーの機能は次の通りである。
1番トリガーは、プリロードトリガーであって、セグメント3に関するファイルを得ることができるディレクトリを参照する。
2番トリガーは、メディア時間トリガーであって、Segment 3に対する再生タイミングを示すために用いられる。
3番トリガーは、イベントリタイミング(re−timing)トリガーであって、TPTでeventID=2のイベントがメディア時間240に発生するように時間が再設定されることを示す。ハッチングされた領域は、3番トリガーが受信機に伝達され得る240以前の時間区間を示す。
4番トリガーは、メディア時間トリガーである。
5番トリガーは、イベントリタイミングトリガーであって、TPTでeventID=5のイベントがメディア時間444に発生するように時間が再設定されることを示す。
6番、7番トリガーは、メディア時間トリガーである。
8番トリガーは、イベントトリガーであって、TPTでeventID=12のイベントが直ちに実行されることを示す。
9番トリガーは、イベントリタイミングトリガーであって、TPTでeventID=89のイベントがメディア時間900に発生するように時間が再設定されることを示す。
以下、TDOのライフサイクル(life cycle)と状態、及び状態変化イベントについて説明する。
TDOは、解除(Released)、準備(Ready)、活動(Active)、及び中止(Suspended)の異なった4つの状態で存在することができる。多数の異なる要素(トリガー、ユーザ動作、変更されるチャネルなど)が一つの状態から他の状態への変動を引き起こしうる。
TDOは、次の4つの状態を有することができる。4つの状態は、準備(Ready)、活動(Active)、中止(Suspended)及び解除(Released)である。準備状態は、TDOがダウンロードされて実行準備となっているが、まだ実行されてはいないことを意味する。活動状態は、TDOが実行中であることを意味する。中止状態は、その状態の保存と併せて、TDOの実行が一時的に中止することを意味する。解除状態は、TDOが準備、活動又は中止状態でないことを意味する。
TDOの状態変化を起こし得るイベントの例には次のものがある。
1.“prepare”をトリガーする − 装置は、TDOが実行(リソース割当、主メモリへのローディングなど)をするように準備されることを要求するトリガーを(現在選択された1次仮想チャネルで)受信する。
2.“execute”をトリガーする − 装置は、TDOが活性化されることを要求するトリガーを(現在選択された1次仮想チャネルで)受信する。
3.“suspend”をトリガーする − 装置は、TDOの中止を示すトリガーを(現在選択された1次仮想チャネルで)受信する。
4.“kill”をトリガーする − 装置は、TDOの終了を示すトリガーを(現在選択された1次仮想チャネルで)受信する。
図4は、トリガーシンタックスの一実施例を示す図である。
活性化メッセージと時間ベースメッセージは両方とも、ある送信環境で次のような一般的な“トリガー”フォーマットを有することができる。
ここで、シンタックス上の定義は、アルタネイティブ(alternative)を指定するために垂直バーシンボル”|”が使われる場合以外は、ABNF(Augmented Backus−Naur Form)文法を用いて記述する。ルール(rule)は等号”=”によって定義と分離され、1行を超えてルール定義を続けるときは字下げ(indentation)を用い、リテラル(literal)は””で引用し、エレメントのグループ化には括弧”(”と”)”を用い、選択的なエレメントは”[”と”]”との間に入れる。そして、エレメントの前に<n>*がつくと、その次のエレメントのn回以上の反復を指定でき、nは基本値として0に設定される。そして、エレメントの前に<n>*<m>がつくと、その次にくるエレメントのn回以上m回以下の反復を指定することができる。
このようなトリガーシンタックスは、<scheme>と“://”部分を除いて、付加的な制限事項と共にURI(Uniform Resource Identifier):ジェネリックシンタックス(Generic Syntax)に基づく。
トリガーは、locator_partとtermsで構成することができる。termsは、省略可能な構成である。termsが存在するとlocator_partとtermsとを‘?’で連結することができる。
locator_partは、hostname部分とpath_segments部分とで構成することができ、その間は‘/’で連結することができる。
hostnameは、domainlabelとtoplabelとで構成することができ、domainlabelはその次に‘.’と共に0回以上反復され得る。すなわち、hostnameは、反復されたdomainlabelがtoplabelと連結した形態であってもよく、又は、toplabelのみで構成された形態であってもよい。
domainlabelは、一つのalphanumからなる形態であってもよい。又は、2つのalphanumの間にalphanum又は‘−’が0回以上反復されたものが挿入された形態であってもよい。
ここで、alphanumは、alpha又はdigitを意味することができる。
ここで、alphaは、lowalpha又はupalphaのいずれかであってもよい。
ここで、lowalphaは、a、b、c、d、e、f、g、h、i、j、k、l、m、n、o、p、q、r、s、t、u、v、w、x、y、zのいずれか一つであってもよい。
ここで、upalphaは、A、B、C、D、E、F、G、H、I、J、K、L、M、N、O、P、Q、R、S、T、U、V、W、X、Y、Zのいずれか一つであってもよい。
ここで、digitは、0、1、2、3、4、5、6、7、8、9のいずれか一つであってもよい。
toplabelは、一つのalphaからなる形態であってもよい。又は、alphaとalkphanumとの間にalphanum又は‘−’が0回以上反復されたものが挿入された形態であってもよい。
path_segmentsは、セグメントが一つがあり、その次にセグメントが0回以上反復されたものが続く形態であってもよい。このとき、セグメントの間は‘/’で連結することができる。
ここで、セグメントは、alphanumが1回以上反復された形態であってもよい。
termsは、event_time又はmedia_timeのいずれかからなる形態であってもよい。続いてspread又はothersが来てもよい。spreadとothersは省略可能な構成であってもよい。spreadとothersが存在すると、これは‘&’を前に置いている形態であって、event_time又はmedia_timeの次に位置することができる。
ここで、spreadは、‘s=’の次にdigitが1回以上反復されたものが続く形態であってもよい。
event_timeは、‘e=’の次にdigitが1回以上反復されたものが続く形態であってもよい。又は、その後、‘&t=’の次にhexdigitが1回以上7回以下反復されたものが続く形態であってもよい。‘&t=’とその次の部分は省略可能な構成であってもよい。
ここで、hexdigitは、0、1、2、3、4、5、6、7、8、9、a、b、c、d、e、fのいずれか一つであってもよい。
media_timeは、‘m=’の次にhexdigitが1回以上7回未満反復されたものが続く形態であってもよい。
othersは、一つのotherからなる形態であってもよい。又は、その次に‘&’とotherが追加された形態であってもよい。
ここで、otherは、resv_cmdとalphanumが1回以上反復されたものとが‘=’によって連結された形態であってもよい。
ここで、resv_cmdは、‘c’、‘e’、‘E’、‘m’、‘M’、‘s’、‘S’、‘t’、‘T’を除くalphanumであってもよい。
トリガーの長さは52バイトを超えなくてもよい。そして、トリガーのhostname部分は、登録されたインターネットドメイン名であってもよい。
トリガーは、3つの部分からなることがわかる。
<domain name part>/<directory path>[?<parameters>]
<domain name part>は、登録されたドメイン名であり、<directory path>は、ドメイン名がURIにおいて登場するようになる経路であってもよい。
<domain name part>は、登録されたインターネットドメイン名を参照することができる。<directory path>は、識別されたドメイン名に対する権限を持つエンティティ(entity)の制御及び管理下でディレクトリ経路を識別する任意の文字列であってもよい。
TDOモデルで、<domain name part>と<directory path>の組合せは、関連しているコンテンツに双方向性を追加するために受信機によって処理され得るTPTを固有に識別することができる。
<domain name part>と<directory path>の組合せは、現在セグメントに対するTPTが得られるインターネット位置のURLであってもよい。
すなわち、トリガーは、<domain name part>と<directory path>を用いてTPTを識別することができ、これによってトリガーの適用されるTPTがわかる。当該triggerがTPTに適用されてどのような役割を果たすかは、<parameters>部分による。
以下、<parameters>部分について説明する。
<parameters>は、“event_time”、“media_time”、又は“spread”の一つ以上で構成することができる。
次は、図4に示したシンタックスにおいて“event_time”、“media_time”、“spread”に関する部分である。
event_time =”e=”1*digit[”&t=”1*7hexdigit]
media_time =”m=”1*7hexdigit
spread =”s=”1*digit
“event_time”項は、ターゲットとされたイベント(“e=”項)と当該イベントが活性化されるべき時間(“t=”項)を識別するために活性化トリガーにおいて用いることができる。“t=”項がないと、これは、トリガーが到達する時間にイベントが活性化されなければならないことを意味する。
すなわち、双方向イベントID項である“e=”は、当該イベントのターゲットであるTDOの関連しているTPT内のappID、当該特定イベントのeventide、及びこのイベント活性化のために用いられるデータエレメントのdataIDを参照することができる。
選択的なタイミング値項である“t=”は、指定されたイベントのための新しいメディアタイミングを示すことができる。“t=”部分が存在しないと、これは、指定されたイベントのためのタイミングがトリガーの到達時間であることを意味することができる。
“media_time”項(“m=”項)は、時間ベーストリガーによって示される時間ベースに対する現在時間を識別するために時間ベーストリガーにおいて用いることができる。そして、現在表れているコンテンツを識別できるコンテンツ識別子情報(“c=”項)がmedia_timeにさらに含まれてもよい。“c=”項については、直接実行モデルに関する説明で後述する。
すなわち、“m=”は、その次に16進数を表示する1乃至8文字長の文字列が続くメディアタイムスタンプ(timestamp)項であって、現在のメディア時間を示すことができる。
“spread”項は、サーバー上で作業負荷が分散するように、時間ベーストリガーに応答してなされる動作(サーバーからのTPTの検索のような動作)又は活性化トリガーに応答してなされる動作(TDOをサーバーに接続させるような動作)がランダムな時間の間に遅延されなければならないということを示すために用いることができる。
“s=”項は、全ての受信機がトリガーで識別されたインターネットサーバーに接続を試みるべき秒単位の時間数を示すことができる。それぞれの個別受信機が、指定された区間内でランダムな時間を導出して、該当する量だけ接続要求を遅延させることによって、受信機でトリガーが初めて現れる時に発生しう需要の最大値を時間上で分散させると考えることができる。
<media time>パラメータを含むトリガーは、イベント時間に対する時間ベースを設定するために用いられることから、時間ベーストリガーと呼ぶこともできる。
<event time>パラメータを含むトリガーは、イベントに対する活性化時間を設定することから、活性化トリガーと呼ぶこともできる。
図5及び図6は、TDOパラメータテーブルの一実施例を示す図である。
TDOパラメータテーブル(TPT)は、一つのセグメントのTDO及びこれらのターゲットであるイベントに関するメタデータを含む。
以下、テーブルに含まれる各フィールドについて説明する。各フィールドの大きさとテーブルに含み得るフィールドの種類は設計者の意図によって追加又は変更されてもよい。
TPT構造内のフィールドの具体的なセマンティックス(semantics)は次の通りである。
TDOパラメータテーブル(TPT)は、@majorProtocolVersion、@minorProtocolVersion、@id、@tptVersion、@expireDate、@updatingTime、@serviceID、@baseURL属性、Capabilities、ライブトリガー(LiveTrigger)、及び/又はTDOエレメントを含むことができる。
TPTは、当該TPTのルートエレメントである。一つのTPTエレメントは、一つのプログラミングセグメントの(時間上での)全体又は一部分を記述する。
4ビット属性であってもよい@MajorProtocolVersionは、テーブル定義の主バージョン番号を示すことができる。主バージョン番号は1に設定することができる。受信機はそれらが支援しない主バージョン値を示すTPTのインスタンスを捨てると考えることができる。
4ビット属性であってもよい@MinorProtocolVersionが存在する場合、テーブル定義の副バージョン番号を示すことができる。存在しない場合、その値は0にデフォルトすることができる。副バージョン番号は0に設定することができる。受信機は、それらが支援するように備えられていない副バージョン番号値を示すTPTのインスタンスを捨てないと予想される。この場合、受信機はそれらが支援しない個別エレメント又は属性を無視すると予想される。
URIである@idは、このTPTエレメントに関連している双方向プログラミングセグメントを固有に識別することができる。@idは、セグメントの識別子の役割を持つ。したがって、受信機がTPTをパーシングした後、@id情報を用いて、一つのセグメントに関連しているトリガー、AMTなどを該セグメントを識別するための@idを有するTPTとマッチングさせることができる。したがって、該トリガーとAMTが適用されるセグメントを探すことが可能になる。AMTに関する詳細な内容は後述する。
8ビット整数であってもよい@tptVersionは、id属性によって識別されるTPTエレメントのバージョン番号を示すことができる。tptVersionは、TPTが変更される度に増分(increment)されてもよい。
TPTエレメントの@expireDate属性は、存在する場合、当該TPTインスタンスに含まれた情報の満了日及び時間を示すことができる。万一、受信機がTPTをキャッシュに保存すると、満了日まで再使用することができる。
16ビットエレメントであってもよい@updatingTimeは、存在する場合、TPTが修正されることを示すことができ、TPTを再びダウンロードするための秒単位の推薦区間を提供する。
16ビットエレメントであってもよい@serviceIDは、存在する場合、このTPTインスタンスで記述された双方向サービスと関連しているNRTservice_idを示すことができる。これは、この双方向サービスのためのファイルが放送ストリームで伝達されるとき、受信機がサービスマップテーブルからFLUTEパラメータを得るために必要である。
@baseURL属性は、存在する場合、当該TPTで登場する任意の相対URLの前につくと、ベースURLを提供することができる。この属性は、ファイルの絶対URLを提供することができる。
Capabilitiesエレメントは、存在する場合、当該TPTと関連している双方向サービスの意味ある表出のために必須である能力を示すことができる。要求される能力のうち一つ以上を持たない受信機はサービスの表出を試みないと予想される。
LiveTriggerは、インターネットを介した活性化トリガーの伝達が利用可能な場合にのみ存在する。存在する場合、活性化トリガーを得るために受信機で必要とする情報を提供することができる。LiveTriggerのチャイルド(child)エレメントと属性については後述する。
TPTエレメントのチャイルドエレメントであるTDOは、当該TPTインスタンスによって記述されたセグメントの間に双方向サービスの一部を提供するアプリケーション(例えば、TDO)を示すことができる。TDOのチャイルドエレメントと属性については後述する。
LiveTriggerエレメントは、@URLと@pollPeriod属性を含むことができる。
上述した通り、LiveTriggerエレメントは、インターネットを介した活性化トリガーの伝達が利用可能な場合にのみ存在する。存在する場合、活性化トリガーを得るために受信機で必要とする情報を提供することができる。
LiveTriggerエレメントの属性である@URLは、インターネットを介して活性化トリガーを伝達し得るサーバーのURLを示すことができる。活性化トリガーは、双方向サービスプロバイダの選択によって、HTTPショートポーリング(short polling)、HTTPロングポーリング(long polling)、又はHTTPストリーミングを用いてインターネットを介して伝達することができる。
LiveTriggerエレメントの属性である@pollPeriodは、存在する場合、活性化トリガーの伝達のためにショートポーリングが使用中であることを示すことができ、pollPeriod属性値は、受信機がポーリング周期として用いる秒単位の推薦時間を示すことができる。
LiveTriggerエレメントが存在する場合、受信機は、当該TPTをパーシングして、活性化トリガーをインターネットを用いて伝達するための情報を得ることができる。@URL情報から、活性化トリガーを伝達してもらえるサーバーのURLを得ることができる。@pollPeriod情報から、或いは@pollPeriod属性が存在しないという情報から、活性化トリガーがインターネットを介して伝達される方式とポーリング周期に関する情報を得ることができる。@pollPeriodの詳細な説明は後述する。
TDOエレメントは、@appID、@appType、@appName、@globalID、@appVersion、@cookieSpace、@frequencyOfUse、@expireDate、@testTDO、@availInternet、@availBroadcast属性と、URL、Capabilities、Contentitem、及び/又はEventエレメントを含むことができる。
上述した通り、TPTエレメントのチャイルドエレメントであるTDOは、当該TPTインスタンスによって記述されたセグメントの間に双方向サービスの一部を提供するアプリケーション(例えば、TDO)を示すことができる。
16ビット整数であってもよい@appIDは、TPT範囲内でアプリケーションを固有に識別することができる。活性化トリガーはappIDを参照してトリガーに対するターゲットアプリケーションを識別することができる。@appIDの場合、アプリケーションの識別子である。一つのTPTには複数のアプリケーション(TDOのようなアプリケーション)があってもよい。したがって、TPTをパーシングした後に@appID情報を用いてアプリケーションを識別することができる。あるアプリケーションに適用されるトリガー又はAMTなどを、そのアプリケーションを識別する@appIDを有するアプリケーションとマッチングさせることができる。したがって、トリガーとAMTの適用されるアプリケーションを探すことが可能になる。AMTに関する詳細な内容は後述する。
8ビット整数であってもよい@appTypeは、アプリケーションフォーマット類型を示すことができる。基本値は1に設定することができ、この値はTDOを示すことができる。他の値は他のフォーマットを示すことができる。
TDOエレメントの属性である@appNameは、アプリケーションを開始するために視聴者の許可を求めるとき、視聴者に表示し得る人間にとって読み取り可能な名前であってもよい。
TDOエレメントの属性である@globalIDは、アプリケーションの全域的に固有な識別子であってもよい。多くの場合に、受信機は近いうちに再び用いるアップをキャッシュに保存する。このことが有用となるには、受信機は当該アップが将来に登場するとそれを認識できなければならない。当該アップが新しいセグメントで再び登場すると、受信機がそれを認識できるようにするためにglobalIDが必要である。
TDOエレメントの属性である@appVersionは、アプリケーションのバージョン番号であってもよい。appVersion値は、当該アプリケーション(globalIDによって識別されたアプリケーション)が変更される度に増分されてもよい。appVersion属性は、globalID属性が存在しない限り存在することができない。
8ビット整数であってもよい@cookieSpaceは、各呼出し(invocation)間に持続性データ(persistent data)を保存するためにアプリケーションがどれくらい多くの空間を必要とするかを示すことができる。
4ビット整数であってもよい@frequencyOfUseは、受信機にそのアプリケーションコードキャッシュ空間の管理に関する案内を提供するために概略的にどれくらい頻繁に当該アプリケーションが放送で使われるかを示すことができる。‘@frequencyOfUse’の詳細な説明は後述する。
TDOエレメントの属性である@expireDateは、受信機が当該アプリケーション及び関連するリソースを安全に削除できる日付及び時間を示すことができる。
ブールの(Boolean)属性である@testTDOは、その値が“true”として存在する場合、当該アプリケーションがテスト用であり、一般受信機では無視されてもよいことを示すことができる。
@availInternet属性に対する“true”値は、当該アプリケーションがインターネットを介したダウンロード用に利用可能であることを示すことができる。その値が“false”であれば、当該アプリケーションがインターネットを介したダウンロード用に利用可能でないことを示すことができる。属性が存在しない場合、基本値は“true”であってもよい。
@availBroadcast属性に対する“true”値は、当該アプリケーションが放送からの抽出に利用可能であることを示すことができる。“false”値は、当該アプリケーションが放送からの抽出に利用可能でないことを示すことができる。属性が存在しない場合、基本値は“true”であってもよい。
TDOエレメントのチャイルドエレメントであるURLの各インスタンスは、当該アプリケーションの一部であるファイルを識別することができる。インスタンスURLエレメントは@entry属性を含むことができる。URLエレメントの属性である@entryは“true”値を有すると、当該URLが当該アプリケーションのエントリポイント(entry point)、すなわち、当該アプリケーションを開始するために開始され得るファイルであることを示すことができる。“false”値を有すると、当該URLが当該アプリケーションのエントリポイントでないことを示すことができる。当該属性が登場しないとき、基本値は“false”であってもよい。TDOエレメントのチャイルドエレメントであるURLエレメントは、上述した通り、当該アプリケーションをなすファイルを識別する。受信端ではTPTをパーシングして当該URL情報を得た後、それを用いてサーバーに接続して、当該URL情報が示すアプリケーションをダウンロードすることとなる。
TDOエレメントのチャイルドエレメントであるCapabilitiesは、存在する場合、当該アプリケーションの意味ある表出のために必須である能力を示すことができる。要求される能力のうち一つ以上を持たない受信機は当該アプリケーションの開始を試みないと予想される。
TDOエレメントのチャイルドエレメントであるContentItemは、当該アプリケーションで必要とする一つ以上のデータファイルで構成されたコンテンツコンテンツアイテムを示すことができる。ContentItemエレメントは、このエレメントの属しているTDOエレメントが示すアプリケーションが必要とするデータファイルに関する情報を有する。受信端ではパーシングを行った後、ContentItemエレメントが存在する場合、ContentItem内のURL情報などを用いて、当該アプリケーションが必要とするデータファイルをダウンロードしたりできる。ContentItemのチャイルドエレメントと属性については後述する。
TDOエレメントのチャイルドエレメントであるEventは、当該アプリケーションのためのイベントを示すことができる。Eventエレメントは、このエレメントの属しているアプリケーションのイベントを示す。いかなるイベントを有しているか、該当データにはどのようなものがあるか、該当動作にはどのようなものがあるか等に関する情報を含んでいる。これをパーシングして受信端ではアプリケーションのイベントに関する情報を得ることができる。Eventのチャイルドエレメントと属性については後述する。
受信端でTPTを受けてパーシングすると、TDO及び上述したTDOのチャイルドエレメントと属性の情報を得ることができる。
TDOエレメントのチャイルドエレメントの一つである、contentItemエレメントは、@updateAvail、@pollPeriod、@size、@availInternet、@availBroadcastattribute及び/又はURLエレメントを含むことができる。
ここで、URLエレメントは、@entry属性を含むことができる。ContentItemエレメントのチャイルドエレメントであるURLの各インスタンスは、コンテンツアイテムの一部であるファイルを識別することができる。URLエレメントは、@entry属性を含むことができる。URLエレメントの属性である@entryは、“true”値を有すると、当該URLが当該コンテンツアイテムのエントリポイント、すなわち、当該コンテンツアイテムを開始するために開始されうるファイルであることを示すことができる。この属性が“false”値を有すると、当該URLが当該コンテンツアイテムのエントリポイントでないことを示すことができる。この属性が登場しないとき、基本値は“false”であってもよい。受信機は、パーシング後にContentItemのURL情報を用いて当該アプリケーションの要求されるデータファイルをダウンロードすることができる。この過程で、上述した他の属性のような情報を用いることができる。
ContentItemエレメントのブールの属性である@updatesAvailは、当該コンテンツアイテムがたまにアップデートされるか否か、すなわち、コンテンツアイテムが固定ファイル(static file)で構成されるか、それとも、当該アイテムが実時間データフィード(feed)であるかを示すことができる。その値が“true”であれば、当該コンテンツアイテムはたまにアップデートされ、その値が“false”であれば、当該コンテンツアイテムはアップデートされない。この属性が登場しないと、基本値は“false”であってもよい。
ContentItemエレメントの属性である@pollPeriodは、updatesAvail属性の値が“true”の場合にのみ存在することができる。@pollPeriodが存在する場合、活性化トリガーを伝達するためにショートポーリングが用いられていることを示すことができ、@pollPeriod属性の値は、受信機がポーリング周期として使用するための秒単位の推薦時間を示すことができる。
ContentItemエレメントの属性である@Sizeは、当該コンテンツアイテムの大きさを示すことができる。
@availInternet属性は、その値が“true”であれば、当該コンテンツアイテムがインターネットを介したダウンロードに利用可能であることを示すことができる。その値が“false”であれば、当該コンテンツアイテムがインターネットを介したダウンロードに利用可能でないことを示すことができる。この属性が存在しない場合、基本値は“true”であってもよい。”
@availBroadcast属性は、その値が“true”であれば、当該コンテンツアイテムが放送からの抽出に利用可能であることを示すことができる。“false”値は、当該コンテンツアイテムが放送からの抽出に利用可能でないことを示すことができる。属性が存在しない場合、基本値は“true”であってもよい。
Eventエレメントは、このEventエレメントの属するTDOエレメントによって示されたアプリケーションのイベントに関する情報を含む。受信機は、当該イベントに関する情報を得るためにこのEventエレメントをパーシングすることができる。
TDOエレメントのチャイルドエレメントであるEventエレメントは、@eventID、@action、@destination、@diffusion属性及び/又はDataエレメントを含むことができる。ここで、Dataエレメントは、@dataID属性を含むことができる。
上記Eventエレメントの16ビット整数属性であってもよい@eventIDは、これを含むTDOエレメントの範囲内で当該イベントを固有に識別することができる。活性化トリガー(又は、AMT内の活性化エレメント)は、appIDとeventIDの組合せによって当該トリガーに対するターゲットアプリケーション及びイベントを識別することができる。イベントが活性化されると、受信機は、このイベントを当該アプリケーションに渡す。@eventIDは、イベントの識別子の役割を持つ。@eventID情報を用いて、当該イベントを活性化させるためのトリガー、AMTなどを、このイベントを識別するための@eventIDを有するアプリケーションとマッチングさせることができる。すなわち、活性化トリガー(又は、AMT内の活性化エレメント)は、appIDとeventIDの組合せによって当該トリガーに対するターゲットアプリケーション及びイベントを識別することができる。イベントが活性化されると、受信機は、このイベントを当該アプリケーションに渡す。AMTの詳細は後述する。
Eventエレメントの属性である@actionは、当該イベントが活性化されるときに適用される動作の類型を示すことができる。許容される値は、“prep”、“exec”、“susp”及び“kill”であってもよい。
“prep”は、“Trig prep”動作に対応できる。ターゲットとなったアプリケーションの状態が“Released”であれば、この動作は“Ready”への状態変更を起こすことができる。
“exec”は、“Trig exec”動作に対応できる。このトリガーを受信すると、ターゲットとなったアプリケーションの状態は“Active”になり得る。
“susp”は、“Trig susp”動作に対応できる。このトリガーを受信すると、ターゲットとなったアプリケーションの状態が“Active”である場合、“Suspended”に変更可能であり、そうでない場合は変更されない。
“kill”は、“Trig kill”動作に対応できる。このトリガーを受信すると、ターゲットとなったアプリケーションの状態は“Released”になり得る。
@actionは、当該イベントが活性化される時に適用される動作の類型を示すことができる。
Eventエレメントの属性である@destinationは、当該イベントのためのターゲット装置を示すことができる。@destinationに関する詳細な内容は後述する。
Eventエレメントの8ビット整数属性であってもよい@diffusionは、存在する場合、秒単位の時間周期Tを示すことができる。この拡散パラメータの目的は、サーバーローディングの最大値を均一にすることである。受信機は0〜Tの範囲で10ミリセカンド単位でランダム時間を算出し、TPTでURLによって参照されたコンテンツを検索するためにインターネットサーバーに接続する前にこの時間量だけ遅延されると予想できる。
EventエレメントのチャイルドエレメントであるDataは、存在する場合、当該イベントに関連するデータを提供することができる。Eventの互いに異なる活性化は、これらの活性化と関連している互いに異なるDataエレメントを有することができる。ここで、Dataエレメントは、@dataID属性を含むことができる。16ビット整数属性である@dataIDは、これを含むEventエレメントの範囲内でDataエレメントを固有に識別することができる。イベントの活性化がこれと関連するデータを有する場合、活性化トリガーは、AppID、EventID及びDataIDの組合せによって当該Dataエレメントを識別することができる。Dataエレメントは、当該イベントに用いられるデータを示す。一つのイベントエレメントは複数のデータエレメントを有することができる。データエレメントの@dataID属性を用いてデータが識別される。受信端では該当データに関連するイベントが活性化された場合、活性化トリガー(又は、AMT内活性化エレメント)は、AppID、EventID、及びDataIDの組合せによってDataエレメントを識別することができる。AMTに関する詳細な内容は後述する。
図7は、‘Frequency of Use’属性値の意味の一実施例を示す図である。
“意味”列は、当該アプリケーションを含むセグメントの発生頻度を示す。(もちろん、一つのセグメント内で一つの属性が複数回登場可能である。)frequencyOfUse属性は、globalIDが存在しなければ存在することができない。万一、アップがキャッシュに保存されて後で用いられるとすれば、受信機は、該当アップが後で再び登場すると、同一のアップとして認識しなければならない。そのためにglobalId属性が必要である。
図8は、‘destination’属性値の意味の一実施例を示す図である。
図8に示すように、目的地属性の値が0のときに予約され、1のときに主装置のみを意味し、2のときに一つ以上の補助装置のみを意味し、3のときに主装置及び/又は一つ以上の補助装置を意味することができる。
図9、図10、図11、図12、図13は、TDOパラメータテーブルの2進形態のシンタックスの一実施例を示す図である。
これは、上述したTPT構造の2進フォーマットである。この構造は、NRTでTPTを送信する場合に必要なフォーマットであって、TPTのXML構造をNRTで送信するのに適するように作成しておいたものである。
TPTのXMLバージョンに含まれた次のエレメント及び/又は属性、すなわち、@protocolVersion(major/minor)、@serviceID及び@tptVersionは、2進テーブルを伝達するためのカプセル化ヘッダー(encapsulation header)によって放送ストリームで提供できるため、2進バージョンから省略することができる。
フィールドのセマンティックスは、次の通りである。図9、図10、図11、図12、図13の順に続くTDOパラメータテーブルの2進フォーマットにおいて、上から下に登場する順に記述した。
1ビットフィールドであってもよいexpire_date_includedは、expire_datefieldが含まれるか否かを示すことができる。その値が‘1’であれば、当該フィールドが含まれることを意味でき、その値が‘0’であれば、含まれないことを意味できる。
5ビットフィールドであってもよいsegment_id_lengthは、segment_idのバイト長を示すことができる。
可変長フィールドであるsegment_idは、セグメントIDのバイトを含むことができるが、これは、TPTXMLフォーマットの“id”属性と同じセマンティックスを有することができる。
8ビットフィールドであってもよいbase_URL_lengthは、base_URLフィールドのバイト長を示すことができる。
可変長フィールドであるbase_URLはベースURLのバイトを含むことができるが、これは、TPTXMLフォーマットのbaseURL属性と同じセマンティックスを有することができる。
32ビットフィールドであってもよいexpire_dateは、当該TPTインスタンスに含まれた情報の満了日及び時間を示すことができる。受信機がTPTをキャッシュに保存すると、満了日まで再使用することができる。符号無し整数(unsigned integer)は、1980年1月6日00:00:00 UTC以後、GPS秒(second)の数からGPS−UTC_offsetを引いたものと解釈することができる。GPS UTCオフセットはGPSとUTC時刻標準間現在の全体秒単位オフセットを定義する8ビット符号無し整数であってもよい。
8ビットフィールドであってもよいtrigger_server_URL_lengthは、trigger_server_URLフィールドのバイト長を示すことができる。このフィールドの値が0であれば、個々の活性化トリガーのインターネット伝達が利用可能でないことを示すことができる。
trigger_server_URL_lengthフィールドが0でなければ、trigger_server_URLは、Trigger Server URLのバイトを含むことができ、これはTPTXMLフォーマットのLiveTriggerエレメントのURL属性と同じセマンティックスを有することができる。
1ビットフィールドであってもよいtrigger_delivery_typeは、インターネットを介した個別活性化トリガーの伝達モードを示すことができる、‘0’値を有すると、HTTPショートポーリングが使用中であることを示すことができ、‘1’値を有すると、HTTPロングポーリング又はHTTPストリーミングが使用中であることを示すことができる。
8ビット整数であってもよいpoll_periodは、HTTPショートポーリングが使用中であるとき、ポール間の推奨される秒の数を示すことができる。
8ビットフィールドであってもよいnum_apps_in_tableは、当該TPTインスタンスで記述されたアプリケーション(TDO)の数を示すことができる。
16ビットフィールドであってもよいapp_idは、当該アプリケーション(num_apps_in_tableループ(loop)の反復で記述されるアプリケーション)に対する識別子を含むことができる。これは、当該TPTインスタンス内で固有であってもよい。
1ビットフィールドであってもよいapp_type_includedは、app_typeフィールドが当該アプリケーションに対して含まれるか否かを示すことができる。その値が‘1’であれば、当該フィールドが含まれることを意味し、その値が‘0’であれば、含まれないことを意味できる。
1ビットフィールドであってもよいapp_name_includedは、app_nameフィールドが当該アプリケーションに対して含まれるか否かを示すことができる。その値が‘1’であれば、当該フィールドが含まれることを意味し、その値が‘0’であれば、含まれないことを意味できる。
1ビットフィールドであってもよいglobal_id_includedは、global_idフィールドが当該アプリケーションに対して含まれるか否かを示すことができる。その値が‘1’であれば、当該フィールドが含まれることを意味し、その値が‘0’であれば、含まれないことを意味できる。
1ビットフィールドであってもよいapp_version_includedは、app_versionフィールドがこのアプリケーションに対して含まれるか否かを示すことができる。その値が‘1’であれば、当該フィールドが含まれることを意味し、その値が‘0’であれば、含まれないことを意味できる。
1ビットフィールドであってもよいcookie_space_includedは、cookie_spaceフィールドがこのアプリケーションに対して含まれるか否かを示すことができる。その値が‘1’であれば、当該フィールドが含まれることを意味し、その値が‘0’であれば、含まれないことを意味できる。
1ビットフィールドであってもよいfrequency_of_use_includedは、frequency_of_useフィールドがこのアプリケーションに対して含まれるか否かを示すことができる。その値が‘1’であれば、当該フィールドが含まれることを意味し、その値が‘0’であれば、含まれないことを意味できる。
1ビットフィールドであってもよいexpire_date_includedは、expire_dateフィールドがこのアプリケーションに対して含まれるか否かを示すことができる。その値が‘1’であれば、当該フィールドが含まれることを意味し、その値が‘0’であれば、含まれないことを意味できる。
8ビットフィールドであってもよいapp_typeは、存在する場合、このアプリケーションのフォーマット類型を示すことができる。その値が0であれば、そのアプリケーションがTDOであることを示すことができる。万一、このフィールドが存在しない場合、その値は0にデフォルトされる。他の値は他のフォーマットを示すことができる。
8ビットフィールドであってもよいapp_name_lengthは、存在する場合、その直後にくるapp_nameフィールドのバイト長を示すことができる。このフィールドの値が0であれば、該当アプリケーションのためのapp_nameフィールドが存在しないことを示すことができる。
可変長フィールドであるapp_nameは、TPT XMLフォーマットであるTDOエレメントのappName属性と同じセマンティックスを有することができる。
8ビットフィールドであってもよいglobal_id_lengthは、その直後にくるglobal_idフィールドのバイト長を示すことができる。このフィールド値が0であれば、当該アプリケーションのためのglobal_idフィールドが存在しないことを示すことができる。
可変長フィールドであるglobal_idは、TPT XMLフォーマットのTDOエレメントのglobalId属性と同じセマンティックスを有することができる。
8ビットフィールドであってもよいapp_versionは、TPT XMLフォーマットのTDOエレメントのappVersion属性と同じセマンティックスを有する。
8ビットフィールドであってもよいcookie_spaceは、TPT XMLフォーマットのTDOエレメントのcookieSpace属性と同じセマンティックスを有することができる。
8ビットフィールドであってもよいfrequency_of_useは、存在する場合、TPT XMLフォーマットのTDOエレメントのfrequencyOfUse属性と同じセマンティックスを有することができる。
8ビットフィールドであってもよいexpire_dateは、TPT XMLフォーマットのTDOエレメントのexpireDate属性と同じセマンティックスを有することができる。
1ビットフィールドであってもよいtest_appは、当該アプリケーションが一般受信機に無視されるようになっているテストアプリケーションであるか否かを示すことができる。その値が‘1’であれば、テストアプリケーションであることを意味でき、その値が‘0’であれば、テストアプリケーションでないことを意味できる。
1ビットフィールドであってもよいavailable_on_internetは、当該アプリケーションがインターネットを介して利用可能か否かを示すことができる。その値が‘1’であれば、インターネットを介して利用可能であることを意味でき、その値が‘0’であれば、インターネットを介して利用可能でないことを意味できる。
1ビットフィールドであってもよいavailable_in_broadcastは、当該アプリケーションが放送を介して利用可能か否かを示すことができる。その値が‘1’であれば、放送を介して利用可能であることを意味でき、その値が‘0’であれば、放送を介して利用可能でないことを意味できる。4ビットフィールドであってもよいnumber_URLsは、当該アプリケーションを含むファイルの数を示すことができる。
8ビットフィールドであってもよいURL_lengthは、それに続くURLフィールドの長さを示すことができる。
可変長フィールドであるURLは、TPT XMLフォーマットであるTDOエレメントのURL属性と同じセマンティックスを有することができる。
8ビットフィールドであってもよいnumber_content_itemsは、このアプリケーションによる使用のためにダウンロードしなければならないコンテンツアイテムの数を示すことができる。
1ビットフィールドであってもよいupdates_availは、このコンテンツアイテムがたまにアップデートされる否か、すなわち、コンテンツアイテムが固定ファイルの集合であるか、それとも、実時間データフィードであるかを示すことができる。その値が‘1’であれば、アップデートされることを示すことができ、その値が‘0’であれば、アップデートされないことを示すことができる。
1ビットフィールドであってもよいavail_internetは、このコンテンツアイテムを含むファイルをインターネットを介してダウンロードできるか否かを示すことができる。その値が‘1’であれば、インターネットを介したダウンロードに利用可能であることを意味でき、その値が‘0’であれば、インターネットを介したダウンロードに利用可能でないことを意味できる。
1ビットフィールドであってもよいavail_broadcastは、このコンテンツアイテムを含むファイルを放送を介してダウンロードできるか否かを示すことができる。その値が‘1’であれば、放送を介したダウンロードに利用可能であることを意味でき、その値が‘0’であれば、放送を介したダウンロードに利用可能でないことを意味できる。
1ビットフィールドであってもよいcontent_size_includedは、このアプリケーションのためにcontent_sizeフィールドが含まれるか否かを示すことができる。その値が‘1’であれば、当該フィールドが含まれることを意味でき、その値が‘0’であれば、含まれないことを意味できる。
4ビットフィールドであってもよいnumber_URLsは、このコンテンツアイテムを含むファイルの数を示すことができる。
8ビットフィールドであってもよいURL_lengthは、それに続くURLフィールドの長さを示すことができる。
可変長フィールドであるURLは、TPT XMLフォーマットであるTDOエレメントのチャイルドエレメントであるContentItemのURL属性と同じセマンティックスを有することができる。
24ビットフィールドであってもよいcontent_sizeは、TPT XMLフォーマットであるTDOエレメントのチャイルドエレメントであるContentItemのcontentSize属性と同じセマンティックスを有することができる。
8ビットフィールドであってもよいnum_content_descriptorsは、その直後にくるデスクリプタループ内のコンテンツデスクリプタの数を示すことができる。
可変長フィールドであるcontent_descriptor()は、MPEG−2デスクリプタフォーマット(タグ、長さ、データ)に従うデスクリプタであってもよい。このフィールドは、当該コンテンツアイテムに関する付加情報を提供することができる。このデスクリプタループに含み得るデスクリプタの中に、このコンテンツアイテムの意味ある表出のために必要な受信機能力を示すCapabilitiesデスクリプタがあってもよい。
8ビットフィールドであってもよいnumber_eventsは、このTDOに対して定義されたイベントの数を示すことができる。
16ビットフィールドであってもよいevent_idは、当該イベント(number_eventsループの反復で記述されたイベント)のための識別子を含むことができる。このフィールドは、当該アプリケーションの範囲内で唯一であってもよい。当該イベントはapp_idとevent_idの組合せによって活性化トリガーら内で参照されてもよい。
5ビットフィールドであってもよいactionは、TPT XMLフォーマットであるTDOエレメントのEventチャイルドエレメントのaction属性と同じセマンティックスを有することができる。
1ビットフィールドであってもよいdestination_includedは、当該イベントのためにdestinationフィールドが含まれるか否かを示すことができる。その値が‘1’であれば、このフィールドが含まれることを示すことができ、その値が‘0’であれば、含まれないことを示すことができる。
1ビットフィールドであってもよいdiffusion_includedは、当該イベントのためにdiffusionフィールドが含まれるか否かを示すことができる。その値が‘1’であれば、このフィールドが含まれることを示すことができ、その値が‘0’であれば、含まれないことを示すことができる。
1ビットフィールドであってもよいdata_includedは、当該イベントのためにdata_sizeとdata_bytesフィールドが含まれるか否かを示すことができる。その値が‘1’であれば、このフィールドらが含まれることを示すことができ、その値が‘0’であれば、含まれないことを示すことができる。
destinationフィールドのセマンティックスは、存在する場合、TPT XMLフォーマットであるTDOエレメントのEventチャイルドエレメントのdestination属性のセマンティックスと同一であってもよい。
diffusionフィールドのセマンティックスは、存在する場合、TPT XMLフォーマットであるTDOエレメントのEventチャイルドエレメントのdiffusion属性のセマンティックスと同一であってもよい。
data_sizeフィールドは、存在する場合、その直後にくるdata_bytesフィールドの大きさを示すことができる。
data_bytesフィールドは、存在する場合、当該イベントに関連するデータを提供することができる。当該イベントが活性化される度にターゲットアプリケーションはそのデータを読み取り、それを用いて所望の動作の実行を助けることができる。このフィールドは、原始(raw)の2進値を含み得るということを除けば、その内容がTPT XMLフォーマットである該当のTDOエレメントの該当のEventチャイルドエレメントの該当のDataチャイルドエレメントの内容と同一なあってもよく、TPT XMLフォーマットであるこのDataエレメントはその2進値のベース64エンコーディングを含むことができる。
8ビットフィールドであってもよいnum_app_descriptorsは、その直後にくるデスクリプタループ内のデスクリプタの数を示すことができる。
可変長フィールドであるapp_descriptor()は、MPEG−2デスクリプタフォーマット(タグ、長さ、データ)に従うデスクリプタであってもよい。このフィールドは、当該アプリケーション(TDO)に関する付加情報を提供することができる。このデスクリプタループに含み得るデスクリプタの中に、このアプリケーションの意味ある表出のために必要な受信機能力を示すCapabilitiesデスクリプタがあってもよい。
8ビットフィールドであってもよいnum_TPT_descriptorsは、その直後にくるデスクリプタループ内のデスクリプタの数を示すことができる。
可変長フィールドであるTPT_descriptor()は、MPEG−2デスクリプタフォーマット(タグ、長さ、データ)に従うデスクリプタであってもよい。このフィールドは、当該TPTに関する付加情報を提供することができる。このデスクリプタループに含み得るデスクリプタの中に、このTPTによって示される双方向サービスの意味ある表出のために必要な受信機能力を示すCapabilitiesデスクリプタがあってもよい。
図14は、活性化メッセージテーブル構造の一実施例を示す図である。以下、テーブルに含まれる各フィールドについて説明する。各フィールドの大きさとテーブルに含み得るフィールドの種類は、設計者の意図によって追加又は変更されてもよい。
活性化メッセージテーブル(Activation Messages Table:AMT)は、セグメントのための活性化トリガーに相応するものを含むことができる。ある環境では活性化トリガーに代えてこのAMTが受信機に伝達されてもよい。トリガーは、“livetrigger”サーバーによって、ACRサーバーによってAMTを介してクローズドキャプション(closed caption)ストリームで伝達されてもよい。
AMT構造内のフィールドの具体的なセマンティックスは、次の通りである。
活性化メッセージテーブル(AMT)は、@majorProtocolVersion、@minorProtocolVersion、@segmentId、@beginMT属性、及び/又はActivationエレメントを含むことができる。
AMTエレメントの4ビット属性であってもよい@majorProtocolVersionは、AMT定義の主バージョン番号を示すことができる。主バージョン番号は1に設定することができる。受信機は、それらが支援するように備えられていない主バージョン値を示すAMTのインスタンスを捨てると予想できる。
AMTエレメントの4ビット属性であってもよい@minorProtocolVersionは、存在する場合、AMT定義の副バージョン番号を示すことができる。存在しない場合、その値は0にデフォルトすることができる。副バージョン番号は0に設定することができる。受信機は、それらが支援するように備えられていない副バージョン値を示すAMTのインスタンスを捨てないと予想され得る。この場合、受信機はそれらが支援しない個別エレメント又は属性を無視すると予想されてもよい。
AMTの識別子である@segmentIDは、AMT内Activationが適用されるアプリケーション及びイベントを含むTPTの識別子とマッチングされる。@segmentIdは、AMTの識別子の役割を担うことができる。したがって、受信端でAMTを受信した後にこれをパーシングし、@segmentId情報を用いてAMTを識別することができる。@segmentIdは、AMTがどのセグメントに適用されるべきかに関する情報を含んでおり、そのセグメントに関連するTPTが有している@idとマッチングされてAMTとTPTとを連結する役割を担うことができる。さらに、まず当該segmentを識別することによって、AMT内のそれぞれのActivationエレメントがターゲットとするTDO、イベントを識別するために必要な基本的な情報を提供することができる。
AMTエレメントの属性である@beginMTは、存在する場合、AMTインスタンスが活性化時間を提供するセグメントのメディア時間の開始を示すことができる。@beginMTは、属しているAMTが適用されるセグメントに対してメディア時間の開始を示すことができる。これによって、Activationエレメントが示す活性化が発生する時間の基準を定めることができる。したがって、@beginMTがある場合、Activationエレメント内の@startTime属性は、@beginMTが示すメディア時間の開始に影響を受けることができる。
AMTのActivationエレメントの各インスタンスは、あるイベントをこのイベントと関連しているあるデータと共にある時間に活性化する命令を示すことができる。Activationエレメントは、AMT内に複数個が存在してもよい。各Activationエレメントは、活性化トリガーと同様の役割を担うことができる。Activationエレメントはいずれも、AMT内の@segmentIdが示すセグメントに適用することができる。Activationエレメント内の属性に、該当活性化がどのアプリケーションの、どのイベントに、いつ起きるかに関する情報などを含めることができる。Activationエレメント内の属性に関する詳細な説明を次に説明する。
Activationエレメントは、@targetTDO、@targetEvent、@targetData、@startTime、@endTimeの属性を含むことができる。
Activationエレメントの属性である@targetTDOは、AMTに関連しているTPT内のTDOエレメントのappID属性とマッチングされることによって、活性化命令に対するターゲットアプリケーションを識別することができる。@targetTDOは、AMT内のActivationエレメントがどのアプリケーションに適用されるかに関する情報を含むことができる。受信端ではAMTを受信してパーシングして@targetTDOを得、マッチングされるTPT内のTDOエレメント内の@appIDを探して、Activationエレメントの適用されるアプリケーションを識別することができる。
Activationエレメントの属性である@targetEventは、targetTDO属性によって識別されるTDOエレメントに含まれたEventエレメントのeventID属性とマッチングされることによって、当該活性化命令に対するターゲットイベントを識別することができる。@targetEventは、AMT内のActivationエレメントがどのアプリケーションのどのイベントに適用されるかに関する情報を含むことができる。受信端ではAMTを受信しパーシングして@targetEventを得、マッチングされるTPT内のTDOエレメント内の@eventIDを探して、Activationエレメントの適用されるイベントを識別することができる。
Activationエレメントの属性である@targetDataは、targetTDOとtargetEvent属性によって識別されるEventエレメントに含まれたDataエレメントのdataIDとマッチングされることによって、活性化命令が適用される時にターゲットイベントと関連しているデータを識別することができる。@targetDataは、活性化命令が適用されるとき、ターゲットとなったイベントに関連するデータを識別することができる。受信端ではAMTを受信しパーシングして@targetDataを得、TPT内の該当Eventエレメント内の@dataIDを探すことができる。
イベントエレメントの属性である@startTimeは、メディア時間に対するイベントの有効期間の開始を示すことができる。受信機は、メディア時間がstartTime内の値に到達する時又はその後のできるだけ近いうちに当該命令を実行すると予想され得る。@startTimeは、当該イベントが起きる開始時間を示すことができる。この開始時間はメディア時間を基準とする。受信端ではAMTをパーシングして@startTime情報を得、これを用いてイベントの起きる時間が把握できる。受信端では、@segmentIdによって識別されたセグメントのメディア時間を基準にメディア時間が開始時間(start Time)に達すると、イベントを活性化させることができる。万一、既に開始時間が過ぎた場合は、できるだけ早くイベントを活性化させることができる。
イベントエレメントの属性である@endTimeは、メディア時間に対する当該イベントのための有効期間の終わりを示すことができる。受信機は、メディア時間がendTimeの値を経過すると当該命令を実行しないと予想され得る。@endTimeは、当該イベントが終わる時間を示すことができる。メディア時間が終わる時間に達すると、受信端ではイベントを実行させなくてもよい。
AMT内Activationエレメントは、startTime値の昇順で登場できる。
受信機がAMT内Activationによってイベントを活性化させるとき、受信機は、各活性化をその開始時間に適用したり、又はその後にできるだけ近いうちに適用(例えば、受信機がサービスに加入して、開始時間以降と終了時間以前との間におけるある時間にAMTを受信する場合)すると予想され得る。TPT内イベントエレメントの“action”属性が“exec”であれば、受信機はTriggerEventをターゲットアプリケーションに渡すと予想できる。TriggerEventについては、APIに関する部分で後述する。
図15は、URLリスト構造の一実施例を示す図である。
URLリストは、受信機に対して使用潜在性のあるURLを含むことができる。次のようなURLなどを含むことができる。
1.一つ又はそれ以上の未来セグメントに対するTPTのためのURL。受信機がファイルを予めダウンロードできるようにする。
2.放送ストリーム内の独立型NRTサービスに関する情報が検索され得るNRTシグナリングサーバーのURL。受信機に放送ストリーム内のNRTサービスシグナリングの伝達に対する接近権限がなくてもこれらのサービスに接近可能になる。
3.仮想チャネルに対する使用報告が送信される使用報告サーバーのURL。受信機に放送ストリーム内のこのURLの伝達に対する接近権限がなくてもこのような報告を送信可能にする。
4.仮想チャネルに対するPDI−QテーブルのURL。受信機に放送ストリームで伝達されたPDI−Qテーブルに対する接近権限がなくても視聴経験を個人化可能にする。(PDI−Qテーブルは双方向サービスを提供するにあたり、ユーザにカスタマイズサービスを提供するための個人化(personalization)に関連するテーブルである。PDI−Qテーブルを介してユーザに個人化のための質問ができる。)。
そのうち、UsrUrlエレメントに関して、URLリストを作ってさらに使用報告のためのサーバーのURLを知らせる必要があり得る。これは、現在、受信機が視聴し消耗しているコンテンツの種類と好むデータを活用してビジネスに活用するためであってもよい。URLリストにあるUsrUrlエレメントは、次のように様々に解釈可能である。
第一は、使用報告サーバーである場合は、受信機はこの使用報告サーバーのURLをもって、予め定められたプロトコル(例、データ構造、XMLファイルなど)によって受信機の使用報告機能を果たすことができる。
第二は、受信機のウェブブラウザで実行されるTDOであってもよい。ここでは、使用報告TDOの位置を知らせ、この場合、TDOが直接、受信機のウェブブラウザのAPI(例、ファイルAPI、使用報告API)を用いて受信機に保存された或いは現在消耗しているコンテンツの情報を収集して報告することができる。TDOは、独自でXMLHttpRequestというジャバスクリプトAPIを活用して収集されたデータを送信することができる。
URLlistは、UrlList、TptUrl、UrsUrl、及び/又はPdiUrlなどを含むことができる。これらのエレメントのセマンティックスは次の通りである。
UrlListエレメントのエレメントであるTptUrlは、現在の双方向付加サービス内の未来セグメントに対するTPTのURLを含むことができる。複数のTptUrlエレメントが含まれた場合、放送内のセグメントの登場順に配列することができる。
UrlListエレメントのエレメントであるNrtSignalingUrlは、受信機が現在のトランスポートストリーム内の全ての仮想チャネルに対するNRTシグナリングテーブルを取得し得るサーバーのURLを含むことができる。
UrlListエレメントのエレメントであるUrsUrlは、受信機が現在の仮想チャネルに対する使用(視聴率調査)報告を送信し得るサーバーのURLを含むことができる。
UrlListエレメントのエレメントであるPdiUrlは、現在の仮想チャネルに対するPDI−QテーブルのURLを含むことができる。
図16は、TPTを含むプライベートセクションの二進フォーマットの一実施例を示す図である。図16は、後述する伝達メカニズムにおいて放送ストリームでTPTが伝達される場合を示す。詳細な内容は後述する。
トリガー、TPTなどを伝達する伝達メカニズムについて説明する。双方向サービス生成からの結果、放送ストリームでのトリガーの伝達、インターネットを介した時間ベーストリガーの伝達、インターネットを介した活性化トリガーの伝達(ACRシナリオ)、放送ストリームでのTPTの伝達、インターネットを介したTPTの伝達、TDO及びコンテンツアイテムの移動、複数セグメントの一つのセグメントへの結合(combining)などを順に説明する。
以下、双方向サービス生成からの結果について説明する。
一つのセグメントに対するサービス生成過程は、全てのTDO及び他のコンテンツアイテムを含むフォルダ、XML formatのTPTファイル、及びXML formatのAMTファイルを生成することができる。その他の結果物も生成することができる。
次に、放送ストリーム内でのトリガーの伝達について説明する。
放送ストリームで伝達される場合、トリガーはURLString命令内でサービス#6でDTVクローズドキャプションチャネルで伝達することができる。
万一、トリガーの長さが26文字以下であれば、トリガーはセグメント化せずに送信することができる(Type=11)。万一、トリガーの長さが27乃至52文字であれば、2つのセグメント(the first segment in a Type=00セグメントである一番目のセグメントと、Type=10セグメントである2番目のセグメント)で送信されてもよい。
当該命令の与えられた任意のインスタンスで伝達されたURIの類型は、インスタンス8ビットパラメータによって与えることができる。
TDOモデルを使用する双方向サービスの場合、URIデータ構造のURI類型は、0(TDOモデルのための双方向Interactive TVトリガー)に設定することができる。この伝達メカニズムは、時間ベーストリガーも活性化トリガーも含む。
時間ベーストリガーが(クローズドキャプションサービス#6で)放送ストリームで伝達される場合に、“m=”項が不在であれば、時間ベーストリガーは単純にシグナリングサーバーのURLを伝達することができる。そして、“m=”項が不在であれば、“t=”項は活性化トリガーに不在でなければならない。
活性化トリガーが(クローズドキャプションサービス#6で)放送ストリームで伝達される場合に、すなわち、“Trigger”フォーマットが“e=”項を有しており、“t=”項は有しているかいない場合に、“t=”項が存在すれば、活性化時間は時間ベースに対するタイムスタンプであってもよい。そして、“t=”項が不在であれば、活性化時間はメッセージの到達時間になってもよい。
時間ベーストリガーと活性化トリガーがCCサービス#6を介して伝達される場合、放送局で時間ベーストリガーと活性化トリガーを扱う方法には3つの可能な方法がある。この3つの方法は、‘明示的な時間ベースがないセグメントモード’、‘明示的な時間ベースがあるセグメントモード’、そして‘明示的な時間ベースがないサービスモード’である。
これらは放送内でセグメント単位で混合されてもよい。
明示的な時間ベースがないセグメントモードでは、活性化メッセージがタイムスタンプを含まないため、各メッセージの活性化時間はそのメッセージの伝達時間となり、また、時間ベースメッセージがタイムスタンプを含まないため、その唯一の目的はTPTファイルを伝達し得るシグナリングサーバーのURLを提供することであり得る。このモードでは、シグナリングサーバーのURLを提供するための活性化メッセージ内のURLによって時間ベースメッセージが完全に省略されてもよいが、この場合受信機は、最初の活性化メッセージが登場するまでTPTを検索したり、TDOのダウンロードを開始できなくなり、活性化メッセージに対する応答をだいぶ遅延することになる。
このような場合、CCサービス#6に登場し得る時間ベースメッセージは、“Trigger”フォーマットの“locator_part”を含むことができ、“spread”項も含むことができるが、“media_time”項は含まなくてもよい。そして、CCサービス#6で登場し得る活性化メッセージは、“Trigger”フォーマットの“locator_part”と“event_time”項を含むことができ、“spread”項も含むことができるが、“イベント_time”項には“t=”部分がなくてもよい。時間ベース及び活性化メッセージの“locator_part”は現在のsegmentIdであってもよい。このURLは、インターネットを介してセグメントのためのTPTを検索するために用いられてもよい。
明示的な時間ベースがあるサービスモードにおいて、時間ベースメッセージは時間ベースを定義するためにこのタイムスタンプを含む。活性化メッセージは、時間ベースに対する活性化時間を定義するために時間スタンプを含む。又は、これらのメッセージはタイムスタンプを含まなくてもよく、この場合、活性化時間はメッセージの到達時間である。
この場合、CCサービス#6で登場し得る時間ベースメッセージは、Trigger”フォーマットの“locator_part”と“media_time”項を含むことができ、“spread”項も含んでもよく、CCサービス#6で登場し得る活性化メッセージは“Trigger”フォーマットの“locator_part”と“event_time”項を含むことができ、“spread”項も含んでもよく、このとき、“event_time”項内の“t=”部分は存在してもしなくてもよい。時間ベース及び活性化メッセージの“locator_part”は現在のsegmentIdであってもよく、該当時間ベースは該当セグメントに特定である。このURLは、インターネットを介してセグメントのためのTPTを検索するために用いられてもよい。
明示的な時間ベースがあるサービスモードにおいて、時間ベースメッセージは時間ベースを定義するためにこのタイムスタンプを含み、活性化メッセージは時間スタンプを含んでも含まなくてもよい。時間ベースは特定の一セグメントに特定されるよりは、複数のセグメントにわたって延長することができる。時間ベースメッセージの“locator_part”は、時間ベースの識別子であってもよく、インターネットを介してサービスのためのTPTを検索するために使用可能なURLであってもよい。
いずれの場合であれ、CCサービス#6にトリガーを挿入するトリガー挿入サーバーは、AMTから作業をして、活性化メッセージをAMT内のXMSフォーマットからCCサービス#6での伝達に特定されたトリガーフォーマットに変えなければならない。endTime属性がないActivationエレメントの場合は、活性化時間がstartTime属性と同一であり、単一トリガーが挿入されてもよい。startTimeとendTimeエレメントの両方を有するActivationエレメントの場合は、同一のターゲットをもってトリガーシーケンスが挿入されてもよい。シーケンス内の最初のトリガーは、startTime属性と同じ活性化時間を有することができ、当該シーケンス内の最後のトリガーは、endTime属性と同じ活性化時間を有することができ、シーケンス内のトリガーの活性化時間の間には固定した時間区間が存在できる(例外として、シーケンス内の最後のトリガーとその直前のトリガーとの間の区間はより短くてもよい。)。この固定した時間区間の長さは設定可能である。
時間ベース及び活性化メッセージがセグメントモードであるとき、時間ベースは、セグメントに対して特定することができる。このベースは、当該セグメントの開始時に“beginMT”値で始まって、セグメントを通じて行うことができる。個々の活性化の“startTime”と“endTime”値は、“beginMT”値に対して相対的であってもよい。時間ベース及び活性化メッセージがサービスモードにあるとき、時間ベースはセグメントにわたっていてもよく、各セグメントに対する“beginMT”値は、サービス時間ベースと放送スケジュールを考慮して調整することができる。
次に、インターネットを介した時間ベーストリガーの伝達について説明する。
時間ベーストリガーインターネット伝達は、いわゆる自動コンテンツ認識(Automatic Content Recognition、ACR)状況で有用であり得るが、このような状況で、時間ベーストリガーの受信側はクローズドキャプションサービス#6に対する接近権限がない。このような状況で受信機はビデオフレームを認識し、時間ベースをこれらのフレームと同期化させるためにACRを使用しなければならない。ACR状況で時間ベースメッセージはウォーターマーク又はACRサーバーから得ることができる。ACRサーバーから受ける場合、時間ベースメッセージはACRサーバーから応答として伝達されてもよい。
次に、インターネットを介した活性化トリガーの伝達(ACRシナリオ)について説明する。
活性化メッセージは、ショートポーリング、ロングポーリング又はストリーミングを通じて伝達することができるが、これらのメッセージはいずれも受信機とサーバーに相当のオーバーロードを発生させ得る。活性化メッセージは、AMTの形態で伝達されてもよいが、セグメントの長さに関する多い量の情報を提供し、広告サイト遮断器(ad killer)を可能にすることができる。他の方法も可能である。
活性化メッセージが活性化トリガーの形態で伝達される場合に、すなわち、“Trigger”formatにおいて“e=”項はあり、“t=”項はあるかない場合に、これは、HTTPショートポーリング、ロングポーリング又はストリーミングを通じて伝達され得る。
インターネットを介して伝達される場合、活性化メッセージは、個別的活性化トリガー伝達メカニズムや一括的活性化トリガー伝達メカニズムのいずれか一方又は両方を用いて伝達することができる。
次に、個別的活性化トリガー伝達について説明する。
前述したように、個別活性化トリガーは、インターネットを介して伝達されるとき、HTTPショートポーリング、ロングポーリング又はストリーミングを用いて伝達すことができる。活性化トリガーのフォーマットはDTVCCサービス#6を通じて伝達されるときと同一であってもよい。
ショートポーリングの場合は、そのポーリング周期を指定しなければならない。この周期は、次の説明のように、TPTにあるpollPeriodを用いてショートポーリング動作を設定することができる。
活性化トリガーのインターネット伝達が利用可能な場合、TPT内LiveTriggerエレメントのURL属性は、活性化トリガーを伝達し得る活性化トリガーサーバーを示すことができる。LiveTriggerエレメントのpollPeriod属性がTPTに存在する場合、これはHTTPショートポーリングが使用中であることを示すことができ、この属性は、受信機が用いるべきポーリング周期を示すことができる。LiveTriggerエレメントのpollPeriod属性がTPTに存在しない場合、これは、HTTPロングポーリングとHTTPストリーミングのいずれか一方が使用中であることを示すことができる。
いずれのプロトコルが用いられるかにかかわらず、受信機は質疑形式で活性化トリガーサーバーにHTTP要求をすると予想できる。
?mt=<media_time>
ここで、<media_time>は、視聴されているコンテンツの現在メディア時間であってもよい。
ショートポーリングが使用中である場合、活性化トリガーサーバーからの応答は、<media_time>で終わるpollPeriod長の時間区間内で発生した全てのトリガーを含むことができる。一つ以上の活性化トリガーがリターンされる場合、これらは一つ以上の空白(whitespace)文字によって分離することができる。万一、リターンされる活性化トリガーがないと、当該応答は空いていてもよい。
HTTPロングポーリング又はHTTPストリーミングが使用中である場合は、活性化トリガーサーバーは、活性化トリガーが放送ストリームで伝達されるメディア時間まで応答のリターンを待機することができる。このとき、活性化トリガーをリターンすることができる。
HTTPロングポーリングが使用中である場合、活性化トリガーサーバーは、活性化トリガーをリターン後にセッションを閉じることができる。受信機はアップデートされたメディア時間を用いて直ちに他の要求をすると予想できる。
HTTPストリーミングが使用中である場合、活性化トリガーサーバーは、各活性化トリガーをリターンした後に当該セッションを開いた状態に維持し、追加の活性化トリガーを伝達する時間が到達すると、当該セッションでそれらのトリガーを伝達することができる。
いずれの場合においても、HTTP応答は、伝達モードを知らせるために、次の形態のいずれかの形態からなるHTTP Response Headerフィールドを含むことができる。
ATSC-Delivery-Mode:ShortPolling[<poll-period>]
ATSC-Delivery-Mode:LongPolling
ATSC-Delivery-Mode:Streaming
<poll−period>パラメータは、連続するポールに対してポール間の推奨間隔を示すことができる。<poll−period>は省略されてもよい。
次に、活性化トリガー一括伝達について説明する。
活性化トリガーがインターネットを介して一括的に伝達される場合、一つのセグメントに対する活性化トリガーを、当該セグメントに対するTPTをメッセージの一番目の部分とし、AMTをメッセージの二番目の部分とする多重部分MIMEメッセージの形態としてHTTPを通じて当該セグメントに対するTPTと共に伝達することができる。
以下、放送ストリームでのTPT伝達について説明する。
放送ストリームで伝達時に、TPTを、それらのXMLフォーマットから相応する2進NRT−スタイルシグナリングフォーマットに変換して、テーブルインスタンス当たり一つずつNRT−スタイルプライベートセクションにカプセル化することができる。現在セグメントに対するTPTは常に存在する。一つ以上の未来セグメントにに対するTPTも存在することができる。TPTインスタンスは、そのsegment_idフィールドの値によって定義される。参考として、TDOパラメータテーブルの2進フォーマットは、上述した通りである。ここで、NRT−スタイルプライベートセクションは、図16のtpt_section()に該当してもよい。
要するに、TPTの2進構造をNRTで送信するために、NRT送信に合うようにセクション構造を有することができる。以下、この過程について詳しく説明する。
各TPTをブロックに分割し、それらのブロックをtable_id、protocol_versionTPT_data_versionとsequence_numberフィールドの共通値を持つセクションのtpt_bytes()フィールドに挿入することによって、各TPTをNRT−スタイルプライベートセクション内にカプセル化することができる。これらのブロックは、section_numberフィールド値の昇順でセクションに挿入することができる。プライベートセクションは、TPTに関連する仮想チャネルのIPサブネットのサービスシグナリングチャネル(Service Signaling Channel;SSC)で送信することができる。ここで、“Service Signaling Channel”は、ATSC−NRT標準に定義されており、特定IPアドレスとポートナンバーを持つチャネルを意味する。セクション内のsequence_numberフィールドは、同一SSCで送信される互いに異なるTPTインスタンスを区別するために用いることができる。
以下、図16のフィールドについて説明する。
プライベートセクション(tpt_section())は、table_id、protocol_version、sequence_number、TPT_data_version、current_next_indicator、section_number、last_section_number、及び/又はservice_id、tpt_bytes()情報を含むことができる。
8ビットフィールドであってもよいtable_idは、当該テーブルセクションをTDOパラメータテーブルインスタンスに属するものとして識別することができる。
protocol_versionは2つの部分に分けることができる。8ビット符号無し整数フィールドのうち上位4ビットは、当該テーブルの定義の主バージョン番号と、ここに含まれて送信されるTPTインスタンスを示すことができ、下位4ビットは、副バージョン番号を示すことができる。主バージョン番号は1に設定することができる。受信機は、それらが支援するように備えられていない主バージョン値を示すAMTのインスタンスを捨てると予想され得る。副バージョン番号は0に設定することができる。受信機は、それらが支援するように備えられていない副バージョン値を示すAMTのインスタンスを捨てないと予想され得る。この場合、受信機はそれらが認識できないデスクリプタと、それらが支援しないフィールドを無視すると予想できる。
sequence_numberは、8ビットフィールドであってもよい。sequence_numberは、当該TPTインスタンスの他の全てのセクションのsequence_numberと同一であり、当該サービスシグナリングチャネル内の他のTPTインスタンスの全てのセクションのsequence_numberとは異なってよい。したがって、他のTPTインスタンスと区別する役割を担うことができる。sequence_numberフィールドは、このセクションが現れるサービスシグナリングチャネルに関連しているIPサブネットを示すことができる。互いに異なるTPTインスタンスのsequence_numberフィールド値は、放送ストリームでセグメントが登場する順序を反映することができる。
TPT_data_versionは、5ビットフィールドであってもよく、当該TPTインスタンスのバージョン番号を示すことができるが、ここで、TPTインスタンスは、そのsegment_idによって定義することができる。TPTバージョンをあらかじめ知ってこそ受信されたTPTセクションデータが最新バージョンのTPTであるか否かがわかるため、セクションテーブルにTPT_data_versionフィールドがあってもよい。バージョン番号は、TPTインスタンス内の任意のフィールドに変更がある場合、1 modulo 32分ずつ増分できる。
current_next_indicatorは1ビット指示子であってもよく、TPTセクションに対して常に‘1’に設定されて送信されるTPTがsegment_idによって識別されるセグメントに対して常に現在TPTであることを示すことができる。
section_numberは8ビットフィールドであってもよく、当該TPTインスタンスセクションのセクション番号を提供することができるが、TPTインスタンスはsegment_idによって識別可能である。TPTインスタンス内の最初のセクションのsection_numberは0x00であってもよい。section_numberは、TPTインスタンス内の各追加セクションと共に1ずつ増分可能である。
last_section_numberは8ビットフィールドであってもよく、最後のセクション(すなわち、section_numberが最も高いセクション)が、その一部であるTPTインスタンスの最後のセクション番号を提供することができる。
service_idは、当該テーブルインスタンスに記述されたコンテンツアイテムを提供する双方向サービスと関連しているservice_idを特定することができる。
tpt_bytes()は、可変長フィールドであって、当該セクションによって部分的に送信されるTPTインスタンスブロックで構成することができる。当該テーブルインスタンスの全てのセクションのtpt_bytes()フィールドがsection_numberフィールドの順に連結されると、その結果として一つの完全なTPTインスタンスが作成できる。
すなわち、TPTの2進フォーマットを用いたり、XMLフォーマットを2進フォーマットに変えた後、NRT送信に合うようにそれを分けて、プライベートセクションのうちtpt_bytes()フィールドに入れてNRT方式で送信することができる。このとき、一つのTPTが複数のプライベートセクションに分けられると、それぞれのプライベートセクションは、同一のtable_id、protocol_versionTPT_data_version、sequence_number値を有することができる。分けられたTPTブロックをsection_numberフィールド値に従う順に挿入することができる。
受信端では、受信したプライベートセクションに対してパーシングできる。一つのTPTに再びまとめるために、同一のtable_id、protocol_versionTPT_data_version、sequence_number値を持つプライベートセクションを用いることができる。このとき、section_numberとlast_section_number情報から得られる順序情報を用いることができる。同一のtable_id、protocol_versionTPT_data_version、sequence_number値を持つ全てのプライベートセクションのtpt_bytes()がsection_numberの順に連結されると、その結果として一つの完全なTPTを作成できる。
インターネットを介したTPTの伝達について図17を参照して詳しく説明する。
次に、TDO及びコンテンツアイテムの移動について説明する。
ネットワークと基地局は、TDO及びこれらのTDOによって用いられるコンテンツアイテム(ファイル)の伝達のために、自体HTTPサーバーを頻繁に提供しなければならない。提供がなされると、TPT内のbaseURLはサーバーの位置を反映して調整されてもよい。
次に、複数のセグメントを一つのセグメントへの結合について説明する。
セグメント間の境界を徹底的に曖昧にさせるために、複数のセグメントに対するTPTとAMTを一つのTPT及びAMTに結合することができる。その段階は、次の通りである。
1.結合されるセグメントの集合を識別する。
2.新しいsegmentIdを有する新しいTPTを生成する。
3.結合されるセグメントの中でライブ活性化を有するものがあれば、それらの活性化の全てに対して接近権限を付与するリレーサーバーを提供し、このサーバーに対するパラメータを“LiveTrigger”エレメントに入れる。
4.必要によって各セグメントに対してbaseURLを適用して全体TDOとContentItem URLを得る(結合される全てのセグメントに共通するより短いbaseURLを識別し、それを、結合されたセグメントに対するbaseURLとして維持する)。
5.必要によって値を修正して衝突を除去する。
6.結合される全てのセグメントに対する全ての修正されたTDOエレメントを新しいTPTに挿入する。
7.結合されたTPTの新しいsegmentIdに相応するsegmentIdを有する新しいAMTを生成する。
8.新しいAMTに対して適切な新しい“beginMT”値を選択する。
9.appId値における変更を反映して結合されるセグメントに対するAMTファイル内の全てのActivation要素のtargetId値を調整する。
10.新しい“beginMT”値と結合されるセグメントに対する放送スケジュールを反映して結合されるセグメントに対するAMTファイル内の全てのActivationエレメントのstartTimeとendTime値を調整する。
11.修正された全てのActivationエレメントを新しいAMTに挿入する。
図17は、XML文書としてエンコードされたURL目録の一実施例を示す図である。
以下、インターネットを介したTPTの伝達について説明する。
インターネットで伝達される場合、TPTはHTTPを通じて伝達することができる。時間ベースメッセージで現在セグメントに対するTPTのURLは“<domain name part>/<directory path>”であってもよい。TPTに対する要求に対する応答は、単純にTPTで構成されてもよく、要求されたTPTは第1部分にあり、URLリストは第2部分にあってXML文書としてエンコードされる2−部分MIMEメッセージとして構成されてもよい(要求に対する応答は常に現在セグメントに対するTPTを含む。一つ以上の未来セグメントらに対するTPTも含むことができる)。
上述した応答の第2部分としてのURLは、図17のような形態であってもよい。
図17のエレメントのセマンティックスについて説明する。
“UrlList”は、受信機に有用なURLリストを含むことができる。
“TptUrl”は、未来セグメントに対するTPTのURLを含むことができる。複数のTptUrlエレメントが含まれる場合、それらは、放送でセグメントの登場順に配列することができる。
“NrtSignalingUrl”は、受信機が現在の放送ストリームで全ての仮想チャネルに対するNRTシグナリングテーブルを取得し得るサーバーのURLを含むことができる。
図18は、addTriggerEventListenerの一実施例を示す図である。
以下、DOを実行するための環境のための、ATSCJavaScriptAPIについて説明する。
放送プログラムに対する宣言的客体動作の同期化を支援するために、ビデオ/放送客体に対して追加の方法が支援されてもよい。
DTVCC或いはインターネットでTPTが受信されると、TPT内にはTDOを実行するための複数のイベントがあってもよく、これらのイベントは活性化トリガーによって活性化されてもよい。
このイベントを処理するようにするために、リスナー(Listener)という関数をeventID別に登録しておくことができる。これによって、上述の‘追加の方案’として、リスナー関数を登録できる次の2つの関数があり得る。
図18には、addTriggerEventListenerについての説明とフォーマット、アーギュメント(argument)などが示されている。
”addTriggerEventListener”関数は、eventIdごとに生成されたイベントを処理するコールバック(callback)関数(リスナー関数)を登録することができる。”addTriggerEventListener”関数は、EventListenerタイプのlistener及びNumberタイプのeventIdをアーギュメントとして受け取ることができる。EventListenerタイプについて後述する。”addTriggerEventListener”関数は返還値を有しなくともよい(void)。ここで、eventIdアーギュメントは、TPTのイベントエレメントにおいてイベントIDであってもよい。ここで、listenerアーギュメントは、イベントに対するリスナーであってもよい。
受信機のトリガー処理モジュールでは活性化メッセージを受信するすと直ちに“addTriggerEventListener”関数を用いてeventIdごとにリスナー関数を登録することができる。後で当該イベントに活性化が起きると、登録されたリスナー関数を呼び出すことができる。このとき、TriggerEventタイプの客体をリスナー関数として伝達することができる。TriggerEventタイプについては後述する。
図19は、removeTriggerEventListenerの一実施例を示す図である。
図19には、removeTriggerEventListenerに対する説明とフォーマット、アーギュメントなどが示されている。
”removeTriggerEventListener”関数は、eventIdごとに生成されたイベントを処理するコールバック関数(リスナー関数)の登録を取消すことができる。”removeTriggerEventListener”関数は、EventListenerタイプのlistener及びNumberタイプのeventIdをアーギュメントとして受け取ることができる。EventListenerタイプについて後述する。”removeTriggerEventListener”関数は返還値を有しなくてもよい(void)。ここで、eventIdアーギュメントは、TPTのイベントエレメントでイベントIDであってもよい。ここで、listenerアーギュメントは、イベントに対するリスナーであってもよい。
ジャバスクリプトプログラムでは、当該eventId別に発生し得るイベントをそれ以上受信しないことを希望したり、“DestroyWindow”のようなプログラム終了時には、“removeTriggerEventListener”を用いて、登録されたリスナー関数を取り消すことができる。
図20は、EventListenerタイプの定義の一実施例を示す図である。
ここで、EventListenerタイプの定義は、Web IDL(Web interface definition language)(インターフェース定義言語)に従う。Web IDLは、ウェブブラウザーで実行されるように意図的インターフェースを記述するために用いることができる。Web IDLは、ウェブプラットフォームにおける共用スクリプトオブジェクトの動作をより読みやすく明細化するための多数の機能を有するIDLの変種である。
EventListenerタイプは、TriggerEventタイプを持つイベントをアーギュメントとすることができる。EventListenerはインターフェースであってもよい。
図21は、TriggerEventタイプの定義の一実施例を示す図である。
TriggerEventタイプは、イベントに関する情報を含むことができる。
TriggerEventタイプは、eventId、data、statusを属性として有することができる。ここで、eventIdは、TPTのイベントエレメント中のeventIdであってもよい。ここで、dataは、イベントの活性化のためのものであってもよい。ここで、dataは、16進法となっていてもよい。ここで、statusは、イベントの状態を意味することができる。ここで、status値が“trigger”の場合は、イベントが活性化トリガーによって活性化された状態を意味できる。ここで、status値が“error”の場合は、エラーが発生した状態を意味できる。
TDOモデルについて説明してきた。以下、直接実行モデルについて説明する。
直接実行モデルでは、仮想チャネルが選択されると、宣言的客体(Declarative Object;DO)が自動で開始され得る。DOは、スクリーン上の特定位置での画面の生成、世論調査の実行、他の特殊DOの開始などのようにオーディオ−ビデオプログラムと同期化される双方向特徴の提供のための具体的な指示事項を得るために、バックエンド(backend)サーバーとインターネットを介して通信することができる。
以下直接実行モデルにおけるトリガー動作について説明する。
トリガーの役割、機能、シンタックスは、直接実行モデルにおいても大きく変わらない。
トリガーの性能については、上述した通りである。
トリガーシンタックスについては、上述した通りである。
トリガーは、3つの部分で構成されたと見なすことができる。
<ドメインネーム部分>/<ディレクトリ経路>[?<パラメータ>]
直接実行モデルにおいて、<ドメインネーム部分>と<ディレクトリ経路>の組合せは、開始されるDOを固有に識別することができる。
<パラメータ>は、“event_time”、“media_time”、又は“spread”のうち一つ以上からなることができる。
直接実行モデルにおいて、仮想チャネルが選択されると直ちにアプリケーションが自動で開始されうる。アプリケーションは、“同期化されたコンテンツプロトコル”を介してバックエンドサーバーとインターネットで通信することができる。このサーバーは、オーディオ−ビデオプログラムと全て同期化された双方向特徴の提供のための具体的な指示事項を提供することができる。
直接実行モデルの場合、直ちにアプリケーションが実行されるために、時間ベーストリガーが伝達されるやいなや、現在実行中のアプリケーションに情報を伝達することができる。このモデルにおいて、アプリケーションは、サーバーに、同期化のために、現在放映中のコンテンツに関する情報を続けて伝達する必要がある。そのために、時間ベーストリガーには、TDOモデルとは異なる特別な情報がさらに含まれてもよい。この特別な情報は、現在放映中のコンテンツに対する識別子であってもよい。
同様に、上記コンテンツ識別子は、トリガーのパラメータ部分にパラメータの形態で存在できる。
同様に、上記コンテンツ識別子は、トリガーのmedia_timeに一つの項の形態で存在してもよい。コンテンツ識別子項は、文字列を伴う“c=”によって指定されうるcontent_idと呼ぶことができ、現在見られているコンテンツに対する識別子を示すことができる。
content_id項は、双方向サービス実行に対する直接実行モデルを支援するためのものであってもよい。
上述した通り、このモデルにおいて、content_id項を有する時間ベーストリガーは、アプリケーションの開始後にこのアプリケーションに伝達されてもよく、このアプリケーションは、双方向作用のためのコンテクスト(context)の識別のために、content_idをバックエンドサーバーに伝達することができる。詳細な動作については後述する。
直接実行モデルにおけるトリガーの伝達メカニズムについては、上述した通りである。
ただし、放送ストリームによるトリガーの伝達の場合において、トリガーは、URLString命令でサービス#6でDTVクローズドキャプションチャネルに伝達されてもよい。そして、直接実行モデルを用いる双方向サービスは、URI_typeフィールドが2(直接実行モデルのための双方向TVトリガー)に設定されてもよい。
以下、直接実行モデルの全体動作について説明する。
双方向サービスを実行する一つのモデルとして、直接実行モデルでは、仮想チャネルが選択されると直ちにアプリケーションが自動で開始されうる。アプリケーションは“同期化されたコンテンツプロトコル”を介してインターネットでバックエンドサーバーと通信することができる。このサーバーは、スクリーン上の特定位置での画面の生成、世論調査の実行、他の特殊DOの開始などのようにオーディオ−ビデオプログラムと同期化される双方向特徴の提供のための具体的な指示事項を提供することができる。
上記の動作を次のように行うことができる。
まず、アプリケーションが開始されうる。その後、時間ベーストリガーが受信される。時間ベーストリガーは、アプリケーションが実行された後にアプリケーションに伝達される。時間ベーストリガーのcontent_id項には、現在見られているコンテンツに関するコンテンツ識別情報が含まれていてもよい。アプリケーションは、相互作用のためのコンテクストを識別し、現在見られているコンテンツを識別するためにcontent_idをバックエンドサーバーに伝達することができる。
直接実行モデルについて説明してきた。
図22は、WM技法のためのアーキテクチャの一実施例を示す図である。
他のインターフェースを介した伝達について説明する。
非圧縮されたオーディオ及びビデオにのみ接近可能な(例えば、ケーブル又は衛星セットトップボックスから受信される)環境で双方向サービスの取得を可能にするプロトコル及びアーキテクチャが定義される。アーキテクチャ及びプロトコルは、インターネット接続を有し、放送ストリームからの非圧縮されたオーディオ及びビデオにのみ接近できる受信機による使用のために設計することができる。勿論、アーキテクチャ及びプロトコルは、双方向サービスプロバイダがそれの支援を選択する場合は、成功的に用いることができる。
このアーキテクチャは、視聴されているコンテンツの識別のための2つの基本技法を支援するように設計され、関連双方向サービスデータ改善事項がインターネットを介して伝達されうるようにすることができる。2つの基本技法は、ウォーターマーキング(Water marking)とフィンガープリンティング(Finger printing)であってもよい。
ウォーターマーキング、フィンガープリンティング技法両方とも、その目的は、どのプログラムが現在視聴されているかを受信機が探して、当該プログラムのための双方向サービスに関する付加情報を得る出発点として用いられうるURLを取得できるようにすることである。
図22は、WM技法のためのアーキテクチャの一実施例を示す図である。
WM技法のためのアーキテクチャにおいて、アーキテクチャは、放送局22010、ウォーターマーク挿入部22011、MVPD 22020、STB 22030、受信機22040、WMクライアント22050、TPTサーバー22060及びコンテンツサーバー22070で構成することができる。
放送局22010は、オーディオ/ビデオストリーム及びこれと関連する双方向サービスを送出するソースであってもよい。TV放送局などをその例に挙げることができる。 放送局22010は、放送コンテンツの生産者又は流通業者であってもよい。放送局22010は、放送ストリーム、オーディオ/ビデオコンテンツ、双方向データ、放送スケジュール又はAMTなどを伝達することができる。
ウォーターマーク挿入部22011は、放送されるオーディオ/ビデオフレームにウォーターマークを入れることができる。ウォーターマーク挿入部22011は、放送局22010と統合されてもよく、別個のモジュールであってもよい。ウォーターマークとは、受信機に必要な一種の情報であってもよい。ウォーターマークは、URLのような情報であってもよい。ウォーターマークについての詳細は後述する。
MVPD 22020は、多重チャネルビデオプログラム流通業者(Multiprogram Video Program Distributor)の略語である。MVPD 22020は、ケーブル事業者、衛星事業者又はIPTV事業者であってもよい。MVPD 22020は、放送局/ウォーターマーク挿入部から放送ストリームを受信することができ、ウォーターマーキングACRシステムの場合、ウォーターマーク挿入部22011によってウォーターマークが挿入される。MVPD 22020は、たびたびオーディオ及びビデオトラック以外の全てのプログラムエレメントを除くストリームを顧客の宅内のセットトップボックス(STB)に送る。
STB 22030は一般にオーディオ及びビデオをデコーティング(圧縮解除)し、これらを、視聴者が視聴するTV受像機に送る。STBは、非圧縮されたオーディオ/ビデオコンテンツを受信機22040に送ることができる。STBは、本発明の一実施例に係る外部のデコーティング部であってもよい。
受信機22040は、WMクライアント22050を含むことができる。WMクライアント22050は、受信機22040の外部に位置してもよい。ここで、受信機は、ウォーターマーキングができる受信機である。受信機22040の構造については後述する。
WMクライアント22050は、該当用途のAPIを用いてACRサーバー(図示せず)から活性化トリガーを受け、これらをメイン受信機コードに送ることができる。一般に、WMクライアント22050は、受信機内に構成されるが、他の構成も可能である。WMクライアント22050は、非圧縮されたオーディオ/ビデオコンテンツから、挿入されたウォーターマークを抽出することができる。ウォーターマークはURLなどの情報であってもよい。
TPTサーバー22060は、TPTのようなアプリケーションをダウンロードできるサーバーであってもよい。受信機22040は、抽出されたウォーターマークをACRサーバーに伝送する。ウォーターマークがデータベース(図示せず)に保存されたウォーターマークとマッチングされると、受信機22040は、一トリガー又は複数トリガーを応答として受信することができる。受信された一トリガー又は複数トリガーが、上述した新しいlocator_partを有したり、又は新しいバージョンのTPT又はアプリケーションパラメータテーブルが発見されると、受信機22040はTPTサーバー22060に新しいTPT又はアプリケーションパラメータテーブルをダウンロードすることを要求することができる。
コンテンツサーバー22070は、双方向サービスを提供するために必要なアプリケーション及びTDOを提供することができる。新しいアプリケーション又はTDOが必要な場合、新しいアプリケーションは、TPT又はアプリケーションパラメータテーブルにあるURLを用いてダウンロードすることができる。
ウォーターマーキング(WM)技法において、放送局/ウォーターマーク挿入部は、放送されるオーディオ/ビデオフレームにウォーターマークを入れることができる。これらのウォーターマークは、視聴者に感知されないか、又はできるだけ邪魔とならないような量の情報を受信機に送信するように設計することができる。このようなウォーターマークは、受信機が必要とする情報を直接提供してもよく、又は受信機が必要とする情報を得るために、遠く離れたサーバーにインターネット接続を通して送ることができるコード値のみを提供してもよい。
図23に、FP技法のアーキテクチャの一実施例が示されている。
FP技法のアーキテクチャにおいて、アーキテクチャは、放送局23010、MVPD 23020、STB 23030、受信機23040、FPクライアント23050、TPTサーバー23060、コンテンツサーバー23070、シグネチャー(signature)抽出機23080及びFPサーバー23090で構成することができる。
放送局23010は、オーディオ/ビデオストリーム及びオーディオ/ビデオストリームと関連した双方向サービスを出力するソースであってもよい。放送局23010の一例としてTV放送局が挙げられる。放送局23010は、放送コンテンツ生産者や配給者であってもよい。放送局23010は、放送ストリーム、オーディオ/ビデオコンテンツ、双方向データ、放送スケジュール、又はAMTを伝達することもできる。
MVPD 23020は、多重チャネルビデオプログラム流通業者(Multiprogram Video Program Distributor)の略語である。MVPD 23020は、ケーブル事業者、衛星事業者又はIPTV事業者であってもよい。MVPD 23020は、たびたびオーディオ及びビデオトラック以外の全てのプログラムエレメントを除くストリームを顧客の宅内のセットトップボックス(STB)に送る。
STB 23030は一般にオーディオ及びビデオをデコーティング(圧縮解除)し、これらを視聴者に視聴されるTV受像機に送る。STBは、非圧縮されたオーディオ/ビデオコンテンツを受信機23040に送ることができる。STB 23030は、本発明の一実施例に係る外部のデコーティング部であってもよい。
受信機23040は、FPクライアント23050を含むことができる。FPクライアント23050は、受信機22040の外部に位置してもよい。ここで、受信機23040は、フィンガープリンティングができる受信機である。受信機23040の構造については後述する。
FPクライアント23050は、当該用途のAPIを用いて、FPサーバー23090から活性化トリガーを受けてそれらをメイン受信機コードに送ることができる。一般に、FPクライアント23050は受信機内に構成されるが、他の構成も可能である。FPクライアント23050は、非圧縮されたオーディオ/ビデオコンテンツから、フィンガープリントを抽出することができる。フィンガープリントについては後述する。
TPTサーバー23060は、TPTのようなアプリケーションをダウンロードできるサーバーであってもよい。受信機23040は、抽出されたフィンガープリントをFPサーバー23090に伝送する。フィンガープリントがシグネチャー抽出機23080のシグネチャーとマッチングされると、受信機23040は、一トリガー又は複数トリガーを応答として受信することができる。受信された一トリガー又は複数トリガーが上述の新しいlocator_partを有したり、又は新しいバージョンのTPT又はアプリケーションパラメータテーブルが発見されると、受信機23040はTPTサーバー23060に新しいTPT又はアプリケーションパラメータテーブルをダウンロードすることを要求することができる。
コンテンツサーバー23070は、双方向サービスを提供するために必要なアプリケーション及びTDOを提供することができる。新しいアプリケーション又はTDOが必要な場合、新しいアプリケーションは、TPT又はアプリケーションパラメータテーブルにあるURLを用いてダウンロードすることができる。
シグネチャー抽出機23080は、放送局23010からメタデータを受信することができる。シグネチャー抽出機23080は、受信されたメタデータからフレームのシグネチャーを抽出することができる。FPサーバー23090に伝送されたフィンガープリントがシグネチャー抽出機23080のシグネチャーとマッチングされると、シグネチャー抽出機23080は、シグネチャーと関連したメタデータをFPサーバー23090に伝達することができる。
FPサーバー23090は、シグネチャー抽出機23080とシグネチャーマッチング動作を行うことができる。FPサーバー23090は、シグネチャーを受信機23040から受信されたフィンガープリントとマッチングさせることができる。シグネチャーがフィンガープリントとマッチングされると、FPサーバー23090は、シグネチャー抽出機23080からシグネチャーと関連したメタデータを受信することができる。FPサーバー23090はメタデータを受信機23040に伝送することができる。
フィンガープリンティング(FP)技法において、FPクライアント23050は、オーディオ又はビデオフレームからフィンガープリント(シグネチャーと呼ぶこともできる。)を抽出し、多重の放送局からの放送フレームに対するフィンガープリントデータベースに対してこのフィンガープリントを検査し、受信機23040が必要とする情報を探すことができる。このような検査は、遠く離れたサーバーに対するシグネチャーによってなされてもよく、所望の情報を有する記録を受けることができ、一部の場合は、受信機23040にダウンロードされたシグネチャーのデータベースに対して検査することによって検査がなされてもよい。ここで、遠く離れたサーバーは、FPサーバー23090であってもよい。
ウォーターマーキングとフィンガープリンティングは互いに区別される技術であるが、必ずしも互いに排他的なものではない。これらの両技術の組合せを用いることも考えることができる。自動コンテンツ認知(automatic content recognition;ACR)は、これらの両技術のいずれか一方を別途に指したり、又はこれらの両技術の組合せを指すために用いることができる。
受信機が放送ストリームからの非圧縮されたオーディオ及びビデオにのみ接近できる環境を“ACR環境”と呼ぶ。
WMの場合もFPの場合も、受信機は、トリガーを含む双方向サービスコンテンツを得るための出発点としてURLを用いることができる。
WM、FPの両方の場合とも、インターネットを介して伝達されたトリガーの活性化タイムスタンプなどのように、当該チャネルに対して時間臨界的(time critical)イベントの放送側クロック(broadcast side clock)に対するタイムスタンプの形態であってもよい。
放送局は、一般にアンテナからTV信号を受ける受信機のために放送ストリームでの双方向サービスの直接伝達を支援でき、非圧縮されたオーディオ及びビデオを受ける受信機のために、前述した通り、インターネットを通した双方向サービスの伝達を支援するものの、インターネット接続を有することができると仮定する。しかし、放送局は、この2つの伝達メカニズムのいずれか一方のみ支援できる。
ウォーターマークがコード値のみを提供する場合、ウォーターマーキング技法のための代表的なアーキテクチャは、図22及び図23の2つのアーキテクチャの組合せのように見える。図22のようにウォーターマーク挿入部が存在するようになるが、この挿入部は、受信機が必要とする情報ではなくコードを挿入する。また、図23のFPサーバーと同じ役割を担うWMサーバーが存在する。受信機は、このサーバーにシグネチャーではなくコードを送り、これら受信機が必要とする情報を受ける。
双方向サービス接近について説明する。
双方向サービス接近についての説明は、直接実行モデル、ACRサーバーに独立的な活性化を有するTDOモデル、ACRサーバーから受信された活性化を有するTDOモデルについての説明を含む。モデルを示してはいないが、モデルは、説明に限定されず、設計者の意図によって変更されてもよい。
放送局選択とACRシステムの特性によってACR環境にある受信機が双方向サービスに接近できる方法には、様々なものがある。双方向サービスモデルは、直接実行モデル又はTDOモデルであり、TDOモデルの場合、活性化とトリガーは、ACRサーバーに独立して又はACRサーバーによって伝達することができる。
直接実行モデルについて説明する。
直接実行モデルを有する双方向サービスを含む仮想チャネルのためのACR過程は、このチャネルを見ている受信機に、media_time(“m=”)項とcontent_id(“c=”)項を含む時間ベーストリガーに相応するものを提供することができる。これらのトリガーは、直接実行モデルを有する双方向サービスのためのトリガーと確認できる。
まず、受信機が新しいlocator_partを有するこのようなトリガーを受信すると、そのブラウザーに、トリガーのlocator_partが指す宣言的客体(DO)をローディングすると考えることができる。一般に、DOは、あらかじめ設置されていたり、あらかじめダウンロードされてキャッシュに格納されたりする。そうでなければ、受信機がHTTP GET要求を用いてDOをダウンロードすると考えることもできる。
その後、DOは、適宜のバックエンドサーバーと連絡して、バックエンドサーバーが指示する双方向サービスを提供することができる。
受信機は、ACRサーバーから新しいlocator_partを有する及び/又はTDOモデルを有する双方向サービスのためのトリガーとして確認されるトリガーを得るまで(これらのいずれか一つの場合は、一般的にチャネルの変更を指示する)取得された初期トリガーと続くトリガーをDOが利用できるようにするものと考えることができる。
以下、ACRサーバーに独立した活性化を有するTDOモデルについて説明する。
TDOモデルを有する双方向サービスを含むことができ、ACRサーバーと独立してイベント活性化を提供する仮想チャネルのためのACR過程は、media_time(“m=”)項を含み得る時間ベーストリガーに相応するものを、このチャネルを見ている受信機に提供することができる。これらのトリガーは、TDOモデルを有する双方向サービスのためのトリガーと確認できる。
まず、受信機が新しいlocator_partを有するこのようなトリガーを受信すると、当該トリガーのlocator_partが指し得るTPTサーバーで現在のTDOパラメータテーブル(TPT)を検索し、このトリガー及び続くトリガー内のメディア時間を用いて、ACR過程によって識別されうるオーディオ又はビデオフレームに対してイベント活性化のための基準時間ベースを設定すると考えることができる。
AMT(活性化メッセージテーブル)がTPTと併せて伝達される場合、受信機は、トリガー内のメディア時間によって設定された時間ベースを基準に正確な時間にイベントを活性化させるためにこのテーブル内のそれぞれの活性化エレメントを使用すると考えることができる。(これらのイベントは、TDODMLローディング及び実行、TDOが同期化される特定動作を行うようにすること、TDOを中止させること、などを含むことができる。)。
TPTにLiveTriggerエレメントが含まれた場合、受信機はLiveTriggerエレメントでシグナリングされたポーリング方法を用いてLiveTriggerエレメント内のURLによって識別されたライブトリガーサーバーから活性化トリガーを検索し、この活性化トリガーを用いて、このトリガー内のメディア時間項によって設定された時間ベースを基準に、正確な時間にイベントを活性化させることができる。
AMTとライブトリガーサーバーの両方とも同一のサービスのために用いることができるが、前者は静的活性化を提供し、後者は動的活性化を提供する。これと違い、セグメントの全ての活性化が静的活性化である場合は、AMTのみを用いてもよく、ライブトリガーサーバーのみを用いて静的活性化及び動的活性化の両方を伝達してもよい。
ACRサーバーから受信された活性化を有するTDOモデルについて説明する。
TDO双方向サービスモデルのための活性化トリガーが、ACR環境において、別途のトリガーサーバー無しでどのように伝達されるかについて記述する。
フィンガープリンティングACRシステムは、ACRサーバーを含むことができる。受信機は、ACRサーバーにフレームシグネチャーを送ることができ、ACRサーバーは、当該シグネチャーが示すフレームを識別して、再び受信機で必要とする情報を送ることができる。ウォーターマークが、受信機で必要とする情報を得るためにACRサーバーに伝達され得るコードのみで構成された場合、ウォーターマーキングACRシステムはACRサーバーを含むことができる。ウォーターマーク自体が受信機で必要とする情報を含む場合、ウォーターマーキングACRシステムはACRサーバーを含まなくてもよい。ACRサーバーを含むACRシステムでは、サーバーと受信機間の通信に互いに異なる2のモデル、すなわち、要求/応答モデルとイベント主導型モデルを用いることができる。
放送局でTDO双方向モデル(TDO interaction model)を支援していると仮定する。
要求/応答モデルを用いるACRサーバー、イベント主導型モデルを用いるACRサーバー、情報を直接挿入するウォーターマーキングACRシステムのような3つの場合を想定することができる。
ACRサーバーがある場合、ACR方式は、フィンガープリンティングであってもよく、この場合、受信機は一種のオーディオ又はビデオフレームのシグネチャー(又は、フィンガープリント)を算出し、識別のためにそれらをACRサーバーに提出する。又は、ACR方式がウォーターマーキングであってもよく、この場合、受信機はオーディオ又はビデオフレームからウォーターマーク形態のコードを抽出し、これらのコードを識別のためにACRサーバーに提出する。
便宜のためにフィンガープリンティングシグネチャーの用語を説明する。ただし、システムはウォーターマーキングコードの場合と同一の方式で動作し、本発明はフィンガープリンティングに限定されない。
図24は要求/応答ACR場合の静的活性化の一実施例を示す図である。
ACRサーバーが要求/応答モデルを使用する場合について説明する。
要求/応答ACRモデルで、受信機は周期的に(例えば、5秒ごとに(これは、例示に過ぎず、設計者によって変更されてもよい))コンテンツのシグネチャーを生成し、シグネチャーを含む要求をACRサーバーに送ると考えることができる。ACRサーバーは、受信機から要求を受けると応答を送ることができる。要求/応答インスタンス間には通信セッションが開放状態に維持されない。このモデルでは、ACRサーバーが受信機にメッセージを開始することが不可能であってもよい。
この要求/応答モデルを用い、受信機に活性化トリガーを伝達するACRサーバーの場合、ACRサーバーからの各応答は、ヌル(Null)、時間ベーストリガー又は活性化トリガーのうち一つであってもよい。
ヌル応答は、シグネチャーが認識されないことを示したり、又は、(ACRインジェストモジュール(ACR Ingest Module)がフレームに対するシグネチャーを双方向サービスのないプログラムセグメントに含める場合に)シグネチャーは関連している双方向サービスのないセグメントに属するフレームを意味することを示すことができる。ACRインジェストモジュールについては後述する。
時間ベーストリガー応答は、クライアントの次の要求がある前にイベント活性化が発生するようにスケジューリングされていないことを示すことができる。クライアントは、時間ベーストリガーを用いてメディア時間クロック(media−time clock)を維持すると考えることができる。
活性化トリガー応答は、活性化がまもなく発生する予定であることを示すことができ、活性化の時間は、トリガー内の“t=”項によって示される。
受信機は、新しいlocator_partを有するトリガーを受ける度に、以前のTPTと共に伝達されたURLListを用いて新しいTPTが検索されていないと、それを直ちにダウンロードすると考えることができる。
受信機は、活性化トリガーを受ける度に、メディア時間クロックに対して当該トリガー内の“t=”項によって示された時間に、当該イベントを活性化させると考えることができる。
図24は、静的活性化に対して(ACRシステムが予定よりも十分に早く動的活性化について知っている場合は動的活性化に対して)、この方式がどのように作用するかを示している。
図24で、受信機は、ACRサーバーでメディア時間MT1、MT2及びMT3を有すると判断したフレームに対するシグネチャーを伝達することができる。メディア時間MT1を有するフレームの場合、受信機は、時間ベーストリガーを含む応答を受ける。メディア時間MT2を有するフレームの場合、静的活性化がメディア時間Mtaに予定され、受信機は“t=MTa”項を有する活性化トリガーを含む応答を受ける。メディア時間MT3を有するフレームの場合、受信機は、時間ベーストリガーを含む応答を受ける。
受信機が同一のイベント活性化に対して一つ以上の活性化トリガーを受信する場合が発生しうる。しかし、これらのそれぞれに対するメディア時間は同一であるため、受信機はそれらの活性化トリガーが重複していると把握し、これらのうち一つのみを適用することができる。
図25は、要求/応答ACRケースにおける静的活性化の一実施例を示す図である。
ACRサーバーが要求/応答モデルを使用する場合について説明する。
図25で、受信機は、ローカルクロック(local clock)時間LC1、LC2、LC3で見られたフレームに対するシグネチャーを伝達することができる。ローカルクロック時間LC1に見られたフレームに対するmedia_timeはACRサーバーによってMT1であると判断でき、受信機は、media_time又はevent_timeのないトリガーを含む応答を受信する。ローカルクロック時間LC2に見られたフレームに対するmedia_timeはACRサーバーによってMT2であると判断でき、ACRサーバーは、メディア時間Mtaに静的活性化が予定されていることを知っているため、ACRサーバーは、この活性化のための活性化時間MtaがMT2以降の<オフセット>時間であることを意味する“d=<offset>”項を有する活性化トリガーを含む応答を伝達する。すると、受信機は<オフセット>を時間LC2に追加し、当該イベントを活性化させるべきローカル時間であるLcaを得る。
図26は、要求/応答ACRケースにおける動的活性化の一実施例を示す図である。
以下、要求/応答ACR場合において動的活性化が起きる場合について説明する。
あらかじめ受信機にトリガーを送るには手遅れになるまでずっと、ACRシステムでイベント活性化について知っていない状況での動的活性化の場合には、ACRサーバーが次の要求があるまで待ってから活性化トリガーを送らなければならない。 このような場合を図26に示す。そのため、一つの要求区間だけ動的活性化が遅延されうる。
図26で、受信機は、ACRサーバーでメディア時間MT1、MT2及びMT3を有すると判断したフレームに対するシグネチャーを伝達することができる。メディア時間MT1及びMT2を有するフレームの場合、受信機は、時間ベーストリガーを含む応答を受ける。活性化時間Mtaを有する動的活性化がメディア時間MTaで又は直前に登場する場合、ACRサーバーは、メディア時間MT3を有するフレームに対して発生する受信機からの次の要求があるまで、受信機にそれを通知することができない。このとき、ACRサーバー応答は、活性化時間MTa(やや去の時間)を有する活性化トリガーを含む。このような状況で、受信機は、その応答が到達すると直ちに当該活性化トリガーを適用すると考えることができる。
ここで、受信機は、同一のイベント活性化に対して一つ以上の活性化トリガーを受信することが可能である。しかし、それらのそれぞれのメディア時間は同一であるため、受信機はそれらが重複したと把握し、それらのうち一つのみを適用できる。
図27は、要求/応答ACRケースにおける動的活性化の一実施例を示す図である。
要求/応答ACRケースにおいて動的活性化が起きる場合について説明する。
図27で、受信機は、ローカルクロック時間LC1、LC2、LC3で見られたフレームに対するシグネチャーを伝達することができる。ローカルクロック時間LC1に見られたフレームに対するmedia_timeはACRサーバーによってMT1であると判断でき、受信機はmedia_time又はevent_timeのないトリガーを含む応答を受信する。ローカルクロック時間LC2に見られたフレームに対するmedia_timeはACRサーバーによってMT2であると判断でき、ACRサーバーは、メディア時間Mtaに動的活性化が登場する予定であることを知っておらず、受信機は、media_time又はevent_timeのないトリガーを含む応答を受信する。動的活性化がメディア時間Mtaに登場すると、ACRサーバーは、ローカル時間LC3に発生する受信機からの次の要求があるまで、受信機にそれに対して通知することができない。このとき、ACRサーバー応答は、負の<オフセット>値を有する活性化トリガー又は“今施行”の活性化トリガーを含むことができる。
イベント主導型モデルを使用するACRサーバーについて説明する。
イベント主導型ACRモデルで、受信機はACRサーバーに対する永久的な接続を開始し、周期的に(例えば、5秒ごとに)コンテンツのシグネチャーを生成し、シグネチャーを接続を通して提出すると考えることができる。ACRサーバーは各シグネチャーに反応しない。それは、新しいセグメントが発見されたり、又はイベント活性化が受信機に伝達される必要があるとき、受信機にメッセージを送ることができる。当該モデルで、ACRサーバーはいつでもクライアントに対するメッセージを開始することができる。
該イベント主導型モデルを使用し、活性化を受信機に伝達するACRサーバーに対して、次の規則はACRサーバーからのメッセージを申し込むことができる。
第一に、ACRサーバーは、新しいセグメントに対応する受信機からシグネチャーを受信すると、単に受信機が関連のTPTを取得できるようにするために、直ちに時間ベーストリガーを受信機に送ることができる。
第二に、イベントが活性化される予定である度に、ACRサーバーは活性化トリガーを受信機に送ることができる。可能ならば、受信機が適用すべき時期よりもやや早く活性化トリガーを送ることができる(これは、要求/応答モデルにおける動作と略同様である)。ACRサーバーは、活性化をあまりにも遅く知って活性化トリガーを事前に早く送ることができなくても(これは、動的イベント活性化の場合に発生しうる)、活性化トリガーを可能な限り早く送ることができる。後者の場合に、メッセージ遅延によってクライアントは活性化時期よりもやや遅れてメッセージを受けることができ、この場合、受信機はメッセージを受け次第イベントを活性化すると考えることができる。
受信機は、新しいlocator_partを有するトリガーを受信する度に、以前のTPTと一緒に伝達されるURLListを用いて既に検索していない限り、新しいTPTを直ちにダウンロードすると考えることができる。
情報を直接挿入するウォーターマーキングACRシステムについて説明する。ウォーターマーキングACRシステムを示してはいないが、ウォーターマーキングACRシステムは、次の説明に限定されず、設計者によって変更されてもよい。
受信機が必要とする情報を直接挿入するウォーターマーキングシステムの場合、フレームと関連しているウォーターマークは、このフレームに対して要求/応答ACRサーバーがリターンすることについて、前述したのと同じ規則を、次のように従うことができる。要求/応答ACRサーバーは、ヌル、時間ベーストリガー、活性化トリガーのうち一つをリターンすることができる。
ヌル応答は、シグネチャーが認識されないことを示したり、又は(ACRインジェストモジュールがフレームに対するシグネチャーを双方向サービスのないプログラムセグメントに含める場合)シグネチャーは関連した双方向サービスのないセグメントに属するフレームを意味することを示すことができる。
時間ベーストリガー応答は、クライアントの次の要求がある前にイベント活性化が発生するようにスケジューリングされていないことを示すことができる。クライアントは、時間ベーストリガーを用い、メディア時間クロックを維持すると考えることができる。
活性化トリガー応答は、活性化がまもなく発生する予定であることを示すことができ、活性化の時間はトリガー内の“t=”項によって示される。
ACRサーバーが必要とされないように、受信機が必要とする情報をウォーターマークに直接含めて伝達するウォーターマーキングACRシステムの場合、インジェストモジュールは、各フレームと関連付けるトリガーを決定し、このトリガーをデータベース内の該当フレームと関連付けずに当該フレームのためのウォーターマークに含める要求/応答サーバーモデルについて、前述したのと同じ規則に従うことができる。インジェストモジュールとデータベースについては後述する。
独立型NRTサービスの支援について説明する。これを示してはいないが、本発明は、次の説明に限定されず、設計者によって変更されてもよい。
ACR環境にある受信機が独立型NRTサービスを受けるために、放送局は、NRTサービスへのインターネット接続を支援する必要があり、受信機は、それらのサービスに対するSMTとNRT−ITインスタンスを得る必要がありうる。
インターネットを介してPSIPテーブルとNRTテーブルを得るための質疑(query)プロトコルについて説明する。
放送局は、特定放送ストリームに対してこのプロトコルを支援し、このとき、この放送ストリームに対する放送局のシグナリングサーバーのURLを知っている受信機は、次の段階を行う。
第一に、受信機は、指定された未来時間区間(例:次の時間)に当該放送ストリームのためのテーブルの“基本NRT集合”に対して質疑を発生させることができる。
第二に、上記の段階で各独立型NRT仮想チャネルに対するSMT及びILT、並びに指定された時間区間を含むNRT−IT及びTFTインスタンスを生成する。
受信機が放送ストリームに対するシグナリングサーバーのURLを発見できる一つの方法は、この放送ストリーム内の双方向サービスセグメントのプロバイダが、TPTと併せて伝達されたURLListエレメント内でシグナリングサーバーURLを提供するように選択することができる。
受信機が放送ストリームに対するシグナリングサーバーのURLを発見できるもう一つの方法は、事前設定によるものであってもよい。DTV受信機メーカーが、特定放送領域に到達するACRサーバーをどのように探すかを知るようにDTV受信機をあらかじめ設定するのと同じ方式で、DTV受信機メーカーが、特定放送領域に到達する“NRT発見サーバー”をどのように探すかを知るようにDTV受信機をあらかじめ設定することができる。このようなNRT発見サーバーは、各放送ストリームに対するシグナリングサーバーURLと共に、独立型NRTサービスを含む放送ストリーム目録を受信機に提供することができる。
図28は、ACRサーバー活性化のためのアーキテクチャの一実施例を示す図である。
あるACRシステムはACRサーバーを含み、あるACRシステムは含まない。フィンガープリンティングACRシステムでは、受信機はフレームシグネチャーを算出してACRサーバーに送ることができ、ACRサーバーは、受信機で必要とする情報を送る。したがって、フィンガープリンティングACRシステムは、ACRサーバーを含む。ウォーターマーキングACRシステムでは、ウォーターマークにフレームを固有に識別するコードのみが含まれてもよく、又は受信機が必要とする全体情報が含まれてもよい。ウォーターマークがコードのみを含む場合は、受信機がコードを抽出し、それらをACRサーバーに送ることができ、ACRサーバーは、受信機で必要とする情報を送る。ウォーターマークが全体情報を含む場合は、受信機が自分に必要な情報をウォーターマークから直接抽出でき、ACRサーバーが必要でない。
ACRサーバーを含むACRシステムでは、ACRサーバーと受信機間の通信のために2種類の互いに異なるモデル、すなわち、要求/応答モデルとイベント主導型モデルを共通に使用することができる。
要求/応答ACRサーバーモデルにおいて、受信機は周期的に(例えば、5秒ごとに)コンテンツのシグネチャーを算出したりコンテンツからコードを抽出し、このシグネチャーやコードが含まれた要求をACRサーバーに送ると考えることができる。ACRサーバーは受信機から要求を受信すると、応答をリターンすることができる。要求/応答インスタンス間には通信セッションが開いた状態で維持されない。このモデルでは、ACRサーバーが受信機にメッセージを開始することが実行可能でなくてもよい。
処理しているチャネルの放送局がTDO双方向モデルを支援すると仮定する。
2種類の一般的な類型のイベント活性化、すなわち、セグメントの放送が開始される前に活性化時間が知らされる静的活性化と、セグメントの放送中に活性化時間が動的に決定される動的活性化がありうる。あらかじめ記録されたセグメントでは、全てのイベント活性化が静的であってもよい。ライブショーを放送するセグメントでは、イベント活性化の一部又は全てが動的であってもよい。静的活性化は活性化トリガーの形態で受信機に伝達されてもよいが、一般的に活性化メッセージテーブル(Activation Messages Table、AMT)に記載される。動的活性化は、これらのタイミングがAMTの発生時点に知らされないため、活性化トリガーの形態で伝達されてもよい。
図28は、ACRサーバーを使用するACRシステムを支援するアーキテクチャを示している。これは論理構成図であって、実行アーキテクチャではない。例えば、ACRインジェストモジュールは、放送ソースと同じ位置にあってもよく、別途の位置にあってもよい。
ACRサーバーを使用するACRシステムを支援するアーキテクチャにおいて、アーキテクチャは、放送ソース28010、ACRインジェストモジュール28020、MVPD 28030、STB 28040、受信機28050、ACRクライアント28060、ACR設定サーバー28070、ACRサーバー28080及びデータベース28090で構成することができる。
放送ソース28010は、A/Vストリーム及び関連した双方向サービスが送出される地点であって、例えば、ネットワーク分配地点又はTV放送局であってもよい。
ACRインジェストモジュール28020は、フィンガープリンティングACRシステムの場合、フレームのシグネチャー(フィンガープリント)を算出したり、コードに基づくウォーターマーキングACRシステムの場合、コードからなるウォーターマークをフレームに挿入することができる。このモジュールは、他のメタデータと併せてシグネチャー又はコードに関連している各フレームのmedia_timeをデータベース28090に保存することができる。ACRインジェストモジュール28020は、一つの放送ストリーム、全体放送ストリーム、又は複数の放送ストリーム又はこれらの組合せにおいて単一チャネルを扱うことができる。そのために、ACRインジェストモジュール28020は、双方向サービスを含むプログラムセグメントのためのフレームを処理すると仮定する。しかし、全てのフレームが処理されるが、双方向サービスを有するセグメントの一部でないものは、これらが双方向サービスを有するセグメントの一部でないことを示す指示子がデータベース28090エントリにあるACRシステムも可能である。
MVPD 28030は一般に、ケーブル事業者、衛星事業者又はIPTV事業者である。MVPD 28030は、ウォーターマーキングACRシステムの場合、ACRインジェストモジュール28020によって挿入されたウォーターマークと共に放送ストリームをいずれかの方式で放送ソースから受信することができる。このようなシステムはたびたびオーディオ及びビデオトラック以外の全てのプログラムエレメントを除くストリームを顧客の宅内のSTB 28040に送る。
STB 28040は一般にオーディオ及びビデオをデコーティング(圧縮解除)し、これらを、視聴者に視聴されるTV受像機に送る。双方向サービストリガーを含むDTVクローズドキャプションサービス#6は、TV受像機が利用できないと仮定する。
受信機28050は、ACRクライアント28060を含むことができる。ACRクライアント28060は、受信機28050の外部に位置してもよい。受信機28050の構造については後述する。
受信機28050内のACRクライアント28060は、当該用途のAPIを用いてACRサーバー28080から活性化トリガーを受け、これらをメイン受信機コードに送ることができる。一般に、ACRクライアント28060は受信機28050内に構成されるが、他の構成図可能である。
ACR設定サーバー28070は、ACRクライアント28060が適切なACRサーバー28080の位置を決定する方式を提供することができる。この発見過程は他の方式で得ることもできる。
ACRサーバー28080は、受信機からシグネチャー又はコードを受け、適切な時点に活性化トリガーをリターンすることができる。
データベース28090は、ACRサーバー28080の使用のためにオーディオ又はビデオフレームのいずれか一方(又は、両方)に関する情報が格納される一種のデータ格納所であって、厳密にはデータベースでなくてもよい。
ウォーターマーク内の情報の直接伝達を用いるACRシステムのアーキテクチャは、データベースとACRサーバーを有しなくてもよい。ACRインジェストモジュールは、情報をフレームの識別子及びこれらと関連している情報を含むデータベース記録に挿入する代わりに、ウォーターマークの形態で放送ストリーム内のフレームに直接挿入してもよい。その後、受信機はその情報をACRサーバーから取得せず、放送内のフレームから抽出することができる。
以下、要求/応答ACRサーバーを介した活性化トリガーの伝達について段階別に説明する。
このACRサーバーの挙動を具現する効果的な方法は、以下に説明する過程に従うものであるが、この過程の動作の数は、上記のアーキテクチャダイヤグラムである図28内の数字に対応する。
1)双方向サービスセグメントとAMT又は各セグメントに相当するものに対する放送スケジュールを、セグメントが放送される前にあらかじめACRインジェストモジュールに伝達することができる。放送スケジュールは、セグメントID、関連する双方向サービスを含み得る各セグメントのGPS開始時点及びGPS終了時点を含むことができる。放送スケジュールに最後の瞬間の変化がある場合、ACRインジェストモジュールにそれらの変化が直ちに通知されてもよい。放送スケジュールは、各セグメントに対するTPTのバージョンナンバーも含むことができ、TPTバージョンのスケジュールされていない変更は、実時間でACRインジェストモジュールに通知され、必要時に“version”(“v=”)項をトリガーに挿入することができる。インジェストモジュールは、各セグメントの開始時に特定区間(多数の受信機が新しいTPTを同時に要求する可能性がある時)のように適切な時間に“spread”(“s=”)項をトリガーに挿入するように構成されてもよい。
2)動的活性化が存在する場合、動的活性化のソースからACRインジェストモジュールにリンクが設定されてもよい。
3)放送ストリームはACRインジェストモジュールに送信されてもよい。
4)ACRインジェストモジュールは、フレームからシグネチャーを抽出したり(フィンガープリントACRシステムの場合)、関連している双方向サービスを持つセグメントに含まれた全てのフレームに対してコードをフレームに挿入(ウォーターマークACRシステムの場合)することができる。(ACRインジェストモジュールは、GPSクロックと放送スケジュール内のセグメントの開始時間及び終了時間を用いてフレームがそのようなセグメントにあるかを判断できる。)そのような各フレームに対してACRインジェストモジュールは、トリガーとシグネチャー又は当該フレームと関連しているコードを含み得るデータベースに記録を挿入することができる。トリガーが挿入されることに関する規則は、過程上、このような動作リストの終端に記述される。
5)放送ストリームは、MVPDに続いてもよい。
6)MVPD加入者の位置にあるSTBに放送ストリームを送信できる。(一般に、双方向コンテンツはまず除く。)
7)STBは、A/Vをデコーティングして非圧縮されたA/VをDTV受信機に送ることができる。
8)まず、受信機がONになると、受信機は自身の位置をACR設定サーバーに送ることができる。(ACR設定サーバーのURLは、この受信機内に構成されてもよい。)
9)ACR設定サーバーは、受信機が使用するACRサーバーのURLを送ることができる。
10)受信機内のACRクライアントは、フィンガープリントシグネチャー又はウォーターマークコードを抽出し、それらをACRサーバーに送ることができる。
11)シグネチャー又はコードを受信したACRサーバーは、データベース内でシグネチャー又はコードのマッチングを試みることができる。
12)シグネチャー又はコードがデータベースのいずれのシグネチャー又はコードともマッチングされないと、ACRサーバーは“no match”指示子を受けることができる。シグネチャー又はコードがデータベース内のシグネチャー又はコードとマッチングされると、ACRサーバーは、マッチングされるシグネチャー又はコードを有するフレームに対する記録を受けることができる。後者の場合、データベース内の記録は時間ベーストリガーを含むことができ、及び/又はACRインジェストモジュールによってフレームの記録に何が挿入されたかによって一つ以上の活性化トリガーを含むことができる。
13)ACRサーバーがデータベースから“no match”指示子を受けると、ACRクライアントにヌル応答をリターンすることができる。そうでない場合、ACRサーバーは、得られたたトリガー又はトリガーをACRクライアントにリターンすることができる。
下記の規則を用いて、ACRインジェストモジュールがどの一つ又は複数のトリガーをデータベース内の各フレーム記録に挿入するかを判断できる。
図29は、EndTimeがない場合(a)と場合(b)における活性化トリガーの一実施例を示す図である。
受信機内の個別ACRクライアントによって使われた要求区間の長さ上に、ある上限(upper bound)L1が存在すると仮定できる。(ACRクライアントが実際にこの上限内で動作する限り、この境界を知っているかは重要でない。)L2をフレームが受信機に到達した時点から計算して、一般のACRクライアントがシグネチャーを算出したり、このフレームと関連しているウォーターマークを抽出するためにかかる時間の長さとしよう。メッセージがACRクライアントからACRサーバーに送られてから帰ってくるためにかかる一般的な往復移動時間をL3としよう。M=L1+L2+L3とする。(ややより大きいMの値が用いられもよい。−ややより大きい値の長所は、活性化トリガーに反応する上で若干の余分の時間を得るということである。短所は、受信機が同一のイベント活性化に対して複数の活性化トリガーを受ける可能性がややより高いということである。受信機は、後述するように、これらが重複することを感知し、活性化を1回のみ適用できるため、この短所は大きく問題にならない。)
ACRインジェストモジュールは、次の3つの条件のうち少なくとも一つが成立しないと、時間ベーストリガーのみをフレームと関連している記録に挿入することができる。
(a)活性化エレメントは、フレームのmedia_timeが活性化エレメントのstartTime前の時間長さMから始まって活性化エレメントのendTimeで終わる時間区間にあるようにAMTに存在する。(活性化がendTimeを有しないと、endTimeはstartTimeと同一のものと見なされる。)
(b)トリガーの活性化時間(“t=<event_time>”)直前の時間長さMの時間区間以前に動的活性化トリガーがインジェストモジュールによって受信されており、当該フレームはこの区間内に存在する。
(c)トリガーの活性化時間直前の時間長さMの区間の開始よりも遅れて動的活性化トリガーがインジェストモジュールによって受信されており、フレームのmedia_timeはトリガーの受信の直後の時間長さL1の区間に存在する。
これらの条件(a)、(b)及び(c)のいずれか一つでも成立すると、活性化トリガーは、活性化されるイベントを識別する“e=”項とAMT内の活性化エレメントのstartTimeを指示したり(条件(a)の場合)、動的トリガーのevent_timeを指示する(条件(b))“t=”項と共に記録に含まれうる。トリガーはバージョン(“v=”)項も含むことができる。
もちろん、(a)の場合、startTimeからendTimeまでの区間を通じて続けて活性化トリガーをフレームと関連付ける理由は、この区間を通じてチャネルに参加する受信機をある程度受容するためである。
この接近法は、ACRサーバー側に追加的な知能を要求しないという点に留意されたい。このサーバーは、単純にデータベースで発見する情報をACRクライアントにリターンする。全ての知能はACRインジェストモジュールに存在できる。しかも、ACRインジェストモジュールが行うべき演算が非常に簡単でありうる。
この方式を用いると、受信機で同一のイベント活性化に対して一つ以上の活性化トリガー(互いに異なるフレームと関連しているトリガー)を受信することが可能である。しかし、受信機は、“t=”値から、それらのトリガーがいずれも同一の活性化時間を有することがわかるため、受信機はそれらが重複すると判断し、イベントを1回のみ活性化させることができる。
上記の場合のうち二つの場合に、活性化トリガー内の“t=”項は、関連しているフレームのmedia_timeより早いevent_timeを有することができる。(a)の状況で、活性化エレメントのendTimeがstartTimeよりも非常に遅いと、受信機は一般的にstartTimeとendTimeの間の区間を通じて複数の活性化トリガーを受けることができ、これらはいずれも活性化時間としてstartTimeを有することができる。(c)の状況では、活性化のための活性化トリガーがあまりにも遅くフレーム記録に挿入され、受信機が受ける活性化トリガーが要求に対する応答として、活性化時間以降のmedia_timeを有するフレームに対するシグネチャーと共にくることがある。受信機が、関連しているフレームのmedia_timeよりも早いevent_timeを有する活性化トリガーを受けると、このトリガーが既に確認して当該イベントの活性化のために使用した活性化トリガーと同じものと認識しない場合、当該イベントを直ちに活性化すると考えることができる。
フレームのmedia_timeがevent_activation timeよりも遅い場合に“今施行”トリガーではなく過去のevent_time値を用いる目的は、受信機がこのような“after the fact”活性化トリガーを一つ以上受けることができるためである。“t=”値は、受信機でこれらのトリガーがいずれも同一の活性化時間を有すると判断し、当該イベントを1回のみ活性化させ得るようにする。
図29は、AMT内の活性化エレメントにendTime属性がない状況(a)と状況(b)を説明する。
図29は、AMT内の活性化エレメントがendTimeを有しないとき、上記の動作(4)での状況(a)の一例を示している。これは、ACRインジェストモジュールに活性化時間よりも少なくてもM時間単位以前に動的活性化トリガーが送られる上記の段階(4)での状況(b)の例であってもよい。
図29は、タイムライン(timeline)上にイベント活性化時間とこれよりも先行する長さL1、L2及びL3の区間を含む長さMの区間を示している。タイムラインの下の垂直矢印は、個別フレームの時間を表す。長さMの区間の開始よりも先行したり、イベント活性化時間後にくる各フレームは、データベースで時間ベーストリガーと関連している。長さMの区間内の各フレームは、データベースにおいて同図の下における2つの例(f1、f2)のような活性化トリガーと関連している。各フレームに対する“t=”項は、media_timeに対するイベント活性化時間を示すことができる。(丸囲みのf1、f2で表示されている。)
丸囲みの4つの垂直矢印は、一般の受信機が要求を送る時の例示である。この例で、受信機は、同一のイベント活性化に対して2つの活性化トリガーを受けるようになるが、これらのトリガーは同一のイベント活性化時間を有するため、受信機はこれらを同一のものと認識し、最初のトリガーのみを適用する。受信機の要求間の間隔がL1未満であるため、受信機は図示のL1区間でフレームに対するシグネチャーと併せて少なくとも一つの要求をするように保障される。これによって活性化時間以前にシグネチャーを算出してACRサーバーに要求を送り、その応答として活性化トリガーを受ける時間を有することとなる。この例で、受信機が受ける一番目の活性化トリガーはあらかじめ伝達されるが、受信機が受ける二番目の活性化トリガーは、かろうじて間に合って到達する(このトリガーは重複トリガーである)。
図30は、EndTimeがない場合(a)と場合(b)における活性化トリガーの一実施例を示す図である。
以下、EndTimeがない場合(a)と場合(b)における活性化トリガーを説明する。これは、上記の図29に関する説明に似ている。
図30は、AMT内の活性化エレメントがendTimeを有しない場合に、上の動作(4)で状況(a)の例を示している。これは、ACRインジェストモジュールに活性化時間よりも少なくてもM時間単位以前に動的活性化トリガーが送られる上の段階(4)で状況(b)の例である。
図30は、タイムライン(timeline)上にイベント活性化時間とこれよりも先行する長さL1、L2及びL3の区間を含む長さMの区間を示している。タイムラインの下の矢印は、個別フレームの時間を表す。長さMの区間の開始よりも先行したりイベント活性化時間後にくる各フレームは、データベースで<media_time>又は<event_time>項のないトリガーと関連している。長さMの区間内の各フレームは、データベースで同図の下における2つの例と同一の活性化トリガーと関連している。各フレームに対する”d=”項は、このフレームとイベント活性化時間との時間の長さを示すことができる。(丸囲みのf1、f2で表示されている)。
丸囲みの4つの垂直矢印は、一般の受信機が要求を送る時の例示であってもよい。この例で、受信機は、同一のイベント活性化に対して2つの活性化トリガーを受けるが、<d1>値をフレームf1に対する受信機のローカル時間に加えたり、<d2>値をフレームf2に対する受信機のローカル時間に加えて算出した活性化時間は、同一の結果を有するため、受信機はそれらを重複したものと認識し、最初のトリガーのみを適用する。受信機要求間の間隔がL1未満であるため、受信機は図示のL1区間でフレームに対するシグネチャーと併せて少なくとも一つの要求をするように保障される。これによって活性化時間以前にシグネチャーを算出してACRサーバーに要求を送り、その応答として活性化トリガーを受ける時間を有することとなる。この例で、受信機で受信された二番目の活性化トリガーは、活性化時間以降に到達する。
図31は、EndTimeがある場合(a)における活性化トリガーの一実施例を示す図である。
図31は、AMT内の活性化エレメントがstartTimeの他、endTimeも持つ場合に、上の動作(4)で状況(a)の例を示している。
同図は、タイムライン上にイベント活性化のstartTimeとendTime、及びstartTimeよりも先行する長さMの区間を示している。タイムラインの下の矢印は、個別フレームの時間を表す。長さMの区間の開始よりも先行したりイベント活性化のendTime後にくる各フレームは、データベースで時間ベーストリガーと関連している。長さMの区間内又はイベント活性化のstartTimeとendTime間の各フレームは、データベースで同図の下における3つの例で示す形態で関連している活性化トリガーを有する。各フレームに対する“t=”項は、media_timeに対するイベント活性化時間を示すことができる。(丸囲みのf1、f2、f3で表示されている。)
丸囲みの3つの垂直矢印は、一般の受信機が要求を送る時の例示であってもよい。この場合、受信機は同一のイベント活性化に対して3つの活性化トリガーを受けるが、活性化時間が同一であるため、受信機はそれらを同一のものと認識し、最初のトリガーのみを適用する。
もちろん、同図における最初の2つの活性化トリガーは、startTime以降にチャネルに参加して最初の要求と併せてフレームf3のシグネチャーを送る受信機にとっては認知できない。
図32は、EndTimeがある場合(a)における活性化トリガーの一実施例を示す図である。
以下、EndTimeがある場合(a)における活性化トリガーを説明する。
図32は、AMT内の活性化エレメントがstartTimeの他、endTimeも有する場合に上の動作(4)での状況(a)の例を示している。
同図は、タイムライン上にイベント活性化のstartTimeとendTime、及びstartTimeよりも先行する長さMの区間を示している。タイムラインの下の矢印は、個別フレームの時間を表す。長さMの区間の開始よりも先行したりイベント活性化時間後にくる各フレームは、データベースで<media_time>又は<event_time>項のないトリガーと関連している。長さMの区間内の各フレームは、データベースで同図の下における2例で示す形態の活性化トリガーを有する。各フレームに対する“d=”項は、このフレームとイベント活性化時間との間の時間長を示すことができる。(丸囲みの垂直矢印で示されている)。
丸囲みの垂直矢印は、一般の受信機が要求を送る時の例示であってもよい。この場合、受信機は同一のイベント活性化に対して3つの活性化トリガーを受けるが、<d1>値をフレームf1に対する受信機のローカル時間に加えたり、<d2>値をフレームf2に対する受信機のローカル時間に加えたり、(負の)<d3>値をフレームf3に対する受信機のローカル時間に加えたりして算出した活性化時間は、同一の結果を有するため、受信機はそれらを重複したものと認識し、最初のトリガーのみを適用する。
もちろん、図示の最初における2つの活性化トリガーは、startTime以降にチャネルに参加して最初の要求と併せてフレームf3のシグネチャーを送る受信機にとっては認知できない。
図33は、場合(c)に対する活性化トリガーの一実施例を示す図である。
図33は、活性化時間以前にM時間単位よりも遅くACRインジェストモジュールに動的活性化トリガーが送られる上記の動作(4)での状況(c)を示している。
図33は、タイムライン上に、動的イベント活性化時間と、ACRインジェストモジュールでイベントの活性化を知るようになるイベント活性化時間の直前の時間を示す図で、ACRインジェストモジュールでイベントの活性化を知る時間後に長さL1の区間が続く。タイムラインの下における垂直矢印は、個別フレームの時間を表す。長さL1の区間の開始よりも先行したり、長さL1の区間の終わりに続く各フレームは、データベースでこのフレームと関連している時間ベーストリガーを有する。長さL1の区間内の各フレームは、データベースで同図の下における例のような活性化トリガーを有する。各フレームに対する“t=”項は、メディア時間ラインに対するイベント活性化時間を示す。(丸囲みの垂直矢印で表示されている。)丸囲みの垂直矢印は、一般の受信機が要求を送る時の例示であってもよい。この場合、受信機はイベント活性化に対して一つの活性化トリガーを有する。活性化トリガーの活性化時間は、このトリガーを受信した時間前であるから、受信機はトリガーを受信すると直ちに適用する。
図34は、場合(c)に対する活性化トリガーの一実施例を示す図である。
以下、場合(c)に対する活性化トリガーを説明する。これは、上記の図33に関する説明に似ている。
図34は、活性化時間以前にM時間単位よりも遅くACRインジェストモジュールに動的活性化トリガーが送られる上記の動作(4)での状況(c)を示している。
図34は、タイムライン上に、動的イベント活性化時間と、ACRインジェストモジュールでイベントの活性化を知るようになるイベント活性化時間の直前の時間を示す図であり、ACRインジェストモジュールでイベントの活性化を知る時間後に長さMの区間が続く。タイムラインの下における矢印は、個別フレームの時間を表す。長さMの区間の開始よりも先行したり、長さMの区間の終わりに続く各フレームは、データベースで<media_time>又は<event_time>項のないトリガーを有する。長さMの区間内の各フレームは、データベースで同図の下における2つの例のような活性化トリガーを有する。各フレームに対する“d=”項は、このフレームとイベント活性化時間との間の時間長を示すことができる。(丸囲みの垂直矢印で表示されている。)丸囲みの垂直矢印は、一般の受信機が要求を送る時の例示であってもよい。この場合、受信機は、同一のイベント活性化に対して2つの活性化トリガーを受けるが、(負の)<d1>値をフレームf1に対する受信機のローカル時間に加えたり、(負の)<d2>値をフレームf2に対する受信機のローカル時間に加えたりして算出した活性化時間はいずれも同一の結果を有するため、受信機はそれらを重複したものと認識し、受信した最初のトリガーのみを適用する。最初のトリガーの活性化時間は、それを受信した時間以前であるから、受信機はこのトリガーを受信すると直ちに適用する。
図35は、最後に伝達される動的活性化トリガーの一実施例を示す図である。
イベント主導型ACRモデルで、受信機は、ACRサーバーに対する持続的な接続を開始し、一定の間隔をおいて(例えば、5秒ごとに)フレームと関連したシグネチャーを生成し、シグネチャーを接続を通して提出すると考えることができる。ACRサーバーは各シグネチャーに反応しない。それは、新しいセグメントが発見されたり、又はイベント活性化が受信機に伝達される必要があるとき、受信機にメッセージを送ることができる。当該モデルで、ACRサーバーはいつでも持続的な接続を通してクライアントに対するメッセージを開始することができる。
また、受信機からの最も最近の提出に対応するセグメントID(トリガーの<locator_part>)及び受信機に送られる最近活性化トリガーのような各受信機に関する一定量の情報を維持することはサーバーにとって簡単である。
当該イベント主導型モデルを使用し、活性化を受信機に伝達するACRサーバーに対して、次の規則はACRサーバーからのメッセージを申し込むことができる。
第一に、ACRサーバーは、新しいセグメントでのフレームに対応する受信機からシグネチャーを受信すると、受信機が関連のTPTを取得できるようにするために、直ちに時間ベーストリガーと共にメッセージを受信機に送ることができる。
第二に、ACRサーバーは(受信機が見た最も最近のバージョンとは異なる)TPTに対する新しいバージョンナンバーを有するセグメントの一部でのフレームに対応する受信機からシグネチャーを受信すると、受信機が関連のTPTの新しいバージョンを取得できるようにするために、直ちに”v=”項を有する時間ベーストリガーと共にメッセージを受信機に送ることができる。
第三に、イベントが活性化される予定である場合、ACRサーバーは活性化トリガーを受信機に送ることができる。可能ならば、メディア時間ラインと関連した活性化時間を示すために活性化トリガーでの”t=”項と共に、受信機が適用すべき時期よりもやや早く活性化トリガーを送ることができる(これは、要求/応答モデルでの動作と略同様である)。ACRサーバーは、活性化をあまりにも遅く知って活性化トリガーを平素より遥かに早く送ることはできなくても、活性化を知るとできるだけ早く活性化トリガーを送ることができる。(後者の場合に、受信機は、活性化時期後に活性化トリガーを受けることができ、この場合、受信機は活性化トリガーを受け次第イベントを活性化すると考えることができる。)
図28に示した要求/応答ケースに対するアーキテクチャも、一つの差異点以外は、当該イベント主導型ケースに適している。その差異点は、イベント主導型ケースにおいて新しいアクション(2a)がありうるということである。動的活性化トリガーが存在すると、ACRインジェストモジュールが選択された動的活性化トリガーをACRサーバーに送ることができるように、ACRインジェストモジュールとACRインジェストモジュールによって実装されたデータベースを使用する全てのACRサーバーとの間に接続が設定されてもよい。
イベント主導型ケースに対する番号付きアクションは、要求/応答ケースと類似可能である。新しいアクション(2a)の他に、アクション(4)がすこし異なり、アクション(13)がすこし異なり、新しいアクション(14)が追加される。
アクション(4)で、ACRインジェストモジュールはフレームからシグネチャーを抽出したり(フィンガープリントACRシステムの場合)、又は関連した双方向サービスを有するセグメントに含まれた全てのフレームに対してコードをフレームに挿入(ウォーターマークACRシステムの場合)することができる。(ACRインジェストモジュールは、GPSクロックと放送スケジュール内セグメントの開始時間及び終了時間を用いて、フレームがそのようなセグメントにあるか否かを判断できる。)そのような各フレームに対してACRインジェストモジュールは、トリガーとシグネチャー又は当該フレームと関連したコードを含み得るデータベースに記録を挿入することができる。次の2つの条件の少なくとも一つを満たさないと、ACRインジェストモジュールによって記録に含まれたトリガーは、時間ベーストリガーであってもよい。
(a)活性化エレメントは、フレームのmedia_timeが活性化エレメントのstartTime前の時間長Mから始まって活性化エレメントのendTimeで終わる時間区間にあるようにAMTに存在する。(活性化がendTimeを有しないと、endTimeはstartTimeと同一であると見なす。)(要求/応答ACRモデルに対して条件(a)と同一)
(b)トリガーの活性化時間(”t=<event_time>”)直前の時間長Mの時間区間以前に動的活性化トリガーがインジェストモジュールによって受信されており、当該フレームはこの区間内に存在する。(要求/応答ACRモデルに対して条件(b)と同一)
これらの条件(a)及び(b)のうち一つでも成立すると、活性化トリガーは、活性化されるイベントを識別する”e=”項とAMT内活性化エレメントのstartTimeを示したり(条件(a)が場合)、動的トリガーのevent_timeを示す(条件(b))”t=”項と共に記録に含まれうる。
動的活性化トリガーがトリガーの活性化時間直前の時間長Mの区間でインジェストモジュールによって受信されると(このとき、Mは要求/応答サーバーにおけると同じ意味を有する)、インジェストモジュールは、動的活性化トリガーと関連してデータベースに如何なるものも置かず、インジェストモジュールが記録を挿入できるデータベースを使用する全てのACRサーバーに活性化トリガーを伝達することができる。(このアーキテクチャに対して次のような変形があってもよい。インジェストモデルを経由せずに動的活性化トリガーが動的活性化トリガーソースからACRサーバーに直接伝達されるが、関連した受信機に直ちにメッセージを伝送できるように、ACRサーバーは活性化時間以前のM時間単位よりも遅く到着する動的活性化トリガーを得る。次の受信機提出まで待つと遅すぎるはずである。)
アクション(13)で、ACRサーバーは直前の提出に対して受信しなかった後にデータベースから”no match”指示子を返してもうと、受信機にNULLメッセージを送ることができる。直前の提出に対して返してもらった<locator_part>と異なる<locator_part>と共にトリガーを返してもらうと、受信機にトリガーを送ることができる。両方の場合において、受信機に視聴中のチャネルが変更されたり視聴中のセグメントが終わったことを知らせ、受信機が現在実行しているTDOを終了し、必要なら、新しいTPTをダウンロードするようにすることができる。ACRサーバーは、一つ以上の活性化トリガーを返してもらうと、既に受信機に送られた活性化トリガーと重複するものは捨てて受信機に送ることができる。それとも、ACRサーバーは何にもしなくてもよい。
新しいアクション(14)で、ACRサーバーは動的活性化トリガーを受信すると、動的活性化トリガーの<locator_part>と各ACRクライアントに対する現<locator_part>とを比較することができる。(ここでクライアントに対する現<locator_part>は、ACRサーバーがACRクライアントからの最も最近の提出に対してデータベースから受けたトリガーの<locator_part>である。<locator_part>がマッチングされる各クライアントに対して、ACRサーバーは動的トリガーをクライアントに送ることができる。)
図29及び図31は、活性化時間よりも少なくともM時間単位以前にACRインジェストモジュールに伝達される静的活性化及び動的活性化に対するトリガーの処理を示す。差異点は、ACRサーバーが重複する活性化トリガーを受信機に送らずに捨てることができるという点である。
図35は、急に(活性化時間よりもM時間単位以前に)受信された動的活性化トリガーの処理の一実施例を示す。
図35は、時間ライン上の動的イベント活性化時間及びACRインジェストモジュールがイベント活性化について知る時であるイベント活性化時間よりも少し前の時間を示す。時間ラインの下の垂直矢印は、個別フレームの回数を表す。ACRサーバーは、ACRインジェストモジュールから活性化トリガーを受信し次第、(トリガーの<locator_part>から確認されるように)現在活性化トリガーと関連したセグメントを視聴している全ての受信機に活性化トリガーを送ることができる。
図36は、最後に伝達される動的活性化トリガーの一実施例を示す図である。
最後に伝達される動的活性化トリガーについて説明する。
図36は、急に(活性化時間よりもM時間単位以前に)受信された動的活性化トリガーの処理の一実施例を示す。
最後に伝達される動的活性化トリガーを示す同図は、時間ライン上の動的イベント活性化時間及びACRインジェストモジュールがイベント活性化について知る時であるイベント活性化時間よりも少し前の時間を示す。時間ラインの下の垂直矢印は、個別フレームの回数を表す。ACRサーバーは、ACRインジェストモジュールから活性化トリガーを受信し次第、(トリガーの<locator_part>から確認されるように)現在活性化トリガーと関連したセグメントを視聴している全ての受信機に活性化トリガーを送ることができる。各受信機に対して、トリガーのevent_timeを、受信機から最も最近に提出されたシグネチャーに対応するフレームと関連した<delay_time>に調節する。
図37は、要求/応答ACRケースにおけるACRクライアントと他のサーバー間のシーケンスダイヤグラムを示す図である。
図37は、要求/応答モデルにおいてACRサーバーと受信機(ACRクライアント)の動作プロトコルによってトリガー及びTPTを效果的に送信する実施例を示すシーケンスダイヤグラムである。
以下、要求/応答の順で要求/応答モデルの動作の一例を説明する。
要求/応答ACRケースにおいて、ACRクライアントと他のサーバー間のシーケンスダイヤグラムは、ACR要求1(S37010)、ACR応答1(S37020)、ACR要求2(S37030)、ACR応答2(S37040)、HTTP要求1(S37050)、HTTP応答1(S37060)、HTTP要求2(S37070)、HTTP応答2(S37080)、ACR要求3(S37090)、ACR応答3(S37100)、ACR要求4(S37110)、及び/又はACR応答4(S37120)を含むことができる。
ACR要求1(S37010)は、受信機が現在視聴中のプログラムのシグネチャーをサーバーに送る段階である。サーバーは、前述したACRサーバーであってもよい。シグネチャーはフィンガープリントシグネチャー又はウォーターマーキングコードであってもよい。
ACR応答1(S37020)は、シグネチャーが認識されなかったり、又は関連した双方向サービスが存在しないとき、ACRサーバーがヌルをリターンする段階である。これは、ヌル応答がリターンされる上述したケースに該当する場合であってもよい。
ACR要求2(S37030)は、チャネル又はプログラムが変更されるとき、受信機が変更されたプログラムのシグネチャーをACRサーバーに伝送する段階である。
ACR応答2(S37040)は、ACRサーバーが該当のプログラムに関連した双方向サービスを取得できるアドレスを含むトリガー(例えば、xbc.com/tpt504)をリターンする段階である。この段階は、ACR応答1(S37020)と違い、シグネチャーが認識され、関連した双方向サービスが存在するケースに該当できる。すなわち、トリガーを利用可能である場合であってもよい。この場合、リターンされるトリガーは、media_timeに関する情報がない時間ベーストリガーであってもよい。
HTTP要求1(S37050)は、受信機がTPTサーバー(例えば、http://xbc.com/tpt504)にhttpプロトコルを通してACR応答2(S37040)で受信したアドレスを用いて該当するTPTを提供することを要求する段階である。
HTTP応答1(S37060)は、TPTサーバーが受信機の要求に応じてXMLに表したTPTを伝送する段階である。
HTTP要求2(S37070)は、受信機がコンテンツサーバーにhttpプロトコルを用いてTDOのようなアプリケーションを提供することを要求する段階である。受信機は、TPT内に含まれたTDO関連情報をパーシングすることができる。TDO関連情報は、TDOをダウンロードできるコンテンツサーバーのアドレスであってもよい。コンテンツサーバーのアドレスを用いて要求を送ることができる。
HTTP応答2(S37080)は、コンテンツサーバーが受信機の要求に応じて該当するTDOを伝送する段階である。
ACR要求3(S37090)は、受信機が現在視聴中のプログラムのフレームのシグネチャーをACRサーバーに送る段階である。
ACR応答3(S37100)は、ACRサーバーが該当のプログラムに関連した双方向サービスを取得できるアドレスを含むトリガー(例えば、xbc.com/tpt504)をリターンする段階である。この場合、ACR応答1(S37020)と違い、シグネチャーが認識され、関連した双方向サービスが存在する。すなわち、この段階でトリガーは使用可能である。
ACR要求4(S37110)は、受信機が現在視聴中のプログラムのフレームのシグネチャーをACRサーバーに伝送する段階である。
ACR応答4(S37120)は、ACRサーバーが、受信機から伝送されたシグネチャーと関連した双方向サービスと関連した活性化トリガーを伝送する段階である。特定イベントが活性化トリガーによって特定時間に活性化されうる。
図38は、イベント主導型ACRケースにおけるACRクライアントと他のサーバー間のシーケンスダイヤグラムを示す図である。
図38は、イベント主導型モデルにおいてACRサーバーと受信機(ACRクライアント)の動作プロトコルによってトリガー及びTPTを效果的に伝送する実施例に係るシーケンスダイヤグラムを示す。
要求、要求に対する応答、イベントの順にイベント主導型モデルの動作についての一例を説明する。
イベント主導型ACRケースにおいて、ACRクライアントと他のサーバー間のシーケンスダイヤグラムは、ACR要求1(S38010)、ACR要求2(S38020)、ACRイベント1(S38030)、HTTP要求1(S38040)、HTTP応答1(S38050)、HTTP要求2(S38060)、HTTP応答2(S38070)、ACR要求3(S38080)、ACRイベント2(S38090)、及び/又はACR応答4(S38100)を含むことができる。
ACR要求1(S38010)は、受信機が現在視聴中のプログラムのシグネチャーをサーバーに送る段階である。サーバーは、上述したACRサーバーであってもよい。シグネチャーは、フィンガープリントシグネチャー又はウォーターマークであってもよい。ここで、シグネチャーが認識されなかったり、又は関連した双方向サービスが存在しないとき、図37のシーケンスとは違い、ACRサーバーはヌルをリターンせずにACR要求1に何ら応答も送らなくてもよい。
ACR要求2(S38020)は、チャネル又はプログラムが変更されるとき、受信機が、変更されたプログラムのシグネチャーをACRサーバーに伝送する段階である。
ACRイベント1(S38030)は、ACRサーバーが、該当のプログラムに関連した双方向サービスを取得できるアドレスを含むトリガー(例えば、xbc.com/tpt504)をリターンする段階である。この段階は、シグネチャーが認識され、関連した双方向サービスが存在するケースに該当できる。すなわち、この段階でトリガーは使用可能である。この場合、リターンするトリガーは、media_timeと関連した如何なる情報も有しない時間ベーストリガーであってもよい。
HTTP要求1(S38040)は、受信機がTPTサーバー(例えば、http://xbc.com/tpt504)にhttpプロトコルを通してACRイベント1(S38030)で受信したアドレスを用いて該当するTPTを提供することを要求する段階である。
HTTP応答1(S38050)は、TPTサーバーが受信機の要求に応じてXMLに表したTPTを伝送する段階である。
HTTP要求2(S38060)は、受信機がコンテンツサーバーにhttpプロトコルを用いてTDOのようなアプリケーションを提供することを要求する段階である。受信機は、TPT内に含まれたTDO関連情報をパーシングすることができる。TDO関連情報は、TDOをダウンロードできるコンテンツサーバーのURLであってもよい。コンテンツサーバーのURLを用いて要求を送ることができる。
HTTP応答2(S38070)は、コンテンツサーバーが受信機の要求に応じて該当するTDOを伝送する段階である。
ACR要求3(S38080)は、受信機が現在視聴中のプログラムのフレームのシグネチャーをACRサーバーに送る段階である。
ACRイベント2(S38090)は、ACRサーバーが受信機から伝送されたシグネチャーと関連した双方向サービスと関連した活性化トリガーを伝送する段階である。特定イベントが活性化トリガーによって特定時間に活性化されうる。
ACR応答4(S38100)は、受信機が現在視聴中のプログラムのフレームのシグネチャーをACRサーバーに送る段階である。
図39は、UPnP RemoteUIクライアントサービスのアクションリストの一実施例である。
第2スクリーン支援は、受信機で、放送社のサービス或いは放送社で提供し、プログラムに適した付加的なサービスを、第2スクリーンデバイスに提供するための方法に関するものである。付加的なコンテンツは、アプリケーションを用いて提供することができ、アプリケーションは、TV画面に表示されてユーザがリモコン操作で付加コンテンツを使用するようにすることができる。しかし、最近では、個人化情報化機器(スマートホン、スマートパッド及び小型化しつつあるラップトップ)などによってTV画面で再生されているコンテンツはそのまま表示させながら、付加的なサービスを第2スクリーンデバイスに表示させることができる。これによって、既存の放送コンテンツを妨害なく個人的に利用できるようにすることができる。このように付加的なデータや情報を第2スクリーンデバイスに表示して処理をすると、TV画面を複数の人が一緒に見る状況で、付加サービスに関心のある人だけが他の人のTV視聴を妨害することなく付加コンテンツを得ることができる効果がある。第2スクリーン支援は、前述した効果の他にも様々な用途に活用することができる。
一つの装置を他の装置に接続させて制御するためには、まず、ホームネットワークにどのような装置があるかを知らなければならない。このため、一つ以上の装置が自身の存在を周期的にホームネットワークにメッセージを送信して広く知らせることができる。一方では、一つの装置が新しくホームネットワークに接続しながら自身を紹介する前に、自身以外にどのような装置があるかを要求することができる。これら2つの接近方式は、互いに装置を容易に且つ迅速に認識できるように手伝うことができる。これを、UPnPデバイスディスカバリ(Device Discovery)と呼ぶ。装置を発見すると、発見された装置に関心のある他の装置は、その装置にどのようなサービスを提供できるかに関する情報が必要でありうる。UPnPフレームワーク(Framework)が内蔵されている家電機器は、互いにどんな機能を有しているか、そしてそれらの機能がどの範囲まで支援するかが把握できる。この情報をUPnPデバイスプロファイル(Device Profile)と定義しておき、互いに提供できるサービスの属性を把握することができる。特定サービスを提供する装置を常に待っていてもよいが、その特定サービスを提供する装置が発見される場合、発見された装置内にどのようなサービスがあるかを問うことができる。発見された装置内に適合なサービスがあると、すぐに接続して互いに通信することができる。また、UPnPサービス記述語(Service Descriptor)に定義されたとおりにサービスを定義して交換することができる。
一つの装置には、単数又は複数個のサービスがあり、このサービスを互いに異なる機器で制御して使用するようになっている。装置に一つ以上の機能があると、その機能別に定義された複数個のサービスが含まれ、他の機器で制御することができる。装置の定義は、装置固有の情報を有することができる。例えば、モデル名(Model Name)、一連番号(Serial Number)、モデル番号(Model Number)、CEメーカー名(Manufacturer Name)及びウェブサイト(Web Site)などの情報が装置固有の情報であってもよい。これらの情報は装置別に固有の値を有し、一般的には変更されない。サービスは、装置が行える動作であり、各動作はアクション(Action)と呼び、一つ以上のアクションを有することができる。アクションは、関数のようにそれぞれパラメータ値を有し、一つ以上のパラメータ値を有することができる。アクションは、装置内のサービスで行われ、アクションが行われた後には、必要によって、定義されたリターン値を返還することができる。
アクションに対する例示として、図39は、例示されたサービスであるUPnP RemoteUIクライアントサービスに対して、そのサービスのアクションの種類及び記述(Description)を示している。Connection/disconnectionは、現在接続状態を返還するアクションであってもよい。GetCurrentConnectionは、現在接続目録を返還するアクションであってもよい。GetDeviceProfileは、デバイスプロファイルをXMLの形態として返還するアクションであってもよい。GetUIListingは、互換可能な(compatible)UIの目録をXMLの形態として返還するアクションであってもよい。AddUIListing/RemoveUIListingは、remote UIのURLをUI目録に追加したり除去する動作であってもよい。ProcessInputは、RemoteUIクライアントサービスにデータを送るアクションであってもよい。DisplayMessageは、RemoteUIクライアントサービスを含む装置にメッセージをディスプレイするアクションであってもよい。
図40は、UPnP RemoteUIクライアントサービスの一実施例である。
UPnPでは、前述したアクションと必要なパラメータ値を送信するために、SOAPというXMLメッセージ形式を使用し、SOAPは、遠隔手順(Remote Procedure)を遠隔で行うために用いることができる。これらのメッセージは、HTTPプロトコルを用いて伝送することができる。
前述したRemoteUIクライアントのアクションは、図40のように動作することができる。図40に示す動作は、前述したアクションの一実施例にすぎない。
UPnP RemoteUIクライアントサービスの一実施例は、UPnP探索プロセスとRemoteUIクライアントアクションとに分けることができる。
UPnP探索プロセスは、第2スクリーンサービスのためのUPnPアプリケーションを実行する段階(s40001)、UPnPデバイスを探す段階(s40010)、RemoteUIClientを探す段階(s40020)、デバイス記述(Device Description)を要求する段階(s40030)、デバイス記述を受信する段階(s40040)、サービス制御記述を要求する段階(s40050)及び/又はサービス制御記述を受信する段階(s40060)を含むことができる。
RemoteUIクライアントアクションは、デバイスプロファイルを要求する段階(s40070)、デバイスプロファイルを受信する段階(s40080)、遠隔UIのURLを送る(put)段階(s40090)、応答1を送信する段階(s40100)、RemoteUIクライアントサービスにメッセージを送信する段階(s40110)、応答2を送信する段階(s40120)、及び/又はユーザがスクリーン上のボタンをクリックする段階(s40130)を含むことができる。
UPnPアプリケーションを実行する段階(s40001)は、第2スクリーンデバイス(RemoteUIクライアント)でan UPnPアプリケーションを実行させる段階であってもよい。
UPnPデバイスを探す段階(s40010)は、プライマリデバイスが第2スクリーンデバイスで実行中のアプリケーションにディスカバリメッセージ(discovery message)をマルチキャストする段階であってもよい。これによってネットワーク内の第2スクリーンデバイスを探すことができる。プライマリデバイスは、ディスカバリメッセージを用いて、自身が提供する第2スクリーン支援サービスを知らせることができる。
RemoteUIClientを探す段階(s40020)は、第2スクリーンデバイスがディスカバリメッセージを受け、プライマリデバイスに通知メッセージ(notification message)を送る段階であってもよい。
デバイス記述を要求する段階(s40030)は、プライマリデバイスが第2スクリーンデバイスに第2スクリーンデバイスに対するデバイス記述を要求する段階であってもよい。
デバイス記述を受信する段階(s40040)は、第2スクリーンデバイスがデバイス記述を要求する段階(s40030)に対する応答として第2スクリーンデバイスのデバイスプロファイルを送ると、プライマリデバイスがこれを受信する段階であってもよい。
サービス制御記述を要求する段階(s40050)は、プライマリデバイスが第2スクリーンデバイスにサービス制御記述を要求する段階であってもよい。
サービス制御記述を受信する段階(s40060)は、プライマリデバイスが第2スクリーンデバイスから、要求したサービス制御記述を受信する段階であってもよい。
UPnP探索プロセスによって、ネットワーク上に存在するプライマリデバイスと第2スクリーンデバイスはお互い探索して認識することができる。また、これによってプライマリデバイスと第2スクリーンデバイスは互いに接続することができる。
デバイスプロファイルを要求する段階(s40070)は、第2スクリーンデバイスのデバイスプロファイルを要求する段階であってもよい。前述したGetDeviceProfileアクションを用いることができる。
デバイスプロファイルを受信する段階(s40080)は、プライマリデバイスが要求した第2スクリーンデバイスのデバイスプロファイルを受信する段階であってもよい。“RemoteUIクライアントサービス”を有する装置(第2スクリーンデバイス、RemoteUIクライアント)は、遠隔の装置(プライマリデバイス)でUIのURLアドレスを知らせると、このアドレスを探して画面に表示する役割を果たすことができる。また“RemoteUIサーバーサービス”を有する装置は、UIのURLアドレスをマルチキャストし、それに関心のある装置に知らせるサービスであってもよい。しかし、この場合には、Remote UIが特定装置のために作られるため、特定装置に合う遠隔UIを提供しなければならない。このため、デバイスプロファイル情報を共に送信する必要があり、デバイスプロファイルを要求する段階(s40070)及びデバイスプロファイルを受信する段階(s40080)が必要でありうる。
遠隔UIのURLを送る段階(s40090)は、遠隔UIのURLアドレスを第2スクリーンデバイスに知らせる段階であってもよい。前述したAddUIListingアクションを用いることができる。第2スクリーンデバイスは、これをUIListingに追加することができる。
応答1を送信する段階(s40100)は、遠隔UIのURLを送る段階(s40090)に対する結果を送る段階であってもよい。状況によって、HTTP/1.1 200 OK(要求が成功裏に処理される)、HTTP/1.1 501 Method Not Implemented(要求を処理するために必要な機能が具現されていない)、HTTP/1.1 400 Not Found(要求したファイル/リソースが存在しない)などの応答を送ることができる。
RemoteUIクライアントサービスにメッセージを送信する段階(s40110)は、プライマリデバイスが第2スクリーンデバイスにディスプレイメッセージを送信する段階であってもよい。ディスプレイメッセージは、メッセージタイプなどの情報を含むことができる。前述したDispalyMessageアクションを用いることができる。第2スクリーンデバイスは、ディスプレイメッセージによって、メッセージを第2スクリーンにディスプレイすることができる。
応答2を送信する段階(s40120)は、RemoteUIクライアントサービスにメッセージを送信する段階(s40110)に対する結果を送る段階であってもよい。前述した応答1を送信する段階(s40100)と同様に、状況に応じて、HTTP/1.1 200 OKなどの応答を送ることができる。
ユーザがスクリーン上のボタンをクリックする段階(s40130)は、第2スクリーンにディスプレイされたメッセージなどによって、ユーザが選択をする段階であってもよい。
RemoteUIクライアントアクションは、前述したアクションなどによってRemoteUIクライアントサービスが動作する過程を記述したものであってもよい。
遠隔ユーザインターフェースに関する記述は、画面に表示されるHTML記述ベースのアプリケーションを家電機器で使用できるように機能を追加したり制限された家電機器のリソースを勘案して、既存のPCシステムで使用可能な機能を簡素化した。この記述には、大きく、2つの観点が含まれている。すなわち、画面に表示するHTMLを家電製品で使用できるようにしたことと、各家電製品で使用できるブラウザAPIを定義することである。ブラウザAPIは、多く使われているスクリプト言語であるジャバスクリプト(JavaScript)で呼び出しして使用することができる。ジャバスクリプトで呼び出されたAPIは、結局として受信機の関数を呼び出すようになる。
この中、前述したUPnPデバイスとサービスは、ブラウザで動作するジャバスクリプトによっても動作できるはずである。そのためには、ブラウザで各UPnPデバイス別に異なるパラメータを伝達する新しいAPIが必要であろう。
図41は、DTVCC Service Number6におけるトリガーの一実施例である。
前述したとおり、DTVCC(Digital TV Closed Caption Service)サービスを用いて前述のリガーを送信することができる。トリガーは、一つのURLストリング(String)値を有することができ、DTVCCサービスのうちの6番目のサービスとして受信することができる。MPEG−2送信プロセッサ41010はトリガーをDTVCCサービスシリーズ#6として受信し、送信プロセッサドライバ41020を通してDTV−CCモジュール41040に伝達できる。このとき、Userdataは、バッファー41030を経由することができる。DTV−CCモジュール41040は、DTVCCデコーダの役割を果たすことができる。DTV−CCモジュール41040は、URIストリング値を有するトリガーを付加サービスモジュール(Adjunct Service module)41050に伝達することができる。付加サービスモジュール41050はトリガーモジュールであり、URIストリング値を把握し、前述したTPT(TDO Parameters Table)を取得することができる。これによって、前述したとおり、トリガー、TPT及びTDOを用いて付加サービスを提供することができる。
図42は、第2スクリーンシナリオのためのシステムアーキテクチャの一実施例である。
第2スクリーンの支援のためにいくつかの要求事項がありうる。1)受信機は、一つ或いはそれ以上の第2スクリーンデバイスと接続することができる。2)第2スクリーンデバイスは、ラップトップ、タブレット、スマートホン、PDAなどの携帯機器を対象とすることができる。3)第2スクリーンの主要コンテンツは、HTML、テキスト、ビデオ、オーディオなどとすることができる。4)第2スクリーンで再生されるコンテンツは、プライマリデバイス(受信機)の放送プログラムに邪魔とならない設計とすることができる。5)第2スクリーンは直接的にATSC2.0受信機に接続することができ、間接的には3GPP網のように迂回して接続することもできる。6)プロバイダが、特定コンテンツが第2スクリーンでのみ表示されるようにシグナリングすることもできる。7)場合によって、受信機で再生可能なコンテンツも、第2スクリーンで再生可能に設計することができる。8)認証(Authentication)及び許可(Authorization)された第2スクリーンで第2スクリーンサービスを用いることができる。9)第2スクリーンコンテンツの聴衆使用量(audience usage)を測定するようにすることができる。(この場合、このような情報を得るためにユーザから同意を得、その情報を報告できる機能が存在してもよい。)10)第2言語又はコンテンツエンハンスメント(Content Enhancement)可能な装置を用いて提供することもできる。
本明細書は、放送されるプログラムと同期したコンテンツを有する第2スクリーンデバイス(スマートホン、タブレット、ラップトップなど)上で実行されるアプリケーションによるA/V放送に関連したコンテンツのディスプレイを支援するために受信機によって提供されうるサービスを記述することができる。サービスに関する説明はUPnPデバイスアーキテクチャに基づいて記述された。
この明細書で、ATSC2.0受信機とは、TV受信機又は一般的な受信機を意味することができる。また、DVB、ATSCなどにおける受信機を意味することができる。
UPnPデバイスアーキテクチャは、サービスを提供する“被制御デバイス”及びそのサービスを利用する“制御ポイント”間のIPネットワークにおける通信のためのプロトコルを定義する。“第2スクリーン”シナリオで、TV受信機は“被制御デバイス”の役割を担い、第2スクリーンデバイスは“制御ポイント”の役割を担うことができ、その逆であってもよい。
UPnPデバイスアーキテクチャは、関心のある被制御デバイスを探す制御ポイントのための“探索”プロトコル、被制御デバイス及びサービスに対する細部事項を学習する制御ポイントのための“記述(description)”プロトコル、被制御デバイス上の“アクション”(方法)を実行(invoke)する制御ポイントのための“制御”プロトコル、及び制御ポイントに非同期通知を伝達する被制御デバイスのための“イベンティング(eventing)”プロトコルを特定する。アクション及びイベントは、デバイスサービスによって提供することができる。
UPnP被制御デバイスがネットワークにジョイン(join)すると、“よく知らされた”IPマルチキャストアドレス及びポートにディスカバリメッセージをマルチキャストすることができる。それらのメッセージは、デバイスによって提供されるデバイスタイプ及びサービスタイプを識別することができ、デバイス及びサービスの記述を取得できるURLを提供することができる。
UPnP制御ポイントがネットワークにジョインすると、被制御デバイスに自身を知らせるかを問う序歯(search)メッセージをマルチキャストすることができる。サーチメッセージは、関心のあるデバイスタイプ及び/又はサービスタイプを特定することができる。関連デバイスは、制御ポイントにユニキャストディスカバリメッセージを送ることによって応答することができる。
制御ポイントが関心のあるデバイス及びサービスに対するディスカバリメッセージを得ると、メッセージ内のURLを用いてデバイス及びサービスの記述(description)を要求することができる。それらの記述は、アクションを実行(invoke)し、サービスに対するイベントを申し込むために用い得るURLを含むことができる。
一般的な第2スクリーン探索シナリオは、シナリオAとシナリオBとに大別できる。シナリオAの場合、ユーザは、TV受信機が(TV受信機がオンになる時又はそのネットワークインターフェースがイネーブルされる時に発生しうる)ネットワークにジョインする時、自身の第2スクリーンデバイスで実行される第2スクリーンアプリケーションを有する。シナリオBの場合、ユーザは、TV受信機がネットワークにジョインする時、自身の第2スクリーンデバイスで実行される第2スクリーンアプリケーションを有しない。
シナリオAは、次の通りでありうる。1)第2スクリーン支援を提供するTV受信機はネットワークにジョインする。2)TV受信機は、その第2スクリーン支援サービスを広告するディスカバリメッセージをマルチキャストする。3)第2スクリーンデバイスで実行される第2スクリーンアプリケーションは、マルチキャストされたディスカバリメッセージを受信し、TV受信機にそのサービスの記述に対する要求を送信する。4)TV受信機は、そのサービスの記述で応答する。5)第2スクリーンアプリケーションは、記述中に含まれた情報を用いて適切なサービスにアクセスして、TVプログラミングと同期したインタラクティブ経験を提供する。
シナリオBは、次の通りでありうる。1)TV受信機上で見ているTV番組は、第2スクリーン支援を提供するプログラムセグメントに入る。(これは、TV受像機がオンになるやいなや又はチャネルが第2スクリーン支援を有するインタラクティブデータサービスを提供しないチャネルからインタラクティブデータサービスを提供するチャネルに変更される時、又は視聴しているチャネルが第2スクリーン支援を有するインタラクティブデータサービスを提供しないプログラムセグメントからインタラクティブデータサービスを提供するプログラムセグメントに変更される時でありうる。)2)これは、TV受信機が第2スクリーン支援が利用可能な任意の方式で、例えば、スクリーンのコーナーにある小さいアイコンによって、ユーザに知らせるようにする。3)視聴者は、第2スクリーン支援を用いて自身の第2スクリーンデバイス上で第2スクリーンアプリケーションを活性化する。すると、第2スクリーンアプリケーションは、第2スクリーン支援を提供する装置を探すメッセージをマルチキャストする。TV受信機は、自身のディスカバリメッセージでこのメッセージに応答する。4)第2スクリーンアプリケーションがディスカバリメッセージを探すと、TV受信機にそのサービスの記述に対する要求を送信する。5)TV受信機は、そのサービスの記述で応答する。6)第2スクリーンアプリケーションは、記述中に含まれた情報を用いて適切なサービスにアクセスし、TV番組と同期したインタラクティブ経験を提供する。
シナリオAを書き換えると、次の通りでありうる。1)第2スクリーン支援を提供するTV受像機はネットワークにジョインする。(これは、TVセットがオンになる時又はそのネットワークインターフェースがイネーブルされる時であってもよい。)2)これは、TV受信機が自身及びその第2スクリーン支援サービスを広告する自身のディスカバリメッセージをマルチキャストするようにする。3)この時、ユーザが自身の第2スクリーンデバイスで実行される第2スクリーンアプリケーションを有すると、アプリケーションは、マルチキャストされたディスカバリメッセージを受信し、段階(7)に進行する。4)TV受信機上で見ているTV番組が第2スクリーン支援を提供するプログラムセグメントに入る。(これは、TV受像機がオンになるやいなや又はチャネルが第2スクリーン支援を有するインタラクティブデータサービスを提供しないチャネルからインタラクティブデータサービスを提供するチャネルに変更される時又は視聴しているチャネルが第2スクリーン支援を有するインタラクティブデータサービスを提供しないプログラムセグメントからインタラクティブデータサービスを提供するプログラムセグメントに変更される時であってもよい。)5)これは、TV受信機が、第2スクリーン支援が利用可能な任意の方式で、例えば、スクリーンのコーナーにある小さいアイコンによって、ユーザに知らせるようにする。6)視聴者が自身の第2スクリーンデバイスで実行される第2スクリーンアプリケーションを有していない場合、視聴者は、第2スクリーン支援を用いて自身の第2スクリーンデバイス上で第2スクリーンアプリケーションを活性化する。すると、第2スクリーンアプリケーションは、第2スクリーン支援を提供する装置を探すメッセージをマルチキャストする。TV受信機は、自身のディスカバリメッセージでこのメッセージに応答する。7)第2スクリーンアプリケーションがディスカバリメッセージを探すと、TV受信機にそのサービスの記述に対する要求を送信する。8)TV受信機は、そのサービスの記述で応答する。これらは、トリガーサービス及び選択的にHTTPプロキシサーバーサービスであろう。9)第2スクリーンアプリケーションは、トリガーサービスの“イベンティング”特徴を申し込むはずである。提供されるインタラクティブデータサービスの相互作用モデルが直接実行モデルであれば、全てのトリガーがTV受信機によって受信される時、トリガーサービスは全てのトリガーを第2スクリーンデバイスに送信するはずである。インタラクティブデータサービスの相互作用モデルがTDOモデルであれば、新しい活性化トリガーの活性化時間に到達する度に、トリガーサービスは活性化トリガーを第2スクリーンアプリケーションに送信するはずである。10)第2スクリーンアプリケーションは、必要によってTDO及び他のファイルを、インターネットリンク又はTV受信機によって提供されたHTTPプロキシサーバーサービスからダウンロードし、インタラクティブサービスを第2スクリーン装置ユーザに提供しながらトリガーに対して動作するはずである。11)TV受信機上のTV番組が、第2スクリーン支援を有するインタラクティブデータサービスを提供しないセグメントに進行すると、トリガーサービスは、“ヌルトリガー(null Trigger)”を第2スクリーンアプリケーションに送信し、第2スクリーンデバイスに対するインタラクティブデータサービスがそれ以上利用可能でないということを知らせる。12)その後、第2スクリーンデバイスのユーザが、第2スクリーンアプリケーションを閉じたり、そのまま第2スクリーンアプリケーションが実行されるようにし、TV受信機上の番組が第2スクリーン支援を提供する他のセグメントに入る度に相互作用を再開するようにすることができる。
これらの両シナリオで、仮定は、ホームネットワーク上に1よりも多いTV受信機を有することができる。この場合、第2スクリーンアプリケーションは、多数の異なった受信機からディスカバリメッセージを受信することができる。この場合、第2スクリーンアプリケーションは(ユーザの決定を助けるために記述メッセージからの情報をディスプレイしながら)どれをもって相互作用をするかをユーザに問うことができる。
第2スクリーン支援を提供するTV受信機は、第2スクリーンアプリケーションの使用のためのいくつかのUPnPサービスを提供することができる。UPnPサービスは、受信機から第2スクリーンアプリケーションへの“トリガー伝達サービス”、受信機で実行されるDO(Declarative Objects)及び第2スクリーンアプリケーション間の“双方向通信サービス”及び“HTTPプロキシサーバーサービス”であってもよい。それらのサービスは、構成によって選択的であってもよい。
それらのサービスは、様々な異なったソースから得られ、様々な異なったタイプの第2スクリーンデバイスで様々な互いに異なる動作環境下に実行される様々な異なったタイプの第2スクリーンアプリケーションを支援するように設計されてもよい。
一般的な第2スクリーンパッケージアプリケーションシナリオは、次の通りである。1)第2スクリーンデバイス上の制御ポイントは、第1スクリーン装置上のパッケージアプリケーションサービスを申し込む。2)消費者は、第1スクリーン装置上のパッケージアプリケーションを始める。3)パッケージアプリケーションは、第2スクリーンアプリケーションのネーム及び第2スクリーンアプリケーションのURLをパッケージアプリケーションサービスに利用可能にする。4)第2スクリーンデバイス上の制御ポイントは、同伴者(companion)アプリケーションのネーム及びURLを受信する。5)制御ポイントは、必要な消費者アクションを指示する第2スクリーン上のマーカーを設定する。6)消費者は、第2スクリーンアプリケーションのネームを検討し選択する。7)制御ポイントは、指示された第2スクリーンアプリケーションを開始する。
第2スクリーン支援を提供する第1スクリーンは、第2スクリーンアプリケーションの利用のためにいくつかのUPnPサービスを提供することができる。UPnPサービスの一つは、第2スクリーンデバイス上で実行される同伴者第2スクリーンアプリケーションのネーム及びURLを提供している“アプリケーションURLサービス”である。
第2スクリーンシナリオに対するシステムアーキテクチャを説明する。
第2スクリーンシナリオに対するシステムアーキテクチャは、放送システム42010、ACRサーバー42020、放送社ATSC2.0 iTVサーバー42030、ATSC2.0受信機42040及び/又は第2スクリーンデバイス42050を含むことができる。
放送システム42010は、一般的な放送システムであってもよい。放送ネットワークを介してトリガー、A/V、TPT及び/又はその他データファイルなどを伝達することができる。トリガーの場合、前述したとおり、DTVCCを用いて伝達することができる。
ACRサーバー42020は、放送コンテンツに対するACR関連データを管理するサーバーであり、要求或いは必要な場合、ATSC2.0受信機42040がインタラクティブサービスを取得できるように、これと関連したトリガーをATSC2.0受信機42040に送信することができる。前述したACRサーバーと同一であってもよい。
放送社ATSC2.0 iTVサーバー42030は、インタラクティブサービスを生成及び管理するサーバーであり、これと関連したTDO/ファイルを管理し、それに関する情報を含むTPT(TDO Parameter Table)を生成及び管理することができる。
ATSC2.0受信機42040は、放送A/V及びインタラクティブサービスと関連したトリガーなどを受信し、それを用いてインタラクティブサービスを取得及び画面上に提供することができる。前述した受信機と同一であってもよい。
第2スクリーンデバイス42050は、第2スクリーンデバイスであるモバイルホン、タブレット、ラップトップなどを含むことができる。前述した第2スクリーンデバイスと同一であってもよい。
トリガーは、DTVCCチャネル又はACRプロセスを通してATSC2.0受信機42040に伝達されてもよく、放送インタラクティブTV(iTV)サーバー42030から伝達されてもよい。いずれの場合も、適切な時間にトリガーはATSC2.0受信機42040から第2スクリーンデバイス42050に伝達される。本明細書は、第2スクリーンデバイス42050に伝達されるトリガーに対するメカニズムを説明する。また、ATSC2.0受信機42040上で実行されて第2スクリーンデバイス42050と双方向通信を確立するDOに対するメカニズムを説明する。
インターネットを介して利用可能なアプリケーション及び他のファイルは、そのサービスを提供する場合には、ホームネットワークを通じて、別途の3GPPネットワークを通じて、又はATSC2.0受信機42040上のHTTPプロキシサーバー(図示せず)を通じて第2スクリーンデバイス42050によって検索されうる。第1スクリーンデバイス上で実行されるアプリケーションは、放送によって送信されるアプリケーション又はインターネットからダウンロードしたパッケージアプリケーションであってもよい。
放送でFLUTEセッションを通じてのみ利用可能なアプリケーション及び他のファイルは、ATSC2.0受信機42040が要求時にFLUTEファイルを伝達するHTTPプロキシサーバーを提供する時にのみ(第2スクリーンデバイス42050はTV受信機を含まないと仮定)、第2スクリーンデバイス42050によって検索されうる。
本明細書はまた、第2スクリーンデバイス42050上でのアプリケーションの開始を支援するためにATSC2.0受信機42040上で実行されるパッケージアプリケーションに対するメカニズムを説明する。
図43は、ATSC2.0受信機及び第2スクリーン間のトポロジ(直接接続)の一実施例である。
図43は、ATSC2.0受信機と第2スクリーンデバイス間の直接接続を説明する。
ATSC2.0受信機及び第2スクリーン間のトポロジ(直接接続)の一実施例は、放送システム43010、放送社ATSC2.0サーバー43020、ATSC2.0受信機43030及び/又は第2スクリーンデバイス43040を含むことができる。
放送システム43010は、放送システム42010と同一であってもよい。
放送社ATSC2.0サーバー43020は、放送社ATSC2.0 iTVサーバー42030と同一であってもよい。
ATSC2.0受信機43030は、ATSC2.0受信機42040と同一であってもよい。
第2スクリーンデバイス43040は、第2スクリーンデバイス42050と同一であってもよい。
ATSC2.0受信機43030は、放送網に接続していて直接的に地上波放送受信が可能であってもよい。したがって、ATSC2.0受信機43030では、DTVCCを通じて送信されるiTVメッセージのURLストリングをDTVCCサービス番号6で抽出可能であってもよい。また、ホームゲートウェイに接続していていつでも必要によってインターネットに接続可能であってもよい。そして、ホームネットワーク記述(UPnP)を用いて、他のホームネットワーク内に接続した装置と通信することができる。
第2スクリーンデバイス43040はいずれもホームゲートウェイと接続していてそれぞれの装置間の通信が可能であり、自由にインターネット接近が可能であってもよい。ホームゲートウェイは、イーサネット(Ethernet)及びWi−Fiを支援する機能を全て備えていてもよい。
放送社は、インタラクティブサービスのためにインターネットにサーバーをおいて付加サービスを提供することができる。ATSC2.0受信機43030や第2スクリーンデバイス43040が接続して、TDOやモバイル用に作られたウェブページをダウンロードすることができる。ATSC2.0受信機43030である場合には、TVの解像度に合わせて作られたウェブページであり、第2スクリーンデバイス43040である場合には、TVと違い、解像度及び支援するAPIsが異なってもよいため、それに適合するように製作されうる。
図44は、ATSC2.0受信機及び第2スクリーン間のトポロジ(間接接続)の一実施例である。
図44は、ATSC2.0受信機及び第2スクリーンデバイス間の間接接続を説明する。
ATSC2.0受信機及び第2スクリーン間のトポロジ(間接接続)の一実施例は、放送システム44010、放送社ATSC2.0サーバー44020、放送社セッション管理44030、ATSC2.0受信機44040及び/又は第2スクリーンデバイス44050を含むことができる。
放送システム44010は、放送システム42010と同一であってもよい。
放送社ATSC2.0サーバー44020は、放送社ATSC2.0 iTVサーバー42030と同一であってもよい。
放送社セッション管理44030は、間接接続において、第2スクリーンデバイス44050とATSC2.0受信機44040間の間接接続を管理する役割を担うことができる。
ATSC2.0受信機44040は、ATSC2.0受信機42040と同一であってもよい。
第2スクリーンデバイス44050は、第2スクリーンデバイス42050と同一であってもよい。
図44の間接接続は、第2スクリーンデバイス44050がホームゲートウェイを通じてATSC2.0受信機44040に接続される場合ではなく、3GPP網に直接接続してホームネットワークにあるATSC2.0受信機44040と接続される場合であってもよい。この場合には、第2スクリーンデバイス44050がホームネットワークに接続し難い場合或いはホームネットワークを支援するネットワークインターフェースがない場合に該当する。
この場合には、第2スクリーンデバイス44050は、外部のインターネットサーバーが有しているATSC2.0受信機44040の情報が必要でありうる。また、ATSC2.0受信機44040は、動作時に、接続アドレスを外部にあるインターネットサーバーに報告して知らせなければならないことがある。
第2スクリーンデバイス上にインタラクティブサービスを效果的に伝達するための方案として、中央集中型(centralized)実行モデル及び分散型(distributed)実行モデルがある。
図45は、第2スクリーンサービスアプリケーションのソフトウェア層の一実施例を示す図である。
第2スクリーンデバイスは、一般的に、OSを用いてアプリケーションを実行する。一般に、モバイル装置用OSの一部の機能は、軽量化の目的から含まれなくてもよい。したがって、OSによって支援されない機能がアプリケーションに含まれる必要がある。
図45のソフトウェア層は、第2スクリーンサービスに必要な第2スクリーンサービスアプリケーションのソフトウェア構造を示す。図45は、受信機が第2スクリーンアプリケーションのライフサイクルを管理する場合を示すことができる。
第2スクリーンデバイスがインターネットコンテンツを再生するので、OSはプラットホームSDKを用いてウェブアプリケーションが実行され得る環境をプログラマーに提供することができる。環境は、OSによって実行されるアプリケーションがインターネットコンテンツをディスプレイするようにSDKの形態で提供することができる。
図45で、第2スクリーンサービスアプリケーションは、第2スクリーンデバイス上で実行されうる。このアプリケーションは、アップストア(AppStore)(又は、任意の種類のアプリケーションマーケット)からダウンロードされうる。第2スクリーンサービスアプリケーションは、ACRクライアントを含むことができ、マイクロホン及びカメラを用いてTV受像機からビデオ及びオーディオデータをキャプチャーすることができる。また、ACRクライアントは、ビデオ及びオーディオデータをサンプリングし、メディアシグネチャーをACRサーバーに送信することができる。第2スクリーンサービスアプリケーションは、OS上で実行可能であり、UPnPフレームワークが何を動作させ得るかによって、HTTP、SSDP又はマルチキャストイベントなどのプロトコルを含み、ブラウザモジュールは、ウェブアプリケーションを実行及びディスプレイするために含まれうる。
ブラウザモジュールは、インターネットウェブページをレンダリングするモジュールであってもよい。ブラウザモジュールは、ウェブアプリケーション(例えば、ECMAScript、HTML及びXHTML)をレンダリングするウェブブラウザエンジンの核心部分である。また、ブラウザモジュールは、OSによって提供されるブラウザと同一又は類似の機能を提供するソフトウェアモジュールを意味できる。ブラウザ及び制御可能な機能を利用する方法は、OS別に異なる。
第2スクリーンアプリケーションは、第2スクリーンデバイス用に設計されたウェブアプリケーションであってもよい。第2スクリーンアプリケーションは、ECMAScript又はウェブアプリケーションによって機能を呼び出すウェブアプリケーションであってもよく、そのサイズは、モバイルOSによって提供されるブラウザモジュールで実行されるように制御されうる。このウェブアプリケーションは、第2スクリーンサービスアプリケーションで実行されうる。
モバイル装置用オペレーティングシステムは、ハードウェアを支援するドライバで構成され、カーネル特定(kernel−specific)サービス用ドライバを含むことができる。基本的に、IP、TCP及びUDPプロトコルを支援することができる。ネットワークプロトコルスタックは、OS上に存在する。UPnPの場合、HTTPは、UDPを用いて送信することができる。
UPnP DCPフレームワークは、UPnPフォーラムに定義されたデバイス制御ポイントを意味することができる。
SSDP(Simple Service Discovery Protocol)は、ホームネットワークでネックワークに接続されたデバイスによって一つ以上のサービスを探すことができる。
図46は、第2スクリーンサービスアプリケーションのソフトウェア層を示す図である。
図46のソフトウェア層は、第2スクリーンサービスに必要な第2スクリーンサービスアプリケーションのソフトウェア構造を示す。図46は、第2スクリーンサービスアプリケーションが第2スクリーンアプリケーションのライフサイクルを管理する場合を示すことができる。
図46のそれぞれのエンティティの説明は、その役割及び機能において図45と同一である。
ATSC2.0トリガークライアントは、上述したトリガー、TPT、AMTなどを受信し処理するモジュールを意味できる。このモジュールは、状況によって第2スクリーンデバイスに含まれてもよい。このモジュールが第2スクリーンデバイスに含まれると、このモジュールはTPT及びAMTを直接処理し、アプリケーションのライフサイクルを直接チェックすることができる。
図47は、第2スクリーンアプリケーションライフサイクル管理による送信順序及び送信されたデータ間の違いを示すテーブルである。
受信機は、放送ネットワークを通じてDTVCCを用いてTPT及びAMTを直接受信したり、インターネットネットワークを通じてTPT及びAMTをダウンロードし、TPT及びAMTを処理する。上述した通り、TPTはイベント情報を含み、イベント情報は、EventId、Action、Destination及びData情報を含むことができる。“Event@Destination”は、このイベント情報が発生する装置を示すことができる。例えば、あて先は、受信機又は第2スクリーンデバイスであってもよい。あて先が第2スクリーンデバイスに設定されると、受信機は、第2スクリーンデバイスにイベント情報を伝達しなければならない。
このため、この情報を第2スクリーンデバイスに伝達する方法が必要である。第2スクリーンアプリケーションのライフサイクルは、受信機又は第2スクリーンサービスアプリケーションで管理することができる。
図47のテーブルは、どのエンティティが第2スクリーンアプリケーションのライフサイクルを支援するかによる情報伝達方法の概要を示す。
第1行は、図51の後述する場合の説明の概要であってもよく、その詳細な説明は後述する。
第2行は、受信機が第2スクリーンアプリケーションのライフサイクルを管理する場合の説明の概要であってもよく、その詳細な説明は後述する。
第3行は、受信機が第2スクリーンデバイスに必要なトリガー情報をフィルタリング(増加)し伝達する場合の説明の概要であってもよく、その詳細な説明は後述する。
第4行は、図58の後述する場合の説明の概要であってもよく、その詳細な説明は後述する。
第5行は、図57の後述する場合の説明の概要であってもよく、その詳細な説明は後述する。
図48は、中央集中型実行モデルの動作概念を示す図である。
インタラクティブサービスを第2スクリーンデバイスに效率的に伝達する方法は、中央集中型実行モデル及び分散型実行モデルを含むことができる。
中央集中型実行モデルの動作概念を示す図に示すように、TV受像機は、UPnPのRUIメカニズムを用いて、各第2スクリーンデバイス上にディスプレイされるRUIを生成及びアップデートし、ネットワークを通じてRUIを送信することができる。それぞれの第2スクリーンデバイスは、RUIクライアントを通じて実時間でRUIを受信し、スクリーン上にRUIをディスプレイすることができる。分散型実行モデルと違い、DAEは、プライマリデバイスに存在しうる。
図49は、分散型実行モデルベース受信機及び第2スクリーン間の連動に対するフローの一実施例である。
図49のフローは、中央集中型実行モデルの動作概念の実施例で受信機が放送ネットワークを通じてインタラクティブサービスを得ることができ、第2スクリーンデバイスと連動する環境で中央集中型実行モデルメカニズムが適用される時の動作であってもよい。
中央集中型実行モデルベース受信機及び第2スクリーン間の連動に対するフローの実施例は、時間ベーストリガーを送信する段階(s49010)、TPTを要求する段階(s49020)、応答としてTPTを送信する段階(s49030)、TPTをパーシング(parse)する段階(s49040)、第2スクリーンに対する実行トリガーを送信する段階(s49050)、TDO/ファイルをダウンロードする段階(s49060)、RUIを生成する段階(s49070)、RUIプロトコルを通じてRUIを送信する段階(s49080)、スクリーン上にUIをディスプレイする段階(s49090)、ユーザが新しいページに対するリンクをクリックする段階(s49100)、入力データを送信する段階(s49110)、新しいTDO/ファイルをダウンロードする段階(s49120)、RUIをアップデートする段階(s49130)、RUIプロトコルを通じてRUIを送信する段階(s49140)、及び/又はスクリーン上にUIをディスプレイする段階(s49150)を含むことができる。
時間ベーストリガーを送信する段階(s49010)は、受信機がDTVCC又はACRサーバーを通じて時間ベーストリガーを受信する段階を含むことができる。時間ベーストリガーは上述した通りである。
TPTを要求する段階(s49020)は、受信機が、受信されたトリガーを解釈する段階、TPTを取得できるサーバーのURLを取得する段階、及びTPTを要求できる段階を含むことができる。
応答としてTPTを送信する段階(s49030)は、TPTを要求する段階(S49020)における要求に応答してTPTを送信する段階を含むことができる。
TPTをパーシングする段階(s49040)は、受信機が、要求されたTPTをパーシングする段階を含むことができる。
第2スクリーンに対する実行トリガーを送信する段階(s49050)は、受信機がDTVCC又はACRサーバーを通じて第2スクリーンに対する実行トリガーを受信する段階を含むことができる。実行トリガーは、上述した活性化トリガーと同一であってもよい。
TDO/ファイルをダウンロードする段階(s49060)は、受信機が、受信したTPTから実行トリガー又は時間ベーストリガーと関連したTDO及びファイルに関する情報を取得する段階、及びコンテンツサーバーからトリガーで指示されたTDO及びファイルをダウンロードする段階を含むことができる。
RUIを生成する段階(s49070)は、ダウンロードされたTDO及びファイルに対するRUIを生成する段階を含むことができる。
RUIプロトコルを通じてRUIを送信する段階(s49080)は、受信機がRUIプロトコルを用いて、第2スクリーン上に生成されたRUIを送信する段階を含むことができる。
スクリーン上にUIをディスプレイする段階(s49090)は、第2スクリーン上に、受信されたRUIをディスプレイする段階を含むことができる。
ユーザが新しいページに対するリンクをクリックする段階(s49100)は、第2スクリーン上でユーザの選択によってRUI上の特定リンクをクリックする段階を含むことができる。
入力データを送信する段階(s49110)は、クリックされた特定リンクが他のページに接続されると、受信機にユーザの入力情報を伝達する段階を含むことができる。
新しいTDO/ファイルをダウンロードする段階(s49120)は、受信機がユーザ入力と関連したTDO及びファイルをダウンロードする段階を含むことができる。
RUIをアップデートする段階(s49130)は、ダウンロードされたTDO及びファイルによってRUIをアップデートする段階を含むことができる。
RUIプロトコルを通じてRUIを送信する段階(s49140)は、受信機がRUIプロトコルを用いて、アップデートされたRUIを第2スクリーンに送信する段階を含むことができる。
スクリーン上にUIをディスプレイする段階(s49150)は、第2スクリーン上にアップデートされたRUIをディスプレイする段階を含むことができる。
図50は、受信機で第2スクリーンデバイスにUI情報を知らせる方法の実施例を示す図である。
図50は、受信機が放送社からトリガーを受信してトリガーを第2スクリーンデバイスに伝達する論理的順序を示す。
このプロセスは、受信機に対するトリガーを受信する段階(s50010)、第2スクリーンサービスに対するトリガーを受信する段階(s50020)、アップデートされたUI情報に対する通知を送信する段階(s50030)、アップデートされたUI情報を要求する段階(s50040)、応答として互換可能なUI情報を送信する段階(s50050)、及び受信機に対する他のトリガーを受信する段階(s50060)を含むことができる。
受信機に対するトリガーを受信する段階(s50010)は、プライマリデバイスが放送ストリームを通じて放送社から受信機、すなわち、プライマリデバイスに対するトリガーを受信する段階を含むことができる。
第2スクリーンサービスに対するトリガーを受信する段階(s50020)は、プライマリデバイスが放送ストリームを通じて放送社から第2スクリーンサービスに対するトリガーを受信する段階を含むことができる。
アップデートされたUI情報に対する通知を送信する段階(s50030)は、アップデートされたUIに対して通知する段階を含むことができる。上述した通り、放送プログラムを見る間にトリガーが受信されると、受信機は、トリガーが第2スクリーンデバイス又はプライマリデバイスに対するものか否かをチェックすることができる。この時、トリガーが第2スクリーンデバイスに対するものであれば、全てのUPnPデバイス又は特定UPnPデバイスにのみ新しいUI情報アップデートを通知することができる。これは、第2スクリーンデバイスがUPnPプロトコルを用いて加入した場合に該当しうる。
アップデートされたUI情報を要求する段階(s50040)は、第2スクリーンデバイスがプライマリデバイスに、アップデートされたUI情報を要求する段階を含むことができる。
応答として互換可能なUI情報を送信する段階(s50050)は、プライマリデバイスが第2スクリーンデバイスに互換可能なUI情報を送信する段階を含むことができる。
受信機に対する他のトリガーを受信する段階(s50060)は、受信機に対するトリガーを受信する段階と同一であってもよい。すなわち、上述した動作が再び行われてもよい。
受信機がトリガーモジュールを含んでもよいため、受信機は、放送ネットワーク又はインターネットネットワークを通じてTPT及びAMTなどのXMLファイルを受信し、XMLファイルをパーシングし、適切な動作を行うことができる。第2スクリーンデバイスを探すと、第2スクリーンデバイスに伝達されるアクション、TDO URL及びデータは、Event@Destinationフィールドを用いて認識することができる。第2スクリーンデバイスは、TPT及びAMTなどのXMLファイルを直接受信しなくてもよく、よって、トリガーモジュールを含まなくてもよい。RemoteUIクライアントサービスが含まれると、受信機は、全ての第2スクリーンアプリケーションのライフサイクルを管理することができる。逆に、いくつかの第2スクリーンデバイスが接続されると、第2スクリーンアプリケーションを制御するデータが数回送信されなければならない。
図51は、受信機で第2スクリーンデバイスにUI情報を通知する方法の実施例を示す図である。
図50と違い、図51は、第2スクリーンデバイスに適切に用いられると決定された第2スクリーンデバイスに対する全てのUI情報が直接伝達される場合を示す。すなわち、第2スクリーンデバイスに対するTDO URLを送信することができる。
このプロセスは、受信機に対するトリガーを受信する段階(s51010)、第2スクリーンサービスに対するトリガーを受信する段階(s51020)、UI情報に対して通知する段階(s51030)、応答“ok”を送信する段階(s51040)、受信機に対するトリガーを受信する段階(s51050)、受信機に対するトリガーを受信する段階(s51060)、第2スクリーンサービスに対するトリガーを受信する段階(s51070)、UI情報に対して通知する段階(s51080)、及び/又は応答“ok”を送信する段階(s51090)を含むことができる。
受信機に対するトリガーを受信する段階(s51010)は、受信機に対するトリガーを受信する段階(s50010)と同一であってもよい。
第2スクリーンサービスに対するトリガーを受信する段階(s51020)は、第2スクリーンサービスに対するトリガーを受信する段階(s50020)と同一であってもよい。
UI情報に対して通知する段階(s51030)は、UI情報アップデートに対して通知する段階を含むことができる。
応答“ok”を送信する段階(s51040)は、UI通知が受信されたことを示すメッセージを送信する段階を含むことができる。
受信機に対するトリガーを受信する段階(s51050)、及び受信機に対するトリガーを受信する段階(s51060)は、受信機に対するトリガーを受信する段階(s50010)と同一であってもよい。すなわち、上述した動作が再び行われてもよい。
第2スクリーンサービスに対するトリガーを受信する段階(s51070)は、第2スクリーンサービスに対するトリガーを受信する段階(s50020)と同一であってもよい。すなわち、上述した動作が再び行われてもよい。
UI情報に対して通知する段階(s51080)は、UI情報に対して通知する段階(s51030)と同一であってもよい。すなわち、上述した動作が再び行われてもよい。
応答“ok”を送信する段階(s51090)は、応答“ok”を送信する段階(s51040)と同一であってもよい。すなわち、上述した動作が再び行われてもよい。
図51の方法で、受信機は、どのUPnPデバイスが第2スクリーンデバイスであるか、及びいかなるデバイスプロファイルが含まれるかを知っていなければならない。特に、受信機は、第2スクリーンデバイスが第2スクリーンサービスを支援するかを知っていなければならない。
トリガーが第2スクリーンデバイス又はプライマリデバイスに関するものかを決定した後に、UI情報に対して通知する方法、及び第2スクリーンデバイスに適切に用いられると決定された第2スクリーンデバイスに対する全てのUI情報を伝達する方法(図51の場合)は、受信機がTPT及びトリガーを処理し、TDO URLのみを第2スクリーンデバイスに伝達するという点で同一でありうる。これら2つの方法は、受信機がTDOを第2スクリーンデバイスに間接的に伝達したり、受信機が各デバイスのデバイスプロファイルを直接記録し、第2スクリーンデバイスにのみ第2スクリーンアプリケーションの位置を通知するという点で異なりうる。
図52は、RemoteUIサーバーサービスに対する放送シグナリングの実施例を示す図である。
RemoteUIサーバーサービスに対する放送シグナリングの一実施例は、UPnPデバイス及びサービスディスカバリ段階(s52010)、UIListingを要求する段階(s52020)、UIListingを送信する段階(s52030)、イベントを申し込む段階(s52040)、HTTPメッセージを返還する段階(s52050)、UIListingUpdateメッセージを送信する段階(s52060)、UIListingを要求する段階(s52070)及び/又はUIListingを返還する段階(s52080)を含むことができる。
UPnPデバイス及びサービスディスカバリ段階(s52010)は、受信機及び第2スクリーンデバイスを探す段階を含むことができる。ホームネットワークに新しく接続されたデバイス又はホームネットワークに既に接続されたデバイス(受信機又は第2スクリーンデバイス)は、ディスカバリのためのメッセージをマルチキャストすることができる。このとき、所望のサービスをマルチキャスティングを用いて探索することができ、複数の不特定UPnPデバイスに対して全てのサービスを探索することができる。これは、デバイスによってどのサービスが提供されるかによって変更されてもよい。この段階で、第2スクリーンデバイスは、プライマリデバイスのデバイスプロファイルを知っていてもよい。プライマリデバイスは、デバイスプロファイルを処理し、適切なUIListingを生成することができる。RemoteUIサーバーは、CompatibleUIs XSDスキマー(schema)を第2スクリーンデバイスに提供することができる。このスキマーは、アプリケーションのURL、UIに対する固有id(“uiID”)、ネーム、protocolInfoなどを含むことができる。
UIListingを要求する段階(s52020)は、第2スクリーンデバイスが自身のデバイスプロファイルを送信する段階、及びUIListingを要求する段階を含むことができる。互換可能なUIが得られるGetCompatibleUIsアクションを用いることができる(UIFilterは選択的であってもよい)。その詳細な説明は後述する。
UIListingを送信する段階(s52030)は、プライマリデバイスが、要求によって、適切なUIリスティングを第2スクリーンデバイスに送信する段階を含むことができる。その詳細な説明は後述する。
イベントを申し込む段階(s52040)は、プライマリデバイスの適切な露出されたイベントを申し込む段階を含むことができる。イベントを申し込む段階(s52040)は、RemoteUIサーバーサービスによって提供されたイベント情報である“UIListingUpdate”を受信するために選択的に行うことができる。In UIListingを返還する段階(s52080)で、第2スクリーンデバイスは、RemoteUIのアドレスが変更されたり又はUIが変更されたという通知を受けることができる。すなわち、第2スクリーンデバイスがUIが変更された通知のみを受けるから、詳細な位置又は追加の情報が要求されると、“GetCompatibleUIs”アクションが受信機に送信され、“UIListing”値を得ることができる。
HTTPメッセージを返還する段階(s52050)は、イベントを申し込む段階(s52040)の結果を送信する段階を含むことができる。応答1を送信する段階(s40100)と同様に、HTTP/1.1 200 OKなどの応答が状況によって伝送されうる。
UIListingUpdateメッセージを送信する段階(s52060)は、加入者に“UIListingUpdate”メッセージを送信する段階を含むことができる。
UIListingを要求する段階(s52070)は、第2スクリーンデバイスが自身のデバイスプロファイルを送信する段階、及びUIListingを要求する段階を含むことができる。互換可能なUIが得られるGetCompatibleUIsアクションを用いることができる。UIListingUpdateメッセージを送信する段階(s52060)及びUIListingを要求する段階(s52070)は、第2スクリーンアプリケーションが変更されず、サーバーによって支援される時にのみ選択的に可能なように時間設定を行う段階を含むことができる。この段階は選択的だ。この方法は、受信機でUPnPイベントを用いて、第2スクリーンサービスが存在することを全ての第2スクリーンデバイスに通知する方法であってもよい。すなわち、ホームネットワーク内の全ての第2スクリーンデバイスは第2スクリーンサービスと関連してUIが変更されたとの通知を受けることができる。全ての第2スクリーンデバイスにUPnPイベントにて“UIListingUpdate”変数が通知されると、第2スクリーンデバイスは、UIが新しくアップデートされたということを確認することができる。その後、第2スクリーンデバイスは、“GetCompatibleUIs”アクションを行い、ハードウェア装置に適したUIを選択し、デバイスプロファイルを参考にすることによってUIを実行することができる。
UIListingを返還する段階(s52080)は、プライマリデバイスが要求によって適切なUIリスティングを第2スクリーンデバイスに送信する段階を含むことができる。上述した通り、UIListingを返還する段階(s52080)は、RemoteUIのアドレスが変更されたりUIが変更されたことを申請した第2スクリーンデバイスに通知する段階を含むことができる。すなわち、第2スクリーンデバイスは、UIが変更されたことのみが通知されるため、詳細な位置又は追加の情報が要求されると、“UIListing”を得るために“GetCompatibleUIs”アクションを受信機に送信しなければならない。
RemoteUIサーバーサービスが動作すると、受信機は、要求する装置のデバイスプロファイルによって遠隔UI情報を提供しなければならない。逆互換性の観点から、デバイスプロファイル“DeviceInfo”が交換され、後で受信機に“GetCompatibleUIs”アクションを要求する時、RemoteUIサーバーサービスによって送信されたURLが、要求するクライアントのプロファイルによって変更されうる。レガシーUPnPデバイスがRemoteUIサーバーに“GetCompatibleUIs”アクションを要求すると、レガシーUPnPデバイスのDeviceInfoに適したUIが提供されなければならない。しかし、第2スクリーンサービスを支援するデバイスが“GetCompatibleUIs”アクションを要求すると、RemoteUIサーバーサービス装置はさらにURL情報を送信しなければならない。
受信機は、DTVCCを通じてトリガー情報を得、トリガー情報からメディア時間及びイベント時間情報を得ることができる。このとき、“appID”、“URL”(TDO_URL)、“eventID”、“action”、及び、選択的に、TDO又は実行時間に対する“Data”は、“t=media_time”シンタックスを用いて確認できる。受信機が第2スクリーンアプリケーションのライフサイクルを管理すると、第2スクリーンサービスアプリケーションによって処理される情報の量が減少しうる。逆に、第2スクリーンサービスアプリケーションが第2スクリーンアプリケーションのライフサイクルを直接管理すると、必要な情報が増加しうる。
図53は、分散型実行モデルの動作概念を示す図である。
第2スクリーンデバイスにインタラクティブサービスを効率的に伝達する方法として、分散型実行モデルを説明する。
分散型実行モデルの動作概念を示す図に示すように、TV受像機は、UPnPなどを用いて第2スクリーンデバイスにトリガーなどの情報を伝達することができる。それぞれの第2スクリーンデバイスはトリガーハンドラーを有し、トリガーハンドラーを通じて受信されたトリガーなどの情報を実時間で処理することができる。ブラウザは、それと関連したインタラクティブサービスを実行することができる。
中央集中型実行モデルと違い、各第2スクリーンデバイスにDAEが存在してもよい。
分散型実行モデルに基づいて第2スクリーンデバイスにインタラクティブサービスを伝達するプロセスは、次の順序で行うことができる。1.受信機は、第2スクリーン支援を有するセグメントを提示している。2.受信機は、第2スクリーン支援が利用可能な任意の指示をディスプレイする。3.ユーザは、第2スクリーンデバイス上で第2スクリーンアプリケーションを開始する。4.受信機及び第2スクリーンデバイスは、(受信機上のネイティブコード及びデバイス上の第2スクリーンアプリケーションによって行われる)UPnPメカニズムを通じてお互い発見する。5.TV受像機は、(DTVCCストリーム又はACRから)トリガーを得、第2スクリーンデバイス上でTDOを開始する。6.TV受像機は、トリガーをTPTからの情報と結合し、活性化時間に第2スクリーンデバイスに送信する。7.第2スクリーンデバイスは、TDO(一つ以上のファイル)をダウンロードしてブラウザで実行する。8.ユーザはTDOと相互作用してTDOが追加のファイルをダウンロードてきるようにする。9.受信機は、トリガーを得、第2スクリーンデバイス上でTDOに対するイベントを生成する。10.受信機はトリガーとTPTからの情報とを結合し、活性化時間に第2スクリーンデバイスに送信する。11.第2スクリーンデバイスは、ブラウザでTDOに対する(DVB StreamEventのような)TriggerEventを生成する。12.TDOは、TriggerEventによって要求されたアクションを行ってデータファイルをダウンロードすることができる。
図54は、分散型実行モデルベース受信機及び第2スクリーン間の連動に対するフローを示す図である。
分散型実行モデルのフローは、受信機がDTVCC又はACRサーバーを通じて受信された情報をそのまま第2スクリーンに送信する場合のデータフローであってもよい。以下、詳細なフローを説明する。
分散型実行モデルベース受信機及び第2スクリーン間の連動に対するフローの実施例は、時間ベーストリガーを送信する段階(s54010)、時間ベーストリガーを送信する段階(s54020)、TPTを要求する段階(s54030)、TPTを応答として送信する段階(s54040)、TPTをパーシングする段階(s54050)、第2スクリーンに対する実行トリガーを送信する段階(s54060)、実行トリガーを送信する段階(s54070)、TDO/ファイルをダウンロードする段階(s54080)、ブラウザでTDOを実行する段階(s54090)、ユーザが新しいページに対するリンクをクリックする段階(s54100)、新しいTDO/ファイルをダウンロードする段階(s54110)、及びブラウザで新しいTDOを実行する段階(s54120)を含むことができる。
時間ベーストリガーを送信する段階(s54010)は、時間ベーストリガーを送信する段階(s49010)と同一であってもよい。
時間ベーストリガーを送信する段階(s54020)は、受信機が受信されたトリガーをそのまま第2スクリーンに送信する段階を含むことができる。
TPTを要求する段階(s54030)は、第2スクリーンが受信されたトリガーを解釈する段階、TPTが得られるサービスのURLを取得する段階、及びTPTを要求できる段階を含むことができる。
応答としてTPTを送信する段階(s54040)は、TPTを要求する段階(s54030)における要求に応答してTPTを送信する段階を含むことができる。
TPTをパーシングする段階(s54050)は、要求されたTPTをパーシングする段階を含むことができる。
第2スクリーンに対する実行トリガーを送信する段階(s54060)は、第2スクリーンに対する実行トリガーを送信する段階(s49050)と同一であってもよい。
実行トリガーを送信する段階(s54070)は、受信機が受信されたトリガーをそのまま第2スクリーンに送信する段階を含むことができる。
TDO/ファイルをダウンロードする段階(s54080)は、TPTからのトリガーと関連したTDO/ファイルを得る段階、及びコンテンツサーバーからTDO/ファイルをダウンロードする段階を含むことができる。
ブラウザでTDOを実行する段階(s54090)は、ダウンロードされたTDO及びファイルをブラウザ上で実行する段階を含むことができる。
ユーザが新しいページに対するリンクをクリックする段階(s54100)は、ユーザが、実行されたTDO上で特定リンクをクリックする段階を含むことができる。
新しいTDO/ファイルをダウンロードする段階(s54110)は、他のTDOへの特定リンクが確立されると、関連したTDO/ファイルをダウンロードする段階を含むことができる。
ブラウザで新しいTDOを実行する段階(s54120)は、ブラウザ上で関連したTDO及びファイルを実行する段階を含むことができる。
図55は、分散型実行モデルベース受信機及び第2スクリーン間の連動に対するフローを示す図である。
分散型実行モデルのフローは、受信機がDTVCC又はACRサーバーを通じて受信された情報をそのまま第2スクリーンに送信せず、第2スクリーンに適したトリガーによって必要な情報を挿入し、その情報を拡張されたトリガーに変更し、その情報を第2スクリーンに送信する場合のデータフローであってもよい。以下、詳細なフローを説明する。
分散型実行モデルベース受信機及び第2スクリーン間の連動に対するフローの実施例は、時間ベーストリガーを送信する段階(s55010)、TPTを要求する段階(s55020)、応答としてTPTを送信する段階(s55030)、TPTをパーシングする段階(s55040)、第2スクリーンに対する実行トリガーを送信する段階(s55050)、拡張されたトリガーを生成する段階(s55060)、拡張されたトリガーを送信する段階(s55070)、TDO/ファイルをダウンロードする段階(s55080)、ブラウザでTDOを実行する段階(s55090)、ユーザが新しいページに対するリンクをクリックする段階(s55100)、新しいTDO/ファイルをダウンロードする段階(s55110)、及び/又はブラウザで新しいTDOを実行する段階(s55120)を含むことができる。
時間ベーストリガーを送信する段階(s55010)は、時間ベーストリガーを送信する段階(s54010)と同一であってもよい。
TPTを要求する段階(s55020)は、TPTを要求する段階(s54030)と同一であってもよい。
応答としてTPTを送信する段階(s55030)は、応答としてTPTを送信する段階(s54040)と同一であってもよい。
TPTをパーシングする段階(s55040)は、TPTをパーシングする段階(s54050)と同一であってもよい。
第2スクリーンに対する実行トリガーを送信する段階(s55050)は、第2スクリーンに対する実行トリガーを送信する段階(s54060)と同一であってもよい。
拡張されたトリガーを生成する段階(s55060)は、受信機がTPTからのトリガーと関連したTDO及びファイルに関する情報を取得する段階、及びそれを含む拡張されたトリガーを生成する段階を含むことができる。
拡張されたトリガーを送信する段階(s55070)は、受信機が拡張されたトリガーを第2スクリーンに送信する段階を含むことができる。
TDO/ファイルをダウンロードする段階(s55080)は、TDO/ファイルをダウンロードする段階(s54080)と同一であってもよい。
ブラウザでTDOを実行する段階(s55090)は、ブラウザでTDOを実行する段階(s54090)と同一であってもよい。
ユーザが新しいページに対するリンクをクリックする段階(s55100)は、ユーザが新しいページに対するリンクをクリックする段階(s54100)と同一であってもよい。
新しいTDO/ファイルをダウンロードする段階(s55110)は、新しいTDO/ファイルをダウンロードする段階(s54110)と同一であってもよい。
ブラウザで新しいTDOを実行する段階(s55120)は、ブラウザで新しいTDOを実行する段階(s54120)と同一であってもよい。
図56は、受信機が第2スクリーンデバイスにTDO及びイベント情報を通知する方法の一実施例を示す図である。
図56は、受信機がトリガー及びTPTを受信し、トリガーによって処理を行い、第2スクリーンデバイスに対するトリガーが到達すると、トリガーをTPTと比較して、第2スクリーンデバイスに認識される必要がある情報を抽出してXMLファイルの形態で構成し、その情報を第2スクリーンデバイスに送信する方法を示す。この方法は、第2スクリーンデバイスが活発に動作して予測を行えるという点で有利である。
このプロセスは、受信機に対するトリガーを受信する段階(s56010)、第2スクリーンデバイスに対するトリガーを受信する段階(s56020)、TPT及びトリガーを変換(translate)し、イベント情報を生成する段階(s56030)、TDO及びイベント情報を送信する段階(s56040)、応答“ok”を送信する段階(s56050)、受信機に対するトリガーを受信する段階(s56060)、受信機に対するトリガーを受信する段階(s56070)、第2スクリーンデバイスに対するトリガーを受信する段階(s56080)、TPT及びトリガーを変換してイベント情報を生成する段階(s56090)、TDO及びイベント情報を送信する段階(s56100)、及び応答“ok”を送信する段階(s56110)を含むことができる。
受信機に対するトリガーを受信する段階(s56010)は、受信機に対するトリガーを受信する段階(s50010)と同一であってもよい。
第2スクリーンデバイスに対するトリガーを受信する段階(s56020)は、第2スクリーンデバイスに対するトリガーを受信する段階(s50020)と同一であってもよい。
TPT及びトリガーを変換してイベント情報を生成する段階(s56030)は、TPT及びトリガーを解釈する段階、及びイベントを生成する段階を含むことができる。生成された情報は、新しいデータ構造を生成するために、TPTに含まれた情報及びトリガーを結合するのに用いられ、どのようなTDOが生成されたか、又はいつTDOが生成されたかに関する情報を含むことができる。このデータ構造は後述する。新しいデータ構造が決定されると、TDO URLに加えて、様々な必要な情報が送信されうる。
TDO及びイベントを送信する段階(s56040)は、生成されたイベント情報及びTDOを第2スクリーンデバイスに送信する段階を含むことができる。
応答“ok”を送信する段階(s56050)は、受信されたTDO及びイベント情報が受信されたことを示すメッセージを送信する段階を含むことができる。
受信機に対するトリガーを受信する段階(s56060)、及び受信機に対するトリガーを受信する段階(s56070)は、受信機に対するトリガーを受信する段階(s50010)と同一であってもよい。
第2スクリーンデバイスに対するトリガーを受信する段階(s56080)は、第2スクリーンデバイスに対するトリガーを受信する段階(s50020)と同一であってもよい。
TPT及びトリガーを変換してイベント情報を生成する段階(s56090)は、TPT及びトリガーを変換してイベント情報を生成する段階(s56030)と同一であってもよい。
TDO及びイベント情報を送信する段階(s56100)は、TDO及びイベント情報を送信する段階(s56040)と同一であってもよい。
応答“ok”を送信する段階(s56110)は、応答“ok”を送信する段階(s56050)と同一であってもよい。
受信機に対するトリガーを受信する段階(s56060)、受信機に対するトリガーを受信する段階(s56070)、第2スクリーンデバイスに対するトリガーを受信する段階(s56080)、TPT及びトリガーを変換してイベント情報を生成する段階(s56090)、TDO及びイベント情報を送信する段階(s56100)、及び応答“ok”を送信する段階(s56110)は、上述した動作と同一であってもよい。
図57は、第2スクリーンデバイスがTPT及び第2スクリーンアプリケーションにアクセスする方法の実施例を示す図である。
第2スクリーンデバイスは、受信機がTPT及びAMTなどのXMLファイルを受信したり、インターネットを通じてTPT及びAMTサーバーアドレスを知ると、第2スクリーンアプリケーションを直接実行できる独立装置である。この場合、トリガーモジュールが第2スクリーンデバイスに含まれる。第2スクリーンデバイスは、受信機によって受信されたiTVメッセージに対するURIストリングを受信することができる。このメッセージは、1)RemoteUIサーバーサービスの場合、iTVメッセージ(トリガー)に対するURIストリングを送信する方法、及び2)RemoteUIクライアントサービスの場合、iTVメッセージ(トリガー)に対するURIストリングを送信する方法の両方に適用することができる。
まず、RemoteUIサーバーサービスの場合、iTVメッセージ(トリガー)に対するURIストリングを送信する方法を説明する。
このプロセスは、受信機に対するトリガーを受信する段階(s57010)、第2スクリーンサービスに対するトリガーを受信する段階(s57020)、アップデートされたUI情報に関する通知を送信する段階(s57030)、アップデートされたUI情報を要求する段階(s57040)、応答としてUI情報を送信する段階(s57050)、TPT XMLファイルを要求する段階(s57060)、TPT XMLファイルを返還する段階(s57070)、第2スクリーンサービスに対するトリガーを受信する段階(s57080)、アップデートされたUI情報に対する通知を送信する段階(s57090)、アップデートされたUI情報を要求する段階(s57100)、応答としてUI情報を送信する段階(s57110)、第2スクリーンサービスに対するトリガーを受信する段階(s57120)、アップデートされたUI情報に対する通知を送信する段階(s57130)、アップデートされたUI情報を要求する段階(s57140)、応答としてUI情報を送信する段階(s57150)、第2スクリーンアプリケーションを要求する段階(s57160)、及び/又は第2スクリーンアプリケーションを返還する段階(s57170)を含むことができる。
受信機に対するトリガーを受信する段階(s57010)は、受信機に対するトリガーを受信する段階(s50010)と同一であってもよい。第1トリガーは、第2スクリーンデバイスに対するものでないから、受信機はトリガーを第2スクリーンデバイスに伝達しない。
第2スクリーンサービスに対するトリガーを受信する段階(s57020)は、第2スクリーンサービスに対するトリガーを受信する段階(s50020)と同一であってもよい。トリガーは、第2スクリーンサービスに対するメディア時間に関する情報を有することができる。第2トリガーは、上述したプリロード(pre−load)トリガーとして機能し得る。
アップデートされたUI情報に対する通知を送信する段階(s57030)は、アップデートされたUI情報を通知する段階を含むことができる。第2トリガーは、第2スクリーンデバイスに対するものであるから、受信機は受信されたURIStringを第2スクリーンデバイスに送信することができる。このとき、第2スクリーンデバイスは、新しい情報が存在するという通知を受けることができ、この情報を直接読み取ることができる。
アップデートされたUI情報を要求する段階(s57040)は、アップデートされたUI情報を要求する段階(s50040)と同一であってもよい。
応答としてUI情報を送信する段階(s57050)は、プライマリデバイスがUI情報を第2スクリーンデバイスに送信する段階を含むことができる。この時、第2トリガーが送信されてもよい。
TPT XMLファイルを要求する段階(s57060)は、第2スクリーンデバイスがプライマリデバイスから受信された情報(第2トリガー)をパーシングする段階、及びTPTサーバーにTPT XMLファイルを要求する段階を含むことができる。
TPT XMLファイルを返還する段階(s57070)は、第2スクリーンデバイスがTPTサーバーから要求されたTPT XMLファイルをダウンロードする段階を含むことができる。
第2スクリーンサービスに対するトリガーを受信する段階(s57080)は、第2スクリーンサービスに対するトリガーを受信する段階(s50020)と同一であってもよい。第3トリガーは、第2スクリーンデバイスと関連しており、メディア時間に関する情報を有することができる。第3トリガーは、上述した時間ベーストリガーと同一の機能を有し得るメディア時間トリガーである。
アップデートされたUI情報に関する通知を送信する段階(s57090)は、アップデートされたUI情報を通知する段階を含むことができる。第3トリガーが第2スクリーンデバイスと関連したものとと決定されるため、受信機は、第3トリガーを第2スクリーンデバイスに通知することができる。
アップデートされたUI情報を要求する段階(s57100)は、アップデートされたUI情報を要求する段階(s50040)と同一であってもよい。
応答としてUI情報を送信する段階(s57110)は、プライマリデバイスがUI情報を第2スクリーンデバイスに送信する段階を含むことができる。このとき、第3トリガーが送信されてもよい。しかし、第3トリガーは、メディア時間トリガーであるから、第2スクリーンデバイスのメディア時間のみを制御することができる。このため、第2スクリーンデバイス及び受信機間のメディア時間同期化を行うことができる。
第2スクリーンデバイスに対するトリガーを受信する段階(s57120)は、第2スクリーンデバイスに対するトリガーを受信する段階(s50020)と同一であってもよい。第4トリガーは、第2スクリーンデバイスと関連しており、イベント時間に関する情報を有することができる。第4トリガーは、上述した活性化トリガーと同一の機能を有し得るイベント時間トリガーである。
アップデートされたUI情報に対する通知を送信する段階(s57130)は、アップデートされたUIを通知する段階を含むことができる。第4トリガーは、第2スクリーンデバイスと関連したものと決定されるため、受信機は第2スクリーンデバイスに第4トリガーを通知することができる。
アップデートされたUI情報を要求する段階(s57140)は、アップデートされたUI情報を要求する段階(s50040)と同一であってもよい。
応答としてUI情報を送信する段階(s57150)は、プライマリデバイスがUI情報を第2スクリーンデバイスに送信する段階を含むことができる。このとき、第4トリガーが送信されてもよい。
第2スクリーンアプリケーションを要求する段階(s57160)は、第2スクリーンデバイスが第4トリガーに関する情報をチェックする段階、及びTDO URLの位置の第2スクリーンアプリケーションをダウンロードするためにアプリケーションサーバーに第2スクリーンアプリケーションを要求する段階を含むことができる。
第2スクリーンアプリケーションを返還する段階(s57170)は、要求によって第2スクリーンアプリケーションをダウンロードする段階を含むことができる。第2スクリーンアプリケーションがダウンロードされ、Event@Actionを行うことができる。このとき、アプリケーションサーバーに第2スクリーンデバイスのブラウザに関する情報を通知するので、アプリケーションサーバーは、どの第2スクリーンデバイスが接続されるかを容易にチェックすることができる。したがって、アプリケーションは自動で選択され、サーバーからダウンロードされることが可能である。
要約すると、iTVメッセージに対するURIストリングがDTVCCを通じて受信されると、受信機は、新しいUIがアップデートされたということを示すイベントを、発見された第2スクリーンデバイスに送信することができる。第2スクリーンデバイスは、イベント情報をチェックし、新しいUI情報を得るために“GetCompatibleUIs”アクションを送信することができる。受信機は、TPTサーバーの受信されたURI情報を送信することができる。この方法によって、第2スクリーンデバイスはURI情報を受信し、TPT及びAMT情報を直接処理し、第2スクリーンアプリケーションを直接制御することができる。
このプロセスは、ATSC2.0トリガークライアントが第2スクリーンサービスアプリケーションに含まれる場合に可能である。
図58は、第2スクリーンデバイスがTPT及び第2スクリーンアプリケーションをアクセスする方法の実施例を示す図である。
上述した2つの方法のうち、RemoteUIクライアントサービスの場合にiTVメッセージ(トリガー)に対するURIストリングを送信する方法を説明する。
このプロセスは、受信機に対するトリガーを受信する段階(s58010)、第2スクリーンサービスに対するトリガーを受信する段階(s58020)、トリガーを通知する段階(s58030)、応答“ok”を送信する段階(s58040)、TPT XMLファイルを要求する段階(s58050)、TPT XMLファイルを返還する段階(s58060)、第2スクリーンデバイスに対するトリガーを受信する段階(s58070)、トリガーを通知する段階(s58080)、応答“ok”を送信する段階(s58090)、第2スクリーンサービスに対するトリガーを受信する段階(s58100)、トリガーを通知する段階(s58110)、応答“ok”を送信する段階(s58120)、第2スクリーンアプリケーションを要求する段階(s58130)及び/又は第2スクリーンアプリケーションを返還する段階(s58140)を含むことができる。
受信機に対するトリガーを受信する段階(s58010)は、プライマリデバイスが放送ストリームを通じて放送社から受信機、すなわち、プライマリデバイスに対するトリガーを受信する段階を含むことができる。第1トリガーが受信機に対するものであるから、第1トリガーは第2スクリーンデバイスに伝達されない。
第2スクリーンサービスに対するトリガーを受信する段階(s58020)は、第2スクリーンサービスに対するトリガーを受信する段階(s50020)と同一であってもよい。第2トリガーは、第2スクリーンサービスに対するトリガーであり、メディア時間に関する情報を有することができる。第2トリガーは、上述したプリロードトリガーとして機能し得る。
トリガーを通知する段階(s58030)は、図57と違い、第2スクリーンデバイスに直ちにトリガーを送信する段階を含むことができる。iTVメッセージに対するURIストリングがDTVCCを通じて受信されると、受信機は、“AddUIListing”アクションを用いて、受信機によって受信されたURI値を第2スクリーンデバイスに伝達することができる。
応答“ok”を送信する段階(s58040)は、トリガーが受信されたことを示すメッセージを送信する段階を含むことができる。
TPT XMLファイルを要求する段階(s58050)は、TPT XMLファイルを要求する段階(s57060)と同一であってもよい。第2スクリーンデバイスに含まれるトリガーモジュールは、受信されたURI値を用いてTPTサーバーにアクセスし、TPT及びAMTファイルをダウンロードし、第2スクリーンアプリケーションを直接制御することができる。
TPT XMLファイルを返還する段階(s58060)は、TPT XMLファイルを返還する段階(s57070)と同一であってもよい。
第2スクリーンサービスに対するトリガーを受信する段階(s58070)は、第2スクリーンサービスに対するトリガーを受信する段階(s50020)と同一であってもよい。第3トリガーは、第2スクリーンデバイスと関連しており、メディア時間に関する情報を有することができる。第3トリガーは、上述した時間ベーストリガーと同一の機能を有し得るメディア時間トリガーである。
トリガーを通知する段階(s58080)は、トリガーを通知する段階(s58030)と同様に、トリガーを伝達する段階を含むことができる。
応答“ok”を送信する段階(s58090)は、応答“ok”を送信する段階(s58040)と同一であってもよい。
第2スクリーンサービスに対するトリガーを受信する段階(s58100)は、第2スクリーンサービスに対するトリガーを受信する段階(s50020)と同一であってもよい。第4トリガーは、第2スクリーンデバイスと関連しており、イベント時間に関する情報を有することができる。第4トリガーは、上述した活性化トリガーと同一の機能を有し得るイベント時間トリガーである。
トリガーを通知する段階(s58110)は、トリガーを通知する段階(s58030)と同様に、トリガーを伝達する段階を含むことができる。
応答“ok”を送信する段階(s58120)は、応答“ok”を送信する段階(s58040)と同一であってもよい。
第2スクリーンアプリケーションを要求する段階(s58130)は、第2スクリーンアプリケーションを要求する段階(s57160)と同一であってもよい。
第2スクリーンアプリケーションを返還する段階(s58140)は、第2スクリーンアプリケーションを返還する段階(s57170)と同一であってもよい。
すなわち、受信機は、常に、第2スクリーンサービスと関連したイベント情報を有するトリガーを第2スクリーンデバイスに伝達することができ、第2スクリーンデバイスは、ダウンロードされたTPT情報を用いて直ちに動作することができる。メディア時間トリガーがDTVCCを用いて周期的に伝達されるため、受信機は、この情報を連続して伝達しなければならない。
プライマリデバイス又は第2スクリーンデバイスがTPT XMLを有するので、イベントトリガーがライブトリガーサーバーから実時間で伝送される時にAMTも受信されうる。
上述した2つの方法は、いかなるURL値が適用されるかによって異なるように行われ、受信機の動作又は第2スクリーンサービスアプリケーションの構造及び動作は変更されてもよい。
第2スクリーンサービスのシグナリングメカニズムを説明する。
第2スクリーンサービスは、2つの方法、すなわち、受信機が、第2スクリーンサービスが存在するということを通知する第1方法、及び第2スクリーンデバイスがホームネットワークに接続されると、第2スクリーンサービスを提供する電子装置を検出するために装置及びサービスを探す第2方法を用いてシグナルすることができる。代案として、受信機は、新しい電子装置のデバイス記述語を確認し、サービス記述語を要求することができる。
以下、放送シグナリング及びユニキャストシグナリングを説明する。
放送シグナリングの場合、第2スクリーンデバイスは、RemoteUIサーバーサービスを検出し、デバイス記述語を確認し、第2スクリーンデバイスと互換可能なDeviceInfoプロファイルを要求する。イベントを受信でき、受信機に見られるプログラムによって変更されるTDO(インタラクティブアプリケーション)のURLを受信することができる。
逆に、ユニキャストシグナリングの場合、受信機は、第2スクリーンデバイスのDeviceInfoが互換可能か否かを確認し、互換可能なTDO URLを送信することができる。RemoveUIListingアクションは、現在実行される第2スクリーンアプリケーションを終了してディスプレイメッセージなどのアクションを支援し、現在実行されるUIを終了するように送信されうる。受信機でパーシングされ処理される追加のEvent@dataが、ProcessInputアクションによって第2スクリーンサービスアプリケーションに伝達されうる。
以下、放送シグナリング及びユニキャストシグナリングを説明する。
図59は、RemoteUIサーバーサービスに対する放送シグナリングの他の実施例である。
放送シグナリングで、最初に受信機がホームネットワークに接続されると、自身のデバイス記述語とサービス記述語を全ての家電機器に自分で知らせたり、他の制御ポイントからの要求に応じて送信することができる。
RemoteUIサーバーサービスに対する放送シグナリングの他の実施例は、UPnPデバイス及びサービスディスカバリ段階(s59010)、UIListingを送信する段階(s59020)、UIListingを送信する段階(s59030)、UIListingを要求する段階(s59040)、及び/又はUIListingを返還する段階(s59050)を含むことができる。
UPnPデバイス及びサービスディスカバリ段階(s59010)は、UPnPデバイス及びサービスディスカバリ段階(s58010)と同一の段階であってもよい。
UIListingを送信する段階(s59020)は、“UIListingUpdate”メッセージを全てのUPnPデバイスに送信する段階であってもよい。プライマリデバイスは、UIListingUpdateのアナウンスメント(announcement)を、固有“uiID”リストを有するUPnPデバイスに送信することができる。第2スクリーンデバイスは、このメッセージを受けた後、uiIDをチェックすることができる。しかし、特定uiIDとマッチングされず、この第2ストリーム装置ではUIアップデートが行われなくてもよい。
UIListingを送信する段階(s59030)は、“UIListingUpdate”メッセージを全てのUPnPデバイスに送信する段階であってもよい。この時は、UIListingを送信する段階(s59020)の場合とは違い、マッチングされるuiIDが存在し得る。
UIListingを要求する段階(s59040)は、UIListingを送信する段階(s59030)でuiIDがマッチングされるため、第2スクリーンデバイスが自身のデバイスプロファイルを送信し、UIListingを要求することができる。互換可能なUIを取得できるGetCompatibleUIsアクションを用いることができる。
UIListingを返還する段階(s59050)は、プライマリデバイスが第2スクリーンデバイスに、要求に応じた適切なUI Listingを送信する段階であってもよい。
図60は、第2スクリーンサービスのための装置ディスカバリ及び装置能力交換の一実施例である。
前述したとおり、最初に受信機がホームネットワークに接続されると、自身のデバイス記述語とサービス記述語を全ての家電機器に自分で知らせたり、他の制御ポイントからの要求に応じて送信することができる。
受信機のデバイス記述語とサービス記述語を受信した、全てのホームネットワークに接続したUPnPデバイスは、自身のデバイス記述語の位置をHTTPの“LOCATION”ヘッダーで送ることができる。すなわち、UPnPデバイス記述語の位置を送信して自身を知らせることができる。“LOCATION”にHTTP GET要求をすると、当該装置に関する情報がわかるXMLファイルを受信することができる。
UPnPデバイス及びサービスディスカバリ過程で、プライマリデバイスが、第2スクリーンサービスが可能な第2スクリーンデバイスを探す方法を紹介する。この方法は、2つに大別することができる。その第一は、第2スクリーンデバイスが2種類のデバイスプロファイルを準備しておき、このデバイスプロファイルのXMLファイルをHTTPヘッダーで知らせる方法である。このとき、互換されないプライマリデバイスは、理解できないHTTPヘッダーはそのまま無視すると仮定することができる。その第二は、デバイスプロファイルのうち、第2スクリーンサービスを提供する第2スクリーンデバイスという情報を“Protocol Info”に含む方法である。
図60は、第一の方式を例示するものである。
第2スクリーンサービスに対する装置ディスカバリ及び装置能力交換の一実施例は、第2スクリーンサービスに対するUPnPアプリケーションを実行する段階(s60001)、UPnPデバイスを探す段階(s60010)、RemoteUIClientを探す段階(s60020)、デバイス記述を要求する段階(s60030)、デバイス記述を受信する段階(s60040)、サービス制御記述(description)を要求する段階(s60050)、サービス制御記述を受信する段階(s60060)、デバイスプロファイルを要求する段階(s60070)、デバイスプロファイルを受信する段階(s60080)、遠隔UIのURLを送る(put)段階(s60090)、応答1を送信する段階(s60100)、RemoteUIクライアントサービスにメッセージを送信する段階(s60110)、応答2を送信する段階(s60120)、及び/又はユーザがスクリーン上のボタンをクリックする段階(s60130)を含むことができる。
第2スクリーンサービスに対するUPnPアプリケーションを実行する段階(s60001)、UPnPデバイスを探す段階(s60010)、RemoteUIClientを探す段階(s60020)、デバイス記述を要求する段階(s60030)、デバイス記述を受信する段階(s60040)、サービス制御記述を要求する段階(s60050)、サービス制御記述を受信する段階(s60060)、デバイスプロファイルを要求する段階(s60070)、デバイスプロファイルを受信する段階(s60080)、遠隔UIのURLを送る(put)段階(s60090)、応答1を送信する段階(s60100)、RemoteUIクライアントサービスにメッセージを送信する段階(s60110)、応答2を送信する段階(s60120)、及びユーザがスクリーン上のボタンをクリックする段階(s60130)は、それぞれ順に、第2スクリーンサービスに対するUPnPアプリケーションを実行する段階(s40001)、UPnPデバイスを探す段階(s40010)、RemoteUIClientを探す段階(s40020)、デバイス記述を要求する段階(s40030)、デバイス記述を受信する段階(s40040)、サービス制御記述を要求する段階(s40050)、サービス制御記述を受信する段階(s40060)、デバイスプロファイルを要求する段階(s40070)、デバイスプロファイルを受信する段階(s40080)、遠隔UIのURLを送る(put)段階(s40090)、応答1を送信する段階(s40100)、RemoteUIクライアントサービスにメッセージを送信する段階(s40110)、応答2を送信する段階(s40120)、及びユーザがスクリーン上のボタンをクリックする段階(s40130)と同一の段階であってもよい。
第一の方式は、図60に示すように、UPnPデバイスを探す段階(s60010)段階後にHTTPヘッダーから得る“X−ATSC−COMPANION−LOCATION”ヘッダーで第2スクリーンサービスを支援するデバイスプロファイルの位置を知らせることができる。X−ATSC−COMPANION−LOCATION:http://10.177.56.36:37900/ATSC2ndScreenRemoteUIClient1.xml\r\nと表示された部分が“X−ATSC−COMPANION−LOCATION”ヘッダーである。受信機は、“LOCATION”ヘッダーは無視し、その代わりに“X−ATSC−COMPANION−LOCATION”ヘッダーから、受信機の所望する情報である第2スクリーンデバイスのデバイスプロファイルを得ることができる。
プライマリデバイスが、第2スクリーンサービスが可能な第2スクリーンデバイスを探す方法のうち、前述した第二の方式は、“LOCATION”ヘッダーの位置でデバイスプロファイルを得、デバイスプロファイル内で第2スクリーンデバイスの“Protocol Info”エレメントの値をパーシングして処理することができる。これは、前述したRemoteUIサーバーサービス#1に対する放送シグナリングの一実施例のうち、UIListing要求(s58020)段階で行うことができる。
特定UPnPデバイスのデバイス記述語には提供可能なサービスのリストがあり、一つ或いは複数個のサービスを提供するという事実がわかる。UPnPデバイスが有しているそれぞれのサービスは、遠隔の他のUPnPデバイスで制御可能であり、イベントを受信することができる。ただし、イベント受信は、提供するサービスがイベントで知らせ得る機能がある場合にのみ可能である。UPnPデバイスが提供するサービスは、“制御”,“コントロール”そして“イベント”ができるようにURLを知らせることができる。
図61は、UPnPフォーラムのDeviceProfile XMLスキマーの一実施例である。
前述したRemoteUIサーバーサービス#1に対する放送シグナリングの一実施例のうち、UIListing要求(s58020)段階についてさらに説明する。この段階は、第2スクリーンデバイスからRemoteUIサーバーサービスのある受信機に、第2スクリーンデバイスに合う条件のUIがあるか問うことであり、“InputDeviceProfile”には、図61のようなXSDファイルのような形式を有しなければならない。
したがって、第2スクリーンデバイスは受信機に、図61のような形式で自身のデバイスプロファイルと合う情報を入れて送信しなければならない。
図62は、第2スクリーンデバイスのデバイスプロファイルの一実施例である。
前述したRemoteUIサーバーサービス#1に対する放送シグナリングの一実施例のうち、UIListing要求(s58020)段階についてさらに説明する。この段階で、図62は、デバイスプロファイルの一例を示している。UIListing要求(s58020)段階で、図示のデバイスプロファイルのような情報を受信機に送ることができる。
第2スクリーンデバイスが探そうとするデバイスプロファイルの第2スクリーンサービスが、受信機にあるか否かを検索することであり、図示の情報を“InputDeviceProfile”変数に格納して送信することができる。受信機では“InputDeviceProfile”情報を確認し提供すべきサービスタイプ、バージョン、第2スクリーンデバイスの解像度、受信機可能なイメージエンコーディング方式等を定義することができる。
図63は、第2スクリーンサービスに対するProtocolnfoの説明の一実施例である。
前述したRemoteUIサーバーサービス#1に対する放送シグナリングの一実施例のうち、UIListingを要求する段階(s58020)及びUIListingを送信する段階(s58030)についてさらに説明する。
前述したとおり、受信機では“InputDeviceProfile”情報を確認し提供すべきサービスタイプ、バージョン、第2スクリーンデバイスの解像度、受信機可能なイメージエンコーディング方式などを定義することができる。“第2スクリーンサービスに対するProtocolnfoの記述の一実施例”は、“InputDeviceProfile”情報の一実施例であってもよい。
図示のような情報を用いて受信機に伝達した時(UIListingを要求する段階(s58020))、XML形態となっているUILising情報を第2スクリーンデバイスに送信する(UIListingを送信する段階(s58030))。
もし、RemoteUIサーバーサービスで所望する第2スクリーンデバイスを支援しない他の装置であると、UIListingを送信する段階(s58030)でエラー情報をリターンして、第2スクリーンサービスを支援できないRemoteUIサーバーサービスであることを知らせることができる。
図64は、第2スクリーンデバイスでAddUIListing及びRemoteUIListingが実行される間のUIListingの一実施例である。
前述したRemoteUIサーバーサービス#1に対する放送シグナリングの一実施例のうち、UIListingを要求する段階(s58020)及びUIListingを送信する段階(s58030)についてさらに説明する。
UIListingを要求する段階(s58020)後に、受信機は、互換されるRemoteUI情報を探し、要求した第2スクリーンデバイスに伝達することができる(UIListingを送信する段階(s58030))。UIListingを送信する段階(s58030)で受信された情報は、図64に示す。
この受信された情報は、受信機が第2スクリーンに送信する時、TPT及びAMTを処理してTDO URLを入れるものであってもよい。したがって、第2スクリーンデバイスは、Remote UIの情報のみを受信機から得、第2スクリーンアプリケーションは、ホームネットワーク外のインターネットアプリケーションサーバーからダウンロードして実行することができる。このとき、実行することは、第2スクリーンサービスアプリケーションが担当することができる。
一方では、放送社からあらかじめ放送網や受信機に第2スクリーンデバイスのための第2スクリーンアプリケーションを送信してもよい。この場合には、受信機が第2スクリーンサービスのためのアプリケーションを保存しておき、直接サービスすることができる。この場合、ウェブサーバーが受信機で動作しなければならず、関連したイメージ及びデータは、受信機或いはホームネットワーク以外の外部アプリケーションサーバーからダウンロードすることができる。DOがNDOである場合に、ATSC−NRTでNDO及び関連リソースファイルを放送網に送信しておき、第2スクリーンサービスを提供することができる。
放送シグナリングの場合、第2スクリーンアプリケーションのライフサイクルは、受信機又は第2スクリーンサービスアプリケーションが管理することができる。
まず、受信機が第2スクリーンアプリケーションのライフサイクルを管理する方法について説明する。
受信機は、DTVCCで伝送されるメディア時間トリガーの情報を処理後に、第2スクリーンと関連したイベントがTPTに存在し、このイベントが実行されなければならない時、すぐに“UIListingUpdate”変数を、全てのホームネットワークにある機器に知らせることができる。このようなイベントに関連していて申請した機器は、UI情報がアップデートされたことを認知し、必要な情報を得るために“GetCompatibleUIs”アクションを行うことができる。この時、受信機のRemoteUIサーバーでは、すぐに実行しなければならないTDOアドレスを渡すことができる。
次に、第2スクリーンサービスアプリケーションが第2スクリーンアプリケーションのライフサイクルを管理する方法について説明する。
この場合には、受信機が受信した情報を第2スクリーンデバイスに伝達し、第2スクリーンサービスアプリケーションが自ら動作できるようにすることができる。放送の場合、第2スクリーンサービスとなるクライアントが“GetComaptibleUIs”アクションを要求すると、受信機がDTVCCで直接受信したiTVメッセージ(トリガー)のURIStringをリターンすることができ、第2スクリーンデバイスが、受信したURIStringを用いてTPTファイルをダウンロードし、受信機と同様にTPTを解釈して動作することができる。受信機はDTVCCでメディア時間トリガーやイベント時間トリガーを受信する度にすぐに“UIListingUpdate”変数を変更して全ての機器に送信することができ、新しいiTVメッセージ(トリガー)のURIStringを受信できるように、機器が“GetCompatibleUIs”アクションをするように誘導することができる。
図65は、RemoteUIクライアントサービスのためのユニキャストシグナリングの一実施例である。
前述したユニキャストシグナリングについて説明する。
この方法は、第2スクリーンデバイスがRemoteUIClientサービスを装置内に内蔵している場合といえる。UPnPデバイスが、最初にホームネットワークに接続すると、自身の情報を自分で通知し、他の装置にも新しい装置がホームネットワークに接続したという事実を知らせることができる。もう一つの方法は、周期的に新しい装置があったら知らせるように要求するメッセージを、全てのホームネットワークに接続した装置に伝達すると、全てのホームネットワークに接続した装置はこの情報に応答して通知(NOTIFY)メッセージをさらに全ての装置に知らせる方法である。まず、第2スクリーンデバイスが第2スクリーンサービスを支援するか否かについて調べなければならない。
RemoteUIクライアントサービスに対するユニキャストシグナリングの一実施例は、UPnPデバイス及びサービスディスカバリ段階(s65010)、デバイスプロファイルを要求する段階(s65020)、デバイスプロファイルを返還する段階(s65030)、TDO URL情報を送信する段階(s65040)、HTTPメッセージを返還する段階(s65050)、ディスプレイメッセージを送信する段階(s65060)、及び/又はHTTPメッセージを送信する段階(s65070)を含むことができる。
UPnPデバイス及びサービスディスカバリ段階(s65010)は、UPnPデバイス及びサービスディスカバリ段階(s58010)と同一の段階であってもよい。
デバイスプロファイルを要求する段階(s65020)は、受信機が新しく発見された第2スクリーンデバイスに第2スクリーンサービスを支援できるかを確認するために“StaticDeviceInfo”情報を送信する段階であってもよい。
デバイスプロファイルを返還する段階(s65030)は、デバイスプロファイルを要求する段階(s65020)に対する応答として、第2スクリーンデバイスのデバイスプロファイルを得る段階であってもよい。もし、新しく発見された第2スクリーンデバイスが送ったデバイスプロファイルが“Static DeviceInfo”と一致しないか、又は第2スクリーンデバイスを支援しない装置と判断されると、第2スクリーンサービスを開始しなくてもよい。“StaticDeviceInfo”は、上記で定義した“DeviceInfo”と同一であってもよい。“StaticDeviceInfo”とDeviceInfo情報が一致するかは受信機で判断しなければならない。もし、ホームネットワークに新しく発見された第2スクリーンデバイスが一つ以上である場合、このような過程は繰り返される。一度発見された第2スクリーンデバイスで第2スクリーンサービスを支援しないからといって、このような過程を経ないというわけにはいかない。第2スクリーンデバイスには一つ以上の複数のソフトウェアが設置及び削除されてもよく、ユーザが実行するか否かによってこの過程に対する結果値が変わってもよいからである。第2スクリーンサービスアプリケーションを行った状態になると、TDO URL情報を送信する段階(s65040)に移行することができる。
TDO URL情報を送信する段階(s65040)は、受信機がTPT及びAMTをパーシングした結果であるTDO URL情報を送信する段階であってもよい。UPnP RemoteUIクライアントサービスで定義された“AddUIString”を用いることができる。“AddUIString”は、第2スクリーンデバイスで第2スクリーンサービスのDeviceInfo情報を満たす場合に実行されるアクションであってもよい。TDO URLは、一つ或いは一つ以上のURLになってもよい。一つ以上のURLである場合、すぐに実行するためのURLを送信することができる。このとき、選択的にディスプレイメッセージを送信する段階(s65060)を行うことができる。
HTTPを返還する段階(s65050)は、TDO URL情報を送信する段階(s65040)に対する結果を送る段階であってもよい。前述した応答1を送信する段階(s40100)と同様に、状況によって、HTTP/1.1 200 OKなどの応答を送ることができる。
ディスプレイメッセージを送信する段階(s65060)は、第2スクリーンデバイスにディスプレイメッセージを送信する段階であってもよい。RemoteUIクライアントサービスは、第2スクリーンデバイス画面にメッセージを表示できるDisplayMessageアクションを有しうるため、第2スクリーンデバイスにTDO URLを送信し、DisplayMessageアクションを用いて、画面に現在視聴中の放送プログラムと関連付けられた第2スクリーンアプリケーションがあるというメッセージを表示することができる。ユーザがこのメッセージを確認するとすぐに第2スクリーンアプリケーション実行となり得る。
HTTPメッセージを返還する段階(s65070)は、ディスプレイメッセージを送信する段階(s65060)に対する結果を送る段階であってもよい。前述した応答1を送信する段階(s40100)と同様に、状況によって、HTTP/1.1 200 OKなどの応答を送ることができる。
図66は、RemoteUIクライアントサービスのためのユニキャストシグナリングの一実施例である。
新しいUIのURLが第2スクリーンデバイスのUIListingに追加される度に、第2スクリーンサービスアプリケーションは新しい第2スクリーンアプリケーションを実行する環境を提供することができる。
図66のRemoteUIクライアントサービスのためのユニキャストシグナリングの一実施例は、実行中の第2スクリーンアプリケーションの実行を中断し、新しい第2スクリーンアプリケーションを実行するための順序を示している。
RemoteUIクライアントサービスのためのユニキャストシグナリングの一実施例は、RemoveUIListingアクションを送信する段階(s66010)、HTTPメッセージを返還する段階(s66020)、ディスプレイメッセージを送信する段階(s66030)、HTTPメッセージを返還する段階(s66040)、TDO URL情報を送信する段階(s66050)、HTTPメッセージを返還する段階(s66060)、ディスプレイメッセージを送信する段階(s66070)、及び/又はHTTPメッセージを返還する段階(s66080)を含むことができる。
RemoveUIListingアクションを送信する段階(s66010)は、RemoteUIクライアントサービスに定義されている“RemoveUIListing”アクションを用いて、第2スクリーンサービスアプリケーションで実行中の第2スクリーンアプリケーションを中止させることができる。第2スクリーンサービスアプリケーションは、受信機で現在実行中であるUIのアプリケーション使用中止をする時、RemoveUIListingアクションを送るということを知っていてもよい。したがって、第2スクリーンサービスアプリケーションは、RemoveUIListing actionが第2スクリーンデバイスに受信されるとすぐに現在動作中の第2スクリーンアプリケーションの動作を中止しなければならない。
HTTPメッセージを返還する段階(s66020)は、RemoveUIListingアクションを送信する段階(s66010)に対する結果を送る段階であってもよい。前述した応答1を送信する段階(s40100)と同様に、状況によって、HTTP/1.1 200 OKなどの応答を送ることができる。
ディスプレイメッセージを送信する段階(s66030)は、第2スクリーンデバイスにディスプレイメッセージを送る段階であってもよい。RemoveUIListingアクションを送信する段階(s66010)の後に、場合によっては、実行が中止されるというメッセージを第2スクリーンデバイス画面に表示する必要がありうる。この場合には、DisplayMessageアクションを用いて適切なメッセージを画面に表示することができる。
HTTPメッセージを返還する段階(s66040)は、ディスプレイメッセージを送信する段階(s66030)に対する結果を送る段階であってもよい。前述した応答1を送信する段階(s40100)と同様に、状況によって、HTTP/1.1 200 OKなどの応答を送ることができる。
TDO URL情報を送信する段階(s66050)は、受信機が、新しく行われるUIのTDO URLを送信するためにAddUIListingアクションを行う段階であってもよい。新しい第2スクリーンアプリケーションが行われる時は、UIListingにTDO URLが追加されるやいなや第2スクリーンサービスアプリケーションを実行させることができる。参考として、TDO URLは、受信機で直接ダウンロードして実行し得る第2スクリーンアプリケーションに関するものであっもよく、部分的なリソースデータだけをインターネットサーバーからダウンロードして行うものであってもよい。また、TDO URLそのものが外部インターネットサーバーアドレスを指してもよい。外部インターネットサーバーアドレスを指す場合には、第2スクリーンアプリケーション及び実行に必要な全てのデータは、インターネットサーバーからダウンロードして実行することができる。
HTTPメッセージを返還する段階(s66060)は、TDO URL情報を送信する段階(s66050)に対する結果を送る段階であってもよい。前述した応答1を送信する段階(s40100)と同様に、状況によって、HTTP/1.1 200 OKなどの応答を送ることができる。
ディスプレイメッセージを送信する段階(s66070)は、第2スクリーンデバイスにディスプレイメッセージを送る段階であってもよい。TDO URL情報を送信する段階(s66050)後に、新しい第2スクリーンサービスが実行されるとのメッセージを第2スクリーンデバイス画面に表示することができる。ディスプレイメッセージを送信する段階(s66030)と同様に、DisplayMessageアクションを用いて適切なメッセージは、画面に表示することができる。
HTTPメッセージを返還する段階(s66080)は、ディスプレイメッセージを送信する段階(s66070)に対する結果を送る段階であってもよい。前述した応答1を送信する段階(s40100)と同様に、状況によって、HTTP/1.1 200 OKなどの応答を送ることができる。
ユニキャストシグナリングの場合も同様、第2スクリーンアプリケーションのライフサイクルは、受信機又は第2スクリーンサービスアプリケーションが管理することができる。
まず、受信機が第2スクリーンアプリケーションのライフサイクルを管理する方法について説明する。
第2スクリーンサービスアプリケーションでは“URL”(TDO_URL)情報だけを知っていればよい。したがって、受信機で第2スクリーンデバイスにあるRemoteUIクライアントサービスに“AddUIListing”アクションを行い、第2スクリーンデバイスで動作する第2スクリーンアプリケーションを、定められた時間に実行することができる。逆に、第2スクリーンアプリケーションを中断させなければならない場合には、“RemoveUIListing”アクションを行い、定められた時間内に第2スクリーンアプリケーションを中断させることができる。
さらに、細部的な時間まで合わせるためには、URLの他に、TDOを行うメディア時間情報まで与えると、第2スクリーンサービスアプリケーションを指定された時間に実行することができる。しかし、メディア時間は、現在受信機で再生されているメディアに対する相対的な時間であるから、この時間は各機器が理解し得る絶対時間に変更する必要がある。NTP(Network Time Protocol)或いは他の時間情報を有することができ、この時間に、未来の時間情報を有するメディア時間を加えると、アクションを行う時間となる。第2スクリーンデバイスにおいてアクションは実行と中止しかないため、これは、AddUIListing及びRemoveUIListing actionの具現によって異なり得る。
次に、第2スクリーンサービスアプリケーションが第2スクリーンアプリケーションのライフサイクルを管理する方法について説明する。
第2スクリーンサービスアプリケーションが第2スクリーンデバイスで動作する第2スクリーンアプリケーションを実行し中断する時間やイベントに関する情報を知っていなければならない。したがって、前述したように、第2スクリーンサービスアプリケーションがトリガークライアントを含んでおり、受信機がDTVCCで受信されたiTVメッセージ(トリガー)のURIString情報を受信機のDeviceInfo(Device Profile)に合わせて送信することができる。
送信方法は、2種類に大別できる。その第一の方法は、DTVCCで送信されて受信機で処理したトリガーメッセージをそのまま送信する方法であり、第二の方法は、受信機で第2スクリーンデバイスに必要な情報のみをさらに整理し、必要な情報とデータのみをXML形態で伝達する方法である。
まず、受信機がトリガーを第2スクリーンにそのまま伝達する方法について説明する。
この方法は、受信されたトリガーをそのまま“AddUIListing”アクションすることによって処理を終えることができる。RemoteUIクライアントサービスでは、この情報をもってすぐにトリガークライアントが処理できるように渡し、トリガークライアントは、受信機と同様に、TPTをダウンロードして処理することができる。ただし、受信機は、DTVCCでメディア時間トリガーが受信される度に、第2スクリーンデバイスにこのように伝達しなければならない。受信機が“appID”、“eventID”及び“event@destination”を確認し、第2スクリーンデバイスで受信しなくてもよいトリガーである場合には、自分で消費し、第2スクリーンデバイスには伝達しなくてもよい。
次に、受信機で第2スクリーンデバイスに必要なトリガー情報をフィルタリングして伝達する方法について説明する。
この方法は、受信機でTPTファイルとトリガーを処理し、第2スクリーンデバイスが処理するデータにして伝達することができる。この方法は、第2スクリーンサービスアプリケーションで、トリガークライアントが動作しなくてもよく、“ProgressInput”アクションを通じてXMLファイルを受け取って処理することができる。すなわち、第2スクリーンサービスアプリケーションが全体TPTを直接処理するのではなく、現在或いは将来に処理しなければならない必要なデータのみを受信機がフィルタリングして伝達すると、これを受けて処理することができる。この方法の長所は、“Event@Data”フィールドがあるが、このフィールドまで伝達できるという点である。
図67は、RemoteUIクライアントサービスのためのユニキャストシグナリングの一実施例である。
図67は、前述した第二の方法である、“受信機で第2スクリーンデバイスに必要なトリガー情報をフィルタリングして伝達する方法”を示している。
RemoteUIクライアントサービスのためのユニキャストシグナリングの一実施例は、イベント1情報を送信する段階(s67010)、HTTPメッセージを返還する段階(s67020)、イベント2情報を送信する段階(s67030)、HTTPメッセージを返還する段階(s67040)、イベント3情報を送信する段階(s67050)、及び/又はHTTPメッセージを返還する段階(s67060)を含むことができる。
イベント1情報を送信する段階(s67010)は、受信機が第2スクリーンデバイスに、受信したイベント情報を伝達する段階であってもよい。前述した通り、受信機でTPTファイルとトリガーを処理し、第2スクリーンデバイスが処理するデータにして伝達することができる。第2スクリーンサービスアプリケーションでは、トリガークライアントが動作しなくてもよく、“ProgressInput”アクションを通じてXMLファイルを受信して処理することができる。
HTTPメッセージを返還する段階(s67020)は、イベント1情報を送信する段階(s67010)に対する結果を送る段階であってもよい。前述した応答1を送信する段階(s40100)と同様に、状況によって、HTTP/1.1 200 OKなどの応答を送ることができる。
イベント2情報を送信する段階(s67030)は、イベント1情報を送信する段階(s67010)と同様に、イベントに関する情報を伝達する段階であってもよい。TPT XMLにおけると同様に、各イベント別にデータをTDOに伝達することができるが、この段階は、イベント2に関する情報を伝達する段階であってもよい。
HTTPメッセージを返還する段階(s67040)は、イベント2情報を送信する段階(s67030)に対する結果を送る段階であってもよい。前述した応答1を送信する段階(s40100)と同様に、状況によって、HTTP/1.1 200 OKなどの応答を送ることができる。
イベント3情報を送信する段階(s67050)は、同様に、イベント3に関する情報を伝達する段階であってもよい。
HTTPメッセージを返還する段階(s67060)は、イベント3情報を送信する段階(s67050)に対する結果を送る段階であってもよい。前述した応答1を送信する段階(s40100)と同様に、状況によって、HTTP/1.1 200 OKなどの応答を送ることができる。
前述した第二の方法では、受信機が第2スクリーンアプリケーションのライフサイクルを管理することができる。第2スクリーンアプリケーションのライフサイクルは、第2スクリーンデバイスで動作するTPT及びAMT情報をパーシングし、処理する過程を意味することができる。
図68は、ProcessInputアクションで第2スクリーンデバイスに伝達される“EventInfo”情報の一実施例である。
図68は、前述した“受信機で第2スクリーンデバイスに必要なトリガー情報をフィルタリングして伝達する方法”において、受信機がTPTファイルとトリガーを処理し、第2スクリーンデバイスが処理するデータにして伝達する時、イベント情報のXMLデータ構造の一例示を示している。
すなわち、受信機で第2スクリーンアプリケーションのライフサイクルを管理する場合には、ProcessInputアクションでは、イベント情報を、図68のデータ構造を有するXMLファイルとしてRemoteUIクライアントに伝達することができる。受信機がライブトリガー(Live Trigger)を受ける場合にも同様に、ライブトリガーを処理し、実行する時間とTDO URLなどの情報のみを第2スクリーンデバイスに伝達することもできる。
図68のテーブルで、@appID、URL、Event、@eventID、@action及びDataは、受信機が受信したトリガー又はAMTの情報と同一であってもよい。しかし、“@mediaTime”、“@startTime”及び“@endTime”は、受信機で特別に処理することができる。“@mediaTime”に合わせて、DTVCCで送信されたトリガーの“time=”シンタックスの情報(或いは、AMTの“@beginMT”情報)を処理し、再び“@startTime”と“@endTime”を決定することができる。受信機と第2スクリーンデバイスが、同一の絶対時間情報(wall clock time)を使用するとはいえないことから、コンテンツのメディア時間に合わせて第2スクリーンデバイスを動作させるためである。すなわち、受信機と第2スクリーンデバイス間にアクションに対する実行開始時間及び終了時間に関する時間情報が実際NTP(Network Time Protocol)に合わせられているとすれば、送信する前に受信機が変換する作業を行わなければならない。
送信遅延及びメディア時間推定について説明する。
前述した通り、@startTimeと@endTimeは、受信機で第2スクリーンに送る時、現在のmediaTime値を基準に相対的に作られて送信されるため、送信時に発生する時間損失は、送信プロトコルであるHTTPのヘッダーの“Date”値とHTTP応答であってもよい到着した時間値との差を用いて、第2スクリーンデバイスで調整してより正確な時間値を探すことができる。現在メディア時間と@mediaTime値との差は送信遅延時間となるため、次のような数式によって現在メディア時間を得ることができる。
現在メディア時間=送信遅延時間(受信時の時間値−HTTPヘッダー“Date”値)+@mediaTime
これによって、現在受信機の現在メディア時間値と略同一に類推することができる。
図69は、受信機及び第2スクリーンデバイス間の構成の一実施例である。
受信機及び第2スクリーンデバイス間の構成が示されている。受信機が被制御デバイス(サーバー)であり、第2スクリーンデバイスが制御ポイント(クライアント)であってもよい。
ディスカバリ段階で、受信機は、サービスリストをマルチキャストしてネットワークにジョインし、第2スクリーンアプリケーションはサービスリストに対する要求をマルチキャストして開始することができる。
記述(Description)段階で、第2スクリーンアプリケーションは、受信機のサービス記述を要求することができる。
本発明では、UPnPに基づいてTV受像機、すなわち、受信機を通じて受信されるA/V放送コンテンツと関連したインタラクティブサービスを第2スクリーンデバイスを通じて取得できるようにするために、新しいUPnPデバイス及びサービスを定義することができる。
図70は、サービスのサービスタイプ及びサービスIDの一実施例である。
受信機は、トリガーサービス、双方向通信サービス及びAppURLサービスを支援することができる。また、HTTPプロキシサーバーサービスを支援することができる。サービスタイプ及びサービスIDは、図70に示している。
双方向通信サービスは、第2スクリーンデバイス内のアプリケーションと双方向通信に参加するように準備されたプライマリデバイスで実行されるDOが存在するかを、第2スクリーンデバイスで決定するようにすることができる。
トリガーサービス、AppURLサービス及びHTTPプロキシサーバーサービスについては後述する。
図71は、トリガー伝達サービスの動作概念図の一実施例である。
トリガー伝達サービスは、UPnPに基づいてTV受信機に受信されるA/V放送コンテンツと関連したインタラクティブサービスを第2スクリーンを通じて取得できるようにするためのサービスを意味できる。
図71は、受信機がDTVCC或いはACRサーバーなどからトリガーを取得し、当該トリガーをそのまま或いは第2スクリーンデバイスに適した形態に変形(拡張されたトリガー)して第2スクリーンデバイスに送信する過程を示している。
トリガーが変化する度に、受信機から第2スクリーンデバイスに当該トリガー或いは変形された拡張トリガーを実時間で送信することができる。
図72は、拡張された活性化トリガー(expanded activation trigger)生成過程の一実施例である。
拡張されたトリガー(拡張された活性化トリガー)は、DTVCCストリーム或いはACRサーバーなどから取得したトリガーとTPT内の情報とを組み合わせて生成することができる。トリガーに含まれたTDO IDとイベントID、データID及び活性化時間と、TPT内のTDO URL、TDO属性、イベント、アクション、ディフュージョン(Diffusion)及びデータなどの情報を組み合わせて生成することができる。TDO内の情報は、トリガー内の情報と関連したTDO及びイベントに関する情報であってもよい。
ここで、拡張されたトリガーは、増加したトリガー(augmented trigger)と呼ぶこともできる。
図73は、増加した活性化トリガー(Augmented Activation Trigger)に対するXMLスキマー記述(Schema Description)の一実施例である。
トリガーサービスの説明書(Specification)について説明する。
トリガーサービスは、トリガーを伝達することができる。トリガーは、(a)ACRプロセス、(b)現在見ているチャネルのDTV CCサービス#6、(c)遠隔“ライブトリガー”サーバー、又は(d)活性化メッセージテーブル(AMT)からTV受像機によって取得することができる。これは状況による。
トリガーサービスはまた、チャネルが変更される度に特殊“チャネル変更”トリガーを伝達することができる。チャネル変更トリガーについては後述する。伝達される4つのタイプのトリガーが基本的に存在し得る。すなわち、1)TDOインタラクティブサービスモデルのための時間ベーストリガー、2)TDOインタラクティブサービスモデルのための活性化トリガー、3)直接実行インタラクティブサービスモデルのためのトリガー、及び4)特殊“チャネル変更”トリガーである。
最大の柔軟性のために、第2スクリーンデバイスに全てのタイプのトリガーを伝達するオプションを有し、受信機でトリガーが到達するやいなや伝達することが好ましい。
しかし、受信機が相互作用を提供するのと同じ方式で相互作用を提供するように設計された第2スクリーンアプリケーションに対して、TDO相互作用モデルのための時間ベーストリガーを省略し、その活性化時間にTDO相互作用モデルのための各活性化トリガーを伝達することが好ましい。これは、時間ベースを維持し、活性化時間を算出する必要性から、それらの第2スクリーンアプリケーションを求めることができる。これはまた、トリガーからの情報をトリガーで参照されたTDOエレメント及びそのイベントチャイルド(child)エレメントに関するTPTからの情報と結合することによってそれぞれの活性化トリガーを増加させ、これらの第2スクリーンアプリケーションがTPTを扱う必要性から求めることが好ましい。
したがって、トリガーサービスは、トリガー伝達のための2つのオプションを提供することができる。その一つは、受信機が(増加していない)全てのトリガーを伝達する“フィルタリングされていないストリーム(Unfiltered stream)”オプションでよい。もう一つは、TDO相互作用モデルのための増加した活性化トリガー、TDO相互作用モデル以外の相互作用モデルのための全てのトリガー及び特殊チャネル変更トリガーのみを伝達する“フィルタリングされたストリーム(Filtered stream)”オプションでよい。
TDO相互作用モデルのためのそれぞれの増加した活性化トリガーのためのターゲット伝達時間は、その活性化時間であってもよい。(フィルタリングされていないストリームオプションで増加無しで伝達された活性化トリガーを含む)全ての他のトリガーに対するターゲット伝達時間は、受信機によって受信される時間であってもよい。それぞれの特殊チャネル変更トリガーのターゲットトリガー時間は、チャネル変更の時間であってもよい。
トリガーサービスのトリガー伝達フォーマットは、増加した活性化トリガーに対する伝達フォーマット及び他の全てのトリガーに対する伝達フォーマットとに区別できる。
図73は、増加した活性化トリガー(Augmented Activation Trigger)に対する伝達フォーマットを示す。他の全てのトリガーに対する伝達フォーマットは後述する。
増加した活性化トリガーに対する伝達フォーマットは、@interactionModel、@appURL、及び/又は@cookieSpace属性と能力及び/又はイベントエレメントを含むことができる。
イベントエレメントは、@action、@destination、@diffusion及び/又は@data attributesを含むことができる。
各フィールドのセマンティックス(semantics)は、次のと通りである。
@interactionModel属性の値は、トリガーを伝達するために用いられるDTVCCチャネルのサービス#6内のSDOPrivateData命令内のcmdIDフィールドに対して同一のコーディングを用いてトリガーと関連した相互作用モデルのための数値コードであってもよい。 本発明の一実施例で、数値コードは、トリガーを伝達するために用いられるDTV CCチャネルのサービス6内のURLString命令内のURI_data()構造内のURI_typeに対するものと同一のコーディングを用いることができる。
@appURL属性の値は、トリガー内のイベント(“e=”)用語によって識別されるTPT TDOエレメントの第1URLチャイルドエレメントの値であってもよい。
@cookieSpace属性は、トリガー内のイベント(“e=”)用語によって識別されるTPT TDOエレメントが@cookieSpace属性を含む度に存在でき、その属性と同じ値を有することができる。
Capabilitiesエレメントは、トリガー内のイベント(“e=”)用語によって識別されるTPT TDOエレメントがCapabilitiesエレメントを含む度に存在でき、そのエレメントと同一であってもよい。
Eventエレメントは、トリガー内のイベント(“e=”)用語によって識別されるEventエレメントを示すことができる。(厳密にいえば、トリガー内のイベント用語は、TPT内のTDOエレメント及びそのTDOエレメントのイベントチャイルドエレメントを識別する。これは、ここでトリガー内のイベント用語によって識別されたEventエレメントという。)
@action属性の値は、トリガー内のイベント(“e=”)用語によって識別されるイベントエレメントのアクション属性の値と同一であってもよい。
@destinationは、トリガー内のイベント(“e=”)用語によって識別されるイベントエレメントがあて先属性を含む度に存在でき、その属性と同じ値を有することができる。 本発明の一実施例で、@destination属性は、トリガー内の“e=”用語によって識別されたTDOエレメントがあて先属性を含む度に存在することができる。
@diffusion属性は、トリガー内のイベント(“e=”)用語によって識別されるイベントエレメントがディフュージョン属性を含む度に存在でき、その属性と同じ値を有することができる。 本発明の一実施例で、@diffusion属性は、トリガー内の“e=”用語によってTDOエレメントがディフュージョン属性を含む度に存在することができる。
@data属性は、イベントエレメントのデータチャイルドエレメントがトリガー内のイベント(“e=”)用語によって識別される度に存在でき、そのエレメントと同じ値を有することができる。
前述した通り、増加したトリガーは、DTVCCストリーム或いはACRサーバーなどから取得したトリガーとTPT内の情報とを組み合わせて生成することができる。
前述した通り、拡張されたトリガーは、増加したトリガーと呼ぶこともできる。
図74は、URI_data()のシンタックスの一実施例である。
図74は、前述したAugmentedTriggerの@interactionModel属性に関する説明のうち、URI_data()に関するものであってもよい。
URI_data()構造は、URI_type及び/又は複数個のURI_charaterを含むことができる。また、URI_data()構造は予約ビットを含むことができる。
4ビット符号無し整数であってもよいURI_typeは、命令内で伝送されるURIのタイプを示すことができる。URI_typeの意味は、図75に示すとおりにすることができる。受信機は、認識されないタイプを示すURIString命令のインスタンスを無視すると期待することができる。URIが2個のセグメントで伝送されると、URI_typeフィールドは両セグメントにおいて同一であってもよい。
URI_characterは、URIに対して許容されるものに制限される値を有する8ビットASCII文字であってもよい。URIが2個のセグメントで伝送される場合の再組立て(reassembly)後に、URI_character値のシーケンスによって形成された文字ストリングが有効URIであってもよい。
図75は、URI_typeの意味の一実施例である。
図75は、URI_data()のシンタックスの一実施例で前述したURI_data()のURI_typeの意味に関するものであってもよい。
URI_typeが0である場合、URI_data()がインタラクティブTVトリガーに関するものであることを意味することができる。
URI_typeが1である場合、URI_data()がサービス使用報告サーバー(SURS)ロケーター(locator)に関するものであることを意味できる。
URI_typeが2−15である場合、URI_data()がどのtypeを有するかはまだ定められておらず、将来の使用のために予約されていることを意味できる。
図76は、増加した活性化トリガー(Augmented Activation Trigger)に対するXMLスキマー記述(Schema Description)の一実施例である。
増加していないトリガーのXMLフォーマットであってもよい。前述した特殊“チャネル変更”トリガーもこのフォーマットに従うことができる。
増加した活性化トリガーに対するXMLスキマー記述の一実施例は、@interactionModel属性及び/又は@triggerString属性を含むことができる。
各フィールドのセマンティックスは、次の通りである。
@interactionModel属性は、特殊“チャネル変更”トリガーのために存在することができない。他のトリガーのために、interactionModelが存在でき、その値は、DTVCCチャネル内のSDOPrivateDataコマンド内のcmdIDフィールドに対するものと同じコーディングを用いてトリガーと関連した相互作用モデルのための数値コードであってもよい。ライブトリガーサーバーから取得されたりAMTから導出されたトリガーのための@interactionModelは、TDOモデルと見なすことができる。本発明の一実施例において、数値コードは、DTV CCチャネルのサービス6のURLString命令内のURI_data()構造内のURI_typeフィールドに対するものと同一のコーディングを用いることができる。
@triggerString属性の値は、トリガーのストリング表示であってもよい。トリガーのストリング表示は、前述したトリガーシンタックスで説明したものと同一であってもよい。ただし、特殊“チャネル変更”トリガーの場合には異なってもよい。特殊“チャネル変更”トリガーのための@triggerString属性は、値“**<major_num>.<minor_num>”を有することができ、ここで、<major_num>は、(TVステーションによって放送されたため)新しいチャネルの本来の主要チャネル番号であり、<minor_num>は、(TVステーションによって放送されたため)新しいチャネルの本来のマイナーチャネル番号であってもよい。チャネル番号を知っていないと、<major_num>及び<minor_num>値は“0”であってもよい。
図77は、増加した活性化トリガーのフォーマットの一実施例である。
前述の増加したトリガーのフォーマットの他の実施例であってもよい。
@cookieSpace、Capabilities、Event、@action、@destination、@diffusion及び@dataは、前述したものと同一であってもよい。
@activationTimeは、メディア時間スケール上の活性化時間であってもよい。
@tdoURLは、前述した@appURLと同一であってもよい。
図78は、増加した活性化トリガーのフォーマットの一実施例である。
前述の増加したトリガーのフォーマットの更に他の実施例であってもよい。
@activationTime、@tdoURL、@cookieSpace、Capabilities、Event、@action、@destination、@diffusion及び@dataは、前述したものと同一であってもよい。
@availInternet及び@availBroadcastはTPTからなってもよい。@availInternet及び@availBroadcastも、前述したものと同一であってもよい。
図79は、増加した活性化トリガーのフォーマットの一実施例である。
前述の増加したトリガーのフォーマットの更に他の実施例であってもよい。
@activationTime、@tdoURL、@cookieSpace、Capabilities、Event、@action、@destination、@diffusion及び@dataは、前述したものと同一であってもよい。
ContentItem element及び、@updatesAvail、@pollPeriod、@size、@availInternet、@availBroadcast属性は、増加したトリガーを生成する時、TPTにおける同名のelement及びattributesから由来ものであってもよい。ContentItem element及び、@updatesAvail、@pollPeriod、@size、@availInternet、@availBroadcastも、前述したものと同一であってもよい。
図80は、増加した活性化トリガーのフォーマットの一実施例である。
前述の増加したトリガーのフォーマットの更に他の実施例であってもよい。
@cookieSpace、@availInternet、@availBroadcast Capabilities、ContentItem、@updatesAvail、@pollPeriod、@size、@availInternet、@availBroadcast、Event、@action、@destination及び@dataは、前述したものと同一であってもよい。
@appID、@appType、@appName、@globalId、@appVersion、@frequencyOfUse、@expireDate、@testTDO、TDOエレメント内のURL及びContentItemエレメント内のURLは、増加したトリガーを生成する時、TPTにおける同名のエレメント及び属性から由来するものであってもよい。@appID、@appType、@appName、@globalId、@appVersion、@frequencyOfUse、@expireDate、@testTDO、TDO element内のURL及びContentItem element内のURLも、前述したものと同一であってもよい。
図81は、HTTPロングポーリング基盤アプローチによるトリガーサービス状態変数の一実施例である。
ここで、トリガーサービスを支援するいくつかのアプローチが存在できる。いくつかのアプローチとしては、HTTPロングポーリング基盤アプローチとUPnPイベンティングメカニズム基盤アプローチを挙げることができる。
以下、HTTPロングポーリング基盤アプローチについて説明する。
HTTPロングポーリング基盤アプローチにおいて、トリガーサービスは一つの状態変数を有することができる。
TrigServerURL状態変数の値は、プロトコル用語無しでクライアントによってトリガーを検索するために用いられるURLであってもよい。
トリガーを検索するとの要求は、HTTP要求又はWebSocket要求を用いてなされてもよい。HTTP要求が(先頭に付け加えられたプロトコル用語http://を有するTrigServerURLを用いて)なされると、サーバーはHTTPロングポーリング伝達モードで応答することができる。WebSocket要求が(先頭に付け加えられたプロトコル用語“ws://”を有するTrigServerURLを用いて)なされると、サーバーは、WebSocket伝達モードで応答することができる。
要求URLがクエリー用語を含まないか、又はクエリー用語“?level=unfilter”を含むと、サーバーは、フィルタリングされていないストリームオプションで応答することができる。要求URLがクエリー用語“?level=filter”を含むと、サーバーは、フィルタリングされたストリームオプションで応答することができる。
トリガーがフィルタリングされていないストリームオプションで伝達され、トリガーがTDOモデル以外の相互作用モデルに対して伝達されると、応答のボディーは、図76で表示されたXMLスキマーに従うXML文書の形態を有することができる。
活性化トリガーがフィルタリングされたストリームオプションで伝達されると、応答のボディーが、図73に表示されたXMLスキマーに従うXML文書の形態を有することができる。
図82は、HTTPロングポーリング基盤アプローチによるトリガーサービスアクションの一実施例である。
HTTPロングポーリング基盤アプローチにおいて、トリガーサービスは、単一アクション、即ちGetTrigServerURLアクションを有することができる。GetTrigServerURLアクションは、クライアントがTrigServerURLの値を得るために用いることができる。
図83は、HTTPロングポーリング基盤アプローチによるGetTrigServerURLアクションの引数(Arguments)の一実施例である。
TrigServerURL出力引数は、TrigServerURL状態変数の現在値であってもよい。
この実施例で、第2スクリーンアプリケーションは、GetTrigServerURLアクションを用いてクライアントによってトリガーを検索するために用いられるURLを得ることができる。
図84は、トリガーサービス状態変数の実施例を示す図である。
図84の実施例は、UPnPイベンティングメカニズム基盤アプローチによるものである。
以下、UPnPイベンティングメカニズム基盤アプローチについて説明する。
トリガーサービス状態変数の一実施例は、図示のトリガーサービス状態変数を定義することができる。トリガーサービスは、図84に列挙された状態変数を有することができる。
LatestUnfilteredTrigger状態変数の値は、最も最近のターゲット伝達時間を有するフィルタリングされていないストリーム内のトリガーを示すことができる。この状態変数のフォーマットは、図76に記載されたスキマーに従うXML文書であってもよい。
LatestFilteredTrigger状態変数の値は、最も最近のターゲット伝達時間を有するフィルタリングされたストリーム内のトリガーを示すことができる。活性化トリガーであれば、TPT内の情報を有する活性化トリガー内の情報を結合して、図73に記載されたテーブルで表示されたXMLスキマーに従うXML文書を生成することによって増加させることができる。TDO以外の相互作用モデルを有するトリガーであれば、図76に記載されたスキマーに従うXML文書の形態を有することができる。特殊チャネル変更トリガーであれば、フォーマットは、上述したように“**<major_num>.<minor_num>”であってもよい。
UnfilteredTriggerDeliveryTime状態変数の値は、最も最近のターゲット伝達時間を有するフィルタリングされていないストリーム内のトリガーの伝達時間であってもよい。“dateTime”データタイプは、1970年1月1日00:00:00以降ミリ秒の数を示す数であってもよい。
FilteredTriggerDeliveryTime状態変数の値は、最も最近のターゲット伝達時間を有するフィルタリングされたストリーム内のトリガーの伝達時間であってもよい。
図85は、トリガーサービスアクションの実施例を示す図である。
図85の実施例は、UPnPイベンティングメカニズム基盤アプローチによるものであってもよい。
アクションは、第2スクリーンデバイス又は受信機がトリガーサービス状態変数の値を任意に判読するように定義することができる。
UPnPイベンティングメカニズム基盤アプローチにおいて、トリガーサービスアクションは、GetLatestUnfilteredTrigger及びGetLatestFilteredTriggerアクションを定義することができる。
図86は、GetLatestUnfilteredTriggerアクションの引数の実施例を示す図である。
図86の実施例は、UPnPイベンティングメカニズム基盤アプローチによるものであってもよい。
LatestUnfilteredTrigger出力引数の値は、LatestUnfilteredTrigger状態変数の値であってもよい。
第2スクリーンアプリケーションは、GetLatestUnfilteredTriggerアクションを用いてLatestUnfilteredTrigger状態変数の値、すなわち、最も最近のターゲット伝達時間を有するフィルタリングされていないストリーム内のトリガーを得ることができる。
図87は、GetLatestFilteredTriggerアクションの引数の実施例を示す図である。
図87の実施例は、UPnPイベンティングメカニズム基盤アプローチによるものであってもよい。
LatestFilteredTrigger出力引数の値は、LatestFilteredTrigger状態変数の値であってもよい。
第2スクリーンアプリケーションは、GetLatestFilteredTriggerアクションを用いてLatestFilteredTrigger状態変数の値、すなわち、最も最近のターゲット伝達時間を有するフィルタリングされたストリーム内のトリガーを得ることができる。
図88は、UPnPイベンティングメカニズム基盤アプローチの実施例である。
UPnPイベンティングメカニズム基盤アプローチの実施例は、トリガーを受信する段階(s88010)、UnfilteredTriggerDeliveryTimeを変更する段階(s88020)、非同期通知を伝達する段階(s88030)、GetLatestUnfilteredTriggerアクションを用いる段階(s88040)、増加していないトリガーで応答する段階(s88050)、活性化トリガーを受信する段階(s88060)、FilteredTriggerDeliveryTimeを変更する段階(s88070)、非同期通知を伝達する段階(s88080)、GetLatestFilteredTriggerアクションを用いる段階(s88090)及び/又は増加した活性化トリガーで応答する段階(s88100)を含むことができる。
図面で、受信機は、前述した受信機であってもよい。第2スクリーンデバイス#1は、“unfiltered stream option”を支援する第2スクリーンデバイスであってもよい。第2スクリーンデバイス#2は、“フィルタリングされたストリームオプション”を支援する第2スクリーンデバイスであってもよい。
トリガーを受信する段階(s88010)は、前述したとおり、受信機がDTVCCチャネル、ACRプロセス又は放送社インタラクティブTV(iTV)サーバーなどを介してトリガーを受信する段階であってもよい。このとき、受信したトリガーは、増加していない全てのタイプのトリガーであってもよい。
UnfilteredTriggerDeliveryTimeを変更する段階(s88020)は、前述したUnfilteredTriggerDeliveryTime状態変数の値が変更される段階であってもよい。
非同期通知を伝達する段階(s88030)は、前述した“イベンティング”プロトコルによるものであってもよい。第2スクリーンアプリケーションは、トリガーサービスの“イベンティング”特徴に加入することができる。
GetLatestUnfilteredTriggerアクションを用いる段階(s88040)は、第2スクリーンアプリケーションがトリガーを得るために、前述したGetLatestUnfilteredTriggerアクションを用いる段階であってもよい。
増加していないトリガーで応答する段階(s88050)は、GetLatestUnfilteredTriggerアクションに対する応答として、増加していないトリガーを送信する段階であってもよい。第2スクリーンアプリケーションは、GetLatestUnfilteredTriggerアクションを用いて適切なトリガーを適切な時間に得ることができる。
活性化トリガーを受信する段階(s88060)は、前述したとおり、受信機がDTVCCチャネル、ACRプロセス又は放送社インタラクティブTV(iTV)サーバーなどを介して活性化トリガーを受信する段階であってもよい。
FilteredTriggerDeliveryTimeを変更する段階(s88070)は、前述したFilteredTriggerDeliveryTime状態変数の値が変更される段階であってもよい。
非同期通知を伝達する段階(s88080)は、前述した非同期通知を伝達する段階(s88030)と同一であってもよい。
GetLatestFilteredTriggerアクションを用いる段階(s88090)は、第2スクリーンアプリケーションがトリガーを得るために、前述したGetLatestFilteredTriggerアクションを用いる段階であってもよい。
増加した活性化トリガーで応答する段階(s88100)は、GetLatestFilteredTriggerアクションに対する応答として、増加した活性化トリガーを送信する段階であってもよい。第2スクリーンアプリケーションは、GetLatestFilteredTriggerアクションを用いて適切なトリガーを適切な時間に得ることができる。
図89は、トリガーサービス状態変数の実施例を示す図である。
前述したトリガーサービスを支援するためのいくつかのアプローチには、HTTPロングポーリング基盤アプローチ及びUPnPイベンティングメカニズム基盤アプローチだけでなく、他の実施例もある。以下、その実施例を、図89及び図90を参照して説明する。
この実施例において、トリガーサービス状態変数は、図89のとおりであってもよい。
CurrentTrigger状態変数の値は、次の3つの状況のいずれかが施行されるかに依存することができる。1)プライマリスクリーンで現在視聴している番組と関連したインタラクティブ付加(adjunct)データサービスがない。2)プライマリスクリーンで現在視聴している番組と関連したインタラクティブ付加データサービスが存在し、直接実行相互作用モデルを有する。3)プライマリスクリーンで現在視聴している番組と関連したインタラクティブ付加データサービスが存在し、TDO相互作用モデルを有する。
(1)の場合、CurrentTrigger状態変数の値は、ヌルストリング(null string)であってもよい。
(2)の場合、CurrentTrigger状態変数の値は、プライマリスクリーンで現在視聴している番組に対してTV受像機によって受信された最も最近のトリガーであってもよい。
(3)の場合、CurrentTrigger状態変数の値は、プライマリスクリーンで現在視聴している番組に対してTV受像機によって受信された活性化トリガーのうち最も最近に活性化された活性化トリガーの増加した形態であってもよい。(すなわち、活性化トリガーは、活性化時間に到達する時にCurrentTrigger状態変数に対する基礎となり、他の活性化トリガーがその活性化時間に到達する時まで基礎として残っていることができる。)活性化トリガーの増加した形態は、活性化トリガー内の情報をTPT内の情報と結合することによって得ることができる。増加した形態は、上述した増加したトリガーフォーマットの一つと同一であってもよい。
CurrentTrigger状態変数の定義は、TDO相互作用モデルに対して活性化トリガーがトリガー活性化時間にUPnPクライアントに伝達されることを意味することができる。
トリガーサービス状態変数の他の実施例において、トリガーが変更される度に、受信機から第2スクリーンデバイスにトリガー又は拡張されたトリガーを実時間に伝送するために、ATSCTrigger及びATSCExpandedTriggerが状態変数として定義されてもよい。
ATSCTrigger状態変数は、DTVCCストリーム又はACRサーバーから受信されたトリガーに対する参照をURIの形態で含むことができる。この変数は、TPT(TDO parameters table)に対するURL、TDO ID、Event ID、Data ID、メディア時間、コンテンツID、ターゲットイベントに対する活性化時間などを含むことができる。
ATSCExpandedTrigger状態変数は、第2スクリーンデバイスに対するTDOと関連したメタデータを、XMLフラグメントの形態で含むことができる。このメタデータは、DTVCCストリーム又はACRサーバーから受信されたTPT及びトリガーから抽出することができる。この変数は、図80の実施例と同様のXMLスキマーを有することができる。
上記で定義したATSCTrigger及びATSCExpandedTriggerの変更された値は、受信機がUPnPのイベンティングメカニズムに基づいて状態変数を変更する時に実時間に取得することができる。
図90は、トリガーサービスアクションの実施例を示す図である。
ATSCTrigger及びATSCExpandedTriggerが状態変数として定義された上述のトリガーサービス状態変数の他の実施例において、トリガーサービスアクションを説明する。
このイベントにおいても、アクションは、第2スクリーンデバイス又は受信機が任意にATSCTrigger及びATSCExpandedTriggerの値を記録又は判読するように定義することができる。
SetTrigger()アクションは、ATSCTriggerの使用を可能にすることができる。CurrentTriggerは、引数であってもよい。
SetExpandedTrigger()アクションは、ATSCExpandedTriggerの値の利用を可能にすることができる。CurrentTriggerは増加してもよい。
GetTrigger()アクションは、ATSCTriggerの値の判読を可能にすることができる。CurrentTriggerは引数であってもよい。
GetExpandedTrigger()は、ATSCExpandedTriggerの値の判読を可能にすることができる。CurrentTriggerは引数であってもよい。
図91は、トリガー伝達サービスを用いてトリガーを取得する時に第2スクリーン上の動作の実施例を示す図である。
第2スクリーンデバイスがトリガー伝達サービスを通じて第2スクリーンデバイスから受信されたトリガー又は拡張された活性化トリガーに含まれるアクション情報によって動作する方法を示すことができる。
実行/終了アクションのトリガーは、トリガー伝達サービスを通じて取得することができる。
第2スクリーンデバイスは、トリガー伝達サービスを通じて実行/終了アクションのトリガーを取得し、取得したトリガーからの関連した情報及びターゲットTDOのURLをDAE/ブラウザに伝達することができる。ブラウザは、実行又は終了などのトリガーに含まれるアクションを行うことができる。
図92は、トリガー伝達サービスの動作概念を示す図である。
トリガー伝達サービスを通じて第2スクリーンデバイスから受信されたトリガー又は拡張された活性化トリガー内に含まれるアクション情報によって動作する方法を示すことができる。
第2スクリーンデバイスは、トリガー伝達サービスを通じてトリガーイベントアクションのトリガーを取得し、取得されたトリガーからData IDなどの情報を抽出することができる。その後、データは、AJAXを用いて現在実行されるTDOに伝達することができる。TDOは、受信したデータによって適切な動作を行うことができる。
ATSCTrigger及びATSCExpandedTriggerが状態変数として定義される上述したトリガーサービス状態変数の他の実施例において、トリガー伝達サービスの動作概念を説明する。
この実施例において、直接実行モデルの場合、コンテンツid、すなわち、“c=”がDTVCCストリーム又はACRサーバーを介して受信されたトリガーに含まれると、受信機は、受信された時間ベーストリガー値をATSCTrigger状態変数の値に設定することができる。時間ベーストリガーが受信機に到達すると、状態変数の値が直ちに変更されたり、SetTriggerアクションによって第2スクリーンデバイスに伝達されうる。
本実施例で、TDOモデルの場合、コンテンツid、すなわち、“c=”がDTVCCストリーム又はACRサーバーを介して受信されたトリガー内に含まれないと、受信機は、活性化トリガーを受信し、TPTからの関連した情報及びトリガー情報を抽出及び結合して拡張されたトリガーを生成する。その後、拡張されたトリガーの活性化時間に(又は、その前に)、ATSCExpandedTrigger状態変数の値が設定されたり、SetExpandedTriggerアクションによって第2スクリーンデバイスに伝達されうる。
図93は、第1アプローチによる双方向通信サービス状態変数の一実施例である。
双方向通信サービスは、第2スクリーンデバイス内のアプリケーションとの双方向通信に参加するように準備されたプライマリデバイスで実行されるDOがあるかを、クライアントデバイスが決定するようにすることができる。
双方向通信サービスは、クライアントデバイスが受信機で実行されるDOから双方向通信を受信するようにすることができる。これを支援するために、2個の互いに異なるアプローチが存在しうる。
以下、双方向通信サービスを実現する第1アプローチを説明する。
まず、クライアントデバイスが登録すると、(一般に、クライアントデバイス上で)WebSocketサーバーのIPアドレス及びTCPポートを提供することができる。DOがクライアントデバイスと通信することを希望すると、登録時に提供されたアドレス及びポートを用いてクライアントデバイスへのWebSocket接続を確立することができる。
第1アプローチにおいて、双方向通信サービスは、図93に示す状態変数を有することができる。
ClientList状態変数は、双方向通信のために登録されたクライアントのリストであってもよい。また、Name、IPAddress及びPortは、各クライアントに対するネーム、IPアドレス及びTCPポートを意味することができる。
図94は、第1アプローチによるClientList状態変数のXMLスキマーテーブルの一実施例である。
ClientListは、図94のテーブルによって記載されたXMLスキマーに従うXML文書の形態であってもよい。
Name状態変数は、双方向通信のために登録されたクライアントのネームであってもよい。
IPAddress状態変数は、双方向通信のために登録されたクライアントに対するWebSocketサーバーのIPアドレスであってもよい。
TCPPort状態変数は、双方向通信のために登録されたクライアントに対するWebSocketサーバーのTCPポートであってもよい。
図95は、第1アプローチによるトリガーサービスアクションの一実施例である。
第1アプローチにおいて、双方向通信サービスは、図95のテーブルによって記載されたように、2個のアクションを有することができる。
SignUpアクションは、クライアントが双方向通信に参加することに関心があることを示し、用いられるネーム及びIPアドレス及びポートを提供して接続を確立するために用いることができる。
SignOffアクションは、クライアントが双方向通信に参加することにもう関心がないことを示すために用いることができる。
図96は、第1アプローチによるSignUpアクションの引数の一実施例である。
Name入力引数は、登録されたクライアントと関連したネームであってもよい。これは、装置のホストネームであってもよい。これは、既に登録された任意の他のクライアントのネームと別個であってもよい。
IPAddress入力引数は、接続を確立する時にDOによって用いられるWebSocketサーバーのIPアドレスであってもよい。
TCPPort入力引数は、接続を確立する時にDOによって用いられるWebSocketサーバーのTCPポートであってもよい。
図97は、第1アプローチによるSignOffアクションの引数の一実施例である。
Name入力引数は、双方向通信サービスのために登録される時にクライアントが提供したネームであってもよい。その目的は、現在送信終了(signing off)するクライアントを識別することである。
図98は。第2アプローチによる双方向通信サービス状態変数の一実施例である。
以下、双方向通信サービスを実現する第2アプローチを説明する。
プライマリデバイスで実行されるこのようなDOが存在すると、第2スクリーンデバイス内のアプリケーションは、第2スクリーンデバイス内のアプリケーションが双方向通信に参加する準備ができていることを示しながら、TCP/IP接続を要求することができる。接続の第2スクリーンデバイス側上のTCP/IPアドレス及びポートが第2スクリーンデバイスの固有識別子としての機能を持つことができる。バイトは、TCP/IP接続を通じて第2スクリーンデバイス及びプライマリデバイス内のDO間で自由に伝送されうる。
双方向通信サービスは、図98に示す2個の状態変数を有することができる。
ConnectionAddress状態変数は、<address>:<port>のフォーマットで、第2スクリーンデバイスからの接続要求が向くIPアドレス及びTCPポートを含むことができる。
Status状態変数は、第2スクリーンデバイスとの双方向通信に参加するように準備された実行DOが存在するかを示し、ここで、“真”は、実行されるこのようなDOが存在するということを意味し、“偽”は、このようなDOが実行されないということを意味する。
本発明の一実施例において、Status状態変数のデータタイプは、“ストリング”であってもよい。この実施例で、Status状態変数の可能な値は“はい”及び“いいえ”であってもよい。
第2アプローチにおいて、双方向通信サービスは任意のアクションを有しなくてもよい。
図99は第2アプローチによるonBytesReceived関数の一実施例である。
以下、メッセージを伝送及び受信するためにプライマリデバイス内のDOによって用いられるAPIを説明する。
次のAPIは、双方向通信サービスを用いてプライマリデバイスで実行されるDOが第2スクリーンデバイスで実行されるアプリケーションとの双方向通信に参加するようにすることができる。
TV受信機は、DOが終了する度に双方向通信サービスのためにUPnP“Status”状態変数を“偽”に設定し、通信する前に新しいDOが事前にその状態変数を“真”に設定することができる。
前述した“Status”状態変数のデータタイプがストリングである実施例の場合、TV受信機は、DOが実行を始める度にUPnP状態変数“Status”を“いいえ”に設定し、通信前にDOが事前にその状態変数を“はい”に設定しなければならない。
新しい特性であるonBytesReceived関数は、NetworkInterfaceクラスに付加することができる。
コールバック関数であるonBytesReceived関数は、双方向通信サービスを通じてDOに対するバイトが受信される時に呼び出すことができる。2個の引数、すなわち、“address”及び“bytes”を定義することができる。
“address”は、<address>:<port>のフォーマットで受信されたバイトの送信者のIPアドレス及びUDPポートを含むストリングであってもよい。
“bytes”は、受信されたバイトを示すストリングであってもよい。実施例によって、UDP及び/又はIPヘッダーを除くものであってもよい。
図100は、第2アプローチによるsetStatusYes()の一実施例である。
新しい方法、すなわち、setStatusYes()をNetworkInterfaceクラスに追加することができる。
setStatusYes()は、双方向通信サービスのUpnPブール(Boolean)状態変数“Status”の値を“真”に設定し、DOが通信に参加する準備ができていないことを示すことができる。
setStatusYes()は、任意の引数を有しなくてもよい。
図101は、第2アプローチによるsetStatusNo()の一実施例である。
新しい方法、すなわち、setStatusNo()をNetworkInterfaceクラスに追加することができる。
setStatusNo()は、双方向通信サービスのUpnPブール状態変数“Status”の値を“偽”に設定し、DOが通信に参加する準備ができていないということを示すことができる。
setStatusNo()は、任意の引数を有しなくてもよい。
図102は、第2アプローチによるsetStatus()の一実施例である。
前述した“Status”状態変数のデータタイプがストリングである実施例の場合、setStatus()はNetworkInterfaceクラスに追加されてもよい。
setStatus()は、双方向通信サービスのUpnP状態変数“Status”の値を設定することができる。
setStatus()は状態引数を有することができる。
状態引数は、DOが第2スクリーンデバイスとの双方向通信に参加できると“はい”に設定し、そうでないと“いいえ”に設定することができる。
図103は、第2アプローチによるsendBytes()の一実施例である。
新しい方法、すなわち、sendBytes()をNetworkInterfaceクラスに追加することができる。
sendBytes()は双方向通信サービスを用いてバイトを伝送することができる。
sendBytes()は、2個の引数、すなわち、アドレス及びバイトを有することができる。
“address”引数は、<address>:<port>のフォーマットでバイトに対するあて先TCP/IPアドレス及びポートを意味することができる。
“bytes”引数は、伝送されるバイトを意味することができる。
図104は、AppURLサービス状態変数の一実施例である。
AppURLサービスは、第2スクリーンデバイスが現在実行中のDOと関連した第2スクリーンアプリケーションのネーム及びベースURLを決定するようにすることができる。
UPnP AppURLサービスは、2個の状態変数、すなわち、AppURL及びAppNameを有することができる。
AppURL状態変数の値は、現在実行中のDOと関連した第2スクリーンアプリケーションのベースURLであってもよい。第1スクリーンデバイス上に実行される関連した第2スクリーンアプリケーションを有するDOがないと、AppURL状態変数の値はヌルストリングであってもよい。
AppName状態変数の値は、現在実行中のDOと関連した第2スクリーンアプリケーションのネームであってもよい。第1スクリーンデバイス上で実行される関連した第2スクリーンアプリケーションを有するDOがないと、AppName状態変数の値はヌルストリングであってもよい。
図105は、AppURLサービスアクションの一実施例である。
AppURLサービスは、一つのアクション、すなわち、GetAppURLを有することができる。
図106は、GetAppURLアクションの引数の一実施例である。
GetAppURLアクションは、2個の引数、すなわち、AppURL及びAppNameを有することができる。
AppURL出力引数は、AppURL状態変数の現在値であってもよい。AppName出力引数は、AppName状態変数の現在値であってもよい。
したがって、GetAppURLアクションを通じて、AppURL状態変数の現在値及びAppName状態変数の現在値を得ることができる。
図107は、プロキシHTTPサーバーサービス(Proxy HTTP Server service)の動作概念図の一実施例である。
受信機は、プロキシHTTPサーバーサービスを支援することができる。プロキシHTTPサーバーサービスは、第2スクリーンデバイスで必要とするTDO/ファイルが放送網を通じて伝送される場合、これをTV受信機を通じて取得できるようにするサービスを意味することができる。
プロキシHTTPサーバーサービスの動作概念図は、放送システム107010、ACRサーバ(107020)、放送社ATSC2.0 iTVサーバ(107030)、ATSC2.0受信(107040)、及び/又は第2スクリーンデバイス107050を含むことができる。
放送システム107010は、放送システム42010と同一であってもよい。
ACRサーバー107020は、ACRサーバー42020と同一であってもよい。
放送社ATSC2.0 iTVサーバー107030は、放送社ATSC2.0 iTVサーバー42030と同一であってもよい。
ATSC2.0受信機107040は、放送A/V及びインタラクティブサービスと関連したトリガーなどを受信し、これを用いてインタラクティブサービスを取得及び画面上に提供することができる。前述した受信機と同一であってもよい。プロキシHTTPサーバーサービスは、ATSC2.0受信機107040がプロキシサーバーと同様の役割を持つようにするサービスであってもよい。第2スクリーンデバイスで要求したファイルを第2スクリーンデバイスに效率的に提供できるようにするためのものであってもよい。
第2スクリーンデバイス107050は、第2スクリーンデバイス42050と同一であってもよい。
プロキシHTTPサーバーサービスは、受信機が放送ストリーム或いはインターネットに存在するファイルに第2スクリーンデバイスを通じて接近できるようにすることによって、第2スクリーンデバイスが放送ストリームを通じて伝送されるコンテンツにも接近できるようにする。そして、複数の第2スクリーンデバイスがインターネットに存在する同一ファイルを接近する場合、各第2スクリーンデバイスが個別的に同じファイルに接近する重複性を最小化することができる。
図108は、プロキシサーバーサービス状態変数(Proxy Server Service State Variable)の一実施例である。
UPnPプロキシサーバーサービスは、HTTPプロキシサーバーを提供し、第2スクリーンデバイスがFLUTEセッションを通じて放送でTV受信機に伝達されるファイルにアクセスするようにすることができ、家庭内の複数の第2スクリーンデバイスが同時に同一ファイルを検索するとき、第2スクリーンデバイスによってインターネットサーバーからより效率的にファイルを検索できるようにする。
これを可能にさせるために、状態変数及びアクションを定義することができる。
UPnP HTTPプロキシサーバーサービスは、単一状態変数、すなわち、ProxyServerURLを有することができる。
ProxyServerURL状態変数の値は、HTTPプロキシサーバーのURL、すなわち、プロキシサーバーを通じて要求をルーティング(route)するためにHTTP要求が向かうURLであってもよい。
図109は、プロキシサーバーサービスアクション(Proxy Server Service Action)の一実施例である。
UPnPプロキシサーバーサービスは、単一アクション、すなわち、GetProxyURLを有することができる。
図110は、GetProxyURLアクションの引数の一実施例である。
GetProxyURLアクションは、単一引数、すなわち、ProxyURLを有することができる。
ProxyURL出力引数は、ProxyServerURL状態変数の現在値であってもよい。
したがって、GetProxyURLアクションによって、ProxyServerURL状態変数の現在値を得ることができる。
図111は、RequestFiles()の一実施例である。
UPnP HTTPプロキシサーバーサービス状態変数の他の実施例は、ATSCProxySeverURLというUPnP HTTPプロキシサーバーサービス状態変数を定義することができる。また、この実施例で、GetProxyServerURL()というアクションを定義することができる。
ATSCProxySeverURL状態変数は、URIの形態で受信機内のプロキシサーバーに対する参照を含むことができる。プロキシサーバーは、第2スクリーンデバイスからファイルに対するHTTP要求を受け、インターネット又は放送ストリーム内のFLUTEセッションからファイルを検索する。その後、プロキシサーバーは、HTTP応答として検索されたファイルを第2スクリーンデバイスに送信する。
GetProxyServerURL()は、ProxySeverURLの値を読み込むようにするアクションであってもよい。ProxySeverURLを引数として有することができる。
UPnP HTTPプロキシサーバーサービス状態変数の更に他の実施例は、さらに、ATSCFileListというUPnP HTTPプロキシサーバーサービス状態変数を定義することができる。また、この実施例で、RequestFiles()というアクションを定義することができる。
放送ストリームに存在するファイルは、放送コンテンツの受信が可能な受信機でのみ取得することができる。したがって、放送コンテンツを受信できない第2スクリーンデバイス上で放送コンテンツに含まれたファイルに接近可能にするために必要なUPnP状態変数及びアクションを定義することができる。すなわち、FLUTEセッションを通じてダウンロードしたいファイルリストであるATSCFileListをUPnP状態変数として定めたり、第2スクリーンデバイスが受信機に該当のファイルを要求するRequestFiles()アクションを通じて特定ファイル或いは複数のファイルを取得できるようにすることができる。
ATSCFileList状態変数は、受信機内にプロキシサーバーへの要求されたファイルのCSVリストを含むことができる。
RequestFiles()は、放送ストリーム或いはインターネット上に存在する特定ファイルをダウンロードするように要求するアクションであってもよい。特に、放送ストリームに存在するファイルの場合、要求したファイルをFLUTEセッションを通じてダウンロードするようにすることができる。
図112は、第2スクリーンデバイスアーキテクチャの一実施例である。
動作の理論について説明する。
2つのモードの動作が存在することができ、その一つの動作モードでは、トリガされたアプリケーション(TDO)がTV受信機上で実行され、他の動作モードでは、ノン−トリガされたアプリケーション(パッケージアプリケーション)がTV受信機上で実行される。
TV受信機上で実行されるトリガされたアプリケーションの場合、TV受信機上に現在表示されている番組が、第2スクリーン支援を有する関連したインタラクティブデータサービスを有すると、第2スクリーンデバイスのユーザは、デバイス上の適切なアプリケーションを活性化させることができる。このアプリケーションは、UPnPディスカバリ及び記述プロセスを経てTV受信機上のトリガーサービス、双方向通信サービス及びプロキシサーバーサービスを発見することができる。
すると、第2スクリーンアプリケーションは、トリガーサービスに対するUPnP“イベンティング”を申し込み、伝達のために準備されたトリガーの通知を得、GetLatestUnfilteredTrigger又はGetLatestFilteredTriggerアクションを用いて使用するように設計されたトリガーを取得することができる。この結果、第2スクリーンアプリケーションが適切な時間に適切なトリガーを得ることができる。すると、アプリケーションは、いずれの方式で用いられるように設計されても、それらのトリガーに対して動作することができる。
第2スクリーンアプリケーションはまた、双方向通信サービスに対するUPnP“イベンティング”を申し込み、双方向通信のための接続を要求するために用いられるTCP/IPアドレス及びポートの通知、及び通信する準備がされるプライマリデバイスで実行されるDOが存在する時の通知を得ることができる。すると、アプリケーションは、このような通信を支援する任意のDOとの双方向通信に参加することができる。
トリガー及び/又は双方向通信によるアクションはたまたま、第2スクリーンアプリケーションがファイルをダウンロードするように要求することができる。それらのファイルは、インターネット上のHTTPサーバーから利用可能であるか、又はTV放送内のセッションから利用可能でありうる(又は、両者から利用可能であってもよい)。
所望の全てのファイルがインターネットを介して利用可能であり、第2スクリーンデバイスがネットワークへの良好な接続性を有すると、アプリケーションは簡単にファイルを直接検索することができる。
所望のファイルの一部又は全てが、TV放送のみを通じて利用可能であり、受信機がHTTPプロキシサーバーサービスを提供すると、アプリケーションは、GetProxyURLアクションでプロキシサーバーURLを得、プロキシサーバーを通じて所望のファイルを検索することができる。アプリケーションはまた、直接的な方式よりは、かえってそのようにファイルを検索することがより便利な他の状況ではプロキシサーバーを用いるように選択してもよい。
TV受信機上で実行されるノン−トリガーアプリケーションの場合、現在表示されている番組と関係なく、ユーザは、その中でも、AppURLサービスを通じて第2スクリーンデバイス上で開始される同伴者アプリケーションのネーム及び位置を利用可能にするTV受信機上のDOを活性化させることができる。
第2スクリーンデバイス上の制御ポイントは、AppURLサービスと関連したUPnP“イベンティング”を申し込み、AppURL及びAppName属性に対する変更の通知を得ることができる。すると、制御ポイントは、利用可能なサービスが係留(pending)中であるということを第2スクリーンデバイスのユーザに知らせる。次に、ユーザは、AppNameを見てサービスを選択し、第2スクリーンデバイス上で同伴者第2スクリーンアプリケーションを開始させる。
第2スクリーンアプリケーションは、そのDOが受信機に以前にダウンロードされた放送社提供パッケージアプリケーションである時にも、ATSC2.0受信機上で実行されるDOと関連付けられてもよく、ここで、放送社提供パッケージアプリケーションのライフサイクルは、放送社の代わりに消費者によって制御される。同伴者第2スクリーンアプリケーションを識別するトリガーの不在時に、受信機は、第2スクリーンデバイス上の制御ポイントがGetAppURLアクションを用いて、公開された第2スクリーンアプリケーションURLにアクセスして第2スクリーンデバイス上で開始するようにするAppURLサービスを提供する。
第2スクリーンデバイスアーキテクチャの一実施例は、受信機と相互作用する第2スクリーンアプリケーションと第2スクリーンデバイスを示している。
第2スクリーンデバイスアーキテクチャの一実施例は、遠隔コンテンツサーバー112010、TV受信機112020及び/又は第2スクリーンデバイス112030を含むことができる。
遠隔コンテンツサーバー112010は、コンテンツを提供できるサーバーであってもよい。受信機112020又は第2スクリーンデバイス112030にコンテンツを提供することができる。
TV受信機112020は、UPnPトリガーサービス及びUPnPプロキシサーバーサービスを提供することができる。前述した受信機と同一であってもよい。
第2スクリーンデバイス112030は、第2スクリーンアプリケーション(ATSC2.0 App)を有することができ、第2スクリーンアプリケーションは、トリガーハンドラー内にUPnP制御ポイント(CP)モジュールを有することができる。UPnP制御ポイント(CP)モジュールは、第2スクリーンアプリケーション(ATSC2.0 App)及びTV受信機112020上のトリガーサービス及びプロキシサーバーサービス間の全てのUPnP通信をハンドリングする。UPnP制御ポイント(CP)モジュールは、探索プロセスを管理し、プロキシサーバーURLを得、トリガーサービスイベンティングを申し込むことができる。
UPnPトリガーサービスからのトリガーはトリガーハンドラーに伝達されうる。新しいDOがDAE(すなわち、ブラウザ)でダウンロードされて実行されるということをトリガーが示すと、トリガーハンドラーはそれを処理する。ブラウザで既に実行されたDOが任意のアクションを取らなければならないとトリガーが指示すると、トリガーハンドラーはトリガーをDOに伝達することができる。第2スクリーンデバイスのユーザは、DOと相互作用ですることがきる。トリガーハンドラーはユーザに見えなくてもよい。
第2スクリーンアプリケーションは、必要によって次の機能を有することができる。1)UPnPディスカバリ及び記述プロトコルを用いて、TV受信機上でトリガーサービス、及び、利用可能であれば、プロキシサーバーサービスを探す。2)UPnP SUBSCRIBEプロトコルを用いてトリガーサービスイベンティングを申し込む。3)プロキシサーバーサービスのGetProxyURLアクションを実行(invoke)して(利用可能であれば)HTTPプロキシサーバーのURLを得る。4)トリガーサービスイベントを通じて伝達されたトリガーを受信する。5)直接実行トリガーが受信され、トリガー内で識別されたDOがまだDAEで実行されていないと、(必要なら、まずダウンロードし)DAEで実行し始める。6)(必要なら、DOをダウンロードして開始した後)各受信された直接実行トリガーを、トリガーで識別されたDOに伝達する。7)TDOトリガーが受信され、トリガーのアクション属性が“TriggerEvent”以外の任意のものであれば、アクションを実行する(例えば、TDO実行を準備、TDO実行、TDO終了など)。8)TDOトリガーが受信され、トリガーのアクション属性が“TriggerEvent”であれば、リガーを、トリガーのターゲットとして識別されたTDOに伝達する。TDOがDAEでまだ実行されていないと、トリガーを廃棄する。9)必要によって、インターネットに直接接続してTV受信機上のプロキシサーバーサービスを通じて(TDOを含む)ファイルをダウンロードする。
直接実行トリガー及びTDOトリガーは、“スプレッド”又は“ディフュージョン”属性を含まないと、受信するとすぐに動作することができる。トリガーが“スプレッド”又は“ディフュージョン”属性を含むと、アクションはランダム間隔だけ遅延されうる。
図113は、受信機の簡略化した構造図の一実施例である。
受信機の簡略化した構造図は、アンテナ(rcvr2010)、チューナー(rcvr2020)、EPG(rcvr2030)、VSB又はDVB復調器(rcvr2040)、チャネルマネジャー(rcvr2050)、SIモジュール(rcvr2051)、MPEG−2TSシステムデコーダ(rcvr2060)、キャプションモジュール(rcvr2070)、トリガーモジュール(rcvr2080)、ウェブブラウザ(rcvr2090)、UPnPフレームワーク(rcvr2091)、ネットワークプロトコルスタック(rcvr2100)、ネットワークインターフェース(rcvr2110)、UIモジュール(rcvr2120)、オーディオデコーダ(rcvr2140)、ビデオデコーダ(rcvr2150)、スピーカー(rcvr2160)、ディスプレイモジュール(rcvr2170)、グラフィックプロセッサ(rcvr2180)、遠隔制御器受信器(rcvr2190)及び/又は遠隔制御器(rcvr2200)を含むことができる。
アンテナ(rcvr2010)は、放送ストリームによって放送信号を受信することができる。ここで、アンテナ(rcvr2010)は、技術の分野で一般に用いられるものであってもよい。
チューナー(rcvr2020)は、受信機のチャネルを探したり同調することができ、無線周波数増幅器、ローカルオシレータ、周波数変換及び入力回路、探知器(seeker)などを含むことができる。チューナー(rcvr2020)は、技術の分野で一般に用いられるものであってもよい。
EPG(rcvr2030)は、TV放送の空いている周波数帯や付加チャネルを用いてTV番組の放送時間と内容、出演者情報などを送る放送プログラム案内サービスであってもよい(Electronic program guide)。受信されたEPGデータは記憶しておき、視聴者がリモコンでこのEPGを操作してプログラムを選択して予約し、ペア・バー・ビュー方式(pay per view)プログラム注文、主題又は種別プログラム検索、ビデオ録画などを可能にする。受信したEPGは、UIモジュールにも伝達されてもよい。
VSB又はDVB復調器(rcvr2040)は、VSB信号又はDVB信号を復調することができる。VSB又はDVB復調器(rcvr2040)は、変調されたVSB又はDVB(e.g.,OFDM−変調信号)を本来の信号に回復することができる。VSB又はDVB復調器(rcvr2040)の復調プロセスは、技術の分野で一般に用いられるものであってもよい。
チャネルマネジャー(rcvr2050)は、受信されたEPGを用いて、チャネル管理を行うことができる。SIモジュールで処理されたEPGを伝達することができる。一般のチャネルマネジャー役割を担うことができる。
SIモジュール(rcvr2051)は、MPEG−2TSシステムデコーダ(rcvr2060)を通じて放送ストリームが入ってくると、プログラム構成情報(Program Specific Information)を把握することができる。このように把握された情報から、この放送プログラムにいくつのキャプションがあり、トリガーがサービス#6にあるか否かなどがわかる。
MPEG−2TSシステムデコーダ(rcvr2060)は、復調された信号の送信ストリーム(TS)をデコードすることができる。MPEG−2TSシステムデコーダ(rcvr2060)は、送信ストリームからキャプションストリームを得てキャプションモジュール(rcvr207)に伝達することができる。MPEG−2TSシステムデコーダ(rcvr2060)は、デコードされたオーディオ及びビデオ信号をオーディオ/ビデオデコーダに送信することができる。
キャプションモジュール(rcvr2070)は、キャプションストリームを受信することができる。キャプションモジュール(rcvr2070)は、サービス#6又は他のサービスをモニタし、サービス#6又はトリガーを送信するトリガーが選択されてトリガーモジュール(rcvr2080)に伝送されるか、又はキャプションテキストが処理されてスクリーン上にディスプレイされるかを決定することができる。トリガーデータは、トリガーモジュール(rcvr2080)に伝達することができる。他のキャプションサービスは、キャプションテキスト処理してグラフィックプロセッサ(rcvr2180)に伝送することができる。キャプションモジュール(rcvr2070)は、前述したSIモジュール(rcvr2051)が把握した情報に基づいて、現在受信されているデジタルキャプション中にトリガーがある場合にはトリガーモジュール(rcvr2080)に伝達する。
トリガーモジュール(rcvr2080)は、トリガー、TPT及び/又はAMT情報をパーシングし、パーシングされたデータを処理することができる。トリガーモジュール(rcvr2080)は、トリガーのURI情報値を用いて、ネットワークプロトコルスタック(rcvr2100)を通じてネットワークにアクセスすることができる。URI情報値は、HTTPサーバーのアドレスであってもよい。トリガーモジュール(rcvr2080)は、TPTファイルコンテンツを分析してTDO URLを得ることができる。また、トリガーモジュール(rcvr2080)は、AMTをパーシングしてデータを処理することができる。他の情報は、パーシングを通じて得ることができる。AMTメッセージが受信された後、ウェブブラウザに対応するTDO URLは、所定の時間及び動作によって伝達されたり、現在動作中のTDOが所定の時間に停止することができる。これは、TDOアクションに対応し、トリガーモジュール(rcvr2080)は動作するウェブブラウザにコマンドを送信することができる。本発明に係るトリガーモジュール(rcvr2080)の動作は、以下に詳述する。トリガーモジュール(rcvr2080)は、直間接的にネットワークプロトコルスタック(rcvr2100)を通じてインターネットにおけるサーバーに接続することができる。トリガーモジュール(rcvr2080)は直ちに、DTVCCで受信されたトリガーを分析し、必要な場合、ネットワークインターフェース(rcvr2110)を介して、TPTファイルをインターネットからダウンロードして処理することができる。TPTファイルをダウンロードするとすぐに処理して必要な動作を取ることができる。このとき、もし、第2スクリーンに関連したトリガーであり、関連したイベントがあると、前述したように、様々な方式で第2スクリーンデバイスと通信することができる。このような通信は、後述するUPnPフレームワーク(rcvr2091)で行うことができる。
ウェブブラウザ(rcvr2090)は、トリガーモジュール(rcvr2080)からコマンドを受信し、UIモジュール(rcvr2120)からブラウザキーコードを受信し、遠隔制御器受信器(rcvr2190)からブラウザキーコードを受信し、ネットワークプロトコルスタック(rcvr2100)と通信することができる。
UPnPフレームワーク(rcvr2091)は、第2スクリーンデバイスを発見してトリガーを送信したり、或いは第2スクリーンデバイスに必要な情報を再生成して送信することができる。前述したように、ネットワークインターフェース(rcvr2110)を通じてトリガーを受けたとき、第2スクリーンに関連したトリガーであり、関連したイベントがあると、UPnPフレームワーク(rcvr2091)は、第2スクリーンデバイスと通信することができる。
ネットワークプロトコルスタック(rcvr2100)は、トリガーモジュール(rcvr2080)及びウェブブラウザと通信し、ネットワークインターフェース(rcvr2110)を介してサーバーにアクセスすることができる。
ネットワークインターフェース(rcvr2110)は、いくつかの他の装置の共同接続又はネットワークコンピュータ及び外部ネットワークの接続を行う。ネットワークインターフェースはサーバーに接続してTDO、TPT、AMTなどをダウンロードすることができる。ここで、ネットワークインターフェース(rcvr2110)の動作は、技術の分野で一般に用いられるネットワークインターフェース(rcvr2110)の動作であってもよい。本発明に係るネットワークインターフェース(rcvr1090)の動作は、以下に詳述する。
UIモジュール(rcvr2120)は遠隔制御器受信器(rcvr2190)から、遠隔制御器(rcvr2200)を用いて視聴者によって入力された情報を受信することができる。受信された情報がネットワークを用いたサービスと関連するものであれば、ブラウザキーコードをウェブブラウザに伝達することができる。受信された情報が現在ディスプレイされるビデオと関連するものであれば、信号を、グラフィックプロセッサ(rcvr2180)を通じてディスプレイモジュール(rcvr2170)に伝達することができる。
オーディオデコーダ(rcvr2140)は、MPEG−2TSシステムデコーダ(rcvr2060)から受信されたオーディオ信号をデコードすることができる。その後、デコードされたオーディオ信号は、スピーカーに伝送し、視聴者に出力することができる。ここで、オーディオデコーダ(rcvr2140)は、技術の分野で一般に用いられるものであってもよい。
ビデオデコーダ(rcvr2150)は、MPEG−2TSシステムデコーダ(rcvr2060)から受信されたビデオ信号をデコードすることができる。その後、デコードされたビデオ信号は、ディスプレイモジュール(rcvr2170)に伝送し、視聴者に出力することができる。ここで、ビデオデコーダ(rcvr2150)は、技術の分野で一般に用いられるものであってもよい。
スピーカー(rcvr2160)は、オーディオ信号を視聴者に出力することができる。スピーカーは、技術の分野で一般に用いられるものであってもよい。
ディスプレイモジュール(rcvr2170)は、ビデオ信号を視聴者に出力することができる。ディスプレイモジュール(rcvr2170)は、技術の分野で一般に用いられるものであってもよい。
グラフィックプロセッサ(rcvr2180)は、キャプションモジュール(rcvr2070)から受信されたキャプションテキスト、及びUIモジュール(rcvr2120)から受信された視聴者入力情報に対してグラフィック処理を行うことができる。処理された情報は、ディスプレイモジュール(rcvr2170)に伝達することができる。グラフィックプロセッサ(rcvr2180)は、技術の分野で一般に用いられるものであってもよい。
遠隔制御器受信器(rcvr2190)は、遠隔制御器(rcvr2200)から情報を受信することができる。この時、キーコードはUIモジュール(rcvr2120)に伝達し、ブラウザキーコードはウェブブラウザに伝達することができる。
遠隔制御器(rcvr2200)は、視聴者によって入力された信号を遠隔制御器受信器(rcvr2190)に伝達する。遠隔制御器(rcvr2200)は、仮想チャネルを変更する視聴者入力を受信することができる。また、遠隔制御器は、アプリケーションに対して視聴者によって選択された情報を受信することができる。遠隔制御器(rcvr2200)は、受信された情報を遠隔制御器受信器(rcvr2190)に伝達することができる。このとき、情報は、所定範囲外の距離で赤外線(IR)光を用いて遠隔で伝達することができる。
図114は、第2スクリーンデバイスの構造図の一実施例である。
第2スクリーンデバイスの構造図の一実施例は、IOサブシステム114010、ファイルシステ(11402)、ネットワークプロトコルサブシステム114030、及び/又は基本モジュール114040を含むことができる。
IOサブシステム114010は、第2スクリーンデバイスに装着可能な、外部接続される全ての装置が接続されていてもよい。IOサブシステム114010には、キーパッド、ディスプレイ、マイクロホン、スピーカー、ステレオジャッキ、動きセンサー、光センサー、GPS及び/又はカメラなどを接続することができる。各入出力装置は、それぞれ、キーモジュール、ディスプレイ制御、オーディオ制御、センサー制御及び/又はカメラ制御によって制御されうる。各入出力装置は、デバイスドライバでコントロールされ、それぞれのセンサーやカメラなどは、IOサブシステム114010によってSDK形態で関数を呼び出すと、いずれのプログラムであっても接近可能である。場合によっては、機能に制限をおき、ネイティブアプリケーションでのみ接近可能にしてもよい。
ファイルシステム114020は、外部SDカードに対するファイルを読み書き可能になっており、USBに接続してデータ通信可能である。SDカード、フラッシュメモリー、USBなどの装置が接続可能である。それぞれSDインターフェース、フラッシュメモリー制御、USBバス制御によって制御されうる。
ネットワークプロトコルサブシステム(114030)では、3GPP、Wi−Fi及び/又はブルートゥースなどを介して通信可能である。
基本モジュール(114040)は、その他、第2デバイスで基本的なモジュールなどがありうる。バッテリーマネジャーは、第2スクリーンデバイスのバッテリー量などを管理し、通知は、通信社或いはメーカーで第2スクリーンデバイスに通知する場合に用いられるモジュールであってもよい。また、ストアモジュールは、第2スクリーンデバイスで提供するオープンSDKを用いて作られた第2スクリーン用アプリケーションを購買するモジュールであってもよい。アプリケーションマネジャーは、ストアモジュールを用いて設置されたアプリケーションを管理し、設置されたアプリケーションがアップグレードされた場合にもそれを知らせることができる。また、第2スクリーンデバイスでインターネット接続できるようにウェブモジュールが内蔵されていてもよい。個人の好みによって第2スクリーンの様々な機能に対する便宜設定をしてもよいが、ユーザ好みのプログラムを用いることができる。
基本モジュール114040は、その他、様々な機能を有し、基本的に、第2スクリーンデバイスに内蔵されていなければならないプログラムである。しかし、点線で表示されたモジュールは、選択的にユーザが設置すると動作するソフトウェアモジュールであってもよい。
例えば、UPnPフレームワークモジュールは、基本的に第2スクリーンデバイスで支援しない場合にも、内蔵されていてもよい。内蔵される場合には、ネイティブアプリケーションも併せて内蔵され、UPnP動作を円滑にしなければならない。本受信機の構造図では、UPnPフレームワークは、選択的にユーザが第2スクリーンサービスアプリケーション或いはUPnPフレームワークを支援するアプリケーションを設置することができる。UPnPフレームワークモジュールを介して、地上波を受信し得る受信機を探すことができる。
図115は、第2スクリーンデバイスシナリオの一実施例である。
第2スクリーンデバイスシナリオの一実施例について説明する。
第2スクリーンデバイスシナリオの一実施例は、トリガーを受信する段階(s115010)、TPTを要求する段階(s115020)、応答としてTPTを送信する段階(s115030)、TDOを要求する段階(s115040)、応答としてTDOを送信する段階(s115050)、TDOを実行する段階(s115060)、scanDeviceListメッセージを送信する段階(s115070)、ディスカバリ機能を呼び出す段階(s115080)、UPnPアプリケーションを実行する段階(s115090)、サーチメッセージをマルチキャストする段階(s115100)、UPnPフレームワークを通知する段階(s115110)、装置リストを返還する段階(s115120)、装置ハンドルを返還する段階(s115130)、scanServiceListメッセージを送信する段階(s115140)、サービスリスト機能を呼び出す段階(s115150)、GetServiceDescriptionメッセージを送信する段階(s115160)、HTTPメッセージを送信する段階(s115170)、サービスリストを返還する段階(s115180)、サービスハンドルのリストを返還する段階(s115190)、hnHandleメッセージを送信する段階(s115200)、サービスリスト機能を呼び出す段階(s115210)、GetDeviceProfileメッセージを送信する段階(s115220)、HTTPメッセージを送信する段階(s115230)、soap応答を返還する段階(s115240)、soap応答XMLを返還する段階(s115250)、soap応答をパーシングする段階(s115260)、hnHandleメッセージを送信する段階(s115270)、サービスリスト機能を呼び出す段階(s115280)、InputUIListingメッセージを送信する段階(s115290)、HTTPメッセージを送信する段階(s115300)、soap応答を返還する段階(s115310)、TimeToLiveを返還する段階(s115320)、hnHandleメッセージを送信する段階(s115330)、サービスリスト機能を呼び出す段階(s115340)、DisplayMessage送信する段階(s115350)、HTTP messageを送信する段階(s115360)、ヌル(null)を返還する段階(s115370)、ヌルを返還する段階(s115380)、及び/又は第2スクリーンアプリケーションを実行する段階(s115390)を含むことができる。
トリガーを受信する段階(s115010)は、放送社から放送ストリームを通じてDTVCC iTVメッセージでトリガーを受信する段階であってもよい。
TPTを要求する段階(s115020)は、受信したトリガーをパーシングし解釈して、放送社インターネットサーバーに関連したTPTを要求する段階であってもよい。
応答としてTPTを送信する段階(s115030)は、要求されたTPTを送る段階であってもよい。
TDOを要求する段階(s115040)は、関連したTDOをダウンロードする必要がある場合、放送社インターネットサーバーに関連TDOを要求する段階であってもよい。
応答としてTDOを送信する段階(s115050)は、要求されたTDOを送る段階であってもよい。
TDOを実行する段階(s115060)は、トリガーモジュールがTDOを実行させる段階であってもよい。
scanDeviceListメッセージを送信する段階(s115070)は、実行されたDO(又はTDO)がデバイススキャンのためにデバイスリストをスキャンすることを要求するメッセージを送る段階であってもよい。
ディスカバリ機能を呼び出す段階(s115080)は、デバイスディスカバリのためにUPnPフレームワークのディスカバリ機能を呼び出す段階であってもよい。
UPnPアプリケーション(s115090)は、第2スクリーンデバイスで第2スクリーンサービスランチャ用UPnPアプリケーションを実行する段階であってもよい。この段階は、プライマリデバイスと独立した段階であり、UPnPアプリケーションを実行する段階(s115090)前に実行されてもよい。
サーチメッセージをマルチキャストする段階(s115100)は、UPnPフレームワークが第2スクリーンデバイスを探すサーチメッセージをホームネットワーク内にマルチキャストする段階であってもよい。
UPnPフレームワークを通知する段階(s115110)は、サーチメッセージを受けた第2スクリーンデバイスが通知メッセージをプライマリデバイスに送信する段階であってもよい。これで、第2スクリーンデバイスの存在を知らせることができる。
デバイスリストを返還する段階(s115120)は、UPnPフレームワークがデバイスディスカバリ後に、デバイスリストを返還する段階であってもよい。
デバイスハンドルを返還する段階(s115130)は、受信したデバイスリストをDOに伝達する段階であってもよい。
scanServiceListメッセージを送信する段階(s115140)は、実行されたDO(又は、TDO)がサービススキャンのためにサービスリストをスキャンすることを要求するメッセージを送る段階であってもよい。
サービスリスト機能を呼び出す段階(s115150)は、サービスディスカバリのために、UPnPフレームワークのサービスリスト機能を呼び出す段階であってもよい。
GetServiceDescriptionメッセージを送信する段階(s115160)は、第2スクリーンデバイスのサービス記述を得るために第2スクリーンデバイスに要求する段階であってもよい。
HTTPメッセージを送信する段階(s115170)は、GetServiceDescriptionメッセージを送信する段階(s115160)における要求に対する結果を送る段階であり、前述したように、HTTP/1.1 200 OK(成功)のようなメッセージを送ることができる。サービス記述をXML形態で受信することもできる。
サービスリストを返還する段階(s115180)は、UPnPフレームワークがサービス記述を受けた後、サービスリストを返還する段階であってもよい。
サービスハンドルのリストを返還する段階(s115190)は、受信したサービスリストをリターンする段階であってもよい。
hnHandleメッセージを送信する段階(s115200)は、デバイスプロファイルを得るためにメッセージを送る段階であってもよい。
サービスリスト機能を呼び出す段階(s115210)は、サービスディスカバリのために、UPnPフレームワークのサービスリスト機能を呼び出す段階であってもよい。
GetDeviceProfileメッセージを送信する段階(s115220)は、第2スクリーンデバイスのサービス記述を得るために第2スクリーンデバイスに要求する段階であってもよい。前述したGetDeviceProfileアクションを用いることができる。HTTPメッセージを送信する段階(s115230)は、GetDeviceProfileメッセージを送信する段階(s115220)における要求に対する結果を送る段階であり、前述したようにHTTP/1.1 200 OK(成功)のようなメッセージを送ることができる。デバイスプロファイルを受信することもできる。
soap応答を返還する段階(s115240)は、受信したデバイスプロファイルを返還する段階であってもよい。
soap応答XMLを返還する段階(s115250)は、受信したデバイスプロファイルをXML形態で返還する段階であってもよい。
soap応答をパーシングする段階(s115260)は、DOが受信したSOAP messageをパーシングする段階であってもよい。
hnHandleメッセージを送信する段階(s115270)は、第2スクリーンサービスのURLアドレスを第2スクリーンデバイスに知らせるためにメッセージを送る段階であってもよい。
サービス呼び出しリスト機能を呼び出す段階(115280)は、UPnPフレームワークのサービスリスト機能を呼び出す段階であってもよい。
InputUIListingメッセージを送信する段階(s115290)は、第2スクリーンサービスのURLアドレスを第2スクリーンデバイスに知らせる段階であってもよい。前述したAddUIListingアクションを用いることができる。第2スクリーンデバイスは、取得したURLをUIListingに追加することができる。
HTTPメッセージを送信する段階(s115300)は、InputUIListingメッセージを送信する段階(s115290)における要求に対する結果を送る段階であり、前述したようにHTTP/1.1 200 OK(成功)のようなメッセージを送ることができる。
soap応答を返還する段階(s115310)は、URLの送信がなされたことを知らせるためのメッセージを返還する段階であってもよい。
TimeToLiveを返還する段階(s115320)は、HTTP messageを送信する段階(s115300)と同様に、InputUIListingメッセージを送信する段階(s115290)における要求に対する結果を送る段階であってもよい。
hnHandleメッセージを送信する段階(s115330)は、ディスプレイメッセージを第2スクリーンデバイスに伝達するために、メッセージを送る段階であってもよい。
サービスリスト機能を呼び出す段階(s115340)は、UPnPフレームワークのサービスリスト機能を呼び出す段階であってもよい。
DisplayMessageを送信する段階(s115350)は、第2スクリーンデバイスにディスプレイメッセージを送信する段階であってもよい。ディスプレイメッセージは、メッセージタイプなどの情報を含むことができる。前述したDispalyMessageアクションを用いることができる。第2スクリーンデバイスは、ディスプレイメッセージによって、メッセージを第2スクリーンにディスプレイすることができる。
HTTPメッセージを送信する段階(s115360)は、DisplayMessageを送信する段階(s115350)に対する結果を送る段階であり、前述したようにHTTP/1.1 200 OK(成功)のようなメッセージを送ることができる。
ヌルを返還する段階(s115370)は、HTTP/1.1 200 OKを受けた場合、ヌルを返還する段階であってもよい。
ヌルを返還する段階(s115380)は同様に、ヌルを応答として受けた場合、DOにヌルを返還する段階であってもよい。
第2スクリーンアプリケーションを実行する段階(s115390)は、第2スクリーンデバイスで第2スクリーンアプリケーションを実行する段階であってもよい。
図116は、プライマリデバイスでデジタルサービス信号を処理する方法の実施例を示す図である。
プライマリデバイスでデジタルサービス信号を処理する方法の実施例は、プライマリアプリケーションを実行する段階(s116010)、インタラクティブサービスのメッセージを送信する段階(s116020)、記述に対する要求を受信する段階(s116030)、記述を送信する段階(s116040)、及び/又はインタラクティブサービスを提供する段階(s116050)を含むことができる。
プライマリアプリケーションを実行する段階(s116010)は、プライマリデバイスがデジタルサービス信号に対するプライマリアプリケーションを実行する段階であってもよい。ここで、プライマリアプリケーションは、トリガーされたアプリケーション又はトリガーされないアプリケーションであってもよい。ここで、プライマリデバイスは、上述したTV受信機であってもよい。ここで、プライマリアプリケーションは、TV受信機によって実行されうるDOを意味することができる。ここで、プライマリアプリケーションは、DO、TDO、NDO、又はUDOであってもよい。
インタラクティブサービスのメッセージを送信する段階(s116020)において、メッセージは、プライマリアプリケーションに関連したセカンダリアプリケーションに対するインタラクティブサービスのメッセージを意味することができる。ここで、上述したメッセージは、プライマリデバイスから第2スクリーンデバイス(又は、第2スクリーンデバイスによって実行されるアプリケーション)に送信することができる。ここで、インタラクティブサービスは、トリガーされたアプリケーションに関連した第1モード又はトリガーされていないアプリケーションに関連した第2モードを含むことができる。ここで、セカンダリアプリケーションは、上述したプライマリアプリケーション及び第2スクリーンデバイスによって実行されるアプリケーションと関連することができる。アプリケーションは、DO、TDO、NDO、又はUDOであってもよい。ここで、トリガーされたアプリケーションはTDOを意味し、トリガーされていないアプリケーションはNDOを意味することができる。
記述に対する要求を受信する段階(s116030)は、プライマリデバイスが第2スクリーンデバイス(又は、第2スクリーンデバイスによって実行されるアプリケーション)から記述を受信する段階であってもよい。ここで、記述は、上述したインタラクティブサービスを識別する記述を意味することができる。
記述を送信する段階(s116040)は、プライマリデバイスが第2スクリーンデバイス(又は、第2スクリーンデバイスによって実行されるアプリケーション)に、要求された記述を送信する段階であってもよい。ここで、記述は、記述に記述されたインタラクティブサービスのそれぞれのサービスタイプ情報又はサービスid情報を含むことができる。ここで、サービスid情報は、インタラクティブサービスのそれぞれを識別することができる。ここで、サービスタイプ情報は、インタラクティブサービスのそれぞれのタイプを示すことができる。
インタラクティブサービスを提供する段階(s116050)は、プライマリデバイスが第2スクリーンデバイス(又は、第2スクリーンデバイスによって実行されるアプリケーション)にインタラクティブサービスを提供する段階であってもよい。インタラクティブサービスは、インタラクティブサービスに対する情報を提供することによって提供することができる。
本発明の一実施例において、上述したインタラクティブサービスに対する情報は、インタラクティブサービスのそれぞれによって定義することができる。また、上述したインタラクティブサービスに対する情報は、トリガー、バイト及びURL情報のうちの一つであってもよい。ここで、インタラクティブサービスに対する上述した情報がトリガーに対応すると、プライマリデバイスは、トリガーサービスを提供することができる。ここで、インタラクティブサービスに対する上述した情報がバイトに対応すると、プライマリデバイスは双方向通信サービスを提供することができる。ここで、インタラクティブサービスに対する上述した情報がURL情報であれば、プライマリデバイスはAppURLサービスを提供することができる。
本発明の他の実施例において、上述したインタラクティブサービスに対する情報はトリガーであってもよい。また、トリガーの少なくとも一つは、デジタルサービス信号のチャネルの変更された番号を示す値を有するチャネル変更情報を含むことができる。本実施例は、上述したトリガーサービスが上述したチャネル変更トリガーを送信する場合に対応できる。チャネル変更情報を含む少なくとも一つのトリガーは、上述したチャネル変更トリガーを意味することができる。チャネル変更情報は、変更されたチャネル番号を示す値を有することができる。
本発明の他の実施例において、上述したインタラクティブサービスに対する情報がトリガーであれば、方法は、TPT内の情報と結合することによってトリガーを増加(augment)させる段階であって、TPTは、トリガーされたアプリケーションに対するメタデータを含む、段階と、トリガー内の識別されたイベントを示すイベント指示子を有する増加したトリガーを送信する段階をさらに含むことができる。ここで、“インタラクティブサービスに対する情報がトリガーであれば”は、プライマリデバイスがトリガーサービスを提供する場合を意味することができる。本実施例は、上述した増加したトリガーが生成及び送信される場合に対応できる。“TPT内の情報と結合することによってトリガーを増加させる段階”は、TPT内に含まれる情報及びトリガーを結合する段階であってもよい。ここで、イベント指示子は、上述したAugmentedTrigger内のイベントエレメントを意味することができる。
本発明の他の実施例において、上述したインタラクティブサービスに対する情報がバイトであってもよい。また、インタラクティブサービスは、アプリケーションが実行されてセカンダリアプリケーションとの通信に参加する準備ができているかを示すstatus状態変数を含むことができる。また、方法は、status状態変数を設定する段階をさらに含むことができる。本実施例は、プライマリデバイスが双方向通信サービスを提供する場合を意味することができる。ここで、status状態変数は、上述した双方向通信サービスの第2アプローチにおけるStatus状態変数を意味することができる。ここで、“status状態変数を設定する段階”は、上述したsetStatusYes()、setStatusNo()or setStatus()APIを用いる場合を意味することができる。
本発明の他の実施例において、プライマリアプリケーションは、APIを用いてインタラクティブサービスを提供する。本実施例は、プライマリデバイスが双方向通信サービスを提供する場合を意味することができる。ここで、APIは、上述した双方向通信サービスのAPIのうち、sendBytes APIを意味することができる。
本発明の他の実施例において、APIは、バイト及びバイト引数に対するアドレス及びポートに関する情報を有するアドレス引数を含むことができる。ここで、アドレス引数は、sendBytes APIのアドレス引数を意味することができる。ここで、バイト引数は、sendBytes APIのバイト引数を意味することができる。
本発明の他の実施例において、方法は、メッセージを送信する前にプライマリアプリケーションに関連したセカンダリアプリケーションに対するインタラクティブサービスのメッセージに対する要求を受信する段階をさらに含むことができる。第2スクリーンデバイスは要求をプライマリデバイスに伝送することができる。要求は、プライマリアプリケーションに関連したセカンダリアプリケーションに対するインタラクティブサービスのメッセージに対するものである。ここで、メッセージは、上述したディスカバリメッセージを意味することができる。プライマリデバイスがメッセージに対する要求を受信すると、プライマリデバイスはメッセージを第2スクリーンデバイスに送信することができる。本実施例は、デバイスディスカバリ又はサービスディスカバリに対応できる。
図117は、セカンダリアプリケーションでデジタルサービス信号を処理する方法の実施例を示す図である。
セカンダリアプリケーションでデジタルサービス信号を処理する方法の実施例は、アプリケーションを実行する段階(s117010)、インタラクティブサービスのメッセージを受信する段階(s117020)、記述に対する要求を送信する段階(s117030)、記述を受信する段階(s117040)、通知のためのプロトコルに加入する段階(s117050)、通知を受信する段階(s117060)、受信された通知を用いて情報を受信する段階(s117070)、及び/又はファイルをダウンロードする段階(s117080)を含むことができる。
アプリケーションを実行する段階(s117010)は、第2スクリーンデバイスがデジタルサービス信号に対するアプリケーションを実行する段階であってもよい。ここで、アプリケーションは、第2スクリーンデバイスによって実行されうるDO、TDO、NDO、又はUDOを意味することができる。
インタラクティブサービスのメッセージを受信する段階(s117020)において、メッセージは、実行されたアプリケーションに対するインタラクティブサービスのメッセージを意味することができる。ここで、メッセージは、プライマリデバイスから第2スクリーンデバイスに送信することができる。
記述に対する要求を送信する段階(s117030)は、第2スクリーンデバイス(又は、第2スクリーンデバイスによって実行される第2スクリーンアプリケーション)がプライマリデバイスに記述を要求する段階であってもよい。ここで、記述はインタラクティブサービスを識別することができる。
記述を受信する段階(s117040)は、第2スクリーンデバイス(又は、第2スクリーンデバイスによって実行される第2スクリーンアプリケーション)がプライマリデバイスによって要求された記述を受信する段階であってもよい。ここで、記述は、インタラクティブサービスのそれぞれを識別するサービスid情報及びインタラクティブサービスのそれぞれに対するタイプを示すサービスタイプ情報を有することができる。
通知のためのプロトコルに加入する段階(s117050)、通知を受信する段階(s117060)、及び受信された通知を用いて情報を受信する段階(s117070)は、第2スクリーンデバイス(又は、第2スクリーンデバイスによって実行される第2スクリーンアプリケーション)が上述の記述を用いて少なくとも一つのインタラクティブサービスに接近する段階に含まれてもよい。
通知のためのプロトコルに加入する段階(s117050)は、第2スクリーンデバイス(又は、第2スクリーンデバイスによって実行される第2スクリーンアプリケーション)がプライマリデバイスによって提供された少なくとも一つのインタラクティブサービスに対する通知のためのプロトコルに加入する段階であってもよく、これは、“イベンティング”プロトコル”に加入する上述した段階であってもよい。
通知を受信する段階(s117060)は、プライマリデバイスからインタラクティブサービスに対する通知を受信する上述した段階であってもよい。通知は、上述した非同期通知であってもよい。
受信された通知を用いて情報を受信する段階(s117070)は、受信された通知を用いてインタラクティブサービスに対する情報を受信する段階であってもよい。
ファイルをダウンロードする段階(s117080)は、アプローチインタラクティブサービスに対するファイルをダウンロードする段階であってもよい。ファイルは、上述したアプリケーションであってもよい。
本発明の一実施例において、上述したインタラクティブサービスに対する情報は、インタラクティブサービスのそれぞれによって定義することができる。また、上述したインタラクティブサービスに対する情報は、トリガー、バイト及びURL情報のうちの一つであってもよい。ここで、インタラクティブサービスに対する上述した情報がトリガーに対応すると、プライマリデバイスはトリガーサービスを提供することができる。ここで、インタラクティブサービスに対する上述した情報がバイトに対応すると、プライマリデバイスは双方向通信サービスを提供することができる。ここで、インタラクティブサービスに対する上述した情報がURL情報であれば、プライマリデバイスはAppURLサービスを提供することができる。
本発明の他の実施例において、探索されたインタラクティブサービスに対する情報がトリガーであれば、トリガーの少なくとも一つは、デジタルサービス信号のチャネルの変更された番号を示す値を有するチャネル変更情報を含むことができる。本実施例は、上述したトリガーサービスが上述したチャネル変更トリガーを送信する場合に対応できる。チャネル変更情報を含む少なくとも一つのトリガーは、上述したチャネル変更トリガーを意味することができる。チャネル変更情報は、変更されたチャネル番号を示す値を有することができる。
本発明の他の実施例において、上述したアクセスされたインタラクティブサービスに対する情報がバイトであれば、方法は、受信された通知を用いてインタラクティブサービスが始まる準備ができているかを決定する段階、及び受信された通知を用いてバイトを送信するための接続に対する要求を送信する段階をさらに含む。本実施例は、上述した双方向通信サービスが提供される場合に対応できる。本実施例で、通知は、プライマリデバイスによって実行されるDOが通信する準備ができているかを示すためのものである。本実施例で、バイトを送信するための接続は、TCP/IP接続であってもよい。また、本実施例は、プライマリデバイスへのTCP/IP接続を要求する動作に対応できる。
本発明の他の実施例において、方法は、メッセージを受信する前に実行されたアプリケーションに対するインタラクティブサービスのメッセージに対する要求を送信する段階をさらに含む。第2スクリーンデバイスは、要求をプライマリデバイスに伝送することができる。要求は、セカンダリアプリケーションに対するインタラクティブサービスのメッセージに対するものである。メッセージは、上述したディスカバリメッセージを意味することができる。プライマリデバイスがメッセージに対する要求を受信すると、プライマリデバイスは、メッセージを第2スクリーンデバイスに送信することができる。本実施例は、デバイスディスカバリ又はサービスディスカバリに対応できる。
図118は、プライマリデバイスとしてデジタルサービス信号を処理する装置の実施例を示す図である。
プライマリデバイスとしてデジタルサービス信号を処理する装置の実施例は、実行モジュール118010、送信モジュール118020、受信モジュール118030、及び/又は提供モジュール118040を備えることができる。
実行モジュール118010は、デジタルサービス信号に対するプライマリアプリケーションを実行するように構成することができる。ここで、プライマリアプリケーションは、トリガーされたアプリケーション又はトリガーされていないアプリケーションであってもよい。ここで、プライマリデバイスは、上述したTV受信機であってもよい。ここで、プライマリアプリケーションは、TV受信機によって実行されうるDOを意味することができる。ここで、プライマリアプリケーションは、DO、TDO、NDO、又はUDOであってもよい。
送信モジュール118020は、プライマリアプリケーションに関連したセカンダリアプリケーションに対するインタラクティブサービスのメッセージを送信するように構成することができる。また、送信モジュール118020は、インタラクティブサービスを識別する記述を送信するように構成することができる。ここで、インタラクティブサービスは、トリガーされたアプリケーションに関連した第1モード又はトリガーされていないアプリケーションに関連した第2モードを含むことができる。ここで、記述は、要求によって送信することができる。上述したメッセージは、第2スクリーンデバイス(又は、第2スクリーンデバイスによって実行されるアプリケーション)に送信することができる。ここで、セカンダリアプリケーションは、上述したプライマリアプリケーションに関連したアプリケーション及び第2スクリーンデバイスによって実行されたアプリケーションであってもよい。アプリケーションは、DO、TDO、NDO、又はUDOであってもよい。ここで、トリガーされたアプリケーションはTDOを意味し、トリガーされていないアプリケーションはNDOを意味することができる。
受信モジュール118030は、インタラクティブサービスのそれぞれを識別するサービスid情報及びインタラクティブサービスのそれぞれのタイプを識別するサービスタイプ情報を有する記述に対する要求を受信するように構成することができる。ここで、記述は、記述に記述されたインタラクティブサービスのそれぞれのサービスタイプ情報及びサービスid情報を含むことができる。
ここで、送信モジュール118020及び受信モジュール118030は、設計者の意図によって一つのモジュールに具備することができる。
提供モジュール118040は、インタラクティブサービスに対する情報を送信することによってインタラクティブサービスを提供するように構成することができる。提供モジュール118040は、インタラクティブサービスを第2スクリーンデバイス(又は、第2スクリーンデバイスによって実行されるアプリケーション)に提供することができる。
本発明の実施例において、上述したインタラクティブサービスに対する情報は、インタラクティブサービスのそれぞれによって定義することができる。また、上述したインタラクティブサービスに対する情報は、トリガー、バイト及びURL情報のうちの一つであってもよい。ここで、インタラクティブサービスに対する上述した情報がトリガーに対応すると、プライマリデバイスはトリガーサービスを提供することができる。ここで、インタラクティブサービスに対する上述した情報がバイトに対応すると、プライマリデバイスは双方向通信サービスを提供することができる。ここで、インタラクティブサービスに対する上述した情報がURL情報であれば、プライマリデバイスはAppURLサービスを提供することができる。
本発明の他の実施例において、上述したインタラクティブサービスに対する情報はトリガーであってもよい。また、トリガーの少なくとも一つは、デジタルサービス信号のチャネルの変更された番号を示す値を有するチャネル変更情報を含むことができる。本実施例は、上述したトリガーサービスが上述したチャネル変更トリガーを送信する場合に対応できる。チャネル変更情報を含む少なくとも一つのトリガーは、上述したチャネル変更トリガーを意味することができる。チャネル変更情報は、変更されたチャネル番号を示す値を有することができる。
本発明の他の実施例において、上述したインタラクティブサービスに対する情報がトリガーであれば、装置は、増加モジュールをさらに備えることができる。増加モジュールは、TPT内の情報と結合することによってトリガーを増加させるように構成することができる。TPTは、トリガーされたアプリケーションに対するメタデータを含むことができる。上述した送信モジュールはさらに、トリガー内の識別されたイベントを示すイベント指示子を有する増加したトリガーを送信することができる。ここで、“インタラクティブサービスに対する情報がトリガーであれば”は、プライマリデバイスがトリガーサービスを提供する場合を意味することができる。本実施例は、上述の増加したトリガーが生成及び送信される場合に対応できる。増加モジュールは、TPT内に含まれる情報及びトリガーを結合することができる。ここで、イベント指示子は、上述したAugmentedTrigger内のイベントエレメントを意味することができる。
本発明の他の実施例において、上述したインタラクティブサービスに対する情報がバイトであってもよい。また、インタラクティブサービスは、アプリケーションが実行されてセカンダリアプリケーションとの通信に参加する準備ができているかを示すstatus状態変数を含むことができる。また、装置は、status状態変数を設定する段階をさらに含むことができる。本実施例は、プライマリデバイスが双方向通信サービスを提供する場合を意味することができる。ここで、status状態変数は、上述した双方向通信サービスの第2アプローチにおけるStatus状態変数を意味することができる。ここで、“status状態変数を設定する段階”は、上述したsetStatusYes()、setStatusNo()or setStatus()APIを用いる場合を意味することができる。
本発明の他の実施例において、プライマリアプリケーションは、APIを用いてインタラクティブサービスを提供する。本実施例は、プライマリデバイスが双方向通信サービスを提供する場合を意味することができる。ここで、APIは、上述した双方向通信サービスのAPIのうちのsendBytes APIを意味することができる。
本発明の他の実施例において、APIは、バイト及びバイト引数に対するアドレス及びポートに関する情報を有するアドレス引数を含むことができる。ここで、アドレス引数は、sendBytes APIのアドレス引数を意味することができる。ここで、バイト引数は、sendBytes APIのバイト引数を意味することができる。本発明の他の実施例において、受信モジュールはさらに、送信モジュールがメッセージを送信する前にプライマリアプリケーションに関連したセカンダリアプリケーションに対するインタラクティブサービスのメッセージに対する要求を受信するように構成することができる。第2スクリーンデバイスは要求をプライマリデバイスに伝送することができる。要求は、プライマリアプリケーションに関連したセカンダリアプリケーションに対するインタラクティブサービスのメッセージに対するものである。ここで、メッセージは、上述したディスカバリメッセージを意味することができる。プライマリデバイスがメッセージに対する要求を受信すると、プライマリデバイスはメッセージを第2スクリーンデバイスに送信することができる。本実施例は、デバイスディスカバリ又はサービスディスカバリに対応できる。
図119は、セカンダリアプリケーションとしてデジタルサービス信号を処理する装置の実施例を示す図である。
セカンダリアプリケーションとしてデジタルサービス信号を処理する装置の実施例は、実行モジュール119010、受信モジュール119020、伝送モジュール119030、アクセスモジュール119040、及び/又はダウンロードモジュール119050を備えることができる。
実行モジュール119010は、デジタルサービス信号に対するアプリケーションを実行するように構成することができる。ここで、アプリケーションは、第2スクリーンデバイスによって実行されうるDO、TDO、NDO、又はUDOを意味することができる。
受信モジュール119020は、実行されたアプリケーション及び記述に対するインタラクティブサービスのメッセージを受信するように構成することができる。ここで、メッセージはプライマリデバイスから送信されてもよい。ここで、記述はプライマリデバイスによって要求されてもよい。ここで、記述はインタラクティブサービスを識別することができる。
伝送モジュール119030は、インタラクティブサービスを識別する記述に対する要求を伝送するように構成することができる。ここで、記述は、インタラクティブサービスのそれぞれを識別するサービスid情報及びインタラクティブサービスのそれぞれに対するタイプを示すサービスタイプ情報を有することができる。
アクセスモジュール119040は、記述を用いて少なくとも一つのインタラクティブサービスをアクセスするように構成することができる。アクセスモジュール119040はまた、少なくとも一つのインタラクティブサービスに対する通知のためのプロトコルに加入することができ、これは、“イベンティング”プロトコルに加入する上述した動作に対応する。アクセスモジュール119040はまた、通知を受信することができる。通知は、上述した非同期通知であってもよい。アクセスモジュール119040はまた、受信された通知を用いて少なくとも一つのインタラクティブサービスに対する情報を受信することができる。
ダウンロードモジュール119050は、アクセスされたインタラクティブサービスに対するファイルをダウンロードするように構成することができる。ここで、ファイルは、上述したアプリケーションであってもよい。
本発明の一実施例で、上述したインタラクティブサービスに対する情報は、インタラクティブサービスのそれぞれによって定義することができる。また、上述したインタラクティブサービスに対する情報は、トリガー、バイト及びURL情報のうちの一つであってもよい。ここで、インタラクティブサービスに対する上述した情報がトリガーに対応すると、プライマリデバイスはトリガーサービスを提供することができる。ここで、インタラクティブサービスに対する上述した情報がバイトに対応すると、プライマリデバイスは双方向通信サービスを提供することができる。ここで、インタラクティブサービスに対する上述した情報がURL情報であれば、プライマリデバイスはAppURLサービスを提供することができる。
本発明の他の実施例において、探索されたインタラクティブサービスに対する情報がトリガーであれば、トリガーの少なくとも一つは、デジタルサービス信号のチャネルの変更された番号を示す値を有するチャネル変更情報を含むことができる。本実施例は、上述したトリガーサービスが上述したチャネル変更トリガーを送信する場合に対応できる。チャネル変更情報を含む少なくとも一つのトリガーは、上述したチャネル変更トリガーを意味することができる。チャネル変更情報は、変更されたチャネル番号を示す値を有することができる。
本発明の他の実施例において、上述したアクセスされたインタラクティブサービスに対する情報がバイトであれば、アクセスモジュール119040はまた、受信された通知を用いてインタラクティブサービスが始まる準備ができているかを決定することができる。また、アクセスモジュール119040は受信された通知を用いてバイトを送信するための接続に対する要求を送信することができる。本実施例は、上述した双方向通信サービスが提供される場合に対応できる。本実施例で、通知は、プライマリデバイスによって実行されるDOが通信する準備ができているかを示すためのものであってもよい。本実施例において、バイトを送信するための接続は、TCP/IP接続であってもよい。また、本実施例は、プライマリデバイスへのTCP/IP接続を要求する動作に対応できる。
本発明の他の実施例において、伝送モジュールはまた、受信モジュールがメッセージを受信する前に実行されたアプリケーションに対するインタラクティブサービスのメッセージに対する要求を伝送するように構成することができる。第2スクリーンデバイス(又は、伝送モジュール)は要求をプライマリデバイスに伝送することができる。要求は、セカンダリアプリケーションに対するインタラクティブサービスのメッセージに対するものであってもよい。ここで、メッセージは、上述したディスカバリメッセージを意味することができる。プライマリデバイスが上述したディスカバリメッセージを受信すると、プライマリデバイスはメッセージを第2スクリーンデバイスに送信することができる。本実施例はデバイスディスカバリ又はサービスディスカバリに対応できる。
UPnPフレームワークは、電子装置をホームネットワークに接続し、電子装置によって機能を提供することによって提供することができる。本発明は、既存のUPnP RemoteUIクライアントサービス及びUPnP RemoteUIサーバークライアントの拡張に関するものである。したがって、既存のUPnP装置と互換可能であるとともに、第2スクリーンサービスを受信することができる。
添付の図面を参照して本発明を明瞭に説明してきたが、添付の図面に示す実施例を組み合わせて新しい実施例を設計することもできる。上述した実施例を実行するプログラムが記録されたコンピュータ読み取り可能な記録媒体が当業者の必要によって設計されると、これは添付した特許請求の範囲及びその同等物に属することができる。
本発明の装置及び方法は、上述した実施例の構成及び方法に制限されるものではない。また、上述した実施例は、一部又は全部が選択的に結合されて様々な変更が可能な方式で構成されてもよい。
また、本発明に係る方法は、ネットワークデバイスに提供されるプロセッサ読み取り可能記録媒体においてプロセッサ読み取り可能コードとして具現することもできる。プロセッサ読み取り可能媒体は、プロセッサによって読み取り可能なデータを記憶できるあらゆる種類の記録装置を含む。プロセッサ読み取り可能記録媒体の例には、ROM、RAM、CD−ROM、磁気テープ、フロッピーディスク、光データ記憶装置などがあり、また、インターネットを介した伝送どのようなキャリアウェーブの形態として具現されてもよい。また、プロセッサ読み取り可能記録媒体は、ネットワークを通じて接続されたコンピュータシステムに分散され、分散方式でプロセッサ読み取り可能コードが記憶されて実行されてもよい。
当業者にとって本発明の思想又は範囲から逸脱することなく本発明の様々な変形及び変更が可能であるということは明らかである。したがって、本発明は、添付した特許請求の範囲及びその同等物の範囲内で提供される本発明の変形及び変更をカバーする。
そして、当該明細書では物の発明と方法の発明の両方とも説明されており、必要によって両発明の説明は相互補充的に適用されてもよい。
〔実施例〕
発明の実施例は、前述した通り、発明を実施するための形態で詳述された。