以下、本発明の実施の形態に係る情報提供システムについて、例示のために、図面を用いて説明する。
本例に係る情報提供システムは、概略、次のような技術である。ネットワークに接続されたコンピュータと音声出力装置から構成される「音響マーカー」から、人間の耳には聞こえにくい高音域の音声信号(以下、音響信号という)を出力する。その音響信号をデバイスに内蔵されたマイクロフォンへ入力させ、音響信号を解析した結果抽出された音響信号識別番号(ID)等を基にネットワーク経由でサーバーへ問い合わせることで、位置情報及び/又はその他の情報(いずれも、各音響マーカーから音響信号を受信したデバイスに対して提供したい情報であり、以下、位置情報等という)を取得させることができる。
なお、音響信号識別ID等と対応する位置情報等をデバイス内にキャッシュしておくことにより、音響信号を受信するだけで(サーバーへ問い合わせることなく)デバイスが位置情報等を求めることができるようにしてもよい。いずれにしても、音響信号を受信することにより、例えば、GPSが使えない屋内や地下街での測位(位置情報の取得)が可能になる。
音響信号は、例えば、15kHz〜22kHz台の可聴周波数の上限域(超音波音ともいう)を使用する。この音域の音声は、一般の人間には聞き取ることができない音域であり、周囲に気づかれることなく信号を出すことができる。当然ながら、写真や映像にも写らないため、運用環境の景観を損ねることもない。また、この周波数帯を使用することで、超音波用の専用機器ではなく、通常市販されるスピーカー等の音声出力装置を流用することができる。
本技術を適用したシステム(以下、音響マーカーシステムともいう)は、例えば、図1に示すように、サーバー10と、N個の音響マーカー20−1〜20−Nと、M個のデバイス(例えばスマートフォンやタブレット等の音声を利用できる携帯型情報機器)30−1〜30−Mとにより構成される。このうち、デバイスは、情報を利用する各ユーザにより使用されるものであるので、例えば、サーバーと音響マーカーとからなるシステム60を、情報提供システムと呼んでも構わない。サーバー10には、このサーバーを用いて情報提供システムの管理を行う管理者が使用するための管理端末40が、1つ又は複数、直接もしくはネットワーク経由で接続されていてもよい。
サーバー10は、各音響マーカー20が出力する音響信号が表す音響信号識別IDを記憶しており、ネットワーク(例えばインターネットプロトコル(IP)ネットワーク等)50により接続されるデバイス30から要求された情報についての提供を行うとともに、各デバイス30から収集したデバイス30における音響信号受信状況に関する情報に基づいて各音響マーカー20の故障の検出を行う。このサーバー10に接続された管理端末40において、各音響マーカー20の故障検出状況を表示することにより、情報提供システムの管理者は、ネットワークに接続されていない音響マーカー群についても、一元的に管理することが可能になる。
本例では、各音響マーカー20がサーバー10にネットワーク接続されておらず、各音響マーカー20が出力すべき音響信号を各音響マーカー20に設定する作業を人手により行うものとするが、音響マーカー群を設置する場所に敷設されている固定通信網を利用する等して各音響マーカー20をサーバー10にネットワーク接続し、サーバー10が各音響マーカー20への音響信号識別IDの割り振り及び出力指示等の管理を自動的に行うようにしてもよい。
デバイス30は、ユーザがデバイスを持ちながら移動するという形態で使用されるものであるため、ネットワーク50は、無線LANや携帯電話網等のネットワークであることが望ましい。
音響マーカー20は、指定された音響信号識別IDが含まれた音響信号を指定された音量で再生する。複数台(N台)の音響マーカー30を、同時に設置して動作させることができ、その数は、情報提供システムの運営者が適用したい情報サービスの内容によって定めればよい。
デバイス30は、音響信号を音声入力し、例えば、高速フーリエ変換(FFT)を用いて音響信号識別IDを抽出し、取得日時情報などと共にサーバーへ送って、位置情報等の提供を要求する。複数台(M台)のデバイス30を、同時に情報提供システム60に収容することができ、その数は、ネットワーク50が輻輳しない限り、サービスを利用したいユーザの数だけ増加させることが可能である。
本技術で用いる音響信号の基本構造は、例えば、次のようなものとする。音響マーカーの配置を管理するために、ロケーション、エリア、セルという概念を設け、それぞれには一意のIDが付与され識別できるように管理する。
最も小さい単位はセルであり、1つの音響マーカーを設置する単位とする。複数のセルを含む同一の空間をエリアと呼ぶ。エリアは、屋内の場合に通路や居室、共有スペースなどを指す。複数のエリアを包含する概念がロケーションであり、同一の建物などを指す。
ロケーションは、利用するアプリケーション側で明示的に指定することを想定しており、ロケーションIDを変更することでマルチテナント利用ができるようにすることが可能である。
1つの音響信号は、例えば、全部で12の正弦波を用いて構成し、変復調を行うことなく、1正弦波を1ビットとして定義している。各正弦波の間隔は、200Hzであり、高速フーリエ変換による解析の際の干渉を排除している。変復調を行わない理由としては、高速に信号を取得し、解析を行うためである。
本技術では、変復調を行わず、12ビット分の信号を一度に送信するため、例えば1分間に80m(1.33m/秒)歩行移動したとしても、音響マーカーから発出される音響信号をデバイス側で受信できる限りは、デバイスを保持している人の行動や動作に制約がかかることはない。
本例では、12ビットの音響信号は、エリアID、ユニークID、エラー訂正という3つの部分で構成される。12ビットの各々につき、ビットの値が1の場合、そのビットに対応する周波数の正弦波を出力し、ビットの値が0の場合、そのビットに対応する周波数の正弦波は出力しない。
エリアIDは、2進数で4ビット分(10進数で0〜15)を確保している。これにより、例えばある部屋から別の部屋へ移動したということがデバイス側で認識することができるようになる。
ユニークIDは、エリアID内でただ一つとなる識別番号であり、2進数で4ビット分(10進数で1〜15)を確保している。このエリアIDにユニークIDを加えた8ビットが基本的な音響信号識別IDであるが、自由空間を伝達されるため、信号の欠損などがあり得る。
このような事故を防止するため、エラー訂正を行うために4ビット分を付加し、エラー検出と訂正に使用する。このエラー検出及び訂正には、エラー検出訂正符号方式を使用しており、2ビットエラー検出、1ビットエラー訂正を採用している。
また、複数の音響信号を隣接する場所で使用することで混信が生じることを考慮し、超音波音の周波数帯域を、例えば4つの音域グループに分割して使用する。エリアID部は、共通の周波数帯域を使い、ユニークID部及びエラー訂正符号部は、音域グループ毎に別々の周波数帯域を使う。隣接するセルでは、同一の音域グループを使用しないように音響信号を割り当てる。ただし、音域グループAから音域グループDへ行く程、低い周波数帯となるため、人によっては聴覚で音響信号を感じる場合がある。
図2に、音域グループ別に、音響信号のビット列に、正弦波の周波数(kHz)を割り当てた一例を示す。音域欄は、音域をA〜Dの4つのグループに分割した例を示している。(1)を先頭ビットとして、(12)まで並べて音響信号として認識させる。
例えば、音域グループAの先頭ビットの周波数は22.0kHzであり、12ビット目は19.8kHzである。音域グループBの先頭ビット〜4ビット目までの周波数は音域グループAと共通であり、5ビット目は19.6kHzであり、12ビット目は18.2kHzである。このように、ユニークID及びエラー訂正符号部については、異なる音域グループ間で、使用する周波数が重複しないように、割り当てられる。
デバイスは、FFTの結果、当該周波数の成分を取得できた場合は、そのビットを1として認識し、周波数成分が取得できなかった場合は、そのビットを0として認識し、ビット配列を形成する。
図3は、音域グループ別に、音響信号識別IDをリストにした一例を示す。音域グループ毎に、エリアIDとユニークIDが指定される。一つの音域グループは16のエリアに分割され、エリアID毎に15のユニークIDが存在する。
超音波音の周波数をA〜Dの4つの音域グループに分けて、すべての音域グループを使用する場合、同一エリアID内で分割できるセルは、4音域グループ×15ユニークIDで最大60セルである。A〜Cの3つの音域グループを使用する場合は、3音域グループ×15ユニークIDで最大45セルを識別できる。A〜Bの2つの音域グループを使用する場合は、2音域グループ×15ユニークIDで最大30セルが識別可能であり、A音域グループのみを使用する場合は、最大15セルを識別することができる。
デバイスからサーバーへ情報を要求する際には、エリアID、ユニークID、音域グループの3つの要素を識別するために音響信号識別IDを指定する。
なお、音響信号のビット数は、12ビットでなくてもよいし、音響信号が、ユニークIDとエラー訂正という2つの部分(それぞれ何ビットでも構わない)で構成されても、ユニークIDのみで構成されても構わない。
図4に、サーバー10の内部構成例を示す。サーバー10は、音響マーカー20及び音響信号についての管理を行い、デバイス30による位置情報等要求への回答を伝達する機能を有するほか、デバイス30からの位置情報等要求もしくはこれとは別の通信により音響信号受信状況を示す情報を収集し、音響マーカー20の故障を検出する機能を有する。
サーバー10は、音響マーカーの管理と音響信号識別IDの付与を行うために、音響マーカー登録部100、音響信号識別ID選択部105を有する。また、音響信号識別IDを再選択するために、音響マーカー変更部120、音響信号識別ID再選択部125を備える。この選択もしくは再選択の結果は、音響マーカー管理テーブル150に記憶され、音響マーカー管理部110を介して管理端末40に表示される。これにより、本システムの管理者等が、各音響マーカーに割り振られた音響信号識別IDの音響信号を出力するように各音響マーカーを設定して回ることができる。
サーバー10はまた、音響マーカーとデバイス間の伝達範囲の調整を行うために、伝達範囲調整依頼取得部140と出力レベル変更部145を有する。この出力レベルの変更結果は、音響マーカー管理テーブル150に記憶され、音響マーカー管理部110を介して管理端末40に表示される。これにより、本システムの管理者等が、変更された出力レベルで音響信号を出力するように音響マーカーの設定をすることができる。
サーバー10はさらに、デバイスからの要求に応答し、位置情報等を伝達するために位置情報等要求取得部160、位置情報等要求確認部165、位置情報等抽出部170、位置情報等伝達部175を有する(これらをまとめて位置情報等処理部と呼ぶことがある)。
上記の機能を実現するために、サーバー10はデータベースを備え、音響マーカー管理テーブル150(図5)、音響信号管理テーブル130(図6)、付帯情報管理テーブル180(図7)を有する。サーバー10と各デバイス30との間はネットワーク50により、接続されており、相互通信が可能である。
図5に示される音響マーカー管理テーブル150は、例えば「最終取得日時」という項目を有しており、デバイス30による位置情報等の要求に応じて音響マーカー管理テーブル150に登録された位置情報が抽出されたときに、その抽出された位置情報に対応する最終取得日時として、そのときの日時が記入されるようになっている。そして、サーバー10の音響マーカー管理部110は、随時、この音響マーカー管理テーブルに記録された情報を解析し、各音響マーカーの故障状態を管理端末40に表示する。
デバイス30から位置情報の要求があったということは、その位置情報に対応する音響信号識別IDの音響信号を出力する音響マーカーは、その時点で正常に動作していることを意味するとして、本システムを運用することができる。各音響マーカーの音響信号を受信できる範囲に、多数のユーザのデバイス30が出入りするとすれば、それぞれのユーザのデバイス30からの位置情報等要求の受信状況を、サーバー10において解析すれば、各音響マーカーが正常に動作しているか故障しているかを推定することが可能である。
つまり、各デバイス30は、音響マーカーからの音響信号を受信すると、サーバー10へ、少なくとも音響信号識別IDを含むメッセージを送信する。このメッセージは、位置情報等を要求するメッセージそのものでもよいし、それとは別に、音響信号の受信状況を示すメッセージをサーバー10に送るようにしてもよい。サーバー10は、音響マーカー管理テーブル150において、音響信号識別IDと対応付いている音響マーカーのエントリに、デバイスからのメッセージを受信した時刻もしくはメッセージに含まれている時刻の情報を記録する。
この時刻情報の記録は、特定のデバイスからのメッセージの受信についてのみ行ってもよいし、どのデバイスからのメッセージかを区別することなく全てについて時刻情報を記録してもよい。 また、メッセージを受信する都度、時刻情報を更新(上書き)して、「最終取得日時」により故障を判断してもよいし、複数の受信メッセージから生成された時刻情報の履歴を記録して、所定のパターンと比較することにより故障を判断してもよい。
また、本例では、音響マーカー管理テーブル150に、メッセージ受信に係る時刻情報等の故障検出に用いる情報を記録しているが、音響信号識別ID(もしくはそれに対応する音響マーカーID)と故障検出に用いる情報とを、音響マーカー管理テーブル150とは別のテーブルとして記録するようにしても構わない。
デバイスからのメッセージ受信がないことをもって音響マーカーの故障を判断する本例の方式では、デバイスを所持してその音響マーカーの音響信号が届く範囲を通過したユーザがいなかったのか、そのようなユーザがいたのにデバイスがサーバーへメッセージを送信してこなかった(すなわち、音響マーカーが故障していて音響信号がデバイスに受信されなかった)のかを、例えば次のように評価する。
簡単な例では、一定期間、デバイスからのメッセージ受信がないものを、故障と判断する。その期間を、各音響マーカー(頻繁に利用者が訪れるところに設置してあるか、稀なところであるか)によって異なるように決めておいてもよい。
より多くの情報を考慮する例では、同じ店舗や同じフロアの中に設置されている別の音響マーカーについてのメッセージ受信の状況(あるいはその他の手段で得られる利用者の数等の情報)から、多くの利用者が訪れているはずなのに、デバイスからの対応するメッセージ受信がないものを、故障と判断する。
より多くの情報を考慮する他の例では、歩行者自律航法(PDR)等の測位技術で、デバイスが位置している場所をある程度特定し、その特定した場所がある音響マーカーの音響信号が届く範囲にあるはずなのに、デバイスからの対応するメッセージ受信がないものを、故障と判断する。
また、あるべきデバイスからのメッセージ受信がないという完全な故障に陥る前に、デバイスに音響信号は受信されサーバーへのメッセージ送信もできているが、デバイスが音響信号から音響信号識別IDを取り出す際にエラー訂正を多く要していたり、デバイスが受信する音響信号の大きさが通常範囲を超えて変化していたりすることがあり得る。
そのような場合も故障として検出して管理端末40に表示するため、これらエラー訂正の情報や音量の情報も、デバイスからサーバーへのメッセージに含めるようにして、サーバーにおいて、故障の可能性が大きい音響マーカーとして判断するようにしてもよい。これらの付加的な情報は、故障の判断の精度を高める方向で利用してもよいし、まだ完全に故障していないが故障の予想される音響マーカーについても本システムの管理者等の注意を促す方向で利用してもよい。
デバイスとして、例えば、スマートフォンを用いる場合、スマートフォンが本システムを利用する(音響信号を処理して位置情報等をサーバーへ要求し受信する)ことができるように、アプリケーションをダウンロードさせるとよい。上述したエラー訂正の情報及び/又は音量の情報等を、デバイスからサーバーへのメッセージに含める場合には、そのための機能も、スマートフォンにダウンロードするアプリケーションに含ませておけばよい。
図8は、サーバー10が、音響マーカー20−1〜20−Nを管理し、各々に音響信号識別IDを付与するための処理の流れの一例を示す。
まず、サーバーの音響マーカー登録部100にて、音響マーカー管理テーブル150に対して、音響マーカーのID、名称、エリアID、エリア内のX,Y座標(さらにZ座標があってもよい)等の登録を行う(800)。
そして、音響マーカーの登録後、音響信号識別ID選択部105にて、音響信号管理テーブル130を参照し、指定されたエリアIDが属する未使用の音響信号識別IDが存在するかを確認する(805)。未使用の音響信号識別IDが存在する場合は、未使用のユニークIDが存在するかを確認する(810)。
未使用のユニークIDが存在する場合にはその音響信号識別IDを候補として抽出し、候補の中から1つのIDを選択する(815)。この際、音域グループは、隣接する音響マーカーの音域グループと同一にならないように自動的に選択してもよいし、登録者(本システムの管理者等)に任意に選択させるようにしてもよい。
音響信号識別ID選択部105は、続いて有効期限情報を決定し(820)、音響信号管理テーブル130に対して、使用中フラグを0から1に変更し、音響マーカーID及び有効期限を登録する。
未使用の音響信号識別IDが存在しない場合、あるいは未使用の音響信号識別IDが存在するが、当該エリア内のユニークIDが存在しない場合は、エラーを返す(840)。
そして、本システムの管理者等は、音響マーカー20−Kに対し、出力すべき音響信号の音響信号識別ID及び出力レベルを設定する。後述するようにサーバーと各音響マーカーがネットワーク接続される環境の場合は、サーバー10が、音響マーカー20−Kに対し、音響信号識別ID及び出力レベルを指示してもよい(830)。
図9は、サーバー10が、指定された音響マーカーに対して、音響信号識別IDを付与しなおすための処理の流れの一例を示す。例えば、ある音響信号識別IDの有効期限が過ぎた後に、同じ音響マーカーから別の音響信号識別IDを流したい場合等に、この再割り振りの処理が行われる。
まず、サーバーの音響マーカー変更部120は、本システムの管理者やサーバーで動作している該当サービスのプログラム等から、音響マーカー変更依頼を受け取り(900)、当該音響マーカー及び音響信号識別IDが登録済みかどうかを確認する(905)。音響マーカー変更依頼には、音響マーカーのIDと音響信号識別IDと隣接する音響マーカーの音域グループ情報が含まれている。
音響信号識別ID再選択部125は、現在選択されている音響信号識別IDと同じエリアIDに属し、かつ音域グループが空きであり(910)ユニークIDが未使用である(915)音響信号識別ID群を抽出し、その中から1つのIDを選択する(920)。この際、音域グループは、隣接する音響マーカーの音域グループと同一にならないように自動的に選択してもよいし、登録者(本システムの管理者等)に任意に選択させるようにしてもよい。
音響信号識別ID再選択部125は、続いて改めて有効期限情報を決定し(925)、音響信号管理テーブル130に対して、新しく選択された音響信号識別IDのレコードについて、使用中フラグを0から1へ変更を行い、音響マーカーID及び有効期限を登録する。さらに、これまで割り振っていた音響信号識別IDのレコードの使用中フラグを1から0に変更し、音響マーカーID及び有効期限を削除した上でレコードの更新を行う(930)。また、変更依頼の対象となっている音響マーカーまたは音響信号識別IDが存在しない場合、あるいは新たに音響信号識別IDを割り振ることができない場合は、エラーを返す(950)。
そして、本システムの管理者等は、音響マーカー20−Jに対し、出力すべき音響信号の音響信号識別ID及び出力レベルを設定する。後述するようにサーバーと各音響マーカーがネットワーク接続される環境の場合は、サーバー10が、音響マーカー20−Jに対し、音響信号識別ID及び出力レベルを指示してもよい(940)。
図10は、サーバー10が、各音響マーカーの音響信号の出力レベル(伝達範囲)を調整するための処理の一例を示す。この伝達範囲の調整は、各々の音響マーカー20−1〜20−Nからの音響信号が伝達されることが望まれる位置にいて音響信号をモニターする各々のデバイス30−1〜30−Nからの情報に基づいて、行うことができる。1つの音響マーカーのモニター用デバイスが複数分散してあってもよく(例えば、30−Cが3台、30−Eが5台ある等)、1つのデバイスが隣接する複数のセルの音響マーカーからの音響信号をモニターするようにしてもよい。
まず、サーバー10の伝達範囲調整依頼取得部140は、デバイス30からネットワーク50を通じて、伝達範囲調整依頼を取得する(1000)。当該依頼には、音響マーカーのIDと出力の増減についての情報が含まれる。
出力レベル変更部145では、音響マーカー管理テーブル150を参照して、受け取った音響マーカーのIDが正しいかどうか調べ(1005)、当該音響マーカーが存在する場合は、受け取った依頼に従って(1010)出力レベルを増加(1015)又は減少(1020)させ、音響マーカー管理テーブル150の当該音響マーカーのレコードに含まれる出力レベルを更新する(1025)。本システムの管理者等は、音響マーカー20−Kに対し、更新された出力レベルを設定する。後述するようにサーバーと各音響マーカーがネットワーク接続される環境の場合は、サーバー10が、音響マーカー20−Kへ指示を行ってもよい。
さらに、出力レベル変更部145は、音響マーカー20−Kにおける変更結果を取得(1040)し、依頼元のデバイス30−Kへネットワーク50を通じて、結果を通知(1060)してもよい。なお、受け取った音響マーカーのIDが正しくない場合は、エラーを返す(1050)。
図11は、サーバー10が、デバイスからの要求に応じて位置情報等を提供するための処理の一例を示す。
サーバー10の位置情報等要求取得部160は、それぞれのデバイス30からネットワーク50を通じて位置情報等の取得要求を受け取る(1100)。当該要求には、音響信号識別IDが含まれている。
位置情報等要求確認部165は、音響信号管理テーブル130を参照し、受け取った要求に含まれる音響信号識別IDの有効性を確認する(1105)。音響信号識別IDが存在し、使用中フラグが1の場合は、受け取った要求に係る日時が、当該音響信号識別IDのレコードの有効期限内かどうかを判断する(1110)。要求に係る日時は、デバイスが要求に含ませた音響信号受信日時でもよいが、サーバーが要求を受け取った日時とする方が安全性は高い。
要求に係る日時が有効期限内である場合は、音響信号管理テーブル130に示される音響マーカーのレコードを、音響マーカー管理テーブル150から抽出する。そして、位置情報等抽出部170は、抽出された音響マーカーのレコードから、位置情報(例えば、エリアIDとX,Y座標)を抽出する(1120)。X,Y座標をエリア内の座標系で定義している場合はエリアIDとともに抽出するが、X,Y座標(もしくはX,Y,Z座標)のみから位置が一意に特定できる場合には座標のみを抽出してもよい。
位置情報等抽出部170はまた、付帯情報管理テーブル180において、抽出された位置情報に付帯情報が関連づけされている場合は(1125)、付帯情報を抽出する(1130)。付帯情報の内容により、その位置に関連した各種の情報サービスを提供することができる(各種応用例を後述する)。提供される情報自体を付帯情報としてもよいし、提供される情報が置かれているURLを付帯情報としてもよい。
位置情報等伝達部175は、抽出された位置情報(エリアID、座標)及び/又は付帯情報を、要求元のデバイス30−Iへネットワーク50を通じて伝達する(1150)。なお、受け取った要求の有効性が確認できなかった場合は、エラーが返され(1040)、要求元のデバイスにも要求処理不可の通知が返される。
図12には、各音響マーカー20の内部構成例を示す。音響マーカー20は、音響信号の出力を行う機能を有する。
音響マーカー20は、音響信号の出力を行うために、音響信号識別ID入力部200、音響信号ファイル選択部210、音響信号出力管理部220、スピーカー部230を有する。スピーカー部230は、概ね15kHz〜22kHzの高音域の信号を出力できるものである。音響マーカー20はまた、出力レベル調整を実施するため、出力レベル調整指示入力部240、音響信号識別ID確認部250を備える。
なお、図25に示すように、各音響マーカー20とサーバー10との間をネットワーク60で接続して、相互通信可能としてもよい。ネットワーク60を利用しない場合は、管理者が音響マーカー20自体に音響信号識別IDや出力レベル等を個別に指示するようにすればよい。
図13は、音響マーカー20が、音響信号を出力するための処理の流れの一例を示す。
音響マーカー20の音響信号識別ID入力部200は、管理者から又はネットワーク60を通じてサーバー10から、音響信号識別ID及び出力レベル、出力又は停止指示を入力する(1300)。
音響信号ファイル選択部210は、予め記憶してある音響信号ファイルの中から、受け取った音響信号識別IDに対応するファイルを選択する(1305)。ただし、受け取った音響信号識別ID情報を基に、音響信号ファイルを新たに作成してもよい。
音響信号出力管理部220は、受け取った指示に停止指示が含まれていない場合には(1310)、指示された出力レベルを基に(1315)、選択した音響信号ファイルを再生し(1320)、スピーカー部230から出力を行う。受け取った指示に停止指示が含まれている場合には、現在再生している音響信号ファイルの再生を停止する(1330)。そして、指示を処理した結果を、管理者に分かるように提示するか、サーバー10に対して通知する(1340)。
上述したように、サーバー10は、デバイス30からネットワーク50経由で取得した出力レベル調整依頼に基づいて、音響マーカー20の出力レベル調整を指示する。
このため、音響マーカー20−Kから音響信号を取得させたい位置(例えば、距離1mなど)にデバイス30−Kを設置し、音響信号の検出を試みる。このとき信号が検出できなければ、デバイス30−Kはサーバー10に対して、出力レベル増加調整を依頼する。この出力レベル増加依頼は、音響信号が検出できるようになるまで繰り返すことができる。
次に、例えば、音響信号の伝達限界(そこから先は音響信号が伝達されるべきでない)位置にデバイスを移動させ、音響信号の検出を試みる。このとき信号が検出されるならば、デバイス30−Kはサーバー10に対して、出力レベルの減少依頼を行う。この出力レベル減少依頼は、音響信号が検出できなくなるまで繰り返すことができる。
なお、上記の増加依頼、減少依頼は、デバイスの使用者が手動操作で行うことは勿論、デバイス自体が自動操作で行うこともできる。
図14は、音響マーカー20が、音響信号の出力レベルを調整するための処理の流れの一例を示す。
音響マーカー20の出力レベル調整指示入力部240は、管理者から又はネットワーク60を通じてサーバー10から、出力レベル調整指示を入力する(1400)。
音響信号識別ID確認部250は、受け取った指示に含まれる音響信号識別IDが使用中の識別IDと同じかどうかを確認する(1405)。異なる場合は、エラーを返す(1450)。
音響信号識別IDが適切に指示されている場合は、当該識別IDの音響信号ファイルがすでに選択されている場合を除いて(1410)、指示された音響信号ファイルを音響信号ファイル選択部210にて選択する(1415)。
そして、音響信号出力管理部220は、現在の出力レベルと指示された出力レベルを比較し(1420)、出力レベルの増加(1425)または減少(1430)を施して、音響信号ファイルを再生し(1440)、スピーカー部230から出力を行い、指示を処理した結果を、管理者に分かるように提示するか、サーバー10に対して通知する(1460)。
図15には、各デバイス30の内部構成例を示す。デバイス30は、サーバー10と連携し、音響マーカー20から取得した音響信号を基に位置情報(例えば、エリア内の2次元又は3次元座標)等を取得する機能を有する。
デバイス30は、通信機能を有する可搬型端末(例えば、スマートフォン)であり、音響信号を受信して解析するために、音響信号入力部300、音響信号抽出部310、音域グループ検出部320、音響信号識別ID取得部330を有し(これらをまとめて音響信号処理部と呼ぶことがある)、ネットワーク50を通してサーバー10から音響信号識別IDに対応する位置情報等を取得するために、位置情報等要求部340、位置情報等取得部350を有する。また、出力レベル調整を実施するため、出力レベル調整依頼部370を備えてもよい。
なお、デバイス30は、サーバー10との間をネットワーク50で接続しており、相互通信が可能である。
図16は、デバイス30が位置情報等を取得するための処理の流れの一例を示す。
デバイス30の音響信号入力部300は、自由空間を経由して音響マーカー20が発するアナログの音響信号を入力する(1600)。
音響信号が入力された場合(1605)、音響信号抽出部310は、受信されたアナログ信号を、例えば44.1kHzのサンプリングレートを用いてデジタルサンプリングし(1610)、デジタル信号への変換を行う。続いて、高速フーリエ変換を実施し(1615)、周波数成分を抽出する。抽出した周波数成分は、図2に基づいて、ビット配列に置き換える。
周波数成分のうち最も高い22.0kHzをエリアID部の先頭ビットとし、2ビット目を21.8kHz、3ビット目を21.6kHz、4ビット目を21.4kHzする。
次に、音域グループAのユニークID部の先頭ビットを21.2kHzとし、2ビット目を21.0kHz、3ビット目を20.8kHz、4ビット目を20.6kHzとする。続いて、同音域グループAのエラー訂正符号部の先頭ビットを20.4kHzとし、2ビット目を20.2kHz、3ビット目を20.0kHz、4ビット目を19.8kHzとする。
いずれのビットも、当該周波数成分が存在する場合は、ビットの値を1とし、周波数成分が存在しない場合はビットの値を0とする。
同様に、音域グループBのユニークID部の先頭ビットを19.6kHzとし、2ビット目を19.4kHz、3ビット目を19.2kHz、4ビット目を19.0kHzとする。続いて、同音域グループBのエラー訂正符号部の先頭ビットを18.8kHzとし、2ビット目を18.6kHz、3ビット目を18.4kHz、4ビット目を18.2kHzとする。
同様に、音域グループCのユニークID部の先頭ビットを18.0kHzとし、2ビット目を17.8kHz、3ビット目を17.6kHz、4ビット目を17.4kHzとする。続いて、同音域グループCのエラー訂正符号部の先頭ビットを17.2kHzとし、2ビット目を17.0kHz、3ビット目を16.8kHz、4ビット目を16.6kHzとする。
同様に、音域グループDのユニークID部の先頭ビットを16.4kHzとし、2ビット目を16.2kHz、3ビット目を16.0kHz、4ビット目を15.8kHzとする。続いて、同音域グループDのエラー訂正符号部の先頭ビットを15.6kHzとし、2ビット目を15.4kHz、3ビット目を15.2kHz、4ビット目を15.0kHzとする。
この変換により、音域グループA〜Dのビット配列が生成され、A〜Dの配列のプレフィクスとして、エリアID部を追加することで、4種類の音響信号のビット配列(エリアID部+ユニークID部+エラー訂正符号部=12ビット)が完成する。
このようにして、高速フーリエ変換で得られた周波数成分から、音響信号のビット配列と、どの音域グループの音響信号であるかの情報を得ることができるから、デバイス30の音域グループ検出部320は、音域グループを検出する(1620)。
音響信号識別ID取得部330は、検出された音域グループと上記12ビットのビット配列とから、音響信号識別IDを取得する(1625)。このとき、得られた12ビットのビット配列の一部であるエリアID部とユニークID部とからエラー訂正符号を計算し、得られた12ビットのビット配列の残りの部分であるエラー訂正部のビット配列と比較することにより、エリアID部及びユニークID部に関してエラー検出及びエラー訂正を実施する(エラー訂正方法は後述する)(1630)。
エラー訂正後に音響信号識別IDが正常に得られたことが確認できた場合(1635)、デバイス30の位置情報等要求部340は、ネットワーク50を通じてサーバー10へ位置情報等の要求を行う(1640)。サーバー10へ送付される要求は、得られた音響信号識別ID(音域グループ+エリアID+ユニークID)を含む。
デバイス30の位置情報等取得部350は、送付された要求への応答として、ネットワーク50を通じてサーバー10から位置情報等を取得する(1650)。デバイス30がサーバー10から受け取る応答には、位置情報及び/又は付帯情報、もしくは要求処理不可という結果の通知が含まれる。位置情報としては、エリアIDはデバイス30内で得られるため、少なくともエリア内の2次元又は3次元座標情報をサーバー10から送ることになる。
図17には、エラー訂正方法の一例を示す。得られた12ビットのビット配列の先頭から8ビット目までのデータ部のビット値をD1、D2、D3、D4、D5、D6、D7、D8とし、9〜12ビット目までのエラー訂正部のビット値をH1、H2、H3、H4とした場合、検算するためのエラー検出・訂正符号をH1'、H2'、H3'、H4'とするとき、
H1'=D1 XOR D2 XOR D3
H2'=D4 XOR D5 XOR D6
H3'=D1 XOR D4 XOR D7
H4'=D2 XOR D5 XOR D8
となる。
例えば、得られた12ビットのビット配列の後ろの4ビット(エラー訂正部)のH1、H3と検算したビットH1'、H3'とが、H1≠H1'かつH3≠H3'の場合は、D1がエラーということになり、D1のビットを反転させることでエラーを訂正できる。同様に図17に従って、エラーが検出できた場合は、当該ビットを反転させる。
図17に示されていないパターンの場合は、エラーを訂正することができないため、そのままエラーとして解釈する。つまり、正常な音響信号識別IDが得られなかったとして、エラーを返す(1660)。
エラー訂正が行われたあとのビット配列(エリアID+ユニークID)を2進数から10進数に変換する。検出された音域グループ名(A〜D)に10進数のエリアID部とユニークID部とを追加したもの(例えば、「A−0−1」、「B−9−14」等)を、音響信号識別IDとして、サーバー10への位置情報等の要求時に使用してもよい。
なお、上述したデバイス30は、音響マーカー20から受信した音響信号に含まれている音響信号識別IDに基づいて、サーバー10へ要求を送ることにより、位置情報及び/又は付帯情報を取得しているが、音響マーカー20から受信した音響信号に含まれているエリアIDについては、サーバー10へ問い合わせなくとも、デバイス30内で今そのデバイスがいるエリアを識別することが可能である。
つまり、デバイス30は、エリア内での詳細な位置を知るには、サーバー10へ問い合わせることになるが、どのエリアにいるかという大まかな位置については、音響信号を受信するだけで知ることができる。よって、例えば、デバイス30が検出したエリアIDを基に、エリアによって異なるアプリケーションプログラムをデバイス30において起動するような応用も、可能である。
また、上述したシステムの例では、音響マーカーを管理するサーバーと、デバイスに位置情報等を取得させるサーバーと、音響マーカーの故障を判断するサーバーとを、同じサーバー10が兼ねているが、別々のサーバーにより実現するようにしてもよい。また、デバイスに位置情報等を取得させるサーバーを、エリア毎に設けておき、デバイス30は、音響信号識別IDの中のエリアIDによって特定される情報提供サーバーに対して、音響信号識別IDの中の音域グループ名とユニークID部とを送ることにより、位置情報等を要求するようにしてもよい。
以下には、図18〜25を参照して、サーバーにおいて音響マーカーの故障を検出する例を説明する。なお、音響マーカーが音響信号に音響信号識別IDの情報を含ませる方式や符号化の方式等は、上述した図2や図3等に示される例に限定されることはなく、どのような方式であっても、以下に述べる構成や動作を適用することができる。例えば、無線通信等で使われるデジタル変調方式やスペクトラム拡散等を用いて音響信号に情報を含ませる方式の音響マーカー(音響信号出力装置)に対しても、同様に本実施形態のような遠隔からの管理を行うことができる。
図18は、音響マーカー20から音響信号を受信したときのデバイス30の位置情報の取得手順と、サーバー10での音響マーカーの管理手順とを説明する図である。
まず、デバイス30が、音響マーカー20からの音響信号を受信する。デバイス30の音響信号処理部は、受信した音響信号を解析し、音響信号識別IDとして認識する。次に、音響信号識別IDに対応する位置情報及び/又は付帯情報(位置情報等)を取得するために、位置問合せメッセージとして、音響信号識別IDをサーバー10に送信する。
音響信号識別IDを受信したサーバー10の位置情報等処理部は、音響マーカー管理テーブル(と必要に応じて付帯情報テーブル)から、音響信号識別IDをキーとして位置情報等を検索する。サーバー10の位置情報等処理部は、音響マーカーの管理のために、音響マーカー管理テーブル(又は別途設けられた故障検出用テーブル)において、いま対応する位置情報等が取得された音響信号識別IDのエントリに、最終取得日時として、現在時刻を記入する。これにより、テーブル中の最終取得日時の項目は、該当音響信号識別IDについて最後にデバイスから問合せがあった日時となる。
そして、サーバー10の位置情報等処理部は、音響マーカー管理テーブル等から取得した位置情報等を、音響信号識別ID(もしくは位置問合せメッセージID)とともに、デバイス30へ位置情報応答メッセージとして送信する。この位置情報等を受信したデバイス30は、例えば、自装置が存在する屋内の位置を知ることができる。
上記の位置情報等の処理とは独立して、サーバー10の音響マーカー管理部では、音響マーカー管理テーブル(又は別途設けられた故障検出用テーブル)を用いて、音響マーカーの故障状況の管理を行う。サーバー10の音響マーカー管理部は、一定間隔で、音響マーカー管理テーブル(又は別途設けられた故障検出用テーブル)を確認し、最終取得日時の項目がZ時間以上となっているエントリを拾い出す。
Zは、例えば、24時間、48時間等の間、音響信号が聞こえたというデバイスが現れないときに、音響マーカーが故障だと判断するための時間である。多くのユーザが利用している場所に設置されている音響マーカーは、よく利用されるため、テーブル中の最終取得日時が頻繁に更新され、あまり利用されない場所に設置されている音響マーカーは、テーブル中の最終取得日時があまり更新されない。Zの値は、これらの状況を考え、適切な値を設定する。Zの値は、すべての場合に同じではなく、場所によって値を変えてもよいし、時間帯や曜日によって値を変えてもよい。
テーブル中の最終取得日時から現在時刻までZ時間以上経過しているエントリを拾い出したら、そのエントリの音響信号識別IDは、一定時間使われておらず、音響マーカーが故障している可能性が高い。これらの音響マーカーを、管理端末40に表示する。表示は、場所がわかりやすいように地図上に表示してもよいし、音響マーカーを管理している店舗毎に表示してもよい。管理端末40において管理のためのアプリケーションを起動することなく、メール等で、故障した可能性のある音響マーカーを伝えるようにしてもよい。
音響マーカーの故障は、上記の例では、音響マーカー1つずつの情報に基づいて推定しているが、ある店舗の中に複数の音響マーカーが置いてある場合には、同一店舗の音響マーカーの音響信号について位置問合せメッセージが受信された場合に、同一店舗の他の音響マーカーの音響信号について位置問合せメッセージが受信されない場合に、その受信されない音響マーカーを故障と判断するようにしてもよい。
また、音響マーカーを設置する場所の特性を考慮し、昼間に利用者が多く集まり、問合せ数が多い場合には、昼間の間を上記の故障推定の対象期間としてもよい。これにより、夜間、利用者の少ないときには、問合せ数が少ないために故障でないものを故障と判断してしまうことを避けることができる。また、対象となる時間を変更することで、故障推定の正確さを向上させることができる。
故障の判断を、過去の問合せ数のパターンと比較して行ってもよい。時間帯、曜日、季節、イベント開催等によって音響マーカーの前を利用者が通る数のパターンが類似しており、問合せ数が類似することがある。これらの類似性は、過去の問合せ数のパターンを見ると分かる。例えば、日曜日の昼間にある場所に利用者が多く存在し、問合せ数が多い音響マーカーがあるとすると、日曜日の昼間に問合せが受信されない場合には、音響マーカーが故障したと推定することができる。
図19は、図18に加えて、デバイスで音響信号識別IDを抽出した際のエラー情報を利用する例を説明する図である。
デバイス30では、音響マーカー20から受信した音響信号から音響信号識別IDを抽出するが、ここで受信する音響信号は、雑音等によりエラーが発生する可能性があるので、エラー訂正やエラー検出できるような符号を用いて、音響信号識別IDが符号化されている。例えば、拡張ハミング符号を用いると、1ビットのエラー訂正、2ビットのエラー検出ができる。
拡張ハミング符号の例では、デバイス30は、受信した音響信号が、1ビットのエラー誤りを含んでいた場合には、エラー訂正することができる。この場合には、正しい音響信号識別IDに訂正し、位置問合せメッセージに、音響信号識別IDと、1ビットのエラー訂正をしたことを示す情報とを含めて、サーバー10へ送信する。
この位置問合せメッセージを受信したサーバー10の位置情報等処理部は、図18の例と同じように、受信した音響信号識別IDをキーにして、音響マーカー管理テーブル等から位置情報等を取得する。その際、該当するエントリに、最終取得日時として現在時刻を記入するとともに、受信したエラー情報を記録する。そして、位置情報等を位置情報応答メッセージとして、サーバー10からデバイス30に位置情報応答メッセージとして送信する。
サーバー10の音響マーカー管理部は、音響マーカー管理テーブルの最終取得日時とエラー情報に基づいて、故障している可能性の高い音響マーカーを表示する。例えば、最終取得日時から現在までZ時間以上経過しているエントリと、エラー訂正がY%以上となるエントリとを抽出し、これらのエントリの音響信号識別IDが割り振られている音響マーカーを、故障しているものとして検出する。これにより、音響信号の問合せが一定時間以上受信されていない音響マーカーと、一定割合以上のエラー訂正が行われている音響マーカーとが、管理端末40に表示される。
Y%以上のエラー訂正かどうかは、例えば、同一音響マーカーにおいて、一定期間(例えば、24時間)に問合せのあった数を総数として、この中でエラー訂正を行った問合せの数の割合を求めることによりエラー訂正の割合が計算できる。エラー訂正されている音響マーカーは、現状では利用できているが、音響マーカーが故障する可能性があるか、音響マーカーの周辺環境により、音響マーカーからデバイスへの音響信号が正確に伝わっていないことが考えられる。このような情報を管理端末40に表示することにより、音響マーカーの故障状態や周辺環境の悪化を通知することができる。
ここでは、音響信号のエラー訂正に基づいて故障状況を推測したが、音響信号の音の大きさを利用して、同一音響マーカーで音の大きさが変わったときに故障を推測するようにしてもよい。
このように、デバイスからエラー情報等の付加的な情報を収集することにより、サーバー側で集中管理するようにすると、故障の可能性のある音響マーカーの交換や周辺環境の悪化した音響マーカーの点検を効率的に実施することが可能になる。
以上の例のように、音響マーカー20からの音響信号でデバイス30の位置を求める方式は、歩行者自律航法(PDR)等の他の測位技術と組み合わせて使うことができる。PDRは、デバイス30に内蔵されているセンサーを使うことにより、自立的に場所を推定する技術である。例えば、加速度センサーにより距離を推定し、地磁気センサーにより方向を推定することができる。デバイス30を他のセンサーが内蔵されているものにして、PDR以外の測位技術を組み合わせることも可能である。
図20(デバイス側)及び図21(サーバー側)を参照して、組み合わせの動作例を説明する。デバイス30で、センサーによる移動を検知すると、PDR等により位置を推定する。推定結果を、デバイス30内で、位置情報リストに記録する。位置情報リストは、図21の右下隅に示すように、位置情報と日時とが記録されるものである。
デバイス30は、他方で、音響マーカーから音響信号を受信すると、音響信号識別IDを抽出し、サーバー10へ位置問合せメッセージを送信する。このとき、音響信号識別IDに加えて、PDR等を用いて記録した位置情報リストを、サーバー10へ送信する。
この位置問合せメッセージを受信したサーバー10は、音響信号識別IDをキーに音響マーカー管理テーブル等から位置情報等を検索する。そして、音響マーカー管理テーブルの該当エントリの最終取得日時を現在時刻に更新し、受信した位置情報リストをサーバー10内に保存する。サーバーに保存される位置情報リストの形式は、デバイスで記録されサーバーへ送信される位置情報リストの形式と同様であるが、サーバーに保存される位置情報リストは、複数のデバイスからの位置情報リストを集積したものになる。
サーバー10の音響マーカー管理部では、音響マーカー管理テーブルとサーバー内の位置情報リストとを比較して、故障音響マーカーを検出する。例えば、音響マーカー管理テーブルの位置情報と位置情報リストの位置情報とが同一であるエントリ同士を比較し、音響マーカー管理テーブルの最終取得日時が位置情報リストの時刻よりも古い場合には、その音響マーカーからの音響信号がデバイスに受信されない状況である可能性が高いと判断し、故障音響マーカーとして表示する。1つのデバイスがその音響マーカーからの音響信号を受信しなかった場合に故障として検出してもよいが、一定数以上のデバイスがその音響マーカーからの音響信号を受信しなかった場合に故障として検出するようにしてもよい。
なお、図20及び図21のPDR等を利用する例と、図19のエラー訂正を利用する例とは、デバイス30からPDR等の情報とエラー訂正の情報との両方をサーバー10に送信することにより、組み合わせて適用することも可能である。
図22は、デバイス30が、音響マーカー20からの音響信号を受信する都度、サーバー10へ位置問合せを行うのではなく、サーバーにある情報の一部(例えば、一度利用した音響信号識別IDと位置情報等との対応等)をデバイス内にキャッシュ360として保存しておき、このキャッシュを利用して位置情報等を取得する機能を有する場合の、デバイス30の構成を示している。
キャッシュを利用することにより、デバイス30は、サーバー10に問い合わせることなく位置情報等を取得できるため、ネットワーク50の速度が遅いとき等にデバイス30のユーザへの表示速度等を早くしたり、通信を少なくしてスマートフォンのレスポンスを早くしたりすることができる。また、通信量ひいてはバッテリの消費量を削減することも可能になる。
但し、キャッシュの情報のみを利用して位置情報等を取得すると、デバイス30が正常に音響マーカー20からの音響信号を受信していることをサーバー10へ伝えることができなくなる。そこで、図22のデバイス30は、位置情報等要求部340により位置問合せメッセージを送信せずに、キャッシュ360により位置情報等を取得したときには、その位置情報を利用したこと(すなわち対応する音響信号を受信したこと)を、位置情報等利用記録部380によりデバイス30内で記録しておき、この利用記録を、適切なタイミングで(例えば、定期的に等)、位置情報等利用報告部390によりサーバー10へ送信する。
この利用記録をデバイス30から受信したサーバー10は、デバイス30から位置問合せメッセージを受信しなかった場合でも、デバイス30が音響マーカー20からの音響信号を受信したことを知ることができるため、音響マーカーの故障の精度の良い検出が可能になる。それだけでなく、例えば、音響信号すなわち位置情報等を利用した回数でユーザに課金する場合に、キャッシュによってユーザの利便性を向上させながら(キャッシュを利用するとサーバーへの位置問合せ回数では正確な課金ができなくなるところ)、サーバーにおいてユーザの位置情報等の利用回数を精度良く把握することが可能になる。
図23(デバイス側)及び図24(サーバー側)を参照して、キャッシュを利用する場合の動作例を説明する。デバイス30は、音響マーカー20からの音響信号を受信して音響信号識別IDを抽出すると、音響信号識別IDと位置情報等との対応を有するキャッシュ360を参照して、そこに有効な位置情報等が存在しなかった場合に、ネットワーク経由でサーバー10へ位置問合せメッセージを送信する。
なお、このキャッシュ360の利用には、毎回、キャッシュの情報が最新のものかサーバーに問い合わせして確認する方法と、一定時間、キャッシュの情報のみを利用してサーバーに問い合わせしない方法とがある。前者の方法を採る場合は、図18〜21で説明した例が適用できるが、後者の方法を採る場合は、サーバーへ何の情報も送信しないので、図22〜24の例を適用する。なお、前者の方法を採る場合であっても、位置問合せメッセージをサーバーでの故障検出のために流用するのではなく、図22〜24の例のように、故障検出のためのメッセージを別途デバイスから送信するようにしてもよい。
キャッシュ360には、音響信号識別IDと位置情報等に加えて、最終利用日時とキャッシュ利用回数を記録するようになっている。デバイス30は、音響マーカー20からの音響信号を受信して音響信号識別IDを抽出すると、音響信号識別IDと位置情報等との対応を有するキャッシュ360を参照して、そこに有効な位置情報等が存在する場合には、キャッシュから位置情報等を読み出して、最終利用時刻として現在時刻を記入(上書き)し、利用回数を1つ増加させる。この利用回数により、デバイスがキャッシュから位置情報等を取得した回数が分かる。
ここに記録された音響信号識別IDと最終利用時刻と、必要に応じて利用回数とを、デバイス30からサーバー10へ送信することにより、サーバー10では、キャッシュ機能なしのデバイスからの位置問合せメッセージによって記録される最終取得日時と、場合によっては取得日時の履歴(又は取得回数)と同等の情報を、キャッシュ機能ありのデバイスから収集することができる。
これにより、サーバー10において、キャッシュ機能を有するデバイス30からも、キャッシュ機能を有さないデバイス30からも、適切に情報を収集して、各音響マーカー20を遠隔監視することが可能になる。また、サーバーへの位置問合せ回数による課金を実施する場合に、キャッシュ機能を有するデバイスに対しては音響信号の利用回数による課金を実施することで、同等の課金を行うことが可能になる。
図18〜24の例は、音響マーカーが通信機能を備えない場合にも適用可能であるが、図25では、音響マーカーが通信機能を備える場合について説明する。
図25の音響マーカー20は、音響信号出力部230に加えて、音響信号を入力するマイク等の音響信号入力部260と、ネットワーク60を通してサーバー10へ情報を送る通信部270とを備える。
音響マーカー20の音響信号出力部230から出力された音響信号は、デバイス30に受信されるとともに、音響マーカー20の音響信号入力部260でも受信される。音響信号が出力されていることを確認するためには、この音が受信されるか否かを調べるのが確実であるため、本例では、同一装置内に音響信号を出力する機能と入力する機能の両方を搭載することにより、音響マーカーが故障していないかどうか確認している。
この確認した情報は、音響マーカー20の通信部270からサーバー10へ送信される。サーバー10への通信メッセージに、音響マーカー20のID、時刻、故障状況の情報を含めることにより、サーバー10は、各音響マーカー20を遠隔故障することができる。
以下には、図26〜37を参照して、音響マーカーの配置例を説明する。音響マーカーは、エリア内のセル単位に配置する。
図26は、単一エリアにおいてセルが2次元に広がる場合(例えば、部屋等)、使用できる音響信号の音域グループが4種類(A〜D)あると、音響マーカーを隙間なく配置することができることを示している。混信を防ぐため、隣接するセルでは同一の音域グループを使用しないように配置している。周波数を重複しないように割り当てる音域グループが4つある(例えば、15.0kHz〜21.2kHzの200Hz毎の周波数を利用し、8ビット分を4グループ確保する)場合、1エリア内で60個のセルを識別可能である。本例では、エリアを6×6のセルに論理的に分割しているが、N×M(NとMは識別可能な個数に収まる任意の自然数)に分割する場合も、4種類あれば、同様に隙間なく配置可能である。これなら、デバイスを携帯しながら移動すると、連続的に、位置に応じた情報を取得していくことができる。
図27、28、29は、それぞれ、図26と同様のセルが2次元に広がるエリアにおいて、使用できる音響信号の音域グループが、3種類(例えばA〜C)の場合、2種類(例えばA〜B)の場合、1種類(例えばAのみ)の場合に、隣接するセルでは同一の音域グループを使用しないという制限の下で可能な音響マーカーの配置例を示している。使える音域グループの数が減るにしたがって、音響マーカーを配置できない(そこにいるデバイスは音響信号を受信できない)セルが多くなり、デバイスを携帯しながら移動しても、間欠的にしか、位置に応じた情報を取得できないことになる。
図30、31、32は、それぞれ、単一エリアにおいてセルが1次元に延びる場合(例えば、通路等)、使用できる音響信号の音域グループが、4種類(A〜D)、3種類(例えばA〜C)、2種類(例えばA〜B)あると、音響マーカーを隙間なく配置することができ、デバイスが移動しながら連続的に情報取得できることを示している。混信を防ぐため、隣接するセルでは同一の音域グループを使用しないように配置している。本例では、エリアを1×6のセルに論理的に分割しているが、1×N(Nは識別可能な個数に収まる任意の自然数)に分割する場合も、同様である。
図33は、図30〜32と同様のセルが1次元に延びるエリアにおいて、使用できる音響信号の音域グループが1種類(例えばAのみ)の場合に、隣接するセルでは同一の音域グループを使用しないという制限の下で可能な音響マーカーの配置例を示している。音響信号が受信できるセルが飛び飛びになるため、デバイスの移動しながらの情報取得も間欠的になる。
図34、35、36、37は、複数のエリアからなるロケーションにおいて、使用できる音響信号の音域グループが、それぞれ、4種類(A〜D)の場合、3種類(例えばA〜C)の場合、2種類(例えばA〜B)の場合、1種類(例えばAのみ)の場合に、隣接するセルでは同一の音域グループを使用しないという制限の下で可能な音響マーカーの配置例を示している。
図34〜37の例では、2×6、1×2、2×6の3つのエリアが接続されたロケーションを取り上げている。接続部分には、エリアは異なるが隣接するセルが存在するため、その間でも異なる音域グループを使用するように、配置する。
以上に詳述した音響マーカーシステムを利用すると、屋外だけでなく、屋内や地下空間を歩行中の、例えばスマートフォン利用者の位置情報を、リアルタイムかつ高精度(最小1m程度)で取得させることができる。
一般的なスマートフォンにはマイクロフォンと通信装置が搭載されており、追加の装置の接続を必要としないため、特殊な外部装置を必要とせずアプリケーションプログラムをインストールするだけで、利用開始できる。他方、設置する音響マーカーについても、通常の音響装置を流用することができるため入手が容易で、二次元コードを貼付した場合のように景観を損ねることもない。
さらにWiFi受信信号強度による位置推定が5〜10秒かかっているのに対して、本方式では、ほぼリアルタイムで位置を取得することができるため、デバイスが移動しても高い精度で位置情報を提供できる。また、事前のWiFi受信信号強度に関するキャリブレーションのような作業も不要であるため、設置時間の短縮も図ることができる。
また、本システムでは、複数の音源から同時に音響信号(音波)を放音・伝送することを前提にして、隣接する場所になる音源からは異なる音域グループの音響信号が流れるように割り振りを行うため、伝送媒体として音波を使っているにもかかわらず、周波数成分の干渉による情報の復元障害という問題が生じない。これにより、音源を密に配置して位置情報(座標)等を提供する用途に使用することが可能になっている。
以上に一例を説明した音響マーカーシステムによる位置情報取得技術を適用する用途は、多岐にわたり得るが、代表的な例を以下に説明する。
屋内や地下空間に音響マーカーによる位置推定基盤を構築することで、これまでは実現が困難であったGPSの届かない場所での歩行中のナビゲーションが可能となる。
屋内の例としては、店舗内に音響マーカーを設置することで、静止して端末をかざすことなく歩きながら現在位置をリアルタイムで確認できることから、入店時に探している商品やお勧めの商品まで案内する店舗内誘導サービス等が実現できる。また、店舗で利用する場合には入店・退出管理や動線把握にも利用できる。
さらにこのサービスは、複数の音響マーカーが同時に聞こえる状況が存在しても、それぞれを認識できるという特徴がある。例えば、音響マーカーを商品の置いてある棚の場所と紐付けて位置情報として使用することが基本と考えられるが、入口、会計場所、トイレなどに別途音響マーカーを付けることで、同時に複数の音響マーカーからの音響信号を取得しても区別して認識することができる。さらに、棚に配置した際に音響マーカーからの信号出力が同時に取得できる場合にも双方ともに認識し区別できる。
上記サービスのためのシステムは、音響マーカー、デバイス、サーバーに加えて、店舗情報管理サーバーで構成される。機能としては下記6点が挙げられる。
i)現在位置提供:スマートフォン等のデバイス(以下、デバイスという)でアプリケーションを起動すると音響信号取得が可能になり、音響信号を認識する度にサーバーへ現在位置を問い合わせるため、現在のデバイスの座標が把握できる。音響信号の把握は立ち止まって端末を音源にかざしたりする必要はなく、歩行したまま受動的に認識可能である。現在位置は常にサーバーを通じて店舗情報管理サーバーから取得したアプリケーション上のエリアマップ上に点で表示される。デバイス単独でエリアの変更を認識できるため、エリアIDの変更を検知するとサーバーに新規エリアのマップを要求し取得することができ、常に現エリアのマップ上に現在地が描画される。音響信号識別IDが複数同時に認識できる場合には、それぞれの音響信号識別IDに対応する座標を取得し、その全座標の中間点を現在地とする。
ii)商品情報検索(商品位置取得、ルート検索):デバイスでアプリケーションを起動し、現在位置を認識すると商品検索が可能になる。商品情報(アイテムコード)を入力するとサーバーを通じて店舗管理用サーバーへ商品位置を要求し、商品の座標を取得する。現在地と検索した商品の座標を取得すると、店舗情報管理サーバーにて現在位置から商品棚までのルートを計算し店舗内全域マップに描画しアプリケーション上に表示する。ここでルートが表示される地図は、現在地を表示するエリアマップとは別にナビゲーション終了時まで常に全域の表示を行う。
iii)商品、コンテンツ情報の提供:デバイスのアプリケーションは、現在位置を取得すると、その座標に紐づいたアイテム(商品、コンテンツ)情報をサーバー経由で店舗情報管理サーバーに問い合わせ、情報を取得する。認識した音響信号識別IDに紐づいている商品、コンテンツを全てリアルタイムに表示することができる。また、表示するものはキャンペーンごとなど店舗側で制御することができる。
iv)商品までの歩行案内:ii)により常にデバイスの現在位置を取得できるため、現在地を把握しながら、ii)で表示されたルートを元に歩行する。商品が置かれている棚に設置された音響マーカーの音響信号を認識すると案内終了のメッセージが表示される。
v)入店、退店管理:入口に音響マーカーを設置することで、既にデバイスのアプリケーションが起動している場合は入口の音響マーカーの音響信号識別IDを認識し、サーバーに問い合わせを行い入店と退店を認識する。入口には入口中央から店舗外側と内側それぞれに向けて音響マーカーの出力スピーカーを設置する。それぞれの音響マーカーが使用する音響信号識別IDは店舗情報管理サーバーにて入口に紐づけられている。
入店・退店判定を行うためのシステムの一例を図38に示す。入店時にデバイスのアプリケーションが起動している場合、まずAの音響マーカー信号を認識し次にBの音響マーカーを認識する。入店後にアプリケーションを起動した場合は入店の記録はないが、起動した地点から現在地の取得が開始される。退店時にはBの音響マーカー信号を取得した後Aの音響マーカー信号を取得することで退店を認識する。詳細は、後述する。また、退店済みと認識しない場合、一定時間が経過しても音響信号を検出していないときは退店とみなすように処理してもよい。
これらの入退店の情報は顧客(以下、ユーザと呼ぶ)ごとに店舗情報管理サーバーにて管理されているため、ユーザ別に来店頻度、店内滞在時間、どのエリアに長く滞在したか等を別途ビジネスインテリジェンス(BI)システム等で分析するためのログとして記録することができる。
応用例として、入店時に前回、当該ユーザが検索した商品や、来店前にチェックしていた商品などを出すことも可能である。
vi)動線管理:ユーザ情報が店舗情報管理サーバーにて管理されており、ユーザが現在位置を取得する度にログが店舗情報管理サーバーに蓄積されていく。ユーザ別にログを見ることで、ユーザの来店時の動線の把握が可能である。ログを時間で検索すると、どの時間帯にはどの売り場に人が多いなど細かい情報の取得が可能である。商品、コンテンツ表示端末には、歩行時に取得した音響信号識別IDに紐づいた位置にあるコンテンツの情報や検索した商品の棚に到着した際に商品の情報を表示することができる。
上記サービスのためのシステムを構築するにあたり、屋内や地下空間では、GPS衛星からの電波が取得できないため、GPSを現在位置情報の取得に用いることはできない。WiFiにおいては、BSSID(無線LAN基地局の識別名称)による位置推定方式では同じフロア内の高精度な識別は困難であり、RSSI(無線LANの受信信号強度)による位置推定方式では一定時間立ち止まっていないと位置推定ができないため歩きながら案内をすることは不可能である。2次元コードにおいても、認識するためには立ち止まり、デバイスを静止させカメラで2次元コード(マーカー)を読み込むという作業をしないと利用できない。このようなことから、商品案内といった詳細レベルでの店舗内誘導サービスは現在存在する他の技術では実現できず、本技術を用いて初めて可能になると考えられる。
上記サービスのためのシステムにおける音響マーカーは、音響マーカーシステムにおける音響マーカーとして前述した通りである。図39、図40に、上記サービスにおける音響マーカーの2つの設置例を示す。音響マーカーの設置は店舗内のほぼ全域を想定し、店舗内ではどの場所においても現在位置が確認できるものとする。
前述した例によれば、音響マーカーは1つの店舗内で最大15エリア(店舗内でいう1つの売り場)まで使用が可能であり、音域グループを4つに分けた場合は1つのエリアにつき最大60点設置することができる。つまり、3階建で各階に2つずつ売り場が存在する店舗に設置する場合は、全部で6エリアあると考え各エリア内で棚の位置情報、特定の場所、お勧め商品など合わせて60点まで音響マーカーを使用できる。
1つのエリア内では、A、B、C、Dの各音域グループの音響マーカーに対し、同じ音域グループの音響マーカーが隣り合わないように配置する。下記に1エリア内での音響マーカーの設置例を示す。音響マーカーのスピーカーで壁や棚から通路に向けて音を発生させた場合、前方の通路にのみ音が放音されるものとする。音響信号は違う音域グループのものであれば、音域グループ数(4つ)までは同時に識別可能である。例えば、図39では、丸数字で1の位置では、3つの音響信号が聞こえることになる。その場合、A-0-8、B-0-8、D-0-8の信号が同時に認識され、それぞれの座標を取得することできる。
音響マーカーの使用例として、基本的にどの音響マーカーも位置情報と紐付けられているが、座標認識のためではなく、コンテンツの情報提供などを目的とすることも可能である。つまり歩行中にコンテンツ情報提供用の音響信号を取得しても現在地には反映せず、コンテンツの内容のみを表示させることが可能である。様々な角度からセルよりも大きな範囲などに情報を提供したり、ポスターなどの情報を提供したりすることに適していると考える。図40で説明すると、キャンペーン情報を十字路周辺に提供したい場合、中央の棚にスピーカーを置き音響信号(D-1-1)を360度に放音する。D-1-1は位置情報を提供せず、キャンペーン情報のみを提供する。図40の丸数字で2の位置にいる場合は、D-1-1の位置情報は使用せずA-1-3とC-1-2の座標の中間点が現在位置となる。
応用例として、それぞれの音響マーカーの位置情報に加え隣り合う音響マーカーもサーバーに記録しておくと、次に認識するはずの音響信号識別IDを予測できるため、それ以外の音響信号識別IDが取得された場合エラーと判別することができ、補正方法の精度を高めることが可能である。
上記サービスのためのシステムにおけるデバイスは、音響マーカーシステムにおけるデバイスとして前述した基本機能に加え、店舗内誘導サービス用のアプリケーションがインストールされている。アプリケーションは商品情報検索、商品までの歩行案内、現在位置把握、商品・コンテンツ情報の閲覧等が可能なグラフィカルユーザインターフェイス(GUI)を有する。
上述した歩行者ナビゲーションのサービスは、店舗だけではなく、例えば、地下鉄のホームで、どの方向に移動することが目的地に一番近いかを利用者に通知するような用途や地下駐車場に駐車した自動車まで案内するといった利用が可能である。
また、博物館や美術館、水族館など展示物の補足情報を提供するために拡張現実技術を利用するような用途でも、上述した音響マーカーシステムによる位置情報取得技術を適用できる。従来技術では実現が困難であったような屋内環境でのシステム化を図ることができる。
上述した店舗情報管理サーバーのように、歩行者ナビゲーションや拡張現実の各ユーザの動線の情報を収集すると、この情報を事業者がサービス向上を図るための情報として利用することができる。また、施設の警備や鉄道事業者の係員の配置などに関して、管理者が現在位置を把握するような用途での利用も可能である。
上述した店舗情報管理サーバーのように、入店管理を行うと、小売店向けのポイントプログラムやクーポン券発行の条件として、来店を求めるような用途において、確実に入店したかどうかを位置情報によって把握することができる。従来技術では、GPSやWiFiによって位置推定を行うことが多いため、実際に入店せずに利用者がチェックインすることは可能であったが、本技術では、高音域の音声信号を利用するためエリアを限定しやすくなっており、店内に入らないとチェックインできないような制限が可能である。また、リアルタイムで位置を取得できるため、入り口を通過した瞬間に入店を確認することができる。
本技術によってポスターなどの掲示物に関する情報を提供すると、従来の二次元コードのスキャンのように一つの二次元コードを同時に取得できるのは一名だけという制約がなく、一度に多人数が同時に情報を取得させることができる。
本技術を利用するデバイスを保持する歩行者は、歩きながら音響信号を取得することができるため、例えば、展示会などにおいて通過したブースを特定することができ、資料を自動的に取得することができる。また、路上などで配布される広告や割引券のような情報も、同様に取得することができる。
テレビ放送やラジオ放送において、本技術を用いた音響信号を発信することによって、あらかじめ配布したアプリケーションと連動した商品紹介や購入支援を行うことも可能である。音響信号は、時々刻々変化させることができるため、出演者の衣装や楽曲などの情報も提供できる。
上述した例では、サーバーにて各音響マーカーの故障状況を評価するための情報を、本システムの多数のユーザが所持するデバイスから収集できるが、本システムの管理者が、定期的に、各音響マーカーの検査のためのルートが表示されたエリアマップを見ながらデバイスを持って歩き回ることによっても、同様に情報を収集することが可能である。
以上では、音響信号を利用して屋内で位置推定(測位)を行う例における音響マーカーの管理について説明したが、上述した例は全て、音響信号以外の屋内測位用の信号を出力する装置の管理にも応用することが可能であり、特に、ネットワーク機能を有していない信号出力装置の管理に有用である。
例えば、Bluetooth(登録商標)の発信装置は、信号の届く範囲にあるデバイスに、当該発信装置のアドレスを認識させることができるから、音響信号識別IDの代わりにBluetooth(登録商標)のアドレスを利用することで、音響マーカーと同等のことが実現できる。このBluetooth(登録商標)の発信装置について、サーバーで集中的に遠隔監視することは、上述した音響信号の例と同様の手法で、実現できる。
以上、本発明の実施形態について説明したが、上述の実施形態を本発明の範囲内で当業者が種々に変形、応用して実施できることは勿論である。