JP2020107078A - 端末認証管理システムおよびその方法、およびそのプログラム - Google Patents

Abstract

【課題】非正規端末がネットワークに接続されることを防止し、ネットワークを介して接続される端末の真正性を確保する。【解決手段】ユーザが使用する端末からネットワークを通して送られる要求に対して、サーバが認証を行う認証管理システムであって、該サーバは、前記端末から送信される前記要求を取得する通信部と、前記通信部を介して該要求が取得された該端末の利用状況を判定する第１処理部と、該端末又は該ユーザの真正性を判定する第２処理部と、を有し、前記第１処理部による判定に応じて、前記第２処理部により該端末又は該ユーザの真正の判定を行わない。【選択図】 図１

Description

本発明は、端末認証管理システムおよびその方法、およびそのプログラムに係り、特にネットワークを介して接続される端末等の電子機器の真正性を検証する技術に関するものである。

パソコンやスマートフォン、タブレット等の端末をネットワークに接続して、日常業務を行うことが不可欠になっている。一方で、パスワードの流出や悪意のユーザによるなりすましによって、企業機密や個人情報が端末を通してネットワークに流出するという事態も起こっている。そのため、企業はネットワークに接続要求される端末の認証や接続条件、利用者の認証等のいろいろな対策を講じて、ネットワークへの情報の漏えい防止、およびセキュリティの強化を図っている。

セキュリティ関連の技術として、例えば、特許文献１には、ネットワークに接続するための端末装置が、適切なセキュリティの条件を満たしている場合に接続を許可するためのセキュリティ保全システムが開示されている。このセキュリティ保全システムは、電子証明書を記憶したカードから電子証明書を得て所定のネットワークへの接続条件を問合せる情報を送信し、応答情報により適合を判断し、適合と判断すると、応答情報付で所定のネットワークへの接続を要求する端末装置と、端末装置から所定のネットワークへの接続要求が来ると、管理部が管理している電子証明書を用いて端末装置のセキュリティ状態情報の所定のネットワークへの接続条件との適合を判断して接続を許可する認証判断部を備えた認証装置とにより構成される、としている。

また、特許文献２には、ユーザが公衆端末を使用し、セキュリティを要する情報を処理する前に、公衆端末を認証する技法が開示されている。この方法は、個人用装置２が端末に接続されると、第１の認証ステップが開始され、その間、端末がそれ自身をサーバ５に認証し、認証の成功に際して、サーバと端末のとの間で、第１の確実な認証済み接続が確立し、続いて第２の認証ステップが開始され、その間、確立済みの第１の認証済み接続を介してサーバがそれ自身を装置に認証し、認証の成功に際してサーバと装置との間で、第２の確実な認証済み接続が確立される、ユーザと前記端末との間の信頼できる接続を確立する方法、としている。

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

特許文献１に記載の技術では、所定の電子証明書を用いている限りネットワークへの接続が許可されるが、電子証明書の漏洩やなりすましに対してどのように対応するのかについては十分に言及されていない。また、特許文献２に記載の技術は、セキュリティを要する情報を処理する前に公衆端末の認証を行っているので、非正規端末がネットワークに接続されることが防止されるように思われる。しかし一方で、認証された端末が継続的に使用される場合、常に真正な端末であるかの検証については、十分に言及されていない。

本発明の目的は、非正規端末がネットワークに接続されることを防止し、ネットワークを介して接続される端末の真正性を確保することにある。
また、本発明は、当初の認証によってネットワークへの接続が許可された端末であっても、その後の端末の利用状態を監視し、真正性の検証に反映させることにある。

本発明の一態様にかかる端末認証管理システムは、ユーザが使用する端末からネットワークを通して送られる要求に対して、サーバが認証を行う認証管理システムであって、該サーバは、前記端末から送信される前記要求を取得する通信部と、前記通信部を介して該要求が取得された該端末の利用状況を判定する第１処理部と、該端末又は該ユーザの真正性を判定する第２処理部と、を有し、前記第１処理部による判定に応じて、前記第２処理部により該端末又は該ユーザの真正の判定を行わないことを特徴とする認証管理システムとして構成される。

また、本発明は、上記システムで行われる認証管理方法、認証管理プログラムとしても把握される。

本発明の一態様によれば、非正規端末がネットワークに接続されることを防止し、ネットワークを介して接続される端末の真正性を確保することができる。また、当初の認証によってネットワークへの接続が許可された端末であっても、その後の端末の利用状態を監視し、真正性の検証に反映させることができる。

実施例１にかかる端末認証管理システムの構成例を示す図である。 端末情報ＤＢの例を示す図である。 登録条件ＤＢの例を示す図である。 認証条件ＤＢの例を示す図である。 履歴条件ＤＢの例を示す図である。 履歴条件ＤＢの例を示す図である。 履歴条件ＤＢの他の例を示す図である。 承認依頼画面の例を示す図である。 実施例１で行われる端末管理のシーケンス図である。 実施例１で行われる端末の評価処理（Ｓ９１７）の処理手順を示すフローチャートである。 実施例２にかかる端末認証管理システムの構成例を示す図である。 認証方式選択テーブルの例を示す図である。 実施例２にかかる端末認証管理システムの他の構成例を示す図である。 認証方式設定テーブルの例を示す図である。

以下に添付図面を参照して、本発明にかかる端末認証管理システムおよびその方法、およびそのプログラムの実施の形態を詳細に説明する。

図１は、実施例１にかかる端末認証管理システム１０００の構成例を示す図である。
端末認証管理システムは、ネットワークを介して接続されるＰＣ（Personal Computer）やスマートフォン等の情報処理端末（以下、単に端末と呼ぶ。）が適正であるかを判定し、適正であると判定された端末に対して真正性の認証を行うシステムである。端末は、例えばスマートフォンであるが、ＰＣのほか、ネットワークに接続可能な様々な端末や電子機器について適用することができる。

端末認証管理システム１０００は、ユーザが使用する端末１００と、端末の真正性を認証する認証サーバ２００とが互いにネットワークＮ１を介して接続される。また、ネットワークＮ１には、正規に認証された端末１００にコンテンツを提供するコンテンツサーバ３００が接続される。ネットワークＮ１は、一般的な通信回線網である。また、認証サーバ２００には、管理者端末４００が接続される。

＜端末１００＞
端末１００は、ユーザによって操作されてコンテンツを利用する端末であり、例えば、スマートフォン等の一般的な端末から構成される。図１では、１台の端末１００が示されているが、実際には複数の端末１００がネットワークＮに接続される。

端末１００は、記憶部１０１と、固有情報取得部１０２を有したアプリケーション部１０４と、通信部１０３と、入出力部１０５と、位置測位部１０６とを有して構成される。記憶部１０１は、一般的な記憶装置から構成され、端末１００を識別するための固有情報１０１１と、認証サーバ２００から受信した、端末１００の判定結果情報１０１２とを記憶する。

固有情報１０１１は、例えば、端末１００の製造メーカ、端末１００のモデル名、端末１００のＭＡＣ（Media Access Control address）アドレスをはじめとするハードウェアに関連する、端末に固有の情報（以下、ハードウェア固有情報と呼ぶ。）を含む。また、端末１００にインストールされているＯＳ（Operating System）やそのバージョン名、ＯＳのユーザ名、ＯＳのメーカ名、ＯＳの発売日、ＯＳのサポート終了日、端末１００にインストールされているアプリケーションやそのバージョン名、アプリケーションのユーザ名、アプリケーションのメーカ名、アプリケーションの発売日、アプリケーションのサポート終了日をはじめとするソフトウェアに関連する、端末に固有の情報（以下、ソフトウェア固有情報と呼ぶ。）を含む。ソフトウェア固有情報には、さらに、ＯＳやアプリケーションのライセンスキーやその有効期限を含めてもよい。ここでは、ハードウェア固有情報とソフトウェア固有情報とを纏め、単に固有情報と呼ぶ。これらの固有情報には、固有情報が有効であるか無効であるかを示す有効性情報が対応付けられている。有効性情報は、テーブル作成時にあらかじめ登録される。固有情報１０１１の例については後述する。

判定結果情報１０１２は、端末１００の真正性の判定結果に関する情報である。判定結果情報１０１２には、判定結果のほか、上述した固有情報を含めてもよい。判定結果情報１０１２の例については後述する。

固有情報取得部１０２は、プログラムの実行によって実現される機能であって、端末１００の固有情報を認証サーバ２００に提供する処理部である。固有情報取得部１０２は、端末１００の固有情報を記憶部１０１から読み出して、認証サーバ２００に送信する。固有情報取得部１０２は、認証サーバ２００から、端末１００に対する判定結果を受信し、受信した判定結果を、記憶部１０１に判定結果情報１０１２として記憶する。

通信部１０３は、一般的な通信機器から構成され、ネットワークＮ１を介した各種情報の送受信を司る。

アプリケーション部１０４は、固有情報取得部１０２を含み、端末評価のための承認や評価に関する処理を実行する。なお、特に図示していないが、コンテンツサーバ３００のコンテンツを利用するアプリケーションについては、記憶部１０１に記憶されているものとする。

入出力部１０５は、一般的な入出力機器、入力機器および出力機器から構成され、各種情報の入力、固有情報取得部１０２やアプリケーション部１０４の処理結果を出力する。

位置測位部１０６は、端末１００の位置情報を取得する、例えば、ＧＰＳ（Global Positioning System）による測位を実現するアプリケーションである。位置測位部１０６は、他の測位方法、例えば、Ｗｉ−Ｆｉ測位、ビーコン測位、歩行者自立航法、ＩＭＥＳ（Indoor Messaging System）測位、地磁気測位を用いてもよい。

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

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

＜認証サーバ２００＞
認証サーバ２００は、端末１００の固有情報１０１１を用いて、端末が適正であるか否かを判定し、適正であると判定された端末を認証するサーバである。

認証サーバ２００は、記憶部２０１と、通信部２０２と、登録判定部２０３と、評価判定部２０４と、利用履歴保管部２０５と、利用情報管理部２０６と、管理部２０７と、認証部２０８とを有して構成されている。

記憶部２０１は、一般的な記憶装置から構成され、本システムに必要な各種データを記憶する。通信部２０２は、一般的な通信機器から構成され、ネットワークＮ１を介した各種情報の送受信を司る。

登録判定部２０３は、端末１００から受信した固有情報を用いて、端末１００を認証するための評価対象端末として承認するか否かを判定する。

評価判定部２０４は、端末１００から受信する固有情報と、端末１００の認証時の利用状態と、認証判定条件ＤＢ２０１３とを用いて端末１００を評価し、認証部２０８に真正性の認証をさせるか否かを判定する。

利用履歴保管部２０５は、端末１００の利用履歴を利用履歴テーブル５２１に記録する。利用履歴には、端末の起動や終了の履歴、認証のための判定結果、認証結果等の端末に対する様々な操作や処理の履歴を含む。

利用情報管理部２０６は、所定のタイミング（例えば、日時分秒）に利用履歴テーブル５２１の情報をもとに、端末設定テーブル２２３に記憶されている端末のランクの更新、および履歴条件ＤＢ２０１５の集計、更新を行う。本実施例では、利用情報管理部２０６は、所定のタイミングで後述する各種テーブル（時間帯条件テーブル６２１、継続時間条件テーブル６２２、認証結果条件テーブル６２３、利用頻度条件テーブル７２１、不審利用条件テーブル７２２、モデル認証結果条件テーブル７２３、位置情報条件テーブル７２４）を集計し、更新する場合を例示しているが、リアルタイムに行ってもよい。この場合、認証のための判定の精度がより一層向上する。

管理部２０７は、認証サーバ２００の各部の動作を制御する。
認証部２０８は、評価判定部２０４が認証要と判定した場合、その端末１００及び又は端末を使用するユーザの真正性の認証を行う。認証サーバ２００の各部の具体的な動作については後述する。
コンテンツサーバ３００は、認証部２０８が認証した端末１００に対して、リクエストされたコンテンツを提供するサーバである。

＜管理者端末４００＞
管理者端末４００は、端末１００を評価対象端末として承認する端末である。管理者端末４００は、入力部４０１と、表示部４０２と、制御部４０３と、を備えたＰＣ等のコンピュータである。入力部４０１は、例えば、キーボード等の入力機器である。表示部４０２は、例えば、ＬＣＤ等のディスプレイ装置である。制御部４０３は、ＣＰＵ等の演算装置である。管理者端末４００は、認証サーバ２００に接続される。

図８は、管理者端末４００の表示部４０２に表示される画面（承認依頼画面）の例を示す図である。承認依頼画面には、端末の利用者であるユーザＡ（ユーザＩＤ：Ｕ０００１）と、ユーザＡが使用する端末１００の端末名称（端末ＩＤ）であるＴＥＲＭＩＮＡＬ０１（Ｔ０００１）とが表示されている。また、これらの情報に加え、端末の固有情報が、端末状態として表示される。

図８では、Ｔ０００１の端末は、固有情報に、製造メーカ「Ｃ社」、モデル「Ｃ１」、ＯＳ「ｃ１」が含まれ、図３に示した端末条件テーブル３２１において、端末を評価するための条件（条件１）として、これらと同じ端末条件が記憶されているため、当該端末を評価対象端末とすることが妥当（ＯＫ）であると判定された判定結果情報１０１２を示している。また、Ｔ０００１の端末は、固有情報に、端末１００にはソフト「ｘ」、「ｙ」、「ｚ」がインストールされ、図３に示したアプリ条件テーブル３２２において、端末を評価するための条件（条件２）として、これらと同じアプリ条件が記憶されているため、当該端末を評価対象端末とすることが妥当（ＯＫ）であると判定された判定結果情報１０１２を示している。さらに、図８では、固有情報に位置条件が含まれていたが、図３に示した位置条件テーブル３２３において、端末を評価するための条件（条件３）として、位置条件（例えば、ＩＰアドレス）が記憶されていないため、位置条件については該当なしであると判定された判定結果情報１０１２を示している。

本システムの管理者は、承認依頼画面に表示されたこれらの情報を確認し、認証のための評価対象端末として承認してもよいと判断した場合に承認ボタン８０１を押下する。一方、認証のための評価対象端末として承認することが望ましくないと判断した場合は却下ボタン８０２を押下する。いずれかのボタンが押下されると、画面に表示したこれらの情報が認証サーバ２００に送信される。これらの判定は、登録判定部２０３が自動的に行ってもよい。例えば、登録判定部２０３は、端末条件、アプリ条件、位置条件の全てについて、判定結果情報１０１２に、評価対象端末とすることが妥当（ＯＫ）である旨が記録されている場合に、当該端末を評価対象端末として承認してもよい。

記憶部２０１は、一般的な記憶装置から構成され、端末情報ＤＢ（Data Base）２０１１と、登録判定条件ＤＢ２０１２と、認証判定条件ＤＢ２０１３と、利用履歴ＤＢ２０１４と、履歴条件ＤＢ２０１５とを記憶する。各ＤＢの構成については後述する。

＜端末情報ＤＢ２０１１＞
図２は、端末情報ＤＢ２０１１の例を示す図である。端末情報ＤＢ２０１１は、固有情報１０１１のほか、端末１００のアカウント情報を記憶するデータベースである。端末情報ＤＢ２０１１は、アカウントテーブル２２１と、端末モデルテーブル２２２と、端末設定テーブル２２３とを有している。

図２（Ａ）に示す、アカウントテーブル２２１は、端末１００を利用するためのアカウントに関する情報を管理するテーブルである。アカウントテーブル２２１は、端末１００を使用するユーザが属する企業を識別するための企業ＩＤと、端末１００を使用するユーザを識別するためのユーザＩＤと、ユーザＩＤにより識別されるユーザの企業における所属および役職と、ユーザの氏名と、ユーザが使用する端末１００のリストを示す利用端末リストとが対応付けて記憶される。利用端末リストには、例えば、端末ＩＤの一覧が記憶される。

図２（Ｂ）に示す、端末モデルテーブル２２２は、端末１００のモデルに関する情報を管理するテーブルである。端末モデルテーブル２２２は、端末１００のモデルを識別するためのモデルＩＤと、モデルＩＤにより識別されるモデルの端末を製造したメーカ名および機種と、端末にインストールされているＯＳ名と、端末の発売日および発売終了日とが対応付けて記憶される。これらの情報には、端末モデルテーブル２２２の情報が有効であるか無効であるかを示す有効性情報が対応付けられている。有効性情報は、テーブル作成時にあらかじめ登録される。

図２（Ｃ）に示す、端末設定テーブル２２３は、端末１００の設定に関する情報を管理するテーブルである。端末設定テーブル２２３は、端末１００を識別するための端末ＩＤと、端末ＩＤに対応付けられているモデルＩＤと、ユーザＩＤと、固有情報１０１１で示した固有情報と、端末１００のランクとが対応付けて記憶される。ランクは、真正性が検証された端末に対する対処のレベルを示す情報である。例えば、上位からランクＳ、Ａ、Ｂ、Ｃの４段階に区分され、ランク別に利用の対処を異ならせる。これについては詳しく後述する。

アカウントテーブル２２１、端末モデルテーブル２２２は、ユーザまたは管理者の判断に従ってあらかじめ登録される。端末設定テーブル２２３は、後述する処理が実行されることにより登録される。

＜登録判定条件ＤＢ２０１２＞
図３は、登録判定条件ＤＢ２０１２の例を示す図である。登録判定条件ＤＢ２０１２は、端末１００の本システムへの登録の判定条件を管理するためのデータベースである。端末１００の真正性を検証するためには、あらかじめ端末の固有情報や利用環境を判定することが有効である。その理由は、端末が使用される環境は、企業、企業に所属する従業員（端末のユーザ）によって異なるためである。端末１００の真正性を検証することで、端末のなりすましや偽の情報が偽であることを確認することができる。

登録判定条件ＤＢ２０１２は、端末条件テーブル３２１と、アプリ条件テーブル３２２と、位置条件テーブル３２３とを有している。

図３（Ａ）に示す、端末条件テーブル３２１は、評価対象とする端末１００の条件を定めたテーブルである。端末条件テーブル３２１は、評価対象とする端末の条件として、企業ＩＤと、端末１００のメーカ名と、端末１００のモデル名と、端末１００にインストールされているＯＳ名と、端末１００の発売日および終了日とが対応付けて記憶される。端末条件テーブル３２１は、端末の仕様が、企業で使用される仕様であるか否かを判定するためのテーブルであるといえる。

図３（Ａ）では、例えば、企業ＩＤ「０００１」で識別される企業では、Ａ社、Ｂ社の異なるモデルの端末１００を使用しており、モデルおよびＯＳは、それぞれ、Ａ１およびａ、Ｂ１およびｂ１、Ｂ２およびｂ２であることを示している。また、これらの端末１００の発売日およびサポート終了日は、それぞれ、２０１６年１０月および２０２０年３月、２０１４年１月および２０１８年３月、２０１６年１０月および２０２０年３月であることを示している。これらの情報には、端末条件テーブル３２１の情報が有効であるか無効であるかを示す有効性情報が対応付けられている。有効性情報は、テーブル作成時にあらかじめ登録される。

図３（Ｂ）に示す、アプリ条件テーブル３２２は、評価対象とする端末１００にインストールされているアプリケーションの条件を定めたテーブルである。アプリ条件テーブル３２２は、企業ＩＤと、端末１００にインストールされているソフトウェア名と、ソフトウェアのメーカ名と、ソフトウェアのバージョンとが対応付けて記憶される。アプリ条件テーブル３２２は、端末にインストールされているアプリケーションの仕様が、企業で使用される仕様であるか否かを判定するためのテーブルであるといえる。

図３（Ｂ）では、例えば、企業ＩＤ「０００２」で識別される企業は、メーカ名が、Ｘ社、Ｙ社、Ｚ社のソフトウェアであるソフト名ｘ、ｙ、ｚのソフトウェアを端末１００にインストールしており、それぞれのバージョンは、１５、２０１７、５７であることを示している。これらの情報には、アプリ条件テーブル３２２の情報が有効であるか無効であるかを示す有効性情報が対応付けられている。有効性情報は、テーブル作成時にあらかじめ登録される。

図３（Ｃ）に示す、位置条件テーブル３２３は、評価対象とする端末１００が使用される位置や範囲の条件を定めたテーブルである。位置条件テーブル３２３は、企業ＩＤと、端末１００のＩＰアドレスとが対応付けて記憶される。位置条件テーブル３２３は、端末が使用される位置が、企業で想定される場所や地理的範囲にあるか否かを判定するためのテーブルであるといえる。

図３（Ｃ）では、例えば、企業ＩＤ「０００３」で識別される企業は、端末１００の使用場所が、ＩＰアドレス「１０．２０．３０．０」、「１００．２００．３００．０」、「３９．１１０．２０６．９６」のいずれかの場所で使用されなければならないことを示している。これらの情報には、位置条件テーブル３２３の情報が有効であるか無効であるかを示す有効性情報が対応付けられている。有効性情報は、テーブル作成時にあらかじめ登録される。

＜認証判定条件ＤＢ２０１３＞
図４を参照するに、認証判定条件ＤＢ２０１３は、本システムに登録された端末１００を認証させるか否かを判定するためのデータベースである。認証判定条件ＤＢ２０１３は、認証判定条件テーブル４２１を有している。

認証判定条件テーブル４２１は、端末１００を認証部２０８で認証させるために、端末１００の評価を行うための条件および当該条件を用いて上記評価が行われたときの対処を管理するテーブルである。認証判定条件テーブル４２１は、企業ＩＤと、端末を評価するための条件値（条件１〜Ｎ）と、条件を適用するための真理値と、端末１００のランクに応じて行われる対処とが対応付けて記憶されている。

図４では、例えば、企業ＩＤが「０００２」で識別される企業で使用される端末は、条件１（例えば、端末条件値）、条件２（例えば、アプリ条件値）がいずれも「１」であり、真理値が「ＡＮＤ」である。このため、条件１、条件２の両方の条件を満たさなければ、端末を認証部２０８に認証させることが妥当でないと判定される。端末条件値は、端末１００が端末条件テーブル３２１に記憶される条件を満たすことを要求することを示す値である。アプリ条件値は、端末１００がアプリ条件テーブル３２２に記憶される条件を満たすことを要求することを示す値である。認証が妥当でないと判定された端末１００は、ランクＳ、ランクＡ、ランクＢ、ランクＣのいずれのランクの場合も、エラーとして対処される。また、例えば、企業ＩＤが「０００３」で識別される企業は、条件１〜３がいずれも「１」であり、真理値が「ＯＲ」である。このため、条件１〜３のいずれか１つの条件も満たさなければ、端末を認証部２０８に認証させることが妥当でないと判定される。条件３（例えば、位置条件値）は、端末１００が位置条件テーブル３２３に記憶される条件を満たすことを要求することを示す値である。認証させることが妥当でないと判定された端末１００は、ランクＳの場合は警告として対処され、ランクＡ、ランクＢ、ランクＣの場合は、エラーとして対処される。

「警告」として対処されると、端末のランクが上位ランクから下位ランクに格下げとなる。また、「警告」として対処される回数が閾値となる所定の回数（例えば、３回）を超えると、「エラー」と同様の対処が行われる。「エラー」として対処されると、管理者端末４００にその旨が通知され、次回以降、管理者承認の元で再登録等の処置が必要となる。認証判定条件テーブル４２１に登録する条件については後述する。

＜利用履歴ＤＢ２０１４＞
図５は、利用履歴ＤＢ２０１４の例を示す図である。利用履歴ＤＢ２０１４は、端末１００の利用履歴を管理するためのデータベースである。利用履歴ＤＢ２０１４は、利用履歴テーブル５２１を有している。

利用履歴テーブル５２１は、端末１００の利用履歴を管理するテーブルである。利用履歴テーブル５２１は、日時と、端末ＩＤと、端末からのアクセスをはじめとする端末の利用に関するエラー情報と、位置情報と、ＩＰアドレスとが対応付けて記憶される。図５では、例えば、ある端末ＩＤ「Ｔ０００１」およびＩＰアドレス「１０．２０．３０．０」の端末１００が、２０１８年６月１０日に本システムにログインしたときには端末のエラーがなかったことを示している。また、このときの位置情報がαであったことを示している。位置情報は、端末１００の位置測位部１０６により取得される。利用履歴テーブル５２１には、本システムに登録されたすべての端末１００の利用履歴が時系列に蓄積されている。

＜履歴条件ＤＢ２０１５＞
図６を参照するに、履歴条件ＤＢ２０１５は、利用履歴テーブル５２１の認証履歴を用いて認証判定条件テーブル４２１の条件（条件１〜Ｎ）を定めたデータベースである。履歴条件ＤＢ２０１５は、時間帯条件テーブル６２１と、継続時間条件テーブル６２２と、認証結果条件テーブル６２３とを有している。

図６（Ａ）に示す、時間帯条件テーブル６２１は、端末が使用される時間帯を用いた端末の評価結果を、認証部２０８に認証させるための条件としたテーブルである。時間帯条件テーブル６２１は、ユーザＩＤと、端末ＩＤと、端末の使用時間帯と、使用時間帯の割合とが対応付けて記憶される。

図６（Ａ）では、例えば、ユーザＩＤ「Ｕ０００１」が使用する端末ＩＤ「Ｔ０００１」で識別される端末は、ある期間（例えば、過去１ヶ月間）のうち９８パーセントが１２時から１５時の間に使用されていることを示している。すなわち、端末ＩＤ「Ｔ０００１」の端末は、日常的に上記時間帯で使用されるため、当該時間帯における使用は真正な端末の使用であると推定することができる。つまり、９時から１２時の時間帯では、当該端末における認証の怪しさは２パーセントである。また、端末ＩＤ「Ｔ０００１」の端末が２１時から翌日の９時の間に使用された割合は０％である。したがって、当該時間帯に使用された端末は、真正でない端末であることが強く推定される。

時間帯条件テーブル６２１は、利用情報管理部２０６が、利用履歴テーブル５２１を所定のタイミング（例えば、１ヶ月に１回）で、利用履歴（例えば、利用履歴テーブル５２１の認証日時）を、ユーザごとおよび端末ごとに集計して得ることができる。

本システムでは、上記のように使用時間帯の割合だけでなく、さらに、時間帯条件テーブル６２１に対応付けて、ユーザの属性（例えば、職種）ごとに、認証部２０８に認証させるための条件として時間帯−属性判定テーブル６２１ａを保持することができる。時間帯−属性判定テーブル６２１ａでは、ユーザの職種（例えば、技術職、営業職、アルバイト）ごとに、使用時間帯の割合（または怪しさ）に基づいて、端末を認証させることが妥当であるか否かを定めている。

図６（Ａ）では、例えば、端末が、ユーザの職種が技術職であるユーザにより使用される端末である場合には、いずれの時間帯でも使用時間帯の割合（または怪しさ）の値に関わらず、認証部２０８による認証可（認証ＯＫ）と判定され、認証させることが妥当であると判断される。一方、端末が、ユーザの職種が営業職であるユーザにより使用される端末である場合には、２１時から翌朝９時までの時間帯では認証部２０８による認証不可（認証ＮＧ）と判定され、認証させることが妥当でないと判断される。つまり、端末が使用される時間帯が同じ時間帯であっても、認証部２０８による認証を行わせることが妥当である場合と、妥当でない場合とが生じる。その理由は、技術職の場合にはシステム保守等により夜遅くから明け方にかけて端末が使用される可能性があるためであり、また、営業職の場合には基本的に夜遅くから明け方にかけて端末が使用されることがないためである。端末を使用するユーザの職種については、例えば、利用情報管理部２０６が、時間帯条件テーブル６２１で集計した端末ＩＤと同じ端末ＩＤを含むアカウントテーブル２２１を参照し、当該端末ＩＤに対応するユーザＩＤ、所属、役職を読み取ればよい。

このように、端末１００が使用される時間帯の集計結果を用いることで、認証部２０８により認証させることが妥当であるか否かを判断することができる。さらに、端末を使用するユーザの属性に応じて、認証部２０８により認証させることが妥当であるか否かを判断する。このため、端末の使用時間帯やユーザの属性を考慮して、認証部２０８により認証させるための条件を定めることができる。

図６（Ｂ）に示す、継続時間条件テーブル６２２は、端末が使用された継続時間を用いた端末の評価結果を、認証部２０８に認証させるための条件としたテーブルである。継続時間条件テーブル６２２は、ユーザＩＤと、端末ＩＤと、端末の利用継続時間と、利用継続時間の割合とが対応付けて記憶される。

図６（Ｂ）では、例えば、ユーザＩＤ「Ｕ０００１」が使用する端末ＩＤ「Ｔ０００１」で識別される端末は、ある期間（例えば、過去１ヶ月間）のうち９８パーセントが、５分から１５分の間使用されていることを示している。すなわち、端末ＩＤ「Ｔ０００１」の端末は、日常的に５分から１５分の間で使用されるため、当該時間内での使用は真正な端末の使用であると推定することができる。つまり、５分から１５分の間の使用では、当該端末における認証の怪しさは２パーセントである。また、端末ＩＤ「Ｔ０００１」の端末が３０分以上継続して使用される割合は０．５％である。したがって、当該時間以上継続使用された端末は、真正でない端末であることが強く推定される。

継続時間条件テーブル６２２は、利用情報管理部２０６が、利用履歴テーブル５２１を所定のタイミング（例えば、１ヶ月に１回）で、認証履歴（例えば、利用履歴テーブル５２１の認証日時に含まれるログイン時刻やログアウト時刻）を、ユーザごとおよび端末ごとに集計して得ることができる。

このように、端末１００の利用継続時間の集計結果を用いることで、認証部２０８により認証させることが妥当であるか否かを判断することができる。このため、端末の使用継続時間を考慮して、認証部２０８により認証させるための条件を定めることができる。

図６（Ｃ）に示す、認証結果条件テーブル６２３は、端末の認証結果を用いた端末の評価結果を、認証部２０８に認証させるための条件としたテーブルである。認証結果条件テーブル６２３は、ユーザＩＤと、端末ＩＤと、認証部２０８による認証結果と、認証可否の割合とが対応付けて記憶される。ユーザが複数の端末を使用している場合には、それぞれの端末についてテーブルが保持される。

図６（Ｃ）では、例えば、あるユーザは、端末ＩＤ「Ｔ０００１」および端末ＩＤ「Ｔ０００２」の２台の端末１００を使用し、前者の端末における認証は、ある期間（例えば、過去１ヶ月間）のうち９８パーセントが１回で成功している。すなわち、端末ＩＤ「Ｔ０００１」の端末は、日常的に１回で認証に成功しているため、当該端末の使用は真正な端末の使用であると推定することができる。つまり、端末ＩＤ「Ｔ０００１」の端末における認証の怪しさは２パーセントである。また、同期間において２回目以降で認証に成功した割合は１．０パーセントであるため、当該端末における認証の怪しさは９９．０％である。すなわち、端末ＩＤ「Ｔ０００１」の端末において２回で認証に成功した場合は、真正な端末の使用でないと推定することができる。その他、失敗１（パスワードの誤入力）、失敗２（通信エラー）等の認証結果についても同様に考えることができる。

認証結果条件テーブル６２３は、利用情報管理部２０６が、利用履歴テーブル５２１を所定のタイミング（例えば、１ヶ月に１回）で、認証履歴（例えば、利用履歴テーブル５２１の認証エラー）を、ユーザごとおよび端末ごとに集計して得ることができる。

また、本システムでは、認証結果だけでなく、さらに、認証結果条件テーブル６２３に対応付けて、端末の種類（例えば、固定端末か携帯端末か）ごとに、端末を認証部２０８に認証させるための条件として認証結果−種類判定テーブル６２３ａを保持することができる。認証結果−種類判定テーブル６２３ａでは、端末の種類（例えば、固定端末、携帯端末（ＯＳ１）、携帯端末（ＯＳ２））ごとに、認証結果の割合（または怪しさ）に基づいて、端末を認証させることが妥当であるか否かを定めている。

図６（Ｃ）では、例えば、端末ＩＤ「Ｔ０００１」の端末が固定端末である場合には、１回で認証成功した場合のみ認証部２０８による認証可（認証ＯＫ）と判定される。一方、端末が携帯端末の場合には、認証結果としてエラー２（通信エラー）が生じた場合以外は認証部２０８による認証ＯＫと判定される。つまり、同じ認証結果が得られた場合であっても、固定端末の場合には通常ユーザが社内で使用する端末であるため認証部２０８により認証させることが妥当であると判定する基準を上げてハードルを高くする。一方、携帯端末の場合には移動中の操作等による誤入力や通信環境の変化があるため、認証部２０８により認証させることが妥当であると判定する基準を下げてハードルを低くする。端末の種類については、例えば、利用情報管理部２０６が、認証結果条件テーブル６２３で集計した端末ＩＤと同じ端末ＩＤを含む端末設定テーブル２２３を参照し、当該端末ＩＤに対応する固有情報を読み取ればよい。

このように、端末１００の認証結果の集計結果を用いることで、認証部２０８により認証させることが妥当であるか否かを判断することができる。さらに、端末の種類に応じて、認証部２０８により認証させることが妥当であるか否かを判断することができる。このため、端末の種類を考慮して、認証部２０８により認証させるための条件を定めることができる。また、上記認証結果は、どのようなプロセスを経て得られたものなのか（例えば、１回の入力操作で認証成功したのか、２回以上の入力操作で認証成功したのか）により分類されているため、認証結果が得られるまでのプロセスを考慮して、認証部２０８により認証させるための条件を定めることができる。

＜履歴条件ＤＢ２０１５＞
図７は、履歴条件ＤＢ２０１５の他の例を示す図である。履歴条件ＤＢ２０１５は、利用頻度条件テーブル７２１と、不審利用条件テーブル７２２と、モデル認証結果条件テーブル７２３と、位置情報条件テーブル７２４とを有している。

図７（Ａ）に示す、利用頻度条件テーブル７２１は、端末の使用頻度を用いた端末の評価結果を、認証部２０８に認証させるための条件としたテーブルである。利用頻度条件テーブル７２１は、ユーザＩＤと、端末ＩＤと、認証成功回数と、認証失敗回数と、ウィークデイの利用頻度と、ウィークデイ以外の利用頻度とが対応付けて記憶される。

図７（Ａ）では、端末Ｔ０００１と端末Ｔ０００２は、９対１の割合でウィークデイとウィークデイ以外で使用され、端末Ｔ０００１では認証部２０８による端末の認証が毎回認証成功している（認証失敗ゼロである）。一方、端末Ｔ０００２では、認証部２０８による認証失敗が３回ある。また、端末Ｔ０００２は必ずウィークデイ以外の夜間に利用されている。つまり、端末Ｔ０００１は昼間に会社に出勤しているときに使用され、端末Ｔ０００２は週末に自宅で使用されていると推定される。このように、同じユーザであっても使用する端末の頻度や使用環境は異なる。このため、例えば、セキュリティが整った環境で頻繁に使用されている端末は優良端末であると考えて、認証部２０８に認証させるための条件を緩やかに設定する。一方、セキュリティが整っているか否か定かではない環境でスポット的に使用されている端末はセキュリティリスクが内在する端末であると判断して、認証部２０８に認証させるための条件を厳しく設定する等、認証させることが妥当であると判断するための条件に重み付けを行うことができる。

図７（Ａ）に示す利用頻度条件テーブル７２１は、利用情報管理部２０６が、利用履歴テーブル５２１を所定のタイミング（例えば、１ヶ月に１回）で、利用履歴（例えば、利用履歴テーブル５２１の日時、認証エラー）を、端末ごとに集計して得ることができる。

不審利用条件テーブル７２２は、ユーザの重複使用を用いた端末の評価結果を、認証部２０８に認証させるための条件としたテーブルである。重複使用とは、例えば、あるユーザがある端末で認証成功してから所定の時間（例えば、３０分）の間に、別の端末で認証成功した場合等、２以上の端末で認証成功となった状態での使用である。不審利用条件テーブル７２２は、ユーザＩＤと、端末ＩＤと、重複回数とが対応付けて記憶される。

図７（Ｂ）では、Ｔ０００１の端末およびＴ００２の端末では、認証成功してから所定の時間経過後に別の端末で認証成功したことによる重複使用がない。しかし、Ｔ０００３の端末は、他の端末が認証成功した状態で、認証成功となったことが５回あることを示している。つまり、端末Ｔ０００３は、本来のユーザではない他人により使用されている可能性が高いと考えることができる。このため、例えば、過去に重複使用された端末はハッキングのリスクが高い端末であると考えて、認証部２０８に認証させるための条件を厳しく設定する一方、過去に重複使用されていない端末はハッキングのリスクが低い端末であると判断して、認証部２０８に認証させるための条件を緩く設定する等、認証させることが妥当であると判断するための条件に重み付けを行うことができる。

図７（Ｂ）に示す不審利用条件テーブル７２２は、利用情報管理部２０６が、利用履歴テーブル５２１を所定のタイミング（例えば、１ヶ月に１回）で、利用履歴（例えば、利用履歴テーブル５２１の日時、端末ＩＤ、認証エラーに含まれるユーザＩＤ）を、端末ごとに集計して得ることができる。

モデル認証結果条件テーブル７２３は、端末のモデルに応じた認証結果を用いた端末の評価結果を、認証部２０８に認証させるための条件としたテーブルである。モデル認証結果条件テーブル７２３は、モデルＩＤと、認証部２０８による認証結果と、認証部２０８による認証回数とが対応付けて記憶される。図７では、モデルＡ１の端末では、ある期間（例えば、過去１ヶ月間）のうち７０パーセントが１回で認証に成功しており、２回目以降で認証に成功した割合は２０パーセントであることを示している。その他、失敗１（パスワードの誤入力）、失敗２（通信エラー）等の認証結果の内訳ごとに、認証割合が記憶されている。一方、モデルＢ１の端末では、上記期間のうち９８パーセントが１回で認証に成功しており、２回目以降で認証に成功した割合は１パーセントであることを示している。その他、失敗１（パスワードの誤入力）、失敗２（通信エラー）等の認証結果の内訳ごとに、認証割合が記憶されている。つまり、同じ端末（例えば、端末Ｔ０００１）であっても、モデルの違いにより、認証部２０８による認証結果が異なると考えることができる。このため、例えば、認証成功の割合が高いモデルの端末は優良端末であると考えて、認証部２０８に認証させるための条件を緩やかに設定する一方、認証成功の割合が低いモデルの端末はセキュリティリスクが内在する端末であると考えて、認証部２０８に認証させるための条件を厳しく設定する等、認証させることが妥当であると判断するための条件に重み付けを行うことができる。このように、端末のモデルごとの認証結果の統計値を分析することにより、どのモデルの端末が認証成功されやすいのかを把握することができる。

図７（Ｃ）に示すモデル認証結果条件テーブル７２３は、利用情報管理部２０６が、利用履歴テーブル５２１を所定のタイミング（例えば、１ヶ月に１回）で、利用履歴（例えば、利用履歴テーブル５２１の日時、端末ＩＤ、認証エラー、端末設定テーブル２２３のモデルＩＤ）を、端末ごとに集計して得ることができる。

位置情報条件テーブル７２４は、端末の位置を用いた端末の評価結果を、認証部２０８に認証させるための条件としたテーブルである。位置情報条件テーブル７２４は、ユーザＩＤと、端末ＩＤと、位置情報と、認証回数とが対応付けて記憶される。図７では、ユーザＵ０００１により使用された端末Ｔ０００１は、アメリカから６０回およびメキシコから１２回認証成功したことを示している。また、端末Ｔ０００２は、カナダから１００回認証成功したことを示している。つまり、端末が使用される場所の違いにより認証部２０８による認証結果が異なると考えることができる。このため、例えば、認証成功の割合が高い場所にある端末は優良端末であると考えて、認証部２０８に認証させるための条件を緩やかに設定する一方、認証成功の割合が低い場所にある端末はセキュリティリスクが内在する端末であると考えて、認証部２０８に認証させるための条件を厳しく設定する等、認証させることが妥当であると判断するための条件に重み付けを行うことができる。このように、端末の場所ごとの認証結果の統計値を分析することにより、どの場所の端末が認証成功されやすいのかを把握することができる。

図７（Ｄ）に示す位置情報条件テーブル７２４は、利用情報管理部２０６が、利用履歴テーブル５２１を所定のタイミング（例えば、１ヶ月に１回）で、利用履歴（例えば、利用履歴テーブル５２１の位置情報）を、端末ごとに集計して得ることができる。位置情報条件テーブル７２４は、ユーザＩＤに対応して、利用端末ＩＤ，位置情報、および認証回数が記憶される。

＜端末認証管理シーケンス＞
図９は、本システムで行われる端末認証管理のシーケンス図である。本システムにおける端末管理は、登録フェーズと、認証フェーズの２つのフェーズが含まれる。認証フェーズはさらに、端末の利用状態を判定する評価フェーズと、端末又はユーザの真正性を判定する真正認証フェーズに分れる。

＜登録フェーズ＞
まず、登録フェーズでの処理について説明する。
管理者端末４００は、端末情報ＤＢ２０１１のアカウントテーブル２２１および端末モデルテーブル２２２（図２）、登録判定条件ＤＢ２０１２（図３）、認証判定条件ＤＢ２０１３（図４）に格納するデータを、認証サーバ２００に送信し、登録する（Ｓ９０１）。

ユーザＵの操作により、固有情報取得部１０２の動作を行うプログラムが端末１００にインストールされる（Ｓ９０２、Ｓ９０３）。例えば、ユーザＵは、上記操作として、固有情報取得部１０２の動作を行うプログラムが格納されたウェブサイトからインターネットを介してダウンロードする。アプリケーション部１０４が、ダウンロードされた固有情報取得部１０２の動作を行うプログラムを取り込む。

ユーザＵが端末１００を操作してアプリケーション部１０４の動作を行うプログラムを起動すると、アプリケーション部１０４が、固有情報取得部１０２の動作を行うプログラムを起動する（Ｓ９０４、Ｓ９０５）。そして、固有情報取得部１０２が、端末１００の記憶部１０１に記憶されている端末ＩＤ、位置情報、ＩＰアドレス等の端末情報と、固有情報１０１１を取得して、認証サーバ２００へ送信する（Ｓ９０６）。

認証サーバ２００は、端末１００から受信した固有情報１０１１が、記憶部２０１に登録された登録判定条件ＤＢ２０１２（図３）に記憶されている条件と同一か否かを判定することにより、端末１００が登録された端末であるか否かを判定する（Ｓ９０７）。具体的には、登録判定部２０３は、固有情報１０１１が、登録判定条件ＤＢ２０１２の端末条件テーブル３２１、アプリ条件テーブル３２２、位置条件テーブル３２３に記憶されている端末条件、アプリ条件、位置条件を満たす組み合わせである場合、端末１００が評価対象として登録されている端末であると判定する。端末条件、アプリ条件、位置条件のそれぞれに対応する判定結果は、判定結果情報１０１２として端末１００に出力される。

利用履歴保管部２０５は、端末１００の利用履歴を利用履歴テーブル５２１に記録する（Ｓ９０８）。

登録判定部２０３は、端末１００が登録されていない端末であると判定した場合、その旨を示す登録判定結果を含む判定結果情報１０１２を端末１００に送信する（Ｓ９０９ａ１）。端末１００の固有情報取得部１０２は、認証サーバ２００から受信した端末１００の登録判定結果を入出力部１０５に出力する（Ｓ９０９ａ２）。例えば、入出力部１０５には、「端末１００の評価ができません。」というメッセージが表示される。

登録判定部２０３は、端末１００が登録されている端末であると判定した場合、評価対象として登録されている端末であることを承認中である旨の経過を含む判定結果情報１０１２を端末１００に送信し（Ｓ９０９ｂ１）、端末１００の固有情報取得部１０２は、認証サーバ２００から受信した端末１００が承認中である旨の経過を入出力部１０５に出力する（Ｓ９０９ｂ２）。例えば、入出力部１０５には、「端末１００が評価されるまでしばらくお待ちください。」というメッセージが表示される。

登録判定部２０３は、端末１００が登録されている端末であると判定した場合、管理者端末４００に対して、端末１００を評価することの承認を依頼する（Ｓ９１０）。具体的には、登録判定部２０３は、登録されていると判定した端末１００の固有情報１０１１と判定結果情報１０１２とを、管理者端末４００に送信する。

管理者端末４００は、認証サーバ２００から受信した承認依頼に含まれる固有情報１０１１、判定結果情報１０１２を含む承認依頼画面（図８）を表示部４０２に表示し、管理者から、承認または却下のいずれかの入力を受け付ける（Ｓ９１１）。

管理者端末４００は、Ｓ９１１で却下の場合にはその旨を示す承認結果を認証サーバ２００に送信し（Ｓ９１２ａ１）、認証サーバ２００の登録判定部２０３は、承認結果を端末１００に送信する（Ｓ９１２ａ２）。端末１００の固有情報取得部１０２は、認証サーバ２００から受信した承認結果を入出力部１０５に出力する（Ｓ９１２ａ３）。例えば、入出力部１０５には、「端末１００の承認が却下されました。」というメッセージが表示される。

管理者端末４００は、Ｓ９１１で承認の場合にはその旨を示す承認結果を認証サーバ２００に送信し（Ｓ９１２ｂ１）、認証サーバ２００の登録判定部２０３は、端末ＩＤを含む承認結果を端末１００に送信する（Ｓ９１２ｂ２）。端末１００の固有情報取得部１０２は、認証サーバ２００から受信した承認結果を入出力部１０５に出力する（Ｓ９１２ｂ３）。例えば、入出力部１０５には、「端末ＩＤ（Ｔ０００１）の端末１００が評価対象として承認されました。」というメッセージが表示される。

Ｓ９１２ａ１において、管理者端末４００から承認結果を受信すると、認証サーバ２００の利用履歴保管部２０５は、端末１００の承認履歴を利用履歴テーブル５２１に記録する（Ｓ９１３ａ）。

Ｓ９１２ｂ１において、管理者端末４００から承認結果を受信すると、認証サーバ２００の利用履歴保管部２０５は、端末１００の承認履歴を利用履歴テーブル５２１に記録し、登録判定部２０３は、端末設定テーブル２２３（図２）に、評価対象として承認された端末１００の端末ＩＤ、モデルＩＤ、ユーザＩＤ、固有情報１０１１、端末のランクを登録する（Ｓ９１３ｂ）。

ユーザＩＤは、例えば、登録判定部２０３が、端末１００から受信した端末ＩＤと同じ端末ＩＤに対応するユーザＩＤをアカウントテーブル２２１から読み出せばよい。また、モデルＩＤは、例えば、登録判定部２０３が、固有情報１０１１と同じメーカ、モデル、ＯＳを含む端末モデルのモデルＩＤを端末条件テーブル３２１から読み出せばよい。端末のランクについては、過去のアクセス履歴などから夜間バッチ処理を行うことにより定めればよい。登録時のランクについては、あらかじめ企業ＩＤにより識別される企業ごとに定めておけばよい。

以上の処理を行うことにより、例えば、あらかじめ企業が定めた条件に合致した端末であって、管理者により承認された端末のみを、認証部２０８による認証を行うための評価対象とすることができる。これにより、なりすまし端末等の非正規端末が認証のための評価対象端末として承認されるリスクを排除することができる。

＜評価フェーズ＞
次に、評価フェーズでの処理について説明する。評価フェーズにおいては、ユーザＵが端末１００を操作して、インストールされたアプリケーション部１０４の動作を行うプログラムを起動すると、アプリケーション部１０４が、固有情報取得部１０２の動作を行うプログラムを起動し（Ｓ９１４、Ｓ９１５）、固有情報取得部１０２は、端末１００の記憶部１０１に記憶されている端末ＩＤ、位置情報、ＩＰアドレス等の端末情報と、固有情報１０１１を取得して、認証サーバ２００へ送信する（Ｓ９１６）。

認証サーバ２００の評価判定部２０４は、端末１００から受信した固有情報１０１１と、記憶部２０１に登録された端末情報ＤＢ２０１１の端末設定テーブル２２３（図２）とを用いて、端末１００を認証部２０８により認証させるための評価を行う（Ｓ９１７）。具体的な処理については、図１０を用いて後述する。

利用履歴保管部２０５は、端末１００の利用履歴を利用履歴テーブル５２１に記録する（Ｓ９１８）。

評価判定部２０４は、Ｓ９１７を実行した結果、端末１００を認証部２０８に認証させることが妥当でないと判定した場合、その旨を示す評価結果を含む判定結果情報１０１２を端末１００に送信する（Ｓ９１９ａ１）。端末１００の固有情報取得部１０２は、認証サーバ２００から受信した端末１００の評価結果を入出力部１０５に出力する（Ｓ９１９ａ２）。例えば、入出力部１０５には、「端末１００を認証させることができません。」というメッセージが表示される。端末１００を認証部２０８に認証させることが妥当でないと判定した場合の対処については、端末のランクに応じて異なる。例えば、図４に示したように、端末のランクＳ〜Ｃに応じて、対処が「警告」の場合と、「エラー」の場合とに分けられる。

＜真正性認証フェーズ＞
評価判定部２０４がＳ９１７を実行した結果、端末１００を認証部２０８に認証させることが妥当であると判定した場合、認証部２０８による端末１００の認証を実行させる（Ｓ９２０）。認証部２０８は種々の認証手段によって、端末又はユーザの真正性の判定を行うことができる。例えば、パスワードの一致によりユーザ認証を行うパスワード認証、登録済みの端末の利用を以ってユーザを特定する認証を行う端末認証、登録済みの携帯端末の所有を以ってユーザを特定する認証を行う携帯端末認証、登録済みのデバイスの所有を以ってユーザを特定する認証を行うデバイス認証を用いることができる。

認証部２０８は、端末又はユーザの真正性が正しく認証されると、端末１００から固有情報１０１１とともに送信されたコンテンツにアクセスするためのアクセス情報を、コンテンツサーバ３００に送信する（Ｓ９２１）。一方、端末又はユーザの真正性が認証されない場合、端末１００への認証不成立を通知する（Ｓ９２０ａ、Ｓ９２０ｂ）。

認証部２０８が端末又はユーザの真正性を認証した場合、端末からの要求をコンテンツサーバ３００に接続することが許可され、コンテンツサーバ３００は、認証サーバ２００から受信したコンテンツへのアクセス情報を用いてコンテンツを取得し、取得したコンテンツが端末へ送信されて、端末１００のアプリケーション部１０４は受信したコンテンツを入出力部１０５に出力する（Ｓ９２２−Ｓ９２５）。

以上のステップＳ９１４〜Ｓ９２５の処理は、端末からの要求がある都度（例えば、Ｎ回）行われ、認証部２０８に認証させることが妥当でないと判定された場合に、その時点で設定されている端末のランクによって異なる対処が行われる。

＜評価フェーズにおける評価動作＞
図１０は、評価判定部２０４が端末１００の利用状況に基づく評価を行う処理（Ｓ９１７）の処理手順を示すフローチャートである。以下では、履歴条件ＤＢ２０１５に定められた条件１（時間帯条件テーブル６２１）、条件２（継続時間条件テーブル６２２）、条件３（認証結果条件テーブル６２３）、条件４（利用頻度条件テーブル７２１）、条件５（不審利用条件テーブル７２２）、条件７（位置情報条件テーブル７２４）を用いることが、認証妥当性の条件として認証判定条件テーブル４２１に設定されている場合について説明する。以下では、評価判定部２０４は、端末１００から受信した固有情報１０１１と、端末設定テーブル２２３に記憶されている固有情報とが一致するか否かを判定し、両者が一致すると判定した端末１００について、ステップＳ１００１以降の処理を行うものとする。

評価判定部２０４は、認証判定条件ＤＢ２０１３と履歴条件ＤＢ２０１５と端末情報ＤＢ２０１１の端末設定テーブル２２３とを参照し（Ｓ１００１）、まず、固有情報１０１１が送信された端末１００の利用時間帯（条件１）を評価する（Ｓ１００２）。例えば、評価判定部２０４は、端末１００から受信した端末ＩＤと同じ端末ＩＤの時間帯条件テーブル６２１を読み出し、現在の時刻が通常使用される時間帯であるか否かを評価する。通常使用される時間帯であるか否かは、例えば、端末が使用される時間帯のうち、日中の勤務時間帯以外の時間帯（例えば、１８：００−９：００の時間帯）が占める割合が所定の閾値（例えば、５パーセント）を超えるか否かにより判定すればよい。このように、端末１００の利用時間を評価することにより、端末が通常使用されている時間帯以外の時間帯で使用された端末を真正な端末でない端末として、認証部２０８による認証を行わないようにすることができる。

評価判定部２０４は、端末１００の利用時間帯が妥当であると判定した場合（Ｓ１００２；Ｙｅｓ）、Ｓ１００４に進む。一方、評価判定部２０４は、端末１００の利用時間帯が妥当でないと判定した場合（Ｓ１００２；Ｎｏ）、ランキングするためのポイントを「−１」する（Ｓ１００３）。

続いて、評価判定部２０４は、固有情報１０１１が送信された端末１００の利用継続時間が妥当であるか否か（条件２）を判定する（Ｓ１００４）。例えば、評価判定部２０４は、端末１００から受信した端末ＩＤと同じ端末ＩＤの継続時間条件テーブル６２２を読み出し、現在の利用継続時間が過去に通常利用される継続時間以内であるか否かを判定する。通常利用される継続時間以内であるか否かは、例えば、端末の利用継続時間の割合が最も多い時間（例えば、１５分間）が占める割合が所定の閾値（例えば、５パーセント）を超えたか否かにより判定すればよい。このように、端末１００の利用継続時間を評価することにより、端末が通常連続して使用されている時間以外の時間分使用された端末を真正な端末でない端末として、認証部２０８による認証を行わないようにすることができる。

評価判定部２０４は、端末１００の利用継続時間が妥当であると判定した場合（Ｓ１００４；Ｙｅｓ）、Ｓ１００６に進む。一方、評価判定部２０４は、端末１００の利用継続時間が妥当でないと判定した場合（Ｓ１００４；Ｎｏ）、ランキングするためのポイントを「−１」する（Ｓ１００５）。

続いて、評価判定部２０４は、固有情報１０１１が送信された端末１００の認証結果が妥当であるか否か（条件３）を判定する（Ｓ１００６）。例えば、評価判定部２０４は、端末１００から受信した端末ＩＤと同じ端末ＩＤの認証結果条件テーブル６２３を読み出し、過去の認証結果のうち、失敗した割合が所定の閾値（例えば、１パーセント）を超えたか否かを判定する。このように、端末１００の認証結果を評価することにより、端末が通常認証されている端末のみを真正な端末として認証部２０８による認証を行わせることができる。

評価判定部２０４は、端末１００の評価結果が妥当であると判定した場合（Ｓ１００６；Ｙｅｓ）、Ｓ１００８に進む。一方、評価判定部２０４は、端末１００の評価結果が妥当でないと判定した場合（Ｓ１００６；Ｎｏ）、ランキングするためのポイントを「−１」する（Ｓ１００７）。

続いて、評価判定部２０４は、固有情報１０１１が送信された端末１００の利用頻度が妥当であるか否か（条件４）を判定する（Ｓ１００８）。例えば、評価判定部２０４は、端末１００から受信した端末ＩＤと同じ端末ＩＤの利用頻度条件テーブル７２１を読み出し、過去の端末のウィークデイ以外の利用があるか（あるいは所定の閾値（例えば、１パーセント）を超えている）を判定する。このように、端末１００の利用頻度を評価することにより、普段からよく使用されている端末のみを真正な端末であるとして、認証部２０８による認証を行わせることができる。

評価判定部２０４は、端末１００の利用頻度が妥当であると判定した場合（Ｓ１００８；Ｙｅｓ）、Ｓ１０１０に進む。一方、評価判定部２０４は、端末１００の利用頻度が妥当でないと判定した場合（Ｓ１００８；Ｎｏ）、ランキングするためのポイントを「−１」する（Ｓ１００９）。

続いて、評価判定部２０４は、固有情報１０１１が送信された端末１００の重複利用の有無（利用形態）が妥当であるか否か（条件５）を判定する（Ｓ１０１０）。例えば、評価判定部２０４は、端末１００から受信した端末ＩＤと同じ端末ＩＤの不審利用条件テーブル７２２を読み出し、過去の端末の重複利用があるか（あるいは所定の閾値（例えば、１パーセント）を超えている）を判定する。このように、端末１００の利用形態を評価することにより、端末が通常使用されている形態以外の用い方で使用された端末を真正な端末でない端末として、認証部２０８による認証を行わないようにすることができる。

評価判定部２０４は、端末１００の利用形態が妥当であると判定した場合（Ｓ１０１０；Ｙｅｓ）、Ｓ１０１２に進む。一方、評価判定部２０４は、端末１００の利用形態が妥当でないと判定した場合（Ｓ１０１０；Ｎｏ）、ランキングするためのポイントを「−３」する（Ｓ１０１１）。

続いて、評価判定部２０４は、固有情報１０１１が送信された端末１００の位置情報が妥当であるか否か（条件７）を判定する（Ｓ１０１２）。例えば、評価判定部２０４は、端末１００から受信した端末ＩＤと同じ端末ＩＤの位置情報条件テーブル７２４を読み出し、端末の位置情報が過去に所定の回数以上認証された位置であるか（あるいは国内である）を判定する。このように、端末１００の位置情報を評価することにより、端末が通常使用されている位置以外の場所で使用された端末を真正な端末でない端末として、認証部２０８による認証を行わないようにすることができる。

評価判定部２０４は、端末１００の位置情報が妥当であると判定した場合（Ｓ１０１２；Ｙｅｓ）、Ｓ１０１４に進む。一方、評価判定部２０４は、端末１００の位置情報が妥当でないと判定した場合（Ｓ１０１２；Ｎｏ）、ランキングするためのポイントを「−３」する（Ｓ１０１３）。

そして、評価判定部２０４は、Ｓ１００３、Ｓ１００５、Ｓ１００７、Ｓ１００９、Ｓ１０１１、Ｓ１０１３で算出されたポイントの合計が、所定の閾値（例えば、−５）よりも大きい値であるか否かを判定する（Ｓ１０１４）。評価判定部２０４は、上記ポイントの合計が所定の閾値よりも大きい値であると判定した場合（Ｓ１０１４；Ｙｅｓ）、端末のランクを下げ、下げた端末のランクを端末情報ＤＢ２０１１の端末設定テーブル２２３のランクに書き込んで更新する（Ｓ１０１５）。一方、評価判定部２０４は、上記ポイントの合計が所定の閾値よりも大きくない値であると判定した場合（Ｓ１０１４；Ｎｏ）、そのまま処理を終了させる。

上記のように、評価判定部２０４が端末１００の利用状況に基づく評価を行う処理を行うことにより、端末１００の最新のランクに基づいて認証の妥当性を自動的に判定することができる。判定の結果、真正性の認証を行うことが妥当でない場合、その時点の端末ランクに応じた対処を可能とする。これにより、例えば、登録フェーズで評価対象とすることが妥当であると判定された端末であっても、その後の端末の使用環境が登録フェーズの時と異なる環境で使用されて一定の基準を超えた場合には、自動的に端末ランクが下がって認証エラーとなり、真正な端末以外の端末によるアクセスを排除することができる。

なお、図１０の例では、条件１−４の場合に下げるポイントの値（「−１」）と、条件５、７の場合に下げるポイントの値（「−３」）とを異なる値としたが、ポイントの定め方については、企業ニーズに応じて適宜変更すればよい。なお、条件６（モデルごとの認証）については、評価対象とされた端末１００が、モデル認証結果条件テーブル７２３に記憶されているモデルのうち、認証成功が所定の割合以上のモデルを搭載した端末でない場合にランクを下げる。例えば、閾値を８０％とすると、モデルＡ１は７０％なので、モデルＡ１を搭載した端末であればランクを下げる。このように、端末１００のモデルを評価することにより、端末が通常使用されているモデル以外のモデルの端末を真正な端末でない端末として、認証部２０８による真正性の認証を行わないようにすることができる。

また、図１０の例では、条件１−５、７による６つの条件による判定を行っているが、他の例によれば、必ずしも全ての条件による判定を行なわず、これらの条件から選択された幾つかの条件を用いて端末を評価することができる。何れの条件を用いるかは、端末のユーザが属する会社等の団体（クライアント）からの要望に応じて適宜選択することができる。例えば、ユーザ（従業員）の休日利用を認めていないクライアントならば、条件４は不要であるし、所定の場所でのみの端末の利用を認めているクライアントならば、条件７は不要であろう。

また、本実施例では、評価判定部２０４による端末の利用状況の評価と記載しているが、「評価」の文言に代わって他の文言を使用してもよい。例えば、端末の「監視」、「検証」、「検査」なる文言を用いても発明の趣旨は変わらない。要するに、端末の真正性の認証の前に、端末の利用状況を監視、または検証、または検査して、その判定に応じて真正性の認証を行えばよい。

実施例１では、評価判定部２０４によって端末１００の利用状態の評価を行い、判定結果が妥当である場合、認証部２０８に端末又はユーザの真正性を認証させることとした。認証部２０８が行う認証としては、パスワードの一致によりユーザ認証を行うパスワード認証、登録済みの端末の利用を以ってユーザを特定する認証を行う端末認証、登録済みの携帯端末の所有を以ってユーザを特定する認証を行う携帯端末認証、登録済みのデバイスの所有を以ってユーザを特定する認証を行うデバイス認証等、様々な認証方式を採用することができる。しかし、必ずしも認証サーバ２００の認証部が真正性の認証を行わない場合もある。そこで、実施例２では、ランクに応じた認証方式による認証を認証サーバ２００内の認証部以外で行う場合について説明する。重複記載を避けるため、以下では、同一の構成要素については同一の符号を付してその説明を省略する。

図１１は、実施例２にかかる端末認証管理システム２０００の構成例を示す図である。図１１では、認証サーバ２００は、実施例１における認証部２０８にかえて、認証制御部１２０を有し、記憶部２０１には、認証方式設定テーブル１１０５、認証方式選択テーブル１１０６がさらに記憶される。さらに、認証サーバ２００は、各認証方式による認証を実現するためのプログラムであるパスワード認証部１２０１、端末認証部１２０２、携帯端末認証部１２０３、デバイス認証部１２０４を有している。 認証制御部１２０は、評価判定部２０４によって評価された端末に対して、端末のランクに応じて各認証部を用いた認証方法を制御する処理部である。例えば、図１１では、パスワード認証を行う場合、認証制御部１２０は、認証サーバ２００にインストールされたパスワード認証部１２０１を呼び出し、パスワード認証の実行を指示する。

認証方式設定テーブル１１０５は、端末を認証するための認証方式を定めたテーブルである。認証方式選択テーブル１１０６は、評価判定部２０４によって評価された端末のランクに応じて認証方式を選択するためのテーブルである。認証方式設定テーブル１１０５については、図１４を用いて後述するが、実施例２においては、呼び出し先が認証サーバ内の各認証部を実行するための実行ファイルとなる。

図１２は、認証方式選択テーブル１１０６の例を示す図である。図１２に示すように、認証方式選択テーブル１１０６は、複数の認証方式と、実施例１において評価された端末のランクとが対応付けて記憶されている。図１２では、例えば、ランクＳと評価された端末は、パスワード認証のみ選択され、ランクＡと評価された端末は、端末認証のみ選択される。また、ランクＢと評価された端末は、パスワード認証と携帯端末認証とが選択され、ランクＣと評価された端末は、パスワード認証、端末認証、携帯端末認証、デバイス認証が選択される。このように、端末の利用状態の評価に応じて、１又は複数の異なる認証方式の組み合わせが選択される。即ち、利用状態が正常な場合（Ｓランク）には軽度なパスワード認証のみで真正性を認証する。一方、利用状態が不適当な場合（Ｃランク）、重度な認証として４つの異なる認証方式を用いて認証する。

実施例２では、図９のステップＳ９１８において、利用履歴保管部２０５が、端末１００の利用履歴を利用履歴テーブル５２１に記録すると、認証制御部１２０が、評価判定部２０４により評価された端末のランクと、認証方式選択テーブル１１０６を読み取り、端末のランクに対応付けて定められた認証方式を選択する。

認証制御部１２０は、認証方式を選択すると、認証方式設定テーブル１１０５を読み取り、選択した１又は複数の認証方式に対応する呼び出し先にアクセスし、選択された認証方式による認証の実行を指示する。

認証の実行を指示されたサーバや認証サーバ２００のプログラムは、各方式で認証を実行し、認証を実行した結果を認証制御部１２０に送信する。例えば、Ｃランクの端末は、複数の認証サーバによる認証の結果、１つの認証で不正と判断された場合には、認証不成立として端末１００に通知する。

このように、認証サーバ２００において、認証制御部１２０がランクに応じて定められた認証方式を選択し、選択された認証方式によって認証を実行させるので、パスワード認証、端末認証、携帯端末認証、デバイス認証等の様々な認証プログラムを認証方式としてランクに応じて設定し、設定した方式により認証することができる。また、上記認証プログラムのバージョンアップや、採用する認証方式が変更された場合でも、認証サーバ２００の認証部２０８を変更することなく、認証プログラムを入れ替えるだけで変更後の認証プログラムによる認証を行うことができる。

実施例２では、認証制御部１２０が、認証サーバ２００内のパスワード認証部１２０１、端末認証部１２０２、携帯端末認証部１２０３、デバイス認証部１２０４に対して認証実行を指示し、これらの認証部がランクに応じて選択され、真正性の認証を実行することとした。しかし、パスワード認証部１２０１、端末認証部１２０２、携帯端末認証部１２０３、デバイス認証部１２０４は、必ずしも認証サーバ２００内に備えず、認証サーバ２００ではない外部のサーバや装置に備える場合もある。そこで、実施例３では、認証を認証サーバ２００以外で行う場合について説明する。重複記載を避けるため、以下では、同一の構成要素については同一の符号を付してその説明を省略する。

図１３は、実施例３にかかる端末認証管理システム３０００の構成例を示す図である。図１３では、認証サーバ２００は、実施例２における認証制御部１２０にかえて、認証制御部２２０を有する。また、ネットワークＮ１には、パスワード認証サーバ２２０１、端末認証サーバ２２０２が接続され、認証サーバ２００には、携帯端末認証サーバ２２０３、デバイス認証サーバ２２０４が接続される。

図１３では、パスワード認証サーバ２２０１、端末認証サーバ２２０２がネットワークＮ１に接続されているが、携帯端末認証サーバ２２０３、デバイス認証サーバ２２０４がネットワークＮ１に接続されてもよい。また、図１３では、携帯端末認証サーバ２２０３、デバイス認証サーバ２２０４が認証サーバ２００に接続されているが、パスワード認証サーバ２２０１、端末認証サーバ２２０２が認証サーバ２００に接続されてもよい。

また、必ずしもパスワード認証サーバ２２０１、端末認証サーバ２２０２、携帯端末認証サーバ２２０３、デバイス認証サーバ２２０４が、認証サーバ２００以外の外部のサーバとして構成されていなくてもよい。例えば、認証方式として採用されているランクの数が多く、一定数以上ある方式の場合には、実施例２のように認証サーバ２００内の認証プログラムを実行することで認証を行う一方、認証方式として採用されているランクの数が少なく、一定数に満たない方式の場合には、実施例３のように認証サーバ２００以外の外部の認証サーバによる認証を実行してもよい。

図１２では、パスワード認証についてはＳ、Ｂ、Ｃの３つのランクで用いる認証方式であり、デバイス認証についてはＣランクで用いられる認証方式である。したがって、認証制御部２２０は、パスワード認証については認証サーバ２００内のパスワード認証部１２０１による認証を指示し、デバイス認証については認証サーバ２００以外の外部のデバイス認証サーバ２２０４による認証を指示する。このような構成により、認証方式として用いられることが多い方式については認証サーバ内部で認証を行ってネットワークの負荷を抑えることができる。

また、例えば、認証方式として採用されているランクの数が少なく、一定数に満たない方式の場合に、実施例２のように認証サーバ２００内の認証プログラムを実行することで認証を行う一方、認証方式として採用されているランクの数が多く、一定数以上ある方式の場合には、実施例３のように認証サーバ２００以外の外部の認証サーバによる認証を実行してもよい。この場合には、認証方式として用いられることが少ない方式については認証サーバ内部で認証を行って認証サーバの処理負荷を抑えることができる。

認証制御部２２０は、評価判定部２０４によって評価された端末に対して、端末のランクに応じて各認証サーバを用いた認証方法を制御する処理部である。例えば、図１３では、パスワード認証を行う場合、認証制御部２２０は、パスワード認証サーバ２２０１にアクセスし、パスワード認証の実行を指示する。

パスワード認証サーバ２２０１、端末認証サーバ２２０２、携帯端末認証サーバ２２０３、デバイス認証サーバ２２０４は、それぞれ、パスワード認証、端末認証、携帯端末認証、デバイス認証を行うサーバである。

図１４は、認証方式設定テーブル１１０５の例を示す図である。図１４に示すように、認証方式設定テーブル１１０５は、認証方式と、その認証方式を実行するサーバや装置等の呼び出し先とが対応付けて記憶されている。呼び出し先とは、実行ファイル又は実行サイトのアドレス又はＵＲＬである。図１４では、例えば、端末認証を行う場合、認証制御部１２０は、ネットワークＮ１を介して端末認証サーバ１２０２の認証実行サイト１にアクセスして、端末認証の実行を指示する。

このように、認証サーバ２００において、認証制御部２２０がランクに応じて定められた認証方式を選択し、選択された認証方式によって認証サーバ以外の外部のサーバを用いて認証を実行させるので、パスワード認証、端末認証、携帯端末認証、デバイス認証等の様々な認証サーバによる認証を認証方式としてランクに応じて設定し、設定した方式により認証することができる。また、上記認証サーバや採用する認証方式が変更された場合でも、認証サーバ２００の認証部２０８を変更することなく、接続する認証サーバを切り替えるだけで変更後の認証サーバによる認証を行うことができる。

以上、幾つかの実施例について説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で適宜組み合わせて実行することも可能である。

例えば、図１では、認証サーバ２００とコンテンツサーバ３００とが別サーバである場合の構成を例示したが、認証サーバの各部を複数のサーバに分けた構成でもよい。例えば、登録の判定機能と認証妥当性の判定機能とを、複数のサーバに分けた構成としてもよい。これにより、登録時の処理と、認証時の処理とを負荷分散させることができ、処理の平準化が可能となる。また、認証サーバ２００およびコンテンツサーバ３００の双方の機能を有した１つのサーバとして構成してもよい。

さらに、認証サーバ２００の登録判定部２０３が行う（１）登録の判定および（２）評価判定部２０４が行う判定（３）認証部２０８が行う真正性の認証を、それぞれ異なるサーバで実行させてもよい。これにより、より一層負荷の分散や処理の平準化が可能となる。

また、図１では、認証サーバ２００が、各データベースを保持する場合について例示したが、これらのデータベースを、認証サーバ以外のサーバで保持し、処理を実行するタイミングで必要に応じて読み出してもよい。これにより、認証サーバで確保すべき容量を抑えることができ、コンパクトな構成で認証サーバを構成することができる。

さらに、管理者端末４００の機能を端末１００で実現してもよく、また、端末１００の機能と管理者端末４００の両方の機能を端末１００で実現してもよい。この場合、管理者端末を設けることなく、端末側で登録の妥当性を判定することができる。

また、図１では、端末１００に位置測位部１０６がインストールされている前提で説明したが、認証の条件として使用する場合に必要に応じて端末１００にインストールしてもよい。これにより、端末側の機能を簡素化することができる。

１０００ 端末認証管理システム
１００ 端末
１０１ 記憶部
１０２ 固有情報取得部
１０３ 通信部
１０４ アプリケーション部
１０５ 入出力部
１０６ 位置測位部
２００ 認証サーバ
２０１ 記憶部
２０２ 通信部
２０３ 登録判定部
２０４ 評価判定部
２０５ 利用履歴保管部
２０６ 利用情報管理部
２０７ 管理部
３００ コンテンツサーバ
４００ 管理者端末
４０１ 入力部
４０２ 表示部
４０３ 制御部
２０１１ 端末情報ＤＢ
２２１ アカウントテーブル
２２２ 端末モデルテーブル
２２３ 端末設定テーブル
２０１２ 登録判定条件ＤＢ
３２１ 端末条件テーブル
３２２ アプリ条件テーブル
３２３ 位置条件テーブル
２０１３ 認証判定条件ＤＢ
４２１ 認証判定条件テーブル
２０１４ 認証履歴ＤＢ
５２１ 認証履歴テーブル
２０１５ 履歴条件ＤＢ
６２１ 時間帯条件テーブル
６２２ 継続時間条件テーブル
６２３ 認証結果条件テーブル
７２１ 利用頻度条件テーブル
７２２ 不審利用条件テーブル
７２３ モデル認証結果条件テーブル
７２４ 位置情報条件テーブル

Claims (30)

1. ユーザが使用する端末からネットワークを通して送られる要求に対して、サーバが認証を行う認証管理システムであって、
   該サーバは、
   前記端末から送信される前記要求を取得する通信部と、
   前記通信部を介して該要求が取得された該端末の利用状況を判定する第１処理部と、
   該端末又は該ユーザの真正性を判定する第２処理部と、を有し、
   前記第１処理部による判定に応じて、前記第２処理部により該端末又は該ユーザの真正の判定を行わない
   ことを特徴とする認証管理システム。
2. 前記第２処理部は、予め用意された１または複数の認証処理手段を有し、
   前記第１処理部による判定の結果、前記端末の利用が適当である場合、前記第２処理部は前記認証処理手段により該端末又は該ユーザの真正の判定を行い、該判定の結果が正当な場合、前記端末が要求するコンテンツサーバへの接続を許可する
   ことを特徴とする請求項１記載の認証管理システム。
3. 前記第１処理部による前記判定の結果、前記端末の利用が不適当である場合、前記第２処理部による認証を行わないで、要求のあった前記端末に対して認証を行わない旨の通知をする、
   ことを特徴とする請求項１または２に記載の認証管理システム。
4. ユーザが使用する端末からネットワークを通して送られる要求に対して、サーバが該端末又は該ユーザの真正性認証の管理を行う認証管理システムであって、
   該サーバは、
   前記端末から送信される前記要求を取得する通信部と、
   前記通信部を介して該要求が取得された該端末の利用状況を判定する第１処理部と、
   該端末又は該ユーザの真正性を認証する１又は複数の認証処理手段を指定する認証管理部と、を有し、
   前記第１処理部の判定に応じて、前記認証管理部は前記１又は複数の認証処理手段による認証を行なわない
   ことを特徴とする認証管理システム。
5. 前記第１処理部による判定の結果、前記端末の利用が適当である場合、前記認証管理部は、前記１または複数の認証処理手段を指定して、該端末又は該ユーザの真正性の認証を行なわせ、該認証の結果が正当な場合、前記認証管理部は、前記端末が要求するコンテンツサーバへの接続を許可する
   ことを特徴とする請求項４記載の認証管理システム。
6. 前記第１処理部による前記判定の結果、前記端末の利用が不適当である場合、前記認証管理部は前記認証処理手段よる真正性の認証を行わせないで、要求のあった前記端末に対して認証を行わない旨の通知をする、
   ことを特徴とする請求項４または５に記載の認証管理システム。
7. 前記端末ごとの利用条件を登録する利用条件ＤＢと、
   前記端末ごとに該端末の固有情報と、該端末に付与されるランクを登録する端末テーブルと、を有し、
   前記第１処理部は、前記通信部を介して取得される前記端末からの要求に対して、前記利用条件ＤＢを参照して、前記端末の利用状況を判定して該端末をランク付けし、付与されたランクを、前記端末テーブルに格納する
   ことを特徴とする請求項１乃至６のいずれかの項に記載の認証管理システム。
8. 前記端末の判定の条件、及び前記第１処理部により判定される前記端末のランクに応じて、該端末への対処を登録する検証テーブルを有し、
   前記第１処理部は、前記利用状況の判定の結果、前記検証テーブルに登録されたランクに応じた対処の通知を指定し、
   前記通信部は、指定された該通知を前記端末へ送信する
   ことを特徴とする請求項７に記載の認証管理システム。
9. 前記第１処理部は、前記端末の利用状況に応じて、前記端末テーブルに登録された情報を更新することを特徴とする請求項７に記載の認証管理システム。
10. 前記端末の利用時間帯に関する情報を管理する時間帯条件テーブルを有し、
    前記第１処理部は、前記時間帯条件テーブルの内容に応じて、要求のあった前記端末の認証に対するランクを下げる
    ことを特徴とする請求項７乃至９のいずれかの項に記載の認証管理システム。
11. 前記端末の利用継続時間に関する情報を管理する利用継続時間条件テーブルを有し、
    前記第１処理部は、前記利用継続時間条件テーブルの内容に応じて、要求のあった前記端末の認証に対するランクを下げる
    ことを特徴とする請求項７乃至１０のいずれかの項に記載の認証管理システム。
12. 前記端末の認証結果に関する情報を管理する認証結果テーブルを有し、
    前記第１処理部は、前記認証結果テーブルの内容に応じて、要求のあった前記端末の認証に対するランクを下げる
    ことを特徴とする請求項７乃至１１のいずれかの項に記載の認証管理システム。
13. ユーザによる前記端末の、所定期間における認証の成否、及び所定日時における利用度を管理する利用頻度テーブルを有し、
    前記第１処理部は、前記利用頻度テーブルの内容に応じて、要求のあった前記端末の認証に対するランクを下げる
    ことを特徴とする請求項７乃至１２のいずれかの項に記載の認証管理システム。
14. 前記端末に固有の端末ＩＤが、所定の期間に使用された回数を管理する不審利用チェックテーブルを有し、
    前記第１処理部は、前記不審利用チェックテーブルの内容に応じて、要求のあった前記端末の認証に対するランクを下げる
    ことを特徴とする請求項７乃至１３のいずれかの項に記載の認証管理システム。
15. 前記端末が利用された位置及び該位置における認証回数を管理する位置チェックテーブルを有し、
    前記第１処理部は、前記位置チェックテーブルの内容に応じて、要求のあった前記端末の認証に対するランクを下げる
    ことを特徴とする請求項７乃至１４のいずれかの項に記載の認証管理システム。
16. 前記端末ごとに、端末を識別する端末ＩＤ、該端末のモデルに関する情報、ユーザを識別するユーザＩＤ、該端末に固有の情報、及び該端末に関する前記ランクを管理する端末設定テーブルを保持する、
    ことを特徴とする請求項７乃至１５のいずれかの項に記載の認証管理システム。
17. 前記サーバは、前記複数の各認証処理手段を選択することができる情報を登録する認証指定テーブルを有し、
    前記第１処理部による前記判定の結果、所定の条件を満たす場合、前記認証管理部は前記認証指定テーブルを参照して、１又は複数の認証処理手段を選択する
    ことを特徴とする請求項４乃至６のいずれかの項に記載の認証管理システム。
18. ユーザが使用する端末からネットワークを通して送られる要求に対して、サーバが認証を行う認証管理方法であって、
    通信部が前記端末から送信される前記要求を取得するステップと、
    前記通信ステップにより該要求が取得された該端末の利用状況を判定する第１処理ステップと、
    該端末又は該ユーザの真性を判定する第２処理ステップと、を有し、
    前記第１処理ステップによる判定に応じて、前記第２処理ステップにおける該端末又は該ユーザの真正の判定を行わない
    ことを特徴とする認証管理方法。
19. １または複数の認証処理手段を有し、
    前記第１処理ステップによる判定の結果、前記端末の利用が適当である場合、前記第２処理ステップにおいて、前記１または複数の認証処理手段により該端末又は該ユーザの真正の判定を行い、該判定の結果が正当な場合、前記端末が要求するコンテンツサーバへの接続を許可する
    ことを特徴とする請求項１８記載の認証管理方法。
20. 前記第１処理ステップによる前記判定の結果、前記端末の利用が不適当である場合、前記第２処理ステップによる認証を行わないで、要求のあった前記端末に対して認証を行わない旨の通知をする、
    ことを特徴とする請求項１８または１９に記載の認証管理方法。
21. ユーザが使用する端末からネットワークを通して送られる要求に対して、サーバが該端末又は該ユーザの真正性認証の管理を行う認証管理方法であって、
    通信部が前記端末から送信される前記要求を取得するステップと、
    前記通信部を介して該要求が取得された該端末の利用状況を判定する第１処理ステップと、
    該端末又は該ユーザの真正性を認証する１又は複数の認証処理手段を指定する認証管理ステップと、を有し、
    前記第１処理ステップの判定に応じて、前記認証管理ステップにおいて指定される前記１又は複数の認証処理手段による真正性の認証を行なわない
    ことを特徴とする認証管理方法。
22. 前記第１処理ステップによる判定の結果、前記端末の利用が適当である場合、前記第２処理ステップにおいて、前記１または複数の認証処理手段を指定して該端末又は該ユーザの真正の判定を行なわせ、
    該判定の結果が正当な場合、前記端末が要求するコンテンツサーバへの接続を許可する
    ことを特徴とする請求項２１記載の認証管理方法。
23. 前記第１処理ステップによる前記判定の結果、前記端末の利用が不適当である場合、前記認証処理手段よる真正性の認証を行わせないで、要求のあった前記端末に対して認証を行わない旨の通知をする、
    ことを特徴とする請求項２１または２２に記載の認証管理方法。
24. 前記端末ごとの利用条件を登録する利用条件ＤＢと、
    前記端末ごとに該端末の固有情報と、該端末に付与されるランクを登録する端末テーブルと、を有し、
    前記第１処理ステップにおいて、前記通信部を介して取得される前記端末からの要求に対して、前記利用条件ＤＢを参照して、前記端末の利用状況を判定して該端末をランク付けし、付与されたランクを、前記端末テーブルに格納する
    ことを特徴とする請求項１８乃至２３のいずれかの項に記載の認証管理方法。
25. 前記端末の判定の条件、及び前記第１処理ステップにより判定される前記端末のランクに応じて、該端末への対処を登録する検証テーブルを有し、
    前記第１処理ステップにおいて、前記利用状況の判定の結果、前記検証テーブルに登録されたランクに応じた対処の通知を指定し、
    前記通信部は、指定された該通知を前記端末へ送信する
    ことを特徴とする請求項２４に記載の認証管理方法。
26. 前記第１処理ステップにおいて、前記端末の利用状況に応じて、前記端末テーブルに登録された情報を更新することを特徴とする請求項２４に記載の認証管理方法。
27. 前記サーバは、前記複数の各認証処理手段を選択することができる情報を登録する認証指定テーブルを有し、
    前記第１処理ステップによる前記判定の結果、所定の条件を満たす場合、前記認証管理ステップにおいて前記認証指定テーブルを参照して、１又は複数の認証処理手段を選択し、
    選択された前記１又は複数の認証処理手段が真正性の認証を行う
    ことを特徴とする請求項２１乃至２３のいずれかの項に記載の認証管理方法。
28. ユーザが使用する該端末からネットワークを通して送られる要求に対して、サーバが認証を行うかを判断する端末の認証管理方法であって、
    該サーバは、
    所定の条件を満たす端末の情報を端末情報ＤＢに登録し、
    前記端末情報ＤＢに登録された前記端末から要求がある度に該端末の利用状況を評価し、
    前記端末情報ＤＢに登録された前記端末であっても、該評価の結果、登録後の前記端末の利用状況が所定の条件を満たさない場合、前記端末の真正性に関する認証を行わないで、前記要求を拒否する
    ことを特徴とする端末の認証管理方法。
29. ユーザが使用する端末からネットワークを通して送られる要求に対して、サーバが認証のための管理を行う認証管理プログラムであって、
    前記サーバは、
    通信部が前記端末から送信される前記要求を取得するステップと、
    前記通信ステップにより該要求が取得された該端末の利用状況を判定する第１処理ステップと、
    該端末又は該ユーザの真性を判定する第２処理ステップと、を実行し、
    前記第１処理ステップによる判定に応じて、前記第２処理ステップにおける該端末又は該ユーザの真正の判定を行わない
    ことを特徴とする認証管理プログラム。
30. ユーザが使用する端末からネットワークを通して送られる要求に対して、サーバが該端末又は該ユーザの真正性認証の管理を行う認証管理プログラムであって、
    前記サーバは、
    通信部が前記端末から送信される前記要求を取得するステップと、
    前記通信部を介して該要求が取得された該端末の利用状況を判定する第１処理ステップと、
    該端末又は該ユーザの真正性を認証する１又は複数の認証処理手段を指定する認証管理ステップと、を実行し、
    前記第１処理ステップの判定に応じて、前記認証管理ステップにおいて指定される１又は複数の認証処理手段に真正性の認証を行なわない
    ことを特徴とする認証管理プログラム。

Images