【事件の表示】
　特願２０１２−５４９００３「デジタルアシスタントのためのパーソナライズされたボキャブラリ」拒絶査定不服審判事件〔平成２３年　７月２１日国際公開、ＷＯ２０１１／０８８０５３、平成２５年　５月１６日国内公表、特表２０１３−５１７５６６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、２０１１年（平成２３年）１月１１日（パリ条約による優先権主張外国庁受理２０１０年（平成２２年）年１月１８日　米国、２０１１年（平成２３年）１月１０日　米国）を国際出願日とする出願であって、平成２５年１２月１３日付けで拒絶理由が通知され、平成２６年６月２０日付けで手続補正がなされたが、平成２７年２月２５日付けで拒絶査定がなされ、これに対し、同年７月２日に拒絶査定不服の審判が請求された。
　その後、当審において、平成２８年２月１８日付けで拒絶理由を通知し、同年８月２２日付けで手続補正がなされ、同年１０月１８日付けで最後の拒絶理由を通知し、平成２９年４月２１日付けで意見書が提出された。
第２　本願発明
　本願の請求項１〜２２に係る発明は、平成２８年８月２２日付け手続補正書により補正された特許請求の範囲の請求項１〜２２に記載された事項により特定されるものと認められるところ、その請求項１に係る発明（以下、「本願発明」という。）は、以下のとおりのものである。
「自動アシスタントの動作方法であって、
　プロセッサと、該プロセッサにより実行される命令を格納するメモリとを備える電子デバイスにおいて、
　ユーザから受け付けた音声入力からテキスト文字列を取得し、
　前記ユーザと関連する複数の語を含む固定的な長期個人メモリと、前記自動アシスタントとの現在のユーザセッションに関連するデータを含む短期個人メモリとに少なくとも部分的に基づいて前記受信したテキスト文字列を解釈することにより、少なくともひとつの構文解析結果を導出し、
　前記自動アシスタントによって提供されるサービスの領域をそれぞれが示す複数の所定のドメインから、前記少なくともひとつの構文解析結果に基づいてドメインを識別し、
　タスク及び当該タスクのための少なくとも１つのパラメータを、少なくとも部分的に前記少なくともひとつの構文解析結果に基づいて識別し、
　識別された前記タスクを実行し、
　前記ユーザへ、前記タスクの実行に関連する出力を提供する
ことを特徴とする方法。」
第３　引用文献及び引用発明
１　平成２８年１０月１８日付けの拒絶の理由（以下、「当審拒絶理由」という。）に引用した「神田 他、マルチドメイン音声対話システムにおける対話履歴を利用したドメイン選択、情報処理学会論文誌、日本、2007.05.15発行、第48巻,第5号、pp.1980-1989」（以下、「引用文献１」という。）には、次のア〜ケの記載がある。（下線は、注目箇所に当審が付した。以下、同様。）
ア
「１．はじめに
　これまで，飛行機の予約やバス運行情報案内など様々なタスクドメインにおいて音声対話システムが作成されてきた5),10)．これらのシステムの多くは，扱えるドメインが飛行機予約のみ，バス運行情報のみと１種類に限られており，ユーザの多様な要求に十分応えられるものではなかった．そこで本研究では，
シングルドメインの音声対話コンポーネントの統合により，複数のドメインを扱えるシステム（マルチドメイン音声対話システム）を開発した．１つのシステムで複数のドメインを扱うことにより，ユーザの要求が複数のドメインをまたがるような，複雑なタスクも扱える．またドメイン間での履歴の共有により，シングルドメイン個々を利用するよりもスムーズなタスク達成が可能となる．
　
マルチドメイン音声対話システムでは，まずユーザ要求の対象ドメインを推定するドメイン選択処理が不可欠である．音声を扱うシステムでは音声認識誤りが不可避であるため，誤りを含んだ音声認識結果からも正確にドメインを推定できる頑健さが要求される．
自然なユーザ発話からの応答すべきドメインの推定が行われてきた
3),4),11)
．これらの研究では，１発話に対する音声認識結果から得られる情報のみを用いて応答すべきドメインを推定している．このため，音声認識結果が誤りである場合にはドメイン選択も誤りとなることが多い．
　音声認識誤りが生じた場合でも正しいドメインで対話を行うには，それまでの対話の流れも考慮したドメイン選択が必要である．本研究では対話履歴から得られる特徴量を導入することで，音声認識誤りに対してより頑健なドメイン選択を行う．
　また，マルチドメイン音声対話システムでは，シングルドメインのシステムよりも構築にかかる労力が大きい．したがって，新たなドメインの追加や，既存のドメインの改変の容易さ（ドメインの保守性・拡張性）が高いシステムアーキテクチャが望ましい．これはドメイン選択手法においても同様であり，ドメインの変更や追加にも対応できる枠組みが求められる．
　本研究では，マルチドメイン音声対話システムにおいて，対話履歴から得られる特徴量を導入し，音声認識誤りに頑健なドメイン選択を行う手法を提案する．本研究ではドメイン選択問題を，応答すべきドメインが，(I)１つ前の応答を行ったドメイン，
(II)音声認識結果に対する最尤のドメイン
(III)それ以外のドメイン，のどれに該当するかを，対話履歴とユーザ発話から判別する問題ととらえる．対話履歴から得られる特徴量を導入して判別器を構成することにより，音声認識誤りに対してより頑健なドメイン選択が可能となる．また，上記の３クラスは，ドメインが増減しても一様に定義できるため，保守性・拡張性が高い．」（p.1980左欄第1行〜p.1981左欄第30行）
イ
「２．マルチドメイン音声対話システムのアーキテクチャ
　マルチドメイン音声対話システムでは，シングルドメインのシステムよりも複雑なシステム設計が必要となる．各ドメインが密接に関連付けられて設計された場合，あるドメインの改変の影響がシステム全体に及ぶため，ドメイン内部での改変や，新たなドメインの追加が困難となる．そこで，
各ドメインが独立に設計できる分散型
6)
のアーキテクチャが提案されている
このアーキテクチャでは，ドメインごとに独立して記述できる部分と，ドメイン間の依存関係の考慮が必要な部分を切り分ける．後者の部分を最小化することにより，システム設計者は個々のドメインを半独立的に設計でき，各ドメインの改良や追加が容易となる．
　
本研究でもこの流れに立ち，我々が開発した分散型のシステムアーキテクチャ
7)
に基づきシステムを設計した．システムは大きく分けて，各ドメインでの対話を担当するエキスパートと，それらを統括するシステム本体に分かれる（図１）．ユーザ発話の処理（言語理解や応答生成など）は各ドメインごとにエキスパートが行い，システム本体ではどのエキスパートにユーザ発話の処理を任せるかの振り分けを行う．
　
このように分散型のアーキテクチャでは，ユーザ発話の処理は各ドメインを担当するエキスパートに任せてシステム本体は関知しないため，どのドメインにユーザ発話の処理を任せるかという判定が重要となる．本研究ではこれをドメイン選択と呼ぶ．
ウ
「３．ドメイン選択の課題
　分散型アーキテクチャの枠組みのもとでは，ドメインの保守性・拡張性を備えたドメイン選択の設計が必要である．さらに，
ドメイン選択は音声認識誤りに対して頑健でなければならない．
　これまでの多くの手法では，
音声認識結果から各ドメインごとにスコアを与え，そのスコアが最も高いドメインを選択する
ドメインヘのスコアの算出方法が音声認識結果のみに依存しているため，音声認識結果が誤りである場合，ドメイン選択も誤りとなることが多い．
　また，ドメイン選択の際に１つ前の応答を行ったドメインの情報を利用した研究がある．文献6),16)では１つ前の応答を行ったドメインに近いドメインを選択するような制約を設けている．さらに文献8)では，サブゴールが達成されるまでドメイン遷移を行わない．これらの手法では，１つ前の応答を行ったドメインが正しい場合，音声認識誤りや言語理解誤りによって起こる誤ったドメイン遷移を防ぐことができる．しかし，１つ前で推定されたドメインが誤っていた場合，その誤ったドメインを連続して選択してしまう．この問題は，１つ前で推定されたドメインを無条件に信頼しているために生じる．本研究では，１つ前のドメイン推定の信頼性を表現する情報を，ドメインの履歴や状態から得ることにより，この問題を解決する．」（p.1981右欄第23行〜p.1982左欄第17行）
エ
「４．ロバストで拡張性を備えたドメイン選択
　４．１　本研究でのドメイン選択の定義
　本研究ではドメイン選択問題を，応答すべきドメインが，(I)１つ前の応答を行ったドメイン，
(II)音声認識結果に対する最尤のドメイン
選択肢(II)は，ユーザの要求するドメインが変化したときに，音声認識結果に基づきドメイン選択を行う場合に相当する．このように，この枠組みは従来研究でのドメイン選択を包含する．
　音声認識の成否とドメイン選択を分けて考えることで，音声認識結果が誤りである場合でも，１つ前に応答したドメインが正しければ，それを維持できる．この例を図３に示す．ユーザはまずＵ１でレストランに関する発話を行う．次にＵ２でもやはりレストランに関する発話を行ったが，未知語を含む発話であったため，レストランドメインで理解できる音声認識結果が得られなかった．この場合，Ｕ２に対する応答はレストランドメインで行われるべきであるが，従来手法ではＵ２の音声認識結果を受理できた寺社ドメインヘ遷移してしまう（Ｓ２誤）．このような場合でも，選択肢(I)が選択されることで「Ｓ２正」のようにレストランドメインで応答を続けることができる．
　さらに選択肢(III)を定義し判別することで，通常の制御が適切でない場合，つまり，１つ前の応答を行ったドメインや音声認識結果に基づくドメインのエキスパートに制御権を与えるのが適当でない場合を検出できる．これは誤りが連続した場合に相当するが，ドメインは正しいが音声認識が誤りであるのか，ドメインそのものが誤りであるのかの判断が必要な点で，単純に音声認識誤りの連続を検出するよりも難しい問題である．この例を図４に示す．ユーザはＵ１でホテルドメインに関する発話を行おうとしたが，いい淀んだため音声認識誤りが生じ，レストランドメインに遷移してしまった．Ｕ２で再びホテルドメインに関する発話を行ったが，さらに音声認識誤りが生じた．このような場合，Ｕ２に対して選択すべきドメインは，１つ前の応答を行ったドメイン（レストラン）でもなければ，音声認識結果に対するドメイン（バス）でもない．このような状況を検出することで，誤ったドメインでの対話の継続を防止できる．たとえば，図４のＳ２正のように，「［選択肢(I)のドメイン］または［選択肢(II)のドメイン］の情報についてお尋ねですか？」といった確認が生成できる．
　これらの選択肢は，個々のドメインの判別ではなく，ドメイン間の時系列上での相対的な関係を表すため，ドメイン数が増減しても一様に定義できる．そのため，得られた判別器はドメインの数に依存せず利用でき，保守性・拡張性が高いドメイン選択を実現できる．」（p.1982左欄第18行〜p.1983左欄第4行）
オ
「４．２　対話履歴を利用したドメイン選択
　前節で定義したドメイン選択を行うために用いた特徴量について説明する．本研究では，従来用いられてきた，音声認識結果から得られる情報に加えて，対話履歴から得られる特徴量の導入により，ドメイン選択の各選択肢が妥当かどうかを表現した．ここでは，選択肢(I)の妥当性を表す特徴量（図５）と，選択肢(II)の妥当性を表す特徴量（図６）を定義し利用した．選択肢(III)は選択肢(I)と(II)の補集合であるため，選択肢(I)と(II)のいずれでもない場合に選択される．特徴は全部で３２個用意した17)が，ここでは４．３節で有効とされたもののみを列挙している．
　選択肢(I)は，１つ前の応答を行ったドメインが信頼でき，かつドメインを維持すべき場合に選択される．ここで利用した特徴量を図５に示す．本研究では，対話履歴を用いて１つ前の応答を行ったドメインが信頼できるかを表現する．たとえば，あるドメインでの対話中にユーザの肯定応答（「はい」「そうです」など）が多けれぱ，そのドメインが正しい可能性は高いとする(I1)．反対に，あるドメインでの対話中にシステムのスロットの状態に変化が見られなければ，ユーザ要求がそのドメインで処理されておらず，そのドメインが誤りである可能性が高い(I5,I7)．また，
ドメインが信頼できる状況でもタスクの状態によってドメインの遷移しやすさが変化するため，これを特徴量としてタスクの種類に応じて用意した(I
10
)．スロットフィリング型タスク
1)
の場合は，埋まっていないスロットがある状態（タスク途中）と必要なすべてのスロットが埋まっている状態（タスク達成）の２種類とした．また，データベース検索タスクの場合
１)
は，文献18)で定義した２状態「検索条件の指定」と「情報の提示要求」とした．そのほかに，そのドメインを選択した場合の履歴・状態も指標とした．たとえば，そのドメインを選択したときに変化するスロット数が少ない場合は，そのドメインで音声認識結果をうまく処理できないと考えられるため，そのドメイン選択は誤りである可能性が高いとする(I
13
)．また，受理された音声認識結果の事後確率を，音響的・言語的にそのドメインが信頼できるかの指標として利用した(I
14
)．これは従来の研究で用いられていた指標と同様のものである．
　次に，選択肢(II)の妥当性を表す特徴量を図６に示す．ここでも，対話履歴から得られる特徴量を利用した．
ドメイン選択後のタスクの状態や，変化するスロット数などはここでも利用した
カ
「４．３　ドメイン選択で利用する特徴量の選択
　本研究では，４．２節で定義した各特徴量を用いてドメイン選択器を構成した．特徴量の中には判別に悪影響を及ぼすものがあるため，事前に以下の手順により特徴量選択を行った．以下では，ドメイン選択器の学習用対話データと，ドメイン選択精度の評価用対話データが用意されていると仮定している．ただし，今回は対話データが少ないため，クロスバリデーション法を用いて評価を行った．
（１）文献17)で定義した特徴量の集合をＦとする．
（２）Ｆに含まれる特徴量から１つを選択し，（３）〜（４）を行う．これをＦに含まれる特徴量すべてに対して行う．
（３）選択された特徴量をａとし，Ｆからａを取り除きドメイン選択器を学習する．
（４）得られたドメイン選択器を用いてドメイン選択精度を算出する．
（５）特徴量を取り除くことでドメイン選択の精度が向上した（もしくは変化がなかった）場合，最も精度の向上が大きかった特徴量をＦから取り除き，（２）に戻る．
（６）どの特徴量を除いてもドメイン選択精度が悪化するようになった時点で終了する．このときのＦが判別に利用する特徴量集合となる．」（p.1984左欄第9行〜p.1984右欄第2行）
キ
「５．評価実験
５．１　評価用データの収集
　提案手法の評価用データを収集するため，
マルチドメイン音声対話システムを実装した．エキスパートを作成したドメインは，レストランデータベース検索，ホテルデータベース検索，寺社案内，天気案内，バス運行情報案内
10)
の５つである．
システム本体はJavaを用いて実装しているが，各エキスパートはどの言語でも動作するように設計している．実際，レストラン，ホテル，寺社，天気ドメインがJavaで実装されているのに対し，バスドメインはPerlで実装されている．
　
音声認識エンジンはJulian
15)
を用いた．音声認識用文法は，各ドメインの言語理解部で用いた言語理解用文法から自動生成することにより得た．音響モデルにはJuliusディクテーションキット付属
15)
の３０００状態ＰＴＭトライフォンモデルを利用した．
　上記のシステムを用いて，１０名の被験者から対話データを収集した．被験者はまず，音声入力のタイミングに慣れるため簡単なシナリオに基づき１０分ほど練習を行った．その後ドメインを３〜４回変更することを想定したシナリオに基づいて対話を行った．同様の条件で３対話を行った．
　
データ収集時のシステムでは，音声認識結果の10-best解の上位から順に言語理解を行い，最初に言語理解できた発話から得られたドメインを選択した．
　実験により得られた発話は総計２，２０５発話（２２１発話／人，７４発話／対話）で，単語正解率は６３．３％であった．単語正解率が低いのは，文法外，語彙外発話による音声認識誤りが起きたときに，ユーザが同様の発話を繰り返して誤りを増加させる傾向に起因する．また，音声認識率の低い話者ほどタスク達成までの発話数が多くなるため，全体として低い単語正解率となっている．収集したデータには，ユーザ発話の音声認識結果が肯定応答（「はい」など）であったものが２７４発話含まれる．これらに対しては，正解がほぼ「(I)１つ前の応答を行ったドメイン」となるため，以下の評価はこれらを除いた１，９３１発話を対象とした☆．なお肯定発話を含む全２，２０５発話に対する評価も併記している．
　収集したユーザ発話には，
各ターンごとにシステムが応答を行ったドメインを記録し，ユーザ発話の書き起こしをもとに以下に従って正解ラベルを付与した．
（１）ユーザ発話に対する正解ドメインが，１つ前の応答を行ったドメインと同じ場合，ラベル(I)を付与する．
（２）(I)以外の場合で，
ユーザ発話に対する正解ドメインが，音声認識結果のN-best解の中で最も認識スコアの高い結果を解釈できたドメインである場合，ラベル(II)とする．
（３）上記以外の場合にはラベル(III)を付与する．
　今回の対話データに対して学習器Ｃ５．０２）を用いて生成した決定木を図７に示す．生成された決定木のうち最も上位に現れた特徴量は音声認識スコアの差(II8)であった．また，１つ前の応答を行ったドメインでの肯定の回数(I1)や対話における否定の割合(I9)，そのドメインに遷移してから変化したスロット数(I5)など，対話履歴から得られる特徴の多くが上位に現れた．
　この決定木を用いてドメイン選択を行った場合のシステム動作について，図８の対話を例にとり説明する．ここではユーザはＵ１で「明日の気温をお願いします」と発話したが，「パスタをお願いします」と誤認識され，レストランドメインヘ遷移してしまった．このとき，「パスタ」の単語信頼度が低かったため，Ｓ１のようにシステムからユーザヘの確認が行われた13)．これに対しユーザは，「天気をお願いします」と発話したが（Ｕ２），今度は「円福寺をお願いします」と認識されてしまった．このとき，選択肢(I)はレストランドメイン，選択肢(II)は寺社ドメインに対応する．(II)のドメインと(I)のドメインで各々受理した音声認識結果のスコアの差は２６．２であった．また，(II)のドメインで受理した音声認識結果に含まれる単語の信頼度の相加平均は０．６４と小さかった．(I)のドメインに遷移してからのユーザからの確認応答は１つもなく，そのドメインでタスクが達成されたこともなかった．さらに，変化したスロットはまだ１つもない☆ため，変化したスロットの対話における割合は０である．(II)を選択した場合のタスクの状態は「検索条件の指定」であった．これらの特徴量から，図７の決定木をたどると，選択肢(III)「その他のドメイン」が選択される．その結果，誤ったドメインで対話を続けることを防止するための，「レストランまたは寺社についてお尋ねですか？」という確認を行える（Ｓ２）．」（p.1984右欄第3行〜p.1986左欄第8行）
ク
「５．２　ドメイン選択の精度の評価
　以下の２種類の方法で，ドメイン選択を行った場合の誤り数を比較評価した．
　
ベースライン手法：音声認識結果を受理できたドメインのうち，認識スコアが最大のものを選択する．ただし，１つ前の応答を行ったドメインには，認識スコアに値αを加算して比較した．
　本手法：提案するドメイン選択を行う．今回，ドメイン選択器はＣ５．０2)により構成した．
　評価はいずれも発話ごとに行った．また，同一スコアのドメインが複数存在した場合，その中からランダムに１つのドメインを選択して正解判定を行った．
　
ベースライン手法で，αの値を０から１００まで変化させた際のドメイン選択誤りの数を調査した．ここではαの値が大きいほど，１つ前の応答を行ったドメインを維持する制約が大きくなる．α＝０のときは，ドメインを維持する制約をまったく用いず，音声認識結果のみからドメイン選択を行う手法に相当する．
　次に，本手法による評価を示す．表２に全データに対する場合，表３に肯定発話を除いた場合のドメイン選択結果を，それぞれｃｏｎｆｕｓｉｏｎ ｍａｔｒｉｘの形で示す．表中の各項目では，左の数字がベースライン手法，右の数字が本手法によるドメイン選択結果を表す．また，対角線上の項目がドメインが正しく選択された発話数に相当し，それ以外の項目がドメイン選択を誤った発話数に相当する．ここでは被験者ごとにデータを分割した１０−ｆｏｌｄのクロスバリデーションにより評価結果を得た．この評価結果は，決定木のカットオフパラメータを実験的に最適化した場合の値を示している．表２の結果の方が，判別の容易な肯定発話が含まれる分，表３と比べてドメイン選択精度は全体的に３％程度高い．
　以下，表３について詳しく説明する．まず，本手法によりドメイン選択誤りの数が６１８から５１８まで減少し，全体のドメイン選択精度が６８．０％から７３．２％へと５．２％向上した．ドメイン選択誤りの削減率は１６．２％（１００／６１８）である．また，ベースライン手法では選択肢(III)は選ぱれない（表３の３列目）のに対し，本手法では１５８発話を検出している．これは，音声認識結果に対するドメインと１つ前に応答したドメインの両方が誤りである状況の約半分において，回復戦略をとるべき状況を検出できたことを示している．さらに，選択肢(I)では，適合率が０．７４から０．８０に向上し，Ｆ値が０．８０から０．８３に上昇した．また，選択肢(II)では，再現率が０．７５から０．６２へと減少したが，適合率が０．５２から０．６２へと向上し，Ｆ値は０．６１で変わらなかった．このように本手法では，それまでのドメイン選択精度を落とすことなく，従来検出できなかった選択肢(III)を検出している．
　今回の評価実験では，本手法によるドメイン選択精度が７３．２％であり，いまだ２６．８％のドメイン選択誤りが残っている．このうち，選択肢
(II)の判別に関しては，主に音声認識の精度がドメイン選択の精度に影響を与えている．今回の実験では音声認識の単語正解率が６３．３％と低い中での評価であったために，選択肢(II)の判別精度が低くなっていると考えられる．また，実際は選択肢(I)もしくは(II)であるものを，選択肢(III)と誤って判定したものが，１１８発話存在した．ここで，選択肢(III)であるものを選択肢(I)や(II)と誤って選択した場合には，誤ったドメインでそのまま対話が進行してしまうのに対し，本来選択肢(I)や(II)であるものを選択肢
(III)に誤っても，ユーザヘのドメインの確認などのドメイン回復戦略が行われ，誤ったドメインでの対話が進行するわけではない．そのため，これらの誤りが対話に及ぼす悪影響は少ない．」（p.1986左欄第9行〜p.1987左欄第33行）
ケ
「６．まとめ
　本稿ではマルチドメイン音声対話システムにおいて，対話の状態や履歴を用いることで音声認識誤りに対してより頑健にドメインを選択する手法について述べた．被験者１０名による評価実験では，本稿で提案した手法により，従来手法に比ベドメイン選択誤りが１６．２％削減されることを確認した．
　本研究の意義を以下に示す．
・１つ前の応答を行ったドメインと音声認識結果に対する最尤のドメインの両方が適切でない状況を検出する必要性を指摘し，対話から得られる情報を用いることでその検出を可能とした．これまで，音声認識結果からドメインを推定するものや，１つ前の応答を行ったドメインを信頼してそのドメインを維持する研究は行われていたが，音声認識結果から得られるドメインと１つ前のドメインのいずれもが妥当でない状況の存在を指摘した研究事例はない．本研究では，これらの状況を検出することで誤ったドメインでの対話の継続を防止できることを指摘し，ドメインの妥当性を表現する特徴量の導入によりその検出を行った．
・様々な特徴最を用いた，ドメインの保守性・拡張性の高いドメイン選択法を実現した．これまでのドメイン選択では，各ドメインに対して判別スコアを算出していた．そのため，対話データなどから判別スコアを算出する場合には，ドメインを追加するたびに新たな対話データの収集が必要であるという問題があった．これに対し本手法では，ドメイン選択の対象を３クラスに抽象化することにより，ドメインの増減に対応できるドメイン選択法を実現した．
　今後は，選択肢(III)が検出された際の最適なドメイン回復戦略の適用方法が課題となる．また今回の実験では改善が十分ではなかった部分に関して，新たな特徴量の設計などの検討が必要である．」（p.1987左欄第34行〜p.1987右欄第23行）
引用文献１図表  
  
  
　ここで、上記ア〜ケの下線部及び表１の記載によれば、引用文献１には、以下の事項が記載されているといえる。
ａ
　上記アによれば、引用文献１には、
「シングルドメインの音声対話コンポーネントを統合したマルチドメイン音声対話システムにおいて、１つのシステムで複数のドメインを扱うことにより、ユーザの要求が複数のドメインをまたがるような複雑なタスクを扱う方法。」が記載されている。
ｂ
　上記アによれば、上記ａの「マルチドメイン音声対話システム」は、「ユーザの発話に対する音声認識結果を用いてユーザ要求の対象ドメインを推定するドメイン選択」を行うことが記載されている。
ｃ
　上記イによれば、上記ａの「マルチドメイン音声対話システム」は、「各ドメインでの対話を担当するエキスパートと、それらを統括するシステム本体とからなり、各ドメインごとにエキスパートが、ユーザ発話に対する言語理解や応答生成などのユーザ発話の処理を行い、システム本体では、どのドメインを担当するエキスパートにユーザ発話の処理を任せるかを振り分けるドメイン選択を行う」ことが記載されている。
ｄ
　上記ウ、エによれば、上記ｂの「ドメイン選択」は、音声認識結果から各ドメインごとにスコアを与え、スコアが最も高いドメインをドメイン選択するものであり、また、上記キによれば、上記ｂの「ドメイン選択処理」は、音声認識結果のN-best解の中から、認識スコアの高い結果を解釈したドメインを選択するものである。
　したがって、上記ｂの「ドメイン選択」は、「ユーザの発話に対する音声認識結果のN-best解の中から、各ドメインごとにスコアを与え、スコアが最も高い結果を解釈したドメインをユーザ要求の対象ドメインとして選択する」ものである。
ｅ
　上記オ、表１によれば、上記ｃの「各ドメイン」の「エキスパート」は、「スロットフィリング型タスク」、「データベース検索型タスク」を行うものである。
ｆ
　上記キによれば、システム本体はJavaを用いて実装され、各エキスパートはJava,Pealで実装され、音声認識エンジンはJulianが用いられている。
ｇ
　以上ａ〜ｆによれば、引用文献１には、
「シングルドメインの音声対話コンポーネントを統合したマルチドメイン音声対話システムにおいて、１つのシステムで複数のドメインを扱うことにより、ユーザの要求が複数のドメインをまたがるような複雑なタスクを扱う方法であって、
　前記マルチドメイン音声対話システムは、各ドメインでの対話を担当するエキスパートと、それらを統括するシステム本体とからなり、各ドメインごとにエキスパートが、ユーザ発話に対する言語理解や応答生成などのユーザ発話の処理を行い、システム本体では、どのドメインを担当するエキスパートにユーザ発話の処理を任せるかを振り分けるドメイン選択を行い、
　システム本体はJavaを用いて実装され、各エキスパートはJava、Perlで実装され、音声認識エンジンはJulianが用いられ、
　前記ドメイン選択は、ユーザの発話に対する音声認識結果のN-best解の中から、各ドメインごとにスコアを与え、スコアが最も高い結果を解釈したドメインをユーザ要求の対象ドメインとして選択するものであり、
　選択されたドメインのエキスパートは、スロットフィリング型タスク、データベース検索型タスクを行う、
タスクを扱う方法。」（以下、「引用発明１」という。）が開示されている。
ｈ　
　なお、上記「引用発明１」の認定に関して、請求人は、平成２９年４月２１日付け意見書（以下、単に「意見書」という。）の３−１．（４），（５）において、引用文献１に記載された「本研究」または「提案手法」（以下、「本手法」という。）と、上記ｄは、「これまでの多くの手法」（以下、「従来手法」とういう。）とを混ぜ合わせたもので、引用文献１には、本手法と従来手法とを混ぜ合わせることは記載も示唆もされていないので、引用文献１には引用発明１は、記載されていないと主張している。
　しかしながら、上記の引用発明１は、以下に示すとおり、引用文献１に記載された本手法に相当する発明ではなく、引用文献１に記載された従来手法に相当する発明である。
　引用文献１の上記エには、「選択肢(II)は，ユーザの要求するドメインが変化したときに，音声認識結果に基づきドメイン選択を行う場合に相当する．このように，この枠組みは従来研究でのドメイン選択を包含する．」と記載され、上記クには、「ベースライン手法：音声認識結果を受理できたドメインのうち，認識スコアが最大のものを選択する．ただし，１つ前の応答を行ったドメインには，認識スコアに値αを加算して比較した．」、「ベースライン手法で，αの値を０から１００まで変化させた際のドメイン選択誤りの数を調査した．ここではαの値が大きいほど，１つ前の応答を行ったドメインを維持する制約が大きくなる．α＝０のときは，ドメインを維持する制約をまったく用いず，音声認識結果のみからドメイン選択を行う手法に相当する．」と記載されているように、本手法は、「従来研究でのドメイン選択を包含する」ものであり、また、本手法と比較の対象として記載された「ベースライン手法」において、α＝０としたときが、音声認識結果のみからドメイン選択を行う手法、すなわち、従来手法であり、引用発明１のドメイン選択手法である。従って、引用文献１には、従来手法に相当する引用発明１が記載されているといえる。
　さらに、請求人は、意見書の３−１．（６）において、上記ｄの「『ドメイン選択処理』は、音声認識結果のN-best解の中から、認識スコアの高い結果を解釈したドメインを選択するものである。」との認定について、音声認識結果のN-best解は、決定木を学習器により生成するために、被験者から対話データを収集し、収集されたユーザ発話を書き起こして正解ラベルを付与することが記載され、このプロセスは従来手法のドメイン選択とは関係ないので、引用文献１には、音声認識結果のN-best解の中から、認識スコアの高い結果を解釈したドメインを選択することは記載も示唆もされていないと主張している。
　しかしながら、決定木の学習器による生成は、上記「キ」に、「各ターンごとにシステムが応答を行ったドメインを記録し、ユーザ発話の書き起こしをもとに以下に従って正解ラベルを付与した。」と記載されているように、ラベル(I)、ラベル(II)、ラベル(III)を学習する決定木であって、音声認識結果のN-best解を得てドメインを選択することは、評価用データのデータの収集においても、また、実際のドメイン選択の動作においても行われる事項である。
　上記クには、「ベースライン手法：音声認識結果を受理できたドメインのうち、認識スコアが最大のものを選択する。」、「ベースライン手法で、αの値を０から１００まで変化させた際のドメイン選択誤りの数を調査した。ここではαの値が大きいほど、１つ前の応答を行ったドメインを維持する制約が大きくなる。α＝０のときは、ドメインを維持する制約を全く用いず、音声認識結果のみからドメイン選択を行う手法に相当する。」と記載されているから、引用文献１には、ドメインの選択において、「音声認識結果のN-best解の中で最も認識スコアの高い結果を解釈できたドメイン」を選択することが記載されている。
２　当審拒絶理由に引用した「牛田 他、自律的行動決定モデルに基づく対話エンジン、OMRON TECHNICS、日本、2000.03.20発行、第40巻,第1号(通巻133号)、pp.16-21」（以下、「引用文献２」という。）には、次のア〜ウの記載がある。
ア
「２．システム構成
　本研究で用いる音声対話システムの構成を図１に示す。音声対話システムは、音声認識エンジン、対話エンジン、および音声合成エンジンで構成される。
　２．１　音声認識エンジン　ユーザが発話する音声はマイクや電話回線を通してシステムに入力され、
音声認識エンジンが入力された音声を認識
。認識結果は確信度の大きい順にＮ個が出力される。これらＮ個の認識結果をＮベストと呼ぶ。
　２．２　対話エンジン　
対話エンジンはアプリケーションに応じた情報をスロット
6)
を用いて管理する。
情報の検索、登録、予約などにおいて必要なスロット値を取得するタスクを「スロット充足型タスク」と呼ぶ。
　
対話エンジンは、 タスク達成に必要なスロット値を取得していなければ、そのスロット値を取得するための質問文を選択または生成する。質問文は音声合成エンジンを通してシステムからユーザに出力される。質問にユーザが回答すると、対話エンジンは音声認識エンジンから認識結果を受けとり、文脈に応じた解釈を行い、スロット値を確定する。認識エラーが発生したり、曖昧な回答を得た場合など、スロット値を確定できない状況が発生すると、対話エンジンはスロット値を確定するための対話制御を行う。
イ
「はじめに、課題１と３の解決策について説明する。
対話エンジンは、まず、どのスロットを埋めるべきかというシステムの目標を設定する。次に、この目標を達成するために、誘導の発話を出力する。この誘導発話に対して、ユーザが発話を行うと、対話エンジンは認識エンジンからの出力を解釈し、設定した目標が達成されたか否かを評価する。そして、認識結果があいまいであったり、認識エラーが発生するなどして、 目標が達成されない場合には、対話エンジンは改めて目標を設定しなおし、実行すべき目標を決定する。
ウ
「４．１　理解部　音声対話においては、ユーザの発話した意図を理解する必要がある。理解部は、ユーザ発話の認識結果からの意図理解を担う。本研究ではユーザの発話した意図をユーザ発話タイプとして分類する。ユーザ発話タイプを決めるに当たり、スロット充足型のタスクを解析した。その結果、次のユーザ発話タイプを抽出できた。
（ａ）質問に対する回答
（ｂ）確認に対する肯定
（ｃ）確認に対する否定
（ｄ）確認に対する訂正
（ｅ）認識エラー
（ｆ）不確定
（ｇ）ユーザからの要求
　このうち、（ｅ）認識エラーは、音声認識エンジンの機能と、エラーを回復するための誘導を行うという２つの観点で、さらに次の３型に分類される。
（ｅ−１）リジェクト：認識結果の確信度が閾値未満の場合
（ｅ−２）未発話タイムアウト：ユーザが一定時間内に発話しない場合
（ｅ−３）過発話タイムアウト：ユーザが一定時間を越えて発話し続ける場合
　また、（ｆ）不確定は、ユーザ発話において言い間違え、情報の欠落、倒置などが発生することによりスロット値が不確定となる場合である。
　認識結果をスロット値として解釈する処理では、テーブル参照により認識結果に対するスロット値を求める。テーブル参照では、認識エンジンから得るＮ個の認識結果（Ｎベスト）のうち、最も確信度が大きい認識結果を用いるようにした。また、Ｎベストのうち確信度が２位以下の認識結果も残すようにした。２位以下の認識結果を残す理由は次の通りである。確信度が最大の認識結果に対するスロット値を用いてシステムが確認し、ユーザが確認を否定した場合には、システムは質問しなおさなければならない。しかし、質問しなおしても、確信度が最大の認識結果が前回と同じ場合、正しいスロット値を取得できない。このため、確信度が１位の認識結果に対するスロット値が否定された場合には、２位以下の認識結果を用いて確認を行えるように、２位以下の認識結果を残すようにした。
　４．２　評価部　
評価部は対話エンジンが設定した目標が達成されたか否かを評価する。スロット充足型タスクにおける目標はスロット値を取得することである。そこで、評価部は質問したスロット値を取得することができたか、または、確認したスロット値について肯定されたか、ということを評価する。質問したスロット値を取得した場合や、確認したスロット値が肯定された場合には、目標が達成したと評価し、そうでない場合は目標が紛糾したと評価する。
　４．３　対話管理部　課題２の説明で述べたように、音声対話においてタスクに依存するのは、スロットと、それらスロットを充足する順番である。このため、複雑な対話制御は対話エンジンの自律性に任せ、目的タスクに応じたシナリオを与えるだけで対話フローを生成することとした。シナリオには充足すべきスロットの定義と、それらスロットを充足する順番を記すようにした。シナリオの例を図４に示す。図４は航空機の発着予定を問い合わせるのに必要なスロットを充足するためのシナリオの例である。
　対話管理部はシナリオで定義されたスロットを生成し、シナリオの順番にスロットを充足するための命令を作業記憶に出力する。そして、認識結果により取得したスロット値をスロットに入れて確定する。しかし、誤認識の場合もあるので、対話管理部において、確信度の値に応じて、スロット値を確定するか、確定せずに回答を確認するかを決定するようにした。
　４．４　目標設定部　
スロット充足タスクではスロット値を取得して確定しなければならない。このため、目標設定部は対話管理部からの命令にしたがって、スロット値を質問する目標、または、スロット値を確認する目標を設定する。しかし、ユーザの発話によっては認識エラー、誤認識、不確定などの状況が発生して目標が紛糾する場合がある。このため、目標設定部において、質問や確認をやり直すために、目標を再設定する。また、ユーザから操作方法の説明などを要求された場合に、これに応答するための目標を設定するようにした。
　４．５　行動計画部　目標設定部は対話管理部からの命令、目標の紛糾、およびユーザからの要求のそれぞれ状況に対して目標を設定する。１回のユーザ発話から、複数の状況が発生することもある。この場合、目標設定部は複数の目標を設定することになる。しかし、設定されたすべての目標について、システムが一度に質問、確認、説明などを行うと、ユーザの負担が大きくなる。このため、行動計画部において、これら目標の中で優先順位を決めて、発話すべき目標を決定するようにした。
　４．６　行動生成部　発話すべき目標が決定したら、具体的な発話文を選択する必要がある。このため、行動生成部において、目標に対応した発話文を選択するようにする。例えば、出発地を質問する目標に対して、「出発地をどうぞ」という発話文を選択する。しかし、認識エラーが原因で同じ質問を繰り返す場合に、常に同じ発話文を選択するのは、協調的な対話とは言えない。システムは認識エラーから回復するようにユーザを誘導すべきである。例えば、システムの認識できない語旬を発話したことによる認識エラーに対して、例示の語句を発話文に含めて誘導する。また、ユーザの声が小さくて認識できないのであれば、大きな声で発話するように誘導する。このため、行動生成部では、目標に対応した発話文を選択することに加えて、認識エラーの状況に応じて発話文を選択するようにする。」（p.18左欄下から14行〜p.19下から3行）
引用文献２図面  
　以上下線部、特に、上記アの記載によれば、引用文献２には、「スロット充足のタスクでは、対話エンジンが、情報の検索、登録、予約などアプリケーションに応じた情報をスロットを用いて管理し、スロット値を取得するための質問文を選択または生成し、音声認識エンジンからの認識結果を受け取り、文脈に応じた解釈を行い、目的のタスク達成に必要なスロット値を確定すること」（以下、「引用文献２記載の技術事項」という。）が記載されている。
３　当審拒絶理由に引用した「神田 他、データベース検索タスクにおける対話文脈を利用した音声言語理解、情報処理学会論文誌、日本、2006.06.15発行、第47巻,第6号、pp.1802-1811」（以下、「引用文献３」という。）には、次のア，イの記載がある。
ア
「３．データベース検索タスクの対話モデル
　本稿では，表１のような
関係データベース（各エントリは，属性名とその値の組で表され，各データは１つのキー属性を持つ）に対し検索するタスクを扱う．
・タスク達成に必要なスロットがユーザごとに異なる：ユーザによって，予算が重要であったり，場所が重要であったりする．
・ユーザの意図が対話中に変化する：システムからの返答を聞くまで満足できるエントリが存在するかどうかが分からないため，ユーザはしばしば検索された結果を見て要求を変更する．
対象とするデータベース検索タスクでの対話の例を図１に示す．
　対話の各時点での状態が表現されていれば，それを対話文脈的な制約として言語理解に利用することができる．スロットフィリング型タスク（天気案内，バス運行情報案内など）を扱うシステムでは，対話の流れを事前にすべて記述できるため，有限オートマトンによって対話の流れをモデル化し，対話の各時点で明示的に状態が定義できる7),8)．しかしながら，データベース検索タスクでは上記の特性より事前に対話の流れを記述しておくことが不可能であるため，これらとは異なるモデル化を行う必要がある．
　また各システムごとに対話状態を設計すると，それに基づく制約はそのシステム以外では利用できないものとなる．本研究では対象とするデータベースに依存しない制約を得ることを目的としている．そのため発話の棄却や解釈に有用な制約を得ることができ，かつデータベースに依存しない対話状態設計を行った．
　以下では，本稿で提案するデータベース検索タスクのモデルに関する説明を行う．
３．１　対話の進行モデル
　本研究では，上で述べた条件を満たすモデルの１つとして，データベース検索タスクにおける
典型的な対話の進行を，まず希望する検索条件を指定して数件までエントリを絞り込み，その後絞り込んだエントリに関するその他の属性の値を取得するものと想定する．これはレストランデータベースにおいては，はじめに希望する店（エントリ）を絞り込み，その後絞り込んだ店の住所や電話番号など（キー属性以外の属性）を取得することに相当する．
前者を「検索条件の指定」モード，後者を「情報の提示要求」モードとする．本研究ではデータベース検索タスクにおける状態は２つのモードのいずれかに属し，対話はモード間を遷移することで行われるとする（図２）．以下，これを対話の進行モデルと呼ぶ．言語理解部では，各時点で対話がどちらのモードであるかや，その時点でのエントリ数などが，対話状態の表現として利用される
　たとえば図１では，Ｕ１〜Ｕ４が「検索条件の指定」モードにおける発話であり，Ｕ５によって対話の状態は「情報の提示要求」モードに移行している．また，得られた検索結果を吟味した結果ユーザが満足しなかった場合，再び「検索条件の指定」モードに戻ることもある．」（p.1803右欄第13行〜p.1804右欄第10行）
イ
「４．１想定発話パターンとの類似度計算
　
各対話行為ごとに複数用意した想定発話パターンと音声認識結果の類似度を計算する
音声認識結果が文としてどれだけその対話行為らしいかを表す
フードタイプ属性の値に対応している
引用文献３図表  
　以上下線部の記載によれば、引用文献３には、「データベース検索タスクでは、各エントリが、属性名とその値の組で表され、各データは１つのキー属性を持つ関係データベースに対して、検索するタスクを扱い、対話が「検索条件の指定」か、「情報の提示要求」なのかのモードを判定し、検索条件の指定により、属性と属性の値でエントリを絞り込み、情報の提示要求により、絞り込んだエントリに対してキー属性以外の属性を取得すること」（以下、「引用文献３記載の技術事項」という。）が記載されている。
４　当審拒絶理由に引用した特開２００４−３３３８７０号公報（以下、「引用文献６」という。）には、次のア〜ウの記載がある。
ア
「【０００６】
【発明の実施の形態】
はじめに、本発明に関する音声認識技術の一般的事項について説明する。すなわち、音声認識では、入力された音声をＡＤ変換し、その
離散系列ｘに最も適合する言語表現ωを推定する。これらを実現するためには言語表現ωを予測するため、予め言語表現を記述した辞書（以下、言語辞書と記述）が必要となる。従来提案されている手法としては、単語の接続状態をネットワーク構造によって文法を表現したネットワーク文法言語辞書と、単語間の統計的な接続確率を表現した統計的言語辞書が主に提案されている。
【０００７】
ネットワーク文法では、例えば、図１５のように「住所は＜県名＞県」のような入力を許す言語辞書を設計することができる。このとき、システムは「住所は」の発話の後には必ず「＜県名＞」が入力（発話）され、更に「＜県名＞」の後には必ず「県」が入力されることを想定している。ここで、＜県名＞の部分は予め必要な県名を記述しておく必要がある。もちろん県名以下の入力、例えば市区町村等も同様の手法で記述することができる。この手法では、入力可能な語彙とその接続過程を限定することで高い認識性能が得られる。
【０００８】
一方、
統計的言語辞書では、大量のサンプルデータから統計的な手法によって、単語と単語（形態素と形態素）の遷移確率の推定を行う。最も単純で広く用いられている手法がｎ−ｇｒａｍモデルと呼ばれるものである。これは、入力された単語列ω１ω２…ωｎに対する出現確率をＰ（ω１ω２…ωｎ）として言語表現の推定をする場合に、
【０００９】
【数１】  
のような近似を行うモデルである。特に、ｎ＝１の時をｕｎｉ−ｇｒａｍ、ｎ＝２の時をｂｉ−ｇｒａｍ（２−ｇｒａｍ）、ｎ＝３の時をｔｒｉ−ｇｒａｍ（３−ｇｒａｍ）という。図１６ではｂｉ−ｇｒａｍによる言語辞書を用いたときを例にとり、ωｎ−１の入力単語で「奈良」が出現した時、ωｎでの其々の単語列への推移計算を示している。このとき、
【００１０】
【数２】  
のように、直前の単語だけに依存すると考える。ｎ−ｇｒａｍ言語辞書は学習させるサンプルデータが膨大であれば、多くの単語間の接続パターンを自動的に含むことができるため、ネットワーク文法と異なり設計者が想像できなかった言い回しで入力された文法を受理することも可能である。しかし、この統計的言語辞書は自由度が高い反面、特定のタスクに限定した音声認識を行うことは、その認識率の低さに問題があるとされている。
このような問題を解決する一手段として、前記非特許文献２の手法（ＧＡ方式）の提案があり、この手法を用いることにより、認識精度において、ｎ−ｇｒａｍ言語辞書だけを用いた場合と比較して５ｐｔ以上改善している。
イ
「【００１６】
図１の１２０および図２の２２０に示す音声認識手段では、入力された音声信号を認識して、認識結果信号Ｒ１００を送出する。認識結果信号Ｒ１００は、例えばテキストなどの情報形態に変換されている。これは図３の演算装置３３０と例えば図２における記憶手段２７０とによって実現できる。演算装置３３０としては、例えば、一般的なパーソナルコンピュータ、マイクロコンピュータ、信号処理装置としての演算機能を有するシステムを構成するＣＰＵ、ＭＰＵ、ＤＳＰを単数、或いは複数個組み合わせればよく、実時間処理が可能な演算能力を有していることが望ましい。また記憶装置もキャッシュメモリ、メインメモリ、ディスクメモリ、フラッシュメモリ、ＲＯＭ等、一般的な情報処理機器に用いられている情報記憶能力を有する機器を用いればよい。
【００１７】
図１に示す次発話予測手段１３０では、認識された語彙をもとに、次に使用者が発話する内容を予測し、予測された情報を図１に示す確率変更手段１５０に送る。一方、図２に示す次発話予測手段２５０では、図２に示す情報制御手段２３０から得られる情報をもとに、次に使用者が発話する内容を予測し、予測された情報を図２に示す確率変更手段２６０に送る。尚、図１および図２の次発話予測手段１３０および２５０については入力情報信号は異なるが、出力する情報信号は同一である。
【００１８】
図１に示す確率変更手段１５０では、送られてきた次発話予測情報を基に、図１に示す記憶手段１４０に記憶されている統計的言語辞書内に含まれる単語間の文法に関する正答確率を高くする。
【００１９】
図１に示す記憶手段１４０には音声認識に必要な、音素辞書、単語辞書、単語の接続を記述した一つ以上の言語辞書が記憶されており、認識などの演算時に参照される。図２に示す記憶手段２７０では、更に、類語辞書、履歴情報も記録されている。
ウ
「【００２２】
以下、図４を用いて本発明における実施の形態に関する動作の流れについて説明する。
システムが動作を開始すると、はじめにステップＳ１１０において、システムが初期化される。このとき、初期状態として音声認識に必要とされる辞書がメモリ（ＲＡＭ）上に展開されるが、所有している全ての辞書を読込む必要はない。ステップＳ１２０では、入力された音信号が音声かどうかを判断する。音声信号であればステップＳ１３０に進み（Ｙｅｓの場合）、音声でなければ音声が入力されるまで待ち受ける（Ｎｏの場合）。ステップＳ１３０では、
ｎ−１番目に入力された音声を認識して、音声情報に含まれる情報を、例えばテキスト情報のような形式に変換する。
【００２３】
ステップＳ１５０では、ステップＳ１４０で検出された発話状態の変化と予測された次発話をもとに、統計的言語辞書内に存在する予測された次発話の単語間の文法に関する確率を変更する。なお、確率の変更対象については後述する。ステップＳ１６０で次の発話を検出し、次いでステップＳ１７０で、ｎ番目に入力された音声を検出し、音声発話がある場合には（Ｙｅｓの場合）入力された音声をステップＳ１７０において認識して音声情報に含まれる情報を、例えばテキスト情報のような形式に変換する。
ｎ番目発話音声の認識のために適切な状態となっており、ステップＳ１５０を導入しない場合と比較して認識率が向上している。同様にステップＳ１８０では、次発話の予測を行い、次発話の状態変更が検出された場合（Ｙｅｓの場合）はＳ１９０で、統計的言語辞書内に存在する予測された次発話の単語間の文法に関する確率を変更する。
【００２４】
以下、図４のステップＳ１５０における確率の変更方法について述べる。
図５では、図４のステップＳ１４０において、
次発話が住所入力であることが予測できた後の、統計的言語辞書の変更例を示している。図５のネットワーク文法言語辞書には、神奈川、奈良、埼玉とそれに続く県が記述されている。このとき、ネットワーク文法言語辞書における単語の接続である「神奈川−県」「奈良−県」「埼玉−県」を、統計的言語辞書の中から探し、それぞれに割り振られている確率を高くするように変更する。
【００２５】
【数３】  
を計算する。このときα＞１であり、事前に決定しておく。
【００２６】
一方、図６では、
ネットワーク文法言語辞書に含まれる単語と、その単語に接続し得る単語および形態素間の接続確率を向上させる例を示している。ここでは、ネットワーク文法に記述されている単語間の接続と、前記単語に接続し得る形態素と単語の接続確率の何れも変更している。例えば、図６のネットワーク文法言語辞書には、神奈川、奈良、埼玉と、それに続く県が記述されている。このとき、神奈川、奈良、埼玉に接続される可能性のある、統計的言語辞書に含まれる全ての単語の接続確率を変更する。「神奈川」に続く可能性のある単語で統計的言語辞書に含まれるものは、「県」あるいは「の」であるため、Ｐ（県│神奈川）、Ｐ（の│神奈川）の２つの確率を（数３）式を適用して変更する。
尚、確率修整の計算は、音声認識前に統計的言語辞書に対して行なう場合と、音声認識中に、音声認識結果候補として出力された文節に含まれる連接単語とネットワーク文法言語辞書とを比較して、前記連接単語がネットワーク文法言語辞書に存在した場合に計算するような仕組みとの何れを選択しても良い。
【００２７】
以下では、前述のネットワーク文法言語辞書の利用手法について説明する。
本発明に用いる、ネットワーク文法言語辞書について、２つの利用手法が考えられる。一つは、図７に示すような複数個の小規模なネットワーク文法言語辞書を切り替える手法である。例えば、インターネットのホームページ画面のように、表示内容が予測できない場合、図７のように、記憶手段７０１に表示画面が取り込まれた段階で辞書として登録する。このような場合、現在表示されている内容および過去に表示された内容を認識することが望ましいため、複数の小規模なネットワーク文法言語辞書７０２、７０３を記憶手段７０１に読み込むか、あるいは不必要な言語辞書を削除する動作を行う。一度登録された言語辞書は音声認識手段７０４に内蔵のスイッチ制御部７０５の操作で音声認識手段７０４に接続され、一時的に不必要なときはスイッチをＯＦＦに、あるいは当分使用しないと判断される場合は記憶手段７０１から削除する。
【００２８】
もう一方は、図８に示すように、あらかじめ大規模なネットワーク文法言語辞書８０２を記憶手段に有し、必要な情報すなわち予測される次発話に関係しているノードだけを動的に有効にしていく方法である。例えば、カーナビゲーションシステムでは、目的地設定などは必須のタスクである住所、施設などの情報を予め記憶手段８０１に記憶しておくことが望ましい。
すなわち、記憶手段８０１は、
統計的言語辞書８０３と、発話内容を含む一つ以上のネットワーク文法言語辞書８０２と、を記憶しており、確率変更手段８０４は、次発話予測手段８０５によって予測された次発話に適合するネットワーク文法言語辞書８０２内のノードを選択し、前記統計的言語辞書内においてネットワーク文法言語辞書内のノードに含まれる連接単語の遷移確率を高くするように機能する。
また、ネットワーク文法言語辞書は、例えば複数の階層と、複数のノードをもつ木構造を有している。なお、木構造とは、枝を張った木のように、太い幹から順次細かく枝分かれして行く構造、つまり階層の高いものから低いものへ分かれて行く構造を意味する。
【００２９】
以下、図１および図２における次発話予測手段による予測手法について具体例を挙げて説明する。
はじめに、カーナビゲーションシステムで用いられることの多い住所入力のタスクを、本発明と表示装置を組み合わせて実現する例について説明する。カーナビゲーションシステムの住所入力タスクでは、県名、市区町村名、町域名、番地のように、階層構造に情報を並べ、上位階層から情報を音声入力させる手法が一般的である。従来のシステムとしては、階層毎に区切って入力する手法と、上位階層から連続して入力する手法が存在し、入力されるコマンドの情報はネットワーク文法言語辞書として記述されている。
【００３０】
本発明においては、図９に示すように表示装置にネットワーク文法言語辞書を表示させている。これは使用者にネットワーク文法言語辞書内の単語を知らしめることでシステムのコマンドの入力限界を示し、更に、表示された単語入力を促すねらいがある。表示された連接単語は使用者にとって発話しやすい音声コマンドに含まれるため、次発話予測手段では“表示された連接単語”を次発話の可能性があると判断する。図９の表示画面９０１の例では、４つの県名と、カーソル（アンダーバ）が設定されている埼玉県の４つ市（さいたま市、川口市、志木市、川越市）が表示されており、統計的言語辞書内において、前記表示連接単語の接続に関する確率が変更される。
【００３１】
図１０では、図９の表示画面右側のスクロールを動かした場合の変更された連接単語を示す。図９では「さいたま市」、「川口市」、「志木市」、「川越市」が表示画面９０１の市町村名の窓に表示されていたが、図１０では「川越市」、「鴻巣市」、「吹上市」、「春日部市」が表示されている。よって、次発話として予測され、接続に関する確率が変更される連接単語は図１０のように、表示変更後の画面に存在する連接単語となる。
図１１では、表示されている連接単語に加えて表示されている単語に文法的に接続し得る形態素との連接単語を次発話として予測した例を示している。県名の後に続く語彙としては、「神奈川」→「県」の場合と、使用者によって県が省略され「神奈川」→「の」と発話される場合が考えられる。このように、名詞の後に助詞をつけて後置詞句を作成するような、文法的に典型的な単語の接続パターンについては次発話として予測する。このような典型的な文例に関しては、対象言語の品詞接続表および特定単語に対する処理などを記憶手段に保存しておくと効率的に運用できる。同様の発想で、「神奈川」のような地名が表示されている場合は「神奈川」→「に」、「に」→「行く」のように、関連しそうな述語まで含めて連接単語の接続に関する確率を変更しても良い。
図１２では、表示されている単語と、表示されている単語の下位階層に位置する単語を連接単語とみなして、前記連接単語を次発話として予測した例を示している。表示単語である「さいたま市」の下位階層には複数の区名が存在する。よって、「さいたま」→「市」、「市」→「浦和区」、「市」→「大宮区」のように市区名の連接単語を次発話として予測する。
【００３２】
次に、インターネットのホームページ情報の表示で用いられることの多い文節、文章についての次発話予測の例を説明する。
図１３では、４つの文節が表示されており、それぞれに複数の連接単語が含まれている。このような場合、それぞれの連接単語を次発話として予測するのはもちろんのこと、個々の単語と、前記単語から接続される可能性のある単語による連接単語についても次発話として予測する。図１３では、「スカイライン」という単語について、既に表示されている「スカイライン」→「クーペ」の他に、後置詞句をつくる「スカイライン」→「の」などが次発話として予測される。その他にも商品ラインナップ情報などを記憶手段に保存しておけば、「スカイライン」→「セダン」などの情報も次発話として予測できる。
【００３３】
文節、文章を用いた情報は音声ガイダンスとして提示される場合もある。音声ガイダンスによる情報提示では、次発話として予測される語彙を減らすことができる。図１３を例に取ると、４つの文節メニューの内、先頭の、
「新型スカイラインクーペプレゼント」
が音声によって提示された場合、変更する連接単語の例として、
（連接単語群１）「新型」→「スカイライン」、「新型」→「キューブ」、…
（連接単語群２）「スカイライン」→「クーペ」、「スカイライン」→「セダン」、…
（連接単語群３）「クーペ」→「プレゼント」、…
などが考えられる。２番目の、
「ＴＲＹ！コンパクトカーキャンペーン」
が音声によって提示された場合、
（連接単語群４）「ＴＲＹ」→「コンパクト」
（連接単語群５）「コンパクト」→「カー」、「コンパクト」→「な」、…
（連接単語群６）「カー」→「キャンペーン」、「カー」→「ディーラー」、…
などが変更する連接単語の例としてあげられる。この場合、音声提示された順に連接単語の接続に関する確率を変更していき、音声提示が終了して一定時間経過した後、徐々に変更前の確率に戻していく。このように音声ガイダンスと本発明を組み合わせると、次発話予測する連接単語の範囲を狭めることができるため効果的である。
【００３４】
表示、音声などで提示された連接単語の類語も次発話として予測できる。最も簡単な方法は、前記記憶手段に類語辞典を有し、入力された単語の類語を調べ、この単語と置き換えた連接単語を予測値とすることである。図１４は、４つの単語が表示された画面において、「エアコン」に関する類語を前記統計的言語辞書に加え、連接単語を作成して追加した例である。追加される単語は「クーラー」、「空調」、「冷房」であり、エアコンの場合と同様に、連接単語としてそれぞれ、
「クーラー」→「ＯＮ」、「クーラー」→「の」
「空調」→「ＯＮ」、「空調」→「の」
「冷房」→「ＯＮ」、「冷房」→「の」
が次発話として予測されている。また、以上の処理で次発話として予測された単語を文章の主語および述語としての機能を有する単語に限定することにより、処理効率をさらに高めることが出来る。
【００３５】
最後に、音声の入力履歴を用いて次発話を予測する方法について説明する。
音声ガイダンスの例でも述べたように、提示された情報の履歴をもとに、統計的言語辞書内において履歴の増加と共に徐々に連接単語の接続に関する確率を変更していくことは有効である。更なる発展法としては、
１．階層構造の情報において、一度使用者が表示させた階層は一定期間、連接単語の接続に関する確率を変更しつづける、
２．数ターン前に入力された内容に含まれる連接単語は一定期間、連接単語の接続に関する確率を変更しつづける、
３．使用者の癖が履歴で明らかなときには関連する連接単語の接続に関する確率を変更しつづける、
等が考えられる。３について、例えば、
・システム起動時に必ずラジオを設定する、
・特定の時間にラジオをつける、
といった動作が履歴により発見されたとき、操作に関連する連接単語の接続に関する確率を変更することで、使用者にとって使い勝手のよいシステムとなる。
  【００３６】
なお、以上述べた処理において、予測された連接単語が統計的言語辞書に存在しないことが判明した場合、その時点で当該単語を統計的言語辞書に追加すると同時に、連接単語の接続に関する確率を付加する。
上記に述べた例はあくまで発明内容の理解を容易に行なうためであり、発明の範囲は上記に限定されるものではない。
【００３７】
以上述べたように本発明によれば、入力音声に対して文法的制約を低減することなく認識精度を維持し得る移動体用音声認識装置の実現を可能としたのみならず、以下の効果についても実現している。すなわち、
記憶容量の増加を抑えることができたため、装置規模の増大を抑えることができた。
また、計算時間を少なくできたため移動体における実時間処理を可能としている。
このような効果は、認識処理アルゴリズムにおいて複数の階層と木構造を採用し、ネットワーク文法言語辞書の内容を工夫することにより実現し得たものである。
また、使用者に提示する情報とリンクすることで、次発話予測の制度を向上している。
さらに、文節および文章で与えられた情報に対しても、精度の高い次発話予測を可能としている。
このため、使用者による発話自由度も高く出来、その上、統計的言語辞書の語彙を増加させることもなく、また、統計的言語辞書に含まれていない単語が次発話として予測された場合でも、処理を可能とすることができるようになった。」
　上記下線部の記載によれば、引用文献６には、「音声認識において、単語間の統計的な接続確率を表現した統計的言語辞書の連接単語の接続に関する確率を、対話履歴に基づいて一定期間変更させ、変更させた統計的言語辞書に基づいて単語と単語の遷移確率の推定を行い、単語列の推定を行い、また、使用者の癖が履歴で明らかなときには、統計的言語辞書の関連する連接単語の接続に関する確率を変更すること」（以下、「引用文献６記載の技術事項」という。）が記載されている。
５　新たに引用する「河原達也，李晃伸：連続音声認識ソフトウェアJulius，人工知能学会誌，日本，2005.01.01発行，第20巻,第1号，pp.41-49」（以下、「引用文献９」という。）には、次のア〜カの記載がある。
ア
「
Juliusは，ディクテーション（音声入力ワープロのような口述筆記）などの大語彙連続音声認識を主な目的として著者らが開発したフリーソフトウェアである．
Webサイトにおいて，最新・完全版が無償で入手できる．
イ
「（市販の音声認識ソフトと比較して）Juliusの最大の特徴は，汎用性・可搬性である．すなわち，
音響モデルや言語モデルなどのインタフェースが公開されており，それらを置き換えたり，修正したりするのが容易なことである
ウ
「
当初JuliusはＩＰＡのプロジェクトである「日本語ディクテーション基本ソフトウェア」のコアエンジンとして作成された．したがって，ディクテーションで一般的な単語N-gramモデル（Ｎ単語連鎖の統計量に基づくモデル；詳細は５・２節参照）のみを扱う仕様であった．
　
一方，音声対話システムなどタスクが明確な場合は専用の文法を人手で記述するのが一般的である．このような記述文法向けの音声認識エンジンとして，（Juliusと大半のコードを共有した）Julianが作成された．こちらはＩＰＡプロジェクトの後継である連続音声認識コンソーシアム（http://www.lang.astem.or.jp/CSRC/）を通した限定的な配布であったが，２００３年秋にその終了に合わせて，JulianをJuliusのパッケージに統合してフリーで公開することとした．このような経緯から，現在でもＵｎｉｘ版で記述文法用のエンジンの実行形式はJulianという名前になっている．
エ
「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ファイルにそれぞれ記述する．図３に，果物注文タスクにおける想定文を受理するJulian用の文法と語彙ファイルの例を示す．
　これらを付属のコンパイラmkdfa.plを用いてJulianで使用できる形式（.dictおよび.dfa）へ変換する．ここで，vocaファイルに単語の読みを直接音素列で記述する必要があるが，ひらがなを音素列へ変換するスクリプトyomi2voca.plがUnix版パッケージに含まれている．」（p.42右欄第16〜30行）
カ
「５・１　音声認識の基本原理
　図５に連続音声認識の基本原理を示す．ここで，
音響モデルは音素（ローマ字１文字にほぼ相当）や音節（かな１文字に相当）の周波数パターンを保持し，入力音声とマッチングを行うものである．
言語モデルは，単語の連鎖を規定する
　（しばしば誤解されるので）正確にいうと，Juliusは図５においてデコーダと呼ばれているモジュールであり，これは，
与えられた音響モデルや言語モデルを用いて，入力音声Xを単語列Wに認識（デコード）する
Juliusは音響モデルや言語モデルと完全に独立
　次にやや専門的になるが，図５に基づく連続音声認識の原理を確率的な枠組みで説明する．音声認識は，
入力音声Xに対する事後確率p(W|X)が最大となる単語列Wを見つける
　　　　　p(W)*p(X|W)
　p(W|X)=――――――　　　　　　（１）
　　　　　　p(X)
　この分母については，Wの決定に影響しない正規化係数と考えられるので，これを無視することができる．分子については単純なパターン認識（数字の認識など）においては，Wの事前確率p(W)を等しいと仮定することができ，その場合はp(X|W)のみで決定されることになるが，連続音声認識においてはp(W)も大きく関与する．
５・２　音声認識における言語モデル
　式（１）の
p(W)は（音声Xが入力される時点で）ある単語列Wのパターンが生起する確率であり，これは（音声Xとは無関係の）言語的な確からしさ
ディクテーションでは，日本語で使用される単語の統計量や，「私」の次には「は」や「の」がきやすいといった統計量に基づいて確率を推定している．タスクが限定されている場合は，文法的・意味的に正しくないものを除外する（確率0とする）ことにより，認識の候補を絞り込む．
　
単語辞書が語彙（認識対象の単語集合）を規定するのに対して，言語モデルは単語間の接続関係を規定するものであり，単純な単語音声認識はこれがない場合とみなすことができる．
言語モデルの適用は，通常先頭の単語から逐次的に行われ，単語列W={w
1
,w
2
…w
k
｝（w
i
は各単語）
　p(W)=Πp(wi|w1…wi-1)　　　　　　（２）
　　　　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-gramモデルを用意するのが望ましい．N-gramモデルを学習するためのツールキットとして，CMU-Cambridge統計言語モデルツールキット(http://mi.eng.cam.ac.uk/〜prc14/toolkit.html）やpalmkit(http://palmkit.sourceforge.net/)がある．ただし学習に際しては，アプリケーションで想定されている（あるいは実際に発話された）文のテキストを大量に（数千文以上）収集する必要がある．
５・３　音声認識における音響モデル
　これに対して，
式（１）のp(X|W)は単語列Wから音声のパターンXが生起する確率であり，音響的なモデルによるマッチングに基づいて評価が行われる．
　また，この
モデル（テンプレート）の単位としては，音素（ローマ字１文字にほぼ相当）を用いる
単語と音素表記（もしくはかな表記）の対応づけは単語辞書で記述
音素表記は，できるだけ実際の発音に忠実であることが必要である．例えば，「京都」は正書法では「きょうと（kyouto）」と書かれるが，通常は「きょーと（ky o- t o）」のように発声されるので，そのように記述する．
　このようにして，単語列W={w1,w2…,wk｝が音素列{m1,m2…,ml｝に展開されるので，p(X|W)は以下のように計算できる．
　　p(X|W)=Πp(x|mi)　　　　　　（３）
　　　　　　i
ここでp(x|mi)は，通常音素単位の音響的特徴を表現したHMMを入力音声（の一部）xとマッチングすることにより計算する．
　
音素は連続的に発声されるので，各音素の音響的特徴が前後の音素によって大きく変動する．そのため，前後の音素に応じて別のテンプレートを用意するのがトライフォンモデルである．
先行母音が/i/で後続の母音が/a/の場合の子音/k/はi-k+aのように表記される．ただしこれは，i-k+aの三つ組全体に対するテンプレートではなく，あくまで子音/k/に対するテンプレートである．
トライフォン
　音響的特徴は，話者（性別・年齢層など）や入力環境（パソコンの接話マイク・電話・自動車内など）によっても大きく影響されるので，利用する条件に適合した音響モデルを使用する必要がある．話者については，不特定話者のモデルを利用することもできるが，小児や高齢者は特別なモデルが必要である．入力環境については，ミスマッチが認識性能に重大な影響を与えるので，例えばパソコンと電話と自動車内では全く異なる音響モデルが必要である．ここであげた典型的なものについては，連続音声認識コンソーシアム(http://www.lang.astem.or.jp/CSRC/)の成果物として有償で入手可能である．
　自力でHMMを学習するためのツールキットとして，HTK(http://htk.eng.cam.ac.uk/)があるが，音響モデルの構築には，言語モデル以上に学習データの収集が大変であり，またかなりの専門的知識も必要とする．
５・４　デコーダJuliusの動作原理
　
音声認識の過程においては，式（１）をさまざまな単語列Wの仮説について計算し，その中で最も事後確率の高いものを選択する（＝最大事後確率原理）．
　　　∧
　　　W=argmax p(W|X)
　　　　=argmax p(W)*p(X|W)
　　　　=argmax{log p(W) + log p(X|W)}　　 （４）
実際には，式（４）のargmaxの中身の評価関数を以下のように設定することが一般的である．
　　log p(X|W) + αlog p(W) + β*N　　　　（５）
　ここで，αは言語モデル重み，βは単語挿入ペナルティと呼ばれるパラメータであり，Nは仮説Wに含まれる単語数（単語列の長さ）である．
　
単語列Wの仮説数は膨大になるので，この評価値（＝尤度）の計算を先頭から逐次的に行い，尤度が小さい候補は途中で除外（枝刈り）し，尤度が大きい候補についてのみ次の単語を接続・展開する．
モデルによる予測・尤度計算を行いながら，最尤仮説の探索を行うプログラムがJuliusである．
　Juliusは２パスの探索アルゴリズムを採用している．すなわち，第１パスで単語バイグラムモデルを用いて粗い照合を行い，その中間結果に対して第２パスで単語トライグラムモデルを適用して，最終的な認識結果を求める．また音響モデルについても，第１パスでは単語間についてはトライフォンを厳密に適用せず，候補を絞った第２パスにおいて正確な尤度を計算する．これにより，全体としての処理時間と使用メモリ量の効率化を図っている．第１パスは入力に対してほぼリアルタイムに処理が進み，いったんその結果を出力するが，実際には第２パスにおいて候補を再評価し，最終的な認識結果を確定する．
　このJuliusの動作原理を図６にまとめる．図５における信号処理のモジュールもJuliusに含まれている．」（p.43右欄第2行〜p.45左欄第35行）
引用文献９図面  
　上記下線部の記載によれば、引用文献９には、
「Julianは、フリーで公開されている連続音声認識ソフトであって、
音響モデルと言語モデルとを独立に保持し、
音響モデルは音素（ローマ字１文字にほぼ相当）や音節（かな１文字に相当）の周波数パターンを保持し、入力音声とマッチングを行うものであり、
単語辞書は認識対象の単語の集合とその単語の音素表記とを規定し、
言語モデルは、音声とは無関係の単語間の接続関係を規定した、N-gramモデルからなる統計モデルであり、
単語辞書の単語の音素表記と音響モデルとに基づくトライフォンをテンプレートとして、入力音声Xをマッチングし、入力音声として入力された確率p(X|W)の高い単語列Wを特定し、
N-gramモデルからなる言語モデルを適用して、前記単語列Wの言語的な確からしさp(W)に基づいて入力音声の認識結果を出力する、
連続音声認識ソフトJulian。」（以下、「引用文献９記載の技術事項」という。）が記載されている。
第４　対比
　本願発明と引用発明１とを対比すると、以下のことがいえる。
ア
　引用発明１は、音声対話システムにおいて、ユーザの要求するタスクを扱う方法であるから、本願発明と同様の「自動アシスタントの動作方法」といい得るものである。
イ
　引用発明１において、システム本体は、Javaで実装され、各ドメインのエキスパートは、Java、Perlで実装され、音声認識エンジンはJulianが用いられることから、引用発明１の「タスクを扱う方法」が、プログラムがコンピュータ上で実行されることによって実現されることは明らかであり、引用発明１は、「プロセッサと、該プロセッサにより実行される命令を格納するメモリとを備える電子デバイス」で行われる方法であるといえる。
ウ
　引用発明１において、ユーザの発話を音声認識する際にテキスト文字列を取得すること、構文解析がなされることは当然であって、これらの処理が「音声認識エンジンとしてJulian」を用い、「ユーザの発話に対する音声認識結果のN-best解」を得る際に行われることは明らかであるから、引用発明１の「音声認識エンジンとしてJulian」を用い、「ユーザの発話に対する音声認識結果のN-best解」を得ることと、本願発明の「ユーザから受け付けた音声入力からテキスト文字列を取得し、前記ユーザと関連する複数の語を含む固定的な長期個人メモリと、前記自動アシスタントとの現在のユーザセッションに関連するデータを含む短期個人メモリとに少なくとも部分的に基づいて前記受信したテキスト文字列を解釈することにより、少なくともひとつの構文解析結果を導出」することとは、いずれも「ユーザから受け付けた音声入力からテキスト文字列を取得し、前記受信したテキスト文字列を解釈することにより、少なくともひとつの構文解析結果を導出」する点で共通する。
　なお、請求人は、意見書の３−２．において、「引用発明１の『音声認識エンジンとしてJulian』を用い、『ユーザの発話に対する音声認識結果のN-best解』を得ること」は、たかだか「ユーザの発話→N-best解」の処理があることを示すに過ぎず、ユーザから受け付けた音声入力から音声認識を用いてテキスト文字列を取得することであると理解するのが自然であり、「音声入力→テキスト文字列」、「テキスト文字列→構文解析結果」のテキスト文字列を介した二つの処理が存在することは引用文献１には記載も示唆もないと主張している。
　しかしながら、以下のとおり、引用発明１においても、音声入力からテキスト文字列を介して、構文解析結果を得ていることは技術常識である。
　ユーザ発話は音響信号であり、音声認識結果のN-best解はテキストであり、N-best解の直前まで音響信号のままではなく、ユーザ発話とN-best解の間のいずれかの段階で音響信号がテキスト化されると考えるのが自然である。
　具体的に、引用発明１の「音声認識エンジンJulian」について、引用文献１の参考文献として挙げられている引用文献９記載の技術事項によれば、引用発明１において、音声入力から音声認識結果を得る際に、単語辞書に基づいて単語列を得て、単語列から言語モデルに基づいて音声認識結果を得ており、言語モデルは音声とは無関係の単語間の接続関係を規定しているのであるから、単語辞書に基づいて得られた単語列は、テキスト文字列であることは明らかである。
　また、引用発明１の音声認識エンジンJulianで音声認識結果のN-best解を得る際に、引用文献１の上記キには、「
音声認識用文法は，各ドメインの言語理解部で用いた言語理解用文法から自動生成する
単語列から言語モデルで規定された単語間の接続関係に基づき確率の高い単語列を認識結果
タスクが限定されている場合は，文法的・意味的に正しくないものを除外する（確率0とする）ことにより，認識の候補を絞り込む．
言語モデル
通常アプリケーションによって規定され
それらに特化したものを用意する
言語表現の予測能力
　したがって、引用発明１の「音声認識エンジンとしてJulian」を用い、「ユーザの発話に対する音声認識結果のN-best解」を得ることは、音声入力からテキスト文字列を取得し、受信したテキスト文字列から構文解析結果を得ていることであるといえる。
エ
　引用発明１の「シングルドメインの音声対話コンポーネントを統合したマルチドメイン音声対話システム」が扱う「複数のドメイン」の「各ドメイン」において、「ユーザの対話」を「エキスパート」が担当するから、引用発明１の「複数のドメイン」は、本願発明の「前記自動アシスタントによって提供されるサービスの領域をそれぞれが示す複数の所定のドメイン」に相当する。
　また、引用発明１の「音声認識結果のN-best解」は、上記ウのとおり、「少なくともひとつの構文解析結果」といえるから、引用発明１の「音声認識結果のN-best解の中から、各ドメインごとにスコアを与え、スコアが最も高い結果を解釈したドメインをユーザ要求の対象ドメインとして選択する」ことは、本願発明の「前記自動アシスタントによって提供されるサービスの領域をそれぞれが示す複数の所定のドメインから、前記少なくともひとつの構文解析結果に基づいてドメインを識別」することに相当する。
オ
　引用発明１は、「各ドメインごとにエキスパートが、ユーザ発話に対する言語理解や応答生成などのユーザ発話の処理を行」うものであり、「選択されたドメインのエキスパートは、スロットフィリング型タスク、データベース検索型タスクを行う」から、引用発明１の各ドメインごとのエキスパートは、言語理解に基づいて処理すべきタスクを決定しているといえる。
　また、引用発明１の「エキスパート」は、タスクを行い、また、「応答生成」を行うのであるから、タスクを行った結果を出力することは自明の事項である。
　よって、引用発明１の「各ドメインごとにエキスパートが、ユーザ発話に対する言語理解や応答生成などのユーザ発話の処理を行」い、「選択されたドメインのエキスパートは、スロットフィリング型タスク、データベース検索型タスクを行う」ことと、本願発明の「タスク及び当該タスクのための少なくとも１つのパラメータを、少なくとも部分的に前記少なくともひとつの構文解析結果に基づいて識別し、識別された前記タスクを実行し、前記ユーザへ、前記タスクの実行に関連する出力を提供する」こととは、いずれも、「タスクを、少なくとも部分的に前記少なくともひとつの構文解析結果に基づいて識別し、識別された前記タスクを実行し、前記ユーザへ、前記タスクの実行に関連する出力を提供する」点で共通する。
　以上、ア〜オによれば、本願発明と引用発明１とは、次の一致点、相違点を有する。
［一致点］
「自動アシスタントの動作方法であって、
　プロセッサと、該プロセッサにより実行される命令を格納するメモリとを備える電子デバイスにおいて、
　ユーザから受け付けた音声入力からテキスト文字列を取得し、
　前記受信したテキスト文字列を解釈することにより、少なくともひとつの構文解析結果を導出し、
　前記自動アシスタントによって提供されるサービスの領域をそれぞれが示す複数の所定のドメインから、前記少なくともひとつの構文解析結果に基づいてドメインを識別し、
　タスクを、少なくとも部分的に前記少なくともひとつの構文解析結果に基づいて識別し、
　識別された前記タスクを実行し、
　前記ユーザへ、前記タスクの実行に関連する出力を提供する
方法。」である点で一致し、以下の点で相違する。
［相違点］
（相違点１）
　タスクを識別する際に、本願発明では、「当該タスクのための少なくとも１つのパラメータ」が識別されているのに対し、引用発明１では、タスクのためのパラメータの識別が特定されていない点。
（相違点２）
　構文解析結果を導出する際の、ユーザから受け付けた音声入力から取得したテキスト文字列の解釈が、本願発明では、「前記ユーザと関連する複数の語を含む固定的な長期個人メモリと、前記自動アシスタントとの現在のユーザセッションに関連するデータを含む短期個人メモリとに少なくとも部分的に基づ」くのに対し、引用発明１では、そのような特定のない点。
第５　判断
　上記（相違点１）、（相違点２）について検討する。
（相違点１）について
　引用発明１において、行われるタスクは、スロットフィリング型タスク、データベース検索型タスクである。
　ここで、スロットフィリング型タスクとは、上記の引用文献２記載の技術事項によれば、音声認識結果から、目的のタスク達成のために必要なスロット値を確定するタスクのことであり、スロットフィリング型タスクにおいて、スロット値を確定することは、タスクのためのパラメータを決定することであるといえる。
　また、データベース検索型タスクとは、上記の引用文献３記載の技術事項によれば、音声認識結果から、検索条件（属性と属性の値）を決定して、データベースの検索を行うタスクであり、データベース検索型タスクにおいて、検索条件（属性と属性の値）を決定することは、タスクのためのパラメータを決定することであるといえる。
　そうすると、引用発明１において、スロットフィリング型タスクを行うことは、音声認識結果から、目的のタスク達成のためのスロット値、すなわち、パラメータを決定することを含み、また、データベース検索型タスクを行うことは、音声認識結果から、検索条件（属性と属性の値）とを決定する、すなわち、パラメータを決定することを含むから、引用発明１のスロットフィリング型タスク、データベース検索型タスクを行うことにおいて、タスクのためのパラメータが識別されていることは自明な事項であると言え、相違点１は、実質的なものではないか、当業者が容易に想到し得た事項にすぎない。
（相違点２）について
　引用文献１の上記アには、マルチドメイン音声対話システムのドメイン選択においては、音声認識に誤りがあるとドメンイン選択が誤りとなることが多いと記載されていることから、引用発明１において、音声認識の精度を上げれば、ドメイン選択の誤りが減ることは明らかである。
　そして、音声認識の精度に関し、上述したとおり、引用文献６には「音声認識において、単語間の統計的な接続確率を表現した統計的言語辞書の連接単語の接続に関する確率を、対話履歴に基づいて一定期間変更させ、変更させた統計的言語辞書に基づいて単語と単語の遷移確率の推定を行い、単語列の推定を行い、また、使用者の癖が履歴で明らかなときには、統計的言語辞書の関連する連接単語の接続に関する確率を変更すること」という技術事項が記載されており、該引用文献６記載の技術事項における「統計的言語辞書」は、連接単語の接続の確率を規定したものであるから、引用文献９の記載を参酌すれば、引用発明１で使用されるJulianの「言語モデル」の「統計的なモデル」に対応し、テキストである単語列の単語と単語の接続に関する確率を規定したものであるところ、引用発明１において、音声認識による精度の高い構文解析結果（引用発明１における「N-best解」）を得るために、引用文献６記載の技術事項を採用して、単語間の統計的な接続確率を表現した統計的言語辞書の単語と単語の遷移確率を、対話履歴と使用者の癖とで変更させることにより、テキスト文字列を解釈し、構文解析結果を導出するように構成することは当業者が容易に想到し得た事項である。
　ここで、引用文献６記載の技術事項の「対話履歴」は「現在のユーザのセッションに関連するデータ」といえ、対話履歴がメモリに格納されていることは自明の事項であって、このようなメモリは「短期個人メモリ」といえる。
　また、引用文献６記載の技術事項の「使用者の癖」は、短期間に変化するものではないから、固定的で長期のものであるといえ、「長期個人メモリ」に格納しておくことは当業者が通常行う事項にすぎない。この点、特開２００４−３５５００３号公報の段落【００４６】，【００６０】〜【００６３】，【００８７】〜【００８９】には、ユーザの連絡先リストなど、すなわち、固定的な長期個人メモリを音声認識の言語モデル（バイグラム言語モデル、トライグラム言語モデル）の単語の確率に提供することが記載されていることからも明らかである。
　これらのことから、引用発明１において、相違点２に係る構成、すなわち、構文解析結果を導出する際に、ユーザから受け付けた音声入力から取得したテキスト文字列の解釈を、「前記ユーザと関連する複数の語を含む固定的な長期個人メモリと、前記自動アシスタントとの現在のユーザセッションに関連するデータを含む短期個人メモリとに少なくとも部分的に基づ」いて行うことは当業者が容易に想到し得た事項である。
（請求人の主張について）
ア　請求人は、意見書の３−３．（１）において、引用文献６には、テキスト文字列から構文解析結果を導出することは記載も示唆もないと主張しているが、引用文献６に記載された統計的言語辞書は、単語列間の接続関係を規定するものであるから、引用文献９でいうJulianの「言語モデル」に相当するものであり、テキスト文字列を解釈することにより、構文解析結果を導出するためのものである。
イ　請求人は、意見書の３−３．（２）において、引用文献１の「これまでのドメイン選択では、各ドメインに対して判別スコアを算出していた。そのため、対話データなどから判別スコアを算出する場合には、ドメインを追加するたびに新たな対話データの収集が必要であるという問題があった。」との記載を根拠に、従来手法にユーザとの対話データに基づく判別を導入することは、引用文献１の記載自体により阻害されていると主張しているが、当該記載は、引用発明１として引用した従来手法がどのようなものであったかを記載したものであって、ドメインを追加する場合に学習データ（対話データの収集）が必要であることを記載したに過ぎず、ドメイン追加後にユーザの対話履歴を考慮することの阻害とはならない。
ウ　請求人は、意見書の３−３．（３）において、引用文献１は、不特定ユーザが利用することを前提としているから、引用文献１では「前記ユーザと関連する複数の語を含む固定的な長期個人メモリ」を用いることは想定されておらず、そのような長期個人メモリの使用を動機づける記載も示唆もないと主張している。
　しかしながら、請求人が、引用文献１に記載されたマルチドメイン音声対話システムが、引用文献１のどの記載を根拠に不特定ユーザが利用するものであると主張しているのか不明であり、請求の主張は採用できない。また、仮に、引用文献１のマルチドメイン音声対話システムが不特定ユーザの利用を前提としたものであったとしても、研究成果を個人用コンピュータにおいて特定ユーザの利用に供することは、普通に行われている事項である。
（本願発明の効果について）
　以上判断したとおり、本願発明における上記相違点１、２に係る構成は当業者が容易に想到し得たものであり、本願発明の作用効果も、引用文献１〜３，６，９に記載された事項から当業者が予測できる範囲のものである。
　したがって、本願発明は、引用発明１、及び、引用文献２，３，６，９に記載された周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許を受けることができないものである。
第６　むすび
　以上のとおり、本願発明は、引用発明１、及び、引用文献２，３，６，９に記載された周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
　したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。 
　よって、結論のとおり審決する。