ネットワークロボットの実現に向けて −ビジブルロボットとバーチャルロボットの連携技術の検討−

全文

(1)ネットワークロボットの実現に向けて - ビジブルロボットとバーチャルロボットの連携技術の検討長谷川哲夫*. 川村隆浩*. 上野晃嗣*. 大須賀昭彦*. 土井美和子*. 1. まえがき. これまでにないアプリケーションの実現が可能となる、. ロボットは一般に手・足・口・耳を持ち、これらを使って. といえる。ここでは、いわゆる手足のあるロボットをビジ. 現実世界に対して働きかけることができる。すなわち、. ブルロボット、センサー等をアンコンシャスロボット、イ. 身振りや音声を使ってわかりやすく自然な形で人間と. ンターネット上のサービスをバーチャルロボットと呼び、. 対話して要求を受け付けその結果を伝えられる。また、. これらのロボットがネットワークに向けて公開している機. 物を運ぶなど物理的な操作による人間の支援を行え. 能をサービスと呼ぶことにする。. る。そのため、ロボットは人間にやさしい HI としても、汎. 我々は、これらの異種のロボット群を透過的に連携. 用的なメカデバイスとしても期待が非常に高い。しかし、. する仕組みに注目する。本稿では、このような連携に. 例えば、段差を超えられず移動範囲に制限がある、視. おける課題を挙げるとともに、それらを解決するために. 覚認識できる範囲に制限があるなど、ロボット単体で. 特にビジブルロボットとバーチャルロボットの連携に注. 行えることには限界がある。. 目して設計中の要素技術を紹介する。. 一方、商店街にカメラが設置されるなど、場や空間には、人間の状態や、環境の状態を把握するための各. 2.異種ネットワークロボット連携の課題. 種センサーが散在して相互にネットワークで接続され. 異種ロボットの連携に関する課題を以下に挙げる。. つつある。また、インターネット上には、従来からさまざ. ・頻繁な変化: 特にビジブルロボットでは、ロボットの. まな情報提供サービスや計算処理サービスなどが提. 現在位置や負荷などの状態が頻繁に変わり、その状. 供されている。そこで、ロボットを、ネットワーク上のひと. 態によって処理を依頼するロボットを変える必要がある。. つの存在と捉え、ロボットがネットワーク上の機器やサ. そのため、特定のサービスを利用条件に応じて提供で. ービスを自由に活用できる環境を整えることで、単体. きるロボットを発見する仕組みが必要となる。. のロボットの限界を超え、ロボットの能力を大幅に増強. ・統一されていないインタフェース: 例えば、インターネ. できる可能性がある。たとえば、未知の知識や最新情. ット上のサービス分野では Web サービス、ネットワーク. 報(ニュースや天気、株価など)の取得、新たなソフトウ. 家電機器分野では UPnP や ECHONET など、分野毎. ェア機能の獲得、外部のセンサーによる外界情報の. にはいくつか代表的な標準規約が存在する。また、ア. 取得、困難な仕事の他ロボットへの委託、他の機器と. プリケーションドメイン毎にやり取りするデータフォーマ. の協調による複雑な仕事の解決など、ロボット単体の. ットの標準もある。しかし、異種ロボットの間では、プロト. 能力を越えたさまざまな処理が可能となる。逆の見方. コルもデータフォーマットも異なっているのが実情であ. をすると、ネットワークにつながれたさまざまな機器や. る。プロトコル変換やデータ変換が必要となることとは. サービス、そしてロボット群を透過的に連携することで、. 別に、サービスの発見においては、サービス名や引数に関して、その名称でなく意味で発見をする必要があ. *株式会社東芝、神奈川県 TOSHIBA Corporation, 1, Komukai-Toshiba-cho, Saiwai-ku, Kawasaki, 232-8582, JAPAN. る。.

(2) NWRアプリケーション. サービス検索. ロボットサービスマッチメーカー. アプリケーションアプリケーションプラットフォームサービス登録. ・サービス・サービス呼び状態変数集合出し条件. ロボット連携ロジック. ビジブルロボット. 状態. ビジブルロボット. アンコンシャスロボット. アプリケーションプラットフォーム. アプリケーションプラットフォーム. アプリケーションプラットフォーム. ロボット情報ロボットコマンド取得部生成部. ロボット情報ロボットコマンド取得部生成部. ロボット情報ロボットコマンド取得部生成部. バーチャルロボットアプリケーションプラットフォーム. Fig 1; Architecture for cooperation during network robots ・複数ロボットの連携: アプリケーションロジックは、さ. ションロジックの実行とロボット間交渉を個々のロボット. まざまな種類のロボット群が提供するサービスの組み. 内に実装されたアプリケーションプラットフォームが処. 合わせとなる。したがって、異種のインタフェースを透. 理する。アプリケーションプラットフォームの機能は、ア. 過的に連携するロジックの定義と実行系が必要とな. プリケーションロジックをロボットに割り当てて遂行する. る。. ためのリモート制御スクリプトと、ロボット間の局所的な. ・ロボット間交渉: ロボット間で仕事を引き継ぐ場合や、. 交渉を行うロボット間協言語からなる。次章以降で、ロ. 複数のロボットが起用力して 1 つの仕事を実行する際. ボットサービスマッチメーカーとリモート制御スクリプト、. にはロボット間交渉が必要となり、そのための言語やプ. ロボット間協調言語について紹介する。. ロトコルの規定が必要となる。。. 4. ロボットサービスマッチメーカー 3.ネットワークロボット連携アーキテクチャ. ロボットサービスマッチメーカーは、各種ロボットが公. 図 1 にネットワークロボットプロジェクトで検討中のアー. 開・提供しており利用可能なサービスの中から、アプリ. キテクチャの基本を示す。実際にはさらに単位空間毎. ケーションで必要とするサービス仕様に合うサービスを. の管理を行うレイヤが存在するが本稿の範囲外となる. 発見する。本プロジェクトでは、バーチャルロボットであ. ので省略した。おおまかなアプリケーション実行の流. るインターネット上の Web サービスの検索を目的として. れは次のようになる。最初、アプリケーションは具体的. 開発済みの Web サービスマッチメーカー[1-4]技術を. なサービス提供ロボットに紐付いておらず連携ロジック. 適用し、ネットワークロボットのための機能拡張を図っ. のみが定義されている。そして、実行前、あるいは、実. た。そこで、まずこの Web サービスマッチメーカーを紹. 行中に個々のサービス呼び出しを処理できるサービス. 介した上で、ビジブルロボットを扱うためにどのような拡. 提供ロボットをロボットサービスマッチメーカーに問い. 張を加えたかを説明する。. 合わせて決定する。その上で、アプリケーションロジッ. 4.1 Web サービスマッチメーカー. クは割り当てたロボットのサービスを呼び出すことによ. Web サービスの検索手順は図 2 の様に、Web サービ. って実行されていく。一方ロボットは必要に応じて他の. スを開発したサービス提供者がサービス仕様を登録し、. ロボットとの間で直接交渉を行う。これらのアプリケー. そして、サービス利用者はそれらの中から利用したい.

(3) 工業製品. サービスを探す。当初の Web サービス検索機能は、主にサービス登録者が自由に設定できるサービス名やサービスカテゴリ、コメントを対象にキーワード検索. AV機器. 家電家電. コンピュータ. が可能であった。しかし、単純なキーワードによる検索は Web サービスの検索には不十分であった。例えばパソコン. ビデオ. HDD レコーダを 100 台注文したい場合に電子商取引. IAサーバ. サービスを検索することを考える。その際、HDD レコーダというキーワードが登録されておらず、たとえば AV 機器というキーワードのみが登録されていると、そのサ. HDDレコーダ HDDレコーダ. 冷蔵庫. PDA. Fig 2; Example of product ontology description. ービスは発見できない。また、納期や配達地域などの条件が希望にあうかどうかもキーワードでは指定でき. ワードで登録しているサービスは、HDD レコーダという. ないことが多い。. キーワードで検索しても発見することができなかった。. そこで、Web サービスマッチメーカーでは、サービス. しかし、マッチメーカーを使えば、図 2 にあるようなオン. のインタフェースにオントロジーや制約条件といったメ. トロジーを参照して AV 機器が HDD レコーダの上位概. タデータを新たに付加している。そして、それらを基に. 念であることを発見し(意味検索)、単語として HDD レコ. 意味検索や制約条件間の包摂関係を判定するア. ーダが登録されていなくても対象となるサービスを見. ルゴリズムを用いて、候補となるサービスを絞り込ん. つけ出すことができる。. でいく。ここで、メタデータとは情報の意味や内容を判. また、従来の Web サービス検索では、納期や配送. 断するために付加するデータのことである。また、オン. 地に関する制約条件を対象としてサービスを検索する. トロジーとは一般に語彙（ごい）体系と呼ばれ、ことば. ことはできなかった。しかし、Web サービスマッチメーカ. の持つ意味に基づいて一種のグラフとして表されたも. ーでは次に示すように、利用者が（1）のような制約条. のであり、制約条件とはサービスを呼び出す際に満た. 件を持つサービスを検索したい場合、仮に（2）のような. されなければならない条件を論理的に記述したもので. 制約条件を持つ部品メーカーのサービスが登録され. ある。簡単な例を用いて以下に説明する。. ていれば、（１）の(a)∼(c)を（2）の(a)∼(c)が満たしてい. 例えば、HDD レコーダを扱う電子商取引サービスを. るということを論理的に判断し（制約条件間の包摂関. 検索する例で、サービス提供者が AV 機器というキー. 係を判定するアルゴリズム）、検索結果として返してく. サービス. サービス仕様. サービス. サービス仕様. Fig 3; Comparison of ordinary Web services searches and with Matchmaker.

(4) れる。 (1)利用者が要求するサービスの制約条件. として、内部状態を抽象化して名前をつけ、その状態名で比較する方法が考えられる。しかし、ビジブルロボ. (a)注文個数＞ 1,000 個. ットの構成はロボット毎にまったく異なり、内部状態の. (b)配送地 ⊂ 東京. 抽象化の仕方も異なる。またその名前の付け方もメー. (c)納期 ≦ ７日. カーや業界によって異なることが予想される。. (2)部品メーカーが提供するサービスの制約条件. そこで、我々は、状態を抽象化するのではなく、プリ. (a)注文個数＞ 100 個. ミティブな状態変数の集合同士を比較することにした。. (b)配送地 ⊂ 関東. これは、状態変数というプリミティブなレベルではどの. (c)納期 ≦ ５日. ビジブルロボットも類似の項目をもっていると考えられ. そのほかにもマッチメーカーは、検索時に利用者がサービスへ与えることのできる情報（品名、注文個数、配送地など）を指定すれば、それが候補となるサービ. るためである。ここで状態変数とは、例えば現在位置やスイッチのオンオフ、車輪の数などである。そして、状態変数の集合同士を比較する方法として、. スが必要としている入力（引数）を満たしているかどうか. 以下のようにする。まず、プリミティブな状態変数を記. を判断することができる。. 述論理のアトミックコンセプトとして定義し、状態変数の. 逆に、候補となるサービスの出力（返値）が、利用者. 集合を記述論理のコンセプトに変換したのち、それら. が必要としている情報（納期など）を満たしているかどう. の包摂関係の判定によって、現在のロボットの状態が、. かを判断することもできる。. サービスを呼び出す際の条件を満たしているかを判定. 従来も、引数のデータ型や個数は指定できたが、引. する。状態変数の集合の比較手法としては、他にルー. 数の情報が持つ意味や出力結果が持つ意味までは. ルベース推論、一階述語論理、ベイジアンネット、ニュ. 検索では扱えなかった。マッチメーカーでは、サービ. ーラルネットワークなどがあるが、記述論理の特徴は. スを呼び出す際に与える引数やサービスの出力結果. 以下である。推論処理時間に関しては一階述語論理. にオントロジーを付加することで、サービス自体が持つ. では NP-hard または決定不能となる場合もあるのに比. 意味を規定できる。また、制約条件を論理的に与える. べて多項式オーﾀﾞで収まり、判定の確実性に関しては、. ことで、提供されているサービスが自分の要求に合う. ベイジアンネットやニューラルネットワークが 100%の確. かどうかを判断することができる。こうした技術を、現在. 実性が無いのに比べて、確実性が高い。さらに条件の. の Web サービス標準の枠組みを壊さずに組み込ん. 記述容易性に関しては、ルールベース推論のようにル. だものが Web サービスマッチメーカーである。. ール間の整合性維持が大変であるということは無い。. 4.2 ロボットサービスマッチメーカーとは Web サービスの検索では、サービス内容や入力引数. 5. リモート制御スクリプト. と返答結果に関するサービス呼び出しインタフェース. リモート制御スクリプトは、アプリケーションのロボット連. などの静的な情報に基づいて検索を行っている。しか. 携ロジックに基づき、各種ロボット群のサービスを呼び. し、それに比べてビジブルロボットは、以下のような動. 出すことで、ロボット群をリモート制御する。リモート制. 的な情報に基づいて検索をする必要がある。. 御スクリプトは、Flipcast[5-7]をベースとして設計中で. (1)位置現実世界に作用するビジブルロボットにおい. ある。以下では、Flipcast について紹介する。. ては、現在位置によって仕事の依頼の可否が決まる。. 5.1 Flipcast とは. 例えば A さんの応対をする場合には、A さんが居るとこ. Flipcast は、ネットワークで接続されたサーバやビ. ろまで移動可能なロボットしか対応できない。. ジブルロボット、機器の間を飛び回りながら仕事をする. (2)負荷多くの要求が同時に来ることが前提となって. ソフトウェアであり、様々なロボットのサービスを呼び出. いるサーバ上の Web サービスと異なり、ビジブルロボッ. しながら連携ロジックを遂行する。例えば、モール街で. トは身体の動作を伴う処理が多く同時に複数の仕事を. 来場者の案内をする場合、以下のように動作する。. こなせないことが多い。. (1)モール街の入り口に設置されたセンサが会員登録. これらの動的な情報は、サービス提供主体の内部状態として扱う。ビジブルロボットの内部状態の判定方法. された A さんの来場を認識すると、サーバ上で案内アプリケーションが起動する。.

(5) ロボットサービスマッチメーカー. え、ビジブルロボットや組み込み機器のネットワーク連携に特化した、以下のような特徴を持つ。. スクリプト. (1)極小フットプリントサイズモール街サーバ. Aさんの携帯電話. 店舗サーバ. ロボットB. 最小パッケージとなる. スクリプト. スクリプト. スクリプト. スクリプト. 携帯電話アプリ版では、プラットフォームを構成する核. アプリケーションプラットフォーム. アプリケーションプラットフォーム. アプリケーションプラットフォーム. アプリケーションプラットフォーム. である、スクリプトの解釈実行部と条件判断などの必須. 案内サービス. メモ帳機能. お勧め情報提供サービス. 移動サービス. サービス 38 種を 11.2KB で実装した。これにネットワー. 説明サービス誘導サービス. ク、データ保持、携帯上グラフィックなどの機能を加え、ターゲットとして設定した機種のアプリ最大容量である 50KB 以下に抑えている。. Fig 4; Example of Flipcast flow. (2)スクリプト移動. 同期処理の必要性によるスクリプ. ト開発の難易度上昇と、アプリケーションプラットフォー (2)A さんの携帯電話の買い物メモを確かめる。 (3)訪問すべき店舗のサーバで、ショッピング情報サービスを利用して、本日のお勧め情報などを取得する。 (4)A さんのそばにいる案内ロボットが、A さんのところに行き、お勧め情報を説明しながらお店に案内する。 5.2 Flipcast の構成 Flipcast は、サーバや各ロボット上で稼働するソフトウェアであるアプリケーションプラットフォームと、その上を自由に移動しながら実行される、スクリプトと呼ばれる指示書で構成される。アプリケーションプラットフォームは、スクリプト内容を解釈実行する役割を持ち、解釈したスクリプトを元に、抽象化された機器機能の呼び出しや、条件判断などを行う。スクリプトは、ユーザの意図する目的ごとに用意される、バッチファイルのような簡単な指示書であり、各ロボットが持つ様々なサービスの呼び出しと制御構造が記述されたプログラムソースである。 Flipcast は、組み込み機器にも搭載可能な小さなフットプリントサイズを実現しているため、家庭用ロボットだけでなく、携帯電話、情報家電などにも応用可能である。 5.3 Flipcast の特徴一般的なスクリプト言語自体は、プログラミング言語の中でも大変ポピュラーなものとして確立しており、数多くの形式が提供され、特に掲示板や各種ポータルなどの Web アプリケーションに広く利用されている。スクリプト言語技術は、アプリケーションの開発・デバッグ・変更の難度を下げ、それらにかかる時間を大幅に短縮することで、アプリケーション数の増大とその多様性を生む。 Flipcast は、既存のスクリプト言語が持つ特徴に加. ムの肥大化を防ぐため、単一のスクリプトが、処理の進行に応じて、実行中に自由に他機器へ移動できるものとした。移動時には、実行状態の情報と、ダイナミックに保持しているデータをあわせて転送し、移動先のプラットフォームでは、これらの情報を参照して、移動前の機器で行われた処理の続きから解釈実行が開始する。 5.4 動作イメージ 5.1 節で述べた例について、スクリプトを実行した場合の動作イメージを以下に示す。 (1)サーバ上で A さんの来場通知がセンサから届くと、案内アプリケーション用のスクリプトが起動され、A さんの携帯電話に移動する。 (2)A さんの携帯電話上でメモ帳の買い物メモを読み込み、その買い物を売っているお店の店舗サーバに移動する。 (3)店舗サーバ上でお店が提供しているショッピング情報サービスを呼び出し、本日のお勧め情報を取得し、A さんのそばにいる案内ロボットをロボットサービスマッチメーカーで探して発見されたロボット B に移動する。 (4)ロボット B 上で A さんの位置まで移動させ、お勧め情報を説明させながら A さんをお店まで誘導させる。. 6. ロボット間協調言語 5 章で挙げたリモート制御は、複数のロボット群が提供するサービスを逐次的に連携してアプリケーションロジックを遂行する。しかし、複数のビジブルロボットが同時に協力して処理を行わなくてはならない場面もある。例えばロボット A が荷物の一方を支え、ロボット B が他方を支えて運ぶ場面などである。あるいは、必要なサービスを提供できるロボットが複数存在する場合に、そ.

(6) の時点で交渉して依頼先を決める場合もあるかもしれない。その様なロボット間の協調問題解決のためには、ネットワークを介した低レベルなコマンド呼び出しだけでは十分でなく、自律的な異種ロボット間で互いが認識している状況や所有している機能に応じて交渉することが必要である。そこで、自律性を有するロボットに対しては、エージェント技術に基づく ACL(Agent Communication Language)と IP(Interaction Protocol)に基づく対話による交渉を検討した。ACL や IP は、エージェント技術に関する国際標準化団体 FIPA[8]が定めた国際標準技術であり、エージェントが互いに自らの意図を伝え合う信念モデル(BDI)に基づく複数エージェント間の協調技術である。 ACL は発話行為理論(Speech-Act-Theory)に基づく、エージェント間通信言語である。対話参加者の間で会話を進める際に行う意味的な行為をパフォーマティブ(performative、通信行為) として規定し、パフォーマティブをメッセージとして相手に送信することによって、ある行為の発生が意図される。例えば、request というパフォーマティブは、送信側が受信側に対して、何らかの行為の実施を要求することを意味する。一方、受信側にとっても、会話の内容がどのような種類の応答を期待しているかを判断することができる。パフォーマティブの例を表 1 に挙げる。そして対話は、複数の主体間で相互にパフォーマティブを送ることにより、ある目的の達成を目指す。この際の、相互作用におけるパフォーマティブの順序列を IP と呼ぶ。IP には、特定のパフォーマティブの順序列が期待されるような、いくつかの典型的なパターンが Table 1; Example of Performative 要旨送信側が受信側に対して，何らかの動作 request の実行を要求する．送信側が知らない情報について，受信側 query に問い合わせる． inform 送信側が知っている情報を通知する．ある動作の実行の申し込みを呼びかけ cfp る．ある特定の事前条件の下で特定の動作を propose (送信側が)実行することを提案する．ある動作を実行するために，先だって申し accept-proposal 出のあった提案を受理する． reject-proposal 先だって申し出のあった提案を却下する． agree 何らかの動作を実行することに同意する．ある動作の実行が可能ではないために拒 refuse 否する．ある動作の実行を試みたが，何らかの理 failure 由により失敗に終わったことを通知する．ある行為を受信したが理解できなかったこ not-understood とを，その行為の送信側に通知する．. Fig 5; Sequences of FIPA-request protocol 存在する。いくつかの典型的なパターンは、 FIPA により、FIPA プロトコルとして規定されている。FIPA プロトコルの例として、FIPA-request プロトコルを紹介する。 FIPA-request プロトコルは、単に 1 つのエージェントが他のエージェントに対してある動作の実行を要求し、受信側エージェントは、その動作を実行するか、又は何らかの方法でその動作を実行できないことを示す応答を返すものである。図 5 に FIPA-request プロトコルの 3 種類のシーケンスを示す。今、エージェント i がエージェント j. に対して、ある動作 action の実行を. 要求していると仮定する。 (a) エージェント i. はエージェント j. に対して、. request を送信する。その要求に対して、エージェント j が合意した場合は、一旦 agree を返し、その後、動作 action の実行が完了した時点で、その旨を inform を使って通知する。 (b) エージェント j. が一旦は合意したものの、その. 後何らかの理由で動作 action を実行できない場合、 failure とその理由を返す。 (c) エージェント i の要求に対して、エージェント j が合意できない場合は、refuse とその理由を返す。. パフォーマティブ. 我々は、既に FIPA エージェント仕様に基づくマルチエージェントシステムとして Bee-gent[9-11]を開発しており、これをベースにネットワークロボット用協調言語としてプロファイル化を予定している。Bee-gent 全体の紹介はここでは省くが、ACL と IP の定義支援機能を紹介する。図 6 に IP の定義画面、図 7 に ACL 定義画面を示す。これらのツールを用いて、IP や ACL を定義することにより、対話部分のソースコードを生成する機能を持つ。Bee-gent の ACL 通信機能を中心に、このような対話定義支援の機能の導入も検討していきたい。具体的な協調言語やプロトコルの開発は今年度進めていく予定である。.

(7) Fig 6; GUI for defining. Fig 7; GUI for defining ACL. 7. おわりにビジブルロボット、アンコンシャスロボット、そしてバーチャルロボットといった、異種のロボット群を透過的に連携する枠組みと、その際に必要な技術要素について述べた。2 章で挙げた異種ロボット連携の課題に対する回答として、サービス発見技術、リモート制御技術、ロボット間協調言語技術を示した。今後、ネットワークロボットプロジェクトでの実証実験を通して、効果を検証していく。謝辞本研究は総務省の研究委託により実施したものである参考文献 [1]川村、長谷川、大須賀、「XML Web サービスマッチメーカー」、東芝レビュー Web サービス特集号、Vol.58, No.2, 2003 [2]Web サービスマッチメーカーホームページ; http://www.agent-net.com [3]T. Kawamura, J. D. Blasio, T. Hasegawa, M. Paolucci, K. Sycara, "Public Deployment of Semantic Service Matchmaker with UDDI Business Registry," Proceedings of 3rd International Semantic Web Conference (ISWC 2004), LNCS 3298, pp. 752-766, 2004 [4]T. Kawamura, J. D. Blasio, T. Hasegawa, M. Paolucci, K. Sycara, "Preliminary Report of Public Experiment of. Semantic Service Matchmaker with UDDI Business Registry," Proceedings of First International Conference on Service Oriented Computing (ICSOC 2003), LNCS No. 2910, pp. 208-224, 2003 [5]上野、長谷川、大須賀、「ロボットをユビキタスの世界へ誘うエージェント」、東芝レビューホームロボット特集号、 Vol.59, No.9, 2004 [6] K. Ueno, T. Kawamura, T. Hasegawa, A. Ohsuga, M. Doi, "Cooperation between Robots and Ubiquitous Devices with Network Script Flipcast," Proceedings of Network Robot System: Toward intelligent robotic systems integrated with environments (IROS 2004 Workshop), 2004 [7]上野、釜洞、川村、長谷川、大須賀、本位田、「携帯電話上で記述・即時実行可能なネットワークスクリプト Flipcast」、オブジェクト指向２００２シンポジウム、2002 [8]FIPA ホームページ; http://www.fipa.org [9]Bee-gent ホームページ; http://www.toshiba.co.jp/rdc/beegent/index_j.htm [10]川村隆浩, 田原康之, 長谷川哲夫, 大須賀昭彦, 本位田真一、「Bee-gent：移動型仲介エージェントによる既存システムの柔軟な活用を目的としたマルチエージェントフレームワーク」、電子通信学会論文誌(D-I), Vol. J82-D-I、No. 9、pp. 1165-1180、1999 [11]Shinichi Nagano, Yasuyuki Tahara, Tetsuo Hasegawa, and Akihiko Ohsuga, "Development of Agent-Based Electronic Catalog Retrieval System," Proc. of 2003 International Conference on Intelligent Agents, Web Technologies and Internet Commerce (IAWTIC'2003), pp.112-113, 2003.

(8)