JP4765042B2 - マルチデバイス上でコンテンツをレンダリングするシステムおよび方法 - Google Patents

Description

本開示は、マルチメディア・コンテンツのレンダリング（rendering ）に関し、より詳細には、マルチデバイス（multiple devices）を介するマルチメディア・コンテンツのレンダリングに関する。
（参照関連出願）
本開示は、２００２年１２月３１日に出願された、「マルチデバイスを介してレンダリングされるマルチメディア・コンテンツをリンクする方法および装置（Method and Apparatus for Linking Multimedia Content Rendered Via Multiple Devices ）」と題された自己（commonly owned）米国特許出願第１０／３３４，８４８号（代理人整理番号：ＣＳ２０６９３ＲＬ）に関連しており、全ての目的において、その全体を引用によって本明細書に援用する。

限られたディスプレイ性能を有する幾つかのモバイル・コンピューティング・デバイスには、ウェブ・ブラウジング性能も与えられている。例えば、パーソナル・デジタル・アシスタント（ＰＤＡ）には、ワイヤレス・モデムおよびウェブ・ブラウジング・ソフトウェアが含まれる場合がある。別の例として、携帯電話には、ディスプレイおよびウェブ・ブラウジング・ソフトウェアが含まれる場合がある。しかし、それらのデバイスでは、典型的な制限（例えば、動力、メモリ、ディスプレイ解像度、スクリーン・サイズ）のため、フル・サイズのコンピュータ（例えば、デスクトップ・コンピュータ、ラップトップ・コンピュータなど）向けのインターネットからのコンテンツを適切にレンダリングすることが可能でない場合がある。例えば、ディスプレイ解像度およびスクリーン・サイズのため、ＰＤＡまたは携帯電話のディスプレイではテキストまたは簡単なアイコン以外を表示することが不可能な場合がある。あるいは、デバイスでコンテンツをレンダリングしても、実用上、品質が充分でない場合がある。例えば、ウェブ・ページからの画像をモバイル・デバイス上で表示すると、ディスプレイの低い解像度のため、小さなスクリーン・サイズのため、またはそれらの両方のために、不鮮明な場合がある。

同様に、典型的には、モバイル・コンピューティング・デバイスでは、利用可能であり得る音声または映像ストリームを適切にレンダリングすることが可能でない場合がある。例えば、ＰＤＡには音声システムが含まれてない場合があり、ＰＤＡの音声システムでは低品質の音声を生成することしか可能でない場合もある。そうしたＰＤＡでは、例えば、インターネットから利用可能なエムピースリー（ＭＰ３）音楽ファイルを、適切にレンダリングすることが可能でない場合がある。

幾つかの例では、モバイル・コンピューティング・デバイスをインターネットにリンクする通信リンクが、ボトルネック（bottleneck）である場合がある。例えば、携帯電話リンクの帯域幅では、映像ストリームを適切にレンダリングすることは可能でない。

一般に、多くのモバイル・コンピューティング・デバイス上では、インターネットを介して利用可能なコンテンツを、意図されているようにレンダリングすることが可能でない場合がある。

複数のデバイスによってコンテンツがレンダリングされ得るシステムおよび方法の例を
説明する。複数のデバイス上でコンテンツをレンダリングすることによって、単一のデバイスにおける制限は緩和される。例えば、ユーザが、低解像度のディスプレイを備えるＰＤＡを有する場合がある。さらに、ユーザが、解像度がより高いディスプレイ、スクリーン・サイズがより大きいディスプレイ、またはそれらの両方であるディスプレイを備えるラップトップ・コンピュータへのアクセスを有する場合がある。本明細書に説明するように、ユーザは、例えば、ＰＤＡおよびラップトップ・コンピュータを用いて、テキスト、低解像度グラフィック、および高解像度グラフィックを含むウェブ・ページを、レンダリングすることが可能である。例えば、ウェブ・ページのテキストおよび低解像度グラフィックをＰＤＡに配信し、そのＰＤＡによってレンダリングすることが可能であり、ウェブ・ページの高解像度グラフィックをラップトップ・コンピュータに配信し、そのラップトップ・コンピュータによってレンダリングすることが可能である。

システム概観：
図１は、マルチデバイス上でレンダリングするためにコンテンツがマルチデバイスに配信される環境の一例である、環境１００のブロック図である。コンテンツ・サーバ１０４はネットワーク１０８に接続されている。コンテンツ・サーバ１０４は、ネットワーク１０８を介してユーザにコンテンツを提供する。コンテンツには、例えば、ウェブ・ページ、ストリーミング映像、ストリーミング音声などが含まれる。単一のコンテンツ・サーバ１０４が多様な型のコンテンツ（例えば、ウェブ・ページ、映像、音声）を提供してもよく、異なるコンテンツ・サーバが異なる型のコンテンツを提供してもよい（例えば、環境１００に、ウェブ・ページ・サーバ、映像サーバ、および音声サーバのうちの少なくとも１つが含まれてもよい）。ネットワーク１０８には、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネット、イントラネット、エクストラネット、ローカル・エリア・ネットワーク（ＬＡＮ）などが含まれる。

また、マルチデバイス・プロクシ・サーバ１１２が、ネットワーク１０８，ネットワーク１１６に接続されており、レンダリング・デバイス１２０ａ，１２０ｂがネットワーク１１６に接続されている。マルチデバイス・プロクシ・サーバ１１２を、以下でさらに詳細に説明する。一般に、マルチデバイス・プロクシ・サーバ１１２は、レンダリング・デバイス１２０ａ，１２０ｂとネットワーク１０８との間のゲートウェイとして機能する。例えば、コンテンツ・サーバ１０４など、ネットワーク１０８に接続されたデバイスから、レンダリング・デバイス１２０ａに情報が伝送される場合、そうした情報はマルチデバイス・プロクシ・サーバ１１２を通じて引き渡される。ネットワーク１１６には、ローカル・エリア・ネットワーク、インターネット、イントラネット、エクストラネット、ローカル・エリア・ネットワークなどが含まれる。ネットワーク１１６がネットワーク１０８から分離しているように示しているが、ネットワーク１１６は、ネットワーク１０８のサブセットであってもよく、ネットワーク１０８のサブセットを含んでもよい。

リソース・マネージャ１２４はネットワーク１１６に接続されている。リソース・マネージャ１２４がマルチデバイス・プロクシ・サーバ１１２から分離しているように示しているが、リソース・マネージャ１２４のうち幾つかがまたは全てが、マルチデバイス・プロクシ・サーバ１１２の構成要素であってもよい。リソース・マネージャ１２４およびレンダリング・デバイス１２０ａ，１２０ｂは、ボックスによって示される物理的な近傍１２８に位置し得る。一般に、例えばレンダリング・デバイス１２０ｂなど、近傍１２８の他のデバイス上でコンテンツをレンダリングするために、そうした他のデバイスにユーザがアクセスすることを可能とするように、リソース・マネージャ１２４はユーザ・デバイス、例えばレンダリング・デバイス１２０ａと、対話する。

また、他のレンダリング・デバイス（例えば、レンダリング・デバイス１２０ａ，１２
０ｂ）の物理的近傍１２８には存在しない、１つ以上のレンダリング・デバイス１２０ｃも含まれる。そうしたレンダリング・デバイス１２０ｃは、ネットワーク１０８に接続されている。デバイス１２０ｃをレンダリング・デバイスと称しているが、コンテンツをレンダリングするためにデバイス１２０ｃを用いる必要はない。例えば、後に別のデバイスでレンダリングするコンテンツを記憶するために、デバイス１２０ｃを用いることが可能である。レンダリング・デバイス１２０には、携帯電話、ページャ、ＰＤＡ、ラップトップ・コンピュータ、デスクトップ・コンピュータ、ワークステーション、サーバなどが含まれる。

また、トランスコーダ１３２もネットワーク１０８に接続されている。トランスコーダ１３２は、コンテンツ・サーバ１０４からのコンテンツがレンダリング・デバイス１２０のうちの１つではレンダリング不可能なフォーマットである場合に、レンダリング可能なフォーマットにトランスコードするために用いられる。

図２は、コンテンツをマルチデバイスに配信する方法の一例である、方法１５０のフローチャートである。図１に関連して図２を説明する。
ブロック１５２にて、ユーザは、例えば、レンダリング・デバイス１２０ａを介して、ユーザが位置する近傍に、リソース・マネージャ１２４を発見する。この発見は、サービス・ロケーション・プロトコル（ＳＬＰ）、ブルートゥース（BLUETOOTH （商標））規格、サン・マイクロシステムズ社のジニー（Jini（商標））技術、サリュテーション・コンソーシアム（Salutation Consortium ）の技術など、規格化された発見メカニズムを含む、種々の技術を用いて達成される。

ブロック１５４にて、ユーザは、ユーザのメイン・デバイス以外のデバイス上でコンテンツをレンダリングするために、リソースを予約する。リソースは、ソフトウェア・リソースであっても、ハードウェア・リソースであってもよい。例えば、ユーザのメイン・デバイスがレンダリング・デバイス１２０ａの場合、ユーザは、レンダリング・デバイス１２０ｂなど、近傍１２８の別のデバイス上のリソースを予約する。コンテンツをレンダリングするためにレンダリング・デバイス１２０ｂ上のリソースを予約するように、ユーザは、レンダリング・デバイス１２０ａを用いてリソース・マネージャ１２４と対話する。例えば、レンダリング・デバイス１２０ｂが音声システムを含む場合、ユーザはデバイス１２０ｂの音声システムを予約する。

さらに、ユーザは、デバイス１２０ｃなどのリモート・デバイス上のリソースを予約してもよく、リモート・デバイスにコンテンツが配信されるように要求してもよい。例えば、ユーザは、一定の型のコンテンツをリモート・デバイス１２０ｃに配信するように、または、一定の特定コンテンツ（例えば、ファイル、音声ストリーム、映像ストリームなど）をリモート・デバイス１２０ｃに配信するように、マルチデバイス・プロクシ・サーバ１１２に命令する。一例では、ユーザは、リソース・マネージャ１２４と対話することなく、リモート・デバイス１２０ｃ上のリソースを予約してもよく、またはリモート・デバイス１２０ｃへの配信を要求してもよい。

ブロック１５８にて、ユーザは、コンテンツ・サーバ１０４からのコンテンツを要求する。例えば、ユーザは、レンダリング・デバイス１２０ａを用いてコンテンツを要求する。

ブロック１６２にて、レンダリング・デバイス１２０ａによって要求された、コンテンツ・サーバ１０４からのコンテンツが、マルチデバイス・プロクシ・サーバ１１２で受信される。ブロック１６６にて、ユーザがアクセスを有するデバイスに対する、要求されたコンテンツのマッピングが、マルチデバイス・プロクシ・サーバ１１２によって決定され
る。このマッピングでは、例えば、テキストおよびグラフィックはデバイス１２０ａへ向かい、音声はデバイス１２０ｂまたはデバイス１２０ｃに向かうことが示される。

幾つかの例で、レンダリング・デバイス１２０にはコンテンツ・サーバ１０４により提供されるフォーマットのコンテンツをレンダリングすることが不可能であると判定された場合、マルチデバイス・プロクシ・サーバ１１２は、レンダリング・デバイス１２０にソフトウェアをダウンロードする（ブロック１６８）。ダウンロードされたソフトウェアによって、コンテンツ・サーバ１０４により提供されるフォーマットのコンテンツをレンダリングする性能が、レンダリング・デバイス１２０に提供される。

幾つかの例で、レンダリング・デバイスにはコンテンツ・サーバ１０４により提供されるフォーマットのコンテンツをレンダリングすることが不可能であると判定された場合、マルチデバイス・プロクシ・サーバ１１２は、トランスコーダ１３２を利用する。そのような場合には、ブロック１７０にて、マルチデバイス・プロクシ・サーバ１１２はコンテンツの一部分をトランスコーダ１３２に伝送する。一例として、トランスコーダはステレオ音声データをモノラル音声データにトランスコードする。続いて、ブロック１７４にて、マルチデバイス・プロクシ・サーバ１１２は、コンテンツのトランスコードされた部分をトランスコーダ１３２から受信する。図１では、トランスコーダ１３２を単独のデバイスのように示しているが、マルチデバイス・プロクシ・サーバ１１２には、トランスコーダ１３２の代わりの、すなわちトランスコーダ１３２に加えて、トランスコーダが含まれてよい。

ブロック１７８にて、マルチデバイス・プロクシ・サーバ１１２は、ブロック１６６で決定したマッピングに従って、コンテンツまたはコンテンツの一部分をマルチデバイスに配信する。

また、幾つかの例では、ユーザは、レンダリング・デバイス１２０ｃなどのリモート・デバイスに、コンテンツが配信されることを望む。その場合、ユーザは、例えば、一定の型のコンテンツをリモート・デバイス１２０ｃに配信するように、マルチデバイス・プロクシ・サーバ１１２に命令する。続いて、マルチデバイス・プロクシ・サーバ１１２は、リモート・デバイス１２０ｃを含むユーザがアクセスを有するデバイスに対する、要求されたコンテンツのマッピングを決定する。このマッピングでは、例えば、テキストおよびグラフィックはデバイス１２０ａへ向かい、音声はデバイス１２０ｂまたはデバイス１２０ｃに向かうことが示される。

次に、マルチデバイス・プロクシ・サーバ１１２は、マッピングに従って適切なデバイスにコンテンツを配信する。例えば、テキストおよびグラフィックをユーザのＰＤＡに配信し、音声を、ユーザの近く（例えば、ユーザの位置する会議室（conference room ））に位置する、音声システムを備えるデスクトップに配信することが可能である。さらに、ユーザのデスクトップ・コンピュータのハードドライブ、ＣＤ−ＲＯＭ、ＤＶＤなどに記憶するため、またはユーザのデスクトップ・コンピュータ上でソフトウェアにより処理するため、またはそれらの両方のために、ユーザのホーム（home）のユーザのデスクトップ・コンピュータに音声を配信することも可能である。

リソース・マネージャ：
リソース・マネージャ１２４は、物理的近傍１２８の内部または付近に位置しても、物理的近傍１２８から離れて位置してもよい。上述のように、リソース・マネージャ１２４のうち幾つかは、または全ては、マルチデバイス・プロクシ・サーバ１１２の構成要素であってもよい。代わりに、リソース・マネージャ１２４がマルチデバイス・プロクシ・サーバ１１２から完全に分離していてもよい。リソース・マネージャ１２４は、パーソナル
・コンピュータ、ワークステーション、サーバ、メインフレーム、セットトップボックス、携帯電話基地局のコンピュータなど、１つ以上のコンピュータを用いて実装されてよい。幾つかの例では、リソース・マネージャ１２４の１つのインスタンスが各近傍に対応し、別の例では、リソース・マネージャ１２４の１つのインスタンスが幾つかの近傍に対応する。

図３は、リソース・マネージャ１２４の一例のブロック図であり、リソース・マネージャ１２４の、レンダリング・デバイス１２０を含む他のシステムとの対話の一例を示している。リソース・マネージャ１２４には、リソース割当サブシステム２０４，ユーザ対話サブシステム２０６，リソース監視サブシステム２０８，および共有リソース・データベース２１２が含まれる。リソース・マネージャ１２４には、レンダリング・デバイス１２０およびマルチデバイス・プロクシ・サーバ１１２など他のシステムと通信するための、通信エージェント２１６も含まれる。他のシステムと通信するために、任意の型の適切なプロトコルが用いられてよい。例えば、セッション・インビテーション・プロトコル（ＳＩＰ）、ハイパー・テキスト・トランスファー・プロトコル（ＨＴＴＰ）、シンプル・メール・トランスファー・プロトコル（ＳＭＴＰ）などのプロトコル、または同様のプロプライエタリな（proprietary ）プロトコルが用いられる。

他のシステムとの通信は、例えば、ネットワーク１０８を介してもよく、ネットワーク１１６を介してもよく、リソース・マネージャ１２４に近接するリモート・デバイスと直接通信してもよく、またはそれらのうちの１つ以上であってもよい。そうした通信には、ＬＡＮ、電話回線、ケーブル回線、光ファイバー回線などの有線通信リンクを介する通信、または無線ＬＡＮ（例えば、IEEE802.11x 規格）、ブルートゥース（商標）規格による無線通信リンク、携帯リンク、双方向ページング・リンク（two-way paging link ）などの無線リンクを介する通信が含まれる。

リソース監視サブシステム２０８は、近傍のデバイスと通信して、どのリソースがユーザに利用可能かを判定する。例えば、会議室には、フル・サイズのディスプレイと音響システムとを有するコンピュータが存在する場合がある。リソース監視サブシステム２０８は、ディスプレイおよび音響システムなど、使用に利用可能なリソースをこのコンピュータが有することを確かめるため、このコンピュータと通信する。リソース・マネージャ１２４は、デバイスを構成要素のリソース（component resource）の集合体として扱う。したがって、多様なユーザが単一のデバイスを共有することが可能である。

ユーザ対話サブシステム２０６はユーザと対話し、リソース・マネージャ１２４により管理される近傍のデバイス上のリソースを、ユーザが予約することを可能とする。ユーザ対話サブシステム２０６は、リソース・マネージャのサービスを近傍のユーザに広告する。ユーザ対話サブシステム２０６は、ＳＬＰ、ブルートゥース（商標）規格、サン・マイクロシステムズ社のジニー（商標）技術、サリュテーション・コンソーシアムの技術などの規格化されたメカニズムを含む種々の技術を用いて広告する。

例えば、会議室に居るユーザは、会議室で利用可能なリソースを判定するため、および、その利用可能なリソースのうちの幾つかまたは全てを予約するために、ＰＤＡを用いて、ユーザ対話サブシステム２０６と通信する。

ユーザ対話サブシステム２０６は、例えば、近傍の全リソース、近傍の予約（reserved）リソース、近傍の利用可能なリソースなどに関する情報を記憶／検索するために、共有リソース・データベース２１２と通信する。さらに、ユーザ対話サブシステム２０６は、ユーザが予約を望むリソースの所有者によって設定されている、アクセス制御ポリシー、課金ポリシーなどを強制（enforce ）するために、リソース割当サブシステムと通信する
。

リソース・マネージャ１２４は、レンダリング・デバイス１２０ａ，１２０ｂなど、近傍１２８のデバイスと通信する。レンダリング・デバイス１２０ａは、例えば、他者に利用可能とすることをユーザが望まないリソースを有するデバイスである。そのようなデバイスを本明細書では「所有デバイス（owned device）」と称する。レンダリング・デバイス１２０ｂは、例えば、他者による使用に利用可能とされてよいリソースを有するデバイスである。そのようなデバイスを本明細書では「貸与可能デバイス（rentable device ）」と称する。レンダリング・デバイス１２０ａ，１２０ｂは各々、リソース・マネージャ・クライアント２３０ａ，２３０ｂをそれぞれ有する。リソース・マネージャ・クライアント２３０ａ，２３０ｂは、例えば、対応するレンダリング・デバイスが所有デバイスであるか貸与可能デバイスであるかによって、同一であってもよく、異なってもよい。リソース・マネージャ・クライアント２３０は、ユーザのリソースを要求するため、デバイスのリソースに関してリソース・マネージャ１２４に通知するため、リソースの現在の状態についてリソース・マネージャ１２４を更新するため、などのために、リソース・マネージャ１２４と対話する。

図４は、リソース・マネージャ・クライアント２３０によって実装され得る方法の一例のフローチャートである。方法２５０は、ＣＤ−ＲＯＭ、フロッピーディスク、ハードドライブ、デジタル多用途ディスク（ＤＶＤ）など有形の媒体上のソフトウェアまたはプロセッサに関連するメモリ上のソフトウェアにより設定されるプロセッサによって、実装されてよい。これに代えて、方法２５０の全体または部分が、周知の手法にて、プロセッサ以外のデバイスによって実行され得ること、またはファームウェアおよび専用のハードウェアのうちの少なくとも１つに組み込まれ得ること、またはそれらの両方であることを、当業者は容易に認めるであろう。さらに、この方法例は図４のフローチャートに関連して説明されているが、多くの他の方法が代わりに用いられてよいことを、当業者は容易に認めるであろう。例えば、ブロックの実行の順序が変更されてもよく、ブロックが変更、削除、または結合されてもよく、それらの両方であってもよい。

方法２５０は、リソース・マネージャ１２４およびマルチデバイス・プロクシ・サーバ１１２のうちの少なくとも１つに、リソース性能とレンダリング・リソースの利用可能性とのうちの少なくとも１つを報知するために用いられ得る。

ブロック２５４にて、レンダリング・デバイスの性能が判定される。例えば、デバイス性能は、システム・ソフトウェアに問い合わせること、一覧、レジストリ、データベースなどから読み出すこと、によって判定される。デバイス性能には、デバイスの型、デバイスのプロセッサ（例えば、型、速度など）、メモリ／記憶装置（例えば、型、サイズなど）、通信リンク（例えば、型、特定リンク用のプロクシ・サーバ、最大帯域幅など）、ディスプレイ（例えば、ディスプレイ・サイズ、ディスプレイ解像度、ディスプレイがカラー・ディスプレイか否か、ピクセルあたりのビット数など）、サウンド・システム（存在するか否か、型など）などに関する情報が含まれる。

ブロック２５８にて、リソース・マネージャ１２４およびマルチデバイス・プロクシ・サーバ１１２のうちの少なくとも１つによって、デバイス性能が登録される。例えば、所有デバイスは、マルチデバイス・プロクシ・サーバ１１２を用いてデバイス性能を登録し、貸与可能デバイスは、貸与可能デバイスが位置する近傍に関連するリソース・マネージャ１２４を用いてデバイス性能を登録する。デバイス性能は、コンポジット・ケイパビリティ／プリファレンス・プロファイル（Composite Capability/Preference Profiles）（ＣＣ／ＰＰ）フレームワーク、プロプライエタリなプロトコルなどの規格化されたメカニズムを含む、種々のメカニズムを用いて表現される。

ブロック２６２にて、デバイスの動的状態情報が判定される。例えば、デバイスの動的状態情報は、システム・ソフトウェアに問い合わせること、一覧、レジストリ、データベースなどから読み出すこと、によって判定される。例えば、動的状態情報には、デバイスのプロセッサ（例えば、現在の負荷、ユーザに利用可能な負荷など）、メモリ（例えば、利用率（utilization ）、利用可能な量など）、通信リンク（例えば、利用可能な帯域幅）、ディスプレイ（例えば、使用パーセンテージ、利用可能な最大ウインドー・サイズなど）、サウンド・システムの利用可能性（現在使用中か否か）などに関する情報が含まれる。

ブロック２６６にて、ブロック２６２で判定された動的状態情報が、リソース・マネージャ１２４およびマルチデバイス・プロクシ・サーバ１１２のうちの少なくとも１つに伝送されるべきか否かが判定される。例えば、動的状態情報は、デバイスの電源立ち上げ時、周期的、動的状態情報の変更時、などで伝送される。

動的状態情報が伝送される必要がない場合、フローはブロック２６２へ進む。動的状態情報が伝送されるべき場合、フローはブロック２７０へ進む。ブロック２７０にて、リソース・マネージャ１２４およびマルチデバイス・プロクシ・サーバ１１２のうちの少なくとも１つに、動的状態情報が伝送される。例えば、所有デバイスは、マルチデバイス・プロクシ・サーバ１１２に動的状態情報を伝送し、貸与可能デバイスは、貸与可能デバイスが位置する近傍に関連するリソース・マネージャ１２４に動的状態情報を伝送する。動的状態を表現するために、プロプライエタリなメカニズムが用いられてもよい。デバイスに動的状態情報を提供するＣＣ／ＰＰフレームワークのエクステンション（extension ）の一例は、以下である。

ここで、「CPU ... Load」は、中央処理装置（ＣＰＵ）の現在の負荷パーセンテージを示す、０〜１の間の数である。「CPU ... User」は、ユーザに利用可能なＣＰＵの負荷パーセンテージを示す、０〜１の間の数である。「Memory ... Utilization」は、現在のメモリ利用率を示す、０〜１の間の数である。「Memory ... Available」は、利用可能なメモ
リ量を示す数である。「Bandwidth 」は、通信リンク上でデバイスに利用可能な現在の帯域幅を示す数である。「Display ... Available 」は、利用可能なディスプレイのパーセンテージを示す、０〜１の間の数である。「Display . . . Max-rectangle 」は、ディスプレイ上でユーザに利用可能な最大矩形のピクセル寸法を与える。「Sound . . . Status」は、サウンド・システムが使用中か否かを示すテキスト値である。

ブロック２７０にて、動的状態情報の完全な一覧が送信される必要はない。例えば、動的状態情報を最後に伝送した時から、特定の動的状態情報だけが変化している場合、変化した動的状態情報だけが伝送されてもよい。

動的状態情報が伝送された後、フローはブロック２６２へ戻る。
図５は、リソース・マネージャ１２４によって実装され得る方法の一例である、方法３００のフローチャートである。詳細には、方法３００はリソース監視サブシステム２０８によって実装され得る。方法３００は、ＣＤ−ＲＯＭ、フロッピーディスク、ハードドライブ、デジタル多用途ディスク（ＤＶＤ）など有形の媒体上のソフトウェアまたはプロセッサに関連するメモリ上のソフトウェアにより設定されるプロセッサによって、実装されてよい。これに代えて、方法３００の全体または部分が、周知の手法にて、プロセッサ以外のデバイスによって実行され得ること、またはファームウェアおよび専用のハードウェアのうちの少なくとも１つに組み込まれ得ること、またはそれらの両方であることを、当業者は容易に認めるであろう。さらに、この方法例は図５のフローチャートに関連して説明されているが、多くの他の方法が代わりに用いられてよいことを、当業者は容易に認めるであろう。例えば、ブロックの実行の順序が変更されてもよく、ブロックが変更、削除、または結合されてもよく、それらの両方であってもよい。

方法３００は、特定近傍の貸与可能なレンダリング・デバイスから受信したデバイス性能および動的状態情報を処理するために用いられ得る。
ブロック３０４にて、レンダリング・デバイス１２０から受信した情報が新たなデバイスの登録に対応するか否かが判定される。新たなデバイスの登録である場合、フローはブロック３０８へ進む。ブロック３０８にて、新たなデバイスのデバイス性能が、１つ以上のリソースに変換される。ブロック３１２にて、ブロック３０８で判定された１つ以上のリソースが、リソース・レジストリに記憶される。リソース・レジストリは、例えば、１人以上のユーザによって予約および使用／共有され得る近傍のリソースを示してもよい。前の図３を参照すると、共有リソース・データベース２１２にリソース・レジストリが含まれてもよい。

ブロック３０４にて、受信情報は新たなデバイスの登録ではない、と判定された場合、フローはブロック３１６へ進む。ブロック３１６では、受信情報がレンダリング・デバイス１２０に対する動的状態情報に対応するか否かが判定される。動的状態情報に対応する場合、フローはブロック３２０へ進む。ブロック３２０にて、動的状態情報を用いて、リソース・レジストリの対応するリソース情報が更新される。

図６は、リソース・マネージャと対話するためにユーザが用いる所有レンダリング・デバイスのリソース・マネージャ・クライアント２３０によって実装され得る方法の一例である、方法３５０のフローチャートである。方法３５０は、ＣＤ−ＲＯＭ、フロッピーディスク、ハードドライブ、デジタル多用途ディスク（ＤＶＤ）など有形の媒体上のソフトウェアまたはプロセッサに関連するメモリ上のソフトウェアにより設定されるプロセッサによって、実装されてよい。これに代えて、方法３５０の全体または部分が、周知の手法にて、プロセッサ以外のデバイスによって実行され得ること、またはファームウェアおよび専用のハードウェアのうちの少なくとも１つに組み込まれ得ること、またはそれらの両方であることを、当業者は容易に認めるであろう。さらに、この方法例は図６のフローチ
ャートに関連して説明されているが、多くの他の方法が代わりに用いられてよいことを、当業者は容易に認めるであろう。例えば、ブロックの実行の順序が変更されてもよく、ブロックが変更、削除、または結合されてもよく、それらの両方であってもよい。

方法３５０は、リソース・マネージャ１２４を用いて近傍のレンダリング・デバイス１２０のリソースを予約するため、または予約取消（unreserve ）するため、またはその両方のために用いられて得る。リソースの予約／予約取消には、完全なリソースまたはリソースの一部分の予約／予約取消が含まれる。例えば、ユーザがディスプレイ・スクリーンの５０％を予約している場合、ユーザはそのリソースのうち半分を予約取消してもよく、したがって、ユーザにはディスプレイ・スクリーンの２５％が与えられる。

ブロック３５２にて、ユーザが追加のリソースを予約することを望むか否か、すなわちユーザがリソースを予約取消することを望むか否かが判定される。追加リソースを予約することをユーザが望む場合、フローはブロック３５４へ進む。

ブロック３５４にて、近傍の利用可能なリソースの指標に対する要求がリソース・マネージャ１２４に伝送される。ブロック３５６にて、近傍の利用可能なリソースの指標がリソース・マネージャ１２４から受信される。利用可能なリソースの指標には、例えば、リソースの一覧が含まれる。さらに、利用可能なリソースの指標によって、利用可能なリソースに関連するデバイスの指標が提供されてもよい。

ブロック３５８にて、ユーザは、ユーザが予約することを望む１つ以上のリソースを選択する。例えば、ユーザは、タッチスクリーン、キーパッド、スタイラス、マウスなどを用いて、リソースの一覧から特定のリソースを選択する。ブロック３６０にて、選択されたリソースがリソース・マネージャ１２４に伝送される。

ブロック３６２にて、ブロック３６０で送信された選択リソースをユーザが予約したことを、リソース・マネージャ１２４が確認したか否かが判定される。確認が受信された場合、フローはブロック３６４へ進む。ブロック３６４では、方法３５０を実装するレンダリング・デバイス１２０がマルチデバイス・プロクシ・サーバ１１２へ通知を送信し、ブロック３６０で選択された追加リソースを、ユーザに関連する利用可能なリソース・プールに追加すべきことを示す。これに代えて、後に説明するように、そうした通知をリソース・マネージャ１２４が送信してもよい。

ブロック３６２にて、選択リソースをユーザが予約したことを、リソース・マネージャ１２４が確認していないと判定された場合、フローはブロック３５８へ戻る。
ブロック３５２にて、ユーザがリソースを予約取消することを望むと判定された場合、フローはブロック３８０へ進む。ブロック３８０にて、ユーザに予約された近傍のリソースの指標に対する要求が、リソース・マネージャ１２４に伝送される。ブロック３８２にて、予約リソースの指標がリソース・マネージャ１２４から受信される。予約リソースの指標には、例えば、リソースの一覧が含まれる。さらに、予約リソースの指標によって、予約リソースに関連するデバイスの指標が提供されてもよい。

ブロック３８４にて、ユーザは、ユーザが予約取消することを望む１つ以上のリソースを選択する。例えば、ユーザは、タッチスクリーン、キーパッド、スタイラス、マウスなどを用いて、リソースの一覧から特定のリソースを選択する。ブロック３６８にて、選択されたリソースがリソース・マネージャ１２４に伝送される。

ブロック３８８にて、ブロック３８６で送信された選択リソースをユーザが予約取消したことを、リソース・マネージャ１２４が確認したか否かが判定される。確認が受信され
た場合、フローはブロック３９０へ進む。ブロック３９０では、方法３５０を実装するレンダリング・デバイス１２０がマルチデバイス・プロクシ・サーバ１１２へ通知を送信し、ブロック３８４で選択されたリソースをユーザに関連する利用可能なリソース・プールから取り除くべきことを示す。これに代えて、後に説明するように、そうした通知をリソース・マネージャ１２４が送信してもよい。

ブロック３８８にて、選択リソースをユーザが予約取消したことを、リソース・マネージャ１２４が確認していないと判定された場合、フローはブロック３８４へ戻る。
図７は、リソース・マネージャ１２４によって実装され得る方法の一例である、方法４００のフローチャートである。詳細には、方法４００はユーザ対話サブシステム２０６によって実装され得る。方法４００は、ＣＤ−ＲＯＭ、フロッピーディスク、ハードドライブ、デジタル多用途ディスク（ＤＶＤ）など有形の媒体上のソフトウェアまたはプロセッサに関連するメモリ上のソフトウェアにより設定されるプロセッサによって、実装されてよい。これに代えて、方法４００の全体または部分が、周知の手法にて、プロセッサ以外のデバイスによって実行され得ること、またはファームウェアおよび専用のハードウェアのうちの少なくとも１つに組み込まれ得ること、またはそれらの両方であることを、当業者は容易に認めるであろう。さらに、この方法例は図７のフローチャートに関連して説明されているが、多くの他の方法が代わりに用いられてよいことを、当業者は容易に認めるであろう。例えば、ブロックの実行の順序が変更されてもよく、ブロックが変更、削除、または結合されてもよく、それらの両方であってもよい。

方法４００は、ユーザの近傍のレンダリング・デバイス１２０のリソースを予約するため、または予約取消するため、またはその両方のために用いられ得る。
ブロック４０２にて、ユーザが追加リソースを予約することを望むか否か、すなわちユーザがリソースを予約取消することを望むか否かが判定される。追加リソースを予約することをユーザが望む場合、フローはブロック４０４へ進む。

ブロック４０４にて、特定の近傍の利用可能なリソースが判定される。これには、近傍に存在するリソースを判定することと、それに続いてそれらのうち利用可能なリソースを判定することとが含まれる。ユーザ対話サブシステム２０６は、共有リソース・データベース２１２に問い合わせることによって、近傍の利用可能なリソースを判定する。さらに、リソースが貸与可能なリソースの場合、ユーザ対話サブシステム２０６は、リソース割当サブシステム２０４によって強制される、アクセス制御ポリシー、課金ポリシーなどに基づいて、利用可能なリソースを判定する。

ブロック４０６にて、近傍の利用可能なリソースの指標がユーザの所有レンダリング・デバイス１２０に送信される。利用可能なリソースの指標には、例えば、リソースの一覧が含まれる。さらに、利用可能なリソースの指標によって、利用可能なリソースに関連するデバイスの指標が提供されてもよい。ブロック４０８にて、ユーザによって選択されたリソースの指標が受信される。

ブロック４１０にて、選択リソースが依然利用可能か否かが判定される。例えば、ユーザ対話サブシステム２０６は、共有リソース・データベース２１２に問い合わせることによって、選択リソースが依然利用可能か否かを判定する。選択リソースがもはや利用可能でない場合、フローはブロック４０６へ戻る。選択リソースが依然利用可能な場合、フローはブロック４１２へ進む。

ブロック４１２にて、選択リソースはユーザに対して予約される。例えば、ユーザ対話サブシステム２０６は、選択リソースがユーザに予約されていることを示すように、共有リソース・データベース２１２を修正する。

ブロック４１４にて、ユーザに確認が送信されて、選択リソースが予約されたことを確認する。ブロック４１６では、リソース・マネージャ１２４がマルチデバイス・プロクシ・サーバ１１２へ通知を送信し、ブロック４１２で予約した追加リソースをユーザに関連する利用可能なリソース・プールに追加すべきことを示す。これに代えて、先に説明したように、そうした通知をレンダリング・デバイスが送信してもよい。

ブロック４０２にて、ユーザがリソースを予約取消することを望むと判定された場合、フローはブロック４３０へ進む。ブロック４３０にて、近傍のユーザによって現在予約されているリソースが判定される。例えば、リソース割当サブシステム２０４は、共有リソース・データベース２１２に問い合わせることによって、近傍のユーザに予約されたリソースを判定する。

ブロック４３２にて、近傍の予約リソースの指標がユーザの所有レンダリング・デバイス１２０に送信される。予約リソースの指標には、例えば、リソースの一覧が含まれる。さらに、予約リソースの指標によって、予約リソースに関連するデバイスの指標が提供されてもよい。ブロック４３４にて、ユーザによって選択されたリソースの指標が受信される。

ブロック４３６にて、選択リソースは予約取消される。例えば、リソース割当サブシステム２０４は、選択リソースがユーザによって予約取消されており、他のユーザに利用可能とされたことを示すように、共有リソース・データベース２１２を修正する。

ブロック４４０にて、ユーザに確認が送信されて、選択リソースが予約取消されたことを確認する。ブロック４４２では、リソース・マネージャ１２４がマルチデバイス・プロクシ・サーバ１１２へ通知を送信し、ブロック４３６で予約取消したリソースをユーザに関連する利用可能なリソース・プールから取り除くべきことを示す。これに代えて、先に説明したように、そうした通知をレンダリング・デバイスが送信してもよい。

マルチデバイス・プロクシ・サーバ：
上述のように、典型的には、マルチデバイス・プロクシ・サーバ１１２は、マルチデバイス通信環境においてユーザに対するプロクシとして機能する。単なる一特定例としては、マルチデバイス・プロクシ・サーバ１１２は、ワイヤレス・アプリケーション・プロトコル（wireless application protocol ）（ＷＡＰ）プロクシ・サーバに対するエクステンションとして実装される。マルチデバイス・プロクシ・サーバ１１２は、パーソナル・コンピュータ、ワークステーション、サーバ、メインフレームなど、１つ以上のコンピュータを有する。

図８は、マルチデバイス・プロクシ・サーバ１１２の一例のブロック図であり、レンダリング・デバイス１２０を含む他のシステムとの対話の一例を示している。図８を図１に関連して説明する。

マルチデバイス・プロクシ・サーバ１１２は、配信制御サブシステム５０４を有する。配信制御サブシステムは、通信エージェント５０８を介して、レンダリング・デバイス１２０およびリソース・マネージャ１２４など他のシステムと通信する。通信エージェント５０８は、リソース・マネージャ１２４の通信エージェント２１６と同一であってもよく、同様であってもよい。

さらに、マルチデバイス・プロクシ・サーバ１１２は、ユーザ・プリファレンス・データベース５１２、ユーザ・リソース・データベース５１６、およびセッション状態データ
ベース５２０を有する。配信制御サブシステム５０４は、それらのデータベースの各々にデータを記憶し、各々からデータを読み出す。

ユーザ・プリファレンス・データベース５１２には、マルチデバイス上でのコンテンツのレンダリングにおけるユーザのプリファレンスに関する情報が含まれる。ユーザ・プリファレンス・データベース５１２には、例えば、一定の型のコンテンツのレンダリングに優先するデバイス（例えば映像は、携帯電話ではなく、フル・サイズのディスプレイを備えるコンピュータ上でレンダリングされることが好適である）、優先するコンテンツ分配（例えば、２つの異なる音声ストリームでは、同一のデバイスではなく異なるデバイスを経由させることを優先する）、優先する配信ネットワーク（例えば、携帯電話に配信されるデータは、無線ＬＡＮネットワークではなく携帯電話ネットワークを介して配信されることを優先する）に関する情報が含まれる。

ユーザ・リソース・データベース５１６には、特定ユーザに利用可能なリソースに関する情報が含まれる。例えば、特定ユーザが所有ＰＤＡを有し、デスクトップ・コンピュータのディスプレイを予約していることが、ユーザ・リソース・データベース５１６に記憶される。

セッション状態データベース５２０には、特定ユーザのセッションの状態に関する情報が含まれる。この情報には、例えば、配信されている、または配信されるべきコンテンツの型（例えば、テキスト、映像、音声）が含まれる。コンテンツ型情報には、コンテンツのフォーマットに関する情報（例えば、映像データ・レート、ステレオ音声かモノラル音声か）も含まれる。セッション状態データベース５２０には、使用されるリモート・デバイスのアドレス、そのデバイス上で使用されるポート番号など、トランスポート層に関する情報も含まれる。

マルチデバイス・プロクシ・サーバ１１２は、さらに、例えば、コンテンツのレンダリングを容易にするために、アプリケーションをレンダリング・デバイスにダウンロードする、アプリケーション・ダウンローダーを有する。アプリケーション・ダウンローダー５２４は、配信制御サブシステム５０４によって制御される。

さらに、マルチデバイス・プロクシ・サーバ１１２は、トランスコーダ・インタフェース５２８を有する。トランスコーダ・インタフェース５２８は、ローカル・トランスコーダ５３２（任意）と１つ以上の外部トランスコーダとに対するインタフェースを、配信制御サブシステム５０４に提供する。トランスコーダ・インタフェース５２８は、シンプル・オブジェクト・アクセス・プロトコル（Simple Object Access Protocol ）（ＳＯＡＰ）、コモン・ゲートウェイ・インタフェース（Common Gateway Interface）（ＣＧＩ）、サン・マイクロシステムズ社のリモート・メソッド・インヴォケーション（Remote Method Invocation）（ＲＭＩ）技術、インターネット・コンテンツ・アダプテーション・プロトコル（Internet Content Adaptation Protocol）（ＩＣＡＰ）など、リモート・プロシージャ呼出用の規格化されたメカニズムを含む種々のプロトコルを介して、外部トランスコーダと通信する。

コンテンツ転送プロトコル・プロクシ５３６には、異なるプロトコルに対応する１つ以上の異なるプロクシが含まれる。例えば、コンテンツ転送プロトコル・プロクシ５３６には、ＨＴＴＰプロクシ、リアル・タイム・プロトコル（ＲＴＰ）プロクシ、リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）プロクシなどが含まれる。コンテンツ転送プロトコル・プロクシ５３６には、コンテンツ型に従ってコンテンツをパースするためのパーサーも含まれる。コンテンツ型には、例えば、マルチパーパス・インターネット・メール・エクステンション（multipurpose internet mail extensions ）（ＭＩＭＥ）型が
含まれる。コンテンツ型には、例えば、注釈ファイルを用いて、例えば、コンテンツの著作者によって規定される型も含まれる。例えば、コンテンツの一定部分が、一定の人物、一定のデバイスによって視聴されることが可能であるように、コンテンツが認可されてもよい。

一般には、コンテンツ転送プロトコル・プロクシ５３６は、一ユーザに宛てられたコンテンツを受信し、そのコンテンツをコンテンツ型にパースし、続いて、配信制御サブシステム５０４の制御下で、そのコンテンツを１つ以上のレンダリング・デバイス１２０に配信する。例えば、コンテンツ転送プロトコル・プロクシ５３６は、テキストおよびグラフィックをレンダリング・デバイス１２０ａに配信し、音声をレンダリング・デバイス１２０ｂに配信する。さらに、コンテンツ転送プロトコル・プロクシ５３６は、トランスコーダ・インタフェース５２８の制御下で、トランスコーダ（例えば、ローカル・トランスコーダ５３２または外部トランスコーダ）へコンテンツを送信し、トランスコーダからコンテンツを受信する。さらに、コンテンツ転送プロトコル・プロクシ５３６は、セッションの状態に関する情報を、セッション状態データベース５２０に記憶する。例えば、コンテンツ転送プロトコル・プロクシ５３６は、ユーザに要求されたコンテンツ・セッションの異なるコンテンツ型に関する情報を記憶する。

マルチデバイス・プロクシ・サーバ１１２は、レンダリング・デバイス１２０ａ，１２０ｂ，１２０ｃ（図８には示さず）などのレンダリング・デバイスと通信する。レンダリング・デバイス１２０ａ，１２０ｃは、例えば、所有デバイスであり、レンダリング・デバイス１２０ｂは、例えば、貸与可能デバイスである。レンダリング・デバイス１２０ａ，１２０ｂ，１２０ｃには、各々、それぞれのマルチデバイス・プロクシ・クライアント５５０が含まれる。マルチデバイス・プロクシ・クライアント５５０は、各レンダリング・デバイスに対して同一であってもよく、例えば、対応するデバイスが所有デバイスか貸与可能デバイスかによって、異なってもよい。所有デバイス上のマルチデバイス・プロクシ・クライアント５５０は、例えば、ユーザに利用可能なリソースをマルチデバイス・プロクシ・サーバ１１２に通知するため、ユーザに利用可能な特定デバイスへのコンテンツ配信に関するユーザ・プリファレンスをマルチデバイス・プロクシ・サーバ１１２に通知するため、コンテンツのレンダリングを容易にするアプリケーションのダウンロードを調整するため、などのために、マルチデバイス・プロクシ・サーバ１１２と対話する。さらに、マルチデバイス・プロクシ・クライアント５５０は、コンテンツのレンダリングを容易にするために、レンダリング・デバイス１２０上で、アプリケーション５６２などのアプリケーションを起動する。例えば、マルチデバイス・プロクシ・クライアント５５０は、レンダリング・デバイス１２０に映像コンテンツが配信されること、または配信され始めたことを感知して、レンダリング・デバイス１２０上で映像再生アプリケーションを起動する。

図９は、マルチデバイス・プロクシ・サーバ１１２によって実装され得る方法の一例である、方法５７０のフローチャートである。方法５７０は、ＣＤ−ＲＯＭ、フロッピーディスク、ハードドライブ、デジタル多用途ディスク（ＤＶＤ）など有形の媒体上のソフトウェアまたはプロセッサに関連するメモリ上のソフトウェアにより設定されるプロセッサによって、実装されてよい。これに代えて、方法５７０の全体または部分が、周知の手法にて、プロセッサ以外のデバイスによって実行され得ること、またはファームウェアおよび専用のハードウェアのうちの少なくとも１つに組み込まれ得ること、またはそれらの両方であることを、当業者は容易に認めるであろう。さらに、この方法例は図９のフローチャートに関連して説明しているが、多くの他の方法が代わりに用いられてよいことを、当業者は容易に認めるであろう。例えば、ブロックの実行の順序が変更されてもよく、ブロックが変更、削除、または結合されてもよく、それらの両方であってもよい。

ブロック５７２にて、ユーザからコンテンツ要求が受信される。この要求はコンテンツ・サーバに宛てられてもよい。ブロック５７４にて、一覧のにエントリ（entry ）が作成されるが、このエントリは要求を送信したユーザに対応している。このエントリには、マルチデバイス・プロクシ・サーバ１１２が要求コンテンツを受信する時に、そのコンテンツに対応するユーザを判定可能な情報が含まれてもよい。そうした情報の例には、ユーザ要求をユニークに（uniquely）識別し得るセッション識別子、要求が受信されたポート番号、ユーザをユニークに（uniquely）識別し得るユーザ識別子などが含まれる。

ブロック５７６にて、コンテンツ・サーバがマルチデバイス・プロクシ・サーバ１１２に要求コンテンツを送信するように、要求は再フォーマットされる。例えば、要求者のアイデンティティ（identity）は、ユーザのデバイスから、マルチデバイス・プロクシ・サーバ１１２に変更される。続いて、ブロック５７８にて、再フォーマットされた要求がコンテンツ・サーバに送信される。

図１０は、マルチデバイス・プロクシ・サーバ１１２によって実装され得る方法の別例である、方法５８４のフローチャートである。方法５８４を図９に関連して説明する。方法５８４は、ＣＤ−ＲＯＭ、フロッピーディスク、ハードドライブ、ＤＶＤなど有形の媒体上のソフトウェアまたはプロセッサに関連するメモリ上のソフトウェアにより設定されるプロセッサによって、実装されてよい。これに代えて、方法５８４の全体または部分が、周知の手法にて、プロセッサ以外のデバイスによって実行され得ること、またはファームウェアおよび専用のハードウェアのうちの少なくとも１つに組み込まれ得ること、またはそれらの両方であることを、当業者は容易に認めるであろう。さらに、この方法例は図１０のフローチャートに関連して説明されているが、多くの他の方法が代わりに用いられてよいことを、当業者は容易に認めるであろう。例えば、ブロックの実行の順序が変更されてもよく、ブロックが変更、削除、または結合されてもよく、それらの両方であってもよい。

ブロック５８６にて、ユーザに要求されたコンテンツがコンテンツ・サーバから受信される。例えば、このコンテンツは、図９のブロック５７８でコンテンツ・サーバへ送信された、再フォーマットされた要求に応じる。ブロック５８８にて、コンテンツを要求したユーザが判定される。例えば、図９のブロック５７４でユーザのエントリを作成した一覧を調査することによって、ユーザが判定される。

ブロック５９０にて、要求コンテンツを処理して、コンテンツに含まれる異なるコンテンツ型（テキスト、グラフィック、映像、音声など）を判定する。
ブロック５９２にて、ユーザに利用可能なリソースに対する、ブロック５９０で判定されたコンテンツ型のマッピングが決定される。利用可能なリソースがマルチデバイス上に存在してもよい。さらに、マルチデバイスには、近傍のデバイスや、リモート・デバイスも含まれてよい。ブロック５９４にて、ブロック５９２で決定されたマッピングに従って、マルチデバイスにコンテンツ型が送信される。

図１１は、配信制御サブシステム５０４の一例のブロック図である。図１１を図８に関連して説明する。配信制御サブシステムには、ユーザ・リソース・マネージャ６０４，マッピング・ジェネレータ６１０，セッション・オーケストレータ（orchestrator）６２０が含まれる。一般に、ユーザ・リソース・マネージャ６０４は、通信エージェント５０８を介して、ユーザに利用可能なリソースに関する情報を、所有レンダリング・デバイス１２０またはリソース・マネージャ１２４から受信する。この情報は、ユーザ・リソース・データベース５１６を更新するために用いられる。さらに、ユーザ・リソース・マネージャ６０４は、ユーザ・プリファレンスに関する情報を所有レンダリング・デバイス１２０から受信し、この情報をユーザ・プリファレンス・データベース５１２に記憶する。

一般に、マッピング・ジェネレータ６１０は、ユーザ・プリファレンス・データベース５１２からユーザ・プリファレンス情報を受信し、ユーザ・リソース・データベース５１６からユーザに利用可能なリソースに関する情報を受信し、セッション状態データベース５２０からユーザに要求されたコンテンツに関する情報を受信する。マッピング・ジェネレータ６１０が、それらの情報に基づいて、ユーザに利用可能なデバイスに対するコンテンツ型のマッピングを生成する。このデバイス・マッピングが、セッション・オーケストレータ６２０に与えられる。

一般に、セッション・オーケストレータ６２０はマッピング・ジェネレータ６１０からデバイス・マッピングを受信し、セッション状態データベース５２０からコンテンツ型情報を受信する。この情報に基づいて、セッション・オーケストレータ６２０は、アプリケーション・ダウンローダー５２４，トランスコーダ・インタフェース５２８，コンテンツ転送プロトコル・プロクシ５３６を制御するための制御情報を生成する。

ユーザ・リソース・マネージャ：
図１２は、マルチデバイス・プロクシ・サーバ１１２によって実装され得る方法の一例のフローチャートである。詳細には、方法６５０はユーザ・リソース・マネージャ６０４によって実装され得る。方法６５０は、ＣＤ−ＲＯＭ、フロッピーディスク、ハードドライブ、デジタル多用途ディスク（ＤＶＤ）など有形の媒体上のソフトウェアまたはプロセッサに関連するメモリ上のソフトウェアにより設定されるプロセッサによって、実装されてよい。これに代えて、方法６５０の全体または部分が、周知の手法にて、プロセッサ以外のデバイスによって実行され得ること、またはファームウェアおよび専用のハードウェアのうちの少なくとも１つに組み込まれ得ること、またはそれらの両方であることを、当業者は容易に認めるであろう。さらに、この方法例は図１２のフローチャートに関連して説明されているが、多くの他の方法が代わりに用いられてよいことを、当業者は容易に認めるであろう。例えば、ブロックの実行の順序が変更されてもよく、ブロックが変更、削除、または結合されてもよく、それらの両方であってもよい。

所有レンダリング・デバイスから情報を受信すると、方法６５０が実装され得る。例えば、図４に関連して説明したように、マルチデバイス・プロクシ・サーバ１１２は、デバイスのリソースおよび性能を示す情報を所有レンダリング・デバイスから受信する。方法６５０は、図５に関連して説明した、方法３００と同様である。

ブロック６５２にて、ユーザのアイデンティティが判定される。ユーザのアイデンティティに関する情報（例えば、名前、ユーザ識別情報（identification）、ログイン・ネームなど）は、所有レンダリング・デバイスからの受信情報に含まれている。さらに、ユーザ・リソース・マネージャ６０４は、所有デバイス１２０にメッセージを送信し、ユーザのアイデンティティに関する情報（例えば、名前、ユーザ識別情報、ログイン・ネーム、パスワードなど）をユーザに提出させてもよい。

ブロック６５４にて、所有レンダリング・デバイス１２０から受信された情報が新たなデバイスの登録に対応するか否かが判定される。新たなデバイスの登録である場合、フローはブロック６５８へ進む。ブロック６５８にて、新たなデバイスのデバイス性能は１つ以上のリソースに変換される。ブロック６６２にて、ブロック６５８で判定された１つ以上のリソースが、ユーザに関連するリソース・レジストリに記憶される。リソース・レジストリは、例えば、ユーザに利用可能なリソースを示す。前の図８を参照すると、リソース・レジストリは共有リソース・データベース５１６に含まれてもよい。

ブロック６５４にて、受信情報が新たなデバイスの登録ではないと判定された場合、フ
ローはブロック６６８へ進む。ブロック６６８では、受信情報が所有レンダリング・デバイス１２０の動的状態情報に対応するか否かが判定される。動的状態情報に対応する場合、フローはブロック６７０へ進む。ブロック６７０にて、動的状態情報は、ユーザに関連するリソース・レジストリの対応するリソース情報を更新するために用いられる。

図１３は、マルチデバイス・プロクシ・サーバ１１２によって実装され得る方法の一例のフローチャートである。詳細には、方法７００はユーザ・リソース・マネージャ６０４によって実装され得る。方法７００は、ＣＤ−ＲＯＭ、フロッピーディスク、ハードドライブ、デジタル多用途ディスク（ＤＶＤ）など有形の媒体上のソフトウェアまたはプロセッサに関連するメモリ上のソフトウェアにより設定されるプロセッサによって、実装されてよい。これに代えて、方法７００の全体または部分が、周知の手法にて、プロセッサ以外のデバイスによって実行され得ること、またはファームウェアおよび専用のハードウェアのうちの少なくとも１つに組み込まれ得ること、またはそれらの両方であることを、当業者は容易に認めるであろう。さらに、この方法例は図１３のフローチャートに関連して説明されているが、多くの他の方法が代わりに用いられてよいことを、当業者は容易に認めるであろう。例えば、ブロックの実行の順序が変更されてもよく、ブロックが変更、削除、または結合されてもよく、それらの両方であってもよい。

ユーザに利用可能なデバイスの追加または取り除きに関する情報を受信すると、方法７００が実装され得る。例えば、図６，７に関連して説明したように、マルチデバイス・プロクシ・サーバ１１２は、追加リソースが利用可能であること、またはリソースがもはや利用可能でないことを示す情報を、所有レンダリング・デバイスまたはリソース・マネージャ１２４から受信する。

ブロック７０４にて、ユーザのアイデンティティが判定される。ブロック７０４は、図１２のブロック６５２と同様の手法によって実装されてよい。ブロック７０８にて、追加リソースがユーザに利用可能か否かが判定される。追加リソースがユーザに利用可能である場合、フローはブロック７１２へ進む。ブロック７１２にて、ユーザに関連するリソース・レジストリに、追加リソースが追加される。

ブロック７０８にて、追加リソースが利用可能でないと判定された場合、ブロック７１６にて、ユーザに利用可能であったリソースはもはや利用可能でないか否かが判定される。リソースがもはや利用可能でない場合、フローはブロック７２０へ進む。ブロック７２０にて、ユーザに関連するリソース・レジストリから、ユーザにもはや利用可能でないリソースが取り除かれる。

ユーザ・プリファレンス：
再び図８，１１を参照すると、ユーザ・プリファレンス・データベース５１２からの情報は、デバイスに対するコンテンツ型のマッピングを生成するために、マッピング・ジェネレータ６１０によって用いられ得る。ユーザ・プリファレンス情報は、１つ以上の標準設定（default configuration ）に基づいてユーザに指定されてもよく、または、例えば、ユーザがマルチデバイス・プロクシ・サーバ１１２の使用を登録する時、マルチデバイス・プロクシ・サーバ１１２を介してコンテンツを要求する際、などに、ユーザから獲得されてもよい。ユーザ・プリファレンス情報は、例えば、ユーザの要求の際、まだユーザがプリファレンス情報を提供していないコンテンツの型を受信する際、まだユーザがプリファレンス情報を提供していない特定デバイスまたはデバイス型を用いる際、などに、修正される。

データベース５１２に記憶されたユーザ・プリファレンス情報は、種々のフォーマットで表現される。例えば、ユーザ・プリファレンス情報は効用関数のフォーマットで表現さ
れる。効用関数のフォーマットでのユーザ・プリファレンス情報の例を、図１４，１５，１６に関連して説明する。説明を容易にするため、表のフォーマットで示した特定の例を説明する。

図１４は、特定の型のコンテンツをレンダリングするために優先するデバイスに関する、ユーザ・プリファレンスを表現するフォーマットの一例を示す表である。詳細には、図１４は、特定デバイスにコンテンツの型を配信することに関するユーザ・プリファレンスを表現する表の一例である、表８００を示す。

表８００の行は、特定デバイスまたはデバイスの型に対応し、表８００の列は、コンテンツ型（テキスト、グラフィック、映像、音声など）に対応する。デバイスの一覧には、現在ユーザに利用可能なデバイス、過去にユーザが使用したデバイスの一覧、ユーザに指定されたデバイスの一覧、標準のデバイスの一覧、などが含まれる。

特定デバイスに配信される特定型のコンテンツの効用は、ある範囲の数として表現される。図１４の例では、この範囲は両端も含む０〜１０の間で、値０は最小の効用を示し、値１０は最大の効用を示す。表８００の例では、テキストのコンテンツをＰＤＡに配信することによって大きな効用が与えられるのに対し、グラフィックをＰＤＡに配信することによって、より小さな効用が与えられ、映像または音声をＰＤＡに配信することによって最小の効用が与えられることが示される。例えば、ＰＤＡのディスプレイはテキストを表示するには適切であるが、ＰＤＡ上では映像の品質は低い。同様に、ＰＤＡには音声システムは含まれていない。

図１５は、特定の型のデバイスに対してコンテンツを配信するために優先する通信リンクに関する、ユーザ・プリファレンスを表現するフォーマットの一例を示す表である。詳細には、図１５は、特定デバイスにコンテンツを配信するために優先する通信リンクに関するユーザ・プリファレンスを表現する表の一例である、表８４０を示す。

表８４０の行は、特定デバイスまたはデバイスの型に対応し、表８４０の列は、特定通信リンクまたは通信リンクの型（例えば、無線ＬＡＮ（ＷＬＡＮ）、ゼネラル・パケット・ラジオ・サービス（general packet radio service）（ＧＰＲＳ）ネットワークなど）に対応する。デバイスの一覧には、現在ユーザに利用可能なデバイス、過去にユーザが使用したデバイスの一覧、ユーザに指定されたデバイスの一覧、標準のデバイスの一覧、などが含まれる。リンクの一覧には、現在ユーザに利用されているリンク、過去にユーザが使用したリンクの一覧、ユーザに指定されたリンクの一覧、標準のリンクの一覧、などが含まれる。

特定通信リンクを用いて特定デバイスにコンテンツを配信することの効用は、ある範囲の数として表現される。図１５の例では、この範囲は両端も含む０〜１０の間で、値０は最小の効用を示し、値１０は最大の効用を示す。表８４０の例では、ＧＰＲＳリンクを介して携帯電話にコンテンツを配信することによって、ＷＬＡＮリンクを介するよりも大きな効用が与えられることが示される。さらに、表８４０の例では、ＷＬＡＮリンクを介してＰＤＡまたはラップトップ・コンピュータにコンテンツを配信することによって、ＧＰＲＳリンクを介するよりも大きな効用が与えられることが示される。

図１６は、同一のデバイスまたは異なるデバイスに対してコンテンツが配信されるべきか否かに関する、ユーザ・プリファレンスを表現するフォーマットの一例を示す表である。詳細には、図１６は、１つ以上のコンテンツ・セッションの成分が同一または異なるデバイスに配信されるべきか否かに関するユーザ・プリファレンスを表現する表の一例である、表８６０を示す。例えば、１つの動画に対応する映像および音声を単一のデバイスを
介して同期させることの方が、２つのデバイスに分配された映像および音声を同期させること、すなわち、映像および音声の間にわずかな遅延時間しか持たせずに２つのデバイス上でその音声および映像を視聴しなければならないことよりも容易である。

表８６０の行および列は、１つ以上のコンテンツ・セッションの特定の成分に対応する。図１６の例では、末尾によって、成分が属するセッションが示される（すなわち、「キャプション（caption ）１」、「音声１」、「映像１」は第１のコンテンツ・セッションの成分であり、「音声２」は、第１のコンテンツ・セッションと異なる第２のコンテンツ・セッションの成分である）。成分の一覧には、ユーザが配信を要求したセッションの成分、可能な成分の一覧、標準の成分の一覧などが含まれる。

同一のデバイスを介して別の成分として配信されている成分の効用は、ある範囲の数として表現される。図１６の例では、この範囲は両端も含む０〜１００の間で、値０は最小の効用を示し、値１００は最大の効用を示す。さらに、同一のデバイスを介して成分が配信されないことに対する強いプリファレンスを表現するために、大きな負の数（例えば、−１００）が用いられる。

表８６０の例では、第１のセッションの音声および映像成分（すなわち、音声１および映像１）が同一のデバイスに配信される場合、大きな効用が示される。さらに、表８６０では、第１のセッションのキャプションおよび映像成分（すなわち、キャプション１および映像１）が同一のデバイスに配信される場合、それより小さな効用が示される。同様に、表８６０では、第１のセッションのキャプションおよび音声成分（すなわち、キャプション１および音声１）が同一のデバイスに配信される場合、小さな効用が示される。さらに、表８６０では、第１のセッションの成分が配信されているデバイスと同一のデバイスに、第２のセッションの音声成分（すなわち、音声２）が配信されないような、強いプリファレンスが示される。

上述の効用関数表現の例では表のフォーマットで説明したが、効用関数表現が種々のフォーマットで与えられることを当業者は認めるであろう。さらに、上述の例では特定の数値および範囲を説明したが、異なる実装では種々の値および範囲を利用し得ることを当業者は認めるであろう。

さらに、上述では効用関数表現においてユーザ・プリファレンスを説明したが、ユーザ・プリファレンスが他の方法で表現されてもよいことを当業者は認めるであろう。さらに、他の型のユーザ・プリファレンスも用いられてよい。例えば、プリファレンスはデバイス性能に基づく。例えば、ユーザは、モノラル音声性能しか有しないデバイスよりも、ステレオ音声性能を有するデバイス上で音声をレンダリングすることを優先する。さらに、プリファレンスがコンテンツに含まれる情報の性質に基づいてもよい。例えば、大量のテキストを表示するには、ＰＤＡよりもデスクトップ・コンピュータが好適である。さらに、共有ディスプレイがＰＤＡよりも適切にコンテンツをレンダリングし得る場合であっても、ユーザが他者に視聴させたくない一定の情報は、共有ディスプレイ上ではなくユーザのＰＤＡ上で表示することが好適な場合がある。

マッピング・ジェネレータ：
再び図８，１１を参照すると、一般に、マッピング・ジェネレータ６１０は、ユーザ・プリファレンスデータベース５１２からユーザ・プリファレンス情報を受信し、ユーザ・リソース・データベース５１６からユーザに利用可能なリソースに関する情報を受信し、およびセッション状態データベース５２０からユーザに要求されたコンテンツに関する情報を受信する。マッピング・ジェネレータ６１０は、これらの情報に基づいて、ユーザに利用可能なデバイスに対するコンテンツ型のマッピングを生成する。このマッピングには
、特定の通信リンク（例えば、ＷＬＡＮリンクかＧＰＲＳリンクか）を介してコンテンツを配信するための情報も含まれる。

図１７は、配信制御サブシステム５０４によって実装され得る方法の一例のフローチャートである。詳細には、方法９００はマッピング・ジェネレータ６１０によって実装され得る。図８，１１に関連して方法９００を説明する。方法９００は、ＣＤ−ＲＯＭ、フロッピーディスク、ハードドライブ、デジタル多用途ディスク（ＤＶＤ）など有形の媒体上のソフトウェアまたはプロセッサに関連するメモリ上のソフトウェアにより設定されるプロセッサによって、実装されてよい。これに代えて、方法９００の全体または部分が、周知の手法にて、プロセッサ以外のデバイスによって実行され得ること、またはファームウェアおよび専用のハードウェアのうちの少なくとも１つに組み込まれ得ること、またはそれらの両方であることを、当業者は容易に認めるであろう。さらに、この方法例は図１７のフローチャートに関連して説明されているが、多くの他の方法が代わりに用いられてよいことを、当業者は容易に認めるであろう。例えば、ブロックの実行の順序が変更されてもよく、ブロックが変更、削除、または結合されてもよく、それらの両方であってもよい。

ブロック９０４にて、特定セッションに対するコンテンツ型情報が受信される。コンテンツ型情報は、例えば、セッション状態データベース５２０から受信される。コンテンツ型情報は、例えば、特定セッションが、テキスト、映像、および音声を含むことを示す。

ブロック９０８にて、セッションに関連するユーザに利用可能なリソースの指標が受信される。例えば、利用可能なリソースの一覧がユーザ・リソース・データベース５１６から受信される。例として、携帯電話上の音声システムおよびディスプレイシステムとラップトップ・コンピュータ上のディスプレイ・システムとが利用可能なリソースに含まれることが、リソースの一覧によって示される。さらに、携帯電話およびラップトップ・コンピュータの両方でＷＬＡＮおよびＧＰＲＳリンクが利用可能であることが、リソースの一覧によって示される。

ブロック９１２にて、ユーザ・プリファレンス情報が、例えば、ユーザ・プリファレンス・データベース５１２から受信される。図１４〜１６に関連して説明したように、ユーザ・プリファレンス情報は１つ以上の効用関数表現として表現される。

ブロック９１６にて、最良の効用値は初期化される。例えば、非常に低い効用を反映するために、最良の効用値は初期化される。ブロック９２０にて、ユーザに利用可能なデバイスおよび通信リンクに対するそのセッションのコンテンツ型の、多様な可能なマッピングが生成される。例えば、可能なマッピングの全てが生成される。そのセッションのコンテンツ型は、ブロック９０４にて受信された情報によって示される。ユーザに利用可能なデバイスおよび通信リンクは、ブロック９０８にて受信された情報によって判定される。多様な可能なマッピングは、例えば、可能なマッピング一覧として生成される。

ブロック９２４にて、ブロック９２０で生成された可能なマッピングのうちの１つが選択される。例えば、ブロック９２０で可能なマッピングの一覧が生成される場合、一覧の最初のマッピングが選択される。これに代えて、マッピングのうちの１つがランダムまたは擬似ランダムに選択される、一覧の最後のマッピングが選択される、などしてもよい。

ブロック９２８にて、選択されたマッピングの効用値が生成される。効用値は、例えば、ブロック９１２で受信された１つ以上の効用関数表現に従って、生成される。ブロック９３２にて、ブロック９２８で生成された効用値が最良の効用値と比較される。ブロック９３２にて、ブロック９２８で生成された効用値が現在の最良の効用値より大きな効用を
示す場合、フローはブロック９３６へ進む。ブロック９３６にて、ブロック９２８で生成された効用値が新たな最良の効用値として記憶される。さらに、新たな最良の効用値に対応するマッピングの指標が記憶される。ブロック９３２にて、ブロック９２８で生成された効用値が現在の最良の効用値より大きな効用を示さない場合、フローはブロック９４０へ進む。

ブロック９４０にて、ブロック９２０で生成された全てのマッピングが試行されたか否かが判定される。全てのマッピングが試行されていない場合、ブロック９４４にて新たなマッピングが選択されて、フローはブロック９２８へ戻る。ブロック９４０にて、全てのマッピングが試行されたと判定された場合、フローはブロック９４８へ進む。ブロック９４８にて、セッション・オーケストレータ６２０に最良のマッピングが与えられる。

図１８は、配信制御サブシステム５０４によって実装され得る方法の別例のフローチャートである。詳細には、方法９６０はマッピング・ジェネレータ６１０によって実装され得る。図８，１１に関連して方法９６０を説明する。方法９６０は、ＣＤ−ＲＯＭ、フロッピーディスク、ハードドライブ、ＤＶＤなど有形の媒体上のソフトウェアまたはプロセッサに関連するメモリ上のソフトウェアにより設定されるプロセッサによって、実装されてよい。これに代えて、方法９６０の全体または部分が、周知の手法にて、プロセッサ以外のデバイスによって実行され得ること、またはファームウェアおよび専用のハードウェアのうちの少なくとも１つに組み込まれ得ること、またはそれらの両方であることを、当業者は容易に認めるであろう。さらに、この方法例は図１８のフローチャートに関連して説明されているが、多くの他の方法が代わりに用いられてよいことを、当業者は容易に認めるであろう。例えば、ブロックの実行の順序が変更されてもよく、ブロックが変更、削除、または結合されてもよく、それらの両方であってもよい。

方法９６０には、図１７の方法９００と同一のブロックが多く含まれる。例えば、ブロック９０４，９０８，９１２，９１６，９２８，９３２，９３６，９４８は同一である。
ブロック９６４にて、可能なマッピングがランダムまたは擬似ランダムに決定される。ブロック９６８にて、全てのマッピングが試行されたか否かが判定される。一例として、全ての可能なマッピングが試行されたか否かが判定される。別例として、所定の数のマッピングが試行されたか否か、すなわちブロック９６４が所定の回数呼び出されたか否かが判定される。

マッピング・ジェネレータ６１０（図１１）が、セッションの間に１回以上呼び出されてもよい。例えば、ユーザに要求されたコンテンツを最初に受信することに応じて、マッピング・ジェネレータ６１０が呼び出される。さらに、セッションの間、追加リソースがユーザに利用可能となった時またはユーザに割り当てられたリソースが利用可能でなくなった時に、マッピング・ジェネレータ６１０が呼び出されてもよい。さらに、ユーザが近傍から退出する時または新たな近傍に進入する時に、マッピング・ジェネレータ６１０が呼び出されてもよい。近傍への進入または近傍からの退去は、例えば、ユーザが近傍の変更をマルチデバイス・プロクシ・サーバ１１２に通知することによって、手動で検出される。さらに、近傍への進入または近傍からの退去は、例えば、ユーザ・デバイスのリソース・マネージャ１２４との対話を介すること、広域測位システム（例えば、全地球測位システム（global positioning system ）（ＧＰＳ）、ロラン−Ｃ・システムなど）、局所的測位システム（例えば、室内位置検出システム（in-building location system ）など）などの位置検出システムを介すること、などによって自動的に検出されてもよい。

セッション・オーケストレータ：
再び図８，１１を参照すると、一般に、セッション・オーケストレータ６２０は、マッピング・ジェネレータ６１０からのユーザ・マッピング情報と、現在のセッションのコン
テンツの型に関する情報とを受信する。続いて、セッション・オーケストレータ６２０は、マッピング情報に従って、適切な通信リンクを介して適切なレンダリング・デバイスに種々の型のコンテンツが配信されるように、コンテンツ転送プロトコル・プロクシを制御するための制御信号を生成する。以下でより詳細に説明するように、セッション・オーケストレータ６２０は、アプリケーション・ダウンローダー５２４を制御するための制御信号、およびトランスコーダ・インタフェース５２８を介してトランスコーダ（ローカル・トランスコーダまたは外部トランスコーダ）を制御するための制御信号も生成する。

図１９は、配信制御サブシステム５０４によって実装され得る方法の一例のフローチャートである。詳細には、方法１０００はセッション・オーケストレータ６２０によって実装され得る。図８，１１に関連して方法１０００を説明する。方法１０００は、ＣＤ−ＲＯＭ、フロッピーディスク、ハードドライブ、デジタル多用途ディスク（ＤＶＤ）など有形の媒体上のソフトウェアまたはプロセッサに関連するメモリ上のソフトウェアにより設定されるプロセッサによって、実装されてよい。これに代えて、方法１０００の全体または部分が、周知の手法にて、プロセッサ以外のデバイスによって実行され得ること、またはファームウェアおよび専用のハードウェアのうちの少なくとも１つに組み込まれ得ること、またはそれらの両方であることを、当業者は容易に認めるであろう。さらに、この方法例は図１９のフローチャートに関連して説明されているが、多くの他の方法が代わりに用いられてよいことを、当業者は容易に認めるであろう。例えば、ブロックの実行の順序が変更されてもよく、ブロックが変更、削除、または結合されてもよく、それらの両方であってもよい。

ブロック１００４にて、マッピング情報、ユーザ・リソース情報、およびコンテンツ型情報が、それぞれ、マッピング・ジェネレータ６１０、ユーザ・リソース・データベース５１６、およびセッション状態データベース５２０から受信される。ブロック１００８にて、そのセッションのコンテンツ型から第１のコンテンツ型が選択される。ブロック１０１２にて、そのコンテンツ型に対応するリソース／デバイスが存在することをマッピングが示すか否かが判定される。対応するリソース／デバイスが存在しない場合、フローはブロック１０１６へ進む。ブロック１０１６にて、リソース／デバイスが利用可能でないコンテンツ型のコンテンツが記憶される。例えば、そのコンテンツ型をレンダリングするためのリソースが利用可能となるまで、一時的にコンテンツが記憶される。続いて、フローはブロック１０２０へ進み、そのセッションに他のコンテンツ型がまだ残っているか否かが判定される。そのセッションの全てのコンテンツ型が取扱われた場合、フローは終了する。他のコンテンツがまだ残っている場合、フローはブロック１０２４へ進む。ブロック１０２４にて、そのセッションの次のコンテンツ型が選択されて、フローはブロック１０１２へ戻る。

ブロック１０１２にて、そのコンテンツ型に対応するマッピングされたデバイスが存在すると判定された場合、フローはブロック１０２８へ進む。ブロック１０２８にて、コンテンツ型が対応するマッピングされたリソースが、その現在のフォーマットでコンテンツ型をレンダリングすることが可能であるか否かが判定される。例えば、音声コンテンツがＭＰ３フォーマットであるのに対し、マッピングによって選択されたデバイスの音声リソースは異なるフォーマットでしか音声を取扱うことが可能でない場合がある。マッピングされたリソースがその現在のフォーマットでコンテンツ型をレンダリングすることが可能な場合、フローはブロック１０３２へ進む。ブロック１０３２にて、コンテンツ転送プロトコル・プロクシ５３６は、ブロック１００４で受信されたマッピング情報によって示されるデバイスにコンテンツ型を配信するように制御される。

ブロック１０２８にて、マッピングされたリソースが、その現在のフォーマットでコンテンツ型をレンダリングすることが可能でないと判定された場合、フローはブロック１０
３６へ進む。ブロック１０３６にて、マッピングされたデバイスが、その現在のフォーマットでコンテンツ型をレンダリングすることを可能とするソフトウェア・ダウンロードを、受信することが可能であるか否かが判定される。例えば、デバイスがダウンロードを受信する性能を有さない場合がある。また、デバイスのユーザが、そうしたダウンロードを許可することに同意しない場合もある。さらに、その現在のフォーマットでコンテンツ型をレンダリングすることをデバイスに可能とするソフトウェア・ダウンロードが、利用可能でない場合もある。マッピングされたデバイスがソフトウェア・ダウンロードを受信することが可能な場合、フローはブロック１０４０へ進む。

ブロック１０４０にて、アプリケーション・ダウンローダー５２４は、マッピングされたデバイスにアプリケーション・ソフトウェアをダウンロードするように制御される。さらに、ダウンロードされたアプリケーションを介してデバイスのリソースが変更されたことを反映するために、ユーザ・リソース・データベース５１６が更新される。続いて、フローはブロック１０３２へ進む。

ブロック１０３６にて、デバイスがアプリケーション・ダウンロードを受信することが可能でないと判断される場合、フローはブロック１０４４へ進む。ブロック１０４４にて、トランスコーダを用いて、コンテンツ型の現在のフォーマットを、マッピングされたリソースによってレンダリングされることが可能な新たなフォーマットに変換するように、トランスコーダ・インタフェース５２８が制御される。トランスコーダ・インタフェース５２８が、コンテンツ転送プロトコル・プロクシに、コンテンツ型をトランスコーダ（ローカルまたは外部）へ送信させ、コンテンツ転送プロトコル・プロクシは、トランスコーダから新たなフォーマットのコンテンツ型を受信する。続いて、フローはブロック１０３２へ進む。

マルチデバイス・レンダリング用のユーザ・インタフェース・メカニズム：
幾つかの例では、マルチデバイス・プロクシ・サーバ１１２は、ユーザ・インタフェース・メカニズムを用いてコンテンツを修正する。ユーザ・インタフェース・メカニズムは、マルチデバイス上でレンダリングされているコンテンツを解釈およびナビゲートすることによって、ユーザを補助する。図２０は、そうしたユーザ・インタフェース・メカニズムを提供するためのサブシステムの一例である、サブシステム１１００のブロック図である。一例のサブシステム１１００によって提供される特定のユーザ・インタフェース・メカニズムは、「ワームホール（wormhole）」と称される。そのようなユーザ・インタフェース・メカニズムを実装するためのシステムのさらなる詳細は、「マルチデバイスを介してレンダリングされるマルチメディア・コンテンツをリンクする方法および装置」と題された、米国特許出願第１０／３３４，８４８号（代理人整理番号：ＣＳ２０６９３ＲＬ）に与えられている。一般に、ワームホールは、ユーザのデバイス上でレンダリングされるコンテンツ内の、アイコンまたは他の標識であり、コンテンツのその部分は取り除かれて異なるデバイス上にあること、または異なるデバイス上でレンダリング可能であることをユーザに示す。ワームホールによって、この取り除かれたコンテンツの元のコンテンツのコンテキスト（context ）をユーザに理解させることが可能である。さらに、取り除かれたコンテンツをレンダリングする、またはユーザに示すために、ユーザがワームホール・メカニズムを用いる場合もある。例えば、画像が取り除かれたウェブ・ページをＰＤＡ上で視聴しているユーザが、ＰＤＡ上でワームホールを作動させて、取り除かれた画像を共有ディスプレイ上に点灯させることが可能である。

説明を容易にするため、ワームホール・サブシステム１１００をウェブ・ページのコンテキストで説明する。さらに、図８に関連して、ワームホール・サブシステム１１００を説明する。

ワームホール・サブシステム１１００は、完全または部分的に、マルチデバイス・プロクシ・サーバ１１２の構成要素であってもよく、分離したシステムとして実装されてもよい。一般には、ワームホール・サブシステム１１００は、マルチデバイス上でレンダリングするためにトランスコードされているコンテンツを受信し、続いて、そのトランスコードされているコンテンツがユーザ・インタフェース・メカニズム（ワームホール）を含むように修正する。さらに、ワームホール・サブシステム１１００は、ワームホールが作動されたことの指標を受信し、作動に応答するようにレンダリング・デバイス１２０上のワームホール・クライアントに命令する。例えば、ユーザは、テキストおよびワームホールがＰＤＡ上に現れ、イメージ（image ）がデスクトップ・コンピュータ上に現れるようにレンダリングされたウェブ・ページを視聴する。ユーザがＰＤＡを介してワームホールを作動させると、ワームホール・サブシステム１１００は、ワームホールに関連するイメージを表示しているデスクトップ・コンピュータに、そのイメージを明滅させるように命令する。

ワームホール・サブシステムには、ワームホール・インサータ（inserter）１１０４、ワームホール・データベース１１０８、およびワームホール・マネージャ１１１２が含まれる。ワームホール・インサータ１１０４がローカル・トランスコーダ５３２の構成要素であってもよい。ワームホール・インサータ１１０４は要求されたコンテンツの第１のサブセットを受信し、ワームホールを含む修正されたコンテンツの第１のサブセットを生成する。

図２１は、ワームホール・インサータ１１０４によって実装され得る方法の一例のフローチャートである。方法１１４０は、ＣＤ−ＲＯＭ、フロッピーディスク、ハードドライブ、デジタル多用途ディスク（ＤＶＤ）など有形の媒体上のソフトウェアまたはプロセッサに関連するメモリ上のソフトウェアにより設定されるプロセッサによって、実装されてよい。これに代えて、方法１１４０の全体または部分が、周知の手法にて、プロセッサ以外のデバイスによって実行され得ること、またはファームウェアおよび専用のハードウェアのうちの少なくとも１つに組み込まれ得ること、またはそれらの両方であることを、当業者は容易に認めるであろう。さらに、この方法例は図２１のフローチャートに関連して説明されているが、多くの他の方法が代わりに用いられてよいことを、当業者は容易に認めるであろう。例えば、ブロックの実行の順序が変更されてもよく、ブロックが変更、削除、または結合されてもよく、それらの両方であってもよい。

ブロック１１４４にて、要求されたコンテンツの第１のサブセットが受信される。例えば、ユーザに要求されたウェブ・ページは、コンテンツ型（例えば、テキスト、グラフィックなど）に分割されていてもよい。コンテンツの第１のサブセットは、要求されたウェブ・ページのテキストを含むがグラフィックのうちの多くを含まない、第１のトランスコードされたウェブ・ページに対応する。コンテンツの第２のサブセットは、第１のトランスコードされたウェブ・ページから欠落しているグラフィックを含む、第２のトランスコードされたウェブ・ページに対応する。

ブロック１１４８にて、第１のサブセットから欠落している当初要求されたコンテンツのうち幾らかまたは全てが判定される。例えば、第１のウェブ・ページから欠落しているグラフィックが判定される。

ブロック１１５２にて、欠落コンテンツに対応するワームホールがコンテンツの第１のサブセットに挿入される。ワームホールには、ワームホールが対応するコンテンツの指標が含まれる。さらに、ワームホールには、欠落コンテンツがレンダリングされている、またはレンダリングされるべき、レンダリング・デバイスの指標が含まれてもよい。これらの指標は、ワームホール自身に含まれてもよく、ワームホール・データベース１１０８に
記憶されてもよい。

例えば、第１のウェブ・ページから欠落しており第２のウェブ・ページに含まれるグラフィックに対応するワームホールが、第１のウェブ・ページに挿入される（inserted）。このワームホールに、第２のウェブ・ページに対応するコンテンツの指標と、第２のウェブ・ページがレンダリングされているデバイスの指標とが含まれてもよい。

ワームホールには、例えば、ボタン、リンク、アイコンなどが含まれる。ワームホールに、取り除かれたコンテンツまたはコンテンツ型の指標が含まれてもよい。例えば、画像が取り除かれた場合、ワームホールには、画像が取り除かれたことを示すアイコン、画像を説明するテキスト、などが含まれる。

さらに、ワームホール・インサータ１１０４が、挿入されたワームホールに関する情報をワームホール・データベース１１０８に記憶してもよい。ワームホール情報には、例えば、関連する欠落コンテンツの指標、欠落コンテンツがレンダリングされているまたはレンダリングされるデバイス、などが含まれる。これに代えて、この情報のうち幾らかまたは全てが、ワームホール自身にエンコードされて（encoded ）もよい。

ユーザがレンダリング・デバイス１２０上でワームホールを作動させる（例えば、ワームホールを選択する、ワームホールをクリックするなどによって）と、レンダリング・デバイス１２０は、マルチデバイス・プロクシ・サーバ１１２へワームホール選択の指標を伝送する。この指標には、ワームホール・サブシステム１１００に、選択されたワームホールをワームホール・データベース１１０８で判定させることが可能な情報が含まれる。これに代えて、指標には、ワームホール・サブシステム１１００に、選択されたワームホールが関連する欠落コンテンツおよび、欠落コンテンツがレンダリングされているまたはレンダリングされるレンダリング・デバイス１２０を判定させることが可能な情報が含まれてもよい。

レンダリング・デバイス１２０は、例えば、マルチデバイス・プロクシ・サーバ１１２のコンテンツ転送プロトコル・プロクシ５３６または通信エージェント５０８に、指標を伝送する。

図２２は、ワームホール・マネージャ１１１２によって実装され得る方法の一例のフローチャートである。方法１１７０は、ＣＤ−ＲＯＭ、フロッピーディスク、ハードドライブ、デジタル多用途ディスク（ＤＶＤ）など有形の媒体上のソフトウェアまたはプロセッサに関連するメモリ上のソフトウェアにより設定されるプロセッサによって、実装されてよい。これに代えて、方法１１７０の全体または部分が、周知の手法にて、プロセッサ以外のデバイスによって実行され得ること、またはファームウェアおよび専用のハードウェアのうちの少なくとも１つに組み込まれ得ること、またはそれらの両方であることを、当業者は容易に認めるであろう。さらに、この方法例は図２２のフローチャートに関連して説明されているが、多くの他の方法が代わりに用いられてよいことを、当業者は容易に認めるであろう。例えば、ブロックの実行の順序が変更されてもよく、ブロックが変更、削除、または結合されてもよく、それらの両方であってもよい。

ブロック１１７４にて、ワームホール選択の指標が受信される。この指標は、例えば、マルチデバイス・プロクシ・サーバ１１２のコンテンツ転送プロトコル・プロクシ５３６または通信エージェント５０８を介して、受信される。

ブロック１１７８にて、ワームホールが対応するコンテンツが決定される。さらに、この対応するコンテンツをレンダリングしているまたはレンダリングするべきデバイスが決
定される。例えば、ワームホール・マネージャ１１１２は、ワームホール自身を介してまたはワームホールデータベース１１０８を介して、ワームホールが対応する欠落コンテンツと、欠落コンテンツがレンダリングされることになる、すなわちレンダリングされるべきレンダリング・デバイス１２０とを決定する。

ブロック１１８２にて、対応するコンテンツをレンダリングしているまたはレンダリングしているべきデバイスは、ワームホールが対応するコンテンツを示すように命令される。例えば、コンテンツがレンダリングされている場合、レンダリング・デバイス１２０は、そのコンテンツを明滅させるように命令されてもよく、そのコンテンツの周囲に輪郭を生成してもよく、そのコンテンツの下方または上方にキャプションを現してもよく、そのキャプションを明滅させてもよい。レンダリング・デバイス上でまだコンテンツがレンダリングされていない場合、ワームホール・マネージャ１１１２は、そのコンテンツを適切なレンダリング・デバイスへ送信させてレンダリングさせる。

本発明には種々の修正および代替の構成が可能であるが、本発明の一定の実施態様を図面に示し、本明細書にて詳細に説明している。しかしながら、開示した特定の形態に開示を限定する意図はなく、反対に、添付の特許請求の範囲によって定義される開示の精神および範囲内にある全ての修正、代替構成、および均等物を包含することを意図するものである。

マルチデバイス上でレンダリングするためにコンテンツをマルチデバイスに配信することが可能であるシステムの一例のブロック図。 マルチデバイス上でレンダリングするためにコンテンツをマルチデバイスに配信する方法の一例のフローチャート。 一例のリソース・マネージャが他のシステムと対話する一例を示すブロック図。 リソース・マネージャ・クライアントによって実装され得る方法の一例のフローチャート。 リソース・マネージャによって実装され得る方法の一例のフローチャート。 所有レンダリング・デバイスのリソース・マネージャ・クライアントによって実装され得る方法の一例のフローチャート。 リソース・マネージャによって実装され得る方法の一例のフローチャート。 一例のマルチデバイス・プロクシ・サーバが他のシステムと対話する一例を示すブロック図。 マルチデバイス・プロクシ・サーバによって実装され得る方法の一例のフローチャート。 マルチデバイス・プロクシ・サーバによって実装され得る方法の別例のフローチャート。 配信制御サブシステムの一例のブロック図。 マルチデバイス・プロクシ・サーバによって実装され得る方法の一例のフローチャート。 マルチデバイス・プロクシ・サーバによって実装され得る方法の一例のフローチャート。 特定型のコンテンツをレンダリングするために優先するデバイスに関するユーザ・プリファレンスを表現するフォーマットの一例を示す表。 特定型のデバイスにコンテンツを配信するために優先する通信リンクに関するユーザ・プリファレンスを表現するフォーマットの一例を示す表。 同一のデバイスまたは異なるデバイスにコンテンツが配信されるべきか否かに関するユーザ・プリファレンスを表現するフォーマットの一例を示す表。 配信制御サブシステムによって実装され得る方法の一例のフローチャート。 配信制御サブシステムによって実装され得る方法の別例のフローチャート。 配信制御サブシステムによって実装され得る方法の一例のフローチャート。 マルチデバイス上でレンダリングされているコンテンツを解釈およびナビゲートすることでユーザを補助し得るユーザ・インタフェース・メカニズムを提供するためのサブシステムの一例のブロック図。 図２０のサブシステムの例によって実装され得る方法の一例のフローチャート。 図２０のサブシステムの例によって実装され得る方法の一例のフローチャート。

Claims (7)

1. 複数のデバイスによってレンダリングされるコンテンツを配信する方法であって、
   マルチデバイス・プロクシ・サーバが、ユーザに利用可能なリソースの指標をリソース・マネージャから受信するステップと、前記リソースの指標はコンテンツをレンダリングすることの可能なレンダリング・リソースに関する情報を含み、前記レンダリング・リソースは複数のデバイスによって提供され、前記複数のデバイスの各デバイスはネットワークに接続され、前記複数のデバイスのうち少なくとも１つのデバイスは前記ユーザによる使用に利用可能な少なくとも１つのレンダリング・リソースを提供しかつ別のユーザによる同時の使用に利用可能な少なくとも１つのレンダリング・リソースを提供することと、
   マルチデバイス・プロクシ・サーバが、前記ユーザによって要求されたコンテンツを受信するステップと、前記コンテンツは複数のコンテンツ型を含むことと、前記コンテンツ型のうちの１つは第１のフォーマットであることと、
   マルチデバイス・プロクシ・サーバが、前記複数のデバイスに対するコンテンツ型のマッピングを決定するステップと、前記マッピングは前記リソースの指標および前記コンテンツ型の種類に基づくことと、
   マルチデバイス・プロクシ・サーバが、前記ユーザによって要求された前記コンテンツのコンテンツ型を前記マッピングに従って前記複数のデバイスに配信するステップと、前記コンテンツのコンテンツ型はネットワークを介して複数のデバイスに配信されることと、
   マルチデバイス・プロクシ・サーバが、前記１つのコンテンツ型がマッピングされているデバイスは前記第１のフォーマットを処理することが可能であるか否かを判定するステップと、
   マルチデバイス・プロクシ・サーバが、前記１つのコンテンツ型がマッピングされているデバイスが前記第１のフォーマットを処理することが不可能であると判定した場合、前記第１のフォーマットを処理することが可能であるアプリケーションを前記１つのコンテンツ型がマッピングされている前記デバイスにダウンロードするステップとから成る方法。
2. 前記マッピングを決定するステップにおいて、さらにマッピングはユーザのプリファレンスに基づく請求項１に記載の方法。
3. 前記プリファレンスは、効用関数と、同一のセッションのコンテンツのコンテンツ型を単一のデバイスに配信するか否かに関するプリファレンスと、異なるセッションのコンテンツのコンテンツ型を単一のデバイスに配信するか否かに関するプリファレンスと、コンテンツのコンテンツ型を前記複数のデバイスに配信するための通信リンクに関するプリファレンスとのうち少なくとも１つを含む請求項２に記載の方法。
4. 複数のデバイスによってレンダリングされるコンテンツを配信するためのマルチデバイス・プロクシ・サーバであって、
   第１のネットワークを介してコンテンツ・サーバと操作可能に接続されかつ第２のネットワークを介して複数のレンダリング・デバイスと操作可能に接続されたコンピュータを備え、前記複数のレンダリング・デバイスのうち少なくとも１つはユーザの使用に利用可能な少なくとも１つのレンダリング・リソースを提供し、かつ別のユーザの同時の使用に利用可能な少なくとも１つのレンダリング・リソースを提供し、
   前記コンピュータは、メモリと、前記メモリに接続されたプロセッサとを有し、
   前記プロセッサは、
   ユーザに利用可能なレンダリング・リソースの指標を受信することであって、前記レンダリング・リソースの指標はコンテンツをレンダリングすることの可能なレンダリング・リソースに関する情報を含む前記複数のレンダリング・デバイスによって提供されることと、
   前記ユーザによって要求されたコンテンツを受信することであって、前記コンテンツは複数のコンテンツ型を含み、前記コンテンツは前記第１のネットワークを介して前記コンテンツ・サーバから受信されることと、前記コンテンツ型のうちの１つは第１のフォーマットであることと、
   前記複数のデバイスに対するコンテンツ型のマッピングを決定することであって、前記マッピングは前記リソースの指標および前記コンテンツ型の種類に基づくことと、
   前記ユーザによって要求された前記コンテンツのコンテンツ型を前記マッピングに従って前記複数のデバイスに配信することであって、前記コンテンツのコンテンツ型は前記第２のネットワークを介して前記複数のデバイスに配信されることと、
   前記１つのコンテンツ型がマッピングされているデバイスは前記第１のフォーマットを処理することが可能であるか否かを判定することと、
   前記１つのコンテンツ型がマッピングされているデバイスが前記第１のフォーマットを処理することが不可能であると判定した場合、前記第１のフォーマットを処理することが可能であるアプリケーションを前記１つのコンテンツ型がマッピングされている前記デバイスにダウンロードすることとを実行するように構成されている、マルチデバイス・プロクシ・サーバ。
5. 複数のデバイス上でレンダリングするために前記マルチデバイスにコンテンツを配信するためのマッピングを決定する方法であって、
   マルチデバイス・プロクシ・サーバが、ユーザによって要求され、かつ複数のコンテンツ型を含むコンテンツを受信する受信ステップと、前記コンテンツ型のうちの１つは第１のフォーマットであることと、
   マルチデバイス・プロクシ・サーバが、前記コンテンツをレンダリングするために前記ユーザに利用可能なリソースのセットを決定するセット決定ステップであって、リソースの前記セットは、複数のレンダリング・デバイスによって提供されるセット決定ステップと、
   マルチデバイス・プロクシ・サーバが、前記コンテンツを配信するためのユーザ・プリファレンスを判定する判定ステップであって、前記ユーザ・プリファレンスは単一のデバイスまたは複数のデバイスに対して前記コンテンツを配信するか否かに関するプリファレンス情報を含む判定ステップと、
   マルチデバイス・プロクシ・サーバが、前記ユーザに利用可能なリソースの前記セット、前記コンテンツ型の種類および前記ユーザ・プリファレンスに基づいて前記複数のレンダリング・デバイスに対する前記コンテンツの複数のコンテンツ型のマッピングを決定するマッピング決定ステップと、
   マルチデバイス・プロクシ・サーバが、前記１つのコンテンツ型がマッピングされているデバイスは前記第１のフォーマットを処理することが可能であるか否かを判定するステップと、
   マルチデバイス・プロクシ・サーバが、前記１つのコンテンツ型がマッピングされているデバイスが前記第１のフォーマットを処理することが不可能であると判定した場合、前記第１のフォーマットを処理することが可能であるアプリケーションを前記１つのコンテンツ型がマッピングされている前記デバイスにダウンロードするステップとから成る方法。
6. 前記ユーザ・プリファレンスは、効用関数と、同一のセッションのコンテンツのコンテンツ型を単一のデバイスに配信するか複数のデバイスに配信するかに関するプリファレンス情報と、異なるセッションのコンテンツのコンテンツ型を単一のデバイスに配信するか複数のデバイスに配信するかに関するプリファレンス情報と、前記複数のデバイスにコンテンツのコンテンツ型を配信するための通信リンクに関するプリファレンス情報とのうち少なくとも１つを含む請求項５に記載の方法。
7. 複数のデバイス上でレンダリングするために前記複数のデバイスにコンテンツを配信するためのマッピングを決定する方法であって、
   マルチデバイス・プロクシ・サーバが、ユーザによって要求され、かつ複数のコンテンツ型を含むコンテンツを受信する受信ステップと、前記コンテンツ型のうちの１つは第１のフォーマットであることと、
   マルチデバイス・プロクシ・サーバが、コンテンツをレンダリングするために前記ユーザに利用可能なリソースのセットを決定するセット決定ステップであって、リソースのセットは、複数のレンダリング・デバイスによって提供されるセット決定ステップと、
   マルチデバイス・プロクシ・サーバが、コンテンツを配信するためのユーザ・プリファレンスを判定する判定ステップであって、前記ユーザ・プリファレンスは複数のデバイスにコンテンツを配信するために優先する通信リンクに関するプリファレンス情報を含む判定ステップと、
   マルチデバイス・プロクシ・サーバが、前記ユーザに利用可能なリソースのセット、前記コンテンツ型の種類およびユーザ・プリファレンスに基づいて複数のレンダリング・デバイスに対するコンテンツの複数のコンテンツ型のマッピングを決定するマッピング決定ステップと、
   マルチデバイス・プロクシ・サーバが、前記１つのコンテンツ型がマッピングされているデバイスは前記第１のフォーマットを処理することが可能であるか否かを判定するステップと、
   マルチデバイス・プロクシ・サーバが、前記１つのコンテンツ型がマッピングされているデバイスが前記第１のフォーマットを処理することが不可能であると判定した場合、前記第１のフォーマットを処理することが可能であるアプリケーションを前記１つのコンテンツ型がマッピングされている前記デバイスにダウンロードするステップとから成る方法。

Images