1. 背景

近年，携帯電話をはじめ無線LANなど無線技術の進展が目覚しい．W-CDMA，CDMA2000，IEEE802.11aなど広帯域無線ネットワーク技術の開発によって，人と人のコミュニケーション手段は音声通話，電子メールだけでなく映像のやりとりも可能なった．加えて，Bluetooth技術によって人が所有する機器同士を無線ネットワークで接続し，複数の機器を同時に操作することも可能である．こうした無線技術の発達は，移動しながらでも作業を行えるモバイルコンピューティング環境を実現しつつある．また，オフィス，家庭，公共空間などあらゆる環境でインターネット接続可能な機器が設置され，ネットワークを介して制御できるようになってきた．こうした環境の出現によって，人々は屋外から家の機器を操作するだけでなく，周囲に存在する機器を組み合わせて作業を行うことも可能になった．さらに，センサがネットワークに接続され，センサ同士がネットワークを構成する研究が行われている．無線通信の機能を持ったセンサが動的にネットワークを構成し，各センサが取得するデータを収集するセンサネットワークである．将来的にはセンサからのデータをもとにネットワークに接続された機器が自身の動作を変更できるような環境が出てくるだろう．このように今後，移動しながら人と人，人と機器，機器と機器がネットワークを介して協調作業を行うことは重要なことになっていくと考えられる．

2. 目的

本研究では，ユビキタス環境下での人やアプリケーションの移動，機器の動作変更に着目し，移動に伴う環境の変化を動的に発生させて協調作業を行いやすい環境にし，また移動によって生じる様々な障害に対し動的に適応して継続的な協調作業を行うための支援基盤環境である”Mobiquitous Environment”(MobiquitousはMobileとUbiquitousからの造語)を確立する．その際，新たなデバイスを作成するのではなく，既存のデバイスを利用し，その上で動作するソフトウェアによって適した機器を利用するよう動的に適応可能なサービスローミング技術を実現していく．我々が目指すMobiquitous Environmentの概念図を図1に示す．

将来，自宅や会社，学校や公共施設ではホームネットワークや情報キオスクなどが普及し，様々なユビキタス環境間を利用できると考えられる．人は利用できるユビキタス環境間を移動する．その際重要となるのは，移動しながらでもユビキタス環境を利用して利用者の要求をそこにある機器を処理するである．更にインターネットカーやセンサネットワークなどのように機器もユビキタス環境間を移動することが考えられる．その際，利用者・機器・アプリケーションが移動しながら人と人，人と機器，機器と機器の協調作業(Human/Device Interaction)を円滑に行えるよう支援する新たなユビキタス環境を構築する．Mobiquitous Environmentでは，利用者が携帯の容易なウェアラブルコンピュータやPDA(これらをMobile Client Host，簡単にクライアントと呼ぶ)を常に所有し，そのクライアントが中心となり，周辺にある情報家電やセンサ，ネットワーク上のコンテンツやサーバ(これらをUbiquitous Service Provider，簡単にサービスプロバイダと呼ぶ)などを利用し，人と機器との協調作業をおこなっていく．このMobiquitous Environmentを構築するにあたり，本研究では2つの目的を挙げる．

移動

図 1　Mobiquitous Environment 概要

l 人の移動によるマイナスな変化への動的適応

第一にMobiquitous Environmentでは，人や機器の移動により引き起こされるマイナスな変化に人や機器が動的に適応し，円滑な人や機器との協調作業を継続して行うことを実現する．ユビキタス環境における人や機器の移動は様々な変化を生じる．それまで利用できていた機器が利用できなくなったり，接続するネットワークが切れたりする．その結果，人や機器の間で行われていた協調作業に障害が発生する．そこで,人や機器の移動によって変化するサービスプロバイダの利用状況の変化に伴い，利用するサービスプロバイダとの通信方法を動的に変え，ユーザの要求を継続的に処理することが重要となる.たとえば，利用者がある部屋で近傍にあるスピーカを利用して音楽を聴いていた．その利用者が部屋から出て別の部屋へ移動したとする．すると，さっきまで利用していたスピーカから音楽が流れていても意味がない．Mobiquitous Environmentでは利用者の移動によって利用する機器や通信方法を動的に変更できる．それにより，移動した先にある別のスピーカを利用して音楽を継続して聴ける．

l 人の移動によるプラスな変化への動的適応

第二にMobiquitous Environmentでは，人の移動や機器の動作の変化を動的に発生させることで，人の要求をより高いレベルで実現できる環境を構築する．これらの変化は上記のようなマイナスの変化を引き起こすだけとは限らない．人の位置や機器の動作が動的に変化ことで，今まで利用できなかった機器が利用できるようになる．また，より効率よく人の要求を実行できる状況を作り出すこともできる．その結果，人や機器の間で行われていた協調作業がより効率よく行われる．たとえば，利用者が現在いる場所で利用可能なサービスプロバイダが存在しない場合を考える．その場合，その場から一番近くに存在するサービスプロバイダを利用者は見つけ出し，発見されたサービスプロバイダが存在する場所へ移動することが可能となる．また，その場に新たなサービスプロバイダが物理的に移動してくると，利用者は移動せずともそのサービスプロバイダを用いて作業を行うことが可能となる．

Mobiquitous Environmentでは，人や機器，アプリケーションが移動しながら，人と人，人と機器，機器と機器の協調作業を円滑に行え，協調作業が円滑に行えなくなったら，積極的に人や機器が移動して円滑に行える．このような環境を既存の機器を用いて動的適応，動的変化などの新たなソフトウェア技術を構築することによって実現していく．

3. 研究内容

本研究は2つのタスクに分かれて行われた．そのうちの1つでは本研究の成果を利用した 3つの応用アプリケーションを作成した．

3.1. タスク1：サービス利用基盤ソフトウェア

本タスクでは，利用者やサービスプロバイダの物理的移動に応じて，その場で利用できる適切なサービスを動的に選択できるよう支援する ASAMA (Adaptive Service Availability Management) とそのサブシステムである ASDS (Adaptive Service Disconnect/Reconnect Support) について述べる．本ソフトウェアはクライアントとサービスプロバイダに対するミドルウェアと，サービスプロバイダのサービス利用可能状況を管理するディレクトリサーバから構成される．

3.1.1. 設計

本タスクでは，以下の目標を実現する．

l 利用者の移動によって生じるサービス利用状況の変化(能動的変化)を検知できる

l サービスの移動やサービス提供の開始，終了などによるサービス利用状況の変化(受動的変化)を検知できる

l ネットワーク障害や負荷上昇によるサービスプロバイダ利用不可能状況の検知

l プログラミング言語非依存なシステムを構築する

l ネットワーク切断・接続時のサービス中断・再開処理の支援

この4つの目標を実現するにあたり，4つの機能を提供できるよう，設計した．以下で4つの機能についてそれぞれ述べていく．

l 能動的変化の検知方法

クライアントが利用するサービスプロバイダには，ユーザから物理的に近くに存在しなければ意味がないものが多い．ディスプレイやスピーカなど，多くのデバイスがこれに該当する．利用者が移動すると，利用できるサービスプロバイダが地価好き，また離れる場合がある．たとえば，ディスプレイを利用しているユーザが移動して100mはなれた場合，クライアントがディスプレイに映像を表示できても，利用者はその映像をその場から見られない．

そこで，クライアントが能動的環境変化により，利用可能なサービスプロバイダが変化したことを検知するために，クライアントは自身の物理的移動を検知し，サービスプロバイダの物理的位置を把握しながら，利用するサービスプロバイダを選択することが必要となる．

クライアントの位置を検知する方法として，GPSなどのセンサを利用することが考えられる．位置情報を取得できるセンサは用途や方法が異なる多くの種類のものが存在し，利用できる範囲や場所もそれぞれ一長一短である．

そこで， ASAMAは独自の木構造を用いた位置情報記述スキーマを用意する．センサから取得できたデータをASAMAの位置情報記述スキーマにしたがって変換し，センサデータの差異を吸収する．センサごとにセンサを制御するためのデバイスモジュールを用意し，センサデータをASAMAが定義する位置情報記述スキーマに変換して，Location Managerに通知する．Location Manager は複数のデバイスモジュールからの位置情報を管理し，利用者の位置情報が変化したら，それをアプリケーションに通知する．アプリケーションはその通知を受信することで，能動的変化を検知し，適応するための処理を実行できる．

l 受動的変化の検知方法

将来的に多くの家電機器がネットワークに接続されることを考慮すると，利用できるサービスが出現・消滅することが多く発生する可能性が高い．多くの家電機器は用意に電源をon/offできるため，その利用可能状況は変化しやすい．また，ポータブルMP3プレイヤやPDAなどの小型なデバイスは用意に環境間を移動できる．

受動的変化はクライアント以外の要因によって引き起こされる変化である．そのため，サービスプロバイダの利用可能性を表す「登録ステート」を管理するディレクトリサーバと協調して変化を検知する必要がある．サービスプロバイダがディレクトリサービスに登録要求，または登録削除要求を行い，登録ステートが変化すると，ディレクトリサーバはその環境にいるクライアントにサービス利用状況の変化が生じたことを通知し，クライアントはその変化を検知できる．

その際，ディレクトリサーバは変化が生じたことを通知するために，現在，どのクライアントが自分の管理する環境の中に存在するかを把握しなければならない．そこで，クライアントはディレクトリサーバにサービスプロバイダの検索を行う際，以下のものを送信する．

Ø クライアントが利用したいサービスプロバイダを検索するためのフィルタ

Ø ディレクトリサーバからの受動的変化通知を受信するポート番号

Ø クライアントがランダムに生成したID番号

ディレクトリサーバはクライアントからサービス検索要求を受けた際，フィルタとクライアントのIPアドレス，ポート番号，およびIDを「検索ステート」として保存し，変化が生じた際に，この検索ステートを用いて関係のあるクライアントにのみ通知を行う．これにより，クライアントとディレクトリサーバとのトラフィックや処理の負荷を軽減する．

通知を行った際，通知を正常に送れなかったクライアントの検索ステートをもとに，同じIPアドレスとIDを持つ検索ステートを削除する．これによりディレクトリサーバは古くなった検索ステートを必要以上に管理する必要がなくなり，負荷の軽減を実現できる．

l クライアントとディレクトリサーバの協調的サービスプロバイダ利用状況管理

サービスプロバイダがネットワーク障害や高負荷によるダウンにより，予測不能なサービス利用不可能状況に陥った場合，ディレクトリサーバのエントリは残ったままである．そこで，クライアントとディレクトリサーバが協調的に予測不可能な理由によってサービス利用不可能状況になったサービスプロバイダのエントリを削除することを実現する．

クライアントはディレクトリサービスに登録されているにもかかわらず利用不可能なサービスプロバイダを発見した場合，ディレクトリサーバにノーティフィケーションメッセージを送信する．それを受信したディレクトリサーバは該当するサービスプロバイダが本当に利用不可能なのか，確認するためにハローメッセージを送信する．サービスプロバイダはディレクトリサーバからはローメッセージを受信すると，応答メッセージを返すようになっており，本当に利用不可能な場合，応答メッセージが帰ってこない．もし，応答メッセージをディレクトリサーバが受信できないと，該当するサービスプロバイダが利用不可能になったと判断し，そのエントリを削除する．

l サービスの定義

クライアントがサポートするプログラミング言語はそのプラットフォームによって様々である．Jiniのような特定のプログラミング言語依存のサービス管理システムでは，PDAのような利用できるプログラミング言語の少ない環境では，その機能を利用できない．そのため，本システムは特定のプログラミング言語に依存しないようなサービス検索を実現する必要がある．

そこで，本システムは基本となるサービス管理システムとして，LDAPを採用し，これを拡張することで，本システムの機能を提供することとする．LDAPはそのプロトコルと登録できるエントリのフォーマットが決まっているだけで，特定の言語に依存していない．実際に様々な言語で実装されたライブラリが存在している．

ASAMAではLDAPに基づき，サービスのエントリをdeviceオブジェクトクラスによって記述する．ただし，deviceオブジェクトクラスで扱える属性が少ないこともあり，deviceオブジェクトクラス内のdescription属性の値にXMLを用いてサービスに関する詳しい情報を記述する．図3にASAMAにおけるサービスのエントリの例としてスピーカーサービスを示す．クライアントはLDAPに基づきサービスのエントリを取得し，description属性値に書かれたXMLをもとにより詳しいサービスの情報を取得することができる．

図 2　スピーカーサービスのエントリ例

l ネットワーク切断・接続の検知方法

クライアントは無線LANによるネットワーク接続がされていると考えられる．そのため，利用者の移動によってネットワーク接続が知らないうちに切断・再接続されることが生じる．通常，サービス利用中断を行う際，サービスプロバイダとクライアントの間のステートを一致させておき，利用再開する際にそのステートを利用して継続的な作業を実現することが考えられる．しかし，ネットワーク切断によるサービス利用中断の場合，ネットワークが切断された段階ではクライアントがサービスプロバイダと通信できないため，中断のための処理を行えない．

そこで，本システムでは，無線LANの電波強度(SN比)を利用し，ネットワークの切断・接続を予見・検知するこを実現する． SN比の値が小さくなると通信ができなくなり，大きくなると通信ができる．図4にSN比とネットワークスループットとの関係を示す．

図 3　SN比とスループットの関係

この図をもとにネットワーク切断の基本閾値を8，接続の基本閾値を16に定める．さらにSN比の閾値とともにSN比の変化にも着目する．SN比の変化をもとに，現在,利用者が無線LAN基地局から離れているのか，近づいているのか，それともとまっているのかを判断する．またSN比の直線回帰を計算し，将来ネットワーク切断が生じるかを予測する．ネットワークの切断・接続および切断予見を検知した場合，アプリケーションに通知し，必要な処理をアプリケーションが実行する．本機能はASDS (Adaptive Service Disconnected/Reconnect Support) と呼び，ASAMAのサブシステムとして動作する．

3.1.2. 実装

l システム概要

本システムはJ2SE 1.3.1とC言語を用いてOpenLDAPを拡張することで実装を行った．図5にシステム構成図を示す．

図 4　ASAMAシステムアーキテクチャ

クライアントのDSEntryモジュールはディレクトリサーバとの通信を管理し，サービスプロバイダの検索，アップデート，ノーティフィケーションメッセージの処理を行う．検索されたサービスプロバイダの情報は検索に利用されたクエリの種類ごとにServiceEntryオブジェクトとして管理される．ServiceAvailabilityManagerモジュールは能動的変化と受動的変化を監視し，変化が生じた場合，アプリケーションが用意する必要な処理を実行させる．ディレクトリサーバのSLAPDはその場所で利用可能なサービスプロバイダのエントリを管理しており，クライアントから検索要求がくると，検索ステートをMCHEntryとして保存する．サービスプロバイダのDSEntryモジュールもディレクトリサーバとの通信を管理し，自身の登録・削除を行う．

l 能動的変化の検知機構

能動的変化の検知に関して，クライアントのLocationManagerモジュールは利用可能な位置情報センサごとにDriverModuleを用意し，ASAMAが定義する位置情報記述スキーマに変換，管理する．もし，利用者の位置情報が変化した場合，その旨をServiceAvailabilityManagerモジュールに通知する．

l 受動的変化の検知機構

受動的変化の検知に関して，サービスプロバイダのDSEntryモジュールからディレクトリサーバのSLAPDへ登録要求もしくは削除要求が行われると，SLAPDはMCHEntryから関係のあるクライアントを検索する．該当するクライアントが発見されるとUpdateSenderモジュールを通じてクライアントのUpdateReceiverモジュールへ通知が行われる．通知をうけたUpdateReceiverはServiceAvailabilityManagerモジュールに通知を行い，能動的変化が生じたことを教える．

l 協調的サービスプロバイダ管理機構

クライアントがディレクトリサーバに登録されているにもかかわらず，利用不可能なサービスプロバイダを発見すると，NotificationSenderモジュールを通じてディレクトリサーバのNotificationReceiverモジュールへ通知を行う．通知をうけたディレクトリサーバはConfirmationSenderモジュールを通じてサービスプロバイダのConfirmationReceiverモジュールへハローメッセージを送信する．プロバイダはハローメッセージを受信すると，応答をディレクトリサーバに返し，自身が利用可能であることを証明する．もし，ディレクトリサーバは応答を受信できないと，該当するサービスプロバイダが利用不可能状況であると判断し，そのエントリを削除する．

l 無線LANによるネットワーク切断予見機構

クライアント派利用者の位置情報を取得するセンサとして無線LANを利用することも考えられる．そこで，無線LAN用のDeviceModuleでは位置情報を取得するだけでなく，ネットワーク切断予見・再接続検知を行えるようにした．このDeviceModuleが切断予見・再接続検知を行うと，アプリケーションが用意した切断事前処理，接続再開処理を実行させる．

3.1.3. テスト

本システムの動作確認を行うため，利用者が現在いる環境で利用可能なサービスプロバイダを表示するGUIを作成した．図6にそのGUIを示す．

図 5　サービスアベイラビリティマネージャ GUI

このGUI(左（１）)に表示されるサービスは基本的に利用者が現在いる環境で利用可能なサービスプロバイダである．GUIの一番下の部分に現在の位置情報がASAMAの位置情報記述スキーマにしたがって表示される．利用したいサービスプロバイダをGUIで選択すると，詳しい情報が一番下の部分に表示される．

利用者が移動すると，能動的変化が生じ，GUIに表示されるサービスプロバイダも変化することが確認され，能動的変化を検知し，アプリケーションが適応することを支援できる．

また，利用者が現在いる環境に新たなサービスプロバイダを追加，削除した場合，該当するエントリがGUIに追加・削除されるかを確認した．新たに追加される場合，図右（２）のように赤い文字で新たなサービスプロバイダが利用可能になったことを示し，ポップアップウィンドウが現れ，利用者にその旨を通知した．

3.1.4. 評価

本システムの定性評価として，本システムのサブシステムであるASDSを用いた応用アプリケーションでの比較を行った．本評価では，ASDSを利用し，サービス利用中断・再開が生じた場合のASDSの優位性を示す．ASDSを利用して利用中断中に事前処理を行った場合(ケース１)，クライアントとサービスプロバイダの間にステートが存在するケース(ケース2)，ステートが存在しない場合(ケース3)との比較を行う．

本評価では，クライアントは MP3 ストリーミングサービスから 128 Kbps で44.1 KHz の MP3 データを 128 Kbps のコンスタントビットレート (以下 CBRとする) で受信する．クライアントは 5 秒分のバッファリングを行い，(0)で示される時刻から受信した MP3 を再生する．その際，クライアントは一度，サービス利用可能な状況から不可能な状況になり，しばらくした後，再び利用可能な状況へ置かれる．図7に評価結果を示す．

まず，すべてのケースにおいて，最初からサービス利用可能な状況にある． (2) で示される時刻に向うにつれ，サービス利用不可能な状況に近づく．ケース 2 と 3 はサービス利用不可能な状況になるまで，同じ動作を行う．ケース1 だけは，サービス利用不可能な状況になることを (1) の時刻に予見し，CBRで受信していたストリーミングをベストエフォートで受信するように処理内容を変更し，できる限り，データをバッファリングする．

図 6　ASDSを用いたMP3プレイヤの切断実験

(2) の時刻になると，ケース 2 と 3 はデータを受信できなくなるため，(3)の時刻，つまりバッファリングした 5 秒分しか再生できない．ケース 1 はケース 2，3 と比べ，事前処理としてできる限りのデータをバッファリングしたため，データを受信しなくても，長時間，音楽を再生しつづけられる．

(4) の時刻になると，すべてのケースにおいて，サービスを利用できるようになる．ケース 3 は，サービスとクライアントとの間でステートが共有されていないため，再びデータの最初から受信を開始し，5 秒間のバッファリングを行い，(5) の時刻で音楽の先頭から再生を開始する．ケース 2 の場合，ステートの共有が行われているため，(2) の時刻までに受信したデータの続きを受信し，5 秒間のバッファリングの後，(3) の時刻までに再生した分の続きから再生を開始する．ケース 1 の場合，事前処理でバッファリングしたデータが基

本値の 5 秒よりも多いため，クライアントは再接続した時点である (5) の時刻では，まだデータを受信せず音楽の再生を行う．クライアントはバッファリングしたデータサイズからデータ受信の再開時刻を計算し，(6) の時刻になってようやくデータの受信を開始する．

このように，ASDS によって，サービスとクライアントとのステートの共有，およびサービス利用不可能な状況になることの予見を実現することは， Mobiquitous Environmentにおいて利用者に有益であることが示された．

3.2. タスク2：本製成果を用いた応用アプリケーション

本研究の成果であるミドルウェア群を用いた応用アプリケーションを作成し，実際のユビキタスコンピューティング環境で動作させ，ミドルウェア群のテスト，および有効性について示していく．

3.2.1. 応用アプリケーションの実験環境について

本研究の成果を用いた応用アプリケーションを実際のユビキタスコンピューティング環境である慶應義塾大学Smart Space Lab(以下SSLabと呼ぶ)を使って実装を行った．SSLabを仮想的に複数のユビキタスコンピューティング環境と見立て，その間を利用者やサービスプロバイダが移動する．図8にSSLabの俯瞰図を示す．

図8　SSLab俯瞰図

SSLabの壁・床・天井はすべて2重構造になっており，様々な機器を利用者から隠蔽して設置することが可能である．今回は壁の中にPCを設置し，利用者にはディスプレイしか見えないようになっている．また，スピーカなどは天井に設置されている．

利用者やサービスプロバイダの位置情報取得のためのセンサとして，Intersense社のIS-600を利用した．IS-600から取得できるセンサデータをサービス利用基盤ソフトウェアが定義する位置情報記述スキーマに変換し，利用者とサービスプロバイダの位置を管理する．

3.2.2. サービスローミング技術を用いたTV電話システム

サービスローミングの例として，今回はTV電話システムを実装した．利用者は移動しながら周辺に存在するサービスプロバイダを適宜利用し，同じ相手と映像と音声を利用した会話が可能になる．図9にサービスローミング技術を用いたTV電話システムの概要を示す．

図 9　サービスローミング技術を用いたTV電話システム

まず利用者はSSLab内に仮想的に作られたリージョン1にいる(�@)．そこでは周辺のサービスプロバイダが利用できないため，利用者が装備するiPAQ上のMoCAから起動されたモジュールを用いて音声による会話を行う．iPAQにはASAMAが提供するサービス管理のためのGUIが表示されてあり，それを利用して隣のリージョン2に利用可能なサービスプロバイダが存在することを知り，移動する(�A)．リージョン2に入ると，ディスプレイサービスとスピーカーサービスが利用できることがわかり，MoCAからそれらを利用して映像と音声を用いた会話を行う(�C)．再び，利用者はリージョン1に移動する(�D，�E)．そこに持ち可能なSmartFunitureがリージョン1に持ち込まれる(�F)．SmartFunitureにはディスプレイが接続されており， ASAMAのサービス管理GUIは新たなサービスプロバイダが利用可能になった旨を利用者に表示する．利用者はそれをもとにSmartFunitureに接続されたディスプレイを用いて相手と会話を行う．

図 10　SSLab内でのTV電話の様子

図10に実際のTV電話システムを利用している様子を示す．図10-(1)はリージョン1でiPAQを用いて会話をしている様子，図10-(2)はリージョン2でディスプレイサービスとスピーカーサービスを利用した様子，図10-(3)はリージョン1でSmartFunitureを利用した様子である．また，図10-(4)はリージョン2で利用者が利用するディスプレイがどのディスプレイなのかを確認するために，点灯されるLEDである．ASAMAのサービス管理GUIでサービスプロバイダのエントリを選択すると，該当するサービスプロバイダに設置されたLEDが光り，利用者が実際のサービスプロバイダがどれなのか確認できるようになっている．

3.2.3. 利用者の位置に応じた動的ポスターシステム

公共の場(以後，パブリックスペースと呼ぶ)におけるサービスプロバイダのモデルとして，利用者の位置に応じた動的ポスターシステムが考えられる．利用者がサービスプロバイダに近づいてくると，自動的に広告のためのポスターが表示され，利用者がサービスプロバイダを利用し，離れた場合，ポスター表示を終了する．

利用者がリージョン１からリージョン2に移ると，サービスプロバイダは自分が存在する空間に利用者が新たに入ってきたことを検知する．それによって動的にポスターを自身のディスプレイに表示させ，音楽をスピーカから流し始める．これにより，サービスプロバイダがその環境で利用可能であることを利用者にアピールできる．

利用者がサービスプロバイダを利用し始めると，表示されているポスターや音楽は利用者にとって邪魔であるため，ポスター処理を終了する．同様に，利用者がその空間から離れる場合も処理を終了する．

パブリックスペースでは，サービスプロバイダを設置するために，魅力的なモチベーションを提示し，設置を行う企業などに積極的にその利点を示す必要がある．この動的ポスターシステムは，そういった企業に対し，パブリックスペースにおける広告というモチベーションを与え，Mobiquiotus Environmentの普及のための糸口になると考えている．

4. 研究成果の特徴

研究成果の特徴として，以下の2つが挙げられる．

4.1. Mobiquitous Environmentの提案

本研究では，新たなユビキタスコンピューティング環境として，Mobiquitous Environment を提案し，サービスローミング技術によって利用者は移動しながら継続的なサービス利用を実現できるようになった．

これまでのユビキタスコンピューティング環境では，利用者がある場所に入って，その場にどのようなサービスがあるかわからない状態から，即興的にその場にあるサービスを用いて利用者の様々な要求を実行することが目的とされてきた．しかし，ホットスポットの普及や，研究機関におけるユビキタスコンピューティング環境同士の相互接続など近年の潮流を考えると，複数のユビキタス空間を利用者が渡り歩くことが考えられる．

本研究では，利用者が複数のユビキタスコンピューティング環境を移動しながら，継続的な作業を実現できるよう，Mobiquitous Environmentを提案した．Mobiquitous Environmentでは特殊な機器を用意することなく，すでに流通している機器を使用した．また，特定のプログラミング言語に依存しないように設計されているため，どのハードウェアにも移植することが比較的容易である．機器上で動作するアプリケーションを作成する際に，本研究が作成したミドルウェア群を利用することにより，利用者だけでなく，サービスやアプリケーションも移動し，3つの移動に適応しながら利用者に対して継続的な作業空間を提供できるようになった．

4.2. サービスローミングの実現

本研究はMobiquitous Environment の中心となる技術として，利用者やサービスなどの移動によって生じる変化に動的に適応し，適切なサービスを利用できるサービスローミング技術を実現した．

これまでのモバイルコンピューティング環境では，利用者が携帯する計算機のみが移動することを前提としていた．OSI7層モデルでいう，物理層からトランスポート層までの移動透過性を保証する研究は多い．しかし，移動によって変化するサービスの利用可能状況はアプリケーション層で解決する必要があると考えられる．また，Mobiquitous Environmentでの移動はサービスも移動することもあり，通信の両端それぞれが変化することが考えられる．

本研究では，サービス利用基盤ソフトウェアによって，利用者が移動した場合でも，それによって生じるサービスの利用可能状況の変化を検知し，利用者に対して適切なサービスプロバイダを選択できるよう，支援する．また，サービス再構築ソフトウェアによって，アプリケーションの一部をサービスへ容易に移動することが可能となり，簡単に利用するサービスを切り替えるよう，支援する．支援する．継続的サービス利用支援ミドルウェアによって，利用者のいる環境で使用できる既存技術を利用しながら，サービスプロバイダとクライアントとの通信の切り替えを支援する．これらのミドルウェアを利用することで，サービスローミングが行えるアプリケーションを容易に作成できるようになった．

5. 今後の課題・展望

今後の課題として，ユビキタスコンピューティング環境で重要となってくるセキュリティについて考えていく．今後の展望として，本研究の成果を学会や論文を通じて世界に発表していき，他の研究者からの意見などを取り入れつつ，より完成度の高いものを目指していく．なお，本研究で作成されたミドルウェア群はhttp://www.ht.sfc.keio.ac.jp/mobiquitous/およびCVSを用いてダウンロードし利用できるよう，近日中に準備を完成させる予定である．

6. その他

開発者がこれまでに発表した本研究の基礎になった論文，および本研究によって新たに発表された論文を以下に示す．

1. "適応的ディレクトリサービスのおけるステート管理方法" 永田 智大, 西尾 信彦, 徳田 英幸 情報処理学会コンピュータシステムシンポジウム 1999年11月 pp.57-64

2. "ウェアラブルネットワーク環境に適したアプリケーションフレームワーク" 村瀬正名, 永田智大, 西尾信彦, 徳田英幸 情報処理学会マルチメディア通信と分散処理研究会(DICOMO) Vol.2001(7) 2001年6月 pp.199-204

3. "ASAMA: 適応的なサービス利用管理機構" 永田 智大, 西尾 信彦, 徳田 英幸 情報処理学会論文誌 Vol.42(6) 2001年6月 pp.1557-1569

4. "サービス利用状況の変化に対する適応支援機構" 永田　智大, 西尾　信彦, 徳田　英幸 情報処理学会システムソフトウェアとオペレーティングシステム研究会 Vol.2002(60) 2002年6月 pp.1-8

5. "サービス利用状況の変化に対する適応支援機構" 永田 智大, 西尾 信彦, 徳田 英幸 情報処理学会論文誌 Vol.44(3) 2003年3月 採録決定

6. "Wearable Network: Architecture and an Implementation" Nobuhiko Nishio, Takeshi Iwamoto, Tomohiro Nagata, Hideyuki Tokuda IEEE International Workshop on Networked Appliances (IWNA'00) 2000 年

7. "ASAMA: Adaptive Service Availability Management" Tomohiro Nagata, Nobuhiko Nishio, Hideyuki Tokuda Proceedings of IEEE International Workshop on Networked Appliances (IWNA'01) 2001 年 3 月 p14--19

8. "Implementation and Evaluation of Wapplet Framework" Masana Murase, Takeshi Iwamoto, Tomohiro Nagata, Nobuhiko Nishio and Hideyuki Tokuda IEEE International Workshop on Networked Appliances (IWNA'02) 2002 年 1 月 p275--284