(57)【要約】【課題】複数種類の入力様式からの入力を処理するための記述に意味属性の記述を導入し、各入力がもつ意味属性を、アプリケーション開発者がマークアップ言語等を用いて記述できるようにする。【解決手段】ＧＵＩ入力部１０１及び音声入力部１０２を介してなされる、複数種類の入力様式による入力情報に基づいてユーザの指示を認識する情報処理方法において、複数種類の入力様式の各々は入力内容と意味属性との対応を含む記述を有する。複数種類の入力様式で入力された入力情報の各々が解析されて、入力内容が取得され、取得された入力内容の各々の意味属性が入力様式に対応する記述より取得される。マルチモーダル入力統合部１０４は、得られた意味属性に基づいて該取得工程で取得された入力内容を統合する。【選択図】  図１
2004362052.tif 000002
【特許請求の範囲】
【請求項１】
ユーザによって複数種類の入力様式で入力された入力情報に基づいてユーザの指示を認識する情報処理方法であって、
前記複数種類の入力様式の各々について入力内容と意味属性との対応を含む記述を有し、
複数種類の入力様式で入力された入力情報の各々について、入力情報を解析して入力内容を取得し、取得した入力内容の各々の意味属性をそれぞれ入力様式に対応する記述より取得する取得工程と、
前記取得工程で得られた意味属性に基づいて該取得工程で取得された入力内容を統合する統合工程とを備えることを特徴とする情報処理方法。
【請求項２】
前記複数種類の入力様式の一つがＧＵＩを介した要素の指示であり、ここで、該ＧＵＩの記述がマークアップ言語により記述されるとともに、各要素と意味属性との対応の記述を含み、
前記取得工程は指示された要素を検出して入力内容とし、前記ＧＵＩの記述より前記指示された要素に対応する意味属性を取得することを特徴とする請求項１に記載の情報処理方法。
【請求項３】
前記複数種類の入力様式の一つが音声入力であり、ここで、音声認識のための文法規則の記述が音声入力と意味属性との対応の記述を含み、
前記取得工程は前記文法規則の記述を参照して音声情報に音声認識処理を行なって入力音声を得てこれを入力内容とし、該文法規則の記述より前記入力音声に対応する意味属性を取得することを特徴とする請求項１又は２に記載の情報処理方法。
【請求項４】
前記文法規則がマークアップ言語を用いて記述されていることを特徴とする請求項３に記載の情報処理方法。
【請求項５】
前記取得工程は、更に各入力内容の入力時刻を取得し、
前記統合工程は、前記取得工程で取得された入力内容の各々の入力時刻と意味属性とに基づいて、複数の入力内容を統合することを特徴とする請求項１乃至４のいずれかに記載の情報処理方法。
【請求項６】
前記取得工程は、更に各入力内容の値、バインド先に関する情報を含み、
前記統合工程は、前記入力値の値及びバインド先に関する情報に基づいて統合の要否を判定し、統合が不要な入力内容はそのまま出力し、統合が必要な入力内容は各々の入力時刻と意味属性とに基づいて統合して得られた結果を出力することを特徴とする請求項５に記載の情報処理方法。
【請求項７】
前記統合工程は、統合が必要な入力内容のうち、入力時刻の時間差が所定範囲であり、意味属性が一致する入力内容を統合して出力することを特徴とする請求項６に記載の情報処理方法。
【請求項８】
前記統合工程は、入力時刻の時間差が所定範囲であり、同じバインド先の入力内容或いは統合結果を出力する場合、それらが入力時刻の順に出力されることを特徴とする請求項６に記載の情報処理方法。
【請求項９】
前記統合工程は、入力時刻が同一であり、同じバインド先の入力内容或いは統合結果が出力されようとした場合、予め設定されている入力様式の優先順位に従い、優先順位の高い方の入力様式で入力された方を選択して出力することを特徴とする請求項６に記載の情報処理方法。
【請求項１０】
前記統合工程は、入力時刻の早い順に入力内容の統合を行なうことを特徴とする請求項６に記載の情報処理方法。
【請求項１１】
前記統合工程は、入力内容を入力時刻順に並べた際に意味属性の異なる入力内容を跨ぐ入力内容について統合を禁止することを特徴とする請求項６に記載の情報処理方法。
【請求項１２】
前記マークアップ言語はＸＭＬであることを特徴とする請求項２又は４に記載の情報処理方法。
【請求項１３】
前記記述には１つの入力内容に対して複数の意味属性が記述されており、
前記統合工程は複数の意味属性に基づいて複数種類の統合の可能性が生じた場合に、各意味属性に割り当てられた重みに基づいて統合すべき入力内容を決定することを特徴とする請求項１に記載の情報処理方法。
【請求項１４】
前記統合工程は、前記取得工程において一つの入力情報について複数の入力内容が取得された場合、解析における各入力内容の確信度に基づいて統合すべき入力内容を決定することを特徴とする請求項１に記載の情報処理方法。
【請求項１５】
ユーザによって複数種類の入力様式で入力された入力情報に基づいてユーザの指示を認識する情報処理装置であって、
前記複数種類の入力様式の各々について入力内容と意味属性との対応を含む記述を有し、
複数種類の入力様式で入力された入力情報の各々について、入力情報を解析して入力内容を取得し、取得した入力内容の各々の意味属性をそれぞれ入力様式に対応する記述より取得する取得手段と、
前記取得手段で得られた意味属性に基づいて該取得手段で取得された入力内容を統合する統合手段とを備えることを特徴とする情報処理装置。
【請求項１６】
ＧＵＩを記述する記述方法において、各ＧＵＩ要素に対応する意味属性をマークアップ言語を用いて記述することを特徴とする記述方法。
【請求項１７】
音声で入力された音声入力情報を認識するための文法規則において、各音声入力に対応した意味属性を該文法規則中に記述することを特徴とする記述方法。
【請求項１８】
請求項１乃至１４のいずれかに記載の情報処理方法をコンピュータによって実行するための制御プログラムが格納された記憶媒体。
【請求項１９】
請求項１乃至１４のいずれかに記載の情報処理方法をコンピュータによって実行するための制御プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、複数の入力様式を用いて指示を行なうための、所謂マルチモーダル・ユーザインタフェースに関するものである。
【０００２】
【従来の技術】
ＧＵＩ入力や音声入力といった複数種類のモダリティ（入力様式）から、ユーザの所望のモダリティをもって情報の入力を可能にするマルチモーダル・ユーザインタフェースは、ユーザにとって利便性が高いものである。特に、複数種のモダリティを同時に用いて入力を行った場合の利便性は高く、例えば音声で「これ」等の指示語を発声しながらＧＵＩで対象を示すボタン等をクリックするといったような操作を行うことにより、コマンド等の専門的な言語に不慣れなユーザであっても自由に対象機器を操作することができる。このような操作を可能にするためには複数種のモダリティによる入力を統合するための処理が必要になる。
【０００３】
複数種類のモダリティによる入力を統合する処理の例として、音声認識結果に対して言語解析を行う方法（特許文献１）や文脈情報を用いる方法（特許文献２）、入力時刻の近いものをまとめて意味解析単位として出力する方法（特許文献３）、言語解析を行って意味構造を用いる方法（特許文献４）が開示されている。
【０００４】
また、ＩＢＭらがＸＨＴＭＬ＋Ｖｏｉｃｅ  Ｐｒｏｆｉｌｅという仕様を策定しており、この仕様を利用することによりマルチモーダル・ユーザインタフェースをマークアップ言語で記述することができる。上記仕様の詳細についてはＷ３Ｃのウェブサイト（ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｘｈｔｍｌ＋ｖｏｉｃｅ／）に記述されている。またＳＡＬＴ  ＦｏｒｕｍではＳＡＬＴという仕様が公開されており、上述のＸＨＴＭＬ＋Ｖｏｉｃｅ  Ｐｒｏｆｉｌｅと同様に、この仕様を利用することによりマルチモーダル・ユーザインタフェースをマークアップ言語で記述することができる。上記仕様の詳細についてはＳＡＬＴ  Ｆｏｒｕｍのウェブサイト（Ｔｈｅ  Ｓｐｅｅｃｈ  Ａｐｐｌｉｃａｔｉｏｎ  Ｌａｎｇｕａｇｅ  Ｔａｇｓ：ｈｔｔｐ：／／ｗｗｗ．ｓａｌｔｆｏｒｕｍ．ｏｒｇ／）に記述されている。
【０００５】
【特許文献１】
特開平９−１１４６３４号公報
【特許文献２】
特開平８−２３４７８９号公報
【特許文献３】
特開平８−２６３２５８号公報
【特許文献４】
特開２０００−２３１４２７号公報
【０００６】
【発明が解決しようとする課題】
しかしながら、上記従来例では、複数種類のモダリティを統合する際に言語解析等の複雑な処理を行わなければならない。また上記処理を行ったとしても、言語解析の解析誤り等により、ユーザが意図する入力の意味をアプリケーションに反映できない場合がある。ＸＨＴＭＬ＋ＶｏｉｃｅやＳＡＬＴに代表される技術、及び従来のマークアップ言語による記述方法では、入力が持つ意味を表す意味属性の記述を取り扱うような仕組みは無い。
【０００７】
本発明は上記の課題に鑑みてなされたものであり、簡易の処理で、ユーザのいとどおりのマルチモーダル統合入力の実現を可能とすることを目的とする。
より具体的には、複数種類の入力様式からの入力を処理するための記述において、入力が持つ意味を表す意味属性の記述といった新規な記述を導入し、簡易な解析処理でユーザ或いは設計者が意図したとおりの入力の統合を実現させることを目的とする。
また、本発明は、各入力がもつ意味属性を、アプリケーション開発者がマークアップ言語等を用いて記述できるようにすることを目的とする。
【０００８】
【課題を解決するための手段】
上記の目的を達成するための本発明による情報処理方法は、
ユーザによって複数種類の入力様式で入力された入力情報に基づいてユーザの指示を認識する情報処理方法であって、
前記複数種類の入力様式の各々について入力内容と意味属性との対応を含む記述を有し、
複数種類の入力様式で入力された入力情報の各々について、入力情報を解析して入力内容を取得し、取得した入力内容の各々の意味属性をそれぞれ入力様式に対応する記述より取得する取得工程と、
前記取得工程で得られた意味属性に基づいて該取得工程で取得された入力内容を統合する統合工程とを備える。
【０００９】
【発明の実施の形態】
以下、添付の図面を参照して、本発明に係る実施形態について説明する。
【００１０】
［第１実施形態］
図１は、第１実施形態における情報処理システムの基本構成を示すブロック図である。情報処理システムはＧＵＩ入力部１０１、音声入力部１０２、音声認識・解釈部１０３、マルチモーダル入力統合部１０４、記憶部１０５、マークアップ解釈部１０６、制御部１０７、音声合成部１０８、表示部１０９、通信部１１０を有する。
【００１１】
ＧＵＩ入力部１０１はボタン群やキーボード、マウス、タッチパネル、ペン、タブレット等の入力装置で構成され、ユーザからの各種指示を本装置に入力するための入力インタフェースとして機能する。音声入力部１０２はマイクロフォンやＡ／Ｄ変換器等で構成され、ユーザの音声を音声信号に変換する。音声認識・解釈部１０３は音声入力部１０２より提供される音声信号を解析し、音声認識を行う。なお、音声認識技術については公知の技術を利用可能であり、ここでは詳細な説明を省略する。
【００１２】
マルチモーダル入力統合部１０４は、ＧＵＩ入力部１０１や音声認識・解釈部１０３から入力された情報を統合する。記憶部１０５は、各種の情報を保存するためのハードディスクドライブ装置や、情報処理システムに各種の情報を提供するためのＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の記憶媒体及びドライブ等により構成される。またこのハードディスクドライブ装置や記憶媒体には、各種のアプリケーションプログラム、ユーザインタフェース制御プログラム、そして各プログラムを実行する際に必要な各種のデータ等が記憶されており、これらは後段の制御部１０７の制御により、本システムに読み込まれる。
【００１３】
マークアップ解釈部１０６はマークアップで記述された文書を解釈する。制御部１０７はワークメモリやＣＰＵ、ＭＰＵ等により構成されており、記憶部１０５に記憶されたプログラムやデータを読み出してシステム全体の各種の処理を実行する。例えば、マルチモーダル入力統合部１０４で統合した結果を、音声合成出力するために音声合成部１０８に渡したり、画像で表示するために表示部１０９に渡したりする。音声合成部１０８はスピーカやヘッドフォン、Ｄ／Ａ変換器等により構成されており、制御部１０７の制御により読み上げテキストから音声データを作成してこれをＤ／Ａ変換し、音として外部に出力する処理を行う。なお、音声合成技術については公知の技術を利用可能であり、ここでは詳細な説明を省略する。表示部１０９は液晶ディスプレイ等の表示装置から構成され、画像や文字等により構成される各種の情報を表示する。なお、表示部１０９としてタッチパネル式の表示装置を用いてもよく、その場合、表示部１０９はＧＵＩ入力部１０１としての機能（各種の指示を本システムに入力する機能）をも有することになる。通信部１１０は、インターネットやＬＡＮ等のネットワークを介して他の装置とのデータ通信を行うためのネットワークインタフェースである。
【００１４】
次に、以上の構成を有する情報処理システムへ入力を行うための機構（ＧＵＩ入力及び音声入力）について説明する。
【００１５】
まず、ＧＵＩ入力について説明する。図２は、上記情報処理システムにおいて、各部品を提示するためのマークアップ言語（本例ではＸＭＬ）による記述の例を示す図である。同図において〈ｉｎｐｕｔ〉タグは各ＧＵＩ部品を記述し、ｔｙｐｅ属性で部品の種類を記述する。また、ｖａｌｕｅ属性で部品の値を記述、ｒｅｆ属性で部品のバインド先のデータモデルを記述する。このようなＸＭＬ文書は、Ｗ３Ｃ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ）の仕様であり、公知の技術である。なお、仕様の詳細についてはＷ３Ｃのウェブサイト（ＸＨＴＭＬ：ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｘｈｔｍｌ１１／，ＸＦｏｒｍｓ：ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｘｆｏｒｍｓ／）に記述されている。
【００１６】
図２においてｍｅａｎｉｎｇ属性は、上記既存の仕様を拡張したものであり、部品の意味属性を記述できる構造を持つ。このように部品の意味属性をマークアップ言語で記述できるようにすることで、アプリケーション開発者自身が意図する各部品の意味を簡単に設定することができる。尚、上記意味属性は、必ずしもｍｅａｎｉｎｇ属性のように独自の仕様を用いる必要はない。例えば、図３に示されるようにＸＨＴＭＬの仕様にあるｃｌａｓｓ属性のような既存の仕様を利用して意味属性を記述してもよい。上記マークアップ言語で記述されたＸＭＬ文書はマークアップ解釈部１０６（ＸＭＬパーサ）にて解釈を行う。
【００１７】
上記ＧＵＩ入力処理方法について図４のフローチャートを用いて説明する。ユーザによりＧＵＩ入力部１０１から、例えばＧＵＩ部品の指示が入力されるとＧＵＩ入力イベントを取得する（ステップＳ４０１）。続いて、当該指示の入力された時刻（タイムスタンプ）を取得し、図２のｍｅａｎｉｎｇ属性（或いは図３のｃｌａｓｓ属性）にて指示されたＧＵＩ部品の意味属性を当該入力の意味属性に設定する（ステップＳ４０２）。更に、当該指示された部品のデータのバインド先及び入力値が上述したＧＵＩ部品の記述より取得される。そして、当該部品のデータについて得られたバインド先、入力値、意味属性、タイムスタンプを、入力情報としてマルチモーダル入力統合部１０４に出力する（ステップＳ４０３）。
【００１８】
上記ＧＵＩ入力処理の具体例を図１０、図１１を参照して説明する。図１０には、ＧＵＩを介して値「１」を持つボタンが押された場合の処理を示している。このボタンは図２もしくは図３に示すようにマークアップ言語で記述されており、このマークアップ言語を解釈することにより、値が「１」、意味属性が「ｎｕｍｂｅｒ」、データのバインド先が「／Ｎｕｍ」であることがわかる。ボタン「１」が押されると、入力された時刻（タイムスタンプ，図１０では「００：００：０８」）が取得される。そして、当該ＧＵＩ部品の値「１」、意味属性「ｎｕｍｂｅｒ」、データのバインド先「／Ｎｕｍ」と、上記タイムスタンプがマルチモーダル入力統合部１０４に出力される（図１０：１００２）。
【００１９】
また、同様に、図１１のようにボタン「恵比寿」が押された場合は、タイムスタンプ（図１１では「００：００：０８」）と、図２もしくは図３のマークアップ言語を解釈することにより得られる値「恵比寿」、意味属性「ｓｔａｔｉｏｎ」、データのバインド先「−（バインドなし）」がマルチモーダル入力統合部１０４に出力される（図１１：１１０２）。以上のような処理を行うことで、アプリケーション開発者が意図する意味属性を、アプリケーション側で入力の意味属性情報として取り扱うことができるようになる。
【００２０】
次に、音声入力部１０２よりの音声入力の処理について説明する。図５は、音声を認識するためのグラマ（文法規則）を示す図である。図５は、「ここから」や「恵比寿まで」といった音声入力を認識し、ｆｒｏｍ＝“＠ｕｎｋｎｏｗｎ”、ｔｏ＝“恵比寿”のような解釈を出力するルールを記述したグラマである。図５において、ｉｎｐｕｔ列は入力音声であり、該入力音声に対応した値をｖａｌｕｅ列に、意味属性をｍｅａｎｉｎｇ列に、バインド先のデータモデルをＤａｔａＭｏｄｅｌ列に記述する構造を持つ。このように音声を認識するためのグラマ（文法規則）に意味属性（ｍｅａｎｉｎｇ）を記述できるようにしたことにより、各音声入力に対応した意味属性をアプリケーション開発者自身が簡単に設定することができ、言語解析等の複雑な処理を行う必要がない。
【００２１】
図５において、「ここ」等、単一の入力では処理を行うことができず、他のモダリティによる入力との照応が必要になる入力に対しては、ｖａｌｕｅに特別な値（本例では＠ｕｎｋｎｏｗｎ）を記述する。このように特別な値をあらかじめ定めておくことで、単一の入力では処理を行うことができないことをアプリケーション側で判別することができ、言語解析等の処理を行う必要がない。尚、上記グラマ（文法規則）は、図６のようにＷ３Ｃの仕様を用いて記述してもよい。上記仕様の詳細についてはＷ３Ｃのウェブサイト（Ｓｐｅｅｃｈ  Ｒｅｃｏｇｎｉｔｉｏｎ  Ｇｒａｍｍａｒ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ：ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｓｐｅｅｃｈ−ｇｒａｍｍａｒ／，Ｓｅｍａｎｔｉｃ  Ｉｎｔｅｒｐｒｅｔａｔｉｏｎ  ｆｏｒ  Ｓｐｅｅｃｈ  Ｒｅｃｏｇｎｉｔｉｏｎ：ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｓｅｍａｎｔｉｃ−ｉｎｔｅｒｐｒｅｔａｔｉｏｎ／）に記述されている。ただし、Ｗ３Ｃの仕様では意味属性を記述する構造になっていないため、図６では解釈結果（入力値）にコロン（：）と意味属性が付記されている。よって、後に上記解釈結果と意味属性を分離する処理が必要になる。上記マークアップ言語で記述されたグラマはマークアップ解釈部１０６（ＸＭＬパーサ）にて解釈を行う。
【００２２】
以下では、上記音声入力・解釈処理方法について図８のフローチャートを用いて説明する。ユーザにより音声入力部１０２から音声が入力されると音声入力イベントを取得する（ステップＳ８０１）。続いて、入力された時刻（タイムスタンプ）を取得し、音声認識・解釈処理を行う（ステップＳ８０２）。ここで解釈処理結果の例を図７に示す。例えばネットワークに接続された音声処理装置を利用した場合には図７のようなＸＭＬ文書で解釈結果を得る。図７において、〈ｎｌｓｍｌ：ｉｎｔｅｒｐｒｅｔａｔｉｏｎ〉タグで１つの解釈結果を示し、更にｃｏｎｆｉｄｅｎｃｅ属性でその確信度を示している。また、〈ｎｌｓｍｌ：ｉｎｐｕｔ〉タグで入力された音声を示し、〈ｎｌｓｍｌ：ｉｎｓｔａｎｃｅ〉タグで認識した結果を示している。上記解釈結果を表現する仕様はＷ３Ｃで公開されており、その仕様の詳細についてはＷ３Ｃのウェブサイト（Ｎａｔｕｒａｌ  Ｌａｎｇｕａｇｅ  Ｓｅｍａｎｔｉｃｓ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ  ｆｏｒ  ｔｈｅ  Ｓｐｅｅｃｈ  Ｉｎｔｅｒｆａｃｅ  Ｆｒａｍｅｗｏｒｋ：ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｎｌ−ｓｐｅｃ／）に記述されている。グラマと同様に、上記音声解釈の結果（入力音声）はマークアップ解釈部１０６（ＸＭＬパーサ）により解釈することができる。そして、この解釈結果に対応する意味属性を文法規則の記述より取得する（ステップＳ８０３）。更に文法規則の記述より当該解釈結果に対応するバインド先、入力値が取得され、意味属性やタイムスタンプとともにマルチモーダル入力統合部１０４に入力情報として出力される（ステップＳ８０４）。
【００２３】
以上説明した音声入力処理の具体例について、図１０及び図１１を用いて説明する。図１０では、音声「恵比寿まで」が入力された場合の処理を示している。図６のグラマ（文法規則）に示すように「恵比寿まで」という音声が入力された場合、値が「恵比寿」、意味属性が「ｓｔａｔｉｏｎ」、データのバインド先が「／Ｔｏ」であることがわかる。音声「恵比寿まで」が入力されると、入力された時刻（タイムスタンプ，図１０では「００：００：０６」）を取得し、上記の値「恵比寿」、意味属性「ｓｔａｔｉｏｎ」、データのバインド先「／Ｔｏ」と併せてマルチモーダル入力統合部１０４に出力する（図１０：１００１）。なお、図６のグラマ（音声認識のための文法）では、下の方の〈ｏｎｅ−ｏｆ〉と〈／ｏｎｅ−ｏｆ〉タグで囲まれた、「ココ」や「シブヤ」、「エビス」、「ジユーガオカ」、「トーキョー」等のいずれかと、「カラ」あるいは「マデ」とを組み合わせて音声入力することができる。（例えば、「ココカラ」や「エビスマデ」）。また、上記の組み合わせも可能である（例えば、「シブヤカラジユーガオカマデ」や「ココマデトーキョーカラ」）。そして、「カラ」と組み合わされた言葉をｆｒｏｍの値として解釈し、「マデ」と組み合わされた言葉をｔｏの値として解釈し、解釈結果として〈ｉｔｅｍ〉〈ｔａｇ〉〈／ｔａｇ〉〈／ｉｔｅｍ〉で囲まれた部分を返す。よって、音声で「エビスマデ」と入力した場合、ｆｒｏｍの値として“恵比寿：ｓｔａｔｉｏｎ”を返し、音声で「ココカラ」と入力した場合、ｔｏの値として“＠ｕｎｋｎｏｗｎ：ｓｔａｔｉｏｎ”を返すことになる。「エビスカラトーキョーマデ」と入力された場合は、ｆｒｏｍの値として“恵比寿：ｓｔａｔｉｏｎ”を返し、Ｔｏの値として“東京：ｓｔａｔｉｏｎ”を返すことになる。
【００２４】
同様に、図１１のように音声「ここから」が入力された場合は、タイムスタンプ「００：００：０６」と、図６のグラマ（文法規則）により、入力値「＠ｕｎｋｎｏｗｎ」、意味属性「ｓｔａｔｉｏｎ」、データのバインド先「／Ｆｒｏｍ」をマルチモーダル入力統合部１０４に出力する（図１１：１１０１）。以上のような処理を行うことで、音声入力処理においても、アプリケーション開発者が意図する意味属性を、アプリケーション側で入力の意味属性情報として取り扱うことができるようになる。
【００２５】
次に、マルチモーダル入力統合部１０４の動作について、図９Ａ〜図１９を参照して説明する。なお、本実施形態では、上述したＧＵＩ入力部１０１と音声入力部１０２よりの入力情報（マルチモーダル入力）を統合する処理を説明する。図９Ａはマルチモーダル入力統合部１０４における上記各入力モダリティからの入力情報を統合する処理方法を示すフローチャートである。まず、各入力モダリティから入力情報（データのバインド先、入力値、意味属性、タイムスタンプ）が出力されると、該入力情報を取得し（ステップＳ９０１）、全ての入力情報をタイムスタンプ順に並べる（ステップＳ９０２）。続いて意味属性の同じ入力情報を対象に、入力された順番を対応付けて情報を統合する（ステップＳ９０３）。すなわち、同じ意味属性の入力情報を入力された順番に従って統合していく。より詳細には、次のとおりである。すなわち、例えば、図１６で後述するように、「ここから（渋谷をクリック）ここまで（恵比寿をクリック）」という入力が入った場合、音声入力情報は、
（１）ここ（ｓｔａｔｉｏｎ）←“ここから”の“ここ”
（２）ここ（ｓｔａｔｉｏｎ）←“ここまで”の“ここ”
の順で入ってくる。また、ＧＵＩ入力（クリック）情報は、
（１）恵比寿（ｓｔａｔｉｏｎ）
（２）東京（ｓｔａｔｉｏｎ）
の順で入ってくる。そして、（１）同士、（２）同士をそれぞれ統合する。
【００２６】
複数の入力情報を統合するための条件としては、
（１）統合処理が必要であること、
（２）かつタイムリミット内（例えばタイムスタンプの差が３秒以内）であること、
（３）意味属性が一致していること、
（４）タイムスタンプ順に並べたときに異なる意味属性を持つ入力情報をまたいでいないこと、
（５）「バインド先」と「値」が相補的な関係にあること、
（６）上記（１）〜（４）を満足するものの中で、最も早く入力された情報であることを統合条件とし、この統合条件を満たす入力情報を統合することになる。
なお、上記統合条件は一例であり、他の条件を設定してもかまわない。例えば、入力の空間的な近さ（座標）を導入してもよい。ここで、座標とは、例えば東京駅や恵比寿駅等の地図上の座標を用いることができる。また、例えば上記統合条件の一部のみを統合条件として用いる（例えば条件（１）と（３）のみを統合条件とする）ようにしてもよい。また、本実施形態では、異なるモダリティの入力を統合するものとし、同じモダリティの入力同士は統合しないものとする。
【００２７】
なお、上記の条件（４）は必ずしも必要というわけではないが、この条件を入れることによりかの利点が考えられる。
例えば、「ここから大人２枚そこまで」と音声入力する場合、クリックのタイミングと統合の解釈として、
（１）「（クリック）ここから大人２枚ここまで」→クリックと“ここ（から）”を統合するのが自然、
（２）「ここ（クリック）から大人２枚ここまで」→クリックと“ここ（から）”を統合するのが自然、
（３）「ここから（クリック）大人２枚ここまで」→クリックと“ここ（から）”を統合するのが自然、
（４）「ここから大人（クリック）２枚ここまで」→“クリックをここ（から）”と統合していいのか“ここ（まで）”と統合していいのか人間にもわからない、
（５）「ここから大人２枚（クリック）ここまで」→クリックと“ここ（まで）”を統合するのが自然、
というように考えた場合、条件（４）が無いと、即ち意味属性がまたがってもよいとすると、上記の（５）で、もし“ここ（から）”とクリックが時間的に近ければクリックと“ここ（から）”を統合してしまうことになる。但し、このような条件がインターフェースの用途に応じて変化し得ることは当業者であれば想像できることである。
【００２８】
図９ＢはステップＳ９０３の統合処理をより詳細に説明するフローチャートである。ステップＳ９０２によって入力情報が時刻順に並べられると、ステップＳ９１１において、先頭の入力情報が選択される。そして、ステップＳ９１２において、選択された入力情報について統合が必要か否かを判定する。ここでは、入力情報のバインド先もしくは入力値の少なくともいずれかが未定となっている場合には統合が必要であると判定し、バインド先及び入力値の両方が確定している入力情報については統合が不要であると判定する。統合が不要であると判定された場合、処理はステップＳ９１３へ進み、当該入力情報は単一入力としてバインド先及び入力値がマルチモーダル入力統合部１０４より出力される。それとともに、当該入力情報を出力したことを表すフラグをたてる。そして、ステップＳ９１９へ進む。
【００２９】
一方、統合が必要であると判定された場合、ステップＳ９１４へ進み、当該入力情報よりも早くに入力された入力情報の中で、上記統合条件を満足する入力情報を探索する。該当する入力情報が見つかった場合は、ステップＳ９１５からステップＳ９１６へ進み、当該入力情報と探索された入力情報を統合する。この統合処理については図１０〜１９により後述する。そして、ステップＳ９１７へ進み、統合結果を出力するとともに、統合された入力情報を統合したことを表すフラグをたてる。そして、ステップＳ９１９へ進む。
【００３０】
上記探索によって統合可能な入力情報が見つからなかった場合は、ステップＳ９１８へ進み、当該選択中の入力情報はそのまま保持し、次の入力情報を選択して（ステップＳ９１９、Ｓ９２０）、ステップＳ９１２からの処理を繰り返す。なお、ステップＳ９１９で未処理の入力情報がないと判定された場合は当該処理を終了する。
【００３１】
以下では、上記マルチモーダル入力統合処理の例を、図１０〜１９を用いて具体的に説明する。なお、各処理の説明において、括弧内に図９Ｂのステップ番号を示した。
【００３２】
図１０の例について説明する。上述のように、まず音声入力情報１００１とＧＵＩ入力情報１００２をタイムスタンプ順に並べ、タイムスタンプの早い入力情報から順に処理を行っていく（図１０では丸数字で順番を示した）。音声入力情報１００１においてデータのバインド先、意味属性、値は全て定まっている。このため、マルチモーダル入力統合処理部１０４は、単一入力としてデータのバインド先「／Ｔｏ」と値「恵比寿」を出力する（図１０：１００４）。また、同様に、ＧＵＩ入力情報１００２においてもデータのバインド先、意味属性、値が全て定まっているので、マルチモーダル入力統合処理部１０４は単一入力としてデータのバインド先「／Ｎｕｍ」と値「１」を出力する（図１０：１００３）。
【００３３】
次に図１１の例について説明する。音声入力情報１１０１とＧＵＩ入力情報１１０２をタイムスタンプ順に並べ、タイムスタンプの早い入力情報から順に処理を行っていくので、まず音声入力情報１１０１について処理される。音声入力情報１１０１では、値が「＠ｕｎｋｎｏｗｎ」であり、単一入力として処理することができず、統合処理が必要となる。統合対象として、音声入力情報１１０１以前のＧＵＩ入力情報の中で、同様に統合処理が必要な入力（この場合、バインド先が不定のもの）を探す。この場合は音声入力情報１１０１以前の入力がないので、情報を保持したまま、次のＧＵＩ入力情報１１０２に処理を移す。ＧＵＩ入力情報１１０２においては、データモデルが「−（バインドなし）」であり、単一入力として処理することができず、統合処理が必要となる（Ｓ９１２）。
【００３４】
図１１の場合、上記統合条件を満たす入力情報は音声入力情報１１０１であるので、ＧＵＩ入力情報１１０２と音声入力情報１１０１を統合対象とする（Ｓ９１５）。そして、上記２つの情報を統合して、データのバインド先「／Ｆｒｏｍ」、値「恵比寿」を出力する（図１１：１１０３）（Ｓ９１６）。
【００３５】
次に図１２の例について説明する。音声入力情報１２０１とＧＵＩ入力情報１２０２をタイムスタンプ順に並べ、タイムスタンプの早い入力情報から順に処理が行われる。音声入力情報１２０１においては、値が「＠ｕｎｋｎｏｗｎ」であり、上述のように単一入力として処理することができず、統合処理が必要となる。統合対象として、音声入力情報１２０１以前のＧＵＩ入力情報の中で、同様に統合処理が必要な入力を探す。この場合は音声入力情報１２０１以前の入力がないので、情報を保持したまま、次のＧＵＩ入力情報１２０２に処理を移す。ＧＵＩ入力情報１２０２においては、データモデルが「−（バインドなし）」であり、単一入力として処理することができず、統合処理が必要となる。統合対象として、ＧＵＩ入力情報１２０２以前の音声入力情報の中で、統合条件を満たす入力情報を探す（Ｓ９１２，Ｓ９１４）。この場合ＧＵＩ入力情報１２０２以前に入力された音声入力情報１２０１は意味属性が異なり、統合条件を満たしていないので統合処理は行わず、音声入力情報１２０１と同様に情報を保持したまま、次の処理へ移る（Ｓ９１４，Ｓ９１５−Ｓ９１８）。
【００３６】
次に図１３の例について説明する。音声入力情報１３０１とＧＵＩ入力情報１３０２をタイムスタンプ順に並べ、タイムスタンプの早い入力情報から順に処理が行われる。音声入力情報１３０１においては、値が「＠ｕｎｋｎｏｗｎ」であり、上述のように単一入力として処理することができず、統合処理が必要となる（Ｓ９１２）。統合対象として、音声入力情報１３０１以前のＧＵＩ入力情報の中で、同様に統合処理が必要な入力を探す（Ｓ９１４）。この場合は音声入力情報１３０１以前の入力がないので、情報を保持したまま、次のＧＵＩ入力情報１３０２に処理を移す。ＧＵＩ入力情報１３０２においては、データのバインド先、意味属性、値が全て定まっているので、単一入力としてデータのバインド先「／Ｎｕｍ」と値「１」を出力する（図１３：１３０３）（Ｓ９１２，９１３）。よって、音声入力情報１３０１は保持されたままである。
【００３７】
次に図１４の例について説明する。音声入力情報１４０１とＧＵＩ入力情報１４０２をタイムスタンプ順に並べ、タイムスタンプの早い入力情報から順に処理が行われる。音声入力情報１４０１は、データのバインド先（／Ｔｏ）、意味属性、値（恵比寿）が全て定まっているので、単一入力としてデータのバインド先「／Ｔｏ」と値「恵比寿」が出力される（図１４：１４０４）（Ｓ９１２，Ｓ９１３）。続いてＧＵＩ入力情報１４０２においても同様に、単一入力としてデータのバインド先「／Ｔｏ」と値「自由が丘」を出力する（図１４：１４０３）（Ｓ９１２，Ｓ９１３）。この結果、１４０３と１４０４でデータのバインド先「／Ｔｏ」が同じため、１４０４の値「恵比寿」を１４０３の値「自由が丘」で上書きすることになる。すなわち、１４０４の内容が出力されて、その後に１４０３の内容が出力されることになる。このような状態は、同じ時間帯に同一データを入力しようとしているのに、片方からは“恵比寿”、もう片方からは“自由が丘”という入力が入っており、一般的には「情報の競合」とみなされる。この場合どちらを選択するのかということが問題になる。時間的に近い入力がないか否かいちいち待ってから処理するという方法もあるが、そうすると処理結果が出るのに時間がかかるという問題があるため、本実施形態では、それを待たずに順次データを出力するという処理を行う。
【００３８】
次に図１５の例について説明する。音声入力情報１５０１とＧＵＩ入力情報１５０２をタイムスタンプ順に並べ、タイムスタンプの早い入力情報から順に処理を行っていく。この場合、上記２つの入力情報のタイムスタンプが同じであるので、このような場合は音声モダリティ、ＧＵＩモダリティの順に処理を行う。この順序についてはマルチモーダル入力統合部に届いた順に処理する、もしくはあらかじめブラウザに設定された入力モダリティの順に処理するようにしてもよい。この結果、音声入力情報１５０１は、データのバインド先、意味属性、値が全て定まっているので、単一入力としてデータのバインド先「／Ｔｏ」と値「恵比寿」が出力される（図１５：１５０４）。続いてＧＵＩ入力情報１５０２について処理されると、単一入力としてデータのバインド先「／Ｔｏ」と値「自由が丘」が出力される（図１５：１５０３）。この結果、１５０３と１５０４でデータのバインド先「／Ｔｏ」が同じため、１５０４の値「恵比寿」を１５０３の値「自由が丘」で上書きすることになる。
【００３９】
次に図１６の例について説明する。音声入力情報１６０１、１６０２とＧＵＩ入力情報１６０３、１６０４をタイムスタンプ順に並べ、タイムスタンプの早い入力情報から順に処理を行っていく（図１６では丸数字の１〜４で示してある）。音声入力情報１６０１においては、値が「＠ｕｎｋｎｏｗｎ」であり、単一入力として処理することができず、統合処理が必要となる（Ｓ９１２）。統合対象として、音声入力情報１６０１以前のＧＵＩ入力情報の中で、同様に統合処理が必要な入力を探す（Ｓ９１４）。この場合は音声入力情報１６０１以前のＧＵＩ入力がないので、情報を保持したまま、次のＧＵＩ入力情報１６０３に処理を移す（Ｓ９１５，Ｓ９１８−Ｓ９２０）。ＧＵＩ入力情報１６０３においては、データモデルが「−（バインドなし）」であり、単一入力として処理することができず、統合処理が必要となる（Ｓ９１２）。統合対象として、ＧＵＩ入力情報１６０３以前の音声入力情報の中で、統合条件を満たす入力情報を探す（Ｓ９１４）。図１６の場合、音声入力情報１６０１とＧＵＩ入力情報１６０３は上記統合条件を満たすので、ＧＵＩ入力情報１６０３と音声入力情報１６０１を統合する（Ｓ９１６）。これら２つの情報を統合した結果、データのバインド先「／Ｆｒｏｍ」、値「渋谷」が出力され（図１６：１６０６）（Ｓ９１７）、次の情報である音声入力情報１６０２に処理を移す（Ｓ９２０）。音声入力情報１６０２においては、値が「＠ｕｎｋｎｏｗｎ」であり、単一入力として処理することができず、統合処理が必要となる（Ｓ９１２）。統合対象として、音声入力情報１６０２以前のＧＵＩ入力情報の中で、同様に統合処理が必要な入力を探す（Ｓ９１４）。この場合、ＧＵＩ入力情報１６０３は既に処理済となっており、音声入力情報１６０２以前に統合処理が必要なＧＵＩ入力情報は存在しない。よって音声入力情報１６０２を保持したまま、次のＧＵＩ入力情報１６０４に処理を移す（Ｓ９１５，Ｓ９１８−Ｓ９２０）。ＧＵＩ入力情報１６０４においては、データモデルが「−（バインドなし）」であり、単一入力として処理することができず、統合処理が必要となる（Ｓ９１２）。統合対象として、ＧＵＩ入力情報１６０４以前の音声入力情報の中で、統合条件を満たす入力情報を探す（Ｓ９１４）。この場合上記統合条件を満たす入力情報は音声入力情報１６０２であるので、ＧＵＩ入力情報１６０４と音声入力情報１６０２を統合する。これら２つの情報が統合されて、データのバインド先「／Ｔｏ」、値「恵比寿」が出力される（図１６：１６０５）（Ｓ９１５−Ｓ９１７）。
【００４０】
次に図１７の例について説明する。音声入力情報１７０１、１７０２とＧＵＩ入力情報１７０３をタイムスタンプ順に並べ、タイムスタンプの早い入力情報から順に処理を行っていく。最初の入力情報である音声入力情報１７０１においては、値が「＠ｕｎｋｎｏｗｎ」であり、単一入力として処理することができず、統合処理が必要となる。統合対象として、音声入力情報１７０１以前のＧＵＩ入力情報の中で、同様に統合処理が必要な入力を探す（Ｓ９１２，Ｓ９１４）。この場合は音声入力情報１７０１以前のＧＵＩ入力がないので、これを保持したまま、次の入力情報である音声入力情報１７０２に処理を移す（Ｓ９１５，Ｓ９１８−Ｓ９２０）。音声入力情報１７０２においてはデータのバインド先、意味属性、値が全て定まっているので、単一入力としてデータのバインド先「／Ｔｏ」と値「恵比寿」が出力される（図１７：１７０４）（Ｓ９１２，Ｓ９１３）。
【００４１】
続いて、処理を次の入力情報であるところのＧＵＩ入力１７０３に移す。ＧＵＩ入力情報１７０３においては、データモデルが「−（バインドなし）」であり、単一入力として処理することができず、統合処理が必要となる。統合対象として、ＧＵＩ入力情報１７０３以前の音声入力情報の中で、統合条件を満たす入力情報を探す。この場合上記統合条件を満たす入力情報として音声入力情報１７０１が存在する。よって、ＧＵＩ入力情報１７０３と音声入力情報１７０１が統合され、その結果、データのバインド先「／Ｆｒｏｍ」、値「渋谷」が出力される（図１７：１７０５）（Ｓ９１５−Ｓ９１７）。
【００４２】
次に図１８の例について説明する。音声入力情報１８０１、１８０２とＧＵＩ入力情報１８０３、１８０４をタイムスタンプ順に並べ、タイムスタンプの早い入力情報から順に処理を行っていく。図１８の場合、入力情報１８０３、１８０１、１８０４、１８０２の順となる。
【００４３】
まず、最初のＧＵＩ入力情報１８０３においては、データモデルが「−（バインドなし）」であり、単一入力として処理することができず、統合処理が必要となる。統合対象として、ＧＵＩ入力情報１８０３以前の音声入力情報の中で、統合条件を満たす入力情報を探す。この場合はＧＵＩ入力情報１８０３以前の音声入力がないので、情報を保持したまま、次の入力情報であるところの音声入力情報１８０１に処理を移す（Ｓ９１２，Ｓ９１４，Ｓ９１５）。音声入力情報１８０１においては、値が「＠ｕｎｋｎｏｗｎ」であり、単一入力として処理することができず、統合処理が必要となる。統合対象として、音声入力情報１８０１以前のＧＵＩ入力情報の中で、同様に統合処理が必要な入力を探す（Ｓ９１２，Ｓ９１４）。この場合、音声入力情報１８０１以前に入力されたＧＵＩ入力情報１８０３が存在するものの、タイムアウト（タイムスタンプの差が３秒以上）となっており、統合条件を満たしていないので統合処理は行われない。この結果、音声入力情報１８０１を保持したまま、次のＧＵＩ入力情報１８０４に処理を移す（Ｓ９１５，Ｓ９１８−Ｓ９２０）。
【００４４】
ＧＵＩ入力情報１８０４においては、データモデルが「−（バインドなし）」であり、単一入力として処理することができず、統合処理が必要となる。統合対象として、ＧＵＩ入力情報１８０４以前の音声入力情報の中で、統合条件を満たす入力情報を探す（Ｓ９１２，Ｓ９１４）。この場合、音声入力情報１８０１が上記統合条件を満たすので、ＧＵＩ入力情報１８０４と音声入力情報１８０１を統合する。これら２つの情報を統合した結果、データのバインド先「／Ｆｒｏｍ」と、値「恵比寿」が出力される（図１８：１８０５）（Ｓ９１５−Ｓ９１７）。
【００４５】
その後、処理を音声入力情報１８０２に処理を移す。音声入力情報１８０２においては、値が「＠ｕｎｋｎｏｗｎ」であり、単一入力として処理することができず、統合処理が必要となる。統合対象として、音声入力情報１８０２以前のＧＵＩ入力情報の中で、同様に統合処理が必要な入力を探す（Ｓ９１２，Ｓ９１４）。この場合は音声入力情報１８０２以前に統合条件を満たすＧＵＩ入力情報がないので、情報を保持したまま、次の処理へ移る（Ｓ９１５，Ｓ９１８−Ｓ９２０）。
【００４６】
次に図１９の例について説明する。音声入力情報１９０１、１９０２とＧＵＩ入力情報１９０３をタイムスタンプ順に並べ、タイムスタンプの早い入力情報から順に処理を行っていく。図１９の例では、入力情報１９０１、１９０２、１９０３の順に情報が並ぶ。
【００４７】
音声入力情報１９０１においては、値が「＠ｕｎｋｎｏｗｎ」であり、単一入力として処理することができず、統合処理が必要となる。統合対象として、音声入力情報１９０１以前のＧＵＩ入力情報の中で、同様に統合処理が必要な入力を探す（Ｓ９１２，Ｓ９１４）。この場合音声入力情報１９０１以前に入力されたＧＵＩ入力情報はないので統合処理は行わず、情報を保持したまま、次の音声入力情報１９０２に処理を移す（Ｓ９１５，Ｓ９１８−Ｓ９２０）。音声入力１９０２においてはデータのバインド先、意味属性、値が全て定まっているので、単一入力としてデータのバインド先「／Ｎｕｍ」と値「２」が出力される（図１９：１９０４）（Ｓ９１２，Ｓ９１３）。続いて処理はＧＵＩ入力情報１９０３に移る（Ｓ９２０）。ＧＵＩ入力情報１９０３においては、データモデルが「−（バインドなし）」であり、単一入力として処理することができず、統合処理が必要となる。統合対象として、ＧＵＩ入力情報１９０３以前の音声入力情報の中で、統合条件を満たす入力情報を探す（Ｓ９１２，Ｓ９１４）。この場合、音声入力１９０１は間に意味属性の異なる入力情報１９０２をまたいでおり、上記統合条件を満たしていないので統合処理は行わず、情報を保持したまま、次の処理に移ることになる（Ｓ９１５，Ｓ９１８−Ｓ９２０）。
【００４８】
以上のように、タイムスタンプと意味属性に基づいて統合処理を行うことで、各入力モダリティからの入力情報を正しく統合することができるようになる。このことにより、アプリケーション開発者は統合すべき入力の意味属性を共通にしておくことで、その意図をアプリケーションに反映することができる。
【００４９】
以上、第１実施形態によれば、ＸＭＬ文書や音声認識のためのグラマ（文法規則）に意味属性を記述することができ、システムにアプリケーション開発者の意図をより反映させることができる。更に、マルチモーダル・ユーザインタフェースを備えるシステムにおいて上記意味属性情報を利用することで、マルチモーダル入力を効率よく統合することができる。
【００５０】
［第２実施形態］
続いて、本発明に係る情報処理システムの第２実施形態について説明する。前述した第１実施形態では、一つの入力情報（ＧＵＩ部品や入力音声）に対して意味属性を１つ指定する例を示した。第２実施形態では、さらに、複数の意味属性を指定可能とする例について説明する。
【００５１】
図２０は、第２実施形態に係る情報処理システムにおいてＧＵＩにおける各部品を提示するためのＸＨＴＭＬ文書の例を示す図である。図２０における〈ｉｎｐｕｔ〉タグやｔｙｐｅ属性、ｖａｌｕｅ属性、ｒｅｆ属性、ｃｌａｓｓ属性については第１実施形態における図３と同様の記述方式で記述されている。但し、ｃｌａｓｓ属性で意味属性を複数記述している点が異なる。例えば値「東京」を持つボタンは、ｃｌａｓｓ属性に「ｓｔａｔｉｏｎ  ａｒｅａ」が記述されている。これを解釈するマークアップ解釈部１０６ではホワイトスペース文字を区切りとした２つの意味属性「ｓｔａｔｉｏｎ」「ａｒｅａ」として解釈を行う。すなわち、第２実施形態では、スペースで区切ることにより複数の意味属性を記述することが可能となっている。
【００５２】
また、図２１は、音声を認識するためのグラマ（文法規則）を示す図である。図２１は、図７と同様の記述方式で記述されており、「ここの天気は」や「東京の天気は」といった音声入力を認識し、ａｒｅａ＝“＠ｕｎｋｎｏｗｎ”のような解釈を出力するルールを記述したグラマである。また、図２１に示すグラマ（文法規則）と上述の図７に示すグラマ（文法規則）の両方を用いた場合の解釈結果の例を図２２に示す。例えばネットワークに接続された音声処理装置を利用した場合には同図のようなＸＭＬ文書で解釈結果を得る。図２２は図７と同様の記述方式で記述されている。図２２によれば、「ココノテンキハ」の確信度が８０、「ココカラ」の確信度が２０となっている。
【００５３】
次に、意味属性を複数持つ入力情報を統合する場合の処理方法について図２３を例に説明する。図２３において、ＧＵＩ入力情報２３０１の「ＤａｔａＭｏｄｅｌ」はデータのバインド先、「ｖａｌｕｅ」は値、「ｍｅａｎｉｎｇ」は意味属性、「ｒａｔｉｏ」は各意味属性の確信度、「ｃ」は値の確信度である。上記「ＤａｔａＭｏｄｅｌ」、「ｖａｌｕｅ」、「ｍｅａｎｉｎｇ」、「ｒａｔｉｏ」は図２０に示すＸＭＬ文書をマークアップ解釈部１０６で解釈することにより得られる。なお、この中の「ｒａｔｉｏ」については、ｍｅａｎｉｎｇ属性（或いはｃｌａｓｓ属性）の中で明記されていない場合、１を意味属性の個数で割った値とする（従って、東京についてはｓｔａｔｉｏｎ及びａｒｅａのそれぞれが０．５となる。また「ｃ」は値の確信度であり、この値は入力された時点でアプリケーションが算出する値である。例えばＧＵＩ入力情報２３０１では値が東京である確率が９０％、神奈川である確率が１０％のポイントを指定された場合（例えば地図上のポイントをペンで円を描いて指定したときに、その円が東京を９０％、神奈川を１０％含む場合）の確信度である。
【００５４】
また、図２３において音声入力情報２３０２の「ｃ」は値の確信度であり、この確信度には認識候補ごとの正規化尤度（認識スコア）を利用する。音声入力情報２３０２では「ココノテンキハ」の正規化尤度（認識スコア）が８０、「ココカラ」の正規化尤度（認識スコア）が２０のときの例を示している。また図２３ではタイムスタンプは記してないが、タイムスタンプの情報は第１実施形態と同様に利用される。
【００５５】
第２実施形態による統合条件は、
（１）統合処理が必要であること、
（２）タイムリミット内（例えばタイムスタンプの差が３秒以内）であること、
（３）意味属性が少なくとも１つ一致していること、
（４）タイムスタンプ順に並べたときに１つも一致しない意味属性を持つ入力情報をまたいでいないこと、
（５）「バインド先」と「値」が相補的な関係にあること、
（６）（１）〜（４）の条件を満足する入力情報の中で最も早く入力された情報であることである。なお、上記統合条件は一例であり、他の条件を設定してもかまわない。また、例えば上記統合条件の一部のみを統合条件として用いる（例えば条件（１）と（３）のみを統合条件とする）ようにしてもよい。また、本実施形態においても、異なるモダリティの入力を統合するものとし、同じモダリティの入力同士は統合しないものとする。
【００５６】
次に、図２３を用いて第２実施形態の統合処理を説明する。ＧＵＩ入力情報２３０１は、図２３における値の確信度「ｃ」と意味属性の確信度「ｒａｔｉｏ」を掛けた値を確信度「ｃｃ」としてＧＵＩ入力情報２３０３とする。同様に、音声入力情報２３０２は、図２３における値の確信度「ｃ」と意味属性の確信度「ｒａｔｉｏ」を掛けた値を確信度「ｃｃ」として音声入力情報２３０４とする（図２３では、音声認識結果について１つの意味属性しかないので「１」となっているが、例えば「東京」という音声認識結果が得られた場合は、意味属性としてｓｔａｔｉｏｎとａｒｅａが存在し、それぞれの確信度が０．５というようになる）。各音声入力情報の統合の方法は第１実施形態と同様であるが、一つの入力情報に複数の意味属性や複数の値が存在するので、ステップＳ９１６では、図２３の２３０５に示されるように統合候補が複数に及ぶ可能性がある。
【００５７】
続いて、ＧＵＩ入力情報２３０３と音声入力情報２３０４において、各入力情報の意味属性が一致するものに対して各確信度を掛けた値を確信度「ｃｃｃ」として入力情報２３０５とする。上記入力情報２３０５において最も確信度（ｃｃｃ）の高いものを選択し、選択されたデータ（本例ではｃｃｃ＝３６００のデータ）のバインド先「／Ａｒｅａ」と値「東京」を出力する（図２３：２３０６）。確信度が同一であった場合は先に処理した方を優先する。
【００５８】
次に、意味属性の確信度（ｒａｔｉｏ）をマークアップ言語で記述する例を示す。図２４では図２２と同様にｃｌａｓｓ属性で意味属性を指定するが、意味属性にコロン（：）と確信度を付記しており、同図では「東京」と値を持つボタンに対して意味属性が「ｓｔａｔｉｏｎ」と「ａｒｅａ」であり、意味属性ｓｔａｔｉｏｎの確信度が「５５」、意味属性ａｒｅａの確信度が「４５」であることを示している。マークアップ解釈部１０６（ＸＭＬパーサ）にて上記意味属性と確信度は分離して解釈され、上記意味属性の確信度は図２５のＧＵＩ入力情報２５０１における「ｒａｔｉｏ」として出力される。図２５においては図２３と同様の処理を行い、データのバインド先「／Ａｒｅａ」と値「東京」を出力する（図２５：２５０６）。
【００５９】
尚、本実施形態では簡便のため、音声認識のためのグラマ（文法規則）に意味属性を１つしか記述しなかったが、図２６のように例えばＬｉｓｔ型を使う等の方法で意味属性を複数指定してもよい。図２６では「ココ」という入力に対して値が「＠ｕｎｋｎｏｗｎ」、意味属性が「ａｒｅａ」と「ｃｏｕｎｔｒｙ」、意味属性ａｒｅａの確信度が「９０」、意味属性ｃｏｕｎｔｒｙの確信度が「１０」であることを示している。
【００６０】
また、図２５、図２６で示した統合処理の例ではマークアップで記述された確信度に基づいた処理を示したが、複数の意味属性をもつ入力情報のうち、一致する意味属性の数から確信度を算出し、その確信度が最も高いものを選択するようにしてもよい。例えば、３つの意味属性Ａ、Ｂ、ＣをもつＧＵＩ入力情報と、３つの意味属性Ａ、Ｄ、ＥをもつＧＵＩ入力情報と、４つの意味属性Ａ、Ｂ、Ｃ、Ｄをもつ音声入力情報が統合対象である場合、意味属性Ａ、Ｂ、ＣをもつＧＵＩ入力情報と意味属性Ａ、Ｂ、Ｃ、Ｄをもつ音声入力情報で共通する意味属性の数は３である。また、意味属性Ａ、Ｄ、ＥをもつＧＵＩ入力情報と、意味属性Ａ、Ｂ、Ｃ、Ｄをもつ音声入力情報で共通する意味属性の数は２である。従ってこの場合、共通する意味属性の数を確信度とし、確信度の高い意味属性Ａ、Ｂ、ＣをもつＧＵＩ入力情報と意味属性Ａ、Ｂ、Ｃ、Ｄをもつ音声入力情報を統合し、出力する。
【００６１】
以上、第２実施形態によれば、ＸＭＬ文書や音声認識のためのグラマ（文法規則）に複数の意味属性を記述することができ、システムにアプリケーション開発者の意図をより反映させることができる。更に、マルチモーダル・ユーザインタフェースを備えるシステムにおいて上記意味属性情報を利用することで、マルチモーダル入力を効率よく統合することができる。
【００６２】
以上説明したように、上記各実施形態によれば、ＸＭＬ文書や音声認識のためのグラマ（文法規則）に意味属性を記述することができ、システムにアプリケーション開発者の意図をより反映させることができる。更に、マルチモーダル・ユーザインタフェースを備えるシステムにおいて上記意味属性情報を利用することで、マルチモーダル入力を効率よく統合することができる。
【００６３】
なお、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【００６４】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００６５】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。
【００６６】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００６７】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００６８】
【発明の効果】
以上説明したように、本発明によれば、複数種類の入力様式からの入力を処理するための記述に意味属性の記述を導入したので、簡易な解析処理でユーザ或いは設計者が意図したとおりの入力の統合を実現させることができる。
また、本発明によれば、各入力がもつ意味属性を、アプリケーション開発者がマークアップ言語等を用いて記述できる。
【図面の簡単な説明】
【図１】第１実施形態における情報処理システムの基本構成を示す図である。
【図２】第１実施形態に係るマークアップ言語による意味属性の記述例を示す図である。
【図３】第１実施形態に係るマークアップ言語による意味属性の記述例を示す図である。
【図４】第１実施形態に係る情報処理システムにおけるＧＵＩ入力処理部の処理の流れを説明するためのフローチャートである。
【図５】第１実施形態に係る音声認識のためのグラマ（文法規則）の記述例を示す図である。
【図６】第１実施形態に係る音声認識のためのグラマ（文法規則）のマークアップ言語による記述例を示す図である。
【図７】第１実施形態に係る音声認識・解釈結果の記述例を示す図である。
【図８】第１実施形態に係る情報処理システムにおける音声認識・解釈処理部１０３の処理の流れを説明するためのフローチャートである。
【図９Ａ】第１実施形態に係る情報処理システムにおけるマルチモーダル入力統合部１０４の処理の流れを説明するためのフローチャートである。
【図９Ｂ】図９ＡのステップＳ９０３を詳細に示すフローチャートである。
【図１０】第１実施形態に係るマルチモーダル入力統合の例を示す図である。
【図１１】第１実施形態に係るマルチモーダル入力統合の例を示す図である。
【図１２】第１実施形態に係るマルチモーダル入力統合の例を示す図である。
【図１３】第１実施形態に係るマルチモーダル入力統合の例を示す図である。
【図１４】第１実施形態に係るマルチモーダル入力統合の例を示す図である。
【図１５】第１実施形態に係るマルチモーダル入力統合の例を示す図である。
【図１６】第１実施形態に係るマルチモーダル入力統合の例を示す図である。
【図１７】第１実施形態に係るマルチモーダル入力統合の例を示す図である。
【図１８】第１実施形態に係るマルチモーダル入力統合の例を示す図である。
【図１９】第１実施形態に係るマルチモーダル入力統合の例を示す図である。
【図２０】第２実施形態に係るマークアップ言語による意味属性の記述例を示す図である。
【図２１】第２実施形態に係る音声認識のためのグラマ（文法規則）のマークアップ言語による記述例を示す図である。
【図２２】第２実施形態に係る音声認識・解釈結果の記述例を示す図である。
【図２３】第２実施形態に係るマルチモーダル入力統合の例を示す図である。
【図２４】第２実施形態に係るマークアップ言語による、ｒａｔｉｏを含む意味属性の記述例を示す図である。
【図２５】第２実施形態に係るマルチモーダル入力統合の例を示す図である。
【図２６】第２実施形態に係る音声認識のためのグラマ（文法規則）の、マークアップ言語による記述例を示す図である。
【図１】
2004362052.tif 000003
【図２】
2004362052.tif 000004
【図３】
2004362052.tif 000005
【図４】
2004362052.tif 000006
【図５】
2004362052.tif 000007
【図６】
2004362052.tif 000008
【図７】
2004362052.tif 000009
【図８】
2004362052.tif 000010
【図９Ａ】
2004362052.tif 000011
【図９Ｂ】
2004362052.tif 000012
【図１０】
2004362052.tif 000013
【図１１】
2004362052.tif 000014
【図１２】
2004362052.tif 000015
【図１３】
2004362052.tif 000016
【図１４】
2004362052.tif 000017
【図１５】
2004362052.tif 000018
【図１６】
2004362052.tif 000019
【図１７】
2004362052.tif 000020
【図１８】
2004362052.tif 000021
【図１９】
2004362052.tif 000022
【図２０】
2004362052.tif 000023
【図２１】
2004362052.tif 000024
【図２２】
2004362052.tif 000025
【図２３】
2004362052.tif 000026
【図２４】
2004362052.tif 000027
【図２５】
2004362052.tif 000028
【図２６】
2004362052.tif 000029