JP2006196014A - 異種デバイス間におけるアプリケーションのマイグレーション方法およびシステム - Google Patents

Abstract

【課題】異種デバイス間におけるアプリケーションのマイクグレーションを可能にする。
【解決手段】アプリケーションは、１以上のコンポーネントの複数セットから成る。ソースデバイス２において実行されるアプリケーションおよびターゲットデバイス３のハードウェア構成が検査されて、ターゲットデバイス３における実行に最も適したコンポーネントを、各セットから少なくともひとつ選択することにより、アプリケーションをターゲットデバイス３にポーティングする。ソースデバイス２にあるアプリケーションの実行状態が取得され、ターゲットデバイス３に送られる。ターゲットデバイス３は、アプリケーションの取得状態を使って、ポーティングされたアプリケーションをロードし、インスタンス化する。
【選択図】図２

Description

この発明は、異種デバイス間、または異なるハードウェア構成のデバイス間でアプリケーションをマイグレーションする方法およびシステムに関する。

マイグレーションとは、ひとつのデバイスにおいて実行中のアプリケーションがタスクを中断して別のデバイスにマイグレーションし、マイグレーション先のデバイスにおいてタスクを再開する際には最初のデバイスにおいて中止した時点で実行していたタスクを実行する処理のことをいう。この点でマイグレーションは、アプリケーションがひとつのデバイスから他のデバイスに移動し、移動先のデバイスにおいては最初のデバイスにおけるアプリケーションの状態に関係なく振り出しからタスクが実行される遠隔実行処理とは異なる。

モビリティ（可動性）へのニーズがコンピュータデバイスの進化の主たる駆動力であると言えるかもしれない。デスクトップ型のコンピュータは、ノートブック型のコンピュータに進化した。ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）やインテリジェント・ページャは、最近この進化ツリーの仲間入りをした新種である。今や、これらのコンピュータデバイスは、有線または無線ＬＡＮ、セルラ網、Ｂｌｕｅｔｏｏｔｈ（登録商標）、そしてＰＡＮ（Ｐｅｒｓｏｎａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ：パーソナル・エリア・ネットワーク）など、様々な通信ネットワークを介したデータ通信により互いに交信することが可能になった。

コンピュータデバイスの進化は、我々の生活に著しい影響を及ぼし、我々のビジネスや作業環境の変化をもたらしてきた。以前は、ＰＣは机に固定され移動できなかったため、必要なソフトウェアを備えたＰＣが設置してある場所でのみ作業をしたりデータを処理することができた。しかし近年では、移動可能であり、十分な機能を備えたコンピュータデバイス、例えば、ノートブック型コンピュータ、ＰＤＡ、セルラ電話などを簡単に利用することができる。これら移動デバイスのユーザは、デバイスの可動性を最大限に利用したいという欲求を持っている場合が多い。ユーザが遠隔地にいるときや移動中に、モバイルコンピュータを用いて仕事を続けられたら、どんなに効率よく、また成果を上げることができるだろうか。例えば、携帯電話かＰＤＡのユーザが、オフィスのデスクトップ型のコンピュータを使ってオンラインでビジネス旅行の計画をしていて、離れた場所でのミーティングに呼ばれて作業を中断しなければならないと仮定しよう。こんな場合、ユーザは、ミーティング場所への移動中の電車やバスの中や、ミーティングの合間に、携帯電話やＰＤＡを使ってビジネス旅行の計画を続けたいと思うかもしれない。

このようなニーズに応えるため、アプリケーションのマイグレーションという概念が開発された。つまり、この概念では、アプリケーションは、あるコンピュータデバイス（ソースデバイス）から別のコンピュータデバイス（ターゲットデバイス）にそのままの状態でマイグレーションする。マイグレーションは、(1)アプリケーションの画一性、(2)アプリケーションの実行の継続性という二つの技術的課題を提起している。

最初の課題は、コンピュータデバイス間のハードウェア構成の違いに起因している。確かに、コンピュータデバイスは、コンピュータ処理能力、メモリ容量、画面の大きさ、データ入力手段など、あらゆる面で多様である。このため、ハードウェア構成に応じた個別のアプリケーションがコンピュータデバイスごとにロードされているのが常であり、それでいて同じ処理を実行している。例えば、デスクトップ型のＰＣでは、「マイクロソフト（登録商標）Ｏｕｔｌｏｏｋ（登録商標）」、パーム型のＰＤＡでは、「メール」、スプリントＰＣＳ社のセル電話では、「ＰＣＳメール」を使っているとする。これらはすべて、異なるアプリケーションであるにも拘らず、同じ電子メール機能を実行する。電子メールの送信や受信だけのためにこれら異なるアプリケーションすべての使い方を学ぶ必要が本当にあるのかとユーザは疑問に思うかもしれないが、マイグレーションの概念の下では、ソースデバイスにおいてもターゲットデバイスにおいても同じアプリケーションが実行される。このように、マイグレーションにより、ユーザが異なるアプリケーションを学ぶ時間が不要になるだけでなく、ソフトウェア開発者が異なるアプリケーションを開発する時間までもが不要になるのである。

二つめの課題は、これほど簡単ではない。ターゲットデバイスに再記録されたアプリケーションは、ソースデバイスに存在していたアプリケーションの状態を復旧するまでは、事実上タスクを再開することができない。ここで、アプリケーションの状態とは、実行状態とデータの状態の両方を含む。アプリケーションの状態は、アプリケーションがソースデバイスからマイグレーションする前に保存しておき、ターゲットデバイスに再記録された後に保存したアプリケーションを復旧するというような操作を行うことで、面倒ではあるが、手動で復旧することができる。しかし、マイグレーション処理では、アプリケーションがソースデバイスからマイグレーションする際には、アプリケーションの状態を伴ってマイグレーションし、ターゲットデバイスにおいてその状態のままリスタートする。このように、アプリケーションは、ターゲットデバイスに到達してすぐタスクを再開できる状態になっている。

アプリケーションのマイグレーションを実現するために、様々な研究が報告されている。意義深いことに、これらの研究の多くは、Ｊａｖａ（登録商標）ベースのソフトウェアアーキテクチャを採用している。Ｊａｖａはプログラミング言語であり、プログラムが実行されるデバイスのハードウェア構成とは関係がない。さらに具体的には、Ｊａｖａプログラムは、ハイレベルであり、かつ機械に依存しないバイトコードにコンパイルされる。また、このバイトコードはＪａｖａ仮想マシンと呼ばれる仮想インタプリタが翻訳することにより実行される。また、このＪａｖａプログラムは機械に依存していないため、異なるハードウェアプラットフォームで実行することができ、アプリケーションにポーティング処理を施す必要がない。この特性は、Ｊａｖａが「一度書けば、どこでも実行できる」と評される所以である。

このようにＪａｖａは、機械に依存しないという特性を持っているため、異種デバイス間、つまり異なるハードウェア構成のデバイス間でのアプリケーションのマイグレーションに有用かつ有利であることは言うまでもない。実際、過去の研究では、Ｊａｖａベースのソフトウェアアーキテクチャによるアプリケーションのマイグレーションが、少なくとも限られた環境においては成功するということが証明されている。しかし、これら先行研究の問題点は、アプリケーションのマイグレーションを実行するためには、選択されたソースデバイスとターゲットデバイスが同程度でかつ十分に機能性の高いものであることが必要だということである。言い換えれば、先行研究におけるアプリケーションのマイグレーションは真の意味での異種環境間で実際に達成されたものではない。

確かに、デスクトップ型ＰＣのように機能性の高いデバイスからＰＤＡのような機能が少ないデバイスにアプリケーションをマイグレーションする場合に困難が生じる。デスクトップ型ＰＣに比べ、ＰＤＡは、処理速度、メモリ容量、永久記憶装置の可用性、ネットワーク通信能力の信頼度などのハードウェア資源に限界がある。ここで課題となるのは、アプリケーションを実行するにはＰＣレベルのリソースが必要であってＰＤＡでの実行には適さない場合でさえ、デスクトップ型ＰＣからＰＤＡに対するアプリケーションのマイグレーションが可能かどうかである。先行研究で、この課題に取り組んだ例は見られない。

上記課題を解決するため、本発明は、真の意味で異種のコンピュータデバイス間でアプリケーションのマイグレーションを実現する方法およびシステムを提供する。この目的を達成するため、本発明では、適応的にマイグレーションするアプリケーションが、マイグレーションの処理中に自らを再構成し、ターゲットのコンピュータデバイスへのアプリケーションの適合化やポーティングを行う。

本発明に係るポーティング処理はユニークである。本発明では、アプリケーションは複数のスタンドアロンのソフトウェアコンポーネントから成る。これらコンポーネントは、デバイス非依存型（ＤＩ：Ｄｅｖｉｃｅ Ｉｎｄｅｐｅｎｄｅｎｔ）とデバイス依存型（ＤＤ：Ｄｅｖｉｃｅ Ｄｅｐｅｎｄｅｎｔ）に分類される。ＤＩコンポーネントは、異なるハードウェアプラットフォームで実行することができる。一方、ＤＤコンポーネントを実行するには、特定のハードウェア構成が必要となる。したがって、ＤＤグループは、異なるハードウェアプラットフォーム上で実行できるように設計された複数セットの代替コンポーネントで形成されている。このように、アプリケーションが実行されるデバイスにおいてアプリケーションを実行するのに適したＤＤコンポーネントが上記複数セットから選ばれ、ＤＩコンポーネントと共にアプリケーションを構成するのである。

本発明に係るマイグレーション処理は、まず、ソースデバイスにおいて実行中の、マイグレーション前のアプリケーションを検査することにより始まる。このアプリケ−ションの検査では、現在実行中のアプリケーションのＤＤコンポーネントは何かということ、また代替ＤＤコンポーネントがあるかどうか判定される。ターゲットデバイスのハードウェア構成に関する検査も行われ、ターゲットデバイスに適合するＤＤコンポーネントを選択することにより、アプリケーションをターゲットデバイスに提供する。そして、選択されたＤＤコンポーネントは、ＤＩコンポーネントとともにターゲットデバイスにロードされる。同時に、ソースデバイス側でのアプリケーションの実行状態が取得され、ターゲットデバイスに転送される。アプリケーションの、取得された実行状態を使い、ターゲットデバイス上でアプリケーションがインスタンス化されると、マイグレーション処理は終了する。

本発明に係るマイグレーション処理においては、アプリケーションの機能は１以上のターゲットデバイスに分配されてもよい。ＤＩコンポーネントは機能コンポーネントなので、異なるプラットフォームで実行することができる。しかし、マイグレーション前のアプリケーションのＤＩコンポーネントが、ターゲットデバイスの能力を超えたコンピュータ処理能力を必要とするタスクを実行する場合もあるかもしれない。本発明では、そのようなタスクは、十分なコンピュータ処理能力がある第３のデバイスに割り当てられる。このように、このＤＩコンポーネントは第３のデバイスにマイグレーションし、他のコンポーネントはターゲットデバイスにマイグレーションする。これ以後、ターゲットデバイスと第３のデバイスは、互いに通信しながら協力してアプリケーションを実行する。

このように、本発明では、ソースデバイスにおいて実行中のアプリケーションとターゲットデバイスのハードウェア構成が検査され、アプリケーションをターゲットデバイスにポーティングする。そして、ポーティングされたアプリケーションは、ターゲットデバイスにロードされる。同時に、ソースデバイス側でのアプリケーションの実行状態が取得され、ターゲットデバイスに転送される。ターゲットデバイスは、取得したアプリケーションの実行状態を使い、アプリケーションをインスタンス化する。アプリケーションは１以上のコンポーネントを含む複数のセットから成り、ターゲットデバイスに最も適合するコンポーネントを少なくともひとつ、各セットから選択することにより、アプリケーションがターゲットデバイスにポーティングされる。

アプリケーションは、１以上の第３のデバイスからターゲットデバイスにロードされ、この第３のデバイスはソースデバイスを含んでも良い。
また、１以上のターゲットデバイスがあってもよく、アプリケーションは１以上のターゲットデバイスに分配されてロードされる。

添付の図面に例示された本発明の実行方法について詳しく説明する。以下に説明する本発明の好ましい形態では、Ｊａｖａベースのソフトウェアシステムを使用している。しかしながら、Ｊａｖａベースのソフトウェアシステムは本発明を実行する唯一の手段ではないことは容易に理解されるべきであり、他の種類のソフトウェアシステムの下で本発明を実行してもよい。

Ａ．マイグレーション動作の概略
本発明に係るアプリケーションのマイグレーションは、特に本発明を実行するために設計されたローム（Ｒｏａｍ：ＲｅｓＯｕｒｃｅ−ａｗａｒｅ Ａｐｐｌｉｃａｔｉｏｎ Ｍｉｇｒａｔｉｏｎ：リソース認識アプリケーション・マイグレーション）システム上で実行される。図１は、ロームシステムのアーキテクチャを例示するブロック図である。図１に示すように、ロームシステムは、Ｊａｖａ仮想マシン（ＪＶＭ）、ＰｅｒｓｏｎａｌＪａｖａ仮想マシン（ＰＪＶＭ）、またはその他の種類の仮想マシン（ＶＭ）の上に構築され、デバイス固有のオペレーティングシステムの最上位で実行される。ＶＭは、抽象化コンピュータデバイスのように動作する。つまり、受け取ったバイトコードを、固有のオペレーティングシステムが実行できる形に変換することにより動的に翻訳する。

「ロームレット」は、ワードプロセッサプログラムやメールプログラムなど、ユーザと直接インターフェースをとるプログラムである。これは、Ｊａｖａで記述され、ＪＶＭＰ、ＪＶＭ、または他の種類のＶＭにより実行される。本発明において、ロームレットは、ロームシステムの制御下でソースデバイスからターゲットデバイスへマイグレーションする。ロームシステムには、ロームレットのマイグレーションの実行時環境を提供するロームエージェントが備えられている。ロームエージェントは、マイグレーションの実行において重要な役割を果たすので、マイグレーションが実行される際には必ずソースデバイスとターゲットデバイスの双方に備える必要がある。ロームシステムとロームレットの間には、複数のロームレットＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ：アプリケーション・プログラム・インターフェース）が一式備えられ、ロームエージェントからの指示を受け取って、ロームレットのマイグレーションの実際の動作を実行する。

図２は、本発明に係る、基本的なマイグレーション動作を示すブロック図である。図２では、ロームレット１がソースデバイス２からターゲットデバイス３にマイグレーションしようとするところを示している。ステップ１において、マイグレーションが指示されると、ソースデバイス２のロームエージェント４が、ターゲットデバイス３のロームエージェント５とネゴシエーションを開始する。このネゴシエーション処理については後で詳述するので、ここでは簡単に説明する。ネゴシエーション処理の間、ロームエージェント４はまず、ロームレット１から、ロームレット１を実行するのに必要なハードウェア構成に関する情報を取得する。次に、ロームエージェント４は、ロームエージェント５から、ターゲットデバイス３のハードウェア構成に関する情報を取得し、ロームレット１がターゲットデバイス３上で実行可能かどうか判定する。今ここで説明が詳しくなりすぎないように、ロームレット１がターゲットデバイス３上で実行可能であると仮定する。最後に、ロームエージェント４は、ロームエージェント５にＨＴＴＰサーバ６のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ：ユニフォーム・リソース・ロケータ）を与え、このＵＲＬからロームレット１のバイトコードをダウンロードすることができるようにする。

ステップ２において、ＵＲＬを受け取ると、ロームエージェント５は、ＨＴＴＰサーバ６にアクセスして、そこからロームレット１のバイトコードをダウンロードする。ステップ３において、ロームレット１の状態が、ロームエージェント４により取得され、ロームエージェント５に送られる。ステップ４において、ロームエージェント５は、取得したロームレット１のソースデバイス２における状態を復旧することにより、ロームレット１をインスタンス化する。ロームレット１のマイグレーションは、ソースデバイス２においてロームレット１を閉じることにより終了する。この段階で、ロームレット１はターゲットデバイス上にあり、ソースデバイス２において停止されていたタスクを再開できる状態になっている。

Ｂ．マイグレーション動作の詳細な説明
１．デバイスの分類
ロームレットは多かれ少なかれデバイス依存型である。したがって、ソースデバイスのロームエージェントは、マイグレーションを実行する前にターゲットデバイスのハードウェア構成を把握する必要があり、それにより特定のロームレットが全体として又は部分的にでもターゲットデバイスにおいて実行可能かどうかが判定可能となる。Ｊａｖａランタイムシステムには実行側デバイスのハードウェア構成を示す情報が含まれているので、ロームシステムを構築する際にＪａｖａを使用すると便利である。現在、Ｊａｖａランタイムシステムには、異なるコンピュータデバイスに合わせた実行時環境を提供するものが複数種類ある。表１は、典型的なＪａｖａランタイムシステムと各々の構造を示している。

表１に示すように、Ｊａｖａランタイムシステムは、仮想マシン（ＶＭ）、コンフィギュレーション、そしてプロファイルの３層構造になっている。コンフィギュレーションは、ＪａｖａＡＰＩの仕様を示している。プロファイルは、コンフィギュレーションＡＰＩの拡張を指定する。表１には、ＰＪＶＭ（Ｐｅｒｓｏｎａｌ
Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ：パーソナルＪａｖａ仮想マシン）、ＣＶＭ（Ｃｏｍｐａｃｔ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ：コンパクト仮想マシン）、ＫＶＭ（Ｋｉｌｏ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ：キロ仮想マシン）３種類のＶＭがある。これらのＶＭは特定のハードウェア構成に適合するように設計されている。例えば、ＫＶＭは、１６／３２ビットのＲＩＳＣ／ＣＩＳＣマイクロプロセッサを備えた、使用可能なメモリ合計が少なくとも１６０Ｋのデバイスに適している。ＰＪＶＭは、文献「ＰｅｒｓｏｎａｌＪａｖａ（登録商標）テクノロジ白書」（サン・マイクロシステムズ、１９９８年８月）で議論されおり、本願明細書において参照として援用される。ＣＶＭは、文献「ＪＳＲ＃００００３６Ｊ２ＭＥ（登録商標）接続デバイスコンフィギュレーション」（サン・マイクロシステムズ、２０００年８月）で議論されており、本願明細書において参照として援用される。ＫＶＭは、文献「Ｊ２ＭＥ ＣＬＤＣ／ＫＶＭパームリリース：リリースノート／ＣＬＤＣ１．０」（サン・マイクロシステムズ、２０００年５月）で議論されており、本願明細書において参照として援用される。

また、表１は、ＣＤＣ（Ｃｏｎｎｅｃｔｅｄ Ｄｅｖｉｃｅ Ｃｏｎｆｉｇｕｒａｔｉｏｎ：コネクティッド・デバイス・コンフィギュレーション）、ＣＬＤＣ（Ｃｏｎｎｅｃｔｅｄ Ｌｉｍｉｔｅｄ Ｄｅｖｉｃｅ Ｃｏｎｆｉｇｕｒａｔｉｏｎ：コネクティッド・リミティッド・デバイス・コンフィギュレーション）の２種類のコンフィギュレーションと、パーソナルプロファイル、ＲＭＩプロファイル、ファンデーションプロファイル、ＰＤＡプロファイル、ＭＩＤ（Ｍｏｂｉｌｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｄｅｖｉｃｅ：モバイル情報デバイス）プロファイルの５種類のプロファイルを示している。これらのコンフィギュレーションおよびプロファイルも、特定のハードウェアプラットフォームで効果的に機能するようにデザインされている。これらのコンフィギュレーションおよびプロファイルは、文献「Ｊａｖａ仕様リクエスト」（Ｊａｖａコミュニティ出版）で議論されており、例えば、ＵＲＬ、ｈｔｔｐ：／／ｊａｖａ．ｓｕｎ．ｃｏｍ／ａｂｏｕｔＪａｖａ／ｃｏｍｍｕｎｉｔｙｐｒｏｃｅｓｓ／ｓｅａｒｃｈ．ｈｔｍｌで参照可能であり、本願明細書において参照として援用される。

このように、デバイスのＪａｖａランタイムシステムを参照して、ＶＭ、コンフィギュレーション、およびプロファイルの種類を調べることにより、デバイスのハードウェア構成をかなり正確に特定することが可能である。しかしながら、Ｊａｖａランタイムシステムはデバイスのハードウェア構成を特定する唯一の情報源ではなく、当業者にとってこの目的のために利用可能な他の情報源の存在を理解することは容易であると解されるべきであろう。例えば、ロームエージェントは、デバイス上で作成された特別なデバイス機能ファイルから、このデバイスのハードウェア構成に関する詳細かつ正確な情報を取得することができる。デバイスにおいて実行されている、ベースとなる固有のオペレーティングシステムに問合せをすれば、ハードウェア情報はこのデバイス機能ファイルから取得できる。

２．コンポーネントベースのプログラミング
ロームレットは、分散した複数のソフトウェアコンポーネントで構成されている。各コンポーネントには、コンポーネントの割り当てられたタスクを行うために実行可能な１以上のオブジェクトが入っている。ロームレットの複数のコンポーネントは相互接続されていて、全体としてロームレットの目的を遂行する。これらのコンポーネントは、デバイス依存型（ＤＤ）グループとデバイス非依存型（ＤＩ）グループに分類されている。ＤＤコンポーネントはソフトウェアコンポーネントで、その実行には特定のハードウェア構成が必要である。本発明では、ハードウェアプラットフォームの種類ごとに、ひとつのインプリメンテーション、つまりひとつのＤＤコンポーネントが提供される。ＤＤコンポーネントの例としては、ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ：グラフィカル・ユーザ・インタフェース）コンポーネントがあり、このコンポーネントでは、コンポ−ネットが実行される入力ハードウェアや表示ハードウェアの種類によって異なるＧＵＩライブラリが必要である。ＧＵＩを含む必要があるロームレットには、ロームレットが異なるプラットフォームで実行できるようにコンポーネントが準備される。これらのＧＵＩコンポーネントは、ＰＣ用のＧＵＩコンポーネント、ＰＤＡ用のＧＵＩコンポーネント、およびその他のプラットフォーム用のＧＵＩコンポーネントを含む。ロームレットがターゲットデバイスにマイグレーションするとき、ターゲットデバイスのハードウェア構成に最も適したＧＵＩコンポーネントが選択され、ターゲットデバイスにおいてインスタンス化される。

一方、ＤＩコンポーネントは、機能コンポーネントである。本発明では、複数のハードウェアプラットフォームに対して、ひとつのインプリメンテーション、つまりひとつのＤＩコンポーネントが提供される。ＤＩコンポーネントは機能的な特徴を持っているので、異なるハードウェアプラットフォームで実行されるものとみなされている。しかし、ＤＩコンポーネントの中には、例えば、高いコンピュータ処理能力のような特定のハードウェア能力を必要とするものもあることがわかっている。ロームレットのＤＩコンポーネントが必要とするハードウェア能力が不足しているターゲットデバイスに、ロームレットがマイグレーションする場合、そのＤＩコンポーネントはロームレットからオフロードされ、第３のデバイスにマイグレーションする。これについては、後に詳述する。

このように、各ロームレットに対して、ＤＩコンポーネントが１セット準備され、ロームレットが異なるハードウェアプラットフォームで動作できるようにＤＤコンポーネントが複数セット準備される。尚、ひとつのロームレットに対してＤＤコンポーネントが複数セット準備されるが、あるデバイスにおいて実際実行されているロームレットにおいては、そのデバイスのハードウェア構成に最も適したＤＤコンポーネントが１セットのみインスタンス化されることに留意してほしい。後続のセクションで詳しく説明するが、ターゲットデバイスのハードウェア構成に最も適したＤＤコンポーネントを１セット選択するには、ソースデバイスのロームエージェントは、マイグレーションするロームレット用に備えられたＤＤコンポーネントのセットすべてを検査し、各セットが必要とするハードウェア構成とターゲットデバイスのハードウェア構成を比較する。

これらＤＩコンポーネントとＤＤコンポーネントはＪａｖａでプログラムされ、バイトコードにコンパイルされた後、上述したＨＴＴＰサーバ６のようなサーバに格納される。これらのコンポーネントは、ターゲットデバイスのハードウェア構成に従ってサーバからターゲットデバイスに選択的にダウンロードされる。しかしながら、ソースデバイスが十分大きなメモリを持っている場合、ＤＩコンポーネントおよびＤＤコンポーネントのセットすべてを、使用中か否かにかかわらずソースデバイスに保存してもよいことに留意してほしい。

３．動的インスタンス化
次に図３を参照して、マイグレーション動作の詳細を説明する。図３では、ソースデバイス１０はＰＣで、ターゲットデバイス１１はＰＤＡである。ＰＣ１０とＰＤＡ１１は、通信ネットワーク１２を介して互いに接続され、通信ネットワーク上の一意のＩＰアドレス（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ａｄｄｒｅｓｓ：インターネット・プロトコル・アドレス）で特定される。ロームレット１３は、現在ＰＣ１０において実行されていて、ＰＤＡ１１にマイグレーションするところである。マイグレーションが指示されると、ＰＣ１０に存在するロームエージェント１４は、ＰＤＡ１１に存在するロームエージェント１５とネゴシエーションを開始する。

図４は、マイグレーション動作をステップごとに示したフローチャートである。ステップ１０において、ロームエージェント１４はロームレット１３とＰＣ１０において実行されているコンポーネントを検査する。ロームレット１３を検査する際、ロームエージェント１４は、現在ＰＣ１０において実行されているロームレット１３のＤＤコンポーネントとＤＩコンポーネントを特定するととともに、異なるハードウェアプラットフォームにおいてロームレット１３を実行するのに利用できる代替ＤＤコンポーネントを特定する。ここでは、ロームレット１３がＰＣ上でのみ実行できるＧＵＩコンポーネント１６を含んでおり、かつ、ロームレット１３をＰＤＡにおいて実行するためのＰＤＡ用の代替ＧＵＩコンポーネント１７が利用可能であるとロームエージェント１４が特定したと仮定する。

ステップ１１において、ロームエージェント１４はＰＤＡ１１のロームエージェント１５に連絡し、ＰＤＡ１１のハードウェア構成に関する情報を要求する。ロームエージェント１４からの要求に応じて、ロームエージェント１５はＰＤＡ１１において実行されているＪａｖａランタイムシステムを検査する（ステップ１２）。自分のランタイムシステムに含まれているＶＭ、コンフィギュレーション、そしてプロファイルの種類に基いて、ロームエージェント１５はＰＤＡ１１のハードウェア設定、例えば、コンピュータ処理能力、スクリーンサイズやメモリサイズなどを判定する。そしてロームエージェント１５は、ＰＤＡ１１のハードウェア構成に関する情報をロームエージェント１４に送り返す（ステップ１３）。尚、ＰＤＡ１１のハードウェア構成に関してさらに詳細または正確な情報を取得する必要がある場合は、ロームエージェント１５はＰＤＡ１１のベースとなる固有のオペレーティングシステムに格納されているデバイス機能ファイルを参照してもよいことに留意してほしい。

ステップ１４において、ロームエージェント１４は、ロームエージェント１５からのＰＤＡ１１のハードウェア構成に関する情報に基いて、どのコンポーネントがＰＤＡ１１に対してのマイグレーションが可能でどのコンポーネントが可能でないかを判定する。ロームレット１３のＤＩコンポーネントはすべて、ＰＤＡ１１のハードウェア構成に拘らずマイグレーション可能である。ＤＤコンポーネントに関しても、いくつかはＰＤＡ１１にマイグレーション可能な場合もあるが、ＰＣ１０とＰＤＡ１１間のハードウェアの違いが原因でマイグレーションできないＤＤコンポーネントについては、ロームエージェント１４はＰＤＡ１１において実行可能な代替コンポーネントを検索する。

ステップ１５において、ロームエージェント１４は、ＤＩコンポーネントおよびＤＤコンポーネントのＵＲＬと、ＨＴＴＰサーバ６に格納されている代替ＤＤコンポーネントを、ロームエージェント１５に送信する。図３に示す例においては、ＰＣのＧＵＩコンポーネント１６は現在ＰＣ１０上で実行中であるので、ＰＤＡ１１にマイグレーションすることはできない。よって、ロームエージェント１４は、ロームエージェント１５に対し、ＨＴＴＰサーバ６に格納されているＰＣのＧＵＩコンポーネント１７のＵＲＬを送信する。

ステップ１６において、ロームエージェント１５はロームエージェント１４から送信されたＵＲＬを使ってサーバ６にアクセスし、サーバ６にバイトコードの形で格納されているコンポーネントのダウンロードを開始する。同時に、ステップ１７において、ロームエージェント１４は、ＰＣ１０におけるロームレット１３の実行状態を取得し、取得した状態をロームエージェント１５に送信する。ステップ１８において、ロームエージェント１５はロームレット１３’をＰＤＡ１１において展開し、展開されたロームレット１３’で、取得した状態を復旧する。これで、ロームレット１３’はＰＤＡ１１においてタスクを再開する準備ができた状態となる。ステップ１９において、ロームエージェント１５は、ロームエージェント１４に対して、ロームレット１３’のＰＤＡ１１上への複製が成功した旨を通知する。これに対し、ロームエージェント１４は、ＰＣ１０からロームレット１３を削除する（ステップ２０）。

本発明においては、Ｊａｖａオブジェクトシリアル化を使って、ロームレット１３の実行状態の取得および復旧が実行される。Ｊａｖａオブジェクトシリアル化は、Ｊａｖａプログラムの実行状態を取得し復旧する有用な方法を提供する。図３に示す形態では、ロームエージェント１４がＰＣ１０においてＪａｖａオブジェクトシリアル化を呼び出し、ロームレット１３にあるすべてのＪａｖａオブジェクトの実行状態をシリアル化する。ロームエージェント１５もＰＤＡ１１にＪａｖａシリアル化を呼び出し、シリアル化された実行状態をＰＤＡ１１においてロームレット１３’に非シリアル化する。このＪａｖａオブジェクトシリアル化によってシリアル化可能な実行状態は、ロームレット１３にある各オブジェクトのすべての変数の値を含む。このＪａｖａオブジェクトシリアル化を使うことにより、ロームレット１３の実行状態の大部分をＰＣ１０において取得することができ、ＰＤＡ１１において復旧することができる。

しかし、このＪａｖａオブジェクトシリアル化に適さない実行状態が２種類ある。ひとつは、ロームシステム特有の実行状態である。即ち、代替ＤＤコンポーネントと置換されるＤＤコンポーネントの実行状態は、代替ＤＤコンポーネントにおいては復旧できない。ＤＤコンポーネントとその代替コンポーネントは、異なるオブジェクトから成ることが多いので、ＤＤコンポーネントの実行状態は、その代替コンポーネントにとっては無意味となる。従って、変換処理を施して、ＤＤコンポーネントとその代替コンポーネント間で実行状態を維持する必要がある。例えば、図３に戻り、ＰＣのＧＵＩコンポーネント１６がチェックボタンを使ってユーザインターフェースを実行する一方、ＰＣのＧＵＩコンポーネント１７は選択ボタンを使ってユーザインターフェースを実行していると仮定する。ＰＣのＧＵＩコンポーネント１６の実行状態をＰＣのＧＵＩコンポーネント１７に転送するためには、ロームエージェント１４はチェックボタンの値を選択ボタンにマップし、これらの値を選択ボタンの値に変換する。

Ｊａｖａオブジェクトシリアル化に適さないふたつめの実行状態は、ロームレット１３を翻訳するＶＭの実行状態である。Ｊａｖａオブジェクトシリアル化はＶＭ内部にはアクセスすることができない。したがって、コールスタックなどのＶＭの実行状態は、シリアル化できない。この問題に対処するため、ロームエージェント１４は、コールスタックが最小になる特定のポイントでのみマイグレーションを実行可能としてもよい。これにより、失われる実行状態の量を極力抑えることができる。

以下は、ロームシステム下で基本的なマイグレーションを実行する際のロームレットＡＰＩの例である。

ロームレットはすべて、クラスロームレットを拡張しなければならない。メソッド“ｍｉｇｒａｔｅ（）”は、“ｈｏｓｔｎａｍｅ”によって示されるターゲットデバイスにロームレットをディスパッチする。メソッド“ｏｎＩｎｉｔｉａｌｉｚａｉｔｏｎ（）”は、ロームレットがターゲットデバイスにおいて、最初にインスタンス化された時に呼び出される。メソッド“ｏｎＲｅｍｏｖａｌ（）”は、ロームレットのターゲットデバイスへのマイグレーションが成功した後、ロームレットがソースデバイスから削除される前に呼び出される。メソッド“ｏｎＡｒｒｉｖａｌ（）”は、ロームレットがターゲットデバイスに到着した時に呼び出される。メソッド“ｅｘｉｔ（）”は、ロームレットをソースデバイスから削除する。メソッド“ｉｎｓｔａｎｔｉａｔｉｏｎ（）”は、ターゲットデバイスにおいてロームレットをインスタンス化する。ターゲットデバイスにおいてロームレットがインスタンス化された後、分離スレッドがターゲットデバイスにおいて生成され実行される。これにより、ターゲットデバイス上で複数の仮想マシンを生成して実行するというオーバーベッドが無くなる。

以下は、同じ機能を実行する代替ＤＤコンポーネント群を維持するためのロームレットＡＰＩの例である。

メソッド“ａｄｄＤＤＣｏｍｐｏｎｅｎｔＤｅｓｃＬｉｓｔ（）”は、デスクリプタリスト、即ち、ＲｏａｍＣｏｍｐｏｎｅｎｔＤｅｓｃ［］を追加する。このデスクリプタリストは、ハードウェア設定に係る代替ＤＤコンポーネントを列挙している。例えば、デスクリプタリストには、ＰＣのＧＵＩコンポーネント、ＰＤＡのＧＵＩコンポーネント、携帯電話ＧＵＩコンポーネントなどの代替ＧＵＩコンポーネントがすべて含まれている。マイグレーションを実行する場合、このデスクリプタリストからターゲットデバイスに最も適したコンポーネントがひとつ選択される。

４．デバイス間での機能の分配
ロームレットの実行に必要不可欠なＤＩコンポーネントのいくつかが、ターゲットデバイスのハードウェア資源が不十分なために実行できない場合があり得る。そのような場合、ロームシステムは、ロームレットの機能を複数のデバイスに分配する。即ち、ロームシステムは、コンポーネントを複数のターゲットデバイスにマイグレーションさせる。図５および図６は、このような分配動作を示すブロック図と、本動作を詳述するフローチャートである。図５では、図３で使用した符号と同じ符号が、デバイスとソフトウェアの構成要素に対応して割り当てられている。

図５では、図３と同様に、ロームレット１３がソースデバイス１０であるＰＣからターゲットデバイス１１であるＰＤＡにマイグレーションしようとしている。ステップ３０において、ロームエージェント１４はロームレット１３を検査し、現在ＰＣ１０において実行されているロームレット１３のＤＩコンポーネントおよびＤＤコンポーネントを特定する。例えば、ロームレット１３は、重荷で、使用するメモリの多いコンピュータ処理タスクを実行するＤＩコンポーネント１８を含み、このタスクの実行にはＰＤＡ１１の能力を超えたコンピュータ処理能力を必要とするため、このコンポーネント１８は、ＤＩコンポーネントであるにも拘らず、ＰＤＡ１１においては実行不可能であると仮定する。また、このＤＩコンポーネント１８はロームレット１３の実行には必要不可欠であるのに、ＰＤＡにおいて利用可能な代替コンポ−ネントは存在しないと仮定する。

ステップ３１では、ロームエージェント１４は、ＰＤＡ１１のロームエージェント１５に連絡し、ＰＤＡ１１のハードウェア構成に関する情報を要求する。ロームエージェント１４からのこの要求に応じ、ロームエージェント１５はＰＤＡ１１において実行されているＪａｖａランタイムシステムを検査し、ＰＤＡ１１のハードウェア構成を判定する（ステップ３２）。ステップ３３において、ロームエージェント１５は、ＰＤＡ１１のハードウェア構成に関する情報をロームエージェント１４に送り返す。

ステップ３４において、ロームエージェント１４は、ロームエージェント１５からのハードウェア情報に基いて、ロームレット１３のどのコンポーネントをＰＤＡ１１に対してマイグレーション可能か、どのコンポーネントがマイグレーション不可能かを判定する。ロームエージェント１４は、ＰＤＡ１１のコンピュータ処理能力には限度があるため、コンポーネント１８をＰＤＡ１１にマイグレーションすることはできないと判定する。ロームエージェント１４は、ステップ３０において既に、ＰＤＡ１１において利用可能な代替コンポーネントは存在しないと判定している。

ステップ３５において、ロームエージェント１４は、コンピュータ処理コンポーネント１８をロームレット１３からオフロードできるかどうかをまず判定する。コンポーネント１８がオフロード可能と判定された場合、ロームエージェント１４はマイグレーション動作を続けて実行する。コンポーネント１８をロームレット１３からオフロードできない場合、ロームエージェント１５はマイグレーション処理を打ち切る。そして、コンポーネント１８がオフロード可能の場合、ロームエージェント１５は、コンポーネント１８を実行可能な第３のデバイスの検索を開始する。ユーザがこのデバイス検索に参加して、自分がコンポーネント１８をマイグレーションしたい特定のデバイスを指定してもよい。ここでは、ロームエージェント１４が、コンポーネント１８を実行するのに十分なコンピュータ処理能力を持つサーバ１９を探し出すのに成功したと仮定する。

ステップ３６において、ロームエージェント１４は、サーバ６に格納されている、ＰＤＡ１１にマイグレーション可能なロームレット１３の各コンポーネントのＵＲＬをロームエージェント１５に送信する。また、ロームエージェント１４は、サーバ１９のロームエージェント２０に対して、サーバ６に格納されているコンポーネント１８のＵＲＬを送信する。ロームエージェント１５は、指定された複数のＵＲＬを使って、サーバ６から各コンポーネントのバイトコードをダウンロードする（ステップ３７）。同様に、ロームエージェント２０は、コンポーネント１８のバイトコードをサーバ６からダウンロードする（ステップ３８）。同時に、ステップ３９において、ロームエージェント１４は、ロームエージェント１３の各コンポーネントの実行状態を取得し、取得した実行状態をマイグレーション先の各デバイスに送信する。具体的には、ロームエージェント１４は、ＰＤＡ１１にマイグレーションすべきコンポーネントの実行状態をロームエージェント１５に送信するとともに、サーバ１９にマイグレーションすべきコンポーネント１８の実行状態をロームエージェント２０に送信する。ロームエージェント１５は、ロームエージェント１４から送信された取得状態を使って、ロームレット１３”をＰＤＡ１１上でインスタンス化する（ステップ４０）。同様に、ロームエージェント２０は、コンポーネント１８をサーバ１９においてインスタンス化する（ステップ４１）。ロームエージェント１５および２０は、ロームエージェント１４に対し、ロームレット１３”およびコンポーネント１８がＰＤＡ１１およびサーバ１９に各々複写されたことを通知する（ステップ４２および４３）。そして、ロームエージェント１４は、ＰＣ１０からロームレット１３を削除する（ステップ４４）。ロームレット１３”は、ＰＤＡ１１においていつでもタスクを再開できる状態にある。

ロームシステムでは、ロームレット１３”をＰＤＡ１１からＰＣ１０に対して逆にマイグレーションすることができる。このような逆分配動作においては、今度はソースデバイス側となるＰＤＡ１１のロームエージェント１５が、図４に示す手順を実行し、今度はターゲットデバイスとなるＰＣ１０にロームレット１３”を返送する。同様に、ロームエージェント２０は、コンポーネント１８をＰＣ１０に対して返送する。尚、ＰＤＡ１１において実行されるコンポーネントのいくつかは、ＰＣ１０にマイグレーションできなくなっている可能性があることに留意して欲しい。そのようなコンポーネントがある場合は、コンポーネントはＰＤＡ１１にとどまることになる。

以下は、機能の分配を実行するロームレットＡＰＩの例である。

各ロームレットの構成要素は、クラスＲｏａｍＣｏｍｐｏｎｅｎｔを拡張する。メソッド“ａｄｄＤＩＣｏｍｐｏｎｅｎｔＤｅｓｃ（）”は、デスクリプタ、ＲｏａｍＣｏｍｐｏｎｅｎｔＤｅｓｃをＤＤコンポーネントの各々に追加するのに呼び出される。デスクリプタには、ＤＤコンポ−ネントの各々のインスタンス化の方法に関する情報が含まれている。即ち、ＤＤコンポーネントの各々について、一意の識別子、インスタンス化されるクラス名（ｃｌａｓｓｎａｍｅ）、コンポーネントを実行するのに必要なデバイス能力（ｒｅｑＤｅｖｉｃｅＣａｐａｂｉｌｉｔｙ）、コンポーネントがオフロード可能か否か（ｏｆｆｌｏａｄａｂｌｅ）、コンポーネントが逆分配可能か否か（ｒｅｖｅｒｓｅＡｐｐｏｒｔｉｏｎ）、そしてコンストラクタのパラメータ（ｉｎｉＡｒｇｓ）に関する情報が含まれている。メソッド“ｇｅｔＣｏｍｐｏｎｅｎｔ（ｉｄ）”は、コンポーネントがターゲットデバイスにおいてインスタンス化された後に、これらコンポーネントの参照を（ＩＤを使って）検索するのに呼び出される。メソッド“ｒｅｇｉｓｔｅｒＳｅｒｖｅｒＤｅｖｉｃｅ（）”は、コンポーネントがオフロード可能なすべてのデバイスを登録するのに呼び出される。

Ｃ．実施例
図７に示すコンピュータネットワークを使って実験を行い本発明を実行した。ネットワークは、ノートブック３０と、ＰＤＡ３１、カシオ（登録商標）Ｅ−１２５、およびＰＣ３２から成る。ウィンドウズ（登録商標）２０００ＯＳと標準ＶＭ（ＪＶＭ）がノートブック３０およびＰＣ３２おいて実行される。また、ウィンドウズＣＥ ＯＳとＰｅｒｓｏｎａｌＪａｖａＶＭ（ＰＪＶＭ）がＰＤＡ３１において実行される。ノートブック３０は、無線ＬＡＮ３３を介してネットワークに接続されている。ＰＤＡ３１とＰＣ３２は、無線ＬＡＮ３４を介してネットワークに接続されている。ネットワークでは、ノートブック３０にはＩＰアドレス、１７２．２１．９６．１７が割り当てられている。ＰＤＡ３１には、ＩＰアドレス、１７２．２１．９６．１９が割り当てられている。ノートブック３０、ＰＤＡ３１、ＰＣ３２の各々には、ロームレットエージェントがロードされている。このロームレットエージェントは、コードサイズが約２４Ｋバイトであり十分小さく、Ｊａｖａベースのソフトウェアアーキテクチャの殆どのデバイスにおいて実行できる。

１．第１例（ＨｅｌｌｏＷｏｒｌｄ）
図８に示すように、ノートブック３０は「ＨｅｌｌｏＷｏｒｌｄ」と呼ばれるロームレット３５を実行し、このロームレットはＰＤＡ３１にマイグレーションするところである。ＨｅｌｌｏＷｏｒｌｄロームレット３５は、Ｃｌｉｃｋコンポーネント３６およびＳｗｉｎｇのＧＵＩコンポーネント３７のふたつのコンポーネントから成る。Ｃｌｉｃｋコンポーネント３６は、ユーザが行うマウスクリックの回数を数える。ＳｗｉｎｇのＧＵＩコンポーネント３７は、ノートブック３０にマウスクリックのカウントを表示する。ノートブック３０からＰＤＡ３１にロームレット３５をマイグレーションする前に、ロームシステムの機能を証明するために２つのルールを定める。第１に、Ｃｌｉｃｋコンポーネント３６は、ＰＤＡ３１が持っているより高いハードウェア能力を必要とする。第２に、ＳｗｉｎｇのＧＵＩコンポーネント３７は、実行にはＪａｖａＳｗｉｎｇライブラリを必要とする。ＪａｖａＳｗｉｎｇライブラリは、ＳｔａｎｄａｒｄＪａｖａにはサポートされているが、ＰｅｒｓｏｎａｌＪａｖａにはサポートされていない。このように、ＳｗｉｎｇのＧＵＩコンポーネント３７はノートブック３０とＰＣ３２では実行可能だが、ＰＤＡ３１では実行不可能である。ＳｗｉｎｇのＧＵＩコンポーネント３７の代わりに、ＡＷＴ（Ａｂｓｔｒａｃｔ Ｗｉｎｄｏｗ Ｔｏｏｌｋｉｔ：抽象化ウィンドウツールキット）のＧＵＩコンポーネント３８を利用して、ロームレット３５を実行可能である。このＡＷＴのＧＵＩコンポーネント３８を実行するには、ＰｅｒｓｏｎａｌＪａｖａにサポートされているＪａｖａＡＷＴライブラリが必要である。

ロームレット３５のマイグレーションは、このルールに従って実行される。つまり、Ｃｌｉｃｋコンポーネント３６は、ＰＤＡ３１にはマイグレーションしないが、ＰＣ３２にはマイグレーションする。ＳｗｉｎｇのＧＵＩコンポーネント３７は廃棄される。代わりに、ＡＷＴのＧＵＩコンポーネント３８がＰＤＡ３１でインスタンス化される。図９の（ａ）、（ｂ）、および（ｃ）は、各々ノートブック３０、ＰＤＡ３１、ＰＣ３２の画面を示す。マイグレーションの前には、ＨｅｌｌｏＷｏｒｌｄロームレット３５が、ノートブック３０で実行されている。ノートブック３０の画面に表示されているクリックカウントは、最初はゼロである。画面上の「Ｓｗｉｎｇ Ｃｌｉｃｋ」ボタンがクリックされるたびに、Ｃｌｉｃｋコンポーネント３６はクリックのカウントを増分し、ＳｗｉｎｇのＧＵＩコンポーネント３７は、画面にカウントを表示する。図９（ａ）において、カウントは「３」である。そして次に、マイグレーションが実行される。ＰＤＡ３１では、ＳｗｉｎｇのＧＵＩコンポーネント３７の代わりに、ＡＷＴのＧＵＩコンポーネント３８がインスタンス化されている。図９（ｂ）に示すように、ＡＷＴのＧＵＩコンポーネント３８は、ＰＤＡ３１の画面にカウント「３」を表示する。Ｃｌｉｃｋコンポーネント３６がＰＣ３２にインスタンス化されている（図９（ｃ））。この例では、マイグレーションは５秒未満で実行された。また、ＰＤＡの「ＡＷＴ Ｃｌｉｃｋ」ボタンをクリックする度に、クリックはＰＣ３２のＣｌｉｃｋコンポーネント３６にカウントされ、ＰＤＡの画面に表示されるクリックカウントが増分することが観察された。

２．第２例（Ｃｏｎｎｅｃｔ４）
第２例では、「Ｃｏｎｎｅｃｔ４」と呼ばれるゲームプログラムを使用した。図１０に示すように、ノートブック３０は、「Ｃｏｎｎｅｃｔ４」と呼ばれるロームレット４０を実行しており、このロームレットは、ＰＤＡ３１にマイグレーションするところである。Ｃｏｎｎｅｃｔ４ロームレット４０は、ＧＵＩコンポーネント４１およびＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ：人工知能）コンポーネント４２のふたつのコンポーネントから成る。ＡＩコンポーネント４２は、ゲームをするために、ツリーを検索するなどのコンピュータ処理作業を実行し、ＧＵＩコンポーネント４１は、ノートブックの画面にゲームの進行状況を表示する。ここでも、マイグレーションの前に、２つのルールが決定される。第１に、ＡＩコンポーネント４２はＰＤＡ３１が持っているより高いハードウェア能力を必要とする。第２に、ＧＵＩコンポーネント４１は、ノートブック３０とＰＤＡ３２の両方において実行可能である。

ロームレット４０のマイグレーションは、このルールに沿って実行される。つまり、ＧＵＩコンポーネント４１はＰＤＡ３１にマイグレーションし、ＡＩコンポーネント４２はＰＣ３２にマイグレーションする。図１１（ａ）および（ｂ）は各々、ノートブック３０およびＰＤＡ３１の画面を示す。マイグレーションの前には、図１１（ａ）に示すように、ノートブック３０ではＣｏｎｎｅｃｔ４ロームレット４０が実行されている。そして、マイグレーションが実行される。ＧＵＩコンポーネント４１はＰＤＡ３１でインスタンス化され、ＡＩコンポーネント４２はＰＣ３２でインスタンス化される。図１１（ｂ）に示すように、ＰＤＡ３１には同じ画面が表示される。この例では、マイグレーションは５秒未満で実行された。また、ＰＤＡ３１上で、ＰＣ３２にインスタンス化されたＡＩコンポーネント４２を使ってゲームをプレイすることができることが観察された。

本発明の範囲と精神にもとることなく、上記実施例に種々の修正や変更が可能であることは当業者に理解されよう。本発明の他の実施形態は、本願明細書および本願明細書に開示された本発明の実施方法とを検討することにより、当業者にとって明瞭になろう。また、明細書および実行例は、後続する特許請求の範囲に示される発明の範囲と精神において、単なる例示を意図するものである。

以上説明したように、本発明によれば、異種デバイス間におけるアプリケーションのマイグレーションが可能になる。

本願明細書に組み込まれ、本願明細書の一部を構成する添付図面は、本発明の実施形態を例示し、発明の詳細な説明とともに本発明の利点と原理を説明する役目を担う。
本発明に係るロームシステムのシステムアーキテクチャを示すブロック図である。 本発明に係る基本的なマイグレーション動作を示すブロック図である。 本発明の第１実施形態に係るマイグレーション動作を示すブロック図である。 図３に示すマイグレーション動作の詳細を示すフローチャートである。 本発明の第２実施形態に係るマイグレーション動作を示すブロック図である。 図５に示すマイグレーション動作の詳細を示すフローチャートである。 本発明を実施する例で使用されるコンピュータネットワークを示すブロック図である。 第１例で実行されるマイグレーション動作を示すブロック図である。 （ａ）、（ｂ）、および（ｃ）は、第１例で使用されるノートブック、ＰＤＡ、およびＰＣの表示画面である。 第２例で実行されるマイグレーション動作を示すブロック図である。 （ａ）および（ｂ）は、第２例で使用されるノートブックおよびＰＤＡの表示画面である。

符号の説明

１…ロームレット、２…ソースデバイス、３…ターゲットデバイス、４・５…ロームエージェント、６…ＨＴＴＰサーバ、１０…ＰＣ、１１…ＰＤＡ、１２…ネットワーク、１３・１３’…ロームレット、１４・１５…ロームエージェント、１６・１７…ＧＵＩコンポーネント、１８…コンピュータ処理コンポーネント、１９…サーバ、２０…ロームエージェント。

Claims (1)

1. 通信手段および記憶部を備えたコンピュータに、
   （ａ）マイグレーション対象であるアプリケーションを検査して、前記アプリケーションを構成する１以上のソフトウェアコンポーネントの各々を、複数の異なるハードウェアプラットフォームで実行可能な第一のソフトウェアコンポーネントか、実行に関して特定のハードウェア構成が必要な第二のソフトウェアコンポーネントかのいずれかに区分するステップと、
   （ｂ）マイグレーション先であるターゲットデバイスに当該ターゲットデバイスのハードウェア構成を示すハードウェア構成情報を要求し、その応答として前記ターゲットデバイスのハードウェア構成情報を受信するステップと、
   （ｃ）前記アプリケーションを構成する１以上のソフトウェアコンポーネントの各々が前記ターゲットデバイスにおいて実行可能か否かを前記ハードウェア構成情報に基づき判断するステップと、
   （ｄ）前記ステップ（ａ）において、前記第二のソフトウェアコンポーネントに区分され、前記ステップ（ｃ）において、前記ターゲットデバイスにおいて実行可能でないと判断されたソフトウェアコンポーネントの各々に関し、当該ソフトウェアコンポーネントの機能を代替可能であり、前記ハードウェア構成情報に基づき前記ターゲットデバイスにおいて実行可能と判断される代替コンポーネントを、前記コンピュータの記憶部もしくは前記コンピュータが通信可能な通信網内の格納場所から検索するステップと、
   （ｅ）前記ステップ（ｃ）において、前記ターゲットデバイスにおいて実行可能と判断されたソフトウェアコンポーネントの各々と、前記ステップ（ｄ）において、前記記憶部もしくは前記通信網内の格納場所から検索された前記代替コンポーネントの各々とに関し、前記ソフトウェアコンポーネントもしくは前記代替コンポーネントの本体、あるいは前記ソフトウェアコンポーネントもしくは前記代替コンポーネントの前記通信網における格納場所を示す格納場所情報を、前記ターゲットデバイスに送信するステップと、
   （ｆ）前記コンピュータにおける前記アプリケーションの実行状態を示す実行状態情報を前記ターゲットデバイスに送信するステップと
   を実行させるプログラム。

Images