JP5904018B2 - 情報処理装置、情報処理方法、並びにプログラム - Google Patents

Description

本技術は、情報処理装置、情報処理方法、並びにプログラムに関する。詳しくは、複数のアプリケーションフレームワークを切り替えた処理を行うことができる情報処理装置、情報処理方法、並びにプログラムに関する。

アプリケーションフレームワーク（Application Framework）は、アプリケーションの開発に便利な機能を提供するミドルウェア群であり、１つのシステム上に、１つのアプリケーションフレームワークが存在し、動作することを前提に設計されている。従って１つのシステム上で複数のアプリケーションフレームワークを利用したい場合、装置の電源を一旦オフにし、再度オンにすることでアプリケーションフレームワークを切り替えるか、別プロセッサ及びハードウェアを用意し、それらを切り替えることでアプリケーションフレームワークを切り替えるか、または仮想マシンを利用する等の方法でアプリケーションフレームワークを切り替える必要があった。

特許文献１には、拡張性の高い電子機器を提供するとの課題をあげ、システムを拡張する時の困難さをとりのぞくために、実行中のアプリケーションの遷移を単位として、デバイスの排他制御設定の変更を管理することが記載されている。

特開2008-210398号公報

１つのシステム上に、１つのアプリケーションフレームワークが存在し、そのアプリケーションフレームワーク上でアプリケーションを動作させる場合、アプリケーションを、アプリケーションフレームワークに合わせ込んで設計する必要があった。このため、アプリケーションによっては、アプリケーションフレームワークに合わせ込むことが困難で、アプリケーションの開発や、動作確認などに時間やコストがかかってしまう。

本技術は、このような状況に鑑みてなされたものであり、複数のアプリケーションフレームワークを切り替え、各アプリケーションフレームワーク上で動作する複数のアプリケーションを利用できるようにするものである。

本技術の一側面の情報処理装置は、複数のアプリケーションフレームワークと、前記アプリケーションフレームワークを切り替える切り替え部とを備え、前記複数のアプリケーションフレームワークのうちの第１のアプリケーションフレームワークと、前記第１のアプリケーションフレームワーク上で動作する第１のアプリケーションと、前記第１のアプリケーションフレームワークとは異なる第２のアプリケーションフレームワークと、前記第２のアプリケーションフレームワーク上で動作する第２のアプリケーションとを備え、前記切り替え部は、前記第１のアプリケーションから、前記第２のアプリケーションフレームワークに切り替えが指示されたとき、前記第１のアプリケーションフレームワークから前記第２のアプリケーションフレームワークに、デバイスとの入出力先を切り替える。

前記切り替え部は、前記複数のアプリケーションフレームワークと前記デバイスを１対１に接続されるように切り換えを行うようにすることができる。

前記切り替え部は、複数のアプリケーションのうちの所定のアプリケーションを不活性化し、他のアプリケーションを活性化する機能を担う部分と、前記複数のアプリケーションフレームワークのうちの所定のアプリケーションフレームワークをデバイスと切り離し、他のアプリケーションフレームワークと接続する機能を担う部分をそれぞれ有するようにすることができる。

前記切り替え部は、前記第１のアプリケーションから、前記第２のアプリケーションフレームワークに切り替えが指示されたとき、前記第１のアプリケーションを不活性化し、前記第２のアプリケーションを活性化するようにすることができる。

前記第１のアプリケーションは複数あり、前記切り替え部は、複数の前記第１のアプリケーションの１アプリケーションとして存在し、前記第１のアプリケーションとしての前記切り替え部は、前記デバイスからの入力を前記第２のアプリケーションフレームワークに転送するようにすることができる。

前記切り替え部は、前記第１のアプリケーションフレームワークの１機能として存在し、前記第１のアプリケーションフレームワークに含まれる前記切り替え部は、前記デバイスからの入力を、前記第２のアプリケーションフレームワークに転送するようにすることができる。

前記デバイスからの入力は、オペレーティングシステムに含まれる入力供給機能により、前記第１のアプリケーションまたは前記第１のアプリケーションフレームワークから、前記第２のアプリケーションフレームワークに供給されるようにすることができる。

前記入力供給機能は、uinputの機能であるようにすることができる。

前記第２のアプリケーションからの出力データは、前記第２のアプリケーションフレームワークを介して、記憶部に記憶され、前記記憶部に記憶された前記出力データは、前記第１のアプリケーションにより読み出され、前記第１のアプリケーションフレームワークを介して、前記デバイスに供給されるようにすることができる。

前記第２のアプリケーションが描画した描画データが、前記記憶部に前記第２のアプリケーションフレームワークを介して記憶され、前記記憶部に記憶された前記描画データが、前記第１のアプリケーションより読み出され、前記第１のアプリケーションフレームワークを介して、ディスプレイに供給されるようにすることができる。

前記第１のアプリケーションフレームワークは、カメラ機能に関するアプリケーションフレームワークであり、前記第２のアプリケーションフレームワークは、通信機能に関するアプリケーションフレームワークであるようにすることができる。

前記カメラ機能に関する前記第１のアプリケーションフレームワーク上で動作する前記第１のアプリケーションの処理により、ユーザからの入力操作に従って撮影された画像を、前記通信機能に関する第２のアプリケーションフレームワーク上で動作する前記第２のアプリケーションの処理により、他の装置に送信するようにすることができる。

本技術の一側面の情報処理方法は、複数のアプリケーションフレームワークのうちの第１のアプリケーションフレームワークと、前記第１のアプリケーションフレームワーク上で動作する第１のアプリケーションと、前記第１のアプリケーションフレームワークとは異なる第２のアプリケーションフレームワークと、前記第２のアプリケーションフレームワーク上で動作する第２のアプリケーションとを備える情報処理装置の情報処理方法において、前記第１のアプリケーションから、前記第２のアプリケーションフレームワークに切り替えが指示されたとき、前記第１のアプリケーションフレームワークから前記第２のアプリケーションフレームワークに、デバイスとの入出力先を切り替えるステップを含む。

本技術の一側面のプログラムは、複数のアプリケーションフレームワークのうちの第１のアプリケーションフレームワークと、前記第１のアプリケーションフレームワーク上で動作する第１のアプリケーションと、前記第１のアプリケーションフレームワークとは異なる第２のアプリケーションフレームワークと、前記第２のアプリケーションフレームワーク上で動作する第２のアプリケーションとを備える情報処理装置を制御するコンピュータに、前記第１のアプリケーションから、前記第２のアプリケーションフレームワークに切り替えが指示されたとき、前記第１のアプリケーションフレームワークから前記第２のアプリケーションフレームワークに、デバイスとの入出力先を切り替えるステップを含む処理を実行させる。

本技術の一側面の情報処理装置、情報処理方法、並びにプログラムにおいては、複数のアプリケーションフレームワークが備えられ、それらの複数のアプリケーションフレームワークが選択的に切り替えられる。

本技術の一側面によれば、複数のアプリケーションフレームワークを切り替えることが可能となる。また複数のアプリケーションフレームワークを切り替えることで、各アプリケーションフレームワーク上で動作する複数のアプリケーションを利用できるようになる。

情報処理装置の構成を示す図である。 アプリケーションフレームワークについて説明するための図である。 アプリケーションフレームワークについて説明するための図である。 アプリケーションフレームワークの接続について説明するための図である。 アプリケーションフレームワークに関する構成について説明するための図である。 アプリケーションフレームワークの切り替えについて説明するための図である。 アプリケーションフレームワークの切り替えについて説明するための図である。 アプリケーションフレームワークの切り替えについて説明するための図である。 アプリケーションフレームワークの切り替えについて説明するための図である。 アプリケーションフレームワークの切り替えについて説明するための図である。 アプリケーションフレームワークの切り替えについて説明するための図である。 アプリケーションフレームワークの切り替えについて説明するための図である。 入力時の処理について説明するための図である。 入力時の処理について説明するための図である。 入力時の処理について説明するための図である。 入力時の処理について説明するための図である。 入力時の処理について説明するための図である。 出力時の処理について説明するための図である。 出力時の処理について説明するための図である。

以下に、本技術を実施するための形態（以下、実施の形態という）について説明する。なお、説明は、以下の順序で行う。
１．情報処理装置の構成について
２．ソフトウェアスタック
３．複数のアプリケーションフレームワークの切り替えについて
４．排他制御について
５．インタフェースについて
６．アービタコアのアプリケーションフレームワークの切り替え処理について
７．アプリケーションの切り替えについて
８．アービタの構成について
９．起動時の処理について
１０．アプリケーションフレームワークの切り替えの処理について
１１．アプリケーションフレームワークの切り替え後の入力に関わる処理について
１２．入力に関わる他の処理について
１３．出力に関わる処理について
１４．記録媒体について

［情報処理装置の構成について］
図１は、情報処理装置の構成を示す図である。ここでは情報処理装置１０を例にあげて説明するが、情報処理装置１０は、例えば、パーソナルコンピュータなどである。また情報処理装置１０は、デジタルカメラなどの撮影装置や、テレビジョン受像機などの再生装置の一部分を構成し、組み込まれている装置とすることも可能である。

ＣＰＵ（Central Processing Unit）２１は、入出力インタフェース２５および内部バス２４を介して、情報処理装置１０のユーザが、入力部２６を用いて入力した各種指令に対応する信号を受け、入力された信号に基づいた各種処理を実行する。

ＲＯＭ（Read Only Memory）２２は、ＣＰＵ２１が使用するプログラムや演算用のパラメータのうちの基本的に固定のデータを格納する。ＲＡＭ（Random Access Memory）２３は、ＣＰＵ２１の実行において使用するプログラムやデータ、その実行において適宜変化するパラメータなどを格納する。ＣＰＵ２１、ＲＯＭ２２、およびＲＡＭ２３は、内部バス２４により相互に接続されている。

内部バス２４は、入出力インタフェース２５とも接続されている。入力部２６は、例えば、キーボード、タッチパッド、ジョグダイヤル、ペンタブレット、あるいはマウスなどからなり、情報処理装置１０のユーザがＣＰＵ２１に各種の指令を入力するとき操作される。出力部２７は、例えば、液晶表示部などのディスプレイで構成され、各種情報をテキスト、あるいはイメージなどで表示する。

記憶部２８は、ＨＤＤ（hard disk drive）などの記憶装置を含む構成とされ、ＣＰＵ２１によって実行されるプログラムや情報が記録または再生される。通信部２９は、有線、あるいは、無線を介して、他の装置などと接続され、情報の授受を行う。ドライブ３０には、必要に応じて磁気ディスク、光ディスク、光磁気ディスク、半導体メモリなどのリムーバブルメディア３１が装着され、データの授受を行う。

これらの入力部２６乃至ドライブ３０は、入出力インタフェース２５および内部バス２４を介してＣＰＵ２１に接続されている。

［ソフトウェアスタック］
次に、本実施の形態の動作環境について説明する。図２を用いて、図１を用いて説明した情報処理装置１０のＣＰＵ２１により実行されるソフトウェアプログラムにおけるソフトウェアスタックについて説明する。図中、より上方に示されるモジュールは、下方に示されるモジュールより上位の階層のものとされる。

図２に示したソフトウェアスタックは、デバイス（Device）１１−１乃至１１−Ｍ、デバイスドライバ（Device Driver）１２−１乃至１２−Ｍ、オペレーティングシステム（Operation System）１３、アプリケーションフレームワーク(Application Framework)１４、およびアプリケーション(Application)１５−１乃至１５−Ｎが含まれている。

デバイス１１−１乃至１１−Ｍは、例えば、入力部２６を構成するキーボードやマウスなどや、出力部２７を構成するディスプレイなどのハードウェアである。デバイスドライバ１２−１乃至１２−Ｍは、デバイス１１−１乃至１１−Ｍを動作させるのに必要なソフトウェアであり、ここではオペレーティングシステム１３に同梱されているとして説明を続ける。また、デバイス１１−１乃至１１−Ｍやデバイスドライバ１２−１乃至１２−Ｍを個々に区別する必要がない場合、単に、デバイス１１、デバイスドライバ１２と記述する。他の記載も同様とする。

オペレーティングシステム１３は、例えば、入力部２６や出力部２７を構成するマウス、キーボード、ディスプレイなどの周辺機器を動作させるためのソフトウェアであるデバイスドライバ１２の管理や、各種の情報を記録する記憶部２８の管理など、多くのアプリケーション１５から共通して利用される基本的な機能を提供し、コンピュータシステム全体を管理するソフトウェアである。

アプリケーションフレームワーク１４は、プログラミングにおいて、特定のオペレーティングシステムのためのアプリケーションの標準構造を実装するのに使われるクラスやライブラリの集まりである。アプリケーションフレームワーク１４は、プラットフォームやアプリケーションの種類ごとに共通して必要とされるコードが予め用意されているため、アプリケーションを開発する際、固有の機能をフレームワークにはめ込んで実装していくだけで目的のアプリケーションを開発することができる。

図２に示すように、１つのシステムには、１つのアプリケーションフレームワーク１４が存在し、そのアプリケーションフレームワーク１４に合わせ込まれたアプリケーション１５−１乃至１５−Ｎが存在している。アプリケーションフレームワーク１４は、デバイス１１をカプセル化し、アプリケーション１５に対してデバイスを抽象化し、通常は１つのシステム上に１つのアプリケーションフレームワーク１４しか搭載されない。

アプリケーションフレームワーク１４に適したアプリケーション１５であれば、アプリケーションフレームワーク１４に合わせ込んだ開発を行うことで、時間やコストを低減することができる。このことは、一方で、アプリケーションを開発する際、固有の機能をフレームワークにはめ込んで実装しなくては、目的のアプリケーションを開発することができないことを意味する。またこのことは、アプリケーションフレームワーク１４に適していないアプリケーション１５であると、アプリケーションフレームワーク１４に合わせ込んだ開発を行うことで、時間やコストの点で無駄が生じる可能性がある。

そこで１つのシステム内に、複数のアプリケーションフレームワーク１４を備え、それぞれのアプリケーションフレームワーク１４に適したアプリケーション１５を開発し、実装することができるようにすると、新たなアプリケーションの追加（機能の追加）などが容易になる。また複数のアプリケーションフレームワーク１４を切り替えることで、それらのアプリケーションフレームワーク１４上に位置する複数のアプリケーション１５を選択的に利用することができるようになり、機能の充実などに役立つ。

そこで、１つのシステム内に複数のアプリケーションフレームワーク１４が搭載され、それらの複数のアプリケーションフレームワーク１４が選択的に切り替えられ、切り替えられたアプリケーションフレームワーク１４上に位置するアプリケーション１５を利用できるようにした場合のソフトウェアスタックの構成について説明する。

［複数のアプリケーションフレームワークの切り替えについて］
図３は、複数のアプリケーションフレームワーク１４が１つのシステム内に搭載されている場合のソフトウェアスタックの構成を示す図である。図３に示したソフトウェアスタックには、アービタ（Arbiter）１０１、アプリケーションフレームワーク１２１、アプリケーション１２２−１乃至１２２−Ｎ、アプリケーションフレームワーク１３１、アプリケーション１３２−１乃至１３２−Ｎ、アプリケーションフレームワーク１４１、アプリケーション１４２−１乃至１４２−Ｎが搭載されている。

アービタ１０１は、アービタコア（Arbiter Core）１０２、プロセススイッチ（Process Switch）１０３、およびデバイスサーバ（Device Server）１０４を含む。デバイスサーバ１０４は、複数のデバイスドライバを管理し、図３に示した例では、グラフィックサーバ１１１、インプットサーバ１１２、サウンドサーバ１１３などが管理されている。

なお、図３に示した構成においては、図２に示したデバイス１１、オペレーティングシステム１３は図示を省略してある。

アプリケーション１２２−１乃至１２２−Ｎは、アプリケーションフレームワーク１２１に合わせ込まれたアプリケーションである。同様に、アプリケーション１３２−１乃至１３２−Ｎは、アプリケーションフレームワーク１３１に合わせ込まれたアプリケーションであり、アプリケーション１４２−１乃至１４２−Ｎは、アプリケーションフレームワーク１４１に合わせ込まれたアプリケーションである。

なおここでは、アプリケーション１２２、アプリケーション１３２、アプリケーション１４２は、それぞれＮ個あるとして図示したが、異なる個数であっても良い。また、図３においては、アプリケーションフレームワーク１２１、アプリケーションフレームワーク１３１、およびアプリケーションフレームワーク１４１の３個のアプリケーションフレームワークを図示し、以下の説明を続けるが、３個に限定されることを示す記載ではなく、他の個数であっても勿論良い。

図３に示した実施の形態のように、アプリケーションフレームワーク１２１，１３１，１４１を共存させることにより、それらのアプリケーションフレームワークに依存したアプリケーション１２２，１３２，１４２を１つのシステム内で動作できるようになる。また、そのようなことを可能とするために、アービタ１０１を設ける。以下の説明において、アプリケーションフレームワーク１２１，１３１，１４１のいずれかが対象とされている場合、アプリケーションフレームワークと記載する。また、アプリケーション１２２−１乃至１２２−Ｎ，１３２−１乃至１３２−Ｎ，１４２−１乃至１４２−Ｎのいずれかが対象とされている場合、アプリケーションと記載する。

アプリケーションフレームワーク１２１は、例えば、従来からあるカメラアプリケーションを動かすための、カメラ機能に特化したフレームワークである。カメラ機能とは、例えば、静止画像の撮影や再生、動画像の撮影や再生、ズーム、オートフォーカス機能などの機能のことである。

アプリケーションフレームワーク１２１は、このようなカメラ機能に特化したフレームワークであり、デジタルカメラのアプリケーションを開発するのに必要な機能を備えている。アプリケーション１２２は、このようなアプリケーションフレームワーク１２１の機能に特化したアプリケーションであり、カメラ機能を実現するためのアプリケーションである。

しかしながら、アプリケーションフレームワーク１２１は、例えば、ネットワークでの通信機能は有しておらず、そのような通信機能は、アプリケーションフレームワーク１３１などの、アプリケーションフレームワーク１２１とは異なるアプリケーションフレームワークが有する。ここでは、アプリケーションフレームワーク１３１が、ネットワークを介した通信を行う機能を有するとする。

アプリケーションフレームワーク１３１は、スマートフォンなどで用いられる通信機能が充実したアプリケーションフレームワークであり、インターネット上のホームページの閲覧や、クラウドへのアップロードなどの機能を有する。

このアプリケーションフレームワーク１３１上のアプリケーション１３２は、撮影画像をネットワークにアップロードするといったアプリケーションとすることができ、そのようなアプリケーション１３２を、アプリケーションフレームワーク１３１を用いて開発することは比較的容易である。

アプリケーションフレームワーク１３１は、アプリケーションフレームワーク１２１がデジタルカメラの撮影などに関する機能を有しているため、そのようなカメラ機能に関する機能を有する必要がなく、ネットワーク機能が充実されたアプリケーションフレームワーク１３１とすることが可能である。

このような異なる機能を有するアプリケーションフレームワークを、ある瞬間にシステム上で動作しているアプリケーションフレームワークを、他のアプリケーションフレームワークに切り替えるといったことができるようにする。例えば、ある瞬間ではアプリケーションフレームワーク１２１が有効であり、その間は アプリケーションフレームワーク１２１を用いたアプリケーション１２２が動作可能な状態にある(動作している)。そして、別の瞬間では アプリケーションフレームワーク１３１が動作可能な状態にある。このようなアプリケーションフレームワークの切り替えの制御をアービタ１０１が行う。このような切り替えは、アプリケーション側からの指示により行われる。

アービタ１０１のアービタコア１０２は、起動されているアプリケーションの指示に基づき、どのアプリケーションフレームワークを有効にするかを決定し、その決定に基づくアプリケーションフレームワークへの切り替えと、そのアプリケーションフレームワーク上で動作するアプリケーションへの切り替えを制御する。

アービタコア１０２は、動作中のアプリケーションフレームワークに休止を指示し、有効にするアプリケーションフレームワークに開始を指示し、デバイスサーバ１０４にシステム資源を使用するアプリケーションフレームワークを通知するといった一連の処理を行う。

デバイスサーバ１０４は、各アプリケーションフレームワークが利用するデバイスについて、切り替え要求に応じてどのシステムとデバイスを接続するかの排他処理を行う。この排他処理については、図４を参照して説明する。また、図５を参照して説明するように、アプリケーションフレームワークとシステム資源(ハードウェアのデバイス等)とのインタフェースも担う。

またデバイスサーバ１０４は、現在どのアプリケーションフレームワークが有効かの情報を持ち、入力デバイスの情報を現在有効なアプリケーションフレームワークへ配信し、出力デバイスの情報は、現在有効なアプリケーションフレームワークからの情報のみ出力するといった機能も有する。

また図６を参照して説明するように、アービタコア１０２は、アービタ１０１の中で、アプリケーションからの要求を基に、プロセススイッチ１０３とデバイスサーバ１０４を呼び出し、アプリケーションフレームワークの切り替えを行うモジュールでもある。

プロセススイッチ１０３は、図７を参照して説明するように、それぞれのアプリケーションフレームワークのアプリケーションを実行するためのプロセスを活性化・不活性化し、アプリケーションの実行主体を切り替えるモジュールである。

なおここでは、アービタ１０１が、アービタコア１０２、プロセススイッチ１０３、およびデバイスサーバ１０４から構成されるとして説明を続ける。しかしながら、アービタ１０１が、複数のアプリケーションフレームワークを、選択的に切り替えるための制御を行う構成であれば良く、図３に示すようにアービタコア１０２、プロセススイッチ１０３、およびデバイスサーバ１０４がそれぞれ独立して存在している構成に限定されるものではない。

［排他制御について］
まず、図４を参照し、デバイスサーバ１０４が行う、切り替え要求に応じてどのシステムとデバイスを接続するかの排他処理について説明する。デバイス、例えば、キーボードなどのデバイスは、通常、システム内に１つ存在するため、２つのアプリケーションフレームワークが同時に利用することはできない構成とされている。よって、１つのデバイスを２以上のアプリケーションフレームワークが同時に利用するようなことがないように、１つのデバイスに１つのアプリケーションフレームワークが接続されるような排他処理が行われる必要がある。

図４Ａに示したように、アプリケーションフレームワーク１２１がインプットサーバ１１２に接続され、アプリケーションフレームワーク１４１がグラフィックサーバ１１１に接続されている状態を想定する。

なお、グラフィックサーバ１１１やインプットサーバ１１２は、アプリケーションフレームワーク１２１をクライアントとして捉えたときに、サーバとしての役割を果たすため、サーバとの名称を付けている。例えば、サーバとしてのグラフィックサーバ１１１は、後述するように、グラフィックデバイスドライバ１６１へのデータの供給を行うインタフェースの機能を有し、クライアントとしてのアプリケーションフレームワーク１２１は、グラフィックサーバ１１１の機能によりグラフィックデバイスドライバ１６１にデータを供給することができるように構成されている。

このようなサーバとクライアントの関係があるため、ここでは、グラフィックサーバ１１１やインプットサーバ１１２といったように、サーバとの記載を行う。

図４Ａに示したような状況の場合、アプリケーションフレームワーク１２１とインプットサーバ１１２が１対１で接続され、アプリケーションフレームワーク１４１とグラフィックサーバ１１１が１対１で接続されている状態であるため、排他制御が正常に行われている状態である。

同様に、図４Ｂに示したように、アプリケーションフレームワーク１３１がグラフィックサーバ１１１に接続され、アプリケーションフレームワーク１４１がインプットサーバ１１２に接続されている状態を想定する。この場合、アプリケーションフレームワーク１３１とグラフィックサーバ１１１が１対１で接続され、アプリケーションフレームワーク１４１とインプットサーバ１１２が１対１で接続されている状態であるため、排他制御が正常に行われている状態である。

このように、アプリケーションフレームワークとデバイスサーバ１０４内のデバイスサーバは、１対１で接続されるように、デバイスサーバ１０４は、排他制御を行う。

［インタフェースについて］
次に、図５を参照し、アプリケーションフレームワークとシステム資源とのインタフェースについて説明する。図５に示すように、デバイスサーバ１０４内のグラフィックサーバ１１１とグラフィックデバイスドライバ１６１との間は、グラフィックデバイスインタフェース１５１によりデータのやり取りが仲介される。グラフィックデバイスドライバ１６１は、ディスプレイ１７１へのデータの出力を制御するドライバである。

デバイスサーバ１０４内のインプットサーバ１１２とインプットデバイスドライバ１６２との間は、インプットデバイスインタフェース１５２によりデータのやり取りが仲介される。インプットデバイスドライバ１６２は、キーボード１７２やマウス１７３からの入力を制御するドライバである。図示はしていないが、サウンドサーバ１１３もインタフェースを介してドライバとのデータのやり取りを行う。

アプリケーションフレームワークは、デバイスサーバ１０４内のグラフィックサーバ１１１やインプットサーバ１１２を、グラフィックデバイスドライバ１６１やインプットデバイスドライバ１６２のインタフェースとして用いる。すなわち、デバイスサーバ１０４は、インタフェースの機能を含むものとされ、ドライバとアプリケーションフレームワークを対応付ける機能を有する。

［アービタコアのアプリケーションフレームワークの切り替え処理について］
次に、図６を参照し、アービタコア１０２によるアプリケーションフレームワークの切り替えについて説明する。図６Ａは、ある時点における接続状態を示す。アプリケーションフレームワーク１２１とグラフィックサーバ１１１、アプリケーションフレームワーク１２１とインプットサーバ１１２が接続されている。このような状態のときに、アプリケーション１２２から、アービタコア１０２に対して、アプリケーションフレームワーク１３１への切り替えが指示される。

このような指示を受け取ったアービタコア１０２は、次の時点において、デバイスサーバ１０４に対して、アプリケーションフレームワーク１３１へ切り替えろという指示を出す。デバイスサーバ１０４は、アービタコア１０２からの指示を受け取ると、その指示に基づき、グラフィックサーバ１１１とインプットサーバ１１２の接続先を、アプリケーションフレームワーク１２１からアプリケーションフレームワーク１３１に切り替える。

このように、アプリケーションからの指示により、アービタコア１０２は、アプリケーションフレームワークを切り替えの指示を、デバイスサーバ１０４に出し、デバイスサーバ１０４は、アービタコア１０２からの指示に基づき、接続先のアプリケーションフレームワークの切り替えを行う。

［アプリケーションの切り替えについて］
このようなアプリケーションフレームワークの切り替えが行われるととともに、切り替え先のアプリケーションにより処理が開始されるように、アプリケーションの切り替えも行われる必要がある。図７を参照し、アプリケーションの切り替えについて説明する。

図７Ａに示した状態は、アプリケーションフレームワーク１２１が動作し、アプリケーションフレームワーク１２１上のアプリケーション１２２が動作している状態である。このような状態のときに、アプリケーション１２２から、アービタコア１０２に、アプリケーションフレームワーク１３１に切り替えの指示が出される。

アービタコア１０２は、アプリケーション１２２からの指示を受け取ると、その指示に基づき、プロセススイッチ１０３に、アプリケーション１３２に切り替えろという指示を出す。プロセススイッチ１０３は、アービタコア１０２からの指示を受け取った時点で動作しているアプリケーションを認識しており、その認識しているアプリケーションに対して動作を停止するように指示を出す。この場合、プロセススイッチ１０３は、アプリケーション１２２に対して動作を停止するように指示を出す。アプリケーション１２２は、その指示に基づき、動作を停止する。

一方でプロセススイッチ１０３は、アプリケーション１３２に対して、動作を開始するように指示を出す。アプリケーション１３２は、その指示に基づき、動作を開始する。

このように、プロセススイッチ１０３により、アプリケーションが切り替えられる。また、プロセススイッチ１０３に対するアプリケーションの切り替えの指示は、アービタコア１０２から出される。アービタコア１０２は、上記したように、デバイスサーバ１０４に対して、接続先のアプリケーションフレームワークの切り替えも指示する。

このようにして、アービタコア１０２の指示に基づき、プロセススイッチ１０３がアプリケーションを切り替え、デバイスサーバ１０４がアプリケーションフレームワークを切り替えることで、アプリケーションフレームワークの切り替えが可能となり、アプリケーションフレームワーク上で動作するアプリケーションの切り替えが可能となる。

［アービタの構成について］
図８、図９にアービタ１０１の構成と、アービタ１０１と他のサブシステムとの関係について説明する。図８、図９を参照するに、アービタ１０１のアービタコア１０２は、アプリケーション１２２やアプリケーション１３２からの指示を受け付けられる構造とされている。また、アービタコア１０２は、プロセススイッチ１０３に対して指示を出せるように接続されているとともに、デバイスサーバ１０４内の各デバイスサーバとも接続されている。

図９に示すようにデバイスサーバ１０４は、スイッチで構成することができる。図９に示した例では、インプットデバイスドライバ１６２と、アプリケーションフレームワーク１２１またはアプリケーションフレームワーク１３１との接続の切り替えを実行するスイッチを図示している。図示はしていないが、デバイスサーバ１０４内には、グラフィックデバイスドライバ１６１と、アプリケーションフレームワーク１２１またはアプリケーションフレームワーク１３１との接続の切り替えを実行するスイッチなども含まれている。

このように各デバイスドライバとアプリケーションフレームワークとの接続を切り替える複数のスイッチから、デバイスサーバ１０４が構成されていても良い。

［起動時の処理について］
次に、図１０のシーケンス図を参照し、図３乃至図９を参照して説明したアプリケーションフレームワークの切り替えを行えるソフトウェアスタックを有するシステム（または装置）において、起動時に実行される処理について説明する。

例えば、図１に示した情報処理装置１０の電源がオンにされたととき、ＣＰＵ２１から、アービタコア１０２などに対して、初期化の命令が出される。ステップＳ１１において、アービタコア１０２は、初期化の処理を行う。

ステップＳ５１において、グラフィックサーバ１１１も初期化の処理を行い、初期化終了後、アービタコア１０２に対して初期化終了の通知を出す。その通知を、アービタコア１０２は、ステップＳ１２において受信する。

同様に、ステップＳ７１において、インプットサーバ１１２も初期化の処理を行い、初期化終了後、アービタコア１０２に対して初期化終了の通知を出す。その通知を、アービタコア１０２は、ステップＳ１３において受信する。このような処理は、デバイスサーバ１０４内の各デバイスサーバにおいて実行される。図１０および以下の説明においては、グラフィックサーバ１１１とインプットサーバ１１２を例にあげて説明する。

同様に、ステップＳ９１において、プロセススイッチ１０３も初期化の処理を行い、初期化終了後、アービタコア１０２に対して初期化終了の通知を出す。その通知を、アービタコア１０２は、ステップＳ１４において受信する。このように、アービタコア１０２は、初期化終了の通知を受け取ることで、デバイスサーバ１０４内のデバイスサーバの状態と、プロセススイッチ１０３の状態を認識する。

ここではＣＰＵ２１により、アプリケーション１３２の起動が指示された場合を例にあげて説明する。このような場合、アプリケーションフレームワーク１３１とアプリケーション１３２が起動される。アプリケーション１３２が起動されると、ステップＳ１０１において、アプリケーション１３２からアービタコア１０２に対してデバイスとの接続要求が出される。

アービタコア１０２は、アプリケーション１３１からの要求をステップＳ１５において受け取ると、アービタコア１０２とグラフィックサーバ１１１との間でコールバック（callback）の処理が実行される（ステップＳ１６、ステップＳ５２）。また、アービタコア１０２とインプットサーバ１１２との間でもコールバック（callback）の処理が実行される（ステップＳ１７、ステップＳ７２）。

図６を参照して説明したように、デバイスサーバ１０４の排他制御により、アプリケーションフレームワークとデバイスサーバ（特定のデバイス）が１対１で接続される。この場合、グラフィックサーバ１１１とインプットサーバ１１２は、それぞれアプリケーションフレームワーク１３１と接続される。このような接続が完了すると、その通知が、グラフィックサーバ１１１とインプットサーバ１１２からそれぞれ出される（ステップＳ５３、ステップＳ７３）。

アービタコア１０２は、グラフィックサーバ１１１とインプットサーバ１１２とからの通知を、ステップＳ１８、ステップＳ１９において受け取る。ステップＳ２０において、デバイスとの接続が完了したことを示す通知が、アプリケーションフレームワーク１３１（アプリケーション１３２）に出され、ステップＳ１０２において、アプリケーション１３２に受信される。このような接続が完了すると、アプリケーション１３２による処理が開始される。

［アプリケーションフレームワークの切り替えの処理について］
図１１を参照し、アプリケーションフレームワークの切り替えについて説明する。ここでは、アプリケーションフレームワーク１３１とアプリケーション１３２が起動されている状態であり、アプリケーションフレームワーク１２１に切り替えが行われる場合を例にあげて説明する。

ステップＳ２０１において、アプリケーション１３２からアービタコア１０２に対してアプリケーションフレームワーク１２１への切り替え要求が出される。そのような要求をステップＳ２２１において受け取ったアービタコア１０２は、ステップＳ２２２において、コールバックの処理をグラフィックサーバ１１１と行う。グラフィックサーバ１１１は、ステップＳ２４１の処理として、アービタコア１０２とのコールバックの処理を行う。

同様に、アービタコア１０２は、ステップＳ２２３において、コールバックの処理をインプットサーバ１１２と行う。インプットサーバ１１２は、ステップＳ２６１の処理として、アービタコア１０２とのコールバックの処理を行う。

ここで行われるコールバックの処理は、アプリケーションフレームワーク１３１との接続を解除するための処理である。そのような接続の解除が行われた場合、グラフィックサーバ１１１とインプットサーバ１１２からそれぞれ、接続の解除が終了したことを示す通知が出される（ステップＳ２４２、ステップＳ２６２）。

アービタコア１０２は、ステップＳ２２４とステップＳ２２５において、グラフィックサーバ１１１とインプットサーバ１１２からの通知を受信すると、ステップＳ２２６において、アプリケーションフレームワーク１３１に対して、デバイスとの接続が解除されたことをアプリケーションフレームワーク１３１に対して通知する。アプリケーションフレームワーク１３１は、ステップＳ２０２において、そのような通知を受信し、デバイスサーバとの接続が解除されたことを認識する。

アービタコア１０２は、このような通知をアプリケーションフレームワーク１３１に出す一方で、ステップＳ２２７において、プロセススイッチ１０３に対して、アプリケーション１３２からアプリケーション１２２に切り替えるように指示を出す。

ステップＳ２８１において、アービタコア１０２からの指示を受け取ったプロセススイッチ１０３は、ステップＳ２８２において、アプリケーション１３２に対して、動作の停止を指示する（アプリケーションフレームワーク１３１の不活性化の処理が実行される）。

またステップＳ２８３において、プロセススイッチ１０３は、アプリケーション１２２に対して動作の開始を指示する（アプリケーションフレームワーク１２１の活性化の処理が実行される）。このようにして、アプリケーションの切り替えが行われる。この場合、アプリケーション１３２からアプリケーション１２２への切り替えが行われる。

このようなプロセススイッチ１０３からの指示によりアプリケーションの切り替えが行われると、プロセススイッチ１０３からアービタコア１０２に対して、アプリケーションの切り替えが終了したことを示す通知が出される（ステップＳ２８４）。ステップＳ２２８において、アービタコア１０２は、プロセススイッチ１０３からの通知により、その時点での動作しているアプリケーション、この場合アプリケーション１２２であることを認識する。

アービタコア１０２は、ステップＳ２２９において、グラフィックサーバ１１１とコールバックの処理を行い、ステップＳ２３０において、インプットサーバ１１２とコールバックの処理を行う。このコールバックの処理は、アプリケーションフレームワーク１２１とグラフィックサーバ１１１、アプリケーションフレームワーク１２１とインプットサーバ１１２をそれぞれ接続するための処理である。

そのような接続の処理が実行された場合、グラフィックサーバ１１１とインプットサーバ１１２からそれぞれ、接続が完了したことを示す通知が出される（ステップＳ２４４、ステップＳ２６４）。アービタコア１０２は、ステップＳ２３１とステップＳ２３２において、グラフィックサーバ１１１とインプットサーバ１１２からの通知を受信すると、ステップＳ２３３において、アプリケーションフレームワーク１２１に対して、デバイスとの接続が完了したことを通知する。このようにしてアプリケーションフレームワークの切り替えが行われる。

図１２を参照し、アプリケーションフレームワークの切り替えについて再度説明する。ここでは、アプリケーションフレームワーク１２１とアプリケーション１２２が起動されている状態であり、アプリケーションフレームワーク１３１に切り替えが行われる場合を例にあげて説明する。

ステップＳ３０１において、アプリケーション１２２からアービタコア１０２に対してアプリケーションフレームワーク１３１への切り替え要求が出される。そのような要求をステップＳ３３１において受け取ったアービタコア１０２は、ステップＳ３３２において、コールバックの処理をグラフィックサーバ１１１と行う。グラフィックサーバ１１１は、ステップＳ３４１の処理として、アービタコア１０２とのコールバックの処理を行う。

同様に、アービタコア１０２は、ステップＳ３３３において、コールバックの処理をインプットサーバ１１２と行う。インプットサーバ１１２は、ステップＳ３６１の処理として、アービタコア１０２とのコールバックの処理を行う。

ここで行われるコールバックの処理は、アプリケーションフレームワーク１２１との接続を解除するための処理である。そのような接続の解除が行われた場合、グラフィックサーバ１１１とインプットサーバ１１２からそれぞれ、接続の解除が終了したことを示す通知が出される（ステップＳ３４２、ステップＳ３６２）。

アービタコア１０２は、ステップＳ３３４とステップＳ３３５において、グラフィックサーバ１１１とインプットサーバ１１２からの通知を受信すると、ステップＳ３３６において、アプリケーションフレームワーク１２１に、デバイスとの接続が解除されたことを通知する。アービタコア１０２は、このような通知を出す一方で、ステップＳ３３７において、プロセススイッチ１０３に対して、アプリケーション１２２からアプリケーション１３２に切り替えるように指示を出す。

ステップＳ３８１において、アービタコア１０２からの指示を受け取ったプロセススイッチ１０３は、ステップＳ３８２において、アプリケーション１２２に対して、動作の停止を指示する（アプリケーションフレームワーク１２１の不活性化の処理が実行される）。

またステップＳ３８３において、プロセススイッチ１０３は、アプリケーション１３２に対して動作の開始を指示する（アプリケーションフレームワーク１３１の活性化の処理が実行される）。このようにして、アプリケーションの切り替えが行われる。この場合、アプリケーション１２２からアプリケーション１３２への切り替えが行われる。

このようなプロセススイッチ１０３からの指示によりアプリケーションの切り替えが行われると、プロセススイッチ１０３からアービタコア１０２に対して、アプリケーションの切り替えが終了したことを示す通知が出される（ステップＳ３８４）。ステップＳ３３８において、アービタコア１０２は、プロセススイッチ１０３からの通知により、その時点での動作しているアプリケーション、この場合アプリケーション１３２であることを認識する。

アービタコア１０２は、ステップＳ３３９において、グラフィックサーバ１１１とコールバックの処理を行い、ステップＳ３４０において、インプットサーバ１１２とコールバックの処理を行う。このコールバックの処理は、アプリケーションフレームワーク１３１とグラフィックサーバ１１１、アプリケーションフレームワーク１３１とインプットサーバ１１２をそれぞれ接続するための処理である。

そのような接続の処理が実行された場合、グラフィックサーバ１１１とインプットサーバ１１２からそれぞれ、接続が完了したことを示す通知が出される（ステップＳ３４４、ステップＳ３６４）。アービタコア１０２は、ステップＳ３４１とステップＳ３４２において、グラフィックサーバ１１１とインプットサーバ１１２からの通知を受信すると、ステップＳ３４３において、アプリケーションフレームワーク１３１に対して、デバイスとの接続が完了したことを通知する。このようにしてアプリケーションフレームワークの切り替えが行われる。

このように、１つのシステムに複数のアプリケーションフレームワークを設け、それら複数のアプリケーションフレームワークを切り替えられるようにすることが可能となる。このような複数のアプリケーションフレームワークの切り替えを、装置の電源を一旦オフにし、再度オンにすることで行ったり、別プロセッサ及びハードウェアを用意し、それらを切り替えることで行ったり、または仮想マシンを利用する等の方法で行ったりしなくても行え、高速な切り替えが可能となる。

また、オペレーティングシステムの生存期間中に、１つのシステム内で、様々なアプリケーションフレームワークに依存したアプリケーションを使用することができるようになる。また、過去のアプリケーションフレームワークとアプリケーションを流用しつつ、そのアプリケーションフレームワークとは異なるアプリケーションフレームワークに対応したアプリケーションをシステムに組込むことができる。このようなことが可能となることで、アプリケーションの開発コストを下げることが可能となる。

［アプリケーションフレームワークの切り替え後の処理について］
次に、上記したようにしてアプリケーションフレームワークが切り替えられた後の処理について説明する。まず参考のために、図１３を参照し、上記したようなアプリケーションフレームワークの切り替えが行えない場合について説明する。

図１３を参照するに、入力デバイスとしてのキーボード１７２やマウス１７３などのデバイス１１からの入力データは、オペレーティングシステム１３上のデバイスドライバ１２を介して、アプリケーションフレームワーク１４に供給される。さらに、アプリケーションフレームワーク１４を介してアプリケーション１５に入力データが供給され、アプリケーション１５の処理により、入力データに応じた処理が実行される。

従来図２を参照して説明したように、１つのシステムには、１つのアプリケーションフレームワーク１４しか存在せず、動作することが前提に設計されている。よって、例えば図１３に示すように、アプリケーションフレームワーク１４’やアプリケーションフレームワーク１４”という、アプリケーションフレームワーク１４とは異なるアプリケーションフレームワークが、１つのシステム上に存在した場合、デバイス１１からの入力データは、アプリケーションフレームワーク１４’やアプリケーションフレームワーク１４”に供給する仕組みが無く、供給することができない。

また、アプリケーションフレームワーク１４’やアプリケーションフレームワーク１４”に依存するアプリケーション１５’やアプリケーション１５”は、入力データに基づく処理を実行することができない。換言すれば、アプリケーションフレームワーク１４上のアプリケーション１５しか、入力デバイスからの入力データを使用することができない。

しかしながら、上記したように、本実施の形態によれば、複数のアプリケーションフレームワークを１つのシステム上に設け、それらの複数のアプリケーションフレームワークの切り替えて用いることができる。アプリケーションフレームワークの切り替え後に、入力デバイスからの入力データを、アプリケーションに届けるまでの処理について次に説明する。

図１４は、アプリケーションフレームワークの切り替え後に、入力デバイスからの入力データを、アプリケーションに届ける場合の１構成例を示す図である。図１４に示した例では、レジストリビュータ（Redistributor）２０１という入力を受け付けるアプリケーションを、アプリケーション１２２−１乃至１２２−Ｎとは別に設ける。

また、複数のアプリケーションフレームワークのうち、動作しているアプリケーションフレームワークに、入力デバイスからの入力データを供給するために、オペレーティングシステム１３、例えば、Linux（登録商標）のUINPUT機能を利用する。このオペレーティングシステム１３のUINPUT機能は、アプリケーションからの指示によって、任意の入力イベントを発生させることができる。すなわち、UINPUT機能は、アプリケーションからの指示によって入力されたデータを、他の機能に供給する機能を有する。

このような機能を利用し、アプリケーションフレームワーク上のアプリケーションとして、「入力イベントを受け取ったらUINPUTに渡す」という処理を行うモジュールを追加する。このモジュールが、図１４におけるレジストリビュータ２０１である。レジストリビュータ２０１により入力イベントは、uinput２１１に渡され、その結果、他のアプリケーションフレームワーク１３１やアプリケーションフレームワーク１４１が入力イベントを受信することができるようになる。

図１４において、アプリケーションフレームワーク１３１が動作しているときには、まず入力デバイスとしてのキーボード１７２やマウス１７３などのデバイス１１からの入力データは、オペレーティングシステム１３上のデバイスドライバ１２を介して、アプリケーションフレームワーク１２１に供給される。さらに、アプリケーションフレームワーク１２１を介してレジストリビュータ２０１に入力データが供給され、レジストリビュータ２０１の処理により、オペレーティングシステム１３のuinput２１１に供給される。

uinput２１１の処理により、入力データは、アプリケーションフレームワーク１３１に供給される。このように、レジストリビュータ２０１に一旦入力データが供給され、レジストリビュータ２０１の処理により、オペレーティングシステム１３のuinput２１１に入力データが戻され、uinput２１１の処理により、その時点で、動作中のアプリケーションフレームワークに入力データが供給される。

このように、レジストリビュータ２０１は、入力デバイスからの入力データを、オペレーティングシステム１３を介して、アプリケーションフレームワークに供給する機能を有する。このような機能は、デバイスサーバ１０４と同じ機能である。デバイスサーバ１０４は、例えば、図５を参照して説明したように、デバイスからのデータをアプリケーションフレームワークに供給するインタフェースの機能を有する。

よって、図１４に示した構成は、デバイスサーバ１０４を、レジストリビュータ２０１に設けた場合と言える。このように、デバイスサーバ１０４は、レジストリビュータ２０１として設けることが可能である。換言すれば、デバイスサーバ１０４は、アプリケーションとして設けることが可能である。また、デバイスサーバ１０４は、完全に独立している必要が無く、他の機能を共用される構成とすることも可能である。

図１４に示したような構成における入力に係わる処理について、図１５のシーケンス図を参照して説明する。ステップＳ５０１において、デバイスドライバ１２に、デバイス１１からの入力データが供給される。デバイスドライバ１２は、デバイス１１からの入力データを、アプリケーションフレームワーク１２１に供給する（ステップＳ５０２）。

アプリケーションフレームワーク１２１は、ステップＳ５２１において、デバイスドライバ１２からの入力データを受け取る。このように、アプリケーションフレームワーク１２１に入力イベントが発生すると、ステップＳ５２２において、アプリケーションフレームワーク１２１は、レジストリビュータ２０１に、入力データを供給する。

レジストリビュータ２０１は、上記したように、入力イベントを受け取ったらUINPUTに渡すという処理を行うアプリケーションである。よってレジストリビュータ２０１は、ステップＳ５４１において、アプリケーションフレームワーク１２１から入力データの供給を受けると、その入力データを、ステップＳ５４２において、uinput２１１に戻す。

uinput２１１は、ステップＳ５６１において、レジストリビュータ２０１からの入力データを受け取ると、ステップＳ５６２において、アプリケーションフレームワーク１３１に入力データを供給する。この場合、アービタコア１０２の処理により、アプリケーションフレームワーク１３１がデバイスと対応付けされているため、アプリケーションフレームワーク１３１に対して入力データが供給される。例えば、アービタコア１０２の処理により、アプリケーションフレームワーク１４１がデバイスと対応付けされていた場合には、アプリケーションフレームワーク１４１に対して入力データが供給される。

アプリケーションフレームワーク１３１は、ステップＳ５８１において、uinput２１１からの入力データを受け取ると、アプリケーションフレームワーク１３１に入力イベントが発生する。アプリケーションフレームワーク１３１に入力イベントが発生した場合、アプリケーションフレームワーク１３１は、ステップＳ５８２において、受け取った入力データを、上層のアプリケーション１３２に供給する。アプリケーション１３２は、ステップＳ５９１において、入力データを受け取ると、その入力データに基づく処理を開始する。

このように、レジストリビュータ２０１を備え、レジストリビュータ２０１からuinput２１１に入力データが供給され、uinput２１１から、その時点で動作しているアプリケーションフレームワークに入力データが転送されるようにすることで、キーボードやマウスなどの入力デバイスからの入力を、切り替え後のアプリケーションフレームワークに供給できるようになる。

［入力に係わる他の処理について］
図１６を参照し、アプリケーションフレームワークの切り替え後に、入力デバイスからの入力データを、アプリケーションに届ける場合の他の構成例について説明する。図１６に示した例でも、図１４に示した構成例と同じく、複数のアプリケーションフレームワークのうち、動作しているアプリケーションフレームワークに、入力デバイスからの入力データを供給するために、オペレーティングシステム１３、例えば、Linux（登録商標）のUINPUT機能を利用する。

図１６に示した構成においては、アプリケーションフレームワーク３０１に、入出力判断部３０２を設け、その入出力判断部３０２により、入力された入力データの出力先が判断され、その判断先に入力データが供給される。入出力判断部３０２により、デバイスドライバ１２を介して入力された入力データが、アプリケーション１２２への入力データであるのか、アプリケーション１２２以外のアプリケーションへの入力データであるのかが判断され、その判断に基づくアプリケーションに、入力データが供給される。

図１６に示した構成においては、アプリケーションフレームワーク３０１内に設けられた入出力判断部３０２が、入力デバイスからの入力データを、オペレーティングシステム１３（uinput２１１）を介して、アプリケーションフレームワークに供給する機能を有する。このような機能は、デバイスサーバ１０４と同じ機能である。デバイスサーバ１０４は、例えば、図５を参照して説明したように、デバイスからのデータをアプリケーションフレームワークに供給するインタフェースの機能を有する。

よって、図１６に示した構成は、デバイスサーバ１０４を、アプリケーションフレームワーク３０１内に設けた場合と言える。このように、デバイスサーバ１０４は、アプリケーションフレームワークの１機能として設けることが可能である。換言すれば、デバイスサーバ１０４は、アプリケーションフレームワークとして設けることが可能である。また、デバイスサーバ１０４は、完全に独立している必要が無く、他の機能を共用される構成とすることも可能である。

図１７のシーケンス図を参照し、入力に関わる処理について説明する。ステップＳ７０１において、デバイスドライバ１２にデバイス１１からの入力があると、ステップＳ７０２において、デバイスドライバ１２は、アプリケーションフレームワーク３０１に、入力データを供給する。アプリケーションフレームワーク３０１の入出力判断部３０２は、ステップＳ７１１において、デバイスドライバ１２からの入力データを、アプリケーション１２２に出力するか、アプリケーション１２２以外のアプリケーションに出力するかを判断する。

入出力判断部３０２は、デバイスサーバ１０４の機能を有しているため、デバイスとアプリケーションフレームワークとの対応付けを管理している。その管理している対応付けに基づいて、入出力判断部３０２は、入力データの供給先を判断する。

入出力判断部３０２は、アプリケーション１２２に入力データを出力すると判断した場合、ステップＳ７１２において、アプリケーション１２２に対して、入力データを出力する。アプリケーション１２２は、ステップＳ７２１において、入出力判断部３０２からの入力データを受け取ると、その入力データに基づく処理を開始する。

一方で、入出力判断部３０２は、入力データは、アプリケーション１２２以外のアプリケーションに出力すると判断した場合、ステップＳ７１３において、入力データを、uinput２１１に出力する。なお、図１７においては、入出力判断部３０２から、ステップＳ７１２において、アプリケーション１２２に対して入力データが供給される場合と、ステップＳ７１３において、uinput２１１に対して入力データが供給される場合とを図示したが、実際には入出力判断部３０２の判断に基づくどちらか一方の供給のみが行われる。

uinput２１１は、ステップＳ７４１において、入出力判断部３０２からの入力データを受け取ると、ステップＳ７４２において、その時点で、動作しているアプリケーションフレームワーク１３１に、入力データを出力する。その結果、アプリケーションフレームワーク１３１は、ステップＳ７５１において、入力データを受け取る。

このようにして、アプリケーションフレームワーク１３１に入力イベントが発生すると、ステップＳ７５２において、アプリケーションフレームワーク１３１は、供給された入力データを上層のアプリケーション１３２に供給する。アプリケーション１３２は、ステップＳ７６１において、アプリケーションフレームワーク１３１からの入力データを受け取ると、入力データに基づく処理を開始する。

このようにして、入力デバイスからの入力データを、所望のアプリケーション（アプリケーションフレームワーク）に供給することが可能となる。

このように入力デバイスからの入力データを、所望のアプリケーション（アプリケーションフレームワーク）に供給することが可能となることで、既定義のアプリケーションフレームワーク側に変更が必要な場合も、変更量は少なく、システム全体を容易に拡張できる。また、アプリケーションまたはアプリケーションフレームワークでイベントを再配信するため、配信前にフィルタリングや値の補正を行うことや、同時に複数のアプリケーションフレームワークに入力イベントを送信するなどの特殊な処理が可能になる。例えば、不要なイベントを削減、ポインタ座標を補正、ポインタ座標によってイベントを配信するアプリケーションフレームワークを決める等の処理が可能となる。

［出力に関わる処理について］
次に、アプリケーションフレームワークの切り替え後に、所定のアプリケーションから出力デバイスに、データを届ける場合について説明する。出力に関しては、図１８に示すように、共有メモリ４０１を備えることで実現する。

共有メモリ４０１は、アプリケーション１２２とアプリケーションフレームワーク１３１で共用されるメモリである。なお、図１８には図示していないが、共有メモリ４０１は、アプリケーション１２２とアプリケーションフレームワーク１４１で共用されるメモリでもある。すなわち、共有メモリ４０１は、所定のアプリケーション、この場合、アプリケーションフレームワーク１２１上のアプリケーション１２２と、その所定のアプリケーションとは異なるアプリケーションの下位層のアプリケーションフレームワークとの間で共有されるメモリである。

共有メモリ４０１には、アプリケーションフレームワーク１３１（アプリケーションフレームワーク１３１の上層のアプリケーション１３２）が描画したデータが一旦記憶される。そして、共有メモリ４０１に記憶された描画データは、アプリケーション１２２により読み出され、アプリケーションフレームワーク１２１に供給される。

そして、アプリケーションフレームワーク１２１により、デバイスドライバ１２を介してデバイス１１に供給され、ディスプレイ１７１に、アプリケーション１３２により描画されたテキストや画像などのグラフィックが表示される。

このような処理について、図１９のシーケンス図を参照して説明する。図１９を参照して説明する出力時の処理は、図１８に示した場合と同じく、アプリケーションフレームワーク１２１がグラフィックデバイスを占有し、アプリケーション１３２により描画されたグラフィックが、ディスプレイ１７１に表示される場合を例に挙げて説明する。

アプリケーション１３２は、ステップＳ９０１において、描画を開始し、描画データを、アプリケーションフレームワーク１３１に出力する。アプリケーションフレームワーク１３１は、受け取った描画データを、ステップＳ９２１において、共有メモリ４０１に書き込む。このように、アプリケーション１３２からの描画データは、共有メモリ４０１に書き込まれる。

アプリケーション１２２は、アプリケーションフレームワーク１３１による共有メモリ４０１への描画データの書き込みが完了したら、アプリケーションフレームワーク１３１からの通知を受け、共有メモリ４０１に書き込まれた描画データを読み出す機能を有する。

アプリケーション１２２は、アプリケーションフレームワーク１３１から通知を受けると、ステップＳ９４１において、共有メモリ４０１から描画データを読み出す。読み出された描画データは、アプリケーション１２２の処理により、アプリケーションフレームワーク１２１に供給される。ステップＳ９６１において、アプリケーションフレームワーク１２１は、そのような供給を受けると、ステップＳ９６２において、オペレーティングシステム１３（デバイスドライバ１２）に、描画データを供給する。

この後、デバイスドライバ１２からデバイス１１（ディスプレイ１７１）に描画データが供給されることで、ディスプレイ１７１上に、アプリケーション１３２により描画されたグラフィックが表示される。

このように、共有メモリ４０１をアプリケーションフレームワーク１３１とアプリケーション１２２で共用し、アプリケーション１２２が、共有メモリ４０１から描画データを読み出し、デバイスに供給することで、描画が行われる。他の出力、例えば音声データなども、同様に共有メモリ４０１を介して行うことが可能である。

このように、複数のアプリケーションフレームワークのうちの所定のアプリケーションフレームワークが、直接、デバイス１１（ディスプレイ１７１）に描画データを供給できない構成であっても、他のアプリケーションフレームワークとそのアプリケーションフレームワーク上のアプリケーションの処理により、所定のアプリケーションフレームワークからの描画データを、デバイス１１に供給することが可能となる。このようなことが可能となることで、アプリケーションフレームワークの変更を少なく、アプリケーションフレームワークを追加して、システム全体を拡張することが可能となる。

［記録媒体について］
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウェアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。

例えば、図１に示した情報処理装置１０では、ＣＰＵ２１が、例えば、記憶部２８に記憶されているプログラムを、入出力インタフェース２５及び内部バス２４を介して、ＲＡＭ２３にロードして実行することにより、上述した一連の処理が行われる。

コンピュータ（ＣＰＵ２１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア３１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。

コンピュータでは、プログラムは、リムーバブルメディア３１をドライブ３０に装着することにより、入出力インタフェース２５を介して、記憶部２８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部２９で受信し、記憶部２８にインストールすることができる。その他、プログラムは、ＲＯＭ２２や記憶部２８に、あらかじめインストールしておくことができる。

なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。

また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。

なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。

１０１ アービタ， １０２ アービタコア， １０３ プロセススイッチ， １０４ デバイスサーバ， １１１ グラフィックサーバ， １１２ インプットサーバ， １１３ サウンドサーバ， １２１ アプリケーションフレームワーク， １２２ アプリケーション， １３１ アプリケーションフレームワーク， １３２ アプリケーション， １４１ アプリケーションフレームワーク， １４２ アプリケーション

Claims (14)

1. 複数のアプリケーションフレームワークと、
   前記アプリケーションフレームワークを切り替える切り替え部と
   を備え、
   前記複数のアプリケーションフレームワークのうちの第１のアプリケーションフレームワークと、
   前記第１のアプリケーションフレームワーク上で動作する第１のアプリケーションと、
   前記第１のアプリケーションフレームワークとは異なる第２のアプリケーションフレームワークと、
   前記第２のアプリケーションフレームワーク上で動作する第２のアプリケーションと
   を備え、
   前記切り替え部は、
   前記第１のアプリケーションから、前記第２のアプリケーションフレームワークに切り替えが指示されたとき、前記第１のアプリケーションフレームワークから前記第２のアプリケーションフレームワークに、デバイスとの入出力先を切り替える
   情報処理装置。
2. 前記切り替え部は、
   前記複数のアプリケーションフレームワークと前記デバイスを１対１に接続されるように切り換えを行う
   請求項１に記載の情報処理装置。
3. 前記切り替え部は、
   複数のアプリケーションのうちの所定のアプリケーションを不活性化し、他のアプリケーションを活性化する機能を担う部分と、
   前記複数のアプリケーションフレームワークのうちの所定のアプリケーションフレームワークをデバイスと切り離し、他のアプリケーションフレームワークと接続する機能を担う部分をそれぞれ有する
   請求項１または２に記載の情報処理装置。
4. 前記切り替え部は、
   前記第１のアプリケーションから、前記第２のアプリケーションフレームワークに切り替えが指示されたとき、前記第１のアプリケーションを不活性化し、前記第２のアプリケーションを活性化する
   請求項１乃至３のいずれかに記載の情報処理装置。
5. 前記第１のアプリケーションは複数あり、
   前記切り替え部は、複数の前記第１のアプリケーションの１アプリケーションとして存在し、
   前記第１のアプリケーションとしての前記切り替え部は、前記デバイスからの入力を前記第２のアプリケーションフレームワークに転送する
   請求項１乃至４のいずれかに記載の情報処理装置。
6. 前記切り替え部は、前記第１のアプリケーションフレームワークの１機能として存在し、
   前記第１のアプリケーションフレームワークに含まれる前記切り替え部は、前記デバイスからの入力を、前記第２のアプリケーションフレームワークに転送する
   請求項１乃至４のいずれかに記載の情報処理装置。
7. 前記デバイスからの入力は、オペレーティングシステムに含まれる入力供給機能により、前記第１のアプリケーションまたは前記第１のアプリケーションフレームワークから、前記第２のアプリケーションフレームワークに供給される
   請求項１乃至６のいずれかに記載の情報処理装置。
8. 前記入力供給機能は、uinputの機能である
   請求項７に記載の情報処理装置。
9. 前記第２のアプリケーションからの出力データは、前記第２のアプリケーションフレームワークを介して、記憶部に記憶され、
   前記記憶部に記憶された前記出力データは、前記第１のアプリケーションにより読み出され、前記第１のアプリケーションフレームワークを介して、前記デバイスに供給される
   請求項１乃至８のいずれかに記載の情報処理装置。
10. 前記第２のアプリケーションが描画した描画データが、前記記憶部に前記第２のアプリケーションフレームワークを介して記憶され、
    前記記憶部に記憶された前記描画データが、前記第１のアプリケーションより読み出され、前記第１のアプリケーションフレームワークを介して、ディスプレイに供給される
    請求項９に記載の情報処理装置。
11. 前記第１のアプリケーションフレームワークは、カメラ機能に関するアプリケーションフレームワークであり、
    前記第２のアプリケーションフレームワークは、通信機能に関するアプリケーションフレームワークである
    請求項１乃至１０のいずれかに記載の情報処理装置。
12. 前記カメラ機能に関する前記第１のアプリケーションフレームワーク上で動作する前記第１のアプリケーションの処理により、ユーザからの入力操作に従って撮影された画像を、前記通信機能に関する第２のアプリケーションフレームワーク上で動作する前記第２のアプリケーションの処理により、他の装置に送信する
    請求項１１に記載の情報処理装置。
13. 複数のアプリケーションフレームワークのうちの第１のアプリケーションフレームワークと、
    前記第１のアプリケーションフレームワーク上で動作する第１のアプリケーションと、
    前記第１のアプリケーションフレームワークとは異なる第２のアプリケーションフレームワークと、
    前記第２のアプリケーションフレームワーク上で動作する第２のアプリケーションと
    を備える情報処理装置の情報処理方法において、
    前記第１のアプリケーションから、前記第２のアプリケーションフレームワークに切り替えが指示されたとき、前記第１のアプリケーションフレームワークから前記第２のアプリケーションフレームワークに、デバイスとの入出力先を切り替える
    ステップを含む情報処理方法。
14. 複数のアプリケーションフレームワークのうちの第１のアプリケーションフレームワークと、
    前記第１のアプリケーションフレームワーク上で動作する第１のアプリケーションと、
    前記第１のアプリケーションフレームワークとは異なる第２のアプリケーションフレームワークと、
    前記第２のアプリケーションフレームワーク上で動作する第２のアプリケーションと
    を備える情報処理装置を制御するコンピュータに、
    前記第１のアプリケーションから、前記第２のアプリケーションフレームワークに切り替えが指示されたとき、前記第１のアプリケーションフレームワークから前記第２のアプリケーションフレームワークに、デバイスとの入出力先を切り替える
    ステップを含む処理を実行させるためのプログラム。

Images