DE69228350T2

DE69228350T2 - Verwaltungssschnittstelle und format für lizenzverwaltungssystem

Info

Publication number: DE69228350T2
Application number: DE69228350T
Authority: DE
Inventors: Robert Wyman
Original assignee: Digital Equipment Corp
Current assignee: Digital Equipment Corp
Priority date: 1991-05-08
Filing date: 1992-05-06
Publication date: 1999-09-23
Anticipated expiration: 2012-05-07
Also published as: EP0538453B1; DE69228350D1; AU2015892A; AU659652B2; EP0538453A1; WO1992020022A1

Description

Diese Erfindung betrifft Verfahren für ein Betreiben von Computersystemen, und insbesondere ein Verfahren und ein System zum Managen des Lizensierens von Software, die auf Computersystemen ausgeführt wird.
Im US-Patent 4,937,863 (EP-A-0 332 304) von Robert, Chase und Schafer, das von Digital Equipment Corporation, dem Anmelder dieser Erfindung, angemeldet ist, ist ein Softwarelizensierungs-Managementsystem offenbart, bei dem eine Anwendung lizensierter Software in einem Computersystem überwacht werden kann, um zu bestimmen, ob eine Anwendung innerhalb des Schutzumfangs einer Lizenz ist. Das System unterhält eine Datenbank von Lizenzen für Softwareprodukte Ausgeben des Lizenzdokuments kann beispielsweise in der Form eines Netzwerks erfolgen, oder kann über eine Telefonleitung unter Anwendung von Modems erfolgen, oder kann eine physikalische Ausgabe mittels Disketten oder CD-ROMs enthalten. Gleichermaßen ist das Verfahren einer Ausgabe der Softwareprodukte, die lizensiert sind, d. h. die Anwendungsprogramme 17, die auf den CPUs 16 auszuführen sind, kein Material für die Lizenz-Managementeinrichtung der Erfindung; die Produkte werden durch irgendeine geeignete Einrichtung ausgegeben, z. B. die Kommunikationsverbindung 30 und die Netzwerke 21 und 22, durch physikalisch verteilte CD-ROMs oder Disketten, etc.
Obwohl sie in Fig. 1 derart gezeigt ist, daß sie auf einem verteilten System arbeitet, kann die Lizenz-Managementeinrichtung der Erfindung im einfachsten Fall auf einer einzelnen CPU betrieben werden. Das Lizenz-Managementprogramm 11 und das Anwenderprogramm 17 können auf derselben CPU ausführen, in welchem Fall das Lizenzdokument wie zuvor in einer Datenbank 23 auf dieser CPU gespeichert würde, und die Aufrufe von der Einheit 18 zum Lizenzserver würden anstatt von RPCs lokal sein. Wie beim verteilten System würde jedoch das lizensierte Produkt noch keinen Zugriff auf das Lizenzdokument haben, sondern könnte statt dessen nur Anfragen zum Serverprogramm durchführen, selbst wenn alle auf derselben CPU ausführen.
Beim Betrieb des verteilten Systems der Fig. 1 gibt der Hersteller 28 dem Herausgeber 25 eine Zugriffsberechtigung zum Erteilen von Lizenzen in seinem Auftrag (der Hersteller und der Herausgeber können eine einzige Rechtspersönlichkeit oder mehrere Rechtspersönlichkeiten sein). Das Lizenzdokument- Generatorprogramm 26 erzeugt unter Steuerung eines Anwenders (einer Person) eine Lizenz (normalerweise das Ergebnis einer Verhandlung zwischen dem Anwender des Programms 26 und einem Anwender des Servers 10). Diese Lizenz wird Produktanwendungs-Zugriffsberechtigung genannt, und sie wird durch die Verbindung 30 zum Server 10 übertragen. Das Lizenz-Managementprogramm im Server 10 speichert die Produktanwendungs-Zugriffsberechtigung in der Datenbank 23, und kann dann, wenn eine Delegation bzw. Bevollmächtigung eine autorisierte Option ist, Teile der autorisierten Anwendung zu den Delegiertenservern 13 verteilen, wo sie wahrscheinlich in einer Datenbank gespeichert wird. Danach erfolgt eine Verwaltung der Lizenz nur in Antwort auf Anfragen von Anwenderknoten 16. Wenn eine Ausführung eines Programms 17 beginnt, wird die Einheit 18 aufgerufen, um die Verfügbarkeit einer Lizenz für diesen bestimmten Knoten zu überprü fen. Die Einheit 18 sendet (wie durch einen RPC) eine Anfrage zum Lizenz- Managementprogramm 14 (oder 11, wenn es keinen Delegierten gibt), wo die Produktanwendungs-Zugriffsberechtigung, die in der Datenbank 23 gespeichert ist, geprüft wird, um zu sehen, ob eine Anwendung autorisiert ist. Wenn es so ist, wird eine Erwiderung zum Anwenderknoten 16 gesendet, was gewährt, daß eine Erlaubnis andauert. Wenn das Programm 17 ein Ausführen beendet hat, wird die Einheit 18 wiederum aufgerufen, um dem Lizenz-Managementprogramm wiederum durch einen RPC zu signalisieren, daß die Zugriffsberechtigung bzw. Autorisierung freigegeben bzw. gelöst ist, so daß das Lizenz-Managementprogramm eine geeignete Handlung vornehmen kann, z. B. die Anwendung in einem Protokoll 24 protokollieren, etc.
Zum Implementieren dieser Operationen enthält das Lizenz- Managementprogramm 11 oder 14 mehrere Funktionen, einschließlich einer Klientenschnittstelle 31, einer Datenbankschnittstelle 32, einer Managementschnittstelle 33 und einer Zwischenserver-Schnittstelle 34 zum Kommunizieren mit den Delegierten 13 (wenn es welche gibt). Die Klientenschnittstelle 31, wie sie unten beschrieben ist, behandelt die vom Anwenderknoten 16 empfangenen Anfragen und Erwiderungen, die aus diesen Anfragen resultieren. Die Datenbankschnittstelle 32 behandelt das Speichern und Wiedergewinnen von Lizenzinformationen in der Datenbank 23 und ein Protokollieren einer Lizenz-Anwendungsaktivität zum Protokoll 24 und eine Wiedergewinnung dieser Daten. Die Managementschnittstelle 33 behandelt die Aufgaben zum Empfangen der Produktanwendungs- Zugriffsberechtigungen vom Herausgeber 25 und zum Unterhalten der Datenbank 23 über die Datenbankschnittstelle 32. Die Zwischenserver-Schnittstelle 34 behandelt die Aufgabe zum Kommunizieren mit den Delegiertenservern 13, einschließlich eines Übertragens der zugehörigen Teile der Produkt-Anwendungsberechtigungen, oder eines Kommunizierens mit anderen Lizenzservern, die die Lizenz- Managementfunktion getrennt ausführen können; beispielsweise können Aufrufe für ein für gültig Erklären von Aufrufkarten zu einem anderen derartigen Server durchgeführt werden. Wenn es keine Delegierten oder keine anderen Lizenzserver gibt, dann hat die Zwischenserver-Schnittstelle 34 natürlich keine Funktion und ist leer bzw. unbesetzt.
Das Lizenzdokument oder die "Produktanwendungs-Zugriffsberechtigung", das bzw. die die Grundlage für die Lizenz-Managementaktivität des Programms 11 am Server 10 bildet, kann als Datenstruktur dargestellt werden, die die Informationen enthält, die in Fig. 2 gezeigt sind; in tatsächlicher Praxis ist die Produktanwendungs-Zugriffsberechtigung vorzugsweise eine abstraktere Datenanordnung und hat kein derartig streng strukturiertes Format, wie es dargestellt ist. Beispielsweise können die Produktanwendungs-Zugriffsberechtigung sowie ähnliche Dokumente, die in der Datenbank 23 gespeichert sind oder zwischen Komponenten des Systems der Fig. 1 weitergegeben werden bzw. geführt werden, vom sogenannten Tag- bzw. Kennungs-Längenwert-Datenformat sein, wobei die Datenstruktur mit einem Identifizierungs-Tag (z. B. PUA oder Produktanwendungs- Zugriffsberechtigung) beginnt, dem ein Feld folgt, das die Länge angibt, dem der Wert selbst (der Inhalt) folgt. Ein Typ einer Datenbehandlung, der dieses Tag- Längenwert-Format anwendet, ist ein internationaler Standard, der ASN.1 oder Abstract-Syntax-Notation genannt wird. In jedem Fall dient das in Fig. 1 dargestellte Dokument 35 eher lediglich zum Diskutieren der verschiedenen Elemente von Daten, als daß es die Art darstellt, auf die Informationen gespeichert sind. Einige der hier gezeigten Felder existieren zu gewissen Zeiten, und nicht zu anderen, und einige sind optional; die Produktanwendungs-Zugriffsberechtigung kann auch zusätzliche Felder enthalten, die hier nicht gezeigt oder diskutiert sind. Ebenso sollte beachtet werden, daß Kopien von Teilen dieses Typs von Dokument für die Delegierten gemacht werden, so daß diese Darstellung der Fig. 2 eine Zusammensetzung aus mehreren Dokumenten ist, die bei dem System der Fig. 1 angewendet sind. Das Dokument 35 enthält Felder 36, die das Softwareprodukt durch einen Produktnamen, einen Hersteller, Versionsnummern, ein Veröffentlichungsdatum, etc. identifizieren. Der Herausgeber 25 ist in einem Feld 37 identifiziert, und der Lizenznehmer (normalerweise der Besitzer des Lizenzservers 10) ist in einem Feld 38 identifiziert. Die wesentlichen Ausdrücke der Lizenzerteilung sind dann in Feldern 40-46 definiert. Das Anfangsdatum und das Enddatum sind in Feldern 40 spezifiziert. Diese speichern die genaue Zeit (Datum, Stunde, Minute, Sekunde, etc.), zu der die Lizenz gültig wird und zu der sie endet, so daß Lizenzen derart gewährt bzw. erteilt werden können, daß sie zu irgendeinem zukünftigen Zeitpunkt beginnen und zu einer bestimmten Zeit enden. Es ist zu beachten, daß es frühere Praxis gewesen ist, eher nur das Enddatum zu spezifizieren, als auch ein Startdatum, wie es hier angewendet wird. Jeder der Knoten, einschließlich des Herausgebers 25, der Server 10 und 13 und der Anwenderknoten 16, unterhalten einen Zeitwert durch einen lokalen Takt, der sich auf einen Standard bezieht, so daß es der Lizenz-Managementeinrichtung eigen ist, daß sie einen Zeitstandard unterhält, um ihn mit den Anfangs- und End-Datum-Informationen in den Feldern 40 zu vergleichen. Die gewährten Einheiten sind im Feld 41 spezifiziert. Die Einheiten sind eine willkürliche quantitative Maßnahme einer Programmanwendung. Bei einem Delegiertenserver 13 werden die Einheitenfelder 41 irgendeine Untergruppe des Einheitenfelds bei der ursprünglichen Produktanwendungs-Zugriffsberechtigung haben. Wenn Einheiten Anwendern 16 gewährt oder zu ihnen delegiert sind, werden die übrigen Einheiten, die für eine Gewährung verfügbar sind, in einem Unterfeld 42 in der durch den Server angewendeten Kopie des Dokuments angezeigt. Die Managementpolice besetzt Felder 43-46 und enthält einen Stil, einen Kontext, eine Dauer und LURDM (Lizenz-Anwendungserfordernis-Bestimmungsverfahren), wie es erklärt wird. Das Stil-Feld 43 spezifiziert, ob die lizensierten Einheiten durch einen "zugeteilten" Stil oder einen "verbrauchenden" Stil gesteuert werden oder irgendeinen anderen "privaten" Algorithmus, wobei Stile Arten sind, die zum zahlenmäßigen Ausmachen des Verbrauchs oder der Zuteilung der Einheiten angewendet werden. Das Kontextfeld 44 spezifiziert die Stelle und die Umgebung, in welcher eine Produktanwendung oder ein Lizenz-Management auftritt, d. h. eine CPU oder einen einzelnen Anwender oder ein Netzwerk, etc. Ein Dauer-Feld 45 zeigt an, ob die einem Anwender gewährte Lizenz durch Zuteilung, durch Transaktion oder durch etwas dazwischen erfolgt. Das LURDM-Feld 46 zeigt das Lizenz- Anwendungserfordernis-Bestimmungsverfahren an, und zwar in einigen Fällen unter Anwendung einer Lizenz-Anwendungserfordernis-Tabelle (LURT), die als Feld 47 zu sehen ist, wie es beschrieben wird.
Zusätzliche Felder 48-54 bei der Produkt-Anwendungsberechtigung 35 der Fig. 2 definieren Merkmale, wie beispielsweise eine Delegations-Zugriffsberechtigung, eine Aufruf-Zugriffsberechtigung, eine Überziehungs-Zugriffsberechtigung, eine Kombinations-Zugriffsberechtigung, einen Token, eine Signatur, eine Prüfsumme, etc. Diese Zugriffsberechtigungen werden in den folgenden Absätzen beschrieben.
Wenn das Delegations-Feld 48 wahr ist, kann ein Lizenzserver 10 Lizenzeinheiten zu mehreren Servern 13 verteilen. Eine Zeitbegrenzung kann auferlegt sein, d. h. Einheiten können zu anderen Hardware-Systemen delegiert werden, bis sie ablaufen. Eine Delegation läßt zu, daß ein Verwalter Einheiten verteilt, um eine Ansprechzeit zu verbessern und um die Unverwüstlichkeit des Systems zu erhöhen. Beispielsweise kann das Kommunikationsnetzwerk 21 eine Satellitenverbindung zu einer entfernten Einrichtung enthalten, wo der lokale Server 13 eine Anzahl von Klienten oder Anwendern 16 hat, in welchem Fall die Aufrufe zum Server 13 viel schneller beendet werden würden, als es der Fall wäre, wenn Aufrufe zum Server 10 gemacht werden müßten. Ebenso kann eine Delegation als Verfahren zum Zu teilen lizensierter Einheiten innerhalb eines Budgets für administrative Zwecke angewendet werden. Normalerweise ist die Delegations-Zugriffsberechtigung eine Eigenschaft, die durch den Herausgeber preislich festgesetzt wird, d. h. eine Lizenz, die 1000 Einheiten mit einer Delegations-Zugriffsberechtigung gewährt, ist preislich höher eingestuft, als ohne diese Zugriffsberechtigung.
Das Feld 49 enthält eine Aufruf-Zugriffsberechtigung und/oder eine Aufrufer- Zugriffsberechtigung. Wenn die Aufrufer-Zugriffsberechtigung im Feld 49 wahr ist, wird zugelassen, daß das Produkt Aufrufe von anderen genannten Produkten empfängt, die nach einer Anwendung des Produkts fragen, und wenn Bedingungen erfüllt sind (der identifizierte Aufrufer autorisiert ist), kann der Server eine Aufrufkarte gewähren, wie es unten beschrieben ist. Wenn die Aufruf-Zugriffsberechtigung wahr ist, kann das Produkt Aufrufe zu anderen Produkten machen. Wenn keine Aufruf-Zugriffsberechtigung wahr ist, dann kann das Produkt Aufrufe unter Anwendung der Aufrufkarteneigenschaft weder durchführen noch empfangen. Gemäß Fig. 1 macht ein Produkt 17a dann, wenn es wünscht, einen entfernten Verfahrensaufruf zu einem Merkmal eines Produkts 17b zu machen, das auf einem anderen Anwenderknoten 16 läuft, einen Aufruf zu seinem Server 13, einschließlich einer Anfrage nach einer Aufrufkarte, und dann, wenn er zugelassen wird, enthält die Erwiderung zum Produkt 17a eine Aufrufkarte 49a. Das Produkt 17a macht dann einen Aufruf zum Produkt 17b auf die normale Weise von RPCs, sendet entlang der Aufrufkarte 49a, welche das Produkt 17b dann durch einen Aufruf zu seinem Server 13 verifiziert, bevor es das aufgerufene Verfahren ausführt und seine Erwiderung zum Produkt 17a ausgibt. Das Merkmal der Aufrufkarten ist wichtig für verteilte Anwendungen. Beispielsweise dann, wenn ein Produkt in einem verteilten System durch Zuordnen von Aufgaben zu anderen CPUs schneller ausführen kann, wird die Ausgabe in bezug darauf präsentiert, welche Lizenzpolice benötigt wird, d. h. muß jeder Knoten, der einen Teil der Aufgabe ausführt, lizensiert sein und eine Zuteilung einer Einheit verbrauchen oder empfangen, oder nur derjenige, der die Aufgabe managt? Dies wird für die meisten Anwendungen durch Anwendung dieses Aufrufkartenkonzepts gelöst. Die Produktanwendungs- Zugriffsberechtigung für ein derartiges Produkt hat das Aufruf- Zugriffsberechtigungsfeld 49 freigegeben, so daß Aufrufkarten ausgegeben werden können. Dieses Merkmal hat typischerweise einen besonderen Preis.
Das Kombinations-Zugriffsberechtigungsfeld 50 der Fig. 2 bestimmt, ob Lizenz- Anfragen von einem Anwenderknoten 16 erfüllt werden können oder nicht durch Kombinieren von Einheiten von mehreren Produktanwendungs- Zugriffsberechtigungen. Es kann vorteilhaft sein, Lizenzen mit verschiedenen Policewerten zu verkaufen, und Einheiten von bestimmten Produktanwendungs- Zugriffsberechtigungen nur für einen Überlauf oder ähnliches anzuwenden. Oder es kann aus anderen Gründen vorteilhaft sein, Einheiten unter Delegiertenservern oder Anwenderknoten zu "borgen" und zu "leihen". Diese Funktion wird durch den Inhalt des Felds 50 zugelassen oder versagt.
Das Überziehungsfeld 51 bestimmt, ob eine angefragte Zuteilung von einem Anwenderknoten 16 nichts desto weniger selbst dann gewährt wird oder nicht, wenn das Feld 42 für verfügbare Einheiten Null oder zu klein ist, um die angefragte Anwendung zuzulassen. Überziehungen können unbeschränkt sein, oder ein spezifischer Überziehungspool kann durch einen Server 10 für interne administrative Zwecke eines Kunden eingestellt werden. Das bedeutet, daß der Überziehungswert in der ursprünglichen Lizenz unbeschränkt sein kann, aber für intern verteilte Kopien der Lizenz beschränkt oder Null sein kann. Somit kann die durch den Herausgeber 25 zum Kunden gesendete Produktanwendungs-Zugriffsberechtigung Überziehungen haben, die durch das Feld 51 zugelassen werden, aber der Kunde kann eine Überziehungserlaubnis für seine eigenen Budgetzwecke versagen. In jedem Fall müssen dann, wenn eine Überziehung zugelassen ist, zusätzliche Gebühren zu irgendeiner Abrechnungsperiode zum Herausgeber gezahlt werden, wenn die protokollierte Anwendung vom Protokoll 24 anzeigt, daß die verfügbaren Einheiten ausgeführt worden sind. Wenn eine Überziehung versagt wird, dann sind die Einheiten 18 der Anwenderknoten, die Anfragezuteilungen durchführen, derart strukturiert, daß sie die Produkte 17 darüber informieren, daß eine Lizenzerteilung bzw. -gewährung nicht verfügbar ist. Es besteht nicht die Absicht, zu verhindern, daß ein Anwenderprogramm läuft; der Lizenzserver informiert die Anwendung lediglich darüber, ob der Lizenz-Manager bestimmt oder nicht, daß sie zum Laufen berechtigt bzw. autorisiert ist. Die Anwendung kann selbst derart strukturiert sein, daß sie sich selbst nach unten fährt, wenn sie nicht zum Laufen autorisiert ist, oder sie kann derart strukturiert sein, daß sie bestimmte Funktionen nach unten fährt (z. B. eine Fähigkeit zum Sichern von Dateien, eine Fähigkeit zum Drucken, etc.), oder sie kann derart strukturiert sein, daß sie auf eine vollständig funktionale Weise fortfährt. Der Zweck der Lizenz-Managementeinrichtung besteht weder in einem Erzwingen noch in einem "Kopienschutz", sondern statt dessen lediglich in einem Lizenz-Management.
Ein optionales Tokenfeld 52 ist bei der ProduktanwendungsZugriffsberechtigung 35 der Fig. 2 verfügbar. Dieses Feld kann Kommentierungen oder andere Informationen enthalten, die vom Herausgeber oder vom Anwender erwünscht sind. Beispielsweise kann eine Telefonunterstützungsnummer im Tokenfeld enthalten sein, und dann, wenn das Produkt 17 seinen "Hilfs-Schirm" zeigt, ist bzw. wird die Nummer eingefügt. Diese Nummer wäre ein Teil des Arguments, d. h. zum Anwenderknoten 16 übertragene Daten, wenn der Server 10 einen Rücksprung durchführt, gefolgt durch eine Anfragezuteilungsnachricht vom Anwender. Dieses Feld kann auch dazu angewendet werden, Informationen zu speichern, die bei einem "privaten" Stil angewendet werden, wobei die Informationen von diesem Feld, die zum Anwenderknoten zurückgebracht werden, durch das Anwenderprogramm 17 oder den Kontrollabschnitt 19 dazu angewendet werden, zu bestimmen, ob die Anwendung aktiviert werden kann.
Das Signaturfeld 53 bei der Produktanwendungs-Zugriffsberechtigung 35 ist ein Teil eines Gültigkeitsmechanismus, der wichtige Merkmale zur Verfügung stellt. Dieses Feld enthält eine digitale Signatur, die codiert ist, um die Daten in der Lizenz selbst zu reflektieren, sowie andere Codierungsverfahren, die den Kunden nicht bekannt sind, so daß sie nicht dupliziert bzw. kopiert werden kann, bis der Codierungsalgorithmus bekannt ist. Bei einem bevorzugten Ausführungsbeispiel wird ein sogenanntes "öffentliches/privates Schlüssel"-System zum Codieren für das Signaturfeld 53 angewendet. Der zum Erzeugen der Signatur 53 angewendete Codierungsalgorithmus ist dem Herausgeber 25 bekannt, und zwar unter Anwendung eines privaten Schlüssels, und jeder, der den öffentlichen Schlüssel kennt, kann die Signatur decodieren, um zu bestimmen, ob er gültig ist, kann aber nicht den Codierungsalgorithmus bestimmen, so daß er keine gefälschte Signatur erzeugen kann. Somit kann der Server 10 dann, wenn er den öffentlichen Schlüssel kennt, der für den Herausgeber 25 eindeutig ist, bestimmen, ob ein Lizenzdokument 35 authentisch bzw. echt ist, aber er kann nicht selbst Lizenzdokumente erzeugen. Jedoch dann, wenn der Server ein gültiges Lizenzdokument besitzt, das ihm das Recht zum Delegieren gibt, wird ihm sein eigener privater Schlüssel zugeteilt (der ein anderer als bei allen anderen Herausgebern oder Servern ist), und seine Delegierten 13 werden bestimmen können, ob eine gültige delegierte Lizenz zu ihnen ausgegeben wird, wenn ihnen der öffentliche Schlüssel für die Server 13 gegeben wird. Das Feld 53 wird somit sowohl die ursprüngliche Signatur vom Herausgeber 25 als auch die Signatur des Lizenzservers enthalten, wenn sie zu einem Delegierten 13 ausgegeben wird. Der Decodierungsalgorithmus, der ein öffentli cher Schlüsselung für irgendwelche Signaturen anwendet, wird somit durch den Lizenzserver 10 oder einen Delegierten 13 dazu angewendet, sicherzustellen, daß eine Produktanwendungs-Zugriffsberechtigung 35 authentisch ist, bevor sie in der Datenbank 23 gespeichert wird. Bezogen auf die digitale Signatur 53 ist ein Prüfsummenfeld 54, das lediglich einen Wert codiert, der durch einen bekannten Algorithmus auf die Daten in der Produktanwendungs-Zugriffsberechtigung 35 selbst bezogen ist. Dieses Feld kann lediglich zum Prüfen auf eine Zerstörung der Daten angewendet werden, wenn sie gespeichert, erneut aufgerufen und innerhalb des Systems übertragen werden. Das bedeutet, daß die Prüfsumme eher für eine Gültigkeitserklärung von Daten als für eine Sicherheit angewendet wird.
Zwei Konzepte, die für das Lizenz-Managementsystem zentral sind, das unter Anwendung des Lizenzdokuments oder der Produktanwendungs-Zugriffsberechtigung 35 der Fig. 2 implementiert ist, sind die "Lizenzeinheiten", die im Feld 41 oder 42 spezifiziert sind, und der "Kontext", der im Feld 44 spezifiziert ist. Lizenzeinheiten sind eine abstrakte numerische Maßnahme einer durch die Lizenz zugelassenen Produktanwendung. Wenn ein Produkt 17 (oder eine Funktion oder ein Merkmal eines Produkts) eine Lizenz-Prüfanfrage durchführt, berechnet das Lizenz- Managementprogramm 11 am Server 10, wieviele Lizenzeinheiten erforderlich sind, um diese bestimmte Anwendung des Produkts zu autorisieren, und dies ist das Lizenzeinheiten-Erfordernis, und zwar in einigen Fällen unter Anwendung des LURDM-Felds 46. Ein "Kontext" ist eine Gruppe von gekennzeichneten Werten, die eine Stelle und eine Umgebung definieren, in welcher eine Produktanwendung oder ein Lizenz-Management auftritt. Kontextwerte können im Feld 44 der Produktanwendungs-Zugriffsberechtigung 35 der Fig. 2 spezifiziert sein, um die Umgebungen zu beschränken, in welchen die Lizenz gemanagt werden kann und in welchen eine Produktanwendung auftreten kann. Eine Kontext-Schablone kann auch im Feld 44 spezifiziert sein, um anzuzeigen, welche Teile des vollständigen Kontexts einer Produktanwendung (Unterkontexte) bei sich unterscheidenden Produktanwendungen zum Zwecke einer Einheitenzuteilung signifikant sind; wenn dies spezifiziert ist, läßt es getrennte Produktanwendungen zum gemeinsamen Nutzen von Lizenzeinheiten auf gesteuerte Weise zu.
Die zwei allgemeinen Typen von Policen, die im Feld 43 spezifiziert sind, sind zuteilend und verbrauchend. Eine Zuteilungspolice gewährt dem Halter eine spezifische Anzahl von Lizenzeinheiten (Feld 41) und spezifiziert die Police, die dazu angewendet werden muß, die Zuteilung dieser Einheiten zu berücksichtigen. Ein Soft wareprodukt 17, das gerade durch eine Zuteilungslizenz gemanagt wird, wird eine Verifizierung erfordern, daß ihm vor einem Durchführen von Diensten zum Anwenden die geeignete Anzahl von Lizenzeinheiten zugeteilt worden ist. Typischerweise erfolgt diese Zuteilung von Einheiten entweder zu der Zeit einer Aktivierung des Produkts 17 oder zu der Zeit, zu der eine Produktanwendung auf einer bestimmten Plattform (der Anwender-CPU 16) freigegeben wird. Die Einheiten bleiben dem Produkt 17 typischerweise während der gesamten Periode zugeteilt, während welcher das Produkt läuft oder zum Laufen freigegeben ist. Auf eine Beendigung einer Verarbeitung oder eines Sperrens hin, werden die zugeteilten Einheiten abgetrennt und für eine Zuteilung zu anderen Fällen des Softwareprodukts 17 verfügbar gemacht (anderen Anwendern 16, die das Produkt aktivieren). Im allgemeinen ist der Halter der Lizenz so lange wie irgendwelche Lizenzeinheiten im Feld 42 nicht zugeteilt bleiben, vertragsmäßig dazu autorisiert, seine Anwendung des lizensierten Produkts zu erhöhen. Die Anwendung löscht jedoch die Lizenz nicht, und sie kann dann, wenn die Einheiten zum Feld 42 für verfügbare Einheiten zurückgebracht sind, nachdem ein Anwender fertig ist, wiederum einem anderen Anwender gewährt werden.
Eine auf einer verbrauchenden Einheit bzw. Verbrauchseinheit basierende Lizenz, die im Policefeld 43 gezeigt ist, gewährt dem Halter eine spezifische Anzahl von anfänglichen Lizenzeinheiten (vom Feld 42) und spezifiziert die Police, die zum Berücksichtigen des Verbrauchs jener Einheiten angewendet wird. Ein Softwareprodukt 17, das gerade durch eine Verbrauchslizenz gemanagt wird, wird veranlassen, daß eine geeignete Anzahl von Lizenzeinheiten verbraucht wird, um die durch das Produkt zur Verfügung gestellten Dienste zu berücksichtigen. Einheiten, die einmal verbraucht sind, können nicht erneut angewendet werden. Somit nimmt die Anzahl von Einheiten, die für eine zukünftige Anwendung verfügbar sind, bei jeder Anwendung des lizensierten Softwareprodukts 17 ab. Dies kann auch "bemaßte bzw. dosierte" Police genannt werden, die konzeptmäßig ähnlich einem gemessenen Verbrauch von Elektrizität, Wasser, etc. ist. Wenn die Anzahl verfügbarer Einheiten im Feld 42 Null erreicht, kann die Lizenz erfordern, daß eine weitere Anwendung des Produkts verhindert wird, oder der Vertrag kann ein fortgeführtes Dekrementieren der Anzahl von verfügbaren Einheiten zulassen; das Ergebnis ist die Akkumulation einer negativen Anzahl verfügbarer Einheiten im Feld 42. Es ist vorausgesetzt, daß die meisten auf einer verbrauchenden Einheit basierenden Lizenzen negative Einheiten berücksichtigen, um eine Verpflichtung des Lizenzhalters zum Bezahlen des Lizenzherausgebers 25 darzustellen. Das Transaktionspro tokoll 24 unterhält eine Schlußrechnungsspur zum Bereitstellen eines Datensatzes der bei einer verbrauchenden Lizenz bzw. einer Verbrauchslizenz angewendeten Einheiten.
Gemäß Fig. 3 sind die Hauptelemente der Managementpolice in einer Tabelle gesetzt, wobei die möglichen Einträge für die Felder 43, 44, 45 und 46 aufgelistet sind. Für den Stileintrag 43 sind die Möglichkeiten zuteilend und verbrauchend, wie es gerade beschrieben ist, plus einer Kategorie, die "privat" genannt wird, die einen Stil eines Managements darstellt, der gegenwärtig nicht definiert ist, sondern statt dessen insbesondere für ein gegebenes Produkt zu erzeugen ist, und zwar unter Anwendung seines eigenen eindeutigen Algorithmus. Es wird erwartet, daß die meisten Lizenzen unter Anwendung der genannten Alternativen der Fig. 3 verwaltet werden können, aber zum Zulassen einer zukünftigen Erweiterung, um Alternativen zu enthalten, die gegenwärtig nicht vorausgesehen werden, oder zum Zulassen spezieller Umstände für eine eindeutige Software, sind die "privaten" Auswahlen enthalten, die lediglich bedeuten, daß das Produkt 17 seine eigenen Anwendungsbedingungen erzeugen wird. Es ist wichtig zu beachten, daß, außer für die "private" Alternative, das Lizenz-Management eher vollständig vom Lizenz- Managementprogramm 11 auf dem Lizenzserver 10 (oder dem Delegierten 13) gesteuert wird, als bei dem Produkt 17. Alles, was das Produkt 17 macht, und zwar über die Einheit 18, dient zum Durchführen der Anfrageuntersuchung zum Server 10 über die Klientenschnittstelle 31 und zum Berichten, wann es endet.
Das Kontextfeld 44 spezifiziert jene Komponenten (Unterkontexte) des Ausführungs-Kontextnamens, der beim Bestimmen dessen angewendet werden sollte, ob Einheitenzuteilungen erforderlich sind. Lizenzdaten werden immer innerhalb des oder zugunsten des irgendwie benannten Lizensierungskontextes angewendet oder zugeteilt, und der Kontext kann "Plattformkontexte" und "Anwendungskontexte" enthalten. Plattformkontexte sind solche Dinge wie ein spezifisches Netzwerk, eine Ausführungsdomäne, eine Einlogdomäne, ein Knoten, eine Verarbeitungs-ID oder eine Verarbeitungsfamilie, ein Anwendername, ein Produktname, ein Betriebssystem, eine spezifische Hardware-Plattform, wie es in Fig. 3 aufgelistet ist. Anwenderkontexte sind Informationen, die von der Anwendung (dem Produkt 17) zugeführt werden, wie sie beispielsweise bei einem "privaten" Verfahren zum Bestimmen einer Lizenzverfügbarkeit angewendet werden können. Der Kontextname kann mehrere von ihnen anwenden, in welchem Fall der Kontextname durch Verketten der Werte aller Unterkontexte in einen einzi gen Kontextnamen aufgebaut ist, z. B. eine Plattform VAX 3100, die ein VMS- Betriebssystem anwendet.
Das Dauerfeld 45 definiert die Dauer einer Zuteilung von Lizenzeinheiten zu einem spezifischen Kontext oder die Dauer der Periode, die eine gültige Verbrauchsanwendung definiert. Für Dauern vom Typ "Zuteilung" ist die Spezifizierung einer Beschränkung einer erneuten Zuteilung auch vorgesehen, wie es unten diskutiert ist. Es gibt drei Typen von Dauern, wobei diese eine "Transaktion", eine "Zuordnung" und eine "Zwischenform" sind, wie es in Fig. 3 zu sehen ist.
Der Transaktions-Dauertyp zeigt dann, wenn er für eine Zuteilungspolice spezifiziert ist, an, daß Lizenzeinheiten auf einen Empfang einer Lizenzanfrage hin zum spezifizierten Kontext zugeteilt werden sollten, und daß jene Einheiten auf einen Empfang einer entsprechenden Lizenzauflösung von einem Anwenderknoten 16 abgetrennt und zum Pool verfügbarer Einheiten zurückgebracht werden sollten. Eine anormale Beendigung des Verfahrens oder des Kontexts, das bzw. der die ursprüngliche Lizenzanfrage durchgeführt hat, wird semantisch äquivalent zu einer Lizenzauflösung sein. Andererseits zeigt dieser Dauertyp dann, wenn er für eine Verbrauchspolice spezifiziert ist, an, daß Lizenzeinheiten zu dem spezifizierten Kontext auf einen Empfang einer Lizenzanfrage zugeteilt und auf einen Empfang einer Lizenzauflösung vom Pool für verfügbare Einheiten (Feld 42) permanent entfernt werden sollten, was eine erfolgreiche Beendigung der Transaktion zeigt. Auf einen Empfang einer Lizenzauflösung hin, die einen Fehlerstatus trägt, oder auf eine anormale Beendigung des Prozessorkontexts hin, der die ursprüngliche Lizenzanfrage durchgeführt hat, werden die zugeteilten Einheiten abgetrennt und zum Pool von verfügbaren Einheiten (Feld 42) zurückgebracht.
Der Zuordnungs-Dauertyp in Fig. 3 (Feld 45 der Fig. 2) erlegt die Beschränkung auf, daß die erforderlichen Einheiten zuvor einem spezifischen Kontext zugeordnet worden sein müssen. Die Unterkontexte, die bei der Zuordnung spezifiziert werden müssen, sind jene, die in der Kontext-Schablone gegeben sind. Eine "Beschränkung einer erneuten Zuordnung" kann auferlegt sein, und dies ist eine Beschränkung diesbezüglich, wie bald eine erneute Zuordnung durchgeführt werden kann. Beispielsweise würde eine Beschränkung einer erneuten Zuordnung von 30 Tagen erfordern, daß einem spezifischen Kontext zugeordnete Einheiten nicht öfter als alle 30 Tage erneut zugeordnet werden könnten; dies würde ein Umgehen der Absicht der Lizenz durch ledigliches erneutes Zuordnen von Einheiten verhin dern, wann immer ein Anwender eines anderen Kontextes einen Anfragezuteilungsaufruf für das Produkt durchführte. Bezogen auf diese Zuordnungsbeschränkung kann eine "Grenze für eine erneute Zuteilung" auch auferlegt sein, um die minimale Dauer einer Zuteilung anzugeben; wo es eine Kontext-Schablone eines Prozesses gibt, besteht die Absicht im Zählen der Anzahl von Anwendungen des Softwareprodukts zu einer gegebenen Zeit, aber wo eine Software eher in einem Stapel läuft, als in einem interaktiven Mode, kann sie auf einer mächtigen Maschine sehr schnell laufen, so daß sehr wenige gleichzeitige Anwendungen eine fast unbeschränkte Anwendung zulassen können - durch Auferlegen einer Beschränkung bezüglich einer erneuten Zuteilung von irgendeiner Zeitperiode kann diese Art eines Umgehens der Absicht der Lizenz beschränkt werden.
Der Direkt-Dauertyp (Feld 45 der Fig. 2) wird dazu angewendet, anzuzeigen, daß die Zuteilung oder der Verbrauch einer geeigneten Anzahl von Lizenzeinheiten vom Pool von verfügbaren Einheiten (Feld 42) sofort bzw. direkt auf einen Empfang einer Lizenzanfrage hin durchgeführt werden sollte. Ein Empfang einer Lizenzauflösung oder anormaler Beendigungen werden dann keinen Einfluß auf das Lizenz- Managementsystem haben. Wenn er als die Dauer für eine Zuteilungspolice spezifiziert ist, wird der Effekt einfach darin bestehen, zu prüfen, ob zu der Zeit einer Lizenzanfrage eine geeignete Anzahl von Lizenzeinheiten verfügbar ist. Wenn er als die Dauer für eine Verbrauchspolice spezifiziert ist, wird der Effekt darin bestehen, die geeignete Anzahl von Lizenzeinheiten vom verfügbaren Pool zu der Zeit einer Lizenzanfrage abzuleiten, und danach wird eine anormale Beendigung, wie beispielsweise ein Fehler bei der Anwender-CPU 16 oder ein Ausfall der Netzwerkverbindung, die Einheiten nicht wieder einsetzen.
Das LURDM- oder das Lizenzeinheitenerfordernis-Bestimmungsverfahren, Feld 46, hat die in Fig. 3 zu sehenden Alternativen und speichert Informationen, die beim Berechnen der Anzahl von Einheiten angewendet werden, die in Antwort auf eine Lizenzanfrage zugeteilt oder verbraucht werden sollten. Wenn dieses Feld eine Tabellennachschauart spezifiziert, bedeutet dies, daß Lizenzeinheitenerfordernisse durch Nachschauen in der LURT (Feld 47) zu bestimmen sind, die zur aktuellen Lizenz gehört. Wenn eine konstante Art spezifiziert ist, zeigt dies an, daß die Lizenzeinheitenerfordernisse für alle Kontexte konstant sind, auf welchen das lizensierte Produkt oder das Produktmerkmal laufen kann. Ein privates LURDM spezifiziert, daß die Lizenzeinheitenerfordernisse durch das lizensierte Produkt 17 zu bestimmen sind, und nicht durch die Lizenz-Managementeinrichtung 11. Die Li zenzeinheitenerfordernistabellen (LURTs) bieten eine Einrichtung, durch welche Herausgeber von Lizenzen Informationen speichern können, die die Beziehung zwischen einem Kontext (oder einem Zeilenselektor) und Einheitenerfordernissen beschreiben. Das Lizenzeinheitenerfordernis-Bestimmungsverfahren (LURDM) muß ein "Tabellennachschauen" für die anzuwendende LURT spezifizieren, und wenn es so ist, muß ein Zeilenselektor spezifiziert werden, wo ein gültiger Zeilenselektor irgendein Unterkontext ist, z. B. eine Plattform-ID, ein Anwendername, eine Tageszeit, etc. Ein Beispiel eines LURT-Fragments ist in Fig. 4 gezeigt, die den Lizenzeinheitenerfordernis-Tabellenmechanismus darstellt. Bei diesem Beispiel ist der Zeilenselektor eine "Plattform-ID", so daß der Plattform-ID-Wert bestimmt, welche Zeile angewendet wird. Der Herausgeber dieser LURT der Fig. 4 hat drei Einheitenerfordernis-Reihen für eine Anwendung beim Bestimmen der Einheitenerfordernisse für jene Produkte des Herausgebers eingerichtet. Der Grund für die Reihen ist nicht durch das Lizenz-Managementsystem vorgeschrieben, sondern der Herausgeber 25 (tatsächlich der Anwender des Programms 26) würde wahrscheinlich drei Preisgebungsreihen ausbilden, von denen jede eine andere Perspektive in bezug auf die relative Nützlichkeit unterschiedlicher Plattformen beim Unterstützen der Anwendung verschiedener Klassen eines Produkts 17 reflektiert. Die erste Spalte in Fig. 4, die Spalte A, spezifiziert die Anwendungserfordernisse für eine Klasse von Produkten, deren Nützlichkeit äußerst empfindlich gegenüber den Eigenschaften der spezifischen Plattform ist, auf der sie laufen. Dies kann durch Beobachten dessen gesehen werden, daß die Einheitenerfordernisse für jede Zeile in der Spalte A unterschiedlich sind. Produkte, die die zweite Spalte (Spalte B) anwenden, erscheinen derart, daß sie eine Nützlichkeit haben, die eher auf die Klasse einer Plattform bezogen ist, auf der sie laufen. Dies ist durch die Tatsache gezeigt, daß alle PC-Plattformen einen einzigen Wert gemeinsam nutzen, der unterschiedlich von demjenigen ist, der der VAX-Plattform zugeordnet ist. Die letzte Spalte (Spalte C) dient zur Anwendung bei einer Klasse von Produkten, die nur auf der VAX-Plattform unterstützt wird. Fig. 4 ist natürlich lediglich ein Beispiel und die tatsächliche LURT, die durch den Lizenzdokumentengenerator 26 erzeugt und in der Lizenzdatenbank 23 (als Feld 47 der Produktanwendungs-Zugriffsberechtigung 35) gespeichert wird, kann von irgendeinem Inhalt dieses allgemeinen Formats sein, wie es durch den Lizenzherausgeber erwünscht ist.
Anstatt immer die Zeilen in LURT-Tabellen gemäß der Plattform-ID der Ausführungsplattform zu wählen, um die Spannweite von Geschäftspraktiken zu behandeln, die durch die Lizenz-Managementeinrichtung unterstützt werden muß, ist der LURT-Mechanismus durch Vorsehen eines "Zeilenselektor"-Attributs in der LURT- Klassenstruktur erweitert. Keine Vorgabe ist vorgesehen, obwohl erwartet wird, daß der normale Wert für das Zeilenselektor-Attribut die "Plattform-ID" ist.
Im System des Patents 4,937,863, wurde ein Konzept vorgesehen, das ähnlich zu demjenigen der LURT der Fig. 4 ist, mit Zeilen, die durch die Plattform-ID ausgewählt werden, und Spalten, die durch irgendeine beliebige Einrichtung ausgewählt werden, und zwar typischerweise gemäß dem Produkttyp. Das System dieser Erfindung erlaubt eine Flexibilität bei der Auswahl von sowohl LURT-Zeilen als auch - Spalten, während es damit fortfährt, eine Abwärtskompatibilität für Lizenzen zur Verfügung zu stellen, die innerhalb der Beschränkungen des Patents 4,937,863 definiert sind.
Einige Beispiele werden mögliche Anwendungen für das Zeilenselektor-Attribut darstellen. Ein Kunde kann nur wünschen, für die Anwendung eines Produkts nur während eines Monats oder während zwei Monaten des Jahres zu zahlen; das Produkt kann FORTRAN sein, und der Grund für die Anfrage kann sein, daß die Firma einen sehr stabilen Satz von FORTRAN-Unterprogrammen hat, denen nur während der Monate Mai und Juni eine regelmäßige "jährliche Wartung" zugeteilt ist. Zum Behandeln dieser Notwendigkeiten des Kunden würde das FORTRAN- Produkt einen Anwendungsunterkontext erzeugen, der einen Wert enthalten würde, der den Monat des Jahrs darstellt. Dann würde eine LURT-Tabelle mit zwölf Zeilen definiert werden, und zwar mit einer für jeden Monat des Jahrs. In irgendeiner Spalte, möglicherweise der Spalte A, würde eine negative Eins (-1) bei jedem Monat außer für Mai und Juni angeordnet werden. Diese zwei Monate würden irgendeine positive Zahl enthalten. Die Produktanwendungs-Zugriffsberechtigung würde dann ein LURDM-Feld haben, das eine LURT für eine Anwendung zum Bestimmen der Einheitenerfordernisse spezifiziert, und würde dies Kunden-LURT- Tabelle nennen. Der Effekt würde darin bestehen, daß die PUA nur während der Monate Mai und Juni angewendet werden könnte, da eine negative Eins durch Lizenz-Manager derart interpretiert wird, daß sie "Anwendung nicht autorisiert" bedeutet. Dieser Mechanismus könnte auch zum Durchführen einer "Tageszeit"- Ladung angewendet werden. Vielleicht für ein Laden von weniger Einheiten pro Anwendung bei Nacht als während des Tages. Ebenso würde dann, wenn ein Unterkontext angewendet würde, der einen Jahreswert enthielt, ein Typ einer Lizenz zur Verfügung gestellt werden, der mit dem Verstreichen von Zeit seine Einheitenerfordernisse veränderte. Beispielsweise könnte er in 1991 beginnen, zehn Ein heiten pro Anwendung zu kosten, aber dann mit dem Verstreichen von Zeit jedes Jahr um eine Einheit weniger kosten, bis man möglicherweise zu der Stelle gelangt, wo das Einheitenerfordernis Null wäre.
Ein weiteres Beispiel sind Schriftsatznamen. Ein spezifischer Kunde kann eine Lizenz kaufen, die ihm das Recht zur gleichzeitigen Anwendung von 100 Einheiten einer großen Schriftsatzsammlung gibt. Einige dieser Schriftsätze können bei einer Anwendung mehr kosten als andere. Beispielsweise könnte Times Roman 10 Einheiten pro Anwendung kosten, während New Century Schoolbook 20 Einheiten pro Anwendung kostet. Das Problem besteht natürlich im Sicherstellen, daß Ladungen geeignet durchgeführt werden. Die Lösung besteht im Bilden einer LURT-Tabelle mit einem spezifizierten Anwendungs-Unterkontext als ihrem Zeilenselektor. Eine Zeile wird dann für jeden Schriftsatz in der Sammlung erzeugt, und in der Spalte A der LURT würde die Anzahl von Einheiten, die für eine Anwendung des Schriftsatzes zu zahlen erforderlich ist, spezifiziert werden. Der Druck-Server würde dann den Namen eines Schriftsatzes als den Wert des Anwendungs-Unterkontextes spezifizieren, wann immer er einen Aufruf Im request allocation() durchführt. Dies würde erlauben, daß Ladungen gemäß einem Schriftsatznamen verändert werden.
Ein weiteres Beispiel ist eine Speichergröße. Einige Produkte sind in Abhängigkeit von der Größe des Speichers, der zum Unterstützen von ihnen verfügbar ist, mehr oder weniger wertvoll. Ein Softwareverkäufer, der wünscht, Einheitenerfordernisse basierend auf einer Speichergröße zu bestimmen, wird dies durch Bilden von LURT-Tabellen mit Zeilen für jedes vernünftige Inkrement eines Speichers (möglicherweise 1-Megabyte-Innkremente) tun können. Ihre Anwendungen würden dann eine Speichergröße (unter Anwendung irgendeines Mechanismus, der kein Teil der Lizenz-Managementeinrichtung ist) erfassen und einen gerundeten Speichergrößenwert zum Lizenz-Manager in einem privaten Kontext weitergeben.
Andere Beispiele sind ein Umgebungs- und Betriebssystem. Einige Produkte können in Abhängigkeit davon unterschiedlich bewertet sein, ob sie in einem interaktiven Mode oder in einem Stapel laufen. Dies kann durch Bilden von LURT-Zeilen für jeden der Standard-Plattform-Unterkontexte erreicht werden, die eine Umgebung spezifizieren. Hinsichtlich des Betriebssystems ist es von vielen als wünschenswert angesehen worden, einer einzigen Produktanwendungs- Zugriffsberechtigung zu erlauben, die Anwendung eines Produkts auf irgendeiner Anzahl von Betriebssystemen zuzulassen, was in Konflikt mit einigen Verkäuferpo licen steht, die nicht wünschen, einen einzigen Preis für ein Produkt erzeugen zu lassen, der auf alle Betriebssysteme Anwendung findet. Somit wäre dann, wenn eine betriebssystemunabhängige Lizenz für einen C-Compiler angeboten würde, der Preis auf MS-DOS, VMS und/oder UNIX derselbe. Es ist klar, daß damit argumentiert werden kann, daß der Wert vieler Produkte teilweise vom Betriebssystem abhängt, das sie unterstützt. Durch Verwenden eines Zeilenselektors eines Betriebssystems (einer der Standard-Plattform-Unterkontexte) könnten Lizenzentwickler in der Tat unterschiedliche Anzahlen von Einheiten für jedes Betriebssystem erfordern. Jedoch könnte es wünschenswerter sein, die Zeilenauswahl auf einem privaten Anwendungs-Unterkontext zu basieren, der normalerweise denselben Wert wie der Betriebssystem-Unterkontext hatte. Der Grund dafür besteht darin, daß der Lizenzentwickler wünschen könnte, einen Vorgabewert für Betriebssystemnamen zur Verfügung zu stellen, die zu der Zeit unbekannt waren, zu der die LURT-Zeilen definiert wurden. Wenn dies der Fall ist, würde das Produkt eine Liste bekannter Betriebssysteme enthalten und den Unterkontext-Wert von "unbekannt" durchlassen, wenn es geeignet ist. Die LURT-Zeile für "unbekannt" würde entweder eine negative Eins (-1) zum Anzeigen, daß dieses Betriebssystem nicht unterstützt wurde, enthalten, oder sie würde irgendein Vorgabe-Einheitenerfordernis enthalten.
Ein weiteres Beispiel ist eine variable Preisvorgabe innerhalb einer Gruppe. Eines der Probleme bei einer "Gruppen"-Lizenz besteht darin, daß es nur ein Einheitenerfordernis-Feld auf der PUA für eine Gruppe gibt. Somit, nutzen alle Elemente der Gruppe ein einziges Einheitenerfordernis gemeinsam. Jedoch kann in denjenigen Fällen, in denen alle Elemente der Gruppe mit einem konstanten Einheitenerfordernis geeignet lizensiert werden kann und es dennoch gewünscht wird, unterschiedliche Beträge für die Anwendung jedes Gruppenelements zu belasten, eine LURT gebildet werden, die Zeilen hat, die für jedes Gruppenelement definiert sind. Der Zeilenselektor für eine solche Gruppe würde der Standard-Plattform- Unterkontext "Produktname" sein.
Viele unterschiedliche Typen von Lizenzen können unter Anwendung unterschiedlicher Kombinationen von Kontexten, einer Dauer und einer Police aus der Tabelle der Fig. 3 erzeugt werden. Als Beispiele zeigen die folgenden Absätze einige herkömmliche Lizensierungsstile, die unter Anwendung der geeigneten Werte der Produktanwendungs-Zugriffsberechtigungsfelder 43-46 implementiert sein können.
Eine "Systemlizenz", wie sie herkömmlich bestimmt ist, ist eine Lizenz, die eine unbeschränkte Anwendung eines Produkts auf einem einzigen Hardware-System zuläßt. Die richtige Anzahl von Einheiten muß dem Prozessor im voraus zugeteilt werden, und dann ist Anwendern des Systems eine unbeschränkte Produktanwendung verfügbar. Die Produktanwendungs-Zugriffsberechtigung würde im Kontextfeld 44 eine Kontext-Schablone für einen Knotennamen haben, das Dauerfeld würde "Zuordnung" sein, und das Policestilfeld 43 würde "zuteilend" sein.
Eine Lizenz für "gleichzeitige Anwendung" ist eine, die die Anzahl von gleichzeitigen Anwendungen eines lizensierten Produkts beschränkt. Einheiten einer Lizenz für eine gleichzeitige Anwendung werden nur zugeteilt, wenn das Produkt gerade angewendet wird, und jeder gleichzeitige Anwender des lizensierten Produkts erfordert seine eigenen Einheiten. In diesem Fall ist die Kontext-Schablone, Feld 44, eine Prozeß-ID, das Dauerfeld ist "Transaktion" und Policestil 43 ist "zuteilend".
Eine Lizenz für eine "persönliche Anwendung" ist eine, die die Anzahl genannter Anwender eines lizensierten Produkts beschränkt. Dieser Stil zum Lizensieren garantiert, daß die Elemente einer Liste von Anwendern auf ein Produkt zugreift. Zu einem Typ einer persönlichen Anwendung einer Produktanwendungs- Zugriffsberechtigung gehörend gibt es eine Liste registrierter Anwender. Der Administrator kann diese Anwender, wie es erforderlich ist, bis zu der Grenze zuordnen, die durch die Produktanwendungs-Zugriffsberechtigung auferlegt ist; die Anzahl von jedem Anwender zugeordneten Einheiten wird durch das LURDM angezeigt. Sie kann eine Konstante sein oder sie kann variieren, wie es in einer LURT spezifiziert ist. Die Kontext-Schablone ist ein "Anwendername", die Dauer ist "Zuordnung" und die Police ist "zuteilend".
Eine "Stellenlizenz" ist eine, die die Anwendung eines lizensierten Produkts auf eine physikalische Stelle bzw. einen physikalischen Ort beschränkt. Hier enthält die Produktanwendungs-Zugriffsberechtigung für die Kontext-Schablone entweder einen "Netzwerknamen" oder einen "Domänennamen", die Dauer ist "Zuordnung" und das Policestil-Feld 43 ist "zuteilend".
Allgemein wird der Preis für eine Lizenz zum Anwenden eines Softwareprodukts demgemäß gestaltet, wieviele Vorteile aus einem Anwenden des Produkts erlangt werden können, was sich auf die Kapazität der Maschine bezieht, auf der es laufen wird. Eine Lizenz für eine unbeschränkte Anwendung auf einer großen Plattform, wie beispielsweise einem Hauptrechner, wo es Tausende von möglichen Anwendern an Endgeräten geben könnte, würde einen Preis auf einer hohen Ebene haben. Hier würde der Stil "zuteilend" sein, die Kontext-Schablone = "Knoten", die Dauer = "Zuordnung" und das LURDM kann die "Spalte A" sein - die Einheiten jedoch würden groß sein, z. B. 1000. Am anderen Ende der Skala wäre eine Lizenz für eine Anwendung auf einem einzigen Personalcomputer, wo die Feldwerte dieselben wie für den Hauptrechner sein würden, außer daß die Einheiten "1" wären. Wenn ein Kunde wünschte, das Produkt auf dem Hauptrechner verfügbar zu machen, aber dennoch die Kosten beschränken möchte, könnte er vielleicht eine Lizenz bekommen, die nur fünf Anwender zu einer gegebenen Zeit zum Anwenden des Produkts zulassen würde; hier würden die Felder bei der Produktanwendungs- Zugriffsberechtigung folgende sein: Einheiten = 5; Stil = zuteilend; Kontext- Schablone = Prozeß; Dauer = Transaktion; LURDM = konstant; 1-Einheit. Dies würde bezüglich des Preises noch sehr hoch sein, da eine große Anzahl von Anwendern tatsächlich das Produkt anwenden kann, wenn eine Session bzw. eine Sitzung einer Anwendung kurz wäre. Ein niedrigerer Preis wäre möglicherweise für eine persönliche Anwendungslizenz verfügbar, wo nur fünf benannte Personen das Produkt anwenden könnten, wobei diese nur beim Lizenzserver 10 identifiziert werden und nicht durch den Lizenzherausgeber 25 benannt werden. Hier sind die Felder bei der Produktanwendungs-Zugriffsberechtigung folgende: Einheiten = 5; Stil = zuteilend; Kontext-Schablone = Anwendername; LURDM = konstant, 1- Einheit.
Ein zusätzliches Merkmal, das in der Produktanwendungs-Zugriffsberechtigung 35 vorgesehen sein kann, ist eine Lizenzkombination. Wo es mehrfache Zugriffsberichtigungen für ein Produkt gibt, können durch Anwenderknoten 16 gesendete Lizenzprüfanfragen durch Kombinieren von Einheiten von mehrfachen Zugriffsberechtigungen erfüllt werden. Einzelne Produktanwendungs-Zugriffsberechtigungen können eine kombinierte Anwendung verbieten. Somit kann ein Lizenznehmer eine Lizenz zum Anwenden eines Produkts 17 auf einer Zuteilungsbasis für eine gewisse Anzahl von Einheiten und auf einer Verbrauchsbasis für eine weitere Anzahl von Einheiten (dies kann vom Standpunkt der Preisgabe aus gesehen attraktiv sein) haben; es könnte nicht genügend Einheiten geben, die für einen bestimmten Kontext von einer dieser Lizenzen verfügbar sind, so daß einige Einheiten von der anderen Lizenz (Produktanwendungs-Zugriffsberechtigung) "geborgt" werden können, in welchem Fall eine Kombination gemacht wird.
Die Schnittstelle zwischen dem Programm, das beim Klienten oder Anwender 16 ausführt, und dem Lizenzserver 10 oder seinen Delegierten 13 enthält grundsätzlich drei Verfahrensaufrufe: eine Anfragezuteilung, eine Freigabezuteilung und eine Abfragezuteilung. Figur b stellt in Form eines Ablaufdiagramms einige der Ereignisse dar, die bei dieser Klientenschnittstelle auftreten. Die Anfragezuteilung ist die grundsätzliche Lizenzprüffunktion, ein Verfahrensaufruf, der dann aufgerufen wird, wenn ein Softwareprodukt 17 gerade begonnen wird, der zum Anfragen einer Zuteilung von Lizenzeinheiten funktioniert, wobei die Erwiderung eine Gewährung oder eine Zurückweisung einer Gewährung ist. Es ist zu beachten, daß ein Produkt Anfragezuteilungsaufrufe eher bei einer Anzahl von Stellen beim Ausführen eines Programms anwenden kann, als nur beim Hochfahren; beispielsweise kann eine Anfragezuteilung beim Anwenden irgendeines bestimmten Merkmals gesendet werden, wie beispielsweise eines speziellen Graphikpakets oder ähnlichem. Der Freigabezuteilungsaufruf wird aufgerufen, wenn der Anwender die Zuteilung nicht mehr benötigt, z. B. die Aufgabe beendet ist, und diese Erwiderung ist oft lediglich eine Bestätigung; wenn der Stil verbrauchend ist, hat der Aufrufer die Gelegenheit, über den Freigabezuteilungsaufruf die Anzahl von verbrauchten Einheiten zu beeinflussen, z. B. die Anzahl aufgrund irgendeines Ereignisses zu erniedrigen. Der Abfragezuteilungsaufruf wird durch den Anwender aufgerufen, um Informationen über eine existierende Zuteilung zu erhalten oder um eine Aufrufkarte zu erhalten, wie es beschrieben wird.
Die Anfragezuteilung, die Im request allocation() genannt wird, ist eine Anfrage, daß Lizenzeinheiten dem aktuellen Kontext zugeteilt werden. Diese Funktion bringt einen Gewährungs- oder einen Absagestatus zurück, der durch den Anwendungsprogrammierer dazu angewendet werden kann, zu entscheiden, ob eine Anwendung des Produkts oder eines Produktmerkmals zu erlauben ist. Der Status basiert auf der Existenz einer geeigneten Produktanwendungs-Zugriffsberechtigung und irgendwelchen Lizenz-Managementpolicen, die zu jener Produktanwendungs- Zugriffsberechtigung gehören können. Lizenzeinheiten werden zugeteilt oder verbraucht, wenn sie verfügbar sind, und zwar gemäß der Policeangabe, die über die geeignete Produktanwendungs-Zugriffsberechtigung gefunden wird. Das Produkt würde normalerweise diese Funktion vor einer Anwendung eines lizensierten Produkts oder eines Produktmerkmals aufrufen. Die Funktion wird nicht verursachen, daß die Ausführung des Produkts beendet wird, wenn die Anfrage fehlschlagen sollte. Die Entscheidung darüber, was im Fall eines Fehlschlags zu tun ist, um eine Zuteilung von Lizenzeinheiten zu erhalten, wird dem Programmierer überlassen.
Die Argumente in einem Anfragezuteilungsaufruf sind der Produktname, der Herstellername, die Version, das Veröffentlichungsdatum und eine Anfrageerweiterung. Der Produktname, der Herstellername, die Version und das Veröffentlichungsdatum sind der Name des Softwareprodukts, der Name des Herstellers, die Versionsnummer und das Veröffentlichungsdatum zum spezifischen Identifizieren des Produkts, das der Anwender gerade zum Durchführen einer Zuteilung anfragt. Das Anfrageerweiterungsargument ist ein Objekt, das erweiterte Attribute der Anfrage beschreibt, wie beispielsweise erforderliche Einheiten, eine LURT-Spalte, einen privaten Kontext und einen Kommentar. Die zum Aufrufknoten zurückgesendeten Ergebnisse sind ein Erwiderungscode, der anzeigt, ob die Funktion erfolgreich war, und dann, wenn sie es nicht war, warum nicht, und eine Gewährungshandhabung, die dann zurückgebracht wird, wenn die Funktion erfolgreich beendet, was eine identifizierende Handlung für diese Gewährung ergibt, so daß auf sie beispielsweise in einem nachfolgenden Freigabezuteilungsaufruf oder Abfragezuteilungsaufruf Bezug genommen werden kann.
Die Freigabezuteilung, die Im_release_allocation() genannt wird, ist ein Anzeichen von einem Anwender zum Lizenz-Manager zum Freigeben oder Verbrauchen von zuvor zugeteilten Einheiten. Diese Funktion gibt eine Zuteilungsgewährung frei, die in Antwort auf einen früheren Aufruf zum Anfragen einer Zuteilung gemacht wurde. Auf eine Freigabe hin bestimmt der Lizenz-Managementstil 38, ob die Einheiten zum Pool verfügbarer Einheiten zurückgebracht oder verbraucht werden sollten. Wenn der Aufrufer eine Anfrageerweiterung beim früheren Aufruf zum Anfragen einer Zuteilung spezifiziert hatte, der ein Attribut für erforderliche Einheiten enthielt, und die Anzahl von Einheiten, die zu dieser Zeit angefragt wurden, nicht die Anzahl von Einheiten ist, die für die vollständige Operation verbraucht werden sollten, sollte der Aufrufer mit dem Argument für verbrauchte Einheiten angeben, wieviele Einheiten verbraucht werden sollten. Die Argumente der Freigabezuteilung sind folgende: eine Gewährungshandhabung, verbrauchte Einheiten und ein Kommentar. Die Gewährungshandhabung identifiziert die Zuteilungsgewährung, die durch einen vorherigen Aufruf zum Anfragen einer Zuteilung erzeugt wird. Das Argument für verbrauchte Einheiten identifiziert die Anzahl von Einheiten, die verbraucht werden sollten, wenn die Lizenzpolice verbrauchend ist; dieses Argument sollte nur in Kombination mit einem früheren Aufruf zum Anfragen einer Zuteilung angewendet werden, der eine Einheitenanforderung in einer Anfrageerweiterung spezifizierte. Ein Weglassen dieses Arguments zeigt an, daß die Anzahl von zu verbrauchenden Einheiten dieselbe wie die zuvor zugeteilte Anzahl ist. Das Kommentierungsargu ment ist eine Kommentierung, die zur Protokollierungsdatei 24 geschrieben wird, wenn Freigabeeinheiten von einer Lizenz für einen Verbrauchsstil sind oder wenn eine Protokollierung ermöglicht ist. Das Ergebnis ist ein Erwiderungscode, der anzeigt, ob die Funktion erfolgreich war, und dann, wenn sie es nicht war, warum nicht.
Die Abfragezuteilung oder Im_query_allocation() wird durch lizensierte Produkte angewendet, die Zuteilungen durch einen vorherigen Anfragezuteilungsaufruf empfangen haben. Die Abfrage erfolgt zum Erhalten von Informationen vom Server 10 oder vom Delegiertenserver 13 über die Art der Gewährung, die dem Anwender bewilligt worden ist, und die beim Bewilligen der Gewährung angewendeten Lizenzdaten, oder zum Erhalten einer Aufrufkarte (d. h. einer Anfrage, daß eine Aufrufkarte ausgegeben wird). Typischerweise ist das Element, das durch diese Abfragefunktion gelesen wird, das Tokenfeld 42, das willkürliche Informationen enthält, die durch den Lizenzherausgeber codiert sind, und das interpretiert werden kann, wie es durch den Kontrollabschnitt 19 für die lizensierte Produktsoftware 17 erforderlich ist, und zwar normalerweise dann, wenn ein "privater" Zuteilungsstil oder Kontext angewendet wird. Die Argumente in diesem Verfahrensaufruf sind die Gewährungshandhabung und das Subjekt. Die Gewährungshandhabung identifiziert die durch einen vorherigen Aufruf zum Anfragen einer Zuteilung erzeugte Zuteilungsgewährung. Das Subjektargument ist entweder "Produktanwendungs- Zugriffsberechtigung" oder "Aufrufkartenanfrage"; wenn es das erstere ist, dann wird das Ergebnis eine öffentliche Kopie der Produktanwendungs- Zugriffsberechtigung enthalten. Wenn dieses Argument eine Aufrufkartenanfrage ist und eine Aufrufkarte, die an die vorherigen Beschränkungen angepaßt ist, die in jener Anfrage spezifiziert sind, verfügbar gemacht werden kann, wird das Ergebnis eine Aufrufkarte enthalten. Wenn das Subjektargument weggelassen ist, wird das Ergebnis ein Beispiel der Zuteilung enthalten. Die Ergebnis des Abfragezuteilungsaufrufs sind (1) ein Erwiderungscode, der anzeigt, ob die Funktion erfolgreich war, und dann, wenn sie es nicht war, warum nicht und (2) ein Ergebnis, das entweder eine Zuteilung, eine Produktanwendungs-Zugriffsberechtigung oder eine Aufrufkarte ist, in Abhängigkeit vom Typ und vom Vorhandensein des Subjektarguments.
Gemäß Fig. 5 zeigt das Ablaufdiagramm die Aktionen beim Klienten in seiner Schnittstelle zum Server. Wenn das Softwareprodukt 17 aufzurufen ist, wird zuerst die Einheit 18 ausgeführt, wie es durch den Block 60 angezeigt ist, und die erste Aktion besteht im Durchführen eines Anfragezuteilungsaufrufs über den Kontroll abschnitt 19, der durch den Block 61 angezeigt ist. Der Klient wartet auf eine Erwiderung, was durch die Schleife 62 angezeigt ist, und wenn eine Erwiderung empfangen wird, wird sie beim Entscheidungsblock 63 geprüft, um zu sehen, ob sie eine Gewährung ist. Wenn nicht, wird der Fehlercode in der Erwiderung beim Block 64 geprüft, und dann, wenn ein Erwiderungscode anzeigt, daß ein erneuter Versuch möglich ist, Block 65, geht die Steuerung zurück zum Anfang, aber dann, wenn kein erneuter Versuch durchzuführen ist, dann wird die Ausführung abgeschlossen. Wenn die Police darin besteht, eine Anwendung des Produkts 17 ohne eine Lizenzgewährung zuzulassen, wird diese Funktion getrennt berücksichtigt. Wenn die Entscheidungsstelle 63 anzeigt, daß eine Gewährung durchgeführt wurde, wird für eine spätere Bezugnahme eine Gewährungshandhabung gespeichert, Block 66. Das Programm 17 wird dann für die durch den Anwender beabsichtigten Hauptaktivitäten eingegeben. Während dieser Ausführung des Produkts 17, oder davor oder danach, kann ein Abfragezuteilungsaufruf durchgeführt werden, Block 67, obwohl dies optional ist und in den meisten Fällen nicht benötigt wird. Wenn eine Ausführung des Programms 17 angewendet ist, wird die Gewährungshandhabung ausgelesen, Block 68, und ein Freigabezuteilungsaufruf wird durchgeführt, Block 69. Eine Schleife 70 zeigt ein Warten auf die Erwiderung vom Server an, und wenn die Erwiderung empfangen wird, wird sie wie zuvor auf einen Fehlercode geprüft, und ein erneutes Versuchen kann geeignet sein. Wenn die Freigabe erfolgreich bestätigt wird, tritt das Programm aus.
Gemäß Fig. 6 sind die Aktionen des Servers 10 oder des Delegiertenservers 13 beim Ausführen des Lizenz-Managementprogramms 11 oder 14 für die Klientenschnittstelle in Form eines Ablaufdiagramms dargestellt. Eine Schleife ist gezeigt, wo das Serverprogramm auf einen Empfang eines Anfrage-, Freigabe- oder Abfrageaufrufs von seinem Klienten prüft. Der Aufruf wäre ein entfernter Verfahrensaufruf, wie es oben diskutiert ist, und wäre beispielsweise eine durch ein Netzwerk kommunizierte Nachricht. Diese Schleife zeigt die Entscheidungsblöcke 71, 72 und 73. Wenn ein Freigabe-Zuteilungsaufruf empfangen wird, wird eine Liste von Produkten, für die Zugriffsberechtigungen gespeichert sind, abgetastet, Block 74, und mit der im Argument des empfangenen Aufrufs gegebenen Produktidentität verglichen, Block 75. Wenn es keine Übereinstimmung gibt, wird ein Fehlercode zum Klienten zurückgebracht, Block 76, und eine Steuerung geht zurück zur Anfangsschleife. Wenn das Produkt gefunden wird, wird die Zugriffsberechtigung aus der Datenbank 73 ausgelesen, Block 77 (es kann mehr als eine Zugriffsberechtigung für ein gegebenes Produkt geben, in welchem Fall alle ausgelesen wurden, aber hier wird nur auf eine Bezug genommen), und alle Informationen werden angepaßt, und die Berechnungen werden in Abhängigkeit von der Managementpolice der Fig. 3 und 4 durchgeführt, was durch den Entscheidungsblock 78 angezeigt ist. Wenn eine Gewährung durchgeführt werden kann, wird sie zurückgebracht, wie es beim Block 79 angezeigt ist, oder wenn nicht, wird ein Fehlercode zurückgebracht, Block 80. Wenn ein Freigabe-Zuteilungsaufruf empfangen wird, was durch ein positives Vorzeichen beim Entscheidungsblock 72 angezeigt ist, wird beim Block 81 die Gewährungshandhabung im Argument auf eine Gültigkeit geprüft. Wenn keine Übereinstimmung gefunden wird, wird ein Fehlercode zurückgebracht, Block 82, und die Steuerung geht zurück zur Anfangsschleife. Wenn die Handhabung gültig ist, wird die Zugriffsberechtigung für dieses Produkt aus der Datenbank 23 beim Block 83 ausgelesen und einem Updaten unterzogen, wie es durch den Block 84 angezeigt ist. Beispielsweise dann, wenn der Lizenz-Managementstil zuteilend ist, werden die Einheiten zum verfügbaren Pool zurückgebracht. Oder es wird in einigen Fällen kein Updaten benötigt. Die Zugriffsberechtigung wird wiederum in der Datenbank gespeichert, Block 85, und eine Erwiderung wird zum Klienten durchgeführt, Block 86, bevor die Steuerung zurück zur Anfangsschleife läuft. Wenn der Entscheidungsblock 73 anzeigt, daß ein Abfrage-Zuteilungsaufruf empfangen wird, wird die Gewährungshandhabung wiederum beim Block 87 geprüft, und ein Fehlercode wird beim Block 88 zurückgebracht, wenn sie nicht gültig ist. Wenn die Gewährungshandhabung angepaßt ist, wird die Zugriffsberechtigung aus der Datenbank 23 ausgelesen, beim Block 89, und eine Erwiderung zum Klienten wird durchgeführt, welche die angefragten Informationen im Argument gibt, Block 90.
Der bei dem Ausführungsbeispiel des hierin beschriebenen Lizenz- Managementsystems angewendete und im Verfahren der Fig. 5 und 6 implementierte grundsätzliche Zuteilungsalgorithmus ist sehr einfach und kann einen sehr großen Anteil bekannter Lizenzeinheiten-Zuteilungsprobleme handhaben. Jedoch sollte erkannt werden, daß ein ausgeklügelterer und erweiterter Algorithmus enthalten sein könnte. Hinzufügungen könnten durchgeführt werden, um den Zuteilungsalgorithmus so zu erweitern, daß er eine spezifische Unterstützung zum Optimieren einer Einheitszuteilung in einer weiteren Vielfalt von Situationen hätte. Insbesondere sind Quellen nicht optimaler Zuteilungen, die dann auftreten, wenn der grundsätzliche Zuteilungsalgorithmus angewendet wird, diejenigen, die aus einer Kombinations- und einer Reservierungshandhabung entstehen.
Der erste Schritt ist eine Ausbildung eines vollständigen Kontexts. Der Klienten- Kontrollabschnitt 19 ist verantwortlich für ein Sammeln aller spezifizierten Plattform- und Anwendungsunterkontexte aus der Ausführungsumgebung des Produkts 17 und für ein Weiterleiten dieser gesammelten Unterkontexte zum Lizenz- Managementserver 13 oder 10. Die Sammlung von Unterkontexten wird für eine bestimmte Lizenzeinheiten-Zuteilungsanfrage "vollständiger Kontext" genannt.
Der nächste Schritt ist ein Auslesen der Kontextmaske. Wenn der Lizenz-Manager Im_request_allocation() empfängt, wird er in seine Liste verfügbarer Produktanwendungs-Zugriffsberechtigungen (PUA) schauen, um zu bestimmen, ob irgendwelche von ihnen mit dem Produktidentifizierer übereinstimmen, der im Aufruf Im_request_allocation() vorgesehen ist. Der Produktidentifizierer ist zusammengesetzt aus: Produktname, Hersteller, Version, Veröffentlichungsdatum. Wenn irgendeine Übereinstimmung gefunden wird, wird der Lizenz-Manager die Kontextmaske aus der übereinstimmenden PUA extrahieren. Diese Maske ist aus einer Liste von Unterkontexten zusammengesetzt, die relevant für den Prozeß zum Bestimmen von Einheitenanforderungen sind. Somit kann eine Kontextmaske anzeigen, daß der Knoten-ID-Unterkontext eines spezifischen vollständigen Kontexts für die Zwecke einer Einheitenzuteilung von Interesse ist. Die Kontextmaske würde keinerlei spezifischen Wert für die Knoten-ID spezifizieren; vielmehr sagt sie einfach, daß eine Knoten-ID beim Durchführen der Zuteilungsberechnung angewendet werden sollte.
Der nächste Schritt besteht im Maskieren des vollständigen Kontexts. Wenn er die Kontextmaske ausgelesen hat, wird der Lizenz-Manager dann einen "Zuteilungskontext" durch Filtern des vollständigen Kontexts bilden, um alle Unterkontexte zu entfernen, die nicht in der Kontextmaske bzw. -schablone aufgelistet sind. Dieser Zuteilungskontext ist der Kontext, der beim Bestimmen von Zuteilungsanforderungen anzuwenden ist.
Dann folgt der Schritt zum Bestimmen, ob die Anfrage neu ist. Der Lizenz-Manager unterhält für jede Produktanwendungs-Zugriffsberechtigung eine dynamische Tabelle, die die Zuteilungskontexte für alle ausstehenden Zuteilungen für jene PUA enthält (d. h. Zuteilungen, die gewährt worden sind, aber noch nicht freigegeben worden sind). Zu jedem Eintrag in dieser Tabelle gehört ein gewisses Maß an Buchhaltungsinformationen, die die Anzahl von zugeteilten Einheiten, den vollständigen Kontext, etc. aufzeichnen. Um zu bestimmen, ob eine letzte Im_request_allocation() erfordert, daß eine Zuteilung von Einheiten durchzuführen ist, vergleicht der Lizenz-Manager den neuen Zuteilungskontext mit allen denjenigen Zuteilungskontexten in der Tabelle ausstehender Zuteilungen und bestimmt, ob eine Zuteilung zum Zuteilungskontext bereits durchgeführt worden ist. Wenn der neue Zuteilungskontext nicht bereits in der Tabelle existiert, wird ein Versuch zum Zuteilen der geeigneten Anzahl von Einheiten in Abhängigkeit von den Werten durchgeführt werden, die in der LURDM-Struktur der PUA enthalten sind, und irgendwelchen LRTs, die erforderlich sein könnten. Wenn ein Zuteilungskontext ähnlich dem in der neuen Zuteilungsanfrage spezifizierten in der Tabelle existiert, wird der Lizenz-Manager verifizieren, daß die Anzahl von zuvor zugeteilten Einheiten gleich oder größer als die Anzahl von Einheiten ist, für die es nötig wäre, zugeteilt zu werden, um die neue Zuteilungsanfrage zu erfüllen. Wenn es so ist, wird der Lizenz-Manager eine Gewährungshandhabung zur Anwendung zurückbringen, die anzeigt, daß die Zuteilung durchgeführt worden ist (d. h. sie ist eine "geteilte bzw. gemeinsam genutzte Zuteilung" - die zugeteilten Einheiten werden von zwei Anfragen gemeinsam genutzt bzw. sind zwischen zwei Anfragen aufgeteilt). Wenn es nicht so ist, wird der Lizenz-Manager versuchen, eine Anzahl von Einheiten zuzuteilen, die gleich der Differenz zwischen der zuvor zugeteilten Anzahl und der Anzahl von erforderlichen Einheiten ist.
Der Schritt zum Freigeben von Zuteilungen (Fig. 6, Blöcke 84-85) tritt auf, wenn der Lizenz-Manager einen Aufruf Im_release_allocation() empfängt; er wird den Datensatz in seiner dynamischen Zuteilungstabelle entfernen, die der freizugebenden Zuteilung entspricht. Nachdem der Lizenz-Manager dies durchgeführt hat, wird er dann bestimmen, ob die zu entfernende Zuteilung durch irgendeinen anderen Zuteilungskontext gemeinsam genutzt wird. Wenn es so ist, werden die zu der Zuteilung, die freigegeben wird, gehörenden Einheiten nicht freigegeben. Sie werden zu den übrigen Zuteilungskontexten zugeteilt bleiben. Einige der Einheiten könnten freigegeben werden, wenn der Lizenz-Manager bestimmt, daß die Anzahl zugeteilter Einheiten die zum Erfüllen der ausstehenden Zuteilungskontexte nötige Anzahl übersteigt. Wenn dies der Fall ist, wird der Lizenz-Manager die Anzahl zugeteilter Einheiten auf eine geeignete Ebene "trimmen bzw. abgleichen".
Zusammengefaßt sind die zwei Dinge, die diesen Algorithmus arbeiten lassen (1) die Grundregel, daß nicht mehr als eine Zuteilung zu einem einzigen Zuteilungskontext durchgeführt wird, und (2) die Anwendung der Kontextschablone, um sonst ungleiche bzw. nicht ähnliche volle Kontexte derart erscheinen zu lassen, daß sie für die Zwecke einer Zuteilung gleich sind.
Die Aufgabe eines Lizenzentwicklers beim Definieren einer Grundpolice besteht dann im Bestimmen, welche Kontexte dem Lizenz-Manager derart erscheinen sollten, daß sie dieselben sind. Wenn der Lizenzentwickler entscheidet, daß alle Kontexte an einem einzigen Knoten genauso ausschauen sollten (Kontextschablone = Knoten-ID), dann werden irgendwelche Anfragen, die von jenem Knoten kommen, alle Zuteilungen gemeinsam nutzen. Andererseits wird einer Entscheidung, daß alle Kontexte eindeutig sein sollten (d. h. Kontextschablone = Prozeß-ID), bedeuten, daß Zuteilungen niemals gemeinsam genutzt werden.

[TEXT FEHLT]

und speichert einen Einheitenwert, der die Anzahl von Lizenzeinheiten für jedes Produkt anzeigt. Wenn ein Anwender wünscht, ein lizensiertes Produkt anzuwenden, wird eine Nachricht zur zentralen Lizenz-Managementeinrichtung gesendet, die eine Lizenzgewährung anfragt. In Antwort auf diese Nachricht greift die Einrichtung auf die Datenbank zu, um zu sehen, ob eine Lizenz für dieses Produkt existiert, und wenn es so ist, ob dem Anwender Einheiten zugeteilt werden können, und zwar in Abhängigkeit von den Eigenschaften des Anwenders, wie beispielsweise der Konfiguration der Plattform (CPU), die das Softwareprodukt ausführen wird. Wenn die Lizenz-Managementeinrichtung bestimmt, daß eine Lizenz gewährt werden kann, sendet sie eine Nachricht zum Anwender, welche Nachricht eine Erlaubnis zum Weitermachen mit einer Aktivierung des Produkts gibt. Wenn nicht, lehnt die Nachricht eine Erlaubnis ab.
Während die im Patent 4,937,863 offenbarten Konzepte weit verbreitet anwendbar sind und tatsächlich bei der vorliegenden Erfindung angewendet werden, gibt es zusätzliche Funktionen und Alternativen, die bei einigen Anwendungen nötig sind. Beispielsweise sollte das Lizenz-Managementsystem eine gleichzeitige Anwendung einer breiten Vielfalt von unterschiedlichen Lizensierungsalternativen zulassen, anstatt daß es streng strukturiert ist, um nur eine oder nur wenige zuzulassen. Beim Verhandeln über Lizenzen mit Anwendern sollten Verkäufer eine breite Vielfalt von Termen und Konditionen verfügbar haben, selbst wenn ein gegebener Verkäufer entscheiden kann, die Auswahl auf eine kleine Anzahl nach unten zu beschränken. Beispielsweise kann ein Softwareprodukt für ein einziges Individuum für eine Anwendung auf einer einzigen CPU lizensiert werden, oder für eine Organisation für eine Anwendung von irgendjemandem auf einem Netzwerk oder für eine Anwendung durch irgendwelche Anwender an Endgeräten in einem Cluster oder nur für Aufrufe von einem anderen spezifischen lizensierten Produkt oder irgendeine einer großen Anzahl anderer Alternativen. Ein Verkäufer kann eine große Anzahl von Produkten haben, von denen einige unter einem Typ einer Lizenz verkauft werden, und einige unter anderen, oder ein Produkt kann eine Zusammensetzung aus einer Anzahl von Eigenschaften von einem oder mehreren Verkäufern mit unterschiedlichen Lizenzpolicen und Preisen sein; es wäre vorzuziehen, dasselbe Lizenz-Managementsystem für alle solche Produkte anzuwenden.
Verteilte Rechensysteme präsentieren zusätzliche Lizensierungsausgaben. Ein verteiltes System enthält eine Anzahl von Prozessorknoten, die in einem Netzwerk von Servern und Klienten miteinander verknüpft sind. Jeder Knoten ist ein Prozes sor, der Programme lokal ausführen kann, und auch Programme oder Merkmale (Unterteile von Programmen) über das Netzwerk ausführen kann. Ein Programm, das an einem Knoten ausführt, kann entfernte Verfahrensaufrufe zu Verfahren oder Programmen an anderen Knoten durchführen. In diesem Fall muß etwas zum Definieren einer Lizenz vorgesehen sein, die zuläßt, daß ein Programm eher auf eine verteilte Weise ausgeführt wird, als separat auf einer einzelnen CPU; kurz zum Gewähren einer Lizenz für eine Ausführung an allen Knoten eines Netzwerks.
Bei einer großen Organisation, wie beispielsweise einer Firma oder einer Behörde mit verschiedenen Abteilungen bzw. Geschäftszweigen und Fachgruppen, die geographisch verstreut sind, ist es schwierig, eine Software-Lizenzpolice zu verwalten und durchzusetzen bzw. geltend zu machen, und ebenso ist es wahrscheinlich, daß es kostenaufwendiger ist, wenn einzelne Lizenzen durch die Einheiten der Organisation verhandelt, gewährt und verwaltet werden. Eine bevorzugte Anordnung würde darin bestehen, eine einzige Lizenz vom Softwarehersteller zu erhalten und dann diese Lizenz in lokal verwaltete Teile durch Delegierung aufzuteilen. Die durch eine Netzwerkkommunikation verursachten Verzögerungen können so minimiert werden, und auch den Fachgruppen oder Abteilungen auferlegte budgetmäßige Beschränkungen. Neben dieser Aufgabe einer Delegation kann die Lizenz- Managementeinrichtung am besten auf einem Netzwerk betrieben werden, wo das Lizensieren von Produkten, die an allen Knoten des Netzwerks laufen, zentral verwaltet werden kann. Ein Netzwerk besteht jedoch nicht notwendigerweise für eine Anwendung der Merkmale der Erfindung, da das Lizenz-Management an einer einzelnen Plattform implementiert werden kann.
Softwareprodukte werden in wachsendem Maß in spezifische Funktionen aufgeteilt, und eine getrennte Verteilung der Funktionen kann ungebührlich teuer sein. Beispielsweise kann ein Arbeitsblattprogramm getrennte Module für eine hochentwickelte Farbgraphik, zum Zugreifen auf eine Datenbank, zum Drucken oder Anzeigen einer erweiterten Liste von Schriftsätzen, etc. haben. Kunden des grundsätzlichen Arbeitsblattprodukts können einige, keine oder alle dieser hinzugefügten Merkmale haben wollen. Jedoch wäre es vorteilhaft, die gesamte Kombination als ein Paket zu verteilen, dann zuzulassen, daß der Kunde die Merkmale in verschiedenen Kombinationen oder unter unterschiedlichen Termen getrennt lizensiert. Der Kunde kann eine gesamte Abteilung der Firma haben, die das Arbeitsblatt jeden Tag anwenden muß, aber nur einige Leute, die die Graphik an einigen wenigen Tagen eines Monats anwenden müssen. Es ist daher vorteilhaft, eher Alternativen für ein variiertes Lizensieren von Teilen oder Merkmalen von Softwarepaketen vorzusehen, als eine feste Police für das gesamte Paket.
Ein weiteres Beispiel einer Verteilung von Produkten in ihrer Gesamtheit, aber eines Lizensierens in Teilen, wäre dasjenige eines Ausgebens von CD-ROMs zu einem Kunden, die die Gesamtheit der Software enthalten, die für ein System verfügbar ist, und eines darauffolgenden Lizensierens von nur denjenigen Teilen, die der Kunde benötigt oder wünscht, um Gebühren für Anwendungsrechte zu zahlen. Natürlich muß das Produkt nicht nur Anwenderprogramme, Betriebssysteme oder ein herkömmlicher ausführbarer Code sein, sondern könnte statt dessen auch statische Objekte enthalten, wie beispielsweise Druckerschriftsätze oder Graphikbilder, oder sogar Musik oder andere Klangeffekte.
Wie es unten erklärt wird, sind im System gemäß einem Merkmal der Erfindung aufrufende Zugriffsberechtigungen und Aufrufer-Zugriffsberechtigungen vorgesehen, um eine technologische Unterstützung für eine Anzahl von Geschäftspraktiken zur Verfügung zu stellen und technische Probleme zu lösen, die die Anwendung dessen erfordern, was "transitives Lizensieren" genannt wird. "Transitives Lizensieren" bedeutet, daß das Recht zum Anwenden eines Produkts oder eines Merkmals ein Recht zum Anwenden eines oder mehrerer anderer Produkte oder Merkmale impliziert. Transitive Lizenzen sind darin ähnlich wie Gruppenlizenzen, daß beide Typen von Lizenzen aus einem einzigen Instrument bestehen, das Anwendungsrechte für eine Vielzahl von Produkten zur Verfügung stellt. Jedoch unterscheiden sich transitive Lizenzen von Gruppenlizenzen darin, daß sie die gewährten Rechte durch ein Spezifizieren beschränken, daß die lizensierten Produkte nur zusammen und durch ein weiteres Spezifizieren einer oder mehrerer erlaubter Zwischenprodukt-Aufruf/Aufrufer-Beziehungen angewendet werden können. Einige Beispiele können zum Klären der Anwendung und der Natur einer transitiven Lizenz hilfreich sein: die zu erklärenden Beispiele sind (1) zwei zusammen verkaufte Produkte, (2) ein Weggeben, das aus engen Auswahlen von Lizensierungsalternativen resultiert, (3) ein Klientenlizensierungsverfahren in einer Klienten/Server- Umgebung, (4) Einfluß eines modularen Entwurfs und (5) der Einfluß eines verteilten Entwurfs.
Ein Softwareverkäufer könnte zwei Produkte zum Verkauf haben: das erste ist ein Mail-System und das zweite ist ein LEXISTM-artiges inhaltsbasierendes Textauslesesystem. Jedes dieser Produkte könnte mit 500 $ bewertet sein, wenn sie ge trennt gekauft werden. Einige Kunden würden durch Kaufen der Rechte zum Anwenden nur eines dieser Produkte zufriedengestellt sein. Andere könnten finden, daß sie eine Anwendung von beiden rechtfertigen können. Zum Erhöhen der Wahrscheinlichkeit, daß Kunden in der Tat beide Produkte kaufen, wäre es nicht überraschend, wenn der Softwareverkäufer seinen potentiellen Kunden einen Mengenrabatt anbieten würde, indem er die zwei Produkte für einen Kombinationspreis von 800 $ anbietet. Die Kunden, die einen Vorteil aus diesem Kombinationsangebot ziehen würden, würden finden, daß sie zwei Produkte erhalten hätten, von welchen jedes unabhängig vom anderen bis zu seiner vollen Kapazität ausgenutzt werden könnte. Somit könnten diese Kunden das inhaltsbasierende Auslesesystem zum Speichern und Auslesen von Nicht-Maildokumenten anwenden. Jedoch kann der Verkäufer von Zeit zu Zeit entdecken, daß besonders starke Anwender von Mail wünschen, das inhaltsbasierende Auslesesystem nur zum Vergrößern der Dateigabekapazitäten anwenden zu können, die durch das standardmäßige Mailangebot zur Verfügung gestellt sind. Es ist wahrscheinlich, daß viele dieser potentiellen Kunden fühlen würden, daß 800 $ einfach zu viel zum Zahlen für eine erweiterte Mail-Kapazität ist. Der Verkäufer könnte dann erwägen, diesen Kunden eine Lizenz anzubieten, die Mailanwendern das Recht zum Verwenden des inhaltsbasierenden Auslesesystems nur dann gewährt, wenn sie Mail anwenden, und die Anwendung eines inhaltsbasierenden Auslesens mit irgendeiner anderen Anwendung verhindert, die auf dem Kundensystem verfügbar sein könnte. Dieser Typ von Lizenz wird unten "transitive Lizenz" genannt und sie könnte für 600 $ verkauft werden.
Ein weiteres Beispiel ist ein Bezugs-Datenbankprodukt (wie beispielsweise dasjenige, das RdbTM genannt wird), das zur Anwendung auf einem bestimmten Betriebssystem, z. B. VMS, entwickelt ist. Dieses Bezugs-Datenbankprodukt hat zwei Komponenten: (1) eine Anwenderschnittstelle, die beim Entwickeln neuer Datenbanken angewendet wird, und (2) ein "Laufzeit"-System, das die Anwendung zuvor entwickelter Datenbanken unterstützt. Die Entwickler des Datenbankprodukts könnten ein klein wenig Anstrengung dafür anwenden, zu versuchen, andere Produkte zu bekommen, die durch den Verkäufer des Datenbankprodukts hergestellt werden, um sie als Datenbank anzuwenden, anstatt jene anderen Produkte ihre eigenen produktspezifischen Datenbanken bilden zu lassen. Unglücklicherweise können die Entwickler des anderen Produkts beklagen, daß die Kosten einer Laufzeit-Lizenz für das Datenprodukt dann, wenn sie zu den Kosten von Lizenzen für ihre Produkte addiert werden, ihre Produkte unvermeidbar nicht konkurrenzfähig machen würden. Somit würde ein Mechanismus benötigt, der zulassen würde, daß eines oder ein anderes der Produkte des Verkäufers das Laufzeit-System für das Bezugs-Datenbankprodukt auf eine "private" Weise angewendet, während er Produkten anderer Verkäufer keinen nichtlizensierten Zugriff zuteilt. Vor dieser Erfindung existierte kein derartiger Mechanismus. Somit könnte der Verkäufer gezwungen werden, das Recht zum Anwenden seines Laufzeit-Systems für das Datenprodukt mit seiner eigenen Betriebssystem-Lizenz zu verkaufen. Es ist klar, daß es diese kombinierte Lizenz für die Produkte des Verkäufers möglich machen würden, sein Datenbankprodukt ohne Erhöhen ihrer Preise anzuwenden; jedoch würde es auch für irgendwelche Kunden und dritte Parteien möglich machen, das Datenbankprodukt ohne Zahlen zusätzlicher Lizenzgebühren anzuwenden. Jedoch könnte der Verkäufer bei Verfügbarkeit des Systems der Erfindung transitive Lizenzen für die Laufzeit-Komponente seines Datenbankprodukts für alle Produkte des Verkäufers gewährt haben. Im wesentlichen würde von diesen Lizenzen gesagt, daß die Datenbank-Laufzeit ohne eine zusätzliche Lizenzgebühr angewendet werden könnte, wenn, und nur wenn, sie in Zusammenhang mit irgendeinem anderen der Produkte des Verkäufers angewendet würde. Ein Kunde, der wünscht, eine neue Bezugs-Datenbankanwendung aufzubauen oder eine Anwendung einer dritten Partei anzuwenden, die auf dem Datenbankprodukt des Verkäufers beruht, würde dem Verkäufer für seine Datenbank-Laufzeitlizenz zahlen müssen.
Ein vorgeschlagenes Klienten/Server-Lizensierungsverfahren zeigt noch ein weiteres Beispiel eines Problems, das durch ein transitives Lizensieren gelöst werden könnte. Typischerweise wird ein Klient nur durch einen Anwender gleichzeitig angewendet, während ein Server eine beliebige Anzahl von Klienten in Abhängigkeit von der Ebene einer Klientenaktivität und der Kapazität der Maschine, die den Server unterstützt, unterstützen kann. Während herkömmlicherweise Server/Klientenanwendungen gemäß der Anzahl von Klienten lizensiert worden sind, die ein Server potentiell unterstützen könnte, kann dies nicht das geeignetste Verfahren zum Lizensieren sein, wenn die durch die Erfindung geschaffenen Alternativen betrachtet werden. Das Geschäftsmodell für das vorgeschlagene Klienten/Server- Verfahren erfordert, daß jeder Klient individuell lizensiert wird, und kein explizites Lizensieren von Servern ist erforderlich, um lizensierte Klienten richtig zu unterstützen. Ein solches Lizensierungsschema macht es möglich, Kunden nur für die spezifische Anzahl von Klienten zu belasten, die sie kaufen. Zusätzlich bedeutet es, daß ein einzelner Klient mehr als einen Server anwenden kann, ohne die Gesamtkosten für das System zu erhöhen. Die Lösung für dieses Problem einer transitiven Lizensierung würde darin bestehen, einen Mechanismus zu schaffen, der zulassen würde, daß die Klienten Lizenzeinheitenzuteilungen erhalten und dann eine "Bestätigung bzw. einen Beweis" jener Zuteilung zu irgendwelchen Servern übergeben, die sie möglicherweise anzuwenden wünschen. Server würden dann irgendwelche Klienten unterstützen, deren Bestätigungen derart verifiziert werden könnten, daß sie gültig sind. Andererseits würde der Server dann, wenn ein Klient, der eine Bestätigung einer Zuteilung nicht empfangen hätte, versuchte, einen Server anzuwenden, eine Lizenzzuteilung für jene Klientensession bzw. Klientensitzung vor einem Durchführen irgendwelcher Dienste erhalten. Eine solche Lösung ist bisher nicht verfügbar gewesen.
Da die Komplexität und die Größe der Softwaresysteme, die Kunden zur Verfügung gestellt werden, größer wird, wird gefunden, daß die aktuelle Lösung, die Kunden zur Verfügung gestellt wird, nicht mehr ein Einzelprodukt ist. Vielmehr werden Kunden nunmehr öfters Lösungen angeboten, die durch Integrieren einer steigenden Anzahl von Komponenten oder Produkten aufgebaut sind, von welchen jedes oft alleinstehen kann oder ein Teil einer großen Anzahl anderer Lösungen sein kann. Tatsächlich kann eine Produktstrategie fast ausschließlich auf dem Entwickeln und Verkaufen eines breiten Bereichs spezialisierter Komponenten durch den Verkäufer beruhen, die nur dann vollständig ausgenutzt werden können, wenn sie mit anderen Komponenten in ein größeres System kombiniert sind. Solche Komponenten enthalten das oben angegebene Bezugsdatenbank-Laufzeitsystem, einen Mail-Transportmechanismus, Hyperinformationen-Datenbanken, Dokumentenformat-Umwandlungsdienste, Zeitdienste, etc. Weil diese Komponenten nicht wegen ihrer eigenen Vorteile verkauft werden, sondern eher wegen ihrer Fähigkeit, einen Beitrag zu irgendeinem größeren System zu leisten, ist es unwahrscheinlich, daß irgendein Kunde den vollen abstrakten ökonomischen Wert irgendeiner der Komponenten empfangen wird, wenn sie einmal in ein System integriert sind. Gleichermaßen kann beobachtet werden, daß der Wert irgendeiner Komponente, die einmal in ein größeres System integriert ist, von System zu System stark variiert. So kann gefunden werden, daß ein Post-Transportmechanismus einen großen Teil zu einem System beiträgt, dessen primäre Ausrichtung ein Postversand ist, er jedoch proportional weniger zum Wert eines Systems beitragen wird, das eine breitere Amtsautomatisierungskapazität zur Verfügung stellt. Als Ergebnis dieser Beobachtungen wird der Job des Geschäftsanalytikers, der versucht, den "richtigen" Marktpreis für jede Komponente, die für sich selbst steht, zu finden, komplexer. In Wirklichkeit kann der Preis oder Wert der Komponenten nur dann bestimmt wer den, wenn man den Beitrag jener Komponente zum Gesamtsystem oder zur Lösung, in welcher sie integriert ist, betrachtet. Ein Versuchen, die Komponenten zu Preisen basierend auf ihren abstrakten unabhängigen Werten zu verkaufen, wird einfach in überteuerten Systemen resultieren.
Arten einer transitiven Lizenz sind insbesondere zum Behandeln einer Preisgabe von modularen Komponenten geeignet, da Komponentenpreise in bezug zu den anderen Komponenten oder Systemen, die sie unterstützen, klar definiert werden können. Somit kann ein Verkäufer einen Preis von 100 $ für das Recht zum Anwenden eines Mail-Transportsystems in Zusammenhang mit einem Produkt belasten, jedoch 200 $ für die Anwendung desselben Mail-Transportsystems belasten, wenn es durch ein weiteres Produkt angewendet wird.
Zusätzlich zu den "geschäftlichen" Gründen für den Wunsch, ein transitives Lizensieren zu unterstützen, gibt es auch einen sehr guten technischen Grund, der aus der anwachsenden Tendenz entsteht, daß Entwickler "verteilte Produkte" bilden, sowie dem Trend in Richtung zu Anwendungsentwicklungen, die entweder eng oder lose gekoppelte Multiprozessorsysteme ausnutzen; die Verfügbarkeit und die anwachsende Anwendung entfernter Verfahrensaufrufe hat zu dieser Tendenz beigetragen. Es kann gesehen werden, daß dieses technische Problem entsteht, wenn man ein Produkt betrachtet, das eine Anzahl von Komponenten hat, von denen jede in einem unterschiedlichen Prozeßraum und potentiell auf einem unterschiedlichen Computersystem laufen kann. Somit könnte es ein Mailsystem geben, dessen Anwenderschnittstelle auf einer Maschine läuft, sein "Datei-Kabinett" durch eine zweite Maschine unterstützt wird und sein Mail- bzw. Post-Transportsystem auf noch einer dritten Maschine läuft. Die einfache Frage, die entsteht, ist folgende: "Welche der drei Komponenten sollte auf Lizenzen prüfen?" Es ist klar, daß sichergestellt werden muß, daß keine einzige Komponente angewendet werden kann, wenn keine gültige Lizenz vorhanden ist. Somit wird die Antwort auf die Frage wahrscheinlich sein, daß alle drei Komponenten auf Lizenzen prüfen sollten. Jedoch wird dann folgende Frage präsentiert: "Wo sind die Lizenzen anzuordnen?" Dies kann komplexer werden.
In ansteigendem Maße werden die verteilten Systeme, die aufgebaut werden, derart entwickelt, daß es schwierig ist, vorherzusagen, auf welcher genauen Maschine irgendeine bestimmte Komponente laufen wird. Idealerweise wird angenommen, daß Netzwerke das Anordnen von Funktionen automatisch optimieren, so daß die Maschine mit dem am meisten verfügbaren Betriebsmittel immer diejenige ist, die irgendeine bestimmte Anfrage bedient. Dieses dynamische Verfahren zum Konfigurieren der Verteilung von Funktions-Servern auf dem Netzwerk macht es sehr schwierig für einen System- oder Netzwerkmanager, vorherzusagen, welche Maschinen irgendwelche bestimmten Funktionen laufen lassen werden, und somit für ihn sehr schwierig, zu entscheiden, auf welchen Maschinen Softwarelizenzen geladen werden sollten.
Selbst wenn ein Systemmanager vorhersagen könnte, welche Maschinen die verschiedenen Anwendungskomponenten laufen lassen würden, und somit, wo die Lizenzeinheiten geladen werden sollten, wäre die Situation noch immer weniger als ideal. Das Problem entsteht aus der Tatsache, daß jede der Komponenten der Anwendung unabhängig Anfragen nach Lizenzeinheitenzuteilungen durchführen würde. Dieses Verhalten wird in einem schwierigen Problem für jemanden resultieren, der versucht, zu entscheiden, wieviele Lizenzeinheiten zum Unterstützen irgendeines Produkts erforderlich sind. Beim gegebenen Mail-Beispiel würde das Problem dann nicht existieren, wenn angenommen würde, daß für alle drei Komponenten (d. h. Anwenderschnittstelle, Datei-Kabinett und Transportsystem) durch den Aufbau des Mailsystems erforderlich wäre, daß sie gleichzeitig angewendet werden. Wenn dies der Fall wäre, könnte einfach angenommen werden, daß ein Unterstützen einer einzigen Aktivierung des Mailsystems drei Einheiten erfordern würde. Jedoch wird bei einem realen Mailsystem unvermeidlich entdeckt, daß viele Anwender nur genau die Anwenderschnittstellen- und Datei-Kabinett- Komponenten des Systems gleichzeitig anwenden werden. Somit werden einige nicht angewendete Einheiten zur Verfügung stehen, die zum Autorisieren zusätzlicher Anwender angewendet werden könnten. Es könnte sein, daß diese Situation nicht das ist, was durch den Softwareverkäufer gewünscht wird.
Das Problem eines Bereitstellens einer Lizenzunterstützung für Mehrkomponentenprodukte, die dynamisch konfiguriert sind, könnte durch Ansehen jeder der Produktkomponenten als unterschiedliches lizensierbares Produkt und durch Behandeln des Problems als eines einer transitiven Lizensierung gelöst werden, aber ein Mechanismus, um dies zu erreichen, ist nicht verfügbar gewesen. Im wesentlichen würde ein einziges Lizenzdokument erzeugt werden, das behauptete, daß dann, wenn irgendeine der Komponenten eine Lizenz zum Laufen erfolgreich erhalten hätte, sie diese Gewährung anwenden könnte, um ihr das Recht zum Nutzen bzw. Anwenden der anderen Komponenten zu geben. Somit könnte der Anwender beim obigen Beispiel das Mailsystem durch Aufrufen seiner Anwenderschnittstelle starten. Dieser Anwenderschnittstellencode würde dann die Lizenz- Managementeinrichtung nach einer Lizenzzuteilung fragen, und wenn er einmal jene Zuteilung empfangen hat, würde er eine Bestätigung einer Zuteilung zu den anderen Mailkomponenten, die er anwendet, weiterleiten. Jede der anderen Komponenten würde vor dem Durchführen irgendeines Dienstes anfragen, daß das Lizenz-Managementsystem bestätigt, daß der "Beweis" gültig ist; jedoch würde keine der anderen Komponenten tatsächlich fordern, daß spezifische Zuteilungen zu ihnen gemacht werden. Auf diese Weise kann die Komplexität von Lizensierungs- und Management-Netzwerken verteilter Anwendungen signifikant reduziert werden.
Gemäß einem Ausführungsbeispiel der Erfindung wird ein Lizenz- Managementsystem zum Erklären einer Softwareproduktanwendung in einem Computersystem angewendet. Das System angewendet ein Lizenz- Managementverfahren, das eine Managementpolice mit einer Vielfalt gleichzeitig verfügbarer alternativer Stile und Kontext aufbaut. Ein Lizenzserver verwaltet die Lizenz, und jedes lizensierte Produkt führt auf ein Hochfahren hin einen Aufruf zum Lizenzserver durch, um zu prüfen, ob eine Anwendung zugelassen ist, und zwar auf eine Weise, die gleich derjenigen des Patents 4,937,863 ist. Der Lizenzserver unterhält eine Speicherung der Lizenzen, die Produktanwendungs- Zugriffsberechtigungen genannt werden, die er verwaltet. Auf ein Empfangen eines Aufrufs von einem Anwender hin prüft der Lizenzserver die Produktanwendungs- Zugriffsberechtigung, um zu bestimmen, ob die angefragte bestimmte Anwendung zugelassen ist, und dann, wenn es so ist, bringt er eine Gewährung zum anfragenden Anwenderknoten zurück. Der Lizenzserver unterhält eine Datenbank von Produktanwendungs-Zugriffsberechtigungen für die lizensierten Produkte und greift auf diese Datenbank zum Updaten zu, und dann, wenn eine Anfrage von einem Anwender empfangen wird. Während das Lizenz-Managementsystem vielleicht von höchster Nützlichkeit auf einem verteilten Computersystem ist, das ein lokales Netzwerk anwendet, ist es auch in einem alleinstehenden oder einem Cluster-Typ eines Systems betreibbar. In einem verteilten System führt ein Lizenzserver an einem Serverknoten aus, und die Produkte, für die Lizenzen verwaltet werden, sind auf Klientenknoten. Jedoch können die Lizenz-Managementfunktionen und die lizensierten Produkte bei einigen Ausführungsbeispielen auf demselben Prozessor ausführen.
Die Produktanwendungs-Zugriffsberechtigung ist strukturiert, um eine Lizenz- Managementpolice zu definieren, die eine Vielfalt von Lizenzalternativen zuläßt, und zwar durch Komponenten, die "Stil", "Kontext", "Dauer" und "Anwendungsanforderungs-Bestimmungsverfahren" genannt werden. Der Stil kann zuteilend oder verbrauchend sein. Ein zuteilender Stil bedeutet, daß die Einheiten der Lizenz temporär einem Anwender zugeteilt werden können, wenn eine Anfrage empfangen wird, und dann zum Pool zurückgebracht werden, wenn der Anwender fertig ist, so daß die Einheiten dann erneut angewendet werden können, wenn ein weiterer Anwender eine Anfrage durchführt. Ein verbrauchender Stil bedeutet, daß die Einheiten von einem verfügbaren Pool abgeleitet werden, wenn ein Anwenderknoten eine gültige Anfrage macht, und "verbraucht", und nicht für eine erneute Anwendung zurückgebracht werden. Der Kontextwert definiert den Kontext, in dem die Anwendung zuzulassen ist, wie beispielsweise auf einem bestimmten Netzwerk, durch einen bestimmten Typ von CPU, durch einen bestimmten Anwendernamen, durch einen bestimmten Prozeß, etc. Der Dauerwert (in Verbindung mit der Stilkomponente angewendet) betrifft die Zeit, zu der die Lizenzeinheiten vom verfügbaren Pool von Einheiten abzuleiten sind, ob es die Zeit einer Anfrage ist, nachdem eine Anwendung beendet ist, etc. Ein Anwendungserfordernis- Bestimmungsverfahren kann spezifiziert sein, um Informationen zu definieren oder bereitzustellen, die die Anzahl von Lizenzeinheiten betreffen, die in Antwort auf eine Lizenzanfrage von einem Anwenderknoten geladen werden; beispielsweise können einige CPU-Plattformen mit einer größeren Anzahl von Lizenzeinheiten als andere geladen werden. Eine Tabelle von Anwendungserfordernissen kann unterhalten werden, und das Bestimmungsverfahren kann spezifizieren, wie beispielsweise auf die Tabelle zuzugreifen ist. Wichtige ist dabei, daß der Anwenderknoten (und somit das Softwareprodukt) nur eine Anfrage durchführen kann, die sich selbst durch einen Anwender, die Plattform, den Prozeß, etc. identifiziert, und die Lizenz-Managementeinrichtung berechnet, ob die Lizenz gewährt werden kann oder nicht (d. h. Einheiten sind zur Zuteilung verfügbar), ohne daß der Anwenderknoten auf irgendwelche der Lizenzdaten oder die Berechnung zugreifen muß. Es gibt eine zentrale Einrichtung, nämlich den Lizenzserver, die die Lizenzdokumente speichert und die auf eine Anfrage hin den lizensierten Produkten berichtet, ob sie unter den Lizenztermen arbeiten können.
Ein wichtiges Merkmal eines Ausführungsbeispiels besteht darin, daß die Lizenzverwaltung zu einem Unterabschnitt der Organisation delegiert werden kann, und zwar durch Erzeugen einer weiteren Lizenz-Managementeinrichtung, die die Haupteinrichtung dupliziert. Beispielsweise können einige der in der Produktanwendungs-Zugriffsberechtigung gewährten Einheiten zu einem anderen Server delegiert werden, wo die Anwenderknoten, die durch diesen Server bedient werden, Anfragen durchführen und Gewährungen empfangen.
Die Lizenz-Managementeinrichtung kann nicht eine Lizenz selbst erzeugen, sondern muß statt dessen ein Lizenzdokument (eine Produktanwendungs- Zugriffsberechtigung) von einem Herausgeber von Lizenzen erhalten. Als Teil des gesamten Lizenz-Managementsystems der Erfindung ist ein Lizenzdokumentenerzeuger vorgesehen, der die Produktanwendungs-Zugriffsberechtigungen unter einer Zugriffsberechtigung des Besitzers der Software erzeugt, wie es mit Kunden verhandelt wird. Somit gibt es drei unterschiedliche Rechte in der gesamten Lizenz-Managementeinrichtung der Erfindung: (1) das Recht zum Ausgeben von Lizenzen, (2) das Recht zum Managen von Lizenzen, und (3) das Recht zum Anwenden der lizensierten Produkte. Jedes davon wendet das Lizenzdokument nur auf vorgeschriebene Weise an. Der Lizenzherausgeber kann ein Lizenzdokument erzeugen. Der Lizenz-Manager (oder der Lizenzserver, wie er hierin genannt wird) kann Produkten das Recht zum Verwenden unter der Lizenz gewähren, und kann Teile der lizensierten Einheiten für ein Management durch einen anderen Server delegieren, wie es durch das Lizenzdokument definiert ist; die Weise zum Gewähren von Rechten für Produkte erfolgt durch Antworten auf bestimmte definierte Aufrufe von den Produkten. Darüber hinaus können die lizensierten Produkte bestimmte Aufrufe zum Lizenzserver durchführen, um Gewährungen von Rechten zu erhalten, und zwar basierend auf dem Lizenzdokument, einer Untersuchung oder einem Bericht, können aber normalerweise nicht auf das Dokument selbst zugreifen.
Wie es oben erklärt ist, ist ein transitives Lizensieren ein wichtiges Merkmal eines Ausführungsbeispiels. Dies ist das Vorsehen eines Mechanismus für einen Anwenderknoten zum Bekommen einer Erlaubnis zum Anwenden eines weiteren Softwareprodukts, das auf einem anderen Anwenderknoten angeordnet ist; dies wird aufrufende Zugriffsberechtigung und Aufrufer-Zugriffsberechtigung genannt, und zwar unter Anwendung einer "Aufrufkarte", und dies sind Beispiele der optionalen Merkmale, die durch die Produktanwendungs-Zugriffsberechtigung spezifisch zugelassen werden müssen. Ein Anwenderknoten muß eine Erlaubnis erhalten, um einen Verfahrensaufruf zum Anwenden eines Programms an einem anderen Knoten durchzuführen; diese Erlaubnis wird durch eine Anfrage zum Lizenzserver wie zuvor erhalten, und die Erlaubnis nimmt die Form einer Aufrufkarte an. Wenn die Aufrufkarte durch einen zweiten Knoten empfangen wird (d. h. wenn der Verfahrensaufruf gemacht wird), wird eine Anfrage durch den zweiten Knoten zum Lizenzserver gemacht, um (über die Produktanwendungs-Zugriffsberechtigung) zu verifizieren, daß die Aufrufkarte gültig ist, und eine Gewährung wird zum Anwenderknoten gesendet, wenn sie zugelassen wird. Auf diese Weise können alle Knoten ein Programm durch entfernte Aufrufe anwenden, aber nur einer verbraucht Lizenzeinheiten.
Ein weiteres wichtiges Merkmal eines Ausführungsbeispiels ist eine Managementschnittstelle, die zuläßt, daß ein Lizenz-Manager die Lizenzpolice-Komponenten eines durch einen Lizenzserver bei ihm unterhaltenen Lizenzdokument in seiner Datenbank modifiziert. Normalerweise kann der Lizenz-Manager nur Modifikationen durchführen, die die Lizenzpolice-Komponenten derart beschränkt, daß sie beschränkter als ursprünglich gewährt sind. Natürlich wird die Managementschnittstelle dazu angewendet, Delegationen und Zuteilungen durchzuführen, wenn diese autorisiert sind.
Das Lizenzdokumenten-Austauschformat ist ein wichtiges Merkmal, und zwar darin, daß es zuläßt, daß das Lizenz-Managementsystem mit einer breiten Vielfalt von Softwareprodukten von unterschiedlichen Verkäufern angewendet wird, solange alle dem definierten Format folgen. Das Format wendet Datenstrukturen an, die durch internationale Standards definiert sind.
Eine wichtige Funktion ist die Filterfunktion, die bei der Managementschnittstelle angewendet wird, und auch bei der Klientenschnittstelle, zum Auswählen unter Elementen in den Datenstrukturen.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Die neuen Merkmale, von denen geglaubt wird, daß sie charakteristisch für die Erfindung sind, sind in den beigefügten Ansprüchen gezeigt. Jedoch wird die Erfindung selbst, sowie andere Merkmale und Vorteile von ihr, am besten durch Bezugnahme auf die detaillierte Beschreibung spezifischer Ausführungsbeispiele verstanden, die folgt, wenn sie in Zusammenhang mit den beigefügten Zeichnungen gelesen wird, wobei:
Fig. 1 ein Diagramm eines verteilten Computersystems in Blockform ist, das zum Implementieren der Lizenz-Managementoperationen gemäß einem Ausführungsbeispiel der Erfindung angewendet werden kann;
Fig. 2 ein Diagramm des Inhalts eines Lizenzdokuments oder einer "Produktanwendung-Zugriffsberechtigung" ist, die durch den Lizenzdokumenten-Generator erzeugt wird und durch den Lizenzserver im System der Fig. 1 gespeichert wird;
Fig. 3 ein Diagramm der Alternativen für Lizenz-Stil, -Kontext und -Dauer ist, die die Lizenz-Managementpolice bilden, die im System der Fig. 1 implementiert ist, und zwar gemäß einem Ausführungsbeispiel der Erfindung;
Fig. 4 ein Diagramm eines Beispiels eines Bruchteils einer Lizenzanwendungs-Anforderungstabelle (LURT) ist, die im System der Fig. 1 angewendet wird, und zwar gemäß einem Ausführungsbeispiel der Erfindung;
Fig. 5 ein logisches Ablaufdiagramm eines Programms ist, das durch einen Anwenderknoten (Klienten) ausgeführt wird, im System der Fig. 1, und zwar gemäß einem Ausführungsbeispiel der Erfindung;
Fig. 6 ein logisches Ablaufdiagramm eines Programms ist, das durch einen Lizenzserver bei einem System der Fig. 1 gemäß einem Ausführungsbeispiel der Erfindung ausgeführt wird; und
Fig. 7 ein Diagramm der Aufrufe und Zurückbringungen bzw. Erwiderungen ist, die bei einem Beispiel einer Anwendung von Aufrufkarten im System der Fig. 1 durchgeführt werden.
Fig. 8 ein Diagramm eines LDIF-Dokumentenidentifizierers gemäß einem Standardformat ist;
Fig. 9 ein Syntaxdiagramm eines LDIF-Dokuments ist;
Fig. 10 ein Diagramm einer LDIF-Dokumentenstruktur ist;
Fig. 11, 13, 15, 17, 18, 19, 21-28 und 31-43 Syntaxdiagramme für Elemente verschiedener der LDIF-Datenstrukturen sind;
Fig. 16 ein Diagramm einer Lizenzdatenstruktur ist;
Fig. 12, 14 und 20 Beispiele von Beschreibungen von Datenelementen unter Anwendung eines Standard-Zahlensystems sind;
Fig. 29 und 30 Beispiele von Kontextschablonen sind, die im Lizenz- Managementsystem angewendet werden;
Fig. 44 und 45 Tabellen von Attributen sind, die für einen Filter- und einen Filterelemententyp spezifisch sind; und
Fig. 46 ein Zahlensystem in einem Standardformat für ein Beispiel eines Filters ist.

DETAILLIERTE BESCHREIBUNG SPEZIFISCHER AUSFÜHRUNGSBEISPIELE

Nimmt man Bezug auf Fig. 1 ist eine Lizenz-Managementeinrichtung gemäß einem Ausführungsbeispiel der Erfindung um einen Lizenzserver 10 zentriert, der typischerweise eine CPU enthält, die im Hauptbüro eines Kunden angeordnet ist und ein Lizenz-Managementprogramm 11 ausführt, wie es beschrieben wird, und zwar unter einem Betriebssystem 12. Der Lizenzserver 10 kommuniziert mit einer Anzahl von Delegierten 13, die gleichermaßen CPUs in Abteilungen oder Fachgruppen der Firma oder Organisation enthalten, die ebenso ein Lizenz-Managementprogramm 14 unter einem Betriebssystem 15 ausführen. Das Lizenz-Managementprogramm 14 ist dasselbe wie das Programm 11, das auf dem Hauptserver 10 ausführt; der einzige Unterschied in bezug auf die Funktionen des Servers 10 und der Server 13 besteht darin, daß die letzteren eine delegierte Untergruppe der Lizenzeinheiten haben, die dem Server 10 gewährt sind, wie es beschrieben wird. Die CPUs 13 sind wiederum Server für eine Anzahl von Anwendern 16, die CPU-Knoten sind, wo die lizensierten Programme 17 tatsächlich ausgeführt werden. Die Programme 17, die auf den Anwender-CPUs 16 ausführen, sind Anwenderprogramme (oder Betriebssysteme, etc.), die zu ihnen hinzugefügt Einheiten 18 und 19 gemäß der Erfindung haben, die ihnen erlauben, eine Untersuchung in bezug auf ihren Server 13 (oder 10) vor einem Ausführen durchzuführen und nach einer Ausführung zurückzuberichten, und zwar bei einem Ausführungsbeispiel unter Anwendung eines Klienten-Kontrollabschnitts 19 auf die Weise von entfernten Verfahrensaufrufen. Ein Anwenderknoten 16 kann viele unterschiedliche Programme 17 haben, die ausgeführt werden können, und die verschiedenen Anwenderknoten 16 würden normalerweise jeweils eine Gruppe von Programmen 17 haben, die unterschiedlich von den anderen Anwenderknoten sind, von denen alle durch das. Lizenz- Managementprogramm 14 oder 11 verwaltet werden würden. Die Terme "Programm" und "lizensiertes Produkt" werden in bezug auf das Element 17 angewendet, aber es ist zu verstehen, daß die Produkte, die verwaltet werden, Segmente von Programmen oder Funktionen oder Merkmalen sein können, die durch ein anderes Programm aufgerufen werden, oder sogar lediglich Daten (wie beispielsweise Druckerschriftsätze) sowie vollständige alleinstehende Anwenderprogramme. Der Lizenzserver 10 kommuniziert mit den Delegiertenservern 13 durch ein Netzwerk 21, wie es bei großen Organisationen normal ist, und die Delegiertenserver 13 kommunizieren jeweils mit ihrem Anwenderknoten 16 durch Netzwerke 22; diese Netzwerke können vom Typ eines Ethernets, eines Tokenrings, von FDDI oder ähnlichem sein, oder alternativ dazu können die Anwenderknoten 16 lediglich ein Cluster von Endgeräten auf einem Mehrfachanwenderersystem sein, wobei der Delegierte eine Host-CPU ist. Der besondere Hardwareaufbau der Anwenderknoten, der Serverknoten, der Kommunikationsnetzwerke, etc. und der Betriebssysteme 12 oder 15 sind in bezug auf die Nützlichkeit der Merkmale der Erfindung nicht von Interesse, wobei der einzige wichtige Punkt ist, daß die Anwender-CPUs 16 der in Frage stehenden Softwareprodukte 17 prompt und schnell mit ihren jeweiligen Serverknoten 13 oder 10 kommunizieren können. Bei einem Ausführungsbeispiel werden entfernte Verfahrensaufrufe (RPCs) als das Kommunikationsmedium für die Schnittstellen zwischen Komponenten des Systems angewendet, die die Untersuchungen und Gewährungen behandeln, wie es beschrieben wird. Ein entfernter Verfahrensaufruf ist gleich einem lokalen Verfahrensaufruf, wird aber zu einem an einem entfernten Knoten angeordneten Verfahren mittels eines Kommunikationsnetzwerks durchgeführt.
Die Funktion der Einheit 19 ist diejenige eines Klienten-Kontrollabschnitts im Sinn eines entfernten Verfahrensaufrufs. Die Aufrufe zum Lizenzserver 10 werden durch diesen Kontrollabschnitt 19 durchgeführt, und Zurückbringungen bzw. Erwiderungen werden durch den Kontrollabschnitt 19 empfangen und zum Programm 17 weitergeleitet. Der Kontrollabschnitt 19 ist verantwortlich für ein Erhalten der Netz werkadressen anderer Knoten auf dem Netzwerk, wie beispielsweise des Servers 10. Ebenso ist der Kontrollabschnitt 19 verantwortlich für ein Bestimmen des Kontexts (wie es unten definiert ist) zum Weiterleiten zum Server 10. Die Einheit 18 funktioniert eher zum Ausführen eines "privaten" Typs einer Lizenzverfügbarkeitsbestimmung, wenn diese angewendet wird, als daß diese Aufgabe durch das Anwenderprogramm 17 durchgeführt wird, aber dann, wenn das normale Verfahren zur Bestimmung angewendet wird (unter Anwendung des Lizenzservers), wie es normalerweise der Fall ist, ist die Einheit 18 lediglich ein Code, der die Ausführung startet und Aufrufe und Zurückbringungen rückwärts und vorwärts zwischen dem Programm 17 und der Einheit 19 weiterleitet.
Der Lizenzserver 10 unterhält unter Anwendung des Lizenz- Managementprogramms 11 eine Lizenzdatendatei 23 mit einer Anzahl von Lizenzdokumenten oder Lizenzen (Produktanwendungs-Zugriffsberechtigungen), und er unterhält auch ein Protokoll 24, das ein Datensatz der Anwenderaktivität aller Anwender-CPUs 16 jedes der lizensierten Programme ist. Die Delegiertenserver 13 würden ähnliche Lizenzdatenbanken und Protokolle unterhalten. Der Lizenzserver 10 hat keine Zugriffsberechtigung zum Entstehenlassen einer Lizenz, sondern muß statt dessen eine Lizenz vom Lizenzherausgeber 25 erhalten. Der Herausgeber 25 ist wiederum eine CPU, die ein Lizenzdokumenten-Generatorprogramm 26 unter einem Betriebssystem 27 ausführt. Der Lizenzherausgeber 25 kann unter Steuerung des Herstellers 28 der Programme oder Softwareprodukte sein, die lizensiert sind, oder kann durch einen Verteiler gesteuert werden, der die Zugriffsberechtigung zum Gewähren von Lizenzen vom Hersteller oder Besitzer 28 erhalten hat.
Dieser Mechanismus läßt zu, daß das System der Erfindung die unhandliche explizite Unterstützung von Lizenztypen von unterschiedlichem Schutzumfang ablegt, wie beispielsweise die Cluster-Lizenzen, Knotenlizenzen und Prozeßlizenzen, die bei früheren Lizenz-Managementsystemen einschließlich demjenigen des Patents 4,937,863 gefunden werden. Statt eines Definierens einer beschränkten Gruppe von Schutzumfängen (Cluster, Knoten, etc.), stellt das System dieser Erfindung einen allgemeinen Mechanismus zur Verfügung, der zuläßt, daß ein effektiv unbeschränkter Bereich von Zuteilungsschutzumfängen definiert wird.
Ein transitives Lizensieren, wie es oben angegeben ist, wird durch das System der Erfindung durch (1) aufrufende Autorisierungen, die Angaben sind, die im Feld 49 der Produktandungs-Zugriffsberechtigung 35 für ein Produkt (den "Aufrufer") durchgeführt werden, um zuzulassen, daß ein Produkt ein anderes Produkt (den "Aufgerufenen") aufruft, und durch (2) Aufruf-Zugriffsberechtigungen, die Angaben sind, die im Feld 49 der Produktanwendungs-Zugriffsberechtigung für ein Produkt (den "Aufrufenden") durchgeführt werden, um zuzulassen, daß er durch ein anderes Produkt (den "Aufrufer") aufgerufen wird, unterstützt.
Wenn aufrufende Zugriffsberechtigungen oder Aufrufer-Zugriffsberechtigungen durch Produkte anzuwenden bzw. auszunutzen sind, dann müssen sie, wann immer ein Produkt ein anderes Produkt aufruft, den Aufrufenden, nämlich eine Aufrufkarte 49a, weiterleiten. Diese Aufrufkarte 49a ist eine Codierung einer Identifikation des Aufrufers sowie eine Angabe durch das Lizenz-Managementsystem, daß eine Lizenzeinheitenzuteilung zum Aufrufer durchgeführt worden ist, der die Aufrufkarte weiterleitet. Die Aufrufkarte wird dann durch den Aufrufenden zum Lizenz- Managementsystem für eine Gültigkeitserklärung weitergeleitet, und dann, wenn entweder die Produktanwendungs-Zugriffsberechtigung des Aufrufers eine geeignete Aufruf-Zugriffsberechtigung trägt oder die Produktanwendungs- Zugriffsberechtigung des Aufrufenden eine geeignete Aufrufer-Zugriffsberechtigung trägt, wird die Anwendung des Aufrufenden durch den Aufrufer ohne irgendwelche zusätzlichen Lizenzeinheitenzuteilungen zu erfordern, autorisiert.
In Fig. 7 sind die Zwischenkomponenten-Interaktionen dargestellt, die dann auftreten, wenn entweder aufrufende Zugriffsberechtigungen oder Aufrufer- Zugriffsberechtigungen angewendet werden. Diese Figur zeigt einen Lizenz- Managementserver 10, ein Aufruferprodukt 17a mit dem Namen "Produkt-1" und ein aufrufendes Produkt 17b mit dem Namen "Produkt-2". Wenn Produkt-1 zu lau fen beginnt, wird es einen Aufruf Im request allocation() zum Lizenz- Managementserver 10 durchführen, um eine Gewährungshandhabung für eine Zuteilung einer Anzahl von Einheiten der Produkt-1-Lizenz zu erhalten. Entweder sofort oder eine gewisse Zeit später, aber immer vor einem Durchführen eines Aufrufs zum Produkt-2, wird Produkt-1 Im_query_allocation() aufrufen, die früher empfangene Gewährungshandhabung weiterleiten und spezifizieren, daß es eine Aufrufkarte für das Produkt mit dem Namen "Produkt-2" wünscht. Wenn das Feld 49 der Produktanwendungs-Zugriffsberechtigung 35, die zum Erfüllen der durch die Gewährungshandhabung dargestellten Gewährung angewendet wird, eine aufrufende Zugriffsberechtigung im Feld 49 mit dem Namen "Produkt-2" trägt, wird der Lizenz-Manager eine Aufrufkarte 49a erzeugen, die die Angabe enthält, daß eine aufrufende Zugriffsberechtigung existiert, und diese Aufrufkarte zurück zum Produkt-1 führen. Wenn die aufrufende Zugriffsberechtigung nicht existiert, wird die zum Produkt-1 geführte Aufrufkarte eine Angabe in bezug auf jenen Effekt enthalten.
Wenn Produkt-1 einmal eine Aufrufkarte 49a vom Lizenz-Manager erfolgreich erhalten hat, wird es dann einen Aufruf zum Produkt-2 durchführen, was die Aufrufkarte zusammen mit irgendwelchen anderen Initialisierungsparametern, die normalerweise dann angewendet würden, wenn Produkt-2 startet, weiterleitet. Produkt-2 wird dann jene Aufrufkarte zum Lizenz-Manager als Teil von seinem Aufruf Im_request_allocation() führen, und der Lizenz-Manager wird bestimmen, ob die Aufrufkarte gültig ist. Es ist zu beachten, daß die Aufrufkarten ungültig werden, wenn der Prozeß, der die Aufrufkarte empfing, einmal einen Aufruf Im_release_allocation() macht oder anormal beendet. Wenn die Aufrufkarte günstig ist und sie anzeigt, daß eine aufrufende Zugriffsberechtigung vorhanden ist, wird der Lizenz-Manager diese Angabe verifizieren, und wenn gefunden wird, daß sie wahr ist, wird er eine Gewährungshandhabung zum Produkt-2 zurückbringen. Wenn die Aufrufkarte andererseits ein Anzeichen trägt, daß keine aufrufende Zugriffsberechtigung vorhanden ist, wird der Lizenz-Manager versuchen, eine Produktanwendungs-Zugriffsberechtigung für Produkt-2 zu finden, die eine Aufrufer- Zugriffsberechtigung mit dem Namen Produkt-1 als einen autorisierten Aufrufer enthält. Wenn die Aufrufer-Zugriffsberechtigung gefunden wird, wird eine Gewährungshandhabung zurück zum Produkt-2 geführt. Wenn nicht, wird der Lizenz- Manager die Aufrufkarte ignorieren und mit der normalen Logik Im_request_allocation() weitermachen.
Das Erfordernis, Aufrufkarten zwischen Produkten zu führen, erfordert, daß sowohl der Aufrufer als auch der Aufgerufene sich über die Tatsache "bewußt" ist, daß aufrufende Zugriffsberechtigungen und Aufrufer-Zugriffsberechtigungen angewendet werden können. Dies ist eines der wenigen Beispiele eines Erfordernisses für ein Produkt 17, um aktiv zu werden, das bei dem Lizensierungsproblem beteiligt ist, wenn das Lizensierungsmanagement der Erfindung angewendet wird. Jedoch deshalb, weil die Anwendung von aufrufenden/Aufrufer-Zugriffsberechtigungen ein sehr "ausgeklügeltes" und mächtiges Merkmal ist, wird es als akzeptabel betrachtet, diese Belastung Anwendercodierern aufzuerlegen.

MANAGEMENTSCHNITTSTELLE

Gemäß Fig. 1 enthält das Lizenz-Managementprogramm 11, das auf einem Server 10 ausführt, eine Lizenz-Managementschnittstelle 33, die funktioniert, um zuzulassen, daß ein Anwender an einer Konsole für die CPU des Servers 10 oder an einem entfernten Endgerät bestimmte notwendige Operationen implementiert. Die Managementschnittstelle 33 ist im wesentlichen das Werkzeug oder der Mechanismus, das bzw. der für den Lizenz-Manager auf der Seite des Lizenzgebers zur Verfügung steht, um (a) die verschiedenen vom Herausgeber 25 erhaltenen Lizenzen in die Datenbank 23 zu laden und sie für Anfragezuordnungsaufrufe von Anwendern verfügbar zu machen, (b) die Lizenzen von der Maschine zu entfernen, wenn sie abgelaufen sind, (c) Delegationen zu machen, wenn sie zugelassen sind, (d) Zuordnungen zu machen, (e) Reservierungen zu machen, etc. Was immer dem Lizenz-Manager erlaubt ist, das er durchführt, um die Lizenz für seine speziellen Umstände zu modifizieren, die normalerweise innerhalb der ursprünglichen Gewährung sind, tut er es durch den Mechanismus der Managementschnittstelle 33. Einige Lizenzen werden schließlich nicht modifiziert, sondern lediglich geladen. In einer Mehrfachmaschinenumgebung, wie an einem Netzwerk, gibt es beachtliche Modifikationen, wie es nötig ist, um sicherzustellen, daß die richtige Anzahl von Einheiten auf die richtigen Maschinen verteilt wird, die richtigen Leute einen Zugriff haben, andere Leute keinen Zugriff haben, etc. Somit gibt es in einer Netzwerkumgebung eine extensive Anwendung der Managementschnittstelle 33.
In bezug auf die beim Beschreiben der Managementschnittstelle angewendete Terminologie, sowie des Lizenz-Managementsystems im allgemeinen, ist es hilfreich, zu beachten, daß die Dokumentationskonventionen, Datenerklärungen, Makroerklärungen, etc. für das bei einem Ausführungsbeispiel der Erfindung ange wendete Objektmanagement gemäß den Standards sind, die in OSI Object Management API Specification, Version 2.0, X.400 API Association and X/Open Company Limited, 24 August 1990, einem veröffentlichten Dokument, gezeigt sind.
Die der Managementschnittstelle 33 zur Verfügung stehenden spezifischen Operationen sind zum Zulassen, daß der Management eine Managementsitzung öffnet und schließt, zum Registrieren (Laden) von Objekten in der Lizenzdatenbank 23, zum Erhalten einer Liste von Objekten der Lizenzdatenbank 23 und zum Steuern eines Cursors (ein Cursor ist ein bewegbarer Zeiger zu einem Element einer Liste von Elementen). Wenn einmal ein Objekt in der Lizenzdatenbank 23 mit dem Cursor identifiziert ist, können gewisse Änderungen in bezug auf das Objekt durch eine Schreibfunktion durchgeführt werden. Beispielsweise können gewisse Felder eines Lizenzdokuments der Fig. 2 oder einer LURT der Fig. 4 auf nur spezifizierte Weisen geändert werden, wie es erklärt wird.
Die Operation zum Öffnen einer Sitzung bzw. Session erfolgt durch den Namen von Im_open_session() und wird dazu angewendet, eine Lizenz- Managementdienstsession zwischen einem Managementklienten und dem Dienst aufzubauen. Ein Öffnen einer Session erzeugt auch einen Arbeitsbereich, um Objekte zu enthalten, die als Ergebnis von Funktionen zurückgebracht werden, die innerhalb der Session aufgerufen werden. Objektmanagement-Objekte können innerhalb dieses Arbeitsbereichs erzeugt und manipuliert werden. Innerhalb dieses Arbeitsbereichs erzeugte Objekte, und nur solche Objekte, können als Objektargumente zu anderen Lizenz-Managementdienst-Managementfunktionen angewendet werden, die während der durch einen Aufruf zu dieser Funktion gebildeten Session angewendet werden. Es können mehr als eine Session gleichzeitig existieren.
Die Argumente, die mit einem Aufruf Im_ open_session() anfangen, sind folgende: (a) das Binden einer Handhabung, welches ein Binden von Informationen ist, die ein mögliches Binden definieren (eine Klienten-Server-Beziehung), und (b) ein Kommentar, der in der Protokolldatei 24 eingefügt wird, wenn ein Protokollieren freigegeben ist. Die Ergebnisse von einem Aufruf Im_open_session() sind folgende: (a) ein Zurückbringcode, der anzeigt, ob die Funktion erfolgreich war, und dann, wenn nicht, warum nicht, (b) eine Session, die eine gebildete Lizenz- Managementsession zwischen dem Managementklienten und dem Lizenz- Managementdienst ist, und (c) ein Arbeitsbereich, der alle Objekte enthalten wird, die als Ergebnis von Funktionen zurückgebracht werden, die in der Session aufgerufen werden.
Der Aufruf zum Schließen einer Session wird Im_close_session() genannt und funktioniert zum Beenden der Lizenz-Managementsession. Diese Funktion beendet die Lizenzdienst-Managementsession und macht das Argument für eine Anwendung mit anderen Schnittstellenfunktionen nicht mehr verfügbar. Die Argumente, die mit einem Aufruf Im_close_session() beginnen, sind folgende: (a) die Session, die die gebildete Lizenz-Managementsession zwischen dem Managementklienten und dem Lizenz-Managementdienst identifiziert, und (b) ein Kommentar, der in der Protokolldatei eingefügt wird, wenn eine Protokollierung freigegeben ist. Das Ergebnis des Aufrufs ist ein Zurückbringcode, der anzeigt, ob die Funktion erfolgreich war, und dann, wenn nicht, warum nicht.
Die Listenfunktion bringt eine Gruppe ausgewählter Objekte in der Lizenzdatenbank 23 zurück und wendet den Namen Im_list_licenses() an. Diese Funktion wird angewendet, um die Lizenzdatenbank 23 zu durchsuchen und einen Cursor zurückzubringen, der das erste von einem oder mehreren Objekten darstellt, die mit dem spezifizierten Filter übereinstimmen. Das spezifizierte Filter wird auf jedes Objekt in der Lizenzdatenbank 23 angewendet; alle Objekte, für die das Filter eine Bewertung mit wahr durchführt, werden in der Objektliste enthalten sein, auf die durch die Funktion set_cursor zugreifbar ist. Die Argumente, die mit Im_list_licenses() beginnen, sind folgende: (a) eine Session, die eine gebildete Session zwischen dem Managementklienten und dem Lizenz-Managementdienst identifiziert, und (b) ein Filter, das ein Objekt ist, das zum Auswählen von Objekten der Lizenzdatenbank 23 angewendet wird; Lizenzdatenbank-Objekte werden in der Objektliste, der der Cursor voransteht, nur enthalten sein, wenn sie das Filter erfüllen - das konstante Kein-Filter kann als der Wert dieses Arguments angewendet werden, wenn alle Lizenzdatenobjekte in der Objektliste enthalten sein müssen. Die Ergebnisse des Aufrufs Im_list_licenses() sind folgende: (a) ein Zurückbringcode, der anzeigt, ob die Funktion erfolgreich war, und dann, wenn nicht, warum nicht, und (b) eine Lizenzliste auf ein erfolgreiches Beenden dieses Aufrufs hin, die einen Cursor enthält, der das erste von einem oder mehreren Objekten in der aktuellen Lizenzdatenbank 23 darstellt, für das das spezifizierte Filter eine Bewertung von wahr durchführt.
Die Registrierfunktion besteht im Registrieren von Objekten in der Lizenzdatenbank 23 und wendet den Namen Im_register() an. Diese Funktion wird zum Registrieren (d. h. Laden oder Erzeugen) neuer Objekte oder zum Modifizieren existierender Objekte in der Lizenzdatenbank 23 angewendet; die Objekte, die registriert werden können, enthalten nur diejenigen, die Unterklassen der Lizenzdatenklasse oder Vorgeschichtenobjekte sind. Die Argumente sind folgende: (a) eine Session, die eine gebildete Session zwischen dem Managementklienten und dem Lizenz- Managementdienst identifiziert, (b) ein Lizenzdatenobjekt, das zu registrieren ist; wenn dieses Argument weggelassen ist, ist das Kommentierungsargument ein erforderliches Argument und ein Vorgeschichtenobjekt, das die Kommentierung enthält, wird in der Lizenzdatenbank 23 registriert, und (c) eine Kommentierung, die in der Protokolldatei eingefügt werden wird, wenn ein Protokollieren freigegeben ist. Das Ergebnis ist ein Zurückbringcode, der anzeigt, ob die Funktion erfolgreich war und dann, wenn nicht, warum nicht. Die Fehler, die möglich sind, wenn sie nicht erfolgreich war, enthalten einen Datenablauf, ein Doppelobjekt, keine solche Session, unzureichenden Speicher, einen Netzwerkfehler, etc., was durch diesen Zurückbringcode angezeigt wird.
Die Funktion zum Einstellen bzw. Setzen eines Cursors bildet einen neuen Cursor und wird Im_set_cursor() genannt. Die Argumente sind folgende: (a) eine Session, die eine gebildete Session zwischen dem Managementklienten und dem Lizenz- Managementdienst identifiziert, (b) ein Weiterleiten, was ein Bool'scher Wert ist, der anzeigt, ob die Richtung, in welcher der Cursor zu bewegen ist, vorwärts oder rückwärts ist, (c) ein Filtern, was zum Eliminieren von Cursorn von der Suche nach dem nächsten Cursor angewendet wird, die nicht erwünscht sind; ein neuer Cursor wird nur eingestellt, wenn er das Filter erfüllt - das konstante Kein-Filter kann als der Wert dieses Arguments angewendet werden, wenn irgendein Cursor als der Zielcursor anzusehen ist, und (d) der Cursor, der als die Anfangsstelle beim Suchen nach dem neuen Cursor anzuwenden ist. Die Ergebnisse sind folgende: (a) ein Zurückbringcode, der anzeigt, ob die Funktion erfolgreich war, und dann, wenn nicht, warum nicht, und (b) ein nächster Cursor, der der angefragte Cursor ist. Die Fehlercodes im Zurückbringcode können Ende einer Liste, nicht ein Cursor, etc. sein.
Nachdem eine Session geöffnet ist und ein Objekt, wie beispielsweise eine Produktanwendungs-Zugriffsberechtigung oder eine LURT, durch den Cursor identifiziert worden ist, und zwar unter Anwendung der oben erklärten Funktionen, kann die Managementschnittstelle 33 gewisse Objektmanagement-Schnittstellenfunktionen ausführen, wie beispielsweise ein Schreiben oder ein Kopieren. Durch diesen Mechanismus kann die Managementschnittstelle gewisse beschränkte Attribute modifizieren. Normalerweise kann keines dieser Attribute auf eine derartige Weise modifiziert werden, daß sie Beschränkungen reduzieren, die durch entsprechende Attribute in den Lizenzdatenobjekten gebildet sind. Wichtigere Attribute, die durch die Managementschnittstelle 33 unter Anwendung dieses Mechanismus modifiziert werden können, sind folgende:
(a) eine Zuordnung: eine Zuordnung einiger oder aller der Einheiten, die bei der zugeordneten Produktanwendungs-Zugriffsberechtigung gewährt sind;
(b) Reservierung: eine Reservierung einiger oder aller der Einheiten, die bei der zugeordneten Produktanwendungs-Zugriffsberechtigung gewährt sind;
(c) Delegation: eine Delegation des Rechts zum Managen einiger oder aller der Einheiten, die bei der zugeordneten Produktanwendungs-Zugriffsberechtigung gewährt sind, oder dann, wenn die zugeordneten Lizenzdaten keine Produktanwendungs-Zugriffsberechtigung sind, ist die Delegation das Recht zum Verwenden jener Lizenzdaten;
(d) Sicherungsdelegation: eine Angabe des Rechts zum Managen einiger oder aller der Einheiten, die bei der zugeordneten Produktanwendungs-Zugriffsberechtigung gewährt sind; dieses Recht ist nur zu Zeiten aktiv, zu denen der delegierende Server nicht verfügbar ist;
(e) Zuteilung: eine Zuteilung von Einheiten zu einem spezifischen Kontext;
(f) Zuteilungsperiode: die minimale Dauer einer einzelnen Zuteilung - alle zugeteilten Einheiten können nicht zu einem neuen Kontext zugeteilt werden, bis eine Zeitperiode gleich der Zuteilungsperiode verstrichen ist, seit die Einheiten zuletzt zugeteilt wurden;
(g) Beendigungsdatum: ein Datum, das den Wert zu überschreiben hat, der als das Enddatum der Produktanwendungs-Zugriffsberechtigung 40 spezifiziert ist - dieses Datum muß früher als spezifiziert sein;
(h) eine zugelassene Delegation: ein Überschreiben der zugeordneten Lizenzdaten;
(i) Überziehung: der aktuelle Überziehungspegel;
(j) Überziehungsprotokollierung: ein Überschreiben des Überziehungs- Protokollierungsattributs der zugeordneten Produktanwendungs- Zugriffsberechtigung;
(k) Kommentierung: eine durch den Lizenzgeber erzeugte Kommentierung;
(l) erweiterte Info: Informationen, die nicht durch die Architektur definiert sind, die von Nutzen beim Managen der Lizenzdaten sein kann.
Es ist zu beachten, daß eine Zuordnung und eine Reservierung identisch sind, wobei der einzige Unterschied darin besteht, daß eine Reservierung etwas optionales ist, während eine Zuordnung etwas ist, was erforderlich ist. Wenn die Dauer eine Zuordnung bei der Police-Erklärung der Fig. 3 ist, muß der Lizenz-Manager einige oder alle der Einheiten zuordnen, bevor Einheiten zugeteilt werden können. Andererseits werden Reservierungen durch den Lizenz-Manager unter Anwendung der Managementschnittstelle ungeachtet der Police durchgeführt.
Somit gibt es gewisse Attribute, die durch einen Lizenzverwalter unter Anwendung der Managementschnittstelle beim Server 10 geändert werden können, aber normalerweise kann nichts davon in einem Erhalten extensiverer Nutzungsrechte resultieren als durch die Produktanwendungs-Zugriffsberechtigung gewährt. In jedem Fall kann der Lizenzverwalter die Rechte, die Anwendern zugeteilt werden, auf irgendeine Weise beschränken, die für den Verwalter für Kontrollzwecke geeignet sein kann.

LIZENZDOKUMENTENAUSTAUSCHFORMAT

Die strukturellen Hauptkomponenten eines mit ASN.1 codierten Dokuments, das an die Spezifikationen für das oben diskutierte Lizenz-Managementsystem angepaßt ist, wird beschrieben. Der Objektidentifizierer, der gemäß einem Ausführungsbeispiel dieser Datensyntax zugeordnet ist, ist derjenige, der in ASN.1 spezifiziert ist, wie es in Fig. 8 zu sehen ist. Die internationale Standardorganisation oder ISO, wie sie genannt wird, definiert, wie Bitmuster ausgewählt werden, um einen Objekttyp eindeutig zu identifizieren, so daß das Bitmuster, das in Fig. 8 gezeigt ist, jedem Dokument vorangehen würde, das im Lizenz-Managementsystem angewendet wird, so daß das Dokument als ein derartiges Dokument identifiziert werden könnte, das an das vorgeschriebene Lizenzdokumentenaustauschformat angepaßt ist.
Ein gemäß diesem Format codiertes Dokument wird durch einen Wert eines komplexen Datentyps dargestellt, der bei diesem Ausführungsbeispiel "Lizenzdokumentenaustauschformat-Dokument" oder LDIF-Dokument genannt wird. Ein Wert dieses Datentyps stellt ein einziges Dokument dar. Die selbstbe schreibende Datenstruktur ist von der Syntax, die im internationalen Standard ASN.1 definiert ist, auf den oben Bezug genommen wurde. Der Standard X/Open, auf den oben Bezug genommen wurde, definiert die Konventionen, die beim Verwenden dieser Syntax angewendet werden müssen, während die Syntax selbst in einem OSI-(Open Systems Interconnect, ein durch ISO verwalteter Standard)- Dokument beschrieben ist, das als X.409 identifiziert ist (auf das im Dokument X/Open Bezug genommen ist, das hierin identifiziert ist).
Der LDIF-Dokumenten-Datentyp besteht aus einer geordneten Folge von drei Elementen: den Dokumentenbeschreiber, den Dokumentenanfang und das Dokument selbst. Jedes dieser Elemente ist wiederum aus anderen Elementen zusammengesetzt. Die Gesamtstruktur des LDIF-Dokumenten-Datentyps wird beschrieben, und die Art der Typen des Dokumentenbeschreibers und des Dokumentenanfangs. Dann werden die Dokumenteninhaltselemente detailliert beschrieben, sowie die verschiedenen Komponentendatentypen, die bei der Definition des Beschreibers, des Anfangs und des Inhalts angewendet werden.
Das LDIF-Dokument stellt ein einziges Lizenzdokument dar, wobei die Syntax in Fig. 9 gezeigt ist, und wobei die Struktur des hohen Pegels eines LDIF-Dokuments in graphischer Form in Fig. 10 zu sehen ist. Der Dokumentenbeschreiber der Fig. 9 ist eine Beschreibung der Dokumentencodierung, der Dokumentenanfang enthält Parameter und Verarbeitungsbefehle, die zum Dokument als Ganzes gehören, und der Dokumenteninhalt ist der Inhalt des Dokuments, wie es alles unten erklärt wird.
Gemäß Fig. 9 ist das, was dies sagt, daß ein LDIF-Dokument (:: = bedeutet "ist zusammengesetzt aus") zusammengesetzt ist aus, einer Anzahl von Elementen, wobei das erste Ding in einem LDIF-Dokument ein Bitmuster (ein Tag) gemäß einem internationalen Standard ist, was einen bestimmten Typ von Dokument anzeigt, dem folgt, was hier derart angezeigt wird, daß es "privat" oder vom Verkäufer ausgewählt ist, wobei in diesem Fall die Zahl 16373 ist. Dem Bitmuster folgend, das als "Anfangsbegrenzer" funktioniert, ist es "implizit", daß eine "Sequenz" von Elementen folgen muß, wobei eine Sequenz sich von einem Satz unterscheidet. Eine Sequenz ist eines oder mehrere der Elemente, um zu folgen, wohingegen ein Satz genau eines der Elemente ist, das aufzulisten ist. Implizit bedeutet, daß irgendeine Datei, die als LDIF-Dokument identifiziert ist, eher einen Sequenzdatentyp haben muß, als irgendeinen anderen Typ. Im Fall der Fig. 9 ist die Sequenz ein Dokumentenbeschreiber, ein Dokumentenanfang und ein Dokumenteninhalt; der Dokumen teninhalt ist zwingend, wohingegen die ersten zwei optional sind. Wenn ein Element in der Sequenz mit einer "0" beginnt, ist es ein Dokumentenbeschreiber, "1" bedeutet einen Dokumentenanfang und "2" bedeutet, daß es ein Dokumenteninhalt ist. Wiederum ist es implizit, daß die Daten, die folgen, in jedem Fall vom Format Dokumentenbeschreiber, etc. sind, und dies ist in der Fig. 11, der Fig. 13 und der Fig. 15 definiert.
Jede Datei ist im oben angegebenen Tag-Längenwert-Format und auch jedes Element einer Datei, das mehrere Elemente enthält, ist vom Tag-Längenwert- Format. Der Datenstrom könnte beginnend bei jener Stelle untersucht werden und sein Inhalt durch ein erstes Suchen nach einem Tag bestimmt werden, was berichten wird, welche Datenstruktur dies ist, dann wird ein Längenfeld sagen, wie lang es ist, und dann wird der Inhalt erscheinen. Diese Strukturen sind ineinander verschachtelt; ein Dokument, das mehrere Produktanwendungs-Zugriffsberechtigungen enthält, wäre ein LDIF-Dokument vom Format der Fig. 9, wobei eine Anzahl von Dokumenteninhalts-Elementen der Fig. 15 folgen, und zwar mit der Länge, die für das LDIF-Dokument gegeben ist, die die mehreren PUAs überspannt, und der Länge, die für jede PUA gegeben ist, die für eine PUA ist.
In Fig. 11 sind die Hauptversionselemente und die Unterversionselemente derart zu sehen, daß sie "implizite ganze Zahlen" sind. Dies bedeutet, daß das Element deshalb, weil es vom Typ Hauptversion, etc. ist, eine ganze Zahl sein muß. Verschiedene andere implizite Typen sind in anderen Syntaxdiagrammen gegeben, wie beispielsweise eine Zeichenkette, ein Bool'scher Typ, etc.
In Fig. 15 ist der Lizenzkörper derart identifiziert, daß er vom Typ "Auswahl" ist, was bedeutet, daß er einer von PUA, LURT, Gruppendefinition, Schlüsselregistrierung, etc. sein kann. Somit bedeutet ein Wissen, daß dies ein Lizenzkörper ist, nicht, daß der Datentyp des Objekts bekannt ist; es erfolgt bei einem nächsten Bit, wo die Art eines Lizenzkörpers bekannt wird. Die Definition eines Lizenzkörpers ist nicht implizit, sondern ist statt dessen vom Wahltyp.
Die Inhalte der verschiedenen Datenelemente werden nun detailliert unter Bezugnahme auf die Fig. 11-43 beschrieben. Unter Anwendung dieser detaillierten Beschreibungen kann das genaue Format jedes der Elemente, das im LDIF angewendet wird, interpretiert werden.
Der Lizenzdokumentenbeschreiber oder Dokumentenbeschreiber besteht aus einer geordneten Sequenz von vier Elementen, die die Versionsebene der LDIF- Codierung spezifizieren und die Software identifizieren, die das Dokument codiert, wobei die Syntax in Fig. 11 gezeigt ist. Ein Beispiel von der Art, auf die ein Produkt, das PAKGEN V1.0 genannt wird, bei der Dokumentenbeschreiber-Codierung ausgedrückt wird, ist in Fig. 12 gezeigt. Die Felder in der Dokumentenbeschreibersyntax sind Hauptversion, Unterversion, Codiereridentifizierer und Codierername. Das Hauptversionsfeld ist der primäre Indikator einer Kompatibilität zwischen LDIF- Prozessoren und dem Codieren des gegenwärtigen Dokuments; dieses Hauptversionsfeld wird einem Updaten unterzogen, wenn Änderungen an der Systemcodierung durchgeführt werden, die nicht rückwärts bzw. abwärts kompatibel sind. Das Unterversionsfeld ist die Revisionsnummer der Systemcodierung. Das Codiereridentifiziererfeld ist eine registrierte Einrichtungs-Speichertechnik, die die Software darstellt, die das Dokument codierte; der Codiereridentifizierer kann ein Acronym oder eine Abkürzung für den Codierernamen sein - dieser Identifizierer ist über Versionen des Codierers konstant. Der Codiereridentifizierer sollte als Vorsilbe zu Tags für einen benannten Wert in Listen für einen benannten Wert angewendet werden, um den Codierer des benannten Werts zu identifizieren. Das Codierernamensfeld ist der Name des Produkts, der das Dokument codierte; die Codierernamenskette muß die Versionsnummer des Produkts enthalten.
Der Dokumentenanfang enthält Daten, die zum Dokument als Ganzes gehören, und beschreibt das Dokument zu Prozessoren, die es empfangen; die Syntax ist in Fig. 13 gezeigt. Ein Beispiel eines Dokumentenanfangs ist in Fig. 14 gezeigt, und zwar unter Anwendung des hypothetischen Produkts PAKGEN V1.0 der Fig. 12. Die privaten Anfangsdaten enthalten die globalen Informationen über das Dokument, die nicht aktuell standardisiert sind; alle Interpretationen dieser Informationen sind Gegenstand von nur privaten Übereinstimmungen zwischen betroffenen Parteien, so daß ein Prozessor, der private Anfangsdaten nicht versteht, jene Daten ignorieren kann. Das Titelfeld ist der für den Anwender sichtbare Name des Dokuments. Das Autorenfeld ist der Name der Person oder der Personen, die für den Informationsinhalt des Dokuments verantwortlich sind. Das Versionenfeld ist die Zeichenkette, die zum Unterscheiden dieser Version des Dokuments von allen anderen Versionen angewendet wird. Das Datumsfeld ist das Datum, das diesem Dokument zugeordnet ist. Es ist zu beachten, daß die Art und Signifikanz der Titel-, Autor-, Versions- und Datums-Felder zwischen Verarbeitungssystemen variieren kann.
Der Inhalt eines LDIF-Dokuments wird durch einen Wert eines komplexen Datentyps dargestellt, der Dokumenteninhalt genannt wird. Ein Element dieses Typs enthält eines oder mehrere Lizenzdaten-Inhaltselemente unter Anwendung einer Syntax, wie sie in Fig. 15 gezeigt ist. Es gibt keine Beschränkungen bezüglich der Anzahl, der Anordnung oder des Kontextes von Lizenzdatenelementen. Die Struktur eines Lizenzdatenelements ist in Fig. 16 dargestellt. Es sind keine Beschränkungen in bezug auf die Anzahl, die Anordnung oder den Kontext von Lizenzdatenelementen auferlegt. Das Lizenzdatenanfangsfeld der Fig. 16 spezifiziert diejenigen Daten, die allen Typen von Lizenzdaten gemeinsam sind, und die die Parteien für die Lizensierungsübereinkunft beschreiben, den Term der Übereinkunft und irgendwelche Beschränkungen, die in bezug auf das Management der im Lizenzkörper codierten Lizenzdaten auferlegt worden sein können. Der Lizenzkörper ist ein Element, das ein Inhaltselement enthält, das folgendes enthält. Produktanwendungs-Zugriffsberechtigungen, Lizenzeinheitenerfordernistabellen, Gruppendefinitionen, Schlüsselregistrierungen und verschiedene Formen von Delegationen. Die Managementinfo ist ein Element, das Informationen in bezug auf den aktuellen Zustand der Lizenzdaten enthält; dieses Element ist vom Herausgeber nicht codiert.
Der Lizenzdatenanfang, der Lizenzdatenanfang genannt wird, ist in Fig. 17 als Syntaxdiagramm dargestellt. Das Lizenz-ID-Feld stellt eine potentiell eindeutige Identifizierung der codierten Lizenzdaten zur Verfügung, so daß Herausgeber von Lizenzdaten eindeutige Lizenz-IDs zum Unterscheiden jeder Ausgabe von Lizenzdaten erzeugen können; jedoch erfordert die Architektur nicht, daß dies der Fall ist, da die einzige architektonische Beschränkung darin besteht, daß keine zwei Objekte in einer einzigen Lizenz-Managementdomäne denselben Wert für eine Lizenz-ID haben können. Das Lizenznehmerfeld identifiziert die Partei, die die Rechte erhalten hat, die in den Lizenzdaten gezeigt sind; es gibt wenigstens zwei Parteien, die bei allen Übertragungen von Lizenzdaten beteiligt sind, nämlich als erstes der Herausgeber der Lizenzdaten und als zweites der Lizenznehmer oder Empfänger jener Daten - es ist vorausgesetzt, daß einzelne Lizenznehmer zu jenen spezifizieren werden, die ihnen Lizenzen ausgeben, was die Lizenznehmerfelder bei ihren Lizenzdaten enthalten sollten. Das Termenfeld identifiziert den Term bzw. Zeitraum, während welchem die Lizenzdaten angewendet werden können; die Gültigkeit von Lizenzdaten kann durch Ausgeber auf spezifische Zeitbereiche mit gegebenen Anfangs- und Enddaten beschränkt werden, die im Termenelement getragen wer den - Versuche zum Verwenden von Lizenzdaten oder Produkten, die durch jene Daten beschrieben sind, entweder vor dem Anfangsdatum oder nach dem Enddatum, werden darin resultieren, daß anpassende Lizenz-Manager einen Zugriff zu der Lizenz ablehnen. Managementbeschränkungen identifizieren Beschränkungen, die dem Recht zum Managen der zugeordneten Lizenzdaten auferlegt sind; diese Beschränkungen können folgendes enthalten: (a) ein Beschränken des Satzes von Kontexten, die zum Managen der Daten zugelassen sind, (b) ein Beschränken des Satzes von Plattformen, die einen Vorteil aus jenem Management ziehen können, und (c) ein Beschränken des Rechts zum Sichern und zum Delegieren der gemanagten Daten. Die Signatur stellt die digitale Signatur zur Verfügung, die durch den Ausgeber zum Zeichnen bzw. Unterzeichnen bzw. Signieren der Lizenzdaten angewendet wird, und identifiziert den beim Codieren der Signatur angewendeten Algorithmus. Eine Herausgeber- bzw. Ausgeberkommentierung ist eine Kommentierung, die durch den Herausgeber bzw. Ausgeber zur Verfügung gestellt wird und die den Lizenzdaten zugeordnet ist.
Die Ausgeberkommentierung ist von einer Informationsnatur und hat keinen Einfluß auf den Prozeß zum Autorisieren einer Produkt- oder Merkmalsanwendung. Dieses Feld ist in den Feldern nicht enthalten, die zum Erzeugen der Signatur für eine Lizenz angewendet werden, weshalb sogar dann, wenn es durch einen Ausgeber spezifiziert ist, die Ausgeberkommentierung von einer Lizenz weggelassen werden kann, ohne die Lizenz ungültig zu machen. Wenn sie spezifiziert ist, sollte die Ausgeberkommentierung in der geeigneten Lizenzdatenbank mit den zugeordneten Lizenzdaten gespeichert sein. Die Ausgeberkommentierung kann durch Produkte ausgelesen werden, die das System anwenden, und kann von einer besonderen Nützlichkeit für Produkte in der "Software-Zuordnungsmanagement"-Domäne sein, die zum Erweitern oder Vergrößern der Verwaltungs- oder Berechnungseinrichtungen oder von Grundsystemkomponenten beabsichtigt sind. Einige Beispiele potentieller Anwendungen für dieses Feld sind Auftragsinformationen, zusätzliche Terme und Bedingungen, und Unterstützungsinformationen. Für Auftragsinformationen können einige Ausgeber wünschen, daß sie mit ihren ladbaren Lizenzdaten irgendein Anzeichen des Verkaufsauftrags oder der Aufträge enthalten, die dazu führten, daß die Lizenzdaten ausgegeben werden; Lizenznehmer können es nützlich finden, daß diese Daten in ihren Lizenzdatenbanken enthalten sind, um beim Lizenz-Managementprozeß zu helfen. Für zusätzliche Terme und Bedingungen wird das System niemals eine automatische Einrichtung für das Management aller möglichen Lizenzterme und -bedingungen zur Verfügung stellen, und so können einige Ausgeber wünschen, daß sie Zusammenfassungen von nicht vom System gemanagten Termen und Bedingungen in der Kommentierung als Erinnerung enthalten. Für Unterstützungsinformationen könnte die Ausgeberkommentierung zum Aufzeichnen der Telefonnummern oder der Adressen der verantwortlichen Individuen innerhalb der Ausgabeorganisation angewendet werden, die kontaktiert werden sollte, wenn es Probleme mit den Daten gibt, wie sie ausgegeben werden.
Eine Produktanwendungs-Zugriffsberechtigung, wie sie zuvor unter Bezugnahme auf Fig. 2 diskutiert ist, wird zum Ausdrücken der Ausgabe eines Rechts zum Anwenden eines Produkts, eines Produktmerkmals oder von Elementen einer Produktgruppe angewendet. Als solches zeichnet sie die Identität des Produkts auf, für welches eine Nutzung autorisiert ist, und spezifiziert die Einrichtung, die durch den Lizenz-Manager dazu angewendet werden wird, sicherzustellen, daß die aktuelle Nutzung eines Lizenznehmers mit den Termen und Bedingungen der Lizenz übereinstimmt. Fig. 18 stellt ein Syntaxdiagramm für eine Produktanwendungs- Zugriffsberechtigung dar. Eine Produkt-ID identifiziert den Namen des Herstellers des Produkts oder des Produktmerkmals, von welchen Nutzungsrechte gewährt werden, sowie den Namen jenes Produkts; zusätzlich können Ausgeber von Produktanwendungs-Zugriffsberechtigungen einen Bereich von Versionen und/oder Veröffentlichungen bzw. Freigaben spezifizieren, deren Nutzung durch die spezifische Produktanwendungs-Zugriffsberechtigung kontrolliert wird. Einheitengewährt enthält die Anzahl von Einheiten einer Produktnutzung, die durch die Lizenz gewährt werden. Eine Managementpolice definiert die Police, die beim Managen der gewährten Software-Nutzungsrechte anzuwenden ist; diese Definition spezifiziert den Stil, die Kontextschablone, die Dauer und das Lizenzeinheitenerfordernis- Bestimmungsverfahren, die angewendet werden müssen. Die aufrufenden Zugriffsberechtigungen und die Aufrufer-Zugriffsberechtigungen sind so, wie es oben in bezug auf Aufrufkarten erklärt ist. Das Ausführungsbeschränkungsfeld identifiziert Beschränkungen, die Eigenschaften von Ausführungskontexten auferlegt sind, die autorisiert sein können, einen Vorteil aus den durch die Produktanwendungs- Zugriffsberechtigung gewährten Einheiten zu ziehen. Das Produkt-Token-Feld enthält produktspezifische Daten, die auf keine Weise durch irgendwelche Prozessoren interpretiert werden, die an die Architektur angepaßt sind; Softwareprodukthersteller 28 anwenden dieses Feld zum Vergrößern der Kapazitäten von angepaßten Lizenz-Managern.
Irgendwelche vorausgesetzten Anwendungen des Tokenfelds enthalten eine Sprachunterstützung, detaillierte Merkmals-Zugriffsberechtigungen und eine Produktunterstützungsnummer. Für eine Sprachunterstützung könnte ein Token konstruiert werden, der eine Liste lokaler Sprachschnittstellenversionen enthält, deren Nutzung autorisiert ist; somit könnte ein Token dann, wenn ein Produkt in Englisch, Deutsch, Französisch und Spanisch verfügbar wäre, derart konstruiert sein, daß es nur Englisch und Deutsch als die autorisierten Sprachen auflistet. Für detaillierte Merkmals-Zugriffsberechtigungen werden einige Lizenzgeber wünschen, eine sehr genaue Kontrolle über die Nutzung von Merkmalen in einem komplexen Produkt zu haben; jedoch können sie nicht wünschen, eine große Anzahl individueller Produktanwendungs-Zugriffsberechtigungen auszugeben, um jedes Merkmal "einzuschalten", so daß diese Käufer Token konstruieren könnten, die Listen der autorisierten Merkmale enthalten, oder deren Nutzung abgelehnt ist. Für eine Produktunterstützungsnummer können einige Ausgeber wünschen, daß sie bei der Produktanwendungs-Zugriffsberechtigung enthalten ist, und somit für das laufende Produkt zur Verfügung steht, wobei einige Informationen die Unterstützungsverfahren für das Produkt betreffen; beispielsweise könnte ein Ausgeber die Telefonnummer des Unterstützungszentrums oder eine Unterstützungs-Vertragsnummer enthalten, und das Produkt könnte derart entwickelt sein, daß es diese Daten vom Lizenz-Manager ausliest und als Teil von Hilfe-Dialogfeldern anzeigt.
Die LURTs oder Lizenzanwendungserfordernistabellen der Fig. 4 stellen eine Einrichtung zur Verfügung, durch welche Ausgeber bzw. Geber von Lizenzen, deren LURDM vom Typ der Plattform abhängt, auf der das Produkt läuft, Information speichern können, die die Beziehung zwischen dem Plattformtyp und Einheitenerfordernissen beschreiben. Ein Syntaxdiagramm für eine LURT ist in Fig. 19 gezeigt. In Fig. 20 ist ein Beispiel davon dargestellt, wie die LURT der Fig. 4 codiert sein könnte. Ein LURT-Name spezifiziert den Namen, durch welchen die LURT für anpassende Lizenz-Manager zu kennen ist. Das Zeilenfeld moduliert eine Liste von Mehrspalten-LURT-Zeilen. Eine Plattform-ID identifiziert die Plattform, für welche diese LURT-Zeile Lizenzeinheitenerfordernisse zur Verfügung stellt. Das LURT- Spaltenfeld stellt eine Liste von einem oder mehreren LURT-Spaltenwerten zur Verfügung; der erste Wert, der zur Verfügung gestellt wird, ist einer Spalte-1 der LURT-Zeile zugeordnet, der zweite Wert, der zur Verfügung gestellt wird, ist einer Spalte- zugeordnet, etc. Ein LURT-Spaltenwert von -1 zeigt an, daß eine Nutzung des Produkts oder des Merkmals nicht autorisiert ist, während ein LURT- Spaltenwert von 0 oder darüber die Anzahl von Einheiten anzeigt, die zugeteilt werden müssen, um eine Produktnutzung auf der Plattform zu autorisieren, die durch diese LURT-Zeile beschrieben ist. Alle nicht spezifizierten Spalten (z. B. die Spalten, deren Anzahl größer als die Anzahl von Spaltenwerten ist, die im LURT- Spaltenelement zur Verfügung gestellt werden) werden derart angesehen, daß sie den Wert -1 enthalten.
Gemäß Fig. 19 würde das Plattform-ID-Element zum Anwenden des oben angegebenen Zeilenselektormerkmals durch Zeilenselektor ersetzt werden, was implizit vom Kontext wäre. Ebenso würde in Fig. 34, die unten beschrieben ist, im Iurdm- Artenelement Zeilenselektor enthalten sein, wenn das Zeilenauswahlmerkmal anzuwenden ist.
Wie es oben diskutiert ist, stellt Fig. 4 ein Beispiel einer hypothetischen LURT zur Verfügung, welche den LURT-Mechanismus darstellt, wobei der Ausgeber dieser LURT-Tabelle drei Einheitenerfordernisstufen zur Anwendung beim Bestimmen der Einheitenerfordernisse für jene Produkte des Ausgebers ausgebildet hat. Fig. 20 zeigt ein Beispiel dafür, wie die in Fig. 4 gezeigte LURT codiert werden könnte.
Eine Gruppendefinition wird zum Definieren und Benennen einer Lizenzgruppe angewendet. Wenn sie einmal so definiert ist, kann der Name dieser Gruppe bei Produktanwendungs-Zugriffsberechtigungen auf dieselbe Weise wie ein Produktname angewendet werden. Da eine einzige Produktanwendungs-Zugriffsberechtigung die Managementpolice für alle Elemente der Gruppe spezifiziert, müssen die Elemente der Gruppe in ihren Lizensierungsstilen kompatibel sein, d. h. ein persönliches Anwendungstypprodukt kann nicht mit einem gleichzeitigen Anwendungsprodukt in derselben Gruppe gemischt werden. Fig. 21 zeigt ein Gruppendefinitionssyntaxdiagramm. Ein Gruppenname ist der Name, der bei Produktanwendungs- Zugriffsberechtigungen für diese Gruppe erscheinen muß. Gruppenversion spezifiziert die aktuelle Version dieser Gruppe; die Erfordernisse zur Übereinstimmung zwischen den Versionsinformationen über eine Produktanwendungs- Zugriffsberechtigung und diejenigen über eine spezifizierte Gruppendefinition sind dieselben wie jene Regeln, die eine Übereinstimmung zwischen Produktanwendungs-Zugriffsberechtigungen und den Freigabedatums-Daten, die durch Produkte zur Verfügung gestellt werden, erfordern. Gruppenelemente listen jene Produkte oder Merkmale auf, die Komponenten der benannten Gruppe sind.
Eine Schlüsselregistrierung wird durch einen Hersteller 28 oder einen Ausgeber 25 angewendet, die als autorisierte Lizenzgeber registriert worden sind und mit einem geeigneten öffentlichen oder privaten Schlüsselpaar ausgestattet worden sind. Die Schlüsselregistrierung identifiziert den öffentlichen Schlüssel, der durch anpassende Lizenz-Manager 10 beim Bewerten von Signaturen 53 anzuwenden ist, die durch die benannten Ausgeber 25 oder den Hersteller 28 erzeugt sind. Ein Schlüsselregistrierungs-Syntaxdiagramm ist in Fig. 22 gezeigt. Ein Schlüsselbesitzername stellt den Namen zur Verfügung, der in einem oder beiden von dem Herstellerfeld und dem Ausgeberfeld von Lizenzdaten angewendet werden muß, die durch den Ausgeber erzeugt sind; der Schlüsselbesitzername muß identisch zu demjenigen sein, der im Ausgeberfeld des Anfangsdatensatzes spezifiziert ist. Ein Schlüsselalgorithmus identifiziert den registrierten Algorithmus, der dann anzuwenden ist, wenn digitale Signaturen mit diesem Schlüssel erzeugt werden. Ein Schlüsselwert identifiziert den öffentlichen Schlüssel.
Eine Ausgeberdelegation wird typischerweise durch einen Hersteller 28 ausgegeben und autorisiert den benannten Ausgeber 25 zum Ausgeben von Lizenzen für Produkte, die durch den Hersteller erzeugt sind. Ein Ausgeberdelegations- Syntaxdiagramm ist in Fig. 23 gezeigt. Ein Name für einen delegierten Ausgeber identifiziert den Namen, der im Ausgeberfeld irgendeiner Produktanwendungs- Zugriffsberechtigung erscheinen muß, die unter Anwendung der Lizenzgeberdelegation erzeugt ist. Eine ID für das delegierte Produkt identifiziert die Produkte, für deren Lizenzausgabe der benannte Ausgeber autorisiert ist. Delegierte-Einheitengewährt zeigt dann, wenn es spezifiziert ist, an, daß die Anwendung dieser Ausgeberdelegation im Stil einer verbrauchenden Lizenz zu managen ist; der Wert dieses Attributs gibt die Anzahl von Einheiten an, für welche Lizenzdokumente erzeugt werden können (d. h. wenn es gewährte 1000 Einheiten von einem Hersteller gibt, kann ein Geber bzw. Ausgeber bzw. Herausgeber nur 1000 Einheiten ausgeben). Eine Schablonen-Zugriffsberechtigung stellt eine "Schablonen"- Produktanwendungs-Zugriffsberechtigung zur Verfügung, deren Attributwerte bei jeder Produktanwendungs-Zugriffsberechtigung enthalten sein müssen, die unter Anwendung dieser Ausgeberdelegation erzeugt ist; im Fall von Attributen, die einen skalaren Wert haben (d. h. Version, Veröffentlichungsdatum, etc.) kann der Ausgeber Lizenzen mit restriktiveren Werten als denjenigen Ausgeben, die bei der Schablonen-Zugriffsberechtigung spezifiziert sind. Unterlizenz-Zugelassen zeigt an, ob der Ausgeber, der auf diese Ausgeberdelegation identifiziert ist, eine Ausgeberdelegation für die ID für das delegierte Produkt ausgeben kann.
Eine Lizenzdelegation, wie sie in einem Syntaxdiagramm der Fig. 24 gezeigt ist, wird zum Delegieren des Rechts zum Managen von Lizenzdaten angewendet. Solche Delegationen werden durch den Lizenznehmer (durch den Lizenz-Manager) erzeugt, wenn er durch den Ausgeber 28 autorisiert ist. Eine Sicherungsdelegation, die auch in Fig. 24 gezeigt ist, wird durch eine Lizenz-Managementeinrichtung zum Autorisieren einer weiteren angewendet, um die delegierten Rechte in dem Fall zu managen, daß der delegierende Lizenz-Manager nicht läuft. Das Feld für delegierte Einheiten spezifiziert die Anzahl von Einheiten, deren Management delegiert ist; dies kann nur spezifiziert sein, wenn eine Produktanwendungs-Zugriffsberechtigung delegiert ist. Eine Delegationsverteilungskontrolle definiert den Mechanismus, durch welchen die Verteilung und ein Auffrischen der Delegation erreicht wird. Delegiertenausführungsbeschränkungen identifiziert irgendwelche Beschränkungen, die dem Ausführungskontext des Delegierten auferlegt sind; diese Beschränkungen werden zusätzlich zu denjenigen angewendet, die ein Teil der delegierten Lizenzdaten sind. Eine Zuordnungsliste identifiziert irgendwelche Zuordnungen der delegierten Einheiten, die durch den Delegierten respektiert werden müssen. Delegierte Daten speichert eine Kopie der Lizenzdaten, die vom Ausgeber empfangen werden, der der Gegenstand der Delegation ist; die delegierten Daten sind nicht vorgesehen, wenn das Lizenzdelegationselement in einer Delegationsliste enthalten ist.
Die Managementinformationen oder das Managementinfo-Element zeichnen Informationen in bezug auf den aktuellen Zustand der Lizenzdaten auf, welchen sie zugeordnet sind. Ein Syntaxdiagramm des Managementinfo-Elements ist in Fig. 25 gezeigt. Das Zuordnungsfeld identifiziert eine Liste von einer oder mehreren Zuordnungen, die für die Einheiten an der zugeordneten Produktanwendungs- Zugriffsberechtigung ausstehend sein können. Reservierungen identifiziert eine Liste von einer oder mehreren Reservierungen, die für die Einheiten an der zugeordneten Produktanwendungs-Zugriffsberechtigung ausstehend sein können. Delegationen identifiziert eine Liste von allen ausstehenden Delegationen. Sicherungsdelegationen identifiziert alle ausstehenden Sicherungsdelegationen. Das Zuordnungsfeld stellt detaillierte Informationen über ausstehende Zuteilungen zur Verfügung, die Einheiten von der zugeordneten Produktanwendungs- Zugriffsberechtigung enthalten. Das Registrierungsdatum ist das Datum, an welchem die Lizenzdaten in der Lizenzdatenbank registriert wurden. Registrierung ist der Kontext, der dazu führt, daß die Lizenzdaten registriert werden. Lokale Kom mentierung ist ein Kommentierungsfeld. Beendigungsdatum hat die Bedeutung eines durch eine Lizenz definierten Datums, nach welchem die Lizenzdaten nicht angewendet werden können; dieses Datum muß früher als das Enddatum sein, das im Termendatensatz der Lizenzdaten spezifiziert ist. Das Feld für erweiterte Info erlaubt zusätzliche Informationen in bezug auf den nicht standardisierten Zustand der Lizenzdaten und ihre Handhabung durch den Lizenz-Manager.
Nun werden die definierten Typen von Elementen beschrieben. Diese definierten Typen sind folgende:
Zuteilung Managementpolice
Zuordnung Element
Kontext Benannter Wert
Verteilungskontrolle Liste für benannten Wert
Ausführungsbeschränkungen Produkt-ID
Intervallzeit Signatur
Lizenz-ID Term
LUDRM Version
Managementbeschränkungen
Das Zuteilungselement zeichnet die Informationen in bezug auf eine einzige Einheitenzuteilung auf und ist in einem Syntaxdiagramm in Fig. 26 gezeigt. Zuteilungskontext spezifiziert den Kontext, zu dem die Zuteilung gemacht wurde. Das Zuteilungs-Iur-Feld spezifiziert das Lizenzeinheitenerfordernis, das auf den Zuteilungskontext Anwendung findet; dieses Lizenzeinheitenerfordernis wird ohne Berücksichtigung irgendeiner Zuteilungsaufteilung berechnet, die möglich sein kann. Das Zuteilungs-Gruppen-ID-Feld identifiziert die "Zuteilungsgruppe" für die aktuelle Zuteilung, wobei eine nicht aufgeteilte Zuteilung immer eine Zuteilungsgruppen-ID von 0 haben wird; Zuteilungen, die geteilte Einheiten bzw. gemeinsam genutzte Einheiten anwenden, werden eine Zuteilungsgruppen-ID haben, die von allen anderen Zuteilungen gemeinsam genutzt wird, die dieselben Einheiten gemeinsam nutzen.
Das Zuordnungselement ist im Syntaxdiagramm in Fig. 27 gezeigt. Zugeordnete Einheiten identifiziert die Anzahl von Einheiten, die zugeordnet werden. Zuordnungsterm identifiziert den Anfang und das Ende der Zuordnungsperiode. Zugeordneter identifiziert den Kontext, zu dem die Zuordnung gemacht wird.
Das Kontextelement ist im Syntaxdiagramm in Fig. 28 gezeigt. Das Unterkontext- Typenfeld identifiziert den Typ eines Unterkontexts, und dieser Typ kann entweder Standard oder Privat sein. Wenn er Standard ist, wird der Typenwert von der Standard-Unterkontext-Typennumerierung genommen: (a) Netzwerk-Unterkontext bedeutet den Unterkontextwert, der ein Netzwerk identifiziert; (b) Ausführungsdomänen-Unterkontext bedeutet den Unterkontextwert, der der Name der Managementdomäne ist, innerhalb welcher der Aufrufer ausführt; (c) Einlog-Domänen-Untertext bedeutet, daß der Unterkontextwert der Name der Managementdomäne ist, innerhalb der der Anwender des Aufrufers ursprünglich authentisiert oder "eingeloggt" war; (d) Knoten-Unterkontext bedeutet, daß der Unterkontextwert der Name eines Knotens ist; (e) Prozeßfamilien-Unterkontext bedeutet, daß der Unterkontextwert ein implementierungsspezifischer Identifizierer für eine Gruppe zugehöriger Prozesse ist; (f) Prozeß-ID-Unterkontext bedeutet, daß der Unterkontextwert ein implementierungsspezifischer Prozeßidentifizierer ist; (g) Anwendernamens- Unterkontext bedeutet, daß der Unterkontextwert ein Anwendername ist; (h) Produktnamen-Unterkontext bedeutet, daß der Unterkontextwert derselbe wie der Produktname ist, der bei der Produktanwendungs-Zugriffsberechtigung gefunden wird; (i) Betriebssystem-Unterkontext bedeutet, daß der Unterkontextwert eine Zeichenkettendarstellung des Namens des Betriebssystems ist; (j) Plattform-ID- Unterkontext bedeutet, daß der Unterkontextwert ein Identifizierer ist, der die Hardwareplattform beschreibt, die den Kontext unterstützt. Das Unterkontextwert- Feld ist der Wert des Unterkontexts.
Wie es oben diskutiert ist, werden Lizenzdaten immer angewendet oder zugeteilt innerhalb irgendeines benannten Lizensierungskontexts oder für den Vorteil von ihm. Dieser Kontextname ist durch Verketten der Werte aller Unterkontexte in einen einzigen Kontextnamen aufgebaut. Eine Kontextschablone spezifiziert jene Komponenten des Kontextnamens, der beim Berechnen von Lizenzeinheitenerfordernissen angewendet werden sollte. Das Managementsystem bestimmt die Notwendigkeit zum Durchführen einer Einheitenzuteilung jedesmal, wenn die Lizenzeinheiten angefragt werden. Der vollständige Kontext, auf dessen Veranlassung hin die Zuteilung durchgeführt werden sollte, wird für jede angefragte Autorisierung erhalten. Das System wird den vollständigen Kontext maskieren, um alle Unterkontexte auszuschließen, die nicht in der Kontextschablone spezifiziert sind, und dann bestimmen, ob der resultierende Kontext bereits ihm zugeteilte Einheiten hat. Wenn es nicht so ist, werden Einheiten gemäß der Spezifikation des LURDM zugeteilt werden, und sonst werden die zuvor zugeteilten Einheiten durch den neuen Kontext gemeinsam genutzt. Somit wird dann, wenn eine gegebene Produkt- Zugriffsberechtigung eine Kontextspezifizierung von KNOTEN + BENUTZER_NAME enthält, jeder Kontext, der Lizenzeinheitenzuteilungen anfragt und der ein eindeutiges Paar von KNOTEN + BENUTZER_NAME- Unterkontextwerten hat, erfordern, daß eine explizite Gewährung von Lizenzeinheiten durchgeführt wird. Andererseits werden irgendwelche Kontexte, die dasselbe Paar von KNOTEN + BENUTZER_NAME-Unterkontextwerten gemeinsam nutzen, dazu fähig sein, eine einzige Zuteilung von Lizenzeinheiten "gemeinsam zu nutzen". Das Erfordernis für spezifische Zuteilungen von Einheiten und die Fähigkeit zum gemeinsamen Nutzen von Einheiten ist in Fig. 29 gezeigt, die versucht, einen "Schnappschuß" bzw. eine "Momentaufnahme", der bzw. die für das Produkt FOOBAR V4.1 bei einem bestimmten Fall zugeteilten Einheiten zur Verfügung zu stellen. Aus der Figur ist zu sehen, daß, obwohl sie mit fünf eindeutigen vollständigen Kontexten gezeigt ist, nur vier von ihnen eindeutig sind, wenn man nur auf diejenigen Teile jedes Kontexts schaut, die durch die Kontextschablone beschrieben sind (d. h.: KNOTEN + BENUTZER_NAME). Eine Einheitenzuteilung muß für jeden der vier Fälle von eindeutigen Kontexten durchgeführt werden, wenn sie durch die Kontextschablone maskiert sind. Der fünfte Kontext kann zugeteilte Einheiten mit einem weiteren Kontext gemeinsam nutzen. Somit wäre das gesamte Erfordernis zum Unterstützen einer Produktanwendung, wie es in diesem Beispiel beschrieben ist, 40 Einheiten (d. h.: vier Zuteilungen von jeweils zehn Einheiten). Signifikante Änderungen bei den Einheitenerfordernissen können durch Durchführen von geringfügigen Modifikationen in bezug auf die Kontextschablone erreicht werden. Fig. 30 zeigt dieselben Kontexte wie in Fig. 29, aber eine Kontext Schablone von KNOTEN. Das gesamte Einheitenerfordernis für dieses Beispiel wäre eher drei Einheiten (drei Zuteilungen von jeweils zehn Einheiten), als die vierzig Einheiten, die beim vorherigen Beispiel erforderlich sind.
Das Verteilungskontrollelement definiert den Mechanismus, der zum Verteilen der Gegenstands- bzw. Subjektdelegation angewendet werden wird und zeichnet einige Zustandsinformationen in bezug auf die Verteilung jener Delegation auf. Ein Syntaxdiagramm des Verteilungskontrollelements ist in Fig. 31 gezeigt. Verteilungsverfahren identifiziert die Einrichtung, durch welche die Delegation verteilt werden wird, und die Alternativen sind eine Auffrischverteilung, anfangs = Nur- Verteilung und eine manuelle Verteilung. Auffrischverteilung bedeutet, daß der Lizenz-Manager für die Anfangsverteilung der Delegation verantwortlich sein wird und für ein Sicherstellen, daß Auffrischdelegationen richtig verteilt werden. Nur Anfangsverteilung bedeutet, daß der Lizenz-Manager für die Anfangsverteilung der Delegation verantwortlich sein wird, jedoch wird eine Verteilung von Auffrischdelegationen durch irgendeine andere Einrichtung durchgeführt. Manuelle Verteilung bedeutet, daß die Verteilung der Delegation unter der Kontrolle bzw. Steuerung irgendeines anderen Mechanismus (vielleicht eines Lizenz-Zusatzmanagers) erfolgen wird. Aktuelles Anfangsdatum ist die Zeit, zu der die letzte erfolgreiche Anfangs- oder Auffrisch-Delegationsverteilung durchgeführt wurde. Aktuelles Enddatum identifiziert das letzte Datum, an welchem die allerletzte Delegationsverteilung durchgeführt wurde. Auffrischintervall identifiziert die Zeitperiode zwischen Versuchen zum Auffrischen der Delegation; das Auffrischintervall kann nicht länger als die maximale Delegationsperiode sein und sollte normalerweise kleiner als diese sein, um sicherzustellen, daß Auffrischdelegationen vor dem Ablauf der vorherigen Delegationen verteilt werden, die sie ersetzen. Intervall für einen erneuten Versuch identifiziert die Menge an Zeit zum Warten auf einen nicht erfolgreichen Verteilungsversuch zum erneuten Versuchen. Maximale Zahl für erneutes Versuchen identifiziert die maximale Anzahl von Malen, die ein nicht erfolgreicher Verteilungsversuch erneut versucht werden kann. Erneute Versuche zeichnet die Anzahl von nicht erfolgreichen Versuchen für ein erneutes Versuchen auf, die durchgeführt worden sind, seit die letzte erfolgreiche Anfangs- oder Auffrisch- Delegationsverteilung durchgeführt wurde.
Die Ausführungsbeschränkungselemente setzen Schranken für die Umgebungen und Kontexte, die Zuteilungen empfangen können. Ein Syntaxdiagramm des Ausführungsbeschränkungselements ist in Fig. 32 gezeigt. Ein Betriebssystem enthält eine Liste von Null oder mehr Betriebssystemen, auf welchen die Anwendung der Subjektlizenz autorisiert ist; wenn keine Betriebssysteme spezifiziert sind, wird angenommen, daß eine Lizenzanwendung auf allen Betriebssystemen autorisiert ist. Ausführungskontext spezifiziert eine Liste von Null oder mehreren vollständigen oder teilweisen Kontextnamen, die die Kontexte identifizieren, innerhalb welchen Produkte, die durch die Lizenzdaten beschrieben sind, ausgeführt werden können; wenn keine Kontextnamen spezifiziert sind, können die lizensierten Produkte in irgendeinem Kontext ausgeführt werden, der durch die Lizenz kontrolliert bzw. gesteuert wird. Umgebungsliste identifiziert jene Umgebungen, innerhalb welchen das lizensierte Produkt angewendet werden kann.
Das Intervallzeitelement ist durch die Syntaxintervall:: = UTCZeit definiert.
Das Lizenz-ID-Element identifiziert die Lizenzdaten eindeutig, denen es zugeordnet ist, und ist durch das Syntaxdiagramm der Fig. 33 beschrieben. Hier identifiziert ein Ausgeber den Ausgeber der Lizenzdaten eindeutig, sowie den Namensbereich, innerhalb welchem die Lizenz-ID-Nummer gehalten wird. Während der Ausgebername typischerweise derselbe wie der Name der Firma des Ausgebers oder ein persönlicher Name sein wird, ist dies kein Erfordernis. Beispielsweise: der Ausgebername für Digital Equipment Corporation ist "DEC", eine Abkürzung des gesamten Namens. Gültige Inhalte des Ausgeberfeldes werden in einer Ausgeberregistratur unterhalten. Die Seriennummer stellt eine eindeutige Identifikation oder eine Seriennummer für die Lizenzdaten zur Verfügung. Das Änderungsfeld ist eine ganze Zahl, die jedesmal dann inkrementiert wird, wenn Lizenzdaten durch ihren Ausgeber geändert werden, wobei die erste Version irgendwelcher Lizenzdaten die Änderungsnummer 0 trägt; eine Änderung kann nur auf Lizenzdaten angewendet werden, wenn jene Lizenzdaten identische Ausgeber- und Nummernwerte und eine Änderungsnummer kleiner als die Nummer der anzuwendenden Änderung haben.
Das Lizenzeinheitenerfordernis-Bestimmungsverfahren oder LURDM-Element ist im Syntaxdiagramm in Fig. 34 gezeigt. Das Feld für eine zugelassene Kombination zeigt an, ob zugelassen ist, daß anpassende Lizenz-Manager die Einheiten von unterschiedlichen Produktanwendungs-Zugriffsberechtigungen in einen gemeinsamen Pool miteinander kombinieren, wenn jene Produktanwendungs- Zugriffsberechtigungen denselben Produkt-Datensatzwert haben; beispielsweise dann, wenn eine Kombination zugelassen ist und ein einzelner Lizenz-Manager in seiner Datenbank zwei 500-Einheiten-Zugriffsberechtigungen für die Anwendung von DEC Cobol entdeckt, würde erlaubt, daß der Lizenz-Manager diese zwei Zugriffsberechtigungen in eine logische Gewährung von 1000 Einheiten kombiniert. Die Überziehungsgrenze modifiziert das Verhalten einer anpassenden Lizenz- Managementeinrichtung in denjenigen Fällen, in welchen gefunden wird, daß es Null oder weniger Lizenzeinheiten gibt, die zur Anwendung zur Zeit einer Anfrage nach der Zuteilung oder einem Verbrauch zusätzlicher Lizenzeinheiten verfügbar sind. Ein Betrieb einer Überziehung ist in Abhängigkeit davon unterschiedlich, ob ein zuteilender oder verbrauchender Stil angewendet wird. Beim Verwenden mit einem zuteilenden Stil wird eine Zuteilung selbst dann gewährt, wenn die übrigen Einheiten Null oder weniger sind, und zwar bis zu der Überziehungsgrenze. Bei einer Anwendung mit einem verbrauchenden Stil wird die Lizenz autorisiert, ein negatives Gleichgewicht von Lizenzeinheiten anzusammeln, und zwar bis zur Überziehungsgrenze. Ein erforderliches Überziehungsprotokollieren zeigt an, ob alle Lizenzgewährungen, die das Ergebnis einer Überziehungsnutzung sind, dazu führen müssen, daß ein Protokolldatensatz erzeugt wird. Wenn das Zuteilungsgrößenfeld nicht Null ist, dann müssen alle Einheitenzuteilungen und Delegationen in Größen gemacht werden, die ganzzahlige Vielfache des Zuteilungsgrößenwerts sind. Lurdm-Art identifiziert das Verfahren, durch das Lizenzeinheitenerfordernisse berechnet werden, wenn das Erfordernis für eine Zuteilung einmal entdeckt worden ist, wobei die zugelassenen Alternativen folgende sind: (a) LURT, was spezifiziert, daß Lizenzeinheitenerfordernisse durch Nachschauen in der LURT zu bestimmen sind, die der aktuellen Lizenz zugeordnet ist, (b) eine Konstante, die spezifiziert, daß Lizenzeinheitenerfordernisse für alle Plattformen konstant sind, auf welchen das lizensierte Produkt oder das Produktmerkmal laufen kann, und (c) Privat- LURDM, was spezifiziert, daß Lizenzeinheitenerfordernisse durch das lizensierte Produkt zu bestimmen sind, und nicht durch die Lizenz-Managementeinrichtung. Der benannte LURT-ID spezifiziert den Namen der LURT-Tabelle, der beim Bestimmen von Lizenzeinheitenerfordernissen anzuwenden ist, wenn die LURDM-Art als LURT spezifiziert ist; wenn die LURDM-Art als LURT spezifiziert ist und keine Tabelle explizit genannt ist, wird der Name der anzuwendenden Tabelle aus dem Ausgebernamen an der Produktanwendungs-Zugriffsberechtigung konstruiert. LURDM-Wert spezifiziert die LURT-Spalte, die anzuwenden ist, wenn LURDM-Art = LURT; jedoch dann, wenn LURDM-Art = konstant, enthält das LURDM-Wertefeld die genaue Anzahl von Einheiten, die zuzuteilen oder zu verbrauchen ist. Vorgabeeinheitenerfordernis spezifiziert den Einheitenerforderniswert, der dann anzuwenden ist, wenn die geeignete LURT keine Zeile entsprechend der geeigneten Plattform-ID hat; wenn sie an einer Produktanwendungs-Zugriffsberechtigung mit Stil = Zuteilung spezifiziert ist, wird sich die Kontextschablone zu Prozeß + Produkt_Spezifisch ändern und die Dauer wird sich zu Transaktion in Fällen nicht erkannter Plattform-IDs ändern.
Das Managementbeschränkungselement ist in einem Syntaxdiagramm in Fig. 35 gezeigt. Das Managementkontextfeld spezifiziert eine Liste von Null oder mehreren teilweisen Kontextnamen, die die spezifischen Kontexte identifizieren, innerhalb welchen die Lizenzdaten gemanagt werden können. Wenn keine Managementkontexte spezifiziert sind, können die Lizenzdaten innerhalb irgendeines Kontexts gemanagt werden, der durch den Lizenznehmer gesteuert bzw. kontrolliert wird. Die beim Spezifizieren von Managementkontextbeschränkungen angewendeten Kontexte können nur die Unterkontexte Netzwerk, Domäne und Knoten enthalten. Ein Spezifizieren einer Liste von Managementkontexten beeinflußt nicht, ob die Lizenzdaten innerhalb anderer Kontexte angewendet werden können oder nicht. Beispielsweise kann auf Lizenzdaten mit einem spezifizierten Managementkontext, bis sie auf andere Weise beschränkt sind, von entfernt oder von Delegierten zu anderen Knoten in einem Netzwerk zugegriffen werden. Das Managementschutzfeld definiert eine maximal zugelassene Größe der Lizenz-Managementdomäne, innerhalb welcher die Lizenzdaten gemanagt und verteilt werden können, wobei diese Einzelplattform, Managementdomäne oder Gesamtnetzwerk sind. Einzelplattform beschränkt die Lizenz-Managementdomäne für die Gegenstands-Lizenzdaten derart, daß sie nicht größer als eine einzelne Plattform sind. Managementdomäne beschränkt die Lizenz-Managementdomäne für die Gegenstands-Lizenzdaten derart, daß sie nicht größer als eine einzige Managementdomäne sind. Gesamtnetzwerk beschränkt die Lizenz-Managementdomäne für die Gegenstands-Lizenzdaten derart, daß sie nicht größer als ein einziges weiträumiges Netzwerk sind; das Netzwerk, das die Plattform enthält, auf der die Lizenzeinheiten anfangs geladen wurden. Obwohl die Technologie zum Erfassen der zwischenorganisatorischen Grenzen eines weiträumigen Netzwerks nicht existieren kann (d. h. was auf dem Internet so ist, im Gegensatz zu einem Netzwerk, das einer Firma gehört), wird angenommen, daß eine Zwischenorganisation und eine gemeinsame Nutzung eines Zwischennetzwerks von Lizenzen normalerweise als eine Verletzung von Lizenztermen und -bedingungen angesehen wird. Das Feld für eine zulässige Sicherung zeigt an, ob der Ausgeber die Nutzung von Sicherungsdelegationen für diese Daten autorisiert hat. Zugelassene Delegation zeigt an, ob der Ausgeber den Lizenznehmer autorisiert hat, diese Daten zu delegieren. Maximale Delegationsperioden identifiziert das längste Intervall, während welchem eine Delegation gültig sein kann; durch Vorgabe haben Delegationen eine Lebensdauer von 72 Stunden.
Die Hauptelemente der Managementpolice-Spezifizierung sind in Fig. 3 gezeigt, wie es zuvor diskutiert ist. Ein Syntaxdiagramm für das Manamagentpolice- Element ist in Fig. 36 gezeigt. Für das Stilfeld werden drei fundamentale Stile von Lizenz-Managementpolice unterstützt, nämlich ein zuteilender, ein verbrauchender und ein privater Stil, wie es oben erklärt ist. Nur einer dieser Stile kann einer einzelnen Produktanwendungs-Zugriffsberechtigung zugeordnet sein. Die Kontextschablone spezifiziert jene Komponenten (Unterkontexte) des Ausführungskontextnamens, die beim Bestimmen angewendet werden sollten, ob Einheitenzuteilungen erforderlich sind. Die Dauer definiert die Dauer einer Zuteilung von Lizenzeinheiten zu einem spezifischen Kontext oder die Dauer der Periode, die eine gültige verbrauchende Nutzung definiert. Für Dauern vom Typ "Zuordnung" ist die Spezifizierung einer Beschränkung für eine erneute Zuordnung ebenso zur Verfügung gestellt. Drei Typen von Dauer Art werden unterstützt, wobei diese Transaktion, Zuordnung und direkt sind, wie es oben erklärt ist. Das Iur- Bestimmungsverfahren speichert Informationen, die beim Berechnen der Anzahl von Einheiten angewendet werden, die in Antwort auf eine Lizenzanfrage zugeteilt oder verbraucht werden sollten. Die Zuteilungsaufteilungsgrenze identifiziert die größte Anzahl von Ausführungskontexten, die eine Zuteilung gemeinsam nutzen können, die unter dieser Managementpolice durchgeführt ist; eine Zuteilungsaufteilungsgrenze von Null zeigt an, daß die Anzahl von Ausführungskontexten, die eine Zuteilung gemeinsam nutzen können, unbeschränkt ist. Die Beschränkung für eine erneute Zuordnung spezifiziert eine minimale Dauer einer Zuordnung; obwohl es normalerweise keine Beschränkung gibt, die diesbezüglich auferlegt ist, wie häufig gewährte Einheiten erneut zugeordnet werden können, kann ein Ausgeber ein erneutes Zuordnen durch Spezifizieren dieser minimalen Dauer einer Zuordnung beschränken, in welchem Fall eine erneute Zuordnung zugeordneter Einheiten nicht unterstützt werden wird, bis die Menge an Zeit, die in der Beschränkung für eine erneute Zuordnung spezifiziert ist, verstrichen ist. Wenn eine Zuordnung irgendeiner bestimmten Gruppe bzw. eines bestimmten Satzes von Einheiten delegiert worden ist und die Delegationsperiode für jene Delegation nicht beendet ist, muß eine Auslöschung der Delegation vor einer erneuten Zuordnung durchgeführt werden.
Das Elementenelement identifiziert ein spezifisches lizensiertes Produkt, das ein Teil einer aufrufenden Zugriffsberechtigung oder einer Gruppendefinition sein kann, und ist im Syntaxdiagramm in Fig. 37 gezeigt. Elementenprodukt identifiziert das Produkt, das ein Element ist. Elementensignatur ist aus dem Produkt- Tokenfeldern der aufgerufenen Elementstruktur sowie den Produkt- und Ausgeberfeldern des aufrufenden Produkts konstruiert. Elementen-Token stellt die Daten zur Verfügung, die als das Produkt-Token für dieses Element angewendet werden sollten.
Benannte Werte sind Datenelemente mit einem Zeichenketten-Tag, das das Datenelement identifiziert, und haben eine Syntax, wie es in Fig. 38 gezeigt ist, die auch die Syntax für Wertdaten und eine Liste für benannten Wert zeigt. Eine Liste für benannten Wert modelliert eine Liste von benannten Werten, wobei ein Beispiel in Fig. 39 gezeigt ist. In Fig. 38 identifiziert Wertname den Wert eindeutig; keine standardmäßigen Wertnamen sind definiert, und das Periodenzeichen kann als ein Teil des Wertnamens dazu angewendet werden, eine hierarchische Tag- Registratur nach Ermessen des Ausgebers auszubilden. Wertdaten sind die Daten, die benannt worden sind; Datentypen werden aus den möglichen Wertdatentypen ausgewählt, wie es in der Figur zu sehen ist. Bool'scher Wert bedeutet, daß die benannten Daten ein Bool'scher Wert sind. Ganzzahliger Wert bedeutet, daß die benannten Daten ein ganzzahliger Wert sind. Werttext bedeutet, daß die benannten Daten ein Kettenlistenwert sind. Allgemeiner Wert bedeutet, daß die benannten Daten ein Strom von Bytes in irgendeinem Format sind. Wertliste bedeutet, daß die benannten Daten eine Liste benannter Datenwerte sind.
Die Produkt-ID identifiziert explizit das Produkt, das der Gegenstand der Lizenzdaten ist, denen sie zugeordnet ist, wobei die Syntax für die Produkt-ID in Fig. 40 gezeigt ist. Die Versions- und Veröffentlichungsdatumsfelder stellen einen Mechanismus zur Verfügung, um zu definieren, welche spezifischen Fälle des lizensierten Produkts in den zugeordneten Lizenzdaten beschrieben sind. Das Herstellerfeld ist ein registrierter Name, der den Hersteller des lizensierten Merkmals identifiziert; im Fall von Gruppennamen ist der Hersteller auch immer der Ausgeber der Gruppe. Der Produktname identifiziert ein lizensiertes Software-Merkmal. Die erste Version identifiziert die früheste Version des Produkts, deren Nutzung autorisiert ist. Die letzte Version identifiziert die letzte Version des Produkts, dessen Nutzung autorisiert ist. Das Datum einer ersten Veröffentlichung identifiziert die früheste Veröffentlichung des Produkts, dessen Nutzung autorisiert ist. Das Datum für die letzte Veröffentlichung identifiziert die letzte Veröffentlichung des Produkts, dessen Nutzung autorisiert ist. Es ist erforderlich, daß anpassende Lizenz-Manager die Inhalte dieser Felder in der beschränkendsten Weise interpretieren, die möglich ist. Somit würde dann, wenn eine Lizenz mit letzte Version = 3.0 und einem Datum für eine letzte Veröffentlichung von 1-Jan-1991 ausgegeben wird, die Anwendung einer Version 2.0 des lizensierten Produkts nicht autorisiert sein, wenn sie ein Veröffentlichungsdatum von 2-Jan-1991 hätte. Wenn entweder ein Datum der ersten Version oder ein Datum der ersten Veröffentlichung ohne ein übereinstimmendes Datum einer letzten Version oder einer letzten Veröffentlichung spezifiziert ist, ist die Nutzung des Produkts für alle Daten der Version oder der Veröffentlichung nach jener spezifizierten autorisiert. Gleichermaßen wird dann, wenn entweder ein Datum für einen letzte Version oder ein Datum für eine letzte Veröffentlichung ohne ein übereinstimmendes Datum für eine erste Version oder ein Datum für eine erste Veröffentlichung spezifiziert ist, angenommen, daß die Nutzung des Produkts für alle Daten für eine Version oder eine Veröffentlichung vor jener spezifizierten autorisiert ist. Ausgeber sollten typischerweise nur ein Datum von entweder dem Datum für eine erste Version oder dem Datum für eine erste Veröffentlichung spezifizieren. Dies ist der Fall, daß vorausgesetzt wird, daß diese Felder sich typischerweise auf Ereignisse beziehen werden, die vor dem Moment einer Lizenzdatenausgabe auftragen. Somit sollte es normalerweise für den Ausgeber möglich sein, unzweifelhaft mit nur einem dieser zwei Felder anzugeben, welches die älteste Implementierung des Produkts ist, die zu autorisieren ist. Die Architektur läßt jedoch zu, daß beide Felder bei einer einzigen Produkt-Zugriffsberechtigung angewendet werden.
Das Signaturelement wird zum Bilden der Integrität und der Autorenschaft der Lizenzdaten angewendet, denen es zugeordnet ist. Ein Syntaxdiagramm für das Signaturelement ist in Fig. 41 gezeigt. Das Signaturenalgorithmenfeld identifiziert den registrierten Algorithmus, der zum Erzeugen der digitalen Signatur angewendet wurde. Signaturparameter sind die Werte der Parameter eines Algorithmus, die anzuwenden sind; die Notwendigkeit für und eine Syntax von Parametern wird durch jeden einzelnen Algorithmus bestimmt. Ein Signaturwert ist eine verschlüsselte Zusammenfassung der Informationen, an welche die Signatur angehängt ist; die Zusammenfassung wird mittels einer Einwege-Hashfunktion erzeugt, während das Verschlüsseln unter Anwendung des Geheimschlüssels des Unterzeichners (Ausgebers) ausgeführt wird.
Das Termenelement definiert ein Intervall, während welchem die Lizenzdaten gültig sind und ist in Syntaxdiagrammform in Fig. 42 gezeigt. Die Felder sind ein Anfangsdatum und ein Enddatum. Anfangsdatum identifiziert das erste Datum des Terms; wenn es nicht spezifiziert ist, werden die Lizenzdaten an jedem Datum vor dem Enddatum als gültig angesehen. Enddatum identifiziert das letzte Datum des Terms; wenn es nicht spezifiziert ist, werden die Lizenzdaten an jedem Datum nach dem Anfangsdatum als gültig angesehen. Während das Anfangsdatum immer als ein absolutes Datum entweder weggelassen oder spezifiziert ist, kann das Enddatum entweder absolut oder relativ sein. Wenn das Enddatum als relatives oder als "Intervall"-Datum spezifiziert ist und das Anfangsdatum weggelassen worden ist, wird das Datum einer Lizenzregistrierung als das effektive Anfangsdatum beim Berechnen des gültigen Terms der Lizenzdaten angewendet werden. Es sollte beachtet werden, daß das System den Mechanismus nicht spezifiziert, durch welchen Systemdaten durch Plattformunterstützungssystemkomponenten unterhalten werden. Statt dessen akzeptiert das System immer, daß eine Systemzeit zu ihm als richtig zurückgebracht wird. Somit hängt die Zuverlässigkeit des Managements von Lizenzdaten, die Terme spezifizieren, von der Zeitmanagemenifunktion der darunterliegenden Plattform ab.
Das Versionselement identifiziert eine Vierteile-Version des lizensierten Software- Produkts oder -Merkmals. Ein Syntaxdiagramm des Versionselements ist in Fig. 43 gezeigt. Die Schematiken jedes der vier Teile ist nicht detailliert, sondern es ist erforderlich, daß Hersteller, die zuzulassen wünschen, daß Versionsbereiche an Produktanwendungs-Zugriffsberechtigungen spezifiziert werden, sicherstellen, daß die vergleichende bzw. zusammenstellende bzw. prüfende Signifikanz der vier Teile beibehalten wird. Beim Vergleichen der Versionen wird zuerst Teil-1 betrachtet, dann Teil-2, dann Teil-3 und schließlich Teil-4. Teil-1 identifiziert eine Hauptmodifikation in bezug auf das Versionsobjekt. Teil-2 identifiziert eine Modifikation in bezug auf das Versionsobjekt, die weniger signifikant als eine Modifikation ist, die eine Änderung in bezug auf den Wert von Teil-1 verursachen würde. Teil-3 identifiziert eine Modifikation in bezug auf das Versionsobjekt, die weniger signifikant als eine Modifikation ist, die eine Änderung in bezug auf den Wert von Teil-2 verursachen würde. Teil-4 identifiziert eine Modifikation in bezug auf das Versionsobjekt, die weniger signifikant als eine Modifikation ist, die eine Änderung in bezug auf den Wert von Teil-3 verursachen würde.

FILTER

Ein wichtiges Merkmal ist die Anwendung von Filtern im Lizenz- Managementprogramm 11, einschließlich der Klientenschnittstelle 31 und der Managementschnittstelle 33. Ein Filter wird beispielsweise bei Auswahlelementen in der Lizenzdatenbank 23 angewendet. Verschiedene Auswahlmechanismen werden beim Herauspicken oder Durchführen von einem Nachschauen bei einer Datenbanktechnologie angewendet; Filter sind einer von ihnen. Die beim Lizenz- Managementsystem 11 der Fig. 1 angewendete Filtermaschine ist allgemein von einem bekannten Aufbau, mit der Ausnahme des Auswahlfilterelemententyps, wie es beschrieben wird, was zuläßt, daß eher ein komplexes als ein flaches Datenformat daraus ausgewählt wird. Das Merkmal, das von Wichtigkeit für dieses Ausführungsbeispiel ist, ist eher die Art zum Spezifizieren von Elementen als eine Eingabe zur Filterfunktion, als die Filterfunktion selbst. Somit ist unten eine Schablone zum Spezifizieren einer Eingabe zur Filtermaschine beschrieben. Dies ist so, als ob eine Form als Eingabe angewendet würde und zwar mit Leerstellen auf der Form;
durch eine Dateneingabe in bestimmte Leerstellen würden diese die ausgewählten Elemente sein, und die Leerstellen, die nicht aufgefüllt sind, würden "keine Sorge" sein.
Ein Beispiel des Klassenfilters ist eine Basis zum Auswählen oder Zurückweisen eines Objekts auf der Basis von Informationen in jenem Objekt. Zu irgendeinem Zeitpunkt hat ein Filter einen Wert relativ zu einem Objekt - dieser Wert ist falsch, wahr oder undefiniert. Das Objekt wird ausgewählt, wenn, und nur wenn, der Wert des Filters wahr ist. Diese konkrete Klasse hat die Attribute ihrer Superklasse- Objekt- und die in der Tabelle der Fig. 44 aufgelisteten spezifischen Attribute.
Ein Filter ist eine Ansammlung einfacher Filter und elementarer Filterelemente zusammen mit einer Bool'schen Operation. Der Filterwert ist undefiniert, wenn, und nur wenn, alle Komponentenfilter und Filterelemente undefiniert sind. Sonst hat das Filter einen Bool'schen Wert in bezug auf irgendein Objekt, der durch Bewerten jeder der verschachtelten Komponenten und durch Kombinieren ihrer Werte unter Anwendung einer Bool'schen Operation (Komponenten, deren Wert undefiniert oder ignoriert wird) bestimmt werden kann. Die Attribute, die für Filter spezifisch sind, wie es in Fig. 44 gezeigt ist, sind (a) Filterelemente, die eine Ansammlung von Behauptungen sind, wobei sich jede auf genau ein Attribut eines Objekts bezieht, (b) Filter, die eine Ansammlung einfacher Filter sind, und (c) Filtertyp, was der Typ des Filters ist, und zwar von einem der folgenden Werte: Und, Oder, Nicht.
Ein Fall bzw. ein Beispiel des Klassenfilterelements ist eine Komponente eines Filters. Es ist eine Behauptung über die Existenz oder Werte eines einzelnen Attributs eines Lizenzdatenobjekts oder Eins oder seiner Unterobjekte. Diese konkrete Klasse hat die Attribute ihrer Unterklasse-Objekt- und die spezifischen Attribute, die in der Tabelle der Fig. 45 aufgelistet sind.
Der Wert eines Filterelements ist undefiniert, wenn: (a) die Attributentypen unbekannt sind, oder (b) die Syntax des Übereinstimmungswerts nicht mit der Attributensyntax übereinstimmt, die für den Attributentyp definiert ist, oder (c) ein erforderliches Attribut nicht zur Verfügung gestellt ist. Die Attribute, die für ein Filterelement spezifisch sind, wie es in Fig. 45 gezeigt ist, sind (a) ein Filterelemententyp, der den Typ von Filterelement identifiziert und dadurch die Natur des Filters, und sein Wert muß einer von folgenden sein:
Gleichheit kleiner
Ungleichheit vorhanden
Größer oder gleich auswählen
Kleiner oder gleich Anfragekandidaten
Größer Simulieren einer Anfrage
(b) ein Attributentyp, der den Typ jenes Attributs identifiziert, dessen Wert oder Vorhandensein zu testen ist; der Wert von allen Attributen kann spezifiziert werden, (c) Übereinstimmungswert, was der Wert ist, der gegenüber dem Wert des Attributs anzupassen ist, (d) Filter, was das beim Bewerten eines ausgewählten Unterobjekts des aktuellen Objekts anzuwendende Filter identifiziert; das Filter wird ignoriert, wenn der Filterelemententyp nicht Auswahl ist oder wenn der spezifizierte Attributentyp im Objekt nicht vorhanden ist, und auf eine Bewertung des Filters hin wird der Wert eines Filterelements auf denjenigen des Filters eingestellt, (e) Anfangs-Unterkette, wenn vorhanden, ist dies die Unterkette zum Vergleichen gegenüber dem Anfangsteil des Werts des spezifizierten Attributentyps, (f) Unterkette, wenn vorhanden, ist die Unterkette(n) zum Vergleichen gegenüber allen Unterketten des Werts des spezifizierten Attributentyps, (g) schließliche Unterkette, wenn vorhanden, ist die Unterkette zum Vergleichen gegenüber dem Endteil des Werts des spezifizierten Attributentyps, und (h) Lizenzanfrage, wenn vorhanden, ist eine Lizenzanfrage gegenüber welchem die geeigneten Lizenzdatenobjekte bewertet werden sollten; dieses Attribut kann nur spezifiziert werden, wenn der Wert des Filterelemententyps entweder Anfragekandidaten oder Simulieren einer Anfrage ist.
Ein Beispiel für einen Aufzählungs-Syntaxfiltertyp identifiziert den Typ eines Filters. Sein Wert wird aus einem der folgenden ausgewählt: (a) Und bedeutet, daß das Filter die logische Verknüpfung seiner Komponenten ist; das Filter ist wahr, bis irgendeines der verschachtelten Filter oder Filterelemente falsch ist, oder wenn es keine verschachtelten Komponenten gibt, ist das Filter wahr; (b) Oder bedeutet, daß das Filter die logische Disjunktion seiner Komponenten ist; das Filter ist falsch, bis irgendeines der verschachtelten Filter oder Filterelemente wahr ist oder dann, wenn es keine verschachtelten Komponenten gibt, ist das Filter falsch; (c) Nicht bedeutet, daß das Ergebnis des Filters umgekehrt ist; es muß genau ein verschachteltes Filter oder Filterelement geben, und das Filter ist wahr, wenn das umhüllte bzw. eingeschlossene Filter bzw. Filterelement falsch ist, und ist falsch, wenn das eingeschlossene Filter oder Filterelement wahr ist.
Ein Beispiel für einen Aufzählungs-Syntax-Filterelemententyp identifiziert den Typ eines Filterelements. Sein Wert wird aus einem der folgenden ausgewählt: (a) Gleichheit, was bedeutet, daß das Filterelement wahr ist, wenn das Objekt wenigstens ein Attribut des spezifizierten Typs enthält, dessen Wert gleich jene ist, der durch einen Übereinstimmungswert (gemäß der Gleichheitsübereinstimmungsregel in Kraft) spezifiziert ist, und ist sonst falsch; (b) Ungleichheit, was bedeutet, daß das Filterelement wahr ist, wenn das Objekt wenigstens ein Attribut des spezifizierten Typs enthält, dessen Wert nicht gleich demjenigen ist, der durch den Übereinstimmungswert (gemäß der Gleichheitsübereinstimmungsregel in Kraft) spezifiziert ist, und sonst falsch; (c) Größer oder Gleich, was bedeutet, daß das Filterelement wahr ist, wenn das Objekt wenigstens ein Attribut des spezifizierten Typs enthält, dessen Wert gleich oder größer als dem Wert ist, der durch den Übereinstimmungswert (gemäß der Übereinstimmungsregel in Kraft) spezifiziert ist, und sonst falsch; (d) Kleiner oder Gleich, was bedeutet, daß das Filterelement wahr ist, wenn das Objekt wenigstens ein Attribut des spezifizierten Typs enthält, dessen Wert gleich oder kleiner als der Wert ist, der durch den Übereinstimmungswert (gemäß der Übereinstimmungsregel in Kraft) spezifiziert ist, und sonst falsch; (e) Größer, was bedeutet, daß das Filterelement wahr ist, wenn das Objekt wenigstens ein Attribut des spezifizierten Typs enthält, dessen Wert größer als der Wert ist, der durch den Übereinstimmungswert (gemäß der Übereinstimmungsregel in Kraft) spezifiziert ist, und sonst falsch; (f) Kleiner, was bedeutet, daß das Filter wahr ist, wenn das Objekt wenigstens ein Attribut des spezifizierten Typs enthält, dessen Wert kleiner als der Wert ist, der durch den Übereinstimmungswert (gemäß der Übereinstimmungsregel in Kraft) spezifiziert ist, und sonst falsch; (g) Vorhanden, was bedeutet, daß das Filterelement wahr ist, wenn das Objekt wenigstens ein Attribut des spezifizierten Typs enthält, und sonst falsch; (h) Auswahl, was bedeutet, daß das Filterelement wahr ist, wenn das Objekt wenigstens ein Attribut des spezifizierten Typs enthält, der eine Objektsyntax hat, und wenn das Filter gegenüber den Attributen von jenem Objekt bewertet wird, ist das Filter wahr, und sonst falsch; (i) Anfragen von Kandidaten, was bedeutet, daß das letzte Element wahr ist, wenn das Objekt gegenüber dem es bewertet wird, eines ist, das zum Bereitstellen einiger oder aller der Einheiten angewendet werden könnte, die durch die spezifizierte Lizenzanfrage angefragt sind; die Bewertung wird unabhängig von irgendwelchen ausstehenden Zuteilungen oder Vor-Zuteilungen durchgeführt; und (j) Simulieren einer Anfrage, was bedeutet, daß das Filterelement wahr ist, wenn das Objekt, gegenüber welchem es bewertet wird, eines ist, das zum Liefern eini ger oder aller der Einheiten angewendet werden würde, die durch spezifizierte Lizenzanfrage angefragt werden.
Die Filterelemententypen für ein Anfragen von Kandidaten und ein Simulieren einer Anfrage sind von speziellem Nutzen beim Testen und beim Herstellen eines Prototyps von Systemen durch einen Lizenz-Manager an einem Ort eines Lizenznehmers. Beispielsweise kann der Lizenz-Manager die Auswirkung potentieller Zuordnungen simulieren, die Auswirkung einer Population gewisser Typen auf einem Netzwerk, etc.
Als Beispiel zeigt Fig. 46, wie ein Filter aufgebaut sein kann, um "Alle von Digital für das Produkt 'Amazing Graphics System' ausgegebenen Produktanwendungs- Zugriffsberechtigungen, die eine aufrufende Zugriffsberechtigung für Digitals 'Amazing Database' Product" zu identifizieren. Dieses Beispiel ist im internationalen Standardformat, auf das als X.409 Bezug genommen wird, wie es oben angegeben ist.
Filter können auch bei einer Anfragezuteilung angewendet werden, die bei einer Anfrageerweiterung spezifiziert werden, wie es oben erklärt ist. Das bedeutet, daß ein Filter eines der optionalen Elemente in einer Anfrageerweiterung ist. Beispielsweise dann, wenn ein Anwender wünschte, eine Version von WordPerfect mit einer französischsprachigen Erweiterung anzuwenden, und es eine Version mit und ohne Netzwerkzugriff gäbe, würde seine Anfragezuteilung eine Anfrageerweiterung haben, die ein Filter für "Französisch" im Tokenfeld spezifizierte. Auf diese Weise kann ein Produkt sich selbst ausführlicher beschreiben. Das Filter in der Anfrageerweiterung kann ein erforderliches Filter oder ein bevorzugtes Filter sein, was die Bedeutung des Merkmals hat, das beispielsweise "Französisch" entweder absolut nötig oder lediglich das bevorzugte ist.

Claims

1. Verfahren zum Managen einer Anwendung lizensierter Software-Elemente (17), wobei die Software-Elemente auf einem Computersystem (16) einzeln ausführbar sind oder einzeln auf sie durch das Computersystem zugegriffen werden kann, wobei das Computersystem einen Prozessor (10) und einen oder mehrere Knoten (16) enthält, und das Verfahren folgende Schritte aufweist:

Unterhalten eines Speichers (23) von Lizenz-Zugriffsberechtigungen (35) für die Software-Elemente durch den Prozessor (10); wobei jede Lizenz- Zugriffsberechtigung eine Anzeige einer Lizenz-Managementpolice für ein Software-Element enthält, wobei die Anzeige eine Vielzahl von Gruppen von Police-Komponenten (43-46) hat, wobei die Gruppen von Police- Komponenten spezifizierte beschränkte Rechte zum Ausführen der oder zum Zugreifen auf die Software-Elemente durch die Knoten gewährt; wobei die spezifizierten beschränkten Rechte Gruppen von Beschränkungen wenigstens in bezug auf einen Kontext (44) einer Anwendung und einer Dauer (45) einer Anwendung eines Software-Elements enthält; wobei die Police-Komponenten jeder Gruppe Alternativen in bezug auf Rechte zum Ausführen der oder zum Zugreifen auf die Software-Elemente durch einen oder mehrere Knoten im Computersystem zur Verfügung stellen; wobei die Lizenz-Zugriffsberechtigungen durch den Prozessor (10) zur Speicherung im Speicher (23) von einem Lizenzgeber (25, 28) empfangen werden, der extern zum Prozessor ist; und

Zugreifen auf den Speicher durch den Prozessor unter Verwendung von Management-Funktionen, die auf dem Prozessor ausgeführt werden, um eine Lizenz-Zugriffsberechtigung im Speicher zu identifizieren, und um im Speicher eines oder mehrere der spezifizierten beschränkten Rechte der Police-Komponenten der identifizierten Lizenz-Zugriffsberechtigung zu modifizieren.

2. Verfahren nach Anspruch 1, das folgende Schritte enthält:

Senden einer Anfrage von einem der Knoten (16) zum Prozessor (10) durch einen Anwender eines der Software-Elemente (17), um eine Erlaubnis zum Anwenden des Software-Elements zu erhalten; wobei die Anfrage den Anwender und das Software-Element identifiziert; und

Zugreifen auf den Speicher durch den Prozessor, um Informationen von der Lizenz-Zugriffsberechtigung für das Software-Element zu erhalten, in Antwort auf die Anfrage, und Vergleichen der Identifikation des Anwenders und des Software-Elements mit den Informationen, um eine Gewährung oder eine Zurückweisung der Anfrage zum Senden durch den Prozessor zum Anwender zu erzeugen.

3. Verfahren nach Anspruch 2, wobei die Anfrage in der Form eines entfernten Verfahrens-Aufrufs ist, und die zum Anwender gesendete Gewährung oder Zurückweisung eine Rücksprung des Verfahrens-Aufrufs ist.

4. Verfahren nach Anspruch 1, wobei die Police-Komponenten ein Beendigungs- Datum (40) enthalten, und die Management-Funktionen das Beendigungs- Datum zu einem früheren Beendigungs-Datum modifizieren können.

5. Verfahren nach Anspruch 1, wobei die Police-Komponenten ein Recht eines Übertragens (48) eines Rechts enthalten, um die Anfragen zu einem anderen Server zu gewähren, und die Management-Funktionen das Recht des Übertragens modifizieren können, um das Recht des Übertragens zu entfernen.

6. Verfahren nach Anspruch 1, das, in Zusammenhang mit der Lizenz- Zugriffsberechtigung (35), ein Speichern einer Anzahl von Managementattributen (40-51) enthält, und wobei die Management- Funktionen die Managementattribute modifizieren können.

7. Verfahren nach Anspruch 1, wobei die spezifizierten beschränkten Rechte eine Gruppe (44) von Beschränkungen im Kontext mit einer Anwendung eines Software-Elements enthält, wobei die Gruppe eine Identifikation eines Netzwerks, eines Anwendernamens, eines Prozesses, eines Betriebssystems und einer Plattform enthält.

8. System, das auf einem Computer ausführbar ist, zum Managen einer Anwendung einer Vielzahl lizensierter Softwareprodukte (17), wobei die Softwareprodukte vom System einzeln betreibbar sind, wobei das System folgendes aufweist:

eine Einrichtung (11), die auf dem Computer (10) ausführt, zum Unterhalten eines Speichers (23) von Lizenzdokumenten (35), und zwar ein Dokument für jedes Produkt (17), und zum Zugreifen auf ihn; wobei jedes Lizenzdokument im Speicher eine Anzeige einer Lizenzpolice enthält, wobei die Anzeige eine Vielzahl von Gruppen von Police-Komponenten (43-46) hat; wobei die Police-Komponenten spezifizierte beschränkte Rechte zum Anwenden der Softwareprodukte gewährt; wobei die spezifizierten beschränkten Rechte wenigstens Beschränkungen in bezug auf einen Kontext (44) einer Anwendung und eine Dauer (45) einer Anwendung eines Softwareprodukts enthält; wobei die Gruppe der Police-Komponenten unterschiedliche Alternativen für die beschränkten Rechte zur Verfügung stellen; und

eine Managementschnittstelle (33), die auf dem Computer (10) ausführbar ist, zum Zugreifen auf den Speicher (23), um ausgewählte der Police-Komponenten eines identifizierten Lizenzdokuments zu modifizieren.

9. System nach Anspruch 8, das folgendes enthält:

eine Einrichtung (18), die auf einem Prozessor (16) ausführbar ist, zum Senden einer Anfrage von einem Anwender eines der Produkte (17), um eine Erlaubnis zum Anwenden des Produkts zu erhalten; wobei die Anfrage den Anwender und das Produkt identifiziert; und

eine Einrichtung, die auf dem Computer (10) ausführbar ist, zum Zugreifen auf den Speicher (23), um Informationen aus dem Lizenzdokument für das Produkt zu erhalten, in Antwort auf die Anfrage, und zum Vergleichen der Identifikation des Anwenders und des Produkts mit den Informationen, und mit durch die Police-Komponenten auferlegten Einschränkungen, um eine Gewährung oder eine Zurückweisung der Anfrage zu erzeugen und eine Gewährung oder eine Zurückweisung zum Anwender zu senden.

10. System nach Anspruch 9, wobei die Einrichtung zum Unterhalten und die Einrichtung zum Zugreifen und zum Senden zum Anwender alle bei einem Server (10, 13) auf einem verteilten Netzwerk angeordnet sind, und die Einrichtung zum Senden einer Anfrage bei einem Anwenderknoten (16) auf dem Netzwerk angeordnet ist.

11. System nach Anspruch 10, wobei das Lizenzdokument (35) eine Datenanordnung ist, die als Produktanwendungs-Zugriffsberechtigung spezifiziert ist, und die Produktanwendungs-Zugriffsberechtigung durch den Server von einem Lizenzgeber (25, 26, 28) empfangen wird.

12. System nach Anspruch 8, wobei die Police-Komponenten ein Beendigungs- Datum (40) enthalten, und die Management-Funktionen das Beendigungs- Datum zu einem früheren Beendigungs-Datum modifizieren können.

13. System nach Anspruch 8, das eine Einrichtung zum Speichern einer Anzahl von Managementattributen (40-51), in Zusammenhang mit der Lizenz- Zugriffsberechtigung, enthält, und wobei die Management-Funktionen die Managementattribute modifizieren können.