JP2007220129A - ユーザインタフェース設計装置およびその制御方法 - Google Patents

Abstract

【課題】 オーサの入力に係る負担が軽減されたユーザインタフェース設計装置の提供。
【解決手段】 意味構造生成規則が記述された音声認識文法が取り込まれると（Ｓ２０１）、そこに含まれる意味構造生成規則から少なくとも１つの意味構造を抽出し（Ｓ２０２）、これをオーサに提示する（Ｓ２０３）。オーサは入力装置用いて提示された意味構造を選択することができる。オーサの選択が終わりしだい、その選択情報が取り込まれ（Ｓ２０４）、ユーザインタフェースコンテンツに反映される（Ｓ２０５）。
【選択図】 図２

Description

本発明は、パタン認識機能を提供するアプリケーションのユーザインタフェースを設計するためのユーザインタフェース設計装置およびその制御方法に関する。

現在、VoiceXML（http://www.w3.org/TR/voicexml20/ を参照。）、 SALT（http://www.saltforum.org/ を参照。）、XHTML+Voice（http://www.w3.org/TR/xhtml+voice/ を参照。）という音声ユーザインタフェース（以下「音声ＵＩ」という。）を記述するためのマークアップ言語仕様が存在する。この仕様に沿って書かれたコンテンツは、対応するブラウザに読み込ませることで、ユーザと機器（あるいはサービス）間で音声ＵＩを実現することが可能である。

これらの音声ＵＩコンテンツは、オーサ（コンテンツ作成者）が専用のオーサリングツールを使って作成することが一般的である（例えば、特許文献１、２を参照。）。

音声ＵＩを実現するためには、ユーザの音声を認識する音声認識技術が必要である。音声認識とは、音響モデルと呼ばれる人間の音声の音響的統計量を用い、指定された言語制約を満たす語連鎖の中で、もっとも発声と近い語連鎖を選択する処理である。この言語制約は音声認識文法と呼ばれている。

“Yes”または“No”を認識するといった一般的な音声認識文法は、既存の文法を用いることが可能である。しかし、その他のアプリケーションに特化した文法は、オーサが自分で作成する必要がある。そのような音声認識文法についてはW3Cで標準化が進められており、現在は、“Speech Recognition Grammar Specification Version 1.0”(以下「ＳＲＧＳ」という。）として勧告されている。ＳＲＧＳの仕様は、http://www.w3.org/TR/speech-grammar/ に公開されている。図３および図４は、このＳＲＧＳで記述された音声認識文法の記述例である。

また、“Semantic Interpretation for Speech Recognition”(以下「ＳＩＳＲ」という。）という仕様についても標準化が進められている。これは、音声認識結果の意味構造を規定するための仕様である。これを用いることで、音声認識の結果として、その発声に含まれる意味情報を取り出すことが可能になる。図３の３０２はＳＩＳＲの意味構造生成規則の一例である。このように意味構造生成規則は、ＳＲＧＳ中の＜tag＞〜＜/tag＞内、あるいは"tag"属性内に記述される。なお、ＳＩＳＲの仕様は、http://www.w3.org/TR/semantic-interpretation/ に公開されている。

例えば、図３、図４の音声認識文法を用いた音声認識処理で、“I would like a coca cola and three large pizzas with pepperoni and mushrooms.”という発声を行った場合を考える。すると、図５のような構造化されたデータが生成される。本明細書では、このような構造化されたデータ構造（５０１）を「意味構造」と呼び、その構造を構成する各データ（５０２）を「意味構造部品」と呼ぶ。一般的に、認識結果を受け取るアプリケーションは、“I would like a coca cola and three large pizzas with pepperoni and mushrooms.”という文字列を認識結果として受け取るよりも、このような意味構造を受け取った方が利用しやすい。

特許第０３２７９６８４号公報 特開平０９−１１４６２３号公報

図６Ａは、音声認識アプリケーションの画面例で、データ入力前の場面を示している。このアプリケーションはピザの注文を、音声またはＧＵＩ入力により行うものである。ユーザは、ＧＵＩ入力により各フォームを埋めてもよいし、６０２のような音声入力ボタンをクリックした後、“I would like a coca cola and three large pizzas with pepperoni and mushrooms.”といった発声を行うこともできる。上記の発声を行った場合、図６Ｂに示すように各フォームにデータが自動的に埋まる。

このような音声ＵＩを作成するには、ＵＩオーサリングツールを用いて生成するのが一般的である。図７はＵＩオーサリングツールの画面例を示している。一般的なＵＩオーサリングツールは、７０２のようなフォームパレットと７０３のような編集中のＧＵＩ画面が見えているものが多い。アプリケーションのオーサは、フォームパレットから所望のフォームコントロールをＵＩ画面上にドラッグ＆ドロップすることで、ＧＵＩ画面を生成していく。

ユーザ発声後、ユーザ発声に応じて図６Ｂの６０３のように各フォームコントロールの値が更新されるためには、各フォームと音声認識結果の意味構造部品とを結び付ける作業が必要である。例えば、ピザの枚数が格納される７０４のフォームには、音声認識結果の意味構造中の５０２のデータ（ピザの枚数）との結びつけを行わなければならない。このように、各フォームやオブジェクトを音声認識結果の意味構造部品との結びつけを行う場合、最も単純な実装は図８のようなＵＩである。つまり、８０１のような意味構造バインドダイアログをオーサに提示し、音声認識文法名（８０２）、音声認識により生成される特定の意味構造部品へのパス（８０３）をテキスト入力により行わせる。ここでは、このような意味構造部品へのパスを「意味構造パス」と呼ぶ。意味構造パスの表記中の“/”は親子関係を表している。したがって“/pizza/number”は、“pizza”要素の子の“number”要素を表しており、つまり５０２のデータを示している。

図８のように、オーサに音声認識結果の意味構造パスをテキスト入力させれば、各フォームコントロール（またはオブジェクト）と音声認識結果の意味構造部品との結びつきを設定することは可能である。

しかし、このようなテキスト入力はオーサの負担となる。そのため、このようなオーサの負担の軽減が望まれている。

本発明の一側面に係るユーザインタフェース制御装置は例えば、以下の構成を有する。すなわち、パタン認識機能を提供するアプリケーションのユーザインタフェースコンテンツを生成するユーザインタフェース設計装置であって、前記パタン認識の結果の意味構造を生成するための、意味構造を構成する意味構造部品を含む意味構造生成規則が記述された認識文法を取り込む認識文法取り込み手段と、オーサが入力装置を介して入力した、意味構造部品の位置を特定するための意味構造パスを取り込む意味構造パス取得手段と、前記認識文法に従い生成され得る意味構造に、前記意味構造パスに適合するものが存在するか確認する意味構造パス確認手段と、前記意味構造パス確認手段による確認が得られなかった場合、オーサに対しエラー情報を出力するエラー情報出力手段とを有する。

本発明のユーザインタフェース制御装置によれば、オーサの入力に係る負担を軽減させることができる。

以下、図面を参照して本発明の好適な実施形態について詳細に説明する。

図１Ａは、本発明のユーザインタフェース設計装置の機能を実現するコンピュータシステムのハードウェア構成例を示す図である。なお、以下の説明では「ユーザインタフェース」を「ＵＩ」ともいう。

図示のコンピュータシステムは、装置全体の制御をつかさどるＣＰＵ１、ブートプログラムや固定的なデータ等を記憶しているＲＯＭ２、主記憶装置として機能するＲＡＭ３をはじめ、以下の構成を備える。

ＨＤＤ４はハードディスク装置であって、ここにＯＳ１０のほか、ＵＩ設計プログラム１１、音声認識文法１１２、ＵＩ設計プログラム１１の実行によって構築されるＵＩコンテンツ１１１が格納される。

また、ＶＲＡＭ５は表示しようとするイメージデータを展開するメモリであり、ここにイメージデータ等を展開することで画面出力装置の一例としてのＣＲＴ６に表示させることができる。７および８はそれぞれ、入力装置としてのキーボードおよびマウスで、ＣＰＵ１に割り込み信号を伝えるキーボードコントローラ７ａおよびマウスコントローラ８ｂに接続されている。

ＵＩ設計プログラム１１は、キーボード７あるいはマウス８からの特定の指示イベントに応じて起動される。その際に、ＵＩ設計プログラム１１はＲＡＭ３にロードされ、ＣＰＵ１によって実行される。これによってこのコンピュータシステムはＵＩ設計装置として機能することになる。

図１Ｂは、本実施形態におけるＵＩ設計装置の機能構成図である。

ＵＩ設計装置１０１は、キーボード７やマウス８を含む入力装置１０５および、ＣＲＴ６で構成される画面出力装置１０８を介し、オーサが所望するＵＩコンテンツ１１１を生成する。

ここでは一例として、図６Ａのようなピザの注文を行うアプリケーションのＵＩコンテンツを生成することを想定して説明する。このＵＩはＧＵＩによるフォームコントロールでデータを入力することができる。また、６０２の音声入力ボタンを押し、“I would like a coca cola and three large pizzas with pepperoni and mushrooms.”のような発声を行うことで、図６Ｂのように各フォームを一挙に埋めることが可能である。

本ＵＩ設計装置のＵＩ画面は図７のようになっている。これは基本的にはオーサからのコマンド入力に応じて動作を行うメッセージドリブンのアプリケーションである。例えばファイルのセーブや、オーサリングツールの終了コマンドが入力されると、それに応じた動作を行う。

音声認識結果としてピザの枚数が入力された場合に、６０４（図６Ａ）のフォーム１の値をその音声認識結果の値に反映させるＵＩを作成する場合を考える。この場合、ＧＵＩのフォームコントロールや、他のオブジェクトと音声認識結果の意味構造を結び付ける必要がある。ここでは、この意味構造との結び付け作業を“意味構造指定モード”と呼ぶ。この“意味構造指定モード”は、本装置の特徴的な動作である。

オーサは、図７の画面のフォーム１（７０４）を例えば右クリックし、コンテキストメニューから“音声認識結果とのバインド”を選択する。すると、“意味構造指定モード”に入る。“意味構造指定モード”ではまず、図９Ａの９０１のような音声認識文法選択ダイアログが現れ、オーサが所望する音声認識文法名を入力する。なお、他の画面で既に音声認識文法が指定されている場合は、このダイアログ表示は省略してもよい。

図２は、本実施形態に係るＵＩ設計装置の意味構造指定モードにおける処理を示すフローチャートである。

上記のとおり音声認識文法選択ダイアログ９０１に音声認識文法名が入力されると、音声認識文法取り込み部１１０（図１を参照）は、指定した音声認識文法１１２を取り込む（ステップＳ２０１）。ここでは、取り込まれた音声認識文法は、図３〜図４に示したものとして説明する。取り込まれる音声認識文法には、発声内容の意味構造を生成するための意味構造生成規則３０２が記述されていることを前提とする。

取り込まれた音声認識文法は、意味構造抽出部１０６に送られる。意味構造抽出部１０６は、取り込まれた音声認識文法を解析し、そこに含まれる意味構造生成規則から少なくとも１つの意味構造を抽出する（ステップＳ２０２）。

例えば、音声認識文法に含まれる全意味構造生成規則中の全プロパティを探し出し、そのリストを抽出することが考えられる。プロパティとは、意味構造生成規則中の左辺に現れる識別子である。この意味構造生成規則のプロパティに関しては、http://www.w3.org/TR/semantic-interpretation/ に詳しい説明が公開されている。

ちなみに、図３〜図４の文法における全プロパティのリストは次の通りである。
［drink、drinksize、liquid、number、pizza、pizzasize、topping、type］

抽出された意味構造は、意味構造提示部１０７に送られ、ここから画面出力装置１０８を介してオーサに提示される（ステップＳ２０３）。例えば、図９Ｂに示すような意味構造パス生成ダイアログ９０２が表示される。オーサは、このダイアログ９０２を見ながら入力装置１０５を操作し、特定の意味構造パスを指定することができる。具体的には、オーサは、リストボックス９０３からプロパティを選択し、所望の意味構造パスを構築する。なお、パスの長さを伸ばしたり縮めたりすることは、９０４のようなパス長さ編集ボタンを用いて行う。

オーサの選択が終わり、“OK”ボタンが押下されると、オーサ入力情報取り込み部１０４はオーサの入力情報（選択情報）を取り込む（ステップＳ２０４）。取り込んだ情報は意味構造パス生成部１０３に送られる。ここでは、オーサが選択した各プロパティ名とその関係から特定の意味構造パスが生成される（ステップＳ２０５）。先の例では、“/pizza/number”という文字列が生成される。このようにオーサはリストボックス９０３からの選択動作を行うだけで、意味構造パスを生成することができる。このとき、オーサは従来のように意味構造部品を特定するテキスト等を入力する必要はない。これにより、オーサの入力に係る負担が軽減される。

この結果はＵＩコンテンツ構築部１０２に送られ、VoiceXMLやＳＡＬＴ、XHTML+Voiceといったマークアップ言語で表現されたＵＩコンテンツに反映される。生成されたＵＩコンテンツはＵＩコンテンツ出力部１０９に送られ、ここから外部のＵＩコンテンツファイル１１１に出力される。

（変形例１）
上述の実施形態では、意味構造生成規則中のプロパティをオーサに提示し、オーサにその中から組み合わせを選択させることにより特定の意味構造パスを生成した。しかしこの方法だと、パスを構成する語彙は正しいものの、その順序が間違ったものをオーサが指定する可能性がある。例えば、図５の意味構造において、“/number/pizza”というこの文法からは生成され得ない意味構造パスが指定される場合がある。これを回避するために、音声認識文法から文法に準拠した仮想の入力情報としての発声情報を自動生成し、その発声が入力された場合の意味構造をオーサに提示するようにしてもよい。以下ではそのような処理を導入した例を変形例１として説明する。

図１０は、この変形例１に係るＵＩ設計処理を示すフローチャートである。

オーサが、図７の画面のフォーム１（７０４）を右クリックし、コンテキストメニューから“音声認識結果とのバインド”を選択すると、この図１０のフローが開始する。このフローに入ると、まず、図１２Ａに示すような音声認識文法指定ダイアログ１２０１を表示し、ここでオーサにより入力された音声認識文法名を取得する（ステップＳ１００１）。なお、既に音声認識文法が指定されている場合には、この部分は省略することが可能である。

次に、内部変数Nを１で初期化し（ステップＳ１００２）、取り込まれた音声認識文法から、発声例を一つ生成する（ステップＳ１００４）。文法から発声例を生成するには、例えば図１１に示すようなアルゴリズムが考えられる。

まず、“Generate”というルーチンを、文法のルートルール名を引数にして呼び出す（00行目）。Generate ルーチン内では、内部変数list をクリアし（0２行目）、入力されたルール名からその右辺を展開する。展開された右辺は、token ごとに切り出され、Tokenリストに格納される（03行目）。

切り出された全Token は、次のチェックを行う。まず、＜ruleref＞のような、他のルールへの参照であるかを調べる。そうであった場合、そのルール名を引数に、Generate ルーチンを再帰的に呼び出す。その結果はlist変数に追加される（06行目）。次に、Tokenが＜one-of＞のような選択要素であるかどうかを調べる。もしそうであった場合、その選択要素を引数に、後述するSelectサブルーチンを呼び出す。その結果はlist変数に追加される（09行目）。他のルールへの参照でも選択要素でもなかった場合、このTokenは終端記号（発声単語）であるとみなし、そのTokenをそのままlist に追加する（12行目）。これらの操作は切り出された全Tokenに対して行い、最後にlist 変数を返す（15行目）。

Select サブルーチンでは、まず内部変数listを初期化する（21行目）。次に、入力された選択要素のうち、＜item＞で指定された選択項目を１つ選択する（22行目）。 この選択方式は、最初に現れた選択項目を選択してもよいし、＜item＞のうちのどれか１つをランダムで選択してもよい。選択された選択項目は、Generate ルーチン同様のチェックを行う（23〜31行目）。チェックが終ると、list変数を返す。

このようなアルゴリズムを実行することで、音声認識文法で受理される発声例のテキスト情報を抽出することが可能である。ただし、このアルゴリズムでは、発声の繰り返しを指定する文法記述には対応できない。また、ルールの再帰を含む文法記述では無限ループに陥ってしまうため、これら一般的な音声認識文法に対応するには、上記アルゴリズムを改良する必要がある。

これらのアルゴリズムで新しい発声例のテキスト情報が作成できた場合（ステップＳ１００５，Ｎｏ）、生成した発声例から意味構造を生成する（ステップＳ１００６）。具体的には、音声認識文法を用いて発声例テキストを構文解析する。そして、その経路上の意味情報生成規則を実行することで、意味構造を生成することが可能である。なお、意味構造生成に関してはhttp://www.w3.org/TR/semantic-interpretation/ に説明がある。

その後、生成された意味構造は既にリストに登録されたものと同じであるかどうかを確認し（ステップＳ１００７）、未登録である場合にはリストに登録し（ステップＳ１００８）、内部変数Nを１増分する（ステップＳ１００９）。

上記したステップＳ１００４〜Ｓ１００９の処理は、変数Nの数が所定数M（例えば、３）になるまで、なおかつ、音声認識文法から新しい発声例が作成できる間、繰り返される。これらの条件を満たさなくなると、このループを抜け、例えば図１２Ｂに示すような意味構造概形選択ダイアログ１２０２において、リスト内のデータをオーサに提示する（ステップＳ１０１０）。同図の画面内には、音声認識文法から自動で生成された意味構造の全体像が最大M個表示される。オーサはこの中から意味構造を選択することができる。この選択情報が取り込まれると（ステップＳ１０１１）、その選択された意味構造の内部構造を展開し、意味構造部品を選択できるような画面を提示する（ステップＳ１０１２）。図１２Ｃにそのときに表示されるダイアログ１２０３の例を示す。オーサはここからマウス等を用いて意味構造部品を選択することができる。この選択された意味構造部品が取り込まれると（ステップＳ１０１３）、オーサにより選択された位置のパスを作成し、ＵＩコンテンツに反映させる（ステップＳ１０１４）。

なお、この例では装置が提示する意味構造は最大M個に限定している。このため、オーサが意図する意味構造が提示されない可能性がある。この場合、図１２Ｂの１２０４のようなボタンを用意し、そのボタンが押された際は、その他のパス指定方法に切り換えてもよい。例えば、図９Ｂに示したようなダイアログ９０２を提示するようにしてもよい。

（変形例２）
上述の変形例１では、音声認識文法から発声例を自動で作成するものであった。ただしこの方法の場合、装置が提示するM個の意味構造の中にオーサが意図する意味構造が含まれない可能性がある。これに対処するためにMを大きくすることも可能である。しかし、Mが大きくなるとオーサの意図する意味構造を探す負担が大きくなるという問題が生じる。そこで、この変形例２では、音声認識文法とその中に書かれた発声例情報を用いて意味構造を生成し、オーサに提示する。

図１３はＳＲＧＳで書かれた音声認識文法の例を示している。ＳＲＧＳでは、発声の例文を記述する＜example＞というタグが用意されており、この内部に書かれた例文を発声例情報とすることができる。図中１３０１が発声例情報の例である。

このときの処理の流れは、図１０に示したフローとはぼ同じであるため、詳しい説明は省略する。ただし、ステップＳ１００４の処理は変形例１と異なる。上述の変形例１では、ここで音声認識文法から発声例を１つ自動的に生成したが、本変形例２では、音声認識文法中に記述された発声例テキストを利用すればよい。

また、音声認識文法中に、その文法で生成されうる意味構造情報を記述しておいてもよい。図１４は、文法で生成され得る意味構造情報を文法中に記述した例である。これはＳＲＧＳのコメント欄に、意味構造情報を入れている。これを用いると、意味構造を生成する処理（ステップＳ１００６）が必要なくなるという利点もある。

（変形例３）
上述の変形例２は、音声認識文法作成時に発声例を入力するものであったが、オーサリングツール使用時に発声例を入力させることも有効である。かかる処理を実現するＵＩ設計処理のフローチャートを、図１５に示す。

オーサが、図７の画面のフォーム１（７０４）を右クリックし、コンテキストメニューから“音声認識結果とのバインド”を選択すると、この図１５のフローが開始する。このフローに入ると、まず、図１６Ａに示すような音声認識文法指定ダイアログ１６０１を表示し、ここでオーサにより入力された音声認識文法名を取得する（ステップＳ１５０１）。この音声認識文法指定ダイアログ１６０１には、音声認識ボタン１６０３も用意されている。この音声認識ボタン１６０３が押されると、オーサの発声を取り込み（ステップＳ１５０２）、ステップＳ１５０１で取り込んだ音声認識文法を用いて音声認識処理を実行する（ステップＳ１５０３）。

音声認識が終了すると、音声認識結果から意味構造を生成し（ステップＳ１５０４）、その意味構造を展開してオーサに提示する（ステップＳ１５０５）。ここでは例えば、図１６Ｂに示すような意味構造パス指定ダイアログ１６０４が表示される。図示のように、オーサの発声内容の意味構造が、値（numberが“３”等）を伴って提示される。オーサはこの画面から、特定の意味構造部品を入力装置１０５を用いて選択する。例えば、pizza の number を指定したい場合は、pizza の下の number という部分をクリックする。特定の意味構造部品の指定が行われると、その情報は装置内部に取り込まれる（ステップＳ１５０６）。

取り込まれた情報はステップＳ１５０４で生成された意味構造と比較され、その意味構造パスが生成される。例えば“/pizza/number”という文字列が生成される。そして、この文字列が作成中のＵＩコンテンツに組み込まれる（ステップＳ１５０７）。

上の例では、オーサの発声により意味構造を生成したが、オーサが入力したテキストデータにより意味構造を生成することも可能である。例えば、図１６Ａの１６０２のような発声例テキスト入力フォームを用意しておく。オーサがこのフォームにテキストで発声内容を入力し、所定の決定ボタン（例えば同図中の“Nextボタン”）を押すと、そのテキストと音声認識文法から意味構造を生成することも可能である。

（変形例４）
意味構造パスの入力はオーサにまかせ、ＵＩ設計装置はそのパスのチェックを行うだけに留めてもよい。

例えば“意味構造指定モード”に入ると、図８に示した意味構造バインドダイアログ８０１を表示し、オーサに８０３の欄に意味構造パスをテキストで指定させる。その後、８０２の欄に指定された音声認識文法を解析する。そして、その文法で生成され得る意味構造に、オーサにより指定された意味構造パスに適合するものが含まれていることの確認がとられる。ここで、その文法で生成され得る意味構造のどれにもオーサが指定した意味構造パスが適合できなかった場合には、オーサの入力誤りであるとみなし、エラー情報を出力する。

（その他の実施形態）
以上の実施形態およびその変形例では、音声認識文法としてＳＲＧＳを、意味構造構成規則としてＳＩＳＲを、それぞれ想定して説明した。しかし、本発明はその他の音声認識文法形式にも適用が可能である。また、ＵＩ設計装置が出力するコンテンツは、独自の仕様であってもよいし、既存の言語仕様（例えば、ＳＡＬＴ、VoiceXML、XHTML+Voice など）であってもよい。また、テキスト形式でも、バイナリ形式で記述されたフォーマットでもよい。

また、上述の実施形態は音声認識を前提とするものであったが、本発明は音声認識に限定されるものではなく、認識文法を用いるその他のパタン認識（例えば、手書き文字認識、ジェスチャ認識など）にも適用が可能である。

例えば、手書き文字認識でも、認識文法で受理され得る手書き入力結果を、認識文法だけから生成することが可能である。これを用いると、変形例１で説明したように生成され得る意味構造をオーサに提示することができる。

また、変形例３のように、オーサに入力例を入力させることも可能である。図１７Ａ、Ｂは、手書き文字認識アプリケーションにおいて提供されるＧＵＩの例である。このＧＵＩを持つアプリケーションは、変形例３と同様に動作する。ただし、変形例３では、オーサの入力として音声入力またはキーボードを用いたテキスト入力を用いたが、この場合には、オーサは、図１７Ａの手書き文字入力フォーム１７０２中に手書きで文字を入力することになる。

ＵＩ設計装置は、図１７Ａの手書き文字認識用文法指定フォーム１７０１で指定された文法と、手書き文字入力フォーム１７０２に入力された手書き文字のデータを用いて、手書き文字認識を行う。そして、その結果から生成された意味構造を、図１７Ｂの意味構造パス指定ダイアログ１７０３によってオーサに提示し、この構造へのオーサのマウス操作から、特定の意味構造へのパス情報を取得する。

以上、本発明の実施形態を詳述したが、本発明は、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータがその供給されたプログラムコードを読み出して実行することによっても達成される。その場合、プログラムの機能を有していれば、その形態はプログラムである必要はない。

従って、本発明の機能処理をコンピュータで実現するために、そのコンピュータにインストールされるプログラムコード自体およびそのプログラムを格納した記憶媒体も本発明を構成することになる。つまり、本発明の特許請求の範囲には、本発明の機能処理を実現するためのコンピュータプログラム自体、およびそのプログラムを格納した記憶媒体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ、ＤＶＤ−Ｒ）などがある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、そのホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記憶媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記憶媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。

本発明のユーザインタフェース設計装置の機能を実現するコンピュータシステムのハードウェア構成例を示す図である。 本発明の実施形態におけるユーザインタフェース設計装置の機能構成図である。 本発明の実施形態に係るＵＩ設計装置の意味構造指定モードにおけるＵＩ設計処理を示すフローチャートである。 、 音声認識文法の記述例を示す図である。 音声認識文法から生成され得る意味構造の例を示す図である。 一般的な音声ＵＩアプリケーションの画面例（データ入力前）を示す図である。 一般的な音声ＵＩアプリケーションの画面例（データ入力後）を示す図である。 一般的なＵＩオーサリングツールの画面例を示す図である。 従来のＵＩオーサリングツールで意味構造の指定を行うＧＵＩの例を示す図である。 実施形態における音声認識文法選択ダイアログの一例を示す図である。 実施形態における意味構造へのパス生成ダイアログの一例を示す図である。 変形例１に係るＵＩ設計処理を示すフローチャートである。 変形例１に係る発声例の生成アルゴリズムの一例を示す図である。 変形例１における音声認識文法指定ダイアログの一例を示す図である。 変形例１における意味構造概形選択ダイアログの一例を示す図である。 変形例１における意味構造パス指定ダイアログの一例を示す図である。 変形例２における発声例情報を含んだ音声認識文法の一例を示す図である。 変形例２における、生成され得る意味構造情報を含んだ音声認識文法の一例を示す図である。 変形例３に係るＵＩ設計処理を示すフローチャートである。 変形例３における音声認識文法指定ダイアログの一例を示す図である。 変形例３における意味構造パス指定ダイアログの一例を示す図である。 、 他の実施形態における手書き文字認識アプリケーションで提供されるＧＵＩの例を示す図である。

Claims (6)

1. パタン認識機能を提供するアプリケーションのユーザインタフェースコンテンツを生成するユーザインタフェース設計装置であって、
   前記パタン認識の結果の意味構造を生成するための、意味構造を構成する意味構造部品を含む意味構造生成規則が記述された認識文法を取り込む認識文法取り込み手段と、
   オーサが入力装置を介して入力した、意味構造部品の位置を特定するための意味構造パスを取り込む意味構造パス取得手段と、
   前記認識文法に従い生成され得る意味構造に、前記意味構造パスに適合するものが存在するか確認する意味構造パス確認手段と、
   前記意味構造パス確認手段による確認が得られなかった場合、オーサに対しエラー情報を出力するエラー情報出力手段と、
   を有することを特徴とするユーザインタフェース設計装置。
2. 前記パタン認識は音声認識であり、前記認識文法は音声認識文法であることを特徴とする請求項１に記載のユーザインタフェース設計装置。
3. 前記パタン認識は手書き文字認識であり，前記認識文法は手書き文字認識文法であることを特徴とする請求項１に記載のユーザインタフェース設計装置。
4. 前記音声認識文法は、W3C勧告のSpeech Recognition Grammar Specification の仕様に準拠して記述されたものであり、かつ、前記意味構造生成規則は、W3C勧告のSemantic Interpretation for Speech Recognition の仕様に準拠して記述されたものであることを特徴とする請求項２に記載のユーザインタフェース設計装置。
5. パタン認識機能を提供するアプリケーションのユーザインタフェースコンテンツを生成するユーザインタフェース設計装置の制御方法であって、
   認識文法取り込み手段が、前記パタン認識の結果の意味構造を生成するための、意味構造を構成する意味構造部品を含む意味構造生成規則が記述された認識文法を取り込む認識文法取り込み工程と、
   意味構造パス取得手段が、オーサが入力装置を介して入力した、意味構造部品の位置を特定するための意味構造パスを取り込む意味構造パス取得工程と、
   意味構造パス確認手段が、前記認識文法に従い生成され得る意味構造に、前記意味構造パスに適合するものが存在するか確認する意味構造パス確認工程と、
   エラー情報出力手段が、前記意味構造パス確認工程で確認が得られなかった場合にオーサに対しエラー情報を出力するエラー情報出力工程と、
   を有することを特徴とするユーザインタフェース設計装置の制御方法。
6. コンピュータを、パタン認識機能を提供するアプリケーションのユーザインタフェースコンテンツを生成するユーザインタフェース設計装置として機能させるために、該コンピュータに、
   前記パタン認識の結果の意味構造を生成するための、意味構造を構成する意味構造部品を含む意味構造生成規則が記述された認識文法を取り込む認識文法取り込み工程と、
   オーサが入力装置を介して入力した、意味構造部品の位置を特定するための意味構造パスを取り込む意味構造パス取得工程と、
   前記認識文法に従い生成され得る意味構造に、前記意味構造パスに適合するものが存在するか確認する意味構造パス確認工程と、
   前記意味構造パス確認工程で確認が得られなかった場合にオーサに対しエラー情報を出力するエラー情報出力工程と
   を実行させるためのプログラム。

Images