(57)【特許請求の範囲】
【請求項１】
複数のノードがネットワークで接続されて構成され、
前記複数のノードのうちの第１ノードが、端末からのオブジェクトを取得するための要求メッセージを受信し、
前記第１ノードから名前解決を行う前記複数のノードのうちの第２ノードまでの各ノードが、オブジェクトの識別子である階層化されたオブジェクトＩＤとルーティング情報とを用いて前記要求メッセージのルーティングを行い、
前記第２ノードが、名前解決情報を参照して、前記要求メッセージの前記オブジェクトＩＤからオブジェクトを保持する前記複数のノードのうちの第３ノードのロケーションＩＤへの変換を行い、
前記第２ノードから前記第３ノードまでの各ノードが、変換された前記ロケーションＩＤを用いて、前記要求メッセージのルーティングを行い、
前記第３ノードが、自身にてオブジェクトを取得し、
前記第３ノードから前記第１ノードまでの各ノードが、取得したオブジェクトを含む返送メッセージのルーティングを行うことで、前記端末が前記要求メッセージで要求したオブジェクトを、前記第１ノードから取得することを特徴とする
データ指向型通信システム。
【請求項２】
前記返送メッセージのルーティングを行う各ノードが、前記返送メッセージに含まれる前記オブジェクトＩＤの前記ルーティング情報を自身に記憶し、その記憶された前記ルーティング情報を用いて前記オブジェクトＩＤのルーティングを実行することを特徴とする
請求の範囲第１項に記載のデータ指向型通信システム。
【請求項３】
前記返送メッセージのルーティングを行う各ノードが、前記要求メッセージに含まれる経路情報に基づいて前記要求メッセージが経由するノードを識別し、経由するノードのうち経路を縮小できる短縮経路のノードを選択し、前記短縮経路のノードを前記ルーティング情報として自身に記憶することを特徴とする
請求の範囲第１項に記載のデータ指向型通信システム。
【請求項４】
前記第１ノードから前記第２ノードまでの各ノードは、オブジェクトの登録するための登録メッセージをルーティングするとともに、その前記登録メッセージの前記オブジェクトＩＤの前記ルーティング情報を自身に記憶し、
前記第２ノードは、前記登録メッセージの前記オブジェクトＩＤと、そのオブジェクトが登録されたノードの前記ロケーションＩＤとを前記名前解決情報として自身に記憶することを特徴とする
請求の範囲第１項に記載のデータ指向型通信システム。
【請求項５】
前記第２ノードは、新たな前記登録メッセージによる前記名前解決情報を自身に記憶する処理において、前記新たな登録メッセージに基づく前記名前解決情報の前記オブジェクトＩＤと、過去の前記登録メッセージに基づく前記名前解決情報の前記オブジェクトＩＤとが一致するときには、前記過去の登録メッセージの前記オブジェクトＩＤを含めて、前記過去の登録メッセージによって記憶された前記ルーティング情報を修正するための修正メッセージを発行し、
前記修正メッセージを受信した前記過去の登録メッセージの経路上の各ノードは、自身に記憶されている前記ルーティング情報のうちの、前記名前解決情報の前記オブジェクトＩＤが前記修正メッセージの前記オブジェクトＩＤと一致するエントリを修正することを特徴とする
請求の範囲第４項に記載のデータ指向型通信システム。
【請求項６】
前記第２ノードは、前記修正メッセージを送信した後に、その修正メッセージへのＡＣＫを受信した後に、前記送信した修正メッセージとは別の新たな修正メッセージを送信することを特徴とする
請求の範囲第５項に記載のデータ指向型通信システム。
【請求項７】
前記第２ノードは、前記修正メッセージを送信した後に、前記修正メッセージへのＡＣＫの受信に失敗したときは、前記登録メッセージへのＡＣＫとして、前記オブジェクトの登録失敗を通知することを特徴とする
請求の範囲第５項に記載のデータ指向型通信システム。
【請求項８】
前記修正メッセージを受信した前記過去の登録メッセージの経路上の各ノードは、前記オブジェクトＩＤが一致するエントリを、自身に格納されている前記ルーティング情報から削除する旨の修正処理を実行することを特徴とする
請求の範囲第５項ないし第７項のいずれか１項に記載のデータ指向型通信システム。
【請求項９】
前記修正メッセージを受信した前記過去の登録メッセージの経路上の各ノードは、前記オブジェクトＩＤが一致するエントリについて、自身に格納されている前記ルーティング情報の次ホップを、前記新たな登録メッセージにより前記名前解決情報を記憶した前記第２ノードへ向かうためのノードに更新する旨の修正処理を実行することを特徴とする
請求の範囲第５項ないし第７項のいずれか１項に記載のデータ指向型通信システム。
【請求項１０】
各ノードが接続されて形成されるデータ指向型ネットワークにおいて、そのノード内に格納されるオブジェクトにアクセスするためのデータ指向型通信システムに用いられ、
前記各ノードの記憶手段には、
前記オブジェクトを識別するためのオブジェクトＩＤと、所定のノードへ向かう次ホップの前記ノードとを対応づけるオブジェクトＩＤ転送テーブルと、
転送先の前記ノードを示すロケーションＩＤと、その転送先の前記ノードへ向かう次ホップの前記ノードとを対応づけるロケーションＩＤ転送テーブルと、がそれぞれ記憶されており、
前記所定のノードは、前記オブジェクトＩＤから、そのオブジェクトが格納される前記ノードを示す前記ロケーションＩＤへの名前解決を実行する前記ノードであり、
前記オブジェクトＩＤが指定されており、そのオブジェクトを取得するためのオブジェクト要求メッセージを受信した前記ノードは、
前記オブジェクト要求メッセージに転送先の前記ロケーションＩＤが含まれているときには、その転送先の前記ロケーションＩＤを検索キーとして、自身の前記ロケーションＩＤ転送テーブルを検索し、得られた次ホップの前記ノードへと前記オブジェクト要求メッセージを転送し、
前記オブジェクト要求メッセージに転送先の前記ロケーションＩＤが含まれていないときには、前記オブジェクト要求メッセージに含まれる前記オブジェクトＩＤを検索キーとして、自身の前記オブジェクトＩＤ転送テーブルを検索し、
検索結果として自身が前記所定のノードであるときには、前記オブジェクトＩＤから、そのオブジェクトが格納される前記ノードを示す前記ロケーションＩＤへの名前解決を実行し、得られた前記ロケーションＩＤを前記オブジェクト要求メッセージに付加し、
検索結果として次ホップである他装置の前記ノードが存在するときには、その他装置の前記ノードへと前記オブジェクト要求メッセージを転送することを特徴とする
ノード。
【請求項１１】
前記オブジェクト要求メッセージを受信した前記ノードのうちの、前記オブジェクト要求メッセージに含まれる転送先の前記ロケーションＩＤが自身である前記ノードは、自身の前記記憶手段から前記オブジェクト要求メッセージで指定された前記オブジェクトを読み込み、そのオブジェクトを含むオブジェクト返送メッセージを作成し、前記オブジェクト要求メッセージの送信元に向けて返送し、
前記オブジェクト返送メッセージを受信した前記各ノードは、受信した前記オブジェクト返送メッセージを前記オブジェクト要求メッセージの送信元に向けて転送するとともに、前記オブジェクト返送メッセージに含まれる前記オブジェクトの前記オブジェクトＩＤと、前記オブジェクト返送メッセージの受信元である前記ノードを次ホップとして対応づけて、前記オブジェクトＩＤ転送テーブルにエントリ追加することを特徴とする
請求の範囲第１０項に記載のノード。
【請求項１２】
前記オブジェクト返送メッセージを受信した前記各ノードは、前記オブジェクトＩＤ転送テーブルにエントリ追加する処理において、対応づける次ホップの前記ノードとして、前記オブジェクト返送メッセージの受信元の代わりに、そのオブジェクト返送メッセージの受信元よりも前記所定のノードに近い前記ノードであり、かつ、自身から直接接続されている前記ノードを、対応づける次ホップの前記ノードとすることを特徴とする
請求の範囲第１１項に記載のノード。
【請求項１３】
前記オブジェクト要求メッセージにより要求される前記オブジェクトを、前記ノード内に格納するためのオブジェクト登録メッセージを受信した前記各ノードは、
前記オブジェクト登録メッセージを前記所定のノードへ向かう次ホップの前記ノードへと転送するとともに、前記オブジェクト登録メッセージで登録対象となる前記オブジェクトの前記オブジェクトＩＤと、前記オブジェクト登録メッセージの転送先である次ホップとを対応づけて、自身の前記オブジェクトＩＤ転送テーブルに新規エントリとして追加することを特徴とする
請求の範囲第１０項ないし第１２項のいずれか１項に記載のノード。
【請求項１４】
各ノードが接続されて形成されるデータ指向型ネットワークにおいて、そのノード内に格納されるオブジェクトにアクセスするためのデータ指向型通信システムにより実行され、
前記各ノードの記憶手段には、
前記オブジェクトを識別するためのオブジェクトＩＤと、所定のノードへ向かう次ホップの前記ノードとを対応づけるオブジェクトＩＤ転送テーブルと、
転送先の前記ノードを示すロケーションＩＤと、その転送先の前記ノードへ向かう次ホップの前記ノードとを対応づけるロケーションＩＤ転送テーブルと、がそれぞれ記憶されており、
前記所定のノードは、前記オブジェクトＩＤから、そのオブジェクトが格納される前記ノードを示す前記ロケーションＩＤへの名前解決を実行する前記ノードであり、
前記オブジェクトＩＤが指定されており、そのオブジェクトを取得するためのオブジェクト要求メッセージを受信した前記ノードは、
前記オブジェクト要求メッセージに転送先の前記ロケーションＩＤが含まれているときには、その転送先の前記ロケーションＩＤを検索キーとして、自身の前記ロケーションＩＤ転送テーブルを検索し、得られた次ホップの前記ノードへと前記オブジェクト要求メッセージを転送し、
前記オブジェクト要求メッセージに転送先の前記ロケーションＩＤが含まれていないときには、前記オブジェクト要求メッセージに含まれる前記オブジェクトＩＤを検索キーとして、自身の前記オブジェクトＩＤ転送テーブルを検索し、
検索結果として自身が前記所定のノードであるときには、前記オブジェクトＩＤから、そのオブジェクトが格納される前記ノードを示す前記ロケーションＩＤへの名前解決を実行し、得られた前記ロケーションＩＤを前記オブジェクト要求メッセージに付加し、
検索結果として次ホップである他装置の前記ノードが存在するときには、その他装置の前記ノードへと前記オブジェクト要求メッセージを転送することを特徴とする
データ転送方法。
【発明の詳細な説明】
【参照による取り込み】
【０００１】
本出願は、２０１２年１月５日に出願された日本特許願第２０１２−５９０号の優先権、および、２０１２年７月１９日に出願された日本特許願第２０１２−１６０１０４号の優先権を主張し、その内容を参照することにより本出願に取り込む。
【技術分野】
【０００２】
本発明は、データ指向型通信システム、ノード、および、データ転送方法に関する。
【背景技術】
【０００３】
ＩＰ（Internet Protocol）ネットワークでは、ネットワーク上の位置（location）を示す識別子であるＩＰアドレスを用いて通信を行うノードの位置を特定する。そのＩＰアドレスを特定するための手がかりとして、所望のデータのＵＲＩ（Uniform Resource Identifier）から抽出されたホストＩＤ（Host Name）などが存在する。【０００４】
ＤＮＳ（Domain Name System）は、ホストＩＤを検索キーとして、そのホストＩＤが示す位置ＩＤを特定するための名前解決サービスである。よって、端末は、ＤＮＳから通知されたＩＰアドレスを用いて、宛先のノードに対して通信を行う。【０００５】
データ指向型ネットワーク（ＤＣＮ：Data-centric Network）とは、データＩＤ（オブジェクトＩＤ）を用いて所望のオブジェクトまで、データ要求をルーティングするためのネットワークである。
ここでいうオブジェクトとは、映像データ、音楽データなどのマルチメディア形式のファイルから、Webページに代表されるテキストデータ、更にはセンサデータや機器状態の監視データなどのMachine-to-Machine（Ｍ２Ｍ）通信向けデータなど、ネットワークを経由してアクセスできるあらゆるデータを意味する。データＩＤ（オブジェクトＩＤ）はそのオブジェクトを示す識別子を意味する。【０００６】
従来のＩＰネットワークでは、前記のようにネットワーク上の位置を示す識別子であるＩＰアドレスを用いてルーティングを行うが、データ指向型ネットワークではデータＩＤを用いてルーティングする。ＩＰアドレスはオブジェクトの位置が変わるごとに変化するが、データＩＤはオブジェクトの位置に依存しない。【０００７】
ＩＰネットワークはＤＮＳなどの名前解決サービスを利用してＵＲＩやホストＩＤからＩＰアドレスを特定した後にルーティングを行う必要があるが、データ指向型ネットワークではデータＩＤを指定すれば適切なオブジェクト（またはその複製）にルーティングが行われる。このため、データ指向型ネットワークはオブジェクトが移動したり、ネットワーク内にオブジェクトの複製が分散して配置される場合に、ＩＰネットワークより効率的に通信ができる。【０００８】
非特許文献１には、オブジェクトＩＤを位置ＩＤへマッピングするためのサービス（ＧＮＲＳ:Global Name Resolution Service）にアクセスする方式が、記載されている。
非特許文献２には、階層型ＤＨＴ（Distributed Hash Table）によってホストＩＤから位置ＩＤへの変換を行う方式が、記載されている。【０００９】
一方、名前解決をせずに、データＩＤそのものを位置ＩＤとみなして通信を行う方式も提案されている。特許文献１では、データＩＤを用いたルーティング機能をネットワークが持つことで、位置ＩＤを用いずに所望のオブジェクトを取得するネットワーク方式が述べられている。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００９−２７８６２４号公報
【非特許文献】
【００１１】
【非特許文献１】Samuel C. Nelson, Gautam Bhanage, Dipankar Raychaudhuri, GSTAR: Generalized Storage-Aware Routing for MobilityFirst in the Future Mobile Internet, MobiArch’11, June 28, 2011.
【非特許文献２】Matteo D’Ambrosio, et al., D-6.2 Second NetInf Architecture Description, The FP7 4WARD Project, January 14, 2010.
【発明の概要】
【発明が解決しようとする課題】
【００１２】
一方、データを保持する端末やデータ自身が頻繁に移動する場合も多い。例えば、センサや機器が無線アクセスを経由してネットワークに接続されて様々な情報を発信し、それらの情報をネットワークに接続された他の端末が取得・活用する場合がある。また、Ｗｅｂサーバなど端末がアクセスするホストも、サーバの仮想化技術などによって遠隔の場所に移動する場合もある。【００１３】
このように、名前解決の手がかり情報（ホストＩＤやデータＩＤなど）が変わらなくても、名前解決の結果である位置ＩＤが時間経過により更新されると、ある時点での１回の名前解決を行って得た位置ＩＤを使用できる期間が短期間になってしまう。
しかし、データの位置が時間経過により更新され続ける状況で、効率的にデータ通信を行う手法は、提案されていない。【００１４】
まず、非特許文献１や非特許文献２などの名前解決サービスを提供する方式では、名前解決をしてからデータ通信を開始するため、位置ＩＤが更新される状況下では、毎回前準備として名前解決を行う必要があり、データ通信を開始するまで待たされてしまう。【００１５】
次に、特許文献１に記載されたデータＩＤそのものを位置ＩＤとみなす方式では、たしかに、名前解決を行う前準備は不要になり、データ通信の開始時期は早まるものの、送信元から宛先への経路に位置する各ノードは、それぞれ宛先へ向かうための次ホップを示す転送テーブルのエントリを、データＩＤごとに用意する必要がある。よって、転送テーブルのエントリ数が膨大になってしまい、その転送テーブルの検索時間や更新時間がボトルネックとなり、データ通信性能が低下してしまう。【００１６】
そこで、本発明は、前記した問題を解決し、データの位置が時間経過により更新され続ける状況で、効率的にデータ通信を行うことを、主な目的とする。
【課題を解決するための手段】
【００１７】
前記課題を解決するために、本発明は、複数のノードがネットワークで接続されて構成されるデータ指向型通信システムであって、
前記複数のノードのうちの第１ノードが、端末からのオブジェクトを取得するための要求メッセージを受信し、
前記第１ノードから名前解決を行う前記複数のノードのうちの第２ノードまでの各ノードが、階層化されたオブジェクトＩＤとルーティング情報とを用いて前記要求メッセージのルーティングを行い、
前記第２ノードが、名前解決情報を参照して、前記要求メッセージの前記オブジェクトＩＤからオブジェクトを保持する前記複数のノードのうちの第３ノードのロケーションＩＤへの変換を行い、
前記第２ノードから前記第３ノードまでの各ノードが、変換された前記ロケーションＩＤを用いて、前記要求メッセージのルーティングを行い、
前記第３ノードが、自身にてオブジェクトを取得し、
前記第３ノードから前記第１ノードまでの各ノードが、取得したオブジェクトを含む返送メッセージのルーティングを行うことで、前記端末が前記要求メッセージで要求したオブジェクトを、前記第１ノードから取得することを特徴とする。
その他の手段は、後記する。
【発明の効果】
【００１８】
本発明によれば、データの位置が時間経過により更新され続ける状況で、効率的にデータ通信を行うことができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の一実施形態に関するデータ指向型通信システムを示す構成図である。
【図２】本発明の一実施形態に関するデータ指向型通信システム上に流れるメッセージのフォーマットを示す説明図である。
【図３】本発明の一実施形態に関するデータ指向型通信システムの各ノードを示す構成図である。
【図４】本発明の一実施形態に関するオブジェクト要求メッセージの送信処理（下位から上位へ）を示すフローチャートである。
【図５】本発明の一実施形態に関するオブジェクト要求メッセージの送信処理（上位から下位へ）を示すフローチャートである。
【図６】本発明の一実施形態に関するオブジェクト要求メッセージの各ノードにおける処理を示すフローチャートである。
【図７】本発明の一実施形態に関するオブジェクト要求メッセージの各テーブルにおける処理を示す説明図である。
【図８】本発明の一実施形態に関するオブジェクト返送メッセージの送信処理（下位から上位へ）を示すフローチャートである。
【図９】本発明の一実施形態に関するオブジェクト返送メッセージの送信処理（上位から下位へ）を示すフローチャートである。
【図１０】本発明の一実施形態に関するオブジェクト返送メッセージの各ノードにおける処理を示すフローチャートである。
【図１１】本発明の一実施形態に関するオブジェクト返送メッセージの各テーブルにおける処理を示す説明図である。
【図１２】本発明の一実施形態に関するデータ指向型通信システムを示す構成図である。
【図１３】本発明の一実施形態に関するオブジェクト登録メッセージの送信処理（下位から上位へ）を示すフローチャートである。
【図１４】本発明の一実施形態に関するオブジェクト登録メッセージの送信処理（上位から下位へ）を示すフローチャートである。
【図１５】本発明の一実施形態に関するオブジェクト登録メッセージの各ノードにおける処理を示すフローチャートである。
【図１６】本発明の一実施形態に関するオブジェクト登録メッセージの各テーブルにおける処理を示す説明図である。
【図１７】本発明の一実施形態に関するオブジェクト要求メッセージの各ノードにおける処理の別形態を示すフローチャートである。
【図１８】本発明の一実施形態に関するデータ指向型通信システム（２つのデータ位置の説明用）を示す構成図である。
【図１９】本発明の一実施形態に関する図１８のシステムにおける旧位置のオブジェクト登録を示す構成図である。
【図２０】本発明の一実施形態に関する図１８のシステムにおける新位置のオブジェクト登録を示す構成図である。
【図２１】本発明の一実施形態に関する図１８のシステムにおける２つの位置のオブジェクト要求を示す構成図である。
【図２２】本発明の一実施形態に関する図２１の新位置のオブジェクト要求処理を示すフローチャートである。
【図２３】本発明の一実施形態に関する図２１の新位置のオブジェクト返送処理を示すフローチャートである。
【図２４】本発明の一実施形態に関する図２１の旧位置のオブジェクト要求処理を示すフローチャートである。
【図２５】本発明の一実施形態に関する図２１の旧位置のオブジェクト返送処理を示すフローチャートである。
【図２６】本発明の一実施形態に関する図２０のオブジェクト登録後の経路修正を示す構成図である。
【図２７】本発明の一実施形態に関する図２６の経路修正処理を示すフローチャートである。
【図２８】本発明の一実施形態に関する図２６の経路修正処理における名前解決ノードの処理を示すフローチャートである。
【図２９】本発明の一実施形態に関する図２６の経路修正後のオブジェクト要求を示す構成図である。
【図３０】本発明の一実施形態に関する図１８のシステムにおける図２６とは別の経路修正を示す構成図である。
【図３１】本発明の一実施形態に関する図１８のシステムにおける図２６とは別の経路修正を示す構成図である。
【発明を実施するための形態】
【００２０】
以下、本発明の一実施形態を、図面を参照して詳細に説明する。
【００２１】
図１は、データ指向型通信システムを示す構成図である。データ指向型通信システムに用いられるデータ指向型ネットワーク（ＤＣＮ：Data-centric Network）とは、オブジェクトＩＤ（以下「ｏｉｄ」と略す）を用いて所望のオブジェクトまで、そのオブジェクトへのアクセスを転送するためのネットワークである。そのため、データ指向型通信システムでは、複数のノード１（１ａ〜１ｇ）上にオブジェクトの位置情報が分散して管理されている。
ここで、ｏｉｄと他のｉｄ（ノードＩＤを示すｎｉｄ，ロケーションＩＤを示すｌｉｄなど）とは、別々のＩＤ空間であり、別々のデータである。ｏｉｄの階層表現については、後記する。
なお、特許請求の範囲では、ノード１ａを第１ノードとし、ノード１ｆを第２ノードとし、ノード１ｇを第３ノードとする。
【００２２】
データ指向型通信システムの各装置は、それぞれＣＰＵ（Central Processing Unit）とメモリとハードディスク（記憶手段）とネットワークインタフェースを有するコンピュータとして構成され、このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラムを実行することにより、各処理部を動作させる。
【００２３】
データ指向型通信システムは、各ノード１と、ノード１ａに収容される端末２ａと、ノード１ｇに収容される端末２ｂとがネットワークで接続されて構成される。各端末２（２ａ，２ｂ）は、ノード１に対してオブジェクト９へのアクセスを指示する。オブジェクト９へのアクセスを指示するためのメッセージとして、以下の３種類が挙げられる。
・オブジェクト要求メッセージは、端末２がオブジェクト９の内容をノード１から読み込むための要求を示すメッセージパケットである。
・オブジェクト返送メッセージは、オブジェクト要求メッセージへの返答として、オブジェクト９の内容を含んだメッセージであり、オブジェクト要求メッセージの送信元である端末２に対して返送される。
・オブジェクト登録メッセージは、端末２がオブジェクト９の内容をノード１へ書き込むための要求を示すメッセージパケットである（図１２以降で説明）。
【００２４】
各ノード１には、ノードＩＤ（ｎｉｄ）が付与されている。以下、本実施形態では、ノード１の符号末尾（例えば、ノード１ａの「ａ」）を、ノードＩＤの「ａ」と同じにしている。
ここで、ｎｉｄと他のｉｄ（ｏｉｄ，ｌｉｄなど）とは、別々のＩＤ空間であり、別々のデータである。
ノード１は、ノード１ｄを頂点とした階層型のトポロジで接続されており、図１では、上側が上位ノードで下側が下位ノードである。例えば、ノード１ｄは、ノード１ｃおよびノード１ｅの親（上位ノード）である。ノード１ｃ，１ｅは、それぞれノード１ｂ，１ｆの上位ノードである。ノード１ｂ，１ｆは、それぞれノード１ａ，１ｇの上位ノードである。
【００２５】
ノード１の階層構造をデータ指向型通信システムに反映させるために、図３で後記する転送テーブル（オブジェクトＩＤ転送テーブル１１、ロケーションＩＤ転送テーブル１３）において、転送先が発見できなかったときのデフォルトの転送先（次ホップ）として、自身のノード１からみた上位ノードが設定される。
【００２６】
ノード１は、端末２ａからのオブジェクト要求メッセージを以下の（手順１）〜（手順３）の順に扱う。
（手順１）各ノード１（１ａ→１ｂ→１ｃ→１ｄ→１ｅ→１ｆ）は、オブジェクト要求メッセージ内の宛先に指定されたオブジェクトＩＤを用いて、次ホップのノード１へとオブジェクト要求メッセージを転送する。このように、オブジェクトＩＤを用いた転送を「ｏｉｄ転送」とし、図１では実線矢印でその転送経路を示す。
（手順２）名前解決を行うノード１ｆは、オブジェクトＩＤ（＝ａ．ｂ．ｃ）からオブジェクトを保持するノード１ｇの位置ＩＤ（ロケーションＩＤ、以下「ｌｉｄ」と略す）への変換（＝ｄ．ｅ．ｆ．ｇ）を行う。
ここで、ｌｉｄと他のｉｄ（ｎｉｄ，ｏｉｄなど）とは、別々のＩＤ空間であり、別々のデータである。
ｌｉｄはＩＰアドレスのような既存のＩＤや、ＩＰアドレスとは異なるデータ指向型ネットワークに特有なＩＤを含む。データ指向型ネットワークに特有のｌｉｄの階層表現の例については、後記する。
そして、ノード１ｆは、オブジェクト要求メッセージの宛先である位置ＩＤ（＝ｄ．ｅ．ｆ．ｇ）を用いて、次ホップのノード１ｇへとオブジェクト要求メッセージを転送する。このように、位置ＩＤを用いた転送を「ｌｉｄ転送」とし、図１では破線矢印でその転送経路を示す。
（手順３）ノード１ｇは、自身の記憶手段からオブジェクト要求メッセージで指定されたオブジェクト９を取得する。
【００２７】
ノード１は、端末２ａへのオブジェクト返送メッセージを以下の（手順４）〜（手順６）の順に扱う。
（手順４）ノード１ｇは、オブジェクト要求メッセージで指定されたオブジェクト９を含むオブジェクト返送メッセージを作成する。このオブジェクト返送メッセージの宛先は、オブジェクト要求メッセージの送信元の端末２ａである。そして、ノード１ｇは、オブジェクト返送メッセージの宛先である端末２ａの位置ＩＤを用いて、次ホップのノード１ｆへとオブジェクト返送メッセージを転送する。
（手順５）各ノード１（１ｆ→１ｅ→１ｃ→１ｂ→１ａ）は、受信したオブジェクト返送メッセージの宛先である端末２ａの位置ＩＤを用いて、次ホップの各ノード１へとオブジェクト返送メッセージを転送する。ここで、各ノード１は、オブジェクト返送メッセージの転送処理に併せて、オブジェクト返送メッセージのオブジェクトＩＤ（＝ａ．ｂ．ｃ）の転送先（例えば、ノード１ａからみた転送先であるノード１ｂ）を、自身の転送テーブルへと記憶する。
（手順６）端末２ａは、ノード１ａからオブジェクト返送メッセージを受信することで、（手順１）のオブジェクト要求メッセージに係わるオブジェクト９を取得することができる。
【００２８】
図２は、データ指向型通信システム上に流れるメッセージのフォーマットを示す説明図である。メッセージヘッダ６０１にはノードがメッセージを転送する際に参照するための情報が記録されている。ペイロード６０２にはオブジェクトのデータが記録されている。
【００２９】
メッセージヘッダ６０１は、以下の通りである。
１行目の「message_type」は、メッセージの種類として、オブジェクト要求メッセージを示す「retrieve」、オブジェクト返送メッセージを示す「return」、および、オブジェクト登録メッセージを示す「register」のいずれかが格納される。
【００３０】
２，３行目の「req」から始まる行は、メッセージの要求先（宛先）を示す。「req_oid」は宛先のオブジェクトＩＤを示し、「req_lid」は宛先の位置ＩＤを示す。
ここで、「req_lid」が「null(値なし)」であるとは、ノード１ｆにより名前解決が行われる前の状態を示すので、「req_oid」を検索キーとするｏｉｄ転送が各ノード１により行われる。一方、「req_lid」に値が代入されているときには、名前解決が行われた後の状態を示すので、「req_lid」を検索キーとするｌｉｄ転送が各ノード１により行われる。
【００３１】
４，５行目の「src」から始まる行は、メッセージの送信元を示す。
６行目の「route_info_nid」は、自身のメッセージが通過したノード１の順序を示す。図２では、各ノード１（１ａ→１ｂ→１ｃ→１ｄ→１ｅ→１ｆ）を順に通過している。
【００３２】
メッセージを作成するノード１または端末２は、メッセージヘッダ６０１の１，２，４，５行目を付与する。名前解決するノード１ｆは、メッセージヘッダ６０１の３行目を付与する。各ノード１は、メッセージヘッダ６０１の６行目に、自身のノードＩＤを追加する。
【００３３】
ここで、ｏｉｄおよびｌｉｄの階層表現について、説明する。ｏｉｄ（＝ａ．ｂ．ｃなど）や、ｌｉｄ（＝ｄ．ｅ．ｆ．ｇ）は、複数の要素（例えば、ｏｉｄではａ，ｂ，ｃ）が先頭から順に「．」を区切りとして接続されている。このような「．」を区切りとする階層表現では、先頭（左）にいくほど上位の階層を示し、末尾（右）にいくほど下位の階層を示す。そして、階層表現のエントリでの一致判定処理では、以下のいずれかの結果を得る。
【００３４】
一致しない場合：検索キー「ａ．ｂ．ｃ」と、検索対象「ｄ．ｅ．ｆ」とでは、最先頭のエントリ「ａとｄ」の時点で不一致である。よって、検索キーと検索対象とでは、データ内容が共通する部分が存在しないため、不一致（ヒットしない）となる。
【００３５】
部分一致する場合：検索キー「ａ．ｂ．ｃ」と、検索対象「ａ．ｂ」とでは、先頭からの部分「ａ．ｂ」は一致するが、末尾の「ｃ」は不一致である。このように、検索キー「ａ．ｂ．ｃ」の先頭から抽出した一部「ａ．ｂ」と、検索対象「ａ．ｂ」とが一致するときに、部分一致する（ヒットする）と表現する。なお、階層表現「ａ．ｂ．ｃ」のうちの先頭から抽出した一部「ａ．ｂ」のことを、以下では「プレフィックス」と呼ぶ。
【００３６】
完全一致する場合：検索キー「ａ．ｂ．ｃ」と、検索対象「ａ．ｂ．ｃ」とでは、先頭から末尾まで一致する。このような場合を完全一致する（ヒットする）と呼ぶ。
【００３７】
なお、検索キー「ａ．ｂ．ｃ」に対して、第１検索対象「ａ」、第２検索対象「ａ．ｂ」、第３検索対象「ａ．ｂ．ｃ」が同じ転送テーブルに存在するときには、検索キー「ａ．ｂ．ｃ」に対する一致箇所が多い検索対象を、優先的にヒットさせる（いわゆる「最長一致ルール」）。この例では、検索キー「ａ．ｂ．ｃ」の検索結果は、第３検索対象の完全一致が最優先され、次に第２検索対象の部分一致、最後に第１検索対象の部分一致となる。
【００３８】
図３は、データ指向型通信システムの各ノードを示す構成図である。ノード１は、制御データ記憶部１０と、データ転送部２０と、データ記憶部３０と、ネットワーク５０に接続するための通信ＩＦ４０と、制御処理部６０とを有する。なお、端末２も、図３に示すノード１の各構成要素（ノード管理部６１など）を有していてもよい。
【００３９】
制御データ記憶部１０は、オブジェクトＩＤ転送テーブル１１と、名前解決テーブル１２と、ロケーションＩＤ転送テーブル１３と、格納データテーブル１４とを有する。これらの各テーブルの詳細は、図７で後記する。
データ転送部２０は、データ送受信部２１を有する。データ送受信部２１は、各メッセージの送受信を制御する。
データ記憶部３０は、データ格納部３１を有する。データ格納部３１は、オブジェクト９を格納する。例えば、図１では、ノード１ｇがオブジェクト９を格納する。
通信ＩＦ４０は、ノード１内の各構成要素と、他装置に接続するためのネットワーク５０とを仲介するインタフェースである。
【００４０】
制御処理部６０は、ノード管理部６１と、オブジェクトＩＤ転送テーブル作成部６２と、オブジェクトＩＤ転送テーブル検索部６３と、ロケーションＩＤ転送テーブル作成部６４と、ロケーションＩＤ転送テーブル検索部６５と、名前解決テーブル作成部６６と、名前解決テーブル検索部６７と、格納データテーブル検索部６８とを有する。
【００４１】
オブジェクトＩＤ転送テーブル作成部６２およびオブジェクトＩＤ転送テーブル検索部６３は、オブジェクトＩＤ転送テーブル１１の作成および検索を行う。
ロケーションＩＤ転送テーブル作成部６４およびロケーションＩＤ転送テーブル検索部６５は、ロケーションＩＤ転送テーブル１３の作成および検索を行う。
名前解決テーブル作成部６６および名前解決テーブル検索部６７は、名前解決テーブル１２の作成および検索を行う。
格納データテーブル検索部６８は、格納データテーブル１４の検索を行うことで、データ格納部３１内のオブジェクト９の格納先を特定する。
【００４２】
図４は、オブジェクト要求メッセージの送信処理（下位から上位へ）を示すフローチャートである。
Ｓ１０１において、端末２ａのノード管理部６１は、オブジェクト「ｏｉｄ＝ａ．ｂ．ｃ」を要求すると判断する。この判断の契機は、ユーザの操作や端末のタイマ、外部要因のトリガなどによる。
Ｓ１０２において、端末２ａのノード管理部６１は、データ送受信部２１を介してオブジェクト要求メッセージ（名前解決用）をノード１ａに送信する。ノード１ａは、データ送受信部２１を介してオブジェクト要求メッセージを受信する。
【００４３】
Ｓ１０３において、ノード１ａのオブジェクトＩＤ転送テーブル検索部６３は、受信したオブジェクト要求メッセージのオブジェクトＩＤを検索キーとして、オブジェクトＩＤ転送テーブル１１を検索する。検索の結果、オブジェクトＩＤがヒットしなかった場合は、次ホップを「default」として設定された上位ノード（ここでは、ノード１ｂ）とする。
Ｓ１０４において、ノード１ａは、ノード１ｂにオブジェクト要求メッセージ（名前解決用）を送信する。Ｓ１０５〜Ｓ１０９も同様に、各ノード１は、オブジェクトＩＤ転送テーブル１１の検索処理と上位ノードへの転送処理を繰り返す。
【００４４】
図５は、図４の続きとして、オブジェクト要求メッセージの送信処理（上位から下位へ）を示すフローチャートである。
Ｓ１１１において、ノード１ｄのオブジェクトＩＤ転送テーブル検索部６３は、Ｓ１０９での検索の結果、オブジェクトＩＤのプレフィックス（ａ．ｂ．ｃのうちの先頭の「ａ」）がヒット（部分一致）し、その検索結果として次ホップのＩＤ（ｎｉｄ＝ｅ）を得る。ノード１ｄは、ノード１ｅに対しオブジェクト要求メッセージ（名前解決用）を送信する。
Ｓ１１２，Ｓ１１３でも、Ｓ１１１と同様に、プレフィックス「ａ」が部分一致する。ノード１ｅは、検索結果として次ホップのＩＤ（ｎｉｄ＝ｆ）を取得し、そのノード１ｆへとオブジェクト要求メッセージを転送する。
【００４５】
Ｓ１１４において、ノード１ｆのオブジェクトＩＤ転送テーブル検索部６３は、オブジェクトＩＤ転送テーブル１１を検索した結果、オブジェクトＩＤが完全一致でヒットする。このように、完全一致でヒットしたノード１ｆが、名前解決を担当する。
Ｓ１１５において、ノード１ｆの名前解決テーブル検索部６７は、オブジェクトＩＤを検索キーとして名前解決テーブル１２を検索し、検索結果としてロケーションＩＤ（ｌｉｄ＝ｄ．ｅ．ｆ．ｇ）を得る。
Ｓ１１６において、ノード１ｆのロケーションＩＤ転送テーブル検索部６５は、Ｓ１１５で得たロケーションＩＤ（ｌｉｄ＝ｄ．ｅ．ｆ．ｇ）を検索キーとして、ロケーションＩＤ転送テーブル１３を検索し、次ホップのＩＤ（ｎｉｄ＝ｇ）を得る。
【００４６】
Ｓ１１７において、ノード１ｆは、Ｓ１１６で得た次ホップであるノード１ｇに対して、オブジェクト要求メッセージ（名前解決用）から生成した、オブジェクト要求メッセージ（オブジェクト取得用）を送信する。
つまり、端末２ａは、名前解決用のメッセージと、オブジェクト取得用のメッセージとを２つ送信する必要が無く、データ指向型通信システムのノード１において、名前解決用のメッセージからオブジェクト取得用のメッセージへと変換される。これにより、名前解決の応答を待つ前準備の期間を短縮できる。
【００４７】
Ｓ１１８において、ノード１ｇの格納データテーブル検索部６８は、受信したオブジェクト要求メッセージの「ｏｉｄ＝ａ．ｂ．ｃ」を検索キーとして、格納データテーブル１４を検索し、格納データＩＤ（図１では、ｓｔｏｒｅ_ｉｄ＝１００）を得る。格納データＩＤとは、データ格納部３１におけるオブジェクトのＩＤである。データ送受信部２１は、格納データＩＤを指定して、データ格納部３１から要求されたオブジェクト９を読み込む。
そして、データ送受信部２１は、読み込んだオブジェクト９をペイロード６０２へと格納し、メッセージヘッダ６０１内の送信元（「src」から始まる行）と宛先（「req」から始まる行）のＩＤを入れ替えることにより、オブジェクト返送メッセージを作成する。
【００４８】
図６は、オブジェクト要求メッセージの各ノードにおける処理を示すフローチャートである。以下の説明では、オブジェクトＩＤとは、受信したオブジェクト要求メッセージに含まれているものを指す。
Ｓ１８１において、オブジェクトＩＤ転送テーブル検索部６３は、オブジェクトＩＤを検索キーとして、オブジェクトＩＤ転送テーブル１１を検索する。
Ｓ１８２において、オブジェクトＩＤ転送テーブル検索部６３は、Ｓ１８１の検索でヒットするプレフィックスがある場合（図１ならｎｉｄ＝ｄ，ｅ，ｆが該当）はＳ１８３へ進み、ない場合（図１ならｎｉｄ＝ａ，ｂ，ｃが該当）はＳ１８７へ進む。
Ｓ１８３において、オブジェクトＩＤ転送テーブル検索部６３は、Ｓ１８１の検索のヒットが完全一致の場合（図１ならｎｉｄ＝ｆが該当）はＳ１８４へ進み、部分一致の場合（図１ならｎｉｄ＝ｄ，ｅが該当）はＳ１８８へ進む。
【００４９】
Ｓ１８４において、名前解決テーブル検索部６７は、オブジェクトＩＤを検索キーとして、名前解決テーブル１２を検索し、オブジェクトＩＤに対するロケーションＩＤを得る。
Ｓ１８５において、ロケーションＩＤ転送テーブル検索部６５は、Ｓ１８４で得たロケーションＩＤを検索キーとしてロケーションＩＤ転送テーブル１３を検索し、次ホップのＩＤを得る。
Ｓ１８６において、データ送受信部２１は、Ｓ１８５で得た次ホップのＩＤを宛先として、オブジェクト要求メッセージを送信する。
【００５０】
Ｓ１８７において、データ送受信部２１は、オブジェクトＩＤ転送テーブル１１で「default」と記載された上位ノードにオブジェクト要求メッセージを送信する。
Ｓ１８８において、データ送受信部２１は、部分一致したエントリに対応する次ホップへ、オブジェクト要求メッセージを送信する。
【００５１】
図７は、オブジェクト要求メッセージの各テーブルにおける処理を示す説明図である。なお、図７の各テーブルの列要素を示す符号の末尾には、そのテーブルが収容されるノード１のｎｉｄが付加される。例えば、ｎｉｄ＝ａのオブジェクトＩＤ転送テーブル１１のｏｉｄ列なら、ｏｉｄを示す「７１１」にｎｉｄを示す「ａ」が付加される。一方、図７の各構成要素は、その性質や機能はどのノード１に格納されているものでも同等であり、その格納されるデータだけが異なるので、以下の図７の各構成要素の説明では、列要素を示す符号の末尾のｎｉｄを適宜省略する。
オブジェクトＩＤ転送テーブル１１は、検索キーの検索対象列であるｏｉｄ７１１（例えば、７１１ａ）と、その検索結果である次ホップを示すｎｅｘｔｈｏｐ＿ｎｉｄ７１２（例えば、７１２ａ）とが対応づけて記録されている。
【００５２】
ここで、データＩＤそのものを位置ＩＤとみなして通信を行う特許文献１との相違点を説明する。本実施形態のオブジェクトＩＤ転送テーブル１１と、特許文献１の転送テーブルとで、検索キーをデータＩＤ（オブジェクトＩＤ）とする点では、共通する。
一方、次ホップを示すｎｅｘｔｈｏｐ＿ｎｉｄ７１２の意味が、両方式で異なる。転送テーブルの検索結果として、本実施形態のオブジェクトＩＤ転送テーブル１１では、検索キーのオブジェクトＩＤの名前解決を行うノード１へ向かう次ホップであるが、特許文献１の転送テーブルでは、検索キーのオブジェクトＩＤを格納するノードへ向かう次ホップである。
【００５３】
よって、オブジェクト９の位置が頻繁に変更される状況下では、特許文献１の転送テーブルは、多くのオブジェクトそれぞれについての最新のデータ位置を頻繁に更新し続ける必要があり、転送テーブルの保存容量や処理負荷が大きくなってしまう。一方、本実施形態のオブジェクトＩＤ転送テーブル１１では、オブジェクト９の位置が頻繁に変更されたとしても、名前解決を行うノード１の位置はほとんど変更されないので、転送テーブルの保存容量や処理負荷を小さくすることができる。
【００５４】
名前解決テーブル１２は、検索キーの検索対象列であるｏｉｄ７２１と、その検索結果である名前解決の結果を示すｌｉｄ７２２とが対応づけて記録されている。
ロケーションＩＤ転送テーブル１３は、検索キーの検索対象列であるｌｉｄ７３１と、その検索結果である次ホップを示すｎｅｘｔｈｏｐ＿ｎｉｄ７３２とが対応づけて記録されている。
格納データテーブル１４は、検索キーの検索対象列であるｏｉｄ７４１と、その検索結果であるデータ記憶部３０内での記録箇所を示すｓｔｏｒｅ＿ｉｄ７４２とが対応づけて記録されている。
なお、「default」とは、検索キーの検索対象がヒットしなかったときの既定の（デフォルトの）転送先を示すエントリであり、図１で説明した上位のノード１に該当する。
【００５５】
ここで、図７に記載された実線矢印は、各テーブルの参照された順序を示す。
Ｓ１０３で、ノード１ａのオブジェクトＩＤ転送テーブル１１の「default」が参照される。
Ｓ１０７で、ノード１ｃのオブジェクトＩＤ転送テーブル１１の「default」が参照される。
Ｓ１０９で、ノード１ｄのオブジェクトＩＤ転送テーブル１１の「ａ」が参照される。
Ｓ１１５で、ノード１ｆの名前解決テーブル１２の「ａ．ｂ．ｃ」が参照される。
Ｓ１１６で、ノード１ｆのロケーションＩＤ転送テーブル１３の「ｄ．ｅ．ｆ．ｇ」が参照される。
Ｓ１１８で、ノード１ｇの格納データテーブル１４の「ａ．ｂ．ｃ」が参照される。
【００５６】
なお、各転送テーブル作成部（オブジェクトＩＤ転送テーブル作成部６２、ロケーションＩＤ転送テーブル作成部６４）は、作成対象の各転送テーブル（オブジェクトＩＤ転送テーブル１１、ロケーションＩＤ転送テーブル１３）内のエントリについて、複数のエントリを１つのエントリへと集約することで、エントリ数を削減させてもよい。集約可能な複数のエントリとは、例えば、以下の２条件をともに満たしたものである。
（条件１）複数のエントリ間で、プレフィックスが同じである。
（条件２）複数のエントリ間で、次ホップが同じである。
【００５７】
図８，図９は、オブジェクト返送メッセージの送信処理を示すフローチャートである。図８は、図５の続きの処理である。
Ｓ２０１において、ノード１ｇは、ノード１ｆにオブジェクト返送メッセージ（Ｓ１１８で作成されたもの）を送信する。
【００５８】
Ｓ２０２において、ノード１ｆのオブジェクトＩＤ転送テーブル作成部６２は、自身のオブジェクトＩＤ転送テーブル１１を更新する。
更新内容のエントリのｏｉｄ７１１は、オブジェクト返送メッセージのオブジェクトＩＤ（ペイロード６０２に格納されているオブジェクト９のｏｉｄ）である。
更新内容のエントリのｎｅｘｔｈｏｐ＿ｎｉｄ７１２は、オブジェクト返送メッセージの受信元ノード（次ホップとして隣接するノード１）のＩＤ（ｎｉｄ＝ｇ）である。
【００５９】
既にオブジェクトＩＤ転送テーブル１１内に更新内容のｏｉｄ７１１が存在するときには、そのエントリのｎｅｘｔｈｏｐ＿ｎｉｄ７１２だけを上書き更新し、ｏｉｄ７１１が存在しないときには、新たに更新内容のエントリを作成して、オブジェクトＩＤ転送テーブル１１に追加する。
これにより、同じオブジェクト９が再度要求されたときに、オブジェクトＩＤ転送テーブル１１にそのオブジェクトのエントリが存在するので、オブジェクト要求メッセージを適切に転送できるルートが確立される。
【００６０】
Ｓ２０３において、ノード１ｆのロケーションＩＤ転送テーブル検索部６５は、オブジェクト返送メッセージのロケーションＩＤを検索キーとしてロケーションＩＤ転送テーブル１３を検索し、検索結果として次ホップのＩＤ（ｎｉｄ＝ｅ）を得る。
Ｓ２０４において、ノード１ｆは、Ｓ２０３で得た次ホップであるノード１ｅに対して、オブジェクト返送メッセージを送信する。
Ｓ２０５〜Ｓ２０９や、図９のＳ２１１〜Ｓ２２０も同様に、オブジェクトＩＤ転送テーブル１１の更新処理（Ｓ２０２相当）、ロケーションＩＤ転送テーブル１３での次ホップの検索処理（Ｓ２０３相当）、および、検索された次ホップへのオブジェクト返送メッセージの送信処理（Ｓ２０４相当）を行う。
Ｓ２２１において、端末２ａは、ノード１ａからオブジェクト９を取得する。
【００６１】
ここで、Ｓ２０２で説明した更新内容のエントリのｎｅｘｔｈｏｐ＿ｎｉｄ７１２について、受信元ノードとする代わりに、短縮経路のノード１を選択してもよい。
短縮経路のノード１とは、同じ宛先へと向かう経路候補のうちのホップ数を少なくできる経路であり、例えば、図１では、短縮経路なしの＜ノード１ｃ→ノード１ｄ→ノード１ｅ＞よりも、短縮経路ありの＜ノード１ｃ→ノード１ｅ＞のほうが、ホップ数が少なくて済む。
【００６２】
以下、短縮経路のノード１の取得方法を説明する。
Ｓ２１２において、ノード１ｃのオブジェクトＩＤ転送テーブル作成部６２は、メッセージヘッダ６０１から６行目の「route_info_nid」を読み込む。「route_info_nid」には、通過したノード１の順序リスト＜ａ，ｂ，ｃ，ｄ，ｅ，ｆ＞が記載されている（図２参照）。
ノード１ｃは、受信元ノード「ｎｉｄ＝ｄ」よりも先にあるノードで、かつ、自身に隣接している（図１で直接接続されている）ノード「ｎｉｄ＝ｅ」を発見すると、そのノード「ｎｉｄ＝ｅ」を短縮経路のノード１としてｎｅｘｔｈｏｐ＿ｎｉｄ７１２に採用する。
【００６３】
図１０は、オブジェクト返送メッセージの各ノードにおける処理を示すフローチャートである。
Ｓ２８１において、オブジェクトＩＤ転送テーブル作成部６２は、Ｓ２０２で説明したように、オブジェクト返送メッセージのオブジェクトＩＤのエントリをもとに、自身のオブジェクトＩＤ転送テーブル１１を更新する。
Ｓ２８２において、ロケーションＩＤ転送テーブル検索部６５は、オブジェクト返送メッセージのロケーションＩＤを検索キーとして、ロケーションＩＤ転送テーブル１３を検索し、次ホップのＩＤを得る。
Ｓ２８３において、Ｓ２８２で得た次ホップのＩＤを宛先として、オブジェクト返送メッセージを送信する。
【００６４】
図１１は、オブジェクト返送メッセージの各テーブルにおける処理を示す説明図である。図７の６つのテーブルのうち、オブジェクト返送メッセージの送信に伴って更新されたオブジェクトＩＤ転送テーブル１１を３つ例示している（他のオブジェクトＩＤ転送テーブル１１も更新されているが、図示を省略する）。
Ｓ２０２で説明したように、各オブジェクトＩＤ転送テーブル１１には、ｏｉｄ７１１＝「ａ．ｂ．ｃ」とするエントリがそれぞれ新規追加されている（図１１の矢印が示すエントリ、矢印は更新順序を示す）。
さらに、ノード１ｃのオブジェクトＩＤ転送テーブル１１には、ｏｉｄ７１１＝「ａ．ｂ」とするエントリも追加されているが、このエントリは、短縮経路のノード１を採用したエントリであり、オブジェクトＩＤ「ａ．ｂ．ｃ」のプレフィックス「ａ．ｂ」と対応づけている。
【００６５】
図１２は、データ指向型通信システムを示す構成図である。例として、端末２ａがノード１ａに対してオブジェクト９（ｏｉｄ＝ａ．ｂ．ｄ）を登録する旨のオブジェクト登録メッセージを、ノード１ａからノード１ｆまで転送する処理について、以下の図１３〜図１６で説明する。
オブジェクト登録メッセージは、登録されるオブジェクトのｏｉｄ「ａ．ｂ．ｄ」を、経由する各ノード１のオブジェクトＩＤ転送テーブル１１に記憶させつつ、名前解決を行うノード１ｆまで転送される。そして、ノード１ｆは、オブジェクトＩＤとオブジェクトが登録されたノード１ａの位置ＩＤ「ｄ．ｅ．ｆ．ａ」を名前解決テーブル１２に記憶する。
【００６６】
図１３，図１４は、オブジェクト登録メッセージの送信処理を示すフローチャートである。
Ｓ３０１において、端末２ａのノード管理部６１は、オブジェクト「ｏｉｄ＝ａ．ｂ．ｄ」の登録を行うと判断する。この判断の契機は、例えば、ユーザの操作や端末のタイマ、外部要因のトリガなどが発生したことによる。
Ｓ３０２において、端末２ａのノード管理部６１は、データ送受信部２１を介して、オブジェクト登録メッセージ（名前解決用）をノード１ａに送信する。ノード１ａは、データ送受信部２１を介してオブジェクト登録メッセージを受信し、その登録先が自身であることを認識すると、オブジェクト登録メッセージのペイロード６０２から読み出したオブジェクト９をデータ格納部３１に格納するとともに、その格納位置を格納データテーブル１４に登録する。
【００６７】
Ｓ３０３において、ノード１ａのオブジェクトＩＤ転送テーブル検索部６３は、Ｓ３０２で受信したオブジェクト登録メッセージのオブジェクトＩＤを検索キーとして、オブジェクトＩＤ転送テーブル１１を検索する。検索した結果、オブジェクトＩＤがヒットしないので、次ホップを上位ノードであるノード１ｂとする。
Ｓ３０４において、ノード１ａは、Ｓ３０３で特定した次ホップであるノード１ｂに、オブジェクト登録メッセージを送信する。
【００６８】
Ｓ３０５において、ノード１ｂのオブジェクトＩＤ転送テーブル作成部６２は、Ｓ２０２と同様に、オブジェクトＩＤ転送テーブル１１を更新する。
Ｓ３０７〜Ｓ３１２、および、図１５のＳ３２１，Ｓ３２２において、オブジェクトＩＤ転送テーブル１１の検索処理（Ｓ３０３相当）、次ホップへのオブジェクト登録メッセージの送信処理（Ｓ３０４相当）、および、オブジェクトＩＤ転送テーブル１１の更新処理（Ｓ３０５相当）を、同様に繰り返す。
【００６９】
Ｓ３２３において、ノード１ｆのオブジェクトＩＤ転送テーブル検索部６３は、Ｓ３０３と同様に、「ｏｉｄ＝ａ．ｂ．ｄ」を検索キーとして、オブジェクトＩＤ転送テーブル１１を検索する。検索の結果、ノード１ｆのオブジェクトＩＤ転送テーブル１１には、ｏｉｄ７２１ｆ＝「ａ．ｂ．ｄ」である完全一致のエントリは存在しないものの、プレフィックス「ａ．ｂ」が共通であるｏｉｄ７２１ｆ＝「ａ．ｂ．ｃ」のエントリが存在するため（図７参照）、完全一致とみなす。つまり、完全一致とみなしたノード１ｆを、名前解決を行うノード１とする。
【００７０】
Ｓ３２４において、ノード１ｆの名前解決テーブル作成部６６は、名前解決テーブル１２において、ｌｉｄ７３１ｆ＝ノード１ａの位置ＩＤ「ｄ．ｅ．ｆ．ａ」とし、ｎｅｘｔｈｏｐ＿ｎｉｄ７３２ｆ＝ノード１ｅとする新エントリを作成して、その新エントリを名前解決テーブル１２に反映する。ここで、反映とは、ｌｉｄ７３１ｆ＝「ｄ．ｅ．ｆ．ａ」のエントリが既に存在していれば、ｎｅｘｔｈｏｐ＿ｎｉｄ７３２ｆだけを書き換え、エントリが存在していなければ、新エントリを名前解決テーブル１２に新規追加する処理である。
【００７１】
図１５は、オブジェクト登録メッセージの各ノードにおける処理を示すフローチャートである。
Ｓ３８１において、オブジェクトＩＤ転送テーブル作成部６２は、Ｓ２０２（Ｓ３０５）と同様に、オブジェクトＩＤ転送テーブル１１を更新する。
Ｓ３８２において、オブジェクトＩＤ転送テーブル検索部６３は、オブジェクト登録メッセージのオブジェクトＩＤを検索キーとしてオブジェクトＩＤ転送テーブル１１を検索し、その検索結果として次ホップを得る。
Ｓ３８３において、データ送受信部２１は、Ｓ３８２で取得した次ホップのＩＤを宛先として、オブジェクト登録メッセージを送信する。
【００７２】
図１６は、オブジェクト登録メッセージの各テーブルにおける処理を示す説明図である。この図１６での矢印は、オブジェクト登録メッセージによる登録後に、その登録されたオブジェクト９を要求するためのオブジェクト要求メッセージが到着したときに参照される各テーブルの順序を示す。
【００７３】
まず、ノード１ａのオブジェクトＩＤ転送テーブル１１内のｏｉｄ７１１ａ＝「ａ．ｂ．ｄ」が参照される（ノード１ｂのオブジェクトＩＤ転送テーブル１１は、図示省略）。次に、ノード１ｃのオブジェクトＩＤ転送テーブル１１内のｏｉｄ７１１ｃ＝「ａ．ｂ．ｄ」が参照される。そして、ノード１ｆのオブジェクトＩＤ転送テーブル１１内のｏｉｄ７１１ｆ＝「ａ．ｂ．ｄ」が参照され、ｎｅｘｔｈｏｐ＿ｎｉｄ７１２ｆが「local」なので、ノード１ｆ自身が名前解決を担当するノード１であることがわかる。
【００７４】
ノード１ｆの名前解決テーブル検索部６７は、名前解決テーブル１２のｏｉｄ７２１ｆ＝「ａ．ｂ．ｄ」から、ｌｉｄ７２２ｆ＝「ｄ．ｅ．ｆ．ａ」を得る。さらに、ノード１ｆのロケーションＩＤ転送テーブル検索部６５は、ｌｉｄ７３１ｆ＝「ｄ．ｅ．ｆ．ａ」からｎｅｘｔｈｏｐ＿ｎｉｄ７３２ｆ＝「ｅ」を得る。
そして、ｌｉｄ＝「ｄ．ｅ．ｆ．ａ」によるｌｉｄ転送を経て、ノード１ａの格納データテーブル１４のｏｉｄ７４１ａ＝「ａ．ｂ．ｄ」からｓｔｏｒｅ＿ｉｄ７４２ａ＝３００が特定され、ノード１ａのデータ格納部３１内の３００番のアドレスからオブジェクト９が読み込まれる。
【００７５】
以上説明した本実施形態では、図１の実線矢印で示すようにオブジェクトＩＤを用いたｏｉｄ転送で名前解決するノード１ｆまでオブジェクト要求メッセージを転送するとともに、ノード１ｆから先は、図１の破線矢印で示すようにロケーションＩＤを用いたｌｉｄ転送でオブジェクト要求メッセージを転送する、つまり、同じデータ指向型通信システム内でｏｉｄ転送とｌｉｄ転送とを併用する形態である。
【００７６】
そして、本実施形態では、端末２は、オブジェクト要求メッセージを１回送信するだけで、名前解決と、その名前解決されたオブジェクト要求メッセージによる宛先への転送とが実現できる（Ｓ１１７の説明を参照）。つまり、端末２は、オブジェクト要求メッセージにおいて、ホストＩＤから位置ＩＤの変換（名前解決）を明示的に要求しなくても、移動するオブジェクトに対し、データＩＤを指定するだけで所望のオブジェクトをオブジェクト返送メッセージから取得することができる。
なお、名前解決を担当するノード１（図１では、ノード１ｆ）の特定方法として、Ｓ１８３などで説明したようにｏｉｄの完全一致をするノード１とする代わりに、図１６のオブジェクトＩＤ転送テーブル１１のｎｅｘｔｈｏｐ＿ｎｉｄ７１２ｆで示したように、ｏｉｄの次ホップが「local」であるノード１としてもよい。
さらに、図１７に示すように、ｏｉｄが完全一致をするノード１（Ｓ１８３，Ｙｅｓ）、かつ、次ホップが「local」であるノード１（Ｓ１８３ｂ，Ｙｅｓ）というＡＮＤ条件を満たすノード１を、名前解決を担当するノード１（以下、「名前解決ノード」と呼ぶ）としてもよい。
図１７は、図６と比較すると、２つの処理（Ｓ１８３ｂ，Ｓ１８７ｂ）が追加されている。Ｓ１８７ｂは、Ｓ１８８と同様に、自身が名前解決を担当するノード１ではないので、次ホップの転送先ノード１へオブジェクト要求を転送する処理である。
【００７７】
一方、非特許文献１や非特許文献２などの方式では、名前解決の応答をクライアント側（端末側）が受ける必要があるため、端末側に名前解決を要求するための機能を実装する負担がかかるとともに、サーバ側（ＤＮＳなどのサービス提供側）にもサービスを管理および維持するためのコストがかかる。
また、名前解決をしてからデータ通信を開始するため、名前解決を行う前準備の期間にデータ通信の待ち時間（遅延）が発生するとともに、名前解決を実行するための制御用パケットのトラフィックによるネットワーク効率の低下も発生する。とくに、非特許文献２の方式では、通信を行う度にホストＩＤから位置ＩＤに変換する要求がＤＨＴ内を渡り歩くため、過剰に遅延とトラフィックが発生する。
【００７８】
さらに、本実施形態では、オブジェクト返送メッセージやオブジェクト登録メッセージを各ノード１が転送するときに、その転送処理に併せて、オブジェクトＩＤを各ノード１の転送テーブルに登録する処理を行う（Ｓ２０２，Ｓ３０５などを参照）。これにより、頻繁に位置が変更されるオブジェクト９であっても、その最新の位置情報をすぐに転送テーブルに反映させることができる。
【００７９】
一方、名前解決の変換結果をＤＮＳサーバに向かう途中のノードにキャッシュすることで、ＤＮＳサーバの負荷を軽減する従来の方式では、キャッシュデータが最新の位置情報を反映していないことも多いため、頻繁に位置が変更されるオブジェクト９の実際の位置を特定することが困難となってしまう。
つまり、通信相手のホストが物理的に移動した場合には、ホスト名が同じでもそのＩＰアドレスが変更されてしまうので、名前解決の変換結果が変更されてしまう。よって、キャッシュされた古い変換結果と、ホスト移動後の新しい変換結果とが異なるものとなってしまう。
【００８０】
以上説明した本実施形態により、オブジェクト９の位置が変更されても、その最新の位置情報の登録先が変更前と同じノード１であるときには、オブジェクト要求メッセージの送信先は、その登録先ノード１のままである。よって、オブジェクト要求メッセージのｏｉｄ転送の経路（オブジェクトＩＤ転送テーブル１１のエントリ）は変更しなくてもよい。
一方、オブジェクト９の位置が変更され、かつ、その最新の位置情報の登録先が変更前とは別のノード１であるときには、オブジェクト要求メッセージのｏｉｄ転送の経路を、新たな登録先のノード１へと誘導する必要がある。
【００８１】
そのため、以下では、「経路修正メッセージ」という新たなメッセージを定義する（詳細は、後記の図２６などで説明）。経路修正メッセージは、オブジェクトＩＤ転送テーブル１１のエントリを修正するためのメッセージである。以下、経路修正メッセージをもとに、オブジェクト９の最新位置が登録されている名前解決のノード１へのオブジェクト要求メッセージの誘導を実現する方法を詳細に説明する。
【００８２】
図１８は、データ指向型通信システム（２つのデータ位置の説明用）を示す構成図である。図１のデータ指向型通信システムと比較すると、２つのノード（ｎｉｄ＝ｈのノード１ｈと、ｎｉｄ＝ｉのノード１ｉ）が追加され、端末２が４台（端末２ａ〜２ｄ）になっている。
さらに、図１８の２つのオブジェクト９（９ａ，９ｂ）は、同じｏｉｄ（＝ａ．ｂ．ｃ）のオブジェクトであり、ノード１ａ（旧位置）内にオブジェクト９ａとして格納された後、ノード１ｇ（新位置）内のオブジェクト９ｂに格納される。なお、オブジェクト９ａの旧位置の名前解決ノードは、ノード１ｂであり、オブジェクト９ａの新位置の名前解決ノードは、ノード１ｆである。
特許請求の範囲の「第１ノード」は、端末２ｄを収容するノード１ｇである。
特許請求の範囲の「第２ノード」は、名前解決ノード（ノード１ｂ、ノード１ｆ）である。
特許請求の範囲の「第３ノード」は、データ収容ノード（ノード１ａ、ノード１ｇ）である。
【００８３】
ここで、オブジェクト９ａからオブジェクト９ｂへの移動処理を実現するためには、本来は、オブジェクト９ｂの格納後に、オブジェクト９ａを消去する必要がある。しかし、以下の説明では、オブジェクト９ｂの格納後にも、オブジェクト９ａが存続する状態をもとに、不具合が発生してしまう事例とその対策について説明する。
【００８４】
図１９は、図１８のシステムにおける旧位置のオブジェクト登録を示す構成図である。オブジェクト９ａのオブジェクト登録メッセージは、端末２ｄから送信されて、ノード１ｇ→ノード１ｆ→ノード１ｅ→ノード１ｃを順に中継し、旧位置として名前解決ノードであるノード１ｂに登録され、オブジェクト９そのものは、旧位置であるノード１ａに格納される。
【００８５】
オブジェクト登録メッセージが中継される各途中のノード１（ノード１ｇ→ノード１ｆ→ノード１ｅ→ノード１ｃ）のオブジェクトＩＤ転送テーブル１１は、それぞれ更新される（具体的な更新処理は、図１３のＳ３０５などを参照）。つまり、各途中のノード１は、自身のオブジェクトＩＤ転送テーブル１１のｏｉｄ７１１にオブジェクト９ａのｏｉｄ（＝ａ．ｂ．ｃ）を書き込み、自身のオブジェクトＩＤ転送テーブル１１のｎｅｘｔｈｏｐ＿ｎｉｄ７１２にノード１ａへ向かう隣接ノードを書き込む。
なお、以下の説明では、オブジェクトＩＤ転送テーブル１１のｎｅｘｔｈｏｐ＿ｎｉｄ７１２の内容を、ノード内に「next_oid」と表記する。また、ロケーションＩＤ転送テーブル１３のｎｅｘｔｈｏｐ＿ｎｉｄ７３１の内容を、ノード内に「next_lid」と表記する。
【００８６】
図２０は、図１８のシステムにおける新位置のオブジェクト登録を示す構成図である。オブジェクト９ｂのオブジェクト登録メッセージは、端末２ｄから送信されて、ノード１ｇを中継し、新位置として名前解決ノードであるノード１ｆに登録され、オブジェクト９そのものは、新位置であるノード１ｇに格納される。
【００８７】
ここで、オブジェクト登録メッセージが通過するノード１ｆ，１ｇは、自身のオブジェクトＩＤ転送テーブル１１の内容を、新しい名前解決ノードがノード１ｆであるように更新できる（具体的な更新処理は、図１３のＳ３０５などを参照）。一方、図２０のオブジェクト登録メッセージが通過しないノード１ｅ，１ｃ，１ｂは、自身のオブジェクトＩＤ転送テーブル１１の内容が、古い名前解決ノードであるノード１ｂのままである。
【００８８】
図２１は、図１８のシステムにおける２つの位置のオブジェクト要求を示す構成図である。オブジェクト９ａからオブジェクト９ｂへのコピー処理が行われた後に、オブジェクト９ｂのデータ内容が変更された結果、オブジェクト９ａとオブジェクト９ｂとのデータ内容が相違する状態が発生する。
【００８９】
図２１の左側は、端末２ｂが、旧位置のオブジェクト９ａに対して、オブジェクト要求メッセージを送信してしまう例を示す。端末２ｂからのオブジェクト要求メッセージは、ノード１ｈ→ノード１ｂ（名前解決ノード）→ノード１ａの順に通過する。これにより、端末２ｂは、古いデータ内容のオブジェクト９ａを取得してしまうので、望ましくない。
オブジェクト９ａを取得してしまう要因は、図２０の新しいオブジェクト登録メッセージが通過しないノード１ｅ，１ｃ，１ｂに、図１９で示した古いオブジェクト登録メッセージによる影響が残ったままになっているためである。
【００９０】
図２１の右側は、端末２ｃが、新位置のオブジェクト９ｂに対して、オブジェクト要求メッセージを送信できる例を示す。端末２ｃからのオブジェクト要求メッセージは、ノード１ｉ→ノード１ｆ（名前解決ノード）→ノード１ｇの順に通過する。これにより、端末２ｃは、新しいデータ内容のオブジェクト９ｂを取得できる。
【００９１】
図２２は、図２１の右側（新位置のオブジェクト要求処理）を示すフローチャートである。このフローチャートは、図４，５で示したオブジェクト要求処理と同じ処理で、ノード１の位置が変更されているだけである。
Ｓ４０１において、端末２ｃは、Ｓ１０１と同様に、オブジェクト「ｏｉｄ＝ａ．ｂ．ｃ」を要求すると判断する。
Ｓ４０２において、端末２ｃは、Ｓ１０２と同様に、オブジェクト要求メッセージ（名前解決用）を隣接する次ホップのノード１ｉに送信する。
【００９２】
オブジェクト要求メッセージ（名前解決用）の経路上に位置するノード１ｉは、以下の手順を行う。
（手順１）Ｓ１０２と同様に、前段の装置からオブジェクト要求メッセージ（名前解決用）を受信する（Ｓ４０２）。
（手順２）Ｓ１０３と同様に、自身のオブジェクトＩＤ転送テーブル１１を検索し、オブジェクト要求メッセージの転送先を決定する（Ｓ４０３）。
（手順３）Ｓ１０４と同様に、決定した転送先である後段の装置へ、オブジェクト要求メッセージを送信する（Ｓ４０４）。
【００９３】
オブジェクト要求メッセージ（名前解決用）の名前解決ノードであるノード１ｆは、以下の手順を行う。
（手順１）Ｓ１１３と同様に、前段の装置からオブジェクト要求メッセージ（名前解決用）を受信する（Ｓ４０４）。
（手順２）Ｓ１１４と同様に、自身のオブジェクトＩＤ転送テーブル１１を検索し、オブジェクト要求メッセージの名前解決ノードを自身であると決定する（Ｓ４０５）。
（手順３）Ｓ１１５と同様に、名前解決テーブル１２を検索し、オブジェクト９のロケーションＩＤを得る（Ｓ４０６）。
（手順４）Ｓ１１６と同様に、ロケーションＩＤ転送テーブル１３を検索し、オブジェクト要求メッセージのｌｉｄ転送における次ホップを得る（Ｓ４０７）。
（手順５）Ｓ１１７と同様に、ロケーションＩＤ転送テーブル１３から得た次ホップ（後段の装置）へ、オブジェクト要求メッセージ（名前解決用）から生成した、オブジェクト要求メッセージ（オブジェクト取得用）を送信する（Ｓ４０８）。
【００９４】
オブジェクト要求メッセージが要求するオブジェクト９を自身に格納するノード１ｇは、以下の手順を行う。
（手順１）Ｓ１１７と同様に、前段の装置からオブジェクト要求メッセージ（オブジェクト取得用）を受信する（Ｓ４０８）。
（手順２）Ｓ１１８と同様に、自身の格納データテーブル１４を検索し、格納データＩＤを得て、データ格納部３１から要求されたオブジェクト９を読み込む（Ｓ４０９）。そして、読み込んだオブジェクト９をもとに、オブジェクト返送メッセージを作成する。
【００９５】
図２３は、図２１の右側（新位置のオブジェクト返送処理）を示すフローチャートである。このフローチャートは、図８，９で示したオブジェクト返送処理と同じ処理で、ノード１の位置が変更されているだけである。
Ｓ４２１において、ノード１ｇは、Ｓ２０１と同様に、Ｓ１１８で作成されたオブジェクト返送メッセージを隣接する次ホップのノード１ｆに送信する。
【００９６】
オブジェクト返送メッセージの経路上に位置する各ノード１は、以下の手順を行う。
（手順１）Ｓ２０１と同様に、前段の装置からオブジェクト返送メッセージを受信する（ノード１ｆならＳ４２１，ノード１ｉならＳ４２４）。
（手順２）Ｓ２０２と同様に、自身のオブジェクトＩＤ転送テーブル１１を更新する（Ｓ４２２，Ｓ４２５）。
（手順３）Ｓ２０３と同様に、自身のロケーションＩＤ転送テーブル１３を検索し、検索結果として次ホップを得る（Ｓ４２３，Ｓ４２６）。
（手順４）Ｓ２０４と同様に、（手順３）で得た次ホップ（後段の装置）へ、オブジェクト返送メッセージを送信する（Ｓ４２４，Ｓ４２７）。
【００９７】
オブジェクト返送メッセージの送信先である（オブジェクト要求メッセージの送信元である）端末２ｃは、以下の手順を行う。
（手順１）Ｓ２２０と同様に、前段の装置からオブジェクト返送メッセージを受信する（Ｓ４２７）。
（手順２）Ｓ２２１と同様に、受信したオブジェクト返送メッセージ内のオブジェクト９を取得する。このオブジェクト９は、新位置のオブジェクト９ｂである（Ｓ４２８）。
【００９８】
図２４は、図２１の左側（旧位置のオブジェクト要求処理）を示すフローチャートである。この図２４の処理は、図２２の処理と同じであり、その処理の動作主体だけが以下のように変更されている。
（図２２の端末２ｃ）→（図２４の端末２ｂ）
（図２２のノード１ｉ）→（図２４のノード１ｈ）
（図２２のノード１ｆ）→（図２４のノード１ｂ）
（図２２のノード１ｇ）→（図２４のノード１ａ）
そして、図２２の処理符号（例えば、Ｓ４０１）に４０を足した符号が、図２４の処理符号（例えば、Ｓ４４１）に対応する。
【００９９】
図２５は、図２１の左側（旧位置のオブジェクト返送処理）を示すフローチャートである。この図２５の処理は、図２３の処理と同じであり、その処理の動作主体の変更や、符号の変更（符号＋４０）は、図２４と同じルールである。
ここで、Ｓ４２８に対応するＳ４６８として、端末２ｂは、旧位置のオブジェクト９ａを取得してしまっている（図２１で説明）。
【０１００】
図２６は、図２０のオブジェクト登録後の経路修正を示す構成図である。
端末２ｄは、図２０で説明したように、「ｏｉｄ＝ａ．ｂ．ｃ」のオブジェクト９ｂを登録するためのオブジェクト登録メッセージを、ノード１ｇを経由して、登録先の名前解決ノードであるノード１ｆに送信する。このオブジェクト登録メッセージが通過する各ノード１では、次ホップへの送信処理（Ｓ３０４相当の処理）に加えて、自身のオブジェクトＩＤ転送テーブル１１の更新処理（Ｓ３０５相当の処理）を実行する。この更新処理により、図２１の右側で示したように、新位置へのオブジェクト要求が実現できる。
【０１０１】
名前解決ノードであるノード１ｆは、Ｓ３２４相当の処理で、自身の名前解決テーブル１２の更新において、新規登録ではなく既存エントリへの書き換えが発生した場合は、ノード１ｆは古い経路情報の修正が必要となると判断する。古い経路情報とは、図２０の新しいオブジェクト登録メッセージが通過しないノード１ｅ，１ｃ，１ｂ内のオブジェクトＩＤ転送テーブル１１のエントリである。そして、修正の判断を受け、ノード１ｆは、古い経路経由で経路修正メッセージを送信する。
ここでは、経路修正メッセージの送信先をオブジェクト９ａを格納するノード１ａのｌｉｄとし、ロケーションＩＤ転送テーブル１３を参照したｌｉｄ転送を用いることにする。
【０１０２】
図２７は、図２６の経路修正処理（経路修正メッセージの処理）を示すフローチャートである。
【０１０３】
Ｓ５０１において、ノード１ｆは、図２６の説明で示したように、古い経路情報の修正が必要か否かを判断する。修正が不要なら（Ｓ５０１，Ｎｏ）、Ｓ５３０へ処理を進める。修正が必要なら（Ｓ５０１，Ｙｅｓ）、古いオブジェクト９ａの「ｏｉｄ＝ａ．ｂ．ｃ」と、格納先の「ｌｉｄ＝ｄ．ｃ．ｂ．ａ（ノード１ａのアドレス）」とを含む経路修正メッセージを作成する。
【０１０４】
そして、ノード１ｆは、ロケーションＩＤ転送テーブル１３から経路修正メッセージのｌｉｄに対応する次ホップをノード１ｅとして検索し、そのノード１ｅに対して、経路修正メッセージを送信する（Ｓ５０２）。なお、図２７のフローチャートでは、経路修正メッセージを「オブジェクト登録（経路修正）」と表記している。これは、経路修正メッセージが、図２６のオブジェクト登録メッセージから派生したメッセージであるためである。
【０１０５】
以下、経路修正メッセージを転送する各ノード１（ノード１ｅ→ノード１ｃ→ノード１ｂ）の処理手順を説明する。
（手順１）ノード１は、前段の装置から経路修正メッセージを受信する（ノード１ｅならＳ５０２，ノード１ｃならＳ５０５，ノード１ｂならＳ５０８）。
（手順２）ノード１のオブジェクトＩＤ転送テーブル作成部６２は、経路修正メッセージ内のｏｉｄを検索キーとして自身のオブジェクトＩＤ転送テーブル１１を検索し、検索結果として得たエントリを修正することで、オブジェクトＩＤ転送テーブル１１を更新する（Ｓ５０３，Ｓ５０６，Ｓ５０９）。
ここで、エントリの修正とは、エントリのレコードを削除してもよいし、エントリのレコードの次ホップのノード１を、オブジェクト９ａの名前解決ノード（ノード１ｂ）からオブジェクト９ｂの名前解決ノード（ノード１ｆ）へ向かう次ホップへと変更してもよい。後記する図２９の例では、エントリの修正として、各ノード１は、次ホップの変更処理を行っている。
【０１０６】
（手順３）ノード１のロケーションＩＤ転送テーブル検索部６５は、経路修正メッセージ内のｌｉｄを検索キーとしてロケーションＩＤ転送テーブル１３を検索し、検索結果として次ホップのノード１のＩＤを得る（Ｓ５０４，Ｓ５０７，Ｓ５１０）。
（手順４）ノード１は、（手順３）で得た後段の装置である次ホップのノード１へ、経路修正メッセージを送信する（Ｓ５０５，Ｓ５０８，Ｓ５１１）。
【０１０７】
そして、経路修正メッセージは、オブジェクト９ａを格納するノード１ａへと送信され、ノード１ａは、その経路修正メッセージへの返事（ＡＣＫ）を、経路修正メッセージの送信者であるノード１ｆに送信する（Ｓ５２０）。
ノード１ｆは、経路修正メッセージが送信不要（Ｓ５０１，Ｎｏ）と判断したとき、または経路修正メッセージへのＡＣＫを受信した（Ｓ５２０）ときに、その経路修正メッセージの派生元であるオブジェクト登録メッセージへのＡＣＫを、オブジェクト登録メッセージの送信元である端末２に返信する（Ｓ５３０）。
【０１０８】
図２８は、図２６の経路修正処理における名前解決ノード（ノード１ｆ）の処理を示すフローチャートである。このフローチャートは、オブジェクト登録メッセージが到着するたびに、別のプロセスを新規に起動して実行される。
なお、このフローチャートは、図１４で説明したノード１ｆの処理（Ｓ３２１〜Ｓ３２４）を拡張したものであるので、既に説明したノード１ｆの処理（Ｓ３２１〜Ｓ３２４）の詳細説明は、省略する。
【０１０９】
ノード１ｆは、オブジェクト登録（名前解決）を受信すると（Ｓ３２１）、オブジェクトＩＤ転送テーブル１１を更新し（Ｓ３２２）、オブジェクトＩＤ転送テーブル１１を検索する（Ｓ３２３）。
【０１１０】
ここで、ノード１ｆは、自身が管理する経路修正メッセージを同時に複数個発生させないためのロック処理を実行する。このロック処理では、ある経路修正メッセージを発行すると、その経路修正メッセージへのＡＣＫを受信するまで、別の経路修正メッセージの発行を待機させる。
よって、ノード１ｆは、現在がロック中であるときには（Ｓ３３１，Ｙｅｓ）、既に前の経路修正メッセージが発行された後なので、その前の経路修正メッセージのロック解除（Ｓ３４５）を待ってから、処理をＳ３２４へ進める。Ｓ３２４では、ノード１ｆは、名前解決テーブル１２を更新する。
なお、前の経路修正メッセージのロック解除（Ｓ３４５）と、現在の経路修正メッセージのロック解除待ち（Ｓ３３１，Ｙｅｓ）とは、それぞれ別のプロセスで並行に動作しているので、ロック解除待ちが永遠に続く（デッドロック）ことはない。
【０１１１】
Ｓ３３２では、ノード１ｆは、古い経路情報の修正が必要か否かを判断する（Ｓ５０１と同じ）。修正が不要なら（Ｓ３３２，Ｎｏ）、ノード１ｆは、オブジェクト登録メッセージへのＡＣＫを端末２に返信して（図２７のＳ５３０）、処理を終了する。そして、ノード１ｆは、次の経路修正メッセージをロックしてから（Ｓ３３３）、今の経路修正メッセージを送信する（Ｓ３４１，Ｓ５０２と同様）。
【０１１２】
ノード１ｆは、今の経路修正メッセージへのＡＣＫを受信したか否かを、例えば、Ｓ３４１の送信時刻を起点として所定時間待つことにより、判断する（Ｓ３４２）。
ノード１ｆは、ＡＣＫを受信できたら（Ｓ３４２，Ｙｅｓ）、Ｓ５３０のオブジェクト登録メッセージへのＡＣＫとして、登録成功のＡＣＫを返信する（Ｓ３４３）。
ノード１ｆは、ＡＣＫを受信できなかったら（Ｓ３４２，Ｎｏ）、Ｓ５３０のオブジェクト登録メッセージへのＡＣＫとして、登録失敗のＡＣＫを返信する（Ｓ３４４）。
そして、ノード１ｆは、次の経路修正メッセージへのロック（Ｓ３３３）を解除する（Ｓ３４５）。
【０１１３】
図２９は、図２６の経路修正メッセージの送信後のオブジェクト要求を示す構成図である。図２６〜図２８で説明した経路修正メッセージによって、ノード１ｅ，１ｃ，１ｂ内のオブジェクトＩＤ転送テーブル１１のエントリは、古い名前解決ノードであるノード１ｂへ向かう次ホップから、新しい名前解決ノードであるノード１ｆへ向かう次ホップへと修正されている。
【０１１４】
例えば、ノード１ｂのnext_oidは、ノード１ｆへ向かうための次ホップであるノード１ｃへと修正される。そのため、図２１と比較すると、端末２ｂからのオブジェクト要求メッセージは、中継点のノード１ｂで、ノード１ａに向かわずに、ノード１ｃへと向かう。
つまり、どの端末２（端末２ａ〜端末２ｄ）からオブジェクト要求メッセージを発行しても、その宛先はノード１ｆへと届くように、各ノード１内のオブジェクトＩＤ転送テーブル１１が修正される。
【０１１５】
図３０は、図１８のシステムにおける図２６とは別の経路修正を示す構成図である。図２６，図２７の古い経路情報の修正判定処理（Ｓ５０１）では、一例として、名前解決テーブル１２内のデータ更新（新規登録ではなく既存エントリへの書き換えが発生した場合）をもとに、修正要否を判定していた。
【０１１６】
一方、同じノード１ｆが、新旧両方のエントリを有していない場合も存在する。図３０では、旧位置のオブジェクト登録メッセージが端末２ａ→ノード１ａ→ノード１ｂの順に通過し（Ｓ６０１）、新位置のオブジェクト登録メッセージが端末２ｄ→ノード１ｇ→ノード１ｆの順に通過する（Ｓ６０３）例を示す。この場合、ノード１ｆは、旧位置のオブジェクト登録メッセージが通過する経路上に位置していないので、旧位置のオブジェクト９ａのエントリ（旧エントリ）を知らない。よって、既存エントリへの書き換えの発生も検知できないので、経路修正メッセージを送信することが困難である。
【０１１７】
そこで、名前解決ノードであるノード１ｂ、ノード１ｆ間で、自身の持つエントリをお互いに交換するため、ノード１ｂは、Ｓ６０１で自身に登録されたオブジェクト９ａについて、その登録された旨（旧位置の通知）をノード１ｆに通知する（Ｓ６０２）。
このＳ６０２の通知メッセージにより、ノード１ｆは、ノード１ｂ内の登録内容を知ることができるので、既存エントリへの書き換えの発生も検知できるようになる。具体的には、ノード１ｆの名前解決テーブル検索部６７は、自身の名前解決テーブル１２内のエントリと、ノード１ｂから通知された名前解決テーブル１２内のエントリとを照合し、同じｏｉｄのエントリが双方の名前解決テーブル１２に存在するときには、既存エントリへの書き換えとして検知する。
【０１１８】
そして、ノード１ｆは、図２６では、自身を起点とした経路修正メッセージをｌｉｄ転送で送信していたが、その送信処理に代えて、旧エントリを有するノード１ｂに対して、経路修正メッセージの送信を依頼するための通知（経路修正の通知）を行う（Ｓ６０４）。
通知を受けたノード１ｂは、自身を起点とした経路修正メッセージをｏｉｄ転送でＳ６０１のオブジェクト登録メッセージとは逆方向に送信する（Ｓ６０５）。これにより、Ｓ６０１のオブジェクト登録メッセージの経路上に登録された古いエントリは、Ｓ６０５の経路修正メッセージによる新しいエントリによって修正（上書き）される。
【０１１９】
図３１は、図３０とは別の経路修正メッセージの送信依頼の形態である。図３０の経路修正の通知（Ｓ６０４）が、図３１の経路修正の通知（Ｓ６０４ｂ）へと置き換わっている。つまり、ノード１ｆは、オブジェクト登録メッセージの送信元である端末２ａに対して、経路修正メッセージの送信を依頼する。
これにより、Ｓ６０１のオブジェクト登録メッセージと、Ｓ６０５ｂの経路修正メッセージとが始点から終点まで同じ経路をたどることができるので、その経路に沿って旧エントリが新エントリへと修正される。
【０１２０】
なお、本発明は前記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、前記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。
また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。
また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。また、上記の各構成、機能、処理部、処理手段などは、それらの一部または全部を、例えば集積回路で設計するなどによりハードウェアで実現してもよい。
また、前記の各構成、機能などは、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。
【０１２１】
各機能を実現するプログラム、テーブル、ファイルなどの情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）などの記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤカード、ＤＶＤなどの記録媒体に置くことができる。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。
【符号の説明】
【０１２２】
１      ノード
２      端末
９      オブジェクト
１０    制御データ記憶部
１１    オブジェクトＩＤ転送テーブル
１２    名前解決テーブル
１３    ロケーションＩＤ転送テーブル
１４    格納データテーブル
２０    データ転送部
２１    データ送受信部
３０    データ記憶部
３１    データ格納部
４０    通信ＩＦ
５０    ネットワーク
６０    制御処理部
６１    ノード管理部
６２    オブジェクトＩＤ転送テーブル作成部
６３    オブジェクトＩＤ転送テーブル検索部
６４    ロケーションＩＤ転送テーブル作成部
６５    ロケーションＩＤ転送テーブル検索部
６６    名前解決テーブル作成部
６７    名前解決テーブル検索部
６８    格納データテーブル検索部
【図１】
0005924598.tif 000002
【図２】
0005924598.tif 000003
【図３】
0005924598.tif 000004
【図４】
0005924598.tif 000005
【図５】
0005924598.tif 000006
【図６】
0005924598.tif 000007
【図７】
0005924598.tif 000008
【図８】
0005924598.tif 000009
【図９】
0005924598.tif 000010
【図１０】
0005924598.tif 000011
【図１１】
0005924598.tif 000012
【図１２】
0005924598.tif 000013
【図１３】
0005924598.tif 000014
【図１４】
0005924598.tif 000015
【図１５】
0005924598.tif 000016
【図１６】
0005924598.tif 000017
【図１７】
0005924598.tif 000018
【図１８】
0005924598.tif 000019
【図１９】
0005924598.tif 000020
【図２０】
0005924598.tif 000021
【図２１】
0005924598.tif 000022
【図２２】
0005924598.tif 000023
【図２３】
0005924598.tif 000024
【図２４】
0005924598.tif 000025
【図２５】
0005924598.tif 000026
【図２６】
0005924598.tif 000027
【図２７】
0005924598.tif 000028
【図２８】
0005924598.tif 000029
【図２９】
0005924598.tif 000030
【図３０】
0005924598.tif 000031
【図３１】
0005924598.tif 000032