JP2008512734A

JP2008512734A - マルチメディアコンテンツ管理システム

Info

Publication number: JP2008512734A
Application number: JP2007522511A
Authority: JP
Inventors: サルモンセン，ダニエル，アール; セルシオ，ジェラルド，ジェイ
Original assignee: ゾランコーポレイション
Priority date: 2004-07-19
Filing date: 2005-06-22
Publication date: 2008-04-24
Also published as: WO2006019503A1; EP1782282A1; US20060026162A1

Abstract

コンテンツ操作方法は、ネットワーク接続が可能なソース及び／又はローカル接続が可能なソースを含む１つ又は２つ以上のソースからコンテンツを取得するステップを含む。該コンテンツ及びソースは動的に構成可能なものである。本方法は更に、コンテンツの選択及びアクセスを可能にするユーザインタフェイスを動的に構成するステップを含む。該動的な構成は、ユーザにとってトランスペアレントなものである。
【選択図】図７

Description

広範な用途において、単一の機能又は少数の機能しか実行しないが、利用すれば大幅に機能を拡張することができる処理、記憶、及び処理能力を有する装置又は機器が存在する。かかる装置及び機器の例として、テレビ、ディジタルビデオカセットレコーダ、DVDプレーヤ、音声受信器、ディジタルポータブル娯楽装置、POS端末、プロセス制御器及びバルブ、自動販売機、警報システム、及び家電製品その他が挙げられる。装置の計算力及び能力が技術の進歩と共に向上し、また更なるソフトウェアソリューションが利用可能となり、製品が次々と生産されてユーザ及び顧客に対するサービス及び経験が改善されていく。該装置及び機器は、典型的には、専用の機能と独自のアーキテクチャを有するものであり、一般に他の装置若しくはモデル形式と対話するようには設計されておらず、また同じ装置であっても別の装置と対話するようには設計されていない。

技術的な進歩により、多くの異なるフォーマットの大量の情報を入手することが可能となった。かかる情報は、イントラネット、ローカルエリアネットワーク、ワイドエリアネットワーク、及びインターネットといったコンピュータネットワークによってアクセスすることが可能なものである。該ネットワークは、世界中の情報に容易にアクセスすることを可能にし、及び、テキストファイル、データ、動画、ビデオクリップ、ミュージックファイル、ウェブページ、flashプレゼンテーション、シェアウェア、コンピュータプログラム、コマンドファイル、及びその他の情報という形で情報を世界中に配信することを容易にするものである。

情報のアクセス及び配信に対する１つの障害は、複数の装置及び複数のコンテンツフォーマットの間における相互運用性及びリソース管理が欠如していることである。もう１つの問題は、絶えず変化し更新されるソース、コンテンツ、及びフォーマットの無数の組み合わせを操作することが不可能なことである。

コンテンツ操作方法は、ネットワーク接続可能なソース及び／又はローカル接続可能なソースを含む１つ又は２つ以上のソースからコンテンツを取得する。該コンテンツ及びソースは、動的に変化することが可能なものである。本方法は更に、コンテンツの選択及びアクセスを可能にするユーザインタフェイスを動的に構成することを含み、該動的な構成は、ユーザにとってトランスペアレントなものである。

本開示の実施形態の特徴は、新規のものであり、特許請求の範囲に詳述されている。しかし、構造及び操作方法の両方に関連する本発明の実施形態は、以下の説明及び添付図面を参照することにより最もよく理解されよう。

必要とされているものは、メディアプレーヤ及びパーソナルコンピュータといった広範に相違し本質的に異なるメディア装置を操作することが可能であり、及び高度な接続性を有するシステムにおける絶えず動的に変化するコンテンツをナビゲートすることが可能である、装置及びシステムである。多数のマルチメディア家電装置及びコンピュータシステムは、有線及び／又は無線ネットワークを使用して接続することができ、これにより、大型ストレージベースの音楽、写真、及びビデオコンテンツをAVシステム及び接続された家電装置上で再生することが可能となる。大型ストレージ及び大容量ハードディスクドライブは、例えば、パーソナルコンピュータ（PC）又は娯楽コンテンツアグリゲーションシステム（セットトップボックス又はTWOパーソナルビデオレコーダ（PVR）等）内に設けることが可能である。例示的なシステムは、追加のソース及びコンテンツが利用可能となった際にソース及びコンテンツが動的に変化し更新されるリモート及び／又はローカルソースから利用可能となるメディアのナビゲーションを可能にするユーザインタフェイスを生成する。該例示的なシステムは、従来の家電装置のルックアンドフィールを変更することなく、かかる動的に変化するユーザインタフェイスを生成する。

例示的な一実施形態では、DVDプレーヤのファームウェアの変更なしでの該DVDプレーヤ-PC間接続及びEthernet ICにより、ユーザが専用ハードウェアを購入することなくホームネットワーク上でコンテンツを見ることが可能となる。該プレーヤは、DVDディスクの通常再生を妨げることなくネットワーク及びサーバの存在を自動的に検出することができる。インタフェイスを利用できるDVDプレーヤは、消費者が、所有権を有する非標準的な電子装置のための膨大な負担を被ることなく、また多数の異なるシステムを異種のインタフェイスを用いて相互接続する苦労を伴うことなく、ホームシアター機器に提示するために、全てのタイプのパーソナルコンピュータ（PC）ベースのオーディオ・ビジュアルメディアコンテンツに容易にアクセスすることを可能にする。一例は、MPEG、Windows Media、QuickTime、DivX、ビデオフォーマット、JPEG、、MP3、WMA、及びその他のスチルイメージ及びミュージックフォーマット、並びにDVDプレーヤによりサポートされていないフォーマットを含む、広範な様々なメディアタイプをサポートする。

インタフェイス及びソフトウェアは、メディア装置（例えばテレビに接続されたDVDプレーヤ）にサポートされるフォーマットでコンテンツを供給するためのマイクロプロセッサの能力をてこ入れするものとなる。インタフェイスのソフトウェア要素は、家電装置とマイクロプロセッサメディア管理アプリケーションソフトウェアとの間の通信を可能にする。例示的なシステムは、コンテンツアグリゲーション及びメディア管理ツールとしてＰＣの有効性を向上させると共に、フレキシブルで機能豊富な使い易い再生装置としてのDVDプレーヤの有効性を向上させるものとなる。細部は変化し得るが、例示的な実施形態では、ＰＣは、例えばＰＶＲ能力を有するセットトップボックスに置き換えることができ、DVDプレーヤは、ポータブルハンドヘルド娯楽装置（例えば、大型液晶ディスプレイ（LCD）画面を有する、マルチメディアをサポートする携帯電話）に置き換えることができる。

図１を参照すると、概略的なブロック図がメディアインタフェイスシステム100の一実施形態を示しており、該メディアインタフェイスシステム100は、コンテンツ操作を容易にし、及びユーザ装置102がローカルサーバ104及びリモートサーバ106からコンテンツを取得し実行することを可能にする。

通常の動作時、これから使用すべきユーザ装置102がメディアインタフェイスシステム100と接続した際に、処理が開始されて、個々のコンテンツ参照ならびにコンテンツ参照「グループ」を発見するためにローカルサーバ104及びリモートサーバ106がサーチされる。該グループは、関連する娯楽コンテンツの「ユーザプリファレンスモジュール」及び／又は「ユーザプロファイル」プレイリストという形をとることが可能である。発見された参照は、ユーザの関与又は介在を伴うことなく、自動的に集約されてユーザ装置102のメニューシステムに組み込まれる。これにより、ユーザは、該集約されたコンテンツ参照に関連するコンテンツを見ること、聞くこと、又はその両方を選択することが可能となる。ユーザプリファレンスモジュール及びプロファイル済みコンテンツの場合には、特定のモジュール又はプロファイルを選択することにより、該モジュール又はプロファイルにおける全てのコンテンツをユーザに対して利用可能とすることができる。ユーザによるプロファイルメニューアイテムの選択は、例えば、別のメニューの表示を生じさせることが可能である。新たなメニューは、選択されたプロファイルからのコンテンツの選択肢を示すことが可能である。ユーザ装置102が既に上述したように初期化されている場合には、ユーザ装置102をメディアインタフェイスシステム100に接続する動作により、ユーザ装置102のメニューシステムで既に発見されている参照と比較して新しい異なる及び／又は更新されたコンテンツ参照をサーバ104,106から収集する更新プロセスが開始される。新たに取得された参照は、ユーザ装置のメニューシステムに既に含まれるコンテンツ参照をリフレッシュするために使用される。

ユーザに対する多大な便宜のために、例示的なシステムは「ユーザプリファレンスモジュール」及び／又は「ユーザプロファイル」をサポートする。該「ユーザプリファレンスモジュール」及び／又は「ユーザプロファイル」は、商業的な投機により、及び／又はユーザにとって関心があると思われるコンテンツ参照のリストを共有する意思のある他のユーザにより、容易に用意することが可能である。かかるリストを適当なフォーマットで用意するためのツールと、プレーンテキストフォーマット並びにそれよりも遙かに複雑なパブリック・プライベートキー暗号化フォーマットとの組み合わせは周知のところである。

ユーザ装置102は、１つ又は２つ以上のソースからコンテンツを取得するホスト108（一般的にはコントローラ又はプロセッサ）を含み、該ソースには、リモートサーバ106及びネットワーク接続を介して該ユーザ装置102と通信するリモートソース、及びローカルサーバ104を介したローカルソースが含まれる。コンテンツ及びソースは動的に変化することができる。ホスト108は、ユーザにとってトランスペアレントな態様でコンテンツに対する選択及びアクセス制御を可能とするユーザインタフェイスを動的に構成する。

メディアインタフェイスシステム100のリモート構成要素106は、コードサーバ112、DRM（Digital Rights Management）サーバ114、メディアサーバ116、及びリモートインタフェイスサーバ118を含む。ローカル構成要素120は、ローカルインタフェイスサーバ104及びユーザ装置102を含み、ローカルで若しくはリモートで利用可能となるサービスを提供する。リモートサービスはネットワークノード内に含まれ、該ネットワークノードは、ローカルセグメント120内にあるよう制限されるものではない。

コードサーバ112は、リモートディスカバリサーバ124及びリモートプログラムコード126を含む。コードサーバ112は、クライアントへのプログラムコードモジュールのダウンロードといったクライアントコードを実行する。

DRMサーバ114は、キーサーバ128及びDRMアカウント機能130を含む。ブートROM（RAM）等のメモリが暗号化キーを含むことができる。例えば、ブートROMによりダウンロードされるコードは、DSA（digital signature analysis）署名されたものであるよう制限することが可能である。パブリックキー暗号化システムは、ブートROMがパブリック暗号化キーを含むことを可能にし、これにより、該暗号化キーが他のエンティティに利用可能となってクライアントソフトウェアイメージが生成されるのが防止される。ダウンロードされるイメージの先頭に署名バイトを追加し、これをクリアテキストイメージとして送信することができる。署名及び検証は、OpenSSL（www.openssl.org）を使用して実行することができる。例示的な実施形態では、暗号強度は1024ビットである。プライベートキーは公開されない。

メディアサーバ116はリモートメディア140を含む。メディアサーバ116はクライアントにメディアを供給する。

リモートインタフェイスサーバ118は、メディアサーバ132、リモートトランスコーダシステム134、SOAP（Simple Object Access Protocol）コントロールブロック136、SOAPメディア138、及びDRMパッケージ142を含む。SOAPは、プラットフォームに依存しない態様でサービス、オブジェクト、及びサーバにアクセスするようにXML及びHTTP（Hyper Text Transport Protocol）の使用を定義したXMLである。SOAPメディア定義サーバ138は、メディア構築アプリケーションと該サーバとの間で通信を行ってアプリケーションの独立性を促進させる。該２つのアプリケーションは、同じ装置又は構成要素上に配設することが可能であり、又は広範に分散された構成要素上に配設することが可能である。SOAPは、特定のメディア制御情報の業界標準の伝送を確実に行うものである。

ローカルインタフェイスサーバ104は、ローカルディスカバリサーバ144、ローカルコードサーバ146、ローカルメディアサーバ148、ローカルトランスコーダシステム150、ローカルSOAPメディア152、ローカルSOAPコントロールブロック154、UPNP（Universal Plug'N'Play）パッケージ156、ローカルDRMパッケージ158、及び診断ロガー160を含む。ローカルインタフェイスサーバ104の様々な構成要素は、単一のネットワークセグメントにおいて又は多数のネットワークにわたって、それら構成要素の全てを１つのノード内で実行することが可能であり又は多数のノードに分散させることが可能である。クライアントコーダサーバは、DHCP（Dynamic Host Configuration Protocol）サービスを用いたネットワークモデムのような単純なハードウェアを有する環境内へのクライアントのインストールを可能にするインターネットリモートサーバとして動作することが可能である。

ディスカバリサーバ144は、他のサーバ及びクライアントの調整を行う。メディアサーバ148は、クライアントへメディアを供給する。コードサーバ146は、クライアントが使用するためのアプリケーションファームウェアコードを実行する。クライアントコードサーバ146は、強力に暗号化され署名されたプログラムコードモジュールをクライアントへダウンロードする。一実施形態では、そのダウンロード方法は、効率及びクライアント認識に関して修正されたTFTP（Trivial file Transfer Protocol）の変種とすることができる。

トランスコーダシステム150は、メディア及びナビゲーション情報をクライアントフォーマットに変換する。SOAPコントロールブロック154は、照会操作及びサーバパラメータの設定を可能にする。SOAPメディア152は、照会操作及びサーバメディアの設定を可能にする。UPNPパッケージ156は、サーバをUPNP環境内に統合させる。DRMパッケージ158は、メディアの再生に関するユーザの支払いの計算を可能にする。診断ロガー160は、開発者のためのデバッグサポートを提供する。サーバは、telnetプロトコルによるインターネットリモートコンピューティング接続を提供し、これにより、様々な構成要素が動作する際に制御可能な診断ストリームが送出される。該診断ストリーム及びそれに関連する制御は、サーバコンソールアプリケーションを使用して見ることが可能である。

リアルタイムトランスコーダシステム150は、メニューを生成し、及びメディアをリアルタイムでメディアターゲットフォーマットへと変換する。該トランスコーダにより実行される様々な機能には、フィルタリング、フィルタパラメータの推定、フィルタの初期化、メニューボタンの生成、メディアパケットの取得、情報フォーマット（IFO）の取得、スタティックIFOの取得、バッファの解放、推定の解放、オプションの設定が含まれる。

例示的な実施形態では、ユーザ装置102は、（ドライブエミュレータと呼ぶこともできる）ホスト108、（ドライブコントローラと呼ぶこともできる）少なくとも１つの内部メディアドライブ162、ネットワーククライアント164、キャッシュメモリ166、復号化エンジン168、及び内部装置診断ロガー170を含むことができる。ユーザ装置102は、クライアントとして動作することができる。例示的な実施形態では、ホスト又はドライブエミュレータ108は、MPEGデコーダに関する動作を管理することができる。ドライブエミュレータ108は、システムが装置又は構成要素（例えばMPEGプレーヤとの対話に関連するDVDドライブ）の態様で動作することを可能にする。ドライブエミュレータ108は、MPEG-DVDドライブ接続経路における動作を回避してパススルー動作モードに入り、MPEGプレーヤがドライブ内のメディアについて動作することを可能にすることができる。パススルー動作モード中に、ドライブエミュレータ108は、クライアントがドライブに送られた全てのコマンドを監視すると同時に介入することを可能にする。ユーザ装置又はクライアント102は、サーバと通信するための適当なサーバインタフェイスを有する。例示的な実施形態では、サーバインタフェイスは、100Base-T Ethernetを介したものとすることが可能である。TCP（Transmission Control Protocol）を使用してサーバへコマンドを伝送することができ、及びパラレルUDP（User Datagram Protocol）ソケットの同じTCPソケットを介してデータを返すことが可能である。ユーザ装置又はクライアント102はまた、例えば、ATAPI（AT Applications Program Interface）コマンドセットの全てを許容するIDE（Integrated Drive Electronics）ドライブをエミュレートするハードウェアを使用した、適当なホストインタフェイスを有している。

ドライブコントローラ162は、随意選択的なものであり、エミュレータをサポートするユーザ装置102に備わっている大容量記憶装置といった装置を管理することができる。ネットワーククライアント164はサーバへの通信能力を提供する。キャッシュメモリ166は、メディアデータを知的に保持し及びプリフェッチする。ユーザ装置又はクライアント102は、メディアデータのための先読みキャッシュ166を有しており、またサーバにより指定された「スティッキー」ブロックのための随意選択的なパラメータキャッシュを有することもできる。復号構成要素168は、メディアのリアルタイム復号を実行する。診断ロガー170は、随意選択的なものであり、システムの開発を支援することができるものである。クライアント102は、リアルタイムで構成可能な診断ストリームをクライアントコンソールへ供給する。クライアント102は、豊富なコマンドセットを有する診断コマンドシェルを使用して多数の診断テストを可能にする。データロガー170の出力カテゴリには、エラーの指示を提供するLogError、情報ログアイテムを提供するLogInfo、詳細な状態情報を提供するLogDetail、システム関連メッセージを提供するLogSystem、及びネットワークに関するメッセージを生成するためのLogNetが含まれる。他の出力カテゴリには、IDEにより生成されたメッセージを提供するLogIDE、タイミング指示を提供するLogTimer、ATAPIコマンドに関連する情報を提供するLogCmd、ネットワーククライアント情報を提供するLogHClnt、及び低レベルCDBメッセージを示すLogCDBが含まれる。LogBCache、LogCmdPrc、BoardIO、及びCBDAddrは、それぞれ、bキャッシュのアクティビティ、コマンド処理アクティビティ、基板入出力処理、及びコマンド及びLBA情報に関する情報を提供する。MaxDetail、MidDetail、及びMinDetailは、異なる量の情報を提供する。

図２Ａを参照すると、その概略的なユースケース図は、例えば、図１に示すローカルメディアサーバ148やリモートメディアサーバ132その他のサーバという形で実施することが可能なサーバユースケース200の一実施形態を示している。サーバユースケース200は、ユーザ装置がメディア208にアクセスすることが可能となるように仮想ボリューム206内にメディアを配置する２つのアクティブユーザ（すなわちメディアモニタ202及び仮想メディアドライバ204）として示すことが可能である。メディアモニタ202は、多数の様々なメディアコンテンツソースからのストリーミングメディアを供給する。仮想メディアドライバ204は、メディアコンテンツを仮想ファイル構造内に配置し格納する。仮想ボリューム206のユースケース（例えばインタフェイスVTS（Video Title Set））は、仮想メディアドライバ204と第３のユーザ（すなわちMPEG（Moving Pictures Expert Group）デコーダ210）との間で情報を伝達させる。サーバ200はまた、メディアモニタ202と仮想メディアドライバ204との間で通信するためにメディアをトランスコードするリアルタイムトランスコーダ212を含むことができる。

メディア208のユースケースは、イメージ及びオーディオコンテンツの提示208A、複数のムービーの提示208B、DVDイメージ等のディスクイメージの提示208C、VTSの提示208D、及び複数のオーディオチャネルの提示208Eを含む、様々なコンテンツタイプを仮想メディアドライバ204に対して提示する。

インタフェイス仮想VTS206のユースケースは動的に、ユーザ対話が存在しない場合に、仮想ボリューム構造206A及びトランスコードされたメディアに関するメディア拡張ポイント206Bを含む情報へのアクセスを制御する。

リアルタイムトランスコーダ212は、トランスコーディングメディア212A及び推定212Bについてのユースケースを有する。

図２Ｂを参照すると、その概略的なユースケース図は、クライアント及びサーバ管理ユースケース214の一実施形態を示している。Console Serverと呼ばれるスタンドアロンアプリケーションは、サーバに接続して該サーバの監視及び構成を行うことを可能にするユーザコンソールを提供することができる。サーバコンソール216の一例は、ネットワーク上の各サーバに接続することができる。

Console Clientと呼ばれるスタンドアロンアプリケーションは、インタフェイスクライアントの監視及び構成を行うために該クライアントに接続することができるクライアントコンソールを提供することができる。クライアントコンソール218の一例は、ネットワーク上の各サーバに接続することができる。スタンドアロン版のクライアントコンソールは、用法のために利用可能とすることができる。コマンドコンソールは、表示及びクライアントレジスタへの書き込みのための多数のテキストベースのコマンド並びに一層高レベルのコマンドをサポートする。コンソールクライアントは、クライアントコマンド及びレジスタ値の入力を可能とする。クライアントコマンドには次のものが含まれる。
コマンド説明
Help コマンドリストをプリント
Version バージョン番号をプリント
Preg レジスタマップをプリント
（変更されたレジスタに現れる数）
PowerTest 電源オン・リセットテストを実行
FirmReset ファームウェアのリセット及びテストを実行
Dump 指定されたアドレス範囲からメモリをダンプ
Fill ダンプメモリ範囲を所与のパターンで充填
Reg FPGAレジスタ空間におけるバイトアドレスの読出し又は設定
LogMask ログマスクをプリント／設定
MemTest FPGAメモリバッファをテスト
<regname> レジスタ値をプリント／設定
<signame> 信号値をプリント／設定
IDEaddr IDEアドレスマスタ又はスレーブをプリント／設定
GetIDEcmd ATAPIコマンドを待機し、次いで該コマンドをプリント
PushData 進行中の現在のコマンドに関してデータをプッシュ
Wait <signame>又は<regname>が所定値になるまで待機
ATAPI ATAPIレジスタ設定及び信号をプリント
Verbose メッセージのプリントのアクティブ化／非アクティブ化
TI リードウェイトタイミングループを設定
Rdtoc<session><format> サーバのTOCを読出す（引数はオプション）
RunDemo デモタスクを開始
StopDemo デモタスクを停止
MyIP クライアントIPアドレスをプリント
Eject メディアをイジェクト
InitBCache<size><gran> サイズメモリ及びグラニュラリティを用いてBCacheを初期化
StartBCache<ip><port> BCacheを開始
StopBCache Bcacheを停止
NetSpeed サーバへの転送速度をテスト
OpenTray ディスクトレーをオープン
CloseTray ディスクトレーをクローズ
TUR TUR(Test Unit Ready)をドライブへ送信
MechStat Mech Statをドライブから取得
DriveReg ドライブ・レジスタをプリント
PassThrough<on||off> パススルーモードを設定
DiscDetect<count> ディスクなしを待機すべくTURの数を設定
WpBit wpBitの状態を返す
SetStream<sector_size> テ゛ィシ゛タルストリームインタフェイスに関するセクタサイス゛を設定
SendStream<#sectors><ssz> ストリームデータを送信
LoadList lba cnt<lba cnt> 送信するセクタのリストを用意
SendList<lba cnt> ロードリストを送信（随意選択的にlba cntで開始）
SetIF<avb||ata> バスインタフェイスを設定
sysspeed<server ip> avbusをプッシュする際の速度をテスト
MemSpeed 異なるキャッシュ設定でSDRAMメモリアクセスを実行
icache<off||on> 現在の設定を設定又はレポート
dcache<off||on<wt||wb>> 現在の設定を設定又はレポート
transfer lba cnt cntブロックについてlbaで始まるデータを転送
複数のサーバ、例えば、プライマリサーバ220及びセカンダリサーバ222は、プライマリサーバ選択214Aにより割り当てられ、及び図１のサーバディスカバリプロトコル（SDP）124,144を介して及びステータス送信214Bユースケースによって調整される。クライアント224がサーバに接続され214C、及びユースケースを介してサーバへと方向付けされる214D。他のユースケースには、サーバリストのアクセス214E及びクライアントリストのアクセス214Fが含まれる。

サーバディスカバリプロトコルは、サーバ220,222間で使用されて種々のサーバの調整を行い、及びクライアント224及びサーバコンソールウィンドウ216が適当なサーバを探し出すことを可能にする。プライマリサーバ220は、コーダサーバであり、及びメディアツリーのルートのIP（Internet Protocol）及びポート番号をクライアントへ提供するためのオーソリティである。該プライマリサーバ220は、サーバへの接続214C、ステータス送信214B、及びプライマリサーバ選択214Aを含む３つのユースケースを有している。セカンダリサーバ222は、クライアントリストアクセス214F及びサーバリストアクセス214Eを含む２つの更なるユースケースを有する。全てのクライアントはプライマリサーバ220に接続し、該プライマリサーバ220は該クライアントをセカンダリサーバ222へ方向付けしてもしなくてもよい。クライアント及びサーバ管理ユースケース214は、クライアント情報の共有及びステータス情報の共有において、セカンダリサーバ222とのプライマリサーバ220の対話を管理する。プライマリサーバ選択ユースケース214Aは、プライマリを選択するためのサーバの協働を含む。ネットワークセグメント上の都度収集された複数のサーバが協働して、全サーバのアクティビティを調整するプライマリサーバを選択し、及びプライマリサーバ又はその他のサーバの損害を検出し回復させる。クライアントコンソールウィンドウ218及びサーバコンソールウィンドウ216は、ネットワークセグメント上の全てのサーバのリストを取得することが可能なものである。該対話プロトコルは、ネットワークの使用及び関心のないノードへの妨害（ブロードキャストトラフィック）を効率的に最小限にする。例示的な実施形態では、プライマリサーバの割り当ての評価は、プライマリサーバ選択ユースケース214Aに制限される。単なるサーバのメディアツリーの変更については再評価は行われない。

図２Ｃを参照すると、その概略的なユースケース図は、メディアデザイナ228、メディアオペレータ230、及びメディアネットワークオペレータ232の対話を説明したメディア管理ユースケース226の一実施形態を示している。メディアデザイナ228は、XMLメディアツリーを設定し(226A)、及びXMLメディアツリーをフェッチする(226B)。該メディアデザイナ228とメディアオペレータ230との間の対話には、XMLメディアツリーのロック(226C)、XMLメディアツリーの修正(226D)、及びXMLメディアツリーの表明(226E)が含まれる。メディアオペレータ230は、DRMの情報（キー等）にアクセスし(226F)、サーバリストにアクセスし(226G)、及びクライアントリストにアクセスする(226G)。メディアネットワークオペレータ232は、サーバパラメトリクスを監視し(226I)、及びサーバパラメトリクスを修正する(226J)。

図２Ｄを参照すると、その概略的なユースケース図は、MPEGデコーダ210及びユーザ装置サーバ336の対話を説明したクライアントユースケース234の一実施形態を示している。データサーバ操作234Aは、随意選択的なドライブパススルーユースケースであり、これは、ユーザ装置が制御を明け渡すことを可能にし、及び構成要素（例えばMPEGプレーヤ及びDVDドライブ）が他のメディアプレーヤ環境の場合のように対話することを可能にする。データサーバ操作234Aは、ローカルメディア増加ユースケースであり、これは、プレーヤとドライブとの間で伝送される制御情報をユーザ装置サーバ236が監視することを可能にする。本システムは次いで、プレーヤ及びドライブの両方に影響を与える操作及びサーバ236からデータを取得する操作を実行することが可能である。次いで、サーバ236から利用可能なコンテンツによってローカルメディアに関する情報が増加される。ローカルメディアの増加は、ドライブ及びサーバ236からマージされたメディア記述を使用する。クライアントユースケース234は、読出し234B、探索234C、メディア操作234D、及びドライブ操作234Eを含み、その全ては、データサーバ操作ユースケース234Aをパススルーすることが可能である。

実施形態によっては、クライアント環境は、低レベルのリード・オンリー・ブートファームウェア及びクライアントソフトウェアの実行のための大規模リード／ライトメモリ領域で実施することが可能である。ブートROMは、初期ネットワーク構成、及びコーダサーバ（図１に示すリモート112又はローカル104）からのクライアントソフトウェアのダウンロードを実行することができる。

図３を参照すると、その詳細な状態図は、エミュレータ300により実行される機能の一例を示している。種々の実施形態において、エミュレータ300は、ソース装置、シンク装置、又は外部装置といった様々な装置及び構成要素からの複数の操作のうちの１つ又は２つ以上を実行することが可能である。

エミュレーション機能では、エミュレータ300は、対話中の装置の識別に関して、ソース装置、シンク装置、及び外部装置のうちの１つ又は２つ以上を欺く制御信号、データ、及び応答を生成する。ネットワーク接続を有する光学式メディアプレーヤの例では、光学式ドライブがソースとして機能し、光媒体デコーダがシンクとして働き、及びリモートコンピュータが外部装置として動作する。エミュレータ300は、光媒体デコーダが、リモートコンピュータからのコンテンツを、光学式ドライブのトランザクションと同じ対話で提供することができるように、それら装置をだますことができる。光学式ドライブは、リモートコンピュータのためのコンテンツを、光媒体デコーダへの供給と同じ対話で供給することができる。書き込み可能なドライブの場合には、リモートコンピュータは、光学式ドライブのためのコンテンツを、バスから該ドライブへの書き込みと同じ対話で供給することができる。

エミュレータ300は、ハードウェアテストが成功した場合に進行するハードウェア電源投入初期化動作302と共に動作を開始する。次に、オペレーティングシステムカーネル初期化動作304がオペレーションソフトウェアを初期化する。TCP/IPソケット初期化動作306は、通信のためのEthernetスタックを用意する。エミュレータタスク開始動作310は、同期ポイント315で同時に同期して実行するエミュレータ状態機械312及びサーバ状態機械314を含むエミュレータ300の動作を開始する。

例示的なエミュレータ状態機械312は、メディアなしバスアイドル状態316、メディアありバスアイドル状態318、及び読み出しデータバス待機状態320を含む、３つの待機状態を有する。この例示的なエミュレータ状態機械312は、フィールドドライブ情報要求状態322、フィールドメディア要求状態324、バス読み出しデータ配信状態326、フィールド読み出し要求状態328、及びフィールド探索要求状態330を含む、５つのコマンドアクション状態を有する。

例示的なサーバ状態機械314は、メディアホスト接続状態332、ネットワークメディアアイドル状態334、メディアなしホスト状態336、及び読み出しデータネットワーク待機状態338を含む、４つの待機状態を有する。この例示的なサーバ状態機械314は、メディア存在状態340、探索パケット送信状態342、読み出しパケット要求送信状態344、及び読み出しデータ到着又はタイムアウト状態346を含む、４つのアクション状態を有する。

メディアなしホスト状態336は、メディア接続がオープンしている際にはメディアホスト接続状態332へと進むが、メディア接続がクローズされている際には戻る。同様に、ネットワークメディアアイドル状態334は、メディア接続が失われた際にメディアなしホスト状態336に戻る。メディアホスト接続状態332は、メディアパケットが到着した際にアクション・メディア存在状態340へと進むが、メディアが除去された際に戻る。メディア記述が利用可能である場合には、エミュレータ状態機械312は、メディアが識別された際にメディアありバスアイドル状態318へと進む。メディアありバスアイドル状態318は、ドライブデータ要求時にフィールドドライブ情報要求状態322へと進み、応答時に戻る。メディアありバスアイドル状態318は、メディア要求時にフィールドメディア要求状態324へと進み、応答時に戻る。メディアありバスアイドル状態318は、読み出し要求時にフィールド読み出し要求状態328へと進み、サーバ状態機械314を読み出しパケット要求送信状態344にするLBA（Logical Block Address）信号を生成する。LBA要求時に、サーバ状態機械314は、読み出しパケット要求送信状態344から読み出しデータネットワーク待機状態338へと進み、読み出しの再試行時に戻る。読み出しデータネットワーク待機状態338では、サーバ状態機械314は、読み出しデータ到着又はタイムアウト状態346へと進み、キューデータ信号でエミュレータ状態機械312はバス読み出しデータ配信状態326になる。データ送信完了信号で、エミュレータ状態機械312は、バス読み出しデータ配信状態326からメディアありバスアイドル状態318になる。

エミュレータ状態機械312のメディアなしバスアイドル状態316は、ドライブデータ要求時にフィールドドライブ情報要求状態322へと進み、応答時に戻る。メディアなしバスアイドル状態316は、メディア記述子が到着したときをサーバ状態機械314に知らせ、サーバ状態機械314をネットワークメディアアイドル状態334にするメディアID応答を生成する。該ネットワークメディアアイドル状態334は、バス探索要求が生じた際に、エミュレータ状態機械312をメディアありバスアイドル状態318にする探索応答を生成する。該該メディアありバスアイドル状態318は、バス探索時にフィールド探索要求状態330へ進む。探索要求時のフィールド探索要求状態330は、サーバ状態機械314を探索パケット送信状態342にする探索宛先信号を生成し、該探索パケット送信状態342は応答時にネットワークメディアアイドル状態334へ移行する。

読み出し要求時のネットワークメディアアイドル状態334は、サーバ状態機械314を読み出しデータバス待機状態320にする読み出し許可信号を生成する。該読み出しデータバス待機状態320においてデータの準備が完了すると、応答がサーバ状態機械314をネットワークメディアアイドル状態334にする。

エミュレータ300は、特定のシンク装置の機能を決定し、リモート装置のための機能を詳細に模倣する。特定の実施形態では、エミュレータ300は、固定又は可変ビットレートの圧縮ディジタルビデオで１トラック又は１ストリームのMPEG-2を生成することにより、ディスクドライブを模倣することができる。特定のエミュレータ300は、フィルムからのプログレッシブな24フレーム／秒(fps)、PALビデオからインタレースされた25fps、及びNTSCビデオからインタレースされた29.97fpsという符号化されたフレームレートを有する、525/60（NTSC,29.97インタレース済フレーム／秒）及び625/50（PAL,25インタレース済フレーム／秒）の固定又は可変ビットレートのMPEG-1、CBR、及びVBRビデオをサポートすることが可能である。インタレースされたシーケンスは、プログレッシブなピクチャ及びマクロブロックを含むことができる。エミュレータ300は、ビデオストリーム内にフラグ及び信号を配置して、所定の表示速度を生じさせる表示周波数を制御することが可能である。エミュレータ300は、インタレース処理、プログレッシブなフレーム表示、エンコーディング、及びミキシングを制御することができる。エミュレータ300は、選択された期間にわたってMPEG-2 I-フレームとしてエンコードされた複数の静止フレームを表示することができ、及びキャプション、サブタイトル、カラオケ、メニュー、及びアニメーションのためにビデオ上に重なる複数のサブピクチャストリームを生成することができる。

エミュレータ300は、コンテンツを送出する装置のファイルシステム及び該ファイルシステムとの通信方法を提示することにより該装置を模倣する。ソース-シンク対話の開始時に、システムは、ソース装置との接触を探索する。エミュレータ300は、ソース装置のファイル構造及びコンテンツ探索をリモート装置において真似て、実際のソース装置又は該ソース装置をエミュレートしているリモート装置からのコンテンツの選択を可能とする。

特定の実施形態では、エミュレータ300は、UDF(Universal Disk Format)又はマイクロUDFファイルシステム等のファイルシステムをエミュレートし、及びライトワンス・フォーマット及びリライタブル・フォーマットの両方をサポートすることが可能である。実施形態によっては、エミュレータ300は、レガシーオペレーティングシステム、プレーヤ、及びコンピュータとの互換性を確保するために、UDF、UDFブリッジ(ISO 9660)、及びISO 13346規格をサポートすることが可能である。

エミュレートされたトランザクションが選択される場合、エミュレータ300は、ソース−シンクトランザクションのプロトコルに従って要求及びデータを交換することにより、該トランザクションを管理する。エミュレータ300はまた、ソース装置を分離させ、該ソース装置により通信される制御信号及びデータを阻止し及びオーバーライドし、並びにシンク及びリモート装置とエミュレートされているソースとの間における信号及びデータの対話を可能とする。様々なシステム及びトランザクションにおいて、エミュレータ300は、シンク装置の通知なしでトランザクションを模倣することができる。他のシステム及びトランザクションでは、エミュレータ300は、エミュレーションが発生して実際のリモートコンテンツソースを識別していることを示す情報をシンク装置に伝達することができ、これにより、ネットワーク対話の更なる制御が可能となり、リモート装置の更なる能力が十分に引き出され、及びレンダリング能力が拡張される。例えば、エミュレータ300は、ソース装置及びエミュレート中のリモート装置からのコンテンツの同時レンダリングを可能にするトランザクションを制御することができる。１つの特定の能力が、ソースコンテンツ及びリモートコンテンツのピクチャ・イン・ピクチャ表示である。もう１つの特定の能力が、ウェブサポート強化型DVDであり、これは、DVDからのコンテンツを特殊なネットワークアクセス型アプリケーションと組み合わせる能力を拡張させたものである。

エミュレータにより実行することが可能なソフトウェア又はファームウェアは、メディアコンテンツナビゲーション、ユーザインタフェイス処理、サーボファームウェア、及びデバイスドライバといった多くの機能を含むことが可能である。

図４を参照すると、その概略的なブロック図は、ネットワーク上に分散されたリソースとして機能するメディアツリー400の一実施形態を示している。サーバは、メディアフォーマット及びソースを解析して、ターゲットデバイスが全ての分散されたメディアにアクセスすることを可能にするナビゲーション構造を構築し、これにより、コンテンツアクセスの動的な制御をユーザの介在又は対話なしに自動的に行うことが可能となる。メディアは、DRM（Digital Rights Management）、暗号化、及びメディアプレーヤの課金事項に従って、利用可能なものとしてアクセスされる。メディアツリー400は、Video Title Set (VTS)メニュー404、メディアアイテム406、及びメディアメニュー408を含む分岐へのポインタを含むルートメニュー402から延びるものである。VTSメニュー404、メディアアイテム406、及びメディアメニュー408は、リモートメディアサーバ410及びリモートビデオサーバ412を介してアクセスすることが可能である。

メディアフォーマットは、トランスコーダシステムによって決定される。例えば、Microsoft DirectShow エンジンにより表示することができる殆どのフォーマットは、DVD MPEGビデオ規格へとトランスコードすることができる。

メディアシステムは、多くのレベルでセキュリティ操作を処理する。あるメディアプロデューサからのメディアは、他のメディアプロデューサによる改変から保護される。ある分類のユーザによるメディアの参照は、他の分類のユーザによって制限される。DRM（ディジタル著作権管理）メディアの参照は、ディジタル著作権の所有者により許可される。

図５を参照すると、その概略的な状態図は、図１に示したローカルメディアサーバ148の場合のような、クライアントメディアサーバ500の一実施形態を示している。該クライアントメディアサーバ500の動的なボリューム状態は、待機状態502、クライアントアイドル状態504、修正ツリー状態506、及び置換ツリー状態508を含む。待機状態502では、クライアントメディアサーバ500は、メディアツリー設定信号又はフラグを待つ。メディアツリー設定信号を受信すると、該サーバは、メディアツリーを構築し（510）、次いでクライアント要求を処理する（512）。ツリー修正要求を受信すると、該サーバ500は、該ツリー修正要求514を処理して、ツリー修正状態506に入る。

ツリー修正状態506において、サーバは、クライアント要求を処理し（516）、該クライアント要求に従ってツリーを修正する（518）。変更ツリー分岐ロックオフ状態520では、影響を受けないクライアント要求が続く際に、修正すべきツリー分岐がロックオフされる。

複数のクライアント要求間で、サーバは、クライアントアイドル状態504に入る。全てのクライアントがアイドル状態504に入った後にのみ、ツリーが置換される。ツリー修正状態508では、サーバはクライアント要求を処理し（522）、該クライアント要求に従って、旧いツリーを破壊して（524）メディアツリーを構築することができる（526）。

ユーザにより供給されたメディアファイルのフォーマットが（例えば、ファイル拡張子又はファイルヘッダの調査を介して）判定されると、システムは、該ファイルのメディアをシンク装置上で成功裏にプレゼンテーションするための機構をインテリジェントにアセンブルする。該機構は、単純なマッピング、拡張された通信能力の使用、トランスコーディング、又はコンテンツをシンク装置に供給しハードウェアまたはハードコードされた変換装置を使用することなく該コンテンツを該装置上で該装置に固有のフォーマットで再生することを可能にする他の技術とすることが可能である。

実施形態によっては、システム内の１つ又は２つ以上のトランスコーダを省略して、プレゼンテーションのための互換性のあるフォーマットへとコンテンツをデコードする１つ又は２つ以上のデコーダに置換することが可能である。デコーダによる一実施形態は、クライアント上に存在する複数のデコーダを使用することが可能である。デコーダによるもう１つの実施形態は、プログラム可能なクライアント上に存在する１つ又は２つ以上のデコーダを使用する。該デコーダは、クライアント上に存在するデコーダコードの多数のバージョンをダウンロードすることにより再構成することが可能である。更に別の実施形態は、コンテンツと共にダウンロードすることが可能なデコーダコード（その特定のコンテンツ及びフォーマットに適したもの）を使用することが可能である。ダウンロード可能なデコーダコードの使用は、特定のアプリケーション又はコンテンツフォーマットに合わせてデコーダを多目的に作成することを可能にする。

トランスコーダの代わりに１つ又は２つ以上のデコーダを使用する実施形態の場合には、１つのデコーダは、到来するコンテンツに問い合わせて、どのデコーダを使用すべきかを判定し、該デコーダ識別情報をクライアントに送って、デコーダの正しい構成を可能にする。適切なデコーダは、一般に、ユーザに対してトランスペアレントな自己構成を実行することができ、又はコンテンツを伴う適切なデコーダコードを送って、該送られたデコーダコードを使用してクライアントが自己構成を行うことの要求を該クライアントへ通知することができる。デコーダによる実施形態は、本例示のトランスコーダシステムほど多目的性を有するものではない。これは、デコーダが一般に、DVDプレーヤ等の従来の又は既存のクライアントシステムとは異なるクライアントファームウェア及び／又はハードウェアの使用を必要とするからであるが、将来のクライアントはプログラム可能なデコーダをサポートする可能性がある。

図６を参照すると、そのユースケース図は、ユーザ装置サーバ602とメディアトランスコーダ604（DVDトランスコーダ等）との間の操作を含むメディアトランスコーダシステム600の一実施形態を示している。１つのユースケースが、トランスコーディングタスクの定義600Aであり、該タスクにおいて、インタフェイスがメディアファイルのリストをメディアトランスコーダ604へ供給する。メディアファイルは、１つの特定のメディア「ビデオオブジェクト（VOB）」へとトランスコードされ、又はそれが適当である場合には一連のVOBオブジェクトへとトランスコードされることになる。

ユースケース600Bは、ビデオオブジェクト（VOB）の記述である。一連のメディア準拠情報フォーマット（IFO）ファイルのコンテンツバッファとして、情報がメディアトランスコーディングパッケージからサーバへ送られる。トランスコーダは、生成されるVOBオブジェクトの各々毎にIFOを１つずつ生成する。トランスコーダは一般に、VOBファイルシリーズのベースアドレスが論理ブロックアドレス(LBA)0であるという仮定の下で動作し、サーバは、デコーダへの提示に適した論理ブロックアドレス変換を管理する。

未加工メディアファイルデータフェッチユースケース600Cは、トランスコーディングのためのデータをフェッチする。サーバは、トランスコーダがランダムアクセス操作を使用して未加工メディアデータをフェッチするために従来の読み出し専用ブロック指向インタフェイスを供給する。

トランスコード済データ提供ユースケース600Dは、データフェッチ処理と同期させてデコーダへ伝達するようにVOBデータストリームをリアルタイムでサーバに供給する。トランスコーダ管理ユースケース600Eは、メディアトランスコーダ604及びサーバ602に共通のリソース管理を提供する。トランスコーダは、必要なときにリアルタイムで作成され使用される。特定のトランスコーディング操作が完了すると、該トランスコーダが終了し削除される。

図７を参照すると、その構成要素図は、エミュレータインタフェイスと共に使用するためのサーバ700の様々なシステム、ハードウェア、及びソフトウェア構成要素を示している。一例としてのサーバ700は、システム702（コンピュータ、パーソナルコンピュータ、ワークステーション、ラップトップ、パームトップコンピュータ、ノートブックコンピュータ、又はプログラムコードを実行するための他のあらゆるタイプの装置等）上で実行することができる。サーバ700は、１つ又は２つ以上の様々な情報処理装置と通信することができ、該情報処理装置には、ソース又は情報又はコンテンツとして機能する装置であって、供給された情報又はコンテンツを表示し、実行し、又はレンダリングし、及び装置を制御するものが含まれる。例示する実施形態では、サーバ700は、Ethernet接続708を介して、クライアント装置720、MPEGデコーダ等のデコーダ704、及びDVDドライバ706と通信するよう構成されている。これらの装置は、例示のみを目的としたものであり、多くの他のタイプの情報処理装置を補充し又はそれらに置換することが可能なものである。クライアント装置720、デコーダ704、及びDVDドライバ706は、IDEバス710により結合された単一のシステムという形でそれぞれ示されている。他の実施形態では、それら装置を異なるシステムで構成し、IDEバス710とは異なる内部インタフェイスを有することが可能である。

サーバ700は、１つ又は２つ以上のサーバアプリケーション712を含み、該サーバアプリケーション712は、オーディオ−ビジュアル(AV)システム715及びメディアディレクトリ718と相俟って実行されて、様々なオーディオ−ビジュアル装置及びコントローラ間の対話を管理する。サーバ700は、サーバアプリケーション712（例えば、所望のコンテンツ処理アプリケーションを実行するソフトウェアアプリケーション）の処理によって、Ehternet接続708を介して装置と通信する。サーバアプリケーション712は、メディアを、システム715によりナビゲートすることが可能なデータボリュームへと仮想化する。サーバアプリケーション712は、ソースメディアの特徴を評価することができ、必要であれば、該特徴をより一般的な形に修正することができる。例えば、DVDベースのサーバ700は、より一層DVDに見えるようデータフォーマットを変更することが可能である。サーバアプリケーション712は、サーバ700に接続され得る多数のクライアントのうちの１つ又は２つ以上へのデータストリーミングを管理する。

一般に、サーバアプリケーション712は、情報伝送エンティティ及び処理タイプを制御する。サーバアプリケーション712は、コンテンツソース及びレンダラとして機能する装置、コンテンツについて実行される処理のタイプ、及び他のあらゆる制御及び管理機能を決定し、選択する。例えば、サーバアプリケーション712は、実行に利用することができるコンテンツのタイプ、及びコンテンツについて実行することができる処理の分類を示すグラフィカルユーザインタフェイス表示を最初に生成することができる。ユーザは、該表示に応じて、所望のコンテンツ及び処理を選択することができる。サーバアプリケーション712は、選択されたコンテンツソース及びレンダラへの制御信号を生成し送信することができ、該コンテンツソース及びレンダラが、コンテンツアクセス、送信、レンダリング、及び表示を開始する。サーバアプリケーション712は、ソースからコンテンツを処理し又は修正するレンダラまでの経路中にある装置を（もしあれば）アクティブにする制御信号を生成し送信することができる。応用例によっては、サーバアプリケーション712は、サーバプロセッサ上での実行に適したコンテンツ処理ルーチンを実行することができる。

AVシステム715は、様々なタイプのオーディオ−ビジュアル装置間の一般的な対話を管理し、及び装置タイプ、コンテンツフォーマット、及びデータ転送プロトコルにかかわらず広範な装置構成及び用途をサポートする。例えば、AVシステム715は、制約のない様々なオーディオ−ビジュアル装置をサポートすることができ、該装置には、コンピュータ、PC、ラップトップ、パームトップコンピュータ、携帯電話、ワークステーション、ビデオ表示装置、電子ピクチャフレーム、テレビ、CD/DVDプレーヤ及びジュークボックス、ビデオカセットレコーダ、セットトップボックス、カムコーダ、スチルイメージカメラ、オーディオシステム、ステレオ、MP3プレーヤが含まれる（但し、これらには制限されない）。該AVシステム715は、制約のない広範なコンテンツ、情報、及びデータフォーマットをサポートすることができ、該データフォーマットには、MPEG（Motion Pictures Expert Group）（MPEG2,MPEG4）、JPEG（Joint Photographic Experts Group）、MP3（MPEG-1 Audio Layer-3）、WMA（Windows Media Architecture）、BMP（ビットマップ）、NTSC（National Television Standards Committee）、PAL（Phase Alteration Line）、SECAM（Sequential Couleur avec Memoire）、ATSC（Advanced Television Systems Committee）、VCD（Video Compact Disk）及びS-VCD規格が含まれる（但し、これらには制限されない）。AVシステム715は、サーバアプリケーション712及びメディアディレクトリ718と組み合わせて、様々なコンテンツソース、コンテンツレンダラ、及びコントローラの機能を選択し、及び定義する。

AVシステム715は、メディアレンダラ714、メディアコントローラ716、及び標準的なメディアサーバ742を含む。AVシステム715は、コンテンツソース、コンテンツレンダラ、及びAV対話コントローラの間の対話を定義し管理する。実施形態によっては、AVシステム715は、あらゆるタイプのメディアソース装置及びあらゆるタイプのメディアレンダリング装置に対して高度なフレキシビリティと互換性とを有するものとすることができる。

サーバ700は、メディアディレクトリ718の１つ又は２つ以上のメディアソース744,746のコンテンツにアクセスする。メディアコントローラ716は、ユーザがメディアディレクトリ718からコンテンツを探し出し選択すること及びターゲットレンダラを選択することを可能にする。該メディアレンダラ714は、選択されたコンテンツを取得し、選択されたターゲットレンダラへの該コンテンツの転送を指示する。

例示的な実施形態では、メディアレンダラ714は、トランスコーダ730、仮想論理ブロックアドレス（LBA）マネージャ732、仮想コンテンツファイルマネージャ734、及び仮想コンテンツレンダラ740を含む。一実施形態では、トランスコーダ730は、MPEG-VOB（ビデオオブジェクトブロック）トランスコーダであり、仮想コンテンツファイルマネージャ734は、仮想IFO/VOBマネージャである。MPEG-VOBトランスコーダは、コンピュータで取り扱うためのビデオコンテンツの圧縮及び表示を行うために一般に使用されるMPEGフォーマットから、DVDプレゼンテーション及びムービーの標準的なフォーマットであるVOBファイルへと変換する。VOBファイルは、多数の多重化されたオーディオ／ビジュアルストリームを含む。仮想IFO/VOBマネージャは、VOBファイル及びIFO（information format）ファイルを取り扱い、該IFOファイルは、特定のフォーマットのVOBファイルを記述する情報（アスペクト比、サブタイトル、メニュー、言語等の再生情報を含む）を含む。

サーバ700は、特定のオーディオ／ビジュアル用途に依存する他のフォーマットの情報をトランスコードするトランスコーダ及び仮想コンテンツファイルマネージャを含むことができる。例えば、トランスコーダ730は、様々なフォーマット間でコンテンツをトランスコードすることができるよう実施することが可能である。かかるフォーマットには、MPEGビデオ、ディジタルビデオ(DV)、MPEGエレメンタリ(ES)又はプログラムストリーム(VOB)、YUV4MPEGストリーム、NuppleVideoファイルフォーマット、及びDivX、OpenDivX、DivX 4.xx、又はMPEG、AC3（パススルー）、及びPCMオーディオを有する未圧縮のAVIファイルを書き込むための未加工又は圧縮済（パススルー）ビデオフレーム及びエクスポートモジュールのうちの１つ又は２つ以上が含まれる。特に有用なトランスコーディング用途の一例が、JPEG-MPEGトランスコーディングである。他の例では、ディジタルビデオをMPEGへトランスコードすることができる（低品質ディジタルビデオから高品質MPEGへのトランスコーディングを含む）。

オーディオの一例では、トランスコーダ730は、MP3メディアファイルを、ドルビーAC3パルス符号変調（PCM）フォーマットへトランスコードすることができる。

DVDプレーヤ用途では、トランスコーダ730は、あらゆる書き換え可能なメディアをDVDプレーヤで見るためにトランスコードすることができる。例えば、パワーポイントプレゼンテーションは、DVDプレーヤ上のビデオプレゼンテーションへとトランスコードすることができる。

トランスコーダ730は、未加工のビデオ／オーディオストリームを用いたトランスコードを提供するインポートモジュールとデータフレームをエンコードするエクスポートモジュールとを含むコンテンツロードモジュールを使用して、デコーディング及びエンコーディング処理を実行する。典型的なトランスコーダ730は、エレメンタリビデオ及びオーディオフレーム変換（ビデオフレーム・デインタレース処理又は高速リサイズ処理及び外部フィルタロード処理を含む）をサポートする。トランスコーダ730により実行される様々な処理には、インポート用の未加工ビデオ／オーディオストリームへのソースコンテンツの逆多重化処理、抽出処理、及びデコード処理、並びに、ファイルの後処理、ファイルヘッダ情報の設定、複数のファイルのマージ、又は格納用ファイルの分離を可能にするためのソースコンテンツのプローブ及びスキャン処理が含まれる。

典型的なトランザクションでは、トランスコーダ730が、ユーザコマンドによりアクティブにされて、コンテンツ転送の初期設定を行い、オーディオ及びビデオストリーム及びエンコーディングフレームの転送及びバッファリングを開始するモジュールをアクティブにする。例えば、フレーム及びそれに関連するファイルオフセットを有する１グループのピクチャリストを含むナビゲーションログファイルを生成することにより転送を開始させることができる。次いでトランスコーダ730は、１つ又は２つ以上のビデオ／オーディオフレーム操作を実行し、または操作を行わずに単純に未加工データを通過させる。ビデオフレーム操作は、処理のための任意のフレーム領域の除去、ビデオフレームのデインタレース処理、ビデオ幅または高さの拡大又は縮小、イメージリサイズ処理のためのフィルタ処理、エンコーディングのための任意のフレーム領域の除去、及びビデオ幅／高さのダウンサンプリングを含むことが可能である。他のビデオ操作としては、ビデオフレームフリップ処理又はミラーイメージ処理、ガンマ補正処理、アンチエイリアシング処理、又は色操作を含むことが可能である。オーディオフレーム操作は、ボリューム変更処理、オーディオストリーム・リサンプリング処理、及びビデオフレームとオーディオフレームとの同期処理を含むことが可能である。

トランスコーダ730は、オーディオ／ビデオエンコード処理のためのエクスポートモジュールをロードして、選択されたフレームについて開始されるエンコーダループ処理を始めることができる。

仮想LBAマネージャ732は、メディアにおける仮想論理ブロックアドレスの定義及びアクセスを制御し、該仮想論理ブロックアドレスをメディアの物理記憶アドレスに関連付ける。仮想論理ブロックアドレシングを生成することにより、仮想LBAマネージャ732は、様々な異なるコンテンツソースからのコンテンツの動的なアクセスを、特定の物理的なソースの態様で管理する。このようにして、仮想LBAマネージャ732は、第１の装置（例えば標準的でない又は一般的でない装置）が第２の装置（例えば論理ブロックアドレシングを使用してシステム内のコンテンツを通常供給する装置）をエミュレートすることを可能にする。特定の実施形態では、仮想LBAマネージャ732は、インターネットから取得したコンテンツからDVDプレーヤのコンテンツのアドレシングをエミュレートすることができる。

仮想コンテンツマネージャ734は、仮想LBAマネージャ732と共に動作して、物理アドレスから仮想ブロックアドレスへのマップを記述する。仮想コンテンツマネージャ734は、コンテンツデータの全ての要素を追跡し、ローカルデータリンク及びリモートデータリンクを含む関連するデータ間のリンクを維持する。サーバ700上のストレージは、相互に参照するファイル間の多数のリンクされたリストという構成を有するものである。仮想コンテンツマネージャ734は、１つ又は２つ以上のメディアボリュームについてファイル間のリンクを維持し、識別し、及び配置する。仮想コンテンツマネージャ734は、ディレクトリ及びボリューム管理レベルでリファレンスの一貫性が確保されるようIFOファイルリファレンスが維持されることを検証し確実にする。

仮想コンテンツマネージャ734は、仮想メモリマネージャがコンピュータ内で動作する態様で、メディアコンテンツの記憶及びアクセスを操作するように機能する。仮想メモリマネージャはメモリのチャンクを追跡する。仮想コンテンツマネージャ734はメディアのチャンクを追跡する。仮想コンテンツマネージャ734は、メディアの複数のチャンクを重複するアドレシングを用いて記憶することを可能にする。

仮想コンテンツマネージャ734は、メディアコントローラ716から、コンテンツのアクセス及びプレゼンテーションを開始し又は修正するコマンドを受信する。仮想コンテンツマネージャ734は、これに応じて、IFOファイルのフォーマットを決定し、及び（必要に応じて）仮想LBAマネージャ732及びトランスコーダ730をアクティブにして、メディアストリーミングを開始させる。仮想コンテンツマネージャ734はまた仮想コンテンツレンダラ740と共に機能してメディアレンダリングを実行する。

仮想コンテンツレンダラ740は、メディアファイルについて動作して、DVDプレーヤ等のプレゼンテーション装置の機能及び能力に合うようメディアをフォーマットする。

例示的な一実施形態では、仮想コンテンツレンダラ740は仮想IFO/VOBレンダラである。仮想コンテンツレンダラ740は、仮想コンテンツマネージャ734による指示に従ってコンテンツデータを操作してコンテンツのレンダリングを行う。仮想コンテンツレンダラ740は、コンテンツデータ要素を操作して、仮想コンテンツマネージャ734により識別され探し出されたファイルに情報を供給する。仮想コンテンツレンダラ740はまた、カスケード型メニューとして現れる選択ツリーの作成を含むIFOファイルを未だ有していないメディアについてIFOファイルを作成する。IFOファイルは、メニューのプレゼンテーションを含み様々なファイルを再生するために使用される。メニューは、メディアのクラスタの選択を提示するものである。仮想メディアレンダラ740は、全てのメディアがアクセス可能になるまでツリー構造で多数のメニューを生成することができる。仮想コンテンツレンダラ740は、プレイリスト構造を明示するものとしてIFOファイルを作成する。

IFOファイルを有さないメディアの他の例は、ディジタルビデオからのMPEGであり、又はスライドショー用のパワーポイントデータ等の無数の他のソースである。用途によっては、仮想コンテンツレンダラ740は、プレゼンテーション用にレンダリングすることなく、存在しないコンテンツを追加する。例えば、仮想コンテンツレンダラ740は、JPEGイメージを構成し、及び充填コンテンツを追加して、MPEGイメージのスライドショーを作成し、これによりスライドショー機能を生成することができる。例示するメディアコントローラ716はメディアスキャナ738を含む。例示的な実施形態では、メディアコントローラ716は、メディアスキャナ738の処理を介してメディアが如何に展開しているかを監視することを可能にする。

メディアスキャナ738は、メディアディレクトリ718を追跡し、メディアコンテンツ及びメディアディレクトリ718が可変となることを可能にする。メディアスキャナ738は、メディアディレクトリ718に規則的にアクセスして、該メディアディレクトリ718のコンテンツに何らかの変化が生じたか否かを判定し、メディアの変化を追跡すべくメディアレンダラ714及びサーバアプリケーション712の仮想構造を変更する。メディアスキャナ738は変化を監視し、あらゆる変化に応じて仮想構造を更新させる。

標準的なメディアサーバ742は、ローカルに記憶され又は外部装置に記憶された、様々なコンテンツにアクセスすることができる。標準的なメディアサーバ742は、コンテンツにアクセスすることができ、及び該アクセスしたコンテンツを標準的な転送プロトコル（例えばHTTP又はFTP）を使用してネットワークを介して別の装置に転送することができる。標準的なメディアサーバ742は、ネットワーク上で様々な装置から利用可能なコンテンツを探し出すことができ、及びメディアコントローラ716と通信して利用可能なコンテンツアイテムのブラウズ又はサーチを行うことを可能にする。標準的なメディアサーバ742は典型的には、コンテンツディレクトリ、接続マネージャ、及びトランスポータを含む。該コンテンツディレクトリは、メディアコントローラ716と対話してコンテンツのサーチ又はブラウズを行い、及びコンテンツを特定的に識別する情報又はプロパティを供給する機能を含む。接続マネージャは、コンテンツの転送準備、フロー制御コマンドの発行、多数のレンダラをサポートするための多数のインスタンスの区別、及び転送が完了した際の接続の終了を含む、特定の装置に関する接続を管理する。トランスポータは、メディアコントローラ716と共に動作させてコンテンツのフローを制御するために使用することができる。標準的なメディアサーバ742は、従来のレンダリングハードウェアによりアクセスできるようにするために大きな変更を必要としないメディアを供給することができる。

メディアディレクトリ718は、メディアの収容手段であり、全ての利用可能なメディアコンテンツのリスト及びおそらくは該メディアコンテンツの一部又は全てを保持するものである。該メディアディレクトリ718は、仮想メディアディレクトリとして動作し、ローカルに記憶されたメディアコンテンツ及び他のサーバ及び装置により収容されたリモートメディアへのアクセスを可能とし容易にする。メディアディレクトリ718は、コンテンツリソースを識別するURI（Uniform Resource Identifiers）を記憶する。URIは、WWWアドレス、UDI（Universal Document Identifiers）、URI（Universal Resource Identifiers）、及びURL（Uniform Resource Locators）及びURN（Uniform Resource Names）の組み合わせを含む。Uniform Resource Identifiers は、名称、ロケーション、又はその他の特徴によりリソースを識別するフォーマットされたストリングである。メディアディレクトリ718は、サーバ700がレンダリングのために配信することができる全てのファイルのURIを保持する。該URIは、何処かに記憶されているファイルに対応することができるものである。

メディアディレクトリ718は、利用可能なコンテンツソース（例えばメディアソース744,746）を識別し、該メディアソースのうちの１つ又は２つ以上からのコンテンツの取得を容易にするためのディレクトリ情報を収容する。

図８Ａを参照すると、そのタイミングチャートは、通信スレッド802を介したレンダラ714とサーバアプリケーション712との間の対話800を示している。例示的な実施形態では、ダイナミックリンクライブラリ（DLL）である「MaestroLink Netcoms communication」は下記のプロセスをコールする。

bool MaestoLinkRegister(void)
Noopは、接続が行われて下記の要求を開始する準備が整った際に「真」を返す。

bool MaestroLinkComm(unsigned int *lba, unsigned int *count,
*unsigned char *data, unsigned int count)
該コールは、一回の動作でMaestroLinkにデータを供給してその次の要求を収集する。MaestroLinkへ最初にコールする場合、d長さがゼロであり、データポインタがNULLである。MaestroLinkは、指定されたポインタで要求を供給する。データが入手可能になると、MaestroLinkCommが再びコールされて、現在のデータが有効になる。MaestroLinkCommが次のdat要求を取得するまでリターンは行われない。照合を可能にするために、論理ブロックアドレス及びカウントは、MaestroLinkCommのダウンロードリンクライブラリによってのみ変更される。

図８Ｂを参照すると、そのタイミングチャートは、ユーザ装置806、DHCP（Dynamic Host Configuration Protocol）サーバ808、サーバアプリケーション810、及びディスカバリサーバ812の間の対話804を示している。

図８Ｃは、プライマリサーバ816とセカンダリサーバ818との間のサーバ調整対話の概略的なユースケース図814である。サーバディスカバリプロトコルは、ネットワークセグメント上の複数のサーバの調整及び秩序正しい動作を可能とする。１つのネットワークセグメントは、１つ又は２つ以上のサーバと、ゼロ又は１つ以上のクライアント及び／又はサーバコンソールウィンドウとを含む。プライマリサーバ816とゼロまたは１つ以上のセカンダリサーバ818との実例は、メディアツリーを要求しているクライアントのための単一のエントリポイントを可能とする。サーバロギングコンソールは、ネットワーク上のあらゆるサーバを制御し監視するためのウィンドウベースのユーザインタフェイスを提供する。コンソールサーバは、サーバ及びクライアントのIP（Internet Protocol）アドレスへのアクセスを可能とし、例えば、ローカル装置上で実行されているサーバのIPアドレス及びおそらくはマシン名をタイトルバー内に示すことができ、及びサーバ及びクライアントのIPアドレス及びそれに関連するマシン名のリストを該サーバにより維持してサーバコンソールウィンドウ内に表示することができる。サーバ機能は、ツールメニューを介してサーバコンソールウィンドウ内で修正のために利用することが可能である。ロギング構成は、ロギング制御チェックボックスにより表示し制御することができる。ログ履歴サイズ、内部エラー及びアクションのロギング、及びその他の機能には、オプションメニューを介してアクセスすることができる。

図８Ｄに示す状態図は、動作時のサーバディスカバリプロトコルを示している。該サーバディスカバリプロトコルは、ネットワークセグメント上の多数のサーバの秩序正しい動作を可能とする。１つのネットワークセグメントは、１つ又は２つ以上のサーバと、ゼロ又は１つ以上のクライアント及び／又はサーバコンソールウィンドウを含む。プライマリサーバ及びゼロ又は１つ以上のセカンダリサーバは、メディアツリーを要求している複数のクライアントのために単一のエントリポイントを作成する。多数の異なる状態がプロトコルの一部として定義される。該プロトコルは、状態、該状態での動作、及び各状態に固有のパケットを定義する。定義される状態は、ディスカバリ820、オペレーショナル822,824、及びアービトレーション826である。例示的な実施形態では、プロトコルは、オペレーションコードZMP_ServerDiscoveryを使用し、及びサブコードZMP_Request、ZMP_Reply、ZMP_Status、ZMP_StatusRequest、ZMP_StatusREply、ZMP_Arbitrate、ZMP_Beaconを使用可能とする。

ディスカバリ状態820では、サーバは、ネットワークセグメント上の現在のプライマリサーバを探し出そうとする。サーバは、ZMP_ServerDiscovery/ZMP_Requestをブロードキャストすることによりネットワークセグメント上の現在のプライマリサーバを探し出す。ZMP_ServerDiscovery/ZMP_Reply応答が受信された場合、プライマリサーバのIPアドレスが将来の使用に備えて保持され、サーバは、オペレーショナルセカンダリ状態822に移行する。ディスカバリ状態820からアービトレーション状態826へ移行する前に、個々のZMP_ServerDiscovery/ZMP_Requestに対する応答を待機するための設定された時間（「SERVER_DISCOVERY_SERVER_TIMEOUT_MILLISECONDS」時間と呼ばれる）だけ間隔をおいて、プライマリサーバを探し出すための多数の試行（「SERVER_DISCOVERY_SERVER_LOCATE_MAX_TRYS」試行と呼ばれる）が行われた後に、プライマリサーバ応答が全く受信されなかった場合には、アービトレーション状態826に入る。現在のプライマリサーバは、サーバのリストをペイロードとして有するZMP_ServerDiscovery/ZMP_Replyパケットで応答することになる。また、サーバコンソールウィンドウが、プライマリサーバのロケーションの探索を可能とすべくZMP_ServerDiscovery/ZMP_Requestをブロードキャストして、全てのサーバのリストを受信することが可能である。サーバコンソールウィンドウは、バックオフ・リトライポリシーを使用することができる。

オペレーショナル状態では、プライマリサーバは、セカンダリサーバのリストを維持し、及び該リストをZMP_ServerDiscovery/ZMP_Beacon及びZMP_ServerDiscovery/ZMP_Replyパケットを介して提供する。ZMP_ServerDiscovery/ZMP_Requestに応じてユニキャスト応答パケットが送られる一方、プライマリサーバにより送られたZMP_ServerDiscovery/ZMP_Beaconパケット間の時間（「SERVER_DISCOVERY_BEACON_PERIOD_MILLISECONDS」時間間隔と呼ばれる）にブロードキャストビーコンが送られる。セカンダリサーバはまた、監視されている状態をプライマリサーバに知らせる。全てのサーバは、アービトレーションパケットに備えて待機する。サーバがアービトレーションパケットを受信した場合、該受信側のサーバがアービトレーション状態826へ移行する。オペレーショナルプライマリ状態822では、最近どのサーバがZMP_ServerDiscovery/ZMP_Statusパケットを送信したかを記録することにより、サーバのリストがプライマリサーバにより維持される。SERVER_DISCOVERY_SECONDARY_MISSING_MILLISECONDS中にパケットを発行しなかった特定のサーバはサーバリストから削除される。サーバリストは、SERVER_DISCOVERY_BEACON_PERIOD_MILLISECONDS毎に送信されるZMP_ServerDiscovery/ZMP_Beaconパケットを使用してプライマリサーバにより提供される。該ビーコンパケットはサーバのリストを含む。オペレーショナルセカンダリ状態824では、セカンダリサーバは、プライマリサーバのサーバリスト内に該セカンダリサーバを包含させるために該プライマリサーバ内にステータス情報を維持する。セカンダリサーバは、規則的かつ一方的なZMP_ServerDiscovery/ZMP_Statusパケットをプライマリサーバに送ることによりステータスを維持する。セカンダリサーバが、プライマリサーバからSERVER_DISCOVERY_PRIMARY_MISSING_MILLISECONDS内にZMP_ServerDiscovery/ZMP_Beaconパケットを受信しない場合には、該セカンダリサーバはアービトレーション状態826へ移行する。セカンダリサーバが、ZMP_Discovery/AMP_Arbitrateパケットを受信した場合には、該セカンダリサーバは、サーバの優先順位が、受信したアービトレーションパケットよりも低くなるまで、アービトレーション状態826へ移行する。

サーバコンソールウィンドウが、ユニキャストバージョンのZMP_ServerDiscovery/ZMP_Requestのブロードキャストを使用してプライマリサーバからサーバのリストを取得することも可能である。プライマリサーバが既知のものである場合には、典型的にはマルチキャストブロードキャストではなくユニキャストバージョンが使用される。プライマリサーバがユニキャストにより発見されない場合には、サーバコンソールウィンドウはフォールバックに入り、セーブされているプライマリサーバのIPアドレスが状態である場合に要求をブロードキャストする。

アービトレーション状態826はプライマリサーバの採決を行う。アービトレーション状態826になるのは、ネットワークセグメント上のセカンダリサーバによってプライマリサーバが検出されなかったとき、又は何れかのサーバがZMP_ServerDiscovery/ZMP_Arbitrateパケットを受信したときである。アービトレーション状態826では、全てのサーバは、該サーバがサーバリストの候補であり続ける場合に、ZMP_ServerDiscovery/ZMP_Arbitrateパケットのブロードキャストを開始する。受信したアービトレーションパケットが、オペレーショナルセカンダリ状態にある特定のセカンダリサーバがアービトレーションを失うことになることを示す場合、該サーバはオペレーショナルセカンダリ状態に維持される。現在のプライマリサーバを除く全てのサーバは、第１のアービトレーションパケットの応答を送る前に第１のアービトレーションパケットの検出による小さなランダム長の遅延を待ち、これによりネットワークの応答側によるコリジョンが制限される。「ラスト・ワン・スタンディング」アルゴリズムを使用してアービトレーションの勝者を決定する。サーバがZMP_ServerDiscovery/ZMP_Arbitrateパケットを受信する度に、該受信したサーバがプライマリサーバステータスの獲得競争を続行する。考え得るルール及び優先順位は、プライマリが勝つ、最短ツリーが勝つ、及び最低MACアドレスが勝つよう構成されたコマンドラインである。他のサーバが最高の優先順位を有していることを知らされていないサーバは、アービトレーションパケットの送信を続行し、それ以外の場合には、サーバはオペレーショナルセカンダリ状態822に移行する。サーバは、ZMP_ServerDiscovery/ZMP_Beaconパケットを受信した際にZMP_ServerDiscovery/ZMP_Statusパケットの送信を再開する。サーバがSERVER_DISCOVERY_PRIMARY_MISSING_MILLISECONDS内にプライマリサーバからパケットを受信しない場合には、セカンダリサーバがアービトレーション状態826へと移行する。勝者は、SERVER_DISCOVERY_ARBITRATE_PERIOD_MILLISECONDSだけ間隔をおいたSERVER_DISCOVERY_ARBITRATE_MAX_TRYSが競争のないZMP_ServerDiscovery/ZMP_Arbitrateパケットが該勝者により送信されたことを知ることにより成功を検出する。該勝者は、オペレーショナルプライマリ状態824に移行してZMP_ServerDiscovery/ZMP_Beaconパケットを送信することにより成功を公表する。

サーバディスカバリプロトコルは、ネットワークパケットの内容及び用法のコンテキストを定義する。ZMP_ServerDiscovery/ZMP_StatusRequest及びZMP_ServerDiscovery/ZMP_StatusReplyを含むパケットは、個々のサーバステータスを記述し、ZMPDiscoverServerStatusのペイロードを保持している。パケットの宛先は、ZMP_ServerDiscovery/ZMP_StatustoPrimaryServer及びZMP_ServerDiscovery/ZMP_StatusReplytoRequestorにより設定される。SERVER_DISCOVERY_STATUS_PRRIOD_MILLISECONDS毎に、各セカンダリサーバが、一方的なユニキャストZMP_ServerDiscovery/ZMP_Statusパケットをプライマリサーバへ送る。該パケットがプライマリサーバにより収集されてサーバ及びクライアントのリストへと編成される。各サーバ毎に、プライマリ又はセカンダリの何れも、ZMP_ServerDiscovery/ZMP_StatusRequestに対してZMP_ServerDiscovery/ZMP_StatusReplyで応答する。ペイロードは、サーバのIP、フラグ（現在ゼロ）、負荷ファクタ（100×負荷ファクタ／最大負荷ファクタ＝負荷百分率）、クライアント数、及びゼロ又は１つ以上のクライアントIPアドレスのリストを含む、ZMPDiscoverServerStatusオブジェクトを含む。
typedef struct ZMPDiscoveryServerStatus_s {
Unsigned int ServerIP;
unsigned short Flags;
unsigned short MaxLoadFactor;
unsigned short LoadFactor; unsigned
short Clients; Unsigned int ClientIP[]
} ZMPDiscoveryServerStatus;
サーバステータスの要求は、ZMP_ServerDiscovery/ZMP_StatusRequestパケットをプライマリサーバ又はセカンダリサーバである宛先へ発行することにより行われる。該パケットは、個々のサーバステータスを引き出すために発行される。プライマリ又はセカンダリサーバは、ZMP_ServerDiscovery/ZMP_StatusRequestに対してZMP_ServerDiscovery/ZMP_StatusReplyで応答することになる。

サーバディスカバリは、ブロードキャストMAC及びIP又はユニキャスト（プライマリサーバが既知である場合）等の宛先へ送られるZMP_ServerDiscovery/ZMP_Requestパケットを使用して要求される。新たなセカンダリサーバ又はサーバコンソールウィンドウは、オンラインになった際に、プライマリサーバを探索するための要求のブロードキャストを開始する。サーバコンソールウィンドウは、応答が受信されるまで、該要求を繰り返し送信する。セカンダリサーバは、応答の受信時に、又はアービトレーションを開始することにより、要求の送信を中止する。セカンダリサーバとして動作しているときに、ZMP_ServerDiscovery/ZMP_Requestを送ってSERVER_DISCOVERY_SERVER_TIMEOUT_MILLISECONDSを待つためのSERVER_DISCOVERY_SERVER_LOCATE_MAX_TRYS試行の後にプライマリサーバから応答が受信されない場合には、セカンダリサーバは、プライマリサーバが存在しないものとみなしてアービトレーション状態826に入る。ユニキャストを送信する場合には、最初の応答のない要求の後に、残りの要求がブロードキャストされる。

プライマリサーバは、サーバリストを指定するZMPDiscoveryServerBeachペイロードと共にZMP_ServerDiscovery/ZMP_Beaconパケットを使用して、ブロードキャストMAC又はIPとしてビーコンを送る。プライマリサーバは、各SERVER_DISCOVERY_BEACON_PERIOD_MILLISECONDS毎にブロードキャストビーコンを送って、セカンダリサーバのアービトレーションを阻止する。ZMP_ServerDiscovery/ZMP_Beaconペイロードは、サーバのIP、フラグワード（現在ゼロ）、及びセカンダリサーバの数及びゼロ又は１つ以上のセカンダリサーバIPを含む。該ペイロードは以下のフォーマットを有することができる。
typedef struct ZMPDiscoveryServerBeacon_s {
Unsigned int ServerIP;
unsigned short Flags;
unsigned short SecondaryServers;
Unsigned short SecondaryServerIP[];
} ZMPDiscoveryServerBeacon;
プライマリサーバビーコンからの応答は、ZMPDiscoveryServerAggregateStatusペイロードを有するZMP_ServerDiscovery/ZMP_Replyパケットという形のものである。宛先は、特定のMAC及びIPアドレスへの応答である。該応答は、ZMP_ServerDiscovery/ZMP_Request（ユニキャスト又はブロードキャストとすることができる要求）に応じて要求側に返されるユニキャストである。ZMPDiscoveryServerAggregateStatusペイロードは、サーバIP、16ビットフラグワード（現在ゼロ）、及びカウントであり、その後に１つ又は２つ以上のZMPDiscoveryServerStatus構造が続く。最初の構造がプライマリサーバのために使用される。ペイロードは次の形式を有することができる。
typedef struct ZMPDiscoveryServerAggregateStatus_s {
Unsigned int ServerIP;
unsigned short Flags;
unsigned short Servers;
ZMPDiscoveryServerStatus;Status[];
} ZMPDiscoveryServerAggregateStatus;
プライマリサーバとしてのステータスについてアービトレーションを行うために、競争者は、ZMP_ServerDiscovery/ZMP_Arbitrateパケットを、メディアツリー長及びコマンドライン構成を含むペイロードと共に、ブロードキャストMAC及びIPを介して宛先へ送る。アービトレーションに勝つには、競争者は、SERVER_DISCOVERY_ARBITRATE_COUNTの競争のないアービトレーションサイクルに勝つことになる。各サイクルは、ZMP_ServerDiscovery/ZMP_Arbitrateパケットのブロードキャストと、それに続く応答の監視及び評価を行うためのSERVER_DISCOVERY_ARBITRATE_PERIOD_MILLISECONDS収集期間とを含む。競争者のアービトレーション優先順位が応答の優先順位よりも低い場合には、該競争者はオペレーショナルセカンダリ状態822に移行する。アービトレーションに勝った後には、サーバは、オペレーショナルプライマリ状態824に移行して、ZMP_ServerDiscovery/ZMP_Beaconパケットの送信を開始し、アービトレーションに勝ったことを示す。ZMP_ServerDiscovery/ZMP_Arbitrateパケットの一例は次の通りである。
typedef struct ZMPDiscoveryServerArbitrate_s {
Unsigned int ServerIP;
unsigned short Flags;
unsigned short ArbitrationCount; Unsigned int
MediaTreeLength;
Unsigned int CommandLineConfiguration;
} ZMPDiscoveryServerArbitrate;
図８Ｅを参照すると、そのタイミングチャートは、メディアモニタ832、仮想ブロッカ834、及びクライアントソケット836間で対話を行うメディアサーバ830を示している。メディア添付は、ボリューム内の全てのファイルのリストを供給する。第１パスで、該ファイルリストが既存のTS-VIDEOディレクトリのコピーに制限される。全てのファイルは、該第１パス中に既に互いにコヒーレントになっている。メディアリストは、多数の構造を含み、各構造は、メディアディレクトリ中のファイルの名称及び長さ（バイト）を記述したものである。LBA要求(2)は、返されたデータブロック(3)の結果として生じるボリュームデータ要求を行う。LBA要求(4)は、IFOファイル要求を行い、これは、オープン(5)、メディア読み出し(6)、全ファイルのリターン(7)、及びクローズ(8)により実行される。LBA要求(13)は、VOBファイル要求を行い、これは、オープン(14)、メディア読み出し(15)、データブロックのリターン(16)、及びメディア接続のリターン(17)により実行される。VOBデータクローズは、メディア接続がもはや通信すべきデータを有さないときに発生する。データが暗号化される場合には、メディアリーダは、暗号キー要求(20)及びキーのリターン(21)を介してキーを提供する。

図９を参照すると、その概略的なシーケンス図は、サーバとメディアトランスコーダとの対話の一実施形態を示している。トランスコーダは、要求時に指定された機能を実行し、及び最小限の量のシステムリソースを使用して休止状態に入り、又はタスクの終了時に完全に破壊される、一時オブジェクトである。該トランスコーダへの全てのコールは、該トランスコーダが重要なコード領域のマルチスレッド保護の責務を負うように同時に実行することが可能である。トランスコーダは、あらゆる状態にあるときに削除時のリソースの解放を慎重に処理するよう削除することが可能である。

例示的な実施形態では、トランスコーダは、インタフェイスシステムによる単一の不変の整数エンティティによって参照される。該エンティティは、多数の作成済トランスコーダを互いに区別するためにインタフェイスルーチンに送られる一意のトークンである。

トランスコーダは、２つの異なる機能を有する。第１の機能は、タスクの調査及び結果的に得られるMPEGオブジェクトについてのパラメータの生成である。第２の機能は、所与のメディアオブジェクトのMPEGデータストリームへのトランスコーディングの実行である。タスクに関する全オブジェクトの入出力操作は、入出力システムを介して実行される。

生成時に、トランスコーダは、任意のメディアオブジェクトを混合したものとすることが可能なユーザ識別子（UID）のリストを受信する。該トランスコーダはまた、要求されたターゲットフォーマット（例えばMPEGフォーマット）を指定する列挙された値を受信する。トランスコーダライブラリは、メディアオブジェクト（例えば、単一のフレーム、オーディオ、単一のフレームと組み合わされたオーディオ、及びビデオオブジェクトを含む）を認識してトランスコードすることが可能である。単一のフレームは、ターゲットフォーマット（例えばMPEGスライドショー）へと変換されることになるあらゆる一連の静的なグラフィックオブジェクトである。トランスコーダは、所与のオブジェクトの最適な表示のために、ビットマップサイズ、ピクセルサイズ、及びカラー深度の変換を実行する。オーディオデータは、メディア経験全体を通して提供されるデフォルトのビデオスライドを有するMPEGオーディオファイルへと変換されることになるあらゆる一連のオーディオオブジェクトである。あらゆるオブジェクトの境界にチャプターストップが設定される。オーディオ及び単一フレームデータは、一連の単一フレームオブジェクトが後続するオーディオオブジェクトとして、トランスコーダに提示される。トランスコーダは、オーディオオブジェクトの再生時間にわたり単一フレームオブジェクトが一様に遷移するMPEGストリームを生成する。チャプターストップは、該オーディオオブジェクトの遷移ポイントに設定される。トランスコーダは、提供されたビデオオブジェクトに最もよく適合するターゲットストリーム（MPEGストリーム等）を生成する。小さすぎて最小MPEG分解能へと変換できないビデオフレームの場合には、トランスコードされたデータは、ストリーム中に黒い境界を有する若干ズームされたものを含むものとなる可能性がある。特定のメディアソースオブジェクト及びフォーマットが、配信可能なタイムテーブル内で繰り返される。該タイムテーブルはまた、MPEGフォーマットの配信時刻を指示する。

生成時に、トランスコーダは、インタフェイスにより供給された入出力ルーチンを使用してファイルリストを調査する。トランスコーダは、メディア配信システムを構築するためにシステムが使用するIFOファイル構造を生成する。結果的に得られるメディアデータストリームのIFOファイル記述子は、ストリーム全体の最後に含まれる追加サイズを有する結果的に得られる実際のストリームよりも僅かに大きいものであることが可能である。結果的に得られるストリームが複数の１GB VOBセグメントを生成する場合であっても、全てのIFOにより指定された過度の空間は、該ストリームの論理的な最後に付加される。IFOの殆どは常用文（boilerplate）及びストリーム記述子といった必須でないコンテンツを含むが、プレイリストはシステムの正しい機能を可能にする。トランスコーダのIFO構造のデータは、論理アドレス0で始まる第１のトランスコード済VOBオブジェクトを含み、その後続の各VOBは、同一の連続する論理アドレス空間に収容される。トランスコーダは、場合によってはメディアストリームのサイズを推定し、該推定値は常に実際のサイズよりも大きくて全体的な実際のサイズの10％以内となる。

代替的な実施形態では、トランスコーダの調査で提供されるIFOファイル構造は、VTSI_MAT、PTT_PRTI、VTS_PGCITI、VTSM_PGCI_UT、VTS_TMAPTI、VTSM_C_ADT、VTSM_VOBU_ADMAP、VTS_C_ADT、及び VTS_VOBU_ADMAP を含む。VTSI_MATは、メインIFOテーブルであり、各IFOファイル内に必ず含まれる。VTSI_MATテーブルは、VOBファイル内に収容されるビデオ及びオーディオストリームを指定する。該ビデオストリームは、MPEG1又はMPEG2といった圧縮されたビデオ、NTSC（National Television System Committee）又はPAL（Phase Alternation Line）といったテレビ用ビデオとして指定することができる。VTSI_MATテーブル中の他の値は、アスペクト比、表示モード（レターボックス等）、ビットレート（可変（VBR）又は固定）、及び解像度を指定する。

PTT_PRTIは、コンテンツがムービーを含む場合に必須のチャプターテーブルである。チャプターテーブルは、これを含む場合には、少なくとも１つのチャプターを指定し、及びチャプター番号1を含む。PTT_PRTIにより指定されたチャプターは、テーブル中のPGC内のプログラムにリンクしている。

VTS_PGCITIは、メディアの再生を操作するメインプログラムチェーンである。プログラムグループコントロール（PGC）は少なくとも１つのプログラムを有し、該プログラムはPGC内の最初のセルにリンクしている。したがって、少なくとも１つのセルが、PGC内に含まれて、該セルのVOBファイル内の開始セクタ、再生時間、及び該セルの終了セクタを保持する。

VTSM_PGCI_UT、VTS_TMAPTI、VTSM_C_ADT、及びVTSM_VOBU_ADMAPを含むビデオタイトル設定ファイル構造は、必須ではない構造である。VTS_C_ADTは、VOBファイル内の全てのセルのリストを保持する。セル値は、VOBファイル内の開始及び終了セクタアドレスを含む。VTS_VOBU_ADMAPは、VOBファイル内の全てのVOBユニットのリストを保持するテーブルであり、VOBファイル内の各VOBユニットの開始セクタを含む。

調査機能が完了すると、トランスコーダは、インタフェイスがGET関数を実行して該トランスコーダからのメディアストリーム（例えばMPEGストリーム）を描画するまで休眠状態に入る。メディアストリームのフェッチは、VOBオブジェクトの初期のゼロアドレスに基づくアドレスにおけるランダムアクセスである。各フェッチは、2048個のデータブロックのメディアストリームへとオフセットされる開始論理ブロックアドレス（LBA）をそれぞれ有している。

トランスコーダによりGET要求が行われると、該トランスコーダは、ユーザ装置により提供される入出力インタフェイス又は（例えば、ワシントン州レドモンドのMicrosoft Corporationによる）メディアグラフ機能を使用して適当なメディアデータをフェッチする。その入出力ルーチンは、非同期であり、入力力処理が完了しない限り、又はエラー条件が発生しない限り、リターンしない。次いでトランスコーダは、受信した部分を該トランスコーダにより管理される入出力バッファ内にトランスコードする。単一のGETコールによりトランスコードされる2048バイトブロックの数は、トランスコーダにより決定され、及び構築されたメディアグラフと該グラフが動作する領域との影響を受ける。該領域は、時間及びトランスコードされるバイト数に関して決定することが可能である。ストリームは、所定の最大値以内の個数の2048バイトブロックに制限される。例示的な実施形態では、キャパシティは512kbyteに設定される。GETルーチンは、バッファ内に返される2048バイトブロックの個数をトランスコーダが設定することを可能にする。

該バッファは、ストリーム配信のためにユーザ装置に対して不変のものとして通過される。その後、ユーザ装置は、トランスコーダに対して別個のコールを実行し、該バッファを解放して該トランスコーダのバッファプール内に戻す。ユーザ装置は、トランスコーダ上の多数のスレッドからの多数のGETを登録することが可能である。該多数のGETは、直列化されていない可能性がある。これは、論理ブロックアドレスが配信順に要求されない可能性があるからである。サスペンドは、入出力処理中にのみ発生することが可能である。

ユーザ装置は、トランスコーディング機能を本質的に状態のないプロセスとして見る。メディアストリームの特定の一部が要求され、その部分が返される。次の要求は必ずしも他の要求に関するものである必要はない。したがって、トランスコーダは、ストリーム要求を待ち受けて単純にアイドル状態に留まる。何らかの１つの要求又は一組の要求の間にトランスコーダが削除される場合には、該トランスコーダは、エラー指示により全てのアクティブなGETを取り出し、未解決の入出力を待ち、次いでリソースを編成する。

図９のシーケンス図は、サーバ−トランスコーダ反復を示している。対話901で始まって、推定処理がドキュメント化され、該ドキュメント化では、トランスコーダは、半分がTCDR_info構造である情報を供給するよう構築され、これにより、それ以降の同じメディアファイルを用いたトランスコーダのインスタンス化が急速に行われるようになる。対話906〜908は、多数回繰り返すことが可能である。多数のファイルをオープンし、及びトランスコーダの存続期間にわたりオープンのままにすることが可能である。一実施形態では、Microsoft transcoder graphsを使用して、ローカルファイルに直接アクセスすることが可能である。例示的な一実施形態は、一組のEndOfMediaVOBオプションを使用した一組のトランスコーダ対話を例証するものである。該オプションは、最初のGETがコールされる前に設定される。対話912〜914は、メディアが用い尽くされるまで繰り返される。メディアの終わりで、バッファは返されず、エンド・オブ・メディア・リターンが行われる。次いでユーザスレッドを続行して、EndOfMediaVOBを（おそらくは多数のTCDR_GETを使用して）フェッチすることが可能である。バッファは各インスタンスで解放されるが、トランスコーダはSetOptionコールでソースバッファからVOB情報をコピーする必要はない。これは、データが不変であることが保証されるからである。各EndOfMediaVOB毎に、空のバッファでEndOfMediaリターンが行われる。該シーケンスは、CloseDVDFilterコールが行われるまで続行することが可能である。

図１０を参照すると、そのシーケンス図は、メディアツリー修正をサポートするSOAP（Simple Object Access Protocol）メディア定義サーバの対話を示している。クライアントタイムアウト(3)は、クライアントがタイマをリセットしない場合に供給される。任意数のメッセージ、例えば、要素追加(4)、要素削除(6)、要素移動(8)、及び置換(10)として示すメッセージが、任意の順に発生することが可能であり、及び任意の数の（SOAP）エンベロープにグループ化することが可能である。タイマリセット(12)は、指定された間隔でタイマをリセットすべきであるため、又はツリー修正を終了させるために、挿入される。ツリー表明(16)は、ツリー修正中の他の要求を拒絶する。タイマメッセージは、表明及び偽リターンの受信後には使用されない。

図１１を参照すると、そのユースケース図は、エミュレータインタフェイスを使用するオーディオ−ビジュアルシステムの機能を示している。該オーディオ−ビジュアルシステム1100は、プロセッサ上で実行することができるサーバ1110と、エミュレータをサポートするメディアプレーヤ1112とを含む。該サーバ1110は、エミュレータをサポートするメディアプレーヤ1112に対するアクセス及びコンテンツのストリーミングを管理する。エミュレータをサポートするメディアプレーヤ1112は、サーバ1110からコンテンツを受信して、該コンテンツの実行又は提示を行う。特定の実施形態では、オーディオ−ビジュアルシステム1100は、エミュレータをサポートするDVDプレーヤ上の１つ又は２つ以上のソースからのビデオコンテンツを再生するビデオシステムとすることができる。

サーバ1110は、メディアサーバ1120、メディアレンダラ1122、メディアコントローラ1124、メディアディレクトリ1126、及びエミュレータサーバ1128を含む複数の機能ブロックを有する。該メディアサーバ1120、該メディアレンダラ1122、及び該メディアコントローラ1124は、それぞれ、仕様上の要素であるサーバ要素1129、レンダラ要素1130、及びコントロール要素1132を含む。該仕様上の要素は、標準的な通信プロトコルに準拠するものである。

メディアコントローラ1124及びメディアレンダラ1122は、それぞれ特殊なコントロール処理及びレンダリング処理を含む。例えば、メディアコントローラ1124は、エミュレートされた対話を選択し、利用可能とし、開始し、及び管理するためのコントロール機能を含む。メディアレンダラ1122は、エミュレータネットワーク通信サーバ1128の代理となる特殊なレンダラを含む。メディアコントローラ1124は、メディアサーバ1120及びメディアレンダラ1122と通信して、コンテンツを供給するソースを初期化し、コンテンツの転送パラメータを設定し、及びコンテンツの配信を開始する。メディア構造要求がメディアコントローラ1124へ送られ、該メディアコントローラ1124が、メディアサーバ1120にメディアレンダラ1122（エミュレータのメディアストリームをアクティブにするメディアレンダラ1122内の機能要素を含む）へメディアファイルを送信させる制御信号を送る。

メディアコントローラ1124（コントロールポイントと呼ぶことも可能）は、メディアディレクトリ1126を調べ、メディアメニュー1140（例えばDVDメニュー）を指定し、コンテンツの転送と同時にメディアディレクトリ1126内にメニューを作成する。メディアディレクトリ1126は、メディアコンテンツの一部又は全部、並びにメニューを生成し表示するために利用することができるコンテンツのリストを含む。メディアプロバイダ1002は、メディアディレクトリ1126に対してメディアを利用可能とする。

メディアサーバ1120は、メディアコントローラ1124から制御信号を受信し、これに応じてメディアコンテンツ1142をレンダリングのために供給する。メディアレンダラ1122は、制御信号を受信し、エミュレートされた規格1144にメディアを適応させる。メディアレンダラ1122は、エミュレータをサポートするメディアプレーヤ1112によりメニューを提示するためにメディアプレーヤメニュー1146をレンダリングすることができる。メディアレンダラ1122は、コンテンツを受信しレンダリングし、該レンダリングしたコンテンツ1148をエミュレータサーバ1128へ供給する。

該エミュレータサーバ1128は、メディアレンダラ1122とエミュレータをサポートするメディアプレーヤ1112との間のインタフェイスとして機能する。エミュレータサーバ1128は、メディアレンダラ1122からエミュレータをサポートするメディアプレーヤ1112へとメディアコンテンツを導き、エミュレータをサポートするメディアプレーヤ1112から制御情報を受信して、利用可能なコンテンツ1052の発見を可能とする。

例示的な一実施形態では、エミュレータをサポートするメディアプレーヤ1112は、エミュレータ1114、メディアドライブ1116、及びコンテンツシンク装置1118を含む。特定の一例では、メディアドライブ1116をDVDドライブとすることができ、コンテンツシンク装置1118をMPEGデコーダとすることができる。エミュレータ1114により実行される機能は、メディアドライブ1116の機能を正確に反映し又はエミュレートするものである。標準的な動作では、メディアドライブ1116は、メディアストリーム1054をコンテンツシンク装置1118に供給し、及びメディア記述子1056を要求する。エミュレータ1114は、メディアドライブ1116の機能をエミュレートし、エミュレートされたメディアストリーム1058を供給し、及びメディア記述子1059を要求する。

エミュレータ1114は、自動的なIP（Internet Protocol）アドレシングを使用して、再使用可能なネットワークアドレス及び構成オプションを割り当てることができる。

本システムは、ネットワーク通信業界で周知のBOOTP（Bootstrap Protocol）に基づいてTCP/IPネットワーク上のホストに構成情報を送るためのフレームワークを提供するDHCP（Dynamic Host Configuration Protocol）サーバ1160を含むことが可能である。該DHCPサーバ1160は、再使用可能なネットワークアドレス及び追加の構成オプション1162を自動的に割り当てる能力を追加するものとなる。DHCPは、BOOTPリレーエージェントの挙動を捕捉して、DHCPに参加するものがBOOTPに参加するものと協働することを可能とする。

メディア構造要求がコントロールポイント1124へ送られる。メディアサーバ1120はメディアファイルをレンダラ1122へ送信する。コントロールポイント1124は、メディアディレクトリ1126を調べることによりメニューをリアルタイムで作成する。

図１２Ａ及び図１２Ｂを参照すると、そのフローチャート及びシーケンス図はそれぞれブートROM（Read-Only Memory）の動作を示している。該ブートROMは、電源オン／リセット時にクライアントの制御を獲得し、ダウンロードされたソフトウェアイメージに制御が渡されるまで実行される。ブートROMは、Ethernetメディアアクセスコントロール（MAC）及びIPアドレスを構成し、クライアントソフトウェアイメージのダウンロードを可能にすべくローカル又はリモートコードサーバへの接触を試みる。ブートROMはまた、I2C（Intelligent Interface Controller）インタフェイスを介してダウンロードされたクライアントを受信することが可能である。

MAC初期化後、ネットワークがアクティブであるとき、ブートROMは、ネットワークケーブルを監視し、該ケーブルが切断され又は再接続される際にネットワークプロトコルをリスタートする。

全てのアプリケーション固有パケットは、以下に示すように定義されるZMP(Zenith MUD Protocol)ヘッダ(ZMPHeader)で始まる。
typedef struct ZMPHeader_s {
Unsigned char Op;
Unsigned char Sub;
Unsigned char ProtocolMajorVer;
Unsigned char ProtocolMinorVer;
Unsigned char Configuration; //サーバOS用のクライアントスイッチ値に関する
Unsigned char pad;
Unsigned char Retries; //機構の実行を試行
Unsigned char Times; //ROMに関するリセット後のセンチ秒(100分の1秒)
} ZMPHeader;
第１の要素「Op」は、パケットの主分類を指定するものであり、これにより、受信時にパケットを適当なハンドラへと効率的に操作することが可能となる。
enum ZMP_OP_Codes {
ZMP_AutoMac =1, // ZMP_Request, ZMP_Reply
ZMP_LocalBoot =2, // 構成要求:ZMP_Request,構成提供:
ZMP_InetDiscovery =3, // インターネット上のコードディレクトリ要求
ZMP_ServerDiscovery =4,
ZMP_Media =5,
ZMP_CodeRequest =6, // sub=ZMP_Download（ローカルダウンロードに関する）
ZMP_MAESTROBEACON =0xA0, // MBOOTPサーバによってのみ送信
ZMP_MAESTROREQUEST =0xA1, // クライアントROMによってのみ送信
ZMP_MAESTROREPLY =0Xa2, // MBOOTPサーバによってのみ送信
};
Typedef ZMP_OP_Codes ZMPOPCodes;
第２の要素「Sub」は、パケットのOp分類内の特定のアクションを指定する。
enum ZMP_Sub_Codes {
ZMP_Request =1,
ZMP_Reply =2,
ZMP_MediaPort =3,
ZMP_Download =4,
ZMP_DISCOVER =5, // クライアント→サーバ
ZMP_OFFER =6, // サーバ→クライアント
ZMP_REQUEST =7, // クライアント→サーバ
ZMP_DECLINE =8, // クライアント→サーバ
ZMP_ACK =9, // サーバ→クライアント
ZMP_NACK =10, // サーバ→クライアント
ZMP_RELEASE =11, // クライアント→サーバ
ZMP_Beacon =12,
ZMP_CodeServerList =13
};
Typedef ZMP_Sub_Codes ZMPSubCodes;
ブートROMは、ZMPmbootp要求のブロードキャストを介してローカルブートサーバ要求を行うことによりローカルサーバの探索を試行する。要求はAutoMACと並行して開始される。これはサーバがクライアントのためにMACアドレスを供給することができるからである。要求は、競合するクライアントによるネットワークの混雑を回避するために、多数の要求について次第に増大する時間間隔だけ間隔をおくことが可能である。要求は、ローカルサーバが応答するまで、又はクライアントソフトウェアイメージが他のソースからダウンロードされるまで、続行される。MAC又はIPのためのブートROMの現在の値は、要求パケットにより指定される。サーバは、クライアントIP、MAC、及びゲート情報に応答することが可能である。何れかのフィールドでサーバにより返される非ゼロ値は、クライアントブートROMにより採用することができる。要求パケットのフォーマットの一実施形態は次の通りである。
typedef struct ZMPmbootp_s { //ローカルサーバからクライアントを構成
//ZMP_LocalBoot:ZMP_Request/ZMP_Reply
ZMPHeader Header;
Unsigned int Xid; //クライアントによりセットされたトランザクション
Unsigned int UniqueIdentifier; //更なる自己識別のためクライアントにより設定
Unsigned int IP; //クライアントIPアドレス
Unsigned int IPMask; //ローカルネットワーク用マスク
Unsigned int IPGate; //インターネットへのゲート
unsigned short Flags; //使用せず
unsigned char Hw_addr[HW_ADDR_LEN]; //クライアントのHW（MAC）アドレス
}ZMPmbootp;
自動MACプロトコルは、クライアントが、選択されたアドレス範囲からMACアドレスを自発的に選択することを可能にする。自動MAC要求パケットの一例は次の通りである。
typedef struct ZMPSqueal_s { //MACアドレスの自己構成
//ZMP_AutoMAC:ZMP_Request/ZMP_Reply
ZMPHeader Header;
unsigned int Xid; //クライアントによりセットされたトランザクション
unsigned int UniqueIdentifier; //更なる自己識別のためクライアントにより設定
unsigned char Flags; //ビット0:1（最後の要請について）
unsigned char pad;
unsigned char Hw_addr[HW_ADDR_LEN]; //候補のアドレス
}ZMPSqueal;
１回の動作は、範囲内のMACアドレスのランダムな選択を伴い、次いで複数のZMPSqueal要求を送信して、応答をリッスンする。応答が、所与のMACアドレスが既に使用されていることを示す場合には、新たなランダムなMACアドレスがテストされることになる。ZMPSqueal要求は、選択された遅延を該要求間に伴って多数回送信される。応答が受信されない場合には候補MACアドレスが採用される。該シーケンスが完了する前に応答が受信された場合には、候補MACが破棄されて新たなランダムなMACアドレスが選択され、該シーケンスがリスタートされる。サーバがクライアントMACアドレスを提供した時点で、自動MAC動作は終了する。

サーバ及び／又はDHCPサーバが検出されない場合には、自動プライベートIPアドレシングプロトコル（APIPA）がクライアントIPアドレスを提供し、これによりクライアントが同様に構成されたホストに接続することが可能となる。

ZMPCodeRequestパケットは、クライアントソフトウェアイメージのダウンロードを開始するためにサーバに送られる。該要求パケットのコアは、所望のクライアントソフトウェアイメージのファイル名を含むTFTP要求ヘッダである。後続するデータ転送及び応答パケットは、TFTPプロトコル仕様に従うものである。ダウンロードされたイメージはDSA署名されたものとすることが可能である。該署名の有効性が確認され、無効である場合には、ブートROMは処理をリスタートする。TFTP読み出し要求の一例は次の通りである。
//TFTP読み出し要求
struct tftp_rrq {
unsigned short cmd; //TFTP_RRQ
//ASCIIZファイル名＋ASCIIZ「バイナリ」ファイルタイプ
unsigned char
filename_mode[TFTP_MAX_FILENAME_LEN+1+TFTP_MAX_MODE_LEN+1];
};

typedef struct ZMPCodeRequest_s {
ZMPHeader Header;
int Blocksize;
struct tftp_rrq InitialRequest;
}ZMPCodeRequest;
ブートROMは、指定された態様でエンコードされた名称を有するフィールドを要求する。ブートROMは、MAC及びIP構成の後、指定された時間内にローカルダウンロードが完了しない場合に、１つ又は２つ以上のIPアドレスでリモートディレクトリサーバに接触する。opcode:ZMP_InetDiscovery、subcode:ZMP_Requestを用いた要求が、定義されたIPアドレスの各々に送られ、応答が受信された場合には、その応答パケットは、クライアントソフトウェアイメージのダウンロードを可能とするために接触することができる１つ又は２つ以上のコード−サーバIP／ポートアドレスを含むことになる。要求の一例は次の通りである。
typedef struct CodeServerDescription_s {
unsigned int Ip; //コードサーバへのIP
unsigned short port; //サーバに接触するためのポート
unsigned short flags; //使用せず
} CodeServerDescription;
全ての定義されたコードアドレスは、多数回の試行及び指定されたタイムアウト期間により重複する要求を用いて問い合わせが行われる。要求は、ゲートウェイ活動を抑制するよう時間的に互いに隔置される。要求は、ZMPヘッダのみを含むが、応答は、次のように定義されるZMPCodeServerペイロードを含む。
//Request opcode:ZMP_InetDiscovery subcode:ZMF_Request
//Replyopcode:ZMP_INetDiscovery subcode:ZMP_Reply

typedef struct ZMPCodeServer_s {
//Request opcode:ZMP_InetDiscovery subcode:ZMP_Request
//Reply opcode:ZMP_InetDiscovery subcode:ZMP_Reply
ZMPHeader Header;
//応答パケットの終わりまで以下の構造を繰り返す
CodeServerDescription Servers;
} ZMPCodeServer;
応答で返されたサーバは、待ち行列に入れられ、クライアントソフトウェアイメージのダウンロードを要求するために接触される。リモート活動は、DHCP又はリモートサーバ構成を介してゲートウェイが指定された場合にのみ試行される。

図１３Ａを参照すると、その概略的な状態図は、図１に示したドライブコントローラ162のようなドライブコントローラ1300の一実施形態を示している。ドライブコントローラ1300の状態図における各状態には、メディアトレイ出力アイドル状態1302、メディアなしアイドル状態1304、及びメディアありアイドル状態1306が含まれる。初期化時に、ブートROMは、インタフェイス1308（例えばIDE（Integrated Drive Electronics）インタフェイス）をセットアップする。各状態において、ドライブコントローラはセンスコマンド1310に応答する。

図１３Ｂを参照すると、そのフローチャートは、ドライブインタフェイス処理の一例を示している。

例示的な一実施形態では、クライアントは、TCP（Transmission Control Protocol）インタフェイス等のサーバインタフェイスを有することができる。TCPインタフェイスは、コマンドパケットを送信するクライアントとメディア状態を指定する該コマンドパケットに応答するサーバとを用いる単純なソケットである。サーバは、要求された個数のデータブロックを送信することにより応答する。要求ブロックの一例は次の通りである。
struct tNetCRB {
unsigned int size; //送信すべきパケット＋データの総サイズ
unsigned char device, //宛先装置 COMSID
command; //サーバに発行すべきコマンド
union {
unsigned char cdb[12]; //CDB（必要な場合）
unsigned char sticky; //スティッキービット（データを維持すべき場合）
};
unsigned int lba; //読み出すべき論理ブロックアドレス
unsigned int count; //読み出すべきセクタの個数
unsigned short blocksize; //読み出すべきセクタのサイズ
unsigned int fileSize; //送信されるファイルのサイズ
unsigned int bufferSize; //後続するデータ（又は受信バッファ）のサイズ
unsigned int encryptionID;
unsigned int stickyBlocks[MAX_StickyBlocks][2]; // 常にキャッシュされるフ゛ロック
unsigned short iStack; //スタックポインタ
unsigned short mediaStack[MAX_MediaStack]; //メディアスタック
};
メディアスタックは、クライアントによって調べられることはなく、サーバのみにより作用される状態情報である。

図１３Ｃを参照すると、その概略的なフローチャートは、UDPプロトコル通信を実施してTCPオーバーヘッドを伴わない急速なパケット送信を可能にするためにクライアントにより実行される処理の一実施形態を示している。TCPソケットでコマンドチャネルが実施され、UDPソケットでデータが送信される。サーバは、各UDP送信にバッファ位置ポインタをタグ付けする。該ポインタは、バッファ内にデータを配置して全てのパケットが到着したことを確認するために使用される。サーバ及びクライアントの両者は、パケットを損失した場合にリトライするために結合されるアクティブタイムアウトを有する。応答間のパケット数及びパケットサイズは変更することが可能である。

図１４Ａを参照すると、その概略的なブロック図は、本システムにより使用することができるメディア構成1400の一実施形態を示している。仮想メディアボリューム1402は、「仮想」フォーマットをユーザ装置に提示し、これによりユーザにとって馴染みのあるユーザフレンドリな態様でメディアのナビゲーション及び再生を行うことが可能となる。スタックフレームは、メディア空間位置を保存するためにクライアントによりVTS（Video Title Set）スタック1404内に保持される。ナビゲーション情報は、ユーザにとって馴染みのある態様でユーザ装置内の履歴機構を操作することを可能にする。メディア記述子1406は、VTSタスクでスタックフレームをメディアツリーに関連付けし、該関連付けは、本システムが再生履歴を監査してストレージリソース及びプロセッサの要件を動的に調整することを可能にする構造で行われる。頻繁に参照されるデータは、ユーザ装置固有のフォーマットへと最初に変換された後に自動的にキャッシュされる。

図１４Ｂ及び図４は、ルートメディアディレクトリ1420及びメディアツリー400というメディアの２つの図をそれぞれ示している。該２つの図は、メディア配信システム内のメディア編成を表しており、多数のリソース間でメディアを配信することができる態様をユーザ装置に対して示している。本システムは、メディアを自己編成し、メディア各部の互いに対する位置によってナビゲーション情報を導出することにより、ユーザインタフェイスを動的に及びユーザに対してトランスペアレントに構成する。多数のメディア部分を収容するメディアディレクトリ1422がメニューになり、メディア部分がユーザ装置上でのユーザインタフェイスの選択のためのソースになる。図１４Ｃは、図１４Ｂ及び図４と同じメディア部分を表すリンクされたメニューを示しており、該リンクされたメニューは、多数のネットワークにわたるメディア部分の分散を強調したものである。導出されたナビゲーション情報、特にメニューは、リンク情報を保持している。

プレーヤが単一のタイトルセットを繰り返し再生する一方、本システムは、該単一のタイトルセット（ルートビデオタイトルセット（VTS）1408と呼ばれる）における分散ファイルシステムからのメディアを置換することができる。VTSスタック1404は、図４に示すメディアツリー400内におけるユーザの位置を保存し、VTSファイルテーブル1410は、その位置をメディアナビゲーションツリー400内の特定の位置にマッピングする。不タックフレームは、メディア空間位置を保存するためにクライアントにより保持される。ナビゲーション情報は、ユーザ装置内で動作する履歴機能が、ユーザ装置にとって典型的であってユーザに一般に知られている態様で動作することを可能にする。メディア記述子は、スタックフレームをメディアツリー400に関連付けし、該関連付けは、本システムが再生履歴を監査してストレージリソース及びプロセッサの要件を動的に調整することを可能にする構造で行われる。頻繁に参照されるデータは、ユーザ装置に固有のフォーマットへと最初に変換された後に自動的にキャッシュすることが可能である。

図１４Ｃに示すリンクされたメニュー図は、トランスコーダ及びクライアントが一貫したルックアンドフィールで一連のメニューをユーザに提示することを可能にするリンクメニュー変換（ＬＭＣ）を示している。ナビゲーション制御及び情報は、ファイル構成から導出され、これにより動的でユーザに対してトランスペアレントなユーザインタフェイスの構成、及び選択されるコンテンツ及びソースに対する動的なアクセスが可能となる。ディレクトリがメニューになり、メディアが該メニュー内のボタンになる。１ディレクトリに収容されているメディアアイテムの数が多すぎる場合には、一連のメニューの連鎖が生成され、これがユーザにとって馴染みのある連続するメニューとしてユーザに提示される。例えば、ユーザ装置がDVDプレーヤである場合には、ディレクトリは、DVDユーザインタフェイスの慣習に従った連続する複数のDVDメニューという形で提示される。該慣習は、メディアツリー400のXML（eXtended Markup Language）記述でクライアントへ伝達されるボタン構造の順序に基づくものである。該メディアツリー400をメディアプレーヤの状態機械（例えばDVD状態機械）のGPRMの使用と組み合わせて、内蔵された自立型のメディアメニューページが一貫し且つ直観的なヒューマンインタフェイスで互いにリンクされたものとして現れるようにすることが可能である。１つのメニューセットは、全てが互いに相互参照すると共にユーザがリモートコントロール上の矢印キーを押下した際に互いに自動的に遷移する１グループのメニューである。

アクションは、メニューページを記述するXMLにおける規定及び属性、並びにメディアシステム内のメニュートランスコーダへ要素が提示される態様に基づくものである。該規定の基本的な特徴は、メディアボタン仕様のネイティブコンポーネントである自動アクションボタンの実施である。自動アクションボタンは、例えばDVDボタンとすることが可能なものであり、メディア状態機械のアクションを生じさせるためにユーザがボタンを選択することを必要としないものである。単にカーソルをボタンへと移動し又はボタンを「ハイライト表示」させるユーザのアクションだけで（ユーザがリモートコントロール上でボタンをハイライト表示させた後に選択又は再生ボタンを押下した場合のように）プレーヤがアクションを行うことになる。

リンクされたメニューの規定は、ボタン要素内の２つの追加の属性と、メニュー要素のための１つの追加の属性とを使用する。ボタン要素内の追加の属性は、「自動ボタン」、すなわち、ボタンが自動アクションボタンであることを示す単純な真偽ブール属性と、「宛先ID」、すなわち、通常のメニュー階層外への遷移を可能にする宛先遷移メニューとを含む。宛先ID属性は、宛先メニュー（自動アクションのターゲットであるメディア、例えば、ビデオ、音楽、スライドショー要素等）の基準識別子IDREFを保持する。IDREFは、あらゆるXML要素の識別子属性における一意の識別子である。メニュー要素属性は、TCDRリンクメニューであり、該メニュー要素属性リストに含まれる単純なブールがリストアップされ、メニュー要素に存在しない場合には偽であると推論される。

リンクメニュー規定の実施のためのXMLメニュー記述の例示的な一実施形態では、メニューXML要素におけるボタンの提示順は意味を有している。例えば、一実施形態では、メニュー内で最初に表示されるボタンは、ハイライト表示された際に直ちに宛先ID要素へのジャンプを実行するアップボタンと呼ばれる自動アクションボタンである。第２のボタンは、メニューページのＺ順の第１メディアボタンである。メニューセット内の他のリンクメニュー規定（LMC）メニューのダウン自動ボタンからジャンプが実行される際には必ず、第２のボタンは、ハイライト表示される新たなメニューページ上のボタンである。１つのメニューセットに属するメニュー内の最後のボタンは、ハイライト表示された際にメニューセット内の次のメニューへのジャンプを直ちに実行するダウンボタンと呼ばれる自動アクションボタンである。LMCメニューのナビゲーションＺ順における最後のボタンは、LMCダウンボタンを指し示すbtnDown属性を有している。この最後のメディアボタンとメニュー上で定められる最終的なボタンとの間には他の非自動アクションボタンを配置することはできず、これによりメニュートランスコーダがLMCメニューナビゲーションのためのボタンを容易に選択することが可能となる。

メニューの最後のボタンは、全てのLMCメニューのIFOに組み込まれているプログラムを介して実行されるリダイレクションで以前のLMCのアップボタンアクションを介してLMCメニューに入った際にハイライト表示される。例えば、DVDプレーヤは、GPRMと呼ばれる一組の汎用レジスタと、SPRMと呼ばれる一組の専用レジスタとを一般に有している。LMCは、GPRM1を使用して最後のメディア選択ボタンを記憶する。SPRM8は、ハイライト表示するメニューボタンを選択するために使用される。LMCメニューのIFO内のDVDプログラムは、SPRM8をチェックして、以前のメニューのアップボタン（例えばＺ順のボタン1）がメニューを選択したか判定する。そうである場合には、IFOプログラムは、GPRM1をSPRM8にコピーして、新たに選択されたLMCメニューの最後のメディアボタンをハイライト表示させる。DVD IFOプログラムは、次いで、IFOプログラムに関連する最後のメディアボタンをGPRM1内にインストールして、LMCにおける次の遷移に備える。

ボタンは、メディアがシステムに追加された時点で生成されるVTSタイトルセット内に収容される。メディアツリーが変化する際にトランスコーディング処理を使用してメニューがリアルタイムで開発されるため、変更されたメディア状態に遭遇した時点でメディアの変更、削除、又は追加による影響を受けるメニューを修正すべく、トランスコーダもまた生成される。

図１４Ｃに示すように、ボタン1,5,6,7は自動アクションフラグセットを有しており、太線で示すボタン2,3,4は自動アクションではない。ボタン2は、常に第１メディアボタンである。ボタン4は、メニューに入る際にGPRM1内にセットされる。

図１４Ｄを参照すると、そのフローチャートは、トランスコーダ上でTCDRリンクメニューオプションがコールされた場合に情報フォーマット（IFO）のためのプログラムコードに追加されるコードセグメントの一実施形態を示している。該コールは、あらゆるボタンがトランスコーダに追加される前に行われる。

ボタン要素は、右ボタン、左ボタン、上ボタン、及び下ボタンを含むよう指定することが可能であり、それらは、特定の用途のために宣言され、及びnvldRight、nvldLeft、nvldUp、及びnvldDownとしてXMLで実施することができる。該ボタン要素を使用して、ボタンＺ順をメニュー要素内に現れる順のメニュートランスコーダ及び基準ボタンへと変換することができる。ボタン要素はまた、メニュー定義構造をメニュートランスコーダへ送るためのボタン宛先として使用することができる。代替的な実施形態では、LMCメニューをXMLで次のように指定することができる。
<menu id="menu1" TCDR_Linkedmenu="true"??>
<buttom id="2" nvld="1" AutoButton="true" DestID="menu3"??/><button
id="3" nvld="2" nvldUp="1" nvldDown="3"??/>
<video??/>
<button id="4" nvld="3" nvldUp="2" nvldDown="4"??/>
<video??/>
<button id="5" nvld="4" AutoButton="true" DestID="menu3"??/>
</menu>

<menu id="menu2" TCDR_Linkedmenu="true"??>
<buttom id="26" nvld="1" AutoButton="true" DestID="menu 1"??/>
<button id="27" nvld="2" nvldUp="1" nvldDown="3"??/>
<video??/>
<button id="28" nvld="3" nvldUp="2" nvldDown="4"??/>
<video??/>
<button id="29" nvld="4" AutoButton="true" DestID="menu3"??/>
</menu>

<menu id="menu3" TCDR_Linkedmenu="true"??>
<buttom id="32" nvld="1" AutoButton="true" DestID="menu2"??/><button
id="33" nvld="2" nvldUp="1" nvldDown="3"??/>
<video??/>
<button id="34" nvld="3" nvldUp="2" nvldDown="4"??/><video??/>
<button id="35" nvld="4" AutoButton="true" DestID="menu1"??/></menu>
図１５を参照すると、その概略的なブロック図は、XML（eXtended Markup Language）メディアスキーマ1500の一実施形態を示している。例示的な一実施形態では、メディア要素の数は、XMLコンパイラコンポーネントの実施及びメンテナンスが容易となるよう最小限に維持される。メディア要素は、ディスク要素1502と呼ばれる１つのコンテナ、メニュー1504及びボタン1506と称する２つのナビゲーション要素、及びビデオ1508及びスライド1510という２つのメディア要素を含む。

図１６を参照すると、その詳細なブロック図は、エミュレータインタフェイスでの使用に適したエミュレーション回路1600の機能ブロックを示している。実施形態によっては、該エミュレーション回路1600は、FPGA（Field Programmable Gate Array）として実施することができるが、他の技術を使用することも可能である。エミュレーション回路1600は、制御、データ転送、エミュレーション、トランスコーディング、データ記憶、インタフェイス、及びテストその他を含む様々な機能を実行するようプログラムすることができるプロセッサ1610を含む。例示的な一実施形態では、プロセッサ1610は、英国のAdvanced RISC Machines製のARM7TDMI-Sとして実施することができる。例示的なプロセッサ1610は、インサーキットエミュレータ1612及びTAP（Test Access Port）コントローラ1614を更に含む。

インサーキットエミュレータ1612は、トリガポイント周辺の履歴の追跡、バックグランドタスクの実行と同時のフォアグランドタスクのデバッグ、及びランタイム中のメモリの修正を用いた、リアルタイムデバッグをサポートすることができる。インサーキットエミュレータ1612はまた、マルチプロセッサ及び複合アーキテクチャデバイス、低速又は可変周波数設計、及び極低電圧コアのデバッグをサポートすることができる。

TAPコントローラ1614はJTAGインタフェイス1616に接続され、これにより、接続されたデバッガソフトウェアの制御下でプロセッサ1610が開始され及び停止されることを可能にするJTAGエミュレーションを該プロセッサ1610が実行することが可能となる。JTAGエミュレーションは、ユーザが、レジスタ及びメモリロケーションを読み出し及び変更し、中断ポイント及び観察ポイントを設定し、及びデバッグ処理のためのコードのダウンロード、追跡、及び監視をサポートすることを可能にする。

プロセッサ1610及びAHBバスインタフェイス1618は、ARMメモリバス1620上で通信する。該AHBバスインタフェイス1612は、プロセッサ1610を多層AMBA（Advanced Microcontroller Bus Architecture）高速バス（AHB）1622に通信可能となるよう接続する。該AHB1622にはAHBマトリクス1626も接続される。該AHBマトリクス1626は、多層AMBA高速バス（AHB）1622上のメモリ及びデバイスに対する並列経路を実現する複雑な相互接続マトリクスである。該AHB1622の並列経路は、バス帯域幅を増大させ、及び競合を低減させることにより待ち時間を短縮する。多層AHB1622は、多数のマスタデバイスとスレーブデバイスとの間の並列アクセスをサポートするAHBプロトコルに基づく相互接続技術である。

AHB1622に接続されたデバイスは、割り込みコントローラ1624、スタティックメモリコントローラ1628、テストインタフェイスコントローラ1630、キャッシュコントローラ1632、AHB-PVCIブリッジ1650、及びAHB-BVCIブリッジ1652を含む。割り込みコントローラ1624は、外部割り込み接続部1636、タイマ1638、MAC（Medis Access Control）モジュール1640、ATAPIデバイスブロック1642、及びホストATAコントロールブロック1644を含む１つ又は２つ以上のソースからの割り込み信号を検出することができる。割り込みコントローラ1624は、１つ又は２つ以上の割り込み信号が発生した際にプロセッサ1610上の割り込みを識別する適当なビットをアサートする。様々な用途において、現在の最高優先順位の割り込みは、ソフトウェア又はハードウェアにより判定することができる。典型的には、現在の最高優先順位の割り込みは、割り込みコントローラ1624内の一組のレジスタから読み出される。割り込みコントローラ1624は、割り込み状態を示すレジスタ、及び割り込みをイネーブルにし及び設定するレジスタを含む。

スタティックメモリコントローラ1628は、フラッシュメモリインタフェイス1646に接続され、典型的にはプロセッサ1610上で実行可能なプログラムコードを供給するが、データその他の情報をエミュレーション回路1600に供給することも可能である。

テストインタフェイスコントローラ1630は、テストインタフェイス1648に接続され、外部バスに対するテストインタフェイスのアクセスを要求する外部バスインタフェイス要求信号と外部バス情報の使用許可を要求するハンドシェイク許可信号とをサポートする。典型的なシステムでは、プロセッサ1610は、バスアクセスに関して最高の優先順位を有するテストインタフェイスコントローラ1630を使用して外部バスへのアクセスを絶えず要求することが可能である。テストパターンを適用するための典型的なイベントシーケンスでは、最初のリセットは非同期で適用され、及び同期して除去される。リセットの除去時に、プロセッサ1610は、スタティックメモリコントローラ1628を介してメモリ読み出しを開始する。該スタティックメモリコントローラ1628は、典型的には外部バスを要求し、該要求に対する肯定応答があった際にバスを読み出す。スタティックメモリコントローラ1628がビジーである場合に、テストインタフェイスコントローラ1630は外部バスを要求することができる。該要求が許可されるのは、テストインタフェイスコントローラ1630が、最高の優先順位を有しており、及び外部バスの所有権を有しているからである。スタティックメモリコントローラ1628が読み出しアクセスを完了したとき、テストインタフェイスコントローラ1630に対して外部バスの使用が許可される。外部バスが、バス要求信号を解決し、テストインタフェイスコントローラ1630が、テストパターンシーケンスを開始する。

キャッシュコントローラ1632がキャッシュメモリ1634（例えば4kBのスタティックRAM）に接続される。該キャッシュメモリ1634は、外部メモリアクセスを削減し、比較的低速のRAMを使用する場合であっても性能を改善する。該キャッシュメモリ1634は、プロセッサ1610がオーディオ及びビデオストリーミング装置のような高いデータスループットを有する多数のデバイスとバス帯域幅を共有することを可能にする。

AHB-PVCIブリッジ1650は、PVCI（Peripheral Virtual Component Interface）機能ブロックをAHB1622に接続する。AHB-PVCIブリッジ1650は、マスタインタフェイス及びスレーブインタフェイスを両方とも含むことができ、AHBマスタ−PVCIスレーブモード及びPVCIマスタ−AHBスレーブモードをサポートする。PVCI規格は、多数のインタフェイスと互換性を有するプラグインコンポーネントの開発を可能にし、これにより設計効率が促進される。例示的な実施形態では、レジスタバス1656に接続されたPVCI装置は、タイマ1638、MACモジュール1640、汎用入出力インタフェイス1654、ATAPIデバイスブロック1642、及びホストATAコントロールブロック1644を含む。

AHB-BVCIブリッジ1652は、BVCI（Basic Virtual Component Interface）機能ブロックをAHB1622に接続する。該BVCIは、メモリバス1658に対するシステムバスインタフェイスである。例示的な実施形態では、AHB-BVCIブリッジ1652に接続されたBVCI装置は、ホストATAコントロールブロック1644、ATAPIデバイスブロック1642、及びSDRAM（Synchronous Dynamic RAM）インタフェイス1668を含む。

タイマ1638は、プログラム制御下にある様々なイベントの時間管理を行うようプログラムすることができる。プロセッサ1610は、レジスタバス1656を介してタイマレジスタに送られた信号を介してタイマ1638の動作を制御する。タイマ1638は、インタフェイスコントローラの動作を介してプログラムの実行をリダイレクトすることができるタイマ割り込みを生成することができる。

エミュレーション回路1600は、レジスタバス1656とGPIOインタフェイス1662との間に接続された汎用入出力インタフェイス1654の動作によりデータ又は情報の送受信を行う。

例示するエミュレーション回路1600では、MACモジュール1640は、高度に集積化され埋め込まれたデバイスをネットワーク接続するための10/100Mbps Ethernetメディアアクセスコントローラである。MACモジュール1640は、外部ネットワークインタフェイス1660、並びにレジスタバス1656及びメモリバス1658に接続される。MACモジュール1640は、物理層のデバイスに対するインタフェイスであり、10Base-T、100Base-TX、100Base-FX、及び集積化されたDMA（Direct Memory Access）コントローラを有する32ビット規格ベースのBVCIバスインタフェイスをサポートすることができる。該MACモジュール1640は、典型的にはIEEE802.3に準拠するものであり、コリジョン検出、自動リトライ、フロー制御、アドレスフィルタリング、WOL（Wakeup-On-LAN）、及びパケット統計と共に、半二重及び全二重動作をサポートする。MACモジュール1640は、DMAバッファ管理ユニットを含むことができ、及び可変パケットサイズ及びバッファ連鎖を用いたワイヤスピード性能をサポートすることができる。MACモジュール1640は、かかるダイレクトなレジスタアクセス及びプログラム可能な割り込みを含むプロセッサタスクをオフロードして、小さなプロセッサオーバーヘッドを有する高いデータスループットを改善することができる。MACモジュール1640は、割り込みを生成することができ、割り込みコントローラ1624への割り込み信号接続を含む。

ホストATAコントロールブロック1644及びATAPIデバイスブロック1642は、レジスタバス1656及びメモリバス1658へ接続され、互いに協働して、計算、通信、娯楽、周辺機器、及びその他の用途を含む様々な用途においてホストコントローラとハードディスクドライブとの接続性を促進させる。ホストATAコントロールブロック1644は、ハードディスク、CD-ROM、DVD、DVD-R、及びその他のホストサブシステムを統合する完全なATAホストサブシステムを形成するためのディジタル回路を含む。ホストATAコントロールブロック1644は、ドライブ制御機能を実施し、及びエミュレーション回路1600がホストとして動作することを可能にする。エミュレータ1600がホストとして機能してストレージドライブを制御する際、該ホストは、ホストATAコントロールブロック1644及びホストATAインタフェイス1664の機能を使用する。ホストATAコントロールブロック1644はまた、PIO（Programmed Input-Output）、マルチワードDMA、及び様々な速度（例えば、33、66、100、及び133Mbyte/sec）のインタフェイス回路を実施することができる。様々な実施形態において、ホストATAコントロールブロック1644は、多数のATA/ATAPIデバイスをサポートすることができる。ホストATAコントロールブロック1644は、ホストコンピュータに接続するためにホストATAインタフェイス1644に接続され、及びプロセッサ1610がホストATAインタフェイスイベントにアドレスすることができるように割り込みコントローラ1624への割り込み接続を有している。

ATAPIデバイスブロック1642は、デバイスATAインタフェイス1666に接続され、及びIDE（Integrated Device Electronics）ストレージデバイスをホストシステムに接続する。ATAPIデバイスブロック1642は、典型的には、組み込みプロセッサ1610と連携してコマンド割り込みを実行する。ATAPIデバイスブロック1642は、ストレージドライブエミュレーション機能を実施し、これにより、エミュレーション回路1600がストレージドライブとして機能することが可能となる。外部装置はエミュレーション回路1600をドライブとして使用するホストとして動作することができる。ATAPIデバイスブロック1642は、ハードディスクドライブ、並びにDRAM、NAND又はNORフラッシュメモリ装置等を用いた半導体記憶装置と通信するために使用することができる。様々な実施形態において、ATAPIデバイスブロック1642は、様々なサイズ（例えば1、1.8、及び2.5インチ）のハードディスクドライブ、低電力ドライブ、ポータブルドライブ、テープドライブ、及び半導体又はフラッシュドライブのうちの１つ又は２つ以上とインタフェイスするよう設計することができる。ATAPIデバイスブロック1642は、プロセッサ1610がデバイスATAインタフェイスイベントにアドレスすることができるように割り込みコントローラ1624への割り込み接続を有している。

ホストATAインタフェイス1644は、デバイスATAインタフェイス1666に論理的に接続することができる。一例では、エミュレーション回路1600は、ストレージドライブと直接通信するMPEGデコーダとして機能することができる。パススルー動作では、エミュレーション回路1600は、ストレージドライブに受動的に送られたコマンドを監視することができる。

SDRAMインタフェイス1668は、回路を支持せず様々な構成（例えばDIMM）でSDRAM（Synchronous dynamic RAM）モジュールに対するエミュレーション回路1600の相互接続をサポートするインタフェイスコントローラである。SDRAMインタフェイス1668は、典型的には、SDRAMコントローラ（図示せず）及びSDRAM構成ブロック（図示せず）を含む。SDRAMコントローラは、SDRAMを制御するための制御信号を生成する。SDRAM構成ブロックは、リフレッシュライン及びモードラインといった様々なエンティティを制御するための構成レジスタ、及びSDRAMコントローラが使用するためのリフレッシュタイマを含む。様々な実施形態において、SDRAMインタフェイス1668は、スレーブ装置、任意長のバス転送、及びプログラム可能性をサポートすることができる。

様々な実施形態について本発明を説明したが、それら実施形態は例示であり、本発明の範囲はそれらには限定されない、ということが理解されよう。上記実施形態の多くの変形、修正、追加、及び改善を実施することが可能である。例えば、当業者であれば、本書で説明した構成及び方法を提供するために必要なステップを容易に実施し、及びその処理パラメータ、データ、及び大きさが例示のみを目的として提示されたものであることが理解されよう。該パラメータ、データ、及び大きさは、所望の構造並びに修正を達成するよう変更することができ、それらもまた本発明の範囲内のものである。本書で説明した実施形態の変更及び修正は、特許請求の範囲に記載した本発明の範囲及び思想から逸脱することなく、本書に記載した説明に基づいて行うことが可能である。

コンテンツ操作を容易にし、及びローカルサーバ及びリモートサーバから取得したコンテンツをユーザ装置102が取得して実行することを可能にする、メディアインタフェイスシステムの一実施形態を示す概略的なブロック図である。サーバユースケースの一実施形態を示す概略的なユースケース図である。クライアント及びサーバ管理ユースケースの一実施形態を示す概略的なユースケース図である。メディア管理ユースケースの一実施形態を示す概略的なユースケース図である。クライアントユースケースの一実施形態を示す概略的なユースケース図である。エミュレータにより実行される機能の一例を示す詳細な状態図である。ネットワーク上に分散するリソースとして機能するメディアツリーの一実施形態を示す概略的なブロック図である。クライアントメディアサーバの一実施形態を示す概略的な状態図である。ユーザ装置サーバとメディアトランスコーダとの間の操作を含むメディアトランスコーダシステムの一実施形態を示すユースケース図である。エミュレータインタフェイスと共に使用するためのサーバの様々なシステム、ハードウェア、及びソフトウェア構成要素を示す構成要素図である。様々なシステム対話を示すタイミングチャートである。様々なシステム対話を示すタイミングチャートである。プライマリサーバとセカンダリサーバとの間のサーバ調整対話に関する概略的なユースケース図である。サーバディスカバープロトコルの操作を示す状態図である。様々なシステム対話を示すタイミングチャートである。サーバとメディアトランスコーダとの間の対話の一実施形態を示す概略的なシーケンス図である。メディアツリーの変更をサポートするSOAP（Simple Object Access Protocol）メディア定義サーバの対話を示すシーケンス図である。エミュレータインタフェイスを使用するオーディオ・ビジュアルシステムの機能を示すユースケース図である。ブートROMの操作を示すフローチャートである。ブートROMの操作を示すシーケンス図である。ドライブコントローラの一実施形態を示す概略的な状態図である。ドライブインタフェイス操作の一実施形態を示すフローチャートである。 UDPプロトコル通信を実施してTCPオーバーヘッドなしの迅速なパケット伝送を可能にするためにクライアントにより実行される操作の一実施形態を示す概略的なフローチャートである。システムにより使用することができるメディア構成の一実施形態を示す概略的なブロック図である。メディアディレクトリの一実施形態を示している。アプリケーション及びクライアントが一貫したルック＆フィールを有する一連のメニューをユーザに提示することを可能にするリンクメニュー仕様（LMC）の一実施形態を示すリンクメニュー図である。 TCDRリンクメニューオプションがトランスコーダ上で呼び出される場合の情報フォーマット（IFO）のためのプログラムコードに追加されるコードセグメントの一実施形態を示すフローチャートである。 XML（eXtended Markup Language）メディアスキームの一実施形態を示す概略的なブロック図である。エミュレータインタフェイスでの使用に適したエミュレーション回路の機能ブロックを示す詳細なブロック図である。

Claims

メディアコンテンツを操作するための装置であって、
ネットワークに接続されたソース及び／又はローカルに接続されたソースを含む１つ又は２つ以上のソースに接続して該ソースからコンテンツを取得するインタフェイスと、
ユーザインタフェイスと、
コンテンツの選択及びアクセスを可能にするユーザインタフェイスを動的に構成するコントローラであって、該動的な構成がユーザにとってトランスペアレントなものである、コントローラと
を含む、メディアコンテンツを操作するための装置。
該装置が１つ又は２つ以上のソースと接続したことに応じて前記コントローラがユーザインタフェイスの構成を自動的に開始する、請求項１に記載の装置。
前記コントローラが前記ユーザインタフェイスを複数のコンテンツグループで構成する、請求項１に記載の装置。
１つ又は２つ以上のソースから複数の異なるフォーマットでコンテンツを取得する前記インタフェイスと、
前記コンテンツを提示のために共通のフォーマットへと変換するトランスコーダと
を更に含む、請求項１に記載の装置。
前記変換がユーザにとってトランスペアレントなものである、請求項４に記載の装置。
１つ又は２つ以上のソースから複数の異なるフォーマットでコンテンツを取得する前記インタフェイスと、
前記コンテンツを提示のための互換性を有する１つのフォーマットへとデコードするデコーダと
クライアント装置に共通のフォーマットで前記コンテンツを提示するクライアント装置と
を更に含む、請求項１に記載の装置。
前記デコーダが、クライアント上に存在する複数のデコーダ、クライアント上に存在する複数のバージョンのデコーダコードをダウンロードすることにより再構成される少なくとも１つのプログラム可能なクライアント上に存在するデコーダ、及びコンテンツと共にダウンロードされるデコーダコードからなる１グループから選択される、請求項６に記載の装置。
１つ又は２つ以上のソースにおけるコンテンツ要素の相対的な位置に基づいてナビゲーション情報を導出し、及び該ナビゲーション情報からコンテンツを編成する、前記コントローラ上で実行することができるサーバを更に含む、請求項１に記載の装置。
クライアント装置と、
分散ファイルシステムを形成し単一のタイトルセットを含む仮想メディアボリューム内にコンテンツ要素及びナビゲーション情報を構成する、前記コントローラ上で実行することができるサーバであって、該サーバが該単一のタイトルセットからコンテンツを置換する際に前記クライアント装置が該単一のタイトルセットを繰り返し再生する、サーバと
を更に含む、請求項１に記載の装置。
VTS（Video Title Set）スタック及びVTSファイルテーブルを含む分散ファイルシステムであって、該VTSスタックが、メディアツリー内のユーザの位置を保存し、該VTSファイルテーブルが、前記ユーザの位置をメディアナビゲーションツリー内の位置にマッピングする、分散ファイルシステムを更に含む、請求項９に記載の装置。
メディア空間位置を保存するためにクライアントにより保持される、前記VTSスタック内のスタックフレームを更に含み、前記サーバが、メディア記述子を使用して前記スタックフレームを前記メディアツリーに関連付けする、請求項１０に記載の装置。
メディアコンテンツを操作するための装置であって、
クライアント装置と、
分散ファイルシステムを形成し単一のタイトルセットを含む仮想メディアボリューム内にコンテンツ要素及びナビゲーション情報を構成するサーバであって、該サーバが該単一のタイトルセットからコンテンツを置換する際に前記クライアント装置が該単一のタイトルセットを繰り返し再生する、サーバと
を含む、メディアコンテンツを操作するための装置。
前記分散ファイルシステムが、VTS（Video Title Set）スタック及びVTSファイルテーブルを含み、該VTSスタックが、メディアツリー内のユーザの位置を保存し、該VTSファイルテーブルが、前記ユーザの位置をメディアナビゲーションツリー内の位置にマッピングする、請求項１２に記載の装置。
メディア空間位置を保存するためにクライアントにより保持される、前記VTSスタック内のスタックフレームを更に含み、前記サーバが、メディア記述子を使用して前記スタックフレームを前記メディアツリーに関連付けする、請求項１３に記載の装置。
コンテンツ操作方法であって、
ネットワーク接続が可能なソース及び／又はローカル接続可能なソースを含む１つ又は２つ以上のソースからコンテンツを取得し、該コンテンツ及びソースが動的に変更可能なものであり、
コンテンツの選択及びアクセスを可能にするユーザインタフェイスを動的に構成し、該動的な構成がユーザにとってトランスペアレントなものである、
という各ステップを含む、コンテンツ操作方法。
ユーザインタフェイスと共に使用するためのユーザ装置を１つ又は２つ以上のソースに接続し、該接続に応じて前記ユーザインタフェイスを自動的に構成する、という各ステップを更に含む、請求項１５に記載の方法。
前記ユーザインタフェイスを複数のコンテンツグループに構成する、請求項１５に記載の方法。
１つ又は２つ以上のソースから複数の異なるフォーマットでコンテンツを取得し、
該コンテンツを提示のために共通のフォーマットへと変換し、該変換がユーザにとってトランスペアレントなものであり、
前記コンテンツを共通のフォーマットでユーザ装置に提供する、
という各ステップを更に含む、請求項１５に記載の方法。
前記ユーザ装置、及び前記ローカル接続ソースのうちの少なくとも１つが、家庭用電化製品である、請求項１５に記載の方法。
前記１つ又は２つ以上のソースから複数の異なるフォーマットでコンテンツを取得し、
該コンテンツを提示のための互換性を有する１つのフォーマットへと処理し、
該コンテンツを共通のフォーマットでユーザ装置に提供する、
という各ステップを更に含む、請求項１５に記載の方法。
コンテンツアイテムの相対的な位置からナビゲーション情報を導出するステップを更に含む、請求項１５に記載の方法。
前記導出されたコンテンツのナビゲーション情報に基づいて該コンテンツを編成するステップを更に含む、請求項１５に記載の方法。
コンテンツアイテムをツリー構造のディレクトリに構成し、
該ディレクトリをユーザによるソース選択のためのメニューとして表示する、
という各ステップを更に含む、請求項１５に記載の方法。
ユーザ装置上でのユーザインタフェイスの選択のためのソースとして前記構成されたコンテンツアイテムを使用するステップを更に含む、請求項２３に記載の方法。
複数のネットワークにわたり分散された複数のツリー構造のディレクトリにコンテンツアイテムを構成するステップを更に含む、請求項１５に記載の方法。
メディアコンテンツを操作するための装置であって、
ネットワークに接続されたソース及び／又はローカルに接続されたソースを含む１つ又は２つ以上のソースに接続して該ソースからコンテンツを取得するインタフェイスと、
前記１つ又は２つ以上のソースの相対的な位置に基づいて該ソースからナビゲーション情報を導出し、及び該ソースに相互に関連する内部的なマップへと前記コンテンツを編成する、コントローラと
を含む、メディアコンテンツを操作するための装置。
前記コントローラに接続されたユーザインタフェイスを更に含み、前記コントローラが、前記ユーザインタフェイスを介してコンテンツアイテムをメニューとしてツリー構造のディレクトリに編成する、請求項２６に記載の装置。
前記コントローラに接続されたクライアント装置を更に含み、前記コントローラが、前記クライアント装置上でのユーザインタフェイスの選択のためのソースとして前記編成されたコンテンツアイテムを使用し、及び複数のネットワークにわたり分散されたツリー構造のディレクトリに前記コンテンツアイテムを構成する、請求項２７に記載の装置。
コンテンツ操作方法であって、
ネットワーク接続可能なソース及び／又はローカル接続可能なソースを含む１つ又は２つ以上のソースから該ソースの相対的な位置に基づいてナビゲーション情報を導出し、
コンテンツを前記ソースに相互に関係する内部的なマップへと編成する、
という各ステップを含む、コンテンツ操作方法。
コンテンツアイテムをツリー構造のディレクトリに構成し、
該ディレクトリをユーザによるソース選択のためのメニューとして表示する、
というステップを更に含む、請求項２９に記載の方法。
前記構成されたコンテンツアイテムをユーザ装置上でのユーザインタフェイスの選択のためのソースとして使用するステップを更に含む、請求項３０に記載の方法。
コンテンツアイテムを複数のネットワークにわたり分散されたツリー構造のディレクトリに構成するステップを更に含む、請求項３１に記載の方法。
サーバであって、
１つ又は２つ以上の様々なメディアコンテンツソースからのストリーミングメディアを供給するメディアモニタと、
前記メディアコンテンツを仮想ファイル構造内に構成し格納する仮想メディアドライバと、
様々なタイプのコンテンツメディアを前記仮想メディアドライバへ提示するメディアサーバと、
１つ又は２つ以上のソースから前記メディアモニタを介してコンテンツを取得するプロセッサであって、クライアント上で提示することができる形式への更なるコンテンツ処理の定義のために前記取得したコンテンツの形式を評価し、及び前記クライアント上で提示することができる形式へ前記取得したコンテンツを処理し、前記取得、評価、及び処理がユーザにとってトランスペアレントなものである、プロセッサと
を含む、サーバ。
前記プロセッサが前記コンテンツを前記クライアント上で提示することができる形式にトランスコードする、請求項３３に記載のサーバ。
前記コンテンツを前記クライアント上で提示することができる形式に変換することができる、サーバ上に存在する１つ又は２つ以上のデコーダを更に含む、請求項３３に記載サーバ。
サーバ上に存在する１つ又は２つ以上のプログラム可能なデコーダを更に含み、前記プロセッサが、サーバ上に存在する所与のバージョンのデコーダコードをコンテンツとは別個に又はコンテンツと共にダウンロードすることにより前記１つ又は２つ以上のデコーダのうちの１つのデコーダを再構成し、前記１つ又は２つ以上のデコーダが、前記クライアント上で提示することができる形式に前記コンテンツを変換するものである、請求項３３に記載のサーバ。
前記コンテンツ及びソースが動的に変更することが可能なものである、請求項３３に記載のサーバ。
前記メディアモニタがネットワーク接続が可能なソース及びローカル接続が可能なソースを含む１つ又は２つ以上のソースからのストリーミングコンテンツを供給する、請求項３３に記載のサーバ。
コンテンツ操作方法であって、
１つ又は２つ以上のソースからコンテンツを取得し、該コンテンツ及びソースが動的に変更可能なものであり、
ユーザ装置上で提示することができる形式への更なるコンテンツ処理の定義のために、取得したコンテンツの形式を評価し、
該取得したコンテンツをユーザ装置上で提示することができる形式へと処理し、前記取得、評価、及び処理がユーザにとってトランスペアレントなものである、
という各ステップを含む、コンテンツ操作方法。
前記コンテンツをクライアント上で提示することができる形式にトランスコードするステップを更に含む、請求項３９に記載の方法。
クライアント上で提示することができる形式にコンテンツを変換するために使用する、サーバ上に存在する複数のデコーダのうちの１つ又は２つ以上を選択し、
該選択されたデコーダを使用してコンテンツをデコードする、
という各ステップを更に含む、請求項３９に記載の方法。
サーバ上に存在する１つ又は２つ以上のバージョンのデコーダコードをコンテンツとは別個に又はコンテンツと共にダウンロードし、
クライアント上で提示することができる形式へのコンテンツの変換を行うように、前記ダウンロードによる前記１つ又は２つ以上のバージョンのデコーダコードを再構成する、という各ステップを更に含む、請求項４１に記載の方法。
ネットワーク接続が可能なソース及びローカル接続が可能なソースを含む１つ又は２つ以上のソースからコンテンツを取得するステップを更に含み、該コンテンツ及びソースが動的に変更可能なものである、請求項４２に記載の方法。
コンテンツの選択及びアクセスを可能にするユーザインタフェイスを動的に構成するステップを更に含み、該動的な構成がユーザにとってトランスペアレントなものである、請求項４２に記載の方法。
コンテンツアイテムの相対的な位置からコンテンツナビゲーション情報を導出し、及び該導出されたコンテンツナビゲーション情報に基づいてコンテンツを編成する、という各ステップを更に含む、請求項４２に記載の方法。
コンテンツを複数のツリー構造のディレクトリに構成し、
ユーザによるソースの選択のためのメニューとして前記ディレクトリを表示し、
前記構成されたコンテンツアイテムを、前記ユーザ装置上でのユーザインタフェイスの選択のためのソースとして使用する、
という各ステップを更に含む、請求項４２に記載の方法。
複数のネットワークにわたって分散されたツリー構造のディレクトリにコンテンツアイテムを構成するステップを更に含む、請求項４２に記載の方法。
ユーザ装置に提示するための仮想メディアボリュームを生成し、該仮想メディアボリュームが分散ファイルシステムであり、
該仮想メディアボリュームの単一のタイトルセットを連続して再生し、
該単一のタイトルセットにおいて前記分散ファイルシステムからのメディアを動的に置換する、
という各ステップを更に含む、請求項４２に記載の方法。
前記取得したコンテンツをユーザ装置上で提示することができる形式へリアルタイムで変換するステップを更に含む、請求項４２に記載の方法。
コンテンツ操作方法であって、
ユーザ装置に提示するための仮想メディアボリュームを生成し、該仮想メディアボリュームが分散ファイルシステムであり、
該仮想メディアボリュームの単一のタイトルセットを連続して再生し、
該単一のタイトルセットにおいて前記分散ファイルシステムからのメディアを動的に置換する、
という各ステップを含む、コンテンツ操作方法。
メディアコンテンツを操作するための装置であって、
少なくとも１つのコンテンツソースに接続して該少なくとも１つコンテンツソースから使用及びナビゲーション情報を１つ又は２つ以上の形式で取得するインタフェイスと、
ユーザインタフェイスと、
前記使用及びナビゲーション情報を前記ユーザインタフェイスのメニュー表示内に組み込み、及び前記使用及びナビゲーション情報に基づいて前記少なくとも１つのソースのコンテンツにアクセスする、コントローラとを含み、
前記取得、組み込み、及びアクセスがユーザにとってトランスペアレントなものである、
メディアコンテンツを操作するための装置。
前記コントローラが、ユーザインタフェイスへ提示するための分散ファイルシステムである仮想メディアボリュームを生成し、及び該分散ファイルシステムのファイル構成からナビゲーション情報を導出する、請求項５１に記載の装置。
前記コントローラが、分散ファイルシステムのディレクトリを生成し、及びメディアコンテンツ要素がメニューボタンとして表示されるメニューとして前記ユーザインタフェイスを介して前記ディレクトリを表示する、請求項５１に記載の装置。
前記少なくとも１つのコンテンツソースが、ネットワーク接続が可能なソース及びローカル接続が可能なソースを含み、前記コンテンツ及びソースが動的に変更可能なものである、請求項５１に記載の装置。
前記使用及びナビゲーション情報が断続的に変化し、
前記コントローラが、前記断続的に変化する使用及びナビゲーション情報に応じて前記メニュー表示をリアルタイムに更新する、請求項５１に記載の装置。
コンテンツ操作方法であって、
少なくとも１つのコンテンツソースから１つ又は２つ以上の形式で使用及びナビゲーション情報を取得し、
該使用及びナビゲーション情報をユーザ装置のメニュー表示に組み込み、
前記使用及びナビゲーション情報に基づいて前記少なくとも１つのソースのコンテンツにアクセスし、
前記取得、組み込み、及びアクセスがユーザにとってトランスペアレントなものである、
という各ステップを含む、コンテンツ操作方法。
ユーザ装置に提示するための仮想メディアボリュームを生成し、該仮想メディアボリュームが分散ファイルシステムであり、
該分散ファイルシステムのファイル構成からナビゲーション情報を導出する、
という各ステップを更に含む、請求項５６に記載の方法。
分散ファイルシステムでディレクトリを生成し、
メディアコンテンツ要素がメニューボタンとして表示されるように前記ディレクトリをメニューとして表示する、
という各ステップを更に含む、請求項５６に記載の方法。
前記少なくとも１つのコンテンツソースが、ネットワーク接続が可能なソース及びローカル接続が可能なソースを含み、前記コンテンツ及びソースが動的に変更可能なものである、請求項５６に記載の方法。
前記使用及びナビゲーション情報が断続的に変化し、
該断続的に変化する使用及びナビゲーション情報に応じて前記メニュー表示を更新するステップを更に含む、請求項５６に記載の方法。
前記コンテンツの形式をリアルタイムで更新するステップを更に含む、請求項６０に記載の方法。
メディアコンテンツを操作するための装置であって、
複数のコンテンツソースと少なくとも１つのシンク装置との間のインタフェイスと、
該インタフェイスに接続され、複数のコンテンツソース上のコンテンツの１つ又は２つ以上のフォーマットを判定し、及び該１つ又は２つ以上のフォーマットをユーザとの対話を伴うことなく少なくとも１つのシンク装置との互換性を有する１つのフォーマットへと処理する、コントローラと
を含む、メディアコンテンツを操作するための装置。
前記インタフェイスが、ネットワーク接続されたソース及びローカル接続されたソースを含む１つ又は２つ以上のソースに接続して該ソースからコンテンツを取得し、該１つ又は２つ以上のソースが、複数の異なる種類のコンテンツを供給する、請求項６２に記載の装置。
前記コントローラが、前記シンク装置上に表示可能な形式への処理の定義のために取得されたコンテンツの形式を評価し、及び取得されたコンテンツを前記シンク装置上に表示可能な形式へ処理し、前記取得、評価、及び処理がユーザにとってトランスペアレントなものである、請求項６２に記載の装置。
コンテンツの管理方法であって、
複数のコンテンツソースの１つ又は２つ以上の形式を判定し、
該１つ又は２つ以上のフォーマットをユーザとの対話を伴うことなくシンク装置と互換性を有するフォーマットに処理する、
という各ステップを含む、コンテンツの管理方法。
ユーザ装置上のコンテンツを管理するための方法であって、
１つ又は２つ以上のソースから少なくとも１つのフォーマットで使用及びナビゲーション情報を取得し、
該情報の組み合わせを前記ユーザ装置のメニュー表示内に組み込み、
ユーザからの如何なる追加情報をも必要とすることなく前記情報の組み合わせに基づいて前記少なくとも１つのソースからのコンテンツにアクセスする、
という各ステップを含む、ユーザ装置上のコンテンツを管理するための方法。
メディアコンテンツに自動的にアクセスするための方法であって、
メディアコンテンツを複数のフォーマットで供給する複数の異なるソースにインタフェイスし、
前記ソース及びメディアコンテンツが動的に変更可能なものであり、
前記メディア及びソースの相対的な位置から導出されたナビゲーション情報にしたがって前記メディアコンテンツを編成し、
アクセスするメディアコンテンツ要素を選択するためのユーザインタフェイスとして前記メディアコンテンツの編成を表示し、
選択されたメディアコンテンツ要素にアクセスする、
という各ステップを含む、メディアコンテンツに自動的にアクセスするための方法。
前記コンテンツの選択及びアクセスヲ可能にするユーザインタフェイスを動的に構成し、該動的な構成がユーザにとってトランスペアレントなものである、請求項６７に記載の方法。