JPH08512155A - スピーチアプリケーション用の命令を生成するシステム - Google Patents

Abstract

(57)【要約】 スピーチアプリケーションプラットフォームのようなアプリケーションプラットフォーム上へのダウンロードが可能な命令を生成するシステムに関する。命令は、複数のパラメータ依存処理によって定義される。各処理はブロック単位で識別され、各ブロックはアプリケーション構成図を特定するために互いにリンクされている。パラメータが入力される前に、リンクされたブロックの構造に関して有効化が行われる。当該構造の有効化テストの後で、パラメータが付加されることになる。パラメータの入力が完了すると、完全なるシステムを構築するためのシミュレーション（スピーチシミュレーションを含む。）が行われる。シミュレーションは、開発プラットフォーム上において、又はスピーチアプリケーションプラットフォーム上において行われる。ブロックは外部ルーチンへのコールを定義している。こうして独自に定義されたシステムは、ダウンロードが可能な命令に自動的に変換される。また、ダウンロードが可能な命令は、外部ルーチンへのコールを含んでいる。そして、上記ルーチンはオンライン処理を行っている間にコールされる。一方、スタッブブロックが用意されており、これはダウンロードが可能なコードの中にＣコードを埋め込む。

Description

【発明の詳細な説明】 スピーチアプリケーション用の命令を生成するシステム 技術分野 本発明は、ダウンロードが可能な命令を生成する技術に関する。また、本発明 は、スピーチアプリケーションを定義する技術に関する。また、本発明は、スピ ーチアプリケーションをシミュレートする技術に関する。 背景技術 スピーチアプリケーションのプラットフォームは、呼出し待ち，呼出し転送， 電話返答やメッセージ記録などの自動化された顧客サービスを提供する電話交換 において使用される。現代の電話交換において使用されるコンピュータのハード ウェアは洗練されており、実際に構築されている以上の広い範囲での顧客サービ スを与えることが可能となっている。この矛盾が生じるのは、顧客サービス用の ソフトウェアを生み出すのに長い処理過程を要するからである。さらに、新たな 顧客がサービスに興味を抱いてより多くこれを利用するようにさせるためには、 ラインを繋ぐ前にその新たな顧客のサービス用の厳密なシミューレーション動作 を行わなければならない。 スピーチアプリケーションは、歴史的には手作りで作成されてきた。サービス の設計者は、最初、フローチャートや他の図式ツールを用いて紙上でサービスを 定義する。一度この形で設計されると、サービスは“スクリプト”として書き出 される。このスクリプトは、演劇用のスクリプトに類似して はいるが、アプリケーションプラットフォームとコール（発呼）する顧客との間 の相互対話について定義している。スクリプトには、顧客のオプションとプラッ トフォームとを判断するための分岐（ブランチ）が存在する。このため、認識可 能なスクリプト言語で書かれたスクリプトは、サービス用として可能なすべての 処理を定義している。そしてスクリプトは、サービスを構築するプログラムを書 く経験のあるプログラマーに提供される。異なる種類の様々なスピーチアプリケ ーションプラットフォーム上で動作させる変更回数を減らすためには、プログラ ムはＣ又はＣ++のような高いレベルの言語で記述する。 この手法においては、フローチャートレベルでサービスの定義を変更するため には対応するスクリプト及び対応するＣやＣ++プログラムを変更する必要がある という難点がある。このため、完成された顧客サービスを変更する際には、サー ビスの定義を少しだけ変えるだけでも不相応な努力をすることになる。 更なる間題としては、サービスの定義をスクリプトに翻訳する際に誤りが起こ りやすいことである。特に、スクリプトをプログラムに翻訳する際には誤りが起 こりやすい。このため、プログラムのデバッグには膨大な時間が普通に費やされ ることになる。多くのコンピュータソフトウェアを使用する場合、生産後に微少 のエラーが残っていることは許容される。こうしたエラーは、しばらくソフトウ ェアを使用しているうちに見つかるという程度のものである。しかしながら、ス ピ ーチアプリケーションの場合は、次の２つの理由により、そのような許容の程度 ではない。第１に、サービス処理中に顧客が誤って電話をすばやく切ってしまう ことがある。この場合、返答サービスにおいてメッセージが失敗した状態となり 、有効な連絡ができなくなることになる。第２に、いくつかのコンピュータがス ピーチアプリケーションプラットフォームとして使用される場合、ソフトウェア のコーディングエラーが他のプラットフォームの処理に介入してしまうことがあ る。最悪の場合は、電話交換の完全な故障を引き起こすことになる。 これらの問題を解決するには、サービスの定義をコンピュータプログラムに翻 訳する処理を自動化することである。そうしたシステムはサービス作成ツールと 呼ばれる。周知のサービス作成ツールにおいては、サービスは、グラフィカルユ ーザインタフェースを採用するコンピュータ上のフローチャートとして定義され る。グラフィカルユーザインタフェースを使うことにより、個別の機能ブロック は、それぞれ位置づけられて、サービス全体の定義を形成するために互いに接続 される。各ブロックはパラメータの調整を行うために選択されることになる。パ ラメータの調整は、フローチャート内でそのブロックが他のブロックとどのよう に接続されるかを決めるためになされるもので、特定のブロックを動作させるこ とにより行われる。 一度定義がされると、周知のサービス作成ツールは、グラフィックのサービス 定義から特定のスピーチアプリケーショ ンプラットフォーム用の実行可能コードへの直接変換を自動的に行う。このため 、手作りによるサービス作成における多くの欠点が解決される。しかしながら、 この周知のシステムは、他のアプリケーションプラットフォームに適したプログ ラムを生成しない。 発明の概要 本発明の第１アスペクトによれば、アプリケーションプラットフォームに対す るダウンロードが可能な命令を生成する方法であって、論理制御されるアプリケ ーションを定義するために複数のパラメータ依存処理がリンクされており、機能 ブロックをグラフィックで表示するステップと、アプリケーションの動作中にお いて前記ブロック間の論理フローを順に示す当該ブロック間の接続をグラフィッ クで表示するステップと、前記論理フローの有効性をテストするために前記ブロ ック間の接続の有効性をテストするステップと、前記有効性のテストの後に、ブ ロックの機能を特定する処理パラメータを入力するステップとを有することを特 徴とする方法を提供する。 本発明は、特にスピーチアプリケーションプラットフォーム用のアプリケーシ ョンを定義することに適用される。本発明の第２アスペクトによれば、スピーチ アプリケーションプラットフォーム上へのダウンロードが可能な命令を生成する 方法であって、機能ブロックをグラフィックで表示するステップと、サービス構 造を定義するための前記ブロック間の接続をグラフィックで表示するステップと 、ブロック間の欠落 リンクとブロック間の二重化したリンクと入力リンクの欠落したブロックとを調 べるために前記接続の有効性をテストするステップとを有することを特徴とする 方法を提供する。 図面の簡単な説明 図１は、顧客の装置に接続するとともにスピーチアプリケーションプラットフ ォームを備えた交換機を有する電気通信網を示している。 図２は、図１に示す種類のスピーチアプリケーションプラットフォームであり 、プラットフォームの有線動作を制御する命令を記憶する記憶装置を含んでいる ものを詳細に示している。 図３は、図２に示すプラットフォーム上で使用される命令を生成するシステム であり、処理ユニット，記憶装置，及び音声信号の生成と認識を行うスピーチカ ードを備えているものを示している。 図４は、図３に示すスピーチカードを詳細に示す。 図５Ａは、図３に示すシステム上でサービスを定義する間に行われる処理の慨 要であり、グラフィカルユーザインタフェース内のサービス構造を定義する処理 ，その構造の有効化の処理，ブロックのパラメータを入力する処理，及びブロッ クテキストファイル内のブロックのパラメータを更新する処理を含んでいるもの を示している。 図５Ｂは、図３に示すシステム上でサービスをシミュレートするとともにダウ ンロードが可能なコードの生成を行う間に行われる処理の慨要を示している。 図６は、図５Ａに示すサービス定義の手順が開始される前にソフトウェアで自 動的に行われるハードウェアの初期化手順を詳細に示している。 図７は、図５Ａに表された処理手順であり、グラフィカルユーザインタフェー ス内のサービス構造を定義するための手順を詳細に示している。 図８は、図５Ａに表されたフローチャート有効化手順を詳細に示している。 図９は、図７におけるサービス構造を定義する手段として表されたグラフィカ ルユーザインタフェースを詳細に示している。 図１０は、図５Ａに表された処理手順であり、ブロックテキストファイル内で パラメータを更新するための手順を詳細に示している。 以下の図は、サービス構造を定義するブロック形式の詳細を示している。これ らの図においては、図５Ａに表された処理手順においてパラメータがどのように 入力されるかを定義する各スクリプト定義が対応するテキストファイルにマッピ ングされている。 図１１Ａは、“ＯＫ”ボタンを含む返答ブロック形式を詳細に示している。 図１１Ｂは、図１１Ａに表された返答ブロック形式に入力されるパラメータか らテキストファイルを生成する際に使用されるスクリプトの構成を詳細に示して いる。 図１２Ａ及び１２Ｂは、ハングアップブロック形式及びそ の対応するスクリプトの定義を詳細に示している。 図１３Ａ及び１３Ｂは、ダイアルアウトブロック形式及びその対応するスクリ プトの定義を詳細に示している。 図１４Ａ及び１４Ｂは、転送ブロック形式及びその対応するスクリプトの定義 を詳細に示している。 図１５Ａ及び１５Ｂは、インフォブロック形式及びその対応するスクリプトの 定義を詳細に示している。 図１６Ａ及び１６Ｂは、ＤＴＭＦブロック形式及びその対応するスクリプトの 定義を詳細に示している。 図１７Ａ，１７Ｂ及び１７Ｃは、質問ブロック形式及びその対応するスクリプ トの定義を詳細に示している。 図１８Ａ及び１８Ｂは、ＹＥＳ／ＮＯブロック形式及びその対応するスクリプ トの定義を詳細に示している。 図１９Ａ及び１９Ｂは、記録ブロック形式及びその対応するスクリプトの定義 を詳細に示している。 図２０Ａ及び２０Ｂは、プレイブロック形式及びその対応するスクリプトの定 義を詳細に示している。 図２１Ａ及び２１Ｂは、外部ブロック形式及びその対応するスクリプトの定義 を詳細に示している。 図２２Ａ及び２２Ｂは、スタッブブロック形式及びその対応するスクリプトの 定義を詳細に示している。 図２３Ａ及び２３Ｂは、スイッチブロック形式及びその対応するスクリプトの 定義を詳細に示している。 図２４Ａ及び２４Ｂは、テストブロック形式及びその対応するスクリプトの定 義を詳細に示している。 図２５〜３８は、前述の各図に示したツールを使用して構築される特定のサー ビスの動作例を示している。 図３８Ａ及び３８Ｂは、図３７に示す変更したスタッブブロックの形式及び結 果としてのテキストファイルを詳細に示している。 図３９は、図５Ｂに示すサービスのシミュレーションの手順の詳細に示してい る。 図４０は、返答ブロックのシミュレーションを行うための制御手順を詳細に示 している。 図４１は、ハングアップブロックのシミュレーションを行うための制御手順を 詳細に示している。 図４２は、ダイアルアウトブロックのシミュレーションを行うための制御手順 を詳細に示している。 図４３は、転送ブロックのシミュレーションを行うための制御手順を詳細に示 している。 図４４は、インフォブロックのシミュレーションを行うための制御手順を詳細 に示している。 図４５Ａ及び４５Ｂは、ＤＴＭＦブロックのシミュレーションを行うための制 御手順を詳細に示している。 図４６は、質問ブロックのシミュレーションを行うための制御手順を詳細に示 している。 図４７は、記録ブロックのシミュレーションを行うための制御手順を詳細に示 している。 図４８は、外部ブロックのシミュレーションを行うための制御手順を詳細に示 している。 図４９は、図５Ｂに表される処理手順であり、ダウンロードが可能なサービス 命令の生成のために変数の取出し及びスクリプトファイルの処理を含んだものを 示している。 図５０は、図４９に表される変数の取出しを詳細に示している。 図５１は、図４９に表されるスクリプトファイルの処理を詳細に示している。 好適な実施例の詳細な説明 好適な実施例は、命令の生成に関し、電話交換又は個々の分岐交換において使 用される種類のスピーチアプリケーションプラットフォーム上にダウンロードす ることが可能な命令に関する。但し、記述される技術は、その他の状況にも適用 することができるものである。この場合、処理を実現する複数のパラメータが、 制御されるアプリケーションを論理的に定義するためにリンクされることになる 。 アプリケーション環境 電気通信網を図１に示す。この電気通信網は複数の中継交換機１５を有してお り、中継交換機１５は複数の局所交換機１６に接続されている。各局所交換機は 複数の局所線１７に接続されており、従来の会話用の電話のように顧客の端末装 置１８に代わるがわる接続される。 各局所交換機１６は、顧客ターミナルとアナログ信号の送受を行う。局所交換 機においては、アナログ信号は中継交換機１５へのディジタル伝送のために符号 化され、中継線から受信されたディジタル信号はアナログ伝送のために局所網に おいて複合化される。ディジタル信号は、中継線１９を介して交換機間で伝送さ れる。このとき、３０のディジタル化されたスピーチチャンネル及び２つのディ ジタル化された信号チャンネルにつき、２メガビット／秒で時分割多重で伝送さ れる。 中継交換機１５はスピーチアプリケーションプラットフォーム２０を有してお り、２メガビット以上の多重化で交換機と連絡するように配置されている。この ため、各スピーチアプリケーションプラットフォームに配備されたハードウェア は、３０の電話チャンネルを取り扱うことができる。 スピーチアプリケーションプラットフォームを図２に示す。このプラットフォ ームは、ラインインタフェース回路２１，スピーチプロセッサ２２，及びプログ ラマブルプロセッシング装置２３を有している。３２チャンネル多重（３０のス ピーチチャンネル及び２つの信号チャンネル）は、ディジタル伝送線２４を介し てラインインタフェース回路２１に供給される。ラインインタフェース回路は信 号コマンドに応じ、次の処理のための各スピーチチャンネルを識別する。 スピーチアプリケーションは、通常は入力されるコールによって開始される。 特に、信号チャンネル上に含まれる情報は、ラインインタフェース回路２１に入 力されるコールの有無を識別する。代わりに、ラインインタフェース回路は、デ ータバス２５を介してプロセッサ２３と連絡する。このとき、ラインインタフェ ース回路は、最初は特定のチャンネルがスピーチサービスを利用したがっている ことを識別し、そして 要求された特定のサービスを識別する。 スピーチアプリケーションプラットフォームは、顧客からの要求に応じて多く の異種の処理を実行する。これらのサービスは、ハードディスクのような記憶装 置２６に記憶されている命令に応じて実行され、要求されたサービスのための特 定の命令は、これら特定のサービスが要求されたときにだけプログラマブルプロ セッサにロードされる。 顧客からの要求は、音声の形で伝送されるか又は非接続の閉じた形態でデータ として伝送され、データバス２５を介してプログラマブルプロセッサ２３に伝送 される。特定のスピーチアプリケーションのための命令が記憶装置２６からプロ グラマブルプロセッサ２３にロードされた後、プログラマブルプロセッサ２３は 、データバス２２を介してラインインタフェース回路２１及びスピーチプロセッ サ２２に対して要求に応じた命令を発行する。このため、圧縮された音声の記録 がスピーチプロセッサ２２に伝送される。このスピーチプロセッサ２２は、音声 を伸張し、その伸張した音声をスピーチバス２７を介してラインインタフェース 回路に供給するように構成されており、音声を代わるがわる通信チャンネル２４ へリレーする。その後、他の音声信号の場合も同様に次々と処理されることにな る。 ラインインタフェース回路２１によって受け取られた音声は、スピーチバス２ ７を介してまたスピーチプロセッサに伝送される。スピーチプロセッサが音声の パターンを認識することを必要としているときには、プログラマブルプロセッサ ２３の制御の下で、スピーチテンプレート（即ち、より一般的には隠れマルコフ モデル）が記憶装置２６からダウンロードされ、データバス２５を介してスピー チプロセッサ２２に供給される。 −般に、プラットフォームに適用可能なサービスの開発は進行中の段階にあり 、プラットフォームのために生成されて記憶装置２６にロードされるべき新規な 命令が要求されている。従来においては、スピーチアプリケーションプラットフ ォーム用の新規な命令を開発するためには、膨大な時間と高い熟練度が要求され ていた。 スピーチアプリケーションプラットフォームは、オペレーティングシステムの 制御の下で動作する。この場合、登録商標となっているＵＮＩＸのようなオペレ ーティングシステムが提供される。アプリケーションプログラムは、高レベル言 語で作成される。この場合、ＣやＣ++のような高レベル言語が翻訳され、ＵＮＩ Ｘオペレーティングシステム及びスピーチアプリケーションプラットフォームを 構成するハードウェアと互換性のある命令が生成される。そしてこれらの命令は 、記憶装置２６に記憶されることになる。この場合の記憶装置２６は、例えばハ ードディスクドライブであり、発呼者が特定のサービスを要求したときのために 使用される。 命令の中にエラーが存在する場合、プラットフォームは顧客に対して不適切な 振る舞いをし、顧客に不満を抱かせる。交換機の中にスピーチアプリケーション プラットフォームを含ませた場合、交換機のコストを増加させる。一度含ませる と、プラットフォームを十分に利用できたときだけにしかコストをかけた意味が なくなるということになる。したがって、顧客を満足させるということは重要な 要件である。さらに、サービスを行っているプラットフォーム内でエラーが発生 すると、交換機全体が動作不能に陥ることがある。 エラーは、通常、高レベル言語でサービス用プログラムを書く段階で引き起こ される。この場合、プログラムはアプリケーションプラットフォーム上にダウン ロードされ、プラットフォーム用の命令に翻訳される。顧客サービス用のプログ ラムを書く処理は時間がかかるため、生成されるプログラム中にはエラーが存在 しないことが特に望ましい。このため、次のようなジレンマが生じる。すなわち 、営業上の十分な収益を上げるためには顧客に対するサービスをできるだけ速く 作成又は変更できるようにすることが望ましい反面、同時にエラーが存在しない ことを保障するようにすることが望ましい。 また、あるグラフィック上の位置において完全かつ十分に動作する特定のアプ リケーションが他の位置においてもその環境の中で動作できるように変更可能に することが望まれる。特に、地域言語，イディオムや方言が使用されることをも 考慮した音声認識が使用される際に、上記のことが望まれる。このため、エラー が存在せず十分に受け入れ可能なサービス命令を構築することは可能であるが、 一方、特定の環境の中で動作変更を行えるようにすることが望まれる。例えば、 アプリケーションは、“はい”と“いいえ”の言葉を多くの地 域にわたって認識するように設計される。この場合、例えば英語が使用され、他 の言語については同じ意味への変換が行われるようにすればよい。 本実施例は、スピーチアプリケーションプラットフォーム用のサービスの命令 を生成するための改善したシステムを目指している。さらに、本実施例は、現に 処理しているプラットフォームに命令がダウンロードされる前に該命令をテスト するシステムを提供する。 システムの概要 スピーチアプリケーションプラットフォームによって行われるサービスを定義 するための命令を生成してテストするシステムを、ここでは開発プラットフォー ムと呼ぶ。開発プラットフォームを図３に示す。この開発ブラットフォームは、 パーソナルコンピュータにおいて通常使用されるアーキテクチャに基づくもので ある。開発プラットフォームは、インテル社が提供するマイクロプロセッサ“８ ０３８６”のような処理装置３１と、これによりアクセスされる典型的な４メガ バイトのランダムアタセスメモリ（ＲＡＭ）３２及び４０メガバイトのハードデ ィスクドライブ３３（永久保存部）を有している。ハードウェアは、追加カード が備えられたＰＣマザーボードを使用して構築されてもよい。 データバス３４は、プロセッサ３４とメモリ３２の間でのデータ伝送をさせる ためのバスであり、インタフェースカード３５やスピーチカード３６にも接続さ れている。インタフェースカード３５は、モニタ３７，キーボード３８及びマウ ス３９に切り替え接続して、操作者との交信を行えるようになっている。スピー チカード３６は、電話機４０と切り替え接続して、操作者が音声及び電話信号に よりシステムと交信できるようになっている。 スピーチカード３６を図４に詳細に示す。このスピーチカード３６は、電話線 インタフェース回路４１，制御プロセッサ４２，ＣＯＤＥＣ４３，ビットレート 変換器４４，及び音声抽出認識回路（音声の抽出及び認識を行う回路）４５を有 している。電話機４０で受け取された音声（スピーチ）は、電話線インタフェー ス４１に供給され、ＣＯＤＥＣ４３によって６４キロビット／秒のディジタル形 式に変換される。ＣＯＤＥＣ４３からの出力は、音声認識回路４５に供給される 。この音声認識回路４５は、メインプロセッサ３１から供給されたテンプレート データに応じ、特定の言葉やフレーズを識別するように構成されている。音声中 における特定事項の現れを示すデータは、認識回路４５によって検出され、制御 プロセッサ４２に供給されるようになっている。 ＣＯＤＥＣ４３からの音声は、またビットレート変換器４４に供給される。こ のビットレート変換器４４は、音声信号を圧縮し、ディスクドライブ３３上に効 率よく記憶する。同様に、音声によるメッセージは、ディスクドライブ３３上に 圧縮された形で記憶され、そしてＣＯＤＥＣ４３及びインタフェース４１を介し て電話機４０に伝送させるために変換機４４によって伸張される。電話機４０か らの信号はインタフェース４１によって翻訳され、該信号を定義するデータが制 御プロセッサ４２に直接供給される。 アプリケーション開発プラットフォーム上で動作するソフトウェアは、マイク ロソフト社が提供するＭＳ−ＤＯＳのようなオペレーティングシステム，同じく マイクロソフト社が提供するＷＩＮＤＯＷＳのようなグラフィカルオペレーティ ングシステム，及びＶｉｓｕａｌ Ｂａｓｉｃのような高レベル言語で記述され たサービス作成ツールを有している。但し、サービス設計者が上記ソフトウェア を使用することが特に重要であるというわけではない。 図２で示した種類のスピーチアプリケーションプラットフォームのためのサー ビスを設計する手順を、図５Ａ及び５Ｂに示す。 ステップ５１において、サービス構造が、フローチャートで相互に接続される 複数の機能ブロックによって定義される。グラフィカルユーザインタフェースは 、各ブロックの選択，位置づけ及び接続の処理を行うために使用される。ステッ プ５２において、ステップ５１で定義された構造が有効化される。すなわち、構 造が有効となっているかどうかを判別するため、ブロック間の接続の構造が解析 される。 もし、構造が有効となっていなければ、制御がステップ５３からステップ５１ に戻る。このため、サービス構造の再定義が行われ、有効な構造が生成されるま で再有効化が行われる。そして、制御がステップ５４に移る。ステップ５４にお いて、いずれかの制御ブロックがパラメータ入力が可能な状態にあるか否かが判 別される。もし、パラメータ入力が可能 な状態にあれば、ブロックの選択がなされる。ブロックのパラメータは、ブロッ クの処理に必要とされるデータの定義をするのに用いられる。例えば、サービス に対するコールが受け取られたときには、メッセージのテキストが発呼者に再送 される。 ステップ５５において、選択されたブロック用のパラメータは入力され、ステ ップ５６において、ブロック用の関連するテキストファイル内のパラメータ値が 更新される。これらのブロックパラメータは、スクリプト言語の規則に従って書 かれるようになっており、これによりテキストファイルは操作者によって理解で きるものとなる。ブロックパラメータは、任意と必須のうちどちらのものであっ てもよい。また、サービスに使用される全てのブロック内の必須のパラメータの 入力が完了するまで、システムは次のステージに進行しない。ステップ５４がブ ロックがパラメータ入力のためにブロックが選択されていないと判定するまで、 パラメータの入力が繰り返される。そして、制御が図５Ｂのステップ５７に移る 。 一度ブロックパラメータが入力されると、サービスが定義される。図５Ｂのス テップ５７は、サービス作成の次ステージ、即ちサービスシミュレーションを示 している。ステップ５７において、サービスシミュレーションはサービス作成プ ラットフォーム上で行われる。なお、このプラットフォームはステップ５１〜ス テップ５６を実行するハードウェアと同じものである。 ステップ５８において、ステップ５７で行われたサービス シミュレーションが成功したか否かが判別される。もし、成功しなければ、制御 がステップ５１に戻り、成功したサービスを定義できるようにするため、ステッ プ５１〜５６のサービス定義の再構築が行われる。 ステップ５８において、ステップ５７で行われたサービスシミュレーションが 成功したときは、個々のブロック用のスクリプトを含んだテキストファイルがス ピーチアプリケーションプラットフォーム上にロードされる。これにより、ステ ップ５９において上記プラットフォームによりサービスシミュレーションが行わ れることになる。また、ステップ５９においてスピーチアプリケーションプラッ トフォーム上で行われたシミュレーションが成功したか否かがステップ６０で判 別される。もし、成功しなければ、制御は再びステップ５１に戻る。これにより 、サービス作成プラットフォーム上でサービスが再定義されることになる。 このように、シミュレーションにおける２つのステージが存在している。すな わち、第１のステージではサービスが作成されている開発システム１で行われ、 第２のステージでは分割されたプラットフォーム上で行われる。この分割された プラットフォームは、そのためにサービスの設計がなされているスピーチアプリ ケーションプラットフォームであってもよい。一度シミュレーションに係る両ス テージが完全に成功すると、ステップ６０では制御がサービス作成の次ステージ 、即ち“コードの生成”に移る。 ステップ６１において、サービスを定義するスクリプトフ ァイルは、サービス作成プラットフォーム上へダウンロードが可能なＣ++に翻訳 される。Ｃ++は、高く移行し得る言語であるため、ステップ６１で生成されるコ ードは、種々のスピーチアプリケーションプラットフォーム上にダウンロードす るのに適しており、ハードウェア，ソフトウェア及びオペレーティングシステム について異なるコンフィギュレーションを持たせることが可能である。 ステップ６１で生成されたダウンロード可能なＣ++コードは、ステップ６２に おいてスピーチアプリケーションプラットフォーム内にロードされる。もし必要 であれば、ステップ６３において、関連するＣ++プログラムもプラットフォーム 内にロードされる。このため、サービス作成ツールにより生成された命令の中に 、スピーチアプリケーションプラットフォーム自体の上で実行される他の関連プ ログラムを含ませることが可能となる。 したがって、ステップ６４において、ロードされたＣ++プログラムは実行可能 なプラットフォーム特定コードに翻訳される。そして、ステップ６５において、 上記プログラムは、スピーチアプリケーションプラットフォーム上で動作できる ように配備される。これにより、上記スピーチアプリケーションを実行できる状 態にすることができる。 サービスの作成及び有効化 ステップ５１に先立ち、サービス生成の開始点を設定するため、サービス作成 プラットフォームが初期化される。初期化は、サービス作成ソフトウェアによっ て自動的に行われる。 これを図６に詳細に示す。 ステップ６６において、スクロールが可能なフローチャートキャンバスが作成 される。この場合、“ＷＩＮＤＯＷＳ”（商標）の下で供給されるオペレーティ ングシステムの一部として用意されたサブルーチンが使用される。そして、スク リーンのサイズよりも大きいウインドウを配置することによってスクロール可能 なウインドウが作成される。このとき、上記ウインドウの背後には、スクリーン 全体を占める第２のウインドウが配置されている。このため、スクリーンに関連 してクロールされるスクリーンエリア上のキャンバスよりも大きいキャンバスが 作成され、大きいウインドウは小さいウインドウに関連して移動することになる 。 ステップ６７において、機能作成ブロックのメニューが作成され、これにより 個々の作成ブロックが、スクロール可能なキャンバス上に配置するために選択さ れることになる。ステップ６８において、付加的プルダウンメニューが定義され る。このメニューは、パラメータ入力やサービス作成プラットフォーム上のサー ビス作成処理におけるナビゲーションを行うのに必要な種々のコマンドを提供す る。ステップ６９において、サービス名がサービス作成プラットフォームによっ て要求される。ユーザにより入力が行われた後には、サービス名はサービス作成 ソフトウェアによって読み出され、スクリーン上に表示される。ステップ６９の 後は、サービスを定義する環境を作成するために必要な全ての命令が実行され、 これにより操作者はサービスの定義に従って作業を進めてい く。 図７のサービス（ステップ５１〜ステップ５６）を定義するための手順を図７ に詳細に示す。ステップ７５において、マウス３９の操作により作成ブロックが 選択される。なお、このステップ７５には、表示されるカーソルがブロックメニ ュー内の特定のブロック上に現れるようにマウスを操作する処理も含まれている 。マウスのボタンを押してこれを押し下げた状態にすると、そのブロックが選択 されたものであることを識別できるように該ブロックの色が変更されるようにな っている。さらに、マウスのボタンを押し下げた状態でこれを移動させると、キ ャンバス上のブロックが“連動”する。一度位置付けがなされると、マウスのボ タンを解除したときに作成ブロックは効果的に解除される。これにより、そのブ ロックに相関するコピーがキャンバス上に残り、その後、ブロックの色が元の色 に戻る。 ステップ７７において、他のブロックが要求されているか否かが判別され、要 求されていれば制御がステップ７５に戻る。ここで認識しておくべきことは、使 用可能な作成ブロックの各々は、使用可能な空間に従って何度でもキャンバス上 にコピーされるということである。もし、フローチャートが非常に大きくて不十 分な空間がキャンバス上で使用可能となっているのであれば、サブキャンバスが 作成される。ここでは、このサブキャンバスをページと呼ぶ。 要求された作成ブロックがキャンバス上に配置され、ステップ７７において他 のブロックが要求されていなければ、作 成ブロック間の論理フローを特定するように論理リンクが定義される。 ステップ７８において、元の作成ブロックは、マウスを介してブロック上のカ ーソルの位置付けを行うことによって選択される。この後、選択されたブロック は、該ブロックが選択されたことを示すためにその色が変わる。 元の作成ブロックが選択された後、ステップ７９において、マウスの更なる操 作で目的の作成ブロックが選択される。目的の作成ブロックが選択された後、ス テップ８０において、元のブロックから目的のブロックへのリンクが行われる。 そして、元の作成ブロックの色は通常の色合いに戻る。処理の流れ方向は、矢印 の頭を用いた図形で再び表現される。このときの矢印は、元の作成ブロックから 目的の作成ブロックまでを指している。 ステップ８１において、元の作成ブロックにとって適当なかつ使用可能なリン ク名がプルダウンメニューから取り出され、そのリンク名が特定される。デフォ ルト名は、処理が正しく流れて次のステージに進行することを示す“ＯＫ”とす る。一方、単一の作成ブロックから複数のリンクが引き出される。例えば、作成 ブロックから２つのリンクが引き出される。第１のリンクは“はい”という返答 を表し、第２のリンクは“いいえ”という返答を表す。その他、数値の範囲や“ 真”及び“偽”のような論理状態で表現することも可能である。 ステップ８２において、他のリンクが作成されるべきか否 かが判別される。もし、作成するのであれば、制御がステップ７９に戻る。要求 された作成ブロックのコピーが全て完了し、必要なリンクの作成（ステップ８２ おいて他のリンクを作成しない場合）が完了した後、図５Ａのステップ５２に示 すように、有効化の手順が実行される。 ステップ５２に表された有効化の手順を図８に詳細に示す。ステップ８４にお いて、作成ブロックが出力リンクの正しい番号を有しているかどうかをチェック する。作成ブロックから発する出力リンクの番号が該作成ブロックにより実行さ れる機能に関連付けされる。このため、ソフトウェアは、定義された出力リンク の番号と、ブロックの論理機能によって予測される番号との間の不一致を検出す ることができるようになっている。但し、ここで注意すべきことは、この手法で は入力リンクの番号が推測できないということである。 ステップ８５において、いずれかの作成ブロックのリンクが二重になっている か否かをチェックする。このため、作成ブロックは、全体の構造として２つの出 力及び２つの出力が存在することが求められることになる。こうして、構造はス テップ８４で行われるテストを通過する。但し、例えば２つの出力を有している 場合、例えば“はい”及び“いいえ”を特定する出力リンクを有する必要がある 。この場合、上記の両リンクは“はい”として識別され、この二重の状態はステ ップ８５において識別される。 ステップ８６において、いずれかの作成ブロックが入力リンクを有していない か否かをチェックする。入力リンクが存 在しているとそのブロックを受け入れるように制御することができないため、失 敗が起こることになる。 コネクタブロックが存在しており、これはリンクの美観を改善する。また、コ ネクタブロックは、２つ以上の出力リンクを単一の入力リンクとなるように結合 するために使用される。但し、全てのコネクタは１つの出力及び少なくとも１つ の入力を有していなければならない。ステップ８７において、すべてのコネクタ が少なくとも１つの入力及び少なくとも１つの出力を有していることを保障する ためにチェックする。 ステップ８８において、複数の出力を有するコネクタが１つも存在しないこと を保障するためにチェックする。ここで注意すべきことは、コネクタは１つの出 力をもつことだけが可能であることである。これにより、コネクタからの出力は １つの方向に進むことだけ可能となる。図５Ａのステップ５３に示すように、も し有効化が成功すれば、ここでパラメータがブロックに入力される。 図６に詳細に示した初期化手順は、図９に示した種類の表示スクリーンの通り になる。スクリーンは、有効なブロックのメニュー９１及びスクロール可能なキ ャンバス９３を示している。キャンバスは、マウスポインタを表示された矢印９ ３，９４，９５又は９６上に位置付けることによりスクロールされる。矢印９３ を起動させると、キャンバスの上側の領域がウインドウを通じて表示されるよう に、キャンバスが下方にスクロールされる。同様に、表示された矢印９４を起動 すると、キャンバスの下側の領域がウインドウを通じて表示 されるように、キャンバスが上方にスクロールされる。同様に、矢印９５及び９ ６を起動した場合も、キャンバスが左、右にそれぞれスクロールされるようにな っている。このため、これらの矢印を起動すると、キャンバスのどんな領域もウ インドウを通じて表示されるように該キャンバスをスクロールすることが可能と なる。 ブロックメニュー９１から選択される作成ブロックは、“返答（Answer）”， “ハングアップ（Hangup）”，“ダイアルアウト（Dialout）”，“転送（Trans fer）”，“インフォ（info）”，“ＤＴＭＦ”，“質問（Query）”，“Ｙｅｓ ／Ｎｏ”，“記録（Record）”，“プレイ（Play）”，“外部（External）”， “スタッブ（Stub）”，“スイッチ（Switch）”，“テスト（Test）”，“コネ クタ（Connector）”，及び“ページ（Page）”といった各種のブロックからな る。 ブロックを含むフローチャートが定義されて有効化された後は、ページブロッ クを選択することによって他のページ上でブロックを作成することが可能である 。ページブロックが選択されると、そのブロックは、キャンバス上で表示される 他のブロックの場合と同様にキャンバス上で表示される。但し、上記ページブロ ック上でポインティングしている間にマウスのボタンをクリックすることによっ てそのページを選択すると、他のキャンバスページが表示され、これにより更な るブロックがその上にコピーされることになる。このため、ページブロックは低 レベルで完全なキャンバスを表示することができるようになっており、処理ブロ ックを記述するため のキャンバスが提供されることになる。 作成ブロックのパラメータは、マウスの適切な操作で特定のブロックを選択す ることによって入力される。これにより、特定のブロック用のブロック形式が開 かれる。ブロック形式は、ブロックに名称を与えることによりその構成を提供す る。この後、ブロックのパラメータは、それぞれ名付けられたブロックのテキス トファイルに書かれる。 各ブロックは、“ＯＫ”と記されたソフトボタンを表示する。マウスを使って このボタンを操作すると、プログラムが実行される。このプログラムは、ブロッ ク内に挿入されたパラメータをスクリプトの形でそれぞれのテキストファイルに 書く。 ブロックのために定義されたデータをテキストファイルに書く場合の例を図１ ０に示す。ステップ１０１において、操作者が各ブロック上の“ＯＫ”を選択す ると、ルーチンが開始される。ステップ１０２において、指定されたパラメータ が存在することを保障するためにチェックする。このため、ステップ１０２にお いては、ブロックが名称を与えられたことをチェックする。そして、該ブロック の処理に必要とされるパラメータが操作者により入力される。明らかに、これら のパラメータはブロックを特定するものであり、上記ブロックの各々を順番に詳 細に表している。もし指定されたパラメータが１つも無ければ、図１０に詳細に 示された処理手順が終了し、操作者は適切なブロック形式を通じてパラメータを 定義するように誘導される。 ステップ１０３において、ブロックに入力されたパラメータが有効となってい ることを保障するためにチェックする。このため、ブロック名は、適切な操作環 境においてファイル名として使用される文字により特定される。同様に定義され る継続時間は、許容された意味ある制約の範囲内で短くなる。 ステップ１０４において、テキストファイルは開けられ、拡張子“.TXT”で結 合されたブロックの名称によって識別される。この後、ステップ１０５において 、パラメータ値に応じてパラメータの名称を書くことにより、ステップ１０４で 開かれたファイルにテキストが書かれる。ステップ１０６において、他のパラメ ータが存在するか否かが判別される。もし存在すれば、制御がステップ１０５に 戻る。 最終的には、すべてのパラメータについての検討が行われて、ステップ１０５ において該パラメータが適切なテキストファイルに書かれる。これにより、ステ ップ１０６において他のパラメータが存在しなければ、制御がステップ１０７に 進む。ステップ１０７において、ブロックのテキストファイルが閉じられると、 制御は、図９に示すようにインタラクティブなグラフィカルユーザインタフェー スを構築するための処理に戻る。 ブロック形式の詳細 特定のブロック形式をこれから詳述する。この際に、図１０に詳細に示すルー チンを実行する際に生成されるテキストファイルも併せて説明する。ステップ１ ０５において実行される処理手順を参照する。ここでは、パラメータの名称と値 が関連するテキストファイルに書かれる。ここで注意すべきことは、パラメータ のスクリプト定義を含んだテキストファイルは、キャンバス上に配置されたブロ ックの各コピーごとに生成されるということである。特定のブロック名は、サー ビスの中で使用される特定のブロックごとにサービス設計者によって定義される 。 図１１Ｂ及びこれに関連する図面に示すように、説明のために行番号が添えら れている。なお、行番号は、生成される実際のスクリプトには存在しない。プロ トコルとしては、コンピュータ言語を定義する際に使用されるスクリプトに類似 するスクリプトの行を記述するためのものが採用される。イタリック体で書かれ たテキストは、文体に関連した名称又はパラメータを示しており、スクリプトの 形式的仕様の中では表すことのできないものである。四角形ブラケットで挟まれ たテキストは、動作を示しており、ブロック用スクリプトの特定位置に含まれて いてもいなくてもよい。 返答ブロック用の形式を図１１Ａに示す。返答ブロックは、サービスに対し、 入ってくるコールを待つように命令する。返答ブロック内で定義されるパラメー タから導き出されるテキストの完全なリストを図１１Ｂに示す。 情報が入力されて図１１Ａに示されるような形式になっている間、ヘルプボタ ン１１１が選択されるようにしてもよい。こうすると、経験の浅い操作者を援助 するためにテキストが表示される。同様に、特定フィールドにパラメータが入力 された後、キャンセルボタン１１２が選択されるようにしても よい。こうすると、そのフィールドの変更内容が消去される。関連する図に示す ように、ヘルプボタンとキャンセルボタンが各種ブロック形式において備えられ ている。 データが返答ブロックに入力された後、“ＯＫ”ボタン１１３の処理は、図１ １Ｂに示すようなフォーマットのデータを使ってスクリプトファイルの更新を開 始する。この種の“ＯＫ”ボタンは各ブロック形式内に備えられている。そして 、前述したように図１０に示す種類の処理手順が実行されることになる。 返答ブロックは、フィールド１１４内において特定の名称が付けられる。そし て、もし複数の返答ブロックがサービス中に存在するのであれば、上記ブロック が順に識別できるように異なった名称が与えられる。ブロック名は、図１１Ｂに 示すテキストファイルの１行目にあるブロック名識別子の後に挿入される。行の 最初の部分は、テキストファイルが、テキスト「tel answer_block:」で表され る返答ブロックに関連していると判別する。また、前述したように、“ＯＫ”ボ タンの実行の際には、最初の行がフィールド１１４で識別される特定のブロック 名とともに図１１Ｂの１行目に示されるテキストファイルに書かれる。 ブロックのタイムアウト期間はフィールド１１５で特定される。タイムアウト 期間は、ボタン１１６及びボタン１１７をそれぞれ使うことによって増減できる ようにしてもよい。一方、もしソフトトグル１１８がチェックされていない状態 のままであれば、システムはコールを受けるまで返答ブロッ クで有効に待ち続ける。このため、ブロックのタイムアウト期間は、コールが入 ってくるのをシステムが待っている間の時間を特定する。このタイムアウト期間 は、フィールド１１５に入力されてくる番号に応じて、「arg:"time to wait"」 の形でテキストファイルの２行目に書かれる。但し、もしソフトトグル１１８が チェックされていない状態のままであれば、２行目のテキストの両側に四角形ブ ラケットを添えることによって２行目はテキストファイルから省略されるように する。 同様に、呼び出しから返答までの時間がフィールド１１９において特定される 。これにより、実際に返答がある前に呼び出しのためのコールをシステムが許可 している間の時間を表す番号に応じて、データが「arg:"ring to ans time"」の 形でテキストファイルの３行目に書かれる。また、ソフトトグル１２０は、チェ ックされたときにだけデータが３行目に書かれるようになっており、これ以外の 場合にはデフォルト値が使用される。 サービスについて顧客に課金できるようにすることは可能であり、顧客のコー ルに対してサービスが返答したときから、すなわち、入ってくるコールを返答ブ ロックが応じたときから課金時間が始まる。ソフトトグル１２１がチェックされ たときには、そのコールに基づき顧客に課金するようになっている。この領域に おいては、図１１Ｂの４行目で特定されたデータは、「arg:"start billing"tru e」の形でテキストファイルに書かれる。一方、ソフトトグル１２１がチェック さ れなかった場合には、“真”は“偽”に置き換えられる。 領域１２２は、前スタッブ手順，前演算手順，後演算手順，及び後スタッブ手 順にそれぞれ対応するフィールド１２３，１２４，１２５及び１２６を有してい る。これらにより、テキストの各行が６行目から１４行目までにおいて定義され るようになっている。そして、同様な内容がサービス内に備えられたすべてのブ ロックの中で作成される。次に、領域１２２の使用について述べる。 領域１２２から導き出される記号がテキストファイルに書かれた後は、次のブ ロックに続くための状態が特定される。このため、もし返答ブロックの実行が成 功すれば、テキストファイルの１６行目は実行すべき次のブロックを識別する。 同様に、もし返答ブロックの実行が失敗すれば、１７行目は実行すべき次のブロ ックを識別する。ただし、ここで注意すべき重要なことは、これらの特定のブロ ックの名称は、返答ブロック形式の中では定義されないけれども、キャンバス上 で生成される構成図から導き出される。 テキストファイルは、「endblock」を特定している１８行目によってその最後 が締めくくられる。 ハングアップブロックの形式を図１２Ａに示す。ハングアップブロックは、サ ービスに対し、コールしている顧客との接続を解除するように命令する。このた め、ハングアップブロックは、コールしている顧客とサービス自身との間の通信 が終了した後、サービスを終える時に使用されることになる。ハングアップブロ ック形式の中で定義されるパラメータから 導き出されるテキストの完全なリストを図１２Ｂに示す。前述したように、行番 号は、サンプル中における特定の行を識別するという目的のためだけに備えられ ており、ファイル中のコードの絶対的位置を表しているわけではない。特別の名 称フィールド１３１が設けられるとともに、スタッブ及び演算領域１３２，ＯＫ ボタン，１３３，キャンセルボタン１３４，及びヘルプボタン１３５が設けられ ている。これらは、図１１Ａにおいて説明した各領域と同様のものである。これ らの領域もすべて関連するブロックの中に存在している。また、これらの動作に ついても図１１Ａを参照して説明した場合と同様である。 ある動作状態のもとでは、フィールド１３６においてハングアップの理由を識 別することが可能である。このフィールド１３６は、テキストファイルの２行目 に特定されている。スクロールバー１３７が設けられており、これを起動すると システムが有効なハングアップの複数の理由事項をスクロールすることになる。 これらのハングアッブ理由事項としては、通常，取得不可能，ビジー，サービス からの一時退避，渋滞や通信網の故障がある。 １６行目において、サービス内の次のブロックは、特定されて再びネットワー クの構成図から導き出される。そして、ブロック区切り文字「endblock」が１８ 行目のテキストファイルに書かれる。 ダイアルアウトブロックの形式を図１３Ａに示す。ダイアルアウトブロックは 、システムが他の電話番号にダイアルア ウトできるようにするものであり、このため、他のシステムから情報を得ている ときやコールを転送しているときなどに使用される。 ダイアルアウトの番号、又はダイアル番号を得ることのできる場所を識別する 変数は、領域１４１において特定される。これにより、「arg:"hangup reason" 」の形の命令が、ダイアルされた番号又は変数の識別子を伴って２行目に書かれ ることになる。 ブロックは、２重音声の多重周波数モード又はループ非接続モードでダイアル アウトすることができる。マウスで領域１４２が選択されるように、又は独占的 にマウスの操作で選択されるように、ソフトトグルが設けられている。図１３Ａ に示すように、領域１４２が選択された後、マウスで適切に操作する。これによ り、領域１４３はチェックされ、領域１４２はチェックされないことになる。ダ イアルモードを選択すると、「arg:"dialing mode"」の形の命令が、多重周波数 を示す識別子”M”又はループの非接続を示す識別子”L”を伴って３行目に書か れることになる。 期間については、領域１４４において設定されることになる。このとき、返答 するためにシステムがコールを待つのにかかる時間が特定される。もしフィール ド１４５がチェックされていない状態であれば、フィールド１４４における図形 を入力する必要はなく、呼び出し時間のデフォルト値が使用される。フィールド １４５をチェックすると、フィールド１４４に入力された値は、選択された番号 に従って、「arg:"r ing tone cl time"」の形で４行目の動作命令の中に含まれることになる。呼び 出し時間の選択は、スクロールバー１４６の操作によりなされる。このとき、閉 じた組の有効オプションだけに基づいて上記期間が定義されるように操作する。 次のブロックのオプションは、１６行目と２１行目の間のテキストファイルに 書かれる。このとき、オプションは通信網の構成図から導き出され、最終ブロッ クの区切り文字が２２行目に書かれる。 転送ブロックの形式を図１４Ａに示す。転送ブロックは他の電話線と連絡し、 もし成功したならば、コールしている顧客をその電話線に転送する。ダイアルフ ィールド１５１の番号は、図１３Ａのフィールド１４１に実質的に類似しており 、類似した命令がテキストファイルの２行目に書かれることになる。同様に、応 答期間がフィールド１５２において特定される。これにより、類似した命令がテ キストファイルの３行目が書かれる。また、次のブロックの状態がテキストファ イルの１５行目と１９行目の間に書かれ、最終ブロックの区切り文字が２０行目 に書かれる。 インフォブロックの形式を図１５Ａに示す。インフォブロックは、コールして いる顧客に情報を供給する。このブロックは、高頻度で選択されて利用されるも のである。インフォブロック形式の中で定義されるパラメータから導き出される テキストの完全なリストを図１５Ｂに示す。特別なブロックの名称がフィールド １５３において特定されると、「info-block:」の形の命令が、上記名称を伴っ てテキストファイルの １行目に書かれる。ソフトトグル１５４がチェックされたときには、キー促進バ ッファが駆動される。このキー促進バッファは、コールしている顧客が前にキー パッド操作で選択した識別子を含んでいる。これにより、「arg:"flush buffer" 」」の形の命令が、ソフトトグル１５４がチェックされたか否かを示す“真”又 は“偽”を伴ってテキストファイルの２行目に書かれる。 領域１５５は、メッセージの詳細を含んでいる。ここで２種類のメッセージが 定義される。通常のメッセージはソフトボタン１５６が選択されるときに定義さ れる。そして同様に、高速トラックメッセージはボタン１５７が選択されるとき に定義される。高速トラックメッセージは、そのサービスに通じている顧客又は この種のサービスに通じている顧客に対してシステム動作を高速化する。 メッセージデータ又は音声認識データを含むテキストファイルは、２つの部分 に分けられる。そして、最終的には、完全なスクリプトがサービスページごとに ２つのページによって特定されることになる。このとき、スクリプトには、論理 動作を定義しているページファイル及びメッセージと認識データを有する形式フ ァイルが含まれている。 これにより、次のブロックのコマンドは１４行目と２０行目の間に書かれる。 この後、２１行目において、最終ブロックの区切り文字が特定される。 形式情報が２３行目以降に特定される。このため、２３行目は、ブロック名に 従った命令「info-form」による形式情報 の始まりを示している。 通常の動作においてコールしている顧客への音声メッセージは、フィールド１ ５８において特定される。そして、システムエラーメッセージは、フィールド１ ５９において特定される。フィールド１５８内でメッセージが特定されると、「 message:」の形の命令が、特定メッセージの各々について予め定義されている順 番で、反転コンマ内の特定メッセージデータを伴って２４行目に書かれることに なる。同様に、もしシステムエラーがフィールド１５９内に特定されると、「sy stem error:」の形の命令が、反転コンマ内のシステムエラーテキストを伴って ２５行目に書かれることになる。これは、ブロック用のメッセージ情報の最後を 構成している。したがって、テキストファイルは、２６行目における命令最終形 式によって区切られることになる。 ＤＴＭＦブロックの形式を図１６Ａに示す。ＤＴＭＦブロックは、コールして いる顧客からのＤＴＭＦ信号、即ち押音信号を受信するようになっている。この 後には、ＤＴＭＦブロックは、受信した情報に応じて判別を行う。このため、多 くのアプリケーションにおいては、処理されるべき次のブロックは、コールして いる顧客からキーの押下げという形で受信される実際の情報に依存している。Ｄ ＴＭＦブロック内で定義されるパラメータから導き出されるテキストの完全なリ ストを図１６Ｂに詳細に示す。 ブロック名がフィールド１６１において特定されると、命令「DTMF-block」が 、ブロック名を伴って１行目に書かれ、 また、命令「DTMF-form」が、ブロック名を伴って３７行目に書かれることにな る。このため、論理動作に係る命令は１行目に続いて書かれる。この後、メッセ ージ情報は、３７行目に続いて書かれる。 パラメータ領域１６３内のソフトトグル１６２は、キー促進バッファを駆動す る際に操作者がこれを選択できるようになっている。これにより、「arg:"flush buffer"」の形の命令が、“真”又は“偽”の識別子を伴って２行目に書かれる ことになる。 ＤＴＭＦブロックは、所定数のディジット又は可変の数のディジットに返答す ることができる。このため、特定のブロックが可変の数のディジットに返答すべ き場合にはソフトボタン１６４が選択され、そのブロックが所定数のディジット に返答すべき場合にはソフトボタン１６５が選択される。ボタン１６５が選択さ れると、システムが返答する実際の数のディジットがフィールド１６６内で特定 される。 これにより、「arg:"max digits"」の形の命令が、期待されるディジットの最 大数を表す番号を伴って３行目に書かれることになる。 ソフトトグル１６７をチェックすると、無音休止期間がフィールド１６８にお いて特定される。これにより、「arg:"pre time out"」の形の命令が、休止期間 の識別子を伴って５行目に書かれる。このため、ブロックは、入ってくる音声に 対し、無音休止により特定される期間だけ待つことになる。一方、もしソフトト グル１６７がチェックされなければ、無 音休止のデフォルト期間が使用される。 ＤＴＭＦブロックに関して重要なのは、特定のＤＴＭＦ音声を受けた後の処理 の定義である。この情報は、システムの構成図（トポロジー）の中で定義されて いる。そして、この構成図の解析により、命令が、３５行目におけるブロック区 切り文字を伴って１８行目と３４行目の間に書かれることになる。 前述のように、３７行目は、形式情報の始まりを特定している。第１プロンプ トはフィールド１６９に特定される。これにより、「pl:」の形の命令が、第１ プロンプトメッセージを伴って３８行目に書かれる。第２プロンプト、ヘルプメ ッセージ、音声不明確、音声無し及び失敗メッセージもまた特定できるようにな っている。これにより、命令が４７行目のところまで各行に書かれることになる 。最終的に、ファイルの最後が５０行目において区切り文字「endform」で特定 される。 質問ブロックの形式を図１７Ａに示す。このブロックは、メッセージプロンプ トに対する発呼者の返答を得るために使用される。これにより、発呼者はサービ スと言葉で交信することができる。例えば、クレジットカード上の番号を読むこ とで行われる。ソフトトグル１７１には、ビープ音をオン／オフするスイッチが 設けられている。このビープ音は、話しているときに発呼者に対して合図するも のである。このソフトトグルがチェックされると、図１７Ｃの４５行目は、生成 される形式ファイルの中に含まれる。音声認識の処理を最適 化するためのソフトトグルは、ディジット最適化機能１７２及びＺＳＭＬ（ゼロ 空間ミディアム長）最適化機能１７３のために設けられている。ディジット最適 化は、期待される応答が言葉による“０”から“９”までの個々のディジットを 含むようにすることを意味する。そして、ＺＳＭＬ最適化は、ユーザがディジッ トの間で話を休止しないようにすることを意味する。ディジット及びＺＳＭＬの 最適化機能は、図１７Ｂの３行目と４行目にそれぞれ示すコマンドによって選択 される。 音声認識テンプレートは、フィールド１７４において特定される。この際、入 ってくる音声パターンと比較するためのテンプレートが応答可能な範囲を有する ように特定される。例えば、音声認識ソフトウェアが１０種の異なる言葉（この 場合、“０”から“９”まで）だけを区別できるように特定される。音声認識テ ンプレートは、図１７Ｃの２９行目から３８行目において一連の確実な返答に相 当する行として特定される。言葉が認識されると、それはフィールド１７５にお いて入力される名称により特定される可変ストリングに置かれる。そして、それ が図１７Ｂの５行目に特定される。 話し手の属性は、フィールド１７６においてソフトトグルボタンを使うことに より選択される。この際、認識処理が話し手と独立しているときに扱われるよう に話し手の広い範囲のスタイルに対応するというよりも、より複雑な話音が特定 の個人から認識される。パラメータボタン１７７を選択することにより、話し手 の属性のための詳細なパラメータが特定 される。これにより、パラメータを特定するための追加ウインドウがユーザに提 供されることになる。これら追加パラメータは、図１７Ｂの６行目から１４行目 に特定される。記録会話フィールド１７８は、実際の音声を数値化し、ファイル に記憶させる。記憶されたものは、アプリケーションプラットフォーム上の他の ブロックやプログラムによって順次参照されることになる。例えば、これは、自 動化電話返答システムの一部として使用される。このシステムでは、顧客が自分 のメッセージを後でプレイバックできるようにするために各メッセージが記録さ れる。記録音声データは、図１７Ｂの１５行目から１８行目において特定される 。不明確な音声や沈黙に適切な応答を定義するために、“音声不明確”及び“音 声無し”メッセージフィールドが質問ブロックに設けられる。 図１８Ａに示すＹＥＳ／ＮＯブロックは、上述の質問ブロックに類似した機能 を提供する。このブロックにおいては、たった２つの言葉、即ち“はい”と“い いえ”が認識され、これにより音声認識が簡単化され、話し手の認識やＺＭＳＬ のためのモードが不要となる。他のすべての点に関しては、このブロックの動作 は質問ブロックの場合と同じである。ＹＥＳ／ＮＯブロックのためのスクリプト の詳細を図１８Ｂに示す。 図１９Ａに示す記録ブロックは、発呼者のメッセージを記録するために使用さ れる。このブロックでは、特定されたメッセージプロンプトが最初に実行される 。数値化された音声がフィールド１７９の特定されたファイルの名称がフィール ド１７９に特定される。数値化された音声ビットレート又はＰＣＭレートは、フ ィールド１８０において特定される。例えば“クレジットカードのアドレス”の ような音声ファイルの内容を記述するために、記述者フィールドが設けられてい る。もしくは、このフィールドでは、例えば“本日あなたの２度目のコールは、 ”のような、前に特定された記述者ストリングを含む変数が特定される。 数秒内におけるメッセージの最大長さと、ブロックが消失する前に許容される 無音の最大長さとをそれぞれ定義するため、記録時間と終了時間が特定される。 “長いメッセージ受入れ”トグルは、チェックされたときに、発呼者が記録メッ セージの最大長さよりも長く話した場合にブロックが失われる状態が発生するこ とを防止する（すなわち、このとき制限時間を越える会話が放棄される）。記録 ブロックによって生成されるスクリプトが図１９Ｂのように特定される。 プレイブロックを図２０Ａに詳細に示す。このブロックは、特定されたファイ ル内の１又は複数の予め記録されたメッセージ、例えば記録ブロックの実行によ り生成されたものを再生する。複数のファイルの名称は、ファイル名フィールド １８２において特定されることになる。プレイブロックにより生成させるスクリ プトは、図２０Ｂにおいて特定される。 外部ブロックを図２１Ａに示す。このブロックは、外部の実行可能プログラム （即ち．exeプログラム）との２通りの通信する手段を提供する。例えば、外部 ブロックは、会社のデータベースプログラムへのコールを行うことが可能である 。 この場合のコールには、発呼者の名前と顧客の番号を持つ引数が含められる。そ して、データベースは顧客の詳細について調べ、顧客の会社での業務に要した費 用の請求を示す電流レベルのような特定データを含む情報を返す。外部ブロック により生成されるスクリプトは、図２１Ｂにおいて特定される。 スタッブブロックを図２２Ａに示す。このブロックは、ＡＮＳＩのＣ又はＣ++ ソースコードをグラフィカルユーザインタフェースのレベルでのアプリケーショ ンに挿入させる。Ｃ又はＣ++ソースコードは変数を操作し、ブロックプログラム の他の部分によってコールルーチンが参照される。但し、このレベルで操作をす るにあたっては、アプリケーション開発プラットフォームにより生成されるＣ又 はＣ++オペレーティング環境についての詳しい知識が必要とされる。ヘッダファ イル、ライブラリファイル及び前翻訳オブジェクトファイルは、スタッブブロッ ク内に供給されるＣ又はＣ++コードによって参照するために、すべてが特定され る。このため、Ｃ又はＣ++コードは、外部ブロックに与えられるデータベースサ ンプルのようなコンプリヘンシブユーティリティソフトウェアにアクセスするた めに使用される。 Ｃ又はＣ++レベルでこの種の機能にアクセスできるようにすると、ユーザ定義 のＣ又はＣ++コード、ユーティリティソフトウェア及びシステムソフトウェアは 、それぞれがお互いに効率的に参照し合い、また、同時にコンパイルされる。こ れにより、手動及び自動による最適化が、Ｃ又はＣ++コード 上でコンパイル前に実行されるようになる。そして、高速かつより効果的な実行 時間のソフトウェアが実現される。 さらに、全体のシステムがＣ又はＣ++で特定され、続いてＣ又はＣ++レベルで 変形されるにつれて、Ｃ又はＣ++コードを変形させることでサービスを変形させ ることを望むサービス提供者にとっては、柔軟な操作が行えることになる。スタ ッブブロックにより生成されるスクリプトは、図２２Ｂにおいて特定される。 スイッチブロックを図２３Ａに示す。このブロックは、サービス内で次に続く ことが可能なブロックを選択するための状態テストを提供する。フィールド１８ ３における表示文字は、Ｃ言語のような言語に従って求められる。もしこの結果 がゼロであれば、ブールの標識子が“真”が得られる。もしゼロでなければ“偽 ”が得られる。制御フローは、ユーザ定義によるリンクラベルの特定値に従って 変換（スイッチ）されることになる。この場合、変数を取り得る各値には、ユー ザ定義によるリンクラベルが要求される。スイッチブロックにより生成されるス クリプトは、図２３Ｂにおいて特定される。 テストブロックを図２４Ａに示す。このブロックは、結果として“はい”（ゼ ロ）又は“いいえ”（ゼロでない）だけが求められるということを除き、上述の スイッチブロックに類似している。テストブロック用に生成されるスクリプトは 、図２４Ｂにおいて特定される。 特定サービスの動作例 サービスの実際の動作例を参照して、図５Ａに表されたサービス作成手順を以 下に説明する。これから述べるサービスは、音楽コンサート等のパフォーマンス に関する情報を得るため、コールしている顧客が特定の番号を呼び出せるように する。サービスは、そのこと自体を識別するとともに、パフォーマンスの動向を 識別する情報を得るべくボタン１を押すように、又は、座席予約の有効性を識別 する情報を得るべくボタン２を押すように、コールしている顧客を誘導する。い ずれかの種類の情報が提供された後は、システムはハングアップする。このため 、このサービスは、ここでは単にサービスがどのように作成されるかを示す一例 として表されているものと理解されたい。実際に動作するこの種のサービスにお いては、単一コールから両方の種類の情報が有効となるようにループが含まれて おり、より洗練されたものとなっている。この場合、コールしている顧客は座席 を予約したり、将来行われるパフォーマンスに関する情報を得たりすることがで きるようになっている。 図５Ａのステップ５１に表されているように、第１のステップは、グラフィカ ルユーザインタフェース内でサービス構造を定義することからなる。このため、 図６に示すように、初期化手順の後は、作成ブロックメニューとプルダウンメニ ューとともにスクロールキャンバスが作成される。そして、サービス名が定義さ れ、図９に示すような種類のキャンバスが表示される。 上述のサービスを作成するためには、入ってくるコールに 返答する返答ブロックをメニュー９１の中から選択する必要がある。この後、Ｄ ＴＭＦブロックを選択する必要がある。このＤＴＭＦブロックは、キーパッドに よる選択を行うように顧客を誘導し、この後、ディジット１を表す信号の入力と ディジット２を表す信号の入力とに応じる。入力してくるディジット１に応答す るためには、インフォブロックが求められる。このインフォブロックは、コール している顧客（特定の日に有効となっているパフォーマンスの種類を調べる顧客 ）に対して情報をそれぞれ伝達する。この後、システムはハングアップする。そ して、ハングアップブロックをシステムに含める必要がある。ディジット２を表 す入力信号に応答するためには、座席予約の有効性に関する情報を得る必要があ る。明らかに、このデータは、規則的な規範にしたがって更新されることを必要 としている。したがって、システムが座席予約のトラックを保持するデータベー スと通信するように構築される。外部データベースへのコールは、開発されるべ き追加のコードを必要としている。そして、このコードは、外部ブロックもしく は独立したスタッブブロックを設けることによって、又は、前スタッブもしくは 後スタッブブロックを設けることによって、システム全体の中に含められる。情 報が受け取られた後は、この情報をコールしている顧客に伝達するため、第２の インフォブロックが必要とされる。この後、システムが再びハングアップする。 ハングアップブロックは、多くの入力リンクを受ける。従って、１つのハングア ップブロックを指定することだけが必要になる。 上述のサービスを構築する構成図を図２５に詳細に示す。サービスは開始ブロ ック１９１により開始される。このブロックは、システムによって自動的に提供 され、特定の名称“and 1”が与えられた返答ブロック１９２へのＯＫリンクを 有している。ＯＫリンクは、返答ブロック１９２を、特定の名称“dtmf1”が与 えられたＤＴＭＦブロック１９３に接続する。 ＤＴＭＦブロックにおいては、顧客が選択したディジット“１”に応じ、制御 がＤＴＭＦブロック１９３から特定の名称“info1”が与えられた第１インフォ ブロック１９５に向けられる。このとき、ＤＴＭＦブロック１９３とインフォブ ロック１９５の間のリンクには、リンク名“１”が与えられている。 同様に、ＤＴＭＦブロック１９３と外部ブロック１９４の間のリンクには、リ ンク名“２”が与えられている。そして、前記外部ブロック１９４には、特定の 名称“extn1”が与えられている。ブロック１９４からのＯＫリンクは、それを “info2”で表される第２インフォブロックに接続する。このブロックは、外部 ブロック１９４でなされた外部コールから得られた顧客への情報をリレイする。 この情報が顧客にリレイした後は、システムがハングアップする。そしてこのこ とが、インフォブロック１９６をハングアップブロック１９７に接続する“ＯＫ ”リンクによって反映される。 ＤＴＭＦブロック１９３も、“fail”リンクによりハングアップブロック１９ ７に接続されている。このため、顧客がディジット“１”又は“２”を与え損ね た場合には、失敗状 態がＤＴＭＦブロック１９３により識別され、システムはハングアップブロック １９７の制御のもとでハングアップする。ハングアップブロック１９７には、特 定の名称“hang1”が与えられる。この後、制御がエンドブロック１９８に向け られる。 図２６に示すサービス構成図の外形が特定された後は、図５Ａのステップ５２ に表されているように構造が有効化される。これは、内的に矛盾がなく、十分に 特徴づけられたサービスが開発されるようにするためである。図２５に示す構造 においては、ステップ５３における質問に対して肯定的な返答が返されなければ ならない。この後、ステップ５５においてパラメータ入力のためにブロックが選 択され、ステップ５６においてテキストファイルが更新される。 どんな順序でもパラメータ入力のためにブロックが選択できるようになってい る。さらに、ブロック形式がコールされた後は、どんな順序でもパラメータはそ のブロックに入力できるようになっている。図１１Ａに示すボタン１１３のよう な関連する“ＯＫ”ボタンによれば、パラメータは、図１１Ｂにおいて特定され ているようにスクリプトコード化されたパラメータを含むテキストファイルに書 かれることになる。但し、ブロックパラメータは変更できようようになっており 、関連するテキストファイルも同様にＯＫボタンの更なる操作より変更可能であ る。但し、この例では、ブロックのパラメータ化は、特別のシーケンスで記述さ れる。そして、サービスを完成させる操作者によって実際に実行されることにな る。 返答ブロック１９２が選択されると、図１１Ａに示す種類の返答ブロック形式 が表示される。この特別の例のための返答ブロック形式を図２６Ａに示す。ブロ ック名“ans1”がブロック名フィールドに入力されると、図２６Ｂに示すテキス トファイルの１行目に命令「tel_answer block:ans1」が書かれる。ブロックタ イムアウトのソフトトグルがチェックされていないと、サービスは、コールが行 われるまで返答ブロックにおいて待ち続ける。この結果、関連するコードがテキ ストファイルに書かれる必要はなくなる。 呼出しから返答までの時間は、ブロック形式において特定される。これにより 、テキストファイルの次の行において命令「arg:"ring to ans time" 3」が含 められることになる。同様に、課金開始ソフトトグルがチェックされる。これに より、テキストファイルの次の行において命令「arg:"start billing" true」が 含められることになる。 演算機能もスタッブ機能も定義されていない場合、次の行は、次のブロックへ の指示を含んでいる。そして、最後の行には、最終ブロック区切り文字が添えら れる。 返答ブロックのＯＫボタンを選択した後は、図２７Ａに示すようにテキストフ ァイルが変更され、ＤＴＭＦブロック１９３が選択され、パラメータがそこに追 加される。ブロック名“dtmf1”が特定されると、関連するテキストファイル「d tmf block:dtmf1」のための最初の命令が生成される。 キー促進バッファを駆動するためのソフトトグルが設定されると、テキストフ ァイルの次の行を「arg:"flush buffer" true」に特定する。同様に、ディジットストリングは所定のオプションに設定さ れ、ディジットの最大数が“１”において特定される。このため、図２７Ｂに示 すテキストファイルの次の行は、命令「arg:"max digits" 1」を含んでいる。 無音タイムアウトトグルが設定され、無音タイムアウト期間が８秒に特定され る。このため、テキストファイルの次の行は、命令「arg:"pre-time out" 8」を 含んでいる。 ＤＴＭＦブロックは、番号の付された複数のフローの行のうち１つに制御フロ を向けさせる。このため、もし発呼者がキーパッド上で“１”を押すと、流れは “１”の付されたフローの行に向けられる。同様に、流れが“２”の付されたフ ローの行に向けられる。これらを可能とするスクリプトを示す。 プロンプト情報の開始は、命令「dtmf-form:dtmf1」により特定される。テキ ストファイルの次の行は、第１のプロンプトメッセージフィールドに入力された プロンプトメッセージを含んでいる。このため、第１のプロンプトメッセージフ ィールドを選択した後は、“今夜のコンサートの詳細についてはボタン１を、座 席予約の有効性についてはボタン２を押してください。”のような適当なメッセ ージが挿入される。このため、次の行において命令「pl:dtmf-form:dtmf1」が続 くことになる。システムエラーメッセージについても、“申し訳ありません。技 術的故障が起こりました。”の形でシステムエラーフィールドに含められる。こ のため、「system error：sorry there is a technical fault"」の形でテキス トの 行に示される。これにより、テキストファイルの最後と特に形式情報の最後は、 命令"end form"によって識別されることになる。 インフォブロック１９５が選択されると、インフォブロック形式が表示される 。これには、図２８Ａに示すようにデータが付加される。これにより、図２８Ｂ に示すような特定のテキストファイルが生成される。 外部ブロック１９４が選択されると、外部ブロック形式が表示される。この中 には、図２９Ａに示すように特定のコマンドが入力される。これにより、図２９ Ｂに示すようなテキストファイルが生成される。 インフォブロック１９６が選択されると、インフォブロックのための形式が表 示される。これには、図３０Ａに示すようにパラメータが入力される。これによ り、図３０Ｂに示すようなテキストファイルが作成される。 ハングアップブロック１９７が選択されると、ハングアップのための形式が表 示される。図３１Ａに示すようにパラメータがハングアップブロック形式に入力 されると、図３１Ｂに示すようなテキストファイルが生成する。 従来においては、特定のスピーチアプリケーションは、記述されたスクリプト によって定義されていた。そして、動作させるための言語はプログラマによって 手作りで書かれていた。このため、スクリプトに応じ、プログラマは、アプリケ ーションプラットフォーム上で直接実行できる形でコードを作成するか、又は、 Ｃ又はＣ++のような中間言語の中でコー ドが生成される。これにより、異なる種類のアプリケーションプラットフォーム 上に上記コードがダウンロードされることになる。本システムにより生成される ページファイルは、オペレータにとって有意の形となっており、周知のスクリプ ト言語に似ている。このため、本システムの第１段階における主要な面は、グラ フィカルユーザインタフェース内で定義される命令をスクリプトファイル（ここ では、人と機械の両方が読むことのできるページファイルやフォームファイルを いう）に変換するということであると考えられる。 サービスがフローチャートとして完全に定義され、記述されたすべてのブロッ ク形式の中にパラメータが入力された後は、サービス作成における次の段階では 、複数のテキストファイルが翻訳される。そして、パラメータ入力している間に 、特定のブロックのために各々がページファイル及びフォームファイルの中に生 成される。この例では、１つのページファイルと１つのフォームファイルだけが 全体のサービスを定義するために生成される。但し、ここで注意すべきことは、 追加スローチャートを低いレベルで定義するのにページブロックが使用されるよ うなより複雑化したフローチャートにおいては、単一のページファイル及び単一 のフォームファイルが各レベルでのフローチャートのために生成されるというこ とである。これは、使用されるキャンバスの“ページ”ごとのページファイルで あるものと考える。そして、ページファイルとフォームファイルは常に一緒に生 成される。多重のページファイル及びフォームファイルが生成される場合、ペー ジ ファイルの１つはマスターページファイルとなる。そしてこれは、ファイル名、 即ち“THEATRE.PGE.”の一部としてのサービスの名称を有していることで示され る。 拡張子”.PGE”を有するページファイルは、すべての“.TXT”ファイルからの ブロック機能スクリプトのコピーを含んでいる。ブロック機能スクリプトは、テ キストファイル内において例えば“query_block:”と“endblock”区切り文字と の間に含まれるスクリプトの部分に相当する。このため、ページファイルは、サ ービス設計者が読むことが可能でかつ直接Ｃ++コードに翻訳するのに適したスク リプト言語で書かれたサービス全体の機能的記述を提供する。 拡張子“.FRM”を有しているページファイルは、すべての“.TXT”ファイルか らのブロックフォームスクリプトのコピーを含んでいる。ブロックフォームスク リプトは、テキストファイル内において例えば“query_form:”と“endform”区 切り文字との間に含まれるスクリプトの部分に相当する。フォームファイルは、 合成された音声として発呼者のところに再生されるテキストデータを供給する。 この再生は、ページファイルの動作部分の一部に対応する。ここで注意すべきこ とは、すべてのブロックがフォームデータを生成するというわけではないことで ある。 このため、ページファイル及びフォームファイルは、ともに動作及びサービス の完全なページを作成するために必要なデータを定義する。この例では、フロー チャートのページが１つだけ使用されるため、ページファイルとフォームファイ ルはともに全体のサービスを定義する。 ページファイル及びフォームファイルを作成するための手順を図３３に詳細に 示す。ステップ３０３において、定義されることを必要とするフローチャートが 他にあるか否かを調べる。もし“いいえ”であれば、“.PGE”ファイルや“.FRM ”ファイルを作成する必要はない。そして、制御フローが図５Ｂ（サービスシミ ュレーション）のステップ５７に向けられる。もし新たなページが定義されるべ きときは、制御はステップ３０４に向けられる。論理ブロックの順序を作成する ためにブロック間の接続が解析される。これにより、ページファイルに含まれる スクリプトから結果的に生成されるＣ++プログラムの階層構造が自由に表される 。 ステップ３０５において、ページファイル及びフォームファイルにコピーされ るべき他の作成ブロックがリスト中に残っているか否かを調べる。もし“いいえ ”であれば、制御はステップ３０３に戻る。もし“はい”であれば、制御はステ ップ３０６に向けられる。ステップ３０６において、特定のブロックを含むテキ ストファイルはその内容が読めるように開かれる。このステップ３０６において は、 “xxxx_block:”から“endblock”区切り文字までの間にあるテキストは 、現ページファイルにコピーされる。ステップ３０７において、“xxxx_form:” から“endform”区切り文字までの間にあるテキストは現フォームファイルにコ ピーされる。このため、ページファイルとフォームファイルは、ブロックパラメ ータの入力の間に生成されたテキストファイルから作成される。こ のようにして劇場チケットの例に基づいて作成されたページファイルを図３４に 示す。そして、その対応するフォームファイルを図３５に示す。 スタッブコードを用いて拡大したブロック機能 スタッブ機能は、スタッブブロック又は前ブロック及び後ブロックスタッブと いった付属物を使用することにより、フローチャート上のシステム設計に挿入さ れる。スタッブコードは、Ｃ又はＣ++で書かれたコードであり、予めプログラム された機能ブロックにより、備えられた機能の幅を拡大するために使用される。 そして、サービス設計者は、予めプログラムされた機能ブロック（サービス作成 ツールの一部として提供されるもの）に妨害されることがない。サービスが自動 的にスクリプトファイルからＣ又はＣ++命令に翻訳されるとき、スタッブコード がその生成されたＣ又はＣ++プログラムの適当な位置に挿入される。 このため、サービス作成ツールは、プログラミングを柔軟に行えるようにする 。一方、スクリプトをＣ又はＣ++に翻訳するという負担のかかる作業は、自動的 に行われることになる。 図２５に示す外部ブロック１９４は、Ｃ又はＣ++コードの行を含むスタッブブ ロックに置き換えることが可能である。 これを行うに当たり、いくつかの理由が考えられる。外部ブロックによりコー ルされる外部プログラムを、Ｃ又はＣ++で書かれたサブルーチンに全面的に置き 換えることは可能である。このため、サービスは、他のソフトウェアを参照する ことなく内部で矛盾のないものとして広く定義される。これにより、速度の面で 効果があり、デバック能力が向上し、より柔軟な操作性が実現される。 図３５は、図２５に示すサービスと同じものの例を示している。但し、外部ブ ロックは、スタッブブロック３５１で置き換えられている。このため、スタッブ ブロックは、予め外部ブロックを用意して局所的なＣ／Ｃ++を使用することによ り、同一の機能を実行する。これにより、完全に分離したプログラムの中で命令 が実行されることになる。 図３６は、スタッブブロック形式、及び、データベースから劇場の座席予約の 有効性について検索する処理を実行するＣ／Ｃ++コードの例を示す。スタッブブ ロックは、ヘッダとサービスのためにＣ又はＣ++プログラム全体に含ませるため のライブラリファイルとをプログラマーが定義できるようにする。従って、特殊 化された動作のために必要なサブルーチンを提供するために、ソフトウェア開発 者により予め作成された機能の特殊化したライブラリが含まれている。この例で は、データベースのヘッダが選択される。このヘッダは、データベースの作成、 アクセス及び操作のための機能のライブラリへのアクセスを定義している。図示 されたスタッブブロックの例においては、「#include <database.h>」の行は、 「database.h」と「database.lib」と呼ばれるルーチンのライブラリへのアクセ スを定義している。 Ｃ／Ｃ++コードは、変数の宣言として「theatre *Index;」を含んでいる。こ れは、劇場の記録を格納するために構築さ れたデータベース内の変数に対するポインタとして使用するポインタ「*Index」 を宣言している。その機能は、 「lookupRecord(*THEATRES,"MADISON",CurrentDate,*Index);」 となっている。すなわち、定常ストリング変数「THEATRE」により定義されるデ ータベース内の記録を参照すること、その名称フィールド内で“MADISON”を有 する劇場のための特定の記録、及び、システム変数「CurrentDate」と同じ値を 有するフィールドに対する記録中にある情報を探すこと、である。日付けに係る フィールドのサブセットに含まれる情報は、「*Index」の値を更新することによ り戻される。これにより、上記情報がポイントされることになる。動作は、 「seats = Index.availabilitty;」 となっている。このとき、インデックス構造の有効性エレメントの中における値 が座席の変数に割り当てられている。これにより、サービス内で他のブロックを アクセスすることができるようになっている。 スタッブブロック例によって生成されるスクリプトを図３６Ｂに示す。これは 、図２２Ｂに詳細に示すスタッブブロックのスクリプト定義と比較されることに なる。 データベースの動作を実現するための第２の方法は、図３７に再び示すように 「info2」ブロック１９６のための前ブロックスタッブの中にＣ／Ｃ++コードを 含めることである。図３７において、サービスの機能がフローチャート上で明ら かになるにつれ、前スタッブブロックの効果が明かとなる。こ こでは、「info2」ブロック１９６は、情報の取り出しに関する実際の動作を行 う。この動作は、発呼者に対して情報を返す動作と同様のものである。 図３８Ａにおいて、インフォブロックが再び示されている。前スタッブボタン ３６１を起動することにより、Ｃ又はＣ++コードが前スタッブに入力される。こ れにより、第２のウインドウが起動されることになる。この第２のウインドウは 、スタッブブロックの形式により提供される場合と同様の手法で、Ｃコードをテ キストとして入力するために適切な形式を提供する。図３６Ａにおけるスタッブ ブロックに示すものに類似しており、同じ機能を提供するＣ／Ｃ++コードは、図 ３８Ｂにおける変更された「info2」ブロックのためのスクリプトファイルの中 に示されている。 ブロック動作を行う前に、その名の示すように前スタッブＣ／Ｃ++コードが実 行される。ブロック動作を行う前に、図３８Ａに示すように、前演算ボタン３６ ３によってシステム変数による動作を定義するための簡単な演算動作が定義され る。同様に、ブロック形式上の後演算ボタン３６２と後スタッブボタン３６４は 、後ブロック演算機能と後ブロックのＣ／Ｃ++コードを定義する手段を提供する 。このため、どのブロックも、４組までに及ぶ追加機能コードセグメントが備え られる。このセグメントは、そのブロックの動作を向上させるか又は変更させる ために使用されるものである。このように、機能ブロックの予め定義されたライ ブラリは、柔軟性の向上したものとなる。 明らかに、このような文体におけるＣ又はＣ++でのプログラミングは、経験の 無いプログラマーにとっては適当でない。ただ、ここで注意すべきことは、Ｃ／ Ｃ++プログラミングとサービス提供の両方についての知識を持っている技術者に 対しては、考えられる専門技術を注ぎ込むことは可能ということである。このた め、これらの効率の高いグラフィックス駆動によるユーザインタフェースにおけ るサービス設計の方法を結合させたシステムは、初心者のためだけに設計された システム以上の効果が得られるものと考えられる。初心者のためだけに設計され たシステムは、Ｃ／Ｃ++の増大を可能とするような柔軟性に欠けている。 無線サービスシミュレーション 図５Ｂのステップ５７で表されているように、ステップ６１におけるダウンロ ードが可能なコードの生成を行う前に、サービスの動作をシミュレートすること が可能である。このことは、ダウンロードが可能なコードの生成の前に、システ ムの変更を始めるとともに、更にシミュレーションを行うことを容易にする。 実際のスピーチアプリケーションプラットフォーム上で実行可能なコードの生 成がワン−オフ翻訳処理として行われる。サービスのシミュレーションは、ペー ジファイル及びフォームファイルのライン間での翻訳において効果を発揮する。 図３に示すように、シミュレーションは、開発システム上で行われ、遠距離シミ ュレーションで知られているようなサービスの設計及び作成に使用される。一方 、シミュレーションは、 図２に示す種類の装置内、即ち実際のスピーチアプリケーションプラットフォー ム上で行われる。シミュレーションがアプリケーションプラットフォーム上で行 われるとき、システム開発を容易なものとするためにプラットフォームはこの目 的に沿ってプログラムされているものとする。行われる手順は、遠距離シミュレ ーションにおいてなされる場合と本質的に類似している。実際のアプリケーショ ンプラットフォーム上のシミュレーションは、コンパイルされた実行可能なコー ドが実際に走るように正確に表された環境を提供する。但し、遠距離開発システ ム上のシミュレーションは、例えば音声認識をシミュレートすることにより、時 間を節約した速い処理を実現する。また、シミュレーションは、システムの静的 動作の解析が行えるようにする。図５のステップ５７で表されたシミュレーショ ン手順を図３９に詳細に示す。 図３９を参照すると、ステップ４０２から４０８までは、単に遠距離開発シス テム上で行われるシミュレーションに関するものである。ステップ４０９から４ １２までは、実際のスピーチアプリケーションプラットフォーム上で行われるシ ミュレーションに加え、さらに遠距離開発システム上で行われるシミュレーショ ンに関するものである。開発システムは、スピーチアプリケーションプラットフ ォーム上で行われる場合と同様にして音声認識を行う。一方、認識手順は、認識 を行って適当な応答を提供する操作者によってシミュレートされる。ステップ４ ０２において、自動化認識が行われるべきか否かを調べる。もし行うのであれば 、ステップ４０３にお いて認識テンプレートが識別され、ステップ４０４において識別されたテンプレ ートの詳細を含んだファイルが開かれる。この後、制御がステップ４０８に向け られる。 一方、もしステップ４０２において自動化認識を行わないのであれば、制御は ステップ４０５に向けられる。ここでは、シミュレートされたエラーが百分率で 表されるべきか、又は上記エラーはプラットフォームに繋がれた統計表（以下、 プラットフォームに繋がれた統計表をＳＡＰと呼ぶ。）から導き出されるべきか 否かを調べる。もしプラットフォームの統計表が選択されると、制御がステップ ４０６に向けられる。これにより、上記統計表がロードされ、制御がステップ４ ０８に向けられる。 一方、ステップ４０５においてエラーが百分率で表されるべきならば、制御が ステップ４０７に向けられる。これにより、この選択が記録され、百分率エラー ルーチンがロードされる。 ステップ４０６の実行の後、又はステップ４０７の実行の後、制御がステップ ４０８に向けられる。ステップ４０８においては、ユーザは動作用データを定義 することを求められる。また、シミュレーションを連続して走らせるべきか、又 は別のステップにおいてデバッグを行わせるかについて、可聴のビープ音を発生 させるべきかについて、そしてユーザの発話を記録すべきかについて調べる。 シミュレーションハウスキーピングルーチン内で主に使用される動作用データ をユーザが定義した後は、制御がステッ プ４０９に向けられる。そして、その後の手順は、上記手順が開発上のものであ るかスピーチアプリケーションプラットフォーム上のものであるかに関係なく、 本質的に同様である。 ステップ４０９において、ページファイルとフォームファイルは、そのサービ ス構造が調べられ、動作状態が定義される。この後、スクリプトにより定義され た命令は、シミュレーションが実行されるのに従って翻訳される。このため、ス テップ４１０においては、次のブロックが読まれる。ステップ４１１においては 、そのブロックの命令が実行され、ステップ４１２においては、他のブロックを 処理すべきか否かを調べる。もし処理すべきであれば、制御がステップ４１０に 戻る。そうでなければ、制御は図５Ｂのステップ５８に戻る。 返答ブロックのためのシミュレーション手順を図４０に詳細に示す。ページフ ァイルは、返答ブロックの後に実行されるべきブロックを特定する。ページファ イル内においてブロックが他のブロックにどのような状態で接続されているのか を示すために、スクリプトの特定の行が各ブロック定義内に含まれる。 ここで注意すべきことは、図４０のステップ４１５は、実際には図３９に示す ステップ４１０の特別の構築例であるということである。ステップ４１６におい て、前ブロック動作が実行される。この動作は、前演算の宣言と前スタッブの宣 言を含んでいる。これについては後述する。 ステップ４１７において、コールが受けられたか否かを調べる。図１１Ａに表 されているように、システムは、ブロッ クのタイムアウト期間で決定される間だけステップ４１７で待機する。ブロック タイムアウト期間のソフトトグルは、図２６Ａに示すようにチェックされていな い状態になっている。これにより、システムは、コールを受けるまでずっとステ ップ４１７で待機する。一方、もし特定の時間がブロックタイムアウト期間のた めに設定されると、ステップ４１７において“いいえ”に相当することになる。 これにより、制御がステップ４２０に向けられ、失敗の状態に戻ることになる。 一方、もしコールを受けると、ステップ４１７において“はい”に相当するこ とになる。これにより、ステップ４１８においてコールが返答されることになる 。呼出しから返答までの期間は、図２６Ａに示すようにブロックパラメータに応 じて設定される。そして、このプリセット期間の後にコールが返答されることに なる。コールが返答された後は、システム“ＯＫ”メッセージがステップ４１９ において生成され、制御がステップ４２１に向けられる。 シミュレーションハウスキーピングがステップ４２１において行われる。シミ ュレーションハウスキーピングのレベルは、アプリケーションプラットフォーム に比べ、開発システム上でシミュレーションが行われているときに非常に高い。 例えば、もしブロックがシステム“ＯＫ”メッセージを発生するならば、ビープ 音が発生する。そして、コールが返答されたか否かを記述しているデータをシミ ュレーションログファイルに記録する。この後、ステップ４２２において、後ブ ロック動作が実行される。そして、制御は、図３９のステッ プ４１２に戻る。 ハングアップブロックをシミュレーティングするステップを図４１に示す。ス テップ４２５において、ハングアップブロックデータがページファイルから読ま れる。そして、ステップ４２６において、前ブロック処理が実行される。ステッ プ４２７において、コールがクリアされる。ステップ４２８において、システム “ＯＫ”メッセージが返答される。シミュレーションハウスキービングがステッ プ４２９において行われ、後ブロック処理がステップ４３０において行われる。 この後、制御は図３９のステップ４１２に戻る。 ダイアルアウトブロッタのためのシミユレーションステップを図４２に詳細に 示す。ステップ４３１においてダイアルアウトブロックスクリブトがページファ イルから読まれ、ステップ４３２において前ブロック処理が行われる。 ダイアルブロック用に記録された所定の番号がステップ４３３においてダイア ルされる。そして、ステップ４３４において、コールが返答されたか否かを調べ る。ステップ４３４において判別がなされる前に、ページファイルのスクリプト は、返答されるべきコールをシステムがどの位の間待つべきかを指定する。もし コールの返答が成功すれば、制御はステップ４３５に向けられ、“ＯＫ”がシス テムに戻る。一方、ステップ４３４においてコールが返答されなければ、“失敗 ”の状態が起こる。シミュレーションハウスキーピング４３７と後ブロック処理 ４３８はいずれも実行され、制御はステップ４１２においてシステムに戻る。 情報がシステムに戻った後は、シミュレーションハウスキーピングの手順がス テップ４３７において行われる。この後、後ブロック処理がステップ４３８にお いて行われる。この後、シミュレートれるべき他のブロックのために、制御はス テップ４１２に向けられる。 転送ブロックのためのシミュレーション手順を図４３に詳細に示す。ステップ ４４１において転送ブロックのためのデータが読まれ、ステップ４４２において 前ブロック処理が実行される。 現コールが接続されており、そのコールが他のラインに再接続されるべきとき には、転送ブロックが含められる。これにより、アプリケーションプラットフォ ームが効果的に外部の顧客から遮断されることになる。このため、ステップ４４ ３において現コールが保持状態となり、ステップ４４４において転送のための特 定の番号がダイアルされる。 ステップ４４５において、ダイアルされた番号が返答されたかを調べる。そし て、特定のタイムアウト期間の経過後、番号が返答されていなければ、制御はス テップ４４９に向けられることになる。他方、番号が返答されていれば、制御は ステップ４４６に向けられる。 もしステップ４４５においてダイアルされた番号が返答されていれば、ステッ プ４４６においてコールが返答ラインに接続され、ステップ４４７においてアプ リケーションプラットフォーム又はそのシミュレーションは効果的にハングアッ プする。この後、ステッブ４４８において、“ＯＫ”が戻さ れ、制御はステップ４５１に向けられる。 一方、コールされたラインが返答されない場合は、ステップ４４５における“ いいえ”に相当する。この後、制御がステップ４４９に向けられる。これにより 、元のコールが再接続され、“失敗”がステップ４５０において返される。 ステップ４５１において、シミュレーションハウスキーピングの手順が行われ る。ここでは、ビープ音やロギング（記録）データなどの生成が行われる。そし て、ステップ４５２において、特定の後ブロック処理が行われる。この後、制御 はステップ４１２に向けられる。 インフォブロックのための手順を図４４に詳細に示す。ステップ４５６におい て、前ブロック処理が実行される。この後、インフォブロックファイルの内容が 読まれる。ステップ４５６において情報の通信が電話線を通じて行われ、ステッ プ４５９において適切なシミュレーションハウスキーピングが行われる。ステッ プ４６０において、後ブロック処理が実行される。この後、制御はステップ４１ ２に向けられる。 ＤＴＭＦのためのシミュレーション手順を図４５Ａと図４Ａ５Ｂに詳細に示す 。ステップ４６１において、ＤＴＭＦブロックデータが読まれ、関連する前ブロ ック処理がステップ４６２において実行される。発呼者のＤＴＭＦタイプの電話 上のボタンを押して発生する音声を入力するため、ＤＴＭＦブロックは顧客に対 してこれを促進する。システムは、ブロックが失敗したものと扱われる前に３つ のプロンプトメッセージが発行されるように構成されている。 ステップ４６３において、最初の反復では、第１のプロンプトファイルがロー ドされ、ステップ４６４において、コールしている顧客に対して音声（会話）の 形で上記ファイルが実行される。ステップ４６５において、音声を受けているか 否かを調べる。もし音声を受けていなければ、ステップ４６６において３つのプ ロンプトメッセージが実行されているか否かを調べる。もしステップ４６６にお いて実行されていなければ、制御はステップ４６３に戻る。これにより、第２の プロンプトファイルがロードされ、ステップ４６４において実行される。再び、 ステップ４６５において、音声を受けているか否かを調べる。もし今回も音声を 受けていなければ、３つのプロンプトが実行される。もしステップ４６５におい て音声を受けていれば、制御はステップ４６８に向けられる。 ３つのプロンプトメッセージを生成した後に、もしステップ４６５においてま だ音声を受けていなければ、ブロックの“失敗”がステップ４６７において記さ れる。この後、制御はステップ４７９に向けられる。 制御がステップ４６８に向けられると、ステップ４６５において音声を受けて いれば、ステップ４６８において所定数のディジットが求められているか否かを 調べる。もし求められていれば、制御がステップ４６９に向けられる。これによ り、上記特定数の音声が選択され、制御がステップ４７２に向けられる。 もしステップ４６８において、所定数のディジットが求められていなければ、 特定数の音声は定義されていないことに なる。そして、制御がステップ４７０に向けられ、音声が選択される。この後、 ステップ４７１において、メッセージの最後を示す四方形（電話イーパッド上の “＃”を押すことにより生成されたＤＴＭＦ音声）で表された音声を受けたか否 かを調べる。もし四方形以外の音声を受けたならば、ステップ４７１における“ いいえ”に相当し、制御がステップ４７０に返される。これにより、更なる音声 が選択される。このため、ステップ４７０が繰り返され、四方形のものを受ける まで音声が選択される。 四方形の音声を受けた後は、ステップ４７１において“はい”に相当する結果 となり、制御がステップ４７２に向けられる。これにより、ステップ４６９にお いて実行が成功したことになる。そして、音声が有効であるか否かを調べる。も し有効でなければ、音声が無効ということになり、“TONE INVALID”メッセージ がステップ４７３においてフォームファイルからロードされ、ステップ４７４に おいてそれが実行される。これにより、ステップ４７５において、音声を得るた めの３度目の試みであったか否かを調べる。もし３度目の試みであれば、制御が ステップ４７６に向けられる。ブロックの“失敗”が返される。 ステップ４７２において、もし音声が有効であれば、制御がステップ４７７に 向けられる。これにより、データが保持され、実行されたブロックの“成功”が 返される。 ステップ４７６とステップ４７８が処理されると、ステップ４７９においてシ ミュレーションハウスキーピングが行わ れる。このステップ４７９には、データのロギング（記録）処理などが含まれる 。ステップ４８０において後ブロック処理が行われると、この後、制御がステッ プ４１２に向けられる。これにより、次のブロックがシミュレートされることに なる。 質問ブロックのためのシミュレーション手順を図４６に示す。質問ブロックは 、顧客がスピーチアプリケーションプラットフォームと容易に交信することがで きるように構成されている。プラットフォームには音声認識の機能が設けられて おり、入ってくる音声は、選択されるテンプレート又はモデル（ＨＭＭ感度に基 づくもの）と比較される。これにより、入ってくる音声が認識可能なカテゴリー の中にあるか否かが判別できることになる。こうした認識がなされると、情報が 上述のように処理され、続いて判別が行われることになる。 ステップ４９０において、特定のブロックデータがロードされる。そして、ス テップ４９１において、前ブロック処理が実行される。ステップ４９２において 、フォームファイルからプロンプトメッセージが読まれる。そして、このフォー ムファイルがステップ４９３で実行されることになる。 プロンプトは、コールしている顧客に対し、システムに話しかけるように促進 する。そして、ステップ４９４において、入ってくる音声が記録される。ステッ プ４９５において、音声が検出されたか否かを調べる。もし検出されれば、制御 がステップ４９７に向けられる。一方、もし音声が検出されなければ、制御がス テップ４９６に向けられる。これにより、 音声を得るための試みが３度目であるか否かを調べる。もし３度目でなければ、 制御がステップ４９２に返される。さらに、プロンプトメッセージが読まれ、こ のプロンプトメッセージがステップ４９３において実行される。 もしステップ４９６において、音声を得るための試みが３度目であれば、制御 がステップ４９９に向けられることになる。このステップ４９９では、ブロック の“失敗”が返される。そして、制御がステップ５０２に向けられることになる 。 もしステップ４９７において音声が認識されたならば、制御がステップ５００ に向けられる。これにより、適当な応答が選択され、この“応答”がステップ５ ０１において返される。この後、制御はステップ５０２に向けられる。 ステップ５０２において、ロギング処理などを含むシミュレーションハウスキ ーピングが行われる。後ブロック処理がステップ５０３において実行されると、 制御がステップ４１２に向けられる。 ステップ４９７において、音声認識処理のための受け入れ処理がなされる。こ の処理は、いくつかの技術によって構築されている。シミュレーションは、基礎 開発システムを使用することにより実行される。これは、操作者によって行われ る。その最も簡単な形態においては、この認識は非常に正確なものとなる傾向が あるが、スピーチアプリケーションプラットフォーム上では正確な認識性が反映 されない。この問題を解決するためには、音声認識システムにおけるエラーの百 分率を導出することが可能である。この場合、操作者は入っ てくる音声を正しく認識するかもしれないが、その認識のうち所定の百分率に相 当するものは不正確なものとなっている。そして、システム開発者は、こうした 不正確な認識の結果物に対してアクセスすることができる。 ここで評価しておくべき点は、簡単な百分率エラー技術を使用すると、実際に エラーが発生しても、実際のスピーチアプリケーショプラットフォームには典型 的なエラー分布が見られないことである。操作者によって音声認識の行われるよ うな性能の高いシステムにおいては、正しく選択されなかった割合とともに正し く選択された割合をそれぞれ詳細に示す確認マトリクスが設けられている。確認 マトリクスは、乱数を発生させることによって使用される。そして、可能な限り の乱数の選択の情報が、確認マトリクス内の有効となる位置に設けられている。 但し、特定の出力のための各番号の位置情報は、実際のスピーチアプリケーショ ンプラットフォームにより選択される出力の割合を表している。このため、乱数 が発生した後は、確認マトリクス内におけるその発生した位置が識別される。従 って、エラーの発生することが稀れな特定のフレーズにおいては、正しい認識が 維持されるように可能な限り多くの番号が配置される。そして、エラーの出力が 生成されることは極めて少ない。一方、正しい関係についての番号が少ない状態 で配置されている場合、特定の言葉やフレーズが実際のオペレーティングシステ ムによってしばしば誤って認識されてしまうことになる。このため、実際のアプ リケーションプラットフォーム内で周知の分布レベルを有 するシステムにおいてエラーが引き起こされる。さらに、異なるアプリケーショ ンプラットフォームは異なる応答をもっており、これらの応答は特定の確認マト リクス内に反映される。各々は、同じサービスの異なるシミュレーションにおい て使用される。 更に性能の高いシステムにおいては、自動化音声認識の機能が設けられる。こ の場合、音声認識の機能が実際のスピーチアプリケーションプラットフォーム上 に設けられているように構成されている。音声認識テンプレートの使用について は従来からよく知られている。特定の言葉又はフレーズの平均的な特性を表すテ ンプレートが生成される。そして、入ってくるデータが標本化され、テンプレー トと比較される。これにより、装置は、特定の音声形態が作成されたか否かを判 別する。但し、音声認識に基づく本来のテンプレートの使用は、隠れマルコフモ デル（ＨＭＭ）の手法に知られる静的競合技術に比べ、あまり好まれていない。 本願発明の要旨は、“ｓｃ”ごとの音声認識ではなく、サービス作成ツール及び 方法である。ここで、ＨＭＭ及びその他の認識技術によってどのように操作する のかを詳細に説明するのは適切でないと思われる。読者は、優れた書である「Fu ndamentals of Speech Recognition，L Rabiner and B H Juang，Prentice Hall ，1993（特に第６章）」及びこれらの著者の数多くの出版物を参照されたい。 スピーチテンプレート又は別個の言葉のモデル（ＨＭＭシステムに基づくもの ）を生成すると、かなりの作業をこなす ことが可能となる。そして、その音声の平均的な形態を作成するためには、同じ フレーズについてかなりの数の音声の採取が求められる。図３９に表されたシミ ュレーションの手順は、音声認識機能を人が操作できるようにし、また、テンプ レートの構築に先だってシミュレーションが行われるようにする。 サブワードモデリングの技術を使用することにより、認識の言語体系をすぐに 作成できる。この場合、言語の中のすべての言葉を音の単位又は音素による小さ な組で記述することが可能となる。言語体系に新たな言葉を追加するためには、 操作者は、その言葉を表す音素のシーケンスを識別する。これは、通常、関連す る音素のシーケンスの備えられた言葉のリストを含んでいる辞書から得られる。 言葉が辞書の中に見つからない場合、言葉がどのように発音されるかを推測する のに規則セットが使用される。こうしたサブワードモデリングは、ＨＭＭのよう な静的な手法によることが好ましい。ユーザは、例えばテキストボックスの中で キーボードを使用してタイプすることにより、言葉や言葉のシーケンスをテキス トとして簡単に入力する。そして、言葉はスペルチェックされる（例えば作成さ れた言葉や実際の名前などのために、スペルチェッカの中に存在しないような言 葉のためのサブワードモデリング認識モデル（又は、モデルシーケンス）を作成 するのに使用できる）。ユーザが言葉をスペリングすることが楽しくなれば、ア プリケーションプラットフォームは、ボタンを押したときに適切なサブワードモ デルシーケンスを作 成することができる。また、例えばより共通化したコマンドの言葉、ディジット 、等の全体的なモデルをシステムに含めるようにしてもよい。そして、サービス の対話機能は、必要があればサブワードモデルと全体的な言葉のモデルとを結合 することによって入力されるテキストから作成されることになる。 この種の音声認識システムにおいては、認識機能としては、言語の中の各音素 のモデル（隠れマルコフモデル）が求められる。モデルは、音声の面で豊富なセ ンテンスを保持するデータベースから用意される。センテンスとしては、何百も の人の話したものであり、また、各言語ごとに一度だけ選択されるものが必要と される。これにより、電話線や受話器の質といった環境面の状態を特に変えるこ ともない。こうしたシステムに係る主な費用としては、データベースと辞書の収 集及び準備にかかる最初の費用くらいなものである。 認識すべきことは、サブワード音声認識が採用されたとき、システムの動作は 悪くなると考えられる。これは、サブワードモデルが、全体の言葉のモデルほど 正確には言語体系を表現できないためである。しかし、新しい言語体系はすばや く作成することができる。これにより、アプリケーションの制作を速くすること ができる。さらに、もしシステムの精度を改善することが必要な場合は、次の使 用のために全体の言葉のモデルを作成するために、アプリケーションが動作中で かつ無線で処理されている間にデータを収集するようにすればよい。 サブワードモデルの生成と使用は、記事「Sabword-Based Large-Vocabulary S peech-Recognition，by Lee，Gaivain，Pieraccini and Rabiner，in AT & T Te chnical Journal，September-October 1993」に記述されている。読者は、さら に詳しく知るためにサブワードモデリングを題目とするRabinerらによる他の書 を前もって読まれたい。 記録ブロックのためのシミュレーション命令を図４７に詳細に示す。ステップ ５１１において、特定の記録ブロックデータがロードされる。そして、ステップ ５１２において、前ブロック処理が実行される。 記録ブロックは、顧客からの言葉によるメッセージが記録されるようにする。 そして、ステップ５１３において、プロンプトデータがロードされ、ステップ５ １４において上記データが顧客に供給される。これにより、顧客はメッセージを 記録するように誘導される。ステップ５１５において、記録処理が開始される。 そして、ステップ５１６において、何かを受けたか否かを調べる。もし何も受け ていなければ、ステップ５１７においてこれが３度目の試みであるか否かを調べ る。もし３度目の試みでなければ、制御がステップ５１３に戻される。ここでは 、次のレベルのプロンプトがロードされ、ステップ５１４が処理される。 もし記録情報に対して３度目の試みが行われたならば、各々が成功したことに なり、ステップ５１７における“はい”に相当することになる。これにより、“ 失敗”がシステムに返される。この後、制御がステップ５２１に向けられる。 ステップ５１６においてもし何かを受けたならば、音声を受けたことになり、 制御がステップ５１９に向けられる。ここでは、メッセージが長すぎないか否か を調べる。もし長すぎるのならば、制御がステップ５１３に戻される。そして、 メッセージを記録するために更なる試みがなされる。 もしメッセージが長すぎないのであれば、ステップ５１９における“いいえ” に相当することになり、“ＯＫ”がステップ５２０に返される。これにより、記 録処理が成功したことになる。この後、制御はステップ５２１に向けられる。 ステップ５２１において、シミュレーションハウスキーピング手順が行われる 。ステップ５２２において後ブロック処理が実行される。そして、次のブロック がシミュレートされるように、制御はステップ４１２に向けられる。 外部ブロックのためのシミュレーションの手順を図４８に詳細に示す。ステッ プ５２５において、特定の外部ブロックデータがロードされる。そして、ステッ プ５２６において、前ブロック処理が実行される。ステップ５２７において、特 定の外部ルーチンに対してコールがなされる。そして、ステップ５２８において 、て上記コールからデータを受けたか否かを調べる。 ステップ５２８においてもしデータを受けていなければ、制御がステップ５２ ９に向けられる。ここでは、“失敗”が返され、制御がステップ５３１に向けら れる。ステップ５２８においてもしコールからデータを受けたならば、制御がス テップ５３０に向けられる。ここでは、“ＯＫ”が返される。 この後、制御がステップ４３１に向けられる。これにより、シミュレーションハ ウスキーピング手順が実行され、ステップ５３２において後ブロック処理が実行 される。この後、制御がステップ４１２に向けられる。 ダウンロードが可能な命令の作成 ダウンロードが可能なＣ又はＣ++命令の生成は、好適な実施例のシステムによ って自動的に行われる。命令（以下、プログラムという。）は自動的に生成され るが、経験豊かなサービス設計者やプログラマーにより使用する場合には、一歩 進んだオプションが有効となる。そして、Ｃ／Ｃ++ライブラリ、オブジェクトコ ードライブラリ及び関連するプログラムライブラリがＣ／Ｃ++ヘッダファイルに よって参照されることになる。これらのオプションは、入力手段に基づく追加の グラフィック（図表）の形態をとる。これらは、システムグローバルファイル及 びサービスグローバルファイルと呼ばれる２つのファイルにおけるデフォルトス クリプトパラメータを無効にする。これらのファイルは、ページファイル（及び 、これらの関連するフォームファイル）を翻訳する処理の間に求められる情報を 提供する。 ダウンロードが可能な命令を生成するためのシステムによって行われる手順を 図４９に詳細に示す。ステップ７０１において、変数がページファイルから取り 出され、サービス構造の表現形式が生成される。ページファイルは、システムグ ローバルファイルとサービスグローバルファイルを含んでいる。システムグロー バルファイルは、全体のサービスに共通 するパラメータを識別する。一方、サービスグローバルファイルは、ページの配 列に基づいてサービスの構造を識別する。サービスの記述は、ページごとに各フ ァイルを付加することにより十分に定義される。このとき、ページ内のブロック と接続の仕方が定義される。 ステップ７０２において、ダウンロードが可能な命令を生成するためにページ ファイルが処理される。このときの命令は、Ｃ++プログラミング言語と互換性の ある形であることが好ましい。命令は、状態の有限数即ち有限状態の機構を定義 する制御プログラムと結合したページごとのサブルーチンを含んでいる。ステッ プ７０３において、人の読めるダウンロードが可能な命令の表現形式が作成され る。これにより、オンライン動作のときに操作者はシステムを進行させることが できる。 Ｃ++の要求に応えるためには、使用されるＣ++命令（機能）のセクションの始 まりにおいて変数を宣言する必要がある。このため、Ｃ++プログラムを作成する 第１のステップとしては、スクリプトファイルの中で変数の存在を判別するとと もに、使用される字体からこれらの種類（整数やストリングなど）を判別する必 要がある。 図４９におけるステッブ７０１に表された、変数を取り出すための手順が図５ ０に詳細に示されている。ステップ７１２において、変数は、“arg”、“pre-d o”及び“do”のような関連するスクリプトキーワードのサーチを行うことによ って識別される。これにより、変数の種類がそれらの字体から 判別される。タイプすることのできない変数が識別されたとき、レポートが作成 される。 ステップ７１３において、変数の種類を識別するため、ページに与えられる引 数を考えることによって更なる評価が行われる。各変数ごとの種類を識別できる ようにするため、“same type as”リストが作成される。この場合、もしリスト 中の変数のうちの１つの種類が判別されていればそのリスト中の変数のすべてが タイプされる。 もし変数をタイプすることができないならば、それら変数はステップ７１４で 表示される。これにより、操作者は要求された情報を供給するか、又はサービス 作成機能から説明文を探す。 ステップ７０２に表された、ページごとにページファイルを処理する手順を図 ５１に詳細に示す。別のページファイルは、サービスのページごとに存在してお り、この手法がＣ++コードの形で保持されている。主となるＣ++プログラムは、 各ページサブルーチンをコールするように作成される。これにより、各ページフ ァイルがともにリンクされ、これらの順が定義される。このため、ステップ７２ １において、次のページファイルが開けられ、対応するＣ++出力ファイルが作成 される。 ステップ７２２において、ページ名が識別されるまでスクリプトファイルから のコメントがＣ++コメントとしてコピーされ続ける。ステップ７２３において、 ページより使用されたグローバル変数がＣ++ファイルにコピーされる。ステップ ７２４において、サービス階層におけるページの位置が判別され、ページファイ ルへ渡された引数がコピーされ、局所変数がＣ++ファイルへ渡される。 ステップ７２５において、ページ説明文の最後が識別されるまでページがＣ++ に翻訳され続ける。翻訳においては、最初にページ内の各ブロックを識別するこ とと、各ブロックをそれぞれ翻訳するための翻訳サブルーチンをコールすること がなされる。 ブロックが翻訳が完了すると、ステップ７２６において、ページ機能の基本型 がＣ++ファイルに書かれる。ステップ７２７において、制御ロジックが書かれる 。この制御ロジックは、ページ内のブロックサブルーチンのコールを制御し、ペ ージのための有限状態機構を定義する。 ステップ７２８において、変数が再設定され、ステップ７２９において処理を 必要とするページが他に存在するか否かを調べる。もしページが存在すれば、制 御がステップ７２１に戻され、テキストファイルの全てのページが処理される。 結局のところ、テキストファイルの全てのページの処理が完了すると、ステップ ７２９において“いいえ”に相当することになる。この場合は、制御がステップ ７３０に向けられる。これにより、十分なサービスを構成するページの階層構造 に基づき、コールしている主な命令が作成される。 このような処理が完了すると、サービスはＣ++ファイルの番号で定義される。 Ｃ++ファイルは、操作者が読むことができるものとなっている。そして、これら のファイルの詳細な コーディングに関する文書が作成される。Ｃ++ファイルは、特定のスピーチアプ リケーションプラットフォームのためにＣ++ファイルを実行可能コードに翻訳す る能力のあるサービス側にダウンロードすることが可能となっている。書類は、 特定のオペレーティングシステム又はプラットフォーム環境内において翻訳に適 したＣ++コードを作成するのに必要とされる微少変更の詳細を提供する。更に、 Ｃ++はよく使用されるプログラミング言語であり、この形で与えられるソフトウ ェアは、プログラミング技術を必要とするサービス提供者により、付加機能や変 形機能を持たせる際に有利となるように変更される。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 庁内整理番号 ＦＩ Ｈ０４Ｍ 3/42 9567−5Ｇ Ｈ０４Ｍ 3/42 Ｚ 9567−5Ｇ Ｐ Ｈ０４Ｑ 3/545 9567−5Ｇ Ｈ０４Ｑ 3/545 (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)ＡＰ(ＫＥ，ＭＷ，ＳＤ)，ＡＭ ，ＡＵ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＮ，ＣＺ，ＦＩ， ＧＢ，ＧＥ，ＨＵ，ＪＰ，ＫＥ，ＫＧ，ＫＲ，ＫＺ，Ｌ Ｖ，ＭＤ，ＮＯ，ＮＺ，ＰＬ，ＲＯ，ＲＵ，ＳＩ，ＳＫ ，ＴＪ，ＴＴ，ＵＡ，ＵＳ，ＵＺ，ＶＮ (72)発明者 サルター、ジョゼフィン・アン・スーザン イギリス国、アイピー４・２アールイー、 サフォーク、イプスウイッチ、アッシュメ ア・ロード 13 (72)発明者 ポペイ、ポール・イアン イギリス国、アイピー４・４エージー、サ フォーク、イプスウイッチ、ホイットバ イ・ロード 125

Claims (1)

1. 【特許請求の範囲】 １． アプリケーションプラットフォームに対するダウンロードが可能な命令 を生成する方法であって、論理制御されるアプリケーションを定義するために複 数のパラメータ依存処理がリンクされており、 機能ブロックをグラフィックで表示するステップと、 アプリケーションの動作中において前記ブロック間の論理フローを順に示す当 該ブロック間の接続をグラフィックで表示するステップと、 前記論理フローの有効性をテストするために前記ブロック間の接続の有効性を テストするステップと、 前記有効性のテストの後に、ブロックの機能を特定する処理パラメータを入力 するステップと を有することを特徴とする方法。 ２． 前記アプリケーションプラットフォームはスピーチアプリケーションプ ラットフォームであり、前記ダウンロードが可能な命令は高レベル言語の形で表 されることを特徴とする請求項１記載の方法。 ３． 前記接続の有効性をテストするステップは、接続の欠落を調べるステッ プを含むことを特徴とする請求項１記載の方法。 ４． 前記接続の有効性をテストするステップは、二重化した接続を調べるス テップを含むことを特徴とする請求項１記載の方法。 ５． 前記接続の有効性をテストするステップは、入力の 欠落した接続を有するブロックを調べるステップを含むことを特徴とする請求項 １記載の方法。 ６． スピーチアプリケーションプラットフォーム上へのダウンロードが可能 な命令を生成する方法であって、 機能ブロックをグラフィックで表示するステップと、 サービス構造を定義するための前記ブロック間の接続をグラフィックで表示す るステップと、 ブロック間の欠落リンクとブロック間の二重化したリンクと入力リンクの欠落 したブロックとを調べるために前記接続の有効性をテストするステップと を有することを特徴とする方法。 ７． 前記ダウンロードが可能な命令は、Ｃ又はＣ++命令として生成されるこ とを特徴とする請求項６記載の方法。 ８． 前記有効性テストの後にブロックの処理パラメータが入力されることを 特徴とする請求項６記載の方法。 ９． スピーチアプリケーションを定義する方法であって、 機能ブロックと当該ブロック間の接続とをグラフィックで表示するステップと 、 前記スピーチアプリケーションの機能を定義するスクリプトファイルを生成す るステップと、 前記スクリプトファイルを行単位で翻訳することにより前記アプリケーション の処理をシミュレートするステップと を有することを特徴とする方法。 １０． 前記ブロックごとにテキストファイルが作成され、前記スクリプトフ ァイルは当該テキストファイルからの命令 の各行を結合することにより作成されることを特徴とする請求項９記載の方法。 １１． 機能ブロックと当該ブロック間の接続を表示した後に有効性をテスト するステップと、有効化が成功した後に処理パラメータを入力するステップと、 前記ブロックに対するパラメータの入力の後にブロックのためのテキストファイ ルを作成するステップとを有することを特徴とする請求項１０記載の方法。 １２． スピーチアプリケーションをシミュレートする方法であって、 前記アプリケーションを表したスクリプトファイルを翻訳するステップと、 登録されている発呼者からの音声を操作者に供給するステップと、 前記操作者からの認識データを受けるステップと、 エラーを前記認識データに導入するステップと を有することを特徴とする方法。 １３． 前記エラーは、前記認識データの所定の百分率で表されることを特徴 とする請求項１２記載の方法。 １４． 導入されたエラーの割合は、実際のスピーチアプリケーションプラッ トフォーム上で起こるエラーの割合から導き出されることを特徴とする請求項１ ２記載の方法。 １５． エラーは確認マトリクスを参照することにより導き出されることを特 徴とする請求項１４記載の方法。 １６． スピーチアプリケーションプラットフォーム上で スピーチアプリケーションをシミュレートする方法であって、 前記アプリケーションを表したスクリプトファイルを翻訳するステップと、 音声認識のテンプレートがサブワード単位の言語体系から構築されている自動 化音声認識を行うステップと を有することを特徴とする方法。 １７． スピーチアプリケーションをシミュレートする方法であって、当該ス ピーチアプリケーションはグラフィック表示された機能ブロックの間の論理接続 で定義されており、 前記ブロックの各々のためのテキストファイルを作成するステップと、 テキストファイルデータを結合させることによりプリケーションを定義するス クリプトファイルを作成するステップと、 前記スクリプトファイルを翻訳することによりシミュレーションを行うステッ プと を有することを特徴とする方法。 １８． 登録されている発呼者から操作者へ音声を供給するステップと、前記 操作者から認識データを受けるステップと、エラーを前記認識データに導入する ステップとを有することを特徴とする請求項１７記載の方法。 １９． 前記アプリケーションを表したスクリプトファイルを翻訳するステッ プと、音声認識のテンプレートがサブワード単位の言語体系から構築されている 自動化音声認識を行うステップとを有することを特徴とする請求項１７記載の方 法。 ２０． 前記機能ブロック間の論理フローの有効性をテストするために当該機 能ブロック間の接続の有効性をテストするステップを有することを特徴とする請 求項１７記載の方法。 ２１． スピーチアプリケーションプラットフォーム上へのダウンロードが可 能な命令を生成する方法であって、 スピーチアプリケーションをグラフィックで表示するステップと、 直接のコンパイルが可能なコードを受ける手段を前記グラフィック表示に含ま せるステップと、 前記グラフィック表示から導き出されるテキストの中に直接のコンパイルが可 能なコードを埋め込むステップと を有することを特徴とする方法。 ２２． 前記直接のコンパイルが可能なコードはＣ又はＣ++であることを特徴 とする請求項２１記載の方法。 ２３． 前記グラフィック表示は機能ブロックを配置することにより定義され 、前記ブロックとテキストの間の論理接続はブロックの機能を表示した状態で生 成されることを特徴とする請求項２１記載の方法。 ２４． 前記直接のコンパイルが可能なコードは前記配置された機能ブロック の各々の中に埋め込むことが可能であることを特徴とする請求項２３記載の方法 。 ２５． 前記テキストファイルの各々からはスクリプトファイルが作成される ことを特徴とする請求項２３記載の方法。 ２６． 前記スクリプトファイルを翻訳することによりシ ミュレーションがなされることを特徴とする請求項２５記載の方法。 ２７． 前記テキストからダウンロードが可能なコードを導き出すステップを 有しており、前記ダウンロードされたコードは前記埋め込まれたコンパイルが可 能なコードにコンパイルされることを特徴とする請求項２１記載の方法。 ２８． スピーチアプリケーションプラットフォームのための命令を生成する 方法であって、 アプリケーションは、機能ブロックと前記ブロック間の論理フローとにより定 義されており、 前記ブロックのうち少なくとも１つは外部ルーチンに対するコールを含んでお り、 実行可能命令は、前記ルーチンが当該実行可能命令によりコールされ得るよう に、前記定義されたアプリケーションから生成される ことを特徴とする方法。 ２９． 前記外部ルーチンは外部のデータベースにアクセスすることを特徴と する請求項２８記載の方法。 ３０． コールされた外部ルーチンには引数が供給され、前記コールされたル ーチンからはデータが返答され得ることを特徴とする請求項２９記載の方法。 ３１． コンパイルをするためにスピーチアプリケーションプラットフォーム 上へのダウンロードが可能な命令を生成する方法であって、 機能ブロックに論理接続された状態でアプリケーションを グラフィックで表示するステップと、 前記ブロック間の接続の有効性をテストするステップと、 前記ブロックの各々のためのテキストファイルを作成するステップと、 前記テキストファイルからスクリプトファイルを作成するステップと、 前記スクリプトファイルからダウンロードが可能な命令を作成するステップと を有することを特徴とする方法。 ３２． 前記ダウンロードが可能な命令はＣ又はＣ++であることを特徴とする 請求項３１記載の方法。 ３３． 前記アプリケーションは前記スクリプトファイルを翻訳することによ り本質的にシミュレートされることを特徴とする請求項３１記載の方法。 ３４． アプリケーションプラットフォームに対するダウンロードが可能な命 令を生成する装置であって、論理制御されるアプリケーションを定義するために 複数のパラメータ依存処理がリンクされており、 機能ブロックとアプリケーションの動作中において前記ブロック間の論理フロ ーを順に示す当該ブロック間の接続とをグラフィックで表示するように構成され たグラフィック表示手段と、 前記論理フローの有効性をテストするために前記ブロック間の接続の有効性を テストするとともに、前記有効性のテストの後に、ブロックの機能を特定する処 理パラメータの入力 を受けるように構成された処理手段と を有することを特徴とする装置。 ３５． 前記アプリケーションプラットフォームはスピーチアプリケーション プラットフォームであり、前記ダウンロードが可能な命令は高レベル言語の形で 表されることを特徴とする請求項３４記載の装置。 ３６． スピーチアプリケーションプラットフォーム上へのダウンロードが可 能な命令を生成する装置であって、 機能ブロックとサービス構造を定義するための前記ブロック間の接続とをグラ フィックで表示するグラフィック手段と、 ブロック間の欠落リンクとブロック間の二重化したリンクと入力リンクの欠落 したブロックとを調べるために前記接続の有効性をテストするように構成された 処理手段と を有することを特徴とする装置。 ３７． スピーチアプリケーションを定義する装置であって、 機能ブロックと当該ブロック間の接続とを表示するように構成されたグラフィ ック手段と、 前記スピーチアプリケーションの機能を定義するスクリプトファイルを生成す るように構成された処理手段と、 前記スクリプトファイルを行単位で翻訳することにより前記アプリケーション の処理をシミュレートするように構成された処理手段と を有することを特徴とする装置。 ３８． 前記第１の処理手段は前記ブロックごとにテキス トファイルを作成し、前記スクリプトファイルは当該テキストファイルからの命 令の各行を結合することにより作成されることを特徴とする請求項３７記載の装 置。 ３９． スピーチアプリケーションをシミュレートする装置であって、 前記アプリケーションを表したスクリプトファイルを翻訳する処理手段と、 登録されている発呼者からの音声を操作者に供給する通信手段と、 前記操作者からの認識データを受けるとともに、エラーを前記認識データに導 入する処理手段と を有することを特徴とする装置。 ４０． アプリケーションを表したスクリプトファイルを翻訳するように構成 された処理手段と、 サブワード単位の言語体系を記憶する手段と を有しており、スピーチアプリケーションのための音声認識のテンプレートが 前記サブワード単位から構築されていることを特徴とするスピーチアプリケーシ ョンプラットフォーム。 ４１． スピーチアプリケーションをシミュレートする装置であって、当該ス ピーチアプリケーションはグラフィック表示された機能ブロックの間の論理接続 で定義されており、前記ブロックの各々のためのテキストファイルを作成し、テ キストファイルデータを結合させることによりアプリケーションを定義するスク リプトファイルを作成し、前記スクリプ トファイルを翻訳することによりシミュレーションを行う処理手段を有すること を特徴とする装置。 ４２． スピーチアプリケーションプラットフォーム上へのダウンロードが可 能な命令を生成する装置であって、 直接のコンパイルが可能なコードを受ける手段を有し、スピーチアプリケーシ ョンを表示するグラフィック手段と、 前記グラフィック表示から導き出されるテキストの中に直接のコンパイルが可 能なコードを埋め込むように構成された処理手段と を有することを特徴とする装置。 ４３． スピーチアプリケーションプラットフォームのための命令を生成する 装置であって、 少なくとも１つが外部ルーチンに対するコールを含んでいる機能ブロックと前 記ブロック間の論理フローとによりアプリケーションを定義する手段と、 前記ルーチンが当該実行可能命令によりコールされ得るようにするため、実行 可能命令を生成すべく前記定義されたアプリケーションを処理する手段と を有することを特徴とする装置。 ４４． コンパイルをするためにスピーチアプリケーションプラットフォーム 上へのダウンロードが可能な命令を生成する装置であって、 機能ブロックに論理接続された状態でアプリケーションをグラフィックで表示 するグラフィック手段と、 前記ブロック間の接続の有効性をテストし、前記ブロック の各々のためのテキストファイルを作成し、前記テキストファイルからスクリプ トファイルを作成し、前記スクリプトファイルからダウンロードが可能な命令を 作成するように構成された処理手段と を有することを特徴とする装置。 ４５． 前記スクリプトファイルを翻訳することによりアプリケーションの動 作をシミュレートする手段を有することを特徴とする請求項４４記載の装置。