以下、本発明の実施の形態に係る情報提供システムについて、例示のために、図面を用いて説明する。
本例に係る情報提供システムは、概略、次のような技術である。ネットワークに接続されたコンピュータと音声出力装置から構成される「音響マーカー」から、人間の耳には聞こえにくい高音域の音声信号(以下、音響信号という)を出力する。その音響信号をデバイスに内蔵されたマイクロフォンへ入力させ、音響信号を解析した結果抽出された音響信号識別番号(ID)等を基にネットワーク経由で管理サーバーへ問い合わせることで、位置情報及び/又はその他の情報(いずれも、各音響マーカーから音響信号を受信したデバイスに対して提供したい情報であり、以下、位置情報等という)を取得させることができる。
音響信号は、15kHz〜22kHz台の可聴周波数の上限域(超音波音ともいう)を使用する。この音域の音声は、一般の人間には聞き取ることができない音域であり、周囲に気づかれることなく信号を出すことができる。当然ながら、写真や映像にも写らないため、運用環境の景観を損ねることもない。また、この周波数帯を使用することで、超音波用の専用機器ではなく、通常市販されるスピーカー等の音声出力装置を流用することができる。
本技術を適用したシステム(以下、音響マーカーシステムともいう)は、例えば、図1に示すように、管理サーバー10と、N個の音響マーカー20−1〜20−Nと、M個のデバイス(例えばスマートフォン等の携帯型情報機器)30−1〜30−Mとにより構成される。このうち、デバイスは、情報を利用する各ユーザにより使用されるものであるので、例えば、管理サーバーと音響マーカーとからなるシステム60を、情報提供システムと呼んでも構わない。
管理サーバー10は、ネットワーク(例えばインターネットプロトコル(IP)ネットワーク等)40により接続された各音響マーカー20を管理し、音響信号識別IDの割り振りを行う。また、ネットワーク(例えばインターネットプロトコル(IP)ネットワーク等)50により接続されるデバイス30から要求された情報についての提供を行う。
デバイス30は、ユーザがデバイスを持ちながら移動するという形態で使用されるものであるため、ネットワーク50は、無線LANや携帯電話網等のネットワークであることが望ましい。ネットワーク40は、音響マーカー群を設置する場所に敷設されている固定
通信網を利用してもよい。ネットワーク40とネットワーク50とが相互に独立したネットワークとしてもよいし、ネットワーク40とネットワーク50とが一つのネットワークを形成するものであっても構わない。
音響マーカー20は、管理サーバー10から指定された音響信号識別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を指定する。
図4に、管理サーバー10の内部構成例を示す。管理サーバー10は、音響マーカー20及び音響信号についての管理を行い、音響信号の伝達範囲の調整指示やデバイス30による位置情報等要求への回答を伝達する機能を有する。
管理サーバー10は、音響マーカーの管理と音響信号識別IDの付与を行うために、音響マーカー登録部100、音響信号識別ID選択部105、音響信号指示部110を有する。また、音響信号識別IDを再選択するために、音響マーカー変更部120、音響信号識別ID再選択部125を備える。
管理サーバー10はまた、音響マーカーとデバイス間の伝達範囲の調整を行うために、
伝達範囲調整依頼取得部140と出力レベル変更指示部145を有する。さらに、デバイスからの要求に応答し、位置情報等を伝達するために位置情報等要求取得部160、位置情報等要求確認部165、位置情報等抽出部170、位置情報等伝達部175を有する。
これらの機能を実現するために、管理サーバー10はデータベースを備え、音響マーカー管理テーブル150(図5)、音響信号管理テーブル130(図6)、付帯情報管理テーブル180(図7)を有する。
管理サーバー10と各音響マーカー20との間はネットワーク40により、管理サーバー10と各デバイス30との間はネットワーク50により、接続されており、相互通信が可能である。
図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)。
そして、音響信号指示部110は、当該音響マーカー20−Kに対して、ネットワーク40を通じて音響信号識別ID及び出力レベルを指示する。
図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)。
そして、音響信号指示部110は、当該音響マーカー20−Jに対して、ネットワーク40を通じて改めて音響信号識別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の当該音響マーカーのレコードに含まれる出力レベルを更新し、ネットワーク40を通じて、当該音響マーカー20−Kへ指示を行う(1025)。
さらに、出力レベル変更指示部145は、音響マーカー20−Kからネットワーク40を通じて、指示を受けた音響マーカー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から抽出する。そして、受け取った要求に含まれるデバイスの緯度・経度情報が、抽出された音響マーカーのレコードに登録された緯度・経度情報と合致するかどうかを確認する(1115)。なお、有効期限の照合及び緯度・経度の照合の両方又は一方を、省略して運用してもよい。
位置情報等抽出部170は、抽出された音響マーカーのレコードから、エリアID、X,Y,Z座標を抽出する(1120)。X,Y,Z座標をエリア内の座標系で定義している場合はエリアIDとともに抽出するが、X,Y,Z座標のみから位置が一意に特定できる場合にはX,Y,Z座標のみを抽出してもよい。
位置情報等抽出部170はまた、付帯情報管理テーブル180において、抽出された位置情報に付帯情報が関連づけされている場合は(1125)、付帯情報を抽出する(1130)。付帯情報の内容により、その位置に関連した各種の情報サービスを提供することができる(各種応用例を後述する)。提供される情報自体を付帯情報としてもよいし、提供される情報が置かれているURLを付帯情報としてもよい。
位置情報等伝達部175は、抽出された位置情報(エリアID、X,Y,Z座標)及び/又は付帯情報を、要求元のデバイス30−Iへネットワーク50を通じて伝達する(1150)。なお、受け取った要求の有効性が確認できなかった場合は、エラーが返され(1040)、要求元のデバイスにも要求処理不可の通知が返される。
図12には、各音響マーカー20の内部構成例を示す。音響マーカー20は、管理サーバー10と連携し、音響信号の出力を行う機能を有する。
音響マーカー20は、音響信号の出力を行うために、音響信号識別ID取得部200、音響信号ファイル選択部210、音響信号出力管理部220、スピーカー部230を有する。スピーカー部230は、概ね15kHz〜22kHzの高音域の信号を出力できるものである。音響マーカー20はまた、出力レベル調整を実施するため、出力レベル調整指示取得部240、音響信号識別ID確認部250を備える。
なお、音響マーカー20は、管理サーバー10との間をネットワーク40で接続しており、相互通信が可能である。ただし、ネットワーク40を利用せずに、音響マーカー20自体に音響信号識別IDや出力レベル等を個別に指示するようにしてもよい。
図13は、音響マーカー20が、音響信号を出力するための処理の流れの一例を示す。
音響マーカー20の音響信号識別ID取得部200は、管理サーバー10からネットワーク40を通じて、音響信号識別ID及び出力レベル、出力又は停止指示を取得する(1300)。
音響信号ファイル選択部210は、予め記憶してある音響信号ファイルの中から、受け
取った音響信号識別IDに対応するファイルを選択する(1305)。ただし、受け取った音響信号識別ID情報を基に、音響信号ファイルを新たに作成してもよい。
音響信号出力管理部220は、受け取った指示に停止指示が含まれていない場合には(1310)、指示された出力レベルを基に(1315)、選択した音響信号ファイルを再生し(1320)、スピーカー部230から出力を行う。受け取った指示に停止指示が含まれている場合には、現在再生している音響信号ファイルの再生を停止する(1330)。そして、管理サーバー10に対して指示を処理した結果を通知する(1340)。
上述したように、管理サーバー10は、デバイス30からネットワーク50経由で取得した出力レベル調整依頼に基づいて、音響マーカー20に対して、ネットワーク40を通じて出力レベル調整指示を伝達する。
このため、音響マーカー20−Kから音響信号を取得させたい位置(例えば、距離1mなど)にデバイス30−Kを設置し、音響信号の検出を試みる。このとき信号が検出できなければ、デバイス30−Kは管理サーバー10に対して、出力レベル増加調整を依頼する。この出力レベル増加依頼は、音響信号が検出できるようになるまで繰り返すことができる。
次に、例えば、音響信号の伝達限界(そこから先は音響信号が伝達されるべきでない)位置にデバイスを移動させ、音響信号の検出を試みる。このとき信号が検出されるならば、デバイス30−Kは管理サーバー10に対して、出力レベルの減少依頼を行う。この出力レベル減少依頼は、音響信号が検出できなくなるまで繰り返すことができる。
なお、上記の増加依頼、減少依頼は、デバイスの使用者が手動操作で行うことは勿論、デバイス自体が自動操作で行うこともできる。
図14は、音響マーカー20が、音響信号の出力レベルを調整するための処理の流れの一例を示す。
音響マーカー20の出力レベル調整指示取得部240は、管理サーバー10からネットワーク40を通じて、出力レベル調整指示を取得する(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から取得した音響信号を基に位置情報(例えば、エリア内の3次元座標)等を取得する機能を有する。
デバイス30は、通信機能を有する可搬型端末(例えば、スマートフォン)であり、位置情報等を取得するために、音響信号入力部300、音響信号抽出部310、音域グループ検出部320、音響信号識別ID取得部330、位置情報等要求部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がGPS緯度経度取得部360を備える場合には、デバイスの緯度・経度情報を含むものとしてもよい。
デバイス30の位置情報等取得部350は、送付された要求への応答として、ネットワーク50を通じて管理サーバー10から位置情報等を取得する(1650)。デバイス30が管理サーバー10から受け取る応答には、位置情報及び/又は付帯情報、もしくは要求処理不可という結果の通知が含まれる。位置情報としては、エリアIDはデバイス30内で得られるため、少なくともエリア内の3次元座標情報(X,Y,Z)を管理サーバー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〜29を参照して、音響マーカーの配置例を説明する。音響マーカーは、エリア内のセル単位に配置する。
図18は、単一エリアにおいてセルが2次元に広がる場合(例えば、部屋等)、使用できる音響信号の音域グループが4種類(A〜D)あると、音響マーカーを隙間なく配置することができることを示している。混信を防ぐため、隣接するセルでは同一の音域グループを使用しないように配置している。周波数を重複しないように割り当てる音域グループが4つある(例えば、15.0kHz〜21.2kHzの200Hz毎の周波数を利用し、8ビット分を4グループ確保する)場合、1エリア内で60個のセルを識別可能である。本例では、エリアを6×6のセルに論理的に分割しているが、N×M(NとMは識別可能な個数に収まる任意の自然数)に分割する場合も、4種類あれば、同様に隙間なく配置可能である。これなら、デバイスを携帯しながら移動すると、連続的に、位置に応じた情報を取得していくことができる。
図19、20、21は、それぞれ、図18と同様のセルが2次元に広がるエリアにおいて、使用できる音響信号の音域グループが、3種類(例えばA〜C)の場合、2種類(例えばA〜B)の場合、1種類(例えばAのみ)の場合に、隣接するセルでは同一の音域グループを使用しないという制限の下で可能な音響マーカーの配置例を示している。使える音域グループの数が減るにしたがって、音響マーカーを配置できない(そこにいるデバイスは音響信号を受信できない)セルが多くなり、デバイスを携帯しながら移動しても、間欠的にしか、位置に応じた情報を取得できないことになる。
図22、23、24は、それぞれ、単一エリアにおいてセルが1次元に延びる場合(例えば、通路等)、使用できる音響信号の音域グループが、4種類(A〜D)、3種類(例えばA〜C)、2種類(例えばA〜B)あると、音響マーカーを隙間なく配置することができ、デバイスが移動しながら連続的に情報取得できることを示している。混信を防ぐため、隣接するセルでは同一の音域グループを使用しないように配置している。本例では、エリアを1×6のセルに論理的に分割しているが、1×N(Nは識別可能な個数に収まる
任意の自然数)に分割する場合も、同様である。
図25は、図22〜24と同様のセルが1次元に延びるエリアにおいて、使用できる音響信号の音域グループが1種類(例えばAのみ)の場合に、隣接するセルでは同一の音域グループを使用しないという制限の下で可能な音響マーカーの配置例を示している。音響信号が受信できるセルが飛び飛びになるため、デバイスの移動しながらの情報取得も間欠的になる。
図26、27、28、29は、複数のエリアからなるロケーションにおいて、使用できる音響信号の音域グループが、それぞれ、4種類(A〜D)の場合、3種類(例えばA〜C)の場合、2種類(例えばA〜B)の場合、1種類(例えばAのみ)の場合に、隣接するセルでは同一の音域グループを使用しないという制限の下で可能な音響マーカーの配置例を示している。
図26〜29の例では、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は店舗情報管理サーバーにて入口に紐づけられている。
入店・退店判定を行うためのシステムの一例を図30に示す。入店時にデバイスのアプリケーションが起動している場合、まずAの音響マーカー信号を認識し次にBの音響マーカーを認識する。入店後にアプリケーションを起動した場合は入店の記録はないが、起動した地点から現在地の取得が開始される。退店時にはBの音響マーカー信号を取得した後
Aの音響マーカー信号を取得することで退店を認識する。詳細は、後述する。また、退店済みと認識しない場合、一定時間が経過しても音響信号を検出していないときは退店とみなすように処理してもよい。
これらの入退店の情報は顧客(以下、ユーザと呼ぶ)ごとに店舗情報管理サーバーにて管理されているため、ユーザ別に来店頻度、店内滞在時間、どのエリアに長く滞在したか等を別途ビジネスインテリジェンス(BI)システム等で分析するためのログとして記録することができる。
応用例として、入店時に前回、当該ユーザが検索した商品や、来店前にチェックしていた商品などを出すことも可能である。
vi)動線管理:ユーザ情報が店舗情報管理サーバーにて管理されており、ユーザが現在位置を取得する度にログが店舗情報管理サーバーに蓄積されていく。ユーザ別にログを見ることで、ユーザの来店時の動線の把握が可能である。ログを時間で検索すると、どの時間帯にはどの売り場に人が多いなど細かい情報の取得が可能である。商品、コンテンツ表示端末には、歩行時に取得した音響信号識別IDに紐づいた位置にあるコンテンツの情報や検索した商品の棚に到着した際に商品の情報を表示することができる。
上記サービスのためのシステムを構築するにあたり、屋内や地下空間では、GPS衛星からの電波が取得できないため、GPSを現在位置情報の取得に用いることはできない。WiFiにおいては、BSSID(無線LAN基地局の識別名称)による位置推定方式では同じフロア内の高精度な識別は困難であり、RSSI(無線LANの受信信号強度)による位置推定方式では一定時間立ち止まっていないと位置推定ができないため歩きながら案内をすることは不可能である。2次元コードにおいても、認識するためには立ち止まり、デバイスを静止させカメラで2次元コード(マーカー)を読み込むという作業をしないと利用できない。このようなことから、商品案内といった詳細レベルでの店舗内誘導サービスは現在存在する他の技術では実現できず、本技術を用いて初めて可能になると考えられる。
上記サービスのためのシステムにおける音響マーカーは、音響マーカーシステムにおける音響マーカーとして前述した通りである。図31、図32に、上記サービスにおける音響マーカーの2つの設置例を示す。音響マーカーの設置は店舗内のほぼ全域を想定し、店舗内ではどの場所においても現在位置が確認できるものとする。
前述した例によれば、音響マーカーは1つの店舗内で最大15エリア(店舗内でいう1つの売り場)まで使用が可能であり、音域グループを4つに分けた場合は1つのエリアにつき最大60点設置することができる。つまり、3階建で各階に2つずつ売り場が存在する店舗に設置する場合は、全部で6エリアあると考え各エリア内で棚の位置情報、特定の場所、お勧め商品など合わせて60点まで音響マーカーを使用できる。
1つのエリア内では、A、B、C、Dの各音域グループの音響マーカーに対し、同じ音域グループの音響マーカーが隣り合わないように配置する。下記に1エリア内での音響マーカーの設置例を示す。音響マーカーのスピーカーで壁や棚から通路に向けて音を発生させた場合、前方の通路にのみ音が放音されるものとする。音響信号は違う音域グループのものであれば、音域グループ数(4つ)までは同時に識別可能である。例えば、図31では、丸数字で1の位置では、3つの音響信号が聞こえることになる。その場合、A-0-8、B-0-8、D-0-8の信号が同時に認識され、それぞれの座標を取得することできる。
音響マーカーの使用例として、基本的にどの音響マーカーも位置情報と紐付けられてい
るが、座標認識のためではなく、コンテンツの情報提供などを目的とすることも可能である。つまり歩行中にコンテンツ情報提供用の音響信号を取得しても現在地には反映せず、コンテンツの内容のみを表示させることが可能である。様々な角度からセルよりも大きな範囲などに情報を提供したり、ポスターなどの情報を提供したりすることに適していると考える。図32で説明すると、キャンペーン情報を十字路周辺に提供したい場合、中央の棚にスピーカーを置き音響信号(D-1-1)を360度に放音する。D-1-1は位置情報を提供せ
ず、キャンペーン情報のみを提供する。図32の丸数字で2の位置にいる場合は、D-1-1
の位置情報は使用せずA-1-3とC-1-2の座標の中間点が現在位置となる。
応用例として、それぞれの音響マーカーの位置情報に加え隣り合う音響マーカーも管理サーバーに記録しておくと、次に認識するはずの音響信号識別IDを予測できるため、それ以外の音響信号識別IDが取得された場合エラーと判別することができ、補正方法の精度を高めることが可能である。
上記サービスのためのシステムにおけるデバイスは、音響マーカーシステムにおけるデバイスとして前述した基本機能に加え、店舗内誘導サービス用のアプリケーションがインストールされている。アプリケーションは商品情報検索、商品までの歩行案内、現在位置把握、商品・コンテンツ情報の閲覧等が可能なグラフィカルユーザインターフェイス(GUI)を有する。
デバイスの構成としては、前述の基本部に加え位置情報取得に関しては取得位置情報を解析する位置情報解析部を有し、さらに商品検索に関する商品入力部、商品情報要求部、商品位置情報取得部、指定した商品までのルート検索に関するルート情報要求部、ルート情報取得部、ルート表示部、店内マップ取得に関する現エリアマップ選択部、現エリアマップ要求部、現エリアマップ取得部、現エリアマップ表示部、アイテム(商品・コンテンツ)表示と選択に関するアイテム情報要求部、アイテム情報取得部、アイテム情報解析部、アイテム情報表示部を有する。
デバイスの動作例を図33〜図38に示す。
図33は、現在位置を取得する処理を示す。音響信号識別IDを取得し位置情報を取得する部分は基本構造と同じである。その後、取得した位置情報を解析し、1つの位置情報の認識か複数の位置情報の認識かを判別する。1つの位置情報を取得した場合、位置フラグが0であればそのまま、現在位置の座標と認識する。フラグが1の場合は位置情報ではないと認識し、現在位置の座標とはしない。また、複数の位置情報を取得した場合は、位置フラグが0のもの全ての座標を合計した上その位置情報の個数で割った中間点の値を現在位置と認識する。現在位置を認識した際に、商品検索フラグがfalseの場合trueに変更
し、アプリケーション上で商品の検索が可能になる。
図34は、取得した現在位置を現エリアマップに表示する処理を示す。現在位置の座標を取得後、前エリアIDがnilの場合もしくは現エリアIDと異なる場合は、初めて現エ
リアに到達したとみなし、エリアIDを送付し現エリアマップを管理サーバーに要求する。現エリアマップの取得に成功すると、現在位置を現エリアマップに表示する。
図35は、アイテム(商品、コンテンツ)情報を表示する処理を示す。現在位置を取得した後、位置情報に紐づくアイテム情報を取得する。管理サーバーに現在位置座標を送付し、その座標に紐づくアイテム情報を全て要求する。取得したアイテム情報数が0でなければ、アイテムリストを作成する。その際にはアイテム種別が3(商品)、4(コンテンツ)のもののみリストの対象とする。
図36は、入店・退店管理を行う処理を示す。現在位置を取得するとそれに紐づくアイテム情報を取得する。その際にアイテム種別が1(入口外)、2(入口内)の場合は入口付近であると考えられるため入店、退店の判別を行う。最初のアイテム種別が1の場合、次に取得した位置情報に紐づくアイテム種別が2の場合は入店したと判定する。また、最初のアイテム種別が2である場合、次に取得した位置情報に紐づくアイテム種別が1である場合は退店したと判定する。入店、退店を認識した場合は、管理サーバーを通じて店舗情報管理サーバーへ、ログを登録するよう要求する(後述の「店舗用管理サーバーの入店状況取得処理フロー」参照)。
図37は、商品情報検索(商品位置取得、ルート検索)を行う処理を示す。現在位置を把握すると、商品検索が可能となる。商品情報を入力すると管理サーバーを通じ店舗情報管理サーバーにて商品の検索、位置情報の取得を行う。商品の座標を取得すると、商品の座標を管理サーバーを通し店舗情報管理サーバーに送付して、商品までのルート検索と店舗内マップへの描画を要求する。検索した商品までのルートが描画された店舗内マップを取得すると、アプリケーション上に表示する。
図38は、商品までの歩行案内を行う処理を示す。商品を検索すると、商品ルートと現在地がそれぞれ店舗内マップと現エリアマップに表示されるためそれを元に商品までの歩行案内が可能になる。歩行中は常に音響信号を取得し現在地を表示する。現在地が検索した商品の座標と一致すると案内の終了をデバイスのアプリケーション上で通知する。
上記サービスのためのシステムにおける管理サーバーは、音響マーカーシステムにおける管理サーバーとして前述した内容に加え、店舗情報管理サーバーへの要求および応答を取得する機能を備える。具体的には、店舗特有の情報を取得した際に店舗情報管理サーバーへ問い合わせるため、店舗情報管理サーバー要求部、店舗情報管理サーバー応答取得部、店舗情報管理サーバー応答に対するデータ作成部を有する。
上記サービスのためのシステムにおける管理サーバーの構成の一例を図39に示す。図39において、デバイスから音響信号を取得して位置情報等を提供する部分の構成は図4と同様である。入店・退店管理、商品情報検索(商品位置取得、ルート検索)、商品・コンテンツ情報表示、商品までの歩行案内、動線把握等のサービス特有の機能については、デバイスから要求を受けた際に店舗情報管理サーバーへ要求しデータを取得するために、管理サーバーが、店舗情報要求作成部190、店舗情報要求部192、店舗情報データ取得部194、店舗情報データ確認部196、店舗情報伝達部198を有する。
上記サービスのために管理サーバーは、基本的に前述のテーブル構造(図5〜図7)をそのまま持つが、図40に示すように、音響マーカー管理テーブルには、音響マーカーが位置を利用するためのもの(0)なのか、商品やその他コンテンツ情報をもつものなのか(1)を示すフラグを追加する。
上記サービスのために管理サーバーが行う位置情報等の提供の処理フローは、図11と同様である。ただ、音響マーカー管理テーブルに位置フラグが追加されたため、デバイスへ位置情報等を提供する際(1150)、座標や付帯情報に加えて位置フラグも送信される。
上記サービスのために管理サーバーは、デバイスから店舗特有の情報の取得要求を受け取った場合に、店舗管理用サーバーに要求をするための中継の役割を担う。この管理サーバーによる店舗情報要求処理フローが、図41に示されている。
図42には、上記サービスのために設置される店舗情報管理サーバーの構成例を示す。
店舗情報管理サーバー50は、店舗特有の情報を保持、管理している。商品の管理を行うためにアイテム情報登録部510、アイテム情報検索部520を有する。棚等の位置を管理するために、棚位置情報登録部530、出入り口情報登録部540、棚位置情報検索部550を有する。店舗地図情報を管理するために店舗地図情報登録部560、店舗地図情報検索部570、ルート検索部を有する。また、お勧め商品の情報を管理するために、お勧め商品登録部、お勧め情報検索部を有してもよい。
店舗情報管理サーバー50はさらに、管理サーバー10との通信を行うための店舗情報要求取得部500、店舗情報応答通知部580を有する。また、各ユーザの動線を管理するユーザ位置管理部590を有する。
店舗情報管理サーバー50は、これら機能を実現するためデータベースを備え、アイテム位置管理テーブル515(図43)、アイテム管理テーブル525(図44)、アイテム情報管理テーブル535(図45)、アイテム種別管理テーブル(図46)、店舗内地図情報管理テーブル545(図47)、動線(ユーザ位置情報)管理テーブル555(図48)を有する。
図49には、店舗情報管理サーバーが行う棚位置登録処理フローの一例を示す。棚位置情報登録部530は、座標と棚番号を元に棚位置情報登録依頼を取得した場合、座標が正しいかどうかを判別し、正しい場合は、アイテム位置管理テーブル515へ座標と棚番号を登録して、店舗内の座標と棚番号とを紐付ける。図43に示すように、当該テーブルのアイテム種別は、商品を意味する3を登録する(棚番号が登録される場合はそこに商品が陳列されるため)。アイテム種別の意味は、図46のアイテム種別管理テーブルに示されている。座標が不正な場合は、エラー処理を行い登録できない旨の結果を表示する。すでに同じ座標に棚番号や出入り口情報が登録されている場合は、旧アイテム識別及び棚番号を削除した後に新アイテム識別及び棚番号を登録する。登録処理が完了した際には、棚位置情報登録結果について表示を行う。
図50には、店舗情報管理サーバーが行う地図登録処理フローの一例を示す。店舗地図情報登録部560は、エリアIDと地図データを元に地図情報登録依頼を取得した場合、エリアIDが正しいかどうかを判別し、正しい場合は、地図情報管理テーブル545へ地図データを登録して、店舗内のエリアIDと地図データとを紐付ける。図47に示すように、地図データは、地図の画像データを参照するためのURLであってもよい。エリアIDが不正な場合は、エラー処理を行い登録できない旨の結果を表示する。すでに同じエリアIDに地図データが登録されている場合は、旧地図データを削除したあとに新地図データを登録する。登録処理が完了した際には、地図情報登録結果について表示を行う。
図51には、店舗情報管理サーバーが行うアイテム情報登録処理フローの一例を示す。アイテム情報登録部510は、棚番号とアイテムコード、アイテム情報を元にアイテム情報登録依頼を取得した場合、棚番号が正しいかどうかを判別し、正しい場合は、アイテム管理テーブル525(図44)へアイテムコードを登録し、アイテム情報管理テーブル535(図45)へアイテム情報を登録して、棚番号とアイテムコード(商品コード等)を紐付ける。棚番号が不正な場合は、エラー処理を行い登録できない旨の結果を表示する。すでに同じ棚に同じアイテムコードが登録されている場合は、旧アイテムコードを削除したあとに新アイテムコードを登録する。同一の棚番号には複数のアイテムコードを登録することができる。アイテム情報管理テーブルにアイテムコードが存在しない場合は、アイテムコード及びアイテム情報を新規に登録する。登録処理が完了した際には、アイテム情報登録結果について表示を行う。
図52には、店舗情報管理サーバーが行う出入り口登録処理フローの一例を示す。出入り口情報登録部540は、座標と出入り口種別を元に出入り口情報登録依頼を取得した場合、座標が正しいかどうかを判別し、正しい場合は、アイテム位置管理テーブル515へ出入り口情報を登録して、店舗内の座標と出入り口の識別情報(内側、外側)を紐付ける。図43に示すように、当該テーブルのアイテム種別は、出入り口の外側を意味する0または内側を意味する1を登録する。アイテム種別の意味は、図46のアイテム種別管理テーブルに示されている。座標が不正な場合は、エラー処理を行い登録できない旨の結果を表示する。すでに同じ座標に棚番号情報や出入り口情報が登録されている場合は、旧アイテム種別を削除した後に新アイテム種別を登録する。登録処理が完了した際には、出入り口情報登録結果について表示を行う。
図53には、店舗情報管理サーバーが行う店舗情報要求処理フローの一例を示す。店舗情報管理サーバーは、管理サーバーからの要求に基づき、座標情報を元にして、出入り口の識別結果の提供、商品データの提供、ユーザの位置の登録を行う。
店舗情報要求取得部500は、管理サーバー10から座標とユーザ情報を取得した場合、座標が正しいかどうかを判別し、正しい場合は、アイテム位置管理テーブル515から当該座標に紐づいたアイテム種別を抽出する。座標が不正な場合は、エラー処理を行い回答できない旨の結果を表示する。
アイテム種別が1の場合、ユーザ位置管理部590は、ユーザ位置情報管理テーブル555に対して、出入り口の外側を通過した旨を記録し(図48)、店舗情報応答通知部580へ通知を依頼する。アイテム種別が2の場合、ユーザ位置管理部590は、ユーザ位置情報管理テーブル555に対して、出入り口の内側を通過した旨を記録し(図48)、店舗情報応答通知部580へ通知を依頼する。
アイテム種別が3または4の場合、棚位置情報抽出部550は、アイテム位置管理テーブル515から棚番号を抽出し、アイテム情報抽出部520へ伝達する。ただし、アイテム種別が4(イベント、キャンペーン)の場合に棚番号が指定されていない場合もある。アイテム情報抽出部520は、棚番号を元にアイテム管理テーブル525からアイテムコードを抽出し、アイテム情報管理テーブル535からアイテム情報を抽出する。続いて、ユーザ位置管理部590へユーザ位置の登録依頼を行う。ユーザ位置管理部590は、ユーザ位置情報管理テーブル555に対して、当該棚等の場所を通過した旨を記録し(図48)、店舗情報応答通知部580へ通知を依頼する。
店舗情報応答通知部580は、依頼された内容について管理サーバー10へ通知する。
図54には、店舗情報管理サーバーが行う入店状況取得処理フローの一例を示す。店舗情報管理サーバーは、ユーザごとの入店状況を管理している。
管理サーバー10からユーザ位置管理部590がユーザの入店状況要求を取得した場合、ユーザ情報が管理されているかどうかを判別し、ユーザ位置情報管理テーブル555にて当該ユーザが正しく管理されている場合は、要求時点での入店状況を抽出し、店舗情報応答通知部580へ通知を依頼する。ただし、入店状況は、ユーザ情報ごとに記録されている最後が出入り口の外側を通過した旨を記録している場合は退店を示し、出入り口の内側を通過した旨を記録している場合は入店中と判断する。ユーザ情報が不正な場合は、エラー処理を行い回答できない旨の結果を表示する。店舗情報応答通知部580は、依頼された内容について管理サーバー10へ通知する。
図55は、店舗情報管理サーバーが行うアイテム情報取得処理フローの一例を示す。店
舗管理サーバーは、アイテムコード(商品コード等)及びアイテム情報(商品情報等)を管理している。
管理サーバー10からアイテム情報抽出部520がアイテムコードを取得し、アイテム情報要求を取得した場合、アイテムコードが正しいかどうかを判別し、正しい場合は、アイテム情報管理テーブル535からアイテム情報を抽出する。同時にアイテム管理テーブル525からアイテムコードを元に棚番号を抽出し、店舗情報応答通知部580へ通知を依頼する。アイテムコードが不正な場合は、エラー処理を行い回答できない旨の結果を表示する。店舗情報応答通知部580は、依頼された内容について管理サーバー10へ通知する。
以上、歩行者ナビゲーションのサービスについて、店舗を例にして説明してきたが、他にも、例えば、地下鉄のホームで、どの方向に移動することが目的地に一番近いかを利用者に通知するような用途や地下駐車場に駐車した自動車まで案内するといった利用が可能である。
また、博物館や美術館、水族館など展示物の補足情報を提供するために拡張現実技術を利用するような用途でも、上述した音響マーカーシステムによる位置情報取得技術を適用できる。従来技術では実現が困難であったような屋内環境でのシステム化を図ることができる。
上述した店舗情報管理サーバーのように、歩行者ナビゲーションや拡張現実の各ユーザの動線の情報を収集すると、この情報を事業者がサービス向上を図るための情報として利用することができる。また、施設の警備や鉄道事業者の係員の配置などに関して、管理者が現在位置を把握するような用途での利用も可能である。
上述した店舗情報管理サーバーのように、入店管理を行うと、小売店向けのポイントプログラムやクーポン券発行の条件として、来店を求めるような用途において、確実に入店したかどうかを位置情報によって把握することができる。従来技術では、GPSやWiFiによって位置推定を行うことが多いため、実際に入店せずに利用者がチェックインすることは可能であったが、本技術では、高音域の音声信号を利用するためエリアを限定しやすくなっており、店内に入らないとチェックインできないような制限が可能である。また、リアルタイムで位置を取得できるため、入り口を通過した瞬間に入店を確認することができる。
本技術によってポスターなどの掲示物に関する情報を提供すると、従来の二次元コードのスキャンのように一つの二次元コードを同時に取得できるのは一名だけという制約がなく、一度に多人数が同時に情報を取得させることができる。
本技術を利用するデバイスを保持する歩行者は、歩きながら音響信号を取得することができるため、例えば、展示会などにおいて通過したブースを特定することができ、資料を自動的に取得することができる。また、路上などで配布される広告や割引券のような情報も、同様に取得することができる。
テレビ放送やラジオ放送において、本技術を用いた音響信号を発信することによって、あらかじめ配布したアプリケーションと連動した商品紹介や購入支援を行うことも可能である。音響信号は、時々刻々変化させることができるため、出演者の衣装や楽曲などの情報も提供できる。
以上、本発明の実施形態について説明したが、上述の実施形態を本発明の範囲内で当業
者が種々に変形、応用して実施できることは勿論である。