拒絶査定不服の審決｜不服2015-12626 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

ポートフォリオを新規に作成して保存		追加
既存のポートフォリオに追加保存		追加

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服 2項進歩性特許、登録しない(前置又は当審拒絶理由) G06F
管理番号	1333975
審判番号	不服2015-12626
総通号数	216
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2017-12-28
種別	拒絶査定不服の審決
審判請求日	2015-07-02
確定日	2017-10-24
事件の表示	特願2012-549003「デジタルアシスタントのためのパーソナライズされたボキャブラリ」拒絶査定不服審判事件〔平成23年 7月21日国際公開、WO2011/088053、平成25年 5月16日国内公表、特表2013-517566〕について、次のとおり審決する。
結論	本件審判の請求は、成り立たない。
理由	第1 手続の経緯本願は、2011年(平成23年)1月11日(パリ条約による優先権主張外国庁受理2010年(平成22年)年1月18日米国、2011年(平成23年)1月10日米国)を国際出願日とする出願であって、平成25年12月13日付けで拒絶理由が通知され、平成26年6月20日付けで手続補正がなされたが、平成27年2月25日付けで拒絶査定がなされ、これに対し、同年7月2日に拒絶査定不服の審判が請求された。その後、当審において、平成28年2月18日付けで拒絶理由を通知し、同年8月22日付けで手続補正がなされ、同年10月18日付けで最後の拒絶理由を通知し、平成29年4月21日付けで意見書が提出された。第2 本願発明本願の請求項1?22に係る発明は、平成28年8月22日付け手続補正書により補正された特許請求の範囲の請求項1?22に記載された事項により特定されるものと認められるところ、その請求項1に係る発明(以下、「本願発明」という。)は、以下のとおりのものである。「自動アシスタントの動作方法であって、プロセッサと、該プロセッサにより実行される命令を格納するメモリとを備える電子デバイスにおいて、ユーザから受け付けた音声入力からテキスト文字列を取得し、前記ユーザと関連する複数の語を含む固定的な長期個人メモリと、前記自動アシスタントとの現在のユーザセッションに関連するデータを含む短期個人メモリとに少なくとも部分的に基づいて前記受信したテキスト文字列を解釈することにより、少なくともひとつの構文解析結果を導出し、前記自動アシスタントによって提供されるサービスの領域をそれぞれが示す複数の所定のドメインから、前記少なくともひとつの構文解析結果に基づいてドメインを識別し、タスク及び当該タスクのための少なくとも1つのパラメータを、少なくとも部分的に前記少なくともひとつの構文解析結果に基づいて識別し、識別された前記タスクを実行し、前記ユーザへ、前記タスクの実行に関連する出力を提供することを特徴とする方法。」第3 引用文献及び引用発明 1 平成28年10月18日付けの拒絶の理由(以下、「当審拒絶理由」という。)に引用した「神田他、マルチドメイン音声対話システムにおける対話履歴を利用したドメイン選択、情報処理学会論文誌、日本、2007.05.15発行、第48巻,第5号、pp.1980-1989」(以下、「引用文献1」という。)には、次のア?ケの記載がある。(下線は、注目箇所に当審が付した。以下、同様。) ア「1.はじめにこれまで,飛行機の予約やバス運行情報案内など様々なタスクドメインにおいて音声対話システムが作成されてきた^(5),10)).これらのシステムの多くは,扱えるドメインが飛行機予約のみ,バス運行情報のみと1種類に限られており,ユーザの多様な要求に十分応えられるものではなかった.そこで本研究では,シングルドメインの音声対話コンポーネントの統合により,複数のドメインを扱えるシステム(マルチドメイン音声対話システム)を開発した.1つのシステムで複数のドメインを扱うことにより,ユーザの要求が複数のドメインをまたがるような,複雑なタスクも扱える.またドメイン間での履歴の共有により,シングルドメイン個々を利用するよりもスムーズなタスク達成が可能となる. マルチドメイン音声対話システムでは,まずユーザ要求の対象ドメインを推定するドメイン選択処理が不可欠である.音声を扱うシステムでは音声認識誤りが不可避であるため,誤りを含んだ音声認識結果からも正確にドメインを推定できる頑健さが要求される.最も単純なドメイン選択方法は,「バス」「レストラン」のようにユーザに明示的にドメイン名を発話させることである.しかしこの方法は,対話が冗長で自然さに欠けるうえに,ユーザはシステム設計者の定義したドメインの区切りを理解することを強制され,ユーザに負担を強いることになる.このため,自然なユーザ発話からの応答すべきドメインの推定が行われてきた^(3),4),11)).これらの研究では,1発話に対する音声認識結果から得られる情報のみを用いて応答すべきドメインを推定している.このため,音声認識結果が誤りである場合にはドメイン選択も誤りとなることが多い. 音声認識誤りが生じた場合でも正しいドメインで対話を行うには,それまでの対話の流れも考慮したドメイン選択が必要である.本研究では対話履歴から得られる特徴量を導入することで,音声認識誤りに対してより頑健なドメイン選択を行う. また,マルチドメイン音声対話システムでは,シングルドメインのシステムよりも構築にかかる労力が大きい.したがって,新たなドメインの追加や,既存のドメインの改変の容易さ(ドメインの保守性・拡張性)が高いシステムアーキテクチャが望ましい.これはドメイン選択手法においても同様であり,ドメインの変更や追加にも対応できる枠組みが求められる. 本研究では,マルチドメイン音声対話システムにおいて,対話履歴から得られる特徴量を導入し,音声認識誤りに頑健なドメイン選択を行う手法を提案する.本研究ではドメイン選択問題を,応答すべきドメインが,(I)1つ前の応答を行ったドメイン,(II)音声認識結果に対する最尤のドメイン, (III)それ以外のドメイン,のどれに該当するかを,対話履歴とユーザ発話から判別する問題ととらえる.対話履歴から得られる特徴量を導入して判別器を構成することにより,音声認識誤りに対してより頑健なドメイン選択が可能となる.また,上記の3クラスは,ドメインが増減しても一様に定義できるため,保守性・拡張性が高い.」(p.1980左欄第1行?p.1981左欄第30行) イ「2.マルチドメイン音声対話システムのアーキテクチャマルチドメイン音声対話システムでは,シングルドメインのシステムよりも複雑なシステム設計が必要となる.各ドメインが密接に関連付けられて設計された場合,あるドメインの改変の影響がシステム全体に及ぶため,ドメイン内部での改変や,新たなドメインの追加が困難となる.そこで,各ドメインが独立に設計できる分散型^(6))のアーキテクチャが提案されている^(6),8),9),11),12),14),16)).このアーキテクチャでは,ドメインごとに独立して記述できる部分と,ドメイン間の依存関係の考慮が必要な部分を切り分ける.後者の部分を最小化することにより,システム設計者は個々のドメインを半独立的に設計でき,各ドメインの改良や追加が容易となる. 本研究でもこの流れに立ち,我々が開発した分散型のシステムアーキテクチャ^(7))に基づきシステムを設計した.システムは大きく分けて,各ドメインでの対話を担当するエキスパートと,それらを統括するシステム本体に分かれる(図1).ユーザ発話の処理(言語理解や応答生成など)は各ドメインごとにエキスパートが行い,システム本体ではどのエキスパートにユーザ発話の処理を任せるかの振り分けを行う.また,特定のスロットに関しては,一定のプロトコルに従い,システム本体を仲介役としてドメイン間で共有を行う.各ドメインでの処理は各エキスパート内で完結しているため,システム本体とのプロトコルに従えば,システム設計者は個々のドメインを独立に設計できる.これにより各ドメインの改良や追加が容易となる. このように分散型のアーキテクチャでは,ユーザ発話の処理は各ドメインを担当するエキスパートに任せてシステム本体は関知しないため,どのドメインにユーザ発話の処理を任せるかという判定が重要となる.本研究ではこれをドメイン選択と呼ぶ.分散型アーキテクチャの特長である,新たなドメインの追加・変更の容易さを確保するためには,ドメイン選択で利用する情報もドメイン非依存である必要がある.」(p.1981左欄第31行?右欄第22行) ウ「3.ドメイン選択の課題分散型アーキテクチャの枠組みのもとでは,ドメインの保守性・拡張性を備えたドメイン選択の設計が必要である.さらに,ドメイン選択は音声認識誤りに対して頑健でなければならない. これまでの多くの手法では,音声認識結果から各ドメインごとにスコアを与え,そのスコアが最も高いドメインを選択する^(3),4),11)).しかし,ドメインヘのスコアの算出方法が音声認識結果のみに依存しているため,音声認識結果が誤りである場合,ドメイン選択も誤りとなることが多い.さらに,新たなドメインを追加する場合にそのドメインの精密な言語モデルを必要とするため,ドメインの拡張性が低い. また,ドメイン選択の際に1つ前の応答を行ったドメインの情報を利用した研究がある.文献6),16)では1つ前の応答を行ったドメインに近いドメインを選択するような制約を設けている.さらに文献8)では,サブゴールが達成されるまでドメイン遷移を行わない.これらの手法では,1つ前の応答を行ったドメインが正しい場合,音声認識誤りや言語理解誤りによって起こる誤ったドメイン遷移を防ぐことができる.しかし,1つ前で推定されたドメインが誤っていた場合,その誤ったドメインを連続して選択してしまう.この問題は,1つ前で推定されたドメインを無条件に信頼しているために生じる.本研究では,1つ前のドメイン推定の信頼性を表現する情報を,ドメインの履歴や状態から得ることにより,この問題を解決する.」(p.1981右欄第23行?p.1982左欄第17行) エ「4.ロバストで拡張性を備えたドメイン選択 4.1 本研究でのドメイン選択の定義本研究ではドメイン選択問題を,応答すべきドメインが,(I)1つ前の応答を行ったドメイン,(II)音声認識結果に対する最尤のドメイン^(☆),(III)それ以外のドメイン,のいずれであるかを選択する問題ととらえる(図2).ドメイン選択器は,これらの判別器を対話データから学習して構成する.選択肢(I)は,1つ前の応答を行ったドメインを維持する場合に相当し,選択肢(II)は,ユーザの要求するドメインが変化したときに,音声認識結果に基づきドメイン選択を行う場合に相当する.このように,この枠組みは従来研究でのドメイン選択を包含する.さらに選択肢(III)を定義し判別することで,選択肢(I)や(II)が有効でない場合にも対処する. 音声認識の成否とドメイン選択を分けて考えることで,音声認識結果が誤りである場合でも,1つ前に応答したドメインが正しければ,それを維持できる.この例を図3に示す.ユーザはまずU1でレストランに関する発話を行う.次にU2でもやはりレストランに関する発話を行ったが,未知語を含む発話であったため,レストランドメインで理解できる音声認識結果が得られなかった.この場合,U2に対する応答はレストランドメインで行われるべきであるが,従来手法ではU2の音声認識結果を受理できた寺社ドメインヘ遷移してしまう(S2誤).このような場合でも,選択肢(I)が選択されることで「S2正」のようにレストランドメインで応答を続けることができる. さらに選択肢(III)を定義し判別することで,通常の制御が適切でない場合,つまり,1つ前の応答を行ったドメインや音声認識結果に基づくドメインのエキスパートに制御権を与えるのが適当でない場合を検出できる.これは誤りが連続した場合に相当するが,ドメインは正しいが音声認識が誤りであるのか,ドメインそのものが誤りであるのかの判断が必要な点で,単純に音声認識誤りの連続を検出するよりも難しい問題である.この例を図4に示す.ユーザはU1でホテルドメインに関する発話を行おうとしたが,いい淀んだため音声認識誤りが生じ,レストランドメインに遷移してしまった.U2で再びホテルドメインに関する発話を行ったが,さらに音声認識誤りが生じた.このような場合,U2に対して選択すべきドメインは,1つ前の応答を行ったドメイン(レストラン)でもなければ,音声認識結果に対するドメイン(バス)でもない.このような状況を検出することで,誤ったドメインでの対話の継続を防止できる.たとえば,図4のS2正のように,「[選択肢(I)のドメイン]または[選択肢(II)のドメイン]の情報についてお尋ねですか?」といった確認が生成できる. これらの選択肢は,個々のドメインの判別ではなく,ドメイン間の時系列上での相対的な関係を表すため,ドメイン数が増減しても一様に定義できる.そのため,得られた判別器はドメインの数に依存せず利用でき,保守性・拡張性が高いドメイン選択を実現できる.」(p.1982左欄第18行?p.1983左欄第4行) オ「4.2 対話履歴を利用したドメイン選択前節で定義したドメイン選択を行うために用いた特徴量について説明する.本研究では,従来用いられてきた,音声認識結果から得られる情報に加えて,対話履歴から得られる特徴量の導入により,ドメイン選択の各選択肢が妥当かどうかを表現した.ここでは,選択肢(I)の妥当性を表す特徴量(図5)と,選択肢(II)の妥当性を表す特徴量(図6)を定義し利用した.選択肢(III)は選択肢(I)と(II)の補集合であるため,選択肢(I)と(II)のいずれでもない場合に選択される.特徴は全部で32個用意した^(17))が,ここでは4.3節で有効とされたもののみを列挙している. 選択肢(I)は,1つ前の応答を行ったドメインが信頼でき,かつドメインを維持すべき場合に選択される.ここで利用した特徴量を図5に示す.本研究では,対話履歴を用いて1つ前の応答を行ったドメインが信頼できるかを表現する.たとえば,あるドメインでの対話中にユーザの肯定応答(「はい」「そうです」など)が多けれぱ,そのドメインが正しい可能性は高いとする(I_(1)).反対に,あるドメインでの対話中にシステムのスロットの状態に変化が見られなければ,ユーザ要求がそのドメインで処理されておらず,そのドメインが誤りである可能性が高い(I_(5),I_(7)).また,ドメインが信頼できる状況でもタスクの状態によってドメインの遷移しやすさが変化するため,これを特徴量としてタスクの種類に応じて用意した(I_(10)).スロットフィリング型タスク^(1))の場合は,埋まっていないスロットがある状態(タスク途中)と必要なすべてのスロットが埋まっている状態(タスク達成)の2種類とした.また,データベース検索タスクの場合^(1))は,文献18)で定義した2状態「検索条件の指定」と「情報の提示要求」とした.そのほかに,そのドメインを選択した場合の履歴・状態も指標とした.たとえば,そのドメインを選択したときに変化するスロット数が少ない場合は,そのドメインで音声認識結果をうまく処理できないと考えられるため,そのドメイン選択は誤りである可能性が高いとする(I_(13)).また,受理された音声認識結果の事後確率を,音響的・言語的にそのドメインが信頼できるかの指標として利用した(I_(14)).これは従来の研究で用いられていた指標と同様のものである. 次に,選択肢(II)の妥当性を表す特徴量を図6に示す.ここでも,対話履歴から得られる特徴量を利用した.ドメイン選択後のタスクの状態や,変化するスロット数などはここでも利用した(II_(1),II_(3)).また,選択肢(II)をとることで急激な話題の変化が生じる場合は,そのドメイン選択が誤りである可能性が高い.ドメインが(II)に変化し,かつドメイン間で共有しているスロット値が変化する場合,ドメインが変化するだけの場合や共有スロットが変化するだけの場合と比べて話題の変化が大きいため,そのドメイン選択が音声認識誤りによるものである可能性が高いとする(II_(4)).そのほかに,音声認識尤度最大の解釈結果を持つドメインで受理された,音声認識結果の事後確率や単語信頼度の相加平均を,選択肢(II)の音響・言語的な尤もらしさの指標とする(II_(6),II_(7)).また,選択肢(I)で受理された音声認識結果との比較を行い,その音声認識結果が曖昧性のあるものかどうかの指標として利用する(II_(8),II_(9)).」(p.1983左欄第5行?p.1984左欄第8行) カ「4.3 ドメイン選択で利用する特徴量の選択本研究では,4.2節で定義した各特徴量を用いてドメイン選択器を構成した.特徴量の中には判別に悪影響を及ぼすものがあるため,事前に以下の手順により特徴量選択を行った.以下では,ドメイン選択器の学習用対話データと,ドメイン選択精度の評価用対話データが用意されていると仮定している.ただし,今回は対話データが少ないため,クロスバリデーション法を用いて評価を行った. (1)文献17)で定義した特徴量の集合をFとする. (2)Fに含まれる特徴量から1つを選択し,(3)?(4)を行う.これをFに含まれる特徴量すべてに対して行う. (3)選択された特徴量をaとし,Fからaを取り除きドメイン選択器を学習する. (4)得られたドメイン選択器を用いてドメイン選択精度を算出する. (5)特徴量を取り除くことでドメイン選択の精度が向上した(もしくは変化がなかった)場合,最も精度の向上が大きかった特徴量をFから取り除き,(2)に戻る. (6)どの特徴量を除いてもドメイン選択精度が悪化するようになった時点で終了する.このときのFが判別に利用する特徴量集合となる.」(p.1984左欄第9行?p.1984右欄第2行) キ「5.評価実験 5.1 評価用データの収集提案手法の評価用データを収集するため,マルチドメイン音声対話システムを実装した.エキスパートを作成したドメインは,レストランデータベース検索,ホテルデータベース検索,寺社案内,天気案内,バス運行情報案内^(10))の5つである.それぞれの詳細を表1に示す.システム本体はJavaを用いて実装しているが,各エキスパートはどの言語でも動作するように設計している.実際,レストラン,ホテル,寺社,天気ドメインがJavaで実装されているのに対し,バスドメインはPerlで実装されている.また本システムは,複数のドメインにまたがるスロットの内容を共有する機能を有している.これにより,あるドメインで話題になったスロットの値を,後続するドメインに引き継がせることができる.今回の5ドメインでは地名属性に対応するスロットを共有させた^(☆). 音声認識エンジンはJulian^(15))を用いた.音声認識用文法は,各ドメインの言語理解部で用いた言語理解用文法から自動生成することにより得た.音響モデルにはJuliusディクテーションキット付属^(15))の3000状態PTMトライフォンモデルを利用した.またシステムからの応答には,図3,図4の対話例に示されるように音声認識結果を含ませることで暗黙的な確認を行った.さらにシステム発話は,音声合成を行うとともに画面上にテキストで表示した.これらによりシステム・ユーザ間に誤解が生じないようにした. 上記のシステムを用いて,10名の被験者から対話データを収集した.被験者はまず,音声入力のタイミングに慣れるため簡単なシナリオに基づき10分ほど練習を行った.その後ドメインを3?4回変更することを想定したシナリオに基づいて対話を行った.同様の条件で3対話を行った. データ収集時のシステムでは,音声認識結果の10-best解の上位から順に言語理解を行い,最初に言語理解できた発話から得られたドメインを選択した.ただし,1つ前の応答を行ったドメインには,音響尤度に40を加算して比較した.この値は予備実験に基づき決定した. 実験により得られた発話は総計2,205発話(221発話/人,74発話/対話)で,単語正解率は63.3%であった.単語正解率が低いのは,文法外,語彙外発話による音声認識誤りが起きたときに,ユーザが同様の発話を繰り返して誤りを増加させる傾向に起因する.また,音声認識率の低い話者ほどタスク達成までの発話数が多くなるため,全体として低い単語正解率となっている.収集したデータには,ユーザ発話の音声認識結果が肯定応答(「はい」など)であったものが274発話含まれる.これらに対しては,正解がほぼ「(I)1つ前の応答を行ったドメイン」となるため,以下の評価はこれらを除いた1,931発話を対象とした^(☆).なお肯定発話を含む全2,205発話に対する評価も併記している. 収集したユーザ発話には,各ターンごとにシステムが応答を行ったドメインを記録し,ユーザ発話の書き起こしをもとに以下に従って正解ラベルを付与した. (1)ユーザ発話に対する正解ドメインが,1つ前の応答を行ったドメインと同じ場合,ラベル(I)を付与する. (2)(I)以外の場合で,ユーザ発話に対する正解ドメインが,音声認識結果のN-best解の中で最も認識スコアの高い結果を解釈できたドメインである場合,ラベル(II)とする. (3)上記以外の場合にはラベル(III)を付与する. 今回の対話データに対して学習器C5.0^(2))を用いて生成した決定木を図7に示す.生成された決定木のうち最も上位に現れた特徴量は音声認識スコアの差(II_(8))であった.また,1つ前の応答を行ったドメインでの肯定の回数(I_(1))や対話における否定の割合(I_(9)),そのドメインに遷移してから変化したスロット数(I_(5))など,対話履歴から得られる特徴の多くが上位に現れた. この決定木を用いてドメイン選択を行った場合のシステム動作について,図8の対話を例にとり説明する.ここではユーザはU1で「明日の気温をお願いします」と発話したが,「パスタをお願いします」と誤認識され,レストランドメインヘ遷移してしまった.このとき,「パスタ」の単語信頼度が低かったため,S1のようにシステムからユーザヘの確認が行われた^(13)).これに対しユーザは,「天気をお願いします」と発話したが(U2),今度は「円福寺をお願いします」と認識されてしまった.このとき,選択肢(I)はレストランドメイン,選択肢(II)は寺社ドメインに対応する.(II)のドメインと(I)のドメインで各々受理した音声認識結果のスコアの差は26.2であった.また,(II)のドメインで受理した音声認識結果に含まれる単語の信頼度の相加平均は0.64と小さかった.(I)のドメインに遷移してからのユーザからの確認応答は1つもなく,そのドメインでタスクが達成されたこともなかった.さらに,変化したスロットはまだ1つもない^(☆)ため,変化したスロットの対話における割合は0である.(II)を選択した場合のタスクの状態は「検索条件の指定」であった.これらの特徴量から,図7の決定木をたどると,選択肢(III)「その他のドメイン」が選択される.その結果,誤ったドメインで対話を続けることを防止するための,「レストランまたは寺社についてお尋ねですか?」という確認を行える(S2).」(p.1984右欄第3行?p.1986左欄第8行) ク「5.2 ドメイン選択の精度の評価以下の2種類の方法で,ドメイン選択を行った場合の誤り数を比較評価した. ベースライン手法:音声認識結果を受理できたドメインのうち,認識スコアが最大のものを選択する.ただし,1つ前の応答を行ったドメインには,認識スコアに値αを加算して比較した. 本手法:提案するドメイン選択を行う.今回,ドメイン選択器はC5.0^(2))により構成した. 評価はいずれも発話ごとに行った.また,同一スコアのドメインが複数存在した場合,その中からランダムに1つのドメインを選択して正解判定を行った. ベースライン手法で,αの値を0から100まで変化させた際のドメイン選択誤りの数を調査した.ここではαの値が大きいほど,1つ前の応答を行ったドメインを維持する制約が大きくなる.α=0のときは,ドメインを維持する制約をまったく用いず,音声認識結果のみからドメイン選択を行う手法に相当する.α=35としたときに,誤り数が最も少なくなり,618であった.ドメイン選択誤り率は32.0%(=618/1,931)であった.この中には,正解ラベルが「1つ前の応答を行ったドメイン」「音声認識に対する最尤のドメイン」のどちらでもないものが361個含まれる.これらはベースライン手法の枠組では正解を選択できない発話である. 次に,本手法による評価を示す.表2に全データに対する場合,表3に肯定発話を除いた場合のドメイン選択結果を,それぞれcｏnfｕｓiｏn maｔｒiｘの形で示す.表中の各項目では,左の数字がベースライン手法,右の数字が本手法によるドメイン選択結果を表す.また,対角線上の項目がドメインが正しく選択された発話数に相当し,それ以外の項目がドメイン選択を誤った発話数に相当する.ここでは被験者ごとにデータを分割した10-fｏldのクロスバリデーションにより評価結果を得た.この評価結果は,決定木のカットオフパラメータを実験的に最適化した場合の値を示している.表2の結果の方が,判別の容易な肯定発話が含まれる分,表3と比べてドメイン選択精度は全体的に3%程度高い. 以下,表3について詳しく説明する.まず,本手法によりドメイン選択誤りの数が618から518まで減少し,全体のドメイン選択精度が68.0%から73.2%へと5.2%向上した.ドメイン選択誤りの削減率は16.2%(100/618)である.また,ベースライン手法では選択肢(III)は選ぱれない(表3の3列目)のに対し,本手法では158発話を検出している.これは,音声認識結果に対するドメインと1つ前に応答したドメインの両方が誤りである状況の約半分において,回復戦略をとるべき状況を検出できたことを示している.さらに,選択肢(I)では,適合率が0.74から0.80に向上し,F値が0.80から0.83に上昇した.また,選択肢(II)では,再現率が0.75から0.62へと減少したが,適合率が0.52から0.62へと向上し,F値は0.61で変わらなかった.このように本手法では,それまでのドメイン選択精度を落とすことなく,従来検出できなかった選択肢(III)を検出している. 今回の評価実験では,本手法によるドメイン選択精度が73.2%であり,いまだ26.8%のドメイン選択誤りが残っている.このうち,選択肢 (II)の判別に関しては,主に音声認識の精度がドメイン選択の精度に影響を与えている.今回の実験では音声認識の単語正解率が63.3%と低い中での評価であったために,選択肢(II)の判別精度が低くなっていると考えられる.また,実際は選択肢(I)もしくは(II)であるものを,選択肢(III)と誤って判定したものが,118発話存在した.ここで,選択肢(III)であるものを選択肢(I)や(II)と誤って選択した場合には,誤ったドメインでそのまま対話が進行してしまうのに対し,本来選択肢(I)や(II)であるものを選択肢 (III)に誤っても,ユーザヘのドメインの確認などのドメイン回復戦略が行われ,誤ったドメインでの対話が進行するわけではない.そのため,これらの誤りが対話に及ぼす悪影響は少ない.」(p.1986左欄第9行?p.1987左欄第33行) ケ「6.まとめ本稿ではマルチドメイン音声対話システムにおいて,対話の状態や履歴を用いることで音声認識誤りに対してより頑健にドメインを選択する手法について述べた.被験者10名による評価実験では,本稿で提案した手法により,従来手法に比ベドメイン選択誤りが16.2%削減されることを確認した. 本研究の意義を以下に示す. ・1つ前の応答を行ったドメインと音声認識結果に対する最尤のドメインの両方が適切でない状況を検出する必要性を指摘し,対話から得られる情報を用いることでその検出を可能とした.これまで,音声認識結果からドメインを推定するものや,1つ前の応答を行ったドメインを信頼してそのドメインを維持する研究は行われていたが,音声認識結果から得られるドメインと1つ前のドメインのいずれもが妥当でない状況の存在を指摘した研究事例はない.本研究では,これらの状況を検出することで誤ったドメインでの対話の継続を防止できることを指摘し,ドメインの妥当性を表現する特徴量の導入によりその検出を行った. ・様々な特徴最を用いた,ドメインの保守性・拡張性の高いドメイン選択法を実現した.これまでのドメイン選択では,各ドメインに対して判別スコアを算出していた.そのため,対話データなどから判別スコアを算出する場合には,ドメインを追加するたびに新たな対話データの収集が必要であるという問題があった.これに対し本手法では,ドメイン選択の対象を3クラスに抽象化することにより,ドメインの増減に対応できるドメイン選択法を実現した. 今後は,選択肢(III)が検出された際の最適なドメイン回復戦略の適用方法が課題となる.また今回の実験では改善が十分ではなかった部分に関して,新たな特徴量の設計などの検討が必要である.」(p.1987左欄第34行?p.1987右欄第23行) 引用文献1図表ここで、上記ア?ケの下線部及び表1の記載によれば、引用文献1には、以下の事項が記載されているといえる。 a 上記アによれば、引用文献1には、「シングルドメインの音声対話コンポーネントを統合したマルチドメイン音声対話システムにおいて、1つのシステムで複数のドメインを扱うことにより、ユーザの要求が複数のドメインをまたがるような複雑なタスクを扱う方法。」が記載されている。 b 上記アによれば、上記aの「マルチドメイン音声対話システム」は、「ユーザの発話に対する音声認識結果を用いてユーザ要求の対象ドメインを推定するドメイン選択」を行うことが記載されている。 c 上記イによれば、上記aの「マルチドメイン音声対話システム」は、「各ドメインでの対話を担当するエキスパートと、それらを統括するシステム本体とからなり、各ドメインごとにエキスパートが、ユーザ発話に対する言語理解や応答生成などのユーザ発話の処理を行い、システム本体では、どのドメインを担当するエキスパートにユーザ発話の処理を任せるかを振り分けるドメイン選択を行う」ことが記載されている。 d 上記ウ、エによれば、上記bの「ドメイン選択」は、音声認識結果から各ドメインごとにスコアを与え、スコアが最も高いドメインをドメイン選択するものであり、また、上記キによれば、上記bの「ドメイン選択処理」は、音声認識結果のN-best解の中から、認識スコアの高い結果を解釈したドメインを選択するものである。したがって、上記bの「ドメイン選択」は、「ユーザの発話に対する音声認識結果のN-best解の中から、各ドメインごとにスコアを与え、スコアが最も高い結果を解釈したドメインをユーザ要求の対象ドメインとして選択する」ものである。 e 上記オ、表1によれば、上記cの「各ドメイン」の「エキスパート」は、「スロットフィリング型タスク」、「データベース検索型タスク」を行うものである。 f 上記キによれば、システム本体はJavaを用いて実装され、各エキスパートはJava,Pealで実装され、音声認識エンジンはJulianが用いられている。 g 以上a?fによれば、引用文献1には、「シングルドメインの音声対話コンポーネントを統合したマルチドメイン音声対話システムにおいて、1つのシステムで複数のドメインを扱うことにより、ユーザの要求が複数のドメインをまたがるような複雑なタスクを扱う方法であって、前記マルチドメイン音声対話システムは、各ドメインでの対話を担当するエキスパートと、それらを統括するシステム本体とからなり、各ドメインごとにエキスパートが、ユーザ発話に対する言語理解や応答生成などのユーザ発話の処理を行い、システム本体では、どのドメインを担当するエキスパートにユーザ発話の処理を任せるかを振り分けるドメイン選択を行い、システム本体はJavaを用いて実装され、各エキスパートはJava、Perlで実装され、音声認識エンジンはJulianが用いられ、前記ドメイン選択は、ユーザの発話に対する音声認識結果のN-best解の中から、各ドメインごとにスコアを与え、スコアが最も高い結果を解釈したドメインをユーザ要求の対象ドメインとして選択するものであり、選択されたドメインのエキスパートは、スロットフィリング型タスク、データベース検索型タスクを行う、タスクを扱う方法。」(以下、「引用発明1」という。)が開示されている。 h なお、上記「引用発明1」の認定に関して、請求人は、平成29年4月21日付け意見書(以下、単に「意見書」という。)の3-1.(4),(5)において、引用文献1に記載された「本研究」または「提案手法」(以下、「本手法」という。)と、上記dは、「これまでの多くの手法」(以下、「従来手法」とういう。)とを混ぜ合わせたもので、引用文献1には、本手法と従来手法とを混ぜ合わせることは記載も示唆もされていないので、引用文献1には引用発明1は、記載されていないと主張している。しかしながら、上記の引用発明1は、以下に示すとおり、引用文献1に記載された本手法に相当する発明ではなく、引用文献1に記載された従来手法に相当する発明である。引用文献1の上記エには、「選択肢(II)は,ユーザの要求するドメインが変化したときに,音声認識結果に基づきドメイン選択を行う場合に相当する.このように,この枠組みは従来研究でのドメイン選択を包含する.」と記載され、上記クには、「ベースライン手法:音声認識結果を受理できたドメインのうち,認識スコアが最大のものを選択する.ただし,1つ前の応答を行ったドメインには,認識スコアに値αを加算して比較した.」、「ベースライン手法で,αの値を0から100まで変化させた際のドメイン選択誤りの数を調査した.ここではαの値が大きいほど,1つ前の応答を行ったドメインを維持する制約が大きくなる.α=0のときは,ドメインを維持する制約をまったく用いず,音声認識結果のみからドメイン選択を行う手法に相当する.」と記載されているように、本手法は、「従来研究でのドメイン選択を包含する」ものであり、また、本手法と比較の対象として記載された「ベースライン手法」において、α=0としたときが、音声認識結果のみからドメイン選択を行う手法、すなわち、従来手法であり、引用発明1のドメイン選択手法である。従って、引用文献1には、従来手法に相当する引用発明1が記載されているといえる。さらに、請求人は、意見書の3-1.(6)において、上記dの「『ドメイン選択処理』は、音声認識結果のN-best解の中から、認識スコアの高い結果を解釈したドメインを選択するものである。」との認定について、音声認識結果のN-best解は、決定木を学習器により生成するために、被験者から対話データを収集し、収集されたユーザ発話を書き起こして正解ラベルを付与することが記載され、このプロセスは従来手法のドメイン選択とは関係ないので、引用文献1には、音声認識結果のN-best解の中から、認識スコアの高い結果を解釈したドメインを選択することは記載も示唆もされていないと主張している。しかしながら、決定木の学習器による生成は、上記「キ」に、「各ターンごとにシステムが応答を行ったドメインを記録し、ユーザ発話の書き起こしをもとに以下に従って正解ラベルを付与した。」と記載されているように、ラベル(I)、ラベル(II)、ラベル(III)を学習する決定木であって、音声認識結果のN-best解を得てドメインを選択することは、評価用データのデータの収集においても、また、実際のドメイン選択の動作においても行われる事項である。上記クには、「ベースライン手法:音声認識結果を受理できたドメインのうち、認識スコアが最大のものを選択する。」、「ベースライン手法で、αの値を0から100まで変化させた際のドメイン選択誤りの数を調査した。ここではαの値が大きいほど、1つ前の応答を行ったドメインを維持する制約が大きくなる。α=0のときは、ドメインを維持する制約を全く用いず、音声認識結果のみからドメイン選択を行う手法に相当する。」と記載されているから、引用文献1には、ドメインの選択において、「音声認識結果のN-best解の中で最も認識スコアの高い結果を解釈できたドメイン」を選択することが記載されている。 2 当審拒絶理由に引用した「牛田他、自律的行動決定モデルに基づく対話エンジン、OMRON TECHNICS、日本、2000.03.20発行、第40巻,第1号(通巻133号)、pp.16-21」(以下、「引用文献2」という。)には、次のア?ウの記載がある。ア「2.システム構成本研究で用いる音声対話システムの構成を図1に示す。音声対話システムは、音声認識エンジン、対話エンジン、および音声合成エンジンで構成される。 2.1 音声認識エンジンユーザが発話する音声はマイクや電話回線を通してシステムに入力され、音声認識エンジンが入力された音声を認識する。本研究では音声認識エンジンとしてNｕance6を用いる。Nｕance6は、認識する単語や定型文を登録した文法を読み込み、これら単語や定型文に対して認識すべき音声の確からしさ(確信度)を、隠れマルコフモデル^(5))を用いて計算する。認識結果は確信度の大きい順にN個が出力される。これらN個の認識結果をNベストと呼ぶ。 2.2 対話エンジン対話エンジンはアプリケーションに応じた情報をスロット^(6))を用いて管理する。この概念を図2に示す。図2は航空機の発着予定を問い合わせるために必要なスロットの例を示している。このように、情報の検索、登録、予約などにおいて必要なスロット値を取得するタスクを「スロット充足型タスク」と呼ぶ。対話エンジンは、タスク達成に必要なスロット値を取得していなければ、そのスロット値を取得するための質問文を選択または生成する。質問文は音声合成エンジンを通してシステムからユーザに出力される。質問にユーザが回答すると、対話エンジンは音声認識エンジンから認識結果を受けとり、文脈に応じた解釈を行い、スロット値を確定する。認識エラーが発生したり、曖昧な回答を得た場合など、スロット値を確定できない状況が発生すると、対話エンジンはスロット値を確定するための対話制御を行う。」(p.16右欄第10行?p.17左欄第17行) イ「はじめに、課題1と3の解決策について説明する。対話エンジンは、まず、どのスロットを埋めるべきかというシステムの目標を設定する。次に、この目標を達成するために、誘導の発話を出力する。この誘導発話に対して、ユーザが発話を行うと、対話エンジンは認識エンジンからの出力を解釈し、設定した目標が達成されたか否かを評価する。そして、認識結果があいまいであったり、認識エラーが発生するなどして、目標が達成されない場合には、対話エンジンは改めて目標を設定しなおし、実行すべき目標を決定する。また、認識エラーの場合には前回と同じ誘導発話を繰り返して出力するのではなく、認識しやすい発話をユーザが行うように誘導するための発話を出力する。」(p.17右欄36行?末行) ウ「4.1 理解部音声対話においては、ユーザの発話した意図を理解する必要がある。理解部は、ユーザ発話の認識結果からの意図理解を担う。本研究ではユーザの発話した意図をユーザ発話タイプとして分類する。ユーザ発話タイプを決めるに当たり、スロット充足型のタスクを解析した。その結果、次のユーザ発話タイプを抽出できた。 (a)質問に対する回答 (b)確認に対する肯定 (c)確認に対する否定 (d)確認に対する訂正 (e)認識エラー (f)不確定 (g)ユーザからの要求このうち、(e)認識エラーは、音声認識エンジンの機能と、エラーを回復するための誘導を行うという2つの観点で、さらに次の3型に分類される。 (e-1)リジェクト:認識結果の確信度が閾値未満の場合 (e-2)未発話タイムアウト:ユーザが一定時間内に発話しない場合 (e-3)過発話タイムアウト:ユーザが一定時間を越えて発話し続ける場合また、(f)不確定は、ユーザ発話において言い間違え、情報の欠落、倒置などが発生することによりスロット値が不確定となる場合である。認識結果をスロット値として解釈する処理では、テーブル参照により認識結果に対するスロット値を求める。テーブル参照では、認識エンジンから得るN個の認識結果(Nベスト)のうち、最も確信度が大きい認識結果を用いるようにした。また、Nベストのうち確信度が2位以下の認識結果も残すようにした。2位以下の認識結果を残す理由は次の通りである。確信度が最大の認識結果に対するスロット値を用いてシステムが確認し、ユーザが確認を否定した場合には、システムは質問しなおさなければならない。しかし、質問しなおしても、確信度が最大の認識結果が前回と同じ場合、正しいスロット値を取得できない。このため、確信度が1位の認識結果に対するスロット値が否定された場合には、2位以下の認識結果を用いて確認を行えるように、2位以下の認識結果を残すようにした。 4.2 評価部評価部は対話エンジンが設定した目標が達成されたか否かを評価する。スロット充足型タスクにおける目標はスロット値を取得することである。そこで、評価部は質問したスロット値を取得することができたか、または、確認したスロット値について肯定されたか、ということを評価する。質問したスロット値を取得した場合や、確認したスロット値が肯定された場合には、目標が達成したと評価し、そうでない場合は目標が紛糾したと評価する。 4.3 対話管理部課題2の説明で述べたように、音声対話においてタスクに依存するのは、スロットと、それらスロットを充足する順番である。このため、複雑な対話制御は対話エンジンの自律性に任せ、目的タスクに応じたシナリオを与えるだけで対話フローを生成することとした。シナリオには充足すべきスロットの定義と、それらスロットを充足する順番を記すようにした。シナリオの例を図4に示す。図4は航空機の発着予定を問い合わせるのに必要なスロットを充足するためのシナリオの例である。対話管理部はシナリオで定義されたスロットを生成し、シナリオの順番にスロットを充足するための命令を作業記憶に出力する。そして、認識結果により取得したスロット値をスロットに入れて確定する。しかし、誤認識の場合もあるので、対話管理部において、確信度の値に応じて、スロット値を確定するか、確定せずに回答を確認するかを決定するようにした。 4.4 目標設定部スロット充足タスクではスロット値を取得して確定しなければならない。このため、目標設定部は対話管理部からの命令にしたがって、スロット値を質問する目標、または、スロット値を確認する目標を設定する。しかし、ユーザの発話によっては認識エラー、誤認識、不確定などの状況が発生して目標が紛糾する場合がある。このため、目標設定部において、質問や確認をやり直すために、目標を再設定する。また、ユーザから操作方法の説明などを要求された場合に、これに応答するための目標を設定するようにした。 4.5 行動計画部目標設定部は対話管理部からの命令、目標の紛糾、およびユーザからの要求のそれぞれ状況に対して目標を設定する。1回のユーザ発話から、複数の状況が発生することもある。この場合、目標設定部は複数の目標を設定することになる。しかし、設定されたすべての目標について、システムが一度に質問、確認、説明などを行うと、ユーザの負担が大きくなる。このため、行動計画部において、これら目標の中で優先順位を決めて、発話すべき目標を決定するようにした。 4.6 行動生成部発話すべき目標が決定したら、具体的な発話文を選択する必要がある。このため、行動生成部において、目標に対応した発話文を選択するようにする。例えば、出発地を質問する目標に対して、「出発地をどうぞ」という発話文を選択する。しかし、認識エラーが原因で同じ質問を繰り返す場合に、常に同じ発話文を選択するのは、協調的な対話とは言えない。システムは認識エラーから回復するようにユーザを誘導すべきである。例えば、システムの認識できない語旬を発話したことによる認識エラーに対して、例示の語句を発話文に含めて誘導する。また、ユーザの声が小さくて認識できないのであれば、大きな声で発話するように誘導する。このため、行動生成部では、目標に対応した発話文を選択することに加えて、認識エラーの状況に応じて発話文を選択するようにする。」(p.18左欄下から14行?p.19下から3行) 引用文献2図面以上下線部、特に、上記アの記載によれば、引用文献2には、「スロット充足のタスクでは、対話エンジンが、情報の検索、登録、予約などアプリケーションに応じた情報をスロットを用いて管理し、スロット値を取得するための質問文を選択または生成し、音声認識エンジンからの認識結果を受け取り、文脈に応じた解釈を行い、目的のタスク達成に必要なスロット値を確定すること」(以下、「引用文献2記載の技術事項」という。)が記載されている。 3 当審拒絶理由に引用した「神田他、データベース検索タスクにおける対話文脈を利用した音声言語理解、情報処理学会論文誌、日本、2006.06.15発行、第47巻,第6号、pp.1802-1811」(以下、「引用文献3」という。)には、次のア,イの記載がある。ア「3.データベース検索タスクの対話モデル本稿では,表1のような関係データベース(各エントリは,属性名とその値の組で表され,各データは1つのキー属性を持つ)に対し検索するタスクを扱う.以下対象ドメインをレストランデータベースとして議論を進める^(☆☆).このタスクは,必要なスロットが事前に決定できるスロットフィリング型^(1))タスクに対し,以下の点で異なる. ・タスク達成に必要なスロットがユーザごとに異なる:ユーザによって,予算が重要であったり,場所が重要であったりする. ・ユーザの意図が対話中に変化する:システムからの返答を聞くまで満足できるエントリが存在するかどうかが分からないため,ユーザはしばしば検索された結果を見て要求を変更する. 対象とするデータベース検索タスクでの対話の例を図1に示す. 対話の各時点での状態が表現されていれば,それを対話文脈的な制約として言語理解に利用することができる.スロットフィリング型タスク(天気案内,バス運行情報案内など)を扱うシステムでは,対話の流れを事前にすべて記述できるため,有限オートマトンによって対話の流れをモデル化し,対話の各時点で明示的に状態が定義できる^(7),8)).しかしながら,データベース検索タスクでは上記の特性より事前に対話の流れを記述しておくことが不可能であるため,これらとは異なるモデル化を行う必要がある. また各システムごとに対話状態を設計すると,それに基づく制約はそのシステム以外では利用できないものとなる.本研究では対象とするデータベースに依存しない制約を得ることを目的としている.そのため発話の棄却や解釈に有用な制約を得ることができ,かつデータベースに依存しない対話状態設計を行った. 以下では,本稿で提案するデータベース検索タスクのモデルに関する説明を行う. 3.1 対話の進行モデル本研究では,上で述べた条件を満たすモデルの1つとして,データベース検索タスクにおける典型的な対話の進行を,まず希望する検索条件を指定して数件までエントリを絞り込み,その後絞り込んだエントリに関するその他の属性の値を取得するものと想定する.これはレストランデータベースにおいては,はじめに希望する店(エントリ)を絞り込み,その後絞り込んだ店の住所や電話番号など(キー属性以外の属性)を取得することに相当する.ここでの前者を「検索条件の指定」モード,後者を「情報の提示要求」モードとする.本研究ではデータベース検索タスクにおける状態は2つのモードのいずれかに属し,対話はモード間を遷移することで行われるとする(図2).以下,これを対話の進行モデルと呼ぶ.言語理解部では,各時点で対話がどちらのモードであるかや,その時点でのエントリ数などが,対話状態の表現として利用される. たとえば図1では,U1?U4が「検索条件の指定」モードにおける発話であり,U5によって対話の状態は「情報の提示要求」モードに移行している.また,得られた検索結果を吟味した結果ユーザが満足しなかった場合,再び「検索条件の指定」モードに戻ることもある.」(p.1803右欄第13行?p.1804右欄第10行) イ「4.1想定発話パターンとの類似度計算各対話行為ごとに複数用意した想定発話パターンと音声認識結果の類似度を計算する.類似度の計算は文献17)に従った^(☆).これは,音声認識結果が文としてどれだけその対話行為らしいかを表す^(☆☆).レストランドメインにおける想定発話パターンには「FOODTYPEがおいしい店を教えてください」といったものを590文用意した.なお想定発話パターン中のFOODTYPEはレストランデータベース中のフードタイプ属性の値に対応している.」(p.1805右欄第11?20行) 引用文献3図表以上下線部の記載によれば、引用文献3には、「データベース検索タスクでは、各エントリが、属性名とその値の組で表され、各データは1つのキー属性を持つ関係データベースに対して、検索するタスクを扱い、対話が「検索条件の指定」か、「情報の提示要求」なのかのモードを判定し、検索条件の指定により、属性と属性の値でエントリを絞り込み、情報の提示要求により、絞り込んだエントリに対してキー属性以外の属性を取得すること」(以下、「引用文献3記載の技術事項」という。)が記載されている。 4 当審拒絶理由に引用した特開2004-333870号公報(以下、「引用文献6」という。)には、次のア?ウの記載がある。ア「【0006】【発明の実施の形態】はじめに、本発明に関する音声認識技術の一般的事項について説明する。すなわち、音声認識では、入力された音声をAD変換し、その離散系列ｘに最も適合する言語表現ωを推定する。これらを実現するためには言語表現ωを予測するため、予め言語表現を記述した辞書(以下、言語辞書と記述)が必要となる。従来提案されている手法としては、単語の接続状態をネットワーク構造によって文法を表現したネットワーク文法言語辞書と、単語間の統計的な接続確率を表現した統計的言語辞書が主に提案されている。【0007】ネットワーク文法では、例えば、図15のように「住所は＜県名＞県」のような入力を許す言語辞書を設計することができる。このとき、システムは「住所は」の発話の後には必ず「＜県名＞」が入力(発話)され、更に「＜県名＞」の後には必ず「県」が入力されることを想定している。ここで、＜県名＞の部分は予め必要な県名を記述しておく必要がある。もちろん県名以下の入力、例えば市区町村等も同様の手法で記述することができる。この手法では、入力可能な語彙とその接続過程を限定することで高い認識性能が得られる。【0008】一方、統計的言語辞書では、大量のサンプルデータから統計的な手法によって、単語と単語(形態素と形態素)の遷移確率の推定を行う。最も単純で広く用いられている手法がn-gｒamモデルと呼ばれるものである。これは、入力された単語列ω1ω2…ωnに対する出現確率をP(ω1ω2…ωn)として言語表現の推定をする場合に、【0009】【数1】のような近似を行うモデルである。特に、n=1の時をｕni-gｒam、n=2の時をbi-gｒam(2-gｒam)、n=3の時をｔｒi-gｒam(3-gｒam)という。図16ではbi-gｒamによる言語辞書を用いたときを例にとり、ωn-1の入力単語で「奈良」が出現した時、ωnでの其々の単語列への推移計算を示している。このとき、【0010】【数2】のように、直前の単語だけに依存すると考える。n-gｒam言語辞書は学習させるサンプルデータが膨大であれば、多くの単語間の接続パターンを自動的に含むことができるため、ネットワーク文法と異なり設計者が想像できなかった言い回しで入力された文法を受理することも可能である。しかし、この統計的言語辞書は自由度が高い反面、特定のタスクに限定した音声認識を行うことは、その認識率の低さに問題があるとされている。このような問題を解決する一手段として、前記非特許文献2の手法(GA方式)の提案があり、この手法を用いることにより、認識精度において、n-gｒam言語辞書だけを用いた場合と比較して5ｐｔ以上改善している。」イ「【0016】図1の120および図2の220に示す音声認識手段では、入力された音声信号を認識して、認識結果信号R100を送出する。認識結果信号R100は、例えばテキストなどの情報形態に変換されている。これは図3の演算装置330と例えば図2における記憶手段270とによって実現できる。演算装置330としては、例えば、一般的なパーソナルコンピュータ、マイクロコンピュータ、信号処理装置としての演算機能を有するシステムを構成するCPU、MPU、DSPを単数、或いは複数個組み合わせればよく、実時間処理が可能な演算能力を有していることが望ましい。また記憶装置もキャッシュメモリ、メインメモリ、ディスクメモリ、フラッシュメモリ、ROM等、一般的な情報処理機器に用いられている情報記憶能力を有する機器を用いればよい。【0017】図1に示す次発話予測手段130では、認識された語彙をもとに、次に使用者が発話する内容を予測し、予測された情報を図1に示す確率変更手段150に送る。一方、図2に示す次発話予測手段250では、図2に示す情報制御手段230から得られる情報をもとに、次に使用者が発話する内容を予測し、予測された情報を図2に示す確率変更手段260に送る。尚、図1および図2の次発話予測手段130および250については入力情報信号は異なるが、出力する情報信号は同一である。【0018】図1に示す確率変更手段150では、送られてきた次発話予測情報を基に、図1に示す記憶手段140に記憶されている統計的言語辞書内に含まれる単語間の文法に関する正答確率を高くする。図2に示す確率変更手段260も同様の機能を有する。【0019】図1に示す記憶手段140には音声認識に必要な、音素辞書、単語辞書、単語の接続を記述した一つ以上の言語辞書が記憶されており、認識などの演算時に参照される。図2に示す記憶手段270では、更に、類語辞書、履歴情報も記録されている。」ウ「【0022】以下、図4を用いて本発明における実施の形態に関する動作の流れについて説明する。システムが動作を開始すると、はじめにステップS110において、システムが初期化される。このとき、初期状態として音声認識に必要とされる辞書がメモリ(RAM)上に展開されるが、所有している全ての辞書を読込む必要はない。ステップS120では、入力された音信号が音声かどうかを判断する。音声信号であればステップS130に進み(Yeｓの場合)、音声でなければ音声が入力されるまで待ち受ける(Nｏの場合)。ステップS130では、n-1番目に入力された音声を認識して、音声情報に含まれる情報を、例えばテキスト情報のような形式に変換する。ステップS140では、ステップS130で出力された情報をもとに、発話状態の変化を検出する。例えば、S130で出力された情報が、「住所を入力したい」というテキスト列であった場合(Yeｓの場合)は、使用者の次発話は具体的な住所であると判断できる。このような状態変化を検出し、次発話内容を予測する。また、状態変化が検出されなかった場合(Nｏの場合)には再び音声入力の待ち受けに戻る。【0023】ステップS150では、ステップS140で検出された発話状態の変化と予測された次発話をもとに、統計的言語辞書内に存在する予測された次発話の単語間の文法に関する確率を変更する。なお、確率の変更対象については後述する。ステップS160で次の発話を検出し、次いでステップS170で、n番目に入力された音声を検出し、音声発話がある場合には(Yeｓの場合)入力された音声をステップS170において認識して音声情報に含まれる情報を、例えばテキスト情報のような形式に変換する。音声発話がない場合(Nｏの場合)は音声発話待ちの状態に戻る。この時はステップS150によって、統計的言語辞書の単語間の文法に関する確率がすでに修正処理されていることにより、n番目発話音声の認識のために適切な状態となっており、ステップS150を導入しない場合と比較して認識率が向上している。同様にステップS180では、次発話の予測を行い、次発話の状態変更が検出された場合(Yeｓの場合)はS190で、統計的言語辞書内に存在する予測された次発話の単語間の文法に関する確率を変更する。また、状態変化が検出されなかった場合(Nｏの場合)は、状態変化待ちの状態に戻る。【0024】以下、図4のステップS150における確率の変更方法について述べる。図5では、図4のステップS140において、次発話が住所入力であることが予測できた後の、統計的言語辞書の変更例を示している。図5のネットワーク文法言語辞書には、神奈川、奈良、埼玉とそれに続く県が記述されている。このとき、ネットワーク文法言語辞書における単語の接続である「神奈川-県」「奈良-県」「埼玉-県」を、統計的言語辞書の中から探し、それぞれに割り振られている確率を高くするように変更する。例えば、「奈良-県」の連接単語では、【0025】【数3】を計算する。このときα＞1であり、事前に決定しておく。【0026】一方、図6では、ネットワーク文法言語辞書に含まれる単語と、その単語に接続し得る単語および形態素間の接続確率を向上させる例を示している。ここでは、ネットワーク文法に記述されている単語間の接続と、前記単語に接続し得る形態素と単語の接続確率の何れも変更している。例えば、図6のネットワーク文法言語辞書には、神奈川、奈良、埼玉と、それに続く県が記述されている。このとき、神奈川、奈良、埼玉に接続される可能性のある、統計的言語辞書に含まれる全ての単語の接続確率を変更する。「神奈川」に続く可能性のある単語で統計的言語辞書に含まれるものは、「県」あるいは「の」であるため、P(県│神奈川)、P(の│神奈川)の2つの確率を(数3)式を適用して変更する。尚、確率修整の計算は、音声認識前に統計的言語辞書に対して行なう場合と、音声認識中に、音声認識結果候補として出力された文節に含まれる連接単語とネットワーク文法言語辞書とを比較して、前記連接単語がネットワーク文法言語辞書に存在した場合に計算するような仕組みとの何れを選択しても良い。【0027】以下では、前述のネットワーク文法言語辞書の利用手法について説明する。本発明に用いる、ネットワーク文法言語辞書について、2つの利用手法が考えられる。一つは、図7に示すような複数個の小規模なネットワーク文法言語辞書を切り替える手法である。例えば、インターネットのホームページ画面のように、表示内容が予測できない場合、図7のように、記憶手段701に表示画面が取り込まれた段階で辞書として登録する。このような場合、現在表示されている内容および過去に表示された内容を認識することが望ましいため、複数の小規模なネットワーク文法言語辞書702、703を記憶手段701に読み込むか、あるいは不必要な言語辞書を削除する動作を行う。一度登録された言語辞書は音声認識手段704に内蔵のスイッチ制御部705の操作で音声認識手段704に接続され、一時的に不必要なときはスイッチをOFFに、あるいは当分使用しないと判断される場合は記憶手段701から削除する。【0028】もう一方は、図8に示すように、あらかじめ大規模なネットワーク文法言語辞書802を記憶手段に有し、必要な情報すなわち予測される次発話に関係しているノードだけを動的に有効にしていく方法である。例えば、カーナビゲーションシステムでは、目的地設定などは必須のタスクである住所、施設などの情報を予め記憶手段801に記憶しておくことが望ましい。すなわち、記憶手段801は、統計的言語辞書803と、発話内容を含む一つ以上のネットワーク文法言語辞書802と、を記憶しており、確率変更手段804は、次発話予測手段805によって予測された次発話に適合するネットワーク文法言語辞書802内のノードを選択し、前記統計的言語辞書内においてネットワーク文法言語辞書内のノードに含まれる連接単語の遷移確率を高くするように機能する。また、ネットワーク文法言語辞書は、例えば複数の階層と、複数のノードをもつ木構造を有している。なお、木構造とは、枝を張った木のように、太い幹から順次細かく枝分かれして行く構造、つまり階層の高いものから低いものへ分かれて行く構造を意味する。【0029】以下、図1および図2における次発話予測手段による予測手法について具体例を挙げて説明する。はじめに、カーナビゲーションシステムで用いられることの多い住所入力のタスクを、本発明と表示装置を組み合わせて実現する例について説明する。カーナビゲーションシステムの住所入力タスクでは、県名、市区町村名、町域名、番地のように、階層構造に情報を並べ、上位階層から情報を音声入力させる手法が一般的である。従来のシステムとしては、階層毎に区切って入力する手法と、上位階層から連続して入力する手法が存在し、入力されるコマンドの情報はネットワーク文法言語辞書として記述されている。【0030】本発明においては、図9に示すように表示装置にネットワーク文法言語辞書を表示させている。これは使用者にネットワーク文法言語辞書内の単語を知らしめることでシステムのコマンドの入力限界を示し、更に、表示された単語入力を促すねらいがある。表示された連接単語は使用者にとって発話しやすい音声コマンドに含まれるため、次発話予測手段では“表示された連接単語”を次発話の可能性があると判断する。図9の表示画面901の例では、4つの県名と、カーソル(アンダーバ)が設定されている埼玉県の4つ市(さいたま市、川口市、志木市、川越市)が表示されており、統計的言語辞書内において、前記表示連接単語の接続に関する確率が変更される。【0031】図10では、図9の表示画面右側のスクロールを動かした場合の変更された連接単語を示す。図9では「さいたま市」、「川口市」、「志木市」、「川越市」が表示画面901の市町村名の窓に表示されていたが、図10では「川越市」、「鴻巣市」、「吹上市」、「春日部市」が表示されている。よって、次発話として予測され、接続に関する確率が変更される連接単語は図10のように、表示変更後の画面に存在する連接単語となる。図11では、表示されている連接単語に加えて表示されている単語に文法的に接続し得る形態素との連接単語を次発話として予測した例を示している。県名の後に続く語彙としては、「神奈川」→「県」の場合と、使用者によって県が省略され「神奈川」→「の」と発話される場合が考えられる。このように、名詞の後に助詞をつけて後置詞句を作成するような、文法的に典型的な単語の接続パターンについては次発話として予測する。このような典型的な文例に関しては、対象言語の品詞接続表および特定単語に対する処理などを記憶手段に保存しておくと効率的に運用できる。同様の発想で、「神奈川」のような地名が表示されている場合は「神奈川」→「に」、「に」→「行く」のように、関連しそうな述語まで含めて連接単語の接続に関する確率を変更しても良い。図12では、表示されている単語と、表示されている単語の下位階層に位置する単語を連接単語とみなして、前記連接単語を次発話として予測した例を示している。表示単語である「さいたま市」の下位階層には複数の区名が存在する。よって、「さいたま」→「市」、「市」→「浦和区」、「市」→「大宮区」のように市区名の連接単語を次発話として予測する。【0032】次に、インターネットのホームページ情報の表示で用いられることの多い文節、文章についての次発話予測の例を説明する。図13では、4つの文節が表示されており、それぞれに複数の連接単語が含まれている。このような場合、それぞれの連接単語を次発話として予測するのはもちろんのこと、個々の単語と、前記単語から接続される可能性のある単語による連接単語についても次発話として予測する。図13では、「スカイライン」という単語について、既に表示されている「スカイライン」→「クーペ」の他に、後置詞句をつくる「スカイライン」→「の」などが次発話として予測される。その他にも商品ラインナップ情報などを記憶手段に保存しておけば、「スカイライン」→「セダン」などの情報も次発話として予測できる。【0033】文節、文章を用いた情報は音声ガイダンスとして提示される場合もある。音声ガイダンスによる情報提示では、次発話として予測される語彙を減らすことができる。図13を例に取ると、4つの文節メニューの内、先頭の、「新型スカイラインクーペプレゼント」が音声によって提示された場合、変更する連接単語の例として、 (連接単語群1)「新型」→「スカイライン」、「新型」→「キューブ」、… (連接単語群2)「スカイライン」→「クーペ」、「スカイライン」→「セダン」、… (連接単語群3)「クーペ」→「プレゼント」、… などが考えられる。2番目の、「TRY!コンパクトカーキャンペーン」が音声によって提示された場合、 (連接単語群4)「TRY」→「コンパクト」 (連接単語群5)「コンパクト」→「カー」、「コンパクト」→「な」、… (連接単語群6)「カー」→「キャンペーン」、「カー」→「ディーラー」、… などが変更する連接単語の例としてあげられる。この場合、音声提示された順に連接単語の接続に関する確率を変更していき、音声提示が終了して一定時間経過した後、徐々に変更前の確率に戻していく。このように音声ガイダンスと本発明を組み合わせると、次発話予測する連接単語の範囲を狭めることができるため効果的である。【0034】表示、音声などで提示された連接単語の類語も次発話として予測できる。最も簡単な方法は、前記記憶手段に類語辞典を有し、入力された単語の類語を調べ、この単語と置き換えた連接単語を予測値とすることである。図14は、4つの単語が表示された画面において、「エアコン」に関する類語を前記統計的言語辞書に加え、連接単語を作成して追加した例である。追加される単語は「クーラー」、「空調」、「冷房」であり、エアコンの場合と同様に、連接単語としてそれぞれ、「クーラー」→「ON」、「クーラー」→「の」「空調」→「ON」、「空調」→「の」「冷房」→「ON」、「冷房」→「の」が次発話として予測されている。また、以上の処理で次発話として予測された単語を文章の主語および述語としての機能を有する単語に限定することにより、処理効率をさらに高めることが出来る。【0035】最後に、音声の入力履歴を用いて次発話を予測する方法について説明する。音声ガイダンスの例でも述べたように、提示された情報の履歴をもとに、統計的言語辞書内において履歴の増加と共に徐々に連接単語の接続に関する確率を変更していくことは有効である。更なる発展法としては、 1.階層構造の情報において、一度使用者が表示させた階層は一定期間、連接単語の接続に関する確率を変更しつづける、 2.数ターン前に入力された内容に含まれる連接単語は一定期間、連接単語の接続に関する確率を変更しつづける、 3.使用者の癖が履歴で明らかなときには関連する連接単語の接続に関する確率を変更しつづける、等が考えられる。3について、例えば、・システム起動時に必ずラジオを設定する、・特定の時間にラジオをつける、といった動作が履歴により発見されたとき、操作に関連する連接単語の接続に関する確率を変更することで、使用者にとって使い勝手のよいシステムとなる。【0036】なお、以上述べた処理において、予測された連接単語が統計的言語辞書に存在しないことが判明した場合、その時点で当該単語を統計的言語辞書に追加すると同時に、連接単語の接続に関する確率を付加する。上記に述べた例はあくまで発明内容の理解を容易に行なうためであり、発明の範囲は上記に限定されるものではない。【0037】以上述べたように本発明によれば、入力音声に対して文法的制約を低減することなく認識精度を維持し得る移動体用音声認識装置の実現を可能としたのみならず、以下の効果についても実現している。すなわち、記憶容量の増加を抑えることができたため、装置規模の増大を抑えることができた。また、計算時間を少なくできたため移動体における実時間処理を可能としている。このような効果は、認識処理アルゴリズムにおいて複数の階層と木構造を採用し、ネットワーク文法言語辞書の内容を工夫することにより実現し得たものである。また、使用者に提示する情報とリンクすることで、次発話予測の制度を向上している。さらに、文節および文章で与えられた情報に対しても、精度の高い次発話予測を可能としている。このため、使用者による発話自由度も高く出来、その上、統計的言語辞書の語彙を増加させることもなく、また、統計的言語辞書に含まれていない単語が次発話として予測された場合でも、処理を可能とすることができるようになった。」上記下線部の記載によれば、引用文献6には、「音声認識において、単語間の統計的な接続確率を表現した統計的言語辞書の連接単語の接続に関する確率を、対話履歴に基づいて一定期間変更させ、変更させた統計的言語辞書に基づいて単語と単語の遷移確率の推定を行い、単語列の推定を行い、また、使用者の癖が履歴で明らかなときには、統計的言語辞書の関連する連接単語の接続に関する確率を変更すること」(以下、「引用文献6記載の技術事項」という。)が記載されている。 5 新たに引用する「河原達也,李晃伸:連続音声認識ソフトウェアJulius,人工知能学会誌,日本,2005.01.01発行,第20巻,第1号,pp.41-49」(以下、「引用文献9」という。)には、次のア?カの記載がある。ア「Juliusは,ディクテーション(音声入力ワープロのような口述筆記)などの大語彙連続音声認識を主な目的として著者らが開発したフリーソフトウェアである.その後,記述文法への対応を含めてさまざまな機能拡張・性能改善が継続的に行われており,現在は下記のWebサイトにおいて,最新・完全版が無償で入手できる.」(p.41左欄第1-6行) イ「(市販の音声認識ソフトと比較して)Juliusの最大の特徴は,汎用性・可搬性である.すなわち,音響モデルや言語モデルなどのインタフェースが公開されており,それらを置き換えたり,修正したりするのが容易なことである.これにより,さまざまな使用環境や目的に応じたシステムの構築が簡単にできる.さらに,ソースコードも公開されているので,システム自体の修正・拡張も可能である.逆に事前登録学習(エンロールメント)や自動適応学習などの機能は現在実装されておらず,単語登録をするGUIもないので,音響モデルや単語辞書・文法ファイルなどを直接操作する必要がある.」(p.41左欄19-29行) ウ「当初JuliusはIPAのプロジェクトである「日本語ディクテーション基本ソフトウェア」のコアエンジンとして作成された.したがって,ディクテーションで一般的な単語N-gramモデル(N単語連鎖の統計量に基づくモデル;詳細は5・2節参照)のみを扱う仕様であった.参考文献[鹿野01]の付録CD-ROMに収められているものもこの版(Rev.3.1)である. 一方,音声対話システムなどタスクが明確な場合は専用の文法を人手で記述するのが一般的である.このような記述文法向けの音声認識エンジンとして,(Juliusと大半のコードを共有した)Julianが作成された.こちらはIPAプロジェクトの後継である連続音声認識コンソーシアム(http://www.lang.astem.or.jp/CSRC/)を通した限定的な配布であったが,2003年秋にその終了に合わせて,JulianをJuliusのパッケージに統合してフリーで公開することとした.このような経緯から,現在でもUniｘ版で記述文法用のエンジンの実行形式は"Julian"という名前になっている.」(p.41右欄第19行?p.42左欄第3行) エ「Unix版の動作環境は,Linuxを含むUnixである.Linux用の実行バイナリがあらかじめ用意されているが,ほかのUnixについてもソースからコンパイルすることで動作する(2004年10月時点の最新版はrev.3.4.2). ディクテーションの実行に必要なもの(Julius実行バイナリ,N-gram言語モデル,および標準的な音響モデル)を一つにまとめた「ディクテーション実行キット」がWebサイト(http://julius.sourceforge.jp/models.htm)で公開されている.展開したディレクトリ上で, % ./bin/julius -C fast.jconf を実行することで,マイクからの音声入力に対するディクテーションが行える.」(p.42左欄第24?35行) オ「機器の操作や天気などの情報案内・商品の注文など,音声認識を用いるタスクが限定されている場合は,想定される発話パターンを文法の形で記述するのが,高い認識精度を実現するうえで手っ取り早い. 記述文法の場合は,"Julian"という実行形式を用いる.Julianで用いる文法の形式は独自のものであり,文法規則をgrammarファイルに,単語辞書をvocaファイルにそれぞれ記述する.図3に,果物注文タスクにおける想定文を受理するJulian用の文法と語彙ファイルの例を示す. これらを付属のコンパイラ"mkdfa.pl"を用いてJulianで使用できる形式(.dictおよび.dfa)へ変換する.ここで,vocaファイルに単語の読みを直接音素列で記述する必要があるが,ひらがなを音素列へ変換するスクリプト"yomi2voca.pl"がUnix版パッケージに含まれている.」(p.42右欄第16?30行) カ「5・1 音声認識の基本原理図5に連続音声認識の基本原理を示す.ここで,音響モデルは音素(ローマ字1文字にほぼ相当)や音節(かな1文字に相当)の周波数パターンを保持し,入力音声とマッチングを行うものである.単語辞書は認識対象の語彙(=単語の集合)とその発音を規定し,ここで規定されているもののみがマッチングの対象となる.文字認識と異なり,文字を認識してから単語を照合するのでなく,単語辞書を照合しながら文字を認識することに注意されたい.これは,音声が本質的に続け字のように文字の区切りが明確でないためである.言語モデルは,単語の連鎖を規定するもので,決定的な記述文法を用いる場合は,それで規定されるもののみが照合の対象となる. (しばしば誤解されるので)正確にいうと,Juliusは図5においてデコーダと呼ばれているモジュールであり,これは,与えられた音響モデルや言語モデルを用いて,入力音声Xを単語列Wに認識(デコード)するものである.商用のソフトウェアでは(内部的にはともかく)音響モデルや言語モデルが一体化されているのに対して,Juliusは音響モデルや言語モデルと完全に独立で,それらとのインタフェースもオープンなのが特徴である.したがって,これらを差し替えることにより,さまざまな入力環境やタスク,しいては日本語以外にも(あるいは音声以外にも?)適用することができる. 次にやや専門的になるが,図5に基づく連続音声認識の原理を確率的な枠組みで説明する.音声認識は,入力音声Xに対する事後確率p(W\|X)が最大となる単語列Wを見つける問題として定式化できる.事後確率p(W\|X)を直接計算することは非常に困難であるので,ベイズ則により以下のように書き換える. p(W)p(X\|W) p(W\|X)=?????? (1) p(X) この分母については,Wの決定に影響しない正規化係数と考えられるので,これを無視することができる.分子については単純なパターン認識(数字の認識など)においては,Wの事前確率p(W)を等しいと仮定することができ,その場合はp(X\|W)のみで決定されることになるが,連続音声認識においてはp(W)も大きく関与する. 5・2 音声認識における言語モデル式(1)のp(W)は(音声Xが入力される時点で)ある単語列Wのパターンが生起する確率であり,これは(音声Xとは無関係の)言語的な確からしさである.ディクテーションでは,日本語で使用される単語の統計量や,「私」の次には「は」や「の」がきやすいといった統計量に基づいて確率を推定している.タスクが限定されている場合は,文法的・意味的に正しくないものを除外する(確率0とする)ことにより,認識の候補を絞り込む. 単語辞書が語彙(認識対象の単語集合)を規定するのに対して,言語モデルは単語間の接続関係を規定するものであり,単純な単語音声認識はこれがない場合とみなすことができる.言語モデルは,統計的なモデルに基づくものと,決定的な記述文法に基づくものに大別できる.言語モデルの適用は,通常先頭の単語から逐次的に行われ,単語列W={w_(1),w_(2)…w_(k)｝(w_(i)は各単語)に対して p(W)=Πp(w_(i)\|w_(1)…w_(i-1)) (2) ^(i) のようになる.これは,記述文法の場合は,単語列が受理されるか否か(1/0で)判定するオートマトン/パーザにより実現されるが,統計モデルの場合は,あまり履歴(確率の条件部分)が長いと組合せが膨大になり統計量の推定が困難になるので,p(w_(i)\|w_(1)…w_(i-1)) を直近のN単語連鎖p(w_(i),\|w_(i-N+1),…w_(i-1)) で近似して用いることが一般的である.これを単語N-gramモデルと呼び,N=2(2単語連鎖)の場合がバイグラム,N=3(3単語連鎖)の場合がトライグラムである. 単語辞書と言語モデルは通常アプリケーションによって規定され,例えば天気案内やホテル検索などのシステムではそれらに特化したものを用意する.汎用的なディクテーション用のモデルは,日本語の大規模なテキストデータベースから構築しているので,それを例えばホテル検索システムにそのまま用いても,固有名詞がカバーされなかったり,言語表現の予測能力が十分でないためにあまり高い性能は期待できない. 文法の記述が難しいような複雑度の大きいタスクにおいては,専用のN-gramモデルを用意するのが望ましい.N-gramモデルを学習するためのツールキットとして,CMU-Cambridge統計言語モデルツールキット(http://mi.eng.cam.ac.uk/^(?)prc14/toolkit.html)やpalmkit(http://palmkit.sourceforge.net/)がある.ただし学習に際しては,アプリケーションで想定されている(あるいは実際に発話された)文のテキストを大量に(数千文以上)収集する必要がある. 5・3 音声認識における音響モデルこれに対して,式(1)のp(X\|W)は単語列Wから音声のパターンXが生起する確率であり,音響的なモデルによるマッチングに基づいて評価が行われる.こちらが通常のパターン認識処理に相当し,パターンの分布を推定したモデルを用いて行われるが,音声認識では時系列を柔軟に扱えるHMM(Hidden Markov Model)が主流になっている. また,このモデル(テンプレート)の単位としては,音素(ローマ字1文字にほぼ相当)を用いることが多い.単語と音素表記(もしくはかな表記)の対応づけは単語辞書で記述する.ここで音素表記は,できるだけ実際の発音に忠実であることが必要である.例えば,「京都」は正書法では「きょうと(kyouto)」と書かれるが,通常は「きょーと(ky o- t o)」のように発声されるので,そのように記述する.格助詞「は」「へ」のようにかなと読みが一致しない場合も要注意である.「日本(にっぽん,にほん)」のように複数の読みをもつ場合は,おのおのを記述する. このようにして,単語列W={w_(1),w_(2)…,w_(k)｝が音素列{m_(1),m_(2)…,m_(l)｝に展開されるので,p(X\|W)は以下のように計算できる. p(X\|W)=Πp(x\|m_(i)) (3) ^(i) ここでp(x\|m_(i))は,通常音素単位の音響的特徴を表現したHMMを入力音声(の一部)xとマッチングすることにより計算する. 音素は連続的に発声されるので,各音素の音響的特徴が前後の音素によって大きく変動する.そのため,前後の音素に応じて別のテンプレートを用意するのがトライフォンモデルである.例えば,先行母音が/i/で後続の母音が/a/の場合の子音/k/はi-k+aのように表記される.ただしこれは,i-k+aの三つ組全体に対するテンプレートではなく,あくまで子音/k/に対するテンプレートである.したがって,「会社(かいしゃ)」という単語に対するトライフォンによる表記は,「k+a k-a+i a-i+sha i-sh+a sh-a」のようになる.トライフォンに対して,前後の音素に依存しないモデルをモノフォンと呼ぶ. 音響的特徴は,話者(性別・年齢層など)や入力環境(パソコンの接話マイク・電話・自動車内など)によっても大きく影響されるので,利用する条件に適合した音響モデルを使用する必要がある.話者については,不特定話者のモデルを利用することもできるが,小児や高齢者は特別なモデルが必要である.入力環境については,ミスマッチが認識性能に重大な影響を与えるので,例えばパソコンと電話と自動車内では全く異なる音響モデルが必要である.ここであげた典型的なものについては,連続音声認識コンソーシアム(http://www.lang.astem.or.jp/CSRC/)の成果物として有償で入手可能である. 自力でHMMを学習するためのツールキットとして,HTK(http://htk.eng.cam.ac.uk/)があるが,音響モデルの構築には,言語モデル以上に学習データの収集が大変であり,またかなりの専門的知識も必要とする. 5・4 デコーダJuliusの動作原理音声認識の過程においては,式(1)をさまざまな単語列Wの仮説について計算し,その中で最も事後確率の高いものを選択する(=最大事後確率原理).前述のように分子のみを考慮し,対数スケールに変換すると以下のように書き換えることができる. _(∧) W=argmax p(W\|X) =argmax p(W)p(X\|W) =argmax{log p(W) + log p(X\|W)} (4) 実際には,式(4)のargmaxの中身の評価関数を以下のように設定することが一般的である. log p(X\|W) + αlog p(W) + β*N (5) ここで,αは言語モデル重み,βは単語挿入ペナルティと呼ばれるパラメータであり,Nは仮説Wに含まれる単語数(単語列の長さ)である. 単語列Wの仮説数は膨大になるので,この評価値(=尤度)の計算を先頭から逐次的に行い,尤度が小さい候補は途中で除外(枝刈り)し,尤度が大きい候補についてのみ次の単語を接続・展開する.この候補を残す範囲(ある時点における仮説数)をビーム幅と呼ぶ.このようにモデルによる予測・尤度計算を行いながら,最尤仮説の探索を行うプログラムがJuliusである. Juliusは2パスの探索アルゴリズムを採用している.すなわち,第1パスで単語バイグラムモデルを用いて粗い照合を行い,その中間結果に対して第2パスで単語トライグラムモデルを適用して,最終的な認識結果を求める.また音響モデルについても,第1パスでは単語間についてはトライフォンを厳密に適用せず,候補を絞った第2パスにおいて正確な尤度を計算する.これにより,全体としての処理時間と使用メモリ量の効率化を図っている.第1パスは入力に対してほぼリアルタイムに処理が進み,いったんその結果を出力するが,実際には第2パスにおいて候補を再評価し,最終的な認識結果を確定する. このJuliusの動作原理を図6にまとめる.図5における信号処理のモジュールもJuliusに含まれている.」(p.43右欄第2行?p.45左欄第35行) 引用文献9図面上記下線部の記載によれば、引用文献9には、「Julianは、フリーで公開されている連続音声認識ソフトであって、音響モデルと言語モデルとを独立に保持し、音響モデルは音素(ローマ字1文字にほぼ相当)や音節(かな1文字に相当)の周波数パターンを保持し、入力音声とマッチングを行うものであり、単語辞書は認識対象の単語の集合とその単語の音素表記とを規定し、言語モデルは、音声とは無関係の単語間の接続関係を規定した、N-gramモデルからなる統計モデルであり、単語辞書の単語の音素表記と音響モデルとに基づくトライフォンをテンプレートとして、入力音声Xをマッチングし、入力音声として入力された確率p(X\|W)の高い単語列Wを特定し、 N-gramモデルからなる言語モデルを適用して、前記単語列Wの言語的な確からしさp(W)に基づいて入力音声の認識結果を出力する、連続音声認識ソフトJulian。」(以下、「引用文献9記載の技術事項」という。)が記載されている。第4 対比本願発明と引用発明1とを対比すると、以下のことがいえる。ア引用発明1は、音声対話システムにおいて、ユーザの要求するタスクを扱う方法であるから、本願発明と同様の「自動アシスタントの動作方法」といい得るものである。イ引用発明1において、システム本体は、Javaで実装され、各ドメインのエキスパートは、Java、Perlで実装され、音声認識エンジンはJulianが用いられることから、引用発明1の「タスクを扱う方法」が、プログラムがコンピュータ上で実行されることによって実現されることは明らかであり、引用発明1は、「プロセッサと、該プロセッサにより実行される命令を格納するメモリとを備える電子デバイス」で行われる方法であるといえる。ウ引用発明1において、ユーザの発話を音声認識する際にテキスト文字列を取得すること、構文解析がなされることは当然であって、これらの処理が「音声認識エンジンとしてJulian」を用い、「ユーザの発話に対する音声認識結果のN-best解」を得る際に行われることは明らかであるから、引用発明1の「音声認識エンジンとしてJulian」を用い、「ユーザの発話に対する音声認識結果のN-best解」を得ることと、本願発明の「ユーザから受け付けた音声入力からテキスト文字列を取得し、前記ユーザと関連する複数の語を含む固定的な長期個人メモリと、前記自動アシスタントとの現在のユーザセッションに関連するデータを含む短期個人メモリとに少なくとも部分的に基づいて前記受信したテキスト文字列を解釈することにより、少なくともひとつの構文解析結果を導出」することとは、いずれも「ユーザから受け付けた音声入力からテキスト文字列を取得し、前記受信したテキスト文字列を解釈することにより、少なくともひとつの構文解析結果を導出」する点で共通する。なお、請求人は、意見書の3-2.において、「引用発明1の『音声認識エンジンとしてJulian』を用い、『ユーザの発話に対する音声認識結果のN-best解』を得ること」は、たかだか「ユーザの発話→N-best解」の処理があることを示すに過ぎず、ユーザから受け付けた音声入力から音声認識を用いてテキスト文字列を取得することであると理解するのが自然であり、「音声入力→テキスト文字列」、「テキスト文字列→構文解析結果」のテキスト文字列を介した二つの処理が存在することは引用文献1には記載も示唆もないと主張している。しかしながら、以下のとおり、引用発明1においても、音声入力からテキスト文字列を介して、構文解析結果を得ていることは技術常識である。ユーザ発話は音響信号であり、音声認識結果のN-best解はテキストであり、N-best解の直前まで音響信号のままではなく、ユーザ発話とN-best解の間のいずれかの段階で音響信号がテキスト化されると考えるのが自然である。具体的に、引用発明1の「音声認識エンジンJulian」について、引用文献1の参考文献として挙げられている引用文献9記載の技術事項によれば、引用発明1において、音声入力から音声認識結果を得る際に、単語辞書に基づいて単語列を得て、単語列から言語モデルに基づいて音声認識結果を得ており、言語モデルは音声とは無関係の単語間の接続関係を規定しているのであるから、単語辞書に基づいて得られた単語列は、テキスト文字列であることは明らかである。また、引用発明1の音声認識エンジンJulianで音声認識結果のN-best解を得る際に、引用文献1の上記キには、「音声認識用文法は,各ドメインの言語理解部で用いた言語理解用文法から自動生成することにより得た.」との記載があり、引用文献9記載の技術事項によれば、Julianは、単語列から言語モデルで規定された単語間の接続関係に基づき確率の高い単語列を認識結果とし、引用文献9の上記カには、「言語モデル」について、「タスクが限定されている場合は,文法的・意味的に正しくないものを除外する(確率0とする)ことにより,認識の候補を絞り込む.」、「単語辞書と言語モデルは通常アプリケーションによって規定され,例えば天気案内やホテル検索などのシステムではそれらに特化したものを用意する.汎用的なディクテーション用のモデルは,日本語の大規模なテキストデータベースから構築しているので,それを例えばホテル検索システムにそのまま用いても,固有名詞がカバーされなかったり,言語表現の予測能力が十分でないためにあまり高い性能は期待できない.」と記載されていることを参酌すると、引用発明1の音声認識エンジンJulianで音声認識結果のN-best解を得る際に、各ドメインにおける言語理解用文法から生成された言語モデルにより、テキスト文字列である単語列から、文法的・意味的に正しくないものを除外して単語列間の接続関係に基づき確率の高い単語列を認識結果としていると解釈できるから、文法的・意味的に正しい単語間の接続関係の絞り込み、すなわち、構文解析が行われることは明らかである。したがって、引用発明1の「音声認識エンジンとしてJulian」を用い、「ユーザの発話に対する音声認識結果のN-best解」を得ることは、音声入力からテキスト文字列を取得し、受信したテキスト文字列から構文解析結果を得ていることであるといえる。エ引用発明1の「シングルドメインの音声対話コンポーネントを統合したマルチドメイン音声対話システム」が扱う「複数のドメイン」の「各ドメイン」において、「ユーザの対話」を「エキスパート」が担当するから、引用発明1の「複数のドメイン」は、本願発明の「前記自動アシスタントによって提供されるサービスの領域をそれぞれが示す複数の所定のドメイン」に相当する。また、引用発明1の「音声認識結果のN-best解」は、上記ウのとおり、「少なくともひとつの構文解析結果」といえるから、引用発明1の「音声認識結果のN-best解の中から、各ドメインごとにスコアを与え、スコアが最も高い結果を解釈したドメインをユーザ要求の対象ドメインとして選択する」ことは、本願発明の「前記自動アシスタントによって提供されるサービスの領域をそれぞれが示す複数の所定のドメインから、前記少なくともひとつの構文解析結果に基づいてドメインを識別」することに相当する。オ引用発明1は、「各ドメインごとにエキスパートが、ユーザ発話に対する言語理解や応答生成などのユーザ発話の処理を行」うものであり、「選択されたドメインのエキスパートは、スロットフィリング型タスク、データベース検索型タスクを行う」から、引用発明1の各ドメインごとのエキスパートは、言語理解に基づいて処理すべきタスクを決定しているといえる。また、引用発明1の「エキスパート」は、タスクを行い、また、「応答生成」を行うのであるから、タスクを行った結果を出力することは自明の事項である。よって、引用発明1の「各ドメインごとにエキスパートが、ユーザ発話に対する言語理解や応答生成などのユーザ発話の処理を行」い、「選択されたドメインのエキスパートは、スロットフィリング型タスク、データベース検索型タスクを行う」ことと、本願発明の「タスク及び当該タスクのための少なくとも1つのパラメータを、少なくとも部分的に前記少なくともひとつの構文解析結果に基づいて識別し、識別された前記タスクを実行し、前記ユーザへ、前記タスクの実行に関連する出力を提供する」こととは、いずれも、「タスクを、少なくとも部分的に前記少なくともひとつの構文解析結果に基づいて識別し、識別された前記タスクを実行し、前記ユーザへ、前記タスクの実行に関連する出力を提供する」点で共通する。以上、ア?オによれば、本願発明と引用発明1とは、次の一致点、相違点を有する。 [一致点] 「自動アシスタントの動作方法であって、プロセッサと、該プロセッサにより実行される命令を格納するメモリとを備える電子デバイスにおいて、ユーザから受け付けた音声入力からテキスト文字列を取得し、前記受信したテキスト文字列を解釈することにより、少なくともひとつの構文解析結果を導出し、前記自動アシスタントによって提供されるサービスの領域をそれぞれが示す複数の所定のドメインから、前記少なくともひとつの構文解析結果に基づいてドメインを識別し、タスクを、少なくとも部分的に前記少なくともひとつの構文解析結果に基づいて識別し、識別された前記タスクを実行し、前記ユーザへ、前記タスクの実行に関連する出力を提供する方法。」である点で一致し、以下の点で相違する。 [相違点] (相違点1) タスクを識別する際に、本願発明では、「当該タスクのための少なくとも1つのパラメータ」が識別されているのに対し、引用発明1では、タスクのためのパラメータの識別が特定されていない点。 (相違点2) 構文解析結果を導出する際の、ユーザから受け付けた音声入力から取得したテキスト文字列の解釈が、本願発明では、「前記ユーザと関連する複数の語を含む固定的な長期個人メモリと、前記自動アシスタントとの現在のユーザセッションに関連するデータを含む短期個人メモリとに少なくとも部分的に基づ」くのに対し、引用発明1では、そのような特定のない点。第5 判断上記(相違点1)、(相違点2)について検討する。 (相違点1)について引用発明1において、行われるタスクは、スロットフィリング型タスク、データベース検索型タスクである。ここで、スロットフィリング型タスクとは、上記の引用文献2記載の技術事項によれば、音声認識結果から、目的のタスク達成のために必要なスロット値を確定するタスクのことであり、スロットフィリング型タスクにおいて、スロット値を確定することは、タスクのためのパラメータを決定することであるといえる。また、データベース検索型タスクとは、上記の引用文献3記載の技術事項によれば、音声認識結果から、検索条件(属性と属性の値)を決定して、データベースの検索を行うタスクであり、データベース検索型タスクにおいて、検索条件(属性と属性の値)を決定することは、タスクのためのパラメータを決定することであるといえる。そうすると、引用発明1において、スロットフィリング型タスクを行うことは、音声認識結果から、目的のタスク達成のためのスロット値、すなわち、パラメータを決定することを含み、また、データベース検索型タスクを行うことは、音声認識結果から、検索条件(属性と属性の値)とを決定する、すなわち、パラメータを決定することを含むから、引用発明1のスロットフィリング型タスク、データベース検索型タスクを行うことにおいて、タスクのためのパラメータが識別されていることは自明な事項であると言え、相違点1は、実質的なものではないか、当業者が容易に想到し得た事項にすぎない。 (相違点2)について引用文献1の上記アには、マルチドメイン音声対話システムのドメイン選択においては、音声認識に誤りがあるとドメンイン選択が誤りとなることが多いと記載されていることから、引用発明1において、音声認識の精度を上げれば、ドメイン選択の誤りが減ることは明らかである。そして、音声認識の精度に関し、上述したとおり、引用文献6には「音声認識において、単語間の統計的な接続確率を表現した統計的言語辞書の連接単語の接続に関する確率を、対話履歴に基づいて一定期間変更させ、変更させた統計的言語辞書に基づいて単語と単語の遷移確率の推定を行い、単語列の推定を行い、また、使用者の癖が履歴で明らかなときには、統計的言語辞書の関連する連接単語の接続に関する確率を変更すること」という技術事項が記載されており、該引用文献6記載の技術事項における「統計的言語辞書」は、連接単語の接続の確率を規定したものであるから、引用文献9の記載を参酌すれば、引用発明1で使用されるJulianの「言語モデル」の「統計的なモデル」に対応し、テキストである単語列の単語と単語の接続に関する確率を規定したものであるところ、引用発明1において、音声認識による精度の高い構文解析結果(引用発明1における「N-best解」)を得るために、引用文献6記載の技術事項を採用して、単語間の統計的な接続確率を表現した統計的言語辞書の単語と単語の遷移確率を、対話履歴と使用者の癖とで変更させることにより、テキスト文字列を解釈し、構文解析結果を導出するように構成することは当業者が容易に想到し得た事項である。ここで、引用文献6記載の技術事項の「対話履歴」は「現在のユーザのセッションに関連するデータ」といえ、対話履歴がメモリに格納されていることは自明の事項であって、このようなメモリは「短期個人メモリ」といえる。また、引用文献6記載の技術事項の「使用者の癖」は、短期間に変化するものではないから、固定的で長期のものであるといえ、「長期個人メモリ」に格納しておくことは当業者が通常行う事項にすぎない。この点、特開2004-355003号公報の段落【0046】,【0060】?【0063】,【0087】?【0089】には、ユーザの連絡先リストなど、すなわち、固定的な長期個人メモリを音声認識の言語モデル(バイグラム言語モデル、トライグラム言語モデル)の単語の確率に提供することが記載されていることからも明らかである。これらのことから、引用発明1において、相違点2に係る構成、すなわち、構文解析結果を導出する際に、ユーザから受け付けた音声入力から取得したテキスト文字列の解釈を、「前記ユーザと関連する複数の語を含む固定的な長期個人メモリと、前記自動アシスタントとの現在のユーザセッションに関連するデータを含む短期個人メモリとに少なくとも部分的に基づ」いて行うことは当業者が容易に想到し得た事項である。 (請求人の主張について) ア請求人は、意見書の3-3.(1)において、引用文献6には、テキスト文字列から構文解析結果を導出することは記載も示唆もないと主張しているが、引用文献6に記載された統計的言語辞書は、単語列間の接続関係を規定するものであるから、引用文献9でいうJulianの「言語モデル」に相当するものであり、テキスト文字列を解釈することにより、構文解析結果を導出するためのものである。イ請求人は、意見書の3-3.(2)において、引用文献1の「これまでのドメイン選択では、各ドメインに対して判別スコアを算出していた。そのため、対話データなどから判別スコアを算出する場合には、ドメインを追加するたびに新たな対話データの収集が必要であるという問題があった。」との記載を根拠に、従来手法にユーザとの対話データに基づく判別を導入することは、引用文献1の記載自体により阻害されていると主張しているが、当該記載は、引用発明1として引用した従来手法がどのようなものであったかを記載したものであって、ドメインを追加する場合に学習データ(対話データの収集)が必要であることを記載したに過ぎず、ドメイン追加後にユーザの対話履歴を考慮することの阻害とはならない。ウ請求人は、意見書の3-3.(3)において、引用文献1は、不特定ユーザが利用することを前提としているから、引用文献1では「前記ユーザと関連する複数の語を含む固定的な長期個人メモリ」を用いることは想定されておらず、そのような長期個人メモリの使用を動機づける記載も示唆もないと主張している。しかしながら、請求人が、引用文献1に記載されたマルチドメイン音声対話システムが、引用文献1のどの記載を根拠に不特定ユーザが利用するものであると主張しているのか不明であり、請求の主張は採用できない。また、仮に、引用文献1のマルチドメイン音声対話システムが不特定ユーザの利用を前提としたものであったとしても、研究成果を個人用コンピュータにおいて特定ユーザの利用に供することは、普通に行われている事項である。 (本願発明の効果について) 以上判断したとおり、本願発明における上記相違点1、2に係る構成は当業者が容易に想到し得たものであり、本願発明の作用効果も、引用文献1?3,6,9に記載された事項から当業者が予測できる範囲のものである。したがって、本願発明は、引用発明1、及び、引用文献2,3,6,9に記載された周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により、特許を受けることができないものである。第6 むすび以上のとおり、本願発明は、引用発明1、及び、引用文献2,3,6,9に記載された周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。よって、結論のとおり審決する。
審理終結日	2017-05-31
結審通知日	2017-06-02
審決日	2017-06-13
出願番号	特願2012-549003(P2012-549003)
審決分類	P 1 8・ 121- WZ (G06F)
最終処分	不成立
前審関与審査官	円子英紀
特許庁審判長	新川圭二
特許庁審判官	高瀬勤山田正文
発明の名称	デジタルアシスタントのためのパーソナライズされたボキャブラリ
代理人	下山治
代理人	永川行光
代理人	高柳司郎
代理人	木村秀二
代理人	大塚康徳
代理人	大塚康弘

プライバシーポリシーセキュリティーポリシー運営会社概要サービスに関しての問い合わせ