(57)【特許請求の範囲】
【請求項１】
アプリケーションを実行可能な情報処理装置と、サービスを要求する複数の端末とが配置される情報通信処理システムであって、
前記端末に接続される第一のネットワークノードと、
第一のネットワーク経由で前記第一のネットワークノードに接続され、第二のネットワーク経由で前記情報処理装置に接続される第二のネットワークノードと、
前記第一のネットワークノードと前記第二のネットワークノードを管理する管理ノードと、を備え、
前記第一のネットワークノードは、前記情報処理装置を宛先とするパケットを、前記第二のネットワークノードを介して送信し、
前記第二のネットワークノードは、前記パケットを受信した場合、前記パケットの内容を解析し、
解析の結果、前記パケット及び前記アプリケーションに関連する処理が可能なプロセッサを前記第二のネットワークノードが有する場合は、前記パケットを前記プロセッサに出力し、前記プロセッサによる処理結果を含むパケットを、前記第一のネットワークノードに送信し、
前記情報処理装置は、前記第二のネットワークノードを介して前記パケットを受信した場合、前記アプリケーションを実行する、
ことを特徴とする情報通信処理システム。
【請求項２】
請求項１に記載の情報通信処理システムであって、
前記第一のネットワークノードはパケットが送受信されるインタフェースと、
前記インタフェースが受信した前記パケットを処理する処理部を備え、
前記処理部は、
前記端末から受信したパケットに対して演算処理、フィルタ処理或いは集約処理を行い、
更に処理結果を選択して送信する、
ことを特徴とする情報通信処理システム。
【請求項３】
請求項２に記載の情報通信処理システムであって、
前記処理部は、
前記第二のネットワークノードから受信したパケットに基づき、処理コマンドを生成して、前記端末に送信する、
ことを特徴とする情報通信処理システム。
【請求項４】
請求項２に記載の情報通信処理システムであって、
前記処理部は、
受信したパケットのヘッダ、又はヘッダとペイロードを解析した結果、受信した前記パケットが蓄積データを要求するパケットである場合、前記第一のネットワークノードが蓄積している蓄積データを前記インタフェース経由で送信する、
ことを特徴とする情報通信処理システム。
【請求項５】
請求項２に記載の情報通信処理システムであって、
前記管理ノードは、
前記第一のネットワークノードの前記演算処理、前記フィルタ処理或いは前記集約処理の内容を蓄積する管理テーブルを備え、前記管理テーブルの内容を前記第一のネットワークノードに送信する、
ことを特徴とする情報通信処理システム。
【請求項６】
請求項１に記載の情報通信処理システムであって、
前記第二のネットワークノードは、複数のプロセッサと通信制御部を備え、
前記複数のプロセッサの内、少なくとも一つのプロセッサを、前記管理ノードによって割当てられたアプリケーションを実行するために用い、
受信した前記パケットのヘッダ、又はヘッダとペイロードを解析した結果が前記管理ノードによって指定された宛先条件に合致した場合、
前記通信制御部は、前記受信したパケットを、前記プロセッサ、又は前記プロセッサの属する前記第二のネットワークノード以外の別の第二のネットワークノードの内、少なくとも一以上の合致した宛先に転送する、
ことを特徴とする情報通信処理システム。
【請求項７】
請求項６に記載の情報通信処理システムであって、
前記通信制御部は、
予め定めた規則に従って前記パケットのヘッダ及びペイロードの少なくとも一部が一致する複数の前記パケットを、同一のフローに対応付け、
前記フローの宛先を示すテーブルを備え、前記テーブルに従い、複数の前記パケットの宛先を、前記対応づけられる前記フローの宛先に変更する、
ことを特徴とする情報通信処理システム。
【請求項８】
請求項７に記載の情報通信処理システムであって、
前記通信制御部は、
前記プロセッサの負荷情報に基づき、前記テーブルの前記宛先を書換える、
ことを特徴とする情報通信処理システム。
【請求項９】
請求項７に記載の情報通信処理システムであって、
前記管理ノードは、
前記第二のネットワークノードに、前記情報処理装置で実施する前記アプリケーションを複製する要求、或いは前記テーブルの前記宛先の書換え要求を生成して、前記第二のネットワークノードに送信し、
前記第二のネットワークノードは、
前記管理ノードからの要求に従って、前記プロセッサにアプリケーションまたは前記アプリケーションに関連する処理を複製し、或いは前記書換え要求に基づき前記テーブルの前記宛先を書換える、
ことを特徴とする情報通信処理システム。
【請求項１０】
請求項６に記載の情報通信処理システムであって、
前記管理ノードは、
前記第二のネットワークノードの前記プロセッサが実行する前記アプリケーションまたは前記アプリケーションに関連する処理の実行先を変更するための候補情報を蓄積する管理テーブルを備え、前記管理テーブルの内容を前記第二のネットワークノードに送信する、
ことを特徴とする情報通信処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書及び図面で開示される技術は情報処理システムに係り、特にネットワーク経由で複数の情報通信機器がサービスを提供する分散情報通信処理技術に関する。
【背景技術】
【０００２】
近年、クラウドコンピューティングの台頭により、情報処理機器の所有から利用への流れが加速している。クラウドコンピューティングは、データセンタなどに配備されるサーバやストレージ等の情報通信技術（Information and Communication Technology；ＩＣＴ）機器の物理的な構成や所在を意識することなしに、ネットワーク経由でこれらのＩＣＴ機器が提供するサービスを利用する情報処理形態である。こうしたクラウドコンピューティングを用いるクラウドシステムは、従来のＩＣＴシステムに対して、柔軟迅速なシステム構築、運用コストの低減といったメリットを有する。【０００３】
特許文献１では、ローカルサーバなどの情報処理装置に対して、ユーザが明示的にアプリケーション実行処理を依頼した場合、ローカルサーバに該当するアプリケーションが存在しなければ、データセンタなどの情報処理装置宛にパケットを流し、実行処理を依頼する構成が開示されている。特許文献２においては、世界各地に分散配置された多数のサイトが存在する状況にあって、情報処理要求発行元の地域に応じて近接するサイトのアドレスを応答するように、ＤＮＳ(Domain Name System)によって宛先アドレスを付与し、情報処理要求元が適切なサイトを参照するためのシステムを開示している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−３１２３１２号公報
【特許文献２】特表２００２−５２０７３５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述した従来のクラウドシステムでは、情報処理機能は、一般に遠隔地に集約設置されるデータセンタで提供され、仮想化機能等を用いた設備集約・稼働率向上によりITサービスのコストダウンが実現されてきた。しかし、この情報処理機能を情報発生源に対して遠隔地のデータセンタに集約するアーキテクチャは、ITビジネスの中でもリアルタイム性を要求するアプリケーションや、電子マネーや交通制御、プラント制御、スマートグリッド、大規模監視等の社会インフラアプリケーションに適用するには、以下の三つの課題がある。【０００６】
一つ目の課題として、応答速度が挙げられる。リアルタイム性を要求するアプリケーションでは、秒オーダではなく、ミリ秒オーダの応答速度が必要となる。高品質ネットワークを利用しても、日米間であれば130ms程度、日本国内であっても遠距離都市間では25ms程度の往復遅延時間が通信遅延として発生しうる。また、ベストエフォートのネットワークでは、２倍以上の遅延も考えられ、ここに情報処理時間を含めると、社会インフラアプリケーションで要求されるミリ秒オーダの応答速度を満足できない。【０００７】
二つ目の課題として、省電力が挙げられる。遠隔地に配するデータセンタに多くのデータを送信することで通信量が増加し、ネットワークの消費電力も増加する。環境負荷低減等の観点から、省電力化は避けられない課題である。【０００８】
三つ目の課題として、信頼性が挙げられる。社会インフラアプリケーションでは、ミリ秒オーダの障害復旧や遅延時間保証などを提供するギャランティ型の信頼性が必要とされる。これは、従来のベストエフォート型のネットワークを前提とする場合満足できない。【０００９】
本発明においては、上述したアプリケーションの応答速度や省電力などの課題を解決することが可能な分散情報通信処理システム、方法およびネットワークノードを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記の目的を達成するため、本発明の一態様は、情報処理装置とサービスを要求する複数の端末とが配置される情報通信処理システムであって、端末に接続される第一のネットワークノードと、第一のネットワーク経由で第一のネットワークノードに接続され、第二のネットワーク経由で情報処理装置に接続される第二のネットワークノードと、第一のネットワークノードと第二のネットワークノードを管理する管理ノードを備える。第一のネットワークノードは、情報処理装置を宛先とするパケットを、第二のネットワークノードを介して送信する。第二のネットワークノードは、そのパケットを受信した場合は、そのパケットについて処理が可能なプロセッサを有する場合は、そのパケットの出力先をそのプロセッサに変更し、プロセッサによる処理結果を含むパケットを、第一のネットワークノードに送信する。また、情報処理装置は、第二のネットワークノードを介してパケットを受信した場合、アプリケーションを実行する。  また、別の本発明の態様では、複数の端末にサービスを提供するための情報通信処理方法で、端末に接続される第一のネットワークノードが、第一のネットワーク経由で第二のネットワークノードに接続され、第二のネットワークノードが第二のネットワーク経由で情報処理装置に接続されており、端末に前記サービスを提供するため、
前記第一のネットワークノードで、前記端末から取得した情報を用いて、前記情報処理装置を宛先とするパケットを前記第一のネットワークへ送出し、前記第二のネットワークノードで、前記第一のネットワークから前記パケットを受けた場合、前記パケットに含まれる宛先及び情報に基づいて、前記第二のネットワークノードが有する情報処理機能部または前記第二のネットワークノード以外のノードに前記パケットを出力し、前記第二のネットワークノードで、前記情報処理機能部による前記パケットに対する処理結果を含むパケットを、前記第一のネットワークノードに送信し、
前記第一のネットワークノードで、前記処理結果を含むパケットを受信し、前記端末に前記サービスを提供する、ことを特徴とする情報通信処理方法である。
、情報通信処理方法を提供する。【００１１】
更に、他の態様として、第一のネットワーク、第二のネットワークを介してパケットを送受信するネットワークノードであって、サービスを要求する複数の端末が接続された情報処理ノードと第一のネットワークを介してパケットを送受信し、情報処理装置と第二のネットワークを介してパケットを送受信するネットワークインタフェース部と、ネットワークインタフェース部が受信したパケットが入力され、入力されたパケットを任意の宛先に転送するための通信制御部と、ネットワークインタフェース部が受信したパケットに任意のアプリケーションを実行する情報処理機能部と、通信制御部は、複数のパケットの宛先を変更することにより、パケットを任意の宛先に転送可能な構成のネットワークノードを提供する。
【発明の効果】
【００１２】
本発明の態様により、社会インフラアプリケーションで要求されるミリ秒オーダの応答速度が得られ、また省電力化が図ることが可能な情報通信処理システムを実現できる。さらに、社会インフラアプリケーションとして必要とされる、ミリ秒オーダの障害復旧や遅延時間保証などを提供するギャランティ型の信頼性を得ることが可能となる。
【図面の簡単な説明】
【００１３】
【図１】第１の実施例の分散情報通信処理システムの構成図である。
【図２】第１の実施例に係る、エントランスノード（ＥＮ）の機能構成の一例を示す図である。
【図３】第１の実施例に係る、ＥＮの装置構成の一例を示すブロック図である。
【図４】第１の実施例に係る、インテリジェントノード（ＩＮ）の一構成例を示すブロック図である。
【図５】第１の実施例に係る、ＩＮ内部の通信制御部の一構成例を示すブロック図である。
【図６】第１の実施例に係る、管理ノード（ＭＮ）の一構成例を示すブロック図である。
【図７】第１の実施例に係る、データセンタ（ＤＣ）の一構成例を示すブロック図である。
【図８】第１の実施例に係る、ＭＮの記憶部に記憶されるＩＮ管理テーブルの一例を示す図である。
【図９】第１の実施例に係る、ＭＮの記憶部に記憶されるＥＮ管理テーブルの一例を示す図である。
【図１０】第１の実施例に係る、ＩＮ内の通信制御部に記憶されるフローテーブルの一例を示す図である。
【図１１】第１の実施例に係る、ＩＮ内の通信制御部に記憶されるフロー状態テーブルの一例を示す図である。
【図１２】第１の実施例に係る、ＥＮ内の記憶部に記憶されるＥＮ管理テーブルの一例を示す図である。
【図１３】第１の実施例に係る、ＥＮの処理の一例のフローチャート図である。
【図１４】第１の実施例に係る、ＩＮの処理の一例のフローチャート図である。
【図１５】第１の実施例に係る、ＤＣの処理の一例のフローチャート図である。
【図１６】第１の実施例に係る、ＥＮ、ＩＮ、ＭＮのノード状態管理処理の一例を示すフローチャート図である。
【図１７】第１の実施例に係る、ＭＮの管理情報再設定処理の一例を示すフローチャート図である。
【図１８】第１の実施例に係る、ＥＮ、ＩＮの管理情報再設定処理の一例を示すフローチャート図である。
【図１９】第１の実施例に係る、分散処理通信処理システムにおける情報の流れの説明図である。
【図２０】第１の実施例に係る、分散情報通信処理システムで用いる通信パケットの一例を示す図である。
【発明を実施するための形態】
【００１４】
以下、本発明の分散情報通信処理システムの一実施形態を図面に従い説明する。本発明の分散情報通信システムの好適な実施形態においては、情報処理を可能な限り情報発生源の近傍で行う。そして、情報処理を蓄積型情報処理とリアルタイム型情報処理に分類し、蓄積型情報処理はデータセンタを利用し、データの蓄積や蓄積情報から付加価値の高い情報、知識を生成するＫａａＳ（Knowledge as a Service）を担う。一方でリアルタイム型情報処理は、ネットワーク上に分散配置した情報処理機能搭載ネットワークノードを利用し、情報発生源近傍のネットワークノード上で処理すべきデータを選別しながら局所的に分散情報処理することで応答速度、省電力、信頼性等の課題を解決する。つまり、本発明の一実施形態では、第一のネットワークノード、第二のネットワークノード、及び情報処理装置が連携して分散情報通信処理を行い、端末にサービスの提供を行う構成の情報通信処理システムである。
【実施例１】
【００１５】
図１に第１の実施例に係る、分散情報通信処理システムの一構成例を示す。同図において、情報端末１０９やセンサ、監視カメラ類１０７などの情報発生源に近い側にリアルタイム型情報処理として、例えば第一のネットワークであるＬＡＮ(Local Area Network)などのネットワーク１０４に接続されたネットワークノードとして、第一のネットワークノードである、一次処理を行うエントランスノード（Entrance Node：ＥＮ）１０１と、より高度な二次処理を行う、第二のネットワークノードであるインテリジェントノード（Intelligent Node：ＩＮ）１０２を分散配置する。たとえば、ＥＮ１０１では、一次処理として、情報発生源１０７、１０８、１０９からの情報の集約等を行うフィルタ処理１１３を担い、ＩＮ１０２では、リアルタイム型情報処理を行う情報処理１１２を担う。第二のネットワークであるＷＡＮ(Wide Area Network)などのネットワーク１０５を介して蓄積型情報処理１１１を担うデータセンタ（Data Center：ＤＣ）１０６を接続し、これらを管理ノード（Management Node：ＭＮ）１０３によって制御する構成である。【００１６】
ＥＮ１０１はＬＡＮ内の出入り口、ＩＮ１０２はＬＡＮ内、ＬＡＮ・ＷＡＮ間、ＷＡＮ内など様々な配置を取りうる。以下、本実施例の分散情報通信処理システムの特徴となるＥＮ１０１、ＩＮ１０２、ＭＮ１０６それぞれの役割について説明する。なお、第一、第二のネットワークは、上述したＬＡＮやＷＡＮに限定されるものでないことは言うまでもない。【００１７】
まず、ＥＮ１０１について説明する。ＥＮ１０１は、情報収集を行う監視カメラ、センサ類１０７、制御対象となるアクチュエータ１０８などを収容する。そして、センシング情報に対する一次処理として、後で詳述するように比較的単純な演算処理やフィルタ処理や集約機能を行い、情報を集約してＩＮ１０２へ転送する。この操作により、ネットワークへ送出する無駄なデータ量を削減し、省電力を実現する。【００１８】
また、ＤＣ１０６やＩＮ１０２からのフィードバック情報を受けてアクチュエータ１０８などの制御対象機器用の制御信号を生成し、優先度の高い処理から予め規定された順番どおりに実行し、応答速度の高い制御を実現する。【００１９】
ＩＮ１０２は、ネットワーク１０４経由で複数のＥＮ１０１や情報端末１０９等を収容する。そして、ＩＮ１０２は、ＥＮ１０１１０１や端末から受信するパケットを転送する通信処理だけでなく、ＩＮ１０２が当該パケットに対する情報処理を行う。具体的には、ＩＮ１０２は、これらの機器からのパケットを検査し、情報処理実行位置が自ＩＮ内か、他ＩＮかＤＣかを判定し、該当宛先に向けてパケットを転送する。さらに、ＩＮ２０２は、情報処理位置が自ＩＮである場合、処理要求に対する二次処理として、ＤＣ１０６に代わって情報処理、フィードバック情報生成を行い、その結果をＥＮ１０１や端末１０９に返答する。この処理により、通信遅延を削減し応答速度を改善する。この情報処理実行位置は、ＭＮ１０３からの指示に従い動的に変更することで、その時々で所望の応答速度、省電力を満たす。また、アプリケーション実行自体を高速化するために、予め定型的な処理内容をシステムに登録しておき、到着データとメモリ上の領域に登録してある直近一定期間のデータとの間で差分演算を高速に行うフロー方情報処理や、定型処理のハードウェア化、データベースのキャッシュなどの実行基盤を備えることで、情報処理自体の応答速度も改善する。【００２０】
ＭＮ１０３は、本システムによる情報処理サービスを受けたいユーザからの登録要求を受け付けると、ＩＰアドレスなどのユーザのネットワーク位置を特定する情報を元に、サービス要求条件に適するＩＮ１０２、ＥＮ１０１をユーザに割り当てる。このため、ＭＮ１０３は、ＩＮ１０２、ＥＮ１０１の性能情報や位置情報を収集し、応答速度、信頼性、省電力を考慮したアプリケーションの配置やリソースの設定、情報処理位置の設定等の運用管理を行う。また、通信遅延やアプリケーションの処理遅延をモニタし、分散情報通信処理システ上のボトルネック解析を行い、動的な情報処理位置の変更や通信経路の再設定などに利用する。【００２１】
続いて、図２、図３を用いてＥＮ１０１の詳細な構成の一例を説明する。【００２２】
図２は、本実施例のＥＮ１０１が実行する機能を示す機能ブロック図である。ＥＮ１０１は、ネットワーク通信機能２０１を介して、図１のセンサ類１０７、アクチュエータ類１０８、端末類１０９との間で、センシング情報、カメラ映像データ、制御信号を送受信する。ネットワーク通信機能２０１で受信されたデータは蓄積機能２０２で蓄積される。管理テーブル２０９、管理機能２０６の管理の下、送出データ選択機能２０７により、上位のネットワークに送出される送出データが、受信データや蓄積データに所望の演算やフィルタ・集約処理したデータ、もしくは、蓄積データそのものから逐次選択される。２０３、２０４、２０５はそれぞれ先に説明した演算機能、フィルタ機能、集約機能を示している。【００２３】
なお、この演算機能２０３、フィルタ機能２０４、集約機能２０５には、パケットのヘッダ情報の圧縮処理等の可逆な処理と、センサ類１０７のセンサ出力であるセンシング情報の量子化処理等の不可逆な処理がある。また、フィルタ機能２０４の内容は、ＥＮ１０１の内部に作りこまれたフィルタリング処理ライブラリとして読み出される場合と、ＩＮ１０２やＭＮ１０３などからプログラムとして配布される場合の二通りがある。【００２４】
可逆な処理としては、センサ類１０７によるセンシング情報の基準値からの差分計算処理、複数のセンシング情報のまとめパケット生成処理、規定された通信プロトコルに則ったヘッダ情報の圧縮処理（例えば、ＩＴＥＦ規格ＲＦＣ４９４４に規定あり）などがある。一方、不可逆な処理としては、不要なセンシング情報の破棄処理、センシング情報の平均値計算処理、最大値／最小値検出／判定処理、異常値判定処理、時間方向のサンプリング間引き処理、量子化処理や、カメラ画像情報のフレーム間引き処理、画像サイズ変更処理、顔検出、動き検出等の特徴抽出処理などがある。不可逆な処理を行ってセンシング情報の精度が落ちたり、意味合いが変化したりしてしまう場合も、蓄積機能２０２が、ＥＮ１０１の記憶部に処理前のデータをバッファリングしておくことで、後から必要な場合には、上位ノードであるＩＮ１０２、ＭＮ１０３、ＤＣ１０６からＥＮ１０１にアクセスし、処理前のデータを確認することができる。【００２５】
さて、ネットワーク通信機能２０８は、図１に示したＬＡＮなどのネットワーク１０４とのインタフェース部を構成している。ここから、集約されたデータ等が上位のネットワークに送出される。また、このネットワーク通信機能２０８は、上位からの制御信号等を受信し、フィードバック機能２１０、ネットワーク機能２０１を介して、アクチュエータ類１０８に制御信号等をフィードバックする機能も有する。【００２６】
図３は、本実施例のＥＮ１０１の装置構成の一例を示すブロック図である。同図において、３１０は上述した処理部を構成するプロセッサ、例えば中央処理部（Central Processing Unit：ＣＰＵ）である。同図のプロセッサ３０１中に、図２で説明した各種の機能、すなわち、演算機能、フィルタ機能、集約機能、管理機能、送出データ選択機能を模式的に図示した。【００２７】
また、プロセッサ３０１が接続された内部バス３０２には、ネットワーク通信機能２０１、２０８に対応するインタフェース部であるネットワークインタフェース、記憶部である、ＥＮ管理テーブル２０９が記憶されたメモリ３０４と蓄積機能２０２である記憶装置３０５、更にはマウスやキーボードやディスプレイなどが繋がる入出力部（Ｉ／Ｏ）３０６が接続されている。【００２８】
図３の、演算機能、フィルタ機能、集約機能、管理機能、送出データ選択機能は、記憶装置に格納されるプログラムをプロセッサ３０１が読みだし、実行することにより実現しているが、ＥＮ１０１の各種の機能は、専用のハードウェアとして構成されても良い。図１２に、ＥＮ１０１中のＥＮ管理テーブル２０９の一例を示した。図１に示すように、本実施例の分散情報通信システムにおいては、複数のＥＮ１０１が存在するが、各ＥＮ１０１はそれぞれ図２に示した管理テーブル２０９の内容を、後で詳述するＭＮ１０３から受信し、そのメモリ３０４中に蓄積する。ＥＮ管理テーブル２０９には、二種類のテーブル１２１０と１２３０が図示されている。一つは、フィルタ処理等、センサ、端末から上がってくる情報に対するテーブル１２１０、他の一つはＩＮ１０２やＤＣ１０６からのフィードバック情報に対するテーブル１２３０である。【００２９】
すなわち、同図のテーブル１２１０は、その対象であるセンサ１２２１Ａ〜１２２１Ｎ、端末１２２２Ａ〜１２２２Ｎには、センサ類１０７と端末類１０９各々からの入力データに対する演算機能、フィルタ機能、集約機能、蓄積機能、送出先である宛先や代替宛先に関する情報が蓄積されている。また、テーブル１２３０は、その対象であるアクチュエータ１２４１Ａ〜１２４１Ｎには、アクチュエータ類１０８に対するフィードバック制御のコマンド１２３１が蓄積される。【００３０】
次に、図４、図５を用いて本実施例のＩＮ１０２の構成の一例を説明する。【００３１】
図４は、ＩＮ１０２の内部のハードウェア構成の一例を示すブロック図である。同図において、４０１−１〜４０１−３は内部に設置されたサーバ機能部を構成する複数の情報処理用のサーバ、すなわち処理部であるプロセッサ、記憶部であるメモリ、ネットワークインタフェース、入出力部などを備えたコンピュータであり、上述したリアルタイム型の情報処理を実行する。４０１−４は管理機能部である管理用のサーバを示す。これらのサーバ４０１−１〜４０１−４は内部スイッチ４０３、通信制御部４０４、ネットワークインタフェース４０５経由で、各種のデータや制御情報をネットワークに送受信する。【００３２】
図４に示すように、ＩＮ１０２のネットワークインタフェース４０５−１〜４０５−４には、ＭＡＣ(Media Access Control)アドレスeth3、eth2、eth1、eth0が与えられ、サーバ４０１−１〜４０１−４にはそれぞれＩＰアドレスＩＰ Ｂ１〜ＩＰ Ｂ４、ＭＡＣアドレスeth4〜eth7が与えられている。スイッチ４０３と、サーバ４０１−１〜４０１−４、複数のネットワークインタフェース４０５−１〜４０５−４間は、本例ではイーサネット（登録商標）を用いて接続する。なお、これらのイーサネットとしては、例えば１０ギガビットイーサネットなどが使用できる。もちろん、イーサネットではなく当該装置専用の規格のインタフェースを用いても良い。なお、４０２は管理用ポートであり、図１の管理ノード（ＭＮ）１０３に接続され、各種の管理用データを送受信するために用いられる。【００３３】
同図において、通信制御部４０４は、通常のルータ装置同様に外部と通信し、パケットの転送制御をおこなう機能に加え、後で詳述するように、ＭＮ１０３の指示に従って情報処理位置を変更することで、特に通信遅延による応答速度を改善するための情報処理位置変更機能を備える。【００３４】
複数のサーバ４０１からなるサーバ機能部は、情報処理を行い、結果となるフィードバック情報を生成する。この際、複数のサーバによるアプリケーション実行自体を高速化し、情報処理の面でも応答速度を改善するための機能を提供できる。本実施例におけるＩＮ１０２のサーバ機能部４０１−１、４０１−２、４０３−３は、例えば、一定期間内の入力データの差分演算をメモリ上で行うフロー型情報処理機能、ＴＣＰ／ＩＰ(Transmission Control Protocol/Internet Protocol)等のプロトコル処理や定型的なアプリケーション処理、頻出処理を直接ハードウェアで実行するハードウェアオフローディング機能を提供する。【００３５】
管理機能部を構成する管理用サーバ４０１−４は、ＩＮ内資源の管理・設定、また収容するＥＮ１０１の管理を行う。これらの資源の情報や利用状況、負荷状況を定期的にＭＮ１０３に報告し、ＭＮ１０３からの新規のアプリケーション割当や削除、資源の再設定要求等に対応する。【００３６】
図２０に本実施例のシステムで用いる通信パケットのヘッダ部の主要なフィールドを抜粋した一例を示した。データリンク層であるレイヤ２（Ｌ２）ヘッダには、宛先ＭＡＣアドレス２０１０と、送信元ＭＡＣアドレス２０１１が配置されている。ネットワーク層であるレイヤ３(Ｌ３)ヘッダには送信元ＩＰアドレス(SIP)２０１２、宛先ＩＰアドレス(DIP)２０１３、プロトコル番号(Protocol)２０１４が配置されている。このＬ３ヘッダは、ＩＰ通信をする場合に、送信元ＩＰアドレス(SIP)２０１２から宛先ＩＰアドレス２０１３に対してパケットをルーティングするのに用いる。また、プロトコル番号(Protocol)２０１４によって、Ｌ４のプロトコル種別を区別する。本実施例のＩＮ１０２においては、これらは、フローを検出するための条件として利用する。【００３７】
更に、トランスポート層であるレイヤ４(Ｌ４)ヘッダには、送信元ポート番号(SP)２０１５、宛先ポート番号(DP)２０１６が配置されている。Ｌ４ヘッダは、通信するアプリケーションなどを示すために用いられるが、これらも、フローを検出するための条件として利用する。最後に、アプリケーション層であるレイヤ７(Ｌ７)ヘッダ、もしくはＬ７ペイロード（一部抜粋）にはセッション識別子(ID)２０１７とその他のペイロードが配置されている。このセッションID２０１７は、特定のユーザや情報発信元からのアクセスを認識するための識別子である。【００３８】
図５は、図４で上述した通信制御部４０４の機能構成の一例を示すブロック図である。図５に示すように、通信制御部４０４は、ネットワークインタフェース集約部５０１、パケット解析部５０２、フローテーブル５０７を備えたフロー検出部５０３、フロー状態テーブル５０８とルーティングテーブル５０９を備えた出力先決定部５０４、ネットワークインタフェース出力部５０５、テーブル更新部５０６の各機能ブロック、更には管理用ポート５１０から構成される。各種機能ブロックはソフトウェアのみならずハードウェアとして構成しても良い。ソフトウェアとして構成する場合、通信制御部４０４は、プロセッサ（ＣＰＵ）とメモリを使い、プロセッサがメモリ上のプログラムを実行することにより実現することができる。【００３９】
通信制御部４０４では、まず、ネットワークインタフェース集約部５０１は、図４の複数のネットワークインタフェース４０５−１〜４０５−４から流入するパケットを集約する処理を行う。ここで集約されたパケットはパケット解析部５０２に送られ解析される。なお、本実施例のシステムで使用されるパケットは、上述した通信プロトコルで用いられる通常の通信パケットを利用することができる。【００４０】
図５の通信制御部４０４は、通常の通信装置が宛先検索に利用するルーティングテーブル５１０のほかに、フローテーブル５０７とフロー状態テーブル５０８を備え、後で具体例を説明するように、ユーザのアプリケーションパケットを区別するためのサーチキー（search key）、通信状態を示す状態(status)、アプリケーション実行位置情報を管理する。サーチキーは、パケットヘッダ情報や、場合によっては、パケットペイロード情報が対象となる。通信状態(status)は、コネクションが確立されているか否かを管理、動的に実行位置を変える場合にコネクションが切断されている状況を選べるようにする。実行位置は、自ＩＮ内のサーバ機能部であれば、テーブルで明示的に当該サーバ機能部を指定する。この指定がある場合、ルーティングテーブル５１０より優先してこの宛先を利用する。他ＩＮ１０２やＤＣ１０６であれば、他ＩＮやＤＣを示す代表となる宛先情報を利用し、当該ＩＮ内での明示的なサーバ機能部指定は他のＩＮやＤＣに委ねることができる。【００４１】
ＩＮ１０２は、管理用ポート５１０を介してＭＮ１０３からの直接的な指示、若しくはポリシー設定により、該当ユーザに対するアプリケーションの実行位置を自身の内部サーバ４０１いずれか、若しくは他のＩＮ１０２、若しくは当初のＤＣ１０６へと変更する。このため、ＩＮ１０２は、自身の複数あるサーバ機能部の負荷状況をモニタし、ＭＮ１０３へ通知してＭＮ１０３、若しくは管理用サーバ４０１−４で実行位置再計算を行い、その結果をＩＮ１０２の上述のテーブルに反映し、動的に情報処理位置の変更を行う。【００４２】
このように、本実施例のシステムのＩＮ１０２の通信制御部４０４は、パケットを処理する情報処理の位置を変更する制御をおこなう。より具体的には、通信制御部４０４のテーブル更新部５０６により、フロー状態テーブル５０７中のインタフェース(interface)を書き換えることによって、パケットに付与するＬ２ヘッダのＭＡＣアドレスを変更する。例えば、ＩＮ１０２自身のサーバ４０１−１にパケットの宛先を強制的に変更する場合、送信元ＭＡＣアドレス２０１１を図４のeth0、宛先ＭＡＣアドレス２０１０をサーバ４０１−１のＭＡＣアドレスであるeth4と書き換えることによって、パケットをサーバ４０１−１に送信することができる。このように、通信制御部４０４は、通常の通信機能に加え、システムにおける情報処理位置変更機能を行う。【００４３】
すなわち、ネットワークにおける最適な処理位置は不変のものではなく、状況に応じて時々刻々と変化していく。これは、ネットワークの状態や、利用している計算資源の負荷状況、あるいはユーザ自体の物理的な空間の移動等に起因する。このため、本実施例のシステム構成では、上述の通信制御部４０４の構成により、ＭＮ１０３の指示の下、ＩＮ１０２に情報処理位置を変更させる。すなわち、上述のように、もともとＤＣ１０６で実行されるはず情報処理だったものを、ＩＮ１０２上のサーバ機能部で実行することや、自ＩＮ内の複数のサーバ４０１−１〜４０１−３間での情報処理の割り当ての変更や、逆に自ＩＮ１０２から他のＩＮ１０２やＤＣ１０６に、情報処理を追い出すための変更も行うことができる。なお、この情報処理位置変更機能については、後でフローテーブルやフロー状態テーブルの具体例を用いて説明する。【００４４】
さて、図６に、上述のＭＮ１０３の装置構成の一例のブロック図を示した。ＭＮ１０３は、例えば、情報処理装置であり、プロセッサ６０１が本実施例のシステムの運用管理を行う。プロセッサ６０１は内部バス６０２に接続され、内部バス６０２には、ネットワークインタフェース６０３、メモリ６０４、記憶装置６０５、入出力部（Ｉ／Ｏ）６０６が接続されている。記憶装置６０５は、プロセッサ６０１が、実行する管理情報設定プログラム６１０や参照する管理テーブル６０７を格納する。プロセッサ６０１が、管理情報設定プログラム６１０を実行するときは、メモリ６０４に管理テーブル６０７が保持される。【００４５】
このＭＮ１０３は、その運用管理機能として、ＩＮ１０２やＥＮ１０１の性能情報や位置情報を収集し、応答速度、信頼性、省電力を考慮したアプリケーションの配置やリソースの設定。情報処理位置の設定を行う。また、通信遅延やアプリケーションの処理遅延をモニタし、分散情報通信処理システ上のボトルネック解析を行い、動的な情報処理位置の変更や通信経路の再設定などに利用する。【００４６】
図７のＤＣ１０６の装置構成の一例のブロック図を示した。通常、ＤＣ１０６は外部ネットワークに接続され、ロードバランサとして機能する代表サーバ７０１とこの代表サーバ７０１に通信路７０２を介して接続される複数のサーバ７０３−１、７０３−２と記憶装置７０４とから構成される。記憶装置７０４は、サーバ７０３−１、７０３−２の背後に置かれるケースも多い。各サーバ７０３−１、７０３−２は、通常のコンピュータ構成を有し、プロセッサ７０５、内部バス７０６、インタフェース部であるネットワークインタフェース７０７、記憶部を構成するメモリ７０８と記憶装置７０９、更に入出力部（Ｉ／Ｏ）７１０を備えている。サーバ７０３内のプロセッサは、ＩＮ１０２内のプロセッサ同様、情報処理を実行するともに、更に蓄積処理を実行する。【００４７】
すなわち、ＤＣ１０６は、ネットワーク１０５を介して取得した各種の情報を、サーバ７０３内のプロセッサ７０５の蓄積処理により蓄積し、データベース（ＤＢ）化する。また、蓄積情報であるＤＢから付加価値の高い情報、知識を生成する処理を行う。このような、大量のＤＢを利用する処理は、上述したＥＮ１０１、ＩＮ１０２で実施できない処理である。【００４８】
以上、本実施例の分散情報通信処理システムの全体構成と、各構成要素の一構成例を説明したので、先に説明した情報処理位置変更機能に用いる、図５のＩＮ１０２の通信制御部４０４内のフローテーブル５０７とフロー状態テーブルの一具体例を図１０、図１１を用いて説明する。【００４９】
図１０にフローテーブル５０７の一例を示した。このフローテーブル５０７を用いて、図５のフロー検出部５０３は、フロー検出およびフロー番号の特定を行う。図１０のフローテーブル５０７に明らかなように、フロー検出に使用する上述したサーチキー（search key）１００１は、図２０に例示したパケットを解析して得た各種レイヤの情報に対応することは言うまでもない。そして、該当するフロー検出結果(result #)１００２が図５の出力先決定部５０４に出力される。各フローは、個々のアプリケーションに対応している。【００５０】
図１１に示すように、出力先決定部５０４は、フロー状態テーブル５０８を用いて、フロー検出部５０３の検出結果に基づき、該当パケットを出力するネットワークを決定し、ネットワークインタフェース出力部５０５に出力する。図１１に明らかなように、フロー状態テーブル５０８は、フロー(flow)番号１１０１に対応して、上述した通信状態を示す状態(status)１１０２、及び、上述のアプリケーション実行位置情報に対応する次ホップ(next hop)１１０３とインタフェース(interface)１１０４の情報を蓄積、更新している。なお、１１０５はアプリケーション実行位置情報の一つであり、明示的に設定される新宛先(new destination)欄を示している。図１１に示すように、状態(status)を保持しないアプリケーションに対して有効に働く。【００５１】
フロー状態テーブル５０８は、指定条件に合致するパケット群をフローとして認識し、フローのコネクション状態と宛先を保持し、管理する。アプリケーション実行位置を変える場合には、例えば、フローの優先度に応じて負荷の低いサーバ機能部へ割り当てなおす。この際、アプリケーションの実行に悪影響を与えないよう、コネクションが切断されているものに対してのみ、宛先情報を変更する。【００５２】
このフロー状態テーブル５０８の次ホップ(next hop)１１０３とは、次に中継する必要のある装置のＩＰアドレス（Ｌ３論理情報）で、インタフェース(interface)１１０４とは、next hop１１０３に接続されている当該装置のインタフェース名称（送信元MACアドレス相当、Ｌ２物理情報）である。宛先ＭＡＣアドレスは、next hop１１０３のＩＰアドレスに対してアドレス解決プロトコル(Address Resolution Protocol: ＡＲＰ）処理することで求まり、その結果は、一般に、ＡＲＰテーブルと呼ばれる情報リストに記録される。本実施例では、このＡＲＰテーブルの説明は省略する。【００５３】
図１１のフロー状態テーブル５０８では、フロー１１０１中のflow#0〜flow#3には、それぞれ状態(status)１１０２として「接続開始中」、「接続中」、「接続終了中」、「未接続」が対応している。なお、新宛先(new destination)１１０５は例えば、flow#3のように状態(status)１１０２が「未接続」の場合、新宛先の装置のＩＰアドレス（ＩＰ Ｄ）が、当該フローの最終宛先として設定されたことを示している。【００５４】
図１０にその一例を示したフローテーブル５０７の設定は、先に説明したＭＮ１０３が行う。具体的には、後でフローチャートを用いて説明するように、フローとして定義したいフィールドの組合せ、例えば上述の宛先ＩＰアドレス(DIP)、送信元ＩＰアドレス(SIP)、宛先ポート番号(DP)、送信元ポート番号(SP)などの組合せを列挙した情報を、フロー番号(flow#)と一緒にＩＮ１０２に通知される。これを受信したＩＮ１０２の通信制御部４０４が、テーブル更新部５０６を利用してフローテーブル５０７の設定更新を行う。尚、フロー番号と一緒に通知するフィールド組合せの情報と共に、各フローの優先度を定義して通知しても良い。フローテーブル５０７、フロー状態テーブル５０８は専用のハードウェア回路、もしくは、ソフトウェアにより作成することができる。【００５５】
さて、ＩＮ１０２自身宛以外のすべてパケットは、パケット解析部５０２でパケット内の各種のヘッダ情報、必要ならペイロード情報の解析をして、フローテーブル５０７が管理する要素を抽出したのち、フロー検出部５０３へ渡され、フロー検出部５０３が当該パケットのフロー番号(flow#)を特定する。ＩＮ１０２自身宛のパケットは、制御パケットであり、制御パケットの中身がフロー更新情報であれば、テーブル更新部５０６がフローテーブル５０７を更新する。また、制御パケットの中身が、後述する負荷情報であれば、フロー状態テーブル５０８の更新に利用される。【００５６】
後でフローチャートを用いて説明するように、フロー状態テーブル５０８の初期設定、および、フロー状態テーブル５０８の更新のためのポリシー定義は上述の通り、ＭＮ１０３が行う。具体的には、ＭＮ１０３は、初期設定として、対応するフローの次ホップ(next hop)、及びインタフェース(interface)の初期値を予め準備する。最初にＤＣ１０６上で動作しているアプリケーションであれば、次ホップ(next hop)はＤＣ１０６へパケットを転送するための次転送先の通信装置のＩＰアドレス、インタフェース(interface)は、その通信装置が接続されているＩＮ１０２の物理ポートとする。【００５７】
なお、フロー状態テーブル５０８をソフトウェアで作成する場合、例えば通信制御部４０４内のメモリ上にテーブルが作成される。なお、出力先決定部５０４には、通常のルーティングテーブル５１０も参照する。そして、本実施例において、フロー状態テーブル５０８に登録があるフローに関しては、ルーティングテーブル５１０によるルーティングではなく、フロー状態テーブル５０８に記載のルーティングを優先することで、パケットの宛先変更を可能にする。【００５８】
変形例としてフロー状態テーブル５０８をサーバ機能部のサーバ４０１内のメモリに備えても良い。この場合、通信制御部４０４では、宛先を変更する可能性のあるものは出力先決定部５０４で、通常のポリシーベースルーティングの機能を用い、アプリケーションの切れ目に関係なく、該当するフローに属するパケットを該当するサーバ４０１に転送する。サーバ４０１は、ソフトウェア的、論理的にフロー状態テーブル５０８を備え、そこでパケットを当該フロー状態テーブルの記載通りに転送する。サーバ４０１は通常ＣＰＵによるプログラム実行で動作するため速度的に問題があれば、サーバ４０４内に専用のハードウェア回路を設置することもできる。【００５９】
尚、宛先を自ＩＮ１０２のサーバ機能部に変更した場合は、自ＩＮのサーバ４０４は、自身のＩＰアドレス宛ではないパケットを受信することになる。通常のままだと、このパケットを受信することができないため、事前の設定、すなわち、フロー状態テーブル５０８で自身宛に設定するより前のタイミングで、当該フローの宛先ＩＰアドレスを受信できるように設定しておく。また、当該フローに対してパケット返信する場合には、送信元ＩＰアドレスを、本来の自身のＩＰアドレスではなく、上記の当該フローの宛先ＩＰアドレスとする。この操作により、例えば端末類１０９やＥＮ１０１では、本来の宛先ＩＰアドレス宛にパケットを送信しながら、実態として、本実施例のＩＮ１０２の複数のサーバからなるサーバ機能部上で、不整合を起こすことなく所望のアプリケーションの実行を行うことができる。【００６０】
さて、図１１のフロー状態テーブル５０８に示す新宛先(new destination)１１０５のフィールドを付加する場合、出力先決定部５０４において、入力パケットの宛先ＩＰアドレスを新宛先(new destination)１１０５に記載のIPアドレスに変更することになる。この場合、出力先決定部５０４は、一旦、通信の終端を行い、新たに、新宛先(new destination)１１０５に対して通信を開始することになる。すなわち、フロー状態テーブル５０８の新宛先(new destination)１１０５を用いる方法は、端末に対し一旦通信を終端し、新規の通信を新規宛先に対して行い、結果として端末が新規宛先と通信することになる。【００６１】
なお、上述した通り、本実施例のシステムにおいても、パケットのＩＮ１０２からの出力先を決定するために、ルーティングテーブル５０９を併用する。より具体的には、通信制御部４０４は、フロー情報テーブル５０８を検索した結果、登録がないことが判明すれば、その後に従来どおりルーティングテーブル５０９を検索して出力先を示す次ホップ(next hop)とインタフェース(interface）を決定する。なお、通信制御部４０４は、フロー情報テーブル５０８とルーティングテーブル５０９とを並列に検索しておいても良い。この場合、フロー情報テーブル５０８に登録があればフロー情報テーブル５０８の出力先を優先的に利用する。【００６２】
フロー情報テーブルもルーティングテーブルを用いても、通信制御部４０４は、ＩＮ１０２からの出力先を決定する点は共通している。しかしながら、ルーティングテーブルを用いる場合、通信制御部４０４は、ＯＳＰＦ(Open Shortest Path First)やＢＧＰ(Border Gateway Protocol)等のルーティングプロトコルにしたがって宛先ＩＰアドレスに対する出力先を決定するのに対し、本実施例におけるフロー状態テーブルを用いる場合は、ＭＮ１０３の指示、および、ＩＮ１０２のサーバ機能部の負荷状況によって、通信制御部４０４がパケット内の複数のフィールドに対応する出力先を決定する点で異なる。すなわち、本実施例におけるフロー状態テーブルを用いることによって、通信制御部４０４は、フローの状態に応じて出力先を変更し、アプリケーションを実行するサーバ位置、すなわち上述した動的な情報処理位置変更を行う。【００６３】
以上、本実施例における分散情報通信処理システムの装置構成の一例、及び情報処理位置変更機能の一例を説明した。次に、このシステムの全体動作を説明するに先立ち、本実施例のシステムで実施されるサービスの一例を図１９により概説する。その他のサービス例は実施例１の説明の後に続く他の実施例として纏めて説明する。【００６４】
図１９において、図１の全体システム構成図と同一番号を振られたブロックは同一のものを示す。同図のシステムにおいては、室内入り口の自動ドアに設置された監視カメラにより入室者の顔認証を行う、顔認証自動ドアシステムに適用した例を示している。同図において、１１９は監視カメラ付き自動ドアを示す。【００６５】
まず、監視カメラ付き自動ドア１１９から、矢印１９０１に示すように第一のネットワークノードであるＥＮ１０１にカメラ映像データが入力され、ＥＮ１０１で上述した演算機能あるいはフィルタ機能により顔画像の抽出を行う。抽出した顔画像データを矢印１９０２に示すように第二のネットワークノードであるＩＮ１０２に送出する。ＩＮ１０２では、顔画像データＤＢの一部をＤＣ１０６からキャッシュしておき、保有する前記顔画像ＤＢのデータを使ってＥＮ１０１から抽出・送信されてきた顔画像データとの顔一致確認し、一致と判断した場合、矢印１９０２に示すようにドア開放命令をＥＮ１０１に送出する。不一致の場合は、ドアを開けない命令を送出する。ドア開放命令を受けたＥＮ１０１は、対応する監視カメラ付き自動ドア１１９のドア制御機器の処理コマンドを生成して、その処理コマンドを矢印１９０１でフィードバックする。なお、矢印１９０３は、例えば、ＩＮ１０２の実行結果のログを蓄積する場合や、一致検出すべき顔画像ＤＢが不足している場合に顔画像ＤＢを要求し受け取る場合、ＩＮ１０２で一致検査ができない状況においてＤＣ１０６に処理を依頼して結果を受け取る場合を示している。【００６６】
続いて、以上説明した実施例１の分散情報通信処理システムの処理動作を図１３〜図１８の処理フロー図、および図８、９、を用いて説明する。図１３、図１４、図１５は、それぞれＥＮ１０１、ＩＮ１０２、ＤＣ１０６の基本的な処理フローを示している。【００６７】
図１３において、ＥＮ１０１はネットワークインタフェースに、センサ類１０７、アクチュエータ類１０８、端末類１０９、ＩＮ１０２等からのパケット受信が無いかを定期的にチェックし（ステップ１３０１、以後括弧内ではステップは省略）、パケットを受信した場合、パケット内容解析を行う（１３０２）。【００６８】
そのパケット内容はセンサ類１０７等の各種情報源からの情報か否かを判断し（１３０３）、各種情報源からの情報の場合（ＹＥＳ、以下省略する）、そのデータ保持を行う（１３０４）。そして、保持したデータに対して、必要な演算処理（１３０５）、フィルタ処理（１３０６）、集約処理（１３０７）を逐次実行する。上述の顔認証自動ドアシステムの場合、監視カメラからの画像データパケットを受信すると、各種情報源からの情報と判断し、顔画像抽出処理を施す。【００６９】
その結果を受け、ＩＮ１０２、ＤＣ１０６との連携処理が必要か否かを判断する（１３０８）。必要と判断された場合、その連携対象に対し、処理データを送信する（１３０９）。上記のサービスの場合、顔画像データをＩＮ１０２に送出する。【００７０】
ステップ１３０３で、パケット内容が情報源からの情報でない（ＮＯ、以下省略する）と判断された場合、そのパケット内容が上位のＩＮ１０２等からのフィードバック情報か否かの判断を行う（１３１０）。フィードバック情報の場合、ＥＮ１０１は処理コマンドの生成を行う（１３１１）。なお、先のステップ１３０８で否判断された場合も同様に処理コマンド生成を行う。生成された処理コマンドは、その処理対象へパケットとして送信される（１３１２）。上述のサービスの場合、このフィードバック情報として、例えば、「ドアを開ける」などの情報を受け取り、ドア制御機器の
処理コマンドを生成することになる。【００７１】
ステップ１３１０においてフィードバック情報で無いと判断した場合、引き続き指令内容は蓄積データ要求か否かを判断する（１３２０）。ＥＮ１０１が蓄積するデータの要求の場合、該当するデータパケットを要求先へ送信する（１３２１）。蓄積データ要求で無い場合、ＥＮ１０１で対処可能な要求の場合、その要求を実施する（１３３０）。【００７２】
図１４において、ＩＮ１０２は、ネットワークインタフェースに、配下のＥＮ１０１、端末類１０９やＤＣ１０６等からのパケット受信が無いかを定期的にチェックし（１４０１）、パケットを受信した場合、パケット宛先解析を行う（１４０２）。そして、パケット宛先対象か否かを判断し（１４０３）、宛先変更対象のパケットの場合は、その宛先が自ノードか否かの判断を行い（１４０４）、自ノードの場合に内部のサーバ機能部へ当該パケットを転送する。宛先変更対象のパケットで無い場合、通常のルーティングを行う（１４５０）。また、変更宛先が自ノード以外の場合、指定宛先へルーティングを行う（１４６０）。【００７３】
なお、このステップ１４０３のパケット宛先解析では、図１０、図１１を用いて説明したように、宛先ＩＰアドレスしか参照しない通常のルータ機能と異なり、本実施例のＩＮ１０２では、図２０に示したパケットの一つ以上のフィールド、指定があれば複数パケットのペイロードを結合したフローの内容などまで参照して宛先を解析する。その結果、ＩＮ１０２内のフロー状態テーブルに記載があれば、パケットに記載の宛先ＩＰアドレスとは異なる宛先、例えば、自ＩＮの中のサーバ機能部へパケットを転送する。ステップ１４０３の宛先変更対象とは、フロー状態テーブル５０８に記載があって、宛先ＩＰアドレス以外の情報もみて宛先を決めるパケットである、という意味を持つ。また、指定宛先とは宛先ＩＰアドレスでなく、フロー状態テーブル５０８の記載先の意味である。【００７４】
さて、図１４のフローに戻り、自ノードのサーバ機能部ではパケットが転送されると（１４０５）、必要データが揃ったか否かを判断し（１４０６）、揃った場合に、自ＩＮ１０２外のデータの参照が不要か否かを判断する（１４０７）。不要の場合は情報処理を実行して結果生成を行い（１４１１）、その結果を対象宛先へ、結果としてフィードバックする（１４１２）。更に、指定先でログ蓄積が必要か否かを判断し（１４１３）、必要な場合指定宛先へログ転送を行う（１４１４）。【００７５】
上記のサービス例では、必要な情報処理として、顔画像抽出を行い、蓄積あるいはキャッシュしている顔画像ＤＢと一致したら、ドアを開けるコマンドを生成して、ＥＮ１０１に、ＤＣでの処理と比較して遅延を少なくしたフィードバックを行う。不一致の場合は、ドアを開けないコマンドをフィードバックする。また、ＤＣ１０６へどの対象者に対してドアを開けたか等の制御内容を通知する。また、他の情報処理としては、例えば、共連れがないかの分析・検知も行い、共連れを検出した場合、予め登録しておいた個人やＤＣなどの宛先にアラームを通知する。【００７６】
なお、ステップ１４０７で自ＩＮ１０２外のデータが必要と判断された場合、当該処理が自ＩＮで処理可能か判断し（１４０８）、処理可能と判断した場合に必要なデータを要求し（１４０９）、データが到着したら（１４１０）、情報処理を行い結果を生成する（１４１１）。自ＩＮで処理不可と判断した場合、変更前の当初宛先へ転送する（１４７０）。上述のサービスの場合、一致検査すべき顔画像ＤＢが不足していればＤＣ１０６へ顔画像ＤＢを要求し、顔画像ＤＢを入手して上述の情報処理を継続する。更に、一致すべき顔画像ＤＢが不足していて、かつ、顔画像ＤＢをＤＣ１０３等が転送しないポリシーのため、一致検査できない状況にあればＤＣ１０３へ処理を依頼する。【００７７】
図１５において、ＤＣ１０６が、ネットワーク経由で、ＩＮ１０２からのパケット受信が無いかを定期的にチェックし（１５０１）、パケットを受信した場合、パケット内容解析を行う（１５０２）。その結果、その内容が蓄積しているデータの転送要求か否かを判断し（１５０３）、転送要求でない場合は、データ蓄積要求か否かを判断する（１５０４）。なお、内容がデータ転送要求の場合は、対象データを転送する（１５５０）。例えば、先のサービス例で、ＤＣ１０６は全ての顔画像ＤＢを保持しているので、一致する可能性のある顔画像データをＩＮ１０２に転送する。また、内容がデータ蓄積要求の場合は、受信データを蓄積する（１５６０）。【００７８】
蓄積要求でない場合には、必要なデータが揃ったか否かを判断（１５０５）、揃った場合に、情報処理源からの追加データの参照が不要かを判断し（１５０６）、不要の場合、情報処理を実行する（１５０９）。上述したサービス例で、例えば蓄積する顔画像ＤＢの顔画像データとの一致得検査などの情報処理を実行する。追加データの参照が必要な場合、データ要求を行い（１５０７）、データが到着したら、同様に情報処理を行う。そして、情報処理結果をフィードバックすると共に（１５１０）、ログ蓄積を行う（１５１１）。すなわち、顔画像と顔画像ＤＢとが一致したら、ドアを開けるコマンドをＩＮ１０２、ＥＮ１０１経由でフィードバックし、フィードバックした情報をログ蓄積する。【００７９】
以上が、本実施例におけるＥＮ１０１、ＩＮ１０２、ＤＣ１０６の基本処理フローである。続いて、図１６、図１７、図１８を用いてＥＮ１０１、ＩＮ１０２、ＭＮ１０３の状態管理フローと管理情報再設定フローの一例を説明する。【００８０】
図１６は、ＥＮ１０１、ＩＮ１０２、ＭＮ１０３で、それ自身または自身の配下のノードの状態を監視するための状態管理フローである。同図において、ＥＮ１０１の場合、各種のセンサ類１０７他の配下のデバイス状態とＥＮ１０１自身の状態を収集する（１６０１、１６０２）。そして、予め定められた時間が経過するか、例えば新規のセンサが追加されたなどの特定のイベントが発生した場合に、モニタ情報を上位の管理機構であるＩＮ１０２に通知する。(１６０３、１６０４)
ＩＮ１０２であれば、自身の配下のＥＮ１０１とＩＮ１０２自身の状態を収集し（１６０１、１６０２）、予め定められた時間が経過するか、例えば新規のＥＮ１０１が追加、除外、或いはＩＮ内部にサーバブレードの追加、削除があったなどの特定のイベントが発生した場合に、モニタ情報を上位の管理機構であるＭＮ１０３に通知する。(１６０３、１６０４)
ＭＮ１０３であれば、自身の配下のＩＮ１０２とＭＮ１０３自身の状態を収集し（１６０１、１６０２）、予め定められた時間が経過するか、例えば、新規のＩＮ１０２が追加された、除外された、ダウンした、或いは本システムに対する新規の情報処理要求登録があった、削除されたなどの特定のイベントが発生した場合に、情報処理の割当先を変更したほうがよい可能性があるため、再計算要求を出す。(１６０３、１６０４)
図１７は、ＭＮ１０３における管理情報再設定フローの一例を示している。管理情報の再設定は、管理要求の有無のチェック（１７００）で管理要求有の場合に、ＭＮ１０３の記憶装置６０５に格納されている管理情報設定プログラム６１０と管理テーブル６０７をプロセッサが、読み出し、開始する。例えば、プロセッサは、管理情報設定プログラムを実行し、新規登録や削除による再設定を行い、設定情報を作成、管理テーブルを更新する。すなわち、ＩＳＰ(Internet Service Provider)や企業の情報管理部門など、管理権限のあるユーザが、本システムのＭＮ１０３に対する管理要求として、利用したいアプリケーションに対する登録要求や削除要求を行う。この要求の際に、そのオプションとして、サービスレベルも指定することもできる。例えば、対象となるアプリケーションの特定の動作に関して、応答速度要求を100ms以内、応答速度要求を500ms以内、応答速度要求を1s以内、などのサービスレベルを指定することができる。以下、一例として新規登録を例に取り説明する。【００８１】
すなわち、新規登録要求があると、登録要求、削除要求の有無の判断（１７０１）で、要求が有りと判断され、ＭＮ１０３は対象アプリケーションを確認し（１７０２）、実行すべきＩＮ１０２やＥＮ１０１を特定し、特定されたＩＮ１０２やＥＮ１０１の設定情報を生成する（１７０３）。設定情報としては図６に示すＭＮ管理テーブル６０７、図８、図９に示すＩＮ管理テーブルとＥＮ管理テーブルとなる。各テーブルの詳細は後述する。【００８２】
そして、ＭＮ１０３は、該当するＩＮ１０２、ＥＮ１０１にアプリケーション情報、例えばＥＮ１０１の場合は、先に説明したような演算処理やフィルタ処理等のプログラムを配布する（１７０６、１７０７）。配布する情報としては、加重平均計算処理、集計処理やジョイン処理がいずれか、あるいは２種類以上の処理が記述されたクエリであってもよい。【００８３】
ついで、ＭＮ１０３は、ＩＮ管理テーブル、ＥＮ管理テーブルの必要情報も配布し（１７０８）、最後に、それらの設定を有効化する指令をＩＮ、ＥＮに出す（１５０９）。この処理によって、情報発生源であるセンサ類１０７の近傍で情報処理が開始される。【００８４】
なお、ステップ１７０１で登録削除要求とされた場合は、該当するユーザをテーブルから削除し、ＭＮ１０３は、その情報を配布、適用することになる。また、ステップ１７０１で、登録要求や削除要求で無いと判断された場合、再計算要求か否かを判断し（１７０４）、再設定要求の場合、設定情報の再生成を行う（１７０５）。また、ステップ１７０４において、再計算要求で無い場合は、管理処理を実行する（１７１０）。【００８５】
図１８は、ＭＮ１０３からの指示に基づき、ＥＮ１０１、ＩＮ１０２において、管理情報再設定にいたる処理フローの一例を示している。ここで再設定とは、管理要求がユーザなどからの要求で無く、ＩＮ１０２やＥＮ１０１の状況をモニタした情報に基づき設定する場合を意味する。図１６のステップ１６０４で再計算要求があると、ＭＮ１０３は管理すべき各種の情報の再計算を行い、新規の設定情報を生成する。その結果、特定のＩＮ、ＥＮに対してアプリケーションの配布が必要であれば、配布を行う。また、アプリケーション配布の有無に拠らず、各種の設定情報変更があれば、ＩＮ、ＥＮに対して通知する。例えば、ＩＮ１０２に対して、新規の情報処理要求をフロー状態テーブルに追記するように要求したり、情報処理位置を明示的にＤＣ１０６に戻したり、別ＩＮ１０２に移したり、これらのためのアルゴリズムを通知したりするなどである。この通知後、実際にその設定を反映するよう指令を出す。なお、この再計算自体をＩＮ１０２上の管理用サーバ４０１−４に任せても良い。【００８６】
図１８に示す処理フローはＥＮ１０１、ＩＮ１０２は共通するフローとなるため、以下、ＥＮ１０１の場合を説明する。【００８７】
同図において、ＥＮ１０１は制御情報の受信の有無をチェックし（１８０１）、制御情報を受信した場合、その制御情報がアプリケーションプログラムか否かを判断する（１８０２）。もし、アプリケーションプログラムの場合、当該プログラムをインストールする（１８０３）。アプリケーションプログラムで無い場合は、制御情報が設定情報か否かを判断し（１８１１）、設定情報の場合に当該設定情報の適用準備を行う（１８１２）。また、制御情報が設定有効化要求か否かを判断し（１８２１）、設定有効化要求の場合、当該設定情報の適用を実施する（１８２２）。一方、設定有効化要求で無い場合、制御情報が対処可能な要求であればそれを実施する（１８３１）。ここで処理される制御情報としては、障害発生時の処理方法の通知などの情報である。【００８８】
続いて、上述したＭＮ１０３に設置されたＩＮ管理テーブルとＥＮ管理テーブルの具体例を図面に従い説明する。【００８９】
図８、図９に、本実施例のシステムのＭＮ１０３の記憶部上に蓄積されるそれぞれ管理テーブル６０７の一例として、ＩＮ管理テーブル、ＥＮ管理テーブルの一実施例を示した。なお、図９に示したＥＮ管理テーブル９００−１〜９００−Ｎは、先に説明した図１２の各ＥＮ１０１が記憶する管理テーブルに対応し、本システム中の複数のＥＮ１０１−１〜ＥＮ１０１−Ｎのそれぞれの分を蓄積していることを示している。この管理テーブル９００中のデータが、図１７のステップ１７０８において、各ＥＮ１０１に配布され、その記憶部に記憶される。【００９０】
図９のＥＮ管理テーブルの内容は図１２のＥＮ管理テーブル２０９で説明した通りであるが、テーブル９１０中の宛先９１５は、該当アプリケーションの当初宛先としても良いし、ＭＮ１０３が明示的にＩＮ１０２の宛先を指定しても良い。また、代替宛先９１６とは、宛先９１５が利用できない場合の代替えとなる宛先を示している。なお、このＥＮ管理テーブル９００の生成、管理に関しては、物理的にはＭＮ１０３内部ではなく、ＩＮ１０２の管理用サーバ４０１−４で代行しても良い。【００９１】
図８のＩＮ管理テーブル８００−１〜８００−Ｎについて説明すると、各アプリケーションに対応するＩＮ管理テーブル８００−１〜８００−Ｎ各々は、対象情報８１０として、該当するユーザやアプリケーションを特定する条件を指定する。例えば、上述した通信パケットのSIP、DIP、SPORT、DPORT、PROTOCOLの５タプルで区別するなどの条件を指定することができる。【００９２】
その場合の条件の例として、
SIPが該当ユーザ、場合によっては、該当ユーザを収容するＥＮ１０１、
DIPが該当アプリケーションＡの当初宛先ＩＰ１（ＤＣ＃１）)、
SPORTが該当ユーザアプリケーションを示すポート番号、
DPORTが該当アプリケーションを示すポート番号、
PROTOCOLがＴＣＰ
とすることができる。【００９３】
もちろん、これだけでは条件不足の場合は更なる上位レイヤの情報を追加しても良いし、条件が多すぎる場合は条件を削っても良い。こうした情報をＩＮ管理テーブル８００の対象情報８１０に記載していく。【００９４】
また、ＩＮ管理テーブルの候補情報８２０として、当該アプリケーションに関する様々な情報を定義する。図８の例では、候補情報８２０として、変更後宛先８２１、続き処理宛先８２２、配布アプリケーション８２３、アプリ割当ポリシー８２４、テーブル更新ポリシー８２５を挙げている。ここで、変更後宛先８２１は、ＤＣである当初宛先ＩＰ１をどのＩＮ１０２へ移動するかを示し、第一候補の欄に対象となるＩＮを選んで記載する。【００９５】
この際、ＩＮの中の所定のブレードまで特定しても良いし、そこまでは特定せずに具体的な割当はＩＮの管理用サーバ４０１−４に任せても良い。その際にはアプリ割当ポリシー８２４によって、割当ポリシーを通知する。例えば、ＣＰＵ性能の合計が一定値を超えるように割り当てる方法がある。また、当該アプリケーションで要求されるＣＰＵ能力、メモリ容量を満たしているサーバのうち稼働率の低い一つ、または複数のサーバに割り当てる方法がある。そのほか、アプリケーション毎に優先度を決めて、優先度の高いアプリケーションは稼働率の低い一つ、または複数のサーバに割り当て、優先度の低いアプリケーションは稼働率の高い一つ、または複数のサーバに割り当てる方法もある。第二候補以下、別のＩＮが候補としてあるのであればそれを記載しても良い。オプションでサービスレベルなどを指定している場合、それを満足するＩＮを記載することになる。【００９６】
続き処理宛先８２２は、一個のＩＮだけでは処理を終えず、複数のＩＮに跨って処理を行う場合に記載する。続きの処理が不用である場合は設定する必要がない。【００９７】
配布アプリケーション８２３は、当該アプリケーションＡをＩＮ上で実行するためのアプリケーションプログラムを示す。このプログラムは実行バイナリでも良いし、当該ＩＮがコンパイルするためのソースコードでも良い。また、単独ファイルである必要はなく、複数ファイルでも構わない。【００９８】
テーブル更新ポリシー８２５は、ＩＮやＥＮの状況モニタの結果、当該アプリを利用した情報処理遅延が当初目論見を超えてしまう場合、例えば、サーバが過負荷になってアプリケーション実行自体が遅くなるような場合、実行位置を変えるためのポリシーを定義する。例えば、過負荷状態に陥った場合に、優先度の高いフローは、ＩＮ１０２内部の極力同じサーバ４０１に割当続け、優先度の中くらいのフローは、ＩＮ１０２内部の優先度の高いフローとは別のサーバ４０１に割り当て直す、優先度の低いフローは、第二候補のＩＮ１０２か、ＤＣ１０６に割り当てなおす、というものがあげられる。【００９９】
以上、第１の実施例の分散情報通信処理システムについて、顔認証自動ドアシステムを具体例として詳述した。以下の実施例において、他の適用サービスを順次説明する。なお、基本的なシステム構成、構成要素、処理フロー等は第１の実施例と同一であるので、以下の説明においては、各実施例と実施例１の差分についてのみ説明することとする。
【実施例２】
【０１００】
第２の実施例は工場の機器異常監視システムの実施例である。【０１０１】
ＥＮ１０１には、センサ類１０７、監視カメラ、更には監視端末装置が収容されている。ＥＮ１０１は、図１３の処理フローに沿い、センサ類１０７からの温度情報を一定周期で収集し、一定以上の変化が発生する度に、情報を集約機能等により、まとめてＩＮ１０２へ通知する。また、ＥＮ１０１に収容された端末類１０９である監視カメラからの監視画像を蓄積機能２０２によりバッファリングし、温度情報の通知とともに必要画像のみをＩＮ１０２へ通知する。これは、図１３のフローチャートで１３０１→１３０２→１３０３→１３０４→１３０５→１３０６→１３０７→１３０８→１３０９と遷移する内容に相当する。【０１０２】
ＩＮ１０２は、ＥＮ１０１からの通知情報により温度監視を行い、異常値を検出したらＥＮ１０１が収容する監視端末へ関係する画像をフィードバック情報として送信する。また、ＩＮ１０２は監視状況のログをＤＣ１０６へ通知する。なお、ＤＣ１０６自身が監視端末装置の場合は、画像配信もＤＣ１０６宛に行うことになる。これは、図１４のフローチャートで１４０１→１４０２→１４０３→１４０４→１４０５→１４０６→１４０７→１４１１→１４１２→１４１３→１４１４と遷移する内容に相当する。【０１０３】
ＥＮ１０１は、ＩＮ１０２から上記の監視端末装置へ画像配信があれば、当該監視端末装置へ画像配信する。例えば、温度監視をして異常値を検知したら、監視端末装置に適したフォーマットで画像配信を行う。これは、図１３のフローチャートで１３０１→１３０２→１３０３→１３１０→１３２０→１３３０、または、１３０１→１３０２→１３０３→１３１０→１３１１→１３１２と遷移する内容に相当する。
【実施例３】
【０１０４】
第３の実施例は、位置管理、すなわちセキュリティ管理システムの実施例である。【０１０５】
ＥＮ１０１には、センサ類１０７、ドア、ブザー、ライトなどのアクチュエータ類１０８が収容されている。そして、ＥＮ１０１はセンサ類１０７から部屋、場所などの位置情報を収集し、演算機能やフィルタ機能や集約機能で、過去の位置情報と照らし合わせを行い、移動した対象物のＩＤ（Identifier）、位置情報をＩＮ１０２へ通知する。これは、図１３のフローチャートで１３０１→１３０２→１３０３→１３０４→１３０５→１３０６→１３０７→１３０８→１３０９と遷移する内容に相当する。そして、アクチュエータ類１０８等の制御対象にフィードバック通知が到着したら、これらのアクチュエータ制御機器の処理コマンドを生成して、アクチュエータ類１０８を動作させる。これは、図１３のフローチャートで１３０１→１３０２→１３０３→１３１０→１３１１→１３１２と遷移する内容に相当する。【０１０６】
一方、ＩＮ１０２は、セキュリティ情報ＤＢを保持し、ＥＮ１０１から通知される対象物の位置情報を保持するセキュリティ情報ＤＢと照らし合わせ、権限の有無によりフィードバック情報を生成、ＥＮ１０１経由でアクチュエータ類１０８等の制御対象に通知を行う。また、ＤＣ１０６に対象物の位置情報を通知する。これは、図１４のフローチャートで１４０１→１４０２→１４０３→１４０４→１４０５→１４０６→１４０７→１４１１→１４１２→１４１３→１４１４と遷移する内容に相当する。制御対象への通知としては、例えば、権限のある対象であればドアを開ける、権限を持たない対象がある区画に入ったらライトを点灯、ブザーなどの警報を鳴らす、警備センタに通知するなどを行う。この場合、通知の対象宛先には警備センタなどが含まれる。【０１０７】
ＤＣ１０６では、ＩＮ１０２から通知される対象物の位置情報をログとして採取する。これは、図１５のフローチャートで１５０１→１５０２→１５０３→１５０４→１５６０と遷移する内容に相当する。更に、位置管理アプリケーションにより、監視員に対し、管理領域全ての位置のモニタ情報を提供し、提供情報を蓄積する。これは、図１５のフローチャートで１５０１→１５０２→１５０３→１５０４→１５０５→１５０６→１５０９→１５１０→１５１１と遷移する内容に相当する。
【実施例４】
【０１０８】
実施例４は、自身検視・設備異常監視システムの実施例である。【０１０９】
本実施例では、ＥＮ１０１は、加速度センサ、振動センサ、圧力センサ等のセンサ類１０７からセンサ情報を収集し、高速フーリエ変換（Fast Fourier Transform：ＦＦＴ)等の演算機能により演算を行って有効な揺れデータと無効な揺れデータを分離し、無効データは廃棄、有効データはＩＮ１０２へ通知する。これは、図１３のフローチャートで１３０１→１３０２→１３０３→１３０４→１３０５→１３０６→１３０７→１３０８→１３０９と遷移する内容に相当する。【０１１０】
ＩＮ１０２は、複数のＥＮ１０１から通知される有効データを詳細分析し、緊急対応が必要なデータを検知した場合は、アラーム、例えば、地震速報、または、巨大施設内の特定場所での異常速報をＥＮ１０１が収容している登録宛先とＤＣ１０６に対して通知する。また、有効データをＤＣ１０６に通知する。これは、図１４のフローチャートで１４０１→１４０２→１４０３→１４０４→１４０５→１４０６→１４０７→１４１１→１４１２→１４１３→１４１４と遷移する内容に相当する。
アラーム配信先を登録宛先として収容しているＥＮ１０１は、ＩＮ１０２からアラーム通知が来た場合に、アラーム配信先に適したフォーマットを生成して配信する。これは、図１３のフローチャートで１３０１→１３０２→１３０３→１３１０→１３１１→１３１２と遷移する内容に相当する。【０１１１】
ＤＣ１０６は、ＩＮ１０２から通知されるアラーム情報、有効データを蓄積する。これは、図１５のフローチャートで１５０１→１５０２→１５０３→１５０４→１５６０と遷移する内容に相当する。また、ＤＣ１０６は、必要に応じて詳細解析を行い、異常発生箇所の予測情報生成などを実施する。また、生成した予測情報などを蓄積する。これは、図１５のフローチャートで１５０１→１５０２→１５０３→１５０４→１５０５→１５０６→１５０９→１５１０→１５１１と遷移する内容に相当する。
【実施例５】
【０１１２】
続いて、実施例５は、監視システムに係り、センサ情報などはＥＮで保持し、ＤＣが必要時に必要分だけ採取するモデルである。【０１１３】
このシステムにおいては、ＥＮ１０１は、収容するセンサ類１０７や端末類１０９から拠点内の一個以上のセンサ情報やカメラ画像を収集する。センサ情報は、例えば、温度や振動、水量、音量などであり、これらの尾センサ情報に対し、閾値を設定し、閾値内の値であるときはセンサ情報、カメラ画像を廃棄、閾値外の値であるときに、発生した事象を意味するイベント情報を生成して、ＩＮ１０２に送信する。この時、センサ情報、カメラ画像そのものはＥＮ１０１で保持しておく。そして、ＩＮ１０２やＤＣ１０６からこれらの蓄積情報の転送要求があれば、要求元の該当宛先に対して要求されたデータを転送する。これは、図１３のフローチャートで１３０１→１３０２→１３０３→１３１０→１３２０→１３２１と遷移する内容に相当する。【０１１４】
ＩＮ１０２は、複数のＥＮ１０１からイベント情報を収集し、同じ系統、例えば、温度変化などの同じ系統の通知のイベント情報を集約し、ＤＣ１０６へ送信する。これは、図１４のフローチャートで１４０１→１４０２→１４０３→１４０４→１４０５→１４０６→１４０７→１４１１→１４１２→１４１３と遷移する内容に相当する。【０１１５】
本実施例において、ＤＣ１０６は監視センタとしての役割を持ち、イベント情報を元に、アプリケーション実行に必要なセンサ情報、または画像情報をＥＮ１０１から取得し、処理を行う。そして、その処理結果をログとして蓄積する。これは、図１５のフローチャートで１５０１→１５０２→１５０３→１５０４→１５０５→１５０６→１５０９→１５１０→１５１１と遷移する内容に相当する。この場合のフィードバック結果としては、監視センタであるＤＣ１０６のモニタなどとする。【０１１６】
以上詳述した本実施形態の分散情報通信処理システムは、ＭＮによって情報処理すべき位置を動的に管理する。ＥＮとＩＮをＤＣよりも情報発生源の十分近傍に配置し、ＥＮにより情報発生源近くで不用な情報をフィルタし、その情報をＤＣの代わりに、ＭＮによってアプリケーション実行の割当をうけた情報発生源近傍のＩＮで実行する。この処理方法により、従来、国外であれば１００ｍｓはかかっていた通信遅延を数ｍｓ以内のオーダに押さえ込むことが可能となる。このため、本実施形態のシステムによれば、従来では実現できない１０ミリ秒オーダのリアルタイム型情報処理を実現しうる。更に、ＥＮでの不要情報削減量に比例して従来生じていた伝送の消費電力を削減できる。【０１１７】
以上、本発明の種々の実施例を、直列的に配置するＥＮ１０１とＩＮ１０２を連携利用して実現する直列分散情報通信処理システムという観点で説明した。しかし、本発明の分散情報通信処理システムは上述した直列分散情報処理の実施例に限定されることなく、並列的に配置されるＩＮ１０２を複数利用する観点からも有効である。このような方法は、従来ＤＣ１０６で一極集中処理されていたものを、位置情報などの特定のパラメータによって実行すべき情報処理位置を複数のＩＮ１０２に分散するものである。ここでは、携帯電話画面を利用した電子看板システムに対する適用方法を例として示す。日本の全携帯電話（約１億台）を対象として電子看板システムを運営する場合、従来システムではＤＣに処理が集中するためＤＣの処理ネックや通信コストの問題が発生する。一方、本実施例の分散情報通信処理システムでは、地域ごとにＥＮ、ＩＮを配置し、各ＥＮ、ＩＮに特定の店舗に近づいた人およびその携帯電話だけを対象とした処理を行うことで、従来の問題を解消できる。【０１１８】
尚、いずれの実施例でもＥＮ１０１とＩＮ１０２が分離されているものとして説明してきたが、ＥＮ１０１の機能をＩＮ１０２の一機能に含めてもよい。【０１１９】
本実施形態のような分散情報通信処理システムでは、ネットワーク経由で複数の情報通信機器がサービスを提供する場合に、各情報通信機器に対して、リアルタイムなサービスを提供することができる。
【符号の説明】
【０１２０】
１０１…エントランスノード（ＥＮ）
１０２…インテリジェントノード（ＩＮ）
１０３…管理ノード（ＭＮ）
１０４、１０５…ネットワーク
１０６…データセンタ（ＤＣ）
１０７…センサ類
１０８…アクチュエータ類
１０９…端末類
２０１、２０８…ネットワーク通信機能
２０２…蓄積機能
２０３…演算機能
２０４…フィルタ機能、
２０５…集約機能
２０６…管理機能
２０７…送出データ選択機能
２０９、９００…ＥＮ管理テーブル
３０１、６０１…プロセッサ
３０２、６０２…内部バス
３０３、４０５、６０３、…ネットワークインタフェース
３０４、６０４…メモリ
３０５、６０５…記憶装置
３０６、６０６…入出力部（Ｉ／Ｏ）
４０１…サーバ
４０２、５１０…管理用ポート
４０３…スイッチ
４０４…通信制御部
５０１…ネットワークインタフェース集約部
５０２…パケット解析部
５０３…フロー検出部
５０４…出力先決定部
５０５…ネットワークインタフェース出力部
５０６…テーブル更新部
５０７…フローテーブル
５０８…フロー状態テーブル
５０９…ルーティングテーブル
６０７…ＭＮ管理テーブル
７０１…代表サーバ
７０２…通信路
７０３…サーバ
７０４…記憶装置
７０５…プロセッサ
７０６…内部バス
７０７…ネットワークインタフェース
７０８…メモリ
７０９…記憶装置
７１０…入出力部（Ｉ／Ｏ）
８００…ＩＮ管理テーブル。
【図１】
0005544006.tif 000002
【図２】
0005544006.tif 000003
【図３】
0005544006.tif 000004
【図４】
0005544006.tif 000005
【図５】
0005544006.tif 000006
【図６】
0005544006.tif 000007
【図７】
0005544006.tif 000008
【図８】
0005544006.tif 000009
【図９】
0005544006.tif 000010
【図１０】
0005544006.tif 000011
【図１１】
0005544006.tif 000012
【図１２】
0005544006.tif 000013
【図１３】
0005544006.tif 000014
【図１４】
0005544006.tif 000015
【図１５】
0005544006.tif 000016
【図１６】
0005544006.tif 000017
【図１７】
0005544006.tif 000018
【図１８】
0005544006.tif 000019
【図１９】
0005544006.tif 000020
【図２０】
0005544006.tif 000021