JP2003208402A - ネットワーク機器汎用相互通信装置 - Google Patents

Abstract

(57)【要約】 【課題】 従来の標準グラフィカル・ユーザー・インタ
ーフェースをそのまま利用して、一様な手順で機器の制
御を行なう。 【解決手段】 利用可能な機器に応じたグラフィカル・
ユーザー・インターフェースがUniIntプロキシ３に送ら
れると、出力装置５の表示手段に適合するように変換さ
れ、表示手段に転送される。また、利用者が利用可能な
機器を制御するには、現在利用できる入力装置４から適
宜コマンドを伝送すればよい。こうすれば、どのような
入力装置４であっても、UniIntプロキシ３は伝送された
コマンドを、汎用相互通信プロトコルに適合するイベン
トに変換し、それをアプリケーション１に伝送する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワーク化さ
れた家庭用機器や個人用機器との汎用的な相互通信を行
うためのネットワーク機器汎用相互通信装置に関する。

【０００２】

【発明が解決しようとする課題】我々の毎日の生活は、
コンピュータを内蔵した種々の対象物により劇的に変化
をするであろう。これらの対象物は、人々の身体と記憶
を拡大するため知的な動作をするものと期待される。

【０００３】こうしたコンピュータ環境を実現する為
に、これまで多くの研究プロジェクトが種々の問題に挑
戦している。これらのコンピュータ環境は、広くユビキ
タス（Ubiquitous：どこにでもある）・コンピューティ
ングと呼ばれている。また、他の研究者たちは、パーベ
ーシブ・コンピューティング（"pervasive computin
g"）[3]、センティエント・コンピューティング（"sent
ient computing"）或いはシングス・ザット・シンク（"
Things That Think"）と呼ばれる同様の概念を提案して
いる。ユビキタス・コンピューティング環境において
は、種々の対象物がコンピュータを内包することにより
増加される。如何なるプログラムも、コンピュータによ
って実行することができるので、プログラムを置き換え
ることにより、これらの対象物は無限に拡張される可能
性を持っている。また、これらの対象物は、他の対象物
と通信を行なうネットワークを持つので、周囲を取り巻
く状況に従って、各対象物がそれぞれでプログラムを置
き換えることにより、一層アクティブに動作するであろ
う。例えば、我々の環境は我々に代わって世界中に起こ
っていることを記憶するかもしれないし、各々の対象物
が現時点で存在する場所を我々に教えるかもしれない。

【０００４】前述したように、前記ユビキタス・コンピ
ューティング環境を実現する為に、多くの研究が成され
ている。或る研究グループは、ユビキタス・コンピュー
ティング環境のプロトタイプ（代表例）を構築する作業
を行なってきた。これらの研究は、ユビキタス・コンピ
ューティングが我々の生活に与えるインパクトを示して
いる。また最近は、幾つかの標準ミドルウェアの仕様
が、ユビキタス・コンピューティングを実現するために
提案されている。ミドルウェアとは、いわゆるOS（Oper
ating System）上で動作し、アプリケーションソフトに
対してOSよりも高度で具体的な機能を提供するソフトウ
ェアのことで、OSとアプリケーションソフトの中間的な
性格を持っている。そのなかで、ネットワークを通じて
各種機器を接続し、相互に機能を提供しあうための技術
仕様であるJini（登録商標）や、同じように家庭内のパ
ソコンや周辺機器、AV機器、電話、家電製品などの機器
をネットワークを通じて接続し、相互に機能を提供しあ
うための技術仕様であるUPnP（ユニヴァーサル・プラグ
アンド・プレイ）は、ミドルウェアとして良く知られて
いるが、これらは分散された環境の中で種々のサービス
を発見する機構を備えている。また、別なミドルウェア
として知られるHAVi（Home Audio/Video Interoperabil
ity）は、ネットワーク化された家庭用機器の発展を可
能にする。それ故に、家庭環境におけるユビキタス・コ
ンピューティングは、近い将来に実現されるであろう。
こうしたユビキタス・コンピューティング環境は、ホー
ム・コンピューティングと呼ばれるが、ホーム・コンピ
ューティングは、我々の日常生活に直接関係があるの
で、とりわけ興味深い分野ではある。また、総ての人
は、ホーム・コンピューティング環境の急激な進歩を期
待しているので、ユビキタス・コンピューティングの効
果を示すことは的を得ていることである。

【０００５】こうしたホーム・コンピューティング環境
で最も重要な問題の一つは、コンピュータを内蔵した種
々の対象物が、如何に相互通信し合うかということであ
る。利用者と種々の対象物に内蔵されたコンピュータ間
の相互通信は、従来から幾つかの研究グループ[2,13,1
7,30]により開発が行なわれていた。これらの装置によ
れば、より自然に内蔵したコンピュータと相互通信を行
なうことができる。しかしながら、ネットワーク化され
た家庭用機器向けの現在の標準ミドルウェアは、Java
（登録商標）に標準で付属するグラフィック関連のクラ
スライブラリとして知られるJava AWTや、同じようにグ
ラフィック関係のライブラリとして知られるGTK+の様
な、従来からある標準グラフィカル・ユーザー・インタ
ーフェースを採用してきた。それ故に、PDA，携帯電話
あるいは上記研究段階のプロトタイプ相互通信機器か
ら、家庭用の機器を制御することは容易なことではな
い。また、利用者の現在の状況によって、自然な相互通
信は変化する。例えば、利用者が食事を料理しているな
らば、音声によって機器を制御したいが、ソファの上で
TVを見ている場合は、リモート・コントロールを使うの
が良いのかもしれない。このことは、最も適当な相互通
信は、利用者の現在の状況と好みによってダイナミック
に選定すべきであり、この相互通信装置の選定は、利用
者が家庭内，事務所或いは公共の場所のように如何なる
場所に居ようと、一貫したものであることを意味してい
る。

【０００６】そこで本発明は、利用者がいかなる場所に
いたとしても、従来の標準グラフィカル・ユーザー・イ
ンターフェースをそのまま利用して、一様な手順で機器
の制御を行なうことができるネットワーク機器汎用相互
通信装置を提供することをその目的とする。

【０００７】

【課題を解決するための手段】本発明の請求項１におけ
るネットワーク機器汎用相互通信装置は、利用できる機
器に応じて、その機器を制御するのに必要なグラフィカ
ル・ユーザー・インターフェースを生成して提示するア
プリケーション手段と、前記機器を制御するためのコマ
ンドを伝送する入力装置と、表示手段を備えた出力装置
と、前記入力装置および出力装置と前記アプリケーショ
ン手段との間に介在するプロキシ手段とを備え、前記プ
ロキシ手段は、前記入力装置や前記出力装置から受信メ
ッセージを受け取ることにより、現在利用可能な入力装
置や出力装置を検出してそれを選択する利用可能装置検
出手段と、前記アプリケーションから汎用相互通信プロ
トコルによって送られてきたグラフィカル・ユーザー・
インターフェースに含まれるイメージを、前記利用可能
装置検出手段が選択した前記出力装置の表示手段に表示
できるように変換し、この変換したイメージを含むグラ
フィカル・ユーザー・インターフェースを該出力装置の
表示手段に転送する出力管理手段と、前記利用可能装置
検出手段が選択した前記入力装置からコマンドを受取る
と、このコマンドを前記アプリケーション手段が認識で
きるイベントに変換し、この変換したイベントを汎用通
信プロトコルによって該アプリケーション手段へ伝送す
る入力管理手段とを備えて構成される。

【０００８】この場合、利用可能な機器に応じたグラフ
ィカル・ユーザー・インターフェースが、アプリケーシ
ョン手段から汎用相互通信プロトコルによってプロキシ
手段に送られると、そのグラフィカル・ユーザー・イン
ターフェースに含まれるイメージは、プロキシ手段によ
り現在利用可能な出力装置の表示手段に適合するように
変換され、その変換されたグラフィカル・ユーザー・イ
ンターフェースが表示手段に転送される。また、利用者
が利用可能な機器を制御するには、表示手段に表示され
るグラフィカル・ユーザー・インターフェースを参照し
ながら、現在利用できる入力装置から適宜コマンドを伝
送すればよい。こうすれば、どのような入力装置であっ
ても、プロキシ手段は伝送されたコマンドを、汎用相互
通信プロトコルに適合する例えばマウスまたはキーボー
ドのイベントに変換し、それをアプリケーション手段に
伝送する。

【０００９】つまり、ここでのプロキシ手段は異種の異
種の入力装置や出力装置を同じように取り扱う手段とし
ての機能を果すので、現存する標準のグラフィカル・ユ
ーザー・インターフェースを変更することなく、種々の
入力装置や出力装置を使って、一様な手順で機器の制御
を行なうことができる。

【００１０】また、本発明の請求項２におけるネットワ
ーク機器汎用相互通信装置は、前記入力装置から所望の
前記出力装置を選択するコマンドを受取ると、前記利用
可能装置検出手段による選択に優先して、この出力装置
の表示手段が表示できるグラフィカル・ユーザー・イン
ターフェースを、該出力装置に転送するように、前記出
力管理手段を構成したものである。

【００１１】このようにすると、入力装置から表示した
い出力装置を選択するコマンドを伝送すると、その出力
装置の表示手段に適合したグラフィカル・ユーザー・イ
ンターフェースがプロキシ手段から送り出される。した
がって、利用者の状況や好みに応じた出力装置の切替え
が可能となり、利用者と機器との間を独自のものとする
ことができる。

【００１２】本発明の請求項３におけるネットワーク機
器汎用相互通信装置は、前記アプリケーション手段が現
在利用可能な前記機器を特定するために、IEEE1394ネッ
トワークを通じて該機器を接続したことを特徴とする。

【００１３】IEEE1394ネットワークは、どの機器が現在
接続されているか、誰のパワースイッチがオンになって
いるかを知らせる機構をサポートしているので、アプリ
ケーション手段が現在利用可能な機器を容易に知ること
ができると共に、最も相応しいユーザー・インターフェ
ースを容易に選定することができる。

【００１４】

【発明の実施形態】以下、添付図面を参照しながら、本
発明における好適な実施例を説明する。先ず実施例の詳
細を説明する前に、ホーム・コンピューティング環境に
おいて、利用者との相互通信すなわち対話をサポート
（支援）する幾つかの設計選択について説明する。

【００１５】本発明の目的を達成するための方法は数種
ある。最も重要な論点は、種々の相互通信装置（デバイ
ス）を如何に支援するかである。従来のユーザー・イン
ターフェイス・システムは、数種の相互通信装置のタイ
プを想定している。例えば、マウス，トラック・ポイン
トそしてタッチ・スクリーンは、入力装置として使用さ
れる。柔軟なユーザー・インターフェース・システムを
構築する手法としては、次の３つの代案が考えられる。 （１）零の状態から新規のユーザー・インターフェイス
・システムを構築する。 （２）従来からある種々の相互通信装置用の各ユーザー
・インターフェイス・システムを呼び出す新たな装置の
独立層（レイヤ）を構築する。 （３）従来のユーザー・インターフェイス・システムの
入力／出力イベントを獲得し、相互通信装置に従ってそ
のイベントを翻訳する。

【００１６】（１）の手法は、最初から種々の相互通信
装置によって使用される新規なユーザー・インターフェ
イス・システムの構築を意味する。この手法は、システ
ムが新たな相互通信装置に適応されることを考慮に入れ
るので、新相互通信装置が出現した時に生き長らえるこ
とができる。しかしながら、現存の機器とミドルウェア
のコンポーネント（構成要素）を新たなユーザー・イン
ターフェイス・システムに編入する為には修正が必要が
あり、その開発には長い期間を必要とする。多くのホー
ム・コンピューティング・システムは、すでに現存のソ
リューション（問題点の解決や要求の実現を行なうため
の情報システム）を採用しているので、現在使用されて
いるユーザー・インターフェイス・システムを置き換え
るこことは不可能であろう。

【００１７】（２）の手法は、従来のユーザー・インタ
ーフェイス・システム上に新しい層を追加することによ
り、種々の相互通信装置を支援する2つの案がある。第
１案は、相互通信装置の独立層が、アプリケーションの
標準的な要求を各ユーザー・インターフェース・システ
ムへの要求に翻訳する。例えば、こうした手法に基礎を
置いた文献の中では、利用者と機器との間の相互通信方
法を含むドキュメントを、アプリケーションが指定して
いる。装置の独立層は、現存する各ユーザー・インター
フェイス・システム用のドキュメントを提供する。第２
案であるマルチプル・ユーザー・インターフェイス・シ
ステムにおいて、各機器は、getUI( )法を提供する。こ
の方法は、マルチプル・ユーザー・インターフェイス・
サポート・サービスへ参照信号を返し、各相互通信装置
に最も適したユーザー・インターフェイスを提供する。
双方の案は、非常に将来性があるが、第１案の様に現存
のアプリケーションを修正する必要があり、装置の独立
層がそれぞれの相互通信装置に対し実行されなければな
らない。それ故に、この手法は、ホーム・コンピューテ
ィング用に現存する標準仕様を支援するには適当ではな
い。

【００１８】最後の（３）の手法は、ユーザー・インタ
ーフェイス・システムによって生成されたビットマップ
・イメージが、機器制御のために相互通信装置の特性に
従がって変換される。また、相互通信装置からの入力イ
ベントは、マウス或いはキーボードのイベントに変換さ
れる。この手法では、入力／出力イベントの変換のため
に、グラフィカル・ユーザー・インターフェイス（GU
I）内のレイアウト情報を利用できないという制限があ
る。しかし、大部分の家庭用音響映像機器は、グラフィ
カル・ユーザー・インターフェイスを提示する表示装置
を備えている。この場合の最も重要な要求とは、グラフ
ィカル・ユーザー・インターフェイスを提示する表示装
置と、利用者の状況や好みに応じて、グラフィカル・ユ
ーザー・インターフェイスを提示する入力装置を変えた
いということであるが、こうした要求は、（３）の手法
において非常に上手く達成できる。一方、この手法は、
ホーム・コンピューティング用の現存のソフトウェアを
修正する必要は無い。また、従来のホーム・コンピュー
ティング用標準ミドルウェアで採用されてきたJava AWT
/Swing，X window system，Microsoft Windows（登録商
標）のような人気のあるユーザー・インターフェイス・
システムの大部分は、本手法にて極めて容易に採用でき
る。

【００１９】ここでは、HAViを実行するホーム・コンピ
ューティング・システムがJava AWTの使用を必要として
おり、しかも近い将来に、修正を行なうことなくHAViに
基づき開発される種々のホーム・コンピューティング・
アプリケーションを使いたいという前提で、（３）の手
法に基づく実施例を説明する。特に最近の興味は、家庭
用機器を構築するためのLinux を内蔵した使用形態にあ
って、それは（３）の手法をより実際的なものにする。
何故なら、Linuxはその基本的ユーザー・インターフェ
イス・システムとして、X windows システムを通常は取
り入れており、内蔵したLinux上の種々のアプリケーシ
ョンが、種々の相互通信装置により制御されることを、
本実施例で提案するシステムが可能にするからである。
こうしたアプリケーションは、従来の良く知られている
ユーザー・インターフェイス・ツールキットを使用可能
であるので、この手法は、種々の内蔵アプリケーション
を極めて容易に発展させることができる。

【００２０】本実施例で以後説明する（３）の手法にお
いて、入力／出力相互通信装置と機器との間の通信に広
く利用できるプロトコルを、ここで汎用相互通信（"uni
versal interaction"）と呼ぶ。この汎用相互通信は、
均一な方法にて種々の家庭用機器を制御することができ
る。このことは、何処にいて何を制御したいかによっ
て、人々の行動が制限を受けないことを意味する。した
がって、ここでの手法は、家庭用機器との極めて自然な
相互通信を提供する。

【００２１】機器からの出力イベントは汎用出力相互通
信イベントに変換され、そのイベントは、それぞれの出
力相互通信装置に向けて翻訳される。また、入力相互通
信装置で発生する入力イベントは汎用入力相互通信イベ
ントに翻訳され、そのイベントは機器内で実行されるア
プリケーションにより処理される。

【００２２】後述するUniIntプロキシと呼ばれる汎用相
互通信プロキシは、汎用相互通信プロトコルと各相互通
信装置の入力／出力イベント間の変換を広範囲に行なう
役割を演じる。もしも、各入力／出力相互通信装置のイ
ベントが汎用相互通信プロトコルに変換されるならば、
プロキシは機器の制御のために如何なる入力／出力相互
通信装置の使用も可能にする。この手法は、次のような
三つの非常に魅力的な特徴を提供する。

【００２３】第１の特徴は、入力相互通信装置と出力相
互通信装置が、利用者の状況と好みによって、それぞれ
独自に選択されることである。例えば、利用者は、PDA
を入力／出力相互通信装置に選択できる。また、利用者
は、携帯電話を入力相互通信装置に選択してもよいし、
またテレヴィジョンも出力相互通信装置として選択して
もよい。利用者は、携帯装置により生じる拡大された実
世界を操作することで、自分の意思表示によって機器を
制御できる。

【００２４】第２の特徴は、利用者の好みに応じてそれ
に相応しい入力／出力相互通信装置を選択できることで
ある。しかも、これらの相互通信装置は、利用者の現在
の状況によってダイナミックに変更される。例えば、入
力相互通信装置として携帯電話を使用している利用者
は、別の仕事のために現在両手が塞がっているので、相
互通信装置を音声入力システムに変えるであろう。

【００２５】第３の特徴は、もしもユーザー・インター
フェース・システムが汎用相互通信プロトコルと交信で
きれば、機器内で実行中の如何なるアプリケーションで
も、あらゆるユーザー・インターフェース・システムを
利用できることである。例えば、キーボード／マウスを
汎用入力イベントとして採用し、ビットマップ・イメー
ジを汎用出力イベントとして採用した場合、あらゆる相
互通信装置との接続のために、Java AWT, GTK+ そしてQ
tのような従来のグラフィカル・ユーザー・インターフ
ェイスのツールキットを利用することができる。

【００２６】実際、家庭用電化製品の殆どの標準仕様
は、GUI(グラフィカル・ユーザー・インターフェイス )
標準用のJava AWTを最近は採用する傾向にある。かくし
て、本手法を取り入れたシステムは、将来の各種家庭用
電化製品を、種々の相互通信装置から、それらのアプリ
ケーションを修正することなく制御することが可能にな
るであろう。現存のGUI標準を変更することは非常に難
しいので、この特徴は非常に望ましいものである。

【００２７】本実施例におけるシステムは、グラフィカ
ル・ユーザー・インターフェイスを描くためにビットマ
ップ・イメージを転送すると共に、入力用マウス／キー
ボードのイベントを処理するために、シンクライアント
・システム（"thin-client system"）を使用する。通常
のシンクライアント・システムは、ビューアとサーバか
ら成る。サーバは、アプリケーションが動作する機器上
で実行される。アプリケーションは、X window system
の様な従来のユーザー・インターフェースを使って、グ
ラフィカル・ユーザー・インターフェースを実行する。
ユーザー・インターフェース・システムにより作られる
ビットマップ・イメージは、通常はもう一つの機器上で
実行されるビューアへ送信される。一方、ビューアによ
って読み込まれるマウスとキーボード・イベントは、サ
ーバへ転送される。ビューアとサーバ間のプロトコル
は、標準プロトコル（例えば、前記VNCシステムに於い
ては、RFB（Remote Frame Buffer）プロトコルと呼ばれ
る）として規定される。ここでは、こうしたプロトコル
を汎用相互通信プロトコル（universal interactionpro
tocol）と呼ぶ。本システムは、利用者の居場所に従っ
て利用者の表示部（デスクトップ）を動かしたり、例え
ばMS Windows（登録商標）とX Window systemの両方と
いうように、同一画面上に複数の表示部を表示する。

【００２８】本システムでは、シンクライアント・シス
テムのビューアを、UniInt（Universal Interaction：
汎用相互通信）サーバから受け取ったビットマップ・イ
メージを出力装置へ転送するUniIntプロキシに置き換え
る。この手法では、如何なるシンクライアント・システ
ムのサーバも、UniIntサーバとして使用可能である。ま
た、UniIntプロキシは、入力相互通信装置から受け取っ
たイ入力イベントをUniIntサーバへ転送する。

【００２９】本実施例におけるシステムは、図１に示す
ように、次の主要な５つの構成要素から成る。すなわち
それは、家庭用機器（図示せず）のアプリケーション１
と、前記UniIntサーバ２と、UniInt プロキシ３と、入
力装置４と、出力装置５である。

【００３０】表示操作制御手段に相当する家庭用機器の
アプリケーション１は、現在使用できる家庭用機器を制
御するのに必要なグラフィカル・ユーザー・インターフ
ェース（表示操作形態）を作成するものである。例え
ば、家庭用機器としてTV（テレヴィジョン）が現在利用
できるならば、アプリケーション１は、TV用のユーザー
・インターフェースを作成する。一方、アプリケーショ
ン１は、いずれも家庭用機器であるTVとVCR（デジタル
ビデオカメラ）が現在両方とも利用できるならば、TVと
VCR用のGUIを構成する。

【００３１】汎用相互通信サーバに相当するUniIntサー
バ２は、windowシステムによって作られるビットマップ
・イメージを、汎用相互通信プロトコルを使って、UniI
ntプロキシ３へ送り出すと共に、UniIntプロキシ３から
受け取ったマウスとキーボードの各イベントを、window
システムに転送する機能を有する。現在の実行例では、
現存するシンクライアント・システムのサーバを修正す
る必要はないし、UniIntサーバ２をサポートするwindow
システム上で動作するあらゆるアプリケーションを、修
正を行なわずにシステムで制御することが可能である。

【００３２】プロキシ手段としての汎用相互通信プロキ
シに相当するUniIntプロキシ３は、内部ネットワークと
インターネットの境にあって、直接インターネットに接
続できない内部ネットワークの機器に代わって、インタ
ーネットとの接続を代理して行なうもので、ネットワー
クに出入りするアクセスを一元管理し、内部から特定の
種類の接続のみを許可したり、外部からの不正なアクセ
スを遮断するために用いられるが、これはとりわけ本シ
ステムにおいて最も重要な構成要素である。UniIntプロ
キシ３は、UniIntサーバ２から受け取ったビットマップ
・イメージを、出力装置５の特性に従って変換する。ま
た、UniIntプロキシ３は、入力装置４から受け取ったイ
ベントを、UniIntサーバ２との間の汎用相互通信プロト
コルに適応するマウス若しくはキーボードのイベントへ
と変換する。UniIntプロキシ３は、各機器を制御するた
めに、現在の適正な入力／出力相互通信装置４，５を選
択する。次に、選択された入力装置４は入力プラグイン
・モジュールの信号を送信すると共に、選定された出力
装置５は出力プラグイン・モジュールの信号をUniIntプ
ロキシ３に送信する。入力プラグイン・モジュールは、
入力装置４から受け取ったイベントやマウスやキーボー
ドのイベントへ翻訳するコードを備えている。出力プラ
グイン・モジュールは、UniIntサーバ２から受け取った
ビットマップ・イメージを、目標となる出力装置５の画
面上に表示することのできるイメージに変換するコード
を備えている。

【００３３】入力装置４は、利用者との相互通信をサポ
ートするもので、家庭用機器を制御するための利用者に
より発せられたコマンドを伝送するものである。出力装
置５は、機器を制御するのに必要なグラフィカル・ユー
ザー・インターフェースを表示するための表示手段（表
示装置）を備えている。

【００３４】UniIntプロキシ３は、異種の相互通信装置
４，５を扱う役目を演じる。また、UniIntプロキシ３
は、利用者の状況や好みに応じて相互通信装置４，５の
切り替えも可能である。これにより、利用者と機器との
間を独自のものとすることができる。

【００３５】ここでのUniIntプロキシ３はJava言語によ
り書かれており、実施例では、図１に示す如く４つのモ
ジュール部を備えている。第１のモジュールは、汎用相
互通信プロトコルモジュール11であり、これはUniIntサ
ーバ２と通信を行なうための汎用相互通信プロトコルを
実行するものである。この第1のモジュール11を置き換
えると、様々なシンクライアント・システムを備えたシ
ステムを使用することができる。このモジュール11は、
シンクライアント・システムの観点にて実行される同様
なモジュールを利用できる。第２のモジュールは、プラ
グイン管理モジュール12で、これは相互通信装置４，５
から入力／出力プラグイン・モジュールを受け取ると共
に、UniIntプロキシ３内の各モジュールとダイナミック
にリンク（連結）するものである。第３のモジュール
は、利用可能装置検出手段に相当するプラグ・アンド・
プレイ管理モジュール13で、これは現在利用可能な入力
／出力相互通信装置４，５を検出するものである。第4
のモジュールは、プラグイン移動管理モジュール14で、
これは相互通信装置４，５とUniIntプロキシ３との間の
入力／出力プラグイン・モジュールの移動を管理するも
のである。

【００３６】プラグ・アンド・プレイ管理モジュール13
は、UniIntプロキシ３の近くにある現在利用可能な入力
装置４や出力装置５を検出する。ここでのシステムで
は、独自のIDが各型式の入力装置４や出力装置５に割り
当てられる。UniIntプロキシ３は、周期的にビーコン・
メッセージを放送する。現行のプロトタイプ（代表例）
では、相互通信装置４，５は、IEEE802.11b，Ethernet
（登録商標）或いは赤外線ネットワークを通じて接続さ
れる。各相互通信装置４，５がビーコン・メッセージを
受け取ると、そこから受信メッセージを回答する。受信
メッセージは、その機器の型式を確認する独自のIDを含
んでいる。仮にUniInt プロキシ３が、複数の相互通信
装置４，５からそれぞれの受信メッセージを受け取る
と、UniIntプロキシ３は、UniInt プロキシ３によって
定められた選択に従って一つの相互通信装置４，５を選
定する。また、新規に検出された相互通信装置４，５が
受信メッセージを回答すると、例えその装置が現在使用
されている装置より好ましいものであれば、その装置は
現在使用中の相互通信装置４，５として選択される。

【００３７】UniIntプロキシ３が、その相互通信装置
４，５の検出後に新たな相互通信装置４，５を選択する
場合は、新たな相互通信装置４，５の使用前に確認メッ
セージを送る。それからUniIntプロキシ３は、現在まで
使われている相互通信装置４，５へ最終メッセージを送
る。最後にUniIntプロキシ３は、新たな相互通信装置
４，５からのプラグイン・モジュールの受け取りを待
つ。入力装置４や出力装置５の選定は、各利用者用のUn
iIntプロキシ３中に登録されている。仮にシステムが機
器を利用したい者を検出できない場合は、優先して不履
行（デフォルト）が選択される。また、プラグイン・モ
ジュールのそれぞれは、現在使用中の入力装置４や出力
装置５を切り替えるイベントを支援する。例えば、現在
使用されている出力装置５を変更するために、利用者は
UniIntプロキシ３に対しコマンドを送ることができる。
UniIntプロキシ３は、利用者が自分の好みの出力装置５
を選択するまでは、現在の出力装置４を次の出力装置５
に切り替える。

【００３８】UniIntプロキシ３からの受信メッセージを
受け取ると、入力装置４や出力装置５は、プラグイン・
モジュールをUniIntプロキシ３に送る。本システムで
は、入力装置４や出力装置５とUniIntプロキシ３と間の
プラグイン・モジュールを送信するために、MobileSpac
e移動体システムを使用している。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 Pil
ot用である。また３つの入力プラグイン・モジュール21
Ａ，22Ｂ，22Ｃは、それぞれキーボードおよびマウス，
Palm Pilot，コンパクトHTMLを支援するウェッブ・ブラ
ウザを有する携帯電話用である。

【００４３】ホーム・コンピューティング・アプリケー
ション１の役割は、利用者が家庭用機器を制御できよう
にすることである。利用者と家庭用機器間の相互通信
は、機器の機能が益々豊富になるので、より複雑になる
であろう。また機器の数は、将来増加するであろう。そ
れ故に、将来の家庭用機器は、種々の機器との状況認知
（"context-aware"）相互通信をサポートしなければな
らない。

【００４４】考慮すべき状況認知は、２つの型がある。
一番目は、相互通信の個別化である。相互通信は、また
利用者の状況に応じてカスタマイズされる。二番目の型
は、一個の機器として現在利用できる複数の機器を処理
することである。

【００４５】システムは誰が機器を制御するかを知らな
いので、機器との相互通信を個別化することは通常困難
である。本実施例におけるシステムでは、各利用者がPD
A装置や携帯電話などのような自身の保有する制御装置
を有することを仮定している。こうした制御装置が、利
用者の確認IDを伝送するならば、システムは誰がその機
器を制御したいかが判る。しかし本システムにおいて
は、利用者の確認をサポートしない従来のユーザー・イ
ンターフェース・システムをアプリケーション１が採用
すると仮定しているので、相互通信装置４，５からホー
ム・コンピューティング・アプリケーション１へ、その
様な情報を伝送する直接の方法は存在しない。それ故
に、現在の実施例では、各利用者用に個別化されたアプ
リケーション１を実行する異なったUniIntサーバ２を、
各利用者毎に備えている。アプリケーション１は、利用
者の好みに応じてカスタマイズされたユーザー・インタ
ーフェースを供給する。UniIntプロキシ３は、入力装置
４から得られる利用者の確認に応じて、最も相応しいUn
iIntサーバ２を選択する。

【００４６】本実施例におけるシステムは、現在の状況
によってどの機器が現在利用できるかを知る必要があ
る。現在のシステムにおいては、そのアプリケーション
１をどの機器が利用できるのかを知っているものと仮定
する。例えば、仮にアプリケーション1が3つの家庭用機
器をサポートしているならば、そのアプリケーション１
は、３つの機器を結合する７個のグラフィカル・ユーザ
ー・インターフェースを提供ことが必要である。ユーザ
ー・インターフェースは、現在利用可能な機器に応じて
選択される。本システムでは、IEEE1394ネットワークを
通じて各家庭用機器が接続されるものと仮定する。IEEE
1394ネットワークは、どの機器が現在接続されている
か、誰のパワースイッチがオンになっているかを知らせ
る機構をサポートしているので、アプリケーション１が
現在利用可能な機器を容易に知ることができると共に、
最も相応しいユーザー・インターフェースを容易に選定
することができる。

【００４７】一方、入力装置４や出力装置５は種々のも
のが利用可能であり、入力装置４と出力装置５を分離し
ても、あるいは結合してもよい。例えば、グラフィカル
・ユーザー・インターフェースは、PDA装置の画面上或
いはTV上の大型表示装置上に表示できる。TＶ上に表示
されるユーザー・インターフェースは、PDA 装置により
操作することもある。それ故に、利用者は自分の好みに
よって相互通信方式の多様な選択ができる。またこれら
の装置は、現在の状況に応じて変更が可能である。例え
ば、現在使用中の装置が利用できないならば、別の相互
通信装置を機器制御のために選択してもよい。

【００４８】本システムでは、前述したようにプラグイ
ン・モジュールをUniIntプロキシ３へ送信すると仮定す
る。しかしながら、マイクロフォンの様なある入力装置
４はプログラム化できないし、UniIntプロキシ３への送
信をサポートすることは困難である。この場合は、我々
は、その装置４を制御処理部であるパソコン（パーソナ
ルコンピュータ）へ接続し、パソコンはUniIntプロキシ
３と通信して、プラグイン・モジュールを伝送する。し
かしながら、パソコンはマイクロフォンが現在利用可能
か否かを理解できないので、ビーコン・メッセージがUn
iIntプロキシ３から受け取られた場合に、パソコン上の
プログラムが確認メッセージを何時戻すのかを知ること
は困難である。それ故に、現在のプロトタイプにおいて
は、その装置４が常に接続され利用可能であると仮定す
る。

【００４９】次に、上記構成におけるシステムの動作を
説明する。アプリケーション１が、現在利用可能な機器
が例えばテレヴィジョンとビデオ・レコーダー（VCR）
であると認識した時に、それらを制御するのに必要なグ
ラフィカル・ユーザー・インターフェースを提示する。
現在の利用者がそのTVプログラムの予約に興味がないと
すると、アプリケーション１は、電源制御、TVチャンネ
ルの選択、VCR機能を含むユーザー・インターフェース
をUniIntサーバ２に描く。UniIntプロキシ３は、これ等
の機器を制御したい利用者用にカスタマイズされたユー
ザー・インターフェースを描くアプリケーションを実行
するUniIntサーバ２を選択すると共に、その選択された
UniIntサーバ２は、インターフェースを含むビットマッ
プ・イメージをUniIntプロキシ３へ送信する。

【００５０】ここで、利用者がPDA装置を備えているこ
とを、UniIntプロキシ３が検出したと仮定する。入力／
出力装置４，５に相当するPDA装置は、入力／出力プラ
グイン・モジュールの信号をUniIntプロキシ３に伝送す
る。UniIntプロキシ３は、ビットマップ・イメージをPD
A装置へ送信する前に、出力プラグイン・モジュール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 P
ilotから動かすことができる。しかしながら、装置の電
源をオフしたら、グラフィカル・ユーザー・インターフ
ェイス上のカーソルは、パソコンのカーソルとマウスに
よって制御される。利用者の好みに応じて、PDA装置上
でグラフィカル・ユーザー・インターフェースを表示す
ることも可能である。また、現在のシステムは、家庭用
機器を制御するために携帯電話と一体化されている。携
帯電話の中には、ウェッブ・ブラウザを有するものがあ
る。これにより、携帯電話に表示される特別リンクをク
リックすることで、カーソルの移動を可能にする。

【００５５】図３は、実際のシステムの使用状態を示し
ている。この図にも示すように、例えばデジタルビデオ
カメラとデジタルTVチューナが同時に利用できるなら、
それらのためのコントロールパネルが、一枚のパネルと
して結合される。この図では、表示装置21に表示される
コントロールパネルが、Palm pilotなどの携帯情報端末
22と移動可能なモバイルパソコン23の両方により制御さ
れる。本実施例におけるホーム・コンピューティング・
システムでは、資源（リソース）保存能力を追加するこ
とで、標準Linuxを拡大するLinux/Rtを採用した。 Linu
xはまた、IEEE1394装置ドライバーとMPEG2デコーダを提
供する。また、Java仮想機器用のIBM社製JDK1.1.8が、H
AViミドルウェア・コンポーネントを実行するために使
用される。

【００５６】本実施例のシステムでは、グラフィカル・
ユーザー・インターフェイスを含むビットマップ・イメ
ージが、UniIntサーバ２からUniIntプロキシ３へ送信さ
れる。ビットマップ・イメージは、自身の内容に関する
意味情報を含んでいないので、UniIntプロキシ３は、そ
の内容を理解できない。例えば、ビットマップ・イメー
ジから各GUI(グラフィカル・ユーザー・インターフェイ
ス)成分のレイアウトを引き出すことは困難である。そ
れ故に、出力装置５の特性や利用者の好みに従ってレイ
アウトを変更することは容易ではない。また、本実施例
のシステムは、マウスとキーボードのイベントによって
のみ処理できる。このため、グラフィカル・ユーザー・
インターフェイスの操作は、カーソルの移動とマウス・
ボタンを押すことにより実行される。もしも、この限界
がシステムの有用性を損なうならば、他の手法を選択す
べきである。しかし、グラフィカル・ユーザー・インタ
ーフェイスをPDAと携帯電話から操作することにより、
家庭用機器との非常に柔軟性のある相互通信ができる。
家庭用機器は、一般的に大表示画面の使用を可能にして
くれると共に、各機器を制御するために画面上にグラフ
ィカル・ユーザー・インターフェイスを表示することを
可能にする。この様に、本実施例におけるシステムは、
将来の家庭用機器用ミドルウェア・コンポーネントに柔
軟性を持たせるのに十分な能力を有している。

【００５７】また、本実施例におけるシステムは、X wi
ndowの様な標準のwindow システム上で実行される如何
なるアプリケーションをも制御できる。ここでのホーム
・コンピューティング・システムにおいては、従来のア
プリケーションがホーム・コンピューティング・アプリ
ケーションと共存し、これらのアプリケーションは本シ
ステムによって、統一化された方法で制御可能である。
例えば、本システムによって、ホーム・コンピューティ
ング・アプリケーションと共に動作するMP3プレイヤー
やNetscape（登録商標）ブラウザを操作することができ
る。しかしながら、重複するwindowレイアウトは、本実
施例におけるユーザー・インターフェース・システムに
よって操作することが難しい。家庭用機器を制御するに
は、いわゆる"tiled window strategy"が適していると
考える。また、本実施例におけるシステムが、種々の速
度でのマウス・カーソルの移動をサポートするならば、
システムを楽な方法で使用することにより、家庭用機器
と、プレゼンテーション・ソフトウェアやウェッブ・ブ
ラウザの様な従来のアプリケーションの両方を制御でき
る。

【００５８】本実施例におけるホーム・コンピューティ
ング・システムのアプリケーションは、状況情報に応じ
てユーザー・インターフェースをカスタマイズするのに
非常に簡単な機能を提供する。本システムでは、IEEE13
94 のプラグ・アンド・プレイ能力を使ってどの機器が
使用可能かを監視する。また、利用できる機器の総ての
結合を知り、且つ各々を結合するためのユーザー・イン
ターフェースを設計することが必要であると考える。そ
れ故に、現在の構成に従って、それに相応しいユーザー
・インターフェースが選定される。

【００５９】プロトタイプのアプリケーションは、本シ
ステムの効果を証明するのに有用である。特に、各々の
機器における機能構成と、利用者の好みに応じたユーザ
ー・インターフェースのカスタマイズ化は、ネットワー
クされた家庭用機器を制御するのに有効である。しかし
ながら、状況認知（"context-aware"）アプリケーショ
ンを構築するための設計手法は、非常に特定されたもの
であり、それ故に、状況認知アプリケーションを組織的
な方法で構築する研究が必要で、場所の情報や利用者の
感情の様な、多くの状況情報を監視する種々のセンサー
を必要とする。また、例えば新しい機器がIEEE1394ネッ
トワーク上に現れようとも、自動的に機器における複数
機能を構成する技術を調べる必要がある。

【００６０】こうした問題を解決するために、2つの問
題を研究している。一番目の問題は、組織的な方法で状
況認知アプリケーションを構築することである。本手法
では、先ず、状況（"context"）を考慮に入れない基本
プログラムを作成する。それから、徐々に増加させなが
ら、状況を処理する新しい関係を加える。このプログラ
ム内で、一つの状況は一つの関係として考えられ、各関
係は基本プログラムから明瞭に分離される。こうしたア
スペクト志向のプログラミングは、この問題を解決する
助けとなると思われる。二番目の問題は、各状況を厳格
に指定することである。従来のシステムでは、状況の表
示は特別な方法で扱われる。しかしながら、ポータブル
な状況認知アプリケーションを構築する為に、状況の表
示は標準化されるべきである。

【００６１】なお、本実施例におけるシステムと類似す
る幾つかの手法がある。そうした５つのシステムを説明
すると共に、本実施例におけるシステムと比較を行な
う。

【００６２】第一のシステムは、Pebbleシステムであ
る。このPebbleシステムにより、世界で最も知られてい
るPDAのPalmPilotを介して、MS Windows（登録商標）オ
ペレーティング・システム用のデスクトップ・アプリケ
ーションを制御することができる。例えば、デスクトッ
プ上のカーソルは、PalmPilotのスクリーンに触れるこ
とにより、動かすことができる。このシステムは、本実
施例で提案したプロトタイプに非常に近い。しかしなが
らPebbleシステムは、システムの利用性に焦点を置くの
で、その目標は異なる。一方、本実施例におけるシステ
ムは、システムの構造に焦点を絞っており、種々の入力
装置４を使って、出力表示装置上においてグラフィカル
・ユーザー・インターフェースを操作できると共に、入
力／出力相互通信装置４，５は、利用者の好みに従って
切り替え可能である。本実施例におけるシステムの柔軟
性は、ネットワーク化された家庭用機器を支援する為に
より適している。

【００６３】二番目のシステムは、UIML(User Interfac
e Makeup Language)システムで、これは高度な装置の独
立性を持って、ユーザー・インターフェースの宣言的記
述が可能なXML言語である。もしも、アプリケーション
がUIML文書としてユーザー・インターフェースを書くと
すると、その文書は、各入力／出力相互通信装置に従っ
て翻訳される。例えば、Palm Pilotを入力／出力装置と
して使用するために、UIML文書はPalm Pilot上に提供さ
れる。またUIML文書は、音声相互通信を支援する為にVo
ice XML用に提供される。しかしながら、入力／出力装
置が分離されている場合は、この手法を採用することは
難しい。また、利用者の状況に応じて、これらの入力／
出力装置をダイナミックに切り替えるサポートが存在し
ない。

【００６４】三番目のシステムであるCUESシステムは、
モバイル装置から種々の機器を制御する骨組みを提供す
る。このシステムにおいては、各機器は、モバイル装置
へ送信されるJavaバイトコードを持っている。このコー
ドは、グラフィカル・ユーザー・インターフェースを含
み、モバイルコンピュータ上に表示される。利用者は、
モバイルコンピュータ上のグラフィカル・ユーザー・イ
ンターフェースによって、機器を制御できる。この手法
により、各機器に対して適正なグラフィカル・ユーザー
・インターフェースを使用できる。しかしながら、この
手法では、モバイルコンピュータは、Java AWT/Swing
により実行されるグラフィカル・ユーザー・インターフ
ェースを表示する中間サイズの表示器を有し、指示装置
とキーボードを持つべきであることを前提としている。
また、この手法は、ユーザー・インターフェースのカス
タマイズと相互通信装置のダイナミックな切り替えはサ
ポートしていない。

【００６５】四番目のシステムであるSimjaは、マルチ
・モデル・インターフェースをサービスにサポートする
ミドルウェア構成要素である。Simjaは、種々のメディ
ア・フォーマットを翻訳する。それぞれの翻訳機は単一
の機能を有し、別の翻訳機への接続が可能である。Simj
aにおいては、この接続はパスと呼ばれ、パスは要求を
表す仕様に従って自動的に翻訳機の中でセットアップさ
れる。本実施例で提案したシステムの手法においては、
プラグイン・モジュールがモノリシック（"monolithi
c"）であり、各相互通信装置が独立して入力／出力モジ
ュールを形成することが必要であるので、この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 Su
n RayそしてAT&T（登録商標） VNC(VirtualNetwork Com
puting)などの国籍のないシンクライアント・システム
に基づいた目標を、非常に容易に実現できる。そして、
プロトタイプ・システムを構築し、利用者が自分の携帯
する種々の相互通信装置を使用することができる。ここ
でのプロトタイプ・システムは、家庭用機器用の広く分
布した標準ミドルウェア仕様であるHAViを導入したホー
ム・コンピューティング・システムと現在統合されてお
り、これは家庭用機器を制御するのに有益である。

【００６９】以上のように本実施例によれば、利用でき
る機器に応じて、その機器を制御するのに必要なグラフ
ィカル・ユーザー・インターフェースを生成して提示す
るアプリケーション手段たるアプリケーション１と、前
記機器を制御するためのコマンドを伝送する入力装置４
と、表示手段を備えた出力装置５と、入力装置４および
出力装置５と、アプリケーション１との間に介在するプ
ロキシ手段としてのUniIntプロキシ３とを備え、UniInt
プロキシ３は、入力装置４や出力装置５から受信メッセ
ージを受け取ることにより、現在利用可能な入力装置４
や出力装置５を検出してそれを選択する利用可能装置検
出手段としてのプラグ・アンド・プレイ管理モジュール
13と、アプリケーション１から汎用相互通信プロトコル
によって送られてきたグラフィカル・ユーザー・インタ
ーフェースに含まれるイメージを、プラグ・アンド・プ
レイ管理モジュール13が選択した出力装置５の表示手段
に表示できるように変換し、この変換したイメージを含
むグラフィカル・ユーザー・インターフェースを前記出
力装置５の表示手段に転送する出力管理手段としての出
力プラグイン・モジュール22と、プラグ・アンド・プレ
イ管理モジュール13が選択した入力装置４からコマンド
を受取ると、このコマンドをアプリケーション１が認識
できるイベントに変換し、この変換したイベントを汎用
通信プロトコルによってアプリケーション１へ伝送する
入力管理手段としての入力プラグイン・モジュール21と
を備えて構成される。

【００７０】この場合、利用可能な機器に応じたグラフ
ィカル・ユーザー・インターフェースが、アプリケーシ
ョン１から汎用相互通信プロトコルによってUniIntプロ
キシ３に送られると、そのグラフィカル・ユーザー・イ
ンターフェースに含まれるイメージは、UniIntプロキシ
３により現在利用可能な出力装置５の表示手段に適合す
るように変換され、その変換されたグラフィカル・ユー
ザー・インターフェースが表示手段に転送される。ま
た、利用者が利用可能な機器を制御するには、表示手段
に表示されるグラフィカル・ユーザー・インターフェー
スを参照しながら、現在利用できる入力装置４から適宜
コマンドを伝送すればよい。こうすれば、どのような入
力装置４であっても、UniIntプロキシ３は伝送されたコ
マンドを、汎用相互通信プロトコルに適合する例えばマ
ウスまたはキーボードのイベントに変換し、それをアプ
リケーション１に伝送する。

【００７１】つまり、ここでのUniIntプロキシ３はいわ
ば異種の入力装置４や出力装置５を扱う手段としての機
能を果すので、現存する標準のグラフィカル・ユーザー
・インターフェースを変更することなく、種々の入力装
置４や出力装置５を使って、一様な手順で機器の制御を
行なうことができる。

【００７２】また、本実施例では、入力装置４から所望
の出力装置５を選択するコマンドを受取ると、プラグ・
アンド・プレイ管理モジュール13による選択に優先し
て、この出力装置５の表示手段が表示できるグラフィカ
ル・ユーザー・インターフェースを出力装置５に転送す
るように、出力プラグイン・モジュール22を構成してい
る。

【００７３】このようにすると、入力装置４から表示し
たい出力装置５を選択するコマンドを伝送すると、その
出力装置５の表示手段に適合したグラフィカル・ユーザ
ー・インターフェースがUniIntプロキシ３から送り出さ
れる。したがって、利用者の状況や好みに応じた出力装
置５の切替えが可能となり、利用者と機器との間を独自
のものとすることができる。

【００７４】さらに本実施例では、アプリケーション１
が現在利用可能な機器を特定するために、IEEE1394ネッ
トワークを通じてこれらの機器と接続している。

【００７５】IEEE1394ネットワークは、どの機器が現在
接続されているか、誰のパワースイッチがオンになって
いるかを知らせる機構をサポートしているので、アプリ
ケーション１が現在利用可能な機器を容易に知ることが
できると共に、最も相応しいユーザー・インターフェー
スを容易に選定することができる。

【００７６】なお、本発明は上記実施例に限定されるこ
となく、本発明の範囲内で種々の変形実施が可能であ
る。

【００７７】

【発明の効果】本発明の請求項１の構成によれば、利用
者がいかなる場所にいたとしても、従来の標準グラフィ
カル・ユーザー・インターフェースをそのまま利用し
て、一様な手順で機器の制御を行なうことができる。

【００７８】本発明の請求項２の構成によれば、利用者
の状況や好みに応じた出力装置の切替えが可能になる。

【００７９】本発明の請求項３の構成によれば、現在利
用可能な機器を容易に知ることができると共に、最も相
応しいユーザー・インターフェースを容易に選定でき
る。

【図面の簡単な説明】

【図１】本発明の一実施例を示すシステムの全体構成を
あらわした概略説明図である。

【図２】同上プラグイン管理モジュールの機能構成を示
す概略説明図である。

【図３】同上実際のシステムの使用状態を示す概略説明
図である。

【符号の説明】

１ アプリケーション（アプリケーション手段） ３ UniIntプロキシ（プロキシ手段） ４ 入力装置 ５ 出力装置 13 プラグ・アンド・プレイ管理モジュール（利用可能
装置検出手段） 21 入力プラグイン・モジュール（入力管理手段） 22 出力プラグイン・モジュール（出力管理手段）

Claims (3)

【特許請求の範囲】
1. 【請求項１】 利用できる機器に応じて、その機器を制
   御するのに必要なグラフィカル・ユーザー・インターフ
   ェースを生成して提示するアプリケーション手段と、 前記機器を制御するためのコマンドを伝送する入力装置
   と、 表示手段を備えた出力装置と、 前記入力装置および出力装置と前記アプリケーション手
   段との間に介在するプロキシ手段とを備え、 前記プロキシ手段は、前記入力装置や前記出力装置から
   受信メッセージを受け取ることにより、現在利用可能な
   入力装置や出力装置を検出してそれを選択する利用可能
   装置検出手段と、 前記アプリケーション手段から汎用相互通信プロトコル
   によって送られてきたグラフィカル・ユーザー・インタ
   ーフェースに含まれるイメージを、前記利用可能装置検
   出手段が選択した前記出力装置の表示手段に表示できる
   ように変換し、この変換したイメージを含むグラフィカ
   ル・ユーザー・インターフェースを該出力装置の表示手
   段に転送する出力管理手段と、 前記利用可能装置検出手段が選択した前記入力装置から
   コマンドを受取ると、このコマンドを前記アプリケーシ
   ョン手段が認識できるイベントに変換し、この変換した
   イベントを汎用通信プロトコルによって該アプリケーシ
   ョン手段へ伝送する入力管理手段と、 を備えたことを特徴とするネットワーク機器汎用相互通
   信装置。
2. 【請求項２】 前記出力管理手段は、前記入力装置から
   所望の前記出力装置を選択するコマンドを受取ると、前
   記利用可能装置検出手段による選択に優先して、この出
   力装置の表示手段が表示できるグラフィカル・ユーザー
   ・インターフェースを、該出力装置に転送するものであ
   ることを特徴とする請求項１記載のネットワーク機器汎
   用相互通信装置。
3. 【請求項３】 前記アプリケーション手段は、現在利用
   可能な前記機器を特定するために、IEEE1394ネットワー
   クを通じて該機器を接続したことを特徴とする請求項１
   または２記載のネットワーク機器汎用相互通信装置。