JP6700815B2 - ライセンス管理システム、クライアント装置、アプリケーションプログラム - Google Patents

Description

本発明は、ライセンス管理システムに関する。

クライアントに有償アプリケーションの使用許諾をする方法として、フローティング方式がある。フローティング方式とは、予め一定数のライセンス（同時利用可能な数のライセンス）をプールしているローカルライセンスサーバがクライアントに一時的にライセンスを貸し出すことにより、クライアントが一時的にアプリケーションを使用可能にする方式である。フローティング方式で管理されるフローティングライセンスは、各クライアントで該当するアプリケーションの使用が終わればローカルライセンスサーバに返却されるため、他のクライアントが当該返却されたライセンスを取得することにより、同じアプリケーションを別のクライアント上で使用することができる。このようなフローティングライセンスを用いて、各クライアントがアプリケーションを使用する時間帯をずらせば、プールしているライセンス数以上の複数のクライアント上で当該アプリケーションを利用することが可能となる。フローティングライセンスは、作業中は途切れずに保持し、作業後は速やかに返却することが望ましい。そのため、アプリケーション起動時にライセンスを取得し、終了時（プロセス終了時）に返却するという使い方が一般的である。

特許文献１では、クライアントアプリケーションの起動要求があると、クライアント側の使用権管理部がライセンスサーバと通信する。ライセンスサーバは該当ソフトウェアの使用者数がライセンス数に満たなければ使用を許可し、使用権管理部は使用が許可されたらアプリケーションを実行する。なお、特許文献１では、クライアント内に複数のクライアントアプリケーションが存在する場合、使用権管理部は、各アプリケーションをアプリケーションＩＤで区別し、アプリケーションＩＤごとに設けられた利用カウンタを用いてライセンス数に達しているかを判断している。

特許文献１では、複数のアプリケーションが存在する場合は、アプリケーションごとに異なるライセンスで管理している。したがって、ライセンスの利用状況（すなわち、各アプリケーションを利用しているクライアントの数がライセンス数上限に達しているか否か）によって、使えるアプリケーションと使えないアプリケーションがあり得る。

特開平０７−２００４９２号公報

一方、複数のアプリケーションが互いに連携するようなスイート製品では、アプリケーション群すべてを利用可能にする必要がある。しかしながら、特許文献１の技術は、複数のアプリケーションをアプリケーションＩＤごとに個別に管理して個別にライセンスを取得するので、利用状況によっては、アプリケーション群すべてを使用できない場合があり、複数のアプリケーションが互いに連携するような製品には適さない。

そこで、本出願人は、各アプリケーションとは独立したプロセスで実行される使用権管理部をクライアント内に設け、使用権管理部が１つのライセンスをライセンスサーバから取得することで、関連する複数のアプリケーションを利用できるようにすることを考えている。

１つのライセンスで複数のアプリケーションを管理すること、１つの使用権管理部（ライセンス管理アプリケーション）が取得したライセンスを管理すること、使用権管理部が複数のアプリケーションのプロセスとは独立したプロセスで動作すること、が望ましいのは、以下の理由（１）〜（３）による。

（１）スイート製品である複数のアプリケーションそれぞれに対して異なるライセンスで管理する構成よりも、１つのライセンスで複数のアプリケーションを管理する構成の方が、簡易な構成にしやすい。

（２）使用権管理部を設けずに、各アプリケーションがそれぞれライセンスの取得／返却を行うようにすると、クライアント・サーバ間のトラフィックが増大してしまうため望ましくない。また、使用権管理部を設けずに、最初に起動したアプリケーションがサーバからライセンスを取得し、他のアプリケーションは該最初に起動したアプリケーションと連携することで、使用権管理を行う方法も考えられる。しかし、この場合、他のアプリケーションと該最初に起動したアプリケーションとの間でプロセス間通信が発生してパフォーマンスに悪影響があると共に、該最初に起動したアプリケーションを終了した後のライセンスの移管処理等が複雑になる。よって、ライセンスの取得／返却は、使用権管理部が一元管理することが現実的である。

（３）フローティングライセンスは、アプリケーションが起動している間だけ消費されるという性質上、ファイルではなく、メモリ上で管理されるケースが多い。これは、頻繁に発生する更新処理を短時間で行えること、アプリケーションがクラッシュした時に自動的に失効できること、等の理由による。したがって、使用権管理部は、各アプリケーションの一部として動作するのではなく、各アプリケーションのプロセスとは独立したプロセスで動作する方が望ましい。

以上の理由により、独立したプロセスで実行される使用権管理部がライセンスの取得／返却を行い、各アプリケーションは起動時／終了時に使用権管理部と連携することが考えられる。

しかし、使用権管理部が起動していないとき（すなわちライセンス未取得時）にいずれかのアプリケーションを起動する場合、該アプリケーションは、まず、別プロセスである使用権管理部を起動させ、その後、該使用権管理部を介してライセンス取得を行うことになる。この場合、アプリケーション自身がライセンスサーバと直接通信してライセンスを取得する場合と比べて、使用権管理部の起動や、該アプリケーションと使用権管理部との間のプロセス間通信などが発生するため、起動時のレスポンスが悪くなってしまう。特に、起動と終了が頻繁に発生するアプリケーション（例えば、ファイルがアイコンにドラッグ＆ドロップされることに応じて起動し、所定の処理を実行後に自動終了するガジェットアプリケーション）では、パフォーマンスの悪影響は顕著となり、ユーザの利便性を低下させる。

上記課題を解決するために、本発明のライセンス管理システムは、ライセンスサーバと、複数のアプリケーション、および前記複数のアプリケーションを起動するためのライセンスを前記ライセンスサーバから取得するライセンス管理部を有するクライアント装置と、を含むライセンス管理システムであって、前記複数のアプリケーションのうちの一つのアプリケーションが、前記アプリケーションを起動するための第一の起動要求を受け付けた場合に、前記ライセンス管理部が前記ライセンスを取得済みか判断する第１の判断手段と、前記第１の判断手段によって前記ライセンス管理部が前記ライセンスを取得済みではないと判断された場合、前記ライセンスサーバから前記ライセンスを取得する第１のライセンス要求手段と、前記第１の判断手段によって前記ライセンス管理部が前記ライセンスを取得済みであると判断された場合、前記アプリケーションをユーザが使用可能な状態にする処理実行手段と、前記処理実行手段によって前記アプリケーションが使用可能な状態に変更された後、前記ライセンス管理部が起動中でなければ、前記ライセンス管理部を起動させる起動手段と、を有することを特徴とする。

本システムでは、アプリケーションを起動する際に、ライセンス管理部がライセンスを取得済みでなければ、該アプリケーション自身がライセンスサーバからライセンスを取得し、該アプリケーションを使用可能状態にする。このように構成することにより、アプリケーションがライセンス管理部を起動して、ライセンス管理部が起動後にライセンスサーバから取得したライセンスをアプリケーションに返し、その後アプリケーションが起動する方法と比べて、使用可能になるまでの時間を短縮できる。すなわち、最初のアプリケーションを起動する際の時間を高速化することができ、ユーザの利便性が向上する。

システム構成例 クライアントおよびサーバにおけるハードウェア構成例 クライアントおよびサーバにおけるソフトウェア構成例 アプリケーション起動時の処理フロー アプリケーション終了時の処理フロー アプリケーション起動時のタイムチャート例 アプリケーション終了時のタイムチャート例 アプリケーションクラッシュ時のタイムチャート例 実施例２のアプリケーション終了時のタイムチャート例

（実施例１）
図１は、本発明の一実施形態におけるフローティングライセンス管理システムの構成を示す図である。本実施形態は、ライセンスサーバと複数のクライアント（クライアント装置）がネットワークを介して通信可能なシステムである。

ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１００は、クライアント１１０及び１１１と、ライセンスサーバ１２０とを通信可能とするネットワークである。なお、このネットワークは、ＬＡＮに限るものではなく、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）であっても構わない。

クライアント１１０（及び１１１）には、アプリケーション３００がインストールされている。アプリケーション３００は、ライセンスを用いて使用許諾を受けることによって、当該アプリケーションの機能の一部または全体にかかっている使用制限が解除されて利用可能となる。

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

なお、フローティングライセンス（以下、単にライセンス）とは、ライセンスサーバ１２０が、ライセンスを要求するクライアントに対して一時的に貸与するものである。各クライアントでは、アプリケーション３００を利用する際に、ライセンスサーバ１２０からライセンスを借りることで、当該アプリケーション３００を利用することができる。当該アプリケーションの利用が終われば、前記ライセンスをライセンスサーバに返却することで、使用する時間帯をずらせば、他のクライアントでも、同じライセンスで同じアプリケーションの利用が可能となる。なお、ラインセンスサーバ１２０が発行するライセンスとは、ファイル形式であっても良いし、バイナリデータや使用許諾フラグのようなものであっても良い。どのような方法であっても、ライセンスサーバとクライアントとの間で、使用許諾をセキュアに取り扱えるものであれば構わない。以後、媒体や手段に関わらず、クライアントがライセンスサーバから使用許諾を得ることをライセンス取得、逆に使用許諾を返却することをライセンス返却と呼ぶ。

本実施形態では、クライアント１１０にインストールされたアプリケーション３００が、ライセンスサーバ１２０から取得したフローティングライセンスによって動作する例を示す。

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

なお、本実施例で説明される処理は、ＲＯＭ２０４、または外部メモリ２０６に保存されたプログラムをＲＡＭ２０３にロードし、ＣＰＵ２０１で実行することによって実現される。

＜ソフトウェア構成例＞
図３は、クライアント１１０（または１１１）と、ライセンスサーバ１２０のソフトウェア構成の一例を示す図である。

クライアント１１０のＣＰＵは、アプリケーション（アプリケーションプログラム）３００を実行することにより、入力部３０１、管理部３０２、処理実行部３０３、ライセンス要求送信部３０４、ライセンス有無確認部３０５、ライセンス管理部状態確認部３０６、アプリケーション状態確認部３０７、として機能する。

入力部３０１は、ユーザからの操作を受け付け、入力された要求を管理部３０２に伝える。入力部３０１で当該アプリケーション３００の起動要求を受け付けた場合、管理部３０２はアプリケーション３００を利用するためのライセンスが必要になったと判断して、ライセンス有無確認部３０５に命じて、該クライアント１１０のライセンス管理部３２０がライセンスを取得済みかどうか（すなわち、クライアント１１０内にライセンスが有るか無いか）を確認する。ライセンス取得済みかどうかの判断は、後述するように「ライセンスフラグ」の状態を確認することにより行われる。ライセンス取得済であると判断した場合は、アプリケーション３００を実行可能状態（ユーザが該アプリケーションを使用可能な状態）にし、ライセンス未取得の場合は、ライセンス要求送信部３０４にライセンスの取得を命ずる。

ライセンス要求送信部３０４は、ライセンスサーバ１２０に直接接続して、ライセンスの取得要求を行う。このとき、クライアントを一意に識別することが可能なクライアント識別子を合わせて送る。クライアント識別子には、Ｍａｃアドレスやハードウェアパーツのシリアル番号、あるいはそれらの組合せで作られた計算値などが利用可能である。ライセンスサーバ１２０の詳細は後述するが、通常は利用可能なライセンスが残っていればライセンス取得は成功する。ここでは、有効期間Ｔ２（例えば１０分）のライセンスが得られるものとする。アプリケーション３００が取得したライセンスは、アプリケーション３００が使用するメモリ空間に格納される。ライセンス要求送信部３０４は、ライセンス取得の成否と、成功の場合は有効期限とを、管理部３０２に伝える。管理部３０２は、ライセンス取得に成功した場合は、アプリケーション３００を実行可能状態（ユーザがアプリケーションを使用可能な状態）にするべく、処理実行部３０３に命ずる。処理実行部３０３は、アプリケーションを実行可能状態にして、入力部３０１を介してユーザからの作業指示を受け付け可能にする。管理部３０２は、入力部３０１から指示された機能の実行や操作画面での処理（ドキュメント編集や印刷等）の要求を受けると、同様に処理実行部３０３に、その要求内容の実行を命令する。なお、ライセンス要求送信部３０４でライセンス取得に失敗した場合、管理部３０２は、アプリケーションの起動要求は実行しないように制御する。この場合、操作しているユーザに対してメッセージ等で通知してもよい。

ここで、管理部３０２は、アプリケーションの起動に成功したら、自身のアプリケーション３００が起動中であることを、関連する他のアプリケーション（例えばオフィススイート製品を構成する他のアプリケーション）から識別可能となるようにする。例えば、プロセス間通信の共有資源に、当該アプリケーションが起動中を示すフラグを保存する、などの方法が考えられる。フラグの保存方法を限定するものではないが、以後は便宜上、起動中のアプリケーションの有無を、フラグのＯｎ／Ｏｆｆで表現する。すなわち、自身のアプリケーションが起動中である状態を「アプリケーションフラグがＯｎ」とし、非起動中である状態を「アプリケーションフラグがＯｆｆ」とし、他のアプリケーションから識別可能とする。また、アプリケーションフラグは、複数のアプリケーションそれぞれに対して個別に存在するものとする。アプリケーションフラグを確認する処理部は、予め確認対象となるすべてのアプリケーションのフラグの保存位置を知っておき、必要に応じて、それらを区別してチェックすることが可能であるものとする。

管理部３０２は、アプリケーション３００の起動に成功した場合、さらに、ライセンス更新を継続するために、ライセンス管理部状態確認部３０６に命じ、ライセンス管理部３２０の起動状態を確認する。ライセンス管理部３２０の起動状態の判断は、後述するように「ライセンス管理部フラグ」の状態を確認する。「ライセンス管理部フラグ」が起動済であった場合は、これでアプリケーション３００でのライセンス取得処理は終了する。確認結果が未起動であった場合は、ライセンス管理部３２０に対して起動を要求する。

次にアプリケーション３００の終了について説明する。入力部３０１でアプリケーションの終了要求を受けた場合、管理部３０２は、アプリケーション３００を終了する前に、ライセンス返却が必要かどうかの判断を行う。管理部３０２は、アプリケーション状態確認部３０７に命じ、アプリケーション３００自身以外に起動中の、スイート製品を構成する他のアプリケーションがあるかどうか判断する。起動しているアプリケーションの有無の判断は、前述したように「アプリケーションフラグ」の状態を確認する。

アプリケーション状態確認部３０７の判断で、起動中の他のアプリケーションが存在した場合、まだ当該スイート製品に対するライセンスは該クライアントに必要となるので、ライセンス返却をせずにアプリケーション３００自身を終了させる。この時、自身のアプリケーションが非起動になったことを他のアプリケーションから識別可能となるように、アプリケーション３００のアプリケーションフラグをＯｆｆにする。アプリケーション状態確認部３０７の判断で、起動中のアプリケーションが存在しなかった場合、当該クライアントにライセンスは不要となるので、ライセンスをサーバに返却するようにライセンス管理部３２０に指示してアプリケーション３００自身を終了させる。ここで、ライセンスを返却するために、管理部３０２は、ライセンス管理部３２０に対して終了要求を行う。また、前述の場合と同様にアプリケーション３００のアプリケーションフラグをＯｆｆにする。

次に、クライアント１１０上で実現されるライセンス管理部３２０の説明を行う。クライアント１１０のＣＰＵは、ライセンス管理部３２０を実現するためのプログラムを実行することにより、要求受信部３２１、管理部３２２、ライセンス要求送信部３２３、アプリケーション状態確認部３２４、として機能する。

アプリケーション３００がライセンス管理部３２０の起動要求を行うと、要求受信部３２１は起動要求を受け付け、起動要求を管理部３２２に伝える。管理部３２２は、ライセンス管理部３２０を起動させると、ライセンス管理部３２０が起動中であることを各アプリケーションから識別可能となるようにする。例えば、ライセンス管理部３２０が起動中であることを示すフラグを保存する方法が考えられる。なお、プロセス間通信の共有資源の機構を利用して起動済を示すフラグを保存してもよいし、ライセンス管理部３２０への問合せインターフェースを設けてフラグを確認できるようにしてもよく、起動状態の確認方法は限定するものではない。以後は便宜上、いずれの方法であっても、ライセンス管理部３２０が起動済である状態を「ライセンス管理部フラグがＯｎ」、非起動である状態を「ライセンス管理部フラグがＯｆｆ」とし、アプリケーション３００の管理部３０２は、その状態を識別可能であるものとする。

ライセンス管理部３２０の管理部３２２は、所定時間間隔Ｔ１毎（例えば３分毎）に、アプリケーション状態確認部３２４に命じ、起動しているアプリケーションがあるかどうか確認する。起動しているアプリケーションの有無の判断は、前述したように「アプリケーションフラグ」の状態を確認する。アプリケーション状態確認部３２４にて、起動中のアプリケーションがあると判断した場合、管理部３２２は、ライセンスの有効期間を延長するために、ライセンス要求送信部３２３に対してライセンスの更新を命ずる。アプリケーション状態確認部３２４が起動中のアプリケーションは無いと判断した場合、管理部３２２はライセンスの継続は不要と判断し、ライセンス要求送信部３２３に命じてライセンスの返却を行う。また、続けて管理部３２２はライセンス管理部３２０を終了する。

ライセンス要求送信部３２３は、ライセンス更新命令を受けると、ライセンスサーバ１２０に接続し、ライセンスの更新を要求する。このとき、クライアントを一意に識別することが可能なクライアント識別子を合わせて送る。ライセンスサーバ１２０については後述するが、使用許諾中のクライアントからの要求であれば、通常は更新に成功する。ここでは、ライセンス要求送信部３２３は、有効期間Ｔ２時間（例：１０分間）の更新ライセンスを取得する。取得したライセンスは、ライセンス管理部３２０が使用するメモリ空間に格納される。２回目以降は、既存のライセンスは新しいライセンスで上書きされる。この処理を、ライセンスの更新と呼ぶ。ライセンス更新に成功している限り、ライセンスの効力は継続される。

なお、アプリケーション３００が最初に取得したライセンスが有効な間は、アプリケーション３００とライセンス管理部３２０で２つのライセンスを重複管理しているように見えるが、これは問題にならない。第一に、後述するように、ライセンスサーバ１２０は、同一クライアントからのライセンス取得要求に対しては、その更新ライセンスを返信する。格納場所は異なるものの、ライセンス管理部３２０が保持するライセンスは、アプリケーション３００が保持するライセンスの更新ライセンスとなるため、ライセンスを余計に消費することはない。第二に、アプリケーション３００が保持するライセンスは、最初のアプリケーション起動の許諾にのみ利用され、それ以外のアプリケーションの使用許諾に利用されることはない。また、アプリケーション３００が保持するライセンスは更新されず、一定時間（取得後Ｔ２経過）後に失効するため、以後はライセンス管理部３２０が保持するライセンスのみとなり、重複も解消される。

なお、ライセンス要求送信部３２３が、ライセンスサーバ１２０との接続に失敗した場合、または、ライセンスサーバ１２０からのライセンス取得に失敗した場合、ライセンスの取得や更新は行われない。例えば、クライアントがネットワークから切り離された場合や、ライセンスサーバ１２０がダウンした場合などに失敗する。

ライセンス要求送信部３２３は、ライセンス取得の成否と、成功の場合は有効期限を、管理部３２２に伝える。ここで管理部３２２は、ライセンス取得に成功した場合は、ライセンスを取得済であることを各アプリケーションから識別可能となるようにする。ライセンスを取得済であることを各アプリケーションから識別可能にする方法は、様々な方法が考えられるが、ここでは方法を限定するものではない。例えば、ライセンス管理部３２０への問合せインターフェースを設ける、プロセス間通信の共有資源の機構を利用してライセンス取得済を示す、などの方法が考えられる。以後は便宜上、いずれの方法であっても、ライセンス管理部３２０がライセンスを取得済である状態を「ライセンスフラグがＯｎ」、非取得である状態を「ライセンスフラグがＯｆｆ」とし、その状態を識別可能であるものとする。

ライセンス要求送信部３２３でのライセンス取得で失敗が続き、その結果、管理部３２２でライセンスの有効期限に達したと判断した場合（ライセンスを最後に取得してから時間Ｔ２が経過した場合）、取得していたライセンスは権利を失効する。この時、管理部３２２は、何らかの期限切れ処理を行っても良い。例えば、アプリケーション終了を促す、ユーザに期限切れのメッセージを表示する、定期更新を停止する、等の対応を行うことができる。また、管理部３２２は何もしないことで、起動中のアプリケーションに限って当該アプリケーションを終了するまで利用可能にするようにしても構わない。なお、ライセンス要求送信部３２３でのライセンス取得は、何度か失敗したとしても、再取得できればライセンスの効力は維持される。

次に、ライセンス管理部３２０の終了処理について説明する。要求受信部３２１が終了要求を受けた場合、管理部３２２はライセンスを返却してから、ライセンス管理部３２０自身を終了する。この際、管理部３２２は、合わせてライセンスフラグをＯｆｆにし、さらに、ライセンス管理部フラグをＯｆｆにする。

次に、ライセンスサーバ１２０についての説明を行う。ライセンスサーバ１２０のＣＰＵは、サーバプログラムを実行することにより、ライセンス要求受信部３５１、管理部３５２、ライセンス情報処理部３５３、ライセンスプール３５４として機能する。

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

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

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

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

ライセンス要求受信部３５１は、クライアント１１０に、成否のステータスと、成功時にはライセンスを返信する。

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

次に、ライセンス要求受信部３５１がライセンス返却要求を受信した場合について説明する。このとき、管理部３５２は、ライセンス要求受信部３５１を介して返却されたライセンスの情報を受け取ると、ライセンス情報処理部３５３に命じてライセンスカウントを１つ増加し、使用許諾先として管理していたクライアント識別子を削除する。

なお、ライセンス発行中のクライアント１１０からのライセンス更新要求が途切れ、そのまま有効期限に達するライセンスもある。管理部３５２では、有効期限に達したライセンスがあるかどうかを定期的に確認し、有効期限に達したライセンスがあった場合、当該ライセンスは失効したと判断し、ライセンス情報処理部３５３に対してライセンス返却時と同じ処理を命ずる。これにより、最後にライセンスが更新されてから時間Ｔ２後にライセンスは自動的に失効し、再び利用可能となる。

以下に、図４と図５のフローチャート、ならびに図６〜図９のタイムチャートの例を用いて、フローティングライセンスの取得、定期更新、返却、失効の一連の流れを説明する。

＜アプリケーション起動要求時の各処理部の処理＞
まず、ユーザの指示によりアプリケーション起動要求が発生した際の、各処理部の起動やライセンスに関する処理について説明する。図４（Ａ）は、起動要求受付時のアプリケーション３００が実行する処理のフロー図である。また、図６は、起動要求受付時のクライアントのアプリケーションとライセンス管理部の動作内容、クライアントにおけるライセンスの取得状況（ライセンスフラグ）、ならびにライセンスサーバ１２０の動作内容、を時系列に示したタイムチャートである。

図６の縦軸には、クライアント１１０で協働して動作可能な２つのアプリケーション３００（３００（１）と３００（２）で表わす）、ライセンスの有無（ライセンスフラグのＯｎ／Ｏｆｆ）、ライセンス管理部３２０、ライセンスサーバ１２０の各要素を示している。横軸は時間経過で、各ｐ点は各事象が発生した時刻を示している。各要素は、太線は有効（アプリケーションが起動中、ライセンスが存在、対応するフラグがＯｎ）であることを示し、細線はその逆に無効であることを示す。線上の丸印はなんらかの処理や、別要素への関与が行われていることを示す。アプリケーションが２つあるのは、複数のアプリケーションが関与する場合の処理を説明するためである。また、各アプリケーションはそれぞれ図３で説明した各処理部を有するものとする。

アプリケーション３００（１）の入力部３０１がユーザからの指示に基づく起動要求を受け付けた場合（ｐ１時点）、Ｓ４０１にて、ライセンス有無確認部３０５はライセンスフラグがＯｎかＯｆｆかを確認する（ｐ２時点）。

Ｓ４０１で、ライセンスフラグがＯｆｆであるとライセンス有無確認部３０５において判断した場合、ライセンス管理部３２０がライセンスを取得しておらず、当該起動指示されたアプリケーション３００（１）が最初に起動指示されたアプリケーションであることを示している。この場合、Ｓ４０２にて、ライセンス要求送信部３０４がライセンスサーバ１２０にアクセスし、ライセンス取得要求を送信する（ｐ３時点）。

Ｓ４０３にて、ライセンス取得に成功したか判定し、Ｙｅｓ（ライセンス取得成功）と判定された場合、Ｓ４０４にて、管理部３０２はアプリケーション３００（１）を実行可能状態（ユーザが該アプリケーションを使用可能な状態）にする。そして、Ｓ４０５にて、アプリケーションフラグをＯｎにする（ｐ４時点）。

なお、Ｓ４０１にてライセンス有無確認部３０５においてＹｅｓ（ライセンスフラグがＯｎ）と判断した場合、ライセンス管理部３２０がライセンスを取得済みであり、当該起動指示されたアプリケーションは２番目以降に起動指示されたアプリケーションであることを示している。この場合、Ｓ４０４にて、すぐに当該起動指示されたアプリケーションを実行可能状態にする。

Ｓ４０６にて、ライセンス管理部状態確認部３０６が、ライセンス管理部フラグがＯｎかＯｆｆかを判定（すなわち、ライセンス管理部３２０が起動済みかどうかを確認）する（ｐ５時点）。Ｓ４０６にてＮｏ（ライセンス管理部３２０が非起動）と判断した場合、Ｓ４０７にて、管理部３０２はライセンス管理部３２０に対して起動要求を行い、アプリケーション３００（１）の起動要求処理は完了する（ｐ６時点）。一方、Ｓ４０６にてＹｅｓ（ライセンス管理部３２０が起動済）と判断された場合、アプリケーション３００（１）の起動要求処理は完了する。以上が、アプリケーション３００が起動要求を受けた際の処理となる。

次に、ライセンス管理部３２０が、Ｓ４０７にてアプリケーションの管理部３０２から起動要求を受けた際の処理について説明する。図４（Ｂ）は、起動要求受付時のライセンス管理部３２０が実行する処理のフロー図であり、図６のタイムチャートとともに説明を行う。

ライセンス管理部３２０の要求受信部３２１は、Ｓ４０７にて発行されたライセンス管理部の起動要求を受けると（ｐ６時点）、ライセンス管理部３２０の管理部３２２はライセンス管理部３２０を起動状態にし、Ｓ４２１にて、ライセンス管理部フラグをＯｎにする（ｐ７時点）。なお、ライセンス管理部フラグがＯｎになると、これ以降に起動要求された他のアプリケーション３００では、Ｓ４０６の判断によって、Ｓ４０７のライセンス管理部３２０の起動処理はスキップされる。

次に、Ｓ４２２からＳ４３０のループにて、管理部３２２は、アプリケーション３００（１）〜（２）のいずれかが起動している間、ライセンスの定期更新処理を実行する。まずＳ４２３にて、管理部３２２は、所定の時間間隔Ｔ１（本実施例では３分）の間ウェイトする。これが定期更新の間隔となる。Ｓ４２４にて、管理部３２２はアプリケーション状態確認部３２４に命じて、アプリケーションフラグでＯｎのものがあるか（すなわち、いずれかのアプリケーションが動作しているかどうか）を確認する（ｐ８時点）。Ｓ４２４にてＹｅｓと判断（いずれかのアプリケーションが動作中）の場合、Ｓ４２５にて、ライセンス要求送信部３２３がライセンスサーバ１２０に接続し、ライセンス取得要求を送信する（ｐ９時点）。Ｓ４２６にてライセンス取得に成功したか確認し、Ｙｅｓ（取得成功）と判断された場合、Ｓ４２７にて、管理部３２２はライセンスフラグをＯｎにする（ｐ１０時点）。なお、ライセンスフラグがＯｎになると、これ以降に起動要求された他のアプリケーション３００では、Ｓ４０１の判断によって、すぐにアプリケーションの実行（Ｓ４０４）を行うことができる。

一方、Ｓ４２６にてＮｏ（取得失敗）と判断された場合、ネットワークの切断やライセンスサーバのダウンが考えられる。このような場合は、ライセンスの更新ができないため、ライセンスの有効期限切れの確認が必要となる。Ｓ４２８にて、管理部３２２は取得済のライセンスが期限切れかどうかを確認し、Ｙｅｓ（期限切れ）と判断された場合は、Ｓ４２９にてライセンスフラグをＯｆｆにする。Ｓ４２８にてＮｏ（期限内）と判断された場合は、Ｓ４３０のループ端に進むので、Ｓ４２３に戻ることになる。以上の定期更新処理（Ｓ４２２からＳ４３０のループ）を、当該ライセンスにより動作可能な全てのアプリケーションが終了するまで繰り返す。すなわち、Ｓ４２３にて間隔Ｔ１のウェイト後、Ｓ４２４にて再びアプリケーションの起動有無を確認し（ｐ１１時点）、Ｓ４２５にてライセンス要求を送信する（ｐ１２時点）、という処理が繰り返される。

一方、Ｓ４２４にてＮｏ（動作中のアプリケーション無し）と判断された場合、Ｓ４３１にて、管理部３２２はライセンス管理部３２０の終了処理を行う。これは、動作中のアプリケーションが存在しなくなり、ライセンスの保持が不要となった場合に該当する。終了処理の詳細については後述する。以上が、ライセンス管理部３２０が起動要求を受けた際の処理となる。

ここで、アプリケーション３００（１）の動作中に、他のアプリケーション３００（２）の起動要求が発生した場合について説明する。もし、アプリケーション３００（２）のライセンス有無確認部３０５がＳ４０１においてライセンス有無の確認処理を行った時点が、上述したｐ１０時点よりも後であれば、ライセンスフラグがＯｎになっているため、Ｓ４０４にてすぐにアプリケーション３００（２）は実行可能状態になる。この場合、ライセンス管理部などの別アプリケーションの起動待ちや、別アプリケーションとのプロセス間通信が存在しないため、アプリケーション３００（２）を高速に起動することが可能となる。なお、ライセンス有無の確認処理（Ｓ４０１）が、ｐ１０時点よりも前であれば、ライセンスフラグがＯｆｆであるので、アプリケーション３００（２）自身がライセンスの取得要求を行って（Ｓ４０２）、アプリケーション３００（２）を実行可能状態にする（Ｓ４０４）。この場合、２つのアプリケーションがそれぞれライセンスを取得し、それぞれのメモリ空間にライセンスを保持することになり得るが、前述したように、ライセンスサーバから見れば単一のクライアントに更新ライセンスを送っただけとなり、問題にはならない。各アプリケーション自身が取得したライセンスはいずれ失効し、ライセンス管理部３２０が取得したライセンスのみによって管理されることとなる。以上のように、それぞれのアプリケーションを確実に起動することができ、且つ、一定時間後にはライセンス管理部３２０がライセンスを一元管理することになる。

＜アプリケーション終了要求時の各処理部の処理＞
次に、ユーザの指示によりアプリケーション終了要求が発生した際の、各処理部の処理やライセンスに関する処理について説明する。図５（Ａ）は、終了要求受付時のアプリケーション３００が実行する処理のフロー図である。また、図７は、終了要求受付時のクライアントのアプリケーションとライセンス管理部の動作内容、クライアントにおけるライセンスの取得状況（ライセンスフラグ）、ならびにライセンスサーバ１２０の動作内容、を時系列に示したタイムチャート例である。

アプリケーション３００の入力部３０１がユーザの指示により終了要求を受けると、Ｓ４１１にて、アプリケーション状態確認部３０７は、他のアプリケーションのアプリケーションフラグでＯｎのものがあるか（すなわち、他に動作中のアプリケーションがあるか）を確認する。Ｓ４１１にてＹｅｓ（他に動作中のアプリケーション有り）と判断された場合は、まだライセンスの保持が必要であるので、ライセンスの返却をせずにアプリケーションを終了する。この場合、管理部３０２は、Ｓ４１３にて当該終了要求されたアプリケーション３００のアプリケーションフラグをＯｆｆにし、Ｓ４１４にて当該終了要求されたアプリケーション３００を終了する。一方、Ｓ４１１にてＮｏ（他に動作中のアプリケーション無し）と判断された場合は、ライセンスの保持が不要となるので、ライセンスの更新処理終了と返却のため、管理部３０２は、Ｓ４１２にてライセンス管理部３２０に終了を要求し、その後、Ｓ４１３に進む。

例えば、アプリケーション３００（１）、（２）が共に起動している状態で、アプリケーション３００（２）に対してユーザの指示により終了要求を受けると（ｐ２１時点）、Ｓ４１１にて他のアプリケーションフラグを確認する（ｐ２２時点）。この場合、アプリケーション３００（１）のアプリケーションフラグがＯｎであるので、アプリケーション３００（２）は、Ｓ４１３にてアプリケーション３００（２）のアプリケーションフラグをＯｆｆとして、Ｓ４１４にて終了する（ｐ２３時点）。複数のアプリケーションが起動していた場合、最後に終了するアプリケーション以外はｐ２１−ｐ２３と同様の処理となる。この後、アプリケーション３００（１）も終了要求を受けると（ｐ２４時点）、Ｓ４１１にて他のアプリケーションフラグを確認する（ｐ２５時点）。この場合、他に動作中のアプリケーションが存在しない（他のアプリケーションフラグがＯｆｆである）ので、アプリケーション３００（１）は、Ｓ４１２にてライセンス管理部３２０に終了を要求する（ｐ２６時点）。そして、Ｓ４１３にてアプリケーション３００（１）のアプリケーションフラグをＯｆｆとして、Ｓ４１４にて終了する（ｐ２７時点）。以上が、アプリケーション３００が終了要求を受けた際の処理となる。

次に、ライセンス管理部３２０が、アプリケーションの管理部３０２からＳ４１２にて終了要求を受けた際の処理について説明する。図５（Ｂ）は、終了要求受付時のライセンス管理部３２０が実行する処理のフロー図であり、図７のタイムチャートとともに説明を行う。

ライセンス管理部３２０の要求受信部３２１は、Ｓ４１２にてアプリケーションの管理部３０２から終了要求を受けると（ｐ２６時点）、Ｓ４４１にて、管理部３２２は、ライセンスフラグをＯｆｆにする（ｐ２８時点）。続けて、Ｓ４４２にて、ライセンス要求送信部３２３は、ライセンスサーバ１２０にライセンス返却要求を送信する（ｐ２９時点）。その後、管理部３２２は、Ｓ４４３にてライセンス管理部フラグをＯｆｆにして、Ｓ４４４にてライセンス管理部３２０を終了する（ｐ３０時点）。以上が、ライセンス管理部３２０が終了要求を受けた際の処理となる。

以上により、すべてのアプリケーションが終了すると、ライセンス管理部が取得していたライセンスもライセンスサーバに返却されて、ライセンス管理部も終了し、各フラグ（アプリケーションフラグ、ライセンスフラグ、ライセンス管理部フラグ）もＯｆｆとなる。

なお、前述したＳ４３１でライセンス管理部３２０の終了要求を行う場合も、Ｓ４４１からＳ４４４の処理が実行される。

ここまで説明したように、本システムでは、最初のアプリケーション３００を起動する際に、該アプリケーション３００自身が、ライセンスサーバ１２０からライセンスを取得し、成功すれば当該アプリケーション３００を実行可能状態にする。このように構成することにより、アプリケーションがライセンス管理部を起動し、該ライセンス管理部がライセンスサーバからライセンスを取得してアプリケーションに返し、その後アプリケーションが起動するのと比べ、以下の時間が節約できる。すなわち、ライセンス管理部３２０の起動時間、ならびに、アプリケーション３００のプロセスとライセンス管理部３２０のプロセスとの間の通信時間、を節約できる。

以上により、最初のアプリケーションを起動する際の時間を高速化することができ、ユーザの利便性が向上する。また、一定時間後にはライセンス管理部３２０がライセンスを一元管理するので、管理が容易になる。

＜アプリケーションクラッシュ時の各処理部の処理＞
次に、アプリケーションが実行中にクラッシュしたケースを考える。もし、起動中のアプリケーション３００が存在しないにも関わらずライセンスを保持してしまうと、他のユーザのアプリケーション利用機会を減らすことになり好ましくない。そこで、実行中のアプリケーションがクラッシュして存在しなくなった場合は、自動的にライセンスを返却する例を、図８のタイムチャートを用いて説明する。

アプリケーションがクラッシュして、実行中のプロセスがなくなると、アプリケーションフラグがＯｆｆとなる（ｐ４１時点）。次に、ライセンス管理部３２０の定期更新処理により、Ｓ４２４にて実行中アプリケーションが存在するかどうかのチェックが実行される（ｐ４２時点）。起動中のアプリケーションがないと判断されると（Ｓ４２４でＮｏ）、Ｓ４３１に進む。そして、Ｓ４４１にてライセンスフラグをＯｆｆとし（ｐ４３時点）、Ｓ４４２にてライセンス返却が行われて（ｐ４４時点）、Ｓ４４３でライセンス管理部フラグをＯｆｆにしてＳ４４４でライセンス管理部３２０を終了する（ｐ４５時点）。

以上のように、本システムでは、アプリケーション３００がクラッシュしたような場合でも、ライセンス管理部３２０による定期更新処理により、最大でもクラッシュから所定期間以内にライセンスの返却処理が行われる。これにより、ライセンスの無駄な消費を抑えることができる。

次に、ライセンス管理部３２０がクラッシュしたケースを考える。ライセンス管理部３２０がクラッシュすると、ライセンスフラグもＯｆｆになるものとする。また、一定時間が経過してライセンスの有効期限に達すると、実際に取得していたライセンスは失効する。ライセンスが失効しても、起動中のアプリケーションは終了されるまでは利用可能なシステムである場合、起動中のアプリケーションの利用は問題ない。更に、ここで、別のアプリケーションの起動要求が発生した場合を考える。新しいアプリケーション３００の起動では、Ｓ４０１にてライセンスフラグはＯｆｆと判断されるため、Ｓ４０２にてアプリケーション自身がライセンス取得要求を行う。ライセンス失効前であれば通常はライセンスの取得（ここでは更新）に成功し、失効後であれば成否はライセンスサーバ１２０のライセンス残数に依存する。ライセンスの取得に成功すれば、更にＳ４０６でライセンス管理部３２０が非起動であることを検知し、Ｓ４０７でライセンス管理部３２０を起動する。これにより、正常な状態に戻すことができる。

以上のように、本システムでは、ライセンス管理部３２０がクラッシュしたような場合でも、使用中のアプリケーションは使うことができ、新しいアプリケーションも起動することができるので、ユーザの利便性を損ねることはない。

（実施例２）
アプリケーション終了要求が発生した際の処理について、図７とは異なる別の処理手順を示す。図９は、終了要求受付時の各処理部の動作内容や状態を時系列に示したタイムチャートである。

ユーザからの終了要求を受けると（ｐ５１時点）、アプリケーション３００（１）はＳ４１１にて他のアプリケーションのアプリケーションフラグを確認し、動作中の他のアプリケーションが存在しないかどうか（すなわち、当該終了指示されたアプリケーションが最後のアプリケーションであるかどうか）を判断する（ｐ５２時点）。次に、アプリケーション３００（１）は、Ｓ４１２でライセンス管理部３２０に終了を要求する代わりに、ライセンスフラグのＯｆｆを要求し（ｐ５３時点）、さらに、ライセンスサーバ１２０へのライセンス返却要求（ｐ５４時点）を行う。そして、Ｓ４１３にてアプリケーションフラグをＯｆｆにし、Ｓ４１４にて終了する（ｐ５５時点）。

このとき、ライセンス管理部３２０は、定期更新処理によって、Ｓ４２４にてアプリケーションの存在チェックが実行され、起動中のアプリケーションがないと判断される（ｐ５６時点）。この後、Ｓ４４１にてライセンスフラグＯｆｆと（ｐ５７時点）、Ｓ４４２にてライセンス返却（ｐ５８時点）が行われるが、いずれもｐ５３、ｐ５４で既に実施されているためＳ４４１ｔｏＳ４４２の処理はスキップしてもよい。最後に、Ｓ４４３〜Ｓ４４４にてライセンス管理部フラグをＯｆｆにしてライセンス管理部を終了する。

以上のようにすることで、実施例２によれば、アプリケーション３００のプロセスとライセンス管理部３２０との間のプロセス間通信を減らすこともできる。

（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。その処理は、上述した実施例の機能を実現させるソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (7)

1. ライセンスサーバと、
   複数のアプリケーション、および前記複数のアプリケーションを起動するためのライセンスを前記ライセンスサーバから取得するライセンス管理部を有するクライアント装置と、
   を含むライセンス管理システムであって、
   前記複数のアプリケーションのうちの一つのアプリケーションが、
   前記アプリケーションを起動するための第一の起動要求を受け付けた場合に、前記ライセンス管理部が前記ライセンスを取得済みか判断する第１の判断手段と、
   前記第１の判断手段によって前記ライセンス管理部が前記ライセンスを取得済みではないと判断された場合、前記ライセンスサーバから前記ライセンスを取得する第１のライセンス要求手段と、
   前記第１の判断手段によって前記ライセンス管理部が前記ライセンスを取得済みであると判断された場合、前記アプリケーションをユーザが使用可能な状態にする処理実行手段と、
   前記処理実行手段によって前記アプリケーションが使用可能な状態に変更された後、前記ライセンス管理部が起動中でなければ、前記ライセンス管理部を起動させる起動手段と、
   を有することを特徴とするライセンス管理システム。
2. 複数のアプリケーション、および前記複数のアプリケーションを起動するためのライセンスをライセンスサーバから取得するライセンス管理部を有するクライアント装置であって、
   前記複数のアプリケーションのうちの一つのアプリケーションが、前記アプリケーションを起動するための第一の起動要求を受け付けた場合に、前記ライセンス管理部が前記ライセンスを取得済みか判断する第１の判断手段と、
   前記第１の判断手段によって前記ライセンス管理部が前記ライセンスを取得済みではないと判断された場合、前記ライセンスサーバから前記ライセンスを取得する第１のライセンス要求手段と、
   前記第１の判断手段によって前記ライセンス管理部が前記ライセンスを取得済みであると判断された場合、前記アプリケーションをユーザが使用可能な状態にする処理実行手段と、
   前記処理実行手段によって前記アプリケーションが使用可能な状態に変更された後、前記ライセンス管理部が起動中でなければ、前記ライセンス管理部を起動させる起動手段と、
   を有することを特徴とするクライアント装置。
3. 前記クライアント装置は、
   前記ライセンスを更新する第１のライセンス要求手段をさらに有し、
   前記第２のライセンス要求手段は、前記ライセンスサーバから前記ライセンスを取得した場合にライセンスフラグをＯｎにし、
   前記第１の判断手段は、前記ライセンスフラグがＯｎであるかどうかに基づいて、前記ライセンス管理部が前記ライセンスを取得済みかどうか判断する
   ことを特徴とする請求項２に記載のクライアント装置。
4. 前記アプリケーションは、さらに、
   前記アプリケーションの終了要求を受けた場合に、他に動作中のアプリケーションがあるかどうか判断する第２の判断手段、
   前記第２の判断手段で他に動作中のアプリケーションが無いと判断した場合に、前記ライセンス管理部に対して終了要求を行う終了要求手段、
   前記アプリケーションを終了する第１の終了手段、
   として前記クライアント装置のコンピュータを機能させ、
   前記ライセンス管理部として機能させるためのプログラムは、さらに、
   前記終了要求手段からの終了要求に応じて、前記ライセンスを前記ライセンスサーバに返却するライセンス返却手段、
   前記ライセンス返却手段により前記ライセンスを前記ライセンスサーバに返却した後に、前記ライセンス管理部を終了する第２の終了手段、
   として前記クライアント装置のコンピュータを機能させる、
   ことを特徴とする請求項２に記載のクライアント装置。
5. 前記処理実行手段は、当該起動要求を受けたアプリケーションをユーザが使用可能な状態にした場合に、当該アプリケーションのアプリケーションフラグをＯｎにし、
   前記第２の判断手段は、他のアプリケーションのアプリケーションフラグがＯｎであるかどうかに基づいて、他に動作中のアプリケーションがあるかどうか判断する
   ことを特徴とする請求項４に記載のクライアント装置。
6. 前記アプリケーションは、さらに、
   前記アプリケーションの終了要求を受けた場合に、他に動作中のアプリケーションがあるかどうか判断する第２の判断手段、
   前記第２の判断手段で他に動作中のアプリケーションが無いと判断した場合に、前記ライセンスフラグをＯｆｆにして、前記ライセンスを前記ライセンスサーバに返却するライセンス返却手段、
   前記アプリケーションを終了する第１の終了手段、
   として前記クライアント装置のコンピュータを機能させ、
   前記ライセンス管理部として機能させるためのプログラムは、さらに、
   動作中のアプリケーションがあるかどうか定期的に判断し、動作中のアプリケーションが無いと判断した場合に、前記ライセンス管理部を終了する第３の終了手段、
   として前記クライアント装置のコンピュータを機能させる、
   ことを特徴とする請求項３に記載のクライアント装置。
7. コンピュータを、
   複数のアプリケーション、および前記複数のアプリケーションを起動するためのライセンスをライセンスサーバから取得するライセンス管理部を有するクライアント装置として機能させるためのプログラムであって、
   前記複数のアプリケーションのうちの一つのアプリケーションが、前記アプリケーションを起動するための第一の起動要求を受け付けた場合に、前記ライセンス管理部が前記ライセンスを取得済みか判断する第１の判断手段と、
   前記第１の判断手段によって前記ライセンス管理部が前記ライセンスを取得済みではないと判断された場合、前記ライセンスサーバから前記ライセンスを取得する第１のライセンス要求手段と、
   前記第１の判断手段によって前記ライセンス管理部が前記ライセンスを取得済みであると判断された場合、前記アプリケーションをユーザが使用可能な状態にする処理実行手段と、
   前記処理実行手段によって前記アプリケーションが使用可能な状態に変更された後、前記ライセンス管理部が起動中でなければ、前記ライセンス管理部を起動させる起動手段と、
   を有する
   ことを特徴とするクライアント装置として機能させるためのプログラム。

Images