JP4002442B2 - ネットワーク機器汎用相互通信装置 - Google Patents
ネットワーク機器汎用相互通信装置 Download PDFInfo
- Publication number
- JP4002442B2 JP4002442B2 JP2002008364A JP2002008364A JP4002442B2 JP 4002442 B2 JP4002442 B2 JP 4002442B2 JP 2002008364 A JP2002008364 A JP 2002008364A JP 2002008364 A JP2002008364 A JP 2002008364A JP 4002442 B2 JP4002442 B2 JP 4002442B2
- Authority
- JP
- Japan
- Prior art keywords
- output
- user interface
- input
- intercommunication
- devices
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- User Interface Of Digital Computer (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク化された家庭用機器や個人用機器との汎用的な相互通信を行うためのネットワーク機器汎用相互通信装置に関する。
【０００２】
【発明が解決しようとする課題】
我々の毎日の生活は、コンピュータを内蔵した種々の対象物により劇的に変化をするであろう。これらの対象物は、人々の身体と記憶を拡大するため知的な動作をするものと期待される。
【０００３】
こうしたコンピュータ環境を実現する為に、これまで多くの研究プロジェクトが種々の問題に挑戦している。これらのコンピュータ環境は、広くユビキタス（Ubiquitous：どこにでもある）・コンピューティングと呼ばれている。また、他の研究者たちは、パーベーシブ・コンピューティング（"pervasive computing"）、センティエント・コンピューティング（"sentient computing"）或いはシングス・ザット・シンク（"Things That Think"）と呼ばれる同様の概念を提案している。ユビキタス・コンピューティング環境においては、種々の対象物がコンピュータを内包することにより増加される。如何なるプログラムも、コンピュータによって実行することができるので、プログラムを置き換えることにより、これらの対象物は無限に拡張される可能性を持っている。また、これらの対象物は、他の対象物と通信を行なうネットワークを持つので、周囲を取り巻く状況に従って、各対象物がそれぞれでプログラムを置き換えることにより、一層アクティブに動作するであろう。例えば、我々の環境は我々に代わって世界中に起こっていることを記憶するかもしれないし、各々の対象物が現時点で存在する場所を我々に教えるかもしれない。
【０００４】
前述したように、前記ユビキタス・コンピューティング環境を実現する為に、多くの研究が成されている。或る研究グループは、ユビキタス・コンピューティング環境のプロトタイプ（代表例）を構築する作業を行なってきた。これらの研究は、ユビキタス・コンピューティングが我々の生活に与えるインパクトを示している。また最近は、幾つかの標準ミドルウェアの仕様が、ユビキタス・コンピューティングを実現するために提案されている。ミドルウェアとは、いわゆるOS（Operating System）上で動作し、アプリケーションソフトに対してOSよりも高度で具体的な機能を提供するソフトウェアのことで、OSとアプリケーションソフトの中間的な性格を持っている。そのなかで、ネットワークを通じて各種機器を接続し、相互に機能を提供しあうための技術仕様であるJini（登録商標）や、同じように家庭内のパソコンや周辺機器、AV機器、電話、家電製品などの機器をネットワークを通じて接続し、相互に機能を提供しあうための技術仕様であるUPnP（ユニヴァーサル・プラグアンド・プレイ）は、ミドルウェアとして良く知られているが、これらは分散された環境の中で種々のサービスを発見する機構を備えている。また、別なミドルウェアとして知られるHAVi（Home Audio/Video Interoperability）は、ネットワーク化された家庭用機器の発展を可能にする。それ故に、家庭環境におけるユビキタス・コンピューティングは、近い将来に実現されるであろう。こうしたユビキタス・コンピューティング環境は、ホーム・コンピューティングと呼ばれるが、ホーム・コンピューティングは、我々の日常生活に直接関係があるので、とりわけ興味深い分野ではある。また、総ての人は、ホーム・コンピューティング環境の急激な進歩を期待しているので、ユビキタス・コンピューティングの効果を示すことは的を得ていることである。
【０００５】
こうしたホーム・コンピューティング環境で最も重要な問題の一つは、コンピュータを内蔵した種々の対象物が、如何に相互通信し合うかということである。利用者と種々の対象物に内蔵されたコンピュータ間の相互通信は、従来から幾つかの研究グループにより開発が行なわれていた。これらの装置によれば、より自然に内蔵したコンピュータと相互通信を行なうことができる。しかしながら、ネットワーク化された家庭用機器向けの現在の標準ミドルウェアは、Java（登録商標）に標準で付属するグラフィック関連のクラスライブラリとして知られるJava AWTや、同じようにグラフィック関係のライブラリとして知られるGTK+の様な、従来からある標準グラフィカル・ユーザー・インターフェースを採用してきた。それ故に、PDA，携帯電話あるいは上記研究段階のプロトタイプ相互通信機器から、家庭用の機器を制御することは容易なことではない。また、利用者の現在の状況によって、自然な相互通信は変化する。例えば、利用者が食事を料理しているならば、音声によって機器を制御したいが、ソファの上でTVを見ている場合は、リモート・コントロールを使うのが良いのかもしれない。このことは、最も適当な相互通信は、利用者の現在の状況と好みによってダイナミックに選定すべきであり、この相互通信装置の選定は、利用者が家庭内，事務所或いは公共の場所のように如何なる場所に居ようと、一貫したものであることを意味している。
【０００６】
そこで本発明は、利用者がいかなる場所にいたとしても、従来の標準グラフィカル・ユーザー・インターフェースをそのまま利用して、一様な手順で機器の制御を行なうことができるネットワーク機器汎用相互通信装置を提供することをその目的とする。
【０００７】
【課題を解決するための手段】
本発明の請求項１におけるネットワーク機器汎用相互通信装置は、利用できる機器に応じて、その機器を制御するのに必要なグラフィカル・ユーザー・インターフェースを生成して提示するアプリケーション手段と、前記機器を制御するためのコマンドを伝送する入力装置と、表示手段を備えた出力装置と、前記入力装置および出力装置と前記アプリケーション手段との間に介在するプロキシ手段とを備え、前記プロキシ手段は、前記入力装置や前記出力装置から受信メッセージを受け取ることにより、現在利用可能な入力装置や出力装置を検出してそれを選択する利用可能装置検出手段を備えたネットワーク機器汎用相互通信装置において、 前記機器からの出力イベントとして、前記アプリケーション手段から汎用相互通信プロトコルによって送られてきたグラフィカル・ユーザー・インターフェースに含まれるビットマップ・イメージを、前記利用可能装置検出手段が選択した前記出力装置の表示手段に表示できるように、該出力装置の特性に従ってコード変換して、このコード変換したビットマップ・イメージを含むグラフィカル・ユーザー・インターフェースを該出力装置の表示手段に転送する出力管理手段と、前記利用可能装置検出手段が選択した前記入力装置からコマンドを受取ると、このコマンドを前記アプリケーション手段が認識できるマウス或いはキーボードのイベントに変換し、この変換したマウス或いはキーボードのイベントを、前記機器への入力イベントとして、汎用通信プロトコルによって該アプリケーション手段へ伝送する入力管理手段と、を前記プロキシ手段にさらに備えて構成される。
【０００８】
この場合、利用可能な機器に応じたグラフィカル・ユーザー・インターフェースが、その機器からの出力イベントとして、アプリケーション手段から汎用相互通信プロトコルによってプロキシ手段に送られると、そのグラフィカル・ユーザー・インターフェースに含まれるビットマップ・イメージは、プロキシ手段により現在利用可能な出力装置の表示手段に適合するように、この出力装置の特性に従ってコード変換され、そのコード変換されたビットマップ・イメージを含むグラフィカル・ユーザー・インターフェースが表示手段に転送される。また、利用者が利用可能な機器を制御するには、表示手段に表示されるグラフィカル・ユーザー・インターフェースを参照しながら、現在利用できる入力装置から適宜コマンドを伝送すればよい。こうすれば、どのような入力装置であっても、プロキシ手段は伝送されたコマンドを、汎用相互通信プロトコルに適合するマウスまたはキーボードのイベントに変換し、それを機器への入力イベントとして、アプリケーション手段に伝送する。
【０００９】
つまり、ここでのプロキシ手段は異種の入力装置や出力装置を同じように取り扱う手段としての機能を果すので、現存する標準のグラフィカル・ユーザー・インターフェースを変更することなく、種々の入力装置や出力装置を使って、一様な手順で機器の制御を行なうことができる。特に、キーボード／マウスを汎用入力イベントとして採用し、ビットマップ・イメージを汎用出力イベントとして採用することで、あらゆる入力装置や出力装置との接続のために、従来のグラフィカル・ユーザー・インターフェースのツールキットを利用することができる。
【００１０】
また、本発明の請求項２におけるネットワーク機器汎用相互通信装置は、前記入力装置から所望の前記出力装置を選択するコマンドを受取ると、前記利用可能装置検出手段による選択に優先して、この出力装置の表示手段が表示できるグラフィカル・ユーザー・インターフェースを、該出力装置に転送するように、前記出力管理手段を構成したものである。
【００１１】
このようにすると、入力装置から表示したい出力装置を選択するコマンドを伝送すると、その出力装置の表示手段に適合したグラフィカル・ユーザー・インターフェースがプロキシ手段から送り出される。したがって、利用者の状況や好みに応じた出力装置の切替えが可能となり、利用者と機器との間を独自のものとすることができる。
【００１２】
本発明の請求項３におけるネットワーク機器汎用相互通信装置は、前記アプリケーション手段が現在利用可能な前記機器を特定するために、プラグ・アンド・プレイ機能を有したネットワークを通じて該機器を接続したことを特徴とする。
【００１３】
プラグ・アンド・プレイ機能を有するネットワークは、どの機器が現在接続されているか、誰のパワースイッチがオンになっているかを知らせる機構をサポートしているので、アプリケーション手段が現在利用可能な機器を容易に知ることができると共に、最も相応しいユーザー・インターフェースを容易に選定することができる。
【００１４】
【発明の実施形態】
以下、添付図面を参照しながら、本発明における好適な実施例を説明する。先ず実施例の詳細を説明する前に、ホーム・コンピューティング環境において、利用者との相互通信すなわち対話をサポート（支援）する幾つかの設計選択について説明する。
【００１５】
本発明の目的を達成するための方法は数種ある。最も重要な論点は、種々の相互通信装置（デバイス）を如何に支援するかである。従来のユーザー・インターフェース・システムは、数種の相互通信装置のタイプを想定している。例えば、マウス，トラック・ポイントそしてタッチ・スクリーンは、入力装置として使用される。柔軟なユーザー・インターフェース・システムを構築する手法としては、次の３つの代案が考えられる。
（１）零の状態から新規のユーザー・インターフェース・システムを構築する。
（２）従来からある種々の相互通信装置用の各ユーザー・インターフェース・システムを呼び出す新たな装置の独立層（レイヤ）を構築する。
（３）従来のユーザー・インターフェース・システムの入力／出力イベントを獲得し、相互通信装置に従ってそのイベントを翻訳する。
【００１６】
（１）の手法は、最初から種々の相互通信装置によって使用される新規なユーザー・インターフェース・システムの構築を意味する。この手法は、システムが新たな相互通信装置に適応されることを考慮に入れるので、新相互通信装置が出現した時に生き長らえることができる。しかしながら、現存の機器とミドルウェアのコンポーネント（構成要素）を新たなユーザー・インターフェース・システムに編入する為には修正が必要であり、その開発には長い期間を必要とする。多くのホーム・コンピューティング・システムは、すでに現存のソリューション（問題点の解決や要求の実現を行なうための情報システム）を採用しているので、現在使用されているユーザー・インターフェース・システムを置き換えるこことは不可能であろう。
【００１７】
（２）の手法は、従来のユーザー・インターフェース・システム上に新しい層を追加することにより、種々の相互通信装置を支援する2つの案がある。第１案は、相互通信装置の独立層が、アプリケーションの標準的な要求を各ユーザー・インターフェース・システムへの要求に翻訳する。例えば、こうした手法に基礎を置いた文献の中では、利用者と機器との間の相互通信方法を含むドキュメントを、アプリケーションが指定している。装置の独立層は、現存する各ユーザー・インターフェース・システム用のドキュメントを提供する。第２案であるマルチプル・ユーザー・インターフェース・システムにおいて、各機器は、getUI( )法を提供する。この方法は、マルチプル・ユーザー・インターフェース・サポート・サービスへ参照信号を返し、各相互通信装置に最も適したユーザー・インターフェースを提供する。双方の案は、非常に将来性があるが、第１案の様に現存のアプリケーションを修正する必要があり、装置の独立層がそれぞれの相互通信装置に対し実行されなければならない。それ故に、この手法は、ホーム・コンピューティング用に現存する標準仕様を支援するには適当ではない。
【００１８】
最後の（３）の手法は、ユーザー・インターフェース・システムによって生成されたビットマップ・イメージが、機器制御のために相互通信装置の特性に従がって変換される。また、相互通信装置からの入力イベントは、マウス或いはキーボードのイベントに変換される。この手法では、入力／出力イベントの変換のために、グラフィカル・ユーザー・インターフェース（GUI）内のレイアウト情報を利用できないという制限がある。しかし、大部分の家庭用音響映像機器は、グラフィカル・ユーザー・インターフェースを提示する表示装置を備えている。この場合の最も重要な要求とは、グラフィカル・ユーザー・インターフェースを提示する表示装置と、利用者の状況や好みに応じて、グラフィカル・ユーザー・インターフェースを提示する入力装置を変えたいということであるが、こうした要求は、（３）の手法において非常に上手く達成できる。一方、この手法は、ホーム・コンピューティング用の現存のソフトウェアを修正する必要は無い。また、従来のホーム・コンピューティング用標準ミドルウェアで採用されてきたJava AWT/Swing，X window system，Microsoft Windows（登録商標）のような人気のあるユーザー・インターフェース・システムの大部分は、本手法にて極めて容易に採用できる。
【００１９】
ここでは、HAViを実行するホーム・コンピューティング・システムがJava AWTの使用を必要としており、しかも近い将来に、修正を行なうことなくHAViに基づき開発される種々のホーム・コンピューティング・アプリケーションを使いたいという前提で、（３）の手法に基づく実施例を説明する。特に最近の興味は、家庭用機器を構築するためのLinux を内蔵した使用形態にあって、それは（３）の手法をより実際的なものにする。何故なら、Linuxはその基本的ユーザー・インターフェース・システムとして、X windows システムを通常は取り入れており、内蔵したLinux上の種々のアプリケーションが、種々の相互通信装置により制御されることを、本実施例で提案するシステムが可能にするからである。こうしたアプリケーションは、従来の良く知られているユーザー・インターフェース・ツールキットを使用可能であるので、この手法は、種々の内蔵アプリケーションを極めて容易に発展させることができる。
【００２０】
本実施例で以後説明する（３）の手法において、入力／出力相互通信装置と機器との間の通信に広く利用できるプロトコルを、ここで汎用相互通信（"universal interaction"）と呼ぶ。この汎用相互通信は、均一な方法にて種々の家庭用機器を制御することができる。このことは、何処にいて何を制御したいかによって、人々の行動が制限を受けないことを意味する。したがって、ここでの手法は、家庭用機器との極めて自然な相互通信を提供する。
【００２１】
機器からの出力イベントは汎用出力相互通信イベントに変換され、そのイベントは、それぞれの出力相互通信装置に向けて翻訳される。また、入力相互通信装置で発生する入力イベントは汎用入力相互通信イベントに翻訳され、そのイベントは機器内で実行されるアプリケーションにより処理される。
【００２２】
後述するUniIntプロキシと呼ばれる汎用相互通信プロキシは、汎用相互通信プロトコルと各相互通信装置の入力／出力イベント間の変換を広範囲に行なう役割を演じる。もしも、各入力／出力相互通信装置のイベントが汎用相互通信プロトコルに変換されるならば、プロキシは機器の制御のために如何なる入力／出力相互通信装置の使用も可能にする。この手法は、次のような三つの非常に魅力的な特徴を提供する。
【００２３】
第１の特徴は、入力相互通信装置と出力相互通信装置が、利用者の状況と好みによって、それぞれ独自に選択されることである。例えば、利用者は、PDAを入力／出力相互通信装置に選択できる。また、利用者は、携帯電話を入力相互通信装置に選択してもよいし、またテレヴィジョンも出力相互通信装置として選択してもよい。利用者は、携帯装置により生じる拡大された実世界を操作することで、自分の意思表示によって機器を制御できる。
【００２４】
第２の特徴は、利用者の好みに応じてそれに相応しい入力／出力相互通信装置を選択できることである。しかも、これらの相互通信装置は、利用者の現在の状況によってダイナミックに変更される。例えば、入力相互通信装置として携帯電話を使用している利用者は、別の仕事のために現在両手が塞がっているので、相互通信装置を音声入力システムに変えるであろう。
【００２５】
第３の特徴は、もしもユーザー・インターフェース・システムが汎用相互通信プロトコルと交信できれば、機器内で実行中の如何なるアプリケーションでも、あらゆるユーザー・インターフェース・システムを利用できることである。例えば、キーボード／マウスを汎用入力イベントとして採用し、ビットマップ・イメージを汎用出力イベントとして採用した場合、あらゆる相互通信装置との接続のために、Java AWT, GTK+ そしてQtのような従来のグラフィカル・ユーザー・インターフェースのツールキットを利用することができる。
【００２６】
実際、家庭用電化製品の殆どの標準仕様は、GUI（グラフィカル・ユーザー・インターフェース）標準用のJava AWTを最近は採用する傾向にある。かくして、本手法を取り入れたシステムは、将来の各種家庭用電化製品を、種々の相互通信装置から、それらのアプリケーションを修正することなく制御することが可能になるであろう。現存のGUI標準を変更することは非常に難しいので、この特徴は非常に望ましいものである。
【００２７】
本実施例におけるシステムは、グラフィカル・ユーザー・インターフェースを描くためにビットマップ・イメージを転送すると共に、入力用マウス／キーボードのイベントを処理するために、シンクライアント・システム（"thin-client system"）を使用する。通常のシンクライアント・システムは、ビューアとサーバから成る。サーバは、アプリケーションが動作する機器上で実行される。アプリケーションは、X window systemの様な従来のユーザー・インターフェースを使って、グラフィカル・ユーザー・インターフェースを実行する。ユーザー・インターフェース・システムにより作られるビットマップ・イメージは、通常はもう一つの機器上で実行されるビューアへ送信される。一方、ビューアによって読み込まれるマウスとキーボード・イベントは、サーバへ転送される。ビューアとサーバ間のプロトコルは、標準プロトコル（例えば、前記VNCシステムに於いては、RFB（Remote Frame Buffer）プロトコルと呼ばれる）として規定される。ここでは、こうしたプロトコルを汎用相互通信プロトコル（universal interactionprotocol）と呼ぶ。本システムは、利用者の居場所に従って利用者の表示部（デスクトップ）を動かしたり、例えばMS Windows（登録商標）とX Window systemの両方というように、同一画面上に複数の表示部を表示する。
【００２８】
本システムでは、シンクライアント・システムのビューアを、UniInt（Universal Interaction：汎用相互通信）サーバから受け取ったビットマップ・イメージを出力装置へ転送するUniIntプロキシに置き換える。この手法では、如何なるシンクライアント・システムのサーバも、UniIntサーバとして使用可能である。また、UniIntプロキシは、入力相互通信装置から受け取った入力イベントをUniIntサーバへ転送する。
【００２９】
本実施例におけるシステムは、図１に示すように、次の主要な５つの構成要素から成る。すなわちそれは、家庭用機器（図示せず）のアプリケーション１と、前記UniIntサーバ２と、UniInt プロキシ３と、入力装置４と、出力装置５である。
【００３０】
表示操作制御手段に相当する家庭用機器のアプリケーション１は、現在使用できる家庭用機器を制御するのに必要なグラフィカル・ユーザー・インターフェース（表示操作形態）を作成するものである。例えば、家庭用機器としてTV（テレヴィジョン）が現在利用できるならば、アプリケーション１は、TV用のユーザー・インターフェースを作成する。一方、アプリケーション１は、いずれも家庭用機器であるTVとVCR（デジタルビデオカメラ）が現在両方とも利用できるならば、TVとVCR用のGUIを構成する。
【００３１】
汎用相互通信サーバに相当するUniIntサーバ２は、windowシステムによって作られるビットマップ・イメージを、汎用相互通信プロトコルを使って、UniIntプロキシ３へ送り出すと共に、UniIntプロキシ３から受け取ったマウスとキーボードの各イベントを、windowシステムに転送する機能を有する。現在の実行例では、現存するシンクライアント・システムのサーバを修正する必要はないし、UniIntサーバ２をサポートするwindowシステム上で動作するあらゆるアプリケーションを、修正を行なわずにシステムで制御することが可能である。
【００３２】
プロキシ手段としての汎用相互通信プロキシに相当するUniIntプロキシ３は、内部ネットワークとインターネットの境にあって、直接インターネットに接続できない内部ネットワークの機器に代わって、インターネットとの接続を代理して行なうもので、ネットワークに出入りするアクセスを一元管理し、内部から特定の種類の接続のみを許可したり、外部からの不正なアクセスを遮断するために用いられるが、これはとりわけ本システムにおいて最も重要な構成要素である。UniIntプロキシ３は、UniIntサーバ２から受け取ったビットマップ・イメージを、出力装置５の特性に従って変換する。また、UniIntプロキシ３は、入力装置４から受け取ったイベントを、UniIntサーバ２との間の汎用相互通信プロトコルに適応するマウス若しくはキーボードのイベントへと変換する。UniIntプロキシ３は、各機器を制御するために、現在の適正な入力／出力相互通信装置４，５を選択する。次に、選択された入力装置４は入力プラグイン・モジュールの信号を送信すると共に、選定された出力装置５は出力プラグイン・モジュールの信号をUniIntプロキシ３に送信する。入力プラグイン・モジュールは、入力装置４から受け取ったイベントをマウスやキーボードのイベントへ翻訳するコードを備えている。出力プラグイン・モジュールは、UniIntサーバ２から受け取ったビットマップ・イメージを、目標となる出力装置５の画面上に表示することのできるイメージに変換するコードを備えている。
【００３３】
入力装置４は、利用者との相互通信をサポートするもので、家庭用機器を制御するための利用者により発せられたコマンドを伝送するものである。出力装置５は、機器を制御するのに必要なグラフィカル・ユーザー・インターフェースを表示するための表示手段（表示装置）を備えている。
【００３４】
UniIntプロキシ３は、異種の相互通信装置４，５を扱う役目を演じる。また、UniIntプロキシ３は、利用者の状況や好みに応じて相互通信装置４，５の切り替えも可能である。これにより、利用者と機器との間を独自のものとすることができる。
【００３５】
ここでのUniIntプロキシ３はJava言語により書かれており、実施例では、図１に示す如く４つのモジュール部を備えている。第１のモジュールは、汎用相互通信プロトコルモジュール11であり、これはUniIntサーバ２と通信を行なうための汎用相互通信プロトコルを実行するものである。この第1のモジュール11を置き換えると、様々なシンクライアント・システムを備えたシステムを使用することができる。このモジュール11は、シンクライアント・システムの観点にて実行される同様なモジュールを利用できる。第２のモジュールは、プラグイン管理モジュール12で、これは相互通信装置４，５から入力／出力プラグイン・モジュールを受け取ると共に、UniIntプロキシ３内の各モジュールとダイナミックにリンク（連結）するものである。第３のモジュールは、利用可能装置検出手段に相当するプラグ・アンド・プレイ管理モジュール13で、これは現在利用可能な入力／出力相互通信装置４，５を検出するものである。第４のモジュールは、プラグイン移動管理モジュール14で、これは相互通信装置４，５とUniIntプロキシ３との間の入力／出力プラグイン・モジュールの移動を管理するものである。
【００３６】
プラグ・アンド・プレイ管理モジュール13は、UniIntプロキシ３の近くにある現在利用可能な入力装置４や出力装置５を検出する。ここでのシステムでは、独自のIDが各型式の入力装置４や出力装置５に割り当てられる。UniIntプロキシ３は、周期的にビーコン・メッセージを放送する。現行のプロトタイプ（代表例）では、相互通信装置４，５は、IEEE802.11b，Ethernet（登録商標）或いは赤外線ネットワークを通じて接続される。各相互通信装置４，５がビーコン・メッセージを受け取ると、そこから受信メッセージを回答する。受信メッセージは、その機器の型式を確認する独自のIDを含んでいる。仮にUniInt プロキシ３が、複数の相互通信装置４，５からそれぞれの受信メッセージを受け取ると、UniIntプロキシ３は、UniInt プロキシ３によって定められた選択に従って一つの相互通信装置４，５を選定する。また、新規に検出された相互通信装置４，５が受信メッセージを回答すると、例えその装置が現在使用されている装置より好ましいものであれば、その装置は現在使用中の相互通信装置４，５として選択される。
【００３７】
UniIntプロキシ３が、その相互通信装置４，５の検出後に新たな相互通信装置４，５を選択する場合は、新たな相互通信装置４，５の使用前に確認メッセージを送る。それからUniIntプロキシ３は、現在まで使われている相互通信装置４，５へ最終メッセージを送る。最後にUniIntプロキシ３は、新たな相互通信装置４，５からのプラグイン・モジュールの受け取りを待つ。入力装置４や出力装置５の選定は、各利用者用のUniIntプロキシ３中に登録されている。仮にシステムが機器を利用したい者を検出できない場合は、優先して不履行（デフォルト）が選択される。また、プラグイン・モジュールのそれぞれは、現在使用中の入力装置４や出力装置５を切り替えるイベントを支援する。例えば、現在使用されている出力装置５を変更するために、利用者はUniIntプロキシ３に対しコマンドを送ることができる。UniIntプロキシ３は、利用者が自分の好みの出力装置５を選択するまでは、現在の出力装置４を次の出力装置５に切り替える。
【００３８】
UniIntプロキシ３からの受信メッセージを受け取ると、入力装置４や出力装置５は、プラグイン・モジュールをUniIntプロキシ３に送る。本システムでは、入力装置４や出力装置５とUniIntプロキシ３と間のプラグイン・モジュールを送信するために、MobileSpace移動体システムを使用している。UniIntプロキシ３内で実行されるJavaの仮想機器内にプラグイン・モジュールがダウンロードされた後、プラグイン移動モジュール14は、入力／出力装置４，５へ移動完成メッセージを送る。MobileSpaceシステムは階層的エージェント（代理人）をサポートしており、同一階層レベルに存在する場合に、エージェントは通信を行なうことができる。それ故に、利用者はまたモバイルエージェントとしてUniIntプロキシ３を実行するが、そのエージェントは別のホストへ移動されない。しかしながら、その特徴は、入力／出力装置４，５から近くのコンピュータへUniIntプロキシ３を移動させるのに利用してもよい。
【００３９】
ここでは、現存するJava言語で書かれたモバイルエージェントシステムを使用することを想定しているが、幾つかの制限のために装置の中にはJava仮想機械（VM）を持つことができないものもあるので、総ての装置においてJavaを使うという仮定は限界があると考える。その場合、エージェントを他のコンピュータへ送る為に、Ｃ言語で書かれた非常に小さなランタイム（アプリケーションソフトを実行する際に必要となるソフトウェアモジュール(部品)）を構築することを考慮してもよい。このランタイムは、エージェントを実行できないが、別のランタイムへエージェントを送信できる。この様な小さなランタイム機能部は、種々の相互通信装置４，５を支援する為に、望ましいものであると考える。また、この手法により、豊富な機能を提供するJavaに基づいたモバイルエージェントシステムを、全般的に採用することができる。このことは、非常に異なった要求を持つ如何なる装置に置いても使用可能な、標準的なモバイルエージェントシステムを構築することが可能であることを意味する。
【００４０】
図２は、プラグイン管理モジュール13，14の機能構成を示すものである。このモジュール13，14は、入力プラグイン・モジュール21と出力プラグイン・モジュール22を含んでいる。入力管理手段としての入力プラグイン・モジュール21は、現在選択されている入力装置４からイベントを受け取るものである。このイベントは、マウス・イベント若しくはキーボード・イベントに変換され、変換されたイベントは、汎用相互通信プロトコルによって、UniIntサーバ２へ伝送される。例えば、利用者が右側の矢を描くボタンに触れると、そのイベントは入力装置４であるPDA（携帯情報端末）装置から発信され、入力プラグイン・モジュール21へと送信される。送信されたイベントは、右へのマウスの移動イベントへと翻訳され、そのイベントは最終的にwindowシステムに転送される。
【００４１】
同様に、UniIntプロキシ３内の汎用相互通信プロトコル・モジュール11により、UniIntサーバ２からビットマップ・イメージを受け取った後、出力管理手段としての出力プラグイン・モジュール22は、出力装置５へ伝送する前に、そのビットマップ・イメージを処理する。例えば、UniIntサーバ２から受け取った色彩イメージは白黒イメージに変換される。また、画像サイズは、出力装置５であるPDA装置の画面に縮小表示される。
【００４２】
本システムでは、２つの出力プラグイン・モジュール22と３つの入力プラグイン・モジュール21を供給する。第１の出力プラグイン・モジュール22Ａは、標準のVGA画面にビットマップ・イメージを描くもので、第２の出力プラグイン・モジュール22ＢはPalm Pilot用である。また３つの入力プラグイン・モジュール21Ａ，21Ｂ，21Ｃは、それぞれキーボードおよびマウス，Palm Pilot，コンパクトHTMLを支援するウェッブ・ブラウザを有する携帯電話用である。
【００４３】
ホーム・コンピューティング・アプリケーション１の役割は、利用者が家庭用機器を制御できようにすることである。利用者と家庭用機器間の相互通信は、機器の機能が益々豊富になるので、より複雑になるであろう。また機器の数は、将来増加するであろう。それ故に、将来の家庭用機器は、種々の機器との状況認知（"context-aware"）相互通信をサポートしなければならない。
【００４４】
考慮すべき状況認知は、２つの型がある。一番目は、相互通信の個別化である。相互通信は、また利用者の状況に応じてカスタマイズされる。二番目の型は、一個の機器として現在利用できる複数の機器を処理することである。
【００４５】
システムは誰が機器を制御するかを知らないので、機器との相互通信を個別化することは通常困難である。本実施例におけるシステムでは、各利用者がPDA装置や携帯電話などのような自身の保有する制御装置を有することを仮定している。こうした制御装置が、利用者の確認IDを伝送するならば、システムは誰がその機器を制御したいかが判る。しかし本システムにおいては、利用者の確認をサポートしない従来のユーザー・インターフェース・システムをアプリケーション１が採用すると仮定しているので、相互通信装置４，５からホーム・コンピューティング・アプリケーション１へ、その様な情報を伝送する直接の方法は存在しない。それ故に、現在の実施例では、各利用者用に個別化されたアプリケーション１を実行する異なったUniIntサーバ２を、各利用者毎に備えている。アプリケーション１は、利用者の好みに応じてカスタマイズされたユーザー・インターフェースを供給する。UniIntプロキシ３は、入力装置４から得られる利用者の確認に応じて、最も相応しいUniIntサーバ２を選択する。
【００４６】
本実施例におけるシステムは、現在の状況によってどの機器が現在利用できるかを知る必要がある。現在のシステムにおいては、そのアプリケーション１をどの機器が利用できるのかを知っているものと仮定する。例えば、仮にアプリケーション１が３つの家庭用機器をサポートしているならば、そのアプリケーション１は、３つの機器を結合する７個のグラフィカル・ユーザー・インターフェースを提供することが必要である。ユーザー・インターフェースは、現在利用可能な機器に応じて選択される。
【００４７】
一方、入力装置４や出力装置５は種々のものが利用可能であり、入力装置４と出力装置５を分離しても、あるいは結合してもよい。例えば、グラフィカル・ユーザー・インターフェースは、PDA装置の画面上或いはTV上の大型表示装置上に表示できる。TＶ上に表示されるユーザー・インターフェースは、PDA装置により操作することもある。それ故に、利用者は自分の好みによって相互通信方式の多様な選択ができる。またこれらの装置は、現在の状況に応じて変更が可能である。例えば、現在使用中の装置が利用できないならば、別の相互通信装置を機器制御のために選択してもよい。
【００４８】
本システムでは、前述したようにプラグイン・モジュールをUniIntプロキシ３へ送信すると仮定する。しかしながら、マイクロフォンの様なある入力装置４はプログラム化できないし、UniIntプロキシ３への送信をサポートすることは困難である。この場合は、我々は、その装置４を制御処理部であるパソコン（パーソナルコンピュータ）へ接続し、パソコンはUniIntプロキシ３と通信して、プラグイン・モジュールを伝送する。しかしながら、パソコンはマイクロフォンが現在利用可能か否かを理解できないので、ビーコン・メッセージがUniIntプロキシ３から受け取られた場合に、パソコン上のプログラムが確認メッセージを何時戻すのかを知ることは困難である。それ故に、現在のプロトタイプにおいては、その装置４が常に接続され利用可能であると仮定する。
【００４９】
次に、上記構成におけるシステムの動作を説明する。アプリケーション１が、現在利用可能な機器が例えばテレヴィジョンとビデオ・レコーダー（VCR）であると認識した時に、それらを制御するのに必要なグラフィカル・ユーザー・インターフェースを提示する。現在の利用者がそのTVプログラムの予約に興味がないとすると、アプリケーション１は、電源制御、TVチャンネルの選択、VCR機能を含むユーザー・インターフェースをUniIntサーバ２に描く。UniIntプロキシ３は、これ等の機器を制御したい利用者用にカスタマイズされたユーザー・インターフェースを描くアプリケーションを実行するUniIntサーバ２を選択すると共に、その選択されたUniIntサーバ２は、インターフェースを含むビットマップ・イメージをUniIntプロキシ３へ送信する。
【００５０】
ここで、利用者がPDA装置を備えていることを、UniIntプロキシ３が検出したと仮定する。入力／出力装置４，５に相当するPDA装置は、入力／出力プラグイン・モジュールの信号をUniIntプロキシ３に伝送する。UniIntプロキシ３は、ビットマップ・イメージをPDA装置へ送信する前に、出力プラグイン・モジュール22を使って、UniIntサーバ２から送信されたビットマップ・イメージをコード変換する。この場合、画像サイズが640×480の８ビットカラー映像は、画像サイズが、180×120の白黒画像に縮小される。また、PDA装置のタッチ・スクリーン上の入力イベントは、入力プラグイン・モジュール21によって、マウスとキーボード・イベントへ変換される。しかしながら、今、利用者は、グラフィカル・ユーザー・インターフェースを大画面で見たいものと仮定しよう。利用者は、PDA装置のタッチ・スクリーン上を軽く叩いて、UniIntプロキシ３へコマンドを送信する。UniIntプロキシ３がそれを検出すると、グラフィカル・ユーザー・インターフェースを含むビットマップ・イメージは、表示システムへ転送されると共に、ビットマップ・イメージを送信する前に、そのビットマップ・イメージは、大画面の表示システムに与えられるように、出力プラグイン・モジュール22によって変換される。またユーザー・インターフェースは、PDA装置のタッチ・スクリーン上を軽く叩くことにより、このタッチ・スクリーン上に再び表示される。
【００５１】
本実施例におけるシステムでは、種々の家庭用機器を制御するために、新型の携帯装置を使用できる。利用者が、眼鏡処方用レンズと区別のつかないヘッド・マウント・ディスプレイを装着して、テレヴィジョンを制御したいとものと仮定しよう。この場合、テレヴィジョンのグラフィカル・ユーザー・インターフェースが、テレヴィジョンの近くにある眼鏡上に表示される。利用者は、音声を通じてグラフィカル・ユーザー・インターフェースを操作する。
【００５２】
UniIntプロキシ３は、グラス上に表示するのに適した映像サイズに変換する。もしも、利用者が眼鏡を外して非装着状態になると、グラフィカル・ユーザー・インターフェースは、自動的にテレヴィジョンの画面中に表示される。また、グラフィカル・ユーザー・インターフェース上のカーソルを移動させるのにも、音声が利用される。音声はUniIntプロキシ３内のキーボードとマウスのイベントに翻訳され、これ等のイベントは、テレヴィジョン内で実行されるアプリケーション１に伝送される。
【００５３】
次に、本実施例におけるプロトタイプ・システムの現状を説明し、それから、ネットワーク化された家庭用機器を制御するためプロトタイプ・システム構築に関する幾つかの事例を説明する。
【００５４】
本実施例のシステムは、シンクライアント・システム として、ネットワークに繋がった他のコンピュータの画面を遠隔操作するソフトウェアとして知られるVNC(Virtual Network Computing)システムを採用しているが、このVNCサーバは、UniIntサーバ３として修正せずに使用することができる。ここでのHAViに基づくホーム・コンピューティング・システムにおける現行プロトタイプは、２つの家庭用機器に機能させている。一番目はDVビューアで、二番目はデジタルTVエミュレーターである。ここでのアプリケーション１は、現在利用可能な機器に従ってグラフィカル・ユーザー・インターフェースを表示する。また、グラフィカル・ユーザー・インターフェースを表示する画面上のカーソルは、Palm Pilotから動かすことができる。しかしながら、装置の電源をオフしたら、グラフィカル・ユーザー・インターフェース上のカーソルは、パソコンのカーソルとマウスによって制御される。利用者の好みに応じて、PDA装置上でグラフィカル・ユーザー・インターフェースを表示することも可能である。また、現在のシステムは、家庭用機器を制御するために携帯電話と一体化されている。携帯電話の中には、ウェッブ・ブラウザを有するものがある。これにより、携帯電話に表示される特別リンクをクリックすることで、カーソルの移動を可能にする。
【００５５】
図３は、実際のシステムの使用状態を示している。この図にも示すように、例えばデジタルビデオカメラとデジタルTVチューナが同時に利用できるなら、それらのためのコントロールパネルが、一枚のパネルとして結合される。この図では、表示装置21に表示されるコントロールパネルが、Palm pilotなどの携帯情報端末22と移動可能なモバイルパソコン23の両方により制御される。本実施例におけるホーム・コンピューティング・システムでは、資源（リソース）保存能力を追加することで、標準Linuxを拡大するLinux/Rtを採用した。 Linuxはまた、IEEE1394装置ドライバーとMPEG2デコーダを提供する。また、Java仮想機器用のIBM社製JDK1.1.8が、HAViミドルウェア・コンポーネントを実行するために使用される。
【００５６】
本実施例のシステムでは、グラフィカル・ユーザー・インターフェースを含むビットマップ・イメージが、UniIntサーバ２からUniIntプロキシ３へ送信される。ビットマップ・イメージは、自身の内容に関する意味情報を含んでいないので、UniIntプロキシ３は、その内容を理解できない。例えば、ビットマップ・イメージから各GUI(グラフィカル・ユーザー・インターフェース)成分のレイアウトを引き出すことは困難である。それ故に、出力装置５の特性や利用者の好みに従ってレイアウトを変更することは容易ではない。また、本実施例のシステムは、マウスとキーボードのイベントによってのみ処理できる。このため、グラフィカル・ユーザー・インターフェースの操作は、カーソルの移動とマウス・ボタンを押すことにより実行される。もしも、この限界がシステムの有用性を損なうならば、他の手法を選択すべきである。しかし、グラフィカル・ユーザー・インターフェースをPDAと携帯電話から操作することにより、家庭用機器との非常に柔軟性のある相互通信ができる。家庭用機器は、一般的に大表示画面の使用を可能にしてくれると共に、各機器を制御するために画面上にグラフィカル・ユーザー・インターフェースを表示することを可能にする。この様に、本実施例におけるシステムは、将来の家庭用機器用ミドルウェア・コンポーネントに柔軟性を持たせるのに十分な能力を有している。
【００５７】
また、本実施例におけるシステムは、X windowの様な標準のwindow システム上で実行される如何なるアプリケーションをも制御できる。ここでのホーム・コンピューティング・システムにおいては、従来のアプリケーションがホーム・コンピューティング・アプリケーションと共存し、これらのアプリケーションは本システムによって、統一化された方法で制御可能である。例えば、本システムによって、ホーム・コンピューティング・アプリケーションと共に動作するMP3プレイヤーやNetscape（登録商標）ブラウザを操作することができる。しかしながら、重複するwindowレイアウトは、本実施例におけるユーザー・インターフェース・システムによって操作することが難しい。家庭用機器を制御するには、いわゆる"tiled window strategy"が適していると考える。また、本実施例におけるシステムが、種々の速度でのマウス・カーソルの移動をサポートするならば、システムを楽な方法で使用することにより、家庭用機器と、プレゼンテーション・ソフトウェアやウェッブ・ブラウザの様な従来のアプリケーションの両方を制御できる。
【００５８】
本実施例におけるホーム・コンピューティング・システムのアプリケーションは、状況情報に応じてユーザー・インターフェースをカスタマイズするのに非常に簡単な機能を提供する。本システムでは、各I/Oデバイスが所有するプラグ・アンド・プレイ能力を使ってどの機器が使用可能かを監視する。また、利用できる機器の総ての結合を知り、且つ各々を結合するためのユーザー・インターフェースを設計することが必要であると考える。それ故に、現在の構成に従って、それに相応しいユーザー・インターフェースが選定される。
【００５９】
プロトタイプのアプリケーションは、本システムの効果を証明するのに有用である。特に、各々の機器における機能構成と、利用者の好みに応じたユーザー・インターフェースのカスタマイズ化は、ネットワークされた家庭用機器を制御するのに有効である。しかしながら、状況認知（"context-aware"）アプリケーションを構築するための設計手法は、非常に特定されたものであり、それ故に、状況認知アプリケーションを組織的な方法で構築する研究が必要で、場所の情報や利用者の感情の様な、多くの状況情報を監視する種々のセンサーを必要とする。また、例えば新しい機器がネットワーク上に現れようとも、自動的に機器における複数機能を構成する技術を調べる必要がある。
【００６０】
なお、本実施例におけるシステムと類似する幾つかの手法がある。そうした５つのシステムを説明すると共に、本実施例におけるシステムと比較を行なう。
【００６１】
第一のシステムは、Pebbleシステムである。このPebbleシステムにより、世界で最も知られているPDAのPalmPilotを介して、MS Windows（登録商標）オペレーティング・システム用のデスクトップ・アプリケーションを制御することができる。例えば、デスクトップ上のカーソルは、PalmPilotのスクリーンに触れることにより、動かすことができる。このシステムは、本実施例で提案したプロトタイプに非常に近い。しかしながらPebbleシステムは、システムの利用性に焦点を置くので、その目標は異なる。一方、本実施例におけるシステムは、システムの構造に焦点を絞っており、種々の入力装置４を使って、出力表示装置上においてグラフィカル・ユーザー・インターフェースを操作できると共に、入力／出力相互通信装置４，５は、利用者の好みに従って切り替え可能である。本実施例におけるシステムの柔軟性は、ネットワーク化された家庭用機器を支援する為により適している。
【００６２】
二番目のシステムは、UIML(User Interface Makeup Language)システムで、これは高度な装置の独立性を持って、ユーザー・インターフェースの宣言的記述が可能なXML言語である。もしも、アプリケーションがUIML文書としてユーザー・インターフェースを書くとすると、その文書は、各入力／出力相互通信装置に従って翻訳される。例えば、Palm Pilotを入力／出力装置として使用するために、UIML文書はPalm Pilot上に提供される。またUIML文書は、音声相互通信を支援する為にVoice XML用に提供される。しかしながら、入力／出力装置が分離されている場合は、この手法を採用することは難しい。また、利用者の状況に応じて、これらの入力／出力装置をダイナミックに切り替えるサポートが存在しない。
【００６３】
三番目のシステムであるCUESシステムは、モバイル装置から種々の機器を制御する骨組みを提供する。このシステムにおいては、各機器は、モバイル装置へ送信されるJavaバイトコードを持っている。このコードは、グラフィカル・ユーザー・インターフェースを含み、モバイルコンピュータ上に表示される。利用者は、モバイルコンピュータ上のグラフィカル・ユーザー・インターフェースによって、機器を制御できる。この手法により、各機器に対して適正なグラフィカル・ユーザー・インターフェースを使用できる。しかしながら、この手法では、モバイルコンピュータは、Java AWT/Swingにより実行されるグラフィカル・ユーザー・インターフェースを表示する中間サイズの表示器を有し、指示装置とキーボードを持つべきであることを前提としている。また、この手法は、ユーザー・インターフェースのカスタマイズと相互通信装置のダイナミックな切り替えはサポートしていない。
【００６４】
四番目のシステムであるSimjaは、マルチ・モデル・インターフェースをサービスにサポートするミドルウェア構成要素である。Simjaは、種々のメディア・フォーマットを翻訳する。それぞれの翻訳機は単一の機能を有し、別の翻訳機への接続が可能である。Simjaにおいては、この接続はパスと呼ばれ、パスは要求を表す仕様に従って自動的に翻訳機の中でセットアップされる。本実施例で提案したシステムの手法においては、プラグイン・モジュールがモノリシック（"monolithic"）であり、各相互通信装置が独立して入力／出力モジュールを形成することが必要であるので、このSimjaの手法は、プラグイン・モジュールを構築するには有益である。
【００６５】
五番目のシステムであるHAViには、利用者との相互通信をサポートする２つの方法がある。一番目の方法は、"Data Driven Interaction"(DDI)である。これは、グラフィカル・ユーザー・インターフェースを記述するための宣言方法を提供する。この手法に於いて、ユーザー・インターフェースは、UIML の様な文書として記述され、この文書は表示装置の特性に応じて提供されるが、しかし、UMILはXMLに基ずいていて、HAViのDDIより一般的である。二番目の方法は、前記CUESシステムに似ている。Java AWTで書かれたユーザー・インターフェースを含むJavaバイトコードがHAVi装置にダウンロードされ、グラフィカル・ユーザー・インターフェースが装置の画面上に表示される。ここで生じる問題は、CUESの場合と同じである。
【００６６】
本実施例では、従来のグラフィカル・ユーザー・インターフェース・システムと、進歩したネットワーク化されたホーム・コンピューティング用入力／出力相互通信装置との間の隙間を埋める新しいユーザー・インターフェースについて説明してきた。実施例に提示するシステムは、グラフィカル・ユーザー・インターフェースを含むビットマップ・イメージの内容は分析しない。それ故に、ビットマップ・イメージが出力装置５へ翻訳されなければ、或いは、入力イベントがマウスまたはキーボードへ翻訳されなければ、本システムを利用するのは難しい。しかし、ネットワーク化された音響映像家庭用装置は、大画面の表示装置と共に使用されるのが普通なので、本システムが、これ等の家庭用機器を制御するのには十分であると、我々は信じるものである。さらに本システムが、WindowsやLinux上で実行する種々のアプリケーションを制御するのに利用することができる。
【００６７】
また本実施例では、上述の隙間を埋めるユーザー・インターフェース・システムであるネットワーク化された家庭用機器用の全般的相互通信を提案した。このシステムは如何なる場所でも一様な方法で機器の制御が可能であり、Java AWTまたはGTK+の様な従来の標準グラフィカル・ユーザー・インターフェースを、アプリケーションが利用することができるが、利用者は、PDAや携帯電話などの種々の装置、若しくは進歩した技術により、そのインターフェースを操作することができる。しかも、Citrix（登録商標） Metaframe，Microsoft（登録商標） Terminal Servier，Sun Microsystems Sun RayそしてAT&T（登録商標） VNC(VirtualNetwork Computing)などの国籍のないシンクライアント・システムに基づいた目標を、非常に容易に実現できる。そして、プロトタイプ・システムを構築し、利用者が自分の携帯する種々の相互通信装置を使用することができる。ここでのプロトタイプ・システムは、家庭用機器用の広く分布した標準ミドルウェア仕様であるHAViを導入したホーム・コンピューティング・システムと現在統合されており、これは家庭用機器を制御するのに有益である。
【００６８】
以上のように本実施例によれば、利用できる機器に応じて、その機器を制御するのに必要なグラフィカル・ユーザー・インターフェースを生成して提示するアプリケーション手段たるアプリケーション１と、前記機器を制御するためのコマンドを伝送する入力装置４と、表示手段を備えた出力装置５と、入力装置４および出力装置５と、アプリケーション１との間に介在するプロキシ手段としてのUniIntプロキシ３とを備え、UniIntプロキシ３は、入力装置４や出力装置５から受信メッセージを受け取ることにより、現在利用可能な入力装置４や出力装置５を検出してそれを選択する利用可能装置検出手段としてのプラグ・アンド・プレイ管理モジュール13を備えたネットワーク機器汎用相互通信装置において、機器からの出力イベントとして、アプリケーション１から汎用相互通信プロトコルによって送られてきたグラフィカル・ユーザー・インターフェースに含まれるビットマップ・イメージを、プラグ・アンド・プレイ管理モジュール13が選択した出力装置５の表示手段に表示できるように、該出力装置５の特性に従ってコード変換して、このコード変換したビットマップ・イメージを含むグラフィカル・ユーザー・インターフェースを前記出力装置５の表示手段に転送する出力管理手段としての出力プラグイン・モジュール22と、プラグ・アンド・プレイ管理モジュール13が選択した入力装置４からコマンドを受取ると、このコマンドをアプリケーション１が認識できるマウス或いはキーボードのイベントに変換し、この変換したマウス或いはキーボードのイベントを、前記機器への入力イベントとして、汎用通信プロトコルによってアプリケーション１へ伝送する入力管理手段としての入力プラグイン・モジュール21とをUniIntプロキシ３にさらに備えて構成される。
【００６９】
この場合、利用可能な機器に応じたグラフィカル・ユーザー・インターフェースが、その機器からの出力イベントとして、アプリケーション１から汎用相互通信プロトコルによってUniIntプロキシ３に送られると、そのグラフィカル・ユーザー・インターフェースに含まれるビットマップ・イメージは、UniIntプロキシ３により現在利用可能な出力装置５の表示手段に適合するように、この出力装置５の特性に従ってコード変換され、そのコード変換されたビットマップ・イメージを含むグラフィカル・ユーザー・インターフェースが表示手段に転送される。また、利用者が利用可能な機器を制御するには、表示手段に表示されるグラフィカル・ユーザー・インターフェースを参照しながら、現在利用できる入力装置４から適宜コマンドを伝送すればよい。こうすれば、どのような入力装置４であっても、UniIntプロキシ３は伝送されたコマンドを、汎用相互通信プロトコルに適合するマウスまたはキーボードのイベントに変換し、それを機器への入力イベントとして、アプリケーション１に伝送する。
【００７０】
つまり、ここでのUniIntプロキシ３はいわば異種の入力装置４や出力装置５を扱う手段としての機能を果すので、現存する標準のグラフィカル・ユーザー・インターフェースを変更することなく、種々の入力装置４や出力装置５を使って、一様な手順で機器の制御を行なうことができる。特に、キーボード／マウスを汎用入力イベントとして採用し、ビットマップ・イメージを汎用出力イベントとして採用することで、あらゆる入力装置４や出力装置５との接続のために、従来のグラフィカル・ユーザー・インターフェースのツールキットを利用することができる。
【００７１】
また、本実施例では、入力装置４から所望の出力装置５を選択するコマンドを受取ると、プラグ・アンド・プレイ管理モジュール13による選択に優先して、この出力装置５の表示手段が表示できるグラフィカル・ユーザー・インターフェースを出力装置５に転送するように、出力プラグイン・モジュール22を構成している。
【００７２】
このようにすると、入力装置４から表示したい出力装置５を選択するコマンドを伝送すると、その出力装置５の表示手段に適合したグラフィカル・ユーザー・インターフェースがUniIntプロキシ３から送り出される。したがって、利用者の状況や好みに応じた出力装置５の切替えが可能となり、利用者と機器との間を独自のものとすることができる。
【００７３】
さらに本実施例では、アプリケーション１が現在利用可能な機器を特定するために、プラグ・アンド・プレイ機能を有したネットワークを通じてこれらの機器と接続している。
【００７４】
プラグ・アンド・プレイ機能を有したネットワークは、どの機器が現在接続されているか、誰のパワースイッチがオンになっているかを知らせる機構をサポートしているので、アプリケーション１が現在利用可能な機器を容易に知ることができると共に、最も相応しいユーザー・インターフェースを容易に選定することができる。
【００７５】
なお、本発明は上記実施例に限定されることなく、本発明の範囲内で種々の変形実施が可能である。
【００７６】
【発明の効果】
本発明の請求項１の構成によれば、利用者がいかなる場所にいたとしても、従来の標準グラフィカル・ユーザー・インターフェースをそのまま利用して、一様な手順で機器の制御を行なうことができる。また、あらゆる入力装置や出力装置との接続のために、従来のグラフィカル・ユーザー・インターフェースのツールキットを利用することができる。
【００７７】
本発明の請求項２の構成によれば、利用者の状況や好みに応じた出力装置の切替えが可能になる。
【００７８】
本発明の請求項３の構成によれば、現在利用可能な機器を容易に知ることができると共に、最も相応しいユーザー・インターフェースを容易に選定できる。
【図面の簡単な説明】
【図１】 本発明の一実施例を示すシステムの全体構成をあらわした概略説明図である。
【図２】 同上プラグイン管理モジュールの機能構成を示す概略説明図である。
【図３】 同上実際のシステムの使用状態を示す概略説明図である。
【符号の説明】
１ アプリケーション（アプリケーション手段）
３ UniIntプロキシ（プロキシ手段）
４ 入力装置
５ 出力装置
13 プラグ・アンド・プレイ管理モジュール（利用可能装置検出手段）
21 入力プラグイン・モジュール（入力管理手段）
22 出力プラグイン・モジュール（出力管理手段）
【発明の属する技術分野】
本発明は、ネットワーク化された家庭用機器や個人用機器との汎用的な相互通信を行うためのネットワーク機器汎用相互通信装置に関する。
【０００２】
【発明が解決しようとする課題】
我々の毎日の生活は、コンピュータを内蔵した種々の対象物により劇的に変化をするであろう。これらの対象物は、人々の身体と記憶を拡大するため知的な動作をするものと期待される。
【０００３】
こうしたコンピュータ環境を実現する為に、これまで多くの研究プロジェクトが種々の問題に挑戦している。これらのコンピュータ環境は、広くユビキタス（Ubiquitous：どこにでもある）・コンピューティングと呼ばれている。また、他の研究者たちは、パーベーシブ・コンピューティング（"pervasive computing"）、センティエント・コンピューティング（"sentient computing"）或いはシングス・ザット・シンク（"Things That Think"）と呼ばれる同様の概念を提案している。ユビキタス・コンピューティング環境においては、種々の対象物がコンピュータを内包することにより増加される。如何なるプログラムも、コンピュータによって実行することができるので、プログラムを置き換えることにより、これらの対象物は無限に拡張される可能性を持っている。また、これらの対象物は、他の対象物と通信を行なうネットワークを持つので、周囲を取り巻く状況に従って、各対象物がそれぞれでプログラムを置き換えることにより、一層アクティブに動作するであろう。例えば、我々の環境は我々に代わって世界中に起こっていることを記憶するかもしれないし、各々の対象物が現時点で存在する場所を我々に教えるかもしれない。
【０００４】
前述したように、前記ユビキタス・コンピューティング環境を実現する為に、多くの研究が成されている。或る研究グループは、ユビキタス・コンピューティング環境のプロトタイプ（代表例）を構築する作業を行なってきた。これらの研究は、ユビキタス・コンピューティングが我々の生活に与えるインパクトを示している。また最近は、幾つかの標準ミドルウェアの仕様が、ユビキタス・コンピューティングを実現するために提案されている。ミドルウェアとは、いわゆるOS（Operating System）上で動作し、アプリケーションソフトに対してOSよりも高度で具体的な機能を提供するソフトウェアのことで、OSとアプリケーションソフトの中間的な性格を持っている。そのなかで、ネットワークを通じて各種機器を接続し、相互に機能を提供しあうための技術仕様であるJini（登録商標）や、同じように家庭内のパソコンや周辺機器、AV機器、電話、家電製品などの機器をネットワークを通じて接続し、相互に機能を提供しあうための技術仕様であるUPnP（ユニヴァーサル・プラグアンド・プレイ）は、ミドルウェアとして良く知られているが、これらは分散された環境の中で種々のサービスを発見する機構を備えている。また、別なミドルウェアとして知られるHAVi（Home Audio/Video Interoperability）は、ネットワーク化された家庭用機器の発展を可能にする。それ故に、家庭環境におけるユビキタス・コンピューティングは、近い将来に実現されるであろう。こうしたユビキタス・コンピューティング環境は、ホーム・コンピューティングと呼ばれるが、ホーム・コンピューティングは、我々の日常生活に直接関係があるので、とりわけ興味深い分野ではある。また、総ての人は、ホーム・コンピューティング環境の急激な進歩を期待しているので、ユビキタス・コンピューティングの効果を示すことは的を得ていることである。
【０００５】
こうしたホーム・コンピューティング環境で最も重要な問題の一つは、コンピュータを内蔵した種々の対象物が、如何に相互通信し合うかということである。利用者と種々の対象物に内蔵されたコンピュータ間の相互通信は、従来から幾つかの研究グループにより開発が行なわれていた。これらの装置によれば、より自然に内蔵したコンピュータと相互通信を行なうことができる。しかしながら、ネットワーク化された家庭用機器向けの現在の標準ミドルウェアは、Java（登録商標）に標準で付属するグラフィック関連のクラスライブラリとして知られるJava AWTや、同じようにグラフィック関係のライブラリとして知られるGTK+の様な、従来からある標準グラフィカル・ユーザー・インターフェースを採用してきた。それ故に、PDA，携帯電話あるいは上記研究段階のプロトタイプ相互通信機器から、家庭用の機器を制御することは容易なことではない。また、利用者の現在の状況によって、自然な相互通信は変化する。例えば、利用者が食事を料理しているならば、音声によって機器を制御したいが、ソファの上でTVを見ている場合は、リモート・コントロールを使うのが良いのかもしれない。このことは、最も適当な相互通信は、利用者の現在の状況と好みによってダイナミックに選定すべきであり、この相互通信装置の選定は、利用者が家庭内，事務所或いは公共の場所のように如何なる場所に居ようと、一貫したものであることを意味している。
【０００６】
そこで本発明は、利用者がいかなる場所にいたとしても、従来の標準グラフィカル・ユーザー・インターフェースをそのまま利用して、一様な手順で機器の制御を行なうことができるネットワーク機器汎用相互通信装置を提供することをその目的とする。
【０００７】
【課題を解決するための手段】
本発明の請求項１におけるネットワーク機器汎用相互通信装置は、利用できる機器に応じて、その機器を制御するのに必要なグラフィカル・ユーザー・インターフェースを生成して提示するアプリケーション手段と、前記機器を制御するためのコマンドを伝送する入力装置と、表示手段を備えた出力装置と、前記入力装置および出力装置と前記アプリケーション手段との間に介在するプロキシ手段とを備え、前記プロキシ手段は、前記入力装置や前記出力装置から受信メッセージを受け取ることにより、現在利用可能な入力装置や出力装置を検出してそれを選択する利用可能装置検出手段を備えたネットワーク機器汎用相互通信装置において、 前記機器からの出力イベントとして、前記アプリケーション手段から汎用相互通信プロトコルによって送られてきたグラフィカル・ユーザー・インターフェースに含まれるビットマップ・イメージを、前記利用可能装置検出手段が選択した前記出力装置の表示手段に表示できるように、該出力装置の特性に従ってコード変換して、このコード変換したビットマップ・イメージを含むグラフィカル・ユーザー・インターフェースを該出力装置の表示手段に転送する出力管理手段と、前記利用可能装置検出手段が選択した前記入力装置からコマンドを受取ると、このコマンドを前記アプリケーション手段が認識できるマウス或いはキーボードのイベントに変換し、この変換したマウス或いはキーボードのイベントを、前記機器への入力イベントとして、汎用通信プロトコルによって該アプリケーション手段へ伝送する入力管理手段と、を前記プロキシ手段にさらに備えて構成される。
【０００８】
この場合、利用可能な機器に応じたグラフィカル・ユーザー・インターフェースが、その機器からの出力イベントとして、アプリケーション手段から汎用相互通信プロトコルによってプロキシ手段に送られると、そのグラフィカル・ユーザー・インターフェースに含まれるビットマップ・イメージは、プロキシ手段により現在利用可能な出力装置の表示手段に適合するように、この出力装置の特性に従ってコード変換され、そのコード変換されたビットマップ・イメージを含むグラフィカル・ユーザー・インターフェースが表示手段に転送される。また、利用者が利用可能な機器を制御するには、表示手段に表示されるグラフィカル・ユーザー・インターフェースを参照しながら、現在利用できる入力装置から適宜コマンドを伝送すればよい。こうすれば、どのような入力装置であっても、プロキシ手段は伝送されたコマンドを、汎用相互通信プロトコルに適合するマウスまたはキーボードのイベントに変換し、それを機器への入力イベントとして、アプリケーション手段に伝送する。
【０００９】
つまり、ここでのプロキシ手段は異種の入力装置や出力装置を同じように取り扱う手段としての機能を果すので、現存する標準のグラフィカル・ユーザー・インターフェースを変更することなく、種々の入力装置や出力装置を使って、一様な手順で機器の制御を行なうことができる。特に、キーボード／マウスを汎用入力イベントとして採用し、ビットマップ・イメージを汎用出力イベントとして採用することで、あらゆる入力装置や出力装置との接続のために、従来のグラフィカル・ユーザー・インターフェースのツールキットを利用することができる。
【００１０】
また、本発明の請求項２におけるネットワーク機器汎用相互通信装置は、前記入力装置から所望の前記出力装置を選択するコマンドを受取ると、前記利用可能装置検出手段による選択に優先して、この出力装置の表示手段が表示できるグラフィカル・ユーザー・インターフェースを、該出力装置に転送するように、前記出力管理手段を構成したものである。
【００１１】
このようにすると、入力装置から表示したい出力装置を選択するコマンドを伝送すると、その出力装置の表示手段に適合したグラフィカル・ユーザー・インターフェースがプロキシ手段から送り出される。したがって、利用者の状況や好みに応じた出力装置の切替えが可能となり、利用者と機器との間を独自のものとすることができる。
【００１２】
本発明の請求項３におけるネットワーク機器汎用相互通信装置は、前記アプリケーション手段が現在利用可能な前記機器を特定するために、プラグ・アンド・プレイ機能を有したネットワークを通じて該機器を接続したことを特徴とする。
【００１３】
プラグ・アンド・プレイ機能を有するネットワークは、どの機器が現在接続されているか、誰のパワースイッチがオンになっているかを知らせる機構をサポートしているので、アプリケーション手段が現在利用可能な機器を容易に知ることができると共に、最も相応しいユーザー・インターフェースを容易に選定することができる。
【００１４】
【発明の実施形態】
以下、添付図面を参照しながら、本発明における好適な実施例を説明する。先ず実施例の詳細を説明する前に、ホーム・コンピューティング環境において、利用者との相互通信すなわち対話をサポート（支援）する幾つかの設計選択について説明する。
【００１５】
本発明の目的を達成するための方法は数種ある。最も重要な論点は、種々の相互通信装置（デバイス）を如何に支援するかである。従来のユーザー・インターフェース・システムは、数種の相互通信装置のタイプを想定している。例えば、マウス，トラック・ポイントそしてタッチ・スクリーンは、入力装置として使用される。柔軟なユーザー・インターフェース・システムを構築する手法としては、次の３つの代案が考えられる。
（１）零の状態から新規のユーザー・インターフェース・システムを構築する。
（２）従来からある種々の相互通信装置用の各ユーザー・インターフェース・システムを呼び出す新たな装置の独立層（レイヤ）を構築する。
（３）従来のユーザー・インターフェース・システムの入力／出力イベントを獲得し、相互通信装置に従ってそのイベントを翻訳する。
【００１６】
（１）の手法は、最初から種々の相互通信装置によって使用される新規なユーザー・インターフェース・システムの構築を意味する。この手法は、システムが新たな相互通信装置に適応されることを考慮に入れるので、新相互通信装置が出現した時に生き長らえることができる。しかしながら、現存の機器とミドルウェアのコンポーネント（構成要素）を新たなユーザー・インターフェース・システムに編入する為には修正が必要であり、その開発には長い期間を必要とする。多くのホーム・コンピューティング・システムは、すでに現存のソリューション（問題点の解決や要求の実現を行なうための情報システム）を採用しているので、現在使用されているユーザー・インターフェース・システムを置き換えるこことは不可能であろう。
【００１７】
（２）の手法は、従来のユーザー・インターフェース・システム上に新しい層を追加することにより、種々の相互通信装置を支援する2つの案がある。第１案は、相互通信装置の独立層が、アプリケーションの標準的な要求を各ユーザー・インターフェース・システムへの要求に翻訳する。例えば、こうした手法に基礎を置いた文献の中では、利用者と機器との間の相互通信方法を含むドキュメントを、アプリケーションが指定している。装置の独立層は、現存する各ユーザー・インターフェース・システム用のドキュメントを提供する。第２案であるマルチプル・ユーザー・インターフェース・システムにおいて、各機器は、getUI( )法を提供する。この方法は、マルチプル・ユーザー・インターフェース・サポート・サービスへ参照信号を返し、各相互通信装置に最も適したユーザー・インターフェースを提供する。双方の案は、非常に将来性があるが、第１案の様に現存のアプリケーションを修正する必要があり、装置の独立層がそれぞれの相互通信装置に対し実行されなければならない。それ故に、この手法は、ホーム・コンピューティング用に現存する標準仕様を支援するには適当ではない。
【００１８】
最後の（３）の手法は、ユーザー・インターフェース・システムによって生成されたビットマップ・イメージが、機器制御のために相互通信装置の特性に従がって変換される。また、相互通信装置からの入力イベントは、マウス或いはキーボードのイベントに変換される。この手法では、入力／出力イベントの変換のために、グラフィカル・ユーザー・インターフェース（GUI）内のレイアウト情報を利用できないという制限がある。しかし、大部分の家庭用音響映像機器は、グラフィカル・ユーザー・インターフェースを提示する表示装置を備えている。この場合の最も重要な要求とは、グラフィカル・ユーザー・インターフェースを提示する表示装置と、利用者の状況や好みに応じて、グラフィカル・ユーザー・インターフェースを提示する入力装置を変えたいということであるが、こうした要求は、（３）の手法において非常に上手く達成できる。一方、この手法は、ホーム・コンピューティング用の現存のソフトウェアを修正する必要は無い。また、従来のホーム・コンピューティング用標準ミドルウェアで採用されてきたJava AWT/Swing，X window system，Microsoft Windows（登録商標）のような人気のあるユーザー・インターフェース・システムの大部分は、本手法にて極めて容易に採用できる。
【００１９】
ここでは、HAViを実行するホーム・コンピューティング・システムがJava AWTの使用を必要としており、しかも近い将来に、修正を行なうことなくHAViに基づき開発される種々のホーム・コンピューティング・アプリケーションを使いたいという前提で、（３）の手法に基づく実施例を説明する。特に最近の興味は、家庭用機器を構築するためのLinux を内蔵した使用形態にあって、それは（３）の手法をより実際的なものにする。何故なら、Linuxはその基本的ユーザー・インターフェース・システムとして、X windows システムを通常は取り入れており、内蔵したLinux上の種々のアプリケーションが、種々の相互通信装置により制御されることを、本実施例で提案するシステムが可能にするからである。こうしたアプリケーションは、従来の良く知られているユーザー・インターフェース・ツールキットを使用可能であるので、この手法は、種々の内蔵アプリケーションを極めて容易に発展させることができる。
【００２０】
本実施例で以後説明する（３）の手法において、入力／出力相互通信装置と機器との間の通信に広く利用できるプロトコルを、ここで汎用相互通信（"universal interaction"）と呼ぶ。この汎用相互通信は、均一な方法にて種々の家庭用機器を制御することができる。このことは、何処にいて何を制御したいかによって、人々の行動が制限を受けないことを意味する。したがって、ここでの手法は、家庭用機器との極めて自然な相互通信を提供する。
【００２１】
機器からの出力イベントは汎用出力相互通信イベントに変換され、そのイベントは、それぞれの出力相互通信装置に向けて翻訳される。また、入力相互通信装置で発生する入力イベントは汎用入力相互通信イベントに翻訳され、そのイベントは機器内で実行されるアプリケーションにより処理される。
【００２２】
後述するUniIntプロキシと呼ばれる汎用相互通信プロキシは、汎用相互通信プロトコルと各相互通信装置の入力／出力イベント間の変換を広範囲に行なう役割を演じる。もしも、各入力／出力相互通信装置のイベントが汎用相互通信プロトコルに変換されるならば、プロキシは機器の制御のために如何なる入力／出力相互通信装置の使用も可能にする。この手法は、次のような三つの非常に魅力的な特徴を提供する。
【００２３】
第１の特徴は、入力相互通信装置と出力相互通信装置が、利用者の状況と好みによって、それぞれ独自に選択されることである。例えば、利用者は、PDAを入力／出力相互通信装置に選択できる。また、利用者は、携帯電話を入力相互通信装置に選択してもよいし、またテレヴィジョンも出力相互通信装置として選択してもよい。利用者は、携帯装置により生じる拡大された実世界を操作することで、自分の意思表示によって機器を制御できる。
【００２４】
第２の特徴は、利用者の好みに応じてそれに相応しい入力／出力相互通信装置を選択できることである。しかも、これらの相互通信装置は、利用者の現在の状況によってダイナミックに変更される。例えば、入力相互通信装置として携帯電話を使用している利用者は、別の仕事のために現在両手が塞がっているので、相互通信装置を音声入力システムに変えるであろう。
【００２５】
第３の特徴は、もしもユーザー・インターフェース・システムが汎用相互通信プロトコルと交信できれば、機器内で実行中の如何なるアプリケーションでも、あらゆるユーザー・インターフェース・システムを利用できることである。例えば、キーボード／マウスを汎用入力イベントとして採用し、ビットマップ・イメージを汎用出力イベントとして採用した場合、あらゆる相互通信装置との接続のために、Java AWT, GTK+ そしてQtのような従来のグラフィカル・ユーザー・インターフェースのツールキットを利用することができる。
【００２６】
実際、家庭用電化製品の殆どの標準仕様は、GUI（グラフィカル・ユーザー・インターフェース）標準用のJava AWTを最近は採用する傾向にある。かくして、本手法を取り入れたシステムは、将来の各種家庭用電化製品を、種々の相互通信装置から、それらのアプリケーションを修正することなく制御することが可能になるであろう。現存のGUI標準を変更することは非常に難しいので、この特徴は非常に望ましいものである。
【００２７】
本実施例におけるシステムは、グラフィカル・ユーザー・インターフェースを描くためにビットマップ・イメージを転送すると共に、入力用マウス／キーボードのイベントを処理するために、シンクライアント・システム（"thin-client system"）を使用する。通常のシンクライアント・システムは、ビューアとサーバから成る。サーバは、アプリケーションが動作する機器上で実行される。アプリケーションは、X window systemの様な従来のユーザー・インターフェースを使って、グラフィカル・ユーザー・インターフェースを実行する。ユーザー・インターフェース・システムにより作られるビットマップ・イメージは、通常はもう一つの機器上で実行されるビューアへ送信される。一方、ビューアによって読み込まれるマウスとキーボード・イベントは、サーバへ転送される。ビューアとサーバ間のプロトコルは、標準プロトコル（例えば、前記VNCシステムに於いては、RFB（Remote Frame Buffer）プロトコルと呼ばれる）として規定される。ここでは、こうしたプロトコルを汎用相互通信プロトコル（universal interactionprotocol）と呼ぶ。本システムは、利用者の居場所に従って利用者の表示部（デスクトップ）を動かしたり、例えばMS Windows（登録商標）とX Window systemの両方というように、同一画面上に複数の表示部を表示する。
【００２８】
本システムでは、シンクライアント・システムのビューアを、UniInt（Universal Interaction：汎用相互通信）サーバから受け取ったビットマップ・イメージを出力装置へ転送するUniIntプロキシに置き換える。この手法では、如何なるシンクライアント・システムのサーバも、UniIntサーバとして使用可能である。また、UniIntプロキシは、入力相互通信装置から受け取った入力イベントをUniIntサーバへ転送する。
【００２９】
本実施例におけるシステムは、図１に示すように、次の主要な５つの構成要素から成る。すなわちそれは、家庭用機器（図示せず）のアプリケーション１と、前記UniIntサーバ２と、UniInt プロキシ３と、入力装置４と、出力装置５である。
【００３０】
表示操作制御手段に相当する家庭用機器のアプリケーション１は、現在使用できる家庭用機器を制御するのに必要なグラフィカル・ユーザー・インターフェース（表示操作形態）を作成するものである。例えば、家庭用機器としてTV（テレヴィジョン）が現在利用できるならば、アプリケーション１は、TV用のユーザー・インターフェースを作成する。一方、アプリケーション１は、いずれも家庭用機器であるTVとVCR（デジタルビデオカメラ）が現在両方とも利用できるならば、TVとVCR用のGUIを構成する。
【００３１】
汎用相互通信サーバに相当するUniIntサーバ２は、windowシステムによって作られるビットマップ・イメージを、汎用相互通信プロトコルを使って、UniIntプロキシ３へ送り出すと共に、UniIntプロキシ３から受け取ったマウスとキーボードの各イベントを、windowシステムに転送する機能を有する。現在の実行例では、現存するシンクライアント・システムのサーバを修正する必要はないし、UniIntサーバ２をサポートするwindowシステム上で動作するあらゆるアプリケーションを、修正を行なわずにシステムで制御することが可能である。
【００３２】
プロキシ手段としての汎用相互通信プロキシに相当するUniIntプロキシ３は、内部ネットワークとインターネットの境にあって、直接インターネットに接続できない内部ネットワークの機器に代わって、インターネットとの接続を代理して行なうもので、ネットワークに出入りするアクセスを一元管理し、内部から特定の種類の接続のみを許可したり、外部からの不正なアクセスを遮断するために用いられるが、これはとりわけ本システムにおいて最も重要な構成要素である。UniIntプロキシ３は、UniIntサーバ２から受け取ったビットマップ・イメージを、出力装置５の特性に従って変換する。また、UniIntプロキシ３は、入力装置４から受け取ったイベントを、UniIntサーバ２との間の汎用相互通信プロトコルに適応するマウス若しくはキーボードのイベントへと変換する。UniIntプロキシ３は、各機器を制御するために、現在の適正な入力／出力相互通信装置４，５を選択する。次に、選択された入力装置４は入力プラグイン・モジュールの信号を送信すると共に、選定された出力装置５は出力プラグイン・モジュールの信号をUniIntプロキシ３に送信する。入力プラグイン・モジュールは、入力装置４から受け取ったイベントをマウスやキーボードのイベントへ翻訳するコードを備えている。出力プラグイン・モジュールは、UniIntサーバ２から受け取ったビットマップ・イメージを、目標となる出力装置５の画面上に表示することのできるイメージに変換するコードを備えている。
【００３３】
入力装置４は、利用者との相互通信をサポートするもので、家庭用機器を制御するための利用者により発せられたコマンドを伝送するものである。出力装置５は、機器を制御するのに必要なグラフィカル・ユーザー・インターフェースを表示するための表示手段（表示装置）を備えている。
【００３４】
UniIntプロキシ３は、異種の相互通信装置４，５を扱う役目を演じる。また、UniIntプロキシ３は、利用者の状況や好みに応じて相互通信装置４，５の切り替えも可能である。これにより、利用者と機器との間を独自のものとすることができる。
【００３５】
ここでのUniIntプロキシ３はJava言語により書かれており、実施例では、図１に示す如く４つのモジュール部を備えている。第１のモジュールは、汎用相互通信プロトコルモジュール11であり、これはUniIntサーバ２と通信を行なうための汎用相互通信プロトコルを実行するものである。この第1のモジュール11を置き換えると、様々なシンクライアント・システムを備えたシステムを使用することができる。このモジュール11は、シンクライアント・システムの観点にて実行される同様なモジュールを利用できる。第２のモジュールは、プラグイン管理モジュール12で、これは相互通信装置４，５から入力／出力プラグイン・モジュールを受け取ると共に、UniIntプロキシ３内の各モジュールとダイナミックにリンク（連結）するものである。第３のモジュールは、利用可能装置検出手段に相当するプラグ・アンド・プレイ管理モジュール13で、これは現在利用可能な入力／出力相互通信装置４，５を検出するものである。第４のモジュールは、プラグイン移動管理モジュール14で、これは相互通信装置４，５とUniIntプロキシ３との間の入力／出力プラグイン・モジュールの移動を管理するものである。
【００３６】
プラグ・アンド・プレイ管理モジュール13は、UniIntプロキシ３の近くにある現在利用可能な入力装置４や出力装置５を検出する。ここでのシステムでは、独自のIDが各型式の入力装置４や出力装置５に割り当てられる。UniIntプロキシ３は、周期的にビーコン・メッセージを放送する。現行のプロトタイプ（代表例）では、相互通信装置４，５は、IEEE802.11b，Ethernet（登録商標）或いは赤外線ネットワークを通じて接続される。各相互通信装置４，５がビーコン・メッセージを受け取ると、そこから受信メッセージを回答する。受信メッセージは、その機器の型式を確認する独自のIDを含んでいる。仮にUniInt プロキシ３が、複数の相互通信装置４，５からそれぞれの受信メッセージを受け取ると、UniIntプロキシ３は、UniInt プロキシ３によって定められた選択に従って一つの相互通信装置４，５を選定する。また、新規に検出された相互通信装置４，５が受信メッセージを回答すると、例えその装置が現在使用されている装置より好ましいものであれば、その装置は現在使用中の相互通信装置４，５として選択される。
【００３７】
UniIntプロキシ３が、その相互通信装置４，５の検出後に新たな相互通信装置４，５を選択する場合は、新たな相互通信装置４，５の使用前に確認メッセージを送る。それからUniIntプロキシ３は、現在まで使われている相互通信装置４，５へ最終メッセージを送る。最後にUniIntプロキシ３は、新たな相互通信装置４，５からのプラグイン・モジュールの受け取りを待つ。入力装置４や出力装置５の選定は、各利用者用のUniIntプロキシ３中に登録されている。仮にシステムが機器を利用したい者を検出できない場合は、優先して不履行（デフォルト）が選択される。また、プラグイン・モジュールのそれぞれは、現在使用中の入力装置４や出力装置５を切り替えるイベントを支援する。例えば、現在使用されている出力装置５を変更するために、利用者はUniIntプロキシ３に対しコマンドを送ることができる。UniIntプロキシ３は、利用者が自分の好みの出力装置５を選択するまでは、現在の出力装置４を次の出力装置５に切り替える。
【００３８】
UniIntプロキシ３からの受信メッセージを受け取ると、入力装置４や出力装置５は、プラグイン・モジュールをUniIntプロキシ３に送る。本システムでは、入力装置４や出力装置５とUniIntプロキシ３と間のプラグイン・モジュールを送信するために、MobileSpace移動体システムを使用している。UniIntプロキシ３内で実行されるJavaの仮想機器内にプラグイン・モジュールがダウンロードされた後、プラグイン移動モジュール14は、入力／出力装置４，５へ移動完成メッセージを送る。MobileSpaceシステムは階層的エージェント（代理人）をサポートしており、同一階層レベルに存在する場合に、エージェントは通信を行なうことができる。それ故に、利用者はまたモバイルエージェントとしてUniIntプロキシ３を実行するが、そのエージェントは別のホストへ移動されない。しかしながら、その特徴は、入力／出力装置４，５から近くのコンピュータへUniIntプロキシ３を移動させるのに利用してもよい。
【００３９】
ここでは、現存するJava言語で書かれたモバイルエージェントシステムを使用することを想定しているが、幾つかの制限のために装置の中にはJava仮想機械（VM）を持つことができないものもあるので、総ての装置においてJavaを使うという仮定は限界があると考える。その場合、エージェントを他のコンピュータへ送る為に、Ｃ言語で書かれた非常に小さなランタイム（アプリケーションソフトを実行する際に必要となるソフトウェアモジュール(部品)）を構築することを考慮してもよい。このランタイムは、エージェントを実行できないが、別のランタイムへエージェントを送信できる。この様な小さなランタイム機能部は、種々の相互通信装置４，５を支援する為に、望ましいものであると考える。また、この手法により、豊富な機能を提供するJavaに基づいたモバイルエージェントシステムを、全般的に採用することができる。このことは、非常に異なった要求を持つ如何なる装置に置いても使用可能な、標準的なモバイルエージェントシステムを構築することが可能であることを意味する。
【００４０】
図２は、プラグイン管理モジュール13，14の機能構成を示すものである。このモジュール13，14は、入力プラグイン・モジュール21と出力プラグイン・モジュール22を含んでいる。入力管理手段としての入力プラグイン・モジュール21は、現在選択されている入力装置４からイベントを受け取るものである。このイベントは、マウス・イベント若しくはキーボード・イベントに変換され、変換されたイベントは、汎用相互通信プロトコルによって、UniIntサーバ２へ伝送される。例えば、利用者が右側の矢を描くボタンに触れると、そのイベントは入力装置４であるPDA（携帯情報端末）装置から発信され、入力プラグイン・モジュール21へと送信される。送信されたイベントは、右へのマウスの移動イベントへと翻訳され、そのイベントは最終的にwindowシステムに転送される。
【００４１】
同様に、UniIntプロキシ３内の汎用相互通信プロトコル・モジュール11により、UniIntサーバ２からビットマップ・イメージを受け取った後、出力管理手段としての出力プラグイン・モジュール22は、出力装置５へ伝送する前に、そのビットマップ・イメージを処理する。例えば、UniIntサーバ２から受け取った色彩イメージは白黒イメージに変換される。また、画像サイズは、出力装置５であるPDA装置の画面に縮小表示される。
【００４２】
本システムでは、２つの出力プラグイン・モジュール22と３つの入力プラグイン・モジュール21を供給する。第１の出力プラグイン・モジュール22Ａは、標準のVGA画面にビットマップ・イメージを描くもので、第２の出力プラグイン・モジュール22ＢはPalm Pilot用である。また３つの入力プラグイン・モジュール21Ａ，21Ｂ，21Ｃは、それぞれキーボードおよびマウス，Palm Pilot，コンパクトHTMLを支援するウェッブ・ブラウザを有する携帯電話用である。
【００４３】
ホーム・コンピューティング・アプリケーション１の役割は、利用者が家庭用機器を制御できようにすることである。利用者と家庭用機器間の相互通信は、機器の機能が益々豊富になるので、より複雑になるであろう。また機器の数は、将来増加するであろう。それ故に、将来の家庭用機器は、種々の機器との状況認知（"context-aware"）相互通信をサポートしなければならない。
【００４４】
考慮すべき状況認知は、２つの型がある。一番目は、相互通信の個別化である。相互通信は、また利用者の状況に応じてカスタマイズされる。二番目の型は、一個の機器として現在利用できる複数の機器を処理することである。
【００４５】
システムは誰が機器を制御するかを知らないので、機器との相互通信を個別化することは通常困難である。本実施例におけるシステムでは、各利用者がPDA装置や携帯電話などのような自身の保有する制御装置を有することを仮定している。こうした制御装置が、利用者の確認IDを伝送するならば、システムは誰がその機器を制御したいかが判る。しかし本システムにおいては、利用者の確認をサポートしない従来のユーザー・インターフェース・システムをアプリケーション１が採用すると仮定しているので、相互通信装置４，５からホーム・コンピューティング・アプリケーション１へ、その様な情報を伝送する直接の方法は存在しない。それ故に、現在の実施例では、各利用者用に個別化されたアプリケーション１を実行する異なったUniIntサーバ２を、各利用者毎に備えている。アプリケーション１は、利用者の好みに応じてカスタマイズされたユーザー・インターフェースを供給する。UniIntプロキシ３は、入力装置４から得られる利用者の確認に応じて、最も相応しいUniIntサーバ２を選択する。
【００４６】
本実施例におけるシステムは、現在の状況によってどの機器が現在利用できるかを知る必要がある。現在のシステムにおいては、そのアプリケーション１をどの機器が利用できるのかを知っているものと仮定する。例えば、仮にアプリケーション１が３つの家庭用機器をサポートしているならば、そのアプリケーション１は、３つの機器を結合する７個のグラフィカル・ユーザー・インターフェースを提供することが必要である。ユーザー・インターフェースは、現在利用可能な機器に応じて選択される。
【００４７】
一方、入力装置４や出力装置５は種々のものが利用可能であり、入力装置４と出力装置５を分離しても、あるいは結合してもよい。例えば、グラフィカル・ユーザー・インターフェースは、PDA装置の画面上或いはTV上の大型表示装置上に表示できる。TＶ上に表示されるユーザー・インターフェースは、PDA装置により操作することもある。それ故に、利用者は自分の好みによって相互通信方式の多様な選択ができる。またこれらの装置は、現在の状況に応じて変更が可能である。例えば、現在使用中の装置が利用できないならば、別の相互通信装置を機器制御のために選択してもよい。
【００４８】
本システムでは、前述したようにプラグイン・モジュールをUniIntプロキシ３へ送信すると仮定する。しかしながら、マイクロフォンの様なある入力装置４はプログラム化できないし、UniIntプロキシ３への送信をサポートすることは困難である。この場合は、我々は、その装置４を制御処理部であるパソコン（パーソナルコンピュータ）へ接続し、パソコンはUniIntプロキシ３と通信して、プラグイン・モジュールを伝送する。しかしながら、パソコンはマイクロフォンが現在利用可能か否かを理解できないので、ビーコン・メッセージがUniIntプロキシ３から受け取られた場合に、パソコン上のプログラムが確認メッセージを何時戻すのかを知ることは困難である。それ故に、現在のプロトタイプにおいては、その装置４が常に接続され利用可能であると仮定する。
【００４９】
次に、上記構成におけるシステムの動作を説明する。アプリケーション１が、現在利用可能な機器が例えばテレヴィジョンとビデオ・レコーダー（VCR）であると認識した時に、それらを制御するのに必要なグラフィカル・ユーザー・インターフェースを提示する。現在の利用者がそのTVプログラムの予約に興味がないとすると、アプリケーション１は、電源制御、TVチャンネルの選択、VCR機能を含むユーザー・インターフェースをUniIntサーバ２に描く。UniIntプロキシ３は、これ等の機器を制御したい利用者用にカスタマイズされたユーザー・インターフェースを描くアプリケーションを実行するUniIntサーバ２を選択すると共に、その選択されたUniIntサーバ２は、インターフェースを含むビットマップ・イメージをUniIntプロキシ３へ送信する。
【００５０】
ここで、利用者がPDA装置を備えていることを、UniIntプロキシ３が検出したと仮定する。入力／出力装置４，５に相当するPDA装置は、入力／出力プラグイン・モジュールの信号をUniIntプロキシ３に伝送する。UniIntプロキシ３は、ビットマップ・イメージをPDA装置へ送信する前に、出力プラグイン・モジュール22を使って、UniIntサーバ２から送信されたビットマップ・イメージをコード変換する。この場合、画像サイズが640×480の８ビットカラー映像は、画像サイズが、180×120の白黒画像に縮小される。また、PDA装置のタッチ・スクリーン上の入力イベントは、入力プラグイン・モジュール21によって、マウスとキーボード・イベントへ変換される。しかしながら、今、利用者は、グラフィカル・ユーザー・インターフェースを大画面で見たいものと仮定しよう。利用者は、PDA装置のタッチ・スクリーン上を軽く叩いて、UniIntプロキシ３へコマンドを送信する。UniIntプロキシ３がそれを検出すると、グラフィカル・ユーザー・インターフェースを含むビットマップ・イメージは、表示システムへ転送されると共に、ビットマップ・イメージを送信する前に、そのビットマップ・イメージは、大画面の表示システムに与えられるように、出力プラグイン・モジュール22によって変換される。またユーザー・インターフェースは、PDA装置のタッチ・スクリーン上を軽く叩くことにより、このタッチ・スクリーン上に再び表示される。
【００５１】
本実施例におけるシステムでは、種々の家庭用機器を制御するために、新型の携帯装置を使用できる。利用者が、眼鏡処方用レンズと区別のつかないヘッド・マウント・ディスプレイを装着して、テレヴィジョンを制御したいとものと仮定しよう。この場合、テレヴィジョンのグラフィカル・ユーザー・インターフェースが、テレヴィジョンの近くにある眼鏡上に表示される。利用者は、音声を通じてグラフィカル・ユーザー・インターフェースを操作する。
【００５２】
UniIntプロキシ３は、グラス上に表示するのに適した映像サイズに変換する。もしも、利用者が眼鏡を外して非装着状態になると、グラフィカル・ユーザー・インターフェースは、自動的にテレヴィジョンの画面中に表示される。また、グラフィカル・ユーザー・インターフェース上のカーソルを移動させるのにも、音声が利用される。音声はUniIntプロキシ３内のキーボードとマウスのイベントに翻訳され、これ等のイベントは、テレヴィジョン内で実行されるアプリケーション１に伝送される。
【００５３】
次に、本実施例におけるプロトタイプ・システムの現状を説明し、それから、ネットワーク化された家庭用機器を制御するためプロトタイプ・システム構築に関する幾つかの事例を説明する。
【００５４】
本実施例のシステムは、シンクライアント・システム として、ネットワークに繋がった他のコンピュータの画面を遠隔操作するソフトウェアとして知られるVNC(Virtual Network Computing)システムを採用しているが、このVNCサーバは、UniIntサーバ３として修正せずに使用することができる。ここでのHAViに基づくホーム・コンピューティング・システムにおける現行プロトタイプは、２つの家庭用機器に機能させている。一番目はDVビューアで、二番目はデジタルTVエミュレーターである。ここでのアプリケーション１は、現在利用可能な機器に従ってグラフィカル・ユーザー・インターフェースを表示する。また、グラフィカル・ユーザー・インターフェースを表示する画面上のカーソルは、Palm Pilotから動かすことができる。しかしながら、装置の電源をオフしたら、グラフィカル・ユーザー・インターフェース上のカーソルは、パソコンのカーソルとマウスによって制御される。利用者の好みに応じて、PDA装置上でグラフィカル・ユーザー・インターフェースを表示することも可能である。また、現在のシステムは、家庭用機器を制御するために携帯電話と一体化されている。携帯電話の中には、ウェッブ・ブラウザを有するものがある。これにより、携帯電話に表示される特別リンクをクリックすることで、カーソルの移動を可能にする。
【００５５】
図３は、実際のシステムの使用状態を示している。この図にも示すように、例えばデジタルビデオカメラとデジタルTVチューナが同時に利用できるなら、それらのためのコントロールパネルが、一枚のパネルとして結合される。この図では、表示装置21に表示されるコントロールパネルが、Palm pilotなどの携帯情報端末22と移動可能なモバイルパソコン23の両方により制御される。本実施例におけるホーム・コンピューティング・システムでは、資源（リソース）保存能力を追加することで、標準Linuxを拡大するLinux/Rtを採用した。 Linuxはまた、IEEE1394装置ドライバーとMPEG2デコーダを提供する。また、Java仮想機器用のIBM社製JDK1.1.8が、HAViミドルウェア・コンポーネントを実行するために使用される。
【００５６】
本実施例のシステムでは、グラフィカル・ユーザー・インターフェースを含むビットマップ・イメージが、UniIntサーバ２からUniIntプロキシ３へ送信される。ビットマップ・イメージは、自身の内容に関する意味情報を含んでいないので、UniIntプロキシ３は、その内容を理解できない。例えば、ビットマップ・イメージから各GUI(グラフィカル・ユーザー・インターフェース)成分のレイアウトを引き出すことは困難である。それ故に、出力装置５の特性や利用者の好みに従ってレイアウトを変更することは容易ではない。また、本実施例のシステムは、マウスとキーボードのイベントによってのみ処理できる。このため、グラフィカル・ユーザー・インターフェースの操作は、カーソルの移動とマウス・ボタンを押すことにより実行される。もしも、この限界がシステムの有用性を損なうならば、他の手法を選択すべきである。しかし、グラフィカル・ユーザー・インターフェースをPDAと携帯電話から操作することにより、家庭用機器との非常に柔軟性のある相互通信ができる。家庭用機器は、一般的に大表示画面の使用を可能にしてくれると共に、各機器を制御するために画面上にグラフィカル・ユーザー・インターフェースを表示することを可能にする。この様に、本実施例におけるシステムは、将来の家庭用機器用ミドルウェア・コンポーネントに柔軟性を持たせるのに十分な能力を有している。
【００５７】
また、本実施例におけるシステムは、X windowの様な標準のwindow システム上で実行される如何なるアプリケーションをも制御できる。ここでのホーム・コンピューティング・システムにおいては、従来のアプリケーションがホーム・コンピューティング・アプリケーションと共存し、これらのアプリケーションは本システムによって、統一化された方法で制御可能である。例えば、本システムによって、ホーム・コンピューティング・アプリケーションと共に動作するMP3プレイヤーやNetscape（登録商標）ブラウザを操作することができる。しかしながら、重複するwindowレイアウトは、本実施例におけるユーザー・インターフェース・システムによって操作することが難しい。家庭用機器を制御するには、いわゆる"tiled window strategy"が適していると考える。また、本実施例におけるシステムが、種々の速度でのマウス・カーソルの移動をサポートするならば、システムを楽な方法で使用することにより、家庭用機器と、プレゼンテーション・ソフトウェアやウェッブ・ブラウザの様な従来のアプリケーションの両方を制御できる。
【００５８】
本実施例におけるホーム・コンピューティング・システムのアプリケーションは、状況情報に応じてユーザー・インターフェースをカスタマイズするのに非常に簡単な機能を提供する。本システムでは、各I/Oデバイスが所有するプラグ・アンド・プレイ能力を使ってどの機器が使用可能かを監視する。また、利用できる機器の総ての結合を知り、且つ各々を結合するためのユーザー・インターフェースを設計することが必要であると考える。それ故に、現在の構成に従って、それに相応しいユーザー・インターフェースが選定される。
【００５９】
プロトタイプのアプリケーションは、本システムの効果を証明するのに有用である。特に、各々の機器における機能構成と、利用者の好みに応じたユーザー・インターフェースのカスタマイズ化は、ネットワークされた家庭用機器を制御するのに有効である。しかしながら、状況認知（"context-aware"）アプリケーションを構築するための設計手法は、非常に特定されたものであり、それ故に、状況認知アプリケーションを組織的な方法で構築する研究が必要で、場所の情報や利用者の感情の様な、多くの状況情報を監視する種々のセンサーを必要とする。また、例えば新しい機器がネットワーク上に現れようとも、自動的に機器における複数機能を構成する技術を調べる必要がある。
【００６０】
なお、本実施例におけるシステムと類似する幾つかの手法がある。そうした５つのシステムを説明すると共に、本実施例におけるシステムと比較を行なう。
【００６１】
第一のシステムは、Pebbleシステムである。このPebbleシステムにより、世界で最も知られているPDAのPalmPilotを介して、MS Windows（登録商標）オペレーティング・システム用のデスクトップ・アプリケーションを制御することができる。例えば、デスクトップ上のカーソルは、PalmPilotのスクリーンに触れることにより、動かすことができる。このシステムは、本実施例で提案したプロトタイプに非常に近い。しかしながらPebbleシステムは、システムの利用性に焦点を置くので、その目標は異なる。一方、本実施例におけるシステムは、システムの構造に焦点を絞っており、種々の入力装置４を使って、出力表示装置上においてグラフィカル・ユーザー・インターフェースを操作できると共に、入力／出力相互通信装置４，５は、利用者の好みに従って切り替え可能である。本実施例におけるシステムの柔軟性は、ネットワーク化された家庭用機器を支援する為により適している。
【００６２】
二番目のシステムは、UIML(User Interface Makeup Language)システムで、これは高度な装置の独立性を持って、ユーザー・インターフェースの宣言的記述が可能なXML言語である。もしも、アプリケーションがUIML文書としてユーザー・インターフェースを書くとすると、その文書は、各入力／出力相互通信装置に従って翻訳される。例えば、Palm Pilotを入力／出力装置として使用するために、UIML文書はPalm Pilot上に提供される。またUIML文書は、音声相互通信を支援する為にVoice XML用に提供される。しかしながら、入力／出力装置が分離されている場合は、この手法を採用することは難しい。また、利用者の状況に応じて、これらの入力／出力装置をダイナミックに切り替えるサポートが存在しない。
【００６３】
三番目のシステムであるCUESシステムは、モバイル装置から種々の機器を制御する骨組みを提供する。このシステムにおいては、各機器は、モバイル装置へ送信されるJavaバイトコードを持っている。このコードは、グラフィカル・ユーザー・インターフェースを含み、モバイルコンピュータ上に表示される。利用者は、モバイルコンピュータ上のグラフィカル・ユーザー・インターフェースによって、機器を制御できる。この手法により、各機器に対して適正なグラフィカル・ユーザー・インターフェースを使用できる。しかしながら、この手法では、モバイルコンピュータは、Java AWT/Swingにより実行されるグラフィカル・ユーザー・インターフェースを表示する中間サイズの表示器を有し、指示装置とキーボードを持つべきであることを前提としている。また、この手法は、ユーザー・インターフェースのカスタマイズと相互通信装置のダイナミックな切り替えはサポートしていない。
【００６４】
四番目のシステムであるSimjaは、マルチ・モデル・インターフェースをサービスにサポートするミドルウェア構成要素である。Simjaは、種々のメディア・フォーマットを翻訳する。それぞれの翻訳機は単一の機能を有し、別の翻訳機への接続が可能である。Simjaにおいては、この接続はパスと呼ばれ、パスは要求を表す仕様に従って自動的に翻訳機の中でセットアップされる。本実施例で提案したシステムの手法においては、プラグイン・モジュールがモノリシック（"monolithic"）であり、各相互通信装置が独立して入力／出力モジュールを形成することが必要であるので、このSimjaの手法は、プラグイン・モジュールを構築するには有益である。
【００６５】
五番目のシステムであるHAViには、利用者との相互通信をサポートする２つの方法がある。一番目の方法は、"Data Driven Interaction"(DDI)である。これは、グラフィカル・ユーザー・インターフェースを記述するための宣言方法を提供する。この手法に於いて、ユーザー・インターフェースは、UIML の様な文書として記述され、この文書は表示装置の特性に応じて提供されるが、しかし、UMILはXMLに基ずいていて、HAViのDDIより一般的である。二番目の方法は、前記CUESシステムに似ている。Java AWTで書かれたユーザー・インターフェースを含むJavaバイトコードがHAVi装置にダウンロードされ、グラフィカル・ユーザー・インターフェースが装置の画面上に表示される。ここで生じる問題は、CUESの場合と同じである。
【００６６】
本実施例では、従来のグラフィカル・ユーザー・インターフェース・システムと、進歩したネットワーク化されたホーム・コンピューティング用入力／出力相互通信装置との間の隙間を埋める新しいユーザー・インターフェースについて説明してきた。実施例に提示するシステムは、グラフィカル・ユーザー・インターフェースを含むビットマップ・イメージの内容は分析しない。それ故に、ビットマップ・イメージが出力装置５へ翻訳されなければ、或いは、入力イベントがマウスまたはキーボードへ翻訳されなければ、本システムを利用するのは難しい。しかし、ネットワーク化された音響映像家庭用装置は、大画面の表示装置と共に使用されるのが普通なので、本システムが、これ等の家庭用機器を制御するのには十分であると、我々は信じるものである。さらに本システムが、WindowsやLinux上で実行する種々のアプリケーションを制御するのに利用することができる。
【００６７】
また本実施例では、上述の隙間を埋めるユーザー・インターフェース・システムであるネットワーク化された家庭用機器用の全般的相互通信を提案した。このシステムは如何なる場所でも一様な方法で機器の制御が可能であり、Java AWTまたはGTK+の様な従来の標準グラフィカル・ユーザー・インターフェースを、アプリケーションが利用することができるが、利用者は、PDAや携帯電話などの種々の装置、若しくは進歩した技術により、そのインターフェースを操作することができる。しかも、Citrix（登録商標） Metaframe，Microsoft（登録商標） Terminal Servier，Sun Microsystems Sun RayそしてAT&T（登録商標） VNC(VirtualNetwork Computing)などの国籍のないシンクライアント・システムに基づいた目標を、非常に容易に実現できる。そして、プロトタイプ・システムを構築し、利用者が自分の携帯する種々の相互通信装置を使用することができる。ここでのプロトタイプ・システムは、家庭用機器用の広く分布した標準ミドルウェア仕様であるHAViを導入したホーム・コンピューティング・システムと現在統合されており、これは家庭用機器を制御するのに有益である。
【００６８】
以上のように本実施例によれば、利用できる機器に応じて、その機器を制御するのに必要なグラフィカル・ユーザー・インターフェースを生成して提示するアプリケーション手段たるアプリケーション１と、前記機器を制御するためのコマンドを伝送する入力装置４と、表示手段を備えた出力装置５と、入力装置４および出力装置５と、アプリケーション１との間に介在するプロキシ手段としてのUniIntプロキシ３とを備え、UniIntプロキシ３は、入力装置４や出力装置５から受信メッセージを受け取ることにより、現在利用可能な入力装置４や出力装置５を検出してそれを選択する利用可能装置検出手段としてのプラグ・アンド・プレイ管理モジュール13を備えたネットワーク機器汎用相互通信装置において、機器からの出力イベントとして、アプリケーション１から汎用相互通信プロトコルによって送られてきたグラフィカル・ユーザー・インターフェースに含まれるビットマップ・イメージを、プラグ・アンド・プレイ管理モジュール13が選択した出力装置５の表示手段に表示できるように、該出力装置５の特性に従ってコード変換して、このコード変換したビットマップ・イメージを含むグラフィカル・ユーザー・インターフェースを前記出力装置５の表示手段に転送する出力管理手段としての出力プラグイン・モジュール22と、プラグ・アンド・プレイ管理モジュール13が選択した入力装置４からコマンドを受取ると、このコマンドをアプリケーション１が認識できるマウス或いはキーボードのイベントに変換し、この変換したマウス或いはキーボードのイベントを、前記機器への入力イベントとして、汎用通信プロトコルによってアプリケーション１へ伝送する入力管理手段としての入力プラグイン・モジュール21とをUniIntプロキシ３にさらに備えて構成される。
【００６９】
この場合、利用可能な機器に応じたグラフィカル・ユーザー・インターフェースが、その機器からの出力イベントとして、アプリケーション１から汎用相互通信プロトコルによってUniIntプロキシ３に送られると、そのグラフィカル・ユーザー・インターフェースに含まれるビットマップ・イメージは、UniIntプロキシ３により現在利用可能な出力装置５の表示手段に適合するように、この出力装置５の特性に従ってコード変換され、そのコード変換されたビットマップ・イメージを含むグラフィカル・ユーザー・インターフェースが表示手段に転送される。また、利用者が利用可能な機器を制御するには、表示手段に表示されるグラフィカル・ユーザー・インターフェースを参照しながら、現在利用できる入力装置４から適宜コマンドを伝送すればよい。こうすれば、どのような入力装置４であっても、UniIntプロキシ３は伝送されたコマンドを、汎用相互通信プロトコルに適合するマウスまたはキーボードのイベントに変換し、それを機器への入力イベントとして、アプリケーション１に伝送する。
【００７０】
つまり、ここでのUniIntプロキシ３はいわば異種の入力装置４や出力装置５を扱う手段としての機能を果すので、現存する標準のグラフィカル・ユーザー・インターフェースを変更することなく、種々の入力装置４や出力装置５を使って、一様な手順で機器の制御を行なうことができる。特に、キーボード／マウスを汎用入力イベントとして採用し、ビットマップ・イメージを汎用出力イベントとして採用することで、あらゆる入力装置４や出力装置５との接続のために、従来のグラフィカル・ユーザー・インターフェースのツールキットを利用することができる。
【００７１】
また、本実施例では、入力装置４から所望の出力装置５を選択するコマンドを受取ると、プラグ・アンド・プレイ管理モジュール13による選択に優先して、この出力装置５の表示手段が表示できるグラフィカル・ユーザー・インターフェースを出力装置５に転送するように、出力プラグイン・モジュール22を構成している。
【００７２】
このようにすると、入力装置４から表示したい出力装置５を選択するコマンドを伝送すると、その出力装置５の表示手段に適合したグラフィカル・ユーザー・インターフェースがUniIntプロキシ３から送り出される。したがって、利用者の状況や好みに応じた出力装置５の切替えが可能となり、利用者と機器との間を独自のものとすることができる。
【００７３】
さらに本実施例では、アプリケーション１が現在利用可能な機器を特定するために、プラグ・アンド・プレイ機能を有したネットワークを通じてこれらの機器と接続している。
【００７４】
プラグ・アンド・プレイ機能を有したネットワークは、どの機器が現在接続されているか、誰のパワースイッチがオンになっているかを知らせる機構をサポートしているので、アプリケーション１が現在利用可能な機器を容易に知ることができると共に、最も相応しいユーザー・インターフェースを容易に選定することができる。
【００７５】
なお、本発明は上記実施例に限定されることなく、本発明の範囲内で種々の変形実施が可能である。
【００７６】
【発明の効果】
本発明の請求項１の構成によれば、利用者がいかなる場所にいたとしても、従来の標準グラフィカル・ユーザー・インターフェースをそのまま利用して、一様な手順で機器の制御を行なうことができる。また、あらゆる入力装置や出力装置との接続のために、従来のグラフィカル・ユーザー・インターフェースのツールキットを利用することができる。
【００７７】
本発明の請求項２の構成によれば、利用者の状況や好みに応じた出力装置の切替えが可能になる。
【００７８】
本発明の請求項３の構成によれば、現在利用可能な機器を容易に知ることができると共に、最も相応しいユーザー・インターフェースを容易に選定できる。
【図面の簡単な説明】
【図１】 本発明の一実施例を示すシステムの全体構成をあらわした概略説明図である。
【図２】 同上プラグイン管理モジュールの機能構成を示す概略説明図である。
【図３】 同上実際のシステムの使用状態を示す概略説明図である。
【符号の説明】
１ アプリケーション（アプリケーション手段）
３ UniIntプロキシ（プロキシ手段）
４ 入力装置
５ 出力装置
13 プラグ・アンド・プレイ管理モジュール（利用可能装置検出手段）
21 入力プラグイン・モジュール（入力管理手段）
22 出力プラグイン・モジュール（出力管理手段）
Claims (3)
- 利用できる機器に応じて、その機器を制御するのに必要なグラフィカル・ユーザー・インターフェースを生成して提示するアプリケーション手段と、前記機器を制御するためのコマンドを伝送する入力装置と、表示手段を備えた出力装置と、前記入力装置および出力装置と前記アプリケーション手段との間に介在するプロキシ手段とを備え、
前記プロキシ手段は、前記入力装置や前記出力装置から受信メッセージを受け取ることにより、現在利用可能な入力装置や出力装置を検出してそれを選択する利用可能装置検出手段を備えたネットワーク機器汎用相互通信装置において、
前記機器からの出力イベントとして、前記アプリケーション手段から汎用相互通信プロトコルによって送られてきたグラフィカル・ユーザー・インターフェースに含まれるビットマップ・イメージを、前記利用可能装置検出手段が選択した前記出力装置の表示手段に表示できるように、該出力装置の特性に従ってコード変換して、このコード変換したビットマップ・イメージを含むグラフィカル・ユーザー・インターフェースを該出力装置の表示手段に転送する出力管理手段と、
前記利用可能装置検出手段が選択した前記入力装置からコマンドを受取ると、このコマンドを前記アプリケーション手段が認識できるマウス或いはキーボードのイベントに変換し、この変換したマウス或いはキーボードのイベントを、前記機器への入力イベントとして、汎用通信プロトコルによって該アプリケーション手段へ伝送する入力管理手段と、を前記プロキシ手段にさらに備えたことを特徴とするネットワーク機器汎用相互通信装置。 - 前記出力管理手段は、前記入力装置から所望の前記出力装置を選択するコマンドを受取ると、前記利用可能装置検出手段による選択に優先して、この出力装置の表示手段が表示できるグラフィカル・ユーザー・インターフェースを、該出力装置に転送するものであることを特徴とする請求項１記載のネットワーク機器汎用相互通信装置。
- 前記アプリケーション手段は、現在利用可能な前記機器を特定するために、プラグ・アンド・プレイ機能を有したネットワークを通じて該機器を接続したことを特徴とする請求項１または２記載のネットワーク機器汎用相互通信装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002008364A JP4002442B2 (ja) | 2002-01-17 | 2002-01-17 | ネットワーク機器汎用相互通信装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002008364A JP4002442B2 (ja) | 2002-01-17 | 2002-01-17 | ネットワーク機器汎用相互通信装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003208402A JP2003208402A (ja) | 2003-07-25 |
| JP4002442B2 true JP4002442B2 (ja) | 2007-10-31 |
Family
ID=27646644
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002008364A Expired - Fee Related JP4002442B2 (ja) | 2002-01-17 | 2002-01-17 | ネットワーク機器汎用相互通信装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4002442B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7823070B2 (en) * | 2003-12-19 | 2010-10-26 | Fuji Xerox Co., Ltd. | Methods and systems for extending existing user interfaces |
| JP2006107423A (ja) * | 2004-09-13 | 2006-04-20 | I System Kk | コンピュータシステム |
| JP2017027366A (ja) * | 2015-07-22 | 2017-02-02 | キヤノン株式会社 | 情報処理装置及びイベント管理方法 |
| EP3719688B1 (en) | 2017-12-01 | 2023-02-08 | Nec Corporation | Operation authentication relay device, method, and program |
-
2002
- 2002-01-17 JP JP2002008364A patent/JP4002442B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003208402A (ja) | 2003-07-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7363398B2 (en) | Intelligent total access system | |
| Henricksen et al. | Infrastructure for Pervasive Computing: Challenges. | |
| CN1849578B (zh) | 通过屏幕拼合在两个计算机之间产生对象处理平台 | |
| Román et al. | A middleware infrastructure for active spaces | |
| Borchers et al. | Stanford interactive workspaces: a framework for physical and graphical user interface prototyping | |
| JP2003177850A (ja) | ユーザ・インタフェース | |
| CN101755299A (zh) | 用于从主机存取数据的移动无线显示器以及控制方法 | |
| CN111897478A (zh) | 一种页面显示方法及显示设备 | |
| CN112165641A (zh) | 一种显示设备 | |
| CN1879355B (zh) | 用于远程用户接口的一致性用户接口前端 | |
| CN113630656B (zh) | 显示设备、终端设备及通信连接方法 | |
| JP4002442B2 (ja) | ネットワーク機器汎用相互通信装置 | |
| CN112073787B (zh) | 显示设备及首页显示方法 | |
| CN111818654B (zh) | 一种信道接入方法及显示设备 | |
| US8984540B2 (en) | Multi-user computer system | |
| Nakajima | System software for audio and visual networked home appliances on commodity operating systems | |
| Nakajima | How to reuse exisiting interactive applications in ubiquitous computing environments? | |
| CN113490013B (zh) | 一种服务器及数据请求方法 | |
| Nakajima | A middleware component supporting flexible user interaction for networked home appliances | |
| CN100396036C (zh) | 具有图形使用界面的计算机系统以及虚拟遥控系统和方法 | |
| WO2023130853A1 (zh) | 一种显示设备及提示信息的展示方法 | |
| KR100976181B1 (ko) | 무선 마우스 기능을 갖는 휴대 단말기 및 그를 이용한 주변디바이스 제어방법 | |
| CN112199612B (zh) | 一种书签添加和合并的方法及显示设备 | |
| Nakajima et al. | Middleware supporting various input/output devices for networked audio and visual home appliances | |
| Mankoff et al. | Domisilica: Providing ubiquitous access to the home |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050113 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070205 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070406 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070501 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070629 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070806 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070817 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100824 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110824 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120824 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120824 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130824 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |