(57)【要約】【課題】ネットワークから情報を取得する端末装置の電力消費を抑制する。【解決手段】ネットワークシステムは、サーバ装置（２００）と、端末装置（１００）と、サーバ装置および端末装置と通信する通信装置と、を備える。通信装置は、端末装置のサーバ装置との周期的通信を含む機能をエミュレーションするためのエミュレート部と、端末装置との通信が可能な通信可能状態において、エミュレート部のエミュレーションに従って、サーバ装置と通信するサーバ通信部と、サーバ通信部がサーバ装置から受信するデータを含む応答内容と予め定めた条件との比較から、端末装置に要求を送信する端末送信部と、を含む。端末装置は、通信可能状態においてサーバ装置との周期的通信を保留する保留部を含み、端末送信部から要求を受信すると、保留されていたサーバ装置との周期的通信を実行する。【選択図】図１
2014082571.tif 000002
【特許請求の範囲】
【請求項１】
サーバ装置と、
端末装置と、
前記サーバ装置および前記端末装置と通信する通信装置と、を備え、
前記通信装置は、
前記端末装置の前記サーバ装置との周期的通信を含む機能をエミュレーションするためのエミュレート部と、
前記端末装置との通信が可能な通信可能状態において、前記エミュレート部のエミュレーションに従って、前記サーバ装置と通信するサーバ通信部と、
前記サーバ通信部が前記サーバ装置から受信するデータを含む応答内容と予め定めた条件との比較から、前記端末装置に要求を送信する端末送信部と、を含み、
前記端末装置は、
前記通信可能状態において前記サーバ装置との前記周期的通信を保留する保留部を含み、
前記端末送信部から前記要求を受信すると、保留されていた前記サーバ装置との前記周期的通信を実行する、ネットワークシステム。
【請求項２】
前記端末装置は、複数種類の出力デバイスを有し、
前記通信装置は、前記応答内容から、前記データを出力するべき出力デバイスの種類を決定し、
前記予め定めた条件は、前記端末装置への要求の送信を許可する出力デバイスの種類を含む、請求項１に記載のネットワークシステム。
【請求項３】
前記予め定めた条件は、前記応答内容のデータ量に関する閾値を含む、請求項１または２に記載のネットワークシステム。
【請求項４】
前記端末送信部は、
前記通信可能状態において所定時間を計時するタイマを有し、
前記タイマが所定時間を計時したとき、前記端末装置に前記要求を送信する、請求項１から３のいずれかに記載のネットワークシステム。
【請求項５】
前記端末送信部は、
前記要求が検出されてから一定時間内に他の前記要求が検出されるとき、前記一定時間の経過後に、これら要求を前記端末装置に送信する、請求項１から４のいずれかに記載のネットワークシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はネットワークシステムに関し、特に、サーバ装置からデータを受信し、受信データを用いた処理機能を有する端末装置を備えるネットワークシステムに関する。
【背景技術】
【０００２】
スマートフォン（多機能携帯電話）などの携帯端末では、通信ネットワーク上のWeb（World Wide Webの略）サーバに対して、携帯端末から定期的にWebサーバに対しポーリングを実行し、Webサーバからの応答を受信する。受信した応答が変化したことを判定したとき、携帯端末は受信応答に従い内部データの更新や表示の更新を実行する場合が多い。
【０００３】
携帯端末側にはWebブラウザ単体だけではなく、Java（登録商標）言語などで記述された高機能なアプリケーションプログラムが提供されることも多い。また、Webブラウザの機能を使用あるいは包含することなく自アプリケーションプログラムで（独自に）通信ネットワークへの定期的なポーリングを行い、データまたは表示の更新を実行する携帯端末もある。
【０００４】
たとえば、特許文献１（特開２００４-１３５１５２号公報）では携帯端末側の契機でデータをチェックまたは更新する必要があるかを判断するために、携帯端末はネットワーク側のWebサーバにアクセスするためにリクエストを発行する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００４-１３５１５２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
したがって、データをチェックし更新の必要を判断するために、繰返しリクエストすることになるため、携帯端末では消費電力が増加する。特に、実際にネットワーク側にアクセスした結果、ユーザの目に見える形で表示態様の変化を行う必要がない場合があり、こうした場合であってもリクエストする必要があり、電力の無駄遣いになる。
【０００７】
それゆえに本発明の目的は、ネットワークから情報を取得する端末装置の電力消費を抑制するネットワークシステムに関する。
【課題を解決するための手段】
【０００８】
この発明のある局面に従うネットワークシステムは、サーバ装置と、端末装置と、サーバ装置および端末装置と通信する通信装置と、を備える。通信装置は、端末装置のサーバ装置との周期的通信を含む機能をエミュレーションするためのエミュレート部と、端末装置との通信が可能な通信可能状態において、エミュレート部のエミュレーションに従って、サーバ装置と通信するサーバ通信部と、サーバ通信部がサーバ装置から受信するデータを含む応答内容と予め定めた条件との比較から、端末装置に要求を送信する端末送信部と、を含む。端末装置は、通信可能状態においてサーバ装置との周期的通信を保留する保留部を含み、端末送信部から要求を受信すると、保留されていたサーバ装置との周期的通信を実行する。
【０００９】
好ましくは、端末装置は、複数種類の出力デバイスを有し、通信装置は、応答内容から、データを出力するべき出力デバイスの種類を決定し、予め定めた条件は、端末装置への要求の送信を許可する出力デバイスの種類を含む。
【００１０】
好ましくは、予め定めた条件は、応答内容のデータ量に関する閾値を含む。
好ましくは、端末送信部は、通信可能状態において所定時間を計時するタイマを有し、タイマが所定時間を計時したとき、端末装置に要求を送信する。
【００１１】
好ましくは、端末送信部は、要求が検出されてから一定時間内に他の要求が検出されるとき、一定時間の経過後に、これら要求を端末装置に送信する。
【発明の効果】
【００１２】
本発明によれば、ネットワークから情報を取得する端末装置は、サーバ装置との周期的通信を通信装置のエミュレート部に代行させて、エミュレート部からの要求があったときのみ、保留していた周期的通信を行うので、電力消費量を少なくすることができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施の形態に係るシステム構成図である。
【図２】本発明の実施の形態に係る端末装置の構成図である。
【図３】本発明の実施の形態に係るサーバ装置の構成図である。
【図４】本発明の実施の形態に係るゲートウェイ装置の構成図である。
【図５】本発明の実施の形態に係るソフトウェアの構成を示す図である。
【図６】本発明の実施の形態に係る周期タイマリストを例示する図である。
【図７】本発明の実施の形態に係るタイマ割込発生時の処理フローチャートである。
【図８】本発明の実施の形態に係るタイマ割込発生時の処理フローチャートである。
【図９】本発明の実施の形態に係る割込発生を説明する図である。
【図１０】本発明の実施の形態に係る仮想環境が『起床状態』に遷移するためのタイマ割込みを説明する図である。
【図１１】本発明の実施の形態１に係る動作の概要を模式的に説明する図である。
【図１２】本発明の実施の形態に係るサーバ装置との通信処理を模式的に示す図である。
【図１３】本発明の実施の形態１に係る端末装置で同期を取るための動作を説明するための図である。
【図１４】本発明の実施の形態に係るタイマデータの登録処理のフローチャートである。
【図１５】本発明の実施の形態に係るハードウェアタイマとその周辺構成を示すブロック図である。
【図１６】本発明の実施の形態に係る仮想環境における周期タイマリストへの登録処理のフローチャートである。
【図１７】本発明の実施の形態に係る端末装置の電力管理ハードウェアの状態遷移を示す図である。
【図１８】本発明の実施の形態に係る仮想環境の仮想電力管理ハードウェアの動作を模式的に示す図である。
【図１９】本発明の実施の形態に係る仮想環境内で描画要求が起こった場合の処理フローチャートである。
【図２０】本発明の実施の形態に係る保留タイマリストの一例を示す図である。
【図２１】本発明の実施の形態に係る端末装置が仮想環境から起床要求を受理した場合の処理フローチャートである。
【図２２】本発明の実施の形態に係る保留タイマリストの参照結果から、イベントを発行する処理フローチャートである。
【図２３】本発明の実施の形態２に係る仮想環境において発生する要求のレベル定義をテーブル形式で示す図である。
【図２４】本発明の実施の形態２に係る仮想環境内でアプリから描画要求が起こった場合の処理フローチャートである。
【図２５】本発明の実施の形態３に係る不揮発メモリのブロック毎の使用目的をテーブル形式で示す図である。
【図２６】本発明の実施の形態３に係る不揮発メモリへの書込み先と起床要求の出力可否とを関連付けて示すテーブルの図である。
【図２７】本発明の実施の形態３に係る仮想環境におけるファイル更新要求の処理フローチャートである。
【図２８】本発明の実施の形態３に係る不揮発メモリへの書込み先と起床要求の出力可否とを関連付けて示す他のテーブルの図である。
【図２９】本発明の実施の形態３に係る仮想環境におけるファイル更新要求の処理フローチャートである。
【図３０】本発明の実施の形態４に係る仮想環境において発生する書込み要求について起床要求を送信するか否かを判定するための参照テーブルを示す図である。
【図３１】本発明の実施の形態４に係る仮想電力管理ハードウェアの状態遷移を示す図である。
【図３２】本発明の実施の形態４に係る仮想環境内でファイル更新要求が起こった場合の処理フローチャートである。
【図３３】本発明の実施の形態４に係る仮想環境内でファイル更新要求が起こった場合の他の処理フローチャートである。
【図３４】本発明の実施の形態５に係る動作を説明する図である。
【図３５】本発明の実施の形態５に係るタイムラグの短縮を説明するグラフである。
【図３６】本発明の実施の形態５に係るタイムラグの短縮を説明するグラフである。
【図３７】本発明の実施の形態６に係る端末装置のＣＰＵの負荷と消費電力量の時間変化を示すグラフである。
【図３８】本発明の実施の形態６に係る仮想環境内でアプリから描画要求が起こった場合の処理フローチャートである。
【図３９】本発明の実施の形態６に係る仮想環境の仮想電力管理ハードウェアの動作を説明するための図である。
【図４０】本発明の実施の形態１に係る概要と効果を説明するための図である。
【図４１】本発明の実施の形態１に係る概要と効果を説明するための図である。
【図４２】本発明の実施の形態１に係る概要と効果を説明するための図である。
【発明を実施するための形態】
【００１４】
以下、本発明の各実施の形態について図面を参照し詳細に説明する。なお、同一の構成要素には各図において同一の符号を付し、詳細な説明は繰返さない。
【００１５】
本実施の形態では、端末装置は、携帯型情報処理端末を想定する。携帯型情報処理端末として、ノートブック型パーソナルコンピュータ、携帯型電話機、スマートフォン、ＰＤＡ（Personal  Digital  Assistant）などを適用することができる。また、端末装置は携帯型に限定されず、据え置き型であってもよい。
【００１６】
本実施の形態で用いる用語について説明する。
端末装置の動作モードには、消費電力が少ない『低電力状態』と低電力状態の消費電力量よりも消費量の多い『起床状態』とが含まれる。
【００１７】
端末装置は、ＣＰＵ（Central Processing Unit）が割込み待ち状態において、ＣＰＵおよび周辺回路へのクロック供給（および／または電源供給）を部分的に断つことにより消費電力を削減し『低電力状態』にする機能を有する。
【００１８】
『低電力状態』からハードウェア的に割込みが入ったとき、ＣＰＵへのクロック供給が再開され、ＣＰＵはソフトウェアに従う処理を再開する。このように、ＣＰＵが処理を開始することにより、消費電力量は先の『低電力状態』より多い『起床状態』となる。『低電力状態』から『起床状態』への遷移を“起床”と呼ぶ。
【００１９】
また、本実施の形態では、各種フラグを用いるが、フラグのセットは、フラグに“１”を設定することであり、フラグのリセットは、フラグに“０”を設定することを言う。
【００２０】
[実施の形態１]
本実施の形態では、端末装置の機能をエミュレーションするためのエミュレート部（以下、仮想環境という）を搭載した装置（仮想マシンとも呼ぶ）を通信ネットワーク上に配置する。端末装置がタイマによって定期的に起床し、サーバ装置に対しポーリングを実行する代わりに、仮想マシンにより起床とサーバ装置へのポーリングを行う。
【００２１】
ポーリングによってサーバ装置から受信する応答内容に基づき、仮想マシンが備える不揮発メモリまたは仮想的なＶＲＡＭ（Video Random Access Memory）へのデータ書込み、または仮想マシンが備える仮想的なオーディオデバイスへのデータ転送が検出されたとき、仮想マシンは端末装置に起床要求を出力し、端末装置を起床させる。これにより、端末装置側のデータまたは表示の更新が必要な場合に限り、端末装置は『起床状態』に遷移するから、仮想マシンを用いることなく端末装置が起床してポーリングする場合に比較して、端末装置が起床する回数が削減されて、端末装置１００の電力消費を抑制することができる。
【００２２】
図１は、本発明の実施の形態に係るシステム構成図である。システムは、複数の端末装置１００、端末装置１００とクライアントして通信するサーバ装置２００、仮想マシンとして機能するゲートウェイ装置３００、ならびにこれらを接続する通信ネットワーク５０および通信網６０を備える。通信ネットワーク５０は、インターネットを含む有線および無線の各種ネットワークを含む。通信網６０は、本実施の形態では無線による通信網としているが、有線を含んでもよい。
【００２３】
本発明の実施の形態では、仮想マシンを搭載する装置として、端末装置１００がサーバ装置２００と通信するために必要なプロトコル変換の機能を備える既存のゲートウェイ装置３００を用いているが、仮想マシンを搭載する装置はゲートウェイ装置に限定されず、通信網において端末装置１００とサーバ装置２００などの異なる装置それぞれと通信可能な既存の通信装置であればよい。
【００２４】
図２は本発明の実施の形態に係る端末装置１００に構成図である。図２を参照して、端末装置１００は、ＣＰＵを有する処理部１０１、ＲＯＭ（Read Only Memory）およびＲＡＭ（Random Access Memory）などを含むメインメモリ・不揮発メモリなどの各種メモリを含む記憶部１０２、ユーザにより操作されて操作内容に従う指示を受け付けるためのキーパッド１０３、通信網６０と通信するためのモデムを含む通信部１０４、ＬＣＤ（Liquid Crystal Display）表示部を含み情報を外部に出力するための出力部１０５、基準周波数信号を発振するためのクロック１０６、図示のないバッテリなどの電源部から各部への電力供給を制御をするための電力管理ハードウェア１０７、音声の収集および出力のためのマイク（マイクロフォンの略）およびスピーカなどを含むオーディオ部１０８、およびＶＲＡＭ１０９を備える。ＶＲＡＭ１０９は、処理部１０１により画像データが書込まれて、ＬＣＤ表示部はＶＲＡＭ１０９から読出す画像データに従ってＬＣＤパネルを駆動することにより、画像を表示する。
【００２５】
通信部１０４は、サーバ装置２００と通信するサーバ通信機能と、ゲートウェイ装置３００と通信する機能を有する。
【００２６】
図３は本発明の実施の形態に係るサーバ装置２００の構成図である。図３を参照してサーバ装置２００は、ＣＰＵを有する処理部２０１、ＲＯＭおよびＲＡＭなどを含むメインメモリ・不揮発メモリなどの各種メモリを含む記憶部２０２、通信ネットワーク５０と通信するためのモデムを含む通信部２０４および基準周波数信号を発振するためのクロック２０６を備える。
【００２７】
図４は本発明の実施の形態に係るゲートウェイ装置３００の構成図である。図４を参照して、ゲートウェイ装置３００は、ＣＰＵを有する処理部３０１、ＲＯＭおよびＲＡＭなどを含むメインメモリ・不揮発メモリなどの各種メモリを含む記憶部３０２、外部から操作されて操作内容に従う指示を受け付けるためのキーパッド３０３、通信網６０および通信ネットワーク５０と通信するためのモデムを含む通信部３０４、および基準周波数信号を発振するためのクロック３０６を備える。
【００２８】
通信部３０４は、サーバ装置２００と通信するためのサーバ通信部と、端末装置１００と通信するための端末通信部を有する。
【００２９】
図５は本発明の実施の形態に係るソフトウェアの構成を示す図である。図５では、図１の端末装置Ａ〜Ｃは同様の構成を有するので、ここでは端末装置Ａに相当する端末装置１００の構成１１０と、ゲートウェイ装置３００に搭載されるエミュレート部である仮想環境３１０の構成を示す。
【００３０】
端末装置１００では実ＯＳ１１２が実ハードウェア１１３上で動作し、アプリ（アプリケーションプログラムの略）１１１が実ＯＳ１１２の制御のもとに実行される。
【００３１】
実ＯＳと、後述のゲストＯＳとは同じＯＳを示すが、ここでは区別するために実ＯＳとゲストＯＳと呼ぶ。また、実ハードウェアと後述の仮想ハードウェアは実質同じハードウェア機能を示すが、ここでは区別するために実ハードウェアと仮想ハードウェアと呼ぶ。
【００３２】
実ハードウェア１１３はハードウェア要素として、ＣＰＵ、メモリの他に不揮発メモリ、ＶＲＡＭ１０９、クロック１０６を含むハードウェアタイマ、および電力管理ハードウェア１０７を含む。
【００３３】
電力管理ハードウェア１０７は、図示しないレジスタの値に基づき端末装置１００内の各ブロックへの電力供給を制御する。ＣＰＵはレジスタの値を書き換える。また、ハードウェアタイマからの基準周波数に基づくクロック信号はＣＰＵの制御により各部に供給される。
【００３４】
実ＯＳ１１２は、ファイルシステム及びウィンドウシステム、ネットワークをアクセスするためのネットワークシステム、周期的な起床をサポートするためのタイマモジュール、メモリの所定領域に格納される周期タイマリスト、保留タイマリストおよび同期フラグを有する。タイマモジュールは、仮想環境３１０とタイマ機能の同期がとられているか否かを判別するために同期フラグをアクセスする。
【００３５】
アプリ１１１は直接実行する形式のものでも、バッチコマンドやスクリプト言語で書かれたものでも良い。アプリ１１１は、端末装置１００に予め格納されたものであってもよく、ユーザが外部からダウンロードしたものでも良い。アプリ１１１はタイマモジュールの機能を使用して定期的に実行が再開（開始）されて、ネットワークシステムを用いてサーバ装置２００へアクセスし、アクセス結果に基づいて必要があればファイルシステム及びウィンドウシステムに変更要求を出力する。
【００３６】
ゲートウェイ装置３００に搭載される仮想環境３１０はゲートウェイ装置３００の実ＯＳであるホストＯＳにより制御される。仮想環境３１０では、ゲストＯＳ３１２が仮想ハードウェア３１３上で動作し、アプリ３１１はゲストＯＳ３１２の制御のもとに実行される。
【００３７】
１つのゲートウェイ装置３００は、複数の端末装置１００のそれぞれに対応し、仮想環境３１０を搭載する。仮想環境３１０がエミュレートする端末装置１００のハードウェア要素として、ＣＰＵ、メモリの他に不揮発メモリ、ＶＲＡＭ及びクロック３０６を含むハードウェアタイマ、電力管理ハードウェアをエミュレートする仮想電力ハードウェアを含む。
【００３８】
仮想環境３１０のゲストＯＳ３１２はファイルシステム及びウィンドウシステム、ネットワークシステム、周期的な起床をサポートするためのタイマモジュール、メモリの所定領域に格納される周期タイマリストを有する。
【００３９】
仮想環境３１０で実行されるアプリ３１１は端末装置１００で実行されるアプリ１１１と同じ直接実行する形式のものでも、バッチコマンドやスクリプト言語で書かれたものであってよい。また、予めメモリに格納されたものであってもよく、外部装置から仮想環境３１０にダウンロードされたものであっても良い。
【００４０】
アプリ３１１はタイマモジュールの機能を使用して定期的に実行が再開（開始）されて、ネットワークシステムを用いてサーバ装置２００へアクセスし、アクセス結果に基づいて必要があればファイルシステム及びウィンドウシステムに変更要求を出力する。
【００４１】
仮想環境３１０のメモリの所定領域に「タイマ起床中フラグ」が格納される。「タイマ起床中フラグ」は仮想環境３１０が割込により起床した際に、当該割込みの種類がタイマ割込みであったか否かを示すためのフラグである。
【００４２】
通信網を介して端末装置１００と仮想環境３１０が接続している間、両者の周期タイマリストは同期するように管理される。
【００４３】
本実施の形態では、端末装置１００の構成と仮想環境３１０がアプリ１１１（３１１）から見れば同じ環境であるため、端末装置１００がアプリ１１１を、仮想環境３１０がアプリ３１１をそれぞれ同時に実行開始する。したがって、プログラム実行中に周期性のあるタイマ要求は同時に出力されることを前提としている。
【００４４】
端末装置１００は『起床状態』であるとき、仮想マシンであるゲートウェイ装置３００と例えばＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）に従い通信し、サーバ装置２００とは、例えばＨＴＴＰに従い通信する。また、ゲートウェイ装置３００は『起床状態』であるとき、サーバ装置２００と、例えばＨＴＴＰ（HyperText Transfer Protocol）に従い通信する。
【００４５】
本実施の形態では、「端末装置１００と仮想環境３１０の同期」とは、端末装置１００が通信網６０を介してゲートウェイ装置３００などの外部装置と通信可能な状態にある、ことと定義する。
【００４６】
本実施の形態では、タイマリストには、通常の周期タイマリストと、保留タイマリストとを含む。いずれのタイマリストもタイマデータが登録される。タイマデータは、イベントを管理するためのデータである。イベントが発生すると、当該イベントに対応したアプリの実行が開始（たとえば、プログラムを実行開始）または実行が再開（たとえばプログラムをイベント待ち状態から実行が再開）されることによりイベントに対応した処理が行われる。ここでは、イベントに対応した処理には、サーバ装置２００に対するアクセス処理を含む。
【００４７】
保留タイマリストは、「端末装置１００と仮想環境３１０の同期」がとられている期間では、発生が保留されているイベント（すなわち、当該イベントに対応したアプリの実行が保留されている）のタイマデータを管理するためのリストである。
【００４８】
図６は、本発明の実施の形態に係る周期タイマリストを例示する図である。図６の周期タイマリストは、ＯＳ内で管理する時刻01:00:00時点での内容を示す。
【００４９】
図６を参照して周期タイマリストには、１つ以上のタイマデータがレコード形式で登録（格納）される。タイマデータは、周期的に発生するイベントを管理するためのデータである。タイマデータは当該タイマデータを識別するための要素番号データ０Ａ、タイマ満了時刻データ１Ａ、イベント要求元アプリデータ２Ａ、呼出イベント番号データ３Ａ、および周期タイマに従ってイベントを起動する場合の起動する時間間隔を示す間隔データ４Ａを対応づけて含む。
【００５０】
図６では、タイマ満了時刻データ１Ａが示すタイマ満了時刻が早い順に登録されている。これはタイマ割込みによりイベントを起動する場合にタイマリストを高速検索するのに都合よくするためであり、登録の順番はタイマ満了時刻データ１Ａが示す時刻順に限定されるものではない。タイマ満了時刻はタイマが満了する時刻を、ＯＳ内時刻と同じ基準で示す。図６では、ＯＳ内時刻は01時00分00秒を示している。
【００５１】
イベント要求元アプリデータ２Ａはイベント要求元アプリを示す。イベント要求元アプリはタイマ処理の要求をＯＳに対して行ったアプリケーションやモジュールを示す。図６を参照してイベント要求元アプリデータ２Ａが示す「アプリＣ」は、アプリ１１１（３１１）の識別子を示し、「カーネル」はＯＳ内部のドライバの識別子を示す。イベント要求元アプリデータ２Ａが示すアプリケーションやモジュールの識別子には、アプリケーションやモジュールの名称ではなく、ＯＳ内でアプリケーションの実行を管理している際のプロセス番号（またはスレッド番号）を用いる。
【００５２】
呼出イベント番号データ３Ａは、対応のイベント要求元アプリデータ２Ａが示すアプリケーションやモジュールがタイマ満了時に受理することを要求するイベント番号を示す。イベント番号は、イベントの識別子を示す。なお、イベント番号は、異なるアプリケーションが同じイベント番号を使用してもよく、或いは端末装置１００内で共通のイベント番号を用いても構わない。また、イベントの識別子は番号に限定されず、イベントの名称を示す文字列、または当該イベントに対応して起動されるプログラム内の関数のポインタ（関数の置かれているアドレス）であってもよい。
【００５３】
図６のタイマリストは周期タイマリストであることから、タイマデータは間隔データ４Ａを有する。間隔データ４Ａは、正の値で秒数を示す。周期的でない１回限りのタイマの際には間隔データ４ＡはNo（0）が、すなわち０秒が設定される。
【００５４】
図６のタイマリストに基づきイベントを発生する場合の動作を、タイマ割込みが発生した際の動作を例示して説明する。図７と図８は本発明の実施の形態に係るタイマ割込発生時の処理フローチャートである。ここでは、アプリまたはカーネルのプログラムがＣＰＵにより実行中であると想定する。
【００５５】
図７を参照して、処理部１０１は、図６の周期タイマリストにタイマデータについて先頭に登録されているものから順番に読出すように要素番号データＡ０を指示するための変数ｉに０を設定する（ステップＷ１）。そして、変数ｉの値を示す要素番号データＡ０を有するタイマデータを読出し、そのタイマ満了時刻データ１Ａが示す満了時刻と、タイマモジュールが計時して出力する現在の時刻とを比較し、比較結果に基づき現在時刻が満了時刻を過ぎているか否かを判定する（ステップＷ３）。過ぎていると判定すれば（ステップＷ１で満了時刻＜＝現在時刻）、処理部１０１は対応のイベント要求元アプリデータ２Ａが示すアプリケーションに対して、対応の呼出イベント番号データ３Ａが示す番号を有するイベントを発行（通知）する（ステップＷ５）。タイマイベントを発生させたので、周期タイマリストから当該タイマデータを削除する。
【００５６】
図８では、イベント待ち状態に入っていたアプリＣはＯＳによりスケジューリングされ、「タイマイベントが発行された」との情報と共に実行が再開される。結果、次のステップＰ３以降の処理に進む。
【００５７】
図６の周期タイマリストではタイマデータはタイマ満了時刻の順にソートされて格納されているので、満了時刻よりも現在時刻の方が早いタイマデータが読出された段階で探索を止めている（ステップＷ３で満了時刻＞現在時刻、ステップＷ４）。ソートされていない場合は周期タイマリスト内の全タイマデータを検索する必要がある。
【００５８】
その後、読出されたタイマデータの間隔データ４Ａの値に基づき周期タイマであるかどうかを判定する（ステップＷ６）。つまり、間隔データ４Ａが正の値を示すと判定した場合には（ステップＷ６で“周期タイマである”）、当該タイマデータを周期タイマリストに再登録する（ステップＷ７）が、間隔データ４ＡがNo（０）を示すと判定した場合には、すなわち周期タイマではないと判定した場合には（ステップＷ６で“周期タイマでない”）、次位に登録されたタイマデータを参照するように変数ｉの値を１だけインクリメントし（ステップＷ９）、ステップＷ３に戻り、以降の処理を実行する。
【００５９】
上記のステップＷ７で、周期タイマリストにタイマデータを再登録する際には、タイマ満了時刻データＡ１が示す時刻を、現在時刻に間隔データ４Ａが示す周期値を加算した時刻を示すように更新し、更新後のタイマデータを周期タイマリストに追加登録する。追加登録時には、タイマ満了時刻データ１Ａが示す満了時刻でソートされた順番が維持されるように、当該タイマデータを周期タイマリストに追加登録する。
【００６０】
アプリ１１１はタイマモジュールの機能を使用して定期的に起床（実行開始）される。これを、図８のようにアプリ１１１の内部でイベント待ち状態を有する方法を示す。
【００６１】
図８を参照して、アプリ１１１は起動後、ＯＳに対してタイマ要求を登録する（ステップＰ１）。ここでタイマ要求は、“現在時刻から何秒後になったらイベント０００１を受信したい”と登録する。ＯＳ上での現在時刻01:00:00において“現在時刻から５秒後にイベント０００１を受信したい”としてタイマ要求した場合には、ＯＳ内の周期タイマリスト（図６参照）に対し、図６の矢印で示すタイマデータが登録される。
【００６２】
アプリ１１１はその後、イベント待ち状態に移行する（ステップＰ２）。なお、イベント待ち状態に移行するまでに、他のタイマ要求、またはキーパッド１０３のキー操作による外部入力時のイベント要求、または他のアプリからの通信が来たときのイベント要求などをＯＳに対して登録していても構わない。仮想環境３１０への仮想キーパッドからの割込みは、例えば図９のようにホストＯＳ３１４上で別のサーバを動作させることで割込みを実現することができる。
【００６３】
イベント待ち状態では、アプリ宛てにイベントが発行されるまで、ＯＳはアプリ１１１をスケジューリングしない。つまり、アプリ１１１に、アプリを実行するためにＣＰＵを割当てない。アプリ１１１など、ＯＳに管理されている全てのアプリ、及びＯＳ自体がイベント待ち状態にあるとき、ＯＳはタイマなどのハードウェアからの割込みだけを待つ状態になり、『低電力状態』に移行する。
【００６４】
タイマ満了してイベントが図７の手順で発行されると（ステップＰ２でイベント到着）、アプリ１１１は受信したイベントの番号を確認し、その番号が先にタイマ要求で登録した番号０００１を示すか否かを判定する（ステップＰ３）。
【００６５】
イベント番号は登録した番号であると判定すると（ステップＰ３で“イベント番号＝＝０００１）、タイマ満了時に対応した処理に移行するが、そうでないと判定すると（ステップＰ３で“イベント番号は０００１でない）、他の処理に移行し、その後、ステップＰ２に戻る。
【００６６】
タイマ満了時に対応した処理では、サーバ装置２００に通信網を介して接続して、サーバ装置２００からの応答を受信する（ステップＰ５）。受信した応答の内容に変化があるか否かを判定する（ステップＰ６）。変化ありと判定すれば（ステップＰ６で“変化あり”）、受信した応答内容に従ってファイルを更新などし（ステップＰ７）、その後、ステップＰ２に戻る。また、変化なしと判定すれば（ステップＰ６で“変化なし”）、ステップＰ７の処理はパスして、ステップＰ２に戻る。
【００６７】
ステップＰ７でイベント番号が“０００１”に対応の処理が行われた後に、周期タイマリストでは、タイマデータが再度同じ周期で登録される（図７のステップＷ７を参照）。アプリ１１１が再びイベント待ち状態（図８のステップＰ２を参照）へ戻ることで、アプリ１１１は番号０００１のイベントに対応した処理を定期的に実行することができる。
【００６８】
上記したように、端末装置１００と仮想環境３１０で同じアプリ１１１と３１１を同時に実行していれば、周期性のあるタイマ要求は一致している、ことを前提としている。
【００６９】
つまり、端末装置１００と仮想環境３１０は同時に動作しているので、図７のステップＰ１の説明で、「ＯＳ上での現在時刻01:00:00において５秒後に」、として端末装置１００内でタイマ要求が出力されて処理されるとき、仮想マシンであるゲートウェイ装置３００の仮想環境３１０においても「ＯＳ上での現在時刻01:00:00において５秒後に」、としてタイマ要求が出力されて処理されることになる。
【００７０】
端末装置１００と仮想環境３１０では２つのアプリ１１１と３１１が同じタイミングでタイマ要求を出力することが要求される。当該要求は、アプリ１１１と３１１のそれぞれが同じ（ネットワークで同期された）時刻で実行開始される、或いはそこまで待ってから処理を開始することで実現される。
【００７１】
または、端末装置１００と仮想環境３１０の２つのアプリ１１１と３１１を時刻同期して実行するためのプロトコルを利用して実現するとしてもよい。
【００７２】
（『低電力状態』から『起床状態』への遷移）
端末装置１００を『起床状態』に遷移させる契機として割込みを用いる。割込みは、タイマによる割込みと、ネットワーク（モデム）、またはキーパッド１０３からの割込みを含む。仮想環境３１０は端末装置１００をそのまま仮想化したものであるから、同じ種類の割込みを仮想的にサポートする。仮想環境３１０へのネットワーク割込みは、仮想環境３１０がサーバ装置２００などから受信した場合に、ホストＯＳを介して発生される。仮想環境３１０では、端末装置１００を起床させる契機として、ネットワーク（モデム）またはキーパッドからの割込みと区別するために、割込みがタイマによる割込みであるかを判定するために「タイマ起床中フラグ」を参照する。
【００７３】
（仮想環境３１０が『起床状態』に遷移する契機）
図１０は、本発明の実施の形態に係る仮想環境３１０が『起床状態』に遷移するためのタイマ割込みを説明する図である。
【００７４】
仮想環境３１０が『起床状態』に遷移する契機は、仮想環境３１０がエミュレートしているハードウェアタイマによる割込みを示す。
【００７５】
ホストＯＳ３１４が仮想環境３１０に対してタイマイベント（タイマ割込みによるイベント）を発行するとき、その仮想的なハードウェアタイマは、仮想的な割込みを発生する。
【００７６】
仮想環境３１０内の仮想ハードウェアタイマの（仮想的な）レジスタに対して、イベント発生までの期間をカウントするための値が書きこまれたとき、仮想環境３１０からホストＯＳ３１４に対して当該発火タイミングに相当するタイマ発行要求がなされ、ホストＯＳ３１４はそのタイマ発行要求に基づいてホストＯＳ３１４内のイベント処理ブロックやハードウェアタイマの設定/変更を行なう。ここでは、イベントの発生を“発火”とも称する。
【００７７】
仮想環境３１０から要求された発火時刻になると、ホストＯＳから仮想環境３１０に対してタイマイベントが発行される。そのタイマイベントが発生した時点で仮想環境３１０が仮想ハードウェアタイマの割込みを発生させる。仮想ハードウェアタイマの割込みが発生すると、仮想マシンであるゲートウェイ装置３００内で割込みが処理されて、起床状態へ遷移するための処理が開始される。
【００７８】
（実施の形態１に係る動作の概要）
図１１は、本発明の実施の形態１に係る動作の概要を模式的に説明する図である。図中の丸付き数値は、以下の説明では括弧付き数値で示す。図１１を参照して端末装置１００および仮想環境３１０上でそれぞれアプリ１１１と３１１が実行されており、対応するＯＳに対して周期タイマ要求を出力する（処理（１））。
【００７９】
端末装置１００では、仮想環境３１０と通信網を介して「端末装置１００と仮想環境３１０の同期」している状態かを確認する（処理（２）および（３））。ただし、タイマ要求の発行毎に通信して同期する訳ではない。
【００８０】
「端末装置１００と仮想環境３１０の同期」している状態と判定すると、端末装置１００ではタイマ要求のタイマデータは保留タイマリストに登録される。
【００８１】
仮想環境３１０ではタイマ要求のタイマデータは、アプリ３１１により周期タイマリストに登録される。周期タイマリストに登録されたタイマデータはタイマ満了時刻データＡ１が示す時刻になったとき、対応するイベントが発生する（処理（４））。図中では、イベント発生を“発火”と記載している。
【００８２】
『起床状態』に遷移して当該イベントが通知されたアプリ３１１は通信ネットワーク５０を介してサーバ装置２００と通信し（処理（５））、応答を受信する。受信した応答内容が変化していると判定した場合には、ゲストＯＳ上のファイルシステムまたはウィンドウシステムに更新要求が発行される（処理（６））。要求に応じて、ファイルシステムはファイルとして応答内容を所定の記憶領域に格納し、またはウィンドウシステムは応答内容に基づき画面に表示される情報を更新する。
【００８３】
上記したファイルシステムまたはウィンドウシステムの処理により、仮想環境３１０内の仮想不揮発メモリまたは仮想ＶＲＡＭのデータが更新されたことを契機に（処理（７））に、仮想環境３１０は端末装置１００へ通信網を介して起床要求を送信する（処理（８））。端末装置１００は『低電力状態』において起床要求を受信すると、『低電力状態』から『起床状態』に遷移する。
【００８４】
起床要求によって『起床状態』に遷移した後の端末装置１００では、実ＯＳは保留タイマリストに保留（登録）してあったタイマデータに基づくイベントを発生させる（処理（９））。これによりアプリ１１１が起動し、プログラムが実行開始される。実行中のアプリ１１１は、実際に通信網６０および通信ネットワーク５０を介してサーバ装置２００と通信し、サーバ装置２００から応答を受信する（処理（１０））。
【００８５】
（サーバ装置２００との通信）
図１２は、本発明の実施の形態に係るサーバ装置２００との通信処理を模式的に示す図である。図１２を参照して、上記の処理（５）と（１０）における端末装置１００または仮想環境３１０上のアプリ１１１と３１１とサーバ装置２００との通信を説明する。図１２では、通信にHTTPプロトコルとHTML（HyperText Markup Language）ファイルを用いるが、他の汎用・専用なプロトコルでも汎用・専用なファイルでも実施することができる。
【００８６】
アプリ１１１（３１１）は、図８で説明した周期的なイベント発生により（処理（Ａ１）、HTTPプロトコルでサーバ装置２００の特定URL（Uniform Resource Locator）へアクセスし、応答を待機する（処理（Ａ２））。
【００８７】
サーバ装置２００はその時点での状態をHTMLファイルとしてHTTPプロトコルで応答する（処理Ａ３）。ここで、状態とは、サーバ装置２００自体の状態の他、サーバ装置２００上で持っているアプリケーションやサービスのデータを示す。
【００８８】
例として、データ本体はHTMLファイルの<pre>タグで囲まれた部分で送付する。本例では<pre>タグで囲まれた部分は一連のニュース記事などを示し、事件が発生した際に人手で記事を追加しているようなイメージで示す。
【００８９】
アプリ１１１（３１１）側では、受信したデータをアプリ内のワーキングメモリに格納する（処理（Ａ４））。
【００９０】
同時に、アプリ１１１（３１１）では直前に保持していたワーキングメモリ上のデータ、つまり前回のサーバ装置２００からの受信データと、今回サーバ装置２００から受信したデータを比較する（処理Ａ５）。
【００９１】
処理Ａ５の比較は、本例では２つのデータに含まれる<pre>で囲まれた部分を文字列により比較する。文字列が完全一致するとき差分がないと検出し、そうでないとき差分が有ると判定する（処理Ａ６）。アプリ１１１（３１１）はファイルシステム上にデータを整理して保存する（処理（Ａ８））。
【００９２】
（処理Ａ５）での比較の結果、差分がない場合には、ファイルシステム上のデータを更新しない。つまり、アプリ１１１（３１１）はＯＳに対し書込み要求を出力しない（処理Ａ６）。
【００９３】
（処理Ａ５）での比較の結果、差分がある場合にはファイルシステムはデータを更新する。本例では、<pre>で囲まれた部分に相当する部分だけを抜き出してファイルシステムを介してファイルに書込む。つまり、アプリ１１１（３１１）はＯＳに対し書込み要求を、差分に相当するバイト数だけ発生させる（処理Ａ７）。
【００９４】
アプリ１１１（３１１）は、ファイルシステム上のデータを更新するのと同時に、ユーザに対して更新後の記事内容を表示するために、ＶＲＡＭに差分に基づくデータを格納する。アプリ１１１（３１１）は、表示用の（仮想環境３１０においては仮想的な）ＶＲＡＭをアクセスする（処理Ａ９）。
【００９５】
（処理Ａ６）と同じく記事内容に変更がない、すなわち表示内容に変更がなければＶＲＡＭのデータは更新されない（処理Ａ１０）。（処理Ａ７）と同じく記事内容に変更があり、すなわち表示すべき内容に変更があればＶＲＡＭのデータを更新する。表示内容は本例ではファイルとして書き出した内容と同じ文字列が表示される。（処理Ａ１１）では、ウィンドウシステムに対して文字と位置を指定して描画を行わせる。
【００９６】
本例ではファイルシステム上へ書き出すデータ及び表示内容は、サーバ装置２００からの応答内容（処理Ａ３）からの一部分の抜き出しによって生成される（処理Ａ７）。なお、生成方法はこれらに限定されない。また、ファイルへの書出し内容と表示内容が異なっていてもよい。
【００９７】
つまり、仮想環境３１０における図１１の処理（５）と（６）に関しては、本実施の形態では次の手順となる。
【００９８】
処理（５）に関しては、仮想環境３１０上のアプリ３１１に対して番号０００１のタイマイベントが発生した場合（図８のステップＰ３）には、サーバ装置２００の状態（本実施の形態では記事データ）をHTTPプロトコルで要求し、そのデータを応答として受信する。
【００９９】
処理（６）に関しては、その<pre>で囲まれた部分に含まれることになっているデータ本体を、前回に受信したデータ本体と比較し（処理Ａ５）、<pre>で囲まれた部分の文字列が完全一致しない（部分的にでも変わった部分がある）場合に（処理Ａ７）、ファイルシステム上に<pre>の部分だけを抜き出した形で保存し（処理Ａ７）、同じ内容に基づく要求をウィンドウシステムに出力する（処理Ａ１１）。
【０１００】
（同期をとる動作）
「端末装置１００と仮想環境３１０の同期」をとる処理について説明する。
【０１０１】
図１３は、本発明の実施の形態１に係る端末装置１００で同期を取るための動作を説明するための図である。
【０１０２】
端末装置１００のＣＰＵは、通信網６０に接続できたイベントが発生したとき、仮想環境３１０に接続を試みて接続できるようであれば、同期中フラグをセットし「同期中」状態に遷移する。「同期中」状態は、「端末装置１００と仮想環境３１０の同期」を示す。
【０１０３】
端末装置１００が通信網６０との接続が切断されたイベントが発生したとき、同期中フラグをリセットして「未同期」状態に遷移させる。「未同期」状態は、「端末装置１００と仮想環境３１０の同期」がとれていない状態を示す。
【０１０４】
ＣＰＵは、同期中フラグのセット／リセットに基づき「未同期」から「同期中」に移行すると判定するときには、一時的に周期タイマリストに登録していたタイマデータを保留タイマリストに移動させる。「同期中」から「未同期」に移行すると判定するときには、保留タイマリストに登録されていたそれぞれのタイマデータを以下のように処理する。
【０１０５】
（ｉ）その前の発火タイミングから指定時間だけ既に経過していれば一度そのタイマデータを発火させ、（ｉｉ）タイマデータを通常の周期タイマリストに移動させる。
【０１０６】
なお、通信網６０との接続／切断は、通信部１０４のモデムが有する通信網６０の信号に基づくステータスレジスタの状態（網接続中１、切断０）と、その変化時に発生するハードウェア割込み信号により検出する。ステータスレジスタの状態は、通信網６０から従する信号に基づき決定する。
【０１０７】
上記の（ｉ）と（ｉｉ）の処理は、通信網６０が切断された段階でも、アプリ１１１がファイルのデータの差替え、または画面の表示情報（画像など）の書換えなどを可能にするための処理である。
【０１０８】
具体的には、「端末装置１００と仮想環境３１０の同期」状態では、保留タイマリストに登録されているタイマデータは、本来ならば対応のイベントを発生するべき時刻（タイマ満了時刻）でもイベントが発生しない。したがって、仮想環境３１０からの起床要求がないまま、端末装置１００側で「未同期」である場合、保留タイマリストの中には既にタイマ満了時刻に到達するタイマデータが存在することになる。したがって、このようなタイマデータに対応のイベント発生によるファイル更新または画面更新ができなくなる。このような不都合を回避するために、（ｉ）と（ｉｉ）の処理では、「未同期」通信網が切れて保留タイマリストを戻す際に、既にタイマの満了時間を経過しているものについては一旦発火させている。
【０１０９】
（周期タイマリストへのタイマデータ登録処理）
図１４は、本発明の実施の形態に係るタイマデータの登録処理のフローチャートである。端末装置１００においてＣＰＵは、同期中フラグがセットされているか否か、すなわち同期中であるか否かを判定する（ステップＳ１）。同期中フラグがセットされていると判定すると（ステップＳ１で“同期中”）、タイマデータを「保留タイマリスト」へ登録し（ステップＳ３）、周期タイマリストへの登録は行わない。
【０１１０】
同期中フラグがリセットされていると判定すると（ステップＳ１で“同期していない”）、端末装置１００自体で発火させるタイマデータとして扱うため、周期タイマリストへ登録し、且つ最も近く発火するタイマデータであると判定すると（ステップＳ７で“最も近くで発火するタイマである”）、ハードウェア上のタイマを設定し直す（ステップＳ９）。そうでないと判定すると（ステップＳ７で“最も近く発火するタイマは変更しない”）、ハードウェア上のタイマは変更しない（ステップＳ１１）。
【０１１１】
図１４では、“最も近く発火するタイマである場合にハードウェア上のタイマを設定し直す”とあるが、ｉ）最も近く発火するタイマであることを判定するための方法と、ii）ハードウェア上のタイマを設定し直す理由について説明する。
【０１１２】
上記ｉ）に関しては、図６のタイマリストのタイマデータとの比較により判定する。つまり、図６の場合、タイマデータはその発火する時間順にソートされているので、データ０Ａが０番目を示すタイマデータのタイマ満了時刻データ１Ａが示すタイマ満了時刻と、図１４のステップＳ５で登録しようとしたタイマデータの満了時刻とを比較し、比較結果に基づき、最も近く発火するタイマデータであるかを判定する。なお、タイマリストにおいてタイマデータが図６のようにソートされていない場合には、全タイマデータのタイマ満了時刻データ１Ａを逐次比較することによって判定する。
【０１１３】
上記ii）に関して、図１５に、本発明の実施の形態に係るハードウェアタイマとその周辺構成を示すブロック図を示す。図１５を参照して、タイマのハードウェアは無限の個数だけタイマ設定できるのではなく、有限であるため、タイマを設定し直す必要がある。
【０１１４】
具体的には、図１５のtimerブロックは１つのタイマ割込みを発生させるハードウェアであって、クロック入力によりカウント値を変化させるカウンタ（Timer Counter）、割込みを発生させるタイミングを示すためのレジスタ（Timer Limit）、およびカウンタのカウント値とレジスタの値とを比較する比較器とを備える。比較器はカウント値とレジスタの値とを比較し、一致したときに“１”を出力する。この出力を基に、ハードウェア上では割込みが発生する。
【０１１５】
タイマをハードウェアで実装する必要があるので、タイマブロックの数は有限であり、本実施の形態では、１つとしている。タイマブロックが１つの場合、次に最も早く発火するタイマデータを登録する必要がある。新しいタイマデータを登録する際にはそれが最も近く発火するタイマデータであることを判定し、必要があればハードウェアタイマの各値を設定し直す必要がある。
【０１１６】
図１６は、本発明の実施の形態に係る仮想環境３１０における周期タイマリストへの登録処理のフローチャートである。図１６を参照して、処理部３０１は、周期タイマリストにタイマデータを登録する（ステップＳ１１）。タイマリストにタイマデータのうち、最も近く発火するタイマデータである場合に仮想ハードウェア上のタイマを設定し直す（ステップＳ１３、Ｓ１５）。そうでない場合には仮想ハードウェア上のタイマを設定変更はしない（ステップＳ１５）。
【０１１７】
図１６における発火するタイマデータの検出と、タイマの設定変更は、図１４および図１５で説明した処理と同様であり、詳細は繰り返さない。
【０１１８】
（端末装置１００の電力管理ハードウェアの状態遷移）
図１７は、本発明の実施の形態に係る端末装置１００の電力管理ハードウェアの状態遷移を示す図である。端末装置１００の電力管理ハードウェアは、『低電力状態』においてハードウェアによる割込みを受けるとＣＰＵ及びメモリへのクロック供給が再開される。ＣＰＵへのクロック供給が再開されることによりＯＳのプログラム実行が再開され、電力管理ハードウェアは『起床状態』へ遷移する。
【０１１９】
また、『起床状態』において、ＣＰＵが電力管理ハードウェアの制御レジスタへ書込みをすると、クロック供給を停止して電力管理ハードウェアは『低電力状態』へ移行する。電力管理ハードウェアは同時に一部ブロックへの電力供給の停止を止めることもできる。
【０１２０】
（仮想環境３１０の仮想電力管理ハードウェアの動作）
図１８は、本発明の実施の形態に係る仮想環境３１０の仮想電力管理ハードウェアの動作を模式的に示す図である。
【０１２１】
図１８を参照して、仮想環境３１０の仮想電力管理ハードウェアは、『低電力状態』において仮想的な割込みを受けると仮想環境３１０におけるプログラム実行を再開する。このとき、発生した仮想割込みがタイマ割込みであれば、「タイマ起床中フラグ」をセットする。仮想割込みは、仮想的なタイマ割込み、または仮想的なモデムからの割込み、または仮想的なキーパッドからの割込みを含む。
【０１２２】
また、『起床状態』において、仮想電力管理ハードウェアの制御レジスタへの書込みが行われることによりを仮想環境３１０におけるプログラム実行を停止する。この際に「タイマ起床中フラグ」がリセットされる。
【０１２３】
仮想環境３１０がタイマ割込みにより『起床状態』に遷移した後、再び『低電力状態』に遷移するまでの間、「タイマ起床中フラグ」はセットされていることになる。
【０１２４】
（仮想環境３１０内でアプリ３１１から描画要求が起こった場合の動作）
図１９は、本発明の実施の形態に係る仮想環境３１０内で描画要求が起こった場合の処理フローチャートである。
【０１２５】
図１９を参照して、アプリ３１１から描画要求が起こった場合、仮想環境３１０内のＶＲＡＭを更新し（ステップＳ２１）、仮想環境３１０内の「タイマ起床中フラグ」の値を判定する（ステップＳ２３）。「タイマ起床中フラグ」がリセットされていると判定した場合には、後述する起床要求の送信はせずに処理を終了する（ステップＳ２５）。
【０１２６】
一方、「タイマ起床中フラグ」がセットされていると判定した場合には（タイマによる起床によって描画内容が更新されたことを示すため）、ゲストＯＳは実端末装置１００に対して起床要求を送信する（ステップＳ２７）。つまり、ゲストＯＳがホストＯＳ側のネットワーク機能へ起床要求を出力することにより、当該ネットワーク機能は起床要求を端末装置１００宛てに送信する。
【０１２７】
仮想環境３１０で起床要求が発生すると、通信網を介して端末装置１００のハードウェア（モデムなど）が起床要求を受信し、端末装置１００内にハードウェア割込みが発生する。
【０１２８】
図１９では描画要求についてのフローを示しているが、
描画要求→ファイル書込み要求、仮想ＶＲＡＭ→仮想不揮発メモリ、
描画要求→サウンド鳴動要求 、仮想ＶＲＡＭ→仮想サウンドデバイス鳴動、
描画要求→バイブレータ鳴動要求、仮想ＶＲＡＭ→仮想ハードウェアレジスタ書込み、
描画要求→バックライト点灯要求、仮想ＶＲＡＭ→仮想ハードウェアレジスタ書込み、などに置換したケースについても同様のフローを適用することができる。
【０１２９】
（端末装置１００内で仮想環境３１０から起床要求を受理した場合の動作）
図２０は、本発明の実施の形態に係る保留タイマリストの一例を示す図である。保留タイマリストは、周期タイマリストと同様の構成を有する。保留タイマリストには、１つ以上のタイマデータがレコード形式で登録（格納）される。タイマデータは、当該タイマデータを識別するための要素番号データ０Ｂ、タイマ満了時刻データ１Ｂ、イベント要求元アプリデータ２Ｂ、呼出イベント番号データ３Ｂ、および周期タイマに従ってイベントを起動する場合の起動する時間間隔を示す間隔データ４Ｂを対応づけて含む。
【０１３０】
図２１は、本発明の実施の形態に係る端末装置１００内で仮想環境３１０から起床要求を受理した場合の処理フローチャートである。図２２は、本発明の実施の形態に係る保留タイマリストの参照結果から、イベントを発行する処理フローチャートである。
【０１３１】
図２１を参照して、処理部１０１のＣＰＵは仮想環境３１０から受信した起床要求を、ハードウェア割込みとして入力すると（ステップＳ３１）、保留タイマリストに登録されたタイマデータが満了しているか全ての登録済みタイマデータについて確認する（ステップＳ３５、Ｓ３７）。なお、起床要求以外の割込みを入力した場合には、当該割込みに対応した割込み処理を実行する（ステップＳ３３）。
【０１３２】
処理部１０１のＣＰＵは、保留タイマリストに登録済みのタイマデータについて、先にタイマイベントを発行した時刻とハードウェアタイマが計時する現在時刻とを比較する（ステップＳ４１）。比較結果から両時刻の差分が、登録された周期の時間よりも大きいと判定すると、タイマデータを登録したアプリケーションに対してタイマイベントを発行し（ステップＳ４３）、そうでないと判定するとタイマイベントは発行しない。
【０１３３】
その後、ステップＳ３７に戻り、保留タイマリストの全てのタイマデータについてタイマデータが満了しているかを確認したと判定すると、起床要求に対応の当該割込処理を終了する（ステップＳ３９）。
【０１３４】
図２１での差分と周期の比較処理、およびタイマイベント発行先のアプリケーションを特定する処理について、図２２を参照し説明する。
【０１３５】
処理部１０１のＣＰＵは、保留タイマリストのタイマデータを指示するための変数ｉの初期値（０）を設定し（ステップＲ１）、保留タイマリストから全てのタイマデータを読出したか否かを判定する（ステップＲ２）。読出し終了と判定すると、当該処理は終了する（ステップＲ３）が、そうでない場合には、変数ｉの値を示す要素番号データ０Ｂのタイマデータの間隔データ４Ｂに基づき周期タイマデータであるか否かを判定する（ステップＲ４）。周期タイマデータと判定すると、前回の発火時間からの経過時間を当該タイマデータのタイマ満了時刻データ１Ｂが示す満了時刻、間隔データ４Ｂが示す周期、および現在時刻から算出し（ステップＲ５）、算出した経過時間を間隔データ４Ｂの周期時間と比較し（ステップＲ７）、経過時間が周期時間未満であればステップＲ１２に移行するが、経過時間が周期時間以上であればイベントを発行する（ステップＲ９）。そして、発火させたタイマデータは一端、保留タイマリストから削除し、周期タイマデータの場合には現在の時刻と間隔データ４Ｂが示す周期から満了時刻を計算して、計算した値でタイマ満了時刻データ１Ｂを書き換えた後に、当該タイマデータを保留タイマリストに再登録する（ステップＲ１１）。その後、変数ｉを１インクリメントして（ステップＲ１２）、ステップＲ２に移行する。
【０１３６】
一方、周期タイマデータではないと判定すると、当該タイマデータのタイマ満了時刻データ１Ｂの時刻と現在時刻とを比較し（ステップＲ６）、現在時刻＜満了時刻の場合には、ステップＲ１２に移行するが、満了時刻≧現在時刻である場合には、イベントを発行する（ステップＲ８）。その後、ステップＲ１２に移行する。
【０１３７】
本実施の形態１によれば、端末装置１００でのタイマによる起床とサーバ装置２００へのポーリングを行う代わりに、仮想環境３１０が起床とポーリングを行う。
【０１３８】
仮想環境３１０は、ポーリングによるサーバ装置２００からの応答内容に基づき、端末装置１００に起床要求を送信し、端末装置１００を『低電力状態』から『起床状態』に遷移させる。これにより、端末装置１００自体が起床する回数を削減でき、消費電力量を低減できる。
【０１３９】
端末装置１００の起床およびポーリングを行う機能を、ネットワーク上の既存のゲートウェイ装置３００上に搭載した仮想環境３１０に代行させることで、専用のプロキシサーバおよびゲートウェイ装置またはpush型のプロトコルを準備する必要もない。
【０１４０】
[実施の形態２]
上記の実施の形態１では、仮想環境３１０は、ポーリングによってサーバ装置２００から受信する応答内容に基づき、仮想マシンが備える不揮発メモリのデータ書込み、または仮想的なＶＲＡＭへのデータ書込み、または仮想マシンが備える仮想的なオーディオデバイスへのデータ転送のいずれかが検出されれば一律に起床要求を送信したが、実施の形態２の仮想環境３１０ではファイルシステム、ウィンドウシステム、オーディオシステムへの要求について、要求レベルを定義し、定義した要求レベルが検出されたとき、起床要求を出力する。
【０１４１】
要求レベルは、端末装置１００が有するデータの出力デバイスの種類毎にユーザが可変に設定変更する。たとえば、ファイルシステム更新のみ（端末内部でしか起こらない変化）では端末装置１００を起床させない、またはＬＣＤのディスプレイ上の描画更新のみ（目視で眺めていないと気付かない変化）では端末装置１００を起床させない、といった設定を可能にする。
【０１４２】
図２３は、本発明の実施の形態２に係る仮想環境３１０において発生する要求のレベル定義をテーブル形式で示す図である。図２３のテーブルには、仮想環境３１０でポーリングによるサーバ装置２００からの応答内容に応じて発生する要求としてファイル更新要求、描画更新要求およびサウンド鳴動要求のそれぞれに対して、起床要求の送信を許可するか否かのデータ、すなわち端末装置１００を起床させ実端末上でアプリを実行することでデータ出力先への要求を発生させるか否かを決定するためのデータが登録されている。データ出力先となるデバイスの種類はサーバ装置２００からの応答内容に基づきアプリ３１１が決定する。たとえば、アプリ３１１は応答内容に含まれる文字列に基づきデータ出力先となるデバイスの種類を決定する。
【０１４３】
図２３によれば、ファイル更新要求、描画更新要求およびサウンド鳴動要求の順番でレベルの低い要求と定義している。
【０１４４】
起床要求をもたらす要求の種類は上記の３種類に限定されず、たとえば、端末装置１００のユーザインタフェースデバイスに合わせて、バイブレータ鳴動要求、バックライト点灯要求などを組込むとしてもよい。
【０１４５】
また、ユーザは「起床要求フラグ」の３つの状態のうち１つを仮想環境３１０に対して指定しておくことができる。例えば、ユーザが「起床要求フラグ」に「１：描画更新」を指定していたとき、描画更新要求とサウンド鳴動要求が仮想環境３１０で発生した場合には端末装置１００へ起床要求を送信するが、ファイルシステム更新のみの場合には起床要求が送信されることはない。
【０１４６】
図２３のテーブルのデータは、後述する図２４のフローチャート内で「起床要求レベル＞ファイル変更」「起床要求レベル＞描画更新」の分岐条件としてプログラム中に記載（組込み）される。プログラムはホストＯＳに管理された不揮発メモリの中の仮想化環境実行プログラムの中に格納されており、不揮発メモリから読出されて仮想環境３１０において実行される。
【０１４７】
図２４は、本発明の実施の形態２に係る仮想環境３１０内でアプリ３１１から描画要求が起こった場合の処理フローチャートである。図２４は、実施の形態１の図１９のフローチャートを起床要求レベルを参照するように変更したものである。
【０１４８】
図２４の（Ａ）を参照して、アプリ３１１からファイルシステム要求が起こった場合、仮想環境３１０内の仮想不揮発メモリを更新し（ステップＳ５１）、仮想環境３１０内の「タイマ起床中フラグ」の値を判定する（ステップＳ５３）。「タイマ起床中フラグ」がリセットされていると判定した場合には、ステップＳ５５以降の起床要求に関する処理をせずに処理を終了する（ステップＳ５７）。
【０１４９】
一方、「タイマ起床中フラグ」がセットされていると判定した場合に、起床要求フラグが示す起床要求レベルが０（すなわち、“いつでも”）より大きいと判定すると（ステップＳ５５）、起床要求の送信はせずに終了する（ステップＳ５９）。
【０１５０】
一方、起床要求フラグが示す起床要求レベルが０以下であると判定すると（ステップＳ５５）、起床要求を端末装置１００の送信する（ステップＳ６０）。
【０１５１】
図２４の（Ｂ）を参照して、アプリ３１１から描画要求が起こった場合、仮想環境３１０内の仮想ＶＲＡＭを更新し（ステップＳ６１）、「タイマ起床中フラグ」の値を判定し（ステップＳ６３）、「タイマ起床中フラグ」がリセットされていると判定した場合には、ステップＳ６５以降の起床要求に関する処理をせずに処理を終了する（ステップＳ６７）。
【０１５２】
一方、「タイマ起床中フラグ」がセットされていると判定した場合には、起床要求フラグが示す起床要求レベルが１（すなわち、“描画更新”）より大きいと判定すると（ステップＳ６５）、起床要求の送信はせずに終了し（ステップＳ６９）、０以下であると判定すると（ステップＳ６５）、起床要求を端末装置１００の送信する（ステップＳ７０）。
【０１５３】
図２４の（Ｃ）を参照して、アプリ３１１からサウンド要求が起こった場合、仮想環境３１０内の仮想サウンドデバイスを動作させ（ステップＳ７１）、仮想環境３１０内の「タイマ起床中フラグ」の値を判定し（ステップＳ７３）、「タイマ起床中フラグ」がリセットされていると判定した場合には、ステップＳ７５以降の起床要求に関する処理をせずに処理を終了する（ステップＳ７７）。
【０１５４】
一方、「タイマ起床中フラグ」がセットされていると判定した場合には、起床要求の送信が許可されていることから、起床要求を端末装置１００に送信する（ステップＳ７５）。
【０１５５】
このように、仮想環境３１０内でアプリ３１１からファイル更新要求、描画更新要求およびサウンド鳴動要求などの要求が起こった場合、「タイマ起床中フラグ」と「起床要求フラグ」の両方について条件を満たした場合のみ、仮想環境３１０は端末装置１００に対し起床要求を送信する。通信網６０を介して端末装置１００のハードウェアが起床要求を受信し、端末装置１００内にハードウェア割込みが発生し、端末装置１００は起床する。
【０１５６】
[実施の形態３]
実施の形態２では、ファイル更新要求、描画更新要求およびサウンド鳴動要求などの要求について要求レベルを予め設定し、設定したレベルを満たす要求についてのみ起床要求を送信したが、実施の形態３では要求レベルではなく、当該要求によるアクセス先に従って、起床要求を出力するか否かを決定する。
【０１５７】
具体例として、仮想環境３１０はファイルシステム介した不揮発メモリへの書込み先である論理ブロック番号またはファイルパスについて、所定条件に基づき判定し、判定結果、予め定めた論理ブロックまたはファイルパスへの書込み要求であると判定したときのみ、端末装置１００に起床要求を送信する。
【０１５８】
これにより、ユーザデータの更新が起きた場合のみ（ユーザに有意な変化のみ）端末装置１００を起床させ、システムデータや一時ファイルの書込みでは端末装置１００を起床しない、といった端末装置１００の起床制御が可能になる。
【０１５９】
図２５は、本発明の実施の形態３に係る不揮発メモリのブロック毎の使用目的をテーブル形式で示す図である。図２５に示すように、端末装置１００および仮想環境３１０の各不揮発メモリはブロック毎に使用目的（役割）が決まっている。ここで、使用目的とは、当該ブロックに格納されるデータの種類により示される。
【０１６０】
図２５では、端末装置１００において不揮発メモリはブロック番号で論理的に分割されたパーティションで管理されており、パーティションは番号により識別される。ＯＳにより不揮発メモリがマウントされる際に、各パーティションは図２５のマウント先に従いマウントされる。ファイルのパスに応じて、対応するマウント先、及び不揮発メモリ上の論理ブロック番号が対応している。
【０１６１】
図２５のパーティション毎の割当てでは、たとえばデータの種類がユーザデータの場合には、ユーザデータは/data以下に書込まれる。当該パーティションはパーティション番号２に相当し、ユーザデータは論理ブロック番号０１００〜１ＦＦＦのいずれかのブロックに書込まれる。仮想環境３１０内の不揮発メモリについても、端末装置１００と同じデータの種類（使用目的）毎にブロック番号とマウント先により当該データの書込み位置が決まる。
【０１６２】
図２５ではデータ種類を、システム起動プログラム、一時データ、ユーザデータおよびアプリケーションプログラムの４種類としているが、これは例示であり、他の種類のデータであってもよく、または３種類以下または５種類以上であってもよい。
【０１６３】
図２６は、本発明の実施の形態３に係る不揮発メモリへの書込み先と起床要求の出力可否とを関連付けて示す図である。実施の形態３では、仮想環境３１０において仮想不揮発メモリに発生する書込みが要求され得る各論理ブロックに対応して起床要求を出力するか否かを予め設定する。たとえば、ユーザが設定する。
【０１６４】
図２６の例では、仮想不揮発メモリの論理ブロック００ＦＦ〜１ＦＦＦへの書込みが発生した場合のみ、端末装置１００に対する起床要求の送信が許可（図中は丸記号で示す）される。
【０１６５】
図２７は、本発明の実施の形態３に係る仮想環境３１０におけるファイル更新要求の処理フローチャートである。図２７は、実施の形態１の図１９のフローチャートを変更したものである。
【０１６６】
図２７を参照して、仮想環境３１０内でアプリ３１１からファイル更新要求が起こった場合、仮想環境３１０の仮想不揮発メモリに対する書込み要求（ファイルシステム要求）が発生し、ファイルシステムは、書込み要求に基づき、仮想不揮発メモリの当該書込み要求に含まれる書込み先ブロックに要求されるデータを書込む（ステップＳ８１）。
【０１６７】
処理部３０１は、「タイマ起床中フラグ」が有る（セットされている）か否かを判定する（ステップＳ８３）。「タイマ起床中フラグ」がない（リセットされている）と判定すると（ステップＳ８３で“フラグなし”）、後述の起床要求の送信処理はせずに終了する（ステップＳ８５）。一方、「タイマ起床中フラグ」が有る（セットされている）と判定すると（ステップＳ８３で“フラグあり”）、ステップＳ８１で実際に書込みが発生した不揮発メモリの論理ブロック番号に基づき仮想環境３１０内に格納された図２６のテーブルを検索し、当該テーブルから書込みが発生“ブロック番号”に対応する起床要求可否データを読出す。
【０１６８】
読出した起床要求可否データが“許可”を示すか否か判定する（ステップＳ８７）。許可を示すと判定すると、すなわち書込み先のブロック番号は起床対象要求の範囲内と判定すると、端末装置１００に起床要求を送信する（ステップＳ９０）が、“許可”を示さないと判定すると、すなわち書込み先のブロック番号は起床対象要求の範囲外と判定すると（ステップＳ８７）、起床要求を送信することなく処理を終了する（ステップＳ８９）。
【０１６９】
図２７によれば、「タイマ起床中フラグ」がセットされて「端末装置１００と仮想環境３１０の同期」状態にあり、且つ仮想不揮発メモリの書込み先の「論理ブロック番号」が起床要求の送信を許可する論理ブロックを示す場合のみ、仮想環境３１０は端末装置１００に対して起床要求を送信する。通信網６０を介して端末装置１００のハードウェアが起床要求を受信し、端末装置１００内にハードウェア割込みが発生し、端末装置１００は起床する。
【０１７０】
図２８は、本発明の実施の形態３に係るデータ書込み先と起床要求の出力可否とを関連付けて示す図である。図２８は、図２６とは異なり、より上位のゲストＯＳ側のファイルシステム層で起床要求の出力可否を判定する場合に参照されるテーブルの一例を示す。
【０１７１】
仮想環境３１０においては、端末装置１００を起床させるか否かを判定するための参照情報として、論理ブロック番号ではなくマウントポイントまたはファイルパスを用いることもできる。図２８の例では、ファイルパスが“/data”である領域への書込みが発生した場合のみ、起床要求の送信を許可（図中は、丸記号で示す）する。
【０１７２】
図２９は、本発明の実施の形態３に係る仮想環境３１０におけるファイル更新要求の処理フローチャートである。図２９は、実施の形態１の図１９のフローチャートを変更したものである。
【０１７３】
図２９を参照して仮想環境３１０内でアプリ３１１からファイル更新要求が起こった場合、仮想環境３１０のゲストＯＳに対して、ファイルパス指定で書込み要求が発生する。ファイルシステムは、書込み要求に基づき、当該書込み要求に含まれるファイルパスの領域に要求されるデータを書込む（ステップＳ９１）。
【０１７４】
処理部３０１は、ステップＳ９１で実際に書込みをした領域のファイルパスに基づき仮想環境３１０内に格納された図２８のテーブルを検索し、当該テーブルから書込みが発生“ファイルパス”に対応する起床要求可否データを読出す。
【０１７５】
読出した起床要求可否データが“許可”を示すか否か判定する（ステップＳ９３）。許可を示すと判定すると、すなわち書込み先を示すファイルパスは起床対象要求の範囲内と判定すると、起床要求送信のための処理（ステップＳ９７）に移行するが、“許可”を示さないと判定すると、すなわち書込み先を示すファイルパスは起床対象要求の範囲外と判定すると（ステップＳ９３）、起床要求を送信することなく処理を終了する（ステップＳ９５）。
【０１７６】
その後、「タイマ起床中フラグ」が有る（セットされている）か否かを判定する（ステップＳ９７）。「タイマ起床中フラグ」がない（リセットされている）と判定すると（ステップＳ９７で“フラグなし”）、後述の起床要求の送信処理はせずに終了する（ステップＳ９９）。一方、「タイマ起床中フラグ」が有る（セットされている）と判定すると（ステップＳ９７で“フラグあり”）、端末装置１００に起床要求を送信する（ステップＳ１００）。
【０１７７】
図２６または図２８のテーブルを参照することにより、端末装置１００を起床させるケースを、サーバ装置２００の応答内容からユーザデータが書き変わるような状態変化が起こったと判定される場合に限定することができ、一時ファイルやシステムプログラムのアップデートが発生した場合には端末装置１００を起床させないようにして、端末装置１００の消費電力量を低減することができる。
【０１７８】
[実施の形態４]
実施の形態４の仮想環境３１０では、ファイルシステム介した不揮発メモリへの書込みが要求された場合に、書込み先（論理ブロック番号またはファイルパス）と、起床状態で書込んだデータ量（総バイト数）との両方を予め定めた条件とを比較し、比較結果から、端末装置１００への起床要求を送信するか否かを決定する。
【０１７９】
所定条件としては、たとえば、一時ファイルのデータ書込みのケースにはデータ量に関する閾値を大きく（書込みデータ量が少ないならば起床させない）、ユーザデータのような結果が残るケースでは閾値を小さく（少しでも結果が残るならば起床する）するように設定する。これにより、ユーザに非可視で結果に残らなくても一時的な書込みが大量に発生するようなケース（アプリ３１１が一時ファイルを多く保存することで通信の中断などに備えて中途状態でもファイルを残すようにしている、との状況判断から）でも端末装置１００の起床を適度に間引くことができて、消費電力量の削減効果と端末装置１００での通信の効率を得ることができる。
【０１８０】
図３０は、本発明の実施の形態４に係る仮想環境３１０において発生する書込み要求について起床要求を送信するか否かを判定するための参照テーブルを示す図である。図３１は、本発明の実施の形態４に係る仮想電力管理ハードウェアの状態遷移を示す図である。
【０１８１】
図３０では複数のファイルパスのそれぞれに対応して、起床要求の送信許可（図中は丸記号）をするか否かのデータと、書込みデータ量とが対応付けて登録される。図３０では、書込み先をファイルパスで示しているが、マウントポイントで示すとしてもよい。
【０１８２】
図３０によれば、ファイルパス“/data”への書込み総データ量が、起床状態である間に１ＭＢ発生した場合のみ、起床要求の送信を許可している。一方、一時ファイルの格納領域である“/var”の書込み総データ量の閾値を１０ＭＢと設定されて、一時ファイルのデータ書込みの場合には、書込み総データ量の閾値をユーザデータの場合よりも大きく設定している。
【０１８３】
仮想環境３１０では、このテーブルで閾値が設定されているマウントポイント（もしくはファイルパス）毎に、書込み総データ量を保持（記録）しておくための「書込み総量メモリ」を備える。
【０１８４】
ここで、図３０のテーブルの書込み総データ量の閾値は、一回の『起床状態』における書込みデータの総量に係る閾値を示す。
【０１８５】
図３１の（Ａ）を参照して、仮想環境３１０の仮想電力管理ハードウェアの動作を説明する。仮想環境３１０の仮想電力管理ハードウェアは、『低電力状態』において仮想的な割込みを受けると、仮想環境の実行を再開する。このとき、発生した仮想割込みがタイマ割込みであれば、「タイマ起床中フラグ」がセットされる。
【０１８６】
また、『起床状態』において、仮想電力管理ハードウェアの制御レジスタへの書込みが検出されると、仮想環境３１０はプログラムの実行を停止する。この際に「タイマ起床中フラグ」がリセットされる。
【０１８７】
このように、仮想環境３１０がタイマ割込みにより『起床状態』に遷移した後に再び『低電力状態』に遷移するまでの期間は、「タイマ起床中フラグ」がセットされることになる。
【０１８８】
本実施の形態４では、「タイマ起床フラグ」の操作と同時に、マウントポイント毎に用意された上記の「書込み総量メモリ」に０を格納することにより、クリアする。「書込み総量メモリ」のデータは、一度「タイマ起床中フラグ」がセットされてから次にリセットされるまでの間に、ファイルシステムへの書込みデータ量（総バイト数）を示す。
【０１８９】
図３０のテーブルの書込み総データ量の閾値を、一回の『起床状態』における書込みデータの総量に係る閾値としているが、図３１の（Ａ）では、『低電力状態』→『起床状態』への遷移時に、「書込みで総量メモリ」を０にクリアすることで、確実に一回の『起床状態』における書込みデータの総量を記録することができる。
【０１９０】
これに対して、過去の複数回の『起床状態』におけるトータルの書込みデータ量に基づき、起床要求を送信するか否かを決定するとしてもよい。その場合には、図３１の（Ａ）の状態遷移は図３１の（Ｂ）に変更される。図３１の（Ｂ）では、状態遷移する際に「書込み総量メモリ」を０クリアする処理を省いている。
【０１９１】
図３２は、本発明の実施の形態４に係る仮想環境３１０内でファイル更新要求が起こった場合の処理フローチャートである。図３２を参照して、仮想環境３１０のゲストＯＳに対して、アプリ３１１の実行中にファイルパス指定で書込み要求が発生すると、図２９のステップＳ９１〜Ｓ９９の処理と同様のステップＳ１０１〜１０７の処理が実行される。
【０１９２】
その後、ステップＳ１０１で書込みをしたデータ量（バイト数）を、そのファイルが属するマウントポイント（またはファイルパス）に対する「書込み総量メモリ」の値に加算する（ステップＳ１０８）。これにより、「書込み総量メモリ」の値は、一旦起床してからステップＳ８０１の書込み時点までの書込みデータ量（総バイト数）を示すことになる。
【０１９３】
その後、「書込み総量メモリ」の値と図３０で予め設定した閾値と比較し（ステップＳ１０９）、「書込み総量メモリ」の値が閾値よりも大きいと判定すると（ステップＳ１０９で“閾値以上”）、端末装置１００に対して起床要求を送信する（ステップＳ１１１）が、そうでないと判定すると（ステップＳ１０９で“閾値未満”）、起床要求を送信せずに処理を終了する（ステップＳ１１０）。
【０１９４】
端末装置１００では、通信網を介して起床要求を受信すると、端末装置１００内でハードウェア割込みが発生し、端末装置１００は『起床状態』に遷移する。
【０１９５】
図３３は、本発明の実施の形態４に係る仮想環境３１０内でファイル更新要求が起こった場合の他の処理フローチャートである。図３３では、図３２とは異なり、過去の複数回の『起床状態』におけるトータルの書込みデータ量に基づき、起床要求を送信するか否かを決定する。図３３では、図３２のステップＳ１０１〜Ｓ１１１の処理が実行されて端末装置１００へ起床要求が送信された後に、「書込み総量メモリ」が０にクリア（ステップＳ１１２）される。
【０１９６】
このように、本実施の形態では、「タイマ起床中フラグ」と「ファイルパス」の両方の条件が満たされ、且つ「書込み総量メモリ」の値が閾値以上を示す場合のみ、端末装置１００に対して起床要求を送信することにより、ユーザデータが書き変わるような状態変化が起こる場合に端末装置１００が起床できるのはもちろん、アプリ３１１（１１１）が大容量データをダウンロードしユーザから見えない一時ファイルとして保存するような場合でも、アプリ３１１（１１１）での通信効率を考慮しつつ端末装置１００の起床回数を削減することができる。
【０１９７】
（実施の形態５）
実施の形態５において仮想環境３１０では、起床から計時を開始し一定時間経過後に満了するタイマ（以下、「起床後一定時間タイマ」という）を備える。ファイルなどの具体的な仮想デバイス状態の変更有無に関わらず、監視タイマが一定時間を計時終了（タイマが満了）した時点で端末装置１００に起床要求を送信する。
【０１９８】
「起床後一定時間タイマ」を利用することで、ユーザに非可視で結果に残らなくてもＣＰＵなどでの計算量が大きく、ゆえに（そのまま仮想環境３１０側でファイル書込みなどのデバイス変化を待っていると）タイムラグが大きくなってしまうような状況に対して、その状況を予測し、タイムラグを小さくすることができる。
【０１９９】
図３４は、本発明の実施の形態５に係る動作を説明する図である。図３４の（Ａ）は、仮想環境３１０の仮想電力管理ハードウェアの動作状態の遷移を示す。図３４の（Ｂ）は、監視タイマによるタイマが満了したときに、起床要求を送信する処理のフローチャートである。
【０２００】
図３４の（Ａ）を参照して、仮想環境３１０の仮想電力管理ハードウェアが、『低電力状態』において仮想的な割込みを受けると、仮想環境３１０のプログラム実行を再開する。このとき、発生した仮想割込みがタイマ割込みであれば、「タイマ起床中フラグ」がセットされる。また、『起床状態』において、仮想電力管理ハードウェアの制御レジスタへの書込みが検出されると、仮想環境３１０のプログラム実行を停止する。この際に「タイマ起床中フラグ」がリセットされる。このように、仮想環境３１０がタイマ割込みにより起床した後、再び『低電力状態』に遷移するまでの間、「タイマ起床中フラグ」がセットされたままとなる。
【０２０１】
実施の形態５では、「タイマ起床フラグ」の操作と同時に、ホストＯＳの機能により「起床後一定時間タイマ」による計時を開始する。「起床後一定時間タイマ」は設定した一定時間後にタイマが満了し、ホストＯＳから仮想環境３１０に対してタイマ満了イベントが発行される。そして、「起床後一定時間タイマ」は「タイマ起床フラグ」をリセットするのと同時に無効化される。
【０２０２】
図３４の（Ｂ）を参照して、仮想環境３１０内で「起床後一定時間タイマ」が満了した場合の動作を説明する。仮想環境３１０はホストＯＳから「起床後一定時間タイマ」のタイマ満了イベントを入力すると、端末装置１００に起床要求を送信する。
【０２０３】
これにより、起床後一定時間は『低電力状態』に戻らない。つまり『起床状態』が継続され、それだけアプリケーションなどで動作が継続される状態を判別し、端末装置１００を起床させることができる。
【０２０４】
タイマ満了イベントによる起床後、ファイルの書込みなどの具体的に目に見える変化が起こるまでの間にＣＰＵなどにより計算時間を費やす場合などがあり、実際にファイル書込みが発生した時点で端末装置１００を起床させるとすれば、端末装置１００でユーザがその変化を知るまでのタイムラグが大きくなる。
【０２０５】
本実施の形態５では、「起床後一定時間タイマ」を使用することにより、タイムラグが発生しそうな状況を察知し端末装置１００の起床を早めることで、タイムラグを短くすることができる。
【０２０６】
図３５と図３６は、本発明の実施の形態５に係るタイムラグの短縮を説明するグラフである。図３５では、各グラフは縦軸にＣＰＵ負荷・消費電力がとられ、横軸には経過時間がとられている。
【０２０７】
上段のグラフでは、仮想環境３１０においてファイル更新が生じた場合に、「起床後一定時間タイマ」を設けないと、中断のグラフに示すように、端末装置１００が当該ファイル更新を検出するまでのタイムラグが長くなるが、「起床後一定時間タイマ」を設ける場合には下断のグラフに示すように、中断グラフに示したタイムラグを短くすることができる。
【０２０８】
図３６では、図３５において「起床後一定時間経過タイマ」が計時する「一定時間」（閾値）と、「起床後一定時間経過タイマ」の計時開始からタイマ満了までの期間が明示的に示される。
【０２０９】
[実施の形態６]
図３７は、本発明の実施の形態６に係る端末装置１００のＣＰＵの負荷と消費電力量の時間変化を示すグラフである。図３７のグラフは縦軸にＣＰＵの負荷と消費電力量がとられ、横軸に時間経過がとられている。
【０２１０】
図３７の（Ａ）では、ファイル更新（Ａ）とファイル更新（Ｂ）のための２つの『起床状態』が、短い期間の『低電力状態』を挟んで且つ短い時間間隔Δｔの中で個別に存在しているのに対して、図３７の（Ｂ）では、両方のファイル更新が１つの『起床状態』において実行されている。図３７の（Ｂ）では、先に起こったファイル更新（Ａ）（を含む、起床状態）を、仮想環境３１０は起床要求として端末装置１００に送信せずに、その後のファイル更新（Ｂ）が起こったときの起床要求でファイル更新（Ａ）が起こるようにしている。
【０２１１】
端末装置１００ではＯＳのスケジューリングにより、ファイル更新（Ａ）の実デバイスへの書込み待ち中にファイル更新（Ｂ）のためのＣＰＵ上での処理が可能となるため、ファイル更新（Ａ）と（Ｂ）の両方を行うためのトータルの『起床状態』保持時間を短くすることができる。
【０２１２】
このように、実施の形態６では、仮想環境３１０では仮想デバイスへの要求が発生した時点ではすぐには端末装置１００に起床要求を送信せず、予め定めた閾値以内の近い時間の間で発生した要求を、カウンタを用いて間引くことにより、図３７の（Ａ）のように２つの『起床状態』が短い期間の『低電力状態』を挟んで、且つ短い時間間隔の中で存在している間に低電力状態を挟んで発生したファイル更新を、図３７の（Ｂ）のように端末装置１００側では一度の『起床状態』の中で行うことができるようになる。
【０２１３】
２つの『起床状態』に挟まれた『低電力状態』の時間が短く、ＯＳのスケジューリングの効果などにより２つの『起床状態』の時間内でアプリ処理を実行するよりも、１つの『起床状態』時間内で実行する方が、消費電力量が減るとの効果が奏されることが知られている。図３７の（Ｂ）に示す本実施の形態によれば、当該効果を奏することができる。
【０２１４】
図３８は、本発明の実施の形態６に係る仮想環境３１０内でアプリ３１１から描画要求が起こった場合の処理フローチャートである。なお、アプリ３１１の実行開始に先立って、図３８のフローチャート中で参照される「更新ありフラグ」は予めリセットされていると想定する。
【０２１５】
図３８を参照して、アプリ３１１から描画要求が起こった場合、描画要求に従い仮想環境３１０内の仮想ＶＲＡＭのデータを更新する（ステップＳ１２１）。その後、処理部３０１は「タイマ起床中フラグ」の値を判定し（ステップＳ１２３）、「タイマ起床中フラグ」がリセットされていると判定した場合には（ステップＳ１２３で“フラグなし”）、ステップＳ１２７以降の起床要求に関する処理をせずに処理を終了する（ステップＳ１２５）。
【０２１６】
一方、「タイマ起床中フラグ」がセットされていると判定した場合には（ステップＳ１２３で“フラグあり”）、「更新ありフラグ」の値を判定する（ステップＳ１２７）。つまり、「タイマ起床中フラグ」がセットされている（有効である）場合には、既に直近で発生した描画要求によるＶＲＡＭのデータ更新を検出するために、「更新ありフラグ」の値を判定する。
【０２１７】
「更新ありフラグ」がまだセットされていない（すなわち、まだ閾値以内の一定の短い時間内で（直近で）発生した描画要求によるＶＲＡＭのデータ更新はない）と判定すると（ステップＳ１２７で“「更新ありフラグ」なし”）、「更新ありフラグ」をセットするだけで、起床要求に関する処理をせずに終了する（ステップＳ１２９）。
【０２１８】
「更新ありフラグ」が既にセットされていると判定すると（ステップＳ１２７で“「更新ありフラグ」あり”）、端末装置１００へ起床要求を送信する（ステップＳ１３１）。これにより、直近で発生した描画要求によるＶＲＡＭのデータ更新と合わせて今回の描画要求によるＶＲＡＭのデータ更新を端末装置１００に実行させるために、端末装置１００を起床させることができる。
【０２１９】
処理部３０１は、端末装置１００へ起床要求を送信後は、端末装置１００への通知が保留されている描画要求によるＶＲＡＭのデータ更新はなくなったことから、「更新ありフラグ」をリセットする（ステップＳ１３１）。
【０２２０】
なお、上記の閾値は、すなわち描画要求によるＶＲＡＭのデータ更新を、起床要求によって端末装置１００へ通知するのを保留する時間期間の長さを示し、この閾値は、可変に変更することができる。
【０２２１】
端末装置１００は、ステップＳ１３０で送信された起床要求により起床する。起床する際に、図２1で示した端末装置１００による保留タイマリストのチェックにおいて、保留されていた、すなわち間引かれていたイベントデータの分まで含めてイベントが発行される。したがって、端末装置１００側では、先の描画要求については「更新ありフラグ」をセットするだけで起床要求を送信しなかったＶＲＡＭのデータ更新（ステップＳ１２９を参照）と合わせて今回の描画要求によるＶＲＡＭのデータ更新を実行することができる（図３７の（Ｂ）を参照）。
【０２２２】
本実施の形態６では「更新ありフラグ」を「セット」，「リセット」の２値とすることで、最大２つの更新要求を統合する（図３７の（Ｂ）のファイル更新（Ａ）と（Ｂ）を参照）ことにしているが、「更新ありフラグ」をカウンタの変数として用いれば、３回以上の更新要求を統合することも可能である。
【０２２３】
図３９は、本発明の実施の形態６に係る仮想環境３１０の仮想電力管理ハードウェアの動作を説明するための図である。図３９を参照して、仮想環境３１０の仮想電力管理ハードウェアは、『低電力状態』において仮想的な割込みを受けると、仮想環境３１０におけるプログラムの実行を再開する。このとき、発生した仮想割込みがタイマ割込みであれば、「タイマ起床中フラグ」を立てる（セットする）。
【０２２４】
また、『起床状態』において仮想電力管理ハードウェアの制御レジスタへの書込みが検出されると、仮想環境３１０におけるプログラムの実行を停止する。この際に「タイマ起床中フラグ」が落とされる（リセットされる）。
【０２２５】
このように、仮想環境３１０がタイマ割込みにより起床した後、再び『低電力状態』に遷移するまでの間、「タイマ起床中フラグ」が立っていることになる。
【０２２６】
本実施の形態６では、『低電力状態』には、『起床状態』から移行して予め定めた閾値以上の時間期間が経過していない状態である「低電力状態（Ａ）」と、閾値以上の時間期間が経過した「低電力状態（Ｂ）」とを含む。
【０２２７】
「低電力状態（Ａ）」から「低電力状態（Ｂ）」への遷移は、ホストＯＳからのタイマイベントの発行により遷移し、遷移する際に「更新ありフラグ」が立っている（セットされている）か否かが判定される。
【０２２８】
「低電力状態（Ａ）」から「低電力状態（Ｂ）」への遷移の際に「更新ありフラグ」が立っている（セットされている）場合には、すなわち端末装置１００に送信するべき起床要求が保留されたままになっている場合には、端末装置１００へ起床要求を送信した上で「更新ありフラグ」をリセットする。
【０２２９】
[実施の形態の効果]
上述の各実施の形態について奏される効果を説明する。なお、上記の実施の形態1〜６は適宜組合わせて構成するとしてよい。
【０２３０】
（実施の形態１の概要と効果）
図４０、図４１および図４２は、本発明の実施の形態１に係る概要と効果を説明するための図である。なお、図４０の丸付き数値は、以下の説明では括弧付き数値で示す。
【０２３１】
図４０を参照して、サーバ装置２００と端末装置１００を含むネットワークシステムにおいて、端末装置１００をエミュレートできる仮想環境３１０を搭載するゲートウェイ装置３００を設ける。端末装置１００は通信網６０を介し仮想環境３１０と通信可能な「端末装置１００と仮想環境３１０の同期」状態においては、タイマイベントなどでのサーバ装置２００へのポーリングを休止する。休止期間において生成される周期タイマデータによるイベント発行を休止し、当該タイマデータを保留タイマリストに登録する。
【０２３２】
仮想環境３１０では、端末装置１００が実行するアプリ１１１と同じアプリ３１１が実行されて、端末装置１００が通信網６０を介して通信可/不可に関わらず、プログラム実行中にサーバ装置２００へネットワーク５０を介しアクセスする（図４０の処理（１）と（２））。
【０２３３】
仮想環境３１０は、ゲストＯＳ(実端末装置１００の実ＯＳと同じ)を介して仮想ハードウェア上のＶＲＡＭまたは不揮発メモリなどのデバイスへのアクセスを監視する機能を有する（図４０の処理（３））。
【０２３４】
上記のアクセスによりサーバ装置２００から受信する応答内容に変化があった場合に、仮想環境３１０内の表示更新（＝ＶＲＡＭの書換え）またはデータ（不揮発メモリのデータ）書換えがあったときにのみ、仮想環境３１０は端末装置１００に対し、起床要求を通信網６０を経由し送信する（図４０の処理（４）と（５））。
【０２３５】
端末装置１００は起床要求を受信すると、実ＯＳは起床要求を割込みとして起床する。端末装置１００は起床するとアプリ１１１の実行が再開（開始）される。また、保留タイマリストに登録のタイマデータに基づき発行されるイベントにより、サーバ装置２００へアクセス要求が送信される。端末装置１００は、当該アクセス要求に対応した応答内容をサーバ装置から受信する（図４０の処理（６）と（７））。
【０２３６】
なお、端末装置１００のアプリ１１１は、仮想環境３１０および仮想環境３１０により実行されるアプリ３１１を意識しておらず、直接にサーバ装置２００にアクセスする。したがって、端末装置１００上のアプリ１１１は、仮想環境３１０またはアプリ３１１を意識する特別な機能を備える必要はない。
【０２３７】
なお、サーバ装置２００へのポーリングを休止する期間においても、ユーザが手でキーパッドを操作した場合のサーバ装置２００へのアクセスを妨げることはしない。ユーザが直接意識しないバックグラウンドでのタイマイベントなどだけを休止するものとする。
【０２３８】
図４１のグラフの縦軸には、ＣＰＵ負荷または消費電力量がとられ、横軸には経過時間がとられる。図４１の上段のグラフは、従来の起床回数を示し、下段は実施の形態１による起床回数を示す。下段のグラフによれば、「端末装置１００と仮想環境３１０の同期」が取れている期間では、端末装置１００側での（タイマ）イベントの発行、及びそれに伴うサーバ装置２００との通信回数が、図４１の上段グラフの回数に比べて削減されることがわかる。
【０２３９】
これに対し、図４２の（Ａ）に示す従来のネットワークシステムでは、仮想環境３１０を搭載するゲートウェイ装置を備えないことから、図４２の（Ｂ）に示すように、端末装置のアプリは（画面が表示されていない状態でも）定期的に起床し、サーバ装置にアクセスする必要がある。ユーザが確認（視認）可能な端末装置１００の出力変化（画面を点灯するか、内部不揮発メモリ上のデータを書換える、など）は、サーバ装置からの応答内容の変化に依存することから、従来は無駄な起床も発生していると言える。
【０２４０】
したがって、図４０と図４１に示す実施の形態１によれば、端末装置１００の電力消費量を少なくできて、着信の待受け時間を従来に比べて長期化できる。
【０２４１】
また、アプリとしては端末装置１００で実行可能であればよく、またpush型のサービスを立ち上げる必要もない。それゆえに、アプリ開発において省電力化のためのコストが抑えられる。また、既存のアプリでも省電力化が見込める。ＯＳ部分の差分も少なくなるため、端末装置１００のＯＳをアップデートした場合にも仮想環境３１０側のゲストＯＳを容易に置換することができる。
【０２４２】
（実施の形態２の効果）
実施の形態２では、仮想環境３１０がサーバ装置２００から受信する応答内容に、ユーザが確認（視認）可能な出力の変化を検出したときに端末装置１００を起床させるが、この起床に関する条件に、ユーザが確認（視認）可能な出力の変化を描画やサウンドの変化など情報の種類を限定することにより、実際にユーザの目に見える形で出力の変化が起こるまでは起床させないようにすることができて、端末装置１００の電力消費量を抑制することができる。
【０２４３】
（実施の形態３の効果）
実施の形態３では、サーバ装置２００から受信する応答内容から仮想環境３１０が不揮発メモリにデータが書込む場合には、ユーザが確認（視認）可能なデータ量の変更が起こる場合にのみ、端末装置１００を起床させる。このことで、実際にユーザの目に見える形で出力の変化が起こるまでは起床させないようにすることができて、端末装置１００の電力消費量を抑制することができる。
【０２４４】
（実施の形態４の効果）
実施の形態４では、アプリ１１１がユーザに非可視な一時ファイルだけで端末装置１００を長時間起床させるような場合でも、またダウンロード動作などにより中途のダウンロード結果などを一時ファイルとして蓄えるような場合でも、端末装置１００の起床回数を削減することができる。
【０２４５】
（実施の形態５の効果）
実施の形態５では、アプリ１１１が端末装置１００の起床後に大量の計算などを行う性質を持ち、実際にユーザに見える形でファイルや描画などの出力を開始するまでに時間がかかるような場合でも、当該時間が長くなりそうと判断した時点で、端末装置１００を起床させることができ、実際にファイルや描画などの出力をしてユーザが視認できるまでに要するタイムラグを軽減することができる（図３５参照）。
【０２４６】
（実施の形態６の効果）
実施の形態６では、短時間内に複数の『起床状態』と『低電力状態』が発生するような場合に、ユーザが視認できる出力とするためのデバイスからの更新要求に従って、仮想環境３１０側で端末装置１００を起床させる回数を間引き、端末装置１００ではファイル更新処理などを短期間の『起床状態』において集中的に実行する。これにより、端末装置１００の起床回数を削減し、消費電力量を削減することができる（図３７の（Ｂ）参照）。
【０２４７】
（プログラムについて）
仮想環境３１０と端末装置１００のそれぞれにおいて、各フローチャートはプログラムとして記憶領域に格納される。
【０２４８】
端末装置１００では、ＯＳ、アプリ１１１のプログラムおよび各フローチャートのプログラムは、端末装置１００内の不揮発メモリの中に非一時的に記録（格納）される。処理部１０１のＣＰＵはプログラムを不揮発メモリから読出し、実行する。
【０２４９】
不揮発メモリは、端末装置１００内の書換え不可能なＲＯＭやフラッシュメモリであっても、ネットワークからのダウンロードなどで書換え可能なフラッシュメモリやディスクであってもよい。
【０２５０】
仮想環境３１０では、ＯＳ、アプリ１１１のプログラムおよび各フローチャートのプログラムは、仮想ハードウェア上のメモリに非一時的に格納される。格納用のメモリには、
仮想環境３１０内の仮想不揮発メモリが含まれる。この不揮発メモリは、仮想環境３１０内の書換え不可能なＲＯＭやフラッシュメモリであっても、ネットワークからのダウンロードなどで書換え可能なフラッシュメモリやディスクであってもよい。
【０２５１】
今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【０２５２】
５０  通信ネットワーク、６０  通信網、１００  端末装置、１１１，３１１  アプリ、２００  サーバ装置、３００  ゲートウェイ装置、３１０  仮想環境。
【図１】
2014082571.tif 000003
【図２】
2014082571.tif 000004
【図３】
2014082571.tif 000005
【図４】
2014082571.tif 000006
【図５】
2014082571.tif 000007
【図６】
2014082571.tif 000008
【図７】
2014082571.tif 000009
【図８】
2014082571.tif 000010
【図９】
2014082571.tif 000011
【図１０】
2014082571.tif 000012
【図１１】
2014082571.tif 000013
【図１２】
2014082571.tif 000014
【図１３】
2014082571.tif 000015
【図１４】
2014082571.tif 000016
【図１５】
2014082571.tif 000017
【図１６】
2014082571.tif 000018
【図１７】
2014082571.tif 000019
【図１８】
2014082571.tif 000020
【図１９】
2014082571.tif 000021
【図２０】
2014082571.tif 000022
【図２１】
2014082571.tif 000023
【図２２】
2014082571.tif 000024
【図２３】
2014082571.tif 000025
【図２４】
2014082571.tif 000026
【図２５】
2014082571.tif 000027
【図２６】
2014082571.tif 000028
【図２７】
2014082571.tif 000029
【図２８】
2014082571.tif 000030
【図２９】
2014082571.tif 000031
【図３０】
2014082571.tif 000032
【図３１】
2014082571.tif 000033
【図３２】
2014082571.tif 000034
【図３３】
2014082571.tif 000035
【図３４】
2014082571.tif 000036
【図３５】
2014082571.tif 000037
【図３６】
2014082571.tif 000038
【図３７】
2014082571.tif 000039
【図３８】
2014082571.tif 000040
【図３９】
2014082571.tif 000041
【図４０】
2014082571.tif 000042
【図４１】
2014082571.tif 000043
【図４２】
2014082571.tif 000044