JP2010538537A - 自動化されたサービス発見及び動的接続管理 - Google Patents

Abstract

幾つかの実施形態では、装置は、少なくとも１つのサービスを行うためのデバイス機能回路構成と、装置とネットワークの間の対話を制御するためのネットワークインターフェース制御回路構成と、を含んでいる。ネットワークインターフェース制御回路構成は、（１）デバイスの外部へ送信されるべき存在表明メッセージを送って、同デバイスの外部の他のデバイスに、同デバイスが行うことのできるサービスを知らせるため、及び（２）同デバイスの外部の他のデバイスから存在表明メッセージを受け取って、他のデバイスが何のサービスを行うことができるかを知るためのサービス発見モジュールを含んでいる。幾つかの実施形態では、ネットワークインターフェース制御回路構成は、動的接続管理モジュールを含んでいる。他にも実施形態が説明され、特許請求されている。
【選択図】図３

Description

実施形態は、一般的には、ネットワークに関する。幾つかの実施形態は、より具体的には、サービスネットワーク内の自動的サービス発見及び動的接続管理に関する。

ローカルエリアネットワーク（ＬＡＮ）は、自宅や小規模オフィスでの様に、比較的少数のデバイスを一体にネットワーク接続したネットワークである。ＬＡＮは、インターネットを含め、より広域のネットワークに接続することができる。ローカルサービスネットワークは、ユーザーレベルの各種サービスが、管理型ネットワークサービスの必要無しに、ネットワーク上で自らの存在を宣伝して通信を確立することを望む、相互接続ネットワークである。ネットワーク管理サービスの例としては、ネットワーク上のデバイスに動的なインターネットプロトコル（ＩＰ）アドレスを割り当てるのに使用されている動的ホスト構成プロトコル（ＤＨＣＰ）、ドメイン名をＩＰアドレスに翻訳するのに使用されているドメイン・ネーム・システム（ＤＮＳ）、及びサンマイクロシステムズから出ている、ネットワーク上のデバイスの接続と共用を簡略化するためのソフトウェアであるJini（ジニー）が挙げられる。サービスが、シングルチップソリューションの様な低コスト、低リソースデバイスの形態で届けられるようにするためには、軽量なプロトコルが望ましい。

ゼロ・コンフィギュレーション・ネットワーク（ZeroConf）（インターネット・エンジニアリング・タスク・フォース（ＥＴＦ）リクエスト・フォー・コメント（ＲＦＣ）３９２７）は、使用可能なＩＰネットワークを、構成及び専用サーバー無しに、自動的に作成するための技法を含んでいる。マルチキャストＤＮＳ（ｍＤＮＳ）は、どのネットワーク品目が特定の名前を有しているかを識別するのに使用されているプロトコルである。ｍＤＮＳベースのＬＡＮ上のデバイスは、ＤＮＳ記録の一覧を記憶している。ｍＤＮＳクライアントが、名前が与えられているデバイスのＩＰアドレスを知りたがると、対応する記録を有するデバイスが自身のＩＰアドレスで応じる。ＤＮＳベースのサービス発見（ＤＮＳ−ＳＤ）が、ＤＮＳの最上位に構築されている。マルチキャストＤＮＳとＤＮＳ−ＳＤはアップル社に帰属する。ネットワーク接続されている品目のどれが特定の名前を有しているかを識別するのに、マイクロソフト社のリンク・ローカル・マルチキャスト・ネーム・リゾリューション（ＬＬＮＭＲ）も使用されている。メディア・アクセス・コントロール（ＭＡＣ）アドレスは、ネットワークの各ノードを一意的に識別するハードウェアアドレスである。例えば、イーサネットネットワークでは、それぞれのデバイスは、グローバルに一意な４８ビットグローバルＭＡＣアドレスを有している。マルチキャスティングとは、メッセージが一般にデバイス全てに受け取られることを意図したものではない場合も含め、メッセージをネットワーク上の複数（又は全）デバイスに送ることを指している。インターネットマルチキャストとは、インターネットを使用した類似の活動を指す。伝送制御プロトコル（ＴＣＰ又はＴＣＰ／ＩＰ）及びユーザー・データグラム・プロトコル（ＵＤＰ又はＵＤＰ／ＩＰ）は、インターネットを含めたネットワーク内で使用されてきたプロトコルである。

ネットワークでは、時に、暗号化が使用されることもあり、そうすればネットワークでは数多くの異なる暗号化フォーマットとプロセスが使用される可能性がある。幾つかの先行技術の技法は、アクティブ接続（例えば、安全ソケット層（ＳＳＬ））に基づいており、暗号状態が接続記録に加えられる。

サービスは、ネットワークに参加するのも離脱するのも意のままに又は不意に行うことができ、そのため他のサービスが新しいサービスや連絡できないサービスを素早く知ることが望ましい。加えて、サービスは、アクティブな通信中に異なるネットワークアドレスが割り当てられることもあり、そのため動的な接続管理技法が望ましい。低リソース設定では、接続記録それ自体が希少リソースであり、そのためネットワークに亘って同時に開くことができるより多くのアクティブ接続をサポートする手段を提供するのが有益である。また、サービス同士の間の通信に暗号化が使用されることもあり、その場合はサービス同士の間の接続の管理の複雑性が増す。

サービスは間欠的にアクティブになったりネットワークにつながれたりすることもあるが、サービスは永久状態、例えば他のサービスに名前を付ける場合の嗜好性のセットを維持していることもある。サービスは、そのネットワークアドレスが、恐らくはネットワークにアクティブにつながれている間に、例えばＩＰアドレス再割り当てを経て変化するデバイス上でアクティブになっていることもある。これらの理由により、サービスは、ネットワーク上に存在している時にはそれが見分けられるようにするため、グローバルに一意又は不揮発性の識別子を使用している。識別子を割り当てるのに、広範に様々な技法が可能である。例えば、サービス識別子割当当局なら、識別子を世界規模で管理することができるであろう。既存のグローバル一意識別子（例えば、イーサネットＭＡＣアドレス）を活用し、それにローカル的不揮発性の通し番号を加味することは、もう１つの可能性を示している。

幾つかの実施形態では、デバイスは、少なくとも１つのサービスを行うためのデバイス機能回路構成と、同デバイスとネットワークの間の対話を制御するためのネットワークインターフェース制御回路構成と、を含んでいる。ネットワークインターフェース制御回路構成は、（１）同デバイスの外部へ送信されるべき存在表明メッセージを送って、同デバイスの外部の他のデバイスに、同デバイスが行うことのできるサービスを知らせるため、及び（２）同デバイスの外部の他のデバイスから存在表明メッセージを受け取って、他のデバイスが何のサービスを行うことができるかを知るためのサービス発見モジュールを含んでいる。

幾つかの実施形態では、ネットワークインターフェース制御回路構成は、動的接続管理モジュールを含んでいる。

他にも実施形態が説明され、特許請求されている。

本発明の実施形態は、実施形態を例示するのに使用される以下の説明並びに添付図面を参照することにより理解されるであろう。しかしながら、本発明の実施形態は、これらの図面の詳細事項に限定されるものではない。

幾つかの実施形態によりネットワークにつながれているデバイスを表したブロック図である。 幾つかの実施形態によりネットワークにつながれているデバイスを表したブロック図である。 幾つかの実施形態によるネットワークデバイスの詳細事項を表したブロック図である。 幾つかの実施形態によるネットワークデバイスの詳細事項を表したブロック図である。 幾つかの実施形態によるネットワークデバイスの詳細事項を表したブロック図である。 幾つかの実施形態によるサービス発見モジュールと動的接続管理モジュールの詳細事項を表したブロック図である。 幾つかの実施形態によるサービス発見モジュールと動的接続管理モジュールの詳細事項を表したブロック図である。 幾つかの実施形態による存在表明メッセージを表した図である。

図１は、導体２４−１、２４−２、２４−３、及び２４−４を通してネットワークインフラストラクチャ３０に連結されたデバイスＤ１、Ｄ２、Ｄ３、及びＤ４を含んでいるネットワーク１０を示している。一例として、ネットワークインフラストラクチャ３０は、イーサネットベースのネットワークであってもよいが、イーサネットベースのネットワークの代わりに、又はそれに追加して、他の種類のネットワークを使用してもよい。デバイスＤ１−Ｄ４は、ネットワークに接続されている限り、ネットワークの一部と見なされるが、物理的又は動作的に外されると、それらデバイスはもはやネットワークの一部とは見なされない。実用上は、ネットワーク上に存在するデバイスは４機よりも多いことも少ないこともある。デバイスＤ１−Ｄ４は、映像信号を提供すること、映像を表示すること、及び印刷することを含め、様々なサービスを行うようになっていてもよい。デバイスＤ１、Ｄ２、Ｄ３、及びＤ４は、ネットワークインターフェース制御回路構成２０−１、２０−２、２０−３、及び２０−４を含んでいる。一例として、ネットワーク３０は、インターネットへのアクセスを含んでいる場合もある家庭用娯楽ネットワークであってもよい。デバイスＤ１、Ｄ２、Ｄ３、及びＤ４は、数機又は全機が、テレビ、ＤＶＤプレーヤー、セットトップボックス、コンピュータ、ビデオゲームシステムなどの様な娯楽デバイスであるかもしれない。デバイスのうちの数機は、プリンタの様なより限定されたデバイスであるかもしれない。システム３０は、デバイスＤ１−Ｄ４の少なくとも数機がサービスを伴っており、デバイスの少なくとも数機が自身の存在をネットワーク上で宣伝し通信を確立することを望んでいる点において、サービスネットワークであるといえる。ネットワークインターフェース制御回路構成２０−１、２０−２、２０−３、及び２０−４は、どのデバイスでも同じであってもよいし、ネットワークインターフェース制御回路構成の１つ又はそれ以上は、僅かに異なっていてもよい。例えば、プリンタ用のネットワークインターフェース制御回路構成は、テレビ用のネットワークインターフェース制御回路構成よりも性能が低いかもしれない。

幾つかの実施形態では、デバイスは１つ又はそれ以上のエージェントを含んでいてもよい。状況によっては、エージェントとエージェントが管理するハードウェアリソースの間に１対１関係が存在していることもある。例えば、単一のエージェントが、単一の同報通信チューナーデバイスを管理し、単一のアクティブセッションをサポートしていることもある。しかしながら、幾つかの実施形態では、他のリソースは、複数のアクティブセッションをサポートしていることもある。例えば、映像サーバーは、幾つかのアクティブストリームが単一のディスクから供給されるようにしているかもしれない。幾つかの実施形態では、複数のエージェントは、単一のメディアリポジトリへのアクセスを提供する場合に同一のサービスを提供している。これらのエージェントは、機能性と挙動においては等価であり、同じリソースのために競合し、同じコンテンツへのアクセスを有しているが、その様な相互に入れ替え可能なエージェントの集合体をエージェント等価クラスと呼んでもよい。

等価クラスは、利用可能なリソース及び性能に関する情報を統合して、それにより記憶及び伝送要件を縮小する上で有用である。更に、それらは、遠隔のエージェントが、エージェントの集合体同士の間の意味のある関係を判定できるようにする。例えば、映像サーバーがアクティブセッションで完全にビジーである場合、等価クラスは、新しいセッションを開始できるようにするため、フリーのリソースに連絡を取ることができるエージェントのセットを公表する。

幾つかの実施形態では、エージェントは、一意識別子の割り当てによって識別されるようになっていてもよい。１つの例では、６４ビット数値識別子が各エージェントに割り当てられていてもよい。エージェント識別子は、永続的で、エージェントそれぞれに対しグローバルに一意である。この例では、値ゼロは、無効又は特定されていないエージェントの識別を表すものとして確保されており、オール１の値（１６進法、０ｘFFFFFFFFFFFFFFFF）は、オールエージェントを表すワイルドカードとして確保されている。エージェント識別子のフォーマットを表１に示す。
表１：エージェント識別子のフォーマット

この例では、６バイトのグローバル一意値フィールドは、全てのデバイスに亘って一意である。この値の選択の仕方は特定せずにおいてもよいが、１つの例では、値は、中央当局によって割り当てられ、而してグローバルに一意である、ネットワークインターフェースの４８ビットイーサネットＭＡＣアドレスであってもよい。或る実施形態では、選定値には、イーサネットＭＡＣアドレススキームと相互運用されることが求められており、そうすれば有効なＭＡＣアドレスは作成されない。エージェント識別子のインスタンスとグループのフィールドは、例えばデバイスの設計者によってローカル的に割り当てられるようになっていてもよい。グループフィールドと一意値フィールドが一体となって、エージェント等価クラスを識別している。一例として、グループフィールドは、符号無し整数値として翻訳されてもよく、そうすればデバイスは最大２５６の等価クラスを作成することができるようになる。インスタンスフィールドは、符号無し整数として翻訳されてもよい。インスタンスフィールドは、等価クラス内の特定のエージェントを識別している。所与の等価クラスのインスタンス値は、連続した範囲を占めていなければならない。而して、デバイス１機で、最大２５６グループの６５５３６エージェントをサポートすることができる。

図２は、同図ではネットワーク４０がサブネットワークインフラストラクチャ４４と４６から構成されているネットワークインフラストラクチャ４２を含んでいること以外は、図１と同様である。更に、デバイスＤ３は、アクセスポイント／アンテナ５０と５２を含んでいる無線接続を通じて、サブネットワークインフラストラクチャ４６に連結されている。図２は、４機のデバイスがつながれているネットワークの１つの例を提示しているが、実施形態は、要素の個数については何ら特定の個数に限定されるものではない。ネットワーク４２に連結されているデバイスは４機より多くてもよいし少なくてもよい。

図３は、幾つかの実施形態によるネットワークインターフェース制御回路機構２０−１を示している。他の実施形態では、ネットワークインターフェース制御回路構成は異なっていてもよい。更に、上で指摘した様に、ネットワークインターフェース制御回路構成は、他にも要因はあるが中でもとりわけ一緒に使用されるデバイスに応じて変えられてもよい。送信器と受信器７２は、導体２４−１とネットワーク安全モジュール７６の間に連結されている。導体２４−１は、信号を双方向に伝える導体の単一セットであってもよい。代わりに、導体２４−１は、信号を異なる方向に送り渡す導体の複数セットを備えていてもよい。導体上の様々な信号には、多重化、パケット化を施してもよいし、又は別のやり方で導体に搬送されるようにしてもよい。様々な種類のシグナリングを使用することができる。ネットワーク安全モジュール７６は、確実に、導体２４-１からの通信がデバイスＤ１の他の部分に送り渡されるようにすることを意図している。幾つかの実施形態では、ネットワーク安全モジュール７６は、認証済みのデバイスからの信号しか送り渡そうとしない。例えば、幾つかの実施形態又は状況では、安全モジュール７６は、或る特定のトークン又はキーをヘッダに有している信号しか送り渡そうとしない。更に、幾つかの実施形態では、ネットワーク安全モジュール７６又はデバイスＤ１内の何か他のモジュールは、デバイスＤ１からの信号が適正な識別子（ヘッダ内のものなど）を有しており、よって他のデバイスに受け入れられることを確認する。他の安全機能を以下に説明する。幾つかの実施形態では、ネットワーク安全モジュール７６は含まれていないか、又はここで説明されているものに比べると性能が縮小されている。サービス発見モジュール８０は、以下に説明されている自動的なサービス発見を行う。動的接続管理モジュール８４は、以下に説明されている動的接続管理を行う。

導体８８は、デバイスＤ１のデバイス機能回路構成９２と呼ばれる他の構成要素への信号を搬送する。デバイスによって提供されるサービスは、デバイス機能回路構成９２によって行うことのできるサービスを含んでいる。デバイス機能回路構成は、それぞれのデバイスで異なっている。デバイス機能回路構成９２の例としては、映像処理、映像表示、映像伝送、その他各種機能が挙げられる。図４は、テレビであることを特徴とする場合のデバイスＤ１の詳細事項を示しており、その場合、デバイス機能回路構成９２は、映像処理回路構成９４、ディスプレイ駆動回路構成９６、及び画面１０４を含めたディスプレイ１０２を含んでいる。図５は、セットトップボックスであることを特徴とする場合のデバイスＤ１の詳細事項を示しており、その場合、デバイス機能回路構成９２は、例えばケーブルコンセント又は衛星受信器から導体１０８を通して映像信号（並びに音声及び制御信号）を受信する映像受信回路構成１１０を含んでいる。映像受信回路構成１１０が、映像信号（及び恐らくは音声及び制御信号も）を映像処理回路構成１１２に提供すると、同映像処理回路構成は映像信号をネットワークインターフェース制御回路構成２０−１に提供する。映像受信回路構成１１０は、何らかの形態のネットワークインターフェース回路構成を含んでいてもよいが、その様な回路構成は実施形態では必須ではない。

図６は、幾つかの実施形態によるサービス発見モジュール８０又は動的接続管理モジュール８４の何れかを示している。図６に示す様に、専用又は共用プロセッサ１２４は、専用又は共用メモリ１２６から受信された命令に基づいて作動し、専用又は共用メモリ１２６をデータ記憶用に使用している。これに関連して、専用又は共用とは、プロセッサ又はメモリが特定のモジュールのためだけに設けられていてもよいし、モジュールがプロセッサ又はメモリを他の構成要素と共用していてもよいという意味である。専用又は共用メモリ１２６は、命令とデータを別々に維持してもよいし、まとめて維持してもよい。専用又は共用メモリ１２６は、連絡先の表、発見されたサービスの一覧、及びサービス場所の表の様な一覧又は表を含んでいてもよい。ハードウェア回路１２０は、専用又は共用プロセッサ１２４と、そして恐らくはモジュール内部又は外部の他の構成要素と、インターフェースしている。

図７は、幾つかの実施形態によるサービス発見モジュール８０又は動的接続管理モジュール８４の何れかを示している。図６に示す様に、ハードウェア回路１３０は、モジュールの各機能を果たす。ハードウェア回路１３０は、連絡先の表、発見されたサービスの一覧、及びサービス場所の表の様な一覧又は表を含んでいてもよい。図８は、幾つかの実施形態による存在表明メッセージを表わしている。他の実施形態は、多少異なる存在表明メッセージを含んでいるか、又は同じ機能であるが相当異なるやり方で行われる機能を含んでいる。図８に示す様に、メッセージ８００の記述子ヘッダ８１０は、タイプと長さのフィールドを含んでいる。メッセージの本体８２０は、サービスの識別子（グローバルに一意なサービス識別子であってもよい）、ネットワークアドレス、ポート番号、有効期限値、及び他の情報を含む各種情報を含んでいてもよい。これについて以下に更に詳しく説明してゆく。

自動的サービス発見
以下は、幾つかの実施形態による自動的サービス発見の詳細事項の説明である。他の実施形態は、異なる詳細事項を含んでいる。サービス発見には、デバイスが、ネットワーク上で何のサービスが利用可能であるかを知ることが伴う。或る特定のデバイスの視点から見て、別のデバイスのサービスは、いつ何時ネットワークに参加又は離脱するかもしれない。サービスネットワークがローカルエリアネットワークであると定義されているときは、同報通信が可能である。サービスネットワークが経路指定されているときは、インターネットマルチキャストを使用することができる。これらの通信技法を活用すれば、メッセージを、ネットワークにつながっている全ての潜在的サービスに、それらのアドレスを知ること無く伝送することができる。その様なメカニズムは、ネットワーク二分帯域に比較してサービスの数が少ない場合のローカルエリアにおいて最も有用である。

この実施形態では、単純なシステムが可能になる。幾つかの実施形態では、サービスは、自身の存在を周期的に表明する責任を負っている。幾つかの実施形態では、周期的にとは、必ずしも厳密というわけではないが実質的に一定の間隔でという意味であり、他の実施形態では、周期的にとは、厳密に一定の間隔でという意味である。間隔の長さは異なっていてもよく、時間経過に伴って変化してもよい。幾つかの実施形態では、その様な存在表明メッセージは、少なくとも以下の情報、即ち、サービスの識別子、サービスと現在連絡が取れるネットワークアドレスとポート番号、及びこの表明メッセージがどれ程の間有効であると見なされるかを表す有効期限（ＥＴ）値、を含んでいる。他の実施形態では、上記情報の幾らかは含まれず、追加の情報が含まれていてもよい。その様な表明メッセージを受け取るサービスは、現在利用可能であるサービスの連絡先の表を作成する。デバイスの（サービス発見モジュールの様な）受信器が、所与のサービスから、そのＥＴの数倍の期間が満了する前に、別の表明メッセージを受け取らなければ、当該サービスはネットワークを離れたものと見なされることになる。

ＥＴ値を調整することにより、サービスはその表明の頻度を制御することができる。ＥＴは、サービスを行うデバイスによって設定することもできるし、別のデバイスによって設定することもできる。頻度が高まる（ＥＴ値が小さくなる）と、ローバスト性と検知の待ち時間が改善される。これは、表明メッセージの損失への対処に役立つのみならず、サービスが（例えばケーブルの取り外しにより）ネットワークから外れた状態になったことをより速く検知できるようにするのにも役立つ。受信器は、更に、ＥＴ満了に対する自身の感度を適合させるか又は調整することができる。ＥＴ満了以降の待ち時間が長くなるほど、サービスがネットワークから外れた状態になったことを判定するのに時間が掛かるようになる。ＥＴ満了以降の待ち時間が短すぎると、受信器は、実際に、例えば、サービスの表明メッセージがネットワークによって落とされたときに、当該サービスが利用できないものと判定してしまう可能性がある。幾つかの実施形態では、各サービスは、環境及びアプリケーションドメインに基づいてこれらのパラメータを適合させるか又は調整することができる。

幾つかの実施形態では、サービス発見モジュールは、ネットワーク上の他のデバイスへの自身の存在表明メッセージを送り、更に、ネットワーク上の他のデバイスからの存在表明メッセージを受け取る。異なる実施形態では、存在表明メッセージは、例えば、サービス発見モジュールによって提供されることもあれば、送信器によって送信されることもあり、また、送信器によって受信されることもあれば、サービス発見モジュールに提供されることもある。様々な実施形態では、サービス表明は、パケット化されていてもよいし、パケット化されていなくてもよい。

時には、全てのアクティブなサービスからの即時通告を得ることが望ましいこともある。例えば、デバイスは、ネットワーク上の利用可能なプリンタの一覧を表示することを望むかもしれず、確実に、自身の利用可能なサービス一覧を可能な限り最新にしておきたいと思っている。幾つかの実施形態では、存在要求メッセージを送ることもできる。サービスは、存在要求メッセージを受け取ると、即座に、表明メッセージを送信することによって応える。表明応答は、例えば、当該要求相手へのユニキャストである場合もあれば、全ての潜在的なサービスへのマルチキャストである場合もある。

幾つかの実施形態では、このシステムは、従来型のマルチキャストＤＮＳ／ＤＮＳ−ＳＤ及びＬＬＭＮＲとは幾つかの点で異なる。表明は、サービス場所を特定することとキープアライブ通告の役目を果たすという二重の目的に供される。従来型の手法は、サービスの場所を発見するのに二段式ネームリゾリューションを伴う場合がある。第１の段階で、サービスの名前が、それが置かれているデバイスのネットワーク名と突き合わされる。第２の段階で、デバイスの名前が、ネットワークアドレスと突き合わされる。このやり方では、低リソース環境にとって現実的でない不要な複雑性が加わることになる。更に、従来型の手法では、追加の情報を発見プロセスの一環として簡単に運搬することができない。

強化されたサービス表明
以下は、幾つかの実施形態による強化されたサービス表明の詳細事項の説明である。他の実施形態は、異なる詳細事項を含んでいる。上で説明した基本的なサービス表明メッセージは、サービスを発見することと、その様なサービスがアクティブになっているときを検知するための最小限のメカニズムを提供している。サービスの性能と状態についての更なる情報を発見するには、サービスに連絡を取って照会が行われるが、これが従来型のメカニズムが採用している手法である。しかしながら、幾つかの実施形態では、表明スキームは、サービスが、自身の表明の中に一般的に要求される情報を含むことができるようにしている。

幾つかの実施形態では、サービスのタイプ又はクラスを識別するための記述子を表明の中に含めることができる。これにより、受信器にとっては、それらが遠隔サービスから何の情報を得るかについての選択性が広がる。例えば、映像表示サービスは、映像ソースサービスの一覧を維持したいと望むかもしれない。表明メッセージにタイプフィールドが無ければ、映像表示サービスは、全てのサービス場所をキャッシュするか又はサービスクラスを確定するのに、各々に順に連絡を取らなくてはならないかもしれない。幾つかの実施形態では、サービスタイプフィールドが含まれているので、映像表示サービスは、映像ソースサービスのみの一覧を維持し、それらのサービスだけに連絡を取ればよいため、リソースと時間を節約することができる。

幾つかの実施形態では、サービスタイプフィールドのフォーマットと解釈は周知されており、表明プロトコルの標準部分になっていてもよい。別に、遠隔サービスにタイプフィールドを利用する能力が無いこともある。しかしながら、サービスのタイプ毎に、表明メッセージの残り部分をサービス特定様式、即ち、特定のサービスに興味のあるサービスだけが表明に運搬されている追加の情報を理解することを求められる、という様式で定義することができる。

サービスは、サービスタイプによって意味があると見なされる、他の一般的に有用な情報を表明の中に含めたいと望むかもしれない。例えば、サービスは、実行時間、興味のある事象が起こったことの表示（例えば、タイムスタンプ又は生成カウント及び事象指示子を介して）、ビジー／利用可能状態、サービスによって管理されている品目の数（例えば音楽サービスでは歌曲の数）などの様な一般的な情報を含んでいてもよい。サービス特定情報も可能である。例えば、デジタルメディアリポジトリは、利用可能な空き領域の量、リポジトリがサポートすることのできるストリームの数、アクティブストリームの数、リポジトリがサポートする性能の一覧（例えば、記録、トリックプレイ）などを含んでいてもよい。考えられる多彩な属性が含まれていてもよいが、プロトコル設計者は、（帯域使用が増すことを犠牲にして）全表明に情報を含める時期と、（待ち時間が増すことを犠牲にして）情報の照会を求める時期とのバランスを取ることになろう。

個人娯楽ネットワーク（例えば、家庭内でデジタルメディアコンテンツを搬送するためのネットワーク）の一例として、最上位サービスタイプ、即ち、メディアソース、メディアシンク、を挙げることができる。メディアソース又はシンクは、それがサポートするコンテンツのタイプ、即ち、映画（組み合わされた音声／映像）、音楽（音声のみ）、写真（画像）、ユーザーインターフェースと制御、２Ｄグラフィック、３Ｄグラフィックなど、を指定する属性を含むことができる。メディアソースは、メディアソースがタイムシフトをサポートしているか否かを表す追加の属性を含んでいてもよく、一方、メディアシンクは、メディアシンクが記憶（記録）又は表示をサポートしているか否かを表す属性を含んでいてもよい。更に、サービスがビジーであるかフリーか、及び記憶サービスの使用済み及び空き領域の量を表すのに、動的状態が含まれていてもよい。

動的接続管理モジュール
以下は、幾つかの実施形態による動的接続管理の詳細事項の説明である。他の実施形態は、異なる詳細事項を含んでいる。上で概説したサービス発見システム内で、サービスは、遠隔サービスに連絡を取るためのネットワークアドレスを確定することができる。このアドレスは、動的に変化する可能性があり、遠隔サービスは自発的にネットワークから離れることもできる。単一デバイス上で複数のサービスがホストされていることもあるが、これは、潜在的に、各サービスに、接続状態を維持すること、そして恐らくは単一の接続記録を管理するために他のローカルサービスと情報を交換すること、という負担を課すことになるので、大抵は現実的なレベル以上に複雑性が増す。従って、幾つかの実施形態では、共有接続管理システムが採用されてもよい。

グローバルに一意なサービス識別子を使用してメッセージをアドレス指定することによって、動的接続管理モジュールはデバイス内で集中化され、モジュールは存在しているアクティブな通信セッションより少ない接続記録を管理すればよくなる。例えば、接続管理モジュールが単一の接続記録を使用する一方で、サービスは幾つかの遠隔サービスと同時に通信している状態になることもできる。低リソース環境では、その様な動的接続管理は、リソースを節約し、低コストの解決法を可能にする。

幾つかの実施形態では、動的接続管理モジュールは、以下のように働く。サービスが、遠隔サービスのクラスへの興味を接続管理モジュールに登録すると、同モジュールは、登録された判定基準に一致する発見されたサービス場所のキャッシュを維持する。サービスは、動的接続管理モジュールに、発見されたサービスの一覧上を反復するよう照会を行うことができる。サービスは、遠隔サービスに送ることを望んでいるメッセージがあれば、メッセージデータ、メッセージの長さ、及びサービス識別子を、接続管理モジュールに送り渡す。接続管理モジュールは、自身の発見されたサービス、即ち、接続管理モジュールが表明メッセージを受け取りネットワークアドレスを記録したサービス、の一覧の中でサービス識別子を探す。接続管理モジュールは、自身が遠隔サービスへの開かれた接続を有しているか確かめる。開かれた接続を有していなければ、接続管理モジュールは接続を開き、メッセージを届ける。このプロセス中、遠隔サービスのネットワークアドレスは常に変化する可能性がある。幾つかの実施形態では、利用できるフリー接続記録が無い場合、まず接続を閉じることにより、使用頻度が最も低い接続記録を再生させることができる。幾つかの実施形態では、接続記録の利用可能性に対応するのに、優先権の使用を含め、他の方策が実施されるようになっていてもよい。

別のデバイスの受信器は、同じフローを逆向きにたどり、サービス場所の表を使用して、着信メッセージの送信先サービスを確定する。

遠隔サービスへの接続は、信頼性の無いプロトコル（例えばＵＤＰ）で行われることもあり得るが、その場合は各サービスに信頼性スキームを実施する負荷が上乗せされることになる。そうではなく、動的接続管理モジュールは、サービスメッセージをラッピングして信頼性を提供する（例えば、通し番号及び再伝送をＵＤＰの一番上に加える）か又は信頼性のあるプロトコル（ＴＣＰなど）を伝送に使用するかの何れかによって、信頼性要件に対処することができる。その様な信頼性のある接続の状態は相当大きくなる可能性があり、従って接続記録より多くの接続が許容されるようにすることが求められるであろう。接続を開かねばならなくなる度、待ち時間が加算されることになるが、幾つかの実施形態では、設計は多数の接続記録をサポートし、接続記録のスラッシングを最小化することができる。

こうすれば、低リソースデバイスは、同デバイスが維持できる接続記録を上回るサービスのセットとの間でアクティブな通信を維持することができる。例えば、或るサービスの場所を記録するには約１６バイトを要するが、接続記録の場合は５１２バイトが必要になるかもしれない。

暗号化のサポート
以下は、幾つかの実施形態による暗号化のサポートの詳細事項の説明である。他の実施形態は、異なる詳細事項を含んでいる。サービス同士の通信に保護手段を講じるために、メッセージ内容を暗号化するのが望ましい場合が多い。現在のスキームは、アクティブ接続（例えばＳＳＬ）に基づいており、暗号状態が接続記録に加えられる。幾つかの実施形態では、アクティブな通信経路より少ない接続記録を使用し、認証待ち時間を短縮するために、暗号状態は接続記録の外部に記憶される。この状態は現在のセッションキーを含んでいる。ブロック暗号を用いたカウンタモード暗号化が使用されるなら、現在に限定してカウンタ値も必要になり、データの各ブロックは独立的に暗号化されることになる。

暗号化のサポートは、以下のやり方で実施することができる。サービスは、メッセージを遠隔サービスに送ることを望むと、メッセージデータ、メッセージの長さ、遠隔サービスの識別子、及び暗号フラグを、動的接続管理モジュールに送り渡す。動的接続管理モジュールは、メッセージを届けるよう求められると、必要に応じ上記の様に新しい接続を開こうとする。或る特定の例では、新しい接続を開くためには、既存の接続を閉じることが必要になることもある。アクティブな暗号セッションが無い場合、セッションキーを生成するために遠隔のエンドポイントを相手に認証交換が行われる。同キーを用いてメッセージデータが暗号化され、遠隔のエンドポイントに届けられる。接続が閉じており再開される場合、（攻撃の受け易さに関して暗号アルゴリズムの要件を満たしていることを条件として）セッションキーを再使用することができる。

上記手法は、キーを長期間使用してもよいことから、不適切な保護策と考えられるかもしれない。キーは「ローリング」が施されてもよく、これはストリームから導出されたカウンター値を加味することによって新しいキーが生成されるということである。送信側と受信側が同期した状態に置かれている場合、伝送されたバイトの数はカウンタの役目を果たすことができる。しかしながら、接続が一時的である場合、この同期化要件は満たされていないかもしれない。キーのローリングを有効にするため、以下のシステムが採用されている。

幾つかの実施形態では、安全な接続は、信頼性のあるバイトストリーム又は信頼性のあるメッセージストリームと見なすことができる。単純なラッパープロトコルが導入されている。このプロトコルは、タイプと長さのフィールドを備えたヘッダを含んでおり、クラスタイプのデータのバイトがその長さに従うことを表している。メッセージタイプは、認証、キーロール、アプリケーションデータ、そして恐らくは単一メッセージ内の２つ又はそれ以上のタイプの組合せを含んでいる。このやり方では、動的接続管理モジュールがサービスメッセージストリーム内に安全に関するメッセージを差し挟むことができるようにしながらも、オーバーヘッドは殆ど上乗せされない（例えば、８ビットタイプと２４ビットカウントを使用）。

このラッパープロトコルを使用して、初めて接続を開くとき、動的接続管理モジュールは、ヘッダを適切なタイプフィールドでプリペンドして、前述同様に認証メッセージを交換する。次に、同モジュールは、キーを加味するのに用いるカウンター値を表すキーメッセージを送ることになる。すると暗号エンジンには新しいキーがローディングされるので、以降のメッセージは全てこの新しいキーを用いて暗号化される。次いでサービスメッセージが暗号化され、適切なデータを表す適切なヘッダでプリペンドされて届けられる。接続が閉じており再開される場合、動的接続管理モジュールは、認証ステップを（暗号的脆弱さを持ちこまない場合は）先送りし、最初にキーロールメッセージを届けることによって通信を開始する。その後、通信は前述同様に続く。

こうすれば、ローカルサービスは、アクティブな通信セッションより少ない接続記録を動的に管理し、安全認証を行う頻度を制限しながらも、安全に通信を行うことができる。

追加の情報と実施形態
ここに説明されている様々なモジュールは、ハードウェア、ソフトウェア、ファームウェアか、又はハードウェアとソフトウェアとファームウェアの何らかの組合せで提供されてもよい。

図示の構成要素の間には、中間的な構造が介在していてもよい。ここに説明され図示されている構成要素は、図示及び説明されていない追加の入力又は出力部を有していてもよい。図のシステムを実際に実施する場合、ここに図示されていない追加の回路構成、制御ライン、そして恐らくは相互接続が設けられることになろう。図で、２つのブロックが導体を通して接続されていることが示されている場合、図示されていない中間的な回路が介在していてもよい。ここで言及されている導体は、連続材料の導体である必要は無い。例えば、それらは、ビア又は他の接続構造を含んでいてもよい。各ブロックの形状と相対サイズは、実際の形状と相対サイズに関係付けることを意図したものではない。ブロック同士の間の矢印が一方向にしか示されていないという事実は、他方の方向への通信が存在しないという意味ではない。ブロック同士の間に線が１本しかないからといって、ブロック同士の間に他の導体が存在しないという意味ではない。

実施形態は、本発明の実施形又は実施例である。明細書で、「或る実施形態」、「１つの実施形態」、「幾つかの実施形態」、又は「他の実施形態」という場合、当該実施形態に関連して記載されている特定の特徴、構造、又は特性は、少なくとも幾つかの実施形態には含まれているが、必ずしも全ての実施形態に含まれているとは限らないという意味である。「或る実施形態」、「１つの実施形態」、又は「幾つかの実施形態」は様々に登場するが、必ずしも全てが同一の実施形態を指しているわけではない。

要素「Ａ」が、要素「Ｂ」に連結されているという場合、要素Ａは、要素Ｂに直に連結されていてもよいし、例えば要素Ｃを通して間接的に連結されていてもよい。明細書で、構成要素、特徴、構造、プロセス、又は特性Ａが、構成要素、特徴、構造、プロセス、又は特性Ｂを「引き起こす、〜させる」と書き表されている場合、「Ａ」は「Ｂ」の少なくとも部分的な原因であることを意味するが、但し「Ｂ」を生じさせることを支援する少なくとも１つの他の構成要素、特徴、構造、プロセス、又は特性が存在している場合もあるという意味である。同様に、ＡがＢに応えているという場合、ＡはＢとＣの組合せに応えている場合もある。

明細書で、構成要素、特徴、構造、プロセス、又は特性が、「含まれていてもよい」、「含まれている場合もある」、又は「含めることができる」と表されている場合、当該の特定の構成要素、特徴、構造、プロセス、又は特性が含まれることが要求されているわけではない。明細書で、「或る」又は「一」要素という場合、これは、同要素が１つしかないという意味ではない。

本発明は、ここに説明されている特定の詳細事項に限定されるものではない。実際、上記の説明及び図面に対する多くの他の変型が、本発明の範囲内で行われてもよい。従って、本発明の範囲を定義するのは、以下の特許請求の範囲並びに補正があった場合にはそれら補正も含めたものであり、上記説明にかかるものに限定されるものではない。

Claims (25)

1. 少なくとも１つのサービスを行うためのデバイス機能回路構成と、
   前記装置とネットワークの間の対話を制御するためのネットワークインターフェース制御回路構成と、を備えており、前記ネットワークインターフェース制御回路構成は、（１）前記デバイスの外部へ送信されるべき存在表明メッセージを送って、前記デバイスの外部の他のデバイスに、前記デバイスが行うことのできるサービスを知らせるため、及び（２）前記デバイスの外部の前記他のデバイスから存在表明メッセージを受け取って、前記他のデバイスが何のサービスを行うことができるかを知るためのサービス発見モジュールを含んでいる、装置。
2. 各サービスはエージェントと関係付けられており、各エージェントは等価クラスのメンバーである、請求項１に記載の装置。
3. 各エージェントは一意な識別子を有している、請求項２に記載の装置。
4. 存在表明を受け取るサービスは、現在利用可能であるサービスの連絡先の表を作成することができる、請求項１に記載の装置。
5. デバイスが、或る一定の期間が満了する前に、第１のサービスから別の存在表明メッセージを受け取らなければ、前記デバイスは、前記サービスが前記ネットワークを離脱したものと判定する、請求項１に記載の装置。
6. 前記サービス発見モジュールは、前記サービス発見モジュールが送る表明の頻度を制御するための有効期限（ＥＴ）、又は表明を受け取る場合にはＥＴ満了に対する感度、を含めた要素を適合させることになっている、請求項１に記載の装置。
7. 前記デバイスのサービスは、自身の存在を周期的に表明する責任を負っている、請求項１に記載の装置。
8. 前記デバイスは、存在要求メッセージを使用して、全てのアクティブなサービスからそれらの利用可能なサービスに関する即時通告を要求する、請求項１に記載の装置。
9. 前記デバイスによって送られる前記存在表明メッセージは、少なくとも以下の情報、即ち、前記サービスの識別子、前記サービスと現在連絡が取れるネットワークアドレスとポート番号、及びこの表明メッセージがどれ程の間有効であると見なされるかを表す有効期限（ＥＴ）値、を含んでいる、請求項１に記載の装置。
10. 前記ネットワークインターフェース制御回路構成は、前記ネットワークインターフェース制御回路構成を通過する不正信号を拒否するためのネットワーク安全モジュールを含んでいる、請求項１に記載の装置。
11. 前記サービス表明メッセージは、前記表明に含まれているサービスのタイプ又はクラスを識別するための記述子を含んでいる、請求項１に記載の装置。
12. 前記ネットワークインターフェース制御回路構成は、動的接続管理を行うための動的接続管理モジュールを含んでいる、請求項１に記載の装置。
13. 装置において、
    少なくとも１つのサービスを行うためのデバイス機能回路構成と、
    前記デバイスとネットワークの間の対話を制御するためのネットワークインターフェース制御回路構成と、を備えており、前記ネットワークインターフェース制御回路構成は、前記デバイスの外部の他のデバイスとの接続を管理するための動的接続管理モジュールを含んでおり、メッセージはグローバルに一意なサービス識別子を使用し、前記接続管理は前記デバイス内で集中化されているので、前記接続管理モジュールが単一の接続記録を使用する一方で、サービスは幾つかの遠隔サービスと同時に通信している状態になることもできる、装置。
14. サービスは、遠隔サービスのクラスへの興味を前記接続管理モジュールに登録し、前記接続管理モジュールは、前記登録の判定基準に一致する発見されたサービス場所のキャッシュを維持する、請求項１３に記載の装置。
15. サービスは、前記動的接続管理モジュールに、前記発見されたサービスのキャッシュ上を反復するよう照会を行うことができる、請求項１４に記載の装置。
16. サービスが遠隔サービスに送ることを望んでいるメッセージを有している場合、前記サービスは前記動的接続モジュールに、メッセージデータ、メッセージの長さ、及びサービス識別子を含んでいる要求を提供する、請求項１４に記載の装置。
17. 前記動的接続管理モジュールは、サービスからの要求を受け取ると、自身の発見されたサービスのキャッシュの中で前記サービス識別子を探し、前記動的接続管理モジュールが前記遠隔サービスへの開かれた接続を有しているか確かめ、開かれた接続が存在していなければ、前記動的接続管理モジュールは前記遠隔サービスへの接続を開く、請求項１６に記載の装置。
18. 前記動的接続管理モジュールは、前記サービスメッセージをラッピングして信頼性を提供するか又は信頼性のあるプロトコルを伝送に使用するかの何れかによって、信頼性要件に備える、請求項１３に記載の装置。
19. システムにおいて、
    ネットワークインフラストラクチャと、
    第１デバイス及び第２デバイスと、を備えており、
    前記第１デバイスと前記第２デバイスは、それぞれ、
    少なくとも１つのサービスを行うためのデバイス機能回路構成と、
    前記デバイスとネットワークの間の対話を制御するためのネットワークインターフェース制御回路構成と、を含んでおり、前記ネットワークインターフェース制御回路構成は、（１）前記デバイスの外部へ送信されるべき存在表明メッセージを送って、前記デバイスの外部の他のデバイスに、前記デバイスが行うことのできるサービスを知らせるため、及び（２）前記デバイスの外部の前記他のデバイスから存在表明メッセージを受け取って、前記他のデバイスが何のサービスを行うことができるかを知るためのサービス発見モジュールと、前記デバイスの外部の他のデバイスとの接続を管理するための動的接続管理モジュールと、を含んでいる、システム。
20. 前記接続管理モジュールが単一の接続記録を使用する一方で、サービスは幾つかの遠隔サービスと同時に通信している状態になることもできる、請求項１９に記載のシステム。
21. 単一デバイス上に複数のサービスをホストすることができる、請求項２０に記載のシステム。
22. 前記サービスネットワークは、ローカルエリアネットワークであり、同報通信が使用されている、請求項１９に記載のシステム。
23. 前記サービスネットワークは、メッセージの経路指定とインターネットマルチキャストを含んでいる、請求項１９に記載のシステム。
24. 前記システムでは暗号化が使用されており、暗号状態は前記接続記録の外部に記憶される、請求項１８に記載のシステム。
25. サービスは、遠隔サービスにメッセージを送ることを望むと、メッセージデータ、メッセージの長さ、遠隔サービス識別子、及び暗号化フラグを、前記接続マネジャに送り渡し、前記接続マネジャは、メッセージを届けるよう要求されると、必要に応じて新しい接続を開こうとする、請求項２４に記載のシステム。

Images