JP2003330899A - 情報処理方法 - Google Patents

Abstract

(57)【要約】 【課題】 端末装置のリソースをより柔軟に利用し、ま
た、各端末装置においてアプリケーションの効率的な処
理を実現する。 【解決手段】 監視ＭＡ34-A1からの交渉開始要求に応
答して、コーディネータ30-1は、ミドルウェアを構成す
る移動可能なエージェントであるサービスＭＡ32-A1を
移動させるための交渉を開始する。交渉においては、コ
ーディネータ30-1は、通信可能な他の端末装置20-2に対
して、そのコーディネータ30-2に調査を依頼し、調査結
果を受理する。調査結果には、サービスＭＡが移動する
ことに伴う影響度が含まれる。コーディネータ30-1は、
サービスＭＡの移動に伴う影響度を考慮して、サービス
ＭＡ32-A1を動作させるのに適した端末装置を選択す
る。選択にしたがって、サービスＭＡ32-A1は自律的に
移動する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数の情報処理装
置をデータ通信網で接続して、分散して処理を実行する
手法に関する。

【０００２】

【従来の技術】ネットワークの普及により、種々の情報
が、サーバからネットワークを介して情報処理装置に提
供できるようになっている。その一方、携帯端末装置の
性能の向上に伴い、当該携帯端末装置が、ネットワーク
を介してサーバに接続して、種々の情報を取得すること
も可能となっている。

【０００３】このようなネットワークを介して種々の端
末装置が接続されている形態では、処理を行なう際に、
単一の端末装置の資源のみを使用するのではなく、ネッ
トワークを介して接続されている複数の端末装置の計算
資源を利用するのが望ましい。このような技術において
は、（１）予め特定の端末装置を指定しておき、ある端
末装置において他の端末装置での処理が必要な場合に、
当該特定の端末装置に処理を依頼する手法、

【０００４】（２）中央制御装置を設け、ネットワーク
に接続されている端末装置を監視し、処理可能な端末装
置に処理を依頼する手法が知られている。処理中の端末
装置の負荷が過度に大きくなった場合や、メモリの空き
容量が不足する場合に、上記（１）や（２）の手法を用
いて、ユーザが利用するアプリケーションを含む処理プ
ロセスを他の端末装置に移動させる。依頼を受けた端末
装置は、必要な処理を実行して、処理結果を依頼元の端
末装置に返す。たとえば、処理プロセスを移動させる手
法の一例が、特開平７−１５２６９９号公報に開示され
ている。ここでは、あるコンピュータの負荷量が基準値
を超えた場合に、負荷の比較的少ない他のコンピュータ
にプロセスを移動するようになっている。

【０００５】

【発明が解決しようとする課題】しかしながら、従来の
手法においては、ユーザが利用するアプリケーションを
含むプロセス自体を移動させていた。このため、アプリ
ケーションを移動させるという前提の下で、アプリケー
ションを設計する必要があった。また、アプリケーショ
ンがユーザインタフェースを含む場合には、処理を依頼
している間に、そのアプリケーションを使用することが
できない。

【０００６】また、携帯端末を含む、それぞれ性能が異
なる種々の端末装置がネットワークを介して接続されて
いる場合に、端末装置の絶対的な処理能力がわからない
と、適切に負荷を分散することができないという問題点
があった。たとえば、ＣＰＵの負荷量が５０％のパーソ
ナルコンピュータと、ＣＰＵの負荷量が１０％の携帯電
話とでは、当然、パーソナルコンピュータの処理能力が
優れるが、このような情報を適切に把握して、処理分散
を実現することができなかった。そこで、本出願人は、
他の端末装置上のリソースの有効利用や環境の変化に対
応できるモバイルエージェント（ＭＡ）を基盤とするミ
ドルウェアを提案し、これを出願している（特願２００
２−４７７１７号）。

【０００７】しかしながら、複数のモバイルエージェン
トがリソースを共有するような場合には、（１）移動後
のリソース再配分を考慮した移動制御、（２）自端末装
置の状態だけでなく、他の端末装置の状態をトリガとし
た移動制御が実現できるのが望ましい。本発明は、各端
末装置のリソースをより柔軟に利用でき、また、各端末
装置においてアプリケーションの効率的な処理を実現で
きるシステムを提供することを目的とする。

【０００８】

【課題を解決するための手段】本発明の目的は、端末装
置で、アプリケーションの依頼に応答して、ミドルウェ
ア中の種々の移動可能なエージェントである１以上のサ
ービスモバイルエージェント（サービスＭＡ）を稼動し
て、当該アプリケーションの機能を実現する情報処理方
法において、あるサービスＭＡの移動ポリシに基づき、
当該サービスＭＡを移動させるための条件が満たされる
場合に、コーディネータにおいて、エリアポリシにした
がって、通信可能な他の端末装置に対して、調査を要求
し、当該他の端末装置のコーディネータに、当該他の端
末装置において、サービスＭＡが移動することに伴う影
響度を調査させるとともに、前記自己の端末装置におい
て、サービスＭＡが移動することに伴う影響度を調査す
るステップと、前記他の端末装置からの調査結果および
自己の調査結果を受理し、前記サービスＭＡの移動に伴
う影響度を考慮して、サービスＭＡを動作させるのに適
した端末装置を選択するステップと、前記サービスＭＡ
に対して、選択された端末装置が他の端末装置である場
合に、当該他の端末装置への移動を要求するステップ
と、前記サービスＭＡにおいて、移動要求に応答し、前
記選択された他の端末装置に移動して、処理を実行する
ステップとを備えたことを特徴とする情報処理方法によ
り達成される。

【０００９】本発明によれば、他の端末装置（移動先の
端末装置）において、サービスＭＡを受け入れた場合
の、当該他の端末装置などにおける影響度を含む調査結
果を作り、その一方、端末装置（移動元の端末装置）に
おいては、自己のサービスＭＡが移動したことによる影
響（好影響）を含む調査結果を作成する。したがって、
これらを考慮して、たとえば、処理時間の著しい低下な
どの悪影響が少なくなるように、サービスＭＡの移動先
を決定することが可能となる。これにより、アプリケー
ションをより効率的に処理することができる。また、各
端末装置のリソースを柔軟に利用することも可能とな
る。

【００１０】好ましい実施態様においては、さらに、リ
ソースマネージャにおいて、端末装置において動作する
サービスＭＡに与えるべきリソースの割当量を、サービ
スＭＡの数および各サービスＭＡの属性にしたがって動
的に決定するステップを備え、前記調査するステップ
が、前記コーディネータにおいて、前記リソースマネー
ジャに対して、前記サービスＭＡの移動後の各サービス
ＭＡへの新たなリソースの割当量の算出を要求するステ
ップと、前記新たなリソースの割当量に基づき、前記影
響度を表す値を算出するステップとを有している。

【００１１】本実施の形態によれば、リソースマネージ
ャにより、サービスＭＡに割り当てるべきリソースの割
当量が動的に設定される。サービスＭＡの移動前後の各
サービスＭＡのリソースの割当量に基づき、影響度を計
算し、これを利用してサービスＭＡの移動先が決定され
る。より好ましい実施態様においては、前記影響度を表
す値を算出するステップが、各サービスＭＡにおける処
理時間の予想値を算出するステップを含み、前記サービ
スＭＡを動作させるのに適した端末装置を選択するステ
ップが、前記移動前後の各サービスＭＡの処理に関する
予想値の最大値に基づき、端末装置を選択するステップ
を有する。

【００１２】より好ましくは、前記端末装置を選択する
ステップが、サービスＭＡの移動元となる端末装置にお
ける最大値が、サービスＭＡの移動先の候補となる端末
装置における最大値以上である場合に、当該候補となる
端末装置を、サービスＭＡを動作させるのに適した端末
装置と決定するステップを含む。

【００１３】さらに、予想値を算出するステップが、サ
ービスＭＡにおけるデータ通信時間および／またはサー
ビスＭＡの移動時間を考慮して、値を算出するのがのぞ
ましい。サービスＭＡが移動した場合の、移動時間を含
む処理時間に基づき、サービスＭＡの移動の是非を判断
するため、より適切な判断をなすことが可能となる。

【００１４】たとえば、端末装置における予想値を算出
するステップが、前記端末装置におけるｉ番目のサービ
スＭＡ_ｉが他の端末装置に移動する可能性がある場合
に、 ｍａｘ｛ｆ（ｊ，ｒ_ｊ）｝＝サービスＭＡ_ｊの処理時間
＋サービスＭＡ_ｊのデータ通信時間 （ただし、ｊは、ｊ番目のサービスＭＡ、ｒはサービス
ＭＡ_ｉが移動する前のリソース割当量を示す）を、サー
ビスＭＡの移動前の予想値として算出するステップと、 ｍａｘ｛ｆ（ｊ，ｒ_ｊ’）｝＝サービスＭＡ_ｊの処理時
間＋サービスＭＡ_ｊのデータ通信時間＋（サービスＭＡ
_ｊの移動時間（ｊ＝ｉの場合）または０（ｊ≠ｉ）の場
合） （ただし、ｊは、ｊ番目のサービスＭＡ、ｒ’はサービ
スＭＡ_ｉが移動した後のリソース割当量を示す）を、サ
ービスＭＡの移動後の予想値として算出するステップと
を有する。

【００１５】また、別の好ましい実施態様においては、
さらに、サービスＭＡにおいて、モバイルエージェント
間およびアプリケーションとの間に介在するマネージャ
を介して、定められた監視項目の調査を実行する１以上
の監視モバイルエージェント（監視ＭＡ）に、当該監視
項目の調査を依頼するステップと、前記サービスＭＡに
おいて、所定の移動ポリシをコーディネータに登録する
ステップと、前記コーディネータにおいて、前記監視Ｍ
Ａからの通知を受理して、端末装置間における交渉を開
始するステップとを備え、前記交渉の中で前記移動ポリ
シを参照して、前記サービスＭＡの移動先を決定する。

【００１６】この実施態様によれば、あらかじめ移動ポ
リシをコーディネータに登録しておき、監視ＭＡからの
通知が、サービスＭＡを経ることなくコーディネータに
伝達されることにより、サービスＭＡの処理とは独立に
交渉を行なうことができる。これにより、サービスＭＡ
は、アプリケーションの機能を実現するために必要な処
理に専念することができる。

【００１７】また、本発明の目的は、アプリケーション
の依頼に応答して、ミドルウェア中の種々の移動可能な
エージェントである１以上のサービスモバイルエージェ
ント（サービスＭＡ）を動作させて、当該アプリケーシ
ョンの機能を実現する情報処理方法において、リソース
マネージャにおいて、端末装置において動作するサービ
スＭＡに与えるべきリソースの割当量を管理するステッ
プと、前記リソースマネージャにおいて、リソースの余
裕度を表す値を算出するステップと、前記余裕度を表す
値が所定の閾値を超えた場合に、コーディネータに、他
の端末装置への交渉開始を要求するステップと、前記コ
ーディネータにおいて、エリアポリシにしたがって、通
信可能な他の端末装置に対して、その余裕度を表す値を
調査させて、他の端末装置におけるサービスＭＡを移動
させるための交渉を促すステップと、前記他の端末装置
のコーディネータにおいて、サービスＭＡの移動の是非
を判断するステップと、サービスＭＡを移動すべき場合
に、当該他の端末装置で稼動中の所定のサービスＭＡに
対して、前記端末装置への移動を要求するステップと、
前記サービスＭＡにおいて、移動要求に応答し、前記端
末装置に移動して、処理を実行するステップとを備えた
ことを特徴とする情報処理方法によっても達成される。

【００１８】本発明によれば、端末装置のリソースに余
裕がある、つまり、遊休資源が存在する場合に、他の端
末装置、特に、リソースに余裕がない状態の端末装置の
サービスＭＡを受け入れて、当該サービスＭＡに、遊休
資源を利用させることができる。これにより、リソース
の柔軟な利用や、システム全体としての処理効率の向上
を実現することが可能となる。好ましい実施態様におい
ては、さらに、リソースマネージャにおいて、端末装置
において動作するサービスＭＡに与えるべきリソースの
割当量を、サービスＭＡの数および各サービスＭＡの属
性にしたがって動的に決定するステップを備えている。

【００１９】また、好ましい実施態様においては、前記
余裕度を表す値を算出するステップが、（１−Ｒ_ａ／Ｒ
_Ｔ）で表されるリソース余裕率（ここに、Ｒ_Ｔは、全リ
ソース量、Ｒ_ａは、端末装置で稼動する各サービスＭＡ
が最小限必要とするリソース量の総和）を算出するステ
ップを有する。また、前記余裕度を表す値を算出するス
テップが、（Ｒ_Ｔ−Ｒ_ａ）で表されるリソース余裕量
（ここに、Ｒ_Ｔは、全リソース量、Ｒ_ａは、端末装置で
稼動する各サービスＭＡが最小限必要とするリソース量
の総和）を算出するステップを有していても良い。

【００２０】別の好ましい実施態様においては、前記移
動の是非を判断するステップが、前記他の端末装置にお
いて、自己の余裕度を示す値より、前記端末装置に関す
る余裕度を示す値が大きい場合に、前記移動のための交
渉を開始するステップを有する。この実施態様によれ
ば、端末装置間のサービスＭＡの移動に関する交渉のト
リガとして、余裕度を利用し、一定の場合に、より詳細
な調査が実行され、サービスＭＡの移動の是非が判断さ
れる。したがって、余裕度に基づく比較的簡単な判断に
より、交渉開始の是非を判断でき、無駄な交渉の数を減
らすことが可能となる。

【００２１】より好ましい実施態様においては、さら
に、前記交渉の開始に引き続いて、前記他の端末装置の
コーディネータにおいて、前記端末装置に対して、調査
を要求し、当該端末装置のコーディネータに、当該端末
装置において、前記他の端末装置で稼動している所定の
サービスＭＡが移動することに伴う影響度を調査させる
とともに、前記自己の端末装置において、サービスＭＡ
が移動することに伴う影響度を調査するステップと、前
記端末装置からの調査結果および自己の調査結果を受理
し、前記サービスＭＡの移動に伴う影響度を考慮して、
サービスＭＡを移動させるべきか否かを判断するステッ
プを備えている。この実施態様によれば、余裕度を利用
した予備的な判断の後、必要な場合には、実際にサービ
スＭＡを移動させた場合の影響度を考慮した、移動の是
非が判断される。

【００２２】

【発明の実施の形態】以下、添付図面を参照して、本発
明の実施の形態につき説明を加える。図１は、本実施の
形態にかかる端末装置の構成を示すブロックダイヤグラ
ムである。図１に示すように、ハードウェア（Ｈ／Ｗ）
１４上にオペレーティングシステム１６、ミドルウェア
１８が配置され、ミドルウェア１８上で種々のアプリケ
ーション２０が動作できるようになっている。図１に示
すように、ミドルウェア２０は、アプリケーションと後
述するエージェントとの間に介在したエージェント管理
部２２、サービスモバイルエージェント群２３、監視モ
バイルエージェント群２４、および、モバイルエージェ
ント実行環境２６を有している。

【００２３】エージェント管理部２２には、アプリケー
ション２０と後述するモバイルエージェントとの間や、
異なるモバイルエージェント間のブローカとして機能す
るマネージャ２８、および、他の端末装置中のコーディ
ネータと協調して動作し、サービスモバイルエージェン
ト等の移動先端末を決定するための交渉を実行するコー
ディネータ３０を有している。

【００２４】サービスモバイルエージェント群２３に
は、アプリケーション２０の機能を提供するための種々
のサービスモバイルエージェント（サービスＭＡ）、た
とえば、アプリケーション２０のある機能を実現する処
理Ｐ１（３Ｄグラフィクス処理など）に関するサービス
ＭＡ３２−１、処理Ｐ２に関するサービスＭＡ３２−
２、・・・が含まれる。監視モバイルエージェント（監
視ＭＡ）群２４には、ミドルウェアまたはアプリケーシ
ョンから利用される実行環境を監視する機能を有する種
々の監視ＭＡ３４−１、３４−２、・・・が含まれる。
監視ＭＡ３４の各々により、たとえば、ＣＰＵ能力、帯
域幅、メモリ容量、ユーザ位置などアプリケーション２
０の実行にかかわる情報が取得される。

【００２５】また、モバイルエージェント実行環境２６
は、サービスＭＡ３２や監視ＭＡ３４の起動、移動、複
製や識別子の管理といった基本制御機能を提供する。本
実施の形態において、モバイルエージェント実行環境２
６は、各ＭＡが実行する処理の特性や利用可能なリソー
ス量の変動にあわせて適切にリソースを配分するための
処理を実行するリソースマネージャ３６を有している。
本実施の形態においては、後述するように、一定のロジ
ックにしたがって、端末装置（以下、場合によって「ノ
ード」とも称する）内のＭＡの生成、消滅或いは移動に
伴って、ＭＡに割り当てるべきリソースを動的に配分す
る。

【００２６】このため、リソースマネージャ３６は、ノ
ード内のリソースを柔軟に利用するために、後述する各
ノードの割り当てポリシにしたがって、割り当て可能な
リソースを、各ＭＡの最小限必要なリソース量を基準に
して配分する。ここで、割り当て可能なリソースは、ノ
ード毎に最大割当量を設定することが可能であり、ノー
ドの内部状態によって変動する。また、最小限必要なリ
ソース量は各ＭＡ内部に定義されている。なお、リソー
スマネージャを導入することにより、不正なプログラム
が記述されたＭＡがリソースを浪費することを防止でき
る。

【００２７】図２は、複数の端末装置の間におけるデー
タ授受の概略を示す図である。図２では、端末装置
「Ａ」１０−１と、端末装置「Ｂ」１０−２とが図示さ
れているが、情報端末「Ｃ」や端末装置「Ｄ」との間で
も同様のデータ通信が実行される。端末装置「Ａ」１０
−１のアプリケーション「Ａ」２０−１は、マネージャ
「Ａ」２８−１を介して、サービスＭＡ３２−Ａ１の処
理の実行を依頼する。また、サービスＭＡ３２−Ａ１
も、処理結果を、マネージャ「Ａ」２８−１を介して、
アプリケーション「Ａ」２０−１に返す。端末装置
「Ｂ」１０−２においても同様である。また、サービス
ＭＡ３２の移動は、マネージャ「Ａ」２８−１を介した
コーディネータ「Ａ」３０−１からの移動要求に応答し
て、サービスＭＡ３２が自律的に移動することにより実
現される。

【００２８】アプリケーション２０は、必要に応じてサ
ービスＭＡ３２が提供する様々な機能を利用する。サー
ビスＭＡは一意の識別子（たとえば、名前やＩＤ）によ
り管理され、アプリケーション２０はサービスＭＡ３２
の識別子、呼び出すメソッドおよび引数を指定すること
により、サービスＭＡ３２に処理を実行させる。このと
き、マネージャ２８は、ブローカとして機能し、アプリ
ケーション２０はマネージャ２８を介してサービスＭＡ
３２に処理を実行させる。また、サービスＭＡ３２が他
端末に移動している場合、アプリケーション２０はマネ
ージャ２８を介して他の端末装置に移動したサービスＭ
Ａ３２へ実行要求し、その実行結果を受け取る。

【００２９】監視ＭＡ３４も、サービスＭＡ３２からの
マネージャ２８を介しての監視要求に応答して、たとえ
ば、メモリ容量などの必要な監視処理の実行を開始し、
その結果を、マネージャ２８を介してコーディネータ３
０に通知するようになっている。

【００３０】以下、サービスＭＡ３２、監視ＭＡ３４お
よびコーディネータ３０の構成につきより詳細に説明を
加える。本実施の形態において、サービスＭＡ３２およ
び監視ＭＡ３４を含むモバイルエージェントは、コード
部およびデータ部を有する。つまり、本実施の形態で
は、後述するモバイルエージェントの移動に伴い、デー
タ部とともにコード部も、他の端末装置に移動する。コ
ード部は、移動要求や複製要求の受理に応答して、ＭＡ
実行環境２６を利用して、自己の移動や複製を実行する
ＭＡ制御処理を実行できるようになっている。

【００３１】図３（ａ）に示すように、サービスＭＡ３
２は、コード部３２０とデータ部３２１とを有する。コ
ード部３２０には、たとえば、複製、移動などに関する
ＭＡ制御処理、３Ｄグラフィクス演算、浮動小数点演算
などサービスＭＡ固有の処理、コーディネータへの登録
処理、起動時に実行される監視ＭＡ３４への監視要求処
理など種々の処理コードが含まれる。また、データ部３
２１は、サービスＭＡの処理に必要な変数の値などを含
む実行時データ３２２と、移動条件３３０および評価基
準３３１を含む移動ポリシ３２３を有している。移動条
件３３０は、交渉開始の判定および監視項目の決定に関
し、評価基準は、調査結果の判定および調査項目の決定
に関する。

【００３２】サービスＭＡ（たとえば、サービスＭＡ処
理Ｐ１（Ａ）：３２−Ａ１）は、基本的には、図３
（ａ）に示すように、マネージャ２８−１を介して与え
られたアプリケーション２０−１からの実行要求（矢印
３０１、３０２参照）に応答して、サービスＭＡ３２−
Ａ１は、処理の実行を開始し、その結果を、マネージャ
２８−１を介してアプリケーション２０−１に返すよう
になっている。図３（ｂ）に示すように、監視ＭＡ３４
は、コード部３４０とデータ部３４１とを有する。コー
ド部３４０には、たとえば、複製、移動などに関するＭ
Ａ制御処理、定期的な監視処理やオンデマンドの調査処
理など監視ＭＡに固有の処理、コーディネータへの通知
処理などの種々の処理コードが含まれる。データ部３４
１には、監視ＭＡの処理に必要な変数の値などを含む実
行時データ３４２が含まれる。

【００３３】本実施の形態においては、監視ＭＡは複数
設けられそれぞれ、処理Ｓ１（メモリ空き容量）、処理
Ｓ２（ＣＰＵ負荷状態）、処理Ｓ３（端末間の通信速
度）、処理Ｓ４（バッテリ残量）などの監視処理を実行
できるようになっている。監視ＭＡ（たとえば、監視Ｍ
Ａ処理Ｓ１（Ａ）：３４−Ａ１）は、基本的には、図３
（ｂ）に示すように、マネージャ２８−１を介して与え
られたサービスＭＡ３２−Ａ１からの実行要求（矢印３
１１、３１２）に応答して、所定の監視処理（たとえ
ば、メモリ容量が２０ＭＢを下回ったか否か）を実行す
る。

【００３４】図４は、本実施の形態にかかるコーディネ
ータ３０をより詳細に示す図である。図４に示すよう
に、他の端末装置からの交渉開始要求を受信する交渉開
始要求受信処理部４１０、交渉に関する種々の処理を実
行する交渉処理部４１１、および、ＭＡに対してその移
動を要求する移動要求処理部４１３を有している。交渉
処理部は、後に詳述するように、必要なときに他の端末
装置に対する調査要求を生成し（調査要求生成処理
部）、調査要求を送信し（調査要求送信処理部）、調査
結果を依頼元の端末装置に送信（返信）し（調査結果回
答送信処理部）、各端末装置から取得した調査結果に基
づき、ＭＡを移動すべき端末を判定し（判定処理部）、
かつ、判定結果を各端末装置に送信（判定結果回答送信
処理部）できるようになっている。

【００３５】コーディネータ３０−１は、基本的には、
以下のように動作する。図４に示すように、マネージャ
２８−１を介して与えられた監視ＭＡ３４−Ａ１からの
通知に応答して（矢印４０１、４０２参照）、コーディ
ネータ３０−１は、調査要求を他の端末装置（たとえ
ば、端末装置１０−２）のコーディネータ（たとえば、
コーディネータ３０−２）に伝達し、調査結果を受理
し、判定の後判定結果を回答する。なお、このようなコ
ーディネータ間の一連の処理を「交渉」とも称する。交
渉の後、マネージャ２８−１を介して、移動させるべき
ＭＡ３２−Ａ１に対して、移動要求を伝達する（矢印４
０４参照）。

【００３６】以下、本実施の形態にかかる端末装置間の
ＭＡの移動に関する種々の処理につき、図５〜図８を参
照して説明を加える。図５（ａ）は、端末装置「Ａ」１
０−１において、アプリケーション２０−１がある処理
Ｐ１を実行する必要が生じると、処理Ｐ１の実行要求が
マネージャ２８−１を介して処理Ｐ１にかかるサービス
ＭＡ３２−Ａ１に伝達される（ステップ５０１、５０
２）。これにより、サービスＭＡ３２−Ａ１において、
定められた処理が実行される。

【００３７】その一方、本実施の形態においては、後述
する交渉処理の後、分散処理を実行する他の端末装置
「Ｂ」１０−２が決定され、当該他の端末装置「Ｂ」１
０−２に、サービスＭＡ３２−Ａ１が移動して、他の端
末装置「Ｂ」１０−２において定められた処理が実行さ
れる場合もある。図５（ｂ）は、そのときの処理を示す
フローチャートである。端末装置「Ａ」１０−１のアプ
リケーション２０−１からの処理Ｐ１の実行要求は、マ
ネージャ２８−１を介して、端末装置「Ｂ」２０−２の
マネージャに伝達される（ステップ５１１、５１２）。
次いで、実行要求は、端末装置「Ｂ」１０−２に移動し
ているサービスＭＡ３２−Ａ１に伝達され、当該サービ
スＭＡ３２−Ａ１にて定められた処理が実行される。

【００３８】図５（ｂ）に示すような分散処理を実現す
るための手順につき、以下に説明を加える。サービスＭ
Ａ３２−Ａ１では、起動時や処理中の必要なとき（基本
的には起動時）に、メモリ容量、ＣＰＵ負荷などの監視
を要求する。図６（ａ）および（ｂ）は、監視要求およ
びこれに応答した通知に関連する処理を示すフローチャ
ートである。サービスＭＡ３２−Ａ１からの監視要求
は、マネージャ２８−１を介して監視ＭＡ３４−Ａ１に
伝達される（ステップ６０１、６０２）。このとき、サ
ービスＭＡ３２−Ａ１は、データ部に保持している移動
条件（図３（ａ）の符号３３０参照）も、監視要求とと
もに伝達する。

【００３９】また、サービスＭＡ３２−Ａ１は、起動時
や処理中の必要なとき（基本的には起動時）に、交渉の
中で移動先を判定するのに使用される評価基準を、マネ
ージャ２８−１を介して、コーディネータ３０−１に伝
達し（ステップ６１１、６１２）、当該評価基準をコー
ディネータ３０−１に登録しておく。

【００４０】監視ＭＡ３４−Ａ１は、ポーリングにより
リソースマネージャ３６−１から必要な情報を取得し
（ステップ６２１）、或いは、他の手段により、定めら
れた項目を監視し、移動条件に定められた事項（たとえ
ばメモリ容量に基づく条件）を満足すると、交渉開始要
求を、マネージャ２８−１を介して、コーディネータ３
０−１に伝達する（ステップ６２２、６２３）。本実施
の形態においては、コーディネータ３０−１に、サービ
スＭＡ３２−Ａ１に関して、他のノードとの交渉の中で
移動先を判定するのに使用される評価基準を事前に登録
しておく。これにより、監視ＭＡ３４−Ａ１からの情報
を、いったんサービスＭＡ３２−Ａ１に伝達し、サービ
スＭＡ３２−Ａ１からマネージャ２８−１を介してコー
ディネータ３０−１に交渉開始要求が通知されるという
手順を経ることなく、換言すれば、サービスＭＡ３２−
Ａ１における本来の処理を中断させることなく、交渉開
始要求をコーディネータ３０−１に伝達することが可能
となる。

【００４１】コーディネータ３０−１は、端末装置１０
−１と通信可能な状態になっている他の端末装置の各々
に、調査要求を送信する（ステップ７０１）。なお、図
７においては、調査要求が、端末装置「Ｂ」１０−２に
のみ送られているが、実際には他の端末装置にも、調査
要求はマルチキャストされている。また、コーディネー
タ３０−１は、自己の状況を知るために、自身（端末装
置１０−１）のリソースマネージャ３６−１にも調査要
求を伝達する（ステップ７０３）。

【００４２】調査要求を受理した他の端末装置「Ｂ」１
０−２のコーディネータは、当該端末装置「Ｂ」１０−
２のリソースマネージャ３６−２に対して、調査要求を
伝達する（ステップ７０２）。リソースマネージャ３６
−２においては、当該端末装置「Ｂ」における各サービ
スＭＡに割り当てるリソースの割当量を算出して、これ
を回答として、コーディネータに返送する（ステップ７
０４）。ここで算出される割当量については、後に詳述
する。コーディネータ３０−２は、リソースマネージャ
からの回答に基づき、コーディネータ３０−２が、サー
ビスＭＡを受け入れた場合の影響度を、後述する所定の
評価式にしたがって算出し（ステップ７０５）、これを
調査結果として回答する（ステップ７０６）。

【００４３】端末装置「Ａ」１０−１のリソースマネー
ジャ３６−１も、同様に、当該端末装置「Ａ」１０−１
における各サービスＭＡに割り当てるリソースの割当量
を算出し、これをコーディネータ３０−１に伝達する
（ステップ７０７）。コーディネータ３０−１も、サー
ビスＭＡを移動させた場合の影響度を、後述する所定の
評価式にしたがって算出する（ステップ７０８）。次い
で、図８に示すように、コーディネータ３０−１におい
て、調査結果を判定し、サービスＭＡによる処理を実行
するのに最も望ましい端末装置が判定される（ステップ
８０１）。

【００４４】ここで、本実施の形態におけるサービスＭ
Ａの移動に関する判定、および、この判定に作用するリ
ソースマネージャにおける処理につき、以下により詳細
に説明する。リソースマネージャ３６は、所定の割り当
てポリシにしたがって、リソースの割当量を算出する。
図９（ａ）は、あるサービスＭＡの処理に割り当てるべ
きリソースを説明する図である。図９（ａ）に示すよう
に、本実施の形態においては、あるサービスＭＡによる
処理に、リソースの割当量として、処理を適切に実行す
るために最小限必要な第１の量（符号９０２参照）と、
余裕を持たせるために与える第２の量（符号９０３参
照）とを割り当てるようになっている。したがって、第
１の量と第２の量とを足したものが、あるサービスＭＡ
へのリソースの割当量となる（符合９０１参照）。

【００４５】本実施の形態においては、各サービスＭＡ
について、第１の量と第２の量との比が、「１：α」と
なるように、割当量が決められる。たとえば、４つのサ
ービスＭＡによる「処理１」〜「処理４」が、それぞ
れ、図９（ｂ）の符号９１１〜９１４にて示し、割り当
て可能なリソースの全体が符号９１０にて示すような場
合に、リソースマネージャ３６は、「処理１」〜「処理
４」のそれぞれについて、第１の量と第２の量との比
が、それぞれ「１：α」となるように、割当量を決定す
る（符合９２１〜９２４参照）。つまり、各ＭＡについ
て、最小限の必要量と余裕を持たせた量とが同じ比とな
るように、かつ、割り当て可能なリソースの全体を利用
するように、αの値を算出して、それぞれの割当量が決
定される。

【００４６】このように、リソースマネージャ３６によ
り、各サービスＭＡには最小限必要なリソース量を基準
とした割当量が与えられる。ここで、あるサービスＭＡ
が、他の端末装置に移動すると、移動先の端末装置にお
ける各サービスＭＡに対する割当量は小さくなり、その
結果、当該移動先の端末装置において、すでに処理を実
行しているサービスＭＡのパフォーマンスが低下する場
合がある。そこで、サービスＭＡの移動の際には、移動
元の端末装置におけるサービスＭＡや、当該端末装置の
パフォーマンスだけでなく、他の端末装置のサービスＭ
Ａへの影響も考慮して、移動先を決定するのが望まし
い。

【００４７】その一方、アプリケーションへの応答時間
を考えた場合には，単純にリソース割当量の大小だけで
なく、サービスＭＡの通信量や移動コストを考慮した移
動制御を行なう必要がある。そこで、本実施の形態にお
いては、これらを考慮した評価基準を定義し、この評価
基準に基づいた交渉を行なうことによりサービスＭＡの
移動先を決定している。ここで、評価基準は、移動先と
して最適なノード（端末装置）を選択するための評価式
と、移動先ノードが満たすべき条件を定義する制約条件
とで構成される。

【００４８】一例として，並列に実行されている各サー
ビスＭＡのアプリケーションの応答時間を評価式とし
て、最大応答時間を最小化する場合を例に説明する。こ
の例では、図１０に示すように、割り当て可能なリソー
スの総量が比較的小さい端末装置「Ａ」（たとえば、Ｐ
ＤＡ）１０００−１において、あるアプリケーションの
要求に応答して、「サービスＭＡ１（処理Ｐ１(Ａ)）」
３２−Ａ０１と、「サービスＭＡ２（処理Ｐ２(Ａ)）」
３２−Ａ０２とが稼動し、その一方、割り当て可能なリ
ソース総量が比較的大きな端末装置「Ｂ」（たとえば、
パーソナルコンピュータ（ＰＣ））１０００−２におい
て、あるアプリケーションの要求に応答して、「サービ
スＭＡ３（処理Ｐ３(Ｂ)）」３２−Ｂ０１が稼動してい
る。このような状態で、「サービスＭＡ１」３２−Ａ０
１が、他の端末装置に移動することを考える。

【００４９】この場合に、対象となるサービスＭＡの処
理時間が移動前よりも短縮され、かつ移動前のノード
（端末装置）で最も時間がかかっていたサービスＭＡの
処理時間よりも，移動後のノード（端末装置）で最も時
間がかかるサービスＭＡの処理時間が短くなるように、
サービスＭＡの移動制御は実行される。たとえば、図１
１（ａ）に示すように、移動前の端末装置「Ａ」におい
ては、「サービスＭＡ１」および「サービスＭＡ２」に
関して、グラフ１１００に示すように、処理時間が予想
される。その一方、移動前の端末装置「Ｂ」において
は、「サービスＭＡ３」に関して、グラフ１１０１に示
すように、処理時間が予想される。これに対して、「サ
ービスＭＡ１」を、端末装置「Ａ」から端末装置「Ｂ」
に移動させた場合には、端末装置「Ａ」および端末装置
「Ｂ」に関して、それぞれ、グラフ１１１０、１１１１
に示すように処理時間が予想される。

【００５０】図１１の処理時間の予想においては、移動
前のノード（端末装置「Ａ」）で最も時間がかかる「サ
ービスＭＡ１」の処理時間よりも、移動後のノード
（「端末装置「Ｂ」」で最も時間のかかる「サービスＭ
Ａ１」の処理時間より短くなっている。したがって、こ
こでは、「サービスＭＡ１」が端末装置「Ｂ」に移動す
べきと判断される。

【００５１】より具体的な評価式を以下に説明する。一
般に、移動の対象となるサービスＭＡの評価式ｆ_ｎ（ｎ
はノードを表す添え字）は、次式で定義される。 ｆ_ｎ＝サービスＭＡの処理時間 ＋サービスＭＡのデータ通信時間 ＋サービスＭＡの移動時間 ・・・（１）

【００５２】今，ノードＡにおけるｉ番目のサービスＭ
Ａ_ｉが、ノードＢに移動することを想定する。ＭＡ
_ｉが、ノードＢに移動すれば、その分、ノードＡのリソ
ースに余裕ができるため、移動元のノードＡにおけるｊ
番目のＭＡ_ｊへのリソース割当量は、ｒ_ｊからｒ_ｊ’
（ｒ_ｊ＜ｒ_ｊ’）に増大する。移動元のノードＡにおけ
るＭＡ_ｊが移動する前に、最も時間のかかるＭＡの処理
時間は次式で定義される。 ｍａｘ｛ｆ_Ａ（ｊ，ｒ_ｊ）｝＝サービスＭＡ_ｊの処理時間 ＋サービスＭＡ_ｊのデータ通信時間 （ただし、ｊはノードＡ内のＭＡ） ・・・（２） その一方、ノードＭにおいては、ＭＡ_ｉが移動してくる
ことから、その分リソースが利用され、ノードＢにおけ
る他のＭＡ_ｊのリソース割当量が、ｒ_ｊからｒ _ｊ’（ｒ
_ｊ＞ｒ_ｊ’）に減少することになる。

【００５３】このことを考慮した場合に、移動先のノー
ドＢにおいて最も時間のかかるＭＡの処理時間を表す式
は、次式で定義される。 ｍａｘ｛ｆ_Ｂ（ｊ，ｒ_ｊ’）｝＝サービスＭＡ_ｊの処理時間 ＋サービスＭＡ_ｊのデータ通信時間 ＋（サービスＭＡ_ｊの移動時間（ｊ＝ｉ） または０（ｊ≠ｉ）） ・・・（３）

【００５４】ただし、式（３）右辺の第３項目は、ノー
ドＡから移動してきたＭＡ_ｉに対してのみ有効となる。
移動先を決定する際には、ノードＢと同様に、ノード
Ｃ、Ｄ、・・・についても評価式を計算し、式（２）≧
（３）などの制約条件を満足するノードのうち、評価式
（１）が最小となるノードを選択する。このような評価
式を用いて移動先を決定することにより、サービスＭＡ
の最大応答時間を悪化させるようなサービスＭＡの移動
を防止することができる。

【００５５】コーディネータ３０−１において、上記評
価式および制約条件にしたがって、移動するのに最も望
ましい端末装置が判定されると、マネージャ２８−１を
介して、サービスＭＡ３２−Ａ１に対して、他の端末装
置（たとえば、端末装置「Ｂ」１０−２）に移動するよ
う、移動要求を与える（ステップ８０２、８０３）。な
お、ステップ８０１において、自己の端末装置「Ａ」１
０−１にて実行するのが最も望ましいと判断される場合
には、以下の処理は実行されない。サービスＭＡ３２−
Ａ１は、モバイルエージェント実行環境２６を利用し
て、指定された端末に、自ら移動する（ステップ８０
４）。これにより、移動先の端末装置「Ｂ」１０−２に
おいて、サービスＭＡ３２−Ａ１は、定められた処理を
実行する。これ以降の処理は、図５（ｂ）の処理フロー
に従う。

【００５６】また、コーディネータは、調査要求を送信
した他の端末装置の全てに、判定結果を送信する（ステ
ップ８０６）。これにより、端末装置「Ｂ」１０−２に
サービスＭＡを移動したことが、端末装置「Ｂ」１０−
２を含む他の端末に通知される（ステップ８０６、８０
７）。同様に、自己のマネージャ２８−１にもその旨が
通知される（ステップ８０８）。移動先を通知されるこ
とにより、マネージャ２８−１は、移動したサービスＭ
Ａ３２−Ａ１の位置を管理することができる。

【００５７】本実施の形態によれば、サービスＭＡが定
められた処理を実行する際など必要なときに、移動ポリ
シにしたがって、処理の実行に望ましい環境を備えた他
の端末装置に移動することができる。ミドルウェア中の
サービスＭＡが移動するため、端末装置のユーザはアプ
リケーションを利用しつづけることができる。また、リ
ソースマネージャからの調査結果回答に基づき、他の端
末装置を選択するため、適切な他の端末装置にサービス
ＭＡを移動することが可能となる。

【００５８】また、本実施の形態によれば、リソースマ
ネージャが、端末装置内のリソースを管理し、各サービ
スＭＡに対するリソースの割当量を動的に決定してい
る。また、コーディネータは、この割当量にしたがっ
て、他の端末装置からサービスＭＡを受け入れた場合の
影響や、他の端末装置にサービスＭＡを移動させた場合
の影響を、所定の評価式にしたがって算出し、サービス
ＭＡを移動させるか否か、また、移動させるのであれば
どの端末装置に移動すべきかが判断される。したがっ
て、最適な移動先にサービスＭＡを移動させ、より効率
的にＭＡを動作させることができる。また、他のＭＡへ
の影響を考慮することにより、システム全体として、効
率的に各ＭＡを動作させることが可能となる。

【００５９】このような仕組みがない場合には、移動の
対象となるＭＡ以外のＭＡの処理時間を大幅に悪化させ
ることが起こりうる。本実施の形態の手法を導入するこ
とにより、ＭＡ移動に伴うリソース再配分の影響を考慮
したＭＡの移動を実現することが可能となる。

【００６０】次に、ネットワーク上にリソースに余裕が
あるノード（端末装置）が存在した場合に、その状態を
トリガとした移動制御につき説明を加える。図１２は、
このような移動制御の概略を示すブロックダイヤグラム
である。図１２において、端末装置「Ａ」１２００−１
において、リソースマネージャ（図示せず）は、ノード
内のリソースの余裕度（たとえば、以下に説明する余裕
率や余裕量）を表す値が、ノード内にてあらかじめ設定
された閾値を超えた場合に、他ノードのＭＡを受け入れ
可能な状態と判断し、コーディネータ１２３０−１に交
渉開始を要求する。これに応答して、コーディネータ１
２３０−１は、他のノード（図１２においては、端末装
置「Ｂ」〜端末装置「Ｄ」）にこれを通知する（矢印１
２０１−１〜１２０１−３参照）。なお、全リソース量
をＲ_Ｔ、各Ｍ_Ａが最小限必要とするリソース量の総和を
Ｒａとすると、リソース余裕率＝１−Ｒ_ａ／Ｒ_Ｔ、リソ
ース余裕量＝Ｒ_Ｔ−Ｒ_ａと表すことができる。

【００６１】通知を受理した他のノードにおいて、コー
ディネータ１２３０−２〜１２３０−４は、それぞれ、
通知に含まれる余裕度を表す値と、自ノード内の余裕度
を表す値とを比較し（矢印１２０２−１〜１２０２の３
参照）、通知された値がより大きい場合には、自ノード
内の適切なＭＡについて、ノード１２００−１のコーデ
ィネータと交渉を開始する（矢印１２０３参照）。移動
するか否かを決定するために必要な情報は、交渉中に収
集されるので、通知を行なう際には、ノードに関する情
報に高い精度を必要としない。

【００６２】以下、図１３のフローチャートを参照し
て、より詳細に説明を加える。ある端末装置（図１３に
おいては、端末装置「Ｂ」）のリソースマネージャは、
所定のタイミングで、端末装置「Ｂ」におけるリソース
の余裕度を表す値を調べ、これが所定の閾値を超えた場
合に、コーディネータ３０−２に交渉開始要求を与える
（ステップ１３０１）。コーディネータ３０−２は、通
信可能な状態となっている他の端末装置の各々に、交渉
開始要求を送信する（ステップ１３０２）。なお、図１
３においては、交渉開始要求が、端末装置「Ａ」にのみ
送られているが、実際には、他の端末装置に対しても、
交渉開始要求はマルチキャストにより伝達されている。

【００６３】交渉開始要求を受理した他の端末装置（図
１３においては、端末装置「Ａ」）のコーディネータ３
０−１は、自己の端末装置の余裕度を表す値と、交渉開
始要求に含まれる余裕度を表す値とを比較し（ステップ
１３０３）、通知された値、つまり、交渉開始要求に含
まれる値がより大きい場合には、端末装置「Ｂ」のコー
ディネータ３０−２に対して、調査要求を伝達する（ス
テップ１３１１）。この調査要求は、端末装置「Ｂ」の
リソースマネージャ３６−２に伝達される。その一方、
端末装置「Ａ」のコーディネータ３０−１は、自身の端
末装置のリソースマネージャ３６−１に対しても、調査
要求を伝達する（ステップ１３１３）。以下、図７のス
テップ７０４〜７０８にそれぞれ対応する処理（ステッ
プ１３１４〜１３１８）が実行される。つまり、余裕度
を表す値により、交渉開始要求を受理した端末装置（図
１３では、端末装置「Ａ」）が、交渉すべきと判断する
と、当該端末装置と、先の交渉開始要求を発した端末装
置（図１３では、端末装置「Ｂ」）との間で、端末装置
「Ａ」中のいずれかのサービスＭＡを移動すべきか否か
の決定を含む処理が開始される。次いで、図８に示すよ
うな処理が実行され、所定の場合には、サービスＭＡ
が、交渉開始要求を発した端末装置（端末装置「Ｂ」）
に移動し、そこで処理を実行する。

【００６４】なお、調査要求を伝達する（ステップ１３
１１）のに先立って、コーディネータ３０−１が、稼動
中のサービスＭＡの何れを移動させるのが、最も望まし
いかを、たとえば、先に述べた評価式を算出することで
決定しておくのが望ましい。これにより、調査要求にお
いて、決定されたサービスＭＡに関する情報を、端末装
置「Ｂ」に伝達することが可能となる。上述した仕組み
がない場合には、自ノードよりも大きなリソース量を割
り当てることが可能なノードがネットワーク上に存在し
ても、自ノードの環境が所定の移動条件より悪化するま
で交渉開始が要求されない。その結果、リソースに余裕
のあるノードを見出すことができない。これに対して、
本実施の形態によれば、リソースに余裕のあるノード
が、それを他のノードに通知することができ、他のノー
ドはリソースに余裕のあるノードに対して交渉を開始す
ることができる。

【００６５】このように、本実施の形態によれば、リソ
ースマネージャを利用したリソース管理および他のノー
ドへの影響を考慮したＭＡの移動、並びに、リソースに
余裕のあるノードからの通知などにより、ＭＡは各ノー
ドのリソースをより柔軟に利用することができ、アプリ
ケーションの効率的な処理を実現できる。本発明は、以
上の実施の形態に限定されることなく、特許請求の範囲
に記載された発明の範囲内で、種々の変更が可能であ
り、それらも本発明の範囲内に包含されるものであるこ
とは言うまでもない。

【００６６】たとえば、前記実施の形態においては、移
動の是非を判断するために、サービスＭＡの処理時間、
データ通信時間、および、場合によってサービスＭＡの
移動時間が利用されているが、これに加えて、他の条
件、たとえば、バッテリー残量などが考慮されても良
い。

【００６７】

【発明の効果】本発明によれば、各端末装置のリソース
をより柔軟に利用でき、また、各端末装置においてアプ
リケーションの効率的な処理を実現できるシステムを提
供することが可能となる。

【図面の簡単な説明】

【図１】 図１は、本実施の形態にかかる端末装置の構
成を示すブロックダイヤグラムである。

【図２】 図２は、複数の端末装置の間におけるデータ
授受の概略を示す図である。

【図３】 図３は、本実施の形態にかかるサービスＭＡ
および監視ＭＡの構成とデータ授受の概略とを示す図で
ある。

【図４】 図４は、本実施の形態にかかるコーディネー
タをより詳細に示す図である。

【図５】 図５は、本実施の形態にかかる端末装置間の
サービスＭＡの移動に関する処理を示すフローチャート
である。

【図６】 図６は、本実施の形態にかかる端末装置間の
サービスＭＡの移動に関する処理を示すフローチャート
である。

【図７】 図７は、本実施の形態にかかる端末装置間の
サービスＭＡの移動に関する処理を示すフローチャート
である。

【図８】 図８は、本実施の形態にかかる端末装置間の
サービスＭＡの移動に関する処理を示すフローチャート
である。

【図９】 図９は、本実施の形態において、サービスＭ
Ａの処理に割り当てるリソースを説明する図である。

【図１０】 図１０は、本実施の形態において、複数の
端末装置において稼動しているＭＡを概略的に示す図で
ある。

【図１１】 図１１は、本実施の形態にかかる処理時間
の評価を説明するためのグラフである。

【図１２】 図１２は、本実施の形態において、リソー
スに余裕のある端末装置へのサービスＭＡの移動に際し
て実行される処理を概略的に示す図である。

【図１３】 図１３は、本実施の形態にかかる端末装置
間のサービスＭＡの移動に関する他の処理を示すフロー
チャートである。

【符号の説明】

１０ 端末装置 １８ ミドルウェア ２２ エージェント管理部 ２３ サービスＭＡ群 ２４ 監視ＭＡ群 ２６ モバイルエージェント実行環境 ２８ マネージャ ３０ コーディネータ ３２ サービスＭＡ ３４ 監視ＭＡ ３６ リソースマネージャ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 岡宅 泰邦 東京都中央区八丁堀四丁目７番１号 日本 テレコム株式会社内 Ｆターム(参考） 5B045 BB42 GG04 GG15 5B085 AA01 AA04 AC03 BG02 BG07 CA02 CA04

Claims (13)

【特許請求の範囲】
1. 【請求項１】 端末装置で、アプリケーションの依頼に
   応答して、ミドルウェア中の種々の移動可能なエージェ
   ントである１以上のサービスモバイルエージェント（サ
   ービスＭＡ）を稼動して、当該アプリケーションの機能
   を実現する情報処理方法において、 あるサービスＭＡの移動ポリシに基づき、当該サービス
   ＭＡを移動させるための条件が満たされる場合に、コー
   ディネータにおいて、エリアポリシにしたがって、通信
   可能な他の端末装置に対して、調査を要求し、当該他の
   端末装置のコーディネータに、当該他の端末装置におい
   て、サービスＭＡが移動することに伴う影響度を調査さ
   せるとともに、前記自己の端末装置において、サービス
   ＭＡが移動することに伴う影響度を調査するステップ
   と、 前記他の端末装置からの調査結果および自己の調査結果
   を受理し、前記サービスＭＡの移動に伴う影響度を考慮
   して、サービスＭＡを動作させるのに適した端末装置を
   選択するステップと、 前記サービスＭＡに対して、選択された端末装置が他の
   端末装置である場合に、当該他の端末装置への移動を要
   求するステップと、 前記サービスＭＡにおいて、移動要求に応答し、前記選
   択された他の端末装置に移動して、処理を実行するステ
   ップとを備えたことを特徴とする情報処理方法。
2. 【請求項２】 さらに、リソースマネージャにおいて、
   端末装置において動作するサービスＭＡに与えるべきリ
   ソースの割当量を、サービスＭＡの数および各サービス
   ＭＡの属性にしたがって動的に決定するステップを備
   え、 前記調査するステップが、 前記コーディネータにおいて、前記リソースマネージャ
   に対して、前記サービスＭＡの移動後の各サービスＭＡ
   への新たなリソースの割当量の算出を要求するステップ
   と、 前記新たなリソースの割当量に基づき、前記影響度を表
   す値を算出するステップとを有することを特徴とする請
   求項１に記載の方法。
3. 【請求項３】 前記影響度を表す値を算出するステップ
   が、 各サービスＭＡにおける処理時間の予想値を算出するス
   テップを含み、 前記サービスＭＡを動作させるのに適した端末装置を選
   択するステップが、 前記移動前後の各サービスＭＡの処理に関する予想値の
   最大値に基づき、端末装置を選択するステップを有する
   ことを特徴とする請求項２に記載の方法。
4. 【請求項４】 前記端末装置を選択するステップが、 サービスＭＡの移動元となる端末装置における最大値
   が、サービスＭＡの移動先の候補となる端末装置におけ
   る最大値以上である場合に、当該候補となる端末装置
   を、サービスＭＡを動作させるのに適した端末装置と決
   定するステップを含むことを特徴とする請求項３に記載
   の方法。
5. 【請求項５】 さらに、予想値を算出するステップが、
   サービスＭＡにおけるデータ通信時間および／またはサ
   ービスＭＡの移動時間を考慮して、値を算出することを
   特徴とする請求項３または４に記載の方法。
6. 【請求項６】 前記端末装置における予想値を算出する
   ステップが、 前記端末装置におけるｉ番目のサービスＭＡ_ｉが他の端
   末装置に移動する可能性がある場合に、 ｍａｘ｛ｆ（ｊ，ｒ_ｊ）｝＝サービスＭＡ_ｊの処理時間
   ＋サービスＭＡ_ｊのデータ通信時間 （ただし、ｊは、ｊ番目のサービスＭＡ、ｒはサービス
   ＭＡ_ｉが移動する前のリソース割当量を示す）を、サー
   ビスＭＡの移動前の予想値として算出するステップと、 ｍａｘ｛ｆ（ｊ，ｒ_ｊ’）｝＝サービスＭＡ_ｊの処理時
   間＋サービスＭＡ_ｊのデータ通信時間＋（サービスＭＡ
   _ｊの移動時間（ｊ＝ｉの場合）または０（ｊ≠ｉ）の場
   合） （ただし、ｊは、ｊ番目のサービスＭＡ、ｒ’はサービ
   スＭＡ_ｉが移動した後のリソース割当量を示す）を、サ
   ービスＭＡの移動後の予想値として算出するステップと
   を有することを特徴とする請求項５に記載の方法。
7. 【請求項７】 さらに、サービスＭＡにおいて、モバイ
   ルエージェント間およびアプリケーションとの間に介在
   するマネージャを介して、定められた監視項目の調査を
   実行する１以上の監視モバイルエージェント（監視Ｍ
   Ａ）に、当該監視項目の調査を依頼するステップと、 前記サービスＭＡにおいて、所定の移動ポリシをコーデ
   ィネータに登録するステップと、 前記コーディネータにおいて、前記監視ＭＡからの通知
   を受理して、端末装置間における交渉を開始するステッ
   プとを備え、 前記交渉の中で、前記移動ポリシを参照して、前記サー
   ビスＭＡの移動先を決定することを特徴とする請求項１
   ないし６の何れか一項に記載の方法。
8. 【請求項８】 アプリケーションの依頼に応答して、ミ
   ドルウェア中の種々の移動可能なエージェントである１
   以上のサービスモバイルエージェント（サービスＭＡ）
   を動作させて、当該アプリケーションの機能を実現する
   情報処理方法において、 リソースマネージャにおいて、端末装置において動作す
   るサービスＭＡに与えるべきリソースの割当量を管理す
   るステップと、 前記リソースマネージャにおいて、リソースの余裕度を
   表す値を算出するステップと、 前記余裕度を表す値が所定の閾値を超えた場合に、コー
   ディネータに、他の端末装置への交渉開始を要求するス
   テップと、 前記コーディネータにおいて、エリアポリシにしたがっ
   て、通信可能な他の端末装置に対して、その余裕度を表
   す値を調査させて、他の端末装置におけるサービスＭＡ
   を移動させるための交渉を促すステップと、 前記他の端末装置のコーディネータにおいて、サービス
   ＭＡの移動の是非を判断するステップと、 サービスＭＡを移動すべき場合に、当該他の端末装置で
   稼動中の所定のサービスＭＡに対して、前記端末装置へ
   の移動を要求するステップと、 前記サービスＭＡにおいて、移動要求に応答し、前記端
   末装置に移動して、処理を実行するステップとを備えた
   ことを特徴とする情報処理方法。
9. 【請求項９】 さらに、リソースマネージャにおいて、
   端末装置において動作するサービスＭＡに与えるべきリ
   ソースの割当量を、サービスＭＡの数および各サービス
   ＭＡの属性にしたがって動的に決定するステップを備え
   たことを特徴とする請求項８に記載の方法。
10. 【請求項１０】 前記余裕度を表す値を算出するステッ
    プが、 （１−Ｒ_ａ／Ｒ_Ｔ）で表されるリソース余裕率（ここ
    に、Ｒ_Ｔは、全リソース量、Ｒ_ａは、端末装置で稼動す
    る各サービスＭＡが最小限必要とするリソース量の総
    和）を算出するステップを有することを特徴とする請求
    項８または９に記載の方法。
11. 【請求項１１】 前記余裕度を表す値を算出するステッ
    プが、 （Ｒ_Ｔ−Ｒ_ａ）で表されるリソース余裕量（ここに、Ｒ
    _Ｔは、全リソース量、Ｒ_ａは、端末装置で稼動する各サ
    ービスＭＡが最小限必要とするリソース量の総和）を算
    出するステップを有することを特徴とする請求項８また
    は９に記載の方法。
12. 【請求項１２】 前記移動の是非を判断するステップ
    が、 前記他の端末装置において、自己の余裕度を示す値よ
    り、前記端末装置に関する余裕度を示す値が大きい場合
    に、前記移動のための交渉を開始するステップを有する
    ことを特徴とする請求項８ないし１１の何れか一項に記
    載の方法。
13. 【請求項１３】 さらに、前記交渉の開始に引き続い
    て、 前記他の端末装置のコーディネータにおいて、前記端末
    装置に対して、調査を要求し、当該端末装置のコーディ
    ネータに、当該端末装置において、前記他の端末装置で
    稼動している所定のサービスＭＡが移動することに伴う
    影響度を調査させるとともに、前記自己の端末装置にお
    いて、サービスＭＡが移動することに伴う影響度を調査
    するステップと、 前記端末装置からの調査結果および自己の調査結果を受
    理し、前記サービスＭＡの移動に伴う影響度を考慮し
    て、サービスＭＡを移動させるべきか否かを判断するス
    テップを備えたことを特徴とする請求項１２に記載の方
    法。