(57)【要約】  データ処理装置（１０１）は、アプリ（ａ）の起動要求を受け付ける。データ処理装置（１０１）は、アプリ（ａ）を実行する際に用いる周辺ユニット（Ｐ１）を起動しているか否かをデータ処理装置（１０２）に問い合わせる。データ処理装置（１０２）は、周辺ユニット（Ｐ１）を起動しているか否かの問い合わせを受け付けると、周辺ユニット（Ｐ１）を起動しているか否かを判断する。データ処理装置（１０２）は、周辺ユニット（Ｐ１）を起動しているか否かを示す起動確認応答をデータ処理装置（１０１）に送信する。データ処理装置（１０１）は、データ処理装置（１０２）で周辺ユニット（Ｐ１）が起動中の場合、データ処理装置（１０２）で起動中の周辺ユニット（Ｐ１）を用いてアプリ（ａ）を実行する。
2013005323.tif 000002
【特許請求の範囲】
【請求項１】
複数のデータ処理装置のうちの第１データ処理装置に起動要求されたアプリケーションが所定のグループに属するか否かを判定し、
前記アプリケーションが前記所定のグループに属するときは、前記複数のデータ処理装置の他のデータ処理装置で前記アプリケーションが起動されているか否かを判定し、
前記アプリケーションが前記他のデータ処理装置で起動されているときは、前記第１データ処理装置は前記アプリケーションを起動しないこと
を特徴とするデータ処理方法。
【請求項２】
前記第１データ処理装置は、前記他のデータ処理装置が実行する前記アプリケーションとの通信によって前記アプリケーションの機能を提供すること
を特徴とする請求項１に記載のデータ処理方法。
【請求項３】
前記他のデータ処理装置は、前記第１データ処理装置からの通信に基づいて前記アプリケーションを実行中であるか否かを前記第１データ処理装置に通知すること
を特徴とする請求項１または請求項２に記載のデータ処理方法。
【請求項４】
前記他のデータ処理装置が前記アプリケーションを起動中でないときは前記第１データ処理装置が前記アプリケーションを実行し、
前記アプリケーションを起動中であることを示すフラグをセットすること
を特徴とする請求項１乃至請求項３の何れか一に記載のデータ処理方法。
【請求項５】
前記アプリケーションが前記所定のグループに属さないときは、前記第１データ処理装置が前記アプリケーションを実行すること
を特徴とする請求項１乃至請求項４の何れか一に記載のデータ処理方法。
【請求項６】
前記アプリケーションは暗号化機能を有すること
を特徴とする請求項５に記載のデータ処理方法。
【請求項７】
前記所定のグループは、コプロセッサ、デジタルシグナルプロセッサ、またはグローバルポジショニングシステムで実行されるアプリケーションを含むこと
を特徴とする請求項１乃至請求項６の何れか一に記載のデータ処理方法。
【請求項８】
前記他のデータ処理装置が前記アプリケーションを起動しているときに前記第１データ処理装置と前記他のデータ処理装置との間の通信強度が弱まるとき、前記複数のデータ処理装置のうちの前記他のデータ処理装置以外のデータ処理装置が前記アプリケーションを起動すること
を特徴とする請求項１乃至請求項７の何れか一に記載のデータ処理方法。
【請求項９】
それぞれが少なくとも一の周辺ユニットを含む複数のデータ処理装置と、
前記複数のデータ処理装置のうちの第１データ処理装置の第１周辺ユニットに対する起動要求があるときに、前記複数のデータ処理装置のうちの第２データ処理装置の第２周辺ユニットが起動されているときは、前記第１周辺ユニットを起動しないで前記第２周辺ユニットの実行を共用するスケジューラと、
を含むことを特徴とするデータ処理システム。
【請求項１０】
前記第１周辺ユニットの機能と前記第２周辺ユニットの機能とは実質的に同じであること
を特徴とする請求項９に記載のデータ処理システム。
【請求項１１】
前記スケジューラは、前記起動要求に基づいて前記複数のデータ処理装置のうちの前記第１データ処理装置以外のデータ処理装置に対してブロードキャスト通信を行うこと
を特徴とする請求項９または請求項１０に記載のデータ処理システム。
【請求項１２】
前記周辺ユニットは、コプロセッサ、デジタルシグナルプロセッサ、またはグローバルポジショニングシステムを含むこと
を特徴とする請求項９乃至請求項１１の何れか一に記載のデータ処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理方法およびデータ処理システムに関する。
【背景技術】
【０００２】
従来、携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）等の端末をノードとして、複数のノードを、分散したメモリを有するマルチプロセッサとすることで分散並列処理を行う技術がある。このような分散メモリ型の計算機でアプリケーションを動作させることによりスケーラブルな性能を達成することが可能となる。【０００３】
また、コプロセッサ、ＤＳＰ（Ｄｉｇｉｔａｌ  Ｓｉｇｎａｌ  Ｐｒｏｃｅｓｓｏｒ）、ＧＰＳ（Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）等のハードウェアを備えた端末の登場により、グラフィックアプリ、マルチメディアアプリ、地図アプリ等の様々なアプリケーションを各端末上で動作させることができるようになってきている。【０００４】
関連する先行技術としては、例えば、電子機器が、自機のジョブの実行中に自機のリソースの残量が所定量以下になった場合に、他の電子機器に対してリソースの借用を要求するものがある。また、計算資源の借用者と提供者の間で電子的デバイスを用いて認証処理を行い、互いに正当性を認識した場合に、借用者から提供者に課題解決のアプリケーションを送信し、提供者が自己の計算資源を用いてアプリケーションを実施して借用者に送信する技術がある。また、分散システムにおいて、複数の機器から検出された、要求されたサービスに必要な資源が、資源公開ポリシを満たすか否かを判定し、資源公開ポリシを満たす資源を連携させてサービスを提供する技術がある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−３２５２３５号公報
【特許文献２】特開２００５−５０２７２号公報
【特許文献３】特開２００４−１９９３００号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、従来技術では、複数のデータ処理装置（例えば、端末）を含むシステムにおいて、各々のデータ処理装置がアプリケーションを実行する場合の、システム全体でのエネルギー効率に対する配慮が十分ではないという問題がある。【０００７】
本発明は、上述した従来技術による問題点を解消するため、複数のデータ処理装置を含むシステム全体の消費電力を抑制することができるデータ処理方法およびデータ処理システムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上述した課題を解決し、目的を達成するため、本発明の一側面によれば、複数のデータ処理装置のうちの第１データ処理装置に起動要求されたアプリケーションが所定のグループに属するか否かを判定し、前記アプリケーションが前記所定のグループに属するときは、前記複数のデータ処理装置の他のデータ処理装置で前記アプリケーションが起動されているか否かを判定し、前記アプリケーションが前記他のデータ処理装置で起動されているときは、前記第１データ処理装置は前記アプリケーションを起動しないデータ処理方法が提案される。【０００９】
また、本発明の別の一側面によれば、それぞれが少なくとも一の周辺ユニットを含む複数のデータ処理装置と、前記複数のデータ処理装置のうちの第１データ処理装置の第１周辺ユニットに対する起動要求があるときに、前記複数のデータ処理装置のうちの第２データ処理装置の第２周辺ユニットが起動されているときは、前記第１周辺ユニットを起動しないで前記第２周辺ユニットの実行を共用するスケジューラと、を含むデータ処理システムが提案される。
【発明の効果】
【００１０】
本発明の一側面によれば、複数のデータ処理装置を含むシステム全体の消費電力を抑制することができるという効果を奏する。
【図面の簡単な説明】
【００１１】
【図１】図１は、実施の形態１にかかるデータ処理方法の一実施例を示す説明図である。
【図２】図２は、実施の形態２にかかるデータ処理システムのシステム構成例を示す説明図である。
【図３】図３は、実施の形態２にかかる携帯端末のハードウェア構成例を示す説明図である。
【図４】図４は、共用リソーステーブルの記憶内容の一例を示す説明図である。
【図５】図５は、実施の形態２にかかる携帯端末の機能的構成例を示すブロック図である。
【図６】図６は、共用リソースフラグテーブルの記憶内容の一例を示す説明図である。
【図７】図７は、アクセス許可テーブルの記憶内容の一例を示す説明図である。
【図８】図８は、携帯端末間の動作連携例を示す説明図である。
【図９】図９は、実施の形態２にかかる携帯端末のデータ処理手順の一例を示すフローチャート（その１）である。
【図１０】図１０は、実施の形態２にかかる携帯端末のデータ処理手順の一例を示すフローチャート（その２）である。
【図１１】図１１は、実施の形態３にかかる携帯端末のデータ処理手順の一例を示すフローチャート（その１）である。
【図１２】図１２は、実施の形態３にかかる携帯端末のデータ処理手順の一例を示すフローチャート（その２）である。
【図１３】図１３は、本実施の形態にかかるコンピュータを用いたシステムの適用例を示す説明図である。
【発明を実施するための形態】
【００１２】
以下に添付図面を参照して、この発明にかかるデータ処理方法およびデータ処理システムの実施の形態を詳細に説明する。
【００１３】
（実施の形態１）
図１は、実施の形態１にかかるデータ処理方法の一実施例を示す説明図である。図１において、データ処理装置１０１，１０２は、アプリケーション（以下、単に「アプリ」ともいう）を実行可能なコンピュータである。データ処理装置１０１，１０２は、例えば、携帯電話、ＰＤＡ、スマートフォン、ノートＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）、ゲーム機器、ＰＣ、サーバなどである。
【００１４】
各データ処理装置１０１，１０２は、少なくとも一のＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）と、少なくとも一の周辺ユニットと、を含む。図１の例では、データ処理装置１０１は、ＣＰＵ１１１，１１２と、周辺ユニットＰ１〜Ｐ３と、を含む。ＣＰＵ１１１は、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）１１３を実行し、データ処理装置１０１の全体の制御を司る。ＯＳ１１３は、アプリケーションをどのＣＰＵに割り当てるかを制御するスケジューラ１１５を備えている。また、ＣＰＵ１１１は、割り当てられたアプリケーションを実行する。ＣＰＵ１１２は、ＯＳ１１４を実行し、ＯＳ１１４に割り当てられたアプリケーションを実行する。
【００１５】
また、データ処理装置１０２は、ＣＰＵ１２１，１２２と、周辺ユニットＰ１〜Ｐ３と、を含む。ＣＰＵ１２１は、ＯＳ１２３を実行し、データ処理装置１０２の全体の制御を司る。ＯＳ１２３は、アプリケーションをどのＣＰＵに割り当てるかを制御するスケジューラ１２５を備えている。また、ＣＰＵ１２１は、割り当てられたアプリケーションを実行する。ＣＰＵ１２２は、ＯＳ１２４を実行し、ＯＳ１２４に割り当てられたアプリケーションを実行する。
【００１６】
周辺ユニットＰ１〜Ｐ３は、各種アプリケーションを実行する際に用いられるハードウェアリソースであり、例えば、コプロセッサ、ＤＳＰ、ＧＰＳデバイス、カメラデバイス、通信Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）、暗号化回路などである。図１において、データ処理装置１０１の周辺ユニットＰ１と、データ処理装置１０２の周辺ユニットＰ１とは、機能が実質的に同じであればよく、例えば、処理性能が異なるものであってもよい。周辺ユニットＰ２，Ｐ３についても同様である。
【００１７】
例えば、地図アプリや経路探索アプリなどを実行する場合、コプロセッサやＧＰＳデバイスなどのハードウェアリソースが用いられる。また、マルチメディアアプリを実行する場合、コプロセッサやＤＳＰなどのハードウェアリソースが用いられる。また、グラフィックアプリケーションを実行する場合、コプロセッサなどのハードウェアリソースが用いられる。また、ＳＮＳ（Ｓｏｃｉａｌ  Ｎｅｔｗｏｒｋｉｎｇ  Ｓｅｒｖｉｃｅ）アプリや業務アプリを実行する場合、暗号化回路などのハードウェアリソースが用いられる。
【００１８】
ここで、データ処理装置１０１，１０２それぞれが、実質的に同じハードウェアリソースを用いて、同一または異なるアプリケーションを実行すると、データ処理装置１０１，１０２全体としてエネルギー効率が良いとはいえない場合がある。
【００１９】
例えば、同一エリアに存在するデータ処理装置１０１，１０２が、ＧＰＳデバイスを用いたアプリケーションをそれぞれ実行する場合を想定する。なお、エリアとは、地図上の領域を区切って分割されたいずれかのエリアである。この場合、同一エリアに存在するデータ処理装置１０１，１０２の座標データは、ほぼ同じものとなる。このため、各データ処理装置１０１，１０２で個別にＧＰＳデバイスを動作させて座標データを取得することは効率的ではない。また、ハードウェアリソースを起動すると処理内容に関わらず所定の電力が消費されるため、起動中のハードウェアリソース数が増えるほどシステム全体としての消費電力が増加する。
【００２０】
そこで、実施の形態１では、複数のデータ処理装置（例えば、データ処理装置１０１，１０２）が、機能が実質的に同じ周辺ユニットを用いるアプリケーションを各々実行する際に、いずれかのデータ処理装置で最初に起動された周辺ユニットを装置間で共用する。これにより、各々のデータ処理装置で周辺ユニットを起動しなくてもアプリケーションを実行することが可能となり、システム全体としての消費電力を削減する。
【００２１】
以下、データ処理装置１０１，１０２のデータ処理手順の一実施例について説明する。ここでは、一例として、データ処理装置１０２が周辺ユニットＰ１を用いるアプリｂを実行していることにし、また、周辺ユニットＰ３を「通信Ｉ／Ｆ」とする。
【００２２】
（１）データ処理装置１０１は、アプリａの起動要求を受け付ける。具体的には、例えば、スケジューラ１１５が、ＯＳ１１３からアプリａの起動要求を受け付ける。ここで、アプリａは、実行時に周辺ユニットＰ１を用いるアプリケーションである。
【００２３】
（２）データ処理装置１０１は、アプリａを実行する際に用いる周辺ユニットＰ１を起動しているか否かをデータ処理装置１０２に問い合わせる。具体的には、例えば、スケジューラ１１５が、通信Ｉ／Ｆ（周辺ユニットＰ３）を介して、周辺ユニットＰ１の起動確認要求をデータ処理装置１０２に送信する。
【００２４】
（３）データ処理装置１０２は、周辺ユニットＰ１を起動しているか否かの問い合わせを受け付けると、周辺ユニットＰ１を起動しているか否かを判断する。具体的には、例えば、スケジューラ１２５が、周辺ユニットＰ１が起動中であることを示すフラグがセットされているか否かを判断する。
【００２５】
（４）データ処理装置１０２は、周辺ユニットＰ１を起動しているか否かを示す起動確認応答をデータ処理装置１０１に送信する。具体的には、例えば、スケジューラ１２５が、通信Ｉ／Ｆ（周辺ユニットＰ３）を介して、周辺ユニットＰ１の起動確認応答をデータ処理装置１０１に送信する。
【００２６】
ここでは、アプリｂの実行に用いられる周辺ユニットＰ１が動作している、すなわち、周辺ユニットＰ１が起動中であることを示すフラグがセットされている。このため、データ処理装置１０２が、周辺ユニットＰ１を起動中であることを示す起動確認応答をデータ処理装置１０１に送信する。この結果、データ処理装置１０１によって周辺ユニットＰ１の起動確認応答が受信される。
【００２７】
（５）データ処理装置１０１は、データ処理装置１０２で周辺ユニットＰ１が起動中の場合、データ処理装置１０２で起動中の周辺ユニットＰ１を用いてアプリａを実行する。すなわち、データ処理装置１０１は、自装置の周辺ユニットＰ１を起動しないで、データ処理装置１０２で起動中の周辺ユニットＰ１をデータ処理装置１０２と共用する。
【００２８】
なお、上記（５）において、データ処理装置１０２で周辺ユニットＰ１が起動されていない場合、データ処理装置１０１は、自装置の周辺ユニットＰ１を起動してアプリａを実行することになる。この場合、自装置の周辺ユニットＰ１が起動中であることを示すフラグがセットされる。
【００２９】
以上説明した実施の形態１によれば、データ処理装置１０１が周辺ユニットＰ１を用いるアプリａを実行する際に、データ処理装置１０２で既に起動されている周辺ユニットＰ１を利用することができる。これにより、データ処理装置１０１で周辺ユニットＰ１を起動しなくてもアプリａを実行することが可能となり、システム全体としての消費電力を削減することができる。
【００３０】
（実施の形態２）
つぎに、実施の形態２にかかるデータ処理システムについて説明する。なお、実施の形態１で説明した箇所と同様の箇所については説明を省略する。
【００３１】
図２は、実施の形態２にかかるデータ処理システムのシステム構成例を示す説明図である。図２において、データ処理システム２００は、携帯端末Ｎ１〜Ｎｎを含む（ｎ：２以上の自然数）。携帯端末Ｎ１〜Ｎｎは、例えば、携帯電話、ＰＤＡ、スマートフォン、ノートＰＣ、ゲーム機器などのコンピュータであり、図１に示したデータ処理装置１０１，１０２に相当する。
【００３２】
データ処理システム２００において、携帯端末Ｎ１〜Ｎｎは、無線または有線のネットワーク２１０を介して相互に通信可能に接続されている。ネットワーク２１０は、例えば、アドホックネットワーク、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、インターネットなどである。
【００３３】
アドホックネットワークは、無線通信でリンクする自己構成型のネットワークの一種である。アドホックネットワークは複数のノード（携帯端末Ｎ１〜Ｎｎ）により構成される。アドホックネットワーク内の各携帯端末Ｎ１〜Ｎｎは、他の携帯端末とアドホック通信可能である。なお、データ処理システム２００は、基地局やゲートウェイを含むことにしてもよい。
【００３４】
（携帯端末Ｎ１〜Ｎｎのハードウェア構成例）
つぎに、実施の形態２にかかる携帯端末Ｎ１〜Ｎｎのハードウェア構成例について説明する。以下の説明では、携帯端末Ｎ１〜Ｎｎのうち任意の携帯端末を「携帯端末Ｎｉ」と表記する（ｉ＝１，２，…，ｎ）。
【００３５】
図３は、実施の形態２にかかる携帯端末のハードウェア構成例を示す説明図である。図３において、携帯端末Ｎｉは、ＣＰＵ＃１〜ＣＰＵ＃ｋ（ｋ：１以上の自然数）と、メモリ３０１と、コプロセッサ３０２と、ＤＳＰ３０３と、ＧＰＳ３０４と、暗号化回路３０５と、通信Ｉ／Ｆ３０６と、を有している。
【００３６】
携帯端末Ｎｉにおいて、ＣＰＵ＃１〜ＣＰＵ＃ｋ、メモリ３０１、コプロセッサ３０２、ＤＳＰ３０３、ＧＰＳ３０４、暗号化回路３０５および通信Ｉ／Ｆ３０６は、バス３１０を介して接続されている。また、図面では、携帯端末Ｎｉが有するソフトウェア（ＯＳ＃１〜＃ｋ、スケジューラ３２０）を一部抜粋して表示している。
【００３７】
ＣＰＵ＃１は、ＯＳ＃１を実行し、携帯端末Ｎｉの全体の制御を司る。ＯＳ＃１は、マスタＯＳであり、アプリケーションをどのＣＰＵに割り当てるかを制御するスケジューラ３２０を備えている。また、ＣＰＵ＃１は、割り当てられたアプリケーションを実行する。ＣＰＵ＃２〜ＣＰＵ＃ｋは、それぞれＯＳ＃２〜ＯＳ＃ｋを実行し、各ＯＳに割り当てられたアプリケーションを実行する。ＯＳ＃２〜ＯＳ＃ｋは、スレーブＯＳである。
【００３８】
メモリ３０１は、ＣＰＵ＃１〜ＣＰＵ＃ｋに共有されるメモリである。メモリ３０１は、例えば、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）およびフラッシュＲＯＭなどを有している。
【００３９】
具体的には、例えば、フラッシュＲＯＭが各ＯＳのプログラムを記憶し、ＲＯＭがアプリケーションプログラムを記憶し、ＲＡＭがＣＰＵ＃１〜ＣＰＵ＃ｋのワークエリアとして使用される。メモリ３０１に記憶されているプログラムは、各ＣＰＵにロードされることで、コーディングされている処理を該各ＣＰＵに実行させることになる。
【００４０】
コプロセッサ３０２は、ＣＰＵ＃１〜ＣＰＵ＃ｋの補助を行う副処理装置である。コプロセッサ３０２としては、例えば、ＦＰＵ（Ｆｌｏａｔｉｎｇ  Ｐｏｉｎｔ  ｎｕｍｂｅｒ  ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、ＧＰＵ（Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）などがある。
【００４１】
ＤＳＰ３０３は、音声や画像などの処理に特化したマイクロプロセッサである。ＧＰＳ３０４は、ＧＰＳ衛星からの電波を受信し、携帯端末Ｎｉの位置を示す位置情報を出力するデバイスである。携帯端末Ｎｉの位置情報は、例えば、緯度・経度、高度などの地球上の１点を特定する座標データである。
【００４２】
暗号化回路３０５は、データを暗号化する回路である。通信Ｉ／Ｆ３０６は、通信回線を通じてネットワーク２１０に接続され、ネットワーク２１０を介して外部装置に接続される。そして、通信Ｉ／Ｆ３０６は、ネットワーク２１０と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。
【００４３】
なお、図示は省略するが、携帯端末Ｎｉは、例えば、メモリ３０１に対するデータのリード／ライトを制御するメモリコントローラ、各部に電源電圧を供給するＰＭＵ（Ｐｏｗｅｒ  Ｍａｎａｇｅｍｅｎｔ  Ｕｎｉｔ）のほか、ディスプレイやキーボードなどを有することにしてもよい。
【００４４】
また、上述した説明では、携帯端末Ｎ１〜Ｎｎが同様のハードウェア構成を有するものとして説明したが、これに限らない。具体的には、例えば、携帯端末Ｎｉは、上述した周辺ユニット（符号３０１〜３０６）とは異なる周辺ユニットを有することにしてもよく、また、上述した周辺ユニット（符号３０１〜３０６）の一部を有さないことにしてもよい。
【００４５】
（共用リソーステーブル４００の記憶内容）
つぎに、携帯端末Ｎｉが用いる共用リソーステーブル４００について説明する。ここで、アプリケーションの実行に用いられる周辺ユニットの中には、複数の携帯端末間で共用するのに好ましくないものがある。例えば、図３に示した暗号化回路３０５は、セキュリティの観点から複数の携帯端末間で共用するのに好ましくない。共用リソーステーブル４００は、各アプリケーションの実行に用いられる周辺ユニットのうち、複数の携帯端末間での共用を許可する周辺ユニットを示す情報である。
【００４６】
図４は、共用リソーステーブルの記憶内容の一例を示す説明図である。図４において、共用リソーステーブル４００は、アプリＩＤ、アプリ名および共用リソース名のフィールドを有し、各フィールドに情報を設定することで、アプリケーションＡ１〜Ａｍごとの共用リソース情報４００−１〜４００−ｍをレコードとして記憶している。
【００４７】
アプリＩＤは、本明細書において使用する各アプリケーションの識別子である。アプリ名は、各アプリケーションの名称である。共用リソース名は、各アプリケーションの実行に用いられる周辺ユニットのうち、複数の携帯端末間での共用を許可する周辺ユニットの名称である。
【００４８】
共用リソース情報４００−１を例に挙げると、アプリケーションＡ１のアプリ名「グラフィック」およびアプリケーションＡ１の実行時に複数の携帯端末間で共用可能な共用リソース名「コプロセッサ」が示されている。
【００４９】
また、共用リソース情報４００−２を例に挙げると、アプリケーションＡ２のアプリ名「マルチメディア」およびアプリケーションＡ２の実行時に複数の携帯端末間で共用可能な共用リソース名「コプロセッサ、ＤＳＰ」が示されている。
【００５０】
共用リソーステーブル４００は、例えば、図３に示したメモリ３０１に記憶されている。具体的には、例えば、各アプリケーションＡ１〜Ａｍの共用リソース情報４００−１〜４００−ｍは、各アプリケーションＡ１〜Ａｍの実行オブジェクトとともに携帯端末Ｎｉのファイルシステムに格納されている。なお、共用リソーステーブル４００は、例えば、各アプリケーションのコンパイル時に、各アプリケーションのメイクファイルを参照して、複数の携帯端末間で共用可能な周辺ユニットと各携帯端末Ｎが有する周辺ユニットとを照合することで作成される。
【００５１】
（携帯端末Ｎｉの機能的構成例）
図５は、実施の形態２にかかる携帯端末の機能的構成例を示すブロック図である。図５において、携帯端末Ｎｉは、検出部５０１と、判定部５０２と、送信部５０３と、受信部５０４と、判断部５０５と、切替部５０６と、割当部５０７と、設定部５０８と、を含む構成である。この制御部となる機能（検出部５０１〜設定部５０８）は、具体的には、例えば、図３に示したメモリ３０１に記憶されたプログラムをＣＰＵ♯１に実行させることにより、または、通信Ｉ／Ｆ３０６により、その機能を実現する。また、各機能部の処理結果は、例えば、メモリ３０１に記憶される。
【００５２】
まず、携帯端末Ｎｉが他の携帯端末Ｎｊ（ｊ≠ｉ、ｊ＝１，２，…，ｎ）に対して共用リソースの使用を依頼する側（以下、「クライアント」という）となる場合の携帯端末Ｎｉの各機能部について説明する。
【００５３】
検出部５０１は、アプリケーションの起動要求を検出する。具体的には、例えば、スケジューラ３２０が、ＯＳ＃１からのアプリケーションの起動要求を検出する。以下の説明では、起動要求が検出されたアプリケーションを「アプリＡ」と表記する。
【００５４】
判定部５０２は、アプリＡの起動要求が検出された場合、アプリＡの実行時に共用リソースＰを使用するか否かを判定する。ここで、共用リソースＰとは、複数の携帯端末間での共用が許可されている周辺ユニット、すなわち、複数の携帯端末間で共用可能な周辺ユニットである。
【００５５】
具体的には、例えば、スケジューラ３２０が、図４に示した共用リソーステーブル４００を参照して、アプリＡの実行時に共用リソースＰを使用するか否かを判定する。例えば、アプリＡを「アプリケーションＡ１」とする。この場合、スケジューラ３２０が、共用リソーステーブル４００を参照して、アプリケーションＡ１の実行時に共用リソースＰとして「コプロセッサ３０２」を使用すると判定する。また、例えば、アプリＡを「アプリケーションＡ３」とする。この場合、スケジューラ３２０が、共用リソーステーブル４００を参照して、アプリケーションＡ３の実行時に共用リソースＰとして「コプロセッサ３０２、ＧＰＳ３０４」を使用すると判定する。
【００５６】
送信部５０３は、アプリＡの実行時に共用リソースＰを使用すると判定された場合、共用リソースＰの起動確認要求を他の携帯端末Ｎｊに送信する。ここで、共用リソースＰの起動確認要求とは、共用リソースＰを起動しているか否かを他の携帯端末Ｎｊに問い合わせる情報である。
【００５７】
具体的には、例えば、スケジューラ３２０が、通信Ｉ／Ｆ３０６を制御して、アドホック通信により、共用リソースＰの起動確認要求をネットワーク２１０にブロードキャストする。例えば、アプリＡを「アプリケーションＡ１」とする。この場合、スケジューラ３２０が、共用リソースＰであるコプロセッサ３０２の起動確認要求をブロードキャストする。
【００５８】
また、アプリＡの実行時に用いられる共用リソースＰが複数存在する場合、スケジューラ３２０は、各々の共用リソースＰの起動確認要求をブロードキャストする。例えば、アプリＡを「アプリケーションＡ３」とする。この場合、スケジューラ３２０が、共用リソースＰであるコプロセッサ３０２の起動確認要求およびＧＰＳ３０４の起動確認要求をブロードキャストしてもよく、また、コプロセッサ３０２およびＧＰＳ３０４の起動確認要求を一括してブロードキャストしてもよい。
【００５９】
受信部５０４は、共用リソースＰの起動確認要求が送信された結果、共用リソースＰの起動確認応答を他の携帯端末Ｎｊから受信する。ここで、共用リソースＰの起動確認応答とは、共用リソースＰを起動しているか否かを示す情報である。具体的には、例えば、スケジューラ３２０が、通信Ｉ／Ｆ３０６を介して、共用リソースＰの起動確認応答を他の携帯端末Ｎｊから受信する。
【００６０】
判断部５０５は、受信された共用リソースＰの起動確認応答に基づいて、アプリＡの実行に用いられる共用リソースＰが他の携帯端末Ｎｊで起動しているか否かを判断する。具体的には、例えば、他の携帯端末Ｎｊから共用リソースＰを起動していることを示す起動確認応答が受信された場合、スケジューラ３２０が、共用リソースＰが他の携帯端末Ｎｊで起動していると判断する。
【００６１】
一方、共用リソースＰの起動確認要求が送信されてから一定時間経過しても、共用リソースＰを起動していることを示す起動確認応答が受信されなかった場合、スケジューラ３２０が、共用リソースＰが他の携帯端末Ｎｊで起動していないと判断してもよい。また、一定時間経過前に、携帯端末Ｎ１〜Ｎｎのうち自端末とは異なるすべての携帯端末から、共用リソースＰを起動していないことを示す起動確認応答が受信された場合は、スケジューラ３２０が、共用リソースＰが他の携帯端末Ｎｊで起動していないと判断する。
【００６２】
切替部５０６は、共用リソースＰが他の携帯端末Ｎｊで起動していると判断された場合、共用リソースＰのデバイスドライバを、実デバイスドライバから仮想デバイスドライバに切り替える。ここで、実デバイスドライバとは、自端末の共用リソースＰを動作させるためのソフトウェアである。仮想デバイスドライバとは、ネットワーク２１０を介して他の携帯端末Ｎｊと通信することにより、共用リソースＰの機能を、他の携帯端末Ｎｊで起動している共用リソースＰを用いて実現するためのソフトウェアである。
【００６３】
具体的には、例えば、他の携帯端末Ｎｊで共用リソースＰが起動している場合、スケジューラ３２０が、共用リソースＰのドライバＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）に関連付けるデバイスドライバを、実デバイスドライバから仮想デバイスドライバに切り替える。なお、初期状態では、共用リソースＰのドライバＡＰＩは、共用リソースＰの実デバイスドライバと関連付けられている。より具体的には、例えば、スケジューラ３２０が、共用リソースＰの実デバイスドライバをアンロードした後、共用リソースＰの仮想デバイスドライバをロードする。
【００６４】
また、共用リソースＰのドライバＡＰＩに、共用リソースＰの仮想デバイスドライバを関連付ける場合、スケジューラ３２０が、共用リソースＰを起動している他の携帯端末Ｎｊの識別情報を仮想デバイスドライバに設定する。他の携帯端末Ｎｊの識別情報としては、例えば、他の携帯端末Ｎｊのアドレスを用いることができる。これにより、アプリＡの実行に用いられる共用リソースＰを起動している他の携帯端末Ｎｊを識別することができる。
【００６５】
また、共用リソースＰを起動している他端末が複数存在する場合がある。この場合、スケジューラ３２０が、共用リソースＰを起動している複数の他端末のうち、最も早く起動確認応答を送信してきた他端末の識別情報を仮想デバイスドライバに設定することにしてもよい。
【００６６】
また、スケジューラ３２０が、共用リソースＰを起動している複数の他端末のうち、共用リソースＰの負荷が最小となる他端末の識別情報を仮想デバイスドライバに設定することにしてもよい。ここで、共用リソースＰの負荷とは、例えば、共用リソースＰの使用率である。
【００６７】
各他端末での共用リソースＰの負荷を特定する負荷情報は、例えば、共用リソースＰを起動していることを示す起動確認応答に含まれている。このように、共用リソースＰを起動している他端末が複数存在する場合は、より負荷が小さい共用リソースＰを選択して共用することにより、共用リソースＰの処理待ちが発生することを回避することができる。
【００６８】
また、切替部５０６は、共用リソースＰのデバイスドライバを仮想デバイスドライバに切り替えた場合、共用リソースＰの切替フラグを「０」から「１」に設定する。ここで、共用リソースＰの切替フラグとは、共用リソースＰのドライバＡＰＩに関連付けられているデバイスドライバを識別するための情報である。
【００６９】
ここでは、切替フラグが「０」の場合、共用リソースＰのドライバＡＰＩに実デバイスドライバが関連付けられていることを示す。一方、切替フラグが「０」の場合、共用リソースＰのドライバＡＰＩに仮想デバイスドライバが関連付けられていることを示す。なお、初期状態では、共用リソースＰの切替フラグは「０」である。
【００７０】
割当部５０７は、共用リソースＰのデバイスドライバが仮想デバイスドライバに切り替えられた結果、アプリＡをＣＰＵ＃１〜＃ｋのいずれかのＣＰＵに割り当てる。具体的には、例えば、スケジューラ３２０が、各ＣＰＵ＃１〜＃ｋの負荷情報に基づいて、ＣＰＵ＃１〜＃ｋの中からアプリＡの割当先となるＣＰＵを選択して、該ＣＰＵにアプリＡを割り当てる。
【００７１】
この結果、割当先のＣＰＵのＯＳにより、アプリＡが実行される。この場合、共用リソースＰのデバイスドライバが仮想デバイスドライバに切り替えられているため、他の携帯端末Ｎｊで起動している共用リソースＰを用いてアプリＡが実行される。これにより、自端末の共用リソースＰを起動することなく、アプリＡを実行することができる。
【００７２】
なお、複数の携帯端末で共用リソースＰを共用する際の携帯端末間の動作連携例については、図８を用いて後述する。
【００７３】
設定部５０８は、共用リソースＰが他の携帯端末Ｎｊで起動していないと判断された場合、共用リソースＰを起動していることを示すフラグを設定する。具体的には、例えば、スケジューラ３２０が、図６に示す共用リソースフラグテーブル６００に、共用リソースＰを起動していることを示すフラグを設定することにしてもよい。
【００７４】
ここで、共用リソースフラグテーブル６００について説明する。共用リソースフラグテーブル６００は、例えば、メモリ３０１により実現される。
【００７５】
図６は、共用リソースフラグテーブルの記憶内容の一例を示す説明図である。図６において、共用リソースフラグテーブル６００は、共用リソース名および共用リソースフラグのフィールドを有する。各フィールドに情報を設定することで、各共用リソースを起動しているか否かを示すフラグ情報６００−１〜６００−３が記憶されている。
【００７６】
共用リソース名は、共用リソースの名称である。この共有リソースは、例えば、図４に示した共用リソーステーブル４００に登録されている周辺ユニットである。共用リソースフラグは、共用リソースを起動しているか否かを示すフラグである。ここでは、共用リソースフラグが「０」の場合、共用リソースを起動していないことを示す。一方、共用リソースフラグが「１」の場合は、共用リソースを起動していることを示す。なお、初期状態では、共用リソースフラグは「０」である。
【００７７】
一例として、共用リソースＰである「コプロセッサ３０２」が他の携帯端末Ｎｊで起動していないと判断された場合、スケジューラ３２０が、共用リソースフラグテーブル６００内のフラグ情報６００−１の共用リソースフラグを「０」から「１」に変更する。
【００７８】
図５の説明に戻り、割当部５０７は、共用リソースＰが他の携帯端末Ｎｊで起動していないと判断された場合、アプリＡをＣＰＵ＃１〜＃ｋのいずれかのＣＰＵに割り当てる。この結果、割当先のＣＰＵのＯＳにより、アプリＡが実行される。この場合、共用リソースＰのデバイスドライバが実デバイスドライバのため、自端末の共用リソースＰを用いてアプリＡが実行される。
【００７９】
なお、上述した設定部５０８による、共用リソースＰを起動していることを示すフラグを設定する処理は、アプリＡがいずれかのＣＰＵに割り当てられた後に行われることにしてもよい。
【００８０】
また、割当部５０７は、アプリＡの実行時に共用リソースＰを使用しないと判定された場合、アプリＡをＣＰＵ＃１〜＃ｋのいずれかのＣＰＵに割り当てる。この結果、割当先のＣＰＵのＯＳにより、アプリＡが実行される。すなわち、アプリＡの実行に用いられる周辺ユニットの中に、他の携帯端末Ｎｊと共用可能な周辺ユニットがないため、自端末の周辺ユニットを用いてアプリＡが実行される。
【００８１】
つぎに、携帯端末Ｎｉが他の携帯端末Ｎｊから共用リソースＰの使用を依頼される側（以下、「サーバ」という）となる場合の携帯端末Ｎｉの各機能部について説明する。
【００８２】
受信部５０４は、共用リソースＰの起動確認要求を他の携帯端末Ｎｊから受信する。ここで、共用リソースＰは、他の携帯端末Ｎｊで起動要求が検出されたアプリＡの実行に用いられる共用リソースである。具体的には、例えば、スケジューラ３２０が、ネットワーク２１０を介して、共用リソースＰの起動確認要求を他の携帯端末Ｎｊから受信する。
【００８３】
判断部５０５は、共用リソースＰの起動確認要求が受信された場合、自端末で共用リソースＰを起動しているか否かを判断する。具体的には、例えば、スケジューラ３２０が、図６に示した共用リソースフラグテーブル６００を参照して、自端末で共用リソースＰを起動しているか否かを判断することにしてもよい。
【００８４】
一例として、共用リソースＰである「コプロセッサ３０２」の起動確認要求が受信されたとする。この場合、スケジューラ３２０が、共用リソースフラグテーブル６００の中からコプロセッサ３０２のフラグ情報６００−１を特定する。そして、フラグ情報６００−１の共用リソースフラグに「１」が設定されている場合、スケジューラ３２０が、コプロセッサ３０２を起動していると判断する。一方、フラグ情報６００−１の共用リソースフラグに「０」が設定されている場合、スケジューラ３２０が、コプロセッサ３０２を起動していないと判断する。
【００８５】
送信部５０３は、共用リソースＰの起動確認応答を他の携帯端末Ｎｊに送信する。具体的には、例えば、共用リソースＰを起動していないと判断された場合、スケジューラ３２０が、通信Ｉ／Ｆ３０６を制御して、アドホック通信により、共用リソースＰを起動していないことを示す起動確認応答を要求元の他の携帯端末Ｎｊに送信する。一方、共用リソースＰを起動していると判断された場合、スケジューラ３２０が、通信Ｉ／Ｆ３０６を制御して、アドホック通信により、共用リソースＰを起動していることを示す起動確認応答を要求元の他の携帯端末Ｎｊに送信する。
【００８６】
また、設定部５０８は、共用リソースＰを起動していると判断された場合、他の携帯端末Ｎｊからの共用リソースＰに対するアクセス許可を設定する。具体的には、例えば、スケジューラ３２０が、図７に示すアクセス許可テーブル７００に要求元の他の携帯端末Ｎｊからの共用リソースＰに対するアクセス許可を設定することにしてもよい。
【００８７】
ここで、アクセス許可テーブル７００について説明する。アクセス許可テーブル７００は、例えば、メモリ３０１により実現される。
【００８８】
図７は、アクセス許可テーブルの記憶内容の一例を示す説明図である。図７において、アクセス許可テーブル７００は、共用リソース名および端末ＩＤのフィールドを有する。各フィールドに情報を設定することで、共用リソースごとのアクセス許可情報７００−１〜７００−３がレコードとして記憶されている。
【００８９】
共用リソース名は、共用リソースの名称である。この共有リソースは、例えば、図４に示した共用リソーステーブル４００に登録されている周辺ユニットである。端末ＩＤは、共用リソースに対するアクセスを許可する他の携帯端末Ｎｊの識別情報である。端末ＩＤとしては、例えば、他の携帯端末Ｎｊのアドレスを用いることができる。
【００９０】
例えば、自端末を携帯端末Ｎ１とし、携帯端末Ｎ２から「コプロセッサ３０２」の起動確認要求を受信した場合を例に挙げる。ここで、コプロセッサ３０２を起動している場合、スケジューラ３２０が、アクセス許可テーブル７００内のアクセス許可情報７００−１の端末ＩＤフィールドに携帯端末Ｎ２の端末ＩＤ「Ｎ２」を設定する（図７中、（７−２）参照）。
【００９１】
以降、携帯端末Ｎ１は、携帯端末Ｎ２から自端末のコプロセッサ３０２に対するアクセス要求があった場合、コプロセッサ３０２に対するアクセスを許可する。一方、アクセス許可情報７００−１の端末ＩＤフィールドに端末ＩＤが設定されていない他の携帯端末Ｎｊからコプロセッサ３０２に対するアクセス要求があった場合、携帯端末Ｎ１は、コプロセッサ３０２に対するアクセスを許可しない。
【００９２】
これにより、自端末で起動している共用リソースＰをクライアントと共用することができるとともに、クライアント以外の他端末からの共用リソースＰに対する不正なアクセスを防ぐことができる。
【００９３】
図５の説明に戻り、判断部５０５は、共用リソースＰの動作が終了したか否かを判断する。具体的には、例えば、スケジューラ３２０が、自端末での共用リソースＰを用いたアプリケーションの実行が終了した場合に、共用リソースＰの動作が終了したと判断することにしてもよい。
【００９４】
また、設定部５０８は、共用リソースＰの動作が終了したと判断された場合、共用リソースＰが起動していないことを示すフラグを設定する。具体的には、例えば、スケジューラ３２０が、共用リソースフラグテーブル６００に、共用リソースＰが起動していないことを示すフラグを設定することにしてもよい。
【００９５】
一例として、共用リソースＰである「コプロセッサ３０２」の動作が終了したと判断された場合、スケジューラ３２０が、共用リソースフラグテーブル６００内のフラグ情報６００−１の共用リソースフラグを「１」から「０」に変更する。
【００９６】
また、設定部５０８は、共用リソースＰの動作が終了したと判断された場合、他の携帯端末Ｎｊからの共用リソースＰに対するアクセス許可を解除（すなわち、アクセス禁止）する。具体的には、例えば、スケジューラ３２０が、アクセス許可テーブル７００に設定されている他の携帯端末Ｎｊからの共用リソースＰに対するアクセス許可を解除することにしてもよい。
【００９７】
例えば、図７に示す（７−２）において、コプロセッサ３０２の動作が終了した場合、スケジューラ３２０が、アクセス許可テーブル７００内のアクセス許可情報７００−１の端末ＩＤフィールドから携帯端末Ｎ２の端末ＩＤ「Ｎ２」を削除する（図７中、（７−３）参照）。これにより、他の携帯端末Ｎｊからの共用リソースＰに対する不正なアクセスを防ぐことができる。
【００９８】
また、設定部５０８は、自端末で起動している共用リソースＰを共用しているクライアントとの通信が切断された場合、該クライアントからの共用リソースＰに対するアクセス許可を解除することにしてもよい。クライアントとの通信が切断された場合とは、例えば、クライアントとの間で確立されているセッションが切断された場合でもよく、また、クライアントとの間の通信強度が所定値以下となった場合でもよい。
【００９９】
また、判断部５０５は、自端末で起動している共用リソースＰの負荷情報に基づいて、共用リソースＰの負荷が所定値Ｘ以上となるか否かを判断することにしてもよい。所定値Ｘは、例えば、共用リソースＰの負荷が所定値Ｘ以上となると、共用リソースＰの処理待ちが発生するような状態になる値に設定される。なお、所定値Ｘは、例えば、予め設定されてメモリ３０１に記憶されている。
【０１００】
また、設定部５０８は、共用リソースＰの負荷が所定値Ｘ以上であると判断された場合、他の携帯端末Ｎｊからの共用リソースＰに対するアクセス許可を解除することにしてもよい。これにより、共用リソースＰの処理待ちが発生することを防ぐことができる。
【０１０１】
また、共用リソースＰの起動確認要求を受信した時点で、自端末で起動している共用リソースＰの負荷が所定値Ｘ以上の場合、送信部５０３は、共用リソースＰを起動していないことを示す起動確認応答を要求元の他の携帯端末Ｎｊに送信することにしてもよい。これにより、共用リソースＰの処理待ちが発生することを未然に防ぐことができる。
【０１０２】
また、送信部５０３は、共用リソースＰを起動していると判断された場合、共用リソースＰの負荷情報を含む起動確認応答を要求元の他の携帯端末Ｎｊに送信することにしてもよい。これにより、上述したように、共用リソースＰを起動している携帯端末が複数存在する場合に、クライアント側で、より負荷が小さい共用リソースＰを選択して共用することができ、共用リソースＰの処理待ちが発生することを回避することができる。
【０１０３】
（携帯端末間の動作連携例）
つぎに、複数の携帯端末で共用リソースＰを共用する際の携帯端末間の動作連携例について説明する。図８は、携帯端末間の動作連携例を示す説明図である。図８において、携帯端末Ｎ１は、クライアント側の携帯端末であり、周辺ユニット８１０と通信Ｉ／Ｆ８１１とを含む。携帯端末Ｎ２は、サーバ側の携帯端末であり、周辺ユニット８２０と通信Ｉ／Ｆ８２１とを含む。
【０１０４】
通信Ｉ／Ｆ８１１，８２１は、図３に示した通信Ｉ／Ｆ３０６に相当する。また、周辺ユニット８１０と周辺ユニット８２０は、実質的に機能が同じ共用リソースＰであり、例えば、図３に示したコプロセッサ３０２、ＤＳＰ３０３、ＧＰＳ３０４などに相当する。
【０１０５】
ここで、アプリＡａは、実行時に共用リソースＰである周辺ユニット８１０を用いるアプリケーションである。また、アプリＡｂは、実行時に共用リソースＰである周辺ユニット８２０を用いるアプリケーションである。
【０１０６】
ドライバＡＰＩ８１２、実デバイスドライバ８１３および仮想デバイスドライバ８１４は、携帯端末Ｎ１のＯＳに含まれる周辺ユニット８１０に関するプログラムである。また、ドライバＡＰＩ８２２、実デバイスドライバ８２３および仮想デバイスドライバ８２４は、携帯端末Ｎ２のＯＳに含まれる周辺ユニット８２０に関するプログラムである。
【０１０７】
ここでは、クライアント側の携帯端末Ｎ１において、アプリＡａの起動要求が検出された結果、周辺ユニット８１０のドライバＡＰＩ８１２と仮想デバイスドライバ８１４とが関連付けられている。一方、サーバ側の携帯端末Ｎ２では、周辺ユニット８２０のドライバＡＰＩ８２２と実デバイスドライバ８２３とが関連付けられており、アプリＡｂが周辺ユニット８２０を用いて実行されている。
【０１０８】
以下、携帯端末Ｎ１が、携帯端末Ｎ２で起動中の周辺ユニット８２０を用いてアプリＡａを実行する場合の携帯端末Ｎ１，Ｎ２間の動作連携例について説明する。
【０１０９】
まず、アプリＡａが、周辺ユニット８１０のドライバＡＰＩ８１２を介して、仮想デバイスドライバ８１４に関数の引数を渡す。このあと、仮想デバイスドライバ８１４が、通信Ｉ／Ｆ８１１を介して、アドホック通信により、携帯端末Ｎ２の周辺ユニット８２０の実デバイスドライバ８２３宛に関数の引数（関数の名称を含む）を送信する。
【０１１０】
この結果、実デバイスドライバ８２３が、通信Ｉ／Ｆ８２１によって受信された関数の引数を、ドライバＡＰＩ８２２を介して受け取る。つぎに、実デバイスドライバ８２３が、周辺ユニット８２０に関数の引数を与えることにより、関数の戻り値を取得する。
【０１１１】
そして、実デバイスドライバ８２３が、通信Ｉ／Ｆ８２１を介して、アドホック通信により、携帯端末Ｎ１の周辺ユニット８１０の仮想デバイスドライバ８１４宛に関数の戻り値を送信する。この結果、仮想デバイスドライバ８１４が、通信Ｉ／Ｆ８１１によって受信された関数の戻り値を受け取ってアプリＡａに渡す。
【０１１２】
これにより、携帯端末Ｎ１では周辺ユニット８１０を起動することなくアプリＡａを実行することができ、携帯端末Ｎ１，Ｎ２全体としてのエネルギー効率を向上させることができる。
【０１１３】
（携帯端末Ｎｉのデータ処理手順）
つぎに、実施の形態２にかかる携帯端末Ｎｉのデータ処理手順について説明する。ここでは、まず、クライアント側の携帯端末Ｎｉのデータ処理手順について説明する。
【０１１４】
図９は、実施の形態２にかかる携帯端末のデータ処理手順の一例を示すフローチャート（その１）である。図９のフローチャートにおいて、まず、スケジューラ３２０により、アプリＡの起動要求を検出したか否かを判断する（ステップＳ９０１）。
【０１１５】
ここで、スケジューラ３２０により、アプリＡの起動要求を検出するのを待つ（ステップＳ９０１：Ｎｏ）。そして、スケジューラ３２０により、アプリＡの起動要求を検出した場合（ステップＳ９０１：Ｙｅｓ）、共用リソーステーブル４００を参照して、アプリＡの実行時に共用リソースＰを使用するか否かを判定する（ステップＳ９０２）。
【０１１６】
ここで、共用リソースＰを使用しない場合（ステップＳ９０２：Ｎｏ）、ステップＳ９１３に移行する。一方、共用リソースＰを使用する場合（ステップＳ９０２：Ｙｅｓ）、スケジューラ３２０により、共用リソースＰの起動確認要求をネットワーク２１０にブロードキャストする（ステップＳ９０３）。
【０１１７】
つぎに、スケジューラ３２０により、他の携帯端末Ｎｊから共用リソースＰの起動確認応答を受信したか否かを判断する（ステップＳ９０４）。ここで、スケジューラ３２０により、共用リソースＰの起動確認応答を受信するのを待つ（ステップＳ９０４：Ｎｏ）。そして、スケジューラ３２０により、共用リソースＰの起動確認応答を受信した場合（ステップＳ９０４：Ｙｅｓ）、共用リソースＰが他の携帯端末Ｎｊで起動中か否かを判断する（ステップＳ９０５）。
【０１１８】
そして、共用リソースＰが他の携帯端末Ｎｊで起動中の場合（ステップＳ９０５：Ｙｅｓ）、スケジューラ３２０により、共用リソースＰの切替フラグを参照して、共用リソースＰに仮想デバイスドライバが設定されているか否かを判断する（ステップＳ９０６）。
【０１１９】
ここで、共用リソースＰに仮想デバイスドライバが設定されている場合（ステップＳ９０６：Ｙｅｓ）、ステップＳ９０８に移行する。一方、共用リソースＰに仮想デバイスドライバが設定されていない場合（ステップＳ９０６：Ｎｏ）、スケジューラ３２０により、共用リソースＰのデバイスドライバを、実デバイスドライバから仮想デバイスドライバに切り替える（ステップＳ９０７）。
【０１２０】
そして、スケジューラ３２０により、アプリＡをＣＰＵ＃１〜＃ｋのいずれかのＣＰＵに割り当てる（ステップＳ９０８）。つぎに、スケジューラ３２０により、共用リソースＰを起動している他の携帯端末Ｎｊ（以下、単に「サーバ」という）との接続状態が維持されているか否かを判断する生存確認を開始する（ステップＳ９０９）。
【０１２１】
このあと、スケジューラ３２０により、サーバとの通信が切断されたか否かを判断する（ステップＳ９１０）。ここで、サーバとの通信が切断された場合（ステップＳ９１０：Ｙｅｓ）、ステップＳ９０１に戻って、一連の処理を繰り返す。一方、サーバとの通信が切断されていない場合（ステップＳ９１０：Ｎｏ）、スケジューラ３２０により、アプリＡの実行が終了したか否かを判断する（ステップＳ９１１）。
【０１２２】
ここで、アプリＡの実行が終了していない場合（ステップＳ９１１：Ｎｏ）、ステップＳ９１０に戻る。一方、アプリＡの実行が終了した場合（ステップＳ９１１：Ｙｅｓ）、本フローチャートによる一連の処理を終了する。
【０１２３】
また、ステップＳ９０５において、共用リソースＰが他の携帯端末Ｎｊで起動していない場合（ステップＳ９０５：Ｎｏ）、スケジューラ３２０により、共用リソースフラグテーブル６００内の共用リソースＰの共用リソースフラグを「０」から「１」に変更する（ステップＳ９１２）。そして、スケジューラ３２０により、アプリＡをＣＰＵ＃１〜＃ｋのいずれかのＣＰＵに割り当てて（ステップＳ９１３）、本フローチャートによる一連の処理を終了する。
【０１２４】
これにより、共用リソースＰを用いるアプリＡを実行する際に、他の携帯端末Ｎｊで起動している共用リソースＰを利用してアプリＡを実行することができる。
【０１２５】
つぎに、サーバ側の携帯端末Ｎｉのデータ処理手順について説明する。
【０１２６】
図１０は、実施の形態２にかかる携帯端末のデータ処理手順の一例を示すフローチャート（その２）である。図１０のフローチャートにおいて、まず、スケジューラ３２０により、共用リソースＰの起動確認要求を他の携帯端末Ｎｊから受信したか否かを判断する（ステップＳ１００１）。
【０１２７】
ここで、スケジューラ３２０により、共用リソースＰの起動確認要求を受信するのを待つ（ステップＳ１００１：Ｎｏ）。そして、スケジューラ３２０により、共用リソースＰの起動確認要求を受信した場合（ステップＳ１００１：Ｙｅｓ）、共用リソースフラグテーブル６００を参照して、自端末で共用リソースＰを起動中か否かを判断する（ステップＳ１００２）。
【０１２８】
ここで、共用リソースＰを起動中の場合（ステップＳ１００２：Ｙｅｓ）、スケジューラ３２０により、共用リソースＰを起動していることを示す起動確認応答を、要求元の他の携帯端末Ｎｊ（以下、単に「クライアント」という）に送信する（ステップＳ１００３）。
【０１２９】
そして、スケジューラ３２０により、アクセス許可テーブル７００にクライアントからの共用リソースＰに対するアクセス許可を設定する（ステップＳ１００４）。つぎに、スケジューラ３２０により、クライアントとの通信が切断されたか否かを判断する（ステップＳ１００５）。
【０１３０】
ここで、クライアントとの通信が切断されていない場合（ステップＳ１００５：Ｎｏ）、スケジューラ３２０により、自端末での共用リソースＰの動作が終了したか否かを判断する（ステップＳ１００６）。ここで、共用リソースＰの動作が終了していない場合（ステップＳ１００６：Ｎｏ）、ステップＳ１００５に戻る。
【０１３１】
一方、共用リソースＰの動作が終了した場合（ステップＳ１００６：Ｙｅｓ）、スケジューラ３２０により、共用リソースフラグテーブル６００内の共用リソースＰの共用リソースフラグを「１」から「０」に変更する（ステップＳ１００７）。そして、スケジューラ３２０により、クライアントからの共用リソースＰに対するアクセス許可を解除して（ステップＳ１００８）、本フローチャートによる一連の処理を終了する。
【０１３２】
また、ステップＳ１００２において、共用リソースＰを起動していない場合（ステップＳ１００２：Ｎｏ）、スケジューラ３２０により、共用リソースＰを起動していないことを示す起動確認応答をクライアントに送信して（ステップＳ１００９）、本フローチャートによる一連の処理を終了する。
【０１３３】
また、ステップＳ１００５において、クライアントとの通信が切断された場合（ステップＳ１００５：Ｙｅｓ）、スケジューラ３２０により、クライアントからの共用リソースＰに対するアクセス許可を解除して（ステップＳ１００８）、本フローチャートによる一連の処理を終了する。
【０１３４】
これにより、自端末で起動している共用リソースＰを他の携帯端末Ｎｊと共用することができる。
【０１３５】
以上説明したように、実施の形態２にかかる携帯端末Ｎｉによれば、共用リソースＰを用いるアプリＡを実行する際に、ネットワーク２１０を介して、他の携帯端末Ｎｊで既に起動中の共用リソースＰを利用することができる。これにより、携帯端末Ｎｉで共用リソースＰを起動することなくアプリＡを実行することができ、システム全体としての消費電力を削減することができる。
【０１３６】
また、実施の形態２にかかる携帯端末Ｎｉによれば、他の携帯端末Ｎｊからの共用リソースＰの起動確認要求に対して、共用リソースＰを起動しているか否かを示す起動確認応答を要求元に送信することができる。これにより、自端末で起動している共用リソースＰを複数の携帯端末間で共用することができる。
【０１３７】
また、実施の形態２にかかる携帯端末Ｎｉによれば、共用リソースＰの起動確認要求の要求元である他の携帯端末Ｎｊについてのみ、自端末で起動中の共用リソースＰに対するアクセス許可を設定することができる。これにより、クライアント以外の他端末からの共用リソースＰに対する不正なアクセスを防ぐことができる。
【０１３８】
また、実施の形態２にかかる携帯端末Ｎｉによれば、自端末での共用リソースＰの動作が終了した場合やクライアントとの通信が切断された場合、クライアントからの共用リソースＰに対するアクセス許可を解除することができる。
【０１３９】
また、実施の形態２にかかる携帯端末Ｎｉによれば、自端末で動作している共用リソースＰの負荷が所定値Ｘ以上となった場合、他の携帯端末Ｎｊからの共用リソースＰに対するアクセス許可を解除することができる。これにより、共用リソースＰの処理待ちが発生することを防ぐことができる。
【０１４０】
また、実施の形態２にかかる携帯端末Ｎｉによれば、共用リソースＰを起動している他端末が複数存在する場合、より負荷が小さい共用リソースＰを選択して利用することにより、共用リソースＰの処理待ちが発生することを回避することができる。
【０１４１】
一例として、データ処理システム２００内の１０台の携帯端末Ｎ１〜Ｎ１０が、ＧＰＳ３０４を用いる同一または異なるアプリをそれぞれ実行する場合を例に挙げて説明する。ここで、各携帯端末ＮｉにおけるＧＰＳ３０４の消費電力を２００［ｍＷ］とし、通信Ｉ／Ｆ３０６の消費電力を５０［ｍＷ］とする。
【０１４２】
ここで、１０台の携帯端末Ｎ１〜Ｎ１０が連動して動作するような利用シーンを想定する。従来のように、すべての携帯端末Ｎ１〜Ｎ１０で１時間連続してＧＰＳ３０４を使用した場合、システム全体の消費電力は、例えば、『２０００［ｍＷｈ］＝２００［ｍＷ］×１［ｈ］×１０［台］』となる。
【０１４３】
一方、実施の形態２では、例えば、ＧＰＳ３０４を起動している１台の携帯端末Ｎｉに対して、１０台の携帯端末Ｎ１〜Ｎ１０が通信Ｉ／Ｆ３０６を介したアドホック通信を行う状態となる。この場合、システム全体の消費電力は、例えば、『７００［ｍＷｈ］＝２００［ｍＷ］×１［ｈ］×１［台］＋５０［ｍＷ］×１［ｈ］×１０［台］』となる。
【０１４４】
したがって、実施の形態２にかかるデータ処理方法によれば、すべての携帯端末Ｎ１〜Ｎ１０で１時間連続してＧＰＳ３０４を使用した場合に比べて、システム全体として１３００［ｍＷｈ］のエネルギー消費を削減することができる。
【０１４５】
このように、実施の形態２にかかるデータ処理方法およびデータ処理システムによれば、複数のデータ処理装置が、実質的に同じ周辺ユニットを用いるアプリを各々実行する際の、システム全体の消費電力を抑制してエネルギー効率を向上させることができる。
【０１４６】
（実施の形態３）
つぎに、実施の形態３にかかる携帯端末Ｎｉについて説明する。なお、実施の形態１，２で説明した箇所と同一箇所については、同一符号を付して図示および説明を省略する。
【０１４７】
ここで、各携帯端末Ｎｉで実行されるアプリケーションの中には、携帯端末Ｎ１〜Ｎｎのうち２台以上の携帯端末が同時に実行する必要性の低いものがある。例えば、携帯端末Ｎｉが道路上の渋滞情報を交通管理センタなどのサーバにアップするアプリケーションの場合、同一エリア内に存在する複数の携帯端末から収集された渋滞情報の内容はほぼ同じものとなる。このため、複数の携帯端末から収集されたほとんどの渋滞情報は、サーバ側で使用されないことになる。すなわち、このアプリケーションは、同一エリア内に存在する２台以上の携帯端末が同時に実行する必要性の低いものである。
【０１４８】
そこで、実施の形態３では、携帯端末Ｎｉで起動要求が検出されたアプリＡと同一のアプリＡが他の携帯端末Ｎｊで起動されているときは、携帯端末ＮｉでアプリＡを起動しないことにより、無駄なアプリＡの実行を抑制する場合について説明する。以下、携帯端末Ｎｉの各機能部について説明する。
【０１４９】
まず、判定部５０２は、アプリＡの起動要求が検出された場合、アプリＡが所定のグループに属するか否かを判定する。ここで、所定のグループとは、例えば、携帯端末Ｎ１〜Ｎｎのうち２台以上の携帯端末が同時に実行する必要性の低いアプリケーションの集合である。なお、所定のグループを特定する情報は、例えば、メモリ３０１に記憶されている。
【０１５０】
送信部５０３は、アプリＡが所定のグループに属すると判定された場合、アプリＡの起動確認要求を他の携帯端末Ｎｊに送信する。ここで、アプリＡの起動確認要求とは、アプリＡを起動しているか否かを他の携帯端末Ｎｊに問い合わせる情報である。
【０１５１】
受信部５０４は、アプリＡの起動確認要求が送信された結果、アプリＡの起動確認応答を他の携帯端末Ｎｊから受信する。ここで、アプリＡの起動確認応答とは、アプリＡを起動しているか否かを示す情報である。
【０１５２】
判断部５０５は、受信されたアプリＡの起動確認応答に基づいて、アプリＡが他の携帯端末Ｎｊで起動しているか否かを判断する。判断部５０５による判断処理は、例えば、アドホック通信により直接通信可能な他の携帯端末ＮｊからのアプリＡの起動確認応答に基づいて行うことにしてもよい。
【０１５３】
これにより、自端末の近傍に位置する他の携帯端末Ｎｊ、すなわち、同一エリア内に存在する可能性が高い他の携帯端末ＮｊからのアプリＡの起動確認応答に基づいて、自端末でのアプリＡの実行の要否を判断することができる。
【０１５４】
割当部５０７は、アプリＡが他の携帯端末Ｎｊで起動していないと判断された場合、アプリＡをＣＰＵ＃１〜＃ｋのいずれかのＣＰＵに割り当てる。この結果、割当先のＣＰＵのＯＳにより、アプリＡが実行される。
【０１５５】
また、割当部５０７は、アプリＡが他の携帯端末Ｎｊで起動していると判断された場合、アプリＡを割り当てない。すなわち、アプリＡは他の携帯端末Ｎｊで起動されており、携帯端末ＮｉでアプリＡを実行する必要性が低いため、携帯端末ＮｉがアプリＡを起動しない。
【０１５６】
これにより、携帯端末Ｎｉにおいて、他の携帯端末Ｎｊと同時に実行する必要性の低いアプリＡの実行を抑制して、アプリＡの実行にかかる消費電力を削減することができる。
【０１５７】
また、受信部５０４は、アプリＡの起動確認要求を他の携帯端末Ｎｊから受信する。また、判断部５０５は、アプリＡの起動確認要求が受信された場合、自端末でアプリＡを起動しているか否かを判断する。そして、送信部５０３は、自端末でアプリＡを起動しているか否かを示す起動確認応答を要求元の他の携帯端末Ｎｊに送信する。
【０１５８】
（携帯端末Ｎｉのデータ処理手順）
つぎに、実施の形態３にかかる携帯端末Ｎｉのデータ処理手順について説明する。ここでは、まず、アプリＡの起動要求を検出した場合の携帯端末Ｎｉのデータ処理手順について説明する。
【０１５９】
図１１は、実施の形態３にかかる携帯端末のデータ処理手順の一例を示すフローチャート（その１）である。図１１のフローチャートにおいて、まず、スケジューラ３２０により、アプリＡの起動要求を検出したか否かを判断する（ステップＳ１１０１）。
【０１６０】
ここで、スケジューラ３２０により、アプリＡの起動要求を検出するのを待つ（ステップＳ１１０１：Ｎｏ）。そして、スケジューラ３２０により、アプリＡの起動要求を検出した場合（ステップＳ１１０１：Ｙｅｓ）、アプリＡが所定のグループに属するか否かを判定する（ステップＳ１１０２）。
【０１６１】
ここで、所定のグループに属さない場合（ステップＳ１１０２：Ｎｏ）、ステップＳ１１０６に移行する。一方、所定のグループに属する場合（ステップＳ１１０２：Ｙｅｓ）、スケジューラ３２０により、アプリＡの起動確認要求をネットワーク２１０にブロードキャストする（ステップＳ１１０３）。
【０１６２】
つぎに、スケジューラ３２０により、他の携帯端末ＮｊからアプリＡの起動確認応答を受信したか否かを判断する（ステップＳ１１０４）。ここで、スケジューラ３２０により、アプリＡの起動確認応答を受信するのを待つ（ステップＳ１１０４：Ｎｏ）。そして、スケジューラ３２０により、アプリＡの起動確認応答を受信した場合（ステップＳ１１０４：Ｙｅｓ）、アプリＡが他の携帯端末Ｎｊで起動中か否かを判断する（ステップＳ１１０５）。
【０１６３】
そして、アプリＡが他の携帯端末Ｎｊで起動中の場合（ステップＳ１１０５：Ｙｅｓ）、本フローチャートによる一連の処理を終了する。一方、アプリＡが他の携帯端末Ｎｊで起動していない場合（ステップＳ１１０５：Ｎｏ）、スケジューラ３２０により、アプリＡをＣＰＵ＃１〜＃ｋのいずれかのＣＰＵに割り当てて（ステップＳ１１０６）、本フローチャートによる一連の処理を終了する。
【０１６４】
これにより、他の携帯端末Ｎｊと同時に実行する必要性の低いアプリＡの実行を抑制して、アプリＡの実行にかかる消費電力を削減することができる。
【０１６５】
つぎに、アプリＡの起動確認応答を受信した場合の携帯端末Ｎｉのデータ処理手順について説明する。
【０１６６】
図１２は、実施の形態３にかかる携帯端末のデータ処理手順の一例を示すフローチャート（その２）である。図１２のフローチャートにおいて、まず、スケジューラ３２０により、アプリＡの起動確認要求を他の携帯端末Ｎｊから受信したか否かを判断する（ステップＳ１２０１）。
【０１６７】
ここで、スケジューラ３２０により、アプリＡの起動確認要求を受信するのを待つ（ステップＳ１２０１：Ｎｏ）。そして、スケジューラ３２０により、アプリＡの起動確認要求を受信した場合（ステップＳ１２０１：Ｙｅｓ）、自端末でアプリＡを起動中か否かを判断する（ステップＳ１２０２）。
【０１６８】
ここで、アプリＡを起動中の場合（ステップＳ１２０２：Ｙｅｓ）、スケジューラ３２０により、アプリＡを起動していることを示す起動確認応答を、要求元の他の携帯端末Ｎｊに送信して（ステップＳ１２０３）、本フローチャートによる一連の処理を終了する。
【０１６９】
一方、アプリＡを起動していない場合（ステップＳ１２０２：Ｎｏ）、スケジューラ３２０により、アプリＡを起動していないことを示す起動確認応答を、要求元の他の携帯端末Ｎｊに送信して（ステップＳ１２０４）、本フローチャートによる一連の処理を終了する。これにより、他の携帯端末Ｎｊに対してアプリＡを起動しているか否かを応答することができる。
【０１７０】
（システムの適用例）
図１３は、本実施の形態にかかるコンピュータを用いたシステムの適用例を示す説明図である。図１３において、ネットワークＮＷは、サーバ１３０１，１３０２とクライアント１３３１〜１３３４とが通信可能なネットワークであり、例えば、ＬＡＮ、ＷＡＮ、インターネット、携帯電話網などで構成される。
【０１７１】
サーバ１３０２は、クラウド１３２０を構成するサーバ群（サーバ１３２１〜１３２５）の管理サーバである。クライアント１３３１〜１３３４のうち、クライアント１３３１はノート型パソコン、クライアント１３３２はデスクトップ型パソコン、クライアント１３３３は携帯電話機（スマートフォン、ＰＨＳ（Ｐｅｒｓｏｎａｌ  Ｈａｎｄｙｐｈｏｎｅ  Ｓｙｓｔｅｍ）でもよい）、クライアント１３３４はタブレット型端末である。
【０１７２】
図１３のサーバ１３０１，１３０２，１３２１〜１３２５、クライアント１３３１〜１３３４は、例えば、実施の形態１で説明したデータ処理装置１０１，１０２、または、実施の形態２で説明した携帯端末Ｎｉと同様の機能を有するコンピュータにより実現される。
【０１７３】
なお、本実施の形態で説明したデータ処理方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本データ処理プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、本データ処理プログラムは、インターネット等のネットワークを介して配布してもよい。
【符号の説明】
【０１７４】
１０１，１０２  データ処理装置
２００  データ処理システム
Ｎ１〜Ｎｎ，Ｎｉ，Ｎｊ  携帯端末
５０１  検出部
５０２  判定部
５０３  送信部
５０４  受信部
５０５  判断部
５０６  切替部
５０７  割当部
５０８  設定部
【図１】
2013005323.tif 000003
【図２】
2013005323.tif 000004
【図３】
2013005323.tif 000005
【図４】
2013005323.tif 000006
【図５】
2013005323.tif 000007
【図６】
2013005323.tif 000008
【図７】
2013005323.tif 000009
【図８】
2013005323.tif 000010
【図９】
2013005323.tif 000011
【図１０】
2013005323.tif 000012
【図１１】
2013005323.tif 000013
【図１２】
2013005323.tif 000014
【図１３】
2013005323.tif 000015
【国際調査報告】
2013005323.tif 000016
2013005323.tif 000017
2013005323.tif 000018
2013005323.tif 000019