"複数のデータ処理装置のうちの第1データ処理装置に起動要求されたアプリケーションが所定のグループに属するか否かを判定し、前記アプリケーションが前記所定のグループに属するときは、前記複数のデータ処理装置の他のデータ処理装置で前記アプリケーションが起動されているか否かを判定し、前記アプリケーションが前記他のデータ処理装置で起動されているときは、前記第1データ処理装置は前記アプリケーションを起動しないことを特徴とするデータ処理方法。前記第1データ処理装置は、前記他のデータ処理装置が実行する前記アプリケーションとの通信によって前記アプリケーションの機能を提供することを特徴とする請求項1に記載のデータ処理方法。前記他のデータ処理装置は、前記第1データ処理装置からの通信に基づいて前記アプリケーションを実行中であるか否かを前記第1データ処理装置に通知することを特徴とする請求項1または請求項2に記載のデータ処理方法。前記他のデータ処理装置が前記アプリケーションを起動中でないときは前記第1データ処理装置が前記アプリケーションを実行し、前記アプリケーションを起動中であることを示すフラグをセットすることを特徴とする請求項1乃至請求項3の何れか一に記載のデータ処理方法。前記アプリケーションが前記所定のグループに属さないときは、前記第1データ処理装置が前記アプリケーションを実行することを特徴とする請求項1乃至請求項4の何れか一に記載のデータ処理方法。前記アプリケーションは暗号化機能を有することを特徴とする請求項5に記載のデータ処理方法。前記所定のグループは、コプロセッサ、デジタルシグナルプロセッサ、またはグローバルポジショニングシステムで実行されるアプリケーションを含むことを特徴とする請求項1乃至請求項6の何れか一に記載のデータ処理方法。前記他のデータ処理装置が前記アプリケーションを起動しているときに前記第1データ処理装置と前記他のデータ処理装置との間の通信強度が弱まるとき、前記複数のデータ処理装置のうちの前記他のデータ処理装置以外のデータ処理装置が前記アプリケーションを起動することを特徴とする請求項1乃至請求項7の何れか一に記載のデータ処理方法。それぞれが少なくとも一の周辺ユニットを含む複数のデータ処理装置と、前記複数のデータ処理装置のうちの第1データ処理装置の第1周辺ユニットに対する起動要求があるときに、前記複数のデータ処理装置のうちの第2データ処理装置の第2周辺ユニットが起動されているときは、前記第1周辺ユニットを起動しないで前記第2周辺ユニットの実行を共用するスケジューラと、を含むことを特徴とするデータ処理システム。前記第1周辺ユニットの機能と前記第2周辺ユニットの機能とは実質的に同じであることを特徴とする請求項9に記載のデータ処理システム。前記スケジューラは、前記起動要求に基づいて前記複数のデータ処理装置のうちの前記第1データ処理装置以外のデータ処理装置に対してブロードキャスト通信を行うことを特徴とする請求項9または請求項10に記載のデータ処理システム。前記周辺ユニットは、コプロセッサ、デジタルシグナルプロセッサ、またはグローバルポジショニングシステムを含むことを特徴とする請求項9乃至請求項11の何れか一に記載のデータ処理システム。しかしながら、従来技術では、複数のデータ処理装置例えば、端末を含むシステムにおいて、各々のデータ処理装置がアプリケーションを実行する場合の、システム全体でのエネルギー効率に対する配慮が十分ではないという問題がある。本発明は、上述した従来技術による問題点を解消するため、複数のデータ処理装置を含むシステム全体の消費電力を抑制することができるデータ処理方法およびデータ処理システムを提供することを目的とする。上述した課題を解決し、目的を達成するため、本発明の一側面によれば、複数のデータ処理装置のうちの第1データ処理装置に起動要求されたアプリケーションが所定のグループに属するか否かを判定し、前記アプリケーションが前記所定のグループに属するときは、前記複数のデータ処理装置の他のデータ処理装置で前記アプリケーションが起動されているか否かを判定し、前記アプリケーションが前記他のデータ処理装置で起動されているときは、前記第1データ処理装置は前記アプリケーションを起動しないデータ処理方法が提案される。また、本発明の別の一側面によれば、それぞれが少なくとも一の周辺ユニットを含む複数のデータ処理装置と、前記複数のデータ処理装置のうちの第1データ処理装置の第1周辺ユニットに対する起動要求があるときに、前記複数のデータ処理装置のうちの第2データ処理装置の第2周辺ユニットが起動されているときは、前記第1周辺ユニットを起動しないで前記第2周辺ユニットの実行を共用するスケジューラと、を含むデータ処理システムが提案される。本発明の一側面によれば、複数のデータ処理装置を含むシステム全体の消費電力を抑制することができるという効果を奏する。以下に添付図面を参照して、この発明にかかるデータ処理方法およびデータ処理システムの実施の形態を詳細に説明する。実施の形態1図1は、実施の形態1にかかるデータ処理方法の一実施例を示す説明図である。図1において、データ処理装置101,102は、アプリケーション以下、単にアプリともいうを実行可能なコンピュータである。データ処理装置101,102は、例えば、携帯電話、PDA、スマートフォン、ノートPCPersonalComputer、ゲーム機器、PC、サーバなどである。各データ処理装置101,102は、少なくとも一のCPUCentralProcessingUnitと、少なくとも一の周辺ユニットと、を含む。図1の例では、データ処理装置101は、CPU111,112と、周辺ユニットP1~P3と、を含む。CPU111は、OSOperatingSystem113を実行し、データ処理装置101の全体の制御を司る。OS113は、アプリケーションをどのCPUに割り当てるかを制御するスケジューラ115を備えている。また、CPU111は、割り当てられたアプリケーションを実行する。CPU112は、OS114を実行し、OS114に割り当てられたアプリケーションを実行する。また、データ処理装置102は、CPU121,122と、周辺ユニットP1~P3と、を含む。CPU121は、OS123を実行し、データ処理装置102の全体の制御を司る。OS123は、アプリケーションをどのCPUに割り当てるかを制御するスケジューラ125を備えている。また、CPU121は、割り当てられたアプリケーションを実行する。CPU122は、OS124を実行し、OS124に割り当てられたアプリケーションを実行する。周辺ユニットP1~P3は、各種アプリケーションを実行する際に用いられるハードウェアリソースであり、例えば、コプロセッサ、DSP、GPSデバイス、カメラデバイス、通信I/FInterface、暗号化回路などである。図1において、データ処理装置101の周辺ユニットP1と、データ処理装置102の周辺ユニットP1とは、機能が実質的に同じであればよく、例えば、処理性能が異なるものであってもよい。周辺ユニットP2,P3についても同様である。例えば、地図アプリや経路探索アプリなどを実行する場合、コプロセッサやGPSデバイスなどのハードウェアリソースが用いられる。また、マルチメディアアプリを実行する場合、コプロセッサやDSPなどのハードウェアリソースが用いられる。また、グラフィックアプリケーションを実行する場合、コプロセッサなどのハードウェアリソースが用いられる。また、SNSSocialNetworkingServiceアプリや業務アプリを実行する場合、暗号化回路などのハードウェアリソースが用いられる。ここで、データ処理装置101,102それぞれが、実質的に同じハードウェアリソースを用いて、同一または異なるアプリケーションを実行すると、データ処理装置101,102全体としてエネルギー効率が良いとはいえない場合がある。例えば、同一エリアに存在するデータ処理装置101,102が、GPSデバイスを用いたアプリケーションをそれぞれ実行する場合を想定する。なお、エリアとは、地図上の領域を区切って分割されたいずれかのエリアである。この場合、同一エリアに存在するデータ処理装置101,102の座標データは、ほぼ同じものとなる。このため、各データ処理装置101,102で個別にGPSデバイスを動作させて座標データを取得することは効率的ではない。また、ハードウェアリソースを起動すると処理内容に関わらず所定の電力が消費されるため、起動中のハードウェアリソース数が増えるほどシステム全体としての消費電力が増加する。そこで、実施の形態1では、複数のデータ処理装置例えば、データ処理装置101,102が、機能が実質的に同じ周辺ユニットを用いるアプリケーションを各々実行する際に、いずれかのデータ処理装置で最初に起動された周辺ユニットを装置間で共用する。これにより、各々のデータ処理装置で周辺ユニットを起動しなくてもアプリケーションを実行することが可能となり、システム全体としての消費電力を削減する。以下、データ処理装置101,102のデータ処理手順の一実施例について説明する。ここでは、一例として、データ処理装置102が周辺ユニットP1を用いるアプリbを実行していることにし、また、周辺ユニットP3を通信I/Fとする。1データ処理装置101は、アプリaの起動要求を受け付ける。具体的には、例えば、スケジューラ115が、OS113からアプリaの起動要求を受け付ける。ここで、アプリaは、実行時に周辺ユニットP1を用いるアプリケーションである。2データ処理装置101は、アプリaを実行する際に用いる周辺ユニットP1を起動しているか否かをデータ処理装置102に問い合わせる。具体的には、例えば、スケジューラ115が、通信I/F周辺ユニットP3を介して、周辺ユニットP1の起動確認要求をデータ処理装置102に送信する。3データ処理装置102は、周辺ユニットP1を起動しているか否かの問い合わせを受け付けると、周辺ユニットP1を起動しているか否かを判断する。具体的には、例えば、スケジューラ125が、周辺ユニットP1が起動中であることを示すフラグがセットされているか否かを判断する。4データ処理装置102は、周辺ユニットP1を起動しているか否かを示す起動確認応答をデータ処理装置101に送信する。具体的には、例えば、スケジューラ125が、通信I/F周辺ユニットP3を介して、周辺ユニットP1の起動確認応答をデータ処理装置101に送信する。ここでは、アプリbの実行に用いられる周辺ユニットP1が動作している、すなわち、周辺ユニットP1が起動中であることを示すフラグがセットされている。このため、データ処理装置102が、周辺ユニットP1を起動中であることを示す起動確認応答をデータ処理装置101に送信する。この結果、データ処理装置101によって周辺ユニットP1の起動確認応答が受信される。5データ処理装置101は、データ処理装置102で周辺ユニットP1が起動中の場合、データ処理装置102で起動中の周辺ユニットP1を用いてアプリaを実行する。すなわち、データ処理装置101は、自装置の周辺ユニットP1を起動しないで、データ処理装置102で起動中の周辺ユニットP1をデータ処理装置102と共用する。なお、上記5において、データ処理装置102で周辺ユニットP1が起動されていない場合、データ処理装置101は、自装置の周辺ユニットP1を起動してアプリaを実行することになる。この場合、自装置の周辺ユニットP1が起動中であることを示すフラグがセットされる。以上説明した実施の形態1によれば、データ処理装置101が周辺ユニットP1を用いるアプリaを実行する際に、データ処理装置102で既に起動されている周辺ユニットP1を利用することができる。これにより、データ処理装置101で周辺ユニットP1を起動しなくてもアプリaを実行することが可能となり、システム全体としての消費電力を削減することができる。実施の形態2つぎに、実施の形態2にかかるデータ処理システムについて説明する。なお、実施の形態1で説明した箇所と同様の箇所については説明を省略する。図2は、実施の形態2にかかるデータ処理システムのシステム構成例を示す説明図である。図2において、データ処理システム200は、携帯端末N1~Nnを含むn:2以上の自然数。携帯端末N1~Nnは、例えば、携帯電話、PDA、スマートフォン、ノートPC、ゲーム機器などのコンピュータであり、図1に示したデータ処理装置101,102に相当する。データ処理システム200において、携帯端末N1~Nnは、無線または有線のネットワーク210を介して相互に通信可能に接続されている。ネットワーク210は、例えば、アドホックネットワーク、LANLocalAreaNetwork、WANWideAreaNetwork、インターネットなどである。アドホックネットワークは、無線通信でリンクする自己構成型のネットワークの一種である。アドホックネットワークは複数のノード携帯端末N1~Nnにより構成される。アドホックネットワーク内の各携帯端末N1~Nnは、他の携帯端末とアドホック通信可能である。なお、データ処理システム200は、基地局やゲートウェイを含むことにしてもよい。携帯端末N1~Nnのハードウェア構成例つぎに、実施の形態2にかかる携帯端末N1~Nnのハードウェア構成例について説明する。以下の説明では、携帯端末N1~Nnのうち任意の携帯端末を携帯端末Niと表記するi=1,2,...,n。図3は、実施の形態2にかかる携帯端末のハードウェア構成例を示す説明図である。図3において、携帯端末Niは、CPU1~CPUkk:1以上の自然数と、メモリ301と、コプロセッサ302と、DSP303と、GPS304と、暗号化回路305と、通信I/F306と、を有している。携帯端末Niにおいて、CPU1~CPUk、メモリ301、コプロセッサ302、DSP303、GPS304、暗号化回路305および通信I/F306は、バス310を介して接続されている。また、図面では、携帯端末Niが有するソフトウェアOS1~k、スケジューラ320を一部抜粋して表示している。CPU1は、OS1を実行し、携帯端末Niの全体の制御を司る。OS1は、マスタOSであり、アプリケーションをどのCPUに割り当てるかを制御するスケジューラ320を備えている。また、CPU1は、割り当てられたアプリケーションを実行する。CPU2~CPUkは、それぞれOS2~OSkを実行し、各OSに割り当てられたアプリケーションを実行する。OS2~OSkは、スレーブOSである。メモリ301は、CPU1~CPUkに共有されるメモリである。メモリ301は、例えば、ROMReadOnlyMemory、RAMRandomAccessMemoryおよびフラッシュROMなどを有している。具体的には、例えば、フラッシュROMが各OSのプログラムを記憶し、ROMがアプリケーションプログラムを記憶し、RAMがCPU1~CPUkのワークエリアとして使用される。メモリ301に記憶されているプログラムは、各CPUにロードされることで、コーディングされている処理を該各CPUに実行させることになる。コプロセッサ302は、CPU1~CPUkの補助を行う副処理装置である。コプロセッサ302としては、例えば、FPUFloatingPointnumberprocessingUnit、GPUGraphicsProcessingUnitなどがある。DSP303は、音声や画像などの処理に特化したマイクロプロセッサである。GPS304は、GPS衛星からの電波を受信し、携帯端末Niの位置を示す位置情報を出力するデバイスである。携帯端末Niの位置情報は、例えば、緯度経度、高度などの地球上の1点を特定する座標データである。暗号化回路305は、データを暗号化する回路である。通信I/F306は、通信回線を通じてネットワーク210に接続され、ネットワーク210を介して外部装置に接続される。そして、通信I/F306は、ネットワーク210と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。なお、図示は省略するが、携帯端末Niは、例えば、メモリ301に対するデータのリード/ライトを制御するメモリコントローラ、各部に電源電圧を供給するPMUPowerManagementUnitのほか、ディスプレイやキーボードなどを有することにしてもよい。また、上述した説明では、携帯端末N1~Nnが同様のハードウェア構成を有するものとして説明したが、これに限らない。具体的には、例えば、携帯端末Niは、上述した周辺ユニット符号301~306とは異なる周辺ユニットを有することにしてもよく、また、上述した周辺ユニット符号301~306の一部を有さないことにしてもよい。共用リソーステーブル400の記憶内容つぎに、携帯端末Niが用いる共用リソーステーブル400について説明する。ここで、アプリケーションの実行に用いられる周辺ユニットの中には、複数の携帯端末間で共用するのに好ましくないものがある。例えば、図3に示した暗号化回路305は、セキュリティの観点から複数の携帯端末間で共用するのに好ましくない。共用リソーステーブル400は、各アプリケーションの実行に用いられる周辺ユニットのうち、複数の携帯端末間での共用を許可する周辺ユニットを示す情報である。図4は、共用リソーステーブルの記憶内容の一例を示す説明図である。図4において、共用リソーステーブル400は、アプリID、アプリ名および共用リソース名のフィールドを有し、各フィールドに情報を設定することで、アプリケーションA1~Amごとの共用リソース情報400-1~400-mをレコードとして記憶している。アプリIDは、本明細書において使用する各アプリケーションの識別子である。アプリ名は、各アプリケーションの名称である。共用リソース名は、各アプリケーションの実行に用いられる周辺ユニットのうち、複数の携帯端末間での共用を許可する周辺ユニットの名称である。共用リソース情報400-1を例に挙げると、アプリケーションA1のアプリ名グラフィックおよびアプリケーションA1の実行時に複数の携帯端末間で共用可能な共用リソース名コプロセッサが示されている。また、共用リソース情報400-2を例に挙げると、アプリケーションA2のアプリ名マルチメディアおよびアプリケーションA2の実行時に複数の携帯端末間で共用可能な共用リソース名コプロセッサ、DSPが示されている。共用リソーステーブル400は、例えば、図3に示したメモリ301に記憶されている。具体的には、例えば、各アプリケーションA1~Amの共用リソース情報400-1~400-mは、各アプリケーションA1~Amの実行オブジェクトとともに携帯端末Niのファイルシステムに格納されている。なお、共用リソーステーブル400は、例えば、各アプリケーションのコンパイル時に、各アプリケーションのメイクファイルを参照して、複数の携帯端末間で共用可能な周辺ユニットと各携帯端末Nが有する周辺ユニットとを照合することで作成される。携帯端末Niの機能的構成例図5は、実施の形態2にかかる携帯端末の機能的構成例を示すブロック図である。図5において、携帯端末Niは、検出部501と、判定部502と、送信部503と、受信部504と、判断部505と、切替部506と、割当部507と、設定部508と、を含む構成である。この制御部となる機能検出部501~設定部508は、具体的には、例えば、図3に示したメモリ301に記憶されたプログラムをCPU♯1に実行させることにより、または、通信I/F306により、その機能を実現する。また、各機能部の処理結果は、例えば、メモリ301に記憶される。まず、携帯端末Niが他の携帯端末Njj≠i、j=1,2,...,nに対して共用リソースの使用を依頼する側以下、クライアントというとなる場合の携帯端末Niの各機能部について説明する。検出部501は、アプリケーションの起動要求を検出する。具体的には、例えば、スケジューラ320が、OS1からのアプリケーションの起動要求を検出する。以下の説明では、起動要求が検出されたアプリケーションをアプリAと表記する。判定部502は、アプリAの起動要求が検出された場合、アプリAの実行時に共用リソースPを使用するか否かを判定する。ここで、共用リソースPとは、複数の携帯端末間での共用が許可されている周辺ユニット、すなわち、複数の携帯端末間で共用可能な周辺ユニットである。具体的には、例えば、スケジューラ320が、図4に示した共用リソーステーブル400を参照して、アプリAの実行時に共用リソースPを使用するか否かを判定する。例えば、アプリAをアプリケーションA1とする。この場合、スケジューラ320が、共用リソーステーブル400を参照して、アプリケーションA1の実行時に共用リソースPとしてコプロセッサ302を使用すると判定する。また、例えば、アプリAをアプリケーションA3とする。この場合、スケジューラ320が、共用リソーステーブル400を参照して、アプリケーションA3の実行時に共用リソースPとしてコプロセッサ302、GPS304を使用すると判定する。送信部503は、アプリAの実行時に共用リソースPを使用すると判定された場合、共用リソースPの起動確認要求を他の携帯端末Njに送信する。ここで、共用リソースPの起動確認要求とは、共用リソースPを起動しているか否かを他の携帯端末Njに問い合わせる情報である。具体的には、例えば、スケジューラ320が、通信I/F306を制御して、アドホック通信により、共用リソースPの起動確認要求をネットワーク210にブロードキャストする。例えば、アプリAをアプリケーションA1とする。この場合、スケジューラ320が、共用リソースPであるコプロセッサ302の起動確認要求をブロードキャストする。また、アプリAの実行時に用いられる共用リソースPが複数存在する場合、スケジューラ320は、各々の共用リソースPの起動確認要求をブロードキャストする。例えば、アプリAをアプリケーションA3とする。この場合、スケジューラ320が、共用リソースPであるコプロセッサ302の起動確認要求およびGPS304の起動確認要求をブロードキャストしてもよく、また、コプロセッサ302およびGPS304の起動確認要求を一括してブロードキャストしてもよい。受信部504は、共用リソースPの起動確認要求が送信された結果、共用リソースPの起動確認応答を他の携帯端末Njから受信する。ここで、共用リソースPの起動確認応答とは、共用リソースPを起動しているか否かを示す情報である。具体的には、例えば、スケジューラ320が、通信I/F306を介して、共用リソースPの起動確認応答を他の携帯端末Njから受信する。判断部505は、受信された共用リソースPの起動確認応答に基づいて、アプリAの実行に用いられる共用リソースPが他の携帯端末Njで起動しているか否かを判断する。具体的には、例えば、他の携帯端末Njから共用リソースPを起動していることを示す起動確認応答が受信された場合、スケジューラ320が、共用リソースPが他の携帯端末Njで起動していると判断する。一方、共用リソースPの起動確認要求が送信されてから一定時間経過しても、共用リソースPを起動していることを示す起動確認応答が受信されなかった場合、スケジューラ320が、共用リソースPが他の携帯端末Njで起動していないと判断してもよい。また、一定時間経過前に、携帯端末N1~Nnのうち自端末とは異なるすべての携帯端末から、共用リソースPを起動していないことを示す起動確認応答が受信された場合は、スケジューラ320が、共用リソースPが他の携帯端末Njで起動していないと判断する。切替部506は、共用リソースPが他の携帯端末Njで起動していると判断された場合、共用リソースPのデバイスドライバを、実デバイスドライバから仮想デバイスドライバに切り替える。ここで、実デバイスドライバとは、自端末の共用リソースPを動作させるためのソフトウェアである。仮想デバイスドライバとは、ネットワーク210を介して他の携帯端末Njと通信することにより、共用リソースPの機能を、他の携帯端末Njで起動している共用リソースPを用いて実現するためのソフトウェアである。具体的には、例えば、他の携帯端末Njで共用リソースPが起動している場合、スケジューラ320が、共用リソースPのドライバAPIApplicationProgramInterfaceに関連付けるデバイスドライバを、実デバイスドライバから仮想デバイスドライバに切り替える。なお、初期状態では、共用リソースPのドライバAPIは、共用リソースPの実デバイスドライバと関連付けられている。より具体的には、例えば、スケジューラ320が、共用リソースPの実デバイスドライバをアンロードした後、共用リソースPの仮想デバイスドライバをロードする。また、共用リソースPのドライバAPIに、共用リソースPの仮想デバイスドライバを関連付ける場合、スケジューラ320が、共用リソースPを起動している他の携帯端末Njの識別情報を仮想デバイスドライバに設定する。他の携帯端末Njの識別情報としては、例えば、他の携帯端末Njのアドレスを用いることができる。これにより、アプリAの実行に用いられる共用リソースPを起動している他の携帯端末Njを識別することができる。また、共用リソースPを起動している他端末が複数存在する場合がある。この場合、スケジューラ320が、共用リソースPを起動している複数の他端末のうち、最も早く起動確認応答を送信してきた他端末の識別情報を仮想デバイスドライバに設定することにしてもよい。また、スケジューラ320が、共用リソースPを起動している複数の他端末のうち、共用リソースPの負荷が最小となる他端末の識別情報を仮想デバイスドライバに設定することにしてもよい。ここで、共用リソースPの負荷とは、例えば、共用リソースPの使用率である。各他端末での共用リソースPの負荷を特定する負荷情報は、例えば、共用リソースPを起動していることを示す起動確認応答に含まれている。このように、共用リソースPを起動している他端末が複数存在する場合は、より負荷が小さい共用リソースPを選択して共用することにより、共用リソースPの処理待ちが発生することを回避することができる。また、切替部506は、共用リソースPのデバイスドライバを仮想デバイスドライバに切り替えた場合、共用リソースPの切替フラグを0から1に設定する。ここで、共用リソースPの切替フラグとは、共用リソースPのドライバAPIに関連付けられているデバイスドライバを識別するための情報である。ここでは、切替フラグが0の場合、共用リソースPのドライバAPIに実デバイスドライバが関連付けられていることを示す。一方、切替フラグが0の場合、共用リソースPのドライバAPIに仮想デバイスドライバが関連付けられていることを示す。なお、初期状態では、共用リソースPの切替フラグは0である。割当部507は、共用リソースPのデバイスドライバが仮想デバイスドライバに切り替えられた結果、アプリAをCPU1~kのいずれかのCPUに割り当てる。具体的には、例えば、スケジューラ320が、各CPU1~kの負荷情報に基づいて、CPU1~kの中からアプリAの割当先となるCPUを選択して、該CPUにアプリAを割り当てる。この結果、割当先のCPUのOSにより、アプリAが実行される。この場合、共用リソースPのデバイスドライバが仮想デバイスドライバに切り替えられているため、他の携帯端末Njで起動している共用リソースPを用いてアプリAが実行される。これにより、自端末の共用リソースPを起動することなく、アプリAを実行することができる。なお、複数の携帯端末で共用リソースPを共用する際の携帯端末間の動作連携例については、図8を用いて後述する。設定部508は、共用リソースPが他の携帯端末Njで起動していないと判断された場合、共用リソースPを起動していることを示すフラグを設定する。具体的には、例えば、スケジューラ320が、図6に示す共用リソースフラグテーブル600に、共用リソースPを起動していることを示すフラグを設定することにしてもよい。ここで、共用リソースフラグテーブル600について説明する。共用リソースフラグテーブル600は、例えば、メモリ301により実現される。図6は、共用リソースフラグテーブルの記憶内容の一例を示す説明図である。図6において、共用リソースフラグテーブル600は、共用リソース名および共用リソースフラグのフィールドを有する。各フィールドに情報を設定することで、各共用リソースを起動しているか否かを示すフラグ情報600-1~600-3が記憶されている。共用リソース名は、共用リソースの名称である。この共有リソースは、例えば、図4に示した共用リソーステーブル400に登録されている周辺ユニットである。共用リソースフラグは、共用リソースを起動しているか否かを示すフラグである。ここでは、共用リソースフラグが0の場合、共用リソースを起動していないことを示す。一方、共用リソースフラグが1の場合は、共用リソースを起動していることを示す。なお、初期状態では、共用リソースフラグは0である。一例として、共用リソースPであるコプロセッサ302が他の携帯端末Njで起動していないと判断された場合、スケジューラ320が、共用リソースフラグテーブル600内のフラグ情報600-1の共用リソースフラグを0から1に変更する。図5の説明に戻り、割当部507は、共用リソースPが他の携帯端末Njで起動していないと判断された場合、アプリAをCPU1~kのいずれかのCPUに割り当てる。この結果、割当先のCPUのOSにより、アプリAが実行される。この場合、共用リソースPのデバイスドライバが実デバイスドライバのため、自端末の共用リソースPを用いてアプリAが実行される。なお、上述した設定部508による、共用リソースPを起動していることを示すフラグを設定する処理は、アプリAがいずれかのCPUに割り当てられた後に行われることにしてもよい。また、割当部507は、アプリAの実行時に共用リソースPを使用しないと判定された場合、アプリAをCPU1~kのいずれかのCPUに割り当てる。この結果、割当先のCPUのOSにより、アプリAが実行される。すなわち、アプリAの実行に用いられる周辺ユニットの中に、他の携帯端末Njと共用可能な周辺ユニットがないため、自端末の周辺ユニットを用いてアプリAが実行される。つぎに、携帯端末Niが他の携帯端末Njから共用リソースPの使用を依頼される側以下、サーバというとなる場合の携帯端末Niの各機能部について説明する。受信部504は、共用リソースPの起動確認要求を他の携帯端末Njから受信する。ここで、共用リソースPは、他の携帯端末Njで起動要求が検出されたアプリAの実行に用いられる共用リソースである。具体的には、例えば、スケジューラ320が、ネットワーク210を介して、共用リソースPの起動確認要求を他の携帯端末Njから受信する。判断部505は、共用リソースPの起動確認要求が受信された場合、自端末で共用リソースPを起動しているか否かを判断する。具体的には、例えば、スケジューラ320が、図6に示した共用リソースフラグテーブル600を参照して、自端末で共用リソースPを起動しているか否かを判断することにしてもよい。一例として、共用リソースPであるコプロセッサ302の起動確認要求が受信されたとする。この場合、スケジューラ320が、共用リソースフラグテーブル600の中からコプロセッサ302のフラグ情報600-1を特定する。そして、フラグ情報600-1の共用リソースフラグに1が設定されている場合、スケジューラ320が、コプロセッサ302を起動していると判断する。一方、フラグ情報600-1の共用リソースフラグに0が設定されている場合、スケジューラ320が、コプロセッサ302を起動していないと判断する。送信部503は、共用リソースPの起動確認応答を他の携帯端末Njに送信する。具体的には、例えば、共用リソースPを起動していないと判断された場合、スケジューラ320が、通信I/F306を制御して、アドホック通信により、共用リソースPを起動していないことを示す起動確認応答を要求元の他の携帯端末Njに送信する。一方、共用リソースPを起動していると判断された場合、スケジューラ320が、通信I/F306を制御して、アドホック通信により、共用リソースPを起動していることを示す起動確認応答を要求元の他の携帯端末Njに送信する。また、設定部508は、共用リソースPを起動していると判断された場合、他の携帯端末Njからの共用リソースPに対するアクセス許可を設定する。具体的には、例えば、スケジューラ320が、図7に示すアクセス許可テーブル700に要求元の他の携帯端末Njからの共用リソースPに対するアクセス許可を設定することにしてもよい。ここで、アクセス許可テーブル700について説明する。アクセス許可テーブル700は、例えば、メモリ301により実現される。図7は、アクセス許可テーブルの記憶内容の一例を示す説明図である。図7において、アクセス許可テーブル700は、共用リソース名および端末IDのフィールドを有する。各フィールドに情報を設定することで、共用リソースごとのアクセス許可情報700-1~700-3がレコードとして記憶されている。共用リソース名は、共用リソースの名称である。この共有リソースは、例えば、図4に示した共用リソーステーブル400に登録されている周辺ユニットである。端末IDは、共用リソースに対するアクセスを許可する他の携帯端末Njの識別情報である。端末IDとしては、例えば、他の携帯端末Njのアドレスを用いることができる。例えば、自端末を携帯端末N1とし、携帯端末N2からコプロセッサ302の起動確認要求を受信した場合を例に挙げる。ここで、コプロセッサ302を起動している場合、スケジューラ320が、アクセス許可テーブル700内のアクセス許可情報700-1の端末IDフィールドに携帯端末N2の端末IDN2を設定する図7中、7-2参照。以降、携帯端末N1は、携帯端末N2から自端末のコプロセッサ302に対するアクセス要求があった場合、コプロセッサ302に対するアクセスを許可する。一方、アクセス許可情報700-1の端末IDフィールドに端末IDが設定されていない他の携帯端末Njからコプロセッサ302に対するアクセス要求があった場合、携帯端末N1は、コプロセッサ302に対するアクセスを許可しない。これにより、自端末で起動している共用リソースPをクライアントと共用することができるとともに、クライアント以外の他端末からの共用リソースPに対する不正なアクセスを防ぐことができる。図5の説明に戻り、判断部505は、共用リソースPの動作が終了したか否かを判断する。具体的には、例えば、スケジューラ320が、自端末での共用リソースPを用いたアプリケーションの実行が終了した場合に、共用リソースPの動作が終了したと判断することにしてもよい。また、設定部508は、共用リソースPの動作が終了したと判断された場合、共用リソースPが起動していないことを示すフラグを設定する。具体的には、例えば、スケジューラ320が、共用リソースフラグテーブル600に、共用リソースPが起動していないことを示すフラグを設定することにしてもよい。一例として、共用リソースPであるコプロセッサ302の動作が終了したと判断された場合、スケジューラ320が、共用リソースフラグテーブル600内のフラグ情報600-1の共用リソースフラグを1から0に変更する。また、設定部508は、共用リソースPの動作が終了したと判断された場合、他の携帯端末Njからの共用リソースPに対するアクセス許可を解除すなわち、アクセス禁止する。具体的には、例えば、スケジューラ320が、アクセス許可テーブル700に設定されている他の携帯端末Njからの共用リソースPに対するアクセス許可を解除することにしてもよい。例えば、図7に示す7-2において、コプロセッサ302の動作が終了した場合、スケジューラ320が、アクセス許可テーブル700内のアクセス許可情報700-1の端末IDフィールドから携帯端末N2の端末IDN2を削除する図7中、7-3参照。これにより、他の携帯端末Njからの共用リソースPに対する不正なアクセスを防ぐことができる。また、設定部508は、自端末で起動している共用リソースPを共用しているクライアントとの通信が切断された場合、該クライアントからの共用リソースPに対するアクセス許可を解除することにしてもよい。クライアントとの通信が切断された場合とは、例えば、クライアントとの間で確立されているセッションが切断された場合でもよく、また、クライアントとの間の通信強度が所定値以下となった場合でもよい。また、判断部505は、自端末で起動している共用リソースPの負荷情報に基づいて、共用リソースPの負荷が所定値X以上となるか否かを判断することにしてもよい。所定値Xは、例えば、共用リソースPの負荷が所定値X以上となると、共用リソースPの処理待ちが発生するような状態になる値に設定される。なお、所定値Xは、例えば、予め設定されてメモリ301に記憶されている。また、設定部508は、共用リソースPの負荷が所定値X以上であると判断された場合、他の携帯端末Njからの共用リソースPに対するアクセス許可を解除することにしてもよい。これにより、共用リソースPの処理待ちが発生することを防ぐことができる。また、共用リソースPの起動確認要求を受信した時点で、自端末で起動している共用リソースPの負荷が所定値X以上の場合、送信部503は、共用リソースPを起動していないことを示す起動確認応答を要求元の他の携帯端末Njに送信することにしてもよい。これにより、共用リソースPの処理待ちが発生することを未然に防ぐことができる。また、送信部503は、共用リソースPを起動していると判断された場合、共用リソースPの負荷情報を含む起動確認応答を要求元の他の携帯端末Njに送信することにしてもよい。これにより、上述したように、共用リソースPを起動している携帯端末が複数存在する場合に、クライアント側で、より負荷が小さい共用リソースPを選択して共用することができ、共用リソースPの処理待ちが発生することを回避することができる。携帯端末間の動作連携例つぎに、複数の携帯端末で共用リソースPを共用する際の携帯端末間の動作連携例について説明する。図8は、携帯端末間の動作連携例を示す説明図である。図8において、携帯端末N1は、クライアント側の携帯端末であり、周辺ユニット810と通信I/F811とを含む。携帯端末N2は、サーバ側の携帯端末であり、周辺ユニット820と通信I/F821とを含む。通信I/F811,821は、図3に示した通信I/F306に相当する。また、周辺ユニット810と周辺ユニット820は、実質的に機能が同じ共用リソースPであり、例えば、図3に示したコプロセッサ302、DSP303、GPS304などに相当する。ここで、アプリAaは、実行時に共用リソースPである周辺ユニット810を用いるアプリケーションである。また、アプリAbは、実行時に共用リソースPである周辺ユニット820を用いるアプリケーションである。ドライバAPI812、実デバイスドライバ813および仮想デバイスドライバ814は、携帯端末N1のOSに含まれる周辺ユニット810に関するプログラムである。また、ドライバAPI822、実デバイスドライバ823および仮想デバイスドライバ824は、携帯端末N2のOSに含まれる周辺ユニット820に関するプログラムである。ここでは、クライアント側の携帯端末N1において、アプリAaの起動要求が検出された結果、周辺ユニット810のドライバAPI812と仮想デバイスドライバ814とが関連付けられている。一方、サーバ側の携帯端末N2では、周辺ユニット820のドライバAPI822と実デバイスドライバ823とが関連付けられており、アプリAbが周辺ユニット820を用いて実行されている。以下、携帯端末N1が、携帯端末N2で起動中の周辺ユニット820を用いてアプリAaを実行する場合の携帯端末N1,N2間の動作連携例について説明する。まず、アプリAaが、周辺ユニット810のドライバAPI812を介して、仮想デバイスドライバ814に関数の引数を渡す。このあと、仮想デバイスドライバ814が、通信I/F811を介して、アドホック通信により、携帯端末N2の周辺ユニット820の実デバイスドライバ823宛に関数の引数関数の名称を含むを送信する。この結果、実デバイスドライバ823が、通信I/F821によって受信された関数の引数を、ドライバAPI822を介して受け取る。つぎに、実デバイスドライバ823が、周辺ユニット820に関数の引数を与えることにより、関数の戻り値を取得する。そして、実デバイスドライバ823が、通信I/F821を介して、アドホック通信により、携帯端末N1の周辺ユニット810の仮想デバイスドライバ814宛に関数の戻り値を送信する。この結果、仮想デバイスドライバ814が、通信I/F811によって受信された関数の戻り値を受け取ってアプリAaに渡す。これにより、携帯端末N1では周辺ユニット810を起動することなくアプリAaを実行することができ、携帯端末N1,N2全体としてのエネルギー効率を向上させることができる。携帯端末Niのデータ処理手順つぎに、実施の形態2にかかる携帯端末Niのデータ処理手順について説明する。ここでは、まず、クライアント側の携帯端末Niのデータ処理手順について説明する。図9は、実施の形態2にかかる携帯端末のデータ処理手順の一例を示すフローチャートその1である。図9のフローチャートにおいて、まず、スケジューラ320により、アプリAの起動要求を検出したか否かを判断するステップS901。ここで、スケジューラ320により、アプリAの起動要求を検出するのを待つステップS901:No。そして、スケジューラ320により、アプリAの起動要求を検出した場合ステップS901:Yes、共用リソーステーブル400を参照して、アプリAの実行時に共用リソースPを使用するか否かを判定するステップS902。ここで、共用リソースPを使用しない場合ステップS902:No、ステップS913に移行する。一方、共用リソースPを使用する場合ステップS902:Yes、スケジューラ320により、共用リソースPの起動確認要求をネットワーク210にブロードキャストするステップS903。つぎに、スケジューラ320により、他の携帯端末Njから共用リソースPの起動確認応答を受信したか否かを判断するステップS904。ここで、スケジューラ320により、共用リソースPの起動確認応答を受信するのを待つステップS904:No。そして、スケジューラ320により、共用リソースPの起動確認応答を受信した場合ステップS904:Yes、共用リソースPが他の携帯端末Njで起動中か否かを判断するステップS905。そして、共用リソースPが他の携帯端末Njで起動中の場合ステップS905:Yes、スケジューラ320により、共用リソースPの切替フラグを参照して、共用リソースPに仮想デバイスドライバが設定されているか否かを判断するステップS906。ここで、共用リソースPに仮想デバイスドライバが設定されている場合ステップS906:Yes、ステップS908に移行する。一方、共用リソースPに仮想デバイスドライバが設定されていない場合ステップS906:No、スケジューラ320により、共用リソースPのデバイスドライバを、実デバイスドライバから仮想デバイスドライバに切り替えるステップS907。そして、スケジューラ320により、アプリAをCPU1~kのいずれかのCPUに割り当てるステップS908。つぎに、スケジューラ320により、共用リソースPを起動している他の携帯端末Nj以下、単にサーバというとの接続状態が維持されているか否かを判断する生存確認を開始するステップS909。このあと、スケジューラ320により、サーバとの通信が切断されたか否かを判断するステップS910。ここで、サーバとの通信が切断された場合ステップS910:Yes、ステップS901に戻って、一連の処理を繰り返す。一方、サーバとの通信が切断されていない場合ステップS910:No、スケジューラ320により、アプリAの実行が終了したか否かを判断するステップS911。ここで、アプリAの実行が終了していない場合ステップS911:No、ステップS910に戻る。一方、アプリAの実行が終了した場合ステップS911:Yes、本フローチャートによる一連の処理を終了する。また、ステップS905において、共用リソースPが他の携帯端末Njで起動していない場合ステップS905:No、スケジューラ320により、共用リソースフラグテーブル600内の共用リソースPの共用リソースフラグを0から1に変更するステップS912。そして、スケジューラ320により、アプリAをCPU1~kのいずれかのCPUに割り当ててステップS913、本フローチャートによる一連の処理を終了する。これにより、共用リソースPを用いるアプリAを実行する際に、他の携帯端末Njで起動している共用リソースPを利用してアプリAを実行することができる。つぎに、サーバ側の携帯端末Niのデータ処理手順について説明する。図10は、実施の形態2にかかる携帯端末のデータ処理手順の一例を示すフローチャートその2である。図10のフローチャートにおいて、まず、スケジューラ320により、共用リソースPの起動確認要求を他の携帯端末Njから受信したか否かを判断するステップS1001。ここで、スケジューラ320により、共用リソースPの起動確認要求を受信するのを待つステップS1001:No。そして、スケジューラ320により、共用リソースPの起動確認要求を受信した場合ステップS1001:Yes、共用リソースフラグテーブル600を参照して、自端末で共用リソースPを起動中か否かを判断するステップS1002。ここで、共用リソースPを起動中の場合ステップS1002:Yes、スケジューラ320により、共用リソースPを起動していることを示す起動確認応答を、要求元の他の携帯端末Nj以下、単にクライアントというに送信するステップS1003。そして、スケジューラ320により、アクセス許可テーブル700にクライアントからの共用リソースPに対するアクセス許可を設定するステップS1004。つぎに、スケジューラ320により、クライアントとの通信が切断されたか否かを判断するステップS1005。ここで、クライアントとの通信が切断されていない場合ステップS1005:No、スケジューラ320により、自端末での共用リソースPの動作が終了したか否かを判断するステップS1006。ここで、共用リソースPの動作が終了していない場合ステップS1006:No、ステップS1005に戻る。一方、共用リソースPの動作が終了した場合ステップS1006:Yes、スケジューラ320により、共用リソースフラグテーブル600内の共用リソースPの共用リソースフラグを1から0に変更するステップS1007。そして、スケジューラ320により、クライアントからの共用リソースPに対するアクセス許可を解除してステップS1008、本フローチャートによる一連の処理を終了する。また、ステップS1002において、共用リソースPを起動していない場合ステップS1002:No、スケジューラ320により、共用リソースPを起動していないことを示す起動確認応答をクライアントに送信してステップS1009、本フローチャートによる一連の処理を終了する。また、ステップS1005において、クライアントとの通信が切断された場合ステップS1005:Yes、スケジューラ320により、クライアントからの共用リソースPに対するアクセス許可を解除してステップS1008、本フローチャートによる一連の処理を終了する。これにより、自端末で起動している共用リソースPを他の携帯端末Njと共用することができる。以上説明したように、実施の形態2にかかる携帯端末Niによれば、共用リソースPを用いるアプリAを実行する際に、ネットワーク210を介して、他の携帯端末Njで既に起動中の共用リソースPを利用することができる。これにより、携帯端末Niで共用リソースPを起動することなくアプリAを実行することができ、システム全体としての消費電力を削減することができる。また、実施の形態2にかかる携帯端末Niによれば、他の携帯端末Njからの共用リソースPの起動確認要求に対して、共用リソースPを起動しているか否かを示す起動確認応答を要求元に送信することができる。これにより、自端末で起動している共用リソースPを複数の携帯端末間で共用することができる。また、実施の形態2にかかる携帯端末Niによれば、共用リソースPの起動確認要求の要求元である他の携帯端末Njについてのみ、自端末で起動中の共用リソースPに対するアクセス許可を設定することができる。これにより、クライアント以外の他端末からの共用リソースPに対する不正なアクセスを防ぐことができる。また、実施の形態2にかかる携帯端末Niによれば、自端末での共用リソースPの動作が終了した場合やクライアントとの通信が切断された場合、クライアントからの共用リソースPに対するアクセス許可を解除することができる。また、実施の形態2にかかる携帯端末Niによれば、自端末で動作している共用リソースPの負荷が所定値X以上となった場合、他の携帯端末Njからの共用リソースPに対するアクセス許可を解除することができる。これにより、共用リソースPの処理待ちが発生することを防ぐことができる。また、実施の形態2にかかる携帯端末Niによれば、共用リソースPを起動している他端末が複数存在する場合、より負荷が小さい共用リソースPを選択して利用することにより、共用リソースPの処理待ちが発生することを回避することができる。一例として、データ処理システム200内の10台の携帯端末N1~N10が、GPS304を用いる同一または異なるアプリをそれぞれ実行する場合を例に挙げて説明する。ここで、各携帯端末NiにおけるGPS304の消費電力を200[mW]とし、通信I/F306の消費電力を50[mW]とする。ここで、10台の携帯端末N1~N10が連動して動作するような利用シーンを想定する。従来のように、すべての携帯端末N1~N10で1時間連続してGPS304を使用した場合、システム全体の消費電力は、例えば、2000[mWh]=200[mW]×1[h]×10[台]となる。一方、実施の形態2では、例えば、GPS304を起動している1台の携帯端末Niに対して、10台の携帯端末N1~N10が通信I/F306を介したアドホック通信を行う状態となる。この場合、システム全体の消費電力は、例えば、700[mWh]=200[mW]×1[h]×1[台]50[mW]×1[h]×10[台]となる。したがって、実施の形態2にかかるデータ処理方法によれば、すべての携帯端末N1~N10で1時間連続してGPS304を使用した場合に比べて、システム全体として1300[mWh]のエネルギー消費を削減することができる。このように、実施の形態2にかかるデータ処理方法およびデータ処理システムによれば、複数のデータ処理装置が、実質的に同じ周辺ユニットを用いるアプリを各々実行する際の、システム全体の消費電力を抑制してエネルギー効率を向上させることができる。実施の形態3つぎに、実施の形態3にかかる携帯端末Niについて説明する。なお、実施の形態1,2で説明した箇所と同一箇所については、同一符号を付して図示および説明を省略する。ここで、各携帯端末Niで実行されるアプリケーションの中には、携帯端末N1~Nnのうち2台以上の携帯端末が同時に実行する必要性の低いものがある。例えば、携帯端末Niが道路上の渋滞情報を交通管理センタなどのサーバにアップするアプリケーションの場合、同一エリア内に存在する複数の携帯端末から収集された渋滞情報の内容はほぼ同じものとなる。このため、複数の携帯端末から収集されたほとんどの渋滞情報は、サーバ側で使用されないことになる。すなわち、このアプリケーションは、同一エリア内に存在する2台以上の携帯端末が同時に実行する必要性の低いものである。そこで、実施の形態3では、携帯端末Niで起動要求が検出されたアプリAと同一のアプリAが他の携帯端末Njで起動されているときは、携帯端末NiでアプリAを起動しないことにより、無駄なアプリAの実行を抑制する場合について説明する。以下、携帯端末Niの各機能部について説明する。まず、判定部502は、アプリAの起動要求が検出された場合、アプリAが所定のグループに属するか否かを判定する。ここで、所定のグループとは、例えば、携帯端末N1~Nnのうち2台以上の携帯端末が同時に実行する必要性の低いアプリケーションの集合である。なお、所定のグループを特定する情報は、例えば、メモリ301に記憶されている。送信部503は、アプリAが所定のグループに属すると判定された場合、アプリAの起動確認要求を他の携帯端末Njに送信する。ここで、アプリAの起動確認要求とは、アプリAを起動しているか否かを他の携帯端末Njに問い合わせる情報である。受信部504は、アプリAの起動確認要求が送信された結果、アプリAの起動確認応答を他の携帯端末Njから受信する。ここで、アプリAの起動確認応答とは、アプリAを起動しているか否かを示す情報である。判断部505は、受信されたアプリAの起動確認応答に基づいて、アプリAが他の携帯端末Njで起動しているか否かを判断する。判断部505による判断処理は、例えば、アドホック通信により直接通信可能な他の携帯端末NjからのアプリAの起動確認応答に基づいて行うことにしてもよい。これにより、自端末の近傍に位置する他の携帯端末Nj、すなわち、同一エリア内に存在する可能性が高い他の携帯端末NjからのアプリAの起動確認応答に基づいて、自端末でのアプリAの実行の要否を判断することができる。割当部507は、アプリAが他の携帯端末Njで起動していないと判断された場合、アプリAをCPU1~kのいずれかのCPUに割り当てる。この結果、割当先のCPUのOSにより、アプリAが実行される。また、割当部507は、アプリAが他の携帯端末Njで起動していると判断された場合、アプリAを割り当てない。すなわち、アプリAは他の携帯端末Njで起動されており、携帯端末NiでアプリAを実行する必要性が低いため、携帯端末NiがアプリAを起動しない。これにより、携帯端末Niにおいて、他の携帯端末Njと同時に実行する必要性の低いアプリAの実行を抑制して、アプリAの実行にかかる消費電力を削減することができる。また、受信部504は、アプリAの起動確認要求を他の携帯端末Njから受信する。また、判断部505は、アプリAの起動確認要求が受信された場合、自端末でアプリAを起動しているか否かを判断する。そして、送信部503は、自端末でアプリAを起動しているか否かを示す起動確認応答を要求元の他の携帯端末Njに送信する。携帯端末Niのデータ処理手順つぎに、実施の形態3にかかる携帯端末Niのデータ処理手順について説明する。ここでは、まず、アプリAの起動要求を検出した場合の携帯端末Niのデータ処理手順について説明する。図11は、実施の形態3にかかる携帯端末のデータ処理手順の一例を示すフローチャートその1である。図11のフローチャートにおいて、まず、スケジューラ320により、アプリAの起動要求を検出したか否かを判断するステップS1101。ここで、スケジューラ320により、アプリAの起動要求を検出するのを待つステップS1101:No。そして、スケジューラ320により、アプリAの起動要求を検出した場合ステップS1101:Yes、アプリAが所定のグループに属するか否かを判定するステップS1102。ここで、所定のグループに属さない場合ステップS1102:No、ステップS1106に移行する。一方、所定のグループに属する場合ステップS1102:Yes、スケジューラ320により、アプリAの起動確認要求をネットワーク210にブロードキャストするステップS1103。つぎに、スケジューラ320により、他の携帯端末NjからアプリAの起動確認応答を受信したか否かを判断するステップS1104。ここで、スケジューラ320により、アプリAの起動確認応答を受信するのを待つステップS1104:No。そして、スケジューラ320により、アプリAの起動確認応答を受信した場合ステップS1104:Yes、アプリAが他の携帯端末Njで起動中か否かを判断するステップS1105。そして、アプリAが他の携帯端末Njで起動中の場合ステップS1105:Yes、本フローチャートによる一連の処理を終了する。一方、アプリAが他の携帯端末Njで起動していない場合ステップS1105:No、スケジューラ320により、アプリAをCPU1~kのいずれかのCPUに割り当ててステップS1106、本フローチャートによる一連の処理を終了する。これにより、他の携帯端末Njと同時に実行する必要性の低いアプリAの実行を抑制して、アプリAの実行にかかる消費電力を削減することができる。つぎに、アプリAの起動確認応答を受信した場合の携帯端末Niのデータ処理手順について説明する。図12は、実施の形態3にかかる携帯端末のデータ処理手順の一例を示すフローチャートその2である。図12のフローチャートにおいて、まず、スケジューラ320により、アプリAの起動確認要求を他の携帯端末Njから受信したか否かを判断するステップS1201。ここで、スケジューラ320により、アプリAの起動確認要求を受信するのを待つステップS1201:No。そして、スケジューラ320により、アプリAの起動確認要求を受信した場合ステップS1201:Yes、自端末でアプリAを起動中か否かを判断するステップS1202。ここで、アプリAを起動中の場合ステップS1202:Yes、スケジューラ320により、アプリAを起動していることを示す起動確認応答を、要求元の他の携帯端末Njに送信してステップS1203、本フローチャートによる一連の処理を終了する。一方、アプリAを起動していない場合ステップS1202:No、スケジューラ320により、アプリAを起動していないことを示す起動確認応答を、要求元の他の携帯端末Njに送信してステップS1204、本フローチャートによる一連の処理を終了する。これにより、他の携帯端末Njに対してアプリAを起動しているか否かを応答することができる。システムの適用例図13は、本実施の形態にかかるコンピュータを用いたシステムの適用例を示す説明図である。図13において、ネットワークNWは、サーバ1301,1302とクライアント1331~1334とが通信可能なネットワークであり、例えば、LAN、WAN、インターネット、携帯電話網などで構成される。サーバ1302は、クラウド1320を構成するサーバ群サーバ1321~1325の管理サーバである。クライアント1331~1334のうち、クライアント1331はノート型パソコン、クライアント1332はデスクトップ型パソコン、クライアント1333は携帯電話機スマートフォン、PHSPersonalHandyphoneSystemでもよい、クライアント1334はタブレット型端末である。図13のサーバ1301,1302,1321~1325、クライアント1331~1334は、例えば、実施の形態1で説明したデータ処理装置101,102、または、実施の形態2で説明した携帯端末Niと同様の機能を有するコンピュータにより実現される。なお、本実施の形態で説明したデータ処理方法は、予め用意されたプログラムをパーソナルコンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本データ処理プログラムは、ハードディスク、フレキシブルディスク、CD-ROM、MO、DVD等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、本データ処理プログラムは、インターネット等のネットワークを介して配布してもよい。"