JPWO2018043113A1 - 情報処理装置、情報処理方法、プログラム - Google Patents

Abstract

本技術は、プライバシーを保護しつつ、ユーザに情報を提供することができるようにする情報処理装置、情報処理方法、プログラムに関する。ユーザの発話から情報を抽出する抽出部と、ユーザからの要求があったとき、他の装置に問い合わせを行う問い合わせ部と、問い合わせ部が問い合わせを行うとき、問い合わせ内容に抽出部により抽出された情報を補足する補足部とを備える。補足部で補足される情報が、プライバシーに係わる情報であるか否かを判定する判定部をさらに備える。抽出部により抽出された情報は、プライバシーに係わる情報であるか否かを表すフラグと関連付けられてデータベースに登録される。本技術は、ユーザに情報を提示する情報処理装置に適用できる。

Description

本技術は情報処理装置、情報処理方法、プログラムに関し、例えば、ユーザのプライバシーを保護した状態で、ユーザに情報を提供するようにした情報処理装置、情報処理方法、プログラムに関する。

特許文献１では、常時ユーザ同士の会話を記録し、記録した後の時点で確認できるシステムについて提案されている。

特許文献２では、ユーザ同士の会話を監視し、特定のキーワードを記録し、他のユーザに通知することで、コミュニティの良好な状態を維持することが提案されている。

特開２００５−２３７０１７号公報 特開２０１４−８１７８２号公報

特許文献１や特許文献２では、ユーザ同士の会話を記録することが提案されているが、全ての会話を記録すると、ユーザのプライバシーが保護されない可能性がある。

本技術は、このような状況に鑑みてなされたものであり、プライバシーを保護しつつ、ユーザに情報を提供することができるようにするものである。

本技術の一側面の情報処理装置は、ユーザの発話から情報を抽出する抽出部と、ユーザからの要求があったとき、他の装置に問い合わせを行う問い合わせ部と、前記問い合わせ部が問い合わせを行うとき、問い合わせ内容に前記抽出部により抽出された前記情報を補足する補足部とを備える。

本技術の一側面の情報処理方法は、ユーザの発話から情報を抽出し、ユーザからの要求があったとき、他の装置に問い合わせを行い、前記問い合わせを行うとき、問い合わせ内容に抽出された前記情報を補足するステップを含む。

本技術の一側面のプログラムは、コンピュータに、ユーザの発話から情報を抽出し、ユーザからの要求があったとき、他の装置に問い合わせを行い、前記問い合わせを行うとき、問い合わせ内容に抽出された前記情報を補足するステップを含む処理を実行させる。

本技術の一側面の情報処理装置、情報処理方法、並びにプログラムにおいては、ユーザの発話から情報が抽出され、ユーザからの要求があったとき、他の装置に問い合わせが行われ、その問い合わせが行われるとき、問い合わせ内容に抽出された情報が補足される。

なお、情報処理装置は、独立した装置であっても良いし、１つの装置を構成している内部ブロックであっても良い。

また、プログラムは、伝送媒体を介して伝送することにより、または、記録媒体に記録して、提供することができる。

本技術の一側面によれば、プライバシーを保護しつつ、ユーザに情報を提供することができる。

なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。

本技術を適用した情報処理システムの一実施の形態の構成を示す図である。 他の情報処理システムの構成を示す図である。 情報処理システムの動作について説明するための図である。 情報処理システムの動作について説明するための図である。 情報取得部の構成について説明するための図である。 情報処理部の構成について説明するための図である。 情報処理システムの動作について説明するための図である。 秘匿データベースについて説明するための図である。 情報処理システムの動作について説明するための図である。 秘匿データベースについて説明するための図である。 情報処理システムの動作について説明するための図である。 情報処理システムの動作について説明するための図である。 情報処理システムの動作について説明するための図である。 情報処理システムの動作について説明するための図である。 情報処理システムの動作について説明するための図である。 情報処理システムの動作について説明するための図である。 情報処理システムの動作について説明するための図である。 秘匿データベースについて説明するための図である。 情報処理システムの動作について説明するための図である。 秘匿データベースについて説明するための図である。 情報処理システムの動作について説明するための図である。 情報処理システムの動作について説明するためのフローチャートである。 記録媒体について説明するための図である。

以下に、本技術を実施するための形態（以下、実施の形態という）について説明する。

＜システムの構成例＞
図１は、本技術を適用した情報処理システムの一実施の形態の構成を示す図である。情報処理システムは、情報取得部１１、情報処理部１２、外部サービス提供部２１が、家庭外ネットワーク３１を介して接続されている。

図１に示した情報処理システムにおいては、情報取得部１１と情報処理部１２は、家庭内に設置されている装置であるとして図示してあるが、図２に示す情報処理システムのように、情報処理部１２は、家庭外に設置され、家庭外ネットワーク３１を介して、情報取得部１１とデータの授受を行う構成とされていても良い。

図１に示した情報処理システムにおいて、情報取得部１１と情報処理部１２は、家庭内に設置され、家庭内に構築されたネットワーク、例えば無線または／および有線で構成されたＬＡＮ（Local Area Network）を介して接続されており、ネットワークを介して互いにデータの授受を行えるように構成されている。

また情報処理部１２は、家庭外ネットワーク３１を介して外部サービス提供部２１と接続されており、データの授受を行えるように構成されている。

図１または図２に示した情報処理システム（以下、図１に示した情報処理システムを例に挙げて説明を続ける）においては、情報取得部１１により情報が取得される。取得される情報は、例えば、ユーザの発話、ユーザ同士の会話、ユーザを識別するための情報などである。

情報取得部１１で取得された情報は、情報処理部１２に供給され、処理される。情報処理部１２は、例えば、ユーザの会話を記録したり、キーワードを抽出したり、会話しているユーザを特定したり、家庭内のどの部屋で会話しているかを特定したりする。また、外部サービス提供部２１に、所定の情報の問い合わせを行ったり、その問い合わせ結果をユーザに提供したりする。

外部サービス提供部２１に問い合わせが行われるとき、後述するように、さまざまな条件が考慮され、ユーザのプライバシーが外部（例えば、家庭外）に漏れないような処理がなされる。よって、ユーザのプライバシーが保護された状態で、ユーザに提供する情報を取得し、提示することができる。

外部サービス提供部２１は、所謂検索サーバと称されるサーバであったり、買い物などを行えるショッピングサイトを管理するサーバであったりする。

＜システムにおける処理例＞
図１に示した情報処理システムにおける処理について、図３、図４を参照して説明する。情報処理システムにおいては、ユーザのプライバシーを保護した状態で、ユーザが必要とする情報を提供することができる。

図３を参照し、ユーザの情報を秘匿しない（プライバシーを保護する必要が無い）場合における情報処理システムの処理について説明する。

時刻ｔ１において、ユーザＡが、“週末の奥多摩の天気を教えて”と情報処理システムに対して発話する。このような発話は、情報取得部１１で取得され、情報処理部１２に供給される。情報処理部１２は、この発話内容に、ユーザのプライバシーに関する情報があるか否かを判定する。“週末”、“奥多摩”、“天気”などは、ユーザのプライバシーに関する情報ではないと判定される。

情報処理部１２は、プライバシーに関する情報はないと判定した場合、外部サービス提供部２１に問い合わせを行う。この場合、情報処理部１２は、“天気”に関する情報を提供する外部サービス提供部２１に対して、“週末の奥多摩の天気”を問い合わせる。

その結果、時刻ｔ２において、情報処理システム（情報処理部１２）は、“週末の奥多摩の天気”に関する情報を取得し、ユーザＡに対して、その取得した情報を提供する。例えば、図３に示したように、“来週の奥多摩の天気は晴れ、降水確率は１０％です”といった情報が提供される。

ユーザのプライバシーに関する情報が無い場合、このような処理が行われる。一方、ユーザのプライバシーに関する情報がある場合について、図４を参照して説明する。

時刻ｔ１において、ユーザＡが、“ガンのステージ３の予後を教えて”と情報処理システムに対して発話する。“ガン”、“ステージ３”、“予後”といったキーワードは、ユーザＡがガンであった、ステージ３のガンであったなど、ユーザのプライバシーに関する可能性が高いと考えられる。

情報処理部１２は、このようなキーワードが検出された場合、プライバシーに係わる情報（秘匿する情報）であると判定する。このような判定は、後述するように、秘匿する情報（キーワード）であるか否かの判定を行うための情報を蓄積しているデータベース（以下、秘匿データベースと記述する）が参照されることで行われる。

秘匿データベースは、秘匿すべきキーワードに、フラグを立てて管理しており、この場合、“ガン”、“ステージ３”といったキーワードには、このフラグが立てられている。情報処理部１２は、そのような秘匿データベースを参照し、“ガンのステージ３の予後を教えて”というユーザからの要望に、フラグが立てられているキーワードが含まれているか否かを判定し、その結果、含まれているとの結論を出す。なお、フラグを付ける単語の選択は、機械学習等により、一般的にプライバシーを秘匿すべき単語群の判別を行っても良いし、カテゴリーなどをユーザに提示し、個別のユーザが指定するようにしても良い。

このような秘匿すべき情報が含まれている場合、外部サービス提供部２１に問い合わせを開始する前（外部にプライベートな情報を出力する前）に、ユーザに対して、プライバシーに係わる情報が含まれる可能性があること、そのような情報を外部に出して良いか否かの確認が行われる。すなわち、図４に示した例では、時刻ｔ２において、情報処理部１２は、ユーザＡに対して、“病気についての検索ですが、ガンのステージ３の予後で調べますか？”といった問いかけを行う。

この場合、“病気についての検索”であり、ユーザＡのプライバシーに係わる可能性があることをユーザＡに伝え、“ガンのステージ３の予後で調べますか”といったメッセージで、本当に調べて良いかの確認をとる。

このようなメッセージを聞いたユーザＡが、時刻ｔ３において、“匿名で調べて”といった場合、時刻ｔ４において、情報処理システムは、“ユーザＩＤなしで検索します”といった返答を行う。すなわちこの場合、ユーザＡは、匿名で調べて欲しいという希望を出し、情報処理システムは、ユーザＩＤなしで検索するという返答を出す。この後、情報処理システムは、ユーザが特定されるような情報を外部に出すことなく、外部サービス提供部２１に問い合わせを行い、情報を取得し、ユーザＡに対して提供する。

または、ユーザＡが、“検索を中止”というような外部サービス提供部２１への問い合わせの中止を指示した場合、外部サービス提供部２１に問い合わせは中止される。または、このような場合、プライバシーに係わる情報（キーワード）を除外した問い合わせが実行されるようにしても良い。

このように、ユーザのプライバシーに関する情報が、外部サービス提供部２１に提供される可能性がある場合、ユーザに、プライバシーに関する情報が外部に出る可能性があることを知らせ、外部に出ても良いか否かが問われる。このような処理がなされることで、ユーザのプライバシーに係わる情報が、ユーザが意図せずに外部に出されてしまうようなことを防ぐことができ、ユーザのプライバシーを保護した状態で、情報の検索や提供を行うことが可能となる。

＜情報取得部の構成＞
上記したような処理を行う情報取得部１１と情報処理部１２の構成について説明する。まず図５を参照し、情報取得部１１の構成について説明する。

情報取得部１１は、音声取得部５１とユーザ状態取得部５２を備える。音声取得部５１は、例えばマイクロフォンを含む構成とされ、家庭内に複数設置されている。例えば、家庭内には、リビング、ダイニング、キッチン、寝室、子供部屋、玄関などの部屋があり、これらの各部屋にマイクロフォンが設置され、ユーザの会話が収集され、必要に応じて記録される。

ユーザ状態取得部５２は、例えば、会話しているユーザを特定するための情報や、ユーザが向いている方向などの情報を取得する。ユーザ状態取得部５２は、例えば、撮像部や、各種センサを含む構成とされ、家庭内に複数設置されている。音声取得部５１と同じく、家庭内のリビング、ダイニング、キッチン、寝室、子供部屋、玄関などの部屋毎に設置され、その部屋に居るユーザを特定するための情報や、その部屋に居るユーザの視線方向などの情報が収集される。

＜情報処理部の構成＞
情報取得部１１で取得された情報は、情報処理部１２に供給され、処理される。図６を参照して、情報処理部１２の構成について説明を加える。

情報処理部１２は、ユーザ状態解析部７１、ユーザデータベース７２、ユーザ認識部７３、音声処理部７４、秘匿データベース作成部７５、秘匿データベース７６、秘匿情報判定部７７、および問い合わせ生成部７８を含む構成とされている。

なお、図２に示したように、情報取得部１１と情報処理部１２が家庭外ネットワーク３１を介してデータの授受を行う構成とした場合、図６に示した情報処理部１２の一部は、家庭内に設置されていても良い。

すなわち、情報処理部１２の一部、または全部（図１の場合）は、家庭内に設置されているように構成することができる。例えば、ユーザデータベース７２や、秘匿データベース７６などデータを管理するデータベースは、家庭内に設置され、他の部分は、家庭外に設置されているようにしても良い。

または、ユーザデータベース７２や、秘匿データベース７６などデータを管理するデータベースは、クラウドとし、他の部分は、家庭内に設置されているようにしても良い。

情報処理部１２の各部を、家庭内に設置するか、家庭外に設置するかは、適宜変更可能な構成である。

ユーザ状態解析部７１は、ユーザ状態取得部５２で取得された情報を用いて、ユーザの状態、例えば、会話している、他のユーザの方向を向いているなどの、ユーザがどのような状態であるかを解析する。解析結果は、秘匿情報判定部７７に供給される。また、図示はしていないが、必要に応じ、秘匿データベース作成部７５にも供給される。

ユーザデータベース７２は、ユーザを識別するためのデータベースである。例えば、ユーザ名（例えば、家族の名前）、年齢などの情報や、ユーザを特定するためのユーザの顔データ、音声データなども必要応じて記憶されている。また、ユーザのスケジュールや、友人リストなども記憶されているようにしても良い。

ユーザ認識部７３は、音声取得部５１や、ユーザ状態取得部５２（図５）から取得される情報を用いて、またユーザデータベース７２を参照し、所定の部屋にいるユーザを認識する。認識結果は、秘匿情報判定部７７に供給される。また、図示はしていないが、必要に応じ、秘匿データベース作成部７５にも供給される。

音声処理部７４は、音声取得部５１（図５）で取得された音声を意味解析し、キーワードを抽出する。処理結果（キーワード）は、秘匿情報判定部７７に供給される。また、秘匿データベース作成部７５にも供給される。

秘匿データベース作成部７５は、秘匿データベース７６を作成する。秘匿データベース７６は、上記したように、秘匿する情報（キーワード）であるか否かの判定を行うための情報を蓄積しているデータベースであり、秘匿すべきキーワードにフラグが立てられているデータベースである。

秘匿データベース作成部７５は、音声処理部７４で抽出されたキーワードを、秘匿データベース７６に登録するとともに、その登録するキーワードが秘匿するキーワードであるか否かを判定し、フラグを付加する。

詳細は後述するが、同一のキーワードであっても、発したユーザにより秘匿にする場合と秘匿しない場合とがあるため、ユーザ認識部７３で認識されたユーザもフラグを付けるときの判定材料とされる。

また、同一のキーワードであっても、発したユーザの視線方向より秘匿にする場合と秘匿しない場合とがあるため、ユーザ状態解析部７１で解析されたユーザの状態も、フラグを付けるときの判定材料とされる。

秘匿情報判定部７７は、ユーザ状態解析部７１、ユーザ認識部７３、および音声処理部７４からの情報から、また秘匿データベース７６を参照して、ユーザが発した文章（問いなど）に、秘匿情報が含まれているか否かを判定し、その判定結果を、問い合わせ生成部７８に供給する。

問い合わせ生成部７８は、判定結果に基づき、問い合わせを生成する。問い合わせ生成部７８は、秘匿情報を含まないとの判定結果であった場合、外部サービス提供部２１への問い合わせを実行する。また問い合わせ生成部７８は、秘匿情報を含むとの判定結果であった場合、外部サービス提供部２１への問い合わせを実行するか否かをユーザに問う問い合わせを実行する。

例えば、図３を参照して説明したように、ユーザＡが“週末の奥多摩の天気を教えて”と要求を出してきたときには、音声処理部７４で、例えば、“週末”、“奥多摩”、“天気”といったキーワードが抽出され、秘匿情報判定部７７に供給される。

秘匿情報判定部７７は、秘匿データベース７６を参照して、“週末”、“奥多摩”、“天気”といったキーワードのフラグを確認し、フラグが立てられていない（秘匿情報ではない）との判定結果を、問い合わせ生成部７８に出す。この結果、問い合わせ生成部７８は、外部サービス提供部２１に、“週末の奥多摩の天気”を問い合わせる。

また例えば、図４を参照して説明したように、ユーザＡが“ガンのステージ３の予後を教えて”と要求を出してきたときには、音声処理部７４で、例えば、“ガン”、“ステージ３”、“予後”といったキーワードが抽出され、秘匿情報判定部７７に供給される。

秘匿情報判定部７７は、秘匿データベース７６を参照して、“ガン”、“ステージ３”、“予後”といったキーワードのフラグを確認し、これらのいずれかのキーワードにフラグが立てられている（秘匿情報がある）との判定結果を、問い合わせ生成部７８に出す。この結果、問い合わせ生成部７８は、ユーザＡに、外部サービス提供部２１に問い合わせを実行しても良いかを問う問い合わせを実行する。

＜秘匿データベースを参照した処理例＞
図３、図４を参照して説明した情報処理システムにおいては、１のユーザからの要求（問い）に対して、秘匿情報が含まれているか否かを判定し、その判定に基づき、ユーザに確認をとってから、外部サービス提供部２１に問い合わせを行うことで、ユーザのプライバシーを保護する場合について説明した。

さらに、秘匿情報が含まれているか否かを判定する処理について説明を加える。

図７は、秘匿データベースを参照し、秘匿情報が含まれているかの判定を行い、判定結果に基づく処理を行う場合の一例を示す図である。

時刻ｔ１において、ユーザＡは、ユーザＢに対して、“人間ドックのことだけど”と話しかける。その話しかけに応じて、ユーザＢは、時刻ｔ２において、“ああ、尿酸値が１０超えてるって？”と言う。時刻ｔ３において、ユーザＡは、ユーザＢに対して、“どんなリスクがあるのかな”と言う。その問いに対し、ユーザＢは、時刻ｔ４において、情報処理システムに対して、“尿酸値について教えて”と要求を出す。

“尿酸値が１０超えている”という情報は、ユーザＡのプライバシーに係わる情報であると考えられる。プライバシーに係わる情報で外部サービス提供部２１に問い合わせが行われることで、外部にプライバシーに係わる情報が漏れる可能性がある。そのため、ユーザに対して、プライバシーに係わる情報を含む状態で、外部サービス提供部２１に問い合わせを行っても良いか否かの確認が行われる。

すなわち、図７に示した例では、時刻ｔ５において、情報処理システムは、ユーザに対して、“尿酸値１０を超える状態を調べていいですか？”という問い合わせを行う。このような問いに対して、ユーザＡまたはユーザＢが、時刻ｔ６において、“調べて”と言った許可を与えた場合、情報処理システムは、外部サービス提供部２１への問い合わせを実行する。その結果、時刻ｔ７において、情報処理システムは、“尿酸値１０以上の状態は、・・・・・です”といった検索結果をユーザに提供する。

このように、ユーザのプライバシーに係わる情報が含まれる場合、ユーザに対して外部に問い合わせを行うか否かを問い、問い合わせが許可されたときには、外部サービス提供部２１に問い合わせを行う。

一方、図示はしないが、時刻ｔ６において、ユーザＡ（またはユーザＢ）が、“調べないで”といた許可を与えなかった場合、情報処理システムは、例えば、“尿酸値についての検索を中止します”といった外部サービス提供部２１に問い合わせを中止したことを示すメッセージをユーザに出す。

ところで、このようなプライバシーに係わる情報が含まれるか否かの判定は、秘匿データベース７６が参照されて行われる。上記したように、秘匿データベース７６は、ユーザのプライバシーに係わる情報であるため、外部サービス提供部２１に問い合わせを行わず、秘匿すべき情報であることを示すフラグとともに、キーワードを管理するデータベースである。

図８に秘匿データベース７６の一例を示す。秘匿データベース７６には、“ユーザ”、“トピック”、“キーワード”、“秘匿フラグ”、“更新日時”といった項目が設けられ、それぞれの項目が関連付けられて管理されている。

秘匿データベース７６の“ユーザ”の項目には、発話したユーザに関する情報が書き込まれる。“トピック”の項目には、“キーワード”の項目に書き込まれるキーワードが属するトピックが書き込まれる。“キーワード”の項目には、監視していた会話から抽出されたキーワードが書き込まれる。

“秘匿フラグ”の項目には、“キーワード”の項目の所に書き込まれているキーワードが、秘匿すべき情報（プライバシーに係わる情報）であるか否かを表す情報が書き込まれる。“更新日時”の項目には、“キーワード”の項目の所に書き込まれているキーワードが発話された日時（監視されていた会話から抽出された日時）が書き込まれる。

例えば、図８に示した秘匿データベース７６の１行目を参照するに、“ユーザ”という項目には、“ユーザＡ”との情報が書き込まれ、“トピック” という項目には、“健康”との情報が書き込まれ、“キーワード” という項目には、“尿酸値”との情報が書き込まれ、“秘匿フラグ” という項目には、“１”との情報が書き込まれ、“更新日時” という項目には、“20160404 19:35”との情報が書き込まれている。

この場合、ユーザＡが、2016年4月4日の19:35に、尿酸値というキーワードを発し、尿酸値は、健康というトピックに該当し、秘匿すべき情報であるため秘匿フラグが“１”に設定されていることが読み取れる。ここでは、秘匿フラグが“１”の場合、秘匿すべき情報であることを示し、“０”である場合、秘匿する必要のない情報であることを示すとして説明を続ける。

なお、秘匿フラグが“０”の場合、秘匿すべき情報であることを示し、“１”である場合、秘匿する必要のない情報であることを示すとしても良い。また秘匿する情報にランクを付け、例えば、絶対に秘匿すべき情報、秘匿した方が良い情報、ユーザなどにより秘匿すべき情報、秘匿する必要が無い情報などのランクを付け、それらのランクに応じた情報が、秘匿フラグの項目に記載されるようにしても良い。

このような秘匿データベース７６は、秘匿データベース作成部７５により作成される。秘匿データベース作成部７５は、会話が監視され、キーワードが抽出されたとき、秘匿データベース７６に、抽出されたキーワードと、そのキーワードに係わる情報を書き込む。キーワードが書き込まれるとき、トピックの情報は、外部の辞書または内部の辞書が参照されて取得される。

秘匿フラグは、トピックに応じて設定される。例えば、トピックが、健康、金融資産、セキュリティなどである場合、これらのトピックに含まれるキーワード（情報）は、プライバシーに係わる情報である可能性が高いと考えられる。このように、プライバシーに係わる情報である可能性が高いトピックに属するキーワードは、秘匿する情報に設定され、秘匿フラグが“１”に設定される。

また、例えば、トピックが、地名、天気、食べ物などである場合、これらのトピックに含まれる情報は、プライバシーに係わる情報である可能性は低いと考えられる。このように、プライバシーに係わる情報である可能性が低いトピックに属するキーワードは、秘匿しない情報に設定され、秘匿フラグが“０”に設定される。

また秘匿フラグは、ユーザに応じて設定されるようにすることもできる。例えば、ユーザＡが大人（親）であり、ユーザＢが子供である場合、同一トピックに該当するキーワードであっても、異なる秘匿フラグが設定されるようにしても良い。

例えば、図８に示した秘匿データベース７６において、ユーザＡが発した“旅館”というキーワードは、“旅行”というトピックに該当し、“０”という秘匿フラグが設定されているが、ユーザＢが発した“キャンプ”というキーワードは、“旅行”というトピックに該当しているが、“１”という秘匿フラグが設定されている。

このように、ユーザにより、同一トピック内でも、異なる秘匿フラグが設定される、換言すれば、ユーザに依存して秘匿フラグが設定されるようにしても良い。

また、図８では項目として記載していないが、“部屋”という項目を設け、キーワードが発せられた場所に依存して、秘匿フラグが設定されるようにしても良い。詳細は、後述するが、例えば、リビングなどで話された内容は秘匿しない情報（秘匿フラグ＝０）に設定し、寝室などで話された内容は秘匿する情報（秘匿フラグ＝１）に設定されるようにしても良い。

勿論、トピック、ユーザ、場所などのいずれかの条件により、秘匿フラグが設定されるようにしても良いし、これら複数の条件を総合的に考慮して、秘匿フラグが設定されるようにしても良い。

秘匿データベース７６は、会話を監視し、監視している会話を意味解析し、キーワードを抽出することで行われるため、会話を監視しているときに作成（新たなキーワードの追加、更新など）が行われる。また、秘匿情報であるか否かは、過去の履歴も確認されることで行われる。図９を参照して後述するように、秘匿データベース７６の秘匿フラグは、所定の条件が満たされたとき、更新される。

図７を再度参照する。時刻ｔ４において、ユーザＢは、情報処理システムに対して、“尿酸値について教えて”と要求を出している。このとき、情報処理システムは、“尿酸値”というキーワードが、秘匿情報であるか否かを、秘匿データベース７６（例えば、図８参照）を参照して判定する。

図８に示した秘匿データベース７６が参照される場合、“尿酸値”というキーワードの秘匿フラグは“１”、すなわち、秘匿情報に設定されていることが読み取られる。この場合、“尿酸値”は、ユーザＡに関連付けられているが、会話をしているユーザが、ユーザＡとユーザＢのため、ユーザＡとユーザＢに関するデータベースが参照される。

このように、秘匿データベース７６が作成され、参照されることで、秘匿情報であるか否かが判定される。

なおここでは、監視されている会話から抽出されたキーワード（情報）が、秘匿データベース７６に書き込まれるとして説明を続けるが、さらに、その書き込まれるキーワードに類似する単語や、シソーラスなどで概念を広げたりして、関連する単語（キーワード）も、秘匿データベース７６に書き込まれるようにしても良い。

図９を参照し、秘匿レベルが変更（秘匿フラグが変更）されるときの処理について説明する。前提として、図９を参照して説明するような会話より以前に、図７を参照して説明したような会話がユーザ同士で行われ、その時の会話から抽出されたキーワードが、秘匿データベース７６に蓄積されている状態であるとする。

時刻ｔ１において、ユーザＡは、ユーザＢに対して、“人間ドックのことだけど”と話しかける。ユーザＢは、時刻ｔ２において、ユーザＡに対して、“今年はどうだった？”と質問する。ユーザＡは、時刻ｔ３において、“また尿酸値再検査だよ”と言う。ユーザＢは、時刻ｔ４において、“成人病のアドバイザを探して”と情報処理システムに要求を出す。

情報処理システムは、時刻ｔ１から時刻t３までの会話を監視し、例えば、“人間ドック”、“尿酸値”、“再検査”といったキーワードを抽出している。情報処理システムは、時刻ｔ５において、ユーザＢからの“成人病のアドバイザを探して”との要求に対して、“尿酸値異常に詳しいアドバイザを探します”といったメッセージをユーザに伝える。

情報処理システムは、このようなメッセージを出すために、“尿酸値”という情報を補足している。図８を参照するに、秘匿データベース７６では、“尿酸値”は、秘匿フラグが１に設定されており、秘匿情報とされている。

図７を再度参照するに、時刻ｔ５、時刻ｔ６において、情報処理システムからの“尿酸値１０を超える状態を調べていいですか？”という問いに対して、ユーザＡは、“調べて”と答えている。すなわちこの場合、ユーザＡは、秘匿データベース７６では、秘匿情報に設定されている“尿酸値”という情報を、外部サービス提供部２１に提供することを許可したことになる。

このように、外部サービス提供部２１に提供する（外部に出す）ことが許可されたキーワードは、秘匿フラグが変更される。すなわちこの場合、秘匿フラグが“１”から“０”に変更される。このような変更が行われることで、図１０に示したような秘匿データベース７６となる。すなわち、図１０に示した秘匿データベース７６においては、“尿酸値”というキーワードの秘匿フラグは“０”に設定し直され、更新日時は、“20160725 20:24”に更新されている。

図９を参照した説明に戻る。時刻ｔ５において、情報処理システムは、図１０に示した秘匿データベース７６を参照して処理を行うため、“尿酸値”というキーワードは、秘匿情報ではないと判定し、“尿酸値”との情報を、補足し、“尿酸値異常に詳しいアドバイザを探します”といったメッセージを生成し、ユーザに伝える。

情報処理システムは、そのようなメッセージをユーザに伝える一方で、外部サービス提供部２１に対して、“尿酸値異常に詳しいアドバイザ”について問い合わせを行う。この問い合わせは、ユーザの許可を得ることなく行われる。そして時刻ｔ６において、情報処理システムは、“近所には３件あります”といった検索結果をユーザに伝える。

図７乃至図１０を参照して説明したように、秘匿データベース７６が作成され、その秘匿データベース７６が参照され、秘匿情報の管理、例えば、外部サービス提供部２１への問い合わせ時に、秘匿情報が出されない、また出すときにはユーザの許可を得た後に出すという管理が行われる。

また秘匿データベース７６は、外部へ出すことの許可をユーザから得られた情報は、その後、秘匿情報から外されるといった更新が適宜行われるため、ユーザに適した秘匿データベース７６へと最適化することが可能である。

なお、例えば、図９の時刻ｔ４において、ユーザＢから情報処理システムに対して、“成人病のアドバイザを探して”との要求が出されるが、このような要求がなくても、情報処理システムは、外部サービス提供部２１に問い合わせを実行し、例えば、“尿酸値”に係わる情報をユーザに提供するようにしても良い。

換言すれば、過去に外部に問い合わせた履歴がある場合、ユーザからの依頼がなくても、外部サービス提供部２１に問い合わせが実行されるようにしても良い。

＜会話から情報を取得する場合１＞
図３乃至図１０を参照して説明した情報処理システムにおいては、１のユーザからの要求（問い）に対して、秘匿情報が含まれているか否かを判定し、その判定に基づき、ユーザに確認をとってから、外部サービス提供部２１に問い合わせを行うことで、ユーザのプライバシーを保護する場合について説明した。

次に、ユーザのプラバシーを保護し、さらに情報を付加して、より有益な情報をユーザに提供できるようにする場合について説明を加える。

図１１を参照し、会話から情報を収集し、情報を補足する場合について説明する。時刻ｔ１において、ユーザＡが、“今週末さぁ”と、ユーザＢに対して話しかける。時刻ｔ２において、そのような話しかけに応じ、ユーザＢが、ユーザＡに対して、“ああ、奥多摩のキャンプね”と返答する。その会話の続きとして、時刻ｔ３において、ユーザＡが、“天気、気になるよね”とユーザＢに対して返答する。

そして、時刻ｔ４において、ユーザＢが、情報処理システムに対して、“天気を教えて”と要求を出す。時刻ｔ１乃至時刻ｔ３における会話は、ユーザＡとユーザＢとの間で行われている会話であるが、時刻ｔ４における会話は、ユーザＢと情報処理システムとの間で行われている会話である。このように、情報処理システムに要求が出された時点で、情報処理システムは、補足する情報の収集を開始する。

情報処理システムは、時刻ｔ１から時刻ｔ３までのユーザＡとユーザＢの会話を監視し、キーワードを切り出している。例えば、情報取得部１１の音声取得部５１は、常に音声を取得し、情報処理部１２に出力している。情報処理部１２の音声処理部７４は、音声取得部５１から供給される音声データを解析し、キーワードを抽出する。抽出されたキーワードは、秘匿データベース７６に保存される。

なお、ユーザ状態取得部５２で取得された情報から、ユーザが部屋に入ってきたと感知されたことをトリガーとして、音声取得部５１による音声の取得が開始されるようにしても良い。

このように、会話が開始された時点から、ユーザが情報処理システムに要求を出すまでの間に行われた会話は、監視され、キーワードが抽出されたり、記録されたりはするが、そのキーワード（情報）を用いた処理は実行されていない状態とされる。

そして、ユーザが情報処理システムに要求を出した時点で、それより以前の会話に遡って、ユーザからの要求を満たすために必要となる情報の収集が行われる。図１１に示した例の場合、ユーザＢは、“天気を教えて”といった要求を出しているが、この要求だけだと、いつの天気であるのか、どこの天気であるのかといった情報が欠落している。

情報処理システムは、時刻ｔ１において、ユーザＡが発した“今週末”とのキーワードから、“今週末”という日時に関する情報を取得する。また、情報処理システムは、時刻ｔ２において、ユーザＢが発した“奥多摩”とのキーワードから、“奥多摩”という場所に関する情報を取得する。

このようにユーザからの要求が出される以前の情報から、ユーザから出された要求を満たすために必要な情報が収集される。そして、図１１に示した例では、時刻ｔ５において、情報処理システムは、 “今週末の奥多摩の天気を調べます”といったメッセージを生成し、ユーザＡ，Ｂに対して伝える。このようなメッセージを伝えることで、捕捉した不足部分（この場合、日時と場所）に間違いがないかを確認させることができる。

また、このようなメッセージを伝えることで、これから、外部サービス提供部２１に問い合わせが行われることをユーザＡ，Ｂに対して伝えることができ、“今週末の奥多摩の天気を調べます”といったメッセージにプライバシー情報が含まれている場合、ユーザは、プライバシー情報が含まれており、その情報が外部に出される可能性があることを認識することができる。

ユーザＡまたはユーザＢが、このようなメッセージを聞いて、間違いがあると判断した場合、またはプライバシー情報が含まれていると判断した場合、情報処理システムに対して、外部サービス提供部２１への問い合わせを中止させる指示を出すことができる。

例えば、ユーザが、“問い合わせの中止”といった要求を出した場合、外部サービス提供部２１への問い合わせは、中止される。または、ユーザが、“東京の今日の天気を教えて”といった新たな要求を出した場合、“今週末の奥多摩の天気を調べる”という先の要求はキャンセルされ、新たな要求に対する問い合わせが行われる。

図１１に示した例では、ユーザによる外部サービス提供部２１への問い合わせに対する中止の命令が出されなかったため、“今週末の奥多摩の天気を調べます”という問い合わせが、外部サービス提供部２１に対して行われ、その問い合わせの結果、時刻ｔ６において、“今週末の奥多摩の天気は晴れ、降水確率１０％です”という情報が、ユーザＡ，Ｂに対して提供される。

図１１に示した例では、図３に示した例と同じく、秘匿する情報が含まれてない場合を例に挙げて説明したが、図１１に示した例においても、上記したように、一度ユーザに対して外部サービス提供部２１に問い合わせすることを確認している（時刻ｔ５において、メッセージを出している）ため、プライバシー情報が、ユーザが意図しないときに出てしまうようなことを防ぐことができる。

図４に示した例と同じく、秘匿する情報が含まれていた場合、ユーザに対して外部サービス提供部２１に問い合わせをしても良いか否かの確認がとられる。すなわち、例えば、図１１に示した例において、“今週末の奥多摩の天気”という問い合わせを行うときに、この問い合わせに秘匿すべき情報が含まれていると判定された場合、時刻ｔ５において、情報処理システムからユーザに対するメッセージは、例えば、“今週末の奥多摩の天気を調べますが、いいですか？”といったようなユーザの許可を求めるメッセージとされる。

このようなメッセージに対して、ユーザが答えた場合、その答えに応じて、外部サービス提供部２１への問い合わせが行われる。

このように、常にユーザの会話（発話）を記録しておき、必要に応じて、その記録してある情報を用いて、問い合わせに必要な情報を補足することで、ユーザの要求に対する返答を、より正確なものとすることができる。

例えば図１１に示した例において、補足が行われなければ、ユーザに対して、例えば、“今日の天気は晴れ”といったようなユーザが所望としていない答えが返される可能性があるが、本技術によれば、このような答えが返されるようなことは防がれ、上記したように、ユーザが所望とする答えを返すことが可能となる。

またこの例の場合も、上記したように、ユーザのプライバシーに係わる情報が、外部に漏れるようなことを防ぐことができる。

なお、図１１では、情報が補足される例を示したが、ユーザの設定により補足されないようにしたり、ユーザが意図してないときには補足されないようにしたりする構成としても良い。このような場合について、図１２を参照して説明する。

時刻ｔ１乃至t４までのユーザＡ、ユーザＢ、および情報処理システム間で行われる会話は、図１１に示した時刻ｔ１乃至t４までのユーザＡ、ユーザＢ、および情報処理システム間で行われる会話と同様である。

時刻ｔ４において、ユーザＢが“天気を教えて”と情報処理システムに対して要求すると、時刻ｔ５において、情報処理システムは、“どこのいつの天気を調べますか？”といった返答を行う。この場合、情報を補足しないため、場所や日時に関する情報が不足しており、そのような不足している情報をユーザに問うメッセージが、情報処理システムから出される。

このように、不足している情報がある場合でも、情報を補足せずに、ユーザに直接問うような構成とすることも可能である。

また、このようにした場合、会話自体は、常に監視し、記録しておくが、情報の補足は行わないように設定しておくことができる。すなわち、図１１を参照して説明したように、時刻ｔ１乃至時刻ｔ３におけるユーザＡとユーザＢの会話は監視され、キーワードの抽出なども行われるが、その情報は、ユーザの許可がない状態では補足などに用いられないように構成することもできる。

補足に用いるか否か、会話を記録しておくか否かなどは、ユーザが設定できるようにしておくことで、ユーザの意図をより反映したシステムを構築することができる。

また、ユーザが会話の記録を明示的に情報処理システムに指示していると判定できるときだけ、会話が監視されるようにしても良い。図１２を参照するに、ユーザＡやユーザＢは、時刻ｔ１乃至時刻ｔ３において会話しているとき、情報処理システムの方（音声取得部５１の方）を向いていないで会話しているとする。

このように、情報処理システムの方に、ユーザの視線や体が向いていないときには、ユーザは会話を監視されたくないと望んでいるとし、監視しないようにする。換言すれば、ユーザが情報処理システムの方を向いているなど、情報処理システムに対して監視を行うことを指示していると判定できるときには、ユーザの会話が監視されるようにしても良い。

ユーザの視線や体が情報処理システムの方に向いておらず、会話が監視されていないときには、情報の補足は行われない。

このように、会話を監視するか否か、監視する場合に情報を必要に応じて補足するか否かは、ユーザが設定できるようにし、ユーザの意図が反映された情報処理システムとすることも可能である。

＜会話から情報を取得する場合２＞
次に、図１３を参照して、会話から情報を取得する場合について説明する。図１３を参照して説明する例は、図１１を参照して説明した例と同じく、基本的に、会話を監視し、情報（キーワード）を抽出し、記録し、その記録されている情報を、必要に応じて読み出し補足する。その補足する情報が、図１１では、直前の会話から抽出された情報である場合を例に挙げたが、図１３では、直前の会話に限らず、過去に抽出された情報（直前の会話から抽出された情報とは異なる情報）である点が異なる。

図１３を参照するに、時刻ｔ１において、ユーザＡがユーザＢに対して、“夏休みどうする？”と質問する。ユーザＢは、この質問に対して、時刻ｔ２において、“箱根とかどうかな？”といった返答を行う。時刻ｔ３において、ユーザＡは、“まだ宿取れるかな？”と質問する。この質問に対して、ユーザＢは、時刻ｔ４において、情報処理システムに対して、“宿空いてる”との質問（要求）を出す。

情報処理システムは、図１１を参照して説明した場合と同じく、時刻ｔ１乃至時刻ｔ３において、ユーザＡとユーザＢとの会話から、場所や日時の情報を抽出し、補足する。すなわち、情報処理システムは、場所として“箱根”という情報を取得し、日時として“夏休み”という情報を取得する。

このような情報が取得されることで、情報処理システムは、“夏休みの箱根の宿を検索します”というメッセージを作成することができる。さらに情報処理システムは、ユーザＡとユーザＢ（ユーザＡとユーザＢを含む家族）は、過去の情報から、温泉旅館を好んで予約することを推測できた場合、そのような情報も問い合わせメッセージに含める。

その結果、図１３に示したように、時刻ｔ５において、情報処理システムは、“夏休みの箱根の温泉旅館を検索します”といったメッセージを作成し、ユーザＢに伝える。このメッセージのうち、“温泉旅館”というキーワードは、過去の情報から取得（推測）された情報である。

この過去の情報は、日常的にユーザ間で交わされている会話（会話内容）が記録、分析されることで蓄積された情報である。また、会話だけでなく、例えば、ユーザの予定（未来に立てた予定だけでなく、過去に書き込んだ予定も含む）、行動履歴なども蓄積し、解析し、情報として蓄積しておくようにし、そのような情報も、過去の情報として用いることができる。

このように、ユーザに関する情報、例えば、嗜好情報、日常生活の行動パターン等を、種々の情報（音声、画像、予定表など）から取得し、解析し、蓄積するようにし、その蓄積した情報を、必要に応じて読み出し、補足する情報として用いるようにすることができる。

図１３に示した例において、このような補足がされない場合、“夏休みの箱根の宿を検索します”というメッセージがユーザに提供され、外部サービス提供部２１に問い合わせが行われるが、“箱根の宿”という検索条件だと、宿の数が多くなり、ユーザに提供される情報量が多くなる可能性がある。

しかしながら、本技術によれば、“温泉旅館”という情報が、ユーザの嗜好情報として、ユーザデータベースに蓄積され、その情報が利用されるため、上記したように、“夏休みの箱根の温泉旅館を検索します” というメッセージがユーザに提供され、外部サービス提供部２１に問い合わせが行われる。よって、“箱根の宿”という検索条件だけでなく、さらに“温泉旅館”という条件が加わるため、宿の数を絞り込むことが可能となり、ユーザに提供される情報量を適切な量に絞り込むことが可能となる。

またこのような情報（嗜好情報など）は、ユーザ毎（家族毎）に異なるため、図１３に示したような会話が他の家族で行われた場合、情報処理システムが生成するメッセージは、例えば、“夏休みの箱根のリゾートホテルを検索します”、“夏休みの箱根の格安な宿を検索します”といったようなメッセージとなる。よって、本技術によれば、ユーザ（家族）に適した検索が行われるための情報を適切に補足することが可能となる。

また補足される情報は、１つではなく、複数であっても良い。例えば、上記した例では、“温泉旅館”といった１つの情報が補足される例を示したが、例えば、“温泉旅館”、“海鮮料理”、“格安”といった複数の情報が補足され、“夏休みの箱根の海鮮料理が自慢の格安温泉旅館を検索します”といったメッセージが作成され、検索が行われるようにしても良い。

なお、このようなユーザの嗜好情報といったような情報も、秘匿データベース７６にフラグとともに蓄積されるようにしておくことで、仮に“温泉旅館”というキーワードが秘匿情報と設定されていた場合、そのような秘匿情報が外部に漏れるようなことを防ぐことが、上記した場合と同様にできる。

例えば、ユーザが“Ａ社の保養所”によく行くため、“Ａ社の保養所”という情報が秘匿データベース７６に記憶されていた場合、“Ａ社”というのはユーザのプラバシー情報に該当する可能性があり、秘匿情報として扱うとしてフラグが立てられた状態で管理される。

このような場合に、図１３に示したような会話があり、時刻ｔ５において、情報処理システムが、情報を補足して、ユーザに提示するメッセージとしては、例えば、“夏休みのＡ社の保養所の空き情報を検索しますが、いいですか？”といったメッセージになる。

図４を参照して説明したように、秘匿情報が含まれる場合には、ユーザに外部サービス提供部２１に問い合わせをして良いか否かを問い合わせ、許可が得られたときに行われる。よって、図１３を参照して説明したような過去の情報、例えばユーザの嗜好情報が補足情報として用いられるような場合にも、ユーザのプラバシーを保護した外部サービス提供部２１への問い合わせを行うことができる。

図１４に、図１３を参照した場合と同じく、会話から情報を取得する場合であり、他の情報を用いてメッセージを生成したり、外部サービス提供部２１への問い合わせを行ったりする他の例について説明する。

他の情報として、秘匿データベース７６またはユーザデータベース７２に、ユーザのスケジュール、ユーザの友人リストが記録されており、それらの情報が用いられるとして説明を続ける。ここでは、ユーザデータベース７２に、ユーザを識別する情報とともに、そのユーザの情報として、スケジュールや友人リストも関連付けられて記憶されているとして説明を続ける。

ユーザデータベース７２に、ユーザＢのスケジュールとして、
８月８日、Ｘさん、Ｙさんとパーティー
という情報が記録されているとする。

またユーザデータベース７２に、ユーザＢの友人リストとして、
Ｘさん（夫婦、中学生の女子、小学生の男子）
Ｙさん（夫婦、小学生の男子）
という情報が記録されているとする。

図１４を参照するに、時刻ｔ１において、ユーザＢが、ユーザＡに、“次回のパーティー何作ろう？”と質問する。この質問に対して、ユーザＡは、時刻ｔ２において、“和食系は？”と返答する。ユーザＢは、時刻ｔ３において、情報処理システムに対して、“和食でお勧めは？”と質問（要求）を出す。

ここまでの会話は、情報処理システムで監視されており、“パーティー”、“何作ろう”、“和食系”といったキーワードが抽出されている。情報処理システムは、これらのキーワードと、ユーザＢからの“和食でお勧めは？”という質問から、用途として、“パーティー”であり、“何作ろう”といったキーワードから、レストランなどの食べに行くところの検索ではなく、作るためのレシピの検索であるという情報を得る。

その結果、情報処理システムは、“パーティー”、“レシピ”といった情報を補足し、“パーティーのときにお勧めの和食のレシピを検索する”ことまで推測する。また、ユーザデータベース７２で管理されているスケジュールを参照し、パーティーは、８月８日に行われるＸさんとＹさんが出席するパーティーであることを認識する。さらに、ユーザデータベース７２で管理されている友人リストを参照し、Ｘさんには、２人の子供がいることと、Ｙさんには、１人の子供がいることを認識する。

このような認識の結果、情報処理システムは、パーティーには子供が多く出席することを認識する。このような情報も補足した結果、情報処理システムは、時刻ｔ４において、“和食のパーティーメニューで子供に人気のレシピを検索します”といったメッセージをユーザに伝える。その後、ユーザからのキャンセルが入らなければ、“和食のパーティーメニューで子供に人気のレシピ”が、外部サービス提供部２１に対して問い合わせられる。

情報処理システムで情報の補足が行われなければ、“和食でお勧めは？”という問いで、外部サービス提供部２１に問い合わせが行われるため、例えば、和食のレストランや、和食のレシピ、和食のお土産など、さまざまな“和食”に関する情報が検索され、ユーザに提示されてしまう。

しかしながら、本技術によれば、ユーザ同士の会話から、上記した例では、用途や対象に対する情報が補足され、スケジュールや友人リストから、参加する人の人数や年齢などの情報が取得され、その取得された情報からの推測が行われ、その推測結果が、情報としてさらに補足される。よって、ユーザが望んだ情報を、より的確に検索し、提供することが可能となる。

また、スケジュールや友人リストから、参加する人の人数や年齢などの情報が取得され、その取得された情報からの推測が行われるが、スケジュールや友人リストというプライバシー情報をそのまま用いるのではないため、プライバシー情報が、外部サービス提供部２１に提供されることはなく、プライバシーを保護した検索を行うことが可能である。

＜人による秘匿＞
本技術においては、上記したように、会話を監視し、キーワードなどを抽出したり、抽出したキーワードを情報として、外部サービス提供部２１への問い合わせ時に補足情報として用いたりする。会話を監視する場合においても、ユーザにより会話を監視する場合と監視しない場合とがあるようにしても良い。

例えば、図１５を参照して説明するように、子供同士の会話の場合には、会話を監視しないで、情報の補足なども行わないようにすることができる。また、例えば、図１６を参照して説明するように、家族以外の人（以下、ゲストと記述する）との会話は監視しないで、情報の補足なども行わないようにすることができる。

図１５を参照して、子供同士の会話の場合には、会話を監視しない例について説明する。なおここでは、子供を例に挙げて説明するが、子供や高齢者などの成人の判断を必要とするような判断能力の低いユーザに対して、この実施の形態は適用できる。

時刻ｔ１において、子供Ａは、子供Ｂに対して、“夏休みどこいくんだっけ？”という質問を行う。子供Ｂは、時刻ｔ２において、“キャンプだって”という返答を行う。時刻ｔ３において、子供Ａは、“どうやっていくの？”という質問を行う。この質問に対して、子供Ｂは、情報処理システムに対して、“行き方を教えて”と要求を出す。

情報処理部１２のユーザ認識部７３（図６）は、ユーザ状態取得部５２（図５）で取得された情報、例えば、画像データから、会話しているユーザを、ユーザデータベース７２を参照して特定する。ユーザデータベース７２には、例えば、子供Ａの画像データが記憶されており、その画像データと、取得された画像データとのマッチングが行われることで、子供Ａであることが特定される。また、子供Ｂに対しても同様に特定が行われる。

音声取得部５１により取得される音声の周波数などから、子供であるか大人であるかが特定されるようにしても良い。

また仮に子供Ａがゲストであり、ユーザデータベース７２にユーザとして登録されていない場合、マッチングの結果、ユーザとして特定されないため、そのような特定されないユーザは、ゲストであるとして処理されるようにしても良い。そして、後述するように、ゲストは、この場合、子供と同じ扱いとし、会話の監視などが行われないように設定することができる。

図１３や、図１４を参照して説明した場合が、図１５に示したような状況の場合にも適用された場合、時刻ｔ１から時刻ｔ４までの間で、子供Ａと子供Ｂとの間で交わされた会話から、例えば、“夏休み”、“キャンプ”といったキーワードが抽出され、必要に応じて、補足情報として用いられる。また、ユーザデータベース７２が参照され、子供Ｂのスケジュールから、行き先や、行く曜日などが読み出され、必要に応じて、補足情報として用いられる。

しかしながら、子供同士の会話の場合、会話を監視しない設定とされていた場合、このような情報の補足は行われないため、情報処理システムは、例えば、時刻ｔ５において、“行き方は調べておきます”といった返答を行う。または、情報処理システムは、時刻ｔ５’において、“行き先はおかあさんといっしょに調べましょう”といった返答を行う。

このように、子供同士の会話の場合、外部サービス提供部２１への問い合わせは行われない。子供は、プライバシーの概念が低く、プライバシーに係わる情報を話す可能性がある。また、外部サービス提供部２１に問い合わせを行うとき、プライバシー情報が含まれるが、問い合わせを行うか否かの判断を、子供に行わせるのも好ましくはない。

そこで、上記したように、外部サービス提供部２１に問い合わせを行わず、親に連絡（相談）することを促すようなメッセージが生成され、子供に伝えられる。

外部サービス提供部２１に問い合わせを行わないことが前提となっているため、子供同士の会話は監視しないようにすることができる。また、子供同士の会話自体は監視し、キーワードの抽出や、秘匿データベース７６への登録などは行うが、外部サービス提供部２１への問い合わせは行わず、情報の補足なども行わないように設定することができる。

子供同士の会話から抽出されたキーワードが、秘匿データベース７６に登録される場合、秘匿する情報として登録される。

このような会話の監視を行わない、または監視は行うが、秘匿情報として扱うのは、子供同士の会話の場合の他に、子供が含まれる会話、例えば、親と子供との会話の場合にも適用できる。また、親と子供の会話の場合、子供の発話は、監視しない、または秘匿情報として扱い、親の発話は、監視し、内容により秘匿情報として扱うようにしても良い。

図１５に示した例の場合、子供Ａまたは子供Ｂは、友達同士で、一方は、情報処理システムが設置されている家に住んでいる家族であり、他方は、他人（ゲスト）である可能性がある。このようにゲストが含まれる場合も、会話の監視を行わない、または秘匿情報として扱うようにすることができる。

図１６を参照し、ゲストが含まれる場合の会話の監視や情報の補足について説明する。図１６において、ユーザＡは、情報処理システムが設置されている家の家族であり、ゲストＡは、家族ではない人である。また、ユーザＡとゲストＡは、共に大人である場合を例に挙げて説明する。

ゲストとの会話は、ゲストのプライバシーに配慮し、会話を監視しない、会話を監視しても、情報の補足は行われないなどの設定がなされる。

時刻ｔ１において、ゲストＡが、ユーザＡに対して、“週末旅行に行くのよ”と言う。これに対して、ユーザＡが、時刻ｔ２において、“ああ、奥多摩のキャンプね”と言う。これに対して、ゲストＡが、時刻ｔ３において、“天気が気になるわ”と言う。ここまでの会話が、ゲストＡとユーザＡとの間で行われる。

このときの会話は、ゲストが含まれるため、監視されていない。または、会話は監視され、キーワードが抽出される等の処理は行われるが、その後の情報の補足などは行われない。

時刻ｔ４において、ユーザＡが、情報処理システムに対して、“天気を教えて”と問う。上記した例、例えば、図１１を参照して説明した例では、会話が監視され、必要に応じて、情報が補足されるため、時刻ｔ６において、情報処理システムは、“今週末の奥多摩の天気は晴れ、降水確率は１０％です”という返答が出される。

図１６を参照して説明している例では、ゲストが含まれるため、会話の監視が行われない、または会話の監視は行われているが、情報の補足は行われないため、時刻ｔ５において、情報処理システムは、ユーザＡに対して、“場所と日にちを教えてください”といったメッセージを出す。

時刻ｔ１から時刻ｔ３までのユーザＡとゲストＡとの会話で、“奥多摩”、“今週末”といった場所や日にちに関する情報は出ていたが、ゲストを含む会話であるため、情報の補足は行われない。その結果、場所や日にちに関する情報が足りないため、情報処理システムは、時刻ｔ５において、足りない情報を得るために、“場所と日にちを教えてください”といったメッセージをユーザＡやゲストＡに対して出す。

その結果、ユーザＡが、時刻ｔ６において、“週末の奥多摩よ”と返答する。このような返答を得ることで、情報処理システムは、場所や日にちに関する情報を得ることができたため、時刻ｔ７において、外部サービス提供部２１に問い合わせを行い、その問い合わせ結果として、“週末の奥多摩の天気は晴れ、降水確率１０％です”とのメッセージをユーザＡに対して出す。

このようにゲストを含む会話の場合、会話自体を監視しないようにしても良い。また会話は監視し、キーワードを抽出し、秘匿データベース７６に登録するようにしても良いが、外部サービス提供部２１への問い合わせ時には、登録された情報での補足はしないようにしても良い。

なお、ゲストがいるときに、外部サービス提供部２１に問い合わせが行われる場合、ゲストやユーザ（家族）から許可を得るための処理が含まれるようにしても良い。すなわち、会話しているユーザにゲストが含まれる場合、ゲストやユーザが、許可したときだけ、外部サービス提供部２１に問い合わせが実行される仕組みを設けても良い。

ここで、会話の相手が家族以外の人である場合の会話の監視や外部サービス提供部２１に問い合わせを行うか否かの設定などについて再度説明を加える。ここでは、例えば会話の監視を行う、または行わないといった設定は、秘匿レベルに応じて設定されるとする。

秘匿レベルは、会話の相手に応じて設定される。なお後述するように、会話がなされていた場所などにより秘匿レベルが設定されるようにすることもできる。

秘匿レベルは、家族である場合、
会話の監視（音声取得部５１） オン
ユーザデータベース７２または秘匿データベース７６への登録 オン
外部問い合わせ時の情報の補足 オン （例外として子供の場合はオフ）
に設定される。（設定１とする）

秘匿レベルは、ゲスト（ゲストが含まれる状況）である場合、
会話の監視（音声取得部５１） オフ
ユーザデータベース７２または秘匿データベース７６への登録 オフ
外部問い合わせ時の情報の補足 オフ
に設定される。（設定２とする）

または、秘匿レベルは、ゲスト（ゲストが含まれる状況）である場合、
会話の監視（音声取得部５１） オン
ユーザデータベース７２または秘匿データベース７６への登録 オン
外部問い合わせ時の情報の補足 オフ
に設定される。（設定３とする）

秘匿レベルは、会話しているユーザ毎に設定されていても良いし、会話しているユーザ内に、ゲストや子供が居る場合には、そのユーザに合わせて設定されるようにしても良い。

例えば、会話しているユーザ毎に設定される場合であり、家族だけで会話しているときには、設定１がユーザ毎に設定される。またユーザ毎に設定される場合であり、家族とゲストで会話しているときには、家族に該当するユーザには、設定１が設定され、ゲストに該当するユーザには、設定２または設定３が設定される。

また、ユーザ毎に秘匿レベルが設定されるのではなく、会話しているユーザを１グループとし、そのグループ毎に秘匿レベルが設定される場合、例えば、グループが家族のみ場合には、設定１が設定される。また、例えば、グループ内にゲストが含まれる場合、設定２または設定３が設定される。

設定２または設定３のどちらが設定されるかは、情報処理システムを管理するユーザが設定できるようにしておいても良いし、予め設定されていても良い。

また、ゲストであっても、例えば、親族など、情報処理システムを管理しているユーザの家族と一緒に住んでは居ないが家族に該当する人、またはたびたび遊びに来ており、家族的な扱いを行える人には、設定１が設定されるようにしても良い。

例えば、５回以上訪問している人は、家族として扱い、秘匿レベルは設定１が設定される。なお、秘匿レベルが変更されるときには、情報処理システムを管理している管理者に、変更しても良いかを問い合わせる仕組みを設けても良い。そして、変更しても良いとの返答が、管理者から得られたときだけ、秘匿レベルが変更されるようにしても良い。

また、管理者により、秘匿レベルが設定されるようにしても良い。例えば、家族は、設定１が設定されるが、家族であっても、設定２や設定３が管理者により設定できたり、ゲストであっても、設定１が設定できたりするようにしても良い。

このように、ユーザにより秘匿レベルが設定される。

また、秘匿レベルとして、電話の会話は記録しないといった秘匿レベルが設定されるようにしても良い。電話での会話は、他人（ゲスト）との会話になるため、上記したゲストに対する秘匿レベル（設定２または設定３）が設定されるようにしても良い。

例外として、家族同士の電話での会話は、家族に対する秘匿レベル（設定１）が設定されるようにしても良い。

＜場所による秘匿＞
秘匿レベルは、場所により設定されるようにしても良い。例えば、寝室は、親同士が会話することが多く、プライバシーに係わる会話をする頻度が高い場所であると考えられる場合、寝室での会話から得られた情報は、秘匿情報として扱う。

また、リビングは、家族が集まって会話することが多く、プライバシーに係わる会話をする頻度が低い場所であると考えられる場合、リビングでの会話から得られた情報は、基本的に秘匿情報としては扱わない。基本的に秘匿情報として扱わないとしたのは、例えば、上記した例では、子供やゲストが含まれる会話や、秘匿情報として扱うトピックなどは、秘匿情報とされるため、そのような秘匿情報とされる場合を除くという意味である。

また、玄関は、ゲストと話す頻度が高い場所であると考えられる場合、玄関での会話から得られた情報は、秘匿情報として扱う。また、子供部屋は、子供を含む会話が行われる可能性が高いため、子供部屋での会話から得られた情報は、秘匿情報として扱う。なおここでは、リビングや寝室などの部屋を例に挙げて説明を続けるが、部屋という概念以外の特定の場所（エリア）に対しても本実施の形態は適用できる。例えば、部屋の一部のエリアを、秘匿情報として扱うエリアとすることも可能である。

このような部屋毎の秘匿レベルの設定は、デフォルトで設定され、ユーザにより設定が変更されるようにすることができる。

図１７は、寝室２０１でユーザＡとユーザＢが会話している場合を表している。時刻ｔ１において、ユーザＡは、ユーザＢに対して、“リフォームのことだけど”と話しかける。ユーザＢは、時刻ｔ２において、“どの程度やる？セキュリティ強化したいな”と言う。

時刻ｔ３において、ユーザＡは、“どれくらいかかるかな”と言う。時刻ｔ４において、ユーザＢは、情報処理システムに、“リフォームの費用について教えて”と要求を出す。この要求に対して、情報処理システムは、“リフォームの費用を調べます”というメッセージを出す。

情報処理システムは、外部サービス提供部２１にリフォームの費用について問い合わせを行う。時刻ｔ６において、情報処理システムは、“リフォームの事例は・・・”という検索結果をユーザに伝える。

このような寝室２０１においてなされた会話からの情報は、秘匿情報に設定される。時刻ｔ１から時刻ｔ３においてなされたユーザＡとユーザＢとの会話を、情報処理システムは監視しており、その結果、例えば、図１８に示すような秘匿データベース７６が作成される（秘匿データベース７６に情報が追加される）。

図１８に示した秘匿データベース７６には、時刻ｔ１から時刻ｔ３においてなされたユーザＡとユーザＢとの会話から抽出された“リフォーム”、“セキュリティ”といったキーワードが追加されている。

“リフォーム”というキーワードは、ユーザＡが時刻ｔ１において発した“リフォームのことだけど”という会話から抽出されたキーワードである。また、トピックとして、“リフォーム”というトピックが関連付けられ、更新日時として“20160405 19:35”が関連付けられている。

“リフォーム”というトピックが、秘匿情報に該当するトピックでなくても、寝室での会話であるため、秘匿情報として扱われる。よって、図１８に示したように“リフォーム”というキーワードは、秘匿情報に設定され、秘匿フラグとして“１”が設定される。

同様に“セキュリティ”というキーワードは、ユーザＢが時刻ｔ２において発した“セキュリティ強化したいな”という会話から抽出されたキーワードである。また、トピックとして、“安全”というトピックが関連付けられ、更新日時として“20160405 19:35”が関連付けられている。

“安全”というトピックが、秘匿情報に該当するトピックでなくても、寝室での会話であるため、秘匿情報として扱われる。よって、図１８に示したように“セキュリティ”というキーワードは、秘匿情報に設定され、秘匿フラグとして“１”が設定される。

このような秘匿データベース７６が作成された後に、図１９を参照して説明するような会話が、リビング２０２で行われた場合、秘匿データベース７６内の情報が更新される。リビング２０２において、ユーザＡが、時刻ｔ１において、“リフォームのことだけど”とユーザＢに対して話しかける。

時刻ｔ２において、ユーザＢは、“費用はわかったけど、どこまでやろうか？”と言う。時刻ｔ３において、ユーザＡは、“お風呂はしたいね”と言う。これに対して、ユーザＢは、情報処理システムに対して“リフォーム会社を探して”と要求を出す。

情報処理システムは、時刻ｔ１から時刻ｔ３までの会話を監視し、“リフォーム”、“風呂”といったキーワードを抽出する。情報処理システムは、リビング２０２でなされた会話から、“リフォーム”というキーワードを抽出したとき、図１８に示した秘匿データベース７６を参照し、既に“リフォーム”というキーワードが書き込まれており、秘匿フラグが“１”である（秘匿情報である）ことを確認する。

“リフォーム”というキーワードは、“リフォーム”というトピックに関連付けられており、“リフォーム”というトピックは、本来、秘匿情報ではないトピックであるが、寝室２０１での会話から抽出されたキーワードであるために、秘匿情報に設定されている。このような状態のとき、“リフォーム”というキーワードが、リビング２０２での会話から抽出された。

リビング２０２での会話は、秘匿情報に該当しなければ、秘匿情報に設定されない。よって、リビング２０２での会話から抽出された“リフォーム”というキーワードは、秘匿情報には設定されない。この場合、秘匿フラグが“１”に設定されていた“リフォーム”というキーワードの秘匿フラグは、“０”、すなわち秘匿情報ではないという情報に更新される。更新された結果、図２０に示したように、“リフォーム”というキーワードの秘匿フラグは、“０”に更新されている。

なおここでは、“リフォーム”というトピックに該当するキーワードが“リフォーム”だけである場合を例に挙げて説明しているため、その“リフォーム”というキーワードに関連付けられている秘匿フラグだけが、“１”から“０”に更新されるとして説明している。

例えば、“リフォーム”というトピックに該当するキーワードが複数あった場合、それら複数のキーワードの秘匿フラグが、一括して変更されるようにしても良い。すなわち、所定の部屋で話された内容は秘匿情報に設定されるが、その内容が、他の部屋で話された場合、秘匿情報ではない情報に一括して変更されるようにしても良い。換言すれば、トピック毎に管理し、トピック単位で、秘匿フラグが変更されるようにしても良い。

秘匿データベース７６には、“風呂”というキーワードも追加登録される。リビング２０２での会話で抽出されたキーワードであるため、秘匿情報に該当しないと判定され、また、トピックも“リフォーム”となるため、秘匿情報に該当しないと判定されるため、秘匿フラグは、“０”に設定される。

このように、会話がなされた場所により、秘匿情報に設定されたキーワードが、秘匿情報に設定しない場所での会話で抽出された場合、秘匿レベルが変更され、秘匿情報ではない情報に設定し直される。

このように、更新が行われることで、“リフォーム”というキーワードは、秘匿情報でなくなる。そこで、時刻ｔ５（図１９）において、情報処理システムは、“お風呂のリフォームに詳しい業者を探します”といった返答を出す。このメッセージには、“風呂”という情報が補足されている。すなわち、“リフォーム”というトピックは、秘匿情報に該当しないため、また、リビング２０２での会話であるため、情報の補足が行われる。

情報処理システムは、外部サービス提供部２１に対して、“お風呂のリフォームに詳しい業者を検索する”という問い合わせを実行する。時刻ｔ６において、情報処理システムは、“近所には３件あります”という検索結果を、ユーザに伝える。

このように、秘匿データベース７６の情報が更新される。

＜声による秘匿＞
秘匿レベルは、声の大きさ（音量）により設定されるようにしても良い。例えば、声が小さい場合、秘匿性の高い話をしている可能性が高いと考えられるため、声が小さい会話から抽出されたキーワードは、秘匿情報として扱われる。

図２１は、リビング２０２でユーザＡとユーザＢが会話している場合を表している。時刻ｔ１において、ユーザＡは、ユーザＢに対して、“リフォームのことだけど”と話しかける。ユーザＢは、時刻ｔ２において、“どの程度やる？セキュリティ強化したいな”と言う。時刻ｔ３において、ユーザＡは、“どれくらいかかるかな”と言う。

時刻ｔ１から時刻ｔ３においてユーザＡとユーザＢとの間でなされた会話は、小声でなされていた（音量が所定値より小さかった）ため、会話は監視し、キーワードを抽出する等の処理は行われるが、秘匿データベース７６には、秘匿情報として登録される（秘匿フラグが１に設定されて登録される）。

時刻ｔ４において、ユーザＢは、情報処理システムに、“リフォームの費用について教えて”と要求を出す。この要求に対して、情報処理システムは、“リフォームの費用を調べます”というメッセージを出す。このとき、情報処理システムは、小声での会話であったため、情報の補足は行わない。

情報処理システムは、外部サービス提供部２１にリフォームの費用について問い合わせを行う。時刻ｔ６において、情報処理システムは、“リフォームの事例は・・・”という検索結果をユーザに伝える。

このように、小声でなされた会話からの情報は、秘匿情報に設定される。時刻ｔ１から時刻ｔ３においてなされたユーザＡとユーザＢとの会話を、情報処理システムは監視しており、その結果、例えば、図１８に示すような秘匿データベース７６が作成される（秘匿データベース７６に情報が追加される）。図１８に示した秘匿データベース７６については、上述したので、ここではその説明は省略する。

このような秘匿データベース７６が作成された後に、図１９を参照して説明するような会話が、リビング２０２で行われた場合、秘匿データベース７６内の情報が更新される。図１９を参照した説明は、上述したので、その詳細な説明は省略する。

情報処理システムは、リビング２０２での時刻ｔ１から時刻ｔ３までの会話を監視し、“リフォーム”、“風呂”といったキーワードを抽出する。この会話は、小声でなされた会話ではないとする。

情報処理システムは、リビング２０２でなされた会話から、“リフォーム”というキーワードを抽出したとき、図１８に示した秘匿データベース７６を参照し、既に“リフォーム”というキーワードが書き込まれており、秘匿フラグが“１”である（秘匿情報である）ことを確認する。

リビング２０２での会話から抽出された“リフォーム”というキーワードは、秘匿情報には設定されない。この場合、秘匿フラグが“１”に設定されていた“リフォーム”というキーワードの秘匿フラグは、“０”、すなわち秘匿情報ではないという情報に更新される。更新された結果、図２０に示したように、“リフォーム”というキーワードの秘匿フラグは、“０”となっている。

小声でなされた会話であったため、秘匿情報に設定された情報（キーワード）が複数あった場合、それら複数のキーワードの秘匿フラグが、一括して変更されるようにしても良い。すなわち、所定の音量以下で話された内容は秘匿情報に設定されるが、その内容が、所定の音量以上で話された場合、秘匿情報ではない情報に一括して変更されるようにしても良い。

このように、会話がなされた声の大きさにより、秘匿情報に設定されたキーワードが、秘匿情報に設定しない声の大きさでの会話で抽出された場合、秘匿レベルが変更され、秘匿情報ではない情報に設定し直される。

このように、更新が行われることで、“リフォーム”というキーワードは、秘匿情報でなくなる。そこで、時刻ｔ５（図１９）において、情報処理システムは、“お風呂のリフォームに詳しい業者を探します”といった返答を出す。このメッセージには、“風呂”という情報が補足されている。

このように、秘匿データベース７６の情報が更新される。

なお、図２１を参照して説明したように、小声で会話されているときであっても、ユーザからの依頼で、明示的に指示が出されたときには、情報の補足が行われ、必要に応じて秘匿情報も用いられ、外部サービス提供部２１への問い合わせが実行されるように構成しても良い。

＜処理フロー＞
上記した処理について、図２２のフローチャートを参照して再度説明する。図２２に示したフローチャートの処理は、情報処理部１２（図６）で主に行われる。

ステップＳ１１において、ユーザ認識部７３は、部屋にいるユーザを検知する。ステップＳ１２において、ユーザ認識部７３は、検知したユーザを、ユーザデータベース７２を参照して識別する。例えば、母親、父親、子供、ゲストといった識別が行われる。

ステップＳ１３において、音声処理部７４は、会話の監視を開始し、会話を検知する。会話が検知された場合、ステップＳ１４において、会話が分析（意味解析）される。会話が分析されることで、キーワードが抽出されたり、そのキーワードを秘匿データベース７６に追加するときのトピックが設定されたりする。

会話が分析される一方で、ユーザ状態解析部７１は、ステップＳ１５において、状況を分析する。例えば、会話が行われている場所（寝室、リビング、玄関など）、会話がなされている声の大きさ（音量）、ユーザの視線（情報処理システムの方に向いているか否かなど）が分析される。

なおこの分析は、必要な分析だけ行われればよい。例えば、図１７や図１９を参照して説明したように、秘匿情報にするか否かの判定の１条件が、会話がなされている部屋に依存する場合、会話が行われている部屋の分析が行われる。

また例えば、図２１を参照して説明したように、秘匿情報にするか否かの判定の１条件が、音量に依存する場合、会話が行われている音量の分析が行われる。また例えば、図１２を参照して説明したように、秘匿情報にするか否かの判定の１条件が、ユーザの視線に依存する場合、会話をしているユーザの視線の分析が行われる。

勿論、これらの複数の条件を考慮して、秘匿情報にするか否かの判定が行われる場合、それぞれの条件に関する判定を行うための情報（状況）が取得され、分析される。

ステップＳ１６において、秘匿情報判定部７７は、秘匿データベース７６を参照する。秘匿データベース７６の参照は、ユーザから何らかの要求、例えば、“何々ついて調べてよ”といったような要求が出されたときに行われる。

ステップＳ１７において、問い合わせ生成部７８は、情報の補足を行うか否かの判定を行う。ステップＳ１７において、情報の補足を行うと判定された場合、ステップＳ１８に処理が進められる。ステップＳ１８において、問い合わせ生成部７８は、情報の補足を行い、外部サービス提供部２１に問い合わせを行う場合に、ユーザへの確認が必要であるか否かを判定する。

例えば、図４を参照して説明したように、秘匿情報に該当する情報を補足する場合、秘匿情報を含む問い合わせをしても良いか否かの確認が、ユーザに対して行われる。そこで、ステップＳ１８において、ユーザへの確認が必要か否かが判定される。

ステップＳ１８において、ユーザへの確認が必要であると判定された場合、ステップＳ２０に処理が進められる。ステップＳ２０において、ユーザへの確認が行われる。例えば、図４を参照した説明では、時刻ｔ２において、“病気についての検索ですが、ガンのステージ３の予後を調べますか？”といった質問文を出すことで、ユーザへの確認が行われた。

ユーザへの確認が行われた結果、外部サービス提供部２１に問い合わせに対する許可が得られたか否かが、ステップＳ２１において判定される。ユーザからの許可、例えば“調べて”といった外部サービス提供部２１に問い合わせを許可する音声が取得された場合、ステップＳ２１において、許可されたと判定され、ステップＳ２２に処理が進められる。

ステップＳ２２において、外部サービス提供部２１への問い合わせが行われる。この場合、ステップＳ１７において、情報を補足すると判定され、ステップＳ１８において、ユーザへの確認が必要であると判定され、ステップＳ２１において、問い合わせの許可が得られたと判定された場合であるため、情報が補足された問い合わせが行われる。

一方、ステップＳ２１において、ユーザからの許可は得られなかったと判定された場合、ステップＳ２２の処理はスキップされ、ステップＳ２３に処理は進められる。すなわち外部サービス提供部２１に問い合わせを行わずに次の処理に移行される。

なお、秘匿情報を除いた問い合わせが行われるようにしても、勿論良い。問い合わせ自体を中止するか、秘匿情報を除いた問い合わせをするかは、問い合わせ内容に依存して決定されるようにしても良い。例えば、秘匿情報を除いた問い合わせでは、情報量が多くなりすぎると判定される場合には、問い合わせ自体が中止される。

また秘匿情報を、秘匿ではない他の情報に置き換えることができると判定されるときには、秘匿ではない他の情報に置き換えた問い合わせが行われるようにしても良い。

一方、ステップＳ１８において、ユーザへの確認は必要ないと判定された場合、ステップＳ２２に処理が進められ、外部サービス提供部２１に問い合わせが実行される。

例えば、図９を参照して説明したように、補足する情報が秘匿情報ではない場合、ユーザへの確認を必要としないため、ユーザへの確認をとらずに、外部サービス提供部２１に問い合わせが実行される。

一方、ステップＳ１７において、情報を補足しないと判定された場合、処理は、ステップＳ１９に進められる。ステップＳ１９において、ユーザへの確認が必要か否かが判定される。例えば、情報の補足はしないが、問い合わせ内容自体に秘匿情報が含まれているような場合に、ステップＳ１９における処理が実行される。

また、会話をしているユーザに、子供が含まれる場合や、ゲストが含まれる場合も、図１５や図１６を参照して説明したように、ユーザへの確認が行われる。なおこの確認は、外部サービス提供部２１に問い合わせをしても良いかの確認も含まれるが、日時や場所などの不足している情報を取得するためのユーザへの確認も含まれる。

ステップＳ１９において、ユーザへの確認が必要であると判定された場合、ステップＳ２０に処理が進められる。ステップＳ２０以降の処理は、上記した場合と同様に行うことが可能なため、その説明は省略する。

一方、ステップＳ１９において、ユーザの確認は、必要ないと判定された場合、ステップＳ２２に処理が進められ、外部サービス提供部２１に問い合わせが実行される。例えば、図３を参照して説明したように、秘匿情報を含まない問い合わせを行うとき、また、不足している情報がなく、ユーザに不足している情報の提供に関する問い合わせを行う必要が無いときには、ユーザへの確認が行われずに外部サービス提供部２１に問い合わせが実行される。

外部サービス提供部２１への問い合わせが行われた場合、その問い合わせ結果は、ユーザに提供される。

ステップＳ２３において、秘匿フラグの変更が必要であるか否かが判定される。例えば、図１９を参照して説明したように、所定の部屋での会話であったため、小声での会話であったためなどのために、秘匿情報に設定されていた情報が、秘匿情報ではないと判定された場合に、秘匿フラグは変更される。

ステップＳ２３において、秘匿フラグの変更が必要であると判定された場合、ステップＳ２４に処理が進められ、秘匿データベース７６内の対応する秘匿フラグが変更される。

一方、ステップＳ２３において、秘匿フラグの変更は必要ない判定された場合、ステップＳ２４の処理はスキップされ、図２２に示したフローチャートの処理は終了される。

情報処理部１２は、このような処理を行う。なおここでの処理の流れは一例であり、各処理が並列的に行われたり、順番が入れ替わって行われたりしても良い。

本技術によれば、プライバシーに係わる情報が、外部にユーザの意図しないときに漏れてしまうようなことを防ぐことが可能となる。また、ユーザが事前に何らかの設定をしなくても、換言すれば、ユーザの手を煩わせることなく、必要に応じて、外部のサービスを利用することができる。

また、外部に問い合わせを行うときの情報の補足なども、ユーザの手を煩わせることなく行うことができる。また、補足する情報は、ユーザの会話（発話）から取得することができるため、ユーザに意識させずに情報を収集することができる。

上記した実施の形態において、秘匿データベース７６に情報が追加されたり、更新されたりしたときには、ユーザに対して、情報が追加されたことや更新されたことを通知するようにしても良い。

上述した実施の形態において、外部サービス提供部２１に問い合わせを実行するとき、情報処理システムは、音声で問い合わせ内容をユーザに知らせたり、問い合わせ結果を知らせたりする例を挙げて説明したが、音声だけでなく、テキストや画像なども用いて知らせるようにしても良い。例えば、ユーザの手元にある端末に、情報が提示されるようにしても良い。

上述した実施の形態において、外部サービス提供部２１に問い合わせが実行されたとき、問い合わせ内容をユーザデータベース７２や秘匿データベース７６に履歴として残しておいても良い。会話の履歴（キーワードなど）と、問い合わせ履歴を関連付けて記憶しておくようにしても良い。

また、そのような履歴は、ユーザにより閲覧、編集できるように構成されていても良い。例えば、ユーザは、会話単位や時間単位で指定して、蓄積されている情報を削除できるようにしても良い。また、秘匿データベース７６に記憶されている情報は、一定時間経過した後、古い順に削除されるようにしても良い。また、予定が終わった時点で、その予定に関連する情報は削除されるようにしても良い。

上述した実施の形態において、会話の監視を開始するタイミングとして、例えば、声の音量が大きく変化したとき、視線が情報処理システム（または予め設定されている方向）に向けられたとき、ユーザから明示的に監視が指示されたときなどとすることができる。

上述した実施の形態において、クラウドサービスを利用した情報の取得や提示などが行われるようにしても良い。例えば、クラウド側に既にある情報も用いられ、上記した秘匿情報とするキーワードであるか否かの判定や、秘匿レベルの設定などがされるようにしても良い。

例えば、ゲストと会話しているときに、ＳＮＳ（Social Networking Service）の情報を用いて、ゲストとの親しさを判定し、親しければ秘匿情報に設定しない、親しくなければ秘匿情報に設定するなどの処理が実行されるようにしても良い。換言すれば、ＳＮＳなどから得られる情報から、秘匿段階を区分し、その区分に基づく処理が行われるようにしても良い。

また例えば、クラウドなどには置いてあるが、かなり特定のメンバーだけに共有されている情報は、外部サービス提供部２１に問い合わせるときに、ユーザに確認するなどの処理が実行されるようにしても良い。

なお、ＳＮＳだけでなく、他人と情報を共有するクラウドサービスの利用状況などが利用されるようにしても良い。

上述した実施の形態を、例えば、ネットワーク接続先との会話に適用することもできる。例えば、遠隔地に住んでいる高齢者と、その高齢者の家族との会話に適用することができる。高齢者側の家の特定の場所、例えば、リビングの特定の壁の近くで高齢者が発話した内容は、家族側の家の特定の場所から、壁を隔てた会話のように家族に伝わるようにしても良い。

またこのようにした場合に、その特定の場所以外からの音は、加工して伝えられるようにすることができる。例えば物音だけでも、高齢者の状態を家族は知ることができ、そのような物音を家族側に伝えることで、家族側は高齢者の安否を知ることができる。

しかしながら、特定の場所以外での高齢者の動作（会話などを含む）は、秘匿したい動作である場合もあり、高齢者のプライバシーを考慮し、特定の場所以外での音は、加工して伝えられる、または全く伝えないようにすることができる。

このようにした場合も、高齢者のプライバシーに関する情報が、家族側に伝えられる可能性がある場合、上記した実施の形態における処理が実行されることで、家族側に伝えられないようにすることができる。よって、このような実施の形態においても、プライバシーを保護することができる。

＜記録媒体について＞
上述した一連の処理は、ハードウエアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウエアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。

図２３は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。例えば、情報処理部１２（図６）を、コンピュータで構成することができる。

コンピュータにおいて、ＣＰＵ（Central Processing Unit）５０１、ＲＯＭ（Read Only Memory）５０２、ＲＡＭ（Random Access Memory）５０３は、バス５０４により相互に接続されている。バス５０４には、さらに、入出力インタフェース５０５が接続されている。入出力インタフェース５０５には、入力部５０６、出力部５０７、記憶部５０８、通信部５０９、及びドライブ５１０が接続されている。

入力部５０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部５０７は、ディスプレイ、スピーカなどよりなる。記憶部５０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部５０９は、ネットワークインタフェースなどよりなる。ドライブ５１０は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブルメディア５１１を駆動する。

以上のように構成されるコンピュータでは、ＣＰＵ５０１が、例えば、記憶部５０８に記憶されているプログラムを、入出力インタフェース５０５及びバス５０４を介して、ＲＡＭ５０３にロードして実行することにより、上述した一連の処理が行われる。

コンピュータ（ＣＰＵ５０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア５１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。

コンピュータでは、プログラムは、リムーバブルメディア５１１をドライブ５１０に装着することにより、入出力インタフェース５０５を介して、記憶部５０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部５０９で受信し、記憶部５０８にインストールすることができる。その他、プログラムは、ＲＯＭ５０２や記憶部５０８に、予めインストールしておくことができる。

なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。

また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。

なお、本明細書に記載された効果はあくまで例示であって限定されるものでは無く、また他の効果があってもよい。

なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。

なお、本技術は以下のような構成も取ることができる。
（１）
ユーザの発話から情報を抽出する抽出部と、
ユーザからの要求があったとき、他の装置に問い合わせを行う問い合わせ部と、
前記問い合わせ部が問い合わせを行うとき、問い合わせ内容に前記抽出部により抽出された前記情報を補足する補足部と
を備える情報処理装置。
（２）
前記補足部で補足される前記情報が、プライバシーに係わる情報であるか否かを判定する判定部をさらに備える
前記（１）に記載の情報処理装置。
（３）
前記抽出部により抽出された前記情報は、プライバシーに係わる情報であるか否かを表すフラグと関連付けられてデータベースに登録される
前記（２）に記載の情報処理装置。
（４）
前記判定部により、前記補足部で補足される前記情報が、プライバシーに係わる情報であると判定された場合、前記問い合わせ部は、プライバシーに係わる情報を含んだ問い合わせを、前記他の装置に行って良いか否かを、ユーザに問い合わせる
前記（２）に記載の情報処理装置。
（５）
前記ユーザにより、前記他の装置に問い合わせを行わないとの指示が出された場合、前記他の装置への問い合わせを中止する、または前記プライバシーに係わる情報を除く問い合わせを行う
前記（４）に記載の情報処理装置。
（６）
前記判定部は、前記情報と、プライバシーに係わる情報であるか否かを表すフラグが関連付けられて記憶されているデータベースを参照して、前記判定を行い、
前記ユーザから前記問い合わせを行って良いとの許可が得られた場合、前記データベース内の前記プライバシーに係わる情報であるとのフラグは、プライバシーに係わる情報ではないとのフラグに更新される
前記（４）に記載の情報処理装置。
（７）
前記発話をしたユーザが判断能力の低いユーザの場合、前記補足部は、前記情報の補足を行わない
前記（１）乃至（６）のいずれかに記載の情報処理装置。
（８）
前記発話をしたユーザが判断能力の低いユーザの場合、前記判断能力の低いユーザの発話からの情報に関連付けられる前記フラグは、プライバシーに係わる情報であることを示すフラグに設定される
前記（３）に記載の情報処理装置。
（９）
前記発話をしたユーザがゲストの場合、前記補足部は、前記情報の補足を行わない
前記（１）乃至（８）のいずれかに記載の情報処理装置。
（１０）
前記発話をしたユーザがゲストの場合、前記ゲストの発話からの情報に関連付けられる前記フラグは、プライバシーに係わる情報であることを示すフラグに設定される
前記（３）に記載の情報処理装置。
（１１）
前記発話が所定のエリアでの発話の場合、前記所定のエリアにおける発話からの情報に関連付けられる前記フラグは、プライバシーに係わる情報であることを示すフラグに設定される
前記（３）に記載の情報処理装置。
（１２）
前記所定のエリアにおける発話からの情報が、前記所定のエリアとは異なるエリアでの発話から得られた場合、前記フラグは、プライバシーに係わる情報ではないことを示すフラグに更新される
前記（１１）に記載の情報処理装置。
（１３）
前記抽出部は、前記ユーザからの指示がなければ、前記発話からの前記情報の抽出を行わない
前記（１）乃至（１２）のいずれかに記載の情報処理装置。
（１４）
前記抽出部は、前記ユーザの発話の音量が一定値以下である場合、前記発話からの前記情報の抽出を行わない
前記（１）乃至（１３）のいずれかに記載の情報処理装置。
（１５）
前記補足部は、前記ユーザの嗜好情報も補足する
前記（１）乃至（１４）のいずれかに記載の情報処理装置。
（１６）
前記補足部は、前記ユーザのスケジュール、友人リストを参照して得られる情報も補足する
前記（１）乃至（１５）のいずれかに記載の情報処理装置。
（１７）
ユーザの発話から情報を抽出し、
ユーザからの要求があったとき、他の装置に問い合わせを行い、
前記問い合わせを行うとき、問い合わせ内容に抽出された前記情報を補足する
ステップを含む情報処理方法。
（１８）
コンピュータに、
ユーザの発話から情報を抽出し、
ユーザからの要求があったとき、他の装置に問い合わせを行い、
前記問い合わせを行うとき、問い合わせ内容に抽出された前記情報を補足する
ステップを含む処理を実行させるためのプログラム。

１１ 情報取得部， １２ 情報処理部， ２１ 外部サービス提供部， ３１ 家庭外ネットワーク， ５１ 音声取得部， ５２ ユーザ状態取得部， ７１ ユーザ状態解析部， ７２ ユーザデータベース， ７３ ユーザ認識部， ７４ 音声処理部， ７５ 秘匿データベース作成部， ７６ 秘匿データベース， ７７ 秘匿情報判定部， ７８ 問い合わせ生成部

Claims (18)

1. ユーザの発話から情報を抽出する抽出部と、
   ユーザからの要求があったとき、他の装置に問い合わせを行う問い合わせ部と、
   前記問い合わせ部が問い合わせを行うとき、問い合わせ内容に前記抽出部により抽出された前記情報を補足する補足部と
   を備える情報処理装置。
2. 前記補足部で補足される前記情報が、プライバシーに係わる情報であるか否かを判定する判定部をさらに備える
   請求項１に記載の情報処理装置。
3. 前記抽出部により抽出された前記情報は、プライバシーに係わる情報であるか否かを表すフラグと関連付けられてデータベースに登録される
   請求項２に記載の情報処理装置。
4. 前記判定部により、前記補足部で補足される前記情報が、プライバシーに係わる情報であると判定された場合、前記問い合わせ部は、プライバシーに係わる情報を含んだ問い合わせを、前記他の装置に行って良いか否かを、ユーザに問い合わせる
   請求項２に記載の情報処理装置。
5. 前記ユーザにより、前記他の装置に問い合わせを行わないとの指示が出された場合、前記他の装置への問い合わせを中止する、または前記プライバシーに係わる情報を除く問い合わせを行う
   請求項４に記載の情報処理装置。
6. 前記判定部は、前記情報と、プライバシーに係わる情報であるか否かを表すフラグが関連付けられて記憶されているデータベースを参照して、前記判定を行い、
   前記ユーザから前記問い合わせを行って良いとの許可が得られた場合、前記データベース内の前記プライバシーに係わる情報であるとのフラグは、プライバシーに係わる情報ではないとのフラグに更新される
   請求項４に記載の情報処理装置。
7. 前記発話をしたユーザが判断能力の低いユーザの場合、前記補足部は、前記情報の補足を行わない
   請求項１に記載の情報処理装置。
8. 前記発話をしたユーザが判断能力の低いユーザの場合、前記判断能力の低いユーザの発話からの情報に関連付けられる前記フラグは、プライバシーに係わる情報であることを示すフラグに設定される
   請求項３に記載の情報処理装置。
9. 前記発話をしたユーザがゲストの場合、前記補足部は、前記情報の補足を行わない
   請求項１に記載の情報処理装置。
10. 前記発話をしたユーザがゲストの場合、前記ゲストの発話からの情報に関連付けられる前記フラグは、プライバシーに係わる情報であることを示すフラグに設定される
    請求項３に記載の情報処理装置。
11. 前記発話が所定のエリアでの発話の場合、前記所定のエリアにおける発話からの情報に関連付けられる前記フラグは、プライバシーに係わる情報であることを示すフラグに設定される
    請求項３に記載の情報処理装置。
12. 前記所定のエリアにおける発話からの情報が、前記所定のエリアとは異なるエリアでの発話から得られた場合、前記フラグは、プライバシーに係わる情報ではないことを示すフラグに更新される
    請求項１１に記載の情報処理装置。
13. 前記抽出部は、前記ユーザからの指示がなければ、前記発話からの前記情報の抽出を行わない
    請求項１に記載の情報処理装置。
14. 前記抽出部は、前記ユーザの発話の音量が一定値以下である場合、前記発話からの前記情報の抽出を行わない
    請求項１に記載の情報処理装置。
15. 前記補足部は、前記ユーザの嗜好情報も補足する
    請求項１に記載の情報処理装置。
16. 前記補足部は、前記ユーザのスケジュール、友人リストを参照して得られる情報も補足する
    請求項１に記載の情報処理装置。
17. ユーザの発話から情報を抽出し、
    ユーザからの要求があったとき、他の装置に問い合わせを行い、
    前記問い合わせを行うとき、問い合わせ内容に抽出された前記情報を補足する
    ステップを含む情報処理方法。
18. コンピュータに、
    ユーザの発話から情報を抽出し、
    ユーザからの要求があったとき、他の装置に問い合わせを行い、
    前記問い合わせを行うとき、問い合わせ内容に抽出された前記情報を補足する
    ステップを含む処理を実行させるためのプログラム。

Images