(57)【要約】  ユニバーサルプラグアンドプレイ（ＵＰｎＰ）ネットワーク内のメディアサーバに、レンダリングデバイスへのメディアリソース情報の配布を決定するリソース共有サービスが含まれる。メディアサーバに、クランプドダウンユーザコンテキスト（例えば、ローカルサービスユーザコンテキスト）で動作する、ネットワークを介してリソース情報を共有するように構成されたメディアサービスモジュールと；ローカルシステムユーザコンテキストで動作し、ネットワークを介するリソース情報の共有でメディアサービスモジュールを支援するように構成された補足モジュールと；ログオンしたユーザのコンテキストで動作し、ユーザインターフェースディスプレイを介してユーザと相互作用するように構成されたコントロールパネルモジュールが含まれる。ローカルシステムユーザコンテキストは、クランプドダウンユーザコンテキストと比較して、メディアサーバリソースへのより高いレベルのアクセスを提供する。メディアサーバは、複数のユーザが同時に保留中のコントロールパネルモジュールのめいめいのインスタンスを有することを可能にする高速ユーザ切替（ＦＵＳ）機能性も提供する。さらに、メディアサーバに、ならず者アプリケーションがコントロールパネルモジュールに成りすますのを防ぎ、これによってメディアサービスモジュールへの許可されないアクセスを得るのを防ぐ機構が含まれる。【特許請求の範囲】
【請求項１】
ネットワークを介してリソース情報を散布するサーバであって、
第１ユーザコンテキストで動作し、前記ネットワークを介してリソース情報を共有するように構成されているメディアサービスモジュールと、
第２ユーザコンテキストで動作し、前記ネットワークを介するリソース情報の共有で前記メディアサービスモジュールを支援するように構成されている補足モジュールと
を含むことを特徴とするサーバ。
【請求項２】
前記ネットワークは、ユニバーサルプラグアンドプレイ（ＵＰｎＰ）ネットワークとして構成されていることを特徴とする請求項１に記載のサーバ。
【請求項３】
第３ユーザコンテキストで動作し、ユーザと相互作用するように構成されているコンフィギュレーションおよびコントロールパネルモジュールをさらに含むことを特徴とする請求項１に記載のサーバ。
【請求項４】
前記第１ユーザコンテキストは、前記サーバによって提供されるリソースへのアクセスの関連する第１レベルを提供するクランプドダウンユーザコンテキストであり、
前記第２ユーザコンテキストは、前記サーバによって提供されるリソースへのアクセスの関連する第２レベルを提供するローカルシステムユーザコンテキストであり、アクセスの前記第２レベルは、アクセスの前記第１レベルより高い
ことを特徴とする請求項１に記載のサーバ。
【請求項５】
第３ユーザコンテキストで動作し、ユーザと相互作用するように構成されているコンフィギュレーションおよびコントロールパネルモジュールをさらに含み、前記第３ユーザコンテキストは、前記サーバにログオンしたユーザに関連するアクセスのレベルを提供するログオンしたユーザのコンテキストであることを特徴とする請求項４に記載のサーバ。
【請求項６】
前記クランプドダウンコンテキストは、ローカルサービスユーザコンテキストであることを特徴とする請求項４に記載のサーバ。
【請求項７】
前記クランプドダウンコンテキストは、ネットワークサービスユーザコンテキストであることを特徴とする請求項４に記載のサーバ。
【請求項８】
前記メディアサービスモジュールは、前記ネットワークを介して共有される共有リソースを識別するストアを含むことを特徴とする請求項１に記載のサーバ。
【請求項９】
前記ストアは、複数のリポジトリを含むことを特徴とする請求項８に記載のサーバ。
【請求項１０】
前記複数のリポジトリは、前記サーバによってアクセス可能な別々のドライブに対応することを特徴とする請求項９に記載のサーバ。
【請求項１１】
前記ストアは、前記共有リソースに関連するリソースメタデータを含むことを特徴とする請求項８に記載のサーバ。
【請求項１２】
前記ストアは、リソースとは別々にそれに関連するリソースメタデータを提供し、その結果、前記リソースメタデータに簡単にアクセスできるようになっていることを特徴とする請求項１１に記載のサーバ。
【請求項１３】
前記メディアサービスモジュールは、さらに、関連するリソースの変化の際に前記ストア内の前記リソースメタデータを更新するように構成されているロジックを含むことを特徴とする請求項１２に記載のサーバ。
【請求項１４】
前記ストアは、前記ネットワークを介するリソース情報の前記配布を決定する少なくとも１つの配布判断基準を含むことを特徴とする請求項８に記載のサーバ。
【請求項１５】
前記ストアは、前記リソースメタデータおよび前記少なくとも１つの配布判断基準をストアするために２つの別々のストアを割り当てることを特徴とする請求項１４に記載のサーバ。
【請求項１６】
前記ストアは、前記リソースメタデータおよび前記少なくとも１つの配布判断基準をストアするために単一のストアを割り当てることを特徴とする請求項１４に記載のサーバ。
【請求項１７】
前記メディアサービスモジュールは、前記ユーザがメンバリソースをリソースフォルダ内で編成することを可能にするように構成されていることを特徴とする請求項１に記載のサーバ。
【請求項１８】
前記メディアサービスモジュールは、前記リソースフォルダ内の前記メンバリソースを少なくとも１つのリソースコンテナに再編成するように構成されていることを特徴とする請求項１７に記載のサーバ。
【請求項１９】
前記メディアサービスモジュールは、前記ユーザが少なくとも１つの配布判断基準を前記フォルダリソースに関連付けることを可能にするように構成されていることを特徴とする請求項１７に記載のサーバ。
【請求項２０】
前記リソース情報は、リソースメタデータを含み、前記メディアサービスモジュールは、ブラウズ要求または検索要求に応答して前記ネットワークを介して前記リソースメタデータをサービスするコンテンツディレクトリサービスモジュールを含むことを特徴とする請求項１に記載のサーバ。
【請求項２１】
前記コンテンツディレクトリサービスモジュールは、前記ブラウズ要求または前記検索要求に応答して、少なくとも１つの配布判断基準が満足されることを条件として、前記リソースメタデータを共有するように構成されていることを特徴とする請求項２０に記載のサーバ。
【請求項２２】
前記リソース情報は、リソースコンテンツを含み、前記メディアサービスモジュールは、リソースコンテンツ要求に応答して前記ネットワークを介して前記リソースコンテンツをサービスするリソース転送モジュールを含むことを特徴とする請求項１に記載のサーバ。
【請求項２３】
前記リソース転送モジュールは、リソースコンテンツをサービスするＨＴＴＰサーバであり、前記リソースコンテンツ要求は、ＨＴＴＰ要求であることを特徴とする請求項２２に記載のサーバ。
【請求項２４】
前記リソース転送モジュールは、リソースコンテンツ要求に応答して、少なくとも１つの配布判断基準が満足されることを条件として、前記リソースコンテンツを共有するように構成されていることを特徴とする請求項２２に記載のサーバ。
【請求項２５】
前記メディアサービスモジュールは、共有リソース情報を受信することを許可される受信側エンティティの表示をストアするように構成され、前記メディアサービスモジュールは、前記ストアされた表示に従ってリソース情報を散布するように構成されていることを特徴とする請求項１に記載のサーバ。
【請求項２６】
前記メディアサービスモジュールは、
リソースはリムーバブルメモリ媒体にストアされることと、
前記リソースは前記サーバに関して前記ネットワーク上でリモートにあることと、
前記リソースの共有を試みているユーザは前記リソースへのアクセスの許可を有しないことと、
前記リソースは隠しファイルまたは隠しサブフォルダにストアされていることと、
前記リソースは前記サーバが共有するように構成されているメディアタイプの所定のリストに従わないメディアタイプを有するファイルにストアされていることと
という条件の少なくとも１つが真である場合に、前記リソースに対応するリソース情報の前記共有を禁止するように構成されていることを特徴とする請求項１に記載のサーバ。
【請求項２７】
前記メディアサービスモジュールは、前記コンフィギュレーションおよびコントロールモジュールが、共有されるリソースを確立し、それに関連する配布判断基準を定義し、前記ネットワークに追加された新しいデバイスを許可することを可能にするように構成されているオブジェクトを含むことを特徴とする請求項３に記載のサーバ。
【請求項２８】
前記補足モジュールは、
前記メディアサービスモジュールが少なくとも１つのリソースにアクセスすることを可能にするために前記少なくとも１つのリソースに関連するアクセス許可属性を変更することと、
ユーザが前記サーバにログオンした時またはユーザが前にログオンされたセッションに接続した時に前記メディアサービスモジュールに知らせることと
のうちの少なくとも１つを実行するように構成されているロジックを含むことを特徴とする請求項１に記載のサーバ。
【請求項２９】
前記補足モジュールは、
前記メディアサービスモジュールが少なくとも１つのリソースにアクセスすることを可能にするために前記少なくとも１つのモジュールに関連するアクセス許可属性を変更することと、
少なくとも１つの所定のイベントの発生時に現在アクティブなログオンしたユーザのユーザコンテキストで前記コンフィギュレーションおよびコントロールパネルモジュールを始動することと、
ユーザが前記サーバにログオンした時またはユーザが前にログオンされたセッションに接続した時に前記メディアサービスモジュールに知らせることと
のうちの少なくとも１つを実行するように構成されたロジックを含むことを特徴とする請求項３に記載のサーバ。
【請求項３０】
前記所定のイベントは、
新しいデバイスが前記ネットワークに加わることの検出と、
前記ネットワークに関連する警告状態の検出と、
前記サーバを実施するのに使用されるコンピュータシステムでの警告状態の検出と
のうちの少なくとも１つに対応することを特徴とする請求項２９に記載のサーバ。
【請求項３１】
前記コンフィギュレーションおよびコントロールパネルモジュールは、
前記ネットワークへのデバイスの追加および／または除去を処理することと、
前記ネットワークを介して共有されるリソース情報を有するリソースおよび前記リソース情報の前記散布を決定する配布判断基準を管理することと、
前記サーバを起動し、かつ／または停止することと、
リソース情報を共有するために前記サーバによって提供されるリソース共有機能性起動し、かつ／または停止することと
のうちの少なくとも１つを実行するように構成されているロジックを含むことを特徴とする請求項３に記載のサーバ。
【請求項３２】
前記ネットワークへのデバイスの追加および／または除去を処理するように構成されている前記ロジックは、
前記ネットワークへのデバイスの前記追加および／または除去の通知を前記メディアサービスモジュールから受け取り、
前記デバイスの前記追加および／または除去についてユーザに知らせ、
前記ユーザが前記デバイスの前記追加および／または除去を許可または拒否できるようにする
ように構成されているロジックを含むことを特徴とする請求項３１に記載のサーバ。
【請求項３３】
前記サーバは、前記サーバにログオンする複数のめいめいのユーザに関連する前記コンフィギュレーションおよびコントロールパネルモジュールの複数のインスタンスを提供するように構成されているロジックを含むことを特徴とする請求項３に記載のサーバ。
【請求項３４】
前記サーバは、個々のユーザセッションのどれもが前記コンフィギュレーションおよびコントロールパネルモジュールの複数のインスタンスを生成していないことを保証するように構成されているロジックを含むことを特徴とする請求項３３に記載のサーバ。
【請求項３５】
前記サーバは、さらに、前記メディアサービスモジュールと相互作用するために前記コンフィギュレーションおよびコントロールパネルモジュールによって使用されるコールバックオブジェクトを含むことを特徴とする請求項３に記載のサーバ。
【請求項３６】
前記補足モジュールは、前記コンフィギュレーションおよびコントロールパネルモジュールを起動し、前記コンフィギュレーションおよびコントロールパネルモジュールは、前記コールバックオブジェクトに関する初期化関数を呼び出すように構成されていることを特徴とする請求項３５に記載のサーバ。
【請求項３７】
前記ユーザは、前記コンフィギュレーションおよびコントロールパネルモジュールを起動し、前記コンフィギュレーションおよびコントロールパネルモジュールは、前記コールバックオブジェクトに関する初期化関数を呼び出すように構成されていることを特徴とする請求項３５に記載のサーバ。
【請求項３８】
前記サーバは、
アプリケーションが最初に前記メディアサーバモジュールと相互作用することを試みる時に前記アプリケーションにＩＤを割り当て、
前記ＩＤをストアし、
前記アプリケーションが別の機会に前記メディアサーバモジュールと相互作用することを試みる時に、前記アプリケーションからＩＤを受信し、前記受信されたＩＤを前記ストアされたＩＤと比較し、
前記受信されたＩＤが前記ストアされたＩＤと一致しない場合に、前記アプリケーションが前記メディアサービスモジュールと通信することを禁止する
ように構成されているロジックを含むことを特徴とする請求項１に記載のサーバ。
【請求項３９】
複数のユーザは、前記サーバをホスティングするコンピュータシステムに同時にログオンすることができ、前記サーバは、前記ユーザに関連するめいめいのクライアントトークンから抽出されるターミナルサービスセッションＩＤに基づいて前記ユーザを区別するように構成されていることを特徴とする請求項３８に記載のサーバ。
【請求項４０】
請求項１に記載の前記メディアサービスモジュールおよび前記補足モジュールのそれぞれを実施する機械可読命令を含むことを特徴とするコンピュータ可読媒体。
【請求項４１】
請求項３に記載の前記メディアサービスモジュール、前記補足モジュール、ならびに前記コンフィギュレーションおよびコントロールパネルモジュールのそれぞれを実施する機械可読命令を含むことを特徴とするコンピュータ可読媒体。
【請求項４２】
ならず者アプリケーションがネットワークを介してリソース情報を配布するのに使用されるサーバへのアクセスを得ることを防ぐ方法であって、
アプリケーションがメディアサーバによって提供されるメディアサービスモジュールとの相互作用をはじめて試みる時にアプリケーションにＩＤを割り当てることと、
前記ＩＤをストアすることと、
前記アプリケーションが別の機会に前記メディアサービスモジュールとの相互作用を試みる時に、前記アプリケーションからＩＤを受信し、前記受信されたＩＤを前記ストアされたＩＤと比較することと、
前記受信されたＩＤが前記ストアされたＩＤと一致しない場合に、前記アプリケーションが前記メディアサービスモジュールと通信することを禁止することと
を含むことを特徴とする方法。
【請求項４３】
前記ネットワークは、ユニバーサルプラグアンドプレイ（ＵＰｎＰ）ネットワークとして構成されていることを特徴とする請求項４２に記載の方法。
【請求項４４】
前記ＩＤの前記割当は、
前記アプリケーションによって、前記メディアサービスモジュールにコールバックオブジェクトを供給することと、
前記メディアサービスモジュールによって、前記アプリケーションに前記ＩＤを提供するのに前記コールバックオブジェクトを使用することと
を含むことを特徴とする請求項４２に記載の方法。
【請求項４５】
複数のユーザは、前記サーバに同時にログオンすることができ、前記ユーザに関連するめいめいのクライアントトークンから抽出されたターミナルサービスセッションＩＤに基づいて前記ユーザを区別することをさらに含むことを特徴とする請求項４２に記載の方法。
【請求項４６】
請求項４２に記載の前記割当、前記ストア、前記受信、および前記禁止のそれぞれを実施する機械可読命令を含むことを特徴とするコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
この主題は、ネットワークを介する受信側へのリソース情報のルーティングのアーキテクチャおよび関連する技法に関し、具体的な実施形態では、ホームネットワークなどのローカルネットワークを介して受信側にリソースメタデータおよびリソースコンテンツを選択的にルーティングするメディアサーバアーキテクチャおよび関連する技法に関する。
【背景技術】
【０００２】
ユニバーサルプラグアンドプレイ（ＵＰｎＰ）は、ネットワークへのデバイスの追加および除去を容易にするネットワークアーキテクチャを提供する。例えば、ＵＰｎＰアーキテクチャは、ユーザが、ネットワーク結合に新しいデバイスを単純に「プラグ」すること可能にする。その後、ネットワークは新しいデバイスの特性を自動的に判定し、その後、この新しいデバイスとネットワーク内の他のデバイスの間の相互作用を、判定された特性に基づいて調整する。ＵＰｎＰアーキテクチャは、家庭、会社、学校など、ローカルセッティングに関連するネットワークに特によく適する（用語「ユニバーサルプラグアンドプレイ」が、より以前に開発されたデバイスプラグアンドプレイ（ＰｎＰ）で提供される機能性から派生したことに留意されたい。デバイスＰｎＰは、ＰＣなどの独立型コンピュータデバイスに周辺機器を自動的に追加し、除去する柔軟な技法を提供する）。
【０００３】
図１に、例示的なＵＰｎＰアーキテクチャ１００に関する高水準の情報を提示する。概要として、ＵＰｎＰアーキテクチャ１００に、ネットワーク１１２を介して一緒に結合された複数のデバイス（例えば、デバイス１０２、１０４、および１０６）と、コントロールポイント（例えば、コントロールポイント１０８および１１０）が含まれる。
【０００４】
ＵＰｎＰデバイス（１０２、１０４、および１０６）に、様々な電子デバイスを含めることができる。例示的なデバイスに、すべてのタイプのコンピュータ、ＣＤ／ＤＶＤプレイヤ／ジュークボックス、ＴＶ、ＶＣＲ、ＭＰ３プレイヤ、ステレオシステム、電子額縁（ＥＰＦ）、様々なタイプの静止画カメラおよびビデオカメラなどが含まれる。具体的に言うと、いわゆるＵＰｎＰデバイスは、概念的に、実際のデバイス、サービスなどを含むことができるコンテナを定義する。サービスは、他のＵＰｎＰデバイスに使用可能にされるＵＰｎＰデバイスによって実行される様々な機能を定義する。例えば、１つの例示的なサービスを、時計によって提供される日時順機能に関するものとすることができる。一般に、サービスは、状態変数を使用してその機能性をモデル化し、そのモデルに関連する様々なアクションを他のＵＰｎＰデバイスに公開する。図１の例示的な事例では、ＵＰｎＰデバイス１０２に、サービス１１６を提供する実際のデバイス１１４が含まれる。ＵＰｎＰデバイス１０４に、サービス１２０および１２２を提供する実際のデバイス１１８が含まれる。ＵＰｎＰデバイス１０６に、サービス１２６および１２８を提供する実際のルートデバイス１２４が含まれる。ルートデバイス１２４に、サービス１３２を提供する組み込みデバイス１３０が含まれる。
【０００５】
ネットワーク１１２は、伝送制御プロトコルおよびインターネットプロトコル（ＴＣＰ／ＩＰ）を使用して、デバイス（１０２、１０４、および１０６）を一緒に結合することができる。ネットワーク１１２は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）、ＧＥＮＡ（Ｇｅｎｅｒａｌ  Ｅｖｅｎｔ  Ｎｏｔｉｆｉｃａｔｉｏｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ）などの複数の他の標準プロトコルから自由に引き出すこともできる。ネットワーク１１２は、物理的には、電話回線、電力線、ＩｒＤａ（Ｉｎｆｒａｒｅｄ  Ｄａｔａ  Ａｓｓｏｃｉａｔｉｏｎ）、イーサネット（登録商標）、ラジオ周波数（ＲＦ）結合などの様々なハードワイヤード通信機構および／または無線通信機構を使用して実施することができる。
【０００６】
最後に、コントロールポイント（１０８、１１０）は、他のＵＰｎＰデバイスを発見でき、制御できるエージェントを定義する。ＵＰｎＰデバイス自体に、それに一体化された１つまたは複数のコントロールポイントを含めることができる。
【０００７】
図２に、階層レイヤに配置された、ＵＰｎＰアーキテクチャ１００によって実行される従来の機能を示す。アドレッシング機能２０２は、デバイスおよびコントロールポイントがネットワーク１１２と相互作用するアドレスをそれによって受け取るプロシージャに関係する。具体的に言うと、デバイスまたはコントロールポイントは、動的ホスト構成プロトコル（ＤＨＣＰ）サーバからまたはＡｕｔｏ  ＩＰ割当プロシージャを使用することによって（例えば、ＤＨＣＰサーバが使用可能でない場合に）、アドレスを受け取ることとができる。Ａｕｔｏ  ＩＰプロシージャは、予約されたプライベートアドレスのセットからＩＰアドレスを知的に選択する技法を提供する。
【０００８】
ディスカバリ機能２０４は、デバイスがそのサービスをコントロールポイントにアドバタイズするプロシージャに関係する。デバイスは、ＨＴＴＰのマルチキャスト変形（すなわちＨＴＴＰ−ＭＵ）を送出することによって、このアドバタイズメントを実行することができる。コントロールポイントが、その後、ＨＴＴＰＵ（すなわち、ＨＴＴＰのマルチキャスト変形）を使用して応答する。ディスカバリ機能２０４は、ＧＥＮＡ（Ｇｅｎｅｒａｌ  Ｅｖｅｎｔ  Ｎｏｔｉｆｉｃａｔｉｏｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ）およびＳＳＤＰ（Ｓｉｍｐｌｅ  Ｓｅｒｖｉｃｅ  Ｄｉｓｃｏｖｅｒｙ  Ｐｒｏｔｏｃｏｌ）を利用して、ＵＰｎＰデバイスとコントロールポイントの間での上で示した交換を実行する。さらに、新たに追加されたコントロールポイントは、ネットワークに結合されたＵＰｎＰデバイスおよびサービスを検索することもできる。
【０００９】
ディスクリプション機能２０６は、ＵＰｎＰデバイスを発見したコントロールポイントが、そのＵＰｎＰデバイスに関するさらなる情報を判定できるようにするプロシージャに関係する。ＵＰｎＰデバイスは、コントロールポイントに情報を送ることによって応答し、その情報は、拡張マークアップ言語（ＸＭＬ）を使用して表される。その情報は、ＵＰｎＰデバイスのタイプ（例えば、製造業者、モデル名、モデル番号、通し番号など）、それが提供するサービス、そのデバイスと相互作用するためのＵＲＬ（ｕｎｉｆｏｒｍ  ｒｅｓｏｕｒｃｅ  ｌｏｃａｔｏｒ）などに関する詳細を定義する。
【００１０】
コントロール機能２０８は、コントロールポイントからＵＰｎＰデバイスへの制御メッセージの送信にかかわる。ＵＰｎＰアーキテクチャ１００は、このメッセージを送信するのにＳＯＡＰを使用する。ＳＯＡＰメッセージに、アクション要求が含まれる。ＵＰｎＰデバイスは、ＳＯＡＰメッセージで指定されたアクションを実行し、その後、コントロールポイントに応答する。この応答に、アクション固有の値またはフォールトコードが含まれる。
【００１１】
イベンティング機能２１０は、コントロールポイントがＵＰｎＰアーキテクチャ１００によって提供されるサービスに関連するイベントを監視するプロシージャに関する。具体的に言うと、サービスは、そのモデルが状態を変更する時にイベントを送ることができる。これらの状態変化を「パブリッシュ」するプロセスを、イベンティングと呼ぶ。コントロールポイントは、関心を持つサービスにサブスクリプションメッセージを送信することによって、様々なイベントを受け取るためにサブスクライブすることができる。
【００１２】
最後に、プレゼンテーション機能２１２は、あるＵＰｎＰデバイスに関連するプレゼンテーションＵＲＬを使用して、このＵＰｎＰデバイスから情報のページを取り出すことを含む。コントロールポイントは、ＵＰｎＰデバイスにＨＴＴＰ  ＧＥＴ要求を発行することによって、プレゼンテーションプロセスを開始することができる。プレゼンテーション機能２１２は、ユーザが、デバイスのステータスを見、かつ／またはデバイスを制御することを可能にする。
【００１３】
ＵＰｎＰ  Ｆｏｒｕｍのウェブサイト（例えば、非特許文献１参照）で、ＵＰｎＰアーキテクチャおよび関連する話題に関する詳細な情報が提供されている。
【００１４】
上で述べたように、ＵＰｎＰデバイスは、一般に、家庭または会社など、比較的ローカライズされたネットワーク環境で使用される。例えば、家庭環境では、ＵＰｎＰデバイスを含むネットワークが、メディアソースデバイスのコレクションとメディアレンダリングデバイスのコレクションを相互接続する場合がある。例示的なメディアソースデバイスに、音楽、ビデオ、写真などのコレクションをストアするパーソナルコンピュータを含めることができ、あるいは、様々なタイプのジュークボックスデバイスを含めることができる。例示的なメディアレンダリングデバイスに、ＴＶ、ステレオ、パーソナルコンピュータなどを含めることができる。コントロールポイント（パーソナルコンピュータなど）を使用して、あるメディアソースデバイスから選択されたメディアレンダリングデバイスにリソース情報をルーティングすることができる。
【００１５】
しかし、ＵＰｎＰデバイスを含む既存のネットワークは、よく制御され、保護され、責任を負う形での上で説明したリソース情報の転送を実行しない。例えば、設計エンジニアが、パーソナルホームコンピュータ（ＰＣ）を使用してメディアサーバを実施すると選択したと仮定する。この場合に、設計エンジニアは、単一ＰＣ全体のセキュリティパラダイムに基づいてその機能性のすべてにアクセスできるようにメディアサーバを構成することができる。しかし、本発明人によって諒解されるように、ＵＰｎＰメディアサーバは、多数の異なる機能を提供し、異なるセキュリティレベルを、これらの異なる機能に適用することができる。したがって、ＵＰｎＰメディアサーバ全体に単一のセキュリティパラダイムを適用するという方策は、すべての機能へのアクセスを保証するために、メディアサーバによって提供されるすべての機能に関して十分に低いセキュリティレベルを選択することを必要とする場合がある。これは、クリティカルなリソースおよび機能（メディアサーバ、メディアサーバを実施するコンピュータシステム、メディアサーバが結合されるネットワークなどに関連する）のセキュリティを潜在的に危険にさらし、したがって、潜在的に、許可されないエンティティがＵＰｎＰメディアサーバのプライベートメディアデータへのアクセスを得ることを可能にするという短所を有する。代替案では、設計エンジニアが、単一のセキュリティパラダイムの使用に対処するために、ある機能を省略することを選択することができる。これは、メディアサーバの有用性を減らすという明白な不利益を有する。
【００１６】
既知のＵＰｎＰメディアサーバソリューションは、追加の欠陥および短所にも苦しむ。例えば、既知のＵＰｎＰメディアサーバは、高速ユーザ切替（ＦＦＵＳ）などの、現代のコンピューティング技法に対処する機能性を提供しない。ＦＵＳ技法は、異なるめいめいのユーザに関連する異なるセッションの間で切替る便利な技法を提供する。例えば、この技法を用いると、第１ユーザが、コンピュータに接続し、アプリケーションを実行できるようになり、それに、別のアプリケーションを実行する第２ユーザが続く。第２ユーザが、コンピュータに接続する時に、コンピュータは、第１ユーザのセッションに関連するアプリケーションインスタンスを保存する。第１ユーザが、コンピュータにもう一度接続する時に、コンピュータは、第１ユーザが切断した時のそのユーザのコンピュータセッションに関連する設定およびアプリケーションを復元する。したがって、ＦＵＳは、任意の数のめいめいのユーザに関連する複数のアプリケーションインスタンスを記録できる機能性を提供する。既知のＵＰｎＰメディアサーバは、そのＵＰｎＰ機能性とのＦＵＳ技法の統合の機構を提供しない。
【００１７】
【非特許文献１】http://upnp.org/
【発明の開示】
【発明が解決しようとする課題】
【００１８】
したがって、ＵＰｎＰデバイスを含むネットワークまたは類似するコンピューティング環境での使用のためのよりセキュアかつ／または多用途のメディアサーバを提供することに対する、当技術分野の例示的な必要が存在する。
【課題を解決するための手段】
【００１９】
１つの例示的な実施形態に従って、ネットワークを介してリソース情報を散布するサーバを説明する。このサーバには、第１ユーザコンテキストで動作し、ネットワークを介してリソース情報を共有するように構成されたメディアサービスモジュールが含まれる。このサーバには、第２ユーザコンテキストで動作し、ネットワークを介するリソース情報の共有でメディアサービスモジュールを支援するように構成された補足モジュールも含まれる。
【００２０】
１つの例示的な特徴によれば、このサーバに、さらに、第３ユーザコンテキストで動作し、ユーザと相互作用するように構成されたコンフィギュレーションおよびコントロールパネルモジュールを含めることができる。
【００２１】
もう１つの例示的な特徴によれば、第１ユーザコンテキストは、サーバによって提供されるリソースへのアクセスの関連する第１レベルを提供するクランプドダウンユーザコンテキストである。第２ユーザコンテキストは、サーバによって提供されるリソースへの関連する第２レベルを提供するローカルシステムユーザコンテキストであり、アクセスの第２レベルは、アクセスの第１レベルより高い。第３ユーザコンテキストは、サーバにログオンしたユーザに関連するアクセスのレベルを提供するログオンしたユーザのコンテキストである。
【００２２】
追加の例示的な実施形態を、下で説明する。
【００２３】
この開示および図面の全体を通じて、同一の符号が、同一の構成要素および特徴を参照するのに使用される。１００番台の数は、最初に図１に現れる特徴を参照し、２００番台の数は、最初に図２に現れる特徴を参照し、３００番台の数は、最初に図３に現れる特徴を参照し、以下同様である。
【発明を実施するための最良の形態】
【００２４】
説明を容易にするために、次の議論で、ユニバーサルプラグアンドプレイ（ＵＰｎＰ）アーキテクチャに関するリソース情報配布機能性を説明する。本明細書で使用される用語「ＵＰｎＰネットワーク」は、ＵＰｎＰアーキテクチャに従って作られた１つまたは複数のエンティティ（例えば、デバイス）を有し、これらのエンティティのアナウンスメント、ディスカバリ、ディスクリプション、イベンティング、およびコントロールにＵＰｎＰプロトコルが使用されるネットワーク（図３に示された例示的なＵＰｎＰネットワーク３１４など）を記述する。本アーキテクチャでは、ＵＰｎＰアーキテクチャに従って作られたエンティティ以外のエンティティを、ＵＰｎＰネットワーク３１４に結合することができる。しかし、この特定のネットワークフレームワークは、単なる例示である。このリソース情報配布機能性は、他の種類のアーキテクチャおよびネットワークを使用して実施することができる（すなわち、この機能性は、ＵＰｎＰエンティティを含むネットワークに制限されない）。
【００２５】
具体的に言うと、短く説明したように、ＵＰｎＰネットワーク３１４に、１つまたは複数の受信側エンティティに情報を供給する１つまたは複数のソースエンティティを含めることができる。ＵＰｎＰネットワーク３１４に、任意選択として、ソースエンティティから受信側エンティティへの情報の転送を調整し、他の機能を実行する１つまたは複数のコントロールポイントを含めることができる。例えば、ソースエンティティに、メディアサーバまたは他の種類のデバイスを含めることができる。受信側エンティティには、コントロールポイントデバイス、メディアレンダリングデバイス、または他の種類のデバイスを含めることができる。一般に、用語「エンティティ」および「デバイス」は、本明細書では広義に解釈されなければならず、これらの用語は、帰するタスクを実行する別個の独立型ユニットを指すことができ、あるいは、複数のユニットからなるシステムを含めることができ、あるいは、ユニット内に含まれるハードウェアコンポーネントおよび／またはソフトウェアコンポーネントを含めることなどができる。議論を単純にするために、用語「デバイス」を、このセクションでは、ＵＰｎＰネットワーク３１４に結合されたすべての種類のモジュールを記述するのに使用する（さらに、メディアサーバデバイスを、議論を単純にするために「メディアサーバ」とも呼ぶ）。
【００２６】
さらに、具体的な例を提供するために、次の議論で、家庭内の人が、ＵＰｎＰネットワーク３１４を使用して、家庭内の複数のメディアサーバおよびメディアレンダリングデバイスを相互接続する、家庭コンテキストでのリソース情報配布機能性を説明する。しかし、このリソース配布機能性は、会社環境（例えば、１企業内）、アカデミック環境（例えば、学校または大学内）などを含むすべての環境に適用することができる。
【００２７】
さらに、ＵＰｎＰネットワーク３１４は、通常は、比較的小さく、明確に定義された地理的区域内（例えば、ビルディング内）のデバイスを一緒に結合する。しかし、このリソース情報配布機能性は、地域的により包括的な環境に適用することができる。
【００２８】
さらに、次の議論で、「リソース」は、情報のすべての単位を指す。例えば、リソースは、単一のファイルに対応することができ、あるいは、ファイルの一部に対応することができ、あるいは、複数のファイルのコレクションに対応することができる。例えば、リソースが、音楽に対応すると仮定する。その音楽を、単一のファイルにストアするか、単一のファイルの一部だけにストアするか、複数のファイルにストアすることができる（最後の場合に、この複数のファイルに、他の音楽からのストリームを組み合わせることもできる）。具体的に言うと、図３からわかるように（この図の右端部分に留意されたい）、リソースストア（下で説明する）にストアされた例示的なリソース（Ｒ）に、本明細書で一般に「リソース情報」と称する様々な情報コンポーネントを含めることができる。リソース情報のそのようなコンポーネントの１つが、「リソースメタデータ」である。リソースメタデータには、リソースのタイトル、そのリソースに関連するアーティスト、そのリソースが作成された日付などの、リソースに関する高水準情報が含まれる。リソース情報のもう１つのコンポーネントが、「リソースコンテンツ」である。リソースコンテンツには、リソースメタデータが記述するデータが格納される。例えば、オーディオリソースのリソースコンテンツは、コンシューマに再生されるオーディオデータに対応する（この開示の諸部分で、用語「リソースコンテンツアイテム」が、特定のリソースに関連するリソースコンテンツを指すのに使用される；この場合の用語「アイテム」の使用は、単に、ある文脈での用語「リソースコンテンツ」の使用を明瞭にするための文法的な便宜の問題である）。最後に、次の説明で、しばしば、レンダリングデバイスでの提示のための、そのレンダリングデバイスへの「リソースコンテンツ」の転送に言及する。この転送は、リソースコンテンツ以外のリソースに関する追加情報の転送を除外せず、リソースの転送に、例えば、リソースコンテンツに付随するリソースメタデータを含めることもできる。
【００２９】
さらに、リソース自体を、個々のメンバリソースのコレクションとすることができる。例えば、リソースが、いわゆるリソースコンテナまたはリソースフォルダあるいはリソースの他の種類のコレクションを構成することができる。下で説明するように、リソースコンテナは、メディアサーバが１つまたは複数のメンバリソースの内部的な管理に使用する、これらのメンバリソースのグループ化を指す。リソースフォルダは、メディアサーバがユーザに「可視」にする１つまたは複数のメンバリソースのグループ化を指す。例えば、メディアサーバに、それぞれに１つまたは複数のメンバリソースを含めることができる複数のリソースフォルダを提示できるユーザインターフェースディスプレイ（または他のプレゼンテーション機構）を含めることができる。しかし、メディアサーバは、内部的に、リソースコンテナのコンテキストでこれらのメンバリソースを管理することができる。リソースフォルダ内の情報の割当は、一般に、リソースコンテナ内の情報の割当と異なるが、代替実施形態では、この割当を同一にすることができる（さらに、メディアサーバは、任意選択として、ユーザがリソースコンテナおよびそのめいめいのメンバリソースに関する情報を見ることと、フォルダごとの基礎ではなくまたはそれに加えてコンテナごとの基礎で様々なアクションを実行することを可能にすることができる）。すべてのコレクション（リソースコンテナまたはリソースフォルダのいずれか）自体に、メンバ「子」コレクション（すなわち、めいめいの子リソースコンテナまたは子リソースフォルダ）を含めることができる
特定の種類のリソースコレクションが、リソース再生リストである。このリソースは、オーディオリソース、ビデオリソース、および／または写真リソース（あるいは他の種類のリソース）のリストを参照するファイルとして実装することができる。
【００３０】
上の例は、リソースがとることのできる現れのうちの少数を記述したものにすぎず、一般に、用語リソースは、あらゆる考慮に基づく情報のあらゆる集団を抽象的に表す。
【００３１】
一実施形態で、リソースを、オーディオリソース（例えば、音楽、オーディオブックなど）、ビデオリソース、写真リソース（例えば、デジタル写真）などのメディアリソースに対応するものとすることができる。しかし、本明細書に記載の原理は、あらゆる目的でのあらゆる種類の情報の配布に使用することができる。
【００３２】
本明細書で引き合いに出される用語「処理」は、様々な動作に関連することができる。ある場合に、用語「処理」が、処理される情報を変更するのに使用される動作を指す。別の場合に、用語「処理」が、処理される情報を単純に取り扱うのに使用される動作、または処理される情報に関する判断を行う動作を指す。これらは、この用語に含まれる動作の様々なタイプの少数の例にすぎない。
【００３３】
さらに、様々な管理タスク（共有リソースの定義など）を実行するために本明細書で説明されるメディアサーバと相互作用するすべてのエンティティを、本明細書で、「メディアサーバユーザ」と称する。メディアサーバユーザは、メディアサーバと相互作用する人間のオペレータに関係することができ、あるいは、メディアサーバと相互作用するように構成された論理機能性を含む他のエンティティを表すことができる。例示的な実施形態では、メディアサーバユーザが、メディアサーバにログオンすると仮定される。一実施形態で、ユーザは、メディアサーバに識別情報を提供することによってメディアサーバにログオンし、その際に、メディアサーバは、そのように構成される場合に、ユーザを認証する（例えば、ユーザに、パスワードを供給するように要求するか、他の形の認証によって）。メディアサーバの他の実施形態は、メディアサーバと相互作用するためにユーザがその身元を与えることを要求しないものとすることができる。下で説明するように、ログオンされたメディアサーバユーザセッションの状況は、アクティブまたはインアクティブになることができる。
【００３４】
メディアサーバにリソース情報を要求するすべてのエンティティを、リソース情報コンシューマと呼ぶ（下では、説明を簡潔にするために、単に「コンシューマ」と呼ぶ）。コンシューマは、メディアサーバにリソースメタデータおよび／またはリソースコンテンツを要求することができる。コンシューマは、コントロールポイントまたはレンダリングデバイスからメディアサーバと相互作用することを望む人間のオペレータを表すことができ、あるいは、メディアサーバと相互作用するように構成された論理機能性を含む他のエンティティを表すことができる。人間のオペレータの場合に、同一の人が、メディアサーバユーザおよびコンシューマの両方として機能することができ、その代わりに、異なる個人がこの２つのめいめいの役割を引き受けることができる。
【００３５】
最後に、代替案（例えば、ＡまたはＢ）で、この開示で複数の例を提示する。さらに、この開示に、毎回これらの事例に明示的に言及しない場合があるが、代替案を単一の実施形態に組み合わせる事例が含まれる（例えば、ＡおよびＢ）。
【００３６】
この開示には、次のセクションが含まれる。
Ａ．リソース共有を実施する例示的なシステム
Ａ．１．このシステムの概要
Ａ．２．このシステムの例示的な応用例
Ａ．３．メディアサーバアーキテクチャの概要
ａ．メディアサービスモジュール
ｂ．コンテンツディレクトリデバイスモニタ（ＣＤＤＭ）モジュール
ｃ．ユーザインターフェースモジュール
Ａ．４．高速ユーザ切替の備え
Ａ．５．追加のセキュリティの備え
ａ．ＩＰアドレス制限
ｂ．ＭＡＣアドレス認証
ｃ．サブネット制限
ｄ．ＴＴＬ制限
ｅ．デバイスおよびセッションの制限
ｆ．ＵＰｎＰアクションへの認証に関する候補デバイスの制限
ｇ．リソースロケータリタイヤメント
ｈ．様々なサーバセキュリティ手段
Ａ．６．ＵＲＬパラメータ化の提供
Ｂ．例示的なユーザインターフェース（ＵＩ）プレゼンテーション
Ｂ．１．新しいデバイスを許可する例示的なＵＩ
Ｂ．２．リソースを共有する例示的なＵＩ
Ｃ．例示的なプロセス
Ｃ．１．デバイス許可プロセス
Ｃ．２．リソース共有プロセス
ａ．共有リソースの定義
ｂ．要求に基づく共有リソースの配布
ｃ．パラメータ化されたＵＲＬの処理
Ｄ．例示的なコンピュータ環境
【００３７】
Ａ．リソース共有を実施する例示的なシステム
Ａ．１．このシステムの概要
図３に、リソース情報共有を含む例示的なネットワークアーキテクチャ３００を示す。ネットワークアーキテクチャ３００には、ＵＰｎＰネットワーク３１４を介して一緒に結合された複数のＵＰｎＰデバイス（３０２〜３１２）（下では、簡潔にするために単に「デバイス」と呼ぶ）が含まれる。デバイス（３０２〜３１２）に、上で述べたメディアサーバ３０２と、複数のメディアレンダリングデバイス（３０４〜３１２）が含まれる。例示的なメディアサーバに、様々なタイプのコンピュータ、様々なタイプのジュークボックスなどを含めることができる。例示的なレンダリングデバイスに、様々なタイプのコンピュータ、ステレオシステム、スピーカ、ＴＶ、ハンドヘルドオーディオプレイヤなどを含めることができる（メディアサーバ３０２だけが図示されているが、ネットワーク３１４に、任意の個数のメディアサーバを含めることができる。さらに、複数のメディアレンダリングデバイス３０４〜３１２が図示されているが、ネットワーク３１４に、１つのメディアレンダリングデバイスだけを含めることができ、多分メディアレンダリングデバイスを含めないことができる）。
【００３８】
ＵＰｎＰネットワーク３１４に、任意選択として、１つまたは複数のコントロールポイント（例えば、コントロールポイント３１６、３１８）も含まれる。コントロールポイント（３１６、３１８）を、ＵＰｎＰデバイス（３０２〜３１２）の１つと一体化することができる。すなわち、例えば、レンダリングデバイスに、メディアサーバ３０２と相互作用するためにコントロールポイント機能性を含めることができる。その代わりに、１つまたは複数のコントロールポイントを、ＵＰｎＰデバイス（３０２〜３１２）と別々に実施することができる。例示的なコントロールポイントは、様々なタイプのコンピュータ、携帯情報端末（ＰＤＡ）、アプリケーション固有ロジックモジュールなどを使用して実施することができる。集合的に、メディアレンダリングデバイス（３０４〜３１２）およびコントロールポイント（３１６、３１８）は、他の役割の中でも、リソース情報受信側エンティティとして働くことができ、これは、上で説明したように、これらがメディアサーバ３０２によって供給されるリソース情報を受信できることを意味する。
【００３９】
ＵＰｎＰネットワーク３１４は、ＵＰｎＰデバイス（３０２〜３１２、３１６、３１８）の間で情報を転送するのに、ＴＣＰ／ＩＰ、ＳＯＡＰ、ＧＥＮＡ、ＨＴＴＰなど、プロトコルの任意の組合せを使用することができる。ＵＰｎＰネットワーク３１４に、さらに、ゲートウェイ、ルータ、ハードワイヤードリンク、無線リンク（例えば、ラジオ周波数リンク）など（図示せず）の任意の組合せを含めることができる。
【００４０】
概要として、新しいＵＰｎＰメディアレンダリングデバイスがＵＰｎＰネットワーク３１４に参加する時に、そのデバイスは、メディアサーバ３０２にその存在をアナウンスする。例えば、この新しいメディアレンダリングデバイスが、図３に示された例示的なデバイス３０６に対応すると仮定する。メディアサーバ３０２は、メディアサーバ３０２のユーザ（すなわち、「メディアサーバユーザ」）に、新しいメディアレンダリングデバイス３０６の存在について警告する。下で詳細に示すように、メディアサーバ３０２は、新しいデバイス３０６に対応する受信したＩＰアドレスをそのメディアアクセス制御（ＭＡＣ）アドレスに変換することによるか、ある他の識別／承認機構を使用することによって、新しいメディアレンダリングデバイス３０６のアイデンティティを判定することができる。次に、メディアサーバ３０２は、メディアサーバユーザに、この新しいデバイス３０６をイネーブルするオプションを与える。イネーブルされた場合に、この新しいデバイス３０６は、メディアサーバ３０２がそれへのリソースの転送を許可されたデバイスのスイートの受け入れられたメンバになる。
【００４１】
メディア転送動作自体で、メディアサーバ３０２は、リソースストア３２０で供給されるリソースに対応するリソース情報を、ネットワーク３１４に結合されたリソース情報受信側エンティティにルーティングする。広義に言って、この動作を実行するために、コンシューマは、まず、コントロールポイント（コントロールポイント３１６など）または他のデバイスを使用して、メディアサーバ３０２のリソースストア３２０で供給されるリソースに対応するリソース情報を調べることができる。例えば、この動作に、使用可能なリソースのタイトルなどのリソースのリソースメタデータおよびリソースに関する他の高水準情報を調べることを含めることができる。そのような調査の後に、コンシューマは、メディアレンダリングデバイス３０６などの選択されたレンダリングデバイスでのプレゼンテーションのためにリソースに関連するリソースコンテンツを選択することができる。コントロールポイント３１６は、その後、メディアサーバ３０２から選択されたレンダリングデバイス３０６へのリソースコンテンツの転送をセットアップする際に役割を提供することができる。一実施形態で、ＵＰｎＰアーキテクチャ３００は、ＨＴＴＰプロトコルなどの（これに制限はされない）非ＵＰｎＰプロトコルを使用して、メディアサーバ３０２からレンダリングデバイス３０６へのリソースコンテンツの転送を実際に実行する。
【００４２】
上で要約した機能を実行するために、メディアサーバ３０２に、リソース情報共有機能性３２２が含まれる。次の議論で、リソース情報共有機能性３２２の高水準の特徴を説明する。セクションＡ．３で、リソース情報共有機能性３２２の動作を詳細に説明する。
【００４３】
まず、ルーティングプロシージャに、ネットワーク３１４を介して共有されるリソースを定義するタスクを含めることができる。１つの例示的な実施形態で、メディアサーバ３０２が、リソースフォルダなどのコレクションの単位で共有可能リソースを指定するように構成される。すなわち、リソース情報共有機能性３２２は、共有可能としてリソースフォルダに「耳標を付ける」ことができ、それに含まれるリソースの少なくともいくつかを、ネットワーク３１２を介して共有できるようにする（下で述べる考慮事項に基づいて）。リソース情報共有機能性３２２は、メディアサーバユーザが共有フォルダの共有可能状況を定義できるようにする１つまたは複数のＵＩページを介してこの機能を実行することができる。セクションＢで、これらのＵＩページを詳細に説明する。一般に、継承が、リソースの階層編成内のリソースの共有可能状況に適用される。すなわち、リソースフォルダは、子リソースを構成する１つまたは複数の個々のメンバリソースを含む親リソースとみなすことができる。リソースフォルダに、サブフォルダを含めることもでき、サブフォルダのそれぞれにメンバ子リソースを含めることができる。共有可能として親リソースを指定することは、一般に、そのメンバリソースおよびサブフォルダのすべてを含むその子リソースをも共有可能として指定するという効果を有する。しかし、リソース情報共有機能性３２２は、異なる継承パラダイムに従って動作するように構成することもできる。例えば、１つの代替の事例で、親リソースの共有可能状況を、そのサブフォルダに自動的に適用しないようにすることができる。
【００４４】
また、リソース情報共有機能性３２２を、ユーザがリソースの共有状況を除去する（例えば、リソースの「共有を解除」する）ことを可能にするように構成することができる。例えば、１つの事例で、親リソースの共有を解除することが、その子リソースの共有を解除するという効果を有する。１つの事例で、リソース情報共有機能性３２２は、親が共有可能と指定されている場合に、メディアサーバユーザが子リソースの共有を解除することを禁止することができる。もう１つの事例で、リソース情報共有機能性３２２は、メディアサーバユーザが、共有解除として共有子リソースを選択的に指定し、これによって、上で説明した継承方式をオーバーライドすることを可能にする。
【００４５】
多数の他の戦略を、リソースの共有に使用することができ、上のリスティングは、可能性の代表的なサンプルを示すにすぎない。例えば、メディアサーバユーザが、個々のリソースレベル（リソースコレクションレベルの代わりにまたはそれに加えて）でリソースを共有可能と指定できるようになるように、リソース情報共有機能性３２２を構成することができる。さらに、メディアサーバユーザが、他の種類のコレクションを共有可能と指定できるようになるように、リソース情報共有機能性３２２を構成することができる。
【００４６】
もう１つの例示的な特徴によれば、セクションＣで詳細に説明するように、メディアサーバ３０２が、共有するリソース情報の種類に他の制約を課すことができる。例えば、メディアサーバ３０２は、ある種類の既知のメディアファイルから得られたリソース情報だけを共有することができる。また、メディアサーバ３０２は、リムーバブルドライブ、ネットワーク共有などにストアされたファイルから得られたリソース情報の共有を拒否することができる。期待されるリソースの既知の「世界」から得られるリソース情報に共有を制限することによって、ＵＰｎＰネットワーク３１４への許可されないアクセスの可能性が減る。
【００４７】
リソース情報共有機能性３２２は、メディアサーバユーザが、リソース情報（リソースメタデータとリソースコンテンツの両方を含む）のルーティングを制御するのに任意選択として使用することができる配布判断基準を定義できるようにもする。例えば、第１の配布判断基準として、リソース情報共有機能性３２２は、メディアサーバユーザが、リソース情報の転送をあるリソース情報受信側エンティティに制限できるようにする。第２の配布判断基準として、リソース情報共有機能性３２２は、メディアサーバユーザが、指定された個人が転送への同意を必要とするかどうかに基づいて条件的にリソース情報の転送を行うことを可能にする。例えば、指定された個人がメディアサーバ３０２を実装するコンピュータにログオンしている（かつ、その個人の端末セッションがアクティブである）場合に、この判断基準が暗黙のうちに満足されるように、メディアサーバ３０２を構成することができる。この特徴は、メディアサーバユーザが、リモートからコンソールと相互作用する（例えば、ネットワーク接続を介して）のではなく、メディアサーバ３０２を実装するコンソールと直接に相互作用する時に限って、そのユーザがログオンしていると考えるようにセットアップすることができるが、もう１つの実施形態では、メディアサーバユーザが、リモート接続を介してログオンしている時であってもそのユーザがログオンしていると考えることができる。もう１つの事例で、指定された個人が、転送が受入可能であると明示的に確認する時（指定された個人が、転送のプロパティに関するＵＩクエリに肯定的に応答する時など）に限って、この判断基準が満足されるように、メディアサーバ３０２を構成することができる。１つの例示的な実施形態で、上で述べた「個人」が、配布判断基準に関連するリソースをネットワークを介して共有可能と指定したメディアサーバユーザに対応する。この２つの判断基準は、単に例示であり、リソース情報共有機能性３２２は、リソース情報の転送を決定する追加の判断基準を課すことができる。例えば、追加の判断基準に、リソース情報へのアクセス特権をある時間に制限する時間制限を含めることができる。リソース情報共有機能性３２２は、セクションＢ（下）で説明するように、リソース情報の配布を決定する配布判断基準を定義する、ユーザのための１つまたは複数のＵＩページを提供することができる。
【００４８】
一実施形態で、配布判断基準の第１のセットを、リソースメタデータの転送に適用し、配布判断基準の別のセットを、リソースコンテンツの転送に適用することができる。第１のセットは、第２のセットと異なるものとすることができる。これは、例えば、リソースコンテンツ自体を実際に取り出すことと比較して、単にリソースのタイトルを見ることに、異なる制限が適用されることを意味する。その代わりに、配布判断基準の第１のセットを、配布判断基準の第２セットと同一にすることができる。しかし、配布判断基準が同一である場合であっても、これが、コンシューマがリソースメタデータを見られるが、リソースコンテンツを見られなくするという効果を有する場合がある。これは、例えば、コンシューマが、配布判断基準によってリソースメタデータを受け取ることを許可されるコントロールポイントにあるリソースメタデータを受け取ることができるが、配布判断基準によってリソースコンテンツを受け取ることを禁止されたレンダリングデバイスでリソースコンテンツの再生を試みるからである。この戦略に対する追加の変形形態が、想定されている。例えば、リソース情報共有機能性３２２は、単一のセットの配布判断基準を提供することができる。この単一のセットが、リソースメタデータまたはリソースコンテンツあるいはこの両方の散布を排他的に決定することができる。
【００４９】
１つの例示的な実施形態によれば、リソース情報共有機能性３２２は、個々のリソースではなく、リソースのコレクションのコンテキストで配布判断基準を指定する。例えば、上で説明したように、メディアサーバは、上で説明したＵＩページを使用して、リソースの集合をリソースフォルダにグループ化し、その後、このリソースフォルダ内のリソースに関連するリソース情報（メタデータ、コンテンツ、または両方）が、ある判断基準を満たす、提供されるＵＰｎＰネットワーク３１４に結合された他のデバイスと共有されなければならないことを指定する。その共有されるリソースフォルダに、それぞれが１つまたは複数のリソースを有すル１つまたは複数のサブフォルダを含めることもできる。上で説明したものと同一の種類の親子継承方式を使用して、リソースの階層への配布判断基準の適用を決定することができる。例えば、リソースフォルダについて確立される配布判断基準を、リソースフォルダ内のサブフォルダおよびリソース（例えば、ファイル）のそれぞれに適用することができる。その代わりに、リソースフォルダに関連する配布判断基準が、リソースフォルダ内のリソースのサブセットだけに適用されるようにリソース情報共有機能性３２２を構成することができ、例えば、配布判断基準が、リソースフォルダ内の個々のリソースだけに適用され、そのリソースフォルダに含めることができるサブフォルダのリソースに適用されなくならないように、リソース情報共有機能性３２２を構成することができる。一般的に言うと、リソース情報共有機能性３２２を、様々な情況で上で説明した親子継承方式をオーバーライドするように構成することができる。
【００５０】
やはり、上で説明した方式は、単に例示であり、代表である。多数の他の置換が存在する。例えば、リソース情報共有機能性３２２は、メディアサーバユーザがリソースフォルダ内の個々のリソースに配布判断基準を「アタッチする」ことまたは個々のリソースから配布判断基準を除去することを可能にすることができる。その代わりにまたはそれに加えて、メディアサーバ３０２は、リソースフォルダではなくリソースコンテナに関して配布判断基準を指定することができる。図６に関して詳細に説明するように、リソースコンテナは、そのリソースを管理するためにメディアサーバ３０２によって内部的に使用されるコレクションを指し、リソースフォルダは、メディアサーバユーザが直接に相互作用するコレクションを指す。メディアサーバ３０２は、フォルダにグループ化されたリソースを再編成して、コンテナを作成することができる。
【００５１】
もう１つの例示的な特徴によれば、リソース情報共有機能性３２２は、メディアサーバユーザが配布判断基準の異なるセットを定義することを可能にすることができる。例えば、異なるユーザが、配布判断基準の異なるめいめいのセットを定義することができる。リソース情報共有機能性３２２は、それに関連するユーザが、メディアサーバ３０２を実施するコンピュータシステムにログオンする時に、配布判断基準のこれらの組の１つを自動的に呼び出すことができる。その代わりに、単一のメディアサーバユーザが、配布判断基準の異なるセットを定義することができる。メディアサーバユーザは、特定の有力なオペレーティング環境に最も適するセットを呼び出すことができる。例えば、メディアサーバユーザは、メディアサーバユーザが日中に家庭にいると期待される時に、週末に適用される配布判断基準の第１のセットをアクティブ化し、日中に家庭にいないと期待される時に、ウィークデイの別のセットをアクティブ化することができる。その代わりに、所与の時に両方のセットを適用するために、配布判断基準の１つのセットを別のセットとマージすることができる。ルールを構成して、セットの間の潜在的な衝突を解決することができる。やはり、これらは、単に代表的であり例示的なシナリオである。この設計戦略の多数の他の置換を実施することができる。
【００５２】
他の実施形態は、上で説明したシナリオに追加の制約を課すことができる。１つの例示的な実施形態では、リソース情報共有機能性３２２は、メディアサーバユーザが、この特定のメディアサーバが共有可能と指定したリソースだけに関する配布判断基準を追加しまたは変更することを可能にすることができる。
【００５３】
もう１つの特徴によれば、リソース情報共有機能性３２２は、１つまたは複数の配布判断基準を「ハードコード」し、これらの配布判断基準が、ユーザがＵＩページ（または他の機構）を介してこれらを定義する必要なしに自動的に適用されるようにすることができる。さらに、リソースがリムーバブルドライブにストアされているので共有を禁止されるかどうかを判定する要因など、リソースが共有可能であるか否かを最初に判断することに関する複数の要因を、上で説明した。これらの要因は、概念上、ハードコードされた配布判断基準とみなすことができる。ここでの「ハードコード」は、メディアサーバユーザが、他の配布判断基準（受信側エンティティ関連判断基準など）の定義に使用されるＵＩページを介してこれらの要因を変更できない可能性があることを意味する。しかし、一実施形態で、リソース情報共有機能性３２２に、メディアサーバユーザが様々な情況でこれらの要因を変更できるようにする様々な備えを含めることができる。
【００５４】
もう１つの特徴によれば、様々な機構を使用して、メディアサーバユーザが他のメディアサーバユーザの配布判断基準を検査し、かつ／または変更することを防ぐことができる。例えば、一実施形態で、リソース情報共有機能性３２２は、メディアサーバユーザが、共有可能としてリソースを指定した場合に限って、これらのリソースに関する配布判断基準を定義し、または変更することを可能にする。この設計戦略の他の置換が可能である。
【００５５】
そのルーティング動作において、リソース情報共有機能性３２２は、まず、コンシューマが共有リソースに関連する情報を検索することを可能にする。例えば、上の概要で示したように、コンシューマは、コントロールポイント３１６（または他のデバイス）を使用して、リソースストレージ３２０で提供されるリソースに関連するリソースメタデータを見る要求を入力することができる。具体的に言うと、この要求は、ブラウザ要求、検索要求、またはある種類の他の要求とすることができる。ブラウザ要求は、ある指定されたカテゴリ内など、情報アイテムのコレクションの取り出しをもたらすことができるＵＰｎＰアクションであり、検索要求は、指定されたキー用語に応答してなど、１つまたは複数のターゲットにされた情報アイテムの取出をもたらすことができるＵＰｎＰアクションである。どの場合でも、この要求の伝送は、図３でパス３２４によって表される。
【００５６】
リソース情報共有機能性３２２は、共有リソースを記述したリソースメタデータのコレクションをスキャンして、コンシューマの要求を満足すると同時に、１つまたは複数のメディアサーバユーザによって定義された関連する配布判断基準が存在する場合にその判断基準を満足するリソースを突き止めることによって、要求に応答する３２４。例えば、コンシューマは、コメディジャンルのすべての使用可能なビデオリソースに対応するリソースメタデータを供給するようにメディアサーバ３０２に要求することができる。リソース情報共有機能性３２２は、リソースメタデータをスキャンして、指定された検索条件に一致し、関連する配布判断基準（これらのリソースの表示をリソース情報受信側エンティティのサブセットに制限する判断基準、特定のメディアレンダリングデバイスを使用する子供へのＲレーティングリソースの表示を防ぐ判断基準など）を満たす関連するリソースを突き止めることによって、この要求に応答する。任意選択としてすなわち必ずではないが、配布判断基準を適用するようにリソース情報共有機能性３２２を構成できることに留意されたい。したがって、関連する配布判断基準が存在しない場合、またはメディアサーバ３０２が現在、配布判断基準を適用するように構成されていない場合に、配布判断基準は、リソース情報の配布の制限で役割を演じない。
【００５７】
リソース情報共有機能性３２２が、上で説明した制約を満足する１つまたは複数のリソースに対応するリソースメタデータを見つけた場合に、そのリソース情報共有機能性３２２は、このリソースメタデータをコンシューマに送信する。リソース情報共有機能性３２２によって生成される応答は、具体的には、拡張マークアップ言語（ＸＭＬ）を使用して定式化される。ＸＭＬ応答は、使用可能なリソースに関する名前、アーティスト、作成日付、サイズなど、使用可能なリソースに関する高水準データを識別するリソースメタデータを提供することができる。リソースメタデータは、ＵＲＬ（ｕｎｉｆｏｒｍ  ｒｅｓｏｕｒｃｅ  ｌｏｃａｔｏｒ）など、リソースコンテンツをそこから取り出すことができるネットワーク位置を識別するリソースロケータも提供する。図３では、このＸＭＬ情報の転送が、パス３２６によって示されている。適切な備えを有する場合に、コントロールポイント３１６は、受信したＸＭＬ情報をプレゼンテーションフォーマットに変換し、その後、その情報をモニタまたは他のプレゼンテーションデバイスに表示する（一般に、図３では、コントロールポイント３１６によって提供されるディスプレイプレゼンテーション３２８によって表される）。その一方で、一実施形態で、コントロールポイント３１６は、検索のパラメータおよび適用可能な場合に配布判断基準の制約を満足する応答情報が使用可能と判定されない場合に、メディアサーバ３０２から情報を受信しない。この場合に、コンシューマは、リソースストレージ３２０に保管された一致しないリソース情報の存在および特性を知らない可能性がある（本明細書で使用される用語「一致しないリソース情報」は、コンシューマの検索のパラメータを満足するが、配布判断基準の制約を満足しないリソースに関するリソース情報を指す）。
【００５８】
一致しないリソースメタデータの可用性を制限することは、複数の理由から望ましい。この特徴は、一般に、コンシューマが好ましくないことを見つける可能性がある（またはコンシューマの保護者が好ましくないことを見つける可能性がある）リソースメタデータの表示を排除するので有利である。また、一致しないリソースメタデータの可用性を制限することは、コンシューマに関心を持たせない可能性がある余分な情報を除外するのに有益である。もう１つの実施形態で、リソース情報共有機能性３２２は、メディアサーバユーザが、特定のリソースのそうでなければ一致するリソースメタデータが関連する配布判断基準を満足しない場合にリソースメタデータの一部（すべてではなく）を単純にフィルタリングする配布判断基準を提供することを可能にすることもできる。これは、保護者が、単に、子供がレンダリングデバイスであるリソースのタイトルを見ることを防ぎたいが、それ以外の点で、そのリソースがメディアサーバに存在することを示す情報を子供が受け取ることに異議を唱えない場合に適当である可能性がある。この事例の配布判断基準は、適用される時にタイトルだけを阻止するという効果を有する。一実施形態で、リソースメタデータ自体に、リソースメタデータがコントロールポイントまたは他のリソース情報受信側エンティティによって表示される形を決定するのに使用できるディスプレイ推奨を含めることができる。
【００５９】
最後の注記として、リソース（上で定義した）が、例えば特定のリソースアイテムを提供する個々のリソースを指すことができることを想起されたい。さらに、リソースは、それ自体が１つまたは複数のメンバリソース（および多分１つまたは複数の他のリソースコレクション）を含むことができるリソースコレクション（例えば、リソースコンテナ、リソースフォルダなど）を指すことができる。したがって、１つまたは複数の個々のリソースまたはリソースコレクションを記述したリソースメタデータを提供するように、リソース情報共有機能性３２２を構成することができる。前者の場合に、リソースメタデータに、個々のリソースのタイトル、作成者などの個々のリソースに関係する高水準情報を含めることができる。後者の場合に、リソースメタデータに、リソースコレクションに関する高水準情報を含めることができる。そのような高水準情報に、コレクション全体自体を記述するすべての種類のグローバル情報、ならびに個々のメンバリソースのタイトル、作成者など、リソースコレクション内の個々のメンバリソースおよびサブコレクション（存在する場合に）に関する情報を含めることができる。
【００６０】
議論を容易にするために、次の説明では、一般に、各リソースのリソースメタデータに、リソースコンテンツを見つけることができる（その結果、後にそれを取り出すことができる）場所を記述するリソースロケータが含まれると仮定する。しかし、一実施形態で、リソースがリソースコレクションである場合に、そのリソースメタデータに、それに関連するリソースロケータを含めても、含めなくてもよい。例えば、いわゆる再生リストリソースコンテナは、それに関連するリソースロケータを有することができる。このリソースロケータは、再生リスト（例えば、曲のリスト）または再生リスト内の曲のそれぞれ（例えば、「連結された」曲のセット）のいずれかを取り出すのに使用することができる。再生リストは、例えば、曲に関連する個々のリソースロケータを提供することによるなど、曲のそれぞれをどのようにして取り出すかを識別することができる。しかし、他のリソースコレクションが、それに関連するリソースロケータを有しないことができる。一般に、すべての所与のアプリケーションに、リソースロケータを有するコレクション、リソースロケータがないコレクション、またはリソースロケータありおよびなしのコレクションの組合せを含めることができる。議論を容易にするために、次の説明は、一般に、リソースメタデータアイテムとリソースロケータの間の１対１対応を暗示するが、必ずしも明示的に述べられてはいないが、リソースコレションの上の限定が、潜在的にあてはまる。
【００６１】
使用可能なリソースを（提供されるリソースメタデータを介して）見た後に、コンシューマは、選択されたメディアレンダリングデバイス、例えばレンダリングデバイス３０６で、使用可能な個々のリソースの１つに対応するリソースコンテンツを再生すると決定することができる。これは、様々な形で実行することができる。１つの技法によれば、コントロールポイント３１６（または他のエージェント）が、ＵＲＬ（ｕｎｉｆｏｒｍ  ｒｅｓｏｕｒｃｅ  ｌｏｃａｔｏｒ）などの選択されたリソースコンテンツアイテムに対応するリソースロケータをレンダリングデバイス３０６に供給することができる（やはり、このリソースロケータが、コンシューマの最初のクエリに応答してメディアサーバ３０２によってコントロールポイント３１６にリソースメタデータの一部として供給されたことを想起されたい）。次に、レンダリングデバイス３０６が、このリソースロケータをメディアサーバ３０２にサブミットすることができる。メディアサーバ３０２は、レンダリングデバイス３０６から受信したリソースロケータを使用して、選択されたリソースコンテンツを突き止め、次に、このリソースコンテンツを、選択されたレンダリングデバイス３０６に提示する。この一連のアクションを、例えばＨＴＴＰ  ＧＥＴ動作または他のタイプの動作を使用して、ＵＰｎＰプロトコルの外で実行することができる。この動作では、レンダリングデバイス３０６が、ＨＴＴＰ  ＧＥＴコマンドをメディアサーバ３０２に供給する。そのコマンドに、リソースロケータが含まれる。図３では、このアクションが、パス３３０によって示されている。メディアサーバ３０２は、要求されたリソースコンテンツを供給することによって応答する。図３では、このアクションが、パス３３２によって示されている。ＨＴＴＰ  ＧＥＴプロトコルの他に使用できる他のプロトコルが、ＩＥＥＥ  １３９４、ＲＴＳＰ／ＲＴＰなどである。様々なメディアストリーミング技法を使用して、メディアサーバ３０２からメディアレンダリングデバイス３０６にリソースコンテンツを転送することもできる。さらに、アイテムのリソースロケータのそれぞれを別々に１つずつ送信するのではなく、複数のリソースロケータを、レンダリングデバイス３０６に転送することができ、その後、メディアサーバ３０２に転送して、複数のリソースコンテンツアイテムをひとまとめにした転送を実行することができる。
【００６２】
上で述べたように、ＨＴＴＰ  ＧＥＴプロトコル（または他のプロトコル）を使用する実際のリソースコンテンツの取り出しは、任意選択として、配布判断基準による条件付きにすることもできる。すなわち、上で説明したように、配布判断基準の第１セットが、リソースメタデータの散布を決定し、配布判断基準の第２セットが、リソースコンテンツの散布を決定することができる。第１セットを第２セットと同一にすることができ、あるいは、第１セットを第２セットと異なるものにすることができる。判断基準の第２セットを使用して、メディアサーバ３０２は、要求元のレンダリングデバイスがコンテンツの受信を許可されないことを関連する配布判断基準が示す場合に、リソースコンテンツの配布を禁止することができる。この備えは、許可されないレンダリングデバイスが、許可されたデバイスから受信した（許可ありまたは許可なしのいずれかで）リソースロケータを使用してリソースコンテンツの受信を試みることを防ぐ。この備えは、一度は許可されたがもはや許可されていないデバイスが、リソースコンテンツへのアクセスを試みるために「古い」リソースロケータを使用することによってリソースコンテンツを受信することも防ぐことができる。
【００６３】
１つの事例で、メディアサーバ３０２は、デバイスがリソースメタデータの受信を許可された場合であっても、その同一のデバイスへのリソースコンテンツの配布を防ぐことができる。その代わりに、メディアサーバ３０２が、あるデバイスがリソースコンテンツ自体にアクセスできる場合であっても、そのデバイスへのリソースメタデータの配布を禁止することができる。一般に、用語配布判断基準の「第１セット」および「第２セット」は、判断基準の異なるコレクションをリソースメタデータとリソースコンテンツの配布に適用できることを単純に示す、抽象概念である。１つの事例で、この２つのセットを、文字どおり、パラメータの２つの別々のストアによって実施することができる。別の事例で、この２つのセットを、各判断基準がリソースメタデータおよび／またはリソースコンテンツの配布に適用されるかどうかを示すフィールドまたは属性を各判断基準にアタッチすることによって実施することができる。もう１つの事例で、リソースメタデータおよびリソースコンテンツの両方またはリソースメタデータまたはリソースコンテンツのいずれかの配布に暗黙のうちに適用されるという前提で、判断基準の単一のストアを設けることができる。この散布戦略を実施する、多数の他の変形が可能である。
【００６４】
デバイス関連判断基準の他に、他の種類の配布判断基準をリソースコンテキストの散布に適用することができる。例えば、リソースメタデータの散布の上で説明した事例と同様に、メディアサーバ３０２は、指定された個人が転送に必要な同意を与えなかったことを関連する配布判断基準が示す場合に、リソースコンテンツの配布を禁止することができ、この判断基準は、その個人がメディアサーバ３０２を実装するコンピュータシステムに現在アクティブにログオンしていることを要求することによって満足することができる。他の判断基準によって、リソースコンテンツの配布を決定することができる。
【００６５】
もう１つの実施形態で、メディアサーバ３０２は、配布判断基準に応じて、リソースコンテンツの配布を行わないことができる。この実施形態の前提は、コンシューマがメディアサーバ３０２によって供給されたリソースコンテンツに対応する有効なリソースロケータを有する場合に、そのコンシューマが、そのリソースコンテンツ自体にアクセスする正しい権限を有すると仮定することとすることができる。これは、コンシューマが、まずリソースメタデータを入手するために、リソースメタデータの配布を決定する配布判断基準に示された条件を満たしていなければならないからである。
【００６６】
Ａ．２．このシステムの例示的な応用例
図４に、家庭環境での上で説明したリソース共有戦略の例示的な応用例を示す。しかし、上で注記したように、本明細書に記載の原理は、会社、アカデミック組織など、すべての環境に適用することができる。
【００６７】
図４では、家庭４０２の概略に、私室４０４、子供の寝室４０６、親の寝室４０８、キッチン４１０、およびリビングルーム４１２などの複数の部屋が含まれる。図４には、父４１４、母４１６、および子供４１８を含む、家庭４０２に住む３人の個人も示されている。
【００６８】
私室４０４に、メディアサーバ４２０および関連するリソースならびにレンダリングデバイスＭ  ４２２が含まれる。子供の寝室４０６に、レンダリングデバイスＮ  ４２４が含まれる。親の寝室４０８に、レンダリングデバイスＯ  ４２６が含まれる。キッチン４１０に、レンダリングデバイスＰ  ４２８が含まれる。リビングルーム４１２に、レンダリングデバイス４３０および４３２（ＱおよびＲ）が含まれる。図示されていないが、様々なコントロールポイントを、家庭４０２全体に散在させることができる。例えば、私室４０４のデバイスＭ  ４２２が、コンシューマがメディアサーバ４２０と相互作用できるコントロールポイントとしても機能することができる。メディアサーバ４２０は、私室４０４に置かれているので、私室４０４は、この家庭全体を通じたリソースの配布を決定する配布判断基準をセットアップするコントロールセンタとして機能することができる。母４１６は、この例では、これらの判断基準をセットアップすることによって、メディアサーバユーザとして働いている。最後に、私室４０４に、デバイスのすべてを一緒に結合するルータ４３４も含まれる。ルータ４３４は、普通の形ですなわち、情報に関連するアドレッシング情報に応じて、リソース情報および他の情報を様々なデバイスにルーティングすることによって、機能する。
【００６９】
リソース情報共有機能性３２２は、異なる環境および目的に合うように、様々な異なるリソース共有シナリオを提供することができる。少数のリソース共有可能性の輪郭を次の議論で示して、リソース情報共有機能性３２２をどのように使用できるかの具体的な例を提供する。
【００７０】
第１のシナリオでは、メディアサーバユーザ（メディアサーバ４２０を使用する）が、子供の寝室４０６のデバイスＮ  ４２４だけへの配布のために、リソースの第１の特定のグループをリソースフォルダに選り抜き、そのリソースフォルダ内のリソースに関連するリソース情報に耳標を付けることを求めることができる。したがって、子供４１８は、自分の部屋で適当な子供のリソース情報（例えば、リソースメタデータおよび／またはリソースコンテンツ）にアクセスすることができる。それと同時に、親（４１４および４１６）は、リソースメタデータをブラウズまたは検索する時にこのリソースメタデータを見ない。これは、興味のないリソースメタデータが親（４１４および４１６）に殺到しないという有益な効果を有する。
【００７１】
第２のシナリオでは、親（４１４および４１６）が、アクションジャンルのリソース情報の配布を、親の寝室４０８で見るために親自体だけに制限することを望むことができる。親（４１４および４１６）は、例えば、このリソース情報の暴力が、子供４１８が見るのに不適切であることを心配する可能性がある。メディアサーバユーザは、アクションジャンルのＲレーティングのリソース情報のコレクションが、親の寝室４０８のデバイスＯ  ４２６でのみ再生されなければならないことを指定することによって、この制限を実施することができる。したがって、子供４１８は、自分の部屋４０６からこの好ましくないリソース情報にアクセスすることができず、子供４１８は、この好ましくないリソース情報が存在することすら知らない（リソース情報共有機能性３２２が、このリソースに関するリソースメタデータさえも子供から遮蔽することができるので）。
【００７２】
第３のシナリオでは、メディアサーバユーザが、リソースのある他のコレクションに関連するリソース情報に、すべてのレンダリングデバイスでの表示に適当として耳標を付けることができる。これは、リソースのこのコレクションの配布判断基準を定義する時に「全デバイス」を指定することによって実施することができる。
【００７３】
上で説明したデバイス関連制約に加えて、メディアサーバユーザは、メディアサーバ４２０を操作する選択された個人がリソース情報の転送に対する暗黙のまたは明示的な同意を与えたかどうかに基づいて条件付きで、リソース情報へのアクセスを行うことができる。例えば、第４のシナリオで、この判断基準は、母４１６がメディアサーバ４２０にログオンしている（かつ、彼女の端末セッションがアクティブである）時に満足される。この場合に、リソース情報の転送に対する母４１６の同意は、メディアサーバ４２０との母の単なる同時相互作用から推論される。もう１つの事例で、この判断基準は、母４１６が転送に明示的な合意を与える時に限って満足される。これは、彼女の子供が特定のリソースメタデータまたは特定のリソースコンテンツへのアクセスを試みる時に、ポップアップメッセージを提示することによって達成することができる。転送は、母４１６が、このクエリに肯定して応答する時に限って進行する。
【００７４】
その一方で、「全ユーザ」を指定するユーザ判断基準は、リソース情報の提示に何の制約も課さない。言い換えると、この判断基準がセットされた場合に、リソース情報は、メディアサーバ４２０を操作するいかなる個人の同意も参照せずに、すべての許可されたデバイスで提示することができる。しかし、デバイス関連判断基準は、リソース情報を提示できる場合に関する独立の制約を課すことができ、したがって、効果的に、あるデバイスがこれらのリソースを受け取れないようにする。
【００７５】
やはり、リソース情報共有機能性３２２は、リソースが消費される時刻に関する様々な判断基準など、デバイス関連判断基準およびユーザ同意関連判断基準の他の種類の判断基準を提供することができる。また、やはり、上で説明した特徴は、会社環境など、家庭コンテキスト以外の他の環境に同等に適用可能である。
【００７６】
最後に、下のセクションＡ．５で完全に説明するように、家庭４０２の外の様々なエンティティが、許可されない形でこのホームネットワークとの相互作用を試みる可能性がある。例えば、家庭４０２内に設けられたネットワークの一部が、無線リンクとして実装される場合があり、この場合に、許可されないエンティティが、それ自体を有効なコントロールポイントまたはレンダリングデバイスとして提示するのに十分に家庭４０２の近くで動作している場合がある。もう１つの事例で、許可されないエンティティが、意図的にまたは意図的でなく、メディアサーバ４２０によって提供されるリソース情報を盗聴する、広域ネットワーク（インターネットなど）を使用する個人を表すことができる。どちらの場合でも、上で説明したリソース共有戦略を使用して、リソース情報の散布を、既知の限られたレンダリングデバイスのセットに制限することができる。これは、許可されないエンティティがリソース情報にアクセスするのを防ぐという効果を有する。というのは、これらのエンティティが、リソース情報を受信できる、事前に承認されたデバイスのリストにないからである。配布は、さらに、メディアサーバ４２０を操作する指定された個人の同意によって条件的である。これによって、許可されないアクセスのパスにもう１つの障害が置かれる（この判断基準が、リソース状態を分け与えるのにメディアサーバユーザの明示的なまたは暗黙の承認を必要とするので）。下のセクションＡ．５で、リソース情報への許可されないアクセスを邪魔するように設計された複数の他の備えを説明する。
【００７７】
Ａ．３．メディアサーバアーキテクチャの概要
図５は、図３に示された例示的なメディアサーバ３０２のより詳細な図である。メディアサーバ３０２は、ソフトウェア、ファームウェア（例えば、固定されたロジック回路）、またはソフトウェアとファームウェアの組合せを使用して、図５に示された様々なブロックを実装することができる。用語「ロジック」は、本明細書では、一般に、ソフトウェア、ファームウェア、またはソフトウェアとファームウェアの組合せを表す。ソフトウェア実施形態の場合に、図示のブロックは、処理デバイス（例えば、ＣＰＵ）で実行される時に、指定されたタスクを実行するプログラムコード（および／または宣言ステートメント）の集合を表すことができる。プログラムコードは、１つまたは複数のコンピュータ可読メモリデバイスにストアすることができる。
【００７８】
概要として、メディアサーバ３０２のアーキテクチャに、３つの主コンポーネントが含まれる。第１の主コンポーネントは、メディアサーバモジュール５０２である。メディアサーバモジュール５０２は、リソース情報共有コード、新しいデバイスについてＵＰｎＰネットワーク３１４を監視するコード、およびリソースコンテンツを共有するサーバをホスティングする。メディアサーバモジュール５０２は、ネットワーク３１４を介するリソースメタデータおよびリソースコンテンツの配布を決定するのに使用されるコンフィギュレーションデータ（例えば、共有されるリソースフォルダのリスト、承認されたデバイスのリスト、リソース情報転送に関する同意を提供することを要求されるメディアサーバユーザのリストなど）も維持する。
【００７９】
第２の主コンポーネントは、コンテンツディレクトリデバイスモニタ（ＣＤＤＭ）サービスモジュール５０４である。下で詳細に説明するように、ＣＤＤＭサービスモジュール５０４は、メディアサーバ３０２のシステムリソースと相互作用するために、メディアサーバモジュール５０２と比較してより高いアクセス特権を有する。したがって、メディアサーバ３０２は、ＣＤＤＭサービスモジュール５０４を使用して、より低いアクセス特権に起因してメディアサーバモジュール５０２が実行できない少数の特権動作を実行する。ＣＤＤＭサービスモジュール５０４によって提供される動作を、下で列挙し、詳細に説明する。
【００８０】
第３の主コンポーネントは、コンフィギュレーションおよびコントロールパネルモジュール５０６（簡潔にするためにコントロールパネルモジュール５０６と呼ぶ）である。コントロールパネルモジュール５０６は、ログオンしたユーザが、ネットワーク３１４に加わる新しいデバイスの許可を承認するか拒否することと、共有リソースフォルダのリストを管理することと、関連する配布判断基準を定義することを可能にする。また、コントロールパネルモジュール５０６は、メディアサーバ３０２がクリティカルシステムエラーに出会った時に、メディアサーバユーザに警告する。
【００８１】
サブセクションＡ．４（下）で説明するように、メディアサーバ３０２は、高速ユーザ切替（ＦＵＳ）を実装する。ＦＵＳ技法は、複数のメディアサーバユーザが、メディアサーバ３０２をホスティングするコンピュータシステムに同時にログオンできるようにする。この場合に、メディアサーバ３０２は、同時に動作することができる、コントロールパネルモジュール５０６の複数のインスタンスを提供する。図５に、モジュールインスタンス５０６がユーザ５０８との相互作用に使用され、モジュールインスタンス５１０がユーザ５１２との相互作用に使用され、モジュールインスタンス５１４がユーザ５１６との相互作用に使用される例示的な事例を示す。しかし、各ユーザは、いつでもコントロールパネルモジュール５０６の多くとも１つのインスタンスを起動することができる。プライベートアプリケーションプログラミングインターフェース（ＡＰＩ）５１８が、コントロールパネルモジュール５０６をメディアサーバ３０２の他のコンポーネントに結合する。
【００８２】
上で説明した３つのモジュールのそれぞれが、異なるいわゆる「ユーザコンテキスト」で動作する。メディアサーバモジュール５０２は、いわゆるローカルサービスユーザコンテキストまたはネットワークサービスコンテキスト（下で説明する）などのいわゆる「クランプドダウン（ｃｌａｍｐｅｄ−ｄｏｗｎ）」ユーザコンテキストで動作する。ＣＤＤＭサービスモジュール５０４は、いわゆるローカルシステムユーザコンテキストで動作する。コントロールパネルモジュール５０６は、いわゆるログオンしたユーザのユーザコンテキストで動作する。基本的に、クランプドダウンユーザコンテキストは、新しいデバイスに関するＵＰｎＰネットワーク３１４の監視、リソース情報の共有など、ＵＰｎＰ機能のコレクションに関するアクセス特権を提供する。しかし、クランプドダウンユーザコンテキストは、ディスクにストアされたリソースの実際の読み取り、削除、および書き込みなど、メディアサーバ３０２を実装するのに必要なコンピュータによって提供されるあるリソースのアクセスを許容しない場合がある。ローカルシステムユーザコンテキスト（ＣＤＤＭサービスモジュール５０４によって使用される）は、これらのコアコンピュータリソースへのアクセスを提供し、さらに、クランプドダウンユーザコンテキストがこれらのコンピュータリソースにアクセスするのを許可するためにこれらのコンピュータリソースに対するアクセス許可を変更することができる。したがって、クランプドダウンユーザコンテキスト（メディアサーバモジュール５０２によって使用される）およびローカルシステムユーザコンテキスト（ＣＤＤＭサービスによって使用される）は、互いに補完して、ＵＰｎＰ共有機能性を実装するのに必要な機能性を提供する。ログオンしたユーザのユーザコンテキスト（コントロールパネルモジュール５０６によって使用される）は、ログオンしたユーザ（例えば、ユーザ５０８）に特に関連するアクセス特権を提供する。
【００８３】
メディアサーバ３０２のリソース、より広義にはメディアサーバ３０２をホスティングするコンピュータシステムのリソースを保護するために、異なるセキュリティユーザコンテキストに異なる機能性を割り当てることが望ましい。例えば、メディアサーバ３０２は、メディアサーバユーザがメディアサーバ３０２に一人もログオンしていない状態で、バックグラウンドモードである動作を実行することができる。そのようなバックグラウンド動作の１つは、クリティカルシステムエラーがある時、または新しいメディアレンダリングデバイスまたはコントロールポイントがネットワーク３１４上で検出された時に、メディアサーバユーザに通知することを必要とする（どちらの事例でも、これは、コントロールパネルモジュール５０６を起動することによって実行される）。これらのバックグラウンドタスクに関連する機能性が、メディアサーバ３０２によって提供されるシステムリソースのすべてと直接に相互作用することを防ぐことが望ましい。このために、メディアサーバ３０２は、ＣＤＤＭサービスモジュール５０４を使用し、ＣＤＤＭサービスモジュール５０４は、ローカルシステムユーザコンテキストを使用して、メディアサーバモジュール５０２を補足する（メディアサーバモジュール５０２は、クランプドダウンユーザコンテキストで動作する）。上で述べたように、ＣＤＤＭサービスモジュール５０４は、クランプドダウンユーザコンテキストが立ち入り禁止のコアシステムリソースにアクセスするのに必要なアクセス特権を有する。
【００８４】
次の議論で、説明を容易にするために、クランプドダウンユーザコンテキストを、ローカルサービスユーザコンテキストを使用する特定の実施形態のコンテキストで説明する。ローカルサービスユーザコンテキストは、通常は他の普通のユーザアカウントのようにコンピュータシステムへの対話型ログオンを許容しない、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムによって作成された特殊なアカウントを参照する。しかし、前に述べたように、ネットワークサービスコンテキスト（これもＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステム内の事前定義のユーザコンテキストを参照する）または他のユーザコンテキストを使用することによって、クランプドダウンユーザコンテキストを実装することも可能である。ローカルサービスユーザコンテキストとネットワークサービスユーザコンテキストの両方が、それに関連する特権の類似するセットを有するが、これらのユーザコンテキストによって提供される利益は、同一ではない。例えば、ネットワークサービスユーザコンテキストは、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムが動作するネットワークに結合された他のマシンによって認識される信任証を提供する。対照的に、ローカルサービスユーザコンテキスト信任証は、ユーザのローカルマシンだけで認識され、さらに、あるマシンのローカルサービスユーザは、他のマシンで認証されることができない。
【００８５】
図３のコンテキストで導入されたリソース情報共有機能性３２２は、集合的に、上で識別された３つのコンポーネント（５０２、５０４、５０６）を表す。この、上で説明したコンポーネントのそれぞれを、下で順番に説明する。
【００８６】
ａ．メディアサービスモジュール
まず、デバイス監視モジュール５２０は、ＵＰｎＰネットワーク３１４に結合されたデバイスから通知を受信する。例えば、このモジュール５２０は、ＵＰｎＰネットワーク３１４に追加された新しいレンダリングデバイスによって生成されたアナウンスメントを検出する。このモジュール５２０は、次に、メディアサーバ３０２内の他のモジュールにこのイベントについて通知し、これが、他のアクション（下で、例えば図１６および１７に関して詳細に説明する）をトリガする。デバイス監視モジュール５２０は、ＵＰｎＰネットワーク３１４に結合されたコントロールポイントによって行われた要求も検出する。図５からわかるように、リソース情報コンシューマ（例えば、簡潔にするために「コンシューマ」）は、メディアサーバ３０２によって提供されるリソースメタデータのブラウズまたは検索のために、そのような要求を開始することができる。次に、デバイス監視モジュール５２０は、この要求についてコンテンツディレクトリサービスモジュールに通知し、これによって、他のアクション（下で詳細に説明する）がトリガされる。
【００８７】
リソースモニタモジュール５２２は、新たに追加されたリソース、削除されたリソース、または変更されたリソースについて、リソースストレージ３２０（図３で紹介した）を監視する。変更を検出した時に、リソースモニタモジュール５２２は、リソースに対する変更についてコンテンツディレクトリサービスモジュール５２６に通知する。コンテンツディレクトリサービスモジュール５２６は、リソースストア３２０で提供されるリソースのディレクトリを維持する。図５からわかるように、コンテンツディレクトリサービスモジュール５２６は、リソースストア３２０によって提供されるリソースのブラウズまたは検索の要求を入力するコンシューマとも相互作用する。コンテンツディレクトリサービスモジュール５２６は、コンシューマの要求を満たし、要求に関連する可能性があるすべての配布判断基準を満足する使用可能なリソースを記述したリソースメタデータを取り出し、コンシューマに転送することによって、この要求に応答する。
【００８８】
リソースストア３２０自体は、リソースの単一のリポジトリまたは複数のリポジトリを表すことができる。リソースストア３２０は、磁気ストレージデバイス、光ストレージデバイス、ＥＥＰＲＯＭストレージデバイス、および／または他の種類のストレージデバイスを使用して実施することができる。リソースストア３２０にストアできる例示的な共有可能リソースに、  ．ｂｍｐイメージファイル、  ．ｇｉｆイメージファイル、  ．ｊｐｅｇイメージファイル、  ．ｐｎｇイメージファイル、  ．ｔｉｆｆイメージファイル、  ．ａｖｉビデオファイル、  ．ｍｐ３オーディオファイル、  ．ｍｐｅｇビデオｍｐｅｇファイル、  ．ｗａｖオーディオファイル、  ．ｗｍａオーディオファイル、  ．ｗｍｖビデオファイルなどが含まれる。これは、単に、例示的なリストである。リソースストア３２０は、メディアサーバ３０２の他の部分と同一の場所に置くか、１つまたは複数の位置に全体的にまたは部分的に置くことができる。後者の場合に、メディアサーバ３０２は、リソースストア３２０で提供されるリソースをリモート管理することができる。
【００８９】
リソース転送モジュール５２４は、メディアレンダリングデバイス（図３に示されたメディアレンダリングデバイス３０６など）へのリソースコンテンツの転送を調整する。一実施形態で、リソース転送モジュール５２４が、ＨＴＴＰサーバである。リソースコンテンツの転送は、リソースコンテンツ要求（ＨＴＴＰサーバが使用される場合にＨＴＴＰ  ＧＥＴ要求など）の受信によって開始される。リソース転送モジュール５２４は、関連する配布判断基準が満たされる（適用可能な場合に）と仮定して、リソースコンテンツを送信することによって応答する。一実施形態で、リソース転送モジュール５２４は、接続マネージャサービスモジュール５３０の助けを得てこのタスクを実行する。接続マネージャサービスモジュール５３０は、メディアサーバ３０２と、リソースコンテンツを受信するレンダリングデバイスとの間の結合を管理する。コントロールポイント（例えば、コントロールポイント３１６または３１８）は、このモジュール５３０を呼び出して、リソース情報のすぐれた転送のためにメディアサーバ３０２を準備することができる。この準備に、メディアサーバ３０２とレンダリングデバイスの機能の照合、ＵＰｎＰネットワーク３１４で進行中のリソース情報の転送に関する情報の発見、ならびにメディアサーバ３０２とレンダリングデバイスの間の接続のセットアップおよびティアダウンが必要になる可能性がある（ＨＴＴＰ技法を使用してリソースコンテンツ転送を実行する、特徴を示された例示的実施形態が、上で識別された機能の１つまたは複数をなしで済ませることによって処理を単純化できることに留意されたい）。
【００９０】
１つの例示的なＨＴＴＰ実施形態では、接続マネージャサービスモジュール５３０が、ＧｅｔＰｒｏｔｏｃｏｌＩｎｆｏメソッドをサポートすることができる。このメソッドは、メディアサーバ３０２がソースおよびシンクになることができるプロトコル情報タイプのコンマ区切りリストを返す。コントロールポイントは、この情報を使用して、メディアサーバ３０２と選択されたレンダリングデバイス（例えば、メディアレンダリングデバイス３０６）の間のメディア接続をセットアップする。各ＰｒｏｔｏｃｏｌＩｎｆｏエントリは、集合的にフォーマット：Ｐｒｏｔｏｃｏｌ：Ｎｅｔｗｏｒｋ：Ｃｏｎｔｅｎｔ＿Ｆｏｒｍａｔ：ＡｄｄｉｔｉｏｎａｌＩｎｆｏによって指定される、トランスポートプロトコル、ネットワーク、ＭＩＭＥ（ｍｕｌｔｉｐｕｒｐｏｓｅ  Ｉｎｔｅｒｎｅｔ  ｍａｉｌ  ｅｘｔｅｎｓｉｏｎｓ）タイプ、および追加情報の組合せである。
【００９１】
メディアサーバモジュール５０２に、オプションのオーディオ−ビジュアル（ＡＶ）トランスポートサービスモジュール（図示せず）も含めることができる。サポートされる場合に、ＡＶトランスポートサービスモジュールを使用して、レンダリングデバイスへのリソースコンテンツの再生を制御することができる。このモジュールは、特に、コントロールポイントが、リソースコンテンツの流れを停止し、リソースコンテンツの流れを一時停止し、リソースコンテンツ内の特定の位置を検索する（シーク機能を使用して）ことなどを可能にすることができる。
【００９２】
図５の特定の例では、メディアサーバモジュール５０２が、ＨＴＴＰサーバ５２４を使用して、リソースコンテンツの転送を調整することができる（ＨＴＴＰ  １．１サーバなど）。このサーバ５２４は、ＨＴＴＰ  ＧＥＴ要求の受信に応答して、リソースコンテンツをサービスする。ＨＴＴＰ  ＧＥＴ要求は、所望のリソースのＵＲＬを指定し、このＵＲＬは、受信側エンティティ（例えば、コントロールポイント）へのリソースメタデータの以前の転送に応答してメディアレンダリングデバイスに供給されたものであり、この受信側エンティティは、コンシューマの前の検索要求またはブラウズ要求によって促されたものである可能性がある。サーバ５２４は、関連する配布判断基準が適用可能な場合にそれが満足されるならば、指定されたＵＲＬに対応するリソースストア３２０からリソースコンテンツを取り出し、そのリソースコンテンツを要求されたメディアフォーマットに変換し（必要な場合に）、このリソースコンテンツをコンシューマに供給することによって応答する。リソースのＵＲＬは、次の例示的な形であるものとすることができる。
【００９３】
【表１】
2007515015.tif 000002
【００９４】
ここで、「ＲｅｓｏｕｒｃｅＩｄ」は、コンテンツディレクトリサービスモジュール５２６によってリソースコンテンツに割り当てられた識別子を指す。ＨＴＴＰ−ＧＥＴプロトコルの代わりに使用できる、リソースコンテンツを転送する他のプロトコルに、ＩＥＥＥ−１３９４、ＲＴＳＰ／ＲＴＰなどが含まれる。
【００９５】
コンテンツディレクトリサービスモジュール５２６は、メディアサーバ３０２がメディアレンダリングデバイスとリソース情報（特にリソースメタデータ）を共有できるようにする機能性のコアを提供する。これには、共有リソースストア５３２が含まれる。一実施形態で、共有リソースストア５３２に、共有される、リソースストア３２０で提供されるリソースを記述するディレクトリおよび関連リソースメタデータが含まれる。
【００９６】
具体的に言うと、一連の図をしばらく飛び越すと、図６に、共有リソースストア５３２内の情報を仮想リソースコンテナに編成するのに使用できる例示的な階層構造、例えばディレクトリ６００が示されている。この図では、「ｒｏｏｔ」リソースコンテナ６０２に、ディレクトリ６００内の他のすべてのリソースコンテナが含まれる。「ｍｕｓｉｃ」リソースコンテナ６０４に、音楽を分類したリソースコンテナが含まれる。「ｍｕｓｉｃ／ａｌｌ  ｍｕｓｉｃ」リソースコンテナ６０６に、コンテンツディレクトリ内で共有されるすべての音楽リソースが含まれる。「ｍｕｓｉｃ／ａｌｂｕｍ」リソースコンテナ６０８に、アルバムごとのリソースコンテナが含まれ、各そのようなリソースコンテナに、そのアルバムに属する音楽リソースが含まれる。「ｍｕｓｉｃ／ａｒｔｉｓｔ」リソースコンテナ６１０に、各アーティストのリソースコンテナが含まれ、各そのようなリソースコンテナに、そのアーティストによって作成されたすべての音楽のリソースが含まれる。「ｍｕｓｉｃ／ｇｅｎｒｅ」リソースコンテナ６１２に、各ジャンルのリソースコンテナが含まれ、各そのようなリソースコンテナに、そのジャンルに属する音楽のリソースが含まれる。
【００９７】
「ｖｉｄｅｏ」リソースコンテナ６１４に、ビデオを分類したリソースコンテナが含まれる。「ｖｉｄｅｏ／ａｌｌ  ｖｉｄｅｏ」リソースコンテナ６１６に、コンテンツディレクトリ内で共有されるすべてのビデオリソースが含まれる。「ｖｉｄｅｏ／ａｃｔｏｒ」リソースコンテナ６１８に、各俳優のリソースコンテナが含まれ、各そのようなリソースコンテナに、その俳優が主演したビデオリソースが含まれる。「ｖｉｄｅｏ／ｇｅｎｒｅ」リソースコンテナ６２０に、各ジャンルのリソースコンテナが含まれ、各そのようなリソースコンテナに、そのジャンルに属するビデオリソースが含まれる。
【００９８】
「ｐｉｃｔｕｒｅｓ」リソースコンテナ６２２に、写真を分類したリソースコンテナが含まれる。「ｐｉｃｔｕｒｅｓ／ａｌｌ  ｐｉｃｔｕｒｅｓ」リソースコンテナ６２４に、コンテンツディレクトリ内で共有されるすべてのイメージリソースが含まれる。（図示されていないが、「ｐｉｃｔｕｒｅｓ／ａｌｂｕｍ」リソースコンテナを含めることができ、このリソースコンテナに、フォルダ名に基づく写真アルバムのそれぞれのリソースフォルダが含まれる。さらに、図示されていないが、「ｐｉｃｔｕｒｅｓ／ｄａｔｅｔａｋｅｎ」リソースコンテナを含めることができ、このフォルダに、所与の日付にとられた写真の各グループのリソースコンテナが含まれる）。
【００９９】
最後に、「ｕｓｅｒ  ｆｉｌｅｓ」リソースコンテナ６２６に、個々のユーザに属するリソースを保持するリソースコンテナが含まれる。図６には、例示的なＮ人のユーザに関連するリソースコンテナのコレクション６２８が示されている。
【０１００】
ディレクトリ６００内のリソースコンテナのそれぞれは、オブジェクトＩＤを関連付けられることができる。例えば、Ｖｉｄｅｏ／Ａｃｔｏｒリソースコンテナは、「ｃｏｎｔａｉｎｅｒ：ＶｉｄｅｏＡｃｔｏｒ」というオブジェクトＩＤを有することができる。一般に、図６に示されたディレクトリ６００は、例示的であり、他のディレクトリは、リソースの異なる編成および選択を使用することができる。
【０１０１】
一実施形態で、ディレクトリ６００に示されたコンテナ内の個々のリソースのそれぞれが、リソースストア３２０にストアされた別々のめいめいのリソースファイルに対応することができる。しかし、前に述べたように、「リソース」は、情報の抽象的な集合と理解されなければならない。単一のリソースを、ファイルの一部だけを使用してストアすることができる（そのようなファイルに、他のリソースに関係する情報もストアすることができる）。その代わりに、単一のリソースを、異なるファイルの集合にまたがってストアすることができる。また、リソースコレクション（図６のリソースコンテナなど）自体が、リソースを構成することに留意されたい。
【０１０２】
図５を参照すると、共有リソースストア５３２に、ディレクトリ６００内の共有リソースに関連するリソースメタデータ５３４が含まれる。前に述べたように、リソースメタデータには、一般に、リソースコンテンツに関連する、名前、アーティスト、作成日付、リソースのサイズ、ＵＲＬなどのリソースロケータなど、リソースの内容を記述する高水準情報が含まれる。共有リソースストア５３２に、めいめいのコントロールポイントおよびレンダリングデバイスでの適当なコンシューマへのリソース情報（リソースメタデータおよびリソースコンテンツを含む）の散布を制限するのに使用されるリソースコレクション（例えば、リソースフォルダまたはリソースコンテナ）に関連する判断基準を記述した判断基準情報５３６もストアすることができる。上で述べたように、１つの例示的な判断基準は、どのデバイスがリソース情報の受信を許可されるかを決定することができる。もう１つの判断基準は、リソース情報の転送を行うために、メディアサーバ３０２を操作する指定された個人（いる場合に）が同意を提供することを要求されるかどうかを決定することができる。
【０１０３】
具体的に言うと、セクションＡ．１で説明したように、判断基準情報５３６に、２セットの判断基準すなわち、リソースメタデータの散布を決定するセットとリソースコンテンツの散布を制御するもう１つのセットを含めることができる。これらのセットは、２つの別々のストアとして、共通のストアに関連するフィールドまたは属性として、あるいは他の技法を使用して、実装することができる。判断基準の第１セットを、判断基準の第２セットと異なるものとすることができ、これは、リソースコンテンツのレンダリングと比較して、異なる制約がリソースメタデータの表示を決定することを示し、あるいは、この２セットを同一とすることができる。あるいは、リソースメタデータ、リソースコンテンツ、またはリソースメタデータおよびリソースコンテンツの両方の散布を決定する、単一のセットを使用することができる。下での議論を容易にするために、判断基準情報５３６が、判断基準の単一のセットを保持し、その単一のセットが、リソースメタデータならびにリソースコンテンツを分け与えることに適用されると仮定する。
【０１０４】
一実施形態で、リソースメタデータ５３４が、個々の共有リソースに関連し、共有リソースは、リソースストア３２０にストアされたファイルに対応することができる。この場合に、リソースメタデータ５３４を、サービス初期化で共有ファイルを「クロール」することによって抽出することができる。共有ファイルの個数によっては、この動作が、はっきりと感知できる時間を要する可能性がある。もう１つの実施形態で、リソースメタデータ５３４を、共有リソースストア５３２内のリレーショナルデータベースで永続させることができる。もう１つの例で、リソースメタデータ５３４を、リソースストア３２０内のすべての共有ファイルから抽出し、１つまたは複数の別々のファイルにストアすることができる（例えば、メディアサーバ３０２が、リソースストア３２０内で使用されるすべてのファイルシステムボリュームについて別々のファイルを使用することができ、各ファイルシステムボリュームは、別々のドライブ文字に対応することができる。この備えは、特にＵＳＢハードドライブなどのリムーバブルボリュームが使用される場合に、リソースメタデータの収集を容易にする；メディアサーバ３０２は、対応するドライブが現在マウントされている場合に限って、ボリュームからのリソースメタデータの読み取りを試みる）。リレーショナルデータベースおよび／または別々のファイルを使用することによって、メディアサーバ３０２の初期化に関連する時間が減る。例えば、別々のファイル戦略が使用される場合に、情報を抽出するためにリソースストア３２０全体を苦労してクロールするのではなく、別々のファイルを素早くロードしてリソースメタデータ５３４を提供することができる。
【０１０５】
同様に、一実施形態で、判断基準情報５３６を、リソースストア３２０によって提供される個々の共有リソースフォルダに関連付けることができる。この事例では、共有ファイル（リソースストア３２０によって提供されるめいめいの共有リソースフォルダに属する）に関係する判断基準情報５３６を、上で説明したものとほぼ同一の形で、サービス初期化時に共有リソースフォルダを「クロール」することによって抽出することができる。これは、はっきりと感知できる時間を要する可能性がある。したがって、このプロセスをはかどらせるために、メディアサーバ３０２は、リレーショナルデータベース戦略および／または別々のファイル戦略（リソースメタデータ５３４のストレージおよび管理に関して上で説明した事例に似る）に頼ることができる。一実施形態で、リソースメタデータ５３４を提供するのに使用されるメタデータ固有のリレーショナルデータベースおよび／または別々のファイルと別個の、判断基準固有のリレーショナルデータベースおよび／または別々のファイルが、判断基準情報５３６を提供するのに使用される。もう１つの実施形態で、単一のリレーショナルデータベースおよび／または別々のファイルを使用して、リソースメタデータ５３４および判断基準情報５３６の両方をストアすることができる。もう１つの実施形態で、リソースメタデータ５３４および／または判断基準情報５３６を、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムレジストリで永続させ、そこから読み戻すことができる。
【０１０６】
上で注記したように、一実施形態で、判断基準情報５３６を、リソースフォルダに適用することができる。メディアサーバユーザは、リソースフォルダに関する情報を表示する１つまたは複数のユーザインターフェースページを介してこの関連付けを作成することができる。もう１つの実施形態で、判断基準情報を、ディレクトリ６００（図６に図示）内のリソースコンテナまたはディレクトリ６００に含まれる個々のリソースに関連付けることができる。メディアサーバ３０２は、やはり、リソースコンテナに関する情報を表示する１つまたは複数のユーザインターフェースページを介してこの関連付けを作成することができる。次の議論では、前者の事例（リソースフォルダの判断基準への関連付けの）を実装する機能性を説明するが、類似する機能性を、後者の事例（リソースコンテナの判断基準への関連付けの）を実装するために提供することができる。どちらの場合でも、配布判断基準を、リソースメタデータおよびリソースコンテンツの散布を決定するのに使用することができる。リソースコンテナの編成（メディアサーバ３０２でのリソースの内部編成を指す）は、一般に、リソースフォルダの階層（メディアサーバユーザが相互作用するリソースの編成を指す）と一致すると期待することができないが、この２つの編成（例えば、リソースコンテナとリソースフォルダ）の間に関係がある場合がある。
【０１０７】
リソースメタデータ５３４の構成にどの方法が使用されても、メディアサーバ３０２は、リソースメタデータ５３４を保持するのに使用されるストアにどのメタデータがストアを許可されるかに関する様々な制約を課すことができる。１つの例で、次の例示的な制約が適用される：（ａ）リソース情報を共有するメディアサーバユーザが、ストアされるリソース情報をストアするファイルに関する読み取り許可を有しなければならず、（ｂ）共有されるリソース情報をストアするファイルが、既知のメディアタイプを有しなければならず、（ｃ）共有されるリソース情報をストアするファイルが、ハードリンクまたはブラウザショートカットである場合に、そのリソース情報の共有を試みるメディアサーバユーザが、基礎になるリソースの読み取り許可を有しなければならず、（ｄ）共有されるリソース情報をストアするファイルが、隠されることができず、（ｅ）共有されるリソース情報をストアするファイルが、隠しサブフォルダになることができず、（ｆ）共有されるリソース情報をストアするファイルを、リムーバブルドライブにストアすることができず、（ｇ）共有されるリソース情報をストアするファイルを、ネットワーク共有に置くことができない。やはり、これらの制約は、単なる例示であり、他の応用例は、特定の応用例の要件に応じて、これらの制約の１つまたは複数を緩和するか除去することができる。
【０１０８】
図５の議論を継続すると、コンテンツディレクトリサービスモジュール５２６に、共有リソース管理ストレージモジュール５３８も含まれる。このモジュール５３８は、一般に、共有リソースストア５３２にストアされた情報を管理する役割のために働く。例えば、共有リソース管理モジュール５３８は、リソースがリソースストア３２０に追加されたか、変更されたか、削除されたことをリソースモニタモジュール５２２が通知する時に、共有リソースストア５３２を更新する。
【０１０９】
一実施形態で、共有リソース管理モジュール５３８は、共有リソースフォルダのそれぞれを最初に共有したメディアサーバユーザを記憶する。共有リソースフォルダを確立したメディアサーバユーザがその共有リソースフォルダに関連する判断基準情報５３６を変更するか、そのリソースフォルダを「共有解除」する（すなわち、そのリソースフォルダの共有可能状況を除去する）ことだけを許可するように共有リソース管理モジュール５３８を構成することができる。例えば、一実施形態で、メディアサーバユーザが、ファイルＡ、Ｂ、およびＣを共有するアクセス特権を確立したと仮定する。この場合に、このユーザがこれらのファイルの配布判断基準を適用することだけを許可するように共有リソース管理モジュール５３８を構成することができる。あるいは、ファイルＡ、Ｂ、およびＣが、このメディアサーバユーザが共有の許可を有しない他のリソースを含むフォルダにグループ化されたと仮定する。共有リソース管理モジュール５３８が、メディアサーバユーザが配布判断基準をフォルダに適用することを許可するように構成されている場合に、これらの判断基準は、それでも、ファイルＡ、Ｂ、およびＣについて有効である。他の実施形態は、様々な形でこの制約を緩和することができる。
【０１１０】
リソースメタデータ５３４が、１つまたは複数の別々のファイルで提供される場合に、共有リソース管理モジュール５３８に、これらの別々のファイルを維持する機能性も含めることができる。この機能性に、サービス初期化時にディレクトリ６００内で識別される共有ファイルの変化を探してリソースストア３２０の共有ファイルを「クロール」するバックグラウンドプロセスを含めることができる。この機能性に、リソースフォルダ内で変更が検出された場合に通知を提供するためにリソースモニタモジュール５２２と相互作用する機構も含めることができる。共有リソース管理５３８は、別々のファイルが壊れていると判定された場合に、これらのファイルを捨てることができ；共有リソース管理モジュール５３８は、その後、メタデータを抽出するために共有リソースフォルダをクロールすることによって、この別々のファイルを再構成することができる。一般に、共有リソース管理モジュール５３８は、様々な他のコヒーレンシ技法を使用して、別々のファイルが共有リソースのメタデータを正確に反映することを保証することができる。
【０１１１】
動作中に、コンテンツディレクトリサービスモジュール５２６は、一般に、コンシューマが共有リソースに対応するリソースメタデータを調査できるようにする。具体的に言うと、通常の相互作用で、コンシューマは、ディレクトリ６００で提供される共有リソースに関連するリソースメタデータをブラウズまたは検索する要求をコントロールポイントを介して送信する。デバイス監視モジュール５２０は、下で詳細に説明する形でこの要求を検出し、これに応答して、コンテンツディレクトリサービスモジュール５２６に通知する。コンテンツディレクトリサービスモジュール５２６は、リソースメタデータ５３４をスキャンして、コンシューマの要求を満たすすべてのリソースを突き止めることによって応答する。例えば、コンシューマが、あるジャンルのリソースメタデータのすべてを示すようにコンテンツディレクトリサービスモジュール５２６に要求した場合があり、あるいは、コンシューマが、ターゲットのリソースに関するリソースメタデータを提供するようにコンテンツディレクトリサービスモジュール５２６に要求した場合がある（例えば、ターゲットのリソースの検索で使用される特定のキーワードを指定することによって）。このプロセスが、１つまたは複数の一致するリソースメタデータアイテムを生じる場合がある。その後、コンテンツディレクトリサービスモジュール５２６は、適用可能な場合に、共有リソースストア５３２にストアされた判断基準情報５３６に対してすべての一致するリソースメタデータを検査し、関連する判断基準に合致しないすべての一致するリソースメタデータアイテムを選り分ける（この備えを非アクティブ化し、その結果、判断基準情報がリソース情報の散布で役割を演じないようにすることが可能である）。次に、コンテンツディレクトリサービスモジュール５２６は、残った一致するリソースメタデータのリストをＸＭＬメッセージにフォーマットし、次に、このＸＭＬメッセージをコンシューマに送信する。このリソースメタファイルは、個々の一致するリソースならびに、適用可能な場合に、個々のメンバリソースを含むリソースコレクション（リソースコンテナなど）を記述することができる。
【０１１２】
受取り側のコントロールポイントデバイスは、このＸＭＬメッセージをプレゼンテーションフォーマット（例えば、ＨＴＭＬ）に変換し、この情報のコンシューマによるレビューのために表示することができる。この表示によって、一致するリソースメタデータを識別するメディアリストを提供することができる。次に、コンシューマは、このメディアリスト内の１つまたは複数のアイテムに関連するリソースコンテンツを再生するようにメディアレンダリングデバイス３０６に指令することができる。これは、レンダリングデバイス３０６などの選択されたレンダリングデバイスに、メディアリスト内の選択されたアイテムに関連するリソースロケータ（ＵＲＬなど）を渡すことによって実行することができる。これらのリソースロケータは、メディアサーバ３０２によってコンシューマに送信されたＸＭＬメッセージで指定されたものである（しかし、やはり、ブラウズ動作の結果が、リソースコンテナ、例えばコンテナのリストを返すことができることに留意されたい。リソースコンテナは、リソースロケータを関連付けられている場合とそうでない場合があり、関連付けられていない場合に、それ自体を再生のためにレンダリングデバイスで提示することはできないが、コンテナ内で識別される個々のリソースを提示することはできる）。
【０１１３】
メディアサーバモジュール５０２の他の１つのコンポーネントが、コントロールパネルＣＯＭオブジェクト５４０である。一般に、このオブジェクト５４０は、コントロールパネルモジュール５０６が、メディアサーバモジュール５０２内でコンフィギュレーションデータを取り出し、セットできるようにする。例示的な実施形態では、オブジェクト５４０が、コンポーネントオブジェクトモデル（ＣＯＭ）オブジェクトである。一般に、ＣＯＭオブジェクトは、１つまたは複数のタスクを実行する。すなわち、ＣＯＭオブジェクトは、アプリケーションが呼び出せるインターフェースを介して機能を公開して、それに帰するタスクを実行する。
【０１１４】
メディアサービス５０２のコンテキストで、コントロールパネルモジュール５０６は、コントロールパネルＣＯＭオブジェクト５４０を介してメディアサービスモジュール５０２を呼び出す。この役割のために働くために、コントロールパネルＣＯＭオブジェクト５４０は、次の例示的なタスクを実行する。第１に、コントロールパネルＣＯＭオブジェクト５４０は、コントロールパネルモジュール５０６が、発見されたデバイスを列挙し、その現在の状態（例えば、承認されているか、拒否されているか、承認も拒否もされていないかどうか）を取り出し、ＵＩに与えるのに使用されるデバイス情報（デバイスの製造業者、アイコン、モデル番号など）を得、デバイスを承認するか拒否することを可能にする。第２に、コントロールパネルＣＯＭオブジェクト５４０は、コントロールパネルモジュール５０６が、リソースストア３２０にストアされた共有可能リソースを含む共有されたリソースフォルダおよびこれらのリソースフォルダに関連するすべての関連する配布判断基準情報５３６（これらの共有されたリソースフォルダに関連するリソース情報を受信することを許可されたデバイスのリストなど）のリストを管理できるようにする。このために、コントロールパネルＣＯＭオブジェクト５４０は、コントロールパネルモジュール５０６が、現在共有されているリソースフォルダおよびそれに関連する配布判断基準情報５３６のリストを取り出し、これらのリソースフォルダの共有を解除し、新しい共有リソースフォルダおよび／または配布判断基準を作成し、共有リソースフォルダに関連する配布判断基準を変更することなどを可能にする。最後に、メディアサービスモジュール５０２は、ＵＰｎＰネットワーク３１４で新しいコントロールポイントまたはメディアレンダリングデバイスを発見した時に、コントロールパネルＣＯＭオブジェクト５４０およびコントロールパネルがホスティングするコールバックオブジェクト５４２（下で詳細に説明する）を使用して、コントロールパネルモジュール５０６に通知する。
【０１１５】
高速ユーザ切替（ＦＵＳ）に対処するために、メディアサーバ３０２は、複数のコントロールパネルモジュール５０６を同時にアクティブにすることを可能にする。しかし、一実施形態で、メディアサーバ５０２は、各端末サービスセッションが、１つのアクティブなコントロールパネルモジュール５０６を有することだけを許可する。
【０１１６】
ｂ．ＣＤＤＭサービスモジュール
上で説明したように、メディアサービスモジュール５０２は、ローカルサービスユーザコンテキスト（または、より一般定にはクランプドダウンユーザコンテキスト）で動作し、ＣＤＤＭサービスモジュール５０４は、ローカルシステムユーザコンテキストで動作する。ローカルサービスユーザコンテキストは、一般に、ローカルシステムユーザコンテキストと比較して、より制限的なアクセス特権を有する。したがって、メディアサーバモジュール５０２は、ＣＤＤＭサービスモジュール５０４に頼って、それ自体で実行するアクセス権を有しない一連の機能を実行する。１つの例示的な実施形態に従ってＣＤＤＭサービスモジュール５０４に委任される特権機能を、下で説明する。
【０１１７】
第１に、ＣＤＤＭサービスモジュール５０４は、新しいメディアレンダリングデバイス３０６またはコントロールポイント３１６がデバイス監視モジュール５２０によってＵＰｎＰネットワーク３１４で検出された時に、コントロールパネルモジュール５０６を始動する役割を実行する。これによって、メディアサーバユーザが、そのデバイスを承認するか拒否することができるようになる。承認されたデバイスは、その後、メディアサーバ３０２の共有リソースに対応するリソース情報（リソースメタデータおよびリソースコンテンツ）へのアクセスを許可される。ＣＤＤＭサービスモジュール５０４は、（ａ）メディアサーバユーザがメディアサーバ３０２コンピュータにログオンし（または、下で説明するように、このコンピュータ上の前に確立されたターミナルサーバセッションに再接続し）、（ｂ）メディアサーバ３０２が、メディアサーバユーザによって承認も拒否もされたことがない前に検出されたデバイスを有する場合にも、コントロールパネルモジュール５０６を始動する。
【０１１８】
さらに、ＣＤＤＭサービスモジュール５０４は、様々なエラーまたは状態についてメディアサーバユーザに警告するために、コントロールパネルモジュール５０６を始動する。例えば、ＣＤＤＭサービスモジュール５０４は、ネットワークインターフェースが、許される前に構成されたＩＰアドレス範囲（例えば、プライベートＩＰアドレス範囲またはＡｕｔｏ  ＩＰアドレス範囲）内のＩＰアドレスを有することがわかっていない時に、メディアサーバユーザに警告することができる。ＣＤＤＭサービスモジュール５０４は、リソース情報共有機能性３２２サービスが動作していない時に、リソースストア３２０の共有リソースフォルダが削除されたか名前を変更されていることをメディアサーバユーザに警告することができる。一般に、ＣＤＤＭサービスモジュール５０４は、現在アクティブなログオンしたユーザのコンテキストでコントロールパネルモジュール５０６を起動する。ＣＤＤＭサービスモジュール５０４は、ログオンしたユーザのトークンを取り出し、ＣｒｅａｔｅＰｒｏｃｅｓｓＡｓＵｓｅｒ関数を呼び出すことによって、コントロールパネルモジュール５０６を起動する。しかし、そうする前に、ＣＤＤＭサービスモジュール５０４は、コントロールパネルモジュール５０６が、まだ、現在アクティブなログオンしたユーザのターミナルサーバセッションで動作していないことを確実にする。
【０１１９】
第２に、ＣＤＤＭサービスモジュール５０４は、ストアされたリソースフォルダに関連するアクセス特権を調整し、その結果、メディアサーバモジュール５０２が、リソースフォルダにアクセスして、それに帰する機能（リソースメタデータ５３４の作成など）を実行できるようにする。これは、ローカルサービスユーザコンテキストによるアクセスを可能にするために共有リソースフォルダに関連するアクセス制御リスト（ＡＣＬ）を変更することによって実行することができる。例示的な実施形態で、これによって、ローカルサービスユーザコンテキストに、リソースフォルダの内容に対する読み取りアクセス、書き込みアクセス、および削除アクセスが与えられる（すなわち、リソースフォルダは、ローカルサービスユーザコンテキストに、読み取りアクセスに加えて、書き込みアクセスおよび削除アクセスを与えるようにＡＣＬを設定される；これは、一部のメディアタイプが、ＵＰｎＰネットワーク３１４で使用可能にされる前に、デコードされなければならないからである。ファイルをデコードするのに使用されるツールは、時々、ファイルを含むディレクトリにテンポラリファイルを作成する。その後、このテンポラリファイルを削除しなければならない）。
【０１２０】
第３に、ＣＤＤＭサービスモジュール５０４は、メディアサーバ３０２を監視して、新しいメディアサーバユーザが、メディアサーバ３０２の実装に使用されているコンピュータシステムにサインオンまたはログオフする時を検出する。ＣＤＤＭサービスモジュール５０４は、メディアサーバ３０２にログオンしているメディアサーバユーザのアイデンティティも確認する。すなわち、上で説明したように、メディアサービスモジュール５０２は、メディアサーバコンピューティングマシンで現在アクティブであるログオンしたメディアサーバユーザのアイデンティティに依存して、リソース情報の共有を制限することができる。したがって、メディアサービスモジュール５０２は、ＣＤＤＭサービスモジュール５０４によって抽出されたユーザ情報を使用して、現在アクティブなログオンしたメディアサーバユーザを考慮して、リソース情報を共有する許可を有するかどうかを判定する（ＣＤＤＭサービスモジュール５０４は、ＷＴＳＱｕｅｒｙＵｓｅｒＴｏｋｅｎ関数を使用して、ログオンしたメディアサーバユーザのトークンを取り出すことと、ＧｅｔＴｏｋｅｎＩｎｆｏｒｍａｔｉｏｎ関数を使用して、そのトークンからメディアサーバユーザのＳＩＤを取り出すことによって、メディアサーバユーザのアイデンティティを判定することができる）。
【０１２１】
ｃ．コントロールパネルモジュール
コントロールパネルモジュール５０６は、メディアサーバユーザがＵＰｎＰネットワーク３１４に追加された新しいデバイスの許可を承認または否定できるようにする機能性を提供する。コントロールパネルモジュール５０６は、メディアサーバユーザが共有リソースフォルダおよび関連する配布判断基準を定義できるようにもする。上で説明したように、１つの判断基準が、リソース情報（例えば、リソースメタデータおよびリソースコンテンツ）の散布を指定されたデバイスだけに制限することができる。もう１つの判断基準が、メディアサーバ３０２を使用する指定された個人がリソース情報の共有の暗黙のうちにまたは明示的な承認を与えたかどうかを条件としてリソース散布を行うことができる。指定された個人は、単純にメディアサーバ３０２にログオンし、その個人のセッションが現在アクティブである場合に、暗黙の承認を与えたと考えられる（一実施形態で）。コントロールパネルモジュール５０６は、一連のＵＩプレゼンテーション（例えば、ＵＩページ）を介して、上で識別したタスクを実行することができる。これらのＵＩプレゼンテーションは、下のセクションＢで詳細に説明する。コントロールパネルモジュール５０６は、アプレットとして実装することができ（アプレットは、アプリケーションのコンテキスト内で実行されるプログラムである）、ログオンしたメディアサーバユーザのコンテキストで動作することができる。
【０１２２】
メディアサーバ３０２は、２つの形でコントロールパネルモジュール５０６をアクティブ化することができる。第１に、メディアサーバユーザが、コントロールパネルモジュール５０６を手作業でアクティブ化することができる。第２に、メディアサービスモジュール５０２は、例えば新しいレンダリングデバイスがＵＰｎＰネットワーク３１４に加わった時にメディアサーバユーザに通知するためなど、自動的にコントロールパネルモジュール５０６を起動することができる。
【０１２３】
一実施形態で、メディアサーバ３０２は、各ターミナルサーバセッションで、コントロールパネルモジュール５０６の単一のインスタンスを提供する。したがって、コントロールパネルモジュール５０６は、始動する時に、コントロールパネルモジュール５０６の別のインスタンスがそのターミナルサーバセッションで既に動作していないことを検証する。次に、コントロールパネルモジュール５０６は、メディアサービスモジュール５０２が動作しているかどうかを判定し、そうでない場合には、コントロールパネルモジュール５０６がそれを始動する。次に、コントロールパネルモジュール５０６は、メディアサービスモジュール５０２がホスティングする（上で説明した）コントロールパネルＣＯＭオブジェクト５４０を、協同で作成する。最後に、コントロールパネルモジュール５０６は、それがホスティングするクライアントコールバックＣＯＭモジュール５４２を作成し、次に、コントロールパネルＣＯＭオブジェクト５４０に関連するＩｎｉｔｉａｌｉｚｅ（）メソッドを呼び出し、クライアントコールバックオブジェクト５４２を渡す。メディアサーバモジュール５０２は、クライアントコールバックオブジェクト５４２を使用して、サービスシャットダウン、バックグラウンドデータ変更、またはコントロールパネルモジュール５０６が動作している間のＵＰｎＰネットワーク３１４での新しいコントロールポイントまたはメディアレンダリングデバイスの発見などのイベントについてコントロールパネルモジュール５０６に通知する。
【０１２４】
Ａ．４．高速ユーザ切替（ＦＵＳ）の備え
ＦＵＳ技法は、異なるめいめいのメディアサーバユーザに関連する異なるコンピューティングセッションの間の切替の便利な技法を提供する。例えば、この技法を用いると、第１メディアサーバユーザが、コンピュータに接続し、アプリケーションを実行できるようになり、それに、別のアプリケーションを実行する第２メディアサーバユーザが続く。第２メディアサーバユーザが、コンピュータに接続する時に、コンピュータは、第１メディアサーバユーザのセッションに関連するアプリケーションインスタンスおよびデスクトップ設定を保存する。第１メディアサーバユーザが、コンピュータにもう一度接続する時に、コンピュータは、第１メディアサーバユーザが切断した時のそのユーザのコンピュータセッションに関連するアプリケーションおよび設定を復元する。ＦＵＳ技法は、連続してコンピュータを使用する異なるめいめいのメディアサーバユーザに関連する複数のアプリケーションインスタンスおよびデスクトップ設定を記録することによって、上で説明した形で任意の人数のメディアサーバユーザの間でトグルすることができる。ＦＵＳを提供する１つの例示的な商業製品が、米国ワシントン州レッドモンドのＭｉｃｒｏｓｏｆｔ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎ社が提供するＷｉｎｄｏｗｓ（登録商標）ＸＰ（登録商標）オペレーティングシステムである。対照的に、従来のコンピューティングソリューションでは、コンピュータは、第２メディアサーバユーザが接続できるようにする前に第１メディアサーバユーザがログアウトし、これによって、第２メディアサーバユーザが同一のコンピュータに接続する際に第１メディアサーバユーザのアプリケーションを終了することを必要とする。
【０１２５】
メディアサーバ３０２へのＦＵＳ技法の適用によって、コントロールパネルモジュール５０６の複数のインスタンスが同時に存在できるようになる。例えば、上で説明したように、コントロールパネルモジュールインスタンス５０６は、メディアサーバユーザＡ  ５０８に関連し、コントロールパネルモジュールインスタンス５１０は、メディアサーバユーザＢ  ５１２に関連し、コントロールパネルモジュールインスタンス５１４は、メディアサーバユーザＣ  ５１６に関連する。しかし、上で説明したＵＰｎＰメディアサーバ環境へのＦＵＳ技法の適用は、様々な課題を提出する。このセクションでは、上で説明したＵＰｎＰメディアサーバ３０２のコンテキストでこれらの課題に対処する例示的なＦＵＳソリューションを説明する。
【０１２６】
第１に、メディアサーバ３０２は、上で説明したように、同時に動作するコントロールパネルモジュール５０６の複数のインスタンスに対処するが、メディアサーバ３０２は、各ターミナルサーバセッションが１つのコントロールパネルモジュール５０６を有することだけを許容する。この特徴を実施するために、メディアサーバ３０２は、各コントロールパネルモジュール５０６が、ＣＯＭオブジェクト５４０を使用する前に、このオブジェクト５４０を作成し、初期化する（Ｉｎｉｔｉａｌｉｚｅ（）メソッドを呼び出すことによって）ことを要求する。Ｉｎｉｔｉａｌｉｚｅメソッドを呼び出す時に、呼出し元は、クライアントコールバックＣＯＭオブジェクト５４２を供給しなければならない。
【０１２７】
具体的に言うと、クライアントがＩｎｉｔｉａｌｉｚｅ（）メソッドを呼び出す時に、メディアサーバモジュール５０２は、クライアントの偽装トークンからクライアントのターミナルサーバセッションＩＤを抽出する。次に、メディアサービスモジュール５０２は、このセッションＩＤが別のクライアントに関連するかどうかを判定する。そうである場合に、メディアサービスモジュール５０２は、そのクライアントのコールバックオブジェクト５４２を呼び出して、そのクライアントがまだ「生きている」かどうかを判定する。クライアントがまだ生きている場合に、新しいクライアントを拒絶する。そうでない場合に、メディアサービスモジュール５０２は、新しいクライアントを受け入れ、そのクライアントのコールバックオブジェクト５４２を将来の使用のために保存する。
【０１２８】
第２に、メディアサーバ３０２は、複数のメディアサーバユーザに対処するので、ネットワーク３１４への新しいデバイスの導入時に、複数のログオンしたメディアサーバユーザに通知するようにメディアサーバ３０２を構成することができる。メディアサーバ３０２は、デバイスが発見された時にメディアサーバユーザが１人もメディアサーバ３０２にログオンしていない（または、メディアサーバユーザがログオンしているがデバイス発見の時にアクティブでない）シナリオにも対処する。この場合に、メディアサーバ３０２は、メディアサーバユーザがログオンするか既存セッションを再開するまで、新しいデバイスの存在についてメディアサーバユーザに通知するのを延期する。
【０１２９】
第３に、コントロールパネルモジュール５０６は、このモジュールの他のインスタンス（例えば、インスタンス５１０および５１４）が同時にアクティブであり、デバイスの許可状況または共有リソースフォルダのリストなどのグローバルデータを変更している可能性があることを認識する。この状況に対処するために、メディアサーバ３０２は、クライアントのいずれかがグローバルデータを変更する時にアクティブであるすべてのクライアントに関連するＣＯＭクライアントコールバックオブジェクト５４２に通知する。
【０１３０】
最後に、メディアサーバ３０２には、コントロールパネルモジュール５０６に「なりすます」ことができる、いわゆるならず者アプリケーションを排除する機構も含まれる。図５に、１つの例示的なそのような、ならず者アプリケーション５４４を示す。具体的に言うと、メディアサーバ３０２は、メディアサービスモジュール５０２とコントロールパネルモジュール５０６の間でプライベートＡＰＩとして（メディアサーバ３０２の内部コンポーネントを一緒に結合するので）ＡＰＩ  ５１８を実装する。個人がＡＰＩ  ５１８のリバースエンジニアリングを試み、ならず者アプリケーション５４４が、メディアサービスモジュール５０２を呼び出し、そのコンフィギュレーションデータをタンパリングできるようにする可能性が存在する。
【０１３１】
この懸念に対処するために、メディアサービスモジュール５０２は、クライアントがコントロールパネルＣＯＭオブジェクト５４０に関連するＩｎｉｔｉａｌｉｚｅ（）メソッドを成功裡に呼び出す時に、各クライアントに一意のクライアントＩＤを割り当てる。具体的に言うと、メディアサービスモジュール５０２は、クライアントのコールバックオブジェクト５４２に関連するメソッドを呼び出すことによって、このＩＤについてクライアントに通知する。メディアサービスモジュール５０２は、割り当てられたＩＤを記録する。次に、クライアントが後にサービスを呼び出す時に、クライアントがそのクライアントＩＤを提供することが期待される。メディアサービスモジュール５０２は、呼出し元が現在供給するＩＤを検出し、このＩＤを前に記録されたクライアントＩＤと比較する。すなわち、メディアサービスモジュール５０２は、クライアントのターミナルサーバセッションＩＤをその偽装トークンから取り出すことによって、クライアントを独立に識別することができ、したがって、クライアントによって供給されなければならないクライアントＩＤを知っている。これらのＩＤが一致する場合に、メディアサービスモジュール５０２は、呼び出しを許可し、そうでない場合には、メディアサービスモジュール５０２は、呼び出しを拒絶する。
【０１３２】
上で述べたように、複数のユーザが、同時にメディアサーバ３０２にログオンすることが可能である。ユーザに関連するめいめいのクライアントトークンから抽出されたターミナルサービスセッションＩＤに基づいてユーザを区別するようにメディアサーバ３０２を構成することができる。
【０１３３】
これによって、クライアントＩＤは、ならず者アプリケーション５４４がコントロールパネルモジュール５０６に「なりすます」ことを防ぐ。ＩＤについてクライアントに通知するためのクライアントコールバックオブジェクト５４２の使用は、ならず者アプリケーションに対する余分の保証を提供する（Ｉｎｉｔｉａｌｉｚｅ（）メソッドの引数としてＩＤを返すという代替技法と比較して）。これは、ならず者アプリケーション５４４が、Ｉｎｉｔｉａｌｉｚｅ（）メソッドを呼び出す時にＣＯＭクライアントコールバックオブジェクト５４２を提供するという追加のハードルに出会わなければならないからである。
【０１３４】
メディアサーバ３０２は、メディアサービスモジュール５０２とコントロールパネルモジュール５０６が、この２つのコンポーネントに間の形式的な相互作用を確立する前に他の秘密情報を交換することを要求することによって、セキュリティの追加レイヤを提供することができる。
【０１３５】
Ａ．５．追加のセキュリティの備え
上で説明したリソース共有特徴（判断基準情報５３６を使用して実施される）は、メディアサーバユーザがプライベートに保つことを望む（例えば、図４に関して述べた例示的な家庭関連応用例で示した複数の理由から）リソース情報へ許可されたユーザがアクセスするのを防ぐことに最も一般的な用途を見出す。類似するプライバシの懸念が、寄宿舎の部屋の応用例に関して存在する（これは、一般に、比較的多数の許可されたユーザがいる可能性があるが、メディアサーバユーザが、このＵＰｎＰネットワーク３１４の許可された参加者のサブセットだけにあるリソース情報を選択的に与えることを望むすべての設定へのＵＰｎＰネットワーク３１４の適用を指す）。
【０１３６】
上で説明したリソース共有特徴は、許可されないエンティティによるアクセスに対してＵＰｎＰネットワーク３１４のリソースを保護する機構も提供する。すなわち、リソース共有特徴は、リソースの散布をデバイスの既知の集団に制限する。したがって、この既知の集団の外部のデバイスは、ＵＰｎＰネットワーク３１４のリソースにアクセスすることを禁止される。リソース共有特徴は、リソース情報転送を、指定されたメディアサーバユーザの暗黙の同意または明示的同意を条件とするものにすることによって、追加の保証も提供する。
【０１３７】
しかし、リソース共有特徴は、特に許可されない（許可されるのではなく）ユーザの場合に関して、ＵＰｎＰネットワーク３１４が直面するすべての既知のセキュリティ脅威に対処しない可能性がある。さらに、許可されないユーザによって提示されるセキュリティ脅威は、性質において動的かつ便宜主義的であり、したがって、メディアサーバユーザが、リソース共有特徴がＵＰｎＰネットワーク３１４のセキュリティに対する将来の予想されない挑戦に耐えられないという懸念を抱く可能性がある。
【０１３８】
上の懸念は、特に許可されないユーザに対してＵＰｎＰネットワーク３１４のリソース情報を保護するためにリソース共有特徴に追加のセキュリティ機構を補足することを保証する。追加の手段は、許可されたユーザが、彼らによる消費を意図されていないプライベートリソース情報を受け取らないことをさらに保証するためにも望ましい。具体的に言うと、ＵＰｎＰネットワーク３１４が直面する少なくとも２つのセキュリティの懸念がある。第１のセキュリティの懸念は、許可されないエンティティがＵＰｎＰネットワーク３１４によって提供されるリソース情報を「盗聴」する可能性によって提出される。このエンティティは、ＵＰｎＰネットワーク３１４の外部で動作しており、ケーブルモデム、ＤＳＬモデム、ダイヤルアップ接続性、無線接続性、または他の結合戦略を介してＵＰｎＰネットワーク３１４の盗聴を試みている可能性がある。第２の懸念は、許可されたエンティティまたは許可されないエンティティがＵＰｎＰネットワーク３１４のオリジナルスコープの外部の多数の聴衆にリソース情報を配布する可能性によって提出される。これを、「スーパーディストリビューション（ｓｕｐｅｒｄｉｓｔｒｉｂｕｔｉｏｎ）」シナリオと呼ぶ。スーパーディストリビューション（超流通）は、意図的または意図的でないものである可能性がある。
【０１３９】
このセクションでは、上の２つの懸念に対処する複数の技法を説明する。これらの技法のどれをも、個別にすなわち他の技法なしで適用することができる。メディアサーバ３０２は、これらの懸念を軽減するためにＵＰｎＰネットワーク３１４を保護するためのこれらの技法のうちの任意の２つ、３つ、４つなどを含むこれらの技法の任意の組合せを適用することもできる。その代わりに、一実施形態で、メディアサーバ３０２が、これら技法のすべてを適用することができる。メディアサーバ３０２または他の管理インターフェースは、任意選択として、例えば適当に構成されたユーザインターフェースプレゼンテーションを介して、これらの技法を個別にイネーブルし、ディスエーブルする能力をメディアサーバユーザに与えることもできる。
【０１４０】
図７に、メディアサーバ３０２によって提供されるセキュリティ技法の多数を説明する媒体として働くＵＰｎＰ応用例を示す。この応用例は、全般的に、図４で提示した応用例にならってモデリングされている。この応用例は、家庭７０２などのローカルセッティングに適用される。家庭７０２に、複数の部屋が含まれる。各部屋に、１つまたは複数のＵＰｎＰデバイスを含めることができる。図７の例示的な事例で、家庭７０２に、ルータ７１８を介してデバイス７０６〜７１６に結合されたメディアサーバ７０４が含まれる。ルータ７１８は、もう１つのルータ７２０にも結合される。ルータ７１８に、メディアサーバ７０４をデバイス７０６〜７１６に結合するハードワイヤード接続性および／または無線接続性を含めることができる。例えば、デバイスの例示的な１つ（例えば、デバイス７１４）が、無線（例えば、ＲＦ、赤外線など）結合を介してルータ７１８と通信する。
【０１４１】
図７に、エンティティ７２２、７２４、および７２６を含む、家庭７０２でＵＰｎＰネットワーク３１４と相互作用することを許可されないエンティティの例示的なサンプルも示されている。エンティティ７２２は、デバイス７２８を使用して、無線通信を介してホームＵＰｎＰネットワーク３１４との相互作用を試みている。このデバイス７２８は、無線接続性を有するメディアレンダリングデバイスまたは類似する装置を表すことができる。エンティティ７２４は、デバイス７３０を使用して、広域ネットワークなどのネットワークを介してＵＰｎＰネットワーク３１４との相互作用を試みている。例えば、このデバイス７３０は、インターネット７３２、モデム７３３、およびルータ７１８を介してメディアサーバ７０４に結合された（または、もう１つの実施形態で、インターネット７３２およびモデム７３３を介してすなわち、ルータ７１８を介してルーティングされずにメディアサーバ７０４に直接に結合された）すべての種類のコンピュータデバイス（例えば、パーソナルコンピュータ、サーバなど）を表すことができる。モデム７３３は、ダイヤルアップモデム、ブロードバンドモデム、または他の種類のモデムとすることができる。最後に、エンティティ７２６は、デバイス７３４を使用して、ルータ７２０を介するＵＰｎＰネットワーク３１４との相互作用を試みている。これらの許可されないエンティティおよびデバイスは、ＵＰｎＰネットワーク３１４のリソースへのアクセスを得ることを試みる可能性がある広い範囲の様々な種類の侵入者の単なる例示である。
【０１４２】
上で説明されたエンティティを邪魔するために、ＵＰｎＰネットワーク３１４に、次の機構のうちの１つまたは複数を含めることができる。
【０１４３】
ａ．ＩＰアドレス制限
リソース情報共有機能性３２２（図３の）を、公衆ブロードバンドトラフィックを除外する効果を有する、所定の非パブリックアドレス範囲に制限することができる。１つの例示的な実施形態では、所定のアドレス範囲が、１９２．１６８範囲（例えば、１つの例示的な実施形態によれば、１９２．１６８．０．０から１９２．１６８．２５５．２５５まで）およびＡｕｔｏ  ＩＰ範囲（例えば、１つの例示的な実施形態によれば、１６９．２５４．０．０から１６９．２５４．２５５．２５５まで）である。他の例示的な非パブリックアドレス範囲が、１０．０．０．０から１０．２５５．２５５．２５５および１７２．１６．０．０から１７２．３１．２５５．２５５までである（１つの例示的な実施形態によれば）。この範囲のどれでも使用することができ、あるいは、これらの範囲の組合せを使用することができる（あるいは、他の範囲を使用することができる）。範囲は、連続する必要がない（例えば、これらの範囲のいずれかの中に「使用不能」ギャップを設けることができる）。一般に、上で指定された範囲は、様々な点で変更することができる（例えば、範囲の「端点」を変更することによる）。
【０１４４】
例えば、例示のために、１９２．１６８およびＡｕｔｏ−ＩＰ範囲を使用する。この範囲は、多数の一般的に入手可能なホームネットワークルータが、１９２．１６８範囲のアドレスを分け与える組み込みＤＨＣＰサーバを有するので選択された。さらに、ブロードバンドネットワーク上のほとんどのルータが、１９２．１６８範囲の宛先ＩＰアドレスを指定するメッセージを単純に捨てる。したがって、リソース情報共有機能性３２２は、１９２．１６８範囲の外のアドレスを有するすべての要求に応答せず、１９２．１６８範囲内のすべてのメッセージが、一般に、公衆ブロードバンドネットワークのルータを越える伝搬に適さない。これは、プライベートＵＰｎＰネットワーク３１４と公衆ブロードバンドネットワークまたはダイヤルアップ接続との間のセキュリティウォールを作成するという効果を有する。図７では、メディアサーバ７０４とインターネット７３２の間に阻止されたアクセスの記号７３６を示すことによって、この概念が示されている。この阻止されたアクセスは、家庭７０２の内部の誰かまたは家庭７０２の外部の誰かが、ブロードバンドネットワークを介してリソースのスーパーディストリビューションにメディアサーバ７０４を使用するのを防ぐ。この備えは、家庭７０２の内部の誰かまたは家庭７０２の外部の誰かが、許可されない形でＵＰｎＰネットワーク３１４を盗聴するのも防ぐ。
【０１４５】
この特徴を実施するために、リソース転送モジュール５２４、コンテンツディレクトリサービスモジュール５２６、およびデバイス監視モジュール５２０（図５の）のすべてを、所定のアドレス範囲内のインターフェースだけを監視し、かつ／または他のＩＰアドレスから発する要求を破棄するように構成することができる。リソース情報共有機能性３２２は、この所定のアドレス範囲を、メディアサーバユーザコンフィギュレーションからアクセス可能なパラメータにするのではなく、このアドレス範囲をハードコードすることによるなど、メディアサーバユーザ（またはこれに関する他の誰か）がこの所定のアドレス範囲を変更することを禁止する様々な機構を提供することができる。
【０１４６】
ｂ．ＭＡＣアドレス認証
前に述べたように、リソース情報共有機能性３２２は、デバイスのメディアアクセスプロトコル（ＭＡＣ）アドレスまたは他のデバイス固有情報を使用して、そのデバイスを認証する。この技法では、リソース情報共有機能性３２２が、まず、ＵＰｎＰネットワーク３１４に追加された新しいデバイスのＩＰアドレスを識別する（新しいデバイスは、まず、図５のデバイス監視モジュール５２０を使用して検出される）。次に、リソース情報共有機能性３２２が、例えばＭｉｃｒｏｓｏｆｔ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎ社のＩｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  Ｈｅｌｐｅｒ（ＡＲＰ（ａｄｄｒｅｓｓ  ｒｅｓｏｌｕｔｉｏｎ  ｐｒｏｔｏｃｏｌ）を使用する）によって提供されるＳｅｎｄＡＲＰ関数を使用して、ＩＰアドレスをＭＡＣアドレスに変換する。前に述べたように、リソース情報共有機能性３２２は、例えばセクションＢ（下）で説明するユーザインターフェースプレゼンテーションを使用して、新しいデバイスの存在についてメディアサーバユーザに通知することができる。メディアサーバユーザがそのデバイスを許可する場合に、リソース情報共有機能性３２２は、ＩＰアドレスおよびＭＡＣアドレスを使用して、そのデバイスが後にＵＰｎＰ要求（ブラウズ要求または検索要求など）を行うか、コンテンツ関連要求（ＨＴＴＰ  ＧＥＴ要求など）を行う時に、そのデバイスを認証する。許可されないデバイスからの要求は、無視される。始める要求のＭＡＣアドレスを使用してデバイスの認証することは、有利である。というのは、ＩＰアドレスだけでは信頼できないからである（ＩＰアドレスは、ＤＨＣＰサーバの可用性に応じて変化する可能性があるからである）。
【０１４７】
このＭＡＣ認証技法は、デバイス７２８などの無線デバイスがＵＰｎＰネットワーク３１４のリソース情報への許可されないアクセスを得るのを防ぐのに特に魅力がある。例えば、エンティティ７２２が、家庭７０２のそばをドライブしており、それと同時に無線アクセスデバイス７２８を使用している場合に、リソース情報共有機能性３２２は、メディアサーバユーザ（メディアサーバ７０４の）がこのデバイスを許可したいかどうかをメディアサーバユーザに尋ねるポップアップメッセージを表示している場合がある。メディアサーバユーザが、アクセスを許可することを選ばない限り、リソース情報共有機能性３２２は、このデバイス７２８に対してアクセスを拒否する。
【０１４８】
ＭＡＣアドレス認証は、ＩＰアドレス制限（上のサブセクション（ａ）で説明した）などの他のセキュリティ手段と共に使用される時に、最も価値がある。例えば、ＩＰアドレス制限なしのＭＡＣ認証は、メディアサーバ７０４がブロードバンドネットワークに直接に接続されるネットワーク構成で（または、メディアサーバ７０４がダイヤルアップ接続を介して外部機能性に結合される時に）適度な保護を提供しない場合がある。ＩＰアドレス制限がなければ、リソース情報共有機能性３２２が、家庭の外の「隣接」デバイスを検出し、これらのデバイスを認証するかどうかをメディアサーバユーザに問い合わせることができ；これは、セキュリティリスクを提示しない場合があるが、ポップアップメッセージの頻繁な表示に起因する迷惑を提示する可能性がある。さらに、ブロードバンド（またはダイヤルアップ）モデムが、インターネットサービスプロバイダのネットワークのプロキシＡＲＰ（ａｄｄｒｅｓｓ  ｒｅｓｏｌｕｔｉｏｎ  ｐｒｏｔｏｃｏｌ）ルータに接続されていると仮定する。この場合に、リソース情報共有機能性３２２は、プロキシＡＲＰルータを介してルーティングされるサブネット上のデバイスのいずれかが認証される時に、効果的にそれらのデバイスのすべてを認証する。
【０１４９】
ｃ．サブネット制限
１つの例示的な実施形態で、リソース情報共有機能性３２２は、そのネットワーククライアントが、それが動作するのと同一のサブネットで動作することを要求する。この制限によって、リソース情報共有機能性３２２は、そのローカルサブネットの外のクライアントから受信されるＵＰｎＰアクション要求およびリソースコンテンツ取り出し要求を無視する。これは、ＵＰｎＰネットワーク３１４のスコープの外部で動作するデバイスがそのリソースにアクセスできる可能性をさらに減らすという効果を有する。
【０１５０】
ＡＲＰプロトコルが、サブネット境界をまたいでＡＲＰパケットを伝送しないので、上で説明したＭＡＣアドレス認証プロシージャが、サブネット境界にまたがって機能しないことに留意されたい。したがって、ＭＡＣアドレス認証が使用される場合に、この技法は、本質的に、動作を単一のサブネットに制限する。しかし、サブネット制限を実施するのにリソース情報共有機能性３２２を使用することが、ＳｅｎｄＡＲＰ（）によって提供される暗黙のサブネット制限と異なる。例えば、後者の技法を、この技法で使用されるルーティングテーブルを変更することによって危険にさらすことができる。
【０１５１】
また、デフォルトで、ＳＤＤＰサービス（例えば、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムプラットフォームでＭｉｃｒｏｓｏｆｔ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎ社によって提供される）が、ブロードキャストＳＳＤＰアナウンスメントをサブネットに制限することに留意されたい。すなわち、ＵＰｎＰデバイスは、ＳＳＤＰを使用して、その存在をネットワークを介してアナウンスし、したがって、デフォルト設定について、リソース情報共有機能性３２２が、他のサブネット上のＵＰｎＰデバイスによって検出されない。しかし、このＳＳＤＰ特徴は、リソース情報共有機能性３２２によって実行されるサブネット制限と異なる。というのは、後者の技法が、レジストリで構成可能なセッティングに依存するからである。また、ＳＳＤＰアナウンスメントは、１９２．１６８アドレス範囲およびＡｕｔｏ  ＩＰアドレス範囲に制限されない。
【０１５２】
ｄ．ＴＴＬ制限
リソース情報共有機能性３２２は、許可されないエンティティがＵＰｎＰネットワーク３１４のリソース情報と相互作用することを許可される可能性をさらに減らすために、ＴＴＬ（ｔｉｍｅ  ｔｏ  ｌｉｖｅ）パラメータを制限することができる。１つの例示的な実施形態で、ＴＴＬパラメータは、ソースノードから宛先ノードに送信される過程でメッセージがトラバースしたノード（例えば、ルータなどのＩＰレベル３ノード）の個数に一般に対応するインターネットプロトコル（ＩＰ）パラメータである。各ＩＰパケットに、ＴＴＬパラメータが含まれる。ＵＰｎＰネットワーク３１４のコンテキストでは、ＴＴＬパラメータによって、共有リソースに関連するリソースメタデータを含むコンテンツディレクトリサービスモジュール５２６によって送信されたメッセージのルーティングを制限することができる。その代わりにまたはそれに追加して、ＴＴＬパラメータは、リソースコンテンツ要求（ＨＴＴＰ  ＧＥＴメッセージなど）に対する応答のルーティングも制限することができる。例えば、数３をセットされたＴＴＬパラメータは、パブリックブロードバンドネットワークを介するリソース情報の散布を禁止するのに十分である（というのは、公衆ブロードバンドネットワークを介する宛先への伝送が、通常は、メッセージを３つより多数のルータにさらすからである）。リソース情報共有機能性３２２が、ＵＰｎＰネットワーク３１４を、１つのルータだけを用いることができる単一のネットワークに制限する例示的な事例では、ＴＴＬパラメータに、１のように小さい値をセットすることができる。１つの例示的な実施形態で、リソース情報共有機能性３２２は、ＴＴＬパラメータをハードコードすることができ、その結果、ＴＴＬパラメータをメディアサーバが（または他のエンティティが）簡単には変更できなくなる。
【０１５３】
例えば、ＴＴＬパラメータに１がセットされている、図７の例示的な事例に留意されたい。この設定では、メディアサーバ７０４が、エンティティ７２６にリソースメタデータおよびリソースコンテンツをサービスすることを禁止することができる。というのは、このエンティティ７２６が、複数のルータを介してメディアサーバ７０４に結合されているからである。したがって、このＴＴＬ設定は、阻止されたアクセスの記号７３８によって示されるように、ルータ７２０へのアクセスを効果的に阻止する。ＴＴＬパラメータに小さい値をセットすることによって、インターネット７３２を介するリソース情報の散布も禁止される。というのは、そのようなブロードバンド伝送が、最終的な宛先への途中で多数の中間ルータを必要とするからである。
【０１５４】
ｅ．デバイスおよびセッションの制限
リソース情報共有機能性３２２は、一時に許可できるＵＰｎＰデバイスの数を、所定の数（一例で１０デバイスなど）までに制限することができる。１つの実施形態で、ＵＰｎＰデバイスの指定された最大個数に、メディアレンダリングデバイス、メディアサーバ、コントロールポイントなどを含む、ＵＰｎＰネットワークに結合できるすべての種類のデバイスを含めることができる。もう１つの実施形態で、デバイスの指定された最大個数が、メディアレンダリングデバイスだけなど、ＵＰｎＰデバイスの１つまたは複数のカテゴリだけに関係することができる。リソース情報共有機能性３２２は、並行リソースコンテンツサービングセッション（並列ＨＴＴＰセッションなど）の個数を、所定の数（一例で１０セッションなど）までに制限することができる。リソース情報共有機能性３２２は、これらのパラメータの両方（すなわち、デバイスの最大個数およびセッションの最大個数）をハードコードして、メディアサーバ（または他のエンティティ）がこれらのパラメータを簡単に変更し、これによってこの制限を回避することを防ぐことができる。
【０１５５】
図７のコンテキストで、ホームＵＰｎＰネットワーク３１４が、デバイスの数を５に制限することができ、これは、デバイス７１６がリソース情報（リソースメタデータとリソースコンテキストの両方）へのアクセスを得るのを防ぐという効果を有する場合がある。この拒否されたアクセスが、図７では、阻止されたアクセスの記号７４０によって示されている。この備えは、許可されたメディアサーバユーザであっても、ＵＰｎＰネットワーク３１４を使用して多数の受信側にリソースを配布することができないことを保証するのに役立つ（例えばスーパーディストリビューションシナリオ）。この備えは、一般に、公衆ブロードバンド伝送が、一般に、共有リソースへのアクセスを試みる多数の参加者を伴う限り、インターネット７３２を介するリソースメタデータおよびリソースコンテンツの配布の試みも邪魔する。
【０１５６】
ｆ．ＵＰｎＰアクションへの認証に関する候補デバイスの制限
リソース情報共有機能性３２２は、ＵＰｎＰアクションを呼び出したデバイスまたはＳＳＤＰを使用してＵＰｎＰネットワーク３１４でメディアレンダリングデバイスとしてそれ自体をアナウンスしたデバイスだけに相互作用を制限することもできる（前者の制限は、ＵＰｎＰネットワーク３１４でそれ自体をアナウンスする必要がないが、他の形でＵＰｎＰネットワーク３１４と相互作用することを許可されるＵＰｎＰコントロールポイントに対処するものである）。これらの制限は、リソース情報共有機能性３２２との相互作用を試みる許可されないエンティティを排除するのに役立つ。すなわち、潜在的な「ハッカー」は、リソース情報共有機能性３２２によって共有されるリソース情報と相互作用するために、適当なＵＰｎＰソフトウェアを獲得し、実行する必要があり、この要件によって、ＵＰｎＰネットワーク３１４への許可されないアクセスの水準が引き上げられる。例えば、これらの制限によって、ハッカーが、ウェブブラウザを開き、前にパブリッシュされた、共有リソースに対応するリソースロケータをリソース情報共有機能性３２２に送信することだけによって、リソース情報共有機能性３２２によって共有されるリソースコンテンツへのアクセスを得ることはできない。そうではなく、デバイスは、まず、例えば最初のＵＰｎＰアクション要求（例えば、ブラウズ要求または検索要求に対応する）を送信することによって、それが正しい許可されたＵＰｎＰデバイスであることを証明しなければならず、その後に限って、そのデバイスが、リソースコンテンツ取り出し要求を使用してリソースコンテンツにアクセスすることを許可される（１つの例示的な実施形態で、前に承認されずにリソースコンテンツの取出を試みるデバイスが、新たに発見されたデバイスである場合であっても、承認のためにメディアサーバユーザに提示すらされない、すなわち、これらのデバイスを無視できることに留意されたい）。
【０１５７】
もう１つの保護として、リソース情報共有機能性３２２は、それ自体をメディアレンダリングデバイスとしてアナウンスするすべてのデバイスが、一意のデバイス番号（ＵＤＮ）を有することを要求することができる。一実施形態で、リソース情報共有機能性３２２は、レンダリングデバイスのＵＤＮが、ＵＰｎＰネットワーク３１４で現在または以前に検出された他のメディアレンダリングデバイスと異なることを検証する。リソース情報共有機能性３２２は、ＵＤＮが既に検出されているＵＮＤと一致する場合に、そのメディアレンダリングデバイスのアクセスを静かに拒否することができる。さらに、デバイスが、メディアレンダリングデバイスとして検出されたならば、リソース情報共有機能性３２２は、そのＵＮＤが変更されないままになることを要求することができる。リソース情報共有機能性３２２は、変化を検出する場合に、そのデバイスに対してアクセスを静かに拒否する。さらに、メディアレンダリングデバイスが通し番号を有する場合に、リソース情報共有機能性３２２は、この番号も変更されないままになることを要求することができる。リソース情報共有機能性３２２は、この番号の変化を検出した場合に、そのデバイスに対してアクセスを静かに拒否する。
【０１５８】
ｇ．リソースロケータリタイヤメント
上で注記したように、リソース情報共有機能性３２２は、リソースロケータ（ＨＴＴＰ  ＵＲＬなどであるが、これに制限はされない）を使用して、そのリソースの位置を定義する。各リソースロケータのコンポーネントは、関連するリソースコンテンツを識別するリソースＩＤ（例えば、ＲｅｓｏｕｒｃｅＩＤ）である。リソース情報共有機能性３２２は、そのリソースコンテンツアイテムを識別するリソースロケータを周期的に変更することによって、もう１つのセキュリティ保護を提供することができる（下の議論では、用語「リソースコンテンツアイテム」が、リソースストア３２０にストアされた選択されたリソースに関連するリソースコンテンツを指し、用語「アイテム」は、単に、文法的な便宜および明瞭さのために追加されている）。これは、リソースコンテンツアイテムを識別するリソースＩＤを周期的に変更することによって実行することができる。この保護は、リソースロケータの使用に時間制限を課すという効果を有する。例えば、コンシューマは、ＵＰｎＰブラウズアクションまたはＵＰｎＰ検索アクションを実行して、１つまたは複数のリソースロケータを取り出すことができる。しかし、リソース情報共有機能性３２２が、これらのリソースロケータを周期的に変更するので、コンシューマは、比較的タイムリーな形でリソースコンテンツ検索要求を使用して（検索されたリソースロケータを使用して）リソースコンテンツアイテムを取り出すことを強制される。コンシューマが、長く待ちすぎた場合に、これらのリソースロケータが、古くなり、動作不能になる。したがって、リソースロケータが、許可されないエンティティに漏らされた場合に、これらのリソースロケータは、非常に長い間有効ではなく、これによって、リソースロケータの望ましくない開示によって引き起こされる損害が制限される。
【０１５９】
ｈ．様々なリソース転送モジュール５２４セキュリティ手段
上で識別された複数の機構が、様々なセキュリティ脅威からリソース転送モジュール５２４（例えば、ＨＴＴＰサーバとして実施することができる）を保護するのに役立つ。例えば、ＩＰアドレス制限手段によって、リソース情報共有機能性３２２が、プライベート範囲（例えば、１９２．１６８範囲）またはＡｕｔｏ  ＩＰ範囲内のネットワークインターフェースだけに対してリソース転送モジュール５２４を始動する。さらに、デバイスおよびセッションの制限によって、リソース情報共有機能性３２２が、リソースコンテンツ取り出しセッションの数を所定の数（例えば、１０セッション）までに制限し、承認されるデバイスの数を所定の数（例えば、１０デバイス）までに制限する。ＴＴＬ制限によって、リソース情報共有機能性３２２が、ＴＴＬパラメータを所定の数（３など）までに制限し、これによって、リソースコンテンツ応答を提供する時に用いられるルータの数を制限する。ＵＰｎＰアクション制限によって、リソース情報共有機能性３２２が、前に承認されたデバイスから発する場合に限ってリソースコンテンツ要求をサービスし、他のすべての要求を無視することができる（具体的に言うと、リソース情報共有機能性３２２は、リソースコンテンツへのアクセスを試みる新しいデバイスを承認のためにメディアサーバユーザに提示する必要がない）。さらに、リソース情報共有機能性３２２は、リソースコンテンツを共有するメディアサーバユーザがファイルシステム上のリソース（例えば、ファイル）へのアクセスの許可を有する場合に限って、リソースコンテンツを共有し；これは、メディアサーバ３０２のリソースへのアクセスを拒否されたメディアサーバユーザが、ＵＰｎＰネットワーク３１４上のデバイスでそのコンテンツを再生できなくするためである。リソース情報共有機能性３２２は、さらに、共有があるデバイスに制限されるかどうか、またはメディアサーバシステムにログオンしている特定の個人を前提条件とするかどうかを判定する。
【０１６０】
リソース転送モジュール５２４に、様々な他のセキュリティ手段も含めることができる。例えば、クライアントが通信ソケットをオープンし、リソースコンテンツ取り出し要求を部分的にのみ書き込むか、タイムリーな形でリソースコンテンツ応答を読み取らない場合に「タイムアウト」するようにリソース転送モジュール５２４を構成することができる。１つの例示的な実施形態で、リソース情報共有機能性３２２は、これらのタイムアウトに５分をセットすることができる。このタイムアウトは、メディアサーバユーザ（または他の誰か）が簡単にこの値を変更できなくするために、ハードコードすることができる。
【０１６１】
もう１つの特徴によれば、リソース転送モジュール５２４は、リソースコンテンツ取り出し要求を、約４０００文字など、所定のサイズまでに制限することができる。
【０１６２】
もう１つの特徴によれば、リソース転送モジュール５２４は、リソースロケータを検証することができる。検証に、リソースロケータが、ｈｔｔｐ：／／ｍａｃｈｉｎｅ  ｉｐ：ｐｏｒｔ／ＲｅｓｏｕｒｃｅＩＤ（すなわち、この場合に、ＨＴＴＰ  ＵＲＬが使用されること）など、所定のフォーマットに従うことを保証することを含めることができる。リソース転送モジュール５２４は、要求ヘッダを注意深く解析し、検証することもできる。
【０１６３】
Ａ．６．ＵＲＬパラメータ化の提供
図３に関して、メディアサーバ３０２からのリソース情報の取出に、情報の４つの主要な交換を含めることができることを想起されたい。第１の交換（パス３２４によって表される）で、コンシューマが、コントロールポイント３１６を使用して、ＵＰｎＰクエリをメディアサーバ３０２に送信することができる。このＵＰｎＰクエリは、ブラウズ要求または検索要求として構成することができる。ブラウズ要求では、コンシューマの意図が、メディアサーバ３０２によって提供されるリソースに関連するリソースメタデータのコレクションをスキャンすることである。検索要求では、コンシューマの意図が、よりねらいを定めたものであり、例えば、様々な検索単語によって識別されるメディアサーバ３０２によって供給される特定のリソースメタデータを見つけることなどである。
【０１６４】
どの場合でも、第２の交換（パス３２６によって表される）で、メディアサーバ３０２は、コンシューマの要求に合致する１つまたは複数のリソースに対応するリソースメタデータ（例えば、リソースストア３２０内のファイル）を提示することによって応答する。このリソースメタデータに、タイトル、ジャンル、アーティスト、作成日付など、一致するリソースに関する様々な高水準情報を含めることができる。このリソースメタデータに、リソースコンテンツアイテムをそこから取り出すことができるめいめいのネットワーク位置を識別するリソースロケータ（ＵＲＬなど）も含めることができる。議論を容易にするために、このセクションでは、ＨＴＴＰサーバに関するＵＲＬの特定の使用を仮定するが、本明細書に記載の原理は、他の種類のリソースロケータおよび関連するリソースコンテンツサーバに適用することができる（次の議論では、用語「リソースコンテンツアイテム」が、リソースストア３２０にストアされた選択されたリソースに関連するリソースコンテンツを表し、用語「アイテム」は、単に、文法的な便宜および明瞭さのために追加されている）。
【０１６５】
リソースメタデータを見た後に、コンシューマが、レンダリングデバイス３０６などのレンダリングデバイスで再生するために、対応するリソースコンテンツアイテムを選択したと仮定する。この場合に、第３の交換（パス３３０によって表される）で、コンシューマは、レンダリングデバイス３０６が、選択されたリソースコンテンツアイテムを取り出すようにメディアサーバ３０２に指示する要求をメディアサーバ３０２に送信することを可能にする。例えば、コンシューマは、選択されたリソースコンテンツアイテムに関連するＵＲＬをレンダリングデバイス３０６に転送することができる。レンダリングデバイス３０６は、選択されたリソースコンテンツアイテムを指定するＨＴＴＰ  ＧＥＴ要求をメディアサーバ３０２に送信することによって応答する。このＨＴＴＰ  ＧＥＴ要求に、選択されたリソースコンテンツアイテムに対応するＵＲＬ（コントロールポイントによって渡されたもの）が含まれる。
【０１６６】
最後に、メディアサーバ３０２は、ＵＲＬによって指定される位置で選択されたリソースコンテンツアイテムを取り出すことによって、ＨＴＴＰ  ＧＥＴ要求に応答する。第４の交換（パス３３２によって示される）で、メディアサーバ３０２が、選択されたリソースコンテンツアイテムをレンダリングデバイス３０６に供給する。
【０１６７】
このセクションの残りでは、上で説明した情報交換の効率を改善する技法を説明する。
【０１６８】
まず、リソースストア３２０が、通常は、定義されたオリジナルメディアフォーマットでファイルをストアすることに留意されたい。用語「メディアフォーマット」は、リソースがストアされ、かつ／またはレンダリングされる形に影響する、リソースに関するすべての特性を含む。例えば、メディアフォーマットは、フォーマットタイプ（例えば、様々なタイプの圧縮フォーマットおよび非圧縮フォーマット）、フォーマット解像度などを指定することができる。例えば、リソースストア３２０は、ＲＧＢのフォーマットタイプおよび６４０×４８０のフォーマット解像度を有するイメージファイルをストアすることができる。したがって、レンダリングデバイスは、ＲＧＢフォーマットタイプで表されたサイズ６４０×４８０のイメージを処理するように構成されている場合に、このイメージファイルを表示することができる。さらに、メディアサーバ３０２に、コンシューマの要求の際に、リソースをオリジナルメディアフォーマットから別のメディアフォーマットに変換する機能性（図示せず）を含めることができる。あるいは、リソースストア３２０は、異なるめいめいのオリジナルメディアフォーマットで表された、リソースの複数のバージョンをストアすることができる。この２つの場合のどちらであっても、単一のリソースに関連する異なるメディアフォーマットを、複数の個々のリソースを含むものとして概念化することができる。したがって、個々のリソースごとに、メディアサーバ３０２を、異なるメディアフォーマットに対応する選択的な配布のために複数のリソースを提供するものとして概念化することができる。
【０１６９】
本明細書に記載の技法は、コンシューマが、指定されたメディアフォーマットに従うリソースコンテンツを取り出すことを可能にする機構を提供する。メディアサーバ３０２は、様々な形でこの目的を達成することができる。視座について、この目的を達成する１つの形が、メディアサーバ３０２に、リソースコンテンツアイテムの異なるメディアフォーマットにそれぞれ関連する異なるＵＲＬをパブリッシュさせることである。例えば、第１の例示的なＵＲＬによって、ＲＧＢのフォーマットタイプおよび６４０×４８０のフォーマット解像度を有するリソースコンテンツアイテムを指定することができる。第２の例示的なＵＲＬによって、ＹＵＶのフォーマットタイプおよび１２８０×１０２４のフォーマット解像度を有する同一のリソースコンテンツアイテムを指定することができる。他の例示的なメディアフォーマットは、様々なアイコンサイズおよびサムネイルサイズのバージョンと、様々な標準ディスプレイ解像度フォーマットに対応する。しかし、この手法は、様々な短所を有する。例えば、この手法は、メディアサーバ３０２が、単一の「親」リソースコンテンツアイテムに関連する異なるメディアフォーマット置換に関連する潜在的に多数のＵＲＬを管理し、パブリッシュすることを必要とする。この多数のＵＲＬを供給することは、ＵＰｎＰネットワーク３１４を複雑にし、これによって、ＵＰｎＰネットワーク３１４でのネットワークトラフィックが潜在的に増加し、他の潜在的な問題が生じる。
【０１７０】
具体的に言うと、一実施形態で、メディアサーバ３０２は、一致するリソースごとにいわゆる「ｒｅｓ」要素を提供することによって、ブラウズＵＰｎＰ要求または検索ＵＰｎＰ要求に応答することができる。「ｒｅｓ」要素に、一致するリソースに関連するリソースコンテンツアイテムを見つけられる場所を識別するＵＲＬが含まれる。上で説明したソリューションは、一致するリソースアイテムに様々な形で対応する複数のメディアフォーマットを指定することができる。例えば、メディアサーバ３０２は、それぞれがめいめいのメディアフォーマット（それぞれがそれ自体のＵＲＬを有する）に関連する複数のｒｅｓ要素を提供することができる。その代わりに、メディアサーバ３０２が、一致するリソースごとに複数の一致するアイテムを作成することができ、各一致するアイテムが、めいめいのメディアフォーマット（それ自体のＵＲＬを有する）に関連する。これらのソリューションの両方が、ＵＰｎＰネットワーク３１４に様々な複雑さを導入し、潜在的に、その性能に悪影響を及ぼす。
【０１７１】
また、上のソリューションでは、メディアサーバ３０２が、サポートされるメディアフォーマットの関連するセットに対応するＵＲＬの限られたセットだけを提供する。しかし、提供されるメディアフォーマットのこの限られたセットは、リソースコンシューマの必要に合致しない場合がある。
【０１７２】
下で特徴を示す技法では、メディアサーバ３０２が、コンシューマのブラウズ要求または検索要求に応答して、使用可能なリソースコンテンツアイテムの単一のＵＲＬをパブリッシュすることができ、その単一のＵＲＬに、様々なメディアフォーマットの範囲を記述するために変更することができるめいめいの特有の属性を指定する様々なパラメータを含めることができる。すなわち、メディアサーバ３０２は、関連するリソースコンテンツアイテムを最もよく提示すると判定されたメディアフォーマットを反映する、その様々なパラメータについてオリジナルのデフォルト値を書き込まれたＵＲＬをパブリッシュすることができる。「最もよい」デフォルトメディアフォーマットの判定は、１つまたは複数の判断基準に基づくものとすることができる。コントロールポイント（例えば、コントロールポイント３１６）は、メディアレンダリングデバイスによって使用されるネイティブメディアフォーマットに対処するために、または他の考慮事項に基づいて、これらのデフォルトパラメータを変更することができる。例えば、コントロールポイント３１６は、メディアレンダリングデバイス３０６の接続マネージャサービスモジュールによって提供されるＧｅｔＰｒｏｔｏｃｏｌＩｎｆｏ  ＵＰｎＰアクションを呼び出すことによって、このレンダリングデバイスのレンダリング能力を判定することができる。次に、コントロールポイント３１６は、レンダリングデバイス３０６のプレゼンテーション能力と互換性があり、リソース自体がサポートできるレンダリングフォーマット（メディアサーバ３０２によってコントロールポイント３１６に返されるリソースメタデータから探り出される）と互換性があるメディアフォーマット（１つまたは複数の）を選択することができる。リソースコンテンツを複数のメディアフォーマットで提示できる場合には、コントロールポイント３１６は、これについてコンシューマに警告し、コンシューマがメディアフォーマットを選択できるようにすることができる。このタスクを容易にするために、コントロールポイント３１６は、サポートされるメディアフォーマットの情報を、コンシューマが簡単に理解できる情報に変換することができる。あるいは、コントロールポイント３１６は、自動化された分析を実行して、複数の可能なフォーマットの中で選択することができる（例えば、コンシューマが過去に何を選択したかの考慮に基づくなど）。
【０１７３】
どの場合でも、パラメータを変更することによって、変更されたＵＲＬが作成され、これを、リソースコンテンツを提示するレンダリングデバイス（例えば、レンダリングデバイス３０６）に転送することができる。次に、レンダリングデバイス３０６が、この変更されたＵＲＬをメディアサーバ３０２にサブミットすることによって、変更されたＵＲＬに対応するリソースコンテンツアイテムを取り出すことができる。代替案では、レンダリングデバイス３０６が、パラメータを変更せずにオリジナルのＵＲＬを単純にメディアサーバ３０２に送り返すことができる（例えば、オリジナルＵＲＬをレンダリングデバイス３０６に転送し、このレンダリングデバイス３０６がそれをメディアサーバ３０２に転送することによって）。
【０１７４】
メディアサーバ３０２は、レンダリングデバイス３０６によって送信されたＵＲＬからパラメータを読み取り、次にＵＲＬ内のパラメータによって指定されるメディアフォーマットのリソースコンテンツアイテムをメディアレンダリングデバイス３０６に供給することによって応答する。この動作は、メディアサーバ３０２が、選択されたリソースコンテンツアイテムをオリジナルメディアフォーマットからＵＲＬのパラメータによって指定されたメディアフォーマットに変換することを必要とする場合がある。あるいは、この動作は、単に、メディアサーバ３０２が、ストアされたリソースコンテンツアイテムを変更せずに供給することを必要とする場合がある（変更が不要であることがパラメータによって示される場合に）。その代わりに、メディアサーバ３０２が、複数の異なるメディアフォーマットでリソースコンテンツアイテムをストアしている場合があり、この場合には、メディアサーバ３０２は、変更せずに使用可能な場合に適当なストアされたメディアフォーマットを選択することができる。
【０１７５】
一実施形態で、メディアレンダリングデバイス３０６は、受信したリソースコンテンツアイテムを、メディアサーバ３０２から受信したメディアフォーマットで提示する。もう１つの実施形態で、メディアレンダリングデバイス３０６に、受信したリソースコンテンツアイテムを、提示の前に（または、潜在的に、それをストアする前に）もう１つのメディアフォーマットに変換する変換機能性（図示せず）をも含めることができる。
【０１７６】
上で説明した技法によって、メディアサーバ３０２は、可能なメディアフォーマットの様々な置換に関連する多数のＵＲＬをパブリッシュする必要がない。これは、ＵＰｎＰネットワーク３１４のトラフィックを減らし、メディアサーバ３０２のＵＲＬ管理要件を単純化するのに役立つ。この戦略は、コントロールポイント３１６に、限られた数のストックオプションの間で選択する必要なしに、現在アドレッシングしているレンダリングシナリオの必要に最もよく適するメディアフォーマットを動的に調整する柔軟性も与える。この戦略は、コントロールポイントが、それが相互作用する可能性がある異なるメディアサーバに関してメディアフォーマットを調整できるようにする標準的で均一な技法も提供する。
【０１７７】
一実施形態で、メディアサーバ３０２は、１つまたは複数の判断基準に基づいて、ＵＲＬで使用されるオリジナルデフォルト値を選択することができる。例えば、メディアサーバ３０２は、ＵＲＬに関連するリソースを調べることによって、このＵＲＬで使用されるオリジナルデフォルト値を選択することができる。リソースに、好ましいオリジナルデフォルト値を識別するそれに含まれる情報が含まれる場合がある。その代わりに、メディアサーバ３０２が、リソースから抽出された情報に対するそれ自体の分析を実行して、好ましいオリジナルデフォルト値に対する判断を行うことができる。あるいは、メディアサーバ３０２が、どのメディアフォーマットが最も一般的であるかの考慮など、リソース自体からは導出されない他の要因を使用することができる。これらの好ましい初期値を選択する、さらに他の技法を提供することができる。
【０１７８】
上で要約した技法の例示的な詳細を、次に示す。上で説明したリソースコンテンツ取り出し戦略を実施するのに使用できる次の例示的なパラメータ化されたＵＲＬを検討されたい。
【０１７９】
【表２】
2007515015.tif 000003
【０１８０】
このＵＲＬには、プロトコル方式を識別する第１フィールドが含まれる。プロトコル方式は、リソースコンテンツアイテムにアクセスするのに使用される技法を定義する。この場合に、第１フィールドは、「ｈｔｔｐ」を指定し、これは、このリソースコンテンツアイテムが、ハイパーテキスト転送プロトコル技法を使用してアクセスされなければならないことを示す。第２フィールドは、権限を識別する。権限は、リソースコンテンツアイテムを提供するエンティティ、通常はリソースコンテンツアイテムを提供するサーバを定義する。この場合に、第２フィールドは、権限として「ＳｅｒｖｅｒＮａｍｅ」を指定している。第３フィールドは、リソースコンテンツアイテムにアクセスするのに使用されるパスを指定する。パス（この場合には「Ｔｕｌｉｐｓ．ｊｐｇ」）は、権限（例えば、ＳｅｒｖｅｒＮａｍｅサーバ）が、そのシステム内でリソースコンテンツアイテムの位置を識別できるようにする。第４フィールドは、クエリを識別する。クエリには、リソースコンテンツアイテムのメディアフォーマットを取り出すのに使用される情報が含まれる（メディアサーバ３０２は、上で説明したパラメータ化されたＵＲＬを、ＸＭＬ「ｒｅｓ」要素のパッケージと共にコントロールポイント３１６に供給することができる。ｒｅｓ要素に、ＵＲＬの他に、一致するリソースに関連する他のメタデータも含めることができる）。
【０１８１】
具体的に言うと、例示的な実施形態で、上にリストしたＵＲＬの第４フィールドに、リソースのレンダリングに使用されるメディアフォーマットを集合的に記述する複数のパラメータが含まれる。上の例では、第１パラメータが、ＹＵＶとしてプレゼンテーションフォーマットのフォーマットタイプを指定し、第２パラメータが、６４０として解像度幅を指定し、第３パラメータが、４８０として解像度高さを指定している。これらのパラメータは、単に例示である。ＵＲＬは、追加のパラメータまたはより少数のパラメータを指定することができる。例えば、ＵＲＬは、イメージのレンダリングに使用される塗潰しカラー、例えばＲ（赤）＝ｘ、Ｂ（青）＝ｙ、およびＧ（緑）＝ｚを指定することができる（すなわち、イメージがレンダリングされる時に、そのイメージがレンダリングデバイスのディスプレイサーフェス全体を覆わない場合がある；塗潰しカラーは、イメージ内容を含まないディスプレイ領域に表示される背景色の赤成分、青成分、および緑成分を指定する）。
【０１８２】
さらに、パラメータ化されたＵＲＬは、上で指定されたもの以外の構文フォーマットを使用して表すことができる。上のフォーマットでは、各パラメータが、「名前＝値」の構文を有する名前／値対として指定されている。しかし、別の構文で、名前情報を省略することができ、名前情報を明示的に識別するのではなく、この情報を、ＵＲＬ内の関連する値の位置から推論することができる。名前情報の明示的識別を省略した例示的なＵＲＬは、次の通りである。
【０１８３】
【表３】
2007515015.tif 000004
【０１８４】
いくつかのパラメータに名前／値対構文を使用し、他のパラメータに位置構文（名前を明示的に識別しない）を使用する、ハイブリッドフォーマットを設けることも可能である。
【０１８５】
どのフォーマットが使用される場合でも、メディアサーバ３０２は、パラメータごとに選択できる値の範囲に関する情報をパブリッシュすることもできる。例えば、１つの例示的な実施形態で、名前パラメータが、ＹＵＶまたはＲＧＢの値を受け入れることができ、幅パラメータが、０から２０４８までの値を受け入れることができ、高さパラメータが、０から２０４８までの値を受け入れることができる。メディアサーバ３０２は、コンシューマのブラウズ要求またはコンシューマの検索要求に応答する時に、リソースメタデータ自体と共にこの範囲情報をパブリッシュすることができる。代替案では、メディアサーバ３０２が、例えば毎日１回、週１回など、周期的な基礎で範囲情報を散布することができる。代替案では、範囲情報を、既知の許容可能な範囲に基づいてコントロールポイントおよび／またはレンダリングデバイスに事前にストアすることができ、したがって、メディアサーバ３０２がこの情報を通信する必要がない。
【０１８６】
上の要約で述べたように、コントロールポイント３１６は、パラメータ化されたＵＲＬを受信した時に、値の指定された範囲内で許容される任意の値にパラメータを変更することができる（コンシューマのアシスタンスありまたはなしで）。例えば、最初に識別された例示的なＵＲＬを検討されたい。コンシューマのレンダリングデバイス３０６が、６４０×４８０の解像度を有するＹＵＶイメージを表示できる場合に、コントロールポイント３１６は、レンダリングデバイス３０６がメディアサーバ３０２にサブミットする前にＵＲＬを変更する必要がない。しかし、メディアレンダリングデバイスが、１２８０×１０２４の解像度を有するディスプレイにＹＵＶイメージを表示できると仮定する。この場合に、コントロールポイントは、上に記載のＵＲＬを次のように変更することができる。
【０１８７】
【表４】
2007515015.tif 000005
【０１８８】
次に、レンダリングデバイス３０６は、この変更されたＵＲＬをメディアサーバ３０２にサブミットすることができる（コントロールポイントから受信した後に）。メディアサーバ３０２は、所望のリソースコンテンツアイテムを取り出し、レンダリングデバイス３０６に送信する前に、１２８０×１０２４の指定された解像度に変換することによって応答する。
【０１８９】
メディアレンダリングデバイス３０６がＲＧＢイメージだけを表示できる、もう１つの例を検討されたい。この場合に、コントロールポイントは、次のように、ＵＲＬ（元々はＹＵＶフォーマットタイプを指定していた）をＲＧＢフォーマットタイプに変更することができる。
【０１９０】
【表５】
2007515015.tif 000006
【０１９１】
やはり、メディアサーバ３０２は、メディアレンダリングデバイス３０６に送信する前に、リソースコンテンツアイテムのイメージをＲＧＢイメージに変換する。メディアサーバ３０２は、レンダリングデバイス３０６の解像度期待（すなわち、１２８０×１０２４）に対処するようにこのイメージのスケーリングも行う。
【０１９２】
一実施形態で、メディアサーバ３０２は、レンダリングデバイス３０６の指定に合うようにイメージの解像度を変換する時に、オリジナルイメージのアスペクト比を保存することを試みる。これによって、イメージが、レンダリングデバイス３０６で不自然に歪んで見えることが防がれる。これによって、レンダリングデバイスのディスプレイサーフェスに、イメージコンテンツを含まない領域が残される場合がある。ＵＲＬで指定できる塗潰しカラーを使用して、これらの空の領域に背景色を表示することができる。
【０１９３】
上の例では、イメージをレンダリングするためのパラメータ化されたＵＲＬの使用を強調した。しかし、この戦略は、オーディオ情報およびビデオ情報など、他のメディアタイプおよび情報タイプにも適用可能である。例えば、ＰＣＭオーディオの場合に、ＵＲＬに、サンプリングレート、チャネル数（モノラル、ステレオ、５．１サラウンドサウンドなど）、およびサンプルあたりのビット数を指定するパラメータを含めることができる。デジタルビデオについて、ＵＲＬによって、レンダリングデバイスでＮＴＳＣまたはＰＡＬが使用されなければならないことなどを指定することができる。
【０１９４】
さらに、上で提示した例では、リソースコンテンツのフォーマットに関する（例えば、一般に、リソースコンテンツがストアされ、かつ／または提示される形に関する）めいめいの特有の属性を記述するＵＲＬパラメータの使用を強調した。しかし、他のパラメータによって、リソースコンテンツの他の特徴に関係する属性を記述することができる。例えば、これらの他のパラメータによって、リソースコンテンツの先頭からの、リソースコンテンツが再生される位置のタイムインターバル、ならびに再生の持続時間など、リソースコンテンツの再生に関連するタイミング情報を記述することができる。
【０１９５】
さらに、上で提示した例で、単一のＵＲＬが、リソースコンテンツアイテムに関連するすべてのメディアフォーマット置換を定義するのに使用される場合を説明した。しかし、メディアサーバは、リソースコンテンツアイテムの異なる態様を表すのに複数のＵＲＬを使用することができる。例えば、異なるＭＩＭＥタイプについて異なるＵＲＬを生成することができ、各ＵＲＬに、特定のＭＩＭＥタイプのコンテキスト内の１つまたは複数のパラメータを含めることができる。例えば、ＷＭＡフォーマットまたはＭＰ３フォーマットでリソースコンテンツアイテムを提示できるメディアサーバが、この２つのフォーマットに対応する２つのＵＲＬを提供することができる。これらのＵＲＬのそれぞれに、その特定のＭＩＭＥタイプ内の変化するフォーマット特性に関する１つまたは複数の変数パラメータを含めることができる。例えば、ＷＭＡ  ＵＲＬに、１２８ｋｂｐｓのビットレートから９０ｋｂｐｓのビットレートまで変更できるビットレートパラメータなどを含めることができる。あるＭＩＭＥタイプ（または他のタイプのカテゴリ）から別のタイプへの変換を、「フォーマット間」トランスコーディングと呼ぶことができる。あるＭＩＭＥタイプ（または他のタイプのカテゴリ）内でのパラメータの変換を、「フォーマット内」トランスコーディングと呼ぶことができる。しかし、これは、単に１つの例示的なシナリオである。上で述べたように、上で説明した実施形態は、単一のＵＲＬを使用して、フォーマットタイプを含むリソースコンテンツアイテムのすべての態様の間で変換した。
【０１９６】
さらに、上で提示した例で、それによってコントロールポイントがオリジナルＵＲＬを受信し、そのＵＲＬを変更し、その変更されたＵＲＬをメディアレンダリングデバイスに転送する（または、変更が行われない場合に、変更されていないＵＲＬをメディアレンダリングデバイスに転送する）リソースコンテンツ取り出しプロシージャを説明した。次に、メディアレンダリングデバイスが、変更された（または未変更の）ＵＲＬをメディアサーバに転送し、変更されたＵＲＬまたは未変更のＵＲＬで識別されるリソースコンテンツアイテムを返すようにメディアサーバに促す。しかし、多数の他の取り出し方式が可能である。例えば、コントロールポイントが、オリジナルＵＲＬを取り出し、これを即座にメディアレンダリングデバイスに送信することができる。メディアレンダリングデバイスは、ＵＲＬを変更し（あるいは、変更しないと決定し）、このＵＲＬをメディアサーバに転送することができる。この実施形態では、コントロールポイントは、メディアレンダリングデバイスのレンダリング要件／特性を調べる必要がない。というのは、メディアレンダリングデバイス自体が、必要なまたは望まれるＵＲＬのすべての変更を処理しているからである。他の置換が可能である。例えば、単一の受信側エンティティが、すべての機能を実行することができ、コントロールポイントおよびメディアレンダリングデバイス以外の１つまたは複数の他のエンティティを使用して、リソース情報の取出の役割のために働かせることができる。
【０１９７】
最後に、上の議論は、メディアサーバ３０２が、変更されたＵＲＬを受け取り、変更されたＵＲＬに基づいてリソースコンテンツアイテムを処理し、そのリソースコンテンツをレンダリングデバイス（または他の受信側エンティティ）に分け与える役割のために働く１つの実施形態に基づくものであった。しかし、より一般的に、これらのタスクのそれぞれまたはタスクの異なる割当を実行するために複数のエージェントまたはモジュールを有する（またはそれを有するのものとして概念化できる）メディアサーバ３０２を実施することができ、これらのタスクを実行するエージェントは、一緒におよび／またはメディアサーバ３０２の他の部分と共に同一の位置に置くことも、そうしないこともできる。例えば、一実施形態で、メディアサーバ３０２を、一緒にメディアサーバ３０２を構成する上で説明したタスクを実行する分散したエージェントの疎な集合とみなすことができる。
【０１９８】
Ｂ．例示的なユーザインターフェース（ＵＩ）プレゼンテーション
１つの例示的な実施形態で、コントロールパネルモジュール５０６（図５の）は、メディアサーバユーザがメディアサーバ３０２と相互作用できるようにする一連のＵＩプレゼンテーション（ページとも称する）を提供する。例えば、コントロールパネルモジュール５０６は、ＵＰｎＰネットワーク３１４に結合されたデバイスをイネーブルし、ディスエーブルする第１の一連のＵＩページを提供することができる。コントロールパネル５０６モジュールは、メディアサーバユーザが、共有されなければならないリソースおよびそのリソースを共有する条件を選択できるようにするもう１つの一連のＵＩページを提供することができる。セクションＢ．１およびＢ．２で、それぞれ、この２つのカテゴリのＵＩページを説明する。
【０１９９】
一般に、一実施形態で、コントロールパネルモジュール５０６は、コントロールパネルインターフェース（米国ワシントン州レッドモンドのＭｉｃｒｏｓｏｆｔ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎ社によって提供される馴染みのあるコントロールパネルインターフェース機能性など）を介して、上で説明したＵＩページを提供することができる。したがって、ＵＩプレゼンテーションを調整して、コントロールパネルＵＩプレゼンテーションのルックアンドフィール（例えば、「タブ付き」ディスプレイページを有する）を採用することができる。このＵＩスタイルの選択は、単に例示であり、他のスタイルおよびＵＩレイアウトを使用して、ＵＩページを実装することができる。
【０２００】
Ｂ．１．新しいデバイスを許可する例示的なＵＩ
図８〜１０に、コントロールパネルモジュール５０６がネットワーク３１４へのデバイスの導入を処理するのに使用できる様々なＵＩページを示す。
【０２０１】
まず、新しいメディアレンダリングデバイスが、ＵＰｎＰネットワーク３１４で検出された時に、メディアサーバユーザにその存在について警告するようにメディアサーバ３０２を実施することができる。１つの技法によれば、コントロールパネルモジュール５０６が、図８に示されたバルーンタイプのメッセージ８００を提供することによって、この警告機能を実行することができる。このメッセージ８００は、「A New Digital Media Receiver has been, found.  Do you wish to enable, disable, or configure this device?（新しいデジタルメディアレシーバが見つかりました。このデバイスを、イネーブル、ディスエーブル、または構成しますか）」と述べるものである。このメッセージ８００に、選択されるオプションに関連するハイパーテキストリンクをクリックすることによって、メディアサーバユーザが列挙されたオプションの１つを選択できるようにするハイパーリンクを含めることができる。他のメッセージスタイルおよび選択フォーマットを使用することができ、図８に示されたメッセージ８００は、単に１つの例にすぎない。
【０２０２】
コントロールパネルモジュール５０６は、メッセージ８００のハイパーテキストリンクがアクティブ化された時に、図９に示されたＵＩページ９００をアクティブ化する。このページ９００に、複数のセクション（９０２、９０４、９０６）が含まれる。各セクションは、ＵＰｎＰネットワーク３１４に結合された異なるデバイスに関する情報を提供する。例えば、セクション９０２は、新しいデバイスが見つかったことを示す。このセクション９０２は、新しいデバイスの製造業者およびモデルも識別する。このセクション９０２は、このセクション内のハイパーテキストリンクをアクティブ化することによって新しいデバイスをイネーブルするオプションを、メディアサーバユーザに与える。セクション９０４は、デバイスが前にイネーブルされたことを説明する。したがって、このセクション９０４は、このセクション９０４に関連するハイパーテキストリンクをアクティブ化することによってこのデバイスをディスエーブルする機会をメディアサーバユーザに与える。セクション９０６は、デバイスが前にディスエーブルされたことを説明する（それ以外の点ではＵＰｎＰネットワーク３１４にとって新規でない）。したがって、このセクション９０６は、このデバイスをもう一度イネーブルする機会をメディアサーバユーザに与える。
【０２０３】
コントロールパネルオブジェクト５０６は、メディアサーバユーザがＵＩページ９００のセクションのいずれかに関連するハイパーテキストリンクをアクティブ化した場合に、図１０に示されたＵＩページ１０００をアクティブ化する。ＵＩページ１０００は、選択されたデバイスの特性を記述した概要情報を提供する。このページには、３つのコマンドボタン（１００２、１００４、１００６）も含まれる。コマンドボタン１００２は、メディアサーバユーザがデバイスをイネーブルできるようにする。コマンドボタン１００４は、メディアサーバユーザがデバイスをディスエーブルできるようにする。コマンドボタン１００６は、メディアサーバユーザが、ＵＩディスプレイページに現れる時のデバイスの名前を変更できるようにする。この最後のボタン１００６は、「子供のＰＣ」など、簡単に認識される「ユーザフレンドリ」名をデバイスに与えるのに有用である可能性がある。
【０２０４】
Ｂ．２．リソースを共有する例示的なＵＩ
図１１に、様々なリソースフォルダと、ＵＰｎＰネットワーク３１４を介するこれらのリソースフォルダ内のリソース情報（リソースメタデータおよびリソースコンテンツを含む）の散布を決定する異なる配布判断基準との間の関連付けを示すＵＩプレゼンテーションページ１１００を示す。ページ１１００に、３つの例示的なエントリ１１０２が示されている。第１のエントリは、リソースストア３２０での共有リソースフォルダの名前（例えば、リソースフォルダ「Ｃ：＼Ｍｙ  ｖｉｄｅｏｓ」１１０４）、このリソースフォルダに関連する同意関連判断基準（例えば、「Ａｌｌ  ｕｓｅｒｓ」１１０６）、およびこのリソースフォルダに関連するデバイス判断基準（例えば、「Ａｌｌ  ｄｅｖｉｃｅｓ」１１０８）を識別する。判断基準「Ａｌｌ  ｕｓｅｒｓ」１１０６は、リソースフォルダ「Ｃ：＼Ｍｙ  ｖｉｄｅｏｓ」１１０４内のリソースを、メディアサーバ３０２を実装するコンピュータに誰がログオンしているかに無関係に取り出せることを示す。判断基準「Ａｌｌ  ｄｅｖｉｃｅｓ」１１０８は、リソースフォルダ「Ｃ：＼Ｍｙ  ｖｉｄｅｏｓ」１１０４内のリソースを、ＵＰｎＰネットワーク３１４内のどのレンダリングデバイスによっても取り出せることを示す。
【０２０５】
その一方で、第２のエントリは、「Ｃ：＼Ｍｙ  ｐｈｏｔｏｓ」という名前１１１０、「Ｄｏｎａｌｄ」というユーザ１１１２、「Ｋｉｄｓ  ｂｅｄｒｏｏｍ  ｄｅｖｉｃｅ」というデバイス１１１４を識別する。ユーザ判断基準「Ｄｏｎａｌｄ」１１１２によって、リソースフォルダ「Ｃ：＼Ｍｙ  ｐｈｏｔｏｓ」１１１０内のリソース情報は、ユーザＤｏｎａｌｄがメディアサーバ３０２を実装するコンピュータの現在アクティブなターミナルサーバセッションにログオンしている時（あるいは、たとえＵＰｎＰネットワーク３１４内のコンシューマがリソース情報へのアクセスを試みる時にポップアップメッセージに肯定的に応答することによるなど、Ｄｏｎａｌｄが他の形でリソース情報の転送に同意を与える時）に限って取り出すことができる。この設計モチーフに対する他の変形形態も可能である。例えば、上で述べたように、リソース情報の配布を決定する複数の配布判断基準（または２つ未満の判断基準もしくは判断基準なし）を提供するようにリソース情報共有機能性３２２を構成することができる。
【０２０６】
３つのリソースフォルダ１１０２だけが図１１に示されている。メディアサーバユーザは、追加コマンドボタン１１１６を作動させることによって、共有する追加のリソースフォルダを選択することができる。変更コマンドボタン１１１８は、メディアサーバユーザが共有リソースフォルダ１１０２の既存リストを変更できるようにする。除去コマンドボタン１１２０は、メディアサーバユーザがリソースフォルダ１１０２の既存コレクションからリソースフォルダを除去できるようにする。
【０２０７】
前のセクションで説明したように、判断基準の第１のセットは、リソースメタデータの散布を決定し、判断基準の第２のセットは、リソースコンテンツの散布を決定する。説明を容易にするために、図１１は、判断基準の同一のセットが、リソースメタデータとリソースコンテンツの両方の配布を決定するという仮定に基づく。しかし、リソース情報共有機能性３２２が、リソースメタデータの判断基準とリソースコンテンツの判断基準をメディアサーバユーザが区別することを可能にする場合に、このユーザインターフェースページを適当に変更して、より微細な粒度の判断基準情報を表示し、メディアサーバユーザがより微細なレベルで判断基準情報を入力できるようにすることができる。リソースメタデータの判断基準とリソースコンテンツの判断基準は、これらのカテゴリに異なるユーザ入力ページを割り当てることによるなど、異なる形でユーザインターフェースで区別することができる。
【０２０８】
図１２に、メディアサーバユーザが図１１の変更コマンドボタン１１１８を押した時にコントロールパネルモジュール５０６がアクティブ化させるページ１２００を示す。例えば、メディアサーバユーザが、図１１の最初のエントリ１１２２を強調表示し（例えば、マウスデバイスまたは他の入力機構を使用することによって）、コマンドボタン１１１８を押したと仮定する。結果の、図１２に示されたページ１２００は、最初のエントリ１１２２の様々な既存プロパティを示し、これらのプロパティを変更する機会をメディアサーバユーザに与える。
【０２０９】
例えば、ページ１２００は、リソースの共有名を「Ｍｙ  ｖｉｄｅｏｓ」１２０２として、同意関連判断基準を「Ａｌｌ」１２０４として、デバイス判断基準を「Ａｌｌ  ｄｅｖｉｃｅｓ」１２０６として識別する。メディアサーバユーザは、関連するテキストボックスの情報を編集することによって、第１フィールド１２０２を変更することができる（例えば、マウスおよびキーボード入力デバイスを使用してこのフィールドを編集することによって）。第２および第３のフィールド（１２０４、１２０６）は、それぞれ、事前定義のユーザおよびデバイスのリストを提供するプルダウン選択メニューとしてセットアップされている。例えば、図１２では、プルダウン選択フィールド１２０６が展開されて、その事前定義のリストが示されている。メディアサーバユーザは、このプルダウンリストから１つまたは複数のエントリを選択して、これらの２つのフィールド（１２０４、１２０６）の入力を提供することができる。テキストエントリボックスおよびプルダウンメニュー以外の他のデータ入力技法を使用して、ページ１２００によって請求される情報を入力することができる。やはり、メディアサーバ機能性３２２が、メディアサーバユーザがリソースメタデータ判断基準とリソースコンテンツ判断基準を区別することを可能にする場合に、このページ１２００を適当な形で拡大して、データ入力用の追加フィールドを提供することができる。
【０２１０】
図１１および１２は、リソースフォルダを選択するのに使用できるＵＩ戦略およびリソースフォルダに関連する散布判断基準を定義するのに使用できるＵＩ戦略を網羅したものではない。例えば、図１３に、共有リソースフォルダおよびそれに関連する配布判断基準のすべてのマスタ表示を提供し、メディアサーバユーザがこのページ１３００自体を使用して（例えば、別のページを呼び出す必要なしに）表示される情報のどれでも変更できるようにする例示的なページ１３００を示す。例えば、このページ１３００の各ユーザフィールドおよび各デバイスフィールドに、メディアサーバユーザがこれらのフィールドの表示される選択を変更できるようにするめいめいのドロップダウンメニューが含まれる。例えば、例示的なユーザフィールド１３０４のドロップダウンメニュー１３０２および例示的なデバイスフィールド１３０８のドロップダウンメニュー１３０６を検討されたい。ブラウズコマンドボタン１３１０によって、メディアサーバユーザが、どのリソースフォルダを共有リソースに追加する（例えば、追加コマンドボタン１３１２をアクティブ化することによって）かを決定する前に、様々なディレクトリを調べられるようになる。前と同様に、除去コマンドボタン１３１４は、前に選択されたリソースフォルダを共有リソースから除去するように機能する。
【０２１１】
図１４に、判断基準情報を入力するもう１つの代替技法を示す。この図に示されたページ１４００は、メディアサーバユーザが、すべての共有リソースフォルダに影響するグローバル判断基準情報を指定できるようにする。すなわち、選択アイテム１４０２は、誰がメディアサーバ３０２にログオンしているかに無関係にメディアサーバ３０２がすべての共有リソースフォルダのリソース情報を共有しなければならないかどうかを、メディアサーバユーザが指定できるようにする。選択アイテム１４０４は、メディアサーバ３０２が区別なしにすべてのドライブのリソースフォルダのすべてを配布しなければならないかどうかを、メディアサーバユーザが指定できるようにする。これらの選択アイテム（１４０２、１４０４）は、チェックボックスＵＩ入力特徴または他の種類のＵＩ入力特徴を使用して、メディアサーバユーザからバイナリＹＥＳ／ＮＯ選択を受け取ることができる。
【０２１２】
ページ１４００は、メディアサーバユーザが、メディアサーバ３０２によって適用されるセキュリティを決定する様々な選択を行うことも可能にする。例えば、選択アイテム１４０６は、メディアサーバユーザがメディアサーバ３０２を実装するコンピュータを起動する時に、メディアサーバを自動的に起動しなければならないかどうかを、メディアサーバユーザが指定できるようにする。選択アイテム１４０８は、メディアサーバ３０２と相互作用することを許可されるネットワーク３１４上のデバイスの最大個数をメディアサーバユーザが指定できるようにする。類似するユーザ入力フィールド（図示せず）を使用して、メディアサーバユーザが、上のセクションＡ．５で述べたセキュリティ機構に関する他のセキュリティオプションを指定できるようにすることができる。例えば、許される場合に、適切なＵＩページを用いて、メディアサーバユーザがセクションＡ．５に記載の機構のいずれかを選択的にアクティブ化または非アクティブ化することならびにこれらの機構で使用される関連パラメータを指定することを可能にすることができる。
【０２１３】
最後に、図１５に、一般に「ウィザード」と称する、自動化されたセットアッププロシージャの一部として使用できるページ１５００を示す。このページは、リソースを含むリソースストア３２０で提供されるリソースフォルダの階層表現１５０２を提供する。ディレクトリ１５０２に、階層内のリソースフォルダのそれぞれに隣接して位置決めされたチェックボックスが含まれる。メディアサーバユーザは、めいめいのリソースフォルダの隣のチェックボックスを選択的にクリックすることによって、これらのリソースフォルダのそれぞれを共有しなければならないかどうかを示すことができる。このページ１５００の右端部分に、図１４に関して上で述べたものと同一のグローバル判断基準選択をメディアサーバユーザが行得るようにする選択アイテム（１５０４および１５０６）が提供される。
【０２１４】
上の議論では、配布判断基準が、フォルダごとの基礎でリソースに割り当てられた。しかし、コンテナごとの基礎で情報を表示し、メディアサーバユーザがコンテナごとの基礎で情報を入力できるようにすることによって、コンテナごとの基礎でリソースに配布判断基準を適用することも可能である。
【０２１５】
やはり、図面に示されたＵＩのレイアウトは、例示である。他のＵＩ戦略は、メディアサーバユーザが、デバイス、共有、セッティング、およびイベントという主要な話題の中から選択できるようにすることができる。共有カテゴリ内で、メディアサーバ３０２は、Ｍｙ  Ｍｕｓｉｃ、Ｍｙ  Ｐｉｃｔｕｒｅｓ、Ｍｙ  Ｖｉｄｅｏｓなどのリソースカテゴリ内のリソースを共有するオプションをメディアサーバユーザに与えることができる。
【０２１６】
Ｃ．例示的なプロセス
図１６および１７は、デバイス許可プロセスに関し、図１８〜２０は、リソース共有プロセスに関する。これらの図に示された個々のブロックは、ソフトウェア、ファームウェア、またはソフトウェアとファームウェアの組合せで実施することができる。
【０２１７】
Ｃ．１．デバイス許可プロセス
図１６に、メディアサーバ３０２が、ＵＰｎＰネットワーク３１４に追加された新しいデバイスを許可するプロシージャ１６００を示す。ステップ１６０２で、誰かが、新しいメディアデバイスをＵＰｎＰネットワーク３１４に接続する。ステップ１６０４で、メディアサーバ３０２が、新しいデバイスの存在をメディアサーバユーザに警告するメッセージを生成する。図８に、このメッセージを提供するのに使用できる１つのディスプレイフォーマットを示す。ステップ１６０６で、メディアサーバ３０２が、メディアサーバユーザが新しいデバイスをイネーブルできるようにするＵＩページ（１つまたは複数）を開く。図９および１０に、このステップを実施する２つの例示的なＵＩページを提供する。ステップ１６０８で、メディアサーバユーザが、例えば新しいデバイスのイネーブルまたはディスエーブルのいずれかを行うことによって、新しいデバイスに関する選択を行う。メディアサーバユーザは、新しいデバイスにユーザフレンドリ名を与えることも許可される。
【０２１８】
図１７に、新しいデバイスのアイデンティティを決定するプロシージャ１７００を示す。ステップ１７０２で、メディアサーバが、新しいデバイスのＩＰアドレスを識別する。ステップ１７０４で、メディアサーバが、ＩＰアドレスをメディアアクセス制御（ＭＡＣ）アドレス（または他のデバイス固有情報）に変換する。ＩＰアドレスは、例えば、Ａｄｄｒｅｓｓ  Ｒｅｓｏｌｕｔｉｏｎ  Ｐｒｏｔｏｃｏｌを使用する、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎ社のＩｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  Ｈｅｌｐｅｒが提供するＳｅｎｄＡＲＰ関数を使用することによって、ＭＡＣアドレスに変換することができる。許可されたならば、ネットワーク３１４との後続の相互作用で、デバイスをそのＩＰアドレスおよびＭＡＣアドレスによって識別することができる。デバイスの認証にＭＡＣアドレスを使用することが、有利である。というのは、ＩＰアドレスだけでは信頼できないからである（ＩＰアドレスは、ＤＨＣＰサーバの可用性に応じて変化する可能性があるからである）。
【０２１９】
図１６および１７に示された動作のより綿密な説明を、図５に示されたアーキテクチャ５００に関して与えることができる。新しいメディアレンダリングデバイスが追加される時に、そのデバイスは、ＵＰｎＰアナウンスメントを発する。デバイス監視モジュール５２０が、このアナウンスメントを検出する。同様に、デバイス監視モジュール５２０は、ＵＰｎＰネットワーク３１４に結合されたコントロールポイントによって行われる要求も検出する。それに応答して、デバイス監視モジュール５２０は、新しいデバイスのＩＰアドレスをルックアップし、ＳｅｎｄＡＲＰ（）を使用してＭＡＣアドレスを得る。ＭＡＣアドレスが新規である場合に、デバイス監視モジュール５２０は、コントロールパネルＣＯＭオブジェクト５４０に通知し、このコントロールパネルＣＯＭオブジェクト５４０は、既に存在するすべてのコールバックオブジェクト５４２に通知する。デバイス監視モジュール５２０は、ＣＤＤＭサービスモジュール５０４にも通知する。コントロールパネルコールバックオブジェクト５４２は、コントロールパネルモジュール５０６を介してメディアサーバユーザに通知する。ＣＤＤＭサービスモジュール５０４は、現在アクティブなターミナルサーバセッションについてコントロールパネルモジュール５０６を作成する必要があるかどうかを判断し、必要である場合には作成する。
【０２２０】
Ｃ．２．リソース共有プロセス
図１８に、メディアサーバユーザが、共有されるリソースフォルダを選択し、これらのリソースフォルダ内のリソース情報の散布を決定するのに使用される配布判断基準を指定できるようにするプロセス１８００を示す。図１９に、コンシューマが共有リソースフォルダをブラウズし、検索できるようにするプロセス１９００を示す。図２０に、コンシューマがパラメータ化されたＵＲＬ手法を使用して選択されたリソースコンテンツアイテムを取り出せるようにするプロセス２０００を示す。
【０２２１】
ａ．共有リソースの定義
まず図１８から始めると、プロシージャ１８００は、共有リソースフォルダおよび配布判断基準を指定する多数の形の１つの例示にすぎない。下のセクションＢで実証するように、この情報を収集する多数の異なるＵＩ戦略があり、したがって、このタスクを実行する多数の関連するプロセスがある。説明を容易にするために、リソースメタデータとリソースコンテンツの両方の散布を決定する判断基準の１つのセットだけが収集されると仮定する。リソース情報共有機能性３２２が、リソースメタデータとリソースコンテンツの判断基準の２つの異なるセットの間でメディアサーバユーザが区別することを可能にする場合に、図１８に示された動作を適切に拡張して、この情報を収集することができる。
【０２２２】
ステップ１８０２で、メディアサーバユーザが、共有リソースフォルダを選択する。図１１から１３に、メディアサーバユーザがこのタスクを実行するのに使用できる技法のうちの少数を示す。
【０２２３】
ステップ１８０４で、メディアサーバユーザが、リソース情報の転送に同意を与えなければならない個人（存在する場合に）を選択する。前に説明したように、この制約は、サービスがどのように構成されるかに応じて、文字どおりにまたはより狭く構成することができる。文字どおりの実施形態では、識別された個人が、メディアサーバ３０２を実装するコンピュータシステムの現在アクティブなターミナルサーバセッションにログオンしている場合に、暗黙の同意を与えると仮定する。より厳格な実施形態では、コンシューマがリソース情報の取出を試みる時に、識別された個人がこの転送を承認するかどうかを判定するために、メディアサーバ３０２が、識別された個人に具体的に問い合わせる。転送は、識別された個人がその転送を承認する場合に限って行われる。識別された個人が選択されない場合に、デフォルトで、リソースの配布に影響する同意関連制約はない。
【０２２４】
ステップ１８０６で、メディアサーバユーザが、選択されたリソースフォルダ内のリソース情報を受信することを許可されるデバイスを選択する。図１１〜１５に、ステップ１８０４および１８０６で収集される判断条件を請い求めるのに使用できるＵＩ技法のうちの少数を示す。また、前に注記したように、追加ステップを設けて、リソースフォルダ内のリソース情報の配布に影響する追加の判断基準を収集することができる。
【０２２５】
ステップ１８０８で、コントロールパネルモジュール５０６が、任意選択として、指定された同意関連ユーザ判断基準によって決定される、指定されたデバイスへの指定されたリソースフォルダ内のリソース情報の共有の結果をメディアサーバユーザに警告する。これは、メディアサーバユーザの選択によって課せられる制約（または課せられる制約がないこと）を説明するメッセージを提示することによって実行することができる。そのようなメッセージを見た後に、メディアサーバユーザは、１つまたは複数の以前の選択を改訂すると決定することができる。ステップ１８１０は、メディアサーバユーザが、指定された結果に満足しない場合に１つまたは複数の選択を繰り返すことができることを示し、そうでない場合には、プロセス１８００が継続される。
【０２２６】
ステップ１８１２で、メディアサーバ３０２が、メディアサーバユーザが、選択されたリソースフォルダ内のリソース情報を共有する許可を有するかどうかを判定する。すなわち、リソースフォルダの作成者が、リソースフォルダ内のリソース情報の変更、読み取り、および／または配布の許可を有する１人または複数の個人を指定している可能性がある。メディアサーバユーザが、これらの個人のうちの１人でない場合に、ステップ１８１４は、そのリソースフォルダを共有できないことを示す。メディアサーバユーザが、これらの個人のうちの１人である場合に、ステップ１８１４は、そのリソースフォルダのリソース情報を共有できることを示し、したがって、プロセス１８００が継続される。
【０２２７】
ステップ１８１６に、選択されたリソースフォルダの状況を「共有」に変更することが含まれる。このステップ１８１６に、共有リソースストア５３２内の共有リソースフォルダを登録することと、関連する配布判断基準を判断基準情報５３６にストアすることを含めることができる。
【０２２８】
上の議論では、配布判断基準が、フォルダごとの基礎でリソースに割り当てられる。しかし、配布判断基準を、上で説明したものに類似する形でコンテナごとの基礎でリソースに割り当てることも可能である。
【０２２９】
リソースフォルダ内のリソースの共有に関する追加の一般的な考慮事項を、下に示す。下の議論では、「リソース」が、リソースストア３２０にストアされたリソースフォルダ内のファイルに対応することができる。リソースフォルダは、共有可能状況または非共有可能状況を有するものとして示される。また、各リソースが、リソースメタデータおよびリソースコンテンツを含む、実際に散布される「リソース情報」を有することも想起されたい。
【０２３０】
具体的に言うと、１つの例示的な実施形態で、コンテンツディレクトリサービスモジュール５２６は、メディアサーバユーザが、リソースフォルダ内の個々のリソースではなく、リソースフォルダを共有可能として指定することだけを許容する。すなわち、リソースは、リソースごとの基礎ではなく、共有可能リソースフォルダに含めることによって共有可能として指定される。さらに、コンテンツディレクトリサービスモジュール５２６は、メディアサーバユーザが、オーディオリソース、ビデオリソース、および写真リソースのあるタイプ（オーディオファイルについて、フォーマットＭＰ３、ＷＭＡ、ＰＣＭ、およびＷＡＶ；ビデオファイルについて、フォーマットＭＰＥＧ−１、２、ＷＭＶ、およびＡＶＩ；およびピクチャフォーマットについて、フォーマットＪＰＥＧ、ＧＩＦ、ＢＭＰ、ＰＮＧ、およびＴＩＦＦ：を含むファイルの例示的な領域など）を共有可能として指定することだけを許容することができる。さらに、コンテンツディレクトリサービスモジュール５２６は、隠しファイル、ネットワーク共有、およびリムーバブルメディアを共有可能と指定することに制限を課す（すなわち、これによって、メディアサーバユーザがこれらのリソースを共有可能として指定することを防ぐ）ことができる。これらの備えは、ＵＰｎＰネットワーク３１４によって提供されるセキュリティを改善するのに有益である可能性がある。というのは、上の許容可能なカテゴリに含まれない馴染みのないリソース情報が、共有されないからである。しかし、代替実施形態で、上で識別された「禁止される」リソースの１つまたは複数を共有可能として指定することが可能である。
【０２３１】
もう１つの例示的な実施形態で、共有可能として指定されたリソースフォルダが、追加のサブコレクション（例えば、サブフォルダおよびファイル）を有することができる。メディアサーバユーザが、所与のリソースフォルダのすべてを共有可能として指定することを選択した時に、共有リソースフォルダおよびそのすべての従属サブフォルダ内のすべてのリソースをも、共有可能として自動的に指定することができる。
【０２３２】
もう１つの例示的な実施形態で、メディアサービスモジュール５０２は、メディアサーバユーザが、リソースフォルダを「共有解除」として指定する（例えば、これによって、前にリソースフォルダに割り当てられたリソースフォルダの共有可能状況を除去するために）ことをも許容する。しかし、１つの例示的な実施形態で、メディアサーバユーザは、共有可能親リソースのサブリソース（例えば、サブフォルダおよびファイル）のいずれかを共有不能として指定することを許可されない。すなわち、例えば、メディアサーバユーザが、「ｃ：＼ｄｏｃ＼」を共有可能として指定する場合に、メディアサーバユーザは、例えばルートリソースフォルダ「ｃ：＼ｄｏｃ＼」が共有として指定されているので、「ｃ：＼ｄｏｃ＼ｍｕｓｉｃ＼」を共有解除として指定することを許可されない。しかし、もう１つの実施形態で、共有解除されるリソースの選択的指定を許容するようにコンテンツディレクトリサービスモジュール５２６を構成することができる。
【０２３３】
もう１つの例示的な実施形態で、メディアサーバユーザは、共有として指定されたリソースディレクトリの名前を変更することができる。コンテンツディレクトリサービスモジュール５２６は、このサービスの実行中の名前のすべての変更を追跡し、古い名前に関連する共有関連プロパティを新しい名前に自動的に変換することができる。メディアサーバユーザが、共有として指定されたリソースのいずれかに変更を加える時に、必ず、ＵＰｎＰネットワーク３１４に結合されたデバイスにこの変更について通知するようにコンテンツディレクトリサービスモジュール５２６を構成することができる。これは、ＵＰｎＰイベントを送出することによって実行することができる。
【０２３４】
ｂ．要求に基づく共有リソースの配布
図１９に、コンシューマがコンテンツディレクトリサービスモジュール５２６と相互作用できるようにするプロシージャ１９００を示す。ステップ１９０２で、コンシューマが、共有として指定されたリソースに関するリソースメタデータを提供するようにメディアサーバ３０２に要求する。コンシューマは、選択されたリソースコンテンツを最終的に受信するレンダリングデバイスに一体化されるか他の形で関連するコントロールポイントからこの要求を行うことができる。その代わりに、コンシューマは、リソースコンテンツを最終的に受信するレンダリングデバイスからリモートのコントロールポイントからこの要求を行うことができる。コンシューマは、具体的には、メディアサーバ３０２とのブラウズセッションを開始することができ、この場合に、メディアサーバ３０２は、おそらくは１つまたは複数のカテゴリ内の、共有として指定された使用可能なリソースのリスティングを示すリソースメタデータを提供することによって応答する。コンシューマは、その代わりに、メディアサーバ３０２との検索セッションを開始することができ、この場合に、メディアサーバ３０２は、コンシューマによって指定された１つまたは複数の検索パラメータに基づいてターゲットを指定された検索を実行し、検索結果の表示をコンシューマに返すことによって応答する。
【０２３５】
ステップ１９０４で、メディアサーバ３０２が、共有リソースストア５３２をスキャンして、コンシューマの要件を満たす、共有リソースフォルダに関連するすべてのリソースメタデータアイテムを突き止める。すなわち、これには、ブラウズパラメータまたは検索パラメータ（例えば、所望のリソースタイプ、リソース名、リソースアーティストなどに関する）を満たす特定のリソースメタデータアイテムを選り抜くためにリソースメタデータ５３４を調べることが含まれる。このスキャンに、それ以外の点でブラウズ条件または検索条件と一致するリソースメタデータアイテムが指定された関連する配布判断基準を満足しないかどうかを判定するために、判断基準情報５３６を調べることも含めることができる。例えば、メディアサーバ３０２が、コンシューマの要件を満たす１０個のリソースメタデータアイテム（１０個の関連するリソースに対応する）を識別するが、このうちの３つだけが、デバイス関連判断基準によって、コンシューマが現在使用しているデバイス（例えば、コンシューマがそこからブラウズ要求または検索要求を送信したコントロールポイントに関連する）での表示を許可される場合がある。
【０２３６】
ステップ１９０６で、メディアサーバ３０２が、上で説明した処理の結果を記述したＸＭＬメッセージを生成する。このＸＭＬメッセージは、メッセージに含まれなければならない情報の様々なフィールドおよびこれらのフィールドを提示するフォーマットを指定するＸＭＬスキーマによって決定することができる。ＸＭＬ以外のフォーマットを使用してこの情報を伝えることができる。ステップ１９０８で、メディアサーバ３０２が、メディアサーバ３０２からコンシューマが使用しているコントロールポイントにこのメッセージを送信する。
【０２３７】
ステップ１９１０で、コントロールポイントが、ＸＭＬメッセージを受信し、プレゼンテーションフォーマットに変換する。コンシューマは、メディアサーバ３０２によって識別された１つまたは複数の共有リソースに対応するリソースメタデータアイテムのリストを見ることを許可される。コンシューマは、選択されたレンダリングデバイスでのプレゼンテーションのために、リストから１つまたは複数のリソースを選択することができる。
【０２３８】
ｃ．パラメータ化されたＵＲＬの処理
図２０に、以前のＵＰｎＰアクション（例えば、ブラウズアクションまたは検索アクション）に応答して供給されたＵＲＬに基づいて共有リソースコンテンツアイテムを取り出すプロセス２０００を示す。具体的に言うと、ブラウズアクションまたは検索アクションに応答してメディアサーバ３０２によって送信されるリソースメタデータに、共有アイテムに関連するリソースコンテンツアイテムが位置する場所を記述した共有リソースのＵＲＬ（ｕｎｉｆｏｒｍ  ｒｅｓｏｕｒｃｅ  ｌｏｃａｔｏｒ）が含まれる。ＵＲＬは、上のセクションＡ．６で説明したパラメータ化された手法を使用して構造化することができる。図２０に示されたプロセス２０００は、これらのパラメータ化されたＵＲＬを処理する技法を説明するものである。
【０２３９】
ステップ２００２で、コンシューマが、コントロールポイント３１６などのコントロールポイントでメディアサーバ３０２からのリソースメタデータを受信する。このステップは、全般的に図１９のステップ１９１０に対応する。共有リソースについて、メタデータに、通常は少なくとも１つのパラメータ化されたＵＲＬが含まれる。セクションＡ．６で説明したように、このＵＲＬのパラメータは、このＵＲＬによって識別されるリソースコンテンツアイテムのメディアフォーマットを指定する。例えば、１つのパラメータが、リソースコンテンツアイテムを提供できるフォーマットタイプ（イメージリソースのＲＧＢまたはＹＵＶフォーマットタイプなど）を記述することができる。もう１つのパラメータが、リソースコンテンツアイテムのフォーマット解像度（特定のイメージ解像度の高さおよび幅など）を記述することができる。これらのパラメータは、単に例示であり、追加のまたは異なるパラメータを供給することができる。どの場合でも、ブラウズ要求または検索要求に対する応答を定式化する時に、メディアサーバ３０２は、例えば、リソースコンテンツアイテムが現在メディアサーバ３０２にストアされているメディアフォーマットを反映することができる、これらのパラメータのデフォルト値を選択することができる。あるいは、メディアサーバ３０２は、メディアサーバ３０２が他の考慮事項に基づいて最善と判定するデフォルト値を選択することができる。
【０２４０】
ステップ２００４で、コントロールポイント３１６が、任意選択として、返されるパラメータ化されたＵＲＬの１つまたは複数のパラメータを変更する。例えば、ＵＲＬは、元々はあるイメージ解像度を指定している場合がある。コントロールポイントは、イメージを提示するレンダリングデバイスによって提供されるより高いディスプレイ解像度に対処するためにこのパラメータの値を変更することができる。
【０２４１】
ステップ２００６で、コントロールポイント３１６が、レンダリングデバイス３０６など、リソースコンテンツアイテムを最終的にレンダリングするレンダリングデバイスに変更された（または未変更の）ＵＲＬを転送する。
【０２４２】
次に、ステップ２００８で、レンダリングデバイス３０６が、変更されたＵＲＬをメディアサーバ３０２にサブミットすることができる。このステップは、変更された（または未変更の）ＵＲＬを含むＨＴＴＰ  ＧＥＴコマンドを介して実行することができる。
【０２４３】
ステップ２０１０で、メディアサーバ３０２が、変更された（または未変更の）ＵＲＬを含むＨＴＴＰ  ＧＥＴコマンドを受信する。次に、メディアサーバ３０２が、リソースストア３２０からリソースコンテンツアイテムを取り出す。取り出されたリソースコンテンツアイテムが、ＵＲＬで指定されたメディアフォーマットを有しない場合には、メディアサーバ３０２が、指定されたメディアフォーマットに変換することができる。
【０２４４】
ステップ２０１２で、メディアサーバ３０２が、変更されたＵＲＬによって識別されたリソースコンテンツアイテムを、レンダリングデバイス３０６でのプレゼンテーションのためにこのレンダリングデバイス３０６に転送する。
【０２４５】
ステップ２０１４で、メディアレンダリングデバイス３０６が、メディアサーバ３０２によって送信されたリソースコンテンツアイテムを受信し、提示する。レンダリングデバイス３０６は、任意選択として、レンダリングデバイス３０６でのプレゼンテーションの前に、リソースコンテンツアイテムを別のメディアフォーマットに変換することもできる。
【０２４６】
やはり、図２０に示されたプロシージャは、単に１つの可能なシナリオである。もう１つのシナリオでは、コントロールポイント３１６が、オリジナルＵＲＬをレンダリングデバイス３０６に転送することができ、レンダリングデバイス３０６が、そのＵＲＬを変更する（または変更しないと決定する）ことができる。その後、レンダリングデバイス３０６が、この変更された（または未変更の）ＵＲＬを、上で説明した形でメディアサーバ３０２に送信する。
【０２４７】
図２０では、ＵＲＬの１つまたは複数のパラメータに、対応するリソースコンテンツアイテムのメディアフォーマットを指定する情報が含まれると仮定した。しかし、他のＵＲＬに、メディアフォーマット情報以外のリソースコンテンツアイテムの他の特性（タイミング関連情報など）を指定するパラメータを含めることができる。
【０２４８】
最後に、図２０の基本的なフレームワークは、リソースメタデータにパラメータ化されたＵＲＬが含まれない場合（すなわち、リソースメタデータに、変数パラメータを有しないＵＲＬが含まれる場合）にも適用される。この場合に、図２０に示されたＵＲＬ変更動作は、実行されない。
【０２４９】
Ｄ．例示的なコンピュータ環境
図２１は、図３および５に記載のメディアサーバ３０２の機能性など、前のセクションで説明した処理機能のいずれかを実施するのに使用できるコンピュータ環境２１００に関する情報を提供する。類似するコンピューティング機能性を使用して、コントロールポイント（例えば、コントロールポイント３１６、３１８）およびメディアレンダリングデバイスのいずれか（３０４〜３１２）などを実施することができる。
【０２５０】
コンピューティング環境２１００に、図１に関して述べた汎用コンピュータ２１０２およびディスプレイデバイス２１０４が含まれる。しかし、コンピューティング環境２１００に、他の種類のコンピュータアーキテクチャおよびネットワークアーキテクチャを含めることができる。例えば、図示されていないが、コンピュータ環境２１００に、ハンドヘルドデバイス、ラップトップッデバイス、セットトップボックス、プログラマブルコンシューマエレクトロニクス、メインフレームコンピュータ、ゲーム機などを含めることができる。さらに、図２１に、議論を容易にするために一緒にグループ化されたコンピュータ環境２１００の要素が示されている。しかし、コンピューティング環境２１００は、分散処理構成を使用することができる。分散コンピューティング環境では、コンピューティングリソースを、環境全体にわたって物理的に分散させることができる。
【０２５１】
例示的なコンピュータ２１０２に、１つまたは複数のプロセッサまたは処理ユニット２１０６、システムメモリ２１０８、およびバス２１１０が含まれる。バス２１１０は、様々なシステムコンポーネントを一緒に接続する。例えば、バス２１１０は、プロセッサ２１０６をシステムメモリ２１０８に接続する。バス２１１０は、様々なバスアーキテクチャのいずれかを使用する、メモリバスまたはメモリコントローラ、周辺バス、ａｃｃｅｌｅｒａｔｅｄ  ｇｒａｐｈｉｃｓ  ｐｏｒｔ、およびプロセッサバスまたはローカルバスを含む、すべての種類のバス構造またはバス構造の組合せを使用して実施することができる。例えば、そのようなアーキテクチャに、ＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ  ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとも称するＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）バスを含めることができる。
【０２５２】
コンピュータ２１０２に、それぞれを取外し可能または取り外し不能とすることができる、様々なタイプの揮発性媒体および不揮発性媒体を含む様々なコンピュータ可読媒体も含めることができる。例えば、システムメモリ２１０８に、ランダムアクセスメモリ（ＲＡＭ）２１１２などの揮発性メモリ、および読取専用メモリ（ＲＯＭ）２１１４などの不揮発性メモリの形のコンピュータ可読媒体が含まれる。ＲＯＭ  ２１１４に、スタートアップ中などにコンピュータ２１０２内の要素の間での情報の転送を助ける基本ルーチンを含む入出力システム（ＢＩＯＳ）２１１６が含まれる。ＲＡＭ  ２１１２に、通常は、処理ユニット２１０６によって素早くアクセスできる形のデータおよび／またはプログラムモジュールが含まれる。
【０２５３】
他の種類のコンピュータストレージ媒体に、取外し不能不揮発性磁気媒体から読み取り、これに書き込むハードディスクドライブ２１１８、取外し可能不揮発性磁気ディスク２１２２（例えば「フロッピー（登録商標）ディスク」）から読み取り、これに書き込む磁気ディスクドライブ２１２０、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、または他の光媒体などの取外し可能不揮発性光ディスク２１２６から読み取り、かつ／またはこれに書き込む光ディスクドライブ２１２４が含まれる。ハードディスクドライブ２１１８、磁気ディスクドライブ２１２０、および光ディスクドライブ２１２４は、それぞれ、１つまたは複数のデータ媒体インターフェース２１２８によってシステムバス２１１０に接続される。その代わりに、ハードディスクドライブ２１１８、磁気ディスクドライブ２１２０、および光ディスクドライブ２１２４を、ＳＣＳＩインターフェース（図示せず）または他の結合機構によってシステムバス２１１０に接続することができる。図示されていないが、コンピュータ２１０２に、磁気カセット、または他の磁気ストレージデバイス、フラッシュメモリカード、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光ストレージ、電気的消去可能プログラマブル読取専用メモリ（ＥＥＰＲＯＭ）などの他のタイプのコンピュータ可読媒体を含めることができる。
【０２５４】
一般に、上で識別されたコンピュータ可読媒体は、コンピュータ２１０２による使用のために、コンピュータ可読命令、データ構造、プログラムモジュール、および他のデータの不揮発性ストレージを提供する。例えば、可読媒体に、オペレーティングシステム２１３０、１つまたは複数のアプリケーションプログラム２１３２（図３に示されたメディアサーバ３０２、コントロールポイント（３１６、３１８）、またはメディアレンダリングデバイス（３０４〜３１２）のいずれかを実装するロジックなど）、他のプログラムモジュール２１３４、およびプログラムデータ２１３６をストアすることができる。
【０２５５】
コンピュータ環境２１００に、様々な入力デバイスを含めることができる。例えば、コンピュータ環境２１００に、コンピュータ２１０２にコマンドおよび情報を入力する、キーボード２１３８およびポインティングデバイス２１４０（例えば、「マウス」）が含まれる。コンピュータ環境２１００に、マイクロホン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、シリアルポート、スキャナ、カード読み取りデバイス、デジタルカメラ、ビデオカメラなどの他の入力デバイス（図示せず）を含めることができる。入出力インターフェース２１４２が、入力デバイスを処理ユニット２１０６に結合する。より一般的には、入力デバイスを、パラレルポート、シリアルポート、ゲームポート、ＵＳＢ（ｕｎｉｖｅｒｓａｌ  ｓｅｒｉａｌ  ｂｕｓ）ポートなど、あらゆる種類のインターフェースおよびバス構造を介してコンピュータ２１０２に結合することができる。
【０２５６】
コンピュータ環境２１００に、ディスプレイデバイス２１０４も含まれる。ビデオアダプタ２１４４が、ディスプレイデバイス２１０４をバス２１１０に結合する。ディスプレイデバイス２１０４の他に、コンピュータ環境２１００に、スピーカ（図示せず）、プリンタ（図示せず）など、他の出力周辺デバイスを含めることができる。
【０２５７】
コンピュータ２１０２は、リモートコンピューティングデバイス２１４６などの１つまたは複数のリモートコンピュータへのロジック接続を使用してネットワーク化された環境で動作する。リモートコンピューティングデバイス２１４６に、汎用パーソナルコンピュータ、ポータブルコンピュータ、サーバ、ルータ、ネットワークコンピュータ、ピアデバイスまたは他の一般的なネットワークノードなどを含むすべての種類のコンピュータ機器を含めることができる。リモートコンピューティングデバイス２１４６に、上でコンピュータ２１０２に関して述べた特徴のすべてまたはそのサブセットを含めることができる。
【０２５８】
ローカルエリアネットワーク（ＬＡＮ）２１４８、または広域ネットワーク（ＷＡＮ）２１５０（インターネットなど）などの任意のタイプのネットワークを使用して、コンピュータ２１０２をリモートコンピューティングデバイス２１４６に結合することができる。ＬＡＮネットワーキング環境で実施される時に、コンピュータ２１０２は、ネットワークインターフェースまたはネットワークアダプタ２１５２を介してローカルネットワーク２１４８に接続される。ＷＡＮネットワーキング環境で実施される時に、コンピュータ２１０２は、モデム２１５４または他の接続戦略を介してＷＡＮ  ２１５０に接続することができる。モデム２１５４は、コンピュータ２１０２の内部または外部に置くことができ、シリアル入出力インターフェース２１５６または他の適当な結合機構を介してバス２１１０に接続することができる。図示されていないが、コンピューティング環境２１００は、リモートコンピューティングデバイス２１４６とコンピュータ２１０２を結合する無線通信機能性を提供することができる（例えば、変調されたラジオ信号、変調された赤外線信号などを介して）。
【０２５９】
ネットワーク化された環境で、コンピュータ２１０２は、リモートメモリストレージ２１５８にストアされたプログラムモジュールから引き出すことができる。一般に、図２１の別個のブロックとしてのプログラムモジュールの表示は、議論を容易にするためのものにすぎない。実際には、プログラムモジュールを、コンピューティング環境２１００にまたがって分散させることができ、この分散は、モジュールが処理ユニット２１０６によって実行される時に動的な形で変更することができる。
【０２６０】
物理的にどこにストアされても、１つまたは複数のメモリモジュール２１０８、２１２２、２１２６、２１５８などは、図３および５に記載のメディアサーバ３０２機能性をストアするために提供することができる。１つの例示的な実施形態で、メディアサーバ３０２によって提供される機能性の諸態様を、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎ社の．ＮＥＴ  Ｆｒａｍｅｗｏｒｋまたは他の仮想マシン環境をターゲットとする管理されたコードで実施することができる。
【０２６１】
本発明を、構造的特徴および／または方法論的動作に固有の言葉で説明したが、請求項で定義される本発明が、必ずしも、説明された特定の特徴または動作に制限されないことを理解されたい。そうではなく、特定の特徴および動作は、請求される発明を実施する例示的な形態として開示されたものである。
【図面の簡単な説明】
【０２６２】
【図１】複数のデバイスおよびコントロールポイントを含む従来のＵＰｎＰアーキテクチャを示す図である。
【図２】図１に示されたＵＰｎＰアーキテクチャによって提供される従来の一連の機能を示す図である。
【図３】リソース共有を含む例示的なネットワークアーキテクチャを示す図である。
【図４】図３に示されたネットワークアーキテクチャの例示的な応用例を示す図である。
【図５】図３に示されたネットワークアーキテクチャで使用される例示的なメディアサーバを示す図である。
【図６】図５のメディアサーバによって使用される例示的なディレクトリを示す図である。
【図７】図４に示された応用例のコンテキストでの、許可されない個人がリソースへのアクセスを得られなくするのに使用される例示的な機構を示す図である。
【図８】図５のメディアサーバによって提示される、異なる例示的なユーザインターフェース（ＵＩ）ページを示す図である。
【図９】図５のメディアサーバによって提示される、異なる例示的なユーザインターフェース（ＵＩ）ページを示す図である。
【図１０】図５のメディアサーバによって提示される、異なる例示的なユーザインターフェース（ＵＩ）ページを示す図である。
【図１１】図５のメディアサーバによって提示される、異なる例示的なユーザインターフェース（ＵＩ）ページを示す図である。
【図１２】図５のメディアサーバによって提示される、異なる例示的なユーザインターフェース（ＵＩ）ページを示す図である。
【図１３】図５のメディアサーバによって提示される、異なる例示的なユーザインターフェース（ＵＩ）ページを示す図である。
【図１４】図５のメディアサーバによって提示される、異なる例示的なユーザインターフェース（ＵＩ）ページを示す図である。
【図１５】図５のメディアサーバによって提示される、異なる例示的なユーザインターフェース（ＵＩ）ページを示す図である。
【図１６】図３のネットワークアーキテクチャで、メディアデバイスをイネーブルし、ディスエーブルし、リソース情報を共有するのに使用される判断基準を定義し、リソース情報を共有する例示的なプロシージャを示す図である。
【図１７】図３のネットワークアーキテクチャで、メディアデバイスをイネーブルし、ディスエーブルし、リソース情報を共有するのに使用される判断基準を定義し、リソース情報を共有する例示的なプロシージャを示す図である。
【図１８】図３のネットワークアーキテクチャで、メディアデバイスをイネーブルし、ディスエーブルし、リソース情報を共有するのに使用される判断基準を定義し、リソース情報を共有する例示的なプロシージャを示す図である。
【図１９】図３のネットワークアーキテクチャで、メディアデバイスをイネーブルし、ディスエーブルし、リソース情報を共有するのに使用される判断基準を定義し、リソース情報を共有する例示的なプロシージャを示す図である。
【図２０】図３のネットワークアーキテクチャで、メディアデバイスをイネーブルし、ディスエーブルし、リソース情報を共有するのに使用される判断基準を定義し、リソース情報を共有する例示的なプロシージャを示す図である。
【図２１】図５のメディアサーバを実施する例示的なコンピュータ環境を示す図である。
【図１】
2007515015.tif 000007
【図２】
2007515015.tif 000008
【図３】
2007515015.tif 000009
【図４】
2007515015.tif 000010
【図５】
2007515015.tif 000011
【図６】
2007515015.tif 000012
【図７】
2007515015.tif 000013
【図８】
2007515015.tif 000014
【図９】
2007515015.tif 000015
【図１０】
2007515015.tif 000016
【図１１】
2007515015.tif 000017
【図１２】
2007515015.tif 000018
【図１３】
2007515015.tif 000019
【図１４】
2007515015.tif 000020
【図１５】
2007515015.tif 000021
【図１６】
2007515015.tif 000022
【図１７】
2007515015.tif 000023
【図１８】
2007515015.tif 000024
【図１９】
2007515015.tif 000025
【図２０】
2007515015.tif 000026
【図２１】
2007515015.tif 000027
【国際調査報告】
2007515015.tif 000028