【手続補正書】
【提出日】平成17年3月23日(2005.3.23)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【書類名】      明細書
【発明の名称】  オーディオ・ブラウザ部の動作方法及びシステム
【特許請求の範囲】
【請求項１】
オーディオ・ブラウザ部の動作方法であって、
（ａ）リクエストを受信するステップと、
（ｂ）前記リクエストに基づいて、音声マークアップを含んだドキュメントを取得するステップと、
（ｃ）パラメータ相互作用定義に従って前記ドキュメントを解釈するステップと、
を含むことを特徴とするオーディオ・ブラウザ部の動作方法。
【請求項２】
請求項１に記載の動作方法であって、
前記リクエストが、公衆電話網を介して受信されることを特徴とする動作方法。
【請求項３】
請求項１に記載の動作方法であって、
前記リクエストが、データ・ネットワークを介して受信されることを特徴とする動作方法。
【請求項４】
請求項１に記載の動作方法であって、
前記ドキュメントが、データ・ネットワークに接続されたサーバから取得されることを特徴とする動作方法。
【請求項５】
請求項１に記載の動作方法であって、
前記パラメータ相互作用定義が、前記ドキュメント中に示されていることを特徴とする動作方法。
【請求項６】
請求項１に記載の動作方法であって、
前記パラメータ相互作用定義が、データ・ネットワークに接続されたサーバ上に置かれていることを特徴とする動作方法。
【請求項７】
請求項６に記載の動作方法であって、
前記ドキュメントが前記データ・ネットワーク及び公衆電話網に接続された音声マークアップ言語（ＶＭＬ）ブラウザによって解釈され、
（ｄ）前記サーバから前記ＶＭＬブラウザによって前記パラメータ相互作用定義を受信するステップと、
（ｅ）前記パラメータ相互作用定義に基づいて、前記ＶＭＬブラウザによって前記ドキュメントを解釈するステップと、
を更に含むことを特徴とする動作方法。
【請求項８】
請求項１に記載の動作方法であって、
前記パラメータ相互作用定義が、有限状態マシンを定義していることを特徴とする動作方法。
【請求項９】
請求項８に記載の動作方法であって、
前記パラメータ相互作用定義を分析することにより、当該パラメータ相互作用定義が任意の無限ループを含んでいるか否かについて判断するステップを更に含むことを特徴とする動作方法。
【請求項１０】
請求項８に記載の動作方法であって、
前記パラメータ相互作用定義を分析することにより、処理がなくなった際に前記有限状態マシンの全ての状態がオーディオ・ブラウザ部を終了させるか否かを判断するステップを更に含むことを特徴とする動作方法。
【請求項１１】
請求項８に記載の動作方法であって、
ユーザ入力が無くなることによる相互作用の終了をどのくらいの長さ期間とるかを決定するステップを更に含むことを特徴とする動作方法。
【請求項１２】
請求項１に記載の動作方法であって、
前記リクエストが、公衆電話網に接続された電話機により受信されることを特徴とする動作方法。
【請求項１３】
請求項１に記載の動作方法であって、
前記ドキュメントがデータ・ネットワークに接続されたサーバに格納されており、当該ドキュメントは、前記データ・ネットワーク及び公衆電話網に接続された音声マークアップ言語（ＶＭＬ）ブラウザにより受信されたリクエストに基づいて、前記ＶＭＬブラウザによって前記サーバから取得されることを特徴とする動作方法。
【請求項１４】
ネットワークを利用したオーディオ・ブラウザ・システムであって、
前記ネットワークに接続されたオーディオ・ブラウザ部を備え、当該オーディオ・ブラウザ部が、音声マークアップ言語（ＶＭＬ）ブラウザを実行し、
前記ＶＭＬブラウザが、リクエストを受信して前記ネットワークを介してＶＭＬドキュメントを取得し、当該ＶＭＬドキュメントをパラメータ相互作用定義に従って解釈するように適合させたことを特徴とするオーディオ・ブラウザ・システム。
【請求項１５】
請求項１４に記載のオーディオ・ブラウザ・システムであって、
前記ＶＭＬブラウザに連結された相互作用定義サーバを更に備え、
前記相互作用定義サーバが、前記ＶＭＬブラウザから前記パラメータ相互作用定義に対するリクエストを受信して、前記リクエストのあったパラメータ相互作用定義を前記ＶＭＬブラウザへ送信するように適合させたことを特徴とするオーディオ・ブラウザ・システム。
【請求項１６】
請求項１５に記載のオーディオ・ブラウザ・システムであって、
前記相互作用定義サーバに連結されたデータベースを更に備え、
前記データベースが、前記パラメータ相互作用定義を格納し、当該データベースから前記相互作用定義サーバが当該パラメータ相互作用定義を取得することを特徴とするオーディオ・ブラウザ・システム。
【請求項１７】
請求項１４に記載のオーディオ・ブラウザ・システムであって、
前記リクエストは、公衆電話網を介して受信されることを特徴とするオーディオ・ブラウザ・システム。
【請求項１８】
請求項１４に記載のオーディオ・ブラウザ・システムであって、
前記リクエストは、データ・ネットワークを介して受信されることを特徴とするオーディオ・ブラウザ・システム。
【請求項１９】
請求項１４に記載のオーディオ・ブラウザ・システムであって、
前記パラメータ相互作用定義は、ＶＭＬドキュメント中に示されていることを特徴とするオーディオ・ブラウザ・システム。
【請求項２０】
請求項１４に記載のオーディオ・ブラウザ・システムであって、
前記パラメータ相互作用定義は、前記ネットワークに接続されたサーバ上に置かれていることを特徴とするオーディオ・ブラウザ・システム。
【請求項２１】
請求項１４に記載のオーディオ・ブラウザ・システムであって、
前記パラメータ相互作用定義が、有限状態マシンを定義していることを特徴とするオーディオ・ブラウザ・システム。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は、ネットワーク上の音声の相互作用を意図している。特に、本発明は、パラメータ相互作用定義を用いるネットワーク上の音声の相互作用を意図している。
【０００２】
【従来技術】
通信網で使用できる情報量は、巨大であり、すごい速さで増加している。このようなネットワークのなかで最も普及しているのが、全世界にわたってリンクされたコンピュータのネットワークである、インターネットである。インターネットの大半は、インターネットのワールド・ワイド・ウェブ（ＷＷＷ）に関係している。ＷＷＷは、情報がハイパーテキスト転送プロトコル（ＨＴＴＰ）を用いるクライアント・コンピュータとサーバ・コンピュータとの間で一般的に送受信されるインターネットの部分である。サーバは、情報を保存して、クライアントからのリクエストに応答してクライアントに情報を提供する（すなわち、送信する）。クライアントは、情報のリクエストと表示を支援する、しばしばブラウザと呼ばれる、コンピュータ・ソフトウェア・プログラムを実行する。ＷＷＷブラウザの例として、ネットエスケープ・コミュニケーション社(Netscape Communications,Inc.)から入手できるネットスケープ・ナビゲーター(Netscape Navigator)（登録商標）と、マイクロソフト社(Microsoft Corp.) から入手できるインターネット・エクスプローラ(Internet Explorer) （登録商標）がある。
【０００３】
サーバと、そこに保存してある情報は、ユニフォーム・リソース・ローケータ（ＵＲＬ）を介して識別される。ＵＲＬは、Ｂｅｒｎｅｒｓ−Ｌｅｅ、Ｔ．，などのＵｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒｓ、ＲＦＣ  １７３８、Ｎｅｔｗｏｒｋ  Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ、１９９４に詳細に記してあり、ここで引例によって包含されている。例えば、ＵＲＬ  ｈｔｔｐ：／／ｗｗｗ．ｈｏｓｔｎａｍｅ．ｃｏｍ／ｄｏｃｕｍｅｎｔ．ｈｔｍｌは、ホスト・サーバ“ｗｗｗ．ｈｏｓｔｎａｍｅ．ｃｏｍ”のドキュメント“ｄｏｃｕｍｅｎｔ１．ｈｔｍｌ”を識別する。従って、クライアントによるホスト・サーバからの情報のリクエストはＵＲＬを全体的に含んでいる。クライアントにサーバから渡された情報は、ドキュメントと全体的に呼ばれている。このようなドキュメントは、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）のように、ドキュメント言語で全体的に定義されている。クライアントからのリクエスト時に、サーバはＨＴＭＬドキュメントをクライアントに送る。ＨＴＭＬドキュメントはブラウザで解釈される情報を含んでいるので、表示する内容は、コンピュータ・ディスプレイ・スクリーンでユーザに表示できる。ＨＴＭＬドキュメントは、テキスト、論理構造コマンド、ハイパーテキスト・リンク、ユーザ入力コマンドのような情報を含むことができる。ユーザがディスプレイからハイパーテキスト・リンクを（例えば、マウス・クリックを用いて）選択すると、ブラウザは、サーバから別のドキュメントをリクエストする。
【０００４】
【発明が解決しようとする課題】
いま、殆どのＷＷＷブラウザは、テキストとグラフィックのユーザ・インタフェースに基づいている。従って、ドキュメントはコンピュータ・スクリーン上に画像として表示される。このような画像は、例えば、テキスト、グラフィック、ハイパーテキスト・リンク、ユーザ入力対話ボックスを含んでいる。ＷＷＷとのユーザの相互作用の大半は、グラフィック・ユーザ・インタフェースを介して行われる。オーディオ・データは、ユーザ・コンピュータで受信して再生できるが（例えば、ａ  ．ｗａｖ  又は  ．ａｕ  のファイル）、このようなオーディオ・データの受信はＷＷＷのグラフィック・インタフェースにとって２次的なものである。従って、殆どのＷＷＷブラウザでは、オーディオ・データがユーザリクエストの結果として受信できるが、ユーザがオーディオ・インタフェースを用いてＷＷＷと相互作用できる手段がない。
【０００５】
オーディオ・ブラウザ・システムは、１９９６年４月２２日に提出されたオーディオ・インタフェースを用いる情報検索の装置と方法という名称で、ＡＴ＆Ｔ社（ＡＴ＆Ｔ  Ｃｏｒｐ．）に譲渡された、米国特許出願第０８／６３５，６０１号に開示してあり、ここで引例によって包含されている（以降“ＡＴ＆Ｔ”オーディオ・ブラウザ特許と呼ぶ）。開示されたオーディオ・ブラウザ・システムは、ユーザが、オーディオ・インタフェース・デバイスを用いてインターネットに接続したサーバ・コンピュータ上でドキュメントにアクセスすることを可能にする。
【０００６】
ＡＴ＆Ｔオーディオ・ブラウザ特許に開示してある１つの実施例では、オーディオ・インタフェース・デバイスは、オーディオ・ブラウザ部で実行される集中オーディオ・ブラウザにアクセスする。オーディオ・ブラウザは、インターネットに接続できるサーバ・コンピュータからドキュメントを受信する。ドキュメントは、オーディオ・インタフェース・デバイスでの使用を可能にする特殊な命令も含むことができる。特殊な命令は一般的にＨＴＭＬと似ている。特殊な命令により、ブラウザは、書き込んであるテキストからオーディオ出力を生成するか、又はＤＴＭＦトーン又は自動スピーチ認識を介してユーザから入力を受け取ることができる。
【０００７】
集中ブラウザを搭載するオーディオ・ブラウザ・システムで生じる問題は、ユーザ・データを入力する際に、ユーザとブラウザとに関連する事象の複雑なシーケンスがしばしば必要になることである。これらの事象は、例えば、（ａ）入力をユーザに促す、（ｂ）入力の選定を数える、（ｃ）更なる入力をユーザに促す、（ｄ）前の入力が不適正であるか又は合致しないことをユーザに知らせることを含んでいる。我々は、ユーザがブラウザと相互作用する時に発生する事象に関して許容できるシーケンスを定めるために、集中ブラウザをプログラム設定して汎用化することが望ましいことに気づいた。しかし、ブラウザをプログラム設定して汎用化する時に、偶発的なエラーと悪意によるプログラミングの両方に起因する実行性能の問題を最小にすることが重要になる。
【０００８】
あるこのような問題として、汎用化したブラウザは、例えば、汎用化に無限ループが含まれている場合に対応できないことである。ブラウザの性能が低下することに加えて、ブラウザが行う他の動作に悪い影響を及ぼし、このようなループは、電話呼出を長時間にし、困ったことに呼出コストを増大させると同時に、ブラウザに対する他の呼出者のアクセスを拒否する可能性がある。
【０００９】
別の問題は、“サービスの拒絶”アタックと呼ばれている。これは、呼出者が、任意の入力を提示せずに、呼出を接続状態に維持することを可能にするように、ブラウザが汎用化される場合に、アタッカーが容易に実行できることにある。
【００１０】
これらの実行性能の問題の一部は、非集中ブラウザについては、それほど重大にならない。なぜならば、不十分な状態で汎用化された非集中ブラウザは、ブラウザを実行しているコンピュータとコンピュータの電話回線とだけに通常は影響するので、プログラム設定上のエラーが効果的に回避されるからである。
【００１１】
しかし、ＡＴ＆Ｔオーディオ・ブラウザ特許に開示してあるオーディオ・ブラウザ・システムの集中ブラウザ実施例と任意の集中ブラウザとでは、集中ブラウザを実行しているオーディオ・ブラウザ部が実行性能の問題を抱えている時には、問題の否定的な影響が益々悪化することになる。オーディオ・ブラウザ・システムでは、複数のユーザが多重オーディオ・インタフェース・デバイスを介して同じオーディオ・ブラウザ部にアクセスするので、多くのユーザは、オーディオ・ブラウザ部が実行性能の問題を抱えている場合に否定的な影響を受けることになる。従って、オーディオ・ブラウザ・システムでは、実行性能の問題を最小にすることが望ましい。
【００１２】
最も知られているブラウザに伴う別の問題は、クライアント・コンピュータのブラウザに入力したデータは、データの検証と検査が行われるサーバに通常は送られることにある。例えば、ユーザがブラウザ上でコンピュータ設定したフィルインフォームにキーボードを介して入力すると、そのデータは、フォームが正しく書き込まれたことを検証するインターネット・サーバに通常は送られる（すなわち、全ての必要な情報が入力された、必要な桁数が入力されたなど）。フォームが不適正に書き込まれていた場合、サーバはエラー・メッセージをクライアントに通常は送り、ユーザはエラーの訂正を試みる。
【００１３】
しかし、オーディオ・ブラウザ・システムでは、ユーザが入力したデータは、しばしばスピーチの形態になる。スピーチは、スピーチ認識を用いて音声データ又は音声ファイルに変換される。しかし、スピーチ認識を用いて音声データを得ることは、キーボードを介してエントリによるデータを得ることほど正確でない。従って、データの検証と検査も、それをスピーチ認識を用いて入力する時に必要になる。更に、スピーチから変換した音声ファイルはキーボードから入力したデータと比べると一般的に大きいので、これは、インターネット・サーバにオーディオ・ブラウザ部から音声ファイルを頻繁に送ることを難しくする。従って、オーディオ・ブラウザ・システムのブラウザの入力データを、できるだけ検証して検査し、音声データがインターネット・サーバに送られる回数を最小限にすることが望ましい。
【００１４】
前述のことから、ブラウザを実行するオーディオ・ブラウザ部の実行性能の問題が最小になり、入力データがインターネット・サーバの代わりにブラウザで通常は検証され検査される、オーディオ・ブラウザ・システムが必要になる。
【００１５】
【課題を解決するための手段】
本発明のある実施例によれば、オーディオ・ブラウザ部は音声マークアップ言語ブラウザを実行する。オーディオ・ブラウザ部は音声相互作用のリクエストを受信する。このリクエストに基づいて、ネットワーク・ノードがドキュメントを入手する。ドキュメントは、音声マークアップ、及びユーザ相互作用が必要になる時に、パラメータ相互作用定義又はパラメータ相互作用定義に対する少なくとも１つのリンクとを含んでいる。オーディオ・ブラウザ部は、パラメータ相互作用定義に従ってドキュメントを解釈する。
【００１６】
パラメータ相互作用定義を用いて、入力データは、ネットワーク・サーバの代わりにオーディオ・ブラウザ部で一般的に検証される。更に、ある実施例では、パラメータ相互作用定義は有限状態マシンを定義できる。この実施例では、パラメータ相互作用定義を分析することができたことによって、オーディオ・ブラウザ部の実行性能の問題が最小になっている。
【００１７】
【実施例】
図１は、本発明の１つの実施例の実施に適した通信システムの図を示す。オーディオ・インタフェース・デバイスは、電話１１０のように、局部交換キャリア（ＬＥＣ）１２０に接続している。電話以外のオーディオ・インタフェース・デバイスも使用できる。例えば、オーディオ・インタフェース・デバイスは電話機能を有するマルチメディア・コンピュータになる場合もある。ある実施例では、電話１１０のユーザは、ドキュメント・サーバ１６０のように、ドキュメント・サーバが呈する情報に関係する電話番号に電話呼出を設定して、情報をリクエストする。ユーザは、コンピュータのように、オーディオ・インタフェース・デバイスとして機能する任意のデバイスを用いて、情報をリクエストすることもできる。
【００１８】
図１に示す実施例では、ドキュメント・サーバ１６０は通信網１６２の一部である。好ましい実施例では、通信網１６２はインターネットである。ドキュメント・サーバ１６０のように、ドキュメント・サーバを介してアクセスできる情報に関連付けられた電話番号は、それらが、オーディオ・ブラウザ部１５０のように、特殊な通信網ノードに経路指定されて送られるように設定される。
【００１９】
図１に示す実施例では、オーディオ・ブラウザ部１５０は、長距離電話網である通信網１０２におけるノードである。従って、呼出は、ＬＥＣ  １２０に経路指定して送られ、それは更に呼出を長距離キャリア・スイッチ１３０にトランク１２５を介して送る。長距離網１０２は、呼出を送るためにスイッチ１３０と類似する他のスイッチを全体的に備えている。しかし、１つのスイッチだけ明確にするために図１に図示してある。通信網１０２のスイッチ１３０は、種々の機能を行うようにプログラム設定できる処理ユニット１３１を搭載している（又はそれに接続している）ので“インテリジェント”スイッチであることに注目すべきである。通信網スイッチにおける処理ユニットのこのような使用と、そのプログラム設定とは、従来技術で周知のことである。
【００２０】
スイッチ１３０で呼出を受信すると、呼出はオーディオ・ブラウザ部１５０に経路指定して送られる。そこで、電話１１０とオーディオ・ブラウザ部１５０との間にオーディオ・チャンネルが構築される。通信網を介する呼出の経路指定は、従来技術で周知のことなので、これ以上ここでは説明しない。
【００２１】
電話１１０から呼出とリクエストを受信すると、オーディオ・ブラウザ部１５０は、リンク１６４を経由して呼び出された電話番号に関連付けられたドキュメント・サーバ１６０と通信チャンネルを構築する。ＷＷＷ実施例において、リンク１６４は、ＴＣＰ／ＩＰのソケット接続部であり、その構築は従来技術で周知のことである。ＴＣＰ／ＩＰについての詳細は、１９８８、Ｅｎｇｌｅｗｏｏｄ  Ｃｌｉｆｆｓ、ＮＪ、Ｐｒｅｎｔｉｃｅ  ＨａｌｌのＴＣＰ／ＩＰ：原理とプロトコルと構造によるインターネット・ワーク、Ｃｏｍｅｒ、Ｄｏｕｇｌａｓを参照すること。これは、ここで引例によって包含されている。オーディオ・ブラウザ部１５０とドキュメント・サーバ１６０とは、ドキュメント・サーブ・プロトコルを用いて互いに通信する。ここで示すように、ドキュメント・サーブ・プロトコルは、クライアントとサーバとの間の情報転送のための通信プロトコルである。このようなプロトコルに従って、クライアントは、サーバにリクエストを送って、サーバからの情報をリクエストし、サーバは、サーバにリクエストされた情報を含んでいるドキュメントを送って、リクエストに応答する。従って、ドキュメント・サーブ・プロトコル・チャンネルが、リンク１６４を介してドキュメント・サーバ１６０とオーディオ・ブラウザ部１５０との間に構築される。好ましいＷＷＷ実施例では、ドキュメント・サーブ・プロトコルはハイパーテキスト転送プロトコル（ＨＴＴＰ）である。このプロトコルは、ＷＷＷ通信の従来技術では周知のことであり、Ｂｅｒｎｅｒｓ−Ｌｅｅ、Ｔ．とＣｏｎｎｏｌｌｙ、Ｄ．，のインターネット・エンジニアリング・タスク・フォースのハイパーテキスト転送プロトコル（ＨＴＴＰ）ワーク・ドラフト、１９９３に詳細に記してあり、ここに引例によって包含されている。
【００２２】
従って、オーディオ・ブラウザ部１５０は、ＨＴＴＰプロトコルを用いてドキュメント・サーバ１６０と通信する。従って、ドキュメント・サーバ１６０に関する限り、ちょうど従来のグラフィック・ブラウザを実行している任意の従来のＷＷＷクライアントと通信しているように作動する。そこで、ドキュメント・サーバ１６０は、リンク１６４上で受信するリクエストに応答して、オーディオ・ブラウザ部１５０にドキュメントを送る。ここで用いるドキュメントは情報の集まりである。ドキュメントは、ドキュメントがサーバ１６０で予め定義してあり、そのドキュメントの全てのリクエストが同じ情報の処理になるので、静的ドキュメントである。代わりに、ドキュメントが動的ドキュメントになることもあり、その場合、リクエストに対応して処理される情報は、リクエスト時に動的に生成される。一般的に、動的ドキュメントは、情報のリクエストに対応して、サーバ１６０が実行するプログラムである、スクリプトによって生成する。例えば、ＵＲＬはスクリプトに関連付けられるものとする。サーバ１６０がそのＵＲＬを含んでいるリクエストを受信すると、サーバ１６０は、スクリプトを実行して動的ドキュメントを生成し、動的に生成したドキュメントを情報をリクエストしていたクライアントに送る。動的スクリプトは、コモン・ゲートウェイ・インタフェース（ＣＧＩ）を用いて一般的に実行される。スクリプトを用いてドキュメントを動的に生成することは、従来技術で周知のことである。
【００２３】
更に次に述べるように、本発明によれば、サーバ１６０が処理するドキュメントは、オーディオ・ブラウザ部１５０が解釈する命令である、音声マークアップを備えている。オーディオ・ブラウザ部１５０と電話１１０のユーザとの間の相互作用を促すために、ある実施例では、音声マークアップがパラメータ相互作用定義とのリンクを備えている。パラメータ相互作用定義についての詳細は次に述べる。リンクがオーディオ・ブラウザ部１５０で解釈される時に、該当するパラメータ相互作用定義が呼び出される。別の実施例では、パラメータ相互作用定義はドキュメント内に含まれている。
【００２４】
ある実施例では、音声マークアップとパラメータ相互作用定義とが、ＨＴＭＬに基づく言語で書き込まれるが、オーディオ・ブラウザ部１５０に相応して特別に適応されている。ＨＴＭＬのような音声マークアップ命令の１つの事例は、ＡＴ＆Ｔオーディオ・ブラウザ特許に記載する“オーディオ−ＨＴＭＬ”である。
【００２５】
ＨＴＭＬドキュメントが従来のＷＷＷブラウザを実行しているクライアントによって受信されると、ブラウザは、ＨＴＭＬドキュメントを画像に解釈（インタープリタ）して、画像をコンピュータ・ディスプレイ・スクリーンに表示する。しかし、図１に示すオーディオ・ブラウザ・システムでは、ドキュメント・サーバ１６０からドキュメントを受信すると、オーディオ・ブラウザ部１５０は、ドキュメントに存在する音声マークアップ命令の一部を、スピーチにテキストを使用するように、既知の方式でオーディオ・データに変換する。この変換の更なる詳細がＡＴ＆Ｔオーディオ・ブラウザ特許に記載してある。オーディオ・データは、スイッチ１３０とＬＥＣ  １２０とを経由して電話１１０に送られる。従って、このように、電話１１０のユーザは、オーディオ・インタフェースを介してドキュメント・サーバ１６０から情報にアクセスできる。
【００２６】
更に、ユーザは、オーディオ・ユーザ入力を電話１１０からオーディオ・ブラウザ部１５０に送り返すことができる。このオーディオ・ユーザ入力は、例えば、スピーチ信号又はＤＴＭＦトーンになる。オーディオ・ブラウザ部１５０は、既知の方式でＨＴＴＰプロトコルに従ってリンク１６４を介してドキュメント・サーバ１６０に伝送することに適している命令又はユーザ・データに、オーディオ・ユーザ入力を変換する。このような変換の更なる詳細は、ＡＴ＆Ｔオーディオ・ブラウザ特許に記してある。ユーザ・データ又は命令は、ドキュメント・サーブ・プロトコル・チャンネルを介してドキュメント・サーバ１６０に送られる。従って、ドキュメント・サーバとのユーザの相互作用が、オーディオ・ユーザ・インタフェースを経由することになる。
【００２７】
パラメータ相互作用定義は、どのようにして入力がプロンプトとフィードバックとタイムアウトとを介してオーディオ・インタフェース・デバイス１１０にユーザから集められるかについて指定する、所定のルーチンである。パラメータ相互作用定義は、ドキュメントがオーディオ・ブラウザ部１５０上で実行しているオーディオ・ブラウザ（“音声マークアップ言語”（ＶＭＬ）ブラウザと呼ばれる）で解釈される時に、ドキュメントの特定の音声マークアップ命令によって呼び出される。ある実施例では、命令に基づいてパラメータ相互作用定義とのリンクを定義する。パラメータ相互作用定義は、ドキュメントの内部又は図１に示すオーディオ・ブラウザ・システム内のどこにでも（例えば、ドキュメント・サーバ１６０、オーディオ・ブラウザ部１５０、又はオーディオ・ブラウザ部１５０に連結された任意の他の記憶装置）位置することができる。ある実施例では、パラメータ相互作用定義は、相互作用定義サーバに連結されたデータベースに保存される。相互作用定義サーバはＶＭＬブラウザに連結されているので、パラメータ相互作用定義は、リクエスト時にＶＭＬブラウザで使用できる。更に、パラメータ相互作用定義は音声マークアップ命令の一部になる場合もあり、そのケースで、リンクは不要になる。
【００２８】
例えば、ユーザがメニュー・オプションのリストから１つの選択を行うことを可能にする、パラメータ相互作用定義がある。このパラメータ相互作用定義は、“ＭＥＮＵ＿ＩＮＴＥＲＡＣＴ．”という名称である。ドキュメントにこの相互作用が必要になる部分が含まれる場合に、“Ｃａｌｌ  ＭＥＮＵ＿ＩＮＴＥＲＡＣＴ、パラメータ１、パラメータ２”のような相互作用を呼び出す、音声マークアップ命令を書き込むことができる。この音声マークアップは、ＶＭＬブラウザで解釈される時に、“ＭＥＮＵ＿ＩＮＴＥＲＡＣＴ”という名称のパラメータ相互作用定義を呼び出して、それをパラメータ１と２に渡す。
【００２９】
パラメータ相互作用定義は、本発明において前述の長所を可能にするものである（すなわち、オーディオ・ブラウザ部の実行性能の問題を最小にし、インターネットのサーバの代わりにオーディオ・ブラウザ部で入力データを検証して検査する）。パラメータ相互作用定義は、集中オーディオ・ブラウザの状態に相応して、それを変更し、これらの長所を実現する。
【００３０】
特に、ある実施例では、パラメータ相互作用定義で有限状態マシンを定義する。有限状態マシンは、既知の技術を用いて実行される前に完全に分析できることは周知のことである。分析から、例えば、ユーザがハングアップせず且つ任意の入力を示さない場合に、パラメータ相互作用定義が終了するかどうかについて決定できる。そこで、ユーザが、なにもせずに漠然とＶＭＬブラウザを独占することを防止する。更に、分析から、パラメータ相互作用定義の全ての部分又は状態にユーザが到達できるかどうかについて決定できる。更に、分析から、パラメータ相互作用定義が、無限ループを導く出口点に誘導しない部分、又は状態を含んでいるかどうかについて決定できる。これらの状態は、パラメータ相互作用定義がＶＭＬブラウザ又はオーディオ・ブラウザ部１５０によって解釈又は実行される前に訂正又は削除できる。これらの分析ツールを使用するので、パラメータ相互作用定義を用いるオーディオ・ブラウザ・ドキュメントの開発者は、ドキュメントがユーザ相互作用をリクエストする時に、分析した相互作用定義を実施することによって、ブラウザに対する中断が最小限になることが保証される。
【００３１】
更に、パラメータ相互作用定義はユーザ入力の検証も行う。従って、パラメータ相互作用定義がオーディオ・ブラウザ部１５０で解釈されるので、ユーザ入力を検証のためにインターネット・サーバに送る必要性が最小限になる。そこで、ユーザ入力は相対的に大きい音声ファイルからしばしば構成しているので、時間と通信コストが節約できる。
【００３２】
パラメータ相互作用定義について考えられるタイプの幾つかの例として、下記がある。
（ａ）メニュー：  ユーザがメニュー・オプションのリストから１つの選定を行う場合
（ｂ）マルチメニュー：  ユーザがオプションのサブセットを選択する場合
（ｃ）テキスト：  ユーザが文字列を提示しなければならない場合
（ｄ）桁：  ユーザが、長さが優先と決定されていない、桁のシーケンスを提示しなければならない場合
（ｅ）桁限定：  ユーザが所定の桁数を入力しなければならない場合
（ｆ）記録：  ユーザの音声がオーディオ・ファイルに記録される場合
【００３３】
図２は、パラメータ相互作用定義の包括的な形態を示す。
【００３４】  
ライン２００では、相互作用タイプ“ｉｎｔｅｒａｃｔｉｏｎ＿ｔｙｐｅ”の“ｉｎｔｅｒａｃｔｉｏｎ＿ｎａｍｅ”という名前の相互作用を定義する。更に、ライン２００では、相互作用に用いる全てのメディアを宣言する。ライン２００で宣言したメディアは、自動スピーチ認識（ＡＳＲ）とタッチ・トーン又はＤＴＭＦ（ＴＴ）と記録（ＲＥＣ）とを備えている。
【００３５】
ライン２０２では属性パラメータの数を定義する。属性パラメータは、相互作用のパラメータ化のために用いられ、相互作用を呼び出す音声マークアップ命令に含まれている。パラメータが音声マークアップ命令に含まれていない場合に、デフォルト値、“ｄｅｆａｕｌｔ＿ｖａｌｕｅ”をパラメータとして用いる。
【００３６】
ライン２０４ではメッセージ・パラメータの数を定義する。メッセージ・パラメータは、状態マシン内の仮位置ホルダとして使用し、相互作用を用いる時に指定したプロンプトとメッセージを含めることができる。メッセージ・パラメータも、相互作用のパラメータ化に用いられ、相互作用を呼び出す音声マークアップ命令に含まれている。
【００３７】
ライン２０６では、カウンタ変数宣言の数を定義する。各々カウンタは初期値で宣言される。オペレーションから、この変数が、固定初期値（通常は１０未満）から減少して、０について試験することが可能になる。
【００３８】
ライン２０８では、ブーリアン変数宣言の数を定義する。各々ブーリアン変数は初期値から宣言される。
【００３９】
ライン２１０では、多数の状態宣言を定義する。各々状態は、次の（１）、（２）に示す構造のうちの１つを備えている。
（１）アクション：  アクションは、直ちにあるいは作動可能な事象の結果として、状態を変更するためにスピーチとコードとを合成したメッセージから成る。起動される入力モードも指定される。例えば、タイプ・メニューの相互作用に対して定義される入力モードｔｔｍｅｎｕは、桁を入力するユーザの結果として生じるオプションの選定を指示する事象を指定する。各事象は事象の変化で説明され、この事象の変化が、その事象が発生した際に実施される側面的な作用を明示している。
（２）条件付き表現：  アクションが変数の設定に従属することを可能にする。従って、条件付き表現は、他の構造がある場合に、埋め込まれているアクションから構成することになる。
【００４０】
前述の言語で定義した相互作用は、その総状態スペースが種々の変数の値と今の状態との積である、有限状態マシンと考えることができる。
【００４１】
図３Ａ、図３Ｂ及び図３Ｃは、パラメータ相互作用定義の例である。図３Ａを見ると、ライン３００では、パラメータ相互作用の名前とメニューとして相互作用タイプを定義する。ライン３０２では、その属性パラメータを定義する。ライン３０４とライン３０６ではカウンタ変数を定義する。ライン３０８、ライン３１０、ライン３１２、ライン３１４、ライン３１６及びライン３１８では、メッセージ・パラメータの始まりを指示する。
【００４２】
図３Ｂを見ると、ライン３２０、ライン３２２及びライン３２４では、種々の状態の始まりを指示する。
【００４３】
図３Ｃを見ると、ライン３２６、ライン３２８及びライン３３０では、種々の状態の始まりを指示する。最後に、ライン３３２ではパラメータ相互作用定義の終わりを指示する。
【００４４】
図３Ｂのライン３２０から始まる“初期”状態の更なる詳細について述べる。図３Ｂ及び図３Ｃに示す他の状態は同様に機能する。
【００４５】
まず、相互作用に関連付けられた状態マシンは“初期”状態にあり、２つのカウンタ変数ＴＴＥＲＲＣＯＵＮＴとＴＯＣＯＵＮＴが、各々、ＭＡＸＴＴＥＲＲＯＲとＭＡＸＴＯに初期設定される。これらの変数は、相互作用定義を用いる時にパラメータによって明示的に無効にならないならば、各々、３と２になる。“初期”状態は、メッセージＰＲＯＭＰＴ（実際の値が相互作用の使用前の音声マークアップ・ドキュメントのテキストである一般的なパラメータ）は、タッチトーン・コマンド・モード（ＴＴ）とタッチトーン・メニュー選択モード（ＴＴＭＥＮＵ）とが起動されながら、合成されることを指定する。これらの起動によって、事象ＴＴＭＥＮＵ  ＣＯＬＬＥＣＴとＴＴ  ＩＮＰＵＴ＝“ＨＥＬＰＴＴ”とが各々発生することになる。第１種の事象で、メニュー・オプション選択を指定する桁入力を表す。第２種の事象で入力“ＨＥＬＰＴＴ”（デフォルトが“＃＃”）を特に表す。第１種の事象が現れると、有限状態マシンの次の状態が“ｅｃｈｏｃｈｏｉｃｅ”になる。第２の事象が最初に現れると、次の状態が“ｈｅｌｐ”になる。意味のないタッチトーンが現れると、事象ＴＴＦＡＬＬに関連する事象変化で、ＴＴＥＲＲＣＯＵＮＴが減少して、次の状態が“ｎｏｔｖａｌｉｄ”であることを指定する。
【００４６】
この３つの事象のいずれも“ＩＮＡＣＴＩＶＩＴＹＴＩＭＥ”が指示する時間の周期内に発生しない場合、事象ＴＩＭＥＯＵＴが現れ、ＴＴＥＲＲＣＯＵＮＴが減少され、次の状態が“ｉｎａｃｔｉｖｉｔｙ”になる。
【００４７】
前述のように、本発明のＶＭＬブラウザは、パラメータ相互作用定義に従ってドキュメントを解釈する。パラメータ相互作用定義により、オーディオ・ブラウザ・システムが、オーディオ・ブラウザ部の実行性能の問題を最小にして、インターネット・サーバの代わりにオーディオ・ブラウザ部で入力データを検証することを可能にする。
【００４８】
更に、パラメータ相互作用定義は、ユーザ入力のシーケンスとシステム応答とを指定して制御できるフィールド（すなわち、“ＨＥＬＰＴＴ”フィールド）の入力のための対話を定める。各々ユーザ生成事象は、ユーザが行うキー押込み動作又は発声のように、パラメータ相互作用定義によって制御され応答される。
【００４９】
【発明の効果】
前述の詳細な説明は、全て各々図解と例示として理解すべきであり、拘束するものでない。ここで開示した本発明の範囲は、詳細な説明から決まるものでなく、むしろ、特許法に完全に基づいて解釈される特許請求の範囲から決定される。ここで図示し説明した実施例は本発明の原理を図示するだけであり、種々の変更が本発明の範囲と精神から逸脱せずに当業者が実施できることを理解すべきである。例えば、図１に示したオーディオ・ブラウザ・システムは、オーディオ・ブラウザ部１５０の集中ブラウザとしてＶＭＬブラウザを実行する。しかし、本発明は、ＡＴ＆Ｔオーディオ・ブラウザ特許に開示してある全ての実施例を含めて、オーディオ・ブラウザ・システムの他の実施例と共に実施できる。
【図面の簡単な説明】
【図１】
本発明の１つの実施例の実施に適した通信システムの図を示す図である。
【図２】
パラメータ相互作用定義の包括的な形態を示す図である。
【図３Ａ】
パラメータ相互作用定義の一例を示す図その１である。
【図３Ｂ】
パラメータ相互作用定義の一例を示す図その２である。
【図３Ｃ】
パラメータ相互作用定義の一例を示す図その３である。
【符号の説明】
１０２  通信網
１１０  電話
１２０  局部交換キャリア（ＬＥＣ）
１２５  トランク
１３０  長距離キャリア・スイッチ
１３１  処理ユニット
１５０  オーディオ・ブラウザ部
１６０  ドキュメント・サーバ
１６２  通信網
１６４  リンク