JP2020071513A - 認証システムおよびその方法 - Google Patents

Abstract

【課題】ネットワークを介して接続要求のある、端末の使用される様々な環境やユーザの種々の要求に応じてセキュリティの対策を図る。【解決手段】端末からのアクセス要求に対して認証を行うサーバは、該認証の制御を行う認証制御部と、１又は複数の異なる認証方式の組み合わせから構成される複数の認証の組を登録する認証管理テーブルと、顧客に対する課金を処理する課金処理部とを有する。認証制御部は端末からのアクセス要求があると、認証管理テーブルを参照して、アクセス要求に関連する認証の組を選択して、その選択された組に含まれる認証方式に基づいて端末との間で認証を行う。課金処理部は、認証の組を構成する認証方式の使用数を基に課金を計算する。【選択図】図１４

Description

本発明は、認証システムおよびその方法に係り、特にネットワークを介して接続される端末及びユーザの認証に関するものである。

パソコンやスマートフォン、タブレット等の端末を、ネットワークを介して目的のサイトやサーバに接続して、コンテンツを取得し或いはアプリケーションを利用することが日常的に行われている。アクセス対象となるコンテンツ等の情報には、個人情報や機密情報等のセキュリティ性の高い情報が含まれている。そこで、アクセス権限のない端末やなりすまし等の不正使用者からの要求に対してはネットワークの接続を拒否することで、セキュリティ保護が図られている。

正当なユーザを確認するユーザ認証の技術としては、ユーザの端末からパスワードを入力させて、その一致性を検証するものが一般的である。さらに、セキュリティを強化するユーザ認証として、例えば特許文献１に開示されるように、利用者の指紋、顔、筆跡、虹彩等の生体情報を組み合わせて認証する複合認証システムが知られている。また、端末と使用者の両方を認証するものとして、特許文献１に開示されているように、端末機の認証と、端末機の使用者の個人認証による二重認証によって、端末機の通信ネットワークに対するアクセス許可を発行する、通信ネットワークへの複数認証システムが知られている。

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

特許文献１及び２に記載の技術は、パスワードのみの検証に比べて、確かにセキュリティの強化が図れる。一方で、ユーザが使用する端末には高度な機能を有するものや、セキュリティ対策が脆弱なものなど様々であり、またこれらの端末が使用される環境も様々である。さら、ユーザが要求するセキュリティ対策の機能も種々ある。これらの多様なセキュリティ対策の要求に応じるには、上記特許文献1および２に記載のセキュリティ対策だけでは十分とは言えない。さらに、セキュリティを一層強化したいという要求に対しては、認証機能がより複雑化する傾向にあるが、それに対応してコストも増加しがちである。

本発明の目的は、ネットワークを介して接続要求のある、端末の使用される様々な環境やユーザの種々の要求に応じてセキュリティの対策を図ることが可能な認証システムおよびその方法、並びにプログラムを提供することにある。

本発明の更に他の目的は、認証サービスに応じた課金を行うことにある。

本発明にかかる認証システムの好ましい一例は、端末からアクセス要求に対してサーバが認証を行う認証システムであって、前記サーバは、
該認証の制御を行う認証制御部と、
１又は複数の異なる認証方式の組み合わせから構成される複数の認証の組を登録する認証管理テーブルと、
顧客に対する課金を処理する課金処理部と、を有し、
前記認証制御部は、前記端末からのアクセス要求があると、前記認証管理テーブルを参照して、該アクセス要求に関連する認証の組を選択して、該選択された組に含まれる認証方式に基づいて、該端末との間で認証を行い、
前記課金処理部は、前記認証の組を構成する認証方式の使用数を基に課金を計算することを特徴とする認証システム、として構成される。
本発明はまた、当該認証システムで実行される認証方法、認証プログラムとしても把握される。

本発明によれば、ネットワークを介して接続要求のある、端末の使用される様々な環境やユーザの種々の要求に応じてセキュリティの対策を図ることができる。また、認証サービスに応じた課金を行うことができる。

実施例１による認証システムの構成例を示す図である。 アクセス許可ＤＢの例を示す図である。 アカウント認証ＤＢの例を示す図である。 ユーザの種別ごとに採用される認証方式の例を示す図である。 初期登録ＤＢの例を示す図である。 認証システムで行われる処理の処理手順を示すシーケンス図である。 アカウントＩＤ入力画面の例を示す図である。 セッションデータの例を示す図である。 認証エラー画面の例を示す図である。 端末認証処理の処理手順を示すシーケンス図である。 携帯端末認証処理の処理手順を示すシーケンス図である。 デバイス認証処理の処理手順を示すシーケンス図である。 各ＰＣ、端末に表示される画面の例を示す図である。 実施例２による認証管理システムの構成例を示す図である。 課金テーブルの例を示す図である。

以下に添付図面を参照して、本発明にかかる認証システムおよびその方法、並びにそのプログラムの実施の形態について詳細に説明する。実施例１は認証システムの好ましい例、実施例２は認証システムにおける課金について開示する。

［システム構成］
図１は、認証システム１０００の構成例を示す図である。
図１に示すように、認証システム１０００は、ユーザがコンテンツの利用承認を得るためのユーザ用ＰＣ（Personal Computer）１００と、携帯端末によりユーザを認証するための携帯端末（例えば、スマートフォン）１１０と、デバイス（例えば、ＵＳＢ（Universal Serial Bus））を用いてユーザを認証するためのデバイス用ＰＣ１２０と、ユーザに応じた認証方式を用いてユーザを認証する認証サーバ２００とが、互いにネットワークＮ１を介して接続されて構成される。ネットワークＮ１にはまたコンテンツサーバ３００が接続される。ネットワークＮ１は、例えば、ＷＡＮ（Wide Area Network）等の一般的な通信回線網である。なお、図１には、1台ずつのユーザ用ＰＣ１００、携帯端末１１０、デバイス用ＰＣ１２０を示しているが、実際にはこれら装置が多数台接続される。認証サーバ２００には、認証されたユーザ用ＰＣ１００、１２０にコンテンツを提供するコンテンツサーバ３００が接続される。

図１に示すように、ユーザ用ＰＣ１００は、アプリケーション部１０１と、表示部１０２と、通信Ｉ／Ｆ（インタフェース）部１０３と、制御部１０４とを有して構成されている。

アプリケーション部１０２は、ユーザからの利用承認要求を受けて、当該ユーザに対応する認証方式を用いて真正なユーザであると認証された場合に、コンテンツサーバ３００に格納されたコンテンツの視聴や動作を実行するアプリケーションである。

入力表示部１０２は、例えば、タッチパネル等の入出力装置から構成され、ユーザから本認証システムに必要な各種情報の入力を受け付けたり、ネットワークＮ１を介して得られた各種情報、アプリケーション部１０１により処理された情報、認証に用いられる各種画面を表示する。

通信部Ｉ／Ｆ部１０３は、例えば、ＮＩＣ（Network Interface Card）等の通信機器から構成され、ネットワークＮ１を介した各種情報の送受信を司る。
制御部１０４は、例えば、ＣＰＵ（Central Processing Unit）のような処理装置により構成され、ユーザ用ＰＣ１００の各部の動作を制御する。

上記各部は、制御部１０４がプログラムを実行することにより、これらの機能が実現される。具体的には、以下に示す処理は、ＣＰＵが図示しないＲＯＭ（Read Only Memory）に記憶されているプログラムを読み出して、ＲＡＭ（Random access memory）にロードして実行することにより実現される。

これらのプログラムは、通信部Ｉ／Ｆ部１０３を介してネットワークＮ１からダウンロードされ、ＲＡＭ上にロードされて、ＣＰＵにより実行されるようにしてもよい。或いは、ＣＤ(Compact Disk)やＤＶＤ(Digital Versatile Disk)等の可搬性を有するコンピュータで読み取り可能な記憶媒体からＲＡＭ上に直接ロードされ、ＣＰＵにより実行されるようにしてもよい。ユーザ用ＰＣ１００が有する各部の具体的な動作については、シーケンス図およびフローチャートを用いて後述する。

図１に示すように、携帯端末１１０は、携帯端末用認証部１１１と、入力表示部１１２と、通信Ｉ／Ｆ（インタフェース）部１１３と、制御部１１４とを有して構成されている。

携帯端末用認証部１１１は、ユーザ用ＰＣ１００から利用承認要求したユーザの認証方式が携帯端末１１０を用いた認証方式（携帯端末認証）を含む場合に、その認証を行うアプリケーションである。

入力表示部１１２は、認証のための各種情報の入力を受け付けたり、ネットワークＮ１を介して得られた認証結果等、その他本認証システムで用いられる各種画面を表示する。

通信部Ｉ／Ｆ部１１３は、ネットワークＮ１を介した各種情報の送受信を司る。

制御部１１４は、例えばＣＰＵのような処理装置であり、携帯端末１１０の各部の動作を制御する。

上記各部は、制御部１１４がプログラムを実行することにより、これらの機能が実現される。携帯端末１１０の各部の具体的な動作については、シーケンス図およびフローチャートを用いて後述する。

図１に示すように、デバイス用ＰＣ１２０は、アプリケーション部１２１と、デバイス用認証部１２２と、入力表示部１２３と、通信Ｉ／Ｆ（インタフェース）部１２４と、デバイスＩ／Ｆ（インタフェース）部１２５と、制御部１２６とを有して構成されている。

アプリケーション部１２１は、ユーザからのコンテンツの利用承認要求を受けて、当該ユーザに対応する認証方式を用いて真正なユーザであると認証された場合に、コンテンツサーバ３００に格納されたコンテンツの視聴や動作を実行するアプリケーションである。

デバイス用認証部１２２は、利用承認要求したユーザの認証方式がデバイス用ＰＣ１２０を用いた認証方式（デバイス認証）を含む場合に、その認証を行うアプリケーションである。

入力表示部１２３は、認証のための各種情報の入力を受け付けたり、ネットワークＮ１を介して得られた認証結果等、その他本認証システムで用いられる各種画面を表示する。

通信部Ｉ／Ｆ部１２４は、ネットワークＮ１を介した各種情報の送受信を司る。

デバイス部Ｉ／Ｆ部１２５は、例えばＵＳＢボードのようなインタフェース機器であり、ＵＳＢ等の各種デバイスの抜き差しを検知する。

制御部１２６は、例えばＣＰＵのような処理装置であり、デバイス用ＰＣ１２０の各部の動作を制御する。

上記各部は、制御部１２６がプログラムを実行することにより、これらの機能が実現される。デバイス用ＰＣ１２０の各部の具体的な動作については、シーケンス図およびフローチャートを用いて後述する。

認証サーバ２００は、ユーザ用ＰＣ１００やデバイス用ＰＣ１２０から利用承認要求されたユーザのアカウントに応じて、ユーザの認証方式を選択し、選択した認証方式によりユーザを認証するサーバである。

図１に示すように、認証サーバ２００は、記憶部２０１と、通信部２０２と、認証制御部２０４と、制御部２０５とを有して構成されている。また、認証制御部２０４は、パスワードの一致により認証を行うパスワード認証部２０４１と、登録済みの端末（ブラウザ）の利用を以ってユーザを特定する認証を行う端末認証部２０４２と、登録済みの携帯端末の所有を以って利用者を特定する認証を行う携帯端末認証部２０４３と、登録済みのデバイスの所有を以って利用者を特定する認証を行うデバイス認証部２０４４とを有している。

記憶部２０１は、ＨＤＤやＳＳＤ等の一般的な記憶装置から構成され、アカウント認証ＤＢ（Data Base）２０１１を記憶する。記憶部２０１は、ユーザによるアクセスの認証時間帯および利用承認要求の接続元を確認するためのアクセス許可ＤＢ２０１１と、アクセスが許可されたユーザのアカウントに応じて認証方式を選択するためのアカウント認証ＤＢ２０１２と、ユーザが利用承認に用いるユーザ用ＰＣ１００、ユーザが認証に用いる携帯端末１１０、デバイス用ＰＣ１２０を登録する初期登録ＤＢ２０１３とを有している。アクセス許可ＤＢ２０１１（図２）、アカウント認証ＤＢ２０１２（図３）、初期登録ＤＢ２０１３（図５）の具体的な構成については後述する。

通信部２０２は、例えばＮＩＣやモデムであり、ネットワークＮ１を介した各種情報の送受信を司る。アクセス制御部２０３は、ユーザ用ＰＣ１００等からのアクセス要求（利用承認要求）を受けて処理を実行する。

認証制御部２０４は、アカウント認証ＤＢ２０１２を参照し、ユーザのアカウントに応じて、パスワード認証部２０４１、端末認証部２０４２、携帯端末認証部２０４３、デバイス認証部２０４４の中から、予め定められた認証方式を選択して実行させる。

パスワード認証部２０４１は、ユーザを、アカウントＩＤおよびパスワードにより認証する。
端末認証部２０４２は、ユーザを、端末認証により認証する。
携帯端末認証部２０４３は、ユーザを、携帯端末認証により認証する。
デバイス認証部２０４４は、ユーザを、デバイス認証により認証する。

制御部２０５は、例えばＣＰＵのような処理装置であり、認証サーバ２００の各部の動作を制御する。認証サーバ２００の各部の具体的な動作については、シーケンス図およびフローチャートを用いて後述する。上記各部は、制御部２０５がプログラムを実行することにより、これらの機能が実現される。

本認証システムでは、ユーザ及びまたは端末の認証に関して、「パスワード認証」、「端末認証」、「携帯端末認証」、「デバイス認証」の４つの認証方式を採用している。
ここで、パスワード認証は、あらかじめ定めたパスワードを入力することによりユーザの認証を行う。その意味では、最も簡便な方法によるユーザの認証方式といえる。また、端末認証は、ユーザ用ＰＣ１００やデバイス用ＰＣ１２０等の端末が予め認証システムに登録されたものと同一であるかを認証する。

携帯端末認証は、ユーザ用ＰＣ１００等の設置場所や使用時間帯といった使用環境が妥当であるかを、定められた携帯端末を用いてユーザを認証する。複数のユーザがユーザ用ＰＣ１００を共有する環境にある場合でも、ユーザを認証することができる。この認証方式は、ユーザ自らが予め携帯端末に登録した生体情報やパスワード等の個人情報を用いてユーザを認証するものである。携帯端末は普及率が高いため、ＢＹＯＤ（Bring Your Own Device）環境で業務を遂行するユーザも多い。そこで、「携帯端末認証」を採用することにより、ユーザのみが知り得る個人情報を認証サーバ２００に登録しないで、少ないリスクで容易にユーザ本人を認証することができる。

デバイス認証は、デバイス用ＰＣ１２０に装着されるＵＳＢのようなデバイスが、初期登録ＤＢ２０１３に予め登録されたデバイス認証情報を有しているかを確認する認証である。ユーザ毎に持たせる認証デバイス１３０のデバイス認証情報を変えることで、複数のユーザがそれぞれ所持する認証デバイス１３０をデバイス用ＰＣ１２０に装着して認証を受けることができる。そのため、コストをかけることなく簡便な方法でユーザの認証を行って、デバイス用ＰＣ１２０を複数のユーザが共用することが可能である。

コンテンツサーバ３００は、認証サーバ２００が真正であると認証したユーザ用ＰＣ１００、デバイス用ＰＣ１２０へ、要求されたコンテンツを提供するサーバである。

［認証管理方式］
図２は、アクセス許可ＤＢ２０１１の例を示す図である。図２に示すように、アクセス許可ＤＢ２０１１は、アカウントごとに、接続元のＩＰアドレスからのアクセスを許可する条件を示す接続元条件と、アクセスを許可する時間帯を示す時間条件とが対応付けて記憶されている。なお、ＩＰアドレスはそれを有する端末の場所を表すとも言えることから、上記接続条件を場所的条件ということができる。

図２において、アカウントＩＤが「Ｅ２」のユーザについて、例えば、ＩＰアドレスが「１９２．１６８．０．０／２４」であるユーザ用ＰＣ１００からアクセスがあった場合に、接続元条件としては許可されることを示している。さらに、その接続が勤務時間帯である「９：００〜１７：００」である場合に、時間条件としては許可されることを示している。すなわち、アカウントＩＤが「Ｅ２」のユーザは、これらの接続元条件と時間条件とが許可されない限り、後述するユーザの認証処理が行われない。

また、例えば、アカウントＩＤが「Ｅ２」のユーザは、例えば、ＩＰアドレスが「１９２．１６８．２０．０／２４」であるユーザ用ＰＣ１００からは、接続時間に関わらずアクセスが許可されないことを示している。さらに、接続時間が深夜時間帯である「０：００〜５：００」である場合は、接続元のＩＰアドレスに関わらずアクセスが許可されないことを示している。このように、「だれが」、「いつ」、「どこから」利用承認要求を行っているのかを確認することにより、認証システム１０００に不正にアクセスするユーザを、各認証部による認証処理を行う前に、事前に排除することができる。

図３は、アカウント認証ＤＢ２０１２の例を示す図である。図３に示すように、アカウント認証ＤＢ２０１１は、アクセスが許可されたユーザのアカウントと、そのユーザの認証方式と、そのアカウントの認証を許可するための場所的な条件を示す認証接続元アドレスと、当該認証要求を行ったアカウントの認証を許可するための時間的な条件を示す認証接続時間とが対応付けて記憶されている。

図３では、例えば、アカウント「Ｃ」のユーザは、「パスワード認証」、「携帯端末認証（スマホ認証）」の２種類の認証方式による認証が必要であることを示している。

また、例えば、アカウント「Ｆ２」のユーザは、「端末認証」、「携帯端末認証」の２種類の認証方式による認証が必要であることを示している。さらに、このユーザについては、認証接続元アドレスとして定められた「１９２．１６８．０．０／２４」以外のアドレスからアクセスされている場合に、携帯端末認証を行うことを示している。

また、例えば、アカウント「Ｆ３」のユーザは、「端末認証」、「携帯端末認証」の２種類の認証方式による認証が必要であることを示している。さらに、このユーザについては、認証接続時間として定められた「０９：００〜１７：００」（勤務時間内）以外の時間にアクセスされている場合に、携帯端末認証を行うことを示している。

また、例えば、アカウント「Ｇ２」のユーザは、「端末認証」、「デバイス認証」の２種類の認証方式による認証が必要であることを示している。さらに、このユーザについては、認証接続元アドレスとして定められた「１９２．１６８．０．１１／３２」のアドレスからアクセスされている場合は、デバイス認証を行わない（スルーする）ことを示している。

また、例えば、アカウント「Ｇ３」のユーザは、「端末認証」、「デバイス認証」の２種類の認証方式による認証が必要であることを示している。さらに、このユーザについては、認証接続時間として定められた「０９：００〜１７：００」（勤務時間内）にアクセスされている場合は、デバイス認証を行わない（スルーする）ことを示している。

このように、この認証システムでは、利用承認要求に対してユーザのアカウントに応じて、様々な認証方式の中からユーザに適した認証方式の組を選択し、そのユーザを認証することができる。さらに、アカウントごとに場所的条件や時間的条件を定めることにより、アカウントのユーザについて個別の認証を行い、ユーザごとに時間的、場所的な条件を用いて認証することができる。しかも、認証方式の組を用いた認証において、最も強固なセキュリティを担保する認証方式（「パスワード認証」かつ「端末認証」かつ「携帯端末認証」）から、最も利便性の高い認証方式（「パスワード認証」のみ）まで、幅広い環境に最適なセキュリティを提供することができる。

本認証システムでは、図２に示したアクセス許可ＤＢ２０１１を用いて利用承認を行うとともに、図３に示したアカウント認証ＤＢ２０１２を用いて認証方式の組を選択して認証するので、ユーザの種別ごとに、時間的条件や場所的条件に応じた認証方法で認証することができる。すなわち、本実施例においては、アクセス許可ＤＢ２０１１を用いて時間的条件及び場所的条件（第1条件という）を満たすかの承認を行い、その後にアカウント認証ＤＢ２０１２を用いて認証方式（第２条件）に基づく認証を行うので、前者を第1認証、後者を第２認証ということができる。さらに後者の第２認証においてもＦ２，Ｆ３，Ｇ２，Ｇ３のアカウントでは、場所的条件又は時間的条件の認証を行っているので、これらはより厳格な認証と言える。

図４は、ユーザの種別ごとに採用される認証方式の例を示す図である。図４では、ユーザの種別が「社員」、「非社員」について、場所的条件（社内外）と時間的条件の関係を示している。図４に示すように、ユーザのアカウントが「社員」である場合、社内からのアクセスの場合には、勤務時間内、勤務時間外を問わず、アカウントおよびパスワード認証（利便性のある軽度な認証方式）を行う。これに対して、社外からのアクセスの場合には、いずれの時間帯でも、上記の認証方式に加えて携帯端末認証（スマホ認証）を行う。この認証は３つの認証方式を行うことから強度の認証方式と言える。また、ユーザのアカウントが「非社員」である場合、社内からのアクセスの場合には、勤務時間内であればアカウントおよびパスワード認証を行う一方、社外からのアクセスの場合には、勤務時間内であれば、さらに端末認証および携帯端末認証（スマホ認証）を行う。そして、勤務時間外の場合は、社内、社外を問わずアクセスを不可とする。

このように、アクセス許可ＤＢ２０１１とアカウント認証ＤＢ２０１２を用いた認証を行うことにより、真正なユーザについては簡便な認証方式とする如く、ユーザの種別や場所的条件、時間的条件に応じて認証方式を変えることができる。すなわち、ユーザの種別に応じて認証方式を動的に変える設定４０１、場所により認証方式を動的に変える設定４０２、時間により認証方式を動的に変える設定４０３が可能となる。従来は、アカウントを認証するにあたり、認証基盤、ＶＰＮ、認証局等の各システムを組み合わせることが必要であったが、本実施例の認証システムでは、認証サーバ２００においてユーザごとにセキュリティの高い認証を実現することができる。従来のようなシステムの組み合わせによる認証の場合、一般的には、導入コストが高価となったり、運用管理が煩雑になり、アカウントの定義や連携をはじめ、認証のための設定に誤りが生じるといったリスクがあるが、本実施例の認証システムによれば、安価な導入コストで、容易かつ安全な運用管理が可能となる。

図５は、初期登録ＤＢ２０１３の例を示す図である。図５に示すように、初期登録ＤＢ２０１３は、本認証システムを利用するユーザのアカウントと、そのユーザのパスワード情報、端末認証情報、携帯端末認証情報、デバイス認証情報とが対応付けて記憶されている。図５では、例えば、アカウント「Ａ」のユーザは、パスワード情報としてパスワード「１２３」が登録され、端末認証情報として割符「α（α１、α２）」が登録され、携帯端末認証情報として生体コード「ａ」が登録され、デバイス認証情報としてＵＳＢのシリアルナンバー「Ｘ０００１」が登録されていることを示している。なお、図５では、すべての認証方式について登録された場合を例示しているが、少なくとも、ユーザのアカウントに対応する認証方式について登録されていればよい。

［認証制御］
図６は、認証システム１０００で行われる処理の処理手順を示すシーケンス図である。
図６に示すように、まず、ユーザ用ＰＣ１００のアプリケーション部１０１は、ユーザがアカウントを入力するためのアカウントＩＤ入力画面を入力表示部１０２に表示する（Ｓ６０１）。

図７は、アカウントＩＤ入力画面の例を示す図である。図７に示すように、アカウントＩＤ入力画面は、ユーザ用ＰＣ１００から利用承認要求するユーザのアカウントを入力するための入力欄と、入力されたアカウントＩＤを認証サーバ２００に送信するためのＯＫボタンとが表示されている。

ユーザ用ＰＣ１００のアプリケーション部１０１は、ＯＫボタンが押下されると、入力されたアカウントＩＤを、認証サーバ２００に送信する。認証サーバ２００の認証制御部２０４は、ユーザ用ＰＣ１００から受信したアカウントＩＤをセッションに登録する（Ｓ６０２）。具体的には、認証制御部２０４は、アカウントＩＤに対応するセッションＩＤを付与したセッション管理テーブルの一例であるセッションデータを生成し、記憶部２０１に保持する。

図８は、セッションデータの例を示す図である。セッションは、ユーザが利用承認要求を行ってから、当該要求に対する結果が得られるまでにネットワークを介した１つの一連の処理であり、セッションデータは、１つの一連のセッションにおいて行われる処理の結果を含むデータである。セッションデータにより保持される項目は、以下に示す処理の結果に応じて変化する。ここでは、図８（ａ）に示すように、セッションＩＤとアカウントＩＤとを対応付けたセッションデータが保持される。図８（ａ）では、アカウントＩＤ「Ｅ」について、セッションＩＤ「Ｓ０００１」が付与されたことを示している。認証制御部２０４は、セッションＩＤに対応付けたアカウントＩＤをキーにしてアクセス許可ＤＢ２０１１を参照し、当該アカウントＩＤのユーザがアクセスするための接続元条件および時間条件を読み出し、これらの条件を満たしたアクセスであるか否かを判定する（Ｓ６０３、Ｓ６０４）。

Ｓ６０３において、認証制御部２０４がこれらの条件を満たしたアクセスではないと判定した場合（Ｓ６０３；Ｎｏ、または／およびＳ６０４；Ｎｏ）、その旨をユーザ用ＰＣ１００に送信し、ユーザ用ＰＣ１００のアプリケーション部１０１が、認証エラー画面を入力表示部１０２に表示する（Ｓ６０５）。

図９は、認証エラー画面の例を示す図である。図９に示すように、認証エラー画面は、認証が失敗した旨が表示されている。ユーザは、認証エラー画面が表示されることにより、自身が本認証システムへのアクセス許可条件を満たしていないことを認識することができる。

認証制御部２０４は、利用承認要求されたユーザのアカウントが接続元条件および時間条件（第1条件）のいずれの条件も満たしていると判定した場合（Ｓ６０３；Ｙｅｓ、Ｓ６０４；Ｙｅｓ）、さらに、アカウントＩＤをキーにしてアカウント認証ＤＢ２０１２を参照し、当該アカウントＩＤに対応するに認証方式（第２条件）を読み出す（Ｓ６０６）。

例えば、認証制御部２０４は、アカウントＩＤが「Ｅ」である場合、認証方式として、「パスワード認証」、「デバイス認証」を読み出す。このとき、認証制御部２０４は、Ｓ６０２で生成したセッションデータに対して、各認証方式の認証結果を示す項目を追加し、認証方式として採用しない項目に、認証に使用しないことを示す情報「−」を書き込む。図８（ｂ）は、各認証方式の認証結果を示す項目を追加したセッションデータの例を示す図である。図８（ｂ）では、図８（ａ）に示したセッションデータに追加された各認証方式の認証結果を示す項目のうち、採用されない「端末認証」、「携帯端末認証」に「−」が書き込まれていることがわかる。

さらに、認証制御部２０４は、アカウントＩＤをキーにしてアカウント認証ＤＢ２０１２を参照し、当該アカウントＩＤのユーザが、接続元アドレスまたは／および接続時間を満たしたユーザであるか否かを判定する（Ｓ６０７、Ｓ６０８）。ここで、接続元アドレスまたは／および接続時間を満たしたユーザとは、これらの条件を満たすことにより、各認証方式による認証を実行しない（スルーする）ことが可能なユーザのことである。

認証制御部２０４は、アカウントＩＤのユーザが、認証元接続アドレスまたは／および認証接続時間を満たしたユーザであると判定した場合（Ｓ６０７；Ｙｅｓ、Ｓ６０８；Ｙｅｓ）、Ｓ６１５に進む。一方、認証制御部２０４は、アカウントＩＤのユーザが、少なくとも接続元アドレスまたは接続時間のいずれかを満たしていないと判定した場合（Ｓ６０７；Ｎｏ、またはＳ６０８；Ｎｏ）、Ｓ６０９に進む。

認証制御部２０４は、アカウントＩＤのユーザが、少なくとも接続元アドレスまたは接続時間のいずれかを満たしていないと判定した場合（Ｓ６０７；Ｎｏ、またはＳ６０８；Ｎｏ）、その旨および当該アカウントＩＤに対応付けて定義されている認証方式でユーザの認証を行う指示をユーザ用ＰＣ１００に送信し、ユーザ用ＰＣ１００のアプリケーション部１０１は、当該指示に従って、各認証部にリダイレクトさせる（Ｓ６０９）。例えば、アカウントＩＤに対応する認証方式が「パスワード認証」、「デバイス認証」である場合、アプリケーション部１０１は、まず、「パスワード認証」を実行するパスワード認証部２０４１を呼び出し、パスワード認証部２０４１による認証処理を実行させる。端末認証部２０４２による認証、携帯端末認証部２０４３による認証、デバイス認証部２０４４による認証を行う場合も同様である。

各認証部は、認証サーバ２００の認証制御部２０４から実行指示を受けると、各認証方式による認証を実行する（Ｓ６１０）。各認証部による認証処理は、例えば、ＣＧＩ（Common Gateway Interface）プログラムにより実現される。各認証方式については、フローチャートを用いて後述する。

Ｓ６１０において、各認証部により認証が実行され、認証結果がセッションデータに書き込まれると、各認証部は、認証結果が得られた旨をユーザ用ＰＣ１００に送信し、ユーザ用ＰＣ１００のアプリケーション部１０１は、認証制御部２０４にリダイレクトさせる（Ｓ６１１）。

そして、認証制御部２０４は、セッションチェックを開始し（Ｓ６１２）、各認証部による認証結果が認証ＯＫ（許可）であるか否かを判定する（Ｓ６１３）。例えば、認証制御部２０４は、認証方式が「パスワード認証」である場合、図８（ｃ）に示すように、セッションデータのうち、パスワード認証部２０４１による認証処理結果を示す項目に認証ＯＫ（○印）が書き込まれていることを確認する。

認証制御部２０４は、各認証部による認証結果が認証ＯＫでない（不許可）と判定した場合（Ｓ６１３；Ｎｏ）、その旨をユーザ用ＰＣ１００に送信し、ユーザ用ＰＣ１００のアプリケーション部１０１が、図９に示した認証エラー画面を入力表示部１１２に表示する（Ｓ６１４）。

一方、認証制御部２０４は、各認証部による認証結果が認証ＯＫであると判定した場合（Ｓ６１３；Ｙｅｓ）、さらに、セッションデータに追加した未実施の認証方式があるか否かを判定する（Ｓ６１５）。認証制御部２０４は、未実施の認証方式があると判定した場合（Ｓ６１５；Ｙｅｓ）、Ｓ６０７に戻り、他の認証方式について、以降の処理を繰り返す。

認証制御部２０４は、未実施の認証方式がないと判定した場合（Ｓ６１５；Ｎｏ）、すなわち、図８（ｄ）に示すように、セッションデータの各認証部のすべての認証処理結果を示す項目に認証ＯＫが書き込まれていることが確認できた場合、ＳＳＯ（シングル・サイン・オン）処理を実行する（Ｓ６１６）。なお、本例では、ＳＳＯについて例示したが、ＨＴＴＰ（Hypertext Transfer Protocol）のリバースプロキシ処理を実行してもよい。

認証制御部２０４は、シングル・サイン・オン先にリダイレクトさせる指示をユーザ用ＰＣ１００に送信し（Ｓ６１７）、ユーザ用ＰＣ１００のアプリケーション部１０１は、当該指示に従って、コンテンツサーバ３００のサイトに認可要求を送信し、コンテンツサーバ３００は、当該認可要求にしたがって、上記サイトへのログイン処理を実行する（Ｓ６１８）。コンテンツサーバ３００は、ログイン処理を行った後のサイト画面をユーザ用ＰＣ１００に送信し、ユーザ用ＰＣ１００のアプリケーション部１０１は、当該サイト画面を表示部１０２に表示する（Ｓ６１９）。Ｓ６１９の処理が終了すると、図６に示す全ての処理が終了し、利用承認され、かつユーザに応じて定められたすべての認証方式により認証されたアカウントのユーザのみが、コンテンツサーバ３００のコンテンツにアクセスすることができるようになる。続いて、各認証方式による認証について説明する。

［各認証方式による認証］
（パスワード認証）
パスワード認証部２０４１は、あらかじめ定められたパスワードを用いてユーザの認証を行う。パスワード認証部２０４１は、図６のＳ６１０において、認証制御部２０４から指示を受けると、アカウントＩＤをキーにして初期登録ＤＢ２０１３を参照し、パスワード認証部２０４１が入力要求して入力されたパスワードが、初期登録ＤＢ２０１３に登録されているパスワードであるか否かを判定する。パスワード認証部２０４１は、パスワードの入力を要求する場合、図１３（ａ）に示すようなパスワード入力画面を出力し、ユーザ用ＰＣ１００のアプリケーション部１０１がパスワード入力画面を入力表示部１０２に表示する。

パスワード認証部２０４１は、入力されたパスワードが、初期登録ＤＢ２０１３に登録されているパスワードであると判定した場合、認証ＯＫとして、セッションデータの該当項目に認証結果を書き込む（図８（ｃ）、図８（ｄ））。なお、パスワード認証部２０４１は、入力されたパスワードが、初期登録ＤＢ２０１３に登録されているパスワードでないと判定した場合、認証ＮＧ（不許可）として、その旨の認証結果をセッションデータの該当項目に書き込む。

このように、「パスワード認証」では、あらかじめ定めたパスワードを入力するだけで認証を行うため、本認証システムへのアクセスが許可されたユーザに対して、最も簡便な方法で認証することができ、ユーザに対する認証のための操作負担を軽減することができる。

（端末認証）
図１０は、端末認証処理の処理手順を示すシーケンス図である。以下では、端末認証に用いる端末認証情報（この例では、サーバ側およびクライアント側の割符）が、あらかじめ初期登録ＤＢ２０１３に登録され、クライアント側の割符については、ユーザ用ＰＣ１００にも登録されているものとする。

図１０に示すように、端末認証部２０４２は、図６のＳ６１０において、認証制御部２０４から指示を受けると、アカウントＩＤをキーにして初期登録ＤＢ２０１３を参照し、アカウントＩＤに対応する端末認証情報として、サーバ側の割符（図５では、例えば、α１）を読み出すとともに、ＰＣ側の割符を要求する（Ｓ１００１）。

ユーザ用ＰＣ１００のアプリケーション部１０１は、あらかじめメモリに登録されているクライアント側の割符（図５では、例えば、α２）を読み出して、認証サーバ２００にその割符を送信する（Ｓ１００２）。

認証サーバ２００の端末認証部２０４２は、ユーザ用ＰＣ１００から受け取ったクライアント側の割符と、サーバ側の割符とを突合せ、両者が符合するか否かを判定する（Ｓ１００３）。端末認証部２０４２は、両者が符合すると判定した場合には認証ＯＫとして、セッションデータの該当項目に認証結果を書き込む（図８（ｃ）、図８（ｄ））。一方、端末認証部２０４２は、両者が符合しないと判定した場合、認証ＮＧとして、その旨の認証結果をセッションデータの該当項目に書き込む（Ｓ１００４）。

図１０では、割符を用いた端末認証について例示したが、ユーザ用ＰＣ１００のＭＡＣアドレスやクライアント証明書を用いた端末認証を行ってもよい。また、必ずしも割符を用いなくてもよい。

このように、端末認証では、一般的に使用環境が定められた端末を認証するため、複数のユーザに１つのアカウントが割り当てられ、ＰＣを共有する環境にある場合でも、そのアカウントを認証することができる。

（携帯端末認証）
図１１は、携帯端末認証処理の処理手順を示すシーケンス図である。図１１に示すように、携帯端末認証部２０４３は、図６のＳ６１０において、認証制御部２０４から指示を受けると、アカウントＩＤをキーにして初期登録ＤＢ２０１３を参照し、アカウントＩＤに対応する携帯端末認証情報（例えば、パスコード）を読み出し（Ｓ１１０１）、携帯端末１１０に対して、認証要求するためのプッシュ通知を行う（Ｓ１１０２）。認証制御部２０４は、プッシュ通知を行うと、携帯端末１１０に対しては、携帯端末認証情報による認証を行うための認証画面を送信し、携帯端末１００の携帯端末用認証部１１１が、入力表示部１１２に認証画面を表示する（Ｓ１１０３）。一方、認証制御部２０４は、ユーザ用ＰＣ１００に対しては、携帯端末による認証中であることを示す携帯端末認証通知画面を送信し、ユーザ用ＰＣ１００のアプリケーション部１０１が、入力表示部１０２に携帯端末認証通知画面を表示する（Ｓ１１０４）。

図１３（ｂ）は、携帯端末に表示される画面の例を示す図である。図１３（ｂ）右は、Ｓ１１０３における認証画面の例であり、図１３（ｂ）左は、Ｓ１１０４における携帯端末認証通知画面の例である。

図１３（ｂ）右に示すように、認証画面には、携帯端末認証情報による認証を実行する認証ボタンと、認証を実行せずに処理を終了させる閉じるボタンとが表示されている。ユーザが認証ボタンを押下すると、携帯端末用認証部１１１は、携帯端末認証情報により認証を行う画面（例えば、パスコードの入力画面）を表示し、入力された情報を認証サーバ２００に送信する。このように、プッシュ通知により携帯端末１１０に認証画面が表示されることにより、ユーザに対する認証を直ちに行うことができる。

また、図１３（ｂ）左に示すように、携帯端末認証通知画面には、携帯端末１１０により認証するために、携帯端末１００にプッシュ通知を行った旨、および確認を促す旨が表示されている。このように、ユーザ用ＰＣ１００に携帯端末認証通知画面が表示されることにより、ユーザは携帯端末１１０により認証を実行するために必要な操作を把握することができる。

その後、携帯端末用認証部１１１が、入力表示部１１２から入力された携帯端末認証情報を認証サーバ２００に送信すると、認証サーバ２００の携帯端末認証部２０４３は、初期登録ＤＢ２０１３に登録されている携帯端末認証情報と、入力された携帯端末認証情報とを突合せ、両者が符合するか否かを判定する（Ｓ１１０５、Ｓ１１０６）。携帯端末認証部２０４３は、両者が符合すると判定した場合には認証ＯＫとして、セッションデータの該当項目に認証結果を書き込む（Ｓ１１０６；Ｙｅｓ、Ｓ１１０８、図８（ｃ）、図８（ｄ））。一方、端末認証部２０４２は、両者が符合しないと判定した場合（Ｓ１１０６；Ｎｏ、認証ＮＧとして、その旨の認証結果をセッションデータの該当項目に書き込むとともに、図９に示した認証エラー画面と同様の画面を携帯端末１１０に送信し、携帯端末１１０の携帯端末用認証部１１１が、入力表示部１１２にその認証エラー画面を表示する（Ｓ１１０７）。

携帯端末認証部２０４３は、セッションデータに書き込んだ認証結果を読み出し、認証結果が認証ＯＫであるか否かを判定する（Ｓ１１０９、Ｓ１１１０）。携帯端末認証部２０４３は、認証結果が認証ＯＫであると判定した場合（Ｓ１１１０；Ｙｅｓ）、さらに有効時間が未経過であるか否かを判定する（Ｓ１１１１）。有効時間は、例えば、Ｓ１１０２においてプッシュ通知されてからＳ１１１０において認証ＯＫと判定されるまでの時間であり、携帯端末１１０からの認証操作がタイムアウトする時間（例えば、４分間）である。なお、携帯端末認証部２０４３は、認証結果が認証ＯＫでない、すなわち認証ＮＧと判定した場合（Ｓ１１１０；Ｎｏ）、Ｓ１１１２に進み、認証結果を確定させる。

携帯端末認証部２０４３は、有効時間が未経過であると判定した場合（Ｓ１１１１；Ｙｅｓ）、Ｓ１１０７、Ｓ１１０８で書き込んだ認証結果を確定させる（Ｓ１１１２）。一方、携帯端末認証部２０４３は、有効時間が未経過でない、すなわち有効時間を過ぎたと判定した場合（Ｓ１１１１；Ｎｏ）、Ｓ１１０４に戻り、以降の処理を続行する。この場合、Ｓ１１０８において認証結果として認証ＯＫがセッションデータに書き込まれたとしても、携帯端末認証部２０４３は、有効時間が経過していると判断し、Ｓ１１１２において、認証ＮＧに書き換えて認証結果を確定させる。

なお、この例ではステップＳ１１０２おいてプッシュ通知を送信しているが、プッシュ通知に限らず、携帯端末１１０がプル通知をしてもよい。

このように、携帯端末認証では、携帯端末のユーザが自ら登録した個人情報を用いてユーザを認証するので、個人情報を認証サーバ２００に登録することなく、少ないリスクで容易にユーザ本人を認証することができる。また、ユーザにとって使い慣れている携帯端末により認証を行うため、違和感なく認証のための操作を行うことができる。

（デバイス認証）
図１２は、デバイス認証処理の処理手順を示すシーケンス図である。図１２に示すように、デバイス認証部２０４４は、図６のＳ６１０において、認証制御部２０４から指示を受けると、アカウントＩＤをキーにして初期登録ＤＢ２０１３を参照し、アカウントＩＤに対応するデバイス認証情報（例えば、ＵＳＢのシリアルナンバー）を読み出し、読み出したデバイス認証情報をデバイス用ＰＣ１２０に送信し（Ｓ１２０１）、デバイス用ＰＣ１２０に対して、デバイスによる認証を促すデバイス認証通知画面を送信し、デバイス用ＰＣ１２０のデバイス用認証部１２１が、ブラウザを介して入力表示部１２２にデバイス認証通知画面を表示する（Ｓ１２０２）。

Ｓ１２０２において、デバイス用認証部１２１が、デバイスＩ／Ｆ部１２４にデバイスが挿入されたことを検知すると、デバイス認証を実行するためのデバイス認証実行画面を入力表示部１２２に表示する（Ｓ１２０３）。

図１３（ｃ）は、デバイス用ＰＣに表示される画面の例を示す図である。図１３（ｃ）左は、Ｓ１２０２におけるデバイス認証通知画面の例であり、図１３（ｃ）左は、Ｓ１２０３におけるデバイス認証実行画面の例である。

図１３（ｃ）左に示すように、デバイス認証通知画面には、デバイス認証するために、デバイス用ＰＣ１２０に、あらかじめ定められたデバイス１３０を挿入して認証を促す旨が表示されている。このように、デバイス用ＰＣ１２０にデバイス認証通知画面が表示されることにより、ユーザはデバイス用ＰＣ１２０によりデバイス認証するために必要な操作を把握することができる。

また、図１３（ｃ）右に示すように、デバイス認証実行画面には、デバイス１３０を挿入するドライブを選択するためのドライブ選択欄と、デバイス認証情報による認証を実行する認証ボタンと、認証を実行せずに処理を終了させるキャンセルボタンとが表示されている。このように、デバイス用ＰＣ１２０にデバイス認証実行画面が表示されることにより、ユーザはデバイス用ＰＣ１２０によりデバイス認証するドライブを選択した上でデバイス認証することができる。

Ｓ１２０３において、ユーザにより認証ボタンが押下されると、デバイス用認証部１２１は、Ｓ１２０１で認証サーバ２００から送信されたデバイス認証情報と、Ｓ１２０３で挿入されたデバイスの認証情報とを突合せ、両者が符合するか否かを判定し、その認証結果を認証サーバ２００に送信する。なお、本例では、デバイス用ＰＣ１２０のデバイス用認証部１２１がデバイス認証を実行しているが、認証サーバ２００のデバイス認証部２０４４がデバイス認証を実行してもよい。

認証サーバ２００のデバイス認証部２０４４は、デバイス用ＰＣ１２０から認証結果を受信すると、セッションデータの該当項目に認証結果を書き込む（Ｓ１２０４、図８（ｃ）、図８（ｄ））。

デバイス認証部２０４４は、セッションデータに書き込んだ認証結果を読み出し（Ｓ１２０５）、認証結果が認証ＯＫであるか否かを判定する（Ｓ１２０６）。デバイス認証部２０４４は、認証結果が認証ＯＫであると判定した場合（Ｓ１２０６；Ｙｅｓ）、さらに有効時間が未経過であるか否かを判定する（Ｓ１２０７）。有効時間については、図１１に示した携帯端末認証の場合と同様であるため、ここではその説明を省略する。なお、デバイス認証部２０４４は、認証結果が認証ＯＫでない、すなわち認証ＮＧと判定した場合（Ｓ１２０６；Ｎｏ）、Ｓ１２０８に進み、認証結果を確定させる。

デバイス認証部２０４４は、有効時間が未経過であると判定した場合（Ｓ１２０７；Ｙｅｓ）、Ｓ１２０４で書き込んだ認証結果を確定させる（Ｓ１２０８）。一方、携帯端末認証部２０４３は、有効時間が未経過でない、すなわち有効時間を過ぎたと判定した場合（Ｓ１２０７；Ｎｏ）、Ｓ１２０２に戻り、以降の処理を続行する。この場合、Ｓ１２０４において認証結果として認証ＯＫがセッションデータに書き込まれたとしても、デバイス認証部２０４４は、有効時間が経過していると判断し、Ｓ１２０８において、認証ＮＧに書き換えて認証結果を確定させる。

このように、デバイス認証では、ＵＳＢ等の安価なデバイスを用いてユーザを認証することにより、コストをかけることなく簡便な方法でユーザ本人を認証することができる。また、デバイスがデバイス用ＰＣを介して必要に応じてネットワークに接続するため、ネットワークから独立して認証のために必要な情報を管理することができる。

図１４および図１５を参照して、実施例２を説明する。
実施例２は、実施例１の認証システムを前提とした課金処理について開示するものである。図１に示す認証システムに管理サーバ２１０が追加されて、課金処理を行う。管理サーバ２１０は顧客管理用のサーバであり、顧客情報を管理するための種々のデータ処理を行う。その処理の１つとして、課金処理部２１２が認証サービスの課金処理を行う。課金処理は、課金処理部２１２がプロセッサでプログラムを実行することで行われる。

管理サーバ２１０はまた顧客情報を保管する顧客管理ＤＢ２１１を有している。顧客は上述の認証サービスを利用するユーザが属する企業や公共団体等の機関であり、顧客情報には顧客のサーバ（顧客サーバ）９００のアドレスの他、種々の個人情報が含まれる。顧客管理ＤＢ２１１は、課金処理に使用する課金テーブル（図１５参照）を保管している。一例では、課金テーブルは顧客ごとに用意される。

図１５に示すように、課金テーブルは、上述した認証方式に対応して、月当たりの単価、及び当該認証方式の使用数、及び合計金額が登録される。ここで、使用数は例えば顧客機関のユーザによって認証方式が使用される端末の台数である。また、使用数とは、認証方式が実際に毎月使用された端末の台数でもよいし、或いは認証方式が毎月使用される端末の予定台数でもよい。実際に使用された端末の台数は、認証要求の度に認証サーバ２００が取得するユーザの端末の接続元のＩＰアドレスを計数して累計することで把握できる。また、端末の予定台数は、顧客との間で認証サービスの契約を締結する時、又はその後の定期的な見直し時に顧客との合意に基づいて決めることができる。図１５に示す使用数は予定台数の例である。

課金処理部２１２は、課金テーブルの登録内容に従って毎月の課金を計算して、ネットワークＮ１を介して顧客サーバ９００へ課金の請求を送信する。なお、使用数が端末の予定台数の場合、毎月の合計額が予め分かるので、課金の請求は例えば３ヵ月毎又は６ヶ月毎、１２ヶ月毎のように定期的に送信することが可能である。

なお、他の例として、上記使用数は顧客機関に属するユーザのアカウントの数を用いてもよい。アカウントの数は認証サーバ２００が把握しているので、これを用いればよい。アカウントの数とは、例えば毎月実際に使用されたアカウントの数、或いは顧客との認証サービスの契約等で確認されるアカウントの使用予定数でもよい。

［代案、変形例］
以上、好ましい実施例について説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で適宜、変形、代替して実施し得る。

例えば、上記実施例１では、図１においてユーザ用ＰＣ１００とデバイス用ＰＣ１２０を別々に図示した。しかし、変形例においてはユーザ用ＰＣ１００に認証デバイス１３０を装着するコネクタを備えたものであるならば、ユーザ用ＰＣ１００をデバイス用ＰＣとして使用することができる。その場合、認証デバイス１３０を所持する複数のユーザは当該ユーザ用ＰＣ１００を共用することが可能となる。

また、上記実施例１では、図６を参照した制御において、ステップＳ６０３（時間的条件の判断）と、ステップＳ６０４（場所的条件の判断）の両方を行っている。代替例においては、これらのステップＳ６０３またはＳ６０４のいずれか一方の処理を行う例もあり得る。

また、上記実施例１では、図６を参照したステップＳ６０４では接続元アドレスであるＩＰアドレスを用いて場所的条件の判断を行っているが、代替例においては、これに限定されない。例えば、認証制御部２０４が、接続元のユーザ用ＰＣ１００やデバイス用ＰＣ１２０が設置された位置情報（ＧＰＳ情報）を取得して、場所的条件を判断することも可能である。

また、上記実施例１では、端末からの要求に対して、認証サーバ２００の認証制御部２０４がセッションを生成して、そのセッションに認証方式や認証結果を登録している。他の例によれば、外部からのアクセス要求を制御するアクセス制御部２０３を備えるサーバにおいて、アクセス制御部２０３がセッションを生成する場合もあり得る。その場合には、その生成されたセッションに対して、認証サーバ２００の認証制御部２０４が認証に係る種々の情報を登録することができる。さらに他の例として、アクセス制御部２０３が、図６の制御動作の一部、例えばステップＳ６０２〜Ｓ６０４の動作を行っても良い。この場合、認証制御部は、アクセス制御部が行う上記Ｓ６０２乃至Ｓ６０４の動作乃至機能を含むような広義の意味と捉えてよい。

また、上記実施例１では、認証サーバ２００が、パスワード認証部２０４１、端末認証部２０４２、携帯端末認証部２０４３、デバイス認証部２０４４を有する、とした。代替例によれば、これら認証部２０４１〜２０４４の1又は複数の部位を、認証サーバ２００とは別のサーバで実現しても良い。例えば、端末認証部２０４２及び又は他の部位をクラウドコンピュータ上で実現することも可能である。その場合でも、認証制御部２０４の制御の基、他のサーバで実現された認証部が制御されることになる。

また、上記実施例１では、アクセス許可ＤＢ２０１１、アカウント認証ＤＢ２０１２、初期登録ＤＢ２０１３と称したが、これらをそれぞれ、アクセス許可管理テーブル、アカウント認証管理テーブル、初期登録管理テーブルと呼んでもよい。

また、上記実施例では、認証制御部２０４は認証サーバ２００の一機能部として実現しているが、この機能部をプロキシサーバとして実現することも可能である。

また、上記実施例１では、認証に用いられる機器として、ＰＣ、スマートフォン、デバイスを例示しているが、動画プレーヤや音楽プレーヤ等のメディア再生機器をはじめとする様々なコンテンツを、ネットワークを介して利用するための装置や機器についても同様に適用することができる。

また、上記実施例２では、認証サーバ２００とは別に設けた管理サーバ２１０の課金処理部２１２が課金テーブルを用いて課金処理を行っている。他の例によれば、１つのサーバに、認証サーバ２００の機能と、管理サーバ２１０の認証処理部２１２及び課金テーブルの機能を持たせてもよい。

上述したように、本実施例の認証システムでは、複数の異なる認証方式のそれぞれを認証要素として、１または複数の認証要素の組み合わせから成る複数の組（認証組）を定義する。そして、ユーザ（一例ではユーザのアカウント）に応じて、１の認証組を選択して、その認証組に含まれる１または複数の認証要素に対応する認証部で実行して、ユーザまたは接続要求のあった端末を認証する。これにより、ネットワークを介して接続要求のある、端末の使用される様々な環境やユーザの種々の要求に応じてセキュリティの対策を図ることができる。また、認証サーバで認証制御や各認証方式による認証を行うので、認証のためのコストを出来るだけ抑えて、認証の運用を簡素化することができる。また、真性のあるユーザに対しては、図４に示したように、認証の手続きを出来るだけ簡素化して、ユーザの利便性を高めることができる。

本実施例による認証システムは、異なる認証要素の組み合わせから成る複数の認証組（認証パターンと言ってもよい）を用いてユーザ及び端末を認証するので、多要素認証システムと言うことができる。

１０００ 認証システム
１００ ユーザ用ＰＣ
１０１ アプリケーション部
１０２ 入力表示部
１０３ 通信Ｉ／Ｆ部
１０４ 制御部
１１０ 携帯端末
１１１ 携帯端末用認証部
１１２ 入力表示部
１１３ 通信Ｉ／Ｆ部
１１４ 制御部
１２０ デバイス用ＰＣ
１２１ アプリケーション部
１２２ デバイス用認証部
１２３ 入力表示部
１２４ 通信Ｉ／Ｆ部
１２５ デバイスＩ／Ｆ部
１２６ 制御部
１３０ 認証デバイス
２００ 認証サーバ
２０１ 記憶部
２０１１ アクセス許可ＤＢ
２０１２ アカウント認証ＤＢ
２０１３ 初期登録ＤＢ
２０２ 通信部
２０３ アクセス制御部
２０４ 認証制御部
２０４１ パスワード認証部
２０４２ 端末認証部
２０４３ 携帯端末認証部
２０４４ デバイス認証部
２０５ 制御部
２１０ 管理サーバ
２１１ 顧客管理ＤＢ
２１２ 課金処理部
３００ コンテンツサーバ
９００ 顧客サーバ
Ｎ１ ネットワーク。

Claims (7)

1. 端末からアクセス要求に対してサーバが認証を行う認証システムであって、
   前記サーバは、
   該認証の制御を行う認証制御部と、
   １又は複数の異なる認証方式の組み合わせから構成される複数の認証の組を登録する認証管理テーブルと、
   顧客に対する課金を処理する課金処理部と、を有し、
   前記認証制御部は、前記端末からのアクセス要求があると、前記認証管理テーブルを参照して、該アクセス要求に関連する認証の組を選択して、該選択された組に含まれる認証方式に基づいて、該端末との間で認証を行い、
   前記課金処理部は、前記認証の組を構成する前記認証方式の使用数を基に課金を計算することを特徴とする認証システム。
2. 前記サーバは、前記認証の組を構成する認証方式ごとに予め決めた単価と該認証方式の使用数を管理する課金テーブルを有し、
   前記課金処理部は、前記課金テーブルを用いて課金を計算し、
   前記処理部で計算された該課金の情報が顧客のサーバへ送信される、
   請求項１に記載の認証システム。
3. 前記課金処理部及び前記課金テーブルは、顧客情報の管理を行う管理サーバが有する、請求項１に記載の認証システム。
4. 前記認証方式の使用数は、所定期間内に前記認証方式が実際に使用された端末の数、又は前記認証方式の使用が予定されている端末の数に基づいた数である、
   請求項１乃至３のいずれかに記載の認証システム。
5. 前記認証管理テーブルは、１又は複数の異なる認証方式の組み合わせから構成される複数の認証の組をアカウントに対応付けて登録しており、
   前記アクセス要求はアカウントＩＤを有し、
   前記認証制御部は、前記アクセス要求が有する該アカウントＩＤに基づいて、前記認証管理テーブルの該アカウントに対応する認証の組を特定して、該認証の組に含まれる１又は複数の認証を実行し、
   前記課金処理部が用いる前記認証方式の使用数は、所定期間内に前記認証方式が実際に使用された前記アカウントの数、又は前記認証方式の使用が予定されている前記アカウントの数に基づいた数である、
   請求項２又は３に記載の認証システム。
6. 端末からアクセス要求に対してサーバが認証を行う認証方法であって、
   前記サーバは、
   該認証の制御を行う認証制御部と、１又は複数の異なる認証方式の組み合わせから構成される複数の認証の組を登録する認証管理テーブルと、顧客に対する課金を処理する課金処理部と、を有し、
   前記認証制御部は、前記端末からのアクセス要求があると、前記認証管理テーブルを参照して、該アクセス要求に関連する認証の組を選択して、該選択された組に含まれる認証方式に基づいて、該端末との間で認証を行い、
   前記課金処理部は、前記認証の組を構成する認証方式の使用数を基に課金を計算することを特徴とする認証方法。
7. 前記サーバは、前記認証の組を構成する認証方式ごとに予め決めた単価と該認証方式の使用数を管理する課金テーブルを有し、
   前記課金処理部は、前記課金テーブルを用いて課金を計算し、
   前記サーバは、前記処理部で計算された該課金の情報を顧客のサーバへ送信する、
   請求項６に記載の認証方法。

Images