(57)【要約】【課題】ネットワークでアプリケーションを実行させるための通信技術に関し、データの転送遅延を減少させ、アプリ実行結果のレスポンスを速くする。【解決手段】  リクエスタ４０１又はそのエッジノードは、要求メッセージ４０７の送信時に、宛先ノードであるデータ−ａ保持ノード４０５までの経路上の中継ノード−Ａ  ４０２及び中継ノード−Ｂ  ４０３のうち、宛先近傍優先でアプリを実行させるか、リンク近傍優先でアプリを実行させるかを、“アプリ−１”の実行結果である出力データとその実行のために必要である入力データとでどちらが大きいかによって決定し、その決定を識別する情報を実行ポリシビットＰＬとして要求メッセージ４０７に設定する。【選択図】図４
2018014077.tif 000002
【特許請求の範囲】
【請求項１】
データ要求先ノードとリクエストノードの経路にあるアプリ実行可能ノードのうち、どのノードにアプリを実行させるかを、前記アプリの実行結果である出力データ量と前記アプリの実行のために必要である入力データ量とに基づいて決定する実行ノード決定手段と、
前記データ要求先ノード又は前記アプリ実行可能ノードに向けて通信される前記アプリの実行を要求する要求メッセージに、前記決定されたノードの識別情報を設定する要求メッセージ設定手段と、
を備える通信装置。 
【請求項２】
前記実行ノード決定手段は、前記データ要求先ノードに近いノードに前記アプリを実行させるか、前記リクエストノードに近いノードに前記アプリを実行させるかを示す実行ポリシを、前記アプリの実行結果である出力データ量と前記アプリの実行のために必要である入力データ量とでどちらが大きいかによって決定し、
前記要求メッセージ設定手段は、前記要求メッセージに、前記ノードの識別情報として少なくとも前記実行ポリシの識別情報を設定する、
請求項１に記載の通信装置。
【請求項３】
前記アプリ実行可能ノード及び前記データ要求先ノードは、前記要求メッセージ及び／又は該要求メッセージに対応する応答メッセージ中の前記ノードの識別情報に基づいて前記アプリを実行する、
請求項１又は２記載の通信装置。
【請求項４】
前記要求メッセージ及び該要求メッセージに対応する応答メッセージは更に、アプリ保持識別情報、及びアプリ実行可能識別情報を含み、
前記アプリ実行可能ノード及び／又は前記データ要求先ノードの各ノードは、自ノードでの前記アプリの保持状態及び／又は前記アプリを実行可能なリソースの保持状態に応じて、前記自ノードが中継する前記要求メッセージ中の前記アプリ保持識別情報及び／又は前記アプリ実行可能識別情報の各情報を順次設定し、前記応答メッセージ中の該各情報と前記ノードの識別情報の設定状態に基づいて前記アプリを実行し、該実行の結果を前記応答メッセージに加えて前記リクエストノードに返す、
請求項３記載の通信装置。
【請求項５】
前記要求メッセージ及び該要求メッセージに対応する応答メッセージは更に、分岐点情報と分岐モード情報とを含み、
前記経路上に単数または複数の分岐点ノードが存在する場合に、
前記アプリの特性と支配的な前記入力データの数に応じて、前記アプリの実行を分岐点ノードで行うか否かと、前記アプリ実行が分岐点ノードで行われる場合にいずれの分岐点ノードで行われるかと、を前記実行ノード決定手段は決定して、該決定結果を分岐モード情報として要求メッセージに格納し、
前記単数または複数の分岐点ノードのうちの少なくとも１つの分岐点ノードは、受け取った前記要求メッセージ中において前記分岐点情報を設定し、
前記アプリ実行可能ノード及び／又は前記データ要求先ノードの各ノードは、前記応答メッセージ中における、前記設定された分岐点情報と、前記分岐モード情報と、前記アプリ保持識別情報及び／又は前記アプリ実行可能識別情報と、前記ノードの識別情報との設定状態に基づいて前記アプリを実行する、請求項４に記載の通信装置。
【請求項６】
前記実行ノード決定手段は、前記分岐モード情報を、分岐点無しの場合と、前記アプリ実行を最初の前記分岐点ノードで行わせる場合と、前記アプリ実行を複数の分岐点ノードにより分担して行わせる場合とに応じて設定する、請求項５に記載の通信装置。
【請求項７】
前記アプリ実行可能ノード及び前記データ要求先ノードの各ノードは、自ノードから所定ホップ内に位置し前記経路上に無い近傍ノードを含む、請求項１乃至６の何れかに記載の通信装置。
【請求項８】
前記実行ノード決定手段は、前記アプリの種別毎に前記実行ポリシを登録した設定テーブルを記憶し、前記要求メッセージの通信時に、該要求メッセージが実行を要求するアプリの種別で前記設定テーブルにアクセスすることにより前記実行ポリシを決定する、請求項２乃至７の何れかに記載の通信装置。
【請求項９】
前記要求メッセージ設定手段は、前記アプリの実行に必要な要素オブジェクトのうち、最大サイズの、単数または複数の要素オブジェクトを探索し、該最大サイズの、単数または複数の要素オブジェクトを宛先として前記要求メッセージに設定する、請求項１乃至８の何れかに記載の通信装置。
【請求項１０】
データ要求先ノードとリクエストノードの経路あるいは経路近傍にあるアプリ実行可能ノードのうち、どのノードにアプリを実行させるかを、前記アプリの実行結果である出力データ量と前記アプリの実行のために必要である入力データ量とに基づいて決定する実行ノード決定手段と、
前記データ要求先ノード又は前記アプリ実行可能ノードに向けて通信される前記アプリの実行を要求する要求メッセージに、前記決定されたノードの識別情報を設定する要求メッセージ設定手段と、
を備え、
前記アプリ実行可能ノード及び前記データ要求先ノードは、前記要求メッセージ中の前記ノードの識別情報に基づいて前記アプリを実行する、
通信システム。
【請求項１１】
データ要求先ノードとリクエストノードの経路あるいは経路近傍にあるアプリ実行可能ノードのうち、どのノードにアプリを実行させるかを、前記アプリの実行結果である出力データ量と前記アプリの実行のために必要である入力データ量とに基づいて決定し、
前記データ要求先ノード又は前記アプリ実行可能ノードに向けて通信される前記アプリの実行を要求する要求メッセージに、前記決定されたノードの識別情報を設定し、
前記アプリ実行可能ノード及び前記データ要求先ノードにおいて、前記要求メッセージ中の前記ノードの識別情報に基づいて前記アプリを実行する、
通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
ネットワークでアプリケーション（以下、「アプリ」と記載）を実行させるための通信装置、システム、及び方法に関する。
【背景技術】
【０００２】
コンテンツを名前で指定して通信＆取得することができる、ＩＣＮ（Ｉｎｆｏｒｍａｔｉｏｎ−Ｃｅｎｔｒｉｃ  Ｎｅｔｗｏｒｋｉｎｇ）と呼ばれる、新しいネットワークアーキテクチャが注目されつつある。更に、このようなネットワークでのアプリの実行について、ＮＦＮ（Ｎａｍｅｄ  Ｆｕｎｃｔｉｏｎ  Ｎｅｔｗｏｒｋｉｎｇ）と呼ばれる方式が知られている。ＮＦＮでは、ネットワーク内でアプリ実行場所のノードが決定され、その決定されたノードへリクエストノードからアプリを実行するための要求が送られる。その決定されたノードは、要求で指定されたアプリとデータをネットワークから取得してそのアプリを実行し、実行結果をリクエストノードに返す。
【０００３】
ネットワークを介して分散配置されるソフトウェアの間でやり取りされるメッセージを配送するメッセージ配送方法に関し、効率的な知的分散環境を実現可能にする従来技術が知られている（例えば特許文献１）。ネットワークを介して分散配置されるソフトウェアの間でやり取りされるメッセージを配送するときに、メッセージに、メッセージの配送先情報とメッセージの指定する処理情報との対データの繋がりで定義されるサービスリストを付加する。配送先のソフトウェアにより処理を終了したサービスリスト部分を削除し、更に、必要に応じてサービスリストを書き換えつつ、サービスリストが付加されたメッセージをソフトウェアからソフトウェアへと配送していく。
【０００４】
また、クライアントからのファイル送信要求に対して複数のサーバを用いてリクエストの振り分けを行う場合、適切な振り分けができるようにする従来技術が知られている（例えば特許文献２）。処理決定部は、「ＲＴs1,c （ＦＳ）＜ＲＴs1,c （ＭＳr ）＋ＲＴc,s2 （ＭＳq ）＋ＲＴs2,c （ＦＳ）」により得られる各レスポンスに要する所用時間の比較をする。ＲＴa,b （Ｌ）は端末ａから端末ｂへサイズＬのファイルを送信する場合に要する転送予想時間である。ＦＳは転送すべきファイルのサイズ、ＭＳr はリダイレクションメッセージのサイズである。ＭＳq は、クライアントが他のサーバに対して再度送信するリクエストのファイルサイズである。
【０００５】
更に、ＩＰルーティング互換のためのネットワークノードの通信方法において、次のような従来技術が知られている（例えば特許文献３）。コンテンツの位置を示す第１情報とコンテンツを識別する第２情報とを含むコンテンツ名を含むパケットを生成するステップと、生成されたパケットを送信するステップとを有する。これにより、ＩＰネットワークとコンテンツ中心ネットワークとの間のパケットフォーマットを変換するためのゲートウェイを必要とせず、ＩＰのための一般的なパケットフォーマットが変換されることなくそのまま利用することを可能とする。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平１１−１７５４２１号公報
【特許文献２】特開２００１−２４３１４２号公報
【特許文献３】特表２０１６−５０２３４３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上述のＮＦＮにおいては、典型的には要求メッセージがネットワーク上に伝送される経路上の最初（又はリクエストノード近く）のＮＦＮノードが、アプリ実行可能ノードとしてアプリを実行する。このため、例えば画像解析アプリなどのように、アプリの出力データ（解析結果）よりもアプリやアプリへの入力データ（画像データ）の方が大きいアプリが実行される場合に、次のような問題が発生する。
【０００８】
アプリやデータを遠くのノードからアプリ実行可能ノードまで転送させなければならないことにより、アプリやデータの転送遅延が大きくなって、レスポンス時間（ユーザがアプリ実行要求を投げてからその応答を受け取るまでの時間）が遅くなるという問題がある。
【０００９】
そこで、本発明の１つの側面では、データの転送遅延を減少させ、アプリ実行結果のレスポンスを速くすることを目的とする。
【課題を解決するための手段】
【００１０】
態様の一例では、通信装置は、実行ノード決定手段と要求メッセージ設定手段とを備える。実行ノード決定手段は、データ要求先ノードとリクエストノードの経路にあるアプリ実行可能ノードのうち、どのノードにアプリを実行させるかを、アプリの実行結果である出力データ量とアプリの実行のために必要である入力データ量とに基づいて決定する。要求メッセージ設定手段は、データ要求先ノード又はアプリ実行可能ノードに向けて通信されるアプリの実行を要求する要求メッセージに、決定されたノードの識別情報を設定する。
【発明の効果】
【００１１】
データの転送遅延を減少させ、アプリ実行結果のレスポンスを速くすることが可能となる。
【図面の簡単な説明】
【００１２】
【図１】ＩＣＮの特徴を表す図である。
【図２】ＮＦＮの基本モデルを表す図である。
【図３】ＮＦＮでのアプリ実行の制御を表す図である。
【図４】アプリ実行を行う通信システムの第１の実施形態の説明図（第１の実施形態の第１の動作例を表す説明図）である。
【図５】アプリ実行を行う通信システムの第２の実施形態の説明図である。
【図６】第１又は第２の実施形態に係るアプリ実行を行う通信システムの構成例を表す図である。
【図７】ノードを構成する通信装置のハードウェア構成例を表す図である。
【図８】第１又は第２の実施形態に係るアプリ実行を行う通信システムで通信される要求メッセージ及び応答メッセージのフォーマット例を表す図である。
【図９】ＰＬ設定テーブルの構成例を示す図である。
【図１０】第１又は第２の実施形態に係るアプリ実行を行う通信システムにおける中継ノードのメッセージ転送処理例を示すフローチャートである。
【図１１】第１の実施形態の第１の動作例のシーケンスを表す図である。
【図１２】第１の実施形態の第２の動作例を表す説明図である。
【図１３】第１の実施形態の第２の動作例を表すシーケンス図である。
【図１４】第１の実施形態の第３の動作例を表す説明図である。
【図１５】第１の実施形態の第３の動作例を表すシーケンス図である。
【図１６】第１の実施形態の第４の動作例を表す説明図である。
【図１７】第１の実施形態の第４の動作例を表すシーケンス図である。
【図１８】第１の実施形態の第５の動作例を表す説明図である。
【図１９】第１の実施形態の第５の動作例を表すシーケンス図である。
【図２０】第１の実施形態の第６の動作例を表す説明図である。
【図２１】第１の実施形態の第６の動作例を表すシーケンス図である。
【図２２】第１の実施形態の第７の動作例を表す説明図である。
【図２３】第１の実施形態の第７の動作例を表すシーケンス図である。
【図２４】第２の実施形態の動作例を表すシーケンス図である。
【図２５】第３の実施形態のアプリ実行を説明するためのネットワーク図である。
【図２６】第３の実施形態の基本方針を説明するためのネットワーク図である。
【図２７】第３の実施形態のメッセージフォーマットを表す図である。
【図２８】第３の実施形態の実施例その１を説明するためのシステムの概略図である。
【図２９】第３の実施形態の実施例その１のシステム動作を表す図である。
【図３０】第３の実施形態の実施例その１のシーケンスを表す図である。
【図３１】第３の実施形態の各ノードの処理フローを表す図である。
【図３２】第３の実施形態の実施例その２を説明するためのシステムの概略図である。
【図３３】第３の実施形態の実施例その２のシステム動作を表す図である。
【図３４】第３の実施形態の実施例その２(a)のシーケンスを表す図である。
【図３５】第３の実施形態の実施例その２(b)のシーケンスを表す図である。
【発明を実施するための形態】
【００１３】
以下、本発明を実施するための形態について図面を参照しながら説明する。
【００１４】
まず、図１は、ＩＣＮの特徴を表す図である。ＩＣＮでは、コンテンツを名前で指定できる、ネットワークのノードがキャッシュを持つ、などの特徴がある。図１において、リクエストノード（以下、「リクエスタ」と記載）１０２は、コンテンツの要求メッセージであるＩｎｔｅｒｅｓｔ  １０６を、ＩＣＮ１００に送信する。要求メッセージＩｎｔｅｒｅｓｔ  １０６では、コンテンツは、例えば「／ｆｊ／ｖｉｄｅｏ１」のような形式で指定される。ＩＣＮ１００を構成する複数のノード１０３のうちの一つのノードは、要求メッセージＩｎｔｅｒｅｓｔ  １０６を受信すると、ＩＣＮ１００に接続され要求で指定されたコンテンツ（例えば「／ｆｊ／ｖｉｄｅｏ１」）を保持するサーバ１０４から、該コンテンツを取得する。ここで、コンテンツとは、データ、アプリ、又はアプリ実行結果を含む。そのノードは、取得したコンテンツ（例えば「／ｆｊ／ｖｉｄｅｏ１」）を処理し、その処理結果を含む応答メッセージＤａｔａ  １０８を、要求元のリクエスタ１０２に返送する。
【００１５】
ここで特に、ＩＣＮ１００（内のノード）でのアプリ実行（Ｉｎ−ｎｅｔｗｏｒｋ  ｐｒｏｃｅｓｓｉｎｇ）を指定及び実施できるようにＩＣＮ１０２を拡張したものとして、ＮＦＮ（Ｎａｍｅｄ  Ｆｕｎｃｔｉｏｎ  Ｎｅｔｗｏｒｋｉｎｇ）が知られている。図２は、ＮＦＮの基本モデルを表す図である。ＮＦＮ２００では、次のような手順でアプリ実行が実施される。
【００１６】
ステップＳ２０１：処理の要求（実行場所の特定及び要求の送付）。ＮＦＮ２００は、リクエスタ（図示せず）からの要求メッセージを、アプリ実行場所のノード２０１へ転送する。アプリ実行場所としては、アプリのある所、データのある所、その他の所（例えば空サーバ）などから選択される。要求メッセージは例えば、“Ｉｎｔｅｒｅｓｔ（Ｆｕｎｃ（Ｄａｔａ_ｉｎ））”というフォーマットを有する。このフォーマットは、「“Ｄａｔａ_ｉｎ”を入力データとして、アプリ“Ｆｕｎｃ”を実行し、その結果を返せ」という意味である。
【００１７】
ステップＳ２０２、Ｓ２０３：アプリ／データの取得。特定されたアプリ実行場所のノード２０１のＣＰＵ（中央演算処理装置）は、アプリ保持ノード２０２に、別の要求メッセージ“Ｉｎｔｅｒｅｓｔ（Ｆｕｎｃ）”を送信することにより、アプリ保持ノード２０２からアプリ“Ｆｕｎｃ”を取得する（ステップＳ２０２）。同様に、ノード２０１のＣＰＵは、データ保持ノード２０３に、更に別の要求メッセージ“Ｉｎｔｅｒｅｓｔ（Ｄａｔａ＿ｉｎ）”を送信することにより、データ保持ノード２０３からデータ“Ｄａｔａ＿ｉｎ”を取得する（ステップＳ２０３）。
【００１８】
ステップＳ２０４：処理の実行。アプリ実行場所のノード２０１のＣＰＵは、データ保持ノード２０３から取得したデータ“Ｄａｔａ＿ｉｎ”を入力として、アプリ保持ノード２０２から取得したアプリ“Ｆｕｎｃ”を実行し、実行結果“Ｄａｔａ_ｏｕｔ”を出力する。
【００１９】
ステップＳ２０５：結果の送付。アプリ実行場所のノード２０１のＣＰＵは、実行結果“Ｄａｔａ_ｏｕｔ”を、応答メッセージとして要求元へ返す。
なお、ＮＦＮにおける前提として、以下を想定する。
・アプリ実行には、アプリとデータが必要。アプリ及びデータはそれぞれ、複数が可能である。以下、アプリとデータを総称して、「要素オブジェクト」と呼ぶ。
・要素オブジェクトは、ＮＦＮ２００ネットワーク内の適切な箇所（ノード）に分散配備されており、ノード間をダイナミックに移動できる。
・アプリ実行の結果として、入力データとは別のデータが出力され応答される。
・ＮＦＮ２００のネットワークは大規模で、全てのノードの状態を１箇所でリアルタイムに集中管理するのは困難である。
・対象とするアプリは、ファイヤウォールやフィルタリング等のネットワークアプリ、データ解析アプリや画像解析アプリ等のユーザアプリの双方を含む。なお、これらのアプリはバイトコード（例えばＪａｖａ（登録商標））の形で実装され、プラットフォーム非依存であるとともに、ノード間での移動が可能である。
【００２０】
図３は、以上の前提に基づくＮＦＮ３００でのアプリ実行の制御を表す図である。図３では、アプリを実行するのに、アプリ−１、データ−ａ、データ−ｂが必要な場合を表している。この場合、次のような手順でアプリ実行が行われる。
【００２１】
＜手順１＞：サービス実行の要求者であるリクエスタ３０１は、アプリ実行を要求する要求メッセージ３０７を、データ（またはアプリ）に向かって投げる。図３では、要求メッセージ３０７は例えば、名前“データ−ａ＋アプリ−１＋データ−ｂ”により指定される。この場合、要求メッセージ３０７は、指定内容の先頭の名前“データ−ａ”が示す要素オブジェクトに向かって投げられる。なお、要求メッセージ３０７をどの要素オブジェクトに向かって投げるかは、リクエスタ３０１が要求メッセージ３０７の名前で特定する。図３において、要求メッセージ３０７の伝達経路は、実線の矢印線で示される。
【００２２】
＜手順２＞：経路上のＮＦＮノード（アプリ実行可能なノード）３０２、３０３等のうちの何れかが、アプリ実行を行う。典型的には、経路上の最初のＮＦＮノード（図３におけるＮＦＮノード−Ａ  ３０２）がアプリ実行場所となる。例えば、ＮＦＮノード−Ａ  ３０２は、要求メッセージ３０７で指定された必要なアプリとデータを、ＮＦＮノード−Ｂ  ３０３を介して、アプリ保持ノード３０４、データ保持ノード３０５、３０６から別途取得して、アプリ実行を行い、その結果を応答メッセージ３０８として、リクエスタ３０１に返す。この応答メッセージ３０８は、要求メッセージ３０７で指定された名前“データ−ａ＋アプリ−１＋データ−ｂ”と、アプリの実行結果とを含む。図３において、アプリ保持ノード３０４、データ保持ノード３０５、３０６からＮＦＮノード−Ａ  ３０２への応答メッセージや、ＮＦＮノード−Ａ  ３０２からリクエスタ３０１への応答メッセージ３０８の伝達経路は、破線の矢印線で示される。
【００２３】
図３に示されるアプリ実行手法では、典型的には経路上の最初（又はリクエスタ３０１の近く）のＮＦＮノード−Ａ  ３０２がアプリ実行を行う。このため、例えば画像解析アプリなどのように、アプリの出力データ（解析結果）よりもアプリやアプリへの入力データ（画像データ）の方が大きいアプリが実行される場合に、次のような問題が発生する。
【００２４】
アプリやデータを遠くのノードからアプリ実行可能ノードまで転送させなければならないことにより、アプリやデータの転送遅延が大きくなって、レスポンス時間（ユーザがアプリ実行要求を投げてからその応答を受け取るまでの時間）が遅くなる。
【００２５】
また、常に経路上の最初（又はリクエストノードの近く）のＮＦＮノードと、経路上の他のＮＦＮノードとの間で、アプリ実行場所（アプリの実行負荷）をバランスすることができない。
【００２６】
アプリの実行を経路上の最初のＮＦＮノードに限定せず、或るポリシに従って他のロジックにより実行場所を決めることも考えられる。しかしながら、ポリシの決め方によって（例えばポリシが宛先の直近のノードを指定した場合）、単独のノードでは、場所の判断ができずに、アプリの実行を制御できないことがある。
【００２７】
以下に説明する各実施形態は、上述の問題を解決する。まず、第１の実施形態におけるアプリ実行の基本方針（アプローチ）は、次の通りである。
【００２８】
＜アプローチ１＞
アプリへの入力データと出力データのサイズの関係、すなわち入力データ量と出力データ量の関係に応じて、
出力データ＜Σ（入力データ）なら、宛先の近傍（リクエスタから遠く）で、
出力データ＞Σ（入力データ）なら、リクエスタの近傍で、
それぞれアプリを実行させる。ここで、「Σ（入力データ）」は、複数あり得る入力データのサイズの合計を意味する。
【００２９】
＜アプローチ２＞
更に、アプリ実行場所の決定に各ノードのリソースの状態を反映させ、アプローチ１で特定した場所を中心に、ノード間で負荷をバランスさせる。ここで、「リソース」とは例えば、指定されたアプリを実行可能なプロセッサ、メモリなどのハードウェア資源、及び／又は指定されたアプリを実行可能なソフトウェア環境をいう。
【００３０】
すなわち、アプリ特性（アプローチ１）と各ノードのリソース状態（アプローチ２）により、各ノードがローカルに得られる情報からアプリ実行の可否を判断し、アプリ実行場所を動的に決定する。
【００３１】
図４は、上記基本方針に基づいてアプリ実行を行う通信システムの第１の実施形態の説明図である。図４の通信システム４００では、図３の場合と同様に、アプリを実行するのに、アプリ−１、データ−ａ、データ−ｂが必要な場合を表している。この場合、次のような手順でアプリ実行が行われる。
【００３２】
＜手順１＞
送信されるアプリの実行を要求する要求メッセージ４０７では、図３の要求メッセージ３０７と同様の名前“データ−ａ＋アプリ−１＋データ−ｂ”が指定される。この要求メッセージ４０７は、特定の要素オブジェクト（アプリ  ｏｒ  データ）に向けて送信される。図４の例では、図３の場合と同様に、要求メッセージ４０７は、名前指定“データ−ａ＋アプリ−１＋データ−ｂ”の先頭の名前“データ−ａ”に対応する要素オブジェクトに向かって投げられる。
【００３３】
更に、第１の実施形態では、要求メッセージ４０７に、図４の破線枠４０９のように、実行ポリシビットＰＬ（実行ポリシ識別情報）、アプリ保持ビットＡＨ（アプリ保持識別情報）、及びアプリ実行可能ビットＡＥ（アプリ実行可能識別情報）が付加される。少なくとも実行ポリシ識別情報は、ノードの識別情報として設定される。
【００３４】
アプリの特性に応じて、リクエスタ４０１或いはエッジノード（リクエスタ４０１を収容するネットワークの入口のノード）は、要求メッセージ４０７の実行ポリシビットＰＬを宛先近傍優先（＝１）か、リクエスタ近傍優先（＝０）か、に設定する。アプリの特性とは、前述の＜アプローチ１＞で説明したように、アプリへの入力データと出力データのサイズの関係である。
【００３５】
すなわち、「出力データ＜Σ（入力データ）」なら、アプリが宛先の近傍（リクエスタから遠く）のノードで実行されるように、実行ポリシビットＰＬが宛先近傍優先（＝１）にセットされる。
【００３６】
逆に、「出力データ＞Σ（入力データ）」なら、アプリがリクエスタ４０１の近傍のノードで実行されるように、実行ポリシビットＰＬがリクエスタ近傍優先（＝０）にセットされる。
【００３７】
図４では、実行ポリシビットＰＬには、宛先近傍優先を示す値１がセットされている。
【００３８】
＜手順２＞
経路上の中継ノード−Ａ  ４０２や中継ノード−Ｂ  ４０３は、経路上にない近傍ノードも含めて、要求メッセージ４０７で指定されたアプリ（以下、「指定アプリ」と記載）を持っているか、アプリ実行のリソースを持っているか、に応じて、以下の動作を実行する。中継ノード−Ａ  ４０２や中継ノード−Ｂ  ４０３は、自ノードが受信し転送する要求メッセージ４０７のアプリ保持ビットＡＨ、及び／又はアプリ実行可能ビットＡＥに順次値１をセットする。
【００３９】
＜手順３＞
宛先のデータ−ａ保持ノード４０５は、受信した要求メッセージ４０７に、要求されている要素オブジェクトである”データ−ａ”本体を付加し、それらを応答メッセージ４０８として、要求メッセージ４０７の経路の逆経路に沿って返送する。
【００４０】
＜手順４＞
中継ノード−Ａ  ４０２や中継ノード−Ｂ  ４０３は、応答メッセージ４０８を受信すると、次の動作を実行する。中継ノード−Ａ  ４０２や中継ノード−Ｂ  ４０３は、要求メッセージ４０７を転送したときと応答メッセージ４０８を受信したときとで、実行ポリシビットＰＬ、アプリ保持ビットＡＨ、及びアプリ実行可能ビットＡＥの値を比較し、自ノードの動作を自律的に決定する。中継ノード−Ａ  ４０２や中継ノード−Ｂ  ４０３のそれぞれで自律的に決定された動作に基づいて、アプリ実行場所が、最大サイズの要素オブジェクトのある宛先ノード、リクエスタ４０１の場所／経路上で宛先ノードまたはリクエスタの近くのノード、経路上ではないがその近傍ノード、の優先順で決定される。後述するように、要求メッセージ４０７と応答メッセージ４０８のアプリ保持ビットＡＨ及びアプリ実行可能ビットＡＥにより、経路上での自ノードの相対的な位置がわかる。それらのビットと宛先の近くでアプリ実行すべきか、リクエスタ４０１の近くでアプリ実行すべきかを示す実行ポリシビットＰＬを考慮して、中継ノード−Ａ  ４０２及び中継ノード−Ｂ  ４０３等の各ノードが、アプリ実行の可否を自律的に決める。図４の例では、中継ノード−Ｂ  ４０３自身が、経路上で宛先（データ−ａ保持ノード４０５） に一番近く、アプリを実行するリソースを持つノードとして、アプリを実行すると決定する。中継ノード−Ｂ  ４０３は、要求メッセージ４０７が指定する“アプリ−１”と、“データ−ａ”及び“データ−ｂ”の各本体をそれぞれ、“アプリ−１”保持ノード４０４、データ−ａ保持ノード４０５、及びデータ−ｂ保持ノード４０６から取得してアプリ実行を行う。中継ノード−Ｂ  ４０３は、アプリの実行結果を応答メッセージ４０８に付加して、新たな応答メッセージ４０９として返送する。
【００４１】
図５は、アプリ実行を行う通信システムの第２の実施形態の説明図である。図５の通信システム４００は、図４の第１の実施形態の拡張型であり、宛先の要素オブジェクトの決め方を追加した上で、第１の実施形態の手法を行うものである。この場合、次のような手順でアプリ実行が行われる。なお、図５において、図４の場合と同じ参照番号を付した各部は、図４の場合と同じものを指すものとする。
【００４２】
＜手順１＞
図５（ａ）の５０１のように、通信システム４００上で、リクエスタ４０１は、アプリ保持ノード４０４、データ−ａ保持ノード４０５、及びデータ−ｂ保持ノード４０６の各々に対して、アプリ実行に必要な要素オブジェクト（アプリ、データ）のサイズを探索する。その結果、リクエスタ４０１は、最大サイズの要素オブジェクトを特定する（以下、「特定オブジェクト」と記載）。図５（ａ）の例では、アプリ保持ノード４０４、データ−ａ保持ノード４０５、及びデータ−ｂ保持ノード４０６はそれぞれ、リクエスタ４０１からのサイズ探索要求に応じて、「１０ｋＢ（キロバイト）」「１ＭＢ（メガバイト）」「５ｋＢ」のサイズを応答する。これを受け手、リクエスタ４０１は、「１ＭＢ」を応答したデータ−ａ保持ノード４０５を、特定オブジェクトとして特定する。
【００４３】
＜手順２＞
図５（ｂ）の５０２として示されるように、リクエスタ４０１は、要求メッセージの宛先を特定オブジェクトとして投げ 、以下各ノードは図４の第１の実施形態と同様の処理を行う。
【００４４】
＜手順３＞
その結果、アプリ実行は次の優先順で実行される。アプリ実行を行うと判断したノードが、その場で他の要素オブジェクトを取得し、アプリ実行して結果を返す。
優先順位１：特定オブジェクトのあるノード。
優先順位２：特定オブジェクトに至る経路上のノード。
優先順位３：経路上のノードの近傍ノード（経路上にないもの）。
【００４５】
以上のようにして、アプリの特性と各ノードのリソース状態に応じて、宛先またはリクエスタの場所／経路上で宛先ノードまたはリクエスタの近くのノード／宛先ノードまたはリクエスタの近傍のノードでアプリが実行され、次に、経路上やその近傍を含む、アプリを実行するリソースのあるノード（特定のノードに限定しない）でアプリが実行される。ここで、「近傍」とは例えば、対象となるノードから経路上のノードを除くｋホップ以内に存在するノードをいう。
【００４６】
図６は、上述の第１又は第２の実施形態に係るアプリ実行を行う通信システム４００の構成例を表す図である。この通信システム４００は、リクエスタ４０１、中継ノード−Ａ  ４０２、中継ノード−Ｂ  ４０３、“アプリ−１”保持ノード４０４、データ−ａ保持ノード４０５、及びデータ−ｂ保持ノード４０６の６つのノードから構成され、ネットワークを構成する。初期状態として、“アプリ−１”本体が“アプリ−１”保持ノード４０４に、“データ−ａ”本体がデータ−ａ保持ノード４０５、“データ−ｂ”本体がデータ−ｂ保持ノード４０６に配備され、アプリを実行するためにはこれらの要素オブジェクトが必要となる。リクエスタ４０１は、このアプリの実行要求を発行する。
【００４７】
図７は、図６の４０１から４０６の何れかのノードを構成する通信装置のハードウェア構成例を表す図である。ノードは、ハードウェア的には汎用サーバであり、図７に示されるように、プロセッサ７０１、メモリ７０２、記憶装置７０３、送受信インタフェース（データ通信用）７０４、及び送受信インタフェース（管理用）７０５が、バス７０６により相互に接続される。記憶装置７０３は、例えばハードディスク記憶装置である。送受信インタフェース（データ通信用）７０４は、例えばノードをＬＡＮ（ローカルエリアネットワーク）に接続するためのハードウェアである。送受信インタフェース（管理用）７０５は、例えばノードを管理サーバが接続される保守用ネットワークに接続するためのハードウェアである。ノードは、メモリ７０２又は記憶装置７０３に配備されたプログラムをプロセッサ７０１が実行することで、プログラムとして定義された動作を行うものである。
【００４８】
図８は、第１又は第２の実施形態に係るアプリ実行を行う通信システム４００で通信される要求メッセージ４０７及び応答メッセージ４０８、４０９のフォーマット例を表す図である。
【００４９】
図８（ａ）に示されるように、要求メッセージ４０７は、実行ポリシビットＰＬ、アプリ保持ビットＡＨ、及びアプリ実行可能ビットＡＥを有するヘッダ部と、Ｎａｍｅ部とから成る。それぞれの定義は、以下の通りである。
【００５０】
・実行ポリシビットＰＬ（ＰｏＬｉｃｙ）：０又は１の値をとるビットである。遅延や転送量の観点から、対象のアプリが、リクエスタ４０１の近くで実行する方が有利か（ＰＬ＝０）、リクエスタ４０１の遠く（＝アプリやデータの近く）で実行する方が有利か（ＰＬ＝１）、を示す。対象のアプリの特性から、前者は、アプリに対して入力データ量＜出力データ量の場合（例えばデータの単純マージ）に判定され、後者はその逆の場合（例えば画像解析）に判定される。リクエスタ４０１が要求メッセージを送出する時、或いはエッジノードが要求メッセージを中継する時に、上述の判定結果に基づいて、実行ポリシビットＰＬがセットされる。
【００５１】
・アプリ保持ビットＡＨ（ＡｐｐＨｏｌｄ）：０又は１の値をとるビットである。要求メッセージ４０７のＮａｍｅ部（図８（ａ））で指定されるアプリを、何れかのノードが持っていないか（ＡＨ＝０）、持っているか（ＡＨ＝１）、を示す。リクエスタ４０１自身が、まずアプリの保有状況に応じて、要求メッセージ４０７のアプリ保持ビットＡＨに値を設定し、その要求メッセージ４０７を送出する。そして、経路上のノードが、（近傍も含めて）指定アプリを持っていれば、受信した要求メッセージ４０７のアプリ保持ビットＡＨに値１をセットし、指定アプリを持っていなければ、そのビットの値は変更しない。
【００５２】
・アプリ実行可能ビットＡＥ（ＡｐｐＥｘｅｃ）：０か１の値をとるビットである。要求メッセージ４０７のＮａｍｅ部で指定されるアプリを実行するリソース（ＣＰＵやメモリ）を、何れかのノードが持っていないか（ＡＥ＝０）、持っているか（ＡＥ＝１）、を示す。リクエスタ４０１自身が、まずアプリを実行するリソースの保有状況に応じて、要求メッセージ４０７のアプリ実行可能ビットＡＥに値を設定し、その要求メッセージ４０７を送出する。そして、経路上のノードが、（近傍も含めて）リソースを持っていれば、受信した要求メッセージ４０７のアプリ実行可能ビットＡＥに値１をセットし、リソースを持っていなければ、そのビットの値は変更しない。
【００５３】
・Ｎａｍｅ部：要求しようとするアプリ実行を指定する、可変長のフィールドである。アプリを実行するのに必要な要素オブジェクト（アプリ、データ）の名前文字列が”+”で連結されて、Ｎａｍｅ部に表示される。例えば、Ｎａｍｅ部は、“データ−ａ＋アプリ−１＋データ−ｂ”と表記される。Ｎａｍｅ部に表記される“データ−ａ”、“アプリ−１”、及び“データ−ｂ”は、それぞれの要素オブジェクトの名前である。要求メッセージ４０７は、Ｎａｍｅ部の先頭の名前（この場合は“データ−ａ”）に対応する要素オブジェクトに向かってルーティングされる。事前に、各要素オブジェクトの存在場所から、各要素オブジェクトに対応するルーティング情報が、ネットワーク内でブロードキャストされ、各ノードは要素オブジェクトの名前に対するルーティングテーブルを構成する。各ノードは、要求メッセージ４０７の受信時に、Ｌｏｎｇｅｓｔ  Ｐｒｅｆｉｘ  ＭａｔｃｈによりＮａｍｅ部の先頭の要素オブジェクトに対する出力インタフェースを決定し、受信した要求メッセージ４０７をその出力インタフェースにルーティングする。
【００５４】
次に、図８（ｂ）に示されるように、応答メッセージ４０８、４０９は、実行ポリシビットＰＬ、アプリ保持ビットＡＨ、及びアプリ実行可能ビットＡＥを有するヘッダ部と、Ｎａｍｅ部と、Ｃｏｎｔｅｎｔ部とから成る。Ｃｏｎｔｅｎｔ部以外の意味は、図８（ａ）の要求メッセージ４０７と同様である。ただし、アプリ保持ビットＡＨ及びアプリ実行可能ビットＡＥは、各ノードがあらためてセットするのではなく、宛先ノードにおいて要求メッセージからコピーされる。アプリ保持ビットＡＨ及びアプリ実行可能ビットＡＥは、途中のノードでアプリを実行した時のみ０にリセットされて次のノードに渡される。また、応答メッセージ４０８、４０９のルーティングは、Ｎａｍｅ部によるのではなく、各ノードが、その応答メッセージ４０８、４０９に対応する要求メッセージ４０７の送信元を覚えておいて、その送信元へ送る。Ｃｏｎｔｅｎｔ部の定義は、以下の通りである。
【００５５】
・Ｃｏｎｔｅｎｔ部：要求されたアプリの実行結果、或いは要素オブジェクト（アプリ、データ）が格納される、可変長のフィールドである。ノードにおいて、アプリ実行前は、Ｃｏｎｔｅｎｔ部には、要素オブジェクトの本体が格納される。例えば、図４の応答メッセージ４０８においては、Ｃｏｎｔｅｎｔ部には、データ−ａ保持ノード４０５で格納された要素オブジェクト“データ−ａ”が格納される。アプリ実行後には、Ｃｏｎｔｅｎｔ部には、アプリの実行結果が格納される。例えば、図４の応答メッセージ４０９の場合である。
【００５６】
図９は、実行ポリシビットＰＬを設定するためのＰＬ設定テーブルの構成例を示す図である。図４の第１の実施形態の＜手順１＞で説明したように、要求メッセージ４０７には、図４の破線枠４０９のように、実行ポリシビットＰＬ、アプリ保持ビットＡＨ、及びアプリ実行可能ビットＡＥが付加される。このとき、アプリの特性において、前述の手順に従って宛先近傍優先（＝１）かリクエスタ近傍優先（＝０）かがセットされる。この実行ポリシビットＰＬは、前述したように、リクエスタ４０１或いはエッジノードによって設定される。ここで、多くのアプリにおいて、上述の「Σ（入力データ）」と「出力データ」とのサイズの大小関係は予め推定することができ、従って実行ポリシビットＰＬの値も予め推定できる。そこで、本実施形態では例えば、アプリ毎に実行ポリシビットＰＬの値を１にするか０にするかを決定するための図９に示されるＰＬ設定テーブルを、リクエスタ４０１又はエッジノードに備える。リクエスタ４０１又はエッジノードは、実行を要求するアプリ毎に、自ノードが例えば図７のメモリ７０２又は記憶装置７０３に記憶している図９のＰＬ設定テーブルを参照することにより、要求メッセージ４０７に付加する実行ポリシビットＰＬの値を決定する。
【００５７】
図９の例では、アプリが画像解析アプリである場合は、入力データは画像データで、出力データは画像解析結果であるため、「出力データ＜Σ（入力データ）」である。この場合には、例えば画像データである“データ−ａ”本体を保持するデータ−ａ保持ノード４０５の近傍（リクエスタ４０１から遠く）の例えば中継ノード−Ｂ  ４０３でアプリが実行された方が、“データ−ａ”本体の転送距離が短くなり、アプリの実行効率が良い。従って、図９のＰＬ設定テーブルにおいて、画像解析アプリに対しては実行ポリシビットＰＬの値は１が記憶される。
【００５８】
また、アプリが地図検索アプリである場合は、入力データは緯度経度データや地点を表す文字列キーワードで、出力データは地図データであるため、「出力データ＞Σ（入力データ）」である。この場合には、出力データであるアプリの実行結果を受信するリクエスタ４０１の近傍の例えば中継ノード−Ａ  ４０２でアプリが実行された方が、出力データの転送距離が短くなり、アプリの実行効率が良い。従って、図９のＰＬ設定テーブルにおいて、地図検索アプリに対しては実行ポリシビットＰＬの値は０が記憶される。
【００５９】
更に、アプリがセンサデータ分析アプリである場合は、入力データはセンサデータで、出力データは分析結果であるため、一般に「出力データ＜Σ（入力データ）」である。この場合には、例えばセンサデータである“データ−ａ”本体を保持するデータ−ａ保持ノード４０５の近傍（リクエスタ４０１から遠く）の例えば中継ノード−Ｂ  ４０３でアプリが実行された方が、“データ−ａ”本体の転送距離が短くなり、アプリの実行効率が良い。従って、図９のＰＬ設定テーブルにおいて、センサデータ分析アプリに対しては実行ポリシビットＰＬの値は１が記憶される。
【００６０】
図１０は、前述した第１又は第２の実施形態に係るアプリ実行を行う通信システム４００における中継ノード−Ａ  ４０２又は中継ノード−Ｂ  ４０３のメッセージ転送処理例を示すフローチャートである。このメッセージ転送処理は例えば、中継ノード−Ａ  ４０２又は中継ノード−Ｂ  ４０３を構成する図７のプロセッサ７０１が、例えば記憶装置７０３からロードされてメモリ７０２に記憶されているメッセージ転送処理プログラムを実行する動作である。
【００６１】
まず、プロセッサ７０１は、メッセージを受信した時、そのメッセージ種別の判定を行う（ステップＳ１００１）。メッセージ種別は例えば、別途ヘッダ等で定義し判別する。
【００６２】
ステップＳ１００１の判定において、受信したメッセージが要求メッセージ４０７である場合には、プロセッサ７０１はまず、要求メッセージ４０７のＮａｍｅ部（図８（ａ）参照）で指定されたアプリを自ノードが持っているかをチェックする（ステップＳ１００２）。
【００６３】
ステップＳ１００２の判定がＹＥＳならば、プロセッサ７０１は、受信し転送する要求メッセージ４０７のアプリ保持ビットＡＨに値１をセットする。また、プロセッサ７０１は、アプリ保持ビットＡＨをセットしたこと、及びＡＨを最初に値０から値１にセットした（受信した要求メッセージ４０７のＡＨが０で自ノードがＡＨを１に書き替えた）か否かを、メモリ７０２に記録する（以上、ステップＳ１００３）。
【００６４】
ステップＳ１００２の判定がＮＯならば、プロセッサ７０１は、上記ステップＳ１００３の処理はスキップし、要求メッセージ４０７のヘッダ部のＡＨビット値は書き換えない。
【００６５】
次に、プロセッサ７０１は、要求メッセージ４０７のＮａｍｅ部（図８（ａ）参照）で指定されたアプリ実行に対するリソースを自ノードが持っているかをチェックする（ステップＳ１００４）。ここで、「リソース」とは例えば、指定されたアプリを実行可能なプロセッサ７０１、メモリ７０２などのハードウェア資源、及び／又は指定されたアプリを実行可能なソフトウェア環境をいう。
【００６６】
ステップＳ１００４の判定がＹＥＳならば、プロセッサ７０１は、受信し転送する要求メッセージ４０７のアプリ実行可能ビットＡＥに値１をセットする。また、プロセッサ７０１は、アプリ実行可能ビットＡＥをセットしたこと、及びＡＥを最初に値０から値１にセットした（受信した要求メッセージ４０７のＡＥが０で、自ノードがＡＥを１に書き替えた）か否かを、メモリ７０２に記録する（以上、ステップＳ１００５）。
【００６７】
ステップＳ１００４の判定がＮＯならば、プロセッサ７０１は、上記ステップＳ１００５の処理はスキップし、要求メッセージ４０７のヘッダ部のＡＥビット値は書き換えない。
【００６８】
以上のステップＳ１００２からＳ１００５までの一連の制御処理の後、プロセッサ７０１は、受信した要求メッセージ４０７を、Ｎａｍｅ部の先頭の要素オブジェクトを宛先として、次のノードに転送する（ステップＳ１００６）。そして、プロセッサ７０１は、図１０のフローチャートで示されるメッセージ転送処理を終了する。
【００６９】
ステップＳ１００１の判定において、受信したメッセージが応答メッセージ４０８、４０９である場合には、プロセッサ７０１はまず、応答メッセージ４０８、４０９のヘッダ部の各ビットの値をチェックすることにより、以下のステップＳ１００７からＳ１０１０までの一連の判定処理を実行する。
【００７０】
まず、プロセッサ７０１は、実行ポリシビットＰＬの値が１で、かつアプリ保持ビットＡＨの値が１で、かつ自ノードがアプリ保持ビットＡＨを１にセットしたことがメモリ７０２に記憶されているか否かを判定する（ステップＳ１００７）。なお、図１０中では、「かつ」は、「＆」記号で示され、論理積を表す。
【００７１】
プロセッサ７０１は、ステップＳ１００７の判定がＹＥＳならば、ステップＳ１０１１の処理に移行して、アプリ実行処理を行う。
【００７２】
プロセッサ７０１は、ステップＳ１００７の判定がＮＯならば、実行ポリシビットＰＬの値が１で、かつアプリ実行可能ビットＡＥの値が１で、かつ自ノードがアプリ実行可能ビットＡＥを１にセットしたことがメモリ７０２に記憶されているか否かを判定する（ステップＳ１００８）。
【００７３】
プロセッサ７０１は、ステップＳ１００８の判定がＹＥＳならば、ステップＳ１０１１の処理に移行して、アプリ実行処理を行う。
【００７４】
後述するように、宛先の例えばデータ−ａ保持ノード４０５は、要求メッセージ４０７のヘッダ部の各ビット値をそのまま有する応答メッセージ４０８を、転送経路と逆経路に返送する。中継ノード−Ａ  ４０２、中継ノード−Ｂ  ４０３、及びデータ−ａ保持ノード４０５等の各ノードは、各要求メッセージ４０７をどのノードから受信したかを記憶しておく。各ノードは、応答メッセージ４０８、４０９を受信したときに、それに対応する要求メッセージ４０７について記憶していた発信元のノードに、受信した応答メッセージ４０８、４０９を転送する。この結果、応答メッセージ４０８、４０９は、それに対応する要求メッセージ４０７が中継されてきた転送経路と逆経路に中継されてゆくことになる。そしてステップＳ１００７又はＳ１００８で、例えば中継ノード−Ｂ  ４０３が最初に、応答メッセージ４０８のＡＨ又はＡＥの値が１で、かつ自ノードでのＡＨ又はＡＥの値の記録が１であると判定すれば、自ノードは宛先ノードに最も近いアプリ実行可能ノードとなる。従ってこの場合に、応答メッセージ４０８、４０９の実行ポリシビットＰＬの値が宛先近傍優先の値１に設定されていれば、自ノードである中継ノード−Ｂ  ４０３が、アプリ実行処理を行うべきノードであると判定できる。このときの判定の優先順位として、まず自ノードがアプリを保持しているか否かが判定され（ステップＳ１００７）、次に自ノードがアプリ実行に対するリソースを持っているか否かが判定される（ステップＳ１００８）。
【００７５】
ステップＳ１００８の判定がＮＯならば、プロセッサ７０１は、実行ポリシビットＰＬの値が０で、かつアプリ保持ビットＡＨの値が１で、かつ自ノードがアプリ保持ビットＡＨを最初に１にセットしたことがメモリ７０２に記憶されているか否かを判定する（ステップＳ１００９）。
【００７６】
プロセッサ７０１は、ステップＳ１００９の判定がＹＥＳならば、ステップＳ１０１１の処理に移行して、アプリ実行処理を行う。
【００７７】
プロセッサ７０１は、ステップＳ１００９の判定がＮＯならば、実行ポリシビットＰＬの値が０で、かつアプリ実行可能ビットＡＥの値が１で、かつ自ノードがアプリ実行可能ビットＡＥを最初に１にセットしたことがメモリ７０２に記憶されているか否かを判定する（ステップＳ１０１０）。
【００７８】
プロセッサ７０１は、ステップＳ１０１０の判定がＹＥＳならば、ステップＳ１０１１の処理に移行して、アプリ実行処理を行う。
【００７９】
ステップＳ１００９又はＳ１０１０で、例えば中継ノード−Ａ  ４０２が、応答メッセージ４０８のＡＨ又はＡＥの値が１で、かつ自ノードが最初にＡＨ又はＡＥをセットしたと判定すれば、自ノードはリクエスタ４０１に最も近いアプリ実行可能ノードとなる。従ってこの場合に、応答メッセージ４０８、４０９の実行ポリシビットＰＬの値がリクエスタ近傍優先の値０に設定されていれば、自ノードである中継ノード−Ａ  ４０２が、アプリ実行処理を行うべきノードであると判定できる。このときの判定の優先順位として、まず自ノードがアプリを保持しているか否かが判定され（ステップＳ１００９）、次に自ノードがアプリ実行に対するリソースを持っているか否かが判定される（ステップＳ１０１０）。
【００８０】
以上のステップＳ１００７からＳ１０１０の一連の判定の何れかＹＥＳとなった場合、プロセッサ７０１は、アプリ実行処理を行う（ステップＳ１０１１）。
【００８１】
ステップＳ１０１１において、プロセッサ７０１は、別要求メッセージにより、自ノードが保持していないアプリ実行に必要な他の要素オブジェクトを取得し、アプリ実行を行う。すなわち、プロセッサ７０１は、受信した応答メッセージ４０８、４０９のＮａｍｅ部で指定されている要素オブジェクト群“アプリ−１”、“データ−ａ”、“データ−ｂ”などのうち、自ノードが保持していない要素オブジェクトについて、以下の処理を実行する。プロセッサ７０１は、その要素オブジェクトがＮａｍｅ部に指定された要求メッセージを作成して、ネットワークに送信する。この結果、プロセッサ７０１は、その要素オブジェクトを宛先とする“アプリ−１”保持ノード４０４、データ−ａ保持ノード４０５、又はデータ−ｂ保持ノード４０６（図４参照）などから、その要素オブジェクトを取得する。
【００８２】
ステップＳ１０１１において、プロセッサ７０１は、アプリ実行が完了すると、次のような応答メッセージ４０９を生成する。この応答メッセージ４０９において、プロセッサ７０１は、他のノードがアプリを実行しないように、ヘッダ部のアプリ保持ビットＡＨ及びアプリ実行可能ビットＡＥの値を共に０にリセットし、Ｃｏｎｔｅｎｔ部（図８（ｂ）参照）にアプリ実行結果を格納する。
【００８３】
上述のステップＳ１０１１の処理の後、プロセッサ７０１は、生成した応答メッセージ４０９を、その応答メッセージ４０９のヘッダ部と同じヘッダ部を有する要求メッセージ４０７を受信した方向のノードに向けて転送する（ステップＳ１０１２）。
【００８４】
前述のステップＳ１０１０の判定がＮＯとなった場合には、プロセッサ７０１は、受信した応答メッセージ４０８、４０９をそのまま、その応答メッセージ４０９のヘッダ部と同じヘッダ部を有する要求メッセージ４０７を受信した方向のノードに向けて転送する（ステップＳ１０１２）。
【００８５】
その後、プロセッサ７０１は、図１０のフローチャートで示されるメッセージ転送処理を終了する。
【００８６】
図７から図９の構成と図１０のメッセージ転送処理に基づく第１の実施形態の７つの動作例について、以下に説明する。
【００８７】
まず、第１の実施形態における第１の動作例について、前述した図４の説明図及び図１１のシーケンス図を用いて説明する。図４及び図１１に示される第１の動作例は、実行ポリシビットＰＬが１にセットされ、中継ノード−Ｂ  ４０３のみにアプリ実行に対するリソースがある場合の例である。
【００８８】
＜動作パターン１＞
リクエスタ４０１は、実行しようとするアプリの特性から、図９のＰＬ設定テーブルを参照することにより、送信する要求メッセージ４０７の実行ポリシビットＰＬの値を０又は１に設定する。なお、前述したように、実行ポリシビットＰＬの設定は、リクエスタ４０１ではなく、エッジノードに当たる中継ノード−Ａ  ４０２（図６参照）が行ってもよい。リクエスタ４０１は、要求メッセージ４０７のＮａｍｅ部が示す宛先（先頭のオブジェクト、Ｒｏｕｔａｂｌｅ  Ｐｒｅｆｉｘ ）が要素オブジェクト（アプリ又はデータ）の１つになるように構成し、その要求メッセージ４０７を送信する。
【００８９】
図４及び図１１の第１の動作例では、実行を行うべきアプリは、例えば画像解析アプリ又はセンサデータ分析アプリのように、「出力データ＜Σ（入力データ）」である場合である。この結果、リクエスタ４０１は、図９のＰＬ設定テーブルを参照することにより、送信する要求メッセージ４０７の実行ポリシビットＰＬに、宛先近傍優先を表す値１を設定する。次に、図４の第１の動作例では、リクエスタ４０１は、要求メッセージ４０７のＮａｍｅ部として名前“データ−ａ＋アプリ−１＋データ−ｂ”を設定する。この結果、宛先ノードは、Ｎａｍｅ部の先頭の名前“データ−ａ”に対応する“データ−ａ”本体を保持するデータ−ａ保持ノード４０５となる。このようにして、リクエスタ４０１は、前述した＜動作パターン１＞に従って、ＰＬ＝１、ＡＨ＝０、ＡＥ＝０とし、Ｎａｍｅ部に“データ−ａ＋アプリ−１＋データ−ｂ”を格納した要求メッセージ４０７を生成する（図１１のＳ１１０１）。そして、リクエスタ４０１は、前述した＜動作パターン１＞に従って、生成した要求メッセージ４０７を中継ノード−Ａ  ４０２に転送する（Ｓ１１０２）。なお、図１１中では、Ｎａｍｅ部に“データ−ａ＋アプリ−１＋データ−ｂ”が格納された要求メッセージ４０７を、「要求（ａ＋１＋ｂ）」と簡略化して表記している。
【００９０】
要求メッセージ４０７を受信した宛先ノードに至る経路上の中継ノード−Ａ  ４０２及び中継ノード−Ｂ  ４０３はそれぞれ、図１０のフローチャートのステップＳ１００１からＳ１００６の一連の制御動作に従って、前述したメッセージ転送処理を次のように実行する。
【００９１】
＜動作パターン２＞
中継ノードは、近傍ノード（太線矢印）も含めて、要求メッセージ４０７での指定アプリを持っていれば、図１０のステップＳ１００１→Ｓ１００２の判定がＹＥＳ→Ｓ１００３→Ｓ１００６の制御を実行する。この結果、中継ノードは、要求メッセージ４０７のアプリ保持ビットＡＨをオンに（値１にセット）し、ＡＨ＝１をセットしたこと、及び最初にＡＨ＝１をセットしたか否かを、メモリ７０２に記憶する。その後、中継ノードは、要求メッセージ４０７を転送する。
【００９２】
＜動作パターン３＞
中継ノードは、近傍ノード（太線矢印）も含めて、指定アプリはないがその実行のリソースがあれば、図１０のステップＳ１００１→Ｓ１００２の判定がＮＯ→Ｓ１００４の判定がＹＥＳ→Ｓ１００５→Ｓ１００６の制御を実行する。この結果、中継ノードは、要求メッセージ４０７のアプリ実行可能ビットＡＥをオンにし、ＡＥ＝１をセットしたこと、及び最初にＡＥ＝１をセットしたか否かを、メモリ７０２に記憶する。その後、中継ノードは、要求メッセージ４０７を転送する。
【００９３】
＜動作パターン４＞
中継ノードは、近傍ノード（太線矢印）も含めて、指定アプリ及びその実行のリソース共に無ければ、図１０のステップＳ１００１→Ｓ１００２の判定がＮＯ→Ｓ１００４の判定がＮＯ→Ｓ１００６の制御を実行する。この結果、中継ノードは、要求メッセージ４０７をそのまま転送する。
【００９４】
以上の動作２、３、又は４において、各ノードは、自ノードの「近傍」として、自ノードのｋホップ以内を探索するか、事前に調べて情報を持っておく。
【００９５】
図４及び図１１の第１の動作例では、中継ノード−Ａ  ４０２は、指定アプリである“アプリ−１”もその実行のリソースも持っていない。このため、中継ノード−Ａ  ４０２は、前述した＜動作パターン４＞に従い、要求メッセージ４０７のアプリ保持ビットＡＨ及びアプリ実行可能ビットＡＥの両方とも値０のままとして、要求メッセージ４０７を中継ノード−Ｂ  ４０３に中継する（図１１のＳ１１０３）。
【００９６】
次に、中継ノード−Ｂ  ４０３は、“アプリ−１”は持っていないがその実行のリソースを持っている。このため、中継ノード−Ｂ  ４０３は、前述した＜動作パターン３＞に従って、要求メッセージ４０７中のアプリ実行可能ビットＡＥをオンする（値１に書き換える）。また、中継ノード−Ｂ  ４０３は、ＡＥ＝１をセットしたこと、及び最初にＡＥ＝１をセットしたことを、メモリ７０２に記憶する（以上、図１１のＳ１１０４）。そして、中継ノード−Ｂ  ４０３は、その要求メッセージ４０７を、データ−ａ保持ノード４０５に転送する（図１１のＳ１１０５）。
【００９７】
宛先ノード（図４の例ではデータ−ａ保持ノード４０５）は、要求メッセージ４０７のヘッダの各ビットを判定して、次のように動作する。
【００９８】
＜動作パターン５＞
宛先ノードが、要求メッセージ４０７での指定アプリを保持しているかその実行のリソースを持っていれば、自ノードが指定アプリを実行する。この結果、宛先ノードは、アプリ実行結果を応答メッセージ４０８のＣｏｎｔｅｎｔ部（図８（ｂ）参照）に格納し、その応答メッセージ４０８を、それに対応する要求メッセージ４０７の経路と逆の経路に中継する。このとき、宛先ノードは、応答メッセージ４０８のヘッダ部のアプリ保持ビットＡＨ及びアプリ実行可能ビットＡＥをクリア（値０に）する。
【００９９】
＜動作パターン６＞
宛先ノードが、要求メッセージ４０７での指定アプリもその実行のリソースも持っていない場合で、要求メッセージ４０７のアプリ保持ビットＡＨ又はアプリ実行可能ビットＡＥがオンならば、次の動作を実行する。宛先ノードは、応答メッセージ４０８を作成し、そのヘッダ部に要求メッセージ４０７のＰＬ、ＡＨ、ＡＥの各ビット値をコピーするとともに、Ｃｏｎｔｅｎｔ部に“データ−ａ”本体を格納する。そして、宛先ノードは、その応答メッセージ４０８を、それに対応する要求メッセージ４０７の経路と逆の経路に返送する。
【０１００】
＜動作パターン７＞
宛先ノードが、要求メッセージ４０７での指定アプリもその実行のリソースも持っていない場合で、かつ要求メッセージ４０７のアプリ保持ビットＡＨ及びアプリ実行可能ビットＡＥが共にオフ（値０）ならば、次の動作を実行する。宛先ノードは、エラー（アプリ実行不可）を、応答メッセージ４０８のＣｏｎｔｅｎｔ部に格納し、その応答メッセージ４０８を、それに対応する要求メッセージ４０７の経路と逆の経路に返送する。
【０１０１】
図４及び図１１の第１の動作例は、宛先ノードであるデータ−ａ保持ノード４０５が要求メッセージ４０７での指定アプリもその実行のリソースも持っていない場合で、かつ要求メッセージ４０７のアプリ実行可能ビットＡＥのみがオンの場合である。従って、データ−ａ保持ノード４０５は、前述した＜動作パターン６＞に従って、、以下の動作を実行する。データ−ａ保持ノード４０５は、応答メッセージ４０８を作成し、そのヘッダ部に要求メッセージ４０７のＰＬ、ＡＨ、ＡＥの各ビット値をコピーするとともに、Ｃｏｎｔｅｎｔ部に“データ−ａ”本体を格納する（図１１のＳ１１０６）。そして、データ−ａ保持ノード４０５は、その応答メッセージ４０８を、中継ノード−Ｂ  ４０３に転送する（図１１のＳ１１０７）。なお、図１１中では、Ｎａｍｅ部に名前“データ−ａ＋アプリ−１＋データ−ｂ”が格納され、Ｃｏｎｔｅｎｔ部に“データ−ａ”本体が格納された応答メッセージ４０８を、「応答（ａ＋１＋ｂ，データ−ａ）」と簡略化して表記している。
【０１０２】
宛先ノードから応答メッセージ４０８を受信した経路上の中継ノードは、図１０のフローチャートのステップＳ１００１→Ｓ１００７からＳ１０１２の一連の制御動作に従って、前述したメッセージ転送処理を次のように実行する。
【０１０３】
＜動作パターン８＞
応答メッセージ４０８のヘッダ部のＰＬビット＝１（宛先近傍優先）で、かつＡＨ又はＡＥの何れかのビットがオンで、更に、近傍も含めて自ノードが、ＡＨ又はＡＥビットをオンにしている場合は、中継ノードは、次の動作を実行する。中継ノードは、図１０のステップＳ１００７又はＳ１００８の何れかの判定がＹＥＳとなることにより、ステップＳ１０１１を実行する。この条件は、応答メッセージ４０８のＮａｍｅ部で指定されたアプリ又はその実行のリソースを持っている中継ノードのうち、宛先のノードから送られてきた応答メッセージ４０８を最初に受信した宛先のノードに最も近い場所のノードにおいて成立する。一方、応答メッセージ４０８のヘッダ部のＰＬビット＝０（リクエスタ近傍優先）で、かつＡＨ又はＡＥの何れかのビットがオンで、更に、近傍も含めて自ノードが、ＡＨ又はＡＥビットを“最初に”オンにしている場合は、中継ノードは、次の動作を実行する。中継ノードは、図１０のステップＳ１００７及びＳ１００８の判定がＮＯ、続いてステップＳ１００９又はＳ１０１０の何れかの判定がＹＥＳとなることにより、ステップＳ１０１１を実行する。この条件は、応答メッセージ４０８のＮａｍｅ部で指定されたアプリ又はその実行のリソースを持っている中継ノードのうち、宛先のノードから送られてきた応答メッセージ４０８を最後に受信するリクエスタ４０１のノードに最も近い場所のノードにおいて成立する。上記何れかの条件の成立により、中継ノードは、図１のステップＳ１０１１で、別要求メッセージにより自ノードが保持していないアプリ実行に必要な他の要素オブジェクトを取得し、アプリ実行を行う。中継ノードは、アプリ実行が完了すると、新たに応答メッセージ４０９を生成する。中継ノードは、生成した応答メッセージ４０９において、他のノードがアプリを実行しないように、ヘッダ部のアプリ保持ビットＡＨ及びアプリ実行可能ビットＡＥの値を共に０にリセットし、Ｃｏｎｔｅｎｔ部にアプリ実行結果を格納する。その後、中継ノードは、図１０のステップＳ１０１２で、生成した応答メッセージ４０９を、そのヘッダ部と同じヘッダ部を有する要求メッセージ４０７の発信元（要求メッセージ４０７の経路と逆の経路）に中継する。
【０１０４】
＜動作パターン９＞
応答メッセージ４０８の判定において、上記＜動作パターン８＞以外の場合には、図１０のステップＳ１００７からＳ１０１０の全ての判定がＮＯとなる。この結果、中継ノードは、図１０のステップＳ１０１２で、応答メッセージ４０８をそのまま、そのヘッダ部と同じヘッダ部を有する要求メッセージ４０７の発信元（要求メッセージ４０７の経路と逆の経路）に中継する。
【０１０５】
図４及び図１１の第１の動作例では、中継ノード−Ｂ  ４０３に応答メッセージ４０８が到着した時に、そのＰＬビット＝１、そのＡＥビットがオンとなっており、かつ、中継ノード−Ｂ  ４０３はメモリ７０２にＡＥ＝１をセットしたことを記憶している。このため、中継ノード−Ｂ  ４０３は、前述の＜動作パターン８＞に従って、“アプリ−１”を実行すべきと判定する。中継ノード−Ｂ  ４０３はまず、Ｎａｍｅ部に自ノードが保持していない要素オブジェクトの１つに対応する名前“データ−ｂ”が格納された別の要求メッセージを生成し、その要求メッセージをネットワークに送信する（図１１のＳ１１０８）。なお、図１１では、この別要求メッセージを「要求（ｂ）」と簡略化して表記している。データ−ｂ保持ノード４０６は、この別要求メッセージに応答し、Ｃｏｎｔｅｎｔ部に“データ−ｂ”本体が格納された応答メッセージを中継ノード−Ｂ  ４０３に返送する（図１１のＳ１１０９）。なお、図１１では、この応答メッセージを「応答（ｂ）」と簡略化して表記している。同様に、中継ノード−Ｂ  ４０３は、Ｎａｍｅ部に自ノードが保持していない要素オブジェクトの１つに対応する名前“アプリ−１”が格納された別の要求メッセージを生成し、その要求メッセージをネットワークに送信する（図１１のＳ１１１０）。なお、図１１では、この別要求メッセージを「要求（１）」と簡略化して表記している。“アプリ−１”保持ノード４０４は、この別要求メッセージに応答し、Ｃｏｎｔｅｎｔ部に“アプリ−１”本体が格納された応答メッセージを中継ノード−Ｂ  ４０３に返送する（図１１のＳ１１１１）。なお、図１１では、この応答メッセージを「応答（１）」と簡略化して表記している。その後、中継ノード−Ｂ  ４０３は、応答メッセージ４０８に格納されている“データ−ａ”本体を取り出し、“データ−ａ”及び“データ−ｂ”を入力データとして“アプリ−１”本体が示すプログラムを実行する（図１１のＳ１１１２）。その結果、中継ノード−Ｂ  ４０３は、ヘッダ部でアプリ実行可能ビットＡＥを０にリセットし（アプリ保持ビットＡＨは元々０）、Ｃｏｎｔｅｎｔ部に実行結果を格納した新たな応答メッセージ４０９を生成する（図１１のＳ１１１３）。ＡＥ＝０とするのは、他のノードがアプリを実行しないようにするためである。そして、中継ノード−Ｂ  ４０３は、その応答メッセージ４０９を中継ノード−Ａ  ４０２に転送する（図１１のＳ１１１４）。なお、図１１では、この応答メッセージ４０９を「応答（ａ＋１＋ｂ，実行結果）」と簡略化して表記している。
【０１０６】
中継ノード−Ａ  ４０２では、受信した応答メッセージ４０９のヘッダ部のアプリ保持ビットＡＨ及びアプリ実行可能ビットＡＥが共にオフとなっており、かつ指定アプリである“アプリ−１”もその実行のリソースも持っていない。従って、中継ノード−Ａ  ４０２は、前述の＜動作パターン９＞に従って、受信した応答メッセージ４０９をそのまま、リクエスタ４０１に中継する（図１１のＳ１１１５）。
【０１０７】
リクエスタ４０１は、受信した応答メッセージ４０９のＣｏｎｔｅｎｔ部から、アプリの実行結果を取り出して受け取る。
【０１０８】
以上説明したようにして、第１の実施形態において、実行ポリシビットＰＬの値が１（宛先近傍優先）にセットされる場合、アプリ実行は下記の優先順位で行われる。
優先順位１：最大サイズの要素オブジェクトのあるノード。
優先順位２：その要素オブジェクトに至る経路上のノード（できる限り宛先の要素オブジェクトに近いノード）。
優先順位３：経路上のノードの近傍ノード（経路上にはないが、経路上のノードからホップ以内のノード）。
【０１０９】
次に、第１の実施形態における第２の動作例について、図１２の説明図及び図１３のシーケンス図を用いて説明する。図１２及び図１３に示される第２の動作例は、実行ポリシビットＰＬが１にセットされ、中継ノード−Ａ  ４０２のみにアプリ実行のリソースがある場合の例である。図１３での簡略化表記のしかたは、図１１の第１の動作例の場合と同様である。
【０１１０】
まず、リクエスタ４０１は、前述した＜動作パターン１＞に従って、以下の制御動作を実行する。図１２の第２の動作例では、図４の第１の動作例の場合と同様に、実行を行うべきアプリは、例えば画像解析アプリ又はセンサデータ分析アプリのように、「出力データ＜Σ（入力データ）」である場合である。この結果、リクエスタ４０１は、前述した＜動作パターン１＞に従って、以下の制御動作を実行する。リクエスタ４０１は、図９のＰＬ設定テーブルを参照することにより、送信する要求メッセージ４０７の実行ポリシビットＰＬに、宛先近傍優先を表す値１を設定する。また、リクエスタ４０１は、要求メッセージ４０７のＮａｍｅ部として名前“データ−ａ＋アプリ−１＋データ−ｂ”を設定する（以上、図１３のＳ１３０１）。そして、リクエスタ４０１は、このようにして生成した要求メッセージ４０７を中継ノード−Ａ  ４０２に送信する（図１３のＳ１３０２）。
【０１１１】
宛先ノードに至る経路上の中継ノード−Ａ  ４０２及び中継ノード−Ｂ  ４０３はそれぞれ、第１の動作例の説明で前述した＜動作パターン２＞、＜動作パターン３＞、又は＜動作パターン４＞に従って、メッセージ転送処理を実行する。
【０１１２】
図１２及び図１３の第２の動作例では、中継ノード−Ａ  ４０２は、“アプリ−１”は持っていないがその実行のリソースを持っている。このため、中継ノード−Ａ  ４０２は、前述した＜動作パターン３＞に従い、以下の制御動作を実行する。中継ノード−Ａ  ４０２は、要求メッセージ４０７中のアプリ実行可能ビットＡＥをオンする。また、中継ノード−Ａ  ４０２は、この要求メッセージ４０７に対してＡＥ＝１をセットしたこと、及び最初にＡＥ＝１としたことを、メモリ７０２（図７）に記憶しておく（以上、図１３のＳ１３０３）。そして、中継ノード−Ａ  ４０２は、その要求メッセージ４０７を、中継ノード−Ｂ  ４０３に転送する（図１３のＳ１３０４）。
【０１１３】
次に、中継ノード−Ｂ  ４０３は、指定アプリである“アプリ−１”もその実行のリソースも持っていない。このため、中継ノード−Ｂ  ４０３は、前述した＜動作パターン４＞に従って、ＡＨ及びＡＥの値を変更せずにそのまま、要求メッセージ４０７をデータ−ａ保持ノード４０５に転送する（図１３のＳ１３０５）。
【０１１４】
宛先ノードであるデータ−ａ保持ノード４０５は、要求メッセージ４０７が指定する“アプリ−１”もその実行のリソースも持っておらず、かつ要求メッセージ４０７のアプリ実行可能ビットＡＥのみがオンである。従って、データ−ａ保持ノード４０５は、図４の第１の動作例と同様に、前述した＜動作パターン６＞に従って、以下の動作を実行する。データ−ａ保持ノード４０５は、応答メッセージ４０８を作成し、そのヘッダ部に要求メッセージ４０７のＰＬ、ＡＨ、ＡＥの各ビット値をコピーするとともに、Ｃｏｎｔｅｎｔ部に“データ−ａ”本体を格納する（図１３のＳ１３０６）。そして、データ−ａ保持ノード４０５は、その応答メッセージ４０８を、中継ノード−Ｂ  ４０３に転送する（図１３のＳ１３０７）。
【０１１５】
データ−ａ保持ノード４０５から応答メッセージ４０８、４０９を受信した経路上の中継ノードは、第１の動作例の説明で前述した＜動作パターン８＞又は＜動作パターン９＞に従って、応答メッセージ４０８、４０９の転送処理／アプリ実行処理を実行する。
【０１１６】
中継ノード−Ｂ  ４０３では、受信した応答メッセージ４０９において、ＰＬ＝１、ＡＥ＝１であるが、近傍も含めて自ノードが応答メッセージ４０８のＮａｍｅ部で指定された“アプリ−１”及びその実行のリソースの何れも持っていない。従って、中継ノード−Ｂ  ４０３は、前述した＜動作パターン９＞に従って、受信した応答メッセージ４０９をそのまま、中継ノード−Ａ  ４０２に中継する（図１３のＳ１３０８）。
【０１１７】
中継ノード−Ａ  ４０２では、応答メッセージ４０８が到着した時に、そのＰＬビット＝１で、そのＡＥビットがオンとなっており、かつ、中継ノード−Ａ  ４０２はメモリ７０２にＡＥ＝１をセットしたことを記憶している。このため、中継ノード−Ａ  ４０２は、前述の＜動作パターン８＞に従って、“アプリ−１”を実行すべきと判定する。この結果、中継ノード−Ａ  ４０２は、図１１の第１の動作例のＳ１１０８からＳ１１１１の一連の制御動作と同様にして、図１３のＳ１３０９からＳ１３１２の一連の制御動作を実行する。これにより、中継ノード−Ａ  ４０２は、別要求メッセージにより、自ノードが保持していない“アプリ−１”本体及び“データ−ｂ”本体をそれぞれ、中継ノード−Ｂ  ４０３を介して、“アプリ−１”保持ノード４０４及びデータ−ｂ保持ノード４０６から取得する。その後、中継ノード−Ａ  ４０２は、応答メッセージ４０８に格納されている“データ−ａ”本体を取り出し、“データ−ａ”及び“データ−ｂ”を入力データとして“アプリ−１”本体が示すプログラムを実行する（図１３のＳ１３１３）。その結果、中継ノード−Ａ  ４０２は、ヘッダ部でアプリ実行可能ビットＡＥを０にリセットし（アプリ保持ビットＡＨは元々０）、Ｃｏｎｔｅｎｔ部に実行結果を格納した新たな応答メッセージ４０９を生成する（図１３のＳ１３１４）。そして、中継ノード−Ａ  ４０２は、その応答メッセージ４０９をリクエスタ４０１に転送する（図１３のＳ１３１５）。
【０１１８】
最後に、リクエスタ４０１は、受信した応答メッセージ４０９のＣｏｎｔｅｎｔ部から、アプリの実行結果を受け取る。
【０１１９】
このように、図１２及び図１３の第２の動作例では、リクエスタ４０１が要求メッセージ４０７の送信時に実行ポリシビットＰＬ＝１（宛先優先）を指定している。しかし、何れの中継ノードも“アプリ−１”は保持しておらず、“アプリ−１”の実行のリソースを有する中継ノードは中継ノード−Ａ  ４０２のみである。従って、宛先ノードであるデータ−ａ保持ノード４０５からは遠い中継ノードではあるが、唯一“アプリ−１”を実行可能な中継ノード−Ａ  ４０２が、“アプリ−１”を実行することになる。
【０１２０】
次に、第１の実施形態における第３の動作例について、図１４の説明図及び図１５のシーケンス図を用いて説明する。図１４及び図１５に示される第３の動作例は、実行ポリシビットＰＬが１にセットされ、中継ノード−Ａ  ４０２及び中継ノード−Ｂ  ４０３の両方ともアプリ実行のリソースがある場合の例である。図１５での簡略化表記のしかたは、図１１の第１の動作例の場合等と同様である。
【０１２１】
まず、リクエスタ４０１は、前述した＜動作パターン１＞に従って、以下の制御動作を実行する。図１４及び図１５の第３の動作例では、図４及び図１１の第１の動作例の場合と同様に、実行を行うべきアプリは、例えば画像解析アプリ又はセンサデータ分析アプリのように、「出力データ＜Σ（入力データ）」である場合である。この結果、リクエスタ４０１は、図９のＰＬ設定テーブルを参照することにより、送信する要求メッセージ４０７の実行ポリシビットＰＬに、宛先近傍優先を表す値１を設定する。また、リクエスタ４０１は、要求メッセージ４０７のＮａｍｅ部として名前“データ−ａ＋アプリ−１＋データ−ｂ”を設定する（以上、図１５のＳ１５０１）。そして、リクエスタ４０１は、このようにして生成した要求メッセージ４０７を中継ノード−Ａ  ４０２に送信する（図１５のＳ１５０２）。
【０１２２】
宛先ノードに至る経路上の中継ノード−Ａ  ４０２及び中継ノード−Ｂ  ４０３はそれぞれ、第１の動作例の説明で前述した＜動作パターン２＞、＜動作パターン３＞、又は＜動作パターン４＞に従って、メッセージ転送処理を実行する。
【０１２３】
図１４の第３の動作例では、中継ノード−Ａ  ４０２は、“アプリ−１”は持っていないがその実行のリソースを持っている。このため、中継ノード−Ａ  ４０２は、前述した＜動作パターン３＞に従って、要求メッセージ４０７中のアプリ実行可能ビットＡＥをオンする。また、中継ノード−Ａ  ４０２は、この要求メッセージ４０７に対してＡＥ＝１をセットしたこと、及び最初にＡＥ＝１としたことを、メモリ７０２（図７）に記憶しておく。（以上、図１５のＳ１５０３）。そして、中継ノード−Ａ  ４０２は、その要求メッセージ４０７を、中継ノード−Ｂ  ４０３に転送する（図１５のＳ１５０４）。
【０１２４】
次に、中継ノード−Ｂ  ４０３も、中継ノード−Ａ  ４０２と同様に、“アプリ−１”は保持していないがその実行のリソースを持っているので、前述した＜動作パターン３＞に従って、以下の動作を行う。まず、中継ノード−Ｂ  ４０３も、要求メッセージ４０７中のアプリ実行可能ビットＡＥを上書きする。この場合、受信された要求メッセージ４０７のＡＥビットは既に値１になっているため、状態は変わらない。また、中継ノード−Ｂ  ４０３は、この要求メッセージ４０７に対してＡＥ＝１をセットしたことをメモリ７０２（図７）に記憶しておく。なお、受信された要求メッセージ４０７のＡＥビットは既に値１になっているため、中継ノード−Ｂ  ４０３は、最初にＡＥ＝１としたことは記憶しない（以上、図１５のＳ１５０５）。そして、中継ノード−Ｂ  ４０３は、その要求メッセージ４０７を、データ−ａ保持ノード４０５に転送する（図１５のＳ１５０６）。
【０１２５】
データ−ａ保持ノード４０５は、 “アプリ−１”及びその実行のリソース共に持っておらず、要求メッセージ４０７のアプリ実行可能ビットＡＥがオンなので、図４の第１の動作例等の場合と同様に、前述した＜動作パターン６＞に従って、以下の動作を実行する。データ−ａ保持ノード４０５は、そのヘッダ部に要求メッセージ４０７のＰＬ、ＡＨ、ＡＥの各ビット値がコピーされ、Ｃｏｎｔｅｎｔ部に“データ−ａ”本体が格納された応答メッセージ４０８を生成する（図１５のＳ１５０７）。そして、データ−ａ保持ノード４０５は、生成した応答メッセージ４０８を中継ノード−Ｂ  ４０３に返送する（図１５のＳ１５０８）。
【０１２６】
データ−ａ保持ノード４０５から応答メッセージ４０８、４０９を受信した経路上の中継ノードは、第１の動作例の説明で前述した＜動作パターン８＞又は＜動作パターン９＞に従って、応答メッセージ４０８、４０９の転送処理／アプリ実行処理を実行する。
【０１２７】
中継ノード−Ｂ  ４０３では、応答メッセージ４０８が到着した時に、その実行ポリシビットＰＬ＝１で、そのアプリ実行可能ビットＡＥがオンとなっており、かつ、中継ノード−Ｂ  ４０３はメモリ７０２にＡＥ＝１をセットしたことを記憶している。このため、中継ノード−Ｂ  ４０３は、図４の第１の動作例の場合と同様にして、前述の＜動作パターン８＞に従って、“アプリ−１”を実行すべきと判定する。この結果、中継ノード−Ｂ  ４０３は、図１１の第１の動作例のＳ１１０８からＳ１１１４の一連の動作と同様の、図１５のＳ１５０９からＳ１５１５の一連の動作を実行する。中継ノード−Ｂ  ４０３は、アプリ−１”、“データ−ａ”、“データ−ｂ”を取得しアプリ実行を行い、ＡＥ（とＡＨ）ビットが０にリセットされ、Ｃｏｎｔｅｎｔ部にアプリ実行結果が格納された応答メッセージ４０９を生成して中継ノード−Ａ  ４０２に中継する。
【０１２８】
中継ノード−Ａ  ４０２では、“アプリ−１”の実行のリソースは持っているが、“アプリ−１”は中継ノード−Ｂ  ４０３で実行済みで、受信した応答メッセージ４０９のヘッダ部のアプリ保持ビットＡＨ及びアプリ実行可能ビットＡＥが共にオフとなっている。従って、中継ノード−Ａ  ４０２は、前述の＜動作パターン９＞に従って、受信した応答メッセージ４０９をそのまま、リクエスタ４０１に中継する（図１５のＳ１５１６）。
【０１２９】
最後に、リクエスタ４０１は、受信した応答メッセージ４０９のＣｏｎｔｅｎｔ部から、アプリの実行結果を受け取る。
【０１３０】
このように、図１４及び図１５の第３の動作例では、リクエスタ４０１が要求メッセージ４０７の送信時に実行ポリシビットＰＬ＝１（宛先近傍優先）を指定している。このため、“アプリ−１”の実行のリソースを有する中継ノード−Ａ  ４０２と中継ノード−Ｂ  ４０３のうち、宛先ノードであるデータ−ａ保持ノード４０５に近い方の中継ノード−Ｂ  ４０３が、“アプリ−１”を実行することになる。
【０１３１】
次に、第１の実施形態における第４の動作例について、図１６の説明図及び図１７のシーケンス図を用いて説明する。図１６及び図１７に示される第４の動作例は、実行ポリシビットＰＬが０にセットされ、中継ノード−Ｂ  ４０３のみにアプリ実行のリソースがある場合の例である。図１７での簡略化表記のしかたは、図１１の第１の動作例の場合等と同様である。
【０１３２】
まず、リクエスタ４０１は、前述した＜動作パターン１＞に従って、以下の制御動作を実行する。図１６及び図１７の第４の動作例では、実行を行うべきアプリは、例えば地図検索アプリのように、「出力データ＞Σ（入力データ）」である場合である。この結果、リクエスタ４０１は、図９のＰＬ設定テーブルを参照することにより、送信する要求メッセージ４０７の実行ポリシビットＰＬに、リクエスタ近傍を表す値０を設定する。また、リクエスタ４０１は、要求メッセージ４０７のＮａｍｅ部として名前“データ−ａ＋アプリ−１＋データ−ｂ”を設定する（以上、図１７のＳ１７０１）。そして、リクエスタ４０１は、このようにして生成した要求メッセージ４０７を中継ノード−Ａ  ４０２に送信する（図１７のＳ１７０２）。
【０１３３】
宛先ノードに至る経路上の中継ノード−Ａ  ４０２及び中継ノード−Ｂ  ４０３はそれぞれ、第１の動作例の説明で前述した＜動作パターン２＞、＜動作パターン３＞、又は＜動作パターン４＞に従って、要求メッセージ４０７の転送処理を実行する。
【０１３４】
図１６及び図１７の第４の動作例では、中継ノード−Ａ  ４０２、中継ノード−Ｂ  ４０３、及びデータ−ａ保持ノード４０５での図１７のＳ１７０３からＳ１７０７までの一連の制御動作は、図１１の第１の動作例のＳ１１０３からＳ１１０７の一連の動作と同様である。
【０１３５】
データ−ａ保持ノード４０５から応答メッセージ４０８を受信した経路上の中継ノードは、第１の動作例の説明で前述した＜動作パターン８＞又は＜動作パターン９＞に従って、応答メッセージ４０８、４０９の転送処理、及び／又はアプリ実行処理を実行する。
【０１３６】
この場合、応答メッセージ４０８を受信した中継ノード−Ｂ  ４０３は、図１１の第１の動作例のＳ１１０８からＳ１１１４の一連の動作と同様の、図１７のＳ１７０８からＳ１７１４の一連の動作を実行する。中継ノード−Ｂ  ４０３は、アプリ−１”、“データ−ａ”、“データ−ｂ”を取得しアプリ実行を行い、ＡＥ（とＡＨ）ビットが０にリセットされ、Ｃｏｎｔｅｎｔ部にアプリ実行結果が格納された応答メッセージ４０９を生成して中継ノード−Ａ  ４０２に中継する。
【０１３７】
中継ノード−Ａ  ４０２は、受信した応答メッセージ４０９において、ＡＨ＝０、ＡＥ＝０であるので、図４の第１の動作例の場合と同様に、前述した＜動作パターン９＞に従って、応答メッセージ４０９をそのまま、リクエスタ４０１に転送する（図１７のＳ１７１５）。
【０１３８】
最後に、リクエスタ４０１は、受信した応答メッセージ４０９のＣｏｎｔｅｎｔ部から、アプリの実行結果を受け取る。
【０１３９】
このように、図１６及び図１７の第４の動作例では、リクエスタ４０１が要求メッセージ４０７の送信時に実行ポリシビットＰＬ＝０（リクエスタ近傍優先）を指定している。しかし、何れの中継ノードも“アプリ−１”は保持しておらず、“アプリ−１”の実行のリソースを有する中継ノードは中継ノード−Ｂ  ４０３のみである。従って、リクエスタ４０１からは遠い中継ノードではあるが、唯一“アプリ−１”を実行可能な中継ノード−Ｂ  ４０３が、“アプリ−１”を実行することになる。
【０１４０】
次に、第１の実施形態における第５の動作例について、図１８の説明図及び図１９のシーケンス図を用いて説明する。図１８及び図１９に示される第５の動作例は、実行ポリシビットＰＬが０にセットされ、中継ノード−Ａ  ４０２のみにアプリ実行のリソースがある場合の例である。図１９での簡略化表記のしかたは、図１１の第１の動作例の場合等と同様である。
【０１４１】
まず、リクエスタ４０１は、前述した＜動作パターン１＞に従って、以下の制御動作を実行する。図１８の第５の動作例では、図１６の第４の動作例の場合と同様に、実行を行うべきアプリは、例えば地図検索アプリのように、「出力データ＞Σ（入力データ）」である場合である。この結果、リクエスタ４０１は、図９のＰＬ設定テーブルを参照することにより、送信する要求メッセージ４０７の実行ポリシビットＰＬに、リクエスタ近傍を表す値０を設定する。また、リクエスタ４０１は、要求メッセージ４０７のＮａｍｅ部として名前“データ−ａ＋アプリ−１＋データ−ｂ”を設定する（以上、図１９のＳ１９０１）。そして、リクエスタ４０１は、前述した＜動作パターン１＞に従って、生成した要求メッセージ４０７を中継ノード−Ａ  ４０２に転送する（図１９のＳ１９０２）。
【０１４２】
宛先ノードに至る経路上の中継ノード−Ａ  ４０２及び中継ノード−Ｂ  ４０３はそれぞれ、第１の動作例の説明で前述した＜動作パターン２＞、＜動作パターン３＞、又は＜動作パターン４＞に従って、要求メッセージ４０７の転送処理を実行する。
【０１４３】
図１８及び図１９の第５の動作例では、中継ノード−Ａ  ４０２、中継ノード−Ｂ  ４０３、及びデータ−ａ保持ノード４０５でのＳ１９０３からＳ１９０７までの一連の制御動作は、図１３の第２の動作例のＳ１３０３からＳ１３０７の一連の動作と同様である。
【０１４４】
データ−ａ保持ノード４０５から応答メッセージ４０８を受信した経路上の中継ノードは、第１の動作例の説明で前述した＜動作パターン８＞又は＜動作パターン９＞に従って、応答メッセージ４０８、４０９の転送処理、及び／又はアプリ実行処理を実行する。
【０１４５】
中継ノード−Ｂ  ４０３は、受信した応答メッセージ４０９において、ＰＬ＝０、ＡＥ＝１であるが、近傍も含めて自ノードが、応答メッセージ４０８のＮａｍｅ部で指定されたアプリ及びその実行のリソースの何れも持っていない。このため、中継ノード−Ｂ  ４０３は、前述した＜動作パターン９＞に従って、応答メッセージ４０８をそのまま、中継ノード−Ａ  ４０２に転送する（図１９のＳ１９０８）。
【０１４６】
中継ノード−Ａ  ４０２は、図１３の第２の動作例のＳ１３０９からＳ１３１５の一連の動作と同様の、図１９のＳ１９０９からＳ１９１５の一連の動作を実行する。中継ノード−Ａ  ４０２は、アプリ−１”、“データ−ａ”、“データ−ｂ”を取得しアプリ実行を行い、ＡＥ（とＡＨ）ビットが０にリセットされ、Ｃｏｎｔｅｎｔ部にアプリ実行結果が格納された応答メッセージ４０９を生成してリクエスタ４０１に中継する。
【０１４７】
最後に、リクエスタ４０１は、受信した応答メッセージ４０９のＣｏｎｔｅｎｔ部から、アプリの実行結果を受け取る。
【０１４８】
次に、第１の実施形態における第６の動作例について、図２０の説明図及び図２１のシーケンス図を用いて説明する。図２０及び図２１に示される第６の動作例は、実行ポリシビットＰＬが０にセットされ、中継ノード−Ａ  ４０２及び中継ノード−Ｂ  ４０３の両方ともアプリ実行のリソースがある場合の例である。図２１での簡略化表記のしかたは、図１１の第１の動作例の場合等と同様である。
【０１４９】
まず、リクエスタ４０１は、前述した＜動作パターン１＞に従って、以下の制御動作を実行する。図２０及び図２１の第６の動作例では、図１６の第４の動作例等の場合と同様に、実行を行うべきアプリは、例えば地図検索アプリのように、「出力データ＞Σ（入力データ）」である場合である。この結果、リクエスタ４０１は、図９のＰＬ設定テーブルを参照することにより、送信する要求メッセージ４０７の実行ポリシビットＰＬに、リクエスタ近傍を表す値０を設定する。また、リクエスタ４０１は、要求メッセージ４０７のＮａｍｅ部として名前“データ−ａ＋アプリ−１＋データ−ｂ”を設定する（以上、図２１のＳ２１０１）。そして、リクエスタ４０１は、このようにして生成した要求メッセージ４０７を中継ノード−Ａ  ４０２に送信する（図２１のＳ２１０２）。
【０１５０】
宛先ノードに至る経路上の中継ノード−Ａ  ４０２及び中継ノード−Ｂ  ４０３はそれぞれ、第１の動作例の説明で前述した＜動作パターン２＞、＜動作パターン３＞、又は＜動作パターン４＞に従って、要求メッセージ４０７の転送処理を実行する。
【０１５１】
図２０及び図２１の第６の動作例では、中継ノード−Ａ  ４０２、中継ノード−Ｂ  ４０３、及びデータ−ａ保持ノード４０５でのＳ２１０３からＳ２１０８までの一連の制御動作は、図１５の第３の動作例のＳ１５０３からＳ１５０８の一連の動作と同様である。
【０１５２】
データ−ａ保持ノード４０５から応答メッセージ４０８を受信した経路上の中継ノードは、第１の動作例の説明で前述した＜動作パターン８＞又は＜動作パターン９＞に従って、応答メッセージ４０８、４０９の転送処理、及び／又はアプリ実行処理を実行する。
【０１５３】
中継ノード−Ｂ  ４０３は、データ−ａ保持ノード４０５から応答メッセージ４０８を受信すると、そのＰＬ＝０、ＡＥ＝１であり、かつ中継ノード−Ｂ  ４０３はメモリ７０２にＡＥ＝１をセットしたことを記憶している。しかし、中継ノード−Ｂ  ４０３は、メモリ７０２に最初にＡＥ＝１をセットしたことは記憶していない。従って、中継ノード−Ｂ  ４０３は、前述した＜動作パターン９＞に従って、応答メッセージ４０８をそのまま、中継ノード−Ａ  ４０２に転送する（図２１のＳ２１０９）。
【０１５４】
次に、中継ノード−Ａ  ４０２は、中継ノード−Ｂ  ４０３から応答メッセージ４０８を受信すると、そのＰＬ＝０、ＡＥ＝１であり、かつ中継ノード−Ａ  ４０２はメモリ７０２に最初にＡＥ＝１をセットしたことを記憶している。そこで、中継ノード−Ａ  ４０２は、前述した＜動作パターン８＞に従って、“アプリ−１”を実行すべきと判定する。この結果、中継ノード−Ａ  ４０２は、図１１の第１の動作例のＳ１３０９からＳ１３１５の一連の動作と同様の、図２１のＳ２１１０からＳ２１１６の一連の動作を実行する。中継ノード−Ａ  ４０２は、アプリ−１”、“データ−ａ”、“データ−ｂ”を取得しアプリ実行を行い、ＡＥ（とＡＨ）ビットが０にリセットされ、Ｃｏｎｔｅｎｔ部にアプリ実行結果が格納された応答メッセージ４０９を生成してリクエスタ４０１に中継する。
【０１５５】
最後に、リクエスタ４０１は、受信した応答メッセージ４０９のＣｏｎｔｅｎｔ部から、アプリの実行結果を受け取る。
【０１５６】
このように、図２０及び図１の第６の動作例では、リクエスタ４０１が要求メッセージ４０７の送信時に実行ポリシビットＰＬ＝０（リクエスタ近傍優先）を指定している。このため、“アプリ−１”の実行のリソースを有する中継ノード−Ａ  ４０２と中継ノード−Ｂ  ４０３のうち、リクエスタ４０１に近い方の中継ノード−Ａ  ４０２が、“アプリ−１”を実行することになる。
【０１５７】
次に、第１の実施形態における第７の動作例について、図２２の説明図及び図２３のシーケンス図を用いて説明する。図２２及び図２３に示される第７の動作例は、実行ポリシビットＰＬが１にセットされ、中継ノード−Ａ  ４０２はアプリを保持しておらずかつアプリ実行のリソースもなく、中継ノード−Ｂ  ４０３はアプリを保持している場合の例である。図２３での簡略化表記のしかたは、図１１の第１の動作例の場合等と同様である。
【０１５８】
まず、リクエスタ４０１は、前述した＜動作パターン１＞に従って、以下の制御動作を実行する。図２２及び図２３の第７の動作例では、実行を行うべきアプリは、例えば画像解析アプリ又はセンサデータ分析アプリのように、「出力データ＜Σ（入力データ）」である場合である。この結果、リクエスタ４０１は、図９のＰＬ設定テーブルを参照することにより、送信する要求メッセージ４０７の実行ポリシビットＰＬに、リクエスタ近傍を表す値１を設定する。また、リクエスタ４０１は、要求メッセージ４０７のＮａｍｅ部として名前“データ−ａ＋アプリ−１＋データ−ｂ”を設定する（以上、図２３のＳ２３０１）。そして、リクエスタ４０１は、このようにして生成した要求メッセージ４０７を中継ノード−Ａ  ４０２に送信する（図２３のＳ２３０２）。
【０１５９】
宛先ノードに至る経路上の中継ノード−Ａ  ４０２及び中継ノード−Ｂ  ４０３はそれぞれ、第１の動作例の説明で前述した＜動作パターン２＞、＜動作パターン３＞、又は＜動作パターン４＞に従って、要求メッセージ４０７の転送処理を実行する。
【０１６０】
図２２及び図２３の第７の動作例では、中継ノード−Ａ  ４０２は、指定アプリである“アプリ−１”もその実行のリソースも持っていない。このため、中継ノード−Ａ  ４０２は、前述した＜動作パターン４＞に従い、要求メッセージ４０７のアプリ保持ビットＡＨ及びアプリ実行可能ビットＡＥの両方とも値０のままとして、要求メッセージ４０７を中継ノード−Ｂ  ４０３に中継する（図２３のＳ２３０３）。
【０１６１】
次に、中継ノード−Ｂ  ４０３は、“アプリ−１”を保持しているため、前述した＜動作パターン２＞に従って、要求メッセージ４０７中のアプリ保持ビットＡＨをオンする。また、中継ノード−Ｂ  ４０３は、ＡＨ＝１をセットしたこと、及び最初にＡＨ＝１をセットしたことを、メモリ７０２に記憶する（以上、図２３のＳ２３０４）。そして、中継ノード−Ｂ  ４０３は、その要求メッセージ４０７を、データ−ａ保持ノード４０５に転送する（図２３のＳ２３０５）。
【０１６２】
データ−ａ保持ノード４０５は、 “アプリ−１”及びその実行のリソース共に持っておらず、要求メッセージ４０７のアプリ保持ビットＡＨがオンなので、図４の第１の動作例等の場合と同様に、前述した＜動作パターン６＞に従って、以下の動作を実行する。データ−ａ保持ノード４０５は、そのヘッダ部に要求メッセージ４０７のＰＬ、ＡＨ、ＡＥの各ビット値がコピーされ、Ｃｏｎｔｅｎｔ部に“データ−ａ”本体が格納された応答メッセージ４０８を生成する（図２３のＳ２３０６）。そして、データ−ａ保持ノード４０５は、生成した応答メッセージ４０８を中継ノード−Ｂ  ４０３に返送する（図２３のＳ２３０７）。
【０１６３】
データ−ａ保持ノード４０５から応答メッセージ４０８、４０９を受信した経路上の中継ノードは、第１の動作例の説明で前述した＜動作パターン８＞又は＜動作パターン９＞に従って、応答メッセージ４０８、４０９の転送処理／アプリ実行処理を実行する。
【０１６４】
中継ノード−Ｂ  ４０３では、応答メッセージ４０８が到着した時に、その実行ポリシビットＰＬ＝１で、そのアプリ保持ビットＡＨがオンとなっており、かつ、中継ノード−Ｂ  ４０３はメモリ７０２にＡＨ＝１をセットしたことを記憶している。このため、中継ノード−Ｂ  ４０３は、前述の＜動作パターン８＞に従って、“アプリ−１”を実行すべきと判定する。この結果、中継ノード−Ｂ  ４０３はまず、Ｎａｍｅ部に自ノードが保持していない要素オブジェクトの１つに対応する名前“データ−ｂ”が格納された別の要求メッセージを生成し、その要求メッセージをネットワークに送信する（図２３のＳ２３０８）。データ−ｂ保持ノード４０６は、この別要求メッセージに応答し、Ｃｏｎｔｅｎｔ部に“データ−ｂ”本体が格納された応答メッセージを中継ノード−Ｂ  ４０３に返送する（図２３のＳ２３０９）。“アプリ−１”に関しては、中継ノード−Ｂ  ４０３自身が保持しているため、アプリ保持ノード４０４に“アプリ−１”を要求することはしない。その後、中継ノード−Ｂ  ４０３は、ＡＨ＝１をセットしたことを記憶しているので応答メッセージ４０８に格納されている“データ−ａ”本体を取り出し、“データ−ａ”及び“データ−ｂ”を入力データとして、自ノードが保持する“アプリ−１”本体が示すプログラムを実行する（図２３のＳ２３１０）。その結果、中継ノード−Ｂ  ４０３は、ヘッダ部でアプリ保持ビットＡＨを０にリセットし（アプリ実行可能ビットＡＥは元々０）、Ｃｏｎｔｅｎｔ部に実行結果を格納した新たな応答メッセージ４０９を生成する（図２３のＳ２３１１）。ＡＨ＝０とするのは、他のノードがアプリを実行しないようにするためである。そして、中継ノード−Ｂ  ４０３は、その応答メッセージ４０９を中継ノード−Ａ  ４０２に転送する（図２３のＳ２３１２）。
【０１６５】
中継ノード−Ａ  ４０２では、“アプリ−１”もその実行のリソースも持っていないため、前述の＜動作パターン９＞に従って、受信した応答メッセージ４０９をそのまま、リクエスタ４０１に中継する（図２３のＳ２３１３）。
【０１６６】
最後に、リクエスタ４０１は、受信した応答メッセージ４０９のＣｏｎｔｅｎｔ部から、アプリの実行結果を受け取る。
【０１６７】
このように、図１４及び図１５の第３の動作例では、リクエスタ４０１が要求メッセージ４０７の送信時に実行ポリシビットＰＬ＝１（宛先近傍優先）を指定している。このため、“アプリ−１”の実行のリソースを有する中継ノード−Ａ  ４０２と中継ノード−Ｂ  ４０３のうち、宛先ノードであるデータ−ａ保持ノード４０５に近い方の中継ノード−Ｂ  ４０３が、“アプリ−１”を実行することになる。
【０１６８】
次に、図５を用いて前述した第２の実施形態の詳細動作について、以下に説明する。
【０１６９】
図５の第２の実施形態の通信システム４００では、リクエスタ４０１が、ネットワークを介して、“アプリ−１”保持ノード４０４、データ−ａ保持ノード４０５、及びデータ−ｂ保持ノード４０６にアクセスする。図５では図示しないが、第２の実施形態においても、図６に示されるように、中継ノード−Ａ  ４０２や中継ノード−Ｂ  ４０３も実際には動作している。
【０１７０】
第２の実施形態の通信システム４００は、図５に示されるように、初期状態として、“アプリ−１”本体が“アプリ−１”保持ノード４０４に、“データ−ａ”本体がデータ−ａ保持ノード４０５、“データ−ｂ”本体がデータ−ｂ保持ノード４０６に配備される。そして、第１の実施形態で説明した中継ノード−Ａ  ４０２や中継ノード−Ｂ  ４０３でアプリを実行するためには、必要に応じて上述の各保持ノードに保持された要素オブジェクトが取得される、これらの要素オブジェクトを用いてアプリが実行される。
【０１７１】
前述したように、アプリ保持ノード４０４、データ−ａ保持ノード４０５、データ−ｂ保持ノード４０６のハードウェア構成としては、図７に示されるハードウェア構成例を有する。
【０１７２】
第２の実施形態の通信システム４００の詳細動作について、図５及び図２４のシーケンス図を用いて説明する。
【０１７３】
リクエスタ４０１或いはエッジノードは、所定の通信プロトコルにより、アプリ保持ノード４０４、データ−ａ保持ノード４０５、及びデータ−ｂ保持ノード４０６に対し、アプリ実行に必要な要素オブジェクトのサイズを探索する（図５の５０１）。所定の通信プロトコルとしては、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｏｒ  Ｐｒｏｔｏｃｏｌ）、Ｔｅｌｎｅｔ、又はＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｏｒ  Ｐｒｏｔｏｃｏｌ）などを用いることができる。
【０１７４】
具体的には、リクエスタ４０１はまず、アプリ保持ノード３０４に対して、そのノードが保持する“アプリ−１”のサイズ探索を行う所定の通信プロトコルのコマンドを送信する（図２４のＳ２４０１）。これに対して、アプリ保持ノード３０４は、“アプリ−１”のサイズ、例えば１０ｋＢを、リクエスタ４０１に応答する（図２４のＳ２４０２）。
【０１７５】
また、データ−ａ保持ノード４０５に対して、そのノードが保持する“データ−ａ”のサイズ探索を行う所定の通信プロトコルのコマンドを送信する（図２４のＳ２４０３）。これに対して、データ−ａ保持ノード４０５は、“データ−ａ”のサイズ、例えば１ＭＢを、リクエスタ４０１に応答する（図２４のＳ２４０４）。
【０１７６】
同様に、データ−ｂ保持ノード４０６に対して、そのノードが保持する“データ−ｂ”のサイズ探索を行う所定の通信プロトコルのコマンドを送信する（図２４のＳ２４０５）。これに対して、データ−ｂ保持ノード４０６は、“データ−ｂ”のサイズ、例えば５ｋＢを、リクエスタ４０１に応答する（図２４のＳ２４０６）。
【０１７７】
その後、リクエスタ４０１は、各応答データから取得したサイズを比較し、最大サイズの要素オブジェクト（以下、特定オブジェクトと記載）、例えば“データ−ａ”を判定する（図２４のＳ２４０７）。
【０１７８】
或いは、アプリの特性から事前にアプリとデータのサイズ関係が分かれば、前述した図９のＰＬ設定テーブルに追加的に、アプリの種別毎の最大オブジェクトをスタティックに定義しておいてもよい。
【０１７９】
リクエスタ４０１は、図８（ａ）の説明で前述したように、アプリを実行するのに必要な要素オブジェクト（アプリ、データ）の名前文字列を”+”で連結して、要求メッセージ４０７のＮａｍｅ部に設定する。前述したように、例えばＮａｍｅ部は、“データ−ａ＋アプリ−１＋データ−ｂ”と表記される。Ｎａｍｅ部に表記される“データ−ａ”、“アプリ−１”、及び“データ−ｂ”は、それぞれの要素オブジェクトの名前である。要求メッセージ４０７は、そのＮａｍｅ部の先頭の名前（図５の場合は“データ−ａ”）に対応する要素オブジェクトを保持するノード（図５の場合は５０２で示されるデータ−ａ保持ノード４０５）を宛先ノードとして、ネットワーク内をルーティングされる。
【０１８０】
要求メッセージ４０７がネットワークに送信された後は、前述した、第１の実施形態における第１〜第７の動作例等のうちの何れかの手順が実行される。
【０１８１】
以上説明した第１又は第２の実施形態の通信システムにより、アプリやデータの転送遅延・帯域を削減して、アプリ実行結果のレスポンスを速くすることが可能となる。また、ネットワーク内でのアプリ実行処理のロードバランスを実現し、アプリの実行に必要なリソースの有効利用を図ることが可能となる。
【０１８２】
次に本発明の第３の実施形態を、図面を参照して説明する。上述したように、第１の実施形態は支配的、すなわち相対的にサイズの大きい入力データの数が１個の場合に適用され、リクエスタから当該入力データに至る経路上の適切な位置でアプリ実行させる方式である。
【０１８３】
第１の実施形態では、支配的な入力データの数が１つの場合を論じたが、第３の実施形態では、支配的なデータが複数の場合をも考慮する。以下に説明する第３の実施形態においては、他のＮＦＮノードとの間でアプリ実行場所を分散する。そしてこれにより、出力データ＜Σ(入力データ)であっても、アプリや入力データの転送遅延を小さくし、かつレスポンス時間を短くすることができる。なお上述のように、レスポンス時間とは、ユーザがアプリ実行要求を投げてから、その応答を受け取るまでの時間を意味するものとする。
【０１８４】
上述したように、第３の実施形態は、支配的な入力データの数が複数の場合に適用され、リクエスタから当該支配的な複数の入力データに至る経路上の適切な位置の分岐点（分岐点ノードとも称する）でアプリ実行させる方式である。なお、支配的な入力データの数が複数である場合とは、入力データのうちの複数の入力データの各々が、他の入力データよりも相対的にサイズが大きく、かつそれら支配的な入力データの各々は互いにほぼ同等のサイズとなる場合を称する。また分岐点とは、受信する要求メッセージが１つであるものの、複数の支配的入力データの各々を有する、複数のノードの各々を宛先として、複数の要求メッセージを転送するノードを指すものとする。
【０１８５】
一般に、ネットワークは大規模で、すべてのノードの状態を1箇所でリアルタイムに集中管理するのは困難である。また、対象とする「アプリ」には、ファイヤウォールやフィルタリング等のネットワークアプリ、データ解析アプリや画像解析アプリ等のユーザアプリの双方が含まれる。なお、これらのアプリはバイトコード（例えば、Ｊａｖａ）のような形で実装され、プラットフォーム非依存であるとともに、ノード間での移動が可能であるものとする。
【０１８６】
そのため第３の実施形態は支配的な入力データの数が複数の場合に、ネットワーク内でのアプリ実行呼出しにおいて、レスポンス時間を短縮し、かつノード間の負荷分散を実現することを課題とする。その課題を解決するために、図２５に例示するように分岐点ノードでアプリ実行することを考える。ここで分岐点ノードとは、この場合、リクエスタ６０１から要求オブジェクトを有するノードまでの経路により形成される木構造のＮＦＮにおいて、データ−ａ、データ−ｂをオブジェクト要素として保持する保持ノードに向かう経路が分岐する点を称する。なお、このＮＦＮは、実際の通信ネットワーク上のリクエスタ６０１を始点として、要求オブジェクトの存在するノードまでの経路を、リクエスタ６０１側で予め選択しておくことにより木構造のネットワークとして形成される。
【０１８７】
図２５、２６は、アプリ実行の基本方針を説明するネットワーク図である。図２６に示すように、要求メッセージ６０７には予め、第１、２の実施形態と同様に、実行ポリシビット（Ｐ）、アプリ実行保持ビット（ＡＨ）、アプリ実行可能ビット（ＡＥ）が設けられる。そしてそれらに加え、例えば1ビットの、分岐点ビット（ＢＲ、分岐点情報）、２ビットの分岐モードビット（ＢＭ、分岐モード情報）、が設けられる。これらのビットを設定することにより、アプリへの入・出力データの関係に応じ、以下のようにネットワーク動作が決定されるものとする。
［Ａ］  出力データ＞Σ(入力データ)  の場合
->  要求ノードの近傍でアプリ実行  （ＰＬ＝０、  ＢＭ＝Φ（ｄｏｎ’
ｔ  ｃａｒｅ））
［Ｂ］  Σ(入力データ)＞出力データ、かつ、支配的な入力データが１つの場合
->入力データを有するノードの近傍（要求ノードから遠く）においてアプリ実行  （ＰＬ＝１、  ＢＭ＝００）
以外に、本実施形態では、
［Ｃ］  Σ(入力データ)＞出力データで、支配的な入力データが複数の場合
->  分岐点の近傍でアプリ実行
（ａ） アプリは全入力データが揃わないと実行できない場合
⇒  最初の分岐点近傍でアプリ実行  （ＰＬ＝１、  ＢＭ＝０１）
（ｂ）  アプリは一部の入力データのみでも実行できる場合
⇒  個々の分岐点近傍でアプリ実行  （ＰＬ＝１、  ＢＭ＝１０）
【０１８８】
このネットワーク動作により、宛先ノードである“アプリ−１”保持ノードやリクエスタ６０１の場合に加え、分岐点ノード６１０においてもアプリ実行を行わせることが可能となる。
【０１８９】
また、この第３の本実施形態は、アプリ実行場所決定に各ノードのリソース状態を反映させ、分岐点を含む特定した場所を中心にノード間で負荷分散させることが可能となる。すなわち、アプリ特性と各ノードのリソース状態により、各ノードがローカルに得られる情報からアプリ実行の可否を判断し、アプリ実行場所を動的に決定することが可能である。
【０１９０】
詳細は後述するが、図２６に示すネットワーク動作を用いて第３の実施形態の方針を簡単に説明する。図２６は、アプリを実行するために、アプリ−１、データ−ａ、データ−ｂが必要な場合を表す。手順は次の通りである。
【０１９１】
要求メッセージ６０７に、実行ポリシビット(ＰＬ)／アプリ保持ビット(ＡＨ)／アプリ実行可能ビット(ＡＥ)に加えて、分岐点ビット(ＢＲ)、分岐モードビット(ＢＭ)を設ける。
【０１９２】
アプリの特性（入力データ量と出力データ量の関係）に応じて、リクエスタ６０１あるいはエッジノード（リクエスタを収容する、ネットワークの入口のノード）は、要求メッセージ６０７の実行ポリシビットＰＬと、分岐モードビットを設定する。
【０１９３】
実行ポリシビットについては、宛先ノードか分岐点ノード６１０近傍優先（ＰＬ＝１）、リクエスタ６０１近傍優先（ＰＬ＝０）、から選択する。
【０１９４】
分岐モードビットは、分岐点なし（ＢＭ＝００）、最初の分岐点においてアプリ実行（ＢＭ＝０１）、個々の分岐点においてアプリ実行（ＢＭ＝１０）、の中から選択され設定される。
【０１９５】
図２６の示す一例における要求メッセージ６０７は、宛先ノードであるアプリ／アプリ実行リソースの保持ノード、または分岐点近傍において、優先的にアプリを実行（ＰＬ＝１）、かつ最初の分岐点においてのアプリ実行（ＢＭ＝０１）、を示す。要求メッセージ６０７のＮａｍｅ部が示す宛先を、複数の支配的な入力データを示すように構成された、要求メッセージが送信される。
【０１９６】
図２６では、データ−ａ、データ−ｂが宛先となる。経路上のノードは、経路上にない近傍ノードも含めて、指定アプリを持っているか、実行リソースを持っているか、に応じて、アプリ保持ビット（ＡＨ）、かつ／または、アプリ実行可能ビット（ＡＥ）を順次セットする。また経路上のノードの、複数のネットワークインタフェースへ要求メッセージ６０７を中継する場所（分岐点）において、分岐点ビットＢＲがセットされ、以降のノードでのアプリ実行を抑止する。
【０１９７】
各ノードが、要求メッセージと応答メッセージにおける、これらのビットの状態を判別して動作を決定することにより、アプリ実行場所が、経路上のノード、経路上でその近くのノード、その近傍のノード、の優先順で決定される。なお、ここでの経路上のノードとは、宛先ノードのアプリ／アプリ実行リソース保持ノード、リクエスタまたはエッジノード、分岐点ノードを指すものとする。また経路上でその近くのノードとは、経路上にあり、かつ、宛先ノードのアプリ／アプリ実行リソース保持ノード、リクエスタまたはエッジノード、分岐点ノードのうちの、いずれかの近くに配置されているノードを指すものとする。そして経路上のノードによりアプリ実行が行われるものとして決定されるときは、宛先ノードのアプリ／アプリ実行リソース保持ノード、リクエスタ６０７またはエッジノード、分岐点ノード６１０のいずれかのノードがアプリ実行場所として決定される。アプリを実行するノードは、その場で必要なアプリとデータを取得してアプリ実行を行い、その結果を応答メッセージとして返す。  アプリが分岐点で実行される場合で、かつ複数の分岐点がある場合には、分岐モードビットＢＲの設定値に従い、1箇所または分岐点毎にアプリが実行される。このように、要求メッセージと応答メッセージのＡＨ、ＡＥ、ＢＲビットにより、各ノードは、経路上での自分の相対的な位置が分かる。また、それらとＰＬビット, ＢＭビットを考慮して、各ノードはアプリ実行の可否を決める。
【０１９８】
図２６は、データ−ａとデータ−ｂへの分岐点ノード６１０である中継ノード-Ｂ  ６０３が、アプリ実行を行う場合を示す。このように、第３の実施形態では、アプリの特性と各ノードのリソース状態に応じて、経路上のノード（宛先ノードのアプリ／アプリ実行リソース保持ノード、リクエスタ６０１またはエッジノード、分岐点ノード６１０）、経路上でその近くのノード、その近傍のノードでアプリを実行することが可能である。すなわち、経路上やその近傍を含む、アプリ実行リソースのあるノード（特定のノードに限定しない）でアプリを実行することになる。
【０１９９】
次に図２６のネットワーク動作を、図２７のメッセージフォーマットを用いて詳細に説明する。図２７は、以下の実施例（その１、その２）における要求メッセージと応答メッセージに対するメッセージフォーマットを表す図である。
【０２００】
要求メッセージは、図２７（a）に示すように、ヘッダ部（ＰＬ、ＡＨ、ＡＥ、ＢＲ、ＢＭ）とＮａｍｅ部を含み、図２６のネットワーク動作の場合では、（ＰＬ、ＡＨ、ＡＥ、ＢＲ、ＢＭ）＝（１、０、０、０、０１）となっている。それぞれの説明は、以下の通りである。なお、第１、第２の実施形態における要求メッセージからの追加拡張部分は、ＢＲ、ＢＭである。
【０２０１】
ＰＬ（実行ポリシビット、Ｐｏｌｉｃｙ）：  ０か１の値をとるビットである。遅延や転送量の観点から、対象のアプリが、リクエスタの近くで実行される方が有利か（ＰＬ＝０）、リクエスタから遠く（＝アプリやデータ、あるいは分岐点の近く）で実行される方が有利か（ＰＬ＝１）、を示す。リクエスタが要求メッセージを送出する時、またはエッジノード（リクエスタを収容する、ネットワークの入口のノード）が要求メッセージを中継する時に、アプリの特性に従い、ＰＬが設定される。
【０２０２】
アプリに対して入力データ量＜出力データ量の場合（ex. データの単純マージ）には、ＰＬ＝０が設定される。一方、アプリに対して入力データ量＞出力データ量の場合（ｅｘ. 画像解析）には、ＰＬ＝１が設定される。
【０２０３】
図２６のネットワーク動作においてはＰＬ＝１なのでリクエスタ６０１から遠くでのアプリ実行が選択されている。
【０２０４】
ＡＨ（アプリ保持ビットＡｐｐＨｏｌｄ）は、０か１の値をとるビットであり、上述した第１、２の実施形態のＡＨと同様であり、自ノードがＮａｍｅ部で指定されるアプリを持っていないか（ＡＨ＝０）、持っているか（ＡＨ＝１）、を示す。リクエスタ自身が、まずアプリの保有状況に応じて設定して送出し、経路上のノードが、（近傍も含めて）指定アプリを持っていれば1にセットし、指定アプリを持っていなければ値を変更しない。図２６のネットワーク動作では、中継ノード−Ａ  ６０２がアプリを保持しないため、ＡＨ＝０からの変化はないが、中継ノード−Ｂ  ６０３はアプリを保持している。そのため、中継ノード−Ｂ  ６０３は、要求メッセージ６０７を、（ＰＬ、ＡＨ、ＡＥ、ＢＲ、ＢＭ）＝（１、０、０、０、０１）から（１、１、０、１、０１）へ変化させ、後続のデータ保持ノードへ転送する。
【０２０５】
ＡＥ（アプリ実行可能ビット、ＡｐｐＥｘｅｃ）は、上述した第１、２の実施形態のＡＥと同様に、アプリを実行するリソース（例えばＣＰＵやメモリの組み合わせ）を各ノードが持つか(ＡＨ＝１)否か(ＡＨ＝０)、を示す。これは、０か１の値をとるビットである。リクエスタ６０１が、まず自己のアプリ実行リソースの保有状況に応じてＡＥの値を設定して、要求メッセージ６０７を送出する。そして経路上のノード（近傍も含めて）が、実行リソースを持っていれば、そのノードがＡＥを1に設定し、そのノードが実行リソースを持たなければ値に変更はない。
【０２０６】
ＢＲ（分岐ビット、Ｂｒａｎｃｈ）は、リクエスタ６０１により要求メッセージ６０７の送信がされる時、初期値０である。そして、ＢＲは、複数のネットワークインタフェースへ要求メッセージ６０７を中継するノード（分岐点ノード６１０）により1に設定される。このＢＲ＝１（かつＢＭ＝０１）により、分岐点ノード６１０以降のノード（分岐点ノードではないノード）でのアプリ実行が抑止される。
【０２０７】
図２６のネットワーク動作では、中継ノード−Ｂ  ６０３が、分岐点ノード６１０である。そのため中継ノード−Ｂ  ６０３により、要求メッセージ６０７は、（ＰＬ、ＡＨ、ＡＥ、ＢＲ、ＢＭ）＝（１、０、０、０、０１）から（１、１、０、１、０１）に更新され、ＢＲ＝１へと変化する。
【０２０８】
ＢＭ（分岐モードビット、Ｂｒａｎｃｈ  Ｍｏｄｅ）は、分岐処理のモードを表す２ビットが割当てられる。詳細には、ＢＭ＝００；分岐処理なし、ＢＭ＝０１；１箇所（最初の分岐点）でアプリ実行、ＢＭ＝１０；各分岐点で随時アプリ実行、を表す。ＢＭは、アプリの特性から、リクエスタが要求メッセージを送出する時、あるいはエッジノードが要求メッセージを中継する時に設定される。図２６のネットワーク動作では、ＢＭ＝０１となっているので最初の分岐点、すなわち中継ノード−Ｂ  ６０３でアプリ実行となる。
【０２０９】
Ｎａｍｅは、上述の第１、２の実施の形態の場合と同様に、要求しようとするアプリ実行を指定する、可変長のフィールドであり、アプリを実行するのに必要な要素オブジェクト（アプリ、データ）を連結して表示する。例えば、要求メッセージの宛先となる複数のデータを"+"で結合し、アプリ実行に必要なアプリを":"で結合する。例としては、図２６のネットワーク動作の要求メッセージ６０７に示されるように、Ｎａｍｅ部は"データ−ａ＋データ−ｂ：アプリ−１"、と表される。なお、データ−ａ, データ−ｂ, アプリ−１は、それぞれのオブジェクトの名前であり、Ｎａｍｅ部は、データ−ａおよびデータ−ｂを入力としアプリ−１が実行されることを表す。要求メッセージ６０７は、Ｎａｍｅ部が示すデータオブジェクト（この場合は、データ−ａおよびデータ−ｂ）に向かってルーティングされる。
【０２１０】
なお、ここで事前に各要素オブジェクトの存在場所から各要素オブジェクトに対応するルーティング情報がネットワーク内でブロードキャストされ、各ノードはオブジェクトの名前に対するルーティングテーブルを構成する。各ノードは、要求メッセージの受信時に、Ｎａｍｅ部の要素オブジェクトを抽出し、これら要素オブジェクトに対する出力インタフェースにルーティングする。
【０２１１】
図２７（ｂ）に示すように、応答メッセージ６０８、６０９は、ヘッダ部（ＰＬ、ＡＨ、ＡＥ、ＢＲ、ＢＭ）とＮａｍｅ部とＣｏｎｔｅｎｔ部を含む。Ｄａｔａ部以外の意味は、要求メッセージ６０７と同様である。ただし、ＡＨ、ＡＥ、ＢＲ、ＢＭは改めて設定されるのではなく、宛先ノードにおいて要求メッセージ６０７からコピーされる。ＡＨ、ＡＥは、途中のノードでアプリが実行されたた場合に０にリセットされ、次のノードに渡される。ＢＲは、分岐点ノード６１０（要求メッセージ６０７に対しＢＲを設定したノード）において応答メッセージを中継するときに、０にリセットして次のノードに渡される。また、応答メッセージのルーティングはＮａｍｅ部によるのではなく、各ノードで要求メッセージ６０７の送信元を覚えておいて、その送信元へ応答メッセージは送られる。
【０２１２】
Ｃｏｎｔｅｎｔは、要求されたアプリの実行結果または要素オブジェクト（アプリ、データ）を入れるための、可変長のフィールドである。ノードでのアプリ実行後にはアプリの実行結果が、アプリ実行前には要素オブジェクトが入れられる。
【０２１３】
図２６に示すネットワーク動作では、データ−ａ保持ノード６０５は、アプリ実行リソースを持たないが、データ−ａを保持している。そのためデータ−ａ保持ノード６０５は、（ＰＬ、ＡＨ、ＡＥ、ＢＲ、ＢＭ）＝（１、１、０、１、０１）に加え、応答メッセージとして、データ−aのコンテンツを追加する。また、同様にデータ−ｂ保持ノード６０６はアプリ実行リソースを持たないが、データ−ｂを保持する。そのためデータ−ｂ保持ノード６０６は、（ＰＬ、ＡＨ、ＡＥ、ＢＲ、ＢＭ）＝（１、１、０、１、０１）に加え、応答メッセージとしてデータ−ｂのコンテンツを追加する。
【０２１４】
分岐点である中継ノード−Ｂ  ６０３は、アプリ−１を保持し（ＡＨ＝１）、かつＢＲを０から１に更新したノードであることを記憶する最初の分岐点ノード６１０Ｆである。またＢＭ＝０１であるので、アプリ−１を保有する、最初の分岐点ノード６１０Ｆがデータ−aとデータ−ｂを使用してアプリ実行を行うことから、中継ノード−Ｂ  ６０３がアプリ実行を行う。アプリ実行後、中継ノード−Ｂ  ６０３は、ＡＨとＢＲの値を元の値からを、ＡＨ＝０、ＢＲ＝０へとリセットし、応答メッセージ６０９として（ＰＬ、ＡＨ、ＡＥ、ＢＲ、ＢＭ）＝（１、０、０、０、０１）＋実行結果を出力する。この応答メッセージ６０９が中継ノード−Ａ  ６０２を介して要求元のリクエスタ６０１に渡される。
【０２１５】
図２６の基本方針を説明するために用いられたネットワークのモデルは、分岐点が１つのネットワーク構成の場合で、５つのノード（リクエスタを含む）から構成され、図２８のようなネットワークの木構成である。そしてネットワーク上には、予めリクエスタ６０１が存在し、初期状態としてアプリ−１がネットワーク上の分岐点ノード６１０にある。またデータ−ａ、データ−ｂが図２８のようにネットワークの木構造の葉の部分に配備されているので、アプリを実行するためにはこれらの要素オブジェクトが必要である。リクエスタ６０１はこのアプリの実行要求を発行する。
【０２１６】
このネットワークの木構造は、実際の通信ネットワークから要求コンテンツの内容によって写像されるが、第３の実施形態のネットワーク動作における分岐点ノードのアプリ実行はどんな複雑な木構造に写像されても適用可能である。
【０２１７】
図２９は、図２６と同じネットワークであって、一般化される木構造のネットワークの一例である。本例は、支配的な入力データ数が２（データ−ａ、データ−ｂ）で、分岐点でアプリ実行させる場合を示す。この場合、要求メッセージ６０７においてＰＬ＝１、ＢＭ＝０１である。、また図２９は、中継ノード−Ａ  ６０２がアプリを有さず、中継ノード−Ｂ  ６０３がアプリを有することを示す。この場合のネットワーク動作は、以下の通りである。
【０２１８】
リクエスタ６０１は、実行しようとするアプリの特性から、要求メッセージ６０７のＰＬビット、およびＢＭビットを設定する。図２９に示す一例では、ＰＬ＝１(宛先ノードまたは分岐点、の近傍でのアプリ実行)、ＢＭ＝０１(最初の分岐点ノード６１０Ｆでのアプリ実行)に設定されている。なお、ここでのＰＬビット、ＢＭビットの設定は、図２９においてエッジノードに当たる中継ノード−Ａ  ６０２が行ってもよい。
【０２１９】
図２９に示される実施例その１においてはＰＬ＝１の場合を説明する。ただし、ＰＬ＝０(リクエスタ６０１近傍でのアプリ実行)の場合については、第１の実施形態の処理手順で対応するものとする。
【０２２０】
図２９において、リクエスタ６０１における、要求メッセージ６０７のＮａｍｅ部が示す宛先は、複数の支配的な入力データであり、本例ではデータ−ａ、データ−ｂである。このようなＮａｍｅ部を有する要求メッセージをリクエスタは送信する。
【０２２１】
本例では、Ｎａｍｅ部で宛先となるデータ−ａとデータ−ｂを "＋" で結合し、かつアプリ-1を "：" で結合するものとする。
【０２２２】
要求メッセージ６０７は複数の宛先を持つので、分岐点ノード６１０である中継ノード−Ｂ  ６０３において、同じメッセージが複数のネットワークインタフェースへ送信される。このとき、リクエスタ６０１からデータ−ａ、データ−ｂに至る経路上のノード（例えば、中継ノード―Ａ  ６０２、中継ノード−Ｂ  ６０３）は、近傍ノードも含め、指定アプリ（アプリ−１）を持っていればＡＨビットをオンにする。また実行リソースがあればＡＥビットをオンにする。更に、分岐点ノード６１０であるならＢＲビットをセットして、以降のノードでのアプリ実行を抑止する。
【０２２３】
経路上の各ノードは、自己ノードからkホップ以内に存在する近傍ノードを探索するか、事前に調べるなどして、近傍ノードの情報を持つ。
【０２２４】
図２９においては、中継ノード−Ａ  ６０２は指定アプリも実行リソースも持っていないため、ＡＨ、ＡＥは中継ノード−Ａ  ６０２では変更されず０のままである。しかし、中継ノード−Ｂ  ６０３は、指定アプリを持つため、ＡＨビットを1にセットし、要求メッセージ６０７を中継する。かつ中継ノード−Ｂ  ６０３は分岐点ノード６１０である（複数のネットワークインタフェースへ要求メッセージを送信する）ため、あわせてＢＲビットを１にセットする。
【０２２５】
宛先となる要素オブジェクトであるデータ−ａ, データ−ｂを持つノード（データ−ａ保持ノード６０５、データ−ｂ保持ノード６０６）は、取得した要求メッセージ６０７のヘッダビットを参照し次のように動作する。
【０２２６】
ＢＲビットがオンなので、自分が指定アプリを持っているか実行リソースがあるかに関わらず、指定データ(データ−ａまたはデータ−ｂ)を応答メッセージ６０８のＣｏｎｔｅｎｔ部に入れて返す。この場合、データ−ａ保持ノード６０５、データ−ｂ保持ノード６０６は、要求メッセージ６０７のヘッダビット（ＰＬ、ＡＨ、ＡＥ、ＢＲ、ＢＭ）を、そのまま応答メッセージ６０８にコピーする。
【０２２７】
データ−ａ保持ノード６０５、データ−ｂ保持ノード６０６からの各応答メッセージ６０８は、要求メッセージ６０７の逆経路にて転送され、分岐点ノード６１０（中継ノード−Ｂ)において1つのメッセージに合成される。
【０２２８】
応答メッセージ６０８を受信した経路上のノード（例えば、中継ノード−Ａ  ６０２、中継ノード−Ｂ  ６０３）は次のように動作する。
【０２２９】
自分が分岐点ノード６１０でなく、かつ受信する応答メッセージのＢＲビットがオンである場合は、そのまま応答メッセージ６０８をリクエスタ６０１方向へ、要求メッセージ６０７と逆経路に転送する。
【０２３０】
例えば、中継ノード（例えば、中継ノード−Ａ  ６０２、中継ノード−Ｂ  ６０３）とデータ−ａ保持ノード６０５との間に別のノードが有る場合には、当該中継ノードは以下のように動作する。その中継ノードが分岐点ノード６１０である場合には、送信した要求メッセージ６０７に対応するすべての応答メッセージの到着を待つ。応答メッセージがすべて到着すれば、アプリ実行に必要なすべての入力データが当該中継ノードに揃う。応答メッセージのＡＥまたはＡＨがオンであり、（近傍も含め）当該中継ノードが指定アプリまたは実行リソースを持っている場合には、その中継ノードがアプリ実行を行う。そして、その結果を応答メッセージのＣｏｎｔｅｎｔ部に入れて返す。なお、当該中継ノードにおいてＡＨをオンにしておらず、かつＡＥをオンとしたときは、別メッセージで別途アプリを取得し、アプリ実行を行う。なお、当該中継ノードは、要求メッセージ６０７に対し、ＡＨまたはＡＥをオンにしたことを記憶し、当該要求メッセージ６０７に対応する応答メッセージを認識できるものとする。中継ノードは、アプリの実行を行い、ＡＥ，ＡＨ、ＢＲをクリアする。それ以外の場合、すなわちアプリ実行を行わない場合には、受信した応答メッセージのＣｏｎｔｅｎｔ部の内容（例えば、データ−ａ、 データ−ｂ）を1つの応答メッセージに入れてリクエスタ６０１方向へ転送する。このときに、当該中継ノードはＢＲをクリアする。
【０２３１】
図２９はこの場合に該当し、中継ノード−Ｂ  ６０３がアプリ実行を行う。
【０２３２】
自分が分岐点でなくかつ応答メッセージのＢＲビットがオフである場合（＝分岐点でアプリ実行されずに転送された場合で、応答メッセージにデータ−ａ、データ−ｂが含まれている場合）には当該中継ノードは以下のように動作する。ＡＥまたはＡＨを当該中継ノードがオンにした場合で、（近傍も含めて）自分が指定アプリまたは実行リソースを持っている場合には、当該中継ノードがアプリ実行を行い、結果を応答メッセージのＣｏｎｔｅｎｔ部に入れて返す。また当該中継ノードにおいてＡＨをオンにしておらず、ＡＥをオンにした場合には、別メッセージにより別途アプリを取得してアプリ実行を行う。この中継ノードは、分岐点ノード６１０に最も近く、指定アプリまたは実行リソースを持つ。その際、当該中継ノードは、ＡＥ、ＡＨ、ＢＲをクリアする。それ以外の場合には、受信した応答メッセージをそのままリクエスタ６０１方向へ転送する。
【０２３３】
図２９では、中継ノード−Ｂ  ６０３はＡＨ＝１をセットし、これを記憶している。また中継ノード−Ｂ  ６０３に、データ−ａ保持ノード６０５およびデータ−ｂ保持ノード６０６からそれぞれ応答メッセージが到着したとき、当該ノードはアプリを持つため、このノードでアプリ実行が行われる。そして、中継ノード−Ｂ  ６０３は、結果を応答メッセージのＣｏｎｔｅｎｔ部に入れて返す。このとき、ＡＨビット、ＢＲビットはクリアされる。
【０２３４】
以上の動作を行うことにより、アプリ実行は下記の優先順位で行われる。
１．分岐点ノード６１０
２．経路上のリクエスタ６０１側で分岐点ノード６１０の近くのノード
３．経路上で分岐点ノード６１０の近くのノードの近傍のノード（経路上にはないが、経路上のノードからkホップ以内のノード）
【０２３５】
次にシーケンス図を参照して説明する。図３０は、図２９の本実施例その１のシーケンスを表す図である。
【０２３６】
リクエスタ６０１は、ＰＬ＝１、ＢＭ＝０１、ＡＨ＝０、ＡＥ＝０とし（ステップＳ３００１）、Ｎａｍｅ部を "データ−ａ＋データ−ｂ：アプリ−１"とした要求メッセージ６０７を中継ノード−Ａ  ６０２に転送する（ステップＳ３００２）。中継ノード−Ａ  ６０２は、アプリ、実行リソースともに持っていないので、ＡＨ、ＡＥを変更せず、要求メッセージ６０７を中継ノード−Ｂ  ６０３に転送する（ステップＳ３００３）。中継ノード−Ｂ  ６０３は、アプリを持っているので、ＡＨ＝１に書替えて（ステップＳ３００４）、要求メッセージ６０７をデータ−ａ保持ノード６０５およびデータ−ｂ保持ノード６０６に転送する（ステップＳ３００５、Ｓ３００５’）。このとき、自分が分岐点ノード６１０であるため、要求メッセージ６０７のＢＲビットをオンにする（ステップＳ３００４）。なお、中継ノード−Ｂ  ６０３は本要求メッセージ６０７に対してＡＨ＝１に書替えたこと、自分が分岐点ノード６１０であることを記憶しておく（ステップＳ３００４）。
【０２３７】
データ−ａ保持ノード６０５およびデータ−ｂ保持ノード６０６は、要求メッセージ６０７中のＢＲが１であることを確認し、応答メッセージ６０８を作成する（ステップＳ３００６、Ｓ３００６’）。そして要求メッセージ６０７のＰＬ、ＡＨ、ＡＥ、ＢＲ、ＢＭの値を、応答メッセージ６０８中の各々へとコピーする（ステップＳ３００６、Ｓ３００６’）。またＣｏｎｔｅｎｔ部に自分の持つデータ(例えば、データ−ａまたはデータ−ｂ）を入れて、中継ノード−Ｂ  ６０３に転送する（ステップＳ３００７、Ｓ３００７’）。
【０２３８】
中継ノード−Ｂ  ６０３は、自分が分岐点ノード６１０なので、２つの応答メッセージ６０８の到着を待つ。中継ノード−Ｂ  ６０３は、応答メッセージ６０８においてＰＬ＝１、ＡＨ＝１であることを読み取る。そして自分がＡＨをオンにしたことから、アプリ−１を持っており、アプリを実行すべきと判断する。データ−ａおよびデータ−ｂはそれぞれ受信した応答メッセージ６０８に含まれるため、中継ノード−Ｂ  ６０３は、これらを使って、アプリ−１の実行を行う（ステップＳ３００８）。そして、応答メッセージ６０８において、ＡＨ＝０、ＢＲ＝０とし、Ｃｏｎｔｅｎｔに実行結果を入れたもの（応答メッセージ６０９）を（ステップＳ３００９）、中継ノード−Ａ  ６０２に転送する（ステップＳ３０１０）。
【０２３９】
中継ノード−Ａ  ６０２は、応答メッセージ６０９においてＡＨ＝０、ＡＥ＝０であるので、応答メッセージ６０９をそのままリクエスタ６０１に送る（ステップＳ３０１１）。
【０２４０】
リクエスタ６０１は、応答メッセージ６０９からアプリ実行結果を受け取る。
【０２４１】
次に各ノードの処理フローを説明する。図３１は、実施例その１における、ノードの処理フローを表す図である。メッセージを受信した時、ノードはまずそのメッセージ種別の判別を行う（別途、ヘッダ等で定義および判別を行う）（ステップＳ３１０１）。
【０２４２】
（要求メッセージの時）
自分がＮａｍｅ部において指定されているアプリを持っているかをチェックし（ステップＳ３１０２）、持っている場合には（ステップＳ３１０２でＹｅｓ）、要求メッセージのＡＨを1にセットする（ステップＳ３１０３）。その時、ＡＨをセットしたこと、およびＡＨを最初に０→１にセットしたか（受信した要求メッセージのＡＨが０で、自分がこれを１に書替えたか）、を記録する（ステップＳ３１０３）。
【０２４３】
ステップＳ３１０３に続いて、または、ステップＳ３１０２でＮｏであると判定した場合に続いて、自分が実行リソースを持っているかをチェックする（ステップＳ３１０４）。持っている場合には（ステップＳ３１０４でＹｅｓ）、要求メッセージのＡＥを１にセットする（ステップＳ３１０５）。その場合、ＡＥをセットしたこと、およびＡＥを最初に０→１にセットしたか（受信した要求メッセージのＡＥが０で、自分がこれを１に書替えたか）、を記録する（ステップＳ３１０５）。
【０２４４】
ステップＳ３１０５に続き、または、ステップＳ３１０４でＮｏであると判定した場合に続き、自分が分岐点ノードであるか（宛先に基づき、複数のネットワークインタフェースに要求メッセージを転送すべきか、で判断）をチェックする（ステップＳ３１０６）。ＹＥＳである場合には（ステップＳ３１０６でＹｅｓ）、要求メッセージのＢＲを１にセットする（ステップＳ３１０７）。その場合、ＢＲをセットしたこと（自分が分岐点ノードであること）を記録する（ステップＳ３１０７）。ステップＳ３１０７に続いて、または、ステップＳ３１０６でＮｏであると判定した場合に続いて、宛先（Ｎａｍｅ部の先頭オブジェクト）に基づき、要求メッセージを次ノードに転送する（ステップＳ３１０８）。
【０２４５】
（応答メッセージの時）
自分が分岐点ノードであるか否かの判別を行う（ステップＳ３１０９）。
【０２４６】
＜分岐点ノードである時＞
全ての応答メッセージを受信したかを判別し（ステップＳ３１１０）、ＮＯならば終了し、Ｙｅｓなら次のステップを実行する。
(ＰＬ＝１かつＡＨ＝１かつ自分がＡＨをセットしたか) をチェックし（ステップＳ３１１１）、Ｙｅｓならばアプリ実行処理を行う（ステップＳ３１１２）。Ｎｏならば、ステップＳ３１１３を実行する。
(ＰＬ＝１かつＡＥ＝１かつ自分がＡＥをセットしたか) をチェックし（ステップＳ３１１３）、Ｙｅｓならばアプリ実行処理を行う（ステップＳ３１１２）。Ｎｏならば、ステップＳ３１１４を実行する。
(ＰＬ＝０かつＡＨ＝１かつ自分がＡＨを最初にセットしたか) をチェックし（ステップＳ３１１４）、Ｙｅｓならばアプリ実行処理を行う（ステップＳ３１１２）。Ｎｏならば、ステップＳ３１１５を実行する。
(ＰＬ＝０かつＡＥ＝１かつ自分がＡＥを最初にセットしたか) をチェックし（ステップＳ３１１５）、Ｙｅｓならばアプリ実行処理を行う（ステップＳ３１１２）。ステップＳ３１１１からステップＳ３１１５まで全てＮｏならば、アプリ実行処理を行わず、ＢＲを０にリセットし、Ｃｏｎｔｅｎｔ部に全てのデータを入れる（ステップＳ３１１６）。
【０２４７】
アプリ実行処理： アプリがなければ別要求メッセージでアプリを取得し、アプリ実行を行う（ステップＳ３１１２）。更に、応答メッセージにおいて、ＡＨ、ＡＥ、ＢＲを０にリセットし、Ｃｏｎｔｅｎｔ部にアプリ実行結果を入れる（ステップＳ３１１２）。
【０２４８】
対応する要求メッセージを受信した方向のノードに対し、応答メッセージを転送する（ステップＳ３１１７）。
【０２４９】
＜分岐点でない時＞
（ＢＲ＝１か) をチェックし（ステップＳ３１１８）、Ｙｅｓならば応答メッセージを転送（ステップＳ３１１７）して終了する。Ｎｏならば、ステップＳ３１１１を実行する。
【０２５０】
次に第３の実施形態の実施例２として、分岐点が２つのネットワーク構成の場合について説明する。
【０２５１】
図３２は、実施例その２を説明するためのネットワーク構成図である。ネットワークは、６つのノード（リクエスタを含む）を含み、図３２に例示されるようなネットワークを有する。初期状態としてデータ−ａ、データ−ｂ、データ−ｃ、アプリ−ｆ１が図のように配備され、アプリを実行するためにはこれらの要素オブジェクトが必要（データ-ａ、ｂ、ｃを入力としてアプリ−ｆ１を実行）である。リクエスタ６０１はこのアプリの実行要求を発行する。
【０２５２】
図３３は、実施例その２のネットワーク動作を表す図であり、（ａ）は、最初の分岐点近傍でアプリ実行する場合を表し、（ｂ）は、個々の（複数の）分岐点近傍でアプリ実行する場合を表す。アプリの特性として、（ａ）に示す場合は全入力データが揃わないとアプリ実行できない場合であり、（ｂ）に示す場合は一部の入力データのみでもアプリ実行できる場合である。それぞれのアプリ例としては、（ａ）：複数の温度センサのデータから平均値を出す、（ｂ）：複数の温度センサのデータから最大値を出す、などがある。その動作説明は、以下の通りである。
【０２５３】
＜（ａ）最初の分岐点でアプリ実行する場合＞
リクエスタ６０１は、実行しようとするアプリの特性から、要求メッセージ６０７のＰＬビット、およびＢＭビットを設定する。図３３（ａ）に示すようにここでは、ＰＬ＝１(宛先ノードまたは分岐点、の近傍でアプリ実行)、ＢＭ＝０１(最初の分岐点でアプリ実行)に設定されている。
【０２５４】
リクエスタ６０１は、要求メッセージ６０７のＮａｍｅ部が示す宛先を、複数の支配的な入力データとする。ここでは、図３３（ａ）に示すように、データ−ａ、データ-ｂ、データ−ｃが宛先となる。リクエスタ６０１は、生成した要求メッセージ６０７を経路上へ送信する。
【０２５５】
中継ノード−Ａ  ６０２は、アプリ−ｆ１を持ち、かつ最初の分岐点ノード６１０Ｆであるため、ＡＨ＝１、ＢＲ＝１にセットする。このようにセットした要求メッセージ６０７を、中継ノード−Ａ  ６０２は、データ−ｃ保持ノード６１１および中継ノード−Ｂ  ６０２に向け転送する。
【０２５６】
中継ノード−Ｂ  ６０３は分岐点ノード６１０であるが、要求メッセージ６０７において、 ＢＲ＝１であるため、既に最初の分岐点を通過したと判断する。またＢＭ＝０１であるので、ＢＲは操作せずに、そのまま要求メッセージ６０７をデータ−ａ保持ノード６０５およびデータ−ｂ保持ノード６０６に向け転送する。
【０２５７】
中継ノード−Ｂ  ６０３は自分が分岐点ノード６１０であるが最初の分岐点ノード６１０Ｆではない。そのため中継ノード−Ｂ  ６０３は、データ−ａおよびデータ−ｂの保持ノードから返ってきたデータが全て揃った時点で、これら２つのデータを入れた応答メッセージ６０８を中継ノード−Ａ  ６０２に返す。このとき、ＢＲの操作はなされない（ＢＲ＝１のままである）。
【０２５８】
中継ノード−Ａ  ６０２は、データ−ｃ保持ノード６１１および中継ノード−Ｂ  ６０３からのデータ（データ−ｃ、データ−ａ、データ−ｂ）が全て揃った時点で、アプリ−ｆ１の実行を行い、結果を入れた応答メッセージ６０９をリクエスタ６０１に返す。このとき、ＡＨ，ＢＲはリセットする。
【０２５９】
＜（ｂ）個々の（複数の）分岐点近傍でアプリ実行する場合＞
リクエスタ６０１は、実行しようとするアプリの特性から、要求メッセージ６０７のＰＬビット、およびＢＭビットを設定する。ここでの図３３（ｂ）においては、ＰＬ＝１(宛先ノードまたは分岐点、の近傍)、ＢＭ＝１０(個々の分岐点実行)に設定されている。
【０２６０】
リクエスタ６０１は、要求メッセージ６０７のＮａｍｅ部が示す宛先を、複数の支配的な入力データ(図３３（ｂ）ではデータ−ａ、データ−ｂ、データ−ｃ)として要求メッセージ６０７を生成し、当該メッセージを送信する。
【０２６１】
中継ノード−Ａ  ６０２は、アプリ−ｆ１を持ち、かつ分岐点ノード６１０である。そのため、中継ノード−Ａ  ６０２は、受信した要求メッセージ６０７において、ＡＨ＝１、ＢＲ＝１をセットする。そしてこのようにセットした要求メッセージ６０７をデータ−ｃ保持ノード６１１および中継ノード−Ｂ  ６０２に向け転送する。
【０２６２】
中継ノード−Ｂ  ６０３はアプリ−ｆ１を持ち、かつ分岐点ノード６１０である。そのため中継ノード−Ｂ  ６０３は、受信した要求メッセージ６０７においてＡＨ＝１をセットし、セット後の要求メッセージ６０７をデータ−ｂ保持ノード６０６およびデータ−ａ保持ノード６０５に向け転送する。このとき、ＢＲは既に１なので、操作しない（ＢＲ＝１のままとする）。
【０２６３】
中継ノード−Ｂ  ６０３は、自分が分岐点ノード６１０であり、かつＢＭ＝１０であることから、データ−ａおよびデータ−ｂの保持ノードから返ってきたデータが全て揃った時点で、これら２つのデータを用いて、アプリ−ｆ１の実行を行う。そしてその結果を入れた応答メッセージ６０９を中継ノード−Ａ  ６０２に返す。このとき、ＡＨはリセットされるが、中継ノード−Ｂ  ６０３は最初の分岐点ノード６１０ＦではないためＢＲは操作されない（ＢＲ＝１のままとする）。
【０２６４】
中継ノード−Ａ  ６０２は、データ−ｃ保持ノード６１１および中継ノード−Ｂ  ６０３からのデータ（データ−ｃ、データ−ａとデータ−ｂとの演算結果）が全て揃った時点で、アプリ―ｆ１の実行を行う。
【０２６５】
そしてその結果を入れた応答メッセージ６０９’をリクエスタ６０１に返す。この場合に、中継ノード−Ａ  ６０２は応答メッセージ６０９のＡＨ、ＢＲをリセットする。
【０２６６】
次に実施例その２のシーケンスを説明する。図３４および図３５は、実施例その２のシーケンスを表す図である。その説明は、以下の通りである。
【０２６７】
図３４は実施例その２（ａ）に例示される場合のような、最初の分岐点ノード６１０Ｆにおいてアプリ実行を行う場合におけるネットワーク動作のシーケンスを示す図である。リクエスタ６０１は、ＰＬ＝１、ＢＭ＝０１、ＡＨ＝０、ＡＥ＝０とし、Ｎａｍｅ部を "データ−Ａ＋データ−ｂ＋データ−ｃ：アプリ−ｆ１"とした要求メッセージ６０７を生成する（ステップＳ３２０１）。そして生成された要求メッセージ６０７を、リクエスタ６０１は、中継ノード−Ａ  ６０２に転送する（ステップＳ３２０２）。
【０２６８】
中継ノード−Ａ  ６０２は、アプリを有するので、受信した要求メッセージ６０７において、ＡＨ＝１に書替える（ステップＳ３２０３）。そして中継ノード−Ａ  ６０２は、書き換えた要求メッセージ６０７をデータ−ｃ保持ノード６１１および中継ノード−Ｂ  ６０３に転送する（ステップ３２０４、Ｓ３２０４’）。このとき、中継ノード−Ａ  ６０２は、自分が最初の分岐点ノード６１０Ｆであることより、要求メッセージ６０７のＢＲビットをオンにする（ステップＳ３２０３）。なお、中継ノード−Ａ  ６０２は本要求メッセージ６０７に対してＡＨ＝１に書替えたこと、および、自分が最初の分岐点ノード６１０Ｆであることを記憶しておく。
【０２６９】
データ−ｃ保持ノード６１１は、受信した要求メッセージ６０７においてＢＲ＝１なので、応答メッセージ６０８を作成する（ステップＳ３２０５）。このとき、データ−ｃ保持ノード６１１は、応答メッセージにおいて、受信した要求メッセージ６０７のＰＬ、ＡＨ、ＡＥ、ＢＲ、ＢＭの値をコピーし、Ｃｏｎｔｅｎｔ部に自分の持つデータ(データ−ｃ）を入れる（ステップＳ３２０５）。そしてこのようにして生成した応答メッセージ６０８を、データ−ｃ保持ノード６１１は、中継ノード−Ａ  ６０２に転送する（ステップＳ３２０６）。
【０２７０】
ステップＳ３２０４’より要求メッセージ６０７を受信した中継ノード−Ｂ  ６０３は、分岐点ノード６１０であるが、要求メッセージ６０７では、既にＢＲ＝１であること、およびＢＭ＝０１であることを確認する。そのため、中継ノード−Ｂ  ６０３は、受信した要求メッセージ６０７を変更することなく、データ−ｂ保持ノード６０３およびデータ−ａ保持ノード６０２に転送する（ステップＳ３２０７、Ｓ３２０７’）。このとき、中継ノード−Ｂ  ６０３は、自分が分岐点ノード６１０であるが、ＢＲは既に１なので最初ではない分岐点と判断し、ＢＲの操作を行わない（ＢＲ＝１のままとする）。なお、中継ノード−Ｂ  ６０３は、自分が最初ではない分岐点ノード６１０であることを記憶しておく。
【０２７１】
データ−ｂ保持ノード６０６およびデータ−ａ保持ノード６０５は、受信した要求メッセージ６０７においてＢＲ＝１であることを各々確認し、応答メッセージ６０８を生成する（ステップＳ３２０８、Ｓ３２０８’）。このときデータ−ｂ保持ノード６０６およびデータ−ａ保持ノード６０５は、要求メッセージ６０７のＰＬ、ＡＨ、ＡＥ、ＢＲ、ＢＭの値を応答メッセージ６０８へとコピーする（ステップＳ３２０８、Ｓ３２０８’）。そして、当該２つのノードのそれぞれは、Ｃｏｎｔｅｎｔ部に自分の持つデータ(データ−ａまたはデータ−ｂ）を入れて（ステップＳ３２０８、Ｓ３２０８’）、中継ノード−Ｂ  ６０３に転送する（ステップＳ３２０９、Ｓ３２０９’）。
【０２７２】
中継ノード−Ｂ  ６０３は、２つの応答メッセージ６０８（データ−ａ、データ−ｂ）の到着を待つ。そして、中継ノード−Ｂ  ６０３は、データ−ａおよびデータ−ｂが揃った時点で、自分が最初ではない分岐点ノード６１０であることより、これら２つのデータを入れた応答メッセージ６０８を作成する（ステップＳ３２１０）。そして中継ノード−Ｂ  ６０３は、中継ノード−Ａ  ６０２へ作成せいた応答メッセージ６０８を転送する（ステップＳ３２１１）。
【０２７３】
中継ノード−Ａ  ６０２は、２つの応答メッセージ６０８（データ−ｃ、データ−ａとデータ−ｂ）の到着を待つ。中継ノード−Ａ  ６０２は、受信した応答メッセージ６０８において、ＰＬ＝１、ＡＨ＝１であることを確認する。そして中継ノード−Ａ  ６０２は、自分が最初の分岐点ノード６１０Ｆであること、および、自分がＡＨをオンにしたことから、自分がアプリ−１を持ち、当該アプリを実行すべきと判断する。データ−ａ、データ−ｂ、データ−ｃは受信した応答メッセージ６０８に全て含まれるため、これらを使って、中継ノード−Ａ  ６０２はアプリ−１の実行を行う（ステップＳ３２１２）。中継ノード−Ａ  ６０２は、応答メッセージ６０９としてて、受信した応答メッセージ６０８に対してＡＨ＝０、ＢＲ＝０と更新を行い、Ｃｏｎｔｅｎｔ部に実行結果を入れたものを作成する（ステップＳ３２１３）。そして中継ノード−Ａ  ６０２は、作成した応答メッセージ６０９を、リクエスタ６０１に転送する（ステップＳ３２１４）。
【０２７４】
リクエスタ６０１は、応答メッセージ６０９によりアプリ実行結果を受け取る（ステップＳ３２１４）。
【０２７５】
図３５は実施例その２（ｂ）のシーケンス図である。リクエスタ６０１は、ＰＬ＝１、ＢＭ＝１０、ＡＨ＝０、ＡＥ＝０とし、Ｎａｍｅ部を "データ−ａ＋データ−ｂ＋データ−ｃ：アプリ−１" とした要求メッセージ６０７を生成する（ステップＳ３３０１）。続いてリクエスタ６０１は、生成した要求メッセージ６０７を中継ノード−Ａ  ６０２に転送する（ステップＳ３３０２）。
【０２７６】
中継ノード−Ａ  ６０２は、アプリを持つので、ＡＨ＝１に書替える（ステップＳ３３０３）。またこのとき中継ノード−Ａ  ６０２は、自分が最初の分岐点ノード６１０Ｆであることより、要求メッセージ６０７のＢＲビットをオンにする（ステップＳ３３０３）。そして中継ノード−Ａ  ６０２は、ステップＳ３３０３において書き換えた要求メッセージ６０７をデータ−ｃ保持ノード６１１および中継ノード−Ｂ  ６０３に転送する（ステップＳ３３０４、Ｓ３３０４’）。なお、中継ノード−Ａ  ６０２は、本要求メッセージ６０７に対してＡＨ＝１に書替えたこと、および、自分が最初の分岐点ノード６１０Ｆであることを記憶しておく。
【０２７７】
データ−ｃ保持ノード６１１は、受け取った要求メッセージ６０７においてＢＲ＝１であることを確認し、応答メッセージ６０８を作成する（ステップＳ３３０５）。このときデータ−ｃ保持ノード６１１は、受信した要求メッセージ６０７のＰＬ、ＡＨ、ＡＥ、ＢＲ、ＢＭの値を応答メッセージ６０８へとコピーする。そしてデータ−ｃ保持ノード６１１は、応答メッセージ６０８のＣｏｎｔｅｎｔ部に自分の持つデータ(データ−ｃ）を入れ（ステップＳ３３０５）、これを中継ノード−Ａ  ６０２に転送する（ステップＳ３３０６）。
【０２７８】
ステップＳ３３０４’において要求メッセージ５０７を受け取った中継ノード−Ｂ  ６０３は、アプリを持つため、要求メッセージ５０７においてＡＨ＝１と書替える（上書きする）（ステップＳ３３０７）。このとき中継ノード−Ｂ  ６０３は、自分が分岐点ノード６１０であるが、ＢＲは既に1であることから、最初の分岐点ノード６１０Ｆではないと判断し、ＢＲの操作を行わない（ＢＲ＝１のままとする）。ステップＳ３３０７に続いて、中継ノード−Ｂ  ６０３は、書き換えた要求メッセージ６０７をデータ−ｂ保持ノード６０６およびデータ−ａ保持ノード６０５に転送する（ステップＳ３３０８、Ｓ３３０８’）。なお、中継ノード−Ｂ  ６０３は、本要求メッセージ６０７に対してＡＨ＝１に書替えたこと、自分が最初ではない分岐点ノード６１０Ｆであることを覚えておく。
【０２７９】
データ−ｂ保持ノード６０３およびデータ−ａ保持ノード６０２は、受信した要求メッセージ６０７において、ＢＲ＝１であることを確認し、応答メッセージ６０８を作成する（ステップＳ３３０９、Ｓ３３０９’）。データ−ｂ保持ノード６０３およびデータ−ａ保持ノード６０２は、応答メッセージ６０８に要求メッセージ５０７のＰＬ、ＡＨ、ＡＥ、ＢＲ、ＢＭの値をコピーする。そしてデータ−ｂ保持ノード６０３およびデータ−ａ保持ノード６０２は、応答メッセージ６０８のＣｏｎｔｅｎｔ部にそれぞれ自分の持つデータ(データ−ｂまたはデータ−ａ）を入れる（ステップＳ３３０９、Ｓ３３０９’）。次に、データ−ｂ保持ノード６０３およびデータ−ａ保持ノード６０２は、それぞれ自分が作成した応答メッセージ６０８を中継ノード−Ｂ  ６０３に転送する（ステップＳ３３１０、Ｓ３３１０’）。
【０２８０】
中継ノード−Ｂ  ６０３は、２つの応答メッセージ６０８（データ−ａ、データ−ｂ）の到着を待つ。中継ノード−Ｂ  ６０３は、応答メッセージ６０８においてＰＬ＝１、ＡＨ＝１、ＢＭ＝１０であることを確認する。中継ノード−Ｂ  ６０３は、自分が最初ではない分岐点ノード６１０であるが、ＢＭ＝１０であることと、自分がＡＨをオンにし、アプリ−１を持つことから、アプリを実行すべきと判断する。
【０２８１】
データ−ａおよびデータ−ｂは受信した応答メッセージ６０８に含まれるため、これらを使って、中継ノード−Ｂ  ６０３はアプリ−１の実行を行う（ステップＳ３３１１）。そして中継ノード−Ｂ  ６０３は、応答メッセージ６０８においてＣｏｎｔｅｎｔ部に実行結果を入れた応答メッセージ６０９を作成する（ステップＳ３３１２）。そして中継ノード−Ｂ  ６０３は、作成した応答メッセージ６０９を中継ノード−Ａ  ６０２に転送する（ステップＳ３３１３）。このとき、中継ノード−Ｂ  ６０３は、自分が最初ではない分岐点ノード６１０であること、自分が最初にＡＨを０から１にセットしたのではないことから、ＡＨ＝１のまま転送する（ステップＳ３３１３）。
【０２８２】
中継ノード−Ａ  ６０２は、２つの応答メッセージ（データ−ｃ、データ−ａとデータ−ｂの演算結果）の到着を待つ。中継ノード−Ａ  ６０２は、応答メッセージにおいてＰＬ＝１、ＡＨ＝１であることを確認し、また自分がＡＨをオンにしたことを確認する。また中継ノード−Ａ  ６０２は、ＢＭ＝１０であることを確認する。中継ノード−Ａ  ６０２は、自分が最初の分岐点ノード６１０Ｆであることを記憶しており、自分がアプリ−１を持っていることから、アプリを実行すべきと判断する。データ−ｃ、および、データ−ａとデータ−ｂの演算結果は、受信した応答メッセージ６０８、６０９に含まれるため、これらを使い、中継ノード−Ａ  ６０２は、アプリ−１の実行を行う（ステップＳ３３１４）。中継ノード−Ａ  ６０２は、受信した応答メッセージ６０８、６０９のいずれか１つに対し、ＡＨ＝０、ＢＲ＝０と更新し、Ｃｏｎｔｅｎｔに実行結果を入れた応答メッセージ６０９’を作成する（ステップＳ３３１５）。続いて、中継ノード−Ａ  ６０２は、作成した応答メッセージ６０９’をリクエスタ６０１に転送する（ステップＳ３３１６）。
【０２８３】
リクエスタ６０１は、応答メッセージ６０９’により、アプリ実行結果を受け取る（ステップＳ３３１６）。
【０２８４】
第３の実施形態のネットワーク動作によって、アプリやデータの転送遅延と占有帯域を削減して、レスポンス時間を短縮することができる。また、ネットワーク内でのアプリ実行処理の負荷分散を実現し、実行リソースの有効利用を図ることができる。
【０２８５】
以上の実施形態に関して、更に以下の付記を開示する。
（付記１）
データ要求先ノードとリクエストノードの経路にあるアプリ実行可能ノードのうち、どのノードにアプリを実行させるかを、前記アプリの実行結果である出力データ量と前記アプリの実行のために必要である入力データ量とに基づいて決定する実行ノード決定手段と、
前記データ要求先ノード又は前記アプリ実行可能ノードに向けて通信される前記アプリの実行を要求する要求メッセージに、前記決定されたノードの識別情報を設定する要求メッセージ設定手段と、
を備える通信装置。
（付記２）
前記実行ノード決定手段は、前記データ要求先ノードに近いノードに前記アプリを実行させるか、前記リクエストノードに近いノードに前記アプリを実行させるかを示す実行ポリシを、前記アプリの実行結果である出力データ量と前記アプリの実行のために必要である入力データ量とでどちらが大きいかによって決定し、
前記要求メッセージ設定手段は、前記要求メッセージに、前記ノードの識別情報として少なくとも前記実行ポリシの識別情報を設定する、
付記１に記載の通信装置。
（付記３）
前記アプリ実行可能ノード及び前記データ要求先ノードは、前記要求メッセージ及び／又は該要求メッセージに対応する応答メッセージ中の前記ノードの識別情報に基づいて前記アプリを実行する、
付記１又は２記載の通信装置。
（付記４）
前記要求メッセージ及び該要求メッセージに対応する応答メッセージは更に、アプリ保持識別情報、及びアプリ実行可能識別情報を含み、
前記アプリ実行可能ノード及び／又は前記データ要求先ノードの各ノードは、自ノードでの前記アプリの保持状態及び／又は前記アプリを実行可能なリソースの保持状態に応じて、前記自ノードが中継する前記要求メッセージ中の前記アプリ保持識別情報及び／又は前記アプリ実行可能識別情報の各情報を順次設定し、前記応答メッセージ中の該各情報と前記ノードの識別情報の設定状態に基づいて前記アプリを実行し、該実行の結果を前記応答メッセージに加えて前記リクエストノードに返す、
付記３記載の通信装置。
（付記５）
前記要求メッセージ及び該要求メッセージに対応する応答メッセージは更に、分岐点情報と分岐モード情報とを含み、
前記経路上に単数または複数の分岐点ノードが存在する場合に、
前記アプリの特性と支配的な前記入力データの数に応じて、前記アプリの実行を分岐点ノードで行うか否かと、前記アプリ実行が分岐点ノードで行われる場合にいずれの分岐点ノードで行われるかと、を前記実行ノード決定手段は決定して、該決定結果を分岐モード情報として要求メッセージに格納し、
前記単数または複数の分岐点ノードは、受け取った前記要求メッセージ中において前記分岐点情報を設定し、
前記アプリ実行可能ノード及び／又は前記データ要求先ノードの各ノードは、前記応答メッセージ中における、前記設定された分岐点情報と、前記分岐モード情報と、前記アプリ保持識別情報及び／又は前記アプリ実行可能識別情報と、前記ノードの識別情報との設定状態に基づいて前記アプリを実行する、
付記４に記載の通信装置。
（付記６）
前記実行ノード決定手段は、前記分岐モード情報を、分岐点無しの場合と、前記アプリ実行を最初の前記分岐点ノードで行わせる場合と、前記アプリ実行を複数の分岐点ノードにより分担して行わせる場合とに応じて設定する、
付記５に記載の通信装置。
（付記７）
前記アプリ実行可能ノード及び前記データ要求先ノードの各ノードは、自ノードから所定ホップ内に位置し前記経路上に無い近傍ノードを含む、付記１乃至６の何れかに記載の通信装置。
（付記８）
前記実行ノード決定手段は、前記アプリの種別毎に前記実行ポリシを登録した設定テーブルを記憶し、前記要求メッセージの通信時に、該要求メッセージが実行を要求するアプリの種別で前記設定テーブルにアクセスすることにより前記実行ポリシを決定する、付記２乃至７の何れかに記載の通信装置。
（付記９）
前記要求メッセージ設定手段は、前記アプリの実行に必要な要素オブジェクトのうち最大サイズの、単数または複数の要素オブジェクトを探索し、該最大サイズの、単数または複数の要素オブジェクトを宛先として前記要求メッセージに設定する、付記１乃至８の何れかに記載の通信装置。
（付記１０）
データ要求先ノードとリクエストノードの経路あるいは経路近傍にあるアプリ実行ノードのうち、どのノードに前記アプリを実行させるかを、前記アプリの実行結果である出力データ量と前記アプリの実行のために必要である入力データ量とに基づいて決定する実行ノード決定手段と、
前記データ要求先ノード又は前記アプリ実行可能ノードに向けて通信される前記アプリの実行を要求する要求メッセージに、前記決定されたノードの識別情報を設定する要求メッセージ設定手段と、
を備え、
前記アプリ実行可能ノード及び前記データ要求先ノードは、前記要求メッセージ中の前記ノードの識別情報に基づいて前記アプリを実行する、
通信システム。
（付記１１）
データ要求先ノードとリクエストノードの経路あるいは経路近傍にあるアプリ実行可能ノードのうち、どのノードにアプリを実行させるかを、前記アプリの実行結果である出力データ量と前記アプリの実行のために必要である入力データ量とに基づいて決定し、
前記データ要求先ノード又は前記アプリ実行可能ノードに向けて通信される前記アプリの実行を要求する要求メッセージに、前記決定されたノードの識別情報を設定し、
前記アプリ実行可能ノード及び前記データ要求先ノードにおいて、前記要求メッセージ中の前記ノードの識別情報に基づいて前記アプリを実行する、
通信方法。
【符号の説明】
【０２８６】
４００  通信システム
４０１、６０１  リクエスタ
４０２、６０２  中継ノード−Ａ
４０３、６０３  中継ノード−Ｂ
４０４、６０４  “アプリ−１”保持ノード
４０５、６０５  データ−ａ保持ノード
４０６、６０６  データ−ｂ保持ノード
４０７、６０７  要求メッセージ
４０８、４０９、６０８、６０９、６０９’  応答メッセージ
６１０  分岐点ノード
６１０Ｆ  最初の分岐点ノード
６１１  データ−ｃ保持ノード
７０１  プロセッサ
７０２  メモリ
７０３  記憶装置
７０４  送受信インタフェース（データ通信用）
７０５  送受信インタフェース（管理用）
７０６  バス
【図１】
2018014077.tif 000003
【図２】
2018014077.tif 000004
【図３】
2018014077.tif 000005
【図４】
2018014077.tif 000006
【図５】
2018014077.tif 000007
【図６】
2018014077.tif 000008
【図７】
2018014077.tif 000009
【図８】
2018014077.tif 000010
【図９】
2018014077.tif 000011
【図１０】
2018014077.tif 000012
【図１１】
2018014077.tif 000013
【図１２】
2018014077.tif 000014
【図１３】
2018014077.tif 000015
【図１４】
2018014077.tif 000016
【図１５】
2018014077.tif 000017
【図１６】
2018014077.tif 000018
【図１７】
2018014077.tif 000019
【図１８】
2018014077.tif 000020
【図１９】
2018014077.tif 000021
【図２０】
2018014077.tif 000022
【図２１】
2018014077.tif 000023
【図２２】
2018014077.tif 000024
【図２３】
2018014077.tif 000025
【図２４】
2018014077.tif 000026
【図２５】
2018014077.tif 000027
【図２６】
2018014077.tif 000028
【図２７】
2018014077.tif 000029
【図２８】
2018014077.tif 000030
【図２９】
2018014077.tif 000031
【図３０】
2018014077.tif 000032
【図３１】
2018014077.tif 000033
【図３２】
2018014077.tif 000034
【図３３】
2018014077.tif 000035
【図３４】
2018014077.tif 000036
【図３５】
2018014077.tif 000037