受信器における同調を改善する方法、装置、及びシステム
レシーバ／再生デバイスがコンテンツの再生を開始するのにかかる時間を短縮する方法、装置、及びシステムは、コンテンツを再生するレシーバにコンテンツを識別する情報を供給する段階を含む。一実施形態では、かかる情報はチューニングコマンドの一部として含まれてもよい。例えば、一実施形態では、再生するコンテンツは、オーディオ／ビデオコンテンツとそれを識別する情報を含み、オーディオおよびビデオコーデックパラメータを含んでもよい。オーディオおよびビデオコーデックパラメータにより、レシーバ／再生デバイスのデコーダをすぐに初期化でき、レシーバのチューニング時間を短縮できる。かかる情報の供給により、デコーダが複数のコンテンツパケットを解析して前記コンテンツのオーディオおよびビデオのタイプを識別する必要がなくなる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、受信における同調時間に関し、より具体的には、セットトップボックス等の受信器の同調時間を改善する方法、装置、及びシステムに関する。
【背景技術】
【０００２】
セットトップボックス（ＳＴＢ）等の受信器が、標準リアルタイムストリームプロトコル（ＲＴＳＰ）リダイレクトと、共有アプリケーションにおいて記述されたペイロードに同調するデバイスグループ制御プロトコル（ＤＧＣＰ）セッション記述プロトコルとのいずれかを用いて、新しいストリームに同調するとき、ＳＴＢがその新しいストリームの再生を開始するには有限の時間遅れが生じる。すなわち、現在のシステムでは、ＳＴＢに供給されるデータは、ＳＴＢがオーディオとビデオをできるだけ素早く再生するのに、必要であるが十分ではない。
【０００３】
かかる構成が特に問題になるのは、用いるＲＴＳＰプロファイルがＭＰＥＧ２トランスポートストリームの場合である。トランスポートストリームはオーディオ及び／またはビデオコンテンツを符号化／復号する様々なデバイスを含み得る。このため、一般的な実装では、デコーダを正しく設定するために、入来ストリームをバッファして、情報を自動検出する。このバッファのために、オーディオやビデオを再生するのに遅延が生じる。
［関連出願との相互参照］
本出願は、２００９年１月２６日出願の米国仮出願第６１／２０５，９５９号の利益を主張するものである。また、本出願は、２００７年４月４日に米国特許商標庁に出願した米国仮出願第６０／９２１，７１４号、及びこの米国仮出願第６０／９２１，７１４号の優先権を主張して２００７年６月１３日に特許協力条約により出願した国際出願第ＰＣＴ／ＵＳ０７／０１３９４９号（両方とも発明の名称は「デバイスグループ制御」である）にも関連する。これらは全体をここに参照援用する。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の実施形態は、レシーバが受信コンテンツの再生開始にかかる時間を、一実施形態では数秒から数分の一秒に短縮する方法、装置、及びシステムを提供することにより、先行技術の欠点を解消する。
【０００５】
本発明の一実施形態では、レシーバが受信コンテンツの再生開始にかかる時間を短縮する方法は、再生するコンテンツを受信したレシーバが、識別情報なしにコンテンツを受信した場合と比較して短い遅延で前記コンテンツの再生を開始できるように、前記コンテンツとともに、前記コンテンツを識別する情報を供給する段階を有する。かかる一実施形態では、コンテンツは、オーディオ／ビデオコンテンツとそれを識別する情報を含み、オーディオおよびビデオコーデックパラメータを含んでもよい。また、かかる実施形態では、コンテンツを識別する情報は、チューニングコマンドの一部としてレシーバ／再生デバイスに送信できる。本発明の様々な実施形態では、コンテンツとそれを識別する情報は、デバイスグループ制御プロトコルを用いて少なくとも１つのレシーバ／再生デバイスに送信できる。
【０００６】
本発明の別の一実施形態では、レシーバが受信コンテンツの再生開始にかかる時間を短縮する方法は、コンテンツとそれを識別する情報を受信する段階と、コンテンツを識別情報なしに受信した場合と比較して、短い遅延で、レシーバ／再生デバイスがコンテンツを再生できるように、受信した情報を用いてデコーダを初期化する段階とを有する。かかる一実施形態では、コンテンツを識別する情報は、セッション記述プロトコルデータパックの一部としてレシーバ／再生デバイスに送信できる。
【０００７】
本発明の別の一実施形態は、コンピュータ読み取り可能媒体を含む。該記憶媒体は、記録されたマルチメディアコンテンツと、前記マルチメディアコンテンツのレシーバ／再生デバイスが、識別情報なしにコンテンツを受信した場合と比較して短い遅延で前記マルチメディアコンテンツの再生を開始できるように記録された、前記マルチメディアコンテンツを識別する情報とを有する。
【図面の簡単な説明】
【０００８】
本発明の教示は、添付した図面とともに以下の詳細な説明を読めば、容易に理解できる。
【図１】本発明の一実施形態による、本発明を様々に実装できる、コンテンツ配信システムを示すハイレベルのブロック図である。
【図２】本発明の一実施形態によるリテール広告ネットワークを示すハイレベルのブロック図である。
【図３】データを受信して解析する先行技術を示すフロー図である。
【図４】本発明の一実施形態によるレシーバの同調の改善方法を示すフロー図である。 言うまでもなく、図面は本発明のコンセプトを例示する目的のものであり、本発明を例示する構成は必ずしもこれだけではない。理解を容易にするために、複数の図面で共通な同一要素を示すためには同じ参照数字を用いた。
【発明の実施するための形態】
【０００９】
本発明は、レシーバが、受信したコンテンツの再生を開始するのにかかる時間を短縮する方法、装置、及びシステムを有利に提供する。主にリテール広告ネットワーク環境とセットトップボックスの場合に本発明を説明するが、本発明の具体的な実施形態を、本発明の範囲を限定するものとして扱ってはならない。当業者や本発明の教示を知った者には言うまでもないが、本発明のコンセプトは、様々なタイプのレシーバを有する実質的にどんなコンテンツ配信環境にも有利に適用できる。
【００１０】
図示した様々な要素の機能は、専用ハードウェアを用いても、ソフトウェアを実行可能なハードウェアと適当なソフトウェアとを組み合わせても提供できる。プロセッサを設けるとき、機能を単一の専用プロセッサで提供してもよいし、共有された単一のプロセッサで提供してもよいし、一部が共有された複数の個別プロセッサで提供してもよい。さらに、「プロセッサ」または「コントローラ」という用語を明示的に使用した場合、ソフトウェアを実行できるハードウェアのみをいうと解釈してはならず、限定はされないが、デジタルシグナルプロセッサ（ＤＳＰ）、ソフトウェアを記憶するＲＯＭ、ＲＡＭ、不揮発性記憶装置を黙示的に含んでもよい。さらに、本発明の原理、態様、実施形態、及びその実施例のすべての記載は、その構成的等価物及び機能的等価物の両方を含むものである。また、かかる等価物は、現在知られている等価物及び将来開発される等価物を含み、すなわち、構成にかかわらず同じ機能を発揮する開発されるすべての要素を含む。
【００１１】
このように、例えば、当業者には言うまでもなく、ここに説明したブロック図は本発明の原理を化体するシステムコンポーネント及び／または回路を概念的に示すものである。同様に、言うまでもなく、フローチャート、フロー図、状態遷移図、擬似コード等は、様々な方法（processes）を表し、これらの方法をコンピュータ読み取り可能媒体に実質的に表しても、（明示的に示していようがいまいが）コンピュータやプロセッサで実行してもよい。
【００１２】
図１は、本発明の一実施形態による、本発明を様々に実装できる、コンテンツ配信システムを示すハイレベルのブロック図である。図１のコンテンツ配信システム１００は、少なくとも１つのサーバ１１０と、同調／復号手段（セットトップボックス（ＳＴＢ）等）１２０１−１２０Ｎなどの複数の受信デバイスと、各セットトップボックス１２０１−１２０Ｎのディスプレイ１３０１−１３０Ｎと、その他のオーディオ出力デバイス（スピーカシステム等）１３５１−１３５Ｎなどの受信デバイスとを有する。各セットトップボックス１２０１−１２０Ｎは、図１のシステム１００では、それぞれ１つのディスプレイに接続されているように描いたが、本発明の別の実施形態では、２つ以上のディスプレイに接続されていてもよい。また、同調／復号手段は、図１のコンテンツ配信システム１００では、セットトップボックス１２０として描いたが、本原理の別の実施形態では、ディスプレイ１３０に組み込まれた同調／復号回路やその他のスタンドアロン同調／復号デバイスなどの別の同調／復号手段であってもよい。さらに、本発明の受信デバイスは、オーディオコンテンツ、ビデオコンテンツ、オーディオ／ビデオコンテンツなどのコンテンツを受信できるどんなデバイスも含み得る。
【００１３】
一実施形態では、図１のコンテンツ配信システム１００は、リテール広告ネットワークの一部であり得る。例えば、図２は、本原理の一態様による、リテール広告を提供するリテール広告ネットワークを示すハイレベルのブロック図である。図２の広告ネットワーク２００では、広告ネットワーク２００とサーバシステム１００は、エンターテイメントコンテンツ、ニュース、及びインストア設定における同様のコンシューマ情報コンテンツとともに、音楽レコーディング、ホームビデオ、製品実演、広告コンテンツなどのカタログ配布、配信、プレゼンテーション、及び利用追跡を、提供するソフトウェアとハードウェアの組み合わせを利用する。コンテンツは、圧縮または非圧縮の、ビデオとオーディオストリームフォーマット（ＭＰＥＧ２、ＭＰＥＧ４パート１０／ＡＶＣ−Ｈ．２６４、ＶＣ−１、ウィンドウズ（登録商標）メディアなど）で表したコンテンツを含んでもよいが、本発明のシステムはこうしたフォーマットのみの利用に限定されない。
【００１４】
一実施形態では、インストア広告ネットワーク２００とコンテンツ配信／サーバシステム１００の様々な要素を制御するソフトウェアは、ウィンドウズ（登録商標）環境を用いた３２ビットオペレーティングシステム（例えば、MSウィンドウズ（登録商標）やXウィンドウ（登録商標）オペレーティングシステム）と、高性能コンピューティングハードウェアを含み得る。広告ネットワーク２００は、分散アーキテクチャを利用して、集中コンテンツ管理を提供し、また一実施形態では衛星（または、ワイドエリアネットワーク（WAN）、インターネット、一連のマイクロ波リンク、または同様のメカニズムなどのその他の方法）及びインストアを介した配信制御を提供できる。
【００１５】
図２に示した通り、リテール広告ネットワーク２００とコンテンツ配信システム１００用のコンテンツは、アドバタイザ２０２、レコーディング企業２０４、映画スタジオ２０６、その他のコンテンツプロバイダ２０８により提供され得る。アドバタイザ２０２は、製品生産者、サービスプロバイダ、これらを代理する広告会社などである。アドバタイザ２０２アドバタイザ２０２からの広告コンテンツは、コマーシャル、「インフォマーシャル（info-mercials）」、製品情報、及び製品実演などを含むオーディオビジュアルコンテンツにより構成され得る。
【００１６】
レコーディング会社２０４は、レコードレーベル、音楽出版社、ライセンシング／出版会社（例えば、ＢＭＩやＡＳＣＡＰ）、アーティスト個人、その他の音楽関連コンテンツのコンテンツ源であり得る。レコーディング会社２０４は、音楽クリップ（レコーディングした音楽の短い一部分）、音楽ビデオクリップなどのオーディオビジュアルコンテンツを提供する。映画スタジオ２０６は、映画スタジオ、映画製作会社、評論家（publicist）、その他の映画産業に関係するコンテンツ源であり得る。映画スタジオ１０６は、映画クリップ、事前に録画した俳優・女優とのインタビュー、映画レビュー、「舞台裏」プレゼンテーションなどのコンテンツを提供できる。
【００１７】
他のコンテンツプロバイダ２０８は、図１のコンテンツ配信システム１００などを介して配信し、表示されるビデオ、オーディオ、またはオーディオビジュアルコンテンツのその他のプロバイダであり得る。
【００１８】
一実施形態では、コンテンツは、例えば、従来の記録メデイア（テープ、ＣＤ、ビデオなど）を用いて、ネットワーク管理センタ（ＮＭＣ）２１０を介して調達される。ＮＭＣ２１０に供給されたコンテンツは、例えばローカル配信システム１００への配信に好適な形式でコンパイルされる。ローカル配信システム１００は、コンテンツを配信し（店内などの）ローカルサイトで表示する。
【００１９】
ＮＭＣ２１０は、受信したコンテンツをデジタル化し、デジタル化データファイル２２２の形式でネットワークオペレーションズセンタ（ＮＯＣ）２２０に提供する。留意すべき点として、データファイル２２２は、デジタル化コンテンツとして説明するが、ストリーミングオーディオ、ストリーミングビデオなどの情報であってもよい。コンパイルされＮＭＣ２１０により受信されたコンテンツは、コマーシャル、バンパー（bumpers）、グラフィックス、オーディオなどを含み得る。全てのファイルは、一意的に識別できるように命名されることが好ましい。より具体的には、ＮＭＣ２１０は、ストアロケーションなど特定のサイトに宛ての配信パックを生成し、スケジュールによって、またはオンデマンドでストアに配信する。配信パック（distribution packs）は、（サイトのシステムが初めて初期化されるのでない場合）利用するとき、すでにオンサイトにある既存のコンテンツを置き換え、または改良するコンテンツを含む（初めて初期化される場合、配信されたパッケージはそのサイトの最初のコンテンツとなる）。あるいは、ファイルは別々に圧縮され、転送されてもよいし、ある種のストリーミング圧縮プログラムを利用してもよい。
【００２０】
図２に示した実施形態では、ＮＯＣ２２０は、ひとまとまりとしてモニタされ、及び／または制御される一群のサーバを規定するリテールネットワークマネージャ（ＲＮＭ）２２４を含む。すなわち、本発明の一実施形態では、デバイスグループ制御プロトコル（ＤＧＣＰ）に従ってＲＮＭ２２４によりグループ化される。デバイスグループ制御プロトコルは、米国特許商標庁に２００７年４月４日に出願された共有に係る仮特許出願第６０／９２１７１４号と、米国を指定してＰＣＴにより２００７年６月１３日に出願された国際出願第０７／０１３９４９号に記載されている。両文献の発明の名称はともに「デバイスグループ制御」である。両文献はその全体をここに参照援用する。
【００２１】
すなわち、デバイスグループ制御プロトコルに従って、各サーバを、少なくとも１つのグループ（それ自身）に所属させ、他の多くのグループにも所属させるように構成することができる。このように、コマンドや要求を、１つまたは複数のサーバを含むグループごとに宛てる（target）ことができる。このように、一グループの各サーバは、同じブロードキャストチャネルまたはマルチキャストチャネルを用いて、送受信する。上記の発明の様々な実施形態では、サーバは、必要なだけ多くのグループのメンバーになることをサポートできる。また、サーバは、上記のプロトコルまたは外部手段を用いて、グループのメンバーになったり、メンバーから抜けたりするように構成できる。外部手段には、コンフィギュレーションファイルと、その他のＳＮＭＰやウェブ構成ページなどのトランザクションがある。本発明のさまざまな実施形態では、すべてのストアが、あるジップコードに属する、ある時間帯に属する、ある州に立地する、ある地域に立地する、ある人口統計的特徴を有するなどの共通の属性により、サーバをグループ化できる。システムのグループは、一意的な識別子を割り当てられ、一単位として通信、モニタ、制御を行う。
【００２２】
図２のリテール広告ネットワーク２００では、ＮＯＣ２２０は、通信ネットワーク２２５を介して、コマーシャルセールスアウトレット２３０にある各サーバ／コンテンツ配信システム１００に、デジタル化したデータファイル２２２を送信する。各サーバ１００は、（ＮＯＣ２２０などからの）入来メッセージを調べて、そのメッセージが適用されるターゲットグループにそのサーバが属しているか判断できるように構成されたグループ識別子ユニット１０２を含む。
【００２３】
本発明の様々な実施形態では、通信ネットワーク２２５はどんな技術で実施してもよい。例えば、本発明の一実施形態では、通信ネットワーク２２５は、コマーシャルセールスアウトレット２３０などの各アプリケーションサーバシステム１００にデジタル化したデータファイル２２２を配信する衛星リンク（衛星ＩＰネットワーク）を含む。かかる構成により、有利にも、コンテンツを様々なロケーションに同時にマルチキャストして配信することができる。あるいは、インターネットを用いて、コマーシャルセールスアウトレット２３０にオーディオビジュアルコンテンツを配信し、そのコマーシャルセールスアウトレット２３０からフィードバックを得ることができる。本発明の他の実施形態では、専用線、マイクロ波ネットワークその他のメカニズムを用いるなどの通信ネットワーク２２５を実施するその他の方法や構成を用いることができる。
【００２４】
インストアなどのローカルレベルでは、コンテンツ配信システム１００のサーバ１１０は、配信パックなどのコンテンツを受信して、適宜そのコンテンツをセットトップボックス１２０とディスプレイ１３０とスピーカシステム１３５などの様々な受信器にインストア配信することができる。すなわち、コンテンツ配信システム１００では、コンテンツは、受信されストリーミング用に構成される。ストリーミングは、共に、または調和して動作するように構成された１つ以上のサーバにより実行できる。ストリーミングコンテンツは、ストアなどのセールスアウトレット２３０中のいろいろなロケーションや製品用に構成されたコンテンツを含み得る。例えば、セットトップボックス１２０とディスプレイ１３０と様々なスピーカシステム１３５とは、セールスアウトレット２３０中のあるロケーションに位置し、各セットトップボックスとディスプレイのロケーションから所定距離内にある製品に関するコンテンツを表示し、オーディオをブロードキャストするように構成され得る。
【００２５】
コンテンツ配信システム１００のサーバ１１０は、コンテンツを受信して、テキスト、オーディオ、ビデオ、及びオーディオ／ビデオのストリーム（コンテンツチャネルなど）を生成し、ストア中のレシーバに送信する。ストリームは、無線周波数配信に変調されたオーディオ、ビデオ、及び／またはオーディオ／ビデオの個別チャネルでもよいし、ユニキャストまたはマルチキャストインターネットプロトコル（ＩＰ）ネットワーク内のデータフローとして送信してもよい。これらのストリームは、同じ論理的に一組の制御ソフトウェアで、１つ以上のサーバに始まるものであってもよい。
【００２６】
例えば、本発明の一実施形態では、図１のコンテンツ配信システム１００のサーバ１１０などの本発明のサーバは、受信したストリームをデバイスグループ制御プロトコルに従って送信できる。デバイスグループ制御プロトコルは、米国特許商標庁に２００７年４月４日に出願された共有に係る仮特許出願第６０／９２１７１４号と、米国を指定してＰＣＴにより２００７年６月１３日に出願された国際出願第０７／０１３９４９号に記載されている。両文献の発明の名称はともに「デバイスグループ制御」である。両文献はその全体をここに参照援用する。
【００２７】
すなわち、サーバを、デバイスグループ制御プロトコルにより情報を送信するように構成することができる。レシーバは、かかるプロトコルを用いて、少なくとも１つのグループ、すなわち自分自身と、その他の多くのグループに属するように構成することもできる。このように、コマンド、要求、またはコンテンツの通信を、１つまたは複数のデバイスを含むグループごとに宛てる（target）ことができる。このように、一グループの各デバイスは、同じブロードキャストチャネルまたはマルチキャストチャネルを用いて、送受信する。上記の発明の様々な実施形態では、デバイスは、必要なだけ多くのグループのメンバーになることをサポートできる。また、デバイスは、上記のプロトコルまたは外部手段を用いて、グループのメンバーになったり、メンバーから抜けたりするように構成できる。外部手段には、コンフィギュレーションファイルと、その他のＳＮＭＰやウェブ構成ページなどのトランザクションがある。また、上記の発明のいくつかのアプリケーションでは、グループメンバーシップを予め設定することも望ましい。
【００２８】
かかるプロトコルを用いる一実施形態では、ストックＤＧＣＰペイロードが、リアルタイムストリームプロトコル（ＲＴＳＰ）DESCRIBE応答と同様のフォーマットを用いて、セッション記述プロトコル（ＳＤＰ）データブロックをセットトップボックス（ＳＴＢ）に配信する。ＳＤＰはＩＥＴＦ（http://tools.ietf.org/html/rfc2327）により規定されている。
【００２９】
かかるデータブロックは次のフォーマットを含み得る：
c=IN IP4 233.192.0.101
a=control:rtsp://169.254.1.1/view0
a=type:scheduled
m=video 49162 RTP/AVP 33
a=fmtp:33 program_number=1
a=framerate:29.97
a=orient:portrait。
【００３０】
上記のデータは次を含む：
IP address and port (233.192.0.101/49162)
Controlling RTSP URL (rtsp://169.254.1.1/view0)
Stream type (video)
RTP profile type (33 - MPEG2 Transport Stream)
Video frame rate (29.97)
Video orientation (portrait)。
【００３１】
しかし、かかるデータブロックは次に関する情報を含んでいない：
ビデオ解像度
ビデオアスペクト比（４：３または１６：９またはその他）
ビデオコーデック
ビデオビットレート
オーディオコーデック
オーディオビットレート
ＭＰＥＧ２トランスポートストリームなどを用いるアプリケーションでは、含まれていない情報が重要である。一通信ではビデオコーデックはＭＰＥＧ２であるが、他の一通信では、ビデオコーデックはＨ．２６４（ＭＰＥＧ４パート１０）であり得る。また、オーディオコーデックはＭＰＥＧオーディオを含むものであってもよいが、別の実施形態ではドルビーＡＣ３を含むものであってもよい。
【００３２】
このように、本発明の様々な実施形態により、ＳＴＢやスピーカなどのレシーバと通信するときの遅延を最小にするため、上記の情報の少なくとも一部、またはそれ以上を、チューニングコマンドの一部としてレシーバに送信しなければならない。より具体的には、本発明の様々な実施形態では、レシーバに追加情報を送信することにより、そのレシーバが新しいストリームにチューニングするのにかかる時間を短くできる。
【００３３】
本発明の一実施形態では、セッション記述プロトコル（ＳＤＰ）拡張を用いて、データを送り、レシーバと通信する。かかる実施形態では、ＳＤＰを使用するため、メディア属性は次のものを含む：
a=vcodec:mpeg2-in-mpeg2ts
a=vcodecrate:19.39mbps
a=vcodecaspect:16x9
a=vcodecresolution:1920x1200
a=acodec:ac3
a=acodecrate:200kbps
a=acodecchannels:5.1
本発明の別の一実施形態では、バイナリＤＧＣＰペイロードは、上記と同様の、ビットフィールドで定義された情報を有してもよい。
【００３４】
例えば、現在のシステムアーキテクチャでは、最初にトランスポートストリームを受け取り、そのトランスポートストリーム（ＭＰＥＧトランスポートストリームなど）を解析して、ビデオコーデックとオーディオコーデックとコーデックパラメータとを調べる。これに０．５秒から数秒の時間がかかる。本発明の様々な実施形態では、有利にも、従来の方法と比較してチューニング時間を短縮できる。
【００３５】
従来の方法に対する利点を示すため、まず、データを受信して解析する従来の方法のフロー図を説明する。次に、本発明の一実施形態によるレシーバのチューニングの改善方法を説明する。図３は、データを受信して解析する従来の方法を示すフロー図である。方法３００は、ステップ３０２から始まり、ＲＴＳＰまたはＤＧＣＰを用いて、ストリームを識別するセッション記述プロトコル（ＳＤＰ）ブロックを受信する。かかるＳＤＰの一例としては：
c=IN IP4 233.192.0.101
a=control:rtsp://169.254.1.1/view0
a=type:scheduled
m=video 49162 RTP/AVP 33
a=fmtp:33 program_number=1
a=framerate:29.97
a=orient:portrait。
そしてステップ３０４に進む。
【００３６】
ステップ３０４において、ＳＤＰブロックを解析（parse）して、ＲＴＰセッションを送信するＩＰアドレスとポートを決定する。上記の例では、ＩＰアドレスは解析の結果、233.192.0.101ポート49162である。そしてステップ３０６に進む。
【００３７】
ステップ３０６において、ＳＤＰブロックを解析して、ＲＴＰペイロードタイプを決定する。上記の例では、ペイロードタイプは、解析の結果、ＲＴＰ／ＡＶＴタイプ３３であり、これはＭＰＥＧ２トランスポートストリームである。そしてステップ３０８に進む。
【００３８】
ステップ３０８において、受信ソケットをオープンにして、ＲＴＰストリームからパケットの受信を開始する。そしてステップ３１０に進む。
【００３９】
ステップ３１０において、解像度などのパラメータを含む、オーディオとビデオのタイプについてストリーム中のＭＰＥＧシグネチャ（signature）を検出するのに十分なパケットを待ってから解析する。コーデックに関するこれらの詳細情報が分かると、ステップ３１２に進む。
【００４０】
ステップ３１２において、オーディオ・ビデオデコーダチップを初期化して、復号を開始する。そしてステップ３１４に進む。
【００４１】
ステップ３１４において、集積したパケットの再生を開始する。留意点として、これらのパケットは受信当初からバッファされていたものであってもよい。この時、デコーダチップは、圧縮ビットストリームを復号し、ディスプレイとスピーカなどの再生デバイスに出力するオーディオとビデオにする。このような従来技術の方法３００では、ＳＤＰを受信してからビデオとオーディオを視聴するまでの遅延は、数分の一秒から数秒であり、これはＭＰＥＧトランスポートストリームをどのくらい解析して、デコーダチップを初期化するのに必要なデータを求めねばならないかに依存する。
【００４２】
図４は、本発明の一実施形態によるレシーバのチューニングの改善方法４００を示すフロー図である。方法４００は、ステップ４０２から始まり、ＲＴＳＰまたはＤＧＣＰを用いて、ストリームを識別するセッション記述プロトコル（ＳＤＰ）ブロックを受信する。かかるＳＤＰの一例としては：
c=IN IP4 233.192.0.101
a=control:rtsp://169.254.1.1/view0
a=type:scheduled
m=video 49162 RTP/AVP 33
a=fmtp:33 program_number=1
a=framerate:29.97
a=orient:portrait
a=vcodec:mpeg2-in-mpeg2ts
a=vcodecrate:19.39mbps
a=vcodecaspect:16x9
a=vcodecresolution:1920x1200
a=acodec:ac3
a=acodecrate:200kbps
a=acodecchannels:5.1。
【００４３】
上記のＳＤＰの例から明らかなように、本発明の様々な実施形態では、事前に追加データを提供して、デコーダチップをすぐに初期化する。そしてステップ４０４に進む。
【００４４】
ステップ４０４において、ＳＤＰブロックを解析（parse）して、ＲＴＰセッションを送信するＩＰアドレスとポートを決定する。上記の例では、ＩＰアドレスは233.192.0.101であり、ポートは49162である。そしてステップ４０６に進む。
【００４５】
ステップ４０６において、ＳＤＰブロックを解析して、ＲＴＰペイロードタイプを決定する。上記の例では、ＲＴＰ／ＡＶＴタイプは３３であり、これはＭＰＥＧ２トランスポートストリームである。そしてステップ４０８に進む。
【００４６】
ステップ４０８において、ＳＤＰブロックを解析して、オーディオコーデックとビデオコーデックのパラメータの詳細を求める。本発明の様々な実施形態では、追加のコーデック情報により、デコーダチップをすぐに初期化でき、レシーバのチューニング時間を短縮できる。すなわち、上記の従来方法では、解像度などのパラメータを含む、オーディオ・ビデオタイプのストリーム中のＭＰＥＧシグネチャを検出するために、十分多くのパケットを待ってから解析するが、これとは対照的に、本発明の実施形態では、ＳＤＰブロックを解析して、オーディオコーデックとビデオコーデックのパラメータの詳細を求め、これによりデコーダチップをすぐに初期化できるようにする。ＳＤＰブロックを解析してオーディオコーデックとビデオコーデックのパラメータの詳細を求めてから、ステップ４１０に進む。
【００４７】
ステップ４１０において、オーディオ・ビデオデコーダチップを初期化して、復号を開始する。そしてステップ４０４に進む。
【００４８】
ステップ４１２において、受信ソケットをオープンにして、ＲＴＰストリームからパケットの受信を開始する。そしてステップ４１４に進む。
【００４９】
ステップ４１４において、メディアパケットを、到着したら再生する。デコーダチップは、圧縮されたビットストリームを、ディスプレイとスピーカなどの再生デバイスに出力するオーディオ及びビデオとして復号する。本発明の実施形態では、ＳＤＰを受信してからビデオとオーディオを視聴できるまでの遅延が、上記の従来方法３００と比較して、短縮される。その理由は、少なくともＭＰＥＧトランスポートストリームを解析するまでの待ち時間がないからである。
【００５０】
本発明の一実施形態では、本発明による（オーディオおよび／またはビデオコンテンツなどの）コンテンツを識別する、レシーバ／再生デバイスにより利用される情報は、図１のコンテンツ配信システム１００のサーバ１１０などのコンテンツサーバから、および／または図２のリテール広告ネットワーク２００のＮＯＣ２２０および／またはＮＭＣ２１０から、レシーバ／再生デバイスに送信できる。すなわち、本発明の一実施形態では、配信するコンテンツを識別する情報は、本発明のサーバのメモリ（図示せず）に記憶でき、コンテンツとともに、および／またはチューニングコマンドの一部として、レシーバに送信できる。すなわち、本発明のサーバは、上記の通り、サーバの様々な動作機能を実行するプロセッサ（図示せず）を含み、上記の通り、コンテンツおよび／またはそのコンテンツを識別する情報を記憶するメモリをさらに含む。
【００５１】
レシーバが受信コンテンツの再生を開始するのにかかる時間を短縮する方法、装置、システムの様々な実施形態を説明したが、（これらは例示であって限定ではなく、）当業者は上記の教示を考慮して修正や変形をすることができることに留意すべきである。それゆえ、当然のことながら、本発明の範囲と精神において、開示した本発明の実施形態を変更することができる。上記は本発明の様々な実施形態に関するが、本発明のその他の実施形態やさらに別の実施形態を、本発明の基本的な範囲から逸脱することなく工夫することができる。
【技術分野】
【０００１】
本発明は、概して、受信における同調時間に関し、より具体的には、セットトップボックス等の受信器の同調時間を改善する方法、装置、及びシステムに関する。
【背景技術】
【０００２】
セットトップボックス（ＳＴＢ）等の受信器が、標準リアルタイムストリームプロトコル（ＲＴＳＰ）リダイレクトと、共有アプリケーションにおいて記述されたペイロードに同調するデバイスグループ制御プロトコル（ＤＧＣＰ）セッション記述プロトコルとのいずれかを用いて、新しいストリームに同調するとき、ＳＴＢがその新しいストリームの再生を開始するには有限の時間遅れが生じる。すなわち、現在のシステムでは、ＳＴＢに供給されるデータは、ＳＴＢがオーディオとビデオをできるだけ素早く再生するのに、必要であるが十分ではない。
【０００３】
かかる構成が特に問題になるのは、用いるＲＴＳＰプロファイルがＭＰＥＧ２トランスポートストリームの場合である。トランスポートストリームはオーディオ及び／またはビデオコンテンツを符号化／復号する様々なデバイスを含み得る。このため、一般的な実装では、デコーダを正しく設定するために、入来ストリームをバッファして、情報を自動検出する。このバッファのために、オーディオやビデオを再生するのに遅延が生じる。
［関連出願との相互参照］
本出願は、２００９年１月２６日出願の米国仮出願第６１／２０５，９５９号の利益を主張するものである。また、本出願は、２００７年４月４日に米国特許商標庁に出願した米国仮出願第６０／９２１，７１４号、及びこの米国仮出願第６０／９２１，７１４号の優先権を主張して２００７年６月１３日に特許協力条約により出願した国際出願第ＰＣＴ／ＵＳ０７／０１３９４９号（両方とも発明の名称は「デバイスグループ制御」である）にも関連する。これらは全体をここに参照援用する。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の実施形態は、レシーバが受信コンテンツの再生開始にかかる時間を、一実施形態では数秒から数分の一秒に短縮する方法、装置、及びシステムを提供することにより、先行技術の欠点を解消する。
【０００５】
本発明の一実施形態では、レシーバが受信コンテンツの再生開始にかかる時間を短縮する方法は、再生するコンテンツを受信したレシーバが、識別情報なしにコンテンツを受信した場合と比較して短い遅延で前記コンテンツの再生を開始できるように、前記コンテンツとともに、前記コンテンツを識別する情報を供給する段階を有する。かかる一実施形態では、コンテンツは、オーディオ／ビデオコンテンツとそれを識別する情報を含み、オーディオおよびビデオコーデックパラメータを含んでもよい。また、かかる実施形態では、コンテンツを識別する情報は、チューニングコマンドの一部としてレシーバ／再生デバイスに送信できる。本発明の様々な実施形態では、コンテンツとそれを識別する情報は、デバイスグループ制御プロトコルを用いて少なくとも１つのレシーバ／再生デバイスに送信できる。
【０００６】
本発明の別の一実施形態では、レシーバが受信コンテンツの再生開始にかかる時間を短縮する方法は、コンテンツとそれを識別する情報を受信する段階と、コンテンツを識別情報なしに受信した場合と比較して、短い遅延で、レシーバ／再生デバイスがコンテンツを再生できるように、受信した情報を用いてデコーダを初期化する段階とを有する。かかる一実施形態では、コンテンツを識別する情報は、セッション記述プロトコルデータパックの一部としてレシーバ／再生デバイスに送信できる。
【０００７】
本発明の別の一実施形態は、コンピュータ読み取り可能媒体を含む。該記憶媒体は、記録されたマルチメディアコンテンツと、前記マルチメディアコンテンツのレシーバ／再生デバイスが、識別情報なしにコンテンツを受信した場合と比較して短い遅延で前記マルチメディアコンテンツの再生を開始できるように記録された、前記マルチメディアコンテンツを識別する情報とを有する。
【図面の簡単な説明】
【０００８】
本発明の教示は、添付した図面とともに以下の詳細な説明を読めば、容易に理解できる。
【図１】本発明の一実施形態による、本発明を様々に実装できる、コンテンツ配信システムを示すハイレベルのブロック図である。
【図２】本発明の一実施形態によるリテール広告ネットワークを示すハイレベルのブロック図である。
【図３】データを受信して解析する先行技術を示すフロー図である。
【図４】本発明の一実施形態によるレシーバの同調の改善方法を示すフロー図である。 言うまでもなく、図面は本発明のコンセプトを例示する目的のものであり、本発明を例示する構成は必ずしもこれだけではない。理解を容易にするために、複数の図面で共通な同一要素を示すためには同じ参照数字を用いた。
【発明の実施するための形態】
【０００９】
本発明は、レシーバが、受信したコンテンツの再生を開始するのにかかる時間を短縮する方法、装置、及びシステムを有利に提供する。主にリテール広告ネットワーク環境とセットトップボックスの場合に本発明を説明するが、本発明の具体的な実施形態を、本発明の範囲を限定するものとして扱ってはならない。当業者や本発明の教示を知った者には言うまでもないが、本発明のコンセプトは、様々なタイプのレシーバを有する実質的にどんなコンテンツ配信環境にも有利に適用できる。
【００１０】
図示した様々な要素の機能は、専用ハードウェアを用いても、ソフトウェアを実行可能なハードウェアと適当なソフトウェアとを組み合わせても提供できる。プロセッサを設けるとき、機能を単一の専用プロセッサで提供してもよいし、共有された単一のプロセッサで提供してもよいし、一部が共有された複数の個別プロセッサで提供してもよい。さらに、「プロセッサ」または「コントローラ」という用語を明示的に使用した場合、ソフトウェアを実行できるハードウェアのみをいうと解釈してはならず、限定はされないが、デジタルシグナルプロセッサ（ＤＳＰ）、ソフトウェアを記憶するＲＯＭ、ＲＡＭ、不揮発性記憶装置を黙示的に含んでもよい。さらに、本発明の原理、態様、実施形態、及びその実施例のすべての記載は、その構成的等価物及び機能的等価物の両方を含むものである。また、かかる等価物は、現在知られている等価物及び将来開発される等価物を含み、すなわち、構成にかかわらず同じ機能を発揮する開発されるすべての要素を含む。
【００１１】
このように、例えば、当業者には言うまでもなく、ここに説明したブロック図は本発明の原理を化体するシステムコンポーネント及び／または回路を概念的に示すものである。同様に、言うまでもなく、フローチャート、フロー図、状態遷移図、擬似コード等は、様々な方法（processes）を表し、これらの方法をコンピュータ読み取り可能媒体に実質的に表しても、（明示的に示していようがいまいが）コンピュータやプロセッサで実行してもよい。
【００１２】
図１は、本発明の一実施形態による、本発明を様々に実装できる、コンテンツ配信システムを示すハイレベルのブロック図である。図１のコンテンツ配信システム１００は、少なくとも１つのサーバ１１０と、同調／復号手段（セットトップボックス（ＳＴＢ）等）１２０１−１２０Ｎなどの複数の受信デバイスと、各セットトップボックス１２０１−１２０Ｎのディスプレイ１３０１−１３０Ｎと、その他のオーディオ出力デバイス（スピーカシステム等）１３５１−１３５Ｎなどの受信デバイスとを有する。各セットトップボックス１２０１−１２０Ｎは、図１のシステム１００では、それぞれ１つのディスプレイに接続されているように描いたが、本発明の別の実施形態では、２つ以上のディスプレイに接続されていてもよい。また、同調／復号手段は、図１のコンテンツ配信システム１００では、セットトップボックス１２０として描いたが、本原理の別の実施形態では、ディスプレイ１３０に組み込まれた同調／復号回路やその他のスタンドアロン同調／復号デバイスなどの別の同調／復号手段であってもよい。さらに、本発明の受信デバイスは、オーディオコンテンツ、ビデオコンテンツ、オーディオ／ビデオコンテンツなどのコンテンツを受信できるどんなデバイスも含み得る。
【００１３】
一実施形態では、図１のコンテンツ配信システム１００は、リテール広告ネットワークの一部であり得る。例えば、図２は、本原理の一態様による、リテール広告を提供するリテール広告ネットワークを示すハイレベルのブロック図である。図２の広告ネットワーク２００では、広告ネットワーク２００とサーバシステム１００は、エンターテイメントコンテンツ、ニュース、及びインストア設定における同様のコンシューマ情報コンテンツとともに、音楽レコーディング、ホームビデオ、製品実演、広告コンテンツなどのカタログ配布、配信、プレゼンテーション、及び利用追跡を、提供するソフトウェアとハードウェアの組み合わせを利用する。コンテンツは、圧縮または非圧縮の、ビデオとオーディオストリームフォーマット（ＭＰＥＧ２、ＭＰＥＧ４パート１０／ＡＶＣ−Ｈ．２６４、ＶＣ−１、ウィンドウズ（登録商標）メディアなど）で表したコンテンツを含んでもよいが、本発明のシステムはこうしたフォーマットのみの利用に限定されない。
【００１４】
一実施形態では、インストア広告ネットワーク２００とコンテンツ配信／サーバシステム１００の様々な要素を制御するソフトウェアは、ウィンドウズ（登録商標）環境を用いた３２ビットオペレーティングシステム（例えば、MSウィンドウズ（登録商標）やXウィンドウ（登録商標）オペレーティングシステム）と、高性能コンピューティングハードウェアを含み得る。広告ネットワーク２００は、分散アーキテクチャを利用して、集中コンテンツ管理を提供し、また一実施形態では衛星（または、ワイドエリアネットワーク（WAN）、インターネット、一連のマイクロ波リンク、または同様のメカニズムなどのその他の方法）及びインストアを介した配信制御を提供できる。
【００１５】
図２に示した通り、リテール広告ネットワーク２００とコンテンツ配信システム１００用のコンテンツは、アドバタイザ２０２、レコーディング企業２０４、映画スタジオ２０６、その他のコンテンツプロバイダ２０８により提供され得る。アドバタイザ２０２は、製品生産者、サービスプロバイダ、これらを代理する広告会社などである。アドバタイザ２０２アドバタイザ２０２からの広告コンテンツは、コマーシャル、「インフォマーシャル（info-mercials）」、製品情報、及び製品実演などを含むオーディオビジュアルコンテンツにより構成され得る。
【００１６】
レコーディング会社２０４は、レコードレーベル、音楽出版社、ライセンシング／出版会社（例えば、ＢＭＩやＡＳＣＡＰ）、アーティスト個人、その他の音楽関連コンテンツのコンテンツ源であり得る。レコーディング会社２０４は、音楽クリップ（レコーディングした音楽の短い一部分）、音楽ビデオクリップなどのオーディオビジュアルコンテンツを提供する。映画スタジオ２０６は、映画スタジオ、映画製作会社、評論家（publicist）、その他の映画産業に関係するコンテンツ源であり得る。映画スタジオ１０６は、映画クリップ、事前に録画した俳優・女優とのインタビュー、映画レビュー、「舞台裏」プレゼンテーションなどのコンテンツを提供できる。
【００１７】
他のコンテンツプロバイダ２０８は、図１のコンテンツ配信システム１００などを介して配信し、表示されるビデオ、オーディオ、またはオーディオビジュアルコンテンツのその他のプロバイダであり得る。
【００１８】
一実施形態では、コンテンツは、例えば、従来の記録メデイア（テープ、ＣＤ、ビデオなど）を用いて、ネットワーク管理センタ（ＮＭＣ）２１０を介して調達される。ＮＭＣ２１０に供給されたコンテンツは、例えばローカル配信システム１００への配信に好適な形式でコンパイルされる。ローカル配信システム１００は、コンテンツを配信し（店内などの）ローカルサイトで表示する。
【００１９】
ＮＭＣ２１０は、受信したコンテンツをデジタル化し、デジタル化データファイル２２２の形式でネットワークオペレーションズセンタ（ＮＯＣ）２２０に提供する。留意すべき点として、データファイル２２２は、デジタル化コンテンツとして説明するが、ストリーミングオーディオ、ストリーミングビデオなどの情報であってもよい。コンパイルされＮＭＣ２１０により受信されたコンテンツは、コマーシャル、バンパー（bumpers）、グラフィックス、オーディオなどを含み得る。全てのファイルは、一意的に識別できるように命名されることが好ましい。より具体的には、ＮＭＣ２１０は、ストアロケーションなど特定のサイトに宛ての配信パックを生成し、スケジュールによって、またはオンデマンドでストアに配信する。配信パック（distribution packs）は、（サイトのシステムが初めて初期化されるのでない場合）利用するとき、すでにオンサイトにある既存のコンテンツを置き換え、または改良するコンテンツを含む（初めて初期化される場合、配信されたパッケージはそのサイトの最初のコンテンツとなる）。あるいは、ファイルは別々に圧縮され、転送されてもよいし、ある種のストリーミング圧縮プログラムを利用してもよい。
【００２０】
図２に示した実施形態では、ＮＯＣ２２０は、ひとまとまりとしてモニタされ、及び／または制御される一群のサーバを規定するリテールネットワークマネージャ（ＲＮＭ）２２４を含む。すなわち、本発明の一実施形態では、デバイスグループ制御プロトコル（ＤＧＣＰ）に従ってＲＮＭ２２４によりグループ化される。デバイスグループ制御プロトコルは、米国特許商標庁に２００７年４月４日に出願された共有に係る仮特許出願第６０／９２１７１４号と、米国を指定してＰＣＴにより２００７年６月１３日に出願された国際出願第０７／０１３９４９号に記載されている。両文献の発明の名称はともに「デバイスグループ制御」である。両文献はその全体をここに参照援用する。
【００２１】
すなわち、デバイスグループ制御プロトコルに従って、各サーバを、少なくとも１つのグループ（それ自身）に所属させ、他の多くのグループにも所属させるように構成することができる。このように、コマンドや要求を、１つまたは複数のサーバを含むグループごとに宛てる（target）ことができる。このように、一グループの各サーバは、同じブロードキャストチャネルまたはマルチキャストチャネルを用いて、送受信する。上記の発明の様々な実施形態では、サーバは、必要なだけ多くのグループのメンバーになることをサポートできる。また、サーバは、上記のプロトコルまたは外部手段を用いて、グループのメンバーになったり、メンバーから抜けたりするように構成できる。外部手段には、コンフィギュレーションファイルと、その他のＳＮＭＰやウェブ構成ページなどのトランザクションがある。本発明のさまざまな実施形態では、すべてのストアが、あるジップコードに属する、ある時間帯に属する、ある州に立地する、ある地域に立地する、ある人口統計的特徴を有するなどの共通の属性により、サーバをグループ化できる。システムのグループは、一意的な識別子を割り当てられ、一単位として通信、モニタ、制御を行う。
【００２２】
図２のリテール広告ネットワーク２００では、ＮＯＣ２２０は、通信ネットワーク２２５を介して、コマーシャルセールスアウトレット２３０にある各サーバ／コンテンツ配信システム１００に、デジタル化したデータファイル２２２を送信する。各サーバ１００は、（ＮＯＣ２２０などからの）入来メッセージを調べて、そのメッセージが適用されるターゲットグループにそのサーバが属しているか判断できるように構成されたグループ識別子ユニット１０２を含む。
【００２３】
本発明の様々な実施形態では、通信ネットワーク２２５はどんな技術で実施してもよい。例えば、本発明の一実施形態では、通信ネットワーク２２５は、コマーシャルセールスアウトレット２３０などの各アプリケーションサーバシステム１００にデジタル化したデータファイル２２２を配信する衛星リンク（衛星ＩＰネットワーク）を含む。かかる構成により、有利にも、コンテンツを様々なロケーションに同時にマルチキャストして配信することができる。あるいは、インターネットを用いて、コマーシャルセールスアウトレット２３０にオーディオビジュアルコンテンツを配信し、そのコマーシャルセールスアウトレット２３０からフィードバックを得ることができる。本発明の他の実施形態では、専用線、マイクロ波ネットワークその他のメカニズムを用いるなどの通信ネットワーク２２５を実施するその他の方法や構成を用いることができる。
【００２４】
インストアなどのローカルレベルでは、コンテンツ配信システム１００のサーバ１１０は、配信パックなどのコンテンツを受信して、適宜そのコンテンツをセットトップボックス１２０とディスプレイ１３０とスピーカシステム１３５などの様々な受信器にインストア配信することができる。すなわち、コンテンツ配信システム１００では、コンテンツは、受信されストリーミング用に構成される。ストリーミングは、共に、または調和して動作するように構成された１つ以上のサーバにより実行できる。ストリーミングコンテンツは、ストアなどのセールスアウトレット２３０中のいろいろなロケーションや製品用に構成されたコンテンツを含み得る。例えば、セットトップボックス１２０とディスプレイ１３０と様々なスピーカシステム１３５とは、セールスアウトレット２３０中のあるロケーションに位置し、各セットトップボックスとディスプレイのロケーションから所定距離内にある製品に関するコンテンツを表示し、オーディオをブロードキャストするように構成され得る。
【００２５】
コンテンツ配信システム１００のサーバ１１０は、コンテンツを受信して、テキスト、オーディオ、ビデオ、及びオーディオ／ビデオのストリーム（コンテンツチャネルなど）を生成し、ストア中のレシーバに送信する。ストリームは、無線周波数配信に変調されたオーディオ、ビデオ、及び／またはオーディオ／ビデオの個別チャネルでもよいし、ユニキャストまたはマルチキャストインターネットプロトコル（ＩＰ）ネットワーク内のデータフローとして送信してもよい。これらのストリームは、同じ論理的に一組の制御ソフトウェアで、１つ以上のサーバに始まるものであってもよい。
【００２６】
例えば、本発明の一実施形態では、図１のコンテンツ配信システム１００のサーバ１１０などの本発明のサーバは、受信したストリームをデバイスグループ制御プロトコルに従って送信できる。デバイスグループ制御プロトコルは、米国特許商標庁に２００７年４月４日に出願された共有に係る仮特許出願第６０／９２１７１４号と、米国を指定してＰＣＴにより２００７年６月１３日に出願された国際出願第０７／０１３９４９号に記載されている。両文献の発明の名称はともに「デバイスグループ制御」である。両文献はその全体をここに参照援用する。
【００２７】
すなわち、サーバを、デバイスグループ制御プロトコルにより情報を送信するように構成することができる。レシーバは、かかるプロトコルを用いて、少なくとも１つのグループ、すなわち自分自身と、その他の多くのグループに属するように構成することもできる。このように、コマンド、要求、またはコンテンツの通信を、１つまたは複数のデバイスを含むグループごとに宛てる（target）ことができる。このように、一グループの各デバイスは、同じブロードキャストチャネルまたはマルチキャストチャネルを用いて、送受信する。上記の発明の様々な実施形態では、デバイスは、必要なだけ多くのグループのメンバーになることをサポートできる。また、デバイスは、上記のプロトコルまたは外部手段を用いて、グループのメンバーになったり、メンバーから抜けたりするように構成できる。外部手段には、コンフィギュレーションファイルと、その他のＳＮＭＰやウェブ構成ページなどのトランザクションがある。また、上記の発明のいくつかのアプリケーションでは、グループメンバーシップを予め設定することも望ましい。
【００２８】
かかるプロトコルを用いる一実施形態では、ストックＤＧＣＰペイロードが、リアルタイムストリームプロトコル（ＲＴＳＰ）DESCRIBE応答と同様のフォーマットを用いて、セッション記述プロトコル（ＳＤＰ）データブロックをセットトップボックス（ＳＴＢ）に配信する。ＳＤＰはＩＥＴＦ（http://tools.ietf.org/html/rfc2327）により規定されている。
【００２９】
かかるデータブロックは次のフォーマットを含み得る：
c=IN IP4 233.192.0.101
a=control:rtsp://169.254.1.1/view0
a=type:scheduled
m=video 49162 RTP/AVP 33
a=fmtp:33 program_number=1
a=framerate:29.97
a=orient:portrait。
【００３０】
上記のデータは次を含む：
IP address and port (233.192.0.101/49162)
Controlling RTSP URL (rtsp://169.254.1.1/view0)
Stream type (video)
RTP profile type (33 - MPEG2 Transport Stream)
Video frame rate (29.97)
Video orientation (portrait)。
【００３１】
しかし、かかるデータブロックは次に関する情報を含んでいない：
ビデオ解像度
ビデオアスペクト比（４：３または１６：９またはその他）
ビデオコーデック
ビデオビットレート
オーディオコーデック
オーディオビットレート
ＭＰＥＧ２トランスポートストリームなどを用いるアプリケーションでは、含まれていない情報が重要である。一通信ではビデオコーデックはＭＰＥＧ２であるが、他の一通信では、ビデオコーデックはＨ．２６４（ＭＰＥＧ４パート１０）であり得る。また、オーディオコーデックはＭＰＥＧオーディオを含むものであってもよいが、別の実施形態ではドルビーＡＣ３を含むものであってもよい。
【００３２】
このように、本発明の様々な実施形態により、ＳＴＢやスピーカなどのレシーバと通信するときの遅延を最小にするため、上記の情報の少なくとも一部、またはそれ以上を、チューニングコマンドの一部としてレシーバに送信しなければならない。より具体的には、本発明の様々な実施形態では、レシーバに追加情報を送信することにより、そのレシーバが新しいストリームにチューニングするのにかかる時間を短くできる。
【００３３】
本発明の一実施形態では、セッション記述プロトコル（ＳＤＰ）拡張を用いて、データを送り、レシーバと通信する。かかる実施形態では、ＳＤＰを使用するため、メディア属性は次のものを含む：
a=vcodec:mpeg2-in-mpeg2ts
a=vcodecrate:19.39mbps
a=vcodecaspect:16x9
a=vcodecresolution:1920x1200
a=acodec:ac3
a=acodecrate:200kbps
a=acodecchannels:5.1
本発明の別の一実施形態では、バイナリＤＧＣＰペイロードは、上記と同様の、ビットフィールドで定義された情報を有してもよい。
【００３４】
例えば、現在のシステムアーキテクチャでは、最初にトランスポートストリームを受け取り、そのトランスポートストリーム（ＭＰＥＧトランスポートストリームなど）を解析して、ビデオコーデックとオーディオコーデックとコーデックパラメータとを調べる。これに０．５秒から数秒の時間がかかる。本発明の様々な実施形態では、有利にも、従来の方法と比較してチューニング時間を短縮できる。
【００３５】
従来の方法に対する利点を示すため、まず、データを受信して解析する従来の方法のフロー図を説明する。次に、本発明の一実施形態によるレシーバのチューニングの改善方法を説明する。図３は、データを受信して解析する従来の方法を示すフロー図である。方法３００は、ステップ３０２から始まり、ＲＴＳＰまたはＤＧＣＰを用いて、ストリームを識別するセッション記述プロトコル（ＳＤＰ）ブロックを受信する。かかるＳＤＰの一例としては：
c=IN IP4 233.192.0.101
a=control:rtsp://169.254.1.1/view0
a=type:scheduled
m=video 49162 RTP/AVP 33
a=fmtp:33 program_number=1
a=framerate:29.97
a=orient:portrait。
そしてステップ３０４に進む。
【００３６】
ステップ３０４において、ＳＤＰブロックを解析（parse）して、ＲＴＰセッションを送信するＩＰアドレスとポートを決定する。上記の例では、ＩＰアドレスは解析の結果、233.192.0.101ポート49162である。そしてステップ３０６に進む。
【００３７】
ステップ３０６において、ＳＤＰブロックを解析して、ＲＴＰペイロードタイプを決定する。上記の例では、ペイロードタイプは、解析の結果、ＲＴＰ／ＡＶＴタイプ３３であり、これはＭＰＥＧ２トランスポートストリームである。そしてステップ３０８に進む。
【００３８】
ステップ３０８において、受信ソケットをオープンにして、ＲＴＰストリームからパケットの受信を開始する。そしてステップ３１０に進む。
【００３９】
ステップ３１０において、解像度などのパラメータを含む、オーディオとビデオのタイプについてストリーム中のＭＰＥＧシグネチャ（signature）を検出するのに十分なパケットを待ってから解析する。コーデックに関するこれらの詳細情報が分かると、ステップ３１２に進む。
【００４０】
ステップ３１２において、オーディオ・ビデオデコーダチップを初期化して、復号を開始する。そしてステップ３１４に進む。
【００４１】
ステップ３１４において、集積したパケットの再生を開始する。留意点として、これらのパケットは受信当初からバッファされていたものであってもよい。この時、デコーダチップは、圧縮ビットストリームを復号し、ディスプレイとスピーカなどの再生デバイスに出力するオーディオとビデオにする。このような従来技術の方法３００では、ＳＤＰを受信してからビデオとオーディオを視聴するまでの遅延は、数分の一秒から数秒であり、これはＭＰＥＧトランスポートストリームをどのくらい解析して、デコーダチップを初期化するのに必要なデータを求めねばならないかに依存する。
【００４２】
図４は、本発明の一実施形態によるレシーバのチューニングの改善方法４００を示すフロー図である。方法４００は、ステップ４０２から始まり、ＲＴＳＰまたはＤＧＣＰを用いて、ストリームを識別するセッション記述プロトコル（ＳＤＰ）ブロックを受信する。かかるＳＤＰの一例としては：
c=IN IP4 233.192.0.101
a=control:rtsp://169.254.1.1/view0
a=type:scheduled
m=video 49162 RTP/AVP 33
a=fmtp:33 program_number=1
a=framerate:29.97
a=orient:portrait
a=vcodec:mpeg2-in-mpeg2ts
a=vcodecrate:19.39mbps
a=vcodecaspect:16x9
a=vcodecresolution:1920x1200
a=acodec:ac3
a=acodecrate:200kbps
a=acodecchannels:5.1。
【００４３】
上記のＳＤＰの例から明らかなように、本発明の様々な実施形態では、事前に追加データを提供して、デコーダチップをすぐに初期化する。そしてステップ４０４に進む。
【００４４】
ステップ４０４において、ＳＤＰブロックを解析（parse）して、ＲＴＰセッションを送信するＩＰアドレスとポートを決定する。上記の例では、ＩＰアドレスは233.192.0.101であり、ポートは49162である。そしてステップ４０６に進む。
【００４５】
ステップ４０６において、ＳＤＰブロックを解析して、ＲＴＰペイロードタイプを決定する。上記の例では、ＲＴＰ／ＡＶＴタイプは３３であり、これはＭＰＥＧ２トランスポートストリームである。そしてステップ４０８に進む。
【００４６】
ステップ４０８において、ＳＤＰブロックを解析して、オーディオコーデックとビデオコーデックのパラメータの詳細を求める。本発明の様々な実施形態では、追加のコーデック情報により、デコーダチップをすぐに初期化でき、レシーバのチューニング時間を短縮できる。すなわち、上記の従来方法では、解像度などのパラメータを含む、オーディオ・ビデオタイプのストリーム中のＭＰＥＧシグネチャを検出するために、十分多くのパケットを待ってから解析するが、これとは対照的に、本発明の実施形態では、ＳＤＰブロックを解析して、オーディオコーデックとビデオコーデックのパラメータの詳細を求め、これによりデコーダチップをすぐに初期化できるようにする。ＳＤＰブロックを解析してオーディオコーデックとビデオコーデックのパラメータの詳細を求めてから、ステップ４１０に進む。
【００４７】
ステップ４１０において、オーディオ・ビデオデコーダチップを初期化して、復号を開始する。そしてステップ４０４に進む。
【００４８】
ステップ４１２において、受信ソケットをオープンにして、ＲＴＰストリームからパケットの受信を開始する。そしてステップ４１４に進む。
【００４９】
ステップ４１４において、メディアパケットを、到着したら再生する。デコーダチップは、圧縮されたビットストリームを、ディスプレイとスピーカなどの再生デバイスに出力するオーディオ及びビデオとして復号する。本発明の実施形態では、ＳＤＰを受信してからビデオとオーディオを視聴できるまでの遅延が、上記の従来方法３００と比較して、短縮される。その理由は、少なくともＭＰＥＧトランスポートストリームを解析するまでの待ち時間がないからである。
【００５０】
本発明の一実施形態では、本発明による（オーディオおよび／またはビデオコンテンツなどの）コンテンツを識別する、レシーバ／再生デバイスにより利用される情報は、図１のコンテンツ配信システム１００のサーバ１１０などのコンテンツサーバから、および／または図２のリテール広告ネットワーク２００のＮＯＣ２２０および／またはＮＭＣ２１０から、レシーバ／再生デバイスに送信できる。すなわち、本発明の一実施形態では、配信するコンテンツを識別する情報は、本発明のサーバのメモリ（図示せず）に記憶でき、コンテンツとともに、および／またはチューニングコマンドの一部として、レシーバに送信できる。すなわち、本発明のサーバは、上記の通り、サーバの様々な動作機能を実行するプロセッサ（図示せず）を含み、上記の通り、コンテンツおよび／またはそのコンテンツを識別する情報を記憶するメモリをさらに含む。
【００５１】
レシーバが受信コンテンツの再生を開始するのにかかる時間を短縮する方法、装置、システムの様々な実施形態を説明したが、（これらは例示であって限定ではなく、）当業者は上記の教示を考慮して修正や変形をすることができることに留意すべきである。それゆえ、当然のことながら、本発明の範囲と精神において、開示した本発明の実施形態を変更することができる。上記は本発明の様々な実施形態に関するが、本発明のその他の実施形態やさらに別の実施形態を、本発明の基本的な範囲から逸脱することなく工夫することができる。
【特許請求の範囲】
【請求項１】
コンテンツを受信したレシーバが、識別情報なしにコンテンツを受信した場合と比較して短い遅延で前記コンテンツの再生を開始できるように、前記コンテンツとともに、前記コンテンツを識別する情報を供給する段階を有する、方法。
【請求項２】
前記コンテンツがオーディオ／ビデオコンテンツを含み、前記コンテンツを識別する情報がオーディオおよびビデオコーデックパラメータを含む、請求項１に記載の方法。
【請求項３】
前記コーデックパラメータによりデコーダの初期化ができ、それによりレシーバのチューニング時間が短くなる、請求項２に記載の方法。
【請求項４】
前記コンテンツを識別する情報を、セッション記述プロトコルデータパックでレシーバに送信する、請求項１に記載の方法。
【請求項５】
前記コンテンツを識別する情報により、デコーダが複数のコンテンツパケットを解析して前記コンテンツのオーディオおよびビデオのタイプを識別する必要がなくなる、請求項１に記載の方法。
【請求項６】
前記コンテンツとそれを識別する情報を、デバイスグループ制御プロトコルを用いて少なくとも１つのレシーバに送信する、請求項１に記載の方法。
【請求項７】
前記コンテンツとそれを識別する情報をチューニングコマンドの一部としてレシーバに送信する、請求項１に記載の方法。
【請求項８】
再生するコンテンツを識別する情報を受信する段階と、
識別情報なしにコンテンツを受信した場合と比較して短い遅延で前記コンテンツを再生できるように、前記受信した情報を用いて、デコーダを初期化するために前記コンテンツを識別する段階とをさらに有する、方法。
【請求項９】
前記コンテンツがオーディオ／ビデオコンテンツを含み、前記コンテンツを識別する情報がオーディオおよびビデオコーデックパラメータを含む、請求項８に記載の方法。
【請求項１０】
前記コンテンツを識別する情報を、セッション記述プロトコルデータパックで再生デバイスに送信する、請求項８に記載の方法。
【請求項１１】
前記コンテンツを識別する情報により、デコーダが複数のコンテンツパケットを解析して前記コンテンツのオーディオおよびビデオのタイプを識別する必要がなくなる、請求項８に記載の方法。
【請求項１２】
前記コンテンツとそれを識別する情報を、デバイスグループ制御プロトコルを用いて少なくとも１つの再生デバイスに送信する、請求項８に記載の方法。
【請求項１３】
前記コンテンツとそれを識別する情報をチューニングコマンドの一部として受信する、請求項８に記載の方法。
【請求項１４】
受信ソケットをオープンして、前記コンテンツを受信する段階と、
前記コンテンツを、受信したら再生する、請求項８に記載の方法。
【請求項１５】
記録されたマルチメディアコンテンツと、
前記マルチメディアコンテンツの再生デバイスが、識別情報なしにコンテンツを受信した場合と比較して短い遅延で前記マルチメディアコンテンツの再生を開始できるように記録された、前記マルチメディアコンテンツを識別する情報とを有する、コンピュータ読み取り可能媒体。
【請求項１６】
前記コンテンツがオーディオ／ビデオコンテンツを含み、前記コンテンツを識別する情報がオーディオおよびビデオコーデックパラメータを含む、請求項１５に記載のコンピュータ読み取り可能媒体。
【請求項１】
コンテンツを受信したレシーバが、識別情報なしにコンテンツを受信した場合と比較して短い遅延で前記コンテンツの再生を開始できるように、前記コンテンツとともに、前記コンテンツを識別する情報を供給する段階を有する、方法。
【請求項２】
前記コンテンツがオーディオ／ビデオコンテンツを含み、前記コンテンツを識別する情報がオーディオおよびビデオコーデックパラメータを含む、請求項１に記載の方法。
【請求項３】
前記コーデックパラメータによりデコーダの初期化ができ、それによりレシーバのチューニング時間が短くなる、請求項２に記載の方法。
【請求項４】
前記コンテンツを識別する情報を、セッション記述プロトコルデータパックでレシーバに送信する、請求項１に記載の方法。
【請求項５】
前記コンテンツを識別する情報により、デコーダが複数のコンテンツパケットを解析して前記コンテンツのオーディオおよびビデオのタイプを識別する必要がなくなる、請求項１に記載の方法。
【請求項６】
前記コンテンツとそれを識別する情報を、デバイスグループ制御プロトコルを用いて少なくとも１つのレシーバに送信する、請求項１に記載の方法。
【請求項７】
前記コンテンツとそれを識別する情報をチューニングコマンドの一部としてレシーバに送信する、請求項１に記載の方法。
【請求項８】
再生するコンテンツを識別する情報を受信する段階と、
識別情報なしにコンテンツを受信した場合と比較して短い遅延で前記コンテンツを再生できるように、前記受信した情報を用いて、デコーダを初期化するために前記コンテンツを識別する段階とをさらに有する、方法。
【請求項９】
前記コンテンツがオーディオ／ビデオコンテンツを含み、前記コンテンツを識別する情報がオーディオおよびビデオコーデックパラメータを含む、請求項８に記載の方法。
【請求項１０】
前記コンテンツを識別する情報を、セッション記述プロトコルデータパックで再生デバイスに送信する、請求項８に記載の方法。
【請求項１１】
前記コンテンツを識別する情報により、デコーダが複数のコンテンツパケットを解析して前記コンテンツのオーディオおよびビデオのタイプを識別する必要がなくなる、請求項８に記載の方法。
【請求項１２】
前記コンテンツとそれを識別する情報を、デバイスグループ制御プロトコルを用いて少なくとも１つの再生デバイスに送信する、請求項８に記載の方法。
【請求項１３】
前記コンテンツとそれを識別する情報をチューニングコマンドの一部として受信する、請求項８に記載の方法。
【請求項１４】
受信ソケットをオープンして、前記コンテンツを受信する段階と、
前記コンテンツを、受信したら再生する、請求項８に記載の方法。
【請求項１５】
記録されたマルチメディアコンテンツと、
前記マルチメディアコンテンツの再生デバイスが、識別情報なしにコンテンツを受信した場合と比較して短い遅延で前記マルチメディアコンテンツの再生を開始できるように記録された、前記マルチメディアコンテンツを識別する情報とを有する、コンピュータ読み取り可能媒体。
【請求項１６】
前記コンテンツがオーディオ／ビデオコンテンツを含み、前記コンテンツを識別する情報がオーディオおよびビデオコーデックパラメータを含む、請求項１５に記載のコンピュータ読み取り可能媒体。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２０１２−５１６１０６（Ｐ２０１２−５１６１０６Ａ）
【公表日】平成２４年７月１２日（２０１２．７．１２）
【国際特許分類】
【出願番号】特願２０１１−５４７８８２（Ｐ２０１１−５４７８８２）
【出願日】平成２１年７月１０日（２００９．７．１０）
【国際出願番号】ＰＣＴ／ＵＳ２００９／００４０３９
【国際公開番号】ＷＯ２０１０／０８５２３２
【国際公開日】平成２２年７月２９日（２０１０．７．２９）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
【公表日】平成２４年７月１２日（２０１２．７．１２）
【国際特許分類】
【出願日】平成２１年７月１０日（２００９．７．１０）
【国際出願番号】ＰＣＴ／ＵＳ２００９／００４０３９
【国際公開番号】ＷＯ２０１０／０８５２３２
【国際公開日】平成２２年７月２９日（２０１０．７．２９）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
[ Back to top ]