JP2003050786A

JP2003050786A - 分散情報収集システム

Info

Publication number: JP2003050786A
Application number: JP2001236589A
Authority: JP
Inventors: Tetsuo Ueda; 哲郎上田
Original assignee: Nissan Motor Co Ltd
Current assignee: Nissan Motor Co Ltd
Priority date: 2001-08-03
Filing date: 2001-08-03
Publication date: 2003-02-21
Also published as: US7254604B2; US20030028292A1

Abstract

(57)【要約】【課題】全体の通信量の増大を抑制すると共に、必要な
情報を容易に検索できる情報の分散収集−分散配信を可
能にするシステムを提供する。【解決手段】エージェントプログラム００９というソフ
トウェアを交通情報サーバに設けた仮想空間上に配置
し、そのエージェントプログラムがネットワークに接続
された移動体相互間を自律的に移動できるようにするこ
とにより、必要な情報をその情報を持っている対象から
収集者が直接に収集可能にし、必要とされていない情報
を交通情報サーバに保存しなくて済むようにした分散情
報収集システム。本発明においては、従来のプローブカ
ーのような分散情報収集−集中情報配信の形態をさらに
一歩進めて、情報の分散収集−分散配信を可能にするこ
とで、集中的な情報配信におけるボトルネックを解消さ
せ、情報を得たい者が適切な情報の収集を容易にできる
ようにした。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は交通情報などの移動
体（例えば車両）に関する情報を分散的に収集、分配す
る技術に関する。

【０００２】

【従来の技術】ネットワークの普及に伴ってさまざまな
情報が容易に手に入る時代になっているが、交通情報に
関しては未だ十分とはいえない。基本的な交通情報収集
手段は道路公団などが設置した特定地点の情報収集装置
に依存しており、情報収集地点が限られている。また、
それらの情報へのアクセス手段にしても、ネットワーク
上でオープンになっているものは少なく、カーナビゲー
ションなどの特定のハードウエアの機能によるか、旧来
のように交通情報センターなどへの電話やラジオによる
情報収集が基本になっている。このような集中的な交通
情報の収集と分配は現在のところ上手くいっておらず、
運転者に潜在的な不満を抱かせることになっている。

【０００３】これに対してプローブカーに代表されるよ
うな分散的な交通情報収集の試みがある（例えば特開平
１１−２５１３０号公報）。プローブカーとは、従来の
固定的に設置された情報収集装置に替わって、現在走行
中の全てあるいは一部の移動体（車両）を情報収集装置
として位置付け、それらから動的に交通情報をサーバに
収集することにより、ダイナミックに交通情報地図を作
成しようとするものである。この方法によれば原理的に
は移動体が走行している全ての道路の情報を入手でき
る。さらに、収集した情報をインターネットを通じて公
開することで、多くの運転者が現在の交通情報をリアル
タイムで把握することが可能となる。上記のように、プ
ローブカーによる交通情報は質量とも現在の集中的な情
報収集手段を上回るものと期待されている。

【０００４】上記のようなプローブカーの仕組みは、車
両の交通情報に関するものであるが、一般的には分散的
な移動情報収集手段の一形態とみなされる。例えば、移
動情報収集手段と移動情報サーバとの通信手段を歩行者
に取り付ければ、ダイナミックな人の動きを把握するこ
とも可能になる。従来の集中的な情報収集手段が都市の
インフラストラクチャーとの関係が強いため、一部の機
関に依存せざるを得なかったのに対し、上記のように交
通情報を含んだ移動情報を分散的に収集することは、よ
り柔軟に情報収集が可能なことから、この分野の情報の
自由化が促進される技術として期待されている。

【０００５】しかし、プローブカーに代表される分散的
な情報収集にも次のごとき問題がある。第１に、集中制
御方式なので情報取得の要求の負荷がサーバに集中し、
必然的に情報量が増えることから交通情報のサーバの負
荷が大きくなる点である。第２に、情報の鮮度を維持す
るには全てのプローブカーの情報を短い間隔で定期的に
サーバに取得する必要がある。そのためプローブカーは
情報をサーバに転送するために特定の頻度でサーバと通
信しなければならず、全体としての通信トラフィックが
増大する。第３に、個々のユーザ側からみると、必要な
情報は自身の経路とその周辺に関するものであって、そ
れも結果的な所要時間や事故などの突発的な情報であ
る。しかし、サーバでは全ての情報を保持しているの
で、膨大な量のデータから必要な情報を検索するための
煩雑さは解消されておらず、むしろ情報量が増えている
ために煩雑さは増大する可能性がある。以上のように、
プローブカーに代表にされる分散移動情報収集システム
においては、確かに収集装置の末端は分散化されている
が、その情報の集約先がサーバコンピュータなどの集中
システムとなるため、ボトルネックとなって分散システ
ムとしてのメリットを出しきれていない。これは、情報
の収集者から見た場合、収集者にとっては不必要な情報
が大量にサーバに保存されており、その中から必要な情
報のみを抜き出して利用しなければならない、という基
本的な構成に問題がある。また、情報の配信者からすれ
ば、必要とされているかどうか判らない情報を常に交信
しつづける必要があり、無駄な通信を増やしているとい
える。

【０００６】

【発明が解決しようとする課題】上記のように、従来の
交通情報センターなどによる集中情報収集−集中情報配
信型の情報収集システムにおいては、情報の内容が不十
分であってユーザが満足出来るものではなく、また、プ
ローブカーに代表される新しい情報収集システムにおい
ても、その内容が分散情報収集−集中情報配信型である
ため、上記のように、サーバの負荷の増大と不要な情報
の蓄積、全体の通信量の増大、情報検索の煩雑さ、等の
問題があった。

【０００７】本発明は上記のごとき従来技術の問題を解
決するためになされたものであり、全体の通信量の増大
を抑制すると共に、必要な情報を容易に検索することの
できる分散情報収集システムを提供することを目的とす
る。

【０００８】

【課題を解決するための手段】本発明では、従来のプロ
ーブカーのような分散情報収集−集中情報配信の形態を
さらに一歩進めて、分散情報収集−分散情報配信を可能
にすることで、集中的な情報配信におけるボトルネック
を解消させ、情報を得たい者が適切な情報の収集を容易
にできるようにしたものである。具体的には、エージェ
ントプログラムというソフトウェアを仮想空間上に配置
し、そのエージェントプログラムがネットワークに接続
された機器相互間を自律的に移動できるようにすること
により、必要な情報をその情報を持っている対象から収
集者が直接に収集可能にし、必要とされていない情報を
サーバに保存しなくて済むようにしたものである。

【０００９】まず、請求項１に記載の発明は、移動体側
の構成を示すものであり、移動体に搭載され、移動体に
おける情報を分散的に収集して分散的に配信するシステ
ムであって、必要とする情報収集を指示する手段と、指
示された情報収集を実施するための自律的プログラムで
あるエージェントプログラムを記憶する記憶手段と、前
記エージェントプログラムの送受信を行う通信手段と、
記憶しているエージェントプログラムの送信を行い、受
信したエージェントプログラムに従った所定の制御を行
う制御手段と、受信したエージェントプログラムに従っ
て実施した所定の制御結果の情報を送信する手段と、を
備えている。

【００１０】また、請求項２に記載の発明は、サーバ側
の構成を示すものであり、サーバとなるコンピュータと
通信手段から構成され、移動体における情報を分散的に
収集して分散的に配信するシステムであって、指示され
た情報収集を実施するための自律的プログラムであるエ
ージェントプログラムを複数の移動体との間で送受信す
る通信手段と、前記エージェントプログラム同士が情報
の交換を行うための、コンピュータ上に形成された仮想
空間と、受信した各エージェントプログラムを前記仮想
空間に配置するよう制御する手段と、を備えている。

【００１１】また、請求項３に記載の発明は、全体の構
成を示すものであり、移動体側には、必要とする情報収
集を指示する手段と、指示された情報収集を実施するた
めの自律的プログラムであるエージェントプログラムを
記憶する記憶手段と、エージェントプログラムの送受信
を行う通信手段と、記憶しているエージェントプログラ
ムの送信を行い、受信したエージェントプログラムに従
った所定の制御を行う制御手段と、受信したエージェン
トプログラムに従って実施した所定の制御結果の情報を
送信する手段と、を備え、サーバ側には、指示された情
報収集を実施するための自律的プログラムであるエージ
ェントプログラムを複数の移動体との間で送受信する通
信手段と、前記エージェントプログラム同士が情報の交
換を行うための、コンピュータ上に形成された仮想空間
と、受信した各エージェントプログラムを前記仮想空間
に配置するよう制御する手段と、を備え、自己の移動体
にとって必要とする情報を収集するための前記エージェ
ントプログラムを用いて、情報収集が指示されると、前
記仮想空間上で検索された必要とする情報を持っている
移動体のコンピュータヘ前記自己のエージェントプログ
ラムが移動し、当該エージェントプログラムが移動先の
コンピュータ内で必要とする情報の収集を行って自己の
移動体へ収集した情報を送信することにより、情報を分
散的に収集して分散的に配信するように構成している。

【００１２】また、請求項４に記載の発明は、本発明を
移動体の移動情報（例えば車両の交通情報）収集に適用
した構成であり、移動体側には、少なくとも移動体の移
動速度を含む自己の移動体の状態を検出する状態検出手
段と、前記自己の移動体の位置を検出する位置検出手段
と、を備え、前記エージェントプログラムに従って実施
した所定の制御結果の情報には、前記自己の移動体の状
態と位置との情報を含むように構成している。

【００１３】また、請求項５に記載の発明は、請求項１
または請求項３において、前記情報収集を指示する手段
は、当該移動体の使用者の操作によって情報収集を指示
するように構成したものである。また、請求項６に記載
の発明は、請求項１または請求項３において、前記情報
収集を指示する手段は、前記移動体の経路計算を行う際
に自動的に情報収集を指示するように構成したものであ
る。

【００１４】また、請求項７乃至請求項１５は、上記請
求項１乃至請求項３における詳細な構成を示すものであ
り、まず、請求項７に記載の発明は、それぞれの前記エ
ージェントプログラムがネットワーク上で一意に特定可
能なＩＤを保持できるエージェントプログラムＩＤ特定
手段を備えるように構成している。また、請求項８に記
載の発明は、自己の移動体のコンピュータにおける前記
エージェントプログラムが情報探索のために他の移動体
のコンピュータとの間で自律的に行き来できる移動手段
を備えるように構成している。また、請求項９に記載の
発明は、前記エージェントプログラムは、該エージェン
トプログラムが最初に生成された移動体と、現在属して
いる移動体と、一つ前に属していた移動体と、にそれぞ
れ対応した３つの状態になり得るように構成している。
また、請求項１０に記載の発明は、デジタル地図情報を
保持する地図データ保持手段と、該地図データ保持手段
のデジタル地図情報を元にした２次元仮想空間上にエー
ジェントブログラムを配置可能なエージェント仮想空間
を有するように構成している。また、請求項１１に記載
の発明は、前記２次元仮想空間に配置されたエージェン
トプログラムが保持している情報に基づいて必要な交渉
相手を検索できる検索手段を備えるように構成してい
る。また、請求項１２に記載の発明は、２次元仮想空間
から他の移動体上のコンピュータにエージェントプログ
ラムを移動させるための移動手段を備えるように構成し
ている。また、請求項１３に記載の発明は、前記各移動
体上のそれぞれのエージェントプログラムが保持する情
報に基づいて、各エージェントプログラム間で互いに交
渉できる交渉手段を備えるように構成している。また、
請求項１４に記載の発明は、任意の移動体上のエージェ
ントプログラムが、他の移動体のエージエントプログラ
ムと交渉可能な通信手段を備えるように構成している。

【００１５】

【発明の効果】本発明においては、情報の収集者は情報
の配信者から直接に必要な情報を入手できる。したがっ
て、サーバに蓄積されるべき情報は、必要な情報を持っ
ている配信者を表す情報（例えばＩＤ番号と位置情報な
どで、上記必要な情報の内容は不要）およびその検索手
段のみとなり、以後の情報収集は配信者からの直接受信
が可能となる。そのため中央に集中的な情報サーバを構
築する必要がなくなる。また、必要とする情報の収集者
とその情報を保持している配信者間で直接に情報の授受
が行われるので、不要な情報を定期的にサーバに送信す
る必要が無くなり、通信トラフィックを減少させること
が出来る。

【００１６】また、収集者が発したエージェントプログ
ラムが仮想空間上で配信者の移動体を検索して直接乗り
移るため、収集者は自身のエージェントプログラムを仮
想空間に送り出すだけで、自動的に適切な一つまたそれ
以上の配信者との情報収集手段を確立することができ
る。したがって、従来のようにサーバに蓄積された膨大
な量のデータから必要とする情報を検索する手間が不要
になる。

【００１７】また、エージェントプログラムは配信者の
移動体のコンピュータ上で自律的に動作するため、常に
配信者との通信回線を維持しておく必要はなく、渋滞の
終了や事故発生などイベントのあったときにだけ通知し
てもらうような配信形態が可能となる。そのため通信ト
ラフィックを減らすことができる。

【００１８】また、エージェントプログラムは配信者の
コンピュータ上で収集者の意図にあった情報の加工を行
うので、データをそのまま通信する方法に比べて通信量
を減らすことができる。

【００１９】また、エージェントプログラムは配信者側
のコンピュータで動作しているため、仮に通信環境の問
題などによって通信が途絶えたとしても、その間の情報
も収集しつづけており、通信回線が復活したときにその
サマリ（概要）を受け取ることができるため、通信環境
による情報の取りこぼしを避けることができる。

【００２０】

【発明の実施の形態】（第１の実施例）まず、第１の実
施例として、車両（移動体）間での交通情報の収集配信
システムに本発明を適用した場合を説明する。図１は第
１の実施例の全体構成を示すブロック図である。図１に
おいて、車両１側には、車速等の車両状態を検出するセ
ンサ群００１、ＧＰＳ（Global Positioning System）
などを利用して車両の現在位置を検出する位置計測装置
００２、車載コンピュータ００５が搭載されている。ま
た、コンピュータ００５の機能としてエージェントプロ
グラム配置手段００４が形成されている。エージェント
プログラム配置手段００４の内容としては、エージェン
トプログラム００９、ＩＤ特定手段０１０、分類手段０
１１、転送手段０１２、検索手段０１３、交渉手段０１
４があり、エージェントプログラム００９の中身として
は、エージェント固有プログラム００６、情報メモリ０
０７、移動手段００８がある。なお、これらの詳細につ
いては後述する。

【００２１】一方、地上局２側には、地図データベース
００３、サーバコンピュータ０１５が配置され、また、
コンピュータ０１５の機能としてエージェントプログラ
ム配置手段００４が形成されている。この内容は車両１
側と同様である。また、車両１側と地上局２側間、およ
び各車両相互間で情報交換を行う無線の通信手段３が設
けられている。

【００２２】次に、図２は、車両１側における車載コン
ピュータ００５の内容を示すブロック図である。この内
容が図１のエージェントプログラム配置手段００４に各
ブロックで示した内容に相当する。コンピュータ上には
ＷｉｎｄｏｗｓＣＥ（登録商標）やＩＴＲＯＮ（登録商
標）などアプリケーションソフトウエアが動作可能なオ
ペレーティングシステム２０５を搭載する。オペレーテ
ィングシステム２０５の上には、エージェントの配置と
動作が可能なエージェントプレース２０３を搭載する。

【００２３】エージェントプレース２０３は、例えばＪ
ａｖａのようなネットワーク対応言語で書かれたもので
ある。Ｊａｖａの場合はその前提としてＪａｖａＶＭ
（登録商標）２０４が必要になる。エージェントプレー
ス２０３の上には、それぞれの目的によって機能するエ
ージェントプログラム２０２を配置する。エージェント
プログラム２０２は例えばＪａｖａなどの言語で記述さ
れたもので、エージェントプレース２０３上にダイナミ
ックにロードされて動作するものである。

【００２４】エージェントプログラム２０２とエージェ
ントプレース２０３は、実際のヒューマンエージェント
にならって例えば図３に示すように構成する。図３にお
いて、エージェントはオフィスで仕事をしているものと
して、オフィスにある要素をＯｆｆｉｃｅＥｌｅｍｅｎ
ｔ３０１として定義する。ＯｆｆｉｃｅＥｌｅｍｅｎｔ
３０１は例えば名前を有し、オフィスに配置されるもの
である。ＯｆｆｉｃｅＥｌｅｍｅｎｔ３０１の派生とし
て、ＯｆｆｉｃｅＥｌｅｍｅｎｔ３０１を配置できるＯ
ｆｆｉｃｅＭａｎａｇｅｒ３０３を定義する。Ｏｆｆｉ
ｃｅＭａｎａｇｅｒ３０３は、ＯｆｆｉｃｅＥｌｅｍｅ
ｎｔ３０１のリストを保持し、それらの間のメッセージ
通信、生成、消滅などを管理するものである。

【００２５】また、ＯｆｆｉｃｅＭａｎａｇｅｒ３０３
の派生でＯｆｆｉｃｅ３０４を定義する。Ｏｆｆｉｃｅ
３０４とは、ネットワークに公開されたエージェントプ
レースそのものである。Ｏｆｆｉｃｅ３０４には、その
要素としてＯｆｆｉｃｅＥｌｅｍｅｎｔ３０１が登録さ
れており、ネットワークを介してＯｆｆｉｃｅＥｌｅｍ
ｅｎｔのやり取りを行うことができる。Ｏｆｆｉｃｅ３
０４はネットワーク上で特定できるように一意のＩＤを
もつ。例えばＴＣＰ／ＩＰによる通信を前提としたネッ
トワークでは、Ｏｆｆｉｃｅ３０４のＩＤは、ＩＰアド
レスとそのＯｆｆｉｃｅへのアクセスプロトコルをセッ
トにした形式になる。例えば、ＲＭＩでアクセス可能な
１９２.１６８.０.１のＩＰアドレスを持つＯｆｆｉｃ
ｅのＩＤとは、ｒｍｉ：／／１９２.１６８.０.１／であり、ＨＴＴＰでアクセスする場合は、ｈｔｔｐ：／／１９２.１６８.０.１／となる。

【００２６】ＯｆｆｉｃｅＭａｎａｇｅｒ３０３の別の
派生としてＤｅｓｋ３０５がある。Ｄｅｓｋ３０５はＯ
ｆｆｉｃｅＥｌｅｍｅｎｔを分類するために設けられ
る。例えば、旅行用のＯｆｆｉｃｅ（ＴｒａｖｅｌＯｆ
ｆｉｃｅ）を例として説明すれば、内部に航空券予約用
のＦｒｉｇｈｔＤｅｓｋ、宿泊予約用のＨｏｔｅｌＤｅ
ｓｋなどが配置され、サービスを分類する。Ｄｅｓｋ３
０５はＯｆｆｉｃｅ中で一意の名前を持っており、前述
のＯｆｆｉｃｅＩＤと組み合わせて下記のように表され
る。ｒｍｉ：／／１９２.１６８.０.１／Ｄｅｓｋ１／Ｄｅ
ｓｋ２この内容は、ｒｍｉでアクセス可能なＩＰアドレス１９
２.１６８.０.１のＯｆｆｉｃｅのオフィス中に存在す
るＤｅｓｋ１というデスクの中に存在するＤｅｓｋ２を
意味している。

【００２７】また、ＯｆｆｉｃｅＥｌｅｍｅｎｔ３０１
の派生としてＡｇｅｎｔ３０２を定義する。このＡｇｅ
ｎｔ３０２がエージェントプログラム２０２の実態であ
る。Ａｇｅｎｔ３０２はＤｅｓｋ３０５に配置され、そ
こを来訪した外のＡｇｅｎｔと交渉することでサービス
を提供する。Ａｇｅｎｔ３０２もＯｆｆｉｃｅ中で一意
の名前を特つ。従って、Ｏｆｆｉｃｅ中のＡｇｅｎｔ
は、前述のＯｆｆｉｃｅのＩＤ及びＤｅｓｋの名前と組
み合わされて下記のように特定される。ｒｍｉ：／／１９２.１６８.０.１／Ｄｅｓｋ１／Ｄｅ
ｓｋ２／ＡｇｅｎｔＮａｍｅ。

【００２８】この内容は、ＲＭＩでアクセス可能な１９
２.１６８.０.１のＩＰアドレスを持つところの、Ｄｅ
ｓｋ１の中のＤｅｓｋ２の中にあるＡｇｅｎｔＮａｍｅ
という名前のＡｇｅｎｔを特定するＩＤであることを意
味している。なお、この部分が前記図１のＩＤ特定手段
０１０に相当する。

【００２９】以上の要素はそれぞれの車両のコンピュー
タにあらかじめ搭載されており、実際にエージェントプ
レース間でやり取りされるのは、Ａｇｅｎｔ３０２から
派生した独自定義の部分だけである。例えば、Ｆｌｉｇ
ｈｔの情報をサービスするＦｌｉｇｈｔＡｇｅｎｔを独
自定義したとして、実際に転送されるのは、Ｆｌｉｇｈ
ｔＡｇｅｎｔとＡｇｅｎｔの差分だけであって、Ａｇｅ
ｎｔ３０２の部分はあらかじめ先方のエージェントプレ
ースに存在しているものとする。このようにすることで
実際の転送の際の通信量は小さくなる。

【００３０】また、図２において、車両に搭載されたコ
ンピュータ（図１の００５に相当）は、ワイヤレスの通
信手段２０６によってネットワークに接続されている。
このネットワークとはインターネットや独自の情報サー
バを指す。

【００３１】また、ユーザ（例えば車両の運転者）は、
車両側のコンピュータに接続された操作手段２０１によ
ってエージェントプログラム２０２を生成し、通信手段
２０６によって例えば交通情報サーバ（図１の０１５に
相当）にエージェントプログラム２０２を転送すること
ができる。例えば、交通情報収集の場合は、自分がこれ
から走行を予定している経路の交通情報が収集したいの
で、いま既に予定される経路を走っている車両に直接エ
ージェントプログラム２０２が移動し、自分になり代わ
って交通情報を収集し連絡するようにしたい。この場合
は車両の運転者は、自分の車両のコンピュータ上に交通
情報エージェント（交通情報用のエージェントプログラ
ム：以下、エージェントプログラムを省略してエージェ
ントと記す）を生成させる。

【００３２】上記の交通情報エージェントは以下の３つ
の状態をもつことができる。（１）ＣＯＮＣＩＥＲＧＥ（２）ＡＧＥＮＴ（３）ＲＥＴＩＲＥＭＥＮＴＣＯＮＣＩＥＲＧＥとは、自分の車両のコンピュータ上
に生成された状態で、まだどこにも移動していない状態
をいう。ＡＧＥＮＴとは、相手の車両上のコンピュータ
に乗り移った状態をいう。ＲＥＴＩＲＥＭＥＮＴとは、
相手の車両上のコンピュータから最初に生成された場所
に戻ってきた状態、つまり現在属しているコンピュータ
における状態をいう。

【００３３】これらの状態の判定は、以下のような３つ
の情報のうちのどれをエージェントが保持しているかを
判断することによって行う。（１）ＨｏｍｅＤｅｓｋ（２）ＰｒｅｖｉｏｕｓＤｅｓｋ（３）ＣｕｒｒｅｎｔＤｅｓｋＨｏｍｅＤｅｓｋとは、最初に誕生したＤｅｓｋのＩＤ
であり、このエージェントが消滅するまで変わらない。
例えば、ｒｍｉ：／／１９２.１６８.０.１／Ｄｅｓｋ１／Ｄｅ
ｓｋ２／などがそれに相当する。ＰｒｅｖｉｏｕｓＤｅｓｋと
は、一つ前に属していたＤｅｓｋのＩＤである。Ｃｕｒ
ｒｅｎｔＤｅｓｋとは、現在属しているＤｅｓｋのＩＤ
である。現在のＤｅｓｋがＣｕｒｒｅｎｔＤｅｓｋにセ
ットされる前に、ＣｕｒｒｅｎｔＤｅｓｋがＰｒｅｖｉ
ｏｕｓＤｅｓｋにコピーされる。

【００３４】上記（１）〜（３）の何れの状態であるか
の判断は以下のようにして行う。（１）ＰｒｅｖｉｏｕｓＤｅｓｋ＝ＮＵＬＬ＆＆Ｃ
ｕｒｒｅｎｔＤｅｓｋ＝ＨｏｍｅＤｅｓｋの場合に
は、ＣＯＮＣＩＥＲＧＥと判断する。（２）ＰｒｅｉｖｏｕｓＤｅｓｋ！＝ＣｕｒｒｅｎｔＤ
ｅｓｋ＆＆ＣｕｒｒｅｎｔＤｅｓｋ＝ＨｏｍｅＤｅ
ｓｋの場合は、ＡＧＥＮＴと判断する。（３）ＰｒｅｖｉｏｕｓＤｅｓｋ！＝ＣｕｒｒｅｎｔＤ
ｅｓｋ＆＆ＣｕｒｒｅｎｔＤｅｓｋ＝ＨｏｍｅＤｅ
ｓｋの場合は、Ｒｅｔｉｒｅｍｅｎｔと判断する。

【００３５】エージェントは以上の３つの状態を自身で
判断することによって、Ｄｅｓｋに到着したときにどの
ような処理を行えば良いかを決定する。例えば前記の交
通情報エージェントでは、ＣＯＮＣＩＥＲＧＥ状態のと
きに、自車両に搭載されているコンピュータリソースと
接続して、現在位置、目的地、経由予定道路、時刻など
の自車両の情報を取得して交通情報サーバ（例えば地上
局）に移動する。交通情報サーバに移動すると状態はＡ
ＧＥＮＴになる。ＡＧＥＮＴ状態では、そのときにＤｅ
ｓｋに対して働きかける。Ｄｅｓｋの反応によって動作
が異なる。

【００３６】交通情報サーバにおいては、上記の交通情
報エージェントは自車両位置座標を元にＤｅｓｋが持つ
２次元仮想空間に配置される。次に、その空間から目的
地及び経由予定道路の情報を元に、考えられる経路を計
算する。次に、経路上に配置されている他の交通情報エ
ージェントを検索する。すなわち、それが直接に交通情
報を教えて貰いたい交通情報の配信エージェントの位置
に相当する。この部分が前記図１の検索手段０１３に相
当する。

【００３７】次に、その配信エージェントに直接移動す
るには、配信エージェントのＨｏｍｅＤｅｓｋを参照す
ればよい。交通情報サーバのＤｅｓｋ上の仮想地図空間
でそのような配信エージェントが複数見つかった場合、
自分の分身を見つかった数だけ生成し、配信エージェン
トの示すＨｏｍｅＤｅｓｋの場所に移動する。エージェ
ントの転送はエージェントプレース２０３によって行わ
れる。この部分が前記図１の移動手段００８に相当す
る。

【００３８】エージェントプレース２０３は、通信回線
を開き、その上でＴＣＰ／ＩＰのセッションを開始す
る。ＴＣＰ／ＩＰの上で行われるリモートサーバとの通
信手段にはさまざまな手段を利用可能である。例えば、
ＪａｖａのＲＭＩを用いて、遠隔サーバのメソッド呼び
出しの引数の形でエージェントを転送できる。これはＪ
ａｖａを用いた最もスマートな方法である。しかし、通
常ＲＭＩはファイヤーウォールを越えられないので、イ
ンターネット経由でエージェントを転送するには他の方
法に依らなければならない。例えば、遠隔サーバがＪａ
ｖａのＳｅｒｖｌｅｔで構成されている場合は、ＨＴＴ
Ｐによってエージェントを転送できる。それ以外に独自
のソケットサーバを構築してエージェントを転送するこ
ともできる。いずれの形態にしろ、エージェントは直列
化されてネットワークに書き出され、反対側で読み出さ
れて直列化から復元される。

【００３９】このような動作を抽象化するために、Ｅｘ
ｐｏｒｔａｂｌｅといったインタフェースを実装する。
Ｅｘｐｏｒｔａｂｌｅにはエージェントの転送を行うた
めにメソッドＶｉｓｉｔを用意し、このインタフエース
を持ったさまざまな実装がＶｉｓｉｔメソッドによって
エージェントを転送可能にする。こうすることでエージ
ェントの送り出し側は、Ｅｘｐｏｒｔａｂｌｅインタフ
ェースを持ったオブジェクトに対して、それがどのよう
な通信プロトコルによってエージェントを転送するかを
意識することなく、Ｖｉｓｉｔメソッドをインボークす
ることによってエージェントの転送が行える。先の例で
は、Ｅｘｐｏｒｔａｂｌｅインタフェースの実装とし
て、ＪａｖａのＲＭＩサーバや、同じくＪａｖａのＳｅ
ｒｖ１ｅｔとの通信、あるいは独自プロトコルによるソ
ケットサーバとの通信が考えられる。

【００４０】次に、図４は交通情報サーバ（図１の０１
５に相当）の一例の構成を示す図である。交通情報サー
バは、個々の交通情報を保持しておらず、交通情報エー
ジェントの登録場所を提供するものである。以下、交通
情報サーバをＪａｖａのＳｅｒｖｌｅｔによって構築す
る場合を説明する。交通情報サーバとして、ＤＯＳ／Ｖ
などのコンピュータを用意してネットワークに接続す
る。コンピュータ４０８上にはサーバ管理に適した、Ｌ
ｉｎｕｘ、Ｕｎｉｘ、Ｗｉｎｄｏｗ２０００などのオペ
レーティングシステム４０７を搭載する。オペレーティ
ングシステム４０７の上にはアプリケーションとして、
外部からのＨＴＴＰリクェストに答えるためにＡｐａｃ
ｈｅなどのＷｅｂサーバ４０６を搭載する。

【００４１】ＡｐａｃｈｅなどのＷｅｂサーバ４０６
は、Ｓｅｒｖｌｅｔエンジン４０５が動作可能なように
あらかじめＡｐａｃｈｅＪＳｅｒｖなどのＳｅｒｖｌｅ
ｔエンジンを組み込んでコンパイルし、Ｓｅｒｖｌｅｔ
対応型Ｗｅｂサーバを構築しておく。その上に、エージ
ェントプレース４０４をＳｅｒｖｌｅｔとして記述し、
Ｓｅｒｖｌｅｔエンジン４０５上で走らせる。

【００４２】また、交通情報サーバでは、転送されてき
たエージェントを格納するためのリレーショナルデータ
ベース（ＲＤＢＭＳ）４０２を搭載する。先のオペレー
ティングシステム４０７上に、ＯｒａｃｌｅはやＳｙｂ
ａｓｅまたはＰｏｓｔｇｒｅＳＱＬなどのＲＤＢＭＳ４
０２を起動させる。これらとＳｅｒｖｌｅｔの間のトラ
ンザクションが可能なように、それぞれのリレーショナ
ルデータベース４０２に対応したＪＤＢＣ４０９もイン
ストールしておく。リレーショナルデータベース４０２
には、各エージェントの経度緯度を含んだ位置情報が保
持されるため、別の見方をすれば、このリレーショナル
データベース４０２はエージェントが配置された仮想空
間となる。

【００４３】次に、交通情報サーバ上のＳｅｒｖｌｅｔ
にエージェントが転送されたときのエージェントプレー
ス４０４の動作を説明する。まず、クライアント（情報
を収集したい者）側からの呼び出しによってエージェン
ト受取側のＳｅｒｖｌｅｔのスレッドが生成されスター
トする。このスレッドは、すぐに入力ストリームを開い
て入力ストリームから直列化されたエージェント４０３
を取りだし、復元する。エージェント４０３は転送の
際、目的アドレスにはＤｅｓｋが指定されている。例え
ば、ｒｍｉ：／／１９２.１６８.０.１／Ｄｅｓｋ１／Ｄｅ
ｓｋ２／の場合は、Ｄｅｓｋ１／Ｄｅｓｋ２がこのＯｆｆｉｃｅ
上でのＤｅｓｋのＩＤである。エージェントプレース４
０４は目的アドレスからＤｅｓｋのＩＤを抜き出し、復
元されたエージェントを目的のＤｅｓｋに配置する。

【００４４】次に、次の行き先を検索するためＲＤＢＭ
Ｓ４０２にクエリを発する。例えば交通情報を知りたい
場合は、自身の目的地、経由道路と同じ情報を持ってい
るエージェントか、交通情報が知りたい場所の近く、あ
るいは特定のエリア内にいるエージェントのＩＰアドレ
スをクエリする。その結果、複数のＩＰアドレスがえら
れたとすれば、エージェントの自身の分身をその数だけ
作り、それぞれのＩＰアドレスに前述の転送方法と同じ
手段によって転送する。

【００４５】次に、情報配信側の構成について説明す
る。情報配信側の構成は、基本的には図２の収集側の構
成と同じである。情報配信側はあらかじめ自身の位置や
目的地、経由道路などを持ったエージェントを前述の交
通情報サーバに転送しておき、収集者のエージェントを
自身のエージェントプレースに導くようにする。すなわ
ち、自身のエージエントの交通情報サーバヘの転送が情
報配信車両としてのスタートを意味する。

【００４６】次に、配信側のエージェントプレース２０
３に収集者のエージェントが到着したときの動作を説明
する。この場合のエージェントプレース２０３はＲＭＩ
サーバとして構築されているとする。配信者のエージェ
ントプレース２０３は、ＲＭＩサーバであるＲｍｉｒｅ
ｇｉｓｔｒｙを起動し、自身の名前を登録しておく。収
集者はＲＭＩサーバに登録されたオブジェクトのＶｉｓ
ｉｔメソッドをインボークし、その引数にエージェント
プログラムのオブジェクトを詰めて送ってくる。配信者
側では、そのまま引数のエージェントブログラムオブジ
ェクトを受け取り、自身のエージェントプレース２０３
に登録する。

【００４７】次に、配信者側のエージェントプレース２
０３に到着した収集者エージェント（情報収集者が送信
したエージェントプログラム）の動作について説明す
る。収集者エージェントは、現在の位置や進行方向を確
認し、希望の位置や方向と合っているかを確かめる。合
っていると判断した場合は、そのまま滞在し以後情報の
配信を行う。もし合っていないと判断した場合や、途中
で進行方向がずれたり、長期滞在して交通情報が交信さ
れない場合は、自動的に交通情報サーバに帰る。滞在中
は、収集者のエージェントプレースかエージェントプレ
ースにいる他のエージェントに対して直接メッセージを
送信することで情報の配信を行う。

【００４８】収集者エージェントは、それに組み込まれ
たプログラムによって独自に動作を行う。例えば、最も
基本的な動作として、現在の平均時速を収集者に伝える
必要があるが、それは内蔵されたタイマーによって定期
的に報告する方法もあれば、ある程度平均時速に変化が
あったときに、はじめて報告するようなプログラムにす
ることもできる。そうすることで、渋滞の終わりや始ま
りだけを検知することができる。

【００４９】また、平均時速は定期的に収集して記憶し
ていくため、途中で回線が途絶えていたとしても、その
間の情報を保持しておき、回線が復活したときに改めて
送信できる。このため、収集者側からすれば回線状態に
左右されずに安定した情報の収集が可能となる。

【００５０】また、収集者エージェントは配信者のエー
ジェントプレースで、速度計測などの配信者側のシステ
ムリソースにアクセスして情報を入手する以外に、その
エージェントプレースに来訪しているほかの収集者のエ
ージェントとも相互作用を行うことができる。例えば、
他の収集者エージェントが自分の目的地から来ているも
のであるとすれば、交通情報サーバを介さずに直接この
収集者エージェントから情報を受理するか、次のエージ
ェント移動先として登録することができる。

【００５１】エージェントが持っている情報は、エージ
ェントの個性と呼ぶものである。個性の情報としては、
これまで走ってきた経路の天気情報や、平均速度、エー
ジェントのオーナーである運転者の車両の趣向などが含
まれる。平均速度の情報を受け取れば現在モニターして
いない範囲の交通情報の概要をつかむことができるた
め、経路選択のヒントとして役立つ。例えば、運転者同
士の車両の趣向が同じであることが判れば交通情報エー
ジェントがチャットエージェントを呼び寄せて、特定の
車両の話題に入ることもできる。つまり、各エージェン
トはそれぞれが保持する情報に基づいて、各エージェン
ト間で互いに交渉することができる。この部分が前記図
１の交渉手段０１４に相当する。これらのエージェント
の個性を表す記述は標準化しておく必要があり、ＸＭＬ
などのポキャブラリで表す。

【００５２】なお、本実施例では、便宜上、情報の収集
側と配信側を分けて説明したが実際は両者は重なってい
る。つまり、ある車両は情報の収集者であると同時に情
報の提供者となる。

【００５３】図５は、従来の分散交通情報収集システム
と本実施例の構成との比較を示す図であり、図５（ａ）
は従来装置、図５（ｂ）本実施例の構成を示す。図５
（ａ）に示すように、従来のプローブカーを用いた分散
交通情報収集システムにおいては、各プローブカー１０
３からの全ての交通情報を交通情報サーバ１０２内のデ
ータベース１０１に記憶し、各プローブカー１０３が情
報を必要とする場合には、データベース１０１に記憶し
た全データから必要な情報を検索するように構成されて
いた。したがって、情報量が増えることから交通情報サ
ーバ１０２の負荷が大きくなる。また、プローブカー１
０３は情報を交通情報サーバ１０２に転送するために特
定の頻度で交通情報サーバ１０２と通信しなければなら
ず、全体としての通信トラフィックが増大する。また、
情報を得る場合にはデータベース１０１に記憶した膨大
な量のデータから必要な情報を検索することが必要なの
で煩雑であった。つまり、従来のプローブカーを用いた
分散移動情報収集システムにおいては、収集装置の末端
は分散化されているが、その情報の集約先がサーバコン
ピュータなどの集中システムとなるため、ボトルネック
となって分散システムとしてのメリットを出しきれてい
ない。これは、情報の収集者から見た場合、収集者にと
っては不必要な情報が大量に交通情報サーバに保存され
ており、その中から必要な情報のみを抜き出して利用し
なければならないない、という基本的な構成に問題があ
り、情報の配信者からすれば、必要とされているかどう
か判らない情報を常に交信しつづける必要があり、無駄
な通信が増加していた。

【００５４】これに対して、本実施例においては、交通
情報サーバ１１０は仮想空間１１１を介してエージェン
トプログラム１１２の仲介を行うだけであり、実際の情
報の配信と収集は各車両（プローブカー１１３）間で直
接に行われる。したがって情報収集者は必要な情報を、
その情報を持っている者から直接に受け取るという、分
散情報収集−分散情報配信の構成になっている。そのた
め交通情報サーバ１１０において膨大な量のデータを記
憶する必要が無い。また、各プローブカーと交通情報サ
ーバ１１０間で定期的に通信を行う必要がないので全体
としての通信トラフィックが減少する。また、情報収集
者は必要な情報を、その情報を持っている者から直接に
受け取るので、膨大な量のデータから必要な情報を検索
する手間が無くなる。

【００５５】（第２の実施例）次に、第２の実施例とし
て、車両間でチャットを行いながら双方の位置をモニタ
ーしながら目的地に到着するためのチャットエージェン
ト（チャット用のエージェントプログラム）について説
明する。この実施例のチャットエージェントでは、エー
ジェントプレースやエージェントサーバの構成は第１の
実施例の構成と同じである。チャットエージェントは、
チャット相手のエージェントプレースに直接乗り移り、
相手にチャットのためのインタフェースを提供するエー
ジェントプログラムである。

【００５６】例えば、Ａ車両とＢ車両がそれぞれの走行
しているものとする。Ａ車両は自車両のエージェントプ
レースでチャットエージェントを生成し、その複製を一
つ作ってチャットサーバ（詳細後述）に転送する。この
場合のチャットエージェントは、話したい内容の種類や
目的地などを保持している。転送されたチャットエージ
ェントはＡＧＥＮＴ状態になり、チャットサーバ上のほ
かのエージェントに対して話しかける。

【００５７】例えば、仮想空間上ですでに目的地にいる
他のエージェントや、同じ目的地に向かっている他のエ
ージェントに対して話しかける。話しかけた結果それら
のエージェントがチャット受け入れが可能であれば、こ
のエージェントはチャットエージェントを直接そのエー
ジェントが属していたＨｏｍｅＤｅｓｋのエージェント
プレースに転送する。受け入れ可能なエージェントが複
数ある場合は、それらの数だけクローンをつくって転送
する。

【００５８】車両上のエージェントプレースに転送され
たエージェントは、チャットサーバの場合と同じくＡＧ
ＥＮＴ状態であり、エージェントプレースに対して話し
かける。この場合の話しかけるとは、チャットためのイ
ンタフェースを表示してよいか否かについてのダイアロ
グを表示することである。運転者が最終的にチャット可
能と判断してダイアログのＯＫボタンを押せばチャット
インタフェースが開き、自身のＨｏｍｅＤｅｓｋのチャ
ットエージェントとの間でチャットが可能になる。この
ようにチャットエージェントをチャットサーバを介して
同じ目的地あるいは同じ趣向を持った車両に転送するこ
とにより、車両の運行に役立つチャットを行うことがで
きる。

【００５９】また、ここでいうチャットサーバは、従来
のクライアントサーバ型のチャットサーバではなく、チ
ャットエージェントのエントリーと転送のみを受け持っ
ており、実際のチャットサーバの機能は、チャットエー
ジェントを発信した側になる。これにより、チャット話
題によって複数のコンピュータを一次的なチャットサー
バに仕立てることができる。たとえば、ある話題でＡ車
両とＢ車両が意気投合した場合に、Ｂ車両の判断でその
話題にＣ車両も加えたと思ったならば、そのチャットエ
ージェントの発信者であるＡ車両の意思とは無関係にチ
ャットエージェントのクローンをＣ車両に転送すれば、
Ｃ車両もこのチャット空間に参加することができる。ま
た、この場合のチャットエージェントはお互いの位置を
カーナビゲーションなどの位置計測装置から取得し、チ
ャットメッセージに付加して送る。

【００６０】また、チャットエージェントが属している
エージェントプレースにカーナビゲーションに相当する
ような地図表示装置が存在する場合は、その地図表示装
置上に、チャット相手の位置をマークすることができ
る。また、チャットエージェントが特定の相手とだけ話
すようにしておけば、これから目的地で会う相手の位置
情報を確認しつつチャットをしながら運転することがで
きる。上記のように本実施例では、集中的なチャットサ
ーバを作ることなく、チャットエージェントによって車
両の運行状況に沿ったチャットが可能な例について説明
した。

【００６１】次に、これまで説明した交通情報収集シス
テムの具体例として、ＪａｖａおよびＴＣＰ／ＩＰをベ
ースとしたネットワークで実現した場合を説明する。こ
の説明においては、エージェントの動作フローをホー
ム、交通情報サーバ、訪問先にわけて説明する。（１）ホーム図６は「ホーム」の動作フローの一例図である。ホーム
とは、エージェントが最初に生成される場所である。エ
ージェントは生成後以下に示した各ステップのように動
作する。ステップ１０１０：（生成）エージェントをＮｅｗする。Ｎｅｗするとは、ホームの
計算機リソース上のメモリにエージェントの実態（オブ
ジェクト）を確保することである。これによりエージェ
ントの実態が生成される。ステップ１０２０：（配置）エージェントを配置する。エージェントの配置は、エー
ジェントが生成されたオフィスヘの登録を意味する。登
録とは、オフィスからエージェントを、あるいはエージ
ェントからオフィスを参照できるように相互にポインタ
を張ることである。ホームヘの配置によって、エージェ
ントはＣＯＮＣＩＥＲＧＥモードになる。ステップ１０３０：（起動）エージェントの起動は、エージェント固有のスレッドの
起動を意味する。エージェントはメインとは別のスレッ
ドを独自に持ち、そのスレッドの中で自身の全ての動作
を行う。メインのスレッドには影響を与えない。ステップ１０４０：（入力）エージェントに対して指示がある場合は、ここで入力フ
ェーズに入る。入力フェーズでは適宜必要なダイアログ
ボックスなどが表示される。基本的に交通情報を入手し
たい場合は、自動的に予定コースに従って情報検索を行
うので入力フェーズはスキップされる。ステップ１０５０：（検索）情報収集先の交通情報サーバを検索する。検索にはＩＰ
アドレスとＲＭＩサーバに登録されたネームルックアッ
プ機能を用いる。すなわち、どのマシンのどのオフィス
に接続したいかを指示することによって移動先の交通情
報サーバを検索できる。検索の結果、移動先オフィスヘ
のハンドラが返る。ハンドラとは、移動先オフィスヘの
一種のポインタであり、ホームではこのハンドラにアク
セスすることによってリモートな移動先オフィスにアク
セスしているのと同じ効果が得られる。ステップ１０６０：（出発）ステップ１０５０で得られたオフィスにエージェントを
ｖｉｓｉｔさせる。ｖｉｓｉｔでは、まずエージェント
を転送用オブジェクトＴｒａｎｓｐｏｒｔｅｒの中に詰
め込む。次に、先方のオフィスに対してｖｉｓｉｔの引
数としてこのＴｒａｎｓｐｏｒｔｅｒオブジェクトを渡
す。Ｊａｖａは、転送先オフィスヘのストリームを開
き、Ｔｒａｎｓｐｏｒｔｅｒオブジェクトを直接化して
ストリームに入力する。このとき、エージェントのクラ
スの定義を送る必要がある。なぜならば、移動先のオフ
ィスは送られてくるエージェントの型を知らないからで
ある。これは、ＪａｖａのＯｂｊｅｃｔＯｕｔｐｕｔＳ
ｔｒｅａｍに用意されているＡｎｎｏｔａｔｅＣ１ａｓ
ｓメソッドを用いることで対処する。Ａｎｎｏｔａｔｅ
Ｃ１ａｓｓメソッドは、オブジェクトがストリームに書
き出きれるときに自動的に呼び出されるため、ここでＣ
１ａｓｓファイルをストリームに書き出してクラス定義
を移動先に転送する。

【００６２】（２）交通情報サーバ図７は、「交通情報サーバ」の動作フローの一例図であ
る。交通情報サーバは、車両から送られてくるエージェ
ントの移動先である。交通情報サーバは、ＪａｖａＲＭ
Ｉのネームルックアップ機能を用いて、自身のオフィス
の名前をＲＭＩサーバに登録している。エージェントの
送り先は、ステップ１０５０の方法によってこのサーバ
を検索し、エージェントを転送してくる。交通情報サー
バでのエージェントは以下に示す各ステップのように動
作する。ステップ２０１０：（到着）交通情報サーバは、Ｊａｖａの機能としてストリームか
らエージェントを取り出し、エージェントオブジェクト
の実態を復元する。このとき、エージェントのクラスも
転送されてくる。エージェントのクラスを読み込んだ場
合は、ｒｅｓｏｌｖｅＣ１ａｓｓメソッドを呼んでクラ
スローダにクラスの読み込みを指示し、新たなクラスを
ＪａｖａＶｉｒｔｕａｌマシンに登録する。エージェン
トの訪問によってエージェントのモードはＡＧＥＮＴに
変わる。ステップ２０１５：（起動）復元したエージェントは再び独自のスレッドを開始す
る。ステップ２０２６：（クエリ）ステップ２０１５のスレッドでエージェントの移動先と
なる他の車のエージェントを検索する。このために、他
の車のエージェントが登録されているデータベースに対
してＳＱＬによりクエリを発行する。ＳＱＬの条件は、
自身がこれから通過する経路のＩＤである。その結果、
これから通過する予定の経路にいる他のエージェントの
ハンドラで一つ以上取得される。ステップ２０３０：（クローン）移動先のハンドラが複数取得された場合は、エージェン
トはその数だけ白身の分身（クローン）を作成する。ク
ローンは、ＪａｖａのＣｌｏｎａｂｌｅインタフェース
を実装することにより実現する。すなわち、エージェン
トのＣｌｏｎｅメソッドを呼ぶことにより複製を行う。ステップ２０４０：（滞留）もし、ハンドラが一つも見つからなかった場合は、交通
情報サーバのデータベー列に自身を登録し、対応する経
路を通過するほかのエージェントの登録があるまで交通
情報サーバ上に滞留する。ステップ２０５０：（訪問）他の車に移動する。移動は、ステップ１０６０と同じ方
法による。

【００６３】（３）訪問先図８は「訪問先」の動作フローの一例図である。訪問先
とは、他の車の上に構築された一種のエージェントオフ
ィスである。このエージェントオフィスに他の車からき
たエージェントが配置されることによって、エージェン
トはこのオフィス（つまり移動中の車から）交通情報を
入手できる。ここでは、訪問先でのエージェントの動作
フローを説明する。ステップ３０１０：（訪問）訪問はステップ２０１０と同じ方法による。ステップ３０２０：（起動）ステップ２０２０と同じく独自スレッドを生成すること
により起動する。ステップ３０３０：（交渉）起動後、オフィスにいる他のエージェントに対して到着
を通知する。この通知には、交通情報の収集目的が含ま
れる。この通知に反応した、このオフィスに所属するほ
かのＣＯＮＣＩＥＲＧＥモードのエージェントから交通
情報が逆に通知される。ステップ３０３５：（通知）ステップ３０３０で得られた交通情報をホームに転送す
る。転送にはエージェント間メッセージ通信を用いる。
すなわち、ＲＭＩサーバに登録されているホームのハン
ドラを取得し、そのハンドラに対して、上記交通情報が
含まれたメッセージパケットを直接送信する。ステップ３０４０：（死滅）移動先の車の経路が想定経路からずれた場合、あるいは
エージェントの寿命（最初に設定された生存時間）がお
とずれた場合は、自身のスレッドを停止し、メモリを開
放する。メモリの実質的な開放はＪａｖａのガベージコ
レクションにより行われる。ステップ３０５０：（帰着）最初の指示によってはステップ３０４０のように死滅せ
ずに、ホームに戻るケースもある。移動先の車の経路が
想定経路からずれた場合、あるいはエージェントの寿命
（最初に設定された生存時間）がおとずれた場合は、ス
テップ２０１０と同じ方法でホームに帰着し、その後、
ＲＥＴＩＲＥＭＥＮＴモードになる。ＲＥＴＩＲＥＭＥ
ＮＴモードになったエージェントは、スレッドを停止
し、ホームのＪａｖａのガベージコレクターによりメモ
リを開放する。

【００６４】以下、これまで説明した本発明の特徴を纏
めて記載する。１．本発明は、情報の収集だけでなく、その後の配信も
分散的に行うシステムである。２．各車両（各々がプローブカーに相当）は交通情報そ
のものでなく、自身の状態（場所や予定経路など）を保
持したエージェント（エージェントプログラム）を仮想
空間上に配置する。３．このシステムを利用するユーザも自身のエージェン
トを仮想空間に配置する。４．ユーザのエージェントは自身の経路の前方を同じ予
定経路で進んでいるエージェントと交渉する。この場
合、相手のエージェントは複数でもよい。５．以後は、相手エージェントの車両と直接更新して情
報を収集する。６．直接交渉することによって交通情報サーバと車両と
の通信量は減少するが、車両間の交信は増加する。これ
に対しては以下の手段によって解決する。７．ユーザのエージェントは１または複数の車両上のＣ
ＰＵに直接乗り移る。８．そして、ユーザのエージェントは、複数の車両の上
で直接情報収集を行い、そのサマリまたは突発情報をイ
ベント的にユーザに伝送する。

【００６５】上記の構成により次のような作用、効果が
ある。本発明においては、サーバの負荷の軽減、通信ト
ラフィックの減少という効果だけではなく、エージェン
トが自律的に行動するプログラムなので以下のような効
果がある。１．ユーザのエージェントは乗り移った先の車両の経路
が外れた場合などは自律的に仮想空間に戻り、新たな乗
り移り先を探すので、ユーザはエージェント配置を考え
る必要がない。したがって利用が簡単で、検索の手間が
省ける。２．あるプローブカーに乗り移っているエージェント同
士で情報を交換し、次の乗り移り先や、乗り移っていな
い車両からの情報も入手することができる。３．エージェントは車両の上で動いているため、ユーザ
側が何かの都合でオフラインになったとしても、サマリ
作成などの処理が滞ることがなく、オフライン期間中の
情報が欠落したような事態に陥らない。そして次のオン
ラインのタイミングで通常通りの結果を受け取ることが
できる。

【００６６】なお、これまでの説明においては、車両に
よる交通情報の収集と配信を例として説明したが、移動
情報収集手段と移動情報サーバとの通信手段を歩行者に
取り付ければ、歩行者の動きを把握するシステムを構成
することも可能である。つまり、車両に限らず一般の移
動体における情報を分散的に収集して分散的に配信する
ことが出来る。

【図面の簡単な説明】

【図１】第１の実施例の全体構成を示すブロック図。

【図２】車両１側における車載コンピュータ００５の内
容を示すブロック図。

【図３】エージェントプレース２０３の構成例を示す
図。

【図４】交通情報サーバの一例の構成を示す図。

【図５】従来の分散交通情報収集システムと本実施例の
構成との比較を示す図であり、（ａ）は従来装置、
（ｂ）本実施例の構成を示す。

【図６】「ホーム」の動作フローの一例図。

【図７】「交通情報サーバ」の動作フローの一例図。

【図８】「訪問先」の動作フローの一例図。

【符号の説明】

１…車両２…地上局３…通信手
段００１…センサ群００２…位
置計測装置００３…地図データベース００４…エージェントプログラム配置手段００５…車
載コンピュータ００６…エージェント固有プログラム００７…情
報メモリ００８…移動手段００９…エ
ージェントプログラム０１０…ＩＤ特定手段０１１…分
類手段０１２…転送手段０１３…検
索手段０１４…交渉手段０１５…サ
ーバコンピュータ２０１…操作盤２０２…エ
ージェントプログラム２０３…エージェントプレース２０４…Ｊ
ａｖａＶＭ２０５…オペレーティングシステム２０６…通
信手段３０１…ＯｆｆｉｃｅＥｌｅｍｅｎｔ３０２…Ａ
ｇｅｎｔ３０３…ＯｆｆｉｃｅＭａｎａｇｅｒ３０４…Ｏ
ｆｆｉｃｅ３０５…Ｄｅｓｋ４０１…エージェント仮想空間データベース４０２…リレーショナルデータベース（ＲＤＢＭＳ）４０３…エージェント４０４…エ
ージェントプレース４０５…Ｓｅｒｖｌｅｔエンジン４０６…Ｗ
ｅｂサーバ４０７…オペレーティングシステム４０８…コ
ンピュータ４０９…ＪＤＢＣ

Claims

【特許請求の範囲】

【請求項１】移動体に搭載され、移動体における情報を
分散的に収集して分散的に配信するシステムであって、必要とする情報収集を指示する手段と、指示された情報収集を実施するための自律的プログラム
であるエージェントプログラムを記憶する記憶手段と、前記エージェントプログラムの送受信を行う通信手段
と、記憶しているエージェントプログラムの送信を行い、受
信したエージェントプログラムに従った所定の制御を行
う制御手段と、受信したエージェントプログラムに従って実施した所定
の制御結果の情報を送信する手段と、を備えた分散情報収集システム。
【請求項２】サーバとなるコンピュータと通信手段から
構成され、移動体における情報を分散的に収集して分散
的に配信するシステムであって、指示された情報収集を実施するための自律的プログラム
であるエージェントプログラムを複数の移動体との間で
送受信する通信手段と、前記エージェントプログラム同士が情報の交換を行うた
めの、コンピュータ上に形成された仮想空間と、受信した各エージェントプログラムを前記仮想空間に配
置するよう制御する手段と、を備えた分散情報収集システム。
【請求項３】移動体側には、必要とする情報収集を指示する手段と、指示された情報収集を実施するための自律的プログラム
であるエージェントプログラムを記憶する記憶手段と、エージェントプログラムの送受信を行う通信手段と、記憶しているエージェントプログラムの送信を行い、受
信したエージェントプログラムに従った所定の制御を行
う制御手段と、受信したエージェントプログラムに従って実施した所定
の制御結果の情報を送信する手段と、を備え、サーバ側には、指示された情報収集を実施するための自律的プログラム
であるエージェントプログラムを複数の移動体との間で
送受信する通信手段と、前記エージェントプログラム同士が情報の交換を行うた
めの、コンピュータ上に形成された仮想空間と、受信した各エージェントプログラムを前記仮想空間に配
置するよう制御する手段と、を備え、自己の移動体にとって必要とする情報を収集するための
前記エージェントプログラムを用いて、情報収集が指示
されると、前記仮想空間上で検索された必要とする情報
を持っている移動体のコンピュータヘ前記自己のエージ
ェントプログラムが移動し、当該エージェントプログラ
ムが移動先のコンピュータ内で必要とする情報の収集を
行って自己の移動体へ収集した情報を送信することによ
り、情報を分散的に収集して分散的に配信することを特
徴とする分散情報収集システム。
【請求項４】移動体側には、少なくとも移動体の移動速
度を含む自己の移動体の状態を検出する状態検出手段
と、前記自己の移動体の位置を検出する位置検出手段と、を
備え、前記エージェントプログラムに従って実施した所定の制
御結果の情報には、前記自己の移動体の状態と位置との
情報を含むことを特徴とする請求項１または請求項３に
記載の分散情報収集システム。
【請求項５】前記情報収集を指示する手段は、当該移動
体の使用者の操作によって情報収集を指示するように構
成されたことを特徴とする請求項１または請求項３に記
載の分散情報収集システム。
【請求項６】前記情報収集を指示する手段は、前記移動
体の経路計算を行う際に自動的に情報収集を指示するよ
うに構成されたことを特徴とする請求項１または請求項
３に記載の分散情報収集システム。
【請求項７】それぞれの前記エージェントプログラムが
ネットワーク上で一意に特定可能なＩＤを保持できるエ
ージェントプログラムＩＤ特定手段を備えたことを特徴
とする請求項１乃至請求項３の何れかに記載の分散情報
収集システム。
【請求項８】自己の移動体のコンピュータにおける前記
エージェントプログラムが情報探索のために他の移動体
のコンピュータとの間で自律的に行き来できる移動手段
を備えたことを特徴とする請求項１乃至請求項３の何れ
かに記載の分散情報収集システム。
【請求項９】前記エージェントプログラムは、該エージ
ェントプログラムが最初に生成された移動体と、現在属
している移動体と、一つ前に属していた移動体と、にそ
れぞれ対応した３つの状態になり得るものである、こと
を特徴とする請求項１乃至請求項３の何れかに記載の分
散情報収集システム。
【請求項１０】デジタル地図情報を保持する地図データ
保持手段と、該地図データ保持手段のデジタル地図情報
を元にした２次元仮想空間上にエージェントブログラム
を配置可能なエージェント仮想空間を有することを特徴
とする請求項２または請求項３に記載の分散情報収集シ
ステム。
【請求項１１】前記２次元仮想空間に配置されたエージ
ェントプログラムが保持している情報に基づいて必要な
交渉相手を検索できる検索手段を備えたことを特徴とす
る請求項１０に記載の分散情報収集システム。
【請求項１２】前記２次元仮想空間から他の移動体上の
コンピュータにエージェントプログラムを移動させるた
めの移動手段を備えたことを特徴とする請求項１０また
は請求項１１に記載の分散情報収集システム。
【請求項１３】前記各移動体上のそれぞれのエージェン
トプログラムが保持する情報に基づいて、各エージェン
トプログラム間で互いに交渉できる交渉手段を備えたこ
とを特徴とする請求項１０乃至請求項１２の何れかに記
載の分散情報収集システム。
【請求項１４】任意の移動体上のエージェントプログラ
ムが、他の移動体のエージエントプログラムと交渉可能
な通信手段を備えたことを特徴とする請求項１０乃至請
求項１３の何れかに記載の分散情報収集システム。