(57)【要約】【課題】ユニバーサル・プラグ・アンド・プレー（ＵＰｎＰ）デバイスが、ＵＰｎＰ発見コンテンツ項目をサーバー・メッセージ・ブロック（ＳＭＢ）所在地にマッピングするサービスを露出する構成を提供する。【解決手段】サービスは、リモート・クライアントにおいてＵＰｎＰプロトコルを用いるユーザーに、ＳＭＢシェア経路を露出するように構成されている。次いで、ユーザーは、ＳＭＢを通じてシェアにアクセスしてファイル・アクセスを得ること、変更を書き込むこと、または発見コンテンツ項目のファイル・レベル制御を施行することが可能となる。任意に、認証を利用して、ユーザーがＳＭＢシェア所在地をサービスから受けることを許可されていることを検証する、またはユーザーがＳＭＢシェアにアクセスすることを許可されていることを検証する。【選択図】図１
2009545089.tif 000002
【特許請求の範囲】
【請求項１】
コンピューター読み取り可能媒体であって、電子デバイス上において１つ以上のプロセッサによって実行すると、メディア・サーバー（２０５）を実装し、該メディア・サーバー（２０５）が、
前記メディア・サーバー（２０５）からクライアント（２１２）に利用可能なＵＰｎＰサービスを特定するように構成されたＵＰｎＰデバイス（２２２）と、
前記クライアント（２１２）からの発見要求（３０３）に応答して、前記ＵＰｎＰデバイス（２２２）によって露出されるコンテンツ・ディレクトリ・サービス（２４０）と、
を備えており、
これによって、前記コンテンツ・ディレクトリ・サービス（２４０）が、前記クライアント（２１２）からのコマンドに応答して、ＵＰｎＰネットワーク（２６０）を通じて１つ以上のＳＭＢ経路を前記クライアント（２１２）に露出する、コンピューター読み取り可能媒体。
【請求項２】
請求項１記載のコンピューター読み取り可能媒体において、前記コンテンツ・ディレクトリ・サービス（２４０）は、ＵＰｎＰプロトコルにおいて定められたコンテンツ・ディレクトリ・サービスである、コンピューター読み取り可能媒体。
【請求項３】
請求項１記載のコンピューター読み取り可能媒体において、前記コンテンツ・ディレクトリ・サービス（２４０）は、ＵＰｎＰプロトコルにおいて定められたコンテンツ・ディレクトリ・サービスであり、更に、ＨＴＴＰまたはＲＴＳＰのうち一方を用いてアクセス可能なＵＲＬに加えて、前記１つ以上のＳＭＢ経路を露出するように構成された、コンピューター読み取り可能媒体。
【請求項４】
請求項１記載のコンピューター読み取り可能媒体において、前記クライアント（２１２）に応答して、１つ以上の<res>タグ（５０５）を用いて、前記１つ以上のＳＭＢ経路を露出する、コンピューター読み取り可能媒体。
【請求項５】
請求項１記載のコンピューター読み取り可能媒体において、前記１つ以上の<res>タグ（５０５）は、ＸＭＬ文書（４１８）内に配された、コンピューター読み取り可能媒体。
【請求項６】
請求項１記載のコンピューター読み取り可能媒体において、前記コマンドは、ブラウズ・コマンドまたは検索コマンド（４１３）を含む、コンピューター読み取り可能媒体。
【請求項７】
請求項１記載のコンピューター読み取り可能媒体において、前記コンテンツ・ディレクトリ・サービス（２４０）は、前記クライアント（２１２）が認証済みクライアントである場合にのみ、前記１つ以上のＳＭＢ経路を前記クライアント（２１２）に露出する、コンピューター読み取り可能媒体。
【請求項８】
請求項７記載のコンピューター読み取り可能媒体において、前記コンテンツ・ディレクトリ・サービス（２４０）は、Negotiate、Kerberos、またはＮＴＬＭの１つから選択した認証方法を用いて、前記クライアント（２１２）を認証する方法を呼び出す、コンピューター読み取り可能媒体。
【請求項９】
請求項８記載のコンピューター読み取り可能媒体において、前記認証方法は、前記電子デバイス上で走るオペレーティング・システムによって実質的に実行する、コンピューター読み取り可能媒体。
【請求項１０】
ＵＰｎＰネットワーク（２６０）を通じてファイル所在地をリモート・クライアント（２１２）に提供する方法であって、
ＵＰｎＰデバイス記述を前記リモート・クライアント（２１２）に供給することによって、前記リモート・クライアント（２１２）に利用可能なＵＰｎＰサービスを特定するステップと、
コンテンツ・レポジトリ（８００）内に配置された発見可能オブジェクトをＳＭＢシェア所在地にマッピングするステップと、
前記リモート・クライアント（２１２）から前記特定したＵＰｎＰサービスへのブラウズ・コマンドまたは検索コマンド（４１３）に応答して、前記ＳＭＢシェア所在地を露出するステップと、
を備えた、方法。
【請求項１１】
請求項１０記載の方法において、ユーザーまたはファイルによって最適化したＳＭＢ所在地を特定するために、マッピングを実行する、方法。
【請求項１２】
請求項１１記載の方法において、前記最適化ＳＭＢ所在地は、ユーザーによってアクセス可能な最も直接的に利用可能なＳＭＢ経路を含む、方法。
【請求項１３】
請求項１１記載の方法において、前記最適化ＳＭＢ所在地の特定は、前記リモート・クライアント（７２１）の証明書を用いて、前記リモート・クライアントを擬人化することを含む、方法。
【請求項１４】
請求項１１記載の方法であって、前記ファイル（７２６）までの最も直接的なＳＭＢ経路を要求するシェルＡＰＩをコールする更なるステップを含む、方法。
【請求項１５】
請求項１４記載の方法であって、前記リモート・クライアント（７３１）に応答して、前記シェルＡＰＩによって戻された経路を含ませる更なるステップを含む、方法。
【請求項１６】
請求項９記載の方法において、前記発見可能なオブジェクトは、音楽、ビデオ、画像、ゲーム、ニュース、またはデータのうち１つから選択したメディア・コンテンツ・データの１つ以上の離散断片を含む、方法。
【請求項１７】
ＵＰｎＰネットワーク（２６０）を通じてメディア・サーバー（２６０）と通信するように構成されたクライアント・デバイス（２１２）であって、
前記クライアント・デバイス（２１２）がコンテンツ・ディレクトリ・サービス（２４０）と通信することを可能にするように構成された制御点（２５１）と、
リモート・サーバー上のＳＭＢ経路にアクセスするように構成されたＳＭＢクライアント（２３５）であって、前記制御点（２５１）に露出されたメディア・サーバー（２０５）上で動作するサービスによって、前記ＳＭＢ経路を提供する、ＳＭＢクライアントと、
前記ＳＭＢクライアント（２３５）によって前記ＳＭＢ経路からアクセスしたコンテンツをレンダリングするメディア・レンダラー（２２８）と、
を備えた、クライアント・デバイス。
【請求項１８】
請求項１７記載のクライアント・デバイス（２１２）において、前記クライアント・デバイス（２１２）は、ＳＳＤＰまたはＳＯＡＰメッセージを用いて、前記コンテンツ・ディレクトリ・サービス（２４０）と通信する、クライアント・デバイス（２１２）。
【請求項１９】
請求項１７記載のクライアント・デバイス（２１２）において、前記ＳＭＢクライアント（２３５）は、前記ＳＭＢ経路において特定したコンテンツの書き込み変更またはファイル・レベル制御を実行するように構成された、クライアント・デバイス。
【請求項２０】
請求項１７記載のクライアント・デバイス（２１２）において、前記ＳＭＢクライアント（２３５）は、前記サービスから前記ＳＭＢ経路を入手する必要条件として、前記メディア・サーバー（２０５）との認証プロセスに加わるように構成された、クライアント・デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
デバイス・レベルでのプラグ・アンド・プレー（ＰｎＰ）能力の追加により、周辺機器を消費者用電子デバイスおよびパーソナル・コンピューターに設定し、構成し、追加することが非常に容易になった。ユニバーサル・プラグ・アンド・プレー（ＵＰｎＰ（商標）は、この簡素さをネ拡張してネットワーク全体を含むようにし、ネットワーク取付プリンター、インターネット・ゲートウェイ、および消費者電子機器のような、ネットワーク接続デバイスおよびサービスの発見および制御を可能にする。ＵＰｎＰネットワーキング・プロトコルは、ＵＰｎＰフォーラムによって公表されている。ＵＰｎＰフォーラムは、多くの異なる販売業者からのスタンド・アロン・デバイスやＰＣ間における簡単でロバストは接続性を可能にするために設計された業界の創意である。
【０００２】
ＵＰｎＰは、プラグ・アンド・プレー周辺モデルの単なる拡張を超えるものである。これは、広範囲の販売業者からのある広さのデバイス別に対する、ゼロ・コンフィギュレーション、「不可視」ネットワーク、および自動発見をサポートするように設計されている。ＵＰｎＰを用いると、デバイスは動的にネットワークに加入し、ＩＰ（インターネット・プロトコル）アドレスを入手し、その能力を伝達し、他のデバイスの存在および能力について学習することができ、全てが自動的に行われることによって、ゼロ・コンフィギュレーション・ネットワークの構築を容易にする。その後、デバイスは、コンテンツにアクセスし共有するためにピア・ツー・ピア・ネットワーキングを用いれば、互いに直接通信することができる。
【０００３】
ＵＰｎＰ対応ネットワークから便益を得ることができる種々のデバイスは、広範に及び(large)、例えば、全ての形状係数(form factor)のインテリジェント器具、ワイヤレス・デバイス、およびＰＣが含まれる。ＵＰｎＰの範囲は、とりわけ、家庭用自動化およびネットワーキング、印刷および撮像、オーディオ／ビデオ娯楽、台所器具、自動車ネットワーク、ならびに移動体デバイス・ネットワークのような分野において既存の用途および新しい用途の多くを包含する程に広い。
【０００４】
ＵＰｎＰは、分散型オープン・ネットワーク・アーキテクチャであり、いずれの特定のオペレーティング・システム、プログラミング言語、物理的媒体にも独立している。しかしながら、ＵＰｎＰは、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネット・プロトコル）、ＨＴＴＰ（ハイパーテキスト転送プロトコル）、ＸＭＬ（拡張可能マークアップ言語）のような標準プロトコルを用いており、既存のネットワークに継ぎ目無く入り込むことができる。このような標準化されたプロトコルを用いることによって、ＵＰｎＰは相互動作可能性の便益を固有の特徴のように得ることが可能になる。
【０００５】
ＵＰｎＰは、コンテンツ・ディレクトリ・サービスを用いており、機能の集合を実装して、ローカルＵＰｎＰデバイス上にあるコンテンツ・レポジトリに格納されているコンテンツ項目（例えば、データ・ファイル、音楽、ソフトウェア、写真、ビデオ、ゲーム等）へのアクセスをＵＰｎＰネットワーク上にあるリモートＵＰｎＰデバイスに提供する。コンテンツ・ディレクトリ・サービスの機能は、レポジトリにおけるコンテンツ項目のブラウジングおよび検索を可能にすることである。コンテンツ・ディレクトリ・サービスにおいて参照された各コンテンツ項目は、コンテンツに関する種々の情報を含み、ローカル・デバイスがコンテンツ項目をリモート・デバイスに転送するために用いることができる転送プロトコルおよびファイル・フォーマットが含まれる。全てのＵＰｎＰサービスに関して、リモート・デバイスは、ＨＴＴＰを用いる単純オブジェクト抽象化プロトコル（ＳＯＡＰ：Simple Object Abstraction Protocol）を用いて、コンテンツ・ディレクトリ・サービスと相互作用を行う。
【０００６】
所望のコンテンツ項目を特定した後、例えば、ＸＭＬ文書におけるリソース即ち<res>タグを用いて、リモート・デバイスはコンテンツ・ディレクトリ・サービスからの転送プロトコル情報を用いて、それをリモート・デバイスにおけるメディア・プレーヤの能力と照合する。共通転送プロトコルは、例えば、ＨＴＴＰ  ＧＥＴおよびＲＴＳＰ／ＲＴＰ（リアル・タイム・ストリーミング・プロトコル、リアル・タイム・トランスポート・プロトコル）を含む。次いで、転送されたコンテンツは、別のＵＰｎＰサービス（ＡＶトランスポート制御サービス）または非ＵＰｎＰ帯域外プロトコルを用いて、リモート・デバイスによって引き渡され(render)、コンテンツのフロー（例えば、停止、早送り、巻き戻し、一時停止等）を制御する。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ＵＰｎＰは多くのネットワーキング用途において非常に満足できる動作を行うが、現在の実現例では、ＵＰｎＰデバイスのユーザーに、ネットワークに接続されている他のＵＰｎＰデバイス上で発見されたコンテンツ項目へのファイル・アクセスを提供しない。即ち、ユーザーは制限されており、コンテンツ・項目があることを知り、読み取り専用の消費を要求することができるに過ぎない。既存のＵＰｎＰ環境には、発見したコンテンツ項目に対する書き込み変更や、ファイル・レベルでのコンテンツ項目の制御を実施することはできない。
【課題を解決するための手段】
【０００８】
ＵＰｎＰデバイスが、ＵＰｎＰ発見コンテンツ項目をサーバー・メッセージ・ブロック（ＳＭＢ）所在地にマッピングするサービスを露出する構成を提供する。サービスは、ＳＭＢ共有経路を、ＵＰｎＰプロトコルを用いてリモート・コンテンツにおいて要求するユーザーに露出するように構成されている。次いで、ユーザーには、ＳＭＢプロトコルを通じてシェア(share)へのアクセスが可能となり、発見したコンテンツ項目のファイル・アクセスを得ること、書き込みを変更すること、またはファイル・レベルの制御を施行することができる。任意に、認証を利用して、ユーザーがＳＭＢシェア所在地をサービスから受信することを許可されていることを確認するか、またはユーザーがＳＭＢシェアにアクセスすることを許可されていることを確認する。
【０００９】
種々の例示的な例では、コンテンツ項目を個々のユーザーおよびファイルに対して最も直接的に利用可能なＳＭＢ所在地にマッピングする。既存のＵＰｎＰサービスを拡張するか、または新しいＵＰｎＰサービスを利用し、要求側ユーザーに対するＸＭＬフォーマット化した応答に含まれる追加の<res>タグの使用によって、ＵＰｎＰブラウザーまたは検索コマンドに応答して、ＳＭＢ所在地を要求側ユーザーに露出する。
【００１０】
本構成の利点は、ユーザーおよびデバイスが、ＵＰｎＰネットワーク上で発見したコンテンツ項目に対するアクセスおよび制御を拡大できることである。
【図面の簡単な説明】
【００１１】
【図１】図１は、ＵＰｎＰを利用するように構成されている例示ホーム・ネットワークの図式表現である。
【図２】図２は、例示のサーバーおよびクライアント・アーキテクチャのブロック図である。
【図３】図３は、コンテンツ・ディレクトリ・サービスと制御点との間における例示のメッセージ・フローを示す図である。
【図４】図４は、コンテンツ・ディレクトリ・サービスと制御点との間における別の例示のメッセージ・フローを示す図である。
【図５】図５は、ＳＭＢ経路を含む<res>タグを含む例示のＸＭＬ文書である。
【図６】図６は、コンテンツ・ディレクトリ・サービスを要求側ユーザーに提供する例示の方法のフローチャートである。
【図７】図７は、ＳＢＭシェア所在地を特定し、要求側ユーザーに露出する例示の方法のフローチャートである。
【図８】図８は、内部に収納したディレクトリ構造を示す例示のコンテンツ・レポジトリのブロック図である。
【図９】図９は、ＳＭＢサーバーとＳＭＢクライアントとの間における例示のメッセージ・フローを示す図である。
【発明を実施するための形態】
【００１２】
図面に移ると、同様の参照番号は同様のコンポーネントまたはエレメントを示し、図１は、種々のデバイスがホーム・ネットワーク１０２に結合されている例示の家庭１００の図式表現である。家庭１００の小部屋１０５には、ＰＣ１１０が家族の写真を格納している。第２ＰＣ１１６が居間１２８に置かれており、大型画面のテレビジョン１２８に結合されている。ゲーム・コンソール１３２が寝室１３６に置かれている。ＰＣ１１０、ＰＣ１１６、およびゲーム・コンソール１３２は、各々、ホーム・ネットワーク１０２に結合されている。この図示の例では、ホーム・ネットワーク１０２は、ＵＰｎＰネットワークとして構成されている。ＵＰｎＰネットワークは、例えば、電話線、電力線、イーサネット（登録商標）、ワイヤレスＲＦ（無線周波数）、およびＩＥＥＥ１３９４（電気電子技術者学会）を含む種々のネットワーク媒体を用いて構成することができる。
【００１３】
ＵＰｎＰ発見項目をＳＭＢ所在地にマッピングする本構成を用いると、家族は居間１２３に集まって、ＰＣ１１０上に格納されている写真を大型画面テレビジョン１２８上で見ることができる。ＰＣ１１６を用いると、家族は居間１２３から写真に格付けを行い、これらを回転させ、更に写真の名称変更も行うことができる。これらの能力は、ＵＰｎＰおよびＨＴＴＰの目視特性を用いつつ、本構成にしたがってファイル動作をＳＭＢ上において追加することによって可能となる。例示の家族写真は、ＰＣ１１０上に格納されており、図１に示すように、ＰＣ１１０に結合されているモニター上に画像１５０Ａとして送り込まれ、大型画面テレビジョン１２８上では画像１５０Ｂとして送り込まれ、ゲーム・コンソール１３２に結合されているモニター上では画像１５０Ｃとして送り込まれる。
【００１４】
ＳＭＢは、ＯＳＩ（オープン・システム相互接続）ネットワーキング・モデル内のアプリケーション／プレゼンテーション・レイヤにおけるネットワーク・ファイル共有プロトコルである。したがって、ＳＭＢは、例えば、ＴＰＣ／ＩＰ上のＮｅｔＢＩＯＳ（ネットワーク基本入力／出力システム）、ＮｅｔＢＥＵＩ（ＮｅｔＢｉｏｓ拡張ユーザー・インターフェース）、またはＩＰＸ／ＳＰＸ（インターネットワーク・パケット交換／シーケンス状パケット交換）を含む多数の下位レイヤ・プロトコル上で走ることができる。
【００１５】
ＳＭＢプロトコルの特定バージョンを定義するメッセージ・パケットの集合をダイアレクト(dialect)と呼ぶ。例えば、ＣＩＦＳ（共通インターネット・ファイル・システム）は、Microsoft Windows NTオペレーティング・システムにおいて最初に実装されたＳＭＢダイアレクトを指す。ＳＭＢおよびＣＩＦＳは、ＶＭＳ（仮想メモリ・システム）、Ｕｎｉｘの様々なバージョン、およびその他のオペレーティング・システム上でも利用可能である。ＳＭＢのダイアレクトは、ＣＩＦＳも含んで全て、本構成において用いることができ、特定のＳＭＢバージョンまたはダイアレクトの選択は、ＵＰｎＰ発見コンテンツをマッピングする用途の特定的な要件によって異なる。「ＳＭＢ」という用語は、ここで用いる場合、このようなＳＭＢバーションまたはダイアレクト全てに該当することを意図している。
【００１６】
図２は、例示のサーバーおよびクライアント・アーキテクチャ２００のブロック図であり、サーバー・デバイス２０５およびクライアント・デバイス２１２を含む。これらの各々は、通例、ＰＣ、ゲーム・コンソール等のような物理的デバイスまたはユニットとして構成(configure)されている。例えば、サーバー・デバイス２０５は、ＰＣ１１０（図１）に具体化して、家族写真、音楽、ゲーム、データ、ファイル等のような、そこに格納されているコンテンツ項目を共有することができる。同様に、クライアント・デバイス２１２は、ＰＣ１１６（図１）またはゲーム・コンソール１３２（図１）に具体化して、サーバー・デバイス２０５からコンテンツ項目を受信することができる。
【００１７】
サーバー・デバイス２０５およびクライアント・デバイス２１２には、それぞれ、メディアサーバー(MediaServer)ＵＰｎＰデバイス２２２およびメディアレンダラー(MediaRenderer)ＵＰｎＰデバイス２２８が設けられている。ＵＰｎＰデバイスは、論理デバイスであり、個々の物理的設定を反映する必要はない。即ち、物理的デバイスは数個の論理的ＵＰｎＰデバイスをホストすることができ、選択された特定の数のＵＰｎＰデバイスおよびそれらの構成は、ＵＰｎＰ発見項目のマッピングの個々の用途の要件に応じて異なる。メディアサーバーＵＰｎＰデバイス２２２に加えて、サーバー・デバイス２０５はＳＭＢサーバー２３１も含む。ＳＭＢサーバー２３１は、線２３８で示すようなネットワークを通じて、クライアント・デバイス２１２におけるＳＭＢクライアント２３５と通信するように構成されている。
【００１８】
メディアサーバーＵＰｎＰデバイス２２２は、コンテンツ・ディレクトリ・サービス２４０を含む。これは、通例、以下に記載する追加機能性で拡張されているＵＰｎＰフォーラムが公表した定義に準拠したコンテンツ・ディレクトリ・サービスとして構成されている。あるいは、コンテンツ・ディレクトリ・サービス２４０は、要求側クライアントが既存のＵＰｎＰプロトコルを用いてアクセスする、新たなサービス（例えば、「SecureContentDirectoryService」と命名する）として構成する。
【００１９】
メディアレンダラーＵＰｎＰデバイス２２８は、制御点２５１を含む。この例示の例では、制御点２５１は、ＵＰｎＰ制御点であり、メディアレンダラーＵＰｎＰデバイス２２８に埋め込まれている。メディアレンダラーＵＰｎＰデバイス２２８は、サービス上でアクションを呼び出しつつ、要求されたあらゆる入力パラメーターを供給し、あらゆる出力パラメーター、サービス応答、および戻り値を受信する。メディアレンダラーＵＰｎＰデバイス２２８は、通例、ＵＰｎＰフォーラムが公表した定義に準拠して、サーバー・デバイス２０５から受信するコンテンツ項目をレンダリングする能力を有するクライアント・デバイス２１２をインスタンス化するメディアレンダラーとして構成されている。メディアレンダラーＵＰｎＰ２２８は、レンダリング制御の集合を露出するように構成されるのが極普通であり、この場合、制御点２５１は、個々のコンテンツ項目をどのようにレンダリングするかを制御することができる。ＵＰｎＰ発見項目をＳＭＢ所在地にマッピングする代替構成では、メディアレンダラーＵＰｎＰデバイス２２８は、任意に、サーバー・デバイス２０５およびクライアント・デバイス２１２が非ＵＰｎＰ（即ち、帯域外）通信プロトコルを用いて互いに相互作用を行う場合にも利用される。例えば、Windows Media PlayerおよびRoku（商標）SoundBridgeを用いて、コンテンツ項目をレンダリングすることができる。
【００２０】
サーバー−クライアント・アーキテクチャ２００では、制御点２５１は、図２に示すように、線２６０で示すＵＰｎＰネットワークを通じてコンテンツ・ディレクトリ・サービス２４０にアクセスする。
【００２１】
図３は、コンテンツ・ディレクトリ・サービス２４０と制御点２５１との間における例示のメッセージ・フローを示す図である。制御点２５１は、ＳＳＤＰ（簡易サービス発見プロトコル）を用いて、発見メッセージ３０３、通例、Ｍ−検索コマンドを送ることによって、ホーム・ネットワーク１０２（図１）のようなＵＰｎＰネットワーク上にある他のデバイスを発見するために用いられる。コンテンツ・ディレクトリ・サービス２４０は、ＸＭＬフォーマット化したデバイス記述文書のＵＲＩ（ユニフォーム・リソース識別子）を収容するＳＳＤＰメッセージを用いて、Ｍ−検索コマンドに応答する。一方、デバイス記述文書は、利用可能なサービス毎にＸＭＬサービス記述文書３０６の所在地を収容する。制御点２５１は、例えば、ＨＴＴＰによってサービス記述文書３０６をダウンロードすることができる。このため、メディアサーバーＵＰｎＰデバイス２２２は、コンテンツ・ディレクトリ・サービス２４０を制御点２５１に露出することができる。
【００２２】
図４は、コンテンツ発見サービス２４０と制御点２５１との間における他の例示のメッセージ・フローを示す図である。制御点２５１は、Windows Negotiate、Kerberos、NTLM等のような認証プロトコルを用いて、コンテンツ・ディレクトリ・サービス２４０に接続する。いずれの認証プロセスの使用も任意である（図４において破線４０６で示す通りである）。コンテンツ・ディレクトリ・サービス２４０と制御点２５１との間における認証交渉に成功した場合、制御点２５１は、ＨＴＴＰによるＳＯＡＰメッセージ４１３を用いて、検索またはブラウズ・コマンドをコンテンツ・ディレクトリ・サービス２４０に発行することができる。コンテンツ・ディレクトリ・サービス２４０は、ＸＭＬ文書４１８を用いて検索またはブラウズ・コマンドに応答して、ＳＭＢ所在地にマッピングされる発見コンテンツ項目について、通例エントリの中でもとりわけ<res>タグ・エントリを露出する。このマッピングについては、図６から図８に付随する文章において以下で説明する。
【００２３】
図５は、ＳＭＢ経路を含む<res>タグ５０５を含む例示のＸＭＬ文書４１８を示す。ＳＭＢ経路は、<res>タグ５０５において、
【表１】
2009545089.tif 000003
として示されている。これは、この例示の例では、ＩＰアドレスが10.194.65.100である、図１のＰＣ１１０上にある「Toby」という名称を付けられたシェアの中に位置するウィンドウズ（登録商標）・メディア・オーディオ（ＷＭＡ）ファイルを示す。ＷＭＡファイルは、Johnny Cowboyが演奏する「My Horse Named Blue」と題するソング（ソングおよび演奏者双方共架空である）のためのファイルである。写真（例えば、ファイル拡張子が.JPGまたは.JPEGである、Joint Photographic Experts Group即ちＪＰＥＧフォーマットの画像）またはビデオ（例えば、Windows Media Video、RealVideo、Apple QuickTime等のフォーマットのビデオであり、.wmv、.rmまたは.ram、および.movという拡張子をそれぞれ有する）のようなその他の形式のファイルに対するＳＭＢ経路は、同様に１つ以上の<res>タグに含めることもできる。
【００２４】
また、ＸＭＬ文書４１８は<res>タグ５１０も含む。<res>タグ５１０は、例えば、既存のＵＰｎＰメディアサーバー・デバイスが供給するように、ＨＴＴＰ  ＧＥＴを用いてアクセスするＷＭＡファイルに対するＵＲＬを特定する。このＵＲＬは、<res>タグ５１０において、
【表２】
2009545089.tif 000004
として示されている。これは、この例示の例では、慣例的に用いられている、抽象化経路／命名規則を用いた、前述のＷＭＡ音楽ファイルと同一である。
【００２５】
図６は、ＵＰｎＰデバイス（図２におけるメディアサーバーＵＰｎＰデバイス２２２等）がそのコンテンツ項目を要求側ユーザーにコンテンツ・ディレクトリ・サービス（図２におけるコンテンツ・ディレクトリ・サービス２４０等）を通じて露出する例示の方法６００のフローチャートである。要求側ユーザーは、通例、図２におけるメディアレンダラーＵＰｎＰデバイス２２８を含むクライアント・デバイス２１２のような、離れて位置する電子デバイスのユーザーである。図示の方法６００は、ブロック６０５において開始する。ブロック６１２において、対象のＵＰｎＰデバイスを検索するためにＭ−検索コマンドのような発見メッセージを制御点２５１（図２）から送り、メディアサーバーＵＰｎＰデバイス２２２において受信する。メディアサーバーＵＰｎＰデバイス２２２は、発見メッセージに応答することによって、メディアサーバーＵＰｎＰデバイス２２２およびコンテンツ・ディレクトリ・サービス２４０をクライアント・デバイス２１２が発見することが可能となる。これは、ブロック６１５に示す通りである。ブロック６１８において、コンテンツ・ディレクトリ・サービス２４０は、コンテンツ項目を要求側ユーザーに露出して、格納されているコンテンツの種々のビューを提供することによって、そこで利用可能なコンテンツ項目の検索およびブラウジングを可能にする。コンテンツの詳細記述を用いて、検索クエリがコンテンツ項目の集合を返すことができる。加えて、コンテナを通じてコンテンツの編成をサポートする。コンテナは、ディレクトリまたはフォルダーと同様に、コンテンツをクラスタ化するために用いることができる。例示の方法６００は、ブロック６２７において終了する。
【００２６】
図７は、前述の方法６００（図６）において提供するコンテンツ・ディレクトリ・サービスを用いて、ＳＭＢシェア所在地を特定し、要求側ユーザーに露出する。先に記したセキュアコンテンツディレクトリ・サービスは、方法７００を実行するために使用可能である。あるいは、既存のＵＰｎＰコンテンツ・ディレクトリ・サービスを拡張して、図７に示すステップを実行してもよい。
【００２７】
例示の方法はブロック７０２において開始する。ブロック７１１において、コンテンツ・ディレクトリ・サービスは検索またはブラウズ・コマンドを要求側ユーザーから受信する。ブロック７１５において、任意の認証ステップを実行する。認証プロトコルは、殆どの用途では、Windows Negotiate、Kerberos、ＮＴＬＭ等の１つから選択する。
【００２８】
コンテンツ・ディレクトリ・サービスは、ブロック７１１において示した方法ステップにおける検索またはブラウズ・コマンドの中で要求されたコンテンツ項目を最良のＳＭＢ経路にマッピングするように作動する。「最良」とは、一般に、特定の要求側ユーザーがアクセスすることができる最も直接的なＳＭＢ経路を意味する。
【００２９】
最良のＳＭＢ経路の概念を、更に図８に示す。これは、内部に収容したディレクトリ構造８１１を示す例示のコンテンツ・レポジトリ８００のブロック図である。コンテンツ・レポジトリ８００は、通例、図１におけるＰＣ１１０のようなデバイスにおけるハード・ディスク・ドライブのようなメモリとして具体化する。図８に示すように、ディレクトリ構造８１１は、３つのシェア８１５、８２２、および８２５を含む。この例示の例では、ＰＣ１１０には３人のユーザー、アドミン、ダッド、およびトビイがいる。つまり、
【表３】
2009545089.tif 000005
にあるファイルにアクセスしたいリモート・ユーザーには、それぞれのシェア８１５、８２２および８２５の各々を通じてファイルにアクセスする方法が、潜在的に３通りある。アドミンはシェア８１５、８２２、および８２５の各々にアクセスし、ダッドはホーム・シェア８２２およびトビイ・シェア８２５の双方にアクセスする。したがって、露出すべき最良のＳＭＢ経路を特定するには、要求の中に収容されているファイルおよび要求側ユーザーの証明書に基づいて、ＵＮＣ（全世界／均一命名規則）経路を決定する。
【００３０】
トビイがトビイ・シェアにおけるファイルを要求する場合、露出すべき唯一利用可能で最良のＵＮＣ経路は、
【表４】
2009545089.tif 000006
となる。
【００３１】
ダッドが同じファイルへのアクセスを望む場合、ダッドのアクセス・レベルに基づいて２つの選択肢がある。
【表５】
2009545089.tif 000007
この例では、選択肢Ａが最も直接的な経路を表すので、これが最良の選択肢となる。メディア・サーバー・サービスは、これに応じて、ダッドが要求側ユーザーである場合、
【表６】
2009545089.tif 000008
を最良のＳＭＢ経路として選択する。
【００３２】
アドミンがアクセスを要求している場合、３つの選択肢がある。
【表７】
2009545089.tif 000009
この例でも、選択肢Ａが再度最も直接的な経路を表すので、これが再度最良の選択肢となる。メディア・サーバー・サービスは、これに応じて、アドミンが要求側ユーザーである場合、
【表８】
2009545089.tif 000010
を最良のＳＭＢ経路として選択する。
【００３３】
図７に戻って、メディア・サーバー・サービスは、ブロック７２１において、要求側ユーザーの証明書を用いて、要求側ユーザーを擬人化する。ブロック７２６において、メディア・サーバー・サービスは、要求されたファイルまでのローカル経路を用い、擬人化した要求側ユーザーとして行動することによって、シェルＡＰＩ（アプリケーション・プログラミング・インターフェース）をコールして、要求されたファイルまでの最良のＳＭＢ経路を要求する。シェルＡＰＩがあるＳＭＢ経路を返した場合、メディア・サーバー・サービスは、要求側ユーザーの検索またはブラウズ・コマンドに対するＸＭＬ応答に含まれる<res>タグに、この経路を含ませる。これは、ブロック７３１に示す通りである。例示の方法７００は、ブロック７４０において終了する。
【００３４】
これより図９に移ると、ＳＭＢサーバー２３１（図２）とＳＭＢクライアント２３５（図２）との間における例示のメッセージ・フローを示す図が呈示されている。例示のメッセージは、パケットを備えている。前述のようにメディア・サーバー・サービスがＳＭＢ経路を要求側ユーザーに露出した後に、ＳＭＢプロトコルを用いて、ＳＭＢサーバー２３１とＳＭＢクライアント２３５との間でパケットを交換する。
【００３５】
この例示の例では、ＳＭＢクライアント２３５およびＳＭＢサーバー２３１は、最初に、全二重ＴＣＰ接続を確立する。次いで、ＳＭＢクライアント２３５はＮｅｔＢＩＯＳセッション要求パケットを組立、ＴＣＰ接続を通じて送る。パケットが正しくフォーマットされていた場合、ＳＭＢサーバー２３１は、セッションを確立したことを認めるメッセージを収容したパケットを返送する。この後、ＳＭＢクライアント２３５は、プロトコル交渉メッセージ９０５をＳＭＢサーバー２３１に送り、セッションに用いる特定のＳＭＢダイアレクトを交渉する。
【００３６】
ＳＭＢサーバー２３１は、ＳＭＢクライアント２３５からの要求に応答して、セッションにおいて用いようとするＳＭＢダイアレクトを特定する。また、返送されたメッセージ９１２は、８バイト・ランダム・ストリングも含む。これは、任意の共有鍵認証プロセスの一部として、チャレンジ(challenge)として用いられる。ＳＭＢクライアント２３５は、メッセージ９１６においてチャレンジに対する応答を返送する。メッセージ９１６は、ＳＭＢクライアント２３５の能力に関する情報を含む。先に記したように、認証は、図９において破線で示す、任意のプロセスである。
【００３７】
ＳＭＢサーバー２３１がＳＭＢクライアント２３５からチャレンジに対する応答を受け入れると、有効なＵＩＤ（ユーザーＩＤ）をメッセージ９１８に含めて、ＳＭＢクライアント２３５に返送する。受け入れられない場合、ＳＭＢサーバー２３１はこのメッセージにおいてエラー・コードを返送し、アクセスを拒否する。
【００３８】
ＳＭＢクライアント２３５は、次に、前述のようにメディア・サーバー・サービスによって露出された<res>タグに収容されているＳＭＢシェアへのアクセスを要求する。アクセス要求メッセージ９２２は、ＵＮＣフォーマットで完全に指定されたシェアの経路を収容する。
【００３９】
シェアへのアクセスが付与された場合、ＳＭＢサーバー２３１は、メッセージ９２７においてシェアに対応する１６ビット・ツリーＩＤ（ＴＩＤ）を返送する。シェアが存在しない場合、またはユーザーがシェアにアクセスするには不十分な証明書を有する場合、サーバーはメッセージ９２７においてエラー・コードを返送し、シェアへのアクセスを拒否する。
【００４０】
ＳＭＢクライアント２３５は、メッセージ９３１において、アクセスしたシェア上にあるファイルを開くように、ＳＭＢサーバーに要求する。このメッセージは、開こうとするファイルの名称を収容している。例えば、再度図５を参照すると、開こうとするファイルの名称は、JC-ahosenamedblue.wmaとなっている。
【００４１】
図９に戻って、ファイルへのアクセスが付与されると、ＳＭＢサーバー２３１は、メッセージ９３５において、要求されたファイルのファイルＩＤを返送する。ファイルが存在しない場合、またはユーザーがファイルにアクセスするには十分な証明書を有していない場合、ＳＭＢサーバーはメッセージ９３５においてエラー・コードを返送し、ファイルへのアクセスを拒否する。
【００４２】
ＳＭＢクライアント２３５は、様々にファイルを開き、開いたファイルからデータを読み取りそしてこのデータをＳＭＢクライアント２３５に返送し、ファイルに書き込み、そしてファイルを閉じるように、ＳＭＢサーバー２３１にメッセージ９４２において要求する。名称変更、削除などを含むその他のファイル動作も、メッセージ９４２によって取り込むことができる。ファイルを開いたときにクライアントが入手するファイルＩＤは、どのファイルを開いて、ＳＭＢサーバー２３１が要求動作を実行すべきかを特定するために、このメッセージに含まれる。メッセージ９４２に対するしかるべき応答が、ＳＭＢサーバー２３１からＳＭＢクライアント２３５へのメッセージ９４８に収容されている。
【００４３】
以上、ＵＰｎＰ発見項目をＳＭＢ所在地にマッピングする種々の例示の構成および方法を示し説明したが、添付する特許請求の範囲は必ずしも記載した具体的な特徴、構成、または方法のいずれにも限定されるのではないことは理解されてしかるべきである。逆に、具体的な特徴、構成、または方法は、以下で更に特定的に特許請求するが、ＵＰｎＰ発見項目をＳＭＢ所在地にマッピングする例示の形態として開示したのである。
【図１】
2009545089.tif 000011
【図２】
2009545089.tif 000012
【図３】
2009545089.tif 000013
【図４】
2009545089.tif 000014
【図５】
2009545089.tif 000015
【図６】
2009545089.tif 000016
【図７】
2009545089.tif 000017
【図８】
2009545089.tif 000018
【図９】
2009545089.tif 000019
【国際調査報告】
2009545089.tif 000020
2009545089.tif 000021
2009545089.tif 000022