JP6548525B2 - ライセンス管理システム、クライアント、ライセンス管理方法、及びコンピュータプログラム - Google Patents

Description

本発明は、フローティングライセンスによるアプリケーションのライセンス管理システム、クライアント、ライセンス管理方法、及びコンピュータプログラムに関する。

クライアントに対して有償アプリケーションの使用許諾を与える方法のひとつとして、フローティングライセンス方式がある。これは、ユーザが購入した複数のライセンス（同時利用可能な数のライセンス）をライセンスサーバ（単にサーバと呼ぶ）で管理し、該サーバがクライアントにライセンスを貸し出すことにより、該クライアントにて一時的にアプリケーションを使用可能にする方式である。すなわち、購入したライセンス数の範囲内でアプリケーションを同時に起動することができる。なお、アプリケーション本体は何台にでもインストールすることができ、各クライアントにおいて、アプリケーションを起動した時に、当該アプリケーションがサーバに接続してライセンスの発行を受け、ライセンスの発行を受けたアプリケーションを使用可能にする。サーバは、ユーザが購入したライセンス数の範囲内でアプリケーションの起動を許可し、貸し出し中のライセンスの数が、購入済みライセンス数の上限に達すると、それ以上、他のクライアントでアプリケーションを起動させないように制御する。この時、いずれかのクライアントがアプリケーションの使用を終了してサーバにライセンスを返却すると、別のクライアントが当該返却されたライセンスを取得することにより、当該別のクライアントでアプリケーションを起動できるようになる。このようなフローティングライセンスを用いて、時間帯をずらしてクライアントがアプリーションを利用することで、購入したライセンス数以上の複数のクライアント上で当該アプリケーションを利用することが可能となる。

上述したようにフローティングライセンスでは同時にアプリケーションを使用できるクライアントの数に限りがあるため、クライアントは作業中途切れずにフローティングライセンスを保持し、作業後は速やかにサーバへ返却することが望ましい。そのため、アプリケーション起動時にライセンスを取得し、終了時（プロセス終了時）に返却するという使い方が一般的である。

特許文献１では、ライセンスは、アプリケーション起動時に取得され、終了時に返却され、また一定回数通信に失敗した際には失効される、という使い方が示されている。

特開２００３−１０８２５２号公報

クライアント装置のＯＳ（オペレーティングシステム）には、１つのクライアント上で複数のアカウントを切り替えてサービスを利用するマルチアカウント機能を持っているものがある。マルチアカウント環境では、それぞれのアカウント上で起動されたアプリケーションは、他のアカウント環境からの影響は受けず、独立して動作することができる。

なお、クライアントＯＳでは、現在使用中のアカウント環境がアクティブな状態になり、それ以外のアカウント環境は非アクティブな状態になる。アクティブな状態とは、デスクトップ画面が表示され、そこで動作するアプリケーションに対して自由にユーザ操作ができる状態を指す。一方、非アクティブな状態とは、アクティブな環境に隠れていて、そこで動作するアプリケーションに対してのユーザ操作はできない状態を指す。

ここで、あるアカウント環境Ａで起動されたアプリケーションが、フローティングライセンスを取得して動作しているケースを考える。別のアカウント環境Ｂへの切り替えが発生した場合、該アプリケーションが動作しているアカウント環境Ａは非アクティブとなるが、アカウント環境Ａで実行中のアプリケーション自体は動作し続けるのでライセンスの保有は続くことになる。よって、アカウント環境Ａの利用者による操作が一切されない状態であるにもかかわらず、ライセンスはサーバに返却されないので、別のユーザの利用機会を奪い、ライセンスの稼働率（ユーザによって実際に操作がされているアプリケーションの数）を下げることになる。これは、フローティングライセンスの運用の観点からは好ましくない。これを解決するには、アカウント切り替えした時点で、アカウント環境Ａで実行中のアプリケーションを強制終了して、ライセンスを返却することが考えられる。

しかし、ほんの一時的な利用のためにアカウント切り替えを行った後、再度アカウント切り替えを行ってすぐに元のアカウント環境に戻るケースもある。このような場合でも、アカウント切り替え時にアプリケーションを終了して一旦ライセンスを返却してしまうと、再度アカウント切り替えを行って元のアカウント環境でアプリケーションを再利用する際にはライセンスの再取得が必要となる。一方で、上述したように、フローティングライセンスには同時使用者数の上限があるため、すぐにライセンスを再取得できるとは限らない。すなわち、一時的なアカウント切り替えであったとしても、一旦ライセンスを返却すると、当該返却したライセンスが他のユーザにより取得されてしまい、元のアカウント環境に戻ったときにすぐに作業を再開できなくなるリスクがある。

以上説明したように、非アクティブになったアカウント環境で動作するアプリケーションが長時間ライセンスを保有し続ければライセンスの実稼働率が低下するという問題がある。かといって、アカウント切り替えした時点ですぐにライセンスを返却すると、一時的なアカウント切り替えであった場合に利用者の利便性を損ねる可能性がある、という課題があった。

上記課題を解決するために、本発明のクライアントは、アプリケーションを起動する際にライセンスサーバからライセンスを取得するクライアントであって、前記ライセンスサーバから、有効期間を有するライセンスを取得する取得手段と、定期的に、前記取得したライセンスを更新する更新手段と、前記アプリケーションを実行している環境が非アクティブになったか判断する第１の判断手段と、前記第１の判断手段で前記環境が非アクティブになったと判断した場合、前記更新手段による前記ライセンスの定期的な更新を停止する停止手段と、前記アプリケーションを実行している環境がアクティブになったか判断する第２の判断手段と、前記第２の判断手段で前記環境がアクティブになったと判断した場合、前記更新手段による前記ライセンスの定期的な更新を再開する再開手段と、前記ライセンスの有効期間が切れた場合、前記アプリケーションに対するライセンス失効処理を実行する失効処理手段と、有する。

本発明によれば、非アクティブになったアカウント環境が長時間ライセンスを保有することを避けることができる。また、アプリケーションは、非アクティブになったときにすぐにライセンスを返却するのではなく、所定期間ライセンスを保持し続ける。したがって、利用者がすぐに元のアカウント環境に戻して該アプリケーションでの作業を再開する場合には、すぐに作業を再開でき、利便性が向上する。

システムの構成を示す図 ハードウェア構成を示す図 ソフトウェア構成を示す図 フローティングライセンスの時系列処理を示す図 ライセンス更新に関する処理のフロー図 実施例１におけるライセンス処理に関する時系列図 実施例２におけるライセンス処理に関する時系列図 実施例３におけるライセンス処理に関する時系列図 実施例３におけるフロー図 実施例３において、アカウント切り替え時に、任意の有効期間を指定したライセンスを取得する場合のフロー図

（実施例１）
［システム構成］
図１は、本発明の一実施形態におけるフローティングライセンス管理システムの構成を示す図である。本実施形態は、ライセンスサーバと複数のクライアントがネットワークを介して通信可能なシステムである。ＬＡＮ１００は、クライアント１１０（及び１１１）とライセンスサーバ１２０を通信可能とするＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）であるが、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）であっても構わない。

クライアント１１０（及び１１１）にはアプリケーション３００がインストールされている。クライアントは、ライセンスサーバから当該アプリケーションの使用許諾（フローティングライセンス）を取得することによって、当該アプリケーションの機能の一部または全体にかかっている使用制限が解除され、アプリケーション３００を利用できる。

ライセンスサーバ１２０は、クライアント１１０（及び１１１）内で動作するアプリケーション３００に、フローティングライセンスの発行を行うライセンスサーバであり、予め購入済みの所定数（ひとつ以上）のライセンスを保有しているものとする。

フローティングライセンス（以下、単にライセンス）とは、ライセンスサーバ１２０が、ライセンスを要求するクライアント１１０に一時的に貸し出すものである。各クライアント１１０（及び１１１）では、予めアプリケーション３００をインストールしておき、利用する際にライセンスをライセンスサーバ１２０から受けることで、当該アプリケーション３００を利用することができる。利用が完了したら、前記ライセンスをライセンスサーバ１２０に返却することで、他のユーザも、当該返却されたライセンスを用いてアプリケーションの利用が可能となる。以上の仕組みにより、ライセンス数以上のユーザによる当該アプリケーションの利用が可能となっている。

なお、ライセンスサーバ１２０が発行するライセンスとは、ファイル形式であっても良いし、バイナリデータや使用許諾フラグのようなものであっても良い。どのような方法であっても、ライセンスサーバ１２０とクライアント１１０の間で、使用許諾をセキュアに取り扱えるものであれば構わない。以後、媒体や手段に関わらず、クライアント１１０がライセンスサーバ１２０から使用許諾（ライセンス）を得ることをライセンス取得、使用許諾をサーバに返却することをライセンス返却と呼ぶ。

［ハードウェア構成］
図２は、図１に示したクライアント１１０（及び１１１）のハードウェア構成（コンピュータのハードウェア構成）を示す図である。図２において、キーボードやポインティングデバイスなどのユーザ操作入力を受信する入力デバイス２０５が設けられている。さらに、ユーザに視覚的な出力情報フィードバックを与える表示部（ディスプレイ）２０２を備える。さらに、本実施形態における各種プログラムや実行情報を保管する記憶デバイスＲＡＭ２０３、ＲＯＭ２０４、ＨＤＤ（ハードディスクドライブ）やＦＤＤ（フロッピー（登録商標）ディスクドライブ）などの外部メモリ２０６が設けられる。さらに、外部機器との通信を行うインターフェースデバイスＩ／Ｏ２０７を備え、プログラム実行を行うＣＰＵ２０１を備える。クライアント１１０とライセンスサーバ１２０は、インターフェースデバイスＩ／Ｏ２０７を介して互いに通信を行う。また、ライセンスサーバ１２０も同様のハードウェア構成であってもよい。

なお、本実施例で説明される処理は、ＲＯＭ２０４、または外部メモリ２０６等の記憶媒体に保存されたプログラムをＲＡＭ２０３にロードし、ＣＰＵ２０１で実行することによって実現される。すなわち、コンピュータは、当該各装置に記憶されているコンピュータプログラムを実行することにより、後述するクライアント１１０（またはライセンスサーバ１２０）の各処理部として機能する。

［ソフトウェア構成］
図３は、クライアント１１０およびライセンスサーバ１２０が、それぞれのコンピュータプログラムを実行することにより実現されるソフトウェア構成の一例を示す図である。

最初に、クライアント１１０上で実行されるアプリケーション３００の説明を行う。アプリケーション３００は、入力部３０１、管理部３０２、処理実行部３０３、ライセンス要求送信部３０４、ライセンス更新処理部３０５として機能する。

入力部３０１は、ユーザからの操作を受け付け、入力された要求を管理部３０２に伝える。入力部３０１での入力がアプリケーションの起動要求だった場合、管理部３０２はライセンスが必要になったと判断し、ライセンス要求送信部３０４にライセンスの取得を命ずる。ライセンス要求送信部３０４は、ネットワークを介してライセンスサーバ１２０に、ライセンスの取得要求を行う。このとき、クライアントを一意に識別することが可能なクライアント識別子を合わせて送る。クライアント識別子には、Ｍａｃアドレスやハードウェアパーツのシリアル番号、あるいはそれらの組合せで作られた計算値などを使うことができる。ライセンスサーバ１２０の詳細は後述するが、利用可能なライセンスが残っていれば、ライセンス要求送信部によるライセンス取得処理は成功する。ここでは、有効期間Ｔ２（例えば１０分）が設定されたライセンスが得られるものとする。

ライセンス要求送信部３０４は、ライセンス取得処理の成否と、成功の場合は有効期限Ｔ２を、管理部３０２に伝える。管理部３０２は、ライセンス取得に成功した場合は、アプリケーションの起動を処理実行部３０３に命ずる。処理実行部３０３は、アプリケーションの起動を実行する。アプリケーションの起動に成功した後、管理部３０２は、入力部３０１から機能の実行や操作画面での処理（ドキュメント編集や印刷指示等）の要求を受けた際も、同様に処理実行部３０３へ命令する。一方、管理部３０２は、ライセンス要求送信部３０４でライセンス取得に失敗した場合は、入力部３０１で入力されたアプリケーション起動要求は実行しないように制御する。この場合、操作しているユーザに対してメッセージ等でフローティングライセンスを取得できなかったこと（同時に起動可能なライセンス数の上限に達していること）を通知してもよい。

アプリケーション３００では、有効期間Ｔ２のライセンス取得に成功した場合、その後、ライセンスの有効期間が切れないように、ライセンスの更新作業を継続的に行う。以下に詳細を説明する。

管理部３０２は、ライセンス更新処理部３０５にライセンスの定期更新を命ずる。ライセンス更新処理部３０５は、ライセンス要求送信部３０４に対し、間隔Ｔ１毎（例えば３分毎）にライセンスの更新を命ずる。ライセンス要求送信部３０４は、ライセンス更新命令を受けると、ネットワークを介してライセンスサーバ１２０と接続し、ライセンスの更新を要求する。ライセンスサーバ１２０は、使用許諾中のクライアントからの要求であれば、通常は更新に成功する。ここで、更新に成功すると、その更新時点から更に有効期間Ｔ２後（例：１０分後）までの新たなライセンスを取得する。ライセンスは、新しいライセンスで上書きされ、ライセンス取得に成功している限り継続してライセンスの効力は維持される。以上の処理を、ライセンスの更新と呼ぶ。

一方、ライセンス要求送信部３０４が、ライセンスサーバ１２０との接続に失敗した場合、または、ライセンスサーバ１２０からのライセンス取得に失敗した場合、ライセンスの更新はなされない。例えば、クライアントがネットワークから切り離された場合や、ライセンスサーバ１２０がダウンした場合などに失敗する。ライセンス更新に失敗した場合は、更に一定間隔後（例えば３分後）に再度ライセンス更新を試みる。ライセンス要求送信部３０４でのライセンス取得で失敗が続き、その結果、ライセンスの有効期間Ｔ２内にライセンスを更新できなかったと判断した場合、取得していたライセンスは権利を失効する。この時、管理部３０２は、何らかの期限切れ処理を行う。例えば、アプリケーションの機能制限を実行してアプリケーション終了を促す、ユーザに期限切れのメッセージを表示する、ライセンス更新処理部３０５に命じて定期更新を終了する、等の対応を行うことができる。なお、ライセンス要求送信部３０４でのライセンス取得で何度か失敗しても、ライセンス失効前に再取得ができれば、ライセンスの効力は更新される。

なお、入力部３０１で入力された要求がアプリケーションの終了要求だった場合、管理部３０２はライセンスが不要になったと判断し、ライセンス要求送信部３０４にライセンスの返却を命じる。ライセンス要求送信部３０４は、ライセンスサーバ１２０にライセンスの返却を行う。

次にライセンスサーバ１２０について説明する。ライセンスサーバ１２０は、予め購入済みの（１つ以上の）ライセンスを、ライセンスプール３２４に格納しているものとする。本システムでは、ライセンスプール３２４に格納済のライセンス数を上限に、クライアントからの要求に応じてライセンスの発行（貸し出し）を行う。ライセンス情報処理部３２３では、少なくともライセンスカウント（残っているライセンス数）と使用許諾先を管理しており、前記ライセンスカウントの初期値はライセンス総数となる。

ライセンス要求受信部３２１は、アプリケーション３００からのライセンス取得要求、またはライセンス返却要求を受信し、管理部３２２に伝える。

管理部３２２は、要求がライセンス取得要求だった場合、ライセンス情報処理部３２３に対して該要求と共に受信したクライアント識別子を送り、クライアント識別子に該当するクライアントへ既に発行しているか問い合わせる。ライセンス情報処理部３２３が該クライアントに対し既にライセンス発行済みと判断した場合、ライセンス更新の要求であるので、管理部３２２は、ライセンス要求受信部３２１へ成功ステータスと新たな有効期間Ｔ２で更新したライセンスを返信する。また、ライセンス情報処理部３２３では、ライセンス更新後の新たな有効期限をクライアント識別子に紐付けて管理する。

ライセンス情報処理部３２３がクライアント識別子を確認した際に、該当するクライアントへの発行がなかった場合は、新規の要求と判断される。このとき、ライセンス情報処理部３２３は、更にライセンスカウントに基づいて、発行可能なライセンスが残っているかを確認する。ライセンスカウントは、発行可能なライセンスの残数を表しており、ライセンスカウントが１以上だった場合は、まだ発行可能なライセンスが残っていることを意味する。その場合、管理部３２２は、ライセンス情報処理部３２３に、ライセンスカウントを−１するよう命じ、ライセンス要求受信部３２１へ成功ステータスと有効期間Ｔ２で用意されたライセンスを返信する。また、ライセンス情報処理部３２３では、当該要求を行ったクライアントのクライアント識別子と当該発行したライセンスの有効期限とを関連付けて記録・管理する。

以上のように、ライセンスサーバ１２０は、使用許諾済のクライアントに対しては期限を更新したライセンスを再発行し（ライセンスカウントは減らない）、使用許諾前のクライアントに対してはライセンスカウントを−１してからライセンスを発行する。前者はアプリケーション３００からのライセンス更新要求に、後者はアプリケーション起動時の新たなライセンス取得要求に、それぞれ応じたものとなる。

なお、ライセンスカウントが０だった場合は、これ以上発行可能なライセンスは残っていないことを意味する。その場合、管理部３２２は、失敗ステータスをライセンス要求受信部３２１へ返信する。

このように、ライセンス要求受信部３２１は、ライセンス取得要求またはライセンス更新要求を受信した場合、クライアント１１０に、成否のステータスと、成功時にはライセンスを返信する。

ライセンス要求受信部３２１がライセンス要求送信部３０４からライセンス返却要求を受信した場合、管理部３２２は当該返却されたライセンスと当該要求を行ったクライアントのクライアント識別子とを受け取る。また、管理部３２２は、ライセンス情報処理部３２３に命じてライセンスカウントを１つ増加し、使用許諾先として管理していた当該要求を行ったクライアントのクライアント識別子を削除する。

なお、ライセンス発行中のクライアント１１０からのライセンス更新要求が途切れ、そのまま有効期限に達するライセンスもある。管理部３２２では、有効期限に達したライセンスを認識した場合、発行中のライセンスは失効したと判断し、ライセンス情報処理部３２３に対してライセンス返却時と同様の処理を命ずる。すなわち、有効期限に達して、ライセンスカウントを１つ増加して、当該ライセンスを失効したクライアントのクライアント識別子を削除する処理を行う。このとき、アプリケーション３００では、ライセンス更新ができずに、有効期間Ｔ２が経過するので、当該ライセンスが失効して、ライセンス期限切れ処理を実行することになる。

図４は、フローティングライセンスの取得、更新、失効の一例を説明した図である。

アプリケーション３００は、起動要求を受けると（時刻ｐ１）、ライセンスサーバ１２０と接続してライセンスを要求し、有効期間Ｔ２（例えば１０分）のライセンスＬ１を取得したものとする。間隔Ｔ１（例えば３分）経過後（時刻ｐ２）、アプリケーション３００は、ライセンスＬ１を更新するために再びライセンスを要求する。ライセンスサーバ１２０に接続できた場合は、ライセンスサーバ１２０においてライセンス更新処理が行われ、アプリケーション３００はライセンスサーバ１２０から有効期間Ｔ２のライセンスＬ２を取得する。ライセンスＬ２が取得された場合、前述したライセンスＬ１は、ライセンスＬ２で上書きされる。更に間隔Ｔ１経過後（時刻ｐ３）、アプリケーション３００は、ライセンスＬ２を更新するために再びライセンスを要求する。ライセンスサーバ１２０に接続できた場合はライセンスサーバから有効期間Ｔ２のライセンスＬ３を取得できるので、同様にライセンスＬ３でライセンスＬ２が上書きされ、ライセンスは更新される。以後、更新が成功している間は有効期限が延び続ける。

一方、時刻ｐ３でライセンス更新された後に、クライアント１１０がネットワークから切り離されたとすると、時刻ｐ４、時刻ｐ５、時刻ｐ６でのライセンス更新要求は失敗する。そして、ライセンスＬ３の有効期限に達すると、ライセンスＬ３は失効するので、アプリケーション３００ではライセンス期限切れ処理（機能制限等）を実行する。このとき、ライセンスサーバ１２０でも同様にライセンスＬ３の有効期限に達したと判断し、同クライアントに発行中のライセンスはライセンスプール内に復元される。なお、有効期限は、特定の時間が経過した、または特定の時間に達したことで判断しても良いし、通信に特定回数失敗したことで判断しても良い。

［アカウント環境切り替え時のライセンス更新に関する処理］
図５は、アカウント環境切り替え機能を有するクライアント１１０において、アプリケーション３００が実行する、ライセンスの更新に関する処理フローを示した図である。

入力部３０１にてアプリケーションの起動要求を受けると、Ｓ５０１にて、ライセンス要求送信部３０４がライセンスサーバ１２０と接続し、ライセンス（有効期間Ｔ２）の取得要求を行う。Ｓ５０２にて、管理部３０２がライセンス取得の成否を判断し、失敗した場合はＳ５０３へ、成功した場合はＳ５０４へ進む。Ｓ５０３では、ライセンス取得に失敗した時の処理、例えば、アプリケーションを起動しないように制御して、ユーザへのメッセージ通知等を行い、終了する。

取得に成功した場合、Ｓ５０４では、管理部３０２が処理実行部３０３に命じてアプリケーションを起動する。その後、Ｓ５０５にて、管理部３０２がライセンス更新処理部３０５に命じて、定期的にライセンスを更新する処理（ライセンスの定期更新処理）を開始する。

ここで、ライセンス更新処理部３０５によって実行されるライセンスの定期更新処理のフローを説明する。管理部３０２から定期更新処理のスタートが命令されると、ライセンス更新処理部３０５は、Ｓ５１１〜Ｓ５１４の処理を実行する。ライセンス更新処理部３０５では、管理部３０２から定期更新処理のストップが命令されるまで、Ｓ５１２（ライセンス取得要求）とＳ５１３（ウェイト）における処理が、Ｓ５１１とＳ５１４のループ端の中で繰り返される。なお、Ｓ５１１およびＳ５１４のループ記号では、定期更新処理のストップが管理部３０２から指示されたかどうかを判断し、定期更新処理のストップが命令されたと判断した場合は、ループ処理から抜け出して定期更新処理を終了する。Ｓ５１２では、ライセンス要求送信部３０４がライセンスサーバ１２０と接続し、有効期間Ｔ２のライセンス取得要求（すなわちライセンスの更新要求）を行う。ライセンスが取得された場合は、当該取得したライセンスで上書きすることにより、ライセンスの有効期限が延びることになる。Ｓ５１３では、間隔Ｔ１にあたる時間ウェイトする。Ｓ５１２とＳ５１３の処理を繰り返し実行することにより、間隔Ｔ１毎に、有効期間Ｔ２のライセンス取得要求（ライセンス更新要求）を行うことになる。Ｓ５１１からＳ５１４の定期更新処理は、管理部３０２からのスタート命令で開始し、管理部３０２からのストップ命令で停止する。

Ｓ５２１にて、管理部３０２が、ライセンスの有効期限が切れているかどうか判断し、期限切れしている場合はＳ５２２へ、期限切れしていなければＳ５２３へ進む。このとき、ライセンスの定期更新処理（Ｓ５１１〜Ｓ５１４）によってライセンスの更新に成功している間は、ライセンスの有効期限が延びているので、Ｓ５２３に進むことになる。

Ｓ５２２において、管理部３０２は、ライセンスの失効時の処理（ライセンス失効処理）を実行する。ここで、管理部３０２は、ライセンス更新処理部３０５に命じて定期更新を終了させて、アプリケーション３００の機能を制限する。このとき、管理部３０２は、例えば、アプリケーションの終了を促すように、ユーザに期限切れのメッセージを表示する等の処理を行ってもよい。

次に、クライアント１１０のＯＳ上でアカウント環境の切り替えが発生した場合の処理について説明する。アカウント切り替えの発生有無、及びアクティブ化、非アクティブ化されたアカウントそれぞれの情報は、ＯＳからのイベント情報等で取得することができる。

Ｓ５２３において、管理部３０２は、当該アプリケーションを実行しているアカウントから、別ユーザのアカウントへアカウント環境の切り替えが発生したかを判断（検知）し、切り替えが発生した場合はＳ５２４へ、発生しなかった場合はＳ５２６へ進む。Ｓ５２４では、管理部３０２がライセンス更新処理部３０５に命じ、ライセンスの定期更新処理を停止する。なお、Ｓ５２５の処理は、後述する第２実施形態で説明するものであり、第１実施形態ではスキップする。

Ｓ５２６において、管理部３０２は、クライアントのＯＳ上で別ユーザのアカウントから当該アプリケーションを実行しているアカウントへアカウント環境の切り替えが発生したかを判断（検知）し、発生した場合はＳ５２７へ、発生しなかった場合はＳ５２１へ進む。Ｓ５２７では、ライセンスの定期更新処理（Ｓ５１１からＳ５１４の処理）を再スタートし、切り替え後のアカウント環境で実行されているアプリケーションをアクティブ化する。このとき、切り替え後のアカウント環境におけるデスクトップ画面もアクティブ化されることになる。

次に、図６の時系列図を用いて、アカウント環境切り替え時のライセンス処理の流れを説明する。

まず、ＵｓｅｒＡのアカウント上で、アプリケーションの起動が指示されると（時刻ｐ１）、アプリケーションはライセンスを要求し（Ｓ５０１）、有効期間Ｔ２のライセンスＬ１の取得に成功すると（Ｓ５０２）、アプリケーションを起動する（Ｓ５０４）。ここでライセンス定期更新処理が開始され（Ｓ５０５）、時刻ｐ２にて、ライセンス定期更新処理が実行されて、ライセンスＬ２を取得し（Ｓ５１２）、ライセンスＬ１をライセンスＬ２で更新する。

その後、定期更新時刻ｐ３よりも前に、ＵｓｅｒＢへのアカウントへの切り替えが発生した場合（Ｓ５２３：ＹＥＳ）、ＵｓｅｒＡのアカウント上で実行されているアプリケーションに対するライセンスの定期更新処理をストップする（Ｓ５２４）。

このあと、ライセンスＬ２の有効期限（ｐ２＋Ｔ２）に達するよりも前の時刻ｐ４において、再びＵｓｅｒＡへのアカウントへ切り替えが発生した場合（Ｓ５２６：ＹＥＳ）、ライセンス定期更新を再開し（Ｓ５２７）、ライセンスＬ４を取得（Ｓ５１２）してライセンス更新する。

一方、ＵｓｅｒＢへのアカウント切り替え後、ＵｓｅｒＡへのアカウント切り替えが発生しないまま、ライセンスＬ２の有効期限（ｐ２＋Ｔ２）に達した場合（Ｓ５２１）、ライセンス失効処理が実行される（Ｓ５２２）。

以上により、マルチアカウント機能を有するクライアントのＯＳにおいて、非アクティブになったアカウント環境で実行中のアプリケーションが長時間ライセンスを保持することを避けることができる。さらに、アカウント環境を切り換えた場合でも即時にライセンスを返却するのではなく、しばらくの間ライセンスを保持し続けるので、利用者がすぐに元のアカウント環境に戻して該アプリケーションでの作業を再開する場合には、すぐに作業を再開でき、利便性が向上する。

（実施例２）
実施例１では、アカウント切り替えのタイミングによってＵｓｅｒＡのライセンス失効までの猶予時間に少々バラつきがある。具体的には、アカウント切り替えが定期更新の直後（例えば、図６の時刻ｐ２の直後）であれば、失効まで期間Ｔ２（例：１０分）がほぼまるまる残っている。しかし、次の定期更新時刻の直前（例えば、図６の時刻ｐ３の直前）であれば、失効まで期間Ｔ２−間隔Ｔ１（例：１０分−３分＝７分）しか残っていない。Ｔ１やＴ２の時間設定によっては、ライセンスが失効するまでの猶予期間のバラつきが大きくなる。すなわち、アプリケーションのライセンスを失効せずにアカウント環境を元に戻せる猶予期間にバラつきが生じてしまう。

そこで、本実施例２では、アカウント切り替え時に定期更新をストップする時点で一度ライセンスを取得しておくことで、アカウント切り替えのタイミングが異なる場合でも、アプリケーションのライセンスを失効せずにアカウント環境を元に戻せる猶予期間が同じになるようにする。

以下、図５のフローチャート、及び図７の時系列図を用いて、実施例１との差異を説明する。なお、特に明示していない処理は実施例１と同様とする。

時刻ｐ１において、ＵｓｅｒＡアカウントにてアプリケーションの起動が指示されると、ライセンスを取得要求し（Ｓ５０１）、ライセンスＬ１の取得に成功すると（Ｓ５０２）、アプリケーションを起動する（Ｓ５０４）。時刻ｐ２にて、ライセンス定期更新処理が実行されて、ライセンスＬ２を取得し（Ｓ５１２）、ライセンスＬ１をライセンスＬ２で更新する。その後、定期更新時刻ｐ３よりも前の時刻ｐ２’において、ＵｓｅｒＢへのアカウント切り替えが発生した場合（Ｓ５２３：ＹＥＳ）、ＵｓｅｒＡのアカウント上で実行されているアプリケーションに対する定期更新処理をストップする（Ｓ５２４）。この時点、実施例２では、更に、Ｓ５２５にて、期間Ｔ２のライセンスの取得要求を行う。図７では、時間ｐ２’にて、ライセンスＬ３の取得要求を行う（Ｓ５２５）。ここでライセンスＬ３の取得に成功すると、ＵｓｅｒＢへのアカウント切り替え時点からライセンスＬ３が失効するまでの残り時間（猶予期間）は、期間Ｔ２となる。

以上により、ユーザは、ライセンス定期更新実行中のどのタイミングでアカウント切り替えを行ったとしても、一定期間Ｔ２の間はライセンスが有効であることが保証される。したがって、実施例２によれば、アプリケーションのライセンスを失効せずにアカウント環境を元に戻せる猶予期間にバラつきが生じなくなる。

（実施例３）
実施例２では、ライセンスを失効せずにアカウント環境を元に戻せる猶予期間は、期間Ｔ２（例：１０分）であった。一方で、期間Ｔ２はもともと、ネットワーク切断やスリープに入った状態から復帰するまでの猶予期間として設定されたものであり、アカウント切り替えとしては短すぎる場合がある。例えば、ユーザＡが３０分間離席している間だけ、他のユーザＢにクライアントＰＣの利用を譲り、その後、ユーザＡが戻ってきたときにすぐに該当アプリケーションでの作業を続けたい場合などは、有効期限が１０分では不足である。

そこで、本実施例３では、アカウント切り替え用の猶予期間Ｔ３（Ｔ２より長時間、例えば３０分）を設ける。なお、ここではライセンスの有効期間Ｔ３はシステム固有値であり、ライセンス要求時に有効期間を変更できない場合の例を示す。

以下、図８の時系列図、および、図９と図５のフローチャートを用いて、実施例２との差異を説明する。図９は、図５のＳ５２１以降のステップを置き換えるものである。なお、特に明示していない処理は、実施例１と同じものとする。

時刻ｐ１において、ＵｓｅｒＡアカウントにてアプリケーションの起動が指示されると、ライセンスを取得要求し（Ｓ５０１）、ライセンスＬ１の取得に成功すると（Ｓ５０２）、アプリケーションを起動する（Ｓ５０４）。時刻ｐ２にて、ライセンス定期更新処理が実行されて、ライセンスＬ２を取得し（Ｓ５１２）、ライセンスＬ１をライセンスＬ２で更新する。その後、定期更新時刻ｐ３よりも前の時刻ｐ２’において、ＵｓｅｒＢへアカウント切り替えが発生した場合（Ｓ５２３：ＹＥＳ）、図９のＳ７０１にて、タイマーをスタートする。タイマーの時間Ｔ３ａには、Ｔ３−Ｔ２をセットする。期間Ｔ３ａと期間Ｔ２を足すと期間Ｔ３となる。

Ｓ５２６にて、別のＵｓｅｒＢのアカウントからＵｓｅｒＡのアカウントへアカウント切り替えが発生したかを判断し、発生した場合はＳ７０２へ、発生しなかった場合はＳ７０４へ進む。Ｓ７０２ではライセンスの定期更新処理をリセットし、続くＳ７０３でタイマーＴ３ａをストップする。

Ｓ７０４では、タイマーＴ３ａの時間が経過したかを判断し、経過した場合はＳ７０５へ、まだ経過していない場合はＳ５２１へ進む。Ｓ７０５では、ライセンスの定期更新処理をストップし、Ｓ７０６でライセンス取得要求を行って有効期間Ｔ２のライセンスＬ５を取得する。すなわち、アカウントが切り替えられた場合、Ｓ７０４〜Ｓ７０６の処理により、所定時間経過後（タイマーＴ３ａ経過後）に、ライセンスの更新を行うとともに、ライセンスの定期的な更新を停止することになる。

図８では、時刻ｐ２’でＵｓｅｒＢへのアカウント切り替えが発生すると、タイマーＴ３ａを開始する（Ｓ７０１）。タイマーＴ３ａが経過するまでは、ライセンスの定期更新処理（Ｓ５１１−Ｓ５１４）は続けられ、アプリケーションはライセンスを保持する。

その後、ＵｓｅｒＡへのアカウント切り替えが発生しないまま、タイマーＴ３ａの時間が経過したと判断した時点（時刻ｐ５）で（Ｓ７０４：ＹＥＳ）、ライセンスの定期更新処理をストップし（Ｓ７０５）、ライセンス取得要求を行う（Ｓ７０６）。ここでライセンスＬ５の取得に成功すると、時刻ｐ５からライセンスが失効するまでの時間は期間Ｔ２となり、ＵｓｅｒＢへのアカウント切り替え時点（時刻ｐ２’）から、ＵｓｅｒＡのアカウントで実行されているアプリケーションがライセンス失効するまでの時間は期間Ｔ３となる。

また、ＵｓｅｒＢからＵｓｅｒＡへアカウント切り替えが、タイマーＴ３ａ動作中に発生した場合、タイマーＴ３ａのストップ（Ｓ７０３）を行う。なお、定期更新処理は動作中であるが、定期更新処理のリセット（Ｓ７０２）を要求しても問題ない。ＵｓｅｒＢからＵｓｅｒＡへアカウント切り替えが、タイマーＴ３ａ終了後に発生した場合、定期更新処理を再スタートする（Ｓ７０２）。なお、タイマーは終了しているが、タイマー終了処理（Ｓ７０３）を要求しても問題はない。いずれにしても、時刻（ｐ２’＋Ｔ３）になるよりも前に、ＵｓｅｒＢからＵｓｅｒＡへアカウント切り替えが行われた場合は、ＵｓｅｒＡのアカウントで実行中のアプリケーションはライセンスＬ６に更新するので、ライセンス失効せずにＵｓｅｒＡは処理を継続できる。

以上により、アカウント切り替え用の猶予期間として、ネットワーク切断やスリープ用の猶予期間として設定されているシステム固定の期間Ｔ２よりも長い時間Ｔ３を設定でき、利便性が向上する。

なお、ライセンスシステムにおいて、ライセンスの有効期間がＴ２固定ではなく、もしライセンス取得要求時に変更可能であるならば、以下の処理フローでも良い。

すなわち、実施例２において、時間ｐ２’のアカウント切り替え時に、有効期間Ｔ２のライセンスを要求する代わりに、有効期間Ｔ３のライセンスを要求する、というように処理を変更すればよい。具体的には、図５のＳ５２５で行っている期間Ｔ２のライセンス要求を、図１０のＳ７１１のように変更する。

以上により、タイマーを使わなくても、ＵｓｅｒＢへのアカウント切り替えからライセンスの失効までの時間として、期間Ｔ３を保証することが可能となる。

また、期間Ｔ３は、ユーザの指示に基づき、設定変更できるようにしてもよい。設定変更できれば、ユーザ毎にアカウント切り替え時の猶予期間を切り替えることが可能となり、更に利便性が向上する。

（実施例４）
本発明は、アカウント切り替え時だけでなく、スクリーンセーバーやパスワード保護画面への移行や復帰に対して適用しても良い。

実施例１〜３では、アカウント切り替えを契機に特定のユーザ環境が非アクティブ化した場合の処理について説明した。一方、スクリーンセーバーやパスワード保護画面への移行が発生した場合も、ユーザ環境は非アクティブ化し、アプリケーションのユーザ操作はできなくなる。そこで、実施例４では、実施例１〜３のアカウント切り替えの検知の代わりに、スクリーンセーバーやパスワード保護画面モードへの移行、及び同モードからの復帰を検知するのに応じて同様の処理を行っても良い。

具体的には、Ｓ５２３にて、スクリーンセーバーやパスワード保護画面への移行によってアカウント環境が非アクティブ化されたかどうかを判断する。また、Ｓ５２６にて、スクリーンセーバーやパスワード保護画面から復帰し、アカウント環境がアクティブ化されたかどうかを判断する。以上により、スクリーンセーバーやパスワード保護画面への移行時も、アカウント切り替えの場合と同様に、ライセンスの効率的な管理を行うことができる。

（実施例５）
本発明は、スリープやハイバネーションへの状態移行に対して適用しても良い。

クライアントのシステムが、スリープやハイバネーションの状態に入ると、それ以降はライセンスの自動更新処理は停止する。ここで、最後のライセンス取得のタイミングに依存して、スリープやハイバネーションの時点からライセンスが失効するまでの猶予時間が異なる。これは実施例２と同様に、猶予期間にバラつきが生じる原因となる。

そこで、アプリケーションは、スリープやハイバネーションへの状態移行を検知した時点で一度ライセンスを取得しておく。以上により、一定期間の猶予期間Ｔ２（またはＴ３）を確保することができる。

（実施例６）
また、本発明は、ライセンスのスコープがクライアント単位であってもユーザ単位であっても適用可能である。クライアント単位のライセンスとは、そのクライアント上にひとつ存在すればすべてのユーザアカウントからアプリケーションの起動が可能となるものである。また、ユーザ単位のライセンスとは、ユーザ毎に必要なライセンスであり、ひとつのクライアントに複数のユーザアカウントが存在する場合はそれぞれライセンスが必要となるものである。

また、本発明は、自動更新処理が、ユーザプロセスで動くものであってもシステムプロセスで動くものであっても適用可能である。一般にアプリケーションの一部として動く場合はユーザプロセスであることが多い。しかし、同一クライアント上の異なるユーザアカウントから共通で利用したい処理の場合には、アプリケーションから実行ファイルとして分離し、システムプロセス（サービス）として動作させることもできる。その場合でも、本発明の適用は可能である。

なお、ライセンススコープがクライアント単位であり、自動更新処理がシステムプロセスの場合、クライアント内の複数のユーザが同じアプリケーションを使う際は単一のライセンスをユーザ間で共有することができて便利である。しかし、以下の問題がある。

ＵｓｅｒＡがアプリケーションの実行とライセンスの取得を行い、期間Ｔ２（またはＴ３）の猶予期間を期待してＵｓｅｒＢにアカウント変更したとする。ＵｓｅｒＢがすぐに同じアプリケーションを起動した場合、ＵｓｅｒＡが取得したライセンスを継続使用することができる。この後、ＵｓｅｒＢがアプリケーションを短時間で終了したときにライセンスを返却してしまうと、アカウント環境をＵｓｅｒＡに戻した場合、ＵｓｅｒＡが期待していた猶予期間Ｔ２（またはＴ３）が経過する前に作業を再開したとしても、ＵｓｅｒＢの操作によりライセンスが既に返却されてしまっていることになる。これは、ＵｓｅｒＡにとっては不便である。

そこで、実施例６では、各アプリケーション３００は、起動時にライセンスを既に取得済みかを確認し、既に取得済みの場合はその有効期限を取得しておき、前記有効期限前にアプリケーションが別のＵｓｅｒＢにより終了されたときは、前記有効期限まではライセンスを返却しないように制御する。

以上により、ＵｓｅｒＢがアプリケーションを終了しても、ＵｓｅｒＡが作業を再開したときに、期待する猶予期間中はライセンスが保持することができ、利便性を向上する。

Claims (12)

1. アプリケーションを起動する際にライセンスサーバからライセンスを取得するクライアントであって、
   前記ライセンスサーバから、有効期間を有するライセンスを取得する取得手段と、
   定期的に、前記取得したライセンスを更新する更新手段と、
   前記アプリケーションを実行している環境が非アクティブになったか判断する第１の判断手段と、
   前記第１の判断手段で前記環境が非アクティブになったと判断した場合、前記更新手段による前記ライセンスの定期的な更新を停止する停止手段と、
   前記アプリケーションを実行している環境がアクティブになったか判断する第２の判断手段と、
   前記第２の判断手段で前記環境がアクティブになったと判断した場合、前記更新手段による前記ライセンスの定期的な更新を再開する再開手段と、
   前記ライセンスの有効期間が切れた場合、前記アプリケーションに対するライセンス失効処理を実行する失効処理手段と、
   を有することを特徴とするクライアント。
2. 前記クライアントは、アカウント環境切り替え機能を有するクライアントであって、
   前記第１の判断手段は、前記アプリケーションを実行しているアカウント環境が別のアカウント環境に切り替えられた場合に、前記アプリケーションを実行している環境が非アクティブになったと判断し、
   前記第２の判断手段は、前記別のアカウント環境から前記アプリケーションを実行しているアカウント環境に切り替えられた場合に、前記アプリケーションを実行している環境がアクティブになったと判断することを特徴とする請求項１に記載のクライアント。
3. 前記停止手段は、前記第１の判断手段で前記環境が非アクティブになったと判断した場合、ライセンスの更新を実行するとともに、前記更新手段による前記ライセンスの定期的な更新を停止することを特徴とする請求項１に記載のクライアント。
4. 前記停止手段は、前記第１の判断手段で前記環境が非アクティブになったと判断した場合、所定のタイマー時間経過後に、ライセンスの更新を実行するとともに、前記更新手段による前記ライセンスの定期的な更新を停止することを特徴とする請求項１に記載のクライアント。
5. 前記停止手段は、前記第１の判断手段で前記環境が非アクティブになったと判断した場合、前記ライセンスの更新を実行して第２の有効期間を有するライセンスを取得するとともに、前記更新手段による前記ライセンスの定期的な更新を停止することを特徴とする請求項１に記載のクライアント。
6. 前記第１の判断手段は、前記アプリケーションを実行している環境がスクリーンセーバーまたはパスワード保護画面に移行した場合に、前記アプリケーションを実行している環境が非アクティブになったと判断し、
   前記第２の判断手段は、前記スクリーンセーバーまたはパスワード保護画面から復帰した場合に、前記アプリケーションを実行している環境がアクティブになったと判断することを特徴とする請求項１に記載のクライアント。
7. 前記第１の判断手段は、前記アプリケーションを実行している環境がスリープまたは幅ネーションの状態に移行した場合に、前記アプリケーションを実行している環境が非アクティブになったと判断することを特徴とする請求項１に記載のクライアント。
8. 前記ライセンスは、クライアント単位で取得されるライセンスであり、
   前記クライアントは、前記切り替えられた別のアカウント環境において、前記アプリケーションの終了が指示された場合、前記ライセンスの有効期間が切れるまでは返却しないように制御する制御手段を更に有することを特徴とする請求項２に記載のクライアント。
9. 前記取得手段で前記ライセンスサーバからライセンスを取得できなかった場合、前記アプリケーションを起動しないように制御する第２の制御手段を、更に有することを特徴とする請求項１乃至８のいずれか１項に記載のクライアント。
10. コンピュータを、請求項１乃至９のいずれか１項に記載のクライアントの各手段として機能させるためのコンピュータプログラム。
11. アプリケーションを起動する際にライセンスサーバからライセンスを取得するクライアントが実行するライセンス管理方法であって、
    前記クライアントの取得手段が、前記ライセンスサーバから、有効期間を有するライセンスを取得する取得ステップと、
    前記クライアントの更新手段が、定期的に、前記取得したライセンスを更新する更新ステップと、
    前記クライアントの第１の判断手段が、前記アプリケーションを実行している環境が非アクティブになったか判断する第１の判断ステップと、
    前記クライアントの停止手段が、前記第１の判断ステップで前記環境が非アクティブになったと判断した場合、前記更新ステップによる前記ライセンスの定期的な更新を停止する停止ステップと、
    前記クライアントの第２の判断手段が、前記アプリケーションを実行している環境がアクティブになったか判断する第２の判断ステップと、
    前記クライアントの再開手段が、前記第２の判断ステップで前記環境がアクティブになったと判断した場合、前記更新ステップによる前記ライセンスの定期的な更新を再開する再開手段と、
    前記クライアントの失効処理手段が、前記ライセンスの有効期間が切れた場合、前記アプリケーションに対するライセンス失効処理を実行する失効処理ステップと、
    を有することを特徴とするライセンス管理方法。
12. ライセンスサーバと、アプリケーションを起動する際にライセンスサーバからライセンスを取得するクライアントとを含むライセンス管理システムであって、
    前記クライアントは、
    前記ライセンスサーバから、有効期間を有するライセンスを取得する取得手段と、
    定期的に、前記取得したライセンスを更新する更新手段と、
    前記アプリケーションを実行している環境が非アクティブになったか判断する第１の判断手段と、
    前記第１の判断手段で前記環境が非アクティブになったと判断した場合、前記更新手段による前記ライセンスの定期的な更新を停止する停止手段と、
    前記アプリケーションを実行している環境がアクティブになったか判断する第２の判断手段と、
    前記第２の判断手段で前記環境がアクティブになったと判断した場合、前記更新手段による前記ライセンスの定期的な更新を再開する再開手段と、
    前記ライセンスの有効期間が切れた場合、前記アプリケーションに対するライセンス失効処理を実行する失効処理手段と、
    を有することを特徴とするライセンス管理システム。

Images