特許 5883841 片方向通信を使用する分散型音声認識

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5883841

(24)【登録日】2016年2月12日

(45)【発行日】2016年3月15日

(54)【発明の名称】片方向通信を使用する分散型音声認識

(51)【国際特許分類】

   G10L 15/22 20060101AFI20160301BHJP

   G10L 15/30 20130101ALI20160301BHJP

【ＦＩ】

   G10L15/22 200Z

   G10L15/30

【請求項の数】10

【外国語出願】

【全頁数】17

(21)【出願番号】特願2013-229237(P2013-229237)

(22)【出願日】2013年11月5日

(62)【分割の表示】特願2011-525266(P2011-525266)の分割

【原出願日】2009年8月31日

(65)【公開番号】特開2014-56258(P2014-56258A)

(43)【公開日】2014年3月27日

【審査請求日】2013年11月11日

(31)【優先権主張番号】61/093,221

(32)【優先日】2008年8月29日

(33)【優先権主張国】US

(31)【優先権主張番号】12/550,381

(32)【優先日】2009年8月30日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】512191960

【氏名又は名称】エムモーダル アイピー エルエルシー

(74)【代理人】

【識別番号】100079108

【弁理士】

【氏名又は名称】稲葉 良幸

(74)【代理人】

【識別番号】100109346

【弁理士】

【氏名又は名称】大貫 敏史

(72)【発明者】

【氏名】カロー，エリック

(72)【発明者】

【氏名】コール，デトレフ

【審査官】 上田 雄

(56)【参考文献】

【文献】 特開２００８−１４５６７６（ＪＰ，Ａ）

【文献】 特開２００３−０５０５９４（ＪＰ，Ａ）

【文献】 特開２００３−０４４０９３（ＪＰ，Ａ）

【文献】 特開２００３−１４０６９１（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ１０Ｌ １５／００−１５／３４

(57)【特許請求の範囲】

【請求項1】

（Ａ）音声認識サーバにおいて、
（Ａ１）クライアントから音声ストリーム及び制御ストリームを含むストリームを受信するステップと、
（Ａ２）自動音声認識エンジンを使用して、前記音声ストリームの第１の部分を認識し、それにより、第１の音声認識結果を生成するステップと、
（Ｂ）前記音声認識サーバにおいて、前記第１の音声認識結果が、前記制御ストリームにより特定される第１の所定の基準を満足させる場合に、（Ｃ）に進む前に、前記音声認識エンジンが再構成されるまで待つステップと、
（Ｃ）前記音声認識サーバにおいて、前記自動音声認識エンジンを使用して、前記音声ストリームの第２の部分を認識し、それにより、第２の音声認識結果を生成するステップとを含むコンピュータで実施される方法。

【請求項2】

（Ｄ）クライアントにおいて、（Ａ）の前に、前記音声ストリームおよび前記制御ストリームを含む前記ストリームを前記音声認識サーバに送信するステップをさらに含む、請求項１に記載の方法。

【請求項3】

（Ｅ）前記クライアントにおいて、音声認識結果を求める要求を前記サーバに送信するステップと、
（Ｆ）前記サーバにおいて、
（Ｆ）（１）任意の音声認識結果が利用可能かどうか判定するステップと、
（Ｆ）（２）音声認識結果が利用可能でない場合に、（Ｆ）（１）に戻るステップと、
（Ｆ）（３）そうでない場合には、前記音声認識結果のうちの少なくとも１つを前記クライアントに送信するステップとをさらに含む、請求項２に記載の方法。

【請求項4】

前記サーバが、（Ｆ）と並列に（Ｂ）を実行する、請求項３に記載の方法。

【請求項5】

（Ａ）が、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を使用して、前記音声ストリームおよび前記制御ストリームを送信するステップを含み、（Ｅ）が、ＨＴＴＰを使用して、前記音声認識結果を求める前記要求を送信するステップを含む、請求項３に記載の方法。

【請求項6】

（Ａ）が、セキュア・ソケット・レイヤ上でのハイパーテキスト転送プロトコル（ＨＴＴＰＳ）を使用して、前記音声ストリームおよび前記制御ストリームを送信するステップを含み、（Ｅ）が、ＨＴＴＰＳを使用して、前記音声認識結果を求める前記要求を送信するステップを含む、請求項３に記載の方法。

【請求項7】

（Ｄ）が、
（Ｄ）（１）前記クライアントが、前記制御ストリーム内の第１の制御メッセージを前記音声認識サーバに送信するステップと、
（Ｄ）（２）前記第１の部分の前記伝送の障害を検出するステップと、
（Ｄ）（３）前記障害の検出に応答して、
（Ｄ）（３）（ａ）前記第１の制御メッセージによって表される第１の状態変更と第２の状態変更との組合せを指定する、第２の制御メッセージを生成するステップと、
（Ｄ）（３）（ｂ）前記制御ストリーム内の前記第２の制御メッセージを前記音声認識サーバに送信するステップとを含む、請求項２に記載の方法。

【請求項8】

（Ｂ）は、（Ｃ）に進む前に、前記自動音声認識エンジンが所定の構成状態になるまで待つステップを含む、請求項１に記載の方法。

【請求項9】

（Ｂ）はさらに、（Ａ）の後に、前記制御ストリーム内の制御メッセージのうちの１つを実行して、前記音声認識エンジンを再構成するステップを含む、請求項１に記載の方法。

【請求項10】

クライアントから音声ストリーム及び制御ストリームを含むストリームを受信するための、受信手段と、
自動音声認識エンジンを使用して、前記音声ストリームの第１の部分を認識し、それにより、第１の音声認識結果を生成するための、第１の部分の認識手段と、
前記第１の音声認識結果が、前記制御ストリームにより特定される第１の所定の基準を満足させる場合、第２の部分の認識手段をアクティブにする前に、前記音声認識エンジンが再構成されるまで待つための、待ち手段と、
前記自動音声認識エンジンを使用して、前記音声ストリームの第２の部分を認識し、それにより、第２の音声認識結果を生成するための、第２の部分の認識手段とを備える装置。

【発明の詳細な説明】

【背景技術】

【0001】

音声をテキストに変換することや、音声に応答してコンピュータの操作を制御することなどの機能を実行するための、様々な自動音声認識装置（ＡＳＲ）が存在する。自動音声認識装置の用途によっては、エンド・ユーザに応答して出力されるように、他の用途よりも短いターンアラウンド・タイム（音声を発話してから音声認識装置が出力を生成するまでの時間）が求められる。例えば、オンスクリーン・カーソルの動きを制御することなど「ライブ」の音声認識用途に使用される音声認識装置は、医学報告の書き起こしを生成するのに使用される音声認識装置よりも短いターンアラウンド・タイム（「応答時間」とも呼ばれている）を必要とすることがある。

【0002】

所望のターンアラウンド・タイムは、例えば、音声認識装置によって処理される音声発話の内容に依存する。例えば、「ウィンドウを閉じよ」など、短い命令および制御の発話においては、約５００ｍｓのターンアラウンド・タイムは、エンド・ユーザにとって反応が遅く感じられることがある。対照的に、ユーザがテキストに書き起こしたいと望む長い口述文においては、１０００ｍｓの応答時間は、エンド・ユーザにとって許容できることがある。実際、後者の場合では、ユーザは、その音声に応答してテキストが直ちに表示されることにより、普通ならば、その音声が割り込まれていると感じることがあるので、より長い方の応答時間を好むことがある。段落全体など、口述されるより長い文節では、何秒間にもわたるより長い応答時間でさえも、エンド・ユーザによって許容できることがある。

【0003】

典型的な従来技術の音声認識システムでは、認識確度を維持しながら応答時間を増大させることにより、音声認識の実行専用であるコンピューティング資源（処理サイクルおよび／またはメモリ）を増大させることが必要になる。その結果、高速な応答時間を必要とする多くのアプリケーションでは、音声認識システムが、それらアプリケーション自体が実行されるのと同じコンピュータ上で実行されることが必要になる。このように同じ場所に配置することにより、ネットワークを介して音声認識結果を要求アプリケーションに伝送するよう要求することで普通なら生じるはずの遅延がなくなることがあるが、このように同じ場所に配置することにはまた、様々な不利な点がある。

【0004】

例えば、同じ場所に配置するには、すべてのデスクトップ・コンピュータ、ラップトップ・コンピュータ、携帯電話、携帯型情報端末（ＰＤＡ）など、音声認識機能を必要とするあらゆるエンド・ユーザ装置上に、音声認識システムをインストールすることが必要になる。このように多数の多種多様な装置上に、こうした音声認識システムをインストールし維持することは、エンド・ユーザおよびシステム管理者にとって退屈で時間のかかるものになることがある。例えば、このようなメンテナンスでは、音声認識システムの新版が利用可能になったときに、システム・バイナリを更新する必要がある。音声モデルなどのユーザ・データが作成され、時が経つにつれて個々の装置上に蓄積されるが、これらのデータは、貴重な記憶空間をとり、同じユーザが使用する複数の装置と同期する必要がある。ユーザが、より多くの多様な装置上で音声認識システムを使用し続けるにつれて、このようなメンテナンスが特に負担になることがある。

【0005】

さらに、音声認識システムをエンド・ユーザ装置上に配置することにより、音声認識システムが、ＣＰＵ処理サイクル、主記憶装置、ディスク空間など、貴重なコンピューティング資源を消費することになる。こうした資源は、携帯電話などのハンドヘルド・モバイル装置では特に不足している。こうした装置を使用して高速なターンアラウンド・タイムで音声認識結果を生成することにより、通常、認識の確度を犠牲にし、同じ装置上で実行される他のアプリケーションに利用可能な資源を減らすことが必要になる。

【0006】

組込み式装置との関連でこれら資源の制約条件を克服するための知られた技法の１つは、音声認識処理の負担のいくらかまたはすべてを、組込み式装置から離れて配置され、この組込み式装置よりもコンピューティング資源がはるかに多い音声認識サーバに委ねることである。この状況でユーザが組込み式装置に発話すると、この組込み式装置は、それ自体のコンピューティング資源を使用して音声を認識しようとはしない。代わりに、この組込み式装置は、音声（または、処理された形式の音声）を、ネットワーク接続を介して音声認識サーバに伝送し、この音声認識サーバは、そのより豊富なコンピューティング資源を使用して音声を認識し、したがって、この組込み式装置が同じ確度で生成することのできる場合よりも迅速に認識結果を生成する。次いで、音声認識サーバは、ネットワーク接続を介して、この結果を組込み式装置に伝送して戻す。理想的には、この技法は、組込み式装置のみを使用して他の方法で実現可能になる場合よりも迅速に、非常に正確な音声認識結果を生成する。

【0007】

しかし実際には、この「サーバ側での音声認識」技法には、様々な欠点がある。具体的には、サーバ側での音声認識は、高速で高信頼のネットワーク接続の可用性に依存するので、必要なときにこうした接続が利用可能でない場合、この技法は破綻する。例えば、十分に広帯域でないネットワーク接続を使用することにより、サーバ側での音声認識によって可能になる潜在的な速度の増加が無効になることがある。一例として、遠隔サーバに対するＨＴＴＰコールの典型的なネットワーク待ち時間は、１００ｍｓ〜５００ｍｓの範囲になることがある。発話データが、発話されて５００ｍｓ後に音声認識サーバに到達する場合、そのサーバは、命令および制御のアプリケーションが必要とする最小限のターンアラウンド・タイム（５００ｍｓ）を満足させるのに十分なだけ迅速に結果を生成することが不可能になる。その結果、最速の音声認識サーバでさえ、低速のネットワーク接続とともに使用される場合には、生成される結果が遅く感じられることになる。

【0008】

さらに、従来のサーバ側での音声認識技法では、クライアント（例えば、組込み式装置）と音声認識サーバの間で確立されたネットワーク接続は、認識プロセス全体にわたって絶えず動作状態を保っていると仮定する。ローカル・エリア・ネットワーク（ＬＡＮ）において、またはクライアントとサーバが両方とも同じ組織実体によって管理される場合には、この状態を満足させることも可能であるが、クライアントとサーバが広域ネットワーク（ＷＡＮ）を介して接続されているときには、この状態を満足させることは、不可能または少なくとも不合理になることがあり、この場合、ネットワーク接続に対する割込みが一般的であり避けがたいものになることがある。

【0009】

さらに、各組織は、そのユーザがインターネットなどの公衆ネットワークを介して関わることのできる通信の種類をしばしば制限する。例えば、組織は、そのネットワーク内のクライアントに、外部への通信に関わることを許可するだけでもよい。このことは、あるポート上で、クライアントが外部サーバにコンタクトすることができるが、そのサーバは、このクライアントとのコンタクトを開始することができないことを意味する。これが、片方向通信の一例である。

【0010】

クライアントに課せられた他の一般的な制限は、クライアントが、制限された範囲の外部向けポートのみを使用して、外部サーバと通信してもよいことである。さらに、それらのポート上での外部向けの通信には、暗号化が求められることがある。例えば、クライアントは、標準のＨＴＴＰポート（ポート８０）または標準の安全な暗号化されたＨＴＴＰＳポート（ポート４４３）のみを使用することがしばしば許可される。

【発明の概要】

【発明が解決しようとする課題】

【0011】

したがって、必要となるものは、クライアント装置の限られたコンピューティング資源に過大な負担をかけることなく、高速な応答時間で音声認識結果を生成するための改良された技法である。

【課題を解決するための手段】

【0012】

音声認識クライアントは、ネットワークを介してサーバ側での音声認識装置に向けて、音声ストリームおよび制御ストリームを並列に送出する。ネットワークは、信頼性の低い、低遅延のネットワークでもよい。サーバ側での音声認識装置は、絶えず音声ストリームを認識する。音声認識クライアントは、クライアントからの要求に応答するサーバ側での認識装置から認識結果を受信する。認識している間、クライアントは、サーバ側での認識装置の状態を遠隔で再構成してもよい。

【0013】

本発明の様々な態様および実施形態の他の特徴ならびに利点が、以下の説明および特許請求の範囲から明らかになろう。

【図面の簡単な説明】

【0014】

【図1】本発明の一実施形態による、低遅延ネットワークを介して音声認識を実行するためのシステムのデータ流れ図である。

【図2A】本発明の一実施形態による、図１のシステムによって実行される方法の流れ図である。

【図2B】本発明の一実施形態による、音声のセグメントを認識するためにサーバ側での自動音声認識装置によって実行される方法の流れ図である。

【図2C】本発明の一実施形態による、音声のセグメントに音声認識を実行することの一部分としてサーバ側での自動音声認識装置によって実行される方法の流れ図である。

【図2D】本発明の一実施形態による、ある認識結果が得られた後で、かつさらなる認識が実行される前にサーバ側での認識装置が確実に再構成されるように、この認識装置によって実行される方法の流れ図である。

【図3】本発明の一実施形態による、音声ストリームの図である。

【図4】本発明の一実施形態による、命令および制御のストリームの図である。

【発明を実施するための形態】

【0015】

図１を参照すると、本発明の一実施形態による音声認識システム１００のデータ流れ図が示してある。図２Ａを参照すると、本発明の一実施形態による、図１のシステム１００によって実行される方法２００の流れ図が示してある。

【0016】

クライアント装置１０６のユーザ１０２が発話し、それにより、クライアント装置１０６に音声１０４を供給する（ステップ２０２）。クライアント装置１０６は、デスクトップ・コンピュータもしくはラップトップ・コンピュータ、携帯電話、携帯型情報端末（ＰＤＡ）、または電話など、どんな装置でもよい。しかし、本発明の各実施形態は、低速なプロセッサもしくは少量のメモリを有するコンピュータまたはモバイル・コンピューティング装置など資源が限られたクライアント、または資源を必要とするソフトウェアを走らせるコンピュータとともに用いると特に有用である。装置１０６は、サウンド・カードに接続されたマイクロフォンなどを介して、任意のやり方でユーザ１０２から音声１０４を受け取ってもよい。音声１０４は、コンピュータ読取り可能な媒体に具体的に格納され、かつ／またはネットワーク接続もしくは他のチャネルを介して伝送されるオーディオ信号内に取り込んでもよい。例えば、音声１０４は、それぞれ押すことで新規のオーディオ・ストリームが開始される「プッシュ・トーク」アプリケーションの場合と同様に、複数のオーディオ・ストリームを含んでもよい。

【0017】

クライアント装置１０６は、トランスクリプション・アプリケーションまたは音声１０４を認識する必要のある他のアプリケーションなど、アプリケーション１０８を含む。アプリケーション１０８は、音声認識結果を使用するどんな種類のアプリケーションでもよいが、以下の議論を進めるために、アプリケーション１０８は、音声を書き起こすための「ライブ」認識アプリケーションであると仮定する。これに関連してユーザ１０２が提供する音声１０４の各部分は、２つの基本的なカテゴリ、すなわち書き起こすべき口述音声（例えば、「患者は３５歳の男性である」）、または命令（「これを消去せよ」もしくは「署名し提出せよ」など）のうちの１つに当てはまることがある。

【0018】

クライアント装置１０６はまた、音声認識クライアント１４０を備える。音声認識クライアント１４０は、アプリケーション１０８から分離されたモジュールとして図１に示してあるが、別法として、音声認識クライアント１４０は、アプリケーション１０８の一部分でもよい。アプリケーション１０８は、音声認識クライアント１４０に音声１０４を供給する。あるいは、アプリケーション１０８は、何らかのやり方で音声１０４を処理し、音声１０４の処理済みバージョンまたはこの音声から得られる他のデータを、音声認識クライアント１４０に供給する。音声認識クライアント１４０自体は、認識するために音声１０４を伝送するのに備えて、（アプリケーション１０８によって音声に対して実行される任意の処理に加えて、またはそれの代わりに）音声１０４を処理してもよい。

【0019】

音声認識クライアント１４０は、ネットワーク１１６を介して、サーバ１１８上に配置されたサーバ側での音声認識エンジン１２０に音声１０４を伝送する（ステップ２０４）。クライアント１４０は、単一のサーバ構成を使用して、音声１０４全体をサーバ１１８に伝送してもよいが、そうすることによって最適とは言えない次善の結果を生成することがある。認識確度を改善するために、または音声認識エンジン１２０のコンテキストを変更するために、クライアント１４０は、代わりに、音声１０４の伝送中での様々な点で、したがって、音声認識エンジンの音声１０４の認識中での様々な点で音声認識エンジン１２０を再構成してもよい。一般に、クライアント１４０によって音声認識エンジン１２０に伝送される構成コマンドは、後に続く音声のコンテキストおよび／または内容について、認識装置１２０の期待値を設定する。初期構成でサーバ側での認識エンジンを構成し、次いで音声のある部分をサーバに送出し、次いでサーバ側での認識エンジンを再構成し、次いで音声のさらなる部分を送出することなどにより、様々な従来技術システムがこの構成機能を実行する。これにより、サーバ側での認識エンジンは、音声の後者の部分について、初期構成を使用して生成した場合よりも良好な結果を生成するように設計された構成およびコンテキストで、音声の様々な部分を認識することが可能になる。

【0020】

しかし、音声１０４の次の部分をサーバ１１８に送出する前に、その前の再構成コマンドがサーバ１１８によって処理されたという肯定応答をサーバ１１８から受信するのを待つように、音声認識クライアント１４０に要求するのは望ましくない。というのも、こうした要求により、特にネットワーク接続が低速で、かつ／または信頼性が低い場合に、音声１０４の認識に著しい遅延が生じることもあるからである。後続の音声をどう処理するかの命令をクライアント側のアプリケーション１０８からサーバが受信するまで、音声のサーバ側での処理を停止することもまた望ましくない。しかし、従来技術のシステムでは、再構成コマンドなどこうした命令をクライアントから受信するまで、サーバは音声の処理を停止する必要がある。

【0021】

本発明の各実施形態は、以下のように、上記その他の問題に取り組む。音声認識クライアント１４０は、ネットワーク１１６を介して音声ストリーム１１０内で、音声１０４をサーバ１１８に伝送する（図２のステップ２０４）。図３に示すように、音声ストリーム１１０は、セグメント３０２ａ〜ｅに分割してもよく、各セグメントは、音声１０４の一部分（例えば、音声１０４のうちの１５０〜２５０ｍｓ）を表してもよい。各セグメントで音声１０４を送出することにより、音声認識クライアント１４０は、音声１０４の各部分が音声認識クライアント１４０で利用可能になって後、比較的速やかにそれらの各部分をサーバ１１８に伝送することが可能になり、それにより、認識装置１２０は、最小限の遅延でそれら各部分の認識を開始する。アプリケーション１０８は、例えば、第２のセグメント３０２ｂが生成されているときでも、第１のセグメント３０２ａが利用可能になると直ちにそのセグメントを送出してもよい。さらに、クライアント１４０は、持続的な接続（例えばソケット）を使用することなく、音声ストリーム１１０内の個々の部分をサーバ１１８に送出してもよい。結果として、ＨＴＴＰなどのコネクションレス・プロトコルまたはステートレス・プロトコルを音声認識クライアント１４０が使用して、音声ストリーム１１０をサーバ１１８に伝送してもよい。

【0022】

説明を簡単にするために、５つの代表的なセグメント３０２ａ〜ｅのみが図２Ａに示してあるが、実際には、音声ストリーム１１０は、任意の数のセグメントを含んでもよく、ユーザ１０２が発話を続けるにつれて、その数が増えてもよい。アプリケーション１０８は、任意の手順を使用して、音声１０４を複数のセグメントに分割してもよく、また、例えばＨＴＴＰ接続を介して音声１０４をサーバ１１８にストリーム転送してもよい。

【0023】

音声セグメント３０２ａ〜ｅのそれぞれは、ユーザ１０２の音声１０４の対応する部分を表すデータ３０４ａを含む。このような音声データ３０４ａは、任意の適切な形式で表してもよい。音声セグメント３０２ａ〜ｅのそれぞれは、対応する音声データ３０４ａの開始時刻３０４ｂや終了時刻３０４ｃ、およびタグ３０４ｄなど他の情報を含んでもよく、これらを以下でさらに詳細に説明する。図３に示した具体的なフィールド３０４ａ〜ｄは単に例であり、本発明を限定するものではない。

【0024】

一般に、サーバ側での認識装置１２０は、音声ストリーム１１０からのセグメントを、サーバ１１８における先入れ先出し処理キュー１２４に入れる（図２のステップ２１６）。以下でより詳細に述べるある種の例外の場合、サーバ側での認識装置１２０は、処理キュー１２４からのセグメントが利用可能になった後、可能な限り早くそれらのセグメントを抜き取り、それらセグメントに音声認識を実行して、音声認識結果を生成し（ステップ２１８）、その結果を、サーバ１２０が先入れ先出しキュー１３４に入れる（ステップ２２０）。

【0025】

アプリケーション１０８はまた、音声認識クライアント１４０を介して、ステップ２０４の一部分として、ネットワーク１１６を介し、制御ストリーム１１２をサーバ側での認識装置１２０に伝送してもよい。図４に示すように、制御ストリーム１１２は、制御メッセージ４０２ａ〜ｃを含んでもよく、これらは順序通りに認識装置１２０に伝送される。説明を簡単にするために、図４には３つの代表的な制御メッセージ４０２ａ〜ｃのみが示してあるが、実際には、制御ストリーム１１２は、任意の数の制御メッセージを含んでもよい。以下でより詳細に述べるように、制御メッセージ４０２ａのそれぞれは、サーバ側での認識装置１２０が実行するコマンドを指定するためのコマンド・フィールド４０４ａ、構成オブジェクトを指定するための構成オブジェクト・フィールド４０４ｂ、タイムアウト値を指定するためのタイムアウト値フィールド４０４ｃなど、複数のフィールドを含んでもよい。図３に示した具体的なフィールド３０４ａ〜ｄは単に例であり、本発明を限定するものではない。

【0026】

図１に示すように、音声認識クライアント１４０は、音声ストリーム１１０と制御ストリーム１１２を２つの異なるストリームとして扱ってもよく（ステップ２０６および２０８）、これらストリームは、音声認識クライアント１４０からエンジン１２０まで並列に伝送される。しかし、サーバ１１８と通信するために音声認識クライアント１４０に対して１つの出力ポートのみが利用可能であると仮定すると、クライアント１０６は、音声ストリーム１１０と制御ストリーム１１２を多重化して、サーバ１１８に伝送される単一のデータ・ストリーム１１４にしてもよい（ステップ２１０）。サーバ１１８は、信号１１４を多重分離して、サーバ側において、その成分である音声ストリーム１１０と制御ストリーム１１２に変換する（ステップ２１４）。

【0027】

どんな多重化方式を使用してもよい。例えば、トランスポート機構としてＨＴＴＰを使用する場合、ＨＴＴＰクライアント１３０およびＨＴＴＰサーバ１３２は、クライアント１０６およびサーバ１１８の代わりに、多重化および多重分離の機能をそれぞれトランスペアレントに実行してもよい。すなわち、音声認識クライアント１４０は、音声ストリーム１１０と制御ストリーム１１２が単一の多重化ストリーム１１４として伝送されるとしても、それらを２つの別々のストリームとして扱ってもよい。というのも、ＨＴＴＰクライアント１３０は、音声認識クライアント１４０の代わりに、これら２つのストリームをともに自動的かつトランスペアレントに多重化するからである。同様にして、サーバ側での認識装置１２０は、音声ストリーム１１０と制御ストリーム１１２が単一の多重化ストリーム１１４としてサーバ１１８が受信するとしても、それらを２つの別々のストリームとして扱ってもよい。というのも、ＨＴＴＰサーバ１３２は、サーバ側での認識装置１２０の代わりに、結合されたストリーム１１４を、自動的かつトランスペアレントに多重分離して２つのストリームに変換するからである。

【0028】

前述の通り、デフォルトでは、サーバ側での認識装置１２０は、順序通りに処理キュー１２４から音声セグメントを抜き取り、それらに音声認識を実行し、その音声認識結果を出力キュー１３４に入れる。音声認識クライアント１０８は、以下のように音声認識結果を受信する。音声認識クライアント１４０は、制御ストリーム１１２内で制御メッセージを送出し、このメッセージのコマンド・フィールド４０４ａが、本明細書において「ＤｅｃｏｄｅＮｅｘｔ」と呼ばれる方法を呼び出す。この方法は、（サーバ側での認識装置１２０の構成状態１２６がどのように更新されるのかを指定する）構成更新オブジェクト４０４ｂ、およびリアルタイム・タイムアウト値４０４ｃを、パラメータとしてとる。音声認識クライアント１４０は、制御ストリーム１１２内で他のコマンドを送出してもよいが、説明を簡単にするために、ここではＤｅｃｏｄｅＮｅｘｔコマンドのみを説明することにする。

【0029】

サーバ側での認識装置１２０は、制御メッセージを受信した後、可能な限り早く、また音声ストリーム１１０内の音声セグメントの処理と並列に、順序通りに制御ストリーム１１２から制御メッセージを抜き取る（ステップ２２２）。サーバ側での認識装置１２０は、順序通りに各制御メッセージ内のコマンドを実行する（ステップ２２４）。

【0030】

図２Ｂを参照すると、制御ストリーム１１２内のＤｅｃｏｄｅＮｅｘｔ制御メッセージを実行するためにサーバ側での認識装置１２０が実行する方法の流れ図が示してある。少なくとも１つの音声認識結果が出力キュー１３４内にある場合（ステップ２４０）、認識装置１２０は、ネットワーク１１６を介して、キュー１３４内の１つまたは複数の次の結果１２２を音声認識クライアント１４０に送出する（ステップ２４２）。ステップ２４２が実行されるときに、キュー１３４内で２つ以上の結果が利用可能である場合、キュー１３４内の利用可能なすべての結果が、結果ストリーム１２２内で音声認識クライアント１４０に伝送される。（説明を簡単にするために、結果１２２は、認識装置１２０から音声認識クライアント１４０に直接伝送されるものとして図１に示してあるが、結果１２２は、ネットワーク１１６を介してＨＴＴＰサーバ１３２によって伝送し、クライアント装置１０６においてＨＴＴＰクライアント１３０が受信してもよい。）次いで、ＤｅｃｏｄｅＮｅｘｔ方法は、制御権をアプリケーション１０８に戻し（ステップ２４６）、終了する。

【0031】

認識装置１２０は、処理キュー１２４内の音声セグメントに対して音声認識を絶えず実行していることを思い起こされたい。したがって、認識装置１２０がＤｅｃｏｄｅＮｅｘｔ方法の実行を開始するとき、出力キュー１３４が空である場合には、少なくとも１つの結果（例えば、１語）が出力キュー１３４内で利用可能になるまで、またはタイムアウト値４０４ｃによって指定された時間量に達するまで（ステップ２４８）、ＤｅｃｏｄｅＮｅｘｔ方法はブロックする。タイムアウト値４０４ｃに達する前に出力キュー１３４内に結果が現れる場合、ＤｅｃｏｄｅＮｅｘｔ方法は、その結果を音声認識クライアント１４０に伝送し（ステップ２４２）、制御権を音声認識クライアント１４０に戻し（ステップ２４６）、終了する。タイムアウト値４０４ｃに達する前に出力キュー１３４内に結果が現れない場合、ＤｅｃｏｄｅＮｅｘｔ方法は、利用可能な結果がないことを音声認識クライアント１４０に通知し（ステップ２４４）、制御権を音声認識クライアント１４０に戻し（ステップ２４６）、音声認識クライアント１４０にいかなる認識結果を戻すこともなく終了する。

【0032】

（ＤｅｃｏｄｅＮｅｘｔ方法が、音声認識クライアント１４０に認識結果を戻すか、または利用可能なそうした結果がないことを音声認識クライアント１４０に通知した後に）制御権が音声認識クライアント１４０に戻ると、音声認識クライアント１４０は、次の認識結果を受信しようとして、別のＤｅｃｏｄｅＮｅｘｔメッセージをサーバ１２０に直ちに送出してもよい。サーバ１２０は、図２Ｂに関して前述したやり方で、このＤｅｃｏｄｅＮｅｘｔメッセージを処理してもよい。この処理を、後続の認識結果について繰り返してもよい。その結果、制御ストリーム１１２は、サーバ側において本質的に常にブロックし（図２Ｂのステップ２４０および２４８によって表されるループ内で）、認識結果を待ち、それらの結果が利用可能になると、クライアント・アプリケーション１０８にそれらの結果を戻してもよい。

【0033】

タイムアウト値４０４ｃは、ＨＴＴＰタイムアウト値など、クライアント１４０とサーバ１２０の間で使用される基本となる通信プロトコルのタイムアウト値よりも短くなるように選択してもよい。その結果、タイムアウト値４０４ｃに達する前に音声認識結果が生成されなかった、という通知をクライアント１４０がサーバから受信すると、クライアント１４０は、このタイムアウトが、ネットワークの通信に問題があった結果としてではなく、タイムアウト値４０４ｃに達する前にサーバ１２０がいかなる音声認識結果をも生成できなかった結果であったとの結論を引き出してもよい。しかし、タイムアウトの理由がどうであれ、クライアント１４０は、こうしたタイムアウトの後に、別のＤｅｃｏｄｅＮｅｘｔメッセージをサーバ１２０に送出してもよい。

【0034】

前述の例では、２つの完全に非同期のデータ・ストリーム１１０および１１２を含む。しかし、これら２つのストリーム１１０および１１２に、ある種の同期を実行することが望ましいことがある。例えば、音声認識クライアント１４０が、音声ストリーム１１０の認識を開始する前に認識装置１２０がある構成状態に確実にあるようにすることが有用になることがある。例えば、認識装置１２０は、テキスト編集ウィンドウ内での現在のカーソル位置のテキスト・コンテキストを使用して、そのカーソル位置に挿入するテキストについての認識をガイドする。マウスまたは他のキーボードのイベントによりカーソル位置は頻繁に変化することがあるので、ユーザ１０２が「記録開始」ボタンを押すまで、アプリケーション１０８がサーバ１２０へのテキスト・コンテキストの伝送を遅らせることが有用になることがある。この場合、サーバ側での認識装置１２０は、サーバ１２０が正しいテキスト・コンテキストを受信し、それに応じてサーバ１２０がその構成状態１２６を更新するまで、サーバ１２０に伝送された音声を認識しないようにしなければならない。

【0035】

別の例として、認識結果によっては、認識装置１２０の構成状態１２６を変更することが必要になることがある。結果として、サーバ側での認識装置１２０は、こうした結果を生成するとき、次の結果を生成する前に再構成されるまで待たなければならない。例えば、認識装置１２０が「すべてを消去せよ」という結果を生成する場合、次にアプリケーション１０８は、次のように、「本当にすべてを消去しますか。はい、または、いいえでお答え下さい」とユーザ１０２を促すことにより、ユーザの目的を確認検査しようとしてもよい。この場合、アプリケーション１０８は（音声認識クライアント１４０を介して）、認識装置１２０が音声ストリーム１１０内の次のセグメントを認識しようとする前に、「はい｜いいえ」の方式で認識装置１２０を再構成しなければならない。

【0036】

図２Ｃの流れ図で示す通り、以下のようにこうした結果を得ることができる。図２Ｃには、処理キュー内のオーディオ・セグメントに音声認識を実行するステップの一部として、サーバ側での認識装置１２０によって実行してもよい方法が示してある（図２Ａのステップ２１８）。各認識装置の構成状態には、固有の構成状態識別子（ＩＤ）が割り当てられる。音声認識クライアント１４０は、構成状態ＩＤに整数値を割り当て、その結果、ＩＤ１＞ＩＤ２である場合、ＩＤ１に関連する構成状態は、ＩＤ２に関する構成状態よりも新しいものである。図３に関して前述の通り、音声認識クライアント１４０はまた、音声ストリーム・セグメント３０２ａ〜ｅのそれぞれの中にタグ３０４ｄを設ける。これらのタグは、そのセグメントの認識が開始可能になる前に必要となる最低限必要な構成状態ＩＤ数を示す。

【0037】

サーバ側での認識装置１２０が、処理キュー１２４から次のオーディオ・セグメントを検索するとき（ステップ２６２）、認識装置１２０は、この認識装置の現在の構成状態１２６の構成状態ＩＤ１３６を、検索されたオーディオ・セグメントのタグ３０４ｄによって指定された最低限必要な構成ＩＤと比較する。現在の構成ＩＤ１３６が、最低限必要な構成ＩＤと少なくとも同じ大きさである場合（ステップ２６４）、サーバ１２０は、検索したオーディオ・セグメントの認識を開始する（ステップ２６６）。そうでない場合、サーバ１２０は、現在の音声セグメントの認識を開始する前に、その構成ＩＤ１３６が最低限必要なＩＤに達するまで待つ。図２Ｃの方法は、図２Ａの方法２００と並列に実行してもよいので、サーバ側での認識装置１２０の構成ＩＤ１３６は、ステップ２６４上のループ内で図２Ｃの方法がブロックしている間でさえ、制御メッセージ２２４を実行することによって更新してもよい。さらに、サーバ１２０は、処理キュー１２４からの音声の処理を待っている間でさえ、音声ストリーム１１０からの追加セグメントを受信し続け、それらのセグメントを処理キュー１２４に入れ続ける（図２Ａのステップ２１４〜２１６）ことに留意されたい。

【0038】

音声ストリーム１１０と制御ストリーム１１２を同期させることのできる方式の別の例として、アプリケーション１０８は、音声認識クライアント１４０を介して、前もって、音声ストリーム１１０の認識を停止するよう認識装置１２０に命令してもよく、または、任意の認識結果を生成すると、もしくはある基準を満たす認識結果を生成すると、他の何らかのアクションをとるよう認識装置１２０に命令してもよい。こうした基準は、ブレークポイントの役割を効果的に果たすことができ、アプリケーション１０８は、音声認識クライアント１４０を介して、このブレークポイントを使用して、認識装置１２０が認識結果をどの程度生成するのかを積極的に制御してもよい。

【0039】

例えば、ユーザ１０２が以下の音声コマンド、すなわち「削除せよ」、「次に」、「すべてを選択せよ」および「ファイル・チューザを開け」のいずれかを発することがある状況を考えてみる。このような状況においては、構成更新オブジェクト４０４ｂによって指定してもよい実現可能な構成は、＜ｄｅｌｅｔｅ，ｃｏｎｔｉｎｕｅ＞、＜ｎｅｘｔ，ｃｏｎｔｉｎｕｅ＞、＜ｓｅｌｅｃｔ ａｌｌ，ｃｏｎｔｉｎｕｅ＞、＜ｏｐｅｎ ｆｉｌｅ ｃｈｏｏｓｅｒ，ｓｔｏｐ＞になるはずである。このような構成は、「削除せよ」、「次に」、または「すべてを選択せよ」という認識結果を取得した後に音声ストリーム１１０の認識を継続するよう、サーバ側での認識装置１２０に命令するが、「ファイル・チューザを開け」という認識結果を取得した後には音声ストリーム１１０の認識を停止するよう命令する。認識装置１２０をこのように構成する理由は、「削除せよ」、「次に」、または「すべてを選択せよ」という結果を生成するには、次の結果を生成する前に認識装置１２０を再構成する必要がないことである。したがって、認識装置１２０は、「削除せよ」、「次に」、または「すべてを選択せよ」という結果のいずれかを生成した後に、音声ストリーム１１０の認識を継続できるようにしてもよく、それにより、認識装置１２０が音声１０４のフルスピードでの認識を継続できるようにする（図２Ｄのステップ２７２を参照）。対照的に、「ファイル・チューザを開け」という結果を生成するには、音声ストリーム１１０内の任意の後続セグメントを再構成する前に、認識装置１２０を再構成する必要がある（例えば、「ＯＫ」、「ｆｉｌｅ１．ｘｍｌを選択せよ」、または「新規フォルダ」などの結果を期待するために）（図２Ｃのステップ２７４を参照）。したがって、アプリケーション１０８が、音声認識クライアント１４０を介して、「ファイル・チューザを開け」という結果が生成されたと認識装置１２０によって通知される場合、アプリケーション１０８は、音声認識クライアント１４０を介して、ファイル・チューザを制御するのに適切な構成状態で認識装置１２０を再構成してもよい。アプリケーション１０８が認識装置１２０をこのように事前構成できるようにすることで、認識装置の応答時間を最大化することと、認識装置１２０が適切な構成状態を使用して音声１０４の様々な部分を確実に認識することの間で均衡を図る。

【0040】

認識装置１２０が、構成「停止」コマンドの結果として（ステップ２７４）、処理キュー１２４からの音声の認識を停止する場合でも、認識装置１２０は、音声ストリーム１１０からの音声セグメントを受信し続け、それらのセグメントを処理キュー１２４に入れ続けてもよいことに留意されたい（図２Ａのステップ２１４、２１６）。結果として、認識装置１２０が音声認識の実行を再開するとすぐに、音声ストリーム１１０の追加セグメントをいつでも処理できる。

【0041】

前述の通り、本明細書において開示される技法は、ＨＴＴＰＳなどの片方向通信プロトコルとともに使用してもよい。このような通信プロトコルは、広域ネットワークではセットアップが簡略であるが、障害に対しての保証がほとんどない。障害は、クライアント１３０とサーバ１３２の間での要求時に生じることがあり、アプリケーション１０８を曖昧な状態にしておくことがある。例えば、いずれかの当事者（クライアント・アプリケーション１０８またはサーバ側での認識装置１２０）がコールの最中で障害を起こすとき、問題が生じることがある。例えば、サーバ１１８との間でのメッセージが失われること、メッセージが順序を誤ってクライアント１０６もしくはサーバ１１８に到達すること、またはメッセージが誤って重複して送出されることにより、他の問題が生じることがある。一般に、従来技術のシステムでは、基本となる通信プロトコルはこうした頑強性を保証しないので、総合的なシステム１００の頑強性を確実にすることは音声認識クライアント１４０の責任である。

【0042】

本発明の各実施形態は、音声認識クライアント１４０とサーバ側での認識装置１２０との間で交換されるすべてのメッセージおよびイベントをベキ等にすることにより、こうした問題に対して頑強である。同じイベントの複数の実現値が、そのイベントの単一の実現値と同じ効果を有する場合、イベントはベキ等である。したがって、音声認識クライアント１４０が、サーバ側での認識装置１２０へのコマンド伝送に障害が発生するなど、障害を検出する場合、音声認識クライアント１４０は、直ちに、または待ち期間の後にコマンドを再伝送してもよい。音声認識クライアント１４０および認識装置１２０は、再試行することでシステム１００をコヒーレント状態にすることを保証する、メッセージング・アプリケーション・プログラム・インターフェース（ＡＰＩ）を使用してもよい。

【0043】

具体的には、音声ストリーム１１０におけるＡＰＩが、音声認識クライアント１４０に、音声ストリーム１１０をセグメントで伝送させる。開始バイト・インデックス３０４ｂ（第１のセグメントに対して最初は０）、および、終了バイト・インデックス３０４ｃまたはセグメント・サイズのいずれかに加えて、各セグメントは固有ＩＤ３０４ｅを有してもよい。サーバ側での認識装置１２０は、通常、開始バイトにセグメント・サイズをプラスしたものに等しいはずのセグメントの終了バイト・インデックスを伝送して戻すことにより、そのセグメントを受信したことを肯定応答してもよい。しかし、サーバがオーディオ・セグメント全体を読み取ることができなかった場合、このサーバによって伝送された終了バイト・インデックスはより低い値でもよい。

【0044】

次いで、音声認識クライアント１４０は、サーバ側での認識装置１２０が中断した箇所から開始する次のセグメントを転送し、その結果、新規の開始バイト・インデックスは、認識装置１２０によって戻された終了バイト・インデックスに等しい。音声ストリーム１１０全体に対して、このプロセスが繰り返される。（サーバ１１８とのやり取りの途中で）メッセージが失われる場合、音声認識クライアント１４０はこの転送を繰り返す。サーバ側での認識装置１２０がその音声セグメントを前もって受信しなかった場合、サーバ側での認識装置１２０は、単に新規データを処理することになる。しかし、認識装置１２０が前もってそのセグメントを処理していた場合（クライアント１０６に戻る途中で結果が失われた場合に生じることがあるように）、例えば、認識装置１２０は、セグメントを受信したことを肯定応答し、それを再度処理することなく廃棄してもよい。

【0045】

制御ストリーム１１２においては、すべての制御メッセージ４０２ａ〜ｃのそれぞれが現在のセッションに対するＩＤを含んでもよいので、それらのメッセージをサーバ１１８に再送してもよい。ＤｅｃｏｄｅＮｅｘｔ方法の場合、音声認識クライアント１４０は、ＤｅｃｏｄｅＮｅｘｔ方法の一部として、実行中の固有の識別子を渡して、現行方法のコールを識別してもよい。サーバ１１８は、それら識別子の記録をとって、制御ストリーム１１２内で受信する現在のメッセージが、新規であるのか、または既に受信されて処理されたのかを判定する。現在のメッセージが新規である場合、認識装置１２０は、前述の通り、通常このメッセージを処理する。現在のメッセージが前もって処理されていた場合、認識装置１２０は、以前戻された結果を再度生成する代わりに、それらを再送達してもよい。

【0046】

制御メッセージ４０２ａ〜ｃのうちの１つがサーバ１１８に送られ、サーバ１１８が、制御メッセージを受信したことを肯定応答しない場合、クライアント１４０は、この制御メッセージを格納してもよい。クライアント１４０が、サーバ１１８に送出する第２の制御メッセージを有するとき、クライアント１４０は、第１の（肯定応答されていない）制御メッセージおよび第２の制御メッセージの両方をサーバ１１８に送出してもよい。あるいは、クライアント１４０は、第１および第２の制御メッセージで表される状態変更を組み合わせて単一の制御メッセージにすることによって同じ結果を達成してもよく、次いで、クライアント１４０は、この単一の制御メッセージをサーバ１４０に伝送してもよい。クライアント１４０は、任意の数の制御メッセージがサーバ１１８によって肯定応答されるまで、このようにして、こうしたメッセージ同士を組み合わせて単一の制御メッセージにしてもよい。同様にして、サーバ１１８は、クライアント１４０によって肯定応答されなかった音声認識結果がクライアントによって肯定応答されるまで、こうした音声認識結果を組み合わせて、結果ストリーム１２２内の個々の結果にしてもよい。

【0047】

本発明の利点の中には、以下の１つまたは複数の利点がある。本発明の各実施形態により、いかなる特別なネットワークも必要とすることなく、インターネット上のいたるところに音声認識を行き渡らせることが可能になる。具体的には、本明細書において開示した各技法は、ＨＴＴＰなどの片方向通信プロトコル上で動作することができ、それにより、外部への（片方向）通信にのみ関与するようにクライアントが制限された環境においても動作が可能になる。その結果、本発明の各実施形態は、セキュリティを犠牲にする必要もなく、多種多様なネットワークと関連して広く有用である。さらに、本発明において開示した各技法は、（ＳＳＬや、さらにはＨＴＴＰＳなどの）既存のウェブ・セキュリティ機構を再使用して、クライアント１０６とサーバ１１８の間の安全な通信を実現してもよい。

【0048】

前述の通り、クライアントに課せられた一般的な制限の１つは、クライアントが、制限された範囲の外部向けポートのみを使用して、外部サーバと通信してもよいことである。本発明の各実施形態は、音声ストリーム１１０と制御ストリーム１１２を多重化して、単一のポートを介して伝送することのできる単一のストリーム１１４にすることにより、こうしたシステムで実施してもよい。

【0049】

さらに、外部向けの通信は、暗号化を求められることがある。例えば、クライアントは、標準の安全で暗号化されたＨＴＴＰＳポート（ポート４４３）を使用することしか許可されないことがしばしばある。本発明の各実施形態は、その通信要求のすべて、すなわちオーディオ転送１１０と制御フロー１１２の両方について、標準の（安全ではない）ＨＴＴＰポートまたは安全なＨＴＴＰＳポートのいずれでも動作することができる。その結果、本明細書において開示した各技法は、安全ではないＨＴＴＰを使用してクライアントが通信できるようにするシステム、および安全なＨＴＴＰＳを使用してユーザが通信するよう要求する、または通信できるようにするシステムとともに使用してもよい。

【0050】

本明細書において開示した各技法はまた、各メッセージがベキ等である通信プロトコルを利用するので、間欠的なネットワーク障害に対して回復力がある。ネットワークの降下および上昇が一般的であるＷＡＮなどのネットワークとともに本発明の各実施形態が使用されるとき、これは特に有用である。こうしたイベントにより、従来のサーバ側での音声認識システムが障害を起こすことがあるが、これらのイベントは、（場合により、ターンアラウンド・タイムが増大する場合を除いては）本発明の各実施形態によって生成される結果には影響を及ぼさない。

【0051】

本発明の各実施形態により、サーバ１１８が音声１０４を絶えず処理することができない場合でも、ネットワーク１１６が許す限り高速に、クライアント１０６からサーバ１１８にその音声を伝送することが可能になる。さらに、サーバ側での認識装置１２０は、ネットワーク１１６が結果を伝送できない、かつ／またはアプリケーション１０８が結果をすぐに受信することができないときでさえ、可能な限り迅速に処理キュー１２４からの音声を処理してもよい。本発明の各実施形態の上記その他の特徴により、システム１００の個々の構成要素が許す限り迅速に、音声および音声認識結果を伝送し処理することができるようになり、その結果、システム１００のその他の構成要素の実行に対する、システム１００の個々の構成要素に関する問題の影響が最小限になる。

【0052】

さらに、本発明の各実施形態により、可能な限り迅速に、ただしクライアント・アプリケーション１０８から乖離し過ぎることなく、サーバ側での認識装置１２０が音声を処理することができるようになる。前述の通り、アプリケーション１０８は、制御ストリーム１１２内の制御メッセージを使用して、認識装置１２０に再構成コマンドを発行してもよく、これらのコマンドにより、認識装置１２０がそれ自体を再構成して、適切な構成状態で音声を認識し、アプリケーション１０８が認識装置１２０の状態を適切に再構成できるように、所定の条件が生じると一時的に認識を停止させることができるようになる。こうした技法により、誤った構成状態を使用して実行することなく、可能な限り迅速に音声認識を実行することが可能になる。

【0053】

これまで、具体的な実施形態に関して本発明を説明してきたが、前述の各実施形態は例示的なものとしてのみ示しており、本発明の範囲を限定または定義するものではないことを理解されたい。他の様々な実施形態もまた、以下のものを含むがそれには限定されず、特許請求の範囲に記載の範囲内にある。例えば、本明細書に記載の各要素および各構成部品は、さらなる構成要素にさらに分割してもよく、また一緒に結合して、同じ機能を実行するための構成部品をより少なくなるよう形成してもよい。

【0054】

前述の通り、本発明の各実施形態で実行される様々な方法は、互いに並列に、全体として、または部分的に実行してもよい。これまで述べてきた利点を達成するために本明細書において開示した方法の具体的な部分を、様々な組合せでどのように実行すべきかが、当業者には理解されよう。

【0055】

前述の各技法は、例えば、ハードウェア、ソフトウェア、ファームウェア、またはそれらのどんな組合せで実施してもよい。前述の各技法は、プロセッサ、プロセッサが読取り可能な記憶媒体（例えば、揮発性メモリと不揮発性メモリ、および／または記憶素子）、少なくとも１つの入力装置、ならびに少なくとも１つの出力装置を備える、プログラム可能なコンピュータ上で実行される１つまたは複数のコンピュータ・プログラムで実施してもよい。入力装置を使用して入ってくる入力にプログラム・コードを適用して、説明した各機能を実行し、出力を生成してもよい。出力は、１つまたは複数の出力装置に供給してもよい。

【0056】

以下の特許請求の範囲に記載の範囲内にある各コンピュータ・プログラムは、アセンブリ言語、機械語、高水準手続き型プログラミング言語、またはオブジェクト指向プログラミング言語など、どんなプログラミング言語で実施してもよい。プログラミング言語は、例えば、コンパイラ型またはインタープリタ型のプログラミング言語でもよい。

【0057】

このようなコンピュータ・プログラムはそれぞれ、コンピュータ・プロセッサで実行するために、機械読取り可能な記憶装置内に具体的に組み入れられたコンピュータ・プログラム製品で実施してもよい。本発明の方法ステップは、コンピュータ読取り可能な媒体上に具体的に組み入れられたプログラムを実行して、入力に演算を施し出力を生成することにより本発明の各機能を実行するコンピュータ・プロセッサによって実行してもよい。適切なプロセッサには、一例として、汎用マイクロプロセッサと特殊目的のマイクロプロセッサが両方含まれる。一般に、プロセッサは、読取り専用メモリおよび／またはランダム・アクセス・メモリから、命令およびデータを受信する。コンピュータ・プログラム命令を具体的に組み入れるのに適した記憶装置には、例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、およびフラッシュ・メモリ・デバイスを含む半導体記憶装置、内部ハード・ディスクや取外し可能ディスクなどの磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭなど、あらゆる形態の不揮発性メモリが含まれる。前述のいかなるものも、特別に設計されたＡＳＩＣ（特定用途向け集積回路）またはＦＰＧＡ（フィールド・プログラマブル・ゲート・アレイ）によって補ってもよく、またそれらに組み込んでもよい。一般に、コンピュータはまた、内部ディスク（図示せず）または取外し可能ディスクなどの記憶媒体から、プログラムおよびデータを受信することができる。これらの要素はまた、従来のデスクトップ・コンピュータまたはワークステーション・コンピュータ、ならびに本明細書において説明した各方法を実施するコンピュータ・プログラムを実行するのに適した他のコンピュータ内に見られ、これらのコンピュータは、任意のデジタル印刷エンジンもしくはマーキング・エンジン、表示モニタ、または、カラーもしくはグレー・スケールの画素を紙、フィルム、表示画面、もしくは他の出力媒体上に生成することのできる他のラスタ出力装置とともに使用してもよい。

【図1】

【図2A】

【図2B】

【図2C】

【図2D】

【図3】

【図4】