JP2014123347A - クライアント端末、サーバ、及び分散処理方法 - Google Patents

Abstract

【課題】クライアント端末での電力消費量を抑制すると同時に、アプリケーションを円滑に実行する。
【解決手段】モード切替部３１２は、実行対象となるアプリケーションがクライアント端末１０１にとって高負荷のアプリケーションである場合、単体処理モードから分散処理モードに切り替える。一方、モード切替部３１２は、サーバ１０２から単体処理モードへの切替通知を受信すると、分散表示処理部３１１によるアプリケーションの表示処理を停止させ、アプリケーションの実行方式を単体処理モードに設定する。
【選択図】図３

Description

本発明は、サーバとクライアント端末とが互いに連携して処理を行うことで、様々なアプリケーションに対する処理を効率的に実行する分散処理技術に関するものである。

特許文献１には、シンクライアントシステムにおいて、サーバからクライアント端末に送信される処理結果のデータ量の削減を目的として、以下の技術が開示されている。すなわち、端末装置に画像を送信する第１送信部と、フレーム間での変化が閾値を超える領域を画像から抽出し、抽出した領域の画像を第１送信部よりも高いフレームレートで圧縮して送信する第２送信部とを備え、第１送信部で送信される画像と第２送信部で送信される画像とを同期表示させる。

特開２０１２−１５８６８号公報

しかしながら、特許文献１では、画面更新がされる毎に通信が発生するため、例えばユーザにより画像をスクロールさせる操作が頻繁に入力された場合、通信されるデータ量が膨大となり、クライアント端末の電力消費量が増大するという課題がある。特に、クライアント端末が据え置き機器ではなくモバイル端末（例えばタブレット端末）の場合、バッテリー容量に制限があるため、通信されるデータ量が膨大になると、直ぐに電池切れになるという課題がある。

本発明の目的は、クライアント端末での電力消費量を抑制すると同時に、アプリケーションを円滑に実行することができる分散処理の技術を提供することである。

本発明の一態様によるクライアント端末は、ネットワークを介して通信可能に接続されたサーバと連携してアプリケーションを実行するクライアント端末であって、前記アプリケーションの実行結果である画像データを表示する表示部と、前記クライアント端末に前記アプリケーションを実行させる単体処理モードと、前記サーバに前記アプリケーションを実行させる分散処理モードとのいずれかにアプリケーションの実行方式を切り替えるモード切替部と、前記単体処理モードにおいて、前記アプリケーションを実行するアプリケーション実行部と、前記分散処理モードにおいて、前記アプリケーションの実行結果を示す画像データを前記サーバから受信し、前記表示部に表示する分散表示処理部とを備え、前記モード切替部は、前記クライアント端末にとって前記アプリケーションが高負荷のアプリケーションである場合、前記実行方式を前記分散処理モードに切り替える。

本発明によれば、クライアント端末での電力消費量を抑制すると同時に、アプリケーションを円滑に実行することができる。

本発明の実施の形態１におけるクライアント端末及びサーバの利用形態の一例を示す図である。 （Ａ）分散処理モードにおいてアプリケーションが実行される様子の一例を示す図である。（Ｂ）単体処理モードにおいてアプリケーションが実行される様子の一例を示す図である。 実施の形態１におけるクライアント端末及びサーバの機能構成の一例を示すブロック図である。 負荷判定部による判定処理の概要の説明図である。 負荷判定部による判定処理の詳細の説明図である。 実施の形態１において、クライアント端末及びサーバがアプリケーションを起動する際の処理の一例を示すフローチャートである。 記録負荷情報に基づく判定処理の一例を示すフローチャートである。 メモリに記録された負荷情報が纏められた記録負荷情報のデータ構成の一例を示す図である。 分散処理モードの処理の一例を示すフローチャートである。 単体処理モードの処理の一例を示すフローチャートである。 クライアント端末及びサーバ間で実行されるアプリケーションの実行状態の引き継ぎを示す図である。 単体処理モードの実行中において、実行方式が分散処理モードに切り替えられる際にユーザに通知されるメッセージ画像の一例を示した図である。 実施の形態２におけるクライアント端末及びサーバの機能構成の一例を示すブロック図である。 実施の形態２において、クライアント端末及びサーバがアプリケーションを起動する際の処理の一例を示すフローチャートである。 実施の形態２における単体処理モードの処理の一例を示すフローチャートである。 実施の形態２において、単体処理モードの実行中にクライアント端末の負荷が高負荷になった場合に、そのことをユーザに通知するための通知画像の一例を示した図である。 図１５に示すフローチャートの変形例のフローチャートである。 クライアント端末及びサーバのそれぞれを実現するコンピュータのハードウェア構成の一例を示す図である。

（実施の形態による分散処理システムに至った経緯）
クライアント端末からの操作要求に基づき、サーバが、アプリケーションを実行してその実行結果を示す画像データをクライアント端末に送信し、クライアント端末が、その画像データを表示するリモートデスクトップ技術が知られている。このリモートデスクトップ技術によれば、ユーザは手元のクライアント端末を用いてネットワークに存在するサーバを操作することができる。

しかしながら、リモートデスクトップ技術では、サーバからクライアント端末に送信される画像データが膨大になると、処理結果の送信遅延が発生し、ユーザにストレスを与える可能性がある。

一方、サーバ及びクライアント端末間の通信を避けるために、すべてのアプリケーションをモバイル端末上で実行することも考えられる。しかしながら、モバイル端末では発熱の問題からＣＰＵの性能に制約があり、サーバほど高速にアプリケーションを実行することができない。そのため、高負荷なアプリケーションを円滑に動作させることができないという問題が発生する。

そこで、本実施の形態では、クライアント端末及びサーバ間で通信されるデータ量を削減してクライアント端末での電力消費量を抑制すると同時に、アプリケーションを円滑に実行することができる分散処理システムを提供することを目的とする。以下、詳細に説明する。

（実施の形態１）
図１は、本発明の実施の形態１の分散処理システムに適用されるクライアント端末１０１及びサーバ１０２の利用形態の一例を示す図である。クライアント端末１０１は、例えば、タブレット端末、スマートフォン、或いはノートＰＣ等のディスプレイ付き携帯端末により構成される。また、クライアント端末としては、例えば通信機能を有する白物家電（例えば冷蔵庫、洗濯機、電子レンジなど）であってディスプレイを搭載するものをクライアント端末１０１としても良い。サーバ１０２は、インターネット上の様々なＷＥＢ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）サービスやＷＥＢアプリケーション（以下、単にアプリケーションと記述する。）を仲介するサーバである。クライアント端末１０１はサーバ１０２を介してインターネット上のＷＥＢサービスやアプリケーションを実行する。

図２（Ａ）、（Ｂ）は、クライアント端末１０１及びサーバ１０２が連携して、アプリケーションを実行する様子の一例を示した図である。アプリケーションの実行主体は、アプリケーションの負荷に応じて異なる。

図２（Ａ）は、分散処理モードにおいてアプリケーションが実行される様子の一例を示す図である。図２（Ａ）では、高負荷のアプリケーションが連携して実行されている。高負荷のアプリケーションとしては、例えば、レンダリングが多用される３次元のコンピュータグラフィックスのアプリケーションや、複数の動画を同時に再生するアプリケーション等が挙げられる。

アプリケーションが高負荷である場合、アプリケーションはサーバ１０２で実行される。クライアント端末１０１は、サーバ１０２からアプリケーションの実行結果を示す画像データを受信し、表示部に表示する。この場合、クライアント端末１０１は、アプリケーションのパースやロードを行う必要はなく、単にサーバ１０２から送信される画像データを表示するディスプレイ端末として機能する。

図２（Ｂ）は、単体処理モードにおいてアプリケーションが実行される様子の一例を示す図である。図２（Ｂ）では低負荷のアプリケーションが実行されている。低負荷のアプリケーションとしては、例えば、テキスト及び静止画のみを表示するアプリケーションや、２つ以上の動画を同時再生しないアプリケーション等が挙げられる。

アプリケーションが低負荷である場合、アプリケーションはクライアント端末１０１により実行される。この場合、クライアント端末１０１は、アプリケーションのパースやロードが必要となり、自身で実行したアプリケーションの実行結果を示す画像を表示部に表示する。一方、サーバ１０２は、アプリケーションを実行せず、単にクライアント端末１０１にアプリケーションを転送するだけの転送サーバとして機能する。なお、本実施の形態では、アプリケーションとしては、例えば、ＨＴＭＬ５や、ＪＡＶＡＳＣＲＩＰＴ（登録商標）等のマークアップ言語で記述されたものが採用される。

図３は、実施の形態１におけるクライアント端末１０１及びサーバ１０２の機能構成の一例を示すブロック図である。図３に示すように、クライアント端末１０１は、分散表示処理部３１１、低負荷アプリ実行部３１０（アプリケーション実行部の一例）、モード切替部３１２、通知部３１６、表示部３１８、及び操作部３１９を含む。

分散表示処理部３１１は、分散処理モードにおいて、アプリケーションの実行結果を示す画像データをサーバ１０２から受信し、表示部３１８に表示する機能と、分散処理モードにおいて、クライアント端末１０１に対してユーザが行った操作をサーバ１０２に通知する機能とを含む。具体的には、分散表示処理部３１１は、画像受信部３１４、画像表示部３１５、ＵＯ（ユーザオペレーション）イベント配信部３１３を含む。

画像受信部３１４は、サーバ１０２から実行結果として送信される画像データを受信し、受信した画像データをデコードする。サーバ１０２から送信される画像データのフォーマットとしては、無圧縮画像のフォーマットや、圧縮画像のフォーマットがある。無圧縮画像のフォーマットとしては、例えばビットマップ形式がある。圧縮画像のフォーマットとしては、フレームのそれぞれが圧縮された連続する画像データにより構成されるフォーマット（例えば、ＭｏｔｉｏｎＪＰＥＧ形式）や、フレーム間で圧縮されたデータから構成される動画データのフォーマット（例えば、Ｈ．２６４形式）がある。したがって、画像受信部３１４は、サーバ１０２から送信される画像データのフォーマットに応じたデコード方式で画像データをデコードすればよい。

また、画像受信部３１４は、サーバ１０２から送信される実行結果に音声データが含まれていれば、更に音声データをデコードする。サーバ１０２から送信される音声データのフォーマットとしては、無圧縮音声データ（例えば、ＰＣＭ；Ｐｕｌｓｅ Ｃｏｄｅ Ｍｏｄｕｌａｔｉｏｎ形式）のフォーマットや、圧縮音声データ（例えば、ＡＡＣ；Ａｄｖａｎｃｅｄ Ａｕｄｉｏ Ｃｏｄｉｎｇ形式）のフォーマット等がある。したがって、画像受信部３１４は、送信される音声データのフォーマットに応じたデコード方式で音声データをデコードすればよい。なお、画像受信部３１４は、クライアント端末１０１がスピーカを保有していない場合や、サーバ１０２から送信される実行結果に音声データが含まれていない場合、音声データをデコードする処理をスキップすればよい。

画像表示部３１５は、画像受信部３１４でデコードされた画像データをフレームバッファ（図略）に書き込み、表示部３１８に表示する。また、画像表示部３１５は、実行結果に音声データが含まれる場合は、画像受信部３１４でデコードされた音声データが示す音声をスピーカ（図略）から出力させる。

ＵＯイベント配信部３１３は、ユーザが操作部３１９を操作することで入力されたアプリケーションに対するユーザ操作を検知し、検知したユーザ操作の内容を示すＵＯイベントをサーバ１０２へ送信する。ユーザ操作としては、例えば画面のタッチ、マウスのクリック、及びキーボードのキーを押す操作等が挙げられる。

ＵＯイベント配信部３１３は、例えば、ユーザ操作がタッチ又はクリックの場合、タッチ又はクリックされた画面上の座標を含むＵＯイベントをサーバ１０２に送信する。また、ＵＯイベント配信部３１３は、ユーザ操作がキー操作であれば、押されたキーを示すＵＯイベントをサーバ１０２へ送信する。サーバ１０２は、ＵＯイベント配信部３１３から送信されたＵＯイベントが示すユーザ操作に基づいてアプリケーションの処理を進行させる。

低負荷アプリ実行部３１０は、例えば、ＨＴＭＬブラウザ等のアプリケーション実行エンジンにより構成される。そして、低負荷アプリ実行部３１０は、単体処理モードにおいて、アプリケーションを取得し、取得したアプリケーションをパースし、アプリケーションを実行する。ここで、実行対象となるアプリケーションはクラウド又はＷＥＢサーバ上に存在し、低負荷アプリ実行部３１０は、アプリケーションをダウンロードして取得する。

ここで、低負荷アプリ実行部３１０は、クラウド又はＷＥＢサーバから直接、アプリケーションをダウンロードするのではなく、サーバ１０２を経由してアプリケーションをダウンロードする。アプリケーションは、サーバ１０２を経由することで、サーバ１０２により、クライアント端末１０１にとって、高負荷又は低負荷であるかが判定される。サーバ１０２により、アプリケーションがクライアント端末１０１にとって低負荷と判定されれば、低負荷アプリ実行部３１０にアプリケーションのデータが送信され、低負荷アプリ実行部３１０でアプリケーションが実行される。一方、サーバ１０２により、アプリケーションがクライアント端末１０１にとって高負荷と判定されれば、低負荷アプリ実行部３１０にアプリケーションのデータが送信されない。この場合、サーバ１０２からモード切替部３１２に分散処理モードに切り替える切替通知が送信され、分散表示処理部３１１が起動され、分散処理モードでアプリケーションが実行される。

モード切替部３１２は、実行対象となるアプリケーションがクライアント端末１０１にとって高負荷のアプリケーションである場合、単体処理モードから分散処理モードに切り替える。ここで、モード切替部３１２は、サーバ１０２から実行方式の切替通知を受け取り、切替通知が示す内容に応じて、分散処理モードと単体処理モードとの切り替えを行う。

分散処理モードとは、アプリケーションの実行処理がサーバ１０２に割り当てられ、アプリケーションの表示処理がクライアント端末１０１に割り当てられたモードである。分散処理モードでは、実行処理及び表示処理を行う機器が分散しており、複数の機器間で連携しながらアプリケーションが処理される。

単体処理モードとは、実行処理及び表示処理の両方が１つの機器に割り当てられたモードである。単体処理モードでは、１つの機器が単体でアプリケーションを処理する。

モード切替部３１２は、サーバ１０２から分散処理モードへの切替通知を受信すると、低負荷アプリ実行部３１０によるアプリケーションの実行処理を停止させ、現在のアプリケーションの実行状態を示す実行状態情報を低負荷アプリ実行部３１０からサーバ１０２に送信させる。そして、モード切替部３１２は、分散表示処理部３１１を起動させ、アプリケーションの実行方式を分散処理モードに切り替える。

一方、モード切替部３１２は、サーバ１０２から単体処理モードへの切替通知を受信すると、分散表示処理部３１１によるアプリケーションの表示処理を停止させる。そして、モード切替部３１２は、サーバ１０２から送信された実行状態情報から、現在のアプリケーションの実行状態を低負荷アプリ実行部３１０に引き継がせ、アプリケーションの実行方式を単体処理モードに設定する。

アプリケーションの実行状態の引き継ぎは、低負荷アプリ実行部３１０及び高負荷アプリ実行部３０４間で実行状態情報が送受されることで行われる。実行状態情報としては、実行中のアプリケーションの保存先を示す情報（例えば、ＵＲＬ；Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）や、アプリケーションの現在の実行状態を示す情報（例えば、ＨＴＴＰＣｏｏｋｉｅ）や、アプリケーションに関するストレージデータ等が挙げられる。

通知部３１６は、負荷判定部３０１がアプリケーションの負荷が高負荷であるか否かを判定するために必要となる端末情報を高負荷アプリ実行部３０４に通知する。端末情報は性能情報及び負荷情報を含む。性能情報は、クライアント端末１０１の性能を示す静的な情報であり、例えば、クライアント端末１０１が使用するＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）のバージョン、クライアント端末１０１のＣＰＵのクロック数、及びクライアント端末１０１が搭載するメモリ容量等を含む。負荷情報は、動的に変化するクライアント端末１０１の負荷を示す情報であり、例えば、現在のＣＰＵ利用率、メモリ消費量、及び描画フレームレート等を含む。

表示部３１８は、液晶パネルや有機ＥＬパネル等の表示装置により構成され、アプリケーションの実行結果である画像データを表示する。具体的には、表示部３１８は、分散処理モードにおいては、分散表示処理部３１１により受信された画像データを表示し、単体処理モードにおいては、低負荷アプリ実行部３１０によるアプリケーションの実行結果である画像データを表示する。

操作部３１９は、タッチパネル、キーボード、マウス等の操作装置により構成され、ユーザ操作を受け付ける。

以上がクライアント端末１０１の機能構成である。

サーバ１０２は、負荷判定部３０１、切替通知部３０２、分散処理実行部３０３、及びメモリ３１７を含む。分散処理実行部３０３は、高負荷アプリ実行部３０４（サーバ側アプリケーション実行部の一例）、スクリーンキャプチャ３０５、音声レコーダ３０６、エンコーダ３０７、画像配信部３０８、及びＵＯイベント受信部３０９を含む。

負荷判定部３０１は、実行対象となるアプリケーションがクライアント端末１０１にとって高負荷のアプリケーションであるか、低負荷のアプリケーションであるかを判定する。

ここで、負荷判定部３０１は、通知部３１６から通知される端末情報と、アプリケーションにより規定されたアプリ情報とに基づいて高負荷であるか否かを判定する。

具体的には、負荷判定部３０１は、端末情報に含まれる性能情報がアプリ情報に含まれる性能条件を満たす場合、実行対象のアプリケーションがクライアント端末１０１にとって低負荷のアプリケーションと判定し、性能情報が性能条件を満たさない場合、実行対象のアプリケーションがクライアント端末１０１にとって高負荷のアプリケーションと判定する。そして、負荷判定部３０１は、高負荷のアプリケーションと判定した場合、分散処理モードに切り替える切替通知を、切替通知部３０２を介してモード切替部３１２に通知し、低負荷のアプリケーションと判定した場合、単体処理モードに切り替える切替通知を切替通知部３０２を介してモード切替部３１２に通知する。

また、負荷判定部３０１は、単体処理モードにおいて、クライアント端末１０１の負荷を監視し、負荷が規定値を超えた場合、分散処理モードへの切替通知を、切替通知部３０２を介してモード切替部３１２に通知する。ここで、負荷判定部３０１は、通知部３１６から定期的に送信される負荷情報を受信することで、クライアント端末１０１の負荷を監視すればよい。なお、通知部３１６は、クライアント端末１０１のＯＳから負荷情報を取得すればよい。

アプリケーションによっては性能条件が規定されていないものも存在する。この場合、負荷判定部３０１は、まず、単体処理モードに切り替える切替通知を切替通知部３０２を介してモード切替部３１２に通知し、実行方式を単体処理モードに設定しておく。そして、負荷判定部３０１は、クライアント端末１０１の負荷を監視し、負荷が規定値を超えた場合、分散処理モードへの切替通知を、切替通知部３０２を介してモード切替部３１２に通知すればよい。

また、負荷判定部３０１は、実行対象のアプリケーションの負荷の監視結果をメモリ３１７に記録しておく。そして、負荷判定部３０１は、アプリケーションの起動時にメモリ３１７を参照し、該当するアプリケーションの監視結果として高負荷を示す監視結果が記録されていれば、該当するアプリケーションは高負荷のアプリケーションであると判定する。そして、負荷判定部３０１は、分散処理モードへの切替通知を、切替通知部３０２を介してモード切替部３１２に通知すればよい。

一方、実行対象となるアプリケーションがクライアント端末１０１によって初めて実行される場合、メモリ３１７に監視結果が記録されていない。この場合、負荷判定部３０１は、まず、単体処理モードに切り替える切替通知を、切替通知部３０２を介してモード切替部３１２に通知し、実行方式を単体処理モードに設定しておく。そして、負荷判定部３０１は、クライアント端末１０１の負荷を監視し、負荷が規定値を超えた場合、分散処理モードに切り替える切替通知を、切替通知部３０２を介してモード切替部３１２に通知すればよい。

切替通知部３０２は、負荷判定部３０１により実行対象のアプリケーションが高負荷のアプリケーションであると判定された場合、分散処理モードに切り替える切替通知をモード切替部３１２に通知する。一方、切替通知部３０２は、負荷判定部３０１により実行対象のアプリケーションが低負荷のアプリケーションであると判定された場合、単体処理モードに切り替える切替通知をモード切替部３１２に通知する。

高負荷アプリ実行部３０４は、例えば、ＨＴＭＬブラウザ等のアプリケーション実行エンジンにより構成され、負荷判定部３０１により実行対象のアプリケーションが高負荷のアプリケーションであると判定された場合、当該アプリケーションをパースし、当該アプリケーションを実行する。

なお、高負荷アプリ実行部３０４の基本的な機能は、低負荷アプリ実行部３１０と同じである。但し、サーバ１０２の方がクライアント端末１０１に比べ、ＣＰＵ、メモリ等の性能が高いのが一般的である。そのため、高負荷アプリ実行部３０４は、高負荷のアプリケーションを実行することができる。

スクリーンキャプチャ３０５は、高負荷アプリ実行部３０４がアプリケーションを実行することでグラフィックメモリ（図略）に書き込んだ画像データをエンコードバッファ（図略）にキャプチャする。

通常、グラフィックメモリに書き込まれたレンダリングされた画像データは、処理を行った機器に直接接続された表示機器に出力される。しかしながら、本実施の形態では、画像データは、遠隔にあるクライアント端末１０１の表示部３１８に表示される。そのため、スクリーンキャプチャ３０５は、エンコーダ３０７に画像データをエンコードさせるために、画像データをエンコードバッファ（図略）にキャプチャしている。なお、画像データのキャプチャ間隔は、短くなるにつれて、クライアント端末１０１で表示されるアニメーションや動画が滑らかになるため好ましいが、キャプチャ間隔を過度に短くするとクライアント端末１０１に送信する画像データのデータ量が増大するため好ましくない。そこで、キャプチャ間隔としては、サーバ１０２の性能及びネットワーク帯域幅に余裕があれば６０ｆｐｓ程度が好ましい。

音声レコーダ３０６は、高負荷アプリ実行部３０４がアプリケーションを実行することでサウンドメモリ（図略）に書き込んだ音声データをエンコードバッファ（図略）にキャプチャする。

通常、サウンドメモリに書き込まれた音声データは、処理を行った機器に直接接続されているスピーカに出力される。しかしながら、本実施の形態では、音声データは、遠隔にあるクライアント端末１０１のスピーカから出力される。そのため、音声レコーダ３０６は、エンコーダ３０７に音声データをエンコードさせるために、サウンドメモリ上の音声データをエンコードバッファ（図略）にキャプチャしている。なお、クライアント端末１０１がスピーカを保持していない、或いは実行対象のアプリケーションが音声を出力しない場合、音声データのキャプチャ及びエンコードは省略されてもよい。この場合、画像データのみがクライアント端末１０１に送信される。

エンコーダ３０７は、スクリーンキャプチャ３０５でキャプチャされた画像データ及び音声レコーダ３０６でキャプチャされた音声データをエンコードする。画像データ及び音声データが、エンコードされずに非圧縮のままクライアント端末１０１に送信されと、クライアント端末１０１に送信されるデータ量が膨大になり、ネットワーク負荷が増大する。そこで、エンコーダ３０７は、クライアント端末１０１及びサーバ１０２間のネットワークが許容するビットレートとなるように画像データ及び音声データをエンコードすればよい。

画像配信部３０８は、エンコーダ３０７でエンコードされた画像データ及び音声データをクライアント端末１０１に送信する。画像データ及び音声データを送信する際に使用する通信プロトコルは、遅延を極力少なくするために、ＴＣＰではなくＵＤＰを用いるのが好ましい。

ＵＯイベント受信部３０９は、クライアント端末１０１から送信されたＵＯイベントを受信し、高負荷アプリ実行部３０４に通知する。高負荷アプリ実行部３０４は、ＵＯイベント受信部３０９から通知されるＵＯイベントを実行中のアプリケーションに渡し、ＵＯイベントに応じた処理をアプリケーションに行わせる。高負荷アプリ実行部３０４にて実行中のアプリケーションは、あたかもサーバ１０２に接続されたタッチパネル、マウス、キーボード等で操作されているように振る舞うが、実際には、遠隔にあるクライアント端末１０１の操作部３１９により操作されている。

例えば、操作部３１９のエンターキーがユーザにより押されると、エンターキーが押されたことを示すＵＯイベントがＵＯイベント配信部３１３からＵＯイベント受信部３０９に通知される。そして、ＵＯイベント受信部３０９は、そのＵＯイベントを高負荷アプリ実行部３０４に通知し、高負荷アプリ実行部３０４は、そのＵＯイベントを実行中のアプリケーションに通知する。

これにより、アプリケーションは、遠隔にある操作部３１９の例えばエンターキーが押されたにもかかわらず、サーバ１０２に直接接続されているキーボードのエンターキーが押された場合と同様に振る舞う。つまり、アプリケーションの振る舞いは単体処理モード及び分散処理モードで違いはなく、ユーザは単体処理モード及び分散処理モードの違いを意識することなくアプリケーションを操作することができる。

なお、図３において、分散表示処理部３１１、低負荷アプリ実行部３１０、モード切替部３１２、及び通知部３１６は、通信装置１８０８（図１８参照）と通信装置１８０８を制御するプログラムを記憶する記憶装置（図１８のＲＯＭ１８０２、ＲＡＭ１８０４、及び外部記憶装置１８０５等）とにより構成され、クライアント端末１０１のＣＰＵ１８０３（図１８参照）がこのプログラムを実行することで実現される。このプログラムはコンピュータをクライアント端末１０１として機能させるクライアントプログラムを構成し、コンピュータ読み取り可能な記録媒体に記録されてユーザに提供される。あるいは、クライアントプログラムは、インターネット上に設けられたダウンロードサーバからダウンロードされてユーザに提供されてもよい。また、分散表示処理部３１１、低負荷アプリ実行部３１０、モード切替部３１２、及び通知部３１６を専用のハードウェア回路により構成してもよい。この場合、分散表示処理部３１１、低負荷アプリ実行部３１０、モード切替部３１２、及び通知部３１６を１チップ化して集積回路により構成してもよい。

また、図３において、分散処理実行部３０３、負荷判定部３０１、及び切替通知部３０２は、通信装置１８０８（図１８参照）と通信装置１８０８を制御するプログラムを記憶する記憶装置（図１８のＲＯＭ１８０２、ＲＡＭ１８０４、及び外部記憶装置１８０５等）とにより構成され、サーバ１０２のＣＰＵ１８０３（図１８参照）がこのプログラムを実行することで実現される。このプログラムはコンピュータをサーバ１０２として機能させるサーバプログラムを構成し、コンピュータ読み取り可能な記録媒体に記録されてユーザに提供される。あるいは、サーバプログラムは、インターネット上に設けられたダウンロードサーバからダウンロードされてユーザに提供されてもよい。

また、分散処理実行部３０３、負荷判定部３０１、及び切替通知部３０２を専用のハードウェア回路により構成してもよい。この場合、分散処理実行部３０３、負荷判定部３０１、及び切替通知部３０２を１チップ化して集積回路により構成してもよい。また、メモリ３１７は、ハードディスクドライブやＦＥＲＡＭ等の書き換え可能な不揮発性の記憶装置により構成される。

また、図３において、ＵＯイベント配信部３１３を省いてもよい。この場合、高負荷アプリ実行部３０４がＵＯイベントを直接受信すればよい。また、通知部３１６を省いてもよい。この場合、低負荷アプリ実行部３１０、分散表示処理部３１１、或いはモード切替部３１２が負荷判定部３０１にデータを送信すればよい。また、音声データ及び画像データを圧縮しない場合、エンコーダ３０７、スクリーンキャプチャ３０５、音声レコーダ３０６を省いてもよい。また、画像配信部３０８を省いてもよい。この場合、高負荷アプリ実行部３０４が実行結果をクライアント端末１０１に送信すればよい。また、切替通知部３０２を省いてもよい。この場合、負荷判定部３０１が直接、切替通知を送信すればよい。

図４は、負荷判定部３０１による判定処理の概要の説明図である。負荷判定部３０１は、クライアント端末１０１から得られる端末情報、実行対象のアプリケーションに付随するアプリ情報、及び過去に同じアプリケーションを実行したときのクライアント端末１０１の負荷の監視結果に基づいて、実行対象のアプリケーションがクライアント端末１０１にとって、高負荷のアプリケーションか否かを判定する。

図５は、負荷判定部３０１による判定処理の詳細の説明図である。アプリ情報には、実行対象のアプリケーションを実行するために必要なクライアント端末１０１の性能を示す性能条件が含まれている。性能条件としては、例えば、ＯＳのバージョン、ＣＰＵのクロック数、及びメモリ容量等が含まれる。

一方、端末情報には、性能情報及び負荷情報が含まれる。性能情報には、クライアント端末１０１のＯＳのバージョン、ＣＰＵのクロック数、及びメモリ容量等が含まれる。負荷情報には、現在のＣＰＵ利用率、メモリ消費量、及びフレームレートなどの動的に変化する情報が含まれる。性能情報は常に固定であるが、負荷情報は刻々と値が変化する。

まず、負荷判定部３０１は、アプリ情報に含まれる性能条件と、取得した端末情報に含まれる性能情報とを比較し、クライアント端末１０１の性能情報が実行対象となるアプリケーションの性能条件を満たしているか否かを判定する。

図５の例では、性能条件として、例えばＯＳのバージョンが４．０以上、ＣＰＵのクロック数が１．２ＧＨｚ以上、メモリ容量が１ＧＢ以上であることが規定されている。一方、性能情報は、ＯＳのバージョンが４．０、ＣＰＵのクロック数が１．５ＧＨｚ、メモリ容量が１ＧＢを示している。したがって、負荷判定部３０１は、性能情報が性能条件の全項目を満たしているため、クライアント端末１０１は性能条件を満たすと判定する。なお、負荷判定部３０１は、性能情報が、性能条件の全項目を満たしていなくても、いずれか１又は複数の項目を満たしていれば、クライアント端末１０１は性能条件を満たしていると判定してもよい。また、性能条件として、図５に示した項目は一例にすぎず、他の項目を採用してもよいし、いずれかの項目を省いてもよい。

クライアント端末１０１がアプリケーションの性能条件を満たしていれば、アプリケーションは、単体処理モードで起動され、クライアント端末１０１がアプリケーションの性能条件を満たしていなければ、アプリケーションは分散処理モードで起動される。

単体処理モードでアプリケーションが起動された場合、負荷判定部３０１はクライアント端末１０１の負荷情報を定期的に取得し、クライアント端末１０１の負荷に余裕があるか否かを監視する。

図５の例では、負荷情報としてＣＰＵ利用率、メモリ消費量、及びフレームレートが採用されている。したがって、負荷判定部３０１は、ＣＰＵ利用率、メモリ消費量、及びフレームレートが規定値を超えた場合、実行対象のアプリケーションはクライアント端末１０１にとって高負荷のアプリケーションであると判定すればよい。

ここで、規定値としては、単体処理モードでアプリケーションを起動させると、クライアント端末１０１がアプリケーションを円滑に処理することができなくなる数値を採用することができる。例えば、ＣＰＵ利用率及びメモリ消費量であれば９０％というような高負荷であることを示す数値が採用される。この場合、負荷判定部３０１は、ＣＰＵ利用率又はメモリ消費量が例えば９０％を超えていた場合、クライアント端末１０１の負荷が規定値を超えたと判定すればよい。図５の例では、クライアント端末１０１の現在のＣＰＵ利用率が７０％であり、規定値である９０％以下であるため、負荷判定部３０１は、負荷が規定値を超えていないと判定する。

負荷情報に含まれるフレームレートは、現在、クライアント端末１０１が単位時間あたりに何枚の画像データを描画できているかを示す数値である。そのため、フレームレートは、数値が高いほど、クライアント端末１０１の負荷に余裕があることを示す。したがって、負荷判定部３０１は、フレームレートに関しては、負荷情報に含まれるフレームレートが規定値以下になった場合、クライアント端末１０１の負荷が規定値を超えたと判定すればよい。

なお、負荷判定部３０１は、負荷情報に含まれる全ての項目が規定値を超えた場合に、実行対象のアプリケーションが高負荷であると判定してもよいし、いずれか１つ又は複数の項目が規定値を超えた場合に、実行対象のアプリケーションが高負荷であると判定してもよい。また、図５では、負荷情報はＣＰＵ利用率、メモリ消費量、フレームレートが示されているがこれは一例であり、他の項目を採用してもよいし、一部の項目を省いてもよい。

また、図５に示すように、負荷判定部３０１は、クライアント端末１０１の負荷情報をメモリ３１７に記録している。メモリ３１７に記録された負荷情報は、次回、同じアプリケーションを起動する際に負荷判定部３０１により参照される。例えば、実行対象となるアプリケーションを起動する際に該当するアプリケーションのＣＰＵ利用率として規定値（９０％）以上のＣＰＵ利用率がメモリ３１７に記録されていたとする。この場合、負荷判定部３０１は、クライアント端末１０１の性能情報が性能条件を満たしていたとしても、該当するアプリケーションはクライアント端末１０１にとっと高負荷のアプリケーションであると判定し、最初から分散処理モードで該当するアプリケーションを起動する。

図６は、実施の形態１において、クライアント端末１０１及びサーバ１０２がアプリケーションを起動する際の処理の一例を示すフローチャートである。まず、負荷判定部３０１は、クライアント端末１０１からアプリケーションの起動要求を受信すると、クラウド又はＷＥＢサーバからアプリケーションをダウンロードし（Ｓ１０１）、アプリケーションがクライアント端末１０１にとって高負荷のアプリケーションであるか否かを判定する判定処理を開始する。

ここで、クライアント端末１０１において、操作部３１９がユーザからアプリケーションを起動するためのユーザ操作を受け付けると、通知部３１６がその起動要求を負荷判定部３０１に送信する。これにより、負荷判定部３０１は、起動要求を受信する。そして、負荷判定部３０１は、起動要求に含まれるアプリケーションのＵＲＬにアクセスしてアプリケーションをダウンロードすればよい。

次に、負荷判定部３０１は、アプリケーションにアプリ情報が含まれているか否かを判定する（ステップＳ１０２）。そして、アプリ情報が含まれている場合（Ｓ１０２でＹＥＳ）、負荷判定部３０１は、通知部３１６から端末情報を受信し、アプリ情報に含まれる性能条件を性能情報が満たすか否かを判定する（ステップＳ１０３）。

性能条件を性能情報が満たす場合（Ｓ１０３でＹＥＳ）、負荷判定部３０１は、単体処理モードに切り替える切替通知を、切替通知部３０２を介してモード切替部３１２に通知し、アプリケーションを単体処理モードで起動させる単体処理モードの処理が実行される（ステップＳ１０５）。

一方、性能条件を性能情報が満たしていない場合（Ｓ１０３でＮＯ）、負荷判定部３０１は、分散処理モードに切り替える切替通知を、切替通知部３０２を介してモード切替部３１２に通知し、アプリケーションを分散処理モードで起動させる分散処理モードの処理が実行される（ステップＳ１０４）。

一方、Ｓ１０２において、アプリケーションにアプリ情報が含まれていない場合（Ｓ１０２でＮＯ）、アプリ情報に基づく判定処理ができないため、負荷判定部３０１は、メモリ３１７を参照し、メモリ３１７に記録された記録負荷情報に基づく判定処理を行う（Ｓ１０６）。

図７は、記録負荷情報に基づく判定処理の一例を示すフローチャートである。まず、負荷判定部３０１は、メモリ３１７を参照し、実行対象のアプリケーションの負荷情報が記録されているか否かを判定する（Ｓ２０１）。

図８は、メモリ３１７に記録された負荷情報が纏められた記録負荷情報のデータ構成の一例を示す図である。記録負荷情報は、アプリＩＤ、ＣＰＵ利用率、メモリ消費量、及びフレームレートの欄を含む。アプリＩＤは、アプリケーションを一意に識別するための識別子である。ＣＰＵ利用率は、該当するアプリケーションをクライアント端末１０１が前回実行したときのＣＰＵ利用率の最大値を示す。メモリ消費量は、該当するアプリケーションをクライアント端末１０１が前回実行したときのメモリ消費量の最大値を示す。フレームレートは、該当するアプリケーションをクライアント端末１０１が前回実行したときのフレームレートの最低値を示す。

なお、該当するアプリケーションにアプリ情報が含まれていれば、このアプリ情報に記載されているＩＤ（図８の例では、”ａｐｐｉｄ：”の次に記載された記号列）がアプリＩＤとして記録負荷情報に記録される。一方、該当するアプリケーションにアプリ情報が含まれていなければ、ＵＲＬ（図８の例では、”ｕｒｌ：”の次に記載された記号列）がアプリＩＤとして記録負荷情報に記録される。

したがって、負荷判定部３０１は、該当するアプリケーションにアプリ情報が含まれている場合、このアプリ情報に記載されたＩＤと同じＩＤが記録負荷情報に記録されていれば、Ｓ２０１でＹＥＳと判定すればよい。一方、負荷判定部３０１は、該当するアプリケーションにアプリ情報が含まれていない場合、このアプリケーションのＵＲＬと同じＵＲＬが記録負荷情報に記録されていれば、Ｓ２０１でＹＥＳと判定すればよい。

図７に戻り、負荷判定部３０１は、記録負荷情報に記載された実行対象のアプリケーションの負荷情報からこのアプリケーションがクライアント端末１０１にとって高負荷のアプリケーションであるか否かを判定する（Ｓ２０２）。ここで、負荷判定部３０１は、記録負荷情報に記載された実行対象のアプリケーションの負荷情報が規定値を超えている場合、高負荷のアプリケーションと判定する（Ｓ２０２でＹＥＳ）。一方、負荷判定部３０１は、記録負荷情報に記録された実行対象のアプリケーションの負荷情報が規定値を超えていない場合、低負荷のアプリケーションと判定する（Ｓ２０２でＮＯ）。

例えば、ＣＰＵ利用率の規定値が８５％であるとすると、負荷判定部３０１は、記録負荷情報に実行対象のアプリケーションのＣＰＵ利用率として、８５％以上の数値が記載されていれば、高負荷と判定する。

また、メモリ消費量の規定値が８５％であるとすると、負荷判定部３０１は、記録負荷情報に実行対象のアプリケーションのメモリ消費量として８５％以上の数値が記載されていれば、高負荷であると判定する。

フレームレートが６０ｆｐｓであれば、クライアント端末１０１は非常に滑らかに画像を描画できている。一方、フレームレートが数ｆｐｓであれば、クライアント端末１０１は、画面更新が遅く、滑らかに画像を描画できていない。例えば、フレームレートの規定値が５ｆｐｓであるとすると、負荷判定部３０１は、記録負荷情報に実行対象のアプリケーションのフレームレートとして５％以下の数値が記載されていれば、高負荷であると判定する。

なお、図８の例では、ＣＰＵ利用率、メモリ消費量、及びフレームレートのワースト値が記録されており、負荷判定部３０１は、ワースト値から高負荷であるか否かを判定しているが、これは一例にすぎない。例えば、記録負荷情報に、ＣＰＵ利用率、メモリ消費量、及びフレームレートの平均値も記録してもよい。この場合、負荷判定部３０１は、平均値も判定材料にして、判定処理を行えばよい。

例えば、ワースト値は規定値を超えているが、平均値は規定値を充分に下回っていることもある。この場合、高負荷状態になるのはアプリケーション実行中の短い区間のみである。そして、一時的に高負荷になることを許容できるユーザであれば、単体処理モードを設定しても問題はない。

そこで、負荷判定部３０１は、ワースト値が規定値を超えているが平均値が規定値を一定の値以上、下回っている場合、一時的に高負荷となるが単体処理モードを設定してもよいかをユーザに問い合わせる問合画像をクライアント端末１０１に表示させる。そして、ユーザがその問い合わせに同意するユーザ操作を行った場合、負荷判定部３０１は、単体処理モードに切り替える切替通知を切替通知部３０２を介してモード切替部３１２に通知すればよい。なお、この問い合わせに同意するか否かのユーザ操作を示す信号は、例えば、通知部３１６から負荷判定部３０１に送信される。

図７に戻り、Ｓ２０２でＮＯと判定されると、単体処理モードの処理が実行され（Ｓ２０３）、Ｓ２０２でＹＥＳと判定されると、分散処理モードの処理が実行される（Ｓ２０４）。

このように、図７のフローチャートによれば、実行対象のアプリケーションの負荷情報がメモリ３１７に記録されていない場合、或いは、実行対象のアプリケーションの負荷情報がメモリ３１７に記録されていても、その負荷情報が規定値を超えていない場合、単体処理モードの処理が実行される。一方、メモリ３１７に記録されている負荷情報が規定値を超えていれば、分散処理モードの処理が実行される。

図９は、分散処理モードの処理の一例を示すフローチャートである。まず、負荷判定部３０１は、実行対象のアプリケーションを高負荷アプリ実行部３０４にロードし、高負荷アプリ実行部３０４にそのアプリケーションを起動させる（Ｓ３０１）。

次に、スクリーンキャプチャ３０５は、アプリケーションによりグラフィックメモリ（図略）に書き込まれた画像データをエンコードバッファ（図略）にキャプチャすると共に、音声レコーダ３０６は、アプリケーションによりサウンドメモリに書き込まれた音声データをエンコードバッファ（図略）にキャプチャする（Ｓ３０２）。

次に、エンコーダ３０７は、エンコードバッファ（図略）にキャプチャされた画像データ及び音声データをエンコードする（Ｓ３０３）。これにより、画像データ及び音声データは、ネットワークにおいて、送信可能なビットレートで送信できるように圧縮される。

次に、画像配信部３０８は、圧縮された画像データ及び音声データをクライアント端末１０１へネットワークを介して送信する（Ｓ３０４）。

クライアント端末１０１は、画像配信部３０８から送信された画像データ及び音声データを画像受信部３１４で受信し（Ｓ３０５）、受信した画像データ及び音声データをデコードする。次に、画像表示部３１５は、デコードされた画像データを表示部３１８に表示すると共に、デコードされた音声データをスピーカに出力する（Ｓ３０６）。

次に、表示部３１８に表示された画像を見たユーザにより何らかのユーザ操作が行われ、ＵＯイベント配信部３１３によりそのユーザ操作が検知されると（Ｓ３０７でＹＥＳ）、検知されたユーザ操作がＵＯイベントとして、サーバ１０２に送信される（Ｓ３０８）。一方、ＵＯイベントが検知されない場合（Ｓ３０７でＮＯ）、処理がＳ３１１に進められる。

次に、サーバ１０２のＵＯイベント受信部３０９は、ＵＯイベント配信部３１３から配信されたＵＯイベントを受信し（Ｓ３０９）、高負荷アプリ実行部３０４に通知する。これにより、現在実行中のアプリケーションにＵＯイベントが通知される（Ｓ３１０）。

アプリケーションは、通知されたＵＯイベントに対応する動作を行い、例えば新しい画像を描画する、クリック音の音声を出力する等の処理を行う。

そして、処理がＳ３０２に戻され、アプリケーションによって新たに生成された画像データ及び音声データに対して、Ｓ３０２〜Ｓ３０６の処理が実行され、画像データ及び音声データが表示部３１８及びスピーカに出力される。

なお、ステップＳ３０７において、ＵＯイベントが検知されなかったとしても（Ｓ３０７でＮＯ）、高負荷アプリ実行部３０４によりアプリケーションの終了が検知されなければ（Ｓ３１１でＮＯ）、処理がＳ３０２に戻され、アプリケーションにより新たに生成された画像データ及び音声データに対する処理が継続される。

例えば、アプリケーションが動画を視聴するアプリケーションである場合、ユーザ操作はほとんど検知されないが、画像データ及び音声データの更新は継続的に行われる。そのため、Ｓ３０２〜Ｓ３０６の処理はアプリケーションが終了するまでは継続して実行される。

一方、Ｓ３１１において、高負荷アプリ実行部３０４がアプリケーションの終了を検知すると（Ｓ３１１でＹＥＳ）、処理が終了される。

図１０は、単体処理モードの処理の一例を示すフローチャートである。まず、低負荷アプリ実行部３１０は、負荷判定部３０１から実行対象のアプリケーションがロードされ、そのアプリケーションを起動する（Ｓ４０１）。

次に、負荷判定部３０１は、通知部３１６から負荷情報を取得する（Ｓ４０２）。なお、単体処理モードによりアプリケーションが起動されると、通知部３１６は、負荷情報を負荷判定部３０１に定期的に送信する。これにより、負荷判定部３０１は、クライアント端末１０１の負荷を監視することができる。

次に、負荷判定部３０１は、取得した負荷情報をメモリ３１７に記録する（Ｓ４０３）。これにより図８に示す記録負荷情報に、ＣＰＵ利用率、メモリ消費量、フレームレート等の負荷情報が書き込まれる。

次に、負荷判定部３０１は、負荷情報が規定値を超えるか否かにより、クライアント端末１０１の現在の負荷が高負荷であるか否かを判定する（Ｓ４０４）。負荷情報が規定値を超えていない場合、負荷判定部３０１は低負荷と判定し（Ｓ４０４でＮＯ）、単体処理モードを継続させる（Ｓ４０５）。

次に、低負荷アプリ実行部３１０によりアプリケーションの終了が検知されない場合（Ｓ４０６でＮＯ）、処理がＳ４０２に戻され、Ｓ４０２以降の処理が繰り返し実行され、クライアント端末１０１の負荷が監視される。

一方、ステップＳ４０４において、負荷情報が規定値を超えた場合、負荷判定部３０１は高負荷と判定し（Ｓ４０４でＹＥＳ）、高負荷アプリ実行部３０４は、現在のアプリケーションの実行状態を示す実行状態情報を低負荷アプリ実行部３１０から取得する（Ｓ４０７）。

これにより、高負荷アプリ実行部３０４は、現在のアプリケーションの状態を引き継ぐことができる。その結果、単体処理モードから分散処理モードに切り替えられても、アプリケーションは、実行状態がリセットされず、途中から処理を開始することができる。

次に、負荷判定部３０１は、切替通知部３０２を介して、分散処理モードに切り替える切替通知をモード切替部３１２に通知する（Ｓ４０８）。

次に、モード切替部３１２は、サーバの切替通知部３０２から分散処理モードへの切替通知を受信すると、低負荷アプリ実行部３１０にアプリケーションの実行を停止させ、分散表示処理部３１１を起動させる。これにより、クライアント端末１０１は、分散処理モードの処理を開始する（Ｓ４０９）。

図１１は、クライアント端末１０１及びサーバ１０２間で実行されるアプリケーションの実行状態の引き継ぎを示す図である。実行状態の引き継ぎは、低負荷アプリ実行部３１０及び高負荷アプリ実行部３０４間で行われる。

低負荷アプリ実行部３１０は、アプリ状態通知部４０１を含む。高負荷アプリ実行部３０４は、アプリ状態受信部４０２を含む。

アプリ状態通知部４０１は、アプリケーションの現在の実行状態を示す実行状態情報をアプリ状態受信部４０２に送信する。アプリ状態受信部４０２は、アプリ状態通知部４０１から送信された実行状態情報を受信する。これにより、クライアント端末１０１におけるアプリケーションの現在の実行状態がサーバ１０２に引き継がれる。

図１２は、単体処理モードの実行中において、実行方式が分散処理モードに切り替えられる際にユーザに通知されるメッセージ画像の一例を示した図である。分散処理モードでは、クライアント端末１０１はサーバ１０２と常時接続状態となるため、単体処理モードに比べ通信のデータ量が増大する。ユーザに何も通知せずに、自動的に単体処理モードから分散処理モードへの切り替えを行うと、ユーザはクライアント端末１０１及びサーバ１０２間で通信が発生していることを認識することができない。この場合、ユーザは、クライアント端末１０１及びサーバ１０２間で通信が発生していないと考えて、アプリケーションを長時間起動させる可能性がある。

しかしながら、これでは、クライアント端末１０１及びサーバ１０２間で大量のデータが送受され、通信プロバイダとユーザとの契約内容によっては、ユーザに想定外の通信費が請求されるといった問題が発生する。そこで、本実施の形態では、単体処理モードの起動中において、実行方式を分散処理モードに切り替える際、図１２に示すメッセージ画像をクライアント端末１０１に表示し、通信が発生することをユーザに通知している。

具体的には、サーバ１０２の負荷判定部３０１は、分散処理モードへの切り替えの要否をユーザに問い合わせるための問い合わせ依頼を切替通知部３０２を介してモード切替部３１２に通知する。そして、モード切替部３１２は、図１２に示すメッセージ画像を表示部３１８に表示する。

図１２に示すメッセージ画像には、「クラウドアクセラレーションを利用しますか？」と記載されている。ここで、クラウドアクセラレーションは、上記の分散処理モードに相当している。図１２のメッセージ画像の上側の説明欄１２０３には、クラウドアクセサレーションを利用すれれば、動作が改善されるが、通信が発生することが記載されている。これにより、ユーザはアプリケーションの動作を改善した場合、サーバ１０２との通信が発生することを認識することができる。

また、図１２には、「はい」と記載されたボタン１２０１と、「いいえ」と記載されたボタン１２０２とが表示されている。ユーザは、サーバ１０２との通信が発生しても動作の改善を希望する場合、ボタン１２０１を選択する。一方、ユーザは、サーバ１０２との通信の発生を希望しない場合、ボタン１２０２を選択する。

そして、ユーザによりボタン１２０１が選択され、操作部３１９がその選択操作を受け付けると、モード切替部３１２は、ユーザが分散処理モードへの切り替えを了承したことを示す了承通知を低負荷アプリ実行部３１０から負荷判定部３０１に通知する。これにより、負荷判定部３０１は、分散処理モードに切り替える切替通知をモード切替部３１２に切替通知部３０２を介して通知し、実行方式が分散処理モードに切り替えられる。

一方、ユーザによりボタン１２０２が選択され、その選択操作を操作部３１９が受け付けると、低負荷アプリ実行部３１０は、ユーザが分散処理モードへの切り替えに了承しないことを示す非了承通知を低負荷アプリ実行部３１０を介して負荷判定部３０１に通知する。これにより、負荷判定部３０１は、単体処理モードを継続してよいと判定し、低負荷アプリ実行部３１０にアプリケーションを継続して実行させる。

但し、通信プロバイダと定額契約をしているユーザは通信のデータ量を気にしないため、単体処理モードにおいて、クライアント端末１０１の負荷が高負荷になる都度、図１２に示すメッセージ画像をクライアント端末１０１に表示させると、ユーザに煩わしさを与えてしまう。

そこで、図１２に示すメッセージ画像にはチェックボックス１２０４が設けられている。このチェックボックス１２０４にユーザがチェックマークを入力した場合、負荷判定部３０１は、以降、チェックマーク入力時でのユーザの選択結果に応じて、分散処理モードに切り替える、或いは、単体処理モードを継続させるかを選択する。

具体的には、チェックマーク入力時において、ユーザがボタン１２０１を選択したとする。この場合、負荷判定部３０１は、単体処理モードにおいて該当するアプリケーションの負荷が規定値を超えたとしてもメッセージ画像を表示することなく、自動的に、分散処理モードに切り替える。一方、チェックマークの入力時において、ユーザがボタン１２０２を選択したとする。この場合、負荷判定部３０１は、単体処理モードにおいて該当するアプリケーションの負荷が規定値を超えたとしても、メッセージ画像を表示することなく、単体処理モードを継続させる。

このように、本実施の形態によれば、実行対象のアプリケーションがクライアント端末１０１にとって高負荷のアプリケーションであると判定された場合、分散処理モードに切り替えられる。そのため、クライアント端末１０１にとって高負荷のアプリケーションがクライアント端末１０１で実行されることが回避され、アプリケーションを円滑に実行することができる。

一方、実行対象のアプリケーションがクライアント端末１０１にとって低負荷のアプリケーションであると判定された場合、単体処理モードに切り替えられる。そのため、クライアント端末１０１で十分に処理することができる低負荷のアプリケーションが分散処理され、通信のデータ量が増大することを防止することができる。その結果、通信のデータ量の増大に伴うクライアント端末１０１のバッテリー消費を極小化することができる。

（実施の形態２）
実施の形態１では、サーバ１０２側で実行対象のアプリケーションがクライアント端末１０１にとって高負荷のアプリケーションであるか否かが判定されていたが、実施の形態２では、クライアント端末１０１側でこの判定が行われる。なお、実施の形態２では、実施の形態１と同じ部分は説明を省略し、相違点のみ説明する。

図１３は、実施の形態２におけるクライアント端末１０１及びサーバ１０２の機能構成の一例を示すブロック図である。実施の形態２では、クライアント端末１０１は、サーバ１０２を経由せず、直接、クラウド又はＷＥＢサーバからアプリケーションを取得する。また、実施の形態１では、負荷判定部３０１及びメモリ３１７はサーバ１０２に設けられていたが、実施の形態２では、負荷判定部３０１及びメモリ３１７は負荷判定部５０１及びメモリ５０２として、クライアント端末１０１に設けられている。また、負荷判定部５０１がクライアント端末１０１側に設けられたことに伴い、切替通知部３０２、通知部３１６は省かれている。

負荷判定部５０１は、実施の形態１と同様、実行対象となるアプリケーションがクライアント端末１０１にとって高負荷のアプリケーションであるか、低負荷のアプリケーションであるかを判定する。なお、負荷判定部５０１による判定処理は負荷判定部３０１による判定処理と基本的には同じである。

但し、負荷判定部５０１は、クライアント端末１０１に設けられている。そのため、負荷判定部５０１は、低負荷アプリ実行部３１０がアプリケーションを実行している際のクライアント端末１０１の負荷を監視し、高負荷と判定した場合は、実行中のアプリケーションのＵＲＬをメモリ５０２に記録する。

メモリ５０２には、高負荷と判定されたアプリケーションのＵＲＬのリストが記録されている。

図１４は、実施の形態２において、クライアント端末１０１及びサーバ１０２がアプリケーションを起動する際の処理の一例を示すフローチャートである。まず、低負荷アプリ実行部３１０は、実行対象となるアプリケーションを取得する前に、アプリケーションのＵＲＬを負荷判定部５０１に通知し、負荷判定部５０１に、該当するＵＲＬがメモリ５０２に記録されているか否かを判定させる（Ｓ１４０１）。

そして、低負荷アプリ実行部３１０から通知されたＵＲＬがメモリ５０２に記録されていれば（Ｓ１４０１でＹＥＳ）、負荷判定部５０１は、該当するアプリケーションは低負荷又は未実行であると判定し、単体処理モードの処理を開始する（Ｓ１４０２）。

一方、低負荷アプリ実行部３１０から通知されたＵＲＬがメモリ５０２に記録されていなければ（Ｓ１４０１でＮＯ）、負荷判定部５０１は、該当するアプリケーションは高負荷であると判定し、分散処理モードの処理を開始させる（Ｓ１４０３）。この場合、負荷判定部５０１は、低負荷アプリ実行部３１０から通知されたＵＲＬを高負荷アプリ実行部３０４に送信すると共に、モード切替部３１２に分散処理モードに切り替える切替通知を通知する。一方、サーバ１０２側では、高負荷アプリ実行部３０４が、通知されたＵＲＬにアクセスして実行対象のアプリケーションを取得し、取得したアプリケーションを起動する。なお、実施の形態２において分散処理モードの処理は実施の形態１と同じであるため、説明を省略する。

図１５は、実施の形態２における単体処理モードの処理の一例を示すフローチャートである。まず、低負荷アプリ実行部３１０は、実行対象のアプリケーションのＵＲＬにアクセスしてアプリケーションを取得し、取得したアプリケーションを起動する（Ｓ１５０１）。

次に、負荷判定部５０１は、例えば、負荷情報を定期的に取得し、負荷情報が規定値を超えるか否かにより、クライアント端末１０１の現在の負荷が高負荷であるか否かを判定する（Ｓ１５０２）。ここで、負荷判定部５０１は、例えばクライアント端末１０１のＯＳから負荷情報を取得すればよい。

負荷情報が規定値を超えていない場合、負荷判定部５０１は低負荷と判定し（Ｓ１５０２でＮＯ）、処理をＳ１５０４に進める。一方、負荷判定部５０１は、負荷情報が規定値を超えた場合、高負荷と判定し（Ｓ１５０２でＹＥＳ）、実行対象となるアプリケーションのＵＲＬをメモリ５０２に記録し（Ｓ１５０３）、処理をＳ１５０４に進める。

Ｓ１５０４において、負荷判定部５０１は、Ｓ１５０２の判定結果によらず、低負荷アプリ実行部３１０にアプリケーションを継続して実行させる。つまり、ステップＳ１５０２において、クライアント端末１０１が高負荷になったとしても、アプリケーションは単体処理モードでの実行が継続される。但し、Ｓ１５０３において、高負荷となったアプリケーションのＵＲＬがメモリ５０２に記録されるため、負荷判定部５０１は、次回、該当するアプリケーションを起動する際に、Ｓ１４０１の処理により該当するアプリケーションを分散処理モードで起動させる。

次に、低負荷アプリ実行部３１０によりアプリケーションの終了が検知されない場合（Ｓ１５０５でＮＯ）、処理がＳ１５０２に戻され、再びクライアント端末１０１の負荷が継続して監視される。一方、低負荷アプリ実行部３１０によりアプリケーションの終了が検知された場合（Ｓ１５０５でＹＥＳ）、処理が終了される。

なお、図１５のフローチャートでは、単体処理モードにおいて、クライアント端末１０１の負荷が高負荷となった場合、次回の起動時に分散処理モードで起動させる態様を採用したが、今回の起動中に分散処理モードに移行する態様を採用してもよい。以下、この態様について説明する。

図１６は、実施の形態２において、単体処理モードの実行中にクライアント端末１０１の負荷が高負荷になった場合に、そのことをユーザに通知するための通知画像の一例を示した図である。

単体処理モードにおいて、アプリケーションの実行中にクライアント端末１０１の負荷が高負荷になった場合、そのアプリケーションをサーバ１０２がリロードすれば分散処理モードに移行することが可能である。

しかしながら、強制的にリロードすると、入力途中の状態が消去されるおそれがあり、また、高負荷状態によるクライアント端末１０１のパフォーマンスの劣化を許容できるユーザもいると想定される。そのため、アプリケーションをリロードするか否かはユーザの判断に委ねることが好ましい。

そこで、本実施の形態では、単体処理モードの実行中にクライアント端末１０１の負荷が高負荷になった場合、図１６に示す通知画像を表示して、アプリケーションをリロードすれば、アプリケーションを高速化できる可能性があることをユーザに通知する。

図１６に示す通知画像には、リロードと記載されたリロードボタン１６０１が設けられている。また、リロードボタン１６０１の右側には、「リロードしてクラウドアクセサレーションを利用」と記載されている。これにより、ユーザは、リロードボタン１６０１を押せば、アプリケーションがリロードされ、アプリケーションの処理が高速化できることを認識することができる。

リロードボタン１６０１の表示態様としては、例えば、リロードボタン１６０１の全域をハイライト表示させる、或いは、リロードボタン１６０１を点滅させるといった表示態様を採用することが好ましい。これにより、リロードボタン１６０１の存在をユーザにより確実に知らせることができる。

但し、アプリケーションをリロードすることを煩わしいと感じるユーザも存在する。そこで、このようなユーザに対処するために、単体処理モードにおいてクライアント端末１０１の負荷が高負荷になった場合、自動的にアプリケーションをリロードすることを予めユーザに設定させる構成を採用してもよい。なお、図１６において、リロードをキャンセルするボタンを設け、リロードしないことをユーザに選択させてもよい。

図１７は、図１５に示すフローチャートの変形例のフローチャートである。図１６の説明で述べたように、アプリケーションの実行中にクライアント端末１０１の負荷が高負荷になった場合、アプリケーションをリロードすることで分散処理モードに移行することができる。しかしながら、分散処理モードへの切り替え時に、サーバ１０２にアプリケーションのＵＲＬを通知し、サーバ１０２にアプリケーションを取得する処理を開始させるとなると、取得する処理が完了するまでの待ち時間が発生することになる。

そこで、本実施の形態では、単体処理モードにおいて、アプリケーションが高負荷になる可能性が高い場合、サーバ１０２にＵＲＬを通知してサーバ１０２に事前にアプリケーションを取得させておく。これにより、単体処理モードから分散処理モードへの移行を速やかに行うことができる。

まず、低負荷アプリ実行部３１０は、Ｓ１５０１と同様にして、アプリケーションを起動する（Ｓ１７０１）。次に、負荷判定部５０１は、定期的に取得した負荷情報から、高負荷の状態が１秒（第１時間の一例）、継続されたか否かを判定する（Ｓ１７０２）。なお、高負荷であるか否かの判定は、実施の形態１で示したように、負荷情報が規定値を超えるか否かにより判定すればよい。

高負荷の状態が１秒未満であれば（Ｓ１７０２でＮＯ）、負荷判定部５０１は、アプリケーションは低負荷と判定し、単体処理モードを継続させる（Ｓ１７１０）。

一方、高負荷の状態が１秒継続されれば（Ｓ１７０２でＹＥＳ）、負荷判定部５０１は、実行中のアプリケーションが高負荷のアプリケーションである可能性が高いと判定し、実行中のアプリケーションのＵＲＬをサーバ１０２に送信する（Ｓ１７０３）。サーバ１０２はＵＲＬを受信すると、分散処理モードに移行される可能性があるため、高負荷アプリ実行部３０４にアプリケーションを事前に取得させる（Ｓ１７０４）。

次に、負荷判定部５０１は、Ｓ１７０２の判定から継続して、更に２秒、高負荷の状態が続き、高負荷の状態が合計３秒（第２時間の一例）継続されたか否かを判定する（Ｓ１７０４）。そして、高負荷の状態が３秒継続されると（Ｓ１７０５でＹＥＳ）、実行中のアプリケーションは高負荷であると判定し、実行中のアプリケーションのＵＲＬをメモリ５０２に記録する（Ｓ１７０６）。

次に、低負荷アプリ実行部３１０は、リロードすることでアプリケーションが高速化されることをユーザに通知する（Ｓ１７０７）。この場合、低負荷アプリ実行部３１０は、図１６に示す通知画像を表示部３１８に表示する。そして、ユーザによりリロードボタン１６０１が押す操作が入力され（Ｓ１７０８でＹＥＳ）、その操作を操作部３１９が受け付けると、低負荷アプリ実行部３１０は、モード切替部３１２に分散処理モードへの切替通知を通知する。これにより、分散処理モードの処理が開始される（Ｓ１７０９）。

ステップＳ１７０４に示すように、サーバ１０２は、実行中のアプリケーションが高負荷である可能性が高い場合、アプリケーションを事前に取得している。したがって、Ｓ１７０８において、ユーザによりリロードボタン１６０１が押された場合、サーバ１０２はアプリケーションを取得する処理が不要となり、その処理の時間分、分散処理モードへの切り替えに要する時間を短縮化することができる。

一方、ユーザによりリロードボタン１６０１が押す操作が行われず（Ｓ１７０８でＮＯ）、その操作を操作部３１９が受け付けない場合、単体処理モードが継続される（Ｓ１７１０）。

Ｓ１７１１において、低負荷アプリ実行部３１０は、アプリケーションの終了を検知した場合（Ｓ１７１１でＹＥＳ）、アプリケーションを終了させ、アプリケーションの終了を検知しなかった場合（Ｓ１７１１でＮＯ）、処理がＳ１７０２に戻される。

図１７に示す処理は、実施の形態１の負荷判定部３０１がサーバ１０２に設けられている構成においても適用可能である。

なお、実施の形態１、２において、サーバ１０２は、ネットワークに設けられていたが、これは一例であり、ローカルネットワークに設けられてもよい。ローカルネットワークとしては、無線ＬＡＮ、有線ＬＡＮ、或いはこれらが混在するネットワークを採用すればよい。

サーバ１０２がＨ．２６４等のフレーム間で圧縮されたデータから構成される動画データのフォーマットで画像データを圧縮する場合、ＭｏｔｉｏｎＪＰＥＧに比べてデータ量が少なくなる。この場合、サーバ１０２をインターネットに設けても問題はない。

一方、サーバがＭｏｔｉｏｎＪＰＥＧ等のフレームのそれぞれが圧縮された連続する画像データにより構成されるフォーマットで画像データを圧縮する場合、Ｈ．２６４に比べてデータ量が多くなる。そのため、サーバ１０２をローカルネットワークに設けることが好ましい。サーバ１０２をローカルネットワークに設ける場合、サーバ１０２をホームサーバに実装すればよい。

図１８は、クライアント端末１０１及びサーバ１０２のそれぞれを実現するコンピュータのハードウェア構成の一例を示す図である。

コンピュータは、入力装置１８０１、ＲＯＭ（リードオンリメモリ）１８０２、ＣＰＵ（中央演算処理装置）１８０３、ＲＡＭ（ランダムアクセスメモリ）１８０４、外部記憶装置１８０５、表示装置１８０６、記録媒体駆動装置１８０７、及び通信装置１８０８を備える。各ブロックは内部のバスに接続され、このバスを介して種々のデータ等が入出され、ＣＰＵ１８０３の制御の下、種々の処理が実行される。

入力装置１８０１は、キーボード、マウス等から構成され、ユーザが種々のデータを入力するために使用される。ＲＯＭ１８０２には、ＢＩＯＳ（Basic Input/Output System）等のシステムプログラムが記憶される。外部記憶装置１８０５は、ハードディスクドライブ等から構成され、所定のＯＳ（Operating System）、コンピュータをクライアント端末１０１機能させるクライアントプログラム又はサーバ１０２として機能させるサーバプログラム等が記憶される。ＣＰＵ１８０３は、外部記憶装置１８０５からＯＳを読み出し、各ブロックの動作を制御する。ＲＡＭ１８０４は、ＣＰＵ１８０３の作業領域等として用いられる。

表示装置１８０６は、例えば液晶ディスプレイや有機ＥＬディスプレイにより構成され、ＣＰＵ１８０３の制御の下に種々の画像を表示する。記録媒体駆動装置１８０７は、ＤＶＤ−ＲＯＭドライブ、フレキシブルディスクドライブ等から構成される。

なお、クライアントプログラム及びサーバプログラムは、ＤＶＤ−ＲＯＭ等のコンピュータ読み取り可能な記録媒体１８０９に格納されてユーザに提供される。ユーザはこの記録媒体１８０９を記録媒体駆動装置１８０７に読み込ませることで、クライアントプログラム又はサーバプログラムをコンピュータにインストールする。また、クライアントプログラム及びサーバプログラムをインターネット上のＷＥＢサーバに格納し、このＷＥＢサーバからダウンロードすることで、クライアントプログラム又はサーバプログラムをコンピュータにインストールしてもよい。

通信装置１８０８は、例えば、コンピュータをＬＡＮやインターネットに接続するための通信装置により構成され、ＣＰＵ１８０３の制御の下、インターネットを介して他の機器との間でデータを送受する。

また、図３又は図１３の各機能ブロックは、典型的にはプロセッサと外部メモリとの協同で処理されるプログラムとして実現されるが、集積回路であるＬＳＩで実現してもよい。これらの各機能ブロックは個別に１チップ化されても良いし、一部又は全てを含むように１チップ化されても良い。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ又はウルトラＬＳＩと呼称されることもある。

また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。

さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。

また、実施の形態におけるクライアント端末１０１及びサーバ１０２が備える構成要素の一部または全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。

システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｍｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等を含んで構成されるコンピュータシステムである。前記ＲＯＭには、コンピュータプログラムが記憶されている。前記マイクロプロセッサが、前記コンピュータプログラムに従って動作することにより、システムＬＳＩは、その機能を達成する。

なお、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、あるいはＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。

さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。

（実施の形態のまとめ）
（１）本実施の形態によるクライアント端末は、ネットワークを介して通信可能に接続されたサーバと連携してアプリケーションを実行するクライアント端末であって、前記アプリケーションの実行結果である画像データを表示する表示部と、前記クライアント端末に前記アプリケーションを実行させる単体処理モードと、前記サーバに前記アプリケーションを実行させる分散処理モードとのいずれかにアプリケーションの実行方式を切り替えるモード切替部と、前記単体処理モードにおいて、前記アプリケーションを実行するアプリケーション実行部と、前記分散処理モードにおいて、前記アプリケーションの実行結果を示す画像データを前記サーバから受信し、前記表示部に表示する分散表示処理部とを備え、前記モード切替部は、前記クライアント端末にとって前記アプリケーションが高負荷のアプリケーションである場合、前記実行方式を前記分散処理モードに切り替える。

この構成によれば、クライアント端末単体では処理することが困難な高負荷のアプリケーションはサーバ側で実行され、クライアント端末はサーバの処理結果を受信して表示するだけで済む。一方、クライアント端末単体で十分に処理することができる低負荷のアプリケーションは、分散処理されずクライアント端末単体で実行される。そのため、アプリケーションを円滑に動作させることができる。

また、アプリケーションが高負荷又は低負荷であるかを問わず、クライアント端末にかかる負荷を常に低い状態に維持することができ、クライアント端末の電力消費量を抑制することができる。更に、高負荷のアプリケーションを実行した場合のみ、サーバ及びクライアント端末間で通信が発生するため、通信されるデータ量が抑制され、クライアント端末の電力消費量を抑制することができる。特に、クライアント端末がバッテリーの容量に制限のあるモバイル端末である場合、バッテリーの消費量を抑制し、クライアント端末を長時間使用することができる。

更に、サーバとの連携処理が高負荷のアプリケーションのみに限定されている。そのため、連携処理のためにクライアント端末がサーバを利用する頻度が低減され、クライアント端末のみならず、サーバにかかる負荷も低下させることができる。

（２）前記クライアント端末の性能を示す性能情報と、前記アプリケーションが規定する性能条件とに基づき、前記アプリケーションが前記クライアント端末にとって高負荷のアプリケーションであるか否かを判定し、高負荷のアプリケーションと判定した場合、前記分散処理モードに切り替える切替通知を前記モード切替部に通知し、低負荷のアプリケーションと判定した場合、前記単体処理モードに切り替える切替通知を前記モード切替部に通知する負荷判定部を更に備えてもよい。

この構成によれば、アプリケーションが要求する性能条件をクライアント端末の性能情報が満たせば、実行対象のアプリケーションが低負荷であると判定され、クライアント端末でアプリケーションが実行される。そのため、実行対象のアプリケーションがクライアント端末にとって低負荷であるか高負荷であるか正確に判断することができる。

（３）前記負荷判定部は、前記単体処理モードにおいて、前記クライアント端末の負荷を監視し、前記負荷が規定値を超えた場合、前記分散処理モードへの切替通知を前記モード切替部に通知してもよい。

この構成によれば、クライアント端末がアプリケーションを実行している際に、クライアント端末の負荷が規定値を超えると、単体処理モードから分散処理モードに実行方式が切り替えられる。そのため、起動時にはクライアント端末にとって低負荷であると判定され、単体処理モードに設定したが、実際に実行させてみると高負荷であった場合に、分散処理モードに切り替えることができる。よって、クライアント端末にとって高負荷のアプリケーションがクライアント端末で実行され続けることを防止することができる。

（４）前記負荷判定部は、前記単体処理モードにおいて、前記クライアント端末の負荷が前記規定値を超えた時間が所定の第１時間継続した場合、前記サーバに前記アプリケーションを事前に取得させ、前記負荷が前記規定値を超えた時間が更に所定の第２時間（＞前記第１時間）継続した場合、前記分散処理モードへの切替通知を前記モード切替部に通知してもよい。

この構成によれば、クライアント端末にとってアプリケーションの負荷が高くなる可能性が高い場合、サーバにより事前にアプリケーションが取得される。そのため、実際に負荷が高いと判定され、単体処理モードから分散処理モードに切り替える際に、サーバがアプリケーションを取得する処理を行う必要がなく、単体処理モードから分散処理モードへの切り替えを短時間で行うことができる。

（５）前記負荷判定部は、前記単体処理モードにおいて、前記分散処理モードへの切替通知を前記モード切替部に通知する場合、前記分散処理モードへの切り替えの要否をユーザに問い合わせ、ユーザにより前記分散処理モードへの切り替えを了承するユーザ操作が行われた場合、前記モード切替部に前記切替通知を通知してもよい。

この構成によれば、アプリケーションの実行速度の低下を許容するユーザや、通信コストの増大を嫌うユーザ等の要望に応じて、適切な実行方式でアプリケーションを実行することができる。

（６）前記負荷判定部は、前記アプリケーションにより前記性能条件が規定されていない場合、前記単体処理モードに切り替える切替通知を前記モード切替部に通知し、その後、前記クライアント端末の負荷を監視し、前記負荷が規定値を超えた場合、前記分散処理モードへの切替通知を前記モード切替部に通知してもよい。

この構成によれば、アプリケーションに性能条件が記載されていない場合、とりあえず、単体処理モードでアプリケーションを起動させておく。その後、クライアント端末の負荷が高負荷になった場合、実行方式が単体処理モードから分散処理モードに切り替えられる。よって、アプリケーションに性能条件が記載されていない場合であっても、アプリケーションを適切な実行方式で実行させることができる。

（７）前記クライアント端末は、前記負荷の監視結果を記録するメモリを更に備え、前記負荷判定部は、前記アプリケーションの起動時に、前記メモリを参照し、高負荷を示す監視結果が記録されていた場合、前記アプリケーションは高負荷のアプリケーションであると判定し、前記分散処理モードへの切替通知を前記モード切替部に通知してもよい。

この構成によれば、クライアント端末がアプリケーションを実行したときの負荷の監視結果がメモリに記録されているため、この監視結果を参照することで、該当するアプリケーションが次に実行される際に、そのアプリケーションがクライアント端末にとって高負荷であるか否かを高速且つ正確に判定することができる。

（８）前記負荷判定部は、前記メモリに監視結果が記録されていない場合、前記単体処理モードに切り替える切替通知を前記モード切替部に通知し、その後、前記クライアント端末の負荷を監視し、前記負荷が規定値を超えた場合、前記分散処理モードに切り替える切替通知を前記モード切替部に通知してもよい。

この構成によれば、実行対象となるアプリケーションがクライアント端末で初めて実行される場合、とりあえず、単体処理モードで起動され、その後、クライアント端末の負荷が高負荷になった場合、分散処理モードに切り替えられる。そのため、クライアント端末にとって高負荷のアプリケーションがクライアント端末で実行され続けることが防止され、適切な実行方式でアプリケーションを実行することができる。

（９）前記アプリケーションに対するユーザ操作を受け付ける操作部を更に備え、前記分散表示処理部は、前記分散処理モードにおいて、前記ユーザ操作を検知して、検知したユーザ操作の内容を示すＵＯイベントを前記サーバに送信してもよい。

この構成によれば、分散処理モードにおいて、ユーザがアプリケーションに対して操作を行うと、そのことがサーバに通知され、操作に応じた処理がサーバによって行われ、実行結果がクライアント端末に返される。そのため、分散処理モードであっても、クライアント端末とサーバとの間でデータの送受が行われていることをユーザに意識させることなく、円滑にアプリケーションを実行させることができる。

（１０）本実施の形態によるサーバは、ネットワークを介して通信可能に接続されたクライアント端末と連携してアプリケーションを実行するサーバであって、分散処理モードにおいて前記アプリケーションを実行するサーバ側アプリケーション実行部と、前記サーバ側アプリケーション実行部による前記アプリケーションの実行結果を示す画像データを前記クライアント端末に送信する画像配信部と、前記アプリケーションが前記クライアント端末にとって低負荷のアプリケーションと判定した場合、前記クライアント端末に前記アプリケーションを実行させる単体処理モードに切り替える切替通知を前記クライアント端末に通知する負荷判定部とを備える。

この構成によれば、（１）で述べた効果を得るためのサーバを提供することができる。

（１１）前記負荷判定部は、前記クライアント端末の性能を示す性能情報と、前記アプリケーションが規定する性能条件とに基づき、前記アプリケーションが前記クライアント端末にとって低負荷のアプリケーションであるか否かを判定し、低負荷のアプリケーションと判定した場合、前記単体処理モードに切り替える切替通知を前記クライアント端末に通知し、高負荷のアプリケーションと判定した場合、前記分散処理モードに切り替える切替通知を前記クライアント端末に通知してもよい。

この構成によれば、負荷判定部をサーバに設けた構成において、（２）で述べた効果と同様の効果が得られる。

（１２）前記負荷判定部は、前記単体処理モードにおいて、前記クライアント端末の負荷を監視し、前記負荷が規定値を超えた場合、前記分散処理モードへの切替通知を前記クライアント端末に通知してもよい。

この構成によれば、負荷判定部をサーバに設けた構成において、（３）で述べた効果と同様の効果が得られる。

（１３）前記負荷判定部は、前記単体処理モードにおいて、前記分散処理モードへの切替通知を前記クライアント端末に通知する場合、前記分散処理モードへの切り替えの要否をユーザに問い合わせるための問い合わせ依頼を前記クライアント端末に送信し、前記クライアント端末からユーザが前記分散処理モードへの切り替えを了承したことを示す了承通知を受信した場合、前記クライアント端末に前記切替通知を通知してもよい。

この構成によれば、負荷判定部をサーバに設けた構成において、（５）で述べた効果と同様の効果が得られる。

（１４）前記負荷判定部は、前記アプリケーションにより前記性能条件が規定されていない場合、前記単体処理モードに切り替える切替通知を前記クライアント端末に通知し、その後、前記クライアント端末の負荷を監視し、前記負荷が規定値を超えた場合、前記分散処理モードへの切替通知を前記クライアント端末に通知してもよい。

この構成によれば、負荷判定部をサーバに設けた構成において、（６）で述べた効果と同様の効果が得られる。

（１５）前記サーバは、前記負荷の監視結果を記録するメモリを更に備え、前記負荷判定部は、前記アプリケーションの起動時に、前記メモリを参照し、高負荷を示す監視結果が記録されていた場合、前記アプリケーションは高負荷のアプリケーションであると判定し、前記分散処理モードへの切替通知を前記クライアント端末に通知してもよい。

この構成によれば、負荷判定部をサーバに設けた構成において、（７）で述べた効果と同様の効果が得られる。

（１６）フレーム間で圧縮されたデータから構成されるフォーマットに前記画像データを圧縮するエンコーダと、前記エンコーダにより圧縮された画像データを前記クライアント端末に送信する画像配信部とを更に備え、前記サーバ及び前記クライアント端末はインターネットを介して接続されていてもよい。

この構成によれば、フレーム間で圧縮されるデータから構成されるフォーマットで画像データが圧縮されてサーバからクライアント端末に送信されている。そのため、サーバ及びクライアント端末間をインターネットを介して接続しても、アプリケーションを円滑に実行させることができる。

（１７）フレームのそれぞれが圧縮された連続する画像データにより構成されるフォーマットに前記画像データを圧縮するエンコーダと、前記エンコーダにより圧縮された画像データを前記クライアント端末に送信する画像配信部とを更に備え、前記サーバ及び前記クライアント端末はローカルネットワークを介して接続されていてもよい。

この構成によれば、フレームのそれぞれが圧縮された連続する画像データにより構成されるフォーマットに画像データが圧縮されてサーバからクライアント端末に送信されている。そして、サーバ及びクライアント端末間がローカルネットワークを介して接続されている。そのため、アプリケーションを円滑に実行させることができる。

本発明によれば、製造産業において継続的に製造し、販売することができる。特に、本
発明は、分散処理を利用したクラウドサービスの制作及び実行に携わる民生機器産業に利用できる。

１０１ クライアント端末
１０２ サーバ
３０１ 負荷判定部
３０２ 切替通知部
３０３ 分散処理実行部
３０４ 高負荷アプリ実行部
３０９ ＵＯイベント受信部
３１０ 低負荷アプリ実行部
３１１ 分散表示処理部
３１２ モード切替部
３１３ ＵＯイベント配信部
３１６ 通知部
３１７ メモリ
３１８ 表示部
３１９ 操作部
５０１ 負荷判定部
５０２ メモリ

Claims (18)

1. ネットワークを介して通信可能に接続されたサーバと連携してアプリケーションを実行するクライアント端末であって、
   前記アプリケーションの実行結果である画像データを表示する表示部と、
   前記クライアント端末に前記アプリケーションを実行させる単体処理モードと、前記サーバに前記アプリケーションを実行させる分散処理モードとのいずれかにアプリケーションの実行方式を切り替えるモード切替部と、
   前記単体処理モードにおいて、前記アプリケーションを実行するアプリケーション実行部と、
   前記分散処理モードにおいて、前記アプリケーションの実行結果を示す画像データを前記サーバから受信し、前記表示部に表示する分散表示処理部とを備え、
   前記モード切替部は、前記クライアント端末にとって前記アプリケーションが高負荷のアプリケーションである場合、前記実行方式を前記分散処理モードに切り替えるクライアント端末。
2. 前記クライアント端末の性能を示す性能情報と、前記アプリケーションが規定する性能条件とに基づき、前記アプリケーションが前記クライアント端末にとって高負荷のアプリケーションであるか否かを判定し、高負荷のアプリケーションと判定した場合、前記分散処理モードに切り替える切替通知を前記モード切替部に通知し、低負荷のアプリケーションと判定した場合、前記単体処理モードに切り替える切替通知を前記モード切替部に通知する負荷判定部を更に備える請求項１記載のクライアント端末。
3. 前記負荷判定部は、前記単体処理モードにおいて、前記クライアント端末の負荷を監視し、前記負荷が規定値を超えた場合、前記分散処理モードへの切替通知を前記モード切替部に通知する請求項２記載のクライアント端末。
4. 前記負荷判定部は、前記単体処理モードにおいて、前記クライアント端末の負荷が前記規定値を超えた時間が所定の第１時間継続した場合、前記サーバに前記アプリケーションを事前に取得させ、前記負荷が前記規定値を超えた時間が更に所定の第２時間（＞前記第１時間）継続した場合、前記分散処理モードへの切替通知を前記モード切替部に通知する請求項３記載のクライアント端末。
5. 前記負荷判定部は、前記単体処理モードにおいて、前記分散処理モードへの切替通知を前記モード切替部に通知する場合、前記分散処理モードへの切り替えの要否をユーザに問い合わせ、ユーザにより前記分散処理モードへの切り替えを了承するユーザ操作が行われた場合、前記モード切替部に前記切替通知を通知する請求項３記載のクライアント端末。
6. 前記負荷判定部は、前記アプリケーションにより前記性能条件が規定されていない場合、前記単体処理モードに切り替える切替通知を前記モード切替部に通知し、その後、前記クライアント端末の負荷を監視し、前記負荷が規定値を超えた場合、前記分散処理モードへの切替通知を前記モード切替部に通知する請求項２記載のクライアント端末。
7. 前記負荷の監視結果を記録するメモリを更に備え、
   前記負荷判定部は、前記アプリケーションの起動時に、前記メモリを参照し、高負荷を示す監視結果が記録されていた場合、前記アプリケーションは高負荷のアプリケーションであると判定し、前記分散処理モードへの切替通知を前記モード切替部に通知する請求項６記載のクライアント端末。
8. 前記負荷判定部は、前記メモリに監視結果が記録されていない場合、前記単体処理モードに切り替える切替通知を前記モード切替部に通知し、その後、前記クライアント端末の負荷を監視し、前記負荷が規定値を超えた場合、前記分散処理モードに切り替える切替通知を前記モード切替部に通知する請求項７記載のクライアント端末。
9. 前記アプリケーションに対するユーザ操作を受け付ける操作部を更に備え、
   前記分散表示処理部は、前記分散処理モードにおいて、前記ユーザ操作を検知して、検知したユーザ操作の内容を示すＵＯイベントを前記サーバに送信する請求項１記載のクライアント端末。
10. ネットワークを介して通信可能に接続されたクライアント端末と連携してアプリケーションを実行するサーバであって、
    分散処理モードにおいて前記アプリケーションを実行するサーバ側アプリケーション実行部と、
    前記サーバ側アプリケーション実行部による前記アプリケーションの実行結果を示す画像データを前記クライアント端末に送信する画像配信部と、
    前記アプリケーションが前記クライアント端末にとって低負荷のアプリケーションと判定した場合、前記クライアント端末に前記アプリケーションを実行させる単体処理モードに切り替える切替通知を前記クライアント端末に通知する負荷判定部とを備えるサーバ。
11. 前記負荷判定部は、前記クライアント端末の性能を示す性能情報と、前記アプリケーションが規定する性能条件とに基づき、前記アプリケーションが前記クライアント端末にとって低負荷のアプリケーションであるか否かを判定し、低負荷のアプリケーションと判定した場合、前記単体処理モードに切り替える切替通知を前記クライアント端末に通知し、高負荷のアプリケーションと判定した場合、前記分散処理モードに切り替える切替通知を前記クライアント端末に通知する請求項１０記載のサーバ。
12. 前記負荷判定部は、前記単体処理モードにおいて、前記クライアント端末の負荷を監視し、前記負荷が規定値を超えた場合、前記分散処理モードへの切替通知を前記クライアント端末に通知する請求項１１記載のサーバ。
13. 前記負荷判定部は、前記単体処理モードにおいて、前記分散処理モードへの切替通知を前記クライアント端末に通知する場合、前記分散処理モードへの切り替えの要否をユーザに問い合わせるための問い合わせ依頼を前記クライアント端末に送信し、前記クライアント端末からユーザが前記分散処理モードへの切り替えを了承したことを示す了承通知を受信した場合、前記クライアント端末に前記切替通知を通知する請求項１１記載のサーバ。
14. 前記負荷判定部は、前記アプリケーションにより前記性能条件が規定されていない場合、前記単体処理モードに切り替える切替通知を前記クライアント端末に通知し、その後、前記クライアント端末の負荷を監視し、前記負荷が規定値を超えた場合、前記分散処理モードへの切替通知を前記クライアント端末に通知する請求項１１記載のサーバ。
15. 前記負荷の監視結果を記録するメモリを更に備え、
    前記負荷判定部は、前記アプリケーションの起動時に、前記メモリを参照し、高負荷を示す監視結果が記録されていた場合、前記アプリケーションは高負荷のアプリケーションであると判定し、前記分散処理モードへの切替通知を前記クライアント端末に通知する請求項１４記載のサーバ。
16. フレーム間で圧縮されたデータから構成されるフォーマットに前記画像データを圧縮するエンコーダと、
    前記エンコーダにより圧縮された画像データを前記クライアント端末に送信する画像配信部とを更に備え、
    前記サーバ及び前記クライアント端末はインターネットを介して接続されている請求項１０記載のサーバ。
17. フレームのそれぞれが圧縮された連続する画像データにより構成されるフォーマットに前記画像データを圧縮するエンコーダと、
    前記エンコーダにより圧縮された画像データを前記クライアント端末に送信する画像配信部とを更に備え、
    前記サーバ及び前記クライアント端末はローカルネットワークを介して接続されている請求項１０記載のサーバ。
18. ネットワークを介して通信可能に接続されたクライアント端末と連携してアプリケーションを実行するサーバによる分散処理方法であって、
    分散処理モードにおいて前記アプリケーションを実行するサーバ側アプリケーション実行ステップと、
    前記サーバ側アプリケーション実行ステップによる前記アプリケーションの実行結果を示す画像データを前記クライアント端末に送信する画像配信ステップと、
    前記アプリケーションが前記クライアント端末にとって低負荷のアプリケーションと判定した場合、前記クライアント端末に前記アプリケーションを実行させる単体処理モードに切り替える切替通知を前記クライアント端末に通知する負荷判定ステップとを備える分散処理方法。

Images