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

Abstract

(57)【要約】本公報は電子出願前の出願データであるため要約のデータは記録されません。

Description

【発明の詳細な説明】 ライセンス管理システム 先行技術 本発明はコンピュータシステムのオペレーション方法に係り、より詳細には、コ ンピュータシステムで実行されるソフトウェアのライセンスを管理する方法とシ ステムに係る。

本発明の譲受人であるデジタル・イクイップメント社に譲渡されたロバート、チ ェース及びスカファ氏の米国特許第４．９３７．８６３号には、ライセンス付き ソフトウェアの使用をコンピュータシステムにおいて監視してその使用がライセ ンスの範囲内であるかどうかを判断するソフトウェアライセンス管理システムが 開示されている。このシステムは、ソフトウェア製品に対するライセンスのデー タベースを維持し、各製品ごとにライセンス単位の数を指示する単位値を記憶し ている。ユーザがライセンス付き製品を使用したい場合には、ライセンスの許− 可を要求するメツセージが中央のライセンス管理設備に送られる。このメツセー ジに応答して、管理設備はデータベースをアクセスして、その製品に対するライ センスが存在するかどうかを調べ、もしあれば、ユーザの特性、例えば、ソフト ウェア製品を実行するプラットフォームｃｃ　ｐ　Ｕ）の構成に基づいて、ある 単位がユーザに割り当てられる。ライセンス管理設備がライセンスを許可できる と判断した場合には、ユーザにメツセージが送られ、そのソフトウェア製品を活 用する許ｉＪを与える。さもなくば、メツセージは許可を拒絶する。

前記特許第４，９３７．８６３号に開示された概念は広範囲に適用でき、実際に 本発明にも使用されるが、ある用途においては更に別の機能や代替物が必要であ る。例えば、ライセンス管理システムは、１つ又は数個のみのライセンスを許す ように厳密に構成されるのではなく、種々様々な胃なるライセンスの同時使用を 許さねばならない。ユーザとライセンスを交渉するときには、たとえある売主は 選択を少数のものに狭める判断をすることがあっても、売主には広範囲の条項及 び条件が得られねばならない。例えば、ソフトウェア製品は、１人１人が単一の ＣＰＵで使用するように各個人にライセンスを与えてもよいし、或いは誰かがネ ットワーク上で使用したり１つの団体内のターミナルにいる任意のユーザによっ て使用したりするように組織にライセンスを与えてもよいし、もしくは別の特定 のライセンス付き製品又は多数の他のそれに代わるもののいずれかからの呼び出 しに対してのみライセンスを与えてもよい。更に、ある売主は非常に多数の製品 を有していて、その幾つかはある形式のライセンスのもとで販売されそして別の 幾つかは他のライセンスのもとで販売されることもあるし、或いは種々のライセ ンス方針及び価格を有する１Å以上の売主からの多数の特徴を複合したもので１ つの製品ができていることもあり、従って、このようなあらゆる製品に対して同 じライセンス管理システムを使用することが望まれる。

分配式のコンピュータシステムは、追加のライセンス発行を与える。この分配シ ステムは、サーバ及びクライエントのネットワークに一緒に接続された多数のプ ロセッサノードを備えている。各ノードは、プログラムをローカル位置で実行す ると共にネットワークを経てプログラム又は特徴（プログラムのサブ部分）も実 行するプロセッサである。１つのノードで実行されるプログラムは、他のノード の手順又はプログラムへリモート手順呼び出しを行うことができる。この場合に 、ネットワークの全てのノードで実行するためのライセンスを許可するのではな く、プログラムを単一のＣＰＵにおいて別々ではなくて分配的に実行できるよう なライセンスを定めるある構成が必要とされる。

地理的に分散した種々の部や課を有する会社や政府機関のような大きな組織にお いては、ソフトウェアライセンスの政策を執行及び実施することが困難であると 共に、その組織の単位ごとに個々のライセンスを交渉し、許可を与えそして執行 する場合に、非常に経費がかかることになり勝ちである。好ましい構成は、ソフ トウェア製作者から単一のライセンスを得て、このライセンスを委任によってそ の地方で執行される部分に分割することである。このようにして、ネットワーク 通信により生じる遅延を最小にできると共に、部や課に課せられる予算的な制約 も最小にできる。このように委任による発行とは別に、ネットワークの全てのノ ードで実行される製品のライセンスが中央で執行される場合には、ライセンス管 理設備をネットワーク−ヒで動作させるのが最も良い。しかしながら、本発明の 特徴を用いるのにネットワークは必要でない。というのは、ライセンスの管理は 単一のプラットフォームで実施できるからである。

ソフトウェア製品は次第に特定のファンクションに細分化されてきており、ファ ンクションの個別の分配が不当に高価なものとなっている。例えば、スプレッド シートプログラムは、高度なカラーグラフィックや、データベースのアクセスや 、フォントの拡張リストのプリント又は表示等のために別々のモジュールを有す る。基本的なスプレッドシート製品の顧客は、これら追加特徴の若干を望んだり 、全てを望んだり又は全く望まなかったりする。更に、全ての組み合わせを１つ のパッケージとして分配し、顧客がこれらの特徴を個々に又は種々の組み合わせ で或いは異なる期間のもとてライセンス使用できるようにするのが効果的である 。顧客はスプレッドシートを毎日使用する必要のある会社の部全体であるが、グ ラフィックについては１力月に数日使用する必要のある数人に過ぎない。それ故 、全パッケージに対して固定の方針というのではなく、ソフトウェアパッケージ の一部分又は特徴を異なったやり方でライセンス使用できることが効果的である 。

製品を全体的に分配するが部分的にライセンス使用する別の例は、システムに対 して使用できる全てのソフトウェアを含むＣＤ　ＲＯＭを顧客に供給し、顧客が 使用権を得るために料金を支払う必要のある又は支払おうとする部分についての みライセンス使用しようとするものである。もちろん、製品は、単にアプリケー ションプログラムや、オペレーティングシステムや、慣例的に実行できるコード である必要はなく、例えば、プリンタのフォントのような静止物体や、グラフィ ック像や、音楽やその他の音響効果も含まれる。

以下で説明するように、本発明の１つの特徴によれば、発呼及び発呼者認可がシ ステムに設けられ、多数の取引」二の慣例に対して技術的なサポートを与えると 共に、「移行的ライセンス（ｔｒａｎｓｉｔｉｖｅ　ｌｉｃｅｎｓｉｎｇ）Ｊと 称するものを使用しなければならない技術的な問題を解決する。この「移行的ラ イセンス」とは、１つの製品又は特徴を使用する権利が１つ以上の他の製品又は 特徴を使用する権利を意味するものをいう。この移行的ライセンスは、複数の製 品を使用する権利を与える弔−の手段で構成されるという点でグループライセン スに類似している。しがしながら、移行的ライセンスは、ライセンス製品にしか 使用できないことを指定すると共に、１つ以りの許可された製品間発呼／発呼者 関係を更に指定することにより許可された権利を制限するという点で、グループ ライセンスとは異なる。

移行的ライセンスの使い方及びその性質を明確にする助けとして幾つかの例を挙 げると、（１）−緒に販売される２つの製品、（２）別々のライセンス製品を狭 義に選択することによる放棄、（３）クライエント／サーバ環境におけるクライ エントライセンス方法、（４）モジュール設計によるインパクト、（５）分配設 計によるインパクトである。

ソフトウェアの売主は販売のために２つの製品を有することがある。即ち、その 第１はメイルシステムでありそして第２はＬＥＸＩＳ（登録商標）のような内容 をベースとするテキスト検索システムである。これら製品の各々は、もし別々に 購入すれば価格が＄５００である。ある顧客は、これら製品の１つだけを使用す る権利を購入することによって満足する。他の顧客は、その両方を使用するのが 妥当であると分かる。顧客が実際に両方の製品を購入する見込みを高めるために 、ソフトウェアの売主が潜在的な顧客に多額の割引を申し出、２つの製品を合わ せて＄８００という価格で売ることは驚くべきことではない。この組み合わせ販 売の利点を得た顧客は、２つの製品を受領し、その各々を互いに他のものとは独 立してその最大能力まで活用できることが分かる。従って、これらの顧客は、内 容をベースとする検索システムを使用して、非メイル文書を記憶及び検索するこ とができる。しかしながら、売主は、特に大量のメイルユーザが、時々、標準的 なメイル構成によって与えられるファイリング容量を増大するためだけに、内容 をベースとする検索システムを使用できることを望むと分かった。これら潜在的 な顧客の多くは、拡張したメイル容量のために＄８００を支払うのはいかにも高 過ぎると感じているであろう。そこで、売主は、メイルユーザがメイル機能を使 用するときだけ内容ベースの検索システムを使用する権利をそのユーザに許可し そして顧客システムで得られる他のアプリケーションと共に内容ベース検索シス テムを使用することは禁止するようなライセンスをこれらの顧客に申し出ること を考えた。この形式のライセンスを以下「移行的ライセンス」と称し、これは＄ ６００で販売される。

もう１つの例は、特定のオペレーティングシステム、例えばＶＭＳに使用するよ うに設計された関係データベース製品（Ｒｄｂ（登録商標）と称するもののよう な）である。この関係データベース製品は２つの要素を有している。即ち、それ は（１）新たなデータベースを開発するのに使用するユーザインターフェイスと 、（２）既に開発されたデータベースの使用をサポートする「ラン・タイム」シ ステムである。データベース製品の開発者は、データベース製品の売主によって 作られた他の製品を入手し、これら他の製品で彼等自身の製品指向のデータベー スを構築するのではなく、それをデータベースとして使用する試みに多大な努力 を費やしている。不都合なことに、他の製品の設計者は、データベース製品のラ ン・タイムライセンスのコストをそれらの製品のライセンスのコストに加えると 、当然ながらそれらの製品が他と競合し得ないものになるという苦情を訴えてい る。従って、売主の製品の一方又は他方が「プライベート」的に関係データベー ス製品のラン・タイムシステムを使用できるが、他の売主の製品には無断てアク セスできないような何らかの機構が必要とされる。このような機構は本発明以前 に存在せず、従って、売主は、データベース製品のラン・タイムシステムを使用 する権利をその専有のオペレーティングシステムライセンスと共に販売すること が強制される。明らかに、この組み合わせライセンスは、売主の製品がその価格 を増すことなくそのデータベース製品を使用できるようにするが、いかなる顧客 及び第３者も追加のライセンス料金を支払うことなくデータベース製品を使用で きることになってしまう。しかしながら、本発明のシステムが使用できれば、売 主は、そのデータベース製品のラン・タイム要素に対する移行的ライセンスを売 主の全ての製品に対して許可することができる。本質的に、これらのライセンス は、データベースのラン・タイムがその売主の他の幾っがの製品と共に使用され た場合及びその場合だけ、追加のライセンス料金なしにそのデータベースのラン ・タイムを使用できるといえる。新たな関係データベースアプリケーションを構 築するか又は売主のデータベース製品に基づく第３者アプリケーションを使用し ようと望む顧客は、データベースのラン・タイムライセンス料金を顧客に支払わ ねばならないことになる。

ここに提案するクライエント／サーバライセンス方法は、移行的ライセンスによ って解決できる問題の更に別の例を提供する。典型的に、クライエントは一度に １人のユーザのみによって使用され、一方、サーバは、クライエントの活動のレ ベルと、サーバをサポートするマシンの容量とに基づいて、任意の数のクライエ ントをサポートすることができる。慣例的に、サーバ／クライエントアプリケー ションは、サーバが潜在的にサポートできるクライエントの数に応じてライセン ス使用されているが、これは、本発明によって提供される別の仕方を考慮したと きには、ライセンス使用に対する最も適当な方法ではない。ここに提案するクラ イエント／サーバ方法の業務モデルでは、各クライエントに個々にライセンスを 与えることが要求され、適切なライセンスが付与されたクライエントをサポート するためにはサーバについての明確なライセンス付与が要求されない。このよう なライセンス付与構成は、顧客が購入する特定数のクライエントについてのみ顧 客に料金を課することができる。更に、単一のクライエントは、システムの全コ ストを増加することなく、２つ以上のサーバを使用できることも意味する。

この移行的ライセンスの問題に対する解決策は、クライエントがライセンスの単 位割り当てを得て、その割り当ての「証明」を、使用しようとするサーバへ送る ことのできる機構を提供することである。次いで、サーバは、その証明か有効で あると確認できるクライエントをサポートする。一方、割り当ての証明を受け取 らなかったクライエントがサーバを使用しようと試みた場合には、サーバは、何 らかのサービスを実行する前にそのクライエントに対するライセンスの割り当て を得ることになる。このような解決策はこれまでに得られていない。

顧客に提供されるソフトウェアシステムの複雑さ及びサイズが増大するにつれて 、顧客に与えられる実際の解決策はもはや１つの製品だけではないことが分かっ た。むしろ、今や、顧客は、益々多数のコンポーネント又は製品を一体化するこ とにより構築される解決策がしばしば提供され、その各々はほとんどの場合スタ ンド・アローンであるが、多数の他の解決策の一部分であることもある。実際に 、製品戦略は、はぼ例外なく、売主の技術と、他のコンポーネントと一緒に組み 合わせたときだけより大きなシステムとなるようにフルに活用できる様々の特殊 コンポーネントを販売することとに依存する。このようなコンポーネントは、上 記の関係データベースのラン・タイムシステムと、メイル搬送機構と、超情報デ ータベースと、文書フォーマット変換サービスと、時間サービス等々を含む。

これらのコンポーネントは、それ自身のメリットで販売されるだけでなく、より 大きなシステムへ貢献できることによっても販売されるので、いずれの顧客も、 いったんシステムへ組み込まれたコンポーネントのいずれについてもその完全な 論理経済価値を受けることはあり得ない。同様に、より大きなシステムへと組み 込まれたいずれのコンポーネントの価値も、システムごとに著しく異なることが 観察されている。従って、メイル搬送機構は、主たる要素がメイルであるシステ ムについてはその大きな部分に影響するが、広範なオフィス自動化機能をもたら すシステムについては比例的に僅かな価値しか与えないことが分かった。これら の観察の結果、各コンポーネントごとにそれ自身耐えられる「適切」な市場価格 を見つけようとする業務分析者の仕事は、益々複雑になる。実際に、コンポーネ ントの価格又は価値は、それが組み込まれる全システム又は解決策に対するその コンポーネントの貢献度を考慮したときにのみ決定することができる。これらコ ンポーネントをその理論的な独立の価値に基づいた価格で販売しようとすると、 単純に高過ぎるシステムになってしまう。

移行的ライセンスのスタイルは、モジュール式コンポーネントの価格設定を処理 するのに特に適している。というのは、コンポーネントの価格を、それらがサポ ートする他のコンポーネント又はシステムに対して明確に決められるからである 。従って、売主は、メイル搬送システムを１つの製品と共に使用する権利に対し て＄１００の価格を請求することができ、更に、その同じメイル搬送システムを 別の製品によって使用するときにその使用について＄２００の請求をすることが できる。

移行的ライセンスをサポートしようと希望する「取引」上の理由に加えて、開発 前が１分配型品」を構築する傾向が増すと共に、密接に又は緩く結合されたマル チプロセッサシステムを利用するドライブ向はアプリケーションの傾向が増して きたことから非常に良好な技術的な理由も生じ、リモート手順呼び出しが利用で き且つこれが益々使用されるようになったことがこの傾向に拍車をかけてきてい る。この技術的な問題は、多数のコンポーネントを有する製品であって各々のコ ンポーネントが異なったプロセススペースにおいて潜在的に異なったコンピュー タシステム上で動作するような製品を考慮したときに生じることが明らかである 。従って、ユーザインターフェイスが１つのマシンにおいて動作し、その「ファ イルキャビネット」が第２のマシンによりサポートされそしてそのメイル搬送シ ステムが更に第３のマシンにおいて動作するようなメイルシステムが生じる。

このとき生じる簡単な問いは［３つのコンポーネントのどれがライセンスをチェ ックすべきか？］というものである。有効なライセンスが存在しない場合には、 単一のコンポーネントを使用できないように確保しなければならないことが明ら かである。従って、上記問いに対する答えは、おそらく、３つのコンポーネント 全部がライセンスをチェックしなければならないことになる。しかしながら、次 には、「ライセンスがどこに置かれるべきであるか？」という問いがなされる。

これは、更に複雑なものとなる。

構築される分配システムは、どの高精度マシンにおいて特定のコンポーネントが 動作するかを予想することが困難であるように益々設計されてきている。理想的 には、最も使用できるリソースを伴うマシンが、常に、特定の要求に応じるマシ ンとなるように、ファンクションの配置を自動的に最適化するようなネットワー クが提案されている。ネットワーク」二でファンクションサーバの分配を構成す るこのダイナミックな方法は、システム又はネットワークマネージャがどのマシ ンが特定のファンクションを実行するかを非常に予想し難いものにし、従って、 上記マネージャがどのマシンにソフトウェアライセンスをロードすべきかを非常 に判断し難いものにする。

たとえシステムマネージャがどのマシンが種々のアプリケーションコンポーネン トを実行するかを予想でき、ひいては、どこにライセンス単位をロードすべきか を予想できたとしても、状態は理想よりも依然として悪いものである。アプリケ ーションの各コンポーネントが独自にライセンス単位割り当ての要求を発するこ とによって問題が出てくる。この特性から、１つの製品をサポートするためにど れほど多くのライセンス単位が要求されるかを誰かが判断しようと試みるという 重大な問題を招く。メイルの例を挙げると、メイルシステムの設計により３つの コンポーネント（即ち、ユーザインターフェイス、ファイルキャビネット及び搬 送システム）全部を同時に使用することが要求されたと仮定した場合に問題が生 じる。このような場合には、メイルシステムの単一の動作をサポートしようとす れば、３つのユニットが必要になることを単純に仮定することができる。しかし ながら、地域的なメイルシステムにおいては、多くのユーザがシステムのユーザ インターフェイス及びファイルキャビネットコンポーネントのみを一度に使用す るだけであることが当然分かる。

従って、更に別のユーザに許可を与えるのに使用できるような幾つかの未使用の ユニットが生じる。これは、ソフトウェアの売主が所望する状態ではない。

動的に構成されたマルチコンポーネント製品に対してライセンスサポートを与え るという問題は、その製品の各コンポーネントを個別にライセンス使用できる製 品と考えそしてこの問題を移行的ライセンスの１つとして処理することにより解 決できるが、これを達成する機構が得られていない。本質的に、コンポーネント のいずれかを使用するライセンスが首尾よく得られた場合に、その許可を用いて それに他のコンポーネントを使用する権利を与えることができると記載された単 一のライセンス文書が形成される。従って、上記例では、ユーザは、そのユーザ インターフェイスを呼び出すことによりメイルシステムをスタートさせる。次い で、そのユーザインターフェイスコードは、ライセンス管理設備にライセンスの 割り当てを質関し、その割り当てをいったん受けていると、使用される他のメイ ルコンポーネントへ割り当ての証明を送る。これら他のコンポーネントの各々は 、ライセンス管理システムが何らかのサービスを実行する前にその「証明」が有 効であることを確認するよう要求するが、これら他のコンポーネントの中で、そ れらに対してなされるべき特定の割り当てを実際に要求するものはない。このよ うに、分配アプリケーションのライセンス付与及び管理ネットワークの複雑さが 著しく減少される。

＾盟ｑ欠旨 本発明は、その広い態様において、ライセンス付きソフトウェアの項目の使用を 管理する方法であって、上記ソフトウェア項目に対してライセンス認可の記憶を 維持し、各ライセンス使用は、複数組の方針コンポーネントを有するソフトウェ ア項目に対してライセンス管理方針の指示を含んでおり、各組の上記方針コンポ ーネントは、上記各組からの方針コンポーネントを同時に用いて複合方針を形成 するための代替え物を与え：ユーザによる上記ソフトウェア項目の１つの要求を 送給して上記ソフトウェア項目を使用するための許可を得、この要求はユーザ及 び上記ソフトウェア項目を識別するものであり；上記要求に応答して上記記憶に アクセスし、上記ソフトウェア項目に対する上記ライセンス認可からの情報を得 ：上記ユーザ及び上記ソフトウェア項目の上記識別を上記情報と比較すると共に 、上記複数組のライセンス管理方針コンポーネントによって課せられる制約とも 比較して、上記要求の許可又は拒絶を発生し；そしてこの許可又は拒絶を上記ユ ーザへ送給するという段階を備えた方法に関する。

本発明の一実施例によれば、ライセンス管理システムはコンピュータシステムに おけるソフトウェア製品の使用を明らかにするために使用される。このシステム は、同時に使用できる種々の別々のスタイル及びコンチクストを有する管理方針 を確立するライセンス管理方法を用いている。ライセンスサーバはライセンスを 執行し、各々のライセンス付き製品は、米国特許第４，９３７，８６３号と同様 に、スタート時にライセンスサーバへ通話してその使用が許可されるかどうかを チェックする。ライセンスサーバは、これが執行するライセンスの記憶、製品使 用認可と称する、を維持する。ユーザからの呼び出しを受けると、ライセンスサ ーバは、その製品使用認可をチェックし、要求された特定の使用が許可されるか どうか決定し、もし許可されれば、その要求を発しているユーザノードへグラン ド信号を返送する。ライセンスサーバは、ライセンス付き製品に対する製品使用 認可のデータベースを維持していて、更新のため及びユーザから要求を受けたと きにこのデータベースにアクセスする。このライセンス管理システムは、ローカ ルエリアネットワークを使用する分配コンピュータシステムにおいておそらく最 も有用であるが、スタンドアローン又はクラスター型のシステムでも動作できる 。分配システムでは、ライセンスサーバがサーバノード上で動作し、ライセンス が執行される製品はクライエントノードにある。しかし、ある実施例では、ライ センス管理ファンクションとライセンス付き製品が同じプロセッサにおいて実行 される。

上記製品使用認可は、「スタイル」、「コンチクスト」、「継続時間」、「使用 要求決定方法」と称するコンポーネントにより種々のライセンス代替物を許すラ イセンス管理方針を定めるように構成される。スタイルは、割り当て又は消費性 のものである。割り当て性のスタイルとは、要求を受けたときにライセンスの単 位をユーザに一時的に割り当て、ユーザが終了したときにプールに返送しそして 別のユーザが要求をしたときにそれらの単位を再使用できることを意味する。

消費性のスタイルとは、ユーザノードが有効な要求をしたときに使用できるプー ルから単位を差し引きそして再使用のために返送するのではなく「消費」してし まうものを意味する。コンチクスト値は、特定形式のＣＰＵ、特定のユーザ名、 特定のプロセス、等によって、例えば、特定のネットワーク上で使用を許すべき であるようなコンチクストを定める。継続時間の値（スタイルコンポーネントと 共に使用される）は、要求があったとき、使用が完了した後、等々において使用 できる単位プールからライセンス単位を差し引くべき時間に関するものである。

使用要求決定方法は、ユーザノードからのライセンス要求に応答して料金が課せ られるライセンス単位の個数に関する情報を定めるか又は与えるように特定され るもので、例えば、あるＣＰＵプラットフォームは、他のものよりも非常の多数 のライセンス単位の料金が課せられる。使用要求のテーブルが維持され、そして 上記の決定方法は、例えば、このテーブルをいかにアクセスするかを特定する。

重要なポイントは、ユーザノード（ひいては、ソフトウェア製品）が、ユーザ、 プラットフォーム、プロセス等によってそれ自身を識別する要求しか行えないこ とであり、ライセンス管理設備は、ライセンスを許可できる（即ち、単位が割り 当てのために得られる）かどうかに関わりなく計算を行い、ユーザノードはライ センスデータ又は計算のいずれにもアクセスしない。ライセンス文書を記憶し、 そして要求があった際に、ライセンス付き製品にそれらがライセンス期間のもと て動作できるかどうかを知らせる中央の設備、即ちライセンスサーバがある。

１つの実施例における重要な特徴は、上記の主設備と同様の別のライセンス管理 設備を形成することによりライセンスの執行が組織のサブセクションに委任され ることである。例えば、製品使用認可において許可された幾つかの単位が別のサ ーバに委任され、そこで、このサーバによりサービスを受けるユーザノードが要 求を発しそしてグランド信号を受け取る。

ライセンス管理設備は、ライセンスそれ自体を形成することはできず、ライセン スの発行者からライセンス文書（製品使用認可）を受けねばならない。本発明の 全ライセンス管理システムの一部分として、ライセンス文書発生器が設けられて おり、これは、顧客と交渉するときにソフトウェアの所有者の認可のもとて製品 使用認可を形成する。従って、本発明の全ライセンス管理設備には３つの別々の 権利がある。即ち、それは、（１）ライセンスを発行する権利と、（２）ライセ ンスを管理する権利と、（３）ライセンス付き製品を使用する権利である。これ らの各々はライセンス文書を規定の方法でのみ使用する。ライセンス発行者手段 はライセンス文書を発生することができる。ライセンスマネージャ（又はここで はライセンスサーバと称する）は、ライセンスのもとで使用する権利を製品に許 可することができ、そしてライセンス文書によって定められたようにライセンス 単位の一部分を別のサーバによって管理するように委任することができ、即ち製 品に対して権利を許可する方法は、製品からのある定められた呼び出しに応答す ることによるものである。ライセンス付き製品はライセンスサーバへ幾つかの呼 び出しを行って、ライセンス文書、問い合わせ又は報告に基づいて権利の許可を 得ることができるが、通常文書それ自体にアクセスすることはできない。

上記したように、移行的ライセンスは１つの実施例の重要な特徴である。これは 、あるユーザノードが、別のユーザノードに置かれた別のソフトウェア製品を使 用するための許可を得る機構を設けることであり、これは、「発呼カード」を用 いた発呼認可及び発呼者認可と称され、これらは製品使用認可によって特に許可 されねばならない任意の特徴の例である。ユーザノードは、別のノードのプログ ラムを使用するために手順呼び出しを行う許可を得なければならず、この許可は 前記したようにライセンスサーバへの要求によって得られ、この許可は発呼カー ドの形態をとる。発呼カードが第２のノードによって受け取られると（即ち、手 順呼び出しがなされると）、第２のノードによりライセンスサーバへ要求が送ら れ、その発呼カードが有効であることが確認され（製品使用認可により）、もし 許された場合にはユーザノードへグランド信号が送られる。このように、全ての ノードがリモート呼び出しによりプログラムの使用権をもっことができるが、１ つだけがライセンス単位を消費する。

天面ｐ簡単μ説朋 本発明の新規な特徴と考えられる特許請求の範囲に指摘する。しかし、本発明、 その別の特徴及び効果は、添付図面を参照した特定の実施例の以下の詳細な説明 より理解されよう。

図１は、本発明の一実施例によるライセンス管理動作を実施するのに用いられる 分配式コンピュータシステムのブロック図である。

図２は、図１に示すシステムのライセンス文書発生器によって発生されてライセ ンスサーバによって記憶されたライセンス文書即ち「製品使用認可」の内容を示 す図である。

図３は、本発明の一実施例により図１のシステムで実施されるライセンス管理方 針を形成するライセンススタイル、コンチクスト及び継続時間の代替物を示す図 である。

図４は、本発明の一実施例により図１のシステムに使用されたライセンス使用要 求テーブル（ＬＵＲＴ）の一部分を一例として示す図である。

図５は、本発明の一実施例により図１のシステムにおいてユーザノード（クライ エント）によって実行されるプログラムの論理流れ図である。

図６は、本発明の一実施例により図１のシステムにおいてライセンスサーバによ り実行されるプログラムの論理流れ図である。

図７は、図１のシステムにおいて発呼カードの使用例で行われた通話及び返送を 示す図である。

実施列９群担μ脱朋 図１を参照すれば、本発明の一実施例によるライセンス管理設備は、ライセンス サーバ１０を中心とするものであり、このライセンスサーバは典型的に顧客のメ インオフィスに配置されたＣＰＵを含み、これはオペレーティングシステム１２ のもとで以下に述べるライセンス管理プログラム１１を実行する。ライセンスサ ーバ１０は多数の委任前手段１３と通信し、これも同様に会社や組織の部又は課 に配置されたＣＰＵを備え、その各々もオペレーティングシステム１５のもとて ライセンス管理プログラム１４を実行する。ライセンス管理プログラム１４はメ インサーバ１０で実行するプログラム１１と同じであり、サーバ１０とサーバ１ ３の機能の唯一の相違は、サーバ１３が以下で述べるようにサーバ１０に対して 許可されたライセンス単位の委任されたサブセットを有することである。ＣＰＵ １３は、次いで、多数のユーザ１６のサーバとなり、これらユーザはライセンス 付きプログラム１７が実際に実行されるＣＰＵノードである。ユーザＣＰＵｌ６ で実行するプログラム１７は、アプリケーションプログラム（又はオペレーティ ングシステム等）であり、これらプログラムには本発明によりユニット１８及び １９が付加され、これらプログラムが実行の前にそのサーバ１３（又は１０）へ 質問をすることができると共に、実行の後に一実施例においてはリモート手順呼 び出しのようにクライエントスタブ１９を使用して報告を戻すことができるよう にする。ユーザノード１６は、実行することのできる多数の異なるプログラム１ ７を有することができ、通常、種々のユーザノード１６は、互いに他のユーザノ ードとは異なる１組のプログラム１７を各々有し、それらは全てライセンス管理 プログラム１４又は１１によって執行される。「プログラム」及び「ライセンス 付き製品」という用語は、エレメント１７を参照するのに用いられるが、執行さ れる製品は、プログラムのセグメントであってもよいし、別のプログラムによっ て呼び出されるファンクション又は特徴であってもよいし、或いは単なるデータ （例えば、プリンタのフォントのような）であってもよいし、完全なスタンドア ローンのアプリケーションプログラムであってもよいことを理解されたい。ライ センスサーバ１０は、大きな組織において通常そうであるように、ネットワーク ２１によって委任者サーバ１３と通信し、委任者サーバ１３の各々はネットワー ク２２によってユーザノード１６と通信し、これらのネットワークはエサ−ネッ トでもよいし、トークンリングでもよいし、ＦＤＤＩタイプ又は同様のものでも よく、或いは又、ユーザノード１６は、単に、マルチユーザシステム上の１群の ターミナルであって、委任者サーバがホストＣＰＵとなってもよい。ユーザノー ド、サーバノード、通信ネットワーク等の特定のハードウェア構造と、オペレー ティングシステム１２又は１５は、本発明の特徴の有用性については重要ではな く、唯一の重要なポイントは、問題とするソフトウェア製品１７のユーザＣＰＵ １６がそれらの各々のサーバノード１３又は１０と容易に且つ迅速に通信できる ことである。一実施例において、リモート手順呼び出しくＲＰ　Ｃ）は、システ ムのコンポーネント間のインターフェイスに対する通信媒体として使用され、以 下で述べるように質問及び許可を取り扱う。リモート手順呼び出しはローカル手 順呼び出しと同様であるが、リモートノードに配置された手順へ通信ネットワー りによって行われる。

ユニット１９のファンクションは、リモート手順呼び出１７という意味でクライ エントスタブの機能である。ライセンスサーバ１０への呼び出しはこのスタブ１ ９を経て行われ、返送信号はこのスタブ１９によって受け取られてプログラム１ ７へと通される。スタブ１９は、ネットワー・り上の他のノード、例えば、サー バ１０のネットワークアトｌメスを得るためのものである。又、スタブ１９は、 サーバ１０へ通すコンチクスト（以下で述べる）を決定する役割も果たす。［プ ライベート１式のライセンス利用性の決定方法が用いられる場合には、このタス クがアプリケーションプログラム１７によって行われるのではなくて、ユニット １８がこれを実行するように働くが、一般の決定方法が通常そうであるように使 用される（ライセンスサーバを用いて）場合には、ユニット１８は、実行をスタ ートさせ、呼び出しを通し、そしてプログラム１７とユニット１９との間で前後 に戻る単なるコードとなる。

ライセンス管理プログラム１１を使用するライセンスサーバ１０は、多数のライ センス文書又はライセンス（製品使用認可）より成るライセンスデータファイル ２３を維持すると共に、各ライセンス付きプログラムの全てのユーザＣＰＵｌ６ の使用状態の記録であるログ２４も維持する。委任者サーバ１３も同様のライセ ンスデータベース及びログを維持する。ライセンスサーバ１０は、ライセンスを 発行する権限はもたず、ライセンス発行者手段２５からライセンスを受け取らね ばならない。この発行者手段２５も、オペレーティングシステム２７のもとでラ イセンス文書発生プログラム２６を実行するＣＰＵである。ライセンス発行者手 段２５は、ライセンス使用されるプログラム又はソフトウェア製品のプロプ。

−サ２８の制御のもとにあってもよいし、或いはプロデューサ又はオーナー２８ からライセンスを許可する権限を受けたディストリビュータによって制御されて もよい。ライセンス発行者手段２５とライセンスサーバ１０との間にあってライ センス文書を供給する通信リンク３０は、ネットワークの形式でもよいし、モデ ムを用いた電話線であってもよいし、或いは、例えばディスクやＣＤ　ＲＯＭに よる物理的な供給路を含んでもよい。同様に、ライセンス使用されるソフトウェ ア製品、即ちＣＰＵ１６で実行されるアプリケーションプログラム１７を供給す る方法は、本発明のライセンス管理設備にとって重要ではなく、これらのソフト ウェア製品は、例えば、通信リンク３０．ネットワーク２１及び２２、物理的に 分配されたＣＤ　ＲＯＭ又はディスクのようなある適当な手段によって供給され る。

図１には分配システムにおいて動作するものとして示すが、最も簡単なケースで は、本発明のライセンス管理設備は単一のＣＰＵにおいて動作される。ライセン ス管理プログラム１１及びアプリケーションプログラム１７は同じＣＰＵで実行 されるが、この場合、ライセンス文書は前記したようにこのＣＰＵのデータベー ス２３に記憶され、ユニット１８からライセンスサーバへの呼び出しはＲＰＣで はなくてローカルとなる。しかしながら、分配システムの場合と同様に、ライセ ンス付き製品は依然としてライセンス文書にアクセスせず、たとえ全てが同じＣ ＰＵにおいて実行されているとしてもサーバプログラムへ質問を出せるに過ぎな い。

図１の分配システムの動作においては、プロデューサ２８がそれに代わってライ センスを許可する権限を発行者手段２５に与える（プロデューサ及び発行者手段 は単一のエンティティであることもあるし多数のエンティティであることもある ）。ライセンス文書発生プログラム２６は、ユーザ（個人）の制御のもとてライ センスを発生する（通常はプログラム２６のユーザとサーバ１０のユーザとの間 の交渉の結果）。このライセンスは、製品使用認可と称され、リンク３０を経て サーバ１０へ送うれる。サーバ１０のライセンス管理プログラムは、この製品使 用認可をデータベース２３に記憶し、委任が許可されたオプションである場合に は、許可された使用の一部分を委任者サーバ１３へ分配し、そこで同様にデータ ベースに記憶される。その後、ライセンスの執行はユーザノードからの問い合わ せのみに応じたものとなる。プログラム１７の実行が始まると、ユニット１８が 呼び出され、この特定ノードについてライセンスを使用できるかどうかチェック する。ユニット１８は、ライセンス管理プログラム１４（又は委任者がいない場 合には１１）へ要求を送り（例えばＲＰＣにより）、そこでデータベース２３に 記憶された製品使用認可をチェックしてその使用が許可されたものであるかどう か調べられる。もしそうであれば、返送信号がユーザノード１６へ送られて、継 続の許可が与えられる。プログラム１７の実行が終了すると、ユニット１８が再 び呼び出され、認可が下ろされるという信号がこの場合もＲＰＣによってライセ ンス管理プログラムへ送られ、従って、ライセンス管理プログラムは、例えばロ グ２４にその使用を記録する等の適当な処理をすることができる。

これらの動作を実行するために、ライセンス管理プログラム１１又は１４は、ク ライエントインターフェイス３１、データベースインターフェイス３２、管理イ ンターフェイス３３、及び委任者サーバ１３（もしあれば）と通信するサーバ間 インターフェイス３４を含む多数のファンクションを備えている。クライエント インターフェイス３１は、以下で述べるように、ユーザノード１６から受け取っ た要求と、これらの要求から生じる返送信号とをを取り扱う。データベースイン ターフェイス３２は、データベース２３内にライセンス情報を記憶したりそこか ら検索したりすることと、ライセンスの使用状態をログ２４に記録したりこのデ ータを検索したりすることとを取り扱う。管理インターフェイス３３は、発行者 ２５から製品使用認可を受け取りそしてデータベースインターフェイス３２を経 てデータベース２３を維持するというタスクを取り扱う。サーバ間インターフェ イス３４は、委任者サーバ１３と通信するタスクであって、製品使用認可の指定 された部分を送信したり、ライセンス管理ファンクションを個別に実行する他の ライセンスサーバと通信したりすることを含むタスクを取り扱い、例えば、発呼 カードを確認するための通話がこのような別のサーバに送られる。委任者サーバ 又は他のライセンスサーバがない場合には、もちろん、サーバ間インターフェイ ス３４は何も機能を果たさず、アイドル状態である。

サーバ１０のプログラム１１についてのライセンス管理動作のベースを形成する ライセンス文書即ち１−製品使用許可」は、前記ｊまた情報を含むデータ構造体 と１、て図２に示されており、実際には、この製品使用認可は、図示されたよう に厳密に形成されたフす−マットではなくて、もっと抽象的なデータ構成である のが好ましい。例えば、製品使用認可と、データベース２３に記憶されるか又は 図１のシステムのコンポーネント間に通される同様の文書は、いわゆるタグ長さ 値データフォーマットのものであり、即ち、データ構造体は識別タグ（例えばＰ ＵＡ即ち製品使用認可）で始まり、その後に長さを示すフィールドが続き、その 後にそれ自身の値（内容）が続くというものである。このタグ長さ値フォーマッ トを用いた１つの形式のデータ処理が、ＡＳＮ、１即ちアブストラクト・シンタ ックス・ノーチージョンと称する国際規格である。いずれにせよ、図２に示され た文書３５は、単にデータの種々の項目を説明するためのものであって、情報を 記憶する方法を表すためのものではない。ここに示すフィールドの幾つかは、あ るときには存在し他のときには存在せず、そしてその幾つかはオプションであり 、又製品使用認可は、ここに示して説明しない更に別のフィールドを含んでもよ い。

又、委任者に対してこの形式の文書の一部分のコピーがとられ、従って、図２の この表示は、図１のシステムに使用される多数の文書の複合体であることに注意 されたい。文書３５は、製品名、プロデューサ、バージョンナンバー、発売日等 によってソフトウェア製品を識別するフィールド３６を含んでいる。発行者２５ はフィールド３７において識別され、そしてライセンス保持者（通常はライセン スサーバ１０の所有者）はフィールド３８において識別される。ライセンス許可 の重要な条項がフィールド４０ないし４６に定められる。開始日及び終了日はフ ィールド４０に指定され、これらはライセンスが有効になるときと終了するとき の正確な時間（日付、時、分、秒、等）を記憶し、従って、ライセンスはある将 来に時間に開始しそして特定の時間に終了するように許可される。これまでの慣 例では終了日のみを指定するのであって、ここで使用する開始日は指定していな いことに注意されたい。発行者２５、サーバ１０及び１３、そしてユーザノード １６を含むノードの各々は、標準と称するローカルタロツクによって時間の値を 維持し、従って、ライセンス管理設備で固有に行われることは、フィールド４０ の開始日及び終了日情報と比較するための時間基準を維持することである。許可 される単位はフィールド４１に指定され、これら単位はプログラム使用について の任意の量的な尺度である。委任者サーバ１３では、この単位フィールド４１は オリジナルの製品使用認可にお番フる弔位フィールドのあるサブセットを有する 。

これら単位がユーザ１６に許可されるか又は委任されると、その許可に対して使 用できる残りの単位が、サーバにより使用される文書のコピーのサブフィールド ４２に指示される。管理方針はフィールド４３−４６を専有し、以下で述べるよ うに、スタイル、コンチクスト、時間巾及びＬＵＲＤＭ　（ライセンス使用要求 決定方性）を含む。スタイルフィールド４３は、ライセンス使用される単位が「 割り当て」スタイルによって制御されるか、「消費」スタイルによって制御され るかを指定し、或いはこれらのスタイルが単位の消費又は割り当てを考慮するの に用いる方法である場合には他の「プライベート」アルゴリズムによって制御さ れることを指定する。コンチクストフィールド４４は、製品使用又はライセンス の管理が行われる位置及び環境、即ちＣＰｔＪであるか個々のユーザであるか又 はネットワークであるか等々を指定する。継続時間フィールド４５は、ユーザに 許可されるライセンスがアサイメントによるものであるか、トランザクションに よるものであるか或いは即時のものであるかを指示する。ＬＵＲＤＭフィールド ４６は、ある場合には以下で述べるようにフィールド４７として示すライセンス 使用要求テーブル（ＬＵＲＴ）を用いたライセンス使用要求決定方法を指示する 。

図２の製品使用認可３５に含まれた更に別のフィールド４Ｌ−５４は、委任認可 、発呼認可、オーバードラフト認可、組み合わせ認可、トークン、署名、チェッ ク和、等々の特徴を定める。これらについては、以下で説明する。

委任フィールド４８が真である場合には、ライセンスサーバ１０がライセンス単 位を多数のサーバＪ３に分配する。タイムリミツトを課してもよく、即ち時間切 れするまで他のハードウェアシステムへ単位を委任することができる。この委任 により執行者はシステムの応答時間を改善し且つその弾力性を増すように単位を 分配することができる。例えば、通信ネットワーク２１は、ローカルサーバ１３ が多数のクライエント又はユーザ】６を有するようなリモート設備へのサテライ トリンクを含んでもよく、この場合に、サーバ１３への通話は、サーバ１０へ通 話をしなければならない場合よりも遥に速く完了する。又、執行のための予算内 にライセンス使用単位を割り当てる方法として委任を用いてもよい。通常、委任 認可の特徴は、発行者によって価格が付けられることであり、即ち委任認可で１ ０００単位を許可するライセンスは、この認可がない場合よりも価格が高くなる 。

フィールド４９は、発呼認可及び／又は発呼者認可を含む。フィールド４９の発 呼者認可が真である場合には、その製品が、その製品の使用を要求する他の名称 の製品から通話を受けることか許され、条件が合致すれば（識別された発呼者が 認可されれば）、サーバは以下に述べるように発呼カードを許可することができ る。発呼認可が真である場合には、その製品が他の製品へ通話を行うことができ る。いずれも真でない場合には、その製品は発呼カード特徴を用いて通話を行う ごとも受けることもできない。図１を参照すれば、製品１７ａが、異なったユー ザノード１６で動作している製品１７ｂの特徴に対してリモート手順呼び出しを 行いたい場合には、発呼カードの要求を含む通話をそのサーバ１３へ行い、もし それが許されると、製品１７ａへの返送信号は発呼カード４９ａを含むことにな る。次いで、製品１７ａは、発呼カード４９ａと共にＲＰＣの通常の方法で製品 １７ｂへ通話を行い、製品１７ｂは、そのサーバ１３への通話によってそれを確 認した後に、その呼び出された手順を実行し、その返送信号を製品１７ａへ発生 ずる。この発呼カードの特徴は、分配アプリケーションにおいて重要である。

例えば、他のＣＰＵヘタスクを指定することにより分配システムにおいて製品を より速く実行できる場合には、どのライセンス方針が必要とされるかの発行がな され、即ちそのタスクの一部分を実行している各ノードごとにライセンスを得て 単位の割り当てを消費するかもしくは受け取るか、或いは単にタスクを管理する かについての発行がなされる。これは、はとんどのアプリケージタンの場合、こ の発呼カード概念を用いることによって解消される。このような製品についての 製品使用認可は、その発呼認可フィールド４９がイネーブルされており、発呼カ ードを発行することができる。この特徴は典型的に別途の価格となる。

図２の組み合わせ認可フィールド５０は、多数の製品使用認可からの単位を組み 合わせることによってユーザノード１６からのライセンス要求を満足できるかど うかを決定する。異なる方針の価格でライセンスを購入しそしである製品使用認 可からの単位をオーバーフロー等についてのみ使用するのが効果的である。或い は、その他の理由で、委任されたサーバ又はユーザノードの間で単位を「借りた り」、「貸したり」するのが効果的である。このファンクションは、フィールド ５０の内容によって許されたり拒絶されたりする。

オーバードラフトフィールド５１は、たとえ単位使用フィールド４２がゼロであ るか或いは要求された使用を許すのに小さ過ぎても、ユーザノード１６からの要 求された割り当てが許可されるかどうかの判断をする。顧客の内部の運用上の目 的で、オーバードラフトは無制限にすることができるか、或いはサーバ１０によ って特定のオーバードラフトプールを設定することができる。即ち、オーバード ラフトの値はオリジナルライセンスでは無制限であってもよいが、ライセンスの 内部分配コピーについては制限もしくはゼロにすることができる。従って、発行 者２５により顧客に送られる製品使用認可は、フィールド５１によって許された オーバードラフトをもつことができるが、顧客はそれ自身の予算のためにオーバ ードラフト許可を拒絶してもよい。いずれの場合にも、オーバードラフトが許さ れた場合には、ログ２４からの記録された使用状態が使用できる単位を越えたこ とを示したときに、ある会計周期で追加料金を発行者に支払わねばならない。

オーバードラフトを拒絶］、た場合には、要求の割り当てを行うユーザノードの ユニット１８が、ライセンス許可が得られないことを製品１７に知らせるように 構成される。その目的は、アプリケーションプログラムの実行を防止することで はなく、ライセンスサーバは、ライセンスマネージャがそのアプリケーションの 実行が認可されたと判断したかどうかを単にそのアプリケーションに知らせるだ けである。アプリケーションそれ自体は、実行が認可されない場合にそれ自体停 止するように構成することもできるし、或いはあるファンクション（例えば、フ ァイルをセーブする機能や、プリントする機能、等）を停止するように構成する こともできるし、完全な機能状態で継続するように構成することもできる。ライ センス管理設備の目的は、強制でも「コピー保護」でもなく、単にライセンス管 理のためである。

任意のトークンフィールド５２は、図２の製品使用認可３５において使用できる 。このフィールドは、発行者又はユーザによって所望されるコメント又は他の情 報を含むことができる。例えば、このトークンフィールドには電話サポート番号 が含まれてもよく、製品１７がその「ヘルプスクリーン」を示すときに、その番 号が挿入される。この番号は、サーバ１０がユーザからの要求割り当てメツセー ジに続いて返送を行うときにユーザノードへ送られるアーギュンメント、即ちデ ータの一部分である。又、このフィールドは、「プライベート」スタイルで用い られる情報を記憶するのにも使用でき、この場合、ユーザノードへ返送されるこ のフィールドからの情報がアプリケーションプログラム１７又はスタブ１９によ って使用され、アプリケーションを実行できるかどうかの判断がなされる。

製品使用認可３５の符号フィールド５３は、重要な特徴を発揮する確認機構の一 部分である。このフィールドは、ライセンスそれ自体のデータを表すようにエン コードされたデジタル符号及び顧客が知らない他のエンコード方法を含んでおり 、従って、エンコードアルゴリズムが分からない限り複製できないようになって いる。好ましい実施例では、いわゆる「パブリック／プライベートキー」のエン コードシステムが符号フィールド５３に使用される。符号５３を発生するのに用 いられるエンコードアルゴリズムは、プライベートキーを用いて発行者２５に分 かり、パブリックキーを知っている者はその符号をデコードしてそれが有効であ るかどうかを判断することはできるが、エンコードアルゴリズムを判断すること はできず、従って、忘れた符号を形成することはできない。従って、サーバ１０ は、発行者２５に対して独特のパブリックキーを知っていれば、ライセンス文書 ３５が本物であるかどうかを判断できるが、それ自身でライセンス文書を発生す ることはできない。しかしながら、サーバが委任の権利を与えるを効なライセン ス文書を有する場合には、それ自身のプライベートキー（他の全ての発行者又は サーバとは異なる）が指定され、その委任者１３は、サーバ１３に対するパブリ ックキーが与えられるので、有効な委任ライセンスが送られるかどうかを判断す ることができる。従って、フィールド５３は、発行者２５からのオリジナルの符 号と、委任者１３へ送られたときのライセンスサーバの符号の両方を含む。それ 故、任意の符号に対するパブリックキーを使用するデコードアルゴリズムがライ センスサーバ１０又は委任者サーバ１３によって使用されて、製品使用認可３５ がデータベース２３に記憶される前に確実なものとなるよう確保する。デジタル 符号５３に関連してチェック和フィールド５４があり、これは、ある既知のアル ゴリズムに関連した値を、製品使用認可３５それ自体におけるデータに単にエン コードするものである。このフィールドは、データがシステム内において記憶さ れ、再呼び出しされそして送信されるときにデータの崩壊を単にチェックするた めに用いられる。即ち、このチェック和は、保安のためではなくて、データ確認 のために使用される。

図２のライセンス文書即ち製品使用認可３５を用いて実施されるライセンス管理 システムを中心とする２つの考え方は、フィールド４１又は４２に指定される「 ライセンス単位」と、フィールド４４に指定される「フンチクスト」である。

ライセンス単位は、ライセンスによって許される製品使用の抽象的な数値尺度で ある。製品１７（又は製品の機能又は特徴）がライセンスチェック要求をすると きには、サーバ１０のライセンス管理プログラム１１が、この特定の製品使用を 許すためにどれほど多くのライセンス単位が要求されるかを計算し、これは、あ る場合にはＬＵＲＤＭフィールド４６を用いたライセンス単位要求である。

「−コンチクスト」は、製品の使用又はライセンスの管理が行われる位置及び環 境を定める１組のタグ付きの値である。コンチクスト値は、図２の製品使用認可 ３５のフィールド４４に指定され、ライセンスを管理する環境及び製品使用を行 う環境を制限する。又、フィールド４４にはコンチクストテンブリットも指定さ れ、単位割り当ての目的で製品使用を区別するのに、製品使用の完全なコンチク ストのどの部分（サブコンチクスト）が重要であるかを指示１９、これが指定さ れたときには、個々の製品使用がライセンス単位を制御されたやり方で分担でき るようにする。

フィールド４３に指定される方針の２つの一般的な形式は、割り当てと消費であ る。割り当て式の方針は、ライセンス保持者に特定数のライセンス単位（フィー ルド４１）を許しそしてこれら単位の割り当てを考慮するのに使用しなければな らない方針を指定する。割り当て式ライセンスによって管理されるソフトウェア 製品１７は、ユーザへのサービスを実行する前に適当な数のライセンス単位が割 り当てられたことを確認する必要がある。典型的に、この単位割り当ては、製品 １７を動作するときか或いは特定のプラットフォーム（ユーザＣＰＵ１６）にお いて製品の使用が可能となったときに行われる。これら単位は、典型的に、製品 が実行されているか又は実行するようにイネーブルされている時間全体にわたっ て製品１７に割り当てられたままとなる。処理が終わるか又はディスエイプルさ れると、その割り当てられた単位が解除され、ソフトウェア製品１７の他の場合 （製品を動作する他のユーザ１６）に割り当てられるようにする。一般に、フィ ールド４２においてライセンス単位が割り当てられないままでいる限り、ライセ ンスの保持者はライセンス付き製品の利用性を高めることが契約上許される。

しかしながら、ユーザが終了した後に単位使用フィールド４２へ単位が戻される のでこのような使用によってライセンスが尽きることはなく、別のユーザに対し て再び許可することができる。

方針フィールド４３に示された消費性単位をベースとするライセンスは、特定数 の初期ライセンス単位を（フィールド４２から）ライセンス保持者に許可し、こ れら単位の消費を考慮するのに用いる方針を指定する。消費性ライセンスによっ て管理されるソフトウェア製品１７は、製品によって与えられるサービスを表す ように適当数のライセンス単位を消費させる。いったん消費されると、これら単 位を再使用することはできない。従って、ライセンス付きソフトウェア製品１７ を使用するたびに、将来使用できる単位数が減少する。これは、「計量」型の方 針とも称され、電気や水道等の測定された消費量と概念的に同様である。フィー ルド４２において使用できる単位の数がゼロに達したときには、そのライセンス はその製品の将来使用を禁止することが必要となるか、或いはアーギュメントに より使用できる単位の数を減少し続けられるようにし、その結果、フィールド４ ２には使用できる単位の負の数が蓄積される。はとんどの消費性単位ベースのラ イセンスは、ライセンス発行者２５に支払うべきライセンス保持者の債務を表す のに負の単位を考えることが明らかである。トランザクションログ２４は、消費 性ライセンスに用いられた単位の記録を与えるオーディット・トレイルを維持し ている。

図３を参照すれば、管理方針の主たるエレメントがテーブルに示されており、フ ィールド４３．４４．４５及び４６の考えられるエンティティがリストされてい る。スタイルのエンティティ４３については、上記した割り当て性及び消費性と 、［プライベートと称する分類とが考えられ、この分類は、現在は規定されてい ないが特に所与の製品に対しそれ自身の独特のアルゴリズムを用いて形成される べき管理のスタイルを表している。はとんどのライセンスは、図３に名称の付け られた代替え物を用いて執行できるが、現在考えられていない代替え物を含むよ うな将来的な拡張を考慮し、或いは独特のソフトウェアに対する特殊な環境を許 すために、この「プライベートの選択か含まれているが、これは単に製品１７が それ自身の使用条件を発生することしか意味しない。「プライベート」代替え物 を除くと、ライセンスの管理は、製品１７にあるのではなくて、ライセンスサー バ１０（又は委任者サーバ１３）のライセンス管理プログラム１１の制御を完全 に受ける。全ての製品１７は、ユニット１８を経て、クライエントインターフェ イス３１を経て、サーバ１０へ要求の問い合わせを行い、そして終了時に報告を 行う。

コンチクストフィールド４４は、単位の割り当てが要求されるかどうかを決定す る際に使用すべき実行コンチクスト名のコンポーネント（サブコンチクスト）を 指定する。ライセンスデータは、常に、ある名称のライセンスコンチクストのた めに又はそのコンチクスト内で使用もしくは割り当てられ、コンチクストは、「 プラットフナ−ムコンチクスト」及び「アプリケーションコンチクスト」を含む ことができる。プラットフォームコンチクストとは、図３にリストされたように 、特定ネットワーク、実行ドメイン、ログ・イン・ドメイン、ノード、プロセス ＩＤ又はプロセスファミリー、ユーザの名称、製品名称、オペレーティングシス テム、トクテイハードウェアプラットフオームのようなものである。アプリケー ションコンチクストとは、アプリケーション（製品１７）から送られる情報、例 えば、ライセンスの利用性を決定する［プライベートｊ方法に使用される情報で ある。フンチクスト名称はこれらのうちの幾つかを使用することができ、この場 合には、全てのサブコンチクストの値を単一のコンチクスト名称、例えば、ＶＭ Ｓオペレーティングシステムを用いたＶＡＸ３１００プラットフォーム、へと連 結することにより構成される。

継続時間フィールド４５は、ライセンス単位を特定のコンチクストに割り当てる 継続時間又は有効な消費性使用を定める周期の時間巾を画成する。「アサイメン ト」の形式の継続時間については、再アサイメント制約の仕様も以下で述べるよ うに与えられる。図３から明らかなように、「トランザクション」、［アサイメ ントＪ及び「即座」の３つの形式の持続時間がある。

トランザクションの形式の継続時間は、割り当て性の方針に対して指定されたと きに、ライセンス要求を受け取った際にライセンス単位を指定のコンチクストに 割り当てねばならないことを指示すると共に、それに対応するライセンス解除を ユーザノード１６から受け取ったときにはこれらの単位を割り当て解除して、使 用できる単位のプールへ返送しなければならないことを指示する。プロセス又は コンチクストが異常な終わり方をしてオリジナルライセンス要求をすることは意 味的にライセンスの解除と同じになる。一方、消費性の方針に対して指定された ときには、この継続時間形式は、ライセンス要求を受け取った際にライセンス単 位を指定のコンチクストに割り当て、そしてトランザクションが首尾よく完了し たことを表すライセンス解除を受け取ったときには、使用できる単位のプール（ フィールド４２）から永久的に除去しなければならないことを指示する。エラー 状態を保持するライセンス解除を受け取るか、或いはプロセッサコンチクストの 異常終了によってオリジナルライセンス要求がなされたときには、割り当てられ た単位が割り当て解除され、使用できる単位のプール（フィールド４２）へ返送 される。

図３のアサイメント継続時間形式（図２のフィールド４５）は、要求された単位 が特定のコンチクストに既に指定されているはずだという制約を課する。このア サイメントにおいて指定しなければならないサブコンチクストは、コンチクスト テンプレットに与えられたものである。「再アサイメント制約」を課してもよく 、これは、いかに早く再アサイメントを行えるかについての制限である。例えば 、３０日の再アサイメント制約は、特定のコンチクストに指定された単位を３０ 日ごと以上の頻度で再アサイメントできないことを要求する。これは、別のコン チクストのユーザがその製品に対して割り当て要求通話を行ったときに、単に単 位を再アサイメントするだけでライセンスの趣旨が境界付けされるのを防止する 。このアサイメント制約に関連して、割り当ての最小継続時間を示すために、「 再割り当て制限」も課せられ、プロセスのコンチクストテンプレットがある場合 には、所与の時間にソフトウェア製品の使用回数をカウントするという趣旨にな るが、ソフトウェアが対話モードではなくてバッチで実行される場合には強力な マシンにおいて非常に迅速に実行することができ、従って、無制限の使用状態の 中でも非常に僅かな同時使用しか許されず、ある時間周期の再割り当て制約を課 することにより、ライセンスの趣旨を境界付けするこの仕方が制限される。

即座の継続時間形式（図２のフィールド４５）は、使用できる単位（フィールド ４２）のプールからの適当な数のライセンス単位の割り当て又は消費を、ライセ ンス要求を受け取った際に直ちに実行しなければならないことを指示するのに用 いられる。従って、ライセンス解除の受け取り又は異常終了はライセンス管理シ ステムに何の衝撃も与えない。割り当て性の方針に対する継続時間として指定さ れたときには、ライセンス要求のときに適当な数のライセンス単位が使用できる かどうかを単にチェックするだけの作用となる。消費性の方針に対する継続時間 として指定されたときには、ライセンス要求の時間に使用できるプールから適当 な数のライセンス単位を差し引くという作用になり、その後は、ユーザＣＰＵ１ ６の欠陥又はネットワークリンクの故障といった異常終了によりそれら単位が回 復することはない。

ＬＵＲＤＭ即ちライセンス単位要求決定方法のフィールド４６は、図３に示す代 替え物を有し、ライセンス要求に応じて割り当て又は消費されねばならない単位 数を計算するのに用いられる情報を記憶する。このフィールドがテーブルルック アップ形式を指定する場合には、現在ライセンスに関連したＬＵＲＴ　（フィー ルド４７）のルックアップによってライセンス単位要求を決定すべきであること を意味する。定数形式が指定された場合には、ライセンス付き製品又は製品の特 徴を実行させる全てのコンチクストに対してライセンス単位要求が一定であるこ とを指示する。プライベートＬＵＲＤＭは、ライセンス管理設備１１ではなくて ライセンス付き製品１７によってライセンス単位要求を決定すべきであることを 指定する。ライセンス単位要求テーブル（ＬＵＲＴ）は、ライセンスの発行者が コンチクスト（又は行セレクタ）と単位要求との関係を述べた情報を記憶できる ようにする手段をなす。ライセンス単位要求決定方法（ＬＵＲＤＭ）は、使用す べきＬＵＲＴに対して「テーブルルックアップ」を指定しなければならず、もし そうならば、行セレクタを指定しなければならず、ここで有効な行セレクタは、 例えば、プラットフォームＩＤ、ユーザ名、日時等のサブコンチクストである。

ＬＵＲＴ部分の一例が図４に示されており、ライセンス単位要求テーブル機構が 示されている。この例では、行セレクタは［プラットフォームＩＤＪであり、従 って、プラットフォームＩＤの値はどの行を使用するかを決定する。図４のこの ＬＵＲＴの発行者は、その発行者の製品に対する単位要求を決定するのに使用す るための３単位要求段を確立している。これら段の理由はライセンス管理システ ムでは命令されないが、発行者２５（実際にはプログラム２６のユーザ）はおそ らく３つの価格段を確立し、その各々は、種々のクラスの製品１７の使用をサポ ートする際に種々のプラットフォームの相対的な利用性についての別々の見方を 表している。図４の最初の列であるカラムＡは、製品利用性がそれを実行する特 定のプラットフォームの特性に非常に敏感であるような種類の製品に対する使用 要求を指定する。これは、カラムＡの各行ごとに単位要求が異なることを観察す ることにより明らかとなろう。第２の列（カラムＢ）を使用する製品は、それを 実行するプラットフォームのクラスにより関係した利用性をもつと考えられる。

これは、全てのＰＣプラットフォームがＶＡＸプラットフォームに指定されたも のとは異なる単一の値を共有することによって示される。最後の列（カラムＣ） は、ＶＡＸプラットフォームにおいてのみサポートされるクラスの製品に使用す るものである。図４はもちろん単なる例に過ぎず、ライセンス文書発生器２６に よって形成されてライセンスデータベース２３に記憶される（製品使用認可３５ のフィールド４７として）実際のＬＵＲＴは、ライセンス発行者により所望され るこの一般的なフォーマットの内容となる。

実行プラットフォームのプラットフォームＩＤに基づいてＬＵＲＴテーブルの行 を常に選択するのではなく、ライセンス管理設備によってサポートすることが必 要な取引上の慣例の寛容さを取り扱うために、ＬＵＲＴ機構は、ＬＵＲＴクラス 構造に「行セレクタ」アトリビュートを設けることによって拡張される。デフオ ールドは与えられないが、行セレクタアトリビュートの正常な値は［プラットフ ォームＩＤＪとなることが予想される。

特許第４．９３７．８６３号のシステムでは、図４のＬＵＲＴに類似した考え方 がされており、行はプラットフォームＩＤにより選択されそして列は典型的に製 品の形式に基づきある任意の手段によって選択される。本発明のシステムは、米 国特許第４，９３７．８６３号の制約内で定められたライセンスに対する後方コ ンパティビリティを与え続けながらも、ＬＵＲＴの行及び列の両方の選択にフレ キシビリティをもつことができる。

幾つかの例が行セレクタアトリビュートの潜在的な使用を示す。ある顧客は、１ 年のうちの１力月又は２力月間しか製品の使用に対して支払いを望まず、製品は フォートランであり、この要求の理由は、会社に充分安定した１組のフォートラ ンサブルーチンがあり、５月と６月の間だけ定期的な［−年間保守」を受けるか らであるとする。この顧客の要望を取り扱うために、フォートラン製品は、１年 のうちの月を表す値を含むアプリケーションサブコンチクストを発生する。次い で、ＬＵＲＴテーブルは、１年の各月に対して１つづつの１２行で定められる。

ある列、おそらくカラムＡでは、５月と６月を除く各月に負の１（−１）が入れ られる。これらの２月はある正の数値を含む。次いで、製品使用認可は、単位要 求を決定するのに使用するためのＬＵＲＴを指定するＬＵＲＤＭフィールドを有 することになり、この慣例をＬＵＲＴテーブルと名付ける。その結果、ＰＵＡは ５月と６月の間しか使用できなくなる。というのは、負の１がライセンスマネー ジャにより「使用が許されない」と意味するように解釈されるからである。この 機構は「１日のうちの時間」で料金請求するのにも使用できる。おそらく、夜は 昼よりも１回使用当たりの料金請求単位が少ない。又、年の値を含むサブコンチ クストが使用された場合には、時間の経過と共に単位要求が変化するような形式 のライセンスが設けられる。例えば、１９９１年には１回使用当たり１０単位で 料金を設定することによってスタートするが、時間の経過と共に毎年１単位づつ 少なく料金を課していって、最終的には単位要求がゼロという点まで至るように する。

別の例はフォント名である。ある特定の顧客は、１００単位の大きなフォント収 集物を同時使用する権利を与えるライセンスを購入する。あるフォントは他のフ ォントよりも使用コストが高い。例えば、タイムズ・ローマン（Ｔｉｍｅｓ　Ｒ ｏｍａｎ）は１回使用当たり１０単位のコストであるが、二ニー・センチユリ− ・スクールブック（Ｎｅｗ　Ｃｅｎｔｕｒｙ　５ｃｈｏｏｌｂｏｏｋ）は１回使 用当たり２０単位のコストである。

もちろん、問題は、適切に料金請求を行うよう確保することである。その解決策 は、指定されたアプリケーションサブコンチクストをもつＬＵＲＴテーブルをそ の行セレクタとして構成することである。次いで、この収集物の各フォントごと に行を形成し、フォントの使用に支払う必要のある単位数がＬＵＲＴのカラムＡ に指定される。次いで、プリントサーバは、１ｍ　ｒｅｑｕｅｓｔ　ａｌｌｏｃ ａｔｉｏｎ通話を行うときにアプリケーションサブコンチクストの値としてフォ ントの名称を指定する。これにより、フォントの名称に従って料金を変えること ができる。

更に別の例はメモリサイズである。幾つかの製品は、それらをサポートするのに 使用できるメモリのサイズに応じて価格が若干具なる。メモリのサイズに基づい て単位要求を決定しようとするソフトウェアの売主は、メモリの適度な増分ごと に（おそらくは１メガバイトの増分ごとに）行をもつＬＵＲＴテーブルを構築す ることによってこれを行うことができる。次いで、それらのアプリケーションが メモリサイズを感知しくライセンス管理設備の部分を構成しないある機構を用い て）、丸み付けされたメモリサイズの値をプライベートコンチクストにおいてラ イセンスマネージャへ送る。

他の例は環境及びオペレーティングシステムである。ある製品は、対話モードで 動作するかバッチモードで動作するかに基づいて異なった価格が付けられる。

これは、環境を指定する標準プラットフォームサブコンチクストの各々に対して ＬＵＲＴ行を構成することにより達成できる。オペレーティングシステムについ ては、単一の製品使用認可でいかなる数のオペレーティングシステムにおける製 品の使用も許すようにすることが著しく望ましいと考えられているが、これは、 全てのオペレーティングシステムに適用する単一製品価格を形成することを望ま ないある売主の方針と矛盾する。従って、オペレーティングシステムの独立した ライセンスがＣコンパイラ−に対して提供された場合には、ＭＳ−ＤＯ３ＳＶＭ Ｓ及び／又はＵＮＩＸについて同じ価格となる。明らかに、多数の製品の価格は その一部がそれらをサポートするオペレーティングシステムに依存していると示 すことができる。オペレーティングシステムの行セレクタ（標準プラットフす一 ムサブコンテクストの１つ）を使用することにより、ライセンス設計者は、実際 に、オペレーティングシステムごとに異なる数の単位を必要とすることがある。

しかしながら、通常オペレーティングシステムのサブコンチクストと同じ値を有 するプライベートアプリケーションサブコンチクストに対して行選択をベースと することがより望ましい。その理由は、ライセンス設計者は、ＬＵＲＴの行を定 めたときに未知であったオペレーティングシステム名に対してデフオールド値を 与えようと希望するからである。この場合には、製品が既知のオペレーティング システムのリストを含み、適宜に「未知」のサブコンチクスト値を通すからであ る。「未知」のＬＵＲＴ行は、そのオペレーティングシステムがサポートされな かったことを指示するために負の１（−１）を含むか、あるデフオールド単位要 求を含むかのいずれかである。

もう１つの例は、あるグループ内で可変な価格設定である。　「グループ」ライ センスに伴う問題の１つは、１つのグループに対しＰＵＡに１つの囃位要求フィ ールドしかないことである。従って、グループの全メンバーは単一の単位要求を 共有する。しかｌ−ながら、グループの全メンバーが一定の単位要求で適当にラ イセンス使用できる場合にも、各グループメンバーの使用に対して異なる金額で 料金を請求するのが望ましく、各グループメンバーに対して定められた行を持つ ＬＵＲＴを形成することができる。このようなグループに対する行セレクタは、 標準プラットフォームサブコンチクスト「製品名」となる。

図３のテーブルからコンチクスト、継続時間及び方針の異なる組み合わせを用い て多数の異なる形式のライセンスを形成することができる。例えば、以下の説明 では、適当な値の製品使用認可フィールド４　：）４６を用いて実施することの できる幾つかの慣例的なライセンススタイルを示す。

慣例的に設計されている「システムライセンス」とは、単一のハードウェアシス テムにおいて製品を無制限に使用できるライセンスである。正しい数の単位を前 もってプロセッサに割り当て、そしてシステムのユーザに無制限の製品使用が得 られるようにしなければならないつ製品使用認可は、ノード名のためのフンチク ストテンブレットをコンチクストフィールド４４に有し、継続時間フィールドは 「アサイメントであり、方針スタイルフィールド４３は「割り当て性−」である 。

「同時使用ライセンス」とは、ライセンス付き製品の同時使用の数を制限するも のである。同時使用のう・イセンス弔位は、製品が使用されるときだけ割り当て られ、ライセンス付き製品の各同時ユーザはそれ自身の単位を必要とする。この 場合に、コンチクストテンプレットのフィールド４４はプロセスＩＤであり、継 続時間フィールドは「トランザクション」であり、方針スタイル４３は「割り当 て性」である。

「個人使用」のライセンスは、ライセンス付き製品のユーザ名の数を制限するも のである。この形式のライセンスは、製品にアクセスするユーザのリストのメン バーを保証するものである。個人使用形式の製品使用認可に関連して、登録され たユーザのリストがある。執行者は、これらのユーザをその製品使用認可により 課せられた限界まで必要に応じて指定することができ、各ユーザに指定される単 位の数はＬＵＲＤＭによって指示される。これは定数であってもよいし、Ｎ、　 ＵＲＴに指定されたように変化してもよい。コンチクストテンプレットは「ユー ザ名」であり、継続時間は「アサイメントであり、そして方針は「割り当て性」 である。

「場所ライセンス」乏は、ライセンス付き製品の使用を物理的な場所に対して制 限するものである。この場合、製品使用認可は、コンチクストテンプレットとし て「ネットワーク名」又は「ドメイン名」のいずれかを含み、継続時間は「アサ イメント」であり、そして方針スタイルフィールド４３は「割り当て性」である 。

一般に、ソフトウェア製品を使用するためのライセンスは、その製品を使用する ことによってどれほどの利益が得られるかに基づいて価格が決められ、これはそ のソフトウェアが実行されるマシンの容量に関連したものである。何千という潜 在的なユーザがターミナルにいる場合に、メインフレームのような大きなプラッ トフォームにおいて無制限に使用するためのライセンスは、高いレベルで価格が 決められる。ここで、スタイルは「割り当て性」であり、コンチクストテンプレ ット−「ノード」であり、継続時間−「アサイメント」であり、そしてＬＵＲＤ Ｍは「カラムＡ」であるが、単位は、例えば１０００のような大きなものである 。スケールの他端には、単一のパーソナルコンピュータで使用するためのライセ ンスがあり、ここで、フィールドの値は、単位が「１」であることを除いてメイ ンフレームの場合と同じである。消費者がコストを制限しながらメインフレーム において製品を使用できることを望む場合には、おそらく所与の時間に５人のユ ーザだけがその製品を使用できるようにするライセンスを得ることができ、ここ で、製品使用認可のフィールドは、単位−５であり、スタイル−割り当て性であ り、フンチクストテンプレット−プロセスであり、継続時間−トランザクジョン であり、ＬＵＲ，ＤＭ一定数、１単位である。これは、更に充分に高い価格とな る。というのは、使用期間が短い場合に非常に多数のユーザが実際に製品を使用 するからである。５人の名前の者しか製品を使用できない場合には個人使用ライ センスがおそらく低い価格で得られ、これらはライセンスサーバ１０のみにおい て識別されるのであって、ライセンス発行者２５によって名前が付けられるので はない。ここで、製品使用認可のフィールドは、単位−５であり、スタイル−割 り当て性であり、コンチクストテンプレット−ユーザ名であり、継続時間−トラ ンザクジョンであり、ＬＵＲＤＭ一定数、１単位である。

製品使用２可３５において与えられる付加的な特徴は、ライセンスの組み合わせ である。、１つの製品に対して多数の認可がある場合には、ユーザノード１６に よって送られるライセンスチェック要求が、多数の認可からの単位を組み合わせ ることによって満足される。個々の製品使用認可は組み合わせ使用を禁止する。

従って、ライセンス保持者は、ある数の単位に対しては割り当てベースでそして 別の数の単位に対しては消費性のベースで製品１７を使用するライセンスをもっ とかでき（これは価格という観点から魅力的なものである）、これらライセンス の１つからは特定のコンチクストに対して充分な単位が得られないことがあり、 従って、ある単位を他のライセンス（製品使用）可）から借りてもよく、この場 合は、組み合わせがなされる。

クライエント即ちユーザ１６で実行しているプログラムと、ライセンスサーバ１ ０又はその委任者サーバ１３との間のインターフェイスは、基本的に３つの手順 呼び出しを含む。即ち、要求割り当てと、解除割り当てと、問い合わせ割り当て である。図５は、このクライエントインターフェイスに生じる幾つかの事象をフ ローチャートの形態で示している。要求割り当ては基本的なライセンスチェック 機能で、ソフトウェア製品１７が取り上げられたときに呼び出される手順呼び出 しであり、ライセンス単位の割り当てを要求するように機能し、グランド又はグ ランドの拒絶を返送する。ある製品は、スタートアップ時のみではなくプログラ ムを実行する際に多数のポイントにおいて要求割り当て呼び出しを使用し、例え ば、特殊なグラフィックパッケージ等のようなある特定の特徴を使用するときに 要求割り当てが送られることに注意されたい。解除割り当て呼び出しは、ユーザ がもはや割り当てを必要としないとき、例えば、タスクが終了したときに呼び出 され、その返送は単にアクノーリッジのみであることが殆どである。即ち、スタ イルが消費性である場合には、発呼者は、解除割り当て呼び出しを経て、消費さ れる単位数に作用を及ぼす機会をもち、例えば、ある事象による数を減少する機 会をもつ。問い合わせ割り当て呼び出しは、既存の割り当てに関する情報を得る か又は以下で述べるように発呼カードを得るためにユーザによって呼び出される 。

１■−ｒｅｑｕｅｓｔ　ａｌｌｏｃａｔｉｏｎＯと称する要求割り当ては、ライ センス単位を現在のコンチクストに割り当てるべきであるという要求である。こ の機能は、製品又は製品特徴を使用できるかどうかを決定するためにアプリケー ションプログラマ−によって使用することのできるグランド又は拒絶状態を返送 するものである。

この状態は、適当な製品使用認可の存在と、その製品使用認可に関連したライセ ンス管理方針とに基づいている。ライセンス単位は、もし使用できれば、適当な 製品使用認可において見つかった方針ステートメントに従って割り当てられるか 又は消費される。製品は、通常、ライセンス付き製品又は製品特徴を使用する前 にこの機能を呼び出す。この機能は、要求が失敗した場合に製品の実行を終了さ せることはない。その失敗の場合に何を行ってライセンス単位の割り当てを得る かの判断はプログラマ−による。要求割り当て呼び出しにおけるアーギュメント は、製品名、プロデューサ名、バージョン、発売日、及び要求拡張である。製品 名、プロデューサ名、バージョン及び発売日は、ユーザが割り当ての実行を要求 している製品を特に識別するためのソフトウェア製品の名称、プロデューサの名 称、バージジン番号及び発売日である。要求拡張アーギュメントは、要求された 単位、ＬＵＲＴカラム、プライベートコンチクスト及びコメントといった要求の 拡張されたアトリビユートを記述する主題である。発呼ノードへ返送される結果 は、機能がうまくいったかどうか、もしそうでなければ、なぜかを示す返送コー ドと、機能が首尾よく完了した場合に返送されるグランドの取り扱いとであり、 これは、そのグランドに対する識別取り扱いを与えるもので、従って、例えば、 その後の解除割り当て呼び出し又は質問割り当て呼び出しにおいて参照できるも のである。

１麿−ｒｅｌｅａｓｅ　ａｌｌｏｃａｔｉｏｎＯと称する解除割り当ては、既に 割り当てられた単位を解除又は消費するためのユーザからライセンスマネージャ への指示である。

この機能は、要求割り当てへの手前の呼び出しに応答してなされた割り当てグラ ンドを解除することである。解除の際に、ライセンス管理スタイル３８は、使用 できる単位のプールへ単位を返送すべきか又は消費すべきかを決定する。発呼者 が、単位要求アトリビュートを含んだ要求割り当てへの手前の呼び出しにおいて 要求拡張を指定しており、そしてそのとき要求された単位の数が、完了したオペ レーションに対して消費されるべき単位の数ではない場合には、発呼者は、１位 消費アーギュメントで、いかに多くの単位を消費すべきかを述べねばならない。

解除割り当てのアーギュメントは、グランドの取り扱い、消費された単位、及び コメントである。グランドの取り扱いは、要求割り当てに対する手前の呼び出し によって形成された割り当てグランドを識別する。単位消費アーギュメントは、 ライセンスの方針が消費性である場合に消費されねばならない単位数を識別し、 このアーギュメントは、要求拡張において単位要求を指定した要求割り当てに対 する手前の呼び出しとの組み合わせにおいてのみ使用しなければならない。この アーギュメントが省略されることは、消費されるべき単位数が既に割り当てられ た数と同じであることを指示する。コメントアーギュメントは、解除単位が消費 性のライセンスからのものであるか又は記録がイネーブルされた場合にログファ イル２４へ書き込まれるコメントである。その結果は、機能が首尾よくいったか どうか、もしいかなければ、なぜかを示す返送コードである。

問い合わせ割り当て、即ち１醜−ｑｕｅｒｙ　ａｌｌｏｃａｔｉｏｎＯは、手前 の要求割り当て呼び出しによって割り当てを受けたライセンス付き製品によって 使用される。この問い合わせは、ユーザに対して発生したグランドの特性及びそ のグランドを発生するのに用いたライセンスデータに関する情報をサーバ１０又 は委任サーバ１３から得るか、又は発呼カード（即ち、発呼カードを発行すべき 要求）を得ることである。典型的に、この問い合わせ機能によって読み取られる 項目はトークンフィールド５２であり、これは、ライセンス発行者によってエン コードされる任意情報を含んでいると共に、通常は「プライベート割り当てスタ イル又はコンチクストが使用されるときにライセンス付きソフトウェア製品１７ に対するスタブ１９により必要に応じて解釈される。この手順呼び出しにおける アーギュメントは、グランドの取り扱いと、主題とである。グランドの取り扱い は、要求割り当てに対する手前の呼び出１．によって形成された割り当てグラン ドを識別する。

主題アーギュメントは、「製品使用認可−１又は「発呼カード要求」のいずれか であり、前者の場合には、その結果が製品使用認可のパブリックコピーを含む。

このアーギュメントが発呼カード要求であって、その要求で指定された手前の制 約に合致する発呼カードが使用できるようになる場合には、その結果が発呼カー ドを含む。主題アーギュメントが省略された場合には、その結果が割り当て形式 の例を含む。問い合わせ割り当て呼び出しの結果は（１）機能が首尾よくいった かどうか、もしそうでなければ、なぜかを指示する返送コードと、（２）主題ア ーギュメントの形式及び存在に基づいて、割り当て、製品使用認可又は発呼カー ドのいずれかの結果である。

図５のフローチャートは、サーバとのインターフェイスにおけるクライエントの 動作を示している。ソフトウェア製品１７を呼び出すべきときには、ブロック６ ０で示すようにユニット１８が最初に実行され、そして最初の動作は、ブロック ６】で示されたように要求割り当て呼び出しを行うことである。クライエントは 、ループ６２で示すように返送を待機し、返送を受け取ったときに、判断ブロッ ク６３においてそれがグランドであるかどうかをチェックする。もしそうでな・ 　ければ、その返送のエラーコードがブロック６４でチェックされ、エラーコー ドが再試みができることを指示する場合には（ブロック６５）、制御は開始部へ 移行されるが、再試みができない場合には、実行が終了となる。ライセンスの許 可なしに製品１７を使用できるという方針である場合には、この機能が別途考慮 される。判断ポイント６３でグランドが得られたことを示す場合には、グランド の取り扱いが、後で参照するために記憶される（ブロック６６）。次いで、ユー ザによって意図された主たる動作についてプログラム１７に入る。製品１７のこ の実行中、又はその前後に、ブロック６７において問い合わせ割り当て呼び出し を行うことができるが、これはオプションであり、殆どの場合は必要とされない 。

プログラム１７の実行が完了すると、ブロック６８においてグランドの取り扱い が検索され、ブロック６９において解除割り当て呼び出しがなされる。ループ７ ０は、サーバからの返送の待機を示しており、その返送が受け取られると、前記 したようにエラーコードについてチェックがなされ、再試みが適宜行われる。解 除が首尾よ（確認された場合には、プログラムが終了となる。

図６を参照すれば、クライエントインターフェイスとしてライセンス管理プログ ラム１１又は１４を実行する際のサーバ１０又は委任者サーバ１３の動作が流れ 図の形態で示されている。サーバプログラムがそのクライエントからの要求、解 除又は問い合わせ呼び出しの受信をチェックするループが示されている。この呼 び出しは、上記したリモート手順呼び出しであり、例えば、ネットワークによっ て通信されるメツセージである。このループは、判断ブロック７１．７２及び７ ３を示している。解除割り当て呼び出しが受け取られた場合には、認可が記憶さ れる製品のリストがブロック７４においてスキャンされ、受信した呼び出しのア ーギュメントに与えられた製品識別と比較される（ブロック７５）。一致が生じ ない場合には、エラーコードがクライエントに返送され（ブロック７６）、最初 のループへ制御が戻される。製品が見つかった場合は、ブロック７７においてデ ータベース２３から認可が検索され（所与の製品には２つ以上の認可があり、こ の場合全てが検索されるが、ここでは１つしか説明しない）、そして判断ブロッ ク７８で示すように、図３及び４の管理方針に基づいてなされた計算に対して全 ての情報が一致される。許可を得ることができる場合には、ブロック７９で示す ようにグランドが返送され、さもなくば、ブロック８０においてエラーコードが 返送される。判断ブロック７２の肯定結果で示されるように解除割り当て呼び出 しを受け取った場合には、ブロック８】においてアーギュメントにおけるグラン ドの取り扱いが有効であるかどうかチェックされる。一致が見つからない場合に は、ブロック８２において１ラーコードが返送され、初期ループへ制御が移行す る。グランドの取り扱いが有効であれば、その製品の認可がブロック８３におい てデータベース２３から検索され、そしてブロック８４に示すように更新される 。例えば、ライセンス管理スタイルが割り当て性である場合には、単位が使用で きるプールへ返送される。或いは、ある場合には、更新が必要とされない。ブロ ック８５において認可が再びデータベースに記憶され、ブロック８６においてク ライエントへ返送がなされ、その後に初期ループへ制御が移行される。判断ブロ ック７３において問い合わせ割り当て呼び出しを受け取ったことが指示された場 合には、ブロック８７において再びグランドの取り扱いがチェックされ、もし有 効でなければ、ブロック８８においてエラーコードが返送される。グランドの取 り扱いが一致する場合には、ブロック８９においてデータベース２３から認可が 検索され、ブロック９０においてクライエントへの返送がなされ、アーギュメン トに要求された情報が与えられる。

ここに述べるライセンス管理システムの実施例に使用されそして図５及び６の方 法で実施された基本的な割り当てアルゴリズムは非常に簡単であり、既知のライ センス単位割り当て問題の非常に大きな部分を取り扱うことができる。しかしな がら、より精巧な拡張アルゴリズムを組み込めることを認識されたい。割り当て アルゴリズムを拡張する努力においては、種々様々な状況において単位割り当て を最適化する特定のサポートを果たすように追加を行うことができる。特に、基 本的な割り当てアルゴリズムを用いたときに生じる非最適割り当ての原因は、組 み合わせ及びリザーブの取り扱いから生じるものである。

第１のステップは、フルコンチクストの形成である。クライエントスタブ１９は 、製品１７の実行環境から全ての指定されたプラットフォーム及びアプリケーシ ョンサブコンチクストを収集しそしてこれらの収集したサブコンチクストをライ センス管理サーバ１３又は１０へ送るという役割を果たす。サブコンチクストの 収集を、特定のライセンス単位割り当て要求に対して「フルコンチクスト」と称 する。

次のステップは、コンチクストテンプレットの検索である。ライセンスマネージ ャが１１　ｒｅｑｕｅｓｔ　ａｌｌｏｃａｔｉｏｎを受け取るときには、使用で きる製品使用認可（ＰＵＡ）のリストを見て、それらのいずれかが１ｓ＋　ｒｅ ｑｕｅｓｔ　ａｌｌｏｃａｔｉｏｎ呼び出しに与えられた製品識別子に合致する かどうか決定する。製品識別子は、製品名と、プロデューサと、バージ３ンと、 発売日とで構成される。いずれかの一致が見つかると、ライセンスマネージャは その一致するＰＵＡからコンチクストテンプレットを抽出する。このテンプレッ トは、単位要求を決定するプロセスに関達したサブコンチクストのリストで構成 される。従って、コンチクストテンプレフトは、特定のフルコンチクストのノー ドＩＤサブコンチクストが単位割り当ての目的で重要であることを指示する。コ ンチクストテンプレットはノードＩＤに対して特定の値を指定するものではなく 、むしろ、割り当ての計算を行うのにノードＩＤを使用すべきであると単にいえ るものである。

次のステップは、フルコンチクストをマスクすることである。フンチクストテン ブレットが検索されると、ライセンスマネージャは、コンチクストテンプレット にリストされていない全てのサブコンチクストを除去するためにフルコンチクス トをフィルタすることにより「割り当てコンチクスト」を構成する。この割り当 てコンチクストは、割り当て要求を決定するのに用いるべきコンチクストである 。

次いで、要求が新たなものであるかどうかを決定するステップが行われる。ライ センスマネージャは、各製品使用認可に対し、そのＰＵＡについての全ての未解 決の割り当て（即ち、グランドが与えられてはいるがまだ解除されていない割り 当て）の割り当てコンチクストを含むダイナミックテーブルを維持している。

このテーブルの各入力には、割り当てられた単位の数、フルコンチクスト、等を 記録するあるブックキーピング情報が組み合わされている。最新の１層−ｒｅｑ ｕｅｓｔａｌｌｏｃａｔｉｏｎが単位の割り当ての実行を要求するかどうかを決 定するために、ライセンスマネージャは、新たな割り当てコンチクストを、未解 決割り当てのテーブル内の全ての割り当てコンチクストと比較し、割り当てコン チクストに対して割り当てが既になされたかどうかを決定する。新たな割り当て コンチクストがテーブルに既に存在しない場合には、ＰＵＡのＬＵＲＤＭ構造に 含まれた値及び要求されるであろうＬＵＲＴに基づいて適当な単位数を割り当て る試みを行う。新たな割り当て要求に指定されたものと同様の割り当てコンチク ストがテーブルに存在する場合には、ライセンスマネージャは、既に割り当てら れた単位の数が、新たな割り当て要求を満たすために割り当てる必要のある単位 数に等しいか又はそれより大きいかを確認する。もしそうであれば、ライセンス マネージャはグランド取り扱いをアプリケーションへ返送し、割り当てがなされ たことを指示する（即ち、これは「共有割り当て」−割り当てられた単位が２つ の要求間で共有されるーである）。さもなくば、ライセンスマネージャは、既に 割り当てられた数と、要求された単位数との差に等しい単位数を割り当てるよう に試みる。

割り当てを解除するステップ（図６のブロック８４−８５）は、ライセンスマネ ージャが１町−ｒｅｌｅａｓｅ　ａｌｌｏｃａｔｉｏｎ呼び出しを受け取ったと きに生じ、これは解除すべき割り当てに対応するダイナミック割り当てテーブル 内の記録を除去する。これを行うとき、ライセンスマネージャは、除去すべき割 り当てが他の割り当てコンチクストによって共有されているかどうかを決定する 。もしそうであれば、解除される割り当てに関連した単位が解除されない。これ らは、残りの割り当てコンチクストに割り当てられたままとなる。割り当てられ た単位の数が未解決の割り当てコンチクストを満足するに必要な数を越えること がライセンスマネージャによって決定された場合に、幾つかの単位が解除される 。この場合には、ライセンスマネージャは、割り当てられた単位の数を適当なレ ベルまで「切断」する。

要約すれば、このアルゴリズムを働かせる２つのものは、（１）単一の割り当て コンチクストに対して２つ以上の割り当てがなされないようにする基本的なルー ルと、（２）コンチクストテンプレットを使用して、さもなくば類似していない フルコンチクストが割り当ての目的で見掛け」似するようにさせることである。

基本的な方針を定めるときのライセンス設計者のタスクは、ライセンスマネージ ャに対してどのコンチクストを見掛は上回じにするかを決定することである。

ライセンス設計者が、単一ノードの全てのコンチクストが同じに見えるようにす べきである（コンチクストテンプレット−ノードＩＤ）と判断した場合には、そ のノードから送られる要求全てが割り当てを共有する。一方、全てのコンチクス トを独特なものにすべきである（即ち、コンチクストテンプレット−プロセスＩ Ｄ）という判断は、割り当てを決して共有しないことを意味する。

この機構により、本発明のシステムは、前記特許第４，９３７，８６３号を含む 公知のライセンス管理システムに見られるクラスターライセンス、ノードライセ ンス、及びプロセスライセンスといった種々の範囲を有するライセンス形式につ いての厄介な明白なサポートをなくすことができる。ある制限された１組の範囲 （クラスター、ノード等）を定めるのではなく、本発明のシステムは、実際上制 限のない割り当て範囲を定めることのできる汎用の機構を提供する。

上記の移行的ライセンスは、本発明のシステムでは、（１）　１つの製品（発呼 者）が別の製品（被呼者）へと通話できるようにその１つの製品の製品使用認可 ３５のフィールド４９になされたステートメントである発呼認可と、１つの製品 （被呼者）が別の製品（発呼者）によって通話され得るようにその１つの製品の 製品使用ノ可３５のフィールド４９になされたステートメントである発呼者認可 とによってサポートされる。

発呼又は発呼者認可を製品によって利用すべき場合には、１つの製品が別の製品 を呼び出すときに、被呼者に発呼カード４９ａを送らねばならない。この発呼カ ード４９ａは、発呼者の識別をエンコードしたものであると共に、発呼カードを 送っている発呼者にライセンス単位割り当てがなされているというライセンス管 理システムによるステートメントである。この発呼カードは、次いで、被呼者に より確認のためにライセンス管理システムへ通され、発呼者の製品使用認可が適 当な発呼認可を保持しているか、或いは被呼者の製品使用認可が適当な発呼者２ 可を保持している場合に、発呼者による被呼者の使用が、追加ライセンス単位割 り当てを要求せずに認可される。

図７には、発呼又は発呼者認可が使用されるときに生じるコンポーネント間の対 話が示されている。この図には、ライセンス管理サーバ１０、「製品Ｉ」と称さ れた発呼者製品１７ａ及び「製品２」と称された被呼者製品１７ｂが示されてい る。製品１が動作を開始すると、ｕｓ　ｒｅｑｕｅｓｔ　ａｌｌｏｃａｔｆｏｎ 呼び出しをライセンス管理サーバ１０へ行い、製品１ライセンスの若干数の単位 の割り当てに対してグランド取り扱いを得る。その直後か又はある時間の後であ るが、常に製品２への通話を行う前に、製品１は、１ｍ　ｑｕｅｒｙ　ａｌｌｏ ｃａｔｉｏｎを呼び出し、前に受け取ったグランド取り扱いを送ると共に、「製 品２」と称する製品のための発呼カードを希望していることを指定する。グラン ド取り扱いによって表されたグランドを満足するのに用いられる製品使用認可３ ５のフィールド４９が「製品２」と称する発呼認可を保持する場合には、ライセ ンスマネージャが発呼カード４９ａを形成し、これは、発呼認可が存在しそして この発呼カードを製品１へ返送するというステートメントを含んでいる。発呼認 可が存在しない場合には、製品１へ送られた発呼カードがその作用に対するステ ートメントを含む。

製品１がライセンスマネージャから発呼カード４９ａを首尾よく得ると、製品２ への通話を行い、発呼カードを、製品２をスタートさせるときに通常使用される 他の初期化パラメータと共に送る。次いで、製品２は、その発呼カードをその１ 膳−ｒｅｑｕｅｓｔ　ａｌｌｏｃａｔｉｏｎ呼び出しの一部としてライセンスマ ネージャへ通し、そしてライセンスマネージャは発呼カードが有効かどうかを判 断する。発呼カードを受け取ったプロセスが１■−ｒｅｌｅａｓｅ　ａｌｌｏｃ ａｔｔｏｎ呼び出しを行うか又は異常な終わり方をしたときには発呼カードが無 効となることに注意されたい。発呼カードが有効であって、発呼認可が存在する ことを指示する場合には、ライセンスマネージャがこのステートメントを確認し 、真であることが分かれば、グランド取り扱いを製品２へ返送する。一方、発呼 カードが、発呼認可が存在しないという指示を保持する場合には、ライセンスマ ネージャは、認可された発呼者として製品１と称する発呼者認可を含んでいる製 品２の製品使用認可を見つけようと試みる。この発呼者認可が見つかった場合に は、グランド取り扱いが製品２へ送り返される。さもなくば、ライセンスマネー ジャは発呼カードを無視し、通常の１鳳ｒｅｑｕｅｓｔ　ａｌｌｏｃａｔｉｏｎ ロジックで動作を進める０製品間に発呼カードを特徴とする請求は、発呼者と被 呼者の両方が発呼及び発呼者認可を使用することに「気付いて」いる必要がある 。これは、本発明のライセンス管理システムを使用するときに製品１７をライセ ンスの問題に能動的に含ませる必要についての幾つかの例の１つである。しかし 、発呼／発呼者認可の使用は充分に「精巧」であり且つ強力な特徴であるから、 この負担をアプリケーションコーダに課することが受け入れられると考えられる 。

特定の実施例について本発明を説明したが、これは本発明を何ら制限するもので はない。当業者であれば、本発明を参照したときに、上記実施例の種々の変更や 、別の実施例が明らかとなろう。それ故、請求の範囲は、本発明の真の範囲内に 入るこのようなあらゆる変更を網羅するものとする。

平成　年　月　日

Claims (22)

【特許請求の範囲】
1. １．ライセンス付きソフトウェア項目の使用を管理する方法（１１）において、 上記ソフトウェア項目に対するライセンス認可の記憶（２３）を維持し、各ライ センス認可は、複数組の方針コンポーネントを有するソフトウェア項目に対して ライセンス管理方針（４３）（１４）の指示を含んでおり、各組における上記方 針コンポーネントは、上記組の各々からの方針コンポーネントを同時に使用して 複合方針を形成するための代替え物を与え、 上記ソフトウェア項目を使用する許可を得るために上記ソフトウェア項目の１つ についてのユーザ（１６）による要求を送信し、この要求は、ユーザ及び上記ソ フトウェア項目（３８，３６）を識別するものであり、上記要求に応答して上記 ソフトウェア項目に対する上記ライセンス認可からの情報を得るように上記記憶 にアクセスし、上記ユーザ及び上記ソフトウェア項目の上記識別を上記情報と比 較すると共に、上記複数組のライセンス管理方針コンポーネントにより課せられ た制約とも比較して（７５）、上記要求の許可（７９）又は拒絶を発生し、そし て 上記許可又は拒絶を上記ユーザへ送信するという段階を備えたことを特徴とする 方法。
2. ２．上記記憶はライセンスサーバ（１０）によって維持され、上記要求はこのサ ーバへ送られる請求項１に記載の方法。
3. ３．ライセンス管理方針コンポーネントの上記組の各々は、ライセンス（２６） 使用の単位を上記ユーザに割り当てるための複数の指定された方法を含んでいる 請求項１に記載の方法。
4. ４．ライセンス管理方針項目の上記組（４３）の１つは、割り当て性の方針と、 消費性の方針を含み、上記割り当て性の方針は、ユーザが要求した使用を完了し た後にそのユーザに割り当てられた単位を再使用できるようにし、そして上記消 費性の方針は、このような再使用を許さない請求項３に記載の方法。
5. ５．上記組は１組のコンテクストを含み、１つのコンテクストは、ライセンス付 き製品の環境、使用位置又は使用条件を識別し、上記コンテクストは、プラット フォームコンテクスト及びアプリケーションコンテクストを含む２つの形式のコ ンテクストの少なくとも一方を含む請求項２に記載の方法。
6. ６．上記プラットフォームコンテクストは、ネットワーク、実行ドメイン、ノー ド、ユーザ名、オペレーティングシステム、プラットフォームＩＤ及びＣＰＵ形 式を含むことができ、上記アプリケーションコンテクストは、上記ソフトウェア 項目からの情報を含むことができる請求項５に記載の方法。
7. ７．上記要求はリモート手順呼び出しの形態であり、上記ユーザに送られる上記 許可又は拒絶は上記手順呼び出しの返送であり、上記ライセンス文書は、製品使 用認可として指定されたデータ構成体であり、上記製品使用認可は発行者手段か ら上記サーバによって受け取られる請求項１に記載の方法。
8. ８．上記組の別々の方針コンポーネントが少なくと３つあり、上記組は、ライセ ンス単位を割り当てる別々の方法を与えるスタイルコンポーネントと、ライセン ス付き製品の環境、使用位置又は使用条件を識別するコンテクストコンポーネン トと、上記ユーザについての使用要求を決定する別々の方法を与える使用要求コ ンポーネントとを含む請求項１に記載の方法。
9. ９．上記ライセンス文書と共に記憶される単位要求テーブルを更に構え、これは 、異なるユーザに対して複数の別々のライセンス単位値を与え、更に、上記コン テクストコンポーネントに基づいて上記テーブルの行を選択する段階を含んでい る請求項８に記載の方法。
10. １０．上記ライセンス文書で許可されたライセンスの一部分を別のライセンスマ ネージャに委任し、追加のユーザからの上記要求を上記別のマネージャに送ると いう段階を含み、上記マネージャ、上記別のマネージャ、上記ユーザ及び上記追 加のユーザは、全て、少なくとも１つのコンピュータネットワークにおけるノー ドである請求項８及び１５に記載の方法。
11. １１．第２のユーザにある別のプログラムへ通話をする許可を得るために上記ユ ーザによる要求を上記サーバへ送り、上記要求に応答し、上記プログラムに対す る上記ライセンス文書から発呼認可を与える情報を得るために上記記憶にアクセ スし、そしてこの発呼認可が上記情報にある場合に発呼カードを発生し、 上記発呼カードを上記サーバから上記ユーザへ送り、上記第２のユーザヘの通話 をする際に、上記発呼カードを上記ユーザにより上記第２のユーザへ送り、 上記発呼カードを確認するために上記第２のユーザによる要求を上記サーバへ送 りそして上記サーバからの返送信号を受け、そして上記ユーザから上記第２のユ ーザヘの上記通話を完了させるという段階を備えた請求項１に記載の方法。
12. １２．ライセンス付きソフトウェア製品の使用を管理するシステム（１１）にお いて、 上記プログラム各々に１つづつライセンス文書の記憶（２３）を維持する手段を 備え、各ライセンス文書は、複数組の別々の方針コンポーネントを有するライセ ンス方針の指示を含み、 上記プログラムを使用する許可を得るために上記プログラムの１つについてのユ ーザからの要求を送る手段を更に備え、この要求はユーザ及び上記プログラムを 識別するものであり、 上記要求に応答して、上記プログラムに対する上記ライセンス文書から情報を得 るために上記記憶にアクセスし、上記ユーザ及びプログラムの上記識別を上記情 報と比較すると共に、上記組の方針コンポーネントによって課せられた制約とも 比較して、上記要求の許可又は拒絶を発生するための手段を備え、そして上記許 可又は拒絶を上記ユーザに送る手段を備えていることを特徴とするシステム。
13. １３．上記維持する手段、上記アクセスする手段、及び上記ユーザへ送る手段は 、全て、分配ネットワーク上のサーバに配置され、要求を送る上記手段はこのネ ットワーク上のユーザノードに配置され、上記ライセンス方針は、割り当て性の 方針と、消費性の方針を含み、割り当て性の方針は、ユーザが要求した使用を完 了した後にそのユーザに割り当てられた単位を再使用できるようにし、そして消 費性の方針は、このような再使用を許さない請求項１２に記載のシステム。
14. １４．上記組は１組のコンテクストを含み、１つのコンテクストは、ライセンス 付き製品の環境、使用位置又は使用条件を識別し、上記コンテクストは、プラッ トフォームコンテクスト及びアプリケーションコンテクストを含む２つの形式の コンテクストの少なくとも一方を含むものであり、上記プラットフォームコンテ クストは、ネットワーク、実行ドメイン、ノード、ユーザ名、オペレーティング システム、プラットフォームＩＤ及びＣＰＵ形式を選択的に含み、そして上記ア プリケーションコンテクストは、上記ソフトウェア項目からの情報を含むことが できる請求項１３に記載のシステム。
15. １５．上記要求はリモート手順呼び出しの形態であり、上記ユーザに送られる上 記許可又は拒絶は上記手順呼び出しの返送であり、上記ライセンス文書は、製品 使用認可として指定されたデータ構成体であり、上記製品使用認可は発行者手段 から上記サーバによって受け取られる請求項１２に記載のシステム。
16. １６．上記組の別々の方針コンポーネントが少なくと３つあり、上記組は、ライ センス単位を割り当てる別々の方法を与えるスタイルコンポーネントと、ライセ ンス付き製品の環境、使用位置又は使用条件を識別するコンテクストコンポーネ ントと、上記ユーザについての使用要求を決定する別々の方法を与える使用要求 コンポーネントとを含む請求項１２に記載のシステム。
17. １７．上記ライセンス文書と共に記憶される単位要求テーブルを更に備え、これ は、異なるクラスのユーザに対して複数の別々のライセンス単位値を与える請求 項１６に記載のシステム。
18. １８．第２のユーザにある別のプログラムへ通話をする許可を得るために上記ユ ーザによる要求を上記サーバへ送る手段と、上記要求に応答し、上記プログラム に対する上記ライセンス文書から発呼認可を与える情報を得るために上記記憶に アクセスし、そしてこの発呼認可が上記情報にある場合に発呼カードを発生する 手段と、上記発呼カードを上記サーバから上記ユーザへ送る手段と、上記第２の ユーザヘの通話をなす際に上記発呼カードを上記ユーザにより上記第２のユーザ へ送る手段と、 上記発呼カードを確認するために上記第２のユーザによる要求を上記サーバへ送 りそして上記ユーザから上記第２のユーザヘの上記通話を完了する前に上記サー バからの返送信号を受けるための手段とを備えており、上記要求はネットワーク 上のリモート手順呼び出しの形態であり、そして上記許可又は拒絶と上記発呼カ ードは、上記ネットワーク上でのリモート手順呼び出しの返送によって上記ユー ザへ送られる請求項１３に記載のシステム。
19. １９．上記ライセンス文書で許可されたライセンスの一部分を別のライセンスマ ネージャに委任し、そして追加のユーザからの上記要求を上記別のマネージャに 送るための手段を備えた請求項１２に記載のシステム。
20. ２０．分配ネットワークを動作する方法において、上記ネットワーク上のサーバ にプログラム使用認可の記憶を維持し、上記ネットワーク上の第１ユーザによる 要求を上記サーバへ送って、上記ネットワーク上の第２ユーザにあるプログラム へ通話をする許可を得るようにし、上記要求に応答して、プログラムに対する上 記認可から情報を得るように上記記憶にアクセスして、上記通話が許されるかど うか判断すると共に、もし通話が許された場合には発呼カードを発生し、上記発 呼カードを上記第１ユーザへ送り、上記第２ユーザへ通話をする際に上記第１ユ ーザにより上記第２ユーザへ上記発呼カードを送り、 上記発呼カードを確認するために上記第２ユーザによる要求を上記サーバへ送り 、上記サーバからの返送信号を受け取り、上記第１ユーザから第２ユーザヘの上 記通話によって要求されたオペレーションを完了させて、返送を行うという段階 を備えたことを特徴とする方法。
21. ２１．ライセンス付きソフトウェアの使用を管理する方法において、上記ライセ ンス付きソフトウェアの各製品に対するライセンス認可をライセンス発行者手段 において発生しそしてこのライセンス認可をライセンスマネージャへ送り、 上記ライセンス認可の記憶をライセンスマネージャに維持し、各ライセンス認可 は製品に対するライセンス管理方針の指示を含み、この指示は多数のコンポーネ ントを有し、上記ライセンスマネージャは上記ライセンス発行者手段と機能的に 別であると共に、上記発生段階を実行することができず、上記製品の１つについ てのユーザによる要求を上記ライセンスマネージャへ送って上記製品を使用する 許可を得、上記要求はユーザ及び上記製品を識別し、上記ユーザは、上記ライセ ンスマネージャ及び上記ライセンス発行者手段と機能的に別のものであり、 上記要求に応答して、上記製品に対する上記ライセンス認可からの情報を得るよ うに上記ライセンスマネージャにより上記記憶にアクセスし、上記ユーザ及び製 品の上記識別を上記情報と比較すると共に、上記ライセンス管理方針の上記コン ポーネントによって課せられた制約とも比較して、上記要求の許可又は拒絶を発 生し、そして 上記ライセンスマネージャから上記ユーザへ上記許可又は拒絶を送るという段階 を備えたことを特徴とする方法。
22. ２２．ライセンス付きソフトウェア製品の使用を管理する方法において、ライセ ンス認可の記憶をライセンスマネージャに維持し、各ライセンス認可は製品に対 するライセンス管理方針の指示を含み、この指示は、ライセンス期間の開始時間 及び終了時間を含む多数のコンポーネントを有し、上記製品の１つについてのユ ーザによる要求を上記ライセンスマネージャへ送って上記製品を使用する許可を 得、上記要求はユーザ及び上記製品を識別し、上記要求に応答して、上記製品に 対する上記ライセンス認可からの情報を得るように上記ライセンスマネージャに より上記記憶にアクセスし、上記ユーザ及び製品の上記識別を上記情報と比較す ると共に、上記ライセンス管理方針の上記コンポーネントによって課せられた制 約とも比較し、更に、上記要求の時間を上記開始時間及び終了時間と比較して、 上記要求の許可又は拒絶を発生し、そして上記ライセンスマネージャから上記ユ ーザへ上記許可又は拒絶を送るという段階を備えたことを特徴とする方法。