(57)【要約】【課題】  ユーザに使用される物（オブジェクト）を管理する場合において、オブジェクトを単独ではなく集合体として管理して、ユーザの観点から効率的な管理を実現する。【解決手段】  第１の識別子（LN-ID）を保有する第１の装置５−ｊと、第２の識別子（GN-ID）を保有するとともに第１の識別子（LN-ID）を第１の装置５−ｊから読み取って当該第１の識別子（LN-ID）と第２の識別子（GN-ID）との組を連携情報として送信しうる第２の装置４−ｉとをそなえたシステムに用いられ、前記連携情報を管理する連携情報管理装置１において、受信した連携情報に含まれる第２の識別子（GN-ID）と、当該連携情報に含まれる第１の識別子（LN-ID）を含む複数の第１の識別子（LN-ID）群とを関連付けて登録するようにする。【選択図】        図１
2005175934.tif 000002
【特許請求の範囲】
【請求項１】
第１の識別子を保有する第１の装置と、第２の識別子を保有するとともに該第１の識別子を該第１の装置から読み取って当該第１の識別子と該第２の識別子との組を連携情報として送信しうる第２の装置とをそなえたシステムに用いられ、該連携情報を管理する連携情報管理装置であって、
該連携情報を受信する受信手段と、
該連携情報を記憶する記憶手段と、
該受信手段で受信した連携情報に含まれる第２の識別子と、当該連携情報に含まれる第１の識別子を含む複数の第１の識別子群とを関連付けて該記憶手段に登録する連携情報登録制御手段とをそなえたことを特徴とする、連携情報管理装置。
【請求項２】
複数の該第１の装置についての第１の識別子同士を予め関連付けた関連付けグループを保持する関連付けグループ保持手段をさらにそなえるとともに、
該連携情報登録制御手段が、
該受信手段で受信した連携情報に含まれる該第１の識別子が属する関連付けグループを該関連付けグループ保持手段において検索する検索手段と、
該検索手段により検索された関連付けグループと該受信手段で受信した連携情報に含まれる該第２の識別子とを関連付けて該記憶手段に登録する登録手段と、
該検索手段により検索された関連付けグループに属する各識別子を該第２の装置に通知する通知手段とをそなえたことを特徴とする、請求項１記載の連携情報管理装置。
【請求項３】
該連携情報登録制御手段が、
該第２の装置から特定の第１の識別子についての一部削除要求を受けると、当該第１の識別子を該記憶手段の連携情報から削除する連携情報一部削除手段をそなえたことを特徴とする、請求項２記載の連携情報管理装置。
【請求項４】
該連携情報登録制御手段が、
該第２の装置から該関連付けグループについての全削除要求を受信すると、当該関連付けグループと該第２の識別子との関連付け情報である連携情報を該記憶手段から削除する連携情報全削除手段をそなえたことを特徴とする、請求項２又は３に記載の連携情報管理装置。
【請求項５】
複数の該第１の装置についての第１の識別子同士の親子関係による階層的な関連付けグループを保持する階層関連付けグループ保持手段をさらにそなえるとともに、
該連携情報登録制御手段が、
該受信手段で受信した連携情報に含まれる該第１の識別子が上位階層の識別子として属する関連付けグループを該階層関連付けグループ保持手段において検索する検索手段と、
該検索手段により検索された階層関連付けグループの該上位階層の識別子及び当該識別子と関連付けられた下位階層の識別子と、該受信手段で受信した連携情報に含まれる該第２の識別子とを関連付けて該記憶手段に登録する登録手段と、
該検索手段により検索された関連付けグループに属する各識別子を該第２の装置に通知する通知手段とをそなえたことを特徴とする、請求項１記載の連携情報管理装置。
【請求項６】
第１の識別子を保有する第１の装置と、第２の識別子を保有するとともに該第１の識別子を該第１の装置から読み取って当該第１の識別子と該第２の識別子との組を連携情報として送信しうる第２の装置とをそなえたシステムに用いられ、該連携情報を管理する連携情報管理装置であって、
該第１の装置を使用中の該第２の装置数（以下、現使用数という）と当該第１の装置を共用できる該第２の装置数の上限値とを該第１の識別子別に保持する共用数保持手段と、
該第２の装置から該連携情報を受信すると、当該連携情報に含まれる上記各識別子と該共用数保持手段における該現使用数及び該上限値とに基づいて、当該第２の装置による当該第１の装置の共用を制御する共用制御手段とをそなえたことを特徴とする、連携情報管理装置。
【請求項７】
他装置によって読み取られる第１の識別子を保有する第１の装置と、第２の識別子を保有するとともに該第１の識別子を該第１の装置から読み取って当該第１の識別子と該第２の識別子との組を連携情報として送信しうる第２の装置と、該第１の装置としての機能と該第２の装置としての機能とを兼ね備えた第３の装置とをそなえたシステムに用いられ、該連携情報を管理する連携情報管理装置であって、
該第３の装置が該第１の装置から読み取った該第１の装置の第１の識別子と該第３の装置が保有する第２の識別子との組を該第３の装置から第１の連携情報として受信する第１の受信手段と、
該第１の装置の該第１の識別子の読み取りを行なった該第３の装置から該第２の装置が読み取った該第３の装置が保有する第１の識別子と当該第２の装置が保有する第２の識別子との組を該第２の装置から第２の連携情報として受信する第２の受信手段と、
該連携情報を記憶する記憶手段と、
該第１の受信手段で受信した該第１の連携情報と該第２の受信手段で受信した該第２の連携情報とを関連付けて該記憶手段に登録する連携情報登録制御手段とをそなえたことを特徴とする、連携情報管理装置。
【請求項８】
該連携情報登録制御手段が、
該第３の装置から該関連付けの解除要求を受信すると、該記憶手段の該第１の連携情報と該第２の連携情報との関連付けを削除する関連付け削除手段をそなえたことを特徴とする、請求項７記載の連携情報管理装置。
【請求項９】
該連携情報登録制御手段が、
該記憶手段において該第１の連携情報と該第２の連携情報との関連付けの生成／解除を監視する監視手段と、
該監視手段にて該関連付けの生成が確認されると、該第１の装置を使用している装置が該第３の装置から該第２の装置に変更されたと認識して、該第１の装置に関する情報の送信先を該第２の装置に変更する指示を該第１の装置に関する情報の送信元に送信し、該監視手段にて該関連付けの解除が確認されると、該第１の装置を使用している装置が該第２の装置から該第３の装置に変更されたと認識して、該第１の装置に関する情報の送信先を該第３の装置に変更する指示を該送信元に送信する送信先変更指示手段とをそなえたことを特徴とする、請求項８記載の連携情報管理装置。
【請求項１０】
第１の識別子を保有する第１の装置と、第２の識別子を保有するとともに該第１の識別子を該第１の装置から読み取って当該第１の識別子と該第２の識別子との組を連携情報として送信しうる第２の装置と、該連携情報を受信して管理する連携情報管理装置と、該第１の装置に関する情報を送信する情報提供サーバとをそなえた連携情報管理システムに用いられるゲートウェイ装置であって、
該情報提供サーバが該第１の装置の該第１の識別子を読み取った該第２の装置宛に該第１の装置に関する情報を送信するために必要な該第２の識別子を該連携情報管理装置から受信する受信手段と、
該受信手段で受信した該第２の識別子を該情報提供サーバへの通知のための他の識別子に変換する識別子変換手段と、
該識別子変換手段による変換後の識別子を該情報提供サーバへ送信する送信手段と、
該情報提供サーバからの該情報に付与された該変換後の識別子を該変換前の識別子に逆変換して該第２の装置宛に転送する情報転送手段とをそなえたことを特徴とする、連携情報管理システムに用いられるゲートウェイ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、連携情報管理装置及び連携情報管理システムに用いられるゲートウェイ装置に関し、特に、ＩＰ（Internet Protocol）ネットワーク等のネットワークに接続可能な装置を保持する特定のユーザに対して、所望のサービスを提供するために、好適な技術に関する。
【背景技術】
【０００２】
近年の無線チップの集積化技術の進歩により、従来の書籍やＣＤ（音楽用コンパクトディスク）等に貼付されていたバーコード（個別識別情報）の代替として、読み書き可能なRF-ID(Radio Frequency ID)タグ（無線タグ）が出現したため、今後、物流管理や工場の製造工程管理など、より広範囲に渡ってRF-IDタグが、情報記憶媒体として使用されると期待されている。このRF-IDタグの普及規模は、バーコードをはるかに上回ると予想されており、RF-IDタグをネットワークサービスの一要素として考えた場合において、よりスケーラブルな管理体系などが必要になってくると考えられている。
【０００３】
例えば、今後のネットワークサービスの一形態として、ユーザの周辺に配置されたアプライアンス（Appliance）を提供することが想定される。ここで、「アプライアンス」とは、個体識別情報を保有するとともに、当該個体識別情報を他装置と通信する通信手段として有する「物」である。アプライアンス（あるいは、オブジェクトともいう）は、ユーザが個人で保有する端末装置（例えば、携帯電話機）のみを用いては実現できない機能をユーザに対して提供する。
【０００４】
即ち、ユーザは、周辺に配置されたアプライアンス（例えば、ポインティングデバイス，プログラム記録媒体，ヘッドホン等）を一時的に利用することにより、ユーザ個人で保有する端末装置のみでは実現できない機能の提供を、サービスとして受けることが可能となる。なお、アプライアンスは、アプライアンス自体がユーザの端末装置に対して直接的に何らかの機能を提供するものでない物（例えば、建物、看板、缶等）であってもよいし、また、公共物、個人所有物のいずれであってもよい。
【０００５】
本発明は、このような身の回りの多様な「物」としてのアプライアンスがRF-IDタグ等の手段によって認識可能になる世界を想定して、これらアプライアンスの情報を利用したサービスを提供しようとするネットワーク事業分野に関連する。
なお、ユーザの移動端末（ＭＮ：Mobile Node）の位置を個々に管理する手段として、レイヤ３〔ＩＰ（Internet Protocol）レイヤ〕におけるモバイルＩＰ（Mobile IP：下記非特許文献１参照）がある。
【０００６】
このモバイルＩＰでは、ＩＰネットワークを用いて構成される複数のサブネットワーク間をＭＮが移動しながら通信することを継続可能とする技術で、ＭＮは、現在所属するサブネットワークに依存しないアドレス（ホームアドレスと呼ばれる）と、サブネットワークに依存するアドレス〔気付アドレス（CoA：Care of Address）と呼ばれる〕とを有する。
【０００７】
そして、ＭＮは、移動に伴って、適宜、上記各アドレスをホームエージェント（ＨＡ：Home Agent）と呼ばれるＭＮの位置管理装置に送信して位置登録を行ない、ＨＡでは、これらのアドレスを対応付けて記憶・管理することにより、ＭＮの現在位置を個々に管理する。ＭＮの通信相手となる端末（ＣＮ：Correspondent Node）は、ＭＮ宛にパケットを送信する際、そのＭＮのホームアドレス宛にパケットを送信し、ＨＡは、当該ＭＮのホームアドレス宛のパケットを受信すると、当該パケットをそのホームアドレスに対応する最新の気付アドレス宛にカプセル化して転送する。これにより、ＭＮは、ＣＮから送信されたパケットを、サブネットワーク間を移動して気付アドレスが変化しても正常に受信することができ、ＣＮとの通信を継続することが可能となる。
【０００８】
また、モバイルＩＰに関連する技術として、ＨＡが、あるＭＮについて、このＭＮは正規のユーザ端末であるか否かを認証する技術がある（下記特許文献１参照）。さらに、ネットワークを介して接続される端末装置のユーザを識別する技術として、ＮＡＩ（Network Access Identifier）を用いた技術（下記非特許文献２参照）もある。
【特許文献１】特開２００１−１６９３４１号公報
【非特許文献１】“IP Mobility Support”、[online]、１９９６年９月、IETF Network Working Group、[平成１５年１２月１０日検索]、インターネット＜URL：http://www.ietf.org/rfc/rfc2002.txt＞
【非特許文献２】“The Network Access Identifier”、[online]、１９９９年１月、IETF Network Working Group、[平成１５年１２月１０日検索]、インターネット＜URL：http://www.ietf.org/rfc/rfc2486.txt＞
【発明の開示】
【発明が解決しようとする課題】
【０００９】
上記のアプライアンスをユーザに対して提供するサービスでは、あるアプライアンスとこれを使用するユーザとの対応関係（即ち、利用関係）を、サービスの提供側（サーバ等）で認識する必要があるが、ネットワークが大規模化した場合等に、これに対応して利用関係についての情報（連携情報）の登録、更新、削除等の操作を高速かつ効率的に行なう（スケーラビリティを確保する）ための連携管理機構について検討する必要がある。
【００１０】
また、アプライアンスとこれを使用するユーザとの対応関係は必ずしも１対１とはならない（例えば、プリンタ等の共有使用が想定されるケース等のように、１対多の関係も想定される）ため、これに対応した連携管理機構も要求される。
さらに、上記対応関係の認識により、例えば、実世界に散在するオブジェクト（RF-IDタグを付けた商品や電気製品等）の属性やロケーションの属性（その位置の特性を現すタグ属性、例えば「会議室」等がある）等を基に、特定のオブジェクトに関する連携情報をもった〔換言すれば、一定のコンテキスト（ある事項についての状況や環境）を満たした〕サービス利用者へ広告情報や緊急メッセージ等の所望のコンテンツを転送するといったサービス（このように、その場の状況に沿ってサービスを実施、内容調整しうるサービスを「コンテキスト・アウェア」サービスと称する）を実現することも可能となるが、コンテンツ受信側（ネットワーク端末）の性能（メモリ，ＣＰＵ，インタフェース速度等）が不足する等の事態の発生を未然に防止する連携情報管理機構も検討する必要がある。
【００１１】
また、上記のような「コンテキスト・アウェア」サービスの実現にあたって、異事業者ネットワークを経由する通信が必要となるような場合に、ある事業者のネットワークが、特定のＩＰアドレスを有するユーザの連携情報を他事業者のネットワーク内ノードに直接的に提供してしまうと、ユーザについてタグ情報に基づいたロケーションプライバシーや、ユーザが保有する「物」についての秘匿性が保護されないので、これを防止する連携管理機構も要求される。
【００１２】
本発明は、以上のような課題に鑑み創案されたもので、主として、下記(1)〜(4)に示す機能ないし機構を実現できるようにした技術を提供することを目的とする。
(1)オブジェクト同士のスケーラビリティを考慮した管理によるネットワーク構築および運用コストの低減。
(2)単一のアプライアンスを複数ユーザで共用（多重的な連携）することを可能とする、拡張連携情報管理機構。
【００１３】
(3)ノード間において、ＧＮ（Global Node）機能の移動を行なうことによって、ＧＮとして機能するノードの性能面についての制約等を解消。
(4)異種事業者ネットワーク間通信時の連携情報に関するプライバシーの保護機構。
【課題を解決するための手段】
【００１４】
上記の目的を達成するために、本発明の連携情報管理装置は、第１の識別子を保有する第１の装置と、第２の識別子を保有するとともに該第１の識別子を該第１の装置から読み取って当該第１の識別子と該第２の識別子との組を連携情報として送信しうる第２の装置とをそなえたシステムに用いられ、該連携情報を管理するものであって、該連携情報を受信する受信手段と、該連携情報を記憶する記憶手段と、該受信手段で受信した連携情報に含まれる第２の識別子と、当該連携情報に含まれる第１の識別子を含む複数の第１の識別子群とを関連付けて該記憶手段に登録する連携情報登録制御手段とをそなえたことを特徴としている。
【００１５】
ここで、本連携情報管理装置は、複数の該第１の装置についての第１の識別子同士を予め関連付けた関連付けグループを保持する関連付けグループ保持手段をさらにそなえるとともに、該連携情報登録制御手段が、該受信手段で受信した連携情報に含まれる該第１の識別子が属する関連付けグループを該関連付けグループ保持手段において検索する検索手段と、該検索手段により検索された関連付けグループと該受信手段で受信した連携情報に含まれる該第２の識別子とを関連付けて該記憶手段に登録する登録手段と、該検索手段により検索された関連付けグループに属する各識別子を該第２の装置に通知する通知手段とをそなえていてもよい。
【００１６】
また、該連携情報登録制御手段は、該第２の装置から特定の第１の識別子についての一部削除要求を受けると、当該第１の識別子を該記憶手段の連携情報から削除する連携情報一部削除手段をそなえていてもよい。
さらに、該連携情報登録制御手段は、該第２の装置から該関連付けグループについての全削除要求を受信すると、当該関連付けグループと該第２の識別子との関連付け情報である連携情報を該記憶手段から削除する連携情報全削除手段をそなえていてもよい。
【００１７】
また、本連携情報管理装置は、複数の該第１の装置についての第１の識別子同士の親子関係による階層的な関連付けグループを保持する階層関連付けグループ保持手段をさらにそなえるとともに、該連携情報登録制御手段が、該受信手段で受信した連携情報に含まれる該第１の識別子が上位階層の識別子として属する関連付けグループを該階層関連付けグループ保持手段において検索する検索手段と、該検索手段により検索された階層関連付けグループの該上位階層の識別子及び当該識別子と関連付けられた下位階層の識別子と、該受信手段で受信した連携情報に含まれる該第２の識別子とを関連付けて該記憶手段に登録する登録手段と、該検索手段により検索された関連付けグループに属する各識別子を該第２の装置に通知する通知手段とをそなえていてもよい。
【００１８】
さらに、本発明の連携情報管理装置は、第１の識別子を保有する第１の装置と、第２の識別子を保有するとともに該第１の識別子を該第１の装置から読み取って当該第１の識別子と該第２の識別子との組を連携情報として送信しうる第２の装置とをそなえたシステムに用いられ、該連携情報を管理するものであって、該第１の装置を使用中の該第２の装置数（以下、現使用数という）と当該第１の装置を共用できる該第２の装置数の上限値とを該第１の識別子別に保持する共用数保持手段と、該第２の装置から該連携情報を受信すると、当該連携情報に含まれる上記各識別子と該共用数保持手段における該現使用数及び該上限値とに基づいて、当該第２の装置による当該第１の装置の共用を制御する共用制御手段とをそなえたことを特徴としている。
【００１９】
また、本発明の連携情報管理装置は、他装置によって読み取られる第１の識別子を保有する第１の装置と、第２の識別子を保有するとともに該第１の識別子を該第１の装置から読み取って当該第１の識別子と該第２の識別子との組を連携情報として送信しうる第２の装置と、該第１の装置としての機能と該第２の装置としての機能とを兼ね備えた第３の装置とをそなえたシステムに用いられ、該連携情報を管理するものであって、該第３の装置が該第１の装置から読み取った該第１の装置の第１の識別子と該第３の装置が保有する第２の識別子との組を該第３の装置から第１の連携情報として受信する第１の受信手段と、該第１の装置の該第１の識別子の読み取りを行なった該第３の装置から該第２の装置が読み取った該第３の装置が保有する第１の識別子と当該第２の装置が保有する第２の識別子との組を該第２の装置から第２の連携情報として受信する第２の受信手段と、該連携情報を記憶する記憶手段と、該第１の受信手段で受信した該第１の連携情報と該第２の受信手段で受信した該第２の連携情報とを関連付けて該記憶手段に登録する連携情報登録制御手段とをそなえたことを特徴としている。
【００２０】
ここで、該連携情報登録制御手段は、該第３の装置から該関連付けの解除要求を受信すると、該記憶手段の該第１の連携情報と該第２の連携情報との関連付けを削除する関連付け削除手段をそなえていてもよい。
また、該連携情報登録制御手段は、該記憶手段において該第１の連携情報と該第２の連携情報との関連付けの生成／解除を監視する監視手段と、該監視手段にて該関連付けの生成が確認されると、該第１の装置を使用している装置が該第３の装置から該第２の装置に変更されたと認識して、該第１の装置に関する情報の送信先を該第２の装置に変更する指示を該第１の装置に関する情報の送信元に送信し、該監視手段にて該関連付けの解除が確認されると、該第１の装置を使用している装置が該第２の装置から該第３の装置に変更されたと認識して、該第１の装置に関する情報の送信先を該第３の装置に変更する指示を該送信元に送信する送信先変更指示手段とをそなえていてもよい。
【００２１】
さらに、本発明のゲートウェイ装置は、第１の識別子を保有する第１の装置と、第２の識別子を保有するとともに該第１の識別子を該第１の装置から読み取って当該第１の識別子と該第２の識別子との組を連携情報として送信しうる第２の装置と、該連携情報を受信して管理する連携情報管理装置と、該第１の装置に関する情報を送信する情報提供サーバとをそなえた連携情報管理システムに用いられるものであって、該情報提供サーバが該第１の装置の該第１の識別子を読み取った該第２の装置宛に該第１の装置に関する情報を送信するために必要な該第２の識別子を該連携情報管理装置から受信する受信手段と、該受信手段で受信した該第２の識別子を該情報提供サーバへの通知のための他の識別子に変換する識別子変換手段と、該識別子変換手段による変換後の識別子を該情報提供サーバへ送信する送信手段と、該情報提供サーバからの該情報に付与された該変換後の識別子を該変換前の識別子に逆変換して該第２の装置宛に転送する情報転送手段とをそなえたことを特徴としている。
【発明の効果】
【００２２】
上記の本発明の連携情報管理装置によれば、第２の装置により使用される第１の装置（オブジェクト）を管理する場合において、第１の装置を単独の装置としてではなく、第１の装置の集合体として管理することができる。したがって、例えば、プリンタトナーやマウスなど、単独では動作不可なオブジェクトを、予めプリンタ及びプリンタトナーの集合体，ノートＰＣ及びマウスの集合体等として管理することができ、ユーザの観点から効率的な管理を実現することが可能となる。その結果、オブジェクト集合体を使用するためのユーザによる明示的な連携情報管理装置への登録（アクセス）回数を大幅に低減することが可能となる。
【００２３】
また、本発明の連携情報管理装置によれば、連携情報管理装置を用いて第１の装置（オブジェクト）のリアルタイムな使用状況や同時使用可能数等の使用条件に応じた第２の装置へのオブジェクトの割当てが可能となるので、オブジェクトが例えば公共アプライアンスやキオスク端末等のように、同時に複数のユーザにより使用されるようなものである場合に、当該オブジェクトの同時使用可能数及びリアルタイムな現使用数を管理することが可能となり、より実用的かつ動作可能なネットワークアーキテクチャを実現できる。
【００２４】
さらに、本発明の連携情報管理装置によれば、第３の装置を使用しているユーザが意図的に、第２の装置を用いて、第３の装置の識別子を読み取ることによって、ユーザが使用装置を第３の装置から第２の装置に変更して第３の装置が使用している第２の装置としての機能を一時的に第２の装置に移動させることが可能であり、このような場合においても、第１の装置に関する情報を当該第２の装置にて正常に継続受信させることが可能となる。したがって、ユーザは、例えば、情報受信のための第３の装置の性能が不足あるいは不十分な場合に、使用中の第３の装置を十分な性能をもつ第２の装置に読み取らせて当該第２の装置を動作させることにより当該第２の装置にて情報受信を継続して行なうことができる。
【００２５】
また、本発明のゲートウェイ装置によれば、情報提供サーバが連携情報管理装置へ、連携情報、即ち、第１の装置（第１の識別子）に関連付けられた第２の装置（第２の識別子）についての問い合わせを行なった場合に、この問い合わせによって返信される第２の識別子を、情報提供サーバに通知を行なうための他の識別子に変換するので、連携情報に関するプライバシーを秘匿（隠蔽）しつつ、第２の装置に対する所望のデータ転送を実現することが可能となる。
【発明を実施するための最良の形態】
【００２６】
〔Ａ〕概要
本発明は、先の出願（国際出願番号：ＪＰ０３／０２４９８）に係る発明に関連する技術である。当該先の出願においては、実世界に散在するオブジェクト（例えば、RF-IDタグを取り付けた商品や電気製品等）の属性やロケーションの属性（その位置の特性を現すタグ属性。例えば、「会議室」などがある）の属性を基に、特定のオブジェクトとの対応関係（連携情報）をもった（一定のコンテキストを満たした）サービス利用者へのコンテンツ（広告情報等）転送等の「コンテキスト・アウェア」サービスを実現する一手法を提案しているが、下記に示すような検討事項があった。
【００２７】
(1)ネットワークが大規模化した場合に、これに対応して連携情報の登録、更新、削除当の操作を高速かつ効率的に行なう（スケーラビリティを確保する）ための機構について検討の余地があった。
(2)先の出願においては、アプライアンスと、そのアプライアンスを使用するユーザとの対応を１対１と想定していたが、サービスが複雑化すると、アプライアンスと、そのアプライアンスを使用するユーザとの関係は、必ずしも１対１とはならない。例えば、プリンタ等の共有使用が想定されるケースのように１対多の関係も想定される。したがって、このようなケースに対応した連携情報の管理機構が必要である。
【００２８】
(3)先の出願では、ＧＮ（Global Node）において、オブジェクトの属性をベースとしたコンテンツ等の受信が可能であるが、ＧＮにて、性能面、搭載アプリケーション、コンテンツ受信インタフェース等に関して制約事項が発生するケースについて検討が不十分であった。特に、コンテンツの送信を行なうサーバ等が、当該コンテンツを受信するノードの性能面(メモリ容量や、CPU速度、インタフェース速度等)を把握できない場合などにおいて、コンテンツを受信する性能が不足する状態が発生する可能性がある。したがって、このような場合においても適切なコンテンツ受信を可能にする必要がある。
【００２９】
(4)先の出願においては、異事業者ネットワークを経由する通信が行なわれる場合に、ある事業者のネットワークが、他事業者のネットワーク内ノードに対して、特定のＩＰアドレスを有するユーザの連携情報を直接的に提供してしまうため、ユーザのタグ情報に基づいたロケーションプライバシーや、ユーザが保有する「物」についての秘匿性に関する保護が十分でなかった。したがって、これらユーザに関するプライバシー情報の保護を十分に図ることのできる機構が必要である。
【００３０】
本発明は、このような検討事項に鑑みてなされたもので、先の出願で提案したオブジェクト（ＬＮ）の連携管理機構を改良・高機能化して、前記のとおり、下記を実現するものである。
(1)オブジェクト同士のスケーラビリティを考慮した管理によるネットワーク構築および運用コストの低減。
【００３１】
(2)単一のアプライアンスを複数ユーザで共用（多重的な連携）することを可能とする、拡張連携情報管理機構。
(3)ノード間において、ＧＮ機能の移動を行なうことによって、ＧＮとして機能するノードの性能面についての制約等を解消。
(4)異種事業者ネットワーク間通信時のプライバシー情報（連携情報）の保護機構。
【００３２】
これらを実現するために、本発明では、
(a)連携情報のグループ化／階層化によるオブジェクト群の管理、
(b)アプライアンスについての同時使用可能数および現在の使用者数の管理、
(c)ＧＮとＬＮの双方の機能を有するノード（ＤＮ：Global-Local Dual function Node）を導入してＧＮとして一次的に機能するノードの切り替え、
(d)ゲートウェイ装置の導入によるプライバシー情報（端末アドレス等）の隠蔽
を行なう。
【００３３】
本発明によって、オブジェクト群の管理やネットワーク端末機能の移動に対してスケーラブルかつ柔軟に対応可能な通信プラットフォームが実現可能である。
〔Ｂ〕一実施形態の説明
以下、本発明の実施形態について、図面を参照しながら説明する。
図１は本発明の一実施形態に係る連携情報管理システムの構成を示すブロック図で、この図に示す連携情報管理システムは、ＩＰネットワークやＷＡＮ（Wide Area Network）等のネットワーク３に設けられた連携管理機構（連携情報管理装置）１を構成するGN-HA１１及びLN-HA１２と、ゲートウェイ装置（以下、単に「ゲートウェイ」という）２とをそなえるとともに、連携管理機構１（GN-HA１１）とネットワーク３経由で通信し得るＧＮ（ここでは、４台）４−１〜４−４、当該ＧＮ４−ｉ（ｉ＝１〜４）と通信し得るＬＮ５−１〜５−５及びＤＮ６をそなえて構成されている。なお、この図１において、ＬＮ５−１，５−２，５−３は、単一のオブジェクト群５を形成しており、ＬＮ５−４は、ＬＮの機能とＧＮの機能とを兼ね備えたＤＮ６と通信し、ＤＮ６は、ＧＮ４−１と通信し得ることを表しており、また、ＬＮ５−５は、ＧＮ４−３，４−４のいずれとも通信し得ることを表している。
【００３４】
ここで、ＬＮ（第１の装置）５−ｊ（ｊ＝１〜５）は、それぞれ、例えば、機能種別，製造番号等の自身の個別識別情報〔LN-ID（第１の識別子）〕を記憶する個別識別情報記憶部５１（図３により後述）をそなえたRF-IDタグのような装置で、無線インタフェース等を介してＧＮ４−ｉ（あるいはＤＮ６）と通信して、自身のLN-IDをＧＮ４−ｉ（あるいはＤＮ６）へ送信することができるものである。
【００３５】
なお、このＬＮ５−ｊには、例えば、公共アプライアンス（公共性の高い場所に設置され、一定の許可の下に不特定多数の者が利用できることを想定した装置類）や、一時貸出し型（通称：キオスク）端末等も含まれる。また、これらＬＮ５−ｊとＧＮ４−ｉとの間の通信は、RF-IDタグ（ＬＮに相当）からRF-IDリーダ（ＧＮに相当）への通信のように一方向通信であってもよいし、ブルートゥース（Bluetooth）等を用いた双方向通信であってもよい。
【００３６】
ＧＮ４−ｉ（第２の装置）は、それぞれ、ＬＮ５−ｊを読み取る無線タグリーダのような装置で、ネットワーク３との通信機能を有し、連携管理機構（GN-HA１１）と無線又は有線により通信可能に接続されて、ＬＮ５−ｊとＧＮ４−ｉとの連携情報を連携管理機構１（GN-HA１１）に登録することができるものである。
ＤＮ（第３の装置）６は、上記のＬＮ５−ｊとしての機能とＧＮ４−ｉとしての機能を兼ね備えた装置、即ち、自身がＧＮとして機能する場合に、ＬＮ５−ｊと通信してそのLN-IDを読み取って自身が保有するGN-IDとともにGN-HA１２宛に連携情報として送信するとともに、自身がＬＮとして機能する場合にＧＮ４−ｉと通信してＧＮ４−ｉに読み取られるLN-IDとして自身が保有するLN-IDをＧＮ４−ｉに送信しうる機能をそなえるものである。
【００３７】
（Ｂ１）ＧＮの機能説明
このため、まず、上記のＧＮ４−ｉは、例えば図２に示すように、局所（ローカル）ネットワークインタフェース４１，ＬＮ情報収集部（RF-IDリーダ等）４２，ＬＮ情報抽出部４３，ＧＮ個別識別情報記憶部４４，広域（グローバル）位置登録機能部４５及び広域（グローバル）ネットワークインタフェース４６をそなえて構成されている。
【００３８】
ここで、局所ネットワークインタフェース４１は、図示しない無線インタフェース等を介してＬＮ５−ｊと通信するためのインタフェースであり、ＬＮ情報収集部４２は、ＬＮ５−ｊから受信される情報（メッセージ）を収集するためのものであり、ＬＮ情報抽出部４３は、このＬＮ情報収集部４３で収集された情報からＬＮ５−ｊに固有の識別情報（LN-ID）を抽出するものである。
【００３９】
ＧＮ個別識別情報記憶部（メモリ）４４は、ＧＮ４−ｉに固有の識別情報〔第２の識別子（GN-ID）〕を記憶するものである。なお、このGN-IDには、例えば、ＩＰアドレスのようなネットワークにおいて一意にＧＮ４−ｉを識別できる情報を用いる。
広域位置登録機能部（位置制御プロトコルスタック）４５は、このＧＮ個別識別情報記憶部４４に記憶されているGN-IDと、上記ＬＮ情報抽出部４３で抽出されたLN-IDとの組を連携情報として広域ネットワークインタフェース４６及び図示しないＩＰインタフェース等を通じてGN-HA１１宛へ送信するためのものである。なお、「プロトコルスタック」とは、一般に、ネットワーク上で特定の機能を実現するために必要なプロトコルを選び階層状に積み上げたソフトウェア群を意味する。
【００４０】
（Ｂ２）ＬＮの機能説明
一方、上記のＬＮ５−ｊは、例えば図３に示すように、個別識別情報記憶部（メモリ）５１，読み取り要求検出部５２，読み取り要求応答部５３及び情報読み取りインタフェース５４をそなえて構成される。
ここで、上記の個別識別記憶部５１は、自身を識別する識別情報、あるいは、RF-IDタグの場合のように自身が取り付けられるオブジェクト（アプライアンス）を識別する識別情報（LN-ID）を記憶しておくものであり、読み取り要求検出部５２は、ＧＮ５−ｊからのLN-IDの読み取り要求を検出するもので、当該読み取り要求を検出すると、上記個別識別情報記憶部５１からLN-IDを読み出して読み取り要求応答部５３へ転送するものである。
【００４１】
読み取り要求応答部５３は、上記読み取り要求検出部５２から転送されてきたLN-IDを上記読み取り要求に対する応答として、情報読み取りインタフェース５４を通じて読み取り要求元のＧＮ４−ｉへ送信するためのものである。情報読み取りインタフェース５４は、上記読み取り要求の受信及び上記応答（LN-ID）の送信機能をそなえるものである。
（Ｂ３）GN-HAの機能説明
次に、前記GN-HA１１は、例えば図４に示すように、アクセス側ネットワークインタフェース１１１，連携情報抽出部１１２，広域位置登録機能部（位置制御プロトコルスタック）１１３，ＧＮ位置（連携）情報データベース（ＤＢ）１１４，LN-HA連携機能部１１５及びコア側ネットワークインタフェース１１６をそなえて構成される。
【００４２】
ここで、アクセス側ネットワークインタフェース１１１は、ＧＮ４−ｉとの通信インタフェースで、前記のLN-IDの読み取り要求送信機能及びその応答受信機能をそなえるものであり、連携情報抽出部１１２は、このインタフェース１１１を通じて受信される前記読み取り要求に対する応答から連携情報（LN-IDとGN-IDの対応）を抽出するものであり、広域位置登録機能部１１３は、このＬＮ情報抽出部１１２で抽出された連携情報をＧＮ連携情報ＤＢ（記憶部）１１４に記憶するとともに、当該連携情報をLN-HA１２へ送信すべくLN-HA連携機能部１１５へ転送する機能を有するものである。なお、ＧＮ連携情報ＤＢ１１４は、ＲＡＭやハードディスク等の所要の記録媒体を用いて実現される。また、内蔵型、外付け型のいずれを用いてもよい。
【００４３】
LN-HA連携機能部１１５は、上記広域位置登録機能部１１３から転送されてきたLN-IDとGN-IDの連携情報をＬＮ位置（連携）情報メッセージとして、コア側ネットワークインタフェース１１６を介してLN-HA１２へ送信するためのものであり、コア側ネットワークインタフェース１１６は、LN-HA１２との通信インタフェースである。
上述のごとく構成されたGN-HA１１は、ＧＮ４−ｉからの応答（連携情報の登録）を受信すると、連携情報抽出機能部１１２によって連携情報の抽出を行ない、広域位置登録機能部１１３によってＧＮ連携情報ＤＢ１１４に格納する。また、格納したLN-IDとGN-IDの連携情報を、LN-HA連携機能部１１５によってLN-HA１２に送信する。以後、GN-HA１１は、GN -IDとLN-IDの対応（連携情報）についてリアルタイムに管理(登録，更新，削除)を行なって、常時、最新の連携情報を管理する。
【００４４】
なお、本実施形態において、GN-HA１１は、その図示を省略するが、GN-ID（GN-IPアドレス）宛に受信データ（ＧＮ４−ｉのユーザのための広告情報等のコンテンツデータ等）をルーティングする機能も有している。
（Ｂ４）LN-HAの機能説明
次に、前記のLN-HA１２は、例えば図５に示すように、アクセス側ネットワークインタフェース１２１，ＬＮ位置（連携）情報登録メッセージ処理部１２２，局所位置登録機能部（位置制御プロトコルスタック）１２３及びLN位置（連携）情報データベース（ＤＢ）１２４をそなえて構成される。
【００４５】
ここで、上記のアクセス側ネットワークインタフェース１２１は、GN-HA１１との通信インタフェースで、GN-HA１１のLN-HA連携機能部１１５から送信されてくる上記ＬＮ位置（連携）情報メッセージの受信手段としての機能を有するものであり、ＬＮ位置（連携）情報登録メッセージ処理部１２２は、上記インタフェース１２１で受信されたＬＮ位置（連携）情報登録メッセージを処理（メッセージ内容の解析等）して連携情報を抽出する機能を有するものであり、局所位置登録機能部１２３は、このＬＮ位置（連携）情報登録メッセージ処理部１２２から転送されてくる連携情報をＬＮ位置（連携）情報ＤＢ（記憶手段）１２４に記憶・格納する機能を有するものである。
【００４６】
上述のごとく構成されたLN-HA１２は、GN-HA１１から連携情報の登録メッセージを受信すると、当該メッセージをＬＮ位置（連携）情報登録メッセージ処理部で処理し、広域位置登録機能部１２３によって、連携情報をＬＮ位置（連携）情報ＤＢ１２４に格納する。以後、LN-HA１２は、LN-IDとGN-IDの対応（連携情報）についてリアルタイムに管理（登録，更新，削除）を行ない、常時、最新の連携情報を管理する。なお、このLN-HA１２は、オブジェクトの管理事業者ごとに配備される。
【００４７】
（Ｂ５）ゲートウェイの機能説明
次に、本実施形態の前記ゲートウェイ２の機能について説明する。
上述した連携管理システムにおいて、例えば、連携管理機構１（GN-HA１１）の運用管理事業者（例えば、ネットワークキャリアのような移動ＩＰ端末の加入者情報を保有する事業者）のネットワークと、ＧＮ４−ｉ宛に広告情報等のコンテンツデータを配信する事業者のネットワークとが異なる場合、これら異事業者ネットワーク間の通信に用いるＩＤとしてGN-ID（ＩＰアドレス）をそのまま用いると、加入者情報と対応付けられる可能性のあるＩＰアドレスと加入者の連携（利用）するオブジェクトとの関連付けが異事業者に漏洩する可能性がある。
【００４８】
そこで、本例では、異なる事業者ネットワーク間に配備されるゲートウェイ２にて、通信に用いるＩＤ（GN-ID）の変換を行なうことによって、加入者の連携情報プライバシー（どのようなアプライアンスを所持し、あるいは、どのようなオブジェクトの近傍に位置しているか等の、第三者に公開を許可／抑制したい個人情報の一種）を保護する機構を導入する。
【００４９】
（Ｂ５．１）GN-HA１１とLN-HA１２が同一事業者のネットワーク内に存在する場合
例えば図９に示すように、GN-HA１１とLN-HA１２がいずれも第一種電気通信事業者のようなネットワークキャリアの管理下にあるネットワーク（キャリアネットワーク）３内に存在し、当該キャリアネットワーク３と、ASP（Application Service Provider）やISP（Internet Service Provider）等といった、キャリアとは異なる事業者（xSP）の管理下にあるネットワーク（xSPネットワーク）７との境界に、ゲートウェイ２が存在し、xSPが運用・管理する、xSPネットワーク７上の情報提供サーバ（xSPサーバ）７１からＧＮ４−ｉ宛に広告情報等のコンテンツデータを配信する場合を想定する。
【００５０】
（Ｂ５．１．１）機能説明
この場合、ゲートウェイ２は、例えば図６に示すように、LN-HAアドレスデータベース（ＤＢ）２１，ＩＰアドレス対応データベース（ＤＢ）２２，ＩＰデータ送受信機能部２３，２６，LN-ID抽出機能部２４，GN-IPアドレス取得機能部２５及びＩＰアドレス変換機能部２７をそなえて構成される。
【００５１】
ここで、上記のLN-HAアドレスＤＢ２１は、LN-HA１２のＩＰアドレスを記憶するものであり、ＩＰアドレス対応ＤＢ２２は、キャリアネットワーク３側で使用するGN-ID（GN-IPアドレス）と、xSPネットワーク７側で使用する、変換先のGN-IP′アドレスとを対応付けたGN-IPアドレス表（変換表）を記憶するものである。
ＩＰデータ送受信機能部２３は、xSPサーバ７１との間の通信インタフェースで、ＩＰレイヤ及びＩＰレイヤよりも上位レイヤのメッセージインタフェースを有するものであり、もう１つのＩＰデータ送受信機能部２６は、GN-HA１１及びLN-HA１２との間の通信インタフェースで、LN-HA１２に対しては、ＩＰレイヤよりも上位レイヤのメッセージインタフェース、GN-HA１１に対しては、ＩＰレイヤでのメッセージインタフェースを有するものである。なお、ＩＰレイヤよりも上位レイヤのメッセージインタフェースの例としては、SOAP（Simple Object Access Protocol）通信によるWebインタフェース等が含まれる。
【００５２】
LN-ID抽出機能部２４は、xSPサーバ７１が例えばＬＮ５−ｊに応じた広告情報等のコンテンツデータを対応するＧＮ４−ｉ宛に配信するためにLN-IDを用いてGN-IDの問い合わせをGN-IPアドレス要求メッセージ（図８の項番１参照）により行なった際に、当該メッセージに含まれるLN-IDを抽出するものであり、GN-IPアドレス取得機能部２５は、このLN-ID抽出機能部２４により抽出されたLN-IDに対応するGN-IDを取得するために、LN-HAアドレスＤＢ２１を参照して該当LN-HA１２宛のGN-IPアドレス要求メッセージ（図７の項番１参照）を作成する機能と、当該メッセージに対する応答であるGN-IPアドレス応答メッセージ（図７の項番２参照）に含まれるGN-IPアドレスを抽出する機能とを有するものである。
【００５３】
ＩＰアドレス変換機能部（識別子変換手段）２７は、(1)上記のGN-IPアドレス取得機能部２７によってLN-HA１２から取得された、xSPサーバ７１から通知を受けたLN-IDに対応するGN-IPアドレスと、当該GN-IPアドレスの変換先のGN-IP′アドレスとを対応付けて前記変換表としてＩＰアドレス対応ＤＢ２２に記憶する記憶制御機能と、(2)ＬＮ５−ｊに対応するＧＮ４−ｉへのコンテンツ配信時に使用すべき宛先アドレスとして当該変換先GN-IP′アドレスをGN-IPアドレス応答メッセージ（図８の項番２参照）によりxSPサーバ７１に通知する通知機能と、(3)xSPサーバ７１から受信されるコンテンツデータ（ＩＰデータ）の宛先アドレス（GN-IP′アドレス）を、GN-IPアドレス対応ＤＢ２２を参照して、元の（キャリアネットワーク３側で使用する）GN-IPアドレスに変換するGN-IPアドレス変換機能とを兼ね備えるものである。
【００５４】
なお、上記のゲートウェイ２−LN-HA１２間及びゲートウェイ２−xSPサーバ７１間でそれぞれ送受されるGN-IPアドレス要求／応答メッセージは、いずれも、ＩＰデータ送受信機能部２３，２６により、ＩＰ上位レイヤメッセージとして送受される。
上述のごとく構成されたゲートウェイ２をキャリアネットワーク３とxSPネットワーク７との間に配置することにより、xSPに対してGN-IPアドレス（GN-ID）を秘匿、即ち、連携管理機構１で管理している連携情報に関するプライバシーを秘匿しつつ、ＧＮ４−ｉに対してＬＮ５−ｊに応じた必要なコンテンツ配信を実現することが可能となる。
【００５５】
（Ｂ５．１．２）動作説明
以下、かかるゲートウェイ２を含むネットワーク動作について、図９及び図１０を参照しながら説明する。
まず、前記先の出願と同様の手順に従って、ＬＮ５−ｊのRF-ID、即ちLN-IDがＧＮ４−ｉに読み取られると（図９のステップＡ１）、ＧＮ４−ｉからGN-HA１１に対してLN-IDとGN-ID（GN-IPアドレス）の対応が連携情報として通知され、GN-HA１１は、当該連携情報を、GN-IPアドレスをキーとしてＧＮ連携情報ＤＢ１１４（図４参照）に登録（記憶）するとともにLN-HA１２に通知し、LN-HA１２は、GN-HA１１から通知された連携情報を、LN-IDをキーとしてＬＮ連携情報ＤＢ１２４（図５参照）に登録（記憶）する（図９のステップＡ２）。
【００５６】
ここで、ＬＮ５−ｊ（LN-ID）に関連するサービスの提供を開始するxSPサーバ７１は、ゲートウェイ２に対して、ＬＮ５−ｊのLN-IDを読み取ったＧＮ４−ｉ宛にＬＮ５−ｊに関する情報を送信するのに必要なGN-IPアドレスを取得するためにGN-IPアドレス要求メッセージによりLN-IDの通知を行なう(図９のステップＡ３)。ゲートウェイ２は、この要求メッセージを受信すると（図１０のステップＢ１）、当該メッセージに含まれるLN-IDに対応するGN-IPアドレスを、GN-IPアドレス取得機能部２５及びＩＰデータ送受信機能部２６を通じて、GN-IPアドレス要求メッセージによりLN-HA１２に問い合わせることによって取得する(図９のステップＡ４及び図１０のステップＢ２，Ｂ３)。
【００５７】
そして、ゲートウェイ２は、LN-HA１２からＩＰデータ送受信機能部（受信手段）２６を通じて受信したGN-IDアドレスを、ＩＰアドレス変換機能部２７によって、自ゲートウェイ２にルーティングされるGN-IP′アドレス（サーバ通知用のアドレス）に変換して(図１０のステップＢ４)、GN-IPアドレス表（変換表）を作成し（図９のステップＡ５）、GN-IPアドレス対応ＤＢ２２に記憶するとともに、LN-HA１２から取得したGN-IPアドレスに対応するGN-IP′アドレスをxSPサーバ７１にＩＰデータ送受信機能部（送信手段）２３を通じGN-IPアドレス応答メッセージにより通知（送信）する（図９のステップＡ６及び図１０のステップＢ５）。
【００５８】
その後、xSPサーバ７１は、ゲートウェイ２より通知されたGN-IP′アドレスを宛先アドレスとしてＩＰデータを送信する (図９のステップＡ７)。ゲートウェイ２は、当該GN-IP′アドレス宛のデータ（上記変換後のGN-IP′が付与されたデータ）を受信すると（図１０のステップＢ６）、ＩＰアドレス変換機能部２７によって、GN-IPアドレス対応ＤＢ２２のGN-IPアドレス表を参照し、再度、GN-IP′アドレスを元のGN-IPアドレスに変換（逆変換）してＩＰデータ送受信機能部２６を通じGN-HA１１へ転送する（図１０のステップＢ７）。
【００５９】
つまり、上記のＩＰアドレス変換機能部２７及びＩＰデータ送受信機能部２６は、xSPサーバ７１からのＩＰデータに付与された上記変換後のGN-IP′アドレスを変換前のGN-IPアドレスに逆変換して当該アドレスをもつＧＮ４−ｉ宛に転送する情報転送手段として機能する。これにより、GN-IP宛のデータはGN-HA１１に到達し、GN-HA１１によりルーティングされて、最終的に、ＧＮ４−ｉへ転送される(図９のステップＡ８)。
【００６０】
以上のようにして、本実施形態では、異事業者ネットワーク３，７間にゲートウェイ２を導入することによって、あるサーバ７１が連携管理機構１へ、連携情報、即ち、LN-IDに関連付けられたGN-IDについての問い合わせを行なった場合に、この問い合わせによって返信されるGN-IDを、異事業者に通知を行なうための他のＩＤに変換することができるので、異事業者（xSP）に対して自ネットワーク加入者の連携情報に関するプライバシーを秘匿（隠蔽）しつつ、ＧＮ４−ｉに対する所望のデータ転送を実現することが可能となる。
【００６１】
特に、上記のようにGN-HA１１がモバイルIPのホームエージェントとしての機能を兼ねる場合において、ＧＮ４−ｉがルート最適化（目的ノードまでの最短経路化）の要求を送信するノードは、xSPサーバ７１ではなく、ゲートウェイ２であるため、モバイルＩＰ適用時においてのゲートウェイ２は、xSPサーバ７１−GN-HA１１間の中継ノードのみならず、キャリアネットワーク３内のルート最適化ノードとして機能する。このため、キャリアネットワーク３において、ＧＮ４−ｉ宛のデータの大半は、GN-HA１１を経由する必要がなくなる。これは、キャリアネットワーク３内のネットワークリソースを節約するのみならず、GN-HA１１のパケット転送負荷を大幅に低減できるという利点がある。
【００６２】
さらに、単一のネットワークキャリアのネットワーク３に、xSP事業者のネットワーク７が複数接続するような場合において、(1)ゲートウェイ２の固定化、(2)ゲートウェイ２においてのルート最適化を行なうことは、通信プラットフォームの簡素化につながり、ネットワークキャリアは、ゲートウェイ２を含む自ネットワーク領域でのデータ転送を主な機能とし、xSPは、ゲートウェイ２によって変換されたアドレス宛にデータを送信することを主な機能として、役割分担することができるため、キャリア、xSP双方の機能配備の面においても、本例のようなアーキテクチャは非常に有効である。
【００６３】
（Ｂ５．２）GN-HA１１とLN-HA１２が異なる事業者のネットワーク内に存在する場合
次に、上記項目（Ｂ５．１）で述べたシステム構成の変形例として、例えば図１６に示すように、GN-HA１１が第一種電気通信事業者のようなネットワークキャリアの管理下にあるネットワーク（キャリアネットワーク）３内に存在し、LN-HA１２がASPやISP等のキャリアとは異なる事業者（xSP）の管理下にあるxSPネットワーク７内に存在し、これらのネットワーク３，７間にゲートウェイ２が存在する場合を想定する。つまり、この図１６に示す例は、LN-HA１２がxSPネットワーク７に属している点が図９に示す例と相違している。
【００６４】
これは、ＬＮ５−ｊが必ずしも、GN-HA１１と同じネットワーク事業者によって管理される必要はなく、xSPが独自に、LN-HA１２を配置することによって、xSPの保有するLN-ID情報(例えば、ユーザのＩＤカード等)を用いたサービスを実現するような形態のネットワーク構成例を示している。
（Ｂ５．２．１）機能説明
この場合のゲートウェイ２は、例えば図１１に示すように、既述のLN-HAアドレスＤＢ２１，ＩＰアドレス対応ＤＢ２２をそなえるほか、ＩＰデータ送受信機能部２３′，２６′，LN-ID抽出機能部２４′，ＩＰアドレス変換機能部２７′及びLN-HA通知機能部２８をそなえて構成される。
【００６５】
ここで、ＩＰデータ送受信機能部２３′は、xSPサーバ７１及びLN-HA１２との間の通信インタフェースで、xSPサーバ７１に対してはＩＰレイヤのメッセージインタフェース、LN-HA１２に対してはＩＰレイヤよりも上位のメッセージインタフェースを有するものであり、もう１つのＩＰデータ送受信機能部２６′は、GN-HA１１との間の通信インタフェースで、ＩＰレイヤでのメッセージインタフェースとＩＰレイヤよりも上位のメッセージインタフェースとを有するものである。なお、本例においても、ＩＰレイヤよりも上位レイヤのメッセージインタフェースの例としては、SOAP（Simple Object Access Protocol）通信によるWebインタフェース等が含まれる。
【００６６】
LN-ID抽出機能部２４′は、GN-HA１１から連携情報登録メッセージ（図１３の項番１参照）により通知されてくる情報（LN-ID，GN-IPアドレス，LN-HA１２のＩＰアドレス）からLN-IDを抽出する機能を有するものであり、ＩＰアドレス変換機能部２７′は、(1)GN-HA１１から通知されるGN-IPアドレスと、当該GN-IPアドレスの変換先のGN-IP′アドレスとを対応付けてＩＰアドレス表（変換表）としてＩＰアドレス対応ＤＢ２２に記憶する記憶制御機能と、(2)LN-HA１２のＩＰアドレス（以下、LN-HAアドレスと表記する）を含む上記連携情報登録メッセージについて、その送信元ＩＰアドレスを、GN-HA１１からＧＮ４−ｉの代替として送信されるGN-IPアドレスから、自ゲートウェイ２にルーティングされるGN-IP′アドレスに変換する変換機能とを兼ね備えるものである。
【００６７】
そして、LN-HA通知機能部２８は、上記ＩＰアドレス変換機能部２７′によって変換された変換後のGN-IP′アドレスを送信元アドレスとする上記連携情報登録メッセージの宛先アドレスを、LN-HAアドレスＤＢ２１を参照して、LN-HAアドレスとし、GN-HA１１からの上記連携情報登録メッセージを、ＩＰデータ送受信機能部２３′を通じてLN-HA１２宛に中継するための機能を有するものである。なお、LN-HA１２へ中継される連携情報登録メッセージの内容は図１４の項番１に示す通りである。また、上記連携情報登録メッセージも、ＩＰ上位レイヤメッセージとして送受される。
【００６８】
ところで、本例の場合、GN-HA１１は、連携情報登録メッセージを送信すべきLN-HA１２に対応するゲートウェイ２を特定して、そのゲートウェイ２に連携情報登録メッセージを送信する必要があるので、図１２に示すように、LN-HA−ゲートウェイアドレス対応データベース（ＤＢ）１１７が付加されており、LN-HA連携機能部１１５が、このＤＢ１１７を参照することで、上記連携情報登録メッセージを該当ゲートウェイ２宛に送信できるように構成される。
【００６９】
また、本例の場合、ゲートウェイ２及びLN-HA１２は、それぞれ、上記連携情報登録メッセージに対する応答として、連携情報の登録処理結果（ＯＫ又はＮＧ）を連携情報応答メッセージ（図１３及び図１４の項番２参照）により返信する応答機能をも有している。この応答機能は、ゲートウェイ２では、例えばＩＰデータ送受信機能部２３′，２６′の一機能として実現でき、LN-HA１２では、例えばＬＮ位置（連携）情報登録メッセージ処理部１２２（図５参照）の一機能として実現できる。なお、上記連携情報応答メッセージも、ＩＰ上位レイヤメッセージとして送受される。
【００７０】
そして、本例の場合、xSPサーバ７１は、ＬＮ５−ｊのLN-IDを読み取ったＧＮ４-ｉに対してサービスを開始するにあたって、LN-HA１２に対して連携情報検索メッセージ（図１５の項番１参照）を発行することにより、LH-HA１２のＬＮ連携情報ＤＢ１２４からLN-IDに対応するGN-IP′アドレスの検索を依頼し、その検索結果を連携情報応答メッセージ（図１５の項番２参照）により取得して、当該取得したGN-IP′宛にデータを送信するように構成される。なお、上記の連携情報検索／応答メッセージも、ＩＰ上位レイヤメッセージとしてLN-HA１２−xSPサーバ７１間を送受される。また、LN-HA１２でのGN-IP′アドレス検索機能や検索結果応答としての連携情報応答メッセージの作成機能は、例えば、ＬＮ連携情報登録メッセージ処理部１２２（図５参照）の一機能として実現できる。
【００７１】
（Ｂ５．２．２）動作説明
以下、上述のごとく構成されたゲートウェイ２を含むネットワーク動作について、図１６及び図１７を参照しながら説明する。
まず、この場合も、ＬＮ５−ｊのRF-ID、即ちLN-IDがＧＮ４−ｉに読み取られると（図１６のステップＣ１）、ＧＮ４−ｉからGN-HA１１に対してLN-IDとGN-ID（GN-IPアドレス）の対応が連携情報として通知される（図１６のステップＣ２）。GN-HA１１は、通知された当該連携情報を、GN-IPアドレスをキーとしてＧＮ連携情報ＤＢ１１４（図４参照）に登録（記憶）するとともに、LN-HA１２に通知すべく、LN-HA−ゲートウェイアドレス対応ＤＢ１１７を参照して、該当ゲートウェイ２宛に連携情報を前記連携情報登録メッセージ（図１３の項番１参照；送信元アドレスは自GN-IPアドレスとする）により送信（通知）する（図１６のステップＣ３）。
【００７２】
ゲートウェイ２は、この連携情報登録メッセージを受信すると（図１７のステップＤ１）、ＩＰアドレス変換機能部２７′によって、当該メッセージの送信元アドレス（GN-IPアドレス）に対応するＩＰアドレスとして、自ゲートウェイ２にルーティングされるGN-IP′アドレスを生成してアドレス表（変換表）を作成するとともに、GN-IPアドレスを当該GN-IP′アドレスに変換する（図１６のステップＣ４及び図１７のステップＤ２）。
【００７３】
その後、ゲートウェイ２は、自アドレスにて受信した連携情報登録メッセージの宛先を、LN-HAアドレスＤＢ２１を参照することで、LN-HAアドレスとし、LN-HA１２に対して、受信した連携情報登録メッセージの中継（図１４の項番１参照）を行なう(図１６のステップＣ５及び図１７のステップＤ３)。ここでの実施例は、すべて、GN-HA１１がLN-HA１２のＩＰアドレスを格納していることを想定しているが、図１６のステップＣ５において、ゲートウェイ２−LN-HA１２間においてSOAPインタフェース等が適用できる場合などについては、LN-HA１２が格納するアドレスは、LN-HA１２のWeb通信用インタフェース、つまり、URL（Uniform Resource Locator）であってもよい。
【００７４】
最終的に、LN-HA１２は、上記連携情報登録メッセージを受信すると、当該メッセージにより通知されたLN-IDとGN-IP′アドレスの連携情報を自己の連携情報ＤＢ１２４に保存する（図１６のステップＣ６）。xSPサーバ７１は、LN-IDを読み取ったＧＮ４−ｉに対してサービスを開始する契機に、前記連携情報検索メッセージ（図１５の項番１参照）を発行し、LN-HA１２は、当該メッセージを受信すると、自己の連携情報ＤＢ１２４を参照して当該LN-IDに対応するGN-IP′アドレスを検索・取得し、当該GN-IP′アドレスを検索結果として連携情報応答メッセージ（図１５の項番２参照）によりxSPサーバ７１へ返信する（図１６のステップＣ７）。
【００７５】
xSPサーバ７１は、このようにしてLN-HA１２から取得した取得したGN-IP′アドレス宛にデータを送信する(図１６のステップＣ８)。送信されたデータは、ゲートウェイ２で受信され（図１７のステップＤ４）、宛先アドレスがGN-IP′アドレスからGN-IPアドレスにアドレス変換されてGN-HA１１にルーティングされ（図１７のステップＤ５）、最終的に、当該GN-HA１１管理下のＧＮ４−ｉに到達する(図１６のステップＣ９)。
【００７６】
このようにして、xSP等のLN-HA１１を管理する事業者は、xSPサーバ７１から、特定のLN-IDと連携するＧＮ４−ｉに対して、広告情報等のコンテンツや緊急メッセージ等の送信を行なう契機に、LN-HA１１の連携情報ＤＢ１２４から当該LN-IDに対応する変換GN-IP′アドレスを取得し、当該GN-IP′アドレスに対して、コンテンツや緊急メッセージ等の送信を行なう。
【００７７】
以上のように、GN-HA１１とLN-HA１２が異事業者によって管理されるようなネットワーク形態において、GN-HA１１がLN-HA１２に通知するGN-IDについてID変換を行なうので、特に、異事業者（xSP）がLN-ID（ＬＮ５−ｊ）の詳細内容や属性を、ネットワークキャリアに対して隠蔽したようなケースにおいて、本アーキテクチャは有力である(xSPが、LN-HA１１と独自のLN-IDのデータベース等を保有できるため)。
【００７８】
なお、xSPサーバ７１の通信（ストリーミングコンテンツ送信）途中に、LN-HA１１の連携情報ＤＢ１２４の内容が変化するような場合、LN-HA１１が、変化のあったＧＮ４−ｉのGN-IP′アドレスをxSPサーバ７１に適宜通知するようにすることも可能である。
〔Ｂ６〕オブジェクト共用機構の説明
次に、以下では、LH-HA１２に、オブジェクト共用機構を配備した例について説明する。図１８はLN-HA１２のオブジェクト共用機構に着目した構成を示す機能ブロック図である。この図１８に示すように、本LN-HA１２は、既述の位置制御プロトコルスタック１２３及びＬＮ連携情報ＤＢ１２４（図５参照）に加えて、例えば、アプライアンス同時使用状態データベース（ＤＢ）１２５，連携情報メッセージ送受信部１２６，アプライアンス使用可／不可判定部１２７及びアプライアンス制御メッセージ送受信部１２８をそなえて構成される。
【００７９】
ここで、アプライアンス同時使用状態ＤＢ（共用数保持手段）１２５は、ＩＰアドレスを保有しないアプライアンス（オブジェクト）、即ち、ＬＮ５−ｊ毎に、ＬＮ５−ｊを使用中のＧＮ数（「現使用数」），ＬＮ５−ｊを共用できるＧＮ数の上限値及び共用可／不可等の使用状態に関する情報を保持しておくものであり、連携情報メッセージ送受信部１２６は、ＧＮ４−ｉとの間で連携情報メッセージを送受信する（後述するＧＮ４−ｉからのアプライアンス（ＬＮ）連携情報登録／解除メッセージの受信及びそれらに対するＧＮ４−ｉへの応答メッセージの送信）ためのものである。
【００８０】
アプライアンス使用可／不可判定部１２７は、この連携情報メッセージ送受信部１２６においてＬＮ連携情報登録メッセージ（図２０の項番１参照）が受信されると、アプライアンス同時使用状態ＤＢ１２５を参照して、該当ＬＮ５−ｊの使用可／不可を判定するもので、具体的には、「現使用数」が「上限値」未満であれば、使用可と判定し、「現使用数」が「上限値」であれば使用不可と判定するようになっている。また、連携情報メッセージ送受信部１２６にてＬＮ連携情報解除メッセージ（図２２の項番１参照）が受信された場合には、アプライアンス同時使用状態ＤＢ１２５の該当ＬＮ５−ｊの「現使用数」を減算し、位置制御プロトコルスタック１２３に対して、当該ＬＮ５−ｊの連携情報エントリの削除と、アプライアンス制御終了信号（電源ＯＦＦ等）の発行とを依頼するようになっている。
【００８１】
このため、本例における位置制御プロトコルスタック１２３は、アプライアンス使用可／不可判定部１２７にて「使用可」と判定されれば、受信した連携情報をＬＮ連携情報ＤＢ１２４に登録した後、当該ＬＮ５−ｊに対する制御信号（ＬＮ制御メッセージ；例えば、電源ＯＮ信号等）を生成するとともに、ＬＮ５−ｊの登録を行なってきたＧＮ４−ｉ宛に処理結果（ＯＫ）をＬＮ連携情報登録応答メッセージ（図２０の項番２参照）により返信する一方、「使用不可」と判定されれば、連携情報の登録は行なわずに、ＬＮ５−ｊの登録を行なってきたＧＮ４−ｉ宛のＬＮ使用不可〔ＮＧ（使用中）〕を同じくＬＮ連携情報応答メッセージ（図２０の項番２参照）により返信する機能を有する。また、アプライアンス使用可／不可判定部１２７から、連携情報エントリの削除依頼とアプライアンス制御終了信号の発行依頼とがあれば、ＬＮ連携情報ＤＢ１２４から該当連携情報エントリを削除するとともに、その処理結果（ＯＫ等）を表すＬＮ連携情報解除応答メッセージ（図２２の項番２参照）を発行し、解除要求元のＧＮ４−ｉ宛にアプライアンス制御終了信号を発行する機能も有する。
【００８２】
つまり、この場合の位置制御プロトコルスタック１２３は、ＧＮ４−ｉから連携情報を受信すると、その連携情報に含まれるLN-ID，GN-IDと上記ＤＢ１２５における「現使用数」及びその「上限値」とに基づいて、ＧＮ４−ｉによる当該ＬＮ５−ｊの共用を制御する共用制御手段としての機能をも有するのである。
そして、アプライアンス制御メッセージ送受信部１２８は、ＬＮ５−ｊとの間でＬＮ制御／応答メッセージ（図２４参照）を送受信するためのものである。
【００８３】
以下、上述ごとく構成されたLN-HA１２によるオブジェクト共用ネットワーク動作について、図１９，図２１，図２３及び図２５を用いて説明する。
（Ｂ６．１）アプライアンス登録時（図１９及び図２５）
図１９に示すように、アプライアンス、即ちＬＮ５−ｊのような非ＩＰノードとLN-HA１２のようなＩＰノードとの間で制御メッセージを送受可能にするために、ＩＰ／制御信号変換機能を具備するアプライアンスコントローラ８をネットワーク３に配備する。そして、例えば、ＧＮ４−ｉがアプライアンス（ＬＮ）５−１のRF-ID(LN-ID1)を読み取ると (ステップＥ１)、当該ＧＮ４−ｉは、LN-HA１２にアクセスポイント（ＡＰ）９等を経由して読み取ったLN-IDと自己のGN-IDとの連携情報を登録しようと、当該連携情報を含むＬＮ連携情報登録メッセージをLN-HA１２に送信する(ステップＥ２)。
【００８４】
LN-HA１２では、当該メッセージを受信すると、まず、そのメッセージに含まれるLN-IDがＬＮ連携情報ＤＢ１２４に存在するか否かを位置制御プロトコルスタック１２３により確認し（図２５のステップＨ１）、存在すれば（ステップＨ１でＹｅｓであれば）、アプライアンス使用可／不可判定部１２７により、アプライアンスの使用可／不可を判定する(ステップＥ３及び図２５のステップＨ２)。今、図１９ではアプライアンス５−１の「同時使用可能数」＝１に対して、「現使用数」＝０であるから、アプライアンス５−１は「使用可」の状態である。
【００８５】
したがって、LN-HA１２は、アプライアンス使用可／不可判定部１２７により、アプライアンス５−１（LN-ID1）の現使用数を１つ増やして０から１に更新するとともに、ＧＮ４−ｉから受信した連携情報を位置制御プロトコルスタック１２３により自己のＬＮ連携情報ＤＢ１２４に新規エントリとして登録した後（ステップＥ４及び図２５のステップＨ２のＹｅｓルートからステップＨ３）、ＧＮ４−ｉが読み取ったLN-IDのLN-IDタグ情報をＧＮ４−ｉに返信する（図２５のステップＨ４）とともに、アプライアンスコントローラ８宛のアプライアンス５−１のＬＮ制御メッセージ（図２４の項番１参照）を発行する（ステップＥ５）。
【００８６】
これにより、上記ＬＮ制御メッセージの制御内容（電源ＯＮ，ＯＦＦ，再生，チャネル切替等）に応じた制御がアプライアンスコントローラ８によってアプライアンス５−１に対して行なわれることになる。
なお、LN-HA１２がＧＮ４−ｉから受信したＬＮ連携情報登録メッセージに含まれるLN-IDがＬＮ連携情報ＤＢ１２４に存在しない場合、LN-HA１２は、その旨をＧＮ４−ｉに返信する（図２５のステップＨ１のＮｏルートからステップＨ９）。
【００８７】
（Ｂ６．２）アプライアンス使用不可時（図２３及び図２５）
一方、上記のアプライアンスの使用可／不可判定において、例えば図２３に示すように、アプライアンス５−１の「現使用数」＝１で、それ以上新規の同時使用は不可能である場合（図２５のステップＨ２でＮｏの場合）、LN-HA１２は、アプライアンス５−１のLN-ID1に対してGN-IDのエントリがＬＮ連携情報ＤＢ１２４に存在するか否かを確認する（図２５のステップＨ５）。例えば、ＬＮ５−１をＧＮ４−２が読み取って連携情報の登録を行なった（図２３のステップＧ１〜Ｇ３）時点では、既に当該ＬＮ５−１を別のＧＮ４−１が読み取って連携情報の登録を済ませていた場合、ＬＮ連携情報ＤＢ１２４には、LN-ID1とＧＮ４−１のGN-ID１の連携情報エントリが存在することになる。
【００８８】
したがって、この場合、LN-HA１２は、ＧＮ４−１の後にＬＮ５−１を読み取ったＧＮ４−２に対して「ＮＧ（使用中）」の旨を前記ＬＮ連携情報登録応答メッセージ（図２０の項番２参照）により通知することになる（ステップＧ４及び図２５のステップＨ５のＹｅｓルートからステップＨ６）。
なお、上記のステップＨ５においてGN-IDのエントリが存在しない場合は、新たにＬＮ５−１を読み取ったＧＮ４−２のGN-IDが読み取ったLN-IDとともにLN-HA１２のＬＮ連携情報ＤＢ１２４に新規登録され、当該ＧＮ４−２に、LN-IDタグ情報が返信される（図２５のステップＨ５のＮｏルートからステップＨ７，Ｈ８）とともに、処理結果がＬＮ連携情報登録応答メッセージにより返信される。
【００８９】
（Ｂ６．３）アプライアンス登録解除時（図２１）
次に、図２１に示すように、ＧＮ４−ｉによるアプライアンス５−１の使用が終了し、アプライアンス５−１がＧＮ４−ｉから取り外される等すると、ＧＮ４−ｉから無線アクセスポイント９等経由でLN-HA１２に対してＬＮ連携情報解除メッセージ（図２２の項番１参照）が発行される（ステップＦ１）。LN-HA１２は、このメッセージを受信すると、そこに含まれるLN-IDに対応するアプライアンス同時使用状態ＤＢ１２５の「現使用数」を１つ減じるとともに、ＬＮ連携情報ＤＢ１２４の該当連携情報エントリを削除し（ステップＦ２，Ｆ３）、アプライアンス制御終了信号（電源ＯＦＦ等）をアプライアンスコントローラ８に発行する（ステップＦ４）。これにより、アプライアンスコントローラ８は、受信した制御信号の内容に応じた制御をアプライアンス５−１に対して行なって、アプライアンス５−１の電源ＯＦＦ等を行なうことができる。
【００９０】
以上のようにして、LN-HA１２（連携管理機構１）を用いてアプライアンス５−ｊのリアルタイムな使用状況や同時使用可能数等の使用条件に応じたＧＮ４−ｉへのアプライアンス５−ｊの割当てが可能となる。したがって、アプライアンス５−ｊが例えば公共アプライアンスやキオスク端末等のように、同時に複数のユーザにより使用されるようなものである場合に、当該オブジェクトの同時使用可能数及びリアルタイムな現使用数を管理することが可能となり、より実用的かつ動作可能なネットワークアーキテクチャを実現できる。
【００９１】
（Ｂ７）オブジェクトのグループ化管理(ユーザセッションを考慮した場合)の説明
次に、以下では、オブジェクト（ＬＮ５−ｊ）をLN-HA１２においてグループ化して管理するためのグループ管理機構について説明する。オブジェクトのグループ化管理を行なうことによって、オブジェクトの管理にスケーラビリティをもたせることができる。以下では、特に、ＩＤカードによって認識されるユーザのセッション毎にオブジェクトの管理をLN-HA１２において行なう場合を例示する。
【００９２】
（Ｂ７．１）対等なオブジェクトのグループ化によるオブジェクト管理（ユーザ毎のグループ化によるオブジェクト管理）
あるユーザがもつオブジェクト５−ｊに対して関連付けを行なう場合で、かつ、オブジェクト５−ｊ同士の関連付けの組を、そのユーザのセッションとしてまとめて管理する例を以下に示す。なお、以下の例では、LN-HA１２に、既に単一のオブジェクト群５（図１参照）を構成するＬＮ５−１，５−２，５−３のLN-IDとして、それぞれ、LN-ID1， LN-ID2，LN-ID3がグループ（関連付けグループ）１（グループＩＤ＝１）として登録されており(次表１参照)、ＧＮ４−１がＬＮ５−１（LN-ID1）を読み込むものと仮定する。また、本例におけるＧＮ４−１のGN-IDはGN-ID1とする。
【００９３】
なお、下記の表１に示すデータ（テーブル）は、例えば前記のＬＮ連携情報ＤＢ１２４（図５参照）に保持することができる。この場合、当該ＤＢ１２４は、複数のＬＮ５−ｊについてのLN-ID同士を予め関連付けた関連付けグループを保持する関連付けグループ保持手段としての機能を果たすことになる。もっとも、当該データは、当該ＬＮ連携情報ＤＢ１２４とは別に専用のメモリ等の記録媒体に保持することも可能である。
【００９４】
【表１】
2005175934.tif 000003
【００９５】
(手順１)ユーザが一時的にＧＮ４−１を保有した場合のセッションＩＤ割当て
（1.1）あるユーザがＧＮ４−１を使用する場合、当該ユーザは自らのＩＤカードをＧＮ４−１に読み込ませる。ＧＮ４−１は、LN-HA１２に対して特定ユーザがＧＮ４−１を保有したことを登録するため、登録要求をGN-ID1と共に送信する。
（1.2）LN-HA１２は、当該登録要求を受信すると、上記ユーザがＧＮ４−１を保有したとみなして、そのユーザが保有している間有効なセッションＩＤを割り振る（例えば、セッションID1）とともに、GN-ID1を登録し(次表２参照)、ＧＮ４−１に対して登録応答と共にセッションＩＤを送信する。
【００９６】
【表２】
2005175934.tif 000004
【００９７】
(手順２)LN-IDの登録
（2.1）：ＧＮ４−１がLN-ID1を読み込むと、ＧＮ４−１は、GN-ID1及びLN-ID1の組をセッションＩＤ(本例では、セッションID1)と共にLN-HA１２に登録するよう要求する。
（2.2）：LN-HA１２は、上記要求を受信すると、上記表１の登録内容を参照してLN-ID1が属しているグループを検索し、そのグループのオブジェクトのLN-ID（LN-ID1， LN-ID2，LN-ID3）とGN-ID1との関連付けをセッションＩＤと共に登録する(次表３参照)。この機能は、例えば前記の局所位置登録機能部（位置制御プロトコルスタック）１２３（図５参照）の一機能として実現できる。つまり、当該機能部１２３は、受信手段としてのアクセス側ネットワークインタフェース１２１で受信した連携情報に含まれるGN-IDと、当該連携情報に含まれるLN-ID1を含む複数のLN-ID（LN-ID1， LN-ID2，LN-ID3）とを関連付けて記憶手段としてのＤＢ１２４に登録する連携情報登録制御手段としての機能を果たす。また、上記インタフェース１２１で受信した連携情報に含まれるLN-IDが属する関連付けグループをＤＢ１２４において検索する検索手段としての機能、この検索手段により検索された関連付けグループと上記インタフェース１２１で受信した連携情報に含まれるGN-IDとを関連付けてＤＢ１２４に登録する登録手段としての機能をも果たす。
【００９８】
（2.3）：LN-HA１２は、ＧＮ４−１に対して、登録応答と共に、同じグループに属するオブジェクトのLN-ID(LN-ID1，LN-ID2，LN-ID3)を送信する。即ち、ＬＮ群５のうちの少なくとも一つのＬＮ５−ｊのLN-IDを読み取って連携情報の登録を行なったＧＮ４−ｉに対して、ＧＮ４−ｉが読み取ったＬＮ５−ｊに関連付けられているＬＮ群５を通知する。これにより、ＬＮ群５単位での連携情報管理が実現される。なお、この機能も、例えば上記機能部１２３の一機能として実現できる。つまり、この場合の機能部１２３は、上記検索手段により検索された関連付けグループに属する各LN-ID（LN-ID1， LN-ID2，LN-ID3）をＧＮ４−ｉに通知する通知手段としても機能する。
【００９９】
【表３】
2005175934.tif 000005
【０１００】
上記手順２によって、LN-HA１２において、ユーザ毎のセッションに対して、グループ化されたオブジェクト群５の割当てが可能となり、ユーザにおいても、グループ化されたオブジェクトに関する情報が受信可能となる。即ち、１回のオブジェクト読み取りによって、複数のオブジェクトについての情報を入手可能となるため、オブジェクトの読み取り回数を低減することが可能となる。
【０１０１】
(手順３)LN-IDの削除
(個別のリソースの関連付けを削除したい場合)
（3.1）ＧＮ４−１は削除したいLN-IDを、セッションＩＤと共にLN-HA１２に対して削除要求（一部削除要求）として送信する。
（3.2）LN-HA１２は、上記削除要求を受信すると、受信したセッションＩＤとLN-IDが共に含まれる関連付けを検索し、削除する(次表４参照)。これにより、ＧＮ４−ｉとＬＮ群５の関連付けについて自ＬＮ連携情報ＤＢ１２４に登録を行なう連携管理機構１において、ＧＮ４−ｉを一時的に専有するユーザ毎に、上記連携情報を管理し、ユーザから削除要求のあったＬＮ５−ｊについて、自連携管理機構１が保持するユーザ毎の連携情報から削除を行なうことが可能となる。なお、この機能も、例えば、上記機能部１２３の一機能として実現でき、この場合、当該機能部１２３は、ＧＮ４−ｉから特定のLN-IDについての一部削除要求を受けると、当該LN-IDをＤＢ１２４の連携情報から削除する連携情報一部削除手段としての機能を果たすのである。
【０１０２】
（3.3）LN-HA１２は、削除応答を削除要求元のＧＮ４−１に対して送信する。
【０１０３】
【表４】
2005175934.tif 000006
【０１０４】
上記手順３によって、ユーザがグループ化されたオブジェクト情報を取得した場合においても、不要なオブジェクトの登録のみ消去可能となるため、ユーザのオブジェクト選択性が実現可能となる。
(手順４)該当ユーザ全ての関連付けを削除したい場合
（4.1）ＧＮ４−１は、削除したいセッションＩＤをLN-HA１２に対して削除要求（関連付けグループについての全削除要求）として送信する。
【０１０５】
（4.2）LN-HA１２は、受信したセッションＩＤが含まれる関連付けを検索し、削除する(表５参照)。この機能も、例えば、上記機能部１２３の一機能として実現でき、この場合、当該機能部１２３は、ＧＮ４−ｉから前記関連付けグループについての全削除要求を受信すると、当該関連付けグループとGN-IDとの関連付け情報である連携情報をＤＢ１２４から削除する連携情報全削除手段として機能するのである。
【０１０６】
（4.3）LN-HA１２は、削除応答を上記削除要求元のＧＮ４−１に対して送信する。
【０１０７】
【表５】
2005175934.tif 000007
【０１０８】
上記手順４によって、ユーザに関するセッション単位の全削除が実現される。
以上のようにして、LN-HA１２は、ユーザが使用するオブジェクト（ＬＮ）５−ｊを管理する場合において、あるオブジェクトを単独のオブジェクトとしてではなく、ユーザ毎に、オブジェクトの集合体として管理することができる。したがって、例えば、プリンタトナーやマウスなど、単独では動作不可なオブジェクトを、予めプリンタ及びプリンタトナーの集合体，ノートＰＣ及びマウスの集合体等として管理することができ、ユーザの観点から効率的な管理を実現することが可能となる。その結果、オブジェクト集合体を使用するためのユーザによる明示的なLN-HA１２（連携管理機構１）への登録（アクセス）回数を大幅に低減することが可能となる。
【０１０９】
（Ｂ７．２）親子関係が存在するオブジェクトによって構成される階層的なグループ化によるオブジェクト管理（ユーザ毎の階層化によるオブジェクト管理）
次に、上記のグループ化によるオブジェクト管理を拡張して、グループ化されるオブジェクト同士に親子関係が存在し、子オブジェクトの登録／削除が親オブジェクトと共に行なわれる場合について説明する。なお、以下においては、LN-HA１２には、既にＬＮ５−１，５−２，５−３のLN-IDとしてそれぞれLN-ID1，LN-ID2，LN-ID3が同一グループ１として登録されており、LN-ID2，LN-ID3の親LN-IDをLN-ID1とし、LN-ID1の親LN-IDは存在しないこととし(null：次表６参照)、ＧＮ４−１はLN-ID1を読み込むものとする。また、本例におけるＧＮ４−１のGN-IDはGN-ID1とする。
【０１１０】
なお、下記の表６に示すデータ（テーブル）も、例えば前記のＬＮ連携情報ＤＢ１２４に保持することができる。つまり、この場合、当該ＤＢ１２４は、複数のＬＮ５−１〜５−３についてのLN-ID（LN-ID1，LN-ID2，LN-ID3）同士の親子関係による階層的な関連付けグループを保持する階層関連付けグループ保持手段としての機能を果たすことになる。もっとも、当該データは、当該ＬＮ連携情報ＤＢ１２４とは別に専用のメモリ等の記録媒体に保持することも可能である。
【０１１１】
【表６】
2005175934.tif 000008
【０１１２】
(手順１)ユーザが一時的にＧＮ４−１を保有した場合のセッションＩＤ割当て
（1.1）あるユーザがＧＮ４−１を使用する場合、当該ユーザは自らのＩＤカードをＧＮ４−１に読み込ませる。ＧＮ４−１は、LN-HA１２に対して特定ユーザがＧＮ４−１を保有したことを登録するため、登録要求をGN-ID1と共にLN-HA１２へ送信する。
(1.2)  LN-HA１２は、ユーザがＧＮ４−１を保有したとみなして、ユーザが保有している間有効なセッションＩＤを割り振る(この例では、セッションID1)とともに、GN-ID(この例では、GN-ID1)を登録し、ＧＮ４−１に対して登録応答と共に送信する(表７参照)。
【０１１３】
【表７】
2005175934.tif 000009
【０１１４】
(手順２)LN-IDの登録
（2.1）ＧＮ４−１がLN-ID1を読み込むと、ＧＮ４−１は、GN-ID1及びLN-ID1の組をセッションＩＤ(この例では、セッションID1)と共にLN-HA１２に登録するよう要求する。
（2.2）LN-HA１２は、LN-ID1が属しているグループを検索し、そのグループのオブジェクトのLN-ID（LN-ID1，LN-ID2，LN-ID3）とGN-ID1の関連付けをセッションＩＤと共に登録する。この時、グループ１が保持している親子関係をそのまま引き継ぐ(次表８参照)。
【０１１５】
【表８】
2005175934.tif 000010
【０１１６】
この機能は、例えば、前記の局所位置登録機能部（位置制御プロトコルスタック）１２３の一機能として実現することができ、この場合、当該機能部１２３は、受信手段としてのアクセス側ネットワークインタフェース１２１で受信した連携情報に含まれるLN-IDが上位階層のLN-IDとして属する関連付けグループを上記階層関連付けグループ保持手段としてのＤＢ１２４において検索する検索手段として機能するとともに、この機能により検索された階層関連付けグループの上位階層のLN-ID及び当該LN-IDと関連付けられた下位階層のLN-IDと、上記インタフェース１２１で受信した連携情報に含まれるGN-IDとを関連付けて連携情報ＤＢ１２４に登録する登録手段として機能することになる。
【０１１７】
（2.3）LN-HA１２は、ＧＮ４−１に対して登録応答と共に、同じグループに属するオブジェクトのLN-ID（LN-ID1，LN-ID2，LN-ID3）を送信する。このように、複数のＬＮ５−ｊ同士の親子関係による階層的な関連付けグループを予め保持する連携管理機構１において、階層的な関連付けグループにある上位階層のＬＮ５−ｊを読み取った後に、このＬＮ５−ｊを含む下位階層に存在する階層的な関連付けグループを、先の上位階層のＬＮ５−ｊを読み取ったＧＮ４−ｉに通知することによって、階層的な関連付けグループを利用した連携情報管理が実現される。
【０１１８】
即ち、このような手順２によって、LN-HA１２において、ユーザ毎のセッションに対して、階層的にグループ化されたオブジェクト群５の割当てが可能となり、ユーザにおいても、階層的にグループ化されたオブジェクト５−ｊに関する情報が受信可能となる。即ち、１回のオブジェクト読み取りによって、複数のオブジェクト５−ｊについての情報を入手することが可能となるため、この場合も、オブジェクトの読み取り回数を大幅に低減することが可能となる。
【０１１９】
(手順３)LN-IDの削除(個別のリソースの関連付けを削除したい場合)
（3.1）ＧＮ４−１は、削除したいLN-IDを、セッションＩＤと共にLN-HA１２に対して削除要求（LN-IDについての一部削除要求）として送信する。
（3.2）LN-HA１２は、上記削除要求を受信すると、受信したセッションＩＤとLN-IDが共に含まれる関連付けを検索し (表９ではNo.5の行が該当)、さらに、そのLN-IDが親LN-IDとなっている関連付けを検索する(表９ではNo.6及びNo.7の行が該当)。かかる検索動作を、親LN-IDとなっている関連付けが存在しなくなるまで繰り返す。LN-HA１２は、かかる操作によって得られた関連付けを、全て削除する(表９ではNo.5，No.6及びNo.7の行を全て削除する)。
【０１２０】
【表９】
2005175934.tif 000011
【０１２１】
この機能も、例えば、前記の局所位置登録機能部１２３の一機能として実現でき、この場合、当該機能部１２３は、ＧＮ４−１から特定のLN-IDについての一部削除要求を受けると、当該LN-ID及び当該LN-IDの下位階層のLN-ID（子LN-ID）のすべてをＤＢ１２４の連携情報から削除する階層連携情報一部削除手段として機能することになる。
（2.3）LN-HA１２は、削除応答をＧＮ４−１に対して送信する。
【０１２２】
このような手順３によって、ユーザがグループ化されたオブジェクト５−ｊに関する情報を取得した場合、オブジェクト５−ｊの登録情報は親子関係によって削除される。このとき、親オブジェクトを削除した場合に、子オブジェクトも自動的に削除されるため、ユーザのオブジェクト削除処理回数を減少することができる。
(手順４)該当ユーザ全ての関連付けを削除したい場合
（4.1）ＧＮ４−１は、削除したいセッションＩＤをLN-HA１２に対して削除要求（階層関連付けグループについての全削除要求）として送信する。
【０１２３】
（4.2）LN-HA１２は、受信したセッションＩＤが含まれる関連付けを検索し、削除する(表１０参照)。
【０１２４】
【表１０】
2005175934.tif 000012
【０１２５】
この機能も、例えば上記の局所位置登録機能部１２３の一機能として実現でき、この場合、当該機能部１２３は、ＧＮ４−１から階層関連付けグループについての全削除要求を受信すると、当該階層関連付けグループの上位及び下位階層の各LN-IDとGN-IDとの関連付け情報である連携情報をＤＢ１２４から削除する階層連携情報全削除手段として機能することになる。
【０１２６】
（4.3）LN-HA１２は、削除応答をＧＮ４−１に対して送信する。
このような手順４によって、ユーザに関するセッション単位の全削除が実現される。
以上のようにして、LN-HA１２は、ユーザ毎の、階層グループで構成されるオブジェクト５−ｊの管理を行なうことができる。したがって、例えば、上位階層のオブジェクト５−ｊの使用を解除する場合に、下位階層のオブジェクト５−ｊを使用している状態が無意味になってしまうようなケース(ノートＰＣの使用を解除した場合に、マウスやキーボードを使用している状態が不要になる等)において、ユーザが上位階層のオブジェクト５−ｊの使用を解除した場合に、下位階層の全てのオブジェクト５−ｊを解除することができるので、ユーザによるオブジェクト使用解除処理回数を大幅に低減することが可能となる。
【０１２７】
〔Ｂ８〕ＤＮ導入によるＧＮ機能の移動
次に、以下においては、ユーザがＤＮ６（図１参照）を所有している場合に、当該ＤＮ６又は当該ＤＮ６をＧＮ４−ｉに読み込んでＧＮ４−ｉにてコンテンツの受信を選択的に行なうための機構について説明する。
（Ｂ８．１）ＤＮ６の階層化をベースにしたＧＮ機能移動
図２６は本実施形態に係るＤＮ６の構成を示す機能ブロック図で、この図２６に示すＤＮ６は、図２により前述したＧＮ４−ｉとしての機能を果たすＧＮ機能部６１と、図３により前述したＬＮ５−ｊとしての機能を果たすＬＮ機能部６２とをそなえて構成されており、これらの各機能部６１，６２がそれぞれ独立して動作を行なうようになっている。なお、ＧＮ機能部６１は、図２により前述したものとそれぞれ同様の局所（ローカル）ネットワークインタフェース４１，ＬＮ情報収集部（RF-IDリーダ等）４２，ＬＮ情報抽出部４３，ＧＮ個別識別情報記憶部４４，広域（グローバル）位置登録機能部４５及び広域（グローバル）ネットワークインタフェース４６をそなえて構成され、ＬＮ機能部６２は、図３により前述したものとそれぞれ同様の個別識別情報記憶部（メモリ）５１，読み取り要求検出部５２，読み取り要求応答部５３及び情報読み取りインタフェース５４をそなえて構成される。
【０１２８】
以下、上述のごとくＧＮ４−ｉとしての機能とＬＮ５−ｊとしての機能の双方をそなえたＤＮ６のネットワーク３上での動作例について、図２７〜図２９を用いて詳述する。ただし、以下において、ＬＮ５−１はRF-ID（LN-ID）としてLN-ID1を有し、ＧＮ４−１はGN-IDとしてGN-ID1を有し、ＤＮ６は、GN-IDとしてGN-ID2とRF-ID（LN-ID）としてLN-ID2の２つのＩＤを有しているものとする。
【０１２９】
（登録時の動作）
まず、ＤＮ６は、例えば図２７に示すように、自己がＧＮとして機能するノード（ＧＮ機能ノード）となるべく、ＬＮ５−１のRF-ID（LN-ID1）の読み取ると (ステップＪ１)、そのＬＮ５−１のID（LN-ID1）と自己のGN-ID（GN-ID2：例えば、ＤＮ６のＩＰアドレス）との対応を連携情報としてGN-HA１１及びLN-HA１２宛に送信して連携情報（第１の連携情報）の登録を行なう(ステップＪ２)。
【０１３０】
次に、例えばＧＮ４−１が、ＧＮ４−１からみてＬＮとして位置付けられるＤＮ６のRF-ID（LN-ID2）を読み取り(ステップＪ３)、そのRF-ID（LN-ID2）と自己のGN-ID（GN-ID1：例えば、ＧＮ４−１のＩＰアドレス）との対応を連携情報としてGN-HA１１及びLN-HA１２宛に送信して連携情報（第２の連携情報）の登録を行なう(ステップＪ４)。なお、以上のステップＪ１，Ｊ２での登録処理とステップＪ３，Ｊ４での登録処理の順序は入れ替わってもよい。
【０１３１】
つまり、この場合、GN-HA１１及びLN-HA１２におけるアクセス側ネットワークインタフェース１１１及び１２１は、それぞれ、ＤＮ６がＬＮ５−ｊから読み取ったLN-IDとＤＮ６が保有するGN-IDとの組を当該ＤＮ６から第１の連携情報として受信する第１の受信手段としての機能と、ＬＮ５−ｊのLN-IDの読み取りを行なったＤＮ６からＧＮ４−ｉが読み取ったＤＮ６が保有するLN-IDと当該ＧＮ４−ｉが保有するGN-IDとの組を当該ＧＮ４−ｉから第２の連携情報として受信する第２の受信手段としての機能を果たしていることになる。
【０１３２】
図２８（Ａ）に、上記のステップＪ１〜Ｊ４で示す登録手順が終了した際のLN-HA１２で保持・管理されるＬＮ連携情報テーブル１３の登録内容例、図２８（Ｂ）に、上記のステップＪ１〜Ｊ４で示す登録手順が終了した際のGN-HA１１で保持・管理されるＧＮ連携情報テーブル１４の登録内容例、図２８（Ｃ）に、LN-HA１２またはGN-HA１１において、予め管理されているＤＮ６のGN-IDとLN-IDとの対応テーブル１５の登録内容例をそれぞれ示す。
【０１３３】
そして、例えば、ＬＮ連携情報テーブル１３はLN-HA１２のＬＮ連携情報ＤＢ１２４（図５参照）に、ＧＮ連携情報テーブル１４は、GN-HA１１のＧＮ連携情報ＤＢ１１４（図４又は図１２参照）にそれぞれテーブル形式データのデータとして保持（登録）される。また、対応テーブル１５は、LN-HA１２ではＬＮ連携情報ＤＢ１２４に、GN-HA１２ではＧＮ連携情報ＤＢ１１４にてテーブル形式のデータとして保持（登録）される。
【０１３４】
かかる登録機能は、例えば、GN-HA１１及びLN-HA１２の位置制御プロトコルスタック１１３及び１２３の一機能としてそれぞれ実現でき、この場合、当該プロトコルスタック１１３及び１２３は、それぞれ、上記インタフェース１１１及び１２１で受信した上記の第１の連携情報と第２の連携情報とを関連付けて記憶手段としての例えばＤＢ１１４及びＤＢ１２４に登録する連携情報登録制御手段としての機能を果たすことになる。
【０１３５】
ところで、ＤＮ６等のネットワーク端末に付与されているRF-ID（LN-ID2）については、予めネットワーク管理者が保持している場合がある。例えば、第一種電気通信事業者が販売を行なう携帯端末において、第一種電気通信事業者は、自ネットワーク３上にて管理を行なう一意なGN-IDと、ユーザに販売した携帯端末に付与されているLN-IDとの対応を保持しているケースが存在する。
【０１３６】
このような場合に、図２６において、xSPサーバ７１が、LN-HA１２のＬＮ連携情報ＤＢ１２４（図５参照）を検索し(ステップＪ５)、LN-ID1のオブジェクト５−１を有するＧＮ４−１に対して、LN-ID1についてのコンテンツを送信する場合、xSPサーバ７１が、まず、LN-ID1を検索キーとして図２８（Ａ）に示すＬＮ連携情報テーブル１３を検索すると、LN-ID1に対応するGN-ID2が参照される。
【０１３７】
次に、LN-HA１２は、GN-ID2を保持するノードがＤＮ６であるか否かを判断するために、当該GN-ID2を検索キーとして図２８（Ｃ）に示す対応テーブル１５を検索する。その結果として、図２８（Ｃ）に示す対応テーブル１５に、GN-ID2をキーとするエントリが参照され、GN-ID2に対応するLN-ID2が得られる。さらに、このLN-ID2を検索キーとして再び図２８（Ａ）に示すＬＮ連携情報テーブル１３を検索するとGN-ID1が参照される。同様に、GN-ID1を検索キーとして図２８（Ｃ）に示す対応テーブル１５を検索すると、エントリが存在しない。よって、LN-ID1に対する最終的な関連付けを保持するノードのGN-IDは、GN-ID1と決定される。
【０１３８】
以上の検索結果より、LN-HA１２は、xSPサーバ７１に対して、LN-ID1に対応するGN-IDとしてGN-ID1を返信する。xSPサーバ７１は、LN-HA１２からのGN-ID1の通知を受信すると、当該GN-ID1を宛先アドレスとして、LN-ID1に関連するコンテンツを送信する。これにより、当該コンテンツは、GN-HA１１経由で、ＤＮ６を介してＬＮ５−１が読み込まれているＧＮ４−１にて受信される。
【０１３９】
このように、本例では、ＤＮ６を使用しているユーザが意図的に、当該ＤＮ６以外のＧＮ機能ノード（ＧＮ４−ｉ）を用いて、ＤＮ６のLN-IDを読み取ることによって、ユーザが使用ネットワーク端末（ノード）をＤＮ６からＧＮ４−ｉに変更してＤＮ６が使用しているＧＮ機能を一時的に他のＧＮ機能ノード４−１に移動させることが可能であり、このような場合においても、ＬＮ５−ｊ（LN-ID）に関連するコンテンツ等を当該ＧＮ４−ｉにて正常に継続受信することが可能となる。
【０１４０】
したがって、ユーザは、例えば、コンテンツ受信のためのＤＮ６の性能（メモリ，ＣＰＵ，インタフェース速度等）が不足あるいは不十分な場合に、ユーザが使用中のＤＮ６を十分な性能をもつＧＮ４−ｉに読み取らせて当該ＧＮ４−ｉをＧＮ機能ノードとして動作させることにより当該ＧＮ４−ｉにてコンテンツ受信を継続して行なうことができる。
（解除時の動作）
一方、ＧＮ４−１とＤＮ６の連携を解除する、即ち、ＧＮ４−１でのコンテンツ受信からＤＮ６でのコンテンツ受信に切り替える場合には、図２７において、ＧＮ４−１を保持したユーザが、GN-ID1とLN-ID2との関連付けの解除を、GN-HA１１及びLN-HA１２に対して行なえばよい。即ち、例えば、ユーザがＧＮ４−１に対して解除操作を行なった、あるいは、ＤＮ６とＧＮ４−１との接続が切り離されたこと等を契機に、ＧＮ４−１は、GN-HA１１及びLN-HA１２に対して、GN-ID1とLN-ID2との関連付けの解除要求を発行し、これを受けたGN-HA１１及びLN-HA１２は、それぞれ、図２９（Ａ），図２９（Ｂ）に示すように、連携情報テーブル１３，１４の２行目のエントリを削除する。なお、この削除機能も、例えば前記の位置制御プロトコルスタック１１３及び１２３の一機能としてそれぞれ実現でき、この場合、当該プロトコルスタック１１３及び１２３は、それぞれ、ＤＮ６から上記関連付けの解除要求を受信すると、ＤＢ１２３及び１２４における前記の第１の連携情報と第２の連携情報との関連付けを削除する連携情報削除手段としての機能を果たすことになる。
【０１４１】
この状態で、xSPサーバ７１が、再度、LN-HA１２内の図２９（Ａ）及び図２９（Ｃ）に示すテーブル１３，１５について検索を行なう。即ち、LN-HA１２は、LN-ID1を検索キーとして図２７（Ａ）に示すＬＮ連携情報テーブル１３を検索して、LN-ID1に対するGN-ID2を得る。次に、LN-HA１２は、このGN-ID2を保持するノードが、ＤＮ６であるか否かを判断するために、当該GN-ID2を検索キーとして図２９（Ｃ）に示す対応テーブル１５を検索する。
【０１４２】
その結果として、図２９（Ｃ）に示す対応テーブル１５に、GN-ID2に対するエントリが参照され、GN-ID2に対応するLN-ID2が得られる。さらに、LN-HA１２は、このLN-ID2を検索キーとして再び図２９（Ａ）に示すＬＮ連携情報テーブル１３を検索するが、この場合、LN-ID2に対応するエントリは、図２９（Ａ）に示すように既に削除されているので、LN-HA１２は、xSPサーバ７１に対して、LN-ID1に対応する最終的なGN-IDとしてGN-ID2を返信する。これにより、xSPサーバ７１は、LN-ID1に対応するGN-ID2を保有するＤＮ６宛に、LN-ID1（ＬＮ５−１）に関連するコンテンツを送信する。
【０１４３】
以上のようにして、ＧＮ機能移動後も、適宜、コンテンツの受信先をＧＮ４−１からＤＮ６へ復元（変更）することが可能となる。
（Ｂ８．２）ＤＮの階層化をベースにしたＤＮ判定によるリアルタイムフローの変更
上述した例においては、ＤＮ６とＧＮ４−ｉとの間においてコンテンツ出力（受信）先を変更することが可能であるが、xSPサーバ７１主導で受信先を変更するため、リアルタイムな経路変更に対応できない可能性がある。そこで、以下では、LN-HA１２が、連携情報の変更を検出する方法や、xSPサーバ７１に対して経路変更を通知する方法について、図３０〜図３４を用いて説明する。
【０１４４】
（登録時の動作）
まず、例えば図３０に示すように、LN-HA１２が、図２７の場合と同様にして、連携情報を受信して連携情報の登録内容を変更すると（ステップＪ１〜Ｊ４）、xSPサーバ７１に、連携情報の変更をxSPサーバ７１に通知する（ステップＪ５′）。ここで、例えば図３１（Ａ）に示すように、ユーザの保有するＤＮ６−１が、複数のオブジェクト（ＬＮ５−３，５−４）を読み込んでいる場合において、ユーザが、ＤＮ６−１からＤＮ６−２へとＧＮ機能を移動させる（ＤＮ６−２をＧＮ機能ノードとする）ことができるような場合を想定する。なお、ＤＮ６−１，６−２は、いずれも、図２６に示す構成と同一もしくは同様の構成を有するものとする。また、ＬＮ５−３はLN-ID3、ＬＮ５−４はLN-ID4をそれぞれ有し、ＤＮ６−１はGN-ID1及びLN-ID1、ＤＮ６−２はGN-ID2及びLN-ID2をそれぞれ有しているものとする。
【０１４５】
この場合、LN-HA１２は、例えば図３１（Ｂ１），図３１（Ｃ１）にそれぞれ示すような、各ＬＮ５−３，５−４のセッション（LN-IDセッション）毎に、LN-IDとGN-IDとの対応（連携情報）を保持する連携情報テーブル（LN-ID管理テーブル）１６，１７をそなえるとともに、図３１（Ｄ）に示すような、ＤＮ６−１，６−２に割り当てられているGN-ID及びLN-IDを保持するＤＮデータベース１８をそなえて構成される。なお、これらのテーブル１６，１７及びデータベース１８は、いずれも、ＬＮ連携情報ＤＢ１２４（図５参照）にテーブル形式のデータとしてその全部又は一部を保持してもよいし、別のＤＢ等に保持してもよい。なお、このようにLN-IDセッション毎に、LN-ID管理テーブル１６，１７を用意するのは、LN-ID毎に、連携情報の変更を検出できるようにするためである。
【０１４６】
そして、図３１（Ｂ１）及び図３１（Ｃ１）は、まず、ＤＮ６−１がＬＮ５−３，５−４をそれぞれ読み取った後のLN-HA１２にける、LN-ID3セッションについての管理テーブル１６，LN-ID4セッションについての管理テーブル１７の連携情報の登録状態をそれぞれ示している。図３１（Ｂ１）を例にすると、LN-HA１２は、ＤＮ６−１が読み込んだLN-ID3と当該ＤＮ６−１のGN-ID1との対応を図３１（Ｂ１）に示すように、管理テーブル１６の１行目に連携情報として登録する。次に、LN-HA１２は、登録したGN-ID1を検索キーとして図３１（Ｄ）に示すＤＮデータベース１８を検索することにより、当該GN-ID1に対応するLN-ID1を得る。
【０１４７】
ここで、LN-HA１２は、上記検索により得られたLN-ID1のみを図３１（Ｂ１）に示すように、管理テーブル１６の２行目のエントリに登録しておく。これは、LN-ID1（ＤＮ６−１）を次に読み込んだ上位ノード（ここでは、ＤＮ６−２）が、LN-ID3セッションについての管理テーブル１６ａのエントリに登録されることが予め分かっているからである。
さて、図３１（Ｂ１）に示すLN-ID3についての管理テーブル１６の登録状態において、xSPサーバ７１が、LN-ID3を検索キーとして、対応するGN-IDを当該管理テーブル１６において検索した場合、LN-ID3に対応する最終的なエントリとして、GN-ID1が検索結果として得られるので、xSPサーバ７１は、当該GN-ID1の通知を受けて、そのGN-ID1を保持する（割り当てられた）ＤＮ６−１に対して、当該ＤＮ６−１が読み込んだLN-ID3（ＬＮ５−３）の属性に応じたコンテンツ等を連続的に送信する。
【０１４８】
その後、ＤＮ６−１がxSPサーバ７１からのコンテンツ等を受信中に、ユーザが意図的に、図３１（Ａ）に示す別のＤＮ６−２を用いて、ＤＮ６−１のLN-ID（LN-ID1）を読み取ったとする。
すると、ＤＮ（ＧＮ機能ノード）６−２は、LN-HA１２に対して連携情報（LN-ID１とGN-ID2との対応）の登録を行なうが、この場合、LN-HA１２は、図３１（Ｂ１）中のLN-ID1と一致する連携情報の登録があったことを検出し、LN-ID1とGN-ID2の対応を図３１（Ｂ２）に示すように、LN-ID3についての管理テーブル１６に格納する。この際、当該管理テーブル１６の３行目のエントリにLN-ID2も登録しておく。その理由は図３１（Ｂ１）の場合と同様である。このとき、LN-HA１２は、図３１（Ｃ１）に示すLN-ID4についての管理テーブル１７おいても、図３１（Ｂ１）と同じ登録状態であるため、図３１（Ｂ２）に示す登録状態と同様に、図３１（Ｃ２）に示すように、連携情報（LN-ID1とGN-ID2との対応）を登録しておく。
【０１４９】
そして、LN-HA１２は、上述のごとく管理テーブル１６，１７が書き換えられたことを契機に、LN-ID3及びLN-ID4についての管理テーブル１６，１７の先頭（１行目のエントリ）にそれぞれ登録されている自LN-IDと、これに連携する最終的な（つまり、現在の）GN-ID（ここでは、２行目のエントリのGN-ID2）と、図３１（Ｄ）に示すＤＮデータベース１８を用いてLN-ID1を検索キーとして検索された旧GN-ID（ここでは、GN-ID1）とを、連携情報変更通知メッセージ（図３２の項番１参照）により、xSPサーバ７１に送信することによって、ＧＮ機能ノード(ここでは、ＤＮ６−２)主導によるxSPサーバ７１への経路切り替えの指示（xSPサーバ７１からＤＮ６−２へのルート設定）が可能となる。なお、xSPサーバ７１は、上記連携情報変更通知メッセージに対する応答（ＯＫ又はＮＧ）を連携情報変更通知応答メッセージ（図３２の項番２参照）によりLN-HA１２に対して返信する。
【０１５０】
（解除時の動作）
さて、次に、以下では、ＤＮ６−２においてLN-ID3に関連するコンテンツ等を受信している状態において、ユーザが、コンテンツの受信を行なうノードをＤＮ６−２からＤＮ６−１に戻す場合（連携情報の解除動作）について説明する。
この解除動作は、ＤＮ６−２が、LN-HA１２に対して、自身のGN-ID（GN-ID2）と、読み込んだLN-ID（LN-ID1）との対応の解除要求メッセージ(図３３の項番１参照)を送信することによって実行される。即ち、LN-HA１２は、当該解除要求メッセージを受信すると、図３４（Ａ），図３４（Ｂ）及び図３４（Ｃ）に示すように、連携情報の解除（削除）を行なう。LN-HA１２は、このようにして連携情報の解除を行なった後、連携情報解除応答メッセージ（図３３の項番２参照）を上記解除要求メッセージの応答（ＯＫ又はＮＧ）としてＤＮ（ＧＮ機能ノード）６−２に返信する。
【０１５１】
以上のようにして、連携情報の解除をそれぞれのLN-IDに対して行なうことで、データ転送経路の切り替えが可能となる。
本方式は、複数のＤＮ６が階層的に連なる場合や、LN-IDを読み込んだＧＮ４−ｉが複数台存在する場合においても、容易に適用可能である。また、LN-IDが、xSPサーバ７１等において管理されているユーザのＩＤである場合においては、xSPサーバ７１は、特定のユーザに対して、使用ネットワーク端末変更時においても、常に、コンテンツ等を正常に受信させ続けることができる、といったメリットがある。
【０１５２】
なお、上述したLN-HA１２におけるデータ転送経路の切り替え（リアルタイムフローの変更）機能も、例えば、前記の位置制御プロトコルスタック１２３の一機能として実現できる。この場合、当該プロトコルスタック１２３は、ＬＮ連携情報ＤＢ１２４において前記の第１の連携情報と第２の連携情報との関連付けの生成／解除を監視する監視手段として機能するとともに、この監視手段にて上記関連付けの生成が確認されると、ＬＮ５−ｊを使用している装置（ノード）がＤＮ６からＧＮ４−ｉに変更されたと認識して、当該ＬＮ５−ｊに関する情報の送信先をＧＮ４−ｉに変更する指示をＬＮ５−ｊに関する情報の送信元であるxSPサーバ７１に送信し、上記監視手段にて上記関連付けの解除が確認されると、ＬＮ５−ｊを使用しているノードがＧＮ４−ｉからＤＮ６に変更されたと認識して、ＬＮ５−ｊに関する情報の送信先をＤＮ６に変更する指示をxSPサーバ７１に送信する送信先変更指示手段として機能するのである。
【０１５３】
〔Ｃ〕補足
上述した実施形態では、ＧＮ４−ｉを管理するGN-HA１１と、ＬＮ５−ｊを管理するLN-HA１２のような２つのＨＡが連携動作するような場合を前提としているが、本発明は、これに限らず、LN-HA１２単独で動作することも可能である。GN-HA１１は、モバイルＩＰにおけるＨＡとしての機能を果たすが、本発明は、必ずしも、モバイルＩＰ，GN-HA，ＩＰコアネットワークの存在を必要とするわけではない。例えば、図３５，図３６，図３７に示すように、無線ＬＡＮ（Local Area Network）のような無線アクセスネットワーク等への適用も可能であるし、また、図３８に示すように、モバイルＩＰを用いない場合においても動作可能である。以下、これらの変形例について説明する。
【０１５４】
（Ｃ１）無線ＬＡＮ利用の実施例（補足１）
図３５に示すように、無線基地局（BS）等の複数のアクセスポイント３２−１，３２−２，３２−３がハブ３１により集線されるとともに、当該ハブ３１を介してLN-HA１２及びxSPサーバ７１が、いずれかのアクセスポイント（ＡＰ）３２−１，３２−２，３２−３に無線回線により接続したＧＮ４−ｉと通信できるような無線ＬＡＮネットワーク形態を想定する。なお、この場合、アクセスポイント３２−１，３２−２，３２−３は、それぞれ、その識別子としてBSS-ID1，BSS-ID2，BSS-ID3を有しており、ＧＮ４−１はGN-ID（GN-IPアドレス）としてIP1を有し、ＬＮ５−ｊはLN-IDとしてLN-ID1を有しているものとする。
【０１５５】
ここで、例えば、ＡＰ３２−１のカバーエリア３３に存在するＧＮ４−１が、ＬＮ５−１のLN-ID1を読み取ると、無線ネットワーク上のLN-HA１２のＤＢ１２４（図５参照）には、LN-ID，GN-IPアドレス（IP1）及びＡＰ３２−１のＭＡＣ（Media Access Control）アドレスを示すBSS-ID（BSS-ID1）が登録される。なお、この場合のLN-IDは、ユーザのネットワーク上でのＩＤ等の情報であってもよい。
【０１５６】
xSPサーバ７１は、LN-HA１２内のＤＢ１２４を、LN-ID(この場合は、LN-ID1)を検索キーとして検索して対応するＩＰアドレス(IP1)を取得し、当該アドレス宛に、LN-ID1に適合するストリーミングコンテンツ等を送信する。なお、LN-HA１２に、GN-IPアドレス以外の情報（ＧＮ４−ｉの属性等）も保持させる場合には、サーバ７１は、LN-HA１２からＧＮ４−ｉの属性を取得し、当該ＧＮ４−ｉの属性に応じたコンテンツ送信等を行なうことも可能である。
【０１５７】
（Ｃ２）無線ＬＡＮ利用の実施例（補足２）
次に、図３６に示すように、図３５に示す構成を前提としつつ、複数のＧＮ４−１，４−２が同一のＬＮ５−１を読み込む場合について説明する。これは、例えば、ユーザＩＤカードを所有したユーザが複数のＧＮ４−１，４−２を用いる場合である。上述した補足１と同様の手順によって、xSPサーバ７１は、LN-ID(ここでは、LN-ID1)に対応する複数のGN-IPアドレス(IP1，IP2)宛に、LN-ID1に適合するストリーミングコンテンツ等を送信することができる。
【０１５８】
（Ｃ３）無線ＬＡＮ利用の実施例（補足３）
次に、図３７に示すように、LN-HA１２を含むネットワーク内において、DHCPサーバのようなＩＰアドレス管理サーバ３４が存在する場合を示す。なお、この図３７において、既述の符号と同一符号を付したものはそれぞれ既述のものと同一もしくは同様のものである。この場合、ＧＮ４−ｉ（ここでは、ＧＮ４−１）がＩＰアドレス管理サーバ３４から取得したＩＰアドレス（IP1）をLN-HA１２の管理情報内に含めることが可能である。
【０１５９】
即ち、ＧＮ４−１は、ＩＰアドレス管理サーバ３４から、ＩＰアドレス＝IP1を取得した後、ＬＮ５−１のLN-ID1を読み込むと、当該LN-ID1とＩＰアドレス管理サーバ３４から取得したＩＰアドレス＝IP1との組を連携情報としてLN-HA１２に登録する。そして、xSPサーバ７１は、LN-HA１２のデータベース１２４から、上記LN-ID1に対応するＩＰアドレス＝IP1を取得し、当該ＩＰアドレス＝IP1宛にストリーミングコンテンツ等を送信する。
【０１６０】
なお、ここでのＩＰアドレス管理サーバ３４は、GN-HA１２そのものではない。つまり、本発明では、GN-HA１２は、ＩＰアドレスを〔ホームアドレス（HoA）からケアオブアドレス（CoA）に〕変換するものであり、ＩＰアドレス管理サーバ３４は、単にＩＰアドレスを割り当てるサーバに過ぎないという位置付けである。
（Ｃ４）ゲートウェイ２を含んだネットワークの変形例（補足４）
また、前述したゲートウェイ２は、必ずしもモバイルＩＰに特化した技術ではない。
【０１６１】
例えば図３８に示すように、ＧＮ４−ｉが、LN-HA１２に直接自身のＩＰアドレス（GN-ID）を登録することも可能である（ステップＡ２′）。この場合は、図９に示すようなモバイルＩＰのホームエージェントに相当するGN-HA１１は存在しないため、この図３８に示すステップＡ５において、ゲートウェイはＩＰアドレスを、GN-HA１２のアドレスではなく、直接、ＧＮ４−１のＩＰアドレスに変換することができる。なお、他の動作は基本的に図４により前述した動作（ステップＡ１，Ａ３〜Ａ４，Ａ６〜Ａ８）と同様である。
【０１６２】
このように、本変形例においても、前述した実施形態と同様に、キャリアネットワーク３とxSPネットワーク７とで構成されるネットワーク形態において、キャリアネットワーク３がIPv6アドレス体系等で構成される場合に、IPv6アドレスを有するユーザが保持するモノ（アプライアンス）についての情報を、xSPサーバ７１に通知してしまうことを防止することができる。
【０１６３】
これは、ビジネス形態としては、ネットワークキャリアがxSPに定額のコンテンツ料金を支払う場合等において、ネットワークキャリアがxSPに通知する情報は、必ずしも、IPv6アドレス等の加入者情報そのものである必要はなく、加入者が有しているモノや位置情報であるようなケースも考えられるため、本実施形態のゲートウェイ２は、前述したように、ネットワークキャリアからxSPサーバ７１に対して通知する必要のない加入者情報を隠蔽するのに効果がある。なお、ネットワークキャリアとxSPを、企業とxSPに置き換えた場合についても、この種のネットワーク事業形態は成立する。
【０１６４】
（Ｃ５）その他
なお、上述した実施形態で説明した連携管理機構１（GN-HA１１，LN-HA１２）の機能は必要に応じて１つ以上適宜組み合わせて適用することができる。
そして、本発明は上述した実施形態に限定されず、本発明の趣旨を逸脱しない範囲で種々変形して実施できることはいうまでもない。
【０１６５】
〔Ｄ〕付記
（付記１）
第１の識別子を保有する第１の装置と、第２の識別子を保有するとともに該第１の識別子を該第１の装置から読み取って当該第１の識別子と該第２の識別子との組を連携情報として送信しうる第２の装置とをそなえたシステムに用いられ、該連携情報を管理する連携情報管理装置であって、
該連携情報を受信する受信手段と、
該連携情報を記憶する記憶手段と、
該受信手段で受信した連携情報に含まれる第２の識別子と、当該連携情報に含まれる第１の識別子を含む複数の第１の識別子群とを関連付けて該記憶手段に登録する連携情報登録制御手段とをそなえたことを特徴とする、連携情報管理装置。
【０１６６】
（付記２）
複数の該第１の装置についての第１の識別子同士を予め関連付けた関連付けグループを保持する関連付けグループ保持手段をさらにそなえるとともに、
該連携情報登録制御手段が、
該受信手段で受信した連携情報に含まれる該第１の識別子が属する関連付けグループを該関連付けグループ保持手段において検索する検索手段と、
該検索手段により検索された関連付けグループと該受信手段で受信した連携情報に含まれる該第２の識別子とを関連付けて該記憶手段に登録する登録手段と、
該検索手段により検索された関連付けグループに属する各識別子を該第２の装置に通知する通知手段とをそなえたことを特徴とする、付記１記載の連携情報管理装置。
【０１６７】
（付記３）
該連携情報登録制御手段が、
該第２の装置から特定の第１の識別子についての一部削除要求を受けると、当該第１の識別子を該記憶手段の連携情報から削除する連携情報一部削除手段をそなえたことを特徴とする、付記２記載の連携情報管理装置。
【０１６８】
（付記４）
該連携情報登録制御手段が、
該第２の装置から該関連付けグループについての全削除要求を受信すると、当該関連付けグループと該第２の識別子との関連付け情報である連携情報を該記憶手段から削除する連携情報全削除手段をそなえたことを特徴とする、付記２又は３に記載の連携情報管理装置。
【０１６９】
（付記５）
複数の該第１の装置についての第１の識別子同士の親子関係による階層的な関連付けグループを保持する階層関連付けグループ保持手段をさらにそなえるとともに、
該連携情報登録制御手段が、
該受信手段で受信した連携情報に含まれる該第１の識別子が上位階層の識別子として属する関連付けグループを該階層関連付けグループ保持手段において検索する検索手段と、
該検索手段により検索された階層関連付けグループの該上位階層の識別子及び当該識別子と関連付けられた下位階層の識別子と、該受信手段で受信した連携情報に含まれる該第２の識別子とを関連付けて該記憶手段に登録する登録手段と、
該検索手段により検索された関連付けグループに属する各識別子を該第２の装置に通知する通知手段とをそなえたことを特徴とする、付記１記載の連携情報管理装置。
【０１７０】
（付記６）
該連携情報登録制御手段が、
該第２の装置から特定の第１の識別子についての一部削除要求を受けると、当該第１の識別子及び当該識別子の下位階層の識別子のすべてを該記憶手段の連携情報から削除する階層連携情報一部削除手段をそなえたことを特徴とする、付記５記載の連携情報管理装置。
【０１７１】
（付記７）
該連携情報登録制御手段が、
該第２の装置から該階層関連付けグループについての全削除要求を受信すると、当該階層関連付けグループの上位及び下位階層の各識別子と該第２の識別子との関連付け情報である連携情報を該記憶手段から削除する階層連携情報全削除手段をそなえたことを特徴とする、付記５又は６に記載の連携情報管理装置。
【０１７２】
（付記８）
第１の識別子を保有する第１の装置と、第２の識別子を保有するとともに該第１の識別子を該第１の装置から読み取って当該第１の識別子と該第２の識別子との組を連携情報として送信しうる第２の装置とをそなえたシステムに用いられ、該連携情報を管理する連携情報管理装置であって、
該第１の装置を使用中の該第２の装置数（以下、現使用数という）と当該第１の装置を共用できる該第２の装置数の上限値とを該第１の識別子別に保持する共用数保持手段と、
該第２の装置から該連携情報を受信すると、当該連携情報に含まれる上記各識別子と該共用数保持手段における該現使用数及び該上限値とに基づいて、当該第２の装置による当該第１の装置の共用を制御する共用制御手段とをそなえたことを特徴とする、連携情報管理装置。
【０１７３】
（付記９）
他装置によって読み取られる第１の識別子を保有する第１の装置と、第２の識別子を保有するとともに該第１の識別子を該第１の装置から読み取って当該第１の識別子と該第２の識別子との組を連携情報として送信しうる第２の装置と、該第１の装置としての機能と該第２の装置としての機能とを兼ね備えた第３の装置とをそなえたシステムに用いられ、該連携情報を管理する連携情報管理装置であって、
該第３の装置が該第１の装置から読み取った該第１の装置の第１の識別子と該第３の装置が保有する第２の識別子との組を該第３の装置から第１の連携情報として受信する第１の受信手段と、
該第１の装置の該第１の識別子の読み取りを行なった該第３の装置から該第２の装置が読み取った該第３の装置が保有する第１の識別子と当該第２の装置が保有する第２の識別子との組を該第２の装置から第２の連携情報として受信する第２の受信手段と、
該連携情報を記憶する記憶手段と、
該第１の受信手段で受信した該第１の連携情報と該第２の受信手段で受信した該第２の連携情報とを関連付けて該記憶手段に登録する連携情報登録制御手段とをそなえたことを特徴とする、連携情報管理装置。
【０１７４】
（付記１０）
該連携情報登録制御手段が、
該第３の装置から該関連付けの解除要求を受信すると、該記憶手段の該第１の連携情報と該第２の連携情報との関連付けを削除する関連付け削除手段をそなえたことを特徴とする、付記９記載の連携情報管理装置。
【０１７５】
（付記１１）
該連携情報登録制御手段が、
該記憶手段において該第１の連携情報と該第２の連携情報との関連付けの生成／解除を監視する監視手段と、
該監視手段にて該関連付けの生成が確認されると、該第１の装置を使用している装置が該第３の装置から該第２の装置に変更されたと認識して、該第１の装置に関する情報の送信先を該第２の装置に変更する指示を該第１の装置に関する情報の送信元に送信し、該監視手段にて該関連付けの解除が確認されると、該第１の装置を使用している装置が該第２の装置から該第３の装置に変更されたと認識して、該第１の装置に関する情報の送信先を該第３の装置に変更する指示を該送信元に送信する送信先変更指示手段とをそなえたことを特徴とする、付記１０記載の連携情報管理装置。
【０１７６】
（付記１２）
第１の識別子を保有する第１の装置と、第２の識別子を保有するとともに該第１の識別子を該第１の装置から読み取って当該第１の識別子と該第２の識別子との組を連携情報として送信しうる第２の装置と、該連携情報を受信して管理する連携情報管理装置と、該第１の装置に関する情報を送信する情報提供サーバとをそなえた連携情報管理システムに用いられるゲートウェイ装置であって、
該情報提供サーバが該第１の装置の該第１の識別子を読み取った該第２の装置宛に該第１の装置に関する情報を送信するために必要な該第２の識別子を該連携情報管理装置から受信する受信手段と、
該受信手段で受信した該第２の識別子を該情報提供サーバへの通知のための他の識別子に変換する識別子変換手段と、
該識別子変換手段による変換後の識別子を該情報提供サーバへ送信する送信手段と、
該情報提供サーバからの該情報に付与された該変換後の識別子を該変換前の識別子に逆変換して該第２の装置宛に転送する情報転送手段とをそなえたことを特徴とする、連携情報管理システムに用いられるゲートウェイ装置。
【産業上の利用可能性】
【０１７７】
以上詳述したように、本発明によれば、ユーザの周辺にあるアプライアンスを含めたコンテキスト・アウェアサービス、例えば、ユーザの端末装置や、ユーザ周辺のアプライアンスに応じた情報配信等を適切に行なうサービスを実現できるので、かかるサービスを提供する産業において極めて有用であると考えられる。
【図面の簡単な説明】
【０１７８】
【図１】本発明の一実施形態に係る連携情報管理システムの構成を示すブロック図である。
【図２】図１に示すＧＮの構成を示す機能ブロック図である。
【図３】図１に示すＬＮの構成を示す機能ブロック図である。
【図４】図１に示す連携管理機構を構成するGN-HAの構成を示す機能ブロック図である。
【図５】図１に示す連携管理機構を構成するLN-HAの構成を示す機能ブロック図である。
【図６】図１に示すゲートウェイの構成を示す機能ブロック図である。
【図７】図９に示すゲートウェイ−LN-HA間で送受されるGN-IPアドレス要求／応答メッセージのフォーマット例を示す図である。
【図８】図９に示すxSPサーバ−ゲートウェイ間で送受されるGN-IPアドレス要求／応答メッセージのフォーマット例を示す図である。
【図９】図１に示す連携情報管理システムのゲートウェイを含んだネットワーク動作を説明するための図である。
【図１０】図１及び図６に示すゲートウェイの動作を説明するためのフローチャートである。
【図１１】図６に示すゲートウェイの変形例を示す機能ブロック図である。
【図１２】図４に示すGN-HAの変形例を示す機能ブロック図である。
【図１３】図１６に示すGN-HA−ゲートウェイ間で送受される連携情報登録／応答メッセージのフォーマット例を示す図である。
【図１４】図１６に示すゲートウェイ−LN-HA間で送受される連携情報登録／応答メッセージのフォーマット例を示す図である。
【図１５】図１６に示すxSPサーバ−LN-HA間で送受される連携情報検索／応答メッセージのフォーマット例を示す図である。
【図１６】図９に示す連携情報管理システムのゲートウェイを含んだネットワーク動作の変形例を説明するための図である。
【図１７】図１６に示すネットワーク動作の変形例におけるゲートウェイの動作を説明するためのフローチャートである。
【図１８】図１に示すLN-HAのオブジェクト共用機構に着目した構成を示す機能ブロック図である。
【図１９】図１８に示すLN-HAを含むオブジェクト共用ネットワーク動作（アプライアンスの登録）を説明するための図である。
【図２０】図１８に示すLN-HAとＧＮとの間で送受されるアプライアンス（ＬＮ）連携情報登録／応答メッセージのフォーマット例を示す図である。
【図２１】図１８に示すLN-HAを含むオブジェクト共用ネットワーク動作（アプライアンスの登録解除）を説明するための図である。
【図２２】図１８に示すLN-HAとＧＮとの間で送受されるアプライアンス（ＬＮ）連携情報解除／応答メッセージのフォーマット例を示す図である。
【図２３】図１８に示すLN-HAを含むオブジェクト共用ネットワーク動作（アプライアンス使用不可時）を説明するための図である。
【図２４】図１８に示すLN-HAとアプライアンスコントローラとの間で送受されるアプライアンス（ＬＮ）制御／応答メッセージのフォーマット例を示す図である。
【図２５】図１８に示すLN-HAを含むオブジェクト共用ネットワーク動作（アプライアンス使用不可時）を説明するためのフローチャートである。
【図２６】図１に示すＤＮの構成を示す機能ブロック図である。
【図２７】図１に示す連携情報管理システムにおけるＤＮを含むネットワーク動作を説明するための図である。
【図２８】（Ａ）は図１に示すLN-HAにおける連携情報テーブルの一例を示す図、（Ｂ）は図１に示すGN-HAにおける連携情報テーブルの一例を示す図、（Ｃ）は図１に示すLN-HA及びGN-HAにおける対応テーブルの一例を示す図である。
【図２９】（Ａ）は図２８（Ａ）に示す連携情報テーブルに対する連携情報削除動作を説明するための図、（Ｂ）は図２８（Ｂ）に示す連携情報テーブルに対する連携情報削除動作を説明するための図、（Ｃ）は図２８（Ｃ）に示す対応テーブルの連携情報削除動作時の内容を示す図である。
【図３０】図１に示す連携情報管理システムにおけるＤＮを含むネットワーク動作の変形例を説明するための図である。
【図３１】（Ａ）は図１に示すＬＮ及びＤＮの親子関係を示す図、（Ｂ１），（Ｂ２），（Ｃ１），（Ｃ２）及び（Ｄ）はいずれも（Ａ）に示す親子関係を基にしたテーブル登録内容例を示す図である。
【図３２】図３０に示すLN-HAとxSPサーバとの間で送受される連携情報変更通知／応答メッセージのフォーマット例を示す図である。
【図３３】図３０に示すＧＮ機能ノードとLN-HAとの間で送受される連携情報解除要求／応答メッセージのフォーマット例を示す図である。
【図３４】（Ａ）〜（Ｃ）は図３０に示すLN-HAにおける連携情報解除時の動作を説明するための図である。
【図３５】本実施形態の補足１（無線ＬＡＮ利用）を説明するための図である。
【図３６】本実施形態の補足２（無線ＬＡＮ利用）を説明するための図である。
【図３７】本実施形態の補足３（無線ＬＡＮ利用）を説明するための図である。
【図３８】本実施形態の補足４（ゲートウェイを含んだネットワーク動作）を説明するための図である。
【符号の説明】
【０１７９】
１  連携管理機構（連携情報管理装置）
２  ゲートウェイ装置
２１  LN-HAアドレスデータベース（ＤＢ）
２２  ＩＰアドレス対応データベース（ＤＢ）
２３，２６，２３′，２６′  ＩＰデータ送受信機能部
２４，２４′  LN-ID抽出機能部
２５  GN-IPアドレス取得機能部
２７，２７′  ＩＰアドレス変換機能部
２８  LN-HA通知機能部
３  ネットワーク（キャリアネットワーク）
４−１〜４−４  ＧＮ（Global Node）（第２の装置）
４１  局所ネットワークインタフェース
４２  ＬＮ情報収集部
４３  ＬＮ情報抽出部
４４  ＧＮ個別識別情報記憶部
４５  広域位置登録機能部（位置制御プロトコルスタック）
４６  広域ネットワークインタフェース
５−１〜５−５  ＬＮ（Local Node）（アプライアンス（オブジェクト）；第１の装置）
５  ＬＮ群
５１  個別識別情報記憶部
５２  読み取り要求検出部
５３  読み取り要求応答部
５４  情報読み取りインタフェース
６，６−１，６−２  ＤＮ（Global-Local Dual function Node）（第３の装置）
６１  ＧＮ機能部
６２  ＬＮ機能部
７  xSPネットワーク
７１  xSPサーバ（情報提供サーバ）
８  アプライアンスコントローラ
１１  GN-HA
１１１  アクセス側ネットワークインタフェース
１１２  連携情報抽出部
１１３  広域位置登録機能部（位置制御プロトコルスタック）
１１４  ＧＮ位置（連携）情報データベース（ＤＢ）
１１５  LN-HA連携機能部
１１６  コア側ネットワークインタフェース
１１７  LN-HA−ゲートウェイアドレス対応データベース（ＤＢ）
１２  LN-HA
１２１  アクセス側ネットワークインタフェース
１２２  ＬＮ位置（連携）情報登録メッセージ処理部
１２３  局所位置登録機能部（位置制御プロトコルスタック）
１２４  ＬＮ位置（連携）情報データベース（ＤＢ）
１２５  アプライアンス同時使用状態データベース（ＤＢ）
１２６  連携情報メッセージ送受信部
１２７  アプライアンス使用可／不可判定部
１２８  アプライアンス制御メッセージ送受信部
１３，１４  連携情報テーブル
１５  対応テーブル
１６，１７  連携情報テーブル（LN-ID管理テーブル）
１８  ＤＮデータベース
３１  ハブ
３２−１，３２−２，３２−３  アクセスポイント（ＡＰ）
３３  カバーエリア
３４  ＩＰアドレス管理サーバ
【図１】
2005175934.tif 000013
【図２】
2005175934.tif 000014
【図３】
2005175934.tif 000015
【図４】
2005175934.tif 000016
【図５】
2005175934.tif 000017
【図６】
2005175934.tif 000018
【図７】
2005175934.tif 000019
【図８】
2005175934.tif 000020
【図９】
2005175934.tif 000021
【図１０】
2005175934.tif 000022
【図１１】
2005175934.tif 000023
【図１２】
2005175934.tif 000024
【図１３】
2005175934.tif 000025
【図１４】
2005175934.tif 000026
【図１５】
2005175934.tif 000027
【図１６】
2005175934.tif 000028
【図１７】
2005175934.tif 000029
【図１８】
2005175934.tif 000030
【図１９】
2005175934.tif 000031
【図２０】
2005175934.tif 000032
【図２１】
2005175934.tif 000033
【図２２】
2005175934.tif 000034
【図２３】
2005175934.tif 000035
【図２４】
2005175934.tif 000036
【図２５】
2005175934.tif 000037
【図２６】
2005175934.tif 000038
【図２７】
2005175934.tif 000039
【図２８】
2005175934.tif 000040
【図２９】
2005175934.tif 000041
【図３０】
2005175934.tif 000042
【図３１】
2005175934.tif 000043
【図３２】
2005175934.tif 000044
【図３３】
2005175934.tif 000045
【図３４】
2005175934.tif 000046
【図３５】
2005175934.tif 000047
【図３６】
2005175934.tif 000048
【図３７】
2005175934.tif 000049
【図３８】
2005175934.tif 000050