JP2006508431A - 網間接続されたメディア・システム内のクライアントによるメディア集約の方法および装置 - Google Patents

Abstract

ネットワーク・クライアントはメディア・システム内で利用可能なメディア項目を集約する。ネットワークは、少なくとも２つのメディア・サーバ・ノードを含む複数のノードからなる。クライアント・ノードはメディア・システム内で利用可能なメディア項目のリストを入手する内部要求を生成する。これに応答して、クライアント・ノードはネットワーク上の個別の各メディア・サーバ・ノードに対し、メディア項目のリストの要求を生成する。各メディア・サーバ・ノードはそのメディア項目のリストをクライアント・ノードに送信する。クライアント・ノードはメディア・サーバ・ノードの各々からのメディア項目のリストを集約する。こうして、メディア・システムで利用可能なメディア項目のリストがメディア・システム内の要求元クライアント・ノードに集約される。

Description

本発明は、異種のメディアを集約する分野に関し、より詳細には、複数の異種のデバイスのメディアをネットワーク上で集約するメディア・デバイスに関する。

コンピュータ、ディジタル・カメラ、およびインターネットの普及によって、ディジタル・メディアが作成および使用されるようになった。また、ディジタル・メディアによって、伝統的なアナログ・オーディオおよびビデオ・フォーマットはオーディオ・コンパクト・ディスク（ＣＤ）およびディジタル・ビデオ・ディスク（ＤＶＤ）の導入と浸透にとって代わられた。一般に、ディジタル・メディアは、オーディオ、ビデオ、および画像をバイナリ・ファイルで記憶するさまざまなフォーマットのデータからなる。これらのバイナリ・ファイルは、通常、ＣＤ−ＲＯＭ、ハード・ドライブ、フレキシブルディスクおよびメモリー・スティックなどのコンピュータ・デバイスがアクセスできる媒体上に記憶される。
一般に使用されるコンピュータ媒体へのディジタル・メディアの記憶によって、ディジタル・メディアの生成と転送とが容易になった。例えば、ディジタル・カメラを用いてディジタル写真を生成し、ディジタル写真をコンピュータに転送することが一般に浸透している。コンピュータ・ソフトウェアを用いてユーザはディジタル写真を加工できる。次いでユーザは、Ｅメールを用いて友人にディジタル写真を転送したり、ワールド・ワイド・ウェブからアクセスできるウェブ・サイト上にディジタル写真を掲載することができる。異なるデバイス間の接続性を利用するこれらのタイプの用途は、またディジタル・メディアの広範な人気に貢献している。
ディジタル・メディアはさまざまなフォーマットで記憶できる。ディジタル・メディアを再生または表示するには、そのディジタル・メディアのフォーマットに適合する特別のハードウェアまたはソフトウェアが必要である。例えば、一般的なＭＰ３フォーマットで記憶された音楽を聴くには、消費者は特別のＭＰ３プレーヤ（すなわち、汎用のコンピュータ上で実行されるソフトウェアまたは独立したＭＰ３プレーヤ）を持たねばならない。高画質のＤＶＤおよびさまざまな圧縮ベースのＭＰＥＧならびに自社開発の標準を含む多数のビデオ・フォーマットが存在する。さまざまなフォーマットのディジタル・ビデオを再生するには、消費者はディジタル・メディアの正しいフォーマットを読み取るデバイスを使用しなければならない。

ディジタル・メディアのフォーマットは多岐にわたるため、今日の多数のタイプのディジタル・メディアを再生または表示するには複数のタイプのデバイスが必要である。さまざまなフォーマットで記憶されたディジタル・メディアの再生はコンピュータ上ではさほど問題ではない。これは、コンピュータがソフトウェア・プログラムを用いてディジタル・メディアを再生できるためである。しかし、消費者は他のタイプのデバイスでメディアを再生したい場合がある。例えば、消費者は家庭のステレオ装置でディジタル・オーディオ・ファイルを再生し、テレビジョンにディジタル・ビデオを表示したい場合がある。現在、ステレオおよびテレビジョンはすべてのフォーマットのディジタル・メディアを再生するような機能を備えていない。したがって、さまざまなタイプのディジタル・メディアを１つのシステムに統合するメディア収束プラットフォームを提供することが望ましい。
ホーム・ネットワーク内のメディア集約は通常、サーバを用いて実行される。この技法では、サーバはホーム・ネットワーク上にあるすべてのメディア項目の存在を追跡する。例えば、メディア・サーバはパーソナル・コンピュータ上に構築できる。ディジタル・オーディオ・ジュークボックスはホーム・ネットワークに結合できる。ホーム・ネットワーク上で利用可能なすべてのオーディオのリストを集約するために、サーバ（パーソナル・コンピュータ）はディジタル・ジュークボックスからメディア項目のリストを受信する。これを実施するため、サーバはホーム・ネットワーク上で利用可能なすべてのオーディオのリストを入手する中央のポイントとして機能する。このサーバ集約アーキテクチャはサーバが常に利用可能であることが要求される。サーバは１つの障害ポイントになる。さらに、サーバを通してすべてのメディア項目を集約するとシステムの処理能力が制限される。
したがって、ホーム・ネットワーク上のすべてのメディア項目を獲得するサーバ集約に依存しないホーム・メディア・システムを生成することが望ましい。

ネットワーク・クライアントはメディア・システム内で利用可能なメディア項目を集約する。複数のノードがネットワークに結合されている。ノードはメディア・システムのサービスをサポートするデバイス、またはネットワークに少なくとも１つのメディア項目を提示するメディア・サーバを含むことができる。各ネットワーク・ノードはメディア・システムの１つまたは複数のサービスを提供する。少なくともノードの２つがメディア・サーバ・ノードを含む。メディア・サーバ・ノードはメディア項目をネットワークに提示する。例えば、メディア・サーバ・ノードはＭＰ３音楽を記憶するハード・ディスク・ドライブである。またはメディア・サーバ・ノードはメディア項目をダウンロードするインターネットへのゲートウェイである。クライアント・ノードはメディア・システム内で利用可能なメディア項目のリストを入手する内部要求を生成する。例えば、クライアント・ノードはテレビジョンを含むことができ、ユーザはテレビジョン画面上のシステムのすべての利用可能なメディア項目のリストを閲覧することを要求できる。
クライアントからのメディア項目の要求に応答して、クライアント・ノードはネットワーク上の各々の個々のメディア・サーバに対するメディア項目のリストの要求を生成する。一実施形態では、メディア・システムは発見プロトコルを用いてネットワーク上のメディア・サーバ・ノードの情報を得る。これに応答して、各メディア・サーバ・ノードはそのメディア項目のリストをクライアント・ノードに送信する。クライアント・ノードは各メディア・サーバ・ノードからのメディア項目のリストを集約する。集約プロセスで、クライアント・ノードは、集約されたリスト上で各メディア項目が他のメディア項目に対して一意的であるか否かを判定する。こうして、メディア・システム上で利用可能なメディア項目のリストはメディア・システム内の要求元クライアント・ノードに集約される。
一実施形態では、メディア・サーバからメディア項目のリストを入手するために、クライアント・ノードはメディア・サーバ上でサービスを起動する。メディア・システムは、メディア・システム内のノード間通信の複数のプロトコルをサポートする。第一に、クライアント・ノードはメディア・サーバがサポートするプロトコルを判定し、次いでそのプロトコルを用いてメディア・サーバからメディア項目のリストを入手する。また。メディア・システムはメディア・サーバ上で手順を呼び出す複数のリモート・プロシージャ・コール（「ＲＰＣ」）機構をサポートする。

（図面の簡単な説明）
図１は、本発明の一実施形態に従って構成されたメディア空間を示す図である。
図２は、デバイスを１つのメディア空間に統合する一実施形態を示す図である。
図３は、本発明の一実施形態によるクライアント・デバイスによるメディア集約を示す図である。
図４は、ネットワーク上のクライアントによるメディア集約の一実施形態を示す流れ図である。
図５は、メディア収束プラットフォーム・デバイス上で動作するソフトウェア構成要素の一実施形態を示すブロック図である。
図６は、メディア収束プラットフォームの例示としてのホーム・ネットワークを示すブロック図である。
図７は、メディア収束システム内のデバイスを発見する一実施形態を示す流れ図である。
図８は、メディア収束プラットフォーム・システムを通してデータ記憶にアクセスする一実施形態を示すブロック図である。
図９は、メディア収束プラットフォーム内にユーザ・インタフェースを実施する一実施形態を示すブロック図である。

メディア収束プラットフォーム：
本発明のユーザ・インタフェースは１人または複数のユーザに「メディア空間」内でメディアを管理し再生する効率的で容易な方法を提供する。本発明で使用する「メディア空間」は、１人または複数のユーザが使用する１つまたは複数のメディア・プレーヤに結合された１つまたは複数のメディア記憶装置を意味する。メディア記憶装置およびメディア・プレーヤの１つのメディア空間への統合によって、メディア空間内で利用可能なコンテンツの分散管理と制御とが可能になる。
図１は本発明の一実施形態に従って構成されたメディア空間を示す図である。図１に示すように、メディア空間１００は「ｎ」個のメディア記憶装置１１０を含み、ここで「ｎ」は１より大きいかそれに等しい任意の整数値である。メディア記憶装置１１０は任意のタイプのメディアを記憶する。一実施形態では、メディア記憶装置１１０は、ディジタル・オーディオ、ディジタル・ビデオ（例：ＤＶＤ、ＭＰＥＧなど）のようなディジタル・メディア、およびディジタル画像を記憶する。また、メディア空間１００は「ｍ」個のメディア・プレーヤ１２０を含み、ここで、「ｍ」は１より大きいかそれに等しい任意の整数値である。一般に、メディア・プレーヤ１２０はさまざまなタイプのメディアを再生し、および／または表示するのに適したデバイスである。例えば、メディア・プレーヤは、音楽を再生するステレオ・システムまたはＤＶＤを再生するか、またはディジタル写真を表示するテレビジョンを含むことができる。

図１に示すように、メディア記憶装置１１０はメディア・プレーヤ１２０に結合されている。メディア記憶装置１１０とメディア・プレーヤ１２０は、メディア記憶とメディア再生の別々の機能を示すために、図１には別々のデバイスとして示されている。ただし、メディア・プレーヤは記憶と再生の両方の機能を実行できる。例えば、メディア・プレーヤはディジタル・ビデオを記憶し再生するためのハード・ドライブを含むＤＶＤプレーヤを含むことができる。別の実施形態では、メディアの記憶およびメディアの再生／表示は別々のデバイスで実行される。この実施形態では、メディア・プレーヤ１２０はメディア記憶装置１１０に記憶されたコンテンツを再生する。例えば、メディア記憶装置「１」に記憶されたビデオ・クリップは、該当する「ｍ」個のメディア・プレーヤ１２０のいずれでも再生できる。
記憶装置１１０およびメディア・プレーヤ１２０は、管理構成要素１３０によって制御される。一般に、管理構成要素１３０を用いてユーザはメディア空間１００内で利用可能なメディアを集約し、整理し、制御し（例えば、追加、削除または変更し）、閲覧し、再生できる。管理構成要素１３０は複数のデバイスにまたがって実施できる。図１のメディア空間は、複数のユーザが異なるメディア・プレーヤによってメディアを再生／表示できることを示すために、複数のユーザ１４０を示している。システムは複数のメディア・プレーヤによって異なるメディアの再生をサポートする（すなわち、システムは同時に複数のメディア・ストリームを提供する）。ユーザ１４０は、また管理構成要素１３０を用いて、メディア空間内で利用可能なメディアを整理し、制御し、閲覧することができる。管理構成要素１３０はメディア空間内のすべてのメディアを管理し制御する分散手段を提供する。以下に詳述するように、収束メディア・プラットフォームは異種のデバイスが通信する（すなわち、異種のデバイスは異なるネットワーク・プロトコルを使用する）ための共通の言語を提供する。

図２は、デバイスを１つのメディア空間に統合する一実施形態を示す図である。この実施形態では、メディア空間２００は少なくとも１つのメディア・サーバ２１０を含む（例えば、メディア空間は多数のメディア・サーバを含むことができる）。メディア・サーバ２１０はメディア空間２００全体に分散するメディアを記憶する。さらに、メディア・サーバ２１０はメディア空間の構成要素を統合し、メディア空間にメディアを分散し、メディア空間の構成要素のユーザ・インタフェースを提供するためのシステム・ソフトウェアを記憶する。メディア・サーバ２１０は、テレビジョン２５０および２７０ならびにオーディオ・プレーヤ２４０（例えば、ステレオ・システム）を含むさまざまなタイプのメディア・プレーヤに結合されている。この実施形態では、メディア・サーバ２１０はメディア・マネージャ２８０および外部コンテンツ・プロバイダ２９０にも結合されている。

この実施形態では、メディア・サーバ２１０はメディア空間内でさまざまな機能を実現するソフトウェアを実行する。したがって、この構成では、メディア・サーバ２１０は「シック・クライアント」として機能する。ユーザはシステム・ユーザ・インタフェースを通してメディア収束プラットフォームの各機能にアクセスし制御する。ユーザ・インタフェースはシックおよびシン・クライアントならびにいくつかのメディア・プレーヤ（例えば、テレビジョン２５０および２７０）を使用する。一実施形態では、ユーザ・インタフェースは、ユーザがシステムの機能にアクセスするためのメディア・プレーヤ出力デバイス上に表示される複数の対話型画面を含む。ユーザ・インタフェースの画面はユーザが選択する１つまたは複数の項目を含む。ユーザがリモート制御デバイス（例えば、リモート・コントロール２６０）を用いてユーザ・インタフェースをナビゲートする。ユーザは、リモート・コントロールを用いてユーザ・インタフェースの画面の表示を制御し、画面に表示される項目を選択する。テレビジョンに表示されるユーザ・インタフェースを用いて、ユーザは、リモート・コントロールを用いて、メディア空間内で利用可能なメディアに関するさまざまな機能を実行できる。
メディア収束プラットフォームの構成要素はネットワークを通して統合される。例えば、図２の実施形態では、メディア・サーバ２１０は、ネットワーク２０５を通して、シン・オーディオ・クライアント２３０およびシン・ビデオ・クライアント２２０と通信する。ネットワーク２０５は無線ネットワークを含む任意のタイプのネットワークを含むことができる。例えば、ネットワーク２０５は、カテゴリ５のイーサネット１０／１００、ＨＰＮＡ、Ｈｏｍｅ Ｐｌｕｇ、ＩＥＥＥ ８０２．１１ｘ、ＩＥＥＥ １３９４、およびＵＳＢ１．１／２．０などの標準に従って構築されたネットワークを含むことができる。

図２の実施形態では、１つまたは複数のシン・ビデオ・クライアントがメディア空間に統合される。特に、シン・ビデオ・クライアント２２０はテレビジョン２７０のディジタル・メディアを再生するメディア・サーバ２１０に結合されている。シン・ビデオ・クライアント２２０はメディアを記憶しない。その代わりに、シン・ビデオ・クライアント２７０はメディア・サーバ２１０からメディアを受信し、メディアを処理してテレビジョン２７０（例えば、標準のテレビジョン）に表示または再生する。例えば、メディア・サーバ２１０はネットワーク２０５上でディジタル映画を送信し、シン・ビデオ・クライアントはディジタル映画を処理してテレビジョン２７０に表示する。一実施形態では、シン・ビデオ・クライアント２２０は「その場で」ディジタル映画を処理してテレビジョン２７０に再生するＮＴＳＣまたはＰＡＬフォーマットのビデオを提供する。シン・ビデオ・クライアント２２０は。テレビジョン２７０に統合できる。一実施形態では、ユーザ・インタフェースはメディア・サーバ２１０およびシン・ビデオ・クライアント２２０を用いて実施でき、テレビジョン２７０での表示を行う。この実施形態では、ユーザが、テレビジョン２７０のリモート・コントロールを用いて、テレビジョン２７０に表示された項目を選択してシステムに命令を出す。
また、メディア収束プラットフォーム・システムは任意選択で１つまたは複数のシン・オーディオ・クライアントをメディア空間に統合する。図２の実施形態では、シン・オーディオ・クライアント２３０はネットワーク２０５上でメディア・サーバ２１０からディジタル音楽（例えば、ＭＰ３フォーマット）を受信し、ディジタル音楽を処理して標準のオーディオ・システム２４０で再生する。一実施形態では、シン・オーディオ・クライアント２１０はユーザ・インタフェースとして使用する小型ディスプレイ（例えば、液晶ディスプレイ「ＬＣＤ」）およびボタンを含む。メディア・サーバ２１０はシン・オーディオ・クライアント２３０に表示する項目および項目の識別子を送信する。例えば、シン・オーディオ・クライアント２３０はオーディオ・システム２４０で再生するトラックのリストを表示できる。ユーザはシステムに命令するボタンを用いて画面に表示された項目を選択する。例えば、シン・オーディオ・クライアントの画面はメディア空間内で利用可能なアルバムのリストを表示でき、ユーザは、ボタンを用いて、ユーザ・インタフェースに選択したアルバムのトラックのリストを表示するように命令することができる。したがって、ユーザは画面に表示されたトラックを選択してオーディオ・システム２４０で再生することができる。

メディア・マネージャ２８０は、メディア収束プラットフォーム・システムのオプションの構成要素である。一般に、メディア・マネージャ２８０を用いてユーザはパーソナル・コンピュータ「ＰＣ」環境のメディアを整理し、ダウンロードし、編集できる。また、メディア・マネージャはメディア空間に統合するためにメディアを記憶する（すなわち、メディア空間内の他の構成要素が使用するためにメディアを記憶する）ことができる。一実施形態では、メディア・マネージャ２８０を用いてユーザはテレビジョン・ベースのユーザ・インタフェースで実施するのに適していないシステム機能をＰＣ上で実行することができる。
メディア空間を拡張して同じ汎用の物理的な近隣にある（例えば、家の）構成要素の外部に記憶されたメディアにアクセスすることができる。一実施形態では、メディア収束プラットフォーム・システムは外部ソースからのコンテンツをメディア空間内に統合する。例えば、図２に示すように、メディア・サーバ２１０はロ−カル・ネットワーク２０５の外部のコンテンツにアクセスできる。外部のコンテンツは、ディジタル音楽およびビデオなどの任意のタイプのメディアを含むことができる。メディア収束プラットフォーム・システムは広帯域接続（すなわち、高帯域幅通信リンク）を通して外部コンテンツ２９０に結合し、メディアが豊富なコンテンツをダウンロードすることができる。外部コンテンツはインターネットを利用してメディア収束プラットフォーム・システムに配信できる。または、外部コンテンツは、私設分配ネットワークを利用して配信できる。他の実施形態では、外部コンテンツは同報通信できる。例えば、メディア・サーバ２１０はデータ・キャスティング・サービス（すなわち、ＲＦ、マイクロ波、または衛星技術を用いてデータを変調して同報通信する）を介して外部コンテンツ２９０にアクセスできる。

クライアント・デバイスによる集約：
本明細書で使用する「デバイス」という用語は、より広い機能を実行するサービスの集合をサポートするホーム・ネットワーク・クライアントを意味する。また、本明細書で使用する「メディア・サーバ」という用語は、メディア項目を記憶する、またはネットワークに提示するホーム・ネットワーク上のエンティティである。さらに、「ノード」はデバイスおよび／またはメディア・サーバを含む、ホーム・ネットワーク上の任意のエンティティを意味する。
収束メディア・プラットフォームは「ピアツーピア」アーキテクチャを使用する。メディア・プラットフォーム上のすべてのクライアント・デバイスは、複数のクライアント・デバイスおよび複数のサーバを含め、他のデバイスと通信する能力がある。このアーキテクチャを用いて、デバイスはネットワーク上で利用可能なすべてのメディアを入手し、メディアを集約してそのデバイス上に提示することができる。
クライアント・デバイスまたはサーバ・デバイスを含むデバイスは、いつでもホーム・ネットワークに接続し、および／または離脱することができ、その間、完全な機能を維持する。したがって、デバイスの電源がオフの時には、他のデバイスはそのデバイスがホーム・ネットワーク上で利用可能でないことを自動的に認識する。ネットワークに新しいデバイスが追加されるかポータブル・デバイスが接続すると、他のノードは新しいデバイスを自動的に認識する。その他のノードは追加されたデバイス上でサービスを利用できる。少なくとも１つの他のメディア・サーバがネットワーク上に現在ある限り、新しいメディア・サーバも新しいデバイスを自動的に認識できる。

図３は本発明の一実施形態によるクライアント・デバイスのメディア集約を示す図である。この例では、３つのメディア・サーバ（３１０、３２０、および３３０）がホーム・ネットワーク３４０に結合されている。図３に示すように、各メディア・サーバはさまざまなメディア項目（例えば、ビデオ、オーディオ、写真など）を記憶する。例えば、サーバ３１０はメディア項目１、４、６、１２、２２および３３を記憶する。この例では、メディア・デバイス３５０はホーム・メディア・ネットワーク３４０上にある。メディア・デバイス３５０はＤＶＤプレーヤを含むことができ、メディア・サーバ３１０、３２０および３３０上に記憶されたメディア項目はＤＶＤを含むことができる。
発見プロセスを完了した後で、メディア・デバイス３５０は、ホーム・ネットワーク３４０上で利用可能な他のデバイス（例えば、メディア・サーバ）に記憶された該当するメディア項目を決定する。こうして、メディア・デバイス３５０はメディア・デバイス３５０に関連するすべてのメディアを集約し、メディア・デバイス３５０で使用する（すなわち、再生、制御など）。図３に示すように、メディア・デバイス３５０はメディア・サーバ３１０、３２０および３３０に記憶されたすべてのメディア項目を集約する。
メディア収束プラットフォームはすべてのメディア項目を一意的なものとして識別する機能を提供する。例えば、「ポップ」というジャンルに分類されたすべてのメディア項目はそのように認識され、システムはそれに従ってそれらを表示する。アーチストは同じ名前であっても同じアーチストとは限らない。メディア収束プラットフォームは、システムが一意的なメディア項目を区別するための分散データベースを使用する。したがって、メディア項目が２つの異なるメディア・サーバ上に記憶されている場合、クライアント・デバイスによる集約の間、デバイスは１つのメディア項目しか認識しない。図３の例では、メディア項目１２がメディア・サーバ３２０とメディア・サーバ３１０の両方に記憶されている。クライアントのメディア集約の間、メディア・デバイス３５０はメディア・サーバ３２０とメディア・サーバ３１０の両方に記憶されたメディア項目１２を同じ項目として認識する。したがって、メディア・デバイス３５０はメディア項目１２を１つの項目としてしか認識しない。
基本プロトコルではクライアント・デバイスはホーム・ネットワーク上のデバイスからメディア項目を集約できない。プロトコルそれ自体も分散システムをサポートする要件を有さない。メディア収束プラットフォームのこの実施形態では、集約論理が非分散プロトコルを用いて分散システムを作成する。集約論理は複数のプロトコルを用いてホーム・ネットワーク上のデバイスを統合する。

図４はネットワーク上のクライアントによるメディア集約の一実施形態を示す流れ図である。最初、クライアント・デバイスはホーム・ネットワーク上にデバイス（例えば、メディア・サーバ）を発見する（図４のブロック４１０）。ホーム・ネットワーク上にデバイスを発見する一実施形態について以下に詳述する。発見プロセスで学習する情報に基いて、クライアント・デバイスは発見したデバイスの状態情報を組み立てる（図４のブロック４２０）。クライアント・デバイスはメディア項目の要求を受信する（図４のブロック４３０）。集約論理は集約論理の上位で動作するソフトウェア構成要素からの要求を受信する。例えば、クライアント・デバイスはユーザ・インタフェースを運用するテレビジョンを含むことができる。ユーザは、リモート・コントロール・デバイスを用いて、ホーム・ネットワーク上で利用可能なすべての音楽項目のリストを要求できる。この例では、ユーザ・インタフェース上のアプリケーション論理が音楽項目の要求を変換し、この要求を集約論理に送信する。
クライアント・デバイスの集約論理はこれらのメディア項目を含むすべてのメディア・サーバからメディア項目を入手する。例えば、クライアントが音楽項目を要求する場合、クライアント・デバイスはネットワーク上で利用可能なすべてのメディア・サーバからすべての音楽項目を入手する。この動作を図４に示す（ブロック４４０、４５０、４６０、４７０および４８０）。特に、特定のメディア・サーバを選択するための識別子（すなわち、ｎ＝０）が設定される（図４のブロック４４０）。クライアント・デバイスは発見プロセス（図４のブロック４５０）中に入手した状態情報を用いて、選択したメディア・サーバ（例えば、メディア・サーバ［０］）に接続する。特に、クライアント・デバイスは、選択したメディア・サーバがサポートするプロトコルにメディア項目要求を変換し、その要求をメディア・サーバに送信する。一実施形態では、クライアント・デバイスは選択したメディア・サーバ上でサービスを起動して、メディア項目を入手する（図４のブロック４６０）。一実施形態では、クライアント・デバイスはメディア・サーバ上でコンテンツ・マネージャ・サービスを起動して利用可能なメディア項目のリストを入手する。ホーム・ネットワーク上に利用可能なメディア・サーバがさらにある場合、クライアント・デバイスは新しいメディア・サーバを識別してメディア項目を入手する（図４のブロック４７０および４８０）。クライアント・デバイスがすべての利用可能なメディア・サーバからメディア項目のリストを入手すると、プロセスは完了する。

図５はメディア収束プラットフォーム・デバイス上で動作するソフトウェア構成要素の一実施形態を示すブロック図である。ソフトウェア構成要素５００は、最上位レベルに、アプリケーション・ソフトウェア５０２を含む。アプリケーション・ソフトウェア５０２は基本デバイスの機能を実現する。例えば、アプリケーション・ソフトウェア５０２はＤＶＤプレーヤの機能を実現できる。図５に示すように、アプリケーション・ソフトウェア５０２の下には集約論理５２０がある。上記のように、集約論理５２０を用いて、クライアント・デバイスはホーム・ネットワーク上のメディア項目を集約できる。
また、ソフトウェア構成要素５００は論理５１０をレンダリングするユーザ・インタフェース（「ＵＩ」）を含む。ＵＩレンダリング構成要素５１０はシーン情報をクライアント・デバイス上での表示に適した表示情報に変換する。ＵＩレンダリング構成要素５１０はまた表示データをレンダリングする。例えば、基本のクライアント・デバイスがテレビジョン・ディスプレイ（例えば、ＣＲＴ）を含む場合、ＵＩレンダリング・エンジン５１０はシーン情報からグラフィック・データを生成し、そのグラフィック・データをテレビジョン・ディスプレイ上にレンダリングする。クライアント・デバイス上のディスプレイがＬＣＤディスプレイの場合、ＵＩレンダリング・エンジン５１０はシーン情報からリストを生成し、ＬＣＤディスプレイ上にリストを表示する。
図５に示すように、クライアント・デバイスは、１つまたは複数のネットワーク・プロトコルおよびリモート・プロシージャ・コール（「ＲＰＣ」）機構を含む。例えば、図５は、クライアント・デバイスがネットワーク・プロトコル_Ａ（５２５）、ネットワーク・プロトコル_Ｂ（５３０）、およびネットワーク・プロトコル_ｎ（５３５）をサポートしていることを示す。この例では、クライアント・デバイス・ソフトウェア５００はＲＰＣ機構_Ａ（５４０）、ＲＰＣ機構_Ｂ（５４５）、およびＲＰＣ機構_ｎ（５５０）をサポートしている。
クライアント・デバイス・ソフトウェア５００は１つまたは複数のサービスをサポートする。図５に示すように、サービスの１つまたは複数の方法はインタフェースを通してアクセスできる。一般に、これらの方法は、起動されると、基本サービスの特定の機能を提供する。この例では、クライアント・デバイス・ソフトウェア５００はサービス_Ａ（５５５）、サービス_Ｂ（５６０）、およびサービス_ｎ（５６５）を含む。各サービスは１つまたは複数の方法（すなわち、方法（１）〜方法（ｎ））に関連する。

一実施形態では、メディア収束プラットフォームは複数の基本プロトコルをサポートする。一般に、プロトコルはコマンド、ＲＰＣ機構、およびサービスへのインタフェースを定義する。一実施形態では、メディア収束プラットフォームは業界規定のＵＰｎＰプロトコルをサポートする。一般に、ＵＰｎＰプロトコルはＩＰネットワーク上の発見、ＲＰＣ機構、およびサービス起動のためのインタフェースを定義する。ＵＰｎＰサービスは、コンテンツ・ディレクトリ・サービス、接続マネージャ・サービス、オーディオ／ビデオ（「Ａ／Ｖ」）トランスポート・サービスおよびＡ／Ｖ制御サービスを含む。
一実施形態では、メディア収束プラットフォームは、また自社開発プロトコル（すなわち、非業界標準プロトコル）をサポートする。この実施形態では、自社開発プロトコルはネットワーク発見プロセス、ＲＰＣ機構、およびサービスへのインタフェースを定義する。これらのサービスはコンテンツ・マネージャおよびメディア・プレーヤ・サービスを含む。コンテンツ・マネージャ・サービスを用いて、クライアント・デバイスはデータベースにインタフェースできる。特に、コンテンツ・マネージャ・サービスを用いて、クライアント・デバイスは別のネットワーク・デバイスのデータベースから情報（例えば、メディアを識別するためのＵＲＬ、メタデータなど）を取り出すことができる。こうして、コンテンツ・マネージャ・サービスはメディア収束プラットフォーム・システムのデバイスがデータベースに問い合わせる手段を提供する。メディア・プレーヤ・サービスは再生機能（例えば、メディア・ストリームを開始して制御する）を許可するインタフェースを定義する。

一実施形態では、自社開発プロトコル上の発見プロセスは非同期ベースのメッセージ交換を実施する。発見プロトコルはパケットベースのメッセージ交換をサポートする任意のネットワークまたはシリアル・ネットワーク上で動作する。一実施形態では、発見プロトコルは「宣言」コマンド、「発見」コマンド、および「ｂｙｅ−ｂｙｅ」コマンドを含む。宣言コマンドはデバイスがホーム・メディア・ネットワーク上でのその存在を宣言するために使用する。発見コマンドは宣言の要求（すなわち、いずれかのクライアント・デバイスがホーム・ネットワーク上にあるか否かの問い合わせ）である。「ｂｙｅ−ｂｙｅ」コマンドはクライアント・デバイスがネットワークから離脱することを宣言するために使用する。一実施形態では、宣言コマンドと「ｂｙｅ−ｂｙｅ」コマンドにはそれぞれ２つのタイプがある。１つはデバイス用、１つはサービス用である。
一実施形態では、自社開発プロトコルがサポートするＲＰＣ機構は、パケットベースのプロトコルを使用する。サービスは、ホーム・ネットワーク上のデバイスが適当な引数を備えたＲＰＣベースのパケットを組み立てることを可能にする方法と識別番号とを含む。一般に、ＲＰＣ機構を用いてデバイスはネットワーク上の別のデバイスを制御できる。プロトコルは要求と応答によって実行される。ＲＰＣパケットはヘッダを含む。一実施形態では、ヘッダはバージョン情報、コマンド・クラス（特定のサービスへのマップ）、コマンド（デバイスが要求している方法または方法から受け取る応答）、識別（要求の識別または要求に対応する応答の識別）、および長さを含む。ヘッダの後に、ＲＰＣプロトコル・フォーマットがデータを指定する（すなわち、要求の引数であって応答の値を返す）。

図６はメディア収束プラットフォームの例示としてのホーム・ネットワークを示すブロック図である。この例では、ホーム・ネットワークはＣＤプレーヤ６５０、ＤＶＤプレーヤ６４０、およびメディア・サーバ６３０を含む。クライアント・デバイス（６１０）はホーム・ネットワーク６２０に接続し、サポート・プロトコルを用いて、３つのデバイス（例えば、ＣＤプレーヤ６５０、ＤＶＤプレーヤ６４０、およびメディア・サーバ６３０）を発見する。図６に示すように、クライアント・デバイス６１０はホーム・ネットワーク６２０上で発見されたデバイスの各々の状態情報を記憶する。特に、クライアント・デバイス６１０は、デバイス_１（メディア・サーバ６３０）について、サポート・ネットワーク・プロトコル（すなわち、ネットワーク・プロトコル_Ａ）とデバイスがサポートするサービス（すなわち、サービス_Ａおよびサービス_Ｃ）のリストを記憶する。また、ネットワーク・プロトコルはメディア・サーバ６３０上でリモート・プロシージャ・コールを実行するＲＰＣ機構を指定する。同様に、デバイス_２（すなわち、ＤＶＤプレーヤ６４０）の状態情報は、デバイス_２がネットワーク・プロトコル_Ａをサポートし、サービス_Ａおよびサービス_Ｂを実施することを示す。デバイス_３、すなわちＣＤプレーヤ６５０は、ネットワーク・プロトコル_Ｃをサポートし、サービス_Ａおよびサービス_Ｂを実施する。
図６に示すように、各サービス（例えば、サービス_Ａ、サービス_Ｂ、およびサービス_Ｃ）はインタフェースをサポートする。インタフェースはサービス内の方法またはコマンドにアクセスする手段を提供する仕様を定義する。したがって、クライアント・デバイス６１０は、それぞれのインタフェースを介してＣＤプレーヤ６５０上でサービス（サービス_Ａまたはサービス_Ｂ）を使用する。メディア・サーバ６３０、ＤＶＤプレーヤ６４０およびＣＤプレーヤ６５０はすべてサービス_Ａを実施することに留意されたい。てサービス_Ａの各インタフェースはサービスへの一様なアクセス機能を許可するインタフェースである。ただし、各デバイス内でのサービス_Ａの実施は異なる。
一実施形態では、メディア収束プラットフォームの実施態様はセキュリティを提供する。この実施形態では、宣言コマンドが変更可能で、プロトコルのみが通信の最小の仕様を定義する。したがって、宣言プロトコルは、ＴＣＰおよびセキュア・ソケット・レイヤ（「ＳＳＬ」）を含む複数のネットワーク仕様をサポートすることができる。このプロトコルはＴＣＰ／ＩＰネットワーク上での実行をサポートする。さらに、このプロトコルはＴＣＰ／ＩＰネットワーク上で動作するＳＳＬをサポートする。ＳＳＬによって、ネットワーク上の２当事者間の認証を含む安全な通信が可能になる。
自社開発プロトコルによっても部分的なセキュリティを用いた実施態様が可能である。この実施形態では、サービスは安全な通信を要求するいくつかの方法と安全な通信を要求しないその他の方法とを含むことができる。したがって、いくつかの方法はホーム・ネットワーク上の２つのデバイスの間の安全な通信を実現するＳＳＬ技術を使用する。

発見：
図７はメディア収束システム内のデバイスを発見する一実施形態を示す流れ図である。新しいデバイス（すなわち、現在ネットワークに接続されていないデバイス）がホーム・メディア・ネットワークに接続する（図７の７１０）。ネットワーク上での通信のために、新しいデバイスはネットワーク・アドレスを取得する（図７のブロック７２０）。例えば、ＩＰネットワークでは、クライアントはＩＰアドレスを必要とする。基本ネットワークがＴＣＰ／ＩＰをサポートする場合、クライアント・デバイスはＤＨＰサーバがあるか否かを判定する。ある場合、ＤＨＰサーバはＩＰアドレスを新しいデバイスに割り当てる。新しいデバイスにＩＰアドレスを割り当てるＤＨＰサーバがない場合、新しいデバイスは、プールからＩＰアドレスを選択してホーム・ネットワーク上の他のデバイスがそのＩＰアドレスを有しているか否かを判定する。ネットワーク上の他のデバイスがそのＩＰアドレスを有していない場合、クライアント・デバイスはこのＩＰアドレスを使用する。この自動ＩＰアドレス設定のプロセスによって１つのサブネット内のホーム・ネットワーク上の通信が可能になる。
新しいデバイスはネットワーク上で「宣言」コマンドを送信する（図７のブロック７３０）。宣言コマンドのフォーマットはデバイスがサポートするプロトコルに適合する。新しいデバイスはネットワーク上で宣言コマンドを同報通信またはマルチキャストすることができる。例えば、ＩＰネットワーク内では、新しいデバイスはホーム・ネットワークがゲートウェイを含む場合、サブネットを拡張するために宣言をマルチキャストすることができる。マルチキャスト・フォーマットは特定のＩＰアドレスを指定する（例えば、ネットワーク上の関与するデバイスまたは新しいデバイスと互換性があるデバイスにのみ宣言を送信する）ために使用される。本明細書で使用する互換デバイスとは、クライアント・デバイスとの通信に関与することができるデバイスである。
新しいデバイスの宣言コマンドに応答して、新しいデバイスは状態情報を組み立てる。一般に、状態情報はネットワーク上で利用可能なデバイスに関する詳細を提供する。状態情報はこれらのデバイスがサポートするプロトコルおよびサービスを含む。ネットワーク上の互換デバイスが宣言コマンドを受信すると、これらの互換デバイスは宣言コマンドにカプセル化された情報をローカル・キャッシュに追加することができる。

ネットワーク上に互換デバイスがない場合、または新しいデバイスがネットワーク上のサービスを利用することを望まない場合、プロセスは終了する。例えば、新しいデバイスがＭＰ３プレーヤの場合、互換デバイスはＭＰ３オーディオを記憶するメディア・サーバと他のＭＰ３プレーヤとを含む。ネットワーク上のその他の互換デバイスがある場合、それらのデバイスは新しいデバイスに１つまたは複数のサービスを提示する（図７のブロック７５０）。ネットワーク上のサービスを発見するために、新しいデバイスは発見コマンドを送信して応答を待つ。この例では、ＭＰ３オーディオを記憶するメディア・サーバが、新しいデバイスがそのメディア・サーバに記憶されたＭＰ３オーディオを集約するためのインタフェースを提示する。同様に、互換ＭＰ３プレーヤは、事前定義されたインタフェースを介して、新しいデバイスが互換ＭＰ３プレーヤの位置にある新しいデバイスに記憶されたＭＰ３オーディオを再生するサービスを提示する。
要求（例えば、新しいデバイスのアプリケーション論理）に応答して、新しいデバイスはサポート・プロトコルを介して互換デバイスに接続する（図７のブロック７６０）。特に、デバイスは状態情報を用いて適当なデバイスのプロトコルを変換する。例えば、互換デバイスが業界標準プロトコルをサポートする場合、新しいデバイスは業界標準プロトコルを選択してそのデバイスに通信する。新しいデバイスは互換デバイス上でサービスを利用する（図７のブロック７７０）。
ホーム・ネットワークに接続するメディア・サーバは、発見プロセスの１例である。この例では、メディア・サーバは、ネットワーク・アドレスを取得した後で、ネットワーク上で宣言コマンドを送信する。メディア・サーバはサポートするサービス（例えば、コンテンツ・マネージャ、メディア・プレーヤ・サービス）を宣言し、ネットワーク・クライアントにインタフェースを提示してこれらのサービスへのアクセスを許可する。デバイスがネットワークに接続すると、デバイスはサーバからの宣言を待つ。クライアントがメディア・サーバを識別すると、クライアントはサーバが宣言コマンド内で指定したプロトコルを介してメディア・サーバに接続する。このプロセスによって、クライアント・デバイスはメディア・サーバ上でメディアをナビゲートできる。サポート・プロトコルを用いて、クライアント・デバイスは、再生デバイス、すなわち、それ自体または別の再生デバイスに接続し、再生デバイスに対して、メディア・サーバ上で利用可能メディア項目からユーザが選択した項目を再生するように命令する。

収束プラットフォーム・データ・モデル：
メディア収束システムはデータ・モデルと連係して動作する。基本データベースのフォーマットおよび構成はメディア収束システムによって定義されていない。データ・モデル内では、オブジェクト（例えば、メディア項目）はデータベース内に一意的な識別を有する。オブジェクトはまた関連する「タイプ」（例えば、写真、オーディオ・トラック、ビデオ・クリップなど）を有する。データ・モデルはオブジェクトおよびタイプ間の構造およびハイアラーキを定義する関係を定義する。
一実施形態では、メディア収束システムのデータベースはリレーショナル・データベース（例えば、主要値ペア・データベースまたは標準問い合わせ言語（「ＳＱＬ」）データベース）を含む。この実施形態では、データベースはリレーショナル・データベース内の記憶にオブジェクトをマッピングする。メディア収束システムの一実施形態はリレーショナル・データベースを使用するが、本発明の精神または範囲から逸脱することなく他のデータベースを使用してもよい。

図８はメディア収束プラットフォーム・システムを介してデータ記憶にアクセスする一実施形態を示すブロック図である。クライアント・デバイス８１０はホーム・ネットワーク８２０に接続されている。図８に示すように、デバイス８３０とデバイス８４０もホーム・ネットワーク８２０に結合されている。デバイス８４０は図８でデータベースＢとラベルが貼られた永続的データ記憶を含む。同様に、デバイス８３０は永続的データ記憶、すなわちデータベースＡを含む。デバイス８３０および８４０は永続的データ記憶内の情報にアクセスするためのサービスをサポートする。一実施形態では、コンテンツ・マネージャ・サービスが利用される。特に、コンテンツ・マネージャ・サービス_Ａの第２の実施態様はデータベースＡへのアクセスをサポートし、コンテンツ・マネージャ・サービス_Ｂの第１の実施態様はデータベースＢへのアクセスをサポートする。
クライアント・デバイス８１０はデータベースＡおよびデータベースＢから情報を得ることができる。データベースＢの問い合わせする場合、クライアント・デバイス８１０は上記の方法でデバイス８４０との接続を得る。クライアント・デバイス８１０はコンテンツ・マネージャ・サービス_Ｂ上のインタフェースを介して方法を起動する。例えば、クライアント・デバイス８１０はメディア収束システムが認識するすべてのジャンルのリストを得ようとすることがある。この情報はデータベースＢ内に記憶できる。クライアント・デバイス８１０はコンテンツ・マネージャ・サービス_Ｂのインタフェースに指定したデータ・モデル・パラメータを用いて要求を生成する。上の例では、クライアント・デバイス８１０はタイプが「ジャンル」のすべてのオブジェクトを識別するコンテンツ・マネージャ・サービス_Ｂへの要求を生成する。要求に応答して、クライアント・マネージャ・サービス_Ｂは「ジャンル」のデータ・モデル動作をデータベースＢと互換の問い合わせに変換する。例えば、データベースＢがＳＱＬをサポートする場合、コンテンツ・マネージャ・サービス_Ｂは、タイプが「ジャンル」のテーブル内のすべてのレコードを得るデータベースＢへのＳＱＬ要求を生成する。
コンテンツ・マネージャ・サービスの実施態様はメディア収束システムのデータ・モデルから基本データベース実施態様への変換を実行する。図８の例の場合、コンテンツ・マネージャ・サービス_ＡはデータベースＡへの第１の変換をサポートし、コンテンツ・マネージャ・サービス_ＢはデータベースＢに記憶されたデータの要求のためのへの第２の変換をサポートする。したがって、クライアント・デバイス８１０は両方のコンテンツ・マネージャ・サービス上のインタフェースによって定義された同じ要求を用いて、異なるデータベース実施態様（例えば、データベースＡおよびデータベースＢ）にアクセスできる。

一実施形態では、メディア収束プラットフォーム・システムはデータベースを用いて実施される。一般に、データベースはオブジェクト、これらのオブジェクトに関連する属性、およびこれらのオブジェクトの連関を記憶する。例えば、データベースはメディア空間内で利用可能な音楽トラックの識別を記憶する。データベースは複数の属性を記憶し、音楽トラックごとに１つまたは複数の属性を関連付ける。一実施形態では、オブジェクトは、アルバム、アーチスト、トラック、ジャンル、および再生リストを含む。したがって、トラックを１つまたは複数のアルバム、１人または複数のアーチスト、１つまたは複数のジャンル、および１つまたは複数の再生リストに関連付けることができる。属性はタイトル、作成日付、および複数の関連するメディア・ファイルを含む。したがって、トラックは関連するアルバム・アート、歌詞などを有することができる。
メディア収束プラットフォーム・データベースを用いて、オーディオ・トラックを極めて用途が広い方法で分類することができる。例えば、ユーザはこの音楽を２つの異なるタイプのジャンル（例えば、ロックとブルース）に関連付けるので、トラックまたはアルバム（すなわち、トラックの集合）を複数のジャンルに分類したいと考える。また、音楽トラックは２人のアーチストの協働作業の結果である場合もある。トラックを正しく分類するために、メディア収束プラットフォームのユーザはトラックを２つの異なるアーチストに関連付けることができる。上記の例に示すように、メディア収束プラットフォーム・システムは音楽を分類および整理する際の最大の柔軟性を提供する。
メディア収束プラットフォーム・システムは各分類または項目を別個のオブジェクトとして扱う。例えば、音楽ジュークボックスの用途では、再生リスト、ジャンル、アーチスト、アルバム、およびトラックはすべて個々のオブジェクトとして扱われる。この機能は、項目の整理と分類のための独立したオブジェクトをサポートし、音楽を整理し分類する際の最大の柔軟性を提供する。例えば、ユーザは第１の再生リストが第２の再生リスト内に完全に含まれるように入れ子構造の再生リストを作成できる。従来技術の音楽システムは再生リストをトラックごとにしか扱わない。これらの従来技術のシステムでは、再生リストはトラックのみからなる。メディア収束プラットフォーム・システムでは、再生リストは任意の「オブジェクト」を含むことができる。したがって、複数のアーチスト、ジャンル、または他の再生リストから再生リストを作成することができる。

また、音楽を整理し再生する際のオブジェクトの利用によって、同じ名前のアーチストを別々に扱うことができる。従来のディジタル音楽システムではアーチストを識別するメタデータを記憶する。ユーザがこれらの従来技術のシステムを用いてメタデータを検索すると、システムは同じ名前のアーチストを区別する方法がない。メディア収束プラットフォーム・システムでは、各アーチストはオブジェクトとして扱われる。したがって、同じ名前を有する２人のアーチストは２つの別個のオブジェクトで、２人の別個のアーチストとして操作できる。
メディア収束システムは分散繰り返し子を使用する。データベース問い合わせへの応答は大量のデータを発生させることがある。一実施形態では、メディア収束プラットフォーム・プロトコルはデータの一部送信、および送信済みデータを識別するポインタの保持をサポートする。一実施形態では、プロトコルは繰り返し子を使用する。メディア収束プラットフォームが繰り返し子を使用することでシステムは１つのデバイスから他のデバイスに転送されたデータ（例えば、リスト）の一部を追跡できる。繰り返し子は、データベース内の項目がデータの転送中に変化した場合に繰り返し子が動的に変化するように実施される。一般に、繰り返し子はアレイ内の部分を指定する。リストはデータベースからの結果である。例えば、データベース問い合わせへの応答はオーディオ・トラックのリストを生成することがある。その後、例示の問い合わせの一部として取り出されるオーディオ・トラックを削除することができる。別のシナリオでは、問い合わせによって指定されるオーディオ・トラックをデータベースに追加することができる。
メディア収束システムが自社開発のプロトコルとＴＣＰ／ＩＰネットワークを用いて実施される場合、システムは状態をデータベース情報要求に関連付ける。この状態情報は繰り返し子情報の保持に使用される。

ユーザ・インタフェース：
一実施形態では、メディア収束プラットフォームはユーザ・インタフェース（「ＵＩ」）シーン・マネージャおよびアプリケーション論理をＵＩレンダリング・エンジンから切り離す。一実施態様では、システムはユーザ・インタフェース表示を「シーン」と定義する。一般に、シーンは表示の抽象的なレイアウトで、論理的なエンティティまたは要素からなる。例えば、シーンは、特定の表示に関して、表示の最上部のタイトルと、表示の最下部のメッセージと、表示の中央の要素のリストとを定義できる。シーンそれ自体はタイトル、メッセージおよびリストの特定のデータを定義しない。一実施態様では、ユーザ・インタフェース・ソフトウェアはシーン・マネージャ、ＵＩアプリケーション論理、およびＵＩレンダリング・エンジンを含む。一般に、シーン・マネージャは論理エンティティによるＵＩ表示の抽象的なレイアウトを生成する。アプリケーション論理はユーザ入力を受け取り、シーンとデータを決定し、ユーザ・インタフェースの論理フローに基いてシーンにデータを埋め込む。例えば、ユーザは現在のＵＩ表示に表示された第１の項目を選択できる。これに応答して、ＵＩアプリケーション論理は、適宜、新しいシーンとデータとを選択し、ユーザ選択に基いて新しいシーンにデータを埋め込む。
アプリケーション論理はシーンおよびＵＩレンダリングとは独立して実施される。ＵＩアプリケーション論理は、シーン・マネージャから、抽象的な要素としてのシーンを得る。次いでアプリケーション論理は論理要素にデータを埋め込み、データが入った抽象的なレイアウトをレンダリング・エンジンに転送する。次いでレンダリング・エンジンはそのデバイスの出力表示に固有の表示要素を備えたシーンおよびデータを表示する。表示要素は表示解像度、テキスト表示のフォント・サイズ、グラフィックス表示機能などを含む。例えば、出力デバイスがテレビジョン画面の場合、ＵＩレンダリング・エンジンはテレビジョン画面のシーンの表示（例えば、適切な解像度、フォント・サイズなど）に適したグラフィック・データ（すなわち、ＲＧＢデータ）を生成する。出力表示が液晶ディスプレイ（「ＬＣＤ」）の場合、ＵＩレンダリング・エンジンはシーンの論理エンティティをＬＣＤディスプレイ上の表示に適したフォーマットに変換する。例えば、デバイスの表示がリストの表示のみの場合、ＵＩレンダリング・エンジンはデータを備えたシーンを表示専用リストに変換する。この変換の結果、シーンから表示をレンダリングする何らかの情報が削除されることがある。ＵＩレンダリング・エンジンはその他の論理要素をリストに変換してＬＣＤディスプレイに表示することができる。

シーン・マネージャとＵＩアプリケーション論理をＵＩレンダリング・エンジンから切り離すメディア収束プラットフォームのユーザ・インタフェースの実施態様はいくつかの利点を有する。第一に、シーン・マネージャ／アプリケーション論理は出力表示の能力に関する情報を全く必要としない。その代わりに、シーン・マネージャおよびアプリケーション論理は論理エンティティの観点からのみＵＩ表示を表示し、ユーザ入力およびユーザ・インタフェースの論理フローに基いてこれらの論理エンティティのデータを埋め込む。第２に、この分離によって、ユーザ・インタフェース・システムのグラフィック・デザイナはユーザ・インタフェースのシーンを容易に変更できる。例えば、グラフィック・デザイナがユーザ・インタフェースのシーンを変更しようとする場合、シーンの抽象的なレイアウトを変更するだけでよい。実行時に、アプリケーション論理は改定された抽象的なレイアウトを受信し、改定された抽象的なレイアウトにデータを埋め込み、データを備えた抽象的なレイアウトをＵＩレンダリング・エンジンに送信する。次いで、ＵＩレンダリング・エンジンは出力デバイスに基いてシーンを表示する特定の表示要素を決定する。したがって、シーンから表示要素への変換はローカルにのみ発生するため、シーンの変更は各出力デバイスに固有の表示要素の変更を必要としない。
一実施形態では、メディア収束プラットフォームはデバイスからリモートの位置でのユーザ・インタフェース・ソフトウェアの実行を許容する。一実施態様では、シーン・マネージャおよびアプリケーション論理はユーザ・インタフェースを表示するデバイスからリモートの位置のデバイス上で実行される。ユーザ・インタフェースを表示するデバイスはＵＩレンダリング・エンジンのみを含む。この実施態様では、ユーザ・インタフェースのデータおよびシーンはリモート・デバイス上に存在する。この実施態様を用いると、シーン・インタフェース（シーン・マネージャとアプリケーション論理との間のインタフェース）は表示をレンダリングするデバイスからリモート位置になる。データを備えたシーン情報のみが送信されるので、リモート・デバイスはネットワーク全体に大きいビットマップを転送しない。この機能の線引きによって、ネットワーク上の処理能力を最大限にするネットワーク上のデバイスの間の論理的な境界が提供される。さらに、シーン・マネージャ／アプリケーション論理を処理するリモート・デバイスはホーム・ネットワーク上の各デバイスのディスプレイ能力に関する情報を必要としない。したがって、この実施態様では、ＵＩレンダリング・ソフトウェアが画像をレンダリングするデバイスまで押し上げられ、一方、アプリケーション論理は他のデバイスに常駐している。このアーキテクチャによって、メディア収束プラットフォーム内でシン・クライアントを実施することができる。これはシン・クライアントがシーン・マネージャおよびアプリケーション論理ソフトウェアを実行する必要がないことによる。

図９はメディア収束プラットフォーム内にユーザ・インタフェースを実施する一実施形態を示すブロック図である。この例示としての実施形態では、デバイス（９１０）はシーン・マネージャ９２０とアプリケーション論理９３０とを含む。デバイス９１０は、コンピュータまたはセットトップ・ボックスなどの相当の処理能力を備えたメディア・サーバを含む。シン・クライアント・デバイス９７０は、ユーザに情報を表示する（例えば、ユーザ・インタフェースを実施するためのデータを表示する）ディスプレイ９６０と、レンダリング・エンジン９５０とを含む。レンダリング・エンジン９５０は、入力として、シーン・データを受信し、出力として、表示データを生成する。表示データはディスプレイ９６０に画像をレンダリングするのに必要な要素からなる。例えば、ディスプレイ９６０がグラフィック表示を含む場合、表示データはディスプレイにグラフィック画像をレンダリングするための情報（例えば、ＲＧＢデータ）を含む。
図９は、表示デバイス上での、リモート・デバイス（デバイス９１０）上で実施されるシーン・マネージャおよびアプリケーション論理からＵＩレンダリング・エンジンを切り離す様子を示す。動作時には、ディスプレイ９６０にオブジェクト（例えば、アルバム）のリストを表示できる。ユーザは再生するアルバムを選択できる。ユーザの選択に応答して、シーン・マネージャ９２０はオーディオ・トラック要素のリストと制御情報とからなる抽象的なシーンを生成できる。抽象的なシーンはシーン・マネージャ９２０からアプリケーション論理９３０に渡される。アプリケーション論理９３０は抽象的なシーン要素に選択に固有のデータを埋め込む。したがって、この例では、アプリケーション論理９３０はオーディオ・トラック要素のリストにユーザが選択したアルバムのオーディオ・トラックの名前を埋め込む。次いでアプリケーション論理９３０は、インタフェース９４０を介して、シーン・データをシン・クライアント９７０上のＵＩレンダリング・エンジン９５０に送信する。ＵＩレンダリング・エンジン９５０はデータを備えたシーン要素を表示要素に変換し、ディスプレイ９６０で表示する。例えば、ディスプレイ９６０がＬＣＤディスプレイの場合、レンダリング・エンジン９５０はオーディオ・トラックのテキスト・リストを生成する。

本発明の一実施形態に従って構成されたメディア空間を示す図である。 デバイスを１つのメディア空間に統合する一実施形態を示す図である。 本発明の一実施形態によるクライアント・デバイスによるメディア集約を示す図である。 ネットワーク上のクライアントによるメディア集約の一実施形態を示す流れ図である。 メディア収束プラットフォーム・デバイス上で動作するソフトウェア構成要素の一実施形態を示すブロック図である。 メディア収束プラットフォームの例示としてのホーム・ネットワークを示すブロック図である。 メディア収束システム内のデバイスを発見する一実施形態を示す流れ図である。 メディア収束プラットフォーム・システムを通してデータ記憶にアクセスする一実施形態を示すブロック図である。 メディア収束プラットフォーム内にユーザ・インタフェースを実施する一実施形態を示すブロック図である。

符号の説明

１００、２００ メディア空間 １１０ メディア記憶装置
１２０ メディア・プレーヤ １３０ 管理構成要素
１４０ ユーザ ２１０ メディア・サーバ
２５０、２７０ テレビジョン ２４０ オーディオ・プレーヤ
２８０ メディア・マネージャ ２９０ 外部コンテンツ・プロバイダ

Claims (21)

1. メディア・システム内でメディア項目を集約するための方法であって、
   複数のノードをネットワークに結合するステップであって、前記ノードの各々が前記メディア・システムの１つまたは複数のサービスを提供し、前記ノードの少なくとも２つがメディア・サーバ・ノードを含み、１つのメディア・サーバ・ノードが前記ネットワークに少なくとも１つのメディア項目を提示するステップと、
   要求元ノードで前記メディア・システム内で利用可能なメディアのリストを入手する要求を受信するステップと、
   前記要求元ノードで、前記ネットワーク上の前記メディア・サーバ・ノードの各々からメディア項目のリストの要求を生成するステップと、
   各メディア・サーバ・ノードから、前記各メディア・サーバ・ノード上で利用可能なメディア項目のリストを受信するステップと、
   前記要求元ノードで、前記メディア・サーバ・ノードの各々から、前記メディア・システム上で利用可能なメディア項目のリストを集約するステップであって、前記メディア・システム上で利用可能なメディア項目のリストが前記メディア・システム内の要求元ノードに集約されるステップとを含む方法。
2. 前記要求元ノードで、メディア・サーバ・ノードからメディア項目を受信するステップをさらに含む請求項１に記載の方法。
3. メディア項目のリストの要求を生成する前記ステップが前記ネットワーク上のメディア・サーバ・ノードを発見するステップを含む請求項１に記載の方法。
4. 利用可能なメディア項目のリストを受信する前記ステップが、
   前記要求元ノードで、前記要求元ノードで表示するメディア項目のリストの最大長を決定するステップと、
   前記要求元ノードで、前記最大長までメディア項目の部分リストを受信するステップとを含む請求項１に記載の方法。
5. 前記メディア・システム上で利用可能なメディア項目のリストを集約する前記ステップが、受信したメディア項目が他のメディア項目に対して一意であるかどうかを決定するステップを含む請求項１に記載の方法。
6. メディア項目のリストを要求する前記ステップとメディア項目のリストを受信する前記ステップとが、
   メディア・サーバ・ノードがサポートするプロトコルを決定するステップと、
   前記プロトコルを用いて前記メディア・サーバ・ノードにメディア項目のリストを要求するステップと、
   前記プロトコルを用いてメディア・サーバ・ノードから利用可能なメディア項目のリストを受信するステップとを含む請求項１に記載の方法。
7. 前記ネットワーク上のメディア・サーバ・ノードにメディア項目のリストを要求する前記ステップが、前記メディア・サーバ・ノード上でサービスを起動して前記メディア・サーバ・ノードからメディア項目のリストを入手するステップを含む請求項１に記載の方法。
8. 前記メディア・サーバ・ノード上でサービスを起動するステップが、
   メディア・サーバ・ノードがサポートするリモート・プロシージャ・コール（「ＲＰＣ」）機構を決定するステップと、
   前記ＲＰＣ機構を用いて前記メディア・サーバ・ノード上でサービスを起動するステップとを含む請求項７に記載の方法。
9. 前記要求元ノードが前記メディア・システムの複数のサービスをサポートするデバイスを備える請求項１に記載の方法。
10. 前記要求元ノードが少なくとも１つのメディア項目を前記ネットワークに提示するメディア・サーバを備える請求項１に記載の方法。
11. 複数の命令を含むコンピュータ可読媒体であって、前記コンピュータによって実行されると、前記コンピュータに、
    複数のノードをネットワークに結合するステップであって、前記ノードの各々が前記メディア・システムの１つまたは複数のサービスを提供し、前記ノードの少なくとも２つがメディア・サーバ・ノードを含み、１つのメディア・サーバ・ノードが前記ネットワークに少なくとも１つのメディア項目を提示するステップと、
    要求元ノードで前記メディア・システム内で利用可能なメディアのリストを入手する要求を受信するステップと、
    前記要求元ノードで、前記ネットワーク上の前記メディア・サーバ・ノードの各々からメディア項目のリストの要求を生成するステップと、
    各メディア・サーバ・ノードから、前記各メディア・サーバ・ノード上で利用可能なメディア項目のリストを受信するステップと、
    前記要求元ノードで、前記メディア・サーバ・ノードの各々から、前記メディア・システム上で利用可能なメディア項目のリストを集約するステップであって、前記メディア・システム上で利用可能なメディア項目のリストが前記メディア・システム内の要求元ノードに集約されるステップとを実行させるコンピュータ可読媒体。
12. 前記要求元ノードで、メディア・サーバ・ノードからメディア項目を受信するステップをさらに含む請求項１１に記載のコンピュータ可読媒体。
13. 前記要求元ノードで、メディア項目のリストの要求を生成する前記ステップが前記ネットワーク上のメディア・サーバ・ノードを発見するステップを含む請求項１１に記載のコンピュータ可読媒体。
14. 利用可能なメディア項目のリストを受信する前記ステップが、
    前記要求元ノードで、前記要求元ノードで表示するメディア項目のリストの最大長を決定するステップと、
    前記要求元ノードで、前記最大長までメディア項目の部分リストを受信するステップとを含む請求項１１に記載コンピュータ可読媒体。
15. 前記メディア・システム上で利用可能なメディア項目のリストを集約する前記ステップが、受信したメディア項目が他のメディア項目に対して一意であるかどうかを決定するステップを含む請求項１１に記載のコンピュータ可読媒体。
16. メディア項目のリストを要求する前記ステップとメディア項目のリストを受信する前記ステップとが、
    メディア・サーバ・ノードがサポートするプロトコルを決定するステップと、
    前記プロトコルを用いて前記メディア・サーバ・ノードにメディア項目のリストを要求するステップと、
    前記プロトコルを用いてメディア・サーバ・ノードから利用可能なメディア項目のリストを受信するステップとを含む請求項１１に記載のコンピュータ可読媒体。
17. 前記ネットワーク上のメディア・サーバ・ノードにメディア項目のリストを要求する前記ステップが、前記メディア・サーバ・ノード上でサービスを起動して前記メディア・サーバ・ノードからメディア項目のリストを入手するステップを含む請求項１１に記載のコンピュータ可読媒体。。
18. 前記メディア・サーバ・ノード上でサービスを起動するステップが、
    メディア・サーバ・ノードがサポートするリモート・プロシージャ・コール（「ＲＰＣ」）機構を決定するステップと、
    前記ＲＰＣ機構を用いて前記メディア・サーバ・ノード上でサービスを起動するステップとを含む請求項１７に記載のコンピュータ可読媒体。
19. 前記要求元ノードが前記メディア・システムの複数のサービスをサポートするデバイスを含む請求項１１に記載のコンピュータ可読媒体。
20. 前記要求元ノードが少なくとも１つのメディア項目を前記ネットワークに提示するメディア・サーバを含む請求項１１に記載のコンピュータ可読媒体。
21. メディア・システムであって
    ネットワークと、
    前記ネットワークに結合された複数のノードであって、前記ノードの各々が前記メディア・システムの１つまたは複数のサービスを提供し、前記ノードの少なくとも２つがメディア・サーバ・ノードを含み、メディア・サーバ・ノードが前記ネットワークに少なくとも１つのメディア項目を提示する複数のノードと、
    前記メディア・システム内で利用可能なメディアのリストを入手する要求を生成し、前記ネットワーク上の前記メディア・サーバ・ノードの各々からメディア項目のリストの要求し、各メディア・サーバ・ノードから、前記各メディア・サーバ・ノード上で利用可能なメディア項目のリストを受信し、前記メディア・サーバ・ノードの各々から、前記メディア・システム上で利用可能なメディア項目のリストを集約する少なくとも１つの要求元ノードとを含み、
    前記メディア・システム上で利用可能なメディア項目のリストが前記メディア・システム内の要求元ノードに集約されるメディア・システム。
    

Images