JP2013175242A - 画像センサベースのヒューマンマシンインタフェースを提供する方法システムおよびソフトウェア - Google Patents

Abstract

【課題】画像センサベースのヒューマンマシンインタフェースを提供する。
【解決手段】各入力信号の種類が、それぞれキャプチャされた動作の種類に関連付けられており、動作の種類の選択肢のうちのキャプチャされた動作を、入力信号の選択肢のうちの一つの入力信号に変換する入力信号生成モジュールと、少なくとも一つの入力信号の種類を、ユーザによって指定されたコマンドに関連付ける構成プロファイルを生成するプロファイル生成モジュールと、前記構成プロファイルに従って、所与の種類の入力信号をコマンドに変換する信号変換モジュールと、を備える画像センサベースのヒューマンマシンインタフェースを提供する方法システムおよびソフトウェア。
【選択図】図２

Description

本発明は一般に、ヒューマンマシンインタフェースの分野に関する。より具体的には、本発明は、画像センサベースのヒューマンマシンインタフェースを提供するための方法システム、および付随するモジュールおよびソフトウェアの構成要素に関するものである。

ソフトウェアの歴史における最大パターンの１つは、計算集約型（ｃｏｍｐｕｔａｔｉｏｎ−ｉｎｔｅｎｓｉｖｅ）設計から提示集約型（ｐｒｅｓｅｎｔａｔｉｏｎ−ｉｎｔｅｎｓｉｖｅ）設計への転換である。機械がますます強力になってきているため、発明者はプレゼンテーションにおいてこの力の割合が確実に増加させることに労力を費やしてきた。この発展の歴史は、便宜上３つの時期：バッチ（１９４５−１９６８）、コマンドライン（１９６９−１９８３）およびグラフィック（１９８４以降）に分割することができる。この歴史は、当然ながらデジタルコンピュータの発明に始まる。後者２つの時期の運用期間は、活気のある新しいインタフェース技術が研究室から出現し、インタフェースに関するユーザの期待を本格的に変え始めた数年である。それらの技術は、相互作用的なタイムシェアリング技術とグラフィカルユーザインタフェースであった。

バッチの時期は、計算能力が非常に低く、高価であった。当時の最も大型のコンピュータがコマンドする、一秒あたりのロジックサイクルは今日の普通のトースターあるいは電子レンジより少なく、今日の自動車、デジタル時計、携帯電話よりかなり少ないものであった。従って、ユーザインタフェースは未発達であった。逆に、むしろユーザがコンピュータに適応しなくてはならず、ユーザインタフェースは経費がかかると考えられており、ソフトウェアは可能な限り少ない経費でプロセッサを最大利用するように設計されていた。

バッチマシーン用のユーザインタフェースの入力側は主にパンチカードか、あるいは紙テープのような同等の媒体であった。出力側はこれらの媒体にプリンタをつなぐラインを足していた。システムのオペレータコンソールの制限付例外によって、人はバッチマシーンとリアルタイムで相互作用していなかった。

バッチマシーンにジョブを提供するには、まず、プログラムとデータセットを記述したパンチカードのデッキを準備することが含まれていた。プログラムカードの穴開けは、コンピュータ自体では行われず、操作が難しく、非常に機械的故障が多い特殊なタイプライタのような機械で行われていた。ソフトウェアインタフェースも、同様に、可能な限り最小のコンパイラと翻訳者によって、語法を解析するべき構文の意味が非常に制限されているという点で許し難いものであった。

一旦カードを穴開けすると、ジョブキューやジョブ待ちにそれらが入る。最終的に、オペレータは、デッキをコンピュータに押し込んで、おそらく、別のデータセットまたは補助ソフトウェアを供給する磁気テープを装着する。このジョブは、最終結果あるいは（何度も）エラーログ付の停止通知を含むプリントアウトを行う。うまく稼動すると磁気テープに結果を書き込むこともでき、あるいは、後の計算に用いるデータカードを何枚か作ることができる。

一つのジョブにかかる所要時間は、しばしば数日にも及んだ。非常に運がよければ数時間ですむこともあったが、リアルタイムでの応答は前代未聞のことであった。しかし、カードキューより悪い結果もあった。いくつかのコンピュータでは、バイナリコードのプログラム内にさらに単調でエラーが生じやすいトグリングのプロセスを実際に必要とした。かなり初期の機械は実際、プラグ盤として知られる装置を用いて、中に組み込まれたプログラム論理を部分的に配線し直さねばならなかった。

初期のバッチシステムは、コンピュータ全体に現在も稼動しているジョブを与えた。プログラムデッキとテープは、Ｉ／Ｏデバイスと通信するために現在我々がオペレーティングシステムコードと考えているものを持っていなくてはならず、その他のメンテナンスを必要とするものは何であれ行っていた。バッチ時代の中頃である１９５７年以降は、いわゆる「ロード＆実行」システムを使って様々なグループが実験を開始した。これらのシステムは、コンピュータ内に常にあるモニタプログラムを使用していた。プログラムはサービスとしてモニタをコールすることができた。モニタのもう一つの機能は、提供されたジョブについてより良好なエラーチェックを行い、より早くより賢明にエラーをキャッチして、ユーザにより使いやすいフィードバックを発生することであった。このように、モニタは、オペレーティングシステムと、明確に設計されたユーザインタフェースの両方に向けての第１ステップを代表するものであった。

コマンドラインインタフェース（ＣＬＩｓ）は、システムコンソールに接続されたバッチモニタから発達した。その相互作用モデルは、一連の応答を要求するトランザクションであり、要求は、特殊な言語のテキストコマンドとして表わされていた。待ち時間はバッチシステムの待ち時間よりはるかに大きく、日または時間から秒へと減少した。従って、コマンドラインシステムによって、ユーザは、リアルタイムであるいはほぼリアルタイムで、前の結果に関するフィードバックに応答して、トランザクション後のステージに対する考えを変えることができた。ソフトウェアは予備的なものであり、以前では不可能であった方法で相互作用した。しかしながら、これらのインタフェースはユーザに比較的重いニーモニック負荷を課し、習得するのに一連の努力と学習時間を必要とした。

コマンドラインインタフェースは、タイムシェアリングコンピュータの台頭に非常に深く関係していた。タイムシェアリングデータの概念は１９５０年代に戻り、最も有力な初期の実験は、１９６５年以降のＭＵＬＴＩＣＳオペレーティングシステムであり、今日のコマンドラインインタフェースに最も影響のあったものは、１９６９年以降のユニックス自体のオペレーティングシステムであり、これはその後生じたほとんどのシステムに影響を与えた。

初期のコマンドラインシステムは、テレタイプとコンピュータを組み合わせたものであり、人と人の間のワイヤを通じた情報転送の仲介に功を奏した成熟技術に適合したものであった。テレタイプは本来、自動電信送受信用デバイスとして開発された。テレタイプの歴史は１９０２年に遡り、１９２０年には既にニュースルームなどで定着していた。テレタイプを再利用するにあたっては、経済的事項は検討すべきであったが、心理状態と驚き最小の法則も同様である。テレタイプは、多くのエンジニアやユーザに親しまれているシステムとのインタフェースポイントを提供した。

１９７０年半ばにビデオディスプレイ端末（ＶＤＴｓ）が広く採用されたことで、コマンドラインシステムは第２期に入った。これらは、プリンタヘッドまたはキャリッジが移動するより早く、文字をスクリーンのドット蛍光体に投影することができたため、待ち時間が更に短くなった。ＶＤＴｓはコスト状況からインクや紙といった消耗品を削減することによって双方向プログラミングに対する保守的な反対を抑え、１９５０年後半及び６０年代の最初のＴＶ世代に対して、１９４０年代のコンピュータの草分けであったテレタイプよりも、より象徴的で快適なものであった。

アクセス可能なスクリーンの存在と同様に重要なことだが、ソフトウェア設計者が、迅速かつ可逆的に変形できるテキストの２次元ディスプレイを、テキストではなく可視的に表示できるインタフェースに展開させるのにコストがかからないようにした。この種のパイオニアであるアプリケーションは、コンピュータゲームとテキストエディタである。ｒｏｇｕｅ（６）やＶＩ（１）などの初期の例のいくつかに近い古い型のものは、いまだにユニックス様式の活電部である。

スクリーンビデオディスプレイは、まったく新規ではなく、１９６１年のＰＤＰ−１と同じように早期にミニコンピュータに登場していた。しかし、シリアルケーブルを介して取り付けたＶＤＴｓに移行するまでは、ことのほか高価なコンピュータがアドレス可能なディスプレイを一つだけそのコンソールにサポートすることができた。このような条件下では、ビジュアルＵＩの様式を開発することは困難であった。このようなインタフェースは、全てのコンピュータが少なくとも一時的に単一ユーザ専用に動くことができるというめったにない状況においてのみ生じる、偶発的な出来事であった。

１９６２年以来、我々が現在グラフィカルユーザインタフェースと呼んでいるものによる散発的な実験が行われ、ＰＤＰ−１のＳＰＡＣＥＷＡＲゲームの先駆となった。このマシーンのディスプレイは、単なる文字端末ではなく、ベクトルグラフィックスをサポートするために作られた変形オシロスコープであった。ＳＰＡＣＥＷＡＲインタフェースは、主にトグルスイッチを使用するものだったが、初期の原型トラックボールを特徴付けるものでもあり、プレーヤ自身が特注していた。１０年後の１９７０年代初期には、これらの実験がビデオゲーム産業を生み出し、これは実際にＳＰＡＣＥＷＡＲのアーケードバージョンを作成する試みと共に始まった。

ＰＤＰ−１コンソールディスプレイは、２０年早い第２次世界大戦のレーダー表示管から始まったものであり、マサチューセッツ工科大学（ＭＩＴ）のリンカーン研究所におけるミニコンピュータの何人かのキーパイオニアが、かつてのレーダー技術者であったことを反映している。同じ１９６２年に大陸各地で、別のかつてのレーダー技術者が、スタンフォード研究所で別の先駆者となり始めていた。彼の名前は、ダグラスエンゲルバートである。彼は、これらの非常に初期のグラフィカルディスプレイによる個人的な経験と、１９４５年に現在ハイパーテキストと呼んでいる構想を与えたヴァネヴァー・ブッシュのゼミナール論文であるＡｓ Ｗｅ Ｍａｙ Ｔｈｉｎｋの両方から着想を得た。

１９６８年１２月に、エンゲルバートとＳＲＩの彼のチームは、最初のハイパーテキストシステムであるＮＬＳ／Ａｕｇｕｍｅｎｔについて、９０分間の公開デモンストレーションを行った。このデモンストレーションは、スリーボタンマウス（エンゲルバートの発明）と、複数ウィンドウのインタフェースのグラフィカルディスプレイと、ハイパーリンクと、スクリーン上でのビデオ会議の初公開を含むものであった。このデモは、１９９１年のＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂの発明まで、および、この発明を含めて、４半世紀の間コンピュータサイエンス界に反響があった。

このように、１９６０年初期には、グラフィカルプレゼンテーションが、ユーザを引き付けたことはすでによく理解されていた。マウスと同等のポインティングデバイスがすでに発明されており、１９６０年代後半の多くの大型汎用コンピュータは、ＰＤＰ−１に匹敵するディスプレイ容量を有していた。１９６８年、Ｕｎｉｖａｃ１１０８コンピュータのコンソールにおける非常に初期のビデオゲームは、２００４年に購入するとすれば４千５百万ドル近くかかるであろう。

ビデオゲームは非常に安価で簡単なプロセッサで、ハードワイヤに組み込まれたプログラムを稼動するため、コンピュータより早くに巨大市場のデバイスとなった。しかし、汎用目的のコンピュータでは、オシロスコープディスプレイが進化の終端となった。コンピュータとの通常の通信に、グラフィカルなビジュアルインタフェースを使用する概念は数年を待たねばならず、実際のところ、１９７０年後半のシリアルラインの文字ＶＤＴの最新式グラフィックス可能なバージョンによって到来した。

１９７０年代の最も初期のＰＡＲＣシステム以来、ＧＵＩｓの設計は、ＡｌｔｏがさきがけとなったＷＩＭＰ（ウィンドウ、アイコン、マウス、ポインタ）モデルと呼ばれるようになったものによってほぼ完全に独占されてきた。後の数十年にわたってコンピュータ処理とディスプレイハードウエアに大きな変化が生じたことを考えると、ＷＩＭＰを超えるものを考えることは驚くほど困難である。

いくつかの試みがなされてきた。おそらく、最も際立った試みは、ＶＲ（仮想現実）インタフェースであり、このインタフェースではユーザは没入型グラフィカル３Ｄ環境を移動し、その中でジェスチャをする。ＶＲは、１９８０年代半ばから大きなリサーチコミュニティを引き付けてきた。基本的な問題は、フライトシミュレータの設計者には長年知られていたが、ＶＲが人間固有の感覚システムを混乱させる方法である。すなわち、普通の速度でのＶＲの動きが、脳が動きの視覚的シミュレーションを体の現実の世界の動きについての内耳の報告と一致させようとするため、眩暈や吐き気を引きおこすことがある。

ジェフ・ラスキンのＴＨＥ（Ｔｈｅ Ｈｕｍａｎｅ Ｅｎｖｉｒｏｎｍｅｎｔ）プロジェクトは、ＧＵＩｓのズーム世界モデルを調査したものである。ＴＨＥでは、スクリーンが２Ｄ仮想世界のウィンドウとなり、そこでデータとプログラムが空間的位置によって組織化される。この世界のオブジェクトは、基準面の上の高さに応じて細かな数種のレベルで表わすことができ、最も基本的な選択動作は、ズームインとそこへのランドである。

エール大学のライフストリームプロジェクトは、実際、ＧＵＩを脱空間化させるといった、完全に反対の方向に進んでいる。ユーザのドキュメントは、修正日によって組織化されたある種のワールドラインあるいは一時的なストリームとして表わされ、様々な方法でフィルタにかけることができる。

これらの３つのアプローチは総て、ものに名前を付けることや、参照の主な形式として名称を用いることを回避するようにしたコンテキストを支持して、従来のファイルシステムを切り捨てるものである。このことは、最も長続きしており有効な特徴の一つであると思われるユニックスのアーキテクチュアのファイルシステムと階層名前空間に、これらのアプローチを合致させるのを困難にしている。それにもかかわらず、これらの初期の実験の一つは、いまだに、ＮＬＳ／Ａｕｇｍｅｎｔのエンゲルバートの１９６８年のデモと同程度に影響力があると実証することが可能である。

ユーザインタフェースの分野では、ヒューマンマシンインタフェースの改善されたシステムおよび方法が求められている。

本発明は、画像センサベースのヒューマンマシンインタフェースを提供するための方法システム、および付随するモジュールおよびソフトウェアの構成要素である。本発明のいくつかの実施形態によると、ＩＢＨＭＩの出力は、第１のマッピングテーブルに基づいて、出力列またはデジタル出力コマンドに変換することができる。ＩＢＨＭＩマッピングモジュールはＩＢＨＭＩから１またはそれ以上の出力を受信することができ、同一または他の機能的に関連する計算プラットフォームを起動する第１のアプリケーションの文字列またはコマンドを生成する場合に、第１のマッピングテーブルを参考にすることができる。マッピングモジュールは、キーボード、マウス、ジョイスティック、タッチパッド、または第１のアプリケーションが起動している計算プラットフォームと互換性があり、適切または適合する任意の他のインタフェースデバイスをエミュレートすることができる。本発明のいくつかの実施形態によると、ＩＢＨＭＩ、マッピングモジュールおよび第１のアプリケーションは、同一の計算プラットフォーム上で起動することができる。本発明の更なる実施形態によると、ＩＢＨＭＩ、マッピングモジュールおよび第１のアプリケーションは、１つのアプリケーションまたはプロジェクトに組み込むことができる。

本発明のいくつかの実施形態によると、第１のマッピングテーブルはマッピングモジュールがアクセスできる不連続なデータテーブルの一部であってもよく、あるいはマッピングテーブルは、（例えば、オブジェクトコードを含む）マッピングモジュール自体の一部であってもよい。第１の動作／位置タイプの位置の動作（例えば、右腕を上昇）の検出に関係するＩＢＨＭＩの第１の出力がマッピングモジュールにより受信することができ、第１のアプリケーションに設けられた第１の入力コマンド（例えば、右にスクロール）にマップすることができるように、第１のマッピングテーブルは第１のアプリケーションに付随していてもよい。第１のマッピングテーブルに応じて、第２の動作／位置タイプの動作または位置（例えば、左腕を上昇）の検出に関係するＩＢＨＭＩの第２の出力はマッピングモジュールによって受信することができ、第１のアプリケーションに設けられた第２の入力コマンド（例えば、左にスクロール）にマップすることができる。マッピングテーブルは、ＩＢＨＭＩの出力の幾つかまたは総ての選択肢に対するマッピングレコードを含んでもよい。マッピングテーブルは、第１のアプリケーションの入力文字列またはコマンドの幾つかまたは総ての選択肢に対するマッピングレコードを含んでもよい。マッピングテーブルは不揮発性メモリに記録することができ、あるいは計算プラットフォームの操作メモリ内に常駐していてもよい。このマッピングテーブルは、構成またはプロファイルファイルの一部であってもよい。

本発明の更なる実施形態によると、マッピングモジュールは第２のマッピングテーブルにアクセスすることができ、このマッピングテーブルは第１のアプリケーション、あるいは第２または第３のアプリケーションのいずれかに付随しうる。第２のマッピングテーブルは１またはそれ以上のマッピングレコードを含むことができ、マッピングレコードのいくつかは第１のマッピングテーブルの対応するレコードと同じであってもよく、幾つかのレコードは、第１のマッピングテーブルの対応するレコードとは異なっていてもよい。従って、マッピングモジュールが第２のマッピングテーブルを使用している場合、同じＩＢＨＭＩ出力の幾つかまたは総ては、マッピングモジュールにより生成された異なる出力文字列またはコマンドとなりうる。

本発明の更なる実施形態によると、ＩＢＨＭＩのマッピングテーブルジェネレータが設けられている。テーブルジェネレータはＩＢＨＭＩから所与の出力を受信することができ、ユーザにＩＢＨＭＩの所与の出力に関連する出力文字列またはコマンドに関する１またはそれ以上の選択肢を提供することができる。画像センサから得られる画像（例えば、ビデオ）内で検出されている決まった種類の動作／位置に応じて、ＩＢＨＭＩにより所与の出力を生成することができる。画像／ビデオファイル内で検出されている決まった種類の動作／位置に応じて、ＩＢＨＭＩにより所与の出力を生成することができる。本発明の更なる実施形態によると、マッピングテーブルジェネレータは、各出力に関連する検出された動作／位置タイプのグラフィック表示を含む、ＩＢＨＭＩ出力の幾つかまたは総ての選択肢を記憶していることができる。ジェネレータのグラフィカルユーザインタフェースは、ユーザに（任意に、コンピュータで生成された）所与の動作／位置タイプの表示や選択肢を提供し、出力文字列／コマンドを選択して、所与の動作／位置タイプをマップまたは関連させる（例えば、バインドする）ことができる。

本発明の更なる実施形態によると、人間モデルを具えるグラフィックインタフェースは、相関段階に使用することができる。（可能な入力手段を用いて）グラフィックモデルをモニタ／移動することにより、ユーザは、（例えば、ユーザの身体を使用して）ユーザによって後で模倣されるコンピュータイベント（例えば、コンピュータ処理されたシステムまたはアプリケーションの可能な入力信号）の動作と相互関係するキャプチャした動作（例えば、位置、移動、ジェスチャまたはその他）を選択することができる。代替的に、キャプチャされ、関連づけられる動作は、任意にまたは口頭で入手、記録および／または定義することができる。

さらに、他のアプリケーションで使用されるコードを作成して、これらの他のアプリケーションおよびそのユーザ自身により後に使用する相関関係／プロファイルを作成／展開する相関モジュールであるコンピュータイベントに、キャプチャした動作を（例えば、グラフィックインタフェース、ＳＤＫ ＡＰＩを介して）アクセスして使用してもよい。

プロフィルが互いに関連する一連の相関関係（例えば、特定のコンピュータ処理されたアプリケーションの起動および／または制御に必要な総てのコンピュータイベントの相関関係）を含みうるのに対し、一連の相関関係はプロファイルに分類される。例えば、１またはそれ以上のユーザは、任意の所定のコンピュータ処理されたシステム、またはアプリケーションに対してプロファイルされた１またはそれ以上の動きを「作る（ｂｕｉｌｄ）」ことができる。これは、複数の一連の異なる（または部分的に異なる）身体の動きを、所与のコンピュータ処理されたシステムまたはアプリケーションを制御する想定される入力信号またはコマンドの同一のリストと相関するようにすることができる。

本発明のいくつかの実施形態によると、一旦所与のプロファイルが終了する（すなわち、総ての必要なコンピュータイベントの動作が規定される）と、ユーザはコンピュータイベントを実行するために、これらの動作（例えば、身体の動き）の使用を開始してもよい。従って、コンピュータ処理されたシステムまたはアプリケーションの制御は、ユーザ自身の定義によってプロファイルされる。ユーザは、自身または他のユーザが使用するためのプロファイルを作ることもできる。

一旦相互に関連すると、キャプチャされた動作を実行して、コンピュータイベントを起動および／または制御することができる。一方で、特定のキャプチャした動作および相互に関連した動作を実行すると、限定はしないが、アプリケーションの実行可能なコマンド（例えば、キーボード、マウスまたはジョイスティック動作に予め割り当てられたコマンド）といった対応するコンピュータイベントをトリガすることもある。

本発明に関する主題は、本明細書の最終部分に特に指摘されており、明確に主張されている。しかしながら、本発明は、組織と操作方法の両方に関するものであり、その目的、特徴、および利点は、添付する図面とともに以下の詳細な説明を参照して読むことにより最もよく理解されるであろう。
図１は、信号変換モジュールを示すブロック図である。 図２は、信号変換システムを示すブロック図である。 図３Ａおよび図３Ｂは、ＩＢＨＭＩ信号変換システムの２つの別個の実施形態の実行段階を示す半絵図である。 図４は、本発明の幾つかの実施形態による信号変換システムの進展段階に関連する機能ブロックおよび信号フローを示す半絵図である。 図５Ａは、本発明の実施形態によるマッピングテーブルジェネレータの実行フローのステップを含む各フローチャートである。 図５Ｂは、本発明の実施形態によるマッピングテーブルジェネレータの実行フローのステップを含む各フローチャートである。 図５Ｃは、本発明の実施形態によるマッピングテーブルジェネレータの実行フローのステップを含む各フローチャートである。

図を単純かつ明確なものにするために、図面に示す要素はスケール通りである必要はない。例えば、いくつかの要素の寸法は、明確にするために他の要素に対して誇張するようにしてもよい。更に、対応するあるいは類似の要素を表示するにあたり、図面間で符号を繰り返し使用することがある。

以下の詳細な記載では、本発明に対する深い理解を与えるために、多くの具体的な詳細を説明している。しかしながら、本発明は、これらの具体的な詳細がなくても当該技術分野の当業者により実施されうるということを理解されたい。他の場合、既知の方法、手順、構成要素および回路は、本発明を不明瞭にしないように、詳しくは記載していない。

特に述べられていない限り、以下の説明から明らかなように、本明細書を通じて、「処理する（ｐｒｏｃｅｓｓｉｎｇ）」「コンピュータで計算する（ｃｏｍｐｕｔｉｎｇ）」「計算する（ｃａｌｃｕｌａｔｉｎｇ）」「決定する（ｄｅｔｅｒｍｉｎｉｎｇ）」などの用語を用いた説明は、コンピュータまたはコンピュータシステム、または、同様の電子コンピュータ装置の動作および／またはプロセスを意味し、これは、コンピュータシステムのレジスタおよび／またはメモリ内の電子などの物理的量として表わされるデータを、コンピュータシステムのメモリ、レジスタあるいはその他の情報保存、転送あるいは表示する装置内の物理量として同様に表わされたその他のデータに操作するおよび／または変換することを意味すると理解されたい。

本発明の実施例は、本書に述べる動作を実行する装置を含むものである。この装置は、所望の目的に対して特別に構成されているか、あるいは、コンピュータに保存されているコンピュータプログラムによって選択的に起動または再構築される、汎用目的のコンピュータを具えていてもよい。このようなコンピュータプログラムは、限定するものではないが、フロッピィディスク、光学ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、電子的にプログラム可能な読み取り専用メモリ（ＥＰＲＯＭ）、電子的に消去可能かつプログラム可能な読み取り専用メモリ（ＥＥＰＲＯＭ）、磁気あるいは光学カード、あるいは電子インストラクションの保存に適したその他の媒体を含むあらゆる種類のディスクといった、コンピュータで読み取り可能で、コンピュータシステムバスに接続可能な記憶媒体に保存することができる。

本書に示す処理およびディスプレイは、任意の特定のコンピュータまたは他の装置とは本質的には関連していない。様々な汎用システムを本書の教示によるプログラムに用いることができ、あるいは、所望の方法を実行するためより特化された装置を構成する方が有用であると判明することもあるであろう。様々なこれらのシステムに望ましい構造は、以下の記載から明らかとなるであろう。さらに、本発明の実施形態は、任意の特定のプログラム言語に関して記載はされていない。様々なプログラム言語を使用して、本書に記載された本発明を実施することができるということを理解されたい。

ここで図１を見てみると、信号変換モジュール１００などの信号変換要素が図示されている。信号変換モジュール１００は、出力文字列をデジタル出力コマンドに変換することができる。信号変換モジュール１００はさらに、マッピングモジュール１０２のようなマッピングモジュールから構成されており、これは、キャプチャされた動作出力１０４のようなキャプチャされた動作に付随する第１の信号を変換、転送または修正し、アプリケーションコマンド１０６のような第１のアプリケーションに付随する第２の信号に変換することができる。キャプチャされた動作出力は、ビデオストリーム、グラフィックファイル、マルチメディア信号等であってもよいが、これらの例に限定はされない。アプリケーションは、コンピュータゲーム、コンソールゲーム、コンソール装置、操作システム等であってもよいが、これらの例に限定はされない。

本発明のいくつかの実施形態によると、マッピングモジュール１０２は、キーボード、マウス、ジョイスティック、タッチパッドまたは第１のアプリケーションが起動している計算プラットフォームと互換性がある任意の他のインタフェース装置をエミュレートすることができる。

本発明のいくつかの実施形態によると、マッピングテーブル１０８などの第１のマッピングテーブルは、マッピングモジュール１０２がアクセスできる不連続なデータテーブルの一部であってもよく、あるいはマッピングテーブル１０８は、マッピングテーブルがオブジェクトコードに含まれるような場合に、マッピングモジュール１０２自体と一体であってもよい。第１の動作／位置タイプの位置の動作の検出（例えば、右腕の上昇）に付随するキャプチャされた動作出力１０４はマッピングモジュール１０２によって受信することができ、第１のアプリケーションに設けられた入力コマンド１０６（例えば、右にスクロール）にマップすることができるように、マッピングテーブル１０８は第１のアプリケーションに付随してもよい。マッピングテーブル１０８に応じて、第２の動作／位置タイプ（例えば、左腕の上昇）の動作または位置の検出に付随しうるキャプチャされた動作出力１１０はマッピングモジュール１０２によって受信することができ、第１のアプリケーションに設けられたアプリケーションコマンド１１２（例えば、左にスクロール）にマップすることができる。マッピングテーブル１０８は、キャプチャされた動作出力１０４および１１０といったキャプチャされた動作出力の幾つかまたは総てに対するマッピングレコードを含んでもよい。マッピングテーブルは、アプリケーションコマンド１０６および１１２といった、第１のアプリケーションの入力文字列またはコマンドの幾つかまたは総ての選択肢に対するマッピングレコードを含んでもよい。

本発明の更なる実施形態によると、マッピングモジュール１０２はマッピングテーブル１１４のような第２のマッピングテーブルにアクセスすることができ、このマッピングテーブルは、第１のアプリケーションか、あるいは第２または第３のアプリケーションの何れかに付随してもよい。マッピングテーブル１１４は１またはそれ以上のマッピングレコードを含み、これらのマッピングレコードの幾つかはマッピングテーブル１０８の対応するレコードと同一であってもよく、幾つかのレコード、データファイルまたは画像ファイルはマッピングテーブル１０８の対応するレコードと異なっていてもよい。従って、マッピングモジュール１０２がマッピングテーブル１１４を用いる場合、（マッピングテーブル１０８を用いた場合と同じ結果と一致して）キャプチャされた動作１１０はアプリケーションコマンド１１６となり、キャプチャされた動作出力１０４はアプリケーションコマンド１０６となることがある。マッピングレコードは、構成ファイルまたはプロファイルファイルといった不連続のデータファイルの一部であってもよい。このマッピングレコードは、ＩＢＨＭＩ ＡＰＩといった実行可能なコード、または第１または第２のアプリケーションの一部であってもよい。

ここで図２を見てみると、信号変換システム２００のような信号変換システムが図示されている。信号変換システム２００は、マッピングモジュール２０２のようなマッピングモジュールから構成され、このマッピングモジュールは、キャプチャされた動作出力２０４などのキャプチャされた動作に付随する第１の信号を変換し、アプリケーションコマンド２０６のような第１のアプリケーションに付随する第２の信号に変換することができる。信号変換システム２００はさらに画像センサベースのヒューマンマシンインタフェース（ＩＢＨＭＩ）２２０のようなキャプチャされた動作を検出する装置を具えてもよく、このヒューマンマシンインタフェース２２０は一連の画像を得ることができ、実質的に各画像は異なる時点に関連し、キャプチャされた動作出力２０４を出力する。信号変換システム２００はさらに、計算プラットフォーム２２４のような計算プラットフォームに付随するゲームアプリケーションといったアプリケーションをさらに具える場合がある。ＩＢＨＭＩ２２０は、動作および／またはビデオ、写真等といったマルチメディア信号を検知および／または記憶するように構成された、デジタルカメラ、ビデオカメラ、個人用デジタルアシスタント、携帯電話等の装置を具えることができる。

信号変換システム２００は基本的に、図１の信号変換モジュール１００に関して記載したものと同様に機能できると理解されたい。さらに、幾つかの実施形態では、キャプチャされた動作出力２０４は基本的に、図１におけるキャプチャされた動作出力１０４、および／またはキャプチャされた動作出力１１０の双方と同一であってもよい。本発明のいくつかの実施形態では、マッピングモジュール２０２は基本的に、図１のマッピングモジュール１０２と同一であってもよい。本発明のいくつかの実施形態では、アプリケーションコマンド２０６は基本的に、図１の総てのアプリケーションコマンド１０６、１１２および／または１１６総てと同一であってもよい。

任意に、本発明のいくつかの実施形態によると、ＩＢＨＭＩ２２０、マッピングモジュール２０２および／またはアプリケーション２２２は、同一の計算プラットフォーム２２４上で起動することができる。計算プラットフォーム２２４は、パーソナルコンピュータ、コンピュータシステム、サーバ、集積回路等であってもよいが、これらの例に限定はされない。

ここで図３Ａおよび図３Ｂを見てみると、本発明の実施形態の２つの別個の実施例を示している。図３Ａの実行によると、マッピングモジュールはアプリケーションに使用されるＡＰＩの一部である。ＡＰＩは、モーションキャプチャエンジン（例えば、ＩＢＨＭＩ）およびマッピングテーブルを含むＩＢＨＭＩ構成プロファイルと機能的に関連している。図３Ｂは、マッピングテーブルモジュールおよびマッピングテーブルがアプリケーションと一体型の実施例を示している。

図３Ａは、実行フェーズ４００Ａのような信号変換システムの実行フェーズの半絵図を示している。動作４０２のような動作は、ビデオカメラ４０３のような動作センサによってキャプチャされる。出力４０４のようなキャプチャされた動作出力は一連の画像を示すことができ、実質的に各画像は、ビデオ、オーディオ／ビデオ、マルチメディア信号等のように、異なる時点と関連している。モーションキャプチャエンジン４０５といったモーションキャプチャエンジンは、キャプチャされた動作出力をアプリケーションコマンド４０７のようなアプリケーションに付随するコマンドに変換する。モーションキャプチャエンジン４０５はＩＢＨＭＩ構成プロファイル４０６のようなＩＢＨＭＩ構成プロファイルを用いて、この変換を構成、実施または実行し、構成されたＩＢＨＭＩはキャプチャされた動作出力４０４とアプリケーションコマンド４０７の間の相関関係を規定し、モーションキャプチャエンジン４０５に組み込むことができる。アプリケーションコマンド４０７は、アプリケーションの入力またはインタフェースアプリケーション４０８などのインタフェース計算システムとして、ＡＰＩを介して転送される。実行フェーズ４００Ａは、動作４０２をアプリケーションコマンド４０７に変換し、ＩＢＨＭＩ構成プロファイル４０６に規定された所定の相関によって、モーションキャプチャエンジンを介してインタフェースアプリケーションのコマンドを実行する。図３Ｂは、アップリケーションと一体化した図３Ａの様々な構成要素を示しており、その結果、ＡＰＩの必要性が取り除かれている。

ここで図４を見てみると、ＩＢＨＭＩマッピングテーブル（例えば、構成ファイル）ジェネレータ／ビルダの記号によるブロック図を示している。ジェネレータはマッピングテーブルを有する構成ファイルを生成することができ、マッピングモジュール及びマッピングテーブルを含むＡＰＩを介して、アプリケーションにより使用することができる。更なる実施形態によると、ジェネレータは関数呼び出しライブラリ（すなわちＳＤＫ）をアプリケーションプロジェクトにリンクさせることができ、アプリケーションはＩＢＨＭＩや内蔵のマッピングモジュールを有するよう生成することができる。

ここで図５Ａを見てみると、フローチャート５００に見られるように、マッピングテーブルジェネレータの実行フローチャートを示している。マッピングテーブルジェネレータは、ステップ５０２に見られるようにキャプチャ動作デバイスから所与の出力を受信することができ、この出力は、ステップ５０１に記載されるように、ほぼ同時のライブ画像から表されている。テーブルジェネレータは、ユーザに、ステップ５０３に記載するように、所与のキャプチャされた動作出力に関連する出力文字列またはコマンドに関する１またはそれ以上の選択肢を提供することができる。本発明のいくつかの実施形態では、所与のキャプチャされた動作出力は、画像センサから得られる画像（例えば、ビデオ）内で検出された所与の種類の動作／位置に応じて、ＩＢＨＭＩにより生成することができる。ユーザは、ステップ５０４に記載されるように、要求された関連付けを選択することができる。マッピングテーブルジェネレータは、ステップ５０５に記載するように、更なるキャプチャされた動作を受信して以下のステップに引き続くように進行させることができる。プロセスの終端では、テーブルジェネレータは、ステップ５０６に記載するように、ＨＭＩの構成プロファイルを作ることができる。ステップ５０６に記載されたＨＭＩ構成プロファイルは、図１のマッピングモジュール１０２のようなマッピングモジュールまたはマッピングテーブル１０８のようなマッピングテーブルの双方の一部であってもよい。

ここで図５Ｂを見てみると、フローチャート６００に見られるように、マッピングテーブルジェネレータを示すフローチャートを図示している。マッピングテーブルジェネレータは、ステップ６０２に見られるように、記憶メモリから所与のキャプチャされた動作出力を受信することができる。記憶メモリは、キャプチャされた動作装置の一部、計算プラットフォームの一部、マッピングテーブルジェネレータの一部等であってもよいが、これらの例に限定はされない。さらに、ステップ６０２に記載された記憶メモリは、フラッシュメモリ、ハードドライブまたは他のものであってもよいが、これらの例に限定はされない。ステップ６０３乃至６０６は、実質的に上述の図５Ａにおける対応するステップ５０３乃至５０６と同じであってもよいと考えられる。

ここで図５Ｃを見てみると、フローチャート７００に見られるように、マッピングテーブルジェネレータを表すフローチャートを示している。マッピングテーブルジェネレータは、各出力に付随する動作／位置のグラフィック表示を含む、ＩＢＨＭＩ出力の幾つかまたは総ての選択肢を記憶していることができる。マッピングテーブルジェネレータのグラフィカルユーザインタフェース（ＧＵＩ）は、ユーザに（任意にコンピュータに生成された）所与の動作／位置タイプの表示及び選択肢を提供し、出力文字列／コマンドを選択させて、ステップ７０１に示すように、所与の動作／位置タイプをマップまたは関連させることができる。ユーザはその後、動作／位置を選択して、ステップ７０２に示すように、アプリケーションコマンドと関連させることができる。ステップ７０３乃至７０６は基本的に、上述の図５Ａの対応するステップ５０３乃至５０６と同一であってもよいと理解される。

本発明の特定の特徴が本書に図示および記載されてきたが、当該技術分野の当業者は多くの改変、置換、変更、および均等物を考えるであろう。従って、添付の特許請求の範囲は、本発明の精神の範囲に収まるこのような総ての改変および変更を包含することを意図するものであることを理解されたい。

Claims (1)

1. 各入力信号の種類が、それぞれキャプチャされた動作の種類に関連付けられており、動作の種類の選択肢うちのキャプチャされた動作を、入力信号の選択肢のうちの一つの入力信号に変換する入力信号生成モジュールと、
   少なくとも一つの入力信号の種類を、ユーザによって指定されたコマンドに関連付ける構成プロファイルを生成するプロファイル生成モジュールと、
   前記構成プロファイルに従って、所与の種類の入力信号をコマンドに変換する信号変換モジュールと、
   を備えることを特徴とする、映像信号変換システム。