JP2019176251A - 認証システム及び認証方法 - Google Patents

Abstract

【課題】セキュリティを考慮しつつ、安価かつ認証処理にかかる負荷を低減可能な認証システムを提供する。【解決手段】認証サーバ、ビーコン、及び入場管理端末を備える認証システムであって、認証システムは、ユーザ端末からのアクセスを受け付け、認証サーバは、電子チケットが購入された場合、認証用データを生成して、ユーザ端末に送信し、認証処理の実行要求を受信した場合、認証処理を実行し、電子チケットが正当なものであると判定された場合、音データを生成するための入場用データを生成して、ユーザ端末に送信し、ユーザ端末は、認証用データ、入場用データ、及びビーコン信号に含まれるビーコン情報に基づいて入場用音データを生成して、音を再生し、入場管理端末は、再生された音の特性を分析し、分析結果に基づいて、ユーザの施設への入場を許可するか否かを判定する。【選択図】 図１

Description

本発明は携帯端末を用いた、電子チケット等の認証を行う認証システム及びその認証方法に関するものである。

イベント及びコンサート等が行われる施設でのチェックインに電子チケットが使用されている。電子チケットを用いた認証では、ＱＲコード（ＱＲコードは登録商標）等を併用した画像に基づく認証が一般的である。

画像を用いた認証を行うシステムでは、高価かつ専用の読取機器を多数用意する必要がある。そのため、システムの構築及び運用にかかるコストが高いという問題がある。したがって、屋外イベント、及び一時的に施設を利用するイベントに前述のシステムを適用するのは現実的でない。

購入者本人にサービスを提供する手段の一例として、特許文献１に記載の技術が知られている。特許文献１には、「利用者情報管理装置は、取得部と、受信部と、送信部とを備える。取得部は、端末装置の利用者が提供を受けようとするサービスに関する権限情報を取得する。受信部は、サービスの提供を受ける際に端末装置側で実行される利用者の本人性を認証する認証処理の結果を受信する。送信部は、受信部によって受信された認証処理の結果に基づいて生成される情報であって、利用者がサービスの提供を受ける権限を有する利用者であることを示す情報である本人確認情報を送信する」ことが記載されている。

特許文献１に記載の技術をイベントが行われる施設に導入されるシステムに適用した場合、高価かつ専用の読取機器の代わりにユーザが保持するモバイル機器等を用いるためシステムの構築及び運用にかかるコストを削減できる。

特開２０１７−９７８０２号公報 特開２００５−３３２２４０号公報

しかし、イベントが行われる施設には一定期間に多数のユーザが来場するため、認証処理を実行する認証装置は、一度に多くのユーザの認証を行う必要がある。そのため、処理負荷（演算量）が非常に大きくなることから、処理性能の高い認証装置を設置、又は、多くの認証装置を設置する必要がある。また、狭いエリアで認証装置と多数のユーザ端末との間で通信が行われるため、通信帯域の不足及び輻輳等の通信リソースの負荷の問題が発生する可能性がある。

認証処理の負荷軽減を目的とした技術として特許文献２に記載の技術が知られている。特許文献２には、「サービスを利用するユーザまたは該ユーザが所持するデバイスを認証する認証方法において、前記ユーザまたは該ユーザが所持するデバイスが、代表して本人認証を行う主管ユーザと、主管ユーザが存在する場所でサービスの利用を許可される従属ユーザ及び前述主管ユーザ、従属ユーザが所持するデバイスとのグループであり、複数のサービスエリアのそれぞれに、認証制御エージェントを備え、該認証制御エージェントは、前記主管ユーザが通常の手順で認証されており、かつ、前記従属ユーザまたは前記デバイスを監視可能なエリアに前記主管ユーザが存在する場合に、トークンによって存在や位置を確認することができた前記従属ユーザまたはデバイスに対するサービスの利用を、自エージェントが持つ認証コンテキストに基づいて認可する」認証方法が記載されている。

しかし、特許文献２では、多くの端末が集中する施設における通信量については考慮されていない。

本発明は、以上の点を考慮してなされたもので、セキュリティを考慮しつつ、安価に、認証処理にかかる処理負荷及び通信リソースの負荷を低減可能な認証システム及び認証方法を実現することを目的とする。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、ユーザが操作するユーザ端末、電子チケットを用いた認証処理を実行する認証サーバ、ビーコン信号を発信するビーコン、及び前記電子チケットを用いて前記ユーザの施設への入場を管理する入場管理端末を備える認証システムであって、前記認証サーバは、前記ユーザによって前記電子チケットが購入された場合、認証用データを生成して、前記ユーザ端末に前記認証用データを送信し、前記ユーザ端末から、前記電子チケットが正当なものであるか否かを判定するための認証処理の実行要求を受信した場合、前記認証処理を実行し、前記電子チケットが正当なものであると判定された場合、任意の特性を有する音の音データを生成するための入場用データを生成して、前記ユーザ端末に前記入場用データを送信し、前記ユーザ端末は、前記ユーザが前記施設に到着する前に前記認証用データから抽出される情報を含む前記認証処理の実行要求を前記認証サーバに送信し、前記ユーザ端末及び前記施設の距離が第一範囲内であり、前記ビーコンから第一ビーコン信号を受信した場合、前記認証用データ、前記入場用データ、及び前記第一ビーコン信号に含まれるビーコン情報に基づいて入場用音データを生成し、前記入場用音データに基づいて前記入場管理端末に対して音を再生し、前記入場管理端末は、前記ユーザ端末によって再生された音の特性を分析し、前記分析の結果に基づいて、前記電子チケットに関連付けられるユーザの前記施設への入場を許可するか否かを判定する。

本発明の一態様によれば、入場可否判定は音を用いて行われるため、高価かつ専用の読取機器が必要ない。また、施設の到着前に任意のタイミングで認証サーバとの間で認証処理が実行されるため、認証処理の実行タイミング及び通信タイミングを分散できる。したがって、セキュリティを確保しつつ、安価に、認証処理にかかる処理負荷及び通信リソースの負荷を低減可能な認証システムを実現できる。

実施例１の認証システムの構成の一例を示す図である。 実施例１の認証サーバの構成の一例を示す図である。 実施例１の携帯端末の構成の一例を示す図である。 実施例１のユーザ認証データベースのデータ構造の一例を示す図である。 実施例１のチケット情報管理データベースのデータ構造の一例を示す図である。 実施例１の音データ生成情報に含まれる音特性管理情報のデータ構造の一例を示す図である。 実施例１の判定条件管理情報のデータ構造の一例を示す図である。 実施例１の判定条件管理情報のデータ構造の一例を示す図である。 実施例１の認証システムにおける処理の流れを説明するシーケンス図である。 実施例１の携帯端末が初期認証処理において実行する処理を説明するフローチャートである。 実施例１の認証サーバが初期認証処理において実行する処理を説明するフローチャートである。 実施例１の認証サーバが生成するタグのデータ構造の一例を示す図である。 実施例１の携帯端末が事前認証処理で実行する処理を説明するフローチャートである。 実施例１の認証サーバが事前認証処理で実行する処理を説明するフローチャートである。 実施例１の携帯端末が入場可否判定処理において実行する処理を説明するフローチャートである。 実施例１の入場管理端末が入場可否判定処理において実行する処理を説明するフローチャートである。

以下、図面を参照しながら本発明の実施の形態を説明する。なお、以下の説明では、「管理テーブル」等の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造（例えば、リスト、リポジトリ、キュー等）で表現されてもよい。また、データ構造に依存しないことを示すために「管理テーブル」を「管理情報」と称すことができる。

また、「プログラム」を主語として処理を説明する場合がある。そのプログラムは、プロセッサ、例えば、ＭＰＵ（Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｏｒ Ｕｎｉｔ）及びＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）によって実行され、定められた処理をするものである。なお、処理は、適宜、記憶資源（例えば、メモリ）及び通信インタフェース装置（例えば、ＬＡＮポート）を用いながら行われるため、処理の主語がプロセッサとされてもよい。プロセッサは、ＣＰＵの他に専用ハードウェアを有してもよい。プログラムは、プログラムソースから各コンピュータにインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディア等で提供されるものでもよい。

また、各要素、例えば、記憶装置は番号などで識別可能であるが、識別可能な情報であれば、名前など他種の識別情報が用いられてもよい。本発明の図及び説明において同一部分には同一符号を付与しているが、本発明が本実施例に制限されず、本発明の思想に合致するあらゆる応用例が本発明の技術的範囲に含まれる。また、特に明示しない限り、各構成要素は複数でもよいし、単数でもよい。

図１は、実施例１の認証システム１０の構成の一例を示す図である。

認証システム１０は、認証サーバ１００、複数の携帯端末１１０、施設１２０、及びビーコン信号発信装置１３０から構成される。認証サーバ１００、複数の携帯端末１１０、施設１２０、及びビーコン信号発信装置１３０は、ネットワーク１５０を介して互いに接続される。

ネットワーク１５０の種別はＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）及びＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等である。また、ネットワーク１５０の接続形式は有線及び無線のいずれでもよい。

認証システム１０は、ユーザが購入した電子チケットに関する認証処理を実行し、施設１２０へのユーザの入場を管理するためのシステムである。

認証サーバ１００は、携帯端末１１０と連携して認証処理を実行する。認証サーバ１００は、ビーコン情報更新モジュール２１０、音データ生成モジュール２１１、及び認証モジュール２１２を実現するプログラムを有し、また、ユーザ認証データベース２２０、チケット情報管理データベース２２１、及び音データ生成情報２２２を保持する。

認証サーバ１００のハードウェア構成及びソフトウェア構成の詳細は図２を用いて説明する。

施設１２０は、スタジアム及びコンサート会場等の施設である。施設１２０は、入場管理端末１２１、マイク１２２、及び入場管理機器１２３を有する。

マイク１２２は、携帯端末１１０が再生した音を集音する。集音された音は電子データとして入場管理端末１２１に入力される。

入場管理端末１２１は、携帯端末１１０と連携して入場可否判定処理を実行する。入場管理端末１２１は、入場可否判定処理において使用する判定条件管理情報１２５を保持する。判定条件管理情報１２５のデータ構造の詳細は図７Ａ及び図７Ｂを用いて説明する。入場管理端末１２１は、当該処理の結果に基づいて入場管理機器１２３を制御する。入場管理端末１２１のハードウェア構成は認証サーバ１００と同一であるものとする。

入場管理機器１２３は、ユーザの施設１２０への入場を管理する機器であり、例えば、表示装置及びゲート機構等が考えられる。

ビーコン信号発信装置（ビーコン）１３０はビーコン信号を発信する装置である。ビーコン信号発信装置１３０は、建物及び道路に設定される。なお、ビーコン信号発信装置１３０が発信するビーコン信号の発信方式は、ＢＬＥ（Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ）（Ｂｌｕｅｔｏｏｔｈは登録商標）等の電波方式及び超音波方式のいずれでもよい。

実施例１では、ビーコン信号に含まれるビーコン情報は、一定の周期で変化する値を含む。例えば、ＵＵＩＤ（Ｕｎｉｖｅｒｓａｌ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）に対応するビット列の一部が周期的に変化する。

携帯端末１１０はユーザが操作する端末である。携帯端末１１０は、例えば、スマートフォン、携帯電話機、タブレット型ＰＣ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｃｅ）等である。実施例１の携帯端末１１０は、認証アプリケーション３１１を実現するプログラムを有する。

認証アプリケーション３１１は、認証処理において認証サーバ１００から再生する音の音データを生成するための情報を取得し、また、入場可否判定処理において音データを生成し、生成された音データに対応する音を再生する。

なお、実施例１の認証処理及び入場可否判定処理はグループ単位で行うことも可能である。例えば、複数のユーザが「家族」、「友人」、「優待」等の属性の異なるグループで有効な電子チケット（グループ電子チケット）を購入した場合、各ユーザの携帯端末１１０が互いに通信し、任意の携帯端末１１０の認証アプリケーション３１１が主管の端末として処理を実行する。

図２は、実施例１の認証サーバ１００の構成の一例を示す図である。

認証サーバ１００は、ハードウェア構成として、ＣＰＵ２００、メモリ２０１、記憶装置２０２、及び通信インタフェース２０３を有する。各デバイスは、内部バス等を介して互いに接続される。

なお、認証サーバ１００は、オペレータが情報を入力するための入力装置及びオペレータに対して情報を出力するための出力装置を有してもよい。入力装置は、例えば、キーボード及びマウス等が考えられる。また、出力装置は、ディスプレイ装置及びプリンタ等が考えられる。

なお、認証サーバ１００にはオペレータが認証サーバ１００を操作するための端末が接続されてもよい。当該端末は入力装置及び出力装置を有する。

ＣＰＵ２００は、メモリ２０１に格納されたプログラムを実行する。ＣＰＵ２００は、後述するビーコン情報更新モジュール２１０、音データ生成モジュール２１１、及び認証モジュール２１２として処理を実行する。

メモリ２０１は、ＣＰＵ２００が実行するプログラム及びプログラムが使用するデータを格納する記憶装置である。メモリ２０１に格納されるプログラムについては後述する。

メモリ２０１は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の揮発性の記憶素子から構成される。なお、メモリ２０１は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等の不揮発性の記憶素子から構成されてもよい。なお、認証サーバ１００は、メモリ２０１とは別に、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）等の不変なプログラムが格納されるＲＯＭ等のメモリを有してもよい。

記憶装置２０２は、データを永続的に格納する。記憶装置２０２に格納されるデータについては後述する。

記憶装置２０２は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）及びＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の大容量かつ不揮発性の記憶装置が考えられる。メモリ２０１に格納されるプログラム及びデータは、記憶装置２０２に格納されてもよい。この場合、ＣＰＵ２００が、記憶装置２０２からプログラム及びデータを読み出し、メモリ２０１に読み出されたプログラム及びデータをロードし、ロードされたプログラムを実行する。

通信インタフェース２０３は、所定のプロトコルにしたがって、ネットワークを介した他の装置との通信を制御する。

ここで、メモリ２０１に格納されるプログラム及び記憶装置２０２に格納されるデータについて説明する。

実施例１のメモリ２０１は、ビーコン情報更新モジュール２１０、音データ生成モジュール２１１、及び認証モジュール２１２を実現するプログラムを格納する。

ビーコン情報更新モジュール２１０は、ビーコン信号に含まれるビーコン情報のパターン及び変更スケジュール等を更新する。音データ生成モジュール２１１は、携帯端末１１０が音データを生成するために使用する認証用データを生成する。認証モジュール２１２は、ユーザ及び電子チケットの認証を行う。

なお、認証サーバ１００が有する各モジュールについては、複数のモジュールを一つのモジュールにまとめてもよいし、一つのモジュールを機能ごとに複数のモジュールに分けてもよい。

実施例１の記憶装置２０２は、ユーザ認証データベース２２０、チケット情報管理データベース２２１、及び音データ生成情報２２２を格納する。

ユーザ認証データベース２２０は、各ユーザの認証に使用するデータを管理するためのデータベースである。ユーザ認証データベース２２０のデータ構造の詳細は図４を用いて説明する。

チケット情報管理データベース２２１は、電子チケットを管理するためのデータベースである。チケット情報管理データベース２２１のデータ構造の詳細は図５を用いて説明する。

音データ生成情報２２２は、音データを生成するための情報である。音データ生成情報２２２には、後述する音特性管理情報６００（図６参照）及び周波数サンプリングデータ等が含まれる。

なお、認証サーバ１００が有するプログラム及び情報は、外部のストレージシステムが有する記憶装置に格納されてもよい。なお、認証サーバ１００が有するプログラム及び情報は、仮想的な記憶装置に格納されてもよい。また、認証サーバ１００が有するプログラム及び情報は、予め認証サーバ１００に格納されてもよいし、ＣＤ−ＲＯＭ及びフラッシュメモリ等のリムーバブルメディアを用いてインストールしてもよいし、また、ネットワーク１５０を介して接続される外部装置から取得してもよい。インストール又はネットワーク１５０を介して取得されたプログラム及び情報は、非一時的な記憶媒体である記憶装置２０２に格納される。

なお、認証サーバ１００は、ユーザ認証データベース２２０及びチケット情報管理データベース２２１を直接管理していなくてよい。この場合、認証サーバ１００は、図示しないサーバが管理するユーザ認証データベース２２０及びチケット情報管理データベース２２１にアクセス可能に接続される。

なお、認証システム１０は複数の認証サーバ１００を備えてもよい。この場合、プログラム及び情報は分散して格納してもよい。また、認証サーバ１００は、物理的な計算機を用いて実現してもよいし、仮想的な計算機を用いて実現してもよい。

図３は、実施例１の携帯端末１１０の構成の一例を示す図である。

携帯端末１１０は、ＣＰＵ３００、メモリ３０１、記憶装置３０２、通信インタフェース３０３、入力装置３０４、出力装置３０５、ＧＰＳセンサ３０６、近距離通信装置３０７、ビーコン信号検出装置３０８、及びビーコン信号分析装置３０９を有する。各デバイスは、内部バス等を介して通信可能に接続される。

ＣＰＵ３００、メモリ３０１、記憶装置３０２、及び通信インタフェース３０３は、ＣＰＵ２００、メモリ２０１、記憶装置２０２、及び通信インタフェース２０３と同様のハードウェアである。

入力装置３０４は、操作キー及びタッチパネル等、携帯端末１１０にデータを入力するための装置である。入力装置３０４にはカメラ及びマイクが含まれる。

出力装置３０５は、ディスプレイ（タッチパネル）等、携帯端末１１０を操作するユーザにデータを出力するための装置である。出力装置３０５にはスピーカが含まれる。ディスプレイには、例えば、カメラによって撮影された画像にビーコン信号等の情報を付加した画像が表示される。

ＧＰＳセンサ３０６は、携帯端末１１０の位置を取得するための装置である。なお、携帯端末１１０は、ＧＰＳセンサ３０６の代わりに、ビーコン信号等を用いた測位センサ、基地局との通信によって位置を計測するデバイスを有してもよい。実施例１では、ＧＰＳセンサ３０６によって取得された位置の情報は、移動経路及び移動距離の推定等に用いられる。

近距離通信装置３０７は、短距離の装置間の通信を制御する装置である。

ビーコン信号検出装置３０８は、ビーコン信号を検出する装置である。ＢＬＥ等の電波方式でビーコン信号が発信される場合、ビーコン信号検出装置３０８は、近距離通信装置３０７を介して受信した信号からビーコン信号を検出する。超音波方式でビーコン信号が発信される場合、ビーコン信号検出装置３０８は、マイクを介して受信した音（信号）からビーコン信号を検出する。

ビーコン信号分析装置３０９は、ビーコン信号検出装置３０８によって検出されたビーコン信号からビーコン情報を抽出する。抽出されたビーコン情報は、認証アプリケーション３１１等によって用いられる。なお、ビーコン信号分析装置３０９は、ビーコン情報を出力する場合、抽出されたビーコン情報をそのまま出力してもよいし、データの整形及び変換、紐付けられている関連情報の付加等の加工を行い、加工されたビーコン情報を出力してもよい。

ここで、メモリ３０１に格納されるプログラム及び情報、並びに記憶装置３０２に格納される情報について説明する。

メモリ３０１は、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）３１０及び認証アプリケーション３１１を実現するプログラムを格納し、また、入場用データ３２１を格納する。記憶装置３０２は、認証用データ３２０を格納する。

ＯＳ３１０は、携帯端末１１０全体を制御する。認証アプリケーション３１１は、認証処理及び入場可否判定処理で必要な処理を実行する。

認証用データ３２０は、後述する事前認証処理及び入場可否判定処理で用いられる情報である。入場用データ３２１は、後述する入場可否判定処理で用いられる情報である。

図４は、実施例１のユーザ認証データベース２２０のデータ構造の一例を示す図である。

図４に示すユーザ認証データベース２２０は、テーブル形式のデータを管理するデータベースであり、一つのエントリはユーザＩＤ４０１、接続状態４０２、接続プロトコル４０３、認証鍵４０４、端末ＩＤ４０５、及びセッション情報４０６から構成される。一つのエントリが一人のユーザに対応する。

なお、エントリは、前述したフィールドのいずれかを含まなくてもよい。また、エントリには、前述した以外のフィールドが含まれてもよい。

ユーザＩＤ４０１は、ユーザを識別するための識別情報を格納するフィールドである。ユーザＩＤ４０１には、例えば、ユーザの名称及び識別番号等が格納される。なお、ユーザＩＤ４０１には、ユーザの名称等から算出されたハッシュ値が格納されてもよい。

接続状態４０２は、ユーザが操作する携帯端末１１０及び認証サーバ１００の間の接続状態を示す情報を格納するフィールドである。接続状態４０２には、携帯端末１１０が認証サーバ１００に接続している状態を示す「Ｌｏｇｉｎ」及び携帯端末１１０が認証サーバ１００に接続していない状態を示す「Ｌｏｇｏｆｆ」のいずれかが格納される。

接続プロトコル４０３は、ユーザが操作する携帯端末１１０及び認証サーバ１００の間の通信で使用される通信プロトコルを示す情報を格納するフィールドである。

認証鍵４０４は、ユーザの認証に使用する情報を格納するフィールドである。認証鍵４０４には、ハッシュ化されたパスワード等が格納される。

端末ＩＤ４０５は、ユーザが操作する携帯端末１１０を識別するための識別情報を格納するフィールドである。端末ＩＤ４０５には、例えば、ハッシュ化された識別番号が格納される。

セッション情報４０６は、ユーザが操作する携帯端末１１０及び認証サーバ１００の間に確立されたセッションの情報を格納するフィールドである。セッション情報４０６には、セッション番号及びセッションの有効期限等が格納される。図４に示す一番目のエントリのセッション情報４０６にはセッション番号として「１１」が格納され、また、セッションの有効期限として「２０１８０１１５＿１０：００：００」が格納される。

図５は、実施例１のチケット情報管理データベース２２１のデータ構造の一例を示す図である。

図５に示すチケット情報管理データベース２２１は、テーブル形式のデータを管理するデータベースであり、一つのエントリは、チケットＩＤ５０１、ユーザＩＤ５０２、ステータス５０３、アクセス鍵５０４、暗号鍵５０５、音ＩＤ５０６、及び期限５０７から構成される。ユーザＩＤ５０２はユーザＩＤ４０１と同一のフィールドである。一つのエントリが一つの電子チケットに対応する。

なお、エントリは、前述したフィールドのいずれかを含まなくてもよい。また、エントリには、前述した以外のフィールドが含まれてもよい。

チケットＩＤ５０１は、電子チケットを識別するための識別情報を格納するフィールドである。チケットＩＤ５０１には、識別番号、並びに、イベント名及び座席番号の組等が格納される。なお、チケットＩＤ５０１には、イベント名及び座席番号の組等から算出されたハッシュ値が格納されてもよい。

ステータス５０３は、電子チケットのステータスを示す情報を格納するフィールドである。ステータス５０３には、処理の実行状態を示す情報等が格納される。なお、ステータス５０３には、ステータス５０３が更新されたタイムスタンプを含めてもよい。

アクセス鍵５０４は、エントリの参照及び更新が行われる場合に用いられる認証用の情報を格納するフィールドである。

暗号鍵５０５は、携帯端末１１０によって生成された暗号鍵（公開鍵）を格納するフィールドである。

音ＩＤ５０６は、後述する音特性管理情報６００のエントリを特定するための識別情報を格納するフィールドである。音ＩＤ５０６は、後述する音ＩＤ６０１に対応する。

期限５０７は、電子チケットに関連する期限を格納するフィールドである。実施例１の期限５０７には、電子チケットの有効期限及び事前認証処理の実行期間を示す情報が格納される。図５に示す一番目のエントリの期限５０７には、電子チケットの有効期限として「２０１８０３０１＿２０：００：００」が格納され、また、事前認証処理の実行期間を示す情報として「−１２ｈｒ」が格納される。これは、電子チケットの有効期限から１２時間前の時刻が、事前認証処理が可能な期間の始点であることを示す。この場合、事前認証処理が可能な期間の終点は有効期限となる。

図６は、実施例１の音データ生成情報２２２に含まれる音特性管理情報６００のデータ構造の一例を示す図である。

音特性管理情報６００は、音の特性を管理するための情報である。音特性管理情報６００は、テーブル形式の情報であり、一つのエントリは、音ＩＤ６０１、ビットレート６０２、周波数制御シーケンス６０３、及び振幅制御シーケンス６０４から構成される。一つのエントリが一つの音の特性を示すデータに対応する。

なお、エントリは、前述したフィールドのいずれかを含まなくてもよい。また、エントリには、前述した以外のフィールドが含まれてもよい。

音の特性は、音の特性を表す要素の変動パターンの組合せとして表される。要素の変動パターンは、要素の変動規則及び要素の値の組合せで表される。要素の変動パターンは、音の特性を識別する識別装置の分解能に対応した粒度で設定できる。識別装置の分解能が高いほど要素の変動パターンの数は多くできるため、再生される音の種類も多くなる。したがって、要素が異なっていても変動規則が同一である場合、識別装置は、同一の特性の音として識別できる。なお、要素及び変動規則の関係が反対である場合に同一の特性の音として識別してもよい。実施例１では、音の特性を表す要素として周波数及び振幅を用いる。

周波数に着目した場合、周波数４４０Ｈｚの音を１秒間再生し、周波数８８０Ｈｚの音を１秒間再生し、周波数２２０Ｈｚの音を１秒間再生する音が考えられる。この場合、識別装置は、周波数の変動規則、周波数の変動幅、周波数の変動比率（最大値及び最小値の比率）、任意の周波数の音の持続時間、及び周波数の変更タイミング等を音の特性として取得できる。

振幅に着目した場合、中音量の音を１．５秒間再生し、大音量の音を１秒間再生し、小音量の音を０．５秒再生する音が考えられる。この場合、識別装置は、振幅の変動規則、振幅の変動幅、振幅の変動比率、任意の音量の音の持続時間、及び、音量の変更タイミング等を音の特性として取得できる。

音ＩＤ６０１は、音の特性を識別するための識別情報を格納するフィールドである。音ＩＤ６０１には、識別番号等が格納される。

ビットレート６０２は、再生する音のビットレートを格納するフィールドである。ビットレートは、サンプリングレート及びビット深度の積として表される。

実施例１では、音の特性に応じて様々なビットレートを設定できる。一般的に周波数が高い音を再生する場合、サンプリングレートを高く設定することが望ましく、また、ダイナミックレンジが広く又は分解能を高く設定する場合、ビット深度を大きくすることが望ましい。最大周波数が小さく、また、振幅の変動比が小さい音は、ビットレートを低く設定しても、再生される音の劣化は少ないため、データのサイズを小さくできる。

周波数制御シーケンス６０３は、周波数の変動パターンを示す情報を格納するフィールドである。実施例１の周波数制御シーケンス６０３には、周波数及び持続時間の組が一つ以上格納される。前述の組は再生順に設定される。なお、周波数制御シーケンス６０３に設定する組の数は任意に変更できる。

振幅制御シーケンス６０４は、振幅の変動パターンを示す情報を格納するフィールドである。実施例１の振幅制御シーケンス６０４には、振幅及び持続時間の組が一つ以上格納される。前述の組は再生順に設定される。なお、振幅制御シーケンス６０４に設定する組の数は任意に変更できる。

音量の大きさは、再生装置ごとに異なるため、実施例１では、振幅を示す値としてレベルを用いる。なお、音量は外部の影響（ノイズ）を受けやすいことから、総じて大きな音が再生されるようにレベルを設定することが望ましい。音量を「０」とする場合、識別装置はノイズを考慮して音の特性を識別する必要がある。

なお、周波数及び振幅のそれぞれの持続時間は異なっていてもよい。なお、周波数及び振幅は直接指定せずに、任意の幅で分割された周波数のレンジ及び振幅のレンジを指定してもよい。この場合、再生装置は、指定されたレンジからランダムに値を選択する。

図７Ａ及び図７Ｂは、実施例１の判定条件管理情報１２５のデータ構造の一例を示す図である。

図７Ａは、識別周波数ごとに判定条件が設定された判定条件管理情報１２５を示す。図７Ａに示す判定条件管理情報１２５に含まれるエントリは、基準値７０１及び判定条件７０２から構成される。一つのエントリは一つの判定条件に対応する。

基準値７０１は、判定条件を識別するための識別周波数を格納するフィールドである。判定条件７０２は、携帯端末１１０によって再生された音の特性を確認するための判定基準を格納するフィールドである。

判定基準には、要素の相対的な変化を利用する。携帯端末１１０及びマイク１２２の距離は一定ではなく、また、マイク１２２は、携帯端末１１０が生成した音を集音する場合に環境音等の雑音を集音する可能性があるためである。また検出タイミングのずれ及び精度の劣化等も考慮する必要があるためである。

例えば、周波数レンジ及び音量レベル等の要素の変動パターン、持続時間、変動回数、変動幅、変動比等を判定基準として用いることができる。判定条件７０２には、前述のような判定基準が少なくとも一つ設定される。

図７Ｂは、参照値ごとに判定条件が設定された判定条件管理情報１２５を示す。図７Ｂに示す判定条件管理情報１２５に含まれるエントリは、参照値５１１及び判定条件５１２から構成される。一つのエントリは判定条件グループに対応する。一つのエントリには複数の判定条件が含まれる。

参照値５１１は、判定条件グループを識別するための、ビーコン信号に含まれるＵＵＩＤの一部を格納するフィールドである。実施例１では、ビーコン信号のＵＵＩＤに対応するビット列は不変部分及び可変部分を含み、参照値５１１には可変部分の値が設定される。判定条件５１２は判定条件７０２と同一のフィールドである。

図８は、実施例１の認証システム１０における処理の流れを説明するシーケンス図である。

認証システム１０で行われる処理は、電子チケットの購入に伴って行われる初期認証処理、経路ビーコン信号の検出を契機に実行される事前認証処理、会場ビーコン信号の検出を契機に実行される入場可否判定処理の三つに分けることができる。

ユーザは、携帯端末１１０を操作して電子チケットの購入手続を行う（ステップＳ１０１）。このとき、携帯端末１１０は、購入情報を認証サーバ１００に送信する（ステップＳ１０２）。購入情報には、少なくとも、電子チケットの識別情報、ユーザの識別情報、及び携帯端末１１０に情報を送信するためのアクセス情報が含まれる。アクセス情報は例えばメールアドレスである。

認証サーバ１００は、購入情報を受信した場合、チケット情報管理データベース２２１を更新する（ステップＳ１０３）。

例えば、認証モジュール２１２は、チケット情報管理データベース２２１にエントリを追加し、追加されたエントリのチケットＩＤ５０１及びユーザＩＤ５０２に購入情報に含まれる電子チケットの識別情報及びユーザの識別情報を設定する。また、認証モジュール２１２は、期限５０７に電子チケットの有効期限及び事前認証処理の実行期間を設定する。実行期間は任意の基準にしたがって設定されるものとする。

なお、グループ電子チケットの場合、認証モジュール２１２は、追加されたエントリのユーザＩＤ５０２にグループに含まれる各ユーザの識別情報を設定する。また、別の登録方法としては、認証モジュール２１２は、グループに含まれるユーザの数だけエントリを追加し、追加された各エントリのユーザＩＤ５０２に各ユーザの識別情報を設定する。この場合、チケットＩＤ５０１には同一の電子チケットの識別情報が格納されてもよいし、異なる電子チケットの識別情報が格納されてもよい。ただし、グループ電子チケットであることが特定できる識別情報であるものとする。

なお、電子チケットの購入は、携帯端末１１０を経由して行う必要はなく、販売所でユーザが直接電子チケットを購入し、また、お店に設置された端末をユーザが操作して電子チケットを購入してもよい。この場合、電子チケットを管理するサーバが、認証サーバ１００に購入情報を送信する。

次に、認証サーバ１００は、携帯端末１１０に、認証サーバ１００にアクセスするためのＵＲＬを送信する（ステップＳ１０４）。ＵＲＬの送信方法は、電子メール等を利用する方法が考えられる。購入した電子チケットがグループ電子チケットである場合、グループに属する複数のユーザが操作する携帯端末１１０にＵＲＬが送信される。

次に、携帯端末１１０は、認証サーバ１００から通知されたＵＲＬへアクセスし、認証サーバ１００と連携して初期認証処理を実行する（ステップＳ１０５）。初期認証処理において認証サーバ１００及び携帯端末１１０が実行する処理の詳細は、図９及び図１０を用いて説明する。

なお、初期認証処理は、ＵＲＬの通知から一定期間内に実行されることが望ましい。そこで、ＵＲＬの有効期限が設定されているものとする。

ユーザはイベントが行われる施設１２０に向けて移動を開始する。このとき、携帯端末１１０は、移動経路に設置されたビーコン信号発信装置１３０が発信した経路ビーコン信号を検出した場合（ステップＳ１１１）、認証サーバ１００と連携して事前認証処理を実行する（ステップＳ１１２）。事前認証処理において認証サーバ１００及び携帯端末１１０が実行する処理の詳細は、図１２及び図１３を用いて説明する。

経路ビーコン信号を発信するビーコン信号発信装置１３０は、電車及びバス等の移動体、建物、並びに、イベント開催に併せて臨時に設置された案内板等に設置される。移動体に設置されたビーコン信号発信装置１３０が発信するビーコン信号を利用する場合、施設１２０の近くの降車場所にユーザが降車し、ビーコン信号が受信できなくなったことを、経路ビーコン信号の検出として扱ってもよい。降車場所は、ＧＰＳセンサ３０６を用いた移動距離の測定及び地図情報の活用によって特定できる。

認証サーバ１００は、事前認証処理の結果に基づいて、入場可否判定処理で使用する判定条件を入場管理端末１２１に送信する（ステップＳ１１３）。入場管理端末１２１は、判定条件管理情報１２５に受信した判定条件を格納する。このとき、認証サーバ１００は、会場ビーコン信号のビーコン情報のパターン及び変更スケジュールを通知してもよい。

ユーザが施設１２０に到着した後、携帯端末１１０は、施設１２０に設置されたビーコン信号発信装置１３０が発信した会場ビーコン信号を検出した場合（ステップＳ１２１）、入場管理端末１２１と連携して入場可否判定処理を実行する（ステップＳ１２２）。入場可否判定処理において入場管理端末１２１及び携帯端末１１０が実行する処理の詳細は、図１４及び図１５を用いて説明する。

経路ビーコン信号は、移動経路に設置され、かつ、施設１２０からの距離が一定の範囲内であるビーコン信号発信装置１３０から発信されるように設定する。なお、移動経路に設置されたビーコン信号発信装置１３０は、固定的に設置されている必要はなく、移動体に設置されていてもよい。

会場ビーコン信号は、施設１２０からの距離が一定の範囲内であるビーコン信号発信装置１３０から発信されるように設定する。当該ビーコン信号発信装置１３０も固定的に設置されている必要はない。ビーコン信号発信装置１３０は、施設１２０に設置されていてもよいし、施設１２０の近くに設置されてもよい。

図９は、実施例１の携帯端末１１０が初期認証処理において実行する処理を説明するフローチャートである。

ユーザが、携帯端末１１０を用いて認証サーバ１００が通知したＵＲＬを操作した場合、認証アプリケーション３１１が起動し、以下で説明する処理を開始する。

認証アプリケーション３１１は、ＵＲＬで指定された宛先（認証サーバ１００）にログイン要求を送信する（ステップＳ２０１）。

ログイン要求に基づくログイン処理が正常に完了した場合、認証アプリケーション３１１は、暗号鍵を生成し、認証サーバ１００に生成された暗号鍵を送信する（ステップＳ２０２）。

具体的には、認証アプリケーション３１１は、公開鍵及び秘密鍵の鍵ペアを生成し、認証サーバ１００に公開鍵を送信する。

次に、認証アプリケーション３１１は、認証サーバ１００から認証用データ３２０を受信する（ステップＳ２０３）。後述するように認証用データ３２０には、公開鍵を用いて暗号化されたデータを含むタグが付与される。

次に、認証アプリケーション３１１は、正常なデータであるか否かを判定するために認証用データ３２０を検証する（ステップＳ２０４）。

具体的には、認証アプリケーション３１１は、認証用データ３２０の破損、及び識別可能な特性を有する音を再生できるか否か等が検証する。このとき、認証アプリケーション３１１は、認証用データ３２０に付与されるタグに設定された値を、秘密鍵を用いて復号化し、復号化されたデータを用いて前述した判定を実行してもよい。

なお、複数の認証用データ３２０を受信した場合、認証アプリケーション３１１は、各認証用データ３２０を検証する。

次に、認証アプリケーション３１１は、検証が成功したか否かを判定する（ステップＳ２０５）。

検証が失敗した場合、認証アプリケーション３１１は、ステップＳ２０２に戻り、同様の処理を実行する。

検証が成功した場合、認証アプリケーション３１１は、認証用データ３２０及び秘密鍵を保存する（ステップＳ２０６）。

具体的には、認証アプリケーション３１１は、記憶装置３０２に認証用データ３２０を格納し、メモリ３０１に秘密鍵を格納する。認証用データ３２０及び秘密鍵は、施設１２０への入場が正常に行われた場合、又は、電子チケットの有効期限が経過した場合に削除される。

次に、認証アプリケーション３１１は、認証サーバ１００に、認証用データ３２０を正常に受信した旨を通知する正常受領通知を送信する（ステップＳ２０７）。

次に、認証アプリケーション３１１は、認証サーバ１００にログアウト要求を送信し（ステップＳ２０８）、処理を終了する。

図１０は、実施例１の認証サーバ１００が初期認証処理において実行する処理を説明するフローチャートである。図１１は、実施例１の認証サーバ１００が生成するタグのデータ構造の一例を示す図である。

認証サーバ１００の音データ生成モジュール２１１は、携帯端末１１０からログイン要求を受信した場合、ログイン処理を実行する（ステップＳ３０１）。なお、ログイン処理は、音データ生成モジュール２１１以外のモジュールが実行してもよい。

ログイン処理は公知の技術を用いればよいため詳細な説明は省略する。なお、ログイン処理が正常に完了した場合、音データ生成モジュール２１１は、携帯端末１１０との間にセッションを確立する。このとき、音データ生成モジュール２１１は、ユーザ認証データベース２２０を参照し、携帯端末１１０を操作するユーザに対応するエントリを検索する。音データ生成モジュール２１１は、検索されたエントリの接続状態４０２に「Ｌｏｇｉｎ」を設定し、接続プロトコル４０３にプロトコルの情報を設定する。また、音データ生成モジュール２１１は、検索されたエントリのセッション情報４０６に確立されたセッションの情報を設定する。

ログイン処理が正常に完了し、かつ、携帯端末１１０から公開鍵を受信した場合、認証サーバ１００の音データ生成モジュール２１１は、携帯端末１１０を操作するユーザの電子チケットを特定する（ステップＳ３０２）。

具体的には、音データ生成モジュール２１１は、チケット情報管理データベース２２１を参照し、ユーザＩＤ５０２にユーザの識別情報が設定されたエントリを検索する。チケット情報管理データベース２２１にグループ電子チケットのエントリが複数存在する場合、音データ生成モジュール２１１は、ユーザが属するグループのグループ電子チケットに関連するエントリを全て検索する。

このとき、音データ生成モジュール２１１は、検索されたエントリの暗号鍵５０５に受信した公開鍵を設定する。

次に、認証サーバ１００の音データ生成モジュール２１１は、音データ生成情報２２２に基づいて音データを生成する（ステップＳ３０３）。例えば、以下のような処理によって音データが生成される。

音データ生成モジュール２１１は、音データ生成情報２２２に含まれる音特性管理情報６００を参照し、エントリを一つ選択する。例えば、音データ生成モジュール２１１は、携帯端末１１０が再生可能な音の特性を確認し、当該音の特性に合致するエントリを検索する。

音データ生成モジュール２１１は、当該エントリのビットレート６０２、周波数制御シーケンス６０３、及び振幅制御シーケンス６０４に格納される値から構成されるデータを音データとして生成する。

音データ生成モジュール２１１は、ステップＳ３０２において検索されたエントリの音ＩＤ５０６に、選択されたエントリの音ＩＤ６０１の値を設定する。以上がステップＳ３０３の処理の一例である。

次に、認証サーバ１００の音データ生成モジュール２１１は、音データに付与するタグを生成する（ステップＳ３０４）。ここで、図１１を用いてタグのデータ構造について説明する。

実施例１では、ＭＰ３形式に準拠した音データが生成される。この場合、ＭＰ３形式のＩＤ３ｖ１タグを音データに付与するタグとして用いることができる。なお、ＩＤ３ｖ１タグを拡張したＩＤ３ｖ２タグを音データに付与するタグとして用いてもよい。なお、ＩＤ３ｖ１タグの各領域には約３０バイト程度のデータしか格納できないが、ＩＤ３ｖ２タグでは各領域に格納できるデータのサイズは約１６ＭＢまで拡張されている。

図１１に示すＩＤ３ｖ１タグ１１００は、タグ識別子１１０１、タイトル情報１１０２、アーティスト情報１１０３、アルバム情報１１０４、日付情報１１０５、コメント情報１１０６、及びジャンル識別子１１０７から構成される。なお、各領域の数値は領域に格納できるデータのサイズを示す。

タグ識別子１１０１は、「ＴＡＧ」の文字列が格納される。タイトル情報１１０２は、楽曲名（タイトル）を格納する領域である。アーティスト情報１１０３は、アーティストの名称を格納する領域である。アルバム情報１１０４は、アルバムの名称を格納する領域である。日付情報１１０５は、日付を格納する領域である。コメント情報１１０６は、コメントを格納する領域である。なお、最後から２バイトはＮｕｌｌ文字及びトラック番号が格納される場合がある。ジャンル識別子１１０７は、予め定義されたジャンルの識別番号が格納される。

実施例１では、タイトル情報１１０２及びアーティスト情報１１０３に、電子チケットに関連する情報を格納する。電子チケットに関連する情報としては、チケット情報管理データベース２２１のアクセス鍵５０４に設定する鍵、電子チケットの識別情報、及び座席番号が考えられる。異なる情報をタイトル情報１１０２及びアーティスト情報１１０３のそれぞれに格納してもよいし、一つの情報を分割し、タイトル情報１１０２及びアーティスト情報１１０３のそれぞれに格納してもよい。

なお、タイトル情報１１０２及びアーティスト情報１１０３には、公開鍵を用いて暗号化された情報が格納される。

なお、再生ソフトウェア等が異常な文字列として認識しないように、当該領域に設定される情報の先頭にＮｕｌｌ文字を格納してもよい。

実施例１では、アルバム情報１１０４に、電子チケットの有効期限に関する情報を格納する。アルバム情報１１０４には、事前認証処理が実行可能な日時を格納してもよい。なお、有効期限及び日付は、イベントが推定される可能性があるため、公開鍵を用いて情報を暗号化することが望ましい。

実施例１では、コメント情報１１０６に、データ保証コード及び訂正コード等のデータ保護用情報を格納する。データ保護用情報は、データ欠損等が生じた場合に、データを修復するための情報である。なお、コメント情報１１０６には、データ保護用情報の代わりに、認証サーバ１００にデータの修復及び新たなデータの取得を依頼するための情報を格納してもよい。この場合、公開鍵を用いて情報を暗号化することが望ましい。

なお、コメント情報１１０６には、音の特性を検証するための情報が格納されてもよい。当該情報は、認証用データ３２０の簡易判定が行える程度の情報であればよい。例えば、周波数の変動回数、振幅の変動回数等をコメント情報１１０６に格納する。携帯端末１１０は、認証用データ３２０を検証する場合に、当該情報を用いることによって、識別可能な特性の音を再生できるか否かを検証できる。

実施例１では、ジャンル識別子１１０７に、固定のダミー値及びランダムな値を格納する。また、再生機器が音を再生する場合に最適なイコライザ設定等を選択するための情報が格納されてもよい。

以上が音データに付与するタグの説明である。図１０の説明に戻る。

次に、認証サーバ１００の音データ生成モジュール２１１は、タグが付与された音データを認証用データ３２０として、携帯端末１１０に送信する（ステップＳ３０５）。その後、認証サーバ１００は、携帯端末１１０からの応答を受信するまで待ち状態に移行する。

認証サーバ１００の音データ生成モジュール２１１は、携帯端末１１０から受信した応答が正常受領通知であるか否かを判定する（ステップＳ３０６）。

受信した応答が正常受領通知ではないと判定された場合、認証サーバ１００の音データ生成モジュール２１１は、ステップＳ３０３に戻り、同様の処理を実行する。

受信した応答が正常受領通知であると判定された場合、認証サーバ１００の音データ生成モジュール２１１は、チケット情報管理データベース２２１を更新する（ステップＳ３０７）。

具体的には、音データ生成モジュール２１１は、ステップＳ３０２において検索されたエントリのステータス５０３に初期認証処理が完了したことを示す情報を設定する。例えば、「初期認証済み」、「認証用データ送付済」等がステータス５０３に設定される。なお、ステータス５０３が更新されたタイムスタンプを含めてもよい。

次に、認証サーバ１００の音データ生成モジュール２１１は、携帯端末１１０からログアウト要求を受信した場合、ログアウト処理を実行する（ステップＳ３０８）。

ログアウト処理は公知の技術を用いればよいため詳細な説明は省略する。なお、ログアウト処理が正常に完了した場合、音データ生成モジュール２１１は、ユーザ認証データベース２２０を参照し、携帯端末１１０を操作するユーザに対応するエントリを検索する。音データ生成モジュール２１１は、検索されたエントリの接続状態４０２に「Ｌｏｇｏｕｔ」を設定し、接続プロトコル４０３及びセッション情報４０６を初期化する。

図１２は、実施例１の携帯端末１１０が事前認証処理で実行する処理を説明するフローチャートである。

認証アプリケーション３１１は、経路ビーコン信号を検出した場合、以下で説明する処理を開始する。なお、携帯端末１１０が処理を開始するタイミングは、経路ビーコン信号の検出以外でもよい。例えば、以下のようなタイミングが考えられる。

（実行タイミング１）認証サーバ１００が予め携帯端末１１０の処理の実行スケジュールを生成し、当該スケジュールにしたがって実行指示を携帯端末１１０に送信する。実行指示を送信するタイミングは、例えば、電子チケットの有効期限に基づいて決定される。ただし、ユーザが施設１２０に到着する前に行われるようなスケジュールである必要がある。また、一度に多数の携帯端末１１０が処理を実行しないようなスケジュールである必要がある。

（実行タイミング２）認証アプリケーション３１１は、ＧＰＳセンサ３０６を用いて、任意の座標に到着したことを検出した場合に処理を開始する。座標は、認証サーバ１００によって決定され、携帯端末１１０に通知される。なお、座標は、施設１２０から一定の距離が離れている移動経路の任意の位置である必要がある。

（実行タイミング３）認証アプリケーション３１１は、カメラを用いて、道路標識等、特定の画像を検出した場合に処理を開始する。検出する画像は、認証サーバ１００によって決定され、携帯端末１１０に通知される。なお、画像は、施設１２０から一定の距離が離れている移動経路上に存在するオブジェクトの画像である必要がある。

実施例１では、経路ビーコン信号の検出を処理の開始タイミングに採用した理由は、ユーザは様々な移動手段で任意の時間に施設１２０へ移動することから、認証サーバ１００へのリクエストの送信タイミングを分散させるためである。また、経路ビーコン信号の検出を開始タイミングとした場合、（実行タイミング１）、（実行タイミング２）、及び（実行タイミング３）のような情報の設定が必要ないためである。

まず、認証アプリケーション３１１は、認証用データに付与されるタグを解析する（ステップＳ４０１）。

具体的には、認証アプリケーション３１１は、秘密鍵を用いてタグの暗号化されたデータを復号化する。

次に、認証アプリケーション３１１は、タグの解析結果に基づいて、有効期限内の電子チケットを所有しているか否かを判定する（ステップＳ４０２）。

具体的には、認証アプリケーション３１１は、アルバム情報１１０４に設定された電子チケットの有効期限情報と現在時刻とを比較し、有効な電子チケットを所有しているか否かを判定する。有効な電子チケットを所有している場合、認証アプリケーション３１１は、さらに現在時刻が事前認証処理の実行期間内であるか否かを判定する。なお、アルバム情報１１０４に直接、事前認証処理の実行期間が含まれる場合、認証アプリケーション３１１は、当該期間と現在時刻とを比較して判定を行う。

有効な電子チケットを所有していない場合、又は、有効な電子チケットを所有しているが事前認証処理の実行期間外である場合、認証アプリケーション３１１は、処理を終了する。このとき、認証アプリケーション３１１は、不要な認証用データ３２０を削除する。

有効な電子チケットを所有し、かつ、事前認証処理の実行期間内である場合、認証アプリケーション３１１は、認証サーバ１００にタグから取得した情報を送信する（ステップＳ４０３）。このとき、認証アプリケーション３１１は、復号化されたタグの情報を暗号化通信にて送信する。認証アプリケーション３１１は、認証サーバ１００から認証結果を受信するまで待ち状態に移行する。なお、携帯端末１１０及び認証サーバ１００は、暗号化通信で使用する暗号鍵を互いに保持する。

このとき、認証アプリケーション３１１は、認証用データ３２０から暗号化されたデータを削除してもよい。また、認証アプリケーション３１１は、タグから取得した情報とともに、位置情報又は経路ビーコン信号に含まれるビーコン情報を送信してもよい。

なお、セキュリティを考慮して、認証サーバ１００に情報を送信する前にログイン処理が実行されるように制御してもよい。

なお、自分及び他人のグループ電子チケットを所有している場合、認証アプリケーション３１１は、各グループ電子チケットの認証用データ３２０のタグから取得した情報を送信する。

認証アプリケーション３１１は、認証サーバ１００から認証結果を受信した場合、認証が成功したか否かを判定する（ステップＳ４０４）。

認証が成功した場合、認証アプリケーション３１１は、認証結果とともに送信された入場用データ３２１をメモリ３０１に保存する（ステップＳ４０５）。その後、認証アプリケーション３１１は、処理を終了する。なお、ログイン処理が実行されている場合、ログアウト処理が実行されるように制御する。

ここで、メモリ３０１に入場用データ３２１を格納する理由は、入場用データ３２１を容易に取り出せないようにするためである。

認証が失敗した場合、認証アプリケーション３１１は、ユーザに対してエラーを通知し（ステップＳ４０６）、その後、処理を終了する。なお、ログイン処理が実行されている場合、ログアウト処理が実行されるように制御する。

図１２を用いて説明したように、事前認証処理では、ユーザの操作は必要なく、携帯端末１１０が自動的に処理を実行する。したがって、ユーザは、施設１２０への移動のみを行えばよい。

なお、有効期限を経過した電子チケットが存在する場合、認証アプリケーション３１１は、当該電子チケットに関連する認証用データ３２０及び入場用データ３２１を削除する。

図１３は、実施例１の認証サーバ１００が事前認証処理で実行する処理を説明するフローチャートである。

認証サーバ１００の認証モジュール２１２は、携帯端末１１０からタグの情報を受信した場合（ステップＳ５０１）、暗号化された通信を復号化する（ステップＳ５０２）。

具体的には、認証モジュール２１２は、暗号化通信の暗号鍵を用いて通信内容を復号化する。

なお、認証モジュール２１２は、携帯端末１１０から位置情報又は経路ビーコン信号に含まれるビーコン情報を受信した場合、当該情報に基づいて認証処理を開始するか否かを判定してもよい。

次に、認証サーバ１００の認証モジュール２１２は、復号化されたタグの情報及びチケット情報管理データベース２２１に基づいて認証処理を実行する（ステップＳ５０３）。認証処理は公知の技術を用いればよいため詳細な説明は省略する。

次に、認証サーバ１００の認証モジュール２１２は、認証が成功したか否かを判定する（ステップＳ５０４）。

認証が成功した場合、認証サーバ１００の認証モジュール２１２は、会場ビーコン信号に含まれるビーコン情報のパターン及び音の特性に基づいて入場用データ３２１を生成する（ステップＳ５０５）。また、認証サーバ１００の認証モジュール２１２は、携帯端末１１０に、入場用データ３２１とともに認証成功通知を送信する（ステップＳ５０６）。その後、認証サーバ１００の認証モジュール２１２は、処理を終了する。

例えば、ビーコン信号のＵＵＩＤの不変部分と、ビーコン信号のＵＵＩＤの可変部分のパターン及び音の特性の組合せとから構成される入場用データ３２１が生成される。このとき、認証モジュール２１２は、ビーコン情報更新モジュール２１０を介して、会場ビーコン信号を発信するビーコン信号発信装置１３０に、ビーコン信号に含まれるビーコン情報のパターンの変更スケジュール等を送信してもよい。

なお、入場用データ３２１には、緊急ビーコン信号等、特定の目的で使用されるビーコン信号に関する情報が含まれてもよい。また、サンプリングデータが含まれてもよい。

なお、緊急ビーコン信号は、携帯端末１１０ごとに異なるビーコン情報を含めることができる。これによって、携帯端末１１０は自身に関係する緊急ビーコン信号以外の緊急ビーコン信号を処理しないように制御できる。緊急ビーコン信号は、重大なインシデントが発生した場合の避難誘導、なりすまし等によって同一の認証用データ３２０が検出された場合の認証用データ３２０の更新処理の開始契機として利用される。

認証が失敗した場合、認証サーバ１００の認証モジュール２１２は、携帯端末１１０に、認証失敗通知を送信する（ステップＳ５０７）。その後、認証サーバ１００の認証モジュール２１２は、処理を終了する。

なお、有効期限を経過した電子チケットが存在する場合、認証サーバ１００は、チケット情報管理データベース２２１から、当該電子チケットに関連するエントリを削除する。また、認証サーバ１００は、必要に応じてユーザ認証データベース２２０からエントリを削除する。

図１４は、実施例１の携帯端末１１０が入場可否判定処理において実行する処理を説明するフローチャートである。

認証アプリケーション３１１は、会場ビーコン信号を受信した場合、以下で説明する処理を開始する。

認証アプリケーション３１１は、グループ電子チケットを所有しているか否かを判定する（ステップＳ６０１）。

例えば、認証アプリケーション３１１は、認証用データ３２０に付与されたタグのタイトル情報１１０２及びアーティスト情報１１０３の少なくともいずれかに格納される電子チケットの識別情報に基づいて、グループ電子チケットを所有しているか否かを判定する。また、認証アプリケーション３１１は、有効期限が同一かつ電子チケットの識別情報が異なる認証用データ３２０を複数保持するか否かを判定してもよい。

グループ電子チケットを所有していないと判定された場合、認証アプリケーション３１１は、ステップＳ６０４に進む。

グループ電子チケットを所有していると判定された場合、認証アプリケーション３１１は、当該グループ電子チケットのグループに属するユーザの携帯端末１１０と通信を行って、主管の携帯端末１１０を特定する。

主管の携帯端末１１０の認証アプリケーション３１１は、従属携帯端末１１０から公開鍵を取得する（ステップＳ６０２）。また、主管の携帯端末１１０の認証アプリケーション３１１は、従属携帯端末１１０から認証用データ３２０及び入場用データ３２１を取得する（ステップＳ６０３）。その後、主管の携帯端末１１０はステップＳ６０４に進む。

ステップＳ６０４では、認証アプリケーション３１１は、会場ビーコン信号に含まれるビーコン情報、認証用データ３２０、及び入場用データ３２１に基づいて、入場用音データを生成し（ステップＳ６０４）、入場用音データに基づいて音を再生する（ステップＳ６０５）。その後、認証アプリケーション３１１は、処理を終了する。ここで、入場用音データの生成方法の一例を説明する。

認証アプリケーション３１１は、新たに会場ビーコン信号を受信し、当該会場ビーコン信号からビーコン情報を取得する。認証アプリケーション３１１は、ビーコン情報のパターンに基づいて入場用データ３２１を参照し、音の特性を特定する。

認証アプリケーション３１１は、認証用データ３２０及び特定された音の特性に基づいて、入場用音データを生成する。例えば、以下のような生成方法が考えられる。

（生成方法１）認証アプリケーション３１１は、認証用データ３２０と特定された特性の音のデータとを連結して入場用音データを生成する。当該方法で生成された入場用音のデータの場合、認証用データ３２０に対応する音の後に、特定された特性の音が再生される。

（生成方法２）認証アプリケーション３１１は、認証用データ３２０と特定された特性の音のデータとを合成して入場用音データを生成する。当該方法で生成された入場用音のデータの場合、認証用データ３２０と特定された特性の音のデータ音とが重ね合わさった音が再生される。

（生成方法３）認証アプリケーション３１１は、認証用データ３２０に付与されるタグを用いて入場用データ３２１を検証し、検証が成功した場合に、特定された特性の音のデータを入場用音データとして出力する。

なお、入場用音データの生成タイミング及び音の再生タイミングは、ユーザの利便性を考慮して任意に設定できる。

例えば、携帯端末１１０の物理的な操作ボタン又はＧＵＩに表示された操作ボタンが押下された場合に、認証アプリケーション３１１は、入場用音データを生成し、音を再生する。ただし、出力装置３０５に含まれるスピーカが、マイク１２２が集音できる状態でない場合も考えられる。そこで、ユーザが、操作ボタンが押下した状態を維持し、マイク１２２が集音できる位置にスピーカの状態を変更した後に操作ボタンを放した場合に入場用音データの生成を開始してもよい。

また、入力装置３０４に含まれるカメラがユーザの手で覆われる等によって明度が変化した場合に入場用音データの生成を開始してもよい。

また、入場管理機器１２３がビーコン信号を発信している場合、認証アプリケーション３１１は、当該ビーコン信号を検出した場合に、音を再生してもよい。ビーコン信号は、携帯端末１１０のスピーカがマイク１２２の近づいた場合に発信することが望ましい。

また、携帯端末１１０のカメラがマイク１２２を検出した場合、認証アプリケーション３１１は、音を生成してもよい。

グループ電子チケットに関する処理の場合、認証アプリケーション３１１は、従属携帯端末１１０から受信した情報を用いて入場用音データを生成する。

主管の携帯端末１１０のみが音を再生する場合、所定の順番で入場用音データに基づく音が再生される。この場合、主管の携帯端末１１０が再生順を示す番号を携帯端末１１０に通知する。

グループ電子チケットを所有する各携帯端末１１０が音を再生する場合、主管の携帯端末１１０は、従属携帯端末１１０に入場用音データを送信する。ユーザは、任意のタイミングで音を再生する。このとき、各携帯端末１１０が、近接通信を行って、再生順を特定し、再生順を示す番号を携帯端末１１０に通知する。なお、グループの識別情報も合わせて通知されてもよい。

図１５は、実施例１の入場管理端末１２１が入場可否判定処理において実行する処理を説明するフローチャートである。

入場管理端末１２１は、マイク１２２が集音した音のデータを取得する（ステップＳ７０１）。

入場管理端末１２１は、取得した音のデータに基づいて、再生された音の特性を分析する（ステップＳ７０２）。具体的には、以下のような処理が実行される。

（処理１）入場管理端末１２１は、判定条件管理情報１２５に設定された判定条件と比較可能な音の特性情報を算出する。例えば、図７Ａに示す判定条件管理情報１２５の場合、入場管理端末１２１は、初期の周波数、周波数の変動回数、及び振幅の変動回数等を算出する。図７Ｂに示す判定条件管理情報１２５の場合、入場管理端末１２１は、周波数の変動回数及び振幅の変動回数等を算出する。なお、具体的な周波数及び振幅が算出されてもよい。

（処理２）入場管理端末１２１は、判定条件管理情報１２５からエントリを選択する。例えば、入場管理端末１２１が図７Ａに示す判定条件管理情報１２５を保持し、また、（生成方法１）で入場用音データが生成された場合、入場管理端末１２１は、基準値７０１が再生された音の最初の周波数に一致するエントリを選択する。入場管理端末１２１が図７Ｂに示す判定条件管理情報１２５を保持する場合、入場管理端末１２１は、会場ビーコン信号からビーコン情報を取得し、参照値５１１がビーコン情報に含まれるＵＵＩＤの可変部分と一致するエントリを選択する。

（処理３）入場管理端末１２１は、算出された音の特性情報及び判定条件管理情報１２５から選択されたエントリに設定された判定条件を比較して、判定条件を満たすか否かを判定する。

複数の要素に関する条件を含む判定条件の場合には以下のような判定が行われる。入場管理端末１２１は、少なくとも一つの要素に関する条件を満たす場合、又は、全ての要素に関する条件を満たす場合、判定条件を満たすと判定する。

（処理４）入場管理端末１２１は、入場管理機器１２３に含まれるディスプレイ等の出力装置に、判定結果を出力する。表示方法としては、入場許可及び入場拒否を視覚的に確認できるように、背景色を変える表示方法が考えられる。このような表示方法の場合、鏡及びＬＥＤ等を用いて携帯端末１１０のカメラが背景色を検出できるようにしてもよい。

なお、入場管理端末１２１は、近接通信及び緊急ビーコン信号等を利用して、携帯端末１１０に判定結果を送信してもよい。例えば、入場管理端末１２１は、判定条件を満たさない場合にのみ、携帯端末１１０に判定結果を送信する。

なお、携帯端末１１０は、出力装置の表示又は入場管理端末１２１からの通知によって入場拒否を示す判定結果を検出した場合、図１４に示す処理を再度実行してもよい。

なお、マイク１２２がグループ電子チケットに関連する音を一度に集音した場合、入場管理端末１２１は、各ユーザに対応する音に対して（処理１）から（処理３）の処理を実行し、（処理４）では、グループ単位で結果を表示する。表示方法としては、再生順番と判定結果とを対応づけた一覧を提示する方法が考えられる。

以上がステップＳ７０２の処理の説明である。

次に、入場管理端末１２１は、入場を許可するか否かを判定する（ステップＳ７０３）。

入場を許可する場合、入場管理端末１２１は、施設１２０へユーザを入場させるために、入場管理機器１２３を制御する（ステップＳ７０４）。その後、入場管理端末１２１は、処理を終了する。例えば、入場管理端末１２１は、施設１２０へ入場するためのゲートを開く。

入場を拒否する場合、入場管理端末１２１は、ユーザに対して入場を拒否する旨を通知する（ステップＳ７０５）。その後、入場管理端末１２１は、処理を終了する。

入場が正常に完了した場合、入場管理端末１２１は、認証サーバ１００に電子チケットの情報を送信してもよい。この場合、認証サーバ１００は、チケット情報管理データベース２２１から電子チケットに対応するエントリを削除し、また、ユーザ認証データベース２２０から電子チケットを使用したユーザに対応するエントリを削除する。

以上で説明した認証システム１０は、安価に構築することができ、また、利便性の高いセキュアなサービスを提供できる。より具体的には、以下のような効果を奏する。

既存の携帯端末が有するハードウェアリソースを及びソフトウェアリソースを利用して実現できる。また、入場可否判定処理では、画像等を認識する専用のデバイスは必要なく、音をデジタル信号に変換するマイク１２２を設置すればよい。したがって、安価に認証システムを構築できる。

事前認証処理は、ユーザが施設１２０へ移動中に移動経路の任意の場所で行われる。そのため、通信リソースが使用される場所及び処理の実行契機を分散することができる。これによって、通信リソースの不足及び認証処理の処理負荷の増大を回避することができる。また、事前認証処理は、自動的に行われるためユーザの利便性を向上させることができる。

音データは画像よりデータサイズが小さいため、認証サーバ１００及び携帯端末１１０間の通信リソースの負荷を低減することができる。また、要素の組合せによって様々な特性の音を生成できるため、偽造の困難性を向上することができる。

入場用音は、事前に受信した認証用データ３２０及び入場用データ３２１だけではなく、会場ビーコン信号を用いて生成されるため、予め、入場用音の音データの偽造等を防止することができる。

判定条件管理情報１２５には、再生される音の任意の特性に関する条件を設定しておくことによって、判定条件を秘匿することができる。これによって、入場用音の生成が困難となる。

本認証システムは、グループ単位の認証にも適用することができる。これによって、処理負荷を削減し、また、ユーザの利便性を向上できる。

なお、入場用音データには、ダミーの周波数を重畳してもよい。これによって、入場用音データの解析を困難にすることができる。この場合、入場管理端末１２１は、ＬＰＦ、ＨＰＦ、及びＢＰＦ等のフィルタを用いて入場用音データからダミーの周波成分を除去した後、音の特性を分析する。なお、マイク１２２に前述のフィルタと同様の機能を具備してもよい。重畳するダミーの周波数は周期的に変動してもよい。また、重畳するダミーの周波数はイベントごとに異なってもよい。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ＨＤＤ及びＳＳＤ等の記憶装置、又は、ＩＣカード、ＳＤカード、及び光ディスク等の記録媒体に置いてもよい。また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。例えば実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

１０ 認証システム
１００ 認証サーバ
１１０ 携帯端末
１２０ 施設
１２１ 入場管理端末
１２２ マイク
１２３ 入場管理機器
１２５ 判定条件管理情報
１３０ ビーコン信号発信装置
１５０ ネットワーク
２００、３００ ＣＰＵ
２０１、３０１ メモリ
２０２、３０２ 記憶装置
２０３、３０３ 通信インタフェース
２１０ ビーコン情報更新モジュール
２１１ 音データ生成モジュール
２１２ 認証モジュール
２２０ ユーザ認証データベース
２２１ チケット情報管理データベース
２２２ 音データ生成情報
３０４ 入力装置
３０５ 出力装置
３０６ ＧＰＳセンサ
３０７ 近距離通信装置
３０８ ビーコン信号検出装置
３０９ ビーコン信号分析装置
３１０ ＯＳ
３１１ 認証アプリケーション
３２０ 認証用データ
３２１ 入場用データ
６００ 音特性管理情報

Claims (12)

1. 認証サーバ、ビーコン信号を発信するビーコン、及びユーザの施設への入場を管理する入場管理端末を備える認証システムであって、
   前記認証システムは、前記ユーザが操作するユーザ端末からのアクセスを受け付け、
   前記認証サーバは、
   前記ユーザによって電子チケットが購入された場合、認証用データを生成して、前記ユーザ端末に前記認証用データを送信し、
   前記ユーザ端末から、前記電子チケットが正当なものであるか否かを判定するための認証処理の実行要求を受信した場合、前記認証処理を実行し、
   前記電子チケットが正当なものであると判定された場合、任意の特性を有する音の音データを生成するための入場用データを生成して、前記ユーザ端末に前記入場用データを送信し、
   前記ユーザ端末は、
   前記ユーザが前記施設に到着する前に、前記認証用データから抽出される情報を含む前記認証処理の実行要求を前記認証サーバに送信し、
   前記ユーザ端末及び前記施設の距離が第一範囲内であり、前記ビーコンから第一ビーコン信号を受信した場合、前記認証用データ、前記入場用データ、及び前記第一ビーコン信号に含まれるビーコン情報に基づいて入場用音データを生成し、
   前記入場用音データに基づいて前記入場管理端末に対して音を再生し、
   前記入場管理端末は、
   前記ユーザ端末によって再生された音の特性を分析し、
   前記分析の結果に基づいて、前記電子チケットに関連付けられるユーザの前記施設への入場を許可するか否かを判定することを特徴とする認証システム。
2. 請求項１に記載の認証システムであって、
   前記第一ビーコン信号に含まれるビーコン情報は、任意のパターンにしたがって変更され、
   前記入場用データは、前記第一ビーコン信号に含まれるビーコン情報のパターン及び音の特性を対応づけた情報であり、
   前記ユーザ端末は、
   前記第一ビーコン信号に含まれるビーコン情報のパターンに基づいて、音の特性を決定し、
   前記決定された音の特性に基づいて、合成用音データを生成し、
   前記認証用データ及び前記合成用音データに基づいて、前記入場用音データを生成することを特徴とする認証システム。
3. 請求項２に記載の認証システムであって、
   前記ユーザ端末は、前記ユーザ端末及び前記施設の距離が前記第一範囲より大きい第二範囲内であり、前記ビーコンから第二ビーコン信号を受信した場合、前記認証処理の実行要求を前記認証サーバに送信することを特徴とする認証システム。
4. 請求項３に記載の認証システムであって、
   前記入場管理端末は、
   前記第一ビーコン信号に含まれるビーコン情報のパターン及び前記音の特性の照合パターンを対応づけた判定条件管理情報を保持し、
   前記分析の結果及び前記判定条件管理情報に基づいて、前記電子チケットに関連付けられるユーザの前記施設への入場を許可するか否かを判定することを特徴とする認証システム。
5. 請求項４に記載の認証システムであって、
   前記入場管理端末には、前記ユーザ端末によって再生された音を集音するマイクが接続されることを特徴とする認証システム。
6. 請求項３に記載の認証システムであって、
   前記認証サーバは、
   任意の特性を有する音のデータ、及び前記ユーザ端末が生成した暗号鍵に基づいて暗号化された前記電子チケットに関する情報を含むタグを前記認証用データとして生成し、
   前記認証用データから抽出された前記タグを含む前記認証処理の実行要求を前記ユーザ端末から受信した場合、前記暗号鍵に基づいて復号化された前記タグに基づいて前記認証処理を実行することを特徴とする認証システム。
7. 認証サーバ、ビーコン信号を発信するビーコン、及びユーザの施設への入場を管理する入場管理端末を備える認証システムにおける認証方法であって、
   前記認証システムは、前記ユーザが操作するユーザ端末からのアクセスを受け付け、
   前記認証方法は、
   前記認証サーバが、前記ユーザによって電子チケットが購入された場合、認証用データを生成して、前記ユーザ端末に前記認証用データを送信する第１のステップと、
   前記ユーザ端末が、前記ユーザが前記施設に到着する前に、前記認証用データから抽出される情報を含む、前記電子チケットが正当なものであるか否かを判定するための認証処理の実行要求を前記認証サーバに送信する第２のステップと、
   前記認証サーバが、前記認証処理の実行要求を受信した場合、前記認証処理を実行する第３のステップと、
   前記認証サーバが、前記電子チケットが正当なものであると判定された場合、任意の特性を有する音の音データを生成するための入場用データを生成して、前記ユーザ端末に前記入場用データを送信する第４のステップと、
   前記ユーザ端末が、前記ユーザ端末及び前記施設の距離が第一範囲内であり、前記ビーコンから第一ビーコン信号を受信した場合、前記認証用データ、前記入場用データ、及び前記第一ビーコン信号に含まれるビーコン情報に基づいて入場用音データを生成する第５のステップと、
   前記ユーザ端末が、前記入場用音データに基づいて前記入場管理端末に対して音を再生する第６のステップと、
   前記入場管理端末が、前記ユーザ端末によって再生された音の特性を分析する第７のステップと、
   前記入場管理端末が、前記分析の結果に基づいて、前記電子チケットに関連付けられるユーザの前記施設への入場を許可するか否かを判定する第８のステップと、を含むことを特徴とする認証方法。
8. 請求項７に記載の認証方法であって、
   前記第一ビーコン信号に含まれるビーコン情報は、任意のパターンにしたがって変更され、
   前記入場用データは、前記第一ビーコン信号に含まれるビーコン情報のパターン及び音の特性を対応づけた情報であり、
   前記第５のステップは、
   前記ユーザ端末が、前記第一ビーコン信号に含まれるビーコン情報のパターンに基づいて、音の特性を決定するステップと、
   前記ユーザ端末が、前記決定された音の特性に基づいて、合成用音データを生成するステップと、
   前記ユーザ端末が、前記認証用データ及び前記合成用音データに基づいて、前記入場用音データを生成するステップと、を含むことを特徴とする認証方法。
9. 請求項８に記載の認証方法であって、
   前記第２のステップでは、前記ユーザ端末が、前記ユーザ端末及び前記施設の距離が前記第一範囲より大きい第二範囲内であり、前記ビーコンから第二ビーコン信号を受信した場合、前記認証処理の実行要求を前記認証サーバに送信することを特徴とする認証方法。
10. 請求項９に記載の認証方法であって、
    前記入場管理端末は、前記第一ビーコン信号に含まれるビーコン情報のパターン及び前記音の特性の照合パターンを対応づけた判定条件管理情報を保持し、
    前記第８のステップは、前記入場管理端末が、前記分析の結果及び前記判定条件管理情報に基づいて、前記電子チケットに関連付けられるユーザの前記施設への入場を許可するか否かを判定するステップを含むことを特徴とする認証方法。
11. 請求項１０に記載の認証方法であって、
    前記入場管理端末には、前記ユーザ端末によって再生された音を集音するマイクが接続されることを特徴とする認証方法。
12. 請求項９に記載の認証方法であって、
    前記第１のステップは、前記認証サーバが、任意の特性を有する音のデータ、及び前記ユーザ端末が生成した暗号鍵に基づいて暗号化された前記電子チケットに関する情報を含むタグを前記認証用データとして生成するステップを含み、
    前記第３のステップは、前記認証サーバが、前記認証用データから抽出された前記タグを含む前記認証処理の実行要求を前記ユーザ端末から受信した場合、前記暗号鍵に基づいて復号化された前記タグに基づいて前記認証処理を実行するステップを含むことを特徴とする認証方法。

Images