音源位置探査システム
【課題】モバイル端末を用いて音源位置の推定精度を向上させる音源位置探査システムを提供する。
【解決手段】端末１０００のデータ送信部１００６は、マイクロホン１００１、音響指紋変換部１００２、メモリ１００３、位置取得部１００４及びマイク方向取得部１００５から取得したデータをまとめて音声タグとして音源位置サーバ１０１０に送付する。音源位置サーバ１０１０は、端末１０００から送信された音声タグを音声タグＤＢ１０１２に登録し、音源位置計算部１０１３は、新規音声タグの音響指紋が登録済の音声タグの音響指紋に一致あるいは似た部分がないか音声タグＤＢ１０１２を検索する。音響指紋の一致列が見付かった場合には、音源位置計算部１０１３は、マイクロホンの指向性に関する情報を、音源が存在しうる位置の範囲として読み換えることで、音源の位置推定を行う。
【解決手段】端末１０００のデータ送信部１００６は、マイクロホン１００１、音響指紋変換部１００２、メモリ１００３、位置取得部１００４及びマイク方向取得部１００５から取得したデータをまとめて音声タグとして音源位置サーバ１０１０に送付する。音源位置サーバ１０１０は、端末１０００から送信された音声タグを音声タグＤＢ１０１２に登録し、音源位置計算部１０１３は、新規音声タグの音響指紋が登録済の音声タグの音響指紋に一致あるいは似た部分がないか音声タグＤＢ１０１２を検索する。音響指紋の一致列が見付かった場合には、音源位置計算部１０１３は、マイクロホンの指向性に関する情報を、音源が存在しうる位置の範囲として読み換えることで、音源の位置推定を行う。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、音源の位置を探査する音源位置探査システムに関する。
【背景技術】
【０００２】
音源探査技術は、例えば、騒音源を探知することで騒音減少に役立てたり、位置が異なる複数の音源を分離するための前処理として行われたり、あるいは、音源の位置を測定することにより、位置をトリガーとするなんらかのサービスを行ったり、様々な目的に利用される。
【０００３】
目的が様々であるために、音源探査を行う装置にも様々な形のものがある。例えば、騒音の測定機器に利用されるようなものは、機器を大量に安価に生産したり、携帯性に優れたものにする必要性が低く、逆に、精度に対する要求が強いために、機器は大型化したり特殊化したりする傾向にある。具体的には、多数のマイクロホンをアレー状に並べたマイクロホンアレイを用いたり、超狭指向性でかつ感度がよいマイクロホンを用いたりすることにより、音源位置推定の精度を上げている。
【０００４】
これに対して、例えば、持ち運びが容易な家電製品に利用されるようなものは、部材のサイズや値段に制限があるため、せいぜい通常の小型マイクロホンを１本あるいは２本程度しか使うことが許されない。
【０００５】
特許文献１には、家庭用ビデオカメラに組み込む音源探査装置の構成が開示されている。すなわち、この音源探査装置は、指向性が異なる２本のマイクロホンで、同時に目標音源から音声を収録し、この２本のマイクロホンから収録された同一音の周波数強度分布を比較することで、音源の方向を探知するものである。つまり、２本のマイクロホンの指向性が異なるため、音源の方向によって、２本のマイクの周波数強度分布に差が生じることを利用するものである。
【０００６】
特許文献２には、家庭用テレビゲーム機器に組み込む音源探査装置が開示されている。ユーザはテレビゲームを行う際に、コントローラを手に持つが、このコントローラに、音源を仕込む。そして、テレビ画面の左右にマイクロホンを設置し、このマイクに音源からの音声が到達する時間をそれぞれ計算し、音源すなわちコントローラ（ユーザ）の位置を探知するものである。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００９−２９６２１９号公報
【特許文献２】特開２０１０−０２１８５４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記特許文献１及び特許文献２に開示の構成では、いずれも音源の位置を探査するために、なお特殊な機器を用いている。すなわち、特許文献１のマイクロホンは、指向性が異なるマイクを２本利用しなければならない。また、特許文献２では、音源であるスピーカーが音源位置探査システムの必須の構成要素になっている。これらの構成は、マイクロホンアレイを用いるよりは、一般向けではあるものの、携帯電話などのモバイル端末等に音源探査装置を組み込む場合、過剰な品質となってしまったり、モバイル端末のコスト上昇につながったりしてしまい、音源探査装置を組み込んだモバイル端末を普及させるのは困難である。
【０００９】
本発明の目的は、モバイル端末を用いて音源位置の推定精度を向上させる音源位置探査システムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の音源位置探査システムは、マイクロホンと、前記マイクロホンによって収録された音声を音響指紋に変換する音響指紋変換手段と、現在地を示す位置情報を取得する位置取得手段と、前記マイクロホンの指向性を示す指向性情報、前記音響指紋、前記位置情報及び自装置を識別する識別子を組にした音声タグを送信する送信手段と、を有する無線通信端末装置と、複数の無線通信端末装置より送信された前記音声タグを識別子毎に時系列で記憶する音声タグ記憶手段と、異なる識別子間で前記音声タグの一部が一致又は近似しており、かつ、一定の時間内に収録された音響指紋を探索し、探索された音響指紋と同じ組の位置情報及び指向性情報を用いて、音源の位置を推定する音源位置計算手段と、を有するサーバ装置と、を具備する構成を採る。
【発明の効果】
【００１１】
本発明によれば、モバイル端末を用いて音源位置の推定精度を向上させることができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施の形態１に係る音源位置探査システムのシステム構成図
【図２】図１に示した音源位置探査システムが利用される様子を示した模式図
【図３】特徴量ベクトルを抽出する様子を示す模式図
【図４】指向性情報パターンを示す模式図
【図５】音声タグが登録された状態を示す模式図
【図６】図２に示した端末から送信されてきた音声タグが登録された状態を示す模式図
【図７】マップ上で指向性情報パターンを重ね合わせた結果を示す模式図
【図８】指向性情報パターンを２次元のビットマップとして示した模式図
【図９】図７に示した重ね合わせの結果をビットマップで表した模式図
【図１０】マイクロホンに指向性があった場合の指向性情報パターンを示す模式図
【図１１】４つの端末の指向性情報パターンを重ね合わせた結果を示す模式図
【図１２】２つの音声タグ列を示す模式図
【図１３】指向性情報パターンの減算を行って、音源位置を推定する様子を示す模式図
【図１４】指向性情報パターンを拡大し、音源位置を推定する様子を示す模式図
【図１５】時間的に離れた場合における指向性情報パターンを重ね合わせて、音源位置を推定する様子を示す模式図
【図１６】時間的に離れた端末が送付した音声タグ列を示す模式図
【図１７】本発明の実施の形態２に係る音源位置探査システムのシステム構成図
【図１８】図１７に示した音源位置探査システムが利用される様子を示した模式図
【図１９】マップに道路と車を重ね合わせた様子を示す模式図
【図２０】図１９に示した４つの端末から送信されてきた音声タグが登録された状態を示す模式図
【発明を実施するための形態】
【００１３】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。ただし、実施の形態において、同一機能を有する構成には、同一符号を付し、重複する説明は省略する。
【００１４】
（実施の形態１）
図１は、本発明の実施の形態１に係る音源位置探査システムのシステム構成図である。本発明のシステム構成には、２通りあり、ここでは、サーバクライアント型の構成を例に説明する。
【００１５】
図１において、１０００は、携帯情報端末であり、対象音を収録し、音響指紋に変換する機能、収録時の位置情報等を検知する機能等が実装されている。なお、本実施の形態においては、携帯情報端末を端末と呼称する。
【００１６】
１００１は、マイクロホンである。マイクロホンの指向性情報や音声収録の録音レベルは、メモリ１００３内に記録されており、それらの情報は随時読み出すことができる。
【００１７】
１００２は、音響指紋変換部であり、後述する方法でマイクロホン１００１が収録した音声を音響指紋に変換する。
【００１８】
１００４は、位置取得部であり、３次元空間の座標、または地面や床を平面とみたてた場合の平面上での端末１０００の現在地を示す２次元座標等を取得する。本発明の効果としては、そのどちらでも同等であるため、説明の便宜上、位置取得部１００４は地球上での２次元位置座標を取得できるものとする。つまり、緯度経度を取得するものである。
【００１９】
１００５は、マイク方向取得部であり、マイクロホン１００１の正面が向いている方向を取得する。ここでいう方向とは、位置取得部１００４に合わせて、地図上の方向（つまり、北を０°、東を９０°南を１８０°、西を２７０°とするもの）を示す。なお、これは二次元平面上の方向であるが、これに俯角（水平方向からの上下角度）を交えて３次元空間内の角度を加えてもよい。
【００２０】
１００６は、データ送信部であり、マイクロホン１００１、音響指紋変換部１００２、メモリ１００３、位置取得部１００４及びマイク方向取得部１００５からのデータをまとめて（まとめられたデータを音声タグと呼ぶ）、適切なフォーマットに変換し、音源位置サーバ１０１０に送付する。
【００２１】
１００７は、ネットワークＩ／Ｆ（ネットワークインタフェース）であり、データ送信部１００６等の端末１０００内のモジュールの依頼を受け、ネットワーク１０３０を介して外部機器とデータの送受信を行う。
【００２２】
１０１０は、音源位置サーバである。
【００２３】
１０１１は、データベース登録部（ＤＢ登録部）であり、端末１０００から音声タグという情報構造体を受け取り、音声タグデータベース（音声タグＤＢ）１０１２に保存する。音声タグＤＢ１０１２は、音声タグを記録及び検索可能なデータベースである。
【００２４】
１０１３は、音源位置計算部であり、音声タグＤＢ１０１２中の音声タグの情報を用いて、音源の位置の精度を高める計算を行う。
【００２５】
１０１４は、ネットワークＩ／Ｆ（ネットワークインタフェース）であり、ＤＢ登録部１０１１等の音源位置サーバ１０１０内のモジュールの依頼を受け、ネットワーク１０３０を介して外部機器とデータの送受信を行う。
【００２６】
１０１５は、マップであり、一種の白地図の集合である。新しく音源が見付かると、その音源用に新たに１枚の白地図が生成される。生成されたマップは、音源とリンクされて管理される。つまり、論理的には、全世界の地図が、ユニークな音源の数だけ存在し、相互に音源とリンクされている。なお、地図といっても、重ね合せの計算と結果の保持に使われるもので、そこに地形、道路やランドマーク等が書き込まれているわけではない。マップは位置（緯度、経度）が定義された平面であり、位置とそれに対する「その位置に音源が存在する尤もらしさを表現したポイント」が記録できるだけのものである。
【００２７】
１０３０は、ネットワークである。
【００２８】
図２は、図１に示した音源位置探査システムが利用される様子を示した模式図である。図１では、表現の便宜上、端末１０００が１つしかないように記載しているが、実際は端末１０００の他にも多数の端末（２０００、２００１、２００２）が存在し、これらの端末は、複数の無線ネットワークアクセスポイント（２０３０、２０３１）を介して、ネットワーク１０３０に接続されている。
【００２９】
これらの端末は、基本的な構成は端末１０００と同じであるが、それぞれの内部のモジュールの諸元値は異なっていてよい。例えば、マイクロホンの指向性や利得などの性能が異なっていてよい。
【００３０】
ここで、図１に示した音源位置探査システムの動作概要について図２を用いて説明する。図２に示すように、実世界においては、複数の多様な音源（２０２０、２０２１）が存在する。これらの音源の位置を、端末（１０００、２０００、２００１、２００２）を使って探査するが、端末には汎用の必ずしも性能の高くない（つまり安価）マイクロホンしか搭載されていないため、１つ１つの端末単独ではおおよそ自分の周囲に音源があるという程度しかわからない。そこで、複数の端末から、その端末単独でわかる音源の位置（精度が低い）に関する情報を、音源位置サーバ１０１０に集積し、これらの情報を統合することにより、音源の位置の精度を高めることが考えられる。
【００３１】
ただし、このような音源の情報を統合するためには、同じ音源のデータのみを用いる必要がある。図２の例では音源が２つあるが、例えば、音源２０２０に関しては端末１０００及び２０００起源の情報のみを使う必要がある。これには、端末１０００と２０００は同じ音源からの音を収録しており、２００１と２００２の収録している音（音源２０２１からの音）とは異なると判別できなくてはならない。この判別を行うために、収録した音を音響指紋に変換し、音響指紋が（ほぼ）一致するかどうかで、同一音の判定を行う。音響指紋とこの利用方法については後述する。
【００３２】
図２に示す状況において、各端末（１０００、２０００、２００１、２００２）が、音源（２０２０、２０２１）の音をそれぞれのマイクロホンで収録を開始する。まず、端末１０００を例にとって、音声タグが音源位置サーバ１０１０まで送付される処理手順について説明する。
【００３３】
端末１０００が、音源２０２０の音をマイクロホン１００１で収録すると、その音声を音響指紋変換部１００２が逐次音響指紋に変換する。音響指紋とは、音声からある一定の時区間の断片を取り出し、その断片から抽出した特徴量のベクトルである。図３は、これを簡単に示した模式図である。
【００３４】
図３（ａ）の３０００は、音声をスペクトログラム風に表示したものであるが、まず音声３０００から断片３００１を切り取る。これは、時間ｔ０〜ｔ１までの時区間の音声（幅はΔｔ）を切り取ったものである。この音声断片３００１（図３（ｂ））を、適当な特徴量抽出アルゴリズムを用いて図３（ｃ）に示すような特徴量ベクトルｖt0に変換する。ここで、ｆ0〜ｆnが個々の特徴量である。
【００３５】
特徴量抽出アルゴリズムは各種提案されており、これらのアルゴリズによれば、上記時区間の幅Δｔにしても、１秒程度から数分間に及ぶ場合などバラエティーがある。本実施の形態における音源は、楽曲と異なり、音声の開始するタイミングが定かではないため、Δｔの値は１秒程度が望ましい。また、音響指紋を作成するサイクル（周期）も、十から数十分の１秒程度が望ましい。また、特徴量にしてもいろいろな方法が考えられる。いずれの方法を使うにしろ、ロバスト性、つまり、「人間の耳に同じように聞こえる音声は、似た特徴量ベクトルに変換され、異なる音声断片は異なる特徴量ベクトルに変換される」という性質を有する必要がある。通常の音響指紋は、このような特徴を持つものが多い。
【００３６】
このような特徴量ベクトルの各要素ｆ0〜ｆnは、普通数値で現わされるが、特徴量ベクトルｖは、ｎ次元空間でのベクトルとなる。この場合、特徴量ベクトルの類似度をなんらかのベクトル間の距離と定義すれば、「同じ音声に対する特徴量ベクトルの距離は０、似ている音声では距離は小さく、似ていない音声ほど距離が遠くなる」ということとなる。
【００３７】
本発明においては、この特性を満たす特徴量抽出アルゴリズムであれば、いかなるアルゴリズムでも利用できる。具体例を挙げるならば、以下の論文に開示されている方法を用いれば、本発明に適した特徴量ベクトルを作ることができる。“Ｃｏｍｐｕｔｅｒ Ｖｉｓｉｏｎ ｆｏｒ Ｍｕｓｉｃ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ（２００５）”、ｂｙ Ｙａｎ Ｋｅ、 Ｄｅｒｅｋ Ｈｏｉｅｍ、 Ｒａｈｕｌ Ｓｕｋｔｈａｎｋａｒ、Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２００５ ＩＥＥＥ Ｃｏｍｐｕｔｅｒ Ｓｏｃｉｅｔｙ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｃｏｍｐｕｔｅｒ Ｖｉｓｉｏｎ ａｎｄ Ｐａｔｔｅｒｎ Ｒｅｃｏｇｎｉｔｉｏｎ （ＣＶＰＲ′０５） Ｖｏｌｕｍｅ １、Ｐａｇｅｓ：５９７−６０４、ＩＳＢＮ〜ＩＳＳＮ：１０６３−６９１９、０−７６９５−２３７２−２
【００３８】
さて、時区間ｔ０〜ｔ１に対する音響指紋ｖ（ｔ０）が作成されると、次の時区間に対する音響指紋ｖ（ｔ１）が作成される。なお、前掲した論文においてなされるように、時区間は重なる部分があってもよく、システム全体で一貫した方法で作成されればそれでよい。
【００３９】
なお、収録した音声のレベルがある一定以下の場合の扱いについて補っておく。通常の音響指紋作成方法では、小さい音や無音に対しても音響指紋を作成することができる。しかし、本発明の場合は音源位置の探査が目的であり、音が小さいあるいは無音の場合は、音源なしと考えて音響指紋を作る必要はない。この場合は、音響指紋なしを意味するような特別の音響指紋が作成されるとする。
【００４０】
このように、音声が収録されると実時間で次々と音響指紋が作成されていく。
【００４１】
音響指紋変換部１００２により作成された音響指紋は、データ送信部１００６に渡される。データ送信部１００６は、この音響指紋を作成した時の指向性情報とマイクロホン１００１の録音レベル（収録した音のレベルではなく、マイクロホンの録音利得である）をメモリ１００３から読み取る。同時に、データ送信部１００６は、端末１０００が存在する経度及び緯度を位置取得部１００４から取得し、さらに、マイクロホン１００１が向いている方向をマイク方向取得部１００５から取得する。
【００４２】
ここで、マイクロホンの指向性情報とは、マイクロホンの向きに対してどの程度感度よく音を拾えるかの情報である。つまり、方向によるマイクロホンの感度である。図４には、指向性情報を模式的に示してある。図４（ａ）は、無指向性つまりどの方向からの音でも同一に拾える場合で、４０００は端末を、４００１は指向性のパターンを示し、ある一定の音量の音源を置いた場合に、同じ音量でマイクが拾える場所を結んだものである。図４（ｂ）は、指向性がある場合の指向性情報である。４００２は端末を、４００３は指向性パターンを示し、マイクロホン前方では感度がよく、マイクロホンの後ろに回ると感度が落ちる様子を示している。
【００４３】
本発明の場合には、この指向性情報である閉曲線（４００１、４００３）を、音源が存在し得る位置の範囲と置き換えて利用する。この閉曲線を指向性情報パターンと呼ぶとする。実際の指向性情報パターンは、音源の周波数や音量により複雑な影響を受けるし、また、音源の音量も一定ではないため、厳密に言えばこの読み換えは成立しない場面も多い。しかしながら、本発明においては、個々のマイクロホンの精度に頼らずに、複数の大量のマイクロホンを利用することで全体として精度を上げることを考えるため、この読み換えでも十分であると言える。さらに、同様の理由で、それぞれの全ての端末が指向性情報持つ必要はない。この場合、代わりに普通の携帯電話やスマートホンで利用されるようなマイクロホンを想定して、平均的な指向性情報というものを考え、指向性情報を持たない端末にはそれを用いればよい。
【００４４】
また、それ程精密な指向性情報がいらないことから、端末（マイクロホン）の機種毎に指向性情報を用意するのではなく、典型的な指向性情報を用意し（例えば、無指向性で感度が低い、無指向性で感度が高い、狭指向性など）、その中から選ぶようにしてもよい。
【００４５】
さて、データ送信部１００６に、音響指紋（ｆｐ）、指向性情報（ｄｉｒ）、録音レベル（ｌｅｖ）、位置情報（ｐｏｓ）、マイク方向（ｏｒｉ）の情報が集まったとする。これらと端末の識別子（ｉｄ）や、収録時（ｔ）をまとめた組を「音声タグ」と呼ぶとする。つまり、音声タグＡＴａｇは、Ａｔａｇ＝（ｉｄ、ｆｐ、ｄｉｒ、ｌｅｖ、ｐｏｓ、ｏｒｉ、ｔ）という６つ組となる。ここで必須であるのは、ｉｄ、ｆｐ、ｄｉｒ、ｐｏｓ、ｔである。
【００４６】
マイク方向（ｏｒｉ）がない場合は、指向性情報（ｄｉｒ）は無視されて、無指向性マイクとしての指向性情報が代わりに使われる。また、オプションとして、上記６つ組に、マイクロホン１００１で収録した音声を加えてもよい。ただし、生の音声データは、これがあれば、後に各種用途に利用できるのだが、音響指紋等他のデータに比較して巨大であり、端末１０００の処理能力やネットワーク１０３０の帯域等に余裕がある場合にしか、加えることはできないだろう。
【００４７】
音声タグが作成されると、データ送信部１００６は、ネットワークＩ／Ｆ１００７からネットワーク１０３０を介して、その音声タグを音源位置サーバ１０１０に送付する。
【００４８】
この送付のタイミングについては、音声タグが１つできる度に送付してもよいし、ある程度の数が溜ったところで一括して送付してもよい。当然後者の方がネッワーク送付に関するオーバーヘッドが削減されて、全体としての効率は良くなるが、それとは逆に音声タグのリアルタイム性は失われる。これは、この音源位置探査システムが供される目的等により適当なタイミングを決めるとよい。
【００４９】
次に、音源位置サーバ１０１０の動作について説明する。
【００５０】
端末１０００を始めとして、各端末から音声タグが送付されてくると、ＤＢ登録部１０１１は、それを音声タグＤＢ１０１２に登録する。
【００５１】
図５は、ある１つの端末から送信されてきた音声タグが登録された状態を模式的に表したものである。５０００は、音声タグの列で、音声タグの収録時ｔの順に並べられている。その中から１つの音声タグを取りだしたものが５００１と５００２である。５００１はその音声タグの音響指紋、５００２は音声タグのうち音響指紋以外のその他の情報及び推定された位置情報（マップ１０１５内に保持されている）へのリンクが書きこまれている。これは、今後の説明で音響指紋は中心的な役割を果すために、便宜上、特に取り出して表現したものである。
【００５２】
なお、これは、あくまで論理的に、このように格納されているということであり、実際に実装された音声タグＤＢ１０１２のデータの物理的な配置がこのようになっているという意味ではない。
【００５３】
今、図６に示すように、３つの端末からの音声タグ列が音声タグＤＢ１０１２に登録されているとする。図６の６０００、６００１、６００２は、音声タグ列から音響指紋のみを表示して図示したものである。例えば、図６（ａ）は端末１０００の音響指紋を、（ｂ）は端末２０００の音響指紋を、（ｃ）は端末２００１の音響指紋をそれぞれ示す。図２に示したように、端末１０００と端末２０００は同一の音源２０２０の音声を収録しており、端末２００１は別音源２０２１を収録しているとする。
【００５４】
このような状態で音源位置計算部１０１３が位置の精密化を行う過程について説明する。音源位置計算部１０１３は、新規登録の音声タグが音声タグＤＢ１０１２に登録されると適当なタイミングで、その新規音声タグの音響指紋が登録済の音声タグの音響指紋に一致あるいは似た部分がないか音声タグＤＢ１０１２を検索する。つまり、新規音声タグの音響指紋からある一定の閾値以下の距離に既登録の音響指紋がないかを検索する。この検索は、新規登録時に即座に行ってもよいし、ある程度新規登録分が溜ってから一斉に行ってもよい。
【００５５】
同一音源からの音を収録していた場合は、ある一定の連続した音響指紋列が互いに似ている、あるいは一致していると判断されることになる。例えば、これが図６の６００３と６００４の部分であるとする。端末（識別子＝ｉ）の時間ｔにおける音響指紋をｖ（ｉ、ｔ）と表現すれば、６００３の音響指紋列は、端末識別子をｉとすると、次のように表される。
Ｄ１＝（ｖ（ｉ、ｔ０）、ｖ（ｉ、ｔ０＋１）、ｖ（ｉ、ｔ０＋２）、…、ｖ（ｉ、ｔ０＋ｎ−１））
【００５６】
また、６００４の音響指紋列は、端末識別子をｊとすると、次のように表される。
Ｄ２＝（ｖ（ｊ、ｔ１）、ｖ（ｊ、ｔ１＋１）、ｖ（ｊ、ｔ１＋２）、…、ｖ（ｊ、ｔ１＋ｎ−１））
【００５７】
Ｄ１、Ｄ２の式において、ｖ（ｉ、ｔ０＋ｍ）≒ｖ（ｊ、ｔ１＋ｍ）、ｍは０からｎ−１の整数、とういう関係が成り立つということである。音響指紋列がいくつ連続していれば良いかは、実装上の決定事項となる。また、連続が一瞬途切れた場合の扱いについては、適当な確率モデルを用いて判定することになる。例えば、前掲の論文“Ｃｏｍｐｕｔｅｒ Ｖｉｓｉｏｎ ｆｏｒ Ｍｕｓｉｃ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ（２００５）”では、録音音声と原音を比較する際に、一致するかしないかをベルヌーイ過程とモデル化して判定する方法が、“ｏｃｃｌｕｓｉｏｎ ｍｏｄｅｌ”という名称で提案されており、それを用いてもよい。あるいは、もっと単純に、ある適当な時間幅（数秒〜１０数秒など）で７割一致していれば、一致と判断してもよい。
【００５８】
また、時刻ｔ０とｔ１は、｜ｔ０−ｔ１｜≦ｔｈ（ｔｈは、数秒〜数分の値で、実装上のパラメータ）の関係にあればよく、一致している必要はない。これは、音声の収録時刻を記録するのが端末側として、端末の時計には当然ばらつきがあるからである。また、サーバ側の登録時間を収録時間と読みかえて、収録時間をサーバ側で付与したとしても、登録のための待ち時間や通信時間はデータ毎に異なるため、やはりばらつきが発生することになる。
【００５９】
このような音響指紋の一致列が見付かった場合には、音源位置計算部１０１３は、他の作業と平行して、位置の精密化の作業を開始する。
【００６０】
前述した通り、本発明では、マイクロホンの指向性に関する情報を、音源が存在しうる位置の範囲として読み換えることで、音源の位置推定を行う。そして、音源位置の精密化とは、同一の音源に由来すると思われる音声タグに記録されている指向性情報を重ね合わせることにより実現される。この重ね合わせは、マップ１０１５上で行われる。
【００６１】
図７は、このマップ１０１５上で指向性情報を重ね合わせた結果を模式的に現わしたものである。図７の背景にあるのがマップ１０１５であり、その上に端末１０００、２０００の実際の位置（音声タグ中の位置情報）に従い、端末１０００、２０００を配置する（図７における１０００、２０００の位置）。次に、それぞれの端末位置を中心にマイク方向に従い、回転を加えた指向性情報をマッピングする（７０００及び７００１）。図７の状況では、指向性情報を無指向性（指向性情報のパターンが円）と仮定しているので、マイク方向はあまり意味を持たない。そして、最終的に指向性情報のパターン７０００と７００１の重なり合う部分７００２に音源があると推定される。
【００６２】
つまり、端末１０００から見て、音源は７０００の中にあると推定され、かつ、端末２０００からみれば、７００１内にあると推定されるから、その結果、音源のより確からしい位置は、７０００と７００１の重ね合わせ部分である領域７００２内ということになる。
【００６３】
なお、この重ね合わせの計算の実装について補足をしておく。指向性情報のパターンである閉曲線同士の重ねあわせを正確に計算してしまうと、もともとの位置情報やマイク方向の誤差を考えればあきらかに過剰品質になる。そこで、計算を効率的に行うために、指向性情報のデータ構造や計算方法を簡略化してやる必要がある。その一例として、マップ１０１５を連続した位置がとれる平面ではなく、離散的な位置しかとれないとすることで、計算量を減らす方法が考えられる。つまり、マップ１０１５の位置に関しては、位置取得部１００４の位置精度を大きく超えて実装しても意味がないから、例えば、東西方向及び南北方向に対して１メートル単位での位置しかとれないよう位置の量子化を行う（１メートルではなく、緯度経度で０．１秒単位なども考えられる）。この結果、指向性情報は閉曲線で囲まれた領域ではなく、２次元のビットマップとして表現できる。これを模式的に表現したのが図８である。
【００６４】
図８では、原点部分に端末（マイクロホン）があり、ｙ軸正方向がマイクロホン正面である。各ビットは、１メートル四方の地面に相当し、ビット毎に音源の存在ポイントというべき整数値が保持される。１が指向性パターン８０００の内側つまり、音源が存在する可能性がある場所を表わし、外側は０である（図８では、０は省略してある）。
【００６５】
マップ１０１５も同様に表現できる。例えば、図７の重ね合わせの結果を、ビットマップで表すと図９のようになる。７０００と７００１の重なった部分は、それぞれのビットマップの各ビットの数を足し合わせたものとなる。この場合は、１＋１で２となる（図９の７００２の部分）。つまり、指向性情報パターン７０００、７００１の外部は、音源の存在するポイントが０で、１の部分は０の部分より存在する尤もらしさがあがり、領域７００２の部分はポイント２で、このマップ１０１５中で音源が存在する尤もらしさが一番高い部分となる。
【００６６】
以上の計算は、地図上での指向性情報の重ね合わせが２つだけの場合であるが、これが３以上になっても同様の計算を行えばよい。これを図６の場合で説明する。前述したように、図６の６００３の音響指紋列は、端末識別子をｉとすると、次のように表された。
Ｄ１＝（ｖ（ｉ、ｔ０）、ｖ（ｉ、ｔ０＋１）、ｖ（ｉ、ｔ０＋２）、…、ｖ（ｉ、ｔ０＋ｎ−１））
【００６７】
また、６００４の音響指紋列は、端末識別子をｊとすると、次のように表された。
Ｄ２＝（ｖ（ｊ、ｔ１）、ｖ（ｊ、ｔ１＋１）、ｖ（ｊ、ｔ１＋２）、…、ｖ（ｊ、ｔ１＋ｎ−１））
【００６８】
Ｄ１、Ｄ２の式において、ｖ（ｉ、ｔ０＋ｍ）≒ｖ（ｊ、ｔ１＋ｍ）、ｍは０からｎ−１の整数、とういう関係が成り立った。ここでさらに、ｖ（ｋ、ｔ）に対応する音声タグをａｔａｇ（ｋ、ｔ）として、その音声タグの指向性情報をａｔａｇ（ｋ、ｔ）［ｄｉｒ］、マイク方向をａｔａｇ（ｋ、ｔ）［ｏｒｉ］、位置情報をａｔａｇ（ｋ、ｔ）［ｐｏｓ］と表記することにする。
【００６９】
この場合、指向性情報の重ね合わせとは、ａｔａｇ（ｉ、ｔ０＋ｍ）［ｄｉｒ］及びａｔａｇ（ｊ、ｔ１＋ｍ）［ｄｉｒ］の指向性情報を、マイク方向と位置情報を勘案して、ｍにつき０からｎ−１まで、マップ１０１５上で各ビット毎に加算していってやればよい。すなわち、以下の計算を行うということである。
【００７０】
ａｔａｇ（ｋ、ｔ）について、ｋは、｛ｉ、ｊ｝と変化させ、ｔは、ｋ＝ｉの時は、ｔ０〜ｔ０＋ｎ−１、ｋ＝ｊの時はｔ１〜ｔ１＋ｎ−１と変化させて、全てのｋ、ｔの組み合わせに対して、次の（１）から（２）を計算する。
【００７１】
（１）ａｔａｇ（ｋ、ｔ）［ｄｉｒ］をａｔａｇ（ｋ、ｔ）［ｏｒｉ］だけ回転させる。この結果をＴとする。
【００７２】
（２）Ｔ上の位置（ｘ、ｙ）のビットに書き込まれた値をＴ（ｘ、ｙ）とし、マップ１０１５上の位置（ｎｏｒｔｈ、ｅａｓｔ）のビットをＭＡＰ（ｎｏｒｔｈ、ｅａｓｔ）とし、位置情報ａｔａｇ（ａｔａｇ（ｋ、ｔ）［ｐｏｓ］） ＝（Ｎ、Ｅ）とすれば、指向性情報が取り得る範囲でｘ、ｙを変化させて、以下を計算する。
【００７３】
ＭＡＰ（Ｎ＋ｘ、Ｅ＋ｙ）＋＝Ｔ（ｘ、ｙ）（ただし、＋＝は、足し込みの演算子）
そして、その重ね合わせの結果、音源の存在する尤もらしさが一番高い数値の地点（例えば、図９の７００２）が、この音声タグ列に対して推定された音源の位置となる。
【００７４】
次に、端末１０００及び２０００のマイクロホンに指向性があった場合の例を、図１０を使って説明する。基本的には、無指向性の場合と同じであり、最終的には図１０に示したようになる。
【００７５】
マップ１０１５上に位置情報の通り端末を配する（図１０の１０００、２０００）。その端末を中心に、その端末のマイク方向分回転させた指向性情報パターンを重ねる。端末１０００に関してのマイク方向が１０００２、端末２０００のマイク方向は、１０００３である。なお、回転の演算の実装であるが、自由な角度の回転を許すと演算量が増え、全体の効率が落ちることから、回転の角度に関しても、例えば３０°単位での離散的な値しか取れないとし、マイク方向の値を適当にまるめれば良い。さらには、予め３０°毎に回転させた指向性情報を計算しておき、マイク方向の回転の演算をする場合は、その事前に計算された結果を呼び出すだけにすれば、一層の演算速度の向上が期待できる。図１０の場合の最終的な音源の推定位置は、１０００４でハッチングをかけた部分となる。
【００７６】
次に、複数端末の指向性情報を重ね合わせた場合について説明する。図１１は、端末１１０００から１１００３の４つの端末で収録した音声に、似た音響指紋列が観測された場合の重ね合わせ結果である。ここで、似た音響指紋列が観測された端末が複数になると、重ね合わせの箇所も複数になる。例えば、図１１では、１１０１０や１１０１１等いくつかの部分で複数の指向性情報の重ねあわせが発生している。
【００７７】
この中で、音源がある位置として推定されるのは、マップ１０１５の各ビットの中で、ビットの音源の存在する尤もらしさのポイントが最も高い部分が音源の位置と推定される。図１１では、領域１１０１０中のビット数値は、３つの指向性情報のパターンが重なっているので３である。それに対して、領域１１０１１では２であるから、領域１１０１０の部分の方が音源位置としてより好ましいということとなる。
【００７８】
以上が、基本的な音源の位置推定方法である。次に、さらに音源の位置推定を正確にするための工夫、拡張を４種説明する。まず、最初の手法について説明する。今までは、指向性情報の重ね合わせをすることで、音源位置推定の精度を上げられることを示したが、指向性情報の減算をすることでも推定精度を向上させることができる。
【００７９】
今、図１２に示したような音声タグ列（ａ）、（ｂ）があるとする。音声タグ列の表現方法は、図５で使ったものと同じで、音声タグ列の上部が、音響指紋の列で、下が音響指紋以外の情報の列である。ここの説明では、位置情報しか言及しないため、位置情報の列と考えてもらってよい。また、図１２の音声タグ列（ａ）を生成した端末を１３０００（図１３）とし、図１２の音声タグ列（ｂ）を生成した端末を１３００１（図１３）とする。
【００８０】
ここで、ある音源に対する音響指紋列１２０００と、その他の情報の列１２００１がある場合に、その他の情報の列１２００１中の位置情報から距離的及び時間的に近接した距離であるにも関わらず、音響指紋列１２０００に似た列が存在しない部分があるかを、音声タグ列（ｂ）の音響指紋列から検索する。ここで、そのような部分があった場合には、減算によって音源位置を推定することができる。
【００８１】
例えば、図１２の音声タグ列（ｂ）の中で、時間ｔ０に近く、その他の情報の列１２００１に近接した位置情報をもった部分がないかを探す。この結果、１２００１と１２００２の部分の位置情報が近いにもかかわらず、音響指紋列１２０００に似た列が音声タグ列（ｂ）に存在しなかったとする。この場合、図１２の音声タグ列（ａ）に対応した端末の指向性情報から、図１２の音声タグ列（ｂ）に対応する端末の指向性情報を減算することができる。つまり、音響指紋列１２０００に対応する音源をＸとすれば、Ｘの位置は、１２００１部分に記録されている端末１３０００の位置の近く（すなわち、指向性情報パターン１３０１０内）ということになる。そして、その音源Ｘが音を発していた時刻ｔ０において、端末１３００１は、端末１３０００の付近にあったにもかかわらず音源Ｘの音を収録していない。これは、音源Ｘは、端末１３００１の指向性情報のパターン１３０１１外にある可能性が高いということである。両者の状況を勘案すれば、音源は、領域１３０１２内にあると推定される。この領域１３０１２とは、指向性情報のパターン１３０１０から、１３０１１を引いたものであり、それゆえに、減算による音源位置の推定と呼ぶ。
【００８２】
次に、２番目の手法について説明する。これは、重ね合わせができる状況にあるにも関わらず重ね合わされた指向性情報のパターンがない場合に利用する。図１４にこの２番目の手法を適用した結果を示す。端末は１４０００〜１４００３まで４台あるとし、これら４台が比較的近い距離内で、ほぼ同じ時刻に、同一音源の音と思われる音響指紋列を記録していたとする。この場合、指向性領域（１４０１０〜１４０１３）を重ね合わせることができるはずだが、図１４に示す通り１４０１０〜１４０１３には重ね合わせる領域がない。この場合、音が非常に大きかったため、通常では聞こえないはずの指向性情報のパターン外の音まで拾ったと解釈するのが妥当と思われる。そこで、指向性情報パターンを通常の領域の数倍拡大し、再度重ね合わせを試みる。なお、何倍にするかは、実装上の調整パラメータとなる。ここでは、例えば５倍に拡大し（１４０２０〜１４０２３）、再度重ね合わせを行うと、音源位置の推定領域１４０３０が得られる。
【００８３】
なお、音声タグにもし録音レベルが記録されていれば、単純に一定倍するのではなく、録音レベルに応じて倍数を決めてもよい。例えば、録音レベルが低い場合は、指向性情報パターンを大きく広げるのがよく（つまり、録音レベルを下げているにもかかわらず音声が収録できたのは、非常に大きな音だったと考えられる）、録音レベルが高い場合は、指向性情報パターンを縮小させるのがよい。
【００８４】
次に、３番目の手法について説明する。これは、時間的には離れているが、距離的には近接している位置で、複数の端末（単一でもよい）が、同一の音源由来と思われる音声を収録した場合である。例えば、学校等で毎日夕刻になると下校のために同じ曲を流している、あるいは、視覚障碍者用の信号機の音楽など、繰り返し同じ場所で流される音声を異なる時間に収録した場合が考えられる。よって、同一の音源と考えてよいので、指向性情報を重ね合わせることができる。
【００８５】
これを図１５、図１６を参照しながら説明する。まず、時刻ｔ１で、端末１５０００が、地点（ｎ１、ｅ１）において、音源Ｘ由来と思われる音声を観測したとする（図１５（ａ））。１５０１０は、この場合の指向性情報のパターンである。次に、ｔに近接していない時刻ｔ２において、端末１５００１が、地点（ｎ２、ｅ２）において、音源Ｘ由来と思われる音声を観測したとする（図１５（ｂ））。
【００８６】
図１６（ａ）、（ｂ）は、この状況での端末１５０００、１５００１が送付した音声タグ列である。図１６（ａ）（１６０００）は、端末１５０００が送付したもので、図１６（ｂ）（１６００１）は、端末１５００１が送付したものである。音声タグ列の表記は、図５で説明したのと同様に、音声タグ列上段が音響指紋列であり、下段がその他の情報（ここでは、位置情報）である。図１６（ａ）の音響指紋列１６０１０と、図１６（ｂ）の音響指紋列１６００１とは音源Ｘ由来であるが、時間ｔ１、ｔ２は、ほぼ同時刻とは言えないほど離れているため、通常は指向性情報の重ね合わせは起こらない。
【００８７】
しかしながら、位置情報１６０１１と１６０２１の距離を計算して十分近接していた（例えば、２位置間の距離がある閾値以下の場合）ならば、前述したような状況が考えられるため、重ね合わせを行うべきである。重ね合わせがなされた状況を、図１５（ｃ）に示す。この結果、図１５（ｃ）の１５０２０のような、音源位置の推定領域を得ることができる。
【００８８】
なお、この場合、端末１５０００と１５００１は、同じ端末でもよい。これは、図１６の（ｃ）のような状況である。この場合、ある１つの端末の音響タグ列１６００２において、時刻ｔ１とｔ２で同じ音源に由来すると思われる音響指紋１６０３０、１６０４０が得られており、位置１６０３１と１６０４１が十分近接していればよい。
【００８９】
さらに、この方法を応用して、プリセットされた音源を用意することもできる。これは、音声タグＤＢ１０１２中に、音のランドマークとして機能するであろう音源を音声タグ列に変換して記録しておく。音のランドマークとは、例えば、前掲した学校等で夕刻にかかる曲や、信号機の音、その他、駅の階段を示す鳥の声などである。ただし、実際に収録した音ではないから、この音声タグに含まれる位置情報や指向性情報は、不定を示す特別な値を入れておく。
【００９０】
一方、これらプリセットされた音源と同じ音源を収録した端末がある場合、その端末が生成した音声タグ列の音響指紋列には、必ずプリセットされた音声タグ列の音響指紋列と一致する部分がある。そして、この後、音源位置推定が行われ、当初は音源位置が不明であったプリセット音源の位置がある程度推定される。そして、これを収録した端末が増えれば、音源の位置がより正確になっていく。
【００９１】
前記の信号機の音であれば、同じ音声を発する信号機が１００台あるとすれば、その信号機の音源に対応するマップ１０１５は、音源位置の存在するポイントのピークが１００観測されるように変化していくことになる（音源位置が大きくかわる毎に、新規のマップを生成するという方法も考えられる）。
【００９２】
最後に、４番目の方法について説明する。これは、位置を明かにしたい音源がある場合に、端末に要請して、音声を収録させる方法である。具体的には、位置をより明かにしたい音源がある場合に、他端末あるいは音源位置サーバから、その位置に一番近い端末に命じて（端末を通じてユーザに命じて）、その音源の付近へ移動させることで、積極的に音源位置を明確にする方法である。
【００９３】
このように実施の形態１によれば、マイクロホン間の相対位置や向きが任意に変化し得る状況において、複数の端末から得られた音響指紋列を用いて、音響指紋による音声のマッチングを行うことにより、特殊なマイクロホンを使うことなく、音源位置の推定精度を向上させることができる。
【００９４】
（実施の形態２）
実施の形態１では、システム構成をサーバクライアント型とする場合に付いて説明したが、本発明の実施の形態２では、システム構成をＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）型のサーバなしとする場合について説明する。
【００９５】
図１７は、本発明の実施の形態２に係る音源位置探査システムのシステム構成図である。図１７において、１７０００は、端末である。
【００９６】
１７００１は、データ送信部であり、マイクロホン１００１、音響指紋変換部１００２、メモリ１００３、位置取得部１００４及びマイク方向取得部１００５からのデータをまとめて（まとめられたデータを音声タグと呼ぶ）、適切なフォーマットに変換し、Ｐ２Ｐネットワーク１７０１０を介して接続されている近隣の端末に対して、音声タグを送付する。
【００９７】
１７００２〜１７００５は、同名のモジュールが実施の形態１にも登場している。実施の形態１では、システム全体に対して（論理的には）１つだけのＤＢ登録部、音声タグＤＢ、マップ、音源位置計算部が存在した。つまり、これらの機能は音源位置サーバ１０１１にしかなかった。これに対して、実施の形態２のＰ２Ｐ型構成では、端末全てにこれらの機能が備わっている。ただし、実施の形態１での音源位置サーバ１０１０は、広い地域に存在する多数の端末からのデータを処理しなければならないため、巨大なデータベースや強力な処理能力が必要であったが、本実施の形態のＤＢ登録部１７００２、音声タグＤＢ１７００３、マップ１７００４、音源位置計算部１７００５は、自端末の近隣の端末しか相手にしないため、サーバクライアント型の構成に比較して、これらのモジュールは小規模コンパクトに実装することができる。
【００９８】
ＤＢ登録部１７００２も、ＤＢ登録部１０１１と機能は同一である。その他、音声タグＤＢ１７００３、マップ１７００４、音源位置計算部１７００５に関しても、実施の形態１の同名のモジュールと機能は同一であるが、ただし、実装段階では小規模、つまりメモリ量等を大幅に削減してよい。
【００９９】
１７００６は、ＤＢマップ同期部であるが、これはＰ２Ｐ構成にするために必要になったモジュールである。一般に端末は、メモリ等の記憶容量に恵まれているわけではないため、音声タグ列やマップを、全世界の全端末分、長期間保持するわけにはいかない。またＰ２Ｐ通信の特性として、そもそも全ての端末からの音声タグを受信できるわけではない。
【０１００】
このため、近隣の端末から各種機能を実行するために必要なデータを受け取り、また、必要なくなったデータを削除する仕組みが必要である。ＤＢマップ同期部１７００６は、この作業を行うためのモジュールである。
【０１０１】
ＤＢマップ同期部１７００６は、自端末１７０００の位置（位置取得部１００４から取得）を常に把握するとともに、通信可能な他端末が、自端末１７０００の近隣の範囲内に存在する音源に関するマップをもっていれば、その複製を転送して自分のマップとして管理するようにする。この管理範囲を「マップ管理範囲」と呼ぶ。
【０１０２】
逆に、自分が持つマップ１７００４中に、マップ管理範囲から逸脱した音源に対するマップがあれば、それを削除する。マップ管理範囲は、自端末を中心にした一定の半径の円（または球）か、あるいは計算を簡便にするために、矩形（直方体）等であってもよい。また、他端末からマップの転送要求を受けた場合、ＤＢマップ同期部１７００６は、要求されたマップを渡す。
【０１０３】
マップと同様に、音声タグ列に関しても他端末とデータを交換する必要がある。いま、通信可能な他端末の音声タグＤＢ内にある音声タグ列中おいて、以下の条件を満す音声タグ列があれば、その音声タグ列の複製を音声タグＤＢ１７００３内にコピーする。
【０１０４】
条件：音声タグ列のうち、現在から一定の過去の範囲内の音声タグのうち少なくとも１つ以上の音声タグの位置情報が、自端末１７０００の近隣内であること。
【０１０５】
この「一定の」というのは、実装上のパラメータである。また「少なくとも１つ」というのも、実装時にある程度は増やしてもかまわない。つまり、一定の時間内の過去において、自端末１７０００の現在地から一定の範囲内に一度でも存在した端末であれば（ただし、現在通信可能な端末内で）、その端末が生成したタグ列を自分の音声タグＤＢ１７００３内に複製する。この「一定の時間内の過去」かつ「自端末の現在地からの一定の範囲内」を「音声タグ管理範囲」と呼ぶ。なお、他端末から音声タグをコピーする場合、列全てを複製せずに、その「一定の時間内の過去」分だけの複製でもよい。
【０１０６】
また、当然、音声タグＤＢ１７００３内のある音声タグ列において、音声タグ管理範囲内に入っている音声タグが１つもなくなってしまった場合、その音声タグ列は削除してよい（音声タグＤＢ１７００３の容量が十分大きければ、しばらくは削除しなくてもよい）。
【０１０７】
なお、このマップ管理範囲と音声タグ管理範囲においては、通信可能な端末を問題にしているが、うまくＰ２Ｐネットワークが構築されれば通信可能な端末とは事実上全端末を指すことになる。これではデータ交換を行う範囲が広すぎ、ネットワークに負荷をかけすぎる可能性があるため、実際の実装上では、ホップ数の制限等を加える必要がある。
【０１０８】
１７００７は、ネットワークＩ／Ｆであり、Ｐ２Ｐネットワーク１７０１０を利用して近隣の端末と通信を行う。
【０１０９】
１７０２０は、他の端末であり、基本的には端末１７０００と同等のものである。すなわち、他端末１７０２０は、端末１７０００に対して実施の形態１における音源位置サーバと同様の機能を果たすことになり、音源位置サーバ装置と捉えることができる。
【０１１０】
図１８は、図１７に示した音源位置探査システムが利用される様子を示した模式図である。１８０００〜１８００３は端末、１８０３０と１８０３１が音源、１８０２０〜１８０２２がルーティング経路である。
【０１１１】
１８０００〜１８００２の端末（端末群１８０４０）は、お互いにマップ管理範囲及び音声タグ管理範囲内にあるデータを持っているとする。すると、端末群１８０４０内では、マップ管理範囲内及び音声タグ管理範囲内にあるデータは時間とともに共有化されていくことになる。
【０１１２】
一方、端末１８００３が持っているデータは、マップ管理範囲内及び音声タグ管理範囲内にないのだから、共有されることはない。また、端末１８００３が、自分が生成した音声タグ（Ｙとする）を、経路１８０２２を介して端末１８００２に送信したとしても、それがさらに端末１８００１に転送されることもない。これは、Ｙは、長さ１の音声タグ列として、端末１８００２内の音声タグＤＢに登録されるが、直後にＹは、ＤＢマップ同期部１７００６により削除されてしまうからである。なお、一旦登録した直後に削除するのは、効率が悪いため、最初からＹの受け取り拒否をするようにしてもよい。
【０１１３】
このように、近い距離にある端末同士（ある端末が音声タグを生成して他端末に送っても、それが削除されないような距離）の中では、おおむね位置計測部１７００５が位置を精密化するのに必要なデータが揃う。すなわち、実施の形態１で説明したような動作と同様な音源位置の推定動作がなされることになる。
【０１１４】
以上のように、サーバクライアント構成（実施の形態１）と比較して、Ｐ２Ｐ構成でも同様な音源位置の推定が可能である。さらにＰ２Ｐ構成ではサーバクライアント構成に比較した利点もある。サーバクライアント方式では、サーバ側に音声タグ列をすべて集めて、その上で位置情報の精密化を行う。サーバ側では多数のデータを処理しなければならず、あるクライアント（端末）が、他クライアント由来の位置情報を利用できるようになるまでには、多少時間がかかることになる。
【０１１５】
それに対して、Ｐ２Ｐ側では、ある端末の近隣の端末が生成した音声タグが、ほぼリアルタイムに自分の音声タグＤＢ内に複製されることになるため、他端末で収録した音声を、自分で収録した音声と時間的な差違がほとんどなく利用することができる。
【０１１６】
ここで、図１９、図２０を使って、この利点に関して具体的に説明をする。図１９は、マップ１７００４に、道路と車を重ね合わせて図示した模式図である。１９０００、１９００１は道路であり、１９００１は１９０００にＴ字路として交わっている。１９０２０、１９０３０、１９０４０、１７０００は、端末であり、これら端末を持っているユーザ４人は、それぞれ道の路側帯に立っていることになる。なお、１７０００は、図１７の端末と同じものであり、この説明の中では自端末と呼称する場合もある。他の１９０２０、１９０３０、１９０４０も、基本的な端末内の構成は、１７０００と同じである。
【０１１７】
このような状況で、１台の車Ｃが図面上から下方向に道路上を走っており、時刻ｔ０、ｔ１、ｔ２における車Ｃの位置を示している。ただし、ｔ０＜ｔ１＜ｔ２である。
【０１１８】
１９０２１、１９０３１、１９０４１、１９０５１は、指向性情報のパターンを、それぞれの端末の位置に応じてマップ１７００４上に重ねて表示したものである。
【０１１９】
なお、４台の全ての端末は、お互いにマップ管理範囲と音声タグ管理範囲にあり、また通信可能であるとする。このため、ある端末で作成された音声タグは、リアルタイムで他の端末の音声タグＤＢ内にもコピーされる。
【０１２０】
時刻ｔ２以降の時点ｎｏｗにおける端末１７０００の音声タグＤＢ１７００３内を模式的に図２０に示す。音声タグＤＢ１７００３内には、端末１７０００が自分で作成した音声タグ列２００３０の他に、端末１９０２０が作成した音声タグ列２００００、端末１９０３０が作成した音声タグ列２００１０、端末１９０４０が作成した音声タグ列２００２０の複製が存在している。つまり、他端末で音声タグが生成されると、瞬時に端末１７０００にも転送され、既にある音声タグ列の末尾（つまり現時点）に追加される。
【０１２１】
ここで、音響指紋変換部１００２は、車Ｃが走行時に発する音声に対して、同一の音声タグ指紋列を生成することができるとする。この場合に、音声タグＤＢ内１７００３内の音声タグ列１９０２０、１９０３０、１９０４０には、同一の音響指紋列が存在することになる。つまり、図２０おいて、２０００１、２００１１、２００２１の部分である。
【０１２２】
これら、音響指紋列に対する位置は、２０００２、２００１２、２００２２中に存在する各端末の位置とマイクの方向（ただし、ここでは説明の便宜上、無指向性とするので、マイクの方向は意味をもたない）、指向性情報から図１９の１９０２１、１９０３１、１９０４１の円内となる。つまり、端末１７０００の場所からは、車Ｃの音を直接聞くことはできないが（指向性情報パターン１９０５１の外にあるので）、音源が自端末１７０００方向に向って、上から下（例えば、北から南）に近づいてくることがわかる。
【０１２３】
もし、今音源に対する音響指紋列２０００１等からこの音響指紋列が車のエンジン音やサイレン等であることが分かれば、おおよそ自端末１７０００の方向に向っているものが、車であることまで分かることになる。さらに、道路１９０００があるなどの地理情報も利用できれば、この車が、道路１９０００上にあることまで推論できるだろう。この場合は、端末１７０００のユーザに対して、「この道１９００１から道路１９０００に出ると、ちょうど車Ｃが接近しており、危ない」などの警告を出すことも可能であろう。この警告機能は、ユーザが例えばヘッドホンを用いて音楽を聞いており、周囲の音をよく聞き取れない状況であるとか、聴覚障碍者にとっても有用であると思われる。
【０１２４】
このように実施の形態２によれば、端末を用いたＰ２Ｐ型の音源位置探査システムを構築し、端末毎に取得した音響指紋列をＰ２Ｐネットワークを介して複数の端末間で互いに共有して、音響指紋による音声のマッチングを行うことにより、音源位置の推定精度を向上させることができる。
【産業上の利用可能性】
【０１２５】
本発明にかかる音源位置探査システムは、モバイル端末を用いて音源位置の推定精度を向上させるものとして有用である。
【符号の説明】
【０１２６】
１０００ 携帯情報端末
１００１ マイクロホン
１００２ 音響指紋変換部
１００３ メモリ
１００４ 位置取得部
１００５ マイク方向取得部
１００６ データ送信部
１００７ ネットワークインタフェース
１０１０ 音源位置サーバ
１０１１ ＤＢ登録部
１０１２ 音声タグＤＢ
１０１３ 音源位置計算部
１０１４ ネットワークインタフェース
１０３０ ネットワーク
２０００、２００１、２００２ 携帯情報端末
２０２０、２０２１ 音源
２０３０、２０３１ 無線ネットワークアクセスポイント
４０００、４００２ 携帯情報端末
１１０００、１１００１、１１００２、１１００３ 携帯情報端末
１３０００、１３００１ 携帯情報端末
１４０００、１４００１、１４００２、１４００３ 携帯情報端末
１５０００、１５００１ 携帯情報端末
１７０００ 携帯情報端末
１７００１ データ送信部
１７００２ ＤＢ登録部
１７００３ 音声タグＤＢ
１７００４ マップ
１７００５ 音源位置計算部
１７００７ ネットワークインタフェース
１７０１０ ピアツーピアネットワーク
１７０２０ 他の携帯情報端末
１８０００、１８００１、１８００２、１８００３ 携帯情報端末
１８０３０、１８０３１ 音源
１９０２０、１９０３０、１９０４０ 携帯情報端末
【技術分野】
【０００１】
本発明は、音源の位置を探査する音源位置探査システムに関する。
【背景技術】
【０００２】
音源探査技術は、例えば、騒音源を探知することで騒音減少に役立てたり、位置が異なる複数の音源を分離するための前処理として行われたり、あるいは、音源の位置を測定することにより、位置をトリガーとするなんらかのサービスを行ったり、様々な目的に利用される。
【０００３】
目的が様々であるために、音源探査を行う装置にも様々な形のものがある。例えば、騒音の測定機器に利用されるようなものは、機器を大量に安価に生産したり、携帯性に優れたものにする必要性が低く、逆に、精度に対する要求が強いために、機器は大型化したり特殊化したりする傾向にある。具体的には、多数のマイクロホンをアレー状に並べたマイクロホンアレイを用いたり、超狭指向性でかつ感度がよいマイクロホンを用いたりすることにより、音源位置推定の精度を上げている。
【０００４】
これに対して、例えば、持ち運びが容易な家電製品に利用されるようなものは、部材のサイズや値段に制限があるため、せいぜい通常の小型マイクロホンを１本あるいは２本程度しか使うことが許されない。
【０００５】
特許文献１には、家庭用ビデオカメラに組み込む音源探査装置の構成が開示されている。すなわち、この音源探査装置は、指向性が異なる２本のマイクロホンで、同時に目標音源から音声を収録し、この２本のマイクロホンから収録された同一音の周波数強度分布を比較することで、音源の方向を探知するものである。つまり、２本のマイクロホンの指向性が異なるため、音源の方向によって、２本のマイクの周波数強度分布に差が生じることを利用するものである。
【０００６】
特許文献２には、家庭用テレビゲーム機器に組み込む音源探査装置が開示されている。ユーザはテレビゲームを行う際に、コントローラを手に持つが、このコントローラに、音源を仕込む。そして、テレビ画面の左右にマイクロホンを設置し、このマイクに音源からの音声が到達する時間をそれぞれ計算し、音源すなわちコントローラ（ユーザ）の位置を探知するものである。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００９−２９６２１９号公報
【特許文献２】特開２０１０−０２１８５４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記特許文献１及び特許文献２に開示の構成では、いずれも音源の位置を探査するために、なお特殊な機器を用いている。すなわち、特許文献１のマイクロホンは、指向性が異なるマイクを２本利用しなければならない。また、特許文献２では、音源であるスピーカーが音源位置探査システムの必須の構成要素になっている。これらの構成は、マイクロホンアレイを用いるよりは、一般向けではあるものの、携帯電話などのモバイル端末等に音源探査装置を組み込む場合、過剰な品質となってしまったり、モバイル端末のコスト上昇につながったりしてしまい、音源探査装置を組み込んだモバイル端末を普及させるのは困難である。
【０００９】
本発明の目的は、モバイル端末を用いて音源位置の推定精度を向上させる音源位置探査システムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の音源位置探査システムは、マイクロホンと、前記マイクロホンによって収録された音声を音響指紋に変換する音響指紋変換手段と、現在地を示す位置情報を取得する位置取得手段と、前記マイクロホンの指向性を示す指向性情報、前記音響指紋、前記位置情報及び自装置を識別する識別子を組にした音声タグを送信する送信手段と、を有する無線通信端末装置と、複数の無線通信端末装置より送信された前記音声タグを識別子毎に時系列で記憶する音声タグ記憶手段と、異なる識別子間で前記音声タグの一部が一致又は近似しており、かつ、一定の時間内に収録された音響指紋を探索し、探索された音響指紋と同じ組の位置情報及び指向性情報を用いて、音源の位置を推定する音源位置計算手段と、を有するサーバ装置と、を具備する構成を採る。
【発明の効果】
【００１１】
本発明によれば、モバイル端末を用いて音源位置の推定精度を向上させることができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施の形態１に係る音源位置探査システムのシステム構成図
【図２】図１に示した音源位置探査システムが利用される様子を示した模式図
【図３】特徴量ベクトルを抽出する様子を示す模式図
【図４】指向性情報パターンを示す模式図
【図５】音声タグが登録された状態を示す模式図
【図６】図２に示した端末から送信されてきた音声タグが登録された状態を示す模式図
【図７】マップ上で指向性情報パターンを重ね合わせた結果を示す模式図
【図８】指向性情報パターンを２次元のビットマップとして示した模式図
【図９】図７に示した重ね合わせの結果をビットマップで表した模式図
【図１０】マイクロホンに指向性があった場合の指向性情報パターンを示す模式図
【図１１】４つの端末の指向性情報パターンを重ね合わせた結果を示す模式図
【図１２】２つの音声タグ列を示す模式図
【図１３】指向性情報パターンの減算を行って、音源位置を推定する様子を示す模式図
【図１４】指向性情報パターンを拡大し、音源位置を推定する様子を示す模式図
【図１５】時間的に離れた場合における指向性情報パターンを重ね合わせて、音源位置を推定する様子を示す模式図
【図１６】時間的に離れた端末が送付した音声タグ列を示す模式図
【図１７】本発明の実施の形態２に係る音源位置探査システムのシステム構成図
【図１８】図１７に示した音源位置探査システムが利用される様子を示した模式図
【図１９】マップに道路と車を重ね合わせた様子を示す模式図
【図２０】図１９に示した４つの端末から送信されてきた音声タグが登録された状態を示す模式図
【発明を実施するための形態】
【００１３】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。ただし、実施の形態において、同一機能を有する構成には、同一符号を付し、重複する説明は省略する。
【００１４】
（実施の形態１）
図１は、本発明の実施の形態１に係る音源位置探査システムのシステム構成図である。本発明のシステム構成には、２通りあり、ここでは、サーバクライアント型の構成を例に説明する。
【００１５】
図１において、１０００は、携帯情報端末であり、対象音を収録し、音響指紋に変換する機能、収録時の位置情報等を検知する機能等が実装されている。なお、本実施の形態においては、携帯情報端末を端末と呼称する。
【００１６】
１００１は、マイクロホンである。マイクロホンの指向性情報や音声収録の録音レベルは、メモリ１００３内に記録されており、それらの情報は随時読み出すことができる。
【００１７】
１００２は、音響指紋変換部であり、後述する方法でマイクロホン１００１が収録した音声を音響指紋に変換する。
【００１８】
１００４は、位置取得部であり、３次元空間の座標、または地面や床を平面とみたてた場合の平面上での端末１０００の現在地を示す２次元座標等を取得する。本発明の効果としては、そのどちらでも同等であるため、説明の便宜上、位置取得部１００４は地球上での２次元位置座標を取得できるものとする。つまり、緯度経度を取得するものである。
【００１９】
１００５は、マイク方向取得部であり、マイクロホン１００１の正面が向いている方向を取得する。ここでいう方向とは、位置取得部１００４に合わせて、地図上の方向（つまり、北を０°、東を９０°南を１８０°、西を２７０°とするもの）を示す。なお、これは二次元平面上の方向であるが、これに俯角（水平方向からの上下角度）を交えて３次元空間内の角度を加えてもよい。
【００２０】
１００６は、データ送信部であり、マイクロホン１００１、音響指紋変換部１００２、メモリ１００３、位置取得部１００４及びマイク方向取得部１００５からのデータをまとめて（まとめられたデータを音声タグと呼ぶ）、適切なフォーマットに変換し、音源位置サーバ１０１０に送付する。
【００２１】
１００７は、ネットワークＩ／Ｆ（ネットワークインタフェース）であり、データ送信部１００６等の端末１０００内のモジュールの依頼を受け、ネットワーク１０３０を介して外部機器とデータの送受信を行う。
【００２２】
１０１０は、音源位置サーバである。
【００２３】
１０１１は、データベース登録部（ＤＢ登録部）であり、端末１０００から音声タグという情報構造体を受け取り、音声タグデータベース（音声タグＤＢ）１０１２に保存する。音声タグＤＢ１０１２は、音声タグを記録及び検索可能なデータベースである。
【００２４】
１０１３は、音源位置計算部であり、音声タグＤＢ１０１２中の音声タグの情報を用いて、音源の位置の精度を高める計算を行う。
【００２５】
１０１４は、ネットワークＩ／Ｆ（ネットワークインタフェース）であり、ＤＢ登録部１０１１等の音源位置サーバ１０１０内のモジュールの依頼を受け、ネットワーク１０３０を介して外部機器とデータの送受信を行う。
【００２６】
１０１５は、マップであり、一種の白地図の集合である。新しく音源が見付かると、その音源用に新たに１枚の白地図が生成される。生成されたマップは、音源とリンクされて管理される。つまり、論理的には、全世界の地図が、ユニークな音源の数だけ存在し、相互に音源とリンクされている。なお、地図といっても、重ね合せの計算と結果の保持に使われるもので、そこに地形、道路やランドマーク等が書き込まれているわけではない。マップは位置（緯度、経度）が定義された平面であり、位置とそれに対する「その位置に音源が存在する尤もらしさを表現したポイント」が記録できるだけのものである。
【００２７】
１０３０は、ネットワークである。
【００２８】
図２は、図１に示した音源位置探査システムが利用される様子を示した模式図である。図１では、表現の便宜上、端末１０００が１つしかないように記載しているが、実際は端末１０００の他にも多数の端末（２０００、２００１、２００２）が存在し、これらの端末は、複数の無線ネットワークアクセスポイント（２０３０、２０３１）を介して、ネットワーク１０３０に接続されている。
【００２９】
これらの端末は、基本的な構成は端末１０００と同じであるが、それぞれの内部のモジュールの諸元値は異なっていてよい。例えば、マイクロホンの指向性や利得などの性能が異なっていてよい。
【００３０】
ここで、図１に示した音源位置探査システムの動作概要について図２を用いて説明する。図２に示すように、実世界においては、複数の多様な音源（２０２０、２０２１）が存在する。これらの音源の位置を、端末（１０００、２０００、２００１、２００２）を使って探査するが、端末には汎用の必ずしも性能の高くない（つまり安価）マイクロホンしか搭載されていないため、１つ１つの端末単独ではおおよそ自分の周囲に音源があるという程度しかわからない。そこで、複数の端末から、その端末単独でわかる音源の位置（精度が低い）に関する情報を、音源位置サーバ１０１０に集積し、これらの情報を統合することにより、音源の位置の精度を高めることが考えられる。
【００３１】
ただし、このような音源の情報を統合するためには、同じ音源のデータのみを用いる必要がある。図２の例では音源が２つあるが、例えば、音源２０２０に関しては端末１０００及び２０００起源の情報のみを使う必要がある。これには、端末１０００と２０００は同じ音源からの音を収録しており、２００１と２００２の収録している音（音源２０２１からの音）とは異なると判別できなくてはならない。この判別を行うために、収録した音を音響指紋に変換し、音響指紋が（ほぼ）一致するかどうかで、同一音の判定を行う。音響指紋とこの利用方法については後述する。
【００３２】
図２に示す状況において、各端末（１０００、２０００、２００１、２００２）が、音源（２０２０、２０２１）の音をそれぞれのマイクロホンで収録を開始する。まず、端末１０００を例にとって、音声タグが音源位置サーバ１０１０まで送付される処理手順について説明する。
【００３３】
端末１０００が、音源２０２０の音をマイクロホン１００１で収録すると、その音声を音響指紋変換部１００２が逐次音響指紋に変換する。音響指紋とは、音声からある一定の時区間の断片を取り出し、その断片から抽出した特徴量のベクトルである。図３は、これを簡単に示した模式図である。
【００３４】
図３（ａ）の３０００は、音声をスペクトログラム風に表示したものであるが、まず音声３０００から断片３００１を切り取る。これは、時間ｔ０〜ｔ１までの時区間の音声（幅はΔｔ）を切り取ったものである。この音声断片３００１（図３（ｂ））を、適当な特徴量抽出アルゴリズムを用いて図３（ｃ）に示すような特徴量ベクトルｖt0に変換する。ここで、ｆ0〜ｆnが個々の特徴量である。
【００３５】
特徴量抽出アルゴリズムは各種提案されており、これらのアルゴリズによれば、上記時区間の幅Δｔにしても、１秒程度から数分間に及ぶ場合などバラエティーがある。本実施の形態における音源は、楽曲と異なり、音声の開始するタイミングが定かではないため、Δｔの値は１秒程度が望ましい。また、音響指紋を作成するサイクル（周期）も、十から数十分の１秒程度が望ましい。また、特徴量にしてもいろいろな方法が考えられる。いずれの方法を使うにしろ、ロバスト性、つまり、「人間の耳に同じように聞こえる音声は、似た特徴量ベクトルに変換され、異なる音声断片は異なる特徴量ベクトルに変換される」という性質を有する必要がある。通常の音響指紋は、このような特徴を持つものが多い。
【００３６】
このような特徴量ベクトルの各要素ｆ0〜ｆnは、普通数値で現わされるが、特徴量ベクトルｖは、ｎ次元空間でのベクトルとなる。この場合、特徴量ベクトルの類似度をなんらかのベクトル間の距離と定義すれば、「同じ音声に対する特徴量ベクトルの距離は０、似ている音声では距離は小さく、似ていない音声ほど距離が遠くなる」ということとなる。
【００３７】
本発明においては、この特性を満たす特徴量抽出アルゴリズムであれば、いかなるアルゴリズムでも利用できる。具体例を挙げるならば、以下の論文に開示されている方法を用いれば、本発明に適した特徴量ベクトルを作ることができる。“Ｃｏｍｐｕｔｅｒ Ｖｉｓｉｏｎ ｆｏｒ Ｍｕｓｉｃ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ（２００５）”、ｂｙ Ｙａｎ Ｋｅ、 Ｄｅｒｅｋ Ｈｏｉｅｍ、 Ｒａｈｕｌ Ｓｕｋｔｈａｎｋａｒ、Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２００５ ＩＥＥＥ Ｃｏｍｐｕｔｅｒ Ｓｏｃｉｅｔｙ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｃｏｍｐｕｔｅｒ Ｖｉｓｉｏｎ ａｎｄ Ｐａｔｔｅｒｎ Ｒｅｃｏｇｎｉｔｉｏｎ （ＣＶＰＲ′０５） Ｖｏｌｕｍｅ １、Ｐａｇｅｓ：５９７−６０４、ＩＳＢＮ〜ＩＳＳＮ：１０６３−６９１９、０−７６９５−２３７２−２
【００３８】
さて、時区間ｔ０〜ｔ１に対する音響指紋ｖ（ｔ０）が作成されると、次の時区間に対する音響指紋ｖ（ｔ１）が作成される。なお、前掲した論文においてなされるように、時区間は重なる部分があってもよく、システム全体で一貫した方法で作成されればそれでよい。
【００３９】
なお、収録した音声のレベルがある一定以下の場合の扱いについて補っておく。通常の音響指紋作成方法では、小さい音や無音に対しても音響指紋を作成することができる。しかし、本発明の場合は音源位置の探査が目的であり、音が小さいあるいは無音の場合は、音源なしと考えて音響指紋を作る必要はない。この場合は、音響指紋なしを意味するような特別の音響指紋が作成されるとする。
【００４０】
このように、音声が収録されると実時間で次々と音響指紋が作成されていく。
【００４１】
音響指紋変換部１００２により作成された音響指紋は、データ送信部１００６に渡される。データ送信部１００６は、この音響指紋を作成した時の指向性情報とマイクロホン１００１の録音レベル（収録した音のレベルではなく、マイクロホンの録音利得である）をメモリ１００３から読み取る。同時に、データ送信部１００６は、端末１０００が存在する経度及び緯度を位置取得部１００４から取得し、さらに、マイクロホン１００１が向いている方向をマイク方向取得部１００５から取得する。
【００４２】
ここで、マイクロホンの指向性情報とは、マイクロホンの向きに対してどの程度感度よく音を拾えるかの情報である。つまり、方向によるマイクロホンの感度である。図４には、指向性情報を模式的に示してある。図４（ａ）は、無指向性つまりどの方向からの音でも同一に拾える場合で、４０００は端末を、４００１は指向性のパターンを示し、ある一定の音量の音源を置いた場合に、同じ音量でマイクが拾える場所を結んだものである。図４（ｂ）は、指向性がある場合の指向性情報である。４００２は端末を、４００３は指向性パターンを示し、マイクロホン前方では感度がよく、マイクロホンの後ろに回ると感度が落ちる様子を示している。
【００４３】
本発明の場合には、この指向性情報である閉曲線（４００１、４００３）を、音源が存在し得る位置の範囲と置き換えて利用する。この閉曲線を指向性情報パターンと呼ぶとする。実際の指向性情報パターンは、音源の周波数や音量により複雑な影響を受けるし、また、音源の音量も一定ではないため、厳密に言えばこの読み換えは成立しない場面も多い。しかしながら、本発明においては、個々のマイクロホンの精度に頼らずに、複数の大量のマイクロホンを利用することで全体として精度を上げることを考えるため、この読み換えでも十分であると言える。さらに、同様の理由で、それぞれの全ての端末が指向性情報持つ必要はない。この場合、代わりに普通の携帯電話やスマートホンで利用されるようなマイクロホンを想定して、平均的な指向性情報というものを考え、指向性情報を持たない端末にはそれを用いればよい。
【００４４】
また、それ程精密な指向性情報がいらないことから、端末（マイクロホン）の機種毎に指向性情報を用意するのではなく、典型的な指向性情報を用意し（例えば、無指向性で感度が低い、無指向性で感度が高い、狭指向性など）、その中から選ぶようにしてもよい。
【００４５】
さて、データ送信部１００６に、音響指紋（ｆｐ）、指向性情報（ｄｉｒ）、録音レベル（ｌｅｖ）、位置情報（ｐｏｓ）、マイク方向（ｏｒｉ）の情報が集まったとする。これらと端末の識別子（ｉｄ）や、収録時（ｔ）をまとめた組を「音声タグ」と呼ぶとする。つまり、音声タグＡＴａｇは、Ａｔａｇ＝（ｉｄ、ｆｐ、ｄｉｒ、ｌｅｖ、ｐｏｓ、ｏｒｉ、ｔ）という６つ組となる。ここで必須であるのは、ｉｄ、ｆｐ、ｄｉｒ、ｐｏｓ、ｔである。
【００４６】
マイク方向（ｏｒｉ）がない場合は、指向性情報（ｄｉｒ）は無視されて、無指向性マイクとしての指向性情報が代わりに使われる。また、オプションとして、上記６つ組に、マイクロホン１００１で収録した音声を加えてもよい。ただし、生の音声データは、これがあれば、後に各種用途に利用できるのだが、音響指紋等他のデータに比較して巨大であり、端末１０００の処理能力やネットワーク１０３０の帯域等に余裕がある場合にしか、加えることはできないだろう。
【００４７】
音声タグが作成されると、データ送信部１００６は、ネットワークＩ／Ｆ１００７からネットワーク１０３０を介して、その音声タグを音源位置サーバ１０１０に送付する。
【００４８】
この送付のタイミングについては、音声タグが１つできる度に送付してもよいし、ある程度の数が溜ったところで一括して送付してもよい。当然後者の方がネッワーク送付に関するオーバーヘッドが削減されて、全体としての効率は良くなるが、それとは逆に音声タグのリアルタイム性は失われる。これは、この音源位置探査システムが供される目的等により適当なタイミングを決めるとよい。
【００４９】
次に、音源位置サーバ１０１０の動作について説明する。
【００５０】
端末１０００を始めとして、各端末から音声タグが送付されてくると、ＤＢ登録部１０１１は、それを音声タグＤＢ１０１２に登録する。
【００５１】
図５は、ある１つの端末から送信されてきた音声タグが登録された状態を模式的に表したものである。５０００は、音声タグの列で、音声タグの収録時ｔの順に並べられている。その中から１つの音声タグを取りだしたものが５００１と５００２である。５００１はその音声タグの音響指紋、５００２は音声タグのうち音響指紋以外のその他の情報及び推定された位置情報（マップ１０１５内に保持されている）へのリンクが書きこまれている。これは、今後の説明で音響指紋は中心的な役割を果すために、便宜上、特に取り出して表現したものである。
【００５２】
なお、これは、あくまで論理的に、このように格納されているということであり、実際に実装された音声タグＤＢ１０１２のデータの物理的な配置がこのようになっているという意味ではない。
【００５３】
今、図６に示すように、３つの端末からの音声タグ列が音声タグＤＢ１０１２に登録されているとする。図６の６０００、６００１、６００２は、音声タグ列から音響指紋のみを表示して図示したものである。例えば、図６（ａ）は端末１０００の音響指紋を、（ｂ）は端末２０００の音響指紋を、（ｃ）は端末２００１の音響指紋をそれぞれ示す。図２に示したように、端末１０００と端末２０００は同一の音源２０２０の音声を収録しており、端末２００１は別音源２０２１を収録しているとする。
【００５４】
このような状態で音源位置計算部１０１３が位置の精密化を行う過程について説明する。音源位置計算部１０１３は、新規登録の音声タグが音声タグＤＢ１０１２に登録されると適当なタイミングで、その新規音声タグの音響指紋が登録済の音声タグの音響指紋に一致あるいは似た部分がないか音声タグＤＢ１０１２を検索する。つまり、新規音声タグの音響指紋からある一定の閾値以下の距離に既登録の音響指紋がないかを検索する。この検索は、新規登録時に即座に行ってもよいし、ある程度新規登録分が溜ってから一斉に行ってもよい。
【００５５】
同一音源からの音を収録していた場合は、ある一定の連続した音響指紋列が互いに似ている、あるいは一致していると判断されることになる。例えば、これが図６の６００３と６００４の部分であるとする。端末（識別子＝ｉ）の時間ｔにおける音響指紋をｖ（ｉ、ｔ）と表現すれば、６００３の音響指紋列は、端末識別子をｉとすると、次のように表される。
Ｄ１＝（ｖ（ｉ、ｔ０）、ｖ（ｉ、ｔ０＋１）、ｖ（ｉ、ｔ０＋２）、…、ｖ（ｉ、ｔ０＋ｎ−１））
【００５６】
また、６００４の音響指紋列は、端末識別子をｊとすると、次のように表される。
Ｄ２＝（ｖ（ｊ、ｔ１）、ｖ（ｊ、ｔ１＋１）、ｖ（ｊ、ｔ１＋２）、…、ｖ（ｊ、ｔ１＋ｎ−１））
【００５７】
Ｄ１、Ｄ２の式において、ｖ（ｉ、ｔ０＋ｍ）≒ｖ（ｊ、ｔ１＋ｍ）、ｍは０からｎ−１の整数、とういう関係が成り立つということである。音響指紋列がいくつ連続していれば良いかは、実装上の決定事項となる。また、連続が一瞬途切れた場合の扱いについては、適当な確率モデルを用いて判定することになる。例えば、前掲の論文“Ｃｏｍｐｕｔｅｒ Ｖｉｓｉｏｎ ｆｏｒ Ｍｕｓｉｃ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ（２００５）”では、録音音声と原音を比較する際に、一致するかしないかをベルヌーイ過程とモデル化して判定する方法が、“ｏｃｃｌｕｓｉｏｎ ｍｏｄｅｌ”という名称で提案されており、それを用いてもよい。あるいは、もっと単純に、ある適当な時間幅（数秒〜１０数秒など）で７割一致していれば、一致と判断してもよい。
【００５８】
また、時刻ｔ０とｔ１は、｜ｔ０−ｔ１｜≦ｔｈ（ｔｈは、数秒〜数分の値で、実装上のパラメータ）の関係にあればよく、一致している必要はない。これは、音声の収録時刻を記録するのが端末側として、端末の時計には当然ばらつきがあるからである。また、サーバ側の登録時間を収録時間と読みかえて、収録時間をサーバ側で付与したとしても、登録のための待ち時間や通信時間はデータ毎に異なるため、やはりばらつきが発生することになる。
【００５９】
このような音響指紋の一致列が見付かった場合には、音源位置計算部１０１３は、他の作業と平行して、位置の精密化の作業を開始する。
【００６０】
前述した通り、本発明では、マイクロホンの指向性に関する情報を、音源が存在しうる位置の範囲として読み換えることで、音源の位置推定を行う。そして、音源位置の精密化とは、同一の音源に由来すると思われる音声タグに記録されている指向性情報を重ね合わせることにより実現される。この重ね合わせは、マップ１０１５上で行われる。
【００６１】
図７は、このマップ１０１５上で指向性情報を重ね合わせた結果を模式的に現わしたものである。図７の背景にあるのがマップ１０１５であり、その上に端末１０００、２０００の実際の位置（音声タグ中の位置情報）に従い、端末１０００、２０００を配置する（図７における１０００、２０００の位置）。次に、それぞれの端末位置を中心にマイク方向に従い、回転を加えた指向性情報をマッピングする（７０００及び７００１）。図７の状況では、指向性情報を無指向性（指向性情報のパターンが円）と仮定しているので、マイク方向はあまり意味を持たない。そして、最終的に指向性情報のパターン７０００と７００１の重なり合う部分７００２に音源があると推定される。
【００６２】
つまり、端末１０００から見て、音源は７０００の中にあると推定され、かつ、端末２０００からみれば、７００１内にあると推定されるから、その結果、音源のより確からしい位置は、７０００と７００１の重ね合わせ部分である領域７００２内ということになる。
【００６３】
なお、この重ね合わせの計算の実装について補足をしておく。指向性情報のパターンである閉曲線同士の重ねあわせを正確に計算してしまうと、もともとの位置情報やマイク方向の誤差を考えればあきらかに過剰品質になる。そこで、計算を効率的に行うために、指向性情報のデータ構造や計算方法を簡略化してやる必要がある。その一例として、マップ１０１５を連続した位置がとれる平面ではなく、離散的な位置しかとれないとすることで、計算量を減らす方法が考えられる。つまり、マップ１０１５の位置に関しては、位置取得部１００４の位置精度を大きく超えて実装しても意味がないから、例えば、東西方向及び南北方向に対して１メートル単位での位置しかとれないよう位置の量子化を行う（１メートルではなく、緯度経度で０．１秒単位なども考えられる）。この結果、指向性情報は閉曲線で囲まれた領域ではなく、２次元のビットマップとして表現できる。これを模式的に表現したのが図８である。
【００６４】
図８では、原点部分に端末（マイクロホン）があり、ｙ軸正方向がマイクロホン正面である。各ビットは、１メートル四方の地面に相当し、ビット毎に音源の存在ポイントというべき整数値が保持される。１が指向性パターン８０００の内側つまり、音源が存在する可能性がある場所を表わし、外側は０である（図８では、０は省略してある）。
【００６５】
マップ１０１５も同様に表現できる。例えば、図７の重ね合わせの結果を、ビットマップで表すと図９のようになる。７０００と７００１の重なった部分は、それぞれのビットマップの各ビットの数を足し合わせたものとなる。この場合は、１＋１で２となる（図９の７００２の部分）。つまり、指向性情報パターン７０００、７００１の外部は、音源の存在するポイントが０で、１の部分は０の部分より存在する尤もらしさがあがり、領域７００２の部分はポイント２で、このマップ１０１５中で音源が存在する尤もらしさが一番高い部分となる。
【００６６】
以上の計算は、地図上での指向性情報の重ね合わせが２つだけの場合であるが、これが３以上になっても同様の計算を行えばよい。これを図６の場合で説明する。前述したように、図６の６００３の音響指紋列は、端末識別子をｉとすると、次のように表された。
Ｄ１＝（ｖ（ｉ、ｔ０）、ｖ（ｉ、ｔ０＋１）、ｖ（ｉ、ｔ０＋２）、…、ｖ（ｉ、ｔ０＋ｎ−１））
【００６７】
また、６００４の音響指紋列は、端末識別子をｊとすると、次のように表された。
Ｄ２＝（ｖ（ｊ、ｔ１）、ｖ（ｊ、ｔ１＋１）、ｖ（ｊ、ｔ１＋２）、…、ｖ（ｊ、ｔ１＋ｎ−１））
【００６８】
Ｄ１、Ｄ２の式において、ｖ（ｉ、ｔ０＋ｍ）≒ｖ（ｊ、ｔ１＋ｍ）、ｍは０からｎ−１の整数、とういう関係が成り立った。ここでさらに、ｖ（ｋ、ｔ）に対応する音声タグをａｔａｇ（ｋ、ｔ）として、その音声タグの指向性情報をａｔａｇ（ｋ、ｔ）［ｄｉｒ］、マイク方向をａｔａｇ（ｋ、ｔ）［ｏｒｉ］、位置情報をａｔａｇ（ｋ、ｔ）［ｐｏｓ］と表記することにする。
【００６９】
この場合、指向性情報の重ね合わせとは、ａｔａｇ（ｉ、ｔ０＋ｍ）［ｄｉｒ］及びａｔａｇ（ｊ、ｔ１＋ｍ）［ｄｉｒ］の指向性情報を、マイク方向と位置情報を勘案して、ｍにつき０からｎ−１まで、マップ１０１５上で各ビット毎に加算していってやればよい。すなわち、以下の計算を行うということである。
【００７０】
ａｔａｇ（ｋ、ｔ）について、ｋは、｛ｉ、ｊ｝と変化させ、ｔは、ｋ＝ｉの時は、ｔ０〜ｔ０＋ｎ−１、ｋ＝ｊの時はｔ１〜ｔ１＋ｎ−１と変化させて、全てのｋ、ｔの組み合わせに対して、次の（１）から（２）を計算する。
【００７１】
（１）ａｔａｇ（ｋ、ｔ）［ｄｉｒ］をａｔａｇ（ｋ、ｔ）［ｏｒｉ］だけ回転させる。この結果をＴとする。
【００７２】
（２）Ｔ上の位置（ｘ、ｙ）のビットに書き込まれた値をＴ（ｘ、ｙ）とし、マップ１０１５上の位置（ｎｏｒｔｈ、ｅａｓｔ）のビットをＭＡＰ（ｎｏｒｔｈ、ｅａｓｔ）とし、位置情報ａｔａｇ（ａｔａｇ（ｋ、ｔ）［ｐｏｓ］） ＝（Ｎ、Ｅ）とすれば、指向性情報が取り得る範囲でｘ、ｙを変化させて、以下を計算する。
【００７３】
ＭＡＰ（Ｎ＋ｘ、Ｅ＋ｙ）＋＝Ｔ（ｘ、ｙ）（ただし、＋＝は、足し込みの演算子）
そして、その重ね合わせの結果、音源の存在する尤もらしさが一番高い数値の地点（例えば、図９の７００２）が、この音声タグ列に対して推定された音源の位置となる。
【００７４】
次に、端末１０００及び２０００のマイクロホンに指向性があった場合の例を、図１０を使って説明する。基本的には、無指向性の場合と同じであり、最終的には図１０に示したようになる。
【００７５】
マップ１０１５上に位置情報の通り端末を配する（図１０の１０００、２０００）。その端末を中心に、その端末のマイク方向分回転させた指向性情報パターンを重ねる。端末１０００に関してのマイク方向が１０００２、端末２０００のマイク方向は、１０００３である。なお、回転の演算の実装であるが、自由な角度の回転を許すと演算量が増え、全体の効率が落ちることから、回転の角度に関しても、例えば３０°単位での離散的な値しか取れないとし、マイク方向の値を適当にまるめれば良い。さらには、予め３０°毎に回転させた指向性情報を計算しておき、マイク方向の回転の演算をする場合は、その事前に計算された結果を呼び出すだけにすれば、一層の演算速度の向上が期待できる。図１０の場合の最終的な音源の推定位置は、１０００４でハッチングをかけた部分となる。
【００７６】
次に、複数端末の指向性情報を重ね合わせた場合について説明する。図１１は、端末１１０００から１１００３の４つの端末で収録した音声に、似た音響指紋列が観測された場合の重ね合わせ結果である。ここで、似た音響指紋列が観測された端末が複数になると、重ね合わせの箇所も複数になる。例えば、図１１では、１１０１０や１１０１１等いくつかの部分で複数の指向性情報の重ねあわせが発生している。
【００７７】
この中で、音源がある位置として推定されるのは、マップ１０１５の各ビットの中で、ビットの音源の存在する尤もらしさのポイントが最も高い部分が音源の位置と推定される。図１１では、領域１１０１０中のビット数値は、３つの指向性情報のパターンが重なっているので３である。それに対して、領域１１０１１では２であるから、領域１１０１０の部分の方が音源位置としてより好ましいということとなる。
【００７８】
以上が、基本的な音源の位置推定方法である。次に、さらに音源の位置推定を正確にするための工夫、拡張を４種説明する。まず、最初の手法について説明する。今までは、指向性情報の重ね合わせをすることで、音源位置推定の精度を上げられることを示したが、指向性情報の減算をすることでも推定精度を向上させることができる。
【００７９】
今、図１２に示したような音声タグ列（ａ）、（ｂ）があるとする。音声タグ列の表現方法は、図５で使ったものと同じで、音声タグ列の上部が、音響指紋の列で、下が音響指紋以外の情報の列である。ここの説明では、位置情報しか言及しないため、位置情報の列と考えてもらってよい。また、図１２の音声タグ列（ａ）を生成した端末を１３０００（図１３）とし、図１２の音声タグ列（ｂ）を生成した端末を１３００１（図１３）とする。
【００８０】
ここで、ある音源に対する音響指紋列１２０００と、その他の情報の列１２００１がある場合に、その他の情報の列１２００１中の位置情報から距離的及び時間的に近接した距離であるにも関わらず、音響指紋列１２０００に似た列が存在しない部分があるかを、音声タグ列（ｂ）の音響指紋列から検索する。ここで、そのような部分があった場合には、減算によって音源位置を推定することができる。
【００８１】
例えば、図１２の音声タグ列（ｂ）の中で、時間ｔ０に近く、その他の情報の列１２００１に近接した位置情報をもった部分がないかを探す。この結果、１２００１と１２００２の部分の位置情報が近いにもかかわらず、音響指紋列１２０００に似た列が音声タグ列（ｂ）に存在しなかったとする。この場合、図１２の音声タグ列（ａ）に対応した端末の指向性情報から、図１２の音声タグ列（ｂ）に対応する端末の指向性情報を減算することができる。つまり、音響指紋列１２０００に対応する音源をＸとすれば、Ｘの位置は、１２００１部分に記録されている端末１３０００の位置の近く（すなわち、指向性情報パターン１３０１０内）ということになる。そして、その音源Ｘが音を発していた時刻ｔ０において、端末１３００１は、端末１３０００の付近にあったにもかかわらず音源Ｘの音を収録していない。これは、音源Ｘは、端末１３００１の指向性情報のパターン１３０１１外にある可能性が高いということである。両者の状況を勘案すれば、音源は、領域１３０１２内にあると推定される。この領域１３０１２とは、指向性情報のパターン１３０１０から、１３０１１を引いたものであり、それゆえに、減算による音源位置の推定と呼ぶ。
【００８２】
次に、２番目の手法について説明する。これは、重ね合わせができる状況にあるにも関わらず重ね合わされた指向性情報のパターンがない場合に利用する。図１４にこの２番目の手法を適用した結果を示す。端末は１４０００〜１４００３まで４台あるとし、これら４台が比較的近い距離内で、ほぼ同じ時刻に、同一音源の音と思われる音響指紋列を記録していたとする。この場合、指向性領域（１４０１０〜１４０１３）を重ね合わせることができるはずだが、図１４に示す通り１４０１０〜１４０１３には重ね合わせる領域がない。この場合、音が非常に大きかったため、通常では聞こえないはずの指向性情報のパターン外の音まで拾ったと解釈するのが妥当と思われる。そこで、指向性情報パターンを通常の領域の数倍拡大し、再度重ね合わせを試みる。なお、何倍にするかは、実装上の調整パラメータとなる。ここでは、例えば５倍に拡大し（１４０２０〜１４０２３）、再度重ね合わせを行うと、音源位置の推定領域１４０３０が得られる。
【００８３】
なお、音声タグにもし録音レベルが記録されていれば、単純に一定倍するのではなく、録音レベルに応じて倍数を決めてもよい。例えば、録音レベルが低い場合は、指向性情報パターンを大きく広げるのがよく（つまり、録音レベルを下げているにもかかわらず音声が収録できたのは、非常に大きな音だったと考えられる）、録音レベルが高い場合は、指向性情報パターンを縮小させるのがよい。
【００８４】
次に、３番目の手法について説明する。これは、時間的には離れているが、距離的には近接している位置で、複数の端末（単一でもよい）が、同一の音源由来と思われる音声を収録した場合である。例えば、学校等で毎日夕刻になると下校のために同じ曲を流している、あるいは、視覚障碍者用の信号機の音楽など、繰り返し同じ場所で流される音声を異なる時間に収録した場合が考えられる。よって、同一の音源と考えてよいので、指向性情報を重ね合わせることができる。
【００８５】
これを図１５、図１６を参照しながら説明する。まず、時刻ｔ１で、端末１５０００が、地点（ｎ１、ｅ１）において、音源Ｘ由来と思われる音声を観測したとする（図１５（ａ））。１５０１０は、この場合の指向性情報のパターンである。次に、ｔに近接していない時刻ｔ２において、端末１５００１が、地点（ｎ２、ｅ２）において、音源Ｘ由来と思われる音声を観測したとする（図１５（ｂ））。
【００８６】
図１６（ａ）、（ｂ）は、この状況での端末１５０００、１５００１が送付した音声タグ列である。図１６（ａ）（１６０００）は、端末１５０００が送付したもので、図１６（ｂ）（１６００１）は、端末１５００１が送付したものである。音声タグ列の表記は、図５で説明したのと同様に、音声タグ列上段が音響指紋列であり、下段がその他の情報（ここでは、位置情報）である。図１６（ａ）の音響指紋列１６０１０と、図１６（ｂ）の音響指紋列１６００１とは音源Ｘ由来であるが、時間ｔ１、ｔ２は、ほぼ同時刻とは言えないほど離れているため、通常は指向性情報の重ね合わせは起こらない。
【００８７】
しかしながら、位置情報１６０１１と１６０２１の距離を計算して十分近接していた（例えば、２位置間の距離がある閾値以下の場合）ならば、前述したような状況が考えられるため、重ね合わせを行うべきである。重ね合わせがなされた状況を、図１５（ｃ）に示す。この結果、図１５（ｃ）の１５０２０のような、音源位置の推定領域を得ることができる。
【００８８】
なお、この場合、端末１５０００と１５００１は、同じ端末でもよい。これは、図１６の（ｃ）のような状況である。この場合、ある１つの端末の音響タグ列１６００２において、時刻ｔ１とｔ２で同じ音源に由来すると思われる音響指紋１６０３０、１６０４０が得られており、位置１６０３１と１６０４１が十分近接していればよい。
【００８９】
さらに、この方法を応用して、プリセットされた音源を用意することもできる。これは、音声タグＤＢ１０１２中に、音のランドマークとして機能するであろう音源を音声タグ列に変換して記録しておく。音のランドマークとは、例えば、前掲した学校等で夕刻にかかる曲や、信号機の音、その他、駅の階段を示す鳥の声などである。ただし、実際に収録した音ではないから、この音声タグに含まれる位置情報や指向性情報は、不定を示す特別な値を入れておく。
【００９０】
一方、これらプリセットされた音源と同じ音源を収録した端末がある場合、その端末が生成した音声タグ列の音響指紋列には、必ずプリセットされた音声タグ列の音響指紋列と一致する部分がある。そして、この後、音源位置推定が行われ、当初は音源位置が不明であったプリセット音源の位置がある程度推定される。そして、これを収録した端末が増えれば、音源の位置がより正確になっていく。
【００９１】
前記の信号機の音であれば、同じ音声を発する信号機が１００台あるとすれば、その信号機の音源に対応するマップ１０１５は、音源位置の存在するポイントのピークが１００観測されるように変化していくことになる（音源位置が大きくかわる毎に、新規のマップを生成するという方法も考えられる）。
【００９２】
最後に、４番目の方法について説明する。これは、位置を明かにしたい音源がある場合に、端末に要請して、音声を収録させる方法である。具体的には、位置をより明かにしたい音源がある場合に、他端末あるいは音源位置サーバから、その位置に一番近い端末に命じて（端末を通じてユーザに命じて）、その音源の付近へ移動させることで、積極的に音源位置を明確にする方法である。
【００９３】
このように実施の形態１によれば、マイクロホン間の相対位置や向きが任意に変化し得る状況において、複数の端末から得られた音響指紋列を用いて、音響指紋による音声のマッチングを行うことにより、特殊なマイクロホンを使うことなく、音源位置の推定精度を向上させることができる。
【００９４】
（実施の形態２）
実施の形態１では、システム構成をサーバクライアント型とする場合に付いて説明したが、本発明の実施の形態２では、システム構成をＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）型のサーバなしとする場合について説明する。
【００９５】
図１７は、本発明の実施の形態２に係る音源位置探査システムのシステム構成図である。図１７において、１７０００は、端末である。
【００９６】
１７００１は、データ送信部であり、マイクロホン１００１、音響指紋変換部１００２、メモリ１００３、位置取得部１００４及びマイク方向取得部１００５からのデータをまとめて（まとめられたデータを音声タグと呼ぶ）、適切なフォーマットに変換し、Ｐ２Ｐネットワーク１７０１０を介して接続されている近隣の端末に対して、音声タグを送付する。
【００９７】
１７００２〜１７００５は、同名のモジュールが実施の形態１にも登場している。実施の形態１では、システム全体に対して（論理的には）１つだけのＤＢ登録部、音声タグＤＢ、マップ、音源位置計算部が存在した。つまり、これらの機能は音源位置サーバ１０１１にしかなかった。これに対して、実施の形態２のＰ２Ｐ型構成では、端末全てにこれらの機能が備わっている。ただし、実施の形態１での音源位置サーバ１０１０は、広い地域に存在する多数の端末からのデータを処理しなければならないため、巨大なデータベースや強力な処理能力が必要であったが、本実施の形態のＤＢ登録部１７００２、音声タグＤＢ１７００３、マップ１７００４、音源位置計算部１７００５は、自端末の近隣の端末しか相手にしないため、サーバクライアント型の構成に比較して、これらのモジュールは小規模コンパクトに実装することができる。
【００９８】
ＤＢ登録部１７００２も、ＤＢ登録部１０１１と機能は同一である。その他、音声タグＤＢ１７００３、マップ１７００４、音源位置計算部１７００５に関しても、実施の形態１の同名のモジュールと機能は同一であるが、ただし、実装段階では小規模、つまりメモリ量等を大幅に削減してよい。
【００９９】
１７００６は、ＤＢマップ同期部であるが、これはＰ２Ｐ構成にするために必要になったモジュールである。一般に端末は、メモリ等の記憶容量に恵まれているわけではないため、音声タグ列やマップを、全世界の全端末分、長期間保持するわけにはいかない。またＰ２Ｐ通信の特性として、そもそも全ての端末からの音声タグを受信できるわけではない。
【０１００】
このため、近隣の端末から各種機能を実行するために必要なデータを受け取り、また、必要なくなったデータを削除する仕組みが必要である。ＤＢマップ同期部１７００６は、この作業を行うためのモジュールである。
【０１０１】
ＤＢマップ同期部１７００６は、自端末１７０００の位置（位置取得部１００４から取得）を常に把握するとともに、通信可能な他端末が、自端末１７０００の近隣の範囲内に存在する音源に関するマップをもっていれば、その複製を転送して自分のマップとして管理するようにする。この管理範囲を「マップ管理範囲」と呼ぶ。
【０１０２】
逆に、自分が持つマップ１７００４中に、マップ管理範囲から逸脱した音源に対するマップがあれば、それを削除する。マップ管理範囲は、自端末を中心にした一定の半径の円（または球）か、あるいは計算を簡便にするために、矩形（直方体）等であってもよい。また、他端末からマップの転送要求を受けた場合、ＤＢマップ同期部１７００６は、要求されたマップを渡す。
【０１０３】
マップと同様に、音声タグ列に関しても他端末とデータを交換する必要がある。いま、通信可能な他端末の音声タグＤＢ内にある音声タグ列中おいて、以下の条件を満す音声タグ列があれば、その音声タグ列の複製を音声タグＤＢ１７００３内にコピーする。
【０１０４】
条件：音声タグ列のうち、現在から一定の過去の範囲内の音声タグのうち少なくとも１つ以上の音声タグの位置情報が、自端末１７０００の近隣内であること。
【０１０５】
この「一定の」というのは、実装上のパラメータである。また「少なくとも１つ」というのも、実装時にある程度は増やしてもかまわない。つまり、一定の時間内の過去において、自端末１７０００の現在地から一定の範囲内に一度でも存在した端末であれば（ただし、現在通信可能な端末内で）、その端末が生成したタグ列を自分の音声タグＤＢ１７００３内に複製する。この「一定の時間内の過去」かつ「自端末の現在地からの一定の範囲内」を「音声タグ管理範囲」と呼ぶ。なお、他端末から音声タグをコピーする場合、列全てを複製せずに、その「一定の時間内の過去」分だけの複製でもよい。
【０１０６】
また、当然、音声タグＤＢ１７００３内のある音声タグ列において、音声タグ管理範囲内に入っている音声タグが１つもなくなってしまった場合、その音声タグ列は削除してよい（音声タグＤＢ１７００３の容量が十分大きければ、しばらくは削除しなくてもよい）。
【０１０７】
なお、このマップ管理範囲と音声タグ管理範囲においては、通信可能な端末を問題にしているが、うまくＰ２Ｐネットワークが構築されれば通信可能な端末とは事実上全端末を指すことになる。これではデータ交換を行う範囲が広すぎ、ネットワークに負荷をかけすぎる可能性があるため、実際の実装上では、ホップ数の制限等を加える必要がある。
【０１０８】
１７００７は、ネットワークＩ／Ｆであり、Ｐ２Ｐネットワーク１７０１０を利用して近隣の端末と通信を行う。
【０１０９】
１７０２０は、他の端末であり、基本的には端末１７０００と同等のものである。すなわち、他端末１７０２０は、端末１７０００に対して実施の形態１における音源位置サーバと同様の機能を果たすことになり、音源位置サーバ装置と捉えることができる。
【０１１０】
図１８は、図１７に示した音源位置探査システムが利用される様子を示した模式図である。１８０００〜１８００３は端末、１８０３０と１８０３１が音源、１８０２０〜１８０２２がルーティング経路である。
【０１１１】
１８０００〜１８００２の端末（端末群１８０４０）は、お互いにマップ管理範囲及び音声タグ管理範囲内にあるデータを持っているとする。すると、端末群１８０４０内では、マップ管理範囲内及び音声タグ管理範囲内にあるデータは時間とともに共有化されていくことになる。
【０１１２】
一方、端末１８００３が持っているデータは、マップ管理範囲内及び音声タグ管理範囲内にないのだから、共有されることはない。また、端末１８００３が、自分が生成した音声タグ（Ｙとする）を、経路１８０２２を介して端末１８００２に送信したとしても、それがさらに端末１８００１に転送されることもない。これは、Ｙは、長さ１の音声タグ列として、端末１８００２内の音声タグＤＢに登録されるが、直後にＹは、ＤＢマップ同期部１７００６により削除されてしまうからである。なお、一旦登録した直後に削除するのは、効率が悪いため、最初からＹの受け取り拒否をするようにしてもよい。
【０１１３】
このように、近い距離にある端末同士（ある端末が音声タグを生成して他端末に送っても、それが削除されないような距離）の中では、おおむね位置計測部１７００５が位置を精密化するのに必要なデータが揃う。すなわち、実施の形態１で説明したような動作と同様な音源位置の推定動作がなされることになる。
【０１１４】
以上のように、サーバクライアント構成（実施の形態１）と比較して、Ｐ２Ｐ構成でも同様な音源位置の推定が可能である。さらにＰ２Ｐ構成ではサーバクライアント構成に比較した利点もある。サーバクライアント方式では、サーバ側に音声タグ列をすべて集めて、その上で位置情報の精密化を行う。サーバ側では多数のデータを処理しなければならず、あるクライアント（端末）が、他クライアント由来の位置情報を利用できるようになるまでには、多少時間がかかることになる。
【０１１５】
それに対して、Ｐ２Ｐ側では、ある端末の近隣の端末が生成した音声タグが、ほぼリアルタイムに自分の音声タグＤＢ内に複製されることになるため、他端末で収録した音声を、自分で収録した音声と時間的な差違がほとんどなく利用することができる。
【０１１６】
ここで、図１９、図２０を使って、この利点に関して具体的に説明をする。図１９は、マップ１７００４に、道路と車を重ね合わせて図示した模式図である。１９０００、１９００１は道路であり、１９００１は１９０００にＴ字路として交わっている。１９０２０、１９０３０、１９０４０、１７０００は、端末であり、これら端末を持っているユーザ４人は、それぞれ道の路側帯に立っていることになる。なお、１７０００は、図１７の端末と同じものであり、この説明の中では自端末と呼称する場合もある。他の１９０２０、１９０３０、１９０４０も、基本的な端末内の構成は、１７０００と同じである。
【０１１７】
このような状況で、１台の車Ｃが図面上から下方向に道路上を走っており、時刻ｔ０、ｔ１、ｔ２における車Ｃの位置を示している。ただし、ｔ０＜ｔ１＜ｔ２である。
【０１１８】
１９０２１、１９０３１、１９０４１、１９０５１は、指向性情報のパターンを、それぞれの端末の位置に応じてマップ１７００４上に重ねて表示したものである。
【０１１９】
なお、４台の全ての端末は、お互いにマップ管理範囲と音声タグ管理範囲にあり、また通信可能であるとする。このため、ある端末で作成された音声タグは、リアルタイムで他の端末の音声タグＤＢ内にもコピーされる。
【０１２０】
時刻ｔ２以降の時点ｎｏｗにおける端末１７０００の音声タグＤＢ１７００３内を模式的に図２０に示す。音声タグＤＢ１７００３内には、端末１７０００が自分で作成した音声タグ列２００３０の他に、端末１９０２０が作成した音声タグ列２００００、端末１９０３０が作成した音声タグ列２００１０、端末１９０４０が作成した音声タグ列２００２０の複製が存在している。つまり、他端末で音声タグが生成されると、瞬時に端末１７０００にも転送され、既にある音声タグ列の末尾（つまり現時点）に追加される。
【０１２１】
ここで、音響指紋変換部１００２は、車Ｃが走行時に発する音声に対して、同一の音声タグ指紋列を生成することができるとする。この場合に、音声タグＤＢ内１７００３内の音声タグ列１９０２０、１９０３０、１９０４０には、同一の音響指紋列が存在することになる。つまり、図２０おいて、２０００１、２００１１、２００２１の部分である。
【０１２２】
これら、音響指紋列に対する位置は、２０００２、２００１２、２００２２中に存在する各端末の位置とマイクの方向（ただし、ここでは説明の便宜上、無指向性とするので、マイクの方向は意味をもたない）、指向性情報から図１９の１９０２１、１９０３１、１９０４１の円内となる。つまり、端末１７０００の場所からは、車Ｃの音を直接聞くことはできないが（指向性情報パターン１９０５１の外にあるので）、音源が自端末１７０００方向に向って、上から下（例えば、北から南）に近づいてくることがわかる。
【０１２３】
もし、今音源に対する音響指紋列２０００１等からこの音響指紋列が車のエンジン音やサイレン等であることが分かれば、おおよそ自端末１７０００の方向に向っているものが、車であることまで分かることになる。さらに、道路１９０００があるなどの地理情報も利用できれば、この車が、道路１９０００上にあることまで推論できるだろう。この場合は、端末１７０００のユーザに対して、「この道１９００１から道路１９０００に出ると、ちょうど車Ｃが接近しており、危ない」などの警告を出すことも可能であろう。この警告機能は、ユーザが例えばヘッドホンを用いて音楽を聞いており、周囲の音をよく聞き取れない状況であるとか、聴覚障碍者にとっても有用であると思われる。
【０１２４】
このように実施の形態２によれば、端末を用いたＰ２Ｐ型の音源位置探査システムを構築し、端末毎に取得した音響指紋列をＰ２Ｐネットワークを介して複数の端末間で互いに共有して、音響指紋による音声のマッチングを行うことにより、音源位置の推定精度を向上させることができる。
【産業上の利用可能性】
【０１２５】
本発明にかかる音源位置探査システムは、モバイル端末を用いて音源位置の推定精度を向上させるものとして有用である。
【符号の説明】
【０１２６】
１０００ 携帯情報端末
１００１ マイクロホン
１００２ 音響指紋変換部
１００３ メモリ
１００４ 位置取得部
１００５ マイク方向取得部
１００６ データ送信部
１００７ ネットワークインタフェース
１０１０ 音源位置サーバ
１０１１ ＤＢ登録部
１０１２ 音声タグＤＢ
１０１３ 音源位置計算部
１０１４ ネットワークインタフェース
１０３０ ネットワーク
２０００、２００１、２００２ 携帯情報端末
２０２０、２０２１ 音源
２０３０、２０３１ 無線ネットワークアクセスポイント
４０００、４００２ 携帯情報端末
１１０００、１１００１、１１００２、１１００３ 携帯情報端末
１３０００、１３００１ 携帯情報端末
１４０００、１４００１、１４００２、１４００３ 携帯情報端末
１５０００、１５００１ 携帯情報端末
１７０００ 携帯情報端末
１７００１ データ送信部
１７００２ ＤＢ登録部
１７００３ 音声タグＤＢ
１７００４ マップ
１７００５ 音源位置計算部
１７００７ ネットワークインタフェース
１７０１０ ピアツーピアネットワーク
１７０２０ 他の携帯情報端末
１８０００、１８００１、１８００２、１８００３ 携帯情報端末
１８０３０、１８０３１ 音源
１９０２０、１９０３０、１９０４０ 携帯情報端末
【特許請求の範囲】
【請求項１】
マイクロホンと、
前記マイクロホンによって収録された音声を音響指紋に変換する音響指紋変換手段と、
現在地を示す位置情報を取得する位置取得手段と、
前記マイクロホンの指向性を示す指向性情報、前記音響指紋、前記位置情報及び自装置を識別する識別子を組にした音声タグを送信する送信手段と、
を有する無線通信端末装置と、
複数の無線通信端末装置より送信された前記音声タグを識別子毎に時系列で記憶する音声タグ記憶手段と、
異なる識別子間で前記音声タグの一部が一致又は近似しており、かつ、一定の時間内に収録された音響指紋を探索し、探索された音響指紋と同じ組の位置情報及び指向性情報を用いて、音源の位置を推定する音源位置計算手段と、
を有するサーバ装置と、
を具備する音源位置探査システム。
【請求項２】
前記サーバ装置は、前記無線通信端末装置とピアツーピアネットワークを介して接続された他の無線通信装置である請求項１に記載の音源位置探査システム。
【請求項３】
前記無線通信端末装置は、前記マイクロホンの向いているマイク方向を取得するマイク方向取得手段を具備し、
前記送信手段は、前記マイク方向を前記音声タグに加えて送信し、
前記サーバ装置における前記音源位置計算手段は、前記マイク方向と指向性情報とを組み合わせて、音源位置を推定する、
請求項１又は請求項２に記載の音源位置探査システム。
【請求項４】
前記無線通信端末装置における前記送信手段は、前記マイクロホンの録音利得である録音レベルを前記音声タグに加えて送信し、
前記サーバ装置における前記音源位置計算手段は、前記マイクロホンの録音利得と指向性情報とを組み合わせて、音源位置を推定する、
請求項１又は請求項２に記載の音源位置探査システム。
【請求項５】
前記音源位置計算手段は、同一の識別子を有する複数の音声タグの一部が一致又は近似しており、かつ、一定の時間内に収録された音響指紋を探索する、
請求項１又は請求項２に記載の音源位置探査システム。
【請求項６】
前記音声タグ記憶手段は、音源が発した音声の音響指紋を含む音声タグを予め記憶する、
請求項１又は請求項２に記載の音源位置探査システム。
【請求項１】
マイクロホンと、
前記マイクロホンによって収録された音声を音響指紋に変換する音響指紋変換手段と、
現在地を示す位置情報を取得する位置取得手段と、
前記マイクロホンの指向性を示す指向性情報、前記音響指紋、前記位置情報及び自装置を識別する識別子を組にした音声タグを送信する送信手段と、
を有する無線通信端末装置と、
複数の無線通信端末装置より送信された前記音声タグを識別子毎に時系列で記憶する音声タグ記憶手段と、
異なる識別子間で前記音声タグの一部が一致又は近似しており、かつ、一定の時間内に収録された音響指紋を探索し、探索された音響指紋と同じ組の位置情報及び指向性情報を用いて、音源の位置を推定する音源位置計算手段と、
を有するサーバ装置と、
を具備する音源位置探査システム。
【請求項２】
前記サーバ装置は、前記無線通信端末装置とピアツーピアネットワークを介して接続された他の無線通信装置である請求項１に記載の音源位置探査システム。
【請求項３】
前記無線通信端末装置は、前記マイクロホンの向いているマイク方向を取得するマイク方向取得手段を具備し、
前記送信手段は、前記マイク方向を前記音声タグに加えて送信し、
前記サーバ装置における前記音源位置計算手段は、前記マイク方向と指向性情報とを組み合わせて、音源位置を推定する、
請求項１又は請求項２に記載の音源位置探査システム。
【請求項４】
前記無線通信端末装置における前記送信手段は、前記マイクロホンの録音利得である録音レベルを前記音声タグに加えて送信し、
前記サーバ装置における前記音源位置計算手段は、前記マイクロホンの録音利得と指向性情報とを組み合わせて、音源位置を推定する、
請求項１又は請求項２に記載の音源位置探査システム。
【請求項５】
前記音源位置計算手段は、同一の識別子を有する複数の音声タグの一部が一致又は近似しており、かつ、一定の時間内に収録された音響指紋を探索する、
請求項１又は請求項２に記載の音源位置探査システム。
【請求項６】
前記音声タグ記憶手段は、音源が発した音声の音響指紋を含む音声タグを予め記憶する、
請求項１又は請求項２に記載の音源位置探査システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【公開番号】特開２０１２−２６４５（Ｐ２０１２−２６４５Ａ）
【公開日】平成２４年１月５日（２０１２．１．５）
【国際特許分類】
【出願番号】特願２０１０−１３７２７８（Ｐ２０１０−１３７２７８）
【出願日】平成２２年６月１６日（２０１０．６．１６）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成２４年１月５日（２０１２．１．５）
【国際特許分類】
【出願日】平成２２年６月１６日（２０１０．６．１６）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]