JP5835197B2

JP5835197B2 - 情報処理システム

Info

Publication number: JP5835197B2
Application number: JP2012261726A
Authority: JP
Inventors: 淳一西田
Original assignee: Toyota Motor Corp
Current assignee: Toyota Motor Corp
Priority date: 2012-11-29
Filing date: 2012-11-29
Publication date: 2015-12-24
Anticipated expiration: 2032-11-29
Also published as: JP2014106927A

Description

本発明は、音声認識を利用して情報を提供する情報処理システムに関する。

スマートフォンなどの携帯端末が通信する無線通信網の充実に伴って、従来よりも音声認識の精度が向上した音声対話サービスが普及してきた。音声認識の精度が向上したのは、大規模なデータベースを使って言語モデルや音響モデルを解析できるためである（例えば、特許文献１参照。）。特許文献１には、文や単語の意味、概念間の連想関係、知識等を木構造のネットワーク形式で図式化して表し、ノード間を意味関係に基づき矢印で結んだ応答ルールにより検索結果を作成する検索結果分類装置が開示されている。そして、検索結果に応じてノードを追加することで応答ルールを更新し検索精度を向上させることができる。

特開2010-140154号公報

しかしながら、運転者や乗員などのユーザが音声対話サービスを利用する上では運転以外のことに気を取られるディストラクションを考慮する必要がある。音声対話システムが対話データを携帯端末や車載装置に表示させることは、ディストラクションが生じやすいため好ましくない場合がある。例えば、運転中にユーザが表示された対話データを目視して言い直したり発話内容を修正することは困難であり、音声対話システムの恩恵を受けにくい。

この不都合について補足する。音声対話システムは、ユーザからの情報が多くなると相互の関連から検索精度が上がることが期待されたシステムである。例えば、音声対話システムは、ユーザとのやり取りを記録して、会話の流れからユーザの意図に沿った情報提供が可能になる。例えば、ユーザが過去に発した単語を省略しても音声対話システムはそれを記録しているので、ユーザは短いフレーズで意図に沿った情報を取得できる。

しかしながら、このような検索では音声対話システムが間違った認識を行ってもそれを記録してしまうため、ユーザは音声対話システムと最初からやりとりをやり直す必要が生じてしまう。例えば、天気予報や施設検索は(i)位置情報（どのエリアを検索するか）と(ii)検索キーワード（カテゴリの絞り込み）などが必要であるが、誤認識されていなければ(i)(ii)どちらかの情報だけでユーザは意図に沿った情報を取得できる。しかし、誤認識された場合は「名古屋の天気を調べて」「大阪のおいしいラーメン屋を探して」などのように(i)(ii)の全ての情報を含むフレーズを毎回、話す必要がある。

車両においてこのような不都合を解消するには、ディストラクションを抑制して短いフレーズで言い直しや修正が可能であることが望まれる。

本発明は、過去の発話内容を利用して対話データを作成する情報処理システムにおいて、一部を修正する場合に短いフレーズで対話データを提供可能な情報処理システムを提供することを目的とする。

本発明は、ユーザが発話した音声データに対応する対話データを作成する情報処理システムであって、所定のユーザ操作を受け付ける操作受付手段と、前記音声データをテキストデータに変換する音声認識手段と、前記音声認識手段が認識したテキストデータから１つ以上の検索キーを抽出し、予め定められたカテゴリに分類する分類手段と、前記カテゴリに分類される検索キーが不足する場合、検索履歴データに記録されている同じカテゴリの過去の検索キーを読み出して該カテゴリの検索キーに決定する検索キー作成手段と、各カテゴリに分類された検索キーによりデータベースを検索する検索手段と、前記分類手段が分類した検索キーをカテゴリに対応づけて前記検索履歴データとして時系列に記録する検索履歴記録手段と、前記操作受付手段がユーザ操作を受け付けた場合、前記検索キー作成手段が前記検索履歴データから検索キーを読み出す時系列上の位置を変更する参照履歴変更手段と、を有することを特徴とする。

過去の発話内容を利用して対話データを作成する情報処理システムにおいて、一部を修正する場合に短いフレーズで対話データを提供可能な情報処理システムを提供することができる。

本実施形態の音声対話システムの概略的な特徴を説明する図の一例である。音声対話システムのシステム構成図の一例である。音声対話システムの機能ブロック図の一例である。操作部と表示部について詳細に説明する図の一例である。音声データから対話データが作成される流れを模式的に説明する図の一例である。情報データベースの構成例等を説明する図の一例である。個人対話履歴データベースの一例を示す図である。音声対話システムの動作時に表示部に表示される表示例を示す図である。対話データの作成手順の一例を示す図である。音声対話システムの動作時に表示部に表示される表示例を示す図である。戻る操作が行われた場合の個人対話履歴データベースの一例を示す図である。サーバーの処理手順を示すフローチャート図の一例を示す。単体の情報処理装置によって構成した音声対話システムの機能ブロック図の一例である。車載機をスマートフォンとした場合の音声対話システムのシステム構成例を示す図である。

以下、図面を参照して本発明の実施形態について説明する。しかしながら、本発明の技術的範囲が、本実施の形態に限定されるものではない。

図１は、本実施形態の音声対話システムの概略的な特徴を説明する図の一例である。図１の画面例は車載機の表示部が表示した認識結果や回答例であり、吹き出しは車載機のスピーカが出力する回答例である。
図１（ａ）：この画面はユーザの発話を待機する初期画面である。この画面に対しユーザは"大阪の天気は？"というフレーズを話す。
図１（ｂ）：音声対話システムは表示部に認識したテキストデータと検索結果を表示すると共に、スピーカから「今日の大阪の天気は晴れです」と出力する。以下、認識したテキストデータと検索結果を区別せずに単に対話データと称す。なお、表示装置の１行目はユーザが話した検索要素（後述する、地域カテゴリ：地域、検索カテゴリ：天気、日付カテゴリ：指定なし）を示す。３行目以下は検索結果であり、３行目は日付情報（ユーザがフレーズに含めなかったためデフォルトとして「今日」と表示される）、４行目は検索した地域として「大阪」が、５行目は検索カテゴリである天気及び検索結果である「晴れ」がそれぞれ表示されている。２行目の「戻る」については後述する。音声対話システムは、１回の検索毎に、検索番号を付与して対話履歴を記録している（例えば、ここまでの検索を検索番号１とする）。

次に、ユーザが"名古屋は？"というフレーズを話す。このように、本実施形態では、ユーザが検索要素を省略しても、音声対話システムが過去の対話履歴を元に検索に必要な単語を穴埋めして検索を行うことができる。
図１（ｃ）：音声対話システムは「名古屋」が地域なので、天気という単語を対話履歴から穴埋めして検索を実行する。音声対話システムは表示部に対話データを表示すると共に、スピーカから「今日の名古屋の天気は曇りのち雨です」と出力する。音声対話システムは、この対話履歴を検索番号２として記録している。

ここで、ユーザは後述するジョグダイヤルを操作して過去の任意の対話履歴を指定する。これにより、音声対話システムは、今後の検索を、指定した過去の対話履歴以前の対話履歴を用いて行うようになる。換言すると、ユーザは指定した過去の対話履歴よりも新しい対話履歴を無効化して、音声対話システムに検索させることができる。したがって、音声対話システムが音声を誤認識した場合や、一部の検索要素だけを変更したい場合に、ダイヤル操作を行うだけで、それまで同様に短いフレーズで検索することができる。
図１（ｄ）：ユーザがダイヤルを操作したため、ここでは１つ前の対話履歴の地域カテゴリである「大阪」が表示される。ユーザはこの画面に対し"ラーメン屋を探して"というフレーズを話す。
図１（ｅ）：音声対話システムは、検索要素を「大阪」「ラーメン屋」として検索し、対話データを作成する。例えば、表示部はいくつかのラーメン屋の屋号のリスト（無敵、ゆず、大将、三郎）とオススメ度（星のマーク）を表示し、スピーカは「大阪のラーメン屋さんだと「無敵」がお勧めです。」と出力する。２行目の「戻る」には「→大阪」と表示され、対話履歴が過去に戻りその検索要素が「大阪」であることが表示される。

このように、過去の対話履歴の参照範囲を任意に変更できるため、ユーザは短いフレーズで検索でき、また、過去の対話履歴を用いて検索するため検索精度を向上させることができる。

〔構成例〕
図２は、本実施形態の音声対話システム５００のシステム構成図の一例を示す。音声対話システム５００は、ネットワーク３００を介して通信可能なサーバー２００と車載機１００と有している。ネットワーク３００は、主に無線通信部分と有線通信部分とを有しており、無線通信部分は例えば携帯電話網、無線ＬＡＮ網、ＷｉＭＡＸ網などであり、有線通信部分は例えばプロバイダが運営する光ファイバやＡＤＳＬなどで構築されたインターネット又は施設内のＬＡＮである。

図２（ｂ）に示すように、サーバー２００はＣＰＵ、ＲＡＭ、ＲＯＭ、ＨＤＤ（Hard Disk Drive）、ＮＩＣ(Network Interface Card)、入力装置、及び、グラフィック制御部を有する情報処理装置である。ＨＤＤにはＯＳ（Operating System）や後述する機能を提供するプログラムが記憶されており、ＣＰＵはこのプログラムをＲＡＭに展開して実行する。サーバー用のＯＳとしてはWindows（登録商標）サーバー、Linux（登録商標）、Unix（登録商標）などがある。ＮＩＣは例えばイーサネット（登録商標）カードであり、ネットワーク３００に接続するために使用される。通信プロトコルは例えばＴＣＰ／ＩＰ、アプリケーション層のＨＴＴＰｓ、ＨＴＴＰ、ＦＴＰ等を用いることができるが通信プロトコルはどのようなものでもよい。入力装置はサーバー２００の管理者の操作を受け付けるキーボード、マウスなどである。グラフィック制御部はＣＰＵの指示によりディスプレイにＧＵＩ（Graphical User Interface）を表示する（レンダリングする）。

車載機１００は電子制御装置と呼ばれる情報処理装置である。本実施形態の機能は例えばナビゲーションシステムに搭載できる。車載機１００は、マイコン、ＧＮＳＳ（global navigation satellite system）装置、ＣＡＮ（Controller Area Network）などの車載ネットワークの通信装置、各種センサやアクチュエータを接続するＩ／Ｏ、液晶や有機ＥＬなどのディスプレイ、Bluetooth（登録商標）や無線ＬＡＮなど無線通信装置等を有している。

＜車載機＞
図３は、音声対話システム５００の機能ブロック図の一例を示す。車載機１００は、表示部１１、制御部１２、通信制御部１６、及び、入出力インタフェース部１５を有しており、入出力インタフェース部１５にはスピーカ３１、マイク３２、操作部３３及び位置取得部３４が接続されている。また、制御部１２は音声・データ送信部１３と検索結果対話データ受信部１４を有している。制御部１２はさらに対話履歴逆行部１２１と個人対話履歴データベース１２２（以下、データベースをＤＢと記載する）を有している。

スピーカ３１はサーバー２００が作成した対話データを音声として出力する。スピーカ３１はナビゲーションシステムの音声案内やオーディオビジュアル装置のスピーカと兼用することが可能である。また、携帯端末のスピーカを使用してもよい。マイク３２は人間の音声に相当する周波数帯をフィルタリングして集音し、電圧信号又は電流信号に変換して入出力インタフェース部１５に送信する。なお、マイク３２は操作部３３が操作されている間のみ音声を集音する。入出力インタフェース部１５は電圧信号又は電流信号をＡ／Ｄ変換して制御部１２に出力する。制御部１２の音声・データ送信部１３は信号を周波数分析して時系列の周波数スペクトルを作成する。これにより運転者や乗員などのユーザが話したフレーズの音声データが得られる。

通信制御部１６は、例えばＤＣＭ（Data Communication Module）と呼ばれる車両専用の通信装置やユーザが携帯している携帯端末の通信機能である。通信制御部１６は、ＣＤＭＡ、ＧＳＭ（登録商標）、ＨＳＤＰＡ、ＬＴＥ、IEEE802.11a/b/g/n、IEEE 802.16（ＷｉＭＡＸ）などの通信方式によりデータ（音声データ、対話データ）を送受信する。通信制御部１６には通信キャリアからＩＰアドレスが与えられており、予め設定されているか又はユーザが設定したサーバー２００のＩＰアドレスを指定することでサーバー２００に接続し、音声データを送信する。また、通信制御部１６はサーバー２００から対話データを受信して検索結果対話データ受信部１４に出力する。検索結果対話データ受信部１４は対話データを表示部１１に表示させると共に、スピーカ３１から出力させる。

表示部１１は車両に固定されている液晶や有機ＥＬなどのディスプレイである。表示部１１として携帯端末のディスプレイを使用してもよい。位置取得部３４は、ＧＮＳＳ装置の他、基地局からの電波強度で車両の位置情報を取得することができる。この位置情報はユーザが許可することで音声データと共にサーバー２００に送信可能である。操作部３３はディスプレイの周囲、メータパネル、ステアリングなどに配置されたハードキー、ディスプレイと一体のタッチパネルに表示されたソフトキー、又は、音声入力装置（サーバー２００とは別に車載機１００が操作内容を認識する音声入力装置を備えていてもよいし、サーバー２００がフレーズから後述する検索キーだけでなくコマンドを抽出してもよい）などである。

図４は、操作部３３と表示部１１について詳細に説明する図の一例である。表示部１１は、メータパネルの略中央に、ユーザが正面から話しかけるような場所に配置されている。図の例では「お話しください」というメッセージとマイクの絵が表示されており、ユーザがフレーズを話すと表示部１１には対話データが表示される。また、図示するように表示部１１は、車両のＨＤＤに記憶されている音楽データのリストを表示するなど、音声対話システム５００以外のサービスにも適用可能である。

図４の操作部３３はステアリングスイッチの一例であり、中立状態のステアリングホイールの左側に音声認識スイッチ３３３が、右側にジョグダイヤル３３１とメニュー表示部３３２が配置されている。音声認識スイッチ３３３は例えば押しボタン式やレバー式のメカニカルスイッチで、ユーザが押下している間だけマイク３２が音声を集音する。ユーザが手を離すと音声認識スイッチ３３３は付勢力により初期位置（集音しない状態）に戻る。

ジョグダイヤル３３１は、表示部１１の表示内容の変更要求や決定要求をユーザから受け付ける操作受付手段である。ジョグダイヤル３３１は円柱の軸に沿って円柱の表面にほぼ等間隔に凹凸が設けられており、円柱の円周方向に力が作用することで、軸を中心に上下両方に回転可能になっている。ジョグダイヤル３３１はステアリングホイールが中立状態で水平方向に軸を有するように配置されている。また、メニュー表示部３３２は例えばタッチパネル型の液晶表示部で、メニュー（ジョグダイヤル３３１で操作可能なサービスのメニュー）が表示される。ユーザはメニュー表示部３３２を操作して、ジョグダイヤル３３１により操作するサービスを選択する。このサービスには音声対話システム５００や音楽データの再生などがある。

また、ジョグダイヤル３３１は、ユーザがステアリングホイールに対し垂直方向下向きに所定距離（例えば数ｍｍ）押し込むことが可能になっている。ユーザが指を離すとジョグダイヤル３３１は付勢力で元の位置に戻る。押し込み操作にどのような操作を割り当てるかは設計できるが、一例として、ユーザは表示部１１に表示されている検索結果（例えばラーメン屋のリスト）から１つの対象（例えばラーメン屋）を決定（確定）することができる。また、音楽データのリストから再生する音楽データを決定することができる。

なお、ジョグダイヤル３３１とメニュー表示部３３２の配置は一例であって、ジョグダイヤル３３１の上下にメニュー表示部３３２が配置されていてもよいし、ジョグダイヤル３３１はステアリングホイールが中立状態で上下方向に軸を有するように配置されていてもよいし、ユーザのステアリングホイールの把持状態を考慮して、水平又は上下のいずれでもなく斜めに軸を有するように配置されてもよい。

また、ジョグダイヤル３３１の替わりに上下ボタン３３４を配置してもよい。上下ボタン３３４はレバー式でステアリングホイール側の端部を中心に、他方の端部が上下に揺動可能に支持されている。ユーザが上側へ揺動を継続することはジョグダイヤル３３１を上方向に回転させる操作に、下側へ揺動を継続することはジョグダイヤル３３１を下方向に回転させる操作に、それぞれ対応する。ジョグダイヤル３３１の押し込み操作は、例えば上下ボタン３３４の全体を押し込む操作で実現してもよいし、メニュー表示部３３２のタップ（タッチ）などで実現してもよい。

また、ジョグダイヤル３３１又は上下ボタン３３４とメニュー表示部３３２を一体化し、全てをタッチパネルで実装することもできる。この場合、ユーザがメニュー表示部３３２を上方向にスワイプすることはジョグダイヤル３３１を上方向に回転させる操作に、下方向にスワイプすることはジョグダイヤル３３１を下方向に回転させる操作に、それぞれ対応する。ジョグダイヤル３３１の押し込み操作は、例えばタップやダブルタップ、又は、長押しなどで実現できる。

また、ジョグダイヤル３３１又は上下ボタン３３４とメニュー表示部３３２は中立状態のステアリングホイールの左側に配置されてもよい。この場合、音声認識スイッチ３３３は右側に配置されてもよいし、左側に配置されたままでもよい。また、ジョグダイヤル３３１又は上下ボタン３３４とメニュー表示部３３２、及び、音声認識スイッチ３３３が全て右側に配置されてもよい
ユーザが指先でジョグダイヤル３３１を回転させると、表示部１１に表示されるリストが回転方向に応じて切り替わる。表示部１１のリストの切り替え速度はジョグダイヤル３３１の回転速度に連動する。したがって、対話データのリストが表示された状態では、例えばラーメン屋の検索結果が次々と表示され、音楽データの再生のサービスにおいては曲名が次々と表示される。ユーザがジョグダイヤル３３１を押し込めばサービスに応じた処理が実行される。音声対話システムではラーメン屋までの経路を探索してナビ用の画面に表示したり、ラーメン屋の詳細な情報をナビ用の画面に表示する。また、音楽データの再生サービスにおいては選択された曲の再生が始まる。

＜サーバー＞
図３に戻り、サーバー２００は、対話データ生成部２２、音声認識エンジン２３、制御部２４、通信制御部２７、及び、情報ＤＢ２１を有している。情報ＤＢ２１はサーバー２００が有していなくてもよく、ネットワーク上に存在すればよい。また、制御部２４は音声・データ受信部２５と検索結果対話データ送信部２６を有している。音声・データ受信部２５は車載機１００から音声データを受信し、音声認識エンジン２３に音声認識させる。また、検索結果対話データ送信部２６は、対話データ生成部２２が作成した対話データを車載機１００に送信する。

＜音声認識＞
図５は、音声データから対話データが作成される流れを模式的に説明する図の一例である。例えば、"大阪の天気は？"という音声データ（時系列の周波数スペクトル）に対し、音声認識エンジン２３は音響モデルと言語モデルを使用して認識処理を施しテキストデータに変換する。対話データ生成部２２はテキストデータや過去の対話履歴を検索キーにして情報ＤＢ２１を検索して対話データを作成する。

なお、対話データ生成部２２は、単語解析部２２１、単語カテゴリ化部２２２、タスク判定部２２３、検索部２２４、回答作成部２２５、意図推定部２２６、対話履歴生成部２２７、及び、参照履歴変更部２２８を有している。これらについては後述する。

音声認識エンジン２３は以下のような公知の手法で音声認識する。音響モデルは大量の音声コーパスとテキストコーパスの集合である。テキストコーパスはテキストデータと同等のデータで様々なフレーズを集めたものであり、音声コーパスはテキストコーパスが発話された際の音声データ（周波数スペクトル）である。テキストコーパスにより１文字とその文字が発話された時の音素（音声認識に用いる音の単位）の対応が得られる。音は前後の音素により変化するので、３つ程度の文字と３つ程度の音素の組み合わせで音響モデルのデータベースが作成されている。

言語モデルは単語と単語の繋がりを確率で表現したデータベースである。例えば、"名古屋の○○"という音声データを認識する際、音響モデルにより「○○」の文字が推定されるが、似た音素は少なくなく複数の候補が挙げられる場合がある。言語モデルは複数の候補から１つの候補を絞り込むために、「名古屋の」の次に「天気」が繋がる確率、「名古屋の」の次に「ラーメン屋」が繋がる確率、などを記憶している。音声認識エンジン２３は音響モデルによる認識の確度と、言語モデルによる確率を総合して「○○」の文字を確定する。なお、言語モデルはシチュエーション毎に用意したり、シチュエーション毎に確率を変えることで認識精度が向上することが知られている。車載機１００で音声対話システム５００を利用する場合は、車載機１００が音声データと共に車両で移動中であることを通知したり、サーバー２００が位置情報の変化からユーザが車両で移動中であることを検知する。そして、車両による移動中の音響モデルや言語モデルを使用することで認識精度を向上させることができる。

＜検索＞
図５の検索の手順について説明する。まず、対話データ生成部２２の単語解析部２２１はテキストデータを単語に分解する。日本語のように分かち書きでない言語では、分解のために形態素解析や係り受け解析を行うことが多い。分解の前にテキストデータをかな漢字変換しておくことで、分解精度が向上する。なお、形態素解析を用いずに、例えば漢字、カタカナ、数字及び記号などを抽出することで単語に分解してもよい。

単語解析部２２１により、例えば、「名古屋の天気を調べて」というテキストデータは、"名古屋""の""天気""を""調べ""て"という単語に分解される。主に名詞、動詞、形容詞、形容動詞、副詞などを取り出せばよく、 "の" "を" "て"等の助詞や助動詞は破棄してよい。よって、「名古屋」「天気」「調べ」という単語が抽出される。

単語カテゴリ化部２２２は、単語をカテゴリに分類する。カテゴリは予め決まっており、本実施形態では一例として地域カテゴリ、検索カテゴリ、フリーワード（本実施形態では主に日付が入る）カテゴリの３つのカテゴリがある。これらが検索要素となる。単語カテゴリ化部２２２はそれぞれを不図示の辞書で検索することで、「名古屋」は地域カテゴリに、「天気」は検索カテゴリに、「調べ」はカテゴリではない（検索要求）と判定される。検索カテゴリについては図６にて説明する。

図６（ａ）は情報ＤＢ２１の構成例を、図６（ｂ）はカテゴリについて説明する図の一例である。情報ＤＢ２１は、例えば、天気予報ＤＢ２１１Ａ、施設情報ＤＢ２１１Ｂ、機械学習ＤＢ２１２、対話シナリオＤＢ２１３、及び、個人対話履歴ＤＢ２１４を有している。

図６（ｂ）に示すように、検索カテゴリは天気以外に、食事、ＧＳ（ガソリンスタンド）、交通情報、ニュース、株価、ラジオ、音楽データ、電話番号などがある。以下、これらを検索するためのデータベースを「検索ＤＢ２１１」といい、検索ＤＢ２１１は検索カテゴリに応じて用意されるものとする。したがって、検索ＤＢ２１１は多種多様なデータベースを含みうる。なお、電話番号とはユーザが携帯している携帯端末に登録されている友人などの電話番号であり、音楽データも同様である。したがって、検索対象に携帯端末を含めることができ、また、車載機１００のＨＤＤなどを含めることができる。

機械学習ＤＢ２１２は、テキストマイニングするためのデータベースである。テキストマイニングは、単語や各単語が分類されたカテゴリの出現頻度や相関関係を分析して有益な情報を見つける情報処理である。本実施形態の有益な情報とは、ユーザがどのような検索結果を望んでいるかという情報であり、これをタスク判定と称する。タスク判定部２２３は機械学習ＤＢ２１２を参照してカテゴリと単語からタスクを判定する。機械学習ＤＢ２１２は、例えば、地域カテゴリと天気という検索カテゴリの組み合わせを天気予報検索というタスクに紐づける学習結果が登録されている。また、例えば、地域カテゴリとラーメンという単語の組み合わせを食事検索というタスクに紐づける学習結果が登録されている。このほかタスクには、ガソリンスタンド検索、交通情報検索というタスク、ニュース検索というタスク、株価検索というタスク、ラジオ番組検索というタスク、音楽データの検索というタスク、電話番号の検索というタスク等がある。

図６（ｂ）に示すように、検索カテゴリ、地域カテゴリ、フリーワードカテゴリの３つが検索要素となる。フリーワードは日付が入ったり、その他、検索の絞り込みに有効な単語が入る。例えば、検索カテゴリがガソリンスタンドの場合、単価やサービス内容（セルフ式、無人など）、付属施設（商品販売の有無、トイレの有無など）などを含めることができる。検索カテゴリがニュースの場合、海外、経済又は領土などの単語を含めることができる。検索カテゴリが株価の場合、会社名や企業コードを含めることができる。なお、本実施形態では検索要素は３つだが、当然ながら、検索要素は４つ以上でもよい。

意図推定部２２６はフレーズに全ての検索要素が含まれない場合は、デフォルトの検索要素で補う。例えば、ユーザが日付を指定しなかった場合、フリーワードカテゴリにデフォルトの「今日」という単語が設定され、ユーザが地域を指定しなかった場合、地域カテゴリにはデフォルトである現在位置から判断された地域が設定される。これも意図推定の一種である。

また、過去の対話履歴を使用する場合は、検索要素は１つ以上あればよい。過去の対話履歴を使用して検索要素を穴埋めすることも意図推定の一種である。これにより、単語が分類されなかったカテゴリを過去の対話履歴で補うことができ、ユーザは短いフレーズで所望の対話データが得られる。また、フレーズが短いため誤認識も生じにくく高精度な認識が可能である。

検索部２２４は、タスクにより検索ＤＢ２１１を決定し、３つのカテゴリの各単語を検索キーにして検索を実行する。これにより、例えば「今日の大阪地域の天気」を取得できる。なお、ユーザは音声操作で検索対象の検索ＤＢ２１１を直接、指定して検索することもできる。

対話シナリオＤＢ２１３は対話データを作成するためのデータベースである。このデータベースは、例えばタスク毎に予め対話データのテンプレートを有しており、検索結果をテンプレートにあてはめることで対話データを作成できるようになっている。例えば天気予報検索というタスクでは「○○の××の天気は△△です。」というテンプレートが用意されている。回答作成部２２５は、予め設定されている対応関係（○○は日時、××は地域、△△は天気検索結果）に基づき、検索結果で○○、××、△△を、置き換えることで対話データを作成する。

また、食事検索というタスクでは、例えば「××の□□さんだと△△がお勧めです。」というテンプレートが用意されている。□□には「ラーメン屋」などユーザが発話した単語があてはめられ、△△にはお店の検索結果である屋号（店名）があてはめられる。検索カテゴリによっては、複数の検索結果が得られる。例えば、ラーメン屋の屋号のように複数の検索結果がありうる場合、回答作成部２２５は上位のＮ件を取り出し対話データを作成する。取り出し順としては、タスクに関係なく現在位置に近い順、アイウエオ順、などを汎用的に使用できる取り出し順がある。また、お店の検索結果はレビュー数の多い順又は評価の高い順、ニュースの検索結果は発表時刻の新しい順、曲名は再生数の多い順又は少ない順、電話番号は着信の新しい順又は発信の新しい順など、タスクに応じて有効な取り出し順がある。このような取り出し順や何件取り出すか（Ｎ件）はユーザが車載機１００を介してサーバー２００に設定可能である。

＜検索の記録＞
図７は個人対話履歴ＤＢ２１４の一例を示す図である。個人対話履歴ＤＢ２１４は、ユーザ毎に過去の対話履歴が登録されるデータベースである。個人対話履歴ＤＢ２１４は、ユーザのフレーズから解析された「入力」と、対話データに使用された「出力」とに分かれており、それぞれ検索番号が付与されている。検索番号が同じ入力と出力は互いに対応している。入力は「検索カテゴリ」「地域カテゴリ」「日付カテゴリ（フリーワードカテゴリ）」「タスク」のフィールドを、出力は「検索カテゴリ」「地域カテゴリ」「日付カテゴリ（フリーワードカテゴリ）」「検索結果」のフィールドを有している。対話履歴生成部２２７はフレーズの発話から対話データの作成までを１回の検索として、検索番号を１つずつ増やしながら、１レコード（入力と出力）の対話履歴を作成する。このように過去の対話履歴を登録しておくことでカテゴリの穴埋め（意図推定）が可能となり、ユーザは短いフレーズを話すだけで精度のよい検索結果を得ることが可能になっている。

また、図3に示したように、車載機１００は個人対話履歴ＤＢ２１４の複製である個人対話履歴ＤＢ１２２を有する。個人対話履歴ＤＢ１２２は、車載機１００が対話データを受信することで蓄積されていく。個人対話履歴ＤＢ１２２は必ずしも必須ではないが、ユーザがジョグダイヤルで戻る操作した際に表示部１１に過去の対話履歴を応答性よく表示できる。

〔音声対話システムの動作例Ｉ〕
図８は音声対話システム５００の動作時に表示部１１に表示される表示例を、図９は対話データの作成手順の一例を示す図である。また、適宜、図7を参照して説明する。
S1：表示部１１には「お話しください」というメッセージとマイクの絵が表示されている。
S2：ユーザは音声認識スイッチ３３３を押しながら、"大阪の天気は？"というフレーズを話す。
S3：スピーカ３１は「今日の大阪の天気は晴れです。」と出力し、表示部１１の１行目は検索要素として、「地域」と「天気」と表示される。２行目の「戻る」にはユーザが戻る操作を行っていないので、何も記述されない。３行目にはユーザがフレーズに含めなかったため「今日」というデフォルトの日時が記述され、４行目には地域カテゴリで指定された地域の「大阪」が、５行目には検索結果として「晴れ」という天気がそれぞれ表示されている。
S4：ユーザが音声認識スイッチ３３３を押下して"名古屋は？"というフレーズを話す。ここでは名古屋という地域が地域カテゴリに分類される。意図推定部２２６は地域以外の検索要素を対話履歴から取得し、検索部２２４は３つのカテゴリを検索要素として天気を検索する。
S5：同様に、スピーカ３１は「今日の名古屋の天気は曇りのち雨です」と出力し、表示部１１の4行目の地域が「名古屋」に更新され、５行目の天気が「曇りのち晴れ」に更新される。
S6：ユーザは音声認識スイッチ３３３を押下して"ラーメン屋を探して"というフレーズを話す。
S7：ここではラーメン屋という単語が検索カテゴリに分類される。意図推定部２２６は、地域カテゴリは同じであると推定し、検索部２２４は名古屋のラーメン屋を検索する。スピーカ３１は「名古屋のラーメン屋さんだと「大黒」がお勧めです。」と出力し、表示部１１には名古屋のラーメン屋の店名（お店リスト）が３つ表示されている。
S8：ユーザは音声認識スイッチ３３３を押下して"大阪は？"というフレーズを話す。
S9：ここでは大阪という単語が地域カテゴリに分類される。意図推定部２２６は、検索カテゴリは同じであると推定し、検索部２２４は大阪のラーメン屋を検索する。スピーカ３１は「大阪のラーメン屋さんだと「無敵」がお勧めです。」と出力し、表示部１１には大阪のラーメン屋の店名（お店リスト）が３つ表示されている。

図９は図８の対話データの作成時における各データベースの機能を説明している。図９（ａ）はステップS3までの処理に対応し、図９（ｂ）はステップS５までの処理に対応している。

単語のカテゴリ化：単語解析部２２１は"大阪の天気は？"というフレーズを単語に分類し、単語カテゴリ化部２２２は各単語をカテゴリ化する。すなわち、「大阪」を地域カテゴリに、「天気」を検索カテゴリに分類し、日付カテゴリ（フリーワードカテゴリ）に何も分類しない。図７に示すように、検索番号１の入力には、検索カテゴリに「天気」、地域カテゴリに「大阪」が設定される。

タスク判定：タスク判定部２２３は、地域カテゴリと天気という検索カテゴリの組み合わせに基づき機械学習ＤＢ２１２を参照して、天気予報検索というタスクであると判定する。なお、意図推定部２２６は、日付カテゴリには今日というデフォルトの単語を設定する。図７に示すように、検索番号１のタスクには「大阪：天気」が設定される。

検索：検索部２２４は、タスク判定の結果（天気予報検索）に基づき天気予報ＤＢ２１１Ａを参照し、天気予報の検索結果を出力する。検索結果は、地域、日付、結果の３つの情報を有している。

対話データ生成：回答作成部２２５は、対話シナリオＤＢ２１３のテンプレートに検索結果をあてはめて対話データを作成する。したがって、出力される対話データは「今日の大阪の天気は晴れです。」となる。また、図７に示すように、検索番号１の出力には、検索カテゴリに「天気」、地域カテゴリに「大阪」、日付カテゴリに「今日」、検索結果に「晴れ」と設定される。

次にユーザが"名古屋は？"と話した場合について説明する（検索番号２）。
単語のカテゴリ化：単語解析部２２１は"名古屋は？"というフレーズを単語に分類し、単語カテゴリ化部２２２は「名古屋」を地域カテゴリに分類する。図７に示すように、検索番号２の入力では地域カテゴリが「名古屋」になっている。

意図推定：しかしながら、検索カテゴリに分類される単語がないため、このままではタスクを決定できない。このため、意図推定部２２６が個人対話履歴ＤＢ２１４の過去の対話履歴から検索意図を推定する。直前の対話履歴の検索カテゴリは「天気」であるため、意図推定部２２６は天気を知りたいという意図を推定する。以降は1番目の検索と同様にタスク判定、検索、対話データ生成の各プロセスが実行される。

対話履歴生成：対話履歴生成部２２７は検索に使用した単語や検索結果を個人対話履歴ＤＢ２１４に記録する。なお、意図推定された場合、個人対話履歴ＤＢ２１４の入力には推定されたカテゴリが登録されない。このため、図７に示すように、検索番号１，２の日付カテゴリや検索番号２の検索カテゴリが空欄になっている。

次にユーザが"ラーメン屋を探して"と話した場合について説明する（検索番号３）。
単語のカテゴリ化：単語解析部２２１は"ラーメン屋を探して"というフレーズを単語に分類し、単語カテゴリ化部２２２は「ラーメン屋」を検索カテゴリに分類する。

意図推定：フレーズには地域カテゴリに分類される単語がないため、意図推定部２２６が個人対話履歴ＤＢ２１４の過去の対話履歴から検索意図を推定する。ここでは、直前の対話履歴で、単語が分類されなかった地域カテゴリに「名古屋」が設定されているので、意図推定部２２６は名古屋のラーメン屋を知りたいという意図を推定する。図７に示すように、検索番号３の入力には、検索カテゴリに「ラーメン」、地域カテゴリは空欄が設定される。

タスク判定：タスク判定部２２３は、地域カテゴリとラーメン屋（食事）という検索カテゴリの組み合わせに基づき機械学習ＤＢ２１２を参照して、食事検索というタスクであると判定する。なお、日付カテゴリには今日というデフォルトの単語が設定される。図７に示すように、検索番号３の検索タスクには「名古屋：食事」が設定される。

検索：検索部２２４は、タスク判定の結果（ラーメン屋の食事検索）に基づき施設情報ＤＢ２１１Bを参照し食事検索の結果を出力する。

対話データ生成：回答作成部２２５は、対話シナリオＤＢ２１３のテンプレートに検索結果をあてはめて対話データを作成する。したがって、出力される対話データは「名古屋のラーメン屋さんだと「大黒」がお勧めです。」となる。また、図７に示すように、検索番号３の出力には、検索カテゴリに「食事」、地域カテゴリに「名古屋」、検索結果に「ラーメン屋お勧めリスト」が設定される。

次にユーザが"大阪は？"と話した場合について説明する（検索番号４）。
単語のカテゴリ化：単語解析部２２１は"大阪は？"というフレーズを単語に分類し、単語カテゴリ化部２２２は「大阪」を地域カテゴリに分類する。図７に示すように、検索番号４の入力では地域カテゴリが「大阪」になっている。

意図推定：検索カテゴリに分類される単語がないため、意図推定部２２６が個人対話履歴ＤＢ２１４の過去の対話履歴から検索意図を推定する。ここでは、直前の対話履歴の検索カテゴリが「ラーメン」なので、意図推定部２２６は大阪のラーメン屋を知りたいという意図を推定する。これにより、カテゴリ化が行われたことになるので、以降は３番目の検索と同様にタスク判定、検索、対話データ生成の各プロセスが実行される。

〔音声対話システムの動作例II〕
図１０は音声対話システム５００の動作時に表示部１１に表示される表示例を、図１１（ａ）は戻る操作が行われた場合の個人対話履歴ＤＢ２１４の一例を示す。図１０の表示例はS1〜S5までは図７と同様である。
S6：S5で対話データが出力された後、ユーザがジョグダイヤル３３１を上方向に回転させる。操作部３３は、ジョグダイヤル３３１の所定量の回転毎に1回の戻る操作を検出する。対話履歴逆行部１２１は1回の戻る操作毎に、個人対話履歴ＤＢ１２２の対話履歴の最後の出力から直前の出力に遡り、表示部１１に過去の出力を表示させる。この場合、対話履歴逆行部１２１は、検索番号１の検索カテゴリ、地域カテゴリ、日付カテゴリを次々と表示部１１に表示する。ユーザは検索に利用したいカテゴリが表示された時点でジョグダイヤル３３１の操作を停止する。
S7：表示部１１は地域として「大阪」を表示し、また、ユーザの音声データを取得するため「お話しください」と表示する。戻った際の表示部１１の画面は一例であり、ステップS3の画面を表示してもよい。個人対話履歴ＤＢ１２２に記憶されている入力及び出力であれば表示可能である。
S8：ユーザは音声認識スイッチ３３３を押下して"ラーメン屋を探して"と話す。
S9：ここではラーメン屋という単語が検索カテゴリに分類される。参照履歴変更部２２８は個人対話履歴ＤＢ２１４で参照される対話履歴を過去に遡り、意図推定部２２６は地域カテゴリを「大阪」に設定する。検索部２２４は大阪のラーメン屋を検索する。スピーカ３１は「大阪のラーメン屋さんだと「無敵」がお勧めです。」と出力し、表示部１１には、戻る操作が検出されたことと、大阪のラーメン屋の店名（お店リスト）が３つ表示されている。

S9の参照される対話履歴を変更について説明する。ステップS6のように戻る操作が行われた場合、音声・データ送信部１３は戻る操作有りと検索番号１を紐づけS8の音声データと共にサーバー２００に送信する。

図１１（ａ）に示すように、個人対話履歴ＤＢ２１４ではS1〜S5により検索番号１、２のレコードが作成される。検索番号２のレコードが作成された時点で、ユーザが戻る操作を行った。参照履歴変更部２２８は車載機１００から受信した検索番号まで個人対話履歴ＤＢ２１４の参照先を変更する。戻る量はジョグダイヤルの操作量により定まるが、図１１（ａ）では１つの対話履歴分戻ったものとする。ジョグダイヤル３３１の回転量に応じて過去の任意の時点まで遡ることが可能である。

音声対話システムは図１１（ｂ）に示すように、検索番号１の対話履歴を起点に意図推定等の処理を行う。
単語のカテゴリ化：単語解析部２２１は"ラーメン屋を探して"というフレーズを単語に分類し、単語カテゴリ化部２２２は「ラーメン」を検索カテゴリに分類する。図１１（ａ）に示すように、検索番号３の入力では検索カテゴリが「ラーメン」になっている。

意図推定：意図推定部２２６は、検索番号１が送信されたため、検索番号１の対話履歴と「ラーメン」の検索カテゴリから検索意図を推定する。よって、検索番号２の対話履歴は無効化される。検索番号３で単語が分類されていないのは地域カテゴリであるため、意図推定部２２６は検索番号１の地域カテゴリである「大阪」を読み出し、大阪のラーメン屋を知りたいという意図を推定する。これにより、カテゴリ化が行われたことになる。

意図推定部２２６が意図推定に用いるのは遡った対話履歴の直前の対話履歴だけである必要はなく、遡った対話履歴より前の対話履歴であれば意図推定に利用可能である。例えば、遡った対話履歴の直前の対話履歴のカテゴリに単語が登録されていない場合、カテゴリに単語が登録されている対話履歴まで遡る。

意図推定された場合、個人対話履歴ＤＢ２１４の入力には推定されたカテゴリが登録されない。したがって、図１１（ａ）に示すように、検索番号３の入力では地域カテゴリが空欄になっている。

タスク判定：タスク判定部２２３は、地域カテゴリ（大阪）とラーメン屋（食事）という検索カテゴリの組み合わせに基づき機械学習ＤＢ２１２を参照して、食事検索というタスクであると判定する。図１１（ａ）に示すように、検索番号３の検索タスクには「大阪：食事」が設定される。

検索：検索部２２４は、タスク判定の結果（ラーメン屋の食事検索）に基づき施設情報ＤＢ２１１Bを参照し、食事検索の結果を出力する。

対話データ生成：回答作成部２２５は、対話シナリオＤＢ２１３のテンプレートに検索結果をあてはめて対話データを作成する。したがって、出力される対話データは「大阪のラーメン屋さんだと「無敵」がお勧めです。」となる。また、図１１（ａ）に示すように、検索番号３の出力には、検索カテゴリに「食事」、地域カテゴリに「大阪」、検索結果に「ラーメン屋お勧めリスト」が設定される。

このように、音声対話システム５００は、ユーザの戻る操作を検出して、名古屋の天気を調べたが、大阪のラーメン屋を知りたいという意図を推定し、過去の音声認識結果を再利用して検索することがでる。このため、ユーザは短いフレーズで目的の検索を行うことができ、フレーズが長い場合よりも高い認識精度が期待できる。仮に認識ミスがあったり言い間違いがあっても、長いフレーズを全て話す必要がなく検索を行うことができる。また、誤認識されたフレーズの全てを言い直すよりも運転中のディストラクションを低減させることができる。

例えば、ユーザが「大阪の天気は？」と話し、「今日の大阪の天気は晴れです。」と対話データが出力され、さらにユーザが「明日は？」と話したが、音声対話システム５００が「那須郡」と誤認識したとする。すると、音声対話システム５００は「今日の那須郡の天気は晴れです。」と回答する。この場合、ユーザが「明日です」と短いフレーズで検索しても、音声対話システム５００は「明日の那須郡の天気は晴れです。」と回答してしまう。このように従来は、「明日の大阪の天気は？」のようにすべてのフレーズを話さなければならなかったため、再度の誤認識が生じる可能性があった。本実施形態では、ジョグダイヤル３３１で「今日の大阪の天気は晴れです。」の検索まで戻れば、ユーザは「明日は？」と話すだけでよい。

上記の実施例では過去の対話履歴に戻る操作について説明したが、より新しい対話履歴を意図推定の参照範囲とすることも可能である。ユーザはジョグダイヤル３３１を下方向に回転させフレーズを話すことで、意図推定部２２６は新しい方の任意の対話履歴とそれよりも過去の対話履歴から意図推定できる。

〔処理フロー〕
図１２は、サーバー２００の処理手順を示すフローチャート図の一例を示す。
音声・データ受信部２５は音声データを受信し、音声認識エンジン２３がテキストデータに変換する（Ｓ１０）。

次に、単語解析部２２１が単語に分解し、単語カテゴリ化部２２２が単語を各カテゴリに分類する（Ｓ２０）。

次に、対話データ生成部２２は過去の対話履歴があるか否かを判定する（Ｓ３０）。対話履歴がない場合（Ｓ３０のＮｏ）、ユーザが音声対話システム５００を使ったことがないか又は対話履歴を消去したと判断し対話履歴を使用しない。

対話履歴がある場合（Ｓ３０のＹｅｓ）、まず、意図推定部２２６は戻る操作有りが車載機１００から送信されたか否かを判定する（Ｓ４０）。戻る操作有りが送信されない場合（Ｓ４０のＮｏ）、処理はステップＳ６０に進む。

戻る操作有りが送信された場合（Ｓ４０のＹｅｓ）、意図推定部２２６は車載機１００から送信された検索番号まで対話履歴を遡り、その検索番号の対話履歴を読み出す（Ｓ５０）。

次に、意図推定部２２６は、ステップＳ２０で単語が分類されなかったカテゴリを、過去の対話履歴のカテゴリで穴埋めする（Ｓ６０）。戻る操作有りの場合は、遡った検索番号より過去の対話履歴のカテゴリで穴埋めされる。なお、ステップＳ３０でＮｏと判定された場合、単語が分類されないカテゴリはデフォルトの単語（例えば日付カテゴリに「今日」）を設定する。なお、穴埋めには対話履歴以外に操作履歴（例えばジョグダイヤルを操作して決定した複数の検索番号）を用いてもよい。

これでカテゴリが揃うので、タスク判定部２２３は機械学習ＤＢ２１２を参照してタスクを判定する（Ｓ７０）。

次に、検索部２２４はタスクに応じて検索ＤＢ２１１を選択し、各カテゴリの単語を検索キーにして検索する（Ｓ８０）。

回答作成部２２５は、対話シナリオＤＢ２１３のテンプレートに検索結果をあてはめて対話データを作成する（Ｓ９０）。検索結果対話データ送信部２６は対話データを車載機１００に送信する（Ｓ１００）。

〔システムの変形例〕
図２、３ではクライアントサーバ型の音声対話システム５００を例示したが、音声対話システム５００は単体の情報処理装置４００によっても実現できる。

図１３は、単体の情報処理装置によって構成した音声対話システム５００の機能ブロック図の一例である。図３の通信制御部１６、２７が不要になり、音声・データ送信部１３、音声データ受信部２５、検索結果対話データ受信部１４、検索結果対話データ送信部２６は音声・データ取得部４１と検索結果対話データ提供部４２に置き換わる。提供される機能は図３と同様である。情報処理装置４００は、例えばＰＣ（Personal Computer）や車載機１００であるが、スマートフォンやタブレットＰＣでも実現可能である。

また、図３では音声認識エンジン２３と対話データ生成部２２を同じサーバー２００に搭載したが、音声認識エンジン２３と対話データ生成部２２を別々のサーバーに搭載してもよい。また、対話データ生成部２２を車載機１００に搭載し、クラウド上の情報ＤＢ２１を車載機１００から検索する実装も可能である。

このように、本実施形態の音声対話システム５００は図３又は図１３の態様に限られるものではなく、各機能がどの情報処理装置に搭載されるかは任意である。

また、車載機１００は車両に固定されていると説明したが、スマートフォン、携帯電話、又は、タブレットＰＣを車両に持ち込むことで、車載機１００を置き換えることができる。

図１４は車載機１００をスマートフォン６００で置き換えた場合の音声対話システム５００のシステム構成例を示す図である。図１４では、図３の操作部３３以外をスマートフォンで代用する。したがって、表示部１１、音声・データ送信部１３、検索結果対話データ受信部１４、入出力インタフェース部１５、スピーカ３１、マイク３２、及び、位置取得部３４は、それぞれスマートフォン６００のディスプレイ等で代用される。

図３で操作部３３とされたジョグダイヤル３３１、及び、音声認識スイッチ３３３は、ステアリングホイールに搭載されたままである。このため、音声認識スイッチ３３３及びジョグダイヤル３３１とスマートフォンとはBluetooth（登録商標）などの近距離無線通信装置で通信する。このように構成すれば車載機１００にはジョグダイヤル３３１等を搭載すればよいのでコスト増を抑制できる。

１１表示部
１２、２４制御部
１３音声・データ送信部
１４検索結果対話データ受信部
１５入出力インタフェース部
２１情報データベース
２２対話データ生成部
２３音声認識エンジン
２５音声・データ受信部
２６検索結果対話データ送信部
１００車載機
２００サーバー

Claims

ユーザが発話した音声データに対応する対話データを作成する情報処理システムであって、
所定のユーザ操作を受け付ける操作受付手段と、
前記音声データをテキストデータに変換する音声認識手段と、
前記音声認識手段が認識したテキストデータから１つ以上の検索キーを抽出し、予め定められたカテゴリに分類する分類手段と、
前記カテゴリに分類される検索キーが不足する場合、検索履歴データに記録されている同じカテゴリの過去の検索キーを読み出して該カテゴリの検索キーに決定する検索キー作成手段と、
各カテゴリに分類された検索キーによりデータベースを検索する検索手段と、
前記分類手段が分類した検索キーをカテゴリに対応づけて前記検索履歴データとして時系列に記録する検索履歴記録手段と、
前記操作受付手段がユーザ操作を受け付けた場合、前記検索キー作成手段が前記検索履歴データから検索キーを読み出す時系列上の位置を変更する参照履歴変更手段と、
を有することを特徴とする情報処理システム。
前記ユーザ操作には前記操作受付手段の操作量を含み、
前記参照履歴変更手段は、前記操作量が大きいほど、前記検索キー作成手段が検索キーを読み出す前記検索履歴データの前記位置を過去に大きく遡らせる、
ことを特徴とする請求項１記載の情報処理システム。
前記参照履歴変更手段は、前記ユーザ操作に含まれる操作方向に応じて、前記検索キー作成手段が検索キーを読み出す前記検索履歴データの前記位置を過去、又は、現在の前記位置よりも未来に変更する、ことを特徴とする請求項２記載の情報処理システム。
前記カテゴリに分類される検索キーが不足する場合、
前記検索キー作成手段は、前記参照履歴変更手段により変更された前記位置よりも過去の前記検索履歴データにて検索キーが記録されている該カテゴリの検索キーを読み出して、検索キーが分類されなかった前記カテゴリの検索キーに決定する、
ことを特徴とする請求項１〜３いずれか１項記載の情報処理システム。
前記操作受付手段は、ステアリングホイールに配置され軸を中心に回転するダイヤル型の操作部材であり、回転方向及び回転量を受け付ける、
ことを特徴とする請求項１〜４いずれか１項記載の情報処理システム。
音声データを送信する車載端末と、前記音声データに応答する対話データを前記車載端末に送信するサーバーとを有する情報処理システムであって、
前記車載端末は、所定のユーザ操作を受け付ける操作受付手段と、
ユーザが発話した前記音声データとユーザ操作情報を前記サーバーに送信する音声データ送信手段と、
前記対話データを受信する対話データ受信手段と、を有し、
前記サーバーは、前記音声データと前記ユーザ操作情報を受信する音声データ受信手段と、
前記音声データをテキストデータに変換する音声認識手段と、
前記音声認識手段が認識したテキストデータから１つ以上の検索キーを抽出し、予め定められたカテゴリに分類する分類手段と、
前記カテゴリに分類される検索キーが不足する場合、検索履歴データに記録されている同じカテゴリの過去の検索キーを読み出して該カテゴリの検索キーに決定する検索キー作成手段と、
各カテゴリに分類された検索キーによりデータベースを検索する検索手段と、
前記分類手段が分類した検索キーをカテゴリに対応づけて前記検索履歴データとして時系列に記録する検索履歴記録手段と、
前記ユーザ操作情報を受信した場合、前記検索キー作成手段が前記検索履歴データから検索キーを読み出す時系列上の位置を変更する参照履歴変更手段と、
を有することを特徴とする情報処理システム。