JP5048064B2 - ユニバーサル・プラグ・アンド・プレー発見項目のｓｍｂ位置に対するマッピング - Google Patents

Description

デバイス・レベルでのプラグ・アンド・プレー（ＰｎＰ）能力の追加により、周辺機器を消費者用電子デバイスおよびパーソナル・コンピューターに設定し、構成し、追加することが非常に容易になった。ユニバーサル・プラグ・アンド・プレー（ＵＰｎＰ（商標）は、この簡素さを拡張してネットワーク全体を含むようにし、ネットワーク取付プリンター、インターネット・ゲートウェイ、および消費者電子機器のような、ネットワーク接続デバイスおよびサービスの発見および制御を可能にする。ＵＰｎＰネットワーキング・プロトコルは、ＵＰｎＰフォーラムによって公表されている。ＵＰｎＰフォーラムは、多くの異なる販売業者からのスタンド・アロン・デバイスやＰＣ間における簡単でロバストな接続を可能にするために設計された業界の創意である。

ＵＰｎＰは、プラグ・アンド・プレー周辺モデルの単なる拡張を超えるものである。これは、広範囲の販売業者からのある広さのデバイス別に対する、ゼロ・コンフィギュレーション、「不可視」ネットワーク、および自動発見をサポートするように設計されている。ＵＰｎＰを用いると、デバイスは動的にネットワークに加入し、ＩＰ（インターネット・プロトコル）アドレスを入手し、その能力を伝達し、他のデバイスの存在および能力について学習することができ、全てが自動的に行われることによって、ゼロ・コンフィギュレーション・ネットワークの構築を容易にする。その後、デバイスは、コンテンツにアクセスし共有するためにピア・ツー・ピア・ネットワーキングを用いれば、互いに直接通信することができる。

ＵＰｎＰ対応ネットワークから便益を得ることができる種々のデバイスは、広範に及び(large)、例えば、全ての形状係数(form factor)のインテリジェント器具、ワイヤレス・デバイス、およびＰＣが含まれる。ＵＰｎＰの範囲は、とりわけ、家庭用自動化およびネットワーキング、印刷および撮像、オーディオ／ビデオ娯楽、台所器具、自動車ネットワーク、ならびに移動体デバイス・ネットワークのような分野において既存の用途および新しい用途の多くを包含する程に広い。

ＵＰｎＰは、分散型オープン・ネットワーク・アーキテクチャであり、いずれの特定のオペレーティング・システム、プログラミング言語、物理的媒体にも独立している。しかしながら、ＵＰｎＰは、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネット・プロトコル）、ＨＴＴＰ（ハイパーテキスト転送プロトコル）、ＸＭＬ（拡張可能マークアップ言語）のような標準プロトコルを用いており、既存のネットワークに継ぎ目無く入り込むことができる。このような標準化されたプロトコルを用いることによって、ＵＰｎＰは相互動作可能性の便益を固有の特徴のように得ることが可能になる。

ＵＰｎＰは、コンテンツ・ディレクトリ・サービスを用いており、機能の集合を実装して、ローカルＵＰｎＰデバイス上にあるコンテンツ・レポジトリに格納されているコンテンツ項目（例えば、データ・ファイル、音楽、ソフトウェア、写真、ビデオ、ゲーム等）へのアクセスをＵＰｎＰネットワーク上にあるリモートＵＰｎＰデバイスに提供する。コンテンツ・ディレクトリ・サービスの機能は、レポジトリにおけるコンテンツ項目のブラウジングおよび検索を可能にすることである。コンテンツ・ディレクトリ・サービスにおいて参照された各コンテンツ項目は、コンテンツに関する種々の情報を含み、ローカル・デバイスがコンテンツ項目をリモート・デバイスに転送するために用いることができる転送プロトコルおよびファイル・フォーマットが含まれる。全てのＵＰｎＰサービスに関して、リモート・デバイスは、ＨＴＴＰを用いる単純オブジェクト抽象化プロトコル（ＳＯＡＰ：Simple Object Abstraction Protocol）を用いて、コンテンツ・ディレクトリ・サービスと相互作用を行う。

所望のコンテンツ項目を特定した後、例えば、ＸＭＬ文書におけるリソース即ち<res>タグを用いて、リモート・デバイスはコンテンツ・ディレクトリ・サービスからの転送プロトコル情報を用いて、それをリモート・デバイスにおけるメディア・プレーヤの能力と照合する。共通転送プロトコルは、例えば、ＨＴＴＰ ＧＥＴおよびＲＴＳＰ／ＲＴＰ（リアル・タイム・ストリーミング・プロトコル、リアル・タイム・トランスポート・プロトコル）を含む。次いで、転送されたコンテンツは、別のＵＰｎＰサービス（ＡＶトランスポート制御サービス）または非ＵＰｎＰ帯域外プロトコルを用いて、リモート・デバイスによってレンダリングされ、コンテンツのフロー（例えば、停止、早送り、巻き戻し、一時停止等）を制御する。

ＵＰｎＰは多くのネットワーキング用途において非常に満足できる動作を行うが、現在の実現例では、ＵＰｎＰデバイスのユーザーに、ネットワークに接続されている他のＵＰｎＰデバイス上で発見されたコンテンツ項目へのファイル・アクセスを提供しない。即ち、ユーザーは制限されており、コンテンツ・項目があることを知り、読み取り専用の消費を要求することができるに過ぎない。既存のＵＰｎＰ環境には、発見したコンテンツ項目に対する書き込み変更や、ファイル・レベルでのコンテンツ項目の制御を実施することはできない。

ＵＰｎＰデバイスが、ＵＰｎＰ発見コンテンツ項目をサーバー・メッセージ・ブロック（ＳＭＢ）位置にマッピングするサービスを露出する構成を提供する。サービスは、ＳＭＢシェア経路を、ＵＰｎＰプロトコルを用いてリモート・コンテンツにおいて要求するユーザーに露出するように構成されている。次いで、ユーザーには、ＳＭＢプロトコルを通じてシェア(share)へのアクセスが可能となり、発見したコンテンツ項目のファイル・アクセスを得ること、書き込みを変更すること、またはファイル・レベルの制御を施行することができる。任意に、認証を利用して、ユーザーがＳＭＢシェア位置をサービスから受信することを許可されていることを確認するか、またはユーザーがＳＭＢシェアにアクセスすることを許可されていることを確認する。

種々の例示的な例では、コンテンツ項目を個々のユーザーおよびファイルに対して最も直接的に利用可能なＳＭＢ位置にマッピングする。既存のＵＰｎＰサービスを拡張するか、または新しいＵＰｎＰサービスを利用し、要求側ユーザーに対するＸＭＬフォーマット化した応答に含まれる追加の<res>タグの使用によって、ＵＰｎＰブラウザーまたは検索コマンドに応答して、ＳＭＢ位置を要求側ユーザーに露出する。

本構成の利点は、ユーザーおよびデバイスが、ＵＰｎＰネットワーク上で発見したコンテンツ項目に対するアクセスおよび制御を拡大できることである。

図１は、ＵＰｎＰを利用するように構成されている例示ホーム・ネットワークの図式表現である。 図２は、例示のサーバーおよびクライアント・アーキテクチャのブロック図である。 図３は、コンテンツ・ディレクトリ・サービスと制御点との間における例示のメッセージ・フローを示す図である。 図４は、コンテンツ・ディレクトリ・サービスと制御点との間における別の例示のメッセージ・フローを示す図である。 図５は、ＳＭＢ経路を含む<res>タグを含む例示のＸＭＬ文書である。 図６は、コンテンツ・ディレクトリ・サービスを要求側ユーザーに提供する例示の方法のフローチャートである。 図７は、ＳＢＭシェア位置を特定し、要求側ユーザーに露出する例示の方法のフローチャートである。 図８は、内部に収納したディレクトリ構造を示す例示のコンテンツ・レポジトリのブロック図である。 図９は、ＳＭＢサーバーとＳＭＢクライアントとの間における例示のメッセージ・フローを示す図である。

図面に移ると、同様の参照番号は同様のコンポーネントまたはエレメントを示し、図１は、種々のデバイスがホーム・ネットワーク１０２に結合されている例示の家庭１００の図式表現である。家庭１００の小部屋１０５には、ＰＣ１１０が家族の写真を格納している。第２ＰＣ１１６が居間１２８に置かれており、大型画面のテレビジョン１２８に結合されている。ゲーム・コンソール１３２が寝室１３６に置かれている。ＰＣ１１０、ＰＣ１１６、およびゲーム・コンソール１３２は、各々、ホーム・ネットワーク１０２に結合されている。この図示の例では、ホーム・ネットワーク１０２は、ＵＰｎＰネットワークとして構成されている。ＵＰｎＰネットワークは、例えば、電話線、電力線、イーサネット（登録商標）、ワイヤレスＲＦ（無線周波数）、およびＩＥＥＥ１３９４（電気電子技術者学会）を含む種々のネットワーク媒体を用いて構成することができる。

ＵＰｎＰ発見項目をＳＭＢ位置にマッピングする本構成を用いると、家族は居間１２３に集まって、ＰＣ１１０上に格納されている写真を大型画面テレビジョン１２８上で見ることができる。ＰＣ１１６を用いると、家族は居間１２３から写真に格付けを行い、これらを回転させ、更に写真の名称変更も行うことができる。これらの能力は、ＵＰｎＰおよびＨＴＴＰの目視特性を用いつつ、本構成にしたがってファイル動作をＳＭＢ上において追加することによって可能となる。例示の家族写真は、ＰＣ１１０上に格納されており、図１に示すように、ＰＣ１１０に結合されているモニター上に画像１５０Ａとして送り込まれ、大型画面テレビジョン１２８上では画像１５０Ｂとして送り込まれ、ゲーム・コンソール１３２に結合されているモニター上では画像１５０Ｃとして送り込まれる。

ＳＭＢは、ＯＳＩ（オープン・システム相互接続）ネットワーキング・モデル内のアプリケーション／プレゼンテーション・レイヤにおけるネットワーク・ファイル共有プロトコルである。したがって、ＳＭＢは、例えば、ＴＰＣ／ＩＰ上のＮｅｔＢＩＯＳ（ネットワーク基本入力／出力システム）、ＮｅｔＢＥＵＩ（ＮｅｔＢｉｏｓ拡張ユーザー・インターフェース）、またはＩＰＸ／ＳＰＸ（インターネットワーク・パケット交換／シーケンス状パケット交換）を含む多数の下位レイヤ・プロトコル上で走ることができる。

ＳＭＢプロトコルの特定バージョンを定義するメッセージ・パケットの集合をダイアレクト(dialect)と呼ぶ。例えば、ＣＩＦＳ（共通インターネット・ファイル・システム）は、Microsoft Windows NTオペレーティング・システムにおいて最初に実装されたＳＭＢダイアレクトを指す。ＳＭＢおよびＣＩＦＳは、ＶＭＳ（仮想メモリ・システム）、Ｕｎｉｘの様々なバージョン、およびその他のオペレーティング・システム上でも利用可能である。ＳＭＢのダイアレクトは、ＣＩＦＳも含んで全て、本構成において用いることができ、特定のＳＭＢバージョンまたはダイアレクトの選択は、ＵＰｎＰ発見コンテンツをマッピングする用途の特定的な要件によって異なる。「ＳＭＢ」という用語は、ここで用いる場合、このようなＳＭＢバーションまたはダイアレクト全てに該当することを意図している。

図２は、例示のサーバーおよびクライアント・アーキテクチャ２００のブロック図であり、サーバー・デバイス２０５およびクライアント・デバイス２１２を含む。これらの各々は、通例、ＰＣ、ゲーム・コンソール等のような物理的デバイスまたはユニットとして構成(configure)されている。例えば、サーバー・デバイス２０５は、ＰＣ１１０（図１）に具体化して、家族写真、音楽、ゲーム、データ、ファイル等のような、そこに格納されているコンテンツ項目を共有することができる。同様に、クライアント・デバイス２１２は、ＰＣ１１６（図１）またはゲーム・コンソール１３２（図１）に具体化して、サーバー・デバイス２０５からコンテンツ項目を受信することができる。

サーバー・デバイス２０５およびクライアント・デバイス２１２には、それぞれ、メディアサーバー(MediaServer)ＵＰｎＰデバイス２２２およびメディアレンダラー(MediaRenderer)ＵＰｎＰデバイス２２８が設けられている。ＵＰｎＰデバイスは、論理デバイスであり、個々の物理的設定を反映する必要はない。即ち、物理的デバイスは数個の論理的ＵＰｎＰデバイスをホストすることができ、選択された特定の数のＵＰｎＰデバイスおよびそれらの構成は、ＵＰｎＰ発見項目のマッピングの個々の用途の要件に応じて異なる。メディアサーバーＵＰｎＰデバイス２２２に加えて、サーバー・デバイス２０５はＳＭＢサーバー２３１も含む。ＳＭＢサーバー２３１は、線２３８で示すようなネットワークを通じて、クライアント・デバイス２１２におけるＳＭＢクライアント２３５と通信するように構成されている。

メディアサーバーＵＰｎＰデバイス２２２は、コンテンツ・ディレクトリ・サービス２４０を含む。これは、通例、以下に記載する追加機能性で拡張されているＵＰｎＰフォーラムが公表した定義に準拠したコンテンツ・ディレクトリ・サービスとして構成されている。あるいは、コンテンツ・ディレクトリ・サービス２４０は、要求側クライアントが既存のＵＰｎＰプロトコルを用いてアクセスする、新たなサービス（例えば、「SecureContentDirectoryService」と命名する）として構成する。

メディアレンダラーＵＰｎＰデバイス２２８は、制御点２５１を含む。この例示の例では、制御点２５１は、ＵＰｎＰ制御点であり、メディアレンダラーＵＰｎＰデバイス２２８に埋め込まれている。メディアレンダラーＵＰｎＰデバイス２２８は、サービス上でアクションを呼び出しつつ、要求されたあらゆる入力パラメーターを供給し、あらゆる出力パラメーター、サービス応答、および戻り値を受信する。メディアレンダラーＵＰｎＰデバイス２２８は、通例、ＵＰｎＰフォーラムが公表した定義に準拠して、サーバー・デバイス２０５から受信するコンテンツ項目をレンダリングする能力を有するクライアント・デバイス２１２をインスタンス化するメディアレンダラーとして構成されている。メディアレンダラーＵＰｎＰ２２８は、レンダリング制御の集合を露出するように構成されるのが極普通であり、この場合、制御点２５１は、個々のコンテンツ項目をどのようにレンダリングするかを制御することができる。ＵＰｎＰ発見項目をＳＭＢ位置にマッピングする代替構成では、メディアレンダラーＵＰｎＰデバイス２２８は、任意に、サーバー・デバイス２０５およびクライアント・デバイス２１２が非ＵＰｎＰ（即ち、帯域外）通信プロトコルを用いて互いに相互作用を行う場合にも利用される。例えば、Windows Media PlayerおよびRoku（商標）SoundBridgeを用いて、コンテンツ項目をレンダリングすることができる。

サーバー−クライアント・アーキテクチャ２００では、制御点２５１は、図２に示すように、線２６０で示すＵＰｎＰネットワークを通じてコンテンツ・ディレクトリ・サービス２４０にアクセスする。

図３は、コンテンツ・ディレクトリ・サービス２４０と制御点２５１との間における例示のメッセージ・フローを示す図である。制御点２５１は、ＳＳＤＰ（簡易サービス発見プロトコル）を用いて、発見メッセージ３０３、通例、Ｍ−検索コマンドを送ることによって、ホーム・ネットワーク１０２（図１）のようなＵＰｎＰネットワーク上にある他のデバイスを発見するために用いられる。コンテンツ・ディレクトリ・サービス２４０は、ＸＭＬフォーマット化したデバイス記述文書のＵＲＩ（ユニフォーム・リソース識別子）を収容するＳＳＤＰメッセージを用いて、Ｍ−検索コマンドに応答する。一方、デバイス記述文書は、利用可能なサービス毎にＸＭＬサービス記述文書３０６の位置を収容する。制御点２５１は、例えば、ＨＴＴＰによってサービス記述文書３０６をダウンロードすることができる。このため、メディアサーバーＵＰｎＰデバイス２２２は、コンテンツ・ディレクトリ・サービス２４０を制御点２５１に露出することができる。

図４は、コンテンツ発見サービス２４０と制御点２５１との間における他の例示のメッセージ・フローを示す図である。制御点２５１は、Windows Negotiate、Kerberos、NTLM等のような認証プロトコルを用いて、コンテンツ・ディレクトリ・サービス２４０に接続する。いずれの認証プロセスの使用も任意である（図４において破線４０６で示す通りである）。コンテンツ・ディレクトリ・サービス２４０と制御点２５１との間における認証交渉に成功した場合、制御点２５１は、ＨＴＴＰによるＳＯＡＰメッセージ４１３を用いて、検索またはブラウズ・コマンドをコンテンツ・ディレクトリ・サービス２４０に発行することができる。コンテンツ・ディレクトリ・サービス２４０は、ＸＭＬ文書４１８を用いて検索またはブラウズ・コマンドに応答して、ＳＭＢ位置にマッピングされる発見コンテンツ項目について、通例エントリの中でもとりわけ<res>タグ・エントリを露出する。このマッピングについては、図６から図８に付随する文章において以下で説明する。

図５は、ＳＭＢ経路を含む<res>タグ５０５を含む例示のＸＭＬ文書４１８を示す。ＳＭＢ経路は、<res>タグ５０５において、

として示されている。これは、この例示の例では、ＩＰアドレスが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>タグ５１０において、

として示されている。これは、この例示の例では、慣例的に用いられている、抽象化経路／命名規則を用いた、前述のＷＭＡ音楽ファイルと同一である。

図６は、ＵＰｎＰデバイス（図２におけるメディアサーバーＵＰｎＰデバイス２２２等）がそのコンテンツ項目を要求側ユーザーにコンテンツ・ディレクトリ・サービス（図２におけるコンテンツ・ディレクトリ・サービス２４０等）を通じて露出する例示の方法６００のフローチャートである。要求側ユーザーは、通例、図２におけるメディアレンダラーＵＰｎＰデバイス２２８を含むクライアント・デバイス２１２のような、離れて位置する電子デバイスのユーザーである。図示の方法６００は、ブロック６０５において開始する。ブロック６１２において、対象のＵＰｎＰデバイスを検索するためにＭ−検索コマンドのような発見メッセージを制御点２５１（図２）から送り、メディアサーバーＵＰｎＰデバイス２２２において受信する。メディアサーバーＵＰｎＰデバイス２２２は、発見メッセージに応答することによって、メディアサーバーＵＰｎＰデバイス２２２およびコンテンツ・ディレクトリ・サービス２４０をクライアント・デバイス２１２が発見することが可能となる。これは、ブロック６１５に示す通りである。ブロック６１８において、コンテンツ・ディレクトリ・サービス２４０は、コンテンツ項目を要求側ユーザーに露出して、格納されているコンテンツの種々のビューを提供することによって、そこで利用可能なコンテンツ項目の検索およびブラウジングを可能にする。コンテンツの詳細記述を用いて、検索クエリがコンテンツ項目の集合を返すことができる。加えて、コンテナを通じてコンテンツの編成をサポートする。コンテナは、ディレクトリまたはフォルダーと同様に、コンテンツをクラスタ化するために用いることができる。例示の方法６００は、ブロック６２７において終了する。

図７は、前述の方法６００（図６）において提供するコンテンツ・ディレクトリ・サービスを用いて、ＳＭＢシェア位置を特定し、要求側ユーザーに露出する。先に記したセキュアコンテンツディレクトリ・サービスは、方法７００を実行するために使用可能である。あるいは、既存のＵＰｎＰコンテンツ・ディレクトリ・サービスを拡張して、図７に示すステップを実行してもよい。

例示の方法はブロック７０２において開始する。ブロック７１１において、コンテンツ・ディレクトリ・サービスは検索またはブラウズ・コマンドを要求側ユーザーから受信する。ブロック７１５において、任意の認証ステップを実行する。認証プロトコルは、殆どの用途では、Windows Negotiate、Kerberos、ＮＴＬＭ等の１つから選択する。

コンテンツ・ディレクトリ・サービスは、ブロック７１１において示した方法ステップにおける検索またはブラウズ・コマンドの中で要求されたコンテンツ項目を最良のＳＭＢ経路にマッピングするように作動する。「最良」とは、一般に、特定の要求側ユーザーがアクセスすることができる最も直接的なＳＭＢ経路を意味する。

最良のＳＭＢ経路の概念を、更に図８に示す。これは、内部に収容したディレクトリ構造８１１を示す例示のコンテンツ・レポジトリ８００のブロック図である。コンテンツ・レポジトリ８００は、通例、図１におけるＰＣ１１０のようなデバイスにおけるハード・ディスク・ドライブのようなメモリとして具体化する。図８に示すように、ディレクトリ構造８１１は、３つのシェア８１５、８２２、および８２５を含む。この例示の例では、ＰＣ１１０には３人のユーザー、アドミン、ダッド、およびトビイがいる。つまり、

にあるファイルにアクセスしたいリモート・ユーザーには、それぞれのシェア８１５、８２２および８２５の各々を通じてファイルにアクセスする方法が、潜在的に３通りある。アドミンはシェア８１５、８２２、および８２５の各々にアクセスし、ダッドはホーム・シェア８２２およびトビイ・シェア８２５の双方にアクセスする。したがって、露出すべき最良のＳＭＢ経路を特定するには、要求の中に収容されているファイルおよび要求側ユーザーの証明書に基づいて、ＵＮＣ（全世界／均一命名規則）経路を決定する。

トビイがトビイ・シェアにおけるファイルを要求する場合、露出すべき唯一利用可能で最良のＵＮＣ経路は、

となる。

ダッドが同じファイルへのアクセスを望む場合、ダッドのアクセス・レベルに基づいて２つの選択肢がある。

この例では、選択肢Ａが最も直接的な経路を表すので、これが最良の選択肢となる。メディア・サーバー・サービスは、これに応じて、ダッドが要求側ユーザーである場合、

を最良のＳＭＢ経路として選択する。

アドミンがアクセスを要求している場合、３つの選択肢がある。

この例でも、選択肢Ａが再度最も直接的な経路を表すので、これが再度最良の選択肢となる。メディア・サーバー・サービスは、これに応じて、アドミンが要求側ユーザーである場合、

を最良のＳＭＢ経路として選択する。

図７に戻って、メディア・サーバー・サービスは、ブロック７２１において、要求側ユーザーの証明書を用いて、要求側ユーザーになりすます。ブロック７２６において、メディア・サーバー・サービスは、要求されたファイルまでのローカル経路を用い、なりすました要求側ユーザーとして行動することによって、シェルＡＰＩ（アプリケーション・プログラミング・インターフェース）をコールして、要求されたファイルまでの最良のＳＭＢ経路を要求する。シェルＡＰＩがあるＳＭＢ経路を返した場合、メディア・サーバー・サービスは、要求側ユーザーの検索またはブラウズ・コマンドに対するＸＭＬ応答に含まれる<res>タグに、この経路を含ませる。これは、ブロック７３１に示す通りである。例示の方法７００は、ブロック７４０において終了する。

これより図９に移ると、ＳＭＢサーバー２３１（図２）とＳＭＢクライアント２３５（図２）との間における例示のメッセージ・フローを示す図が呈示されている。例示のメッセージは、パケットを備えている。前述のようにメディア・サーバー・サービスがＳＭＢ経路を要求側ユーザーに露出した後に、ＳＭＢプロトコルを用いて、ＳＭＢサーバー２３１とＳＭＢクライアント２３５との間でパケットを交換する。

この例示の例では、ＳＭＢクライアント２３５およびＳＭＢサーバー２３１は、最初に、全二重ＴＣＰ接続を確立する。次いで、ＳＭＢクライアント２３５はＮｅｔＢＩＯＳセッション要求パケットを組立、ＴＣＰ接続を通じて送る。パケットが正しくフォーマットされていた場合、ＳＭＢサーバー２３１は、セッションを確立したことを認めるメッセージを収容したパケットを返送する。この後、ＳＭＢクライアント２３５は、プロトコル交渉メッセージ９０５をＳＭＢサーバー２３１に送り、セッションに用いる特定のＳＭＢダイアレクトを交渉する。

ＳＭＢサーバー２３１は、ＳＭＢクライアント２３５からの要求に応答して、セッションにおいて用いようとするＳＭＢダイアレクトを特定する。また、返送されたメッセージ９１２は、８バイト・ランダム・ストリングも含む。これは、任意の共有鍵認証プロセスの一部として、チャレンジ(challenge)として用いられる。ＳＭＢクライアント２３５は、メッセージ９１６においてチャレンジに対する応答を返送する。メッセージ９１６は、ＳＭＢクライアント２３５の能力に関する情報を含む。先に記したように、認証は、図９において破線で示す、任意のプロセスである。

ＳＭＢサーバー２３１がＳＭＢクライアント２３５からチャレンジに対する応答を受け入れると、有効なＵＩＤ（ユーザーＩＤ）をメッセージ９１８に含めて、ＳＭＢクライアント２３５に返送する。受け入れられない場合、ＳＭＢサーバー２３１はこのメッセージにおいてエラー・コードを返送し、アクセスを拒否する。

ＳＭＢクライアント２３５は、次に、前述のようにメディア・サーバー・サービスによって露出された<res>タグに収容されているＳＭＢシェアへのアクセスを要求する。アクセス要求メッセージ９２２は、ＵＮＣフォーマットで完全に指定されたシェアの経路を収容する。

シェアへのアクセスが付与された場合、ＳＭＢサーバー２３１は、メッセージ９２７においてシェアに対応する１６ビット・ツリーＩＤ（ＴＩＤ）を返送する。シェアが存在しない場合、またはユーザーがシェアにアクセスするには不十分な証明書を有する場合、サーバーはメッセージ９２７においてエラー・コードを返送し、シェアへのアクセスを拒否する。

ＳＭＢクライアント２３５は、メッセージ９３１において、アクセスしたシェア上にあるファイルを開くように、ＳＭＢサーバーに要求する。このメッセージは、開こうとするファイルの名称を収容している。例えば、再度図５を参照すると、開こうとするファイルの名称は、JC-ahosenamedblue.wmaとなっている。

図９に戻って、ファイルへのアクセスが付与されると、ＳＭＢサーバー２３１は、メッセージ９３５において、要求されたファイルのファイルＩＤを返送する。ファイルが存在しない場合、またはユーザーがファイルにアクセスするには十分な証明書を有していない場合、ＳＭＢサーバーはメッセージ９３５においてエラー・コードを返送し、ファイルへのアクセスを拒否する。

ＳＭＢクライアント２３５は、様々にファイルを開き、開いたファイルからデータを読み取りそしてこのデータをＳＭＢクライアント２３５に返送し、ファイルに書き込み、そしてファイルを閉じるように、ＳＭＢサーバー２３１にメッセージ９４２において要求する。名称変更、削除などを含むその他のファイル動作も、メッセージ９４２によって取り込むことができる。ファイルを開いたときにクライアントが入手するファイルＩＤは、どのファイルを開いて、ＳＭＢサーバー２３１が要求動作を実行すべきかを特定するために、このメッセージに含まれる。メッセージ９４２に対するしかるべき応答が、ＳＭＢサーバー２３１からＳＭＢクライアント２３５へのメッセージ９４８に収容されている。

以上、ＵＰｎＰ発見項目をＳＭＢ位置にマッピングする種々の例示の構成および方法を示し説明したが、添付する特許請求の範囲は必ずしも記載した具体的な特徴、構成、または方法のいずれにも限定されるのではないことは理解されてしかるべきである。逆に、具体的な特徴、構成、または方法は、以下で更に特定的に特許請求するが、ＵＰｎＰ発見項目をＳＭＢ位置にマッピングする例示の形態として開示したのである。

Claims (4)

1. ＵＰｎＰネットワークを通してファイル位置をリモート・クライアントに提供する、コンピュータにより実行する方法であって、
   前記コンピュータが、ＵＰｎＰデバイス記述を前記リモート・クライアントに供給することによって、前記リモート・クライアントに利用可能なＵＰｎＰサービスを特定するステップと、
   前記コンピュータが、複数のサーバー・メッセージ・ブロック（ＳＭＢ）経路からユーザーがアクセス可能な特定のコンテンツ項目への、利用可能で最も直接的なＳＭＢ経路を選択することにより、コンテンツ・レポジトリ内に配置された発見可能オブジェクトをＳＭＢシェア位置にマッピングするステップであって、前記複数のＳＭＢ経路は、前記特定のコンテンツ項目に対し利用可能であり、前記最も直接的なＳＭＢ経路の特定は、前記リモート・クライアントの証明書を使用して前記リモート・クライアントになりすますことを含む、ステップと、
   前記コンピュータが、前記リモート・クライアントから前記特定したＵＰｎＰサービスへのブラウズ・コマンドまたは検索コマンドに応答して、前記利用可能で最も直接的なＳＭＢ経路およびＳＭＢシェア位置を露出するステップと、
   を含む、方法。
2. 請求項１に記載の方法であって、前記コンピュータが、前記特定のコンテンツ項目への前記最も直接的なＳＭＢ経路を要求するシェルＡＰＩをコールする更なるステップを含む、方法。
3. 請求項２記載の方法であって、前記コンピュータが、前記リモート・クライアントに応答して、前記シェルＡＰＩによって戻された経路を含ませる更なるステップを含む、方法。
4. 請求項１から３のいずれかに記載の方法において、前記発見可能なオブジェクトは、音楽、ビデオ、画像、ゲーム、ニュース、またはデータのうち１つから選択したメディア・コンテンツ・データの１つ以上の離散断片を含む、方法。

Images