[1.実施形態1]
以下、本発明に係る認証システムの第1の実施形態(以降、実施形態1)の例を説明する。
[1−1.認証システムの全体構成]
図1は、実施形態1の認証システムの全体構成を示す図である。図1に示すように、認証システムSは、サーバ10、ユーザ端末20、及び認証装置30を含み、これらは、インターネットなどのネットワークNに接続可能である。なお、図1では、サーバ10、ユーザ端末20、及び認証装置30の各々を1台ずつ示しているが、これらは複数台あってもよい。
サーバ10は、サーバコンピュータである。サーバ10は、制御部11、記憶部12、及び通信部13を含む。制御部11は、少なくとも一つのプロセッサを含む。制御部11は、記憶部12に記憶されたプログラムやデータに従って処理を実行する。記憶部12は、主記憶部及び補助記憶部を含む。例えば、主記憶部はRAMなどの揮発性メモリであり、補助記憶部は、ROM、EEPROM、フラッシュメモリ、又はハードディスクなどの不揮発性メモリである。通信部13は、有線通信又は無線通信用の通信インタフェースであり、ネットワークNを介してデータ通信を行う。
ユーザ端末20は、ユーザが操作するコンピュータである。例えば、ユーザ端末20は、携帯電話機(スマートフォンを含む)、携帯情報端末(タブレット型コンピュータ及びウェアラブル端末を含む)、又は、パーソナルコンピュータ等である。本実施形態では、ユーザ端末20は、制御部21、記憶部22、通信部23、操作部24、表示部25、及び撮影部26を含む。制御部21、記憶部22、及び通信部23の物理的構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。
操作部24は、入力デバイスであり、例えば、タッチパネルやマウス等のポインティングデバイス、キーボード、又はボタン等である。操作部24は、操作内容を制御部21に伝達する。表示部25は、例えば、液晶表示部又は有機EL表示部等である。表示部25は、制御部21の指示に従って画像を表示する。
撮影部26は、少なくとも1台のカメラを含む。例えば、撮影部26は、CCDイメージセンサやCMOSイメージセンサなどの撮像素子を含み、当該撮像素子が撮影した画像をデジタルデータとして記録する。画像は、静止画であってもよいし、所定のフレームレートで連続的に撮影された動画であってもよい。
認証装置30は、認証に使用されるコンピュータである。例えば、認証装置30は、携帯電話機、携帯情報端末、又は、パーソナルコンピュータ等である。本実施形態では、認証装置30は、制御部31、記憶部32、通信部33、操作部34、表示部35、及び撮影部36を含む。制御部31、記憶部32、通信部33、操作部34、表示部35、及び撮影部36の物理的構成は、それぞれ制御部11、記憶部12、通信部13、操作部24、表示部25、及び撮影部26と同様であってよい。
なお、記憶部12,22,32に記憶されるものとして説明するプログラム及びデータは、ネットワークNを介して供給されるようにしてもよい。また、上記説明した各コンピュータのハードウェア構成は、上記の例に限られず、種々のハードウェアを適用可能である。例えば、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部(例えば、光ディスクドライブやメモリカードスロット)や外部機器とデータの入出力をするための入出力部(例えば、USBポート)が含まれていてもよい。例えば、情報記憶媒体に記憶されたプログラムやデータが読取部や入出力部を介して、各コンピュータに供給されるようにしてもよい。
[1−2.認証システムの概要]
認証システムSは、任意の場面においてユーザの正当性を確認するために、認証を実行する。認証は、ユーザが所定の資格を有するか否かを確認する行為であり、相手認証又は本人認証と呼ばれることもある。認証システムSは、種々のタイプの認証を実行可能であり、例えば、生体認証、パスコード認証、パスワード認証、電子スタンプ認証、又は合言葉認証を実行可能である。
生体認証は、人間の身体的特徴又は行動的特徴を利用する認証方法である。例えば、身体的特徴を利用する生体認証には、顔認証、指紋認証、DNA認証、掌形認証、網膜認証、虹彩認証、静脈認証、又は音声認証がある。また例えば、行動的特徴を利用する生体認証には、筆跡認証、キーストローク認証、リップムーブメント認証、まばたき認証、又は歩行認証がある。
本実施形態では、ユーザがセキュリティゲートを通過する場面を例に挙げて、認証システムSの処理を説明する。なお、認証システムSは、後述する変形例のように、種々の場面に適用可能であり、認証システムSが適用される場面は、本実施形態の例に限られない。
図2は、認証システムSが利用される場面の一例を示す図である。図2に示すように、セキュリティゲートSGは、回転式のドアを含み、認証装置30が接続されている。セキュリティゲートSGのドアは、ロック機構によりロックされており、ユーザの認証が成功すると、ロックが解除される。ロックが解除されると、ユーザはドアを押して通過することができる。ドアは、所定角度だけ回転すると再びロックされる。なお、ドアは、開閉式であってもよいし、電子錠によって開閉が制御されてもよい。
例えば、セキュリティゲートSGは、勤務先の会社や公共施設などの任意の施設に配置され、入場する資格を有する者だけが通過することができる。一般的には、カードキーを利用したセキュリティゲートが主流であるが、ユーザがカードキーを紛失すると、カードキーを取得した第三者が、ユーザに成りすましてセキュリティゲートを通過する可能性がある。
この点、生体認証を利用すれば、カードキーのように紛失する心配はなくなる。しかし、従来技術で説明したように、生体認証は、顔などの完全一致までは要求されず、類似によって成否が決まるので、例えば、ユーザと顔が似ている他人が、ユーザに成りすましてセキュリティゲートを通過する可能性がある。
この点、生体認証と、パスコード認証などの他の認証と、を組み合わせて二段階の認証とすれば、顔認証だけを利用する場合に比べてセキュリティが向上する。しかしながら、パスコードは、比較的短い情報(例えば、4桁の数字)であり、互いに顔が似ている複数のユーザが、偶然同じパスコードを使用することもある。この場合、あるユーザAが、顔が似ており同じパスコードを使用する別のユーザBとして認証されてしまい、ユーザAがユーザBに成りすましてセキュリティゲートを通過する可能性がある。
そこで、認証システムSは、互いに顔が似ている複数のユーザの各々が、互いに同じパスコードを使用している場合に、電話番号やメールアドレスなどのユーザ情報の違いに基づく追加認証をすることによって、上記のような成りすましを防止している。
追加認証は、通常の認証に加えて行われる認証である。通常の認証は、全てのユーザに対して毎回行われる認証であり、追加認証は、特定のユーザに対して行われる認証、又は、毎回は行われない認証である。追加認証は、通常の認証よりも頻度が低く、通常の認証の後に行われる。本実施形態では、通常の認証が生体認証とパスコード認証の二段階の認証であり、追加認証が行われると、合計で三段階の認証が行われる場合を説明する。なお、認証の段階数は、本実施形態の例に限られず、任意の段階数であってよい。例えば、通常の認証は、一段階であってもよいし、三段階以上であってもよい。同様に、追加認証は、二段階以上であってもよい。
ユーザ情報は、ユーザに関する情報である。別の言い方をすれば、ユーザ情報は、ユーザが認証システムSに登録した情報である。認証情報もユーザに関する何らかの情報ということができるが、本実施形態では、ユーザ情報は、認証情報とは異なる情報を意味する。例えば、ユーザを一意に識別するユーザ識別情報、ユーザの個人情報、ユーザの決済情報、又はユーザの嗜好情報は、ユーザ情報に相当する。本実施形態では、ユーザの個人情報がユーザ情報に相当する場合を説明し、更にその一例として、電話番号とメールアドレスについて説明する。このため、本実施形態で電話番号又はメールアドレスについて説明している箇所は、ユーザ情報と読み替えることができる。なお、ユーザ情報は、電話番号とメールアドレスに限られず、例えば、氏名、住所、生年月日、又はニックネームといった他の情報であってよい。
本実施形態では、ユーザは、認証システムSが提供する認証サービスを利用するにあたり、所定の利用登録を行う。利用登録は、ユーザが自ら行うのではなく、書類上で利用登録の申請が行われて、オペレータなどの操作によってユーザ情報が登録されてもよい。例えば、まだ利用登録をしていない新規のユーザがユーザ端末20を操作してサーバ10にアクセスすると、利用登録をするための登録申請画面がユーザ端末20の表示部25に表示される。
図3は、登録申請画面の一例を示す図である。登録申請画面は、ユーザが利用登録を申請するための画面である。図3に示すように、登録申請画面G1には、希望するユーザIDを入力するための入力フォームF10、パスワードを入力するための入力フォームF11、顔写真をアップロードするための入力フォームF12、パスコードを入力するための入力フォームF13、電話番号を入力するための入力フォームF14、及びメールアドレスを入力するための入力フォームF15等が表示される。
ユーザIDは、ユーザ識別情報の一例であり、ユーザアカウントと呼ばれることもある。パスワードは、ユーザが指定した任意の長さの記号列であり、上記説明したパスコードとは異なる情報である。記号とは、数字と文字の両方を意味する。本実施形態では、パスワードは、セキュリティゲートSGを通過するために利用されるのではなく、自身の登録情報の変更などの他の目的で利用される。
本実施形態では、ユーザ端末20の記憶部22にユーザの顔写真が記憶されており、ユーザは、入力フォームF12に顔写真のファイル名を入力して、アップロードする顔写真を指定する。即ち、ユーザは、入力フォームF12に、顔認証で用いる顔写真を指定する。なお、説明の簡略化のために、顔写真を1枚だけ登録する場合を説明するが、複数の顔写真が登録されてもよい。また、ユーザは、撮影部26を起動して、その場で顔写真を撮影してもよい。
また、本実施形態では、ユーザが入力フォームF13に4桁のパスコードを入力する場合を説明するが、パスコードは、任意の桁数であってよい。例えば、1桁〜3桁又は5桁以上であってもよい。また例えば、全ユーザでパスコードの桁数が同じであってもよいし、ユーザごとに任意の桁数のパスコードが設定できてもよい。ユーザが、入力フォームF10〜F15の各々に情報を入力して所定の操作をすると、利用登録が完了し、登録完了画面が表示部25に表示される。
図4は、登録完了画面の一例を示す図である。図4に示すように、登録完了画面G2には、利用登録が完了したことを示すメッセージとともに、登録申請をしたユーザのユーザID、氏名、顔写真、パスコード、電話番号、及びメールアドレスが表示される。利用登録が完了すると、ユーザは、セキュリティゲートSGを通過するための認証サービスを受けることができるようになる。
図5は、ユーザがセキュリティゲートSGを通過する様子を示す図である。図5に示すように、ユーザは、認証装置30の表示部35に表示された案内に従い、撮影部36に自身の顔を撮影させる。例えば、表示部35の表示領域A35には、撮影部36により撮影された画像が表示される。ユーザは、操作部34を操作して、表示部35に表示された入力フォームF35aに、自身のパスコードを入力する。
ユーザがボタンB35aを選択すると、撮影部36により撮影された画像と、入力フォームF35aに入力されたパスコードと、がサーバ10に送信され、顔認証とパスコード認証が実行される。図5に示すように、これら2つの認証が成功すると、セキュリティゲートSGのロックが解除され、ユーザは、セキュリティゲートSGを通過することができる。
一方、顔が似た他のユーザが同じパスコードを使用している場合、当該他のユーザとして認証されてしまい、セキュリティゲートSGの前にいるユーザが、当該他のユーザに成りすまして通過してしまう可能性がある。このため、本実施形態では、電話番号又はメールアドレスのうち、顔が似ており同じパスコードを使用する他のユーザとは異なる部分を追加認証で入力させるようにしている。
図6は、追加認証が行われる様子を示す図である。図6に示すように、顔が似た他のユーザが同じパスコードを使用している場合、認証装置30の表示部35には、追加認証を行うことを示すメッセージが表示される。この場合、顔認証とパスコード認証が成功したユーザが複数人存在し、追加認証によって、セキュリティゲートSGを通過しようとしているユーザが識別される。追加認証が成功するまで、セキュリティゲートSGは、ロックされたままとなる。
図6に示すように、表示部35には、追加認証においてユーザが入力すべき内容が表示される。本実施形態では、追加認証において、電話番号の一部の入力が要求されることもあれば、メールアドレスの一部の入力が要求されることもある。図6の例では、セキュリティゲートSGを通過しようとしているユーザは、顔が似ており同じパスコードを使用する他のユーザと電話番号の下3桁が異なっている。このため、追加認証では、誰がセキュリティゲートSGを通過しようとしているかを識別するために、電話番号の下3桁の入力が要求されている。
ユーザは、表示部35に表示された追加認証の案内に従い、入力フォームF35bに、自身の電話番号の下3桁を入力する。ユーザがボタンB35bを選択すると、入力フォームF35bに入力された電話番号の下3桁がサーバ10に送信され、追加認証が実行される。追加認証が成功すると、セキュリティゲートSGのロックが解除され、ユーザは、セキュリティゲートSGを通過することができる。
なお、追加認証で要求される情報が複雑すぎると、ユーザは、その情報を思い出すことができなかったり、誤入力したりすることがある。このため、追加認証では、ユーザビリティを高めるために、比較的シンプルな情報を入力させるようにしている。一方、追加認証で要求される情報がシンプルすぎると、セキュリティが低下するので、ある程度の情報量は入力させるようにしている。追加認証のしやすさとセキュリティは、トレードオフの関係にあるので、本実施形態では、これらのバランスを取るために、例えば、2桁〜4桁程度の数字又は記号を入力させるようにしている。
以上のように、本実施形態の認証システムSは、互いに顔が似ている複数のユーザが互いに同じパスコードを使用している場合に、これら複数のユーザの間で電話番号やメールアドレスが異なる部分を入力させて追加認証を行うことによって、セキュリティを十分に高めるようにしている。以降、この技術の詳細を説明する。
[1−3.認証システムにおいて実現される機能]
図7は、本実施形態の認証システムSで実現される機能の一例を示す機能ブロック図である。ここでは、サーバ10、ユーザ端末20、及び認証装置30の各々で実現される機能を説明する。
[1−3−1.サーバにおいて実現される機能]
図7に示すように、サーバ10では、データ記憶部100、認証部101、判定部102、生成部103、入力要求部104、追加認証部105、変更要求部106、及び処理実行部107が実現される。
[データ記憶部]
データ記憶部100は、記憶部12を主として実現される。データ記憶部100は、認証に必要なデータを記憶する。ここでは、データ記憶部100が記憶するデータの一例として、ユーザに関する各種情報が格納されたユーザデータベースDBについて説明する。
図8は、ユーザデータベースDBのデータ格納例を示す図である。図8に示すように、ユーザデータベースDBには、ユーザID、ユーザの氏名、パスワード、アップロードされた顔写真のデータ、顔写真から計算された顔の特徴量、パスコード、パスコードの登録日時、電話番号、及びメールアドレス等が格納される。ユーザデータベースDBに格納されるこれらの情報は、ユーザ情報の一例である。
例えば、ユーザが利用登録をすると、ユーザデータベースDBに新たなレコードが作成される。新たなレコードには、ユーザIDに関連付けて、氏名、パスワード、パスコード、パスコードの登録日時、電話番号、メールアドレス、顔写真、及び当該顔写真に基づいて計算された特徴量が格納される。なお、ユーザが自らユーザIDを指定しない場合には、サーバ10は、ユーザIDを新たに発行する。
ユーザデータベースDBに格納されるパスワード、顔の特徴量、及びパスコードは、認証情報の一種である。電話番号及びメールアドレスについても、追加認証で利用されることがあるので、認証情報の一種といえる。
認証情報とは、認証時に参照される情報である。認証情報は、認証時の正解又はインデックスとなる情報ということもできる。認証情報は、認証方法によって呼び名が異なる。例えば、電子スタンプ認証であれば、スタンプのマルチタッチパターンが認証情報となり、合言葉認証であれば、合言葉が認証情報となる。認証情報は、任意の目的で利用されてよい。本実施形態では、パスワードは、ユーザが登録申請をしたり登録済みの情報を編集したりするために利用され、顔の特徴量、パスコード、電話番号、及びメールアドレスは、ユーザがセキュリティゲートを通過するために利用される。なお、顔写真が認証情報に相当してもよい。
顔の特徴量は、顔の特徴を数値化した情報であり、例えば、顔のパーツの相対位置、大きさ、又は形状などの特徴が示されている。本実施形態では、顔写真が示す顔の特徴量を予め計算しておくものとするが、顔の特徴量は、認証時にその場で計算されてもよい。複数の顔写真が登録される場合には、顔写真ごとに、顔の特徴量が計算される。顔認証自体は、種々の手法を適用可能であり、例えば、主成分分析、線形判別分析、弾性マッチング、又は隠れマルコフモデルといった手法を利用可能であり、特徴量は、これらの手法に応じた計算式で計算されるようにすればよい。例えば、顔の特徴量は、多次元のベクトルで示されるものとするが、配列や単一の数値といった他の形式で示されてもよい。
パスコードは、先述したように、認証のために用いられる所定桁数の番号である。パスコードは、PIN(Personal Identification Number)又は暗証番号と呼ばれることもある。パスコードとパスワードは、似た概念であるが、パスコードが数字のみから構成されるのに対し、パスワードは、任意の種類の記号によって構成される点で異なる。また、本実施形態では、パスコードは、桁数が決められているのに対し、パスワードは、任意の桁数で設定可能な点でも異なる。パスコードは、桁数が決められていなくてもよい。
なお、ユーザデータベースDBに格納される情報は、図8の例に限られず、ユーザに関する任意の情報が格納されてよい。例えば、ユーザの生年月日、住所、クレジットカード番号、又は銀行口座の番号といった任意のユーザ情報がユーザデータベースDBに格納されてよい。
[認証部]
認証部101は、制御部11を主として実現される。認証部101は、入力された認証情報に基づいて、認証をする。本実施形態では、ユーザデータベースDBに認証情報が予め登録されており、認証部101は、入力された認証情報と、登録された認証情報と、に基づいて、認証をする。
入力された認証情報とは、認証時にコンピュータに対して入力された認証情報である。別の言い方をすれば、入力された認証情報は、登録された認証情報と比較される情報、又は、認証時のクエリとなる情報ということもできる。入力された認証情報は、ユーザの操作により入力された認証情報であってもよいし、撮影部36などのセンサの検出結果により入力された認証情報であってもよい。本実施形態では、撮影部36の撮影画像が示す顔の特徴量、入力フォームF35aに対して入力されたパスコード、及び入力フォームF35bに対して入力された電話番号又はメールアドレスの一部の各々は、入力された認証情報の一例である。
登録された認証情報とは、予め登録された認証情報であり、認証時の正解となりうる認証情報である。別の言い方をすれば、登録された認証情報は、入力された認証情報と比較される情報であり、認証時のインデックスとなる情報である。本実施形態では、ユーザデータベースDBに格納された顔の特徴量、パスコード、電話番号、及びメールアドレスの各々は、登録された認証情報の一例である。
例えば、認証部101は、入力された認証情報と登録された認証情報とが一致又は類似するか否かを判定することによって、認証を行う。認証部101は、入力された認証情報と登録された認証情報とが一致又は類似しない場合には、認証が成功しないと判定し、入力された認証情報と登録された認証情報とが一致又は類似する場合に、認証が成功したと判定する。
一致とは、入力された認証情報と、登録された認証情報と、が同一であることを意味する。ここでの一致は、部分一致ではなく、完全一致を意味する。このため、認証情報の一致が判定される場合には、認証情報が一部でも異なっていれば、認証が成功しない。例えば、パスワード認証では、パスワードの一致が判定される。
類似とは、入力された認証情報と、登録された認証情報と、が似ているか否かである。別の言い方をすれば、類似とは、入力された認証情報と、登録された認証情報と、の差又は違いである。例えば、生体認証では、生体認証情報の類似が判定される。生体認証では、特徴量化された認証情報が利用されるので、特徴量の差(距離)が閾値未満であれば類似となり、差が閾値以上であれば非類似となる。
本実施形態では、認証部101は、第1認証部101aと第2認証部101bを含み、認証情報の一致と類似の両方を利用した二段階の認証が実行される場合を説明するが、認証部101は、一段階だけの認証を行ってもよく、認証情報の一致又は類似の何れか一方だけを利用して認証してもよい。この場合、第1認証部101aと第2認証部101bに分かれていなくてもよい。
[第1認証部]
第1認証部101aは、入力された第1の認証情報と、登録された第1の認証情報と、の類似に基づいて、第1の認証を行う。
第1の認証情報とは、第1の認証で利用される認証情報である。第1の認証は、認証情報の類似に基づく認証である。第1の認証では、入力された認証情報と、登録された認証情報と、に基づいて、類似度が計算される。類似度とは、類似の程度を示す指標である。別の言い方をすれば、類似度とは、認証情報の差又は違いの小ささを示す指標である。類似度が高いほど、認証情報が類似していることを示し、類似度が小さいほど、認証情報が類似していないことを示す。類似度は、認証情報が類似する蓋然性ということもできる。類似度は、0%〜100%の間のパーセンテージで示されてもよいし、ベクトル空間上の距離などの他の数値で示されてもよい。
本実施形態では、第1の認証情報が生体認証情報であり、第1の認証が生体認証である場合を例に挙げて説明する。更に、生体認証情報の具体例として顔の特徴量を説明し、生体認証の具体例として顔認証を説明する。このため、本実施形態で顔の特徴量と記載した箇所は、第1の認証情報又は生体認証情報と読み替えることができ、顔認証と記載した箇所は、第1の認証又は生体認証と読み替えることができる。
第1認証部101aは、入力された顔の特徴量と、登録された顔の特徴量と、の類似に基づいて、顔認証をする。例えば、認証装置30によってユーザの顔が撮影される場合、第1認証部101aは、認証装置30により撮影された画像に基づいて、入力された顔の特徴量を計算する。また、第1認証部101aは、ユーザデータベースDBを参照し、登録された顔の特徴量を取得する。第1認証部101aは、入力された顔の特徴量と、登録された顔の特徴量と、が類似する場合に認証成功と判定し、これらが類似しない場合に認証失敗と判定する。
第1認証部101aは、これらの特徴量の差(例えば、特徴量が示すベクトル同士の距離)の逆数を類似度としてもよいし、これらの特徴量を所定の計算式(例えば、特徴量が示すベクトルの要素ごとに重み付けをした計算式)に代入することで類似度を計算してもよい。本実施形態では、特徴量の差が小さいほど類似度は高くなり、特徴量の差が大きいほど類似度が小さくなる。第1認証部101aは、類似度が閾値以上の場合に認証成功と判定し、類似度が閾値未満の場合に認証失敗と判定する。
なお、第1の認証情報として、顔の特徴量ではなく、顔写真そのものを利用する場合には、第1認証部101aは、入力された顔写真と、登録された顔写真と、の類似度を計算してもよい。画像同士の類似度を計算する方法自体は、種々の手法を適用可能であり、例えば、画像内の画素の画素値の差を計算する方法を利用してもよいし 、機械学習における類似度計算を利用してもよい。
本実施形態では、第1認証部101aは、類似に関する第1の基準に基づいて、類否を判定する。
類似に関する基準とは、類似に基づく認証の成否を判定する基準である。別の言い方をすれば、類似に関する基準は、どの程度類似していれば認証を成功/失敗とするかの閾値である。本実施形態のように類似度に基づいて認証の成否が判定される場合には、類似度の閾値である。第1の基準は、後述する第2の基準よりも厳しい基準である。厳しい基準とは、認証が成功しにくい基準である。本実施形態のように、類似度が用いられる場合には、第1の基準は、類似度の閾値であり、後述する第2の基準よりも大きい閾値である。
第1認証部101aは、第1の基準を満たす場合には類似と判定し、第1の基準を満たさない場合には非類似と判定する。第1の基準を満たすことは、類似度が閾値以上であることを意味し、第1の基準を満たさないことは、類似度が閾値未満であることを意味する。例えば、第1認証部101aは、上記計算した類似度が第1の閾値以上であれば類似と判定し、類似度が第1の閾値未満であれば非類似と判定する。
なお、第1の認証である顔認証では、ユーザデータベースDBに登録された全ての顔の特徴量が比較対象となってもよいが、本実施形態では、第1認証部101aは、ユーザデータベースDBに登録された顔の特徴量の中から、入力されたパスコードと一致するユーザの顔の特徴量を抽出する。即ち、本実施形態では、第2の認証であるパスコード認証が先に実行され、第1の認証で比較対象とする顔の特徴量が絞り込まれた後に、第1の認証である生体認証が実行される。
第1認証部101aは、ユーザデータベースDBのうち、上記抽出した顔の特徴量を、入力された顔の特徴量との比較対象とする。即ち、第1認証部101aは、ユーザデータベースDBのうち、入力されたパスコードと一致するレコードを、入力された顔の特徴量との比較対象にする。また、認証時にユーザにユーザID又は氏名を入力させてもよく、この場合には、第1認証部101aは、当該入力されたユーザID又は氏名に関連付けられた顔の特徴量だけを比較対象としてもよい。
[第2認証部]
第2認証部101bは、入力された第2の認証情報と、登録された第2の認証情報と、の一致に基づいて、第2の認証をする。
第2の認証情報とは、第2の認証で利用される認証情報である。第2の認証は、認証情報の一致に基づく認証である。本実施形態では、第2の認証情報が所定桁数のパスコードであり、第2の認証がパスコード認証である場合を例に挙げて説明する。このため、本実施形態でパスコードと記載した箇所は、第2の認証情報と読み替えることができ、パスコード認証と記載した箇所は、第2の認証と読み替えることができる。
第2認証部101bは、入力されたパスコードと、登録されたパスコードと、の一致に基づいて、パスコード認証をする。第2認証部101bは、これらが一致する場合には認証成功と判定し、これらが一致しない場合に認証失敗と判定する。
本実施形態では、パスコード認証を先に実行して、顔認証における比較対象となる顔の特徴量が絞り込まれるので、ユーザデータベースDBに登録された全てのパスコードが比較対象となる。このため、第2認証部101bは、入力されたパスコードと一致するパスコードが格納された全てのレコードを特定する。第2認証部101bは、入力されたパスコードと一致するレコードが見つからなければ、認証失敗と判定し、入力されたパスコードと一致するレコードが1つでも見つかれば、認証成功と判定する。認証成功した場合に発見したレコードに格納された顔の特徴量は、顔認証における比較対象となる。
なお、本実施形態とは逆に、第1の認証である生体認証が先に実行され、第2の認証であるパスコード認証が後に実行されてもよい。この場合、ユーザデータベースDBに登録された全ての顔の特徴量が、生体認証における比較対象となり、パスコード認証における比較対象となるパスコードが絞り込まれる。この場合、生体認証が成功したと判定されたレコードに格納されたパスコードだけが、パスコード認証における比較対象となる。
[判定部]
判定部102は、制御部11を主として実現される。判定部102は、入力された認証情報に基づいて、認証が成功する可能性のある複数のユーザが存在するか否かを判定する。
認証が成功する可能性のあるユーザとは、入力された認証情報と、登録された認証情報と、が一致又は類似するユーザである。別の言い方をすれば、認証が成功する可能性のあるユーザは、入力された認証情報が、認証が成功する基準を満たす可能性のあるユーザである。判定部102は、入力された認証情報と、ユーザデータベースDBと、に基づいて、認証が成功する可能性のあるユーザが複数人いるか否かを判定する。
例えば、認証情報の類否に基づいて認証の成否が決定される場合、上記複数のユーザの各々は、入力された認証情報と、登録された認証情報と、が類似するユーザである。判定部102は、入力された認証情報と、登録された認証情報と、が類似するレコードがユーザデータベースDBに複数個存在するか否かを判定する。当該レコードが複数個存在することは、認証が成功する可能性のある複数のユーザが存在することを意味する。
また例えば、認証情報の一致に基づいて認証の成否が決定される場合、認証が成功する可能性のある複数のユーザの各々は、入力された認証情報と、登録された認証情報と、が一致するユーザである。判定部102は、入力された認証情報と、登録された認証情報と、が一致するレコードがユーザデータベースDBに複数個存在するか否かを判定する。当該レコードが複数個存在することは、認証が成功する可能性のある複数のユーザが存在することを意味する。
本実施形態では、顔の特徴量の類否とパスコードの一致の2つの判定が行われるので、認証が成功する可能性のある複数のユーザの各々は、入力された顔の特徴量と登録された顔の特徴量とが類似し、かつ、入力されたパスコードと登録されたパスコードとが一致するユーザである。判定部102は、入力された顔の特徴量と登録された顔の特徴量とが類似し、かつ、入力されたパスコードと登録されたパスコードとが一致するレコードがユーザデータベースDBに複数個存在するか否かを判定する。類似と一致の個々の判定方法は、先述した通りである。
本実施形態では、判定部102は、第1の基準よりも低い第2の基準に基づいて、類否を判定する。基準が低いとは、類似と判定されやすい基準であり、非類似と判定されにくい基準である。基準が低いとは、基準が甘い又はゆるいと同じ意味である。本実施形態のように類似度に基づいて認証の成否が判定される場合には、閾値の値が低いことである。第2の基準は、第1の基準よりも小さい閾値となる。なお、これら2つの基準を用意するのではなく、1つの基準だけが用意されてもよい。即ち、認証部101の基準と判定部102の基準とが同じであってもよい。
図9は、第1の基準と第2の基準の関係を示す図である。ここでは、ユーザの顔の特徴量がm(mは自然数)次元のベクトルで示される場合を説明する。実際には、顔の特徴量は、数十〜数百次元のベクトルで表現されることが多いが、図9では、説明の簡略化のために、mの値が2であり、顔の特徴量が2次元座標で示される場合を説明する。
図9の例は、ユーザA,B,Xが登録申請を行い、何れのユーザも、「1427」のパスコードを指定した場合を示す。図9のような2次元座標上では、顔の特徴量の違いは距離に表れる。距離が近いほど顔の特徴量が類似しており、距離が離れているほど顔の特徴量が類似していないことを意味する。ユーザXは、ユーザA,Bと顔が似ていないため、ベクトル空間上で離れているが、ユーザA,Bは、互いに顔が似ており、ベクトル空間上で近くにいる。
図9では、第1の基準を濃い網点の円で示し、第2の基準を白い円で示している。このため、入力された顔の特徴量が濃い網点の円内にあることは、第1の基準を満たすことを意味し、入力された顔の特徴量が白い円内にあることは、第2の基準を満たすことを意味する。例えば、入力された顔の特徴量が図9の「P」の符号であれば、ユーザAの第1の基準及び第2の基準を満たし、かつ、ユーザBの第2の基準を満たすことになる。
図9の例では、ユーザAとユーザBは、互いに顔が似ておりパスコードが同じなので、一方のユーザが他方のユーザに成りすましてしまう可能性がある。例えば、ユーザAの濃い網点の円と、ユーザBの濃い網点の円と、が重なっていれば、成りすましの可能性が高くなる。この場合は、判定部102によって、認証が成功する可能性のある複数のユーザが存在すると判定される。
また例えば、ユーザAの濃い網点の円と、ユーザBの濃い網点の円と、が重なっていなくても、一方の白い円と他方の網点の円とが重なっていれば、何らかの要因によって、一方の顔の特徴量が他方よりに検出されると、成りすましの可能性が発生する。この場合も、判定部102によって、認証が成功する可能性のある複数のユーザが存在すると判定される。
[生成部]
生成部103は、制御部11を主として実現される。生成部103は、認証が成功する可能性のある複数のユーザの各々のユーザ情報の違いを特定し、追加認証情報を生成する。
ユーザ情報の違いとは、あるユーザのユーザ情報と他のユーザのユーザ情報との差異又は相違点である。ユーザ情報の全部が違うこともあるし、ユーザ情報の一部だけが違うこともある。例えば、ユーザ情報が電話番号の場合、電話番号の全ての桁が違うこともあれば、電話番号の一部の桁だけが違うこともある。また例えば、ユーザ情報がメールアドレスの場合、メールアドレスの全ての文字が違うこともあれば、メールアドレスの一部の文字だけが違うこともある。
追加認証情報は、追加認証で利用される認証情報である。認証情報の意味は先述した通りである。ユーザ情報の全部を追加認証情報として利用してもよいし、ユーザ情報の一部だけを追加認証情報として利用してもよい。追加認証情報がユーザ情報の一部だけである場合には、ユーザ情報の連続した部分(例えば、電話番号の下3桁)が追加認証情報になってもよいし、ユーザ情報の非連続の部分(例えば、電話番号の5桁目と8桁目)が追加認証情報となってもよい。
本実施形態では、生成部103は、入力量が一定範囲に収まるように、追加認証情報を生成する。入力量とは、追加認証情報の情報量であり、操作量ということもできる。例えば、入力量は、桁数、文字数、又はキー入力の回数である。一定範囲は、予め定められた範囲であればよく、例えば、上限値だけが定められていてもよいし、下限値だけが定められていてもよいし、これらの両方が定められていてもよい。本実施形態では、生成部103は、入力量が2桁〜4桁に収まるように、追加認証情報を生成する。
本実施形態では、ユーザ情報は、複数の項目が存在し、複数の項目の各々には、優先順位が定められている。生成部103は、複数の項目の各々の優先順位に基づいて、追加認証情報を生成する。
項目とは、ユーザ情報の種類である。ユーザデータベースDBのフィールドは、項目に相当する。本実施形態では、電話番号とメールアドレスの2つの項目が存在する場合を説明するが、項目数は、1つであってもよいし、3つ以上であってもよい。例えば、電話番号、メールアドレス、生年月日、及び氏名の各々を追加認証情報として利用する場合には、項目数は4つとなる。
優先順位は、追加認証情報として使用する優先度である。優先順位は、認証システムSの管理者によって指定されるようにすればよく、例えば、ユーザが思い出しやすく、かつ、入力が容易な項目の優先順位が高くなる。本実施形態では、数字入力だけで済む電話番号の優先順位が高く、記号入力が発生する可能性のあるメールアドレスの優先順位が低くなっている。優先順位は、データ記憶部100に予め記憶されているものとする。
生成部103は、複数の項目の各々の優先順位順に、ユーザ情報に違いがあるか否かを判定する。生成部103は、ユーザ情報に違いがあると判定した場合、当該違いの全部又は一部を追加認証情報とする。生成部103は、ユーザ情報に違いがないと判定した場合には、次の優先順位の項目について、ユーザ情報に違いがあるか否かを判定する。
先述したように、本実施形態では、入力量が一定範囲に収まるように追加認証情報が生成されるので、生成部103は、優先順位順に、入力量が一定範囲に収まる程度のユーザ情報の違いがあるか否かを判定することになる。このため、ユーザ情報に違いがあったとしても、その違いが小さすぎれば、追加認証情報が生成されず、次の優先順位の項目について、ユーザ情報に違いがあるか否かが判定される。ユーザ情報の違いが大きい場合には、その全部が追加認証情報となってもよいし、入力量が一定範囲に収まらないのであれば、その一部が追加認証情報となる。
本実施形態では、ユーザ情報は、複数の情報部分を含み、複数の情報部分の各々には、優先順位が定められており、生成部103は、複数の情報部分の各々の優先順位に基づいて、追加認証情報を生成する。
情報部分は、1つのユーザ情報に含まれる複数の部分である。各情報部分は、他の情報部分と重複していてもよいし、特に重複していなくてもよい。例えば、ユーザ情報が電話番号であれば、電話番号の下2桁、下3桁、下4桁、4桁目〜7桁目、3桁目と8桁目といった部分は、情報部分に相当する。また例えば、ユーザ情報がメールアドレスであれば、メールアドレスの@以前の部分、@以降の部分、2文字目〜5文字目、4文字目と6文字目といった部分は、情報部分に相当する。
生成部103は、複数の情報部分の各々の優先順位順に、ユーザ情報に違いがあるか否かを判定する。生成部103は、ユーザ情報に違いがあると判定した場合、当該違いの全部又は一部を追加認証情報とする。生成部103は、ユーザ情報に違いがないと判定した場合には、次の優先順位の情報部分について、ユーザ情報に違いがあるか否かを判定する。先述したように、本実施形態では、入力量が一定範囲に収まるように追加認証情報が生成されるので、一定範囲に収まるような情報部分が設定されているものとする。
図10は、生成部103の処理を示す図である。図10に示すように、生成部103は、複数の項目の各々のユーザ情報に違いがあるか否か、及び、複数の情報部分の各々に違いがあるか否か、を優先順位順に判定する。例えば、生成部103は、1番目の優先順位の項目(図10の例では、電話番号)のユーザ情報のうち、1番目の優先順位の情報部分(図10の例では、下3桁)に違いがあるか否かを判定する。
生成部103は、1番目の優先順位の項目の1番目の情報部分に違いがあると判定した場合、当該違いを追加認証情報として生成する。図10の例では、ユーザAとBの電話番号の下3桁に違いがあるので、生成部103は、電話番号の下3桁を追加認証情報として生成する。
生成部103は、1番目の優先順位の項目の1番目の情報部分に違いがないと判定した場合、2番目の優先順位の情報部分(例えば、4桁目〜7桁目)に違いがあるか否かを判定する。以降、生成部103は、1番目の優先順位の項目の情報部分の違いを発見するまで、優先順位順に判定処理を繰り返す。
生成部103は、1番目の優先順位の項目の違いを発見できなかった場合、2番目の優先順位の項目(本実施形態では、メールアドレス)の1番目の情報部分(例えば、@の前3文字)に違いがあるか否かを判定する。以降、生成部103は、2番目の優先順位の項目の情報部分の違いを発見するまで、優先順位順に判定処理を繰り返す。生成部103は、情報部分の違いを発見した場合、当該違いを追加認証情報として生成する。
[入力要求部]
入力要求部104は、制御部11を主として実現される。入力要求部104は、認証が成功する可能性のある複数のユーザが存在すると判定された場合に、当該複数のユーザの各々のユーザ情報の違いに基づく追加認証情報の入力を要求する。
追加認証情報の入力を要求するとは、追加認証情報の入力を促すことである。入力要求部104は、ユーザに所定の通知をすることによって、追加認証情報の入力を要求する。この通知は、ユーザが知覚可能な態様で行われるようにすればよく、本実施形態では、画像を利用して視覚的に行われるものとするが、音声を利用して聴覚的に行われてもよいし、振動等を利用して触覚的に行われてもよい。
本実施形態では、サーバ10によって入力要求部104が実現されるので、入力要求部104は、認証装置30に対し、追加認証情報の入力を要求するためのデータを送信する。このデータは、任意の形式のデータであってよく、例えば、メッセージ、画像、プッシュ通知、又は電子メールなどである。追加認証情報の入力を要求するためのデータは、データ記憶部100に予め記憶されており、入力要求部104は、データ記憶部100に記憶されたデータに基づいて、追加認証情報の入力を要求する。
本実施形態では、生成部103が追加認証情報を生成するので、入力要求部104は、生成部103が生成した追加認証情報の項目や情報部分をユーザに通知し、当該項目の当該情報部分の入力を要求することになる。即ち、追加認証情報として、何のユーザ情報のどの部分を入力するかをユーザに把握させるために、入力要求部104は、追加認証情報として入力すべき項目とその部分をユーザに通知する。
[追加認証部]
追加認証部105は、制御部11を主として実現される。追加認証部105は、入力された追加認証情報に基づいて、追加認証をする。本実施形態では、生成部103が追加認証情報を生成するので、追加認証部105は、入力された追加認証情報と、生成された追加認証情報と、に基づいて、追加認証をする。生成部103が生成した追加認証情報は、データ記憶部100に記憶されているものとする。追加認証自体は、先述した認証と同様の方法で行われるようにすればよく、追加認証部105は、追加認証情報の一致又は類似に基づいて、追加認証をすればよい。認証部101の説明で「登録された認証情報」と記載した箇所を、「生成された追加認証情報」と読み替えればよい。
[変更要求部]
変更要求部106は、制御部11を主として実現される。変更要求部106は、認証が成功する可能性のある複数のユーザのうち、パスコードの登録日時に基づいて定まるユーザに対し、パスコードの変更を要求する。
登録日時は、ユーザデータベースDBにパスコードが登録された日時、又は、その前後の日時である。例えば、登録日時は、ユーザによる利用登録を受け付けた日時、ユーザデータベースDBに新たなレコードが作成された日時、又は当該レコードにパスコードが格納された日時である。
登録日時に基づいて定まるユーザは、登録日時と所定の選出条件に基づいて選出されたユーザである。選出条件としては、任意の条件を設定可能であり、例えば、登録日時が最も古いこと、登録日時が所定日時よりも前であること、登録日時が古い順に所定人数を選出すること、登録日時が最も新しいこと、登録日時が所定日時よりも後であること、又は登録日時が新しい順に所定人数を選出することである。
例えば、図9の例であれば、ユーザAとBが互いに認証が成功する可能性のあるユーザとなる。図8のデータ格納例に示すように、ユーザBの登録日時は、ユーザAの登録日時よりも古いので、変更要求部106は、ユーザBに対し、パスコードの変更を要求する。
パスコードの変更は、所定の方法を利用して要求されるようにすればよく、例えば、電子メール、SMS、メッセージアプリ、プッシュ通知、又はSNSを利用して行われる。変更要求部106は、ユーザ端末20に対し、パスコードの変更を促す旨のデータを送信する。このデータには、サーバ10のURLが含まれており、ユーザは、当該URLを選択し、パスコードを変更するための画面をユーザ端末20に表示させる。サーバ10は、当該画面から入力された新パスコードを、ユーザデータベースDBに格納し、パスコードを変更させる。パスコードの変更は、パスコードの更新ということもできる。
[処理実行部]
処理実行部107は、制御部11を主として実現される。処理実行部107は、認証結果に基づいて、所定の処理を実行する。本実施形態では、第1の認証、第2の認証、及び追加認証の3つの認証が行われるので、処理実行部107は、3つの認証の少なくとも1つが失敗した場合には、所定の処理を実行せず、3つの認証が全て成功した場合に、所定の処理を実行する。なお、追加認証が行われない場合には、処理実行部107は、第1の認証と第2の認証の2つが成功した場合に、所定の処理を実行する。
所定の処理は、認証が成功した場合に実行が許可される処理である。本実施形態では、セキュリティゲートSGのロックを解除するための処理が所定の処理に相当する場合を説明するが、所定の処理は、任意の処理を適用可能である。例えば、所定の処理は、サーバ又は端末へのログイン処理、コンピュータのロックを解除する処理、データの閲覧を許可する処理、データの書き込みを許可する処理、自動ドアを開閉する処理、電子投票を許可する処理、又は公的文書の取得を許可する処理であってよい。
処理実行部107は、自らロック解除の制御をしてもよいが、本実施形態では、認証装置30の処理実行部303がロック解除の制御を実行するので、処理実行部107は、認証装置30に対し、認証結果を通知する。例えば、処理実行部107は、3つの認証の少なくとも1つが失敗した場合には、認証が成功したことを示す通知を送信せず、3つの認証が全て成功した場合に、認証が成功したことを示す通知を送信する。なお、ユーザによる認証が一定回数成功しなかった場合には、ユーザが入力したパスコードが格納されたレコード、又は、ユーザと顔が類似する特徴量が格納されたレコードの認証情報がロックされて使用できなくなるようにしてもよい。
[1−3−2.ユーザ端末において実現される機能]
図7に示すように、ユーザ端末20では、データ記憶部200、受付部201、及び送信部202が実現される。なお、本実施形態では、ユーザ端末20が認証システムSに含まれる場合を説明するが、ユーザ端末20は、認証システムSと通信可能な外部装置であってもよい。
[データ記憶部]
データ記憶部200は、記憶部22を主として実現される。データ記憶部200は、登録申請に必要なデータを記憶する。例えば、データ記憶部200は、ユーザの顔写真のデータを記憶する。また例えば、データ記憶部200は、ユーザID及びパスワードを記憶してもよい。
[受付部]
受付部201は、制御部21を主として実現される。受付部201は、ユーザが登録申請をするための入力操作を受け付ける。例えば、受付部201は、入力フォームF10〜F15の各々に対するユーザID、パスワード、顔写真のファイル名等、パスコード、電話番号、及びメールアドレスの入力を受け付ける。なお、受付部201が受け付ける入力操作は、これらに限られず、他の種々の入力操作を受け付け可能である。
[送信部]
送信部202は、制御部21を主として実現される。送信部202は、受付部201により受け付けられた入力操作に基づいて、登録申請をするためのデータを送信する。例えば、送信部202は、入力フォームF10〜F15の各々に対する入力操作に基づいて、ユーザID、パスワード、顔写真のデータ、パスコード、電話番号、及びメールアドレスをサーバ10に送信する。なお、送信部202が送信するデータは、これらに限られず、他の種々のデータを送信可能である。
[1−3−3.認証装置において実現される機能]
図7に示すように、認証装置30では、データ記憶部300、受付部301、送信部302、及び処理実行部303が実現される。なお、本実施形態では、認証装置30が認証システムSに含まれる場合を説明するが、認証装置30は、認証システムSと通信可能な外部装置であってもよい。
[データ記憶部]
データ記憶部300は、記憶部32を主として実現される。データ記憶部300は、認証に必要なデータを記憶する。例えば、データ記憶部300は、サーバ10のIPアドレス等の情報を記憶する。また例えば、データ記憶部300は、表示部35に入力フォームF35a,F35bなどを表示させるためのデータ(例えば、HTMLデータや画像データ)を記憶する。
[受付部]
受付部301は、制御部31を主として実現される。受付部301は、入力操作を受け付ける。入力操作は、認証に必要な入力操作であればよく、本実施形態では、顔認証についてはユーザの入力操作は要しないので、受付部301は、パスコードの入力操作を受け付ける。例えば、受付部301は、入力フォームF35aに対するパスコードの入力を受け付ける。また例えば、追加認証が発生した場合には、受付部301は、入力フォームF35bに対する追加認証情報の入力を受け付ける。
なお、受付部301は、認証システムSで利用する認証の種類に応じた入力操作を受け付ければよく、例えば、指紋認証が利用される場合には、ユーザがカメラやセンサなどの上に指を置く入力操作を受ける。また例えば、筆跡認証が利用される場合には、ユーザがタッチパネルなどの上で文字を書く入力操作を受け付ける。また例えば、パスワード認証又は合言葉認証が利用される場合には、受付部301は、パスワード又は合言葉の入力操作を受け付ける。合言葉は、認証装置30にマイクを備えておき、当該マイクによって検出されるようにすればよい。
[送信部]
送信部302は、制御部31を主として実現される。送信部302は、入力操作に基づいて、認証に必要な情報を送信する。送信部302は、認証情報そのものを送信してもよいし、認証情報を特定するための情報を送信してもよい。
なお、本実施形態では、第1認証部101aと第2認証部101bがサーバ10により実現される場合を説明するので、送信部202は、サーバ10にデータを送信する場合を説明するが、他のコンピュータによって第1認証部101aと第2認証部101bが実現される場合には、当該他のコンピュータにデータを送信してもよい。例えば、第1認証部101aと第2認証部101bが別々のコンピュータで実現される場合には、送信部202は、これらのコンピュータに情報を送信すればよい。
本実施形態では、第1の認証が顔認証であり、第2の認証がパスコード認証なので、送信部302は、撮影部36により撮影された画像(顔写真)と、入力フォームF35aに入力されたパスコードと、を送信する。なお、認証装置30側で顔の特徴量が計算されてもよく、この場合には、送信部302は、画像の代わりに、当該計算された顔の特徴量を送信する。また例えば、送信部302は、入力フォームF35bに入力された追加認証情報を送信する。
なお、送信部302は、認証システムSで利用する認証の種類に応じた情報を送信すればよく、例えば、指紋認証が利用される場合には、送信部302は、ユーザの指の画像を送信してもよいし、画像から計算された指の特徴量を送信してもよい。また例えば、筆跡認証が利用される場合には、送信部302は、ユーザがタッチパネルなどの上に書いた文字の画像を送信してもよいし、タッチ位置の変化を示す座標情報を送信してもよい。また例えば、パスワード認証又は合言葉認証が利用される場合には、送信部302は、ユーザが入力したパスワード又は合言葉を送信する。
[処理実行部]
処理実行部303は、制御部31を主として実現される。処理実行部303は、認証と追加認証が成功した場合に、所定の処理を実行する。処理実行部303は、第1の認証、第2の認証、及び追加認証の3つの認証が成功した場合に、所定の処理を実行する。所定の処理の意味は、先述した通りであり、認証が成功した場合に実行が許可される処理である。なお、追加認証が行われない場合には、処理実行部303は、第1の認証と第2の認証の2つが成功した場合に、所定の処理を実行する。
本実施形態では、3つの認証が全て成功した場合に、セキュリティゲートSGのロックが解除されるので、処理実行部303は、認証が成功したことを示す通知を受信した場合には、ロック機構のモータを回転等させることによってロックを解除し、認証が成功したことを示す通知を受信しなかった場合には、ロックを解除しない。なお、サーバ10の処理実行部107は、3つの認証が全て成功した場合に、認証が成功したことを示す通知ではなく、ロック機構を解除させるための信号を送信してもよく、この場合には、認証装置30の処理実行部303は、当該信号に基づいてロックを解除すればよい。
[1−4.本実施形態において実行される処理]
図11及び図12は、本実施形態において実行される処理の一例を示すフロー図である。図11及び図12に示す処理は、制御部11,31が、それぞれ記憶部12,32に記憶されたプログラムに従って動作することによって実行される。下記に説明する処理は、図7に示す機能ブロックにより実行される処理の一例である。なお、認証処理が実行されるにあたり、利用登録が完了しているものとする。
図11に示すように、まず、認証装置30において、制御部31は、撮影部36の検出信号に基づいて、撮影画像を取得する(S1)。S1においては、制御部31は、撮影部36が生成した撮影画像を取得し、表示部35の表示領域A35に表示させる。なお、表示部35には、入力フォームF35aとボタンB35aも表示されており、ユーザによるパスコードの入力を受付可能な状態となっている。
制御部31は、操作部34の検出信号に基づいて、ユーザによるパスコードの入力を受け付ける(S2)。S2においては、制御部31は、入力フォームF35aに対する4桁のパスコードの入力を受け付ける。例えば、パスコードを入力するためのソフトウェアテンキーが表示部35に表示される。
制御部31は、ユーザがボタンB35aを選択したことに応じて、サーバ10に対し、S1で取得した撮影画像と、S2で入力されたパスコードと、を送信する(S3)。
サーバ10においては、撮影画像とパスコードを受信すると、制御部11は、ユーザデータベースDBに基づいて、パスコード認証をする(S4)。S4においては、制御部11は、パスコードが一致するユーザがいるか否かを判定し、パスコードが一致するユーザがいる場合は認証成功となり、パスコードが一致するユーザがいない場合には認証失敗となる。
本実施形態では、パスコードが一致するユーザ全てが特定されるので、S4においては、制御部11は、ユーザが入力した4桁のパスコードをクエリとし、ユーザデータベースDBに格納された4桁のパスコードをインデックスとした検索を実行することになる。この検索は、パスコードの完全一致が判定される。検索で誰かヒットすれば認証成功となり、検索で誰もヒットしなければ認証失敗となる。
パスコード認証が失敗した場合(S4;失敗)、制御部11は、認証装置30に対し、所定のエラーメッセージを送信し(S5)、本処理は終了する。この場合、認証装置30の表示部35に、エラーメッセージが表示され、パスコードが違うことがユーザに通知される。
一方、パスコード認証が成功した場合(S4;成功)、制御部11は、S4で受信した撮影画像の顔の特徴量と、パスコードが一致するユーザの顔の特徴量と、に基づいて、顔認証をする(S6)。S6においては、制御部11は、これらの特徴量の差に基づいて類似度を計算し、類似度が閾値以上であるユーザが存在するか否かを判定する。類似度が閾値以上であるユーザが存在する場合は認証成功となり、類似度が閾値以上であるユーザが存在しない場合は認証失敗となる。
顔認証が失敗した場合(S6;失敗)、S5の処理に移行し、エラーメッセージが送信され、本処理は終了する。この場合、認証装置30の表示部35に、エラーメッセージが表示され、顔認証が成功しなかったことがユーザに通知される。
一方、顔認証が成功した場合(S6;成功)、制御部11は、顔認証とパスコード認証が成功する可能性のある複数のユーザが存在するか否かを判定する(S7)。S7においては、制御部11は、顔の特徴量が類似し、かつ、パスコードが一致する複数のユーザが存在するか否かを判定する。なお、S7の処理は、S6と同じ基準で判定されてもよいし、S6よりも低い基準で判定されてもよい。即ち、S6は、先述した第1の基準で判定され、S7は、先述した第2の基準で判定されてもよい。
顔認証とパスコード認証が成功する可能性のある複数のユーザが存在すると判定されない場合(S7;N)、後述するS14の処理に移行し、セキュリティゲートSGのロックが解除される。一方、顔認証とパスコード認証が成功する可能性のある複数のユーザが存在すると判定された場合(S7;Y)、制御部11は、ユーザデータベースDBに基づいて、当該複数のユーザの各々のユーザ情報の違いに基づいて、追加認証情報を生成する(S8)。S8においては、制御部11は、複数項目の各々の優先順位と、複数の情報部分の各々の優先順位と、に基づいて、追加認証情報を生成する。
例えば、制御部11は、顔認証とパスコード認証が成功する可能性のある複数のユーザの各々の電話番号の下3桁を比較し、違いがあるか否かを判定する。制御部11は、電話番号の下3桁が違う場合、電話番号の下3桁を追加認証情報として生成する。制御部11は、電話番号の下3桁が同じ場合、電話番号の4桁目〜7桁目を比較し、違いがあるか否かを判定する。制御部11は、電話番号の4桁目〜7桁目が違う場合、電話番号の4桁目〜7桁目を追加認証情報として生成する。制御部11は、電話番号の4桁目〜7桁目が同じ場合、メールアドレスを比較し、違いがあるか否かを判定する。制御部11は、メールアドレスが違う場合、メールアドレスの違う部分の全部又は一部を追加認証情報として生成する。なお、メールアドレスが同じ場合には、S5に移行してエラーメッセージが表示されるようにしてもよい。
制御部11は、認証装置30に対し、追加認証情報の入力を要求する(S9)。追加認証情報の入力の要求は、追加認証情報として生成されたユーザ情報の項目が何であるかを識別する情報が含まれているものとする。
認証装置30においては、要求を受信すると、制御部31は、追加認証情報の入力を受け付けるための画面を表示部35に表示させる(S10)。S10においては、制御部31は、追加認証が発生したことを示すメッセージ、追加認証情報として入力すべき項目と情報部分、入力フォームF35b、及びボタンB35bを表示部35に表示させる。
制御部31は、操作部34の検出信号に基づいて、ユーザによる追加認証情報の入力を受け付ける(S11)。S11においては、制御部31は、入力フォームF35bに対する追加認証情報の入力を受け付ける。例えば、パスコードを入力するためのソフトウェアキーボードが表示部35に表示される。制御部31は、サーバ10に対し、S11で入力された追加認証情報を送信する(S12)。
図12に移り、サーバ10においては、追加認証情報を受信すると、制御部11は、追加認証をする(S13)。S13においては、制御部11は、入力された追加認証情報と、S8で生成された追加認証情報と、が一致するか否かを判定し、これらが一致するユーザがいる場合は認証成功となり、これらが一致しないユーザがいない場合には認証失敗となる。
追加認証が成功した場合(S13;成功)、制御部11は、認証装置30に対し、全ての認証が成功したことを示す認証成功通知を送信する(S14)。認証成功通知は、所定形式のデータが送信されることにより行われ、認証が成功したユーザの名前が含まれるものとする。即ち、追加認証で入力された電話番号又はメールアドレスと一致した電話番号又はメールアドレスのユーザの名前が認証成功通知に含まれる。
認証装置30においては、通知を受信すると、制御部31は、セキュリティゲートSGのロックを解除し(S15)、認証が成功したユーザの名前を表示部35に表示させる(S16)本処理は終了する。ユーザは、自身の名前が表示部35に表示されたことを確認し、セキュリティゲートのドアを押して通過する。なお、この場合には、サーバ10にユーザの氏名や現在日時などの情報が通行記録として残ってもよい。
サーバ10においては、制御部11は、ユーザデータベースDBに基づいて、パスコードの登録日時が最も古いユーザに対し、パスコードの変更を要求し(S17)、本処理は終了する。S17においては、制御部11は、S7において判定された複数のユーザの各々のパスコードの登録日時を比較し、最も古い登録日時のユーザのメールアドレスに、パスコードを変更するためのURL入りの電子メールを送信する。なお、S7の判定が否定されてS14の処理が実行された場合には、S17の処理は実行されない。
認証システムSによれば、入力された認証情報に基づく認証が成功する可能性のある複数のユーザが存在すると判定された場合に、追加認証情報の入力を要求して追加認証をすることによって、セキュリティを十分に高めることができる。例えば、互いに顔が似ておりパスコードも同じ複数のユーザが存在したとしても、ユーザ情報の違いに基づく追加認証をすることによって、原則として本人しか知り得ない追加認証情報で認証し、悪意のある第三者による成りすましを防止することができる。更に、追加認証情報として、ユーザ情報を利用することによって、ユーザにとって思い出しやすく、かつ、入力のしやすい情報で追加認証をすることができる。また例えば、ユーザ情報の違いに基づく追加認証情報を利用することによって、互いに顔が似ておりパスコードも同じ複数のユーザの各々を互いに識別可能な情報で追加認証をすることができ、セキュリティを効果的に高めることができる。
また、認証システムSは、入力された認証情報に基づく認証が成功する可能性のある複数のユーザの各々のユーザ情報の違いを特定することによって、これらのユーザを識別可能な追加認証情報を生成することができ、セキュリティを効果的に高めることができる。
また、認証システムSは、入力量が一定範囲に収まるように追加認証情報を生成することによって、ユーザビリティとセキュリティのバランスを適切に担保することができる。例えば、追加認証情報が複雑すぎてしまうことを防止し、ユーザにとって思い出しやすく、かつ、入力のしやすい情報で追加認証をすることができる。また例えば、追加認証情報がシンプルすぎてしまうことも防止し、セキュリティを担保することもできる。
また、認証システムSは、ユーザ情報の複数の項目の各々の優先順位に基づいて、追加認証情報を生成することによって、ユーザビリティとセキュリティのバランスを効果的に担保することができる。例えば、ユーザにとって思い出しやすく、かつ、入力のしやすい項目の優先順位を上げることで、ユーザビリティを高めることができる。また例えば、他のユーザが推測しにくい項目の優先順位を上げることで、セキュリティを向上することもできる。
また、認証システムSは、ユーザ情報の複数の情報部分の各々の優先順位に基づいて、追加認証情報を生成することによって、ユーザビリティとセキュリティのバランスを効果的に担保することができる。例えば、ユーザにとって思い出しやすく、かつ、入力のしやすい情報部分の優先順位を上げることで、ユーザビリティを高めることができる。また例えば、他のユーザが推測しにくい情報部分の優先順位を上げることで、セキュリティを向上することもできる。
また、認証システムSは、入力された認証情報と、登録された認証情報と、の類似に基づいて認証を行い、当該認証をする場合には、悪意のある第三者による成りすましが発生しやすいところ、このような認証を利用したとしても、追加認証情報の入力を要求して追加認証をすることによって、セキュリティを十分に高めることができる。
また、認証システムSは、認証情報の類似に基づく第1の認証と、認証情報の一致に基づく第2の認証と、の二段階の認証をすることで、セキュリティを効果的に向上させることができる。また、先述したように、二段階の認証をしたとしても、悪意のある第三者の成りすましを防止できないことがあるが、追加認証をすることで成りすましを防止し、セキュリティを向上させることができる。
また、認証システムSは、互いに顔が似ておりパスコードが同じ複数のユーザのうち、パスコードの登録日時に基づいて定まるユーザに対し、パスコードの変更を要求することによって、セキュリティを効果的に向上させることができる。
また、第1の認証として生体認証を利用し、第2の認証としてパスコード認証を利用することで、ユーザがカードキーなどを持たず手ぶらであったとしても、セキュリティを担保した認証をすることができる。更に、ユーザが認証情報を覚える必要のない生体認証と、認証情報を忘れにくいパスコード認証と、の二段階の認証とすることで、セキュリティを向上しつつ、ユーザビリティを向上させるもできる。また例えば、生体認証として、指紋認証やDNA認証などに比べて抵抗が少ない顔認証を利用することで、ユーザビリティをより向上させることができる。
また、第1の基準に基づいて、顔認証の類否を判定し、第1の基準よりも低い第2の基準に基づいて、認証が成功する可能性のあるユーザを判定し、追加認証を行うことによって、セキュリティを効果的に向上させることができる。
[2.実施形態2]
次に、第2の実施形態(以降、実施形態2)について説明する。実施形態1では、互いに顔が似ており、かつ、パスコードが同じ複数のユーザが存在する場合に追加認証が行われる場合を説明したが、特に追加認証が行われずに、何れかのユーザに対してパスコードの変更が促されてもよい。実施形態2では、追加認証が行われずに、パスコードの変更が促される場合を説明する。なお、実施形態2では、実施形態1と同様の構成については説明を省略する。
実施形態2のサーバ10は、データ記憶部、第1認証部101a、第2認証部101b、判定部102、変更要求部106、及び処理実行部107が実現される。実施形態2では、入力要求部104、追加認証部105、及び生成部103は実現されなくてもよい。第1認証部101a及び第2認証部101bの処理は、実施形態1で説明した通りである。
実施形態2の判定部102は、登録された顔の特徴量が互いに類似し、かつ、登録されたパスコードが互いに一致する複数のユーザがいるか否かを判定する。判定部102の処理は、実施形態1で説明した処理と同様であってよい。
なお、実施形態2では、ユーザの認証時ではなく、他のタイミングで判定処理が実行されてもよい。例えば、判定部102は、入力された認証情報と、登録された認証情報と、を比較するのではなく、登録された認証情報同士を比較することによって、上記複数のユーザがいるか否かを判定してもよい。即ち、判定部102は、ユーザデータベースDBに格納された顔の特徴量同士を比較し、互いに類似する複数のユーザがいるか否かを判定してもよい。
実施形態2の変更要求部106は、判定部102により判定された複数のユーザのうち、パスコードの登録日時に基づいて定まるユーザに対し、パスコードの変更を要求する。変更要求部106の処理は、実施形態1で説明した通りである。
以上説明した実施形態2によれば、登録された第1の認証情報が互いに類似し、かつ、登録された第2の認証情報が互いに一致する複数のユーザのうち、第2の認証情報の登録日時に基づいて定まるユーザに対し、第2の認証情報の変更を要求することによって、成りすましを防止し、セキュリティを高めることができる。
[3.変形例]
なお、本発明は、以上に説明した実施の形態に限定されるものではない。本発明の趣旨を逸脱しない範囲で、適宜変更可能である。
(1)例えば、実施形態1では、顔が似ており、かつ、パスコードが一致する複数のユーザが存在することを条件として、追加認証が行われる場合を説明したが、他の条件のもとで追加認証が行われてもよい。即ち、顔が似ており、かつ、パスコードが一致するユーザが1人しかいなかったとしても、一定の条件のもとで追加認証が行われるようにしてもよい。
入力要求部104は、複数のユーザが存在しないと判定されたとしても、所定の条件に基づいて、認証が成功するユーザのユーザ情報の一部又は全部の入力を要求する。所定の条件は、予め定められた条件であればよく、例えば、認証回数が閾値を超えること、一定時間が経過すること、所定の日時が訪れること、又は乱数が所定の値となることである。入力要求部104は、所定の条件が満たされた場合に、追加認証情報であるユーザ情報の一部又は全部の入力を要求する。
本変形例で追加認証情報となるユーザ情報の一部又は全部は、ユーザ間のユーザ情報の違いに基づかなくてもよく、任意のユーザ情報が追加認証情報となってよい。例えば、予め定められた項目の全てのユーザ情報が追加認証情報となってもよいし、予め定められた項目の予め定められた情報部分のユーザ情報が追加認証情報となってもよい。
追加認証部105は、入力された一部又は全部のユーザ情報に基づいて、追加認証を行う。追加認証の方法自体は、実施形態で説明した通りである。追加認証部105は、入力された一部又は全部のユーザ情報と、登録された一部又は全部のユーザ情報と、の一致又は類似に基づいて、追加認証をすればよい。
変形例(1)によれば、認証が成功する可能性のある複数のユーザが存在しないと判定されたとしても、所定の条件に基づいて、追加認証が行われるので、セキュリティを効果的に高めることができる。例えば、顔が似ておりパスコードが同じユーザがいるときにだけ追加認証が要求されると、ユーザが、他のユーザに成りすませる可能性があることに気付く可能性がある。この点、例えば、10回に一度は必ず追加認証をするといったように、他のタイミングで追加認証を求めることによって、ユーザは、他のユーザに成りすませる可能性があることに気付くことを防止することができる。これにより、成りすましを効果的に防止することができる。
(2)また例えば、実施形態では、ユーザがセキュリティゲートSGを通過する場面を例に挙げたが、認証システムSは、ユーザが商品を購入したりサービスを利用したりする場面にも適用可能である。この場合、例えば、認証装置30は、自動販売機、券売機、POS端末、又は店舗における支払端末である。ユーザは、認証装置30の撮影部36に顔を向けて操作部34からパスコードを入力し、顔認証とパスコード認証が成功すると、決済処理が実行され、商品を購入したり、サービスを利用したりすることができる。
本変形例の処理実行部107は、認証と追加認証が成功した場合に、認証と追加認証が成功したユーザの決済情報に基づいて決済処理を実行してもよい。決済処理の際に参照される決済情報は、顔認証、パスコード認証、及び追加認証が成功したユーザに関連付けられた決済情報である。
決済情報は、決済をするために必要な情報であり、例えば、クレジットカード情報、電子バリュー(例えば、電子マネー又はポイント)のアカウント情報、仮想通貨のアカウント情報、銀行口座情報、又はデビットカード情報などである。決済情報は、ユーザ登録時などに登録され、例えば、ユーザデータベースDBに、ユーザIDに関連付けて決済情報が格納されているものとする。なお、決済情報は、ユーザデータベースDBとは異なるデータベースに格納されていてもよい。
処理実行部107は、決済情報に応じた決済処理を実行すればよく、例えば、クレジットカード情報に基づく与信処理、電子バリューの残高を減少させる処理、仮想通貨の残高を減少させる処理、銀行口座から引き落としや振り込みをする処理、又はデビットカード情報が示す口座の残高を減少させる処理などを実行する。処理実行部107は、顔認証又はパスコード認証の何れか一方が失敗した場合には決済処理を実行せず、顔認証とパスコード認証とが成功した場合に決済処理を実行する。
決済処理が実行された場合、認証装置30の表示部35又は店舗の端末などに、その旨が表示され、ユーザは商品を受け取ったり、サービスを利用したりする。例えば、認証装置30が店舗などに設置されたデジタルサイネージ装置である場合、サーバ10から認証成功通知を受信すると、認証が成功したことを示すメッセージが表示部35に表示される。店舗のスタッフは、当該メッセージを確認すると、ユーザに商品を渡したりサービスを提供したりする。なお、メッセージは、認証装置30ではなく、店舗のスタッフが操作する端末などの他のコンピュータに転送されて表示されてもよい。また例えば、認証装置30が自動販売機であれば、サーバ10から認証成功通知を受信すると、認証装置30は、ユーザが指定した商品を排出したり、コーヒーやインスタント食品などの商品を調理したりする。
以上説明した変形例によれば、顔が類似する他のユーザが成りすまして決済し、不正に商品を購入したりサービスを利用したりすることを防止し、商品の購入時やサービスの利用時におけるセキュリティを十分に高めることができる。また、ユーザからしてみれば手ぶらで店舗に行ったとしても、セキュリティを担保した決済が可能になるので、ユーザビリティを向上させることができる。店舗からしてみても、クレジットカードの読取装置などの専用の装置を用意しなくても決済が可能となるので、店舗の利便性を向上させることもできる。
(3)また例えば、上記変形例を組み合わせてもよい。
また例えば、認証装置30の撮影部36で撮影された画像に基づいて、生体認証が実行される場合を説明したが、赤外線センサ又は超音波センサなどといった他のセンサを利用して生体認証が実行されてもよい。認証システムSは、第1の認証として利用する生体認証に応じたセンサを含めばよい。
また例えば、認証装置30に対して認証情報が入力される場合を説明したが、ユーザ端末20又は他のコンピュータに対して認証情報が入力されてもよい。また例えば、第1の認証として生体認証を説明したが、第1の認証は、類似に基づく認証であればよく、生体認証に限られない。例えば、タッチパネル上で所定の軌跡を描くパターン認証が第1の認証として用いられてもよい。また例えば、第1の認証は、合言葉の類似に基づく認証であってもよい。この場合、ユーザが入力した合言葉と、ユーザデータベースDBに登録された合言葉と、が類似する(一致する部分の割合が閾値以上)であれば認証成功となり、類似しなければ認証失敗となる。また例えば、第1の認証は、複数の生体認証が複合的に利用されてもよいし、パターン認証と合言葉認証が複合的に利用されてもよい。
また例えば、第2の認証としてパスコード認証を説明したが、第2の認証は、複数の認証が組み合わされていてもよい。例えば、第2の認証は、合言葉認証と、パスコード認証と、を組み合わせてもよい。この場合、第2の認証情報は、合言葉とパスコードの組み合わせである。また例えば、第2の認証は、パスワード認証、秘密鍵認証、又は電子証明書認証といった他の認証が用いられてもよい。
また例えば、主な機能がサーバ10で実現される場合を説明したが、各機能は、複数のコンピュータで分担されてもよい。例えば、サーバ10、ユーザ端末20、及び認証装置30の各々で機能が分担されてもよい。例えば、認証処理がサーバ10で実行されるのではなく、ユーザ端末20又は認証装置30で実行されてもよい。また例えば、認証システムSが複数のサーバコンピュータを含む場合には、これら複数のサーバコンピュータで機能が分担されてもよい。また例えば、データ記憶部100で記憶されるものとして説明したデータは、サーバ10以外のコンピュータによって記憶されてもよい。