JPWO2017134922A1 - サービス提供システム、認証装置、及びプログラム - Google Patents

Abstract

サービス提供システム（１）は、ユーザが操作するユーザ端末（３０）からサービスのログイン要求を受信し、このユーザ端末（３０）から認証用の秘密鍵を取得できた場合、取得した秘密鍵と予め保持している秘密鍵とに基づいてユーザの認証を行う。また、サービス提供システム（１）は、ユーザ端末（３０）から秘密鍵を取得できない場合、又は秘密鍵による認証に失敗した場合、ユーザに関連付けられている携帯端末（４０）からの電話着信に基づいて、ユーザの認証を行う。

Description

本発明は、サービス提供システム、認証装置、及びプログラムに関する。

インターネットを利用したネットバンキング、ネットショッピング、オンライントレード等のサービスが普及している。ユーザは、ＰＣ（Personal Computer）等の端末装置を操作して専用のサイトにアクセスし、パスワード等による認証を行うことにより、このようなサービスを利用することができる。特許文献１には、携帯電話からシステム側に発呼番号を送信することで、より安全にこのようなサービスを利用することができる発明について記載されている。

特許第３４９７７９９号公報

特許文献１に記載された発明では、パスワード方式の認証よりもセキュリティを高めることが期待できる。しかしながら、特許文献１に記載された発明では、サービスを利用する度に携帯電話を用いてシステム側に発呼する必要があり、ユーザにとって面倒である。

本発明は、上記実情に鑑みてなされたものであり、サービスを利用する際に高いセキュリティを確保できるとともに、ユーザの手間もかからないサービス提供システム等を提供することを目的とする。

上記目的を達成するため、本発明の第１の観点に係るサービス提供システムは、
ユーザが操作するユーザ端末からサービスのログイン要求を受信するログイン要求受信部と、
前記ユーザ端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部と、
前記ユーザ端末から前記秘密鍵を取得できない場合、又は前記鍵認証部で認証に失敗した場合、前記ユーザに関連付けられている携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部と、
前記鍵認証部又は前記電話認証部で認証に成功した場合に、ログイン要求の送信元のユーザ端末に対して前記サービスを提供するための処理を実行するサービス提供部と、
を備える。

前記鍵認証部又は前記電話認証部で認証に成功した場合に、前記ユーザの認証用の秘密鍵を新たに作成して前記サービス提供システムで保持するとともに、作成した前記秘密鍵を前記ユーザ端末に送信する秘密鍵送信部を備えてもよい。

前記電話認証部は、前記携帯端末からの電話着信を受信後、前記ユーザ端末からの電話認証依頼があった場合に認証を行ってもよい。

前記電話認証部は、前記携帯端末からの電話着信を受信後に、予め定めた待ち時間以内に前記電話認証依頼が無かった場合、ユーザを認証しなくてもよい。

前記電話認証部は、
前記ユーザ端末に複数の自局電話番号の中から選択した接続番号を通知し、
前記携帯端末からの電話着信の着信先の電話番号が通知した接続番号と一致しない場合はユーザを認証しなくてもよい。

前記電話認証部は、前記携帯端末の機器識別情報を前記ユーザ端末から取得し、予め記憶している対応する機器識別情報と一致する場合は前記電話着信に基づいて前記ユーザの認証を行い、一致しない場合は前記ユーザの認証を行わなくてもよい。

上記目的を達成するため、本発明の第２の観点に係るサービス提供システムは、
ユーザが操作する携帯端末からサービスのログイン要求を受信するログイン要求受信部と、
前記携帯端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部と、
前記携帯端末から前記秘密鍵を取得できない場合、又は前記鍵認証部で認証に失敗した場合、前記携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部と、
前記鍵認証部又は前記電話認証部で認証に成功した場合に、前記携帯端末に対して前記サービスを提供するための処理を実行するサービス提供部と、
を備える。

上記目的を達成するため、本発明の第３の観点に係る認証装置は、
ネットワークを介してユーザが操作するユーザ端末にサービスを提供するサーバに接続された認証装置であって、
前記サーバが前記ユーザ端末からサービスのログイン要求を受信した際に前記ユーザ端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部と、
前記秘密鍵を取得できなかった場合、又は前記鍵認証部で認証できなかった場合、前記ユーザに関連付けられている携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部と、
を備える。

上記目的を達成するため、本発明の第４の観点に係る認証装置は、
ネットワークを介してユーザが操作する携帯端末にサービスを提供するサーバに接続された認証装置であって、
前記サーバが前記携帯端末からサービスのログイン要求を受信した際に前記携帯端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部と、
前記秘密鍵を取得できなかった場合、又は前記鍵認証部で認証できなかった場合、前記携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部と、
を備える。

上記目的を達成するため、本発明の第５の観点に係るプログラムは、
ネットワークを介してユーザが操作するユーザ端末にサービスを提供するサーバに接続されたコンピュータを、
前記サーバが前記ユーザ端末からサービスのログイン要求を受信した際に前記ユーザ端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部、
前記秘密鍵を取得できなかった場合、又は前記鍵認証部で認証できなかった場合、前記ユーザに関連付けられている携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部、
として機能させる。

上記目的を達成するため、本発明の第６の観点に係るプログラムは、
ネットワークを介してユーザが操作する携帯端末にサービスを提供するサーバに接続されたコンピュータを、
前記サーバが前記携帯端末からサービスのログイン要求を受信した際に前記携帯端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部、
前記秘密鍵を取得できなかった場合、又は前記鍵認証部で認証できなかった場合、前記携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部、
として機能させる。

本発明によれば、サービスを利用する際に高いセキュリティを確保できるとともに、ユーザの手間も低減することができる。

本発明の実施形態に係るサービス提供システムの全体構成を示す図である。 サーバの構成を示すブロック図である。 顧客ＤＢの構成例を示す図である。 認証装置の構成を示すブロック図である。 利用者コードＤＢの構成例を示す図である。 秘密鍵ＤＢの構成例を示す図である。 共通設定ＤＢの構成例を示す図である。 ユーザ端末の構成を示すブロック図である。 本発明の実施形態１に係るログイン処理の動作を説明するためのフローチャート（その１）である。 本発明の実施形態１に係るログイン処理の動作を説明するためのフローチャート（その２）である。 電話認証画面の例を示す図である。 秘密鍵登録処理の動作を説明するためのフローチャートである。 鍵認証処理の動作を説明するためのフローチャートである。 実施形態２に係る利用者コードＤＢの構成例を示す図である。 実施形態２に係るログイン処理の動作を説明するためのフローチャートである。 実施形態２における電話認証画面の例を示す図である。 実施形態３における顧客ＤＢの構成例を示す図である。 実施形態３に係るログイン処理の動作を説明するためのフローチャートである。 製造番号入力画面の例を示す図である。 変形例に係るサービス提供システムの全体構成を示す図である。

（実施形態１）
以下、本発明の実施形態１について図面を参照しながら詳細に説明する。なお、図中、同一または同等の部分には同一の符号を付す。

図１は、本発明の実施形態１に係るサービス提供システム１の全体構成を示す図である。このサービス提供システム１は、インターネットＮ１を介してユーザ端末３０に接続されるサーバ１０と、電話網Ｎ２を介して携帯端末４０に接続される認証装置２０と、を備える。なお、サーバ１０と認証装置２０とは専用線Ｎ３（又はインターネット）により接続されている。

サーバ１０は、インターネットＮ１を介してユーザ端末３０に各種のサービスを提供する。なお、ここでいう「サービス」とは、例えば、インターネットＮ１を利用したネットバンキング、ネットショッピング、オンライントレード、電子チケットシステム、ネットワーク上で分割して保持されているファイルを復元するサービス等であり、利用時に正規のユーザであるかどうかの認証を受ける必要がある。サーバ１０は、例えば、提供するサービスを運営する企業によって管理される。サーバ１０は、図２に示すように、通信部１１と、記憶部１２と、制御部１３と、を備える。なお、サーバ１０は、１台のコンピュータから構成されていてもよいし、複数台のコンピュータから構成されていてもよい。なお、図１では１つのサーバ１０しか示していないが、異なるサービスを提供する複数のサーバ１０がそれぞれ認証装置２０に接続されている。

通信部１１は、制御部１３の制御の下、インターネットＮ１や専用線Ｎ３を介して、ユーザ端末３０や認証装置２０とデータ通信を行う。通信部１１は、例えば、ＮＩＣ（Network Interface Card）などの通信インタフェースを備える。例えば、通信部１１は、インターネットＮ１を介して、ユーザ端末３０からサービスのログイン要求を受信する。

記憶部１２は、ハードディスクドライブなどであり、サーバ１０が動作するために必要な各種のデータを記憶する。例えば、記憶部１２には、サーバ１０の識別情報となる企業コードが記憶されている。また、記憶部１２は、顧客ＤＢ１２１を有している。

顧客ＤＢ１２１には、このサーバ１０が提供するサービスを利用可能な各ユーザに関する情報が記憶される。具体的には、図３に示すように、顧客ＤＢ１２１には、ユーザ毎に、ユーザＩＤ、氏名、パスワード、携帯電話番号等が記憶される。

なお、ユーザＩＤは、ユーザを一意に識別するためのＩＤである。パスワードは、ユーザがサービスにログインする際の認証に利用される。携帯電話番号は、ユーザの携帯端末４０の電話番号である。

図２に戻り、制御部１３は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）等（何れも図示せず）を備え、ＣＰＵが、ＲＡＭをワークメモリとして用い、ＲＯＭや記憶部１２に記憶されている各種プログラムを適宜実行することにより、サーバ１０の全体を制御する。

図１に戻り、続いて、認証装置２０について説明する。認証装置２０は、ユーザ端末３０からサーバ１０へのログイン要求があった際にユーザの認証を行う。認証装置２０は、図４に示すように、通信部２１と、記憶部２２と、制御部２３と、を備える。なお、認証装置２０は、１台のコンピュータから構成されていてもよいし、複数台のコンピュータから構成されていてもよい。

通信部２１は、制御部２３の制御の下、電話網Ｎ２を介して、携帯端末４０と電話通信を行う。また、通信部２１は、制御部２３の制御の下、専用線Ｎ３を介して、サーバ１０とデータ通信を行う。

記憶部２２は、ハードディスクドライブなどであり、サービス提供サーバ１０が動作するために必要な各種のデータを記憶する。例えば、記憶部２２は、利用者コードＤＢ２２１と、秘密鍵ＤＢ２２２と、共通設定ＤＢ２２３と、を備える。

利用者コードＤＢ２２１には、図５に示すように、利用者コードとその利用者コードを用いた電話認証が行われた日時（電話認証日時）とが登録される。利用者コードは、携帯端末４０からの電話着信の際に、その着信番号から不可逆に変換されたコードである。利用者コードは、後述するログイン処理において、ユーザの認証（電話番号認証）のために利用される。

秘密鍵ＤＢ２２２には、後述するログイン処理において、ユーザの認証のために利用される秘密鍵が登録される。具体的には、図６に示すように、秘密鍵ＤＢ２２２には、ユーザ毎に、ユーザの利用者コードと、ユーザの認証に用いる秘密鍵と、その秘密鍵を登録する際に必要となる電話認証の行われた日（電話認証日）と、が登録される。なお、一人のユーザで複数のユーザ端末３０を利用可能とするために複数の秘密鍵を保持することも可能であり、秘密鍵ＤＢ２２２には、１つのレコードに複数の秘密鍵が登録可能である。例えば、図６の先頭レコードでは、利用者コード「1ac279e09da2‥」に対して２つの秘密鍵が登録されている。

共通設定ＤＢ２２３には、接続されているサーバ１０毎に、そのサーバ１０で共通に設定される情報が登録される。具体的には、共通設定ＤＢ２２３には、図７に示すように、サーバ１０毎に、サーバ１０の企業コードと電話認証待ち時間と秘密鍵有効期間とが格納されている。

電話認証待ち時間は、携帯端末４０からの電話着信から電話認証依頼がなされるまでの制限時間を示し、電話認証待ち時間を超えて電話認証依頼を受信した際には認証失敗となる。また、秘密鍵有効期間は、秘密機が有効な期間を示し、この期間を超えて過去に作成された秘密鍵を認証に利用することはできない。

図４に戻り、制御部２３は、ＣＰＵ、ＲＯＭ、ＲＡＭ等（何れも図示せず）を備え、ＣＰＵが、ＲＡＭをワークメモリとして用い、ＲＯＭや記憶部２２に記憶されている各種プログラムを適宜実行することにより、認証装置２０の全体を制御する。また、制御部２３は、機能的な構成として鍵認証部２３１と電話認証部２３２とを備える。

鍵認証部２３１は、ユーザ端末３０からログイン要求を受信した際にサーバ１０が秘密鍵を取得できた場合に、この秘密鍵と秘密鍵ＤＢ２２２に保持している秘密鍵とに基づいて、ユーザが正規のユーザであるか否かを判別（鍵認証）する。

電話認証部２３２は、ユーザ端末３０からログイン要求を受信した際にサーバ１０が秘密鍵を取得できなかった場合や鍵認証部２３１で認証できなかった場合に、携帯端末４０からの電話着信の有無に基づいて、ユーザが正規のユーザであるか否かを判別（電話認証）する。

図１に戻り、続いて、ユーザ端末３０について説明する。ユーザ端末３０は、例えば、一般的なＰＣであり、インターネットＮ１を介して、サーバ１０に接続される。また、ユーザ端末３０には、Ｗｅｂブラウザ（以下、単にブラウザとする）が予めインストールされており、サーバ１０へのログインやサービスの申し込み等はブラウザの画面から行われる。また、後述するログイン処理により、ユーザ端末３０のブラウザには、「Ｗｅｂ Ｓｔｏｒａｇｅ」や「Ｃｏｏｋｉｅ」等の仕組みにより、ユーザの認証に用いる秘密鍵が格納される。ユーザ端末３０は、図８に示すように、通信部３１と、入力部３２と、表示部３３と、記憶部３４と、制御部３５と、を備える。

通信部３１は、通信インタフェースを備え、制御部３５の制御の下、インターネットＮ１を介して、サーバ１０とデータ通信を行う。

入力部３２は、キーボードやマウス等から構成され、ユーザ端末３０に様々な情報を入力するために使用される。例えば、ユーザは、入力部３２を操作して、ログインするために必要なユーザＩＤやパスワードを入力する。

表示部３３は、例えば液晶ディスプレイ等であり、制御部３５の制御の下、様々な情報を出力する。例えば、表示部３３には、ログイン画面や後述する電話認証画面等が表示される。

記憶部３４は、例えば、ハードディスクトライブであり、ユーザ端末３０が動作するために必要な各種のデータを記憶する。また、記憶部３４には、サーバ１０から送信された秘密鍵が格納される。

制御部３５は、ＣＰＵ、ＲＯＭ、ＲＡＭ等（何れも図示せず）を備え、ＣＰＵが、ＲＡＭをワークメモリとして用い、ＲＯＭや記憶部３４に記憶されている各種プログラムを適宜実行することにより、ユーザ端末３０の全体を制御する。

図１に戻り、続いて、携帯端末４０について説明する。携帯端末４０は、例えば、携帯電話やスマートフォンであり、電話網Ｎ２を介して認証装置２０に接続される。本実施形態では、携帯端末４０は、ユーザ端末３０からサーバ１０へなされたログインが、正規のユーザによるもので有るかどうかを判別（電話認証）するために利用される。携帯端末４０は、通信装置、タッチパネル、フラッシュメモリ、及びＣＰＵ等（何れも図示せず）を備える。

続いて、上述したサービス提供システム１で、ユーザ端末３０がサーバ１０が提供するサービスにログインする際の処理（ログイン処理）の動作について、図９、１０のフローチャートを用いて説明する。

サーバ１０が提供するサービスを利用したいユーザ（ログインユーザ）は、ユーザ端末３０の入力部３２を操作してブラウザを起動させ、サービス開始用のログイン画面を表示部３３に表示させる。そして、ユーザは、ユーザ端末３０の入力部３２を操作して、ログイン画面に自分のユーザＩＤとパスワードとを入力し、ログイン画面のログインボタンをクリックする。ログインボタンがクリックされると、制御部３５は、入力されたユーザＩＤとパスワードとを含んだログイン要求をサーバ１０に送信する（ステップＳ１０１）。

ログイン要求を受信すると、サーバ１０の制御部１３は、このログイン要求に含まれるユーザＩＤとパスワードとを用いて認証を行う（ステップＳ１０２）。具体的には、制御部１３は、受信したログイン要求に含まれるユーザＩＤとパスワードとを含むレコードが顧客ＤＢ１２１に登録されていることを確認してユーザ認証を行えばよい。なお、顧客ＤＢ１２１に該当するレコードが登録されていない場合、ユーザ認証は不成功となりエラーとして処理は終了する。

ユーザ認証に成功するとサーバ１０の制御部１３は、ログイン要求に含まれるユーザＩＤで顧客ＤＢ１２１を検索してユーザの携帯端末４０の電話番号を取得する。そして、制御部１３は、取得した電話番号から利用者コードを作成する（ステップＳ１０３）。例えば、制御部１３は、ＭＤ５等のハッシュ関数を用いて電話番号を変換したハッシュ値を利用者コードとして作成すればよい。利用者コードは、認証装置２０がユーザを認証する際に利用される。

続いて、制御部１３は、ログイン要求の送信元のユーザ端末３０にリクエストを送信して認証用の秘密鍵の取得を試みる。なお、初回ログイン時には、ユーザ端末３０のブラウザに秘密鍵は保持されていないため、秘密鍵を取得することはできない。秘密鍵を取得できない場合（ステップＳ１０４；Ｎｏ）、制御部１３は、携帯端末４０から認証装置２０に電話（発呼）することを促す電話認証画面の画面データをユーザ端末３０に送信し（図１０、ステップＳ１０５）、ユーザ端末３０の制御部３５は、図１１に示す電話認証画面を表示部３３に表示する（ステップＳ１０６）。なお、図１１に示す電話認証画面に表示されている電話番号（０３−１１１１−０００１）は、認証装置２０に発呼するための電話番号である。

図１０に戻り、ユーザ端末３０の電話認証画面を確認したユーザは、画面のメッセージに従い、自分の所有する携帯端末４０から認証装置２０に対して発呼する。認証装置２０の制御部２３は、携帯端末４０からの電話着信があると、その着信番号から利用者コードを作成して、利用者コードＤＢ２２１に登録する（ステップＳ１０７）。なお、ここで登録される利用者コードは、ステップＳ１０３で作成した利用者コードと同一の手法により作成される。また、制御部２３は、ステップＳ１０７で利用者コードＤＢ２２１に新たに登録されるレコードの電話認証日時を現在の日時に設定する。

一方、携帯端末４０のユーザは、認証装置２０からの応答（呼出音）を確認した後、ユーザ端末３０の入力部３２を操作して電話認証画面の電話認証ボタン（図１１参照）をクリックする。電話認証ボタンがクリックされると、ユーザ端末３０の制御部３５は、電話認証要求をサーバ１０に送信する（ステップＳ１０８）。

ユーザ端末３０から電話認証要求を受信すると、サーバ１０の制御部１３は、ステップＳ１０３で作成した利用者コードとサーバ１０の企業コードとを含んだ電話認証依頼を認証装置２０に送信する（ステップＳ１０９）。

電話認証依頼を受信すると認証装置２０の制御部２３は、電話認証処理を行う（ステップＳ１１０）。具体的には、制御部２３は、まず、電話認証依頼に含まれている企業コードをキーに共通設定ＤＢ２２３を検索して、この企業（サーバ１０）の電話認証待ち時間を取得する。そして、制御部２３は、認証依頼に含まれている利用者コードを有するレコードが利用者コードＤＢ２２１に登録されており、且つ、このレコードの電話認証日時から現在までの経過時間が、取得した電話認証待ち時間以内であることを確認することにより、認証を行えばよい。なお、認証に失敗した場合（即ち、利用者コードＤＢ２２１に該当するレコードが存在しない場合、若しくは存在しても経過時間が電話認証待ち時間を過ぎている場合）、認証失敗として以降の処理は実行されずに処理は終了する。

認証に成功した場合、制御部２３は、秘密鍵ＤＢ２２２に認証用の秘密鍵を登録する秘密鍵登録処理を実行する（ステップＳ１１１）。秘密鍵登録処理の詳細について、図１２のフローチャートを用いて説明する。

まず、認証装置２０の制御部２３は、所定桁数の乱数を作成する等して秘密鍵を作成する（ステップＳ１１）。そして、制御部２３は、サーバ１０から受信した電話認証依頼に含まれている利用者コードを有するレコードが秘密鍵ＤＢ２２２に登録されているか否かを判別する（ステップＳ１２）。

レコードが登録されている場合（ステップＳ１２；Ｙｅｓ）、制御部２３は、そのレコードの秘密鍵と電話認証日を、ステップＳ１１で作成した秘密鍵と今日の日付に更新し（ステップＳ１３）、秘密鍵登録処理は終了する。

一方、初回ログイン時などでありレコードが登録されていない場合（ステップＳ１２；Ｎｏ）、制御部２３は、電話認証依頼に含まれている利用者コードを有するレコードを新たに秘密鍵ＤＢ２２２に登録する（ステップＳ１４）。なお、このとき制御部２３は、新たに登録するレコードの秘密鍵はステップＳ１１で作成した秘密鍵、電話認証日は今日の日付とする。以上で秘密鍵登録処理は終了する。

図１０のフローチャートに戻り、秘密鍵登録処理（ステップＳ１１１）が終了すると、続いて、認証装置２０の制御部２３は、秘密鍵登録処理で登録又は更新した秘密鍵を電話認証依頼の依頼元のサーバ１０に送信する（ステップＳ１１２）。サーバ１０の制御部１３は、受信した秘密鍵をログイン要求の送信元のユーザ端末３０に送信する（ステップＳ１１３）。ユーザ端末３０の制御部３５は、「Ｗｅｂ Ｓｔｏｒａｇｅ」や「Ｃｏｏｋｉｅ」等の仕組みを用いてサーバ１０から受信した秘密鍵をブラウザ（物理的には記憶部３４）に格納する（ステップＳ１１４）。なお、既にブラウザに秘密鍵が格納されている場合は、受信した秘密鍵に更新する。

続いて、サーバ１０の制御部１３は、ユーザを正規のユーザとして正しく認証できたものとして、ログイン要求の送信元のユーザ端末３０に対して所定のサービスを開始する（ステップＳ１１５）。例えば、制御部１３は、このユーザ端末３０用のサービスメニュー画面をユーザ端末３０の表示部３３に表示させる。以上で、ユーザ端末３０からの初回のログイン等により、秘密鍵を取得できなかった場合（図９、ステップＳ１０４；Ｎｏ）のログイン処理は終了する。

一方、ログイン要求の送信元のユーザ端末３０から秘密鍵を取得できた場合（図９、ステップＳ１０４；Ｙｅｓ）、サーバ１０の制御部１３は、この秘密鍵とステップＳ１０３で作成した利用者コードとサーバ１０の企業コードとを含んだ鍵認証依頼を認証装置２０に送信する（ステップＳ１１６）。

鍵認証依頼を受信した認証装置２０は、依頼された秘密鍵を用いてユーザの認証を行う鍵認証処理を実行する（ステップＳ１１７）。鍵認証処理の詳細について、図１３のフローチャートを用いて説明する。

まず、認証装置２０の制御部２３は、鍵認証依頼に含まれている利用者コードを含むレコードが秘密鍵ＤＢ２２２に登録されているか否かを判別する（ステップＳ２１）。そのようなレコードが登録されていない場合（ステップＳ２１；Ｎｏ）、制御部２３は、秘密鍵は無効と判別して（ステップＳ２２）、鍵認証処理を終了する。

一方、レコードが登録されている場合（ステップＳ２１；Ｙｅｓ）、制御部２３は、そのレコードに含まれている何れかの秘密鍵が、鍵認証依頼に含まれている秘密鍵と一致するか否かを判別する（ステップＳ２３）。秘密鍵が一致しない場合（ステップＳ２３；Ｎｏ）、制御部２３は、秘密鍵は無効と判別して（ステップＳ２２）、鍵認証処理を終了する。

秘密鍵が一致する場合（ステップＳ２３；Ｙｅｓ）、制御部２３は、鍵認証依頼に含まれている企業コードをキーに共通設定ＤＢ２２３を検索して、この企業（サーバ１０）の鍵有効日数を取得する（ステップＳ２４）。

そして、制御部２３は、ステップＳ２３で一致すると判別した秘密鍵の電話認証日を秘密鍵ＤＢ２２２から取得し、電話認証日から現在までの経過日数がステップＳ２４で取得した鍵有効日数以内であるか否かを判別する（ステップＳ２５）。鍵有効日数以内でない場合（ステップＳ２５；Ｎｏ）、制御部２３は、秘密鍵は無効と判別し（ステップＳ２２）、鍵認証処理を終了する。

一方、鍵有効日数以内である場合（ステップＳ２５；Ｙｅｓ）、認証装置２０の制御部２３は、所定桁数の乱数を作成する等して新たな秘密鍵を作成する（ステップＳ２６）。

そして、制御部２３は、ステップＳ２３で一致すると判別した秘密鍵ＤＢ２２２に登録されているレコードの秘密鍵を、ステップＳ２６で作成した秘密鍵に更新する（ステップＳ２７）。以上で鍵認証処理は終了する。

図９に戻り、制御部２３は、鍵認証処理（ステップＳ１１７）で秘密鍵が無効と判別された場合（ステップＳ１１８；Ｙｅｓ）、その旨を鍵認証依頼元のサーバ１０に通知する（ステップＳ１１９）。そして、ログイン時に秘密鍵を取得できなかった場合（ステップＳ１０４；Ｎｏ）と同様に、携帯端末４０の発呼による認証（電話認証）が行われ（図１０、ステップＳ１０５〜Ｓ１１０）、認証できた場合に秘密鍵が更新された後（ステップＳ１１１〜Ｓ１１４）、ユーザ端末３０にサービスが提供される（ステップＳ１１５）。

一方、鍵認証処理で秘密鍵が無効であると判別されなかった場合（図９、ステップＳ１１８；Ｎｏ）、認証装置２０の制御部２３は、鍵認証処理（図１３）のステップＳ２６で作成した秘密鍵をサーバ１０に送信し（図１０、ステップＳ１１２）、サーバ１０の制御部１３は、受信した秘密鍵をログイン要求の送信元のユーザ端末３０に送信する（ステップＳ１１３）。ユーザ端末３０の制御部２３は、サーバ１０から受信した秘密鍵をブラウザ（記憶部３４）に格納する（ステップＳ１１４）。その後、サーバ１０の制御部１３は、ユーザの認証に成功したものとして、ログイン要求の送信元のユーザ端末３０に対するサービスを開始する（ステップＳ１１５）。以上でログイン処理は終了する。

このように、本実施形態によれば、ユーザ端末３０からのサーバ１０へのログインの際に、ユーザ端末３０から秘密鍵を取得できた場合は（ステップＳ１０４；Ｙｅｓ）、秘密鍵を用いた認証（ステップＳ１１７）が行われ、この秘密鍵が有効な場合は（ステップＳ１１８；Ｎｏ）、携帯端末４０からの発呼による認証を必要とせずに、ユーザ端末３０にサービスが提供される（ステップＳ１１５）。一方、ユーザ端末３０からのサーバ１０へのログイン時に、ユーザ端末３０から秘密鍵を取得できなかった場合（ステップＳ１０４；Ｎｏ）、又は取得できたものの秘密鍵が無効である場合（ステップＳ１１８；Ｙｅｓ）、携帯端末４０からの発呼による認証がなされる（ステップＳ１１０）。従って、本発明によれば、有効な秘密鍵がある場合には、ユーザは携帯端末４０から発呼する必要が無いため、ログイン時に常に携帯端末４０からの発呼を必要とする特許文献１記載の発明よりも、ユーザの負担を抑えることが可能となる。

また、本実施形態によれば、ログインして認証に成功する度に、新たな秘密鍵が作成されて、サーバ１０の秘密鍵ＤＢ２２２およびユーザ端末３０のブラウザに保持される秘密鍵が更新されるため、秘密鍵を用いた認証のセキュリティを向上させることができる。

また、本実施形態によれば、サーバ１０が保持するユーザの個人情報が認証装置２０に送信されることはない。具体的には、本実施形態では、携帯端末４０の電話番号の代わりに、電話番号を不可逆に変換した利用者コードが認証装置２０に保持される。そのため、認証装置２０からユーザの個人情報が漏えいする虞も無い。

（実施形態２）
実施形態１では、電話認証をする際に、ユーザが携帯端末４０を直接操作して認証装置２０に発呼する必要があった。実施形態２では、電話認証する際に、ユーザの操作を介さないで自動的に発呼を行うことを特徴とする。

なお、実施形態２に係るサービス提供システム１の構成は基本的に実施形態１と同じである。また、実施形態２では、ユーザ端末３０と携帯端末４０とは、ブルートゥース（登録商標）等の近距離無線規格に対応している。ユーザ端末３０と携帯端末４０とは、事前のペアリング処理により、相互に近距離通信を行うことができる。

また、実施形態２に係る認証装置２０は、複数の自局電話番号を有している。携帯端末４０は、この複数の自局電話番号の何れか宛てに発呼することで、認証装置２０と電話通信することができる。

さらに、実施形態２に係る認証装置２０の記憶部２２に格納されている利用者コードＤＢ２２１は、図１４に示すように、利用者コードと電話認証日時とに加えて、接続番号が記憶されている。接続番号は、上述した認証装置２０の保持する複数の自局電話番号の何れかから選択されたものであり、この接続番号宛に携帯端末４０からの発呼があることを示す。

続いて、実施形態２に係るサービス提供システム１の動作について説明する。なお、ステップＳ１０１〜Ｓ１１６、Ｓ１１７〜Ｓ１１９の処理は実施形態１の動作と実質的に同一であるため、実施形態１と同じ図９に示すフローチャートを用いて説明する。それ以外の処理については、図１５のフローチャートを用いて説明する。また、実施形態１と同じステップについては、同じステップ番号を付し、適宜説明を簡略化し、実施形態２に特有のステップについて重点的に説明する。

ユーザ端末３０からログイン要求が送信されると（ステップＳ１０１）、サーバ１０の制御部１３は、ＩＤとパスワードを用いて認証を行った後（ステップＳ１０２）、顧客ＤＢ１２１から取得したユーザの電話番号から利用者コードを生成する（ステップＳ１０３）。

そして、サーバ１０の制御部１３は、ユーザ端末３０から秘密鍵を取得できない場合（ステップＳ１０４；Ｎｏ）、図１５のステップＳ２０１に処理を移す。図９に戻り、一方、ユーザ端末３０から秘密鍵を取得できた場合（ステップＳ１０４；Ｙｅｓ）、制御部１３は、鍵認証依頼を認証装置２０に送信し、認証装置２０の制御部２３は鍵認証処理を実行し（ステップＳ１１７）、秘密鍵が無効と判別された場合（ステップＳ１１８；Ｙｅｓ）、その旨をサーバ１０に通知し（ステップＳ１１９）、ステップＳ２０１に処理は移る。

図１５のステップＳ２０１において、サーバ１０の制御部１３は、認証装置２０に接続番号取得要求を送信する（ステップＳ２０１）。接続番号取得要求を受信すると認証装置２０の制御部２３は、複数の自局電話番号のなかから１つをランダムに取得する（ステップＳ２０２）。なお、以下の説明では、ステップＳ２０２で取得した番号を接続番号とも呼ぶ。続いて、制御部２３は、取得した接続番号とステップＳ１０３で作成した利用者コードとを対応付けて、利用者コードＤＢ２２１に新規のレコードとして登録する（ステップＳ２０３）。そして、制御部２３は、ステップＳ２０２で取得した接続番号を接続番号取得要求の送信元のサーバ１０に送信する（ステップＳ２０４）。サーバ１０の制御部１３は、受信した接続番号をユーザ端末３０に送信する（ステップＳ２０５）。

ユーザ端末３０の制御部３５は、サーバ１０から受信した接続番号宛てに発呼するよう、近距離無線で携帯端末４０に指示する（ステップＳ２０６）。携帯端末４０は、指示された接続番号宛（即ち認証装置２０）に発呼する。当該指示に従って、携帯端末４０は、指示された接続番号で認証装置２０に発呼する。認証装置２０の制御部２３は、携帯端末４０からの電話着信があると、ステップＳ１０３と同様の手法により、その着信番号から利用者コードを作成する（ステップＳ２０７）。続いて、制御部２３は、この電話着信の接続先の番号（接続番号）と作成した利用者コードとの組を含むレコードが、利用者コードＤＢ２２１に登録されていることを確認するとともに、当該レコードの電話認証日時に現在日時を登録する（ステップＳ２０８）。なお、このようなレコードが確認できない場合は、制御部２３は、エラーとして処理を終了する。ステップＳ２０８での確認を行うことにより、ステップＳ２０４、Ｓ２０５でユーザ端末３０に通知した接続番号による認証装置２０への電話着信の場合しか、認証は成功しないこととなる。

一方、ユーザ端末３０の制御部３５は、携帯端末４０に発呼を指示した後、図１６に示すような電話認証画面を表示部３３に表示する（ステップＳ２０９）。

以降の処理は、実施形態１の処理と同様である。即ち、図１０に移り、ユーザにより図１６の電話認証画面から「電話認証」ボタンがクリックされると、ユーザ端末３０の制御部３５は、電話認証要求をサーバ１０に送信し（ステップＳ１０８）、サーバ１０は電話認証依頼を認証端末に送信し（ステップＳ１０９）、認証装置２０の制御部２３は電話認証処理（ステップＳ１１０）を実行してユーザを認証する。そして、認証に成功すると、制御部２３は、今後の認証用の秘密鍵を作成、登録してサーバ１０経由でユーザ端末３０に送信して格納され（ステップＳ１１１〜Ｓ１１４）、サーバ１０はログイン要求元のユーザ端末３０にサービスを提供する（ステップＳ１１５）。

このように、本実施形態によれば、近接通信によりユーザ端末３０から携帯端末４０に発呼の指示がなされ（ステップＳ２０６）、この指示に基づいて携帯端末４０は認証装置２０へ発呼する。そのため、ユーザの操作を介さないで、自動的に認証装置２０に発呼を行って電話認証することが可能となる。

また、本実施形態によれば、認証装置２０は複数の自局電話番号を有しており、電話認証の度に、その認証で用いる接続番号は変化する。そして、携帯端末４０からの発呼の際に、発呼先の番号と接続番号とが一致しない場合は認証エラーとなるため、セキュリティをより向上させることが可能となる。

（実施形態３）
一般的に、携帯端末４０の電話番号は機器固有の情報であり変更することはできない。そのため、実施形態１、２では、ユーザ端末３０から認証用の秘密鍵を取得できない場合や取得した秘密鍵で認証ができない場合に、携帯端末４０が認証装置２０に発呼し、認証装置２０がその着信電話番号を用いて認証（電話認証）を行った。

一方、日本以外の国（例えば米国）では、任意の電話番号から電話発信できるサービスが知られている。このようなサービスを用いれば、不正なユーザが、電話認証可能な電話番号から認証装置２０に発呼するように偽装して、電話認証ができてしまう可能性がある。本実施形態では、このような不正を防止することを特徴とする。

なお、実施形態３に係るサービス提供システム１の構成は基本的に実施形態１と同じである。また、実施形態３では、サーバ１０の記憶部１２には、図１７に示すような顧客ＤＢ１２１が記憶されている。実施形態１、２と比較して、この顧客ＤＢ１２１には、新たにユーザ毎に、機器識別情報と、機器認証要否フラグと、エラーカウントと、認証許可フラグと、が記憶されている。

機器識別情報は、ＩＭＥＩ（International Mobile Equipment Identity）であり、ユーザの携帯端末４０を一意に識別するための番号（機器ＩＤ）である。なお、機器識別情報は、ＩＭＥＩＳＶ（IMEI Software Version）等であってもよく、携帯端末４０を一意に識別できる情報であれば種々のものが採用可能である。

機器認証要否フラグは、このユーザに対して機器識別情報を用いた認証（機器認証）を行う必要があるか否かを示すフラグである。機器認証要否フラグが「０」の場合は機器認証は不要であり、「１」の場合は機器認証が必要であることを示す。

エラーカウントは、後述する認証処理において、ユーザが入力した機器識別情報が顧客ＤＢ１２１のものと一致しなかった回数を示す。

認証許可フラグは、このユーザに対して認証を行うか否かを示すフラグである。認証許可フラグが「０」の場合は認証を行い、「１」の場合は認証を行わない（エラー終了させる）ことを示す。エラーカウントの値が所定値以上（例えば３以上）となった場合に、認証許可フラグは「１」に更新される。

続いて、実施形態３に係るサービス提供システム１で実施されるログイン処理の動作について説明する。なお、実施形態１のログイン処理と比較して、実施形態３のログイン処理は、電話認証画面をユーザ端末に送信するステップ（図１０のステップＳ１０５）の前に、機器識別情報を用いた認証に関する各ステップが追加された点以外は実質的に同じである。そのため、この追加された部分のみを、図１８のフローチャートを用いて説明し、実施形態１と共通する他の部分の説明については省略する。

ログイン要求が送信されたユーザ端末３０から認証用の秘密鍵を取得できない場合（図９のステップＳ１０４；Ｎｏ）、若しくは、秘密鍵の無効が通知された場合（ステップＳ１１９）、図１８に進み、サーバ１０の制御部１３は、顧客ＤＢ１２１の機器認証要否フラグを参照して、ログインユーザに対して機器認証が必要であるか否かを判別する（ステップＳ３０１）。機器認証が不要であると判別した場合（ステップＳ３０１；Ｎｏ）、図１０のステップＳ１０５に処理は移り、以降は実施形態１の処理と同様である。

一方、機器認証が必要であると判別した場合（ステップＳ３０１；Ｙｅｓ）、サーバ１０の制御部１３は、顧客ＤＢ１２１の認証許可フラグを参照して、ログインユーザの認証が許可されているか（認証許可フラグが「０」であるか）を確認する（ステップＳ３０２）。認証が許可されていない場合、ログインユーザを認証せずに処理は終了する。

認証が許可されていることを確認した後、サーバ１０の制御部１３は、携帯端末４０の機器識別情報（ＩＭＥＩ）を入力させるための製造番号入力画面の画面データをユーザ端末３０に送信し（ステップＳ３０３）、ユーザ端末３０の制御部３５は、図１９に示す製造番号入力画面を表示部３３に表示する（ステップＳ３０４）。

そして、ユーザは、製造番号入力画面の指示に従って、機器識別情報を入力し確認ボタンを押下する。この操作に応答して、ユーザ端末３０の制御部３５は、入力された機器識別情報をサーバ１０に送信する（ステップＳ３０５）。なお、ユーザ端末３０と携帯端末４０とが、ブルートゥース（登録商標）等による近距離無線通信に対応している場合、携帯端末４０が、近距離無線通信により、ユーザ端末３０に自身の機器識別情報を送信し、ユーザ端末３０の制御部３５が受信した機器識別情報をサーバ１０に送信してもよい。

続いて、サーバ１０の制御部１３は、ユーザ端末３０から受信した機器識別情報と、顧客ＤＢ１２１に記憶されているログインユーザの機器識別情報とが一致していることを確認する（ステップＳ３０６）。なお、機器識別情報が一致していない場合、制御部１３は、エラーカウントを１つ加算し、機器識別情報の入力を再度促すメッセージ等をユーザ端末３０に送信する。

機器識別情報の一致を確認した後は、図１０のステップＳ１０５に処理は移り、以降は実施形態１の処理と同様である。即ち、ログインユーザの携帯端末４０から認証装置に発呼がなされて電話認証が行われる。

このように、本実施形態によれば、電話認証を行う前に、サーバ１０は、ユーザ端末３０から取得した携帯端末４０の機器識別情報と顧客ＤＢ１２１に予め登録しているログインユーザの機器識別情報とが一致していることを確認し、一致している場合に限って電話認証を行う。電話番号と異なり、ＩＭＥＩのような機器識別情報は秘匿されている情報であり、第三者が知ることはできない。そのため、本実施形態では、任意の電話番号で電話発信できるサービスを利用した不正も防止することが可能となる。

（変形例）
なお、上述した実施形態は一例であり、種々の変更及び応用が可能である。

例えば、上記各実施形態では、電話番号を利用者コードに変換して電話認証に利用したが、このような変換を行わずに、電話番号を直接用いて、電話認証を行ってもよい。

また、上記各実施形態では、携帯端末４０から認証装置２０に発呼した後、ユーザ端末３０に電話番号認証画面を表示し（図１０、ステップＳ１０６）、この画面から電話認証要求を送信（ステップＳ１０８）した際に、認証装置２０で電話認証（ステップＳ１１０）がなされた。しかしながら、電話番号認証画面を表示せずに、携帯端末４０からの発呼があった際に、即時に電話認証を行ってもよい。

また、認証装置２０とサーバ１０との機能を１つのコンピュータ等で実現してもよい。

また、上記各実施形態では、ユーザ端末３０がサーバにユーザＩＤとパスワードとを含んだログイン要求をサーバ１０に送信した（図９、ステップＳ１０１
）。しかしながら、パスワードを含まないログイン要求をサーバ１０に送信してもよい。この場合、サーバ１０は、ステップＳ１０２において、受信したログイン要求に含まれるユーザＩＤが顧客ＤＢ１２１に登録されていることを確認し、登録されていなければエラーとして終了し、登録されていればステップＳ１０３に進めばよい。

また、上記各実施形態では、サービス提供システム１は、ユーザ端末３０からサービスのログイン要求を受け付けた後、ユーザの認証を行い、認証に成功するとユーザ端末３０にサービスを提供した。しかしながら、携帯端末４０がインターネットＮ１に接続する機能を有する場合には、携帯端末４０からサービスのログイン要求を受け付け、認証を行い、認証に成功した場合に携帯端末４０にサービスを提供してもよい。この場合のシステムの全体構成を図２０に示す。この場合、携帯端末４０は、図１に示すユーザ端末３０の機能も兼ね、携帯端末４０の記憶部には、認証装置２０から受信した秘密鍵が記憶される。

続いて、この場合の認証処理の動作について概略を説明する。まず、携帯端末４０からサービスへのログイン要求がインターネットＮ１を介してサーバ１０に送信される。ログイン要求を受信すると、サーバ１０は、ログイン要求に含まれるＩＤとパスワードとを用いて認証を行う。この認証に成功した後、携帯端末４０から秘密鍵を取得できた場合、認証装置２０が取得した秘密鍵に基づいて鍵認証処理を行う。また、携帯端末４０から秘密鍵を取得できない場合や鍵認証処理で認証に失敗した場合、携帯端末４０から認証装置２０に発呼がなされ、認証装置２０が、その着信電話番号に基づいて電話認証処理を行う。そして、鍵認証処理又は電話認証処理に成功すると、携帯端末４０においてサービスを提供するための処理（例えば、サービスへのログイン）がなされる。

また、上記各実施形態では、ユーザ端末３０に保持される秘密鍵をサーバ１０へのログインの認証に利用したが、秘密鍵を他の用途に利用してもよい。例えば、ユーザ端末３０がサーバ１０にデータを送信する際に、保持している秘密鍵でこのデータを暗号化してサーバに送信してもよい。そして、サーバ１０は、認証装置２０から対応する秘密鍵を取得して、受信したデータを取得した秘密鍵で復号すればよい。

本各実施形態に係る認証装置２０やサーバ１０は、専用のシステムにより実現してもよいし、通常のコンピュータシステムにより実現してもよい。例えば、上述の動作を実行するためのプログラムをコンピュータ読み取り可能な記録媒体に格納して配布し、該プログラムをコンピュータにインストールして、上述の処理を実行することによって認証装置２０やサーバ１０を構成してもよい。また、上記プログラムをインターネットＮ１等のネットワーク上のサーバ１０装置が備えるディスク装置に格納しておき、コンピュータにダウンロード等できるようにしてもよい。また、上述の機能を、ＯＳとアプリケーションソフトとの協働により実現してもよい。この場合には、ＯＳ以外の部分を媒体に格納して配布してもよいし、ＯＳ以外の部分をサーバ１０装置に格納しておき、コンピュータにダウンロード等できるようにしてもよい。

本発明は、本発明の広義の精神と範囲を逸脱することなく、様々な実施の形態及び変形が可能とされるものである。また、上述した実施形態は、本発明を説明するためのものであり、本発明の範囲を限定するものではない。つまり、本発明の範囲は、実施の形態ではなく、特許請求の範囲によって示される。そして、特許請求の範囲内及びそれと同等の発明の意義の範囲内で施される様々な変形が、本発明の範囲内とみなされる。

本出願は、２０１６年２月５日に出願された、日本国特許出願２０１６−０２０６６９号に基づく。本明細書中に日本国特許出願２０１６−０２０６６９号の明細書、特許請求の範囲、図面全体を参照として取り込むものとする。

本発明は、インターネットを利用した各種サービスに好適に利用される。

１ サービス提供システム、１０ サーバ、１１ 通信部、１２ 記憶部、１２１ 顧客ＤＢ、１３ 制御部、２０ 認証装置、２１ 通信部、２２ 記憶部、２２１ 利用者コードＤＢ、２２２ 秘密鍵ＤＢ、２２３ 共通設定ＤＢ、２３ 制御部、２３１ 鍵認証部、２３２ 電話認証部、３０ ユーザ端末、３１ 通信部、３２ 入力部、３３ 表示部、３４ 記憶部、３５ 制御部、４０ 携帯端末、Ｎ１ インターネット、Ｎ２ 電話網、Ｎ３ 専用線

Claims (11)

1. ユーザが操作するユーザ端末からサービスのログイン要求を受信するログイン要求受信部と、
   前記ユーザ端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部と、
   前記ユーザ端末から前記秘密鍵を取得できない場合、又は前記鍵認証部で認証に失敗した場合、前記ユーザに関連付けられている携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部と、
   前記鍵認証部又は前記電話認証部で認証に成功した場合に、ログイン要求の送信元のユーザ端末に対して前記サービスを提供するための処理を実行するサービス提供部と、
   を備えるサービス提供システム。
2. 前記鍵認証部又は前記電話認証部で認証に成功した場合に、前記ユーザの認証用の秘密鍵を新たに作成して前記サービス提供システムで保持するとともに、作成した前記秘密鍵を前記ユーザ端末に送信する秘密鍵送信部を備える、
   請求項１に記載のサービス提供システム。
3. 前記電話認証部は、前記携帯端末からの電話着信を受信後、前記ユーザ端末からの電話認証依頼があった場合に認証を行う、
   請求項１又は２に記載のサービス提供システム。
4. 前記電話認証部は、前記携帯端末からの電話着信を受信後に、予め定めた待ち時間以内に前記電話認証依頼が無かった場合、ユーザを認証しない、
   請求項３に記載のサービス提供システム。
5. 前記電話認証部は、
   前記ユーザ端末に複数の自局電話番号の中から選択した接続番号を通知し、
   前記携帯端末からの電話着信の着信先の電話番号が通知した接続番号と一致しない場合はユーザを認証しない、
   請求項１から４の何れか１項に記載のサービス提供システム。
6. 前記電話認証部は、前記携帯端末の機器識別情報を前記ユーザ端末から取得し、予め記憶している対応する機器識別情報と一致する場合は前記電話着信に基づいて前記ユーザの認証を行い、一致しない場合は前記ユーザの認証を行わない、
   請求項１から５の何れか１項に記載のサービス提供システム。
7. ユーザが操作する携帯端末からサービスのログイン要求を受信するログイン要求受信部と、
   前記携帯端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部と、
   前記携帯端末から前記秘密鍵を取得できない場合、又は前記鍵認証部で認証に失敗した場合、前記携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部と、
   前記鍵認証部又は前記電話認証部で認証に成功した場合に、前記携帯端末に対して前記サービスを提供するための処理を実行するサービス提供部と、
   を備えるサービス提供システム。
8. ネットワークを介してユーザが操作するユーザ端末にサービスを提供するサーバに接続された認証装置であって、
   前記サーバが前記ユーザ端末からサービスのログイン要求を受信した際に前記ユーザ端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部と、
   前記秘密鍵を取得できなかった場合、又は前記鍵認証部で認証できなかった場合、前記ユーザに関連付けられている携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部と、
   を備える認証装置。
9. ネットワークを介してユーザが操作する携帯端末にサービスを提供するサーバに接続された認証装置であって、
   前記サーバが前記携帯端末からサービスのログイン要求を受信した際に前記携帯端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部と、
   前記秘密鍵を取得できなかった場合、又は前記鍵認証部で認証できなかった場合、前記携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部と、
   を備える認証装置。
10. ネットワークを介してユーザが操作するユーザ端末にサービスを提供するサーバに接続されたコンピュータを、
    前記サーバが前記ユーザ端末からサービスのログイン要求を受信した際に前記ユーザ端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部、
    前記秘密鍵を取得できなかった場合、又は前記鍵認証部で認証できなかった場合、前記ユーザに関連付けられている携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部、
    として機能させるプログラム。
11. ネットワークを介してユーザが操作する携帯端末にサービスを提供するサーバに接続されたコンピュータを、
    前記サーバが前記携帯端末からサービスのログイン要求を受信した際に前記携帯端末から認証用の秘密鍵を取得できた場合、取得した前記秘密鍵と予め保持している秘密鍵とに基づいて、前記ユーザの認証を行う鍵認証部、
    前記秘密鍵を取得できなかった場合、又は前記鍵認証部で認証できなかった場合、前記携帯端末からの電話着信に基づいて、前記ユーザの認証を行う電話認証部、
    として機能させるプログラム。

Images