JP2004038578A - 情報処理装置、情報処理方法、プログラム、記録媒体 - Google Patents
情報処理装置、情報処理方法、プログラム、記録媒体 Download PDFInfo
- Publication number
- JP2004038578A JP2004038578A JP2002195029A JP2002195029A JP2004038578A JP 2004038578 A JP2004038578 A JP 2004038578A JP 2002195029 A JP2002195029 A JP 2002195029A JP 2002195029 A JP2002195029 A JP 2002195029A JP 2004038578 A JP2004038578 A JP 2004038578A
- Authority
- JP
- Japan
- Prior art keywords
- command
- application
- program
- window
- processing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
【課題】複数のアプリケーションが起動される情報処理装置において、非アクティブとなっているアプリケーションであっても、入力コマンドに応答した処理が可能なようにして、操作性の向上を図る。また、これと共に、オペレーションシステムのプログラムが複雑にならないようにする。
【解決手段】コマンド対応処理として、アクティブなアプリケーションが、オペレーションシステムから転送されたコマンドについて処理できないと判断したときには、このコマンドをコマンド管理アプリケーションに転送する。そして、コマンド管理アプリケーションでは、転送されたコマンドを、このコマンドを処理することのできる非アクティブのアプリケーションに転送するように構成する。これにより、非アクティブのアプリケーションによってコマンド処理が実行される。
【選択図】 図８
【解決手段】コマンド対応処理として、アクティブなアプリケーションが、オペレーションシステムから転送されたコマンドについて処理できないと判断したときには、このコマンドをコマンド管理アプリケーションに転送する。そして、コマンド管理アプリケーションでは、転送されたコマンドを、このコマンドを処理することのできる非アクティブのアプリケーションに転送するように構成する。これにより、非アクティブのアプリケーションによってコマンド処理が実行される。
【選択図】 図８
Description
【０００１】
【発明の属する技術分野】
本発明は、外部からのイベントに応じて入力されるコマンドに対応して処理を実行する情報処理装置、及び情報処理方法に関する。また、このような情報処理装置、及び情報処理方法が実現されるようにするためのプログラム、及びこのプログラムが記憶される記憶媒体に関する。
【０００２】
【従来の技術】
近年においては、例えばパーソナルコンピュータが広く普及してきている。このようなパーソナルコンピュータには、ＯＳ（Ｏｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ）上で動作するプログラム単位である、各種のアプリケーションプログラムがインストールされる。そして、ユーザは、これらのアプリケーションプログラムを複数起動させて、これらのアプリケーションプログラムを使用することができる。なお、以降においては、アプリケーションプログラムについては、略して「アプリケーション」ともいうこととする。
【０００３】
また、上記のようにして複数のアプリケーションを起動させた場合、ユーザは、アクティブとなっているアプリケーションに対してのみ、イベント入力（操作）が可能なようになっている。アクティブとなっているアプリケーションは、例えば表示画面に表示されるＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）画像上では、そのアプリケーションのウィンドウが、所定態様による強調表示が行われるなどして、他の非アクティブとなっているアプリケーションのウィンドウとの区別が行われる。また、アクティブとなっているアプリケーションは、一般には、１つであるようにしてＯＳによる管理が行われる。
【０００４】
【発明が解決しようとする課題】
上記したように、ユーザによる操作入力に応答できるのは、アクティブとなっているアプリケーションのみとされる。これは、ＯＳ及びアプリケーションの仕組みとして、次のようになっていることに依る。
つまり、ＯＳとしては、外部からのイベントに基づいて入力したコマンドを、常に現在アクティブとなっているアプリケーションに渡すようにされる。そして、アクティブなアプリケーションでは、受け渡されたコマンドについて自己が処理すべきものであれば、そのコマンドに従った処理を実行させる。これに対して、コマンドについては自己が処理すべきものでない場合には、特に処理は実行せずに、そのコマンドを無効とするのである。
【０００５】
上記のような仕組みとされていることで、ユーザは、非アクティブとなっているアプリケーションに対して、直接的に入力操作を行うことはできないということになる。
このようなことは、例えばユーザが一般にマウスやキーボードを操作してパーソナルコンピュータを使用している場合には、これらの入力デバイスによるＧＵＩ画像への直接的な操作によってアクティブなアプリケーションの切り換えを直ぐに行うことができるから、これまで特に問題とはなっていなかったものである。
【０００６】
しかしながら、近年のパーソナルコンピュータなどにおいては、例えばテレビジョンチューナのほか、ＣＤプレーヤをはじめとするメディアプレーヤなどを搭載することで、相当に充実したＡＶ機能を有するものが普及してきている。そして、このようなパーソナルコンピュータでは、上記したＡＶ機能に対応した操作が可能なリモートコントローラを備えるものも知られるようになってきている。つまり、リモートコントローラに対する操作に応じて、パーソナルコンピュータ側では、テレビジョンチューナにおけるチャンネルの選局制御を行ったり、また、メディアプレーヤの記録再生動作を制御するものである。
一例ではあるが、操作態様として、上記のようしてリモートコントローラにより操作を行う場合に、上記した操作性等の問題が顕著となるものである。この点について次のような動作例を挙げて説明しておく。
【０００７】
ここで、パーソナルコンピュータにはメディアプレーヤが搭載されており、このパーソナルコンピュータには、上記メディアプレーヤについての記録再生を行うためのメディアプレーヤ対応アプリケーションがインストールされていることとする。また、画像処理アプリケーションもインストールされているものとする。そして、例えば現在においては、上記した２つのアプリケーションが起動されているうえで、アクティブとなっているのは、画像処理アプリケーションであるとする。
【０００８】
この状態の下で、ユーザがリモートコントローラを操作して、メディアプレーヤに装填されたメディアを再生するための操作を行ったとする。パーソナルコンピュータ側のＯＳでは、上記操作に応じてリモートコントローラから送信された信号を受信し、再生コマンドとして取得することになる。つまり、ＯＳでは、リモートコントローラからの送信信号の受信をイベントとして受け付け、この送信信号に基づいた再生コマンドを取得する。
このとき、アクティブとなっているアプリケーションは、画像処理アプリケーションとなっている。このため、ＯＳは、受信取得した再生コマンドを、メディアプレーヤ対応アプリケーションではなく、画像処理アプリケーションに渡すことになる。
この再生コマンドは、メディアプレーヤ対応アプリケーションが処理すべきコマンドであり、画像処理アプリケーションが処理すべきコマンドではない。従って、上記再生コマンドを受け取った画像処理アプリケーションでは、このコマンドを無効として、特に対応した処理は実行しないことになる。
【０００９】
これは、リモートコントローラを再生するユーザにとってみれば、再生操作を行ったのにも関わらず、メディアプレーヤによるメディア再生が開始されないというようにして捉えることになる。つまり、ユーザがリモートコントローラに対して行った操作に、パーソナルコンピュータが反応していないものとして受け取られることになる。
このような動作をみたユーザによっては、パーソナルコンピュータ又はリモートコントローラが故障しているのではと考える場合も出てくる可能性がある。
また、メディアプレーヤ対応アプリケーションがアクティブではなかったから、このような動作になったのだということをユーザが理解しているとしても、リモートコントローラに対する操作に応じて、即座にパーソナルコンピュータ側が反応した動作を行わないというのは、操作感上での違和感を覚えることになる。また、操作性がよくないと感じることにもなり、機器としての信頼性を損なう可能性がある。
【００１０】
このようにして、現状における外部イベントに対応したパーソナルコンピュータなどのコマンド対応処理の仕方では、良好な操作性が得られないことで信頼性を欠く場合があるという問題を有しているものである。特に、例えば上記したように、例えばリモートコントローラなどのようにして、これまでのマウス、キーボード以外の多様な入力デバイスによる入力に対応するようになってきている背景を考慮すれば、この問題は解決されるべき大きな課題になっているといえる。
【００１１】
そこで、例えばアプリケーションを管理するＯＳにより、コマンド管理を実行させるように構成することが考えられる。つまり、ＯＳは、入力されたコマンドが、どのアプリケーションで処理すべきなのかを認識する。そして、この認識結果に基づいて、そのアプリケーションによりコマンドに対応した処理を実行させるものである。
しかしながら、上記のような構成を採ろうとすれば、ＯＳについて、膨大な数のコマンドを理解できるようにしたうえで、これらコマンドの間でのコリジョンなどが生じないようにしてプログラムを作成する必要がある。
このようなプログラムを作成することは非常に困難であり、現実的ではない。つまり、アプリケーションは現在において、また将来的にも実に多様に存在するから、これらに全て対応することは不可能に近い。また、例えばいくつかのアプリケーションに限定してこのようなプログラム構成のＯＳを作成するとしても、やはり、プログラム作成についての困難がつきまとう。
【００１２】
ちなみに、現状におけるＯＳが、入力したコマンドの内容に関わらず、常に、アクティブとなっているアプリケーションにそのコマンドを転送するイベント処理としているのは、この理由が大きい。
つまり、現状におけるＯＳのイベント処理は、ユーザによりアクティブなアプリケーションを選択させたうえで、ユーザに対して、このアクティブとしたアプリケーションが処理すべきコマンドを送信してもらうことを前提としている。このようなことを前提としたイベント処理であれば、ＯＳについての複雑化を避け、かつ、ＯＳに対応可能な多くのアプリケーションを確保することができるわけである。
【００１３】
【課題を解決するための手段】
そこで本発明は、先に述べた課題を考慮して、例えば非アクティブとなっているアプリケーションに対するコマンドが入力されたときにも、このコマンドに応答して上記非アクティブとなっているアプリケーションがコマンド処理できるようにして、これまでよりも操作性が向上されるようにすることを目的とする。また、この目的を実現するのにあたっては、オペレーションシステムのプログラムが複雑にならないようにすることも目的とする。
【００１４】
そして、情報処理装置としては次のように構成することとした。
つまり、複数のアプリケーションプログラムと、これら複数のアプリケーションプログラムを管理するプログラムであるオペレーティングシステムと、上記オペレーティングシステムにより管理される上記アプリケーションプログラムの１つであり、他のアプリケーションプログラムに対応する各コマンドを管理可能とされるコマンド管理アプリケーションとが記憶される記憶手段を備える。
また、外部から与えられるイベントをコマンドとして入力する入力手段を備える。
そして、記憶手段に記憶されたプログラムを実行することによって、オペレーティングシステムが入力手段により入力されたコマンドをアクティブなアプリケーションに転送し、アクティブなアプリケーションプログラムが上記コマンドに対応する処理を実行できないと判定したときに、コマンド管理アプリケーションに上記コマンドを転送し、コマンド管理アプリケーションがコマンドに対応する処理を実行可能な非アクティブなアプリケーションプログラムに上記コマンドを転送し、非アクティブなアプリケーションプログラムが上記コマンドに対応する処理を実行するようにされた実行処理手段とを備えることとした。
【００１５】
また、情報処理方法としては次のように構成することとした。
つまり、複数のアプリケーションプログラムと、これら複数のアプリケーションプログラムを管理するプログラムであるオペレーティングシステムと、オペレーティングシステムにより管理されるアプリケーションプログラムの１つであり、他のアプリケーションプログラムに対応する各コマンドを管理可能とされるコマンド管理アプリケーションとを情報処理装置に記憶させておく。
そのうえで、オペレーティングシステムが外部からのイベントに応じて入力されたコマンドをアクティブなアプリケーションに転送する第１の転送ステップと、アクティブなアプリケーションプログラムが上記コマンドに対応する処理を実行できないと判定したときに、コマンド管理アプリケーションに上記コマンドを転送する第２の転送ステップと、コマンド管理アプリケーションが上記コマンドに対応する処理を実行可能な非アクティブなアプリケーションプログラムに上記コマンドを転送する第３の転送ステップと、非アクティブなアプリケーションプログラムが上記コマンドに対応する処理を実行する実行ステップとを実行するように構成することとする。
【００１６】
また、上記コマンド管理アプリケーション以外の他のアプリケーションプログラムに相当するプログラムとしては次のように構成する。
つまり、自己がアクティブな状態である場合に、オペレーションシステムとしてのプログラムが転送してきた、外部からのイベントに応じて入力されたコマンドについて、自己が処理を実行可能であるか否かを判定する判定ステップと、この判定ステップにより、上記コマンドについて処理を実行できないと判定した場合には、上記コマンドに対応する処理をすべき非アクティブなアプリケーションプログラムに対して上記コマンドを転送可能なコマンド管理アプリケーションに、上記コマンドを転送する転送ステップとを情報処理装置に実行させるように構成する。
【００１７】
また、上記コマンド管理アプリケーションに相当するプログラムとして発議のように構成する。
つまり、外部イベントに対応してオペレーティングシステムから転送されたコマンドに対応する処理を実行できないアクティブなアプリケーションプログラムから転送されてきた上記コマンドを、上記コマンドに対応する処理が可能な非アクティブなアプリケーションプログラムに転送する転送ステップを情報処理装置に実行させるように構成するものである。
【００１８】
また、上記各プログラムを記憶することで、本発明としての記憶媒体を構成することとした。
【００１９】
上記各構成によれば、プログラムとして、オペレーションシステムと、このオペレーションシステム上で動作する各種のアプリケーションプログラムに加え、アプリケーションプログラムとしてのコマンド管理アプリケーションが備えられる。
そのうえで、オペレーションシステムは、外部イベントとして入力したコマンドを、先ずアクティブなアプリケーションに転送するようにされる。そして、このアクティブなアプリケーションが、このコマンドについて処理できないと判断したときには、このコマンドをコマンド管理アプリケーションに転送するようにされる。
コマンド管理アプリケーションでは、転送されたコマンドを、さらに、このコマンドを処理することのできる非アクティブのアプリケーションに渡し、この非アクティブのアプリケーションによりコマンド処理を実行させるようにしている。
このような構成であれば、非アクティブとなっているアプリケーションに対するコマンドが入力されたとしても、上記非アクティブとなっているアプリケーションにコマンドに応答した処理を実行させることが可能となる。
また、このような構成によっては、オペレーションシステムとしては、これまでと同様のイベント処理によって、入力したコマンドを、アクティブとなっているアプリケーションに対して転送するという処理を実行させればよいことになる。
【００２０】
【発明の実施の形態】
以下、本発明の実施の形態について説明を行うこととする。なお、以降の説明は次の順序で行う。
１．情報処理装置の構成
２．本実施の形態のソフトウェア構成
３．本実施の形態のアプリケーションにより得られる動作
４．コマンド管理アプリケーションの構造概念
５．処理動作
５−１．ＯＳによる処理動作
５−２．一般アプリケーションによる処理動作
５−３．コマンド管理アプリケーションによる処理動作
【００２１】
１．情報処理装置の構成
図１は、本発明の実施の形態としての情報処理装置１の構成例を示している。ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１は、起動されたプログラムに基づいて情報処理装置１の全体の制御、演算処理を行う。例えばネットワークを介した通信動作、ユーザーに対する入出力動作、ＣＤの再生、ＨＤＤ２１へのコンテンツ記憶やそのための管理などを行う。
ＣＰＵ１１はバス１２を介して各回路部との間で制御信号やデータのやりとりを行う。
【００２２】
メモリ部１３はＣＰＵ１１が処理に用いるＲＡＭ、ＲＯＭ、フラッシュメモリ（不揮発性メモリ）などを包括的に示している。
この場合のメモリ部１３におけるＲＯＭには、ＣＰＵ１１が実行する小規模なプログラムや、ＣＰＵ１１の処理実行時に使用する固定の各種デバイス設定値などを記憶させておくことができる。また、メモリ部１３におけるフラッシュメモリには、各種演算係数、プログラムで用いるパラメータ等が記憶される。メモリ部１３におけるＲＡＭには、プログラムを実行する上でのデータ領域、タスク領域が一時的に確保される。
【００２３】
操作入力部１５は、情報処理装置１の筐体に設けられた操作キーやジョグダイヤル、タッチパネルなどの各種操作子などから成る部位である。なお、ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）操作のためのキーボードやマウスが操作入力部１５として設けられてもよい。操作部１５にて行われた操作に応じた操作情報信号は、入力処理部１４に対して出力される。
【００２４】
また、本実施の形態の情報処理装置１には、リモートコントローラ２９が付属されている。このリモートコントローラ２９には、当該情報処理装置１の各種動作をコントロールするための各種操作子が備えられている。例えば本実施の形態であれば、後述するＣＤドライブ１９に装填されたＣＤについての各種再生操作や、チューナ２７において受信される放送の選局操作などをはじめ、各種の操作を行うことができる。
そして、このリモートコントローラ２９では、操作子に対して行われた操作に応じた操作情報信号を、赤外線又は電波などによって無線により送信出力するようにされる。リモートコントローラから送信された操作情報信号は、情報処理装置１側の受信部２８にて受信され、入力処理部１４に対して入力される。
【００２５】
入力処理部１４では、上記のようにして操作部１５又は受信部２８から入力された操作情報信号について所定の処理を施し、ＣＰＵ１１に対して外部イベントにより発生したコマンドとして伝送する。ＣＰＵ１１は入力されたコマンドに応答した機器としての動作が得られるように、所要の演算や制御を行う。
【００２６】
ディスプレイモニタ１７としては、例えば液晶ディスプレイなどの表示デバイスが接続され、各種情報表示が行われる。
ＣＰＵ１１が各種動作状態や入力状態、通信状態に応じて表示情報を表示処理部１６に供給すると、表示処理部１６は供給された表示データに基づいてディスプレイモニタ１７に表示動作を実行させる。
例えばＣＤ再生時、或いはＨＤＤ２１に格納されたオーディオファイルとしてのコンテンツの再生時には、トラックナンバ、演奏時間、動作状態、音量状態などが表示される。また再生するコンテンツに対応してＣＤタイトル情報が格納されていれば曲名、アーティスト名等の各種情報を表示することもできる。
またラジオ受信時には、受信周波数、音量状態などが表示される。
【００２７】
ＣＤドライブ１９は、光学ヘッド、スピンドルモータ、再生信号処理部、サーボ回路等を備え、ＣＤに対する再生動作を行う。ＣＤドライブ制御部１８は、ＣＤドライブ１９におけるＣＤに対する再生動作、アクセス動作等を制御する。例えばユーザーが入力部１５からＣＤ再生操作を行った場合は、ＣＰＵ１１はＣＤドライブ制御部１８にＣＤ再生を指示する。するとＣＤドライブ制御部１８は、ＣＤドライブ１９に対して再生／アクセスを実行させる制御を行う。
ＣＤドライブ１９では、ＣＤから読み出した信号に対してデコードを行い、再生データをＣＤドライブ制御部１８を介してバス１２に送出する。
この再生データはオーディオデータ処理部２４においてイコライジング等の音場処理や音量調整、Ｄ／Ａ変換、増幅等の処理が施され、スピーカ部２５から出力される。
またＣＤドライブ１９で再生されたデータは、例えばＣＰＵ１１の処理によって所要のファイルエンコード処理を施されてＨＤＤ２１にコンテンツファイルとして蓄積することもできる。
なお、公知のようにＣＤではその最内周側にＴＯＣと呼ばれる管理情報が記録されており、ＣＤ再生時にはＴＯＣに基づいてディスク上のトラック（コンテンツ）のアクセスを行う。従ってＣＤドライブ制御部１８は、ＣＤが装填された際にはＣＤドライブ１９にＴＯＣ読出を指示し、読み出されたＴＯＣデータを得ることで、ＣＤの再生制御が可能となる。
【００２８】
ＨＤＤ２１は、比較的大きな記憶容量を有しているもので、例えば上記もしたように、ＣＤドライブ１９によりＣＤから再生して得たオーディオデータなどのコンテンツファイルを記憶して保存させておくことができる。
また、本実施の形態では、ＣＰＵ１１が実行すべき各種プログラム（ソフトウェア）もインストールされるようにして記憶されている。これらプログラムとしては、ＯＳ（Ｏｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ）、及びこのＯＳ上で動作するアプリケーションプログラムとなる。
【００２９】
チューナ部２７は、例えばＡＭ・ＦＭラジオチューナとされ、ＣＰＵ１１の制御に基づいて、アンテナ２６で受信された放送信号を復調する。もちろんテレビチューナや衛星放送チューナ、デジタル放送チューナなどとしてのチューナでもよい。
復調された放送音声信号は、オーディオデータ処理部２４において所要の処理が施され、スピーカ部２５から放送音声として出力される。
【００３０】
通信処理部２２は、ＣＰＵ１１の制御に基づいて送信データのエンコード処理、受信データのデコード処理を行う。
ネットワークインターフェイス２３は、通信処理部２２でエンコードされた送信データをネットワークを介して所定の外部ネットワーク対応機器に送信する。またネットワークを介して外部ネットワーク対応機器から送信されてきた信号を通信処理部２２に受け渡す。
通信処理部２２は受信した情報をＣＰＵ１１に転送する。
【００３１】
なお、情報処理装置１の構成は、この図１の構成に限られるものではなく、更に多様に考えられる。
例えば各種記録媒体に対応するように、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）ドライブ、ＭＤ（Ｍｉｎｉ Ｄｉｓｃ）ドライブ、テープドライブなどが設けられたり、例えばＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）、ＩＥＥＥ１３９４、Ｂｕｌｕｅｔｏｏｔｈなどの通信方式による周辺機器とのインターフェースが設けられるようにしてもよい。
またマイクロホンや外部のヘッドホンの接続に用いられる端子や、ＤＶＤ再生時に対応するビデオ出力端子、ライン接続端子、光デジタル接続端子等が設けられてもよい。
またＰＣＭＣＩＡスロット、メモリカードスロットなどが形成され、外部の情報処理装置やオーディオ機器とデータのやりとりが可能とされてもよい。
【００３２】
２．本実施の形態のソフトウェア構成
図２は、上記図１に示したＨＤＤ２１にインストールされているソフトウェアについてのソフトウェア構造例を示している。
先ず、この図に示すようにして、ソフトウェア構造における最下層に、ＯＳが在るようにされる。周知のようにして、ＯＳは、情報処理装置を運用するのに必要とされる基本的なプログラムであり、後述するアプリケーションプログラムを管理し、また、各種データ及びハードウェアを管理する。
【００３３】
そして、このＯＳの上の階層に対して、１以上のアプリケーションプログラム（以降、単に「アプリケーション」ともいう）から成るとされる、アプリケーションプログラム層が位置することになる。このアプリケーションプログラム層を形成する各アプリケーションは、上記ＯＳにより管理されるようにして、ＯＳ上で動作する。各アプリケーションは、周知のようにして、或る特定の目的に従った機能が得られるようにしてそのプログラムが構築されている。
図１１に示したＣＰＵ１１は、ＯＳ上で起動されたアプリケーションのプログラムに従って処理を実行することができる。これにより、当該情報処理装置１は、そのアプリケーションが提供する機能を実行する機器として動作できることになる。
【００３４】
そして、本実施の形態においては、上記アプリケーションプログラム層に属するアプリケーションとして、先ずは、１つのコマンド管理アプリケーションが在るようにされる。また、コマンド管理アプリケーション以外のアプリケーションである、１以上の一般アプリケーションが在るようにされる。
【００３５】
この図に示す一般アプリケーションがどのようなものであり、また、いくつ存在するのかは、ユーザが情報処理装置１に対してどのようなアプリケーションを、どれだけインストールしたのかによって異なってくる。
例えば、一般アプリケーションの種類としては、Ｗｅｂブラウザ機能を有するアプリケーション、ワードプロセッサ機能を有するアプリケーション、静止画又は動画の画像編集処理を行う画像処理アプリケーションなどを挙げることができる。
また、特に本実施の形態の場合に対応しては、ＣＤドライブ１９によるＣＤについての再生操作をユーザが行うためのＣＤ再生アプリケーション、ＣＤから再生したオーディオデータをコンテンツファイルとしてＨＤＤ２１に記憶させ、また、このコンテンツファイルをＨＤＤ２１から再生させるためのリッピングアプリケーション、などもインストールされる。
【００３６】
詳しいことは後述するが、コマンド管理アプリケーションは、アプリケーションとして次のようなコマンド管理が可能なプログラムとして構成されている。
例えば外部からのイベントとしてＯＳが入力したコマンドが、そのときにアクティブとなっているアプリケーションが処理できるものでない場合がある。コマンド管理アプリケーションは、このような場合に対応してコマンド管理を実行させる。
つまり、コマンド管理アプリケーションは、上記コマンドについて処理が可能なアクティブではないアプリケーションを認識し、この非アクティブのアプリケーションに対してコマンドを転送するようにされる。これにより、非アクティブのアプリケーションに対してコマンドが入力された場合においても、この非アクティブのアプリケーションによってコマンドについての処理が実行されることになる。
【００３７】
このことから、コマンド管理アプリケーションは、アプリケーションプログラム層において、ＯＳと他の一般アプリケーションとの間に介在するようにして、アプリケーションプログラムが処理すべきコマンドについての管理を行う機能を有しているということがいえる。
また、本実施の形態のコマンド管理アプリケーションとしては、後述するようにして、登録された一般アプリケーションの起動／終了等を、ユーザ操作に応じてコントロールする、いわゆるランチャーとしての機能も与えることができる。
【００３８】
３．本実施の形態のアプリケーションにより得られる動作
上記した本実施の形態のコマンド管理アプリケーションにより得られる動作について、図３を参照して説明する。
図３は、ディスプレイモニタ１７の表示画面１７ａに表示されるＧＵＩ画像を示している。この場合には、一般アプリケーションとして、アプリケーションＡ、アプリケーションＢ、及びアプリケーションＣが起動されているものとする。
【００３９】
これに対応して、例えばこの場合には、各アプリケーションのアプリケーションウィンドウが開いた状態が示されている。
アプリケーションＡに対応しては、２つのウィンドウが表示されている。つまり、アプリケーションＡ・子ウィンドウＷ１と、アプリケーションＡ・親ウィンドウＷ２が表示されている。ここで、アプリケーションＡ・子ウィンドウＷ１は、アプリケーションＡ・親ウィンドウＷ２に対して階層的に１つ下にあるものとされる。従って、例えばアプリケーションＡ・親ウィンドウＷ２に対しては、その階層下にあるとされる子ウィンドウが並列的に複数存在していてもよい。但し、ここでは説明の便宜上、子ウィンドウについてはアプリケーションＡ・子ウィンドウＷ１を１つのみ示している。
【００４０】
また、アプリケーションＢに対応しては、１つのアプリケーションＢ・ウィンドウＷ３が表示されている。また、アプリケーションＣについても、１つのアプリケーションＣ・ウィンドウＷ４が表示された状態が示される。
【００４１】
ここで、本実施の形態のＯＳとしては、複数のアプリケーションが起動している状態では、アクティブとなるウィンドウは常に１つであるようにして管理している。そして、この場合には、アプリケーションＢ・子ウィンドウがアクティブとなっており、残るウィンドウは非アクティブとなっている。
【００４２】
この状態で、仮に本実施の形態としてのコマンド管理を採用しない場合には、次のようなコマンド対応処理となる。
つまり、図３に示す状態では、処理され得るコマンドは、アクティブとなっているアプリケーションＡに対応するものだけということになり、残るアプリケーションＢ，Ｃをはじめ、他のアプリケーションが処理可能なコマンドについては、処理することができない。但し、この場合には、アプリケーションＡ・子ウィンドウＷ１がアクティブとなっているから、処理され得るコマンドは、子ウィンドウＷ１が処理可能なコマンドのみとなる。つまり、同じアプリケーションＡが処理可能なコマンドであっても、これが親ウィンドウＷ２が処理すべきコマンドで、子ウィンドウＷ１が処理できるコマンドでない場合には、このコマンドに対応した処理は行われない。
【００４３】
しかしながら、本実施の形態としては、非アクティブとなっているアプリケーション、ウィンドウが対応するコマンドが入力された場合にも、このコマンドが無効にされることなく正常に処理されるようになっている。これは、次に説明するようにして、一般アプリケーションとコマンド管理アプリケーションによるコマンド管理機能に対応した処理によって実現される。
【００４４】
ここで、コマンド管理アプリケーションは、例えば、ＯＳが起動されたときに、常に自動的に起動するようになっている。そして、起動された状態では、図示するようにして表示画面上に対して、コマンド管理アプリケーション・アイコンＡ１を表示させるようになっている。そして、このコマンド管理アプリケーション・アイコンＡ１内には、後述する操作手順によって登録された一般アプリケーションを示すボタンアイコンが配置される。ここでは、アプリケーションＡ，Ｂ，Ｃがそれぞれ登録されているものとされ、これに対応して、アプリケーションＡ，Ｂ，Ｃを示す各ボタンアイコンＢＴ１，ＢＴ２，ＢＴ３が配置表示された状態が示されている。
【００４５】
このコマンド管理アプリケーション・アイコンＡ１は、ランチャー機能に対応するＧＵＩ画像とされる。つまりユーザは、このコマンド管理アプリケーション・アイコンＡ１内に表示されるボタンアイコンのうちから、所望のボタンアイコンを操作することで、そのボタンアイコンが示すアプリケーションを起動させることができる。また、所定操作によっては、既に起動されているアプリケーションを終了させることも可能とされる。
【００４６】
そして、このコマンド管理アプリケーション及び一般アプリケーションによるコマンド管理機能によっては、例えば次のような動作が得られる。
この図３に示す表示状態において、子ウィンドウがアクティブとなっているアプリケーションＡは、画像処理アプリケーションであるとする。また、非アクティブであるアプリケーションＢは、ＣＤドライブ１９に装填されたＣＤを再生するためのＣＤプレーヤアプリケーションであるとする。例えばユーザは、このＣＤプレーヤアプリケーションに対して操作を行うことで、ＣＤドライブ１９に装填されたＣＤの再生開始、一時停止、頭出し等をはじめとした各種再生に関する動作を実行させることができる。
そして、前述もしたように、本実施の形態の情報処理装置１にはリモートコントローラ２９が付属している。このリモートコントローラ２９を使用して、上記した画像処理アプリケーションやＣＤプレーヤアプリケーションに対する操作を行うことができる。また、操作入力部１５としての所定の操作子又は操作入力デバイスにより行うこともできる。
【００４７】
例えば、上記図３に示した状態の下で、アプリケーションＡとしての画像処理アプリケーションを対象として、在る特定の画像処理を実行させるための操作を行ったとする。この操作に応じて、ＯＳには特定の画像処理を指示するコマンドが入力される。ＯＳは、この入力したコマンドを現在アクティブとなっているウィンドウに渡す。
ここで、上記操作が指示する画像処理は、アプリケーションＡ・子ウィンドウＷ１が処理すべきものではなく、アプリケーションＡ・親ウィンドウＷ２が処理すべきものであったとする。
【００４８】
この場合、アクティブとなっているのは、アプリケーションＡ・子ウィンドウＷ１であり、アプリケーションＡ・親ウィンドウＷ２ではない。
しかしながら、本実施の形態としては、各一般アプリケーションは、受け渡されたコマンドが、そのときにアクティブとなっているウィンドウが処理すべきものでない場合には、このコマンドの処理を、同じアプリケーションが管理するその１階層上のウィンドウに受け渡すこととしている。
従って、この場合、アプリケーションＡ・子ウィンドウＷ１は、上記画像処理のための操作に応じて得られたコマンドを、そのアプリケーションＡ・親ウィンドウＷ２に渡すことになる。すると、アプリケーションＡ・親ウィンドウＷ２では、このコマンドについて処理を行う。つまり、ユーザ操作に応じた画像処理を実行することになる。
【００４９】
また、同じく、図３に示した状態の下で、ユーザは、ＣＤプレーヤアプリケーションに対する操作として、ＣＤ再生開始のための操作を行ったとする。この操作に応じては、ＣＤ再生を指示するコマンドがＯＳからアクティブとなっているウィンドウに渡すされる。
【００５０】
このときにも、アクティブとなっているのは、画像処理アプリケーションであるアプリケーションＡ・子ウィンドウＷ１である。
上記もしたように、本実施の形態に対応する一般アプリケーションは、アクティブとなっているウィンドウが処理すべきコマンドでない場合には、このコマンドの処理を、その１階層上のウィンドウに転送するようにしている。しかしながら、最上層のウィンドウにまで至っても、処理すべきコマンドでない場合には、コマンド管理アプリケーションに、そのコマンドを転送するようにされている。この場合、ＣＤ再生のコマンドを受けた画像処理アプリケーションであるアプリケーションＡでは、アプリケーションＡ・親ウィンドウＷ２も、このコマンドを処理できない。そして、この場合における最上層のウィンドウは、アプリケーションＡ・親ウィンドウＷ２である。従って、アプリケーションＡとしては、このコマンドをコマンド管理アプリケーションに渡すようにされる。
【００５１】
コマンド管理アプリケーションでは、後述するようにして、登録されたアプリケーションが処理可能なコマンドについての認識が可能とされている。
そこで、コマンド管理アプリケーションでは、上記のようにしてアプリケーションＡから取得したコマンドが、どの一般アプリケーションで処理可能であるのかを、登録されたアプリケーションの中から認識する。そして、認識したアプリケーションに対して、この取得していたコマンドを受け渡す。
つまり、図３の場合であれば、コマンド管理アプリケーションは、ＣＤプレーヤアプリケーションに対してコマンドを受け渡すことになる。ＣＤプレーヤアプリケーションは、受け取ったコマンドに応じてＣＤ再生を開始させる処理を実行させる。
【００５２】
上記した各動作は、ユーザにとって見れば、非アクティブとなっているウィンドウに対して操作を行っても、この操作に応じた動作が情報処理装置側で反応して得られているというように見えることになる。
これにより、例えばユーザは、情報処理装置１やリモートコントローラ２９などが故障しているのではないかなどと不安になることがない。また、所望の操作に応じた動作を情報処理装置に対して実行させるのにあたり、前もって、その操作対象となるアプリケーションやウィンドウをアクティブにする操作を行わなくてもよいことになる。
【００５３】
４．コマンド管理アプリケーションの構造概念
以降においては、上記したようなアプリケーションによるコマンド処理の動作を実現するための構成について、より詳細に説明していくこととする。先ず、コマンド管理アプリケーションの構造概念について説明しておく。
ここで、コマンド管理アプリケーションが、上記のようにして、受け渡されたコマンドを、このコマンドについての処理が可能とされるしかるべきアプリケーションに転送するためには、各アプリケーションが処理可能なコマンドを認識できることが必要とされる。
このために本実施の形態としては、非アクティブの状態でもコマンド入力に応じて動作させるべき一般アプリケーションを、コマンド管理アプリケーションに登録させることとする。
この登録は、ユーザによって行われることとする。つまり、ユーザは、非アクティブの状態でも操作に応じて動作させたいとする一般アプリケーションを任意に選択し、登録のための操作を行うようにされる。
【００５４】
図４のフローチャートに、ユーザによる上記一般アプリケーション登録のための操作手順と、この操作に応じたコマンド管理アプリケーションの動作を、フローチャートとして示す。
ここでは先ず、ステップＳ１により、ユーザの操作、作業として、一般アプリケーションを新規にＨＤＤ２１にインストールするところから始まっている。そして、インストールが行われた後の機会において、ユーザは、ステップＳ２として示すようにして、この新規にインストールした一般アプリケーションを、コマンド管理アプリケーションに登録するための操作を行うことができる。
この登録操作の実際としては、いくつか考えることができるが、例えば１つには、図３に示したコマンド管理アプリケーション・アイコンＡ１に、新規インストールされた一般アプリケーションの実行ファイルに相当するアイコンを、ドラッグ・アンド・ドロップさせるという操作とすることができる。
あるいは、コマンド管理アプリケーションとしてのＧＵＩに対する所定操作によって、登録のためのダイアログを表示させ、このダイアログに対する操作によって登録させるようにすることも考えられる。
【００５５】
そして、上記のようにして登録操作が行われたとすると、ステップＳ３に示すようにして、コマンド管理アプリケーションによる処理として、この登録操作によって登録対象となった一般アプリケーションについての登録ファイルを作成する。なお、登録ファイルの構造例については、後述する。そして、次のステップＳ５として示すようにして、この作成した登録ファイルを、ＨＤＤ２１に記憶させるようにする。この際には、例えば登録ファイル用に作成された所定のディレクトリに在るものとして管理されるようにしてＨＤＤ２１への記憶が行われるようにすればよい。
このようにして、登録ファイルが作成、保存されることで、一般アプリケーションの登録が完了したことになる。
【００５６】
そして図５は、上記登録ファイルと共に、コマンド管理アプリケーションの構造を模式的に示している。
先ず、この図５により登録ファイルの構造例について説明しておく。例えばこの図には、ＨＤＤ２１の所定のディレクトリに記憶される登録ファイルとして、アプリケーションＡ，Ｂ，Ｃの３つに対応した登録ファイルが示されている。これらの登録ファイルの各々は、図示するようにして、例えば、実行ファイルディレクトリ情報Ｄ１、アイコン画像データＤ２、及びコマンド識別テーブルＤ３とから成る。
【００５７】
実行ファイルディレクトリ情報Ｄ１は、登録された一般アプリケーションとしての実行ファイルの実体（若しくはエイリアス）の識別子と、この実行ファイルの実体（若しくはエイリアス）が保存されているＨＤＤ２１上のディレクトリとを対応付けた情報とされる。この実行ファイルディレクトリ情報Ｄ１を参照することで、ＨＤＤ２１における実行ファイルの保存先を特定することができる。
また、アイコン画像データＤ２は、例えば、登録された一般アプリケーションとしての実行ファイルに対応するアイコン画像のデータである。
そして、コマンド識別テーブルＤ３は、登録された一般アプリケーションが処理可能なコマンドコードをテーブル化して格納した情報とされる。
【００５８】
これらの情報は、先の図４におけるステップＳ３において作成され、登録ファイルを形成することになる。
実行ファイルディレクトリ情報Ｄ１は、図４のステップＳ２として示した登録操作時において、登録対象の一般アプリケーションの識別子及びディレクトリが認識されるので、これらの情報を基に作成可能である。
また、アイコン画像データＤ２も、登録操作時において、例えばドラッグ・アンド・ドロップされたアイコンの画像データを取得することで作成できる。
コマンド識別テーブルＤ３をどのようにして作成するのかについては、いくつか考えられるが、例えば次のような手法により作成することができる。
つまり、コマンド管理アプリケーションとしての処理により、登録対象とされた一般アプリケーションのプログラムの記述内容を解析する。そして、この解析したプログラムに記述されているコマンドコードを抽出してテーブル化するものである。
あるいは、一般アプリケーション側で、コマンド管理アプリケーションにより管理してもらうべきコマンドのリストを有していることとし、コマンド管理アプリケーションが、このリストの情報を取得してコマンド識別テーブルＤ３を作成できるように構成することも考えられる。
【００５９】
そして、同じく図５に示すようにして、本実施の形態のコマンド管理アプリケーションとしては、前述したランチャー機能処理ブロックＢ１としてのプログラムと、コマンド管理処理ブロックＢ１としてのプログラムと、さらに、ＡＰＩ処理ブロックＢ３としてのプログラムから成るものとされる。
【００６０】
ランチャー機能処理ブロックＢ１は、図示するようにして各一般アプリケーションの登録ファイルを参照することで、図３により説明したようなランチャーとしての機能を実現する。
つまり、アイコン画像データＤ２を参照することによっては、図３に示したコマンド管理アプリケーション・アイコンＡ１内の各ボタンアイコンを表示させることができる。また、実行ファイルディレクトリ情報Ｄ１を参照することによっては、例えばボタンアイコン操作に応じて、一般アプリケーションを起動させることができる。
【００６１】
同様にして、コマンド管理処理ブロックＢ２も、各一般アプリケーションの登録ファイルを参照することでコマンド管理機能を実現する。つまり、各登録ファイル内のコマンド識別テーブルＤ３を参照することで、受け取ったコマンドを処理すべき一般アプリケーションを認識することができる。
【００６２】
また、ＡＰＩ処理ブロックＢ３は、所定のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）に従って、一般アプリケーションとの通信を実行するためのプログラムであり、このＡＰＩ処理ブロックＢ３により、例えばランチャー機能処理ブロックＢ１による一般アプリケーションの起動／終了等のイベントを一般アプリケーションに通知する。また、コマンド管理処理ブロックＢ２が指定する一般アプリケーションへのコマンドの転送処理が行われる。
【００６３】
５．処理動作
５−１．ＯＳによる処理動作
続いては、図３により説明したコマンド管理を実現するためのプログラム処理について説明していくこととし、先ずは、ＯＳに従ったコマンド対応処理について説明する。
図６のフローチャートは、ＯＳによるコマンド対応処理を示している。この図に示す処理は、ＣＰＵ１１が、ＯＳとしてのプログラムを実行することで得られるものである。
【００６４】
本実施の形態では、操作入力部１５から出力される操作情報信号、又は受信部２８により受信したリモートコントローラ２９からの操作情報信号が入力処理部１４によりコマンドに変換され、ＣＰＵ１１に転送される。つまり、操作入力部１５やリモートコントローラ２９に対して行われた操作は、外部イベントとして扱われ、ＣＰＵ１１は、この外部イベントに応じたコマンドを入力するものである。
【００６５】
図６に示すステップＳ１０１においては、先ず、上記したコマンドが入力されるのを待機している。そして、コマンドの入力が得られたことを判別するとステップＳ１０２の処理に進む。
ステップＳ１０２においては、現在のアクティブウィンドウを認識するようにされる。アプリケーション又はウィンドウをアクティブにする管理は、ＯＳが行っているから、この場合の処理としては、自身が現在設定しているアクティブなウィンドウが何であるのかを認識するようにすればよい。
そして、次のステップＳ１０３においては、上記ステップＳ１０２により認識したアクティブウィンドウに対して、ステップＳ１０１の処理に対応して入力したコマンドを受け渡す処理を行う。
【００６６】
５−２．一般アプリケーションによる処理動作
続いては、一般アプリケーションによるコマンド対応処理について、図７のフローチャートを参照して説明を行う。この図に示す処理は、アクティブとなっている一般アプリケーションとして、アクティブウィンドウに対応するプログラムが、上記図６に示した処理によってＯＳからコマンドを受け取ったときに開始される。
【００６７】
この図７においては、先ずステップＳ２０１により、コマンドの受信を待機している。ここで受信されるコマンドは、先の図６におけるステップＳ１０３の処理によってＯＳから受け渡されるコマンドと、以降説明する処理の結果、親ウィンドウに渡されたコマンドの何れかとなる。ただし、最初のステップＳ２０１の処理にて受信されるコマンドは、ＯＳからアクティブウィンドウに対して受け渡されたものとなる。
そして、例えば最初のステップＳ２０１の処理として、アクティブウィンドウが、ＯＳからコマンドを受け取るとステップＳ２０２の処理に移行する。
【００６８】
ステップＳ２０２においては、受け取ったコマンドに対応する処理がこのウィンドウ内に存在するか否かについて判別する。つまりは、現ウィンドウが、このコマンドを処理可能であるか否かについて判別するものである。このためには、例えば、受け渡されたコマンドのコードを解析する。そして、現ウィンドウ内で実行可能なコマンド応答処理を発現させるコマンドのコードと、受け渡されたコマンドのコードとを比較参照する。一致したコマンコードがあれば、コマンドコードが処理可能であることになり、ステップＳ２０２では肯定結果が得られる。これに対して、一致したコマンドコードがなくコマンドの処理ができないとされる場合には否定結果が得られる。
【００６９】
ステップＳ２０２において肯定結果が得られた場合には、ステップＳ２０３の処理によって、受け渡されたコマンドに応答した処理を実行する。
これに対してステップＳ２０２において否定結果が得られた場合には、ステップＳ２０４の処理に進む。
【００７０】
ステップＳ２０４においては、現ウィンドウの１つ上の階層にあるウィンドウである、親ウィンドウが存在するか否かについて判別している。現ウィンドウは、自身の親ウィンドウとのリンクの情報を持つようにされているから、例えばこの情報に基づいて親ウィンドウの存在の有無を認識できる。そして、親ウィンドウが存在するとして肯定結果が得られたのであれば、ステップＳ２０５に進む。ステップＳ２０５においては、親ウィンドウに対して先のステップＳ２０１の処理により受け取ったコマンドを親ウィンドウに受け渡す。
これまでの処理は、例えば図３の場合であれば、先ず、アプリケーションＡ・子ウィンドウＷ１にて、ＯＳから受け渡されたコマンドが処理できないと判定したことにより、このアプリケーションＡ・子ウィンドウＷ１が、その１つ上の階層のウィンドウである、アプリケーションＡ・親ウィンドウＷ２にコマンドを受け渡すという動作に対応する。
【００７１】
ステップＳ２０５の処理により親ウィンドウにコマンドが受け渡されると、次には、この親ウィンドウが、現ウィンドウとしてステップＳ２０１の処理を実行し、コマンドが受信されることを判別することとなる。親ウィンドウは非アクティブであるが、このステップＳ２０１によりコマンドを受信したことを判別すると、ステップＳ２０２以降の処理を実行することになる。
【００７２】
また、先のステップＳ２０４において、現ウィンドウに対する親ウィンドウが存在しないことを判別した場合には、ステップＳ２０６の処理に移行する。ステップＳ２０６においては、現ウィンドウが、コマンド管理アプリケーションの管理下にあるか否かを判別する。つまり、このウィンドウの一般アプリケーションについて、先に図４及び図５により説明したようにして、管理アプリケーションに登録されているか否かについて判別を行う。
このためには、例えば一般アプリケーションにおけるコマンド管理アプリケーション対応のプログラムとして、自身がコマンド管理アプリケーションに登録されているか否かを認識できるようにする仕組みが必要となる。そこで、例えば一般アプリケーションは、登録されたときに登録されたことを示すフラグを持つようにすることが考えられる。また、ステップＳ２０６としての処理実行時には、管理アプリケーションと所定のＡＰＩにより通信を行って、自己のアプリケーションが登録されているか否かを問い合わせるようにしてもよい。
【００７３】
そして、ステップＳ２０６において、現ウィンドウが、コマンド管理アプリケーションの管理下にあると判別した場合には、ステップＳ２０７の処理に進む。ステップＳ２０７においては、この現ウィンドウが先のステップＳ２０１にて、ＯＳ又は子ウィンドウから受け渡されたとされるコマンドを、コマンド管理アプリケーションに対して受け渡す。
なお、このステップＳ２０６にて、現ウィンドウが、コマンド管理アプリケーションの管理下には無いとして否定結果を得た場合には、このまま、一般アプリケーションによるコマンド対応処理は終了する。これは、例えばコマンド管理アプリケーションに登録されていない一般アプリケーションに対して、自己が処理すべきコマンドが受け渡された場合の処理結果となる。この場合には、イベントとして入力されたコマンドは、処理されずに無効となる。
【００７４】
５−３．コマンド管理アプリケーションによる処理動作
続いては、コマンド管理アプリケーションによるコマンド対応処理について、図８のフローチャートを参照して説明を行う。この図に示す処理は、図５に示したランチャー機能処理ブロックＢ１、コマンド管理処理ブロックＢ２、及びＡＰＩ処理ブロックとしてのプログラムに従って、ＣＰＵ１１が処理を実行することで実現される。
【００７５】
先ずステップ３２０１において、先の図７のステップＳ２０７の処理によって一般アプリケーションから受け渡されたコマンドを受信するのを待機しており、コマンドを受信したことを判別するとステップＳ３０２の処理に進む。
【００７６】
ステップＳ３０２においては、受信したコマンドが処理すべきアプリケーションを判定する。
コマンドとしては、例えば一般アプリケーションのみではなく、このコマンド管理アプリケーションが実行すべきものが含まれる可能性がある。例えばランチャー機能に関連して、ユーザ操作に応じて、アプリケーション指定して起動させるためのコマンドなども受信される可能性があるということである。
そこで、ステップＳ３０２においては、先ず、コマンド管理アプリケーション自身が処理すべきコマンドであるのかを判別する。そして、コマンド管理アプリケーション自身が処理すべきコマンドではないと判別した場合に、コマンド管理アプリケーションに登録された一般アプリケーションのうちから、受信したコマンドを処理すべきアプリケーションを判定するようにされる。
【００７７】
ここで、図４に示したように、コマンド管理アプリケーションは、登録されたアプリケーションごとの登録ファイルを管理し、この登録ファイルには、その登録アプリケーションが処理可能なコマンドコードを示すコマンド識別テーブルＤ３が格納されている。
そこで、ステップＳ３０２において、登録された一般アプリケーションのうちから、受信したコマンドを処理すべきアプリケーションを判定するのにあたっては、受信したコマンドのコードと、各登録ファイルのコマンド識別テーブルＤ３に格納されたコマンドコードとを比較参照する。これにより、受信したコマンドのコードに一致したコマンドコードを格納したコマンド識別テーブルＤ３が特定される。さらに、この特定されたコマンド識別テーブルＤ３を格納する登録ファイルが特定される。そして、この登録ファイルが対応するアプリケーションが、受信したコマンドを処理すべきアプリケーションであるとして判定できることになる。
【００７８】
次のステップＳ３０３では、上記ステップＳ３０２の判定結果に基づいて、受信したコマンドについて、コマンド管理アプリケーション自身が処理すべきものであるか否かについての判別を行う。そして、自身が実行すべきコマンドであるとして肯定結果を得た場合にはステップＳ３０７の処理に進む。
ステップＳ３０７の処理としては、コマンド管理アプリケーション自身が、受信したコマンドに応答した処理を実行する。
【００７９】
これに対して、ステップＳ３０３において、自身が実行すべきコマンドではないとして否定結果を得た場合にはステップＳ３０４以降の処理に進む。ステップＳ３０４以降の処理に進む場合とは、先のステップＳ３０２にて、コマンド管理アプリケーションに登録された一般アプリケーションのうちから、受信したコマンドを処理すべきアプリケーションが判定された場合となる。
【００８０】
そして、ステップＳ３０４では、受信したコマンドを処理すべき一般アプリケーションが起動中にあるか否かを判別する。この場合、コマンド管理アプリケーションは、ランチャーとしての機能を有しているものとされているから、登録された一般アプリケーションが起動中にあるか否かについては、自己が管理している。従って、例えば、ランチャー機能処理ブロックＢ１において現在管理しているアプリケーションごとの起動状況を参照することで、ステップＳ３０４としての判別は可能である。
【００８１】
そして、ステップＳ３０４において、受信コマンドを処理すべきアプリケーションが起動されていると判別した場合には、ステップＳ３０５の処理をスキップしてステップＳ３０６の処理に進む。これに対して、受信コマンドを処理すべきアプリケーションが起動されていないと判別した場合には、ステップＳ３０５の処理を実行してからステップＳ３０６の処理に進む。
【００８２】
ステップＳ３０５においては、コマンド管理アプリケーションにおけるランチャー機能処理ブロックＢ１としてのプログラムにより、受信コマンドを処理すべきアプリケーションを起動させるための処理を実行する。これにより、アプリケーションはＯＳ上で起動し、以降は、コマンド対応処理を実行可能となる。
このような処理によると、本実施の形態としては、起動されていない一般アプリケーションが処理すべきコマンドが入力されたときには、この一般アプリケーションが自動的に起動され、そして、入力されたコマンドに応じた処理が実行されることになる。
【００８３】
そして、ステップＳ３０６においては、受信したコマンドを、ステップＳ３０２で判定したアプリケーションに対して受け渡す。
このコマンドが受け渡されたアプリケーションは、先に説明した図７の処理を実行することになる。そしてこの場合には、ステップＳ２０３又はステップＳ２０５の処理によって、このアプリケーションによりコマンドの処理が行われることとなる。
【００８４】
これまでの説明によると、一般アプリケーションとしては、図７に示したようにして、ウィンドウの階層ごとに自身が処理すべきコマンドであるか否かについて判定を行って、自身が処理すべきコマンドであれば処理を行うようにされる。つまり、これによっては、同一のアプリケーション上で、非アクティブとなっているウィンドウが存在する場合にも、この非アクティブのウィンドウにより、コマンド入力に対応した処理を実行できるようになっている。
また、コマンド管理アプリケーションとしては、図８に示したようにして、アクティブなアプリケーションが処理できないとして受け渡したコマンドを、登録された一般アプリケーションのうちから、このコマンドが処理可能なアプリケーションに転送するようにしている。
そして、ＯＳによるコマンド対応処理を図６に示したが、この処理は、入力コマンドをアクティブウィンドウに渡すというものであり、例えば従来と特に変わるところはない。
【００８５】
このことから、本実施の形態としてのコマンド管理は、一般アプリケーションとコマンド管理アプリケーションとの連携により実現されているということが分かる。
従来の問題点として前述もしたように、非アクティブのアプリケーション、ウィンドウに対して、コマンド処理を実行させるようにＯＳを構成するとした場合には、そのプログラムが非常に複雑となって重くなり、現実的ではないということがいえる。
これに対して本実施の形態では、非アクティブのアプリケーション、ウィンドウに対してコマンド処理を実行させるコマンド管理を、コマンド管理アプリケーションと、一般アプリケーションの連携によって実現している。従って、図７にも示されているように、ＯＳとしては、従来のコマンド対応処理を行えばよい。つまり、ＯＳについては、本実施の形態のコマンド管理を実現するのに対応して、特にプログラム構成を変更する必要はない。
【００８６】
また、コマンド管理アプリケーションについては、登録された一般アプリケーションの登録ファイルとしての情報に基づいて、しかるべきアプリケーションにコマンドの受け渡しを行う構成とされているが、１つのアプリケーションとして、このようなプログラムを作成することは、特に困難なことではない。
【００８７】
また、一般アプリケーションが有するべきコマンド管理としては、同一アプリケーションのウィンドウ間でコマンドを授受し、コマンドを処理可能なウィンドウが存在しない場合には、コマンドを管理アプリケーションに受け渡すという、比較的単純な動作が実現されればよい。そして、このような動作実現のための処理が実行されるように、プログラムの追加、変更を行えばよい。このようなプログラムの追加、変更も、容易に行うことができる。
また、このような一般アプリケーションにおけるコマンド管理機能は、予め、プログラムの一部として組み込まれるようにしてもよい。また、図７に示したようなコマンド管理機能を追加するためのパッチプログラム、プラグインファイルのようなものを用意し、ユーザが、適宜これを入手してインストールすることで、機能追加ができるようにすることも考えられる。
【００８８】
ところで、上記した各処理を実現するためのプログラムは、前述もしたように、情報処理装置１では、ＨＤＤ２１のに予め記憶して格納しておくものである。あるいは、メモリ部１３内のＲＯＭに格納されていても良い。
あるいは、プログラムは、フレキシブルディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＭＯ（Ｍａｇｎｅｔ Ｏｐｔｉｃａｌ）ディスク、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウェアとして提供することができる。例えば、本実施の形態であれば、ＣＤ−ＲＯＭにプログラムを記録し、パッケージソフトウェアとして提供することができる。これにより、情報処理装置１では、ＣＤドライブ１９によりプログラムを読み出し、メモリ部１３内のＲＯＭに記憶させることでインストールできる。
なお、プログラムは、上記のようなリムーバブルな記録媒体からインストールする他、プログラムを記憶しているサーバなどから、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワークを介してダウンロードすることもできる。
【００８９】
また、本発明としては、上記した実施の形態としての構成に限定されるものではない。例えば、本発明としてのイベント管理が行われる機器としては、図１に示した情報処理装置１としての構成に限定されるものではない。つまりは、上記したＡＶ機能に対応した情報処理装置としての構成だけではなく、例えばこのようなＡＶ機能に対応した装置部分を備えない、汎用のパーソナルコンピュータにも適用することが可能とされる。また、ＯＳ上で複数のアプリケーションを起動させることで各種の機能を実現するように構成された各種電子機器に適用できる。
また、本発明としてのコマンド管理のために、コマンド管理アプリケーション及び他の一般アプリケーションが実行する処理ステップについても、図６〜図８に示したもののみに限定される必要はなく、必要に応じて変更可能である。さらには、コマンド管理アプリケーションによる管理の仕組みも、図５に示したプログラム構成、及び登録ファイルの構造などに限定されるものではない。
特に、本発明としては、コマンド管理アプリケーションは、コマンド管理が行うことを主目的としているから、実施の形態で説明したランチャー機能は省略しても構わない。この場合、例えば、図３に示したようなコマンド管理アプリケーション・アイコンＡ１を表示出力させる必要は、必ずしもない。この場合、コマンド管理アプリケーションとしては、各種操作が可能なＧＵＩ画像表示を伴わない、バックグラウンド的に動作するアプリケーションとして構成することができる。
【００９０】
【発明の効果】
以上説明したように本発明は、プログラムとして、オペレーションシステムと、このオペレーションシステム上で動作する各種のアプリケーションプログラムに加え、アプリケーションプログラムとしてのコマンド管理アプリケーションが存在する。
そのうえで、コマンド対応処理として、アクティブなアプリケーションが、オペレーションシステムから転送されたコマンドについて処理できないと判断したときには、このコマンドをコマンド管理アプリケーションに転送するようにされる。そして、コマンド管理アプリケーションでは、転送されたコマンドを、このコマンドを処理することのできる非アクティブのアプリケーションに転送する。
【００９１】
上記のようなコマンド処理の構成を採ることで、本発明としては、非アクティブのアプリケーションによりコマンド処理を実行させることが可能となる。これにより、例えばユーザが、非アクティブのアプリケーションを対象として操作を行ったとしても、機器側では、この操作に応答した動作が行われることになるから、機器についての操作性及び信頼性が向上する。
【００９２】
また、本発明によると、上記したコマンド管理は、アプリケーションと他のアプリケーションとの連携によって実現されるということがいえる。これは即ち、ＯＳについては、従来と同様のコマンド対応処理を行う構成とすればよく、特に、本発明としてのコマンド管理に構成を採るのに応じて、変更を与える必要はないということになる。これにより、ＯＳのプログラム構造としては、複雑化、肥大化することがなく、ＯＳとしてのプログラム作成が困難になることが避けられる。
そしてまた、従来と同様のコマンド対応処理でよいということは、本発明としてのコマンド管理の構成は、幅広い種類のＯＳに適用できることにもなるという汎用性も有しているということがいえる。
【００９３】
また、上記構成のもとで、あるアプリケーションがコマンドを受け取ったときに、このコマンドがアクティブウィンドウで処理できない場合は、これより上位の非アクティブのウィンドウにコマンドを転送するようにされる。そして、コマンドを処理可能な上位階層のウィンドウがこれ以上はないとされる場合に、上記コマンド管理アプリケーションに対してコマンドを転送するようにされる。
この構成であれば、１つのアプリケーションにより複数のウィンドウが開かれている状況のもとで、非アクティブのウィンドウが処理すべきコマンドが入力されたときには、この非アクティブのウィンドウによってコマンドを処理させることが可能になる。この場合も、非アクティブのウィンドウに対する操作に反応して機器が動作することになるから、先の場合と同様に、操作性及び信頼性が向上されるものである。また、この構成においても、ＯＳについて特に変更が与えられることはない。
【図面の簡単な説明】
【図１】本発明の実施の形態としての情報処理装置の構成例を示すブロック図である。
【図２】実施の形態の情報処理装置のＨＤＤにインストールされるソフトウェアの構造例を示す概念図である。
【図３】本実施の形態におけるコマンド管理により得られる動作を説明するための、ＧＵＩ画面の表示態様例を示す説明図である。
【図４】コマンド管理アプリケーションへのアプリケーション登録手順を示すフローチャートである。
【図５】コマンド管理アプリケーションの構造例を示す概念図である。
【図６】本実施の形態のＯＳにより実行されるコマンド対応処理を示すフローチャートである。
【図７】本実施の形態の一般アプリケーションにより実行されるコマンド対応処理を示すフローチャートである。
【図８】本実施の形態のコマンド管理アプリケーションにより実行されるコマンド対応処理を示すフローチャートである。
【符号の説明】
１ 記録再生装置、１１ ＣＰＵ、１３ メモリ部、１４ 操作入力部、１５入力処理部、１６ 表示処理部、１７ ディスプレイモニタ、１８ ＣＤドライブ制御部、１９ ＣＤドライブ、２１ ＨＤＤ、２２ 通信処理部、２３ ネットワークインターフェイス、２４ オーディオデータ処理部、２５ スピーカ、２６ アンテナ、２７ チューナ、Ｄ１ 実行ファイルディレクトリ情報、Ｄ２ アイコン画像データ、Ｄ３ コマンド識別テーブル、Ｂ１ ランチャー機能処理ブロック、Ｂ２ コマンド管理処理ブロック、Ｂ３ ＡＰＩ処理ブロック
【発明の属する技術分野】
本発明は、外部からのイベントに応じて入力されるコマンドに対応して処理を実行する情報処理装置、及び情報処理方法に関する。また、このような情報処理装置、及び情報処理方法が実現されるようにするためのプログラム、及びこのプログラムが記憶される記憶媒体に関する。
【０００２】
【従来の技術】
近年においては、例えばパーソナルコンピュータが広く普及してきている。このようなパーソナルコンピュータには、ＯＳ（Ｏｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ）上で動作するプログラム単位である、各種のアプリケーションプログラムがインストールされる。そして、ユーザは、これらのアプリケーションプログラムを複数起動させて、これらのアプリケーションプログラムを使用することができる。なお、以降においては、アプリケーションプログラムについては、略して「アプリケーション」ともいうこととする。
【０００３】
また、上記のようにして複数のアプリケーションを起動させた場合、ユーザは、アクティブとなっているアプリケーションに対してのみ、イベント入力（操作）が可能なようになっている。アクティブとなっているアプリケーションは、例えば表示画面に表示されるＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）画像上では、そのアプリケーションのウィンドウが、所定態様による強調表示が行われるなどして、他の非アクティブとなっているアプリケーションのウィンドウとの区別が行われる。また、アクティブとなっているアプリケーションは、一般には、１つであるようにしてＯＳによる管理が行われる。
【０００４】
【発明が解決しようとする課題】
上記したように、ユーザによる操作入力に応答できるのは、アクティブとなっているアプリケーションのみとされる。これは、ＯＳ及びアプリケーションの仕組みとして、次のようになっていることに依る。
つまり、ＯＳとしては、外部からのイベントに基づいて入力したコマンドを、常に現在アクティブとなっているアプリケーションに渡すようにされる。そして、アクティブなアプリケーションでは、受け渡されたコマンドについて自己が処理すべきものであれば、そのコマンドに従った処理を実行させる。これに対して、コマンドについては自己が処理すべきものでない場合には、特に処理は実行せずに、そのコマンドを無効とするのである。
【０００５】
上記のような仕組みとされていることで、ユーザは、非アクティブとなっているアプリケーションに対して、直接的に入力操作を行うことはできないということになる。
このようなことは、例えばユーザが一般にマウスやキーボードを操作してパーソナルコンピュータを使用している場合には、これらの入力デバイスによるＧＵＩ画像への直接的な操作によってアクティブなアプリケーションの切り換えを直ぐに行うことができるから、これまで特に問題とはなっていなかったものである。
【０００６】
しかしながら、近年のパーソナルコンピュータなどにおいては、例えばテレビジョンチューナのほか、ＣＤプレーヤをはじめとするメディアプレーヤなどを搭載することで、相当に充実したＡＶ機能を有するものが普及してきている。そして、このようなパーソナルコンピュータでは、上記したＡＶ機能に対応した操作が可能なリモートコントローラを備えるものも知られるようになってきている。つまり、リモートコントローラに対する操作に応じて、パーソナルコンピュータ側では、テレビジョンチューナにおけるチャンネルの選局制御を行ったり、また、メディアプレーヤの記録再生動作を制御するものである。
一例ではあるが、操作態様として、上記のようしてリモートコントローラにより操作を行う場合に、上記した操作性等の問題が顕著となるものである。この点について次のような動作例を挙げて説明しておく。
【０００７】
ここで、パーソナルコンピュータにはメディアプレーヤが搭載されており、このパーソナルコンピュータには、上記メディアプレーヤについての記録再生を行うためのメディアプレーヤ対応アプリケーションがインストールされていることとする。また、画像処理アプリケーションもインストールされているものとする。そして、例えば現在においては、上記した２つのアプリケーションが起動されているうえで、アクティブとなっているのは、画像処理アプリケーションであるとする。
【０００８】
この状態の下で、ユーザがリモートコントローラを操作して、メディアプレーヤに装填されたメディアを再生するための操作を行ったとする。パーソナルコンピュータ側のＯＳでは、上記操作に応じてリモートコントローラから送信された信号を受信し、再生コマンドとして取得することになる。つまり、ＯＳでは、リモートコントローラからの送信信号の受信をイベントとして受け付け、この送信信号に基づいた再生コマンドを取得する。
このとき、アクティブとなっているアプリケーションは、画像処理アプリケーションとなっている。このため、ＯＳは、受信取得した再生コマンドを、メディアプレーヤ対応アプリケーションではなく、画像処理アプリケーションに渡すことになる。
この再生コマンドは、メディアプレーヤ対応アプリケーションが処理すべきコマンドであり、画像処理アプリケーションが処理すべきコマンドではない。従って、上記再生コマンドを受け取った画像処理アプリケーションでは、このコマンドを無効として、特に対応した処理は実行しないことになる。
【０００９】
これは、リモートコントローラを再生するユーザにとってみれば、再生操作を行ったのにも関わらず、メディアプレーヤによるメディア再生が開始されないというようにして捉えることになる。つまり、ユーザがリモートコントローラに対して行った操作に、パーソナルコンピュータが反応していないものとして受け取られることになる。
このような動作をみたユーザによっては、パーソナルコンピュータ又はリモートコントローラが故障しているのではと考える場合も出てくる可能性がある。
また、メディアプレーヤ対応アプリケーションがアクティブではなかったから、このような動作になったのだということをユーザが理解しているとしても、リモートコントローラに対する操作に応じて、即座にパーソナルコンピュータ側が反応した動作を行わないというのは、操作感上での違和感を覚えることになる。また、操作性がよくないと感じることにもなり、機器としての信頼性を損なう可能性がある。
【００１０】
このようにして、現状における外部イベントに対応したパーソナルコンピュータなどのコマンド対応処理の仕方では、良好な操作性が得られないことで信頼性を欠く場合があるという問題を有しているものである。特に、例えば上記したように、例えばリモートコントローラなどのようにして、これまでのマウス、キーボード以外の多様な入力デバイスによる入力に対応するようになってきている背景を考慮すれば、この問題は解決されるべき大きな課題になっているといえる。
【００１１】
そこで、例えばアプリケーションを管理するＯＳにより、コマンド管理を実行させるように構成することが考えられる。つまり、ＯＳは、入力されたコマンドが、どのアプリケーションで処理すべきなのかを認識する。そして、この認識結果に基づいて、そのアプリケーションによりコマンドに対応した処理を実行させるものである。
しかしながら、上記のような構成を採ろうとすれば、ＯＳについて、膨大な数のコマンドを理解できるようにしたうえで、これらコマンドの間でのコリジョンなどが生じないようにしてプログラムを作成する必要がある。
このようなプログラムを作成することは非常に困難であり、現実的ではない。つまり、アプリケーションは現在において、また将来的にも実に多様に存在するから、これらに全て対応することは不可能に近い。また、例えばいくつかのアプリケーションに限定してこのようなプログラム構成のＯＳを作成するとしても、やはり、プログラム作成についての困難がつきまとう。
【００１２】
ちなみに、現状におけるＯＳが、入力したコマンドの内容に関わらず、常に、アクティブとなっているアプリケーションにそのコマンドを転送するイベント処理としているのは、この理由が大きい。
つまり、現状におけるＯＳのイベント処理は、ユーザによりアクティブなアプリケーションを選択させたうえで、ユーザに対して、このアクティブとしたアプリケーションが処理すべきコマンドを送信してもらうことを前提としている。このようなことを前提としたイベント処理であれば、ＯＳについての複雑化を避け、かつ、ＯＳに対応可能な多くのアプリケーションを確保することができるわけである。
【００１３】
【課題を解決するための手段】
そこで本発明は、先に述べた課題を考慮して、例えば非アクティブとなっているアプリケーションに対するコマンドが入力されたときにも、このコマンドに応答して上記非アクティブとなっているアプリケーションがコマンド処理できるようにして、これまでよりも操作性が向上されるようにすることを目的とする。また、この目的を実現するのにあたっては、オペレーションシステムのプログラムが複雑にならないようにすることも目的とする。
【００１４】
そして、情報処理装置としては次のように構成することとした。
つまり、複数のアプリケーションプログラムと、これら複数のアプリケーションプログラムを管理するプログラムであるオペレーティングシステムと、上記オペレーティングシステムにより管理される上記アプリケーションプログラムの１つであり、他のアプリケーションプログラムに対応する各コマンドを管理可能とされるコマンド管理アプリケーションとが記憶される記憶手段を備える。
また、外部から与えられるイベントをコマンドとして入力する入力手段を備える。
そして、記憶手段に記憶されたプログラムを実行することによって、オペレーティングシステムが入力手段により入力されたコマンドをアクティブなアプリケーションに転送し、アクティブなアプリケーションプログラムが上記コマンドに対応する処理を実行できないと判定したときに、コマンド管理アプリケーションに上記コマンドを転送し、コマンド管理アプリケーションがコマンドに対応する処理を実行可能な非アクティブなアプリケーションプログラムに上記コマンドを転送し、非アクティブなアプリケーションプログラムが上記コマンドに対応する処理を実行するようにされた実行処理手段とを備えることとした。
【００１５】
また、情報処理方法としては次のように構成することとした。
つまり、複数のアプリケーションプログラムと、これら複数のアプリケーションプログラムを管理するプログラムであるオペレーティングシステムと、オペレーティングシステムにより管理されるアプリケーションプログラムの１つであり、他のアプリケーションプログラムに対応する各コマンドを管理可能とされるコマンド管理アプリケーションとを情報処理装置に記憶させておく。
そのうえで、オペレーティングシステムが外部からのイベントに応じて入力されたコマンドをアクティブなアプリケーションに転送する第１の転送ステップと、アクティブなアプリケーションプログラムが上記コマンドに対応する処理を実行できないと判定したときに、コマンド管理アプリケーションに上記コマンドを転送する第２の転送ステップと、コマンド管理アプリケーションが上記コマンドに対応する処理を実行可能な非アクティブなアプリケーションプログラムに上記コマンドを転送する第３の転送ステップと、非アクティブなアプリケーションプログラムが上記コマンドに対応する処理を実行する実行ステップとを実行するように構成することとする。
【００１６】
また、上記コマンド管理アプリケーション以外の他のアプリケーションプログラムに相当するプログラムとしては次のように構成する。
つまり、自己がアクティブな状態である場合に、オペレーションシステムとしてのプログラムが転送してきた、外部からのイベントに応じて入力されたコマンドについて、自己が処理を実行可能であるか否かを判定する判定ステップと、この判定ステップにより、上記コマンドについて処理を実行できないと判定した場合には、上記コマンドに対応する処理をすべき非アクティブなアプリケーションプログラムに対して上記コマンドを転送可能なコマンド管理アプリケーションに、上記コマンドを転送する転送ステップとを情報処理装置に実行させるように構成する。
【００１７】
また、上記コマンド管理アプリケーションに相当するプログラムとして発議のように構成する。
つまり、外部イベントに対応してオペレーティングシステムから転送されたコマンドに対応する処理を実行できないアクティブなアプリケーションプログラムから転送されてきた上記コマンドを、上記コマンドに対応する処理が可能な非アクティブなアプリケーションプログラムに転送する転送ステップを情報処理装置に実行させるように構成するものである。
【００１８】
また、上記各プログラムを記憶することで、本発明としての記憶媒体を構成することとした。
【００１９】
上記各構成によれば、プログラムとして、オペレーションシステムと、このオペレーションシステム上で動作する各種のアプリケーションプログラムに加え、アプリケーションプログラムとしてのコマンド管理アプリケーションが備えられる。
そのうえで、オペレーションシステムは、外部イベントとして入力したコマンドを、先ずアクティブなアプリケーションに転送するようにされる。そして、このアクティブなアプリケーションが、このコマンドについて処理できないと判断したときには、このコマンドをコマンド管理アプリケーションに転送するようにされる。
コマンド管理アプリケーションでは、転送されたコマンドを、さらに、このコマンドを処理することのできる非アクティブのアプリケーションに渡し、この非アクティブのアプリケーションによりコマンド処理を実行させるようにしている。
このような構成であれば、非アクティブとなっているアプリケーションに対するコマンドが入力されたとしても、上記非アクティブとなっているアプリケーションにコマンドに応答した処理を実行させることが可能となる。
また、このような構成によっては、オペレーションシステムとしては、これまでと同様のイベント処理によって、入力したコマンドを、アクティブとなっているアプリケーションに対して転送するという処理を実行させればよいことになる。
【００２０】
【発明の実施の形態】
以下、本発明の実施の形態について説明を行うこととする。なお、以降の説明は次の順序で行う。
１．情報処理装置の構成
２．本実施の形態のソフトウェア構成
３．本実施の形態のアプリケーションにより得られる動作
４．コマンド管理アプリケーションの構造概念
５．処理動作
５−１．ＯＳによる処理動作
５−２．一般アプリケーションによる処理動作
５−３．コマンド管理アプリケーションによる処理動作
【００２１】
１．情報処理装置の構成
図１は、本発明の実施の形態としての情報処理装置１の構成例を示している。ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１は、起動されたプログラムに基づいて情報処理装置１の全体の制御、演算処理を行う。例えばネットワークを介した通信動作、ユーザーに対する入出力動作、ＣＤの再生、ＨＤＤ２１へのコンテンツ記憶やそのための管理などを行う。
ＣＰＵ１１はバス１２を介して各回路部との間で制御信号やデータのやりとりを行う。
【００２２】
メモリ部１３はＣＰＵ１１が処理に用いるＲＡＭ、ＲＯＭ、フラッシュメモリ（不揮発性メモリ）などを包括的に示している。
この場合のメモリ部１３におけるＲＯＭには、ＣＰＵ１１が実行する小規模なプログラムや、ＣＰＵ１１の処理実行時に使用する固定の各種デバイス設定値などを記憶させておくことができる。また、メモリ部１３におけるフラッシュメモリには、各種演算係数、プログラムで用いるパラメータ等が記憶される。メモリ部１３におけるＲＡＭには、プログラムを実行する上でのデータ領域、タスク領域が一時的に確保される。
【００２３】
操作入力部１５は、情報処理装置１の筐体に設けられた操作キーやジョグダイヤル、タッチパネルなどの各種操作子などから成る部位である。なお、ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）操作のためのキーボードやマウスが操作入力部１５として設けられてもよい。操作部１５にて行われた操作に応じた操作情報信号は、入力処理部１４に対して出力される。
【００２４】
また、本実施の形態の情報処理装置１には、リモートコントローラ２９が付属されている。このリモートコントローラ２９には、当該情報処理装置１の各種動作をコントロールするための各種操作子が備えられている。例えば本実施の形態であれば、後述するＣＤドライブ１９に装填されたＣＤについての各種再生操作や、チューナ２７において受信される放送の選局操作などをはじめ、各種の操作を行うことができる。
そして、このリモートコントローラ２９では、操作子に対して行われた操作に応じた操作情報信号を、赤外線又は電波などによって無線により送信出力するようにされる。リモートコントローラから送信された操作情報信号は、情報処理装置１側の受信部２８にて受信され、入力処理部１４に対して入力される。
【００２５】
入力処理部１４では、上記のようにして操作部１５又は受信部２８から入力された操作情報信号について所定の処理を施し、ＣＰＵ１１に対して外部イベントにより発生したコマンドとして伝送する。ＣＰＵ１１は入力されたコマンドに応答した機器としての動作が得られるように、所要の演算や制御を行う。
【００２６】
ディスプレイモニタ１７としては、例えば液晶ディスプレイなどの表示デバイスが接続され、各種情報表示が行われる。
ＣＰＵ１１が各種動作状態や入力状態、通信状態に応じて表示情報を表示処理部１６に供給すると、表示処理部１６は供給された表示データに基づいてディスプレイモニタ１７に表示動作を実行させる。
例えばＣＤ再生時、或いはＨＤＤ２１に格納されたオーディオファイルとしてのコンテンツの再生時には、トラックナンバ、演奏時間、動作状態、音量状態などが表示される。また再生するコンテンツに対応してＣＤタイトル情報が格納されていれば曲名、アーティスト名等の各種情報を表示することもできる。
またラジオ受信時には、受信周波数、音量状態などが表示される。
【００２７】
ＣＤドライブ１９は、光学ヘッド、スピンドルモータ、再生信号処理部、サーボ回路等を備え、ＣＤに対する再生動作を行う。ＣＤドライブ制御部１８は、ＣＤドライブ１９におけるＣＤに対する再生動作、アクセス動作等を制御する。例えばユーザーが入力部１５からＣＤ再生操作を行った場合は、ＣＰＵ１１はＣＤドライブ制御部１８にＣＤ再生を指示する。するとＣＤドライブ制御部１８は、ＣＤドライブ１９に対して再生／アクセスを実行させる制御を行う。
ＣＤドライブ１９では、ＣＤから読み出した信号に対してデコードを行い、再生データをＣＤドライブ制御部１８を介してバス１２に送出する。
この再生データはオーディオデータ処理部２４においてイコライジング等の音場処理や音量調整、Ｄ／Ａ変換、増幅等の処理が施され、スピーカ部２５から出力される。
またＣＤドライブ１９で再生されたデータは、例えばＣＰＵ１１の処理によって所要のファイルエンコード処理を施されてＨＤＤ２１にコンテンツファイルとして蓄積することもできる。
なお、公知のようにＣＤではその最内周側にＴＯＣと呼ばれる管理情報が記録されており、ＣＤ再生時にはＴＯＣに基づいてディスク上のトラック（コンテンツ）のアクセスを行う。従ってＣＤドライブ制御部１８は、ＣＤが装填された際にはＣＤドライブ１９にＴＯＣ読出を指示し、読み出されたＴＯＣデータを得ることで、ＣＤの再生制御が可能となる。
【００２８】
ＨＤＤ２１は、比較的大きな記憶容量を有しているもので、例えば上記もしたように、ＣＤドライブ１９によりＣＤから再生して得たオーディオデータなどのコンテンツファイルを記憶して保存させておくことができる。
また、本実施の形態では、ＣＰＵ１１が実行すべき各種プログラム（ソフトウェア）もインストールされるようにして記憶されている。これらプログラムとしては、ＯＳ（Ｏｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ）、及びこのＯＳ上で動作するアプリケーションプログラムとなる。
【００２９】
チューナ部２７は、例えばＡＭ・ＦＭラジオチューナとされ、ＣＰＵ１１の制御に基づいて、アンテナ２６で受信された放送信号を復調する。もちろんテレビチューナや衛星放送チューナ、デジタル放送チューナなどとしてのチューナでもよい。
復調された放送音声信号は、オーディオデータ処理部２４において所要の処理が施され、スピーカ部２５から放送音声として出力される。
【００３０】
通信処理部２２は、ＣＰＵ１１の制御に基づいて送信データのエンコード処理、受信データのデコード処理を行う。
ネットワークインターフェイス２３は、通信処理部２２でエンコードされた送信データをネットワークを介して所定の外部ネットワーク対応機器に送信する。またネットワークを介して外部ネットワーク対応機器から送信されてきた信号を通信処理部２２に受け渡す。
通信処理部２２は受信した情報をＣＰＵ１１に転送する。
【００３１】
なお、情報処理装置１の構成は、この図１の構成に限られるものではなく、更に多様に考えられる。
例えば各種記録媒体に対応するように、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）ドライブ、ＭＤ（Ｍｉｎｉ Ｄｉｓｃ）ドライブ、テープドライブなどが設けられたり、例えばＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）、ＩＥＥＥ１３９４、Ｂｕｌｕｅｔｏｏｔｈなどの通信方式による周辺機器とのインターフェースが設けられるようにしてもよい。
またマイクロホンや外部のヘッドホンの接続に用いられる端子や、ＤＶＤ再生時に対応するビデオ出力端子、ライン接続端子、光デジタル接続端子等が設けられてもよい。
またＰＣＭＣＩＡスロット、メモリカードスロットなどが形成され、外部の情報処理装置やオーディオ機器とデータのやりとりが可能とされてもよい。
【００３２】
２．本実施の形態のソフトウェア構成
図２は、上記図１に示したＨＤＤ２１にインストールされているソフトウェアについてのソフトウェア構造例を示している。
先ず、この図に示すようにして、ソフトウェア構造における最下層に、ＯＳが在るようにされる。周知のようにして、ＯＳは、情報処理装置を運用するのに必要とされる基本的なプログラムであり、後述するアプリケーションプログラムを管理し、また、各種データ及びハードウェアを管理する。
【００３３】
そして、このＯＳの上の階層に対して、１以上のアプリケーションプログラム（以降、単に「アプリケーション」ともいう）から成るとされる、アプリケーションプログラム層が位置することになる。このアプリケーションプログラム層を形成する各アプリケーションは、上記ＯＳにより管理されるようにして、ＯＳ上で動作する。各アプリケーションは、周知のようにして、或る特定の目的に従った機能が得られるようにしてそのプログラムが構築されている。
図１１に示したＣＰＵ１１は、ＯＳ上で起動されたアプリケーションのプログラムに従って処理を実行することができる。これにより、当該情報処理装置１は、そのアプリケーションが提供する機能を実行する機器として動作できることになる。
【００３４】
そして、本実施の形態においては、上記アプリケーションプログラム層に属するアプリケーションとして、先ずは、１つのコマンド管理アプリケーションが在るようにされる。また、コマンド管理アプリケーション以外のアプリケーションである、１以上の一般アプリケーションが在るようにされる。
【００３５】
この図に示す一般アプリケーションがどのようなものであり、また、いくつ存在するのかは、ユーザが情報処理装置１に対してどのようなアプリケーションを、どれだけインストールしたのかによって異なってくる。
例えば、一般アプリケーションの種類としては、Ｗｅｂブラウザ機能を有するアプリケーション、ワードプロセッサ機能を有するアプリケーション、静止画又は動画の画像編集処理を行う画像処理アプリケーションなどを挙げることができる。
また、特に本実施の形態の場合に対応しては、ＣＤドライブ１９によるＣＤについての再生操作をユーザが行うためのＣＤ再生アプリケーション、ＣＤから再生したオーディオデータをコンテンツファイルとしてＨＤＤ２１に記憶させ、また、このコンテンツファイルをＨＤＤ２１から再生させるためのリッピングアプリケーション、などもインストールされる。
【００３６】
詳しいことは後述するが、コマンド管理アプリケーションは、アプリケーションとして次のようなコマンド管理が可能なプログラムとして構成されている。
例えば外部からのイベントとしてＯＳが入力したコマンドが、そのときにアクティブとなっているアプリケーションが処理できるものでない場合がある。コマンド管理アプリケーションは、このような場合に対応してコマンド管理を実行させる。
つまり、コマンド管理アプリケーションは、上記コマンドについて処理が可能なアクティブではないアプリケーションを認識し、この非アクティブのアプリケーションに対してコマンドを転送するようにされる。これにより、非アクティブのアプリケーションに対してコマンドが入力された場合においても、この非アクティブのアプリケーションによってコマンドについての処理が実行されることになる。
【００３７】
このことから、コマンド管理アプリケーションは、アプリケーションプログラム層において、ＯＳと他の一般アプリケーションとの間に介在するようにして、アプリケーションプログラムが処理すべきコマンドについての管理を行う機能を有しているということがいえる。
また、本実施の形態のコマンド管理アプリケーションとしては、後述するようにして、登録された一般アプリケーションの起動／終了等を、ユーザ操作に応じてコントロールする、いわゆるランチャーとしての機能も与えることができる。
【００３８】
３．本実施の形態のアプリケーションにより得られる動作
上記した本実施の形態のコマンド管理アプリケーションにより得られる動作について、図３を参照して説明する。
図３は、ディスプレイモニタ１７の表示画面１７ａに表示されるＧＵＩ画像を示している。この場合には、一般アプリケーションとして、アプリケーションＡ、アプリケーションＢ、及びアプリケーションＣが起動されているものとする。
【００３９】
これに対応して、例えばこの場合には、各アプリケーションのアプリケーションウィンドウが開いた状態が示されている。
アプリケーションＡに対応しては、２つのウィンドウが表示されている。つまり、アプリケーションＡ・子ウィンドウＷ１と、アプリケーションＡ・親ウィンドウＷ２が表示されている。ここで、アプリケーションＡ・子ウィンドウＷ１は、アプリケーションＡ・親ウィンドウＷ２に対して階層的に１つ下にあるものとされる。従って、例えばアプリケーションＡ・親ウィンドウＷ２に対しては、その階層下にあるとされる子ウィンドウが並列的に複数存在していてもよい。但し、ここでは説明の便宜上、子ウィンドウについてはアプリケーションＡ・子ウィンドウＷ１を１つのみ示している。
【００４０】
また、アプリケーションＢに対応しては、１つのアプリケーションＢ・ウィンドウＷ３が表示されている。また、アプリケーションＣについても、１つのアプリケーションＣ・ウィンドウＷ４が表示された状態が示される。
【００４１】
ここで、本実施の形態のＯＳとしては、複数のアプリケーションが起動している状態では、アクティブとなるウィンドウは常に１つであるようにして管理している。そして、この場合には、アプリケーションＢ・子ウィンドウがアクティブとなっており、残るウィンドウは非アクティブとなっている。
【００４２】
この状態で、仮に本実施の形態としてのコマンド管理を採用しない場合には、次のようなコマンド対応処理となる。
つまり、図３に示す状態では、処理され得るコマンドは、アクティブとなっているアプリケーションＡに対応するものだけということになり、残るアプリケーションＢ，Ｃをはじめ、他のアプリケーションが処理可能なコマンドについては、処理することができない。但し、この場合には、アプリケーションＡ・子ウィンドウＷ１がアクティブとなっているから、処理され得るコマンドは、子ウィンドウＷ１が処理可能なコマンドのみとなる。つまり、同じアプリケーションＡが処理可能なコマンドであっても、これが親ウィンドウＷ２が処理すべきコマンドで、子ウィンドウＷ１が処理できるコマンドでない場合には、このコマンドに対応した処理は行われない。
【００４３】
しかしながら、本実施の形態としては、非アクティブとなっているアプリケーション、ウィンドウが対応するコマンドが入力された場合にも、このコマンドが無効にされることなく正常に処理されるようになっている。これは、次に説明するようにして、一般アプリケーションとコマンド管理アプリケーションによるコマンド管理機能に対応した処理によって実現される。
【００４４】
ここで、コマンド管理アプリケーションは、例えば、ＯＳが起動されたときに、常に自動的に起動するようになっている。そして、起動された状態では、図示するようにして表示画面上に対して、コマンド管理アプリケーション・アイコンＡ１を表示させるようになっている。そして、このコマンド管理アプリケーション・アイコンＡ１内には、後述する操作手順によって登録された一般アプリケーションを示すボタンアイコンが配置される。ここでは、アプリケーションＡ，Ｂ，Ｃがそれぞれ登録されているものとされ、これに対応して、アプリケーションＡ，Ｂ，Ｃを示す各ボタンアイコンＢＴ１，ＢＴ２，ＢＴ３が配置表示された状態が示されている。
【００４５】
このコマンド管理アプリケーション・アイコンＡ１は、ランチャー機能に対応するＧＵＩ画像とされる。つまりユーザは、このコマンド管理アプリケーション・アイコンＡ１内に表示されるボタンアイコンのうちから、所望のボタンアイコンを操作することで、そのボタンアイコンが示すアプリケーションを起動させることができる。また、所定操作によっては、既に起動されているアプリケーションを終了させることも可能とされる。
【００４６】
そして、このコマンド管理アプリケーション及び一般アプリケーションによるコマンド管理機能によっては、例えば次のような動作が得られる。
この図３に示す表示状態において、子ウィンドウがアクティブとなっているアプリケーションＡは、画像処理アプリケーションであるとする。また、非アクティブであるアプリケーションＢは、ＣＤドライブ１９に装填されたＣＤを再生するためのＣＤプレーヤアプリケーションであるとする。例えばユーザは、このＣＤプレーヤアプリケーションに対して操作を行うことで、ＣＤドライブ１９に装填されたＣＤの再生開始、一時停止、頭出し等をはじめとした各種再生に関する動作を実行させることができる。
そして、前述もしたように、本実施の形態の情報処理装置１にはリモートコントローラ２９が付属している。このリモートコントローラ２９を使用して、上記した画像処理アプリケーションやＣＤプレーヤアプリケーションに対する操作を行うことができる。また、操作入力部１５としての所定の操作子又は操作入力デバイスにより行うこともできる。
【００４７】
例えば、上記図３に示した状態の下で、アプリケーションＡとしての画像処理アプリケーションを対象として、在る特定の画像処理を実行させるための操作を行ったとする。この操作に応じて、ＯＳには特定の画像処理を指示するコマンドが入力される。ＯＳは、この入力したコマンドを現在アクティブとなっているウィンドウに渡す。
ここで、上記操作が指示する画像処理は、アプリケーションＡ・子ウィンドウＷ１が処理すべきものではなく、アプリケーションＡ・親ウィンドウＷ２が処理すべきものであったとする。
【００４８】
この場合、アクティブとなっているのは、アプリケーションＡ・子ウィンドウＷ１であり、アプリケーションＡ・親ウィンドウＷ２ではない。
しかしながら、本実施の形態としては、各一般アプリケーションは、受け渡されたコマンドが、そのときにアクティブとなっているウィンドウが処理すべきものでない場合には、このコマンドの処理を、同じアプリケーションが管理するその１階層上のウィンドウに受け渡すこととしている。
従って、この場合、アプリケーションＡ・子ウィンドウＷ１は、上記画像処理のための操作に応じて得られたコマンドを、そのアプリケーションＡ・親ウィンドウＷ２に渡すことになる。すると、アプリケーションＡ・親ウィンドウＷ２では、このコマンドについて処理を行う。つまり、ユーザ操作に応じた画像処理を実行することになる。
【００４９】
また、同じく、図３に示した状態の下で、ユーザは、ＣＤプレーヤアプリケーションに対する操作として、ＣＤ再生開始のための操作を行ったとする。この操作に応じては、ＣＤ再生を指示するコマンドがＯＳからアクティブとなっているウィンドウに渡すされる。
【００５０】
このときにも、アクティブとなっているのは、画像処理アプリケーションであるアプリケーションＡ・子ウィンドウＷ１である。
上記もしたように、本実施の形態に対応する一般アプリケーションは、アクティブとなっているウィンドウが処理すべきコマンドでない場合には、このコマンドの処理を、その１階層上のウィンドウに転送するようにしている。しかしながら、最上層のウィンドウにまで至っても、処理すべきコマンドでない場合には、コマンド管理アプリケーションに、そのコマンドを転送するようにされている。この場合、ＣＤ再生のコマンドを受けた画像処理アプリケーションであるアプリケーションＡでは、アプリケーションＡ・親ウィンドウＷ２も、このコマンドを処理できない。そして、この場合における最上層のウィンドウは、アプリケーションＡ・親ウィンドウＷ２である。従って、アプリケーションＡとしては、このコマンドをコマンド管理アプリケーションに渡すようにされる。
【００５１】
コマンド管理アプリケーションでは、後述するようにして、登録されたアプリケーションが処理可能なコマンドについての認識が可能とされている。
そこで、コマンド管理アプリケーションでは、上記のようにしてアプリケーションＡから取得したコマンドが、どの一般アプリケーションで処理可能であるのかを、登録されたアプリケーションの中から認識する。そして、認識したアプリケーションに対して、この取得していたコマンドを受け渡す。
つまり、図３の場合であれば、コマンド管理アプリケーションは、ＣＤプレーヤアプリケーションに対してコマンドを受け渡すことになる。ＣＤプレーヤアプリケーションは、受け取ったコマンドに応じてＣＤ再生を開始させる処理を実行させる。
【００５２】
上記した各動作は、ユーザにとって見れば、非アクティブとなっているウィンドウに対して操作を行っても、この操作に応じた動作が情報処理装置側で反応して得られているというように見えることになる。
これにより、例えばユーザは、情報処理装置１やリモートコントローラ２９などが故障しているのではないかなどと不安になることがない。また、所望の操作に応じた動作を情報処理装置に対して実行させるのにあたり、前もって、その操作対象となるアプリケーションやウィンドウをアクティブにする操作を行わなくてもよいことになる。
【００５３】
４．コマンド管理アプリケーションの構造概念
以降においては、上記したようなアプリケーションによるコマンド処理の動作を実現するための構成について、より詳細に説明していくこととする。先ず、コマンド管理アプリケーションの構造概念について説明しておく。
ここで、コマンド管理アプリケーションが、上記のようにして、受け渡されたコマンドを、このコマンドについての処理が可能とされるしかるべきアプリケーションに転送するためには、各アプリケーションが処理可能なコマンドを認識できることが必要とされる。
このために本実施の形態としては、非アクティブの状態でもコマンド入力に応じて動作させるべき一般アプリケーションを、コマンド管理アプリケーションに登録させることとする。
この登録は、ユーザによって行われることとする。つまり、ユーザは、非アクティブの状態でも操作に応じて動作させたいとする一般アプリケーションを任意に選択し、登録のための操作を行うようにされる。
【００５４】
図４のフローチャートに、ユーザによる上記一般アプリケーション登録のための操作手順と、この操作に応じたコマンド管理アプリケーションの動作を、フローチャートとして示す。
ここでは先ず、ステップＳ１により、ユーザの操作、作業として、一般アプリケーションを新規にＨＤＤ２１にインストールするところから始まっている。そして、インストールが行われた後の機会において、ユーザは、ステップＳ２として示すようにして、この新規にインストールした一般アプリケーションを、コマンド管理アプリケーションに登録するための操作を行うことができる。
この登録操作の実際としては、いくつか考えることができるが、例えば１つには、図３に示したコマンド管理アプリケーション・アイコンＡ１に、新規インストールされた一般アプリケーションの実行ファイルに相当するアイコンを、ドラッグ・アンド・ドロップさせるという操作とすることができる。
あるいは、コマンド管理アプリケーションとしてのＧＵＩに対する所定操作によって、登録のためのダイアログを表示させ、このダイアログに対する操作によって登録させるようにすることも考えられる。
【００５５】
そして、上記のようにして登録操作が行われたとすると、ステップＳ３に示すようにして、コマンド管理アプリケーションによる処理として、この登録操作によって登録対象となった一般アプリケーションについての登録ファイルを作成する。なお、登録ファイルの構造例については、後述する。そして、次のステップＳ５として示すようにして、この作成した登録ファイルを、ＨＤＤ２１に記憶させるようにする。この際には、例えば登録ファイル用に作成された所定のディレクトリに在るものとして管理されるようにしてＨＤＤ２１への記憶が行われるようにすればよい。
このようにして、登録ファイルが作成、保存されることで、一般アプリケーションの登録が完了したことになる。
【００５６】
そして図５は、上記登録ファイルと共に、コマンド管理アプリケーションの構造を模式的に示している。
先ず、この図５により登録ファイルの構造例について説明しておく。例えばこの図には、ＨＤＤ２１の所定のディレクトリに記憶される登録ファイルとして、アプリケーションＡ，Ｂ，Ｃの３つに対応した登録ファイルが示されている。これらの登録ファイルの各々は、図示するようにして、例えば、実行ファイルディレクトリ情報Ｄ１、アイコン画像データＤ２、及びコマンド識別テーブルＤ３とから成る。
【００５７】
実行ファイルディレクトリ情報Ｄ１は、登録された一般アプリケーションとしての実行ファイルの実体（若しくはエイリアス）の識別子と、この実行ファイルの実体（若しくはエイリアス）が保存されているＨＤＤ２１上のディレクトリとを対応付けた情報とされる。この実行ファイルディレクトリ情報Ｄ１を参照することで、ＨＤＤ２１における実行ファイルの保存先を特定することができる。
また、アイコン画像データＤ２は、例えば、登録された一般アプリケーションとしての実行ファイルに対応するアイコン画像のデータである。
そして、コマンド識別テーブルＤ３は、登録された一般アプリケーションが処理可能なコマンドコードをテーブル化して格納した情報とされる。
【００５８】
これらの情報は、先の図４におけるステップＳ３において作成され、登録ファイルを形成することになる。
実行ファイルディレクトリ情報Ｄ１は、図４のステップＳ２として示した登録操作時において、登録対象の一般アプリケーションの識別子及びディレクトリが認識されるので、これらの情報を基に作成可能である。
また、アイコン画像データＤ２も、登録操作時において、例えばドラッグ・アンド・ドロップされたアイコンの画像データを取得することで作成できる。
コマンド識別テーブルＤ３をどのようにして作成するのかについては、いくつか考えられるが、例えば次のような手法により作成することができる。
つまり、コマンド管理アプリケーションとしての処理により、登録対象とされた一般アプリケーションのプログラムの記述内容を解析する。そして、この解析したプログラムに記述されているコマンドコードを抽出してテーブル化するものである。
あるいは、一般アプリケーション側で、コマンド管理アプリケーションにより管理してもらうべきコマンドのリストを有していることとし、コマンド管理アプリケーションが、このリストの情報を取得してコマンド識別テーブルＤ３を作成できるように構成することも考えられる。
【００５９】
そして、同じく図５に示すようにして、本実施の形態のコマンド管理アプリケーションとしては、前述したランチャー機能処理ブロックＢ１としてのプログラムと、コマンド管理処理ブロックＢ１としてのプログラムと、さらに、ＡＰＩ処理ブロックＢ３としてのプログラムから成るものとされる。
【００６０】
ランチャー機能処理ブロックＢ１は、図示するようにして各一般アプリケーションの登録ファイルを参照することで、図３により説明したようなランチャーとしての機能を実現する。
つまり、アイコン画像データＤ２を参照することによっては、図３に示したコマンド管理アプリケーション・アイコンＡ１内の各ボタンアイコンを表示させることができる。また、実行ファイルディレクトリ情報Ｄ１を参照することによっては、例えばボタンアイコン操作に応じて、一般アプリケーションを起動させることができる。
【００６１】
同様にして、コマンド管理処理ブロックＢ２も、各一般アプリケーションの登録ファイルを参照することでコマンド管理機能を実現する。つまり、各登録ファイル内のコマンド識別テーブルＤ３を参照することで、受け取ったコマンドを処理すべき一般アプリケーションを認識することができる。
【００６２】
また、ＡＰＩ処理ブロックＢ３は、所定のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）に従って、一般アプリケーションとの通信を実行するためのプログラムであり、このＡＰＩ処理ブロックＢ３により、例えばランチャー機能処理ブロックＢ１による一般アプリケーションの起動／終了等のイベントを一般アプリケーションに通知する。また、コマンド管理処理ブロックＢ２が指定する一般アプリケーションへのコマンドの転送処理が行われる。
【００６３】
５．処理動作
５−１．ＯＳによる処理動作
続いては、図３により説明したコマンド管理を実現するためのプログラム処理について説明していくこととし、先ずは、ＯＳに従ったコマンド対応処理について説明する。
図６のフローチャートは、ＯＳによるコマンド対応処理を示している。この図に示す処理は、ＣＰＵ１１が、ＯＳとしてのプログラムを実行することで得られるものである。
【００６４】
本実施の形態では、操作入力部１５から出力される操作情報信号、又は受信部２８により受信したリモートコントローラ２９からの操作情報信号が入力処理部１４によりコマンドに変換され、ＣＰＵ１１に転送される。つまり、操作入力部１５やリモートコントローラ２９に対して行われた操作は、外部イベントとして扱われ、ＣＰＵ１１は、この外部イベントに応じたコマンドを入力するものである。
【００６５】
図６に示すステップＳ１０１においては、先ず、上記したコマンドが入力されるのを待機している。そして、コマンドの入力が得られたことを判別するとステップＳ１０２の処理に進む。
ステップＳ１０２においては、現在のアクティブウィンドウを認識するようにされる。アプリケーション又はウィンドウをアクティブにする管理は、ＯＳが行っているから、この場合の処理としては、自身が現在設定しているアクティブなウィンドウが何であるのかを認識するようにすればよい。
そして、次のステップＳ１０３においては、上記ステップＳ１０２により認識したアクティブウィンドウに対して、ステップＳ１０１の処理に対応して入力したコマンドを受け渡す処理を行う。
【００６６】
５−２．一般アプリケーションによる処理動作
続いては、一般アプリケーションによるコマンド対応処理について、図７のフローチャートを参照して説明を行う。この図に示す処理は、アクティブとなっている一般アプリケーションとして、アクティブウィンドウに対応するプログラムが、上記図６に示した処理によってＯＳからコマンドを受け取ったときに開始される。
【００６７】
この図７においては、先ずステップＳ２０１により、コマンドの受信を待機している。ここで受信されるコマンドは、先の図６におけるステップＳ１０３の処理によってＯＳから受け渡されるコマンドと、以降説明する処理の結果、親ウィンドウに渡されたコマンドの何れかとなる。ただし、最初のステップＳ２０１の処理にて受信されるコマンドは、ＯＳからアクティブウィンドウに対して受け渡されたものとなる。
そして、例えば最初のステップＳ２０１の処理として、アクティブウィンドウが、ＯＳからコマンドを受け取るとステップＳ２０２の処理に移行する。
【００６８】
ステップＳ２０２においては、受け取ったコマンドに対応する処理がこのウィンドウ内に存在するか否かについて判別する。つまりは、現ウィンドウが、このコマンドを処理可能であるか否かについて判別するものである。このためには、例えば、受け渡されたコマンドのコードを解析する。そして、現ウィンドウ内で実行可能なコマンド応答処理を発現させるコマンドのコードと、受け渡されたコマンドのコードとを比較参照する。一致したコマンコードがあれば、コマンドコードが処理可能であることになり、ステップＳ２０２では肯定結果が得られる。これに対して、一致したコマンドコードがなくコマンドの処理ができないとされる場合には否定結果が得られる。
【００６９】
ステップＳ２０２において肯定結果が得られた場合には、ステップＳ２０３の処理によって、受け渡されたコマンドに応答した処理を実行する。
これに対してステップＳ２０２において否定結果が得られた場合には、ステップＳ２０４の処理に進む。
【００７０】
ステップＳ２０４においては、現ウィンドウの１つ上の階層にあるウィンドウである、親ウィンドウが存在するか否かについて判別している。現ウィンドウは、自身の親ウィンドウとのリンクの情報を持つようにされているから、例えばこの情報に基づいて親ウィンドウの存在の有無を認識できる。そして、親ウィンドウが存在するとして肯定結果が得られたのであれば、ステップＳ２０５に進む。ステップＳ２０５においては、親ウィンドウに対して先のステップＳ２０１の処理により受け取ったコマンドを親ウィンドウに受け渡す。
これまでの処理は、例えば図３の場合であれば、先ず、アプリケーションＡ・子ウィンドウＷ１にて、ＯＳから受け渡されたコマンドが処理できないと判定したことにより、このアプリケーションＡ・子ウィンドウＷ１が、その１つ上の階層のウィンドウである、アプリケーションＡ・親ウィンドウＷ２にコマンドを受け渡すという動作に対応する。
【００７１】
ステップＳ２０５の処理により親ウィンドウにコマンドが受け渡されると、次には、この親ウィンドウが、現ウィンドウとしてステップＳ２０１の処理を実行し、コマンドが受信されることを判別することとなる。親ウィンドウは非アクティブであるが、このステップＳ２０１によりコマンドを受信したことを判別すると、ステップＳ２０２以降の処理を実行することになる。
【００７２】
また、先のステップＳ２０４において、現ウィンドウに対する親ウィンドウが存在しないことを判別した場合には、ステップＳ２０６の処理に移行する。ステップＳ２０６においては、現ウィンドウが、コマンド管理アプリケーションの管理下にあるか否かを判別する。つまり、このウィンドウの一般アプリケーションについて、先に図４及び図５により説明したようにして、管理アプリケーションに登録されているか否かについて判別を行う。
このためには、例えば一般アプリケーションにおけるコマンド管理アプリケーション対応のプログラムとして、自身がコマンド管理アプリケーションに登録されているか否かを認識できるようにする仕組みが必要となる。そこで、例えば一般アプリケーションは、登録されたときに登録されたことを示すフラグを持つようにすることが考えられる。また、ステップＳ２０６としての処理実行時には、管理アプリケーションと所定のＡＰＩにより通信を行って、自己のアプリケーションが登録されているか否かを問い合わせるようにしてもよい。
【００７３】
そして、ステップＳ２０６において、現ウィンドウが、コマンド管理アプリケーションの管理下にあると判別した場合には、ステップＳ２０７の処理に進む。ステップＳ２０７においては、この現ウィンドウが先のステップＳ２０１にて、ＯＳ又は子ウィンドウから受け渡されたとされるコマンドを、コマンド管理アプリケーションに対して受け渡す。
なお、このステップＳ２０６にて、現ウィンドウが、コマンド管理アプリケーションの管理下には無いとして否定結果を得た場合には、このまま、一般アプリケーションによるコマンド対応処理は終了する。これは、例えばコマンド管理アプリケーションに登録されていない一般アプリケーションに対して、自己が処理すべきコマンドが受け渡された場合の処理結果となる。この場合には、イベントとして入力されたコマンドは、処理されずに無効となる。
【００７４】
５−３．コマンド管理アプリケーションによる処理動作
続いては、コマンド管理アプリケーションによるコマンド対応処理について、図８のフローチャートを参照して説明を行う。この図に示す処理は、図５に示したランチャー機能処理ブロックＢ１、コマンド管理処理ブロックＢ２、及びＡＰＩ処理ブロックとしてのプログラムに従って、ＣＰＵ１１が処理を実行することで実現される。
【００７５】
先ずステップ３２０１において、先の図７のステップＳ２０７の処理によって一般アプリケーションから受け渡されたコマンドを受信するのを待機しており、コマンドを受信したことを判別するとステップＳ３０２の処理に進む。
【００７６】
ステップＳ３０２においては、受信したコマンドが処理すべきアプリケーションを判定する。
コマンドとしては、例えば一般アプリケーションのみではなく、このコマンド管理アプリケーションが実行すべきものが含まれる可能性がある。例えばランチャー機能に関連して、ユーザ操作に応じて、アプリケーション指定して起動させるためのコマンドなども受信される可能性があるということである。
そこで、ステップＳ３０２においては、先ず、コマンド管理アプリケーション自身が処理すべきコマンドであるのかを判別する。そして、コマンド管理アプリケーション自身が処理すべきコマンドではないと判別した場合に、コマンド管理アプリケーションに登録された一般アプリケーションのうちから、受信したコマンドを処理すべきアプリケーションを判定するようにされる。
【００７７】
ここで、図４に示したように、コマンド管理アプリケーションは、登録されたアプリケーションごとの登録ファイルを管理し、この登録ファイルには、その登録アプリケーションが処理可能なコマンドコードを示すコマンド識別テーブルＤ３が格納されている。
そこで、ステップＳ３０２において、登録された一般アプリケーションのうちから、受信したコマンドを処理すべきアプリケーションを判定するのにあたっては、受信したコマンドのコードと、各登録ファイルのコマンド識別テーブルＤ３に格納されたコマンドコードとを比較参照する。これにより、受信したコマンドのコードに一致したコマンドコードを格納したコマンド識別テーブルＤ３が特定される。さらに、この特定されたコマンド識別テーブルＤ３を格納する登録ファイルが特定される。そして、この登録ファイルが対応するアプリケーションが、受信したコマンドを処理すべきアプリケーションであるとして判定できることになる。
【００７８】
次のステップＳ３０３では、上記ステップＳ３０２の判定結果に基づいて、受信したコマンドについて、コマンド管理アプリケーション自身が処理すべきものであるか否かについての判別を行う。そして、自身が実行すべきコマンドであるとして肯定結果を得た場合にはステップＳ３０７の処理に進む。
ステップＳ３０７の処理としては、コマンド管理アプリケーション自身が、受信したコマンドに応答した処理を実行する。
【００７９】
これに対して、ステップＳ３０３において、自身が実行すべきコマンドではないとして否定結果を得た場合にはステップＳ３０４以降の処理に進む。ステップＳ３０４以降の処理に進む場合とは、先のステップＳ３０２にて、コマンド管理アプリケーションに登録された一般アプリケーションのうちから、受信したコマンドを処理すべきアプリケーションが判定された場合となる。
【００８０】
そして、ステップＳ３０４では、受信したコマンドを処理すべき一般アプリケーションが起動中にあるか否かを判別する。この場合、コマンド管理アプリケーションは、ランチャーとしての機能を有しているものとされているから、登録された一般アプリケーションが起動中にあるか否かについては、自己が管理している。従って、例えば、ランチャー機能処理ブロックＢ１において現在管理しているアプリケーションごとの起動状況を参照することで、ステップＳ３０４としての判別は可能である。
【００８１】
そして、ステップＳ３０４において、受信コマンドを処理すべきアプリケーションが起動されていると判別した場合には、ステップＳ３０５の処理をスキップしてステップＳ３０６の処理に進む。これに対して、受信コマンドを処理すべきアプリケーションが起動されていないと判別した場合には、ステップＳ３０５の処理を実行してからステップＳ３０６の処理に進む。
【００８２】
ステップＳ３０５においては、コマンド管理アプリケーションにおけるランチャー機能処理ブロックＢ１としてのプログラムにより、受信コマンドを処理すべきアプリケーションを起動させるための処理を実行する。これにより、アプリケーションはＯＳ上で起動し、以降は、コマンド対応処理を実行可能となる。
このような処理によると、本実施の形態としては、起動されていない一般アプリケーションが処理すべきコマンドが入力されたときには、この一般アプリケーションが自動的に起動され、そして、入力されたコマンドに応じた処理が実行されることになる。
【００８３】
そして、ステップＳ３０６においては、受信したコマンドを、ステップＳ３０２で判定したアプリケーションに対して受け渡す。
このコマンドが受け渡されたアプリケーションは、先に説明した図７の処理を実行することになる。そしてこの場合には、ステップＳ２０３又はステップＳ２０５の処理によって、このアプリケーションによりコマンドの処理が行われることとなる。
【００８４】
これまでの説明によると、一般アプリケーションとしては、図７に示したようにして、ウィンドウの階層ごとに自身が処理すべきコマンドであるか否かについて判定を行って、自身が処理すべきコマンドであれば処理を行うようにされる。つまり、これによっては、同一のアプリケーション上で、非アクティブとなっているウィンドウが存在する場合にも、この非アクティブのウィンドウにより、コマンド入力に対応した処理を実行できるようになっている。
また、コマンド管理アプリケーションとしては、図８に示したようにして、アクティブなアプリケーションが処理できないとして受け渡したコマンドを、登録された一般アプリケーションのうちから、このコマンドが処理可能なアプリケーションに転送するようにしている。
そして、ＯＳによるコマンド対応処理を図６に示したが、この処理は、入力コマンドをアクティブウィンドウに渡すというものであり、例えば従来と特に変わるところはない。
【００８５】
このことから、本実施の形態としてのコマンド管理は、一般アプリケーションとコマンド管理アプリケーションとの連携により実現されているということが分かる。
従来の問題点として前述もしたように、非アクティブのアプリケーション、ウィンドウに対して、コマンド処理を実行させるようにＯＳを構成するとした場合には、そのプログラムが非常に複雑となって重くなり、現実的ではないということがいえる。
これに対して本実施の形態では、非アクティブのアプリケーション、ウィンドウに対してコマンド処理を実行させるコマンド管理を、コマンド管理アプリケーションと、一般アプリケーションの連携によって実現している。従って、図７にも示されているように、ＯＳとしては、従来のコマンド対応処理を行えばよい。つまり、ＯＳについては、本実施の形態のコマンド管理を実現するのに対応して、特にプログラム構成を変更する必要はない。
【００８６】
また、コマンド管理アプリケーションについては、登録された一般アプリケーションの登録ファイルとしての情報に基づいて、しかるべきアプリケーションにコマンドの受け渡しを行う構成とされているが、１つのアプリケーションとして、このようなプログラムを作成することは、特に困難なことではない。
【００８７】
また、一般アプリケーションが有するべきコマンド管理としては、同一アプリケーションのウィンドウ間でコマンドを授受し、コマンドを処理可能なウィンドウが存在しない場合には、コマンドを管理アプリケーションに受け渡すという、比較的単純な動作が実現されればよい。そして、このような動作実現のための処理が実行されるように、プログラムの追加、変更を行えばよい。このようなプログラムの追加、変更も、容易に行うことができる。
また、このような一般アプリケーションにおけるコマンド管理機能は、予め、プログラムの一部として組み込まれるようにしてもよい。また、図７に示したようなコマンド管理機能を追加するためのパッチプログラム、プラグインファイルのようなものを用意し、ユーザが、適宜これを入手してインストールすることで、機能追加ができるようにすることも考えられる。
【００８８】
ところで、上記した各処理を実現するためのプログラムは、前述もしたように、情報処理装置１では、ＨＤＤ２１のに予め記憶して格納しておくものである。あるいは、メモリ部１３内のＲＯＭに格納されていても良い。
あるいは、プログラムは、フレキシブルディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＭＯ（Ｍａｇｎｅｔ Ｏｐｔｉｃａｌ）ディスク、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウェアとして提供することができる。例えば、本実施の形態であれば、ＣＤ−ＲＯＭにプログラムを記録し、パッケージソフトウェアとして提供することができる。これにより、情報処理装置１では、ＣＤドライブ１９によりプログラムを読み出し、メモリ部１３内のＲＯＭに記憶させることでインストールできる。
なお、プログラムは、上記のようなリムーバブルな記録媒体からインストールする他、プログラムを記憶しているサーバなどから、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワークを介してダウンロードすることもできる。
【００８９】
また、本発明としては、上記した実施の形態としての構成に限定されるものではない。例えば、本発明としてのイベント管理が行われる機器としては、図１に示した情報処理装置１としての構成に限定されるものではない。つまりは、上記したＡＶ機能に対応した情報処理装置としての構成だけではなく、例えばこのようなＡＶ機能に対応した装置部分を備えない、汎用のパーソナルコンピュータにも適用することが可能とされる。また、ＯＳ上で複数のアプリケーションを起動させることで各種の機能を実現するように構成された各種電子機器に適用できる。
また、本発明としてのコマンド管理のために、コマンド管理アプリケーション及び他の一般アプリケーションが実行する処理ステップについても、図６〜図８に示したもののみに限定される必要はなく、必要に応じて変更可能である。さらには、コマンド管理アプリケーションによる管理の仕組みも、図５に示したプログラム構成、及び登録ファイルの構造などに限定されるものではない。
特に、本発明としては、コマンド管理アプリケーションは、コマンド管理が行うことを主目的としているから、実施の形態で説明したランチャー機能は省略しても構わない。この場合、例えば、図３に示したようなコマンド管理アプリケーション・アイコンＡ１を表示出力させる必要は、必ずしもない。この場合、コマンド管理アプリケーションとしては、各種操作が可能なＧＵＩ画像表示を伴わない、バックグラウンド的に動作するアプリケーションとして構成することができる。
【００９０】
【発明の効果】
以上説明したように本発明は、プログラムとして、オペレーションシステムと、このオペレーションシステム上で動作する各種のアプリケーションプログラムに加え、アプリケーションプログラムとしてのコマンド管理アプリケーションが存在する。
そのうえで、コマンド対応処理として、アクティブなアプリケーションが、オペレーションシステムから転送されたコマンドについて処理できないと判断したときには、このコマンドをコマンド管理アプリケーションに転送するようにされる。そして、コマンド管理アプリケーションでは、転送されたコマンドを、このコマンドを処理することのできる非アクティブのアプリケーションに転送する。
【００９１】
上記のようなコマンド処理の構成を採ることで、本発明としては、非アクティブのアプリケーションによりコマンド処理を実行させることが可能となる。これにより、例えばユーザが、非アクティブのアプリケーションを対象として操作を行ったとしても、機器側では、この操作に応答した動作が行われることになるから、機器についての操作性及び信頼性が向上する。
【００９２】
また、本発明によると、上記したコマンド管理は、アプリケーションと他のアプリケーションとの連携によって実現されるということがいえる。これは即ち、ＯＳについては、従来と同様のコマンド対応処理を行う構成とすればよく、特に、本発明としてのコマンド管理に構成を採るのに応じて、変更を与える必要はないということになる。これにより、ＯＳのプログラム構造としては、複雑化、肥大化することがなく、ＯＳとしてのプログラム作成が困難になることが避けられる。
そしてまた、従来と同様のコマンド対応処理でよいということは、本発明としてのコマンド管理の構成は、幅広い種類のＯＳに適用できることにもなるという汎用性も有しているということがいえる。
【００９３】
また、上記構成のもとで、あるアプリケーションがコマンドを受け取ったときに、このコマンドがアクティブウィンドウで処理できない場合は、これより上位の非アクティブのウィンドウにコマンドを転送するようにされる。そして、コマンドを処理可能な上位階層のウィンドウがこれ以上はないとされる場合に、上記コマンド管理アプリケーションに対してコマンドを転送するようにされる。
この構成であれば、１つのアプリケーションにより複数のウィンドウが開かれている状況のもとで、非アクティブのウィンドウが処理すべきコマンドが入力されたときには、この非アクティブのウィンドウによってコマンドを処理させることが可能になる。この場合も、非アクティブのウィンドウに対する操作に反応して機器が動作することになるから、先の場合と同様に、操作性及び信頼性が向上されるものである。また、この構成においても、ＯＳについて特に変更が与えられることはない。
【図面の簡単な説明】
【図１】本発明の実施の形態としての情報処理装置の構成例を示すブロック図である。
【図２】実施の形態の情報処理装置のＨＤＤにインストールされるソフトウェアの構造例を示す概念図である。
【図３】本実施の形態におけるコマンド管理により得られる動作を説明するための、ＧＵＩ画面の表示態様例を示す説明図である。
【図４】コマンド管理アプリケーションへのアプリケーション登録手順を示すフローチャートである。
【図５】コマンド管理アプリケーションの構造例を示す概念図である。
【図６】本実施の形態のＯＳにより実行されるコマンド対応処理を示すフローチャートである。
【図７】本実施の形態の一般アプリケーションにより実行されるコマンド対応処理を示すフローチャートである。
【図８】本実施の形態のコマンド管理アプリケーションにより実行されるコマンド対応処理を示すフローチャートである。
【符号の説明】
１ 記録再生装置、１１ ＣＰＵ、１３ メモリ部、１４ 操作入力部、１５入力処理部、１６ 表示処理部、１７ ディスプレイモニタ、１８ ＣＤドライブ制御部、１９ ＣＤドライブ、２１ ＨＤＤ、２２ 通信処理部、２３ ネットワークインターフェイス、２４ オーディオデータ処理部、２５ スピーカ、２６ アンテナ、２７ チューナ、Ｄ１ 実行ファイルディレクトリ情報、Ｄ２ アイコン画像データ、Ｄ３ コマンド識別テーブル、Ｂ１ ランチャー機能処理ブロック、Ｂ２ コマンド管理処理ブロック、Ｂ３ ＡＰＩ処理ブロック
Claims (9)
- 複数のアプリケーションプログラムと、これら複数のアプリケーションプログラムを管理するプログラムであるオペレーティングシステムと、上記オペレーティングシステムにより管理される上記アプリケーションプログラムの１つであり、他のアプリケーションプログラムに対応する各コマンドを管理可能とされるコマンド管理アプリケーションと、が記憶される記憶手段と、
外部から与えられるイベントをコマンドとして入力する入力手段と、
上記記憶手段に記憶されたプログラムを実行することによって、
上記オペレーティングシステムが、上記入力手段により入力されたコマンドをアクティブなアプリケーションに転送し、
上記アクティブなアプリケーションプログラムが、上記コマンドに対応する処理を実行できないと判定したときに、上記コマンド管理アプリケーションに上記コマンドを転送し、
上記コマンド管理アプリケーションが、上記コマンドに対応する処理を実行可能な非アクティブなアプリケーションプログラムに上記コマンドを転送し、
上記非アクティブなアプリケーションプログラムが上記コマンドに対応する処理を実行する、ようにされた実行処理手段と、
を備えることを特徴とする情報処理装置。 - 上記他のアプリケーションプログラムは、階層化された複数のウィンドウを表示する機能を有し、
上記実行処理手段は、
上記記憶手段に記憶されたプログラムを実行することによって、
上記オペレーティングシステムが、上記入力手段により入力したコマンドをアクティブなアプリケーションプログラムのアクティブウィンドウに転送し、
上記アクティブウィンドウ上では、上記コマンドに対応する処理を実行できないと判定したときに、上記アクティブウィンドウよりも上位階層のウィンドウに上記コマンドを転送し、
上記コマンドに対応する処理を実行可能な上記上位階層のウィンドウが無いと判定される場合に、上記コマンド管理アプリケーションに上記コマンドを転送し、
上記コマンド管理アプリケーションが、上記コマンドに対応する処理を可能な非アクティブなアプリケーションプログラムに上記コマンドを転送し、
上記非アクティブなアプリケーションプログラムが上記コマンドに対応する処理を実行する、
ことを特徴とする請求項１に記載の情報処理装置。 - 上記入力手段は、
上記イベントとして、リモートコントローラから送信されたコマンド信号を受信することで、上記コマンドを入力可能に構成されている、
ことを特徴とする請求項１に記載の情報処理装置。 - 複数のアプリケーションプログラムと、これら複数のアプリケーションプログラムを管理するプログラムであるオペレーティングシステムと、上記オペレーティングシステムにより管理される上記アプリケーションプログラムの１つであり、他のアプリケーションプログラムに対応する各コマンドを管理可能とされるコマンド管理アプリケーションとを、情報処理装置に記憶させたうえで、
上記オペレーティングシステムが、外部からのイベントに応じて入力されたコマンドをアクティブなアプリケーションに転送する第１の転送ステップと、
上記アクティブなアプリケーションプログラムが、上記コマンドに対応する処理を実行できないと判定したときに、上記コマンド管理アプリケーションに上記コマンドを転送する第２の転送ステップと、
上記コマンド管理アプリケーションが、上記コマンドに対応する処理を実行可能な非アクティブなアプリケーションプログラムに上記コマンドを転送する第３の転送ステップと、
上記非アクティブなアプリケーションプログラムが上記コマンドに対応する処理を実行する実行ステップ、
とを実行するように構成されることを特徴とする情報処理方法。 - 自己がアクティブな状態である場合に、オペレーションシステムとしてのプログラムが転送してきた、外部からのイベントに応じて入力されたコマンドについて、自己が処理を実行可能であるか否かを判定する判定ステップと、
上記判定ステップにより、上記コマンドについて処理を実行できないと判定した場合には、上記コマンドに対応する処理をすべき非アクティブなアプリケーションプログラムに対して上記コマンドを転送可能なコマンド管理アプリケーションに、上記コマンドを転送する転送ステップと、
を情報処理装置に実行させることを特徴とするプログラム。 - 階層化された複数のウィンドウを表示出力させる表示ステップと、
上記オペレーティングシステムがアクティブウィンドウに対して転送してきた、外部からのイベントに応じて入力されたコマンドについて、自己が処理を実行可能であるか否かを判定するウィンドウ対応判定ステップと、
上記ウィンドウ対応判定ステップにより、アクティブウィンドウ上では上記コマンドに対応する処理を実行できないと判定したときに、上記アクティブウィンドウよりも上位階層のウィンドウに上記コマンドを転送する、第１のウィンドウ対応転送ステップと、
上記コマンドに対応する処理を実行可能な上記上位階層のウィンドウが無いと判定される場合に、上記コマンド管理アプリケーションに上記コマンドを転送する、第２のウィンドウ対応転送ステップと、
をさらに情報処理装置に実行させることを特徴とする、請求項５に記載のプログラム。 - 外部イベントに対応してオペレーティングシステムから転送されたコマンドに対応する処理を実行できないアクティブなアプリケーションプログラムから転送されてきた上記コマンドを、上記コマンドに対応する処理が可能な非アクティブなアプリケーションプログラムに転送する転送ステップ、
を情報処理装置に実行させることを特徴とするプログラム。 - 自己がアクティブな状態である場合に、オペレーションシステムとしてのプログラムが転送してきた、外部からのイベントに応じて入力されたコマンドについて、自己が処理を実行可能であるか否かを判定する判定ステップと、
上記判定ステップにより、上記コマンドについて処理を実行できないと判定した場合には、上記コマンドに対応する処理を実行すべき非アクティブなアプリケーションプログラムに対して上記コマンドを転送可能なコマンド管理アプリケーションに、上記コマンドを転送する転送ステップと、
を情報処理装置に実行させるプログラムが記憶される記憶媒体。 - 外部イベントに対応してオペレーティングシステムから転送されたコマンドに対応する処理を実行できないアクティブなアプリケーションプログラムから転送されてきた上記コマンドを、上記コマンドに対応する処理が可能な非アクティブなアプリケーションプログラムに転送する転送ステップ、
を情報処理装置に実行させるプログラムが記憶される記憶媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002195029A JP2004038578A (ja) | 2002-07-03 | 2002-07-03 | 情報処理装置、情報処理方法、プログラム、記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002195029A JP2004038578A (ja) | 2002-07-03 | 2002-07-03 | 情報処理装置、情報処理方法、プログラム、記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004038578A true JP2004038578A (ja) | 2004-02-05 |
| JP2004038578A5 JP2004038578A5 (ja) | 2005-09-29 |
Family
ID=31703571
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002195029A Pending JP2004038578A (ja) | 2002-07-03 | 2002-07-03 | 情報処理装置、情報処理方法、プログラム、記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004038578A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006338173A (ja) * | 2005-05-31 | 2006-12-14 | Toshiba Corp | 情報処理装置および表示制御方法 |
| JP2022525433A (ja) * | 2019-04-05 | 2022-05-13 | ソニー・インタラクティブエンタテインメント エルエルシー | リモートデバイスを使用したメディアマルチタスク |
-
2002
- 2002-07-03 JP JP2002195029A patent/JP2004038578A/ja active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006338173A (ja) * | 2005-05-31 | 2006-12-14 | Toshiba Corp | 情報処理装置および表示制御方法 |
| JP4653561B2 (ja) * | 2005-05-31 | 2011-03-16 | 株式会社東芝 | 情報処理装置および表示制御方法 |
| JP2022525433A (ja) * | 2019-04-05 | 2022-05-13 | ソニー・インタラクティブエンタテインメント エルエルシー | リモートデバイスを使用したメディアマルチタスク |
| JP7278409B2 (ja) | 2019-04-05 | 2023-05-19 | ソニー・インタラクティブエンタテインメント エルエルシー | リモートデバイスを使用したメディアマルチタスク |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6690392B1 (en) | Method system software and signal for automatic generation of macro commands | |
| US20090077491A1 (en) | Method for inputting user command using user's motion and multimedia apparatus thereof | |
| CN100341319C (zh) | 音频/视频设备中外接装置的菜单驱动控制方法 | |
| US8316322B2 (en) | Method for editing playlist and multimedia reproducing apparatus employing the same | |
| JP2001093226A (ja) | 情報通信システムおよび方法、ならびに、情報通信装置および方法 | |
| JP2004288197A (ja) | スクリーンエリアインセット内にデータ表現を提示するためのインターフェース | |
| US7685324B2 (en) | Audio-video processing apparatus and program therefor | |
| KR100639767B1 (ko) | 전자기기 및 전자기기의 동작제어방법 | |
| US7769946B2 (en) | Information processing apparatus and information processing method | |
| JP2001067163A (ja) | 情報処理装置および情報処理方法、並びに記録媒体 | |
| US7991759B2 (en) | Communication apparatus, communication method and communication program | |
| JP2004038578A (ja) | 情報処理装置、情報処理方法、プログラム、記録媒体 | |
| JP4023233B2 (ja) | 情報出力装置、情報出力方法、プログラム、記憶媒体 | |
| JP2002197015A (ja) | データ配信システム及びデータ配信方法 | |
| JP2009037320A (ja) | 情報処理装置、情報処理装置の制御方法 | |
| JP4191221B2 (ja) | 記録再生装置、同時記録再生制御方法、および同時記録再生制御プログラム | |
| JP2002108747A (ja) | ダウンロードシステム、情報処理装置、及び記録媒体 | |
| JP2004318607A (ja) | 情報処理装置、情報処理方法、プログラム、記憶媒体 | |
| JP2003196177A (ja) | 情報処理システムおよび方法、情報処理装置および方法、記録媒体、並びにプログラム | |
| KR20140038791A (ko) | 멀티미디어 데이터 재생방법 및 이를 적용한 멀티미디어 재생장치 | |
| JP4151544B2 (ja) | 記録装置、記録方法およびプログラム | |
| JP4595138B2 (ja) | リモートコントロールシステム及び監視アプリケーションプログラム | |
| JP2002108363A (ja) | ダウンロードシステム、携帯型情報処理装置、及び、記録媒体 | |
| JP2005293408A (ja) | 電子機器装置、サーバ装置、制御方法及びそのプログラム | |
| WO2001027925A1 (fr) | Unite de traitement d'informations, procede de traitement et support d'enregistrement |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050509 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050509 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070227 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070501 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20071016 |