ＵＰＮＰ認証及び認可
安全なハンドシェイクサービスが、１つまたは複数のＵＰｎＰサービスをホストしているオープンネットワーク内の複数のＵＰｎＰ（Universal Plug and Play）ポータブルメディアデバイスとエンドポイントとの間で実装される。第１のポータブルメディアデバイスは、ネットワークを介して第２のポータブルメディアデバイスからホストされたサービスに対する第１の要求を受信する。第１のポータブルメディアデバイスは、要求の証明書の関数として、第２のポータブルメディアデバイスを認証して認可する。第２のポータブルメディアデバイスが第１のポータブルメディアデバイスによって認証されかつ認可された場合に、第２のポータブルメディアデバイスは、第１のポータブルメディアデバイスにおいてホストされる要求されたサービスへアクセスすることを許可される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＵＰｎＰ認証及び認可に関する。
【背景技術】
【０００２】
ＵＰｎＰ（Universal Plug and Play）アーキテクチャは、例えば電気器具、無線デバイス、エレクトロニクス、ポータブルメディアデバイスデバイス、及びパーソナルコンピュータなどの家庭用電子機器のネットワーク接続性を提供する。ＵＰｎＰは、ＴＣＰ／ＩＰ及びウェブ技術を利用して、近接ネットワークを可能にし、そして家庭、オフィス、及び公共の場のネットワーク化されたデバイスの間のデータ転送を制御する、分散オープンネットワークアーキテクチャである。ＵＰｎＰは、様々なベンダーからの広範囲に及ぶデバイスの種類に対して、ゼロ設定、「不可視」ネットワーク、及び自動発見をサポートするように設計される。デバイスは、動的にネットワークに参加し、ＩＰアドレスを取得し、自らの機能を伝え、他のデバイスのプレゼンス及び機能について知ることができる。また、ＵＰｎＰデバイスは、あとにいかなる望ましくない状態も残すことなしにネットワークを離脱することができる。
【０００３】
ＵＰｎＰモデルでは、全てのデバイスは、いわゆる「不可視」ネットワークを可能にするための任意の可能な要求を行うことを黙示的に認可されると仮定される。しかしながら、認証なしで、別のＵＰｎＰデバイスからＵＰｎＰ要求を受信するデバイスは、かかる要求を送信しているデバイスがかかる要求を行う権限を与えられているかどうかが分らない。ＵＰｎＰは、全てのデバイスが信頼できると仮定されるホームネットワークなどのために設計されたので、デバイスの認証及び認可は必要ではなかった。しかしながら、ホームネットワーク内でさえ、ＵＰｎＰにおける承認及び認可についてのサポートの欠落は問題がある可能性がある。例えば、共有ネットワークが、大学寄宿舎においてまたは無線技術（例えば、Ｗｉ−Ｆｉ）を利用している環境において実施されると仮定する。そのような場合、ＵＰｎＰに基づくファイルサーバの所有者は、ネットワークのサーバに記憶されているファイルへの無制限のアクセスを認めたくないかもしれない。所有者は、ネットワークにアクセスできる他の全てのＵＰｎＰデバイスを信頼することができないかもしれないからである。
【０００４】
別の例では、高解像度ビデオをストリーミングできるＵＰｎＰに基づくメディアサーバの製造業者が、ビデオコンテンツの標準解像度バージョンを他のデバイスにストリーミングしつつ、ライセンスされていてかつ高解像度ビデオコンテンツをレンダリングすることができるデバイスに、高解像度ビデオコンテンツへのアクセスを制限することを望むかもしれないと仮定する。換言すれば、ＵＰｎＰデバイスの製造業者は、同じ製造業者によって製造されたＵＰｎＰデバイスなどの一部のＵＰｎＰデバイスに、アクセスを許可することを望むかもしれない。
【０００５】
認証問題及び認可問題への既存の解決法は、不完全であるか、十分に安全ではないか、またはデジタル著作権管理（ＤＲＭ）システムに縛られている。例えば、認証問題に対する一般的な解決法は、１つまたは複数のＵＰｎＰメッセージにおいて人間が読める周知のストリングを探すことである。ストリングは、ユーザ‐エージェント間のプロトコルのヘッダ内にあってもよいし、または、ストリングは、デバイスディスクリプション文書、即ち、全てのＵＰｎＰデバイスからダウンロードすることができるＸＭＬフォーマットのドキュメントに埋め込まれてもよい。第２のＵＰｎＰデバイスを認証したい第１のＵＰｎＰデバイスは、これらのストリングのうちの１つのプレゼンスについて調べる。見出される場合、第１のＵＰｎＰデバイスは、第２のＵＰｎＰデバイスは認証されているとみなす。しかしながら、複製するのに瑣末な、はっきりと人間が読める形式でストリングが送信されるので、この解決法は安全ではない。
【０００６】
別の既存の解決法では、要求を受信するＵＰｎＰデバイスは、認可されたデバイスのアドレスのテーブルにおいてＵＰｎＰ要求のイーサネット（登録商標）ＭＡＣ（媒体アクセス制御）アドレスを調べる。要求側のデバイスのＭＡＣアドレスが見出される場合、デバイスは認可されているとみなされる。そうでなければ、受信するデバイスのユーザは、要求側のデバイスにアクセスを許可してそのアドレスをテーブルに加えるというオプションを与えられる。しかしながら、イーサネット（登録商標）ＭＡＣアドレスは「なりすまし」または偽造が相対的に容易であるので、この解決法は安全ではない。
【０００７】
更に、この解決法は、ＵＰｎＰデバイスが特定のライセンスされたまたは承認されたデバイスだけにアクセスを制限したいというシナリオにおいては実行不可能である。なぜならば、イーサネット（登録商標）ＭＡＣアドレスは、通常、ＵＰｎＰソフトウェアとは別個に製造されるハードウェアチップに記憶されるからである。承認されたデバイスのＭＡＣアドレスはソフトウェアが開発される時に分かっていないので、ソフトウェア製造業者が、認可されたイーサネット（登録商標）ＭＡＣアドレスのテーブルを生成することは通常、実行不可能である。更に、このシナリオでは、認可されたＭＡＣアドレスのテーブルにＭＡＣアドレスを加えるようにユーザに促すことは望ましくない。なぜならば、ユーザはライセンスされていないかまたは承認されていないデバイスへのアクセスを認めるかもしれないからである。
【０００８】
第３の解決法は、従来のＤＲＭシステムによって提供される。ＤＲＭシステムは、２つのデバイスが互いに認証して、暗号化された形式でオーディオコンテンツ／ビデオコンテンツを転送することを可能にするするが、この特殊化された解決法は、全てのシナリオにおいて適用可能ではない。例えば、ＤＲＭシステムに要求されているように、転送されているコンテンツを暗号化することが、いつも望ましいとは限らないかもしれない。また、いくつかのＤＲＭシステムは、オーディオコンテンツ／ビデオコンテンツを転送する間、安全な（暗号化に基づく）メッセージ交換を有するが、（ＵＰｎＰ ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスによる）コンテンツの発見は、この安全なメッセージ交換でカバーされていない。よって、第１のデバイスは、第１のデバイスが発見されたコンテンツをストリームする権限を与えられているかどうかを知ることなしに、第２のデバイスのＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービス内でコンテンツを発見するかもしれない。
【発明の概要】
【課題を解決するための手段】
【０００９】
本発明の実施形態は、互いのかつ他のＵＰｎＰエンドポイントを認証しかつ認可するためのＵＰｎＰデバイスに対する安全なサービスを提供することによって、公知のＵＰｎＰプロトコルの１つまたは複数の不備を克服する。本発明の態様によれば、ＵＰｎＰイニシエータデバイスは、ＵＰｎＰレスポンダデバイスに信頼された機関からの識別情報を含む要求を送信する。レスポンダは、信頼された機関を介してイニシエータデバイスの識別性を認証して、識別情報の関数としてデバイスを認可する。
【００１０】
別の態様では、本発明は、認証及び認可プロセスの間にセッション識別子を構築する。セッション識別子は、イニシエータへの応答に含まれ、イニシエータからの後続のＵＰｎＰ要求またはＨＴＴＰ要求と前のうまく完了した認可及び認証を適合させる。
【００１１】
ネットワーク化されたポータブルメディアデバイスのための安全な認証及び認可サービスに対するコンピュータ実行可能命令を有するコンピュータ可読媒体は、本発明の更なる態様を具体化する。あるいは、本発明の実施形態は、様々な他の方法及び装置を備えることができる。
【００１２】
この概要は、以下の詳細な説明において更に後述する単純化された形式の概念の選択を導くために提供されている。この概要は特許請求の範囲に記載された主題の重要な特徴または本質的な特徴を識別することを意図していないし、特許請求の範囲に記載された主題の範囲を決定する際の助けとして用いられることも意図していない。
【００１３】
他の特徴は、以下で一部が明らかになり、一部が指摘される。
【００１４】
対応する参照文字は、図面にわたって対応する部分を示す。
【図面の簡単な説明】
【００１５】
【図１】本発明の１つの実施形態による認証及び認可サービスについてのコンピュータシステム環境を示すブロック図である。
【図２】本発明の１つの実施形態によるイニシエータメッセージの生成を示す例示的なフロー図である。
【図３】本発明の１つの実施形態による応答メッセージの生成を示す例示的なフロー図である。
【図４】本発明の１つの実施形態による確認メッセージの生成を示す例示的なフロー図である。
【図５】本発明の１つの実施形態による開始メッセージのブロック図である。
【図６】本発明の実施形態による応答メッセージのブロック図である。
【図７】メディアサーバによってメディアレンダラを承認しかつ認可するコンピュータ実行可能構成要素を有するコンピュータ可読媒体を示す図である。
【図８】メディアサーバによってメディアレンダラを承認しかつ認可するコンピュータ実行可能構成要素を有するコンピュータ可読媒体を示す図である。
【発明を実施するための形態】
【００１６】
図面を参照すると、図１は、本発明の態様による認証及び認可サービスのためのシステムを示している。有利に、本発明の実施形態は、あるＵＰｎＰ（Universal Plug and Play）デバイスに、例えば、ＵＰｎＰプロトコル自体を変更することなしに拡張可能な方法でＵＰｎＰプロトコルに新規の安全なサービスを追加することによって、別のＵＰｎＰデバイスを認証しかつ認可することができるようにする。
【００１７】
１つの実施形態では、ＵＰｎＰデバイスは、ＵＰｎＰエンドポイントからの要求に応じて１つまたは複数のＵＰｎＰサービスを実行する。ＵＰｎＰエンドポイントも、ＵＰｎＰデバイスであってもよいということが理解されるべきである。例えば、第１のデバイスがＵＰｎＰサービスを実行する場合、それは明らかにＵＰｎＰデバイスである。その同じデバイスが第２のＵＰｎＰデバイスで実行されるＵＰｎＰサービスを要求する場合、第１のデバイスもまた、ＵＰｎＰエンドポイントの機能を果たす。示された実施形態では、イニシエータ１０２などのＵＰｎＰエンドポイント及びレスポンダ１０４などのＵＰｎＰデバイスは、同じＵＰｎＰネットワークのメンバである。ＵＰｎＰアーキテクチャは、デバイスが、動的にネットワークに参加し、ＩＰアドレスを取得し、その機能を伝え、他のデバイスのプレゼンス及び機能について知ることができるようにする。ＵＰｎＰデバイス、エンドポイントなどは、例えば家庭用電化製品、コンピュータデバイス、ホームオートメーションデバイス、ホームセキュリティデバイス、電気器具、ポータブルメディアデバイス、プリンティングデバイス、デジタルカメラ、スキャナ、コンピュータネットワークデバイス、モバイルデバイスなどの、ＵＰｎＰネットワークプロトコルを実行するいかなるデバイスをも含む。
【００１８】
本発明の１つの態様は、新規なＵＰｎＰハンドシェイクサービスを実行する。ハンドシェイクサービスは、ＵＰｎＰエンドポイント（例えば、イニシエータ１０２）及びＵＰｎＰデバイス(例えば、レスポンダ１０４）に、一方もしくはもう一方または互いに認証することができるようにする（即ち、安全な方法で互いの識別性を確立する）。一旦認証されると、各デバイスは、もう一方のデバイスがデバイスと通信する権限を与えられているかどうかを判断することができる。
【００１９】
１つの実施形態では、レスポンダ１０４は、例えばネットワーク上のイニシエータ１０２などのＵＰｎＰメディアレンダラデバイスに、メディアコンテンツを提供する汎用メディアサーバデバイスである。例えば、メディアサーバは、ポータブルメディアデバイス、ＶＣＲ、ＣＤプレーヤ、ＤＶＤプレーヤ、オーディオテーププレーヤ、静止画像カメラ、カムコーダ、ラジオ、ＴＶチューナ、及びセットトップボックスなどのデバイス、ＭＰ３サーバ、ＰＶＲ（パーソナルビデオレコーダ）、並びに、パーソナルコンピュータなどのホームメディアサービスを含む。実施中、イニシエータ１０２及びレスポンダ１０４は、本発明の態様を実行する図に示したコンピュータ実行可能命令などのコンピュータ実行可能命令を実行する。
【００２０】
イニシエータ１０２及びレスポンダ１０４は、通常、少なくともいくつかの形式のコンピュータ可読媒体を有している。揮発性媒体及び不揮発性媒体、着脱自在媒体及び固定式媒体の両方を含むコンピュータ可読媒体は、イニシエータ１０２及びレスポンダ１０４によってアクセスすることができるいかなる利用可能媒体であってもよい。例であって限定ではないが、コンピュータ可読媒体は、コンピュータ記憶媒体及び通信媒体を備える。コンピュータ記憶媒体は、例えばコンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報の記憶のためのいかなる方法または技術において実行される揮発性媒体及び不揮発性媒体、着脱自在媒体及び固定式媒体を含む。例えば、コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、もしくは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（Digital Versatile Disk）、もしくは他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、もしくはその他の磁気記憶デバイス、または所望の情報を記憶するために用いることができてかつイニシエータ１０２及びレスポンダ１０４によってアクセスすることができるいかなる他の媒体をも含む。通信媒体は、通常、コンピュータ可読命令、データ構造、プログラムモジュール、または、搬送波または他の搬送メカニズムなどの変調されたデータ信号内の他のデータを具体化し、かついかなる情報配信媒体をも含む。当業者は、変調されたデータ信号に精通しており、変調されたデータ信号は、１つまたは複数のその特徴を、信号内の情報を符号化するような方法で設定または変更した。例えば有線ネットワークまたは直接配線接続などの有線媒体、並びに、音響、ＲＦ、赤外線、及びその他の無線媒体などの無線媒体は、通信媒体の例である。上記のうちのいずれの組合せも、コンピュータ可読媒体の範囲内に含まれる。
【００２１】
メディアサーバは、ＵＰｎＰコンテンツディレクトリサービスを介してそのコンテンツを公開する。メディアサーバは、いかなる特定のタイプの媒体、いかなるデータフォーマット、及び転送プロトコルをも処理することができる。媒体コンテンツの例は、ＭＰＥＧ２ビデオ、ＣＤオーディオ、ＭＰ３オーディオ、ＷＭＡオーディオ、及びＪＰＥＧ画像を含む。
【００２２】
ＵＰｎＰサービスは、ＵＲＮ（Uniform Resource Name）で識別される。デバイスが他のデバイスによってホストされるサービスを検索するときに、または、デバイス自身がホストするサービスの可用性（availability）をデバイスが知らせるときに、ＵＲＮが用いられる。ハンドシェイクサービス用のＵＲＮは、任意に選択することができる。本発明の１つの実施形態では、「ｕｒｎ：ｓｃｈｅｍａｓ−ｍｉｃｒｏｓｏｆｔ−ｃｏｍ：ｓｅｒｖｉｃｅ：Ｈａｎｄｓｈａｋｅ：ｌ」が、ハンドシェイクサービス用のＵＲＮである。
【００２３】
安全なＵＰｎＰデバイスだけが、認証されかつ認可された他のＵＰｎＰデバイス及びエンドポイントからの通信を受け入れる。よって、安全なＵＰｎＰデバイスが第２のデバイスに安全なデバイスによって実行される任意の他のＵＰｎＰサービスにアクセスすることができるようにする前に、ハンドシェイクサービスが第２のデバイスをうまく認証しかつ認可することを安全なＵＰｎＰデバイスは必要とする。
【００２４】
１つの実施形態では、別のＵＰｎＰデバイスによってホストされるサービスを要求するＵＰｎＰエンドポイントは、イニシエータ１０２と称される。例えば、メディアレンダラデバイスがメディアサーバデバイスによって提供される利用可能なコンテンツのリストを要求する場合、メディアレンダラは、メディアサーバデバイスによってホストされるＵＰｎＰ ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスに、要求を送信する。この例では、メディアレンダラがＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスと通信するときにメディアレンダラがイニシエータ１０２であり、メディアサーバデバイスがレスポンダ１０４と称される。
【００２５】
しかしながら、同じメディアレンダラデバイスがまた、それ自体のＵＰｎＰサービスをホストすることもできる。この場合、メディアレンダラは、ＵＰｎＰデバイスとしてもＵＰｎＰエンドポイントとしても動作している。メディアサーバがそれらのサービスのうちのいずれかを利用することを決定する場合、役割は逆転し、メディアサーバはイニシエータ１０２でありかつメディアレンダラはレスポンダ１０４である。１つの実施形態では、メディアレンダラによって開始されたメディアサーバへのハンドシェイク及びメディアサーバによって開始されたメディアレンダラへのハンドシェイクは、２つの完全に独立した動作として処理される。
【００２６】
ＵＰｎＰプロトコルは、ＵＰｎＰプロトコルが通信したいデバイスを見つけるための２つの標準的な方法をイニシエータ１０２に提供する。第１に、イニシエータ１０２は、Ｍ−ＳＥＡＲＣＨ要求を放送し、Ｍ−ＳＥＡＲＣＨ要求は、Ｍ−ＳＥＡＲＣＨ要求内のＵＲＮによって識別されるＵＰｎＰサービスをサポートするネットワーク上の全てのＵＰｎＰデバイスから応答を求める。第２に、イニシエータ１０２はＮＯＴＩＦＹメッセージを聞く（listen）。全てのＵＰｎＰデバイスは、それらがホストするサービスの可用性（availability）を知らせるＮＯＴＩＦＹメッセージを周期的に送信する。
【００２７】
１つの実施形態では、ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスを実行するＵＰｎＰデバイスを検索するメディアレンダラデバイスは、Ｍ−ＳＥＡＲＣＨ及び／またはＮＯＴＩＦＹメッセージを用いてＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスを見つけることになる。メディアレンダラはまた、Ｍ−ＳＥＡＲＣＨ及び／またはＮＯＴＩＦＹメッセージを用いて、サービスのＵＲＮで識別されるハンドシェイクサービスを見つける。本実施形態では、同じＵＰｎＰデバイスがハンドシェイクサービスもＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスもホストする場合、メディアレンダラはＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスと通信するだけである。そして、ハンドシェイクサービスが成功した場合、メディアレンダラはＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスを用いるだけである。ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスは実例的な目的として用いられ、ハンドシェイクサービスは、ＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒサービスまたはＡＶＴｒａｎｓｐｏｒｔサービスなどの他のいかなるＵＰｎＰサービスの前に実行することができる。
【００２８】
代替的実施形態では、ハンドシェイクサービスは、共有秘密及び対称暗号鍵を構築する。共有秘密は、セキュリティトークン７０２を生成するために用いられて、セキュリティトークン７０２は、後続のＵＰｎＰ要求またはＨＴＴＰ要求において用いられて、要求がすでに認証されかつ認可されたデバイスからのものであることを証明することができる。セキュリティトークン７０２は、各要求に応じて変更されて、悪い（rogue）デバイスが認可されたデバイスになりすまそうとするのをより難しくすることができる。あるいは、デバイスのイーサネット（登録商標）ＭＡＣアドレスまたはＩＰアドレスを、すでに認証されたデバイスからの要求を識別するために用いることができる。しかしながら、上記に説明したように、この実行はより安全ではない。
【００２９】
図３-５に示した方法によって構築される対称暗号鍵を、デバイスが認可されたあとに転送されているコンテンツを暗号化するために用いることができる。このことは、追加のセキュリティの層を設けて、認可されていないデバイスが２つの相互に認可されたデバイス間の通信で盗聴できないようにする。例えば、上で述べられた高解像度ビデオストリームを、対称暗号鍵を用いて暗号化することができる。
【００３０】
１つの実施形態では、ハンドシェイクサービスに加えて、最初のハンドシェイクが実行された後に、新規のＨＴＴＰヘッダ及びＵＰｎＰヘッダが後続のＨＴＴＰ要求及びＵＰｎＰ要求において用いられる。あるいは、ＸＭＬに基づく構文が、ＵＰｎＰヘッダの代わりに用いられる。
【００３１】
ＵＰｎＰサービスは、動作及びイベントを有する。ハンドシェイクサービスは、２つの動作を含み、イベントを含まない。動作は、入力パラメータ及び出力パラメータを有するリモートプロシージャコールと同様である。１つの実施形態では、ハンドシェイクサービスを始めるために、イニシエータ１０２は、ＤｏＨａｎｄｓｈａｋｅ動作１０６を呼び出す。動作の名前は全く重要ではなくて、ＸＭＬ形式のＵＰｎＰサービスディスクリプションが名前を正しく記述する限り、異なっていてもよい。
【００３２】
１つの実施形態では、ＤｏＨａｎｄｓｈａｋｅ動作は、１つの入力パラメータ及び２つの出力パラメータを有する。本発明の本実施形態では、入力パラメータはイニシエータメッセージ５００であり、第１の出力パラメータはレスポンダメッセージ６００であり、第２の出力パラメータは要求識別子である。代替的実施形態では、イニシエータメッセージ５００、レスポンダメッセージ６００は一つのフォーマットである。さらに、ＵＰｎＰはテキストベースのプロトコルであるので、イニシエータメッセージ及びレスポンダメッセージは、ＵＰｎＰを越えて転送されると、ベース６４（Ｂａｓｅ６４）符号化される。
【００３３】
イニシエータメッセージ５００の目的は、レスポンダ１０４がイニシエータ１０２を認証することができるようにすることである。ＤｏＨａｎｄｓｈａｋｅ動作１０６は、イニシエータ１０２からレスポンダ１０４へイニシエータメッセージ５００を送信する。図５に示した実施形態では、イニシエータメッセージ５００は証明書５０２を含み、公開鍵暗号法が認証のために用いられる。証明書は、デジタル署名を用いて、例えばデバイスモデル番号及びシリアル番号などのイニシエータ１０２の識別情報５０６に公開鍵５０４を結びつける。証明書を、公開鍵５０４がイニシエータ１０２に属していることを検証するために用いることができる。典型的な公開鍵インフラストラクチャスキームでは、署名は信頼された機関からのものだろう。レスポンダ１０４は、署名を検証して、証明書が本物であることを確認することができる。有利に、レスポンダ１０４は、異なるイニシエータ１０２間で区別することができて、証明書５０２に含まれた情報を用いることにより各イニシエータ１０２を個々に認可することができるだろう。例えば、レスポンダ１０４は、高解像度ビデオコンテンツをストリーミングすることができるだけであると仮定する。レスポンダ１０４は、証明書５０２からデバイスモデル番号を調べて、イニシエータ１０２が高解像度ビデオコンテンツをレンダリングすることができるかどうかを判断する。イニシエータ１０２が高解像度ビデオコンテンツをレンダリングすることができる場合、レスポンダ１０４はイニシエータ１０２を認可する。
【００３４】
代替的実施形態では、証明書はイニシエータの公開鍵５０４を含む。公開鍵５０４で暗号化されたメッセージは、適合している秘密鍵を用いて解読することができるだけである。適合している秘密鍵はイニシエータ１０２だけに知られている。本実施形態では、イニシエータメッセージ５００は、証明書５０２だけでなく、ＤｏＨａｎｄｓｈａｋｅ動作が呼び出されるたびに異なっている乱数５０８も含む。乱数５０８は、レスポンダ１０４によって用いられて、共有秘密を生成する。あるいは、乱数５０８は、数字及び文字の任意の生成された組合せである。
【００３５】
１つの実施形態では、レスポンダメッセージ６００は、レスポンダ１０４がイニシエータメッセージ５００において証明書５０２を認証することができたという指示である。図６に示した代替的実施形態では、レスポンダメッセージ６００は、レスポンダ１０４の証明書６０２を含んで、イニシエータ１０２がレスポンダ１０４を認証することができるようにする。証明書６０２はまた、レスポンダ１０４の識別情報６０６もレスポンダの公開鍵６０４も含む。ＤｏＨａｎｄｓｈａｋｅ動作の応答１０８は、イニシエータ１０２からレスポンダ１０４へレスポンダメッセージ６００及び要求識別子を送信する。
【００３６】
上で説明されたように、証明書６０２は、信頼された機関によって直接または間接的にデジタル署名される。さらに、この署名を検証することによって、イニシエータ１０２はレスポンダ１０４を認証することができる。さらに、レスポンダの証明書６０２は、イニシエータの公開鍵を用いる方法で暗号化される。１つの代替的実施形態では、レスポンダメッセージ６００の暗号化された部分は、ＤｏＨａｎｄｓｈａｋｅ動作が呼び出されるたびに異なる乱数６０８を含む。あるいは、乱数６０８は、数字及び文字の任意の生成された組合せである。
【００３７】
１つの実施形態では、第２の出力パラメータ、即ち、要求識別子は、後続のＵＰｎＰ要求またはＨＴＴＰ要求と前のうまく完了したＤｏＨａｎｄｓｈａｋｅ動作を適合させるために用いられる。うまく完了したＤｏＨａｎｄｓｈａｋｅ動作を有するイニシエータデバイスのイーサネット（登録商標）ＭＡＣアドレスをレスポンダ１０４が記録する実施形態では、更なる要求はイーサネット（登録商標）ＭＡＣアドレスだけに基づいて受け入れられるかまたは拒絶されるので、要求識別子は用いられない。要求識別子を利用する実施形態では、要求識別子は、レスポンダ１０４によって生成される。１つの実施形態では、要求識別子は乱数である。あるいは、要求識別子は、数字及び文字の任意の生成された組合せである。しかしながら、本実施形態では、レスポンダ１０４は、イニシエータ１０２がレスポンダメッセージ６００内の暗号化された証明書を実際に解読することができたかどうかを知らない。これを確認することができない状態で、異なるデバイスに対して実際に発行された証明書をイニシエータ１０２が用いたということもあり得る。
【００３８】
Ｃｏｎｆｉｒｍ動作と称される、ＵＰｎＰハンドシェイクサービスの第２の動作は、レスポンダ１０４が、イニシエータ１０２がレスポンダメッセージ６００の証明書を解読することができたということを確認できるようにする。Ｃｏｎｆｉｒｍ動作１１０は、イニシエータ１０２からレスポンダ１０４へ確認メッセージ７００を送信する。
【００３９】
Ｃｏｎｆｉｒｍ動作１１０は、２つの入力パラメータを有し、かつ（成功／失敗指示１１２以外の）出力パラメータを有していない。第１の入力パラメータは、ＤｏＨａｎｄｓｈａｋｅ動作の応答１０８においてレスポンダ１０４がイニシエータ１０２に与えた要求識別子である。１つの実施形態では、要求識別子は、限られた期間有効なだけである。期限切れになった要求識別子を用いてＣｏｎｆｉｒｍ動作を呼び出そうとすることは、この動作に失敗の指示を返させる。
【００４０】
図７において、確認メッセージ７００は、第２の入力パラメータを具体化する。本実施形態では、確認メッセージ７００は、セキュリティトークン７０２を含む。１つの実施形態では、セキュリティトークン７０２は、共有秘密７０２のダイジェストである。１つの代替的実施形態では、セキュリティトークン７０２は、レスポンダ１０４及びイニシエータ１０２に知られており、かつ例えば共有秘密から得られる暗号鍵を用いて暗号化された数字である。１つの実施形態では、確認メッセージ７００は、バイナリ形式で記憶される。共有秘密は、イニシエータメッセージ５００内の乱数５０８及びレスポンダメッセージ６００内の乱数６０８を用いて得られる。レスポンダメッセージ６００内の乱数６０８が暗号化されたので、イニシエータ１０２が確認メッセージ７００内に正しいセキュリティトークン７０２を含む場合、イニシエータ１０２はレスポンダメッセージ６００の暗号化された部分を解読することができたということが分かる。成功または失敗の指示１１２は、レスポンダ１０４からイニシエータ１０２に送信される。
【００４１】
セキュリティトークン７０２は、確認メッセージ７００の平文で送信されない。１つの実施形態では、セキュリティトークン７０２は、レスポンダ及びイニシエータの両方に知られていてかつ例えば、共有秘密から得られる暗号鍵を用いて暗号化された数字である。あるいは、セキュリティトークン７０２は、共有秘密のダイジェスト（ハッシュ）である。ＣＰＵ資源を最小にするのを望む１つの実施形態では、ハッシュが実行される。なぜならば、ハッシュは通常、暗号化アルゴリズムより計算するのに少ないＣＰＵ資源を必要とするからである。
【００４２】
代替的実施形態では、２つの乱数５０８、６０８もまた用いられて、対称暗号鍵を得ることができる。鍵は、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）などの、いくつかの適当な暗号化アルゴリズムと共に用いられて、シェークハンド動作が完了した後に送信されるＵＰｎＰトラフィック及び／またはＨＴＴＰトラフィックを暗号化する。例えば、この暗号鍵を用いてメディアサーバからダウンロードされるかまたはストリームされるコンテンツを暗号化することが望ましい可能性がある。
【００４３】
１つの実施形態では、レスポンダ１０４は、イニシエータ１０２デバイスのイーサネット（登録商標）ＭＡＣアドレスを記録することができて、ハンドシェイクを通過したデバイスのテーブルにそれを加えかつ／または（デバイスがまたうまく認可されたと仮定すると）認可されたデバイスのテーブルにそれを加えることができる。後続のＵＰｎＰ要求及びＨＴＴＰ要求は、ＭＡＣアドレスが認可されたデバイステーブル内にあるかどうかに基づいて受け入れられるかまたは拒絶されることになる。
【００４４】
本発明の別の実施形態では、要求識別子パラメータがセッション識別子の役割を担う。本実施形態では、セッション識別子は後続のＵＰｎＰ要求及びＨＴＴＰ要求において用いられて、要求はハンドシェイク作業を完了したデバイスからのものであるということをレスポンダ１０４に分かるようにする。
【００４５】
１つの実施形態では、セッション識別子パラメータは、前に述べた要求識別子と同一である。あるいは、セッション識別子パラメータは、セッショントークンを含む。セッショントークンは、第１の乱数及び第２の乱数の関数として生成されて、第１の生成されたセッショントークンは第２の生成されたセッショントークンと等しくない。別の代替では、Ｃｏｎｆｉｒｍ動作は、１つの出力パラメータを用いて拡張される。新しい出力パラメータはセッション識別子であり、それはＣｏｎｆｉｒｍ動作が成功する場合に提供されるだけである。
【００４６】
本発明の代替的実施形態では、セッション識別子及びセキュリティトークン７０２は、ＵＰｎＰ要求及びＨＴＴＰ要求に含まれる。さらに別の実施形態では、セキュリティトークン７０２は、各要求において異なっている。ある代替では、セキュリティトークン７０２は数字から得られ、イニシエータ１０２及びレスポンダ１０４の両方は各ＵＰｎＰ要求またはＨＴＴＰ要求に応じて数字をインクリメントする。あるいは、セキュリティトークン７０２は同じままであり、追加の数字（例えば、現在の時刻）がダイジェストにおいて算出される。追加の数字は、各ＵＰｎＰ要求またはＨＴＴＰ要求に応じてインクリメントされるかまたは異なっている。
【００４７】
ＵＰｎＰでは、プロトコルヘッダはＨＴＴＰヘッダと同じ構文を用いるので、両方のプロトコルに有効である単一のプロトコルヘッダを定義することが可能である。１つの実施形態では、セッション識別子及び秘密のダイジェストは、ＡＢＮＦ（augmented Backus-Naur form）構文を利用しているＵＰｎＰヘッダ／ＨＴＴＰヘッダに含まれる。
【００４８】
“Ｘ‐Ｈａｎｄｓｈａｋｅ‐Ｉｄ：”＜ｓｅｓｓｉｏｎ‐ｉｄ＞“：”＜ｂａｓｅ６４‐ｅｎｃｏｄｅｄ‐ｄｉｇｅｓｔ‐ｏｆ‐ｓｅｃｒｅｔ＞
【００４９】
＜ｓｅｓｓｉｏｎ‐ｉｄ＞フィールドは、前に言及されたセッション識別子パラメータであり、＜ｂａｓｅ６４‐ｅｎｃｏｄｅｄ‐ｄｉｇｅｓｔ‐ｏｆ‐ｓｅｃｒｅｔ＞フィールドは、ベース６４符号化が用いられてそれをＡＳＣＩＩ表現に変換した後に、共有秘密を通じて算出されるダイジェスト（ハッシュ）である。
【００５０】
例：
Ｘ−Ｈａｎｄｓｈａｋｅ‐Ｉｄ：１２３４５：ａｂ０ｆｌ２ｃｄ４５ｅｅｆｌ
【００５１】
（ベース６４符号化ダイジェストは、説明の目的のためにここに示されていて、実際にはより大きいだろう。）本発明の別の変化形では、上で定義された“Ｘ−Ｈａｎｄｓｈａｋｅ‐Ｉｄ”ヘッダのようなヘッダは、ＨＴＴＰ要求のために用いられるだけである。
【００５２】
あるいは、ＵＰｎＰ要求について、情報はＵＰｎＰ要求メッセージ内に埋め込まれる。以下は、ＸＭＬ構文の例である。
【００５３】
＜ｍｓｈ：ｈａｎｄｓｈａｋｅ ｘｍｌｎｓ：ｍｓｈ＝“ｓｃｈｅｍａｓ‐ｍｉｃｒｏｓｏｆｔ‐ｃｏｍ：Ｈａｎｄｓｈａｋｅ‐ｌ‐０”ｍｓｈ：ｉｄ＝“１２３４５”＞
Ａｂ０ｆｌ２ｃｄ４５ｅｅｆｌ
＜／ｍｓｈ：ｈａｎｄｓｈａｋｅ＞
【００５４】
ここで図２を参照すると、図は、本発明の実施形態によるイニシエータメッセージの生成を示す。２０２で、第１のポータブルメディアデバイスは、ホストされたＵＰｎＰサービスの可用性を知らせるネットワークを介してメッセージを放送する。代替的実施形態では、ネットワークはピアツーピアネットワークである。別の実施形態では、第１のポータブルメディアデバイスはＵＰｎＰコントロールポイントを備え、第２のポータブルメディアデバイスはＵＰｎＰメディアレンダラを備える。あるいは、第１のポータブルメディアデバイスはＵＰｎＰメディアレンダラを備え、第２のポータブルメディアデバイスはＵＰｎＰコントロールポイントを備える。サービスは、ハンドシェイクサービス及び例えばコンテンツディレクトリサービスなどの少なくとも１つの追加のＵＰｎＰサービスを含む。１つの実施形態では、第１のポータブルメディアデバイスは、そのホストされたサービスの可用性を知らせるＵＰｎＰ ＮＯＴＩＦＹメッセージを周期的に放送する。代替的実施形態では、第２のポータブルメディアデバイスは、ハンドシェイクサービスについてのＵＰｎＰ Ｍ−ＳＥＡＲＣＨ要求を放送する。それは、Ｍ−ＳＥＡＲＣＨ要求内のＵＲＮによって識別されるハンドシェイクサービスをサポートしているネットワーク上の全てのＵＰｎＰデバイスからの応答を求めている。
【００５５】
２０４において、第２のポータブルメディアデバイスは、第１の乱数を生成する。代替のものでは、乱数は文字及び数字のいかなる組合せであってもよい。１つの実施形態では、第１のポータブルメディアデバイスはレスポンダなどのＵＰｎＰデバイスであり、第２のポータブルメディアデバイスは図１に示したイニシエータなどのＵＰｎＰエンドポイントである。代替的実施形態では、第２のポータブルメディアデバイスもＵＰｎＰデバイスである。別の実施形態では、乱数は、第１のポータブルメディアデバイスへの要求に含まれて、デバイス間の更なる通信の対称暗号化に用いることができる共有秘密を生成するために用いられるだろう。あるいは、乱数は、デバイス間の更なる通信に含まれるセッション識別子を構築するために用いられる。
【００５６】
２０６において、第２のポータブルメディアデバイスは、識別情報及びデジタル署名を第１のポータブルメディアデバイスへの要求にフォーマットする。１つの実施形態では、第２のポータブルメディアデバイスは、公開鍵‐非公開鍵対のうちの非公開鍵を用いて信頼された機関からの証明書及び第１の乱数に署名する。証明書は第２のポータブルメディアデバイスの識別情報を含み、下記のうちの少なくとも１つを含む。即ち、デバイスのデバイスモデル番号、デバイスのシリアル番号、及びデバイスでサポートされるメディアフォーマットのリストである。代替的実施形態では、要求に含まれるデータは、図５に示されるバイナリのイニシエータメッセージにフォーマットされる。
【００５７】
２０８において、第２のポータブルメディアデバイスは、ハンドシェイクサービスをホストしている第１のポータブルメディアデバイスにネットワークを介して要求を送信する。ローカルエリアネットワーク環境において用いられると、第１のポータブルメディアデバイス及び第２のポータブルメディアデバイスは、ネットワークインタフェースまたはアダプタを通じてＬＡＮに接続される。広域ネットワーク環境において用いられると、第１のポータブルメディアデバイス及び第２のポータブルメディアデバイスは、インターネットなどのＷＡＮを越えて通信を確立するネットワークカードまたは他の手段を通常含む。ネットワーク環境内の接続は、有線ネットワークまたは直接配線接続、並びに、Ｗｉ‐Ｆｉ、音響、ＲＦ、赤外線、及び他の無線媒体などの無線媒体であってもよい。示されたネットワーク接続は、例示的であり、第１のポータブルメディアデバイスと第２のポータブルメディアデバイスとの間の通信リンクを確立する他の手段が用いられてもよい。
【００５８】
ここで、図３を参照すると、第１のポータブルメディアデバイスは、第２のポータブルメディアデバイスから要求を受信する。次に、第１のポータブルメディアデバイスは、３０２‐３０９において第２のポータブルメディアデバイスのデジタル署名の関数として、第２のポータブルメディアデバイスを認証する。認証は、第２のポータブルメディアデバイスの識別性を証明する。
【００５９】
３０２において、第１のポータブルメディアデバイスは、デジタル署名が第２のポータブルメディアデバイスからであるということを検証する。１つの実施形態では、イニシエータメッセージに含まれる署名された証明書は、信頼された機関によって検証される。デジタル署名が検証されない場合、第１のポータブルメディアデバイスは３０４においてセッションをやめて、３０６において第２のポータブルメディアデバイスとの接続を終了する。３０８において、第１のポータブルメディアデバイスは、イニシエータメッセージに含まれる証明書が信頼された機関からであるかどうかを調べる。証明書が信頼された機関からでない場合、第１のポータブルメディアデバイスは３０４においてセッションをやめて、３０６において第２のポータブルメディアデバイスとの接続を終了する。
【００６０】
一旦デバイスが認証されると、３０９において、第１のポータブルメディアデバイスは、証明書の識別情報の関数として、第２のポータブルメディアデバイスを認可する。代替的実施形態では、第１のポータブルメディアは、第２のポータブルメディアデバイスにクエリして、第２のポータブルメディアデバイスでサポートされるメディアフォーマットのリストを得る。本実施形態では、第２のデバイスが少なくとも１つの互換性のあるフォーマットをサポートする場合、第１のポータブルメディアデバイスは第２のポータブルメディアデバイスを認可する。第２のポータブルメディアデバイスが認可されない場合、第１のポータブルメディアデバイスは３０４でセッションをやめて、３０６で第２のポータブルメディアデバイスとの接続を終了する。
【００６１】
有利に、第１のポータブルメディアは、ライセンスされたまたは承認されたデバイスに対して認可を通してそのサービスへのアクセスを制限することができる。例えば、第１のポータブルメディアデバイスは高解像度ビデオをストリームするだけのサービスをホストすると仮定する。第１のポータブルメディアデバイスは、それが高解像度ビデオコンテンツをレンダリングすることができる場合に、第２のポータブルメディアデバイスを認可するだけだろう。第１のポータブルメディアデバイスは、第２のポータブルメディアデバイスが高解像度ビデオコンテンツをレンダリングすることができるかどうかを第２のポータブルメディアデバイスの識別情報（例えばモデル番号、シリアル番号、及びサポートされるメディアフォーマット）によって判定する。
【００６２】
１つの実施形態では、第１のポータブルメディアデバイスは、テーブル内に認証されかつ認可された第２のポータブルメディアデバイスのＭＡＣイーサネット（登録商標）アドレスを記録する。本実施形態では、第１のポータブルメディアデバイスは、そのイーサネット（登録商標）ＭＡＣアドレスが記録されたデバイスからホストされたサービスに対する要求を受け入れるだけであり、方法は終了する。
【００６３】
あるいは、図３を再び参照すると、３１０において、第１のポータブルメディアデバイスは、第１の乱数を生成する。代替のものでは、乱数は文字及び数字の任意の組合せであることができる。３１２において、第１のポータブルメディアデバイスは、セキュリティトークン７０２を生成する。１つの実施形態では、セキュリティトークン７０２は、第１の乱数及び第２の乱数から生成される共有秘密のハッシュであり、第１の乱数及び第２の乱数を、デバイス間の更なる通信の対称暗号化（例えば、ＡＥＳ）のために用いることができまたはデバイス間の更なる通信に含まれるセッション識別子を構築するために用いることができる。
【００６４】
３１４において、第１のポータブルメディアデバイスは、証明書、デジタル署名、及び第２の乱数を第２のポータブルメディアデバイスへの応答にフォーマットする。１つの実施形態では、第１のポータブルメディアデバイスは、信頼された機関からの証明書に署名し、第２のポータブルメディアデバイスは、証明書及び署名を用いて第１のポータブルメディアデバイスを認証することができる。代替的実施形態では、要求に含まれるデータは、図６に示したレスポンダメッセージにフォーマットされる。
【００６５】
３１６において、第１のポータブルメディアデバイスは、対称暗号鍵（例えば、ＡＥＳ鍵）を選択して、３１８において、署名された証明書、第２の乱数、及びセキュリティトークン７０２を選択された鍵を用いて暗号化する。３２０において、第１のポータブルメディアデバイスは、第２のポータブルメディアデバイスの公開鍵を用いて選択されたＡＥＳ鍵を暗号化する。ＡＥＳ鍵は第２のポータブルメディアデバイスの公開鍵を用いて暗号化されるので、有利に、人間が読める認証ストリングは応答に含まれない。よって、第２のポータブルメディアデバイスの秘密鍵を有するデバイスだけが、第１のポータブルメディアデバイスの証明書及びハッシュを解読することができる。
【００６６】
３２０において、第１のポータブルメディアデバイスは、第２のポータブルメディアデバイスにネットワークを介して応答メッセージを送信する。代替的実施形態では、要求識別子は応答に含まれる。要求識別子は、第１のポータブルメディアデバイスによって用いられて、第２のポータブルメディアデバイスからの後続のＵＰｎＰ要求またはＨＴＴＰ要求と前のうまく完了した承認及び認可を適合させる。別の実施形態では、要求識別子は、第２のポータブルメディアデバイスが応答メッセージ内の証明書を解読することができたということを確認するために用いられる。本実施形態では、セッション識別子は、応答に含まれて、第２のポータブルメディアデバイスからの後続のＵＰｎＰ要求またはＨＴＴＰ要求と前のうまく完了した承認及び認可を適合させる。
【００６７】
ここで図４を参照すると、第２のポータブルメディアデバイスは、第１のポータブルメディアデバイスから応答を受信する。次に、第２のポータブルメディアデバイスは、４０２-４１２で第１のポータブルメディアデバイスのデジタル署名の関数として、第１のポータブルメディアデバイスを認証する。認証は、第１のポータブルメディアデバイスの識別性を確立する。１つの実施形態では、応答メッセージに含まれる署名された証明書は、信頼された機関によって検証される。
【００６８】
４０２において、第２のポータブルメディアデバイスは、その非公開鍵を用いて応答メッセージ内のＡＥＳ鍵を解読する。４０４において、第２のポータブルメディアデバイスは、解読されたＡＥＳ鍵を用いて第１のポータブルメディアデバイスの証明書を解読する。４０６において、第２のポータブルメディアデバイスは、デジタル署名が第１のポータブルメディアデバイスからであるということを検証する。デジタル署名が検証されない場合、第２のポータブルメディアデバイスは４０８においてセッションをやめて、４１０において第１のポータブルメディアデバイスとの接続を終了する。４１２において、第２のポータブルメディアデバイスは、応答メッセージに含まれる証明書が信頼された機関からであるかどうかを調べる。証明書が信頼された機関からでない場合、第２のポータブルメディアデバイスは、４０８でセッションをやめて、４１０において第１のポータブルメディアデバイスとの接続を終了する。
【００６９】
４１４において、一旦第１のポータブルメディアデバイスが認証されると、第２のポータブルメディアデバイスは、受信した要求識別子及び解読されたハッシュを含む確認を生成する。代替的実施形態では、確認に含まれるデータは、図７に示した確認メッセージにフォーマットされる。１つの実施形態では、少なくとも確認の一部は、第１のポータブルメディアデバイスの公開鍵によって暗号化される。代替的実施形態では、要求識別子は、限られた期間（例えば、１０秒）有効なだけである。要求識別子が期限切れになる前に、第２のポータブルメディアデバイスが第１のポータブルメディアデバイスに確認を送信しない場合、認証及び認可は失敗し、第２のポータブルメディアデバイスは、ステップ３０２において再びプロセスを開始しなければならない。４１６において、第２のポータブルメディアデバイスは、第１のポータブルメディアデバイスに確認を送信する。
【００７０】
４１８において、第１のポータブルメディアデバイスは、第１のポータブルメディアデバイスの秘密鍵を用いて第２のポータブルメディアデバイスから受信される確認メッセージを解読する。４２０において、第１のポータブルメディアデバイスは、第１の乱数及び第２の乱数からセキュリティトークン７０２を算出する。４２２において、第１のポータブルメディアデバイスは、算出されたセキュリティトークンを確認メッセージの解読されたセキュリティトークン７０２と比較する。２つのセキュリティトークンが等しくない場合、確認は失敗し、４０８において第１のポータブルメディアデバイスはセッションをやめて、４１０において第２のポータブルメディアデバイスとの接続を終了する。
【００７１】
４２４において、第１のポータブルメディアデバイスは、セッション識別子を生成する。セッション識別子は、第１のポータブルメディアデバイスによって用いられて、第２のポータブルメディアデバイスからの後続のＵＰｎＰ要求またはＨＴＴＰ要求と前のうまく完了した承認及び認可を適合させる。１つの実施形態では、セッション識別子は、要求識別子と等しい。代替的実施形態では、セッション識別子は要求識別子と異なる乱数値である。４２６において、第１のポータブルメディアデバイスはセッション識別子を第２のポータブルメディアデバイスに返して、第２のポータブルメディアデバイスの認証及び認可が完了したということを示す。
【００７２】
図８は、メディアサーバによってメディアレンダラを承認しかつ認可するコンピュータ実行可能構成要素を有するコンピュータ可読媒体を示す。１つの実施形態では、メディアレンダラ及びメディアサーバは、ＵＰｎＰデバイスである。あるいは、メディアレンダラ及びメディアサーバは、ポータブルメディアデバイスである。第３の代替のものでは、メディアレンダラは、ＵＰｎＰエンドポイントであり、メディアサーバはＵＰｎＰデバイスである。メディアサーバは、オープンネットワークにおいて１つまたは複数のＵＰｎＰサービスを実行する。１つの代替的実施形態では、ネットワークはピアツーピアネットワークである。構成要素は、インターフェース構成要素８０２、検証構成要素８０４、及びセキュリティ構成要素８０６を含む。
【００７３】
インターフェース構成要素８０２は、ネットワークを介してメディアレンダラから要求を受信する。要求は、メディアレンダラ及びデジタル署名の識別情報を含む開始メッセージと関連付けられる。さらに、インターフェース構成要素８０２は、メディアレンダラがメディアサーバによって認証されかつ認可されたかどうかを示している応答をメディアレンダラデバイスにネットワークを介して送信する。
【００７４】
検証構成要素８０４は、要求のデジタル署名の関数としてメディアレンダラを認証する。１つの実施形態では、デジタル署名は信頼された機関によって検証される。さらに、検証構成要素８０４は、要求の識別情報の関数として、メディアレンダラデバイスを認可する。１つの代替的実施形態では、メディアレンダラデバイスは、サポートされるメディアフォーマットのリストを得るためにクエリされる。本実施形態では、メディアレンダラデバイスは、それが少なくとも１つの互換性のあるフォーマットをサポートする場合に認可される。
【００７５】
セキュリティ構成要素８０６は、メディアレンダラが検証構成要素によって認可されて認証された場合、メディアサーバによって実行される１つまたは複数のサービスへのアクセスをメディアレンダラに許可し、メディアレンダラが検証構成要素によって認可されずかつ認証されなかった場合、メディアレンダラへのアクセスを拒否する。
【００７６】
説明の目的のために、プログラム、及び、例えばインターフェース構成要素８０２、検証構成要素８０４、及びセキュリティ構成要素８０６などの他の実行可能プログラム構成要素は、分離したブロックとして本明細書において示されている。しかしながら、かかるプログラム及び構成要素はＵＰｎＰデバイスの異なる記憶構成要素の様々な時間に存在して、デバイスのデータプロセッサ（または複数のデータプロセッサ）によって実行されるということが認識される。
【００７７】
特別の定めのない限り、本明細書において図示されて説明された本発明の実施形態における動作の実行順序または性能は、本質的ではない。即ち、特別の定めのない限り、動作はいかなる順番で実行されてもよく、本発明の実施形態は、本明細書において開示された動作以外の追加の動作またはそれより少ない動作を含んでいてもよい。例えば、別の動作より前に、別の動作と同時に、または別の動作の後で、特定の動作を実施しまたは実行することは、本発明の態様の範囲内にあると考えられる。
【００７８】
本発明の実施形態は、コンピュータ実行可能命令を用いて実行されてもよい。コンピュータ実行可能命令は、１つまたは複数のコンピュータ実行可能構成要素またはモジュールにまとめられてもよい。本発明の態様を、かかる構成要素またはモジュールのうちのいかなる数及び体系でも実行することができる。例えば、本発明の態様は、図に示して本明細書で説明された特定のコンピュータ実行可能命令または特定の構成要素もしくはモジュールに限定されない。本発明の他の実施形態は、本明細書において示しかつ説明されたよりも多くの機能またはより少ない機能を有する異なったコンピュータ実行可能命令または構成要素を含むことができる。
【００７９】
本発明の態様または本発明の実施形態の要素を導くときに、冠詞「ある（a）」、「ある（an）」、「この（the）」、及び「前記（said）」は、１つまたは複数の要素があることを意味することを意図している。用語「備える」、「含む」、及び「有する」は、包括的であることを意図し、リストされた要素以外の追加の要素があってもよいことを意味する。
【００８０】
様々な変更を、本発明の態様の範囲を逸脱しないで、上記の構造、製品及び方法に行うことができるので、上記の説明に含まれかつ添付の図面に示された全ての内容は例示的であって限定の意味ではないと解釈されるべきである。
【技術分野】
【０００１】
本発明は、ＵＰｎＰ認証及び認可に関する。
【背景技術】
【０００２】
ＵＰｎＰ（Universal Plug and Play）アーキテクチャは、例えば電気器具、無線デバイス、エレクトロニクス、ポータブルメディアデバイスデバイス、及びパーソナルコンピュータなどの家庭用電子機器のネットワーク接続性を提供する。ＵＰｎＰは、ＴＣＰ／ＩＰ及びウェブ技術を利用して、近接ネットワークを可能にし、そして家庭、オフィス、及び公共の場のネットワーク化されたデバイスの間のデータ転送を制御する、分散オープンネットワークアーキテクチャである。ＵＰｎＰは、様々なベンダーからの広範囲に及ぶデバイスの種類に対して、ゼロ設定、「不可視」ネットワーク、及び自動発見をサポートするように設計される。デバイスは、動的にネットワークに参加し、ＩＰアドレスを取得し、自らの機能を伝え、他のデバイスのプレゼンス及び機能について知ることができる。また、ＵＰｎＰデバイスは、あとにいかなる望ましくない状態も残すことなしにネットワークを離脱することができる。
【０００３】
ＵＰｎＰモデルでは、全てのデバイスは、いわゆる「不可視」ネットワークを可能にするための任意の可能な要求を行うことを黙示的に認可されると仮定される。しかしながら、認証なしで、別のＵＰｎＰデバイスからＵＰｎＰ要求を受信するデバイスは、かかる要求を送信しているデバイスがかかる要求を行う権限を与えられているかどうかが分らない。ＵＰｎＰは、全てのデバイスが信頼できると仮定されるホームネットワークなどのために設計されたので、デバイスの認証及び認可は必要ではなかった。しかしながら、ホームネットワーク内でさえ、ＵＰｎＰにおける承認及び認可についてのサポートの欠落は問題がある可能性がある。例えば、共有ネットワークが、大学寄宿舎においてまたは無線技術（例えば、Ｗｉ−Ｆｉ）を利用している環境において実施されると仮定する。そのような場合、ＵＰｎＰに基づくファイルサーバの所有者は、ネットワークのサーバに記憶されているファイルへの無制限のアクセスを認めたくないかもしれない。所有者は、ネットワークにアクセスできる他の全てのＵＰｎＰデバイスを信頼することができないかもしれないからである。
【０００４】
別の例では、高解像度ビデオをストリーミングできるＵＰｎＰに基づくメディアサーバの製造業者が、ビデオコンテンツの標準解像度バージョンを他のデバイスにストリーミングしつつ、ライセンスされていてかつ高解像度ビデオコンテンツをレンダリングすることができるデバイスに、高解像度ビデオコンテンツへのアクセスを制限することを望むかもしれないと仮定する。換言すれば、ＵＰｎＰデバイスの製造業者は、同じ製造業者によって製造されたＵＰｎＰデバイスなどの一部のＵＰｎＰデバイスに、アクセスを許可することを望むかもしれない。
【０００５】
認証問題及び認可問題への既存の解決法は、不完全であるか、十分に安全ではないか、またはデジタル著作権管理（ＤＲＭ）システムに縛られている。例えば、認証問題に対する一般的な解決法は、１つまたは複数のＵＰｎＰメッセージにおいて人間が読める周知のストリングを探すことである。ストリングは、ユーザ‐エージェント間のプロトコルのヘッダ内にあってもよいし、または、ストリングは、デバイスディスクリプション文書、即ち、全てのＵＰｎＰデバイスからダウンロードすることができるＸＭＬフォーマットのドキュメントに埋め込まれてもよい。第２のＵＰｎＰデバイスを認証したい第１のＵＰｎＰデバイスは、これらのストリングのうちの１つのプレゼンスについて調べる。見出される場合、第１のＵＰｎＰデバイスは、第２のＵＰｎＰデバイスは認証されているとみなす。しかしながら、複製するのに瑣末な、はっきりと人間が読める形式でストリングが送信されるので、この解決法は安全ではない。
【０００６】
別の既存の解決法では、要求を受信するＵＰｎＰデバイスは、認可されたデバイスのアドレスのテーブルにおいてＵＰｎＰ要求のイーサネット（登録商標）ＭＡＣ（媒体アクセス制御）アドレスを調べる。要求側のデバイスのＭＡＣアドレスが見出される場合、デバイスは認可されているとみなされる。そうでなければ、受信するデバイスのユーザは、要求側のデバイスにアクセスを許可してそのアドレスをテーブルに加えるというオプションを与えられる。しかしながら、イーサネット（登録商標）ＭＡＣアドレスは「なりすまし」または偽造が相対的に容易であるので、この解決法は安全ではない。
【０００７】
更に、この解決法は、ＵＰｎＰデバイスが特定のライセンスされたまたは承認されたデバイスだけにアクセスを制限したいというシナリオにおいては実行不可能である。なぜならば、イーサネット（登録商標）ＭＡＣアドレスは、通常、ＵＰｎＰソフトウェアとは別個に製造されるハードウェアチップに記憶されるからである。承認されたデバイスのＭＡＣアドレスはソフトウェアが開発される時に分かっていないので、ソフトウェア製造業者が、認可されたイーサネット（登録商標）ＭＡＣアドレスのテーブルを生成することは通常、実行不可能である。更に、このシナリオでは、認可されたＭＡＣアドレスのテーブルにＭＡＣアドレスを加えるようにユーザに促すことは望ましくない。なぜならば、ユーザはライセンスされていないかまたは承認されていないデバイスへのアクセスを認めるかもしれないからである。
【０００８】
第３の解決法は、従来のＤＲＭシステムによって提供される。ＤＲＭシステムは、２つのデバイスが互いに認証して、暗号化された形式でオーディオコンテンツ／ビデオコンテンツを転送することを可能にするするが、この特殊化された解決法は、全てのシナリオにおいて適用可能ではない。例えば、ＤＲＭシステムに要求されているように、転送されているコンテンツを暗号化することが、いつも望ましいとは限らないかもしれない。また、いくつかのＤＲＭシステムは、オーディオコンテンツ／ビデオコンテンツを転送する間、安全な（暗号化に基づく）メッセージ交換を有するが、（ＵＰｎＰ ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスによる）コンテンツの発見は、この安全なメッセージ交換でカバーされていない。よって、第１のデバイスは、第１のデバイスが発見されたコンテンツをストリームする権限を与えられているかどうかを知ることなしに、第２のデバイスのＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービス内でコンテンツを発見するかもしれない。
【発明の概要】
【課題を解決するための手段】
【０００９】
本発明の実施形態は、互いのかつ他のＵＰｎＰエンドポイントを認証しかつ認可するためのＵＰｎＰデバイスに対する安全なサービスを提供することによって、公知のＵＰｎＰプロトコルの１つまたは複数の不備を克服する。本発明の態様によれば、ＵＰｎＰイニシエータデバイスは、ＵＰｎＰレスポンダデバイスに信頼された機関からの識別情報を含む要求を送信する。レスポンダは、信頼された機関を介してイニシエータデバイスの識別性を認証して、識別情報の関数としてデバイスを認可する。
【００１０】
別の態様では、本発明は、認証及び認可プロセスの間にセッション識別子を構築する。セッション識別子は、イニシエータへの応答に含まれ、イニシエータからの後続のＵＰｎＰ要求またはＨＴＴＰ要求と前のうまく完了した認可及び認証を適合させる。
【００１１】
ネットワーク化されたポータブルメディアデバイスのための安全な認証及び認可サービスに対するコンピュータ実行可能命令を有するコンピュータ可読媒体は、本発明の更なる態様を具体化する。あるいは、本発明の実施形態は、様々な他の方法及び装置を備えることができる。
【００１２】
この概要は、以下の詳細な説明において更に後述する単純化された形式の概念の選択を導くために提供されている。この概要は特許請求の範囲に記載された主題の重要な特徴または本質的な特徴を識別することを意図していないし、特許請求の範囲に記載された主題の範囲を決定する際の助けとして用いられることも意図していない。
【００１３】
他の特徴は、以下で一部が明らかになり、一部が指摘される。
【００１４】
対応する参照文字は、図面にわたって対応する部分を示す。
【図面の簡単な説明】
【００１５】
【図１】本発明の１つの実施形態による認証及び認可サービスについてのコンピュータシステム環境を示すブロック図である。
【図２】本発明の１つの実施形態によるイニシエータメッセージの生成を示す例示的なフロー図である。
【図３】本発明の１つの実施形態による応答メッセージの生成を示す例示的なフロー図である。
【図４】本発明の１つの実施形態による確認メッセージの生成を示す例示的なフロー図である。
【図５】本発明の１つの実施形態による開始メッセージのブロック図である。
【図６】本発明の実施形態による応答メッセージのブロック図である。
【図７】メディアサーバによってメディアレンダラを承認しかつ認可するコンピュータ実行可能構成要素を有するコンピュータ可読媒体を示す図である。
【図８】メディアサーバによってメディアレンダラを承認しかつ認可するコンピュータ実行可能構成要素を有するコンピュータ可読媒体を示す図である。
【発明を実施するための形態】
【００１６】
図面を参照すると、図１は、本発明の態様による認証及び認可サービスのためのシステムを示している。有利に、本発明の実施形態は、あるＵＰｎＰ（Universal Plug and Play）デバイスに、例えば、ＵＰｎＰプロトコル自体を変更することなしに拡張可能な方法でＵＰｎＰプロトコルに新規の安全なサービスを追加することによって、別のＵＰｎＰデバイスを認証しかつ認可することができるようにする。
【００１７】
１つの実施形態では、ＵＰｎＰデバイスは、ＵＰｎＰエンドポイントからの要求に応じて１つまたは複数のＵＰｎＰサービスを実行する。ＵＰｎＰエンドポイントも、ＵＰｎＰデバイスであってもよいということが理解されるべきである。例えば、第１のデバイスがＵＰｎＰサービスを実行する場合、それは明らかにＵＰｎＰデバイスである。その同じデバイスが第２のＵＰｎＰデバイスで実行されるＵＰｎＰサービスを要求する場合、第１のデバイスもまた、ＵＰｎＰエンドポイントの機能を果たす。示された実施形態では、イニシエータ１０２などのＵＰｎＰエンドポイント及びレスポンダ１０４などのＵＰｎＰデバイスは、同じＵＰｎＰネットワークのメンバである。ＵＰｎＰアーキテクチャは、デバイスが、動的にネットワークに参加し、ＩＰアドレスを取得し、その機能を伝え、他のデバイスのプレゼンス及び機能について知ることができるようにする。ＵＰｎＰデバイス、エンドポイントなどは、例えば家庭用電化製品、コンピュータデバイス、ホームオートメーションデバイス、ホームセキュリティデバイス、電気器具、ポータブルメディアデバイス、プリンティングデバイス、デジタルカメラ、スキャナ、コンピュータネットワークデバイス、モバイルデバイスなどの、ＵＰｎＰネットワークプロトコルを実行するいかなるデバイスをも含む。
【００１８】
本発明の１つの態様は、新規なＵＰｎＰハンドシェイクサービスを実行する。ハンドシェイクサービスは、ＵＰｎＰエンドポイント（例えば、イニシエータ１０２）及びＵＰｎＰデバイス(例えば、レスポンダ１０４）に、一方もしくはもう一方または互いに認証することができるようにする（即ち、安全な方法で互いの識別性を確立する）。一旦認証されると、各デバイスは、もう一方のデバイスがデバイスと通信する権限を与えられているかどうかを判断することができる。
【００１９】
１つの実施形態では、レスポンダ１０４は、例えばネットワーク上のイニシエータ１０２などのＵＰｎＰメディアレンダラデバイスに、メディアコンテンツを提供する汎用メディアサーバデバイスである。例えば、メディアサーバは、ポータブルメディアデバイス、ＶＣＲ、ＣＤプレーヤ、ＤＶＤプレーヤ、オーディオテーププレーヤ、静止画像カメラ、カムコーダ、ラジオ、ＴＶチューナ、及びセットトップボックスなどのデバイス、ＭＰ３サーバ、ＰＶＲ（パーソナルビデオレコーダ）、並びに、パーソナルコンピュータなどのホームメディアサービスを含む。実施中、イニシエータ１０２及びレスポンダ１０４は、本発明の態様を実行する図に示したコンピュータ実行可能命令などのコンピュータ実行可能命令を実行する。
【００２０】
イニシエータ１０２及びレスポンダ１０４は、通常、少なくともいくつかの形式のコンピュータ可読媒体を有している。揮発性媒体及び不揮発性媒体、着脱自在媒体及び固定式媒体の両方を含むコンピュータ可読媒体は、イニシエータ１０２及びレスポンダ１０４によってアクセスすることができるいかなる利用可能媒体であってもよい。例であって限定ではないが、コンピュータ可読媒体は、コンピュータ記憶媒体及び通信媒体を備える。コンピュータ記憶媒体は、例えばコンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報の記憶のためのいかなる方法または技術において実行される揮発性媒体及び不揮発性媒体、着脱自在媒体及び固定式媒体を含む。例えば、コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、もしくは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（Digital Versatile Disk）、もしくは他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、もしくはその他の磁気記憶デバイス、または所望の情報を記憶するために用いることができてかつイニシエータ１０２及びレスポンダ１０４によってアクセスすることができるいかなる他の媒体をも含む。通信媒体は、通常、コンピュータ可読命令、データ構造、プログラムモジュール、または、搬送波または他の搬送メカニズムなどの変調されたデータ信号内の他のデータを具体化し、かついかなる情報配信媒体をも含む。当業者は、変調されたデータ信号に精通しており、変調されたデータ信号は、１つまたは複数のその特徴を、信号内の情報を符号化するような方法で設定または変更した。例えば有線ネットワークまたは直接配線接続などの有線媒体、並びに、音響、ＲＦ、赤外線、及びその他の無線媒体などの無線媒体は、通信媒体の例である。上記のうちのいずれの組合せも、コンピュータ可読媒体の範囲内に含まれる。
【００２１】
メディアサーバは、ＵＰｎＰコンテンツディレクトリサービスを介してそのコンテンツを公開する。メディアサーバは、いかなる特定のタイプの媒体、いかなるデータフォーマット、及び転送プロトコルをも処理することができる。媒体コンテンツの例は、ＭＰＥＧ２ビデオ、ＣＤオーディオ、ＭＰ３オーディオ、ＷＭＡオーディオ、及びＪＰＥＧ画像を含む。
【００２２】
ＵＰｎＰサービスは、ＵＲＮ（Uniform Resource Name）で識別される。デバイスが他のデバイスによってホストされるサービスを検索するときに、または、デバイス自身がホストするサービスの可用性（availability）をデバイスが知らせるときに、ＵＲＮが用いられる。ハンドシェイクサービス用のＵＲＮは、任意に選択することができる。本発明の１つの実施形態では、「ｕｒｎ：ｓｃｈｅｍａｓ−ｍｉｃｒｏｓｏｆｔ−ｃｏｍ：ｓｅｒｖｉｃｅ：Ｈａｎｄｓｈａｋｅ：ｌ」が、ハンドシェイクサービス用のＵＲＮである。
【００２３】
安全なＵＰｎＰデバイスだけが、認証されかつ認可された他のＵＰｎＰデバイス及びエンドポイントからの通信を受け入れる。よって、安全なＵＰｎＰデバイスが第２のデバイスに安全なデバイスによって実行される任意の他のＵＰｎＰサービスにアクセスすることができるようにする前に、ハンドシェイクサービスが第２のデバイスをうまく認証しかつ認可することを安全なＵＰｎＰデバイスは必要とする。
【００２４】
１つの実施形態では、別のＵＰｎＰデバイスによってホストされるサービスを要求するＵＰｎＰエンドポイントは、イニシエータ１０２と称される。例えば、メディアレンダラデバイスがメディアサーバデバイスによって提供される利用可能なコンテンツのリストを要求する場合、メディアレンダラは、メディアサーバデバイスによってホストされるＵＰｎＰ ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスに、要求を送信する。この例では、メディアレンダラがＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスと通信するときにメディアレンダラがイニシエータ１０２であり、メディアサーバデバイスがレスポンダ１０４と称される。
【００２５】
しかしながら、同じメディアレンダラデバイスがまた、それ自体のＵＰｎＰサービスをホストすることもできる。この場合、メディアレンダラは、ＵＰｎＰデバイスとしてもＵＰｎＰエンドポイントとしても動作している。メディアサーバがそれらのサービスのうちのいずれかを利用することを決定する場合、役割は逆転し、メディアサーバはイニシエータ１０２でありかつメディアレンダラはレスポンダ１０４である。１つの実施形態では、メディアレンダラによって開始されたメディアサーバへのハンドシェイク及びメディアサーバによって開始されたメディアレンダラへのハンドシェイクは、２つの完全に独立した動作として処理される。
【００２６】
ＵＰｎＰプロトコルは、ＵＰｎＰプロトコルが通信したいデバイスを見つけるための２つの標準的な方法をイニシエータ１０２に提供する。第１に、イニシエータ１０２は、Ｍ−ＳＥＡＲＣＨ要求を放送し、Ｍ−ＳＥＡＲＣＨ要求は、Ｍ−ＳＥＡＲＣＨ要求内のＵＲＮによって識別されるＵＰｎＰサービスをサポートするネットワーク上の全てのＵＰｎＰデバイスから応答を求める。第２に、イニシエータ１０２はＮＯＴＩＦＹメッセージを聞く（listen）。全てのＵＰｎＰデバイスは、それらがホストするサービスの可用性（availability）を知らせるＮＯＴＩＦＹメッセージを周期的に送信する。
【００２７】
１つの実施形態では、ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスを実行するＵＰｎＰデバイスを検索するメディアレンダラデバイスは、Ｍ−ＳＥＡＲＣＨ及び／またはＮＯＴＩＦＹメッセージを用いてＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスを見つけることになる。メディアレンダラはまた、Ｍ−ＳＥＡＲＣＨ及び／またはＮＯＴＩＦＹメッセージを用いて、サービスのＵＲＮで識別されるハンドシェイクサービスを見つける。本実施形態では、同じＵＰｎＰデバイスがハンドシェイクサービスもＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスもホストする場合、メディアレンダラはＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスと通信するだけである。そして、ハンドシェイクサービスが成功した場合、メディアレンダラはＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスを用いるだけである。ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスは実例的な目的として用いられ、ハンドシェイクサービスは、ＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｒサービスまたはＡＶＴｒａｎｓｐｏｒｔサービスなどの他のいかなるＵＰｎＰサービスの前に実行することができる。
【００２８】
代替的実施形態では、ハンドシェイクサービスは、共有秘密及び対称暗号鍵を構築する。共有秘密は、セキュリティトークン７０２を生成するために用いられて、セキュリティトークン７０２は、後続のＵＰｎＰ要求またはＨＴＴＰ要求において用いられて、要求がすでに認証されかつ認可されたデバイスからのものであることを証明することができる。セキュリティトークン７０２は、各要求に応じて変更されて、悪い（rogue）デバイスが認可されたデバイスになりすまそうとするのをより難しくすることができる。あるいは、デバイスのイーサネット（登録商標）ＭＡＣアドレスまたはＩＰアドレスを、すでに認証されたデバイスからの要求を識別するために用いることができる。しかしながら、上記に説明したように、この実行はより安全ではない。
【００２９】
図３-５に示した方法によって構築される対称暗号鍵を、デバイスが認可されたあとに転送されているコンテンツを暗号化するために用いることができる。このことは、追加のセキュリティの層を設けて、認可されていないデバイスが２つの相互に認可されたデバイス間の通信で盗聴できないようにする。例えば、上で述べられた高解像度ビデオストリームを、対称暗号鍵を用いて暗号化することができる。
【００３０】
１つの実施形態では、ハンドシェイクサービスに加えて、最初のハンドシェイクが実行された後に、新規のＨＴＴＰヘッダ及びＵＰｎＰヘッダが後続のＨＴＴＰ要求及びＵＰｎＰ要求において用いられる。あるいは、ＸＭＬに基づく構文が、ＵＰｎＰヘッダの代わりに用いられる。
【００３１】
ＵＰｎＰサービスは、動作及びイベントを有する。ハンドシェイクサービスは、２つの動作を含み、イベントを含まない。動作は、入力パラメータ及び出力パラメータを有するリモートプロシージャコールと同様である。１つの実施形態では、ハンドシェイクサービスを始めるために、イニシエータ１０２は、ＤｏＨａｎｄｓｈａｋｅ動作１０６を呼び出す。動作の名前は全く重要ではなくて、ＸＭＬ形式のＵＰｎＰサービスディスクリプションが名前を正しく記述する限り、異なっていてもよい。
【００３２】
１つの実施形態では、ＤｏＨａｎｄｓｈａｋｅ動作は、１つの入力パラメータ及び２つの出力パラメータを有する。本発明の本実施形態では、入力パラメータはイニシエータメッセージ５００であり、第１の出力パラメータはレスポンダメッセージ６００であり、第２の出力パラメータは要求識別子である。代替的実施形態では、イニシエータメッセージ５００、レスポンダメッセージ６００は一つのフォーマットである。さらに、ＵＰｎＰはテキストベースのプロトコルであるので、イニシエータメッセージ及びレスポンダメッセージは、ＵＰｎＰを越えて転送されると、ベース６４（Ｂａｓｅ６４）符号化される。
【００３３】
イニシエータメッセージ５００の目的は、レスポンダ１０４がイニシエータ１０２を認証することができるようにすることである。ＤｏＨａｎｄｓｈａｋｅ動作１０６は、イニシエータ１０２からレスポンダ１０４へイニシエータメッセージ５００を送信する。図５に示した実施形態では、イニシエータメッセージ５００は証明書５０２を含み、公開鍵暗号法が認証のために用いられる。証明書は、デジタル署名を用いて、例えばデバイスモデル番号及びシリアル番号などのイニシエータ１０２の識別情報５０６に公開鍵５０４を結びつける。証明書を、公開鍵５０４がイニシエータ１０２に属していることを検証するために用いることができる。典型的な公開鍵インフラストラクチャスキームでは、署名は信頼された機関からのものだろう。レスポンダ１０４は、署名を検証して、証明書が本物であることを確認することができる。有利に、レスポンダ１０４は、異なるイニシエータ１０２間で区別することができて、証明書５０２に含まれた情報を用いることにより各イニシエータ１０２を個々に認可することができるだろう。例えば、レスポンダ１０４は、高解像度ビデオコンテンツをストリーミングすることができるだけであると仮定する。レスポンダ１０４は、証明書５０２からデバイスモデル番号を調べて、イニシエータ１０２が高解像度ビデオコンテンツをレンダリングすることができるかどうかを判断する。イニシエータ１０２が高解像度ビデオコンテンツをレンダリングすることができる場合、レスポンダ１０４はイニシエータ１０２を認可する。
【００３４】
代替的実施形態では、証明書はイニシエータの公開鍵５０４を含む。公開鍵５０４で暗号化されたメッセージは、適合している秘密鍵を用いて解読することができるだけである。適合している秘密鍵はイニシエータ１０２だけに知られている。本実施形態では、イニシエータメッセージ５００は、証明書５０２だけでなく、ＤｏＨａｎｄｓｈａｋｅ動作が呼び出されるたびに異なっている乱数５０８も含む。乱数５０８は、レスポンダ１０４によって用いられて、共有秘密を生成する。あるいは、乱数５０８は、数字及び文字の任意の生成された組合せである。
【００３５】
１つの実施形態では、レスポンダメッセージ６００は、レスポンダ１０４がイニシエータメッセージ５００において証明書５０２を認証することができたという指示である。図６に示した代替的実施形態では、レスポンダメッセージ６００は、レスポンダ１０４の証明書６０２を含んで、イニシエータ１０２がレスポンダ１０４を認証することができるようにする。証明書６０２はまた、レスポンダ１０４の識別情報６０６もレスポンダの公開鍵６０４も含む。ＤｏＨａｎｄｓｈａｋｅ動作の応答１０８は、イニシエータ１０２からレスポンダ１０４へレスポンダメッセージ６００及び要求識別子を送信する。
【００３６】
上で説明されたように、証明書６０２は、信頼された機関によって直接または間接的にデジタル署名される。さらに、この署名を検証することによって、イニシエータ１０２はレスポンダ１０４を認証することができる。さらに、レスポンダの証明書６０２は、イニシエータの公開鍵を用いる方法で暗号化される。１つの代替的実施形態では、レスポンダメッセージ６００の暗号化された部分は、ＤｏＨａｎｄｓｈａｋｅ動作が呼び出されるたびに異なる乱数６０８を含む。あるいは、乱数６０８は、数字及び文字の任意の生成された組合せである。
【００３７】
１つの実施形態では、第２の出力パラメータ、即ち、要求識別子は、後続のＵＰｎＰ要求またはＨＴＴＰ要求と前のうまく完了したＤｏＨａｎｄｓｈａｋｅ動作を適合させるために用いられる。うまく完了したＤｏＨａｎｄｓｈａｋｅ動作を有するイニシエータデバイスのイーサネット（登録商標）ＭＡＣアドレスをレスポンダ１０４が記録する実施形態では、更なる要求はイーサネット（登録商標）ＭＡＣアドレスだけに基づいて受け入れられるかまたは拒絶されるので、要求識別子は用いられない。要求識別子を利用する実施形態では、要求識別子は、レスポンダ１０４によって生成される。１つの実施形態では、要求識別子は乱数である。あるいは、要求識別子は、数字及び文字の任意の生成された組合せである。しかしながら、本実施形態では、レスポンダ１０４は、イニシエータ１０２がレスポンダメッセージ６００内の暗号化された証明書を実際に解読することができたかどうかを知らない。これを確認することができない状態で、異なるデバイスに対して実際に発行された証明書をイニシエータ１０２が用いたということもあり得る。
【００３８】
Ｃｏｎｆｉｒｍ動作と称される、ＵＰｎＰハンドシェイクサービスの第２の動作は、レスポンダ１０４が、イニシエータ１０２がレスポンダメッセージ６００の証明書を解読することができたということを確認できるようにする。Ｃｏｎｆｉｒｍ動作１１０は、イニシエータ１０２からレスポンダ１０４へ確認メッセージ７００を送信する。
【００３９】
Ｃｏｎｆｉｒｍ動作１１０は、２つの入力パラメータを有し、かつ（成功／失敗指示１１２以外の）出力パラメータを有していない。第１の入力パラメータは、ＤｏＨａｎｄｓｈａｋｅ動作の応答１０８においてレスポンダ１０４がイニシエータ１０２に与えた要求識別子である。１つの実施形態では、要求識別子は、限られた期間有効なだけである。期限切れになった要求識別子を用いてＣｏｎｆｉｒｍ動作を呼び出そうとすることは、この動作に失敗の指示を返させる。
【００４０】
図７において、確認メッセージ７００は、第２の入力パラメータを具体化する。本実施形態では、確認メッセージ７００は、セキュリティトークン７０２を含む。１つの実施形態では、セキュリティトークン７０２は、共有秘密７０２のダイジェストである。１つの代替的実施形態では、セキュリティトークン７０２は、レスポンダ１０４及びイニシエータ１０２に知られており、かつ例えば共有秘密から得られる暗号鍵を用いて暗号化された数字である。１つの実施形態では、確認メッセージ７００は、バイナリ形式で記憶される。共有秘密は、イニシエータメッセージ５００内の乱数５０８及びレスポンダメッセージ６００内の乱数６０８を用いて得られる。レスポンダメッセージ６００内の乱数６０８が暗号化されたので、イニシエータ１０２が確認メッセージ７００内に正しいセキュリティトークン７０２を含む場合、イニシエータ１０２はレスポンダメッセージ６００の暗号化された部分を解読することができたということが分かる。成功または失敗の指示１１２は、レスポンダ１０４からイニシエータ１０２に送信される。
【００４１】
セキュリティトークン７０２は、確認メッセージ７００の平文で送信されない。１つの実施形態では、セキュリティトークン７０２は、レスポンダ及びイニシエータの両方に知られていてかつ例えば、共有秘密から得られる暗号鍵を用いて暗号化された数字である。あるいは、セキュリティトークン７０２は、共有秘密のダイジェスト（ハッシュ）である。ＣＰＵ資源を最小にするのを望む１つの実施形態では、ハッシュが実行される。なぜならば、ハッシュは通常、暗号化アルゴリズムより計算するのに少ないＣＰＵ資源を必要とするからである。
【００４２】
代替的実施形態では、２つの乱数５０８、６０８もまた用いられて、対称暗号鍵を得ることができる。鍵は、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）などの、いくつかの適当な暗号化アルゴリズムと共に用いられて、シェークハンド動作が完了した後に送信されるＵＰｎＰトラフィック及び／またはＨＴＴＰトラフィックを暗号化する。例えば、この暗号鍵を用いてメディアサーバからダウンロードされるかまたはストリームされるコンテンツを暗号化することが望ましい可能性がある。
【００４３】
１つの実施形態では、レスポンダ１０４は、イニシエータ１０２デバイスのイーサネット（登録商標）ＭＡＣアドレスを記録することができて、ハンドシェイクを通過したデバイスのテーブルにそれを加えかつ／または（デバイスがまたうまく認可されたと仮定すると）認可されたデバイスのテーブルにそれを加えることができる。後続のＵＰｎＰ要求及びＨＴＴＰ要求は、ＭＡＣアドレスが認可されたデバイステーブル内にあるかどうかに基づいて受け入れられるかまたは拒絶されることになる。
【００４４】
本発明の別の実施形態では、要求識別子パラメータがセッション識別子の役割を担う。本実施形態では、セッション識別子は後続のＵＰｎＰ要求及びＨＴＴＰ要求において用いられて、要求はハンドシェイク作業を完了したデバイスからのものであるということをレスポンダ１０４に分かるようにする。
【００４５】
１つの実施形態では、セッション識別子パラメータは、前に述べた要求識別子と同一である。あるいは、セッション識別子パラメータは、セッショントークンを含む。セッショントークンは、第１の乱数及び第２の乱数の関数として生成されて、第１の生成されたセッショントークンは第２の生成されたセッショントークンと等しくない。別の代替では、Ｃｏｎｆｉｒｍ動作は、１つの出力パラメータを用いて拡張される。新しい出力パラメータはセッション識別子であり、それはＣｏｎｆｉｒｍ動作が成功する場合に提供されるだけである。
【００４６】
本発明の代替的実施形態では、セッション識別子及びセキュリティトークン７０２は、ＵＰｎＰ要求及びＨＴＴＰ要求に含まれる。さらに別の実施形態では、セキュリティトークン７０２は、各要求において異なっている。ある代替では、セキュリティトークン７０２は数字から得られ、イニシエータ１０２及びレスポンダ１０４の両方は各ＵＰｎＰ要求またはＨＴＴＰ要求に応じて数字をインクリメントする。あるいは、セキュリティトークン７０２は同じままであり、追加の数字（例えば、現在の時刻）がダイジェストにおいて算出される。追加の数字は、各ＵＰｎＰ要求またはＨＴＴＰ要求に応じてインクリメントされるかまたは異なっている。
【００４７】
ＵＰｎＰでは、プロトコルヘッダはＨＴＴＰヘッダと同じ構文を用いるので、両方のプロトコルに有効である単一のプロトコルヘッダを定義することが可能である。１つの実施形態では、セッション識別子及び秘密のダイジェストは、ＡＢＮＦ（augmented Backus-Naur form）構文を利用しているＵＰｎＰヘッダ／ＨＴＴＰヘッダに含まれる。
【００４８】
“Ｘ‐Ｈａｎｄｓｈａｋｅ‐Ｉｄ：”＜ｓｅｓｓｉｏｎ‐ｉｄ＞“：”＜ｂａｓｅ６４‐ｅｎｃｏｄｅｄ‐ｄｉｇｅｓｔ‐ｏｆ‐ｓｅｃｒｅｔ＞
【００４９】
＜ｓｅｓｓｉｏｎ‐ｉｄ＞フィールドは、前に言及されたセッション識別子パラメータであり、＜ｂａｓｅ６４‐ｅｎｃｏｄｅｄ‐ｄｉｇｅｓｔ‐ｏｆ‐ｓｅｃｒｅｔ＞フィールドは、ベース６４符号化が用いられてそれをＡＳＣＩＩ表現に変換した後に、共有秘密を通じて算出されるダイジェスト（ハッシュ）である。
【００５０】
例：
Ｘ−Ｈａｎｄｓｈａｋｅ‐Ｉｄ：１２３４５：ａｂ０ｆｌ２ｃｄ４５ｅｅｆｌ
【００５１】
（ベース６４符号化ダイジェストは、説明の目的のためにここに示されていて、実際にはより大きいだろう。）本発明の別の変化形では、上で定義された“Ｘ−Ｈａｎｄｓｈａｋｅ‐Ｉｄ”ヘッダのようなヘッダは、ＨＴＴＰ要求のために用いられるだけである。
【００５２】
あるいは、ＵＰｎＰ要求について、情報はＵＰｎＰ要求メッセージ内に埋め込まれる。以下は、ＸＭＬ構文の例である。
【００５３】
＜ｍｓｈ：ｈａｎｄｓｈａｋｅ ｘｍｌｎｓ：ｍｓｈ＝“ｓｃｈｅｍａｓ‐ｍｉｃｒｏｓｏｆｔ‐ｃｏｍ：Ｈａｎｄｓｈａｋｅ‐ｌ‐０”ｍｓｈ：ｉｄ＝“１２３４５”＞
Ａｂ０ｆｌ２ｃｄ４５ｅｅｆｌ
＜／ｍｓｈ：ｈａｎｄｓｈａｋｅ＞
【００５４】
ここで図２を参照すると、図は、本発明の実施形態によるイニシエータメッセージの生成を示す。２０２で、第１のポータブルメディアデバイスは、ホストされたＵＰｎＰサービスの可用性を知らせるネットワークを介してメッセージを放送する。代替的実施形態では、ネットワークはピアツーピアネットワークである。別の実施形態では、第１のポータブルメディアデバイスはＵＰｎＰコントロールポイントを備え、第２のポータブルメディアデバイスはＵＰｎＰメディアレンダラを備える。あるいは、第１のポータブルメディアデバイスはＵＰｎＰメディアレンダラを備え、第２のポータブルメディアデバイスはＵＰｎＰコントロールポイントを備える。サービスは、ハンドシェイクサービス及び例えばコンテンツディレクトリサービスなどの少なくとも１つの追加のＵＰｎＰサービスを含む。１つの実施形態では、第１のポータブルメディアデバイスは、そのホストされたサービスの可用性を知らせるＵＰｎＰ ＮＯＴＩＦＹメッセージを周期的に放送する。代替的実施形態では、第２のポータブルメディアデバイスは、ハンドシェイクサービスについてのＵＰｎＰ Ｍ−ＳＥＡＲＣＨ要求を放送する。それは、Ｍ−ＳＥＡＲＣＨ要求内のＵＲＮによって識別されるハンドシェイクサービスをサポートしているネットワーク上の全てのＵＰｎＰデバイスからの応答を求めている。
【００５５】
２０４において、第２のポータブルメディアデバイスは、第１の乱数を生成する。代替のものでは、乱数は文字及び数字のいかなる組合せであってもよい。１つの実施形態では、第１のポータブルメディアデバイスはレスポンダなどのＵＰｎＰデバイスであり、第２のポータブルメディアデバイスは図１に示したイニシエータなどのＵＰｎＰエンドポイントである。代替的実施形態では、第２のポータブルメディアデバイスもＵＰｎＰデバイスである。別の実施形態では、乱数は、第１のポータブルメディアデバイスへの要求に含まれて、デバイス間の更なる通信の対称暗号化に用いることができる共有秘密を生成するために用いられるだろう。あるいは、乱数は、デバイス間の更なる通信に含まれるセッション識別子を構築するために用いられる。
【００５６】
２０６において、第２のポータブルメディアデバイスは、識別情報及びデジタル署名を第１のポータブルメディアデバイスへの要求にフォーマットする。１つの実施形態では、第２のポータブルメディアデバイスは、公開鍵‐非公開鍵対のうちの非公開鍵を用いて信頼された機関からの証明書及び第１の乱数に署名する。証明書は第２のポータブルメディアデバイスの識別情報を含み、下記のうちの少なくとも１つを含む。即ち、デバイスのデバイスモデル番号、デバイスのシリアル番号、及びデバイスでサポートされるメディアフォーマットのリストである。代替的実施形態では、要求に含まれるデータは、図５に示されるバイナリのイニシエータメッセージにフォーマットされる。
【００５７】
２０８において、第２のポータブルメディアデバイスは、ハンドシェイクサービスをホストしている第１のポータブルメディアデバイスにネットワークを介して要求を送信する。ローカルエリアネットワーク環境において用いられると、第１のポータブルメディアデバイス及び第２のポータブルメディアデバイスは、ネットワークインタフェースまたはアダプタを通じてＬＡＮに接続される。広域ネットワーク環境において用いられると、第１のポータブルメディアデバイス及び第２のポータブルメディアデバイスは、インターネットなどのＷＡＮを越えて通信を確立するネットワークカードまたは他の手段を通常含む。ネットワーク環境内の接続は、有線ネットワークまたは直接配線接続、並びに、Ｗｉ‐Ｆｉ、音響、ＲＦ、赤外線、及び他の無線媒体などの無線媒体であってもよい。示されたネットワーク接続は、例示的であり、第１のポータブルメディアデバイスと第２のポータブルメディアデバイスとの間の通信リンクを確立する他の手段が用いられてもよい。
【００５８】
ここで、図３を参照すると、第１のポータブルメディアデバイスは、第２のポータブルメディアデバイスから要求を受信する。次に、第１のポータブルメディアデバイスは、３０２‐３０９において第２のポータブルメディアデバイスのデジタル署名の関数として、第２のポータブルメディアデバイスを認証する。認証は、第２のポータブルメディアデバイスの識別性を証明する。
【００５９】
３０２において、第１のポータブルメディアデバイスは、デジタル署名が第２のポータブルメディアデバイスからであるということを検証する。１つの実施形態では、イニシエータメッセージに含まれる署名された証明書は、信頼された機関によって検証される。デジタル署名が検証されない場合、第１のポータブルメディアデバイスは３０４においてセッションをやめて、３０６において第２のポータブルメディアデバイスとの接続を終了する。３０８において、第１のポータブルメディアデバイスは、イニシエータメッセージに含まれる証明書が信頼された機関からであるかどうかを調べる。証明書が信頼された機関からでない場合、第１のポータブルメディアデバイスは３０４においてセッションをやめて、３０６において第２のポータブルメディアデバイスとの接続を終了する。
【００６０】
一旦デバイスが認証されると、３０９において、第１のポータブルメディアデバイスは、証明書の識別情報の関数として、第２のポータブルメディアデバイスを認可する。代替的実施形態では、第１のポータブルメディアは、第２のポータブルメディアデバイスにクエリして、第２のポータブルメディアデバイスでサポートされるメディアフォーマットのリストを得る。本実施形態では、第２のデバイスが少なくとも１つの互換性のあるフォーマットをサポートする場合、第１のポータブルメディアデバイスは第２のポータブルメディアデバイスを認可する。第２のポータブルメディアデバイスが認可されない場合、第１のポータブルメディアデバイスは３０４でセッションをやめて、３０６で第２のポータブルメディアデバイスとの接続を終了する。
【００６１】
有利に、第１のポータブルメディアは、ライセンスされたまたは承認されたデバイスに対して認可を通してそのサービスへのアクセスを制限することができる。例えば、第１のポータブルメディアデバイスは高解像度ビデオをストリームするだけのサービスをホストすると仮定する。第１のポータブルメディアデバイスは、それが高解像度ビデオコンテンツをレンダリングすることができる場合に、第２のポータブルメディアデバイスを認可するだけだろう。第１のポータブルメディアデバイスは、第２のポータブルメディアデバイスが高解像度ビデオコンテンツをレンダリングすることができるかどうかを第２のポータブルメディアデバイスの識別情報（例えばモデル番号、シリアル番号、及びサポートされるメディアフォーマット）によって判定する。
【００６２】
１つの実施形態では、第１のポータブルメディアデバイスは、テーブル内に認証されかつ認可された第２のポータブルメディアデバイスのＭＡＣイーサネット（登録商標）アドレスを記録する。本実施形態では、第１のポータブルメディアデバイスは、そのイーサネット（登録商標）ＭＡＣアドレスが記録されたデバイスからホストされたサービスに対する要求を受け入れるだけであり、方法は終了する。
【００６３】
あるいは、図３を再び参照すると、３１０において、第１のポータブルメディアデバイスは、第１の乱数を生成する。代替のものでは、乱数は文字及び数字の任意の組合せであることができる。３１２において、第１のポータブルメディアデバイスは、セキュリティトークン７０２を生成する。１つの実施形態では、セキュリティトークン７０２は、第１の乱数及び第２の乱数から生成される共有秘密のハッシュであり、第１の乱数及び第２の乱数を、デバイス間の更なる通信の対称暗号化（例えば、ＡＥＳ）のために用いることができまたはデバイス間の更なる通信に含まれるセッション識別子を構築するために用いることができる。
【００６４】
３１４において、第１のポータブルメディアデバイスは、証明書、デジタル署名、及び第２の乱数を第２のポータブルメディアデバイスへの応答にフォーマットする。１つの実施形態では、第１のポータブルメディアデバイスは、信頼された機関からの証明書に署名し、第２のポータブルメディアデバイスは、証明書及び署名を用いて第１のポータブルメディアデバイスを認証することができる。代替的実施形態では、要求に含まれるデータは、図６に示したレスポンダメッセージにフォーマットされる。
【００６５】
３１６において、第１のポータブルメディアデバイスは、対称暗号鍵（例えば、ＡＥＳ鍵）を選択して、３１８において、署名された証明書、第２の乱数、及びセキュリティトークン７０２を選択された鍵を用いて暗号化する。３２０において、第１のポータブルメディアデバイスは、第２のポータブルメディアデバイスの公開鍵を用いて選択されたＡＥＳ鍵を暗号化する。ＡＥＳ鍵は第２のポータブルメディアデバイスの公開鍵を用いて暗号化されるので、有利に、人間が読める認証ストリングは応答に含まれない。よって、第２のポータブルメディアデバイスの秘密鍵を有するデバイスだけが、第１のポータブルメディアデバイスの証明書及びハッシュを解読することができる。
【００６６】
３２０において、第１のポータブルメディアデバイスは、第２のポータブルメディアデバイスにネットワークを介して応答メッセージを送信する。代替的実施形態では、要求識別子は応答に含まれる。要求識別子は、第１のポータブルメディアデバイスによって用いられて、第２のポータブルメディアデバイスからの後続のＵＰｎＰ要求またはＨＴＴＰ要求と前のうまく完了した承認及び認可を適合させる。別の実施形態では、要求識別子は、第２のポータブルメディアデバイスが応答メッセージ内の証明書を解読することができたということを確認するために用いられる。本実施形態では、セッション識別子は、応答に含まれて、第２のポータブルメディアデバイスからの後続のＵＰｎＰ要求またはＨＴＴＰ要求と前のうまく完了した承認及び認可を適合させる。
【００６７】
ここで図４を参照すると、第２のポータブルメディアデバイスは、第１のポータブルメディアデバイスから応答を受信する。次に、第２のポータブルメディアデバイスは、４０２-４１２で第１のポータブルメディアデバイスのデジタル署名の関数として、第１のポータブルメディアデバイスを認証する。認証は、第１のポータブルメディアデバイスの識別性を確立する。１つの実施形態では、応答メッセージに含まれる署名された証明書は、信頼された機関によって検証される。
【００６８】
４０２において、第２のポータブルメディアデバイスは、その非公開鍵を用いて応答メッセージ内のＡＥＳ鍵を解読する。４０４において、第２のポータブルメディアデバイスは、解読されたＡＥＳ鍵を用いて第１のポータブルメディアデバイスの証明書を解読する。４０６において、第２のポータブルメディアデバイスは、デジタル署名が第１のポータブルメディアデバイスからであるということを検証する。デジタル署名が検証されない場合、第２のポータブルメディアデバイスは４０８においてセッションをやめて、４１０において第１のポータブルメディアデバイスとの接続を終了する。４１２において、第２のポータブルメディアデバイスは、応答メッセージに含まれる証明書が信頼された機関からであるかどうかを調べる。証明書が信頼された機関からでない場合、第２のポータブルメディアデバイスは、４０８でセッションをやめて、４１０において第１のポータブルメディアデバイスとの接続を終了する。
【００６９】
４１４において、一旦第１のポータブルメディアデバイスが認証されると、第２のポータブルメディアデバイスは、受信した要求識別子及び解読されたハッシュを含む確認を生成する。代替的実施形態では、確認に含まれるデータは、図７に示した確認メッセージにフォーマットされる。１つの実施形態では、少なくとも確認の一部は、第１のポータブルメディアデバイスの公開鍵によって暗号化される。代替的実施形態では、要求識別子は、限られた期間（例えば、１０秒）有効なだけである。要求識別子が期限切れになる前に、第２のポータブルメディアデバイスが第１のポータブルメディアデバイスに確認を送信しない場合、認証及び認可は失敗し、第２のポータブルメディアデバイスは、ステップ３０２において再びプロセスを開始しなければならない。４１６において、第２のポータブルメディアデバイスは、第１のポータブルメディアデバイスに確認を送信する。
【００７０】
４１８において、第１のポータブルメディアデバイスは、第１のポータブルメディアデバイスの秘密鍵を用いて第２のポータブルメディアデバイスから受信される確認メッセージを解読する。４２０において、第１のポータブルメディアデバイスは、第１の乱数及び第２の乱数からセキュリティトークン７０２を算出する。４２２において、第１のポータブルメディアデバイスは、算出されたセキュリティトークンを確認メッセージの解読されたセキュリティトークン７０２と比較する。２つのセキュリティトークンが等しくない場合、確認は失敗し、４０８において第１のポータブルメディアデバイスはセッションをやめて、４１０において第２のポータブルメディアデバイスとの接続を終了する。
【００７１】
４２４において、第１のポータブルメディアデバイスは、セッション識別子を生成する。セッション識別子は、第１のポータブルメディアデバイスによって用いられて、第２のポータブルメディアデバイスからの後続のＵＰｎＰ要求またはＨＴＴＰ要求と前のうまく完了した承認及び認可を適合させる。１つの実施形態では、セッション識別子は、要求識別子と等しい。代替的実施形態では、セッション識別子は要求識別子と異なる乱数値である。４２６において、第１のポータブルメディアデバイスはセッション識別子を第２のポータブルメディアデバイスに返して、第２のポータブルメディアデバイスの認証及び認可が完了したということを示す。
【００７２】
図８は、メディアサーバによってメディアレンダラを承認しかつ認可するコンピュータ実行可能構成要素を有するコンピュータ可読媒体を示す。１つの実施形態では、メディアレンダラ及びメディアサーバは、ＵＰｎＰデバイスである。あるいは、メディアレンダラ及びメディアサーバは、ポータブルメディアデバイスである。第３の代替のものでは、メディアレンダラは、ＵＰｎＰエンドポイントであり、メディアサーバはＵＰｎＰデバイスである。メディアサーバは、オープンネットワークにおいて１つまたは複数のＵＰｎＰサービスを実行する。１つの代替的実施形態では、ネットワークはピアツーピアネットワークである。構成要素は、インターフェース構成要素８０２、検証構成要素８０４、及びセキュリティ構成要素８０６を含む。
【００７３】
インターフェース構成要素８０２は、ネットワークを介してメディアレンダラから要求を受信する。要求は、メディアレンダラ及びデジタル署名の識別情報を含む開始メッセージと関連付けられる。さらに、インターフェース構成要素８０２は、メディアレンダラがメディアサーバによって認証されかつ認可されたかどうかを示している応答をメディアレンダラデバイスにネットワークを介して送信する。
【００７４】
検証構成要素８０４は、要求のデジタル署名の関数としてメディアレンダラを認証する。１つの実施形態では、デジタル署名は信頼された機関によって検証される。さらに、検証構成要素８０４は、要求の識別情報の関数として、メディアレンダラデバイスを認可する。１つの代替的実施形態では、メディアレンダラデバイスは、サポートされるメディアフォーマットのリストを得るためにクエリされる。本実施形態では、メディアレンダラデバイスは、それが少なくとも１つの互換性のあるフォーマットをサポートする場合に認可される。
【００７５】
セキュリティ構成要素８０６は、メディアレンダラが検証構成要素によって認可されて認証された場合、メディアサーバによって実行される１つまたは複数のサービスへのアクセスをメディアレンダラに許可し、メディアレンダラが検証構成要素によって認可されずかつ認証されなかった場合、メディアレンダラへのアクセスを拒否する。
【００７６】
説明の目的のために、プログラム、及び、例えばインターフェース構成要素８０２、検証構成要素８０４、及びセキュリティ構成要素８０６などの他の実行可能プログラム構成要素は、分離したブロックとして本明細書において示されている。しかしながら、かかるプログラム及び構成要素はＵＰｎＰデバイスの異なる記憶構成要素の様々な時間に存在して、デバイスのデータプロセッサ（または複数のデータプロセッサ）によって実行されるということが認識される。
【００７７】
特別の定めのない限り、本明細書において図示されて説明された本発明の実施形態における動作の実行順序または性能は、本質的ではない。即ち、特別の定めのない限り、動作はいかなる順番で実行されてもよく、本発明の実施形態は、本明細書において開示された動作以外の追加の動作またはそれより少ない動作を含んでいてもよい。例えば、別の動作より前に、別の動作と同時に、または別の動作の後で、特定の動作を実施しまたは実行することは、本発明の態様の範囲内にあると考えられる。
【００７８】
本発明の実施形態は、コンピュータ実行可能命令を用いて実行されてもよい。コンピュータ実行可能命令は、１つまたは複数のコンピュータ実行可能構成要素またはモジュールにまとめられてもよい。本発明の態様を、かかる構成要素またはモジュールのうちのいかなる数及び体系でも実行することができる。例えば、本発明の態様は、図に示して本明細書で説明された特定のコンピュータ実行可能命令または特定の構成要素もしくはモジュールに限定されない。本発明の他の実施形態は、本明細書において示しかつ説明されたよりも多くの機能またはより少ない機能を有する異なったコンピュータ実行可能命令または構成要素を含むことができる。
【００７９】
本発明の態様または本発明の実施形態の要素を導くときに、冠詞「ある（a）」、「ある（an）」、「この（the）」、及び「前記（said）」は、１つまたは複数の要素があることを意味することを意図している。用語「備える」、「含む」、及び「有する」は、包括的であることを意図し、リストされた要素以外の追加の要素があってもよいことを意味する。
【００８０】
様々な変更を、本発明の態様の範囲を逸脱しないで、上記の構造、製品及び方法に行うことができるので、上記の説明に含まれかつ添付の図面に示された全ての内容は例示的であって限定の意味ではないと解釈されるべきである。
【特許請求の範囲】
【請求項１】
オープンネットワークにおいてＵＰｎＰ（ユニバーサルプラグアンドプレイ）デバイス（１０４）とＵＰｎＰエンドポイント（１０２）との間に安全な接続を構築する方法であって、前記ＵＰｎＰデバイス（１０４）及び前記ＵＰｎＰエンドポイント（１０２）は前記ネットワークに動的に参加しかつ離脱することができ、前記方法は、
ＵＰｎＰデバイス（１０４）によって、ＵＰｎＰサービスの要求（５００）を受信するステップであって、前記要求は、前記ネットワークを介してＵＰｎＰエンドポイント（１０２）から受信され、前記要求（５００）は、前記ＵＰｎＰエンドポイント（１０２）と関連付けられた識別情報（５０６）及びデジタル署名を含むステップと、
前記ＵＰｎＰエンドポイント（１０２）の前記受信されたデジタル署名の関数として前記ＵＰｎＰエンドポイント（１０２）を前記ＵＰｎＰデバイス（１０４）によって認証して、前記ＵＰｎＰエンドポイント（１０２）の識別性を検証するステップと、
前記受信された識別情報（５０６)の関数として前記ＵＰｎＰエンドポイント（１０２）を前記ＵＰｎＰデバイス（１０４）によって認可して、前記ＵＰｎＰデバイス（１０４）によって実装される１つまたは複数のサービスへのアクセスを許可するステップと、
前記ＵＰｎＰエンドポイント（１０２）が前記ＵＰｎＰデバイス（１０４）によって認証されかつ認可されたかどうかを示す応答を、前記ＵＰｎＰデバイス（１０４）から前記ＵＰｎＰエンドポイント（１０２）へ送信するステップと
を備える方法。
【請求項２】
請求項１に記載の方法において、前記識別情報は、信頼された機関によって提供される証明書を備え、前記信頼された機関は、前記要求の前記デジタル署名を提供することを特徴とする方法。
【請求項３】
請求項２に記載の方法において、前記証明書は、前記ＵＰｎＰエンドポイントの公開鍵を含み、前記ＵＰｎＰエンドポイントの前記公開鍵を用いて前記ＵＰｎＰデバイスによって提供される前記応答の少なくとも一部を暗号化するステップを更に備えることを特徴とする方法。
【請求項４】
請求項１に記載の方法において、前記識別情報は、前記ＵＰｎＰエンドポイントのデバイスモデル番号、前記ＵＰｎＰエンドポイントのシリアル番号、及び前記ＵＰｎＰエンドポイントでサポートされるメディアフォーマットのリスト、のうちの１つまたは複数を含むことを特徴とする方法。
【請求項５】
請求項１に記載の方法において、前記応答は、前記ＵＰｎＰデバイスの証明書を含み、前記ＵＰｎＰデバイスの前記証明書を用いて前記ＵＰｎＰエンドポイントによって前記ＵＰｎＰデバイスを認証するステップを更に備えることを特徴とする方法。
【請求項６】
請求項１に記載の方法において、前記応答はセッション識別子を含み、前記セッション識別子は後続の要求に含まれることを特徴とする方法。
【請求項７】
請求項１に記載の方法において、前記要求は、前記ＵＰｎＰエンドポイントによって生成される第１の乱数を含み、前記応答は、前記ＵＰｎＰデバイスによって生成される第２の乱数を含み、前記応答は、前記ＵＰｎＰエンドポイントの公開鍵で暗号化されており、 前記ＵＰｎＰデバイスによって前記ＵＰｎＰエンドポイントから確認を受信するステップであって、前記確認は、前記第１の乱数の関数として前記ＵＰｎＰエンドポイントによって生成されるセキュリティトークン及び解読された第２の乱数を含み、前記第２の乱数は、前記ＵＰｎＰエンドポイントの非公開鍵を用いて解読され、前記ＵＰｎＰエンドポイントの前記非公開鍵は、前記ＵＰｎＰエンドポイントの前記公開鍵に対応するステップと、
前記確認の受信に応答して、前記セキュリティトークンの関数として前記ＵＰｎＰエンドポイントの前記認証及び前記認可を前記ＵＰｎＰデバイスによって確認するステップと
を更に備えることを特徴とする方法。
【請求項８】
請求項７に記載の方法において、
前記第１の乱数及び前記第２の乱数の関数として共有秘密を前記ＵＰｎＰエンドポイントによって生成するステップと、
前記共有秘密の関数として前記セキュリティトークンを前記ＵＰｎＰエンドポイントによって生成するステップと
を更に備えることを特徴とする方法。
【請求項９】
請求項８に記載の方法において、前記セキュリティトークンは、前記共有秘密のダイジェスト、及び、前記共有秘密から得られる暗号鍵を用いて暗号化されている前記ＵＰｎＰエンドポイント及び前記ＵＰｎＰデバイスに知られている値、のうちの１つまたは複数であることを特徴とする方法。
【請求項１０】
請求項７に記載の方法において、
前記ＵＰｎＰデバイスによってセッション識別子を生成するステップであって、前記セッション識別子は、前記ＵＰｎＰエンドポイントへの応答に含まれていて、前記セッション識別子は、前記ＵＰｎＰエンドポイントからの後続の要求にかつ前記ＵＰｎＰデバイスからの後続の応答に更に含まれているステップを更に備えることを特徴とする方法。
【請求項１１】
請求項１０に記載の方法において、前記セッション識別子は、セッショントークンを含み、前記第１の乱数及び前記第２の乱数の関数として前記セッショントークンを生成するステップを更に備え、第１の生成されたセッショントークンは、第２の生成されたセッショントークンとは等しくないことを特徴とする方法。
【請求項１２】
請求項１１に記載の方法において、前記セッション識別子及び前記セッショントークンは、ＸＭＬ要求、及びＵＰｎＰ要求のＨＴＴＰヘッダ、のうちの少なくとも１つに埋め込まれていることを特徴とする方法。
【請求項１３】
請求項１に記載の方法において、
前記ＵＰｎＰエンドポイントの前記承認及び前記認可の関数として前記ＵＰｎＰエンドポイントと関連付けられたアドレスを前記ＵＰｎＰデバイスによって記録するステップであって、前記アドレスは、前記ＵＰｎＰデバイスによって用いられて前記ＵＰｎＰエンドポイントからの後続の要求を識別するステップを更に備えることを特徴とする方法。
【請求項１４】
請求項１に記載の方法において、１つまたは複数のコンピュータ可読媒体は、請求項１に記載の前記方法を実行するためのコンピュータ実行可能命令を有することを特徴とする方法。
【請求項１５】
オープンネットワーク内の複数のＵＰｎＰ（ユニバーサルプラグアンドプレイ）ポータブルメディアデバイスの中で新規で安全なハンドシェイクサービスを構築する方法であって、前記ＵＰｎＰポータブルメディアデバイスのうちの１つまたは複数は前記ネットワークに動的に参加しかつ離脱することができ、前記方法は、
第１のポータブルメディアデバイスによってホストされるＵＰｎＰサービスの可用性を知らせるメッセージ（２０２）を前記ネットワークを介して送信するステップであって、前記サービスは、前記ハンドシェイクサービス及び少なくとも１つの追加のＵＰｎＰサービスを含むステップと、
前記ネットワークを介して第２のポータブルメディアデバイスから、前記ハンドシェイクサービスを開始する第１の要求（２０８）を前記第１のポータブルメディアデバイスによって受信するステップであって、前記要求は開始メッセージを含み、前記開始メッセージは、前記第２のポータブルメディアデバイスの識別情報及びデジタル署名を含むステップと、
前記第２のポータブルメディアデバイスの前記デジタル署名の関数として前記第２のポータブルメディアデバイスを前記第１のポータブルメディアデバイスによって認証するステップ（３０２）であって、前記認証するステップは、前記第２のポータブルメディアデバイスの識別性を確立するステップと、
前記要求の前記識別情報の関数として前記第２のポータブルメディアデバイスを前記第１のポータブルメディアデバイスによって認可するステップ（３０９）であって、前記認可するステップは、前記第２のポータブルメディアデバイスが前記第１のポータブルメディアデバイスとの通信を許可されているかどうかを判定するステップと、
前記第２のポータブルメディアデバイスが前記第１のポータブルメディアデバイスによって認証されかつ認可されているかどうかを示す応答を、前記第１のポータブルメディアデバイスによって前記ネットワークを介して前記第２のポータブルメディアデバイスに送信するステップ（３２２）と、
前記第１のポータブルによってホストされる少なくとも１つの追加のＵＰｎＰサービスに対する第２の要求を、前記第１のポータブルメディアデバイスによって前記第２のポータブルメディアデバイスから前記ネットワークを介して受信するステップ（４１６）と
を備え、
前記第２のポータブルメディアデバイスが前記第１のポータブルメディアデバイスにより認証されかつ認可されている場合に、前記第２のポータブルメディアデバイスは、前記第１のポータブルメディアデバイスでホストされる前記少なくとも１つの追加のＵＰｎＰサービスへのアクセスを許可され、
前記第２のポータブルメディアデバイスが前記第１のポータブルメディアデバイスによって認証されておらずかつ認可されていない場合に、前記第２のポータブルメディアデバイスは、前記第１のポータブルメディアデバイスでホストされる少なくとも１つの追加のＵＰｎＰサービスへの前記アクセスを許可されないことを特徴とする方法。
【請求項１６】
請求項１５に記載の方法であって、前記第１のポータブルメディアデバイスは、ＵＰｎＰコントロールポイントを備え、前記第２のポータブルメディアデバイスは、ＵＰｎＰメディアレンダラを備えることを特徴とする方法。
【請求項１７】
請求項１５に記載のシステムであって、前記第１のポータブルメディアデバイスは、ＵＰｎＰメディアレンダラを備え、前記第２のポータブルメディアデバイスは、ＵＰｎＰコントロールポイントを備えることを特徴とするシステム。
【請求項１８】
メディアサーバによってメディアレンダラを認可しかつ認証するコンピュータ実行可能構成要素を有する１つまたは複数のコンピュータ可読媒体であって、前記メディアサーバはオープンネットワークにおいて１つまたは複数のＵＰｎＰサービスを実行し、前記コンピュータ可読媒体は、
インターフェース構成要素（８０２）であって、
前記メディアレンダラからネットワークを介して要求を受信することであって、前記要求は開始メッセージを含み、前記開始メッセージは前記メディアレンダラの識別情報及びデジタル署名を含み、
前記メディアレンダラが前記メディアサーバによって認証されかつ認可されたかどうかを示す応答を、前記ネットワークを介してメディアレンダラデバイスに送信すること
のためのインターフェース構成要素と、
検証構成要素（８０４）であって、
前記メディアレンダラの前記デジタル署名の関数として前記メディアレンダラを認証し、前記認証することは、前記メディアレンダラの識別性を確立し、
前記要求の前記識別情報の関数として前記メディアレンダラを認可することであって、前記認可することは、前記メディアレンダラが前記メディアサーバとの通信を許可されているかどうかを判定すること
のための検証構成要素と、
セキュリティ構成要素（８０６）であって、
前記メディアレンダラが前記検証構成要素によって認可されかつ認証された場合に、前記メディアサーバによって実行される１つまたは複数のサービスへの前記メディアレンダラへのアクセスを許可し、
前記メディアレンダラが前記検証構成要素によって認可されずかつ認証されなかった場合に、前記メディアサーバによって実行される１つまたは複数のサービスへの前記メディアレンダラへのアクセスを拒否すること
のためのセキュリティ構成要素と
を備えることを特徴とするコンピュータ可読媒体。
【請求項１９】
請求項１８に記載のコンピュータ可読媒体において、前記メディアサーバによって送信される要求に応答して、前記メディアレンダラによって前記メディアサーバを認証しかつ認可するコンピュータ実行可能命令を更に備えることを特徴とするコンピュータ可読媒体。
【請求項２０】
請求項１８に記載のコンピュータ可読媒体において、前記メディアサーバ及び前記メディアレンダラは、ポータブルメディアデバイスであることを特徴とするコンピュータ可読媒体。
【請求項１】
オープンネットワークにおいてＵＰｎＰ（ユニバーサルプラグアンドプレイ）デバイス（１０４）とＵＰｎＰエンドポイント（１０２）との間に安全な接続を構築する方法であって、前記ＵＰｎＰデバイス（１０４）及び前記ＵＰｎＰエンドポイント（１０２）は前記ネットワークに動的に参加しかつ離脱することができ、前記方法は、
ＵＰｎＰデバイス（１０４）によって、ＵＰｎＰサービスの要求（５００）を受信するステップであって、前記要求は、前記ネットワークを介してＵＰｎＰエンドポイント（１０２）から受信され、前記要求（５００）は、前記ＵＰｎＰエンドポイント（１０２）と関連付けられた識別情報（５０６）及びデジタル署名を含むステップと、
前記ＵＰｎＰエンドポイント（１０２）の前記受信されたデジタル署名の関数として前記ＵＰｎＰエンドポイント（１０２）を前記ＵＰｎＰデバイス（１０４）によって認証して、前記ＵＰｎＰエンドポイント（１０２）の識別性を検証するステップと、
前記受信された識別情報（５０６)の関数として前記ＵＰｎＰエンドポイント（１０２）を前記ＵＰｎＰデバイス（１０４）によって認可して、前記ＵＰｎＰデバイス（１０４）によって実装される１つまたは複数のサービスへのアクセスを許可するステップと、
前記ＵＰｎＰエンドポイント（１０２）が前記ＵＰｎＰデバイス（１０４）によって認証されかつ認可されたかどうかを示す応答を、前記ＵＰｎＰデバイス（１０４）から前記ＵＰｎＰエンドポイント（１０２）へ送信するステップと
を備える方法。
【請求項２】
請求項１に記載の方法において、前記識別情報は、信頼された機関によって提供される証明書を備え、前記信頼された機関は、前記要求の前記デジタル署名を提供することを特徴とする方法。
【請求項３】
請求項２に記載の方法において、前記証明書は、前記ＵＰｎＰエンドポイントの公開鍵を含み、前記ＵＰｎＰエンドポイントの前記公開鍵を用いて前記ＵＰｎＰデバイスによって提供される前記応答の少なくとも一部を暗号化するステップを更に備えることを特徴とする方法。
【請求項４】
請求項１に記載の方法において、前記識別情報は、前記ＵＰｎＰエンドポイントのデバイスモデル番号、前記ＵＰｎＰエンドポイントのシリアル番号、及び前記ＵＰｎＰエンドポイントでサポートされるメディアフォーマットのリスト、のうちの１つまたは複数を含むことを特徴とする方法。
【請求項５】
請求項１に記載の方法において、前記応答は、前記ＵＰｎＰデバイスの証明書を含み、前記ＵＰｎＰデバイスの前記証明書を用いて前記ＵＰｎＰエンドポイントによって前記ＵＰｎＰデバイスを認証するステップを更に備えることを特徴とする方法。
【請求項６】
請求項１に記載の方法において、前記応答はセッション識別子を含み、前記セッション識別子は後続の要求に含まれることを特徴とする方法。
【請求項７】
請求項１に記載の方法において、前記要求は、前記ＵＰｎＰエンドポイントによって生成される第１の乱数を含み、前記応答は、前記ＵＰｎＰデバイスによって生成される第２の乱数を含み、前記応答は、前記ＵＰｎＰエンドポイントの公開鍵で暗号化されており、 前記ＵＰｎＰデバイスによって前記ＵＰｎＰエンドポイントから確認を受信するステップであって、前記確認は、前記第１の乱数の関数として前記ＵＰｎＰエンドポイントによって生成されるセキュリティトークン及び解読された第２の乱数を含み、前記第２の乱数は、前記ＵＰｎＰエンドポイントの非公開鍵を用いて解読され、前記ＵＰｎＰエンドポイントの前記非公開鍵は、前記ＵＰｎＰエンドポイントの前記公開鍵に対応するステップと、
前記確認の受信に応答して、前記セキュリティトークンの関数として前記ＵＰｎＰエンドポイントの前記認証及び前記認可を前記ＵＰｎＰデバイスによって確認するステップと
を更に備えることを特徴とする方法。
【請求項８】
請求項７に記載の方法において、
前記第１の乱数及び前記第２の乱数の関数として共有秘密を前記ＵＰｎＰエンドポイントによって生成するステップと、
前記共有秘密の関数として前記セキュリティトークンを前記ＵＰｎＰエンドポイントによって生成するステップと
を更に備えることを特徴とする方法。
【請求項９】
請求項８に記載の方法において、前記セキュリティトークンは、前記共有秘密のダイジェスト、及び、前記共有秘密から得られる暗号鍵を用いて暗号化されている前記ＵＰｎＰエンドポイント及び前記ＵＰｎＰデバイスに知られている値、のうちの１つまたは複数であることを特徴とする方法。
【請求項１０】
請求項７に記載の方法において、
前記ＵＰｎＰデバイスによってセッション識別子を生成するステップであって、前記セッション識別子は、前記ＵＰｎＰエンドポイントへの応答に含まれていて、前記セッション識別子は、前記ＵＰｎＰエンドポイントからの後続の要求にかつ前記ＵＰｎＰデバイスからの後続の応答に更に含まれているステップを更に備えることを特徴とする方法。
【請求項１１】
請求項１０に記載の方法において、前記セッション識別子は、セッショントークンを含み、前記第１の乱数及び前記第２の乱数の関数として前記セッショントークンを生成するステップを更に備え、第１の生成されたセッショントークンは、第２の生成されたセッショントークンとは等しくないことを特徴とする方法。
【請求項１２】
請求項１１に記載の方法において、前記セッション識別子及び前記セッショントークンは、ＸＭＬ要求、及びＵＰｎＰ要求のＨＴＴＰヘッダ、のうちの少なくとも１つに埋め込まれていることを特徴とする方法。
【請求項１３】
請求項１に記載の方法において、
前記ＵＰｎＰエンドポイントの前記承認及び前記認可の関数として前記ＵＰｎＰエンドポイントと関連付けられたアドレスを前記ＵＰｎＰデバイスによって記録するステップであって、前記アドレスは、前記ＵＰｎＰデバイスによって用いられて前記ＵＰｎＰエンドポイントからの後続の要求を識別するステップを更に備えることを特徴とする方法。
【請求項１４】
請求項１に記載の方法において、１つまたは複数のコンピュータ可読媒体は、請求項１に記載の前記方法を実行するためのコンピュータ実行可能命令を有することを特徴とする方法。
【請求項１５】
オープンネットワーク内の複数のＵＰｎＰ（ユニバーサルプラグアンドプレイ）ポータブルメディアデバイスの中で新規で安全なハンドシェイクサービスを構築する方法であって、前記ＵＰｎＰポータブルメディアデバイスのうちの１つまたは複数は前記ネットワークに動的に参加しかつ離脱することができ、前記方法は、
第１のポータブルメディアデバイスによってホストされるＵＰｎＰサービスの可用性を知らせるメッセージ（２０２）を前記ネットワークを介して送信するステップであって、前記サービスは、前記ハンドシェイクサービス及び少なくとも１つの追加のＵＰｎＰサービスを含むステップと、
前記ネットワークを介して第２のポータブルメディアデバイスから、前記ハンドシェイクサービスを開始する第１の要求（２０８）を前記第１のポータブルメディアデバイスによって受信するステップであって、前記要求は開始メッセージを含み、前記開始メッセージは、前記第２のポータブルメディアデバイスの識別情報及びデジタル署名を含むステップと、
前記第２のポータブルメディアデバイスの前記デジタル署名の関数として前記第２のポータブルメディアデバイスを前記第１のポータブルメディアデバイスによって認証するステップ（３０２）であって、前記認証するステップは、前記第２のポータブルメディアデバイスの識別性を確立するステップと、
前記要求の前記識別情報の関数として前記第２のポータブルメディアデバイスを前記第１のポータブルメディアデバイスによって認可するステップ（３０９）であって、前記認可するステップは、前記第２のポータブルメディアデバイスが前記第１のポータブルメディアデバイスとの通信を許可されているかどうかを判定するステップと、
前記第２のポータブルメディアデバイスが前記第１のポータブルメディアデバイスによって認証されかつ認可されているかどうかを示す応答を、前記第１のポータブルメディアデバイスによって前記ネットワークを介して前記第２のポータブルメディアデバイスに送信するステップ（３２２）と、
前記第１のポータブルによってホストされる少なくとも１つの追加のＵＰｎＰサービスに対する第２の要求を、前記第１のポータブルメディアデバイスによって前記第２のポータブルメディアデバイスから前記ネットワークを介して受信するステップ（４１６）と
を備え、
前記第２のポータブルメディアデバイスが前記第１のポータブルメディアデバイスにより認証されかつ認可されている場合に、前記第２のポータブルメディアデバイスは、前記第１のポータブルメディアデバイスでホストされる前記少なくとも１つの追加のＵＰｎＰサービスへのアクセスを許可され、
前記第２のポータブルメディアデバイスが前記第１のポータブルメディアデバイスによって認証されておらずかつ認可されていない場合に、前記第２のポータブルメディアデバイスは、前記第１のポータブルメディアデバイスでホストされる少なくとも１つの追加のＵＰｎＰサービスへの前記アクセスを許可されないことを特徴とする方法。
【請求項１６】
請求項１５に記載の方法であって、前記第１のポータブルメディアデバイスは、ＵＰｎＰコントロールポイントを備え、前記第２のポータブルメディアデバイスは、ＵＰｎＰメディアレンダラを備えることを特徴とする方法。
【請求項１７】
請求項１５に記載のシステムであって、前記第１のポータブルメディアデバイスは、ＵＰｎＰメディアレンダラを備え、前記第２のポータブルメディアデバイスは、ＵＰｎＰコントロールポイントを備えることを特徴とするシステム。
【請求項１８】
メディアサーバによってメディアレンダラを認可しかつ認証するコンピュータ実行可能構成要素を有する１つまたは複数のコンピュータ可読媒体であって、前記メディアサーバはオープンネットワークにおいて１つまたは複数のＵＰｎＰサービスを実行し、前記コンピュータ可読媒体は、
インターフェース構成要素（８０２）であって、
前記メディアレンダラからネットワークを介して要求を受信することであって、前記要求は開始メッセージを含み、前記開始メッセージは前記メディアレンダラの識別情報及びデジタル署名を含み、
前記メディアレンダラが前記メディアサーバによって認証されかつ認可されたかどうかを示す応答を、前記ネットワークを介してメディアレンダラデバイスに送信すること
のためのインターフェース構成要素と、
検証構成要素（８０４）であって、
前記メディアレンダラの前記デジタル署名の関数として前記メディアレンダラを認証し、前記認証することは、前記メディアレンダラの識別性を確立し、
前記要求の前記識別情報の関数として前記メディアレンダラを認可することであって、前記認可することは、前記メディアレンダラが前記メディアサーバとの通信を許可されているかどうかを判定すること
のための検証構成要素と、
セキュリティ構成要素（８０６）であって、
前記メディアレンダラが前記検証構成要素によって認可されかつ認証された場合に、前記メディアサーバによって実行される１つまたは複数のサービスへの前記メディアレンダラへのアクセスを許可し、
前記メディアレンダラが前記検証構成要素によって認可されずかつ認証されなかった場合に、前記メディアサーバによって実行される１つまたは複数のサービスへの前記メディアレンダラへのアクセスを拒否すること
のためのセキュリティ構成要素と
を備えることを特徴とするコンピュータ可読媒体。
【請求項１９】
請求項１８に記載のコンピュータ可読媒体において、前記メディアサーバによって送信される要求に応答して、前記メディアレンダラによって前記メディアサーバを認証しかつ認可するコンピュータ実行可能命令を更に備えることを特徴とするコンピュータ可読媒体。
【請求項２０】
請求項１８に記載のコンピュータ可読媒体において、前記メディアサーバ及び前記メディアレンダラは、ポータブルメディアデバイスであることを特徴とするコンピュータ可読媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公表番号】特表２０１０−５０７２８５（Ｐ２０１０−５０７２８５Ａ）
【公表日】平成２２年３月４日（２０１０．３．４）
【国際特許分類】
【出願番号】特願２００９−５３２５５５（Ｐ２００９−５３２５５５）
【出願日】平成１９年１０月１０日（２００７．１０．１０）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０８０９５２
【国際公開番号】ＷＯ２００８／０４８８３６
【国際公開日】平成２０年４月２４日（２００８．４．２４）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公表日】平成２２年３月４日（２０１０．３．４）
【国際特許分類】
【出願日】平成１９年１０月１０日（２００７．１０．１０）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０８０９５２
【国際公開番号】ＷＯ２００８／０４８８３６
【国際公開日】平成２０年４月２４日（２００８．４．２４）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]