JP2018121099A - 認証システム、認証方法及びプログラム - Google Patents

Abstract

【課題】携帯端末ＯＳのＡＰＩを介して電話番号を取得することなく、アプリケーションサイドで電話番号を用いて当該電話番号に紐付く携帯端末を認証することが可能な認証システムを提供する。【解決手段】サーバ装置１００は、携帯端末のアプリから当該携帯端末に固有な端末固有情報を含む認証要求を受信して認証要求ログを生成する認証要求受信部１３０と、ゲートウェイ装置から認証情報を受信して端末固有情報を取得するＳＭＳ情報受信部１５０と、認証情報に含まれるＳＭＳ発信元電話番号が記憶部に存在するか否か、及び認証情報に含まれる端末固有情報に関する認証要求ログが存在するか否かを判定する真正性判定部であって、ＳＭＳ発信元電話番号が記憶部に存在し、認証情報に含まれる端末固有情報に関する認証要求ログが存在する場合、端末固有情報を、記憶部の電話番号に紐付けて格納する真正性判定部１６０とを備える。【選択図】図２

Description

本発明は、認証システム、認証方法及びプログラムに関する。

近年、スマートフォン等の携帯端末が急速に普及している。携帯端末に搭載されるアプリケーション（以下、アプリとも呼ぶ。）において、携帯端末の電話番号を用いる場合、アプリを提供する企業は、不正利用を防ぐために真正なユーザから提供された電話番号であることを確認する必要がある。

一方、ｉＰｈｏｎｅ（登録商標）では、個人情報保護の観点から、現在、アプリがｉＯＳのＡＰＩを介して電話番号を取得することはできない仕様となっている。そのため、アプリが電話番号を取得するために、ユーザに電話番号を入力させる方法が現在多く採られている。しかしながら、単に電話番号を入力させるだけでは、入力された電話番号と、携帯端末の実際の電話番号とが同一であることを保証できないため、不正ユーザによる利用を防ぐことができない。そこでＳＭＳ（ショートメッセージサービス）認証等を用いてセキュリティを強化する対策が行われている（例えば、特許文献１参照）。

また、近年、興行イベントのチケットとして電子チケットが利用されるようになっている。例えば、特許文献２には、ユーザが携帯端末により管理サーバにアクセスしてチケットの購入を希望すると、管理サーバからユーザの携帯端末に電子チケットが送信される技術が開示されている。

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

人気のある興行イベントのチケットは、悪徳業者が意図的に買い占めて高額で販売するダフ屋行為の標的となっている。例えば、既存のＳＭＳ認証を用いて、（１）ユーザにアプリ上で電話番号を入力させ、（２）アプリ提供企業が、入力された電話番号に認証コードを含むＳＭＳメッセージを送信し、（３）ユーザに認証コードをアプリ上で入力させることによってユーザを認証する場合、不正に電話番号を取得した第三者からの不正利用を防ぐことはきる。

しかしながら、（２）で認証コードを取得したユーザ自身から直接、認証コードを取得した第三者は、電話番号に紐付いた携帯電話を保有していないにも関わらず、認証を受けることができてしまう。例えば前述のチケットの例では、人気のある興行イベントのチケットの予約購入に成功した悪徳業者が認証コードを第三者に開示することにより、第三者の携帯端末において認証が成立してしまう。

そこで、本発明は、携帯端末ＯＳのＡＰＩを介して電話番号を取得することなく、アプリケーションサイドで電話番号を用いて当該電話番号に紐付く携帯端末を認証することが可能な認証システム、認証方法及びプログラムを提供することを目的とする。

本発明の一態様に係るゲートウェイ装置及び携帯端末と通信可能に接続されるサーバ装置は、携帯端末の電話番号を記憶する記憶部と、携帯端末のアプリケーションから当該携帯端末に固有な端末固有情報を含む認証要求を受信して、端末固有情報に基づいて認証要求ログを生成する認証要求受信部と、携帯端末からゲートウェイ装置に送信されたＳＭＳメッセージに含まれる認証情報をゲートウェイ装置から受信して、受信した認証情報から端末固有情報を取得するＳＭＳ情報受信部であって、認証情報は、端末固有情報及びＳＭＳ発信元電話番号を含む、ＳＭＳ情報受信部と、ＳＭＳ発信元電話番号が記憶部に存在するか否かを判定する第１の判定と、認証情報に含まれる端末固有情報に関する認証要求ログが存在するか否かを判定する第２の判定とを実行する真正性判定部であって、ＳＭＳ発信元電話番号が記憶部に存在し、認証情報に含まれる端末固有情報に関する認証要求ログが存在する場合、端末固有情報を、記憶部の電話番号に紐付けて格納する、真正性判定部とを備える。

この態様によれば、携帯端末ＯＳのＡＰＩを介して電話番号を取得することなく、アプリケーションサイドで電話番号を用いて当該電話番号に紐付く携帯端末を認証することができる。ＳＭＳ発信元電話番号が記憶部に存在するか否かを判定する第１の判定により、ゲートウェイ装置にＳＭＳメッセージを送信した携帯端末が、記憶部により管理される電話番号に紐付く携帯端末であることが確認できる。また、認証情報に含まれる端末固有情報に関する認証要求ログが存在するか否かを判定する第２の判定により、ゲートウェイ装置に送信されたＳＭＳメッセージが、当該メッセージに含まれる端末固有情報を生成した携帯端末からのものであることが確認できる。

上記サーバ装置において、真正性判定部は、ＳＭＳ発信元電話番号が記憶部に存在しない場合、認証情報に含まれる端末固有情報に関する認証要求ログを削除してもよい。

この態様によれば、記憶部により管理される電話番号に紐付かない携帯端末からの認証要求に由来する認証要求ログを削除することで、より強固な認証システムを構築することができる。

上記サーバ装置において、ＳＭＳ発信元電話番号が記憶部に存在し、認証情報に含まれる端末固有情報に関する認証要求ログが存在する場合、携帯端末においてアプリケーションを起動すると共に、アプリケーションに端末固有情報を用いた処理を実行可能とさせるためのＵＲＬスキームを生成して、当該ＵＲＬスキームを含むＳＭＳメッセージを、ＳＭＳ発信元電話番号に送信する認証応答部をさらに備えてもよい。

この態様によれば、アプリケーションに端末固有情報を用いた処理を実行可能とさせるためのＵＲＬスキームを生成することで、サーバ装置において電話番号と紐付けられた端末固有情報を用いた処理を確実に遂行することができ、より強固な認証システムを構築することができる。

上記サーバ装置において、ＵＲＬスキームは、アプリケーションに、ＳＭＳメッセージで特定される端末固有情報と、アプリケーションが認証要求送信時に生成した端末固有情報とが一致するか否か判定する処理を実行可能とさせてもよい。

この態様によれば、ＵＲＬスキームを用いて、ＳＭＳメッセージに含まれる端末固有情報と、アプリケーションが認証要求送信時に生成した端末固有情報とが一致することを確認することにより、認証が成功した携帯端末上でのみ、ＵＲＬスキームで指定した所定の処理を実行することができ、より強固な認証システムを構築することができる。

上記サーバ装置において、認証要求の受信から一定の期間を経過した認証要求ログを削除する認証要求ログ管理部をさらに備えてもよい。

この態様によれば、認証要求の受信から一定の期間を経過した認証要求ログについては無効であるとして削除することで、より強固な認証システムを構築することができる。

本発明の他の態様に係る方法は、ゲートウェイ装置及び携帯端末と通信可能に接続される１又は複数のコンピュータが、携帯端末の電話番号を記憶部に記憶する工程と、携帯端末のアプリケーションから当該携帯端末に固有な端末固有情報を含む認証要求を受信して、端末固有情報に基づいて認証要求ログを生成する工程と、携帯端末からゲートウェイ装置に送信されたＳＭＳメッセージに含まれる認証情報をゲートウェイ装置から受信して、受信した認証情報から端末固有情報を取得する工程であって、認証情報は、端末固有情報及びＳＭＳ発信元電話番号を含む、工程と、ＳＭＳ発信元電話番号が記憶部に存在するか否かを判定する工程と、認証情報に含まれる端末固有情報に関する認証要求ログが存在するか否かを判定する工程と、ＳＭＳ発信元電話番号が記憶部に存在し、認証情報に含まれる端末固有情報に関する認証要求ログが存在する場合、端末固有情報を、記憶部の電話番号に紐付けて格納する工程とを含む。

本発明の他の態様に係るプログラムは、サーバ装置及びゲートウェイ装置と通信可能に接続される携帯端末に、当該携帯端末に固有な端末固有情報を生成する工程と、ＳＭＳメッセージをゲートウェイ装置に送信するために当該携帯端末のＳＭＳアプリケーションを起動する工程と、端末固有情報を本文に含むＳＭＳメッセージを生成する工程と、ＳＭＳアプリケーションが所定の条件下でＳＭＳメッセージを送信した場合、端末固有情報を含む認証要求をサーバ装置に送信する工程とを実行させる。

上記プログラムにおいて、携帯端末に、端末固有情報を含むＵＲＬスキームが選択されることに応答して、当該プログラムを起動する工程と、ＵＲＬスキームに含まれる端末固有情報を用いた処理を実行する工程とをさらに実行させてもよい。

本発明の他の態様に係る方法は、サーバ装置及びゲートウェイ装置と通信可能に接続される携帯端末が、当該携帯端末に固有な端末固有情報を生成する工程と、ＳＭＳメッセージをゲートウェイ装置に送信するために当該携帯端末のＳＭＳアプリケーションを起動する工程と、端末固有情報を本文に含むＳＭＳメッセージを生成する工程と、ＳＭＳアプリケーションが所定の条件下でＳＭＳメッセージを送信した場合、端末固有情報を含む認証要求をサーバ装置に送信する工程とを含む。

本発明の他の態様に係るサーバ装置及びゲートウェイ装置と通信可能に接続される携帯端末は、当該携帯端末に固有な端末固有情報を生成して、当該端末固有情報を含む認証要求をサーバ装置に送信する認証要求送信部であって、ＳＭＳメッセージをゲートウェイ装置に送信するために当該携帯端末のＳＭＳアプリケーションを起動して、端末固有情報を本文に含むＳＭＳメッセージを生成し、ＳＭＳアプリケーションが所定の条件下でＳＭＳメッセージを送信した場合、認証要求をサーバ装置に送信する認証要求送信部を備える。

なお、本発明において、「部」や「手段」、「装置」、「システム」とは、単に物理的手段を意味するものではなく、その「部」や「手段」、「装置」、「システム」が有する機能をソフトウェアによって実現する場合も含む。また、１つの「部」や「手段」、「装置」、「システム」が有する機能が２つ以上の物理的手段や装置により実現されても、２つ以上の「部」や「手段」、「装置」、「システム」の機能が１つの物理的手段や装置により実現されても良い。

本発明によれば、携帯端末ＯＳのＡＰＩを介して電話番号を取得することなく、アプリケーションサイドで電話番号を用いて当該電話番号に紐付く携帯端末を認証することが可能な認証システム、認証方法及びプログラムを提供することができる。

実施形態に係る認証システムの構成例を示す図である。 実施形態に係るサーバ装置の機能構成の具体例を示す図である。 実施形態に係るチケットアプリの機能構成の具体例を示す図である。 実施形態に係るサーバ装置のチケット購入要求処理の流れの具体例を示すフローチャートである。 実施形態に係る認証システムのチケット受取処理の流れの具体例を示すシーケンス図である。 実施形態に係る認証システムのチケット受取処理の流れの具体例を示すシーケンス図である。 実施形態に係る認証システムのチケット受取処理の流れの具体例を示すシーケンス図である。 実施形態に係るサーバ装置の認証処理の流れの具体例を示すフローチャートである。 実施形態に係るサーバ装置のハードウェア構成の具体例を示す図である。 実施形態に係る携帯端末のハードウェア構成の具体例を示す図である。

添付図面を参照して、本発明の好適な実施形態について説明する。なお、各図において、同一の符号を付したものは、同一又は同様の構成を有する。

図１から図１０は、実施形態を説明するための図である。以下、これらの図を参照しながら、以下の流れに沿って実施形態を説明する。まず「１」で、実施形態に係る認証システムの概要を説明する。続いて「２」で、認証システムに含まれるサーバ装置、ゲートウェイ装置及びチケットアプリの機能構成を説明し、「３」で認証システムの処理の流れを説明する。「４」では、「３」で説明した実施形態とは異なる別の実施形態を説明し、「５」では、認証システムに含まれるサーバ装置及び携帯端末を実装可能なハードウェア構成の具体例を説明する。最後に、「６」で本実施形態に係る効果を説明する。

（１．概要）
図１は、本発明の一実施形態に係る認証システムの構成例を示す。認証システム１０は、サーバ装置１００及びゲートウェイ装置２００を備える。サーバ装置１００は、インターネット等の通信ネットワークＮを介して、ゲートウェイ装置２００及び複数のユーザＵ（Ａ〜Ｃ）が保有する携帯端末３００（ａ〜ｃ）と通信可能に接続されている。サーバ装置１００は、ゲートウェイ装置２００と協働して、携帯端末３００を介して受け付けられる認証要求を処理する。

図１においては、認証サービスを提供するサービス事業者により管理されるサーバ装置１００、ゲートウェイ装置２００がそれぞれ１つのみ図示されているが、これらの装置の数は特に限定されない。また、携帯端末３００は例示のため３つのみ図示されているが、これらの端末の数も特に限定されない。本発明の実施形態は、電話番号を用いる様々な認証処理に適用することができ、そのサービス内容は特に限定されないが、以下の説明においては、電子チケット受け取りの際に実行される認証処理を例とする。

ユーザＵは事前にチケットを購入申請し、携帯端末３００のチケットアプリ４００を用いて、当選したチケットに係るチケットデータをサーバ装置１００からダウンロードすることができる。ユーザＵは、ダウンロードした電子チケットを表示した表示画面を会場の係員に提示することで、紙チケットと同様に会場に入場することができる。

チケットデータのダウンロードに際し、チケットアプリ４００は、ユーザＵからチケットデータ受け取り指示を受けると、認証システム１０に対して認証要求を送信する。

認証システム１０は、サーバ装置１００においてチケットを受け取る権利を有する携帯端末３００の電話番号を管理している。認証システム１０が実行する真正性判定では、管理されている電話番号に紐付いた携帯端末３００ａからの認証要求は成功するが、一方、管理されている電話番号に紐付いていない携帯端末３００ｃからの認証要求は失敗する。さらに、認証システム１０が実行する真正性判定では、管理されている電話番号に紐付いた携帯端末３００ｂからの認証要求であっても、管理されていない電話番号に紐付いた携帯端末３００ｃを保有する不正ユーザＵＣと共謀して不正ユーザＵＢが不正操作を行った場合、当該携帯端末３００ｂからの認証要求は失敗する。

サーバ装置１００は、チケットを受け取る権利を有する携帯端末３００の電話番号を含むチケット管理情報１９１を備える。チケット管理情報１９１には、既存のチケット管理サーバが複数のユーザから携帯端末３００を介してチケットの購入申請を受け付けた後、所定の時期に行った抽選に当選した購入申請者に関連する電話番号が格納されている。ここで、当選した購入申請者に関連する電話番号は、購入申請者自身の電話番号だけでなく、購入申請者が同伴する同伴者の電話番号も含むことができる。

サーバ装置１００は、前述したように、ゲートウェイ装置２００と協働して、携帯端末３００を介して受け付けられる認証要求を処理する。認証要求において、携帯端末３００からゲートウェイ装置２００にＳＭＳメッセージを送信することで、チケットアプリ４００が携帯端末ＯＳのＡＰＩを介して電話番号を取得することなく、サーバ装置１００はＳＭＳ発信元電話番号として携帯端末３００の電話番号を取得することができる。一方、ＳＭＳメッセージの本文に含まれる情報は、ユーザＵによって書き換えられる可能性がある。そのため、チケットアプリ４００からサーバ装置１００に、ＳＭＳメッセージの本文に含まれる情報と同一の書き換え不能な情報を送信することで、サーバ１００はユーザＵによる不正操作を判定することができる。

チケット管理情報１９１に管理されている電話番号に紐付く携帯端末３００ａからの認証要求はサーバ装置１００の真正性判定に成功し、ユーザＵＡはチケットアプリ４００を用いて、当選したチケットに係るチケットデータをサーバ装置１００からダウンロードすることができる。一方、チケット管理情報１９１に管理されていない電話番号に紐付く携帯端末３００ｃからの認証要求はサーバ装置１００の真正性判定に失敗するので、ユーザＵＣは電子チケットを受け取ることはできない。さらには、チケット管理情報１９１に管理されている電話番号に紐付く携帯端末３００ｂからの認証要求であっても、不正ユーザＵＢが不正操作を行った場合、認証要求はサーバ装置１００の真正性判定に失敗するので、電子チケットを受け取ることはできない。

（２．機能構成）
以下、図２及び図３を参照しながら、本実施形態に係るサーバ装置１００、ゲートウェイ装置２００及び携帯端末３００にインストールされるチケットアプリ４００の機能構成を説明する。

（２．１ サーバ装置１００の機能構成）
まず、図２を参照しながら、サーバ装置１００の機能構成を説明する。図２は、サーバ装置１００の機能構成の具体例を示す機能ブロック図である。サーバ装置１００は、ウェブサイト提供部１１０、抽選部１２０、認証要求受信部１３０、認証要求ログ管理部１４０、ＳＭＳ情報受信部１５０、真正性判定部１６０、認証応答部１７０、チケットデータ送信部１８０、及びＤＢ１９０を含む。なお、サーバ装置１００の機能構成は、必ずしも１台のサーバにより実現する必要はなく、複数台のサーバにより実現することも考えられる。例えば、本実施形態におけるサーバ装置１００は、チケット管理システムの機能を兼ね備えているが、これに限るものではなく、サーバ装置１００に対してチケット管理機能を提供する別個のチケット管理サーバ等が構成されていてもよい。

ウェブサイト提供部１１０は、電子チケットサービスを提供するためのウェブサイトを、例えばインターネットであるネットワークＮ上で提供する。当該ウェブサイトは、販売しているチケット等の各種情報を提供したり、チケットを実際に販売したりすることができる。このためにウェブサイト提供部１１０は、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）等で記述されたウェブページを、ユーザＵの使用する携帯端末３００へ送信すると共に、ユーザＵによる入力結果等を、携帯端末３００から受信する。ウェブサイト提供部１１０は、ユーザ画面送信部１１１及びチケット購入申請受信部１１３を含む。

ユーザ画面送信部１１１は、ユーザＵからの入力等に応答して、対応するウェブページを作成して携帯端末３００に送信する。具体的には、例えば販売対象のチケットの一覧画面、チケットの購入を申請する申請画面等に係る各種ウェブページを、ユーザ画面送信部１１１は携帯端末３００のブラウザ３２０へ送信する。

チケット購入申請受信部１１３は、ユーザＵの携帯端末３００から、ユーザＵの選択したチケットの購入申請を受け付ける。前述したように、購入を申請したユーザＵがチケットの購入権を得た（例えばチケットに当選した）場合に当該チケットを電子チケットとして受け取る携帯端末の電話番号の入力も、チケット購入申請受信部１１３は受け付ける。チケット購入申請受信部１１３が受け付けた各種情報は、チケット購入申請情報１９３としてＤＢ１９０に格納される。

抽選部１２０は、販売されている各々のチケットに対して、いずれの購入申請者に購入権を与えるかを決める。抽選部１２０は、抽選に当選した購入申請者に関連する電話番号を、チケット管理情報１９１においてチケットに紐付けて格納する。

認証要求受信部１３０は、携帯端末３００のチケットアプリ４００から認証要求を受信して、認証要求ログを生成する。認証要求には、チケットアプリ４００が携帯端末３００に固有の情報（以下、端末固有情報と呼ぶ。）及びタイムスタンプ（年／月／日／時／分／秒）を用いて生成した、直接ワンタイム暗号化データが含まれる。本実施形態では、認証システム１０は、端末固有情報として、携帯端末３００を一意に識別する携帯端末ＩＤを用いるが、携帯端末３００から取得可能な、携帯端末３００に固有の任意の情報を用いることができる。なお、携帯端末ＩＤとして、例えば携帯端末３００にインストールされたチケットアプリ４００に個別に割り当てた識別情報を用いることができる。

ここで、本明細書に記載の端末固有情報には、携帯端末ＩＤ等の携帯端末３００に固有の任意の情報のみならず、例えば、携帯端末ＩＤ及びタイムスタンプを用いて生成したワンタイム暗号化データ等、携帯端末３００に固有の情報に基づく情報が含まれる。

ここで、本明細書に記載のワンタイム暗号化データは、一定期間内において一度だけ有効な暗号化データである。また、本明細書では、チケットアプリ４００が生成したワンタイム暗号化データのうち、認証要求として携帯端末３００からサーバ装置１００に直接送信されるものを「直接ワンタイム暗号化データ」、後述するＳＭＳメッセージに含まれる認証情報として携帯端末３００からゲートウェイ装置２００を経由してサーバ装置１００に送信されるものを「経由ワンタイム暗号化データ」と呼ぶ。本明細書では説明の便宜上、異なる名称を付して呼ぶが、ＳＭＳメッセージの本文に含まれるワンタイム暗号化データを故意に書き換えない限り、直接ワンタイム暗号化データと経由ワンタイム暗号化データとは同一の内容である。

認証要求受信部１３０は、認証要求に含まれる直接ワンタイム暗号化データを復号化して、端末固有情報を取得する。そして、認証要求受信部１３０は、取得した端末固有情報と受信時刻とを、認証要求ログとして認証要求ログ情報１９５に格納する。本実施形態では、認証要求受信部１３０は、直接ワンタイム暗号化データから携帯端末ＩＤを取得して、取得した携帯端末ＩＤと受信時刻とを認証要求ログとして格納する。

認証要求ログ管理部１４０は、受信から一定の期間を経過した認証要求ログを、認証要求ログ情報１９５から削除する。本実施形態では、受信から１０分経過した認証要求ログを削除するものとして説明するが、認証要求ログを削除する時間として他の任意の期間を設定することができる。このように、認証要求の受信から一定の期間を経過した認証要求ログについては無効であるとして削除することで、より強固な認証システムを構築することができる。

ＳＭＳ情報受信部１５０は、携帯端末３００からゲートウェイ装置２００に送信されたＳＭＳメッセージに含まれる認証情報をゲートウェイ装置２００から受信する。ゲートウェイ装置２００から受信する認証情報には、チケットアプリ４００が端末固有情報及びタイムスタンプを用いて生成した経由ワンタイム暗号化データ、及びＳＭＳ発信元電話番号が含まれる。ＳＭＳ情報受信部１５０は、認証情報に含まれる経由ワンタイム暗号化データを復号化して、端末固有情報を取得する。本実施形態では、ＳＭＳ情報受信部１５０は、経由ワンタイム暗号化データから携帯端末ＩＤを取得する。

真正性判定部１６０は、ＳＭＳ情報受信部１５０が受信した認証情報を用いて真正性判定を行う。まず、真正性判定部１６０は、第１の真正性判定として、受信したＳＭＳ発信元電話番号がチケット管理情報１９１に存在するか否かを判定する。チケット管理情報１９１において、受信したＳＭＳ発信元電話番号が存在する場合、ゲートウェイ装置２００にＳＭＳメッセージを送信した携帯端末３００の電話番号が、チケットを受け取る権利を有することが確認される。

次に、真正性判定部１６０は、第２の真正性判定として、認証要求ログ情報１９５を参照して、経由ワンタイム暗号化データから得られた端末固有情報に関する認証要求ログが存在するか否かを判定する。本実施形態では、真正性判定部１６０は、認証要求ログ情報１９５において、経由ワンタイム暗号化データから得られた携帯端末ＩＤに関する認証要求ログが存在するか否かを判定する。

直接ワンタイム暗号化データから得られた端末固有情報を含む認証要求ログ情報１９５において、経由ワンタイム暗号化データから得られた端末固有情報に関する認証要求ログが存在する場合、ゲートウェイ装置２００に送信されたＳＭＳメッセージが、ワンタイム暗号化データを生成したチケットアプリ４００がインストールされた携帯端末３００からのものであることが確認される。すなわち、ＳＭＳメッセージのＳＭＳ発信元電話番号と、ＳＭＳメッセージに含まれるワンタイム暗号化データから得られた端末固有情報とが関連付けられる。

第１の真正性判定でチケット管理情報１９１において、受信したＳＭＳ発信元電話番号が存在し、第２の真正性判定で認証要求ログ情報１９５において、経由ワンタイム暗号化データから得られた端末固有情報に関する認証要求ログが存在する場合、真正性判定部１６０は、チケット管理情報１９１において、第２の真正性判定を経た端末固有情報を、第１の真正性判定を経た電話番号に紐付けて格納する。

一方、第１の真正性判定でチケット管理情報１９１において、受信したＳＭＳ発信元電話番号が存在しないにも関わらず、第２の真正性判定で認証要求ログ情報１９５において、経由ワンタイム暗号化データから得られた端末固有情報に関する認証要求ログが存在する場合、真正性判定部１６０は、経由ワンタイム暗号化データから得られた端末固有情報に関する認証要求ログを、不正ユーザＵからの認証要求に由来するものとして削除する。

認証応答部１７０は、経由ワンタイム暗号化データから得られた端末固有情報及びタイムスタンプを共通鍵で暗号化して、ワンタイム暗号化データを生成する。さらに、認証応答部１７０は、携帯端末３００においてチケットアプリ４００を起動すると共に、チケットアプリ４００に、認証応答部１７０が生成したワンタイム暗号化データを用いた処理を実行可能とさせるためのＵＲＬスキームを生成して、当該ＵＲＬスキームを含むＳＭＳメッセージを、ＳＭＳ発信元電話番号に送信する。

本実施形態では、ＵＲＬスキームは、チケットアプリ４００に、ＳＭＳメッセージで特定されるワンタイム暗号化データと、認証要求送信時に生成したワンタイム暗号化データとが一致するか否か判定する処理を実行可能とさせる。両ワンタイム暗号化データが一致する場合、チケットを受け取る権利を有する電話番号と紐付く携帯端末３００からの認証要求であることが認証され、チケットアプリ４００は、チケットデータ受け取り処理に遷移する。

チケットデータ送信部１８０は、携帯端末３００からのチケットデータ送信要求に応答して、チケットデータを携帯端末３００に送信する。チケットデータ送信要求には、一連の認証処理において真正性が確認された端末固有情報が含まれる。チケットデータ送信部１８０は、チケット管理情報１９１を参照して、チケット受取要求に含まれる端末固有情報に紐付いたチケットデータを携帯端末３００に送信する。本実施形態では、チケットデータ送信部１８０は、携帯端末ＩＤを含むチケットデータ送信要求を受信して、受信した携帯端末ＩＤに紐付いたチケットデータを携帯端末３００に送信する。

ＤＢ１９０は、チケット管理情報１９１、チケット購入申請情報１９３及び認証要求ログ情報１９５を管理する。

チケット管理情報１９１には、イベント主催者／サービス事業者が発行する各チケットを、例えばイベント毎に管理するためのデータが格納されている。チケット管理情報１９１において、チケットを電話番号に紐付けて管理することにより、チケットを受け取る権利を有するユーザＵの携帯端末３００を確認することが可能である。この他、一実施形態では、チケット管理情報１９１には、チケットに関する各種情報である、公演名、会場名、チケット種別、使用者の属性等に基づくチケット券種、各種期限、端末固有情報等が管理されていることが望ましい。

チケット購入申請情報１９３には、チケット購入を申請したチケット及びチケット購入申請者に係る各種情報が格納されている。一実施形態では、チケット購入申請情報１９３には、チケット購入申請者及び同伴者が電子チケットを受け取る際に用いる携帯端末３００の電話番号も含むことができる。

認証要求ログ情報１９５には、前述したように、認証要求に含まれる直接ワンタイム暗号化データから得られた端末固有情報と受信時刻とが格納されている。本実施形態では、前述したように、端末固有情報として携帯端末ＩＤが格納されている。

（２．２ ゲートウェイ装置２００の機能構成）
次に、ゲートウェイ装置の機能構成を説明する。ゲートウェイ装置２００は、認証ＳＭＳ受信部を含む。

認証ＳＭＳ受信部は、携帯端末３００からＳＭＳメッセージを受信して、受信したＳＭＳメッセージに含まれるワンタイム暗号化データ及びＳＭＳ送信元電話番号を認証情報としてサーバ装置１００に送信する。

（２．３ チケットアプリ４００の機能構成）
次に、図３を参照しながら、携帯端末３００にインストールされるチケットアプリ４００の機能構成を説明する。図３は、チケットアプリ４００の機能構成の具体例を示す機能ブロック図である。チケットアプリ４００は、認証要求送信部４１０、ワンタイム暗号化データ管理部４２０、ＵＲＬスキーム実行部４３０、チケット取得部４４０、ＵＩ表示部４５０及びＤＢ４６０を含む。

認証要求送信部４１０は、サーバ装置１００に認証要求を送信するために、ワンタイム暗号化データを生成する。前述したように、認証要求には、チケットアプリ４００が端末固有情報及びタイムスタンプを用いて生成した、ワンタイム暗号化データが含まれる。本実施形態では、認証要求送信部４１０は、端末固有情報として、携帯端末３００を一意に識別する携帯端末ＩＤを用い、当該携帯端末ＩＤ及びタイムスタンプを共通鍵で暗号化して、ワンタイム暗号化データを生成する。

続いて認証要求送信部４１０は、ＳＭＳメッセージをゲートウェイ装置２００に送信するために携帯端末３００のＳＭＳアプリ３３０を起動して、生成したワンタイム暗号化データを本文に含むＳＭＳメッセージを生成する。さらに認証要求送信部４１０は、ユーザＵからの送信指示に応答してＳＭＳアプリ３３０が正常にＳＭＳメッセージを送信した場合、生成したワンタイム暗号化データを含む認証要求をサーバ装置１００に送信し、生成したワンタイム暗号化データをＤＢ４６０にワンタイム暗号化データ４６１として格納する。

携帯端末３００からＳＭＳメッセージを送信することで、チケットアプリ４００が携帯端末ＯＳのＡＰＩを介して電話番号を取得することなく、サーバ装置１００はＳＭＳ発信元電話番号として携帯端末３００の電話番号を取得することができる。一方、ＳＭＳメッセージの本文に含まれる情報は、ユーザＵによって書き換えられる可能性がある。そのため、チケットアプリ４００からサーバ装置１００に、ＳＭＳメッセージの本文に含まれる情報と同一の書き換え不能な情報を送信することで、サーバ１００はユーザＵによる不正操作を判定することができる。

本実施形態では、認証要求送信部４１０によるワンタイム暗号化データ生成後、他のアプリが有効化（チケットアプリ４００から他のアプリへのタスクの切り替え）されることなく、所定の時間（例えば、２０秒等）以内にＳＭＳメッセージの送信が完了した場合に、認証要求送信部４１０は、正常にＳＭＳメッセージが送信されたと判定する。すなわち、認証要求送信部４１０はワンタイム暗号化データを含む認証要求をサーバ装置１００に送信する。

ワンタイム暗号化データ管理部４２０は、認証要求送信部４１０によるワンタイム暗号化データ生成から一定の期間を経過したワンタイム暗号化データ４６１を、ＤＢ４６０から削除する。本実施形態では、生成から１０分経過したワンタイム暗号化データを削除するものとして説明するが、ワンタイム暗号化データを削除する時間として他の任意の期間を設定することができる。このように、生成から一定の期間を経過したワンタイム暗号化データについては無効であるとして削除することで、より強固な認証システムを構築することができる。

ＵＲＬスキーム実行部４３０は、ＳＭＳメッセージに含まれるＵＲＬスキームをユーザが選択することに応答して、ＵＲＬスキームに記述されているワンタイム暗号化データと、ＤＢ４６０に格納されているワンタイム暗号化データ４６１とが一致するか否か判定する。また、ＵＲＬスキーム実行部４３０は、判定の後、ＤＢ４６０からワンタイム暗号化データ４６１を削除する。

ＳＭＳメッセージで特定されるワンタイム暗号化データと認証要求送信時に生成したワンタイム暗号化データとが一致する場合、サーバ装置１００において電話番号と紐付けられた端末固有情報を有する携帯端末上でＵＲＬスキームが実行されていることが確認される。よって、ＳＭＳメッセージに含まれるＵＲＬスキームをコピーし、不正に利用されることを防ぐことができる。

チケット取得部４４０は、ＵＲＬスキーム実行部４３０によって両ワンタイム暗号化データが一致すると判定される場合に、サーバ装置１００にチケットデータ送信要求を送信し、ユーザＵが受取可能なチケットデータをサーバ装置１００から受信する。チケットデータ送信要求には、一連の認証処理において真正性が確認された端末固有情報が含まれる。受信したチケットデータは、チケット情報４６３としてＤＢ４６０に格納される。

ＵＩ表示部４５０は、ユーザＵに対して、認証要求を送信するためのチケット受け取り画面、取得したチケットデータを閲覧可能なチケットデータ表示画面等を表示する。

ＤＢ４６０は、ワンタイム暗号化データ４６１及びチケット情報４６３を管理する。

ワンタイム暗号化データ４６１は、端末固有情報を共通鍵で暗号化したデータである。本実施形態では、前述したように、ワンタイム暗号化データは、端末固有情報として携帯端末ＩＤを用い、当該携帯端末ＩＤ及びタイムスタンプを共通鍵で暗号化することで生成される。

チケット情報４６３は、ユーザＵが使用可能な電子チケットに関する各種情報である。チケット情報４８３には、例えば、公演名、会場名、チケット種別、使用対象者の属性等に基づく券種、電子チケットとして表示する画像や、有効期間等の情報を含むことができる。前述したように、チケット情報４８３はチケット取得部４４０がサーバ装置１００から取得する。

（３．処理の流れ）
以下、認証システム１０の処理の流れを、図４から図８を参照しながら説明する。まず、図４を用いて、サーバ装置１００が、チケット管理情報１９１において、抽選に当選した購入申請者に関連する電話番号をチケットに紐付けて格納する処理について説明する。次に、図５を用いて、サーバ装置１００がゲートウェイ装置２００と協働して、真正ユーザＵＡからの認証要求を処理するフローについて説明する。

次に、図６及び図７を用いて、サーバ装置１００がゲートウェイ装置２００と協働して、不正ユーザＵからの認証要求を処理するフローについて説明する。図６及び図７はいずれも、ダフ屋である不正ユーザＵＢとダフ屋からチケットの購入を望む不正ユーザＵＣとが共謀して、ＳＭＳメッセージの本文の書き換えを行って認証要求を行う例である。図６で、ダフ屋である不正ユーザＵＢのみが認証要求を送信する例を示し、図７は、ダフ屋である不正ユーザＵＢ及びダフ屋からチケットの購入を望む不正ユーザＵＣがいずれも認証要求を送信する例を示す。最後に、図８を用いて、サーバ装置１００の認証処理の流れを説明する。

なお、後述の各処理ステップは、処理内容に矛盾を生じない範囲で、任意に順番を変更して若しくは並列に実行することができ、また、各処理ステップ間に他のステップを追加しても良い。更に、便宜上１つのステップとして記載されているステップは複数のステップに分けて実行することもでき、便宜上複数に分けて記載されているステップを１ステップとして実行することもできる。

（３．１ 電子チケットの購入申請時の処理）
サーバ装置１００が、チケット管理情報１９１において、抽選に当選した購入申請者に関連する電話番号をチケットに紐付けて格納する処理の流れを、図４を参照しながら説明する。図４は、電子チケットの購入要求に係るサーバ装置１００の処理の流れを示すフローチャートである。なお、ユーザＵが電子チケット購入申請の際に使用するブラウザ１１０は、必ずしもチケットアプリ３００がインストールされた携帯端末３００上である必要はない。例えば、パーソナルコンピュータ（ＰＣ）のブラウザを用いて、購入申請を行うこともできる。

ユーザＵが携帯端末３００のブラウザ３２０を用いてサーバ装置１００の提供するチケットサービスサイトへとアクセスすると（Ｓ４０１）、サーバ装置１００のウェブサイト提供部１１０は、アクセスを受けたＵＲＬに応じたウェブページを携帯端末３００へと送信する（Ｓ４０３）。

ブラウザ３２０でのユーザＵの操作に応じて、携帯端末３００から購入可能チケットの閲覧要求がサーバ装置１００に送信されると（Ｓ４０５）、サーバ装置１００のユーザ画面送信部１１１は、購入可能なチケットの一覧画面を携帯端末３００へと送信する（Ｓ４０７）。本実施形態では、一覧画面には、チケット管理情報１９１から抽出された購入可能なチケットの情報が含まれる。

ブラウザ３２０でのユーザＵの操作に応じて、携帯端末３００からチケットの購入要求が送信されると（Ｓ４０９）、サーバ装置１００のチケット購入申請受信部１１３が購入要求を受信して、ユーザ画面送信部１１１が、購入申請情報の登録画面を携帯端末３００へと送信する（Ｓ４１１）。本実施形態では、登録画面には、前述したように、購入申請者のチケット受領端末に係る電話番号、及び、同伴者のチケットも購入する場合には、同伴者のチケット受領端末に係る電話番号が含まれる。

ブラウザ３２０でのユーザＵの操作に応じて、携帯端末３００から購入申請情報が送信されると（Ｓ４１３）、チケット購入申請受信部１１３は、受信した購入申請情報をチケット購入申請情報１９３としてＤＢ１９０に登録する（Ｓ４１５）。

このようにして、１以上のユーザＵからチケットの購入申請を受けた後、所定の抽選時期が到来すると（Ｓ４１７）、サーバ装置１００の抽選部１２０は抽選を行う（Ｓ４１９）。抽選を行った後、抽選部１２０は、抽選に当選した購入申請者に関連する電話番号を、チケット管理情報１９１においてチケットに紐付けて格納する（Ｓ４２１）。最後に、サーバ装置１００は、例えば購入申請情報として受信したメールアドレスを用いて、購入申請者であるユーザＵに抽選結果を通知するメールを送信する（Ｓ４２３）。

（３．２ 真正ユーザによる電子チケットの受取時の処理）
真正ユーザＵＡによる電子チケットの受取に係る処理の流れを、図５を参照しながら説明する。本実施例では、サーバ装置１００のチケット管理情報１９１において真正ユーザＵＡが保有する携帯端末３００ａの電話番号が登録されている。図５は、電子チケットの受取に係る認証システム１０の処理の流れを示すシーケンス図である。

真正ユーザＵＡが携帯端末３００ａのチケットアプリ４００を起動すると、チケットアプリ４００のＵＩ表示部４５０は、認証要求を送信するためのチケット受け取り画面を表示する（Ｓ５０１）。チケット受取画面において、真正ユーザＵＡが、例えばチケット受け取りボタンを押下することにより、チケットアプリ４００の認証要求送信部４１０は、チケットデータ取得のための処理を開始する。まず、認証要求送信部４１０は、携帯端末３００ａから携帯端末ＩＤを取得して（Ｓ５０３）、当該携帯端末ＩＤ及びタイムスタンプを共通鍵で暗号化して、ワンタイム暗号化データを生成する（Ｓ５０５）。

次に、認証要求送信部４１０は、ワンタイム暗号化データを含むＳＭＳメッセージをゲートウェイ装置２００に送信するために携帯端末３００のＳＭＳアプリ３３０を起動して（Ｓ５０７）、生成したワンタイム暗号化データを本文に含むＳＭＳメッセージを生成する。ユーザＵからの送信指示に応答して、ＳＭＳアプリ３３０が正常にＳＭＳメッセージを送信した場合（Ｓ５０９）、認証要求送信部４１０は、生成したワンタイム暗号化データを含む認証要求をサーバ装置１００に送信し（Ｓ５１１）、生成したワンタイム暗号化データをＤＢ４６０にワンタイム暗号化データ４６１として格納する（Ｓ５１３）。

本実施形態では、認証要求送信部４１０によるワンタイム暗号化データ生成後、他のアプリが有効化（チケットアプリ４００から他のアプリへのタスクの切り替え）されることなく、所定の時間（例えば、２０秒等）以内にＳＭＳメッセージの送信が完了した場合に、認証要求送信部４１０は、正常にＳＭＳメッセージが送信されたと判定する。すなわち、認証要求送信部４１０はワンタイム暗号化データを含む認証要求をサーバ装置１００に送信する。

携帯端末３００ａから認証要求を受信すると、サーバ装置１００の認証要求受信部１３０は、認証要求に含まれる直接ワンタイム暗号化データを復号化して、携帯端末３００ａの携帯端末ＩＤを取得する（Ｓ５１５）。さらに、認証要求受信部１３０は、取得した携帯端末ＩＤを、受信時刻の情報と共に認証要求ログとして認証要求ログ情報１９５に格納する（Ｓ５１７）。

一方、ゲートウェイ装置２００が携帯端末３００ａからＳＭＳメッセージを受信すると、ゲートウェイ装置２００の認証ＳＭＳ受信部は、受信したＳＭＳメッセージに含まれるワンタイム暗号化データ及びＳＭＳ送信元電話番号を認証情報としてサーバ装置１００に送信する（Ｓ５１９）。

サーバ装置１００のＳＭＳ情報受信部１５０がゲートウェイ装置２００から携帯端末３００ａの認証情報を受信すると、認証情報に含まれる経由ワンタイム暗号化データを復号化して、携帯端末ＩＤを取得する（Ｓ５２１）。本実施形態では、ゲートウェイ装置２００から受信する認証情報には、チケットアプリ４００が携帯端末３００ａの携帯端末ＩＤ及びタイムスタンプを用いて生成した経由ワンタイム暗号化データ、及びＳＭＳ発信元電話番号として携帯端末３００ａの電話番号が含まれる。

次に、真正性判定部１６０は、ＳＭＳ情報受信部１５０が受信した認証情報を用いて真正性判定を行う。まず、真正性判定部１６０は、第１の真正性判定として、受信したＳＭＳ発信元電話番号がチケット管理情報１９１に存在するか否かを判定する（Ｓ５２３）。本実施例では、携帯端末３００ａの電話番号はチケット管理情報１９１において登録されているので、第１の真正性判定は成功する。

次に、真正性判定部１６０は、第２の真正性判定として、Ｓ５２１で経由ワンタイム暗号化データから得られた携帯端末ＩＤに関する認証要求ログが認証要求ログ情報１９５に存在するか否かを判定する（Ｓ５２５）。受信したＳＭＳ発信元電話番号がチケット管理情報１９１に存在し、かつ、経由ワンタイム暗号化データから得られた携帯端末ＩＤに関する認証要求ログが存在する場合、真正性判定部１６０は、チケット管理情報１９１において、第２の真正性判定を経た携帯端末ＩＤを、第１の真正性判定を経た電話番号に紐付けて格納する（Ｓ５２７）。

本実施例では、経由ワンタイム暗号化データを復号化して得られる携帯端末３００ａの携帯端末ＩＤに関する認証ログは、Ｓ５１７で認証要求ログ情報１９５に格納されているので、第２の真正性判定にも成功し、Ｓ５２７で携帯端末ＩＤと電話番号とが紐付けられる。

携帯端末ＩＤと電話番号とが紐付けられると、サーバ装置１００の認証応答部１７０は、経由ワンタイム暗号化データから得られた端末固有情報及びタイムスタンプを共通鍵で暗号化して、ワンタイム暗号化データを生成する（Ｓ５２９）。さらに、認証応答部１７０は、携帯端末３００においてチケットアプリ４００を起動すると共に、チケットアプリ４００にワンタイム暗号化データを用いた処理を実行可能とさせるためのＵＲＬスキームを生成して（Ｓ５３１）、当該ＵＲＬスキームを含むＳＭＳメッセージを、ＳＭＳ発信元電話番号に送信する（Ｓ５３３）。

サーバ装置１００からＳＭＳメッセージを受信すると、ユーザ操作に応じて、ＳＭＳアプリ３３０は受信したＳＭＳメッセージを表示する（Ｓ５３５）。ＳＭＳメッセージに含まれるＵＲＬスキームをユーザが選択すると、チケットアプリ４００が起動され、チケットアプリ４００のＵＲＬスキーム実行部４３０が、ＳＭＳメッセージで特定されるワンタイム暗号化データと、ＤＢ４６０に格納されるワンタイム暗号化データ４６１とが一致するか否か判定する（Ｓ５３７）。また、ＵＲＬスキーム実行部４３０は、判定の後、ＤＢ４６０からワンタイム暗号化データ４６１を削除する。

ＵＲＬスキーム実行部４３０によって両ワンタイム暗号化データが一致すると判定される場合、チケットアプリ４００のチケット取得部４４０は、サーバ装置１００にチケットデータ送信要求を送信する（Ｓ５３９）。チケットデータ送信要求には、一連の認証処理において真正性が確認された携帯端末３００ａの携帯端末ＩＤが含まれる。

携帯端末３００ａからチケットデータ送信要求を受信すると、サーバ装置１００のチケットデータ送信部１８０は、チケット管理情報１９１を参照して、チケット受取要求に含まれる携帯端末ＩＤに紐付いたチケットデータを携帯端末３００ａに送信する（Ｓ５４１）。チケット取得部４４０は、受信したチケットデータをチケット情報４６３としてＤＢ４６０に格納する（Ｓ５４３）。

（３．３ 不正ユーザによる電子チケットの受取時の処理１）
次に、不正ユーザＵＢ及び不正ユーザＵＣによる電子チケットの受取に係る第１の処理の流れを、図６を参照しながら説明する。本実施例では、サーバ装置１００のチケット管理情報１９１においてダフ屋である不正ユーザＵＢが保有する携帯端末３００ｂの電話番号が登録されており、不正ユーザＵＣは、ダフ屋である不正ユーザＵＢからチケットの購入を望む不正ユーザである。図６は、電子チケットの受取に係る認証システム１０の処理の流れを示すシーケンス図である。

図６のＳ５０１からＳ５０７は、図５のＳ５０１からＳ５０７と同じ処理であるので、これらの処理の詳細な説明は省略する。ただし、図６では、ユーザＵＡが保有する携帯端末３００ａに代えて、不正ユーザＵＣが保有する携帯端末３００ｃで処理が実行される。

Ｓ５０７においてＳＭＳアプリ３３０が起動された後、不正ユーザＵＣは、ＳＭＳメッセージを送信することなく、ＳＭＳメッセージに含まれるワンタイム暗号化データをコピーして、他のメールアプリ等を用いて不正ユーザＵＢに送信する（Ｓ６０１）。認証ＳＭＳ送信部４２０が正常にＳＭＳメッセージを送信していないので、認証要求送信部４１０は、生成したワンタイム暗号化データを含む認証要求をサーバ装置１００に送信することなく、及びＤＢ４６０にワンタイム暗号化データ４６１を格納することもない。

不正ユーザＵＢは、不正ユーザＵＣから携帯端末３００ｃの携帯端末ＩＤに関連するワンタイム暗号化データを受信する。その後、不正ユーザＵＢの携帯端末３００ｂで、図５のＳ５０１からＳ５０７と同じＳ６０３からＳ６０９の処理が実行され、Ｓ６０９においてＳＭＳアプリ３３０が起動される。

ここで、不正ユーザＵＢは、Ｓ６０９において表示されたＳＭＳメッセージの本文を、不正ユーザＵＣから受信した携帯端末３００ｃの携帯端末ＩＤに関連するワンタイム暗号化データに書き換えてＳＭＳメッセージを送信する（Ｓ６１１）。不正ユーザＵＢからの送信指示に応答して、ＳＭＳアプリ３３０が正常にＳＭＳメッセージを送信したので、認証要求送信部４１０は、生成した（携帯端末３００ｂの携帯端末ＩＤに関連する）ワンタイム暗号化データを含む認証要求をサーバ装置１００に送信し（Ｓ６１３）、ＤＢ４６０に（携帯端末３００ｂの携帯端末ＩＤに関連する）ワンタイム暗号化データ４６１として格納する（Ｓ６１５）。

携帯端末３００ｂから認証要求を受信すると、サーバ装置１００の認証要求受信部１３０は、認証要求に含まれる直接ワンタイム暗号化データを復号化して、携帯端末３００ｂの携帯端末ＩＤを取得する（Ｓ６１７）。さらに、認証要求受信部１３０は、取得した携帯端末３００ｂの携帯端末ＩＤを、受信時刻の情報と共に認証要求ログとして認証要求ログ情報１９５に格納する（Ｓ６１９）。

一方、ゲートウェイ装置２００が携帯端末３００ｂからＳＭＳメッセージを受信すると、ゲートウェイ装置２００の認証ＳＭＳ受信部は、受信したＳＭＳメッセージに含まれるワンタイム暗号化データ及びＳＭＳ送信元電話番号を認証情報としてサーバ装置１００に送信する（Ｓ６２１）。

ＳＭＳ情報受信部１５０がゲートウェイ装置２００から認証情報を受信すると、認証情報に含まれる経由ワンタイム暗号化データを復号化して、携帯端末ＩＤを取得する（Ｓ６２３）。本実施形態では、ゲートウェイ装置２００から受信する認証情報には、チケットアプリ４００が携帯端末３００ｃの携帯端末ＩＤ及びタイムスタンプを用いて生成した経由ワンタイム暗号化データ、及びＳＭＳ発信元電話番号として携帯端末３００ｂの電話番号が含まれるので、ＳＭＳ情報受信部１５０は、携帯端末３００ｃの携帯端末ＩＤを取得する。

次に、真正性判定部１６０は、第１の真正性判定として、受信したＳＭＳ発信元電話番号がチケット管理情報１９１に存在するか否かを判定する（Ｓ６２５）。本実施例では、携帯端末３００ｂの電話番号はチケット管理情報１９１において登録されているので、第１の真正性判定は成功する。

さらに、真正性判定部１６０は、第２の真正性判定として、Ｓ６２３で経由ワンタイム暗号化データから得られた携帯端末ＩＤに関する認証要求ログが認証要求ログ情報１９５に存在するか否かを判定する（Ｓ６２７）。本実施例では、経由ワンタイム暗号化データを復号化して得られるのは携帯端末３００ｃの携帯端末ＩＤであり、一方、認証要求ログにはＳ６１９で携帯端末３００ｂの携帯端末ＩＤに関する認証ログが格納されているので、経由ワンタイム暗号化データから得られた携帯端末ＩＤに関する認証要求ログは存在しない。

よって、第２の真正性判定に失敗し、サーバ装置１００は処理を終了する。

このように、不正ユーザＵＢと不正ユーザＵＣが共謀して、ゲートウェイ装置２００に送信されたＳＭＳメッセージが書き換えられる場合、すなわち、当該ＳＭＳメッセージを送信する携帯端末３００ｂと、ワンタイム暗号化データを生成するチケットアプリ４００がインストールされた携帯端末３００ｃとが異なる場合、携帯端末３００ｂからの認証要求はサーバ装置１００における真正性判定に失敗する。よって、不正ユーザはチケットを取得することはできない。

（３．４ 不正ユーザによる電子チケットの受取時の処理２）
さらに、不正ユーザＵＢ及び不正ユーザＵＣによる電子チケットの受取に係る第２の処理の流れを、図７を参照しながら説明する。本実施例も、サーバ装置１００のチケット管理情報１９１においてダフ屋である不正ユーザＵＢが保有する携帯端末３００ｂの電話番号が登録されており、不正ユーザＵＣは、ダフ屋である不正ユーザＵＢからチケットの購入を望む不正ユーザである。図７は、電子チケットの受取に係る認証システム１０の処理の流れを示すシーケンス図である。

図７のＳ５０１からＳ５０７は、図５のＳ５０１からＳ５０７と同じ処理であるので、これらの処理の詳細な説明は省略する。ただし、図７では、ユーザＵＡが保有する携帯端末３００ａに代えて、不正ユーザＵＣが保有する携帯端末３００ｃで処理が実行される。

Ｓ５０７においてＳＭＳアプリ３３０が起動された後、不正ユーザＵＣはＳＭＳメッセージに含まれるワンタイム暗号化データをコピーした後、ＳＭＳメッセージを送信する（Ｓ５０９）。不正ユーザＵＣからの送信指示に応答して、認証ＳＭＳ送信部４２０が正常にＳＭＳメッセージを送信したので、認証要求送信部４１０は、生成した（携帯端末３００ｃの携帯端末ＩＤに関連する）ワンタイム暗号化データを含む認証要求をサーバ装置１００に送信し（Ｓ５１１）、及びＤＢ４６０に（携帯端末３００ｃの携帯端末ＩＤに関連する）ワンタイム暗号化データ４６１として格納する（Ｓ５１３）。

さらに、不正ユーザＵＣは、コピーしたＳＭＳメッセージに含まれるワンタイム暗号化データを、他のメールアプリ等を用いて不正ユーザＵＢに送信する（Ｓ７０１）。

携帯端末３００ｃから認証要求を受信すると、サーバ装置１００の認証要求受信部１３０は、認証要求に含まれる直接ワンタイム暗号化データを復号化して、携帯端末３００ｃの携帯端末ＩＤを取得する（Ｓ５１５）。さらに、認証要求受信部１３０は、取得した携帯端末３００ｃの携帯端末ＩＤを、認証要求ログとして認証要求ログ情報１９５に格納する（Ｓ５１７）。

一方、ゲートウェイ装置２００が携帯端末３００ｃからＳＭＳメッセージを受信すると、ゲートウェイ装置２００の認証ＳＭＳ受信部は、受信したＳＭＳメッセージに含まれるワンタイム暗号化データ及びＳＭＳ送信元電話番号を認証情報としてサーバ装置１００に送信する（Ｓ５１９）。

ＳＭＳ情報受信部１５０がゲートウェイ装置２００から認証情報を受信すると、認証情報に含まれる経由ワンタイム暗号化データを復号化して、携帯端末ＩＤを取得する（Ｓ５２１）。本実施形態では、ゲートウェイ装置２００から受信する認証情報には、チケットアプリ４００が携帯端末３００ｃの携帯端末ＩＤ及びタイムスタンプを用いて生成した経由ワンタイム暗号化データ、及びＳＭＳ発信元電話番号として携帯端末３００ｃの電話番号が含まれるので、ＳＭＳ情報受信部１５０は、携帯端末３００ｃの携帯端末ＩＤを取得する。

次に、真正性判定部１６０は、第１の真正性判定として、受信したＳＭＳ発信元電話番号がチケット管理情報１９１に存在するか否かを判定する（Ｓ５２３）。本実施例では、携帯端末３００ｃの電話番号はチケット管理情報１９１において登録されていないので、第１の真正性判定は失敗する。

さらに、真正性判定部１６０は、第２の真正性判定として、Ｓ５２１で経由ワンタイム暗号化データから得られた携帯端末ＩＤに関する認証要求ログが認証要求ログ情報１９５に存在するか否かを判定する（Ｓ５２５）。本実施例では、経由ワンタイム暗号化データを復号化して得られる携帯端末３００ｃの携帯端末ＩＤに関する認証要求ログが、認証要求ログ情報１９５に格納されている。

第１の真正性判定に失敗しているので、真正性判定部１６０は、経由ワンタイム暗号化データから得られた携帯端末３００ｃの携帯端末ＩＤに関する認証要求ログを、不正ユーザＵからの認証要求に由来するものとして削除する（Ｓ７０３）。

よって、第１の真正性判定に失敗し、サーバ装置１００は処理を終了する。なお、本実施例では、不正ユーザＵＣを、ダフ屋である不正ユーザＵＢと共謀する不正ユーザとして記載しているが、ユーザＵＣが単独で電子チケットの受取を試みた場合も、上述した図７のＳ５０１からＳ５２５、及びＳ７０３で説明されるように、サーバ装置１００における真正性判定に失敗する。

ここでさらに、不正ユーザＵＣから携帯端末３００ｃの携帯端末ＩＤに関連するワンタイム暗号化データを受信した不正ユーザＵＢが、携帯端末３００ｂを用いて操作を行う。携帯端末３００ｂで、図６のＳ６０３からＳ６０９と同じＳ７０５からＳ７１１の処理が実行され、Ｓ７１１においてＳＭＳアプリ３３０が起動される。

ここで、不正ユーザＵＢは、Ｓ７１１において表示されたＳＭＳメッセージの本文を、不正ユーザＵＣから受信した携帯端末３００ｃの携帯端末ＩＤに関連するワンタイム暗号化データに書き換えてＳＭＳメッセージを送信する（Ｓ７１３）。不正ユーザＵＢからの送信指示に応答して、ＳＭＳアプリ３３０が正常にＳＭＳメッセージを送信したので、認証要求送信部４１０は、生成した（携帯端末３００ｂの携帯端末ＩＤに関連する）ワンタイム暗号化データを含む認証要求をサーバ装置１００に送信し（Ｓ７１５）、ＤＢ４６０に（携帯端末３００ｂの携帯端末ＩＤに関連する）ワンタイム暗号化データ４６１として格納する（Ｓ７１７）。

携帯端末３００ｂから認証要求を受信すると、サーバ装置１００の認証要求受信部１３０は、認証要求に含まれる直接ワンタイム暗号化データを復号化して、携帯端末３００ｂの携帯端末ＩＤを取得する（Ｓ７１９）。さらに、認証要求受信部１３０は、取得した携帯端末３００ｂの携帯端末ＩＤを、受信時刻の情報と共に認証要求ログとして認証要求ログ情報１９５に格納する（Ｓ７２１）。

一方、ゲートウェイ装置２００が携帯端末３００ｂからＳＭＳメッセージを受信すると、ゲートウェイ装置２００の認証ＳＭＳ受信部は、受信したＳＭＳメッセージに含まれるワンタイム暗号化データ及びＳＭＳ送信元電話番号を認証情報としてサーバ装置１００に送信する（Ｓ７２３）。

ＳＭＳ情報受信部１５０がゲートウェイ装置２００から認証情報を受信すると、認証情報に含まれる経由ワンタイム暗号化データを復号化して、携帯端末ＩＤを取得する（Ｓ７２５）。本実施形態では、ゲートウェイ装置２００から受信する認証情報には、チケットアプリ４００が携帯端末３００ｃの携帯端末ＩＤ及びタイムスタンプを用いて生成した経由ワンタイム暗号化データ、及びＳＭＳ発信元電話番号として携帯端末３００ｂの電話番号が含まれるので、ＳＭＳ情報受信部１５０は、携帯端末３００ｃの携帯端末ＩＤを取得する。

次に、真正性判定部１６０は、第１の真正性判定として、受信したＳＭＳ発信元電話番号がチケット管理情報１９１に存在するか否かを判定する（Ｓ７２７）。携帯端末３００ｂの電話番号はチケット管理情報１９１において登録されているので、第１の真正性判定は成功する。

さらに、真正性判定部１６０は、第２の真正性判定として、Ｓ７２５で経由ワンタイム暗号化データから得られた携帯端末ＩＤに関する認証要求ログが認証要求ログ情報１９５に存在するか否かを判定する（Ｓ７２９）。本実施例では、Ｓ５１７で格納された携帯端末３００ｃの携帯端末ＩＤはＳ７０３で削除されているので、認証要求ログには、Ｓ７２１で格納された携帯端末３００ｂの携帯端末ＩＤのみが格納されている。すなわち、経由ワンタイム暗号化データから得られる携帯端末３００ｂの携帯端末ＩＤに関する認証要求ログは存在しないので、第２の真正性判定に失敗し、サーバ装置１００は処理を終了する。

このように、チケットを受け取る権利を有する携帯端末３００の電話番号を含むチケット管理情報１９１において登録されていない携帯端末３００ｃからの認証要求は、サーバ装置１００における第１の真正性判定に失敗する。

さらに、不正ユーザＵＢと不正ユーザＵＣが共謀して、携帯端末３００ｃにインストールされたチケットアプリ４００で生成されたワンタイム暗号化データが携帯端末３００ｂに送信される場合がある。しかし、ＳＭＳメッセージを書き換えて送信する携帯端末３００ｂからの認証要求は、サーバ装置１００における第２の真正性判定に失敗する。よって、不正ユーザはチケットを取得することはできない。

（３．５ 認証処理）
サーバ装置１００の認証要求に係る処理の流れを、図８を参照しながら説明する。図８は、サーバ装置１００の認証処理の流れを示すフローチャートである。

携帯端末３００から認証要求を受信すると（Ｓ８０１）、認証要求受信部１３０は、認証要求に含まれる直接ワンタイム暗号化データを復号化して、携帯端末３００の携帯端末ＩＤを取得する（Ｓ８０３）。さらに、認証要求受信部１３０は、取得した携帯端末ＩＤを、認証要求ログとして認証要求ログ情報１９５に格納する（Ｓ８０５）。

一方、ＳＭＳ情報受信部１５０がゲートウェイ装置２００から携帯端末３００の認証情報を受信する（Ｓ８０７）。本実施形態では、ゲートウェイ装置２００から受信する認証情報には、チケットアプリ４００が携帯端末３００の携帯端末ＩＤを用いて生成した経由ワンタイム暗号化データ、及びＳＭＳ発信元電話番号が含まれる。ＳＭＳ情報受信部１５０は、認証情報に含まれる経由ワンタイム暗号化データを復号化して、携帯端末ＩＤを取得する（Ｓ８０９）。

次に、真正性判定部１６０は、第１の真正性判定として、受信したＳＭＳ発信元電話番号がチケット管理情報１９１に存在するか否かを判定する（Ｓ８１１）。さらに、真正性判定部１５０は、第２の真正性判定として、Ｓ８０９で経由ワンタイム暗号化データから得られた携帯端末ＩＤに関する認証要求ログが認証要求ログ情報１９５に存在するか否かを判定する（Ｓ８１３）。

受信したＳＭＳ発信元電話番号がチケット管理情報１９１に存在し（Ｓ８１１：Ｙｅｓ）、かつ、経由ワンタイム暗号化データから得られた携帯端末ＩＤに関する認証要求ログが存在する（Ｓ８１３：Ｙｅｓ）場合、真正性判定部１６０は、チケット管理情報１９１において、第２の真正性判定を経た携帯端末ＩＤを、第１の真正性判定を経た電話番号に紐付けて格納する（Ｓ８１５）。

次に、認証応答部１７０は、経由ワンタイム暗号化データから得られた携帯端末ＩＤ及びタイムスタンプを含むデータを共通鍵で暗号化して、ワンタイム暗号化データを生成する（Ｓ８１７）。さらに、認証応答部１７０は、携帯端末３００においてチケットアプリ４００を起動すると共に、チケットアプリ４００にワンタイム暗号化データを用いた処理を実行可能とさせるためのＵＲＬスキームを生成する（Ｓ８１９）。最後に、認証応答部１７０は、生成したＵＲＬスキームを含むＳＭＳメッセージを、ＳＭＳ発信元電話番号に送信し（Ｓ８２１）、処理を終了する。

ここで、受信したＳＭＳ発信元電話番号がチケット管理情報１９１に存在しない場合も（Ｓ８１１：Ｎｏ）、真正性判定部１６０は、Ｓ８０９で経由ワンタイム暗号化データから得られた携帯端末ＩＤに関する認証要求ログが認証要求ログ情報１９５に存在するか否かを判定する（Ｓ８２３）。同一の認証要求ログが存在する場合（Ｓ８２３：Ｙｅｓ）、真正性判定部１６０は当該認証要求ログを削除して（Ｓ８２５）処理を終了する。同一の認証要求ログが存在しない場合（Ｓ８２３：Ｎｏ）、真正性判定部１６０は処理を終了する。Ｓ８１３において同一の認証要求ログが存在しない場合も（Ｓ８１３：Ｎｏ）、真正性判定部１６０は処理を終了する。

なお、図５〜８の例では、サーバ装置１００が携帯端末３００から認証要求を受信した後に、ゲートウェイ装置２００から認証情報を受信している。しかしながら、前述したように受信の順番は特に限定されるものではなく、サーバ装置１００がゲートウェイ装置２００から認証情報を受信した後に、携帯端末３００から認証要求を受信することもあり得る。

（４．別の実施形態）
特に図２、図３、図５及び図８を参照して説明した実施形態のうち、認証システム１０は、一部の処理を省略して認証処理を行うことができる。具体的には、本実施形態では、サーバ装置の認証応答部１７０、チケットアプリ４００のＵＲＬスキーム実行部４３０が行う処理を省略してユーザＵの認証処理を行う。

本実施形態では、図５において示されるＳ５０１からＳ５２７までの処理を経て、サーバ装置１００のチケット管理情報１９１において携帯端末ＩＤと電話番号との紐付けが完了したことにより、携帯端末３００からの認証要求を真正なものとして処理し、例えばチケット購入申請情報１９３において管理されているメールアドレスを用いて、ユーザＵに認証結果を通知するメールを送信する。

認証結果を受信したユーザＵは、携帯端末３００においてチケットアプリ４００を起動し、ＵＩ表示部４５０によって表示される画面上で例えばチケットデータ表示ボタンを押下する。これに応答して、チケット取得部４４０が、一連の認証処理において真正性が確認された携帯端末ＩＤを用いてサーバ装置１００にチケットデータ送信要求を送信し、チケットデータを受信するよう構成することもできる。

（５．ハードウェア構成）
以下、サーバ装置１００及び携帯端末３００を実現可能なハードウェア構成について、図９から図１０を参照しながら説明する。

（５．１ サーバ装置１００）
まず、図９を参照しながら、サーバ装置１００を実現可能なハードウェア構成を説明する。図９は、サーバ装置１００を実現可能なハードウェア構成の具体例を示す図である。図９に示すように、サーバ装置１００は、制御部９０１と、通信Ｉ／Ｆ（インタフェース）部９０５と、記憶部９０７と、表示部９１１と、入力部９１３とを含み、各部はバスライン９１５を介して接続される。

制御部９０１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ。図示せず。）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ。図示せず。）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９０３等を含む。制御部９０１は、記憶部９０７に記憶される制御プログラム９０９を実行することにより、一般的な情報処理装置としての機能に加え、上述したチケットサービスに係る認証処理を実現可能に構成される。例えば、図２を参照しながら説明したウェブサイト提供部１１０、抽選部１２０、認証要求受信部１３０、認証要求ログ管理部１４０、ＳＭＳ情報受信部１５０、真正性判定部１６０、認証応答部１７０及びチケットデータ送信部１８０は、ＲＡＭ９０３に一時記憶された上で、ＣＰＵ上で動作する制御プログラム９０９として実現可能である。

またＲＡＭ９０３は、制御プログラム９０９に含まれるコードの他、図２に示したチケット管理情報１９１、チケット購入申請情報１９３及び認証要求ログ情報１９５の一部又は全部を一時的に保持する。更にＲＡＭ９０３は、ＣＰＵが各種処理を実行する際のワークエリアとしても使用される。

通信Ｉ／Ｆ部９０５は、ゲートウェイ装置２００及び携帯端末３００を含む外部の装置との間で、有線又は無線によるネットワークＮを介したデータ通信を行うためのデバイスである。図２で示したウェブサイト提供部１１０、認証要求受信部１３０、ＳＭＳ情報受信部１５０、認証応答１７０及びチケットデータ送信部１８０がゲートウェイ装置２００及び携帯端末３００との間で行う通信は、全て通信Ｉ／Ｆ部９０５が行う。

記憶部９０７は、例えばＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やフラッシュメモリ等の不揮発性の記憶媒体である。記憶部９０７は、一般的な情報処理装置としての機能を実現するためのオペレーションシステム（ＯＳ）及びデータ（図示せず）を記憶する。また記憶部９０７は、制御プログラム９０９及びＤＢ１９０を記憶する。

制御プログラム９０９は、上述のチケットサービスに係る認証処理を行うためのプログラムである。前述したように、図２に示したウェブサイト提供部１１０、抽選部１２０、認証要求受信部１３０、認証要求ログ管理部１４０、ＳＭＳ情報受信部１５０、真正性判定部１６０、認証応答部１７０及びチケットデータ送信部１８０は、制御プログラム９０９に含まれ得る。

ＤＢ１９０は、チケットサービスに係る認証処理に必要な各種データ、例えばチケット管理情報１９１、チケット購入申請情報１９３及び認証要求ログ情報１９５を含むことができる。ＤＢ１９０に含まれる各種データは、必要に応じてＲＡＭ９０３にロードされ、制御部９０１に含まれるＣＰＵから参照される。

表示部９１１は、サービス事業者に情報を提示するためのディスプレイ装置である。表示部９１１の具体例としては、例えば液晶ディスプレイや有機ＥＬ（Ｅｌｅｃｔｒｏ−Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ等が挙げられる。入力部９１３は、サービス事業者から入力を受け付けるためのデバイスである。入力部９１３の具体例としては、キーボードやマウス、タッチパネル等を挙げることができる。

なお、サーバ装置１００は、表示部９１１及び入力部９１３を必ずしも備える必要はない。また表示部９１１及び入力部９１３は、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）やディスプレイポート等の各種インタフェースを介して外部からサーバ装置１００に接続されても良い。

（５．２ 携帯端末３００）
次に、図１０を参照しながら、携帯端末３００を実現可能なハードウェア構成を説明する。図１０は、携帯端末３００のハードウェア構成の具体例を示す図である。図１０に示すように、携帯端末３００は、制御部３０１と、通信インタフェース（Ｉ／Ｆ）部３０５と、記憶部３０７と、タッチパネルディスプレイ３０９と、入力部３１５とを含み、各部はバスライン３１７を介して接続される。

制御部３０１は、ＣＰＵ、ＲＯＭ、ＲＡＭ３０３等を含む。制御部３０１は、記憶部３０７に記憶されるチケットアプリ４００、ブラウザ３２０、及びＳＭＳアプリ３３０を実行可能である。これにより、携帯端末３００は一般的な情報処理装置としての機能に加え、上述したチケットサービスに係る各種処理を実現可能である。

また、ＲＡＭ３０３は、チケットアプリ４００、ブラウザ３２０、及びＳＭＳアプリ３３０に含まれるコードの他、図３に示したワンタイム暗号化データ４６１、及びチケット情報４６３の一部又は全部を一次的に保持する。更にＲＡＭ３０３は、ＣＰＵが各種処理を実行する際のワークエリアとしても使用される。

通信Ｉ／Ｆ部３０５は、サーバ装置１００及びゲートウェイ装置２００を含む外部の装置との間で、有線又は無線によるネットワークＮを介したデータ通信を行うためのデバイスである。図３で示した認証要求送信部４１０、チケット取得部４４０等がサーバ装置１００及びゲートウェイ装置２００との間で行う通信は、全て通信Ｉ／Ｆ部３０５が行う。

記憶部３０７は、例えばＨＤＤやフラッシュメモリ等の不揮発性の記憶媒体である。記憶部３０７は、一般的な情報処理としての機能を実現するためのオペレーションシステム（ＯＳ）やアプリケーション及びデータ（図示せず）を記憶する。また記憶部３０７は、チケットアプリ４００、ブラウザ３２０、及びＳＭＳアプリ３３０を記憶する。

ブラウザ３２０は、サーバ装置１００の提供するチケットサービスサイトを含むネットワークＮ上の各種ウェブサイトをユーザＵに閲覧可能とするためのアプリケーションプログラムである。

ＳＭＳアプリ３３０は、ユーザＵがゲートウェイ装置２００や他のユーザとの間でＳＭＳメッセージの送受信を行うためのアプリケーションプログラムである。

チケットアプリ４００については、図３を参照しながら前述したので、ここでは説明を省略する。

タッチパネルディスプレイ３０９は、情報を提示する表示装置であるディスプレイ部３１１と、操作入力がなされるタッチパネル部３１３とが重ね併せて実装される装置である。タッチパネルディスプレイ３０９を用いることによりユーザＵは、ディスプレイ部３１１に表示された表示内容に対して、直接操作を行っているような直感的な操作感を得ることができる。

入力部３１５は、ユーザＵからの操作入力を受け付けるための、タッチパネルディスプレイ３０９とは別に設けられたデバイスである。入力部３１５の具体例としては、例えば操作ボタンやキーボード、マウス等を挙げることができる。

なお、携帯端末３００は、入力部３１５を必ずしも備える必要はない。また、入力部３１５は、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）やＢｌｕｅｔｏｏｔｈ（登録商標）等の各種インタフェースを介して外部から携帯端末３００に接続されても良い。

以上説明した実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。また、本発明は、その要旨を逸脱しない限り、さまざまな変形が可能である。さらに、当業者であれば、以下に述べる各要素を均等なものに置換した実施形態を採用することが可能であり、係る実施形態も本発明の範囲に含まれる。

（６．本実施形態の効果）
以上、本発明の認証システムによれば、携帯端末ＯＳのＡＰＩを介して電話番号を取得することなく、アプリケーションサイドで電話番号を用いて当該電話番号に紐付く携帯端末３００を認証することができる。ＳＭＳ発信元電話番号がチケット管理情報１９１に存在するか否かを判定する第１の判定により、ゲートウェイ装置２００にＳＭＳメッセージを送信した携帯端末３００が、チケット管理情報１９１に含まれる電話番号に紐付く携帯端末３００であることが確認できる。また、認証情報に含まれる携帯端末ＩＤに関する認証要求ログが存在するか否かを判定する第２の判定により、ゲートウェイ装置２００に送信されたＳＭＳメッセージが、当該メッセージに含まれる携帯端末ＩＤを生成した携帯端末３００からのものであることが確認できる。

また、チケット管理情報１９１に含まれる電話番号に紐付かない携帯端末３００からの認証要求に由来する認証要求ログを削除することで、より強固な認証システムを構築することができる。

また、チケットアプリ４００にワンタイム暗号化データを用いた処理を実行可能とさせるためのＵＲＬスキームを生成することで、サーバ装置１００において電話番号と紐付けられた携帯端末ＩＤに基づくワンタイム暗号化データを用いた処理を確実に遂行することができ、より強固な認証システムを構築することができる。

また、ＵＲＬスキームを用いて、ＳＭＳメッセージで特定されるワンタイム暗号化データと、アプリケーションが認証要求送信時に生成したワンタイム暗号化データとが一致することを確認することにより、認証が成功した携帯端末３００上でのみ、ＵＲＬスキームで指定した所定の処理を実行することができ、より強固な認証システムを構築することができる。

また、認証要求の受信から一定の期間を経過した認証要求ログについては無効であるとして削除することで、より強固な認証システムを構築することができる。

１０…認証システム、１００…サーバ装置、１１０…ウェブサイト提供部、１１１…ユーザ画面送信部、１１３…チケット購入申請受信部、１２０…抽選部、１３０…認証要求受信部、１４０…認証要求ログ管理部、１５０…ＳＭＳ情報受信部、１６０…真正性判定部、１７０…認証応答部、１８０…チケットデータ送信部、１９０…ＤＢ、１９１…チケット管理情報、１９３…チケット購入申請情報、１９５…認証要求ログ情報、２００…ゲートウェイ装置、３００…携帯端末、３０１…制御部、３０３…ＲＡＭ、３０５…通信Ｉ／Ｆ部、３０７…記憶部、３０９…タッチパネルディスプレイ、３１１…ディスプレイ部、３１３…タッチパネル部、３１５…入力部、３１７…バスライン、３２０…ブラウザ、３３０…ＳＭＳアプリ、４００…チケットアプリ、４１０…認証要求送信部、４２０…ワンタイム暗号化データ管理部、４３０…ＵＲＬスキーム実行部、４４０…チケット取得部、４５０…ＵＩ表示部、４６０…ＤＢ、４６１…ワンタイム暗号化データ、４６３…チケット情報、９０１…制御部、９０３…ＲＡＭ、９０５…通信Ｉ／Ｆ部、９０７…記憶部、９０９…制御プログラム、９１１…表示部、９１３…入力部、３１５…バスライン、１００１…制御部、１００３…ＲＡＭ、１００５…通信Ｉ／Ｆ部、１００７…記憶部、１００９…制御プログラム、１０１１…バスライン、Ｎ…ネットワーク、Ｕ…ユーザ

Claims (10)

1. ゲートウェイ装置及び携帯端末と通信可能に接続されるサーバ装置であって、
   携帯端末の電話番号を記憶する記憶部と、
   携帯端末のアプリケーションから当該携帯端末に固有な端末固有情報を含む認証要求を受信して、前記端末固有情報に基づいて認証要求ログを生成する認証要求受信部と、
   前記携帯端末から前記ゲートウェイ装置に送信されたＳＭＳ（ショートメッセージサービス）メッセージに含まれる認証情報を前記ゲートウェイ装置から受信して、受信した前記認証情報から端末固有情報を取得するＳＭＳ情報受信部であって、前記認証情報は、前記端末固有情報及びＳＭＳ発信元電話番号を含む、ＳＭＳ情報受信部と、
   前記ＳＭＳ発信元電話番号が前記記憶部に存在するか否かを判定する第１の判定と、前記認証情報に含まれる前記端末固有情報に関する認証要求ログが存在するか否かを判定する第２の判定とを実行する真正性判定部であって、前記ＳＭＳ発信元電話番号が前記記憶部に存在し、前記認証情報に含まれる前記端末固有情報に関する認証要求ログが存在する場合、前記端末固有情報を、前記記憶部の前記電話番号に紐付けて格納する、真正性判定部と
   を備えるサーバ装置。
2. 前記真正性判定部は、前記ＳＭＳ発信元電話番号が前記記憶部に存在しない場合、前記認証情報に含まれる前記端末固有情報に関する認証要求ログを削除する、請求項１に記載のサーバ装置。
3. 前記ＳＭＳ発信元電話番号が前記記憶部に存在し、前記認証情報に含まれる前記端末固有情報に関する認証要求ログが存在する場合、前記携帯端末において前記アプリケーションを起動すると共に、前記アプリケーションに前記端末固有情報を用いた処理を実行可能とさせるためのＵＲＬスキームを生成して、当該ＵＲＬスキームを含むＳＭＳメッセージを、前記ＳＭＳ発信元電話番号に送信する認証応答部
   をさらに備える、請求項１又は２に記載のサーバ装置。
4. 前記ＵＲＬスキームは、前記アプリケーションに、前記ＳＭＳメッセージで特定される前記端末固有情報と、前記アプリケーションが認証要求送信時に生成した前記端末固有情報とが一致するか否か判定する処理を実行可能とさせる、請求項３に記載のサーバ装置。
5. 前記認証要求の受信から一定の期間を経過した認証要求ログを削除する認証要求ログ管理部
   をさらに備える、請求項１から４のいずれか一項に記載のサーバ装置。
6. ゲートウェイ装置及び携帯端末と通信可能に接続される１又は複数のコンピュータが、
   携帯端末の電話番号を記憶部に記憶する工程と、
   携帯端末のアプリケーションから当該携帯端末に固有な端末固有情報を含む認証要求を受信して、前記端末固有情報に基づいて認証要求ログを生成する工程と、
   前記携帯端末から前記ゲートウェイ装置に送信されたＳＭＳメッセージに含まれる認証情報を前記ゲートウェイ装置から受信して、受信した前記認証情報から端末固有情報を取得する工程であって、前記認証情報は、前記端末固有情報及びＳＭＳ発信元電話番号を含む、工程と、
   前記ＳＭＳ発信元電話番号が前記記憶部に存在するか否かを判定する工程と、
   前記認証情報に含まれる前記端末固有情報に関する認証要求ログが存在するか否かを判定する工程と、
   前記ＳＭＳ発信元電話番号が前記記憶部に存在し、前記認証情報に含まれる前記端末固有情報に関する認証要求ログが存在する場合、前記端末固有情報を、前記記憶部の前記電話番号に紐付けて格納する工程と
   を含む方法。
7. サーバ装置及びゲートウェイ装置と通信可能に接続される携帯端末に、
   当該携帯端末に固有な端末固有情報を生成する工程と、
   ＳＭＳメッセージを前記ゲートウェイ装置に送信するために当該携帯端末のＳＭＳアプリケーションを起動する工程と、
   前記端末固有情報を本文に含むＳＭＳメッセージを生成する工程と、
   前記ＳＭＳアプリケーションが所定の条件下で前記ＳＭＳメッセージを送信した場合、
   前記端末固有情報を含む認証要求を前記サーバ装置に送信する工程と
   を実行させるプログラム。
8. 前記携帯端末に、
   前記端末固有情報を含むＵＲＬスキームが選択されることに応答して、当該プログラムを起動する工程と、
   前記ＵＲＬスキームに含まれる前記端末固有情報を用いた処理を実行する工程と
   をさらに実行させる、請求項７に記載のプログラム。
9. サーバ装置及びゲートウェイ装置と通信可能に接続される携帯端末が、
   当該携帯端末に固有な端末固有情報を生成する工程と、
   ＳＭＳメッセージを前記ゲートウェイ装置に送信するために当該携帯端末のＳＭＳアプリケーションを起動する工程と、
   前記端末固有情報を本文に含むＳＭＳメッセージを生成する工程と、
   前記ＳＭＳアプリケーションが所定の条件下で前記ＳＭＳメッセージを送信した場合、
   前記端末固有情報を含む認証要求を前記サーバ装置に送信する工程と
   を含む方法。
10. サーバ装置及びゲートウェイ装置と通信可能に接続される携帯端末であって、
    当該携帯端末に固有な端末固有情報を生成して、当該端末固有情報を含む認証要求を前記サーバ装置に送信する認証要求送信部であって、ＳＭＳメッセージを前記ゲートウェイ装置に送信するために当該携帯端末のＳＭＳアプリケーションを起動して、前記端末固有情報を本文に含むＳＭＳメッセージを生成し、前記ＳＭＳアプリケーションが所定の条件下で前記ＳＭＳメッセージを送信した場合、前記認証要求を前記サーバ装置に送信する、認証要求送信部
    を備える携帯端末。