特許 5969937 複数の信号出力装置を管理するためのサーバー装置及び携帯機器用プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5969937

(24)【登録日】2016年7月15日

(45)【発行日】2016年8月17日

(54)【発明の名称】複数の信号出力装置を管理するためのサーバー装置及び携帯機器用プログラム

(51)【国際特許分類】

   H04W 24/08 20090101AFI20160804BHJP

【ＦＩ】

   H04W24/08

【請求項の数】4

【全頁数】41

(21)【出願番号】特願2013-37129(P2013-37129)

(22)【出願日】2013年2月27日

(65)【公開番号】特開2014-165814(P2014-165814A)

(43)【公開日】2014年9月8日

【審査請求日】2014年4月16日

【審判番号】不服2015-12279(P2015-12279/J1)

【審判請求日】2015年6月29日

(73)【特許権者】

【識別番号】391021710

【氏名又は名称】株式会社インテック

(74)【代理人】

【識別番号】230104019

【弁護士】

【氏名又は名称】大野 聖二

(74)【代理人】

【識別番号】100105038

【弁理士】

【氏名又は名称】田中 久子

(74)【代理人】

【識別番号】100131451

【弁理士】

【氏名又は名称】津田 理

(72)【発明者】

【氏名】永見 健一

(72)【発明者】

【氏名】遠藤 貴裕

(72)【発明者】

【氏名】吉澤 菜津子

【合議体】

【審判長】 佐藤 智康

【審判官】 水野 恵雄

【審判官】 北岡 浩

(56)【参考文献】

【文献】 再公表特許第２００７／１０８４０７（ＪＰ，Ａ１）

【文献】 特開２００４−２５２７９０（ＪＰ，Ａ）

【文献】 特開２００５−１４８４９０（ＪＰ，Ａ）

【文献】 特開平１１−１４６４４３（ＪＰ，Ａ）

【文献】 特開２０１１−２５７８５１（ＪＰ，Ａ）

【文献】 特開平８−２７４７０９（ＪＰ，Ａ）

【文献】 特開平１１−１６３７８４（ＪＰ，Ａ）

【文献】 特開２０１３−９０５３（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００６／００８７４７４（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

H04W24/00

(57)【特許請求の範囲】

【請求項1】

信号の届く範囲内に存在している携帯機器であれば受信可能な信号を連続的に出力する機能を有し、各々の信号が届く範囲が異なるように互いに離れて設置された、複数の信号出力装置を、管理するためのサーバー装置であって、
各々の信号出力装置が出力する信号により伝送される各々のデータに基づいて該信号がいずれの信号出力装置から出力されたものかを特定できるようにする手段と、
複数の信号出力装置のいずれかからの信号を受信して該信号により伝送されるデータを得た携帯機器に対して提供したい情報を記憶する手段と、
前記情報を前記データに対応付けてキャッシュする機能を備える携帯機器が、受信した前記信号から得たデータに対応する情報を該キャッシュから取得した場合に、前記データに対応する情報を取得したことを示すメッセージを、前記携帯機器から受信する手段と、
前記携帯機器からの前記メッセージの受信状況に基づいて、出力すべき信号を正常に出力していない故障状態にあると評価される信号出力装置を検出する手段とを備えることを特徴とするサーバー装置。

【請求項2】

信号の届く範囲内に存在している携帯機器であれば受信可能な信号を連続的に出力する機能を有し、各々の信号が届く範囲が異なるように互いに離れて設置された、複数の信号出力装置を、管理するためのサーバー装置として、コンピュータを動作させるために、該コンピュータにインストールされるプログラムであって、
各々の信号出力装置が出力する信号により伝送される各々のデータに基づいて該信号がいずれの信号出力装置から出力されたものかを特定できるようにするためのプログラムコードと、
複数の信号出力装置のいずれかからの信号を受信して該信号により伝送されるデータを得た携帯機器に対して提供したい情報を記憶するためのプログラムコードと、
前記情報を前記データに対応付けてキャッシュする機能を備える携帯機器が、受信した前記信号から得たデータに対応する情報を該キャッシュから取得した場合に、前記データに対応する情報を取得したことを示すメッセージを、前記携帯機器から受信するためのプログラムコードと、
前記携帯機器からの前記メッセージの受信状況に基づいて、出力すべき信号を正常に出力していない故障状態にあると評価される信号出力装置を検出するためのプログラムコードとを備えることを特徴とするコンピュータ用プログラム。

【請求項3】

携帯機器にインストールされて、該携帯機器に対してシステムから情報を提供可能とするためのプログラムであって、
前記システムは、信号の届く範囲内に存在している携帯機器であれば受信可能な信号を連続的に出力する機能を有し、各々の信号が届く範囲が異なるように互いに離れて設置された、複数の信号出力装置と、これら複数の信号出力装置を管理するためのサーバー装置とを含むものであり、
前記サーバー装置は、複数の信号出力装置のいずれかからの信号を受信して該信号により伝送されるデータを得た携帯機器に対して提供したい情報を記憶する機能を備えるものであり、
前記プログラムは、
前記情報を前記データに対応付けて前記携帯機器にキャッシュするためのプログラムコードと、
前記信号が前記携帯機器に受信されたことに応じて、前記データに対応する情報を前記キャッシュから取得するためのプログラムコードと、
前記データに対応する情報を取得したことを示すメッセージを、前記携帯機器から前記サーバー装置へ送信することにより、前記サーバー装置が、出力すべき信号を正常に出力していない故障状態にあると評価される信号出力装置を検出することを可能にするためのプログラムコードとを備えることを特徴とする携帯機器用プログラム。

【請求項4】

システムから情報の提供を受けることが可能な携帯機器であって、
前記システムは、信号の届く範囲内に存在している携帯機器であれば受信可能な信号を連続的に出力する機能を有し、各々の信号が届く範囲が異なるように互いに離れて設置された、複数の信号出力装置と、これら複数の信号出力装置を管理するためのサーバー装置とを含むものであり、
前記サーバー装置は、複数の信号出力装置のいずれかからの信号を受信して該信号により伝送されるデータを得た携帯機器に対して提供したい情報を記憶する機能を備えるものであり、
前記携帯機器は、
前記情報を前記データに対応付けてキャッシュする手段と、
前記信号が受信されたことに応じて、前記データに対応する情報を前記キャッシュから取得する手段と、
前記データに対応する情報を取得したことを示すメッセージを、前記サーバー装置へ送信することにより、前記サーバー装置が、出力すべき信号を正常に出力していない故障状態にあると評価される信号出力装置を検出することを可能にする手段とを備えることを特徴とする携帯機器。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、各々の場所に設置されている信号出力装置を利用して、移動する携帯機器のその時々の場所を把握し、各場所に応じた情報もしくはサービスを提供するシステムにおいて、各信号出力装置を遠隔から管理するための技術に関する。

【背景技術】

【0002】

近年、ＧＰＳの電波が届きにくい屋内や地下等の空間において、携帯機器の使用者が歩行中に、該携帯機器の位置情報をリアルタイムで得て、位置情報に依存した情報やサービスを提供するための技術が、活発に開発されている（例えば、非特許文献１を参照）。

【0003】

本出願人も、特願２０１１−２５０１５０（本出願人の未公開の先願）に示されるように、可聴周波数の上限域を利用する音響信号を出力する複数の信号出力装置を設置して位置情報関連サービスを行うための技術を、開発している。

【先行技術文献】

【非特許文献】

【0004】

【非特許文献1】「活用始まる屋内測位 高精度化で広がる用途」日経エレクトロニクス ２０１２年２月２０日号、６５〜７１頁

【発明の概要】

【発明が解決しようとする課題】

【0005】

上記のようなシステムでは、所望のサービスを実現するために信号出力装置を多数配置する際、その費用を抑制するため、各信号出力装置にネットワーク接続機能を設けないことが考えられる。システムの運用に当たり、これらの音響信号装置が正常に動作しているか（故障していないか）を管理する必要があるが、ネットワーク接続機能がない場合、システムの管理者等が、各々の信号出力装置が設置されている現場に頻繁に出向いて、故障の有無を調べなければならない。しかも、屋内測位用の信号は、人間に見えたり聞こえたりするものではないため、計測器を持って行って調べなければならず、管理に手間がかかってしまう。

【0006】

本発明は、携帯機器の場所に依存した情報やサービスを提供するためのシステムにおいて、分散配置される複数の信号出力装置が、ネットワーク接続されていない場合でも、各信号出力装置の故障の有無等の動作状態を遠隔から監視することができるようにすることを目的とする。

【課題を解決するための手段】

【0007】

本発明の原理に従う一例に係るサーバー装置は、複数の信号出力装置を管理するためのサーバー装置であって、該複数の信号出力装置は、信号の届く範囲内に存在している携帯機器であれば受信可能な信号を連続的に出力する機能を有し、各々の信号が届く範囲が異なるように互いに離れて設置されたものである。本サーバー装置は、各々の信号出力装置が出力する信号により伝送される各々のデータに基づいて該信号がいずれの信号出力装置から出力されたものかを特定できるようにする手段と、複数の信号出力装置のいずれかからの信号を受信して該信号により伝送されるデータを得た携帯機器から、該データを含むメッセージを受信する手段と、前記携帯機器からの前記メッセージの受信状況に基づいて、出力すべき信号を正常に出力していない故障状態にあると評価される信号出力装置を検出する手段とを備える。

【0008】

この構成によれば、信号出力装置から出力されている信号を受信した携帯機器が、場所に依存した情報やサービスの提供を受けるためにサーバー装置へネットワーク接続されることを利用して、サーバー装置において、現に携帯機器に受信されている信号の出力元の信号出力装置を特定可能なデータを含むメッセージを、携帯機器から受信し、これらのメッセージの受信状況に基づいて、各音響信号装置が正常に動作しているか（故障していないか）を評価することにより、システムの管理者等が点検や修理等を行うべき信号出力装置を検出することが可能になる。

【0009】

上記のサーバー装置は、各々の信号出力装置が出力すべき信号を正常に出力している場合に携帯機器から受信されるはずである前記メッセージが受信されないことに基づいて、前記故障状態の評価を行うことができる。

【0010】

ここで、ある信号出力装置が出力すべき信号を正常に出力している場合に携帯機器から受信されるべきメッセージが、受信されていないという判断は、以下のように、様々な手法により行うことができる。

【0011】

第１の手法では、前記サーバー装置は、ある信号出力装置についての前記メッセージを最後に携帯機器から受信した時からの時間経過が所定値を超えていることに基づいて、該ある信号出力装置が前記故障状態にあると評価する。

【0012】

第２の手法では、前記サーバー装置は、ある信号出力装置についての過去の前記メッセージの受信パターンを用いて、該ある信号出力装置が出力すべき信号を正常に出力している場合に携帯機器から受信されるはずである前記メッセージが受信されていないという判断を行い、この判断に基づいて、該ある信号出力装置が前記故障状態にあると評価する。

【0013】

第３の手法では、前記サーバー装置は、ある信号出力装置の周囲に設置された信号出力装置についての携帯機器からの前記メッセージの受信状況と、該ある信号出力装置についての携帯機器からの前記メッセージの受信状況とを比較して、該ある信号出力装置が出力すべき信号を正常に出力している場合に携帯機器から受信されるはずである前記メッセージが受信されていないという判断を行い、この判断に基づいて、前記故障状態にあると評価する。

【0014】

第４の手法では、前記携帯機器が、前記信号出力装置によらない測位機能を備えており、前記サーバー装置は、前記携帯機器の移動に伴う位置の履歴を含むメッセージを受信する手段を備え、前記位置の履歴に信号の届く範囲が含まれる信号出力装置についての携帯機器からの前記メッセージが受信されていないことに基づいて、該信号出力装置が前記故障状態にあると評価する。

【0015】

第５の手法では、前記携帯機器が、受信した信号からデータを得る際に該信号に含まれていたエラーを検出する機能を備えており、前記サーバー装置は、前記携帯機器から前記データを含むメッセージとともに前記エラーの情報を受信し、前記エラーの検出状況に基づいて、故障状態にあると評価される信号出力装置を検出する。

【0016】

第６の手法は、前記携帯機器が、受信した信号からデータを得る際に該信号の大きさを検出する機能を備えており、前記サーバー装置は、前記携帯機器から前記データを含むメッセージとともに前記信号の大きさの情報を受信し、前記信号の大きさの変化に基づいて、故障状態にあると評価される信号出力装置を検出する。

【0017】

上記第１〜第６の手法のうちの二つ以上を適宜組み合わせて用いても構わない。

【0018】

上記第４〜第６の手法を用いるために、携帯機器に対してシステムから情報又はサービスを提供可能とするためのプログラムであって、複数の信号出力装置のいずれかからの信号が前記携帯機器に受信されると、該信号により伝送されたデータを含むメッセージを、前記携帯機器から前記サーバー装置へ送信することにより、前記サーバー装置に、前記携帯機器が受信した信号がいずれの信号出力装置から出力されたものかを特定して前記情報又はサービスの提供を行わせるためのプログラムコードと、前記サーバー装置に、出力すべき信号を正常に出力していない故障状態にあると評価される信号出力装置を検出させるための付加的な情報を含むメッセージを、前記携帯機器から前記サーバー装置へ送信するためのプログラムコードとを備えるプログラムを、携帯機器にインストールするようにしてもよい。

【0019】

上記第４の手法の場合、前記携帯機器が、前記信号出力装置によらない測位機能を備えており、前記サーバー装置へ送信する付加的な情報を、前記携帯機器の移動に伴う位置の履歴とすることで、前記サーバー装置に、前記位置の履歴に信号の届く範囲が含まれる信号出力装置についての前記データを含むメッセージが携帯電話から受信されていないことに基づいて、該信号出力装置が前記故障状態にあると評価させる。

【0020】

上記第５（又は第６）の手法の場合、前記携帯機器が、受信した信号からデータを得る際に該信号に含まれていたエラーを検出する（又は該信号の大きさを検出する）機能を備えており、前記サーバー装置へ送信する付加的な情報を、前記エラーの情報（又は前記信号の大きさの情報）とすることで、前記サーバー装置に、前記データ及び前記エラーの検出状況（又は前記信号の大きさの変化）に基づいて、故障状態にあると評価される信号出力装置を検出させる。

【0021】

上記のサーバー装置は、各々の信号出力装置からの信号を受信した携帯機器に対して提供したい情報を記憶する手段と、前記データを含むメッセージを送信してきた携帯機器へ、該データに基づいて特定される信号出力装置に対応して記憶されている前記情報を提供する手段とをさらに備えてもよい。

【0022】

これにより、信号出力装置から出力されている信号を受信した携帯機器が、場所に依存した情報を取得受けるためにサーバー装置へ送信するメッセージを利用して、サーバー装置において、これら携帯機器からのメッセージの受信状況に基づいて、各音響信号装置が正常に動作しているか（故障していないか）を評価することが可能になる。

【0023】

上記のサーバー装置と通信する前記携帯機器が、一部の信号出力装置に対応する前記情報をキャッシュし、キャッシュが存在しない信号出力装置に対応する前記情報を前記サーバー装置へ要求する機能を備えている場合、前記携帯機器からの前記データを含むメッセージに、前記情報を前記キャッシュから取得したことを示す第１のメッセージと、前記情報を前記サーバー装置に要求する第２のメッセージとがあるようにし、前記サーバー装置の前記故障状態にあると評価される信号出力装置を検出する手段は、前記第１及び第２のメッセージに基づいて検出を行うようにし、前記サーバー装置の前記情報を提供する手段は、前記第２のメッセージに応答して提供を行うようにしてもよい。

【0024】

上記キャッシュ機能を有する携帯機器を実現するために、携帯機器に対してシステムから情報又はサービスを提供可能とするためのプログラムであって、複数の信号出力装置のいずれかからの信号が前記携帯機器に受信されると、該信号により伝送されたデータを含むメッセージを、前記携帯機器から前記サーバー装置へ送信することにより、前記サーバー装置に、前記携帯機器が受信した信号がいずれの信号出力装置から出力されたものかを特定して前記情報又はサービスの提供を行わせるためのプログラムコードと、前記サーバー装置に、出力すべき信号を正常に出力していない故障状態にあると評価される信号出力装置を検出させるための付加的な情報を含むメッセージを、前記携帯機器から前記サーバー装置へ送信するためのプログラムコードとを備えるプログラムを、携帯機器にインストールするようにしてもよい。

【0025】

この場合、上記プログラムをインストールした携帯機器は、一部の信号出力装置に対応する前記情報をキャッシュし、キャッシュが存在しない信号出力装置に対応する前記情報を前記サーバー装置へ要求する機能を備えるようになり、前記情報を前記キャッシュから取得したことを前記サーバー装置へ送信する付加的な情報が示すようにすることで、前記サーバー装置に、前記データを含むメッセージ及び前記付加的な情報を含むメッセージに基づいて、故障状態にあると評価される信号出力装置を検出させる。

【0026】

上記の構成において、前記第１のメッセージを、前記携帯機器が前記情報を前記キャッシュから取得した回数をも示すものとし、前記サーバー装置は、前記第１のメッセージが示す情報取得回数に基づいて、前記携帯機器に対する課金を行う手段を備えるようにしてもよい。

【0027】

これにより、サーバー装置は、キャッシュ機能を有する携帯機器についても、前記情報を利用した回数を適切に把握して、サービスに関する課金を行うことが可能になる。

【0028】

上記のサーバー装置は、前記携帯機器がいずれの信号出力装置の近隣を通って移動したかを示す情報を収集して提供されるサービスのために、前記データを含むメッセージを送信してきた各々の携帯機器につき、該データに基づいて特定される位置の情報を、前記サービスへ伝える手段をさらに備えてもよい。

【0029】

これにより、信号出力装置から出力されている信号を受信した携帯機器が、場所に依存したサービスを提供されるためにサーバー装置へ送信するメッセージを利用して、サーバー装置において、これら携帯機器からのメッセージの受信状況に基づいて、各音響信号装置が正常に動作しているか（故障していないか）を評価することが可能になる。

【0030】

前記複数の信号出力装置は、可聴周波数の上限域を利用する音響信号又はＢｌｕｅｔｏｏｔｈ（登録商標）の信号を出力するものとしてもよい。

【0031】

これにより、携帯機器としてスマートフォン等の一般に広く普及している機器に内蔵されている機能を用いて、信号出力装置から出力される信号を受信することが可能になる。

【0032】

前記各々の信号出力装置は、可聴周波数の上限域を利用する周波数域に含まれる所定数の周波数から、該信号出力装置を特定するためのデータに対応する一つ又は複数の周波数を選択し、選択された周波数の正弦波を音響信号として出力するものとしてもよい。

【0033】

このように、人間には認識されにくい高音域の音響信号を用いた音響マーカー技術を使用すると、屋内や地下空間でも運用でき、位置情報等を高速に検出し、検出誤差も運用環境に合わせて小さくすることが可能になる。

【0034】

本発明の原理に従えば、サーバー装置は、音波に変復調をかけることによって伝送すべきデータを音響信号に含ませる方式の信号出力装置に対しても、上述したように一つ又は複数の周波数を重畳した高音域の正弦波を変復調せずに出力する際の周波数の選択によって伝送すべきデータを音響信号に含ませる方式の信号出力装置に対しても、故障の有無等の動作状態を遠隔から監視することができるようになる。

【0035】

後者の方式の音響信号を受信した携帯機器に、信号を解析させ、抽出されたデータ（例えば、音響信号識別ＩＤ）を基に、携帯機器に情報（位置情報等）が提供されるようにする場合、高音域の正弦波の周波数検出は、携帯機器において高速に行えるため、静止状態でなく、歩行速度でも、リアルタイムで位置検出が可能になる。検出された周波数により表されるデータに基づいて得られる位置情報を、絶対位置としてそのまま用いてもよいし、歩行者自律航法（ＰＤＲ）等により取得される相対的な位置情報を補正するのに用いてもよい。

【0036】

後者の方式において、前記音響信号により伝送されるデータが所定数のビットで表され、各ビットの値は前記所定数の周波数の各々の正弦波の出力の有無で表されるものとしてもよい。

【0037】

これにより、高音域の正弦波の周波数を検出した携帯機器は、例えば、所定数の周波数の並びのうち、検出された周波数については値を１とし、検出されなかった周波数については値を０として、ビット列に置き換えることにより、信号出力装置から伝送されたデータを得ることができ、より高速な処理が可能になる。

【0038】

上記音響信号の可聴周波数の上限域を利用する周波数域を、複数のサブ周波数域に分割し、前記各々の信号出力装置は、該信号出力装置を特定するためのデータに対応する周波数を、前記複数のサブ周波数域のうちの一つに含まれる周波数から選択するものとし、前記サーバー装置は、音響信号が届く範囲が重なる二つ以上の信号出力装置が互いに異なるサブ周波数域内で前記周波数の選択を行うように、前記各々の信号出力装置に対する前記データを定める手段を備えてもよい。

【0039】

これにより、二つ以上の信号出力装置からの音響信号を同時に携帯機器が受信しても、互いに異なるサブ周波数領域内で選択された周波数が受信されることになるため、音響信号が干渉するのを防止することが可能になる。

【0040】

さらに、前記音響信号により伝送されるデータが、一つのサブ周波数域に含まれる周波数のうちのいずれが選択されているかと、いずれのサブ周波数域が用いられているかとの組み合わせにより、表されるようにしてもよい。

【0041】

これにより、音響信号の干渉を防止しつつ、音響信号により伝達可能な情報量を、一つのサブ周波数域を構成する周波数の個数分のビットが持つ情報量から、周波数域の個数倍、増加させることが可能になる。

【0042】

そして、前記サーバー装置が、音響信号が届く範囲が重なる信号出力装置の数が前記サブ周波数域の数を超えないように制御する手段を含むようにしてもよい。

【0043】

これにより、システム全体に亘って、音響信号の干渉が起こる場所がないようにすることが可能になる。サブ周波数域の数が所与であり、音響信号が届く範囲が重なる信号出力装置の数がその所与の数以下になるように、信号出力装置の配置及び／又は出力レベルを制御してもよいし、音響信号が届く範囲が重なる信号出力装置の数が所与であり、サブ周波数域の数をその所与の数に合わせて、周波数域の分割を行うように制御してもよい。

【0044】

上記音響信号により伝送される複数のビットが、音響信号により伝送されるデータを表すビットに加えて、誤り訂正のためのビットを含むようにし、前記携帯機器は、受信された音響信号から検出されたビットに誤り訂正の処理を行って、前記データを得るようにしてもよい。このときの誤り訂正の処理から、上記第５の手法で用いられるエラーの情報を得ることができる。

【0045】

本発明の原理に従う別の例に係るサーバー装置の管理の対象となる複数の信号出力装置は、該サーバー装置と通信可能であって、出力された信号を受信する機能を有する。この場合のサーバー装置は、各々の信号出力装置が出力する信号により伝送される各々のデータに基づいて該信号がいずれの信号出力装置から出力されたものかを特定できるようにする手段と、各々の信号出力装置から、該信号出力装置が出力すべき信号が該信号出力装置により受信されているか否かを示すメッセージを受信する手段と、前記メッセージの受信状況に基づいて、出力すべき信号を正常に出力していない故障状態にあると評価される信号出力装置を検出する手段とを備える。

【0046】

この構成によれば、各々の信号出力装置から実際に信号が出力されているかを、各信号出力装置自体が信号を受信することにより調べ、その結果がサーバー装置へ収集されるため、サーバー装置において、故障している信号出力装置を検出することが可能になる。

【0047】

上述したサーバー装置の全ての発明は、サーバー装置及び複数の信号出力装置を構成要素とするシステムの発明としても、システム全体の方法の発明としても、システムを構成する信号出力装置の発明としても、サーバー装置で行われる方法の発明としても、システムを利用する携帯機器の装置又は方法の発明としても、さらに、汎用のコンピュータもしくは携帯機器にインストールされて上述した発明を実現するためのプログラム（又はそのプログラムを記録した記録媒体）の発明としても、成立するものである。

【0048】

例えば、本発明の原理に従う一例に係るプログラムは、コンピュータを複数の信号出力装置を管理するためのサーバー装置として動作させるために、該コンピュータにインストールされるプログラムである。前記複数の信号出力装置は、信号の届く範囲内に存在している携帯機器であれば受信可能な信号を連続的に出力する機能を有し、各々の信号が届く範囲が異なるように互いに離れて設置されたものである。本プログラムは、各々の信号出力装置が出力する信号により伝送される各々のデータに基づいて該信号がいずれの信号出力装置から出力されたものかを特定できるようにするためのプログラムコードと、複数の信号出力装置のいずれかからの信号を受信して該信号により伝送されるデータを得た携帯機器から、該データを含むメッセージを受信するためのプログラムコードと、前記携帯機器からの前記メッセージの受信状況に基づいて、出力すべき信号を正常に出力していない故障状態にあると評価される信号出力装置を検出するためのプログラムコードとを備える。

【発明の効果】

【0049】

以上のとおり、本発明によれば、携帯機器の場所に依存した情報やサービスを提供するためのシステムにおいて、分散配置される複数の信号出力装置が、ネットワーク接続されていない場合でも、各信号出力装置の故障の有無等の動作状態を、サーバー装置において集中的に監視することが可能になる。

【図面の簡単な説明】

【0050】

【図1】本発明の実施の形態の一例に係る音響マーカーシステムの全体構成を示す図。

【図2】音域グループ別に、音響信号のビット列に周波数（ｋＨｚ）を割り当てた一例を示す図。

【図3】音域グループ別に、音響信号識別ＩＤをリストにした一例を示す図。

【図4】本例におけるサーバーの内部構成例を示すブロック図。

【図5】音響マーカー管理テーブル（サーバー）の一例を示す図。

【図6】音響信号管理テーブル（サーバー）の一例を示す図。

【図7】付帯情報管理テーブル（サーバー）の一例を示す図。

【図8】サーバーによる音響信号の割り振り処理の一例を示すフロー図。

【図9】サーバーによる音響信号の再割り振り処理の一例を示すフロー図。

【図10】サーバーによる伝達範囲の調整処理の一例を示すフロー図。

【図11】サーバーによる位置情報等の提供処理の一例を示すフロー図。

【図12】本例における音響マーカーの内部構成例を示すブロック図。

【図13】音響マーカーによる音響信号の出力処理の一例を示すフロー図。

【図14】音響マーカーによる出力レベルの調整処理の一例を示すフロー図。

【図15】本例におけるデバイスの内部構成例を示すブロック図。

【図16】デバイスによる音響信号入力から位置情報等取得までの処理の一例を示すフロー図。

【図17】エラー訂正符号によるエラー検出及び訂正の一例を示す図。

【図18】サーバーにおいて各音響マーカーの故障の検出を行うためのデバイス及びサーバーの動作の第１の例を示す図。

【図19】サーバーにおいて各音響マーカーの故障の検出を行うためのデバイス及びサーバーの動作の第２の例を示す図。

【図20】サーバーにおいて各音響マーカーの故障の検出を行うためのデバイスの動作の第３の例を示す図。

【図21】サーバーにおいて各音響マーカーの故障の検出を行うためのサーバーの動作の第３の例を示す図。

【図22】本例におけるデバイスがキャッシュを利用する場合の内部構成例を示すブロック図。

【図23】サーバーにおいて各音響マーカーの故障の検出を行うためのデバイスのキャッシュを利用する場合の動作例を示す図。

【図24】サーバーにおいて各音響マーカーの故障の検出を行うためのサーバーのキャッシュを利用する場合の動作例を示す図。

【図25】本発明の実施の形態の別の例に係る音響マーカーシステムの全体構成を示す図。

【図26】セルが２次元に広がるエリア（部屋等）で４つの音域グループを使用した場合の音響マーカーの配置例を示す図。

【図27】セルが２次元に広がるエリア（部屋等）で３つの音域グループを使用した場合の音響マーカーの配置例を示す図。

【図28】セルが２次元に広がるエリア（部屋等）で２つの音域グループを使用した場合の音響マーカーの配置例を示す図。

【図29】セルが２次元に広がるエリア（部屋等）で１つの音域グループを使用した場合の音響マーカーの配置例を示す図。

【図30】セルが１次元に延びるエリア（通路等）で４つの音域グループを使用した場合の音響マーカーの配置例を示す図。

【図31】セルが１次元に延びるエリア（通路等）で３つの音域グループを使用した場合の音響マーカーの配置例を示す図。

【図32】セルが１次元に延びるエリア（通路等）で２つの音域グループを使用した場合の音響マーカーの配置例を示す図。

【図33】セルが１次元に延びるエリア（通路等）で１つの音域グループを使用した場合の音響マーカーの配置例を示す図。

【図34】複数のエリアに分割される場所で４つの音域グループを使用した場合の音響マーカーの配置例を示す図。

【図35】複数のエリアに分割される場所で３つの音域グループを使用した場合の音響マーカーの配置例を示す図。

【図36】複数のエリアに分割される場所で２つの音域グループを使用した場合の音響マーカーの配置例を示す図。

【図37】複数のエリアに分割される場所で１つの音域グループを使用した場合の音響マーカーの配置例を示す図。

【図38】歩行者ナビゲーションサービスにおいて入店・退店判定を行うシステムの一例を説明するための図。

【図39】歩行者ナビゲーションサービスにおいて店内に音響マーカーを配置した一つの例を示す図。

【図40】歩行者ナビゲーションサービスにおいて店内に音響マーカーを配置した別の例を示す図。

【発明を実施するための形態】

【0051】

以下、本発明の実施の形態に係る情報提供システムについて、例示のために、図面を用いて説明する。

【0052】

本例に係る情報提供システムは、概略、次のような技術である。ネットワークに接続されたコンピュータと音声出力装置から構成される「音響マーカー」から、人間の耳には聞こえにくい高音域の音声信号（以下、音響信号という）を出力する。その音響信号をデバイスに内蔵されたマイクロフォンへ入力させ、音響信号を解析した結果抽出された音響信号識別番号（ＩＤ）等を基にネットワーク経由でサーバーへ問い合わせることで、位置情報及び／又はその他の情報（いずれも、各音響マーカーから音響信号を受信したデバイスに対して提供したい情報であり、以下、位置情報等という）を取得させることができる。

【0053】

なお、音響信号識別ＩＤ等と対応する位置情報等をデバイス内にキャッシュしておくことにより、音響信号を受信するだけで（サーバーへ問い合わせることなく）デバイスが位置情報等を求めることができるようにしてもよい。いずれにしても、音響信号を受信することにより、例えば、ＧＰＳが使えない屋内や地下街での測位（位置情報の取得）が可能になる。

【0054】

音響信号は、例えば、１５ｋＨｚ〜２２ｋＨｚ台の可聴周波数の上限域（超音波音ともいう）を使用する。この音域の音声は、一般の人間には聞き取ることができない音域であり、周囲に気づかれることなく信号を出すことができる。当然ながら、写真や映像にも写らないため、運用環境の景観を損ねることもない。また、この周波数帯を使用することで、超音波用の専用機器ではなく、通常市販されるスピーカー等の音声出力装置を流用することができる。

【0055】

本技術を適用したシステム（以下、音響マーカーシステムともいう）は、例えば、図１に示すように、サーバー１０と、Ｎ個の音響マーカー２０−１〜２０−Ｎと、Ｍ個のデバイス（例えばスマートフォンやタブレット等の音声を利用できる携帯型情報機器）３０−１〜３０−Ｍとにより構成される。このうち、デバイスは、情報を利用する各ユーザにより使用されるものであるので、例えば、サーバーと音響マーカーとからなるシステム６０を、情報提供システムと呼んでも構わない。サーバー１０には、このサーバーを用いて情報提供システムの管理を行う管理者が使用するための管理端末４０が、１つ又は複数、直接もしくはネットワーク経由で接続されていてもよい。

【0056】

サーバー１０は、各音響マーカー２０が出力する音響信号が表す音響信号識別ＩＤを記憶しており、ネットワーク（例えばインターネットプロトコル（ＩＰ）ネットワーク等）５０により接続されるデバイス３０から要求された情報についての提供を行うとともに、各デバイス３０から収集したデバイス３０における音響信号受信状況に関する情報に基づいて各音響マーカー２０の故障の検出を行う。このサーバー１０に接続された管理端末４０において、各音響マーカー２０の故障検出状況を表示することにより、情報提供システムの管理者は、ネットワークに接続されていない音響マーカー群についても、一元的に管理することが可能になる。

【0057】

本例では、各音響マーカー２０がサーバー１０にネットワーク接続されておらず、各音響マーカー２０が出力すべき音響信号を各音響マーカー２０に設定する作業を人手により行うものとするが、音響マーカー群を設置する場所に敷設されている固定通信網を利用する等して各音響マーカー２０をサーバー１０にネットワーク接続し、サーバー１０が各音響マーカー２０への音響信号識別ＩＤの割り振り及び出力指示等の管理を自動的に行うようにしてもよい。

【0058】

デバイス３０は、ユーザがデバイスを持ちながら移動するという形態で使用されるものであるため、ネットワーク５０は、無線ＬＡＮや携帯電話網等のネットワークであることが望ましい。

【0059】

音響マーカー２０は、指定された音響信号識別ＩＤが含まれた音響信号を指定された音量で再生する。複数台（Ｎ台）の音響マーカー３０を、同時に設置して動作させることができ、その数は、情報提供システムの運営者が適用したい情報サービスの内容によって定めればよい。

【0060】

デバイス３０は、音響信号を音声入力し、例えば、高速フーリエ変換（ＦＦＴ）を用いて音響信号識別ＩＤを抽出し、取得日時情報などと共にサーバーへ送って、位置情報等の提供を要求する。複数台（Ｍ台）のデバイス３０を、同時に情報提供システム６０に収容することができ、その数は、ネットワーク５０が輻輳しない限り、サービスを利用したいユーザの数だけ増加させることが可能である。

【0061】

本技術で用いる音響信号の基本構造は、例えば、次のようなものとする。音響マーカーの配置を管理するために、ロケーション、エリア、セルという概念を設け、それぞれには一意のＩＤが付与され識別できるように管理する。

【0062】

最も小さい単位はセルであり、１つの音響マーカーを設置する単位とする。複数のセルを含む同一の空間をエリアと呼ぶ。エリアは、屋内の場合に通路や居室、共有スペースなどを指す。複数のエリアを包含する概念がロケーションであり、同一の建物などを指す。

【0063】

ロケーションは、利用するアプリケーション側で明示的に指定することを想定しており、ロケーションＩＤを変更することでマルチテナント利用ができるようにすることが可能である。

【0064】

１つの音響信号は、例えば、全部で１２の正弦波を用いて構成し、変復調を行うことなく、１正弦波を１ビットとして定義している。各正弦波の間隔は、２００Ｈｚであり、高速フーリエ変換による解析の際の干渉を排除している。変復調を行わない理由としては、高速に信号を取得し、解析を行うためである。

【0065】

本技術では、変復調を行わず、１２ビット分の信号を一度に送信するため、例えば１分間に８０ｍ（１．３３ｍ／秒）歩行移動したとしても、音響マーカーから発出される音響信号をデバイス側で受信できる限りは、デバイスを保持している人の行動や動作に制約がかかることはない。

【0066】

本例では、１２ビットの音響信号は、エリアＩＤ、ユニークＩＤ、エラー訂正という３つの部分で構成される。１２ビットの各々につき、ビットの値が１の場合、そのビットに対応する周波数の正弦波を出力し、ビットの値が０の場合、そのビットに対応する周波数の正弦波は出力しない。

【0067】

エリアＩＤは、２進数で４ビット分（１０進数で０〜１５）を確保している。これにより、例えばある部屋から別の部屋へ移動したということがデバイス側で認識することができるようになる。

【0068】

ユニークＩＤは、エリアＩＤ内でただ一つとなる識別番号であり、２進数で４ビット分（１０進数で１〜１５）を確保している。このエリアＩＤにユニークＩＤを加えた８ビットが基本的な音響信号識別ＩＤであるが、自由空間を伝達されるため、信号の欠損などがあり得る。

【0069】

このような事故を防止するため、エラー訂正を行うために４ビット分を付加し、エラー検出と訂正に使用する。このエラー検出及び訂正には、エラー検出訂正符号方式を使用しており、２ビットエラー検出、１ビットエラー訂正を採用している。

【0070】

また、複数の音響信号を隣接する場所で使用することで混信が生じることを考慮し、超音波音の周波数帯域を、例えば４つの音域グループに分割して使用する。エリアＩＤ部は、共通の周波数帯域を使い、ユニークＩＤ部及びエラー訂正符号部は、音域グループ毎に別々の周波数帯域を使う。隣接するセルでは、同一の音域グループを使用しないように音響信号を割り当てる。ただし、音域グループＡから音域グループＤへ行く程、低い周波数帯となるため、人によっては聴覚で音響信号を感じる場合がある。

【0071】

図２に、音域グループ別に、音響信号のビット列に、正弦波の周波数（ｋＨｚ）を割り当てた一例を示す。音域欄は、音域をＡ〜Ｄの４つのグループに分割した例を示している。（１）を先頭ビットとして、（１２）まで並べて音響信号として認識させる。

【0072】

例えば、音域グループＡの先頭ビットの周波数は２２．０ｋＨｚであり、１２ビット目は１９．８ｋＨｚである。音域グループＢの先頭ビット〜４ビット目までの周波数は音域グループＡと共通であり、５ビット目は１９．６ｋＨｚであり、１２ビット目は１８．２ｋＨｚである。このように、ユニークＩＤ及びエラー訂正符号部については、異なる音域グループ間で、使用する周波数が重複しないように、割り当てられる。

【0073】

デバイスは、ＦＦＴの結果、当該周波数の成分を取得できた場合は、そのビットを1として認識し、周波数成分が取得できなかった場合は、そのビットを０として認識し、ビット配列を形成する。

【0074】

図３は、音域グループ別に、音響信号識別ＩＤをリストにした一例を示す。音域グループ毎に、エリアＩＤとユニークＩＤが指定される。一つの音域グループは１６のエリアに分割され、エリアＩＤ毎に１５のユニークＩＤが存在する。

【0075】

超音波音の周波数をＡ〜Ｄの４つの音域グループに分けて、すべての音域グループを使用する場合、同一エリアＩＤ内で分割できるセルは、４音域グループ×１５ユニークＩＤで最大６０セルである。Ａ〜Ｃの３つの音域グループを使用する場合は、３音域グループ×１５ユニークＩＤで最大４５セルを識別できる。Ａ〜Ｂの２つの音域グループを使用する場合は、２音域グループ×１５ユニークＩＤで最大３０セルが識別可能であり、Ａ音域グループのみを使用する場合は、最大１５セルを識別することができる。

【0076】

デバイスからサーバーへ情報を要求する際には、エリアＩＤ、ユニークＩＤ、音域グループの３つの要素を識別するために音響信号識別ＩＤを指定する。

【0077】

なお、音響信号のビット数は、１２ビットでなくてもよいし、音響信号が、ユニークＩＤとエラー訂正という２つの部分（それぞれ何ビットでも構わない）で構成されても、ユニークＩＤのみで構成されても構わない。

【0078】

図４に、サーバー１０の内部構成例を示す。サーバー１０は、音響マーカー２０及び音響信号についての管理を行い、デバイス３０による位置情報等要求への回答を伝達する機能を有するほか、デバイス３０からの位置情報等要求もしくはこれとは別の通信により音響信号受信状況を示す情報を収集し、音響マーカー２０の故障を検出する機能を有する。

【0079】

サーバー１０は、音響マーカーの管理と音響信号識別ＩＤの付与を行うために、音響マーカー登録部１００、音響信号識別ＩＤ選択部１０５を有する。また、音響信号識別ＩＤを再選択するために、音響マーカー変更部１２０、音響信号識別ＩＤ再選択部１２５を備える。この選択もしくは再選択の結果は、音響マーカー管理テーブル１５０に記憶され、音響マーカー管理部１１０を介して管理端末４０に表示される。これにより、本システムの管理者等が、各音響マーカーに割り振られた音響信号識別ＩＤの音響信号を出力するように各音響マーカーを設定して回ることができる。

【0080】

サーバー１０はまた、音響マーカーとデバイス間の伝達範囲の調整を行うために、伝達範囲調整依頼取得部１４０と出力レベル変更部１４５を有する。この出力レベルの変更結果は、音響マーカー管理テーブル１５０に記憶され、音響マーカー管理部１１０を介して管理端末４０に表示される。これにより、本システムの管理者等が、変更された出力レベルで音響信号を出力するように音響マーカーの設定をすることができる。

【0081】

サーバー１０はさらに、デバイスからの要求に応答し、位置情報等を伝達するために位置情報等要求取得部１６０、位置情報等要求確認部１６５、位置情報等抽出部１７０、位置情報等伝達部１７５を有する（これらをまとめて位置情報等処理部と呼ぶことがある）。

【0082】

上記の機能を実現するために、サーバー１０はデータベースを備え、音響マーカー管理テーブル１５０（図５）、音響信号管理テーブル１３０（図６）、付帯情報管理テーブル１８０（図７）を有する。サーバー１０と各デバイス３０との間はネットワーク５０により、接続されており、相互通信が可能である。

【0083】

図５に示される音響マーカー管理テーブル１５０は、例えば「最終取得日時」という項目を有しており、デバイス３０による位置情報等の要求に応じて音響マーカー管理テーブル１５０に登録された位置情報が抽出されたときに、その抽出された位置情報に対応する最終取得日時として、そのときの日時が記入されるようになっている。そして、サーバー１０の音響マーカー管理部１１０は、随時、この音響マーカー管理テーブルに記録された情報を解析し、各音響マーカーの故障状態を管理端末４０に表示する。

【0084】

デバイス３０から位置情報の要求があったということは、その位置情報に対応する音響信号識別ＩＤの音響信号を出力する音響マーカーは、その時点で正常に動作していることを意味するとして、本システムを運用することができる。各音響マーカーの音響信号を受信できる範囲に、多数のユーザのデバイス３０が出入りするとすれば、それぞれのユーザのデバイス３０からの位置情報等要求の受信状況を、サーバー１０において解析すれば、各音響マーカーが正常に動作しているか故障しているかを推定することが可能である。

【0085】

つまり、各デバイス３０は、音響マーカーからの音響信号を受信すると、サーバー１０へ、少なくとも音響信号識別ＩＤを含むメッセージを送信する。このメッセージは、位置情報等を要求するメッセージそのものでもよいし、それとは別に、音響信号の受信状況を示すメッセージをサーバー１０に送るようにしてもよい。サーバー１０は、音響マーカー管理テーブル１５０において、音響信号識別ＩＤと対応付いている音響マーカーのエントリに、デバイスからのメッセージを受信した時刻もしくはメッセージに含まれている時刻の情報を記録する。

【0086】

この時刻情報の記録は、特定のデバイスからのメッセージの受信についてのみ行ってもよいし、どのデバイスからのメッセージかを区別することなく全てについて時刻情報を記録してもよい。 また、メッセージを受信する都度、時刻情報を更新（上書き）して、「最終取得日時」により故障を判断してもよいし、複数の受信メッセージから生成された時刻情報の履歴を記録して、所定のパターンと比較することにより故障を判断してもよい。

【0087】

また、本例では、音響マーカー管理テーブル１５０に、メッセージ受信に係る時刻情報等の故障検出に用いる情報を記録しているが、音響信号識別ＩＤ（もしくはそれに対応する音響マーカーＩＤ）と故障検出に用いる情報とを、音響マーカー管理テーブル１５０とは別のテーブルとして記録するようにしても構わない。

【0088】

デバイスからのメッセージ受信がないことをもって音響マーカーの故障を判断する本例の方式では、デバイスを所持してその音響マーカーの音響信号が届く範囲を通過したユーザがいなかったのか、そのようなユーザがいたのにデバイスがサーバーへメッセージを送信してこなかった（すなわち、音響マーカーが故障していて音響信号がデバイスに受信されなかった）のかを、例えば次のように評価する。

【0089】

簡単な例では、一定期間、デバイスからのメッセージ受信がないものを、故障と判断する。その期間を、各音響マーカー（頻繁に利用者が訪れるところに設置してあるか、稀なところであるか）によって異なるように決めておいてもよい。

【0090】

より多くの情報を考慮する例では、同じ店舗や同じフロアの中に設置されている別の音響マーカーについてのメッセージ受信の状況（あるいはその他の手段で得られる利用者の数等の情報）から、多くの利用者が訪れているはずなのに、デバイスからの対応するメッセージ受信がないものを、故障と判断する。

【0091】

より多くの情報を考慮する他の例では、歩行者自律航法（ＰＤＲ）等の測位技術で、デバイスが位置している場所をある程度特定し、その特定した場所がある音響マーカーの音響信号が届く範囲にあるはずなのに、デバイスからの対応するメッセージ受信がないものを、故障と判断する。

【0092】

また、あるべきデバイスからのメッセージ受信がないという完全な故障に陥る前に、デバイスに音響信号は受信されサーバーへのメッセージ送信もできているが、デバイスが音響信号から音響信号識別ＩＤを取り出す際にエラー訂正を多く要していたり、デバイスが受信する音響信号の大きさが通常範囲を超えて変化していたりすることがあり得る。

【0093】

そのような場合も故障として検出して管理端末４０に表示するため、これらエラー訂正の情報や音量の情報も、デバイスからサーバーへのメッセージに含めるようにして、サーバーにおいて、故障の可能性が大きい音響マーカーとして判断するようにしてもよい。これらの付加的な情報は、故障の判断の精度を高める方向で利用してもよいし、まだ完全に故障していないが故障の予想される音響マーカーについても本システムの管理者等の注意を促す方向で利用してもよい。

【0094】

デバイスとして、例えば、スマートフォンを用いる場合、スマートフォンが本システムを利用する（音響信号を処理して位置情報等をサーバーへ要求し受信する）ことができるように、アプリケーションをダウンロードさせるとよい。上述したエラー訂正の情報及び／又は音量の情報等を、デバイスからサーバーへのメッセージに含める場合には、そのための機能も、スマートフォンにダウンロードするアプリケーションに含ませておけばよい。

【0095】

図８は、サーバー１０が、音響マーカー２０−１〜２０−Ｎを管理し、各々に音響信号識別ＩＤを付与するための処理の流れの一例を示す。

【0096】

まず、サーバーの音響マーカー登録部１００にて、音響マーカー管理テーブル１５０に対して、音響マーカーのＩＤ、名称、エリアＩＤ、エリア内のＸ，Ｙ座標（さらにＺ座標があってもよい）等の登録を行う（８００）。

【0097】

そして、音響マーカーの登録後、音響信号識別ＩＤ選択部１０５にて、音響信号管理テーブル１３０を参照し、指定されたエリアＩＤが属する未使用の音響信号識別ＩＤが存在するかを確認する（８０５）。未使用の音響信号識別ＩＤが存在する場合は、未使用のユニークＩＤが存在するかを確認する（８１０）。

【0098】

未使用のユニークＩＤが存在する場合にはその音響信号識別ＩＤを候補として抽出し、候補の中から１つのＩＤを選択する（８１５）。この際、音域グループは、隣接する音響マーカーの音域グループと同一にならないように自動的に選択してもよいし、登録者（本システムの管理者等）に任意に選択させるようにしてもよい。

【0099】

音響信号識別ＩＤ選択部１０５は、続いて有効期限情報を決定し（８２０）、音響信号管理テーブル１３０に対して、使用中フラグを０から１に変更し、音響マーカーＩＤ及び有効期限を登録する。

【0100】

未使用の音響信号識別ＩＤが存在しない場合、あるいは未使用の音響信号識別ＩＤが存在するが、当該エリア内のユニークＩＤが存在しない場合は、エラーを返す（８４０）。

【0101】

そして、本システムの管理者等は、音響マーカー２０−Ｋに対し、出力すべき音響信号の音響信号識別ＩＤ及び出力レベルを設定する。後述するようにサーバーと各音響マーカーがネットワーク接続される環境の場合は、サーバー１０が、音響マーカー２０−Ｋに対し、音響信号識別ＩＤ及び出力レベルを指示してもよい（８３０）。

【0102】

図９は、サーバー１０が、指定された音響マーカーに対して、音響信号識別ＩＤを付与しなおすための処理の流れの一例を示す。例えば、ある音響信号識別ＩＤの有効期限が過ぎた後に、同じ音響マーカーから別の音響信号識別ＩＤを流したい場合等に、この再割り振りの処理が行われる。

【0103】

まず、サーバーの音響マーカー変更部１２０は、本システムの管理者やサーバーで動作している該当サービスのプログラム等から、音響マーカー変更依頼を受け取り（９００）、当該音響マーカー及び音響信号識別ＩＤが登録済みかどうかを確認する（９０５）。音響マーカー変更依頼には、音響マーカーのＩＤと音響信号識別ＩＤと隣接する音響マーカーの音域グループ情報が含まれている。

【0104】

音響信号識別ＩＤ再選択部１２５は、現在選択されている音響信号識別ＩＤと同じエリアＩＤに属し、かつ音域グループが空きであり（９１０）ユニークＩＤが未使用である（９１５）音響信号識別ＩＤ群を抽出し、その中から１つのＩＤを選択する（９２０）。この際、音域グループは、隣接する音響マーカーの音域グループと同一にならないように自動的に選択してもよいし、登録者（本システムの管理者等）に任意に選択させるようにしてもよい。

【0105】

音響信号識別ＩＤ再選択部１２５は、続いて改めて有効期限情報を決定し（９２５）、音響信号管理テーブル１３０に対して、新しく選択された音響信号識別ＩＤのレコードについて、使用中フラグを０から１へ変更を行い、音響マーカーＩＤ及び有効期限を登録する。さらに、これまで割り振っていた音響信号識別ＩＤのレコードの使用中フラグを１から０に変更し、音響マーカーＩＤ及び有効期限を削除した上でレコードの更新を行う（９３０）。また、変更依頼の対象となっている音響マーカーまたは音響信号識別ＩＤが存在しない場合、あるいは新たに音響信号識別ＩＤを割り振ることができない場合は、エラーを返す（９５０）。

【0106】

そして、本システムの管理者等は、音響マーカー２０−Ｊに対し、出力すべき音響信号の音響信号識別ＩＤ及び出力レベルを設定する。後述するようにサーバーと各音響マーカーがネットワーク接続される環境の場合は、サーバー１０が、音響マーカー２０−Ｊに対し、音響信号識別ＩＤ及び出力レベルを指示してもよい（９４０）。

【0107】

図１０は、サーバー１０が、各音響マーカーの音響信号の出力レベル（伝達範囲）を調整するための処理の一例を示す。この伝達範囲の調整は、各々の音響マーカー２０−１〜２０−Ｎからの音響信号が伝達されることが望まれる位置にいて音響信号をモニターする各々のデバイス３０−１〜３０−Ｎからの情報に基づいて、行うことができる。１つの音響マーカーのモニター用デバイスが複数分散してあってもよく（例えば、３０−Ｃが３台、３０−Ｅが５台ある等）、１つのデバイスが隣接する複数のセルの音響マーカーからの音響信号をモニターするようにしてもよい。

【0108】

まず、サーバー１０の伝達範囲調整依頼取得部１４０は、デバイス３０からネットワーク５０を通じて、伝達範囲調整依頼を取得する（１０００）。当該依頼には、音響マーカーのＩＤと出力の増減についての情報が含まれる。

【0109】

出力レベル変更部１４５では、音響マーカー管理テーブル１５０を参照して、受け取った音響マーカーのＩＤが正しいかどうか調べ（１００５）、当該音響マーカーが存在する場合は、受け取った依頼に従って（１０１０）出力レベルを増加（１０１５）又は減少（１０２０）させ、音響マーカー管理テーブル１５０の当該音響マーカーのレコードに含まれる出力レベルを更新する（１０２５）。本システムの管理者等は、音響マーカー２０−Ｋに対し、更新された出力レベルを設定する。後述するようにサーバーと各音響マーカーがネットワーク接続される環境の場合は、サーバー１０が、音響マーカー２０−Ｋへ指示を行ってもよい。

【0110】

さらに、出力レベル変更部１４５は、音響マーカー２０−Ｋにおける変更結果を取得（１０４０）し、依頼元のデバイス３０−Ｋへネットワーク５０を通じて、結果を通知（１０６０）してもよい。なお、受け取った音響マーカーのＩＤが正しくない場合は、エラーを返す（１０５０）。

【0111】

図１１は、サーバー１０が、デバイスからの要求に応じて位置情報等を提供するための処理の一例を示す。

【0112】

サーバー１０の位置情報等要求取得部１６０は、それぞれのデバイス３０からネットワーク５０を通じて位置情報等の取得要求を受け取る（１１００）。当該要求には、音響信号識別ＩＤが含まれている。

【0113】

位置情報等要求確認部１６５は、音響信号管理テーブル１３０を参照し、受け取った要求に含まれる音響信号識別ＩＤの有効性を確認する（１１０５）。音響信号識別ＩＤが存在し、使用中フラグが１の場合は、受け取った要求に係る日時が、当該音響信号識別ＩＤのレコードの有効期限内かどうかを判断する（１１１０）。要求に係る日時は、デバイスが要求に含ませた音響信号受信日時でもよいが、サーバーが要求を受け取った日時とする方が安全性は高い。

【0114】

要求に係る日時が有効期限内である場合は、音響信号管理テーブル１３０に示される音響マーカーのレコードを、音響マーカー管理テーブル１５０から抽出する。そして、位置情報等抽出部１７０は、抽出された音響マーカーのレコードから、位置情報（例えば、エリアＩＤとＸ，Ｙ座標）を抽出する（１１２０）。Ｘ，Ｙ座標をエリア内の座標系で定義している場合はエリアＩＤとともに抽出するが、Ｘ，Ｙ座標（もしくはＸ，Ｙ，Ｚ座標）のみから位置が一意に特定できる場合には座標のみを抽出してもよい。

【0115】

位置情報等抽出部１７０はまた、付帯情報管理テーブル１８０において、抽出された位置情報に付帯情報が関連づけされている場合は（１１２５）、付帯情報を抽出する（１１３０）。付帯情報の内容により、その位置に関連した各種の情報サービスを提供することができる（各種応用例を後述する）。提供される情報自体を付帯情報としてもよいし、提供される情報が置かれているＵＲＬを付帯情報としてもよい。

【0116】

位置情報等伝達部１７５は、抽出された位置情報（エリアＩＤ、座標）及び／又は付帯情報を、要求元のデバイス３０−Ｉへネットワーク５０を通じて伝達する（１１５０）。なお、受け取った要求の有効性が確認できなかった場合は、エラーが返され（１０４０）、要求元のデバイスにも要求処理不可の通知が返される。

【0117】

図１２には、各音響マーカー２０の内部構成例を示す。音響マーカー２０は、音響信号の出力を行う機能を有する。

【0118】

音響マーカー２０は、音響信号の出力を行うために、音響信号識別ＩＤ入力部２００、音響信号ファイル選択部２１０、音響信号出力管理部２２０、スピーカー部２３０を有する。スピーカー部２３０は、概ね１５ｋＨｚ〜２２ｋＨｚの高音域の信号を出力できるものである。音響マーカー２０はまた、出力レベル調整を実施するため、出力レベル調整指示入力部２４０、音響信号識別ＩＤ確認部２５０を備える。

【0119】

なお、図２５に示すように、各音響マーカー２０とサーバー１０との間をネットワーク６０で接続して、相互通信可能としてもよい。ネットワーク６０を利用しない場合は、管理者が音響マーカー２０自体に音響信号識別ＩＤや出力レベル等を個別に指示するようにすればよい。

【0120】

図１３は、音響マーカー２０が、音響信号を出力するための処理の流れの一例を示す。

【0121】

音響マーカー２０の音響信号識別ＩＤ入力部２００は、管理者から又はネットワーク６０を通じてサーバー１０から、音響信号識別ＩＤ及び出力レベル、出力又は停止指示を入力する（１３００）。

【0122】

音響信号ファイル選択部２１０は、予め記憶してある音響信号ファイルの中から、受け取った音響信号識別ＩＤに対応するファイルを選択する（１３０５）。ただし、受け取った音響信号識別ＩＤ情報を基に、音響信号ファイルを新たに作成してもよい。

【0123】

音響信号出力管理部２２０は、受け取った指示に停止指示が含まれていない場合には（１３１０）、指示された出力レベルを基に（１３１５）、選択した音響信号ファイルを再生し（１３２０）、スピーカー部２３０から出力を行う。受け取った指示に停止指示が含まれている場合には、現在再生している音響信号ファイルの再生を停止する（１３３０）。そして、指示を処理した結果を、管理者に分かるように提示するか、サーバー１０に対して通知する（１３４０）。

【0124】

上述したように、サーバー１０は、デバイス３０からネットワーク５０経由で取得した出力レベル調整依頼に基づいて、音響マーカー２０の出力レベル調整を指示する。

【0125】

このため、音響マーカー２０−Ｋから音響信号を取得させたい位置（例えば、距離１ｍなど）にデバイス３０−Ｋを設置し、音響信号の検出を試みる。このとき信号が検出できなければ、デバイス３０−Ｋはサーバー１０に対して、出力レベル増加調整を依頼する。この出力レベル増加依頼は、音響信号が検出できるようになるまで繰り返すことができる。

【0126】

次に、例えば、音響信号の伝達限界（そこから先は音響信号が伝達されるべきでない）位置にデバイスを移動させ、音響信号の検出を試みる。このとき信号が検出されるならば、デバイス３０−Ｋはサーバー１０に対して、出力レベルの減少依頼を行う。この出力レベル減少依頼は、音響信号が検出できなくなるまで繰り返すことができる。

【0127】

なお、上記の増加依頼、減少依頼は、デバイスの使用者が手動操作で行うことは勿論、デバイス自体が自動操作で行うこともできる。

【0128】

図１４は、音響マーカー２０が、音響信号の出力レベルを調整するための処理の流れの一例を示す。

【0129】

音響マーカー２０の出力レベル調整指示入力部２４０は、管理者から又はネットワーク６０を通じてサーバー１０から、出力レベル調整指示を入力する（１４００）。

【0130】

音響信号識別ＩＤ確認部２５０は、受け取った指示に含まれる音響信号識別ＩＤが使用中の識別ＩＤと同じかどうかを確認する（１４０５）。異なる場合は、エラーを返す（１４５０）。

【0131】

音響信号識別ＩＤが適切に指示されている場合は、当該識別ＩＤの音響信号ファイルがすでに選択されている場合を除いて（１４１０）、指示された音響信号ファイルを音響信号ファイル選択部２１０にて選択する（１４１５）。

【0132】

そして、音響信号出力管理部２２０は、現在の出力レベルと指示された出力レベルを比較し（１４２０）、出力レベルの増加（１４２５）または減少（１４３０）を施して、音響信号ファイルを再生し（１４４０）、スピーカー部２３０から出力を行い、指示を処理した結果を、管理者に分かるように提示するか、サーバー１０に対して通知する（１４６０）。

【0133】

図１５には、各デバイス３０の内部構成例を示す。デバイス３０は、サーバー１０と連携し、音響マーカー２０から取得した音響信号を基に位置情報（例えば、エリア内の２次元又は３次元座標）等を取得する機能を有する。

【0134】

デバイス３０は、通信機能を有する可搬型端末（例えば、スマートフォン）であり、音響信号を受信して解析するために、音響信号入力部３００、音響信号抽出部３１０、音域グループ検出部３２０、音響信号識別ＩＤ取得部３３０を有し（これらをまとめて音響信号処理部と呼ぶことがある）、ネットワーク５０を通してサーバー１０から音響信号識別ＩＤに対応する位置情報等を取得するために、位置情報等要求部３４０、位置情報等取得部３５０を有する。また、出力レベル調整を実施するため、出力レベル調整依頼部３７０を備えてもよい。

【0135】

なお、デバイス３０は、サーバー１０との間をネットワーク５０で接続しており、相互通信が可能である。

【0136】

図１６は、デバイス３０が位置情報等を取得するための処理の流れの一例を示す。

【0137】

デバイス３０の音響信号入力部３００は、自由空間を経由して音響マーカー２０が発するアナログの音響信号を入力する（１６００）。

【0138】

音響信号が入力された場合（１６０５）、音響信号抽出部３１０は、受信されたアナログ信号を、例えば４４．１ｋＨｚのサンプリングレートを用いてデジタルサンプリングし（１６１０）、デジタル信号への変換を行う。続いて、高速フーリエ変換を実施し（１６１５）、周波数成分を抽出する。抽出した周波数成分は、図２に基づいて、ビット配列に置き換える。

【0139】

周波数成分のうち最も高い２２．０ｋＨｚをエリアＩＤ部の先頭ビットとし、２ビット目を２１．８ｋＨｚ、３ビット目を２１．６ｋＨｚ、４ビット目を２１．４ｋＨｚする。

【0140】

次に、音域グループＡのユニークＩＤ部の先頭ビットを２１．２ｋＨｚとし、２ビット目を２１．０ｋＨｚ、３ビット目を２０．８ｋＨｚ、４ビット目を２０．６ｋＨｚとする。続いて、同音域グループＡのエラー訂正符号部の先頭ビットを２０．４ｋＨｚとし、２ビット目を２０．２ｋＨｚ、３ビット目を２０．０ｋＨｚ、４ビット目を１９．８ｋＨｚとする。

【0141】

いずれのビットも、当該周波数成分が存在する場合は、ビットの値を１とし、周波数成分が存在しない場合はビットの値を０とする。

【0142】

同様に、音域グループＢのユニークＩＤ部の先頭ビットを１９．６ｋＨｚとし、２ビット目を１９．４ｋＨｚ、３ビット目を１９．２ｋＨｚ、４ビット目を１９．０ｋＨｚとする。続いて、同音域グループＢのエラー訂正符号部の先頭ビットを１８．８ｋＨｚとし、２ビット目を１８．６ｋＨｚ、３ビット目を１８．４ｋＨｚ、４ビット目を１８．２ｋＨｚとする。

【0143】

同様に、音域グループＣのユニークＩＤ部の先頭ビットを１８．０ｋＨｚとし、２ビット目を１７．８ｋＨｚ、３ビット目を１７．６ｋＨｚ、４ビット目を１７．４ｋＨｚとする。続いて、同音域グループCのエラー訂正符号部の先頭ビットを１７．２ｋＨｚとし、２ビット目を１７．０ｋＨｚ、３ビット目を１６．８ｋＨｚ、４ビット目を１６．６ｋＨｚとする。

【0144】

同様に、音域グループＤのユニークＩＤ部の先頭ビットを１６．４ｋＨｚとし、２ビット目を１６．２ｋＨｚ、３ビット目を１６．０ｋＨｚ、４ビット目を１５．８ｋＨｚとする。続いて、同音域グループDのエラー訂正符号部の先頭ビットを１５．６ｋＨｚとし、２ビット目を１５．４ｋＨｚ、３ビット目を１５．２ｋＨｚ、４ビット目を１５．０ｋＨｚとする。

【0145】

この変換により、音域グループＡ〜Ｄのビット配列が生成され、Ａ〜Ｄの配列のプレフィクスとして、エリアＩＤ部を追加することで、４種類の音響信号のビット配列（エリアＩＤ部＋ユニークＩＤ部＋エラー訂正符号部＝１２ビット）が完成する。

【0146】

このようにして、高速フーリエ変換で得られた周波数成分から、音響信号のビット配列と、どの音域グループの音響信号であるかの情報を得ることができるから、デバイス３０の音域グループ検出部３２０は、音域グループを検出する（１６２０）。

【0147】

音響信号識別ＩＤ取得部３３０は、検出された音域グループと上記１２ビットのビット配列とから、音響信号識別ＩＤを取得する（１６２５）。このとき、得られた１２ビットのビット配列の一部であるエリアＩＤ部とユニークＩＤ部とからエラー訂正符号を計算し、得られた１２ビットのビット配列の残りの部分であるエラー訂正部のビット配列と比較することにより、エリアＩＤ部及びユニークＩＤ部に関してエラー検出及びエラー訂正を実施する（エラー訂正方法は後述する）（１６３０）。

【0148】

エラー訂正後に音響信号識別ＩＤが正常に得られたことが確認できた場合（１６３５）、デバイス３０の位置情報等要求部３４０は、ネットワーク５０を通じてサーバー１０へ位置情報等の要求を行う（１６４０）。サーバー１０へ送付される要求は、得られた音響信号識別ＩＤ（音域グループ＋エリアＩＤ＋ユニークＩＤ）を含む。

【0149】

デバイス３０の位置情報等取得部３５０は、送付された要求への応答として、ネットワーク５０を通じてサーバー１０から位置情報等を取得する（１６５０）。デバイス３０がサーバー１０から受け取る応答には、位置情報及び／又は付帯情報、もしくは要求処理不可という結果の通知が含まれる。位置情報としては、エリアＩＤはデバイス３０内で得られるため、少なくともエリア内の２次元又は３次元座標情報をサーバー１０から送ることになる。

【0150】

図１７には、エラー訂正方法の一例を示す。得られた１２ビットのビット配列の先頭から８ビット目までのデータ部のビット値をD1、D2、D3、D4、D5、D6、D7、D8とし、９〜１２ビット目までのエラー訂正部のビット値を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
となる。

【0151】

例えば、得られた１２ビットのビット配列の後ろの４ビット（エラー訂正部）のH1、H3と検算したビットH1'、H3'とが、H1≠H1'かつH3≠H3'の場合は、D1がエラーということになり、D1のビットを反転させることでエラーを訂正できる。同様に図１７に従って、エラーが検出できた場合は、当該ビットを反転させる。

【0152】

図１７に示されていないパターンの場合は、エラーを訂正することができないため、そのままエラーとして解釈する。つまり、正常な音響信号識別ＩＤが得られなかったとして、エラーを返す（１６６０）。

【0153】

エラー訂正が行われたあとのビット配列（エリアＩＤ＋ユニークＩＤ）を２進数から１０進数に変換する。検出された音域グループ名（Ａ〜Ｄ）に１０進数のエリアＩＤ部とユニークＩＤ部とを追加したもの（例えば、「Ａ−０−１」、「Ｂ−９−１４」等）を、音響信号識別ＩＤとして、サーバー１０への位置情報等の要求時に使用してもよい。

【0154】

なお、上述したデバイス３０は、音響マーカー２０から受信した音響信号に含まれている音響信号識別ＩＤに基づいて、サーバー１０へ要求を送ることにより、位置情報及び／又は付帯情報を取得しているが、音響マーカー２０から受信した音響信号に含まれているエリアＩＤについては、サーバー１０へ問い合わせなくとも、デバイス３０内で今そのデバイスがいるエリアを識別することが可能である。

【0155】

つまり、デバイス３０は、エリア内での詳細な位置を知るには、サーバー１０へ問い合わせることになるが、どのエリアにいるかという大まかな位置については、音響信号を受信するだけで知ることができる。よって、例えば、デバイス３０が検出したエリアＩＤを基に、エリアによって異なるアプリケーションプログラムをデバイス３０において起動するような応用も、可能である。

【0156】

また、上述したシステムの例では、音響マーカーを管理するサーバーと、デバイスに位置情報等を取得させるサーバーと、音響マーカーの故障を判断するサーバーとを、同じサーバー１０が兼ねているが、別々のサーバーにより実現するようにしてもよい。また、デバイスに位置情報等を取得させるサーバーを、エリア毎に設けておき、デバイス３０は、音響信号識別ＩＤの中のエリアＩＤによって特定される情報提供サーバーに対して、音響信号識別ＩＤの中の音域グループ名とユニークＩＤ部とを送ることにより、位置情報等を要求するようにしてもよい。

【0157】

以下には、図１８〜２５を参照して、サーバーにおいて音響マーカーの故障を検出する例を説明する。なお、音響マーカーが音響信号に音響信号識別ＩＤの情報を含ませる方式や符号化の方式等は、上述した図２や図３等に示される例に限定されることはなく、どのような方式であっても、以下に述べる構成や動作を適用することができる。例えば、無線通信等で使われるデジタル変調方式やスペクトラム拡散等を用いて音響信号に情報を含ませる方式の音響マーカー（音響信号出力装置）に対しても、同様に本実施形態のような遠隔からの管理を行うことができる。

【0158】

図１８は、音響マーカー２０から音響信号を受信したときのデバイス３０の位置情報の取得手順と、サーバー１０での音響マーカーの管理手順とを説明する図である。

【0159】

まず、デバイス３０が、音響マーカー２０からの音響信号を受信する。デバイス３０の音響信号処理部は、受信した音響信号を解析し、音響信号識別ＩＤとして認識する。次に、音響信号識別ＩＤに対応する位置情報及び／又は付帯情報（位置情報等）を取得するために、位置問合せメッセージとして、音響信号識別ＩＤをサーバー１０に送信する。

【0160】

音響信号識別ＩＤを受信したサーバー１０の位置情報等処理部は、音響マーカー管理テーブル（と必要に応じて付帯情報テーブル）から、音響信号識別ＩＤをキーとして位置情報等を検索する。サーバー１０の位置情報等処理部は、音響マーカーの管理のために、音響マーカー管理テーブル（又は別途設けられた故障検出用テーブル）において、いま対応する位置情報等が取得された音響信号識別ＩＤのエントリに、最終取得日時として、現在時刻を記入する。これにより、テーブル中の最終取得日時の項目は、該当音響信号識別ＩＤについて最後にデバイスから問合せがあった日時となる。

【0161】

そして、サーバー１０の位置情報等処理部は、音響マーカー管理テーブル等から取得した位置情報等を、音響信号識別ＩＤ（もしくは位置問合せメッセージＩＤ）とともに、デバイス３０へ位置情報応答メッセージとして送信する。この位置情報等を受信したデバイス３０は、例えば、自装置が存在する屋内の位置を知ることができる。

【0162】

上記の位置情報等の処理とは独立して、サーバー１０の音響マーカー管理部では、音響マーカー管理テーブル（又は別途設けられた故障検出用テーブル）を用いて、音響マーカーの故障状況の管理を行う。サーバー１０の音響マーカー管理部は、一定間隔で、音響マーカー管理テーブル（又は別途設けられた故障検出用テーブル）を確認し、最終取得日時の項目がＺ時間以上となっているエントリを拾い出す。

【0163】

Ｚは、例えば、２４時間、４８時間等の間、音響信号が聞こえたというデバイスが現れないときに、音響マーカーが故障だと判断するための時間である。多くのユーザが利用している場所に設置されている音響マーカーは、よく利用されるため、テーブル中の最終取得日時が頻繁に更新され、あまり利用されない場所に設置されている音響マーカーは、テーブル中の最終取得日時があまり更新されない。Ｚの値は、これらの状況を考え、適切な値を設定する。Ｚの値は、すべての場合に同じではなく、場所によって値を変えてもよいし、時間帯や曜日によって値を変えてもよい。

【0164】

テーブル中の最終取得日時から現在時刻までＺ時間以上経過しているエントリを拾い出したら、そのエントリの音響信号識別ＩＤは、一定時間使われておらず、音響マーカーが故障している可能性が高い。これらの音響マーカーを、管理端末４０に表示する。表示は、場所がわかりやすいように地図上に表示してもよいし、音響マーカーを管理している店舗毎に表示してもよい。管理端末４０において管理のためのアプリケーションを起動することなく、メール等で、故障した可能性のある音響マーカーを伝えるようにしてもよい。

【0165】

音響マーカーの故障は、上記の例では、音響マーカー１つずつの情報に基づいて推定しているが、ある店舗の中に複数の音響マーカーが置いてある場合には、同一店舗の音響マーカーの音響信号について位置問合せメッセージが受信された場合に、同一店舗の他の音響マーカーの音響信号について位置問合せメッセージが受信されない場合に、その受信されない音響マーカーを故障と判断するようにしてもよい。

【0166】

また、音響マーカーを設置する場所の特性を考慮し、昼間に利用者が多く集まり、問合せ数が多い場合には、昼間の間を上記の故障推定の対象期間としてもよい。これにより、夜間、利用者の少ないときには、問合せ数が少ないために故障でないものを故障と判断してしまうことを避けることができる。また、対象となる時間を変更することで、故障推定の正確さを向上させることができる。

【0167】

故障の判断を、過去の問合せ数のパターンと比較して行ってもよい。時間帯、曜日、季節、イベント開催等によって音響マーカーの前を利用者が通る数のパターンが類似しており、問合せ数が類似することがある。これらの類似性は、過去の問合せ数のパターンを見ると分かる。例えば、日曜日の昼間にある場所に利用者が多く存在し、問合せ数が多い音響マーカーがあるとすると、日曜日の昼間に問合せが受信されない場合には、音響マーカーが故障したと推定することができる。

【0168】

図１９は、図１８に加えて、デバイスで音響信号識別ＩＤを抽出した際のエラー情報を利用する例を説明する図である。

【0169】

デバイス３０では、音響マーカー２０から受信した音響信号から音響信号識別ＩＤを抽出するが、ここで受信する音響信号は、雑音等によりエラーが発生する可能性があるので、エラー訂正やエラー検出できるような符号を用いて、音響信号識別ＩＤが符号化されている。例えば、拡張ハミング符号を用いると、１ビットのエラー訂正、２ビットのエラー検出ができる。

【0170】

拡張ハミング符号の例では、デバイス３０は、受信した音響信号が、１ビットのエラー誤りを含んでいた場合には、エラー訂正することができる。この場合には、正しい音響信号識別ＩＤに訂正し、位置問合せメッセージに、音響信号識別ＩＤと、１ビットのエラー訂正をしたことを示す情報とを含めて、サーバー１０へ送信する。

【0171】

この位置問合せメッセージを受信したサーバー１０の位置情報等処理部は、図１８の例と同じように、受信した音響信号識別ＩＤをキーにして、音響マーカー管理テーブル等から位置情報等を取得する。その際、該当するエントリに、最終取得日時として現在時刻を記入するとともに、受信したエラー情報を記録する。そして、位置情報等を位置情報応答メッセージとして、サーバー１０からデバイス３０に位置情報応答メッセージとして送信する。

【0172】

サーバー１０の音響マーカー管理部は、音響マーカー管理テーブルの最終取得日時とエラー情報に基づいて、故障している可能性の高い音響マーカーを表示する。例えば、最終取得日時から現在までＺ時間以上経過しているエントリと、エラー訂正がＹ％以上となるエントリとを抽出し、これらのエントリの音響信号識別ＩＤが割り振られている音響マーカーを、故障しているものとして検出する。これにより、音響信号の問合せが一定時間以上受信されていない音響マーカーと、一定割合以上のエラー訂正が行われている音響マーカーとが、管理端末４０に表示される。

【0173】

Ｙ％以上のエラー訂正かどうかは、例えば、同一音響マーカーにおいて、一定期間（例えば、２４時間）に問合せのあった数を総数として、この中でエラー訂正を行った問合せの数の割合を求めることによりエラー訂正の割合が計算できる。エラー訂正されている音響マーカーは、現状では利用できているが、音響マーカーが故障する可能性があるか、音響マーカーの周辺環境により、音響マーカーからデバイスへの音響信号が正確に伝わっていないことが考えられる。このような情報を管理端末４０に表示することにより、音響マーカーの故障状態や周辺環境の悪化を通知することができる。

【0174】

ここでは、音響信号のエラー訂正に基づいて故障状況を推測したが、音響信号の音の大きさを利用して、同一音響マーカーで音の大きさが変わったときに故障を推測するようにしてもよい。

【0175】

このように、デバイスからエラー情報等の付加的な情報を収集することにより、サーバー側で集中管理するようにすると、故障の可能性のある音響マーカーの交換や周辺環境の悪化した音響マーカーの点検を効率的に実施することが可能になる。

【0176】

以上の例のように、音響マーカー２０からの音響信号でデバイス３０の位置を求める方式は、歩行者自律航法（ＰＤＲ）等の他の測位技術と組み合わせて使うことができる。ＰＤＲは、デバイス３０に内蔵されているセンサーを使うことにより、自立的に場所を推定する技術である。例えば、加速度センサーにより距離を推定し、地磁気センサーにより方向を推定することができる。デバイス３０を他のセンサーが内蔵されているものにして、ＰＤＲ以外の測位技術を組み合わせることも可能である。

【0177】

図２０（デバイス側）及び図２１（サーバー側）を参照して、組み合わせの動作例を説明する。デバイス３０で、センサーによる移動を検知すると、ＰＤＲ等により位置を推定する。推定結果を、デバイス３０内で、位置情報リストに記録する。位置情報リストは、図２１の右下隅に示すように、位置情報と日時とが記録されるものである。

【0178】

デバイス３０は、他方で、音響マーカーから音響信号を受信すると、音響信号識別ＩＤを抽出し、サーバー１０へ位置問合せメッセージを送信する。このとき、音響信号識別ＩＤに加えて、ＰＤＲ等を用いて記録した位置情報リストを、サーバー１０へ送信する。

【0179】

この位置問合せメッセージを受信したサーバー１０は、音響信号識別ＩＤをキーに音響マーカー管理テーブル等から位置情報等を検索する。そして、音響マーカー管理テーブルの該当エントリの最終取得日時を現在時刻に更新し、受信した位置情報リストをサーバー１０内に保存する。サーバーに保存される位置情報リストの形式は、デバイスで記録されサーバーへ送信される位置情報リストの形式と同様であるが、サーバーに保存される位置情報リストは、複数のデバイスからの位置情報リストを集積したものになる。

【0180】

サーバー１０の音響マーカー管理部では、音響マーカー管理テーブルとサーバー内の位置情報リストとを比較して、故障音響マーカーを検出する。例えば、音響マーカー管理テーブルの位置情報と位置情報リストの位置情報とが同一であるエントリ同士を比較し、音響マーカー管理テーブルの最終取得日時が位置情報リストの時刻よりも古い場合には、その音響マーカーからの音響信号がデバイスに受信されない状況である可能性が高いと判断し、故障音響マーカーとして表示する。１つのデバイスがその音響マーカーからの音響信号を受信しなかった場合に故障として検出してもよいが、一定数以上のデバイスがその音響マーカーからの音響信号を受信しなかった場合に故障として検出するようにしてもよい。

【0181】

なお、図２０及び図２１のＰＤＲ等を利用する例と、図１９のエラー訂正を利用する例とは、デバイス３０からＰＤＲ等の情報とエラー訂正の情報との両方をサーバー１０に送信することにより、組み合わせて適用することも可能である。

【0182】

図２２は、デバイス３０が、音響マーカー２０からの音響信号を受信する都度、サーバー１０へ位置問合せを行うのではなく、サーバーにある情報の一部（例えば、一度利用した音響信号識別ＩＤと位置情報等との対応等）をデバイス内にキャッシュ３６０として保存しておき、このキャッシュを利用して位置情報等を取得する機能を有する場合の、デバイス３０の構成を示している。

【0183】

キャッシュを利用することにより、デバイス３０は、サーバー１０に問い合わせることなく位置情報等を取得できるため、ネットワーク５０の速度が遅いとき等にデバイス３０のユーザへの表示速度等を早くしたり、通信を少なくしてスマートフォンのレスポンスを早くしたりすることができる。また、通信量ひいてはバッテリの消費量を削減することも可能になる。

【0184】

但し、キャッシュの情報のみを利用して位置情報等を取得すると、デバイス３０が正常に音響マーカー２０からの音響信号を受信していることをサーバー１０へ伝えることができなくなる。そこで、図２２のデバイス３０は、位置情報等要求部３４０により位置問合せメッセージを送信せずに、キャッシュ３６０により位置情報等を取得したときには、その位置情報を利用したこと（すなわち対応する音響信号を受信したこと）を、位置情報等利用記録部３８０によりデバイス３０内で記録しておき、この利用記録を、適切なタイミングで（例えば、定期的に等）、位置情報等利用報告部３９０によりサーバー１０へ送信する。

【0185】

この利用記録をデバイス３０から受信したサーバー１０は、デバイス３０から位置問合せメッセージを受信しなかった場合でも、デバイス３０が音響マーカー２０からの音響信号を受信したことを知ることができるため、音響マーカーの故障の精度の良い検出が可能になる。それだけでなく、例えば、音響信号すなわち位置情報等を利用した回数でユーザに課金する場合に、キャッシュによってユーザの利便性を向上させながら（キャッシュを利用するとサーバーへの位置問合せ回数では正確な課金ができなくなるところ）、サーバーにおいてユーザの位置情報等の利用回数を精度良く把握することが可能になる。

【0186】

図２３（デバイス側）及び図２４（サーバー側）を参照して、キャッシュを利用する場合の動作例を説明する。デバイス３０は、音響マーカー２０からの音響信号を受信して音響信号識別ＩＤを抽出すると、音響信号識別ＩＤと位置情報等との対応を有するキャッシュ３６０を参照して、そこに有効な位置情報等が存在しなかった場合に、ネットワーク経由でサーバー１０へ位置問合せメッセージを送信する。

【0187】

なお、このキャッシュ３６０の利用には、毎回、キャッシュの情報が最新のものかサーバーに問い合わせして確認する方法と、一定時間、キャッシュの情報のみを利用してサーバーに問い合わせしない方法とがある。前者の方法を採る場合は、図１８〜２１で説明した例が適用できるが、後者の方法を採る場合は、サーバーへ何の情報も送信しないので、図２２〜２４の例を適用する。なお、前者の方法を採る場合であっても、位置問合せメッセージをサーバーでの故障検出のために流用するのではなく、図２２〜２４の例のように、故障検出のためのメッセージを別途デバイスから送信するようにしてもよい。

【0188】

キャッシュ３６０には、音響信号識別ＩＤと位置情報等に加えて、最終利用日時とキャッシュ利用回数を記録するようになっている。デバイス３０は、音響マーカー２０からの音響信号を受信して音響信号識別ＩＤを抽出すると、音響信号識別ＩＤと位置情報等との対応を有するキャッシュ３６０を参照して、そこに有効な位置情報等が存在する場合には、キャッシュから位置情報等を読み出して、最終利用時刻として現在時刻を記入（上書き）し、利用回数を１つ増加させる。この利用回数により、デバイスがキャッシュから位置情報等を取得した回数が分かる。

【0189】

ここに記録された音響信号識別ＩＤと最終利用時刻と、必要に応じて利用回数とを、デバイス３０からサーバー１０へ送信することにより、サーバー１０では、キャッシュ機能なしのデバイスからの位置問合せメッセージによって記録される最終取得日時と、場合によっては取得日時の履歴（又は取得回数）と同等の情報を、キャッシュ機能ありのデバイスから収集することができる。

【0190】

これにより、サーバー１０において、キャッシュ機能を有するデバイス３０からも、キャッシュ機能を有さないデバイス３０からも、適切に情報を収集して、各音響マーカー２０を遠隔監視することが可能になる。また、サーバーへの位置問合せ回数による課金を実施する場合に、キャッシュ機能を有するデバイスに対しては音響信号の利用回数による課金を実施することで、同等の課金を行うことが可能になる。

【0191】

図１８〜２４の例は、音響マーカーが通信機能を備えない場合にも適用可能であるが、図２５では、音響マーカーが通信機能を備える場合について説明する。

【0192】

図２５の音響マーカー２０は、音響信号出力部２３０に加えて、音響信号を入力するマイク等の音響信号入力部２６０と、ネットワーク６０を通してサーバー１０へ情報を送る通信部２７０とを備える。

【0193】

音響マーカー２０の音響信号出力部２３０から出力された音響信号は、デバイス３０に受信されるとともに、音響マーカー２０の音響信号入力部２６０でも受信される。音響信号が出力されていることを確認するためには、この音が受信されるか否かを調べるのが確実であるため、本例では、同一装置内に音響信号を出力する機能と入力する機能の両方を搭載することにより、音響マーカーが故障していないかどうか確認している。

【0194】

この確認した情報は、音響マーカー２０の通信部２７０からサーバー１０へ送信される。サーバー１０への通信メッセージに、音響マーカー２０のＩＤ、時刻、故障状況の情報を含めることにより、サーバー１０は、各音響マーカー２０を遠隔故障することができる。

【0195】

以下には、図２６〜３７を参照して、音響マーカーの配置例を説明する。音響マーカーは、エリア内のセル単位に配置する。

【0196】

図２６は、単一エリアにおいてセルが２次元に広がる場合（例えば、部屋等）、使用できる音響信号の音域グループが４種類（Ａ〜Ｄ）あると、音響マーカーを隙間なく配置することができることを示している。混信を防ぐため、隣接するセルでは同一の音域グループを使用しないように配置している。周波数を重複しないように割り当てる音域グループが４つある（例えば、１５．０ｋＨｚ〜２１．２ｋＨｚの２００Ｈｚ毎の周波数を利用し、８ビット分を４グループ確保する）場合、１エリア内で６０個のセルを識別可能である。本例では、エリアを６×６のセルに論理的に分割しているが、Ｎ×Ｍ（ＮとＭは識別可能な個数に収まる任意の自然数）に分割する場合も、４種類あれば、同様に隙間なく配置可能である。これなら、デバイスを携帯しながら移動すると、連続的に、位置に応じた情報を取得していくことができる。

【0197】

図２７、２８、２９は、それぞれ、図２６と同様のセルが２次元に広がるエリアにおいて、使用できる音響信号の音域グループが、３種類（例えばＡ〜Ｃ）の場合、２種類（例えばＡ〜Ｂ）の場合、１種類（例えばＡのみ）の場合に、隣接するセルでは同一の音域グループを使用しないという制限の下で可能な音響マーカーの配置例を示している。使える音域グループの数が減るにしたがって、音響マーカーを配置できない（そこにいるデバイスは音響信号を受信できない）セルが多くなり、デバイスを携帯しながら移動しても、間欠的にしか、位置に応じた情報を取得できないことになる。

【0198】

図３０、３１、３２は、それぞれ、単一エリアにおいてセルが１次元に延びる場合（例えば、通路等）、使用できる音響信号の音域グループが、４種類（Ａ〜Ｄ）、３種類（例えばＡ〜Ｃ）、２種類（例えばＡ〜Ｂ）あると、音響マーカーを隙間なく配置することができ、デバイスが移動しながら連続的に情報取得できることを示している。混信を防ぐため、隣接するセルでは同一の音域グループを使用しないように配置している。本例では、エリアを１×６のセルに論理的に分割しているが、１×Ｎ（Ｎは識別可能な個数に収まる任意の自然数）に分割する場合も、同様である。

【0199】

図３３は、図３０〜３２と同様のセルが１次元に延びるエリアにおいて、使用できる音響信号の音域グループが１種類（例えばＡのみ）の場合に、隣接するセルでは同一の音域グループを使用しないという制限の下で可能な音響マーカーの配置例を示している。音響信号が受信できるセルが飛び飛びになるため、デバイスの移動しながらの情報取得も間欠的になる。

【0200】

図３４、３５、３６、３７は、複数のエリアからなるロケーションにおいて、使用できる音響信号の音域グループが、それぞれ、４種類（Ａ〜Ｄ）の場合、３種類（例えばＡ〜Ｃ）の場合、２種類（例えばＡ〜Ｂ）の場合、１種類（例えばＡのみ）の場合に、隣接するセルでは同一の音域グループを使用しないという制限の下で可能な音響マーカーの配置例を示している。

【0201】

図３４〜３７の例では、２×６、１×２、２×６の３つのエリアが接続されたロケーションを取り上げている。接続部分には、エリアは異なるが隣接するセルが存在するため、その間でも異なる音域グループを使用するように、配置する。

【0202】

以上に詳述した音響マーカーシステムを利用すると、屋外だけでなく、屋内や地下空間を歩行中の、例えばスマートフォン利用者の位置情報を、リアルタイムかつ高精度（最小１ｍ程度）で取得させることができる。

【0203】

一般的なスマートフォンにはマイクロフォンと通信装置が搭載されており、追加の装置の接続を必要としないため、特殊な外部装置を必要とせずアプリケーションプログラムをインストールするだけで、利用開始できる。他方、設置する音響マーカーについても、通常の音響装置を流用することができるため入手が容易で、二次元コードを貼付した場合のように景観を損ねることもない。

【0204】

さらにＷｉＦｉ受信信号強度による位置推定が５〜１０秒かかっているのに対して、本方式では、ほぼリアルタイムで位置を取得することができるため、デバイスが移動しても高い精度で位置情報を提供できる。また、事前のＷｉＦｉ受信信号強度に関するキャリブレーションのような作業も不要であるため、設置時間の短縮も図ることができる。

【0205】

また、本システムでは、複数の音源から同時に音響信号（音波）を放音・伝送することを前提にして、隣接する場所になる音源からは異なる音域グループの音響信号が流れるように割り振りを行うため、伝送媒体として音波を使っているにもかかわらず、周波数成分の干渉による情報の復元障害という問題が生じない。これにより、音源を密に配置して位置情報（座標）等を提供する用途に使用することが可能になっている。

【0206】

以上に一例を説明した音響マーカーシステムによる位置情報取得技術を適用する用途は、多岐にわたり得るが、代表的な例を以下に説明する。

【0207】

屋内や地下空間に音響マーカーによる位置推定基盤を構築することで、これまでは実現が困難であったＧＰＳの届かない場所での歩行中のナビゲーションが可能となる。

【0208】

屋内の例としては、店舗内に音響マーカーを設置することで、静止して端末をかざすことなく歩きながら現在位置をリアルタイムで確認できることから、入店時に探している商品やお勧めの商品まで案内する店舗内誘導サービス等が実現できる。また、店舗で利用する場合には入店・退出管理や動線把握にも利用できる。

【0209】

さらにこのサービスは、複数の音響マーカーが同時に聞こえる状況が存在しても、それぞれを認識できるという特徴がある。例えば、音響マーカーを商品の置いてある棚の場所と紐付けて位置情報として使用することが基本と考えられるが、入口、会計場所、トイレなどに別途音響マーカーを付けることで、同時に複数の音響マーカーからの音響信号を取得しても区別して認識することができる。さらに、棚に配置した際に音響マーカーからの信号出力が同時に取得できる場合にも双方ともに認識し区別できる。

【0210】

上記サービスのためのシステムは、音響マーカー、デバイス、サーバーに加えて、店舗情報管理サーバーで構成される。機能としては下記６点が挙げられる。

【0211】

ｉ）現在位置提供：スマートフォン等のデバイス（以下、デバイスという）でアプリケーションを起動すると音響信号取得が可能になり、音響信号を認識する度にサーバーへ現在位置を問い合わせるため、現在のデバイスの座標が把握できる。音響信号の把握は立ち止まって端末を音源にかざしたりする必要はなく、歩行したまま受動的に認識可能である。現在位置は常にサーバーを通じて店舗情報管理サーバーから取得したアプリケーション上のエリアマップ上に点で表示される。デバイス単独でエリアの変更を認識できるため、エリアＩＤの変更を検知するとサーバーに新規エリアのマップを要求し取得することができ、常に現エリアのマップ上に現在地が描画される。音響信号識別ＩＤが複数同時に認識できる場合には、それぞれの音響信号識別ＩＤに対応する座標を取得し、その全座標の中間点を現在地とする。

【0212】

ｉｉ）商品情報検索（商品位置取得、ルート検索）：デバイスでアプリケーションを起動し、現在位置を認識すると商品検索が可能になる。商品情報（アイテムコード）を入力するとサーバーを通じて店舗管理用サーバーへ商品位置を要求し、商品の座標を取得する。現在地と検索した商品の座標を取得すると、店舗情報管理サーバーにて現在位置から商品棚までのルートを計算し店舗内全域マップに描画しアプリケーション上に表示する。ここでルートが表示される地図は、現在地を表示するエリアマップとは別にナビゲーション終了時まで常に全域の表示を行う。

【0213】

ｉｉｉ）商品、コンテンツ情報の提供：デバイスのアプリケーションは、現在位置を取得すると、その座標に紐づいたアイテム（商品、コンテンツ）情報をサーバー経由で店舗情報管理サーバーに問い合わせ、情報を取得する。認識した音響信号識別ＩＤに紐づいている商品、コンテンツを全てリアルタイムに表示することができる。また、表示するものはキャンペーンごとなど店舗側で制御することができる。

【0214】

ｉｖ）商品までの歩行案内：ｉｉ）により常にデバイスの現在位置を取得できるため、現在地を把握しながら、ｉｉ）で表示されたルートを元に歩行する。商品が置かれている棚に設置された音響マーカーの音響信号を認識すると案内終了のメッセージが表示される。

【0215】

ｖ）入店、退店管理：入口に音響マーカーを設置することで、既にデバイスのアプリケーションが起動している場合は入口の音響マーカーの音響信号識別ＩＤを認識し、サーバーに問い合わせを行い入店と退店を認識する。入口には入口中央から店舗外側と内側それぞれに向けて音響マーカーの出力スピーカーを設置する。それぞれの音響マーカーが使用する音響信号識別ＩＤは店舗情報管理サーバーにて入口に紐づけられている。

【0216】

入店・退店判定を行うためのシステムの一例を図３８に示す。入店時にデバイスのアプリケーションが起動している場合、まずＡの音響マーカー信号を認識し次にＢの音響マーカーを認識する。入店後にアプリケーションを起動した場合は入店の記録はないが、起動した地点から現在地の取得が開始される。退店時にはＢの音響マーカー信号を取得した後Ａの音響マーカー信号を取得することで退店を認識する。詳細は、後述する。また、退店済みと認識しない場合、一定時間が経過しても音響信号を検出していないときは退店とみなすように処理してもよい。

【0217】

これらの入退店の情報は顧客（以下、ユーザと呼ぶ）ごとに店舗情報管理サーバーにて管理されているため、ユーザ別に来店頻度、店内滞在時間、どのエリアに長く滞在したか等を別途ビジネスインテリジェンス（ＢＩ）システム等で分析するためのログとして記録することができる。

【0218】

応用例として、入店時に前回、当該ユーザが検索した商品や、来店前にチェックしていた商品などを出すことも可能である。

【0219】

ｖｉ）動線管理：ユーザ情報が店舗情報管理サーバーにて管理されており、ユーザが現在位置を取得する度にログが店舗情報管理サーバーに蓄積されていく。ユーザ別にログを見ることで、ユーザの来店時の動線の把握が可能である。ログを時間で検索すると、どの時間帯にはどの売り場に人が多いなど細かい情報の取得が可能である。商品、コンテンツ表示端末には、歩行時に取得した音響信号識別IDに紐づいた位置にあるコンテンツの情報や検索した商品の棚に到着した際に商品の情報を表示することができる。

【0220】

上記サービスのためのシステムを構築するにあたり、屋内や地下空間では、ＧＰＳ衛星からの電波が取得できないため、ＧＰＳを現在位置情報の取得に用いることはできない。ＷｉＦｉにおいては、ＢＳＳＩＤ（無線ＬＡＮ基地局の識別名称）による位置推定方式では同じフロア内の高精度な識別は困難であり、ＲＳＳＩ（無線ＬＡＮの受信信号強度）による位置推定方式では一定時間立ち止まっていないと位置推定ができないため歩きながら案内をすることは不可能である。２次元コードにおいても、認識するためには立ち止まり、デバイスを静止させカメラで２次元コード（マーカー）を読み込むという作業をしないと利用できない。このようなことから、商品案内といった詳細レベルでの店舗内誘導サービスは現在存在する他の技術では実現できず、本技術を用いて初めて可能になると考えられる。

【0221】

上記サービスのためのシステムにおける音響マーカーは、音響マーカーシステムにおける音響マーカーとして前述した通りである。図３９、図４０に、上記サービスにおける音響マーカーの２つの設置例を示す。音響マーカーの設置は店舗内のほぼ全域を想定し、店舗内ではどの場所においても現在位置が確認できるものとする。

【0222】

前述した例によれば、音響マーカーは１つの店舗内で最大１５エリア（店舗内でいう１つの売り場）まで使用が可能であり、音域グループを４つに分けた場合は１つのエリアにつき最大６０点設置することができる。つまり、３階建で各階に２つずつ売り場が存在する店舗に設置する場合は、全部で６エリアあると考え各エリア内で棚の位置情報、特定の場所、お勧め商品など合わせて６０点まで音響マーカーを使用できる。

【0223】

１つのエリア内では、Ａ、Ｂ、Ｃ、Ｄの各音域グループの音響マーカーに対し、同じ音域グループの音響マーカーが隣り合わないように配置する。下記に１エリア内での音響マーカーの設置例を示す。音響マーカーのスピーカーで壁や棚から通路に向けて音を発生させた場合、前方の通路にのみ音が放音されるものとする。音響信号は違う音域グループのものであれば、音域グループ数（４つ）までは同時に識別可能である。例えば、図３９では、丸数字で１の位置では、３つの音響信号が聞こえることになる。その場合、A-0-8、B-0-8、D-0-8の信号が同時に認識され、それぞれの座標を取得することできる。

【0224】

音響マーカーの使用例として、基本的にどの音響マーカーも位置情報と紐付けられているが、座標認識のためではなく、コンテンツの情報提供などを目的とすることも可能である。つまり歩行中にコンテンツ情報提供用の音響信号を取得しても現在地には反映せず、コンテンツの内容のみを表示させることが可能である。様々な角度からセルよりも大きな範囲などに情報を提供したり、ポスターなどの情報を提供したりすることに適していると考える。図４０で説明すると、キャンペーン情報を十字路周辺に提供したい場合、中央の棚にスピーカーを置き音響信号（D-1-1）を360度に放音する。D-1-1は位置情報を提供せず、キャンペーン情報のみを提供する。図４０の丸数字で２の位置にいる場合は、D-1-1の位置情報は使用せずA-1-3とC-1-2の座標の中間点が現在位置となる。

【0225】

応用例として、それぞれの音響マーカーの位置情報に加え隣り合う音響マーカーもサーバーに記録しておくと、次に認識するはずの音響信号識別ＩＤを予測できるため、それ以外の音響信号識別ＩＤが取得された場合エラーと判別することができ、補正方法の精度を高めることが可能である。

【0226】

上記サービスのためのシステムにおけるデバイスは、音響マーカーシステムにおけるデバイスとして前述した基本機能に加え、店舗内誘導サービス用のアプリケーションがインストールされている。アプリケーションは商品情報検索、商品までの歩行案内、現在位置把握、商品・コンテンツ情報の閲覧等が可能なグラフィカルユーザインターフェイス（ＧＵＩ）を有する。

【0227】

上述した歩行者ナビゲーションのサービスは、店舗だけではなく、例えば、地下鉄のホームで、どの方向に移動することが目的地に一番近いかを利用者に通知するような用途や地下駐車場に駐車した自動車まで案内するといった利用が可能である。

【0228】

また、博物館や美術館、水族館など展示物の補足情報を提供するために拡張現実技術を利用するような用途でも、上述した音響マーカーシステムによる位置情報取得技術を適用できる。従来技術では実現が困難であったような屋内環境でのシステム化を図ることができる。

【0229】

上述した店舗情報管理サーバーのように、歩行者ナビゲーションや拡張現実の各ユーザの動線の情報を収集すると、この情報を事業者がサービス向上を図るための情報として利用することができる。また、施設の警備や鉄道事業者の係員の配置などに関して、管理者が現在位置を把握するような用途での利用も可能である。

【0230】

上述した店舗情報管理サーバーのように、入店管理を行うと、小売店向けのポイントプログラムやクーポン券発行の条件として、来店を求めるような用途において、確実に入店したかどうかを位置情報によって把握することができる。従来技術では、ＧＰＳやＷｉＦｉによって位置推定を行うことが多いため、実際に入店せずに利用者がチェックインすることは可能であったが、本技術では、高音域の音声信号を利用するためエリアを限定しやすくなっており、店内に入らないとチェックインできないような制限が可能である。また、リアルタイムで位置を取得できるため、入り口を通過した瞬間に入店を確認することができる。

【0231】

本技術によってポスターなどの掲示物に関する情報を提供すると、従来の二次元コードのスキャンのように一つの二次元コードを同時に取得できるのは一名だけという制約がなく、一度に多人数が同時に情報を取得させることができる。

【0232】

本技術を利用するデバイスを保持する歩行者は、歩きながら音響信号を取得することができるため、例えば、展示会などにおいて通過したブースを特定することができ、資料を自動的に取得することができる。また、路上などで配布される広告や割引券のような情報も、同様に取得することができる。

【0233】

テレビ放送やラジオ放送において、本技術を用いた音響信号を発信することによって、あらかじめ配布したアプリケーションと連動した商品紹介や購入支援を行うことも可能である。音響信号は、時々刻々変化させることができるため、出演者の衣装や楽曲などの情報も提供できる。

【0234】

上述した例では、サーバーにて各音響マーカーの故障状況を評価するための情報を、本システムの多数のユーザが所持するデバイスから収集できるが、本システムの管理者が、定期的に、各音響マーカーの検査のためのルートが表示されたエリアマップを見ながらデバイスを持って歩き回ることによっても、同様に情報を収集することが可能である。

【0235】

以上では、音響信号を利用して屋内で位置推定（測位）を行う例における音響マーカーの管理について説明したが、上述した例は全て、音響信号以外の屋内測位用の信号を出力する装置の管理にも応用することが可能であり、特に、ネットワーク機能を有していない信号出力装置の管理に有用である。

【0236】

例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）の発信装置は、信号の届く範囲にあるデバイスに、当該発信装置のアドレスを認識させることができるから、音響信号識別ＩＤの代わりにＢｌｕｅｔｏｏｔｈ（登録商標）のアドレスを利用することで、音響マーカーと同等のことが実現できる。このＢｌｕｅｔｏｏｔｈ（登録商標）の発信装置について、サーバーで集中的に遠隔監視することは、上述した音響信号の例と同様の手法で、実現できる。

【0237】

以上、本発明の実施形態について説明したが、上述の実施形態を本発明の範囲内で当業者が種々に変形、応用して実施できることは勿論である。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】

【図32】

【図33】

【図34】

【図35】

【図36】

【図37】

【図38】

【図39】

【図40】