(57)【要約】      （修正有）【課題】ユーザの状況に応じて、効果的なタイミングで機器に発話させる発話制御装置を実現する。【解決手段】発話制御装置１は、機器２の稼働状況を示す稼働ログを分析して、該機器を使用するユーザの繁忙度を判定する判定部２１と、判定された繁忙度に応じて、上記機器に出力させる音声データの出力タイミングを上記機器に対して指示する出力制御部２２とを備える。【選択図】図１
2017151718.tif 000002
【特許請求の範囲】
【請求項１】
１または複数の機器による音声データの出力を制御する発話制御装置であって、
上記発話制御装置は、以下を含む；
上記機器の稼働状況を示す稼働ログを分析して、該機器を使用するユーザの繁忙度を判定する判定部、
上記判定部によって判定された繁忙度に応じて、上記機器に出力させる音声データの出力タイミングを上記機器に対して指示する出力制御部。
【請求項２】
請求項１に記載の発話制御装置は、以下を含む；
上記判定部は、上記機器から逐次供給される稼働ログに基づいて、上記繁忙度を逐次出力し、
上記出力制御部は、上記判定部によって判定された繁忙度が、多忙な状況を示す値から、該値よりも多忙でない状況を示す値に移行したときに、音声データを出力するように上記機器に指示する。
【請求項３】
請求項１または２に記載の発話制御装置は、以下を含む；
上記出力制御部は、上記判定部によって判定された繁忙度が、多忙な状況を示す値である間、音声データを出力しないように上記機器を制御する。
【請求項４】
請求項３に記載の発話制御装置は、以下を含む；
上記出力制御部は、上記繁忙度が多忙な状況を示す値である間、上記音声データに対して、多忙時でも出力する旨の出力条件が設定されている場合に、該音声データを出力するように上記機器を制御する。
【請求項５】
発話制御装置の指示にしたがい、音声データを出力する機器であって、
上記発話制御装置は、上記機器の稼働状況を示す稼働ログを分析して、該機器を使用するユーザの繁忙度を判定し、判定した繁忙度に応じて、上記機器に出力させる音声データの出力タイミングを上記機器に対して指示するものであり、
上記機器は、以下を含む；
上記発話制御装置に送信する稼働ログを生成する生成部、
上記発話制御装置によって指示されたタイミングで上記音声データを出力する出力部。
【請求項６】
１または複数の機器による音声データの出力を制御する発話制御装置の制御方法であって、
上記発話制御装置の制御方法は、以下を含む；
上記機器の稼働状況を示す稼働ログを分析して、該機器を使用するユーザの繁忙度を判定する判定ステップ、
上記判定ステップで判定された繁忙度に応じて、上記機器に出力させる音声データの出力タイミングを上記機器に対して指示する出力制御ステップ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、音声を出力する機器を制御する発話制御装置に関する。
【背景技術】
【０００２】
機器に音声を出力させる技術が従来知られている。例えば、特許文献１には、表示画面を表示手段に表示するときに、音声案内を出力する電子機器において、表示画面の表示回数およびユーザの操作の有無に応じて、音声出力のタイミングを制御する音声出力制御方法が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１１−４３８９４号公報（２０１１年３月３日公開）
【特許文献２】特開２０１０−１４０２７１号公報（２０１０年６月２４日公開）
【特許文献３】特開２０１０−１１７０９３号公報（２０１０年５月２７日公開）
【特許文献４】特開平５−２４８７５６号公報（１９９３年９月２４日公開）
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上述の従来技術のように、機器に音声を出力させる技術において、音声出力の内容とタイミングとが、ユーザの状況に適合しない場合、機器が出力した音声の内容を、ユーザに確実に伝達できないという問題がある。
【０００５】
例えば、ユーザが忙しくしている状況で、機器が重要度の低い内容に関する音声出力を行っても、ユーザは、その音声を聞き逃したり、真剣に聞かなかったり、さらには、そのような音声の出力に対して不快感を覚えたりするという問題がある。とりわけ、ユーザと機器との間で対話を成立させることを前提として発話させる機器においては、上記問題は特に顕著となる。
【０００６】
そこで、ユーザの状況に応じた効果的なタイミングで、機器に発話させることにより、ユーザに対して発話内容を確実に伝達することが望まれる。ここで、ユーザの状況を推定する技術として、例えば、特許文献２が挙げられる。特許文献２には、ユーザが発する音声、ユーザが操作する操作デバイスの操作履歴、情報処理装置におけるアプリケーション・プログラムの起動操作履歴などに基づいて、ユーザの繁忙度を推定する繁忙度推定装置が開示されている。また、ユーザによる機器の利用状況を推定する技術としては、例えば、特許文献３、４などに開示されているように、冷蔵庫のドアの開閉回数を検出する技術が挙げられる。しかしながら、ユーザの状況に応じて、効果的なタイミングで機器に発話させる、発話制御に係る技術は、従来なかった。
【０００７】
本発明は、上記の問題点に鑑みてなされたものであり、その目的は、ユーザの状況に応じて、効果的なタイミングで機器に発話させる発話制御装置等を実現することにある。
【課題を解決するための手段】
【０００８】
上記の課題を解決するために、本発明の一態様に係る発話制御装置は、１または複数の機器による音声データの出力を制御する発話制御装置であって、上記発話制御装置は、以下を含む；上記機器の稼働状況を示す稼働ログを分析して、該機器を使用するユーザの繁忙度を判定する判定部、上記判定部によって判定された繁忙度に応じて、上記機器に出力させる音声データの出力タイミングを上記機器に対して指示する出力制御部。
【０００９】
上記の課題を解決するために、本発明の一態様に係る発話制御装置の制御方法は、１または複数の機器による音声データの出力を制御する発話制御装置の制御方法であって、上記発話制御装置の制御方法は、以下を含む；上記機器の稼働状況を示す稼働ログを分析して、該機器を使用するユーザの繁忙度を判定する判定ステップ、上記判定ステップで判定された繁忙度に応じて、上記機器に出力させる音声データの出力タイミングを上記機器に対して指示する出力制御ステップ。
【発明の効果】
【００１０】
本発明の一態様によれば、ユーザの状況に応じて、効果的なタイミングで機器に発話させることができ、結果として、ユーザに対して発話内容を確実に伝達することが可能となるという効果を奏する。
【図面の簡単な説明】
【００１１】
【図１】本発明の発話システムおよび該発話システムを構成する各装置の要部構成を示すブロック図である。
【図２】本発明に係る稼働ログＤＢのデータ構造の一具体例を示す図である。
【図３】本発明の実施形態１に係る繁忙度判定ＬＵＴのデータ構造の一具体例を示す図である。
【図４】本発明の実施形態１に係る繁忙度履歴ＤＢのデータ構造の一具体例を示す図である。
【図５】本発明の実施形態１に係る発話データＤＢのデータ構造の一具体例を示す図である。
【図６】本発明の実施形態１に係る発話制御サーバが実行する繁忙度判定の処理の流れを示すフローチャートである。
【図７】本発明の実施形態１に係る発話制御サーバが実行する発話制御の処理の流れを示すフローチャートである。
【図８】本発明の実施形態１に係る発話制御サーバが実行する他の発話制御の処理の流れを示すフローチャートである。
【図９】本発明の実施形態２に係る繁忙度判定ＬＵＴのデータ構造の一具体例を示す図である。
【図１０】本発明の実施形態２に係る発話データＤＢのデータ構造の一具体例を示す図である。
【図１１】本発明の実施形態２に係る発話制御サーバが実行する発話制御の処理の流れを示すフローチャートである。
【図１２】本発明の実施形態２に係る発話制御サーバが実行する他の発話制御の処理の流れを示すフローチャートである。
【図１３】本発明に係る稼働ログＤＢのデータ構造の他の具体例を示す図である。
【図１４】本発明の実施形態３に係る繁忙度判定ＬＵＴのデータ構造の一具体例を示す図である。
【図１５】（ａ）は、本発明の実施形態３に係る繁忙度履歴ＤＢのデータ構造の一具体例を示す図であり、（ｂ）は、時間の区間と稼働ログとの対応関係を説明する図であり、（ｃ）は、繁忙度履歴に係る中間テーブルのデータ構造の一具体例を示す図であり、（ｄ）は、時間の区間と稼働ログとの対応関係について、他の例を説明する図である。
【図１６】本発明の実施形態３に係る発話制御サーバが実行する繁忙度判定の処理の流れを示すフローチャートである。
【図１７】本発明の発話データＤＢのデータ構造の他の具体例を示す図である。
【図１８】図１に示す発話制御サーバまたは家庭内機器として利用可能なコンピュータの構成を例示したブロック図である。
【発明を実施するための形態】
【００１２】
〔実施形態１〕
（発話システムの概要）
以下、本発明の実施の形態について、図１〜図８に基づいて説明すれば、以下のとおりである。図１に、発話システム１００の概要、および、発話システム１００を構成する各装置の要部構成の一例を示す。発話システム１００は、発話制御サーバ１（発話制御装置）と、家庭内機器２（機器）とを含み、これらの装置が連携して、ユーザに対して以下のサービスを提供する。すなわち、発話システム１００において、発話制御サーバ１は、音声入出力機能を備えた家庭内機器２に対して、発話の内容および発話のタイミングを指示する。このように、発話制御サーバ１が家庭内機器２を制御することにより、発話システム１００において、ユーザと家庭内機器２との間での対話を成立させる。
【００１３】
図１に示す例では、１のユーザ宅に設置された１台の家庭内機器２のみを示しているが、これに限らず、発話制御サーバ１は、複数のユーザに対して、その各々の宅に設置された家庭内機器２が発話を実行するように制御することができる。また、発話制御サーバ１は、１のユーザ宅に設置された複数台の家庭内機器２を制御してそれらの家庭内機器２に発話させることができる。説明の簡略化のため、実施形態１では、１のユーザ宅に設置された１台の家庭内機器２に実行させる発話を制御する発話システム１００について説明する。また、実施形態１では、発話制御サーバ１は、家庭内機器２に発話させる内容を含む音声データである発話データを、発話させたい家庭内機器２に供給することにより、家庭内機器２に対して発話の実行を指示する。しかし、これに限らず、発話データは、家庭内機器２がローカルに保持していてもよい。この場合、発話制御サーバ１は、出力させたい発話データを識別する識別情報（発話データＩＤ）を家庭内機器２に送信することにより、家庭内機器２に対して発話の実行を指示する。
【００１４】
上述のとおり、家庭内機器２は、音声入出力機能を備え、ユーザとの対話を実現するものである。具体的には、家庭内機器２は、ユーザが発した音声を入力音声データとして取得して、それを、発話制御サーバ１に送信する。そして、発話制御サーバ１の指示にしたがって、発話制御サーバ１から供給された発話データを音声として出力することにより、ユーザ対して発話を行う。以下では、家庭内機器２のうち、特に、発話制御サーバ１の制御下でユーザに対して発話を実行する家庭内機器２のことを「発話主体機器」と称する。なお、家庭内機器２は、これには限定されないが、例えば、冷蔵庫、電子レンジ、炊飯器、デジタルテレビ、自走式掃除機、空気清浄機、および、洗濯機などの家庭用電子機器である。さらに、本発明に係る発話システム１００において、家庭内機器２は、自機の稼働状況を記録し、記録したデータを「稼働ログ」として、定期的にあるいは発話制御サーバ１からの要求に応じて、発話制御サーバ１に供給する。
【００１５】
発話制御サーバ１は、音声認識機能を備え、家庭内機器２を介して取得された入力音声データを解析し、ユーザの発話に応答するための発話データを家庭内機器２に供給するものである。発話制御サーバ１は、所定のイベントが発生すると、家庭内機器２の方から発話を開始するように、発生したイベントに応じた発話データを家庭内機器２に供給することもできる。さらに、本発明に係る発話制御サーバ１は、家庭内機器２から供給された稼働ログを分析して、家庭内機器２を利用するユーザの忙しさを推定し、忙しさの指数である「繁忙度」を判定する。そして、ユーザの繁忙度に応じて、家庭内機器２に実行させる発話の内容およびタイミングを制御する。以下では、家庭内機器２のうち、特に、ユーザの繁忙度を判定するために分析の対象となる稼働ログを提供する家庭内機器２のことを「繁忙度判定対象機器」と称する。
【００１６】
実施形態１に係る発話システム１００において、１のユーザ宅において、家庭内機器２は、例えば、１台の冷蔵庫２ａである。そして、この冷蔵庫２ａが、発話主体機器かつ繁忙度判定対象機器として機能する。
【００１７】
（家庭内機器の構成）
図１に示すとおり、家庭内機器２は、制御部４０、通信部４１、操作部４２、センサ４３、マイク４４およびスピーカ４５を備える。なお、家庭内機器２の構成において、本発明に直接関係のない部分（例えば、家庭内機器２が冷蔵庫２ａである場合に、庫内に冷気を放出する部分など、家庭内機器２が電子レンジ２ｂである場合に、庫内にて食材を加熱調理する部分など）については、以下の説明およびブロック図１から省略している。通信部４１は、発話制御サーバ１と通信して、上述した各種情報の送受信を行う。
【００１８】
制御部４０は、家庭内機器２の機能を統括して制御する。制御部４０は、稼働ログ生成部５０（生成部）および音声制御部５１（出力部）を含む。音声制御部５１は、音声データに関する処理を行う。具体的には、音声制御部５１は、マイク４４が取得した、ユーザが発した音声を録音し、入力音声データを生成する。また、音声制御部５１は、通信部４１が受信した発話データを処理して、家庭内機器２の発話としての音声をスピーカ４５（出力部）から出力する。
【００１９】
稼働ログ生成部５０は、家庭内機器２の稼働状況を示す稼働ログを生成し、発話制御サーバ１に供給する。稼働ログは、例えば、家庭内機器２のセンサ４３によって得られるセンサ情報、または、操作部４２によって得られる操作ログを含む。具体例を挙げると、家庭内機器２が冷蔵庫２ａである場合、稼働ログ生成部５０は、センサ４３によって検知される冷蔵庫２ａのドアの開閉数をカウントして、開閉日時とともに、図示しない記憶部に記憶しておく。そして、定期的に（例えば、５分おき）に、累積の開閉数（ユーザ宅で使用が開始されてからの総開閉数）を、通信部４１を介して発話制御サーバ１に供給する。例えば、冷蔵庫２ａの場合、センサ４３は、ドアの開閉を検知するセンサである。センサ４３は、ドアが開けられたこと、または、閉じられたことを検知すると、その検知結果を稼働ログ生成部５０に出力する。なお、センサ４３は、明るさセンサ、接触センサなど適宜のセンサで実現される。本実施形態では、稼働ログ生成部５０は、ドアが開けられたことが検知された直後にドアが閉じられたことが検知された場合に、開閉数１回をカウントする。
【００２０】
操作部４２は、ユーザによる入力操作を受け付ける。操作部４２は例えば物理ボタン、タッチパネルなどであり、入力操作を受け付けたことを示す入力信号を、稼働ログ生成部５０および音声制御部５１に出力する。音声制御部５１は当該入力信号を受けて、対話を開始する。音声制御部５１は、ユーザとの対話が開始されるイベントが発生した旨を、発話制御サーバ１に通知し、発話制御サーバ１の制御下で、音声データを入出力して対話を実行する。一方、稼働ログ生成部５０は、入力信号が入力されたことをトリガとして、家庭内機器２が特定の機能を実行した場合に、操作部４２の操作ログにしたがって、家庭内機器２の稼働状況を示す稼働ログを生成する。具体例を挙げると、家庭内機器２が電子レンジ２ｂである場合、稼働ログ生成部５０は、上記入力信号にしたがって電子レンジ２ｂが加熱調理機能の実行を開始した日時と、稼働秒数とを含む稼働ログを生成する。
【００２１】
なお、マイク４４およびスピーカ４５は常に起動された状態であってもよく、所定のイベントが発生したことをトリガとして、家庭内機器２から発話を開始する形で、ユーザとの対話が開始されてもよい。つまり、ユーザが操作部４２に対して対話を開始するための入力操作を行わない構成であってもよい。さらに、家庭内機器２は、図示しないタイマを備えていてもよい。例えば、タイマは、センサ４３が、ユーザの家庭内機器２に対する操作（ドアの開閉など）を検知した時点から計時を開始する。家庭内機器２は、その時点から所定時間が経過するまでの間、マイク４４およびスピーカ４５を起動する構成であってもよいし、音声制御部５１は、上記タイマによる計時期間のみ音声データを入出力する構成であってもよい。これにより、ユーザが家庭内機器２を使用している所定期間に限って、効率よく音声認識処理が実行されるため、家庭内機器２および発話制御サーバ１の処理の負荷を軽減させることができる。
【００２２】
（発話制御サーバの構成）
図１に示すとおり、発話制御サーバ１は、制御部１０、通信部１１および記憶部１２を備える。通信部１１は、家庭内機器２と通信して、上述した各種情報の送受信を行う。制御部１０は、発話制御サーバ１の機能を統括して制御する。制御部１０は、機能ブロックとして、少なくとも、繁忙度判定部２１（判定部）および発話制御部２２（出力制御部）を含み、必要に応じて、稼働ログ処理部２０を含む。機能ブロックの各部については、後に詳述する。
【００２３】
記憶部１２は、発話制御サーバ１が使用する各種データを記憶する。記憶部１２は、稼働ログデータベース（ＤＢ）３０、繁忙度判定ルックアップテーブル（ＬＵＴ）３１、繁忙度履歴データベース（ＤＢ）３２、および、発話データデータベース（ＤＢ）３３を含む。各ＤＢのデータ構造は、別図を参照して詳述する。
【００２４】
稼働ログ処理部２０は、家庭内機器２から供給された稼働ログを処理して、稼働ログＤＢ３０に格納する。繁忙度判定部２１は、稼働ログＤＢ３０に格納された、家庭内機器２の稼働ログを分析し、家庭内機器２を使用しているユーザの繁忙度を判定する。繁忙度の判定の基準は、繁忙度判定ＬＵＴ３１にあらかじめ格納されており、繁忙度判定部２１は、稼働ログの分析結果を、繁忙度判定ＬＵＴ３１と照らし合わせて、繁忙度を判定する。繁忙度判定部２１は、ユーザの繁忙度の判定結果を、時系列で繁忙度履歴ＤＢ３２に格納する。発話制御部２２は、家庭内機器２の発話の内容およびタイミングを制御する。具体的には、発話制御部２２は、繁忙度履歴ＤＢ３２を監視し、繁忙度に変化があったことをトリガとして、家庭内機器２に発話させる発話データを発話データＤＢ３３から取得し、該発話データを出力するように家庭内機器２に指示する。また、その他の所定のイベントの発生をトリガとして、家庭内機器２に発話させる場合に、繁忙度および発話データの属性に応じて、当該発話の実行可否を判断する。
【００２５】
（稼働ログデータベース）
図２を参照して、稼働ログＤＢ３０のデータ構造についてその一例を示す。図２において、稼働ログＤＢ３０のデータ構造をテーブル形式にて示したことは一例であって、当該データ構造を、テーブル形式に限定する意図はない。以降、データ構造を説明するためのその他の図においても同様である。実施形態１では、冷蔵庫２ａの稼働ログ生成部５０は、稼働ログとして、５分おきに、ドアの総開閉数を、発話制御サーバ１に供給する。稼働ログ処理部２０は、稼働ログ生成部５０から取得した稼働ログを処理して、図２に示す稼働ログＤＢ３０に格納する。すなわち、図２に示す稼働ログＤＢ３０は、繁忙度判定対象機器が冷蔵庫２ａである場合の稼働ログのデータベースである。
【００２６】
図２に示すとおり、稼働ログＤＢ３０は、これには限定されないが、例えば、クライアントＩＤ、機器名、稼働情報、日時のカラムを含む。クライアントＩＤは、発話システム１００のサービスを利用する１家庭につき、１つ付与されるものであり、発話制御サーバ１において、サービスの受け手を家庭単位で識別するのに用いられる。実施形態１では、１家庭について、一人のユーザが、また、繁忙度判定対象機器として１台の家庭内機器２（冷蔵庫２ａ）が想定されている。そのため、発話制御サーバ１は、このクライアントＩＤひとつで、サービスの受け手を一意に特定することができる。つまり、実施形態１では、繁忙度判定対象機器を特定するための機器名のカラムは、省略されてもよい。１家庭内に、ユーザが複数いたり、繁忙度判定対象機器としての家庭内機器が複数設けられたりする場合は、ユーザおよび家庭内機器を識別するためのＩＤまたは名前が別途設定される。
【００２７】
稼働情報のカラムは、さらに、総開閉数、および、「５分間の開閉数（開閉数／５分）」のカラムで構成される。総開閉数は、冷蔵庫２ａがユーザ宅で使用が開始されてからカウントされている累積のドアの開閉数であり、冷蔵庫２ａから供給された情報が格納される。５分間の開閉数は、５分間におけるドアの開閉数を指す。実施形態１では、５分おきにドアの総開閉数が冷蔵庫２ａから供給される。よって、今回供給された総開閉数から、前回（つまり５分前に）供給された総開閉数を引くことにより、直近５分間のドアの開閉数が求まる。稼働ログ処理部２０は、冷蔵庫２ａから稼働ログを受信すると、前回（５分前）の稼働ログを参照して、直近５分間のドアの開閉数を算出し、今回供給された総開閉数とともに、稼働情報のカラムに格納する。日時のカラムには、冷蔵庫２ａがその総開閉数を取得したときの日時が格納される。日時の情報は、総開閉数とともに冷蔵庫２ａから供給される。
【００２８】
図２を参照して、例えば、２０１６／１／８の１１：００に取得された総開閉数は、１００５２回であり、その５分後、１１：０５に取得された総開閉数は、１００５６回である。稼働ログ処理部２０は、１００５６回−１００５２回＝４回を、「５分間の開閉数」のカラムの、日時「２０１６／１／８  １１：０５：００」に対応する行に格納する。この行の稼働ログを参照することにより、繁忙度判定部２１は、１１：００から１１：０５までの５分間に、冷蔵庫２ａのドアが４回開け閉めされたと分析することができる。
【００２９】
なお、実施形態１では、冷蔵庫２ａの稼働ログ生成部５０は、ドアの総開閉数を５分おきに発話制御サーバ１に供給する構成であるが、これに限定されない。稼働ログ生成部５０が、直近５分間におけるドアの開閉数を算出して、これを発話制御サーバ１に供給する構成であってもよい。あるいは、稼働ログ生成部５０は、センサ４３によって、「ドアの開き」および「ドアの閉じ」が検知されるたびに、その検知内容および検知日時を発話制御サーバ１に供給する構成であってもよい。この場合、稼働ログ処理部２０は、供給された検知内容および検知日時に基づいて、ドアが開けられて閉められた回数を、５分おきにカウントし、図２に示す稼働ログを生成する。
【００３０】
（繁忙度判定ルックアップテーブル）
図３を参照して、繁忙度判定ＬＵＴ３１のデータ構造についてその一例を示す。実施形態１では、繁忙度判定部２１は、図２に示す稼働ログＤＢ３０が更新されると、更新された稼働ログについて、その日時までの直近５分間におけるユーザの繁忙度を、図３に示す繁忙度判定ＬＵＴ３１を参照することにより判定する。具体的には、繁忙度判定部２１は、５分間の開閉数が、２回以下の場合に、繁忙度「０」と判定し、３回以上の場合に、繁忙度「１」と判定する。ここで、繁忙度「１」は、ユーザが多忙であることを示し、繁忙度「０」は、そうではないことを示す。以下では、ユーザが多忙でないことを、「多忙」に対して、「通常」と表現する。なお、繁忙度判定ＬＵＴ３１に格納される判定基準は、５分間という比較的短い時間に、冷蔵庫２ａの開閉が３回以上も発生すれば、それは、ユーザが調理中などで多忙であろうという推測に基づいている。しかし、判定基準は、図３に示す例に限定されず、開閉数の閾値は、任意の値が設定される。また、開閉数をカウントするために区切る期間は、５分間より短くても長くても構わない。
【００３１】
さらに、多忙な状況下で、どの家庭内機器２をどのように使用するのかは、家庭ごとに異なることが予想される。したがって、繁忙度判定ＬＵＴ３１は、家庭（クライアントＩＤ）ごとに作成されても構わない。
【００３２】
（繁忙度履歴データベース）
図４を参照して、繁忙度履歴ＤＢ３２のデータ構造についてその一例を示す。図４に示すとおり、繁忙度履歴ＤＢ３２は、これには限定されないが、クライアントＩＤ、機器名、繁忙度、日時のカラムを含む。繁忙度判定対象機器が、１つの家庭につき１台しかない場合は、機器名のカラムを省略することができる。繁忙度のカラムには、繁忙度判定部２１によって判定されたユーザの繁忙度が格納される。日時のカラムには、繁忙度を判定するために分析対象となった稼働ログが取得された日時が格納される。実施形態１では、稼働ログＤＢ３０は、５分おきに更新されるので、繁忙度判定部２１は、５分おきに、更新された稼働ログについて、繁忙度を判定し、その繁忙度を繁忙度履歴ＤＢ３２に格納する。図４に示す繁忙度履歴ＤＢ３２を参照すれば、発話制御部２２は、例えば、２０１６／１／８の１１：００から１１：０５までの５分間、および、１１：１０から１１：１５までの５分間、ユーザが多忙であり、それ以外の時間帯は、通常であると認識することができる。
【００３３】
（発話データのデータベース）
図５を参照して、発話データＤＢ３３のデータ構造についてその一例を示す。図５に示すとおり、発話データＤＢ３３は、これには限定されないが、発話データＩＤ、発話主体機器、発話条件（出力条件）、発話データのカラムを含む。発話主体機器が、１つの家庭につき１台しかない場合は、発話主体機器のカラムを省略することができる。発話データのカラムには、家庭内機器２に発話させる内容を示す発話データが格納される。ここに格納される発話データのフォーマットは、音声データであってもよいしテキストデータであってもよい。あるいは、発話データの本体に代えて、当該発話データの格納場所およびファイル名が格納されてもよい。発話データには、発話データＩＤと発話条件とが紐付けられている。
【００３４】
発話データＩＤのカラムには、上記発話データを一意に識別するための識別情報が格納される。発話データＩＤは、発話制御サーバ１と家庭内機器２との間で、共有されるものである。発話条件のカラムには、対応する発話データを家庭内機器２に出力させるための条件が格納される。発話条件が「０」を示す場合、これに対応する発話データは、繁忙度が「０」のとき、つまり、ユーザが多忙でないとき（通常時）に、出力可能であるということを意味する。発話条件が「１→０」を示す場合、これに対応する発話データは、繁忙度が「１」から「０」に変化したとき、つまり、ユーザが多忙な状況から通常の状況に復帰したときに、出力させるべきであるということを意味する。発話条件が「０  ａｎｄ  １」を示す場合、これに対応する発話データは、ユーザの繁忙度によらず、すなわち、多忙な状況にあっても、出力させるべきであるということを意味する。
【００３５】
発話制御部２２は、図５に示す発話データＤＢ３３を参照して、家庭内機器２の発話を制御することができる。詳細には、発話制御部２２は、発話のトリガとなる所定のイベントが発生した場合に、発話主体機器に発話させる発話データに対応付けられている発話条件を参照する。そして、繁忙度履歴ＤＢ３２を参照し、上記発話主体機器のユーザの繁忙度が、上記発話条件を満たすか否かに応じて、上記発話データの出力可否を判断する。さらに、発話制御部２２は、繁忙度履歴ＤＢ３２を監視し、ユーザの繁忙度が変化した場合に、そのタイミングで出力すべき発話データを、発話条件に基づいて発話データＤＢ３３から特定し、発話主体機器に対して発話を指示する。
【００３６】
（処理の流れ）
（１）家庭内機器の稼働ログに基づく繁忙度判定
図６を参照して、実施形態１の発話制御サーバ１が実行する繁忙度判定の処理の流れを説明する。まず、繁忙度判定対象機器としての冷蔵庫２ａが、５分おきに、自機の総開閉数を取得して、取得日時とともに、それを稼働ログとして発話制御サーバ１に供給する。発話制御サーバ１の稼働ログ処理部２０が、供給された稼働ログを処理して図２の稼働ログＤＢ３０に該稼働ログを追加する。これにより、稼働ログＤＢ３０が更新される。
【００３７】
このように稼働ログＤＢ３０が更新されると（Ｓ１０１でＹＥＳ）、繁忙度判定部２１は、追加された最新の稼働ログから、直近５分間の（冷蔵庫２ａのドアの）開閉数を取得する（Ｓ１０２）。繁忙度判定部２１は、図３の繁忙度判定ＬＵＴ３１を参照して、５分間の開閉数が３回以上であれば（Ｓ１０３でＹＥＳ）、冷蔵庫２ａのユーザの繁忙度が１（＝多忙）であると判定し（判定ステップ）、該繁忙度を、日時とともに、図４の繁忙度履歴ＤＢ３２に記録する（Ｓ１０４）。なお、上記日時は、冷蔵庫２ａが総開閉数を取得した取得日時に対応する。一方、５分間の開閉数が３回未満であれば（Ｓ１０３でＮＯ）、上記ユーザの繁忙度が０（＝通常）であると判定し（判定ステップ）、該繁忙度を、日時とともに、繁忙度履歴ＤＢ３２に記録する（Ｓ１０５）。これにより、発話制御部２２は、５分おきにユーザの繁忙度を把握することが可能となる。
【００３８】
（２）繁忙度の変化を発話の条件とする発話制御
図７を参照して、実施形態１に係る発話制御サーバ１が実行する発話制御の処理の流れを説明する。実施形態１では、発話制御サーバ１は、以下の方法で、ユーザの繁忙度が多忙から通常に変化したタイミングで、所定のコメントを発話主体機器に発話させる。
【００３９】
繁忙度判定部２１によって、上述したように繁忙度履歴ＤＢ３２が更新されると（Ｓ２０１でＹＥＳ）、発話制御部２２は、繁忙度履歴ＤＢ３２に記録された最新の履歴を取得する（Ｓ２０２）。図４に示す例では、日時が「２０１６／１／８  １１：３５：００」のレコードを取得する。ここで、取得した履歴の繁忙度が１でない場合（Ｓ２０３でＮＯ）、ユーザの状況は５分より前から通常で維持されていることを意味する。この場合、繁忙度が多忙から通常に変化するタイミングを監視する必要はないので、発話制御部２２は、引き続き、ユーザの繁忙度が多忙に移行するまで繁忙度履歴の監視を継続する。一方、取得した履歴の繁忙度が１である場合（Ｓ２０３でＹＥＳ）、ユーザの状況は現在多忙であることを意味する。この場合、繁忙度が多忙から通常に移行するタイミングを検知するために、繁忙度履歴の監視を継続する（Ｓ２０４）。
【００４０】
繁忙度履歴ＤＢ３２がさらに更新されると（Ｓ２０４でＹＥＳ）、発話制御部２２は、最新の履歴を取得する（Ｓ２０５）。ここで、取得した履歴の繁忙度が０でない場合（Ｓ２０６でＮＯ）、ユーザにおいて多忙な状況が継続していることを意味する。すなわち、繁忙度が多忙から通常に変化したタイミングではないので、発話制御部２２は、引き続き、ユーザの繁忙度が通常に移行するまで繁忙度履歴の監視を継続する。
【００４１】
一方、取得した履歴の繁忙度が０である場合（Ｓ２０６でＹＥＳ）、ユーザの繁忙度が多忙から通常に移行したことを意味する。そのため、発話制御部２２は、図５の発話データＤＢ３３を参照し、発話条件が「１→０（＝繁忙度が多忙から通常に変化したとき）」である発話データを取得する（Ｓ２０７）。最後に、発話制御部２２は、取得した発話データを発話主体機器に送信して（Ｓ２０８）、該発話データの出力を該発話主体機器に指示する（出力制御ステップ）。
【００４２】
ここで、上記発話データは、図５に示す例では、「お料理お疲れ様！」である。このように労をねぎらう発話が、ユーザが多忙な状況から通常の状況に移行したタイミングで出力される。ユーザは、落ち着いた状況で、家庭内機器２による労をねぎらう発話を気分よく受け取ることができる。このように、上記の方法によれば、ユーザの状況に応じた内容の発話を効果的なタイミングで機器に行わせることが可能となり、結果として、発話の内容を確実にユーザに伝達することができる。
【００４３】
（３）多忙時に発話指示を取り下げるための発話制御
図８を参照して、実施形態１の発話制御サーバ１が実行する発話制御の処理の流れを説明する。実施形態１では、発話制御サーバ１は、以下の方法で、発話主体機器に発話させるべき所定のイベント（以下、発話イベント）が発生したとしても、ユーザが多忙である場合には、その発話指示を取り下げる制御を行う。
【００４４】
所定の発話イベント（所定時刻に発話制御サーバ１が家庭内機器２に発話させる“今日のニュース”を受信するなど）が発生すると（Ｓ３０１でＹＥＳ）、発話制御部２２は、図５の発話データＤＢ３３に登録されている発話データの中から、発話イベントに応じた発話データを特定する（Ｓ３０２）。
【００４５】
次に、発話制御部２２は、図４の繁忙度履歴ＤＢ３２から最新の履歴を参照する。最新の履歴におけるユーザの繁忙度が１（＝多忙）である場合（Ｓ３０３でＹＥＳ）、発話制御部２２は、Ｓ３０２で特定した発話データの発話条件が、「多忙時に発話（可）」を示すか否かを判定する（Ｓ３０４）。上記発話条件に基づき、上記発話データが、多忙時に発話可能である場合（Ｓ３０４でＹＥＳ）、発話制御部２２は、上記発話データを発話主体機器に送信し（Ｓ３０５）、発話を指示する。これに対し、上記発話データが、多忙時に発話不可である場合（Ｓ３０４でＮＯ）、発話制御部２２は、上記発話データの出力指示を取り止めて一連の処理を終了する。
【００４６】
一方、最新の履歴におけるユーザの繁忙度が０（＝通常）である場合（Ｓ３０３でＮＯ）、発話制御部２２は、上記発話データを発話主体機器に送信し（Ｓ３０５）、発話を指示する（出力制御ステップ）。なお、実施形態１では、通常時に発話不可となる発話データが存在しないため、発話条件を判定するステップが省略されている。しかし、そのような発話データが存在する場合には、発話条件が「通常時に発話（可）」を示すか否かを判定するステップがＳ３０５の前に追加される。
【００４７】
上記の方法によれば、ユーザが多忙な状況下では、発話イベントが発生したとしても、発話させようとしている発話データの内容が、多忙なユーザに対して出力されるべきでない（出力しても効果が薄い）場合には、その発話データの出力が省略される。これにより、ユーザの状況に合致しない発話を控えることができ、家庭内機器２の発話に対してユーザが不快感を覚えたりするという問題を回避することができる。
【００４８】
なお、発話制御部２２は、図８に示す方法によって、ユーザの多忙時に出力を見合わせた発話データがある場合に、図７に示す方法によって検知された、繁忙度が変化するタイミングで、上記発話データを出力させるように、発話主体機器を制御してもよい。これにより、ユーザの多忙時を避けて通常時に発話されるため、どのような発話内容であってもそれを確実にユーザに伝達することが可能である。したがって、緊急性または重要度の低いコメントについて、発話のタイミングを、これらの方法によって制御することが好ましい。
【００４９】
〔実施形態２〕
本発明の他の実施形態について、図９〜図１２に基づいて説明すれば、以下のとおりである。なお、説明の便宜上、実施形態１にて説明した部材と同じ機能を有する部材については、同じ符号を付記し、その説明を省略する。
【００５０】
実施形態１では、ユーザの繁忙度は、１（多忙）または０（多忙でない、通常）の２値で表現され、２値の情報として取り扱われていた。実施形態２では、ユーザの繁忙度を多値で表現する。以下では、その場合の発話制御サーバ１の構成について説明する。
【００５１】
（繁忙度判定ルックアップテーブル）
図９を参照して、実施形態２の繁忙度判定ＬＵＴ３１のデータ構造についてその一例を示す。図９に示す繁忙度判定ＬＵＴ３１において、図３に示す繁忙度判定ＬＵＴ３１と異なる点は、ユーザの状況が多忙である場合に、その忙しさの程度に応じて、繁忙度を３段階設定している点である。実施形態２では、繁忙度の値が高いほど、多忙であることを意味する。図９に示す例では、繁忙度判定部２１は、５分間の開閉数が、１回以下の場合に、繁忙度「０（＝通常）」と判定し、２回の場合に、繁忙度「１（＝やや多忙）」と判定し、３回の場合に、繁忙度「２（＝多忙）」と判定し、４回以上の場合に、繁忙度「３（＝かなり多忙）」と判定する。
【００５２】
（繁忙度履歴データベース）
実施形態２の繁忙度履歴ＤＢ３２は、図４に示す繁忙度履歴ＤＢ３２と同様のデータ構造を有する。異なる点は、繁忙度のカラムにおける繁忙度が多値であるという点である。実施形態１では、５分おきの冷蔵庫の開閉数、上から順に、０、４、２、５、１、１、０、０回に対して、図４に示す繁忙度判定ＬＵＴ３１の判定基準にしたがって、２値で表現された繁忙度が繁忙度のカラムに格納されている。一方、実施形態２では、上記開閉数に対して、図９に示す繁忙度判定ＬＵＴ３１の判定基準にしたがって、上から順に、０、３、１、３、０、０、０、０の繁忙度の値が入る。
【００５３】
（発話データのデータベース）
図１０を参照して、実施形態２の発話データＤＢ３３のデータ構造についてその一例を示す。図１０に示す発話データＤＢ３３において、図５に示す発話データＤＢ３３と異なる点は、発話条件のカラムが、現繁忙度のカラムと前繁忙度のカラムとによって構成されている点である。なお、実施形態２では、実施形態１と同様に、発話主体機器は、冷蔵庫２ａの１台であるため、発話主体機器のカラムは省略可能である。さらに、実施形態２では、実施形態１と同様に、すべての発話データは、発話制御サーバ１に保持されており、必要に応じて都度、発話制御サーバ１から家庭内機器２に供給される。そのため、機器内蔵データのカラムは省略される。当該カラムの説明は、実施形態４にて詳細に行う。
【００５４】
発話条件のカラムのうち、現繁忙度のカラムには、最新の繁忙度について発話の条件が格納される。一方、前繁忙度のカラムには、上記最新の繁忙度に対応する日時から３０分遡った日時の繁忙度について発話の条件が格納される。例えば、発話データＩＤが「１１」の発話データ「お料理がんばってね」は、最新の繁忙度（現繁忙度）が２以下であり、かつ、その３０分前の繁忙度（前繁忙度）が０である場合に、出力される、あるいは、出力可能となる。このように、発話制御部２２は、図１０に示す発話データＤＢ３３を参照して、ユーザの現繁忙度および前繁忙度が発話条件を満たす発話データについて、これを出力するように、家庭内機器２を制御する。
【００５５】
（処理の流れ）
（１）家庭内機器の稼働ログに基づく繁忙度判定
実施形態２の発話制御サーバ１が実行する繁忙度判定の処理の流れについて、図６を参照して説明する。ここで、実施形態２に係る繁忙度判定処理において、図６に示す実施形態１の繁忙度判定処理と異なるのは、Ｓ１０３〜Ｓ１０５の各ステップである。
【００５６】
繁忙度判定部２１は、図９の繁忙度判定ＬＵＴ３１を参照し、Ｓ１０２にて取得した直近５分間の開閉数が、（Ａ）１回以下、（Ｂ）２回、（Ｃ）３回、および、（Ｄ）４回以上のうち、いずれのケースに該当するかを判断する（図示しないＳ１０３’）。５分間の開閉数が、１回以下の場合（Ｓ１０３’でＡ）、繁忙度判定部２１は、ユーザの繁忙度を０と判定する（図示しないＳ１０４’：判定ステップ）。上記開閉数が、２回の場合（Ｓ１０３’でＢ）、繁忙度判定部２１は、繁忙度を１と判定する（図示しないＳ１０５’：判定ステップ）。上記開閉数が、３回の場合（Ｓ１０３’でＣ）、繁忙度判定部２１は、繁忙度を２と判定する（図示しないＳ１０６’：判定ステップ）。上記開閉数が、４回以上の場合（Ｓ１０３’でＤ）、繁忙度判定部２１は、繁忙度を３と判定する（図示しないＳ１０７’：判定ステップ）。そして、繁忙度判定部２１は、Ｓ１０４’〜Ｓ１０７’にて判定した上記繁忙度を、日時とともに、上述の繁忙度履歴ＤＢ３２に記録する。
【００５７】
（２）繁忙度の推移を発話の条件とする発話制御
図１１を参照して、実施形態２に係る発話制御サーバ１が実行する発話制御の処理の流れを説明する。実施形態２では、発話制御サーバ１は、ユーザの繁忙度の推移に応じて、条件に合致するコメントを発話主体機器に発話させる。
【００５８】
繁忙度判定部２１によって、繁忙度履歴ＤＢ３２が更新されると（Ｓ４０１でＹＥＳ）、発話制御部２２は、繁忙度履歴ＤＢ３２に追加された最新の履歴と、その３０分前に更新された履歴とを取得する（Ｓ４０２）。図４を参考にして、実施形態２では、最新の履歴として、日時が「２０１６／１／８  １１：３５：００」のレコード（繁忙度０）を取得するとともに、３０分前の履歴として、日時が「２０１６／１／８  １１：０５：００」のレコード（実施形態２では、繁忙度３）を取得する。この場合、現繁忙度は０であり、前繁忙度は３である。
【００５９】
続いて、発話制御部２２は、発話データＤＢ３３に記録されている発話データの発話条件を参照し、最新の履歴における現繁忙度および３０分前の履歴における前繁忙度が、発話条件のいずれかに合致するか否かを判定する（Ｓ４０３）。現繁忙度および前繁忙度が、発話データＤＢ３３におけるいずれの発話条件にも合致しない場合（Ｓ４０３でＮＯ）、このことは、今のユーザの状況に合わせて出力すべき発話データがないことを意味する。したがって、発話制御部２２は、繁忙度履歴ＤＢ３２が次に更新されるまで、繁忙度履歴の監視を継続する。
【００６０】
一方、現繁忙度および前繁忙度が、いずれかの発話条件を満たす場合（Ｓ４０３でＹＥＳ）、発話制御部２２は、発話条件が満たされた発話データを発話データＤＢ３３から特定する（Ｓ４０４）。そして、発話制御部２２は、特定した発話データを発話データＤＢ３３から取得し、これを発話主体機器に送信して、発話を指示する（Ｓ４０６：出力制御ステップ）。なお、実施形態２では、Ｓ４０５およびＳ４０７は省略される。これらの各ステップについては実施形態４で詳細に説明する。
【００６１】
上記の方法によれば、ユーザが、通常の状況（前繁忙度０）から、多忙な状況、とりわけ、多忙のピークを迎える前のやや多忙な状況（現繁忙度１〜２）に移行したタイミングで、ユーザを励ます発話（例えば、「お料理がんばってね」）が出力される。ユーザは、これから迎える多忙のピークを前に、落ち着いて、励ましの発話を気分よく受け取ることができる。このように、上記の方法によれば、ユーザの状況に応じた内容の発話を効果的なタイミングで機器に行わせることが可能となり、結果として、ユーザが不快感を覚えることなく、発話の内容を確実にユーザに伝達することができる。
【００６２】
（３）多忙時に発話指示を取り下げるための発話制御
図１２を参照して、実施形態２の発話制御サーバ１が実行する発話制御の処理の流れを説明する。実施形態２では、発話制御サーバ１は、発話イベントが発生したとしても、現繁忙度が発話条件を満たさない場合には、その発話指示を取り下げる制御を行う。
【００６３】
発話イベントが発生すると（Ｓ５０１でＹＥＳ）、発話制御部２２は、図１０の発話データＤＢ３３に登録されている発話データの中から、発話イベントに応じた発話データを特定する（Ｓ５０２）。
【００６４】
次に、発話制御部２２は、図４の繁忙度履歴ＤＢ３２から最新の履歴を参照する。最新の履歴における繁忙度（すなわち、現繁忙度）が、Ｓ５０２で特定された発話データの発話条件を満たすのか否かを判定する（Ｓ５０３）。現繁忙度が、上記発話条件を満たす場合（Ｓ５０３でＹＥＳ）、発話制御部２２は、上記発話データを発話主体機器に送信し（Ｓ５０５）、発話を指示する（出力制御ステップ）。これに対し、現繁忙度が、上記発話条件を満たさない場合（Ｓ５０３でＮＯ）、上記発話データは、今のユーザの状況に合わせて出力すべき発話データではないことを意味する。したがって、発話制御部２２は、上記発話データの出力指示を取り止めて一連の処理を終了する。なお、実施形態２では、Ｓ５０４およびＳ５０６は省略される。これらの各ステップについては実施形態４で詳細に説明する。上記の方法によれば、ユーザの状況に合致しない発話を控えることができ、家庭内機器２の発話に対してユーザが不快感を覚えたりするという問題を回避することができる。
【００６５】
〔実施形態３〕
本発明の他の実施形態について、図１３〜図１６に基づいて説明すれば、以下のとおりである。なお、説明の便宜上、実施形態１および２にて説明した部材と同じ機能を有する部材については、同じ符号を付記し、その説明を省略する。
【００６６】
実施形態１および２では、発話システム１００において、１の家庭に、１台の家庭内機器２が設けられ、それが発話主体機器および繁忙度判定対象機器として機能する構成であった。実施形態３では、発話システム１００において、複数台の家庭内機器２が設けられ（例えば、冷蔵庫２ａおよび電子レンジ２ｂ）、発話制御サーバ１は、それぞれの繁忙度判定対象機器から稼働ログを受け付ける。これにより、発話制御サーバ１は、機器ごとの稼働ログを用いて、ユーザの繁忙度を総合的に判定し、ユーザの忙しさをより精度良く推定することができる。
【００６７】
（稼働ログデータベース）
図１３を参照して、稼働ログＤＢ３０のデータ構造について他の例を示す。実施形態３では、図２に示す冷蔵庫２ａの稼働ログＤＢ３０に加えて、図１３に示す電子レンジ２ｂの稼働ログＤＢ３０が記憶部１２に記憶されている。実施形態３では、電子レンジ２ｂの稼働ログ生成部５０は、稼働ログとして、調理開始の指示が操作部４２を介して入力される度に、指示された操作モードと、指示された調理秒数と、調理を開始した開始日時とを、発話制御サーバ１に供給する。なお、開始日時は、操作部４２である「加熱調理開始」のボタンが押下された日時などである。
【００６８】
図１３に示す稼働ログＤＢ３０において、図２に示す稼働ログＤＢ３０と異なる点は、稼働情報のカラムが、操作モードのカラムおよび調理秒数のカラムによって構成されている点、ならびに、開始日時のカラムには、操作部４２が操作指示を受け付けた日時が格納される点である。なお、操作モードとは、電子レンジ２ｂが実行する調理方法の種類に対応しており、ここでは、例えば、レンジによる加熱（レンジモード）と、オーブンによる加熱（オーブンモード）の２種類があるものとする。
【００６９】
発話制御サーバ１の稼働ログ処理部２０は、家庭内機器２の稼働ログ生成部５０から取得した、操作モード、調理秒数、および調理の開始日時を、クライアントＩＤおよび機器名に対応付けて、図１３に示す稼働ログＤＢ３０に格納する。さらに、稼働ログ処理部２０は、開始日時に調理秒数を加算して、調理の終了日時を求め、これを、稼働ログＤＢ３０に格納してもよい。この場合、稼働ログＤＢ３０には、終了日時のカラムがさらに設けられる。また、稼働ログ処理部２０は、前回の稼働ログにおける調理の終了日時から、今回の稼働ログにおける調理の開始日時までの期間、電子レンジ２ｂが「非稼働」状態であったことを示す稼働ログを生成し、稼働ログＤＢ３０に追加してもよい。この場合、開始日時のカラムには、非稼働状態が開始された日時、すなわち、前回の稼働ログにおける調理の終了日時が格納される。
【００７０】
さらに、稼働ログ処理部２０は、冷蔵庫２ａの場合と同様、電子レンジ２ｂのドアの開閉数を稼働ログとして処理してもよい。また、稼働情報のカラムには、設定温度（オーブンモード時）のカラム、または、出力ワット数（レンジモード時）のカラムが追加されてもよい。これらのカラムは、繁忙度判定部２１がユーザの繁忙度を判定する際に利用しない場合には適宜省略されてもよい。
【００７１】
（繁忙度判定ルックアップテーブル）
図１４を参照して、実施形態３の繁忙度判定ＬＵＴ３１のデータ構造についてその一例を示す。例えば、繁忙度判定部２１は、同図の繁忙度判定ＬＵＴ３１を参照して、電子レンジ２ｂが非稼働中のユーザの繁忙度を０と判定し、電子レンジ２ｂがレンジモードにて加熱調理中の繁忙度を１と判定し、オーブンモードにて加熱調理中の繁忙度を２と判定する。なお、電子レンジ２ｂについてドアの開閉数が、稼働ログとして記憶される場合には、実施形態１と同様に、単位時間あたりのドアの開閉数を稼働条件に含めてもよい。
【００７２】
（繁忙度履歴データベース）
図１５の（ａ）を参照して、実施形態３の繁忙度履歴ＤＢ３２のデータ構造についてその一例を示す。図１５の（ａ）に示す繁忙度履歴ＤＢ３２において、図４に示す繁忙度履歴ＤＢ３２と異なる点は、機器名のカラムに代えて、機器グループＩＤのカラムが含まれている点、および、繁忙度のカラムに代えて、繁忙度合計のカラムが含まれている点である。
【００７３】
機器グループＩＤのカラムには、繁忙度判定対象機器となった複数の家庭内機器２の組み合わせを識別するための機器グループＩＤが格納される。図１５の（ａ）に示す例では、機器グループＩＤ「００１１５０」は、冷蔵庫２ａおよび電子レンジ２ｂを意味する。繁忙度判定対象機器が複数台であっても、機器の組み合わせが冷蔵庫２ａおよび電子レンジ２ｂで固定されている場合には、機器グループＩＤのカラムは省略されてもよい。しかし、繁忙度判定対象機器の組み合わせが、冷蔵庫１台、電子レンジ１台、または、冷蔵庫および電子レンジというように、様々に変更される場合、あるいは、家庭内機器２が３台以上設けられ、繁忙度判定対象機器の組み合わせが様々ある場合、上記機器グループＩＤによって、繁忙度判定対象機器の組み合わせを管理することが望ましい。これにより、どの繁忙度判定対象機器の稼働ログを統合した結果得られた繁忙度合計なのかを明確にできる。
【００７４】
繁忙度合計のカラムには、複数の繁忙度判定対象機器から得られたそれぞれの稼働ログに基づいて算出された繁忙度の合計値が格納される。例えば、図４および図１３に示すとおり、稼働ログの形式は、繁忙度判定対象機器ごとに異なる。そのため、繁忙度判定部２１は、繁忙度をマージするために、それぞれの稼働ログを分析して、形式を統一した上で、繁忙度判定対象機器ごとの繁忙度を算出する。
【００７５】
繁忙度のマージ方法は、これには限定されないが、例えば、以下の方法が挙げられる。実施形態３では、繁忙度合計を５分おきに算出し、これを繁忙度履歴ＤＢ３２に記憶していく。ここで、冷蔵庫２ａの稼働ログは、図４に示すとおり、５分おきに作成される。そのため、繁忙度判定部２１は、稼働ログ（１レコード）ごとに格納された繁忙度を、形式を変換することなく、そのままマージ対象として取り扱うことができる。一方、電子レンジ２ｂの稼働ログは、図１３に示すとおり、１つのレコードが、稼働期間を、調理の開始日時と調理秒数とによって示す形式であり、５分おきに１つのレコードが作成される形式ではない。そのため、繁忙度判定部２１は、電子レンジ２ｂの稼働ログに基づくユーザの繁忙度が、５分おきに判定されるように、電子レンジ２ｂの稼働ログの形式を変換する必要がある。電子レンジ２ｂの繁忙度が５分おきに求まれば、冷蔵庫２ａの繁忙度と統合し、繁忙度合計を算出することが可能となる。
【００７６】
繁忙度判定部２１は、まず、電子レンジ２ｂの稼働状態を示す稼働ログが、５分間隔で刻まれた時間の区間のいずれに該当するのかを決定する。図１３に示す例では、稼働状態を示す稼働ログは、３つある。１つ目の稼働ログにおいて、稼働時間は、２０１６／１／８  １１：１２：１０〜１１：１３：１０であるので、当該稼働ログは、図１５の（ｂ）に示すとおり、１１：１０〜１１：１５の区間に該当する。同様に、２つ目の稼働ログは、１１：１５〜１１：２０の区間に該当し、３つ目の稼働ログは、１１：２５〜１１：３０の区間、および、１１：３０〜１１：３５の区間に該当する。
【００７７】
次に、繁忙度判定部２１は、各区間に含まれている稼働ログと、その操作モードとに基づいて、区間ごとに繁忙度を判定する。図１５の（ｂ）に示すとおり、第１〜第３の区間（１０：５５〜１１：１０）では、稼働状態を示す稼働ログが含まれていないので、これら３つの区間の繁忙度をそれぞれ０と判定する。同様に、第６の区間の繁忙度を０と判定する。第４および第５の区間では、稼働状態（レンジモード）を示す稼働ログが１つずつ含まれているので、これら２つの区間の繁忙度をそれぞれ１と判定する。第７および第８の区間では、稼働状態（オーブンモード）を示す稼働ログが１つずつ含まれているので、これら２つの区間の繁忙度をそれぞれ２と判定する。繁忙度判定部２１は、上述の判定結果を反映した、電子レンジ２ｂの繁忙度履歴の中間テーブルを作成し、繁忙度履歴ＤＢ３２に記憶してもよい。繁忙度履歴の中間テーブルは、図１５の（ｃ）に示すとおり、冷蔵庫２ａに基づく繁忙度履歴ＤＢ３２（図４）と同様に、５分おきに繁忙度が判定された形式を有する。最後に、繁忙度判定部２１は、同じ区間同士の冷蔵庫２ａの繁忙度と、電子レンジ２ｂの繁忙度とを合計し、その繁忙度合計を、該区間に対応する日時と関連付けて、図１５の（ａ）に示す繁忙度履歴ＤＢ３２に格納する。なお、繁忙度判定対象機器ごとに重み付け値が割り当てられていてもよい。この場合、繁忙度判定部２１は、繁忙度を合計する際に、各機器の重み付け係数をそれぞれの繁忙度にかけてから繁忙度を合計する。
【００７８】
なお、図１５の（ｄ）に示すように、稼働状態を示す稼働ログが１つの区間に複数含まれたり、１つの稼働ログが複数の区間にまたがったりすることが想定される。前者の場合、例えば、複数の稼働ログのうち、操作モードに応じて判定された繁忙度が最も高いもの１つ採用して、それを、当該区間の繁忙度とすることが考えられる。具体的には、繁忙度判定部２１は、図１５の（ｄ）における第１の区間について、繁忙度を２と判定する。あるいは、各稼働ログの繁忙度を合算することが考えられる。具体的には、繁忙度判定部２１は、上記第１の区間について、繁忙度を４と判定する。後者の場合、調理開始時点のみが区間に含まれている場合、当該区間における稼働状況を非稼働とみなす。具体的には、繁忙度判定部２１は、図１５の（ｄ）における第２の区間について、繁忙度を０と判定する。区間が調理期間に完全に含まれている場合、当該区間における稼働状況を稼働（オーブンモード）とみなす。具体的には、繁忙度判定部２１は、第３の区間について、繁忙度を２と判定する。調理終了時点のみが区間に含まれている場合、当該区間における稼働状況を稼働とみなす。具体的には、繁忙度判定部２１は、第４の区間について、繁忙度を２と判定する。
【００７９】
（発話データのデータベース）
実施形態３の発話データＤＢ３３は、図１０に示す発話データＤＢ３３と同様のデータ構造を有する。実施形態３では、発話システム１００において発話主体機器は複数あるので、発話データＤＢ３３は発話主体機器のカラムを必ず含む。一方、実施形態１および実施形態２と同様に、実施形態３では、発話データは、発話制御サーバ１から家庭内機器２に供給されるため、機器内蔵データのカラムは省略される。実施形態３において、発話条件のカラムは、最新の履歴における繁忙度合計が現繁忙度のカラムに、その３０分前の履歴における繁忙度合計が前繁忙度のカラムにそれぞれ格納される。
【００８０】
（処理の流れ）
（１）家庭内機器の稼働ログに基づく繁忙度判定
図１６を参照して、実施形態３の発話制御サーバ１が実行する繁忙度判定の処理の流れを説明する。繁忙度履歴ＤＢ３２を更新するタイミングになると、例えば、前回繁忙度履歴を追加してから５分が経過すると（Ｓ６０１でＹＥＳ）、繁忙度判定部２１は、繁忙度合計Ｌを初期化し、繁忙度合計を求める処理を開始する（Ｓ６０２）。図１６に示す例では、まず、繁忙度判定部２１は、直近５分間の冷蔵庫２ａの稼働ログに基づく繁忙度Ｒを判定する（Ｓ６０３：図６参照）。そして、求めたＲをＬに代入する（Ｓ６０４）。続いて、繁忙度判定部２１は、直近５分間の電子レンジ２ｂの稼働ログに基づく繁忙度Ｍを判定する。具体的には、繁忙度判定部２１は、直近５分間の区間に含まれる、稼働ログを取得する（Ｓ６０５）。
【００８１】
上記区間に稼働状態を示す稼働ログが含まれていない場合（Ｓ６０６でＡ）、繁忙度判定部２１は、当該区間において、繁忙度は０（通常）と判定し（Ｓ６０７：判定ステップ）、繁忙度Ｍに０を代入する（Ｓ６０８）。あるいは、上記区間にレンジモードの稼働ログが含まれている場合（Ｓ６０６でＢ）、繁忙度判定部２１は、当該区間において、繁忙度は１（やや多忙）と判定し（Ｓ６０９：判定ステップ）、繁忙度Ｍに１を代入する（Ｓ６１０）。あるいは、上記区間にオーブンモードの稼働ログが含まれている場合（Ｓ６０６でＣ）、繁忙度は２（多忙）と判定し（Ｓ６１１：判定ステップ）、繁忙度Ｍに２を代入する（Ｓ６１２）。なお、繁忙度判定部２１は、電子レンジ２ｂの稼働ログＤＢ３０が更新される度に、図１５の（ｃ）に示す繁忙度履歴の中間テーブルを予め作成しておき、Ｓ６０５にて、該中間テーブルから直近５分間の繁忙度Ｍを取得する構成であってもよい。この場合、Ｓ６０６〜Ｓ６１２の各ステップは省略される。
【００８２】
繁忙度判定部２１は、Ｓ６０３で判定した冷蔵庫２ａの繁忙度Ｒと、Ｓ６０６〜Ｓ６１２で判定した電子レンジ２ｂの繁忙度Ｍとを合計して、直近５分間の繁忙度合計Ｌを求める（Ｓ６１３）。繁忙度判定部２１は、得られた繁忙度合計Ｌを、Ｓ６０１における更新タイミングの日時と関連付けて、図１５の（ａ）に示す繁忙度履歴ＤＢ３２に記録する（Ｓ６１４）。上記の方法によれば、１の家庭において家庭内機器２が複数設けられている場合に、それぞれの家庭内機器２の稼働ログを統合して、ユーザの繁忙度を判定することが可能となる。
【００８３】
なお、実施形態３において、（２）繁忙度の推移を発話の条件とする発話制御は、図１１を参照して、実施形態２と略同様に実施される。また、（３）多忙時に発話指示を取り下げるための発話制御は、図１２を参照して、実施形態２と略同様に実施される。すなわち、冷蔵庫２ａの繁忙度に代えて、冷蔵庫２ａおよび電子レンジ２ｂの繁忙度合計に基づいて発話制御が実施される。
【００８４】
〔実施形態４〕
本発明の他の実施形態について説明すれば、以下のとおりである。なお、説明の便宜上、実施形態１〜３にて説明した部材と同じ機能を有する部材については、同じ符号を付記し、その説明を省略する。
【００８５】
実施形態１〜３では、発話システム１００において、発話データは、発話制御サーバ１の記憶部１２に記憶されている。そのため、発話制御サーバ１は、出力させたい発話データを、必要に応じて都度家庭内機器２に供給することにより、家庭内機器２に対して発話の実行を指示する構成であった。また、上記に代えて、発話データは、家庭内機器２によってローカルに保持されていてもよい。この場合、発話制御サーバ１は、出力させたい発話データを識別する発話データＩＤを家庭内機器２に送信することにより、家庭内機器２に対して発話の実行を指示する構成であった。
【００８６】
実施形態４では、発話システム１００において、発話データは、発話制御サーバ１の記憶部１２に記憶されているものもあれば、家庭内機器２がローカルに保持しているものもある。そのため、発話制御サーバ１は、家庭内機器２に出力させたい発話データが、自機に記憶されているものか、家庭内機器２に記憶されているものかに応じて、発話の指示の仕方を変更するための構成を有する。
【００８７】
（発話データのデータベース）
実施形態４に係る発話データＤＢ３３は、図１０に示す機器内蔵データのカラムを必ず含む。実施形態１では、図１０と同様に、図５に示す発話データＤＢ３３がさらに、機器内蔵データのカラムを含む。機器内蔵データのカラムには、その発話データが、発話制御サーバ１に保持されているものか、家庭内機器２に保持されているものかを示す情報が格納される。図１０に示す例では、「１」は、家庭内機器２にローカルに保持されている発話データを示し、「０」は、家庭内機器２に保持されていない、すなわち、発話制御サーバ１から供給しなければならない発話データを示す。
【００８８】
（処理の流れ）
実施形態２または３の変形例として、実施形態４では、図１１に示す、Ｓ４０５〜Ｓ４０７が、発話制御部２２によって省略されずに実行される。すなわち、発話制御部２２は、Ｓ４０４で特定された発話データに対応する機器内蔵データのフラグが「０」を示す場合には（Ｓ４０５でＮＯ）、発話制御サーバ１の記憶部１２に記憶されている発話データを取得し、これを発話主体機器に送信することで、発話を指示する（Ｓ４０６）。一方、上記フラグが「１」を示す場合には（Ｓ４０５でＹＥＳ）、上記発話データを識別するための発話データＩＤを発話主体機器に送信することで、発話を指示する（Ｓ４０７）。同様に、実施形態２または３の変形例として、実施形態４では、さらに、図１２に示す、Ｓ５０４〜Ｓ５０６が、発話制御部２２によって省略されずに実行される。また、実施形態１の変形例として、実施形態４では、図７のＳ２０８、および、図８のＳ３０５に代えて、Ｓ４０５〜Ｓ４０７の各ステップが実行される。
【００８９】
〔変形例〕
実施形態３に実施形態１を組み合わせた発話システム１００も本発明の技術的範囲に含まれる。すなわち、１の家庭において、複数の家庭内機器２が設けられている場合に、それぞれの稼働ログに基づく繁忙度を０（通常）と１（多忙）との２値で表現してもよい。この場合、繁忙度判定部２１は、稼働条件（図１４）が、レンジモードおよびオーブンモードのいずれでも繁忙度を１と判定するように構成することが考えられる。
【００９０】
実施形態３、すなわち、家庭内機器２が複数設けられる場合は、繁忙度判定対象機器と、発話主体機器とは、一致してもよいし、一致しなくてもよい。また、発話主体機器が複数台ある場合に、繁忙度判定対象機器は１台であっても構わない。例えば、発話制御部２２は、冷蔵庫２ａの稼働ログに基づいて繁忙度を判定し、その繁忙度に応じて、電子レンジ２ｂの発話を制御してもよい。あるいは、冷蔵庫２ａおよび電子レンジ２ｂの稼働ログに基づいて繁忙度合計を求め、それに応じて、炊飯器の発話を制御してもよい。
【００９１】
さらに、発話制御サーバ１の発話制御部２２は、発話タイミングに加えて、ユーザの繁忙度に応じて、発話主体機器を制御してもよい。例えば、発話制御部２２は、ユーザが多忙でないときには、リビングに設置されているテレビを発話主体機器として選択し、ユーザが多忙なときには、キッチンに設置されている冷蔵庫を発話主体機器として選択するように構成されていてもよい。
【００９２】
図１７を参照して、本変形例の発話データＤＢ３３のデータ構造についてその一例を示す。図１７に示す発話データＤＢ３３において、図１０に示す発話データＤＢ３３と異なる点は、１つの発話データに対して、発話条件ごとに、異なる発話主体機器が関連付けられている点である。例えば、図１７に示す発話データＤＢ３３によれば、“家族からの伝言”を伝える発話データは、ユーザの繁忙度に応じて、発話主体機器が異なる。ユーザの繁忙度（現繁忙度）が、１以上である（前繁忙度は任意でよい）場合、発話制御部２２は、“家族からの伝言”の発話主体機器として、冷蔵庫を選択する。一方、ユーザの繁忙度が０である場合、発話制御部２２は、上記発話データの発話主体機器として、テレビを選択する。このように、ユーザがどういう状況のときに、どの家庭内機器２を使っているか（傍に居るか）を推測し、繁忙度と発話主体機器とを対応させた発話データＤＢ３３を作成しておくことにより、発話データの内容を、より確実にユーザに伝達することが可能となる。とりわけ、緊急度または重要度がそれほど高くない発話内容に関して、すべての発話主体機器に同時に同内容を発話させることが、ユーザの利便性および実用性の観点から好ましくない場合には、上述のように、ユーザが傍に居そうな家庭内機器２を１つ選択して、その家庭内機器２に発話させる構成を、好適に用いることができる。
【００９３】
なお、本変形例では、図１１に示すフローチャートを参照して、発話制御部２２は、Ｓ４０６またはＳ４０７で、以下の処理を実行する。すなわち、発話制御部２２は、Ｓ４０４にて特定された発話データに関連付けられている発話主体機器宛てに、発話データまたは発話データＩＤを送信して発話を指示する。本変形例では、発話条件のうち、前繁忙度は任意でよいので、Ｓ４０２およびＳ４０３において、前繁忙度を取り扱う処理は省略されてもよい。
【００９４】
〔実施形態５〕
上記各実施形態では、１つの発話制御サーバ１を用いる例を説明したが、発話制御サーバ１の有する各機能が、個別のサーバにて実現されていてもよい。そして、複数のサーバを適用する場合においては、各サーバは、同じ事業者によって管理されていてもよいし、異なる事業者によって管理されていてもよい。
【００９５】
〔実施形態６〕
発話制御サーバ１および家庭内機器２の各ブロック（発話制御サーバ１の稼働ログ処理部２０、繁忙度判定部２１および発話制御部２２、ならびに、家庭内機器２の稼働ログ生成部５０および音声制御部５１）は、集積回路（ＩＣチップ）等に形成された論理回路（ハードウェア）によって実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェアによって実現してもよい。後者の場合、発話制御サーバ１および家庭内機器２のそれぞれを、図１８に示すようなコンピュータ（電子計算機）を用いて構成することができる。
【００９６】
図１８は、発話制御サーバ１または家庭内機器２として利用可能なコンピュータ９１０の構成を例示したブロック図である。コンピュータ９１０は、バス９１１を介して互いに接続された演算装置９１２と、主記憶装置９１３と、補助記憶装置９１４と、入出力インターフェース９１５と、通信インターフェース９１６とを備えている。演算装置９１２、主記憶装置９１３、および補助記憶装置９１４は、それぞれ、例えばＣＰＵ、ＲＡＭ（random access memory）、ハードディスクドライブであってもよい。入出力インターフェース９１５には、ユーザがコンピュータ９１０に各種情報を入力するための入力装置９２０、および、コンピュータ９１０がユーザに各種情報を出力するための出力装置９３０が接続される。入力装置９２０および出力装置９３０は、コンピュータ９１０に内蔵されたものであってもよいし、コンピュータ９１０に接続された（外付けされた）ものであってもよい。例えば、入力装置９２０は、キーボード、マウス、タッチセンサなどであってもよく、出力装置９３０は、ディスプレイ、プリンタ、スピーカなどであってもよい。また、タッチセンサとディスプレイとが一体化されたタッチパネルのような、入力装置９２０および出力装置９３０の双方の機能を有する装置を適用してもよい。そして、通信インターフェース９１６は、コンピュータ９１０が外部の装置と通信するためのインターフェースである。
【００９７】
補助記憶装置９１４には、コンピュータ９１０を発話制御サーバ１または家庭内機器２として動作させるための各種のプログラムが格納されている。そして、演算装置９１２は、補助記憶装置９１４に格納された上記プログラムを主記憶装置９１３上に展開して該プログラムに含まれる命令を実行することによって、コンピュータ９１０を、発話制御サーバ１または家庭内機器２が備える各部として機能させる。なお、補助記憶装置９１４が備える、プログラム等の情報を記録する記録媒体は、コンピュータ読み取り可能な「一時的でない有形の媒体」であればよく、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブル論理回路などであってもよい。
【００９８】
また、上記プログラムは、コンピュータ９１０の外部から取得してもよく、この場合、任意の伝送媒体（通信ネットワークや放送波等）を介して取得してもよい。そして、本発明は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
【００９９】
〔まとめ〕
本発明の態様１に係る発話制御装置（発話制御サーバ１）は、１または複数の機器（家庭内機器２）による音声データ（発話データ）の出力を制御する発話制御装置であって、上記発話制御装置は、以下を含む；上記機器の稼働状況を示す稼働ログを分析して、該機器を使用するユーザの繁忙度を判定する判定部（繁忙度判定部２１）、上記判定部によって判定された繁忙度に応じて、上記機器に出力させる音声データの出力タイミングを上記機器に対して指示する出力制御部（発話制御部２２）。
【０１００】
上記の構成によれば、判定部は、機器がユーザの使用によって稼働している状況を、機器が提供する稼働ログを分析することにより認識し、ユーザの繁忙度を判定する。そして、出力制御部は、ユーザの繁忙度に応じて、音声データの出力タイミングを機器に対して指示する。これにより、ユーザの状況に応じて、効果的なタイミングで機器に発話させることができ、結果として、ユーザに対して発話内容を確実に伝達することが可能となる。
【０１０１】
本発明の態様２に係る発話制御装置は、上記態様１において、以下を含む；上記判定部は、上記機器から逐次供給される稼働ログ（稼働ログＤＢ３０）に基づいて、上記繁忙度を逐次出力し（繁忙度履歴ＤＢ３２）、上記出力制御部は、上記判定部によって判定された繁忙度が、多忙な状況を示す値（繁忙度１、繁忙度１〜３）から、該値よりも多忙でない状況を示す値（繁忙度０、繁忙度０〜２）に移行したときに、音声データを出力するように上記機器に指示する。
【０１０２】
上記の構成によれば、ユーザの繁忙度は逐次出力される。そして、音声データは、ユーザの繁忙度が多忙な状況示す値から多忙でない状況を示す値に移行したタイミングで出力される。つまり、ユーザの多忙な状況が終了したタイミングで出力される。そして、該音声データは、例えば、「お料理お疲れ様！」などの労をねぎらう発話であることが想定される。よって、ユーザは、落ち着いた状況で、機器から出力される労をねぎらう発話を気分よく受け取ることができる。このように、ユーザの状況に応じて、効果的なタイミングで機器に発話させることができ、結果として、ユーザに対して発話内容を確実に伝達することが可能となる。
【０１０３】
本発明の態様３に係る発話制御装置は、上記態様１または２において、以下を含む；上記出力制御部は、上記判定部によって判定された繁忙度が、多忙な状況を示す値である間、音声データを出力しないように上記機器を制御する。上記の構成によれば、ユーザが多忙な状況下では、機器に出力させたい音声データの内容が、多忙なユーザに対して出力されるべきでない（出力しても効果が薄い）場合には、その音声データは出力されない。これにより、ユーザの状況に合致しない発話を控えることができ、機器の発話に対してユーザが不快感を覚えたりするという問題を回避することができる。
【０１０４】
本発明の態様４に係る発話制御装置は、上記態様３において、以下を含む；上記出力制御部は、上記繁忙度が多忙な状況を示す値である間、上記音声データに対して、多忙時でも出力する旨の出力条件（発話条件）が設定されている場合に、該音声データを出力するように上記機器を制御する。上記音声データは、例えば、家族からの伝言であったり、緊急地震速報であったりすることが想定される。よって、機器は、ユーザが多忙であっても、重要度または緊急性の高いコメントを遅滞なく、省略することなく、ユーザに確実に伝達することができる。
【０１０５】
本発明の態様５に係る機器は、発話制御装置の指示にしたがい、音声データを出力する機器であって、上記発話制御装置は、上記機器の稼働状況を示す稼働ログを分析して、該機器を使用するユーザの繁忙度を判定し、判定した繁忙度に応じて、上記機器に出力させる音声データの出力タイミングを上記機器に対して指示するものであり、上記機器は、以下を含む；上記発話制御装置に送信する稼働ログを生成する生成部（稼働ログ生成部５０）、上記発話制御装置によって指示されたタイミングで上記音声データを出力する出力部（音声制御部５１、スピーカ４５）。上記の構成によれば、請求項１と同様の効果を奏する。
【０１０６】
本発明の態様６に係る発話制御装置の制御方法は、１または複数の機器による音声データの出力を制御する発話制御装置の制御方法であって、上記発話制御装置の制御方法は、以下を含む；上記機器の稼働状況を示す稼働ログを分析して、該機器を使用するユーザの繁忙度を判定する判定ステップ（Ｓ１０３〜Ｓ１０５、Ｓ６０６〜Ｓ６１２）、上記判定ステップで判定された繁忙度に応じて、上記機器に出力させる音声データの出力タイミングを上記機器に対して指示する出力制御ステップ（Ｓ２０８、Ｓ３０５、Ｓ４０６、Ｓ４０７、Ｓ５０５、Ｓ５０６）。上記の方法によれば、請求項１と同様の効果を奏する。
【０１０７】
本発明の態様７に係る発話制御装置では、上記態様１〜４において、上記判定部は、上記複数の機器のそれぞれの稼働ログを分析して、機器ごとに求めた繁忙度を統合した繁忙度合計を出力し、上記出力制御部は、上記繁忙度合計に応じて、上記機器に出力される音声データの出力タイミング（発話タイミング）を制御する。
【０１０８】
本発明の態様８に係る発話制御装置では、上記態様１〜４において、上記出力制御部は、上記繁忙度に応じて、音声データを出力する機器を選択する。
【０１０９】
本発明の態様９に係る発話制御装置では、上記態様１において、ユーザの最新の繁忙度（現繁忙度）と、該最新の繁忙度が判定された時点より所定時間前に判定された過去の繁忙度（前繁忙度）との両方が、所定の条件を満たすときに、音声データを出力するように上記機器に指示する。
【０１１０】
本発明の各態様に係る発話制御装置および機器は、コンピュータによって実現してもよく、この場合には、コンピュータを上記発話制御装置または機器が備える各部（ソフトウェア要素）として動作させることにより上記発話制御装置または機器をコンピュータにて実現させる上記発話制御装置または機器の制御プログラム、およびそれを記録したコンピュータ読み取り可能な記録媒体も、本発明の範疇に入る。
【０１１１】
本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。さらに、各実施形態にそれぞれ開示された技術的手段を組み合わせることにより、新しい技術的特徴を形成することができる。
【符号の説明】
【０１１２】
１  発話制御サーバ（発話制御装置）
２  家庭内機器（機器）
２ａ  冷蔵庫（機器）
２ｂ  電子レンジ（機器）
１０  制御部
１１  通信部
１２  記憶部
２０  稼働ログ処理部（処理部）
２１  繁忙度判定部（判定部）
２２  発話制御部（出力制御部）
４０  制御部
４１  通信部
４２  操作部
４３  センサ
４４  マイク
４５  スピーカ（出力部）
５０  稼働ログ生成部（生成部）
５１  音声制御部（出力部）
１００  発話システム
【図１】
2017151718.tif 000003
【図２】
2017151718.tif 000004
【図３】
2017151718.tif 000005
【図４】
2017151718.tif 000006
【図５】
2017151718.tif 000007
【図６】
2017151718.tif 000008
【図７】
2017151718.tif 000009
【図８】
2017151718.tif 000010
【図９】
2017151718.tif 000011
【図１０】
2017151718.tif 000012
【図１１】
2017151718.tif 000013
【図１２】
2017151718.tif 000014
【図１３】
2017151718.tif 000015
【図１４】
2017151718.tif 000016
【図１５】
2017151718.tif 000017
【図１６】
2017151718.tif 000018
【図１７】
2017151718.tif 000019
【図１８】
2017151718.tif 000020