JP5751711B2

JP5751711B2 - コンテキスト・アウェアに分散処理可能な処理装置、方法、及びプログラム

Info

Publication number: JP5751711B2
Application number: JP2012012241A
Authority: JP
Inventors: チェンエリック; 桂太郎堀川; 将司外山; 駿介車谷
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2012-01-24
Filing date: 2012-01-24
Publication date: 2015-07-22
Anticipated expiration: 2032-01-24
Also published as: JP2013152541A

Description

本発明は、モバイルＯＳ（オペレーティング・システム）の下で実行されるアプリケーションの実行に関し、特に、アプリケーションのバックグラウンド処理の実行をモバイル端末とサーバとの間で分散させる技術に関する。

スマートフォンやタブレット端末などのモバイル端末は、リチウムイオン電池などの二次電池（バッテリー）からの電力で動作し、モバイルＯＳによるプロセス管理及びメモリ管理の下で各種のアプリケーション（ＡＰ；アプリあるいはアプリケーションプログラムとも呼ばれる）を実行可能である。典型的なモバイル端末では、その表示画面上では１つのアプリケーションのみが実行されているように見えるが、実際には同時に他の種々のアプリケーションのバックグラウンド処理が実行されていることが多い。

また、モバイル端末で実行されるアプリケーションは、ＭＶＣ（モデル・ビュー・コントロール；Model View Control）というデザインパターンにより設計されることが多い。ＭＶＣでは、プログラムであるアプリケーションは、モデルとビューとコントロールという３つのコンポーネントに分けられる。モデルは、アプリケーションが実行すべき処理の手続きを規定するものであり、ビューは、モデルからデータを取り出して見やすい形態で利用者に表示するものであり、コントロールは、利用者からの入力に対して応答し、それを処理するコンポーネントである。ビューとコントロールとによって、利用者に対する入出力のインタフェース（すなわちユーザインタフェース）が提供され、モデルによってユーザインタフェースの処理からは分離したそのアプリケーションに固有の内部処理が実行されることになる。

非特許文献１に記載されるように、代表的なモバイルＯＳの１つのであるＡｎｄｒｏｉｄ（登録商標）ＯＳの環境では、アプリケーションは、ビューとコントロールとをまとめたActivityというコンポネントとモデルに対応するServiceというコンポーネントとから構成される。そして、Serviceコンポーネントにアプリケーションのバックグラウンド処理が実装されており、アプリケーションのＧＵＩ（グラフィカルユーザインタフェース）処理に相当するActivityコンポーネントの動作が停止した後も、バックグラウンドで処理を継続できるようになっている。

江川崇、竹端進、山田暁通、麻野耕一、山岡敏夫、藤井大助、藤田泰介、佐野徹郎、「Google Androidプログラミング入門」、163ページ、アスキー・メディアワークス、ISBN:4048679562、2009年7月1日

モバイル端末にインストールされるアプリケーションの数の増加に伴って、実行されるバックグラウンド処理の処理量も増加し、モバイル端末の電池消費の加速や処理速度の低下などの問題が生じる。

本発明の目的は、モバイルＯＳの下で実行されるアプリケーションについてそのバックグラウンド処理の分散処理を行ってモバイル端末の電池消費を低減し、処理速度を向上させることができる処理装置、方法及びプログラムを提供することにある。

本発明の第１の処理装置は、ユーザインタフェースに係る処理を実行する第１のコンポーネントと内部処理を実行する第２のコンポーネントとが分離して実装されているアプリケーションを実行する処理装置において、アプリケーションの実行に係るデータを格納するストレージと、第１のコンポーネントから第２のコンポーネントに対する呼出しがあったときに、処理装置のコンテキストとアプリケーションの属性とに基づき、第２のコンポーネントの処理を処理装置において実行するか、ネットワークを介して処理装置に接続して第２のコンポーネントに相当するコンポーネントを実装したサーバにおいて実行するかを判断し、判断の結果に応じて、呼出しの呼出し先を処理装置の第２のコンポーネントとサーバとの間で切り替える切替手段と、処理装置のストレージとサーバのストレージとの間でデータを同期させる同期手段と、を有することを特徴とする。

本発明の第２の処理装置は、ユーザインタフェースに係る処理を実行する第１のコンポーネントと内部処理を実行する第２のコンポーネントとが分離して実装されているアプリケーションを実行する端末装置にネットワークを介して接続する処理装置において、第２のコンポーネントに相当するコンポーネントが実装されており、端末装置に設けられるストレージと同期したストレージと、端末装置から呼出しを受けたときに実装されたコンポーネントを実行して実行結果を端末装置に返す制御手段と、を有することを特徴とする。

本発明の処理方法は、ユーザインタフェースに係る処理を実行する第１のコンポーネントと内部処理を実行する第２のコンポーネントとが分離して実装されているアプリケーションを実行する端末装置と、サーバとを有し、端末装置とサーバとがネットワークを介して接続しているシステムにおける処理方法において、第２のコンポーネントに相当するコンポーネントをサーバに実装し、端末装置においてアプリケーションの実行に係るデータを格納するストレージとサーバのストレージとを同期させ、端末装置において第１のコンポーネントから第２のコンポーネントに対する呼出しがあったときに、処理装置のコンテキストとアプリケーションの属性とに基づき、第２のコンポーネントの処理を端末装置において実行するかサーバにおいて実行するかを判断し、判断の結果に応じて、呼出しの呼出し先を処理装置の第２のコンポーネントとサーバとの間で切り替え、サーバが呼出し先に指定されたときに、サーバにおいて、サーバに実装されたコンポーネントによって呼出しの処理を実行し、実行した結果を前記呼出しに対応する実行結果として端末装置に返すことを特徴とする。

上記の構成を採用することにより、利用者に意識させることなくモバイル端末のコンテキストとアプリケーションの属性とに応じて、モバイル端末で実行されるそのアプリケーションのバックグラウンド処理について、当該モバイル端末上で実行するかクラウド基盤等のサーバ上で実行するかのいずれか適切な環境での実行が可能になる。すなわち、バックグラウンド処理について、コンテキスト・アウェアな分散処理を行うことが可能になる。その結果、バックグラウンド処理時にモデルコンポーネント（Ａｎｄｏｒｏｉｄ（登録商標）ＯＳであればServiceコンポーネント）をモバイル端末上で動作させなくて済むようになって、モバイル端末の省電力化を図ることができ、サーバが有する豊富なリソース（計算能力、回線帯域、メモリ容量など）を利用することができてバックグラウンド処理の高速化を図ることができる。また、バックグラウンド処理がモバイル端末上で動作していることに伴って他のアプリケーションの動作速度が低下することも防止できる。

本発明の実施の一形態の分散処理方法が適用されるシステムの全体構成の一例を示すブロック図である。本発明の実施の一形態の分散処理方法を説明する図である。モバイル端末及びサーバの実装例を説明する図である。従来のアプリケーションの構成を示す図である。第１の具体例を説明する図である。アプリケーション実行の従来の処理を示すシーケンス図である。第１の具体例におけるアプリケーション実行の処理を示すシーケンス図である。 ProxyクラスとStubクラスを有するアプリケーションの構成を示す図である。第２の具体例を説明する図である。第２の具体例におけるアプリケーション実行の処理を示すシーケンス図である。

図１は、本発明の実施の一形態のアプリケーション実行方法が適用されるシステムの全体構成を示している。ネットワーク１０に対し、１または複数のモバイル端末２０と１または複数のサーバ３０が接続している。各モバイル端末２０は、リチウムイオン電池などの二次電池で駆動され無線によってネットワーク１０に接続する物理デバイスである。サーバ３０は、例えば、クラウド基盤上のものとして構成することができる。本実施形態では、モバイル端末２０におけるアプリケーション（ＡＰ）のバックグラウンド処理をコンテキスト・アウェアにサーバ３０上で実行させることにより、分散処理を実現している。

本実施形態においては、モバイル端末２０のアプリケーションとして、ＭＶＣ（モデル・ビュー・コントロール；ＭＶＣ）などのデザインパターンにより、ユーザインターフェース（ビュー及びコントロール）のコンポーネントと内部処理（モデル）のコンポーネントが容易に分割可能なものであるとする。ここでは、モバイル端末２０にある既存実行環境を本発明に基づいて改造し、サーバ３０にも同等な実行環境を導入し、モバイル端末２０のアプリケーションをサーバ３０の環境にもインストールして実行できるようにしている。

図２は、本実施形態におけるモバイル端末２０とサーバ３０の論理的な構成を示している。モバイル端末２０において、モバイルＯＳによって実現される実行環境２１が設けられており、実行環境２１の上位にアプリケーション２２が位置する。アプリケーション２２は、ＭＶＣのデザインパターンによるものであって、ビュー及びコントロールのコンポーネントとモデルのコンポーネントから構成されている。また、実行環境２１の下位には、ハードウェアコンポーネントとして、ＧＰＳ（全地球測位システム；Global Positioning System）センサや電池残量計、加速度センサなどの各種のセンサ２３と、アプリケーション２２の実行に関連したデータ等を格納するストレージ（記憶装置）２４とが設けられている。ストレージ２４は、例えば、フラッシュメモリを有するメモリカードなどによって構成される。同様にサーバ３０には、そのＯＳによって実現される実行環境３１が設けられており、実行環境３１の上位に、モバイル端末２０のアプリケーション２２と同等のアプリケーション３２が位置する。実行環境２１の下位には、ハードウェアコンポーネントとしてセンサをシミュレートする仮想センサ３３と、アプリケーション３２の実行に関連したデータ等を格納するストレージ（記憶装置）３４とが設けられている。ストレージ３４は、例えば、ＨＤＤ（ハードディスク装置）によって構成される。

従来のモバイル端末では、その実行環境に、アプリケーションにおけるビュー及びコントロールのコンポーネントからモデルのコンポーネントへの関数呼出し（あるいはメソッド呼出し）及びプロセス間通信の機能が設けられている。本実施形態では、モバイル端末２０の実行環境２１におけるこの機能に、モバイル端末２０のコンテキストとアプリケーション２２の属性とに応じて呼出し先（及び通信先）を動的に切り替える仕組みである切替部２５を追加する。具体的には、例えば、切替部２５を備えるようにモバイルＯＳを改造すればよい。モバイル端末２０のコンテキストとは、モバイル端末２０の所在地（ＧＰＳあるいは無線ＬＡＮ情報から取得）、回線状況、電池残量、メモリ残量、ストレージ残量、実行中プロセス数、利用者のプレゼンスなどの様々な状況である。これらのコンテキストは、例えばセンサ２３から取得されるものであったり、モバイルＯＳに本来備えられている機能によって取得されるものであったりする。アプリケーション２２の属性とは、アプリケーション２２が利用するリソース、実装された機能、実行時間（システム情報により集計）などのことである。

呼出し先（及び通信先）を動的に切り替える切替部２５は、モバイル端末のコンテキストとアプリケーションの属性とに基づいて評価を行い、アプリケーション２２のバックグラウンド処理をモバイル端末２０自体で実行するべきか、サーバ３０側で実行するべきかを決定する。具体的には、下記の判定結果（１）〜（３）のいずれかが真（ＴＲＵＥ）となった場合に、サーバ３０側で処理させる。

（１）［モバイル端末で実行した場合の時間］＞［サーバで実行した場合の時間＋伝送遅延＋データ転送時間］；
（２）［モバイル端末で実行した場合の電池消費率］＞［サーバで実行させるためのバッテリー消費率（分散処理に伴うネットワーク転送のオーバーヘッドなど）］；
（３）［モバイル端末で実行した場合の実行終了時の電池消費率見込み］＜０％＜［サーバで実行するための事前準備としてモバイル端末からサーバへのデータ転送が終了した時の電池消費率見込み］。

サーバ３０側で処理すると決定したら、切替部２５は、呼出し先をサーバ３０側のアプリケーション３２のモデルに指定し、サーバ３０側で処理させる。ネットワーク１０に複数のサーバ３０が接続していてそのいずれのサーバ３０もバックグラウンド処理を実行可能である場合には、切替部２５は、それらのサーバ３０の中から最適な（例えば、モバイル端末から見て最寄りである、あるいは、特定のバックグラウンド処理に特化しているなど）サーバを選択することが好ましい。このように最適なサーバを選択することによって、伝搬遅延の最小化や処理のさらなる高速化を達成することができる。例えば、モバイル端末２０のセンサ２３としてＧＰＳセンサが設けられているとして、ＧＰＳセンサからのＧＰＳ情報（例えばモバイル端末２０の所在地の経緯度情報）により、利用者が利用可能なサーバの所在地（ＧＰＳ情報）一覧からそのモバイル端末に最寄りのサーバを選択し、選択したサーバ上でのモデルのコンポーネント（すなわちバックグラウンド処理）を実行させることにより、ネットワーク転送遅延を最小限に抑えることができる。

モバイル端末２０のストレージ２４はアプリケーション２２の実行に関連したデータ等を格納し、サーバ３０のストレージ３４はアプリケーション３２の実行に関連したデータ等を格納しているから、モバイル端末２０が起動されているときにそのストレージ２４を常にサーバ３０側のストレージ３４と同期させ、さらにサービス利用時などに必要に応じてモバイル端末２０でのセンサ情報（ＧＰＳ、傾き、方位、加速度などのセンサ２３で得られる情報）をサーバ３０に転送させて仮想センサ３３で得られた情報とすることにより、モデルコンポーネントの処理（バックグラウンド処理）をモバイル端末２０で実行してもサーバ３０で実行しても同じ結果が得られる。

また、モバイル端末２０においてバックグラウンド処理を実行すると決定したら、切替部２５は、呼出し先をモバイル端末２０側のモデルのコンポーネントに指定し、ローカルで処理させる。これにより、モバイル端末２０がサーバ３０からオフラインの状態にあるときでも、アプリケーション２２の実行が可能になる。

図３は、モバイル端末２０とサーバ３０との間でストレージ２４，３４の同期を実現するためのソフトウェアの実装例を示している。モバイル端末２０もサーバ３０も、ソフトウェア階層として、カーネル２６，３６の上にライブラリがあり、ライブラリの上にアプリケーション２２，３２が位置している。モバイル端末２０においてライブラリには、汎用のライブラリｌｉｂｃとキャッシュ動作を実現するライブラリＥＣＳが含まれている。カーネル２６には、ファイル関係の機能として、ＶＦＳ（仮想ファイルシステム；Virtual File System）とＬｉｎｕｘ（登録商標）の１モジュールであるＦｕｓｅ(Filesystem in Userspace)が実装されている。アプリケーション２２は、ファイルアクセスに際しては、ファイルＡＰＩによりＶＦＳにアクセスする。このアクセスは、ＶＦＳからＦｕｓｅを介してライブラリＥＣＳに送られ、その結果、ライブラリＥＣＳを介して、モバイル端末２０のストレージ２４とサーバ３０のストレージ３４との間で、ストレージの同期が達成される。ここで示す例では、ローカルキャッシュとＮＦＳ（ネットワークファイルシステム；Network File system）とを組み合わせたファイルシステムを構築することで、ＳＱＬｉｔｅなどのアプリケーション特有ファイルについてのストレージ同期を実現している。ここに示したもの以外にも、ローカルのストレージとリモートのストレージとを同期させる手法として数多くのものが知られているから、それらの手法を用いてストレージ２４，３４を同期させるようにしてもよい。

次に、モバイル端末２０における実行環境２１を構成するモバイルＯＳがＡｎｄｒｏｉｄ（登録商標）ＯＳである場合を例に挙げて、本実施形態の具体例を説明する。図４は、この場合のモバイルＯＳ上で動作する従来のアプリケーションの構成を示している。ここではＡｎｄｒｏｉｄ（登録商標）ＯＳを前提としているから、アプリケーションは、ビュー及びコントロールに相当しユーザインタフェースを担当するActivityコンポーネントと、モデルに相当しバックグラウンド処理を担当するServiceコンポーネントから構成される。実行環境としてのカーネル２６には、メソッド呼出し（例えばActivityコンポーネントからServiceコンポーネントの呼出し）及びプロセス間通信を実行するBinder Driverが設けられている。Activityは、Binder Driverにより、呼び先のServiceの機能を定義するインターフェースとバインドする。なお図４及びそれ以降の図面において、モバイル端末２０のカーネル２６の中にセンサ２３及びストレージ２４が設けられ、カーネル３６の中に仮想センサ３３及びストレージ３４が設けられているように記載されているが、これらは、カーネルの中に物理デバイスとしてのセンサ、仮想センサ及びストレージが設けられていることを意味するのではなく、カーネルを介してセンサ、仮想センサ及びストレージにアクセスできることを意味している。

ここでは、具体例を２つ提示する。図５〜図７は第１の具体例を説明するためのものであり、図８〜図１０は第２の具体例を説明するものである。

第１の具体例は、ＯＳのカーネルを改造することを前提とし、そのため、モバイル端末は専用ＯＳ端末となるが、アプリケーションのバイトコードには改変を要さず、既存のアプリケーションをそのまま使用できるものである。

図５に示すように、第１の具体例では、モバイル端末２０でのカーネル２６におけるBind Driverを本発明の分散実行方法に適合するように改造し、サーバ３０においてモバイル端末２０と同等な、改造したBinder Driver（図において「Binder Driver（独自）」と表記）を備えたＯＳの環境を導入する。また、モバイル端末２０にあるアプリケーション２２と同じアプリケーション３２をサーバ３０の環境にもインストールする。本来、同じアプリケーションのActivityコンポーネントとServiceコンポーネンツトとは同一の端末に存在することが前提されているが、上述のように改造したBinder Driverにより、インターネットなどのネットワークを経由してモバイル端末２０のActivityをサーバ３０のServiceにバインドさせることを可能とする。モバイル端末２０のBinder Driverは、メソッド呼出しの呼出し先を切り替える切替手段として機能する。さらに、モバイル端末２０とサーバ３０との間でストレージ２４，３４を同期させ、センサ情報も同期させることにより、サーバ３０においてモバイル端末２０のコンテキストを把握、利用することを可能とする。これらによって、サーバ３０側のServiceコンポーネントは、モバイル端末２０のServiceコンポーネントと同等な実行結果を得ることができる。

図６は、改造を行っていない従来のBind Driverを用いた場合の処理を示している。ActivityはBinder Driver経由でServiceのメソッドを呼び出す（ステップ１０１）。Binder Driverは、呼出命令をServiceにリレーし（ステップ１０２）、Serviceの実行結果を取得して（ステップ１０３）それをActivityに返す（ステップ１０４）。

図７は、第１の具体例において改造されたBind Driverを用いた場合の処理を示している。モバイル端末２０のActivityはBinder Driver経由でServiceのメソッドを呼び出す（ステップ１１１）。この時、モバイル端末２０の改造されたBinder Driverは、モバイル端末２０のコンテキスト（様々な周辺状況）とアプリケーションの属性情報（AndroidManifest.xmlファイルに記載されている情報）とを評価し、モバイル端末２０で実行するべきかサーバ３０側で処理するべきかどうか判断する（ステップ１１２）。モバイル端末２０のコンテキストとは、例えば、（ＧＰＳあるいは無線ＬＡＮ情報に基づく）モバイル端末２０の所在地、回線状況、方位、温度、電池残量、メモリ残量、ストレージ残量、実行中プロセス数、利用者のプレゼンスなどのことである。アプリケーションの属性情報とは、利用するリソース、実装された機能、実行時間（システム情報により集計）など、アプリケーションに対するServiceに関する情報である。ステップ１１１での判断では、具体的には、例えば、下記の判定結果（１）〜（３）にいずれかが真（ＴＲＵＥ）となった場合に、サーバ側３０で処理させるものとする。これらの評価は、Serviceを呼出すごとに実施する。評価基準自体は複数のアプリケーションにおいて共通である。

モバイル端末２０を所持している利用者がその現在地を移動するなどのコンテキストの変化に応じ、モバイル端末２０側かサーバ３０側かの評価結果は適宜変化する可能性があるが、サーバ３０側でのServiceが完了しない限り、コンテキストの条件としてはモバイル端末２０側の処理が適しているとなっても、実行中のServiceについては、モバイル端末２０上での処理には移行しない。ただし、モバイル端末２０がサーバ３０から完全にオフラインになった場合には、Serviceの処理はモバイル端末２０に移行する。

コンテキストの例としては、以下のようなものが挙げられる：
例）モバイル端末２０内のプロセス数が多い、あるいはメモリ残量が少ない時、モバイル端末２０で処理を実行した場合の時間が長引いてしまうため、呼出し先をサーバ３０に指定する；
例）ネットワーク転送量の大きいServiceは、使用するネットワークの転送能力に応じ、転送能力の小さいネットワーク（例えば３Ｇ回線）の使用時にはモバイル端末２０側で実行するが、転送能力の大きなネットワーク（例えばＷｉ−Ｆｉネットワーク）へのアクセスが可能になった場合に、呼出し先にサーバ３０に指定する；
例）回線状況の悪い場合、呼出し先をモバイル端末２０に指定する。

ステップ１１２においてモバイル端末２０で処理するべきと判断した場合、Binder Driverは、従来のものと同様に、モバイル端末２０のServiceに呼出し命令をリレーし（ステップ１１３）、Serviceのからの実行結果を受け取って（ステップ１１４）、Activityに返す（ステップ１１５）。

一方、ステップ１１２においてサーバ３０側で処理するべきと判断した場合には、モバイル端末２０のBinder Driverは、ネットワーク経由で所定のサーバ３０内のBinder Driverに対して呼出し命令を転送する（ステップ１１６）。サーバ３０内のBinder Driverは、同じサーバ３０内部にあるServiceに呼出し命令をリレーする（ステップ１１７）。このServiceでの実行結果は、サーバ３０のBinder Driverとモバイル端末２０のBinder Driverとを経由して、モバイル端末２０のActivityに返される（ステップ１１８〜１２０）。なお、サーバ３０内のBinder Driverも本発明に適合するように改造されており、モバイル端末２０から呼出しを受けたときにサーバ３０においてServiceコンポーネントを実行して実行結果をモバイル装置２０に返す制御手段として機能する。

次に、図８〜図１０によって第２の具体例を説明する。

第２の具体例では、ＯＳのカーネルを改造せず、汎用のモバイル端末に本発明を適用するものである。そのため実行させるようとする既存のアプリケーションに手を加えるとともに、本実施形態に基づくロジックが実装された専用アプリケーション２７を予めモバイル端末２０にインストールしておく。既存のアプリケーションについては、そのソースコード自体を改修する必要はないが、実行コード（インストールファイル）を生成する際に、本発明に対応した専用ツールを使用するようにする。

従来、Ａｎｄｒｏｉｄ（登録商標）ＯＳ上で動作するアプリケーションを開発する場合、アプリケーションのServiceコンポーネントが提供する機能については、ＡＩＤＬ(Android Interface Definition Language)ファイルで定義する。開発環境のＡＩＤＬツールを使用すると、ＡＩＤＬファイルから、Proxyと呼ばれるクラス（ActivityがServiceを呼び出すためのクラス）とStubと呼ばれるクラス（ServiceがActivityからの要求を受け取るためのクラス）が生成される。そして、Serviceのソースコードをコンパイルすると、これらのクラスも一緒にコンパイルされる。図８に示すように、モバイル端末２０にアプリケーションとしてServiceをインストールすると、ProxyはActivityコンポーネントに配布される。Activityは、Proxy経由でStubを呼出し、Serviceの様々な機能を利用する。

図９は、第２の具体例の全体構成を示している。第２の具体例では、実行させようとするアプリケーションの開発時に本発明に対応した専用ＡＩＤＬツールを使用することと、本発明に基づくロジックが実装された専用アプリケーション２７，３７を予めモバイル端末２０及びサーバ３０にそれぞれインストールしておくこととを前提としている。

専用ＡＩＤＬツールは、ＡＩＤＬファイルから、本発明に基づいた独自Proxyクラスと独自Stubクラスを生成する。ＡＩＤＬファイル自体は、本発明を意識することなく記述することが可能であり、したがって、既存のアプリケーションを本発明に対応させる際に改変する必要はない。専用ＡＩＤＬツールによって生成される独自Proxyクラスでは、直接にServiceのStubを呼び出さず、専用アプリケーション２７のStubを呼び出すように改造されている。専用アプリケーション２７は、そのStubが呼び出されたときに、モバイル端末２０のコンテキスト（様々な周辺状況）とアプリケーションの属性情報（AndroidManifest.xmlファイル）とを評価し、呼び出されたStubに対応するServiceのメソッドをサーバ３０側で処理すべきかモバイル端末２０で処理すべきかを判断するものである。

図１０は、第２の具体例での処理を示している。モバイル端末２０のActivityはカーネル２６のBinder Driver経由でServiceのメソッドを呼び出す（ステップ１３１）。このとき、Activityの独自Proxyは専用アプリケーション２７のStubを呼び出すように構成されるから、呼出し命令はカーネル２６から専用アプリケーション２７に送られる（ステップ１３２）。専用アプリケーション２７は、モバイル端末２０のコンテキストとアプリケーションの属性情報とを評価し、モバイル端末２０で実行するべきかサーバ３０側で処理するべきかどうか判断する（ステップ１３３）。モバイル端末２０のコンテキストの例やステップ１３３での判断基準などは、第１の具体例と同様である。

ステップ１３３においてモバイル端末２０で処理するべきと判断した場合、専用アプリケーション２７は、モバイル端末２０のServiceに呼出し命令をリレーし（ステップ１３４）、Serviceからの実行結果は、カーネル２６のBinder Driverを経由してActivityに返される（ステップ１３５〜１３６）。

一方、ステップ１３３においてサーバ３０側で処理するべきと判断した場合には、モバイル端末２０の専用アプリケーション２７は、ネットワーク経由で所定のサーバ３０内の専用アプリケーション３７に対して呼出し命令を転送する（ステップ１３７）。サーバ３０内の専用アプリケーション３７は、同じサーバ３０内部にあるServiceに呼出し命令をリレーする（ステップ１３８）。このServiceでの実行結果は、サーバ３０の専用アプリケーション３７とモバイル端末２０の専用アプリケーション２７及びBinder Driverとを経由して、モバイル端末２０のActivityに返される（ステップ１３９〜１４１）。

専用アプリケーション２７，３７は、基本ロジックとしては第１の具体例での独自のBind Driverと同等のものであるが、実装されるレイヤがカーネルでなくてアプリケーションレイヤであるから、ＯＳのカーネルを改造することなく、汎用のモバイル端末にも導入可能である。

以上、本発明の好ましい実施形態を説明したが、モバイル端末もサーバもハードウェアとしてはコンピュータそのものであるから、上述したモバイル端末及びサーバのいずれの機能もコンピュータ上でプログラムを実行させることによっても実現できる。

例えば、モバイル端末２０は、ユーザインタフェースに係る処理を実行する第１のコンポーネントと内部処理を実行する第２のコンポーネントとが分離して実装されているアプリケーションを実行し、第２のコンポーネントに相当するコンポーネントを実装したサーバ３０に対してネットワークを介して接続したコンピュータに、そのコンピュータにおいてアプリケーションの実行に係るデータを格納するストレージとサーバ３０のストレージとの間でデータを同期させる処理と、第１のコンポーネントから第２のコンポーネントに対する呼出しがあったときに、そのコンピュータでのコンテキストとアプリケーションの属性とに基づき、第２のコンポーネントの処理をそのコンピュータにおいて実行するかサーバ３０において実行するかを判断し、判断の結果に応じて、呼出しの呼出し先をそのコンピュータの第２のコンポーネントとサーバ３０との間で切り替える処理と、を実行させるプログラムを読み込ませ、このプログラムを実行させることによって実現できる。

同様にサーバ３０は、ユーザインタフェースに係る処理を実行する第１のコンポーネントと内部処理を実行する第２のコンポーネントとが分離して実装されているアプリケーションを実行するモバイル端末２０に対してネットワークを介して接続するコンピュータに、そのコンピュータのストレージをモバイル端末２０においてアプリケーションの実行に係るデータを格納するストレージに同期させる処理と、モバイル端末２０から呼出しを受けたときに、第２のコンポーネントに対応するコンポーネントを実行して実行結果をモバイル端末２０に返す処理と、を実行させるプログラムを読み込ませ、このプログラムを実行させることによって実現できる。

１０ネットワーク
２０モバイル端末
２１，３１実行環境
２２，３２アプリケーション
２３センサ
２４，３４ストレージ
２５判定部
２６，３６カーネル
２７，３７専用アプリケーション
３０サーバ
３３仮想センサ

Claims

ユーザインタフェースに係る処理を実行する第１のコンポーネントと内部処理を実行する第２のコンポーネントとが分離して実装されているアプリケーションを実行する処理装置において、
前記アプリケーションの実行に係るデータを格納するストレージと、
前記第１のコンポーネントから前記第２のコンポーネントに対する呼出しがあったときに、前記処理装置のコンテキストと前記アプリケーションの属性とに基づき、前記第２のコンポーネントの処理を前記処理装置において実行するか、ネットワークを介して前記処理装置に接続して前記第２のコンポーネントと同じコンポーネントを実装したサーバにおいて実行するかを判断し、前記判断の結果に応じて、前記呼出しの呼出し先を前記処理装置の前記第２のコンポーネントと前記サーバとの間で切り替える切替手段と、
前記処理装置の前記ストレージと前記サーバのストレージとの間でデータを同期させる同期手段と、
を有し、
前記ネットワークに複数の前記サーバが接続し、前記切替手段は、前記第２のコンポーネントの処理に関して前記複数のサーバの内のうち、前記処理装置の最寄りのサーバを最適なサーバとして選択して前記呼出し先に指定することを特徴とする処理装置。
前記処理装置のコンテキストを構成するデータの少なくとも１つを検出するセンサをさらに備える、請求項１に記載の処理装置。
ユーザインタフェースに係る処理を実行する第１のコンポーネントと内部処理を実行する第２のコンポーネントとが分離して実装されているアプリケーションを実行する端末装置と、複数の処理装置とがネットワークを介して接続しているシステムにおける処理装置において、
前記第２のコンポーネントと同じコンポーネントが実装されており、
前記端末装置に設けられるストレージと同期したストレージと、
前記端末装置から呼出しを受けたときに前記実装されたコンポーネントを実行し、実行した結果を前記呼出しに対応する実行結果として前記端末装置に返す制御手段と、
を有し、
前記端末装置において前記第１のコンポーネントから前記第２のコンポーネントに対する呼出しがあり、前記端末装置のコンテキストと前記アプリケーションの属性とに基づき前記端末装置が前記第２のコンポーネントを前記複数の処理装置のいずれかにおいて実行すると判断して最適な処理装置として当該処理装置を選択した場合に、前記端末装置から呼び出されることを特徴とする処理装置。
ユーザインタフェースに係る処理を実行する第１のコンポーネントと内部処理を実行する第２のコンポーネントとが分離して実装されているアプリケーションを実行する端末装置と、サーバとを有し、前記端末装置と前記サーバとがネットワークを介して接続しているシステムにおける処理方法において、
前記第２のコンポーネントと同じコンポーネントを前記サーバに実装することと、
前記端末装置において前記アプリケーションの実行に係るデータを格納するストレージと前記サーバのストレージとを同期させることと、
前記端末装置において前記第１のコンポーネントから前記第２のコンポーネントに対する呼出しがあったときに、前記端末装置のコンテキストと前記アプリケーションの属性とに基づき、前記第２のコンポーネントの処理を前記端末装置において実行するか前記サーバにおいて実行するかを判断し、前記判断の結果に応じて、前記呼出しの呼出し先を前記端末装置の前記第２のコンポーネントと前記サーバとの間で切り替えることと、
前記サーバが前記呼出し先に指定されたときに、前記サーバにおいて、前記サーバに実装された前記コンポーネントによって前記呼出しの処理を実行して結果を前記端末装置に返すことと、
を有し、
前記ネットワークに複数の前記サーバが接続し、前記端末装置において、前記第２のコンポーネントの処理に関して前記複数のサーバの内のうち、前記処理装置の最寄りのサーバを最適なサーバとして選択して前記呼出し先に指定することを特徴とする、処理方法。
ユーザインタフェースに係る処理を実行する第１のコンポーネントと内部処理を実行する第２のコンポーネントとが分離して実装されているアプリケーションを実行し、前記第２のコンポーネントと同じコンポーネントを実装したサーバに対してネットワークを介して接続したコンピュータに、
前記コンピュータにおいて前記アプリケーションの実行に係るデータを格納するストレージと前記サーバのストレージとの間でデータを同期させるために、前記コンピュータにおいて必要となる処理と、
前記第１のコンポーネントから前記第２のコンポーネントに対する呼出しがあったときに、前記コンピュータでのコンテキストと前記アプリケーションの属性とに基づき、前記第２のコンポーネントの処理を前記コンピュータにおいて実行するか前記サーバにおいて実行するかを判断し、前記判断の結果に応じて、前記呼出しの呼出し先を前記処理装置の前記第２のコンポーネントと前記サーバとの間で切り替える処理と、
を実行させ、
さらに前記ネットワークに複数の前記サーバが接続しており、前記コンピュータに、前記第２のコンポーネントの処理に関して前記複数のサーバの内のうち、前記処理装置の最寄りのサーバを最適なサーバとして選択して前記呼出し先に指定する処理を実行させるプログラム。
ユーザインタフェースに係る処理を実行する第１のコンポーネントと内部処理を実行する第２のコンポーネントとが分離して実装されているアプリケーションを実行する端末装置と、複数のコンピュータとがネットワークを介して接続しているシステムにおけるコンピュータに、
前記コンピュータのストレージを前記端末装置において前記アプリケーションの実行に係るデータを格納するストレージに同期させるために、前記コンピュータにおいて必要となる処理と、
前記端末装置から呼出しを受けたときに、前記第２のコンポーネントと同じコンポーネントを実行し、実行した結果を前記呼出しに対応する実行結果として前記端末装置に返す処理と、
を実行させ、
前記コンピュータは、前記端末装置において前記第１のコンポーネントから前記第２のコンポーネントに対する呼出しがあり、前記端末装置のコンテキストと前記アプリケーションの属性とに基づき前記端末装置が前記第２のコンポーネントを前記ネットワークに接続された前記複数のコンピュータのいずれかにおいて実行すると判断して、前記処理装置の最寄りのコンピュータを最適なコンピュータとして当該コンピュータを選択した場合における、前記端末装置からの呼び出しを待ち受ける処理を実行させる、プログラム。