(57)【特許請求の範囲】
【請求項１】
クラス、クラスの属性、およびクラス間の関係を含む実体関連モデルを使って表現されたデータを有するソフトウエア・アプリケーションに対する音声インタフェース・コードを生成するためのコンピュータ実施の方法であって、前記方法は、
−前記実体関連モデルから読み取られ、前記ソフトウエア・アプリケーションのインタフェースに使われているクラスでもなく、抽象クラスでもないと識別された各々のクラスに対し、
−前記クラスの前記属性に対する値の取得のための対話ユニット・コード（ＶｏｉｃｅＸＭＬフォーム）の構造を生成するステップ（３０４）と、
−前記実体関連モデルから読み取られ前記識別されたクラスの各属性に対し、前記クラスが他の一つのクラスと単一の関係を有するか、または前記クラスが他のクラス群と複数の関係を有しているが前記複数の関係が前記属性には適用されない場合は、前記対話ユニット・コード中に、前記属性（ＶｏｉｃｅＸＭＬフィールド）の値の直接取得のためのコードを生成するステップ（３０７）と、前記以外の場合には、前記対話ユニット・コード中に、前記他のクラス群の対話ユニット・コードの選定を可能にするためのサブ対話コードを生成するステップ（３０８）と、
−前記実体関連モデル中の前記クラスに関連する前記関係を読み取ることによって、前記生成されたフォームがエントリ・フォームなのかまたは内部フォームなのかを識別するステップと、
を含む、前記方法。
【請求項２】
前記対話ユニット・コード中に、前記属性に対する値の直接取得のためのコードを生成する前記ステップ（３０７）は、
−前記属性に対する値の直接取得のためのプロンプト・コードを生成するステップと、
−前記実体関連モデルから前記属性のタイプを読み取るステップと、
−前記属性のタイプが組み込み型の場合は、対応する既存の組込み文法に参照付けするステップ（１０７）と、
−前記属性が単純なタイプでない場合、それが列挙である場合にあっては、列挙文法を生成して参照付けし、それが列挙でない場合にあっては、前記属性が被包含型として定義されていれば、この属性によって参照されている前記クラスの前記対話ユニット・コード中に、前記属性の前記クラスの前記対話ユニット・コードを実行するためのサブ対話コードを生成し、前記属性が被包含型でなければ、この属性によって参照されている前記クラスの前記対話ユニット・コード中に、前記属性の前記クラスの前記対話ユニット・コードを選定するためのサブ対話コードを生成するステップと、
を含む、請求項１に記載の方法。
【請求項３】
前記生成された音声対応ウィザード・コードに基づいて、入力ウィザード対話ユニット・コード、および存在する場合内部ウィザード対話ユニット・コードに対する属性値を、全ての前記ウィザード対話ユニット・コードの属性が記入済みになるまで記入することからスタートして、ユーザが音声対応ウィザード・プログラムを実行する前記ソフトウエア・アプリケーションをさらに含む、請求項１または２のいずれか一つに記載の方法。
【請求項４】
前記ステップは、ＵＭＬクラス図である実体関連モデルを読み取って実行される、請求項１〜３のいずれか一つに記載の方法
【請求項５】
コードを生成するための前記ステップは前記ＶｏｉｃｅＸＭＬ言語に基づいており、前記対話ユニット・コードはＶｏｉｃｅＸＭＬフォームであり、前記フォーム中の属性値の直接取得のための前記コードはＶｏｉｃｅＸＭＬフィールドである、請求項１〜４のいずれか一つに記載の方法。
【請求項６】
コードを生成するための前記ステップは自然言語理解に基づいている、請求項１〜５のいずれか一つに記載の方法。
【請求項７】
プログラムがコンピュータで実行されたとき、請求項１〜６のいずれか一つに記載の前記方法の前記ステップを実行するためのプログラミング・コード命令を包含する、コンピュータ・プログラム。
【請求項８】
請求項１〜６のいずれか一つに記載の前記方法を遂行するようになされた手段を包含するシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般にソフトウエア開発に関し、さらに具体的には、本発明は、グラフィカル・ユーザ・インタフェースに対するウィザードと同等なガイド式やり方を用いるソフトウエア・アプリケーションのための、音声ユーザ・インタフェース・コードの生成を目的としており、また、本発明は、例えば、統一モデリング言語（ＵＭＬ：Ｕｎｉｆｉｅｄ  Ｍｏｄｅｌｉｎｇ  Ｌａｎｇｕａｇｅ）クラス図など、設計言語でソフトウエア・アプリケーションを記述した実体関連モデルからスタートして音声ユーザ・インタフェース・コードを生成することも目的としている。
【背景技術】
【０００２】
ソフトウエア・アプリケーション全体のデータ・モデルからスタートして、音声ユーザ・インタフェース・コードの生成を自動化するのは難しい課題である。今日の最新開発ツールは、開発者が、まず対話フローを設計し次いで該フローから音声ユーザ・インタフェース・コードが自動的に生成されるようにして、音声ユーザ・インタフェース・コードを生成することを可能にしている。音声インタフェース人間工学は、一般に非常に微妙であり、開発者は、第一段階で生成された音声ユーザ・インタフェース・コードを修正し、カスタム化する必要がある。この開発コンセプトは、ＯＭＧによって、音声のためのＵＭＬプロファイル（ＯＭＧ）に取り入れられ公式化された。
【０００３】
ソフトウエア・アプリケーションの音声ユーザ・インタフェース・コードが、例えば、ＵＭＬクラス図などのメタ・データ・モデルのような該アプリケーションが取り込むデータのモデル化から、自動的に生成できるようにする必要性がある。しかしながら、現在のところ、このような、メタ・データ・モデルから直接に音声ユーザ・インタフェース・コードを自動的に生成する方法は見出されておらず、ＯＭＧのモデル化の試みも、インタフェースおよび対話フローに大きく重点をおいたものに留まっている。
【０００４】
ユーザ・インタフェース開発のための既存のソフトウエア開発ツールと並行して、グラフィカル・ユーザ・インタフェースとして非常に分かり易いウィザードを組み込んだビジネス・アプリケーションの数が増えている。ウィザードは対話型ソフトウエアであって、ユーザが、ステップバイステップのページを用い、グラフィカル・ユーザ・インタフェースを介しガイド式やり方で、複雑なビジネス・オペレーションを達成するのを助力する。同様に、グラフィカル・ユーザ・インタフェース・アプリケーションに対するウィザードと同等なガイド式やり方が、音声ユーザ・インタフェース・アプリケーションにも求められる。現在のところ、ソフトウエア・アプリケーションのメタ・データ・モデルから、ユーザが、グラフィカル・ユーザ・インタフェースのウィザードを通して行われているようなガイド方式でアプリケーション・データを入力できる、音声ユーザ・インタフェース・コードを直接に自動生成することはできていない
【０００５】
なお、現在のところ、既存の技術では、メタ・データ・モデルから、グラフィカル・ユーザ・インタフェース・コードのウィザード・コードを自動的に生成することもできない。グラフィカル・ユーザ・インタフェースに対しては、実体関連モデルなどアプリケーションの高位設計からスタートして、アプリケーションでの対話を遂行するコードを生成するためのツールがある。対話コードの自動的生成は、各種多くのソフトウエア・ツールによって用いられてきたし、今も使われているが、ほとんどは、ＤｙｎａｍｉｃＴＭＮ（Ｒ）  ＣＭＩＰ  ＭＩＴ  Ｂｒｏｗｓｅｒのような開発ツールでの使用である。ＳＮＭＰまたはＣＭＩＰベースの全ての管理システムは、持続性モデルに基づいて動的にユーザ・インタフェースを生成することに留意する。一つの例が、インターネット・アドレス、ｈｔｔｐ：／／ｗｗｗ．ｍｏｎｆｏｘ．ｃｏｍ／ｄｔｍｎ／ｊａｖａ−ｃｍｉｐ−ｍｉｔ−ｂｒｏｗｓｅｒ．ｈｔｍｌ
に記載されており、これでは、ユーザ・インタフェースが、ＣＭＩＰ定義に取り入れられたＯＯモデルに基づいて自動的に生成される。ＤｙｎａｍｉｃＴＭＮ（Ｒ）ＣＭＩＰ  ＭＩＴ  Ｂｒｏｗｓｅｒは、統合開発環境（Ｅｃｌｉｐｓｅ）ＥＭＦフレームワークが提供しているようなフォームの一般的なプロパティ値表エディタと併せた、データ・モデル・オブジェクトのツリー表示を企図している。また、該Ｂｒｏｗｓｅｒは、データベース・システムのための自動インタフェース・レイアウト・ジェネレータを記載した特許文献１に定義されているような、マニュアルによる追加のグラフィカル・インプットに関連した、これも実体関連モデルを使った、さらに高度な対話法も企図している。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】米国特許第５４９５５６７号
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上記のように、音声ユーザ・インタフェースを含むソフトウエア・アプリケーションのメタ・データ・モデルからスタートして、音声ユーザ・インタフェース・コードを自動的に生成することが必要とされている。さらに加えて、ユーザがオペレーションを遂行するのをガイド式やり方で助力するために、ソフトウエア・アプリケーションのグラフィカル・ユーザ・インタフェースに使われているウィザードと同じようなやり方で、ユーザがデータを入力するのをガイドする音声インタフェースを開発する必要性がある。
【課題を解決するための手段】
【０００８】
本発明の方法およびシステムの目的は、ソフトウエア・アプリケーションの実体関連データ・モデルからスタートして、該モデルの解釈を行って、ガイド式音声インタフェース・コードを自動的に生成するために必要な必須のおよび選択的なステップを定義することである。該ソフトウエア・アプリケーションのガイド式音声インタフェースは、アプリケーションのユーザに実行され、ガイド式やり方の対話で、ソフトウエア・アプリケーションのデータ・モデル中にエンティティを生成する。
【０００９】
グラフィカル・ユーザ・インタフェース・ウィザードが連続するページで構成されているのと同じように、本発明の方法およびシステムによって生成されるガイド式音声インタフェースも、音声対話、および、本文書で以降「フォーム」と呼ぶ対話ユニットの連続で構成される。ＶｏｉｃｅＸＭＬ規格で定義される「フォーム」は、一組のフィールドに対する値の取得に対応する対話コード・ユニットである。類似はしていても、ページとフォームとは同じ構造的性質ではない。標準的なページ機能はあるページに関連している（進む、戻る、終了する）が、「フォーム」はこれと違っている。しかしながら、本文書の以降では、本発明のガイド式音声インタフェースを「音声対応ウィザード」と呼ぶことにする。
【００１０】
音声対応ウィザードに対するコードを自動的に生成するための技術的、人間工学的苦労は、例えば、電話ラインを介して事実上どこにいるユーザにでも接触できるこの音声インタフェースの広汎的性質によって埋め合わせが付く。
【００１１】
本発明の目的は、クラス、クラスの属性、およびクラス間の関係を含む実体関連モデルを使って表現されたデータを有するソフトウエア・アプリケーションに対する、音声インタフェース・コードを生成するコンピュータ実施の方法を記載した請求項１によって達成され、該方法は、
−  実体関連モデルから読み取られ、ソフトウエア・アプリケーションのインタフェースに使われているクラスでもなく、抽象クラスでもないと識別された各々のクラスに対し、
−該クラスの属性に対する値の取得のための対話ユニット・コード（ＶｏｉｃｅＸＭＬフォーム）の構造を生成するステップ（３０４）と、
−  実体関連モデルから読み取られ識別されたクラスの各属性に対し、該クラスが他の一つのクラスと単一の関係を有するか、または該クラスが他のクラス群と複数の関係を有しているがその複数の関係が該属性には適用されない場合は、対話ユニット・コード中に、該属性（ＶｏｉｃｅＸＭＬフィールド）の値の直接取得のためのコードを生成するステップ（３０７）と、上記以外の場合には、対話ユニット・コード中に、他のクラス群の対話ユニット・コードの選定を可能にするためのサブ対話コードを生成するステップ（３０８）と、
−  実体関連モデル中の該クラスに関連する関係を読み取ることによって、生成されたフォームがエントリ・フォームなのかまたは内部フォームなのかを識別するステップと、
を含む。
【００１２】
また、本発明の目的は、請求項１の方法と一体になった請求項２によっても達成され、上記対話ユニット・コード中に、上記属性に対する値の直接取得のためのコードを生成するステップ（３０７）は、
−  該属性に対する値の直接取得のためのプロンプト・コードを生成するステップと、
−  実体関連モデルから属性のタイプを読み取るステップと、
−  該属性のタイプが組み込み型の場合は、対応する既存の組込み文法に参照付けするステップ（１０７）と、
−  該属性が単純なタイプでない場合、それが列挙である場合にあっては、列挙文法を生成して参照付けし、それが列挙でない場合にあっては、該属性が被包含型として定義されていれば、この属性によって参照されているクラスの対話ユニット・コード中に、該属性のクラスの対話ユニット・コードを実行するためのサブ対話コードを生成し、該属性が被包含型でなければ、この属性によって参照されているクラスの対話ユニット・コード中に、該属性のクラスの対話ユニット・コードを選定するためのサブ対話コードを生成するステップと、
を含む。
【００１３】
さらに、本発明の目的は、請求項１または２のいずれか一つに記載の方法と一体になった請求項３によっても達成され、該方法は、生成された音声対応ウィザード・コードに基づいて、入力ウィザード対話ユニット・コード、および存在する場合内部ウィザード対話ユニット・コードに対する属性値を、全てのウィザード対話ユニット・コードの属性が記入済みになるまで記入することからスタートして、ユーザが音声対応ウィザード・プログラムを実行するソフトウエア・アプリケーションをさらに含む。
【００１４】
また、本発明の目的は、請求項１〜３のいずれか一つに記載の方法と一体になった請求項４によっても達成され、上記のステップは、ＵＭＬクラス図である実体関連モデルを読み取って実行される。
【００１５】
さらに、本発明の目的は、請求項１〜４のいずれか一つに記載の方法と一体になった請求項５によっても達成され、コードを生成するための上記ステップはＶｏｉｃｅＸＭＬ言語に基づいており、対話ユニット・コードはＶｏｉｃｅＸＭＬフォームであり、フォーム中の属性値の直接取得のためのコードはＶｏｉｃｅＸＭＬフィールドである。
【００１６】
また、本発明の目的は、請求項１〜５のいずれか一つに記載の方法と一体になった請求項６によっても達成され、コードを生成するための上記ステップは自然言語理解に基づいている。
【００１７】
さらに、本発明の目的は、プログラムがコンピュータで実行されたとき、請求項１〜６のいずれか一つに記載の方法のステップを実行するためのプログラミング・コード命令を包含する、コンピュータ・プログラム製品を含む、請求項７によっても達成される。
【００１８】
また、本発明の目的は、請求項１〜６のいずれか一つに記載の方法を遂行するようになされた手段を包含するシステムを含む請求項８によっても達成される。
【００１９】
本発明の方法は、開発者に対し、音声インタフェース・コードの自動的生成を可能にする利点、すなわち該方法の全ステップがコンピュータ上で遂行可能な設計のモデル化という利点をもたらす。本発明の方法は、アプリケーションの音声対応ウィザード・コードである、統合ユーザ音声インタフェース・コードを提供する。統合された音声対応ウィザード・コードは容易にメンテナンスできる。アプリケーション・ユーザの観点からは、音声対応ウィザードの使用の一般化は、このガイド式ユーザ・インタフェースの便利さの利点がもたらされる。
【００２０】
本方法は、例えばＵＭＬを使った、アプリケーション音声対応ウィザードの開発に対する、ＭＤＡ（Ｍｏｄｅｌ−Ｄｒｉｖｅｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ（モデル駆動アーキテクチャ））アプローチを企図している。
【００２１】
提供する対処法は、永続データがモデル化されているＵＭＬクラス図からスタートする。次いで、このモデルは、システムによって解析され、音声対応ウィザード・コードが自動的に生成される。
【００２２】
本発明の方法は、特定タイプの音声対応ウィザードを生成するための繰り返し可能なプロセスであり、このタイプのウィザードは、アプリケーションのユーザが、実体関連モデルの個別オブジェクトを生成するのを助力するためのものである。クラスの属性に値を付与することが可能なだけの「エディタ」に比べ、本音声対応ウィザード・ジェネレータは、実行時にユーザがクラスの属性に値を付与するのを助力する音声対応ウィザードを生成する。本発明の方法によって生成された音声対応ウィザードは、該音声対応ウィザードを包含するアプリケーションのユーザが、簡単な文字列、日付またはブール値など単純なタイプの値から、別のオブジェクトへの参照などもっと複雑な属性値いたるまでの該アプリケーションの属性値を記入するのをガイドする、全面的に使用可能なソフトウエア・エンティティである。アプリケーション・ユーザによって生成され記入された、音声対応ウィザードのエンティティ・インスタンスは、例えば、該ソフトウエア・アプリケーションの他のプログラムによる編集のため再使用することができよう。
【図面の簡単な説明】
【００２３】
【図１】本発明の、好適な実施形態の方法によって形成される音声対応アプリケーション・ウィザードを構築し使用するための環境を図示する。
【図２】統一モデリング言語（ＵＭＬ）を使って表された、好適な実施形態の方法によるインプットとして用いられるデータ・メタモデルの一例を図示する。
【図３】好適な実施形態の方法の全般的フローチャートである。
【図４】好適な実施形態の方法のフィールド構築のサブプロセス（３０７）である。
【図５】好適な実施形態の属性サブプロセス（３０８）からのサブ対話生成の考えられる実装により形成された、例示的な対話フローチャートを図示する。
【図６】図１に提示されたデータ・メタモデルの一部から生成された生成コードの一例である。
【図７】図１に提示されたデータ・メタモデルの一部から生成された生成コードの一例である。
【発明を実施するための形態】
【００２４】
図１は、好適な実施形態の方法によって形成される音声対応アプリケーション・ウィザードを、構築・使用するための環境を図示している。この環境は、実体関連モデル（１０２）で表されたアプリケーションの永続データを操作する、アプリケーションのウィザードのコードの生成を可能にし、該アプリケーションのデータ・メタモデルはＵＭＬクラス図にすることができる。
【００２５】
好適な実施形態において、音声対応ウィザード・コードを生成する方法は、ソフトウエア・プログラム、コンピュータ実行の音声対応ウィザード・ジェネレータ（１０３）として実装される。音声対応ウィザードのソース・コードを生成する方法のステップの、他の可能な実装（ハードウエア、言語インタプリタ等々）も妥当である。
【００２６】
音声対応ウィザード・ジェネレータ（１０３）は、アプリケーション開発者が、完全に使用可能な音声対応ウィザード（１０５）のコードを生成することを可能にする。次いで、音声対応ウィザード・プログラムをアプリケーションの実行可能ファイル（１１２）と組み合わせて、アプリケーションのユーザ（１１１）に、順次的な音声やり取りで、アプリケーション・データおよびそれらの属性を容易に作成するやり方を提供できる。
【００２７】
この標的音声対応ウィザード（１０５）は、対話指向言語としてのＶｏｉｃｅＸＭＬ、並びに動的コンテントおよび高レベルの対話フロー制御を取り扱うためのＪＡＶＡを含め、音声のためのＵＭＬプロファイル（ＯＭＧ）もしくは適切なプログラミング言語として表現することができる。
【００２８】
音声対応ウィザード・ジェネレータ（１０３）は「ソフトウエア開発環境」（１００）で実行され、アプリケーションの音声対応ウィザードのコードを生成する。その後、音声対応ウィザードは「実行環境」（１１０）に展開され、実行される。
【００２９】
該ソフトウエア開発環境（１００）は、開発者のコンピュータ作業空間において利用可能な、エディタ、ウィザード、コンパイラ、リンカなどのアプリケーション全体を構築するためのツールを含む、今日多く存在する開発フレームワークの一つである。該ソフトウエア環境は、本発明の好適な実施形態の、好ましい開発者インタフェースとして使われるグラフィカル・ユーザ・インタフェースを備える、オペレーティング・システム上で動作するプログラムとしてインストールされる。
【００３０】
実行環境（１１０）は、電話チャネルを介して遠隔に、あるいは、音声対応ウィザードが実行されるのと同じデバイスに音声信号が収集される場合はローカルに、音声アプリケーションを実行するのに適したハードウエアおよびソフトウエアのプラットフォームである。実行環境には、アプリケーション・サーバ、音声ブラウザ、音声認識エンジン、およびテキスト音声変換エンジンを含めることができる。また、実行環境には、随意的にマルチモーダル・ブラウザを含め、音声およびグラフィカル・インタフェースの両方をサポートすることもできる。
【００３１】
核心的ユニットである音声対応ウィザード・ジェネレータ（１０３）は、プログラム・インプットとして一組の情報を必要とする。第一インプットは、アプリケーションによって操作される対象のデータを表す、アプリケーション設計者によって生成されたアプリケーションのデータ・メタモデル（１０２）である。データ・メタモデルは、好適な実施形態中のＵＭＬなど、グラフィカル表現を記述することが可能な設計言語で表される。第二インプットは、実行時環境の音声機能（異なる言語、異なる声音タイプ等々）をサポートする一組のライブラリ（１０７）である。
【００３２】
開発者（１０６）は、これら機能の中でも特に、音声対応ウィザード・ジェネレータによりインプットとして使われるパラメータをカスタム化することができる。これらのパラメータは、例えば、対話のタイプ（指示型対相互主導型）、ＴＴＳプロンプトの長さ、自由記載の属性に対するデフォルト・コレクションの動作（スペル、文法、音声文字変換アルゴリズム…）、必須フィールド、音声対応ウィザード中のフォームの順序などを定義することができる。これらのカスタム化は、実行環境において音声対応ウィザードが実行されるときに適用されることになる。
【００３３】
図２は、好適な実施形態の方法によるインプットとして用いられる、ＵＭＬクラス図であるデータ・メタモデルの一例（２００）を図示している。
【００３４】
図２のデータ・メタモデルは、実体関連モデルであり、プログラム設計者またはアーキテクトによって、任意の高レベルのオブジェクト指向モデリング言語ツールを使って生成されたもので、音声インタフェース属性は定義されておらず、クラス（２０１）、クラスの属性、それら属性関連タイプ（２０３）、およびクラス間の関係（２０２）だけが定義されている。このクラス図の例は、ＲＡＴＩＯＮＡＬ  ＲＯＳＥ（ＩＭＢ社の登録商標）という名称のモデリング・ツールに基づいたＵＭＬを使って作成されたものである。任意の他の高レベルのオブジェクト指向モデリング言語ツールを使って、データ・メタモデルの違った表現が作成することもできたであろう。
【００３５】
クラス、クラスの属性、およびクラス間の関係である図２のデータ・メタモデルから読み取られたエンティティは、ナビゲーション・ツリーを形成し、該ツリーは、以降の図に表されるような、音声対応ウィザード・ジェネレータによって生成されたる音声対応ウィザード・プログラムのフローチャートに線形化される。
【００３６】
図２の例において、該データ・モデルはプロジェクト・マネジメントのアプリケーションに対する設計である。「被包含型」のクラスは、一つの黒いダイヤモンドを有する関係性で他の一つのクラスにリンクされているとして識別されるものである。クラスが被包含型であるという事実は、このクラスに対するデータを取り込むための音声インタフェースの構造に影響する。例えば、ドロップのクラスはプロジェクトのクラスに包含されている、というのは、プロジェクトのドロップがある可能性があり、プロジェクトについてのデータを取り込むため、ユーザ・インタフェースはドロップについてのデータの取り込みも企図しなければならないからである。これに対し、ドロップとバグとの間の関係は、ドロップについてのデータを取り込む際に、バグについてのデータを取り込まなければならない何の必要性もないので、黒いダイヤモンドは含まれていない。バグについてのデータは、プロジェクトについてのデータを取り込む際に必ず取り込まれる。同様に、クラスの属性も、その属性によって参照されるクラスが被包含型として定義される場合、被包含型として識別される。プログラムの観点からは、被包含型クラスのデータを取り込む、音声対応ウィザード・プログラムのコードは、その音声対応ウィザード・プログラム内の他のコードから呼び出しを受けるサブプログラムである。この概念についてはサブ対話として、ステップ３０８においてさらに説明する。
【００３７】
図３は、生成プロセスの過程で、全音声対応ウィザード・コンポーネントを生成する（３００）ための方法の全般的フローチャートである。このフローチャートは、ジェネレータのコンポーネントに実装される。
【００３８】
該プロセスの最初のステップは、データ・モデル中の全てのクラスを収集し、収集された全てのクラスをループし（３０１）、このとき、処理中のクラスがインタフェースかどうかを点検する（３０２）ことである。クラスは、それ自体は方法を定義しているインタフェースを実装することができ、インタフェースは具象クラスとしてインスタンス化することができず、このため、インタフェースは、編集されないので上記プロセスでフィルタしなければならない。そのクラスがインタフェース・クラスである場合（検定３０２の答えが「はい」）、次のクラスが読み取られる（３１４）
【００３９】
そのクラスがインタフェース・クラスでない場合（検定３０２の答えが「いいえ」）、システムは、対象が抽象クラスかどうかを点検する（３０３）。抽象クラスは、具象クラスが使用または再定義するため必要となることのある、デフォルト動作方法および属性を包含しており、このため、抽象クラスも上記プロセスでフィルタしなければならず、これらは、本プロセスの後の方でこれらを使用する具象クラスを介してだけ使われる。
【００４０】
そのクラスが抽象クラスである場合（検定３０３の答えが「はい」）、次のクラスが読み取られる（３１４）。そのクラスが抽象クラスでない場合（検定３０３の答えが「いいえ」）、システムは、フォームの識別子に対するベースとしてクラスの名前を使ってクラスの定義からウィザードのフォームを生成するための、別の主要ステップ（３０４）の実行に進む。
【００４１】
プロセスの次のステップは、処理中のクラスおよびその祖先の全ての属性を収集し、それら全ての属性をループする（３０５）ことである。各属性に対し、検定３０６は、それが単一関係かどうかを点検する。
【００４２】
そのクラスが、別のクラスと単一の関係を有する場合（検定３０６の答えが「はい」）、次のステップは、処理中のフォーム中に、読み取られた属性からフィールドを生成する（３０７）。音声ＸＭＬ言語のためのＷ３Ｃによって定義されたフィールドは、文法に基づいて特定の変数または属性のインスタンスを形成するために用いられる、フォームのサブエレメントである。フィールド生成のサブプロセスの定義は、本文書の後記で図４を参照しながら説明する。
【００４３】
上記と異なりそのクラスが複数の関係を有する場合（検定３０６の答えが「いいえ」）、次のステップは、該複数関係の標的クラスからサブ対話を生成する（３０８）。このサブ対話は、どのようなエンティティがこの属性の部分であるかを定義し、該標的クラスが処理中のクラスに包含されていれば、それらエンティティを生成することを狙いとしている。サブ対話がその役割を完了したならば、前回の点からフォーム呼び出しの実行が継続される。本文書で定義するサブ対話の動作は、音声ＸＭＬ言語仕様書でＷ３Ｃによって定義されたエレメント・サブ対話の動作に比較的類似しており、この特定のコンテキストにおいて、動的コンテントを制御するため、その実装をＪＡＶＡ／ＪＳＰなどの中間プログラミング・レイヤ中に定着させることもできる。
【００４４】
かかるサブ対話の実装の例が図５に示されている。標的クラスが只今処理中のクラスに包含されていない場合には、これに換えて選定フィールドを用いることができる。かかるフィールドは、この属性に対し適格な全てのエンティティを連結する特定フォームを可能にする文法と関連付けられている。
【００４５】
次いで、該クラス中にもう属性がなくなる（検定３０９の答えが「いいえ」）まで、次の属性が読み取られる（３０９）。
【００４６】
該クラスの全属性が処理されたならば（検定３０９の答えが「いいえ」）、ステップ３１０は、必須の属性に関連するフィールドを前に進めるために、フォーム内の全てのフィールドの並べ替えを開始する。これは、本発明の好適な実施形態である、指示型（順次型）対話スキームにおいて特に重要である。ステップ４０２に記載したバイパス文法によって、全ての必須属性のインスタンスが作成されたとき、ユーザが次のクラスにスキップできる可能性が開かれる。
【００４７】
次いで、システムは、関係のある標的クラスが被包含型かどうかを点検する（３１１）。この情報は、ステップ３０７の実行の間保存されているか（図４のステップ４０９の説明に関連して本文書の後記で説明する）、あるいはこの検定３１１において読み出される。該クラスが関係のあるソース・クラスによって、包含はされていないが参照されているだけの場合（検定３１１の答えが「いいえ」）、次のステップは、処理中のフォームに「エントリ・フォーム」としてフラグを立てる（３１３）。エントリ・フォームは、対話フローに対する適格な入力ポイントである。
【００４８】
上記と異なりクラスが被包含型である場合（検定３１１の答えが「はい」）、次のステップは、処理中のフォームに「内部」としてフラグを立てる（３１２）。内部フォームは、上記関係のソースに基づき、音声対応ウィザード内でだけ呼び出すことができるフォームである。これは、対話フローの入力ポイントとすることはできないものである。
【００４９】
該プロセスの最後のステップ（３１３）は、生成されたフォーム（３０４）を、エントリ・フォームとして（３１３）または内部フォームとして（３１２）音声対応ウィザードに加える。対話フローは、開発者が、随意的にカスタム化処理を入力し（１０６）特定の命令を組み付ける場合を除いて、フォーム生成の順番に展開される。各フォーム内で、デフォルト実装は、指示型（順次型）対話であるが、混合主導型または自然言語などもっと精緻な対話方式も考えることができる。
【００５０】
全てのクラスが読み取られ（検定３１４の答えが「いいえ」）、全フォームの生成が完了したとき、開発者が音声対応ウィザードに対するページ順序をカスタム化する場合、随意的ステップ３１５においてフォームの再順序付けをすることが可能である。
【００５１】
図４は、処理中のクラスの属性に基づいてフィールドを生成するための、サブプロセスのフローチャート（４００）である。このフローチャートは、ジェネレータのコンポーネント（１０５）中に実装される。これは、処理中のフォーム（３０４）に新しいフィールドを与えるものである。
【００５２】
このプロセスの最初のステップ（４０１）は、属性が必須のものかどうかを点検する。答えが「いいえ」の場合、ステップ４０２は、バイパス文法を生成し、これに整合する場合、処理中の、もしくは後続の全ての属性のスキップを可能にする。後者の選択は、ステップ３１０による指示型または順次型対話スキームにおいて行うことができ、次のフォーム／クラスへの移行（グラフィカル・インタフェースでの「次へ」または「終了」ボタン）に相当する。この文法は、生成された場合、後で主フィールド文法に包含される（４０８、４０９、４１１、４１３）。ステップ３１０での実装を容易化するために、各フォームに対する必須フィールドの永続リストを維持しておくことができる。実行時に、ユーザから次のフォームへのスキップが要求され、記入対象として残る少なくとも一つの必須項目を有するフォームが他にない場合、その時点で対話を終了することができる。ステップ４０１、４０２、４０８、４０９、４１１、４１３、および４１６は、随意的なフィールドをスキップするための簡単な実装スキームを形成する。しかしながら、例えば当技術分野で周知の混合主導型または自然言語対話など、非指示型対話を介してフィールドの記入をすることが可能な対話による他のスキームにおいては別の選択肢も可能である。
【００５３】
ステップ４０３においてクラスの属性が読み取られ、ステップ４０４においてその名前を使ってプロンプトが生成される。このプロンプトは、典型的には、テキスト音声変換技術を使い、例えば「Ｘ欄に対する値を入力してください」といったデフォルト説明文に、クラスの属性名を組み込んで動的に生成される。
【００５４】
ステップ４０５においてクラスの属性タイプが読み取られ、システムによって点検されて（４０６）単純なタイプと複雑なものとに分けられる。
【００５５】
処理中のタイプが単純な場合（検定４０６の答えが「はい」）、次のステップは、当該技術により、対応する単純なタイプに基づいて単純な入力フィールドを生成することである。この目的を達成するため、ステップ４０７は、処理中のものが組込みタイプかどうかを検定する。組込みタイプとは、本発明の実行環境が、Ｗ３Ｃによって定義されたＶｏｉｃｅＸＭＬ組込み文法などの文法を、それに対し提供できるタイプであると定義する。処理中の属性タイプが組込みタイプの場合（検定４０７の答えが「はい」）、ステップ４０８は、処理中のフィールドに対しこの組込み文法を参照付けする。
【００５６】
処理中の属性タイプが組込みタイプでない場合（検定４０７の答えが「いいえ」）、ステップ４０９は、その属性に対するデータ収集のため、バックオフ方式を実行する。このバックオフ方式は、ほぼ一切のテキスト入力を対象とするバックオフ文法（例えばスペリング文法）で構成することができる。これに換えて、この属性に対し、音声文字変換システムを使うことができ、あるいは、最も簡単な代替策の一つとして、音声信号の単なる記録を収集し記録することもできる。
【００５７】
次いで、新しく生成されたフィールドが処理中のフォームに加えられる（３０４）。
【００５８】
属性のタイプが複雑な場合（検定４０６の答えが「いいえ」）、次のステップは、該タイプがデータ・モデルで定義された列挙であるかどうかを点検（４１０）することである。
【００５９】
処理中のタイプが列挙である場合（検定４１０の答えが「はい」）、次のステップは、該列挙で定義されるあり得る全ての値を含むデフォルト列挙文法を生成する（４１１）ことである。次いで、完了したフィールドが処理中のフォームに加えられる（３０４）。
【００６０】
上記と異なり処理中のタイプが列挙でない場合（検定４１０の答えが「いいえ」）、次のステップは、システムが該属性が被包含型かどうかを点検しているかどうかを確認することである（４１２）。
【００６１】
処理中の属性が被包含型である場合（検定４１２の答えが「はい」）、これは、
−この属性によって参照されるクラスは被包含型として定義され、実体関連データのメタモデル中の別のクラスがこのクラスをポイントしており、このクラスに対して「内部」とフラグされたフォームが生成されることになる、
−解析されている属性は、データ・メタモデル中の他のクラスをポイントしているものである、ということを意味する。
この場合、ステップ４１３は、ユーザに、標的クラスのオブジェクトが生成されようとしていることを知らせるＴＴＳプロンプト生成する。次いで、ステップ４１４で文法が生成・参照付けされ、ユーザが、必須でないフィールドをスキップしまたは次のクラスにジャンプできるようにすることになる（ステップ４０２参照）。ステップ４１５は、標的クラスに対し生成された適切な内部フォームを使って処理中の属性のインスタンスを作成するため、該属性からサブ対話を生成する。次いで、新しく生成されたフィールドが処理中のフォームに加えられる（３０４）。
【００６２】
上記と異なり処理中の属性が被包含型でない場合（検定４１２の答えが「いいえ」）、次のステップは、実行時に、標的クラスの適格な既存のオブジェクトとともに提供される文法を生成・参照付けし、ユーザが、それらオブジェクトの中から処理中の属性に対し適切な値を選択できるようにすることである。次いで、新しく生成されたフィールドが処理中のフォームに加えられる（３０４）。
【００６３】
図５は、ステップ３０８（複数関係の属性からサブ対話を生成する）を遂行する対話フローチャートの例を図示する。プロンプト（５０１）は、実行時に動的に読み出せる選定オブジェクトおよび適格オブジェクトをリストする。また、ユーザは、現在の対話を終了する（親フォームへ戻る）こと、あるいは標的クラスの新しいオブジェクトを生成することを選択することもできる。音声認識の整合如何によって（５０２、５０３、５０４、５０５）、現在の選定からオブジェクトが除去され（５０６）、または現在の選定にオブジェクトが追加され（５０７）、あるいはオブジェクトが生成されて現在の選定に追加され（５０８、５０９）、もしくは、既選定のオブジェクトの数が、データ・メタ・モデルに適合する場合、ユーザは対話を終了する（５１１）ことができる。
【００６４】
図６および図７は、音声対応ウィザード・ジェネレータ（１０３）が生成することができる、ＶｏｉｃｅＸＭＬ中の対話コードの一例を図示する。ステップ３０４によって、対応クラスに対し「ＣｏｎｓｕｌｔｉｎｇＰｒｏｊｅｃｔ（コンサルティングプロジェクト）」のフォームＩＤが生成される。該フォームは、実体関連データ・メタモデル中の、クラスＣｏｎｓｕｌｔｉｎｇＰｒｏｊｅｃｔの対応する単一関係の属性に対してステップ３０７によって生成された４つのフィールド（Ｎａｍｅ（名前）、ＳｔａｒｔｉｎｇＤａｔｅ（開示日）、ＥｎｄｉｎｇＤａｔｅ（終了日）、ＣｏｍｐａｎｙＮａｍｅ（会社名））をさらに含む。これらのフィールドの各々内の文法は、ｓｐｅｌｌｉｎｇ．ｇｒｘｍｌおよびｄａｔｅ．ｇｒｘｍｌに対してはステップ４０８で、ｓｋｉｐ．ｇｒｘｍｌに対してはステップ４０２で生成・参照付けされる。
【００６５】
図３、４および５のフローチャートを用いて説明した音声対応ウィザード・コードを生成する方法は、オペレーションおよび検定のステップを含む。アプリケーション開発者は、好適な実施形態で説明した全てのステップを対話モードにおいてコンピュータ上で実行する（１０６）ことができるが、当技術分野で周知のように、これらの全ステップを、ソース・コード・ジェネレータ・プログラムによって自動的に実行することも可能である。好適な実施形態において、開発者は、開発フレームワークのウィザードを介して、ソース・コード・ジェネレータを呼び出すことができ、該ウィザードは、開発者が随意的にウィザードを介して生成プロセスに追加を行う（１０６）ことを可能にするページを開発者に提示することになる。また一方、音声対応ウィザード・コードの生成は、スタンドアロン・モードで、カスタム化の随意的ステップのため実行することもでき、開発者は、カスタム化ファイルを前もって作成しておき、音声対応ウィザード・コード・ジェネレータの自動実行の過程でのインプットとして使うことができる。
【図１】
0005363589.tif 000002
【図２】
0005363589.tif 000003
【図３】
0005363589.tif 000004
【図４】
0005363589.tif 000005
【図５】
0005363589.tif 000006
【図６】
0005363589.tif 000007
【図７】
0005363589.tif 000008