JP4242458B2 - ライセンス管理システム - Google Patents

Description

技術分野
本発明はソフトウェアのライセンス管理システムに関し、特に、ソフトウェアメーカーから所望のソフトウェアをユーザに提供する際に、当該ユーザの使用環境に応じた自在なソフトウェアライセンスの発給を可能とするライセンス管理システムに関する。
背景技術
近年、コンピュータがあらゆる分野で広く利用されるようになるにつれて、ソフトウェアそれ自体の開発のみならず、ソフトウェアメーカーがユーザにソフトウェアを発給する際に、又はソフトウェアの発給後に、ソフトウェアのライセンス管理もまた重要なものとなっている。
一般に、ソフトウェアはソフトウェアメーカーが開発し、ハードウェア（コンピュータ）を持つユーザがそのソフトウェアを所定のライセンス契約に基づき使用する。ソフトウェアを供給した後に、ソフトウェアメーカーはライセンス管理を実行し、即ち、そのソフトウェアが所定のライセンス契約どおり適正に使用されているか否かチェックする。
従来、ライセンス契約には主に２の形式がある。即ち、フローティング・ライセンスシステムとノードロック・ライセンスシステムである。前者では、ソフトウェアの起動毎にライセンス数が一つずつ減少し、ソフトウェアの終了毎に一つずつライセンス数が増加するシステムである。後者は、ユーザ側にて使用するハードウェアが固定されており、ソフトウェアメーカーは、ソフトウェアの本数によらず所定の一定価格にてライセンスを発給する。
さらに、前者において、ユーザが複数のワークステーション（例えば１０台）を同じソフトウェアで稼働させたい場合には、ソフトウェアメーカーは１０本分のライセンスの価格でユーザからライセンス契約をとる。
前者によれば、ソフトウェアメーカーはソフトウェア単価を高く設定できる利点がある。一方、ユーザは自身が扱うことができるソフトウェアについて使用上のフレキシビリティを持つ利点がある。
一方、後者において、ユーザで使用するハードウェアは固定され、ソフトウェアの数とその性能によらず所定の一定価格にてライセンス契約を発給する。
後者によれば、ユーザはソフトウェアを低い価格単位で設定できる利点がある。しかしながら、使用するハードウェアが固定されているのでソフトウェアの使用上においてフレキシビリティに欠ける。さらに全てのソフトウェアが１つのハードウェアで扱われるので、システム全体の処理速度が悪化する問題がある。
以上説明のように、従来のライセンスシステムではソフトウェアメーカー側にとってもユーザ側にとっても種々の問題がある。特に、ソフトウェアメーカー側にとってはその販売戦略を考慮したライセンスの発給ができないという問題がある。従って、ソフトウェアメーカーは、多額の費用を投入して開発したソフトウェアを適正な価格でユーザに供給すべく最適なライセンス管理を探究し開発してきた。
発明の開示
本発明の目的は、ソフトウェアメーカーの販売戦略を考慮したライセンスの発給を可能にするライセンス管理システムを提供することにある。
本発明は、単一もしくは複数のコンピュータを駆動するソフトウェアのライセンス管理システムであって、自身を駆動するために必要なキー数の決定を要求し、ライセンスの発給を受けるアプリケーション・プログラムと、前記アプリケーション・プログラムからの要求に応じて必要なキー数を決定するライセンス数決定部と、前記キー数決定部にて決定されたキー数を前記アプリケーション・プログラムに対して発給するライセンス管理部とを具備する。
前記キー数決定部は、以下の多項式関数に基づきキー数を決定する手段を含む。
ＬＫ＝ｆ（ｘ１，ｘ２，．．．．，ｘｎ）
但し、ＬＫはキー数、ｘｎはキー数の決定に必要なパラメータである。
さらに、本発明は、少なくともライセンス管理部と、アプリケーション・プログラムと、キー数決定部とを備え、単一もしくは複数のコンピュータを駆動するソフトウェアのライセンス管理システムにおけるライセンス管理方法であって、
アプリケーション・プログラムが起動された際に、前記アプリケーション・プログラム自身の起動に必要なキー数を多項式関数に代入してもらうために、パラメータを前記アプリケーション・プログラムから前記キー数決定部に渡す段階と、
キー数決定部において、キー数の決定に必要なパラメータの値を調べてキー数を決定し、前記アプリケーション・プログラムから渡されたパラメータに決定したキー数を代入し、前記アプリケーション・プログラムにパラメータを返す段階と、
アプリケーション・プログラムからライセンス管理部に、自身が必要とするキー数をパラメータを渡すことによって通知し、ライセンスを要求する段階と、
ライセンス管理部においてキー数決定部から正常フラグを受けると、保持しているキー数から必要なキー数分を減らし、その結果、ライセンス管理部にて保持しているキー数が負にならなければ、正常フラグをアプリケーション・プログラムに返すとともに、前記アプリケーション・プログラムにライセンスを発給する段階とを具備する。
【図面の簡単な説明】
図１〜図５は、ソフトウェアメーカーの販売戦略の説明図である。
図６は、本発明によるライセンス管理システムの第１の実施形態としての基本構成図である。
図７は、本発明によるライセンス管理システムの第２の実施形態としての基本構成図である。
図８は、本発明によるライセンス管理システムの第３の実施形態としての基本構成図である。
図９は、本発明によるライセンス管理システムの第４の実施形態としての基本構成図である。
図１０は、ライセンスデーモンとアプリケーション・プログラムとの間の起動処理の説明図である。
図１１は、ライセンスデーモンにおけるフォーク処理の説明図である。
図１２は、アプリケーション・プログラムにおけるフォーク処理の説明図である。
図１３は、アプリケーション・プログラムの終了処理の説明図である。
図１４は、専用アプリケーション・マネージャからの強制終了の説明図である。
図１５は、アプリケーション・プログラムの終了報告の説明図である。
図１６は、専用ライセンスデーモンに対する終了処理の説明図である。
図１７は、専用ライセンスデーモンからの調査要求の説明図である。
図１８は、専用アプリケーション・マネージャからの正常通知の説明図である。
図１９は、専用ライセンスデーモンからの再起動処理の説明図である。
図２０は、専用ライセンスデーモンにおけるライセンス解除処理の説明図である。
図２１は、専用アプリケーション・マネージャから専用ライセンスデーモンへの調査要求の説明図である。
図２２は、専用ライセンスデーモンから専用アプリケーション・マネージャへの正常通知の説明図である。
図２３は、専用アプリケーション・マネージャにおける無効情報の説明図である。
図２４は、専用アプリケーション・マネージャにおける終了処理の説明図である。
図２５は、専用ライセンスデーモンにおける再起動の説明図である。
図２６は、ライセンスデーモンからの無効通知の説明図である。
図２７は、ライセンスデーモンからの再起動通知の説明図である。
図２８は、専用ライセンスデーモンからライセンスデーモンへのポーリング処理の説明図である。
図２９は、ライセンスデーモンにおける終了処理の説明図である。
図３０は、専用アプリケーション・マネージャＡＰＣＭ１が所定の処理時間内にアプリケーション・プログラムＡＰ１から命令ＣＯＲを受けない場合における、ライセンスデーモンにおける終了処理の説明図である。
図３１は、ライセンスデーモンにおける異常終了の説明図である。
図３２は、アプリケーション・プログラムにおける異常終了の説明図である。
図３３は、ライセンスデーモンと専用アプリケーション・マネージャとの間における異常終了の説明図である。
図３４は、アプリケーション・プログラムと専用アプリケーション・マネージャの両方における異常終了の説明図である。
図３５は、アプリケーション・プログラムと専用ライセンスデーモンの両方における異常終了の説明図である。
図３６は、ライセンスデーモンと専用ライセンスデーモンの両方における異常終了の説明図（その１）である。
図３７は、ライセンスデーモンが図３６の説明で記載された状況の後に再起動する場合の説明図である。
図３８は、システム構成の説明図である。
図３９は、キー数を決定するフローチャートである。
図４０（Ａ）乃至図４０（Ｉ）は、キー数を決定する実関数リストである。
図４１（Ａ）乃至図４１（Ｆ）は、プログラムの一例の説明図である。
図４２（Ａ）乃至図４２（Ｃ）は上記プログラムの実行結果の説明図である。
発明を実施するための最良の形態
図１〜図５はソフトウェアメーカーの販売戦略の説明図である。本明細書では、ライセンスを「キー」（“ｋｅｙ”）とも称し、ライセンス数はキー数とも称する。既存のライセンスシステムでは、「キー数＝ライセンス数」であり、キー数はソフトウェアの価値と同じと考えることができる。しかしながら、適正なライセンス管理を実現するためには、キー数とライセンス数の間に所定の相関関係（後述する関数“ｆ”に対応する関係）を実現することが望ましい。例えば、キー数がライセンス数に比例する関係を持つことが望ましい。
以下の５つのパターンは、図１乃至図５に示すように、ソフトウェアメーカーの販売戦略において考慮しなければならない。
図１に示すように、アプリケーション・プログラムが、メモリを多く備えた高速ハードウェアにおいて高速で動作するように特化された設計の場合には、ソフトウェアの設計は複雑となり、その結果ソフトウェアは価値の高いものとなる。従って、多くのメモリを持つハードウェアがユーザ側で使用されるときは、ソフトウェアメーカーはユーザに対してメモリ数が多ければ多いほどより多くのキー数を要求すべきである。
図２に示すように、図１の状況では、コンピュータの性能が高いほどコンピュータの単位時間当たりの処理能力が向上する。従って、ソフトウェアメーカーはコンピュータの性能が高ければ高いほどユーザに対してより多くのキー数を要求すべきである。
図３に示すように、アプリケーション・プログラムが特化されていない設計の場合には、ユーザから見れば、コンピュータの性能が高いほどソフトウェアの見かけの性能が高くなるのであるから、アプリケーション・プログラムは少ないキー数で動作すべきである、との見方もある。このような見方のときは、ソフトウェアメーカーは、少ないキー数でソフトウェアを起動できるように考慮すべきである。しかしながら、これは特殊な場合である。例えば、そのソフトウェアがまだ開発と設計途上にあり、その性能がソフトウェアメーカーにおいて最終的に決定されていない場合に、ソフトウェアメーカーはソフトウェア性能を改善するためにユーザ側にてそのソフトウェアを使用して欲しいと願う。
図４に示すように、ソフトウェアを大量購入するユーザに対しては、購入したキー数に応じて必要なキー数を段階的に減らす。従って、この場合、ソフトウェアメーカーにおいてソフトウェアの実質的な単価を下げる必要がある。
図５に示すように、ソフトウェアメーカーは、ソフトウェアを所定の期日までは無償（必要キー数が「０」に相当）で供給し、その期日以降はソフトウェアを有償（キー数が「０」より大きいに相当）で供給する。
以上のように、ユーザのソフトウェア使用上の諸要因、即ち、ハードウェア的な要因、処理時間的な要因、価格的な要因、等の諸要因に応じて、キー数を決定するようなライセンス管理システムを提供する必要がある。
本発明は、ソフトウェアメーカー側で柔軟にパラメータを設定できるキー数の発給を実行することを目的とする。
上記の目的を達成するために、本発明では、まず、必要なキー数を決定する機能（キー数決定手段）を持つ。キー数決定部では、次式に示す多項式関数に基づいてキー数を決定する。
ＬＫ＝ｆ（ｘ１，ｘ２，．．．．，ｘｎ） ・・・・ （１）
ここで、ＬＫはキー数、ｘｎはキー数の決定に必要なパラメータである。パラメータとして、図１乃至図５で説明したようなハードウェアのメモリ容量、システムのクロックスピード、さらにソフトウェアメーカー側で自由に設定可能な項目、その他、がある。
さらに、本発明では、ソフトウェアが起動された際に、キー数を決定するために必要なパラメータ値を取得する機能（パラメータ値取得手段）を持つ。
キー数ＬＫが常に「１」となるように設定される場合は、従来のシステムと等価となる。これは、本発明のシステムが従来システムの上位に位置にランクされ、従来との互換性を持つことを意味する。従って、本発明の機能に基づいて、ソフトウェアメーカー側にて販売戦略が考慮されたキー数の発給を実現することができる。さらに、従来の固定キー数を利用することも可能である。その結果、ソフトウェアに対して改善されたライセンス管理システムを提供することができる。
図６は本発明によるライセンス管理システムの第１の実施形態としての基本構成図である。図中、Ａはライセンス管理部、Ｂはアプリケーション・プログラム、Ｃはキー数決定部（デーモンプログラム）である。周知のように、デーモンプログラムとはオペレーションシステム（ＯＳ）上でバックグランドで自動的に実行されるプログラムである。また、本発明において、データの授受は、全て、例えばＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）のようなＵＮＩＸ系のネットワークを介して行われる。なお、以下の図中の数字は処理手順を示す。
処理手順１：アプリケーション・プログラムＢが起動された際に、アプリケーション・プログラムを起動するのに必要なキー数を代入するためにパラメータ（例えば、NoOfKeys）をキー数決定部Ｃに渡す。
処理手順２：キー数決定部Ｃは、キー数の決定に必要なパラメータの値を調べてキー数を決定し、アプリケーション・プログラムから渡されたパラメータ（NoOfKeys）に決定された値を代入し、アプリケーション・プログラムＢにパラメータを返す。
処理手順３：アプリケーション・プログラムＢは、ライセンス管理部Ａに、必要とするキー数をパラメータ（NoOfKeys）を渡すことにより通知しライセンスを要求する。
処理手順４：ライセンス管理部Ａは、アプリケーション・プログラムＢの要求するキー数が正しいか否か確認するために、アプリケーション・プログラムから通知されたキー数（NoOfKeys）をキー数決定部Ｃに通知する。
処理手順５：キー数決定部Ｃは、アプリケーション・プログラムＢからライセンス管理部Ａに通知されたキー数と、アプリケーション・プログラムＢに通知した必要なキー数とを比較する。キー数が正しければ、キー数決定部Ｃは正常フラグをライセンス管理部Ａに返す。
なお、処理手順４及び５は正当な要求が実行されたか否かの確認のためであり、任意の手順である。
処理手順６：ライセンス管理部Ａは、キー数決定部Ｃから正常フラグを受けると、保持しているキー数から必要なキー数分を減らし、ライセンス管理部に保持されているキー数が負にならなければ、正常フラグをアプリケーション・プログラムＢに返し、アプリケーション・プログラムＢにライセンスを発給する。アプリケーション・プログラムＢはライセンスの発給を受けると、実行可能なアプリケーション・プログラムとなる。もし、拒絶を示す異常フラグ、例えば、保持しているキー数が負になることを示すフラグ、がライセンス管理部Ａから返されたときは、アプリケーション・プログラムＢはその時点で終了する。
図７は本発明によるライセンス管理システムの第２の実施形態としての基本構成図である。上記の第１の実施形態ではキー数決定部Ｃは独立したデーモンプログラムとして動作する。本実施形態では、キー数決定関数Ｃ’を関数コールとしてアプリケーション・プログラム内に組み込んでいる。この場合では第１の実施形態とは異なり、処理手順１は可変引数の関数コールとして与えられ、処理手順２はその戻り値として与えられる。さらに、キー数は式（１）に基づいてキー数決定部Ｃ自身を含むアプリケーション・プログラムにより決定される。
処理手順１：アプリケーション・プログラムＢが起動された際に、自身の起動に必要なキー数を受けるためにパラメータ（NoOfKeys）をキー数決定関数Ｃ’に渡す。
処理手順２：キー数決定関数Ｃ’は、パラメータの必要な値を調べ、キー数を決定する。さらに、キー数決定関数Ｃ’はアプリケーション・プログラムＢから渡されたパラメータに値を代入し、アプリケーション・プログラムＢに対して値とともにパラメータ（NoOfKeys）を返す。
処理手順３：アプリケーション・プログラムＢは、ライセンス管理部Ａに必要なキー数を、パラメータ（NoofKeys）を渡すことにより通知し、ライセンスを要求する。
第１の実施形態で説明した処理手順４及び５は任意なのでここでは省略する。
処理手順６：ライセンス管理部Ａは、アプリケーション・プログラムＢから要求を受けると、ライセンス管理部Ａ自身に保持しているキー数から必要なキー数分を減らす。減算の結果、保持しているキー数が負にならなければ、ライセンス管理部Ａは正常フラグをアプリケーション・プログラムＢに返し、アプリケーション・プログラムＢにライセンスを発給する。アプリケーション・プログラムＢはライセンスの発給を受けると、実行可能なアプリケーション・プログラムとなる。もし、ライセンス管理部Ａから異常フラグが返されたときは、アプリケーション・プログラムＢはその時点で終了する。
図８は本発明によるライセンス管理システムの第３の実施形態としての基本構成図である。上記の第１の実施形態では、ソフトウェアメーカー側の都合で、多項式関数を変更する際には、直接、キー数決定部Ｃを変更する方法をとっていた。本実施形態では、多項式関数を決定するデータベースＤが、キー数決定部Ｃに多項式関数を読み込ませるために別途に用意される。この場合、多項式関数を変更する際には、データベースＤを変更し、その結果、キー数決定部Ｃにおける多項式関数の変更は不要となる。
処理手順１：アプリケーション・プログラムＢが起動された際に、アプリケーション・プログラム自身の起動に必要なキー数を代入してもらうため、パラメータ（NoOfKeys）をキー数決定部Ｃに渡す。
処理手順２：キーｙ数決定部Ｃは、データベースＤからデータを読み込み（処理手順７を参照）多項式関数を決定する。さらに、キー数決定関数Ｃは、必要なパラメータの値を調査してキー数を決定する。さらに、キー数決定関数Ｃは、アプリケーション・プログラムＢから渡されたパラメータに値を代入し、アプリケーション・プログラムＢに値とともに返す。
処理手順３：アプリケーション・プログラムＢは、ライセンス管理部Ａに必要なキー数をパラメータ（NoOfKeys）を渡すことにより通知し、ライセンスを要求する。
第１の実施形態で説明した処理手順４及び５は任意なのでここでは省略する。
処理手順６：ライセンス管理部Ａがキー数関数Ｃから正常フラグを受けると、ライセンス管理部Ａ自身に保持されているキー数から必要なキー数分を減らす。減算の結果、保持しているキー数が負にならなければ、ライセンス管理部Ａは、正常フラグをアプリケーション・プログラムＢに返すとともにライセンスを発給する。アプリケーション・プログラムＢはライセンスの発給を受けると、実行可能なアプリケーション・プログラムとなる。もし、ライセンス管理部Ａから異常フラグが返されたときは、アプリケーション・プログラムＢはその時点で終了する。
図９は本発明におけるライセンス管理システムの第４の実施形態としての基本構成図である。上記のように第２の実施形態では、キー数決定関数Ｃ’は関数コールとしてアプリケーション・プログラムＢに組み込まれている。本実施形態では、多項式関数を決定するデータベースＤ’は、キー数決定部Ｃに多項式関数を読み込ませるために別途に用意される。この場合、多項式関数を変更する際には、データベースＤ’が変更され、その結果、キー数決定関数Ｃ’での多項式関数の変更は不要となる。
処理手順１：アプリケーション・プログラムＢが起動された際に、アプリケーション・プログラム自身の起動に必要なキー数を受けるために、パラメータ（NoOfKeys）をキー数決定関数Ｃ’に渡す。
処理手順２：キー数決定部Ｃは、データベースＤ’からデータを読み込み（処理手順７を参照）、多項式関数を決定する。さらに、キー数決定関数Ｃ’は、必要なパラメータの値を調べてキー数を決定する。さらに、キー数決定関数Ｃ’は、アプリケーション・プログラムＢから渡されたパラメータ（NoOfKeys）に値を代入し、アプリケーション・プログラムＢに値とともに返す。
処理手順３：アプリケーション・プログラムＢは、ライセンス管理部Ａに必要なキー数を、パラメータ（NoOfKeys）を渡すことにより通知し、ライセンスを要求する。
第１の実施形態で説明した処理手順４及び５は任意なのでここでは省略する。
処理手順６：ライセンス管理部Ａは、アプリケーション・プログラムＢから要求を受けると、ライセンス管理部Ａ自身に保持されているキー数から必要なキー数分を減らす。減算の結果、保持しているキー数が負にならなければ、ライセンス管理部Ａは、正常フラグをアプリケーション・プログラムＢに返すとともにライセンスを発給する。アプリケーション・プログラムＢはライセンスの発給を受けると、実行可能なアプリケーション・プログラムとなる。もし、ライセンス管理部Ａから異常フラグが返されたときは、アプリケーション・プログラムＢはその時点で終了する。
次に、図６〜図９の処理手順を以降の図面にそってさらに詳しく説明する。以下の説明は、ライセンス管理部Ａとアプリケーション・プログラムＢの間の処理手順３及び６をさらに具体的に説明するものである。
ライセンス管理部Ａにおいて、従来は、１つのライセンスデーモン（デーモンプログラム）がそれぞれのアプリケーション・プログラムとやりとりを行う方法により、アプリケーション・プログラムの動作が正常に行われているか否か調査していた。
しかしながら、この方法では、ライセンスデーモンは各アプリケーション・プログラムとの間で多くの煩雑なやりとりが必要である。例えば、ライセンスデーモンが各アプリケーション・プログラムに所定項目を調査する調査要求を送り、各アプリケーション・プログラムはデーモンプログラムに調査要求に対する回答を戻す。この場合、回答が各アプリケーション・プログラムからデーモンプログラムに同時に戻されるので、多くの回答がライセンスデーモンにて待機状態となる。これはライセンスデーモンに多くの負荷が与えられるからである。その結果、ライセンスデーモンにおいて各回答に対する処理時間が遅延し、その結果ソフトウェアの性能も悪化する。
従って、本発明は、ライセンスデーモンにおける負担を低減し、それぞれのソフトウェア（即ち、アプリケーション・プログラム）における処理時間の遅延を除去することを目的とする。
上述の目的を達成するために、本発明では専用ライセンスデーモン（ＡＰＳＭ：Application Program Server Manager）と専用アプリケーション・マネージャ（ＡＰＣＭ：Application Program Client Manager）がライセンスデーモン及びアプリケーション・プログラムに追加して用意され、種々のやりとりが以下に詳細に説明するように専用ライセンスデーモン（ＡＰＳＭ）と専用アプリケーション・マネージャ（ＡＰＣＭ）の間で実行される。
図１０は、ライセンスデーモンとアプリケーション・プログラムとの間の起動処理の説明図である。ユーザがアプリケーション・プログラムの起動処理を実行すると、アプリケーション・プログラム（ＡＰ１）は、実行許可（ライセンス）を得るために、ライセンスデーモン（ＬＤＰ）に、申請（ＣＩＲ：Check-In Request）を送る。
図１１は、ライセンスデーモンにおけるフォーク処理の説明図である。ライセンスデーモン（ＬＤＰ）は、専用ライセンスデーモン（ＡＰＳＭ１）を設立するためにフォーク命令を発生する。専用ライセンスデーモン（ＡＰＳＭ１）は、アプリケーション・プログラム（ＡＰ１）に対して、実行許可（ＣＩＲＣ：Check-In Request Confirmation）を送り、ライセンスを発給する。この場合、以下の３つの状態が考えられる。
ａ）専用ライセンスデーモン（ＡＰＳＭ１）から実行許可（ＣＩＲＣ）が得られないときは、アプリケーション・プログラム（ＡＰ１）は処理を終了する。
ｂ）専用ライセンスデーモン（ＡＰＳＭ１）から実行許可（ＣＩＲＣ）は得られたが、「無効な」内容を含むものであれば、アプリケーション・プログラム（ＡＰ１）はユーザに「無効」を通知する。
ｃ）専用ライセンスデーモン（ＡＰＳＭ１）から実行許可（ＣＩＲＣ）が得られ、かつ「有効な」内容を含むときは、アプリケーション・プログラム（ＡＰ１）は専用アプリケーション・マネージャ（ＡＰＣＭ１）を設立するためにフォーク命令を発生する。
図１２は、アプリケーション・プログラムにおけるフォーク処理の説明図である。上記のｃ）項で説明したように、専用ライセンスデーモン（ＡＰＳＭ１）から実行許可（ＣＩＲＣ）が得られ、かつ「有効な」内容を含むときは、アプリケーション・プログラム（ＡＰ１）は専用アプリケーション・マネージャ（ＡＰＣＭ１）を設立するためにフォーク命令を発生する。この処理以降、ライセンス管理に関するやりとりは、専用ライセンスデーモン（ＡＰＳＭ１）と専用アプリケーション・マネージャ（ＡＰＣＭ１）との間で実行される。アプリケーション・プログラム（ＡＰ１）はそれ自身のプログラムの実行を開始する。
図１３は、アプリケーション・プログラムの終了処理の説明図である。ユーザがアプリケーション・プログラム（ＡＰ１）の終了処理を実行すると、アプリケーション・プログラム（ＡＰ１）は終了要求（ＳＩＧＵＳＲ２：ＵＮＩＸのシグナルの一種）を専用アプリケーション・マネージャ（ＡＰＣＭ１）に送り、アプリケーション・プログラム（ＡＰ１）は終了する。
図１４は、専用アプリケーション・マネージャからの強制終了の説明図である。アプリケーション・プログラム（ＡＰ１）が、終了要求（ＳＩＧＵＳＲ２）を送出した後に万一終了しない場合は、専用アプリケーション・マネージャ（ＡＰＣＭ１）は、パイプ（ＰＩＰＥ）に無効情報＋ｖｅ（正の値）を設定する。アプリケーション・プログラム（ＡＰ１）は無効情報＋ｖｅを読み込み、それ自身を終了する。
図１５は、アプリケーション・プログラムの終了報告の説明図である。アプリケーション・プログラム（ＡＰ１）が終了していれば、専用アプリケーション・マネージャ（ＡＰＣＭ１）は、アプリケーション・プログラム（ＡＰ１）の終了を示す終了報告（ＣＯＲＣ：Check-Out Request Confirmation）をライセンスデーモン（ＬＤＰ）に送り、専用アプリケーション・マネージャ（ＡＰＣＭ１）は終了する。
図１６は、専用ライセンスデーモンに対する終了処理の説明図である。最後に、ライセンスデーモン（ＬＤＰ）は、アプリケーション・プログラム（ＡＰ１）が終了した後にデータベースに情報を書き込み、専用アプリケーション・デーモン（ＡＰＳＭ１）自身が終了するように終了命令（ＳＩＧＫＩＬＬ：ＵＮＩＸのシグナル）を専用ライセンスデーモン（ＡＰＳＭ１）に発生する。
次に、専用ライセンスデーモンと専用アプリケーション・マネージャとの間のポーリング動作について説明する。専用ライセンスデーモンと専用アプリケーション・マネージャでは、これらの間で正常なやりとりが実行されているか否かを調べるために定期的なポーリングを行う。
図１７は、専用ライセンスデーモンからの調査要求の説明図である。専用ライセンスデーモン（ＡＰＳＭ１）は、専用アプリケーション・マネージャ（ＡＰＣＭ１）に対して、専用アプリケーション・マネージャ（ＡＰＣＭ１）が正常に動作しているか否かを調べるために、調査要求（ＡＰＰＲ：Application Program Poll Request）を、専用アプリケーション・マネージャ（ＡＰＣＭ１）にに送る。
図１８は、専用アプリケーション・マネージャからの正常通知の説明図である。専用アプリケーション・マネージャ（ＡＰＣＭ１）は、専用ライセンスデーモン（ＡＰＳＭ１）からの内容と専用アプリケーション・マネージャ（ＡＰＣＭ１）自身からの内容のチェックが成功すれば、正常通知（ＡＰＰＣ：application program poll confirmation）を専用ライセンス・デーモン（ＡＰＳＭ１）に送る。
図１９は専用ライセンスデーモンからの再起動処理の説明図である。専用ライセンスデーモン（ＡＰＳＭ１）が、専用アプリケーション・マネージャ（ＡＰＣＭ１）から異常応答を受けると（Heart Beat Message Exchange Fails）、専用ライセンスデーモン（ＡＰＳＭ１）はライセンスデーモン（ＬＤＰ）に命令（ＣＯＲＣ）を送り、それ自身を終了する。
図２０は、専用ライセンスデーモンにおけるライセンス解除処理の説明図である。ライセンスデーモン（ＬＤＰ）がアプリケーション・プログラム（ＡＰ１）を無効にし、アプリケーション・プログラム（ＡＰ１）に割り当てられたライセンスキーを解除する。
次に、専用アプリケーション・マネージャ（ＡＰＣＭ１）から専用ライセンスデーモン（ＡＰＳＭ１）へのポーリング動作について以下に説明する。
図２１は、専用アプリケーション・マネージャから専用ライセンスデーモンへの調査要求の説明図である。専用アプリケーション・マネージャ（ＡＰＣＭ１）は、専用ライセンスデーモン（ＡＰＳＭ１）へ調査要求（ＡＰＲＲ：Application Program Re-validation Request）を送る。
図２２は、専用ライセンスデーモンから専用アプリケーション・マネージャへの正常通知の説明図である。専用ライセンスデーモン（ＡＰＳＭ１）は、専用アプリケーション・マネージャ（ＡＰＣＭ１）からの内容と専用ライセンスデーモンそれ自身からの内容が成功すれば正常通知（ＡＰＲＣ：Application Program Re-validation Confirmation）を専用アプリケーション・マネージャ（ＡＰＣＭ１）に送る。
図２３は、専用アプリケーション・マネージャにおける無効情報の説明図である。専用アプリケーション・マネージャ（ＡＰＣＭ１）における内容と、専用ライセンスデーモン（ＡＰＳＭ１）における内容のチェックが成功しないときは、専用アプリケーション・マネージャ（ＡＰＣＭ１）はパイプに無効情報＋ｖｅ（正の値）を設定する。アプリケーション・プログラム（ＡＰ１）はこの無効情報を読んで自身を終了する。
図２４は、専用アプリケーション・マネージャにおける終了処理の説明図である。専用アプリケーション・マネージャ（ＡＰＣＭ１）は終了命令を親アプリケーション・プログラムに送った後に自身を終了する。
次に専用ライセンスデーモンの異常終了について説明する。
図２５は、専用ライセンスデーモンにおける再起動の説明図である。専用アプリケーション・マネージャ（ＡＰＣＭ１）が、専用ライセンスデーモン（ＡＰＳＭ１）の異常終了を検出すると、専用アプリケーション・マネージャ（ＡＰＣＭ１）は、専用ライセンスデーモン（ＡＰＳＭ１）を再起動させるために、要求（ＡＰＲＩＲ：Application Program Re-Initiation Confirmation）をライセンスデーモン（ＬＤＰ）に送る。
図２６は、ライセンスデーモンからの無効通知の説明図である。ライセンスデーモン（ＬＤＰ）は、専用ライセンスデーモン（ＡＰＳＭ１）が再起動要求を無効にしたことを検出したときは、ライセンスデーモン（ＬＤＰ）は、専用ライセンスデーモン（ＡＰＳＭ１）が再起動しなかったことを示す通知（ＡＰＲＩＣ：Application Program Re-Initiation Confirmation）を、専用アプリケーション・マネージャ（ＡＰＣＭ１）に送る。さらに、専用アプリケーション・マネージャ（ＡＰＣＭ１）は自身を終了し、そしてアプリケーション・プログラム（ＡＰ１）は終了する。
図２７は、ライセンスデーモンからの再起動通知の説明図である。ライセンスデーモン（ＬＤＰ）は、専用ライセンスデーモン（ＡＰＳＭ１）が再起動要求を有効にしたことを検出したときは、ライセンスデーモン（ＬＤＰ）は、フォーク命令に基づいて新専用ライセンスデーモン（ＡＰＳＭ１’）を提供する。新専用ライセンスデーモン（ＡＰＳＭ１’）はデータベースを更新し、専用ライセンスデーモンが再起動したことを示す通知（ＡＰＲＩＣ）を専用アプリケーション・マネージャ（ＡＰＣＭ１）に送る。
図２８は、専用ライセンデーモンからライセンスデーモンへのポーリングの説明図である。専用ライセンスデーモン（ＡＰＳＭ１）はライセンスデーモン（ＬＤＰ）を定期的にポーリングする。もし、専用ライセンスデーモン（ＡＰＳＭ１）が、ライセンスデーモン（ＬＤＰ）のエクジット（ＥＸＩＴ）を見つけたならば（ステップ１）、専用ライセンスデーモン（ＡＰＳＭ１）自身は終了する（ステップ２）。従って、アプリケーション・プログラム（ＡＰ１）の正常動作は、専用アプリケーション・マネージャ（ＡＰＣＭ１）により中断され（ステップ３）、専用アプリケーション・マネージャ（ＡＰＣＭ１）は通知（ＡＰＲＩＲ）をライセンスデーモン（ＬＤＰ）に送る試みをループ（loop）する（ステップ４）。
図２９は、ライセンスデーモンの終了の説明図である。ライセンスデーモン（ＬＤＰ）はシステム管理部からのリクエストにより終了する。終了モードには２つある。即ち、通常終了（ＴＲ１）と他の終了（ＴＲ２）である。ライセンスデーモン（ＬＤＰ）は、終了要求（ＴＲ２）を受けた後に、ライセンスキーを持っている有効なアプリケーション・プログラム（ＡＰ１）を調査し、終了命令（ＳＤＣ：Shut Down Command）を専用アプリケーション・マネージャ（ＡＰＣＭ１）に送る（ステップ１）。
専用アプリケーション・マネージャ（ＡＰＣＭ１）は専用ライセンスデーモン（ＡＰＳＭ１）から終了命令（ＳＤＣ）を受けると、専用アプリケーション・マネージャ（ＡＰＣＭ１）はこれを優先的メッセージとして扱い、直ちにそれ自身の終了を決定する。専用アプリケーション・マネージャ（ＡＰＣＭ１）は、アプリケーション・プログラム（ＡＰ１）の終了前に専用アプリケーション・プログラム（ＡＰＣＭ１）に命令（ＳＩＧＵＳＲ２：ＵＮＩＸのシグナルの一種）を確実に送るようにアプリケーション・プログラム（ＡＰ１）を強制する（ステップ２）。専用アプリケーション・プログラム（ＡＰＣＭ１）は、アプリケーション・プログラム（ＡＰ１）から命令（ＳＩＧＵＳＲ２）を受けた後に、図１３乃至図１６に示す処理に従って正常終了を実行する。
図３０は、ライセンスデーモンにおける終了処理の説明図である。専用アプリケーション・マネージャ（ＡＰＣＭ１）が図２９に示す所定の処理時間内にアプリケーション・プログラム（ＡＰ１）から命令（ＳＩＧＵＳＲ２）を受け取らないときは、専用アプリケーション・マネージャ（ＡＰＣＭ１）はシグナル（ＳＩＧＫＩＬＬ）をアプリケーション・プログラム（ＡＰ１）に送り（ステップ１）、アプリケーション・プログラム（ＡＰ１）は終了する（ステップ２）。
専用アプリケーション・マネージャ（ＡＰＣＭ１）は所定時間の後に、自身を終了し（ステップ３）、命令（ＣＯＲＣ）を使用するライセンスデーモン（ＬＤＰ）にこの終了を通知する（ステップ４）。この場合、ライセンスデーモン（ＬＤＰ）は所定の時間の間、専用アプリケーション・マネージャ（ＡＰＣＭ１）からの命令（ＣＯＲＣ）を待つ。もしライセンスデーモン（ＬＤＰ）が専用アプリケーション・マネージャ（ＡＰＣＭ１）から命令（ＣＯＲＣ）を受け取っていなければ、ライセンスデーモン（ＬＤＰ）は専用ライセンスデーモン（ＡＰＳＭ１）を終了させる（ステップ５）。
図３１は、ライセンスデーモンにおける異常終了の説明図である。ライセンスデーモン（ＬＤＰ）が異常終了したとき、専用アプリケーション・マネージャ（ＡＰＣＭ１）はアプリケーション・プログラム（ＡＰ１）における通常動作を中断させ（ステップ１）、それ自身も中断する（ステップ２）。ライセンスデーモン（ＬＤＰ）が異常終了した後、再起動すると、ライセンスデーモン（ＬＤＰ）は、専用ライセンスデーモン（ＡＰＳＭ１）が異常終了後に終了したかを調査する（ステップ３）。
ライセンスデーモン（ＬＤＰ）は、専用アプリケーション・マネージャ（ＡＰＣＭ１）にて命令（ＡＰＲＩＲ）のペンディング状態を調査する。もし、命令（ＡＰＲＩＲ）が専用アプリケーション・マネージャ（ＡＰＣＭ１）にてペンディングであれば、ライセンスデーモン（ＬＤＰ）は専用アプリケーション・マネージャ（ＡＰＣＭ１）から命令（ＡＰＲＩＲ）を受け入れる（ステップ４）。専用ライセンスデーモン（ＡＰＳＭ１’）は、ライセンスデーモン（ＬＤＰ）が専用アプリケーション・マネージャ（ＡＰＣＭ１）から命令（ＡＰＲＩＲ）を受け入れた時のみリカバーする（ステップ５）。ライセンスデーモン（ＬＤＰ）は通常動作を開始する。
図３２は、アプリケーション・プログラムにおける異常終了の説明図である。もし、アプリケーション・プログラム（ＡＰ１）が専用アプリケーション・マネージャ（ＡＰＣＭ１）に命令（ＳＩＧＵＳＲ２）を送らずに終了した時は、専用アプリケーション・マネージャ（ＡＰＣＭ１）は専用ライセンスデーモン（ＡＰＳＭ１）へ命令（ＡＰＲＲ）を送り（ステップ１）、アプリケーション・プログラム（ＡＰ１）の存在を調べる（ポーリングする）（ステップ２）。もし専用アプリケーション・マネージャ（ＡＰＣＭ１）が、アプリケーション・プログラム（ＡＰ１）が専用アプリケーション・マネージャ（ＡＰＣＭ１）に知らせずに終了したのを見つけたならば、専用アプリケーション・マネージャ（ＡＰＣＭ１）はライセンスデーモン（ＬＤＰ）に命令（ＣＯＲＣ）を送る（ステップ３）。
図３３は、専用ライセンスデーモンと専用アプリケーション・マネージャの異常終了の説明図である。専用アプリケーション・マネージャ（ＡＰＣＭ１）が終了した後（ステップ１）、アプリケーション・プログラム（ＡＰ１）は、アプリケーション・プログラム（ＡＰ１）と専用アプリケーション・マネージャ（ＡＰＣＭ１）との間に設けられたパイプの情報＋ｖｅ（正の値）を調査した後に終了する（ステップ２）。ライセンスデーモン（ＬＤＰ）は専用ライセンスデーモン（ＡＰＳＭ１）からシグナル（ＳＩＧＣＬＤ）を受けて（ステップ３）、アプリケーション・プログラム（ＡＰ１）へライセンスキーを解除する。
図３４は、アプリケーション・プログラムと専用アプリケーション・マネージャが共に異常終了する場合の説明図である。専用アプリケーション・プログラム（ＡＰ１）と専用アプリケーション・マネージャ（ＡＰＣＭ１）が共にライセンスデーモン（ＬＤＰ）か専用ライセンスデーモン（ＡＰＳＭ１）のどちらかに知らせずに異常終了した時（ステップ１）、専用ライセンスデーモン（ＡＰＳＭ１）は要求（ＡＰＰＲ：Application Program Poll Request）に対する確認（ＡＰＰＣ：Application Program Poll Confirmation）を取得しない（ステップ２）。
専用ライセンスデーモン（ＡＰＳＭ１）は専用アプリケーション・マネージャ（ＡＰＣＭ１）の終了を見つけた後（ステップ４）、専用ライセンスデーモン（ＡＰＳＭ１）はアプリケーション・プログラム（ＡＰ１）の存在を調査する．もしアプリケーション・プログラム（ＡＰ１）が存在するならば、専用ライセンスデーモン（ＡＰＳＭ１）は、ポーリングを通してアプリケーション・プログラム（ＡＰ１）の終了を待つ（ステップ６）。その後、専用ライセンスデーモン（ＡＰＳＭ１）は命令（ＣＯＲＣ）を使用してライセンスデーモン（ＬＤＰ）に通知する。ライセンスデーモン（ＬＤＰ）はアプリケーション・プログラム（ＡＰ１）に割り当てられたライセンスキーを解除する。
図３５は、アプリケーション・プログラムと専用ライセンスデーモンが共に異常終了する場合の説明図である。アプリケーション・プログラム（ＡＰ１）が異常終了した時（ステップ１）、専用アプリケーション・マネージャ（ＡＰＣＭ１）はこの異常終了を検出し（ステップ２）、ライセンスデーモン（ＬＤＰ）に確認（ＣＯＲＣ）を送る（ステップ３）。ライセンスデーモン（ＬＤＰ）はアプリケーション・プログラム（ＡＰ１）に保持されていた全ライセンスキーを解除し、専用ライセンスデーモン（ＡＰＳＭ１）を終了する（ステップ４）。もし専用ライセンスデーモン（ＡＰＳＭ１９が既に終了していても、この場合の問題はない。
図３６は、ライセンスデーモンと専用ライセンスデーモンが共に異常終了する場合の説明図である。ライセンスデーモン（ＬＤＰ）と専用ライセンスデーモン（ＡＰＳＭ１）の終了には次の２つの場合がある。
１）ライセンスデーモン（ＬＤＰ）と専用ライセンスデーモン（ＡＰＳＭ１）が共にシグナル（ＳＩＧＫＩＬＬ）によりキル（ｋｉｌｌ）される。
２）ライセンスデーモン（ＬＤＰ）が異常キルされ、専用ライセンスデーモン（ＡＰＳＭ１）がライセンスデーモン（ＬＤＰ）を調査する。専用ライセンスデーモン（ＡＰＳＭ１）は、ライセンスデーモン（ＬＤＰ）が終了してエクジット（ＥＸＩＴ）を実行したのを見つけた時、専用ライセンスデーモン（ＡＰＳＭ１）は自身をキルする。
このような状況のもとで、専用アプリケーション・マネージャ（ＡＰＣＭ１）は、アプリケーション・プログラム（ＡＰ１）と専用アプリケーション・マネージャ（ＡＰＣＭ１）の間に設けられたパイプに情報−ｖｅ（負の値）を設定した後、アプリケーション・プログラム（ＡＰ１）を中断し（ステップ１）、要求（ＡＰＲＩＲ）をライセンスデーモン（ＬＤＰ）に送る（ステップ２）。
図３７は、ライセンスデーモン（ＬＤＰ）が図３６で説明した状況の後に再起動する場合の説明図である。ライセンスデーモン（ＬＤＰ）が再起動すると、ライセンスデーモン（ＬＤＰ）は要求（ＡＰＲＩＲ）を認識し（ステップ１）、専用アプリケーション・マネージャ（ＡＰＣＭ１）とやりとりするために新専用ライセンスデーモン（ＡＰＳＭ１’）をリカバーする。
図３８は、システム構成の説明図である。図示のように、例えば、１つのライセンスデーモン（ＬＤＰ）は２つのグループＩ及びIIを設立することができ、各々は、アプリケーション・プログラム（ＡＰ）、専用アプリケーション・マネージャ（ＡＰＣＭ）、及び専用ライセンスデーモン（ＡＰＳＭ）を含む。このような構成により、ライセンスデーモン（ＬＤＰ）の負担を低減することができる。その結果、ソフトウェアの処理時間の遅延を除去することができる。
次に、本発明によるキー数の具体的な決定方法を説明する。
図３９は、ライセンス数（キー数）の決定フローチャートである。さらに、図４０（Ａ）乃至図４０（Ｉ）はキー数を決定するための実際の関数のリストであり、図４１（Ａ）乃至図４１（Ｆ）はサンプルプログラムの説明図であり、図４２（Ａ）乃至図４２（Ｃ）はサンプルプログラムの実行結果の説明図である。
図４０（Ａ）乃至図４０（Ｉ）に示した関数を使用する実際のプログラムは、所定のファイルを処理するものである。このプログラムにおいて、以下の項目、例えば、処理対象となるファイルサイズ、プラットフォーム、ＣＰＵの数、メモリの容量、等が考慮される。この考慮に基づいて、このプログラムは、複数のプロセスを自動的に並列に起動してプログラムの高速処理が実現できるように設計されている。従って、並列起動されるプロセス数に従ってキー数を増減する必要がある。
キー数を決定する実際の関数について、以下に詳細に説明する。
図４０（Ａ）乃至図４０（Ｉ）において、第１の関数“GetSystemParameters”は、５つのパラメータ、即ち、ＣＰＵの数（Ncpu）、メモリのページサイズ（Psize）、全物理的メモリ容量のページ数（PhyPage）、空きメモリ容量のページ数（AvPage）、プラットフォーム（Platform）、を取得する。これらのパラメータは、第２の関数“DetermineNumberOfLicense”に渡される。
第２の関数“DetemineNumberOfLicense”は、第１の関数“GetSystemParameters”からのパラメータとファイルのサイズを受け、並列処理の数を決定する。同時に、第２の関数“DetermineNumberOfLicense”は、必要なキー数を決定し、戻り値（return value）として返す。
まず、第１の関数“GetSystemParameters”を第１ブロック（５３〜６８行）及び第２ブロック（７１〜８９行）について説明する。
第１のブロック（５３〜６８行）に関して、第１の関数“GetSystemParameters”は、以下のパラメータ、即ち、ＣＰＵの数（sysconf（＿SC＿NPROCESSORS ＿ ONLN））、メモリのページサイズ（sysconf（＿SC＿PAGESIZE））、全物理的メモリ容量のページ数（sysconf（＿SC＿PHYS＿PAGES））、空きメモリ容量のページ数（sysconf（＿SC＿AVPHYS＿PAGES））を取得し、どれか１つでもエラーであった場合には処理を中断する。
次に、第２ブロック（７１〜８９行）に関して、第２の関数“DetermineNumberOfLicense”は、プラットフォーム（PLATFORM）を取得する。もしプラットフォームにエラーがあれば処理は中断される。第１の関数“GetSystemParameters”が全てのパラメータを正常に取得できた時は、各パラメータの値、即ち、ＣＰＵの数（Ncpu）、メモリのページ数（Psize）、全物理的メモリ容量のページ数（PhyPage）、空きメモリ容量のページ数（AvPage）を定められた変数に代入する。
次に、図３９及び図４０（Ｆ）乃至図４０（Ｉ）を参照して第２の関数“DetemineNumberOfLicense”を詳細に説明する。
第１ブロック（１２５〜１３４行）に関して、渡される引数が正常か否かチェックを行う。もし引数が異常ならば、処理は中断される。もし引数が正常ならば、ライセンス数（キー数）はデフォルト値（NL=NL＿DEFAULT）にセットされる（１２６行目の（１）参照）。
第２ブロック（１３８〜１４７行）に関して、もし、自身のハードウェアのＣＰＵ数が１つか、又はスパークサーバ（ＳＰＡＲＣｓｅｒｖｅｒ）ではない場合は、並列処理は行えないと決定する。この場合、プロセス数は１、キー数はデフォルト値と決定される。そして、処理はこの関数内で終了する。もし、ＣＰＵ数が２又はそれ以上のスパークサーバのときは、ライセンス数（キー数）はデフォルト値の２倍（NL=NL＿DEFAULT+NL＿DEFAULT）にセットされる（１３９行目の（２）参照）。
第３ブロック（１５０〜１５７行）に関して、与えられたファイルサイズがメモリページ数に換算される（１５０行目の（３）参照）。
第４ブロック（１６０〜１８１行）に関して、並列処理（特化したプログラム）を行うべきか否か決め、並列プロセス数とキー数を決める。
１６３〜１６６行に関して、もし、値（ファイルサイズ＊NL＿ MEM＿ FACTOR）（注，＊＝×）が空きメモリ容量よりも大きい場合には、並列処理をしても意味がない（実験によれば、高速処理が得られないことは明らかである。）。従って、単一処理が実行され、キー数はデフォルト値（NL=2）に決定される。
１６７〜１８１行に関して、もし、値（ファイルサイズ＊NL＿MEM ＿FACTOR）が空きメモリ容量よりも小さい場合には、次の３通りの場合に分ける。
１）：１６７〜１７１行に関して、もし、値（ファイルサイズ＊NL＿MEM ＿FACTOR）が１０⁶バイトより小さいとき、並列処理をしても意味がない（上述のように、実験によれば、高速処理が得られないことは明らかである。）。従って、単一処理が実行され、キー数は、デフォルト数＊プロセス数、によって決定される。
２）：１７２〜１７６行に関して、もし、値（ファイルサイズ＊NL＿ MEM＿ FACTOR）が、１０⁶バイト以上で２＊１０⁶バイト以下のときは、２並列（２プロセス）処理が実行され、キー数はデフォルト＊プロセス数によって決定される。
３）：１７７〜１８１行に関して、もし値（ファイルサイズ＊NL＿ MEM＿ FACTOR）が、２＊１０⁶バイトより大きいときは、並列処理の数は、値（ＣＰＵ数−１）に基づいて実行され、キー数はデフォルト＊プロセス数によって決定される。
次に、図４１（Ａ）乃至図４１（Ｆ）のサンプルプログラムについて説明する。
このサンプルプログラムは、関数“GetSystemParameters”を用いてハードウェアの情報、即ち、プラットフォーム、ＣＰＵの数、メモリのページサイズ、全物理的メモリ容量のページ数、及び空きメモリ容量のページ数、を取得する。この結果はスクリーンに表示される。さらに、関数“DetermineNumberOfLicense”を用いて１２種類のファイルサイズに対するプロセス数とキー数をスクリーンに表示する。
以下に、図４１（Ａ）乃至図４１（Ｆ）に示すサンプルプログラムを詳細に説明する。
第１ブロック（５４〜６２行）に関して、最初に、変数の初期化（リセット）を行う。ハードウェアの情報、即ち、ＣＰＵの数（Ncpu）、メモリのページサイズ（Psize）、全物理的メモリ容量のページ数（PhyPage）、及び空きメモリ容量のページ数（AvPage）、に「０」を代入する。さらに、プラットフォーム（Platform）にはヌル（Null）を代入する。
第２ブロック（６５〜８１行）に関して、実際のハードウェアの数、即ち、ＣＰＵの数（Ncpu）、メモリのページサイズ（Psize）、全物理的メモリ容量のページ数（PhyPage）、及び空きメモリ容量のページ数（AvPage）、が決定され、スクリーンに表示される。
第３ブロック（８５〜１０３行）に関して、１２種類のファイルサイズについて、上述により取得したハードウェアの情報に基づいて、並列処理の数（プロセス数）及びキー数が決定される。決定したプロセス数とキー数はスクリーンに表示される。
次に、図４２（Ａ）乃至図４２（Ｃ）を参照してサンプルプログラムの実行結果を説明する。
サンプルプログラムを“Ｓｏｌａｒｉｓ２．５”（ＯＳ）を搭載した２種類のワークステーション（モデル名：Ｓ−４／１，Ｓ−４／１０００）で実行した結果を示す。
図４２（Ａ）において、サンプルプログラムは、プラットフォームとしてＳ−４／１上で実行された。この場合、ＣＰＵ数は１つであるから、ファイルサイズによらず、キー数は常に１つである。
図４２（Ｂ）において、サンプルプログラムは、プラットフォームとしてＳ−４／１０００上で実行された。この場合、ＣＰＵを４つ持つスパークサーバを使用し、ファイルサイズに従って並列処理の数とキー数が相違する。
図４２（Ｃ）において、サンプルプログラムは、プラットフォームとしてＳ−４／１０００上で実行された。この場合、ＣＰＵを４つ持つスパークサーバを使用した。空きメモリ容量のページ数（AvPage）が小さいので、並列処理を行われない。従って、キー数は全て２つである。
上述の説明で明らかなように、基本的に、キー数決定関数は、以下の項目を満たすように作成されている。
第１に、ＣＰＵの性能を予め調べておく。ＣＰＵが高い性能を持つときは、多くのキー数を提供する必要がある。
第２に、空きメモリ容量とファイルサイズを互いに比較する。並列処理を実行すべき場合には、多くのキー数を提供する必要がある。
第３に、もし考慮すべきパラメータが他にある場合は、上述に類似の関数を作成することにより、キー数を変更することができる。
産業上の利用可能性
以上説明したように、本発明によれば、ソフトウェアメーカーとユーザの両方に存在する従来の多くの問題を解消することができる。従って、ソフトウェアメーカーは、多大な費用を要して開発したソフトウェアをユーザに適切な価格で発給するために、常に最適なライセンス管理を探究し開発する。その結果、本発明によるライセンス管理システムは、販売戦略が十分に考慮されライセンスの発給を提供することができ、従って、本発明は非常に高い産業上の利用可能性を有する。

Claims (12)

1. 単一もしくは複数のコンピュータを駆動するソフトウェアのライセンス管理システムであって、
   自身を駆動するために必要なキー数の決定を要求し、ライセンスの発給を受けるアプリケーション・プログラムと、
   前記アプリケーション・プログラムからの要求に応じて必要な前記キー数を決定するキー数決定手段と、
   前記キー数決定手段にて決定された前記キー数を発給するライセンス管理手段と、
   を具備し、
   前記キー数決定手段は、ＬＫを前記キー数、ｘ１〜ｘ５をそれぞれ前記キー数の決定に必要なパラメータである、前記アプリケーション・プログラムが動作するコンピュータのプラットフォームの種類、ＣＰＵの数、ＣＰＵの処理能力、メモリ容量、および処理されるデータファイルのサイズ、としたとき、以下の多項式関数、
   ＬＫ＝ｆ（ｘ１，ｘ２，ｘ３，ｘ４，ｘ５）
   に基づき必要な前記キー数を決定する手段と、アプリケーション・プログラムが起動された際に、前記キー数を決定するための必要なパラメータ値をデータベースから取得する手段と、を有するライセンス管理システム。
2. 前記ライセンス管理手段は、前記キー数が正しいときは前記ライセンス管理手段に保持されている前記キー数から必要な前記キー数を減らし、保持されている前記キー数が負にならないときはアプリケーション・プログラムに対してライセンスを発給する手段を有する請求項１に記載のライセンス管理システム。
3. 前記キー数決定手段は、デーモンプログラムである請求項１に記載のライセンス管理システム。
4. 多項式関数を決定するデータベースを備え、前記多項式関数は前記キー数決定手段にて前記多項式関数を変更することなく、前記データベースにて変更される請求項１に記載のライセンス管理システム。
5. 単一もしくは複数のコンピュータを駆動するソフトウェアのライセンス管理システムであって、
   自身を駆動するために必要なキー数の決定を要求し、ライセンスの発給を受けるアプリケーション・プログラムと、
   前記アプリケーション・プログラムに組み込まれ、前記アプリケーション・プログラムからの要求に応じて必要な前記キー数を決定するキー数決定関数と、
   前記キー数決定関数にて決定された前記キー数を発給するライセンス管理手段と、
   を具備し、
   前記キー数決定関数は、ＬＫを前記キー数、ｘ１〜ｘ５をそれぞれ前記キー数の決定に必要なパラメータである、前記アプリケーション・プログラムが動作するコンピュータのプラットフォームの種類、ＣＰＵの数、ＣＰＵの処理能力、メモリ容量、および処理されるデータファイルのサイズ、としたとき、以下の多項式関数、
   ＬＫ＝ｆ（ｘ１，ｘ２，ｘ３，ｘ４，ｘ５）
   に基づき必要な前記キー数を決定する手段と、アプリケーション・プログラムが起動された際に、前記キー数を決定するために必要なパラメータ値をデータベースから取得する手段と、を有するライセンス管理システム。
6. 前記キー数決定関数は、前記アプリケーション・プログラムに組み込まれた関数コールである請求項５に記載のライセンス管理システム。
7. 前記ライセンス管理手段は、前記キー数が正しいときは前記ライセンス管理手段で保持されている前記キー数から必要な前記キー数を減らし、保持されている前記キー数が負にならないときはアプリケーション・プログラムに対してライセンスを発給する手段を有する請求項５に記載のライセンス管理システム。
8. 多項式関数を決定するデータベースを備え、前記多項式関数は前記キー数決定関数にて前記多項式関数を変更することなく、前記データベースにて変更される請求項５に記載のライセンス管理システム。
9. 前記ライセンス管理手段のライセンスデーモンとは別個に設けられた専用ライセンスデーモンと、前記アプリケーション・プログラムとは別個に設けられた専用アプリケーション・マネージャとを備え、前記専用ライセンスデーモンと専用アプリケーション・マネージャとの間でやりとりを行う請求項１又は５に記載のライセンス管理システム。
10. 複数の前記専用ライセンスデーモンと前記専用アプリケーション・マネージャの組が１つのライセンスデーモンに対して確立される請求項９に記載のライセンス管理システム。
11. 前記アプリケーション・プログラムは、前記コンピュータ上において並列に起動することができるプロセスの数を決定し、
    前記キー数決定手段は、前記並列処理の数に基づいて前記キー数を決定し、
    前記ライセンス管理手段は、前記キー数決定手段にて決定された複数の前記キー数を発給する請求項１に記載のライセンス管理システム。
12. 前記アプリケーション・プログラムは、前記コンピュータ上において並列に起動することができるプロセスの数を決定し、
    前記キー数決定関数は、前記並列処理の数に基づいて前記キー数を決定し、
    前記ライセンス管理手段は、前記キー数決定関数にて決定された複数の前記キー数を発給する請求項５に記載のライセンス管理システム。

Images