特許 6476402 認証システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6476402

(24)【登録日】2019年2月15日

(45)【発行日】2019年3月6日

(54)【発明の名称】認証システム

(51)【国際特許分類】

   G06F 21/10 20130101AFI20190225BHJP

   G06F 21/33 20130101ALI20190225BHJP

   G06F 21/12 20130101ALI20190225BHJP

【ＦＩ】

   G06F21/10 350

   G06F21/33

   G06F21/12 310

【請求項の数】6

【全頁数】20

(21)【出願番号】特願2016-101166(P2016-101166)

(22)【出願日】2016年5月20日

(65)【公開番号】特開2017-208000(P2017-208000A)

(43)【公開日】2017年11月24日

【審査請求日】2017年8月25日

(73)【特許権者】

【識別番号】500148514

【氏名又は名称】システムメトリックス株式会社

(74)【代理人】

【識別番号】100165663

【弁理士】

【氏名又は名称】加藤 光宏

(72)【発明者】

【氏名】伊鍋 貴宏

(72)【発明者】

【氏名】前田 吉男

【審査官】 宮司 卓佳

(56)【参考文献】

【文献】 特開２０１５−２０７１５２（ＪＰ，Ａ）

【文献】 特開平０８−１８１９６５（ＪＰ，Ａ）

【文献】 特開２００４−０４６７５６（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ２１／００−２１／８８

(57)【特許請求の範囲】

【請求項1】

ネットワークを介してサーバに接続されたクライアントにおいてアプリケーションを利用するための認証を行う認証システムであって、
前記サーバは、
前記クライアントからの認証要求に従い、前記アプリケーションの利用を許可するためのトークンとして、その有効期限を表す固定的な日時情報と、認証の実行に応じて更新される動的な日時情報を含み、前記クライアントがオフライン状態にある場合の認証に用いられるオフライン用トークンを生成して、該クライアントに送信するトークン発行部と、
前記生成されたトークンを管理するトークン管理部と
を備え、
前記クライアントは、
前記オフライン用トークンを保持するトークン保持部と、
現在時刻が、前記オフライン用トークンに含まれる前記動的な日時情報以降であり、かつ前記有効期限内である場合に前記アプリケーションの利用を許可し、その他の場合には前記アプリケーションの利用を禁止する利用許可部と、
前記利用許可部の動作に伴い、前記動的な日時情報を、前記現在時刻に更新する日時情報更新部と
を備え、
前記サーバは、前記クライアントからの認証要求に応じて、前記クライアントがオンライン状態にある場合の認証に用いるための該クライアントに固有のオンライン用トークンの有効性、および前記アプリケーションの起動を許可するための起動条件の少なくとも一方を踏まえて、該クライアントにおける前記アプリケーションの利用を許可するか否かの認証を行う認証部を有し、
前記クライアントは、前記アプリケーションの起動時および起動後の所定のタイミングで、繰り返し、前記サーバに対して前記認証要求を送信する認証要求送信部を有し、
前記サーバにおいて、
前記トークン発行部は、前記認証により前記アプリケーションの利用を許可する場合、該クライアントに固有の有効なオンライン用トークン、または前記クライアントに対して発行済みのオンライン用トークンが有効であることを示す情報を前記クライアントに送信し、
前記トークン管理部は、前記認証要求に対応する発行済みのオンライン用トークンであって、前記トークン発行部によって新たに生成されたオンライン用トークンとは異なるクライアントに対して発行されたものがある場合は、所定の無効化条件に従って当該発行済みのオンライン用トークンを無効化し、
前記クライアントにおいて、
前記利用許可部は、前記オンライン用トークンが有効であることが確認できたときは前記アプリケーションの利用を許可し、その他の場合は前記アプリケーションの利用を禁止する認証システム。

【請求項2】

請求項１記載の認証システムであって、
前記日時情報更新部は、前記動的な日時情報を、将来に向かう方向にのみ更新するよう規制されている認証システム。

【請求項3】

請求項２記載の認証システムであって、
前記日時情報更新部は、オンラインとなった時には、前記規制を解除し、前記動的な日時情報を、前記ネットワーク経由で取得される日時に同期させる認証システム。

【請求項4】

請求項１〜３いずれか記載の認証システムであって、
前記認証要求は、前記アプリケーションの開発者の識別情報、該アプリケーションの識別情報、該アプリケーションのユーザのアカウント情報、該クライアントの端末識別情報を含み、
前記認証は、前記認証要求に含まれる各情報と、前記サーバに予め登録された情報との整合性を考慮して行われる認証システム。

【請求項5】

請求項４記載の認証システムであって、
前記サーバは、
前記アプリケーションの識別情報および前記ユーザのアカウント情報とを記憶しておくデータベースを、前記アプリケーションの開発者ごとに個別に備える認証システム。

【請求項6】

ネットワークを介してサーバに接続されたクライアントにおいてアプリケーションを利用するための認証を行う認証方法であって、
前記サーバが実行する処理として、
前記クライアントからの認証要求に従い、前記アプリケーションの利用を許可するためのトークンとして、その有効期限を表す固定的な日時情報と、認証の実行に応じて更新される動的な日時情報を含み、前記クライアントがオフライン状態にある場合の認証に用いられるオフライン用トークンを生成して、該クライアントに送信するステップと、
前記生成されたトークンを管理するステップと
を備え、
前記クライアントが実行する処理として、
前記オフライン用トークンを保持するトークン保持ステップと、
現在時刻が、前記オフライン用トークンに含まれる前記動的な日時情報以降であり、かつ前記有効期限内である場合に前記アプリケーションの利用を許可し、その他の場合には前記アプリケーションの利用を禁止する利用許可ステップと、
前記利用許可ステップに伴い、前記動的な日時情報を、前記現在時刻に更新する日時情報更新ステップと
を備え、
前記サーバは、前記クライアントからの認証要求に応じて、前記クライアントがオンライン状態にある場合の認証に用いるための該クライアントに固有のオンライン用トークンの有効性、および前記アプリケーションの起動を許可するための起動条件の少なくとも一方を踏まえて、該クライアントにおける前記アプリケーションの利用を許可するか否かの認証を行うステップを有し、
前記クライアントは、前記アプリケーションの起動時および起動後の所定のタイミングで、繰り返し、前記サーバに対して前記認証要求を送信するステップを有し、
前記サーバにおいては、
前記認証により前記アプリケーションの利用を許可する場合、該クライアントに固有の有効なオンライン用トークン、または前記クライアントに対して発行済みのオンライン用トークンが有効であることを示す情報を前記クライアントに送信し、
前記認証要求に対応する発行済みのオンライン用トークンであって、前記トークン発行部によって新たに生成されたオンライン用トークンとは異なるクライアントに対して発行されたものがある場合は、所定の無効化条件に従って当該発行済みのオンライン用トークンを無効化し、
前記クライアントにおいては、
前記オンライン用トークンが有効であることが確認できたときは前記アプリケーションの利用を許可し、その他の場合は前記アプリケーションの利用を禁止する認証方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ネットワークを介してサーバに接続されたクライアントにおいてアプリケーションを利用するための認証を行う認証システムに関する。

【背景技術】

【0002】

アプリケーションの利用時には、ユーザが、その利用についてライセンスを有しているかの認証が、種々の方法によって行われている。近年では、アプリケーションを利用するクライアントがインターネットに接続されている環境にあることを前提として、同じくインターネット上のサーバによって、ライセンスを管理するための技術も多く提供されている。
例えば、特許文献１は、ネットワークを利用してアプリケーションの認証を行う際に、端末に固有の識別情報を取得することによって、正規に許容された端末以外の非正規端末におけるアプリケーションの利用を防ぐ技術を開示している。
特許文献２は、同様に端末に固有の識別情報を含むライセンスキーを利用して認証を行う場合において、アプリケーションを利用している端末の識別情報をデータベースで管理することにより、他の端末で認証が行われたときは、従前利用していた端末での利用を停止させた上で、新たな端末での利用を認める技術を開示している。
特許文献３は、ライセンス時に、アプリケーションをインストール可能な台数、アプリケーションを同時に起動可能なライセンス数という２つの設定値を設けることにより、アプリケーションをインストールする台数および同時に稼働する台数の双方を制御する技術を開示している。
特許文献４は、サーバによって認証を行う際に、有効期限付きのアクセストークンを発行し、このアクセストークンの有効期限が過ぎていないかを確認することによって、アプリケーションの利用中においても、ライセンスの認証を行う技術を開示している。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１３−０１５９３０号公報

【特許文献2】特開２００９−１１６３９２号公報

【特許文献3】特開２０１５−１４８１７号公報

【特許文献4】特開２０１６−０１８５２９号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

従来技術における認証方法において、特許文献１〜４のようにオンラインを前提としたサーバでの認証では、アプリケーションがインストールされたクライアントが、サーバと通信可能に接続されたオンライン状態でないと、アプリケーションを利用できないという課題があった。また、サーバと接続していないオフラインの状態でも認証可能な方法を採用すると、アクセストークンの有効期限を改ざんするなどの不正が行われる危険性が高まるという課題があった。このように、オンラインでの認証には、利便性に欠けるという課題があり、一方で、オフラインでの認証は不正への対処が不十分であった。
本発明は、かかる課題に鑑み、オンラインによる認証とオフラインによる認証の利点を活かした認証を実現することを目的とする。

【課題を解決するための手段】

【0005】

本発明は、
ネットワークを介してサーバに接続されたクライアントにおいてアプリケーションを利用するための認証を行う認証システムであって、
前記サーバは、
前記クライアントからの認証要求に従い、前記アプリケーションの利用を許可するためのトークンとして、その有効期限を表す固定的な日時情報と、認証の実行に応じて更新される動的な日時情報を含み、前記クライアントがオフライン状態にある場合の認証に用いられるオフライン用トークンを生成して、該クライアントに送信するトークン発行部と、
前記生成されたトークンを管理するトークン管理部と
を備え、
前記クライアントは、
前記オフライン用トークンを保持するトークン保持部と、
現在時刻が、前記オフライン用トークンに含まれる前記動的な日時情報以降であり、かつ前記有効期限内である場合に前記アプリケーションの利用を許可し、その他の場合には前記アプリケーションの利用を禁止する利用許可部と、
前記利用許可部の動作に伴い、前記動的な日時情報を、前記現在時刻に更新する日時情報更新部と
を備える認証システムとして構成することができる。
クライアントに構成されるトークン保持部、利用許可部、および日時情報更新部は、それぞれアプリケーションとは別個に構成してもよいし、アプリケーションの一部として組み込んでもよい。

【0006】

本発明では、サーバから発行されるオフライン用トークンを用いて、クライアントにおけるアプリケーションの利用の許可／禁止を行うことができる。従って、オフライン用トークンの発行時には、クライアントはサーバにネットワークで接続されている必要があるが、その後は、サーバに接続されていなくとも、アプリケーションを利用することができるため利便性が確保される。
しかも、本発明で用いられるオンライン用トークンには、有効か否かを判定するための日時として、有効期限を表す固定的な日時情報と、認証の実行に応じて更新される動的な日時情報が含まれる。固定的な日時情報としては、オフライン用トークンを利用可能な最終の日時情報、オフライン用トークンの利用を開始可能な日時または発行日時、オフライン用トークンの利用を開始してから利用できなくなるまでの期間などの情報を用いることができる。これらを全てもちいてもよいし、一部を用いても良い。また、動的な日時情報としては、認証を実行した日時、アプリケーションを利用した日時、オフライン用トークンの利用を開始した後の経過時間などを利用することができる。その上で、現在時刻が動的な日時情報以降であること、および有効期限内であることという２つの条件を満たすときにアプリケーションの利用を許可するように判断する。ここで用いる現在時刻は、クライアントの時計に基づいて得られる時刻でよい。このように、固定的な日時情報に加えて、動的な日時情報を用いれば、仮に有効期限を過ぎた後にクライアントの時計を遡らせたとしても、現在時刻が動的な日時情報以降という条件を満たさないため、オフライン用トークンを不正に利用することはできなくなる。
従って、本発明は、不正を抑制しつつ、オフラインでアプリケーションを利用できる利便性を実現することが可能となる効果を奏する。

【0007】

本発明においては、
前記日時情報更新部は、前記動的な日時情報を、将来に向かう方向にのみ更新するよう規制されているものとしてもよい。
こうすることにより、動的な日時情報を遡らせるという不正を防ぐことができ、アプリケーションの不正利用をより確実に回避することが可能となる。

【0008】

このように日時情報の更新を規制する場合、
前記日時情報更新部は、オンラインとなった時には、前記規制を解除し、前記動的な日時情報を、前記ネットワーク経由で取得される日時に同期させるものとしてもよい。
こうすることにより、動的な日時情報が誤って不正確な日時となったときに、その修正を図ることができる。例えば、クライアントの時計が、何らかの理由で、有効期限以降の将来の日時に変動してしまったとすると、動的な日時情報もこれに併せて将来の日時に更新されてしまう可能性があり、真の現在時刻が有効期限内であったとしても、オフライン用トークンに基づくアプリケーションの利用ができなくなってしまう。そして、動的な日時情報は不正防止のため簡単には遡らせることができないから、一旦、かかる事態が生じてしまうと、クライアントの時計を正常に戻しても、アプリケーションの利用は再開できなくなってしまうおそれがある。
上記態様によれば、クライアントがオンラインとなった時には、例外的に動的な日時情報の同期を認めることができ、正常な時刻に遡らせることも可能となるから、アプリケーションの利用を復旧させることができる。

【0009】

また、本発明においては、
前記サーバは、前記クライアントからの認証要求に応じて、前記クライアントがオンライン状態にある場合の認証に用いるための該クライアントに固有のオンライン用トークンの有効性、および前記アプリケーションの起動を許可するための起動条件の少なくとも一方を踏まえて、該クライアントにおける前記アプリケーションの利用を許可するか否かの認証を行う認証部を有し、
前記クライアントは、前記アプリケーションの起動時および起動後の所定のタイミングで、繰り返し、前記サーバに対して前記認証要求を送信する認証要求送信部を有し、
前記サーバにおいて、
前記トークン発行部は、前記認証により前記アプリケーションの利用を許可する場合、該クライアントに固有の有効なオンライン用トークン、または前記クライアントに対して発行済みのオンライン用トークンが有効であることを示す情報を前記クライアントに送信し、
前記トークン管理部は、前記認証要求に対応する発行済みのオンライン用トークンであって、前記トークン発行部によって新たに生成されたオンライン用トークンとは異なるクライアントに対して発行されたものがある場合は、所定の無効化条件に従って当該発行済みのオンライン用トークンを無効化し、
前記クライアントにおいて、
前記利用許可部は、前記オンライン用トークンが有効であることが確認できたときは前記アプリケーションの利用を許可し、その他の場合は前記アプリケーションの利用を禁止するものとしてもよい。

【0010】

上記態様は、ネットワークに接続した状態での認証、即ちオンライン認証を実現する態様である。即ち、サーバは、クライアントからの認証要求に応じて認証を行う。この認証は、クライアントにおいて新たにアプリケーションを起動させる場合、および既にアプリケーションを利用している場合に行われる。後者の場合は、アプリケーションの利用中に、ユーザが指示しなくても、クライアントが定期的にサーバに対して認証要求を送信するのである。
サーバは、アプリケーションの利用を許可する場合には、オンライン用トークン等の情報をクライアントに送信する。例えば、クライアントにおいて新たにアプリケーションを起動するときは、新しいオンライン用トークンを発行し、それをクライアントに送信する。オンライン用トークン自体に代えて、オンライン用トークンの識別情報を送信する態様も含まれる。
一方、既にクライアントにおいてアプリケーションを利用しているときは、既存のオンライン用トークンが有効である旨の情報をクライアントに送信する。既存のオンライン用トークンに代わる新たなオンライン用トークンを発行し、それをクライアントに送信するようにしてもよい。
こうすることにより、クライアントでは、有効なオンライン用トークン（その識別情報や、オンライン用トークンが有効であることを示す情報も含む）を受け取ると、アプリケーションの利用を許可することができる。
本発明では、さらに、サーバは、異なるクライアントからの認証要求が送信された場合には、発行済みのオンライン用トークンを無効化した上で、新たなオンライン用トークンを発行する。発行済みのオンライン用トークンが無効化されることにより、従前、アプリケーションを利用していた端末では、アプリケーションの利用ができなくなる。つまり、ユーザは、使用する端末を変更したい場合、従前の端末でアプリケーションの利用を停止しなくても、新たな端末から認証要求を送信しさえすれば、容易に端末を変更することができることになる。
既に発行されているオンライン用トークンと異なる端末からの認証要求か否かを判断するために、本発明では、オンライン用トークンは、クライアントに「固有」なものとしている。例えば、クライアントの端末に固有の識別情報をオンライン用トークンに含めるようにしてもよいし、オンライン用トークンをクライアントの識別情報と関連付けて管理してもよい。

【0011】

本発明においては、
前記認証要求は、前記アプリケーションの開発者の識別情報、該アプリケーションの識別情報、該アプリケーションのユーザのアカウント情報、該クライアントの端末識別情報を含み、
前記認証は、前記認証要求に含まれる各情報と、前記サーバに予め登録された情報との整合性を考慮して行われるものとしてもよい。
こうすることにより，本発明による認証を複数の開発者、アプリケーション、ユーザ、クライアント端末で混乱なく利用可能なシステムとすることができる。例えば、認証要求にアプリケーションの開発者の識別情報を含めることにより、例え他の情報（アプリケーションの識別情報、アカウント情報、端末情報）が同一であったとしても、認証要求としては、開発者に関連づけられたものと認識することができるからである。従って、各開発者は、他の開発者がどのようなアプリケーションの識別情報、アカウント情報を用いているかを考慮せず、これらについて任意に設定することが可能となるのである。

【0012】

また、本発明においては、
前記サーバは、
前記アプリケーションの識別情報および前記ユーザのアカウント情報とを記憶しておくデータベースを、前記アプリケーションの開発者ごとに個別に備えるものとしてもよい。
こうすることにより、アプリケーションの開発者ごとに、データ管理をすることが可能となり、より本発明の利便性を向上させることが可能となる。

【0013】

本発明は、以上で説明した種々の特徴を必ずしも全て備えている必要はなく、適宜、その一部を省略したり、組み合わせたりして構成してもよい。また、本発明は、上述した認証システムとしての構成に限らず、種々の態様での構成が可能であり、
例えば、
ネットワークを介してサーバに接続されたクライアントにおいてアプリケーションを利用するための認証を行う認証方法であって、
前記サーバが実行する処理として、
前記クライアントからの認証要求に従い、前記アプリケーションの利用を許可するためのトークンとして、その有効期限を表す固定的な日時情報と、認証の実行に応じて更新される動的な日時情報を含み、前記クライアントがオフライン状態にある場合の認証に用いられるオフライン用トークンを生成して、該クライアントに送信するステップと、
前記生成されたトークンを管理するステップと
を備え、
前記クライアントが実行する処理として、
前記オフライン用トークンを保持するトークン保持ステップと、
現在時刻が、前記オフライン用トークンに含まれる前記動的な日時情報以降であり、かつ前記有効期限内である場合に前記アプリケーションの利用を許可し、その他の場合には前記アプリケーションの利用を禁止する利用許可ステップと、
前記利用許可ステップに伴い、前記動的な日時情報を、前記現在時刻に更新する日時情報更新ステップと
を備える認証方法として構成してもよい。
これらの認証方法においても、認証システムで説明した種々の特徴を組み込むことが可能である。

【0014】

また、上述の認証方法を、コンピュータに実現させるためのコンピュータプログラム、およびこれらのコンピュータプログラムを記録したコンピュータ読み取り可能な記録媒体として構成することもできる。かかるコンピュータプログラムとしては、サーバにインストールするものとして構成することもできるし、クライアントにインストールするものとして構成することもできる。後者の態様としては、
例えば、
ネットワークを介してサーバに接続されたクライアントにおいてアプリケーションを利用するための認証を行うために該クライアントにおいて実行させるコンピュータプログラムであって、
前記サーバに対して認証要求を送信する機能と、
前記サーバから、前記アプリケーションの利用を許可するためのトークンとして、その有効期限を表す固定的な日時情報と、認証の実行に応じて更新される動的な日時情報を含み、前記クライアントがオフライン状態にある場合の認証に用いられるオフライン用トークンを受信する機能と、
現在時刻が、前記オフライン用トークンに含まれる前記動的な日時情報以降であり、かつ前記有効期限内である場合に前記アプリケーションの利用を許可し、その他の場合には前記アプリケーションの利用を禁止する利用許可機能と、
前記利用許可機能の実行に伴い、前記動的な日時情報を、前記現在時刻に更新する日時情報更新機能と
を前記クライアントに実現させるためのコンピュータプログラムとしての構成である。
これらのコンピュータプログラムにおいても、認証システムで説明した種々の特徴を組み込むことが可能である。クライアントに実行させるコンピュータプログラムの場合、クライアントで利用するアプリケーションとは別のコンピュータプログラムとして用意することもできるし、アプリケーションに組み込む形で用意することもできる。

【図面の簡単な説明】

【0015】

【図1】実施例としての認証システムの構成を示す説明図である。

【図2】データベースの構成を例示する説明図である。

【図3】ネットワーク認証処理のフローチャートである。

【図4】スタンドアロン切替処理のフローチャートである。

【図5】アプリケーション利用許可処理のフローチャートである。

【図6】利用日時更新の内容を示す説明図である。

【発明を実施するための形態】

【0016】

Ａ．システム構成：
本発明の実施例について説明する。
図１は、実施例としての認証システムの構成を示す説明図である。認証システムは、インターネットＩＮＴにクライアントＰＣおよびサーバ１０が接続された環境下において、クライアントＰＣにインストールされたアプリケーションの利用についての認証をサーバ１０が与えるためのシステムである。以下、ネットワークを介した認証を、「クラウド認証」と称することもある。
図１においては、クライアントＰＣは１台のみを示したが、複数台であってもよい。クライアントＰＣは、ＣＰＵ、メモリなどを備え種々のアプリケーションを実行できるコンピュータであり、パーソナルコンピュータの他、タブレット、スマートフォン、携帯電話などを利用可能である。
認証システムは、サーバ１０に備えられる機能と、クライアントＰＣに備えられる認証システムモジュール２０とによって構築されることになる。本実施例では、サーバ１０およびクライアントＰＣに、図示した各機能ブロックを実現するためのコンピュータプログラムをインストールすることによって、ソフトウェア的に構成されるが、少なくとも一部をハードウェア的に構成することも可能である。また、サーバ１０に示した各機能ブロックは、複数のサーバによる分散処理によって実現してもよい。

【0017】

本実施例の認証システムは、例えば、次のような態様で利用される。アプリケーションの開発者であるデベロッパは、アプリケーションを利用する権利、即ちライセンスを、ユーザに有償で提供することにより利益を得る。かかる利益を適正に得るためには、ユーザによるアプリケーションの不正利用を防止する必要があり、そのためには、アプリケーションの利用時にユーザが有効なライセンスを有しているか否かを認証する必要がある。かかる認証を実現するのが、本実施例の認証システムである。この認証システムは、アプリケーションのデベロッパ自身が構築し、運用するものとしてもよいが、本実施例では、デベロッパ以外の運用主体が認証システムを運用する例を示した。即ち、デベロッパは、認証システムの運用主体と、認証システムの利用契約を締結した上で、クライアントＰＣにインストールされる認証システムモジュール２０を用意する。この認証システムモジュール２０は、デベロッパが開発するアプリケーションに組み込んでも良いし、アプリケーションと別のモジュールとしてもよい。デベロッパからアプリケーションのライセンスを受けたユーザは、自身のクライアントにアプリケーションをインストールすることにより、同時に、認証システムモジュール２０もインストールすることになる。かくして、アプリケーションは、本実施例の認証システムによる認証の下で、稼働するようになるのである。

【0018】

サーバ１０に備えられた各機能ブロックについて説明する。
サーバ１０には、デベロッパ情報データベース１６、ライセンス情報データベース１７、アカウント情報データベース１８の３種類のデータベースが備えられている。デベロッパ情報データベース１６は、認証システムを利用するアプリケーションのデベロッパに関する情報を格納する。ライセンス情報データベース１７およびアカウント情報データベース１８は、それぞれデベロッパごとに用意されるデータベースである。ライセンス情報データベース１７は、アプリケーションのライセンスを購入したユーザおよびライセンス条件などの情報を記憶する。アカウント情報データベース１８は、ライセンスを受けたユーザが利用可能なアカウント（またはユーザＩＤということもある）に関する情報を記憶する。これらのデータベースの内容については、後で具体的に説明する。
データベース管理部１３は、デベロッパ情報データベース１６、ライセンス情報データベース１７、アカウント情報データベース１８に対するデータの読み書きを管理する。
送受信部１１は、インターネットＩＮＴを介して種々の情報の送受信を実行する。本実施例で送受信される情報としては、例えば、アプリケーションの利用の認証を求める認証要求や、利用を許可するためのトークンなどが挙げられる。
認証部１４は、サーバ１０における各機能ブロックを統合する機能も奏しつつ、アプリケーションの認証を行う。本実施例では、後で説明する通り、アプリケーションの起動時に認証が行われる他、アプリケーションの利用中にも繰り返し認証が行われる。認証部１４は、クライアントＰＣから認証要求を受取り、それぞれのタイミングにおいて、デベロッパ情報データベース１６、ライセンス情報データベース１７、アカウント情報データベース１８、トークン管理部１５などに格納された情報を参照しながら、アプリケーションの利用可否を判断するのである。
トークン発行部１２は、認証部１４による認証の結果、アプリケーションの利用を許可する場合に、必要に応じて、新たなトークンを発行する。トークンとは、クライアントＰＣにアプリケーションの利用を許可するためのワンタイム、即ち使い捨ての情報である。
トークン管理部１５は、発行されたトークンを保持する。

【0019】

次に、クライアントＰＣに備えられた各機能ブロックについて説明する。
送受信部３０は、インターネットＩＮＴを介して各種情報の送受信をする。
アプリケーション３１は、クライアントＰＣで利用される種々のコンピュータプログラムである。本実施例の認証の対象となっているものもあれば、そうでないものも含まれ得る。本実施例では、以下、アプリケーション３１と呼ぶときは、本実施例の認証の対象となっているものを意味するものとする。
認証システムモジュール２０は、サーバ１０と連携して、本実施例の認証システムを構築するモジュールである。認証システムモジュール２０は、アプリケーション３１と個別のモジュールとして用意してもよいし、各アプリケーション３１に組み込むものとしてもよい。
認証要求送信部２１は、サーバ１０に対して認証を要求する情報（これを認証要求と呼ぶ）を送信する。認証要求送信部２１は、クライアントＰＣにおいて新たにアプリケーションを起動しようとするときに、認証要求を送信する。また、アプリケーションの利用中は、ユーザからの指示に関わらず所定のタイミングで繰り返し認証要求を送信する。
認証用情報記憶部２２は、認証要求に含まれる情報を一時的に格納しておく。認証要求に含まれる情報には、クライアントＰＣの端末固有の識別情報も含まれる。また、アプリケーションの認証要求に対して、サーバ１０からトークンが発行されているとき、認証用情報記憶部２２は、このトークンも記憶しておく。
利用許可部２３は、サーバ１０による認証が得られた場合には、アプリケーション３１の利用を許可する。また、本実施例では、クライアントＰＣがサーバ１０と接続されていない状態での認証も行うことができるスタンドアロンモードが用意されている。利用許可部２３は、スタンドアロンモードの場合には、認証用情報記憶部２２に記憶された情報、特にオフライン用トークンに基づいて、アプリケーション３１の利用可否を判断する機能も奏する。
日時情報更新部２４は、スタンドアロンモードにおいて、認証用情報記憶部２２に記憶されているオフライン用トークンに含まれる「利用日時」の情報を更新する。「利用日時」とは、後述する通り、オフライン用トークンの不正利用を防止するための情報である。日時情報更新部２４は、スタンドアロンモードでの認証が行われたときなど、所定のタイミングで、利用日時を更新するのである。

【0020】

Ｂ．データベース構成：
図２は、データベースの構成を例示する説明図である。
デベロッパ情報データベース１６は、認証システムを利用するアプリケーションのデベロッパに関する情報を格納するデータベースである。
デベロッパＩＤは、デベロッパの識別情報である。
契約情報は、認証システムの運用主体と、デベロッパとの契約に関連する情報を表す。契約情報には、例えば、デベロッパの名称、連絡先、契約条件、課金情報、支払情報などが含まれる。
デベロッパキーは、アプリケーションの認証の際に用いられるデベロッパに固有の情報である。デベロッパキーは、デベロッパＩＤと同じ情報とすることもできるが、本実施例では、別個の情報を用いるものとした。
アプリケーション名称およびアプリケーションＩＤは、本実施例の認証対象となるアプリケーションの名称および識別情報である。アプリケーション名称、アプリケーションＩＤは、デベロッパごとに複数設けることもできる。デベロッパ情報データベース１６は、デベロッパごとに情報が格納されるものであるから、アプリケーション名称、アプリケーションＩＤは、他のデベロッパのアプリケーション名称等と重複していても差し支えない。もっとも、本実施例では、混乱を回避するため、アプリケーションＩＤについては、デベロッパによってアプリケーションが新たに登録されたときに、認証システムが他のデベロッパとも重複しない固有の識別情報を付すものとした。

【0021】

ライセンス情報データベース１７、アカウント情報データベース１８は、それぞれデベロッパごとに用意されるデータベースである。
ライセンス情報データベース１７は、アプリケーションのライセンスを購入したユーザおよびライセンス条件などの情報を記憶する。ユーザによるライセンスごとに図示するデータが用意されることになる。
アプリケーションＩＤは、ライセンスの対象となるアプリケーションの識別情報である。デベロッパ情報データベース１６に格納されているアプリケーションＩＤに対応した情報である。
デベロッパキーは、デベロッパを表す情報であり、デベロッパ情報データベース１６に格納されている情報である。
購入ライセンス数は、ユーザが購入したライセンス数、即ちアプリケーションを同時に利用可能な数を表す情報である。他に、コンピュータにインストール可能な数を表す情報を追加してもよい。
適用開始日時は、ライセンスの適用によりアプリケーションの利用を開始できる日時を表す。
有効期限は、ライセンスの有効期限、即ちアプリケーションの利用が許可される期限を表す。
アカウント当たりのライセンス数は、一つのアカウント、即ち利用者ＩＤによってアプリケーションを同時に利用可能な数を表す。

【0022】

アカウント情報データベース１８は、ライセンスを受けたユーザが利用可能なアカウント（またはユーザＩＤということもある）に関する情報を記憶する。例えば、会社がライセンスを受け、複数の従業員にアプリケーションを利用させるような場合など、一つのライセンス情報に対して、複数のアカウント情報が対応づけられることもある。
利用者ＩＤは、アプリケーションの利用者の識別情報であり、パスワードは、アプリケーションを利用するために認証画面において入力すべき情報である。
権限は、アプリケーションの利用について、利用者に許容された権限である。本実施例では、クライアントがサーバに接続された状態でアプリケーションの認証を行うオンライン認証の他、サーバと接続されていないオフライン状態でも認証可能なスタンドアロンモードが用意されている。権限には、スタンドアロンモードの利用可否を設定可能とした。
適用開始日時は、利用者ごとに、アプリケーションの利用を開始できる日時を記憶している。

【0023】

いずれのデータベースにおいても、図示した各情報の全てを備えている必要はなく、一部を必要に応じて省略してもよい。また、図示した以外の情報をデータベースに追加しても良い。本実施例では、ライセンス情報データベース１７とアカウント情報データベース１８とを分けて用意したが、両者を統合したデータベースとすることもできる。

【0024】

Ｃ．トークンの構成：
次に、本実施例の認証で利用されるトークンの構成について説明する。トークンは、クライアントＰＣにアプリケーションの利用を許可するためのワンタイム、即ち使い捨ての情報である。トークンを構成する情報は、任意に設定可能であるが、本実施例では、以下の情報を含めるものとした。
「トークンＩＤ」、即ちトークンの識別情報である。
ライセンス情報データベース１７に格納されている「アプリケーションＩＤ」、デベロッパキー」である。
「ライセンス種別」、即ちオンライン認証用か、スタンドアロン用かを示す情報である。
ライセンス情報データベース１８に格納されている「利用者ＩＤ」である。
スタンドアロンモードのときに利用される情報として、「利用日時」、「有効期限」、「切替日時」などの情報である。これらの各情報の意味は後述する。
クライアントの「端末ＩＤ」、即ちハードウェア固有の識別情報である。
その他の管理情報などを含めることもできる。

【0025】

Ｄ．オンライン認証：
以下、本実施例の認証システムによる認証処理によって順に説明する。
図３は、オンライン認証処理のフローチャートである。オンライン認証とは、クライアントとサーバとがインターネットを介して通信可能な状況で行う認証処理である。この処理は、クライアントからサーバに対する認証要求が送信されたときにサーバによって実行される。認証要求が送信される場面としては、利用者が新たにアプリケーションを起動させるとき、および既にアプリケーションを利用しているときがある。後者の場合は、利用者の指示に関係なく、所定のタイミングで、クライアントが自動的に認証要求をサーバに送信するのである。

【0026】

サーバは、まず認証要求を受信する（ステップＳ１０）。認証要求には、デベロッパキー、アプリケーションＩＤ、利用者ＩＤ、パスワード、端末ＩＤが含まれる。デベロッパキーおよびアプリケーションＩＤが含まれることにより、認証システムを利用する契約が締結された正規のデベロッパが作成した正規のアプリケーションからの認証要求であることを確認することができる。また、デベロッパキーを含むことにより、アプリケーションＩＤ、利用者ＩＤ、パスワードは、他のデベロッパとの重複を考慮することなく、デベロッパごとに任意に設定された情報を利用することが可能となる。もっとも、利用者ＩＤ、パスワードなどは、認証システムにおいてデベロッパに依存せずに利用可能な情報としても差し支えない。
アプリケーションの利用中に送信される認証要求の場合は、利用者ＩＤやパスワードなどの情報を省略してもよい。また、デベロッパキー、アプリケーションＩＤなどの情報に代えて、認証の際に発行されるトークンを用いるようにしてもよい。
端末ＩＤは、クライアントに固有の情報であり、本実施例ではクライアントおよびアプリケーションの組み合わせに対して固有の情報となるSecureUDIDを利用するものとした。端末ＩＤとしては、他にＭＡＣアドレスなどを用いても良い。端末ＩＤを用いることにより、サーバは、インターネットに複数のクライアントが接続されている状態でも、認証要求を送信したクライアントを特定することができる利点がある。

【0027】

次に，サーバは、認証要求が有効か否かを判断する（ステップＳ１１）。本実施例では、次の４つの条件を満たすときに、認証要求が有効と判断するものとした。
条件(１)は、デベロッパキーが有効であること、即ち認証要求に含まれるデベロッパキーが、デベロッパ情報データベース１６に格納された情報と一致することである。
条件（２）は、アプリケーションＩＤが有効であること、即ち認証要求に含まれるアプリケーションＩＤが、デベロッパ情報データベース１６またはライセンス情報データベース１７に格納された情報と一致することである。
条件（３）は、利用者ＩＤ、パスワードが有効であること、即ちこれらの情報が、アカウント情報データベース１８に格納された情報と一致することである。
条件（４）は、ライセンスの有効期限内であること、即ち認証を行っている時刻が、ライセンス情報データベース１７に格納された「有効期限」の情報と整合することである。
アプリケーションの利用中に送信された認証要求の場合は、条件（３）を省略してもよい。

【0028】

上述の４つの条件のいずれかを満たさず、認証要求が有効ではないと判断されると（ステップＳ１１）、サーバは、アプリケーションの利用を認めることなく、オンライン認証処理を終了する。
一方、認証要求が有効であると判断された場合（ステップＳ１１）、サーバは、トークン管理部１５（図１参照)に格納された発行済みのトークンを検索し、認証要求に対応するトークンが発行されたか否かを判断する。認証要求に対応するトークンとは、デベロッパキー、アプリケーションＩＤ、利用者ＩＤが一致するトークンを言う。

【0029】

トークンが発行済みでない場合において（ステップＳ１２）、アプリケーションの利用数が有効範囲内におさまるときは（ステップＳ１７）、サーバは新規にトークンを発行する（ステップＳ１８）。クライアントがトークンを受け取ると、アプリケーションは利用可能となる。アプリケーションの利用数が有効範囲を超えるときは（ステップＳ１７）、サーバはアプリケーションの利用を認めることなく、オンライン認証処理を終了する。

【0030】

アプリケーションの利用数が有効範囲を超えるか否かの判断（ステップＳ１７）は、例えば、次の手順で行うことができる。トークン管理部１５に格納されたデベロッパキー、アプリケーションＩＤが認証要求と一致するトークンを検索することにより、アプリケーションの利用数を求めることができる。この利用数が、ライセンス情報データベース１７に格納された購入ライセンス数よりも小さい場合には、新たにアプリケーションの利用を認めても、利用数が購入ライセンス数を超えることはないため、アプリケーションの利用数は有効範囲内におさまると判断できる。また、この利用数が、ライセンス情報データベース１７と一致する場合は、アプリケーションの利用数は有効範囲を超えると判断できる。

【0031】

一方、認証要求に一致するトークンが発行済みの場合（ステップＳ１２）、サーバは、発行済みのトークンと認証要求にそれぞれ含まれる端末ＩＤが一致するかを判断する（ステップＳ１３）。
両者が一致するときは、サーバは、トークンを発行済みのクライアントから、アプリケーション利用中に繰り返し認証要求が送信されたものと判断し、トークンを継続利用する処理を行う（ステップＳ１６）。例えば、トークン管理部１５に格納されているトークンを改めてクライアントに送信してもよいし、発行済みのトークンが有効である旨の情報をクライアントに送信してもよい。

【0032】

発行済みのトークンと認証要求にそれぞれ含まれる端末ＩＤが一致しない場合（ステップＳ１３）、サーバは、利用者が異なる端末から認証要求を送信したと判断し、以下の処理を行う。まず、サーバは、アカウント当たりのライセンス数を確かめる（ステップＳ１４）。即ち、トークン管理部１５から認証要求に含まれる利用者ＩＤを含むトークンの数を求めることにより、認証要求を送ったアカウントによるアプリケーションの利用数を求め、この利用数と、ライセンス情報データベース１７に格納されたアカウント当たりのライセンス数を比較する。
この結果、アプリケーションの利用数がアカウント当たりのライセンス数の範囲内と判断されるときは（ステップＳ１４）、サーバは、先に説明したステップＳ１７の処理によって、アプリケーションの利用可否を判断する。また、アプリケーションの利用数がアカウント当たりのライセンス数を超過すると判断されるときは（ステップＳ１４）、発行済みのトークンを無効化して（ステップＳ１５）、利用中のアプリケーションの利用を停止した上で、先に説明したステップＳ１７の処理によって、アプリケーションの利用可否を判断する。
このように、同じ利用者ＩＤを含みつつ、端末ＩＤが一致しない認証要求がなされたときに、発行済みのトークンを無効化することにより、利用者は、それまでに利用していたアプリケーションを停止させるまでなく、異なる端末でアプリケーションを容易に利用することが可能となる利点がある。
トークンの無効化は、認証要求と利用者ＩＤが一致するトークンに対して行われるものであり、利用者ＩＤが異なるトークンに対しては、行われない。即ち、利用者ＩＤが異なる場合には、先にアプリケーションを利用していたものが優先して扱われ、利用者ＩＤが一致する場合には、あとから認証した端末が優先して扱われることになる。

【0033】

Ｅ．スタンドアロン認証：
図４は、スタンドアロン切替処理のフローチャートである。オンライン認証が行われた後、オフラインでもアプリケーションを利用することができるスタンドアロンモードに切り替えるための処理である。この処理は、利用者が、クライアントからサーバに対して切替要求を送信することによって、サーバにおいて実行される。

【0034】

サーバは、まず切替要求を受信する（ステップＳ２０）。切替要求には、トークン、有効期限、クライアント日時、および端末ＩＤの各情報が含まれる。トークンとは、オンライン認証によって発行されたトークンである。本実施例では、オンラインで認証を受けた後、スタンドアロンモードへの切替を行うものとしたため、このように切替要求にはトークンを含めることができる。もっとも、最初からスタンドアロンモードでの認証を認めるようにしてもよい。この場合でも、アプリケーションの起動時には、トークンを受け取るために、クライアントとサーバが接続されていることが前提となるから、先に説明したオンライン認証（図３参照）を実行した後、自動的にスタンドアロン切替処理に移行するようにすれば足りる。
有効期限はトークンの有効期限、クライアント日時は、クライアントが保持する時計に基づく日時情報である。端末ＩＤはオンライン認証処理と同様である。切替要求には、スタンドアロンモードでの利用を希望する期間などの情報を含めても良い。

【0035】

サーバは、受信した切替要求の有効性を判断する（ステップＳ２１）。本実施例では、次の２つの条件を満たすときに有効と判断するものとした。
条件（１）トークンが有効とは、切替要求に含まれるトークンが、サーバのトークン管理部１５（図１参照）に無効化されずに管理されていることを意味する。
条件（２）ライセンスの有効期限内とは、ライセンス情報データベース１７に格納された有効期限を過ぎていないことを意味する。ライセンス自体が有効期限を超過している場合は、スタンドアロンモードへの切替えを認める必要もないからである。
条件（１）（２）のいずれか一方または双方を満たさず、切替要求が無効と判断される場合には（ステップＳ２１）、サーバは、切替えを認めることなく、この処理を終了する。

【0036】

切替要求が有効な場合（ステップＳ２１）、サーバは、スタンドアロンモードへの変更が要求されたアプリケーションに対して有効なトークンが発行されているかを判断する（ステップＳ２２）。かかるトークンが発行されていない場合には、オンラインでの認証が未了と判断し、サーバは、切替えを認めることなく、この処理を終了する。
有効なトークンが発行されている場合には（ステップＳ２２）、そのトークンがスタンドアロンモードに設定されているか否かを判断し（ステップＳ２３）、既にスタンドアロンモードになっている場合には、そのトークンを継続利用する（ステップＳ２６）。つまり、クライアントに対して、改めて切替要求を認めることなく、既に発行されているトークンを再送するか、発行済みのトークンを利用できる情報を送信する。

【0037】

発行済みのトークンがオンライン認証用である場合には（ステップＳ２３）、サーバは、以下の手順で、スタンドアロンモードへの切替えのための処理を行う。まず、クライアントの時計の日時を取得し、その誤差が許容範囲内かを判断する(ステップＳ２４)。後述する通り、本実施例においては、スタンドアロンモードによる認証では、トークンに格納された日時情報によって、利用者によるアプリケーションの不正利用を防止している。スタンドアロンモードへの切替時に、クライアントの時計の誤差が大きい場合には、アプリケーションの不正利用を防止できないおそれがある。従って、誤差が許容範囲を超える場合には（ステップＳ２４）、スタンドアロンモードへの切替えを認めず、誤差が許容範囲内のときのみ、スタンドアロンモードへの切替を実行して（ステップＳ２５）、この処理を終了する。切替を認めるか否かの判断基準としての、「誤差の許容範囲」は、不正利用防止の観点から、任意に設定可能な値である。
スタンドアロンモードへの切替では、スタンドアロンモードであることを表すオフライン用トークンがクライアントに送信される。オフライン用トークンには、スタンドアロンモードへの切替日時、同モードで利用可能な有効期限、および利用日時などの情報が含まれる。切替日時および有効期限は、スタンドアロンモードへの切替時に設定される固定的な日時情報であるが、利用日時は、オフライン用トークンを利用して認証を行った最後の日時を表す情報であり、オフライン用トークンの利用に伴って更新される動的な日時情報である。クライアントは、このオフライン用トークンを、認証用情報記憶部２２（図１参照）に保持する。

【0038】

図５は、アプリケーション利用許可処理のフローチャートである。この処理は、クライアントにおいて、アプリケーションを利用する際に実行される処理である。この処理が実行される場面としては、アプリケーションを新規に起動するとき、およびアプリケーションを既に利用しているときがあり、クライアントがオンラインの場合とスタンドアロンの場合とがある。アプリケーションの利用中である場合には、例えば、一定の周期でこの処理を実行するようにしてもよいし、アプリケーションに対するユーザの特定の操作をトリガとして実行するようにしてもよい。

【0039】

処理を実行し、クライアントがネットワークに接続されている場合であって（ステップＳ３０）、アプリケーションを起動中でない場合（ステップＳ３１）、つまりアプリケーションを新たに起動する場合には、クライアントは認証画面を表示する（ステップＳ３２）。認証画面とは、利用者ＩＤおよびパスワードなどの認証情報を入力するための画面である。そして、入力された認証情報も含めて、認証要求をサーバに送信し、またクライアントの時計をサーバと同期する（ステップＳ３３）。
既にアプリケーションを起動しているときは（ステップＳ３１）、認証画面の表示をスキップした上で、認証要求をサーバに送信し、またクライアントの時計をサーバと同期する（ステップＳ３３）。この場合の認証要求からは、利用者ＩＤやパスワードの情報は省略してもよい。
ステップＳ３３の処理において、クライアントの時計を同期するのは、次の理由によるものである。本実施例では、スタンドアロンモードにおいて、トークンに記録された日時情報（利用日時という）によって、アプリケーションの不正利用を防止している。かかる観点から、クライアントとサーバの時計が同期していることが好ましいのである。また、スタンドアロンモードにおいて時計が同期されたときは、それに合わせてトークンの利用日時の情報も同期させるものとしている。この意義については、後で説明する。

【0040】

クライアントは、認証要求を送信した後、スタンドアロンモードでない場合は（ステップＳ３４）、サーバでの認証が完了するのを待つ。サーバからトークンが受信できない場合には（ステップＳ３５）、クライアントは、アプリケーションの利用を禁止して（ステップＳ３６）、この処理を終了する。トークンが受信できない（ステップＳ３５）とは、トークンが所定の待機時間内に受信できなかった場合や、認証に失敗した旨の情報をサーバから受信した場合などが含まれる。
一方、サーバからトークンを受信できた場合には（ステップＳ３５）、クライアントはアプリケーションの利用を許可して（ステップＳ４３）、この処理を終了する。利用の許可には、新規にアプリケーションを起動する場合、および利用中のアプリケーションを継続的に利用可能とする場合の双方が含まれる。受信したトークンは、認証用情報記憶部２２（図１参照）に保持される。

【0041】

スタンドアロンモードの場合（ステップＳ３４）には、利用可否判断を行う（ステップＳ４０)。クライアントがネットワークに接続されていない場合（ステップＳ３０）も同様である。
利用可否判断とは、アプリケーションの利用を許可するか否かの判断であり、クライアントは、認証用情報記憶部２２に保持されたオフライン用トークンを参照し、次の３つの条件を満たすときに、利用可能と判断する。

【0042】

条件（１）は、クライアント日時は切替日時以降であるという条件である。クライアント日時とは、クライアントの時計の日時を意味する。切替日時とは、スタンドアロンモードへの切替えが行われた日時を意味する。これらの情報は、オフライン用トークンに記録されている。
条件（２）は、クライアント日時は利用日時以降であるという条件である。利用日時とは、オフライン用トークンを用いた認証が最後に行われた日時を意味する。
条件（３）は、クライアント日時は有効期限内であるという条件である。
認証用情報記憶部２２にオフライン用トークンが保持されていないときは、そもそもスタンドアロンモードが許容されていないことになり、上の３つの条件のいずれも満たさないから、アプリケーションの利用は不可と判断されることになる。

【0043】

上記条件のうち、条件（１）（３）は、切替日時、有効期限という固定的な日時情報を用いた判断である。仮に、これらの条件のみでアプリケーションの利用可否を判断するとすれば、有効期限を過ぎた後に、クライアントの時計を、遡らせることによって、容易に条件（１）（２）を満たすようにでき、アプリケーションの不正利用をすることが可能となってしまう。
これに対し、条件（２）は、オフライン用トークンを用いて認証するたびに更新される動的な日時情報である。従って、オフライン用トークンを利用するにつれて、日時の進行に伴って、条件（２）は有効期限に近づくように更新されることになるから、条件（２）（３）を満たす時間幅は徐々に狭くなることになる。仮に有効期限を過ぎてしまえば、条件（２）（３）を満たす範囲は存在しなくなることも起き得る。このように動的な日時情報を組み合わせてアプリケーションの利用可否を判断することにより、不正利用を防止することができる利点がある。
本実施例では、こうした機能をさらに強化するため、利用日時の情報は、原則として将来に向かってのみ更新可能とし、遡る変化は許容しないものとした。

【0044】

条件（１）〜（３）のいずれかを満たさない場合には、アプリケーションの利用は不可と判断され（ステップＳ４１）、アプリケーションの利用が禁止される（ステップＳ３６）。
条件（１）〜（３）のいずれも満たす場合には、アプリケーションの利用が可能と判断され（ステップＳ４１）、利用日時を更新した後（ステップＳ４２）、アプリケーションの利用が許可される（ステップＳ４３）。

【0045】

ステップＳ４０で説明した条件（１）〜条件（３）の意義について改めて説明する。
図６は、利用日時更新の内容を示す説明図である。
図６（ａ）は、アプリケーション利用許可処理（図５）のステップＳ４０に示した条件（１）〜（３）を図示している。条件（１）は、黒塗りの三角で示したクライアント日時が、矢印ｔｒ１に示すように、切替日時以降の範囲にあるときに満たされる。条件（２）は、クライアント日時が、矢印ｔｒ２に示すように、利用日時以降の範囲にあるときに満たされる。条件（３）は、クライアント日時が、矢印ｔｒ３に示すように、有効期限までの範囲にあるときに満たされる。この結果、条件（１）〜（３）を満たす範囲は、図中のハッチングを示した範囲ｅｔ１にクライアント日時が存在するときに満たされることになる。
そして、利用日時は、矢印Ａで示すように、オフライン用トークンの利用に伴って、将来方向に向かってのみ更新される。

【0046】

利用日時が更新されることにより、図６（ｂ）に示すように、条件（１）〜（３）を満たす範囲ｅｔ２は、徐々に狭くなる。この状態で、クライアント日時を図示するように、意図的に過去に遡らせて設定したとしても、利用日時に基づく条件（２）を満たさないため、アプリケーションは利用できないことになる。

【0047】

このようにスタンドアロンモードでの不正利用の防止に寄与する利用日時であるが、何らかの理由でクライアント日時が、将来の日時に設定されてしまうと、図６（ｃ）に示す状態となる。例えば、クライアント日時が有効期限を過ぎた日時に設定されると、認証が行われた時点で、オフライン用トークンの利用日時も、同様に有効期限以降の日時に設定されてしまい、矢印ｔｒ１〜ｔｒ３の条件を全て満たす領域は存在しなくなってしまう。この結果、アプリケーションの利用は許可されなくなる。
かかる状態を解消するためには、利用日時を正確な日時に修正する必要があるが、本実施例では、利用日時は原則として将来方向に向かってのみ更新可能としているため、たとえクライアント日時を矢印ｔａで示すように正確な日時に修正したとしても、利用日時は遡らないため、やはり矢印ｔｒ１〜ｔｒ３の条件を全て満たす領域は得られない。
本実施例では、かかる状態を回避するため、アプリケーション利用許可処理（図５）のステップＳ３３において、オンラインでサーバとクライアントの時計を同期できたときに限り、例外的に利用日時も過去に遡ることを許容している。この結果、クライアントがサーバに接続されれば、利用日時が、図６（ｃ）中の真正の現在日時に修正されるため、条件（２）は、破線の矢印ｔｒ２に示す状態となり、全ての条件を満たす時間範囲を回復させることができる。

【0048】

以上で説明した本実施例の認証システムによれば、スタンドアロンモードを設けることにより、クライアントがオフライン状態にあるときでも、アプリケーションを利用することができる。また、スタンドアロンモードにおいて、固定的な日時情報（切替日時および有効期限）と動的な日時情報（利用日時）とを併用することにより、アプリケーションの不正利用を防止することができる。
また、オンラインで認証処理を行う際に、利用者が、クライアントを変えて認証要求をしたときは、発行済みのトークンを無効にすることにより、それまで利用していたアプリケーションを停止するまでなく、異なるクライアントでアプリケーションの利用を開始することが可能となる利点がある。

【0049】

本実施例で説明した種々の特徴は、必ずしも全てを備えている必要はなく、その一部を適宜、省略したり組み合わせたりしてもよい。

【産業上の利用可能性】

【0050】

本発明は、ネットワークを介してサーバに接続されたクライアントにおいてアプリケーションを利用するための認証を行うために利用することができる。

【符号の説明】

【0051】

１０…サーバ
１１…送受信部
１２…トークン発行部
１３…データベース管理部
１４…認証部
１５…トークン管理部
１６…デベロッパ情報データベース
１７…ライセンス情報データベース
１８…アカウント情報データベース
２０…認証システムモジュール
２１…認証要求送信部
２２…認証用情報記憶部
２３…利用許可部
２４…日時情報更新部
３０…送受信部
３１…アプリケーション

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】