(57)【要約】分散ライセンス管理のための技術を提供する。三つ以上のサービスもしくはサーバは、第一、第二、および第三ライセンスサービスを構築するために、お互いに協働しやり取りを行う。最初に、第一ライセンスサービスがマスターライセンスサービスとして指定され、ネットワーク上の複数のユーザーのためのライセンスを管理する。もし第一ライセンスサービスが、設定可能な時間内に、第二および第三ライセンスサービス両方に応答できなかった場合は、第二ライセンスサービスが、ライセンス管理を目的として、マスターライセンスサービスの役割を動的に担う。【選択図】図２
2008539518.tif 000002
【特許請求の範囲】
【請求項１】
第一ライセンスサーバと、
第二ライセンスサーバと、
第三ライセンスサーバ
を含むシステムであり、ここで、
前記第一ライセンスサーバがネットワーク上の複数のユーザーのためのライセンスを動的に管理し、
前記第一ライセンスサーバが、前記第二ライセンスサーバおよび前記第三ライセンスサーバと一定間隔で継続的に通信し、
前記第一ライセンスサーバが、前記ライセンスのためのマスターライセンスサーバとして指定され、
もし前記第一ライセンスサーバが前記一定間隔の所定回数の反復処理内に応答しない場合、ならびに、もし前記第一ライセンスサーバの前記非応答性が、前記第二ライセンスサーバにより作られたアサーションから独立した前記第三ライセンスサーバによって確認された場合、前記第二ライセンスサーバが前記マスターライセンスサーバとなるように設定される
ことを特徴とするシステム。
【請求項２】
請求項１のシステムであり、
前記第一ライセンスサーバが、前記所定回数の反復処理に応答しないとき、
前記第二ライセンスサーバが、前記マスターライセンスサーバとなるよう、前記第三ライセンスサーバと自動的且つ動的にやり取りを行う
ことを特徴とするシステム。
【請求項３】
請求項１のシステムであり、
もし前記第二ライセンスサーバが前記マスターライセンスサーバとなった際に、
前記第一ライセンスサーバが、前記第二ライセンスサーバおよび前記第三ライセンスサーバの少なくとも一方と再通信を始めた時点で、
前記第二ライセンスサーバが前記マスターライセンスサーバとしての指定を自動的に放棄し、前記第一ラインセンスサーバに返す
ことを特徴とするシステム。
【請求項４】
請求項１のシステムであり、前記所定回数の反復処理が、前記第一ライセンスサーバ、前記第二ライセンスサーバ、および前記第三ライセンスサーバに与えられる動的設定パラメータであることを特徴とするシステム。
【請求項５】
請求項４のシステムであり、前記所定回数の反復処理が設定可能であり、また設定可能な期間において前記一定間隔であることを特徴とするシステム。
【請求項６】
請求項１のシステムであり、ここで、
前記第一ライセンスサーバの、前記第二ライセンスサーバおよび前記第三ライセンスサーバとの通信が、前記複数のユーザーのためのライセンス状態情報を含み、また、
もし前記第二ライセンスサーバが前記マスターライセンスサーバとなる場合、前記状態情報が処理されて、前記第一ライセンスサーバの最後の良好な通信の間に存在していた、前記第二ライセンスサーバ上の前記ライセンスの状態が再構築される
ことを特徴とするシステム。
【請求項７】
ネットワーク上の三つの個別のマシンから、第一ライセンスサービス、第二ライセンスサービス、ならびに第三ライセンスサービスを決定および指定することと、
ネットワーク上の複数のユーザーのためのライセンスを、マスターライセンスサービスを介して管理し、ここで前記第一ライセンスサービスが最初に前記マスターライセンスサービスとして指定されることと、
前記第一ライセンスサービスが応答不能であることが、前記第二ライセンスサービスと前記第三ライセンスサービス両方から検出されることと、
前記第二ライセンスサービスを前記マスターライセンスサービスとして動的に再指定すること
を含む方法
【請求項８】
請求項７の方法であり、さらに、
前記複数のユーザーに対して前記ライセンスの状態を維持し、
前記第二ライセンスサービスが前記マスターライセンスサービスとして再指定されたとき、前記第二ライセンスサービス上の前記状態を再構築すること
を含む方法。
【請求項９】
請求項８の方法であり、さらに、
前記第一サービスが応答可能であったとき、前記第一ライセンスサービスから受信された最新のハートビート通信から前記状態を取得することと、
前記第一サービスによって記録された記憶場所から前記状態を取得し、ここで前記記憶場所は前記第一サービスに付随するマシンから独立していること
のうちの少なくとも一つを含む方法。
【請求項１０】
請求項７の方法であり、前記第一ライセンスサービス、前記第二ライセンスサービス、および前記第三ライセンスサービスの間でハートビート信号を一定間隔で通信することをさらに含む方法。
【請求項１１】
請求項１０の方法であり、ここで検出がさらに、
前記第一ライセンスサービスが、所定の経過時間内に前記ハートビート信号を一つも送信しないということが、前記第二ライセンスサービスと前記第三ライセンスサービス両方によって確認されることを含む
ことを特徴とする方法。
【請求項１２】
請求項７の方法であり、さらに、
前記第一ライセンスサービスが、前記第二ライセンスサービスまたは前記第三ライセンスサービスとの通信を再構築したとき、
前記第二ライセンスサービスが前記マスターライセンスサービスとしての指定を放棄すること
を含む方法。
【請求項１３】
請求項７の方法であり、ここで決定がさらに、
前記第一サービス、前記第二サービス、ならびに前記第三サービスの指定を、前記ライセンスに列挙された各マシンの順番から特定することを含む
ことを特徴とする方法。
【請求項１４】
請求項７の方法であり、ここで前記ライセンスの管理がさらに、
前記ライセンスに関する複数のアプリケーションインスタンスに複数のキーを配布し、
ここで前記複数のアプリケーションインスタンスが前記ネットワーク上に存在し、且つ前記複数のユーザーに付随する複数のマシン上で実行されることと、
前記複数のキーが前記複数のアプリケーションインスタンスに、前記複数のユーザーのために適切に作動することを許可すること
を含む
ことを特徴とする方法。
【請求項１５】
マシンがアクセス可能であり命令を有するメディアであって、マシンにアクセスされた際に前記命令が、
三個よりも多いマシンのうちの三個のマシンのクォーラムを取り決めることと、
前記クォーラムの各メンバーに役割を割り当てることと、
ここで、前記複数のマシンのうちから一つを選択する際のマスターライセンスサービスの役割指定が、前記複数のマシンのどれが顧客のためにネットワーク上のライセンス管理に責任を負うかをあらわす、ということと、
前記ライセンスが現在のマスターライセンスサービスによって管理されている間に、前記マシン間でハートビート信号を一定間隔で通信することと、
もし前記現在のマスターライセンスサービスが、設定可能な経過時間の期間内に、前記ハートビート信号を一つも通信できなかった場合、前記複数のマシンのうちの別の一つを、前記マスターライセンスサービスとして動的に再指定すること
を行う方法を実行する
ことを特徴とするメディア。
【請求項１６】
請求項１５のマシンがアクセス可能なメディアであり、
前記ライセンスが管理されている間に、前記ライセンスを消費している前記顧客の識別子を維持するための命令を、さらに含むメディア。
【請求項１７】
請求項１６のマシンがアクセス可能なメディアであり、
前記マスターライセンスサービスが再指定されたときに、前記ネットワーク上の前記顧客識別子に対し、前記ライセンスのためのキーを自動的に再配布するための命令を、さらに含むメディア。
【請求項１８】
請求項１５のマシンがアクセス可能なメディアであり、
もし前記複数のマシンのうちの少なくとも一つが、まだ前記現在のマスターライセンスサービスと良好に通信している場合、前記再指定を実行する要求を拒否するための命令を、さらに含むメディア。
【請求項１９】
請求項１５のマシンがアクセス可能なメディアであり、
起動の間に前記複数のマシンのそれぞれに与えられる設定パラメータに応じて、前記複数のマシンのそれぞれにおいて前記設定可能な経過時間を個別に決定するための命令を、さらに含むメディア。
【請求項２０】
請求項１９のマシンがアクセス可能なメディアであって、
前記複数のマシンのそれぞれにおいて実行されるサービス内で維持される上限および下限に対して、前記設定可能な経過時間を比較するための命令であり、
ここで前記複数のマシンが、前記設定可能な経過時間が前記下限を下回ること、あるいは前記上限を超えることを許可しないことを特徴とする命令を、
さらに含むメディア。
【発明の詳細な説明】
【技術分野】
【０００１】
［優先権主張］本特許出願は、2005年4月28日に出願された米国特許出願第11/118,946号、名称「分散ライセンス管理」の優先権を、本明細書において米国特許法第120条、あるいは第365条(c)項に基づいて主張し、その全内容を参照として本明細書に引用する。
［技術分野］本発明は、一般にソフトウェアライセンスに関し、さらに具体的にはソフトウェアライセンスの分散管理のための技術に関する。
【背景技術】
【０００２】
ソフトベンダーは、自社のソフトウェアライセンスを行使および監視するために絶え間ない努力を続けている。ソフトウェアライセンスの維持と行使は、ベンダーが権利を有する自社ソフトウェア製品の利益を享受することを保証し、ソフトウェア製品の保全性が侵害されないことを正当に保証し、ソフトウェア製品に関連する知的所有権が保護されることを正当に保証する。ベンダーは自社のソフトウェアライセンスの管理に著しい時間と努力を注ぎ込んでいる。
【０００３】
同時に、ベンダーはライセンスの行使を保証しようとするがあまりに、あまりにも制限的になったり、あるいは不合理になり過ぎることはできない。言い換えれば、もしライセンスに関する条件と環境が、顧客（customer）の環境にとって不合理、もしくは非実用的であれば、実施権者もしくは顧客は他の製品の方へ向いてしまうだろう。従って、ベンダーは顧客を維持し、自社ソフトウェア製品に引き付けるため、いくつかの規制と考えを放棄するのである。
【０００４】
さらに、今日の高度につながった環境においては、顧客はしばしば、ライセンスがネットワーク通信上で利用できることを望み、あるいは主張する。というのも、製品へのアクセスが必要なとき、顧客のユーザーは地理的に分散しているか、あるいはネットワークでつながれているからである。典型的に、このような状況は、顧客の環境内の単一のネットワークノードから設定および実行される、ライセンス管理サービスで対処される。
【０００５】
ネットワーク通信上でライセンスを利用可能にするもう一つの理由は、ユーザーがしばしばネットワーク上の限られた企業資源を共有しなければならないということである。例えば、CadenceRのような小さな工業技術設計会社が、工業技術ソフトウェア設計パッケージを使用したいとする。パッケージのライセンスは数十万ドルかかる。フローティングライセンスを購入することで、その会社は自社の技術者に、ライセンスの共有のためにネットワーク通信上のパッケージにアクセスする許可を与えることができるが、同時にアクセスすることはできない。このような場合には、各技術者は利用可能なパッケージを得ることができるが、パッケージ実行のためのネットワークライセンスが必要となり、さらにおそらくは、各時点においては一人の技術者あるいは少数の技術者のみしかパッケージを実行することができない。このように、限られた資源（工業技術設計パッケージ）がネットワーク設定されたライセンスによって管理されており、会社は自社の技術者全員のためにパッケージを購入しなくてよいのである。
【０００６】
しかし、単一のネットワークノードから分散されたライセンスの管理では、他のネットワーク交通量で負荷がかかったときには、単一障害点を生じ、さらには単一のネットワークノードに過度に負荷を与え得る。さらに、ノード障害が起こったとき、ソフトウェアライセンスの管理を目的として別の異なるノードを持ち出すために、手動での介入が必要となる。
【０００７】
分散したソフトウェアライセンスの管理への従来の取り組みは最適ではなく、顧客にとって高可用性（high availability：HA）な応答を作るものではないということは、一目瞭然である。
【０００８】
従って、分散ライセンス管理のための改良技術が必要とされる。
【発明の開示】
【０００９】
種々の実施形態で分散ライセンス管理の技術を示す。さらに具体的にいうと、或る実施形態では、分散ライセンス管理システムを提供する。分散ライセンス管理システムは、第一ライセンスサーバ、第二ライセンスサーバ、および第三ライセンスサーバを含む。最初に、第一ライセンスサーバはマスターライセンスサーバとして指定され、ネットワーク上のユーザーのためのライセンスを管理する。もし、第一ライセンスサーバからの通信が第二サーバと第三サーバの両方から検出されない場合は、第二ライセンスサーバが動的にマスターライセンスサーバの役割を担い、また動的にネットワーク上のユーザーのためのライセンスを管理する。
【発明を実施するための最良の形態】
【００１０】
本明細書では、「サーバ」および「マシン」という言葉は互換可能である。従って、サーバもしくはマシンは、ソフトウェアサービス、アプリケーション、および／もしくはシステムを処理することのできる処理装置である。サーバはネットワーク上でアクセス可能で、またネットワーク通信は有線、無線、あるいは有線と無線の組み合わせである可能性がある。
【００１１】
「ライセンス」とは、ソフトウェア製品の使用、もしくは消費に関する規定を意味する。いくつかの規定は、ソフトウェア製品の使用を、そのソフトウェア製品の一定の機能に制限する。他の規定は、ソフトウェア製品を同時に使用できる同時ユーザー、もしくは顧客の数を制限する。ライセンス管理サービスは、規定の解釈と執行によって、ライセンスの規定を管理する。いくつかの事例では、このことは、ユーザー（例えば顧客）のマシン上で実行されるソフトウェア製品のインスタンスに、動的キーあるいはライセンス証明書を提供するライセンス管理サービスによって達成されており、有効キーが無ければソフトウェア製品のインスタンスがユーザーのマシン上で実行されないようになっている。
【００１２】
本発明の種々の実施形態は、従来のライセンス管理サービス内に組み込むか、新たなカスタムライセンス管理サービス内に組み込むか、あるいはライセンス管理サービスのラッパーとして実装することができる。サービスもしくはラッパーは、複数のネットワークマシンもしくはノード上（サーバ、ファイヤーウォール、ゲートウェイ、ルータなど）に実装される。サービスもしくはラッパーは、複数の異なるネットワークノード上で、それ自体の複数インスタンスとして実行されるように適応される。各インスタンスは、他のインスタンスに関する役目を担い、また一定の間隔で他のインスタンスと通信する。そのようなラッパーもしくはサービスの技術および処理について、これから詳細に述べる。
【００１３】
図１は、分散ライセンス管理システム 100 を実施形態例に従って図示したものである。ライセンス管理システム 100 は、マシンがアクセス可能且つ読み取り可能なメディアに組み込まれ、ネットワーク上で使用できる。ネットワークは、ローカルエリアネットワーク（LAN）もしくはインターネットなどのワイドエリアネットワーク（WAN）である。
【００１４】
ライセンス管理システム 100 は第一ライセンスサーバ 101 、第二ライセンスサーバ 102 、および第三ライセンスサーバ 103 を含む。サーバ 101 〜 103 は、ネットワーク 110 上の異なるマシン上に存在する。図解と理解を目的として、ライセンス管理システム 100 は三つのライセンスサーバ 101 〜 103 と共に示してあるが、当然のことながらライセンス管理システム 100 はN個のライセンスサーバも含んでおり、このNはN/2+1よりも大きいかもしくは等しい奇整数である。本明細書中で下記に述べるように、奇数N個のサーバによって、クォーラムをライセンスサーバ 101 〜 103 間で設定し、また役割を割り当てることができる。
【００１５】
最初に、ライセンスサーバ 101 〜 103 は、割り当てられた役割設定をもってお互いに作用しあうように設定される。ある実施形態では、この設定、および対応する最初の役割設定は、ライセンスサーバ 101 〜 103 がライセンス内に現れる順番によって識別され、ライセンス内に一番目にあげられたライセンスサーバが第一ライセンスサーバ 101 、ライセンス内に二番目にあげられたライセンスサーバが第二ライセンスサーバ 102 、そしてライセンス内に三番目にあげられたライセンスサーバが第三ライセンスサーバ 103 となるようになっている。ライセンスサーバ 101 〜 103 が初期設定の間に割り当てられた役割を実行できるように、他の技術（ライセンスサーバ 101 〜 103 のためのインターネットプロトコル（IP）アドレスに関連したラベル（識別の役目）など）が使われ得ることが認められている。そのような全ての代替技術は、本明細書で開示する実施形態の範囲内に含まれることを意図するものである。
【００１６】
第一ライセンスサーバ 101 および第二ライセンスサーバ 102 は共に、ライセンス管理の間、マスターライセンスサーバの役割を担うことができる。マスターライセンスサーバは、マスターライセンスサーバが起動、実行するベンダーライセンス管理サービスを介して、キーを配布し、ライセンスに関する規定を執行する。第三ライセンスサーバ 103 はマスターライセンスサーバの役割を担うのでなく、第二ライセンスサーバ 102 の抑制と均衡としてはたらく。それによって、第一ライセンスサーバ 101 が、もはやライセンス管理のためにマスターライセンスサーバとしてはたらくことができないということを、第二ライセンスサーバ 102 が一方的に断じることができないようになっている。
【００１７】
最初に、第一ライセンスサーバ 101 はマスターライセンスサーバとして指定され、ライセンスの管理責任を負う。さらに、これらの責任は、マスターライセンスサーバがユーザー 120 〜 130 の代わりに実行する適切なベンダーライセンスデーモンを介して全うされる。ライセンスはネットワーク 110 上で複数のユーザー 120 〜 130 に分散される。各ライセンスサーバ 101 〜 103 は、ネットワーク 110 上で一定の間隔でお互いに通信している。ある実施形態では、一定間隔の通信はハートビート信号を介して達成される。ハートビート信号間の経過時間の間隔もしくは期間は設定可能である。
【００１８】
加えて、ライセンスサーバ 101 〜 103 は、間隔の最大数の閾値を識別できるように設定され、その後、もしハートビート信号が現在指定されたマスターライセンスサーバから検出されない場合、新しいマスターライセンスサーバが指定されると仮定される。言い換えれば、この閾値によって、第二ライセンスサーバ 102 と第三ライセンスサーバ 103 は、第一ライセンスサーバ 101 が動作停止（ダウン）したとみなすべき時点を決定することができ、その結果必然的に、第二ライセンスサーバ 102 がマスターライセンスサーバの役割を担い、ユーザー 120 〜 130 に代わってネットワーク 110 上でライセンスの管理を始める。マスターライセンスサーバとなる第二ライセンスサーバ 102 は、第二ライセンスサーバ 102 に付随するマシン上の適切なベンダーライセンス管理サーバデーモンを起動および実行することで、ライセンスを管理する。
【００１９】
第二ライセンスサーバ 102 は、ライセンスのためのマスターライセンスサーバとしての役割を担うのに、第三ライセンスサーバ 103 の承認を必要とする。加えて、第二ライセンスサーバ 102 は第三ライセンスサーバ 103 に一方的なアサーションを作ることはできず、そのアサーションによって、第三ライセンスサーバ 103 はマスターライセンスサーバの再指定のための承認を与えることができる。このようにすることで、もし第二ライセンスサーバ 102 が第一ライセンスサーバ 101 と通信できなくなり、しかし第一ライセンスサーバ 101 が別の方法で作動可能であることが第三ライセンスサーバ 103 との通信から明らかであるような場合には、第二ライセンスサーバ 102 が、マスターライセンスサーバとなるために第三ライセンスサーバ 103 の承認を得ようとする際には、第三ライセンスサーバ 103 は要求を拒否し、また第一ライセンスサーバ 103 がマスターライセンスサーバのままとなる。
【００２０】
第一ライセンスサーバ 101 は、fail-stopあるいはfail-busyを介する二つの方法のうちの一つで故障し得る。fail-stop状態では、第一ライセンスサーバ 101 上で実行する、ライセンスを管理するアプリケーション（例えばベンダーのライセンス管理サービスデーモン）は停止し、もはやいかなる作業も処理できなくなる。fail-stop状態のいくつかの例は、手動で停止されたベンダーライセンスデーモン、第一ライセンスサーバ 101 の故障などを含む。オペレーティングシステム（OS）機能は、イベントを起動し、fail-stop状態を伝達するために利用でき、これらの状況の評価が、fail-busy状態よりも簡単に行われるようにしている。
【００２１】
fail-busy状態では、ベンダーライセンスデーモンは処理しているように見えるが応答はしない。fail-busy状態の原因となるいくつかの例は、アプリケーション内のデッドロック（行き詰まり）、ネットワーク混雑、ネットワーク接続障害などを含む。fail-busy状態は、ライセンスサーバ 101 〜 103 間のハートビート通信の利用から検出され、また、ハートビート間隔および閾値の利用を通して検出される。
【００２２】
ハートビート間隔は、ハートビート信号がライセンスサーバ 101 〜 103 間で交信される一定の期間である。閾値は間隔の最大数であり、その後、もしハートビート信号がマスターライセンスサーバから検出されない場合、fail-busy状態が起きたとみなされ、ネットワーク 110 上のユーザー 120 〜 130 のためのライセンス管理における継続性を維持するために、新しいマスターライセンスサーバの指定が必要となる。さらに、不正第二ライセンスサーバ 102 が非障害状態を混乱させないようにするために、第二ライセンスサーバ 102 および第三ライセンスサーバ 103 の双方が、第一ライセンスサーバ 101 が反応しないことを個別に検証しその結果が一致することを確認する。こうして本物のfail-busy状態が確実に検出されるようになっている。
【００２３】
ハートビート信号それ自体は、各ライセンスサーバ 101 〜 103 に役立つような様々な種類の情報を含む。例えば、ハートビート信号は発信元識別子と連番を含み、信号の受信者が送信者を特定し、他の信号に対する信号の順番を特定することができるようになっている。さらに、各ハートビート信号は受信を確認される必要が無く、特定のライセンスサーバ 101 〜 103 が、受信した最新のハートビート信号のみに選択的に応答するようにしてもよい。
【００２４】
ある実施形態では、ハートビート信号は、管理されるライセンスに関する状態情報も含む。つまり、現在のマスターライセンスサーバからのハートビート信号は、現在ライセンスへのアクセスが有効なユーザー識別子を含む。このことは、第一ライセンスサーバ 101 が故障し、第二ライセンスサーバ 102 が新しいマスターライセンスサーバとしての役割を担う場合に役立つと思われる。
【００２５】
例えば、特定の分散ライセンスが、或るソフトウェア製品の実行を五人の同時ユーザーのみに許可しているが、製品の需要はもっと大きいという場合を仮定する。もし、第一ライセンスサーバ 101 が故障し、動的に第二ライセンスサーバ 102 が新たなマスターライセンスサーバとして再指定されたとき、五人のユーザーがソフトウェア製品を有効に実行している場合、第二ライセンスサーバ 102 がマスターライセンスサーバの役割を担い、適切なベンダーライセンスデーモンを起動するとき、別のユーザーはソフトウェア製品のためのキーを入手することになると思われる。しかし、もし新しいマスターライセンスサーバがライセンス状態を作り直すことができる場合、最初の五人のユーザーは優先権を与えられ、ソフトウェア製品を使用し続けるためのキーを与えられる。従って、新しいマスターライセンスサーバが動的に再指定されても、優先ユーザー継続性が維持される。
【００２６】
いくつかの実施形態では、ハートビート信号は、ライセンス状態が見られる記憶場所もしくは記憶域への参照を含む。他の実施形態では、状態情報はマスターライセンスサーバによって個別の記憶場所に記録されており、記憶場所はランタイムパラメータや環境変数などを介してライセンスサーバ 101 〜 103 内に設定されている。別の手法として、ハートビート信号は、実際にはライセンス状態を非圧縮もしくは圧縮フォーマットで含む。
【００２７】
ライセンス管理システム 100 の作動の間、第一ライセンスサーバ 101 が作動可能であって、且つ残り二つのライセンスサーバ 102 および 103 の少なくとも一つとうまく通信できる場合は、第一ライセンスサーバ 101 はマスターライセンスサーバとしてはたらく。マスターライセンスサーバとしてはたらく間、第一ライセンスサーバ 101 は、ネットワーク 110 上のユーザー 120 〜 130 の代わりにソフトウェアライセンスに関する規定を解釈し執行する、ベンダーライセンス管理サービスデーモンを起動および実行する。
【００２８】
第一ライセンスサーバ 101 は、第二ライセンスサーバ 102 および第三ライセンスサーバ 103 と、ネットワーク上で継続的に且つ一定の間隔で通信する。いくつかの事例では、この通信は、上記のやり方のような一定間隔（ハートビート間隔）で、ハートビート信号を介してなされる。例えば、ライセンスサーバ 101 〜 103 はハートビート信号を20秒毎にお互いに送信する。
【００２９】
第二ライセンスサーバ 102 および第三ライセンスサーバ 103 は、第一ライセンスサーバ 101 がfail-busy状態に陥ったと思われる時点を検出する。例えば、三つのハートビート間隔が第一ライセンスサーバ 101 から検出されること無く経過した時点などである。第二ライセンスサーバ 102 および第三ライセンスサーバ 103 は共に、第一ライセンスサーバ 101 から発する通信の欠如あるいは遅れが、マスターライセンスサーバの指定を動的且つリアルタイムに変更する根拠となることを承認しなければならない。
【００３０】
このことが起こると、第二ライセンスサーバ 102 はマスターライセンスサーバの役割を担う。これは、第二ライセンスサーバ 102 がベンダーライセンス管理サービスデーモンのバージョンを起動および実行し、また、ソフトウェアライセンスが第二ライセンスサーバ 102 に付随するマシンを介して管理される、ということを意味する。いくつかの実施形態では、上記のように、第二ライセンスサーバ 102 は、一旦マスターライセンスサーバとして再指定されると、ライセンス状態の再構成を目的として、保存された状態情報を用いてベンダーライセンスデーモンと情報をやり取りする。
【００３１】
もし、第二ライセンスサーバ 102 あるいは第三ライセンスサーバ 103 と通信することによって、第一ライセンスサーバ 101 が通信能力を回復した場合は、第二ライセンスサーバ 102 はマスターライセンスサーバとしての制御を放棄し、第一ライセンスサーバ 101 が、適切なベンダーライセンスデーモンの再起動と再実行により、マスターライセンスサーバとして自身を再構築する。
【００３２】
ライセンス管理システム 100 の、初期起動の間、ならびに処理ライフサイクルを通して、ライセンスサーバ 101 〜 103 はそれらの間でクォーラムを構築し維持する。ベンダーライセンスデーモンはこのクォーラム決定には参加しない。クォーラムの決定後、ベンダーライセンスデーモンがライセンスサーバ 101 〜 103 で起動される。各ライセンスサーバ 101 〜 103 がベンダーライセンスデーモンを起動しても、任意の特定の時点でライセンスもしくはキーをユーザー 120 〜 130 に配布するのはマスターライセンスサーバのみである。
【００３３】
いくつかの実施形態では、各ベンダーライセンスデーモンは、クォーラムの状態および、現在マスターライセンスサーバとして指定されているライセンスサーバ 101 〜 103 の状態を継続的に確認するために、そのライセンスサーバ 101 〜 103 と個別のハートビート通信を設定する。ベンダーライセンスデーモンは、対応するライセンスサーバ 101 〜 103 と通信できないとき、自らシャットダウンするように設定されている。これにより、分散ライセンスが確かに管理され、ベンダーライセンスデーモンの不正バージョンが不正に起動されないことが保証される。
【００３４】
種々の設定操作が、ライセンス管理システム 100 の管理者によって設定され効果を発揮する。例えば、ハートビート間隔、および間隔の数のための閾値は、ライセンス管理システム 100 のランタイムで設定される。さらに、各ライセンスサーバ 101 〜 103 は、ハートビート間隔と閾値のための上限および下限を個別に含み、ランタイム設定パラメータを介してこれらの上限と下限を超えようとするいかなる試みも、ライセンスサーバ 101 〜 103 によって認証されないようになっている。
【００３５】
加えて、第一サーバ 101 が作動可能なとき、第一ライセンスサーバ 101 がマスターライセンスサーバにならなくてはいけないということは、オプションとして設定可能である。従って、第一ライセンスサーバ 101 は、もしマスターとしての状態を失い、さらにその後通信能力を回復した場合、常に自動的にマスターになるわけではない。言い換えれば、この条件は設定可能である。
【００３６】
図２は、図１の分散ライセンス管理システム 100 の状態例図 200 を、実施形態例に従って図示したものである。各ライセンスサーバ 101 〜 103 もしくはサービスは、ネットワーク 110 上の異なるマシン上で実行する。ライセンスサーバ 101 〜 103 は、任意の時点において特定の処理状態にある。一つの状態例図 200 を図２に図示した。これらの状態それぞれについて順に述べていく。
【００３７】
ライセンスサーバ 101 〜 103 が起動すると、第一状態（初期） 201 に入る。これは単に暫定的な状態で、この間にライセンスサーバ 101 〜 103 がライセンスファイルを読み取り、ネットワーク 110 上に問い合わせを受けるための通信ソケットをセットアップしようとしたりする。
【００３８】
アップ状態 202 は、複数および分散ライセンス管理システム 100 には参加していない、ライセンスサーバ 101 〜 103 の定常作動状態である。つまり、アップ状態 202 のライセンスサーバ 101 〜 103 は、ライセンスサーバ 101 〜 103 のうちのその他のものとの通信に依存することなく、単独でライセンスを管理している。これは単独ライセンス管理モードとみなせる。
【００３９】
ダウン（Going Down）状態 203 は一時的な状態で、ここでライセンスサーバ 101 〜 103 は動作停止に向かい始め、正常終了する前にクリーンアップ操作を実行している。
QM（クォーラム）初期状態 204 は、ライセンスサーバ 101 〜 103 が分散ライセンス管理システム 100 処理内にアップされた最初の状態である。これはまだ一時的な状態として示され、この間にライセンスサーバ 101 〜 103 が初期化を実行しようし、また、クォーラムの任意の他のライセンスサーバ 101 〜 103 が、ネットワーク 110 上でアップされて実行されているかどうかを調べようとする。
【００４０】
QM待機状態 205 は、ライセンスサーバ 101 〜 103 が他の残りのライセンスサーバ 101 〜 103 と通信しようとした後の状態で、しかしまだいずれからも認証を介して応答を得ていない状態である。ライセンスサーバ 101 〜 103 は他のライセンスサーバ 101 〜 103 からの応答を待っており、まだ適切なマスターライセンスサーバの識別を決定していない。これは、通信する二つのライセンスサーバ 101 〜 103 が第二ライセンスサーバ 102 と第三ライセンスサーバ 103 であり、また、二者が一時的に第二ライセンスサーバ 102 をマスターライセンスサーバと認めた状態でもある。しかし、第一ライセンスサーバがマスターライセンスサーバのままであるのに間に合うようにアップされ、動的再指定を阻止するかどうかを調べようと、二者はこの時点ではまだもう少し待機している。
【００４１】
QM確認状態206 は、マスターライセンスサーバが決定され、ライセンスサーバ 101 〜 103 が、マスターライセンスサーバの指定を承認した他のライセンスサーバ 101 〜 103 の少なくとも一つと通信するか、あるいはそれによって通信されている状態である。この状態のライセンスサーバ 101 〜 103 は、次の手順に進む前に、クォーラムの残りのライセンスサーバ 101 〜 103 からの認証を待っている。
【００４２】
QMアップ状態 207 では、マスターライセンスサーバは、ライセンスサーバ 101 〜 103 の少なくとも一つのクォーラムによって決定されており、また、そのクォーラムはアップされ、ベンダーライセンスデーモンを介してネットワーク 110 上のユーザー 120 〜 130 のためのライセンスを管理する、適切な指定マスターライセンスサーバで実行される。
【００４３】
QM障害状態 208 は、現在のマスターライセンスサーバとして指定されたライセンスサーバ 101 〜 103 が、fail-stopもしくはfail-busy状態を介して、動作停止した、あるいは応答不能になった状態である。これは、クォーラムが壊れてしまったと思われるときにも起こる。クォーラムにあるライセンスサーバ 101 〜 103 は、QM待機状態 205 に入る前に、クリーンアップならびにクォーラムセットアップの再初期化のために、この一時的な状態に入る。
【００４４】
QMダウン状態 209 で、ライセンスサーバ 101 〜 103 はシャットダウンするように指示され、終了の前にそれぞれがクリーンアップ段階にある状態に入る。
状態図 200 に図示した状態に加えて、ライセンスサーバ 101 〜 103 は、上記のハートビート信号の域を越えた種々の異なるメッセージを介して、お互いに通信する。いくつかのメッセージ例をこれから示す。
【００４５】
いくつかの事例では、全メッセージは唯一のトランザクション識別子（id）を（連続的に増加する数として）持ち、これはメッセージを発信したライセンスサーバ 101 〜 103 によって作られる。他のメッセージに対する応答として送信された任意のメッセージは、同じトランザクションidを含む。各メッセージはライセンスサーバ（発信者）名も含む。
【００４６】
“WHO”メッセージは、ライセンスサーバ 101 〜 103 によって送信される最初のメッセージで、クォーラムの任意の他のライセンスサーバ 101 〜 103との交信を始める。これは、“現在の状態を教えてください”という意図である。メッセージは、ライセンスサーバ 101 〜 103 のバージョン、ライセンスサーバ 101 〜 103 の設定、およびライセンスサーバ 101 〜 103 のためのクォーラムの認識された指定役割と設定を含む。
【００４７】
“WHO(M)”メッセージは、第一ライセンスサーバ 101 および第二ライセンスサーバ 102 から、起動もしくは初期化の一部として送られる。これは“WHO”メッセージと同様だが、“マスター候補名”という追加要素も含まれる。最初に、第一ライセンスサーバ 101 および第二ライセンスサーバ 102 は共に、マスターライセンスサーバとなる候補として自身を指名することができる。
【００４８】
注目すべきは、いくつかの実施形態では、“WHO(M)”メッセージは、“WHO(M)”メッセージを独自に識別する追加パラメータを持つ“WHO”メッセージと組み合わされるということである。実際、注目すべきは、本明細書においてメッセージは実施形態例として開示されるということであり、また、本明細書で開示される他のメッセージもしくはメッセージの組み合わせは、本発明と共に開示される内容から逸脱することなく作られるということが認められる。
【００４９】
“STATUS”メッセージは、ライセンスサーバ 101 〜 103 から送信される最も一般的なメッセージであり、また、送信ライセンスサーバ 101 〜 103 からわかる現在のクォーラムの状態情報を含む。これは以下の要素（マスターライセンスサーバ名、クォーラムの状態、送信ライセンスサーバ 101 〜 103 からわかる、設定ライセンスサーバ 101 〜 103 の状態）を含む。いくつかの実施形態では、“STATUS”メッセージは、ライセンスサーバ 101 〜 103 がお互いにクロック（動作周波数）の同期を維持できるようにするための時間も含んでいる。
【００５０】
“CONFIRM”メッセージは、マスターライセンスサーバから、クォーラムの他のライセンスサーバ 101 〜 103 に対して、どれがマスターライセンスサーバであるかを全サーバが承認していることを確かめるために送られる。このメッセージはマスターライセンスサーバ名を含む。
【００５１】
“CONFIRMOK”メッセージは、非マスターライセンスサーバ 101 〜 103 （スレーブ）から、現在のマスターライセンスサーバからの“CONFIRM”メッセージの受信に応えて送信される。このメッセージはYESもしくはNOの値を持つ認証フィールドを含む。
【００５２】
“UP”メッセージは、マスターライセンスサーバから、クォーラムの残りのライセンスサーバ 101 〜 103 に対して、クォーラムが現在適切にアップされて正常に作動しているということを伝え、さらに、マスターライセンスサーバ設定のためのライセンスサーバ 101 〜 103 間のやり取りが終了したことを伝えるために送信される。これは本当に、単にスレーブに対して、必要な“CONFIRMOK”メッセージが全て受信されたことを知らせ、また全スレーブが自身の状態をクォーラムアップ状態 207 に設定するように知らせるだけのものである。
【００５３】
“BADPARM”メッセージは、パラメータのミスマッチが受信者に発見された際、“WHO”メッセージに対する応答として用いられる。
“SHEARTBEAT”および“SHEARTBEATOK”メッセージは、クォーラムのメッセージではなく、これらは、ライセンスサーバ 101 〜 103 の稼動状態の経過を追うための、ライセンスサーバ 101 〜 103 のハートビートメッセージである。これらは、クォーラムの設定後に上記のようなやり方でライセンスサーバ 101 〜 103 に利用される。個々のハートビート信号は、各ライセンスサーバ 101 〜 103 によってベンダーライセンスデーモンとの通信において利用される。
【００５４】
ライセンス管理システム 100 には、種々の大域状態または大域状況が存在する。これらについてそれぞれ、図解を目的として、これから以下の用語を用いて列挙していく。第一ライセンスサーバ 101 は“P”とあらわし、第二ライセンスサーバ 102 は“S”とあらわし、また第三ライセンスサーバ 103 は“T”とあらわす。
【００５５】
ライセンス管理システム 100 の、クォーラムが有効な間において可能な操作シナリオは以下の通りである：PS（Pアップ、Sアップ、Tダウン）、PST（Pアップ、Sアップ、Tアップ）、PT（Pアップ、Sダウン、Tアップ）、およびST（Pダウン、Sアップ、Tアップ）。もし単一のライセンスサーバ 101 〜 103 しかアップされず、他のサーバがダウンしている場合（P、S、またはT）、クォーラムは設定されない。
【００５６】
加えて、ライセンスサーバ 101 〜 103 が利用可能になるタイミングは、ライセンス管理システム 100 の異なる順列であらわされる。例えば、SP（Pの前にSがアップされる）、SPT（最初にSがアップされ、続いてP、それからT）、STP（最初にSがアップされ、続いてT、それからP）、TP（Tがアップされ、続いてP）、およびTS（Tがアップされ、続いてS）となる。さらに注目すべきは、起こり得る障害のために、ライセンス管理システム 100 の起動シーケンスが、クォーラムの稼動期間中、交互に変わる可能性があるということである。
【００５７】
ライセンス管理システム 100 は、種々の有益なエラー処理技術も展開する。一般的に、エラー処理の一つのやり方として、クォーラム障害が検出されると、クォーラム状態を再初期化し、QM待機 205 に戻って、再試行することが適切といえる。
【００５８】
他の障害としてピア検出障害がある。これは、ライセンスサーバ 101 〜 103 が孤立してしまい、クォーラムの設定のために他のどのライセンスサーバ 101 〜 103 も検出することができない状態である。ここで、ライセンスサーバ 101 〜 103 はQM待機状態 205 に入る。この状態のライセンスサーバ 101 〜 103 は、ピア検出タイマーを起動し、もしライセンスサーバ 101 〜 103 がタイマーの切れる時間までに何の通信も受信しなかった場合、ライセンスサーバ 101 〜 103 は手動でピアと通信しようとし、もし失敗した場合はQM待機状態 205 に戻る。
【００５９】
どれがマスターライセンスサーバかについての不一致があるとき、QM確認状態 206 において遮断障害が起こる。もしこれが起こると、デッドロック状態にとどまり、永久に遮断される可能性がある。これを処理するため、全ライセンスサーバ 101 〜 103 は、QM確認状態 206 に入る際に承認タイマーを起動する。もしスレーブとなるライセンスサーバ 101 〜 103 が、マスターとなるライセンスサーバ 101 〜 103 からタイムアウトの期限内に何も受信しない場合、全サーバはクォーラムの確認を停止し、破損クォーラムとして扱い、再初期化し、QM待機状態 205 に戻る。
【００６０】
メッセージおよびエラー処理に加えて、ライセンス管理システム 100 は、種々のメンテナンスユーティリティも含む。メンテナンスユーティリティのいくつかの例は、作動中のクォーラムにおける単一のライセンスサーバ 101 〜 103 のシャットダウン、クォーラムにおけるマスターライセンスサーバの再指定を動的に強制する手動操作、ならびにクォーラムからの診断をとらえ追跡するための操作を含む。診断は状態のデバッグに役立ち、ここでクォーラムの別の要素は、クォーラム状態の別の表示を有する。
【００６１】
図３は、分散ライセンス管理の方法 300 を実施形態例に従って図示したものである。方法 300 （以下ライセンス管理サービス）は、マシンがアクセス可能且つ読み取り可能なメディアに組み込まれ、ネットワーク上で作動できる。或る実施形態では、ライセンス管理サービスは、ライセンス管理システム 100 の各ライセンスサーバ 101 〜 103 上に、複数の顧客またはユーザー 120 〜 130 の代わりに分散ソフトウェアライセンスを共同管理することを目的として、組み込まれる。
【００６２】
310 では、ライセンス管理サービスは、ライセンスサービスの異なる実行インスタンスの役割を決定および指定する。これらのインスタンスはそれぞれ、ネットワーク上の異なるマシン上で実行されている。ネットワークはLANまたはWAN（例えばインターネット）である。ライセンスサービスインスタンス間のやり取りの間、第一ライセンスサービス、第二ライセンスサービス、および第三ライセンスサービスが初期クォーラムとして指定される。さらに、マスターライセンスサービスが第一ライセンスサービスとして最初に識別される。
【００６３】
或る実施形態においては、 311 では第一、第二、および第三の指定は、管理されるソフトウェアライセンスに出現するマシンの順番によって決定される。
320 では、ライセンス管理サービスがマスターライセンスサービスを介してライセンスを管理する。これを行うため、最初に第一ライセンスサービスがベンダーライセンス管理デーモンサービスを起動する。或る実施形態においては、 321 では、第一ライセンスサービスのマシン上で実行するベンダーライセンスサービスが、顧客のユーザーに供給されるキーを介してライセンスを動的に配布する。ユーザーまたは顧客は、ネットワーク上でマシン上のライセンスに関するソフトウェア製品のインスタンスを個別に実行し、また、マスターライセンスサービスとして指定されたライセンスサービスのマシン上で実行する、ベンダーライセンスデーモンを介して配布された有効キーを持っている限り、ソフトウェア製品をうまく実行することができる。
【００６４】
或る実施形態においては、 322 では、ライセンス管理サービスはさらに、マスターライセンスサービスを介して管理されるライセンスの状態を維持する。例えば、マスターライセンスサービスは、ベンダーライセンスサービスに接続してソフトウェア製品をアクティブに実行しているユーザーまたは顧客の識別子を定期的に記録できる。
【００６５】
或る実施形態によれば、 323 では、もし現在のマスターライセンスサービスが続いて第二ライセンスサービスに再指定されると、その後新しいマスターライセンスサービスはライセンスの以前の保存状態を再構築する。 324 では、その状態は、以前のマスターライセンスサービスからの最新のハートビート通信によって得ることもでき、あるいは、以前のマスターライセンスサービスによって記録された、以前のマスターライセンスサービスを処理するマシンとは独立した記憶場所から得ることも可能である。
【００６６】
再び、 330 では、ライセンス管理サービスは最初に第一ライセンスサービスをマスターライセンスサービスと指定する。第一、第二、および第三ライセンスサービスの作動の間、ならびに或る実施形態においては、 331 では、各ライセンスサービスはその他のライセンスサービスとハートビート信号を介して通信する。実際、ライセンスサービス間の通信にあたっては、任意の形式が許容され用いられる。
【００６７】
ライセンス管理サービスの作動の間のいくつかの時点において、 340 では、第二および第三ライセンスサービスが、第一ライセンスサービスが応答不能であることを検出する。或る実施形態において、 341 では、第二ライセンスサービスと第三ライセンスサービスが共に、第一ライセンスサービスがハートビート信号または他の取り決められたネットワーク上の通信を通信していないということを、自身で個別に確認する。
【００６８】
第二および第三ライセンスサービス両方が、第一ライセンスサービスがfail-stopまたはfail-busy状態にあることを承認したと仮定すると、それから 350 では、ライセンス管理サービスが第二ライセンスサービスを新しい現在のマスターライセンスサービスとして、リアルタイムに動的に再指定する。いくつかの事例では、ライセンスの状態は第一マスターライセンスサービスによって維持され、 323 でその状態は第二ライセンスサービス上で再構築される。第二ライセンスサービスと同じマシン上で実行しているベンダーライセンスデーモンは、現在マスターであることを知らされ、ライセンスが管理される。ベンダーライセンスデーモンは、既に第二ライセンスサービスのマシン上で実行しているか、あるいは、第二ライセンスサービスを新しいマスターライセンスサービスとして再指定するにあたり、第二ライセンスサービスから必要なときに起動される。
【００６９】
或る実施形態においては、 360 では、第一ライセンスサービスが第二ライセンスサービスおよび／もしくは第三ライセンスサービスと再び通信可能になったとき、第二ライセンスサービスが自動的且つ動的に、マスターライセンスサービスとしての制御を放棄する。なお、この操作シナリオはライセンス管理サービス内で設定されるので、いつもこうである必要はない。
【００７０】
図４は、分散ライセンス管理の別の方法 400 を実施形態例に従って図示したものである。この方法は、マシンがアクセス可能且つ読み取り可能なメディアに命令として組み込まれる。命令はマシンに読み込まれ実行されると、図４に図示された処理を実行する。
【００７１】
最初に、命令は取り外し可能なメディアに存在し、マシンに接続され、そこでそのマシンにアップロードされて実行される。もう一つの方法として、命令はネットワーク上の遠隔記憶場所または遠隔マシンに存在し、別のネットワークマシンにダウンロードされ、そこで実行される。さらに他の設定では、命令は、マシンに付随する記憶装置および／もしくはメモリ内に作成済みであり、そのマシンによって実行される。さらに注目すべきは、命令が単一のメディアに隣接して存在する必要は無いということである。つまり、いくつかの事例では、命令は複数のばらばらなメディアから取得され、マシンで実行される。
【００７２】
命令は、複数のネットワークマシンまたはノードから、ネットワーク上で重複して実行されることができる。命令の個々のインスタンスはそれぞれ、方法 400 の処理を、命令の他の残りのネットワークインスタンスと連携して行うことができる。
【００７３】
410 では、命令は三つ以上のネットワークマシン間のクォーラムを取り決め、 420 において、命令の初期化の間、クォーラムの各メンバーの役割が動的に構築されるようにする。この処理の間、マスターライセンスサービスが選択され、ネットワークマシンの特定の一つと関連して識別される。マスターライセンスサービスは、複数のユーザーまたは顧客のために、ネットワーク上でソフトウェアライセンスを管理する責任を負う。これを行う一つの技術は、マスターライセンスサービスに、そのソフトウェアライセンスのためのベンダーライセンスデーモンをマスターとして指定させることである。
【００７４】
430 では、命令は、ネットワーク上のマシン間におけるハートビート信号の一定間隔の通信を促進し、その一方で、ライセンスがマスターライセンスサービスによって、ベンダーライセンスデーモンを介して独立して管理される。或る実施形態においては、 431 では、命令は、ライセンスをアクティブに消費または使用している顧客の識別子を維持する。これは、記録された識別子が、 442 において、任意の新たに再指定されたマスターライセンスサービスから、ライセンスに付随するソフトウェア製品のための再配布キーを受け取る優先権を与えられるように、異なるマシンが動的にマスターライセンスサービスの役割を担う際に役立つことがわかる。
【００７５】
もし現在のマスターライセンスサービスが、経過時間の設定期間内にハートビート信号を送信し損ねた場合、その後 450 では、命令は、ネットワークマシンの別の一つから、新しいマスターライセンスサービスを動的に再指定する。或る実施形態では、マシンは閾値を用いて、現在のマスターライセンスサービスがダウンした、あるいは応答不能になったと断ずるべき時点を決定できる。閾値とハートビート間隔とのやり取りは、図１のライセンス管理システム 100 について上記に述べてある。
【００７６】
再指定が起こる前に、現在のマスターライセンスサービスに付随しない各マシンは、現在のマスターライセンスサービスと識別されるマシンと通信することができないはずである。従って、もし少なくとも一つのマシンが、現在のマスターライセンスサービスとまだ通信している場合、その後 460 では、別のマシンが現在のマスターライセンスサービスの指定における変化を得ようとする試みは拒否される。
【００７７】
或る実施形態によれば、 470 では、現在のマスターライセンスサービスに付随するマシンが応答不能とみなされた経過期間は、命令に対する設定パラメータとして与えられる。加えて、設定パラメータは、各マシンに個別に維持される上および下の限界、または境界と比較され、経過期間の設定パラメータが所定限界を下回らないように、あるいは所定上限を超えないようになっている。
【００７８】
ここまで、分散ソフトウェアライセンスが、複数のユーザーのためにネットワーク上でどのように管理されるか説明してきた。ライセンスは単一のネットワークノードからのみ管理されるのではなく、従って、単一の障害ポイントともならない。さらに、マスターノードの障害が起こった際は、別のネットワークノード上で手動介入することなく、ライセンスが動的に再構築され、且つ自動的に再構築される。
【００７９】
上記の説明は実例的であり、制限的なものではない。上記の説明を再考する上で、多くの他の実施形態が当業者に明らかであろう。実施形態の範囲は、従って添付の請求項に準拠して、その請求項が権利を有する均等な特徴の全範囲として定められる。
【００８０】
要約書は米国特許法施行規則1.72条(b)項に従って規定され、読者が技術的開示の本質と趣旨を素早く解明することを可能にするものである。これは、請求項の範囲または意味を、解釈あるいは制限するために用いられるものではないという合意と共に提示される。
【００８１】
前述の実施形態の説明において、開示の合理化を目的として、種々の特徴は単一の実施形態に一緒に分類してある。この開示方法は、請求項の実施形態が、各請求項に明確に列挙された以上の特徴を持つことを反映するものとしては解釈されない。むしろ、次の請求項が反映するように、発明主題は、開示された単一の実施形態の全特徴の範囲内にある。従って、以下の請求項は、本明細書において実施形態群の説明に組み込まれ、各請求項は個々の例示的な実施形態として独立するものである。
【図面の簡単な説明】
【００８２】
【図１】図１は、分散ライセンス管理システムを実施形態例に従って図示したものである。
【図２】図２は、図１の分散ライセンス管理システムの状態図の一例を、実施形態例に従って図示したものである。
【図３】図３は、分散ライセンス管理の方法を実施形態例に従って図示したものである。
【図４】図４は、分散ライセンス管理の別の方法を実施形態例に従って図示したものである。
【図３】
2008539518.tif 000003
【図１】
2008539518.tif 000004
【図２】
2008539518.tif 000005
【図４】
2008539518.tif 000006
【手続補正書】
【提出日】平成20年1月15日(2008.1.15)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項９
【補正方法】変更
【補正の内容】
【請求項９】
請求項８の方法であり、さらに、
前記第一ライセンスサービスが応答可能であったとき、前記第一ライセンスサービスから受信された最新のハートビート通信から前記状態を取得することと、
前記第一ライセンスサービスによって記録された記憶場所から前記状態を取得し、ここで前記記憶場所は前記第一ライセンスサービスに付随するマシンから独立していること
のうちの少なくとも一つを含む方法。
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項１５
【補正方法】変更
【補正の内容】
【請求項１５】
マシンがアクセス可能であり命令を有するメディアであって、マシンにアクセスされた際に前記命令が、
三個以上のマシンのクォーラムを取り決めることと、
前記クォーラムの各メンバーに役割を割り当てることと、
ここで、前記複数のマシンのうちから一つを選択する際のマスターライセンスサービスの役割指定が、前記複数のマシンのどれが顧客のためにネットワーク上のライセンス管理に責任を負うかをあらわす、ということと、
前記ライセンスが現在のマスターライセンスサービスによって管理されている間に、前記マシン間でハートビート信号を一定間隔で通信することと、
もし前記現在のマスターライセンスサービスが、設定可能な経過時間の期間内に、前記ハートビート信号を一つも通信できなかった場合、前記複数のマシンのうちの別の一つを、前記マスターライセンスサービスとして動的に再指定すること
を行う方法を実行する
ことを特徴とするメディア。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００１９
【補正方法】変更
【補正の内容】
【００１９】
第二ライセンスサーバ 102 は、ライセンスのためのマスターライセンスサーバとしての役割を担うのに、第三ライセンスサーバ 103 の承認を必要とする。加えて、第二ライセンスサーバ 102 は第三ライセンスサーバ 103 に一方的なアサーションを作ることはできず、そのアサーションによって、第三ライセンスサーバ 103 はマスターライセンスサーバの再指定のための承認を与えることができる。このようにすることで、もし第二ライセンスサーバ 102 が第一ライセンスサーバ 101 と通信できなくなり、しかし第一ライセンスサーバ 101 が別の方法で作動可能であることが第三ライセンスサーバ 103 との通信から明らかであるような場合には、第二ライセンスサーバ 102 が、マスターライセンスサーバとなるために第三ライセンスサーバ 103 の承認を得ようとする際には、第三ライセンスサーバ 103 は要求を拒否し、また第一ライセンスサーバ 101 がマスターライセンスサーバのままとなる。
【国際調査報告】
2008539518.tif 000007