JP4264339B2 - 連携情報管理装置 - Google Patents

連携情報管理装置 Download PDF

Info

Publication number
JP4264339B2
JP4264339B2 JP2003413568A JP2003413568A JP4264339B2 JP 4264339 B2 JP4264339 B2 JP 4264339B2 JP 2003413568 A JP2003413568 A JP 2003413568A JP 2003413568 A JP2003413568 A JP 2003413568A JP 4264339 B2 JP4264339 B2 JP 4264339B2
Authority
JP
Japan
Prior art keywords
information
identifier
cooperation
address
unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2003413568A
Other languages
English (en)
Other versions
JP2005175934A (ja
Inventor
治幸 武吉
洋一郎 五十嵐
正明 高瀬
光明 掛水
新也 山村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2003413568A priority Critical patent/JP4264339B2/ja
Priority to US10/871,909 priority patent/US7577105B2/en
Priority to CNB2004100688018A priority patent/CN100403834C/zh
Publication of JP2005175934A publication Critical patent/JP2005175934A/ja
Application granted granted Critical
Publication of JP4264339B2 publication Critical patent/JP4264339B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/35Network arrangements, protocols or services for addressing or naming involving non-standard use of addresses for implementing network functionalities, e.g. coding subscription information within the address or functional addressing, i.e. assigning an address to a function
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0893Assignment of logical groups to network elements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/52Network services specially adapted for the location of the user terminal

Description

本発明は、連携情報管理装置に関し、特に、IP(Internet Protocol)ネットワーク等のネットワークに接続可能な装置を保持する特定のユーザに対して、所望のサービスを提供するために、好適な技術に関する。
近年の無線チップの集積化技術の進歩により、従来の書籍やCD(音楽用コンパクトディスク)等に貼付されていたバーコード(個別識別情報)の代替として、読み書き可能なRF-ID(Radio Frequency ID)タグ(無線タグ)が出現したため、今後、物流管理や工場の製造工程管理など、より広範囲に渡ってRF-IDタグが、情報記憶媒体として使用されると期待されている。このRF-IDタグの普及規模は、バーコードをはるかに上回ると予想されており、RF-IDタグをネットワークサービスの一要素として考えた場合において、よりスケーラブルな管理体系などが必要になってくると考えられている。
例えば、今後のネットワークサービスの一形態として、ユーザの周辺に配置されたアプライアンス(Appliance)を提供することが想定される。ここで、「アプライアンス」とは、個体識別情報を保有するとともに、当該個体識別情報を他装置と通信する通信手段として有する「物」である。アプライアンス(あるいは、オブジェクトともいう)は、ユーザが個人で保有する端末装置(例えば、携帯電話機)のみを用いては実現できない機能をユーザに対して提供する。
即ち、ユーザは、周辺に配置されたアプライアンス(例えば、ポインティングデバイス,プログラム記録媒体,ヘッドホン等)を一時的に利用することにより、ユーザ個人で保有する端末装置のみでは実現できない機能の提供を、サービスとして受けることが可能となる。なお、アプライアンスは、アプライアンス自体がユーザの端末装置に対して直接的に何らかの機能を提供するものでない物(例えば、建物、看板、缶等)であってもよいし、また、公共物、個人所有物のいずれであってもよい。
本発明は、このような身の回りの多様な「物」としてのアプライアンスがRF-IDタグ等の手段によって認識可能になる世界を想定して、これらアプライアンスの情報を利用したサービスを提供しようとするネットワーク事業分野に関連する。
なお、ユーザの移動端末(MN:Mobile Node)の位置を個々に管理する手段として、レイヤ3〔IP(Internet Protocol)レイヤ〕におけるモバイルIP(Mobile IP:下記非特許文献1参照)がある。
このモバイルIPでは、IPネットワークを用いて構成される複数のサブネットワーク間をMNが移動しながら通信することを継続可能とする技術で、MNは、現在所属するサブネットワークに依存しないアドレス(ホームアドレスと呼ばれる)と、サブネットワークに依存するアドレス〔気付アドレス(CoA:Care of Address)と呼ばれる〕とを有する。
そして、MNは、移動に伴って、適宜、上記各アドレスをホームエージェント(HA:Home Agent)と呼ばれるMNの位置管理装置に送信して位置登録を行ない、HAでは、これらのアドレスを対応付けて記憶・管理することにより、MNの現在位置を個々に管理する。MNの通信相手となる端末(CN:Correspondent Node)は、MN宛にパケットを送信する際、そのMNのホームアドレス宛にパケットを送信し、HAは、当該MNのホームアドレス宛のパケットを受信すると、当該パケットをそのホームアドレスに対応する最新の気付アドレス宛にカプセル化して転送する。これにより、MNは、CNから送信されたパケットを、サブネットワーク間を移動して気付アドレスが変化しても正常に受信することができ、CNとの通信を継続することが可能となる。
また、モバイルIPに関連する技術として、HAが、あるMNについて、このMNは正規のユーザ端末であるか否かを認証する技術がある(下記特許文献1参照)。さらに、ネットワークを介して接続される端末装置のユーザを識別する技術として、NAI(Network Access Identifier)を用いた技術(下記非特許文献2参照)もある。
特開2001−169341号公報 "IP Mobility Support"、[online]、1996年9月、IETF Network Working Group、[平成15年12月10日検索]、インターネット<URL:http://www.ietf.org/rfc/rfc2002.txt> "The Network Access Identifier"、[online]、1999年1月、IETF Network Working Group、[平成15年12月10日検索]、インターネット<URL:http://www.ietf.org/rfc/rfc2486.txt>
上記のアプライアンスをユーザに対して提供するサービスでは、あるアプライアンスとこれを使用するユーザとの対応関係(即ち、利用関係)を、サービスの提供側(サーバ等)で認識する必要があるが、ネットワークが大規模化した場合等に、これに対応して利用関係についての情報(連携情報)の登録、更新、削除等の操作を高速かつ効率的に行なう(スケーラビリティを確保する)ための連携管理機構について検討する必要がある。
また、アプライアンスとこれを使用するユーザとの対応関係は必ずしも1対1とはならない(例えば、プリンタ等の共有使用が想定されるケース等のように、1対多の関係も想定される)ため、これに対応した連携管理機構も要求される。
さらに、上記対応関係の認識により、例えば、実世界に散在するオブジェクト(RF-IDタグを付けた商品や電気製品等)の属性やロケーションの属性(その位置の特性を現すタグ属性、例えば「会議室」等がある)等を基に、特定のオブジェクトに関する連携情報をもった〔換言すれば、一定のコンテキスト(ある事項についての状況や環境)を満たした〕サービス利用者へ広告情報や緊急メッセージ等の所望のコンテンツを転送するといったサービス(このように、その場の状況に沿ってサービスを実施、内容調整しうるサービスを「コンテキスト・アウェア」サービスと称する)を実現することも可能となるが、コンテンツ受信側(ネットワーク端末)の性能(メモリ,CPU,インタフェース速度等)が不足する等の事態の発生を未然に防止する連携情報管理機構も検討する必要がある。
また、上記のような「コンテキスト・アウェア」サービスの実現にあたって、異事業者ネットワークを経由する通信が必要となるような場合に、ある事業者のネットワークが、特定のIPアドレスを有するユーザの連携情報を他事業者のネットワーク内ノードに直接的に提供してしまうと、ユーザについてタグ情報に基づいたロケーションプライバシーや、ユーザが保有する「物」についての秘匿性が保護されないので、これを防止する連携管理機構も要求される。
本発明は、以上のような課題に鑑み創案されたもので、主として、下記(1)〜(4)に示す機能ないし機構を実現できるようにした技術を提供することを目的とする。
(1)オブジェクト同士のスケーラビリティを考慮した管理によるネットワーク構築および運用コストの低減。
(2)単一のアプライアンスを複数ユーザで共用(多重的な連携)することを可能とする、拡張連携情報管理機構。
(3)ノード間において、GN(Global Node)機能の移動を行なうことによって、GNとして機能するノードの性能面についての制約等を解消。
(4)異種事業者ネットワーク間通信時の連携情報に関するプライバシーの保護機構。
上記の目的を達成するために、本発明の連携情報管理装置は、第1の識別子を保有する第1の装置と、第2の識別子を保有するとともに該第1の識別子を該第1の装置から読み取って当該第1の識別子と該第2の識別子との組を連携情報として送信しうる第2の装置とをそなえたシステムに用いられ、該連携情報を管理するものであって、該連携情報を受信する受信手段と、該連携情報を記憶する記憶手段と、該受信手段で受信した連携情報に含まれる第2の識別子と、当該連携情報に含まれる第1の識別子を含む複数の第1の識別子群とを関連付けて該記憶手段に登録する連携情報登録制御手段と、複数の該第1の装置についての第1の識別子同士を予め関連付けた関連付けグループを保持する関連付けグループ保持手段とをそなえ、該連携情報登録制御手段が、該受信手段で受信した連携情報に含まれる該第1の識別子が属する関連付けグループを該関連付けグループ保持手段において検索する検索手段と、該検索手段により検索された関連付けグループと該受信手段で受信した連携情報に含まれる該第2の識別子とを関連付けて該記憶手段に登録する登録手段と、該検索手段により検索された関連付けグループに属する各識別子を該第2の装置に通知する通知手段と、をそなえたことを特徴としている。
また、該連携情報登録制御手段は、該第2の装置から特定の第1の識別子についての一部削除要求を受けると、当該第1の識別子を該記憶手段の連携情報から削除する連携情報一部削除手段をそなえていてもよい。
さらに、該連携情報登録制御手段は、該第2の装置から該関連付けグループについての全削除要求を受信すると、当該関連付けグループと該第2の識別子との関連付け情報である連携情報を該記憶手段から削除する連携情報全削除手段をそなえていてもよい。
また、前記関連付けグループは、複数の該第1の装置についての第1の識別子同士の親子関係による階層的な関連付けグループであって、該検索手段が、該受信手段で受信した連携情報に含まれる該第1の識別子が上位階層の識別子として属する関連付けグループを該関連付けグループ保持手段(以下、階層関連付けグループ保持手段ともいう)において検索該登録手段が、該検索手段により検索された階層的な関連付けグループの該上位階層の識別子及び当該識別子と関連付けられた下位階層の識別子と、該受信手段で受信した連携情報に含まれる該第2の識別子とを関連付けて該記憶手段に登録該通知手段が、該検索手段により検索された関連付けグループに属する各識別子を該第2の装置に通知するようにしてもよい。
さらに、本発明に関連する技術の連携情報管理装置は、第1の識別子を保有する第1の装置と、第2の識別子を保有するとともに該第1の識別子を該第1の装置から読み取って当該第1の識別子と該第2の識別子との組を連携情報として送信しうる第2の装置とをそなえたシステムに用いられ、該連携情報を管理するものであって、該第1の装置を使用中の該第2の装置数(以下、現使用数という)と当該第1の装置を共用できる該第2の装置数の上限値とを該第1の識別子別に保持する共用数保持手段と、該第2の装置から該連携情報を受信すると、当該連携情報に含まれる上記各識別子と該共用数保持手段における該現使用数及び該上限値とに基づいて、当該第2の装置による当該第1の装置の共用を制御する共用制御手段とをそなえたことを特徴としている。
また、本発明に関連する技術の連携情報管理装置は、他装置によって読み取られる第1の識別子を保有する第1の装置と、第2の識別子を保有するとともに該第1の識別子を該第1の装置から読み取って当該第1の識別子と該第2の識別子との組を連携情報として送信しうる第2の装置と、該第1の装置としての機能と該第2の装置としての機能とを兼ね備えた第3の装置とをそなえたシステムに用いられ、該連携情報を管理するものであって、該第3の装置が該第1の装置から読み取った該第1の装置の第1の識別子と該第3の装置が保有する第2の識別子との組を該第3の装置から第1の連携情報として受信する第1の受信手段と、該第1の装置の該第1の識別子の読み取りを行なった該第3の装置から該第2の装置が読み取った該第3の装置が保有する第1の識別子と当該第2の装置が保有する第2の識別子との組を該第2の装置から第2の連携情報として受信する第2の受信手段と、該連携情報を記憶する記憶手段と、該第1の受信手段で受信した該第1の連携情報と該第2の受信手段で受信した該第2の連携情報とを関連付けて該記憶手段に登録する連携情報登録制御手段とをそなえたことを特徴としている。
ここで、該連携情報登録制御手段は、該第3の装置から該関連付けの解除要求を受信すると、該記憶手段の該第1の連携情報と該第2の連携情報との関連付けを削除する関連付け削除手段をそなえていてもよい。
また、該連携情報登録制御手段は、該記憶手段において該第1の連携情報と該第2の連携情報との関連付けの生成/解除を監視する監視手段と、該監視手段にて該関連付けの生成が確認されると、該第1の装置を使用している装置が該第3の装置から該第2の装置に変更されたと認識して、該第1の装置に関する情報の送信先を該第2の装置に変更する指示を該第1の装置に関する情報の送信元に送信し、該監視手段にて該関連付けの解除が確認されると、該第1の装置を使用している装置が該第2の装置から該第3の装置に変更されたと認識して、該第1の装置に関する情報の送信先を該第3の装置に変更する指示を該送信元に送信する送信先変更指示手段とをそなえていてもよい。
さらに、本発明に関連する技術のゲートウェイ装置は、第1の識別子を保有する第1の装置と、第2の識別子を保有するとともに該第1の識別子を該第1の装置から読み取って当該第1の識別子と該第2の識別子との組を連携情報として送信しうる第2の装置と、該連携情報を受信して管理する連携情報管理装置と、該第1の装置に関する情報を送信する情報提供サーバとをそなえた連携情報管理システムに用いられるものであって、該情報提供サーバが該第1の装置の該第1の識別子を読み取った該第2の装置宛に該第1の装置に関する情報を送信するために必要な該第2の識別子を該連携情報管理装置から受信する受信手段と、該受信手段で受信した該第2の識別子を該情報提供サーバへの通知のための他の識別子に変換する識別子変換手段と、該識別子変換手段による変換後の識別子を該情報提供サーバへ送信する送信手段と、該情報提供サーバからの該情報に付与された該変換後の識別子を該変換前の識別子に逆変換して該第2の装置宛に転送する情報転送手段とをそなえたことを特徴としている。
上記の本発明の連携情報管理装置によれば、第2の装置により使用される第1の装置(オブジェクト)を管理する場合において、第1の装置を単独の装置としてではなく、第1の装置の集合体として管理することができる。したがって、例えば、プリンタトナーやマウスなど、単独では動作不可なオブジェクトを、予めプリンタ及びプリンタトナーの集合体,ノートPC及びマウスの集合体等として管理することができ、ユーザの観点から効率的な管理を実現することが可能となる。その結果、オブジェクト集合体を使用するためのユーザによる明示的な連携情報管理装置への登録(アクセス)回数を大幅に低減することが可能となる。
また、本発明に関連する技術の連携情報管理装置によれば、連携情報管理装置を用いて第1の装置(オブジェクト)のリアルタイムな使用状況や同時使用可能数等の使用条件に応じた第2の装置へのオブジェクトの割当てが可能となるので、オブジェクトが例えば公共アプライアンスやキオスク端末等のように、同時に複数のユーザにより使用されるようなものである場合に、当該オブジェクトの同時使用可能数及びリアルタイムな現使用数を管理することが可能となり、より実用的かつ動作可能なネットワークアーキテクチャを実現できる。
さらに、本発明に関連する技術の連携情報管理装置によれば、第3の装置を使用しているユーザが意図的に、第2の装置を用いて、第3の装置の識別子を読み取ることによって、ユーザが使用装置を第3の装置から第2の装置に変更して第3の装置が使用している第2の装置としての機能を一時的に第2の装置に移動させることが可能であり、このような場合においても、第1の装置に関する情報を当該第2の装置にて正常に継続受信させることが可能となる。したがって、ユーザは、例えば、情報受信のための第3の装置の性能が不足あるいは不十分な場合に、使用中の第3の装置を十分な性能をもつ第2の装置に読み取らせて当該第2の装置を動作させることにより当該第2の装置にて情報受信を継続して行なうことができる。
また、本発明に関連する技術のゲートウェイ装置によれば、情報提供サーバが連携情報管理装置へ、連携情報、即ち、第1の装置(第1の識別子)に関連付けられた第2の装置(第2の識別子)についての問い合わせを行なった場合に、この問い合わせによって返信される第2の識別子を、情報提供サーバに通知を行なうための他の識別子に変換するので、連携情報に関するプライバシーを秘匿(隠蔽)しつつ、第2の装置に対する所望のデータ転送を実現することが可能となる。
〔A〕概要
本発明は、先の出願(国際出願番号:JP03/02498)に係る発明に関連する技術である。当該先の出願においては、実世界に散在するオブジェクト(例えば、RF-IDタグを取り付けた商品や電気製品等)の属性やロケーションの属性(その位置の特性を現すタグ属性。例えば、「会議室」などがある)の属性を基に、特定のオブジェクトとの対応関係(連携情報)をもった(一定のコンテキストを満たした)サービス利用者へのコンテンツ(広告情報等)転送等の「コンテキスト・アウェア」サービスを実現する一手法を提案しているが、下記に示すような検討事項があった。
(1)ネットワークが大規模化した場合に、これに対応して連携情報の登録、更新、削除当の操作を高速かつ効率的に行なう(スケーラビリティを確保する)ための機構について検討の余地があった。
(2)先の出願においては、アプライアンスと、そのアプライアンスを使用するユーザとの対応を1対1と想定していたが、サービスが複雑化すると、アプライアンスと、そのアプライアンスを使用するユーザとの関係は、必ずしも1対1とはならない。例えば、プリンタ等の共有使用が想定されるケースのように1対多の関係も想定される。したがって、このようなケースに対応した連携情報の管理機構が必要である。
(3)先の出願では、GN(Global Node)において、オブジェクトの属性をベースとしたコンテンツ等の受信が可能であるが、GNにて、性能面、搭載アプリケーション、コンテンツ受信インタフェース等に関して制約事項が発生するケースについて検討が不十分であった。特に、コンテンツの送信を行なうサーバ等が、当該コンテンツを受信するノードの性能面(メモリ容量や、CPU速度、インタフェース速度等)を把握できない場合などにおいて、コンテンツを受信する性能が不足する状態が発生する可能性がある。したがって、このような場合においても適切なコンテンツ受信を可能にする必要がある。
(4)先の出願においては、異事業者ネットワークを経由する通信が行なわれる場合に、ある事業者のネットワークが、他事業者のネットワーク内ノードに対して、特定のIPアドレスを有するユーザの連携情報を直接的に提供してしまうため、ユーザのタグ情報に基づいたロケーションプライバシーや、ユーザが保有する「物」についての秘匿性に関する保護が十分でなかった。したがって、これらユーザに関するプライバシー情報の保護を十分に図ることのできる機構が必要である。
本発明は、このような検討事項に鑑みてなされたもので、先の出願で提案したオブジェクト(LN)の連携管理機構を改良・高機能化して、前記のとおり、下記を実現するものである。
(1)オブジェクト同士のスケーラビリティを考慮した管理によるネットワーク構築および運用コストの低減。
(2)単一のアプライアンスを複数ユーザで共用(多重的な連携)することを可能とする、拡張連携情報管理機構。
(3)ノード間において、GN機能の移動を行なうことによって、GNとして機能するノードの性能面についての制約等を解消。
(4)異種事業者ネットワーク間通信時のプライバシー情報(連携情報)の保護機構。
これらを実現するために、本発明では、
(a)連携情報のグループ化/階層化によるオブジェクト群の管理、
(b)アプライアンスについての同時使用可能数および現在の使用者数の管理、
(c)GNとLNの双方の機能を有するノード(DN:Global-Local Dual function Node)を導入してGNとして一次的に機能するノードの切り替え、
(d)ゲートウェイ装置の導入によるプライバシー情報(端末アドレス等)の隠蔽
を行なう。
本発明によって、オブジェクト群の管理やネットワーク端末機能の移動に対してスケーラブルかつ柔軟に対応可能な通信プラットフォームが実現可能である。
〔B〕一実施形態の説明
以下、本発明の実施形態について、図面を参照しながら説明する。
図1は本発明の一実施形態に係る連携情報管理システムの構成を示すブロック図で、この図に示す連携情報管理システムは、IPネットワークやWAN(Wide Area Network)等のネットワーク3に設けられた連携管理機構(連携情報管理装置)1を構成するGN-HA11及びLN-HA12と、ゲートウェイ装置(以下、単に「ゲートウェイ」という)2とをそなえるとともに、連携管理機構1(GN-HA11)とネットワーク3経由で通信し得るGN(ここでは、4台)4−1〜4−4、当該GN4−i(i=1〜4)と通信し得るLN5−1〜5−5及びDN6をそなえて構成されている。なお、この図1において、LN5−1,5−2,5−3は、単一のオブジェクト群5を形成しており、LN5−4は、LNの機能とGNの機能とを兼ね備えたDN6と通信し、DN6は、GN4−1と通信し得ることを表しており、また、LN5−5は、GN4−3,4−4のいずれとも通信し得ることを表している。
ここで、LN(第1の装置)5−j(j=1〜5)は、それぞれ、例えば、機能種別,製造番号等の自身の個別識別情報〔LN-ID(第1の識別子)〕を記憶する個別識別情報記憶部51(図3により後述)をそなえたRF-IDタグのような装置で、無線インタフェース等を介してGN4−i(あるいはDN6)と通信して、自身のLN-IDをGN4−i(あるいはDN6)へ送信することができるものである。
なお、このLN5−jには、例えば、公共アプライアンス(公共性の高い場所に設置され、一定の許可の下に不特定多数の者が利用できることを想定した装置類)や、一時貸出し型(通称:キオスク)端末等も含まれる。また、これらLN5−jとGN4−iとの間の通信は、RF-IDタグ(LNに相当)からRF-IDリーダ(GNに相当)への通信のように一方向通信であってもよいし、ブルートゥース(Bluetooth)等を用いた双方向通信であってもよい。
GN4−i(第2の装置)は、それぞれ、LN5−jを読み取る無線タグリーダのような装置で、ネットワーク3との通信機能を有し、連携管理機構(GN-HA11)と無線又は有線により通信可能に接続されて、LN5−jとGN4−iとの連携情報を連携管理機構1(GN-HA11)に登録することができるものである。
DN(第3の装置)6は、上記のLN5−jとしての機能とGN4−iとしての機能を兼ね備えた装置、即ち、自身がGNとして機能する場合に、LN5−jと通信してそのLN-IDを読み取って自身が保有するGN-IDとともにGN-HA12宛に連携情報として送信するとともに、自身がLNとして機能する場合にGN4−iと通信してGN4−iに読み取られるLN-IDとして自身が保有するLN-IDをGN4−iに送信しうる機能をそなえるものである。
(B1)GNの機能説明
このため、まず、上記のGN4−iは、例えば図2に示すように、局所(ローカル)ネットワークインタフェース41,LN情報収集部(RF-IDリーダ等)42,LN情報抽出部43,GN個別識別情報記憶部44,広域(グローバル)位置登録機能部45及び広域(グローバル)ネットワークインタフェース46をそなえて構成されている。
ここで、局所ネットワークインタフェース41は、図示しない無線インタフェース等を介してLN5−jと通信するためのインタフェースであり、LN情報収集部42は、LN5−jから受信される情報(メッセージ)を収集するためのものであり、LN情報抽出部43は、このLN情報収集部43で収集された情報からLN5−jに固有の識別情報(LN-ID)を抽出するものである。
GN個別識別情報記憶部(メモリ)44は、GN4−iに固有の識別情報〔第2の識別子(GN-ID)〕を記憶するものである。なお、このGN-IDには、例えば、IPアドレスのようなネットワークにおいて一意にGN4−iを識別できる情報を用いる。
広域位置登録機能部(位置制御プロトコルスタック)45は、このGN個別識別情報記憶部44に記憶されているGN-IDと、上記LN情報抽出部43で抽出されたLN-IDとの組を連携情報として広域ネットワークインタフェース46及び図示しないIPインタフェース等を通じてGN-HA11宛へ送信するためのものである。なお、「プロトコルスタック」とは、一般に、ネットワーク上で特定の機能を実現するために必要なプロトコルを選び階層状に積み上げたソフトウェア群を意味する。
(B2)LNの機能説明
一方、上記のLN5−jは、例えば図3に示すように、個別識別情報記憶部(メモリ)51,読み取り要求検出部52,読み取り要求応答部53及び情報読み取りインタフェース54をそなえて構成される。
ここで、上記の個別識別記憶部51は、自身を識別する識別情報、あるいは、RF-IDタグの場合のように自身が取り付けられるオブジェクト(アプライアンス)を識別する識別情報(LN-ID)を記憶しておくものであり、読み取り要求検出部52は、GN5−jからのLN-IDの読み取り要求を検出するもので、当該読み取り要求を検出すると、上記個別識別情報記憶部51からLN-IDを読み出して読み取り要求応答部53へ転送するものである。
読み取り要求応答部53は、上記読み取り要求検出部52から転送されてきたLN-IDを上記読み取り要求に対する応答として、情報読み取りインタフェース54を通じて読み取り要求元のGN4−iへ送信するためのものである。情報読み取りインタフェース54は、上記読み取り要求の受信及び上記応答(LN-ID)の送信機能をそなえるものである。
(B3)GN-HAの機能説明
次に、前記GN-HA11は、例えば図4に示すように、アクセス側ネットワークインタフェース111,連携情報抽出部112,広域位置登録機能部(位置制御プロトコルスタック)113,GN位置(連携)情報データベース(DB)114,LN-HA連携機能部115及びコア側ネットワークインタフェース116をそなえて構成される。
ここで、アクセス側ネットワークインタフェース111は、GN4−iとの通信インタフェースで、前記のLN-IDの読み取り要求送信機能及びその応答受信機能をそなえるものであり、連携情報抽出部112は、このインタフェース111を通じて受信される前記読み取り要求に対する応答から連携情報(LN-IDとGN-IDの対応)を抽出するものであり、広域位置登録機能部113は、このLN情報抽出部112で抽出された連携情報をGN連携情報DB(記憶部)114に記憶するとともに、当該連携情報をLN-HA12へ送信すべくLN-HA連携機能部115へ転送する機能を有するものである。なお、GN連携情報DB114は、RAMやハードディスク等の所要の記録媒体を用いて実現される。また、内蔵型、外付け型のいずれを用いてもよい。
LN-HA連携機能部115は、上記広域位置登録機能部113から転送されてきたLN-IDとGN-IDの連携情報をLN位置(連携)情報メッセージとして、コア側ネットワークインタフェース116を介してLN-HA12へ送信するためのものであり、コア側ネットワークインタフェース116は、LN-HA12との通信インタフェースである。
上述のごとく構成されたGN-HA11は、GN4−iからの応答(連携情報の登録)を受信すると、連携情報抽出機能部112によって連携情報の抽出を行ない、広域位置登録機能部113によってGN連携情報DB114に格納する。また、格納したLN-IDとGN-IDの連携情報を、LN-HA連携機能部115によってLN-HA12に送信する。以後、GN-HA11は、GN -IDとLN-IDの対応(連携情報)についてリアルタイムに管理(登録,更新,削除)を行なって、常時、最新の連携情報を管理する。
なお、本実施形態において、GN-HA11は、その図示を省略するが、GN-ID(GN-IPアドレス)宛に受信データ(GN4−iのユーザのための広告情報等のコンテンツデータ等)をルーティングする機能も有している。
(B4)LN-HAの機能説明
次に、前記のLN-HA12は、例えば図5に示すように、アクセス側ネットワークインタフェース121,LN位置(連携)情報登録メッセージ処理部122,局所位置登録機能部(位置制御プロトコルスタック)123及びLN位置(連携)情報データベース(DB)124をそなえて構成される。
ここで、上記のアクセス側ネットワークインタフェース121は、GN-HA11との通信インタフェースで、GN-HA11のLN-HA連携機能部115から送信されてくる上記LN位置(連携)情報メッセージの受信手段としての機能を有するものであり、LN位置(連携)情報登録メッセージ処理部122は、上記インタフェース121で受信されたLN位置(連携)情報登録メッセージを処理(メッセージ内容の解析等)して連携情報を抽出する機能を有するものであり、局所位置登録機能部123は、このLN位置(連携)情報登録メッセージ処理部122から転送されてくる連携情報をLN位置(連携)情報DB(記憶手段)124に記憶・格納する機能を有するものである。
上述のごとく構成されたLN-HA12は、GN-HA11から連携情報の登録メッセージを受信すると、当該メッセージをLN位置(連携)情報登録メッセージ処理部で処理し、広域位置登録機能部123によって、連携情報をLN位置(連携)情報DB124に格納する。以後、LN-HA12は、LN-IDとGN-IDの対応(連携情報)についてリアルタイムに管理(登録,更新,削除)を行ない、常時、最新の連携情報を管理する。なお、このLN-HA12は、オブジェクトの管理事業者ごとに配備される。
(B5)ゲートウェイの機能説明
次に、本実施形態の前記ゲートウェイ2の機能について説明する。
上述した連携管理システムにおいて、例えば、連携管理機構1(GN-HA11)の運用管理事業者(例えば、ネットワークキャリアのような移動IP端末の加入者情報を保有する事業者)のネットワークと、GN4−i宛に広告情報等のコンテンツデータを配信する事業者のネットワークとが異なる場合、これら異事業者ネットワーク間の通信に用いるIDとしてGN-ID(IPアドレス)をそのまま用いると、加入者情報と対応付けられる可能性のあるIPアドレスと加入者の連携(利用)するオブジェクトとの関連付けが異事業者に漏洩する可能性がある。
そこで、本例では、異なる事業者ネットワーク間に配備されるゲートウェイ2にて、通信に用いるID(GN-ID)の変換を行なうことによって、加入者の連携情報プライバシー(どのようなアプライアンスを所持し、あるいは、どのようなオブジェクトの近傍に位置しているか等の、第三者に公開を許可/抑制したい個人情報の一種)を保護する機構を導入する。
(B5.1)GN-HA11とLN-HA12が同一事業者のネットワーク内に存在する場合
例えば図9に示すように、GN-HA11とLN-HA12がいずれも第一種電気通信事業者のようなネットワークキャリアの管理下にあるネットワーク(キャリアネットワーク)3内に存在し、当該キャリアネットワーク3と、ASP(Application Service Provider)やISP(Internet Service Provider)等といった、キャリアとは異なる事業者(xSP)の管理下にあるネットワーク(xSPネットワーク)7との境界に、ゲートウェイ2が存在し、xSPが運用・管理する、xSPネットワーク7上の情報提供サーバ(xSPサーバ)71からGN4−i宛に広告情報等のコンテンツデータを配信する場合を想定する。
(B5.1.1)機能説明
この場合、ゲートウェイ2は、例えば図6に示すように、LN-HAアドレスデータベース(DB)21,IPアドレス対応データベース(DB)22,IPデータ送受信機能部23,26,LN-ID抽出機能部24,GN-IPアドレス取得機能部25及びIPアドレス変換機能部27をそなえて構成される。
ここで、上記のLN-HAアドレスDB21は、LN-HA12のIPアドレスを記憶するものであり、IPアドレス対応DB22は、キャリアネットワーク3側で使用するGN-ID(GN-IPアドレス)と、xSPネットワーク7側で使用する、変換先のGN-IP′アドレスとを対応付けたGN-IPアドレス表(変換表)を記憶するものである。
IPデータ送受信機能部23は、xSPサーバ71との間の通信インタフェースで、IPレイヤ及びIPレイヤよりも上位レイヤのメッセージインタフェースを有するものであり、もう1つのIPデータ送受信機能部26は、GN-HA11及びLN-HA12との間の通信インタフェースで、LN-HA12に対しては、IPレイヤよりも上位レイヤのメッセージインタフェース、GN-HA11に対しては、IPレイヤでのメッセージインタフェースを有するものである。なお、IPレイヤよりも上位レイヤのメッセージインタフェースの例としては、SOAP(Simple Object Access Protocol)通信によるWebインタフェース等が含まれる。
LN-ID抽出機能部24は、xSPサーバ71が例えばLN5−jに応じた広告情報等のコンテンツデータを対応するGN4−i宛に配信するためにLN-IDを用いてGN-IDの問い合わせをGN-IPアドレス要求メッセージ(図8の項番1参照)により行なった際に、当該メッセージに含まれるLN-IDを抽出するものであり、GN-IPアドレス取得機能部25は、このLN-ID抽出機能部24により抽出されたLN-IDに対応するGN-IDを取得するために、LN-HAアドレスDB21を参照して該当LN-HA12宛のGN-IPアドレス要求メッセージ(図7の項番1参照)を作成する機能と、当該メッセージに対する応答であるGN-IPアドレス応答メッセージ(図7の項番2参照)に含まれるGN-IPアドレスを抽出する機能とを有するものである。
IPアドレス変換機能部(識別子変換手段)27は、(1)上記のGN-IPアドレス取得機能部27によってLN-HA12から取得された、xSPサーバ71から通知を受けたLN-IDに対応するGN-IPアドレスと、当該GN-IPアドレスの変換先のGN-IP′アドレスとを対応付けて前記変換表としてIPアドレス対応DB22に記憶する記憶制御機能と、(2)LN5−jに対応するGN4−iへのコンテンツ配信時に使用すべき宛先アドレスとして当該変換先GN-IP′アドレスをGN-IPアドレス応答メッセージ(図8の項番2参照)によりxSPサーバ71に通知する通知機能と、(3)xSPサーバ71から受信されるコンテンツデータ(IPデータ)の宛先アドレス(GN-IP′アドレス)を、GN-IPアドレス対応DB22を参照して、元の(キャリアネットワーク3側で使用する)GN-IPアドレスに変換するGN-IPアドレス変換機能とを兼ね備えるものである。
なお、上記のゲートウェイ2−LN-HA12間及びゲートウェイ2−xSPサーバ71間でそれぞれ送受されるGN-IPアドレス要求/応答メッセージは、いずれも、IPデータ送受信機能部23,26により、IP上位レイヤメッセージとして送受される。
上述のごとく構成されたゲートウェイ2をキャリアネットワーク3とxSPネットワーク7との間に配置することにより、xSPに対してGN-IPアドレス(GN-ID)を秘匿、即ち、連携管理機構1で管理している連携情報に関するプライバシーを秘匿しつつ、GN4−iに対してLN5−jに応じた必要なコンテンツ配信を実現することが可能となる。
(B5.1.2)動作説明
以下、かかるゲートウェイ2を含むネットワーク動作について、図9及び図10を参照しながら説明する。
まず、前記先の出願と同様の手順に従って、LN5−jのRF-ID、即ちLN-IDがGN4−iに読み取られると(図9のステップA1)、GN4−iからGN-HA11に対してLN-IDとGN-ID(GN-IPアドレス)の対応が連携情報として通知され、GN-HA11は、当該連携情報を、GN-IPアドレスをキーとしてGN連携情報DB114(図4参照)に登録(記憶)するとともにLN-HA12に通知し、LN-HA12は、GN-HA11から通知された連携情報を、LN-IDをキーとしてLN連携情報DB124(図5参照)に登録(記憶)する(図9のステップA2)。
ここで、LN5−j(LN-ID)に関連するサービスの提供を開始するxSPサーバ71は、ゲートウェイ2に対して、LN5−jのLN-IDを読み取ったGN4−i宛にLN5−jに関する情報を送信するのに必要なGN-IPアドレスを取得するためにGN-IPアドレス要求メッセージによりLN-IDの通知を行なう(図9のステップA3)。ゲートウェイ2は、この要求メッセージを受信すると(図10のステップB1)、当該メッセージに含まれるLN-IDに対応するGN-IPアドレスを、GN-IPアドレス取得機能部25及びIPデータ送受信機能部26を通じて、GN-IPアドレス要求メッセージによりLN-HA12に問い合わせることによって取得する(図9のステップA4及び図10のステップB2,B3)。
そして、ゲートウェイ2は、LN-HA12からIPデータ送受信機能部(受信手段)26を通じて受信したGN-IDアドレスを、IPアドレス変換機能部27によって、自ゲートウェイ2にルーティングされるGN-IP′アドレス(サーバ通知用のアドレス)に変換して(図10のステップB4)、GN-IPアドレス表(変換表)を作成し(図9のステップA5)、GN-IPアドレス対応DB22に記憶するとともに、LN-HA12から取得したGN-IPアドレスに対応するGN-IP′アドレスをxSPサーバ71にIPデータ送受信機能部(送信手段)23を通じGN-IPアドレス応答メッセージにより通知(送信)する(図9のステップA6及び図10のステップB5)。
その後、xSPサーバ71は、ゲートウェイ2より通知されたGN-IP′アドレスを宛先アドレスとしてIPデータを送信する (図9のステップA7)。ゲートウェイ2は、当該GN-IP′アドレス宛のデータ(上記変換後のGN-IP′が付与されたデータ)を受信すると(図10のステップB6)、IPアドレス変換機能部27によって、GN-IPアドレス対応DB22のGN-IPアドレス表を参照し、再度、GN-IP′アドレスを元のGN-IPアドレスに変換(逆変換)してIPデータ送受信機能部26を通じGN-HA11へ転送する(図10のステップB7)。
つまり、上記のIPアドレス変換機能部27及びIPデータ送受信機能部26は、xSPサーバ71からのIPデータに付与された上記変換後のGN-IP′アドレスを変換前のGN-IPアドレスに逆変換して当該アドレスをもつGN4−i宛に転送する情報転送手段として機能する。これにより、GN-IP宛のデータはGN-HA11に到達し、GN-HA11によりルーティングされて、最終的に、GN4−iへ転送される(図9のステップA8)。
以上のようにして、本実施形態では、異事業者ネットワーク3,7間にゲートウェイ2を導入することによって、あるサーバ71が連携管理機構1へ、連携情報、即ち、LN-IDに関連付けられたGN-IDについての問い合わせを行なった場合に、この問い合わせによって返信されるGN-IDを、異事業者に通知を行なうための他のIDに変換することができるので、異事業者(xSP)に対して自ネットワーク加入者の連携情報に関するプライバシーを秘匿(隠蔽)しつつ、GN4−iに対する所望のデータ転送を実現することが可能となる。
特に、上記のようにGN-HA11がモバイルIPのホームエージェントとしての機能を兼ねる場合において、GN4−iがルート最適化(目的ノードまでの最短経路化)の要求を送信するノードは、xSPサーバ71ではなく、ゲートウェイ2であるため、モバイルIP適用時においてのゲートウェイ2は、xSPサーバ71−GN-HA11間の中継ノードのみならず、キャリアネットワーク3内のルート最適化ノードとして機能する。このため、キャリアネットワーク3において、GN4−i宛のデータの大半は、GN-HA11を経由する必要がなくなる。これは、キャリアネットワーク3内のネットワークリソースを節約するのみならず、GN-HA11のパケット転送負荷を大幅に低減できるという利点がある。
さらに、単一のネットワークキャリアのネットワーク3に、xSP事業者のネットワーク7が複数接続するような場合において、(1)ゲートウェイ2の固定化、(2)ゲートウェイ2においてのルート最適化を行なうことは、通信プラットフォームの簡素化につながり、ネットワークキャリアは、ゲートウェイ2を含む自ネットワーク領域でのデータ転送を主な機能とし、xSPは、ゲートウェイ2によって変換されたアドレス宛にデータを送信することを主な機能として、役割分担することができるため、キャリア、xSP双方の機能配備の面においても、本例のようなアーキテクチャは非常に有効である。
(B5.2)GN-HA11とLN-HA12が異なる事業者のネットワーク内に存在する場合
次に、上記項目(B5.1)で述べたシステム構成の変形例として、例えば図16に示すように、GN-HA11が第一種電気通信事業者のようなネットワークキャリアの管理下にあるネットワーク(キャリアネットワーク)3内に存在し、LN-HA12がASPやISP等のキャリアとは異なる事業者(xSP)の管理下にあるxSPネットワーク7内に存在し、これらのネットワーク3,7間にゲートウェイ2が存在する場合を想定する。つまり、この図16に示す例は、LN-HA12がxSPネットワーク7に属している点が図9に示す例と相違している。
これは、LN5−jが必ずしも、GN-HA11と同じネットワーク事業者によって管理される必要はなく、xSPが独自に、LN-HA12を配置することによって、xSPの保有するLN-ID情報(例えば、ユーザのIDカード等)を用いたサービスを実現するような形態のネットワーク構成例を示している。
(B5.2.1)機能説明
この場合のゲートウェイ2は、例えば図11に示すように、既述のLN-HAアドレスDB21,IPアドレス対応DB22をそなえるほか、IPデータ送受信機能部23′,26′,LN-ID抽出機能部24′,IPアドレス変換機能部27′及びLN-HA通知機能部28をそなえて構成される。
ここで、IPデータ送受信機能部23′は、xSPサーバ71及びLN-HA12との間の通信インタフェースで、xSPサーバ71に対してはIPレイヤのメッセージインタフェース、LN-HA12に対してはIPレイヤよりも上位のメッセージインタフェースを有するものであり、もう1つのIPデータ送受信機能部26′は、GN-HA11との間の通信インタフェースで、IPレイヤでのメッセージインタフェースとIPレイヤよりも上位のメッセージインタフェースとを有するものである。なお、本例においても、IPレイヤよりも上位レイヤのメッセージインタフェースの例としては、SOAP(Simple Object Access Protocol)通信によるWebインタフェース等が含まれる。
LN-ID抽出機能部24′は、GN-HA11から連携情報登録メッセージ(図13の項番1参照)により通知されてくる情報(LN-ID,GN-IPアドレス,LN-HA12のIPアドレス)からLN-IDを抽出する機能を有するものであり、IPアドレス変換機能部27′は、(1)GN-HA11から通知されるGN-IPアドレスと、当該GN-IPアドレスの変換先のGN-IP′アドレスとを対応付けてIPアドレス表(変換表)としてIPアドレス対応DB22に記憶する記憶制御機能と、(2)LN-HA12のIPアドレス(以下、LN-HAアドレスと表記する)を含む上記連携情報登録メッセージについて、その送信元IPアドレスを、GN-HA11からGN4−iの代替として送信されるGN-IPアドレスから、自ゲートウェイ2にルーティングされるGN-IP′アドレスに変換する変換機能とを兼ね備えるものである。
そして、LN-HA通知機能部28は、上記IPアドレス変換機能部27′によって変換された変換後のGN-IP′アドレスを送信元アドレスとする上記連携情報登録メッセージの宛先アドレスを、LN-HAアドレスDB21を参照して、LN-HAアドレスとし、GN-HA11からの上記連携情報登録メッセージを、IPデータ送受信機能部23′を通じてLN-HA12宛に中継するための機能を有するものである。なお、LN-HA12へ中継される連携情報登録メッセージの内容は図14の項番1に示す通りである。また、上記連携情報登録メッセージも、IP上位レイヤメッセージとして送受される。
ところで、本例の場合、GN-HA11は、連携情報登録メッセージを送信すべきLN-HA12に対応するゲートウェイ2を特定して、そのゲートウェイ2に連携情報登録メッセージを送信する必要があるので、図12に示すように、LN-HA−ゲートウェイアドレス対応データベース(DB)117が付加されており、LN-HA連携機能部115が、このDB117を参照することで、上記連携情報登録メッセージを該当ゲートウェイ2宛に送信できるように構成される。
また、本例の場合、ゲートウェイ2及びLN-HA12は、それぞれ、上記連携情報登録メッセージに対する応答として、連携情報の登録処理結果(OK又はNG)を連携情報応答メッセージ(図13及び図14の項番2参照)により返信する応答機能をも有している。この応答機能は、ゲートウェイ2では、例えばIPデータ送受信機能部23′,26′の一機能として実現でき、LN-HA12では、例えばLN位置(連携)情報登録メッセージ処理部122(図5参照)の一機能として実現できる。なお、上記連携情報応答メッセージも、IP上位レイヤメッセージとして送受される。
そして、本例の場合、xSPサーバ71は、LN5−jのLN-IDを読み取ったGN4-iに対してサービスを開始するにあたって、LN-HA12に対して連携情報検索メッセージ(図15の項番1参照)を発行することにより、LH-HA12のLN連携情報DB124からLN-IDに対応するGN-IP′アドレスの検索を依頼し、その検索結果を連携情報応答メッセージ(図15の項番2参照)により取得して、当該取得したGN-IP′宛にデータを送信するように構成される。なお、上記の連携情報検索/応答メッセージも、IP上位レイヤメッセージとしてLN-HA12−xSPサーバ71間を送受される。また、LN-HA12でのGN-IP′アドレス検索機能や検索結果応答としての連携情報応答メッセージの作成機能は、例えば、LN連携情報登録メッセージ処理部122(図5参照)の一機能として実現できる。
(B5.2.2)動作説明
以下、上述のごとく構成されたゲートウェイ2を含むネットワーク動作について、図16及び図17を参照しながら説明する。
まず、この場合も、LN5−jのRF-ID、即ちLN-IDがGN4−iに読み取られると(図16のステップC1)、GN4−iからGN-HA11に対してLN-IDとGN-ID(GN-IPアドレス)の対応が連携情報として通知される(図16のステップC2)。GN-HA11は、通知された当該連携情報を、GN-IPアドレスをキーとしてGN連携情報DB114(図4参照)に登録(記憶)するとともに、LN-HA12に通知すべく、LN-HA−ゲートウェイアドレス対応DB117を参照して、該当ゲートウェイ2宛に連携情報を前記連携情報登録メッセージ(図13の項番1参照;送信元アドレスは自GN-IPアドレスとする)により送信(通知)する(図16のステップC3)。
ゲートウェイ2は、この連携情報登録メッセージを受信すると(図17のステップD1)、IPアドレス変換機能部27′によって、当該メッセージの送信元アドレス(GN-IPアドレス)に対応するIPアドレスとして、自ゲートウェイ2にルーティングされるGN-IP′アドレスを生成してアドレス表(変換表)を作成するとともに、GN-IPアドレスを当該GN-IP′アドレスに変換する(図16のステップC4及び図17のステップD2)。
その後、ゲートウェイ2は、自アドレスにて受信した連携情報登録メッセージの宛先を、LN-HAアドレスDB21を参照することで、LN-HAアドレスとし、LN-HA12に対して、受信した連携情報登録メッセージの中継(図14の項番1参照)を行なう(図16のステップC5及び図17のステップD3)。ここでの実施例は、すべて、GN-HA11がLN-HA12のIPアドレスを格納していることを想定しているが、図16のステップC5において、ゲートウェイ2−LN-HA12間においてSOAPインタフェース等が適用できる場合などについては、LN-HA12が格納するアドレスは、LN-HA12のWeb通信用インタフェース、つまり、URL(Uniform Resource Locator)であってもよい。
最終的に、LN-HA12は、上記連携情報登録メッセージを受信すると、当該メッセージにより通知されたLN-IDとGN-IP′アドレスの連携情報を自己の連携情報DB124に保存する(図16のステップC6)。xSPサーバ71は、LN-IDを読み取ったGN4−iに対してサービスを開始する契機に、前記連携情報検索メッセージ(図15の項番1参照)を発行し、LN-HA12は、当該メッセージを受信すると、自己の連携情報DB124を参照して当該LN-IDに対応するGN-IP′アドレスを検索・取得し、当該GN-IP′アドレスを検索結果として連携情報応答メッセージ(図15の項番2参照)によりxSPサーバ71へ返信する(図16のステップC7)。
xSPサーバ71は、このようにしてLN-HA12から取得した取得したGN-IP′アドレス宛にデータを送信する(図16のステップC8)。送信されたデータは、ゲートウェイ2で受信され(図17のステップD4)、宛先アドレスがGN-IP′アドレスからGN-IPアドレスにアドレス変換されてGN-HA11にルーティングされ(図17のステップD5)、最終的に、当該GN-HA11管理下のGN4−iに到達する(図16のステップC9)。
このようにして、xSP等のLN-HA11を管理する事業者は、xSPサーバ71から、特定のLN-IDと連携するGN4−iに対して、広告情報等のコンテンツや緊急メッセージ等の送信を行なう契機に、LN-HA11の連携情報DB124から当該LN-IDに対応する変換GN-IP′アドレスを取得し、当該GN-IP′アドレスに対して、コンテンツや緊急メッセージ等の送信を行なう。
以上のように、GN-HA11とLN-HA12が異事業者によって管理されるようなネットワーク形態において、GN-HA11がLN-HA12に通知するGN-IDについてID変換を行なうので、特に、異事業者(xSP)がLN-ID(LN5−j)の詳細内容や属性を、ネットワークキャリアに対して隠蔽したようなケースにおいて、本アーキテクチャは有力である(xSPが、LN-HA11と独自のLN-IDのデータベース等を保有できるため)。
なお、xSPサーバ71の通信(ストリーミングコンテンツ送信)途中に、LN-HA11の連携情報DB124の内容が変化するような場合、LN-HA11が、変化のあったGN4−iのGN-IP′アドレスをxSPサーバ71に適宜通知するようにすることも可能である。
〔B6〕オブジェクト共用機構の説明
次に、以下では、LH-HA12に、オブジェクト共用機構を配備した例について説明する。図18はLN-HA12のオブジェクト共用機構に着目した構成を示す機能ブロック図である。この図18に示すように、本LN-HA12は、既述の位置制御プロトコルスタック123及びLN連携情報DB124(図5参照)に加えて、例えば、アプライアンス同時使用状態データベース(DB)125,連携情報メッセージ送受信部126,アプライアンス使用可/不可判定部127及びアプライアンス制御メッセージ送受信部128をそなえて構成される。
ここで、アプライアンス同時使用状態DB(共用数保持手段)125は、IPアドレスを保有しないアプライアンス(オブジェクト)、即ち、LN5−j毎に、LN5−jを使用中のGN数(「現使用数」),LN5−jを共用できるGN数の上限値及び共用可/不可等の使用状態に関する情報を保持しておくものであり、連携情報メッセージ送受信部126は、GN4−iとの間で連携情報メッセージを送受信する(後述するGN4−iからのアプライアンス(LN)連携情報登録/解除メッセージの受信及びそれらに対するGN4−iへの応答メッセージの送信)ためのものである。
アプライアンス使用可/不可判定部127は、この連携情報メッセージ送受信部126においてLN連携情報登録メッセージ(図20の項番1参照)が受信されると、アプライアンス同時使用状態DB125を参照して、該当LN5−jの使用可/不可を判定するもので、具体的には、「現使用数」が「上限値」未満であれば、使用可と判定し、「現使用数」が「上限値」であれば使用不可と判定するようになっている。また、連携情報メッセージ送受信部126にてLN連携情報解除メッセージ(図22の項番1参照)が受信された場合には、アプライアンス同時使用状態DB125の該当LN5−jの「現使用数」を減算し、位置制御プロトコルスタック123に対して、当該LN5−jの連携情報エントリの削除と、アプライアンス制御終了信号(電源OFF等)の発行とを依頼するようになっている。
このため、本例における位置制御プロトコルスタック123は、アプライアンス使用可/不可判定部127にて「使用可」と判定されれば、受信した連携情報をLN連携情報DB124に登録した後、当該LN5−jに対する制御信号(LN制御メッセージ;例えば、電源ON信号等)を生成するとともに、LN5−jの登録を行なってきたGN4−i宛に処理結果(OK)をLN連携情報登録応答メッセージ(図20の項番2参照)により返信する一方、「使用不可」と判定されれば、連携情報の登録は行なわずに、LN5−jの登録を行なってきたGN4−i宛のLN使用不可〔NG(使用中)〕を同じくLN連携情報応答メッセージ(図20の項番2参照)により返信する機能を有する。また、アプライアンス使用可/不可判定部127から、連携情報エントリの削除依頼とアプライアンス制御終了信号の発行依頼とがあれば、LN連携情報DB124から該当連携情報エントリを削除するとともに、その処理結果(OK等)を表すLN連携情報解除応答メッセージ(図22の項番2参照)を発行し、解除要求元のGN4−i宛にアプライアンス制御終了信号を発行する機能も有する。
つまり、この場合の位置制御プロトコルスタック123は、GN4−iから連携情報を受信すると、その連携情報に含まれるLN-ID,GN-IDと上記DB125における「現使用数」及びその「上限値」とに基づいて、GN4−iによる当該LN5−jの共用を制御する共用制御手段としての機能をも有するのである。
そして、アプライアンス制御メッセージ送受信部128は、LN5−jとの間でLN制御/応答メッセージ(図24参照)を送受信するためのものである。
以下、上述ごとく構成されたLN-HA12によるオブジェクト共用ネットワーク動作について、図19,図21,図23及び図25を用いて説明する。
(B6.1)アプライアンス登録時(図19及び図25)
図19に示すように、アプライアンス、即ちLN5−jのような非IPノードとLN-HA12のようなIPノードとの間で制御メッセージを送受可能にするために、IP/制御信号変換機能を具備するアプライアンスコントローラ8をネットワーク3に配備する。そして、例えば、GN4−iがアプライアンス(LN)5−1のRF-ID(LN-ID1)を読み取ると (ステップE1)、当該GN4−iは、LN-HA12にアクセスポイント(AP)9等を経由して読み取ったLN-IDと自己のGN-IDとの連携情報を登録しようと、当該連携情報を含むLN連携情報登録メッセージをLN-HA12に送信する(ステップE2)。
LN-HA12では、当該メッセージを受信すると、まず、そのメッセージに含まれるLN-IDがLN連携情報DB124に存在するか否かを位置制御プロトコルスタック123により確認し(図25のステップH1)、存在すれば(ステップH1でYesであれば)、アプライアンス使用可/不可判定部127により、アプライアンスの使用可/不可を判定する(ステップE3及び図25のステップH2)。今、図19ではアプライアンス5−1の「同時使用可能数」=1に対して、「現使用数」=0であるから、アプライアンス5−1は「使用可」の状態である。
したがって、LN-HA12は、アプライアンス使用可/不可判定部127により、アプライアンス5−1(LN-ID1)の現使用数を1つ増やして0から1に更新するとともに、GN4−iから受信した連携情報を位置制御プロトコルスタック123により自己のLN連携情報DB124に新規エントリとして登録した後(ステップE4及び図25のステップH2のYesルートからステップH3)、GN4−iが読み取ったLN-IDのLN-IDタグ情報をGN4−iに返信する(図25のステップH4)とともに、アプライアンスコントローラ8宛のアプライアンス5−1のLN制御メッセージ(図24の項番1参照)を発行する(ステップE5)。
これにより、上記LN制御メッセージの制御内容(電源ON,OFF,再生,チャネル切替等)に応じた制御がアプライアンスコントローラ8によってアプライアンス5−1に対して行なわれることになる。
なお、LN-HA12がGN4−iから受信したLN連携情報登録メッセージに含まれるLN-IDがLN連携情報DB124に存在しない場合、LN-HA12は、その旨をGN4−iに返信する(図25のステップH1のNoルートからステップH9)。
(B6.2)アプライアンス使用不可時(図23及び図25)
一方、上記のアプライアンスの使用可/不可判定において、例えば図23に示すように、アプライアンス5−1の「現使用数」=1で、それ以上新規の同時使用は不可能である場合(図25のステップH2でNoの場合)、LN-HA12は、アプライアンス5−1のLN-ID1に対してGN-IDのエントリがLN連携情報DB124に存在するか否かを確認する(図25のステップH5)。例えば、LN5−1をGN4−2が読み取って連携情報の登録を行なった(図23のステップG1〜G3)時点では、既に当該LN5−1を別のGN4−1が読み取って連携情報の登録を済ませていた場合、LN連携情報DB124には、LN-ID1とGN4−1のGN-ID1の連携情報エントリが存在することになる。
したがって、この場合、LN-HA12は、GN4−1の後にLN5−1を読み取ったGN4−2に対して「NG(使用中)」の旨を前記LN連携情報登録応答メッセージ(図20の項番2参照)により通知することになる(ステップG4及び図25のステップH5のYesルートからステップH6)。
なお、上記のステップH5においてGN-IDのエントリが存在しない場合は、新たにLN5−1を読み取ったGN4−2のGN-IDが読み取ったLN-IDとともにLN-HA12のLN連携情報DB124に新規登録され、当該GN4−2に、LN-IDタグ情報が返信される(図25のステップH5のNoルートからステップH7,H8)とともに、処理結果がLN連携情報登録応答メッセージにより返信される。
(B6.3)アプライアンス登録解除時(図21)
次に、図21に示すように、GN4−iによるアプライアンス5−1の使用が終了し、アプライアンス5−1がGN4−iから取り外される等すると、GN4−iから無線アクセスポイント9等経由でLN-HA12に対してLN連携情報解除メッセージ(図22の項番1参照)が発行される(ステップF1)。LN-HA12は、このメッセージを受信すると、そこに含まれるLN-IDに対応するアプライアンス同時使用状態DB125の「現使用数」を1つ減じるとともに、LN連携情報DB124の該当連携情報エントリを削除し(ステップF2,F3)、アプライアンス制御終了信号(電源OFF等)をアプライアンスコントローラ8に発行する(ステップF4)。これにより、アプライアンスコントローラ8は、受信した制御信号の内容に応じた制御をアプライアンス5−1に対して行なって、アプライアンス5−1の電源OFF等を行なうことができる。
以上のようにして、LN-HA12(連携管理機構1)を用いてアプライアンス5−jのリアルタイムな使用状況や同時使用可能数等の使用条件に応じたGN4−iへのアプライアンス5−jの割当てが可能となる。したがって、アプライアンス5−jが例えば公共アプライアンスやキオスク端末等のように、同時に複数のユーザにより使用されるようなものである場合に、当該オブジェクトの同時使用可能数及びリアルタイムな現使用数を管理することが可能となり、より実用的かつ動作可能なネットワークアーキテクチャを実現できる。
(B7)オブジェクトのグループ化管理(ユーザセッションを考慮した場合)の説明
次に、以下では、オブジェクト(LN5−j)をLN-HA12においてグループ化して管理するためのグループ管理機構について説明する。オブジェクトのグループ化管理を行なうことによって、オブジェクトの管理にスケーラビリティをもたせることができる。以下では、特に、IDカードによって認識されるユーザのセッション毎にオブジェクトの管理をLN-HA12において行なう場合を例示する。
(B7.1)対等なオブジェクトのグループ化によるオブジェクト管理(ユーザ毎のグループ化によるオブジェクト管理)
あるユーザがもつオブジェクト5−jに対して関連付けを行なう場合で、かつ、オブジェクト5−j同士の関連付けの組を、そのユーザのセッションとしてまとめて管理する例を以下に示す。なお、以下の例では、LN-HA12に、既に単一のオブジェクト群5(図1参照)を構成するLN5−1,5−2,5−3のLN-IDとして、それぞれ、LN-ID1, LN-ID2,LN-ID3がグループ(関連付けグループ)1(グループID=1)として登録されており(次表1参照)、GN4−1がLN5−1(LN-ID1)を読み込むものと仮定する。また、本例におけるGN4−1のGN-IDはGN-ID1とする。
なお、下記の表1に示すデータ(テーブル)は、例えば前記のLN連携情報DB124(図5参照)に保持することができる。この場合、当該DB124は、複数のLN5−jについてのLN-ID同士を予め関連付けた関連付けグループを保持する関連付けグループ保持手段としての機能を果たすことになる。もっとも、当該データは、当該LN連携情報DB124とは別に専用のメモリ等の記録媒体に保持することも可能である。
Figure 0004264339
(手順1)ユーザが一時的にGN4−1を保有した場合のセッションID割当て
(1.1)あるユーザがGN4−1を使用する場合、当該ユーザは自らのIDカードをGN4−1に読み込ませる。GN4−1は、LN-HA12に対して特定ユーザがGN4−1を保有したことを登録するため、登録要求をGN-ID1と共に送信する。
(1.2)LN-HA12は、当該登録要求を受信すると、上記ユーザがGN4−1を保有したとみなして、そのユーザが保有している間有効なセッションIDを割り振る(例えば、セッションID1)とともに、GN-ID1を登録し(次表2参照)、GN4−1に対して登録応答と共にセッションIDを送信する。
Figure 0004264339
(手順2)LN-IDの登録
(2.1):GN4−1がLN-ID1を読み込むと、GN4−1は、GN-ID1及びLN-ID1の組をセッションID(本例では、セッションID1)と共にLN-HA12に登録するよう要求する。
(2.2):LN-HA12は、上記要求を受信すると、上記表1の登録内容を参照してLN-ID1が属しているグループを検索し、そのグループのオブジェクトのLN-ID(LN-ID1, LN-ID2,LN-ID3)とGN-ID1との関連付けをセッションIDと共に登録する(次表3参照)。この機能は、例えば前記の局所位置登録機能部(位置制御プロトコルスタック)123(図5参照)の一機能として実現できる。つまり、当該機能部123は、受信手段としてのアクセス側ネットワークインタフェース121で受信した連携情報に含まれるGN-IDと、当該連携情報に含まれるLN-ID1を含む複数のLN-ID(LN-ID1, LN-ID2,LN-ID3)とを関連付けて記憶手段としてのDB124に登録する連携情報登録制御手段としての機能を果たす。また、上記インタフェース121で受信した連携情報に含まれるLN-IDが属する関連付けグループをDB124において検索する検索手段としての機能、この検索手段により検索された関連付けグループと上記インタフェース121で受信した連携情報に含まれるGN-IDとを関連付けてDB124に登録する登録手段としての機能をも果たす。
(2.3):LN-HA12は、GN4−1に対して、登録応答と共に、同じグループに属するオブジェクトのLN-ID(LN-ID1,LN-ID2,LN-ID3)を送信する。即ち、LN群5のうちの少なくとも一つのLN5−jのLN-IDを読み取って連携情報の登録を行なったGN4−iに対して、GN4−iが読み取ったLN5−jに関連付けられているLN群5を通知する。これにより、LN群5単位での連携情報管理が実現される。なお、この機能も、例えば上記機能部123の一機能として実現できる。つまり、この場合の機能部123は、上記検索手段により検索された関連付けグループに属する各LN-ID(LN-ID1, LN-ID2,LN-ID3)をGN4−iに通知する通知手段としても機能する。
Figure 0004264339
上記手順2によって、LN-HA12において、ユーザ毎のセッションに対して、グループ化されたオブジェクト群5の割当てが可能となり、ユーザにおいても、グループ化されたオブジェクトに関する情報が受信可能となる。即ち、1回のオブジェクト読み取りによって、複数のオブジェクトについての情報を入手可能となるため、オブジェクトの読み取り回数を低減することが可能となる。
(手順3)LN-IDの削除
(個別のリソースの関連付けを削除したい場合)
(3.1)GN4−1は削除したいLN-IDを、セッションIDと共にLN-HA12に対して削除要求(一部削除要求)として送信する。
(3.2)LN-HA12は、上記削除要求を受信すると、受信したセッションIDとLN-IDが共に含まれる関連付けを検索し、削除する(次表4参照)。これにより、GN4−iとLN群5の関連付けについて自LN連携情報DB124に登録を行なう連携管理機構1において、GN4−iを一時的に専有するユーザ毎に、上記連携情報を管理し、ユーザから削除要求のあったLN5−jについて、自連携管理機構1が保持するユーザ毎の連携情報から削除を行なうことが可能となる。なお、この機能も、例えば、上記機能部123の一機能として実現でき、この場合、当該機能部123は、GN4−iから特定のLN-IDについての一部削除要求を受けると、当該LN-IDをDB124の連携情報から削除する連携情報一部削除手段としての機能を果たすのである。
(3.3)LN-HA12は、削除応答を削除要求元のGN4−1に対して送信する。
Figure 0004264339
上記手順3によって、ユーザがグループ化されたオブジェクト情報を取得した場合においても、不要なオブジェクトの登録のみ消去可能となるため、ユーザのオブジェクト選択性が実現可能となる。
(手順4)該当ユーザ全ての関連付けを削除したい場合
(4.1)GN4−1は、削除したいセッションIDをLN-HA12に対して削除要求(関連付けグループについての全削除要求)として送信する。
(4.2)LN-HA12は、受信したセッションIDが含まれる関連付けを検索し、削除する(表5参照)。この機能も、例えば、上記機能部123の一機能として実現でき、この場合、当該機能部123は、GN4−iから前記関連付けグループについての全削除要求を受信すると、当該関連付けグループとGN-IDとの関連付け情報である連携情報をDB124から削除する連携情報全削除手段として機能するのである。
(4.3)LN-HA12は、削除応答を上記削除要求元のGN4−1に対して送信する。
Figure 0004264339
上記手順4によって、ユーザに関するセッション単位の全削除が実現される。
以上のようにして、LN-HA12は、ユーザが使用するオブジェクト(LN)5−jを管理する場合において、あるオブジェクトを単独のオブジェクトとしてではなく、ユーザ毎に、オブジェクトの集合体として管理することができる。したがって、例えば、プリンタトナーやマウスなど、単独では動作不可なオブジェクトを、予めプリンタ及びプリンタトナーの集合体,ノートPC及びマウスの集合体等として管理することができ、ユーザの観点から効率的な管理を実現することが可能となる。その結果、オブジェクト集合体を使用するためのユーザによる明示的なLN-HA12(連携管理機構1)への登録(アクセス)回数を大幅に低減することが可能となる。
(B7.2)親子関係が存在するオブジェクトによって構成される階層的なグループ化によるオブジェクト管理(ユーザ毎の階層化によるオブジェクト管理)
次に、上記のグループ化によるオブジェクト管理を拡張して、グループ化されるオブジェクト同士に親子関係が存在し、子オブジェクトの登録/削除が親オブジェクトと共に行なわれる場合について説明する。なお、以下においては、LN-HA12には、既にLN5−1,5−2,5−3のLN-IDとしてそれぞれLN-ID1,LN-ID2,LN-ID3が同一グループ1として登録されており、LN-ID2,LN-ID3の親LN-IDをLN-ID1とし、LN-ID1の親LN-IDは存在しないこととし(null:次表6参照)、GN4−1はLN-ID1を読み込むものとする。また、本例におけるGN4−1のGN-IDはGN-ID1とする。
なお、下記の表6に示すデータ(テーブル)も、例えば前記のLN連携情報DB124に保持することができる。つまり、この場合、当該DB124は、複数のLN5−1〜5−3についてのLN-ID(LN-ID1,LN-ID2,LN-ID3)同士の親子関係による階層的な関連付けグループを保持する階層関連付けグループ保持手段としての機能を果たすことになる。もっとも、当該データは、当該LN連携情報DB124とは別に専用のメモリ等の記録媒体に保持することも可能である。
Figure 0004264339
(手順1)ユーザが一時的にGN4−1を保有した場合のセッションID割当て
(1.1)あるユーザがGN4−1を使用する場合、当該ユーザは自らのIDカードをGN4−1に読み込ませる。GN4−1は、LN-HA12に対して特定ユーザがGN4−1を保有したことを登録するため、登録要求をGN-ID1と共にLN-HA12へ送信する。
(1.2) LN-HA12は、ユーザがGN4−1を保有したとみなして、ユーザが保有している間有効なセッションIDを割り振る(この例では、セッションID1)とともに、GN-ID(この例では、GN-ID1)を登録し、GN4−1に対して登録応答と共に送信する(表7参照)。
Figure 0004264339
(手順2)LN-IDの登録
(2.1)GN4−1がLN-ID1を読み込むと、GN4−1は、GN-ID1及びLN-ID1の組をセッションID(この例では、セッションID1)と共にLN-HA12に登録するよう要求する。
(2.2)LN-HA12は、LN-ID1が属しているグループを検索し、そのグループのオブジェクトのLN-ID(LN-ID1,LN-ID2,LN-ID3)とGN-ID1の関連付けをセッションIDと共に登録する。この時、グループ1が保持している親子関係をそのまま引き継ぐ(次表8参照)。
Figure 0004264339
この機能は、例えば、前記の局所位置登録機能部(位置制御プロトコルスタック)123の一機能として実現することができ、この場合、当該機能部123は、受信手段としてのアクセス側ネットワークインタフェース121で受信した連携情報に含まれるLN-IDが上位階層のLN-IDとして属する関連付けグループを上記階層関連付けグループ保持手段としてのDB124において検索する検索手段として機能するとともに、この機能により検索された階層関連付けグループの上位階層のLN-ID及び当該LN-IDと関連付けられた下位階層のLN-IDと、上記インタフェース121で受信した連携情報に含まれるGN-IDとを関連付けて連携情報DB124に登録する登録手段として機能することになる。
(2.3)LN-HA12は、GN4−1に対して登録応答と共に、同じグループに属するオブジェクトのLN-ID(LN-ID1,LN-ID2,LN-ID3)を送信する。このように、複数のLN5−j同士の親子関係による階層的な関連付けグループを予め保持する連携管理機構1において、階層的な関連付けグループにある上位階層のLN5−jを読み取った後に、このLN5−jを含む下位階層に存在する階層的な関連付けグループを、先の上位階層のLN5−jを読み取ったGN4−iに通知することによって、階層的な関連付けグループを利用した連携情報管理が実現される。
即ち、このような手順2によって、LN-HA12において、ユーザ毎のセッションに対して、階層的にグループ化されたオブジェクト群5の割当てが可能となり、ユーザにおいても、階層的にグループ化されたオブジェクト5−jに関する情報が受信可能となる。即ち、1回のオブジェクト読み取りによって、複数のオブジェクト5−jについての情報を入手することが可能となるため、この場合も、オブジェクトの読み取り回数を大幅に低減することが可能となる。
(手順3)LN-IDの削除(個別のリソースの関連付けを削除したい場合)
(3.1)GN4−1は、削除したいLN-IDを、セッションIDと共にLN-HA12に対して削除要求(LN-IDについての一部削除要求)として送信する。
(3.2)LN-HA12は、上記削除要求を受信すると、受信したセッションIDとLN-IDが共に含まれる関連付けを検索し (表9ではNo.5の行が該当)、さらに、そのLN-IDが親LN-IDとなっている関連付けを検索する(表9ではNo.6及びNo.7の行が該当)。かかる検索動作を、親LN-IDとなっている関連付けが存在しなくなるまで繰り返す。LN-HA12は、かかる操作によって得られた関連付けを、全て削除する(表9ではNo.5,No.6及びNo.7の行を全て削除する)。
Figure 0004264339
この機能も、例えば、前記の局所位置登録機能部123の一機能として実現でき、この場合、当該機能部123は、GN4−1から特定のLN-IDについての一部削除要求を受けると、当該LN-ID及び当該LN-IDの下位階層のLN-ID(子LN-ID)のすべてをDB124の連携情報から削除する階層連携情報一部削除手段として機能することになる。
(2.3)LN-HA12は、削除応答をGN4−1に対して送信する。
このような手順3によって、ユーザがグループ化されたオブジェクト5−jに関する情報を取得した場合、オブジェクト5−jの登録情報は親子関係によって削除される。このとき、親オブジェクトを削除した場合に、子オブジェクトも自動的に削除されるため、ユーザのオブジェクト削除処理回数を減少することができる。
(手順4)該当ユーザ全ての関連付けを削除したい場合
(4.1)GN4−1は、削除したいセッションIDをLN-HA12に対して削除要求(階層関連付けグループについての全削除要求)として送信する。
(4.2)LN-HA12は、受信したセッションIDが含まれる関連付けを検索し、削除する(表10参照)。
Figure 0004264339
この機能も、例えば上記の局所位置登録機能部123の一機能として実現でき、この場合、当該機能部123は、GN4−1から階層関連付けグループについての全削除要求を受信すると、当該階層関連付けグループの上位及び下位階層の各LN-IDとGN-IDとの関連付け情報である連携情報をDB124から削除する階層連携情報全削除手段として機能することになる。
(4.3)LN-HA12は、削除応答をGN4−1に対して送信する。
このような手順4によって、ユーザに関するセッション単位の全削除が実現される。
以上のようにして、LN-HA12は、ユーザ毎の、階層グループで構成されるオブジェクト5−jの管理を行なうことができる。したがって、例えば、上位階層のオブジェクト5−jの使用を解除する場合に、下位階層のオブジェクト5−jを使用している状態が無意味になってしまうようなケース(ノートPCの使用を解除した場合に、マウスやキーボードを使用している状態が不要になる等)において、ユーザが上位階層のオブジェクト5−jの使用を解除した場合に、下位階層の全てのオブジェクト5−jを解除することができるので、ユーザによるオブジェクト使用解除処理回数を大幅に低減することが可能となる。
〔B8〕DN導入によるGN機能の移動
次に、以下においては、ユーザがDN6(図1参照)を所有している場合に、当該DN6又は当該DN6をGN4−iに読み込んでGN4−iにてコンテンツの受信を選択的に行なうための機構について説明する。
(B8.1)DN6の階層化をベースにしたGN機能移動
図26は本実施形態に係るDN6の構成を示す機能ブロック図で、この図26に示すDN6は、図2により前述したGN4−iとしての機能を果たすGN機能部61と、図3により前述したLN5−jとしての機能を果たすLN機能部62とをそなえて構成されており、これらの各機能部61,62がそれぞれ独立して動作を行なうようになっている。なお、GN機能部61は、図2により前述したものとそれぞれ同様の局所(ローカル)ネットワークインタフェース41,LN情報収集部(RF-IDリーダ等)42,LN情報抽出部43,GN個別識別情報記憶部44,広域(グローバル)位置登録機能部45及び広域(グローバル)ネットワークインタフェース46をそなえて構成され、LN機能部62は、図3により前述したものとそれぞれ同様の個別識別情報記憶部(メモリ)51,読み取り要求検出部52,読み取り要求応答部53及び情報読み取りインタフェース54をそなえて構成される。
以下、上述のごとくGN4−iとしての機能とLN5−jとしての機能の双方をそなえたDN6のネットワーク3上での動作例について、図27〜図29を用いて詳述する。ただし、以下において、LN5−1はRF-ID(LN-ID)としてLN-ID1を有し、GN4−1はGN-IDとしてGN-ID1を有し、DN6は、GN-IDとしてGN-ID2とRF-ID(LN-ID)としてLN-ID2の2つのIDを有しているものとする。
(登録時の動作)
まず、DN6は、例えば図27に示すように、自己がGNとして機能するノード(GN機能ノード)となるべく、LN5−1のRF-ID(LN-ID1)の読み取ると (ステップJ1)、そのLN5−1のID(LN-ID1)と自己のGN-ID(GN-ID2:例えば、DN6のIPアドレス)との対応を連携情報としてGN-HA11及びLN-HA12宛に送信して連携情報(第1の連携情報)の登録を行なう(ステップJ2)。
次に、例えばGN4−1が、GN4−1からみてLNとして位置付けられるDN6のRF-ID(LN-ID2)を読み取り(ステップJ3)、そのRF-ID(LN-ID2)と自己のGN-ID(GN-ID1:例えば、GN4−1のIPアドレス)との対応を連携情報としてGN-HA11及びLN-HA12宛に送信して連携情報(第2の連携情報)の登録を行なう(ステップJ4)。なお、以上のステップJ1,J2での登録処理とステップJ3,J4での登録処理の順序は入れ替わってもよい。
つまり、この場合、GN-HA11及びLN-HA12におけるアクセス側ネットワークインタフェース111及び121は、それぞれ、DN6がLN5−jから読み取ったLN-IDとDN6が保有するGN-IDとの組を当該DN6から第1の連携情報として受信する第1の受信手段としての機能と、LN5−jのLN-IDの読み取りを行なったDN6からGN4−iが読み取ったDN6が保有するLN-IDと当該GN4−iが保有するGN-IDとの組を当該GN4−iから第2の連携情報として受信する第2の受信手段としての機能を果たしていることになる。
図28(A)に、上記のステップJ1〜J4で示す登録手順が終了した際のLN-HA12で保持・管理されるLN連携情報テーブル13の登録内容例、図28(B)に、上記のステップJ1〜J4で示す登録手順が終了した際のGN-HA11で保持・管理されるGN連携情報テーブル14の登録内容例、図28(C)に、LN-HA12またはGN-HA11において、予め管理されているDN6のGN-IDとLN-IDとの対応テーブル15の登録内容例をそれぞれ示す。
そして、例えば、LN連携情報テーブル13はLN-HA12のLN連携情報DB124(図5参照)に、GN連携情報テーブル14は、GN-HA11のGN連携情報DB114(図4又は図12参照)にそれぞれテーブル形式データのデータとして保持(登録)される。また、対応テーブル15は、LN-HA12ではLN連携情報DB124に、GN-HA12ではGN連携情報DB114にてテーブル形式のデータとして保持(登録)される。
かかる登録機能は、例えば、GN-HA11及びLN-HA12の位置制御プロトコルスタック113及び123の一機能としてそれぞれ実現でき、この場合、当該プロトコルスタック113及び123は、それぞれ、上記インタフェース111及び121で受信した上記の第1の連携情報と第2の連携情報とを関連付けて記憶手段としての例えばDB114及びDB124に登録する連携情報登録制御手段としての機能を果たすことになる。
ところで、DN6等のネットワーク端末に付与されているRF-ID(LN-ID2)については、予めネットワーク管理者が保持している場合がある。例えば、第一種電気通信事業者が販売を行なう携帯端末において、第一種電気通信事業者は、自ネットワーク3上にて管理を行なう一意なGN-IDと、ユーザに販売した携帯端末に付与されているLN-IDとの対応を保持しているケースが存在する。
このような場合に、図26において、xSPサーバ71が、LN-HA12のLN連携情報DB124(図5参照)を検索し(ステップJ5)、LN-ID1のオブジェクト5−1を有するGN4−1に対して、LN-ID1についてのコンテンツを送信する場合、xSPサーバ71が、まず、LN-ID1を検索キーとして図28(A)に示すLN連携情報テーブル13を検索すると、LN-ID1に対応するGN-ID2が参照される。
次に、LN-HA12は、GN-ID2を保持するノードがDN6であるか否かを判断するために、当該GN-ID2を検索キーとして図28(C)に示す対応テーブル15を検索する。その結果として、図28(C)に示す対応テーブル15に、GN-ID2をキーとするエントリが参照され、GN-ID2に対応するLN-ID2が得られる。さらに、このLN-ID2を検索キーとして再び図28(A)に示すLN連携情報テーブル13を検索するとGN-ID1が参照される。同様に、GN-ID1を検索キーとして図28(C)に示す対応テーブル15を検索すると、エントリが存在しない。よって、LN-ID1に対する最終的な関連付けを保持するノードのGN-IDは、GN-ID1と決定される。
以上の検索結果より、LN-HA12は、xSPサーバ71に対して、LN-ID1に対応するGN-IDとしてGN-ID1を返信する。xSPサーバ71は、LN-HA12からのGN-ID1の通知を受信すると、当該GN-ID1を宛先アドレスとして、LN-ID1に関連するコンテンツを送信する。これにより、当該コンテンツは、GN-HA11経由で、DN6を介してLN5−1が読み込まれているGN4−1にて受信される。
このように、本例では、DN6を使用しているユーザが意図的に、当該DN6以外のGN機能ノード(GN4−i)を用いて、DN6のLN-IDを読み取ることによって、ユーザが使用ネットワーク端末(ノード)をDN6からGN4−iに変更してDN6が使用しているGN機能を一時的に他のGN機能ノード4−1に移動させることが可能であり、このような場合においても、LN5−j(LN-ID)に関連するコンテンツ等を当該GN4−iにて正常に継続受信することが可能となる。
したがって、ユーザは、例えば、コンテンツ受信のためのDN6の性能(メモリ,CPU,インタフェース速度等)が不足あるいは不十分な場合に、ユーザが使用中のDN6を十分な性能をもつGN4−iに読み取らせて当該GN4−iをGN機能ノードとして動作させることにより当該GN4−iにてコンテンツ受信を継続して行なうことができる。
(解除時の動作)
一方、GN4−1とDN6の連携を解除する、即ち、GN4−1でのコンテンツ受信からDN6でのコンテンツ受信に切り替える場合には、図27において、GN4−1を保持したユーザが、GN-ID1とLN-ID2との関連付けの解除を、GN-HA11及びLN-HA12に対して行なえばよい。即ち、例えば、ユーザがGN4−1に対して解除操作を行なった、あるいは、DN6とGN4−1との接続が切り離されたこと等を契機に、GN4−1は、GN-HA11及びLN-HA12に対して、GN-ID1とLN-ID2との関連付けの解除要求を発行し、これを受けたGN-HA11及びLN-HA12は、それぞれ、図29(A),図29(B)に示すように、連携情報テーブル13,14の2行目のエントリを削除する。なお、この削除機能も、例えば前記の位置制御プロトコルスタック113及び123の一機能としてそれぞれ実現でき、この場合、当該プロトコルスタック113及び123は、それぞれ、DN6から上記関連付けの解除要求を受信すると、DB123及び124における前記の第1の連携情報と第2の連携情報との関連付けを削除する連携情報削除手段としての機能を果たすことになる。
この状態で、xSPサーバ71が、再度、LN-HA12内の図29(A)及び図29(C)に示すテーブル13,15について検索を行なう。即ち、LN-HA12は、LN-ID1を検索キーとして図27(A)に示すLN連携情報テーブル13を検索して、LN-ID1に対するGN-ID2を得る。次に、LN-HA12は、このGN-ID2を保持するノードが、DN6であるか否かを判断するために、当該GN-ID2を検索キーとして図29(C)に示す対応テーブル15を検索する。
その結果として、図29(C)に示す対応テーブル15に、GN-ID2に対するエントリが参照され、GN-ID2に対応するLN-ID2が得られる。さらに、LN-HA12は、このLN-ID2を検索キーとして再び図29(A)に示すLN連携情報テーブル13を検索するが、この場合、LN-ID2に対応するエントリは、図29(A)に示すように既に削除されているので、LN-HA12は、xSPサーバ71に対して、LN-ID1に対応する最終的なGN-IDとしてGN-ID2を返信する。これにより、xSPサーバ71は、LN-ID1に対応するGN-ID2を保有するDN6宛に、LN-ID1(LN5−1)に関連するコンテンツを送信する。
以上のようにして、GN機能移動後も、適宜、コンテンツの受信先をGN4−1からDN6へ復元(変更)することが可能となる。
(B8.2)DNの階層化をベースにしたDN判定によるリアルタイムフローの変更
上述した例においては、DN6とGN4−iとの間においてコンテンツ出力(受信)先を変更することが可能であるが、xSPサーバ71主導で受信先を変更するため、リアルタイムな経路変更に対応できない可能性がある。そこで、以下では、LN-HA12が、連携情報の変更を検出する方法や、xSPサーバ71に対して経路変更を通知する方法について、図30〜図34を用いて説明する。
(登録時の動作)
まず、例えば図30に示すように、LN-HA12が、図27の場合と同様にして、連携情報を受信して連携情報の登録内容を変更すると(ステップJ1〜J4)、xSPサーバ71に、連携情報の変更をxSPサーバ71に通知する(ステップJ5′)。ここで、例えば図31(A)に示すように、ユーザの保有するDN6−1が、複数のオブジェクト(LN5−3,5−4)を読み込んでいる場合において、ユーザが、DN6−1からDN6−2へとGN機能を移動させる(DN6−2をGN機能ノードとする)ことができるような場合を想定する。なお、DN6−1,6−2は、いずれも、図26に示す構成と同一もしくは同様の構成を有するものとする。また、LN5−3はLN-ID3、LN5−4はLN-ID4をそれぞれ有し、DN6−1はGN-ID1及びLN-ID1、DN6−2はGN-ID2及びLN-ID2をそれぞれ有しているものとする。
この場合、LN-HA12は、例えば図31(B1),図31(C1)にそれぞれ示すような、各LN5−3,5−4のセッション(LN-IDセッション)毎に、LN-IDとGN-IDとの対応(連携情報)を保持する連携情報テーブル(LN-ID管理テーブル)16,17をそなえるとともに、図31(D)に示すような、DN6−1,6−2に割り当てられているGN-ID及びLN-IDを保持するDNデータベース18をそなえて構成される。なお、これらのテーブル16,17及びデータベース18は、いずれも、LN連携情報DB124(図5参照)にテーブル形式のデータとしてその全部又は一部を保持してもよいし、別のDB等に保持してもよい。なお、このようにLN-IDセッション毎に、LN-ID管理テーブル16,17を用意するのは、LN-ID毎に、連携情報の変更を検出できるようにするためである。
そして、図31(B1)及び図31(C1)は、まず、DN6−1がLN5−3,5−4をそれぞれ読み取った後のLN-HA12にける、LN-ID3セッションについての管理テーブル16,LN-ID4セッションについての管理テーブル17の連携情報の登録状態をそれぞれ示している。図31(B1)を例にすると、LN-HA12は、DN6−1が読み込んだLN-ID3と当該DN6−1のGN-ID1との対応を図31(B1)に示すように、管理テーブル16の1行目に連携情報として登録する。次に、LN-HA12は、登録したGN-ID1を検索キーとして図31(D)に示すDNデータベース18を検索することにより、当該GN-ID1に対応するLN-ID1を得る。
ここで、LN-HA12は、上記検索により得られたLN-ID1のみを図31(B1)に示すように、管理テーブル16の2行目のエントリに登録しておく。これは、LN-ID1(DN6−1)を次に読み込んだ上位ノード(ここでは、DN6−2)が、LN-ID3セッションについての管理テーブル16aのエントリに登録されることが予め分かっているからである。
さて、図31(B1)に示すLN-ID3についての管理テーブル16の登録状態において、xSPサーバ71が、LN-ID3を検索キーとして、対応するGN-IDを当該管理テーブル16において検索した場合、LN-ID3に対応する最終的なエントリとして、GN-ID1が検索結果として得られるので、xSPサーバ71は、当該GN-ID1の通知を受けて、そのGN-ID1を保持する(割り当てられた)DN6−1に対して、当該DN6−1が読み込んだLN-ID3(LN5−3)の属性に応じたコンテンツ等を連続的に送信する。
その後、DN6−1がxSPサーバ71からのコンテンツ等を受信中に、ユーザが意図的に、図31(A)に示す別のDN6−2を用いて、DN6−1のLN-ID(LN-ID1)を読み取ったとする。
すると、DN(GN機能ノード)6−2は、LN-HA12に対して連携情報(LN-ID1とGN-ID2との対応)の登録を行なうが、この場合、LN-HA12は、図31(B1)中のLN-ID1と一致する連携情報の登録があったことを検出し、LN-ID1とGN-ID2の対応を図31(B2)に示すように、LN-ID3についての管理テーブル16に格納する。この際、当該管理テーブル16の3行目のエントリにLN-ID2も登録しておく。その理由は図31(B1)の場合と同様である。このとき、LN-HA12は、図31(C1)に示すLN-ID4についての管理テーブル17おいても、図31(B1)と同じ登録状態であるため、図31(B2)に示す登録状態と同様に、図31(C2)に示すように、連携情報(LN-ID1とGN-ID2との対応)を登録しておく。
そして、LN-HA12は、上述のごとく管理テーブル16,17が書き換えられたことを契機に、LN-ID3及びLN-ID4についての管理テーブル16,17の先頭(1行目のエントリ)にそれぞれ登録されている自LN-IDと、これに連携する最終的な(つまり、現在の)GN-ID(ここでは、2行目のエントリのGN-ID2)と、図31(D)に示すDNデータベース18を用いてLN-ID1を検索キーとして検索された旧GN-ID(ここでは、GN-ID1)とを、連携情報変更通知メッセージ(図32の項番1参照)により、xSPサーバ71に送信することによって、GN機能ノード(ここでは、DN6−2)主導によるxSPサーバ71への経路切り替えの指示(xSPサーバ71からDN6−2へのルート設定)が可能となる。なお、xSPサーバ71は、上記連携情報変更通知メッセージに対する応答(OK又はNG)を連携情報変更通知応答メッセージ(図32の項番2参照)によりLN-HA12に対して返信する。
(解除時の動作)
さて、次に、以下では、DN6−2においてLN-ID3に関連するコンテンツ等を受信している状態において、ユーザが、コンテンツの受信を行なうノードをDN6−2からDN6−1に戻す場合(連携情報の解除動作)について説明する。
この解除動作は、DN6−2が、LN-HA12に対して、自身のGN-ID(GN-ID2)と、読み込んだLN-ID(LN-ID1)との対応の解除要求メッセージ(図33の項番1参照)を送信することによって実行される。即ち、LN-HA12は、当該解除要求メッセージを受信すると、図34(A),図34(B)及び図34(C)に示すように、連携情報の解除(削除)を行なう。LN-HA12は、このようにして連携情報の解除を行なった後、連携情報解除応答メッセージ(図33の項番2参照)を上記解除要求メッセージの応答(OK又はNG)としてDN(GN機能ノード)6−2に返信する。
以上のようにして、連携情報の解除をそれぞれのLN-IDに対して行なうことで、データ転送経路の切り替えが可能となる。
本方式は、複数のDN6が階層的に連なる場合や、LN-IDを読み込んだGN4−iが複数台存在する場合においても、容易に適用可能である。また、LN-IDが、xSPサーバ71等において管理されているユーザのIDである場合においては、xSPサーバ71は、特定のユーザに対して、使用ネットワーク端末変更時においても、常に、コンテンツ等を正常に受信させ続けることができる、といったメリットがある。
なお、上述したLN-HA12におけるデータ転送経路の切り替え(リアルタイムフローの変更)機能も、例えば、前記の位置制御プロトコルスタック123の一機能として実現できる。この場合、当該プロトコルスタック123は、LN連携情報DB124において前記の第1の連携情報と第2の連携情報との関連付けの生成/解除を監視する監視手段として機能するとともに、この監視手段にて上記関連付けの生成が確認されると、LN5−jを使用している装置(ノード)がDN6からGN4−iに変更されたと認識して、当該LN5−jに関する情報の送信先をGN4−iに変更する指示をLN5−jに関する情報の送信元であるxSPサーバ71に送信し、上記監視手段にて上記関連付けの解除が確認されると、LN5−jを使用しているノードがGN4−iからDN6に変更されたと認識して、LN5−jに関する情報の送信先をDN6に変更する指示をxSPサーバ71に送信する送信先変更指示手段として機能するのである。
〔C〕補足
上述した実施形態では、GN4−iを管理するGN-HA11と、LN5−jを管理するLN-HA12のような2つのHAが連携動作するような場合を前提としているが、本発明は、これに限らず、LN-HA12単独で動作することも可能である。GN-HA11は、モバイルIPにおけるHAとしての機能を果たすが、本発明は、必ずしも、モバイルIP,GN-HA,IPコアネットワークの存在を必要とするわけではない。例えば、図35,図36,図37に示すように、無線LAN(Local Area Network)のような無線アクセスネットワーク等への適用も可能であるし、また、図38に示すように、モバイルIPを用いない場合においても動作可能である。以下、これらの変形例について説明する。
(C1)無線LAN利用の実施例(補足1)
図35に示すように、無線基地局(BS)等の複数のアクセスポイント32−1,32−2,32−3がハブ31により集線されるとともに、当該ハブ31を介してLN-HA12及びxSPサーバ71が、いずれかのアクセスポイント(AP)32−1,32−2,32−3に無線回線により接続したGN4−iと通信できるような無線LANネットワーク形態を想定する。なお、この場合、アクセスポイント32−1,32−2,32−3は、それぞれ、その識別子としてBSS-ID1,BSS-ID2,BSS-ID3を有しており、GN4−1はGN-ID(GN-IPアドレス)としてIP1を有し、LN5−jはLN-IDとしてLN-ID1を有しているものとする。
ここで、例えば、AP32−1のカバーエリア33に存在するGN4−1が、LN5−1のLN-ID1を読み取ると、無線ネットワーク上のLN-HA12のDB124(図5参照)には、LN-ID,GN-IPアドレス(IP1)及びAP32−1のMAC(Media Access Control)アドレスを示すBSS-ID(BSS-ID1)が登録される。なお、この場合のLN-IDは、ユーザのネットワーク上でのID等の情報であってもよい。
xSPサーバ71は、LN-HA12内のDB124を、LN-ID(この場合は、LN-ID1)を検索キーとして検索して対応するIPアドレス(IP1)を取得し、当該アドレス宛に、LN-ID1に適合するストリーミングコンテンツ等を送信する。なお、LN-HA12に、GN-IPアドレス以外の情報(GN4−iの属性等)も保持させる場合には、サーバ71は、LN-HA12からGN4−iの属性を取得し、当該GN4−iの属性に応じたコンテンツ送信等を行なうことも可能である。
(C2)無線LAN利用の実施例(補足2)
次に、図36に示すように、図35に示す構成を前提としつつ、複数のGN4−1,4−2が同一のLN5−1を読み込む場合について説明する。これは、例えば、ユーザIDカードを所有したユーザが複数のGN4−1,4−2を用いる場合である。上述した補足1と同様の手順によって、xSPサーバ71は、LN-ID(ここでは、LN-ID1)に対応する複数のGN-IPアドレス(IP1,IP2)宛に、LN-ID1に適合するストリーミングコンテンツ等を送信することができる。
(C3)無線LAN利用の実施例(補足3)
次に、図37に示すように、LN-HA12を含むネットワーク内において、DHCPサーバのようなIPアドレス管理サーバ34が存在する場合を示す。なお、この図37において、既述の符号と同一符号を付したものはそれぞれ既述のものと同一もしくは同様のものである。この場合、GN4−i(ここでは、GN4−1)がIPアドレス管理サーバ34から取得したIPアドレス(IP1)をLN-HA12の管理情報内に含めることが可能である。
即ち、GN4−1は、IPアドレス管理サーバ34から、IPアドレス=IP1を取得した後、LN5−1のLN-ID1を読み込むと、当該LN-ID1とIPアドレス管理サーバ34から取得したIPアドレス=IP1との組を連携情報としてLN-HA12に登録する。そして、xSPサーバ71は、LN-HA12のデータベース124から、上記LN-ID1に対応するIPアドレス=IP1を取得し、当該IPアドレス=IP1宛にストリーミングコンテンツ等を送信する。
なお、ここでのIPアドレス管理サーバ34は、GN-HA12そのものではない。つまり、本発明では、GN-HA12は、IPアドレスを〔ホームアドレス(HoA)からケアオブアドレス(CoA)に〕変換するものであり、IPアドレス管理サーバ34は、単にIPアドレスを割り当てるサーバに過ぎないという位置付けである。
(C4)ゲートウェイ2を含んだネットワークの変形例(補足4)
また、前述したゲートウェイ2は、必ずしもモバイルIPに特化した技術ではない。
例えば図38に示すように、GN4−iが、LN-HA12に直接自身のIPアドレス(GN-ID)を登録することも可能である(ステップA2′)。この場合は、図9に示すようなモバイルIPのホームエージェントに相当するGN-HA11は存在しないため、この図38に示すステップA5において、ゲートウェイはIPアドレスを、GN-HA12のアドレスではなく、直接、GN4−1のIPアドレスに変換することができる。なお、他の動作は基本的に図4により前述した動作(ステップA1,A3〜A4,A6〜A8)と同様である。
このように、本変形例においても、前述した実施形態と同様に、キャリアネットワーク3とxSPネットワーク7とで構成されるネットワーク形態において、キャリアネットワーク3がIPv6アドレス体系等で構成される場合に、IPv6アドレスを有するユーザが保持するモノ(アプライアンス)についての情報を、xSPサーバ71に通知してしまうことを防止することができる。
これは、ビジネス形態としては、ネットワークキャリアがxSPに定額のコンテンツ料金を支払う場合等において、ネットワークキャリアがxSPに通知する情報は、必ずしも、IPv6アドレス等の加入者情報そのものである必要はなく、加入者が有しているモノや位置情報であるようなケースも考えられるため、本実施形態のゲートウェイ2は、前述したように、ネットワークキャリアからxSPサーバ71に対して通知する必要のない加入者情報を隠蔽するのに効果がある。なお、ネットワークキャリアとxSPを、企業とxSPに置き換えた場合についても、この種のネットワーク事業形態は成立する。
(C5)その他
なお、上述した実施形態で説明した連携管理機構1(GN-HA11,LN-HA12)の機能は必要に応じて1つ以上適宜組み合わせて適用することができる。
そして、本発明は上述した実施形態に限定されず、本発明の趣旨を逸脱しない範囲で種々変形して実施できることはいうまでもない。
〔D〕付記
(付記1)
第1の識別子を保有する第1の装置と、第2の識別子を保有するとともに該第1の識別子を該第1の装置から読み取って当該第1の識別子と該第2の識別子との組を連携情報として送信しうる第2の装置とをそなえたシステムに用いられ、該連携情報を管理する連携情報管理装置であって、
該連携情報を受信する受信手段と、
該連携情報を記憶する記憶手段と、
該受信手段で受信した連携情報に含まれる第2の識別子と、当該連携情報に含まれる第1の識別子を含む複数の第1の識別子群とを関連付けて該記憶手段に登録する連携情報登録制御手段とをそなえたことを特徴とする、連携情報管理装置。
(付記2)
複数の該第1の装置についての第1の識別子同士を予め関連付けた関連付けグループを保持する関連付けグループ保持手段をさらにそなえるとともに、
該連携情報登録制御手段が、
該受信手段で受信した連携情報に含まれる該第1の識別子が属する関連付けグループを該関連付けグループ保持手段において検索する検索手段と、
該検索手段により検索された関連付けグループと該受信手段で受信した連携情報に含まれる該第2の識別子とを関連付けて該記憶手段に登録する登録手段と、
該検索手段により検索された関連付けグループに属する各識別子を該第2の装置に通知する通知手段とをそなえたことを特徴とする、付記1記載の連携情報管理装置。
(付記3)
該連携情報登録制御手段が、
該第2の装置から特定の第1の識別子についての一部削除要求を受けると、当該第1の識別子を該記憶手段の連携情報から削除する連携情報一部削除手段をそなえたことを特徴とする、付記2記載の連携情報管理装置。
(付記4)
該連携情報登録制御手段が、
該第2の装置から該関連付けグループについての全削除要求を受信すると、当該関連付けグループと該第2の識別子との関連付け情報である連携情報を該記憶手段から削除する連携情報全削除手段をそなえたことを特徴とする、付記2又は3に記載の連携情報管理装置。
(付記5)
複数の該第1の装置についての第1の識別子同士の親子関係による階層的な関連付けグループを保持する階層関連付けグループ保持手段をさらにそなえるとともに、
該連携情報登録制御手段が、
該受信手段で受信した連携情報に含まれる該第1の識別子が上位階層の識別子として属する関連付けグループを該階層関連付けグループ保持手段において検索する検索手段と、
該検索手段により検索された階層関連付けグループの該上位階層の識別子及び当該識別子と関連付けられた下位階層の識別子と、該受信手段で受信した連携情報に含まれる該第2の識別子とを関連付けて該記憶手段に登録する登録手段と、
該検索手段により検索された関連付けグループに属する各識別子を該第2の装置に通知する通知手段とをそなえたことを特徴とする、付記1記載の連携情報管理装置。
(付記6)
該連携情報登録制御手段が、
該第2の装置から特定の第1の識別子についての一部削除要求を受けると、当該第1の識別子及び当該識別子の下位階層の識別子のすべてを該記憶手段の連携情報から削除する階層連携情報一部削除手段をそなえたことを特徴とする、付記5記載の連携情報管理装置。
(付記7)
該連携情報登録制御手段が、
該第2の装置から該階層関連付けグループについての全削除要求を受信すると、当該階層関連付けグループの上位及び下位階層の各識別子と該第2の識別子との関連付け情報である連携情報を該記憶手段から削除する階層連携情報全削除手段をそなえたことを特徴とする、付記5又は6に記載の連携情報管理装置。
(付記8)
第1の識別子を保有する第1の装置と、第2の識別子を保有するとともに該第1の識別子を該第1の装置から読み取って当該第1の識別子と該第2の識別子との組を連携情報として送信しうる第2の装置とをそなえたシステムに用いられ、該連携情報を管理する連携情報管理装置であって、
該第1の装置を使用中の該第2の装置数(以下、現使用数という)と当該第1の装置を共用できる該第2の装置数の上限値とを該第1の識別子別に保持する共用数保持手段と、
該第2の装置から該連携情報を受信すると、当該連携情報に含まれる上記各識別子と該共用数保持手段における該現使用数及び該上限値とに基づいて、当該第2の装置による当該第1の装置の共用を制御する共用制御手段とをそなえたことを特徴とする、連携情報管理装置。
(付記9)
他装置によって読み取られる第1の識別子を保有する第1の装置と、第2の識別子を保有するとともに該第1の識別子を該第1の装置から読み取って当該第1の識別子と該第2の識別子との組を連携情報として送信しうる第2の装置と、該第1の装置としての機能と該第2の装置としての機能とを兼ね備えた第3の装置とをそなえたシステムに用いられ、該連携情報を管理する連携情報管理装置であって、
該第3の装置が該第1の装置から読み取った該第1の装置の第1の識別子と該第3の装置が保有する第2の識別子との組を該第3の装置から第1の連携情報として受信する第1の受信手段と、
該第1の装置の該第1の識別子の読み取りを行なった該第3の装置から該第2の装置が読み取った該第3の装置が保有する第1の識別子と当該第2の装置が保有する第2の識別子との組を該第2の装置から第2の連携情報として受信する第2の受信手段と、
該連携情報を記憶する記憶手段と、
該第1の受信手段で受信した該第1の連携情報と該第2の受信手段で受信した該第2の連携情報とを関連付けて該記憶手段に登録する連携情報登録制御手段とをそなえたことを特徴とする、連携情報管理装置。
(付記10)
該連携情報登録制御手段が、
該第3の装置から該関連付けの解除要求を受信すると、該記憶手段の該第1の連携情報と該第2の連携情報との関連付けを削除する関連付け削除手段をそなえたことを特徴とする、付記9記載の連携情報管理装置。
(付記11)
該連携情報登録制御手段が、
該記憶手段において該第1の連携情報と該第2の連携情報との関連付けの生成/解除を監視する監視手段と、
該監視手段にて該関連付けの生成が確認されると、該第1の装置を使用している装置が該第3の装置から該第2の装置に変更されたと認識して、該第1の装置に関する情報の送信先を該第2の装置に変更する指示を該第1の装置に関する情報の送信元に送信し、該監視手段にて該関連付けの解除が確認されると、該第1の装置を使用している装置が該第2の装置から該第3の装置に変更されたと認識して、該第1の装置に関する情報の送信先を該第3の装置に変更する指示を該送信元に送信する送信先変更指示手段とをそなえたことを特徴とする、付記10記載の連携情報管理装置。
(付記12)
第1の識別子を保有する第1の装置と、第2の識別子を保有するとともに該第1の識別子を該第1の装置から読み取って当該第1の識別子と該第2の識別子との組を連携情報として送信しうる第2の装置と、該連携情報を受信して管理する連携情報管理装置と、該第1の装置に関する情報を送信する情報提供サーバとをそなえた連携情報管理システムに用いられるゲートウェイ装置であって、
該情報提供サーバが該第1の装置の該第1の識別子を読み取った該第2の装置宛に該第1の装置に関する情報を送信するために必要な該第2の識別子を該連携情報管理装置から受信する受信手段と、
該受信手段で受信した該第2の識別子を該情報提供サーバへの通知のための他の識別子に変換する識別子変換手段と、
該識別子変換手段による変換後の識別子を該情報提供サーバへ送信する送信手段と、
該情報提供サーバからの該情報に付与された該変換後の識別子を該変換前の識別子に逆変換して該第2の装置宛に転送する情報転送手段とをそなえたことを特徴とする、連携情報管理システムに用いられるゲートウェイ装置。
以上詳述したように、本発明によれば、ユーザの周辺にあるアプライアンスを含めたコンテキスト・アウェアサービス、例えば、ユーザの端末装置や、ユーザ周辺のアプライアンスに応じた情報配信等を適切に行なうサービスを実現できるので、かかるサービスを提供する産業において極めて有用であると考えられる。
本発明の一実施形態に係る連携情報管理システムの構成を示すブロック図である。 図1に示すGNの構成を示す機能ブロック図である。 図1に示すLNの構成を示す機能ブロック図である。 図1に示す連携管理機構を構成するGN-HAの構成を示す機能ブロック図である。 図1に示す連携管理機構を構成するLN-HAの構成を示す機能ブロック図である。 図1に示すゲートウェイの構成を示す機能ブロック図である。 図9に示すゲートウェイ−LN-HA間で送受されるGN-IPアドレス要求/応答メッセージのフォーマット例を示す図である。 図9に示すxSPサーバ−ゲートウェイ間で送受されるGN-IPアドレス要求/応答メッセージのフォーマット例を示す図である。 図1に示す連携情報管理システムのゲートウェイを含んだネットワーク動作を説明するための図である。 図1及び図6に示すゲートウェイの動作を説明するためのフローチャートである。 図6に示すゲートウェイの変形例を示す機能ブロック図である。 図4に示すGN-HAの変形例を示す機能ブロック図である。 図16に示すGN-HA−ゲートウェイ間で送受される連携情報登録/応答メッセージのフォーマット例を示す図である。 図16に示すゲートウェイ−LN-HA間で送受される連携情報登録/応答メッセージのフォーマット例を示す図である。 図16に示すxSPサーバ−LN-HA間で送受される連携情報検索/応答メッセージのフォーマット例を示す図である。 図9に示す連携情報管理システムのゲートウェイを含んだネットワーク動作の変形例を説明するための図である。 図16に示すネットワーク動作の変形例におけるゲートウェイの動作を説明するためのフローチャートである。 図1に示すLN-HAのオブジェクト共用機構に着目した構成を示す機能ブロック図である。 図18に示すLN-HAを含むオブジェクト共用ネットワーク動作(アプライアンスの登録)を説明するための図である。 図18に示すLN-HAとGNとの間で送受されるアプライアンス(LN)連携情報登録/応答メッセージのフォーマット例を示す図である。 図18に示すLN-HAを含むオブジェクト共用ネットワーク動作(アプライアンスの登録解除)を説明するための図である。 図18に示すLN-HAとGNとの間で送受されるアプライアンス(LN)連携情報解除/応答メッセージのフォーマット例を示す図である。 図18に示すLN-HAを含むオブジェクト共用ネットワーク動作(アプライアンス使用不可時)を説明するための図である。 図18に示すLN-HAとアプライアンスコントローラとの間で送受されるアプライアンス(LN)制御/応答メッセージのフォーマット例を示す図である。 図18に示すLN-HAを含むオブジェクト共用ネットワーク動作(アプライアンス使用不可時)を説明するためのフローチャートである。 図1に示すDNの構成を示す機能ブロック図である。 図1に示す連携情報管理システムにおけるDNを含むネットワーク動作を説明するための図である。 (A)は図1に示すLN-HAにおける連携情報テーブルの一例を示す図、(B)は図1に示すGN-HAにおける連携情報テーブルの一例を示す図、(C)は図1に示すLN-HA及びGN-HAにおける対応テーブルの一例を示す図である。 (A)は図28(A)に示す連携情報テーブルに対する連携情報削除動作を説明するための図、(B)は図28(B)に示す連携情報テーブルに対する連携情報削除動作を説明するための図、(C)は図28(C)に示す対応テーブルの連携情報削除動作時の内容を示す図である。 図1に示す連携情報管理システムにおけるDNを含むネットワーク動作の変形例を説明するための図である。 (A)は図1に示すLN及びDNの親子関係を示す図、(B1),(B2),(C1),(C2)及び(D)はいずれも(A)に示す親子関係を基にしたテーブル登録内容例を示す図である。 図30に示すLN-HAとxSPサーバとの間で送受される連携情報変更通知/応答メッセージのフォーマット例を示す図である。 図30に示すGN機能ノードとLN-HAとの間で送受される連携情報解除要求/応答メッセージのフォーマット例を示す図である。 (A)〜(C)は図30に示すLN-HAにおける連携情報解除時の動作を説明するための図である。 本実施形態の補足1(無線LAN利用)を説明するための図である。 本実施形態の補足2(無線LAN利用)を説明するための図である。 本実施形態の補足3(無線LAN利用)を説明するための図である。 本実施形態の補足4(ゲートウェイを含んだネットワーク動作)を説明するための図である。
符号の説明
1 連携管理機構(連携情報管理装置)
2 ゲートウェイ装置
21 LN-HAアドレスデータベース(DB)
22 IPアドレス対応データベース(DB)
23,26,23′,26′ IPデータ送受信機能部
24,24′ LN-ID抽出機能部
25 GN-IPアドレス取得機能部
27,27′ IPアドレス変換機能部
28 LN-HA通知機能部
3 ネットワーク(キャリアネットワーク)
4−1〜4−4 GN(Global Node)(第2の装置)
41 局所ネットワークインタフェース
42 LN情報収集部
43 LN情報抽出部
44 GN個別識別情報記憶部
45 広域位置登録機能部(位置制御プロトコルスタック)
46 広域ネットワークインタフェース
5−1〜5−5 LN(Local Node)(アプライアンス(オブジェクト);第1の装置)
5 LN群
51 個別識別情報記憶部
52 読み取り要求検出部
53 読み取り要求応答部
54 情報読み取りインタフェース
6,6−1,6−2 DN(Global-Local Dual function Node)(第3の装置)
61 GN機能部
62 LN機能部
7 xSPネットワーク
71 xSPサーバ(情報提供サーバ)
8 アプライアンスコントローラ
11 GN-HA
111 アクセス側ネットワークインタフェース
112 連携情報抽出部
113 広域位置登録機能部(位置制御プロトコルスタック)
114 GN位置(連携)情報データベース(DB)
115 LN-HA連携機能部
116 コア側ネットワークインタフェース
117 LN-HA−ゲートウェイアドレス対応データベース(DB)
12 LN-HA
121 アクセス側ネットワークインタフェース
122 LN位置(連携)情報登録メッセージ処理部
123 局所位置登録機能部(位置制御プロトコルスタック)
124 LN位置(連携)情報データベース(DB)
125 アプライアンス同時使用状態データベース(DB)
126 連携情報メッセージ送受信部
127 アプライアンス使用可/不可判定部
128 アプライアンス制御メッセージ送受信部
13,14 連携情報テーブル
15 対応テーブル
16,17 連携情報テーブル(LN-ID管理テーブル)
18 DNデータベース
31 ハブ
32−1,32−2,32−3 アクセスポイント(AP)
33 カバーエリア
34 IPアドレス管理サーバ

Claims (4)

  1. 第1の識別子を保有する第1の装置と、第2の識別子を保有するとともに該第1の識別子を該第1の装置から読み取って当該第1の識別子と該第2の識別子との組を連携情報として送信しうる第2の装置とをそなえたシステムに用いられ、該連携情報を管理する連携情報管理装置であって、
    該連携情報を受信する受信手段と、
    該連携情報を記憶する記憶手段と、
    該受信手段で受信した連携情報に含まれる第2の識別子と、当該連携情報に含まれる第1の識別子を含む複数の第1の識別子群とを関連付けて該記憶手段に登録する連携情報登録制御手段と
    複数の該第1の装置についての第1の識別子同士を予め関連付けた関連付けグループを保持する関連付けグループ保持手段とをそなえ、
    該連携情報登録制御手段が、
    該受信手段で受信した連携情報に含まれる該第1の識別子が属する関連付けグループを該関連付けグループ保持手段において検索する検索手段と、
    該検索手段により検索された関連付けグループと該受信手段で受信した連携情報に含まれる該第2の識別子とを関連付けて該記憶手段に登録する登録手段と、
    該検索手段により検索された関連付けグループに属する各識別子を該第2の装置に通知する通知手段と、をそなえたことを特徴とする、連携情報管理装置
  2. 該連携情報登録制御手段が、
    該第2の装置から特定の第1の識別子についての一部削除要求を受けると、当該第1の識別子を該記憶手段の連携情報から削除する連携情報一部削除手段をそなえたことを特徴とする、請求項記載の連携情報管理装置。
  3. 該連携情報登録制御手段が、
    該第2の装置から該関連付けグループについての全削除要求を受信すると、当該関連付けグループと該第2の識別子との関連付け情報である連携情報を該記憶手段から削除する連携情報全削除手段をそなえたことを特徴とする、請求項又はに記載の連携情報管理装置。
  4. 前記関連付けグループが、複数の該第1の装置についての第1の識別子同士の親子関係による階層的な関連付けグループであって
    検索手段が、
    該受信手段で受信した連携情報に含まれる該第1の識別子が上位階層の識別子として属する関連付けグループを該関連付けグループ保持手段において検索
    該登録手段が、
    該検索手段により検索された階層的な関連付けグループの該上位階層の識別子及び当該識別子と関連付けられた下位階層の識別子と、該受信手段で受信した連携情報に含まれる該第2の識別子とを関連付けて該記憶手段に登録
    該通知手段が、
    該検索手段により検索された関連付けグループに属する各識別子を該第2の装置に通知することを特徴とする、請求項1記載の連携情報管理装置
JP2003413568A 2003-12-11 2003-12-11 連携情報管理装置 Expired - Fee Related JP4264339B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2003413568A JP4264339B2 (ja) 2003-12-11 2003-12-11 連携情報管理装置
US10/871,909 US7577105B2 (en) 2003-12-11 2004-06-17 Cooperation information managing apparatus and gateway apparatus for use in cooperation information managing system
CNB2004100688018A CN100403834C (zh) 2003-12-11 2004-07-05 用于合作信息管理系统的合作信息管理设备及网关设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2003413568A JP4264339B2 (ja) 2003-12-11 2003-12-11 連携情報管理装置

Publications (2)

Publication Number Publication Date
JP2005175934A JP2005175934A (ja) 2005-06-30
JP4264339B2 true JP4264339B2 (ja) 2009-05-13

Family

ID=34650510

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003413568A Expired - Fee Related JP4264339B2 (ja) 2003-12-11 2003-12-11 連携情報管理装置

Country Status (3)

Country Link
US (1) US7577105B2 (ja)
JP (1) JP4264339B2 (ja)
CN (1) CN100403834C (ja)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8144671B2 (en) * 2005-07-01 2012-03-27 Twitchell Jr Robert W Communicating via nondeterministic and deterministic network routing
US7142107B2 (en) 2004-05-27 2006-11-28 Lawrence Kates Wireless sensor unit
US7990967B2 (en) 2005-01-06 2011-08-02 Rockwell Automation Technologies, Inc. Firewall method and apparatus for industrial systems
US7813511B2 (en) * 2005-07-01 2010-10-12 Cisco Technology, Inc. Facilitating mobility for a mobile station
JP4701132B2 (ja) 2005-12-07 2011-06-15 株式会社エヌ・ティ・ティ・ドコモ 通信経路設定システム
JP4820636B2 (ja) * 2005-12-07 2011-11-24 パナソニック株式会社 オブジェクト行動検知・通知システム及びコントローラ装置
KR20090044437A (ko) * 2007-10-31 2009-05-07 성균관대학교산학협력단 홈 네트워크 환경에서 이동 에이전트의 접근 제어 방법 및시스템
WO2009151877A2 (en) 2008-05-16 2009-12-17 Terahop Networks, Inc. Systems and apparatus for securing a container
JP5193797B2 (ja) * 2008-10-23 2013-05-08 Kddi株式会社 移動通信ネットワークシステム、ホームエージェント、アクセスゲートウェイ及び相手ノード
US8391435B2 (en) 2008-12-25 2013-03-05 Google Inc. Receiver state estimation in a duty cycled radio
US8028470B2 (en) 2009-04-21 2011-10-04 Deere & Company Robotic watering unit
US8437879B2 (en) 2009-04-21 2013-05-07 Deere & Company System and method for providing prescribed resources to plants
US8321365B2 (en) * 2009-04-21 2012-11-27 Deere & Company Horticultural knowledge base for managing yards and gardens
US9538714B2 (en) * 2009-04-21 2017-01-10 Deere & Company Managing resource prescriptions of botanical plants
US8938533B1 (en) * 2009-09-10 2015-01-20 AppDynamics Inc. Automatic capture of diagnostic data based on transaction behavior learning
US9167028B1 (en) 2009-09-10 2015-10-20 AppDynamics, Inc. Monitoring distributed web application transactions
US10230611B2 (en) * 2009-09-10 2019-03-12 Cisco Technology, Inc. Dynamic baseline determination for distributed business transaction
US8321061B2 (en) 2010-06-17 2012-11-27 Deere & Company System and method for irrigation using atmospheric water
US9076105B2 (en) 2010-08-20 2015-07-07 Deere & Company Automated plant problem resolution
US8504234B2 (en) 2010-08-20 2013-08-06 Deere & Company Robotic pesticide application
US9357759B2 (en) 2010-08-20 2016-06-07 Deere & Company Networked chemical dispersion system
JP2011004424A (ja) * 2010-09-06 2011-01-06 Panasonic Electric Works Co Ltd 制御システム、制御装置、及び制御装置用プログラム
US20140052833A1 (en) * 2011-03-11 2014-02-20 Nokia Siemens Networks Oy Network element configuration management
US9311598B1 (en) 2012-02-02 2016-04-12 AppDynamics, Inc. Automatic capture of detailed analysis information for web application outliers with very low overhead
JP2015023533A (ja) * 2013-07-23 2015-02-02 日本電気株式会社 通信システム

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3374638B2 (ja) * 1996-02-29 2003-02-10 株式会社日立製作所 システム管理/ネットワーク対応表示方法
SE510664C2 (sv) * 1996-10-29 1999-06-14 Ericsson Telefon Ab L M Metoder och anordning för meddelandehantering i ett kommunikationssystem
JPH10285162A (ja) * 1997-04-10 1998-10-23 Nippon Telegr & Teleph Corp <Ntt> グループ通信方法及びシステム
JP3494562B2 (ja) * 1997-10-15 2004-02-09 株式会社東芝 ネットワーク管理システム
KR100272567B1 (ko) * 1997-12-31 2000-11-15 서평원 이동통신 네트워크를 이용한 이동 인터넷
JP3782229B2 (ja) * 1998-03-13 2006-06-07 富士通株式会社 パス情報構築方法
SE513544C2 (sv) * 1998-06-17 2000-10-02 Ziad Ismail Anläggning och förfarande för att tillhandahålla en tjänst
JP2000059380A (ja) * 1998-08-07 2000-02-25 Toshiba Tec Corp 移動体データ通信システム
JP2000278290A (ja) * 1999-03-29 2000-10-06 Matsushita Electric Ind Co Ltd ネットワーク管理システム
JP2001169341A (ja) 1999-09-29 2001-06-22 Fujitsu Ltd 移動通信サービス提供システム、移動通信サービス提供方法、認証装置、およびホームエージェント装置
JP2001156775A (ja) * 1999-11-25 2001-06-08 Nippon Telegr & Teleph Corp <Ntt> グループ制御方法及びその装置並びにそのプログラムを記録した媒体
JP2001352341A (ja) * 2000-06-07 2001-12-21 Nec Corp パケット通信システム及びその方法
JP2002077185A (ja) * 2000-08-30 2002-03-15 Sony Corp 通信システムおよび方法
JP2002163722A (ja) * 2000-11-29 2002-06-07 Kojima Co Ltd 商品販売管理方法および装置ならびに携帯端末
US6600418B2 (en) * 2000-12-12 2003-07-29 3M Innovative Properties Company Object tracking and management system and method using radio-frequency identification tags
US6616047B2 (en) * 2001-03-31 2003-09-09 Koninklijke Philips Electronics N.V. Machine readable label reader system with robust context generation
JP2002344477A (ja) * 2001-05-16 2002-11-29 Mitsubishi Electric Corp マルチキャスト配信システム及びその端末用装置
US6944760B2 (en) * 2001-05-24 2005-09-13 Openwave Systems Inc. Method and apparatus for protecting identities of mobile devices on a wireless network
US7131141B1 (en) * 2001-07-27 2006-10-31 At&T Corp. Method and apparatus for securely connecting a plurality of trust-group networks, a protected resource network and an untrusted network
US20030043070A1 (en) * 2001-08-30 2003-03-06 Soliman Samir S. Wireless coordination and management system
JP2003134161A (ja) * 2001-10-25 2003-05-09 Sony Corp 情報配信システム及びそのアドレス配信サーバ並びに情報配信方法
JP3680783B2 (ja) * 2001-11-01 2005-08-10 ソニー株式会社 電子機器、通信システムおよび方法、情報処理端末および方法、情報処理装置および方法、並びにプログラム
JP2003209875A (ja) * 2002-01-15 2003-07-25 Iwatsu Electric Co Ltd 通信網における位置情報管理方法とシステム
GB0204686D0 (en) * 2002-02-28 2002-04-17 Koninkl Philips Electronics Nv Interactive system using tags
JP4373060B2 (ja) * 2002-08-14 2009-11-25 株式会社エヌ・ティ・ティ・ドコモ 分散処理システム並びに分散処理システムにおける代理ノード、利用者側ノードおよび方法
JP4046593B2 (ja) * 2002-10-25 2008-02-13 Necエレクトロニクス株式会社 ネットワーク制御方法
SE0203188D0 (sv) * 2002-10-29 2002-10-29 Ericsson Telefon Ab L M Automatic provisioning including mms greeting
AU2003297433A1 (en) * 2002-12-24 2004-07-22 Samrat Vasisht Method, system and device for automatically configuring a communications network
WO2004080008A1 (ja) * 2003-03-04 2004-09-16 Fujitsu Limited 連携情報管理システム
FI118619B (fi) * 2003-05-16 2008-01-15 Jarmo Talvitie Menetelmä ja järjestelmä tiedon salaamiseksi ja tallentamiseksi
JP3886934B2 (ja) * 2003-06-09 2007-02-28 株式会社東芝 無線通信装置、通信制御プログラム及び通信制御方法

Also Published As

Publication number Publication date
CN1627853A (zh) 2005-06-15
CN100403834C (zh) 2008-07-16
JP2005175934A (ja) 2005-06-30
US20050129034A1 (en) 2005-06-16
US7577105B2 (en) 2009-08-18

Similar Documents

Publication Publication Date Title
JP4264339B2 (ja) 連携情報管理装置
CN1316796C (zh) 短程无线网络环境中位置独立信息包路由选择和安全访问
Albrecht et al. IP services over Bluetooth: leading the way to a new mobility
JP3639200B2 (ja) 通信システム、移動端末装置、ゲートウェイ装置、アドレス割り当て方法及び検索サービス方法
CN100428719C (zh) 一种基于身份与位置分离的互联网接入方法
CN1726689B (zh) 用于移动ip的代理间通信协议
EP2003862A2 (en) Access, connectivity and interoperability for devices and services
KR101370270B1 (ko) 사용자 지향 통신 방법, 라우트 등록 방법 및 장치 및 통신 시스템
CN101513019A (zh) 通信网络中的定位器解析
JP3538527B2 (ja) 無線通信システムおよび無線通信方法
JP4682329B2 (ja) 通信ネットワークにおけるネームシステム及びネーミング方法
CN102739809A (zh) DNS64数据库、服务器、系统和IPv4/IPv6通信方法
JP4339379B2 (ja) プレゼンス情報管理方法及びプレゼンス情報管理システム
KR101899802B1 (ko) 미래 인터넷 환경에서의 통합 식별 체계 구축장치 및 그 방법
Chtcherbina et al. Peer-to-peer coordination framework (p2pc): Enabler of mobile ad-hoc networking for medicine, business, and entertainment
JP3464358B2 (ja) 通信制御方法、中継装置およびデータパケット処理装置
Li et al. Supporting personal mobility for nomadic computing over the internet
JP2011071870A (ja) 通信装置、通信システムおよび通信方法
Jacobsson et al. A network architecture for personal networks
Jacobsson et al. A network layer architecture for personal networks
KR20020000887A (ko) 다중 트리 계층적 통신 시스템 및 방법
JP3875051B2 (ja) 通信システム、通信方法及び通信制御装置
Demir et al. The Design and Implementation of an Information Centric Networking Architecture in Contiki NG OS
Ramanathan Mobility support for Nimrod: Challenges and solution approaches
Weatherall et al. Predator: A distributed location service and example applications

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060223

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20080129

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080826

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20081014

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090203

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090216

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120220

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130220

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140220

Year of fee payment: 5

LAPS Cancellation because of no payment of annual fees