IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社ユピテルの特許一覧 ▶ 株式会社YPKの特許一覧

<>
  • 特許-装置及びプログラム等 図1
  • 特許-装置及びプログラム等 図2
  • 特許-装置及びプログラム等 図3
  • 特許-装置及びプログラム等 図4
  • 特許-装置及びプログラム等 図5
  • 特許-装置及びプログラム等 図6
  • 特許-装置及びプログラム等 図7
  • 特許-装置及びプログラム等 図8
  • 特許-装置及びプログラム等 図9
  • 特許-装置及びプログラム等 図10
  • 特許-装置及びプログラム等 図11
  • 特許-装置及びプログラム等 図12
  • 特許-装置及びプログラム等 図13
  • 特許-装置及びプログラム等 図14
  • 特許-装置及びプログラム等 図15
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-12-22
(45)【発行日】2024-01-05
(54)【発明の名称】装置及びプログラム等
(51)【国際特許分類】
   G06F 3/16 20060101AFI20231225BHJP
   G10L 15/32 20130101ALI20231225BHJP
   G10L 15/30 20130101ALI20231225BHJP
   G10L 15/22 20060101ALI20231225BHJP
【FI】
G06F3/16 650
G10L15/32 220Z
G10L15/30
G10L15/22 300Z
G06F3/16 630
G06F3/16 690
【請求項の数】 10
(21)【出願番号】P 2022129500
(22)【出願日】2022-08-16
(62)【分割の表示】P 2018006267の分割
【原出願日】2018-01-18
(65)【公開番号】P2022169645
(43)【公開日】2022-11-09
【審査請求日】2022-09-13
(73)【特許権者】
【識別番号】391001848
【氏名又は名称】株式会社ユピテル
(73)【特許権者】
【識別番号】508320239
【氏名又は名称】株式会社ユピテル鹿児島
(72)【発明者】
【氏名】水野 隆之
(72)【発明者】
【氏名】島津江 幹雄
(72)【発明者】
【氏名】梶田 裕一
(72)【発明者】
【氏名】清水 勇喜
(72)【発明者】
【氏名】和田 昌浩
(72)【発明者】
【氏名】高橋 圭三
(72)【発明者】
【氏名】高橋 慶介
【審査官】田川 泰宏
(56)【参考文献】
【文献】国際公開第2016/105916(WO,A1)
【文献】特開2005-242243(JP,A)
【文献】特表2015-528140(JP,A)
【文献】特開2011-090100(JP,A)
【文献】特開2006-172110(JP,A)
【文献】特表2005-535012(JP,A)
【文献】特開2014-013569(JP,A)
【文献】米国特許第06944592(US,B1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 3/16
G10L 15/32
G10L 15/30
G10L 15/22
(57)【特許請求の範囲】
【請求項1】
入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバに対して音声認識に基づく文字列を前記入力文字列として送信し、前記異なる複数のサーバから前記出力文字列として出力された文字列を受信し、前記異なる複数のサーバから受信した前記出力文字列として出力された文字列に基づいてユーザー又は他の機器の少なくともいずれか一方への出力情報の出力をすることでユーザー又は他の機器と対話させる機能を有し、
前記異なる複数のサーバから前記出力文字列として出力された文字列を受信し、語尾に疑問符がついた前記出力文字列を選択して対話させる機能を有することを特徴とする装置。
【請求項2】
入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバに対して音声認識に基づく文字列を前記入力文字列として送信し、前記異なる複数のサーバから前記出力文字列として出力された文字列を受信し、前記異なる複数のサーバから受信した前記出力文字列として出力された文字列に基づいてユーザー又は他の機器の少なくともいずれか一方への出力情報の出力をすることでユーザー又は他の機器と対話させる機能を有し、
前記異なる複数のサーバから前記出力文字列として出力された文字列を受信し、肯定文を組み合わせた後に疑問文を組み合わせて対話させる機能を有することを特徴とする装置。
【請求項3】
入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバに対して音声認識に基づく文字列を前記入力文字列として送信し、前記異なる複数のサーバから前記出力文字列として出力された文字列を受信し、前記異なる複数のサーバから受信した前記出力文字列として出力された文字列に基づいてユーザー又は他の機器の少なくともいずれか一方への出力情報の出力をすることでユーザー又は他の機器と対話させる機能を有し、
前記異なる複数のサーバから前記出力文字列として出力された文字列を受信し、話題転換した文字列を最後に配置するように組み合わせて対話させる機能を有することを特徴とする装置。
【請求項4】
入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバに対して音声認識に基づく文字列を前記入力文字列として送信し、前記異なる複数のサーバから前記出力文字列として出力された文字列を受信し、前記異なる複数のサーバから受信した前記出力文字列として出力された文字列に基づいてユーザー又は他の機器の少なくともいずれか一方への出力情報の出力をすることでユーザー又は他の機器と対話させる機能を有し、
前記異なる複数のサーバから前記出力文字列として出力された文字列を受信し、フレンドリーな前記出力文字列を初めに配置するように組み合わせて対話させる機能を有することを特徴とする装置。
【請求項5】
入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバに対して音声認識に基づく文字列を前記入力文字列として送信し、前記異なる複数のサーバから前記出力文字列として出力された文字列を受信し、前記異なる複数のサーバから受信した前記出力文字列として出力された文字列に基づいてユーザー又は他の機器の少なくともいずれか一方への出力情報の出力をすることでユーザー又は他の機器と対話させる機能を有し、
前記異なる複数のサーバから前記出力文字列として出力された文字列を受信し、それらをランダムな順で組み合わせて対話させる機能を有することを特徴とする装置。
【請求項6】
入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバに対して音声認識に基づく文字列を前記入力文字列として送信し、前記異なる複数のサーバから前記出力文字列として出力された文字列を受信し、前記異なる複数のサーバから受信した前記出力文字列として出力された文字列に基づいてユーザー又は他の機器の少なくともいずれか一方への出力情報の出力をすることでユーザー又は他の機器と対話させる機能を有し、
前記異なる複数のサーバから前記出力文字列として出力された文字列を受信し、それらの内に顔文字を含む前記出力文字列がある場合には、対話対象とせず、表示部には対話対象とされた前記出力文字列と一緒に表示させる機能を有することを特徴とする装置。
【請求項7】
入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバに対して音声認識に基づく文字列を前記入力文字列として送信し、前記異なる複数のサーバから前記出力文字列として出力された文字列を受信し、前記異なる複数のサーバから受信した前記出力文字列として出力された文字列に基づいてユーザー又は他の機器の少なくともいずれか一方への出力情報の出力をすることでユーザー又は他の機器と対話させる機能を有し、
前記異なる複数のサーバから前記出力文字列として出力された文字列を受信し、同じ文字列が含まれる前記出力文字列同士についてはいずれか1つのみを選択して他の前記出力文字列と組み合わせて対話させる機能を有することを特徴とする装置。
【請求項8】
入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバに対して音声認識に基づく文字列を前記入力文字列として送信し、前記異なる複数のサーバから前記出力文字列として出力された文字列を受信し、前記異なる複数のサーバから受信した前記出力文字列として出力された文字列に基づいてユーザー又は他の機器の少なくともいずれか一方への出力情報の出力をすることでユーザー又は他の機器と対話させる機能を有し、
前記異なる複数のサーバから前記出力文字列として出力された文字列を受信し、前記出力文字列の語尾を語尾変換エンジンによって変換してから組み合わせて対話させる機能を有することを特徴とする装置。
【請求項9】
入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバに対して音声認識に基づく文字列を前記入力文字列として送信し、前記異なる複数のサーバから前記出力文字列として出力された文字列を受信し、前記異なる複数のサーバから受信した前記出力文字列として出力された文字列に基づいてユーザー又は他の機器の少なくともいずれか一方への出力情報の出力をすることでユーザー又は他の機器と対話させる機能を有し、
前記異なる複数のサーバから前記出力文字列として出力された文字列を受信し、すべての前記出力文字列を使用せずに一部の前記出力文字列を記憶手段に記憶させておき、以後の対話で前記記憶手段から取り出して対話に使用させる機能を有することを特徴とする装置。
【請求項10】
請求項1~のいずれかに記載の装置の機能をコンピュータに実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、例えばコミュニケーション等を行う機能を備えた装置及びプログラム等に関するものである。
【背景技術】
【0002】
特許文献1には、対話式のコミュニケーションロボットに関する技術が開示されている。
【先行技術文献】
【特許文献】
【0003】
【文献】特開2011-000681号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかし、従来のコミュニケーションロボットは十分な能力を備えていないという課題があった。そこで従来よりも優れた能力を有する装置及びプログラム等を提供することを目的とする。
本願の発明の目的はこれに限定されず、本明細書および図面等に開示される構成の部分から奏する効果を得ることを目的とする構成についても分割出願・補正等により権利取得する意思を有する。例えば本明細書において「~できる」と記載した箇所を「~が課題で
ある」と読み替えた課題が本明細書には開示されている。課題はそれぞれ独立したものとして記載しているものであり、この課題を解決するための構成についても単独で分割出願・補正等により権利取得する意思を有する。課題が明細書の記載から黙字的に把握されるものであっても、本出願人は本明細書に記載の構成の一部を補正または分割出願にて特許請求の範囲とする意思を有する。またこれら独立の課題を組み合わせた課題も開示されている。
【課題を解決するための手段】
【0005】
(1)ユーザー又は他の機器の少なくともいずれか一方への出力情報の出力をすることでコミュニケーションを行う機能とを備える装置であって、前記コミュニケーションのための前記出力情報の生成を制御する機能又は前記コミュニケーションのための前記出力情報の出力を行うタイミングを制御する機能を備えるとよい。
このようにすれば、ユーザーまたは他の機器の少なくともいずれか一方は、生成が制御された出力情報又はタイミングが制御された出力情報の少なくともいずれか一方を得ることができる。従来よりも優れた装置を提供できる。
装置はコミュニケーションのための前記出力情報の生成を制御として例えばコミュニケーションに応じた出力情報を生成するとよい。このようにすれば特にユーザー又は他の機器において装置とのコミュニケーションを図る際の利便性が高まる。コミュニケーションはどのような出力情報を出力して行うようにしてもよいが、特に過去のコミュニケーションの履歴情報を記憶しておき当該履歴情報にも基いて行うとよい。また異なる複数のユーザーまたは他の機器とのコミュニケーションの履歴情報に基いて行うとよい。特に出力情報の出力は1の出力手段から行うようにしてもよいが、異なる複数の出力手段から可能な構成とし、これらのうちいずれかの出力手段を選択して出力を行うようにするとよい。出力手段としては例えば音声出力手段、表示手段、通信手段等とするとよい。コミュニケーションは、音声や目視あるいはそれら以外の五感、例えば触感にうったえコミュニケーションを図る構成としてもよい。
【0006】
「装置」は特に出力情報を音声出力をする機能を備えるとよい。このようにすれば、例えば音声を入力して動作するデバイスを制御できる。装置は、特にコミュニケーションするためのインターフェースを備え、コミュニケーションを実行するための判断手段を備えるとよい。
なお「装置」の構成の含まれる部分は複数の筺体で構成してもよいが、特に1つの筺体で構成するとよい。
また装置は、例えば、有線や無線を通じてネットワークにアクセスする機能を備えるシステムとするとよい。特に、例えば、スマートフォン、タブレット端末、スマートスピーカ、スマートカメラ等とするとよい。また、外観も限定されるものではないが、特に、いかにも他者とコミュニケーションをとるような装置とするとよい。特にロボットとするとよい。例えば人や動物を模したような、あるいは例えばそれら以外の擬人化した形態のロボットとすると特によい。
【0007】
装置は、コミュニケーションするための入力側のインターフェースを備えるとよく、例えばキーボードのような入力装置、例えば文字を読み込んでデータ化する光学文字認識(OCR:Optical character recognition)とのインターフェースでもよいが、入力側のインターフェースとして音声によるものを備えるとよい。音声によるものとしては、例えばマイクロフォンで電気信号に変換した音声信号に基づく音声データの取得する機能を備えるとよい。
出力側のインターフェースとして音声によるものを備えるとよく、例えばスピーカ装置、イヤフォン等がよい。出力側のインターフェースとして目視によるものを備えるとよく、例えば表示内容を変更可能なディスプレイを備えるとよく、例えば液晶ディスプレイ(LCD)、プラズマディスプレイ(PDP)、有機ELディスプレイ、ブラウン管等の表示
装置を備えるとよい。また、例えば印刷物による出力を備えるとよい。また特に出力側のインターフェースとして実際に動きを発生するものを備えるとよい。実際に動きを発生するものとしてアクチュエータを備えるとよい。例えばモータ等を備えるとよい。特に装置は実際に動きを発生する部材を備えるロボットとするとよい。装置は特に出力情報の出力を、実際に動きを発生する部材の動きとして行なうとよい。特に、出力側のインターフェースとしては音声によるものと目視によるものと実際に動きを発生するものをいずれも備えるとよい。
「ユーザー」は例えば装置を扱える人であって、一人でもよいが、複数人とするとよい。
「他の装置」は上記の装置の具体的な1つと例えば外観、機能等が同じであっても異なるものであってもよい。他の装置は音声出力をする機能を備えてなくともよい。音声出力機能を備えるとよい。また他の装置は音声入力をする機能を備えてなくともよいが音声入力機能を備えるとよい。
他の機器は、ネットワークにアクセスできない機器としてもよいが、ネットワークにアクセスできる機器とするとよい。特にインターネットにアクセスできる機器とするとよい。
出力情報は出力手段からある出力をさせる構成とするとよい。「ある出力」は、例えば外部に対する報知である。明らかな「報知」という形態でなくともそれによって結果的に何かの変化があったことだけでも「報知」と解釈できる。「ある出力」は必ずしも報知することを目的としたものでなくともよい。例えばなんらかの情報を有する、あるいはなんらの情報も有さない音や光の出力がよく、例えば何か物理的な量の変化、物の移動等がよい。
【0008】
(2)前記装置は、音声による前記コミュニケーションによって表示部での表示態様を変化させるように表示させる表示機能を備えているとよい。
【0009】
音声によってコミュニケーションを取る際に表示部に音声によるコミュニケーションとの関係で表示態様が変化させられるため、音声を目で見る表示に変更してコミュニケーションできることとなり、コミュニケーションを図る際の利便性が高まる。
「表示部」は、音声による前記コミュニケーションによって前記表示部での表示態様を変化させるように表示させるデバイスとするとよく、例えば液晶ディスプレイ(LCD)、プラズマディスプレイ(PDP)、有機ELディスプレイ、ブラウン管等のような表示装置がよい。特に表示部は装置に備えるとよい。
「音声による前記コミュニケーションによって表示部での表示態様を変化させるように表示させる」は、ユーザー又は他の機器の音声を表示部に表示させてその態様を変化させる場合と、装置自身の音声も表示部に表示させてその態様を変化させる場合のいずれか一方のみとしてもよいが、特に両方を備えるとよく、このときどちらか片方だけ表示させても両方とも表示させてもよいが、片方だけ表示させる状態と両方を表示させる状態との双方を備え、切り替え可能な構成とするとよい。例えば、片方だけ表示させる例としては下記実施の形態1のロボット1で顔画面S1が表示されている場合の態様であり、両方とも表示させる例としては下記実施の形態1のロボット1でチャット画面S2が表示されている場合の態様である。
表示態様としては、例えば音声との関係で画面を様々に変化させることとするとよく、例えば、音声によって表示画面に表示されたオブジェクトが動くようなアニメーションを実行させるとよい。例えば、音声の出力に伴って画像を変動させたり、音声の変化によって画像に他の画像を重ねたりするとよい。また、例えば、音声データを文字データに変換して表示させたりするとよい。その文字データの表示は音声の変化に応じて刻々と変化させるとよい。
音声による前記コミュニケーションは、前記出力情報の生成を制御する機能又は前記コミュニケーションのための前記出力情報の出力を行うタイミングを制御する機能によって
制御するとよく、特に前記コミュニケーションは前記出力情報の生成を制御する機能及び前記コミュニケーションのための前記出力情報の出力を行うタイミングを制御する機能によって制御するとよい。
また、表示部での表示態様を変化させる機能は、前記出力情報の生成を制御する機能又は前記コミュニケーションのための前記出力情報の出力を行うタイミングを制御する機能によって制御するとよく、特に前記コミュニケーションは前記出力情報の生成を制御する機能及び前記コミュニケーションのための前記出力情報の出力を行うタイミングを制御する機能によって制御するとよい。
以下(3)以降も同様に、装置からの出力を行なう構成については、前記出力情報の生成を制御する機能又は前記コミュニケーションのための前記出力情報の出力を行うタイミングを制御する機能によって制御するとよく、特に前記コミュニケーションは前記出力情報の生成を制御する機能及び前記コミュニケーションのための前記出力情報の出力を行うタイミングを制御する機能によって制御するとよい。
【0010】
(3)前記表示部での前記表示態様の変化は、前記ユーザー又は前記他の機器の少なくともいずれか一方の発話のみに基づく構成とするとことがよい。
【0011】
ユーザーや他の機器からの発話に基づいて装置が表示部での表示態様を変化させることでユーザーや他の機器側では自身の発話が装置に認識されているかが目視でわかることとなり、コミュニケーションを図る際の利便性が高まる。また、異種のヒューマンインターフェースによる特殊なコミュニケーションとなって、新鮮でおもしろさを感じる。
発話は直接的にユーザー又は他の機器から行われてもよく、間接的に発話を例えば文字データ化したものを使用してもよい。また、発話をなんらかの対応する情報、例えば他の音や視覚化した模様等に変換し、それに基づいて表示部で表示態様を変化させるようにしてもよい。
(3)では「ユーザー又は他の機器の少なくともいずれか一方の発話に基づく」ものであるため、例えば装置自身は音声のコミュニケーション機能とするとよい。
前記ユーザー又は前記他の機器の少なくともいずれか一方の発話に基づく構成としては、例えば、音声認識機能により音声を文字列に変換して前記ユーザー又は前記他の機器の少なくともいずれか一方の発話内容を特定する構成を備えるとよい。
【0012】
(4)前記表示部での前記表示態様の変化は、前記装置からの音声出力と交互に行われるようにした。
コミュニケーションが一方的にならず、安定して意思疎通しながらコミュニケーションを図ることができる。「交互」とは、例えば基本的に装置側とユーザー又は他の機器側とのコミュニケーションが対話形式で進行するように構成とするとよく、片方だけが一方的に発話する構成でない構成とするとよい。
【0013】
(5)前記表示態様は前記ユーザー又は前記他の機器の少なくともいずれか一方の発話が変換された文字情報でを備えるとよい。
【0014】
このようにすれば、ユーザーや他の機器側では自身の発話がどのように装置に認識されているかが表示された文字情報から具体的にわかることとなり、正しくコミュニケーションができているかを表示された文字情報の内容から判断できる。また、発話した内容の目視での確認ができる。また、認識が誤っているならもう一度言ったり、他の表現で言い直したりして正しいコミュニケーションに導くことができる。
「文字情報」は、例えば日本語であれば、例えば通常の漢字、ひらがな、かたかな等のユーザー又は他の機器の発話に基づく文字であり、発話が文を構成している場合には、漢字、ひらがな、かたかな、外国語表記等の混じった文節を有する文であることがよい。外国語、例えば英語や中国語等で発話される場合には、それらの文字で表示されることがよ
い。
例えば、音声認識機能と音声出力機能とを備え、音声認識機能によって音声認識し文字情報に変換された前記ユーザー又は前記他の機器の少なくともいずれか一方の発話の内容を表示部に表示させ、その内容に基づく返答文字情報を生成し、当該返答文字情報を音声合成機能により音声情報に変換して、音声として出力させる機能を備えると特によい。
【0015】
(6)前記発話が変換された文字は発話の開始から終了までの全内容が同時に前記表示部に表示されるようにするとよい。
ユーザーや他の機器からのある長さを持った発話全体が装置側に受け止められるため、その発話に対する装置からの正しいコミュニケーションが期待できる。また、自らが発話した内容の目視での確認が瞬時にできることとなり、以後のコミュニケーションの修正や方向性に寄与する。
発話の開始から終了は、人が一息で発話できる時間を加味して設定するとよい。発話の終了は、例えば、所定の時間、音声の発話がないとみなされる音の大きさが続いた時点とするとよい。発話の開始は例えば音の大きさが所定のレベルを越えたことを条件に開始するとよい。発話の開始は例えば音の大きさが所定のレベル以上のレベルの急激な変化が検出されたことを条件に開始するとよい。
【0016】
(7)前記装置は、前記装置と前記ユーザー又は前記他の機器の少なくともいずれか一方の音声によるコミュニケーションの対話履歴を文字情報として前記表示部に表示させる機能を備えるとよい。
【0017】
装置とユーザー又は他の機器との間でどのように対話がされたかが容易にわかり、音声によるコミュニケーションにおける利便性が高まる。
対話履歴の表示は、例えばどちらが対話したものかがわかるように表示させることがよい。そのためには、例えば吹き出しを設けていずれの発話に基づく文字情報かを区別することがよい。過去の対話については画面上でスクロールして確認できることがよい。対話形式であることを示すために装置側とユーザー又は他の機器側とで異なるアバターキャラクターを表示させるとよい。いつ発話したのかその日時が同時に表示されるとユーザーが対話履歴から過去を思い出す契機となるのでよい
【0018】
(8)前記装置は、前記対話履歴を文字情報として表示させる際に、前記ユーザー又は前記他の機器の交替があり、前記装置の対話対象が代わった場合には前記表示部にその旨が表示させる機能を備えるとよい。
【0019】
装置の対話対象が代われば対話内容にも変化がある。対話対象が代わった旨を表示させることで、例えば過去の対話履歴を見た際にその表示があることでその前後で対話内容が代わることが読み手にわかるため、対話内容の切れ目がわかることとなる。
装置は前記ユーザー又は前記他の機器の交代を検出する機能を備えるとよい。交代の検出は、音声の特徴の変化から検出する機能を備えるとよいが、カメラを用いて周囲の人または機器の状態を取得して検出する機能を備える構成が望ましく、特に両者に基づいて検出する構成とするとよい。
【0020】
(9)前記装置は音声認識機能によって前記ユーザー又は前記他の機器の少なくともいずれか一方の音声の認識状況を前記装置の表示部に表示させる機能を備えるようにするとよい。
【0021】
例えば、ユーザーや他の機器が発話している場合に、それを間違いなく聞いていることをユーザー等に理解させることで円滑に対話が行われていることをユーザー等に理解させることができる。
例えば、視覚を通じた機能として、表示部に音声認識の度合いに応じて、例えば表示画面や表示画面に表示されるオブジェクトの色を変えたり、例えば音声の認識状況応じて異なるオブジェクトを表示をさせたり、音声認識の度合いに応じて量的な表示、例えばよく認識していれば高い数値を示したりすることがよい。聴覚を通じた機能として、例えば音声認識の度合いに応じて音を大きくしたり小さくしたりすることがよく、例えば音色を変えたりすることがよい。
特に擬人化された態様での表示を表示部に行なうようにし、その表情を変化させる構成とするとよい。
【0022】
(10)音声を認識して文字列に変換した結果を用いて前記音声出力を行うことで前記コミュニケーションを行うための機能を備え、音声を認識して文字列に変換した結果が、予め前記結果の文字列と出力内容との対応関係を記憶した記憶手段に記憶された文字列と一致する部分がある場合に当該文字列に対応する出力内容を音声出力する機能を備えるようにするとよい。
【0023】
音声を認識して変換した文字列が音声記憶手段に記憶された文字列と一致する部分がある場合に、装置内のみで必要な音声出力ができれば、ユーザーや他の機器からの発話に迅速に応じることができる。また、外部サーバーに接続しないため、接続のためのコストが削減できる。
例えば、記憶手段に記憶された文字列として多数のビルトインシナリオを用意することがよい。ビルトインシナリオは予定された対話であって例えば、ユーザーからの「おはよう」に対して装置側から「お元気ですか」と返答するような簡単な挨拶や、一定の処理を実行するための、例えば「設定画面を開いて」(ユーザー)、「本当にいいですか」(装置)、「はい」(ユーザー)、「じゃあ、設定画面を開くね」(装置)のようなシナリオ等がよい。記憶手段としては、例えばコンピュータ内部のROMやSSDや外付けのSDカードmicroSDカード、CD-ROM等がよい。
【0024】
ここで「文字列と一致する部分がある場合」とは、完全に記憶された文字列と一致する場合と、ある部分が異なっていてもよい正規表現である場合である。正規表現とは文字列の集合を一つの文字列で表現する言語処理方法の一つであり、例えば「×××音量大きく××」という場合に「ユピ坊音量大きくしてよ」とか「おい音量大きくして」「音量大きくしてください」等のように異なる部分があっても要部が一致すれば解釈として「音量を大きく」する表現として認識するような場合である。そして、「当該文字列に対応する出力内容を音声出力する」とは、例えば、このような「音量を大きく」するという当該文字列に応じて「はい、音量を大きくします」というような音声出力がよい。また、このような音声出力に続いて装置はある処理をするようにしてもよい。例えば、「はい、音量を大きくします」という発話の後で装置は実際に以後の対話における自身の発話の音量を大きくすることがよい。
音声を認識して文字列に変換する処理は、装置で行なうようにしてもよいが、ネットワークに接続された音声認識サーバーに対して音声データを送信し、音声認識サーバーで変換された文字列を受信するようにして行なうようにしてもよい。望ましくは両者を備えるとよく、コミュニケーションの状況等に応じていずれの結果を用いるかを決定する機能を備えるとよい。
【0025】
(11)音声を認識して文字列に変換した結果が、予め前記結果の文字列と出力内容との対応関係を記憶した記憶手段に記憶された文字列と一致する部分がない場合に、対話エンジンを備えるサーバーに接続して音声データを出力する機能を備えるとよい。
【0026】
音声を認識して変換した文字列が音声記憶手段に記憶された文字列と一致する部分がない場合に、対話エンジンを備えるサーバーに接続するため、接続のためのコストが削減で
きる。
サーバーは、例えばインターネット回線を使用して接続する記憶部、制御部としてのコンピュータの機能を有する装置とするとよい。本発明では対話エンジンを備えていることがよい。外部サーバーの場合には例えばIDやパスワードや電子認証によって接続可能となる。外部サーバーはクラウドサーバーがよい。サーバーは音声認識エンジンを備え、音声認識エンジンによって音声を文字列データに変換ことができることがよい。変換された文字列データはインターネット回線を使用して装置に送信されることがよい。
対話エンジンを備えるサーバーに接続して音声データを出力する機能は、例えば、音声認識した文字列を対話エンジンに送信し、対話エンジンからその文字列に対応する対話内容を含む文字列を受信して、当該対話内容の文字列を音声合成機能で音声データに変換するとよい。
文字列の音声データへの変換は、装置に備えた音声合成エンジンで行ってもよいが、文字列を音声データに変換する音声認識サーバーに文字列を送信し、当該音声認識サーバーから変身された当該文字列に対応する音声データを受信して行うとよい。
【0027】
(12)音声を認識して文字列に変換した結果が、予め前記結果の文字列と出力内容との対応関係を記憶した記憶手段に記憶された文字列と一致する部分があっても、ある条件を満たすことで音声認識エンジンを備えるサーバーに接続して音声データを出力する機能を備えるようにするとよい。
【0028】
音声を認識して変換した文字列が記憶手段に記憶された文字列と一致する部分がある場合に、ユーザーが予測できるような決まった音声出力をすることは対話の意欲を削ぐことにもなるため、敢えてこのよう外部サーバーに接続することが、より人間的な対話ができることとなりよい。
例えば、ユーザーから「こんにちは」と発話がされ、それを装置側が認識した場合に、本来のシナリオでは「こんにちは、ご機嫌はいかがですか」というように対話をさせるビルトインシナリオであった場合に、そのシナリオを使用せずに外部サーバーに「こんにちは」という音声データをリクエストし、外部サーバーの対話エンジンを使用してその「こんにちは」に対する返答データの作成をリクエストするようにすることがよい。ある条件は例えば何回かに一回の回数や、ランダムなタイミングとするとよい。
【0029】
(13)音声認識後に音声が途切れて無音状態となったことを検知する機能と、音声認識から無音状態となるまでの音声データを記憶する記憶手段と、前記記憶手段に記憶された音声データを無音状態となったタイミングで音声認識エンジンを備えるサーバーに接続して音声データを出力する機能を備えるとよい。
【0030】
対話においてはしばしば無音状態となることがある。しかし、無音状態となっても外部の音声認識エンジンを備えるサーバーに接続したままでは無用なコストがかかってしまう。そのためこのような前もって音声認識から無音状態となるまでの音声データを記憶手段に記憶させ、リアルタイムではなくその音声データを無音状態となったタイミングで送ることで無音部分の時間分をカットできるため、コストが削減できる。
【0031】
(14)前記装置は録音機能を備え、所定の音圧レベルの音声の検出によって音声認識エンジンを備えるサーバーに接続して音声データを出力する機能を備えるようにするとよい。
常に外部の音声認識エンジンを備えるサーバーに接続したままでは無用なコストがかかってしまう。これによって無音や無音に近いような対話になっていない場合には接続せずに必要な対話が開始される場合にのみ外部サーバーに接続するため、接続のためのコストが削減できる。
音声認識エンジンを備えるサーバーは、装置ですでに録音済みの過去の所定期間の録音
データを受信して、当該録音データに対する文字列を返信するものとしてもよいが、特に、例えばストリーミングデータとしてリアルタイムに音声データを受信して、文字列を返信するタイプのものとするとよい。音声データの受信時間当たり何円という形で従量課金等されるケースが多いが、大幅にコストを削減することが可能となる。
【0032】
(15)音声認識エンジンを備えるサーバーに接続して音声データを出力した際に、前記サーバーがビジー状態である場合に、前記ユーザーに対して記憶手段に記憶された対話データから選択された対話例を音声出力する機能を備えるようにするとよい。
【0033】
ビジー状態である場合にはその旨の報知をすることが普通であるが、例えば対話途中でそのような報知は唐突でいかにも対話とは関係ない発話であり、対話がしらけてしまう可能性もある。そのため、ビジー状態である旨の報知の代わりに例えば「もう一度いってくれる?」という呼びかけや「ほう、そうですか」などのつなぎの発話をして対話をつなぐようにすれば、その間に音声認識エンジンに接続して適切な対話を続けることが可能となるし、対話が不自然にならない。
【0034】
(16)認識した前記ユーザーの発話が長すぎると判断した場合に、音声認識エンジンを備えるサーバーに接続することなく記憶手段に記憶された音声データから選択された対話例を音声出力する機能を備えるようにするとよい。
【0035】
ユーザー側の発話が長すぎると、音声認識エンジンが誤認識をする可能性がある。そして、その結果的外れな返答が返ってくることがある。そのため、一定以上のセンテンスになってしまった場合には、あえてそのような可能性を排除して対話を仕切り直しするために「うん」とか「マジ?」とか「本当ですか?」などという対話においてどのようにも取れる相づちのような対話例を選択して音声出力することがよく、それによって適切な対話を続けることが可能となる。
【0036】
(17)対話による前記コミュニケーションにおいて、前記装置の音声を聞き逃した際に、前記ユーザーのある発話に基づいて前記装置は直前の音声を再度出力するとよい。
例えば「もう一度言って」とか「もう一回しゃべって」のような直前に装置が話した言葉が聞き取れなかったり、うっかり聞き忘れた場合にこのような呼びかけをすることで、直前に装置が話した言葉を発話させることができる。これによって、直前まで行っていた対話を途切れさせることなくそのまま続けることが可能となる。
【0037】
(18)音声を認識できなかった場合に、前記ユーザーに対して再度の発話を促すように前記装置から音声が出力されるとよい。
これによって、直前まで行っていた対話を途切れさせることなくそのまま続けることが可能となる。
【0038】
(19)認識した音声内容がある条件を満たす場合に、表示部にある表示をさせるようにするとよい。
例えば、所定の言葉が含まれた発話がされ、それを音声認識した場合に、表示部にその言葉に対応する「ある表示」をさせるようにする。「所定の言葉」とは、例えば、ユーザーの誕生日、ユーザーの子供の名前、装置の愛称、会社の名称、特定の宣伝用のキャッチフレーズ等とするとよい。所定の言葉とある表示との対応関係を予め設定しておく機能を備えるとよい。これによって、単なる対話に留まらず目視を含めたコミュニケーションをすることができ、装置との間でコミュニケーションの態様が増すこととなってコミュニケーションを図る際の利便性が高まる。
【0039】
(20)前記装置は筐体又は筐体に接続される部分を動かす機能を備え、認識した音声
内容がある条件を満たす場合に、筐体又は筐体に接続される部分がある動きをするとよい。
例えば、所定の言葉が含まれた発話がされ、それを音声認識した場合に、筐体又は筐体に接続される部分にその言葉に対応するある動き、例えばジェスチャーをさせるようにする。これによって、単なる対話に留まらず装置の動きを含めたコミュニケーションをすることができ、装置との間でコミュニケーションの態様が増すこととなってコミュニケーションを図る際の利便性が高まる。上記の「ある表示」と組み合わせると特によい。
【0040】
(21)前記装置は前記ユーザーが目として認識できる部分である目部と、前記ユーザーの位置を認識するユーザー位置認識機能と、前記目部を動かす機能とを備え、 前記コミュニケーションとして前記位置認識機能で認識した前記ユーザーの位置方向を向くよう前記目部を動かす機能を備えるとよい。
【0041】
目として認識できる目部がユーザーの位置方向を向くことで、実際に人と話しているような疑似感覚を得られることとなり、装置とコミュニケーションを取りたいという欲求もますこととなり、装置の利用価値が向上する。
「ユーザーが目として認識できる部分である目部」は表示画面に表示されるオブジェクトとしての目でもよく、そのようなバーチャルな映像ではない実際に機械的に動作する目でもよい。目部と同期して装置自体もユーザーの位置方向を向くよう制御してもよい。目部をユーザーの方向に向けるための装置だけをユーザーの位置方向を向くよう制御してもよい。
【0042】
(22)前記装置はユーザーの顔を認識する顔認識機能を備えるとよい。
個々の人物の顔を識別できるため、個々の個性に応じたコミュニケーションをとることが可能となる。例えば個々の人物の認証された顔と名前を関連付けすることで、対話の際に顔認識した人物をその名前で呼ぶことができる。また、過去の対話履歴に基づいて顔認識した人物に特化した対話を行う構成とすると特によい。
【0043】
(23)前記装置は表示部を備え、前記顔認識機能によってユーザーの顔の認識状況を表示部に表示させる機能を備えるとよい。
このようにすればユーザーは自身の顔の装置での認識状況を表示部を見ることで把握できる。特に認識状況として顔認識が完了しているか、それとも未だ人物の顔として認識されていないかを表示させるとよく、このようにすれば、ユーザーは未だ認識が完了していなければなるべく装置が認識しやすいように顔を動かさないようにして協力することができる。
【0044】
(24)前記位置認識機能は、三角形の頂点に配置された3つのマイクロフォンと、音源から前記3つのマイクロフォンの各々までの音の到達時間の差に基づき、前記音源の位置を、前記三角形を含む平面に垂直な方向に沿って前記三角形を含む平面に投影した位置から前記平面の前記三角形で囲まれた領域の内側にある基準位置へ向かう音源方向を特定する特定部と、を備える音源方向特定機能であるとよい。
これによって3つのマイクロフォンで音源方向を特定することができる。そして、音源方向を特定することができれば、ユーザーが発話すればその方向に装置を向けさせることができるため、対話によるコミュニケーションをしているようにユーザーは感じることができる。
【0045】
(25)前記装置は赤外線リモコン信号出力部を備え、前記コニュニケーションは赤外線リモコン受信機能を備える前記他の機器との間のコミュニケーションであるとよい。
これによって装置の赤外線リモコン信号出力部を介して簡単に機器との間のコミュニケーションを取ることができる。
例えば、赤外線リモコン信号受信部を備えた受信側装置、例えば、赤外線リモコン信号受信部を備えた受信側装置、例えばテレビ、オーディオ装置、エアコン装置等に対して装置から赤外線リモコン信号を出力して例えばON・0FF等の制御を実行させることが可能となる。特に装置に音声対話機能を備え、例えば「テレビつけて」とか「テレビ消して」という命令語句の発話に対し、装置はその命令に基づいて赤外線リモコン信号出力部を制御する構成とよい。
【0046】
(26)前記装置は前記他の機器からのインターネットを介して遠隔操作されるようにするとよい。
他の機器から装置を遠隔操作できるため、装置の利便性が高まる。例えば、他の機器としてのスマートフォン等とするとよい。装置にはカメラを備えるとよい。装置にはカメラの向きを変える機構を備えるとよい。他の機器からアクセスして、例えば、装置側のカメラ動画を見たり、カメラの向きを代えたりすることがよい。これによって装置の近くにいなくとも装置の制御が可能となる。また、例えばスマートフォンからアクセスして、例えば装置の見守り機能をONとして、人(物)が動いたことをスマートフォンにeメールで通報するようにするとよい。また、例えば病人や被介護者の見守りとして、常に動いていることを前提とし、例えば一定時間以上その人が動いていない場合に通報するようにするとよい。他の機器とは、例えばタブレット端末やパソコン等でもよい。
【0047】
(27)装置は前記他の機器からインターネットを介して送信された文字情報を用いて前記音声出力を行うようにするとよい。
例えば受信した電子メールの文字列を読み上げる機能を備えるとよい。誰かからのeメールが届く設定にしておくことで、そのメール内容が装置から音声出力されるため、自身の端末を目視で確認する必要がなくなる。他の機器とは、例えばスマートフォンやタブレット端末やパソコン等とするとよいが、他の「装置」としてもよい。
【0048】
(28)前記音声出力は前記文字情報の内容によって前記音声出力を行う時間、時刻又は回数を変更できるとよい。
例えば「薬飲んだ」とういうメールは決まった時刻にしゃべらせたい。例えば件名の記載が合致することで、所定の時刻に装置が発話したり、例えば重要な内容を時間を空けて2回発話させるようにすれば、装置側の近くにいるユーザーにメール内容を間違いなく実行させることができる。
【0049】
(29)前記装置は音声認識した文字情報を前記他の機器へインターネットを介して送信する機能を有するとよい。
装置の音声コミュニケーション機能を使用して音声を文字化して他の機器に文字データとして送れば、例えばeメールを送りたい場合に自身の端末に手入力しなくとも、送ることができる。
【0050】
(30)入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバーに対して音声認識した文字列を前記入力文字列として送信し、前記異なる複数のサーバーから前記出力文字列として出力された文字列を受信し、最も長い前記出力文字列を選択して対話させる機能を有するとよい。
最も長い返答であると、いかにも対話しているように感じ、対話の単調さがなくなり、聞き手(ユーザー)は対話を楽しむことができる。
【0051】
(31)入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバーに対して音声認識した文字列を前記入力文字列として送信し、前記異なる複数のサーバーから前記出力文字列として出力された文字列を受信し、語尾に疑問符がついた前記出力文字列を選択して対話させる機能を有するとよい。
語尾に疑問符がつくと、その疑問に更に答えるような話の流れになるため、会話が続きやすくなり聞き手(ユーザー)は対話を楽しむことができる。
【0052】
(32)入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバーに対して音声認識した文字列を前記入力文字列として送信し、前記異なる複数のサーバーから前記出力文字列として出力された文字列を受信し、肯定文を組み合わせた後に疑問文を組み合わせて対話させる機能を有するとよい。
このようにアレンジすることでいかにも考えて文章を練ったような応答になるため、ユーザーは真剣に自身の発話を聞いてもらっているような感覚となり、続けて会話をしたいと思うようになるため、会話が続きやすくなり聞き手(ユーザー)は対話を楽しむことができる。また、出力尺をかせぐことができるとともに聞き手(ユーザー)への返答を求めることができる。
【0053】
(33)入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバーに対して音声認識した文字列を前記入力文字列として送信し、前記異なる複数のサーバーから前記出力文字列として出力された文字列を受信し、話題転換した文字列を最後に配置するように組み合わせて対話させる機能を有するとよい。
このようにアレンジすることで話題転換したことで次の発話を誘うような対話となり、対話が続きやすくなる。
【0054】
(34)入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバーに対して音声認識した文字列を前記入力文字列として送信し、前記異なる複数のサーバーから前記出力文字列として出力された文字列を受信し、フレンドリーな前記出力文字列を初めに配置するように組み合わせて対話させる機能を有するとよい。
このようにアレンジすることで聞き手(ユーザー)が対話に引き込まれやすくなり、対話が続きやすくなる。
【0055】
(35)入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバーに対して音声認識した文字列を前記入力文字列として送信し、前記異なる複数のサーバーから前記出力文字列として出力された文字列を受信し、それらをランダムな順で組み合わせて対話させる機能を有するとよい。
対話のバリエーションが増えることとなるため、聞き手(ユーザー)が同じ発話をした場合でもまったく同じ応答が帰ってきてしまうことがなくなり、対話に飽きることがなく対話が続きやすくなる。
【0056】
(36)入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバーに対して音声認識した文字列を前記入力文字列として送信し、前記異なる複数のサーバーから前記出力文字列として出力された文字列を受信し、それらの内に顔文字を含む前記出力文字列がある場合には、対話対象とせず、表示部には対話対象とされた前記出力文字列と一緒に表示させる機能を有するとよい。
顔文字は音声出力できないが、表示部に敢えて顔文字を表示させることで、音声と併せて対話の一部とすることで通常にはない対話のおもしろさを創出することができる。
【0057】
(37)入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバーに対して音声認識した文字列を前記入力文字列として送信し、前記異なる複数のサーバーから前記出力文字列として出力された文字列を受信し、同じ文字列が含まれる前記出力文字列同士についてはいずれか1つのみを選択して他の前記出力文字列と組み合わせて対話させる機能を有するとよい。
同じ文字列が繰り返されると対話がくどくなってしまうし、聞き手に違和感を覚えさせてしまうためである。
【0058】
(38)入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバーに対して音声認識した文字列を前記入力文字列として送信し、前記異なる複数のサーバーから前記出力文字列として出力された文字列を受信し、前記出力文字列の語尾を語尾変換エンジンによって変換してから組み合わせて対話させる機能を有するとよい。
普通の対話エンジンの文章に比べて、より親しみやすい表現となるのでよい。
【0059】
(39)入力文字列に対応する出力文字列を出力する対話エンジンを備える異なる複数のサーバーに対して音声認識した文字列を前記入力文字列として送信し、前記異なる複数のサーバーから前記出力文字列として出力された文字列を受信し、すべての前記出力文字列を使用せずに一部の前記出力文字列を記憶手段に記憶させておき、以後の対話で前記記憶手段から取り出して対話に使用させる機能を有するとよい。
音声認識が失敗した場合や、外部サーバーからのレスポンスがなかなか来ない場合に使用することで、対話が途切れずにつなげることができ、自然な対話に寄与する。
【0060】
(40)音声認識エンジンを備えるサーバーを利用する際に料金が無料のサーバーと有料のサーバーをミックスして利用するとよい。
これによって例えば特に装置との対話のヘビーユーザーはサーバー接続料金を節約することができる。
【0061】
(41)前記他の機器はスマートスピーカであり、前記装置は前記スマートスピーカに音声出力を行って前記スマートスピーカとコミュニケーションを行うようにするとよい。
スマートスピーカは表示部がないため、装置と組み合わせて使用することで利便性が高まる。
スマートスピーカとは、例えば無線通信接続機能と音声操作のアシスタント機能を持つスピーカーとするとよい。例えばGoogleHome、AmazonEcho、LINE Clova等とするとよい。スマートスピーカは例えば様々な機能・能力(スキル)を実現する機能を備えるものとするとよい。て音声でのコミュニケーションをする装置からスマートスピーカに対して発話することでその機能を実行させることができる。装置から発話させる際には、例えばユーザーがスマートスピーカのスキルを起動させるフレーズを発話し、装置がその発話を音声認識して文字列データとして保存し、あるタイミングでその文字列データを音声合成してスマートスピーカに対して発話してスキルを実行させる構成とするとよい。
【0062】
(42)前記他の機器はスマートスピーカであり、前記装置は前記スマートスピーカに音声出力を行って前記スマートスピーカとコミュニケーションを行うようにするとよい。
スマートスピーカを起動させたり、スキルを起動させる。あるいは問い合わせを行う。自らスマートスピーカを起動させなくとも、ある決まったタイミングや、ある予定時刻にスマートスピーカのスキルを自動的に実行させることが可能となる。
【0063】
(43)前記他の機器はスマートスピーカであり、前記装置は前記スマートスピーカの音声出力を翻案する翻案機能を有するとよい。
質問に対するスマートスピーカの決まった長い回答を聞くのが面倒であったりする場合や、内容をざっと再確認したい場合に便利である。
【0064】
(44)前記装置の音声出力はWeb記事の読み上げる機能を有するとよい。
Web記事を読まなくとも装置との対話のみで聞くことができる。
【0065】
(45)前記ある出力としてロボティクスプロセスオートメーションの所定の処理単位の実行が完了した時点でなされるようにするとよい。
ロボティクスプロセスオートメーションは処理単位の実行状況がわかりにくいが、装置
に処理単位の実行に応じた「ある出力」をさせることで処理状況がわかりやすくなり利便性が高まる。
【0066】
(46)前記ある出力とは報知動作とするとよい。
報知動作によってある出力がされたことがわかることとなる。
(47)ロボティクスプロセスオートメーションの実行中のコンピュータがユーザーからの入力待ち状態となった場合に、報知動作を行うようにした。
これによって入力待ち状態となったことをユーザーに報せ、次の処理を促すことが可能となる。
【0067】
(48)ロボティクスプロセスオートメーションを行うクライアントコンピュータと、前記クライアントコンピュータに対してロボティクスプロセスオートメーションの実行指示を与えるサーバーコンピュータとを備え、前記クライアントコンピュータに前記サーバーコンピュータからの指示があった場合、報知動作を行うようにするとよい。
これによってサーバーコンピュータからの指示があったことをユーザーに報せ、次の処理を促すことが可能となる
【0068】
(49)ロボティクスプロセスオートメーションを実行しているコンピュータの方向を指し示す動作を行なう前記出力情報を生成するとよい。
これによってどのコンピュータにおいて実行が行われたのかをユーザーがわかることとなり、ユーザーに次の処理を促すことが可能となる。
(50)ロボティクスプロセスオートメーションの実行状態に応じて異なる前記出力情報を生成するものとするとよい。
これによってどのような実行が行われたかを区別することができる。
【0069】
(51)(1)~(50)のいずれかに記載の装置の機能をコンピュータに実現させるためのプログラム。
「ある出力」など「ある」と記載した部分は例えば「所定の」とするとよい。
上述した(1)から(50)に示した発明は、任意に組み合わせることができる。例えば、(1)に示した発明の全てまたは一部の構成に、(2)以降の少なくとも1つの発明の少なくとも一部の構成を加える構成としてもよい。特に、(1)に示した発明に、(2)以降の少なくとも1つの発明の少なくとも一部の構成を加えた発明とするとよい。また、(1)から(50)に示した発明から任意の構成を抽出し、抽出された構成を組み合わせてもよい。本願の出願人は、これらの構成を含む発明について権利を取得する意思を有する。また「~の場合」「~のとき」という記載があったとしてもその場合やそのときに限られる構成として記載はしているものではない。これらの場合やときでない構成についても開示しているものであり、権利取得する意思を有する。また順番を伴った記載になっている箇所もこの順番に限らない。一部の箇所を削除したり、順番を入れ替えた構成についても開示しているものであり、権利取得する意思を有する。
【発明の効果】
【0070】
ユーザーや他の機器とコミュニケーションを取る際に、装置はコミュニケーションに応じた出力情報を生成することができる。そのため、ユーザー又は他の機器において装置とのコミュニケーションを図る際の利便性が高まる。
本願の発明の効果はこれに限定されず、本明細書および図面等に開示される構成の部分から奏する効果についても開示されており、当該効果を奏する構成についても分割出願・補正等により権利取得する意思を有する。例えば本明細書において「~できる」と記載した箇所などは奏する効果を明示する記載であり、また「~できる」と記載がなくとも効果を示す部分が存在する。またこのような記載がなくとも当該構成よって把握される効果が存在する。
【図面の簡単な説明】
【0071】
図1】本発明にかかる実施の形態1のロボットの正面図。
図2】同じ実施の形態1のロボットの側面図。
図3】同じ実施の形態1のロボットの背面図。
図4】ロボットの電気的構成を説明するブロック図。
図5】ロボットの顔面部に表示される顔画面のある表情の一例を捉えた説明図。
図6】ロボットの顔面部に表示されるチャット画面のあるチャット状態の一例を捉えた説明図。
図7】ロボットの顔面部に表示される顔画面を背景とする待ち受け画像を説明する説明図。
図8】ロボットの顔面部に表示されるチャット画面を背景とする待ち受け画像を説明する説明図。
図9】(a)~(d)はロボットの顔面部に表示される目オブジェクトの変形パターンを説明する説明図。
図10】(a)~(c)はロボットの顔面部にユーザーの発話内容が文字列として徐々に表れてくる様子を説明する説明図。
図11】ロボットの顔面部に表示される顔画面において目オブジェクトがユーザーの顔を追って移動している状態を説明する説明図。
図12】スマートフォンの一例を説明する説明図。
図13】ロボットの起動~ウェイクアップモード~対話モード~スリープモードの関係を説明する説明図。
図14】実施の形態7においてロボットとスマートスピーカの関係を説明する説明図。
図15】実施の形態9においてスマートフォンの一例を説明する説明図。
【発明を実施するための形態】
【0072】
<実施の形態1>
図1図3に示すように、人の声に反応して動作するコミュニケーションロボットであるロボット1は、下半身となる固定部2と、固定部2上に載置される上半身となる可動部3を筐体として備えている。可動部3は固定部2に隣接配置された胴部4と、胴部4に支持された頭部5とから構成されている。固定部2は上に開いた碗状の外観に形成され、胴部4は固定部2上縁と上下方向に連続的なカーブで構成された筒体形状に形成されている。ロボット1は固定部2と胴部4の接続部分がもっとも大径に構成されて、その接続部分を境界に上下方向に窄まった外形とされている。胴部4はその筒体形状の前方が半円形形状に大きく切り欠かれている。頭部5は胴部4の上部に埋め込まれるように嵌合されている。胴部4は固定部2に対して水平方向(図1の矢印方向)に回動し、頭部5は胴部4に対して縦方向(図2の矢印方向)と左右回転方向(図3の矢印方向)の2方向に回動する。
【0073】
頭部5は全体として球体の一部(前面部分)が1つの平面でカットされた残余である球欠状の形状に構成されている。カット状に形成された前面部分は円形形状に現れロボット1の顔面部6を構成する。顔面部6の表面に形成された長方形部分はタッチパネル機能を備えた液晶ディスプレイ(LCD)である表示部としてのタッチパネル部7とされている。タッチパネル部7に表示される内容については後述する。タッチパネル部7の周囲の顔面部6領域にはスモークパネルが配置され顔面部6全体が統一された濃色の背景となっている。頭部5の内部において顔面部6の上方左右の収容位置には照度センサ8と高輝度白色LED9がそれぞれ配設されている。顔面部6においてタッチパネル部7の上部中央位置には顔認識用カメラ10のレンズ11が配設されている。
【0074】
胴部4内部において胴部4の前方左右寄り位置と後方中央位置の120度ずつずれた同
じ高さの3箇所の位置にはマイクロフォン12が配設されている。固定部2内部において固定部2上には左右一対のスピーカ装置13が配設されている。スピーカ装置13の側方にはスピーカ装置13で発生した音を出力するための開口部14が形成されている。スピーカー用開口部14に隣接した位置には電源スイッチ15とスピーカー装置13の音量を調整するためのアップスイッチ16とダウンスイッチ17がそれぞれ配設されている。固定部2の後方位置にはUSBのOTG(On-The-Go)用の端子18、DC12V用の電源用ジャック20、マイクロSDカード用ソケット(リーダー)19が配設されている。
【0075】
ロボット1はインターネット回線を利用して所定の外部のクラウドサーバーに接続可能とされている。クラウドサーバーはロボット1が必要とするデータを記憶する記憶手段としての記憶領域、ロボット1が必要とする各種処理を行うための各種エンジン等を備えている。そのため、広義にはロボット1はこれらのクラウドサーバーのソフトウェア等の部分を含めた装置として解釈することができる。
【0076】
次に、図4のブロック図に基づいて、実施の形態1のロボット1の電気的構成について説明する。
制御手段としてのコントローラMCには上記のタッチパネル部7、照度センサ8、高輝度白色LED9、顔認識用カメラ10、マイクロフォン12、スピーカ装置13、端子18、マイクロSDカード用ソケット19が接続され、これらに加え、無線LAN装置21、ドップラーセンサ22、第1~第3のモータ23~25等がそれぞれ接続されている。
【0077】
タッチパネル部7はその表面に接触することで入力する入力操作機能を有する。タッチパネル部7は後述する自然対話モードにおいては図5又は図6のような異なった画面を表示させることができる。コントローラMCは第1の画面として図5のようなロボット1の表情、特に目の周辺の変化を司る顔画面S1を変位可能にタッチパネル部7に表示させる。顔画面S1はデフォルトで表示される画面であって、ロボット1の目オブジェクト27とほっぺオブジェクト28と楕円領域29が表示される。目オブジェクト27はアニメーション画像としていくつかの目オブジェクト27の変形パターンを備えている(図9(a)~(d))。また、アニメーション画像として瞳オブジェクト27aが左右に移動する動きをする。
【0078】
また、コントローラMCは第2の画面として図6のようなチャット画面S2をタッチパネル部7に表示させる。チャット画面S2は顔画面S1の状態でタッチパネル部7をタッチしてスライドさせることで顔画面S1に代えてタッチパネル部7上にチャット画面S2を表示させることができる。スライド操作によって顔画面S1とチャット画面S2は相互に表示切り替えが可能となっている。チャット画面S2については後述する。
また、タッチパネル部7は待ち受けモード(ウェイクアップモード)ではタッチパネル部7上に図7又は図8の待ち受け画像を表示させることができる。待ち受け画像については後述する。
ロボット1にはこれら以外の異なる画像として設定画面が用意され、チャット画面S2からその設定画面に移動可能である。ロボット1が初めて起動された状態では設定画面からアクセスして、例えば、ID・パスワードのサーバーへの設定登録、Wi-Fiパスワードの設定登録、ユーザー登録(例えば名前、年齢、性別等)、顔認証、データを転送する先となるeメールアドレスの設定等の必要な初期設定項目を入力する。
【0079】
照度センサ8は、ロボット1の設置された環境の明るさを認識する。高輝度白色LED9は照度センサ8の検出した数値に基づいて顔認識用カメラ10による撮影に光度が足りない場合に自動的に点灯される。
マイクロフォン12は、ユーザーとの対話においてユーザーの発話を取得する音声入力手段であると同時に、三角形の頂点に配置される3つのマイクロフォン12を同時に使用
することで、これらの間での音の到達時間の差によって音源方向を特定することができる方向検知手段でもある。コントローラMCは各マイクロフォン12の取得した電気信号の位相差から到達時間差を求める。コントローラMCはその到達時間差に基づいて基準方向に対する音源角度を算出する。ユーザーとの対話に特化したマイクロフォンを例えば顔面部6に設けるようにしてもよい。
スピーカ装置13は、ユーザーとの対話においてロボット1が発話(音声出力)する音声出力手段である。
マイクロSDカード用ソケット19は挿入されるmicroSDカードのデータの読み取り及び書き換えをする。
無線LAN装置21は、Wi-Fi対応機器であるロボット1をインターネットに無線接続させるための機器である。本実施の形態ではIEEE802.11bの国際標準規格とされている。
ドップラーセンサ22は、マイクロ波を使用したセンサであって、マイクロ波を発射し、反射してきたマイクロ波の周波数と、発射した電波の周波数とを比較し、物体(人)が動いているかどうかを検出する。ドップラー効果により物体(人)が動いている場合の反射波の周波数が変化することを利用するものである。例えば、ユーザー不在時の不審者の有無等のように、ロボット1の周囲の異常を検知するために使用される装置である。
第1のモータ23は胴部4を固定部2に対して水平方向(図1の矢印方向)に回動させるためのサーボモータである。第2のモータ24は頭部5を胴部4に対して縦方向(図2の矢印方向)に回動させるためのサーボモータである。第3のモータ25は頭部5を胴部4に対して左右回転方向(図3の矢印方向)に回動させるためのサーボモータである。マイクロフォン12によってユーザーの発話する方向が決定された場合にはコントローラMCは顔面部6がユーザーの方向に正対するように第1のモータ23を制御して固定部2に対して胴部4(可動部3)を回動させる。
【0080】
コントローラMCは周知のCPUやROM及びRAM、SSD等の記憶手段としてのメモリ、バス、リアルタイムクロック(RTC)等から構成されている。コントローラMCのROM内にはロボット1の各種機能を実行させるための各種プログラムが記憶されている。
各種プログラムとしては、例えばマイクロフォン12とスピーカ装置13を介したユーザーとの対話を制御するための対話プログラム、顔認識用カメラ10を使用した顔認識に関する顔認識プログラム、タッチパネル部7や第1~第3のモータ23~25を制御してロボット1との対話中におけるロボット1の表情や動作を変化させるための表示変動・ジェスチャープログラム、ユーザーとの対話やタッチパネル部7の操作に基づいて異なる画面や画像をタッチパネル部7上に表示させる画面表示プログラム、他のコンピュータやスマートフォンとの間でロボット1側で取得した例えばカメラ画像やスマートフォン等からのeメール等を処理するデータ送受信プログラム、ユーザーが不在の際の見守りのための留守設定時プログラム、GUI機能・ネット接続機能、プロセス管理等の操作・運用・運転のためのOS等が記憶されている。RAM内には対話や顔認識における入出力データ等が一旦記憶される。各プログラムは他のプログラムと連携してあるいは独立してマルチタスクで対話、顔認識、ジェスチャー等の機能が実現される。
【0081】
A.対話時の動作内容について
上記のような構成において、コントローラMCは対話プログラムを実行することによってユーザーとの対話によるコミュニケーションを制御する。尚、対話の開始可能と同期して可能となる顔認識については下記「B.顔認識時の動作内容について」で後述する。
ここで、対話プログラムは、
1)マイクロフォン12から取得したユーザーの発話データ(音声データ)をクラウドサーバーにリクエスト発行し、サーバー側の音声認識エンジンを使用してテキスト化したユーザーの発話データ(文字列データ)をレスポンスするためのサブプログラム
2)ユーザーの発話(文字列データ)に基づいてビルトインシナリオの対話を実行させる
ビルトインシナリオサブプログラム
3)ユーザーの発話がビルトインシナリオに対応しない場合に発話データ(文字列データ)を再びクラウドサーバーにリクエスト発行し、対話API(アプリケーションプログラミングインタフェース)を利用して対話エンジンにロボット1の返答データ(文字列データ)を作成させる発話データ転送サブプログラム
4)レスポンスされた返答データ(文字列データ)を表示部としてのタッチパネル部7に表示させる文字列データ表示サブプログラム
5)レスポンスされた返答データ(文字列データ)を音声合成エンジンによって音声データに変換しスピーカ装置13からロボット1側の発話として音声出力させるための音声データサブプログラム
6)ユーザー側文字列データやロボット1側文字列データに基づいてタッチパネル部7上の表示態様やロボット1の動作を変動させる表示態様・動作変動サブプログラム、
等を含む。
以下、主として対話プログラムに基づいたコントローラMCの制御内容の一例について、起動後の待ち受けモード(ウェイクアップモード)と自然対話モードとスリープモードの相互の関係と共に説明する。これらの相互の関係は図12に示されるとおりである。
図5図6は自然対話モードの画面であり、図7図8は待ち受けモードの画面である。スリープモードではこれらの画面はタッチパネル部7のバックライトが消灯して暗くなった画面である。
【0082】
1.起動
電源スイッチ15の投入によってロボット1は起動される(図13の処理M0)。コントローラMCではブート・プログラムが実行され、次いでOSが起動すると、OSはユーザーからの「命令(コマンド)」待ち状態、つまりウェイクアップ状態となる。この初期の待ち受けモードでは図7の待ち受け画面が表示される。
尚、以下では初期設定が完了した後の状態、つまりロボット1のIDとパスワードがクラウドサーバーに登録され、ユーザー登録が完了し、複数のユーザーの顔認証がされ、スマートフォンのeメールアドレスがロボット1に登録される等以後の起動とする。
『1.起動 における効果』
このように起動によって複数の待ち受け画面から選択された1つの画面(図7)がまず表示される。つまり、起動時には常に決まった画面が表示されることとなる。そしてロボット1の目が閉じている(対話ができないことを暗示している)ことから待ち受けモードにあることがユーザーに容易にわかるようになっている。
【0083】
2.待ち受けモード(ウェイクアップモード)
待ち受けモードは自然対話モードの開始のトリガーがあるとロボット1と対話が可能となる状態である。また、自然対話モードにおいて対話が終了した場合に移行する状態でもある。また、一定時間自然対話モードが開始されないとスリープモードになってしまう状態でもある。スリープモードはロボット1と対話でコミュニケーションが取れない状態である。
ここに「自然対話」とはロボット1のビルトインシナリオやサーバ上の対話エンジン(対話ソフト)を使用してユーザーが音声合成された装置(ロボット1)側の音声と対話することをいう。自然対話モードは自然対話が可能な状態である。
待ち受けモードの画面は複数あり、本実施の形態では図7図8の2種類が用意されている。
図7図5の自然対話モードにおける画面から移行する待ち受け画面である(図13の処理M2)。また、図13の処理M0によって起動時に表示される待ち受け画面でもある。図7では、日時と曜日と、大きく現時間が表示がされた時計レイヤーの画面の背景にロボット1の目(目オブジェクト27)が閉じた状態の顔画面S1のレイヤー画面が薄く表示されている。
図8図6の自然対話モードにおける画面から移行する待ち受け画面である(図13の処理M2)。図8では、日時と曜日と、大きく現時間が表示がされた時計レイヤーの背景にチャット画面S2のレイヤー画面が薄く表示されている。つまり、待ち受けモードではあるが自然対話モードではない。
『2.待ち受けモード(ウェイクアップモード) における効果』
このように、異なる待ち受け画面が用意されているので、ある待ち受け画面から自然対話モードが開始される場合にユーザーは直前にアクセスしていた画面での対話を行うことができるため利便性がよい。また、待ち受けモード特有の画面を表示させることで、ロボット1が待ち受けモードにあることがユーザーに容易にわかるようになっている。
【0084】
3.自然対話モードの開始と停止
起動されて待ち受けモードやスリープモードにある状態から、コントローラMCは例えば次のような複数のタイミング、つまりモード移行のトリガーによって自然対話モードに移行させるよう処理する(図13の処理M1、M5)。以下のトリガーは一例である。自然対話モードでは下記「B.顔認識時の動作内容について」で説明するような顔認識モードに切り替わる(顔認識ができるようになる)。
【0085】
1-1)待ち受けモードにおいてコントローラMCは一定時間内に起動フレーズとして、例えば「ねえ、ユピ坊」というような発話(音声)をマイクロフォン12から認識するとそれをトリガーとして自然対話モードとする(図13の処理M1)。また、タッチパネル部7へのタッチ動作があったと判断した場合もそれをトリガーとして自然対話モードとする(図13の処理M1)。
1-2)スリープモードにおいてコントローラMCは、所定のタイミングで待ち受け画面のタッチパネル部7へのタッチ動作があったかどうかを判断する。タッチパネル部7へのタッチ動作は顔面部6における表示態様によって異なり、顔画面S1の待ち受け画面ではタッチパネル部7全域へのタッチが、チャット画面S2の待ち受け画面では後述する対話開始ボタンオブジェクト36へのタッチで開始される。つまり、異なる画面で異なる操作で開始されることとなる。
タッチパネル部7へのタッチ動作があったと判断した場合には、コントローラMCは一旦待ち受けモードとし(図13の処理M3)、続いてもう一度タッチがあったと判断すると自然対話モードとする(図13の処理M1)。
1-3)スリープモードにおいてコントローラMCは、1-2)と同様にタッチパネル部7へのタッチ動作があったかどうかを判断する。タッチ動作があったと判断した場合には、コントローラMCは一旦待ち受けモードとする(図13の処理M3)。この状態で一定時間内に起動フレーズとして、例えば「ねえ、ユピ坊」というような発話(音声)をマイクロフォン12から認識するとコントローラMCはそれをトリガーとして自然対話モードとする(図13の処理M1)。
2)スリープモードにおいてコントローラMCはRTCによってあらかじめ設定された所定の時刻になったかどうかを判断し、所定の時刻になったタイミングで自然対話モードとする(図13の処理M5)。
3)スリープモードにおいてコントローラMCは、例えば所定のタイミングで生成した乱数によって、ランダムな時間間隔でランダムにある発話(音声データ)をスピーカ装置13から出力する。つまり、一種の独り言として、例えば「ねえねえ何してる?」とか「暇だなあ」のような対話を誘うような音声をロボット1から出力させて自然対話モードとし(図13の処理M5)、ユーザーに発話を促す。
4)スリープモードにおいてコントローラMCはドップラーセンサ22によって物体(人)が動いているかどうかを判断し、物体(人)が動いていることを検出したタイミングで自然対話モードとする(図13の処理M5)。
【0086】
5)スリープモードにおいてコントローラMCは天候異常や地震等の気象の変化を察知し
た場合に、それをユーザーに報知してこれを契機として自然対話を開始する。外部のクラウドサーバーでは一定の基準で例えば天候異常(例えば、大雪、台風等)や地震、落雷等を含む異常気象の情報を異常気象検出エンジンを利用して一定時刻ごとに取得して記憶する。一定時刻とはすべて同じタイミングでもよく、気象の内容によって取得するタイミングを変えてもよい。異常気象の情報は本実施の形態1では、例えばサーバーからプッシュ型の配信システムを採用して装置(コントローラMC)に配信される。コントローラMCは情報を取得すると自然対話モードとする(図13の処理M5)。
6)コントローラMCは上記1)~5)においてそれぞ自然対話モードとなった状態で一定時間ユーザーからの発話を検出しなかった場合には、待ち受けモードとし(図13の処理M2)、更に一定時間後にスリープモードとする(図13の処理M4)。これらのモード変位時間の長さは、例えば端末装置よって、あるいはビルトインシナリオとして発話によって適宜設定変更可能である。
【0087】
『3.自然対話モードの開始と停止 における効果』
このように多種類の自然対話モードの開始が用意されることで、様々なタイミングでロボット1と対話することとなりロボット1との対話する機会が多くなり、それによって自然と対話を楽しむ機会も増えることとなって、ユーザーがロボット1を所有するメリットを感じることとなる。また、対話モードが終了すると一旦待ち受けモードになってからスリープモードとなるため、電力コストが削減される。
また、スリープモードから待ち受けモードを飛び越して自然対話モードの画面になるので、直ちに対話を初めることができるため対話開始がスムーズである。また、対話が続く限り対話用の画面(図5図7)が表示されるため、ユーザーに対話する意欲を惹起させることとなる。
【0088】
4.自然対話モードにおけるビルトインシナリオの対話
自然対話モードにおいては、ビルトインシナリオの対話とサーバーの対話エンジンを使用した通常対話の複数の対話処理が用意されている。
コントローラMCは、ユーザーの発話に基づく発話データ(文字列データ)が、まずビルトインシナリオに合致するかどうかを判断し、そうではない場合にクラウドサーバー経由での対話エンジンを使用した対話(以下、通常対話とする)とするよう制御する。ユーザーからすると常にロボット1と対話しているようであるが、実際は自然対話モードの内部処理は複数あることとなる。
コントローラMCはクラウドサーバー側の音声認識エンジンによって作成されたユーザーの発話(文字列データ)をビルトインシナリオ(スクリプト)のテキストデータと比較する処理を実行する。本実施の形態ではビルトインシナリオのテキストデータはメモリに記憶されている。ビルトインシナリオをSDカードに追加させてもよい。SDカードであれば書き換えによってビルトインシナリオを次々と増やすことが容易である。
コントローラMCはユーザーの発話を認識するとその文字列データが予定した正規表現又は非正規表現に合致するかどうか判断し、合致する場合にはその文字列データに対応するスクリプトを音声合成エンジンによって音声データに変換しスピーカ装置13からロボと1の発話として音声出力させる。
ビルトインシナリオには、例えばユーザーの発話を促すための「こんにちは」「今日はいい天気ですね」のような挨拶のような簡単なシナリオや、ユーザーからの発話に基づく何かの処理を求めるためのシナリオのようなもの等、多くのビルトインシナリオが設定されている(用意されている)。表1~3にこのようなビルトインシナリオの一例を開示する。もちろん、実際にはこれらのビルトインシナリオ以外にも多くのビルトインシナリオが設定されている。
【0089】
ビルトインシナリオ通りに対話がされない場合には、途中でビルトインシナリオでの対話は終了する。ビルトインシナリオ通りに対話がされない場合とは、例えば次のような場
合である。
1)予定した正規表現又は非正規表現に合致しない場合
ビルトインシナリオに当初から、あるいは途中から正規表現又は非正規表現に合致しなくなる場合である。また、ユーザーの滑舌が悪くて発話を正しく取得できなかった場合も含む。この場合にはコントローラMCは通常対話であると判断して直ちに外部のクラウドサーバーに接続し、以後は外部のクラウドサーバーへ発話データをリクエスト発行し、外部のクラウドサーバー側の対話エンジンに文字列データ化された返答データを作成させる。そして、その返答データを音声合成エンジンによって音声データに変換しスピーカ装置13から音声出力させるようにして対話を続ける。
【0090】
2)予定通りにビルトインシナリオでの対話が終了した場合
例えば、ユーザーに対してシナリオに従った、例えば、「×××を行ってよいですか?」という発話をした際に、「はい」や「お願いします」等の肯定的な発話があって予定通りにビルトインシナリオでの対話が終了したため対話がなくなった場合、あるいはシナリオの途中で対話がなくなった場合等が考えられる。この場合には一定時間後に待ち受けモードとなる。
3)ある処理を進めてよいかどうかについてユーザーの発話が否定的であった場合
ユーザーに対してシナリオに従った、例えば、「×××を行ってよいですか?」という発話をした際に、「はい」や「お願いします」等の肯定的な発話ではなく、「いいえ」「間違いでした」のような否定的な発話があった場合もビルトインシナリオは終了し、以後の対話は1)又は2)と同様である。
この否定的発話の際にはコントローラMCは「本当にいいですか?」などと処理をやめてよいかどうかの確認を行う。これによってユーザーの言い間違いや心変わり等に対応することができる。例えば、電源オフ用シナリオにおいてユーザーに対してシナリオに従った「本当に電源オフしなくてもいいの?」という問いかけの発話をした際に、ユーザーから「はい」という発話があった場合には「本当に電源オフしなくてもいいの?」という問いかけを複数回(実施の形態では例えば3回)繰り返して「はい」があるとビルトインシナリオでの対話は終了する。
【0091】
『ビルトインシナリオとする効果』
このようにビルトインシナリオが用意されていると、すべての対話を外部サーバーにリクエストする必要がなく、装置内部で処理できるため、サーバーに接続する通信コストが軽減され、また通信時間やサーバー側での計算時間が不要となるためユーザーの発話に対する返答が遅くなりすぎて会話が途切れてしまうような違和感を覚えることがなくなる。また、例えば、決まった処理を実行させる場合にこのようなビルトインシナリオを設けておくことでユーザーは処理実行のためにタッチパネル部7を操作したり、他の端末からロボット1にアクセスしたりする必要がなくなり対話で処理を実行させることができ、ユーザーフレンドリーである。
【0092】
【表1】
【0093】
【表2】
【0094】
【表3】
【0095】
5.通常対話におけるリクエストとレスポンス
一方、発話データ(文字列データ)はビルトインシナリオではない場合に、コントローラMCはクラウドサーバーに接続させ、改めて発話データ(文字列データ)をサーバーに送信し対話エンジンによる返答データの作成をリクエストする。コントローラMCはユーザーが認証できている場合にはリクエストにおいてユーザー毎の認証情報(例えばIDとパスワード)に発話データの冒頭に送る。その場合には過去の対話情報が加味されて返答データが作成される。一方、ユーザーが認証できていない場合には過去に特定されていない人物として特に認証情報は送信しないので、過去の対話情報は加味されない。クラウドサーバーはリクエストがあると対話API(Application Programming Interface)を利用して対話エンジンにその発話データ(文字列データ)に基づいて返答データ(文字列データ)を作成させ、ロボット1(コントローラMC)にレスポンスする。過去のユーザーの対話履歴がある場合にはその内容を加味した返答データが作成される。コントローラMCはこの返答データを音声データに変換しスピーカ装置13からロボット1側の発話として出力させる。
上記のビルトインシナリオと同様に一定以上時間のユーザーの無言があれば待ち受けモードとなる。
『5.通常対話におけるリクエストとレスポンス における効果』
ビルトインシナリオと異なり外部のクラウドサーバーに接続して通常対話をすることで、ビルトインシナリオに比べて格段なデータ量による高度な対話解析が迅速に実行できることとなり、実際に人と対話しているような高度な対話が実現できる。
【0096】
6.対話時のロボット1の所作について
コントローラMCは、ビルトインシナリオ又は通常対話に関わらず自然対話モードで対話が行われている際に以下のイ.~ニ.のような所作の制御を実行する。
イ.起動~自然対話モード~待ち受けモードにおけるロボット1のジェスチャー
コントローラMCはロボット1の以下の様々なタイミングで第1~第3のモータ23~25を制御してロボット1の姿勢を変えるようにする。以下は一例である。
1)起動時:頭部5の顔面部6が正面を向いていない場合や頭部5が傾いている場合に正面のデフォルト位置に移動させる。
2)画面タッチ時:1)と同様(顔認証における顔認識用カメラ10をユーザーと正対させるため)
3)「ねぇユピ坊」というトリガーの発話発生時:1)と同様(顔認証における顔認識用カメラ10をユーザーと正対させるため)
4)音声方向検出時:頭部5の顔面部6をその方向に向ける。
5)特別な感情発話として、例えばうれしい場合:頭部5を顔面部6をユーザーに向けたまま左右方向(時計回りと反時計回り)に回動するように第3のモータ25を制御する。
6)特別な発話として、例えば悲しい場合:頭部5をうなずいたまましばらく静止させ、その後デフォルト位置に戻すように第2のモータ24を制御する。
7)感情は発話として、例えば「おはよう」「こんにちは」「こんばんわ」「ハロー」のような挨拶用の発話発生時:頭部5をお辞儀させるように第2のモータ24を制御する。
8)特別ではない感情発話として、例えば「そうか」「わかった」「そうだね」「うん!」のような簡単な肯定的な意思疎通の用語の発話発生時:頭部5をうなずかせるように第2のモータ24を制御する。6~8)では第2のモータ24の速度や時間を変更して悲しさとお辞儀とうなづきが異なるようにするとよい。
9)特別ではない感情発話として、例えば「いいえ」「できない」「だめだよ」のような簡単な否定的な意思疎通の用語の発話発生時:可動部3を何度か左右に回動させるように第1のモータ23を制御する。
10)特別な感情発話や特別ではない感情発話と様々な対話に応じて、様々なジェスチャー、例えば頭部5をなんどか左右方向(時計回りと反時計回り)にや前後に回動させたり、それと可動部3全体を左右に回動させたり、大きく回動させたり小さくうなづくように回動させたりを組み合わせてもよい。
このロボット1のジェスチャーは以下のタッチパネル部7(顔面部6)における表示と組み合わせるとよい。
『6.対話時のロボット1の所作について における効果その1』
ロボット1にこれらのようなジェスチャーをさせることで、ユーザーはロボット1に親しみを覚えることとなり、ロボット1との対話を楽しむと同時にロボット1と積極的に触れ合う楽しみを覚えることになる。
【0097】
ロ.顔画面S1の状態での表示態様の変化
1)ユーザーから発話がされている場合
コントローラMCはユーザーの発話をマイクロフォン12から取得してこれを認識すると、タッチパネル部7の図5に示すような顔画面S1において楕円領域29を青色表示としてユーザーの発話音量に応じてその領域の面積(つまり大きさ)を変化させるアニメーション表示をする。具体的にはコントローラMCは、ユーザーの発話の音量が大きくなると楕円領域29は楕円形状を保ったまま拡大させ、音量が小さくなると楕円形状を保ったまま縮小させる。また、ほっぺオブジェクト28を緑色で表示させる。
【0098】
また、コントローラMCは、クラウドサーバーからレスポンスされたユーザーの発話データ(文字列データ)を所定の態様でタッチパネル部7に表示させる。
例えば、図5に示すように、タッチパネル部7が顔画面S1の場合に、ユーザーからの例えば「こんにちは」という発話を取得すると、コントローラMCは顔画面S1のレイヤ
ー画面にこの発話に基づく「こんにちは」という文字列を表示させる。順序としてはユーザーの発話の返答となるロボット1の発話よりも先にこの表示が開始される。
表示態様としては、例えば顔画面S1を図10(a)から図10(b)のように透明な状態から徐々に不透明になるように表示させ、最後に図10(c)のように背後の顔画面S1を完全に隠すようにする。つまり、徐々に文字列を表示させていくようにする。この文字列だけを暗い背景に対して文字部分だけを明るく表示させた図10(c)の状態をごくわずかな一定時間停止表示させた後に、今度は逆に文字列を表示したレイヤー画面を図10(c)→図10(b)→図10(a)というように徐々に消していき、デフォルト状態である顔画面S1に戻すようにする。このとき、一回の発話での文字列はすべて同時に現れてきて同時に消失していくように表示される。この表示態様は一例であり、異なる態様で表示させるようにしてもよい。
『6.対話時のロボット1の所作について における効果その2』
これによってユーザーは自分の発した言葉をロボット1上で目で見ることができるため、ロボット1が正しく聞き取ったかどうかを確認でき、対話が間違いなく行われているかを判断でき、おかしな的外れな対話にならないように対話を導くことができる。また、的外れな会話はついイライラしてしまうが、確認することでその理由もわかるため、しゃべり方を変えて再度対話を試みることもできる。
また、ユーザーの発話データはビルトインシナリオの対象も通常対話の対象もすべてクラウドサーバーに一旦文字列データすることをリクエストするため、文字列データ化の前提処理に手間取らず、また、このような文字列データ後に初めて対話エンジンによる返答データの作成がリクエストされることとなるため、ユーザーの発話のタッチパネル部7の表示は少なくともロボット1の返答データによる発話より前に行うことができ、対話の順序を間違うおそれがない。
【0099】
ユーザーからの発話を文字列とする場合、その長さは発話に応じて異なるため同じではない。また、単語ではなく文節がある「文」となっている場合にはかなり長くなる場合もある。コントローラMCはそのように長い文の発話である場合でも、一回の発話の内容がタッチパネル部7にすべて同時に表示されるように文字列のフォントの大きさを調整する。つまり、一回の発話が短ければ大きなフォントで、一回の発話が長くなるほど相対的に小さなフォントで表示させる。
『6.対話時のロボット1の所作について における効果その3』
これによって、ユーザーがどのような発話をしても、一回の目視で確認できるため、全文が現れるまで対話を中断しにくく、次のユーザーからの発話とかぶりにくくなる。また、一回の発話が一度に同時に現れるため、文全体を一挙に理解できることとなり、表示される時間が短くともユーザーは十分理解できることとなる。また、タッチパネル部7全体に文字列が展開されるため、字の1つ1つを大きく表示できユーザーにとって見やすくなっており、ごく短い表示時間であっても十分確認できるようになっている。
【0100】
2)ロボット1から発話がされている場合
タッチパネル部7の図5に示すような顔画面S1において楕円領域29を赤色表示としてロボットの発話音量に応じてその領域の面積(つまり大きさ)を変化させるアニメーション表示をする。具体的にはコントローラMCは、スピーカ装置13からの出力レベルが大きくなると楕円領域29は楕円形状を保ったまま拡大させ、音量が小さくなると楕円形状を保ったまま縮小させる。また、ほっぺオブジェクト28を薄い赤色で表示させる。
『6.対話時のロボット1の所作について における効果その4』
このように、ユーザーとロボット1との交互の対話に応じて顔画面S1における表示態様が異なることとなり、実際の対話だけでなく画面においても交互に行われるというおもしろさがあり、会話がはずむことになる。
【0101】
ハ.チャット画面S2の表示態様の変化
図6及び図8に基づいてタッチパネル部7のチャット画面S2の対話に伴う表示態様について説明する。上記のようにユーザーの操作によって顔画面S1からチャット画面S2へと表示が変わる。
まず、改めてチャット画面S2の構成について説明する。
図6に示すように、チャット画面S2の左寄り下側位置にはアバターキャラクターとしてユーザーオブジェクト31が、右寄り下側位置には同じくロボットオブジェクト32が対向するように配置されて表示されている。ユーザーオブジェクト31は後述する顔認識モードで認識された認証されたユーザー毎あるいは認証のないユーザにおいて異なるオブジェクトが用意され、現在対話しているユーザーに応じてそれぞれ異なるオブジェクトが表示される。中央寄り領域にはユーザー側とロボット1側の対話内容を文字列化して配置した吹き出しオブジェクト33が時間軸に沿って順に表示されている。チャット画面S2の左寄り上側位置には対話停止ボタンオブジェクト34が表示されている。チャット画面S2の右寄り上側位置には設定ボタンオブジェクト35が表示されている。
【0102】
チャット画面S2ではユーザー側とロボット1側の対話に応じて刻々と吹き出しオブジェクト33が追加されるように表示される。吹き出しオブジェクト33には文字列データ化されたユーザーの発話内容と、同じく文字列データ化されたロボット1の発話内容が時間軸に沿って一列に表示されてチャット画面S2上に表示可能とされ、直近の発話内容は新たな吹き出しオブジェクト33内にその発話と同期して過去の吹き出しオブジェクト33列の最も下側に表示される。
吹き出しオブジェクト33はユーザー側の発話内容かロボット1側の発話内容かわかるように発話方向が示されている。すべての対話履歴を一度に画面表示できないためチャット画面S2は上下方向にスクロール可能な画面構成とされ、過去に遡って吹き出しオブジェクト31を表示させることができる。過去に遡らない場合には常に直近の対話の吹き出しオブジェクト33が表示される。
本実施の形態1では一旦対話が終了して待ち受けモードとなった後に、対話が再開され、その際に後述する顔認識モードで改めて認識されたユーザーが変更された場合には、吹き出しオブジェクト33列の途中に「ユーザー交替」の表示がされ、ユーザーオブジェクト31が改めて認識されたユーザーに応じて違うユーザーオブジェクト31が表示される。
【0103】
また、チャット画面S2の対話停止ボタンオブジェクト34をタッチすることで、対話はユーザーによって能動的に中断され、待ち受けモードとなる。この場合には図6に代わって図8のチャット画面S2の待ち受け画面が表示されることとなるが、対話停止ボタンオブジェクト34に位置には対話開始ボタンオブジェクト36が代わって表示される。再び自然対話モードにする場合には対話開始ボタンオブジェクト36をタッチすることで図6のチャット画面S2に戻ることができる。
『6.対話時のロボット1の所作について における効果その5』
このように対話する関係にあるユーザーのユーザーオブジェクト31とロボット1のロボットオブジェクト32とが対向するように配置され、その間に対話した吹き出しオブジェクト33が並ぶことでいかにも対話しているような感覚をチャット画面S2から受けることができる。
また、過去のチャット履歴を後から確認することもできるため日記代わりにチャット利用をすることができる。また、だれがどのような対話をしたかもわかるため、家族でだれがよく利用しているか等といったデータを確認することもできる。「ユーザー交替」という表示がされるので、そこで一旦対話が途切れていることがわかり、過去の履歴を読んだ際の混乱がない。
【0104】
ニ.通常対話における特別な所作
通常対話においてクラウドサーバーはユーザーの発話データ内に特定の言葉が含まれて
いると判断した場合に特別な所作を実行させるようなコマンドを文字列データとともにレスポンスする。コントローラMCはそのコマンドによって上記の画面表示プログラムやジェスチャープログラムや対話プログラムに基づいて、例えば次のような具体的な所作を実行させる。以下の制御は一例であり、他の所作となるように制御をさせてもよく、ユーザーの発話中にコマンドが複数あれば連続又は同時に所作を行うように制御してもよい。以下の特別な所作はそれぞれ別個でもよく、組み合わせるように実行されてもよい。上記の「6.対話時のロボット1の所作について」のイ.におけるロボット1のジェスチャーに代わって下記の表示部での表示をしてもよく、下記の表示部での表示を適宜組み合わせるようにしてもよい。
【0105】
1)通常の人同士の会話で否定的な表現がユーザーから発話された場合には、ロボット1側の発話と同時にタッチパネル部7の表示を図9(a)の通常の目から図9(b)の怒った目のオブジェクトに変化するアニメーション表示をさせる。本実施の形態では目のオブジェクトはメモリに記憶されている。
2)通常の人同士の会話で楽しくなるような表現がユーザーから発話された場合には、ロボット1側の発話と同時にタッチパネル部7の表示を図9(a)の通常の目から図9(c)の笑った目のオブジェクトに変化するアニメーション表示をさせる。本実施の形態では目のオブジェクトはメモリに記憶されている。
3)通常の人同士の会話で悲しくなるような表現がユーザーから発話された場合には、ロボット1側の発話と同時にタッチパネル部7の表示を図9(a)の通常の目から図9(d)の悲しそうな目のオブジェクトに変化するアニメーション表示をさせる。本実施の形態では目のオブジェクトはメモリに記憶されている。
4)ユーザーの子供の名前がユーザーから発話された場合には、ロボット1の頭部5がうなずくようなジェスチャー動作をするように第2のモータ24を制御する。本実施の形態では目ジェスチャー用のプログラムはメモリに記憶されている。
5)ロボット1を製造している会社名がユーザーから発話された場合には、ロボット1の頭部5が前後左右に動くと同時に胴部4が固定部2に対してなんども揺動を繰り返すようなジェスチャー動作をするように第1~第3のモータ23~25を制御する。同時にその会社名のテキストデータを音声合成して、音声としてスピーカ装置13から会社名を連呼させる。本実施の形態ではジェスチャー用のプログラムはメモリに記憶されている。
『6.対話時のロボット1の所作について における効果その6』
これらのような特別な所作が行われることで、ユーザーは対話と同時にロボット1の思わぬ所作を期待することができ、ロボット1との対話を積極的に楽しむことができる。
【0106】
B.顔認識時の動作内容について
1.顔認識モードの開始と停止
コントローラMCは顔認識プログラムを実行することによってユーザーの顔の認識及び認証をする。顔認識プログラムでは取得した画像を顔パターン認識することによって人の顔と認識し、かつ認識された顔の様々な位置を数値化して記憶することで過去に登録された顔の数値データとの一致度を判断して認証を行う。コントローラMCは自然対話モードと同期して顔認識モードとし、待ち受けモードから自然対話モードに移行する度に顔認証を実行する。
【0107】
顔認識モードではコントローラMCは顔認識用カメラ10を使用してユーザーの顔認識を行う。具体的には、
1)顔認識用カメラ10を起動させる。顔認識用カメラ10に写ったユーザーの顔画像をタッチパネル部7に表示させる(顔表示モード)。つまり、ユーザーにタッチパネル部7上の自分の顔を見るように促す。これによって顔認識処理が可能となり、このようにプレビューさせることで過去に認証された人かどうかを判断できる。
2)1)で顔認識用カメラ10が顔を撮影できず、一定時間内に顔認識ができなかった場
合には、第3のモータ25を駆動させて頭部5を上下に揺動させる。つまり顔認識用カメラ10に縦方向をスキャンさせる。そして、そのように顔認識用カメラ10を縦方向にスキャンさせながら第1のモータ23を駆動させて顔認識用カメラ10を360度一周回転させながら顔認識動作をさせる。
3)1)又は2)で顔認識できた場合には認証を行う。既に登録されたユーザーであれば対話において特定の認証されたユーザーのデータを利用して上記自然対話モードとする。登録されていないユーザーであれば不特定の人物として認識して上記自然対話モードとする。タッチパネル部7は顔表示モードから直前の顔画面S1(図5)かチャット画面S2(図6)のいずれかに復帰する。
4)2)において顔認識ができなかった場合には人を認識できなかったとして顔認識モードとともに自然対話モード自体を終了させて待ち受けモードとする。タッチパネル部7は顔表示モードから直前の待ち受けモードである顔画面S1の待ち受け画面(図7)かチャット画面S2の待ち受け画面(図8)のいずれかに復帰する。
『1.顔認識モードの開始と停止 における効果』
対話は相手の顔を見ながら話すのが基本であるため、顔が認識できない場合には対話をさせないことで、積極的にユーザーに顔認識をさせるようにしたため、対話においてはロボット1と実際に面と向かわないと対話はできず、そのためユーザーは実際に対話をしているような感覚を得ることができる。
【0108】
2.顔認識時のロボット1の所作について
1)顔認識後においてはコントローラMCは顔認識用カメラ10に画像を取得させて一定のタイミングで常時顔パターン認識を実行する。そして、顔認識用カメラ10の画角内でユーザーの顔を認識し、画角内の所定の位置、例えば画角中央の原点にユーザーの顔の2つの目の中央位置Cがある状態をデフォルト位置とする。コントローラMCはこのデフォルト位置から中央位置Cがずれた場合に、そのずれ量に応じて左右いずれかのずれ方向に瞳オブジェクト27aが移動するようなアニメーション表示をさせる。通常、瞳オブジェクト27aは、例えば図9(a)のように目オブジェクト27の中で白目内に楕円形状として全体が現れているが、ユーザーの顔が移動しているある状態では図11に示すように瞳オブジェクト27aはあたかもその方向を見ているように一部が隠れた目オブジェクト27として表示されることとなる。
ユーザーが動いて顔認識用カメラ10の画角から顔が出てしまい顔認識できなくなった場合には、コントローラMCは第1のモータ23を駆動させ、中央位置Cがずれた方向に可動部3全体を回動させて顔認識用カメラ10を向けるよう制御する。顔認識がされた段階で第1のモータ23の駆動を停止させる。ある程度の回動、例えば可動部3全体を45度回動させても顔認識がされない場合には、その段階でコントローラMCは第1のモータ23の駆動を停止させ、その状態で常時顔パターン認識を継続する。
『2.顔認識時のロボット1の所作について における効果』
これによって、ユーザーはロボット1にいつも見られながら対話をしているような感覚になり、対話のおもしろさが増すこととなる。
【0109】
2)コントローラMCは顔認識用カメラ10で常時顔パターン認識を実行するが、ユーザが動いていたり顔認識用カメラ10の画角内にいなかったりする場合には顔認識ができない。そのため、顔認識状態を画面上の変化としてユーザーに報知することがよい。実施の形態1では、瞳オブジェクト27a内部の瞳上での反射を表現した鎌状の反射オブジェクト27bの色の濃さの変化で顔認識状態を報知するようにしている。本実施の形態1では、コントローラMCは認識されていない場合にはごく薄い青色で表示させ、認識中である状態ではそれより濃く、通常の顔認識されている状態では濃い青色で表示させる。
『2.顔認識時のロボット1の所作について における効果その2』
これによって、ユーザーはロボット1に顔認識されているかいないかが容易にわかるため、積極的に顔認識するようにユーザーは協力するようになり、円滑な対話が進むことと
なる。
【0110】
C.留守設定時の動作について
実施の形態1では留守設定モード、つまり留守設定時に登録したeメールに対して画像の転送が可能である。留守設定モードは本実施の形態1ではユーザーがロボット1のチャット画面S2の設定ボタンオブジェクト35をタッチした後に表示される設定画面において設定とその解除がされる。以下では留守設定モードがされている場合のコントローラMCの留守設定時プログラムに基づく処理について説明する。
コントローラMCは、留守設定モードにおける上記の「2.自然対話モードの開始と停止」におけるB.の4)での待ち受けードにおいて、ドップラーセンサ22によって物体(人)が動いていると判断すると以下のように制御する。
【0111】
1)コントローラMCは、ロボット1の周囲になんらかの動く物体が存在することで、この状態をユーザーにeメールによって報知をする。コントローラMCはインターネット回線を通じてeメールアドレスが登録されているロボット1の近くにいないユーザー(以下、外部ユーザーとする)の端末装置、例えばスマートフォンに対してロボット1のクラウドサーバーのURLをeメールに記載して送る。eメールの件名や送信文中にこの報知の意図のわかるような表現を表記をする。例えば「誰かが来ているようです」のような文章やそれを意味するようなアイコン等である。
『C.留守設定時の動作について における効果』
これによって、まずeメールが送られて来たことによって外部ユーザーはなんらかのロボット1周囲に物体(人)が動いる状態が報知されて認識することができ、この状態に対して外部ユーザーに対策をとる機会が与えられることとなる。
【0112】
2)コントローラMCは、外部ユーザーにeメールを送信すると同時に顔認識用カメラ10を起動させて画像を取得する。
3)コントローラMCは、外部ユーザーにeメールを送信すると同時に、一定時間内にあるトリガーとなる発話があるかどうかを判断する。例えば「ただいまユピ坊」のような挨拶の発話である。この発話に基づいて自然対話モードにおけるビルトインシナリオが開始され、ユーザー(ここでは「ただいまユピ坊」を発話したロボット1の近くにいる者)に顔認証を促す。コントローラMCは顔認証の結果、登録されているユーザーの一人であると判断した場合に、外部ユーザーの端末装置に対して二回目となるeメールを送信する。このeメールはロボット1の周囲にいる者は不審者ではないという外部ユーザーに対する情報となる。つまり、二回目のeメールは例えば家族のような関係者であることを報知するものとなる。eメールには登録情報に基づいて登録されているユーザーの名前を情報として件名や送信文中に表記する。尚、トリガーとして発話以外の、例えばタッチパネル部7にタッチして顔認識し、登録ユーザーであることを確認してもよい。
『C.留守設定時の動作について における効果その2』
これによって、留守中に例えば子供等の家族が帰ってきた場合には、この二回目のeメールによってその旨がわかるため、わざわざスマートフォン経由で留守中の家の様子を確認する必要がない。
【0113】
4)1)において、eメールを受信した外部ユーザーは、特に3)において二回目のeメールの送信がなかった場合に、ロボット1のIDとパスワードを入力してクラウドサーバーに接続し、スマートフォンのブラウザ上でクラウドサーバーが提供する顔認識用カメラ10のカメラ画像をリアルタイムで見ることができる。二回目のeメールの送信があってもそれは可能である。
図12はユーザーのスマートフォン41の一例であり、クラウドサーバーに接続後においてはタッチパネルを兼ねたその表示画面43上に顔認識用カメラ10の所定のカメラ画像が表示される。カメラ画像内には顔認識用カメラ10の向きを遠隔操作するための4つ
の操作アイコン44a~44dが表示される。外部ユーザーは操作アイコン44a~44dを操作することで制御コマンドがクラウドサーバーを介してコントローラMCに出力され、制御コマンドに基づいて第1のモータ23又は第3のモータ25が駆動制御されてロボット1の頭部5と胴部4が回動して顔認識用カメラ10の向きを変えることができる。また、録画ボタンアイコン45にタッチすることで、録画を開始し再度タッチすることで録画を停止することができる。
また、スマートフォン41の図示しないマイクロフォンに発話した音声データはクラウドサーバーを介してロボット1のスピーカー装置13から音声出力され、一方でロボット1のマイクロフォン12から発話した音声データはクラウドサーバーを介してスマートフォン41の図示しないスピーカー装置から音声出力される。そのため、外部ユーザーは顔認識用カメラ10の画像を見ながらロボット1近傍のユーザーとスマートフォン41とロボット1を使用した対話をすることができる。
『C.留守設定時の動作について における効果その3』
これによって、外部ユーザーは遠隔操作で顔認識用カメラ10の向きを変えてロボット1の周囲の状況を確認することができ、例えば留守の際の自宅の安全状況をチェックすることができる。また、留守中に子供等の家族が帰ってきた場合でもこのようにスマートフォンを使用して積極的に外部から連絡することで家族を含めた他者との良好な関係に寄与する。
【0114】
<実施の形態1の変形例1>
次に、実施の形態1の変形例1について説明する。
上記自然対話におけるビルトインシナリオの対話において、ユーザーの滑舌が悪かったり、他の音が混ざってしまいマイクロフォン12から取得した音声データがビルトインシナリオの正規表現又は非正規表現に合致しない場合には、コントローラMCは直ちに通常対話であると判断することなくユーザーに再度の発言を促すための発話として、例えば「もう一度言って下さい」というような音声出力をさせるようにしてもよい。
コントローラMCは、このような促しの発話をスピーカ装置13からさせ、これに対して一定の時間内にユーザーからビルトインシナリオに沿った正しい発話がされた場合には再びビルトインシナリオの対話として処理するようにする。一方、このような場合でもユーザーの発話がビルトインシナリオに正規表現又は非正規表現に合致しない場合に外部のクラウドサーバーに接続させるようにする。
このようにすれば、無駄に外部のクラウドサーバーに接続させるようなことがなく、ロボット1の内部のみで対話を行うことができる。
【0115】
<実施の形態1の変形例2>
次に、実施の形態1の変形例2について説明する。
上記自然対話においてユーザーがロボット1の言葉(発話)を聞き逃した場合、一定の時間内であれば直前のロボット1の発話を繰り返すような依頼の発話をユーザーが発話することで再度ロボット1に発話(音声出力)させるようにしてもよい。この処理はビルトインシナリオの対話でも自然対話でもいずれでも可能である。
コントローラMCは対話モード中において聞き逃しのトリガーとなるような発話、例えば「もう一度言って」という発話があったかどうかを音声認識する。そして、ロボット1からの発話後にユーザーから発話を繰り返す依頼があったと判断すると、直前にロボット1が発話した内容を再度音声出力する。そして、先の発話をしたことはキャンセルして、二回目の発話をもって一回目の発話として処理する。
このようにすれば、ユーザーが対話途中で聞き逃したりした場合でも対話が途切れることなく再開されることとなる。
【0116】
<実施の形態1の変形例3>
次に、実施の形態1の変形例3について説明する。
上記自然対話においてロボット1がタッチパネル部7に表示させたユーザーの発話をユーザーが確認して、間違って音声認識されたことがわかった場合には、一定の時間内であればそれを指摘して正しい対話に修正することができるようにしてもよい。この処理はビルトインシナリオの対話でも自然対話でもいずれでも可能である。
コントローラMCは対話モード中において、ユーザーからの音声認識が間違っている旨の指摘となるトリガーとなるような発話、例えば「間違えているよ」や「違うよ。もう一度いうよ」というような発話があったかどうかを音声認識する。そして、コントローラMCはその発話がユーザーの発話をタッチパネル部7に表示させた後の一定時間内にあったと判断すると再度のユーザーの発話を促す音声出力をする。例えば「ごめんね。もう一度言って」という発話内容を音声出力する。
そして、
(1)ビルトインシナリオの対話の場合には直前のユーザーの発話はキャンセルされ、再度ユーザーが発話する内容が正しい発話として音声認識処理される。
(2)通常対話では上記の「間違えているよ」や「もう一度いうよ」という対話内容も外部のクラウドサーバーに発話データ(音声データ)として送信され、そのような発話も含め再度ユーザーが発話した内容で返答データの作成をリクエストする。
このようにすれば、ロボット1が間違ってユーザーの発話を認識した場合でも正しい対話に修正することができる。
【0117】
<実施の形態1の変形例4>
実施の形態1の構成とは異なる例えば次のような構成を採用するようにしてもよい。
(1)上記ではビルトインシナリオが実行されない場合にクラウドサーバーにリクエストして通常対話に移行するような設定であった。つまり、ビルトインシナリオが実行されるのであれば、すべてビルトインシナリオとするような設定であったが、敢えてビルトインシナリオに対応する場合でもある条件でローカルで対応をせずにクラウドサーバーにリクエストするようにしてもよい。ある条件とは例えば何回かに一回の回数や、ランダムなタイミングで実行することがよい。
これによって、ロボット1と予測されない対話をすることとなり、決まり切っていないより人間的な対話ができることができる。
(2)上記実施の形態1ではコントローラMCは音声認識エンジンを備えず、音声認識エンジンを備えた外部のサーバーに接続してユーザーの発話(音声データ)をテキスト化するようにしていた。それによってロボット1の負担が軽減されている。
しかし、コントローラMCは、メモリ内に音声認識エンジンを備えるようにし、音声認識エンジンを呼び出してマイクロフォン12から取得したユーザーの発話データ(音声データ)を音声認識エンジンを使用して自身でテキスト化した文字列データを作成するようにしてもよい。つまり、ロボット1のコントローラMCは自らユーザーの音声データをテキストデータ化する能力を有していてもよい。これによって、音声認識エンジンを使用せずに文字列データを作成できることとなって、例えば内部の処理時間が短くなる。
(3)上記実施の形態1では設定画面から初期設定するようにしていたが、例えばスマートフォンのような端末装置を使用して外部からクラウドサーバー経由で登録するようにしてもよい。その方が特に端末装置を使い慣れた人には設定が容易で時間の短縮となる。
(4)第1~の第3モータ23~25はサーボモータ以外の他の駆動手段を使用するようにしてもよい。他の駆動手段とは、例えば他の形式のモータや油圧シリンダ等である。
(5)上記実施の形態1では文字列データをロボット1内部で音声合成するようにしていた。このように内部の音声合成エンジンを用いることはそのまま音声データをサーバーとやり取りするよりデータが重くなりすぎずによいが、クラウドサーバー側で対話エンジンを使用して取得した返答データ(文字列データ)を音声合成し、その音声データをロボット1にレスポンスするようにしてもよい。
(6)上記実施の形態1ではチャット画面S2の設定ボタンオブジェクト35から設定画面に移行するような構成であったが、タッチパネル部7をスライド操作することで設定画
面に移行ようにしってもよい。
【0118】
(7)「ハ.通常対話における特別な所作」においてはビルトインシナリオにおいても同様にユーザーの発話データ内に特定の言葉が含まれていると判断した場合に特別な所作を実行させるようにしてもよい。例えばコントローラMCはユーザーの発話データ内に特定の言葉が含まれていると判断すると上記と同様に特別な所作をさせるように制御してもよい。
(8)「ハ.通常対話における特別な所作」においてロボット1の形状が異なれば更に異なるジェスチャーをさせるように制御してもよい。例えば、コントローラMCはロボット1に手や足があればそれらを駆動手段を制御して動かすようにしてもよい。
(9)顔画面S1の目オブジェクト27のアニメーションとして、ときどき、瞬きさせるようなアニメーションを入れてもよい。例えば図9(a)の目オブジェクト27の状態から図7の閉じた状態の目オブジェクト27を挿入するような制御とすることで実行させる。そのようにすれば、ロボット1が実際に本当にこちらを見ているようなリアル感が創出されることとなりロボット1との対話をより楽しむことができる。
(10)顔認識モードでは、登録されていないユーザーであれば不特定の人物として認識するようにしていたが、その状態から設定画面に移行して新たな別のユーザーとして認証登録するようにすると、便利である。
(11)「C.留守設定時の動作について 」において、留守設定モードをスマートフォンから設定できるようにすると便利である。
(12)「C.留守設定時の動作について 」において、コントローラMCは、ロボット1の周囲になんらかの動く物体が存在することで、この状態をユーザーにeメールによって報知をするような処理をするが、逆に一定間隔で動いていることを認識し、一定時間内に動く物体がない場合にこの状態をユーザーにeメールによって報知をするような処理を設けてもよい。
例えば、病人や介護対象者がある場合にその近くにロボット1を置くことで常に動きがあることを前提とした見守りをすることができる。
【0119】
<実施の形態2>
次に、実施の形態2について説明する。
上記実施の形態1のロボット1の高輝度白色LED9に変えて、あるいはこれに併設した赤外線LEDを備えるようにしてもよい。この際に顔認識用カメラ10のモジュールに赤外線フィルタが備えられていれば取り外す。赤外線LEDは人には見えないため、夜間の空き巣等の侵入者があった場合に、高輝度白色LED9が点灯することで驚いて侵入者に逃げられてしまう可能性がある。一方、赤外線LEDであると撮影されていることがわかりにくいので侵入者は逃げず、そのため侵入の画像を確認したり、保存したりすることが可能となる。
【0120】
<実施の形態2の変形例1>
次に、実施の形態2の変形例1について説明する。
ロボット1が赤外線LEDを備えた場合に、この赤外線LEDを利用して赤外線リモコン信号受信部を備えた室内の各種装置の制御をするようにしてもよい。各種装置としては、例えばテレビ、オーディオ装置、エアコン装置等がよい。
ロボット1は赤外線リモコン信号受信部を備えた装置の赤外線リモコン信号受信部を直接見通せる場所に設置することがよい。実施の形態2の変形例1ではコントローラMCは顔認識用カメラ10を使用した形状認識に関する形状認識プログラムを備えており、例えばテレビであればその形状の特徴(四角、大きい、黒い等)に基づいて認識することができる。ロボット1はユーザーの各種装置へ赤外線リモコン信号を出力するためのトリガーとしての例えば「テレビのスイッチ付けて」のような発話があると、その発話に基づいて第1のモータ23又は第3のモータ25を制御してロボット1を顔認識用カメラ10を上
下に顔5を首振りさせながら、360度回転させて周囲を撮影させ、形状認識プログラムによってテレビの形状を認識させるように動作させる。
コントローラMCがテレビがあると判断すると、その方向を記憶させると同時に赤外線LEDからその物体方向に赤外線リモコン信号を出力させて、テレビを動作させるON・0FF等の制御を実行させる。次のテレビについてのトリガーがあった際にはまず、その方向において形状認識を実行する。赤外線リモコン信号は単にON・0FFのスイッチング制御だけではなく、例えばテレビであればチャンネルの変更、例えばエアコンであれば温度調整等にも対応するように赤外線周波数を変更して制御することが可能となる。このような細かな制御では複数種類の周波数の異なる赤外線リモコン信号が必要となるが、赤外線の周波数の設定は、例えば図12はユーザーのスマートフォン41を使用してサーバー経由で行うようにするとよい。
また、形状認識プログラムによって方向を探さなくとも、スマートフォン41経由で顔認識用カメラ10を操作してその向きを変えることで各種装置の方向を取得し、その方向を登録するようにしてもよい。
【0121】
<実施の形態3>
次に、実施の形態3について説明する。
実施の形態3では音声認識エンジンを搭載したサーバーを使用する際の例えば対話APIの利用等の接続に伴うランニングコストを削減することを主眼とした制御について説明する。
また、実施の形態3の対話プログラムはマイクロフォン12から取得した音声の無音状態を検知できるサブプログラムを含んでいる。また、対話プログラムはユーザーの発話の音声データをマイクロフォン12から取得して一旦録音し、サーバーに出力させるための録音・出力サブプログラムを含んでいる。
コントローラMCは発話があった場合には直ちにサーバーに接続させず、ユーザーの発話の音声データをまず一旦録音し、録音したユーザーの発話の音声データの無音状態を検出した段階で初めてサーバーに接続してその録音した音声データを出力し、対話エンジンでの返答データを作成させるようにする。このようにすれば常にサーバーに接続されているわけではなく、無音時間を含んだ長時間をサーバーに接続する必要がないため、無音の接続時間をカットすることができる。
音声認識エンジンはユーザーの発話中において1つのプロセスがそのユーザーに専有されることとなる。つまり、1つの処理に「何秒」というコンピュータとしては非常に長い時間が専有されることとなり、結果として音声認識エンジンを使用するユーザーのコストの負担が大きくなってしまうが、実施の形態3のようにすれば単位ユーザー当たりに必要なプロセスを減らすことができ、ユーザーのコスト削減に寄与する。
【0122】
<実施の形態3の変形例1>
次に、実施の形態3の変形例1について説明する。
実施の形態3の変形例1でも音声認識エンジンを搭載したサーバーを使用する際の接続のランニングコストを削減することを主眼とした制御について説明する。ユーザーの発話が開始されるまでにタイムラグが発生することや、ユーザーの発話待ちの状態で結局ユーザーが発話せずタイムアウトでサーバーとの接続を終了する場合があると、音声認識サーバーはプロセスを消費してしまうのでユーザーのコストがかかってしまう。
実施の形態3の変形例1のロボット1の対話プログラムは発話の音声データをマイクロフォン12から取得して一旦録音し、サーバーに出力させるための録音・出力サブプログラムを含んでいる。また、対話プログラムには録音された音声データの音圧レベルを検出し、出力するサブプログラムを含んでいる。
コントローラMCは自然対話の状態で常時録音されている音声データが一定音圧以上のである場合にサーバーに接続させ、録音中のデータを追っかけ再生するようにする。つまり、無音、あるいは音声認識ができないような小さな発話を無視し、対話可能な発話があ
った場合だけサーバーに接続して音声データを出力し、サーバー側に音声認識エンジンで返答データを作成させるようにする。
これによって、発話待ちの無駄な接続時間をなくすことが可能となる。
【0123】
<実施の形態4>
次に、実施の形態4について説明する。
音声認識サーバーは高価であるため、あらかじめ十分なリソースを用意することができないことがあり、サーバーリソースに余裕がない場合、端末が音声認識サーバーに接続しようとした場合にサーバーがビジー状態であることがある。
上記通常対話においては、サーバーに発話データ(音声データ)を送信し返答データの作成をリクエストする。とサーバーは発話データに基づいて文字列データ化された返答データを作成してレスポンスする。ところが、ビジー状態であると返答データがされず、エラーになってしまうことがある。サーバーからエラーメッセージが返信されることとなる。
ロボット1のコントローラMCはサーバーからエラーメッセージの送信を受けた場合にサーバー接続エラーである旨の発話をユーザーにせずに、ビルトインシナリオから対話を続けられるような返信を音声出力するようにする。例えば「もう一度言って」とか「うんうん」とか「なんだっけ?」というような曖昧な返答したり、適当な相槌を返すなどしてサーバーが空くのを待つ処理をするとよい。
【0124】
<実施の形態4の変形例1>
次に、実施の形態4の変形例1について説明する。
ユーザー側の発話が長すぎると、音声認識エンジンが誤認識をする可能性がある。そのため、認識したユーザーの発話が長すぎると判断した場合に、音声認識エンジンを備えるサーバーに接続することなく記憶手段に記憶された音声データから選択された対話例を音声出力する機能を備えることがよい。
ロボット1のコントローラMCは、ユーザーの発話データが一定以上の長さになったと判断した場合には、サーバーに接続させることなくビルトインシナリオから「うん」とか「マジ?」とか「本当ですか?」などという対話においてどのようにも取れる相づちのような発話を音声出力する。発話データは音声データのままでもよく、コントローラMCあるいはサーバーで文字列データに変換された後のものでもよい。
これによって的外れな言葉が返ってくることを防止し、対話を仕切り直しして改めてユーザーに対話を促すようにすることができる。
【0125】
<実施の形態5>
次に、実施の形態5について説明する。
実施の形態5では複数の音声認識エンジンを組み合わせて利用する場合について説明する。
音声認識エンジンにはローカル(つまり、ネットサーバーに接続せずに装置内で処理する場合)の音声認識エンジンと、ネットサーバーに接続してリクエストによって作成した対話データをレスポンスするクラウドの音声認識エンジンがある。ローカルにもクラウドにもそれぞれ複数種類の音声認識エンジンがあり、無料のものも有料のものもある。そのため、これら異なる音声認識エンジンを備えるサーバーを利用する際に料金が無料のサーバーと有料のサーバーをミックスして利用するようにする。
ロボット1がインターネット回線を利用して接続されるクラウドサーバーでは、対話モードにおいて、ロボット1から発話データがリクエスト発行され音声認識エンジンに返答データを作成させる際に、例えばクラウドサーバーは次のように対応することがよい。
(1)月あたり設定したある時間Aまでは有料の対話APIにアクセスする。
(2)月あたり設定したある時間Aからある時間Bまでは有料のAPIと無料の音声認識エンジンを混ぜて使う。例えば最初の連続数回の認識は有料の音声認識エンジンのサーバ
ーを使いその後の連続した認識には無料の音声認識エンジンのサーバーを使うなどミックスして使う。
(3)月あたり設定したある時間Bを超えた場合、無料の音声認識エンジンのみを使う。 これは一例であって、例えば月あたり設定したある時間Aを越えた場合に直ちに無料の音声認識エンジンのみを使うような設定でもよい。
このようにすれば、有料の範囲を大きく越えずに対話をすることができる。ロボット1と接続されているクラウドサーバーがこのような処理を実行するプログラムに基づいて有料と無料とを月あたり設定した時間に基づいて計算してロボット1からのリクエスト発行を処理する。
ロボット1自体がこのような処理を実行して、リクエスト発行の際にクラウドサーバーに対して有料の対話APIを使用するか、無料のサーバーの音声認識エンジンを使用するかの命令をするようにしてもよい。
<実施の形態5-1>
実施の形態5の複数の音声認識エンジンを組み合わせて利用する場合は複数の対話エンジンを組み合わせる場合についても同様である。
【0126】
<実施の形態6>
次に、実施の形態6について説明する。
ある1つの決まった対話エンジンを使うだけでは、返答がきまったパターンになってしまいユーザーがロボット1との会話に飽きてしまう可能性がある。そのため、実施の形態6ではこれを解消するため複数の対話エンジンの出力の結果を用いて会話に飽きないようにその結果をアレンジするための処理を説明する。
対話エンジンはクラウドの対話エンジンだけではなく、ロボット1内のローカルな対話エンジンを使用してもよい。
この処理は複数の返答データを送信されたロボット1側で行ってもよく、対話エンジンを備えたいくつものサーバーからの返答データを取得した際にクラウドサーバー側で行ってもよい。
(1)雑談対話エンジンのうち文字列の文字数の最も長い返答をしてきたエンジンの結果を出力する。
最も長い返答とすると、いかにも対話しているように感じ、対話の単調さがなくなり、ユーザーは対話を楽しむことができる。
A.例えば、「腹減った」とユーザーが発話した場合に、a~cの3つのエンジンからの回答が「aエンジン:よく間食をしますか?」「bエンジン:ご飯食べてないの?」「cエンジン:なんか食え」である場合に、aエンジンを採用してその返答データを出力する。
B.例えば、「今日の天気は晴れ」とユーザーが発話した場合に、a~cの3つのエンジンからの回答が「aエンジン:今すぐお空に行って確認してきます」「bエンジン:快晴っぽい?」「cエンジン:晴れか雨かで、その日の気分が決まることがあるよね。」である場合に、cエンジンを採用してその返答データを出力する。
【0127】
(2)雑談対話エンジンのうち、語尾に「?」がついているものを最後に持ってきて出力する。このとき「?」がついている回答が複数あればそれらを連続して出力する。
語尾に疑問符がつくと、その疑問に更に答えるような話の流れになるため、会話が続きやすくなりユーザーは対話を楽しむことができる。
例えば、上記(1)A.の選択肢では「よく間食をしますか?ご飯食べてないの?」と出力する。また、上記(1)B.の選択肢であれば「快晴っぽい?」と出力する。
(3)肯定文を組み合わせた後、疑問文を組み合わせて出力する。
このようにアレンジすることでいかにも考えて文章を練ったような応答になるため、ユーザーは真剣に自身の発話を聞いてもらっているような感覚となり、続けて会話をしたいと思うようになるため、会話が続きやすくなりユーザーは対話を楽しむことができる。ま
た、出力尺をかせぐことができるとともに人への返答を求めることができる。
例えば、上記(1)B.のような返答データが取得された場合「今すぐお空に行って確認してきます。晴れか雨かで、その日の気分が決まることがあるよね。快晴っぽい?」出力する。
【0128】
(4)他よりも話題の転換をより頻繁にしてくるエンジンからの結果を、他のエンジンの結果よりも後に持ってきて出力する。
このようにアレンジすることで話題転換したことで次の発話を誘うような対話となり、対話が続きやすくなる。
A.例えば、「どーもどーも」とユーザーが発話した場合に、a~cの3つのエンジンからの回答が「aエンジン:だょね~」「bエンジン:そうですね」「cエンジン:野球は見たりしますか?」である場合に、cエンジンのデータを最後にして「だょね~ そうですね 野球は見たりしますか?」と出力する。
B.例えば、「なかなか見つからないね」とユーザーが発話した場合に、a~cの3つのエンジンからの回答が「aエンジン:その通りですね」「bエンジン:あるあるー」「cエンジン:ご家族は何人ですか?」である場合に、cエンジンのデータを最後にして「その通りですね あるあるー ご家族は何人ですか?」と出力する。
(5)他よりもよりフレンドリーな返答をしてくるエンジンをまず真っ先に出力して、その後に他のエンジンからの返答をくっつけて出力する。
このようにアレンジすることでユーザーが対話に引き込まれやすくなり、対話が続きやすくなる。フレンドリーかどうかは言葉(単語)に相対的な序列化をすることでどの位置に配置するかを決定することができる。
A.例えば、上記(4)B.の場合ではbエンジンの結果を最初にして「あるあるー その通りですね ご家族は何人ですか?」と出力する。
B.例えば、「なるほどね」とユーザーが発話した場合に、a~bの2つのエンジンからの回答が「aエンジン:あら適当な相槌ですね」「bエンジン:うむ」である場合に、bエンジンのデータを最後にして「ほほほー あら適当な相槌ですね うむ」と出力する。
【0129】
(6)(1)~(5)の処理を任意に組み合わせる
これによって、対話のバリエーションが増えることとなるため、ユーザーが同じ発話をした場合でもまったく同じ応答が帰ってきてしまうことがなくなり、対話に飽きることがなく対話が続きやすくなる。
例えば「老後って何」とユーザーが発話した場合に、a~cの3つのエンジンからの回答が「aエンジン:ちょっと待ってくださいね」「bエンジン:サポートは嫌いじゃないよ」「cエンジン:今健康でいらっしゃいますか?」である場合に、最もフレンドリーなbエンジンを最初にし、肯定文を組み合わせた後、疑問文を組み合わせ、「サポートは嫌いじゃないよ ちょっと待ってくださいね 今健康でいらっしゃいますか?」と出力する。
【0130】
(7)テキスト出力用の場合のエンジンでは、カッコや顔文字が帰ってくることがあるため、これらが帰ってきた場合には音声出力を抑制して出力する。そして画面にはそれらは表示させる。
顔文字は音声出力できないが、表示部に敢えて顔文字を表示させることで、音声と併せて対話の一部とすることで通常にはない対話のおもしろさを創出することができる。
A.例えば、「腹減った」とユーザーが発話した場合に、a~cの3つのエンジンからの回答が「aエンジン:(わざと無視)」「bエンジン:こんにちはお元気ですね」「cエンジン:こんにちは」である場合に、aエンジンだけは音声出力させず、タッチパネル部7(表示画面)に表示させるようにする。
B.例えば、「元々入ってる」とユーザーが発話した場合に、a~cの3つのエンジ
ンからの回答が「aエンジン:あなたはよくするんですか?「bエンジン:(´・ω・`)」「cエンジン:夜型さんですか?」である場合に、bだけは音声出力させず、タッチパネル部7(表示画面)に表示させるようにする。
(8)同じ文字列が含まれる返答についてはいずれか1つを出力する。
同じ文字列が繰り返されると対話がくどくなってしまうし、聞き手に違和感を覚えさせてしまうためである。
例えば、「中華」とユーザーが発話した場合に、a~cの3つのエンジンからの回答が「aエンジン:あらっいいですねぇ」「bエンジン:うん、中華です。」「cエンジン:中華を食べに行くんでしょうか?」である場合に、bエンジンとcエンジンには「中華」の文字列があるためいずれか一方のみ出力する。例えば「あらっいいですねぇ 中華を食べに行くんでしょうか?」のように出力する。
【0131】
(9)語尾変換手段、例えば語尾変換APIを使って統一感を出すようにする。このときすべての返答について語尾変換を行ってもよいが、最後に出力する文か最初に出力する文のいずれか一方にのみ語尾変換を行うようにしてもよい。
普通の対話エンジンの文章に比べて、より親しみやすい表現となるのでよい。
例えば、あるエンジンから「ねむいな」と返答データがあった場合に語尾を語尾変換APIによって変換させて「ねむいニャ」というように出力する。
(10)認識失敗に備えて、複数のエンジンから得た返答のうち一部のみを音声出力に利用し、残りの返答は保持しておき、次の音声認識に失敗したときや対話システムからの返答がなかったときは、その保持しておいた返答を返すようにする。
音声認識が失敗した場合や、外部サーバーからのレスポンスがなかなか来ない場合に使用することで、対話が途切れずにつなげることができ、自然な対話に寄与する
【0132】
<実施の形態7>
図14に示すように、実施の形態7はロボット1の近傍にスマートスピーカ51を配置し、ロボット1とスマートスピーカ51を組み合わせた装置(システム)である。ロボット1とスマートスピーカ51の間隔は互いのマイクロフォンで音が拾える程度の距離であって例えば1~2m以内に隣接配置されることがよい。
スマートスピーカ51は無線LAN装置を内蔵し、インターネットを使用した無線通信機能、電話回線接続機能等を有しネットワークモジュールが搭載されたネットワーク端末であり、マイクロフォンとスピーカ装置を備えた一種のコンピュータでもある。スマートスピーカ51はスマートフォンのような端末装置を利用してサーバーを介して各種初期登録(例えば、使用者の名前、住所、電話番号、メールアドレス登録、複数の音声登録、ブルトゥースによるネットワーク対応のAI機器の設定等)を実行し、音声登録した使用者からの発話(命令)によってインターネットに接続してサーバーの検索エンジンを使用して所定の処理を実行し、その結果をスピーカ装置から音声情報として出力する。
【0133】
ロボット1はスマートスピーカ51と連携することで互いの機能を補うことができる。具体的にはロボット1とスマートスピーカ51とを音声をインターフェースとして次のような機能を奏する。
(1)スマートスピーカ51へのロボット1からの指示機能
イ.例えば、ユーザーがスマートスピーカのスキルを起動するフレーズを喋ったとき、ロボットはそのフレーズの音声認識結果の文字列を記憶しておき、ロボットは自らその文字列を音声合成で所定のタイミングで喋るようにする。
実施の形態7ではロボット1のコントローラMCは、ユーザーの発話を周波数成分を分析して個人の声を識別する声識別プログラム、ユーザーの発話を個人毎に区別して舞う頃フォン12によって取得し、文字列データとして記憶させ、その文字列データに基づいて音声合成してスピーカ装置13から再生させるフレーズを録音・再生プログラムを備えている。
ロボット1は、例えば発話を記憶するトリガーとなる発話、例えば「今からしゃべるから、録音して」という発話の後の言葉を記憶する機能を有している。そして、ユーザーはこの機能を利用して、スマートスピーカ51を、起動させたりなんらかの処理をさせるような言葉を記憶させるようにする。例えば「OK、×××。照明をつけて。」のような言葉がよい。このとき、ロボット1に登録されるユーザー個人の音声は、スマートスピーカ51に登録されるユーザー個人の声である。
そして、ロボット1に所定のタイミングで発話させるようにする。所定のタイミングで発話させる設定は、例えばスマートフォンのような端末を操作して設定登録できる。
ロ.ロボット1の「所定のタイミングでの発話」としては、例えばロボット1がなんらかの変化を検知すること、例えばタッチパネル部7へのタッチ動作や、ドップラーセンサ22による物体(人)の検知等である。
例えばロボット1のコントローラMCはドップラーセンサ22によって人を検知した場合に「OK、×××。照明をつけて。」というようにスピーカ装置13から音声出力をさせる。それを受けてスマートスピーカ51はネットワーク対応しているAI機器である室内の照明を点灯させるように制御する。尚、制御される照明は前もってスマートスピーカ51によって制御される対象であるように登録されている。照明以外に例えば、エアコン、テレビ、カーテンの開閉装置等をAI機器とすることがよい。
【0134】
(2)スマートスピーカ51からの発話かユーザーの発話かを区別する機能
ユーザーの個人の声を識別してロボット1に設定登録することで、ロボット1がスマートスピーカ51からの発話か、あるいはユーザーの直の発話かを区別する機能を備えることができる。これによって、ロボット1が登録されていない声であるスマートスピーカ51からの音に反応しないように制御することができ、逆に(1)のようにスマートスピーカ51とロボット1にそれぞれユーザーの個人の声を登録することで、スマートスピーカ51に対してユーザーだけでなくロボット1からも指示をすることができる。このように個人の発話を区別できることでスマートスピーカ51への音声操作を妨害しないという機能も有する。
(3)スマートスピーカ51からの発話の表示機能
スマートスピーカ51にユーザーが指示した発話内容をロボット1が取得して文字テキスト化し、タッチパネル部7に表示させるようにしてもよい。
ロボット1のコントローラMCは発話内容を取得して自身であるいはサーバーに接続して文字テキスト化するプログラムを有しているとよい。
例えば、ユーザーが「OK、×××。今日の天気を教えて。」と発話し、これに対してスマートスピーカ51が「今日の愛知県岡崎市の天気は晴れ、最高気温15度、降水確率は20%です」と回答した場合に、これらのすべての対話を、例えば、ロボット1のタッチパネル部7には例えば、次のように聞き取った両者の対話が表示される。
「ユーザー:OK、×××。今日の天気を教えて。
スマートスピーカ:今日の愛知県岡崎市の天気は晴れ、最高気温15度、降水確率は20%です」
また、加えてロボット1のコントローラMCは文字テキスト化した内容を短く翻案したり要約するプログラムを有しているとよい。ロボット1は翻案したり要約した内容を音声出力又はタッチパネル部7への表示させるようにするとよい。
(4)人がいないときにロボット1がスマートスピーカ51へ色々聞いて学習しておく機能
例えば、ロボット1がビルトインシナリオとして「明日の天気は?」とか「なにか事件はないですか」などという質問ワードを有しており、ユーザーが留守の時にロボット1のコントローラMCに所定のタイミングでスマートスピーカ51を起動するフレーズと一緒に質問ワードを音声出力させるようにする(ロボット1の声はスマートスピーカ51に登録済みとする)。このとき、コントローラMCはスマートスピーカ51からの発話内容をロボット1はマイクロフォン12によって取得して記憶しておき、所定のタイミングでそ
の内容を音声出力させる。所定のタイミングとは、例えば所定の時間、ドップラーセンサ22によって人を検知した際、ユーザーがロボット1に「何かニュースはないの?」というようなビルトインシナリオとしての発話を行った際等である。
【0135】
<実施の形態7の変形例1>
スマートスピーカ等、他の音声認識機器の音声操作を妨害しない機能を設定するようにしてもよい。例えば、他のスマートスピーカの起動フレーズ(音声認識開始ワード)を、の音声をロボット1が認識した場合、自身の音声出力を停止するようにしてもよい。
例えば、他のスマートスピーカであるA社の起動フレーズである「OK、×××」のような起動用のフレーズの音声を認識した場合に、ロボット1のコントローラMCはそれをマイクロフォン12から取得し、登録済みの起動フレーズであると判断すると、自身の音声出力を一旦停止させる。
これによって音声認識機器の音声操作を妨害せずに、機能を発揮させることができる。
【0136】
<実施の形態7の変形例2>
ロボット1にスマートスピーカ51のような他の音声認識機器の音声認識起動キーワードを認識し、その後のユーザーのスマートスピーカ51への発音を認識してクラウドサーバ-にリクエストして、検索エンジン等に検索をさせて対応する回答を得ておく。
ロボット1は、スマートスピーカ51が音声認識に失敗してしまった場合(例えば「エラーです」など)や音声認識結果に対する適切な回答を出力できない旨の音声出力(例えば「すみません」など)を認識した場合、ロボット1は自身が前もって得ておいた回答を出力する。あるいは、音声認識に失敗してしまった場合や音声認識結果に対する適切な回答を出力できない旨の音声出力を受けてから、ロボット1はクラウドサーバ-にリクエストして回答を得るようにしてもよい。
【0137】
<実施の形態8>
ロボット1は、例えばユーザーの要求によってwebサイト上のニュース記事を音声で読み上げるようにしてもよい。ロボット1のコントローラMCはサーバー上での検索エンジンを利用したニュース記事のリクエストをし、クラウドサーバーはそのリクエストに対して、例えば登録サイトのニュースデータをテキストデータとしてレスポンスする。
ロボット1はニュースデータを音声合成して読み上げる(出力する)と同時に記事の情報源の名称も音声合成して読み上げる(出力する)。また、併せて表示画面としてのタッチパネル部7には記事の情報源のURLを表示をし、タッチパネル部7上でそのURLにタッチされたら、そのURLのページの内容をタッチパネル部7上に表示するようにする。
また、記事や記事の情報源を読み上げる場合には、それらが引用であることがわかるような表現で出力することがよい。
例えば、URL「https://\\\\.jp/archives/92###」の記事内容を読み上げる場合を説明する。
『「××ニュース」のサイトの記事を読み上げるよ。「・・・・・を本年1月15日より販売する。」そうだよ。』
というように、例えば「のサイトの記事を読み上げるよ。」や「そうだよ」というような記事や記事の情報源以外を正規表現として引用であるように、聞き手にわかるように発話させ、この場合では画面表示に、例えば『https://\\\\.jp/archives/92###の情報だよ。』というようにURLを表示させる。そしてこのURL部分にタッチすることでタッチパネル部7に読み上げた記事の内容を改めて表示させる。
「聞き手にわかるように発話」とは記事部分とそうでない部分で、例えば語調や声を変えるようにすることがよい。
このようにすれば、Web記事を読まなくともロボット1の読み上げた内容を聞き取る
だけでニュース内容を理解でき、場合によっては念のため目視でニュース内容を確認することもできる。
【0138】
<実施の形態9>
実施の形態9ではコンピュータの見えない動きをロボットのアクチュエータの動作で見せる場合について説明する。
(1)ロボティクスプロセスオートメーションについて
ロボティクスプロセスオートメーション(以下、RPAとする)は、単純なパソコン作業を自動化するソフトウェアである。ソフトウェアはサーバーに設定することもでき、ユーザーのコンピュータに設定することもできる。図15に基づいてソフトウェアをサーバーに設定した場合であって、上記各実施の形態のロボット1をRPAのネットワークに組み込んだ場合の一例について説明する。
図15に示すように、クラウドサーバー55とユーザー側コンピュータ56、57とがインターネットを使用したネットワークで接続されている。また、クラウドサーバー55とロボット1もネットワークで接続されている。ユーザー側コンピュータ56はRPAプログラムによってクラウドサーバー55によって制御されている。また、ロボット1にはクラウドサーバー55によって実行されるRPAのためのプログラムにおける所定の処理においてその処理がまもなく実行される、実行されている、あるいは実行された等の処理情報が報知されるようになっている。
クラウドサーバー55はユーザー側コンピュータ56に処理1~処理4を順に処理させる。本実施の形態では処理1と処理2はコンピュータ56、処理3と処理4はコンピュータ57が実行する。もっと多くの処理を設定してもよく、処理に関わるユーザー側コンピュータ56も1以上いくつでもよい。
処理1としては、例えばコンピュータ56へのユーザーのアクセス・ログイン等、処理2としては、例えばコンピュータ56内のデータに基づくリストの作成・仕分け等、処理3は、例えば処理2に続いて実行する顧客毎の請求内容の修正、処理4は、例えば処理3に続いて実行する請求書の発行である。本実施の形態9では例えば処理3ではユーザに修正のための入力を促し、その入力があって後に、次の処理4に移行するものとする。つまり、処理2の後は処理3での力が完了するまで一旦待ち受けードとなる。
クラウドサーバー55はこれらの処理を実行する直前、処理中、処理後にそれぞれロボット1に異なる報知情報を出力し、ロボット1はその報知情報に基づいてロボット1の周囲に処理状況を報知するようにするとよい。あるいは各処理毎に一回の報知でもよい。
【0139】
例えば、
a.ロボット1がどの処理がどのような状態かを音声や音の違い、あるいは音楽等で報知する。
b.表示画面上で報知する。a.と同時に行ってもよい。
c.処理3ではユーザーの入力が必要であるため、処理3だけを報知するようにしてもよく、処理3だけを他の報知とは異なる(識別できる)報知としてもよい。
d.ロボット1から他の端末装置に処理の状態を転送して報知する。
e.ロボット1が処理状況がわかるような動作をする。例えば、コンピュータ56の処理が行われていればその方向を向くように制御する。そのため、前もってロボット1に対する各コンピュータ56、57の方向は何らかの方向特定手段、例えば上記の形状認識プログラムを使用して認識しておくことがよい。ロボット1に例えば矢印や腕部材のような方向指示部材を設け、その指し示す方向に報知対象としてのコンピュータ56、57があるように動作してもよい。
【0140】
(2)ブロックチェーンについて
ブロックチェーンは多数のコンピュータが分散して記録する仕組みである。特にパブリック型のブロックチェーンでは記録対象のデータや記録されたデータが公開される。
そこでブロックチェーンのネットワーク中にロボット1を配置し、ブロックデータが送信される前にユーザーにロボット1がお知らせするようにする。ロボット1に「待て」という命令を出力させることで(つまりデータ送信させずに待機するリクエストをする)送信を停止させるようにするとよい。
【0141】
<実施の形態10>
各実施の形態では自然対話モードについて説明したが、自然対話モードに代えて、または、自然対話モードとともに、外国語学習モードを設けるとよい。自然対話モードに加えて外国語学習モードを設けるときは、例えば自然対話モードで「外国語学習モードへ切り替え」という音声を認識したときに自然対話モードから外国語学習モードへ切替えるとよい。また「外国語学習モード」で「自然対話モードへ切り替え」という音声を認識したときに外国語学習モードから自然対話モードへ切替えるとよい。
よく外国語を習得するには外国人の友人を作るとよいなどと言われるが、そのような機会に恵まれる人は多くない。そこで外国語学習のパートナーになり得る対話システムである外国語学習機能を備えるとよい。
任意の第一言語と第二言語との連携とすることができる。以下、日本語の対話システムと英語の対話システムを連携させる構成で説明する。
基本的には英語で会話するシステムとし、会話中に日本語で「もう一回言って」などの要求を出力するとよい。さらに、英文解析Webサービスなどと連携して、「説明して」などの要求にたいして会話中の英文を日本語で解説する機能を備える。会話中に言いたいことが英語でどう言えばいいかわからないときには、「翻訳して」と要求をすると英語でどういうのかを出力する。出力された英文を読めばそのまま会話を続けることができる。自分で調べたりする必要がないので、会話が途切れることもなく、円滑な英会話学習が期待できる。
外国語学習モードでの母国語(例えば、日本人なら日本語)の音声認識エンジンと外国語(例えば英語)の音声認識エンジンはどちらもクラウド上で動作している音声認識エンジンを利用するようにしてもよいが、母国語(例えば日本語)については要求内容が定型文であること、要求に対する回答のフォーマットが決まっていることから、ローカル(例えばロボット1内)に音声認識エンジンを設けこれを利用するとよい。対話エンジンも同様である。音声合成エンジンもいずれの場所に設けてもよいが、特にローカルに設けるとよい。
マイクロフォン12からの信号に基づく音声データを両言語の音声認識エンジンに投げると、どちらの音声認識エンジンからもなんらかの結果が返ってくる。例えば、「もう一回言って」という日本語を両方のエンジンに投げると、日本語のエンジンは「もう一回言って」というテキストデータを返し、英語のエンジンは「もう一回言って」を英語として解釈したデタラメなテキスト データを返してくる。このような場合、日本語の要求は定型文であるため、日本語のエンジンが返してきたテキストデータと要求の定型文を比較して、一致すれば日本語の要求がされたと判断し、一致しなければ英語が話されたと判断することで、英語と日本語を切り分ける処理を行なうと良い。
要求は英語で受け付けるようにしてもよいが、特に、要求をしようにも英語がわからないというケースを想定して、日本語でも要求できるようにすることが望ましいことを発明者は見出した。
「説明して」などの要求に対して会話中の英文を日本語で解説する機能は、単に英文の訳を日本語にして出力するだけでもよいが、特に英文で用いられている語句や文法の解説を出力するとよい。特にその英文で用いられている構文についての解説を出力するとよい。構文についての解説は例えば各句を頂点(ノード)して例えば各句を囲む描画をし、関連する各句の関係を示す線分等の枝(エッジ)を描画するとよい。例えばグラフ構造(特にツリー構造とするとよい)の図でタッチパネル部7に表示するとよい。
また、表示した内容を音声でスピーカ装置13から出力するとよい。例えば、https://gigazine.net/news/20160602-foxtype-review/で解説されるような構文解析サービスのAP
Iをコールし、その結果を受け取って、解析結果を日本語で出力する構成とするとよい。
例えば以下のような処理と出力を行なう。
『 処理 英語の対話エンジンからフレーズを取得
ロボット I'm a fantastic robot.
人 「もう一回言って」
ロボット I'm a fantastic robot.
人 「説明して」
処理 (「説明して」を認識)→構文解析APIコール→構文解析結果から日本語解説を生成
ロボット Iが主語で、amが動詞、robotが目的語になるよ。
fantasticは素晴らしいという意味の形容詞でrobotを修飾しているよ。
英文は「私は素晴らしいロボットです」という意味になるよ。
人 「I don't think so.」
ロボット Don't say it! 』
話したいことが英語でわからなければ、日本語で英語での言い方を教えてくれるように要求できるので会話が途切れないという優れた効果を発揮する。日本語での要求ができない場合は、英語での言い方がわからないとき、辞書で調べたりネットで翻訳したりする必要があり、勉強しているという感じになってしまいストレスを感じる。日本語で要求できれば、ただバイリンガルと会話しているという感覚でストレスなく学習できる。語学学習は継続することがとても大事であるから、なるべく学習の際にストレスが少ないということは継続する上で極めて重要なことである。本構成によれば、継続して語学学習を行なえるロボット1を実現できる。
【0142】
<実施の形態11>
各実施の形態で説明した機能に加え、ロボット1の設置された室内へ人が入ってきたことを検知したとき発話する機能を設けるとよい。またロボット1の設置された室内から人が出ていくことを検知したとき発話する機能を設けるとよい。
例えば、その室内とその室内以外の場所の通路にセンサを設けて、ロボット1の設置された室内へ人が入ってきたこと、ロボット1の設置された室内から人が出ていくことを検知するとよい。特にロボット1が設置された室内に出入りするための自動ドアがある場合、センサは特に自動ドアの開閉のために人がその自動ドアに接近していることを検知するセンサを用いると良い。特に自動ドアをはさんで室外にある第一の人検知センサと、自動ドアをはさんで室内にある第二の人検知センサと、自動ドアが開いているときに自動ドアの場所にいる人を検知する第三の人検知センサセンサ(人のドアへの挟み込みを防止するためのセンサ)の少なくともいずれか2つにロボット1のコントローラMCを接続して、室内への出入りを検知するとよい。このようにすれば、ロボット1が設置された室内への出入り等を新たなセンサを設置することなく検出できる。例えば各センサの人を検知した際に立ち上がる信号のエッジを捉えて検出するとよい。
例えば、第一の人検知センサで人が検知された後、第三の人検知センサで人が検知された場合、「いらっしゃいませ」などと入ってきた人を歓迎するフレーズの音声をスピーカ装置13から出力するとよい。例えば、第二の人検知センサで人が検知された後、第三の人検知センサで人が検知された場合、「ありがとうございました」と出ていく人に感謝するフレーズの音声をスピーカ装置13から出力するとよい。
これらのときに第1~第3のモータ23~25を動かし、ロボット1の設置位置から予め設定した自動ドアの方を向く動作を行なうようにするとよい。なお、第一の人検知センサと第二の人検知センサとが同じ時に人を検知した場合には、第一の人検知センサを優先するとよい。このようにすれば、入ってくる人によりロボット1の存在を気づいてもらいやすくなるとともに、入ってくる人が「ありがとうございます」とロボット1にいきなり言われる違和感を軽減できる。
【0143】
<その他の実施の形態>
(1)各実施形態等においては、無線LAN装置21を備えることとしたが、これに代えてまたはこれとともに有線LAN装置を備え、有線LANネットワークに接続するようにしてもよい。有線LAN装置はロボット1に内蔵しても、外付けとしてもよい。USBのOTG(On-The-Go)用の端子18に有線LAN装置を接続する構成としてもよい。有線LANネットワークはルーター等を介してインターネットに接続される構成とするとよい。無線LANは環境によっては通信が安定しないまたは接続できないケースも想定されうる。例えばスマホ等、多数の無線LAN装置が存在する場所にロボット1を設置する場合には有線LAN装置を介してインターネットにアクセスする構成とすると望ましい。
(2)各実施形態等においては、半二重方式での人とロボット1との対話の例を示しているが、全二重方式で人とロボット1との対話を行なうようにしてもよい。例えば表1の対話の中で「・・・を開いて」と人が行った後、「本当にいいですか」の発話を行っている間も人の音声の認識を続け「取消」という音声が「本当にいいですか」の発話中に認識された場合には、発話中であれば発話を中断し、すぐに「中止しました」とロボットから発話するように構成してもよい。
(3)半二重方式での対話を行なう構成は、構成や処理を簡素化でき、コストを低減できるので特によい。しかし、ロボット1がマイクロフォン12をオンにしたタイミングが分かりづらく、ユーザーが喋っても、ロボットが認識対象とするユーザーの音声の先頭部分、すなわち言葉の先頭部分が欠けてしまうことが多いという課題を発明者らは見出した。この課題を解決するため、コントローラMCがマイクをオンしたタイミングで特徴的な画面表示をおこなうとよい。これによりスムーズな会話をサポートする。コントローラMCがマイクをオンしたタイミングで特徴的な画面表示をおこなう態様としては、1)画面の四隅を光らせる、2)マイクのアイコンを表示させる、の少なくともいずれか一方を行なうとよく、特に1)、2)の両方とも行うと優れた効果を発揮する。
(4)第1~第3のモータ23~25を構成するモータとしては、DCモータなど各種のモータとすることができるが、特にステッピングモータとするとよく、ロボット1はステッピングモータにより姿勢を制御する構成とするとよい。ステッピングモータはモータに流す電流に比例してトルクの大きさが変わる。電流をたくさん流せば大きなトルクを得られるが、発熱や電池寿命などが問題になる。そこでロボット1の静止時はその姿勢を維持するために必要な最小限の電流を流し、ロボット1が姿勢を変えるときのみ大きな電流を流すようにすると特によい。なお、サーボモータ23~25のすべてについてその静止時に姿勢を維持するために必要な最小限の電流を通電するようにしてもよいが、ディテントトルク(通電しない状態でのトルク)で支持できる胴体部の第1のモータ23は通電しないようにする一方、頭部分はディテントトルクでは負けてしまうため第2のモータ24,第3のモータ25については静止時もこの通電をするようするとよい。
また、静止時のトルクのまま回転させるとトルク不足で脱調が起こり上手く回転しないため、回転させる時は静止時に比べ、電流をたくさん流すようにしてトルクを上げるとよい。一方、静止時は回転時のような大きなトルクは必要ないので回転時に比べ、電流を下げるとよい。
また、ある方向に向きを変える場合、加速しながら一定速度まで上げて目的の角度が近づいたら減速して止めるという制御を行なうとよい。
また、ロボットをモータによって駆動させると機械的、電気的なノイズを発生する。このノイズが音声認識の認識率を低下させるので音声認識中はモータを停止するように制御するとよい。
本発明の範囲は,明細書に明示的に説明された構成や限定されるものではなく,本明細書に開示される本発明の様々な側面の組み合わせをも,その範囲に含むものである。本発明のうち,特許を受けようとする構成を,添付の特許請求の範囲に特定したが,現在の処は特許請求の範囲に特定されていない構成であっても,本明細書に開示される構成を,将来的に特許請求の範囲とする意思を有する。
本願発明は上述した実施の形態に記載の構成に限定されない。上述した各実施の形態や
変形例の構成要素は任意に選択して組み合わせて構成するとよい。また各実施の形態や変形例の任意の構成要素と,発明を解決するための手段に記載の任意の構成要素または発明を解決するための手段に記載の任意の構成要素を具体化した構成要素とは任意に組み合わせて構成するとよい。これらについても本願の補正または分割出願等において権利取得する意思を有する。また「~の場合」「~のとき」という記載があったとしてもその場合やそのときに限られる構成として記載はしているものではない。これらの場合やときでない構成についても開示しているものであり、権利取得する意思を有する。また順番を伴った記載になっている箇所もこの順番に限らない。一部の箇所を削除したり、順番を入れ替えた構成についても開示しているものであり、権利取得する意思を有する。
また,意匠出願への変更出願により,全体意匠または部分意匠について権利取得する意思を有する。図面は本装置の全体を実線で描画しているが,全体意匠のみならず当該装置の一部の部分に対して請求する部分意匠も包含した図面である。例えば当該装置の一部の部材を部分意匠とすることはもちろんのこと,部材と関係なく当該装置の一部の部分を部分意匠として包含した図面である。当該装置の一部の部分としては,装置の一部の部材としても良いし,その部材の部分としても良い。全体意匠はもちろんのこと,図面の実線部分のうち任意の部分を破線部分とした部分意匠を,権利化する意思を有する。
【符号の説明】
【0144】
1…装置としてのロボット、41…他の機器としてのスマートフォン、51…他の機器としてのスマートスピーカ。

図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15