JP2014508439A - Ｄｌｎａｄｍｓサービスを使用してチャンネルをリモートからチューニングするための方法および装置 - Google Patents

Abstract

特定の一実施態様は、番組に関するステーション・コールサインまたはチャンネル番号を含むメタデータ要素を有する放送メディアアイテムを、サービスプロバイダーが番組を放送する特定の放送周波数および仮想チャンネルに相関付ける。コマンド文字列が、周波数および物理チャンネルをエンコードするようにアルゴリズム的に定義されて、ロックするための、および信号をデコードするためのチューナハードウェアに提示される。次いで、そのコマンド文字列を含むＵＲＬを生成することができる。その結果、ＤＬＮＡクライアントデバイスは、ＵＲＬおよびコントロールインターフェースのやり取りを通じてメディアレンダラーを放送メディアアイテムの再生に従事させることができる。

Description

本発明は、放送番組の再生を実行することに関する。より詳細には、本発明は、ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）環境における放送番組の再生をコントロールするための方法および装置に関する。

（関連出願の相互参照）
本出願は、２０１１年１月４日に出願された「A method for using a DLNA DMS service to present and manage tunable devices」という名称の米国特許仮出願第６１／４２９，５５０号の出願日の利益を主張するものであり、この仮出願は、その全体がすべての目的のために参照によって本明細書に組み込まれている。

放送コンテンツサービスプロバイダーおよびインターネットサービスプロバイダーは各自のコンテンツ配信システム内で相乗効果を見出そうとしている。しかし、放送中心のデバイスと、インターネット中心のデバイスとの間におけるオペレーションが、依然として問題である。たとえば、従来のリモートコントロールデバイスには、情報用の画面がない。テキスト、写真、およびビデオクリップを表示するタッチパッドおよびその他のインタラクティブなデバイスは、選択されたコンテンツをより高い解像度／機能のデバイス上に表示させるメカニズムを必要とする。

ある一般的な態様によれば、放送メディアアイテムにアクセスしたいという要求を受信し、放送メディアアイテムにチューニングするための放送パラメータを特定する。当該放送パラメータを表すコマンド文字列を特定し、当該要求に応答して送信する。

別の一般的な態様によれば、放送メディアアイテムにアクセスしたいという要求をメディアサーバへ送信する。コマンド文字列をメディアサーバから受信し、デコードして、放送メディアアイテムに関連付けられている放送パラメータを特定する。特定された放送パラメータに応答してチューナをコントロールして、放送メディアアイテムにアクセスする。

別の一般的な態様によれば、あるシステムは、ネットワークに接続するように適合されているメディアサーバと、放送メディアアイテムにアクセスするためのメディアクライアントとを含む。メディアサーバは、放送メディアアイテムにアクセスしたいという要求を受信し、放送メディアアイテムにチューニングするための放送パラメータを特定する。メディアサーバは、放送パラメータを表すコマンド文字列を特定し、要求に応答してコマンド文字列を送信する。メディアクライアントは、放送メディアアイテムにアクセスしたいという要求をメディアサーバへ送信し、メディアサーバからコマンド文字列を受信する。メディアクライアントは、コマンド文字列をデコードして、放送メディアアイテムに関連付けられている放送パラメータを特定し、その特定された放送パラメータに応答してチューナをコントロールして、放送メディアアイテムにアクセスする。

図面において、同様の参照番号は、各図を通じて同様のコンポーネントを指す。
本発明の一実施態様による、ＤＬＮＡデバイスが放送番組の再生を管理できるようにするための例示的な方法を示す流れ図である。 本発明のさらなる実施態様による例示的な方法を示す流れ図である。 本発明の一実施態様による、ＤＬＮＡデバイスが放送番組の再生を管理できるようにする方法を運用する例示的なシステムを示すブロック図である。

ＤＬＮＡ ＤＭＳ（Ｄｉｇｉｔａｌ Ｍｅｄｉａ Ｓｅｒｖｉｃｅ）仕様は、ＤＬＮＡクライアントデバイス（「ＤＬＮＡコントロールポイント」または「ＤＬＮＡクライアント」とも呼ばれる）が、ＵＲＬおよびコントロールインターフェースのやり取りを通じてメディアレンダラーをコンテンツの再生に従事させるための方法を提供する。ここで、抽象化（ａｂｓｔｒａｃｔｉｏｎ）とは、ＵＲＬが、ＬＡＮ内で利用可能な何らかのシステム上の格納されたファイルとして存在するビデオ、写真、またはオーディオ資産を代理していることである。

本発明の原理は、この抽象化を拡張して、チューニングデバイスを通じてアクセスされる放送オーディオ／ビデオストリームをレンダリングすることを可能にする。

ＤＭＳ仕様は、ＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ）イベントに関するメタデータ定義を提供し、クライアントが、放送予定の番組に関する時間およびチャンネルについての情報を求めてＤＭＳにクエリー（問い合わせ）を行うようにする。番組を再生したいと望むＤＭＳクライアントには、その番組を要求するために使用可能なＵＲＬが提示される。

しかし、放送番組は一般に、地上有線、衛星伝送、または無線ＲＦ伝送を介して特定の周波数上で信号を伝送することが優先し、ＩＰパケットネットワークへストリーミングされることはない。これらの伝送方法のそれぞれは、番組を受信するための信号上にロックすることができるチューニングデバイス、たとえばＳＴＢ（ｓｅｔ ｔｏｐ ｂｏｘ）を必要とする。

チューニングデバイス上で受信されるコンテンツをコンシューマー（消費者）が視聴できるようにしようとするＤＭＳデバイスは、利用可能な番組メタデータをチューニング周波数へと変換して要求される番組を監視し、かつＤＭＳコンシューマーにＵＲＬを提示して、要求された番組を再生するためにどの周波数にチューニングするべきかをシステムがわかるようにさせる。所与の周波数は、複数の番組をその上にエンコードさせることに留意されたい。所与の周波数内にある番組を特定するために、番組ＩＤ、たとえばＭＰＥＧ−２番組番号を使用することができる。

本発明の原理は、番組に関するステーション・コールサインまたはチャンネル番号を含むメタデータ要素を有するメディアアイテムを、サービスプロバイダーが番組を放送する特定の放送周波数および仮想チャンネルに相関付けるメカニズムを提供することによって、この問題を解決する。これは、ＤＬＮＡクライアントデバイスに到来する放送ＴＶデジタル通信上で利用可能な周波数をスキャンして、その周波数情報を、そのデジタル通信上でネットワークオペレータから受信したデジタルデータストリーム内に公開されているガイド情報と相関付けることによって、行うことができる。

ガイド情報は、ユーザ指向のデータ（たとえば、番組の説明、ステーション・コールサイン、チャンネル番号）と、テクニカルデータ（たとえば、仮想チャンネル番号、ＭＰＥＧ番組ＩＤ）とを有するということに留意されたい。たとえば、ＤＶＢ−Ｔシステムにおけるこれらのデータは、所与の周波数でＭＰＥＧストリーム内で放送することができ、定義されたＭＰＥＧ番組ＩＤ内に設定することができる。あらゆるネットワークオペレータは、この情報を、自分たちが定義するある程度カスタムな方式で供給する。プロバイダーは、ＩＰ接続を介してアクセス可能なデータベースから番組に関するさらに豊富な情報を供給することもできる。この情報は、ＤＶＢ−Ｔインターフェースを介してＭＰＥＧトランスポートストリーム内に含めて送信される基本情報コンテナ（ｂａｓｉｃ ｉｎｆｏｒｍａｔｉｏｎ ｃｏｎｔａｉｎｅｒ）よりもはるかに豊富になるであろう。

番組／チャンネル周波数は、共通なものではなく、放送プロバイダーによって固有に割り当てられるため、本発明の原理は、相関テーブルがその領域内で供給する手段も提供し、デバイスが、自己の周波数の相関付けを動的に把握することができる。

図１および図２は、ＤＬＮＡ ＤＭＳサービスを使用して放送番組の再生をコントロールするための例示的な方法１０を示す。例示的なデータストリームとしてＭＰＥＧストリームを、および例示的な放送システムとしてＤＶＢを使用して、どのようにして相関付けを動的に生成することができるかについて論じる。この方法は、その他のデータストリームフォーマットまたは放送システム（たとえば、ＡＴＳＣ、ケーブルネットワーク）が使用される場合でも容易に拡張することができるということに留意されたい。

ＭＰＥＧストリームを受信する際に、ＤＶＢトリプレット（すなわち、オリジナルネットワークＩＤ、トランスポートストリームＩＤ、およびサービスＩＤ）を物理チャンネル番号とともにＭＰＥＧストリームから抽出することができる。これは、物理チャンネルを、そのチャンネルのユーザのアイデアに相関付けるシステムに関して供給されるテーブルと相互参照される（１２）。

イベント（放送番組）に関するＣＭＳ（ｃｏｎｔｅｎｔ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ）内に格納されているメタデータは、コールサインおよび仮想チャンネル番号を含む。ＣＭＳは、ＵＲＬを構築するために、その供給されたテーブルから仮想チャンネル番号に関するＤＶＢトリプレットを見つけて、ＵＲＬ、例えば、http://192.168.1.100/MediaPlayer?source=dvb://fff.99dc.1&sink=decodeを生成する（１４）。この情報は、ＵＰｎＰ ＤＩＤＬ−Ｌｉｔｅドキュメント内にパッケージすることができ、ＵＰｎＰ ＤＩＤＬ−Ｌｉｔｅドキュメントは、テーブル１に示すように、「ｐｒｏｔｏｃｏｌＩｎｆｏ」プロパティー内の標準の「ｒｅｓ」要素の一部としてＤＬＮＡクライアントに送信される。セッションを介してコントロールの手段を得るために、ＵＲＬをセキュリティー手段としてエンコードすることができ、それによってクライアントは、どのようにしてＵＲＬを選択するかを推測することができない。

例えば、ＤＬＮＡクライアントは、これらの「ｒｅｓ」要素の選択を、自分がＳＴＢ上で見つけ出すＤＬＮＡ ＤＭＲ（ｄｉｇｉｔａｌ ｍｅｄｉａ ｒｅｎｄｅｒｉｎｇ）サービスに提示することができ、このＤＭＲサービスは、自分がｓｔｂｖｉｄｅｏプロトコルを受け入れる旨を示し、したがってクライアントは、ｈｔｔｐ：／／１９２．１６８．１．１００／ＭｅｄｉａＰｌａｖｅｒ？ｓｏｕｒｃｅ＝ｄｖｂ：／／ｆｆｆ．９９ｄｃ．１＆ｓｉｎｋ＝ｄｅｃｏｄｅの値を処理のためにネットワークに提示し、そして番組は、ＨＴＴＰサーバを通じたＭｅｄｉａＰｌａｙｅｒ ＣＧＩプログラムへの到達（ｐｌｕｍｂｉｎｇ）、そしてＭｅｄｉａＰｌａｙｅｒ ＣＧＩプログラムはソース／シンクパラメータに関する「Ｄｂｕｓｓｅｎｄ」コマンドを発することに起因して、ＳＴＢ上で再生を開始する。

ＤＬＮＡクライアントは、ＵＲＬを受信し（１６）、そのＵＲＬを、そのＵＲＬ内で指定されているＨＴＴＰサービスに、たとえば、ＨＴＴＰクライアントに提示するか（１８）、または局所的にデコードされることになる。その結果、番組の再生は、その指定された再生デバイスで実行される（１８）。ステップ１８について、図２においてさらに詳細に説明する。

図２を参照すると、ＨＴＴＰサービスは、「ＨＴＴＰ−Ｇｅｔ」要求を受け取る（２０）。周波数および番組ＩＤ情報、たとえばＤＶＢトリプレット情報を抽出するためにＵＲＬをデコードして、どの番組にチューニングするべきかを特定し（２２）、チューニングされたチャンネルがどこで再生されることになるかを特定する（２４）。

図２は、放送番組をどこで再生するかに関する２つの例示的な選択を示している。１つ目の選択肢は、ビデオをローカルに（例えば、ｐｒｏｔｏｃｏｌＩｎｆｏ＝“ｓｔｂｖｉｄｅｏ．．．”）、例えば、セットトップボックスに接続されているＴＶ上で再生することである（２６）。別の選択肢は、例えばｈｔｔｐライブ（例えば、ｐｒｏｔｏｃｏｌＩｎｆｏ＝“ｈｔｔｐｌｉｖｅ．．．”）でストリームアウトすることである（２８）。すなわち、デジタル番組は、ＩＰリンクを介してリモートメディアレンダリングデバイスへ導かれる。

ビデオ再生機能を備えたタブレットが、所与のチャンネルにチューニングするようＴＶに要求するためのＤＬＮＡコントロールポイントとして使用されると想定して、２つの例示的なユースケース、すなわち、ローカルでの再生およびリモートでの再生について以降で説明する。

第１のユースケースにおいては、タブレットが、あるチャンネルにチューニングするようＴＶに要求し、ＴＶが、そのチャンネルを再生する。タブレットは、ＤＬＮＡコントロールポイントとして機能して、ＤＬＮＡ ＤＭＳサービスと、ＳＴＢ上のＤＬＮＡ ＤＭＲサービスとを見つけ出す。タブレットは、自身がＤＭＳ内で見つけるコンテンツアイテムをＳＴＢ上で再生するようＤＭＲに要求する。ＤＭＲは、自身が使用するリソースメタデータを認識して、そのメタデータ内で識別されたチャンネルにチューニングすることにメディアプレーヤを従事させ、それに伴って、接続されているＴＶスクリーン上では、ビデオのレンダリングが行われる。

第２のユースケースにおいては、タブレットが、あるＴＶチャンネルにチューニングすることを要求し、タブレットが、そのチャンネルを再生する。タブレットは、ＤＬＮＡコントロールポイントとして機能して、ＤＬＮＡ ＤＭＳサービスを見つけ出す。タブレットは、ビデオを自身のローカルスクリーンへ導きたいと望み、サポートされているネットワークプロトコル（たとえば、ＨＴＴＰ、ＲＴＳＰ）でストリームを要求するというオプションをリソースメタデータ内で見つける。タブレットは、自身がサポートしているネットワークプロトコル用にエンコードされているＵＲＬを使用し、その提供されたＵＲＬを用いてＨＴＴＰ−Ｇｅｔオペレーションを行う。ＵＲＬパラメータは、「Ｄｂｕｓｓｅｎｄ」コマンドをメディアプレーヤへ送信するためにＨＴＴＰサーバによって処理され、そしてメディアプレーヤは、ＵＲＬパラメータ内で識別された要求されているチャンネルにチューニングし、要求されているプロトコルに従ってストリームを出力する。

テーブル２は、本発明の原理に従って構築される相関テーブルの一例である。テーブル２は、コールサイン（たとえば、ＣＳＰＡＮ）を、そのコールサイン／チャンネルに関する番組が放送される周波数マッピングに相関付けるデータを示している。デバイスチューナがそのチャンネル上にロックして、デコードするために適切な仮想チャンネルを選択する必要があるという情報は、「Ｄｂｕｓｓｅｎｄ」ロケータによって表すことができる。このケースにおいては、「Ｄｂｕｓｓｅｎｄ」ロケータは、メディアプレーヤが特定のチャンネルにチューニングするために必要とするＤＶＢトリプレット情報（たとえば、ｆｆｆｆ．９９３ｃ．１）を含む。チューナが番組を特定するために必要とする放送パラメータを含むコマンドシーケンスを編成するための多くの方法が存在し、したがって本発明の原理は、「Ｄｂｕｓｓｅｎｄ」ロケータに限定されるものではなく、それらの「Ｄｂｕｓｓｅｎｄ」ロケータは、例示的な一実施態様として本明細書で示され説明されているにすぎないということを当業者なら理解するであろう。たとえば、ＤＭＳがロケータにマップすることができる、ＤＭＳによって認識される一意の文字列を使用することができる。

周波数／コールサイン／チャンネルのマッピングは、放送プロバイダーによって、デジタル放送のビデオストリーム内に（たとえば、ＭＰＥＧ−２ストリーム内に）含めてエンコードされているテーブルを通じて放送されるサービス内に含めて供給されるということに留意することが重要である。本発明の原理は、このマッピング情報を読み取り、番組の視聴が所望される場合にチューナへ送信するための正しい「Ｄｂｕｓｓｅｎｄ」コマンドを確立するためにメタデータ内のコールサインまたはチャンネル番号データを使用してＭＰＥＧマッピングテーブルからの「Ｄｂｕｓｓｅｎｄ」コマンドを放送番組のメタデータに相関付ける。

放送プロバイダーは、所与の番組チャンネル（たとえば、ＥＳＰＮ、ＣＳＰＡＮ）を介して送信したいと希望する周波数およびチャンネル／仮想チャンネルを選択する。「Ｄｂｕｓｓｅｎｄ Ｌｏｃａｔｏｒ」の文字列は、周波数と、その周波数からデコードするための物理チャンネルとをエンコードするようにアルゴリズム的に定義されて、ロックするための、および信号をデコードするためのチューナハードウェアに提示される。

図３は、本発明の原理を実施するための例示的なシステム１１０を示す。ＤＬＮＡクライアント又はコントロールポイント１１２は、コンテンツをＤＭＳ１１６に要求する（１１４）。上述のように、ＤＬＮＡクライアントは、例えば、タブレット、スマートフォン、ポータブルミュージックプレーヤ、ＰＣなどとすることができる。ＤＭＳは、クライアントのコンテンツに対する要求を、コンテンツマネージメントシステム１２０へ転送する（１１８）。コンテンツマネージメントシステム１２０は、クライアントの検索基準を尊重するフィルタリングを用いて自身のコンテンツデータベース１４０を読み取る。コンテンツマネージメントシステムはまた、クライアントの要求を満たそうとする際にネットワークオペレータ３００からの番組ガイド情報３０４を利用するチャンネル変換テーブル１４２にアクセスする。

次いでコンテンツマネージメントシステム１２０は、適切なデータを収集し、それらのデータをＤＩＤＬ−Ｌｉｔｅ Ｓｃｈｅｍａ（１２４）（例えば、ｕｒｌ：ｓｃｈｅｍａｓ−ｕｐｎｐ−ｏｒｇ：ｍｅｔａｄａｔａ−１−０／ＤＩＤＬ−Ｌｉｔｅ／）にフォーマット設定／準備する（１２２）。ＤＩＤＬ−Ｌｉｔｅ Ｓｃｈｅｍａは、ＤＭＳ１１６へ転送して戻され、ＤＬＮＡクライアント１１２に返送する。

本発明の原理による方法の一態様に含まれることとして、要求を行うクライアントへ送信されることになるそれぞれのコンテンツアイテムごとにチャンネル変換テーブル１４２が参照され、ＤＩＤＬ−Ｌｉｔｅ「ｒｅｓ」要素タグが、ｈｔｔｐパラメータ文字列とともに設定され、そのｈｔｔｐパラメータ文字列によって、メディアプレーヤ１３４は、クライアントが再生を開始するためのコントロール要求を行う際にどのチャンネルにチューニングするべきかを指示されることになる。

ＤＬＮＡプロトコル内では、ＵＲＬ１２８が、ＤＬＮＡメディアレンダラー１３０に提示され、ＤＬＮＡメディアレンダラー１３０は、（ボリュームコントロール、一時停止などを提供するための）コントロールインターフェースをメディアプレーヤ１３４に提供し、メディアプレーヤ１３４は、実際にハードウェア上でのビデオ／オーディオのチューニングおよびレンダリングを実施する。ＵＲＬへとエンコードされるＤＶＢトリプレット情報（すなわち、この例においては「Ｄｂｕｓｓｅｎｄ Ｌｏｃａｔｏｒ」の文字列）は、ＤＬＮＡコントロールポイント１１２およびＤＬＮＡメディアレンダラー１３０を透過的に通過する。メディアプレーヤ１３４は、エンコードされたＵＲＬをＤＬＮＡメディアレンダラー１３０から受け入れるインターフェースを提供し、要求されている番組のチューニングおよび再生を、対応する放送３０２にアクセスしてチューニングを行うことによって実行する。メディアプレーヤ１３４は、ビデオ／オーディオ１３６を再生デバイス１３８に渡す。

本発明の一態様によれば、ＤＬＮＡメディアレンダラー１３０は、チューニングの要求がネットワークに接続されているデバイスからメディアプレーヤへ、どのようにして提示することができるかについての一例として提供される。ＤＬＮＡメディアレンダラー１３０はまた、メディアプレーヤ１３４からのステータス情報をＤＬＮＡコントロールポイント１１２に提示するための仲介者として、また、今度はメディアプレーヤ１３８に提示されるプレーヤコントロールコマンドをコントロールポイントから受信するための仲介者として機能する。この例においては、ＤＬＮＡメディアレンダラー１３０は、メディアプレーヤとのインターフェースを取るためのメッセージベースのＡＰＩを記述するソフトウェア仕様とすることができる。ＤＬＮＡコントロールポイント１１２は、オーディオ／ビデオ資産のレンダリングをコントロールできるようにするためにＤＬＮＡメディアレンダラー１３０と通信する。特定のチャンネルにチューニングの要求をどのようにしてメディアプレーヤに提示するかに関するその他の方法および／または実施態様は、本発明の範囲から逸脱することなく実施することができる。

メディアプレーヤ１３４は、本明細書では一例として使用されており、相関付けられているメディアアイテム／エンコードされているＵＲＬを介して、チューニングする先のチャンネルを設定するための適切なインターフェースがある限り、デジタル放送をチューニングすることができる任意のメディアプレーヤを利用することができるということを当業者なら理解するであろう。デジタル放送をチューニングすることができるメディアプレーヤの例は、ケーブルセットトップボックス、受信される衛星などとすることができる。

本明細書においてさらに考えられることとして、リモートクライアントが再生をローカルまたはリモートのレンダリング用に構成できるようにするために、メディアプレーヤウェブサービスを本発明の方法とともに利用することもできる。メディアプレーヤウェブサービスの詳細は、当業者によってよく知られており、理解されている。

一実施態様によれば、コンテンツマネージメントシステム１２０は、ネットワークオペレータ３００によって提示される番組ガイド情報３０４を使用し、この情報を、ＷＡＮを介したコンテンツ公開サービス２００を介して公開されているさらに包括的な情報ガイドとマージする。帯域幅の制約に起因して、ネットワークオペレータ３００によって送信される番組ガイド３０４には、スケジュールされている番組に関する限られた情報しかない。したがって、番組に関する視聴を行うためのさらに豊富な情報基盤をコンシューマーに提供するために取り込まれるレビュー、俳優、ディレクタ、番組ティーザーなどのさらなる情報は、ＷＡＮ上で利用可能なコンテンツ公開サービス（たとえば、ｉｍｄｂ．ｃｏｍ）から得られる。

理解できることであろうが、これらのサービスは、プロバイダー固有ではなく、放送を得るためのチューニング情報を含んでいない。コンテンツマネージメントシステム１２０は、公開サービス３００からメタデータを取り込み、そのメタデータを、ネットワークオペレータ３００が何を提供するかに基づいてフィルタリングし、それによって、ネットワークオペレータを通じて利用できない番組に関する情報は、ＬＡＮ内のクライアントに提示されるデータから削除される。

上記から明らかであろうが、コンテンツマネージメントシステムは、さまざまなプロバイダーからの情報のソースを集約すること、および利用可能な選ばれた番組コンテンツを提示することを可能にする処理機能を含み、それによって、ＤＬＮＡクライアントは、情報を検討して、その番組コンテンツの再生を選択することができ、その選ばれた番組コンテンツへのチューニングは、本発明の生成されたエンコードされているＵＲＬを通じて行われる。したがって、このプロセスの結果として、外部のチューニングステップは必要とされない。

このシステムの利点は、クライアントが、見るメディア番組を選択する際に、放送されているコンテンツ、ＬＡＮでストリーミングされているコンテンツ、ＷＡＮでストリーミングされているコンテンツ、またはローカルに格納されているコンテンツの間で区別を行う必要がないということである。この結果として得られる、クライアントデバイス用の簡略化されたユーザインターフェースは、メディアの再生を視聴およびコントロールするためのさまざまな複数のユースケースを構築することとは対照的に、１つの均一なユースケースを作成することを可能にする。ユーザは、クライアントデバイスおよびアプリケーションを通じてコンテンツを、そのソースを問わずに、これらのメカニズムを通じて視聴および再生することができる。

本明細書において列挙されているすべての例および条件を表す表現（ｃｏｎｄｉｔｉｏｎａｌ ｌａｎｇｕａｇｅ）は、本発明の原理、および、当技術分野を進展させることに対して本発明者によって寄与されたコンセプトを読みが理解する際に役立つための教示上の目的を意図されており、また、そのような具体的に列挙された例および条件に限定されるものではないと解釈されるべきである。

その上、本明細書において本発明の原理の原理、態様、および実施形態、ならびにその具体例について述べるすべての記述は、その構造上の均等物および機能上の均等物の両方を包含することを意図されている。加えて、そのような均等物は、現在知られている均等物、ならびに将来開発される均等物、すなわち、構造のいかんを問わず同じ機能を実行する開発されるあらゆる要素の両方を含むことが意図されている。

したがって、たとえば、本明細書において提示されているブロック図は、本発明の原理を具体化する例示的な回路の概念的な図を表しているということを当業者なら理解するであろう。同様に、あらゆるフローチャート、流れ図、状態遷移図、疑似コードなどは、コンピュータ可読メディアにおいて実質的に表すことが可能な、したがってコンピュータまたはプロセッサによって実行することが可能な（そのようなコンピュータまたはプロセッサが明示的に示されているか否かにかかわらず）さまざまなプロセスを表しているということがわかるであろう。

図において示されているさまざまな要素の機能は、専用のハードウェア、ならびに、適切なソフトウェアと関連付けてソフトウェアを実行できるハードウェアの使用を通じて提供することができる。それらの機能は、プロセッサによって提供される場合には、単一の専用のプロセッサによって、単一の共有プロセッサによって、または複数の個別のプロセッサ（そのうちのいくつかを共有することができる）によって提供することができる。その上、「プロセッサ」または「コントローラ」という用語の明示的な使用は、ソフトウェアを実行することができるハードウェアだけを指すと解釈されるべきではなく、ＤＳＰ（「ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ」）ハードウェア、ソフトウェアを格納するためのＲＯＭ（「ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ」）、ＲＡＭ（「ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ」）、および不揮発性ストレージを暗に含むことができるが、それらには限定されない。

その他のハードウェアを、通常のものであれ、および／またはカスタムのものであれ、含むこともできる。同様に、図において示されているあらゆるスイッチは、概念上のものにすぎない。それらの機能は、プログラムロジックのオペレーションを通じて、専用のロジックを通じて、プログラムコントロールと専用のロジックとの対話を通じて、または手動でさえ、実行することができ、特定の技術は、コンテキストからさらに具体的に理解された際に実施者によって選択可能である。

本明細書の特許請求の範囲においては、指定された機能を実行するための手段として表されているいかなる要素も、たとえば、ａ）その機能を実行する回路要素の組合せ、またはｂ）任意の形態のソフトウェア（したがって、ファームウェア、マイクロコードなどを含む）を、その機能を行うためにそのソフトウェアを実行するための適切な回路と組み合わせたものを含む、その機能を実行するあらゆる方法を包含することを意図されている。そのような特許請求の範囲によって定義される本発明の原理は、さまざまな列挙されている手段によって提供される機能が、特許請求の範囲が求める様式で組み合わされ結合されるという事実の中に存在する。したがって、それらの機能を提供することができるいかなる手段も、本明細書において示されている手段と同等であるとみなされる。

本明細書における、本発明の原理の「一実施形態」または「ある実施形態」、ならびに本発明の原理のその他の変形形態への言及は、その実施形態に関連して説明されている特定の機能、構造、特徴などが、本発明の原理の少なくとも１つの実施形態に含まれているということを意味する。したがって、「一実施形態において（における）」または「ある実施形態において（における）」という語句、ならびにその他のあらゆる変形が、本明細書を通じてさまざまな個所に登場しても、それらは、必ずしもすべて同じ実施形態を指しているとは限らない。

本発明の原理は、さまざまな形態のハードウェア、ソフトウェア、ファームウェア、専用プロセッサ、またはそれらの組合せで実装することができるということを理解されたい。本発明の原理は、ハードウェアとソフトウェアの組合せとして実装できることが好ましい。その上、そのソフトウェアは、プログラムストレージデバイス上で有形に具体化されるアプリケーションプログラムとして実装されることが好ましい。そのアプリケーションプログラムは、任意の適切なアーキテクチャーを含むマシンにアップロードして、そのマシンによって実行することができる。そのマシンは、１つまたは複数のＣＰＵ（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、および（１つまたは複数の）Ｉ／Ｏ（ｉｎｐｕｔ／ｏｕｔｐｕｔ）インターフェースなどのハードウェアを有するコンピュータプラットフォーム上に実装されることが好ましい。そのコンピュータプラットフォームはまた、オペレーティングシステムおよびマイクロ命令コードを含む。本明細書に記載されているさまざまなプロセスおよび機能は、オペレーティングシステムを介して実行される、マイクロ命令コードの一部、またはアプリケーションプログラムの一部（またはそれらの組合せ）のいずれかとすることができる。加えて、さらなるデータストレージデバイスおよび印刷デバイスなど、その他のさまざまな周辺デバイスをそのコンピュータプラットフォームに接続することができる。

添付の図において示されている構成要素であるシステムコンポーネントおよび方法ステップのうちのいくつかは、ソフトウェアで実装されることが好ましいため、システムコンポーネントどうし（またはプロセスステップどうし）の間における実際の接続は、本発明の原理がプログラムされる方法に応じて異なることがあるということをさらに理解されたい。本明細書の教示を与えられれば、関連した技術分野の標準的な技術者なら、本発明の原理のこれらおよび類似の実装形態または構成を想起できるであろう。

本発明の原理の根幹をなす新規な特徴を示し、説明し、指摘したが、説明されている方法および示されているデバイスの形態および詳細において、ならびにそれらの動作において、本発明の原理の趣旨から逸脱することなく、当業者によってさまざまな省略、置換、および変更を行うことができるということが理解できるであろう。たとえば、実質的に同じ機能を実質的に同じ方法で実行して同じ結果を達成する要素および／または方法ステップのすべての組合せは本発明の原理の範囲内であることが明らかに意図されている。その上、本発明の原理の任意の開示されている形態または実施態様に関連して示されているおよび／または説明されている構造および／または要素および／または方法ステップは、設計上の選択という一般的な問題として、その他の任意の開示、説明、または提案されている形態または実施態様に組み込むことができるということを認識されたい。したがって、添付の特許請求の範囲の範疇によって示されているようにのみ限定されることが意図されている。

Claims (32)

1. ネットワークに接続されるように適合されたメディアサーバをコントロールするための方法であって、
   放送メディアアイテムにアクセスするための要求を受信することと、
   前記放送メディアアイテムにチューニングするための放送パラメータを特定することと、
   前記放送パラメータを表すコマンド文字列を特定することと、
   前記要求に応答して前記コマンド文字列を送信することと
   を含む、前記方法。
2. 前記ネットワークはＬＡＮであり、
   前記受信するステップは、前記ＬＡＮに接続されたメディアクライアントデバイスから前記要求を受信することを備え、前記送信するステップは、前記コマンド文字列を前記メディアクライアントデバイスへ送信することを含む、請求項１に記載の方法。
3. 前記メディアサーバおよびメディアクライアントデバイスは、ＤＬＮＡ準拠デバイスである、請求項２に記載の方法。
4. 前記要求は、放送局と関連付けられるコールサインおよびチャンネル番号を少なくとも含む、請求項１に記載の方法。
5. 前記コマンド文字列を前記特定することは、前記メディアサーバ内に格納された相関テーブルを使用して、前記コールサインおよび前記チャンネル番号のうちの前記少なくとも１つを前記放送パラメータと相関付けることを含む、請求項４に記載の方法。
6. 前記放送パラメータは、放送周波数および仮想チャンネル番号のうちの少なくとも１つを含む、請求項１に記載の方法。
7. 前記放送パラメータは、ネットワークＩＤと、トランスポートストリームＩＤと、サービスＩＤとを含むＤＶＢトリプレット情報を含む、請求項１に記載の方法。
8. 前記コマンド文字列は、前記ネットワークに接続されたデバイスによって知られるエンコーディングアルゴリズムを使用して前記放送パラメータでエンコードされたＵＲＬを備える、請求項１に記載の方法。
9. 前記コマンド文字列は、Ｄｂｕｓｓｅｎｄ Ｌｏｃａｔｏｒの文字列を備える、請求項１に記載の方法。
10. メディアクライアントをコントロールして放送メディアアイテムにアクセスする方法であって、
    前記放送メディアアイテムにアクセスするための要求を、ネットワークに接続されたメディアサーバへ送信することと、
    前記メディアサーバからコマンド文字列を受信することと、
    前記コマンド文字列をデコードして、前記放送メディアアイテムに関連付けられた放送パラメータを特定することと、
    前記特定された放送パラメータに応答してチューナをコントロールして、前記放送メディアアイテムにアクセスすることと
    を備える、前記方法。
11. 前記メディアサーバおよびメディアクライアントデバイスは、ＤＬＮＡ準拠デバイスである、請求項１０に記載の方法。
12. 前記要求は、放送局と関連付けられるコールサインおよびチャンネル番号のうちの少なくとも１つを含む、請求項１０に記載の方法。
13. 前記放送パラメータは、放送周波数および仮想チャンネル番号のうちの少なくとも１つを含む、請求項１０に記載の方法。
14. 前記コマンド文字列は、ネットワークＩＤと、トランスポートストリームＩＤと、サービスＩＤとを含むＤＶＢトリプレット情報を含む、請求項１０に記載の方法。
15. 前記デコードすることは、前記メディアサーバ内に格納された相関テーブルを使用して前記放送パラメータを特定することを備える、請求項１０に記載の方法。
16. 前記コマンド文字列は、前記ネットワークに接続されたデバイスによって知られるエンコーディングアルゴリズムを使用して前記放送パラメータでエンコードされたＵＲＬを含む、請求項１０に記載の方法。
17. ネットワークに接続されるように適合されるメディアサーバであって、
    放送メディアアイテムにアクセスするための要求を受信することと、
    前記放送メディアアイテムにチューニングするための放送パラメータを特定することと、
    前記放送パラメータを表すコマンド文字列を特定することと、
    前記要求に応答して前記コマンド文字列を送信することと
    を行う、前記メディアサーバ
    を備える、装置。
18. 前記ネットワークはＬＡＮであり、前記メディアサーバは、前記ＬＡＮに接続されるメディアクライアントデバイスから前記要求を受信し、前記メディアサーバは、前記コマンド文字列を前記メディアクライアントデバイスへ送信する、請求項１７に記載の装置。
19. 前記メディアサーバおよびメディアクライアントデバイスは、ＤＬＮＡ準拠デバイスである、請求項１８に記載の装置。
20. 前記要求は、放送局と関連付けられるコールサインおよびチャンネル番号のうちの少なくとも１つを含む、請求項１７に記載の装置。
21. 前記コマンド文字列を前記特定することは、前記メディアサーバ内に格納された相関テーブルを使用して、前記コールサインおよび前記チャンネル番号のうちの前記少なくとも１つを前記放送パラメータと相関付けることを備える、請求項２０に記載の装置。
22. 前記放送パラメータは、放送周波数および仮想チャンネル番号のうちの少なくとも１つを含む、請求項１７に記載の装置。
23. 前記コマンド文字列は、前記ネットワークに接続されたデバイスによって知られるエンコーディングアルゴリズムを使用して前記放送パラメータでエンコードされたＵＲＬを含む、請求項１７に記載の装置。
24. 前記コマンド文字列は、ネットワークＩＤと、トランスポートストリームＩＤと、サービスＩＤとを含むＤＶＢトリプレット情報を含む、請求項２３に記載の装置。
25. 放送メディアアイテムにアクセスするためのメディアクライアントであって、
    前記放送メディアアイテムにアクセスするための要求を、ネットワークに接続されたメディアサーバへ送信することと、
    前記メディアサーバからコマンド文字列を受信することと、
    前記コマンド文字列をデコードして、前記放送メディアアイテムに関連付けられた放送パラメータを特定することと、
    前記特定された放送パラメータに応答してチューナをコントロールして、前記放送メディアアイテムにアクセスすることと
    を行う、前記メディアクライアント
    を備える、装置。
26. 前記メディアサーバおよびメディアクライアントデバイスは、ＤＬＮＡ準拠デバイスである、請求項２５に記載の装置。
27. 前記要求は、放送局と関連付けられるコールサインおよびチャンネル番号のうちの少なくとも１つを含む、請求項２５に記載の装置。
28. 前記放送パラメータは、放送周波数および仮想チャンネル番号のうちの少なくとも１つを含む、請求項２５に記載の装置。
29. 前記コマンド文字列は、ネットワークＩＤと、トランスポートストリームＩＤと、サービスＩＤとを含むＤＶＢトリプレット情報を含む、請求項２５に記載の装置。
30. 前記デコードすることは、前記メディアサーバ内に格納された相関テーブルを使用して前記放送パラメータを特定するステップを含む、請求項２５に記載の装置。
31. 前記コマンド文字列は、前記ネットワークに接続されるデバイスによって知られるエンコーディングアルゴリズムを使用して前記放送パラメータでエンコードされたＵＲＬを含む、請求項２５に記載の装置。
32. ネットワークに接続されるように適合されるメディアサーバであって、
    放送メディアアイテムにアクセスするための要求を受信することと、
    前記放送メディアアイテムにチューニングするための放送パラメータを特定することと、
    前記放送パラメータを表すコマンド文字列を特定することと、および
    前記要求に応答して前記コマンド文字列を送信することと
    を行う、前記メディアサーバと、
    前記放送メディアアイテムにアクセスするためのメディアクライアントであって、
    前記放送メディアアイテムにアクセスするための前記要求を前記メディアサーバへ送信することと、
    前記メディアサーバから前記コマンド文字列を受信することと、
    前記コマンド文字列をデコードして、前記放送メディアアイテムに関連付けられた前記放送パラメータを特定することと、および
    前記特定された放送パラメータに応答してチューナをコントロールして、前記放送メディアアイテムにアクセスすることと、
    を行う、前記メディアクライアントと
    を備える、するシステム。

Images