(57)【要約】処理ノード（１０）によって実行される方法であって、少なくとも１つの通信デバイス（１００）から、音声に関連する音声データ（１２）を取得（１１）し、処理ノード（１０）に音声データ（１２）を保存するステップ１と、音声に関連したイベント指定（１６）を取得（１５）し、処理ノード（１０）にイベント指定（１６）を保存（１７）するステップ２と、音声データ（１２）をイベント指定（１６）に関連付けるモデル（２０）を決定し、モデル（２１）を保存するステップ３と、モデル（２０）を通信デバイス（１００）に提供（２３）するステップ４を含む方法。処理ノード（１０）によって実行される方法と同様に、通信デバイス（１００）によって実行される方法、および通信デバイス（１００）、システム（１０００）、および方法を実行するためのコンピュータプログラムも記載されている。
2020524300.tif 000002
【特許請求の範囲】
【請求項１】
処理ノード（１０）によって実行される方法であって、
少なくとも１つの通信デバイス（１００）から、音声に関連する音声データ（１２）を取得（１１）し、前記処理ノード（１０）に前記音声データを保存（１３）する、ステップ（ｉ）と、
前記音声データ（１２）に関連したイベント指定（１６）を取得（１５）し、前記イベント指定を前記処理ノード（１０）に保存（１７）する、ステップ（ｉｉ）と、
前記音声データ（１２）を前記イベント指定（１６）に関連付けるモデル（２０）を決定（１９）し、前記モデル（２０）を保存（２１）する、ステップ（ｉｉｉ）と、
前記モデル（２０）を前記通信デバイス（１００）に提供（２３）する、ステップ（ｉｖ）と、を含む、方法。
【請求項２】
前記ステップ（ｉ）は、第１の複数の通信デバイス（１００）から、第２の複数の音声に関連する第２の複数の音声データ（１２）を取得（１１）し、第２の複数の音声データ（１２）を処理ノード（１０）に保存（１３）することを含み、
前記ステップ（ｉｉ）は、前記第２の複数の音声データ（１２）に関連した第２の複数のイベント指定（１６）を取得（１５）し、前記処理ノード（１０）に前記第２の複数のイベント指定（１６）を保存（１７）することを含み、
前記ステップ（ｉｉｉ）は、各モデルが前記第２の複数の音声データ（１２）の１つを前記第２の複数のイベント指定（１６）の１つに関連付け、第２の複数のモデル（２０）を決定（１９）し、前記第２の複数のモデル（２０）を保存することを含み、
前記ステップ（ｉｖ）は、前記第２の複数のモデル（２０）を前記第１の複数の通信デバイス（１００）に提供すること（２３）を含む、
請求項１に記載の方法。
【請求項３】
各通信デバイス（１００）は、固有の通信デバイスＩＤ（２４）に関連付けられており、さらに、
各通信デバイス（１００）から前記通信デバイスＩＤ（２６）を取得（２５）する、ステップ（ｖ）と、
各通信デバイス（１００）からの前記通信デバイスＩＤ（２６）を、その通信デバイス（１００）から取得した前記音声データ（１２）と関連付けるステップ（ｖｉ）と、を含み、
前記ステップ（ｉｉｉ）は、各モデル（２０）を、前記モデル（２０）を決定するために使用される前記音声データ（１２）が取得された前記通信デバイスの前記通信デバイスＩＤ（２６）に関連付けることを含み、
前記ステップ（ｉｖ）は、各通信デバイスが少なくともその通信デバイス（１００）に関連した前記通信デバイスＩＤ（２６）に関連する前記モデル（２０）を取得するように、前記第２の複数のモデル（２０）を前記第１の複数の通信デバイス（１００）に提供（２３）することを含む、
請求項２に記載の方法。
【請求項４】
前記第１の複数の通信デバイス（１００）のうちの第１のものから、その通信デバイスに提供されるどのモデル（２０）にも関連しない第１の音声データ（１２）を取得（１１）する、ステップ（ｖｉｉ）と、
前記ステップ（ｉ）において、前記第１の複数の通信デバイス（１００）から取得した前記音声データ（１２）の中から、第１の複数の通信デバイス（１００）のうちの第２のものによって取得された、第１の音声データ（１２）に類似する第２の音声データ（１２）を検索（２９）する、ステップ（ｖｉｉｉ）と、
第２の音声データが見つかった場合、
前記第１の複数の通信デバイス（１００）のうちの前記第１のものに、第２の音声データに関連したモデル（２０）を提供する（２３’）、ステップ（ｉｘ）と、
または、第２の音声データが見つからない場合、
前記第１の複数の通信デバイス（１００）のうちの前記第１のものに、前記第１の音声データ（１２）に関連した第１のイベント指定（１５）を処理ノード（１０）に提供するようプロンプトを出す（３１）、ステップ（ｘ）と、
前記第１の音声データ（１２）を前記第１のイベント指定（１６）に関連付ける第１のモデル（２０）を決定（１９）し、前記第１のモデル（２０）を保存（２１）する、ステップ（ｘｉ）と、
前記第１のモデル（２０）を前記複数の通信デバイス（１００）のうちの第１のものに提供（２３）する、ステップ（ｘｉｉ）と、
を含む、請求項３に記載の方法。
【請求項５】
各通信デバイスから、前記音声データ（１２）に関連した非音声データ（３４）を取得（３３）し、前記非音声データ（３４）を処理ノードに保存（１３）する、ステップ（ｘｉｉｉ）を含み、
前記ステップ（ｉｉｉ）は、前記音声データ（１２）および前記非音声データ（３４）を前記イベント指定（２６）に関連付けるモデル（２０）を決定（１９）することを含む、
請求項１から４のいずれか一項に記載の方法。
【請求項６】
前記ステップ（ｉｉｉ）で決定された各モデル（２０）は、第３の複数のサブモデル（４０）を含み、各サブモデル（４０）は音声データおよび必要に応じて非音声データをイベント指定に関連付ける、様々な処理またはアルゴリズムを使用して決定される、
請求項１から５のいずれか一項に記載の方法。
【請求項７】
各モデル（２０）および／またはサブモデル（４０）は、周波数領域変換された音声データ（１２）および必要に応じて非音声データ（３４）の特徴の主成分分析に、少なくとも部分的に基づき、および／または、周波数領域変換された音声データ（１２）および必要に応じて非音声データ（４０）のヒストグラムデータに、少なくとも部分的に基づく、請求項１から６のいずれか一項に記載の方法。
【請求項８】
少なくとも１つの通信デバイスから、音声に関連する第３の音声データ（１２）および／または非音声データ（３４）を取得し、前記第３の音声データ（１２）および／または非音声データ（３４）を処理ノード（１０）に保存（１３）する、ステップ（ｘｉｖ）と、
前記処理ノード（１０）に保存されている音声（１２）および／または非音声データ（３４）から、前記第３の音声データ（１２）および／または非音声データ（３４）に類似する、第４の音声データ（１２）および／または非音声データ（３４）を検索（２９）する、ステップ（ｘｖ）と、
前記第４の音声データおよび／または非音声データが見つかった場合、
前記第４の音声データ（１２）および／または非音声データ（３４）に関連したイベント指定（２６）を、前記第３の音声データ（１２）および／または非音声データ（３４）ならびに前記第４の音声データ（１２）および／または非音声データ（３４）の両方と関連付けることにより、前記第４の音声データ（１２）および／または非音声データ（３４）に関連したモデル（２０）を再決定する（３５）、ステップ（ｘｖｉ）と、
を含む、請求項１から７に記載の方法。
【請求項９】
第１の音声データ（１２）を第１のイベント指定（１６）に関連付ける第１のモデル（２０）が保存される通信デバイス（１００）によって実行される方法であって、
音声の音声信号（１０２）を記録（１０１）し、音声信号（１０２）に基づいて音声に関連する音声データ（１２）を生成（１０３）し、音声データを保存（１０５）する、ステップ（ｘｖｉｉ）と、
前記第１の音声データに関連した前記第１のイベント指定（１６）を取得するために、前記通信デバイス（１００）に保存された前記第１のモデル（２０）に前記音声データ（１２）を適用する（１０７）、ステップ（ｘｖｉｉｉ）と、
ステップ（ｘｖｉｉｉ）で前記第１のイベント指定が取得されない場合、
前記音声データ（１２）を前記処理ノード（１０）に提供（１１１）するステップ（ａ）と、
前記処理ノード（１００）から、前記音声データを第２の音声データに関連した第２のイベント指定に関連付ける第２のモデル（２０）を取得（１１３）および保存（１１５）するステップ（ｂ）と、
前記第２の音声データ（１２）に関連した前記第２のイベント指定（１６）を取得するために、前記音声データ（１２）を前記通信デバイス（１００）に保存された前記第２のモデル（２０）に適用する（１０７）するステップ（ｃ）と、
前記第２のイベント指定（１６）を前記通信デバイス（１００）のユーザー（２）に提供（１０９）するステップ（ｄ）と、を実行する、
ステップ（ｘｉｘ）と、を含む、方法。
【請求項１０】
前記第１および前記第２のモデルはさらに、第１および第２の非音声データ（３４）をそれぞれ前記第１および前記第２のイベント指定（１６）に関連付け、
前記ステップ（ｘｖｉｉ）はさらに、前記音声データ（１２）に関連した非音声データ（３４）を取得し（１１７）、前記非音声データを保存（１１７）することを含み、
前記ステップ（ｘｖｉｉｉ）は、前記非音声データ（３４）を前記音声データ（１２）とともに前記第１モデル（２０）に適用することをさらに含み、
前記ステップ（ｘｉｘ）（ｂ）は、前記非音声データ（３４）を前記処理ノード（１００）に提供することをさらに含み、
前記ステップ（ｄ）は、前記非音声データ（３４）を前記第２のモデル（２０）に適用することをさらに含む、
請求項９に記載の方法。
【請求項１１】
前記ステップ（ｘｖｉｉ）は、
前記音声信号（１０２）のエネルギーを継続的に測定（１１９）するステップ（ｅ）と、
前記音声信号（１０２）の前記エネルギーが閾値を超えると、前記音声データ（１２）を記録および生成（１０３）するステップ（ｆ）と、
こうして生成された前記音声データ（１２）を前記処理ノード（１０）に提供（１２１）するステップ（ｇ）と、を含み、
前記処理ノード（１０）から、前記処理ノード（１００）に提供された前記音声データ（１２）に関連したイベント指定（１６’）のプロンプト（１２４）を受信（１２３）する、ステップ（ｘｘ）と、
前記通信デバイス（１００）の前記ユーザー（２）から前記イベント指定（１６’）を取得（１２５）する、ステップ（ｘｘｉ）と、
前記イベント指定（１６）を前記処理ノード（１０）に提供（１２７）する、ステップ（ｘｘｉｉ）と、
前記処理ノード（１０）から、前記音声データ（１２）を前記ユーザ（２）から取得した前記イベント指定（１６’）に関連付ける前記モデル（２０）を取得（１１３）する、ステップ（ｘｘｉｉｉ）と、
を含む、請求項９または１０に記載の方法。
【請求項１２】
前記通信デバイス（１００）によって取得および／または保存された各モデル（２０）は、複数のサブモデル（４０）を備え、各サブモデル（４０）は、音声データ（１２）および必要に応じて非音声データ（３４）をイベント指定（１６）に関連付ける様々な処理またはアルゴリズムを使用して決定され、
前記ステップ（ｘｖｉｉｉ）は、
前記複数のサブモデル（４０）から複数のイベント指定（１６）を取得するステップ（ｈ）と、
複数のイベント指定（１６）のそれぞれが音声データ（１２）に関連したイベント（１）に対応する確率を決定するステップ（ｉ）と、
前記複数のイベント指定（１６）の中から、ステップ（ｊ）で決定された最も高い前記確率を有する前記イベント指定（１６）を選択し、そのイベント指定（１６）を前記通信デバイスの前記ユーザ（２）に提供するステップ（ｊ）と、を含む、
請求項９から１１のいずれか一項に記載の方法。
【請求項１３】
請求項１から８のいずれか一項に記載の方法を実行するように構成された回路を備える、処理ノード（１０）。
【請求項１４】
請求項９から１２のいずれか一項に記載の方法を実行するように構成された回路を備える、通信デバイス（１００）。
【請求項１５】
請求項１３に記載の少なくとも１つの処理ノード（１０）と、請求項１４に記載の少なくとも１つの通信デバイス（１００）と、を備えるシステム（１０００）。
【請求項１６】
処理ノード（１０）で実行されるとき、請求項１から８のいずれか一項に記載の方法を、処理ノード（１０）に実行させる命令を備える、コンピュータプログラム。
【請求項１７】
通信デバイス（１００）で実行されるとき、請求項９から１２のいずれか一項に記載の方法を、通信デバイス（１００）に実行させる命令を備える、コンピュータプログラム。
【請求項１８】
請求項１６または１７に記載のコンピュータプログラムをそなえるキャリアであって、電子信号、光信号、無線信号、およびコンピュータ可読記憶媒体のうちの１つである、キャリア。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、イベントに関連する音声に基づいてイベントが発生したことの兆候を取得するなど、音声データに基づいてイベント指定を取得する方法およびデバイスの分野に関する。そのような技術は、例えば、いわゆるスマートホームデバイスで使用されてもよい。方法およびデバイスは、イベントが発生する際に通信デバイスが記録する音声に関連した音声データに基づいて、イベント指定、すなわち、通信を識別する情報を取得するために、通信デバイスの近傍で発生するイベントに関連する音声データを取得する処理ノードに接続される、家庭または他の環境に配置される１つ以上の通信デバイスを備えてもよい。
【背景技術】
【０００２】
今日では、さまざまな種類のスマートホームデバイスが知られている。これらのデバイスには、家庭内などの１つの場所からネットワークサービス（インターネット）を介して、携帯電話などのハンドヘルドデバイスを視聴するユーザーへ、映像や音声を記録および／またはストリーミングできるネットワーク対応ビデオカメラが含まれる。
【０００３】
映像に関しては、画像分析を使用してイベント指定を提供し得、イベントが発生しているまたは発生したという事実にユーザーの注意を向け得る。イベント指定を提供する目的で、磁気接点や振動センサーなどの他のセンサーも使用される。
【０００４】
音声は一般的に、映像を使用してイベントを検出するよりも必要な帯域幅が少ないとみなされるため、イベントの魅力的な表示方法である。したがって、音声を記録および保存することによって音声データを取得し、特定のイベントに関連するものとして音声データを認識または分類しようとする所定のアルゴリズムを使用し、そこからイベントを指定する情報を取得および出力するデバイスが知られている。
【０００５】
これらのデバイスには、乳幼児の近くに置かれた第１の「ベビー」ユニットデバイスと、乳幼児の活動を監視し、乳幼児の状態、睡眠／覚醒状態をリモートで判断できるように乳幼児の親が携帯する第２の「ペアレント」ユニットデバイスとの間の通信を提供する、いわゆるベビーモニターが含まれる。
【０００６】
このタイプのデバイスは、通常、イベント指定を提供する機能、つまり特定のイベントが発生しているまたは発生したときにユーザーに通知する機能という利点があり、これにより、常時の監視が不要になる。ベビーモニターの場合、これには、乳幼児の泣き声と一致する音声データが第１デバイスによって記録されるときに、「乳幼児が泣いている」などの特定のイベント指定を提供する、第１デバイスの構成が含まれる。このイベント指定を使用して、第１ユニットと第２ユニットの一方または両方を作動させ、第２ユニットが泣いている乳幼児の声を受信して出力するようにするが、それ以外では無音とする。
【０００７】
したがって、第１ユニットは、音声データを連続的に記録し、それを乳幼児が泣いているなどの特定のイベントを表す音声データと比較してもよく、記録された音声データが代表的な音声データと一致する場合、ユーザーに警告してもよい。同様にイベントや音声データに関連付けられる可能性のあるイベント指定は、銃の発砲、ガラスが割れた音、アラーム音、犬の鳴き声、ドアベルの音、叫び声、咳を含んでもよい。
【０００８】
認識できれば便利で有用となる多数のイベントがあり、人またはシステムによるさらなるアクションのためにイベント指定が取得されるため、音声データが同時に発生する複数のイベントの音声に関連付けられるより多様な背景と環境において、音声イベントに関連するイベント指定をさらなるイベントに、より高い精度で、提供できる方法およびシステムが強く求められている。
【０００９】
特に、この種の技術からさらなる利便を得るためには、音声認識を使用して、さらなるイベントのさらなるイベント指定を取得できることが重要である。これらのさらなるイベントと音声には、たとえば、ドアの開閉、建物または環境内の人間または動物の存在を示す音、交通、特定の犬、猫、および他のペットの音などが含まれる。しかしながら、これらのタイプのイベントは、銃声、悲鳴、ガラスの割れた音などの特有の音声とは関連付けられておらず、これらのイベントに関連する音声はこの技術の各ユーザーに非常に特有である可能性があるため、これらのイベントの代表的な音声データを取得することは困難であり、よってこれらのイベントのイベント指定を取得することは困難である。
【００１０】
したがって、本発明の目的は、さらなるイベントのさらなる音声に対するイベント指定を提供することができる方法およびデバイスの提供を含む。
【００１１】
本発明のさらなる目的は、イベントが発生したことをより正確に判別するイベント指定を提供できる方法およびデバイスの提供を含む。
【００１２】
本発明のさらなる別の目的は、様々な背景および／または環境で同時に発生する複数のイベントにイベント指定を提供できる方法およびデバイスの提供を含む。
【発明の概要】
【００１３】
上述の目的の少なくとも１つは、本発明の第１の態様によれば、処理ノードによって実行される方法によって達成され、方法は、以下のステップ、すなわち、
少なくとも１つの通信デバイスから、音声に関連した音声データを取得し、処理ノードに音声データを保存する、ステップ（ｉ）と、
音声データに関連したイベント指定を取得し、イベント指定を処理ノードに保存する、ステップ（ｉｉ）と、
音声データをイベント指定に関連付けるモデルを決定し、モデルを保存する、ステップ（ｉｉｉ）と、
モデルを通信デバイスに提供する、ステップ（ｉｖ）と、を含む。
【００１４】
通信デバイスが記録できる音声に関連した音声データを提供して得る通信デバイスについて、処理ノードのモデルを決定することにより、通信デバイスでは、潜在的なすべてのイベントモデルおよび通信デバイスのユーザーにとって興味があるかもしれない関連音声に基づいて、イベント指定を取得してもよい。したがって、通信デバイスのユーザーは、例えば、正面玄関が閉じるイベントのイベント指定を取得したい場合がある。今日ではユーザーは銃声、サイレン、ガラスの割れる音などの一般的な音声に限定されず、代わりにドアが閉まる音を記録でき、その後、この音と関連する音声データとイベント指定「ドアが閉まる」とが、通信デバイスに提供されるモデルを決定するために処理ノードに提供される。
【００１５】
さらに、モデルは処理ノードで決定されるため、通信デバイスで集中的な演算を行う必要がなくなる。処理ノードは、クラウドネットワークなどのネットワーク上の、少なくとも１つの物理プロセッサまたは仮想プロセッサを含む、１つ以上の物理サーバーまたは仮想サーバー上で実現できる。処理ノードは、バックエンドサービスとも呼ばれ得る。
【００１６】
通信デバイスは、火災探知機、ネットワークカメラ、ネットワークセンサー、携帯電話などのスマートホームデバイスであり得る。通信デバイスは、好ましくは、バッテリー式であり、プロセッサ、メモリ、ならびに例えばインターネットなどのネットワークを介して、処理ノードと無線通信するための回路およびアンテナを含む。音声データは、音声のアナログ音声信号のデジタル表現であり得る。音声データはさらに、周波数領域音声データに変換されてもよい。音声データは、音声信号の時間領域表現と音声信号の周波数領域変換の両方を含んでもよい。
【００１７】
さらに、音声データは、音声信号、またはＭＦＣＣ（メル周波数ケプストラム係数）、それらの１次導関数および２次導関数、スペクトル重心、スペクトル帯域幅、実効エネルギー、時間領域ゼロ交差率などの更なる特徴を備えてもよい。
【００１８】
したがって、音声データは、音声信号の完全なデジタル表現から、音声信号より抽出または計算された１つ以上の特徴に至るまで、音声および音声のアナログ音声信号に関連する広範囲のデータを包含するものと理解される。
【００１９】
音声データは、ローカルエリアネットワーク、ワイドエリアネットワーク、モバイルネットワーク、インターネットなどのネットワークを介して通信デバイスから取得されてよい。
【００２０】
音声は、通信デバイスに備えられたマイクによって録音されてもよい。音声は、発生したイベントの結果である任意の音声であり得る。音声は、例えば、ドアが閉まる音、車が始動する音などであり得る。
【００２１】
さらに、音声は、「ｐｉｎｇ」または短い音声パルスとして機能する音声を発する通信デバイスによって引き起こされる、エコーであってよく、そのエコーのために、音声データが取得される。したがって、イベントは、処理ノードおよび／または通信デバイスの制御外で発生するイベントである必要はなく、むしろ、人がいない部屋などのイベントおよびイベントの指定は、処理ノードおよび／または通信デバイスの動作によって作動される。
【００２２】
音声、すなわち音声データは、低周波音、つまり２０Ｈｚ未満の周波数と、同様に超音波、つまり２０ｋＨｚを超える周波数を含む、広範囲の周波数の音声を指す。
【００２３】
したがって、音声データは、２０Ｈｚ未満から２０ｋＨｚを超える広いスペクトルの音声に関連付けられ得る。
【００２４】
本発明の文脈において、「イベント指定」という用語は、イベントを描写または分類する情報として理解されるべきである。イベント指定は、プレーンテキストのテキスト文字列、数値またはアルファベットのコード、一次元または多次元の分類構造の座標セットなどである。
【００２５】
さらに、イベント指定は、対応するイベントが実際に発生したことを保証しないことを理解されたい。しかしながら、イベント指定は、イベント指定を取得するためのモデルが構築され、音声データを生成する音声に関連するイベントが発生した特定の可能性を提供する。
【００２６】
イベント指定は、処理ノードへの別個のインターフェースなどを介して、通信デバイスから、また通信デバイスのユーザーから、取得されてもよい。
【００２７】
このモデルは、音声データ形式での入力に基づいて、イベント指定を提供する１つ以上のアルゴリズムまたはルックアップテーブルで構成される。簡単な例では、モデルは、音声データの主成分分析を使用し、音声データの主成分分析は、様々な音声／イベントからの様々な音声データをたとえば２つの第１の主成分によって決定される２次元表面における別々の領域に配置するために、音声信号から抽出された特徴のベクトルを備え、各エリアをイベント指定に関連付ける。通信デバイスでは、特定の録音された音声から得られた音声データにモデルを適用し、この音声データの２次元表面の位置を決定し得る。特定のイベント指定に関連した領域の１つにその位置がある場合、このイベント指定が出力され、ユーザーはこのイベント指定を受け取り得、イベント指定に関連したイベントが、より高い確実性またはより低い確実性で発生したことを知らせ得る。
【００２８】
モデルは、音声データを既知のイベントの音声に関連づけるトレーニング、つまり通信デバイスのユーザーがどのイベントが発生したかを知ることによって、決定され得る。たとえば、ユーザーがイベントを実行したり、イベントを発生させたりするときに、通信デバイスを具体的に操作して音声を録音することである。これは、たとえば、ユーザーがドアを閉めて、ドアが閉まったというイベントに関連する音声を取得することである。ユーザーがイベントを発生させる回数が増えると、より多くの音声データを取得してモデルに含め、領域をより適切にマッピングし得る。上記の例では、ドアが閉まる音の音声データが二次元表面に配置される。処理ノードによって取得された音声データは、処理ノードに保存されているモデルの対象となり得る。イベント指定が、音声データに正しく関連付けられている確実性が十分に高いモデルの１つから取得できる場合、音声データはそのモデルに含まれる場合がある。音声データをモデルに追加すると、特定の音声データがイベント指定に関連付けられる確率をより適切に計算できるようになり得る。上記の簡単な２次元の例を使用すると、同じイベント指定に関連付けられているがわずかに異なる音声データからの２次元表面の多数の位置を使用して、イベント指定に関連付けられている領域の拡張または境界の信頼区間を計算し得る。したがって、たとえば、この追加の音声データの位置を、既にモデルに含まれている音声データの位置と比較することにより、イベント指定をもたらすモデルに追加される音声データの正しい計算を行うことができる。
【００２９】
このようにして、モデルは音声データをイベント指定に関連付ける。処理ノードは、個々のモデルのイベント指定のブーリアン結合に基づくモデルである、結合モデルをさらに特定してもよい。従って、第１モデルからのイベント指定「正面玄関を開ける」および第２のモデルからのイベント指定「犬が吠える」を、「誰かが家に入る」という組み合わせイベント指定に関連付ける、組み合わせモデルを定義してもよい。
【００３０】
さらに、時刻、音声データが１つ以上のモデルに適用された回数など、他のデータまたはルールと組み合わせたモデルからの１つ以上のイベント指定に基づいて、結合モデルを定義してもよい。したがって、結合モデルには、「トイレの水を流す」というイベント指定とカウンターが含まれてもよく、このカウンターは、単純なモデルまたはアルゴリズムと見なしてもよく、イベント指定「トイレットペーパーがなくなった」を、モデルからＸ回取得されたイベント指定「トイレの水を流す」に関連付けてもよい。Ｘは例えば３０である。
【００３１】
モデルは、通信デバイスから音声データを取得するために、上記のネットワークのいずれかを介して通信デバイスに提供されてもよい。
【００３２】
本発明の第１の態様による方法の好ましい実施形態は以下を含む。
ステップ（ｉ）は、第１の複数の通信デバイスから、第２の複数の音声に関連した、第２の複数の音声データを取得し、処理ノードに第２の複数の音声データを保存することを含み、
ステップ（ｉｉ）は、第２の複数の音声データに関連した第２の複数のイベント指定を取得し、処理ノードに第２の複数のイベント指定を保存することを含み、
ステップ（ｉｉｉ）は、各モデルの第２の複数の音声データの１つを第２の複数のイベント指定の１つに関連付け、第２の複数のモデルを決定し、第２の複数のモデルを保存することを含み、
ステップ（ｉｖ）は、第２の複数のモデルを第１の複数の通信デバイスに提供することを含む。
【００３３】
第１の複数の通信デバイスが処理ノードに第２の複数の音声データを提供することにより、通信デバイスの各ユーザーは、そのユーザーに対してまだ発生していないイベントのイベント指定を取得するためのモデルを取得し得る。したがって、各通信デバイスは、さまざまなイベントのはるかに広い範囲のイベント指定を提供し得る。
【００３４】
たとえば、ユーザーＡが通信デバイスＡを有し、トラックが家の外でアイドリングしている音を録音するとする。イベント指定「トラックのアイドリング」に関連するこの音声および音声データはともに、ユーザーＡの指示の下で通信デバイスＡによって処理ノードに提供される。
【００３５】
これで、遠隔地に住むユーザーＢの通信デバイスＢは、ユーザーＡが提供する音声およびイベント指定に関連したモデルを取得できる。これにより、ユーザーＢは、ユーザーＢがそのような音声を自分で録音する必要なく、イベントが発生した場合にトラックが家の外でアイドリングしているというイベント指定を取得できる。第１の複数のものの個数と第２の複数のものの個数とは、等しくても異なっていてもよい。第２の複数のモデルは、様々な方法で第１の複数の通信デバイスに提供され得る。
【００３６】
本発明の第１の態様による方法の１つの代替実施形態では、各通信デバイスは固有の通信デバイスＩＤに関連付けられ、方法はさらに以下のステップ、すなわち、
各通信デバイスから通信デバイスＩＤを取得する、ステップ（ｖ）と、
各通信デバイスからの通信デバイスＩＤを、その通信デバイスから取得した音声データに関連付けるステップ（ｖｉ）と、を含み、
ここで、
ステップ（ｉｉｉ）は、各モデルを、モデルを決定するために使用される音声データが取得された通信デバイスの通信デバイスＩＤと関連付けることを含み、
ステップ（ｉｖ）は、各通信デバイスがその通信デバイスに関連した通信デバイスＩＤに関連したモデルを少なくとも取得するように、第２の複数のモデルを第１の複数の通信デバイスに提供することを含む。
【００３７】
この代替実施形態は、各通信デバイスに少なくともＨＡＴ通信デバイスに関連するモデルが提供されることを保証する。これは、通信デバイスの保管スペースが限られているため、各デバイスにすべてのモデルを保存できない場合に有利である。
【００３８】
通信デバイスＩＤは、任意のタイプの固有番号、コード、または一連の記号または数字／文字としてもよい。
【００３９】
通信デバイスに関連したモデルのみがその通信デバイスに提供される場合、本発明の第１の態様による方法の好ましい実施形態は、さらに以下のステップ、すなわち、
第１の複数の通信デバイスのうちの第１のものから、その通信デバイスに提供されたどのモデルにも関連しない第１の音声データを取得する、ステップ（ｖｉｉ）と、
ステップ（ｉ）で第１の複数の通信デバイスから取得した音声データの中から、第１の複数の通信デバイスのうちの第２のものによって取得した、第１の音声データに類似する第２の音声データを検索する、ステップ（ｖｉｉｉ）と、
そして、第２の音声データが見つかった場合、
第１の複数の通信デバイスのうちの第１のものに、第２の音声データに関連したモデルを提供する、ステップ（ｉｘ）と、
または、第２の音声データが見つからない場合、
第１の複数の通信デバイスのうちの第１のものに、第１の音声データに関連する第１のイベント指定を処理ノードに提供するようにプロンプトを出す、ステップ（ｘ）と、
第１の音声データを第１のイベント指定に関連付ける第１のモデルを決定し、第１のモデルを保存する、ステップ（ｘｉ）と、
第１のモデルを複数の通信デバイスの第１のものに提供する、ステップ（ｘｉｉ）と、を含む。
【００４０】
この実施形態により、モデルは必要な場合にのみ通信デバイスに提供される。これにより、すべてのモデルをすべての通信デバイスに提供する必要なく、幅広いイベントのイベント指定を取得できる。さらに、第２の音声データが見つからない場合、この情報について第１の複数の通信デバイスのうちの第１のものにプロンプトを出すことにより、処理ノード内のモデルの数を増やし得る。
【００４１】
ステップ（ｉ）で第１の複数の通信デバイスから取得した音声データの中から、第１の音声データに類似する第２の音声データを検索することで、計算された精度が設定された制限を超えるイベント指定を提供するモデルがあるかどうかを判断するために、第１の音声データを処理ノードに保存されたモデルに含めるかまたは備えてもよい。
【００４２】
本発明の第１の態様による方法の代替実施形態では、
ステップ（ｉｖ）は、第２の複数のモデルのすべてを第１の複数の通信デバイスのそれぞれに提供することを含む。
【００４３】
これは、通信デバイスと処理ノード間の通信の必要性を減らすため、通信デバイスのストレージ容量がすべてのモデルを保存するのに必要な容量よりも大きい場合に有利である。
【００４４】
本発明の第１の態様による方法の好ましい実施形態では、方法はさらに以下のステップ、すなわち、
各通信デバイスから、音声に関連した非音声データを取得し、処理ノードに非音声データを保存する、ステップ（ｘｉｉｉ）と、を含み、
ここで、
ステップ（ｉｉｉ）は、音声データと非音声データをイベント指定に関連付けるモデルを決定することを含む。
【００４５】
これは、発生したイベントを適切に指定するイベント指定の精度を高め得るため、有利である。
【００４６】
本発明の第１の態様による方法の好ましい実施形態では、非音声データは、気圧データ、加速度データ、赤外線センサーデータ、可視光センサーデータ、ドップラーレーダーデータ、無線送信データ、大気中粒子データ、温度データおよび音声定位データのうちの１つ以上を含む。
【００４７】
したがって、部屋の気圧の変動に関連した気圧データは、ドアが閉じる音とイベントに関連付けられてもよく、ドアが閉じられたというイベント指定をより正確に提供するモデルを決定するために使用される。
【００４８】
さらに何かが燃えているというイベント指定をより正確に提供するために、温度データを炎が燃えるときのパチパチという音に関連付けてもよい。
【００４９】
音声データは、発生するイベントに関する豊富な情報源であるが、本発明の文脈内では、本発明の第１および第２の態様による方法は、非音声データのみを使用して実行されてもよいと考えられる。
【００５０】
さらに、本発明の第１の態様による方法の好ましい実施形態では、様々なアルゴリズムを使用してモデルを構築してもよく、
ステップ（ｉｉｉ）で決定された各モデルは、第３の複数のサブモデルを含み、各サブモデルは、音声データと必要に応じて非音声データとを、イベント指定に関連付ける様々な処理またはアルゴリズムを使用して決定される。
【００５１】
様々なサブモデルのイベント指定は、精度を測定するか、重み付けておよび組み合わせにより精度を高めることができる。
【００５２】
本発明の第１の態様による方法の好ましい実施形態では、各モデルおよび／またはサブモデルは、周波数領域変換された音声データおよび必要に応じて非音声データの特徴の主成分分析に少なくとも部分的に基づいており、および／または、周波数領域の変換された音声データおよび必要に応じて非音声データのヒストグラムデータに少なくとも部分的に基づいている。
【００５３】
本発明の第１の態様による方法の好ましい実施形態では、方法はさらに以下のステップ、すなわち、
少なくとも１つの通信デバイスから、音声に関連する第３の音声データおよび／または非音声データを取得し、第３の音声データおよび／または非音声データを処理ノードに保存する、ステップ（ｘｉｖ）と、
処理ノードに保存された音声データおよび／または非音声データの中から、第３の音声データおよび／または非音声データに類似する第４の音声データおよび／または非音声データを検索する、ステップ（ｘｖ）と、
音声および／または非音声データが見つかった場合、
第４の音声データおよび／または非音声データに関連したイベント指定を第３の音声データおよび／または非音声データならびに第４の音声データおよび／または非音声データの両方に関連付けることにより、第４の音声データおよび／または非音声データに関連したモデルを再決定する、ステップ（ｘｖｉ）と、を含む。
【００５４】
これは、モデルを改良し、特定のイベント指定が正しい正確性または確率を有するより良い推定を提供するため、有利である。複数の音声データを使用して、モデルを再決定してもよい。
【００５５】
上記のオブジェクトの少なくとも１つは、第１の音声データを第１のイベント指定に関連付ける第１のモデルが保存される通信デバイスによって実行される方法によってさらに取得され、以下のステップ、すなわち、
音声の音声信号を記録し、音声信号に基づいて音声に関連する音声データを生成し、音声データを保存する、ステップ（ｘｖｉｉ）と、
第１の音声データに関連した第１のイベント指定を取得するために、音声データを通信デバイスに保存された第１のモデルに適用する、ステップ（ｘｖｉｉｉ）と、
ステップ（ｘｖｉｉｉ）で第１のイベント指定が取得されない場合、次のステップ、すなわち、
音声データを処理ノードに提供する、ステップ（ｂ）と、
処理ノードから、第２の音声データに関連した第２のイベント指定に、音声データを関連付ける、第２のモデルを取得し、保存する、ステップ（ｃ）と、
第２の音声データに関連した第２のイベント指定を取得するために、音声データを通信デバイスに保存された第２のモデルに適用する、ステップ（ｄ）と、
第２のイベント指定を通信デバイスのユーザーに提供する、ステップ（ｅ）と、を実行する、
ステップ（ｘｉｘ）と、を含む。
【００５６】
本発明の第１の態様による方法で述べたステップおよび特徴の説明は、本発明の第２の態様による方法のステップおよび特徴にも当てはまる。
【００５７】
音声データは、モデルがイベント指定を生成するように、第１または第２のモデルに適用される。
【００５８】
イベントの指定は、インターネットを介して、たとえばユーザーの携帯電話へのメールとして、ユーザーに提供される。
【００５９】
ユーザーは人間であることが好ましい。
【００６０】
したがって、本発明の第２の態様による方法の好ましい実施形態では、
第１および第２モデルは、さらに、第１および第２非音声データを第１および第２イベント指定にそれぞれ関連付け、
ステップ（ｘｖｉｉ）は、音声に関連する非音声データを取得し、非音声データを保存することをさらに含み、
ステップ（ｘｖｉｉｉ）は、非音声データを音声データとともに第１のモデルに適用することをさらに含み、
ステップ（ｘｉｘ）（ｂ）は、非音声データを処理ノードに提供することをさらに含み、
ステップ（ｄ）は、非音声データを第２のモデルに適用することをさらに含む。
【００６１】
上述のように、非音声データは、音声データおよび非音声データに基づいてイベント指定を提供する際に、モデルの精度を高める可能性があるため、有利である。
【００６２】
さらに、本発明の第２の態様による方法の好ましい実施形態では、非音声データは、通信デバイス内のセンサーによって取得され、気圧データ、加速度データ、赤外線センサーデータ、可視光センサーデータ、ドップラーレーダーデータ、無線伝送データ、大気中粒子データ、温度データ、音声定位データのうちの１つ以上を備える。
【００６３】
通信デバイスは、非音声データを提供するためのさまざまなセンサーを備えてもよい。
【００６４】
処理ノード内のモデルの数を連続的に増加させるために、本発明の第２の態様による方法の一実施形態では、
ステップ（ｘｖｉｉ）は、
音声信号のエネルギーを継続的に測定する、ステップ（ｆ）と、
音声信号のエネルギーが閾値を超えると、音声データを記録および生成する、ステップ（ｇ）と、
こうして生成された音声データを処理ノードに提供する、ステップ（ｈ）と、を含み、
そして、この方法はさらに、
処理ノードに提供された音声データに関連するイベント指定のプロンプトを処理ノードから受信する、ステップ（ｘｘ）と、
通信デバイスのユーザーからイベント指定を取得する、ステップ（ｘｘｉ）と、
処理ノードにイベント指定を提供する、ステップ（ｘｘｉｉ）と、
処理ノードから、ユーザーから取得したイベント指定に音声データを関連付けるモデルを取得する、ステップ（ｘｘｉｉｉ）と、を含む。
【００６５】
これは、各通信デバイスが処理ノード内のモデルの数を増やすことを支援できるため、有利である。
【００６６】
したがって、通信デバイスは、音声信号を連続的に取得し、音声信号内のエネルギーを測定してもよい。
【００６７】
閾値は、時刻に基づいて設定され、および／または非音声データに基づいて増減される。
【００６８】
処理ノードからのプロンプトは、通信デバイスによって、通信デバイスのユーザーが保持している、携帯電話などの別のデバイスに転送されてもよい。
【００６９】
さらに、本発明の第２の態様による方法の一実施形態では、
通信デバイスによって取得および／または保存された各モデルは、複数のサブモデルを備え、各サブモデルは、音声データ、および必要に応じて非音声データをイベント指定に関連付ける様々な処理またはアルゴリズムを使用して決定され、および、
ステップ（ｘｖｉｉｉ）は、
複数のサブモデルから複数のイベント指定を取得する、ステップ（ｘｖｉｉｉ）（ｉ）と、
複数のイベント指定のそれぞれが、音声データに関連するイベントに対応する確率を決定する、ステップ（ｊ）と、
複数のイベント指定のうち、ステップ（ｊ）で決定された最も高い確率を有するイベント指定を選択し、そのイベント指定を通信デバイスのユーザーに提供する、ステップ（ｋ）と、を含む。
これは、イベントの検出範囲を拡大できるという利点がある。
【００７０】
さらに、本発明の第２の態様による方法の一実施形態では、各モデルおよび／またはサブモデルは、周波数領域変換された音声データおよび必要に応じて非音声データの特性の主成分分析に少なくとも部分的に基づいており、および／または周波数領域変換された音声データのヒストグラムデータおよび必要に応じて非音声データに少なくとも部分的に基づく。
【００７１】
上記の目的の少なくとも１つは、本発明の第１の態様による方法を実行するように構成された処理ノードに関する本発明の第３の態様によってさらに得られる。
【００７２】
上記の目的の少なくとも１つは、本発明の第２の態様による方法を実行するように構成された通信デバイスに関する本発明の第４の態様によってさらに達成される。
【００７３】
上記の目的の少なくとも１つは、本発明の第３の態様による処理ノードと、本発明の第４の態様による少なくとも１つの通信デバイスと、を備えるシステムに関する、本発明の第５の態様によってさらに得られる。
【００７４】
本発明の追加の第６および第７の態様は、
少なくとも１つの処理ノードで実行されると、処理ノードに本発明の第１の態様による方法を実行させる命令を含むコンピュータプログラム、
および
通信デバイスの少なくとも１つのプロセッサで実行されると、通信デバイスに本発明の第２の態様による方法を実行させる命令を含むコンピュータプログラム、に関する。
【図面の簡単な説明】
【００７５】
本発明の、上記の特徴および他の特徴、ならびに利点のより完全な理解は、添付の図面とともに、好ましい実施形態の以下の詳細な説明から明らかになるであろう。
【図１】本発明の第３の態様による処理ノードによって実行される、本発明の第１の態様による方法を示す。
【図２】本発明の第４の態様による通信デバイスによって実行される、本発明の第２の態様による方法を示す。
【図３】処理ノードをトレーニングするために音声データを取得し得るさまざまな方法を示すフローチャート。
【図４】音声データを生成し、音声データを１つ以上のサブモデルに適用して、通信デバイス上のイベント指定を取得するためのパイプラインのフローチャート。
【図５】ＳＴＡＴアルゴリズムおよびモデルのパイプラインを示すフローチャート。
【図６】ＬＭアルゴリズムおよびモデルのパイプラインを示すフローチャート。
【図７】通信デバイスにおける電力管理を示すフローチャート。
【図８】追加のセンサーからの非音声データをＳＴＡＴアルゴリズムとモデルで使用し得る方法を示すフローチャート。
【図９】複数のマイクからの複数の音声データを使用して音声の発生元を特定し、ビーム形成のために音声の発生元の位置を使用し、さらにＳＴＡＴアルゴリズムおよびモデルで使用される非音声データとして使用する方法を示すフローチャート。
【図１０】目覚まし時計の音声サンプルのスペクトログラムを示す。
【図１１】生の音声サンプルのＭＦＣＣ特徴を示す。
【図１２】フレームのスペクトルエネルギー（実効エネルギー）を測定することにより、さまざまなイベントの音声データを含む音声データのセグメンテーションと、ＭＦＣＣ特徴などの特徴を取得し、イベントのノイズと情報音声の区別および検出に使用できる結果のスペクトログラムと、を示す。
【００７６】
以下の図の説明では、図全体を通して同じ特徴を示すために同じ参照番号が使用されている。さらに、参照番号に「’」が追加されているのは、その特徴が、「’」記号を持たない対応する参照番号で指定された特徴の変形であることを示している。
【発明を実施するための形態】
【００７７】
図１は、本発明の第３の態様による処理ノード１０によって実行される本発明の第１の態様による方法を示している。
【００７８】
処理ノード１０は、例えば、矢印１１で示すように、インターネットなどのネットワークを介して、通信デバイス１００から音声データ１２を取得する。この音声データは、ストレージまたはメモリ１４に保存１３される。
【００７９】
次に、例えばインターネットなどのネットワークを介して、矢印１５で指定される通信デバイス１００から、または参照番号１５’で示される別のチャネルから、イベント指定１６が取得される。
【００８０】
イベント指定１６は、１４と同じストレージまたはメモリであり得るストレージまたはメモリ１８に保存１７される。次に、音声データ１２とイベント指定１６とを関連付けるモデル２０が決定１９され、そして、モデルに音声データ１２を入力すると、イベント指定１６が生成される。このモデル２０は、ストレージまたはメモリ１４および１８と同じであっても異なっていてもよいストレージまたはメモリ２２に保存２１される。次に、モデル２０が通信デバイス１００に提供２３され、したがって、図２に示されるように、通信デバイス１００に、通信デバイスが音声データに基づいてイベント指定を取得するために使用することができるモデル２０が提供される。
【００８１】
必要に応じて、処理ノード１０は、通信デバイス１００から固有の通信デバイスＩＤ２６を取得２５することもできる。この通信デバイスＩＤ２６は、ストレージまたはメモリ１４にも保存され、モデル２０に関連付けられ、通信デバイス１００が複数ある場合、各通信デバイス１００は、通信デバイスから取得した音声データに対応するモデル２０を取得してもよい。
【００８２】
さらに、処理ノード１０が音声データ１２を取得する場合、ステップ２９において、ストレージ２２にモデル２０がすでに存在するかどうかを判断してもよく、その場合、このモデルは、新しいモデルを決定する必要なしに通信デバイス１００に提供２３’されてよい。
【００８３】
ストレージ２２内の音声データ１２についてモデル２０が見つからない場合、処理ノード１０は、イベント指定１６を取得するように通信デバイスに指示３１し、その後、モデルは矢印３５で示されるように決定され得る。
【００８４】
また、非音声データ３４は、処理ノードによって取得３３されてもよい。この非音声データ３４は、音声データ１２と同じ方法で１３、１４に保存され、モデル２０を決定するときにも使用される。
【００８５】
各モデル２０は、複数のサブモデル４０を含んでもよく、様々なアルゴリズムまたは処理を使用して、音声データ１２、および必要に応じて非音声データ３４をイベント指定にそれぞれ関連付ける。
【００８６】
処理ノード１０および少なくとも１つの通信デバイス１００は、システム１０００に組み合わされてもよい。
【００８７】
図２は、本発明の第４の態様による通信デバイス１００によって実行される、本発明の第２の態様による方法を示す。
【００８８】
こうして、イベント１が発生すると、イベントで発生する音声の音声信号１０２が取得１０１される。音声信号１０２は、音声に関連する音声データ１２を生成１０３するために使用される。
【００８９】
音声データ１２は、通信デバイス１００のストレージまたはメモリ１０６に保存１０５される。
【００９０】
次に、この音声データ１２は、通信デバイス１００に保存されたモデル２０に適用１０７され、音声データのイベント指定１６を取得するために使用される。
【００９１】
次に、イベント指定は、通信デバイス１００のユーザー２、もしくは例えばユーザーの携帯電話または電子メールアドレスに提供１０９される。
【００９２】
しかし、イベント指定１６が取得されない場合、すなわち、通信デバイス１００に保存されたモデル２０のいずれも音声データ１２をイベント指定に関連付けない場合、通信デバイスは処理ノード１０に音声データ１２を提供１１１する。図１に示すように、処理ノードはモデル２０を決定する。次に、このモデル２０は、通信デバイス１００に提供１１３され、１０６と同じであってもよいストレージまたはメモリ１１６に保存され、その後イベント指定１６は現在保存されているモデル２０から取得され得る。
【００９３】
必要に応じて、通信デバイス内のセンサーからさらなる非音声データ３４も取得１１７される。この非音声データ３４もモデル２０にかけられ、イベント指定１６を取得するために使用され、上述のように処理ノード１０に提供１１１されてもよい。
【００９４】
さらに下の図７に示すように、音声信号１０２のエネルギーを測定１１９して、エネルギーが閾値を超える場合にのみ音声データ１２を取得してもよい。閾値を超えると、音声データ１２が取得され、処理ノード１０に提供１２１される。その後、通信デバイスは、ユーザー２により提供されるイベント指定１６’のプロンプト１２４を受信１２３し、いったん提供されると、通信デバイス１００がイベント指定１６’を処理ノード１０に提供し、その後処理ノード１０はモデル２０を通信デバイスに提供し得る。
【００９５】
通信デバイス１００に複数のモデル２０を保存することにより、複数のイベントに関連した複数のイベント指定を取得し得る。
【００９６】
通信デバイス１００は、イベントを検出できることが望ましい、任意の適切な場所に配置されてもよい。
【００９７】
モデル２０は、必要ならば通信デバイス１００に提供されてもよい。モデルは通常、通信デバイス１００のユーザー２に固有のイベントに関連する両方のモデルを含むが、銃声、ガラスの割れる音、アラーム、犬の鳴き声、ドアベル、悲鳴、咳などの一般的な音のモデルも含む。
【００９８】
図３は、処理ノード１０をトレーニングするために音声データが取得される様々な方法を示すフローチャートである。
【００９９】
最も一般的な代替方法は、デバイス１００が継続的かつ自律的に音声から音声データ１２を取得するとき、およびこの音声データが通信デバイス１００に保存されたモデルを使用してイベント指定を生成しないことを発見した後、この音声データ１２を処理ノード１０に提供１２１することである。
【０１００】
次いで、処理ノード１０は、定期的または即座に、通信デバイス１００にイベント指定１６を提供するようにプロンプト３１を出してよい。プロンプトには、処理ノードに保存されているモデルを使用して決定された最も可能性の高いイベントの指示が含まれる場合がある。
【０１０１】
音声データ１２を収集する別の方法は、ユーザーがスマートフォン２などの別のデバイスを使用して、通信デバイス１００で実行しているものと同様のソフトウェアを実行し、音声を録音して音声データを取得し、イベント指定とともに音声データを処理ノード１０へ送信できるようにすることである。
【０１０２】
スマートフォン２を使用して、通信デバイス１００に音声信号を記録させ、イベント指定とともに音声データを取得して処理ノード１０に送信させることもできる。
【０１０３】
すべての場合において、通信デバイスと処理ノード１０との間、およびスマートフォン２と処理ノード１０との間の通信は、インターネットまたはワールドワイドウェブまたは無線データリンクなどのネットワークを介して実行されることが好ましい。
【０１０４】
要約すると、図３は、スマートフォン２がユーザーリクエストに音声データを提供し、通信デバイス１００が自律的に音声データを提供し、通信デバイス１００がユーザーリクエストに音声データを提供し、他の通信デバイス１００が音声データを提供することを示している。
【０１０５】
図４は、音声データを生成し、音声データを１つ以上のサブモデルに適用して通信デバイス１００上のイベント指定を取得するためのパイプラインのフローチャートである。
【０１０６】
通信デバイス１００が置かれている場所の音声は、マイクロホン１３０によって連続的に取得され、電気音声信号１０２に変換される。次に、この信号は、自動利得制御モジュール１３２を使用して音声信号の音量を正規化する自動利得制御のステップによって操作される。次に、この音声信号は、ＤＣリジェクトモジュール１３４でのハイパスフィルタリングによりさらに処理され、音声信号のＤＣ電圧オフセットが除去される。次いで、このように正規化およびフィルタリングされた信号は、音声信号が周波数領域音声データに変換されるＦＦＴモジュール１３６で高速フーリエ変換を受けることによって、音声データ１２を得るために使用される。この変換は、２秒の長さの着信音声サンプルごとに行われ、信号の短時間フーリエ変換（ＳＴＦＴ）を取得して音声信号のスペクトログラムを作成する。したがって、短時間のフレームのＦＦＴが計算され、そのフレームは、音声信号の終わりに達するまで、たとえば１０ｍｓ（５０％オーバーラップ）だけスライドする。
【０１０７】
あるいは、ＳＦＴＦは連続的に、つまり音声サンプルを２ｓサンプルに分割せずに計算される。
【０１０８】
音声データ１２は、周波数領域と時間領域のデータとを含むようになり、通信デバイスに保存されたモデルに適用される。この場合、モデル２０には、分析パイプラインとも呼ばれるいくつかのサブモデルが含まれる。これらのサブモデルのＳＴＡＴサブモデル４０とＬＭサブモデル４０’は２つである。
【０１０９】
サブモデルの結果は、イベント指定につながり、選択モジュール１３８で評価されるように、正しいイベント指定の計算された確率または確実性に基づいた選択後に、イベント指定を取得する。
【０１１０】
具体的には、各サブモデルは、イベント指定が取得される精度、つまり特定のイベントが決定される精度、または代替として正しいイベントが決定される確率の、推定値または実際の値を提供し得る。計算された確率または確実性は、音声データ１２が処理ノード１０に提供されるべきかどうかを決定するためにも使用され得る。
【０１１１】
通信デバイス１００は、本発明の第１の態様による方法を実行するためのプロセッサ２００を備えてもよい。
【０１１２】
図５は、ＳＴＡＴアルゴリズムとモデル４０のパイプラインを示すフローチャートである。
【０１１３】
このアルゴリズムは、入力として、周波数領域の音声データと時間領域の音声データとを含む音声データ１２を取得し、たとえばＭＦＣＣ（メル周波数ケプストラム係数）１４２、それらの一次導関数１４４および二次導関数１４６、スペクトル重心１４８、スペクトル帯域幅１５０、実効エネルギー１５２および時間領域ゼロ交差率１５４からなる連結によって特徴ベクトル１４０を構築する。いくつかの特徴ベクトルのウィンドウにわたるこれらの特徴の平均１５６および標準偏差１５８もまた計算され、連結により特徴ベクトル１６０を形成するために付加される。次に、各特徴ベクトル１６０はスケーリング１６２され、ＰＣＡ（主成分分析）１６４を使用して変換され、次いで分類のためにＳＶＭ（サポートベクトルマシン）１６６に供給される。ＰＣＡおよびＳＶＭのパラメータは、サブモデル４０で提供される。
【０１１４】
ＳＶＭ１６６は、処理された各特徴ベクトルのクラス識別子および確率１６８としてイベント指定１６を出力し、したがって、どのイベント指定が音声データおよび確率に関連付けられているかを示す。
【０１１５】
図５では、サブモデル４０は音声データ１２の処理の大部分を包含するように示されている。なぜなら、この場合、主成分分析１６４に供給される特徴ベクトル１６０の要件はモデルの一部と考えられるからである。
【０１１６】
あるいは、サブモデル４０は、ＰＣＡ１６４およびＳＶＭ１６６に必要なパラメータのみを包含するように定義されてもよく、その場合、音声データはスケーリング１６２後の特徴ベクトル１６０を包含すると理解されるべきであり、上記の手順は、音声データの取得／生成方法の一部である。
【０１１７】
図６は、ＬＭアルゴリズムとモデル４０’のパイプラインを示すフローチャートである。このモデルは、周波数領域の入力音声データ１２を受け取り、ピーク抽出モジュール１７０で連続スペクトログラムデータの顕著なピークを抽出し、時間と周波数空間で適切なピーク密度が維持されるようにピークをフィルタリングする。次に、これらのピークをペアにして、「ランドマーク」を作成する。基本的には３−タプル（周波数１（ｆ１）、周波数２の時間−周波数１の時間（ｔ２−ｔ１）、周波数２−周波数１（ｆ２−ｆ１））である。これらの３−タプルは、ハッシュモジュール１７２でハッシュに変換され、ハッシュテーブル１７４を検索するために使用される。ハッシュテーブルは、ハッシュデータベースに基づいている。
【０１１８】
見つかった場合、ハッシュテーブルは、モデルを決定するために処理ノードに提供された（トレーニング）音声データからこのランドマークが抽出されたタイムスタンプを返す。
【０１１９】
ｔ１（分析対象の音声データからランドマークが抽出されたタイムスタンプ）と返された参照タイムスタンプとの間のデルタが、ヒストグラム１７４に送られる。時間の経過とともにヒストグラムに十分に高いピークが発生した場合、アルゴリズムは、分析されたデータでトレーニングされた音声が発生したこと（つまり、正しい順序で複数のランドマークが見つかったこと）を確立でき、イベント指定１６が取得される。時間単位ごとの正しいヒストグラムビン内のハッシュの一致数は、精度１７６の尺度として使用できる。
【０１２０】
図５では、音声データ１２の処理の大部分を包含するようにＬＭサブモデルが示されている。なぜなら、この場合、ハッシュテーブルルックアップ１７２の要件はモデルの一部と見なされるからである。
【０１２１】
あるいは、ＬＭサブモデル４０’はハッシュデータベースのみを含むように定義できる。この場合、音声データはステップ１７２の後に生成されたハッシュを含むと理解され、上記の手順は、音声データの取得／生成方法の一部である。
【０１２２】
図７は、通信デバイス１００における電力管理を示すフローチャートである。
【０１２３】
好ましくはバッテリー式である通信デバイス１００では、電力の節約が非常に重要である。したがって、音声データを取得してモデルに音声データを供する音声処理は、十分なエネルギーの音声が存在する場合、または通信デバイスが他のセンサーを使用してイベントを検出した場合にのみ実行するべきである。
【０１２４】
したがって、通信デバイス１００は、閾値検出器１８０、電力モード制御モジュール１８２、および閾値制御モジュール１８４を含んでもよい。閾値検出器１８０は、マイクロホン１３０からの音声信号のエネルギーを連続的に測定１１９し、それが特定のプログラム可能な閾値を超える場合に電力モード制御モジュール１８２に通知するように構成される。次に、電力モード制御モジュール１８２は、プロセッサを起動して、音声データを取得し、音声データをモデルに供してよい。電力モード制御モジュール１８２は、マイクロホン１３０の性能モード（低電力、低性能対高電力、高性能）と同様にサンプルレートをさらに制御してもよい。
【０１２５】
電力モード制御モジュール１８２は、例えば、気圧計を使用する圧力過渡変動、加速度計を使用する衝撃、受動赤外線センサー（ＰＩＲ）を使用する動き、およびドップラーレーダーおよび／または時刻などのその他のデータなど、マイクロホン１３０以外のセンサーによって検出されるイベントを入力としてさらに取得してもよい。
【０１２６】
電力モード制御モジュール１８２はさらに、例えば平均エネルギーレベルまたは時刻などの他のデータに基づいて閾値検出器１８０の閾値を設定する閾値制御モジュール１８４を設定する。
【０１２７】
いずれの場合も、自動イベント検出（ＡＥＤ）を開始するために、閾値を超えたために取得された音声データがプロセッサに提供される。つまり、音声データをモデルに適用し、イベント指定を取得する。
【０１２８】
図８は、追加のセンサーからの非音声データをＳＴＡＴアルゴリズムおよびモデルで使用し得る方法を示すフローチャートである。
【０１２９】
したがって、マイクロホン１３０からの音声データに加えて、データは、気圧計１３０’、加速度計１３０’’、受動赤外線センサー（ＰＩＲ）１３０’’’、環境光センサー（ＡＬＳ）１３０’’’’、ドップラーレーダー１３０’’’’’、または１３０’’’’’’で表されるその他のセンサーによって提供されてもよい。
【０１３０】
いずれの場合も、非音声データはセンサー固有の信号調節（ＳＣ）、フレームレート変換（様々なセンサーから特徴ベクトルレートが一致することを確認する）、そして、連結によって特徴ベクトル１６０に結合される前の適切な特徴の特徴抽出（ＦＥ）を受け、したがって拡張特徴ベクトル１６０’を形成する。次いで、拡張された特徴ベクトル１６０’は、図５に示されるように特徴ベクトル１６０として扱われ得、イベント指定を取得するために、主成分分析１６４およびサポートベクターマシン４６６を使用する。
【０１３１】
あるいは、追加のセンサーからの非音声データ３４を処理ノード１０に提供し、そこで評価を行い、イベントの検出の精度を高め得る。これは、通信デバイス１００が計算機能を欠いている場合、またはあるいは、例えば制限された電力により、拡張特徴ベクトル５６’で動作することを制約されている場合に有利であり得る。
【０１３２】
図９は、複数のマイクロホンからの複数の音声データを使用して音声の発生元を特定し、音声の発生元の位置をビームフォーミングに使用し、さらに非音声データとしてＳＴＡＴアルゴリズムとモデル４０で使用できる方法を示すフローチャートである。
【０１３３】
図９に示す通信デバイス１００では、ＸＣＯＲＲ、ＧＣＣ−ＰＨＡＴ、ＢＭＰＨまたは同様のアルゴリズムを使用して音声の発信元を特定し、ビームフォーミングのために音声の発生元の位置を使用し、および  ＳＴＡＴパイプライン／アルゴリズムにおける拡張機能ベクトル１６０’に追加される非音声データをさらに追加するように、複数のマイクロホン１３０のアレイからの複数の音声データストリームを使用できる。
【０１３４】
したがって、音声定位モジュール１９０は、拡張特徴ベクトル１６０’に追加するための空間的特徴を抽出してもよい。
【０１３５】
さらに、音声信号のＳＮ比を改善するために、音声定位モジュール１９０によって提供される空間的特徴に基づいて、ビーム形成モジュール１９２を使用して、マイクロホン１３０からの音声信号を組み合わせて処理することができる。空間的特徴を使用して、ユーザー固有のイベントの検出性能をさらに改善したり、追加の見識を提供したりできる（たとえば、どのドアが開かれたかを検出する、移動する音声を追跡するなど）。
【０１３６】
消費電流を最小限に抑えるために、アレイ内の１つを除くすべてのマイクの電源を切って、アイドルモードにすることができる。
【実施例１】
【０１３７】
（ＬＭパイプラインのプロトタイプ実装）
プロトタイプシステムは、目覚まし時計が鳴る長さの２秒の音声サンプルを記録するように構成されたプロトタイプデバイスを含むようにセットアップされた。これらの音声サンプルは、処理のためにデバイスの一時メモリに一時的に保存された。
【０１３８】
処理は、最初に短時間フーリエ変換（ＳＴＦＴ）（図４のＦＦＴモジュール１８に対応）を使用して実行され、スペクトログラムが作成される。ＳＴＦＴプロセスでは、短時間フレームのＦＦＴが計算され、そのフレームは、音声信号の終わりに達するまで１０ミリ秒（５０％オーバーラップ）ずつスライドする。この場合、２０ｍｓフレームが使用され、１０２４のＦＦＴサイズ、つまり１０２４の様々な周波数ビンの信号の周波数成分の解像度が得られた。
【０１３９】
図１０に、目覚まし時計の音声サンプルのスペクトログラムを示す。図に見られるように、音声サンプルの「関心」部分をできるだけ多くカバーするように、スペクトルピークは時間領域に沿って分布している。ランドマークである円は、２つのスペクトルピーク間のペアであり、特定の時間の音声サンプルを識別する。
プロトタイプ実装では、各ランドマークに対して６ペアが使用され、各ランドマークは
ランドマーク：［ｔｉｍｅ１、ｆｒｅｑｕｅｎｃｙ１、ｄｔ、ｆｒｅｑｕｅｎｃｙ２］
の形式を有する。
【０１４０】
したがって、ランドマークは、音声サンプルのスペクトログラムから定義された２次元空間の座標である。次に、ランドマークはハッシュに変換され、ローカルデータベース／メモリブロックに保存された。
【実施例２】
【０１４１】
（ＳＴＡＴパイプラインサブモデルのプロトタイプ実装）
上記のプロトタイプシステムでは、ＳＴＡＴパイプラインもまた次のように実装され
た。入力音声は、信号のエネルギーに応じてセグメントに分割され、これにより、適応エネルギーの閾値を超える音声セグメントは、知覚的、スペクトル的、時間的特徴が抽出される、処理チェーンの次のステージに移動する。
【０１４２】
音声セグメンテーションアルゴリズムは、４つの連続した音声フレームの実効エネルギーを計算することから始まる。次の入力フレームでは、現在および前の４フレームからの平均実効エネルギーが計算され、特定の閾値を超えると、現在のフレームのオンセットが作成される。一方、オフセットは、平均実効エネルギーが事前に定義された閾値を下回ると生成される。
【０１４３】
閾値を超える各音声セグメントは処理されるべきである。これには、各音声セグメントを２０ミリ秒のフレームに５０％のオーバーラップで分割することが含まれる。これは、時間領域データに加えて周波数領域データを取得するために、上記のような短時間フーリエ変換（ＳＴＦＴ）を実行することをさらに含む。
【０１４４】
各音声フレームに対して、次の機能が計算される。
・１３メル周波数ケプストラム係数（ＭＦＣＣ）（ＭＦＣＣ０を含まない）
・ＭＦＣＣのデルタ（一次導関数）
・ＭＦＣＣのデルタのデルタ（二次導関数）
・スペクトル重心
・スペクトル拡散
・ゼロ交差率
・二乗平均平方根エネルギー
合計４３個の特徴を累積し、サイズＭｘＮの音声セグメントごとに１つの特徴マトリックスを生成する。ここで、Ｍは音声セグメントのフレーム数、Ｎは特徴の数（４３）である。それから、特徴マトリックスは、図５と比較して、サイズ１ｘ８６のベクトルになる特徴マトリックスの各特徴の統計（平均、標準）を含む単一の特徴ベクトルに変換される。
【０１４５】
特徴マトリックスの平均化は、０．５秒のコンテキストウィンドウと０．１秒のオーバーラップを使用して行われる。特徴マトリックスの各行が分類されるデータポイントを表す場合、分類前にデータポイントを削減／平均化して、観測値のノイズをフィルタリングする。ノイズフィルタリング後の結果を示す実証については、図１０の右側のグラフを参照のこと。
【０１４６】
結果として得られるベクトルは、サポートベクターマシン（ＳＶＭ）に送られ、音声セグメント（分類）の識別情報が決定される。生の音声サンプルのＭＦＣＣ特徴を示す図１１を参照すると、実線は分類器の判定面を示し、破線はより軟判定の面を示している。
【０１４７】
イベント検出に使用される分類器は、サポートベクターマシン（ＳＶＭ）である。分類器は、Ｋ−ＳＶＭがバイナリ分類問題でトレーニングされる１対１のストラテジーを使用してトレーニングされる。Ｋは、分類器の数のＣ×（Ｃ−１）／２に等しく、Ｃは音声検出問題における音声分類の数である。ＳＶＭのトレーニングは、音声セグメンテーション、特徴抽出、および上記と同じアプローチを使用して行われたＳＶＭ分類で行われ、図１２に示されている。
【０１４８】
図１２の一番上のグラフは、さまざまなイベントの音声データを含む音声サンプルと、セグメントのオンセットとオフセットを示すマーカーで定義された指定のセグメントを示している。上記のように、セグメントはフレームのスペクトルエネルギー（実効エネルギー）を測定することによって定義される（上から２番目のグラフを参照のこと）
【０１４９】
３番目のフレームに見られるように、実効エネルギーに対応するフレームごとのスペクトルの広がりが存在する。
【０１５０】
その結果、スペクトログラム（下から２番目のグラフ）が得られ、ＭＦＣＣ特徴などの特徴を取得して、ノイズと有益な音声の区別およびイベント指定の取得に使用できる。
【図１】
2020524300.tif 000003
【図２】
2020524300.tif 000004
【図３】
2020524300.tif 000005
【図４】
2020524300.tif 000006
【図５】
2020524300.tif 000007
【図６】
2020524300.tif 000008
【図７】
2020524300.tif 000009
【図８】
2020524300.tif 000010
【図９】
2020524300.tif 000011
【図１０】
2020524300.tif 000012
【図１１】
2020524300.tif 000013
【図１２】
2020524300.tif 000014
【国際調査報告】
2020524300.tif 000015
2020524300.tif 000016
2020524300.tif 000017
2020524300.tif 000018