DE60212969T2

DE60212969T2 - Verfahren und vorrichtung zum verfolgen des status eines betriebsmittels in einem system zur verwaltung der benutzung der betriebsmittel

Info

Publication number: DE60212969T2
Application number: DE60212969T
Authority: DE
Inventors: Xin Los Angeles Wang; Thomas Culver City DEMARTINI; Eddie Rancho Palos Verdes CHEN; P. Charles Darien GILLIAM; Manuel Downey HAM; Guillermo Torrance Lao; Michael Downey RALEY; Thahn Huntington Beach TA; Bijan Germantown TADAYON
Original assignee: Contentguard Holdings Inc
Current assignee: Contentguard Holdings Inc
Priority date: 2001-06-07
Filing date: 2002-06-07
Publication date: 2006-11-23
Anticipated expiration: 2022-06-08
Also published as: KR20030096248A; EP1399796A2; WO2002101493A2; WO2002101975A1; ATE332527T1; DE60212969D1; CA2432317A1; JP2004530986A; EP1399796A4; JP5095854B2; EP1399796B2; DE60212969T3; CA2432317C; JP2009015875A; MXPA03011332A; CA2432283A1; KR100604715B1; WO2002101493A3; JP4520736B2; KR100621318B1

Description

Ein Teil der Offenbarung dieses Patentdokumentes enthält Material, das dem Urheberrecht unterliegt. Der Inhaber des Urheberrechts hat keine Einwände gegen die Faksimile-Ausgabe des Patentdokumentes oder der Patentoffenbarung durch jegliche Personen, wie dies in den Patentakten oder den Patentunterlagen des Patent- und Markenamtes festgelegt ist, er behält sich jedoch ansonsten sämtliche Urheberrechte vor.
Die Erfindung betrifft das Verwalten von Ressourcen in einem Computersystem. Im Besonderen betrifft die Erfindung ein Verfahren und eine Vorrichtung zum Verfolgen des Status von geschützten Ressourcen, wie beispielsweise von digitalem Inhalt, sowie Nutzungsrechte, die den geschützten Ressourcen zugeordnet sind.
Eines der wesentlichen Probleme, welches der umfassenden Verteilung von digitalen Arbeiten (das heißt, von Dokumenten oder anderer Inhalt in Formen, die von Computern lesbar sind) über elektronische Einrichtungen und insbesondere über das Internet entgegensteht, ist die derzeit nicht vorhandene Möglichkeit, die geistigen Eigentumsrechte der Inhaber der Inhalte während der Verteilung und der Nutzung der digitalen Arbeiten durchzusetzen. Anstrengungen zur Lösung dieses Problems wurden als „Intellectual Property Rights Management" („IPRM"), „Digital Property Rights Management" („DPRM"), „Intellectual Property Management" („IPM"), „Rights Management" („RM") und „Electronic Copyright Management" („ECM") bezeichnet und werden in dieser Erfindung insgesamt als „Digital Rights Management" („DRM") [Verwaltung digitaler Rechte] bezeichnet. Es gibt eine Reihe von Sachverhalten, die bei der Ausführung eines DRM-Systems berücksichtigt werden müssen. So sollte sich beispielsweise mit der Authentifizierung, der Autorisierung, der Abrechung, der Bezahlung und dem Finanzclearing, der Spezifizierung der Rechte, der Verifizierung der Rechte, der Durchsetzung der Rechte und mit Problemen hinsichtlich des Dokumentenschutzes befasst werden. Die U.S.-Patente 5.530.235, 5.634.012, 5.715.403, 5.638.443 und 5.629.940 offenbaren DRM-Systeme, die sich mit diesen Sachverhalten befassen.
Beispielsweise offenbart das U.S.-Patent 5.634.012 ein System zum Steuern der Verteilung von digitalen Dokumenten. Jede Rendering-Vorrichtung verfügt über eine dazugehörige Speichervorrichtung. Eine vorgegebene Reihe von Nutzungstransaktionsschritten definiert ein Protokoll, das von den Speichervorrichtungen verwendet wird, um die Nutzungsrechte, die zu einem Dokument gehörigen, durchzusetzen. Nutzungsrechte bestehen mit dem Inhalt des Dokumentes. Die Nutzungsrechte zeigen eine Vielzahl von Benutzungsarten des Inhaltes, wie beispielsweise ledigliches Ansehen, einmaliges Benutzen, Vertrieb und Ähnliches, an. Das Erfüllen von Vorbedingungen, wie beispielsweise das Bezahlen einer Gebühr, das Prüfen der Identität oder andere Bedingungen, kann vor dem Gewähren des Zugangs zu dem Inhalt in Übereinstimmung mit den Nutzungsrechten erforderlich sein. Sobald die Vorbedingungen erfüllt sind, wird der Zugang zu dem Inhalt gewährt. Das Konzept des bedingten Zugangs ist bei den Anwendungen für die Zugangskontrolle gut bekannt. Beispielsweise ist bekannt, dass der Zugang zu Netzwerkressourcen nach der Eingabe des Login-Namens und des Passwortes gewährt wird.
Das Konzept des bedingten Zugangs bildet sowohl für die Zugangskontrolle als auch für die DRM-Systeme eine Grundlage. Eine typische Vorbedingung, das heißt, eine Bedingung zum Gewähren von Zugang, wird durch eine Liste von berechtigten Benutzern zusammen mit einer Reihe von Zugangsrechten und -bedingungen für eine gegebene Ressource definiert. Vorbedingungen, die einer gegebenen Ressource zugeordnet sind, können als Ressourcen definiert werden, die bestimmten Benutzern zugeordnet sind. Dies ist als „Role-Based" Access Control (rollenbasierte Zugangskontrolle) bekannt. Vorbedingungen können auch durch Regeln in einem Prozess, der als „Rule Based" Access Control (regelbasierte Zugangskontrolle) bekannt ist, definiert werden. Beide Typen von Vorbedingungen werden als eine Zugangssteuerungsliste dargestellt, die eine Reihe von Ressourcen und Regeln ist, die in einigen Sprach- und Datenstrukturen definiert ist.
Der bedingte Zugang wird typischerweise von den meisten Systemen als ein Autorisierungsprozess implementiert, in dem einem Prinzipal (beispielsweise einer Person, einem System oder einem Prozess) Zugang zu einer geschützten Ressource gewährt wird, nachdem bestimmte Bedingungen erfüllt und/oder verifiziert wurden.
EP-A-0 818 748 (MURAKOSHI HIROMASA) 14. Januar 1998 (1998-01-14) offenbart ein Softwareverwaltungssystem und ein entsprechendes Verfahren zum Verwalten des Betriebs eines verwalteten Softwareproduktes. Wenn eine Verwaltungszielfunktion ausgeführt wird, wird Bezug auf einen Stromverbrauchswert genommen, und wenn der Wert Null oder größer ist, kann die Funktion ausgeführt werden. Der Stromverbrauchswert wird verringert, da die Funktion ausgeführt wird, um den Betrieb des verwalteten Softwareproduktes auf einem Gerät des Benutzers zu beschränken.
Es ist eine Aufgabe der vorliegenden Erfindung, ein verbessertes System und ein Verfahren zum Verwalten einer geschützten Ressource in einem System zum Gewähren von Zugang zu einer geschützten Ressource bereitzustellen.
Diese Aufgabe wird durch den Gegenstand in den unabhängigen Patentansprüchen 1 und 10 gelöst.
Bevorzugte Ausführungsbeispiele werden durch den Gegenstand der abhängigen Patentansprüche definiert.
Ein erster Aspekt der Erfindung ist ein System zum Verwalten des Status einer geschützten Ressource in einem System zum Gewähren von Zugang zu einer geschützten Ressource gemäß der Nutzungsrechte. Die Nutzungsrechte umfassen Statusvariablen, die einen Status einer zugehörigen geschützten Ressource anzeigen. Das System umfasst eine geschützte Ressource, welcher ein Nutzungsrecht zugeordnet ist, das zumindest teilweise durch eine Statusvariable definiert ist, ein Ressource-Verwaltungsgerät, das mit der Ressource verbunden ist, um die Benutzung der Ressource zu steuern, indem das Nutzungsrecht durchgesetzt wird, einen Status-Controller, der eingerichtet ist, einen Wert der Statusvariable zu verfolgen, ein Rahmenwerk für eine Schnittstelle (interface framework), das eingerichtet ist, eine Nachricht von dem Ressource-Verwaltungsgerät zu empfangen, welche sich auf die Statusvariable bezieht, und das eingerichtet ist, den Status-Controller zu laden und den Status-Controller anzuweisen, den Wert der Statusvariable gemäß der Nachricht zu verändern.
Ein zweiter Aspekt der Erfindung ist ein Verfahren zum Verwalten des Status einer geschützten Ressource in einem System zum Gewähren von Zugang zu einer geschützten Ressource gemäß der Nutzungsrechte, wobei die Nutzungsrechte eine Statusvariable umfassen, die einen Status einer zugehörigen Ressource anzeigt. Das Verfahren umfasst das Übertragen einer Nachricht bezüglich der Statusvariable von einem Ressource-Verwaltungsgerät zu einem Rahmenwerk für eine Schnittstelle (interface framework), wobei das Ressource-Verwaltungsgerät mit der geschützten Ressource verbunden ist, um die Benutzung der geschützten Ressource zu steuern, indem das Nutzungsrecht durchgesetzt wird, wobei ein Status-Controller in das Rahmenwerk gela den wird, der eingerichtet ist, den Wert der Statusvariable zu verfolgen und den Status-Controller anzuweisen, den Wert der Statusvariable gemäß der Nachricht zu verändern.
Die Erfindung wird anhand eines bevorzugten Ausführungsbeispiels sowie anhand der angehängten Zeichnungen beschrieben, wobei:
1 ein Blockdiagramm einer Computerarchitektur des bevorzugten Ausführungsbeispiels ist.
2 ist eine schematische Darstellung der Status eines herkömmlichen Zugangskontrollmodells.
3 ist eine schematische Darstellung der Status des bevorzugten Ausführungsbeispiels.
4 ist eine schematische Darstellung einer Bedingung/eines Rechtes des bevorzugten Ausführungsbeispiels.
5 ist eine schematische Darstellung eines Status der Rechte des bevorzugten Ausführungsbeispiels.
6 ist eine schematische Darstellung der Status-Verwaltungseinrichtung des bevorzugten Ausführungsbeispiels mit Elementen des Rahmenwerks für den Status der Rechte, und
7 ist eine schematische Darstellung der Status-Verwaltungseinrichtung mit Elementen der Ressource-Verwaltungseinrichtung.
Verschiedene Typen von Ressourcen erfordern verschiedene Typen von Bedingungen sowie verschiedene Mechanismen, um sie vor unberechtigter Benutzung zu schützen. In dem bevorzugten Ausführungsbeispiel sind die Bedingungen und die Rechte Teil des gesamten Lebenszyklus der geschützten Ressourcen. Das heißt, dass die Bedingungen der Rechte nicht nur vor dem Gewähren des Zugangs evaluiert werden, sondern auch während der tatsächlichen Benutzung der Ressource. Darüber hinaus sind die Bedingungen sowohl der geschützten Ressource als auch dem Status der geschützten Ressource zugeordnet. Das Zuordnen von Bedingungen zu den verschiedenen Status einer geschützten Ressource bietet den Inhabern der Inhalte oder den Diensteanbietern eine flexible Möglichkeit, die verschiedenen Typen von Ressourcen zu schützen. Ressourcen können digitaler Inhalt, Hardware, Softwareprogramme, Speicherplatz, Waren, Dienste (einschließlich Internetdienste), Zeit, Gebühren, Nutzungsrechte oder eine Lizenz sein.
Die Nutzungsrechte zeigen Benutzungsarten an. Benutzungsarten können beispielsweise die Fähigkeit einschließen, ein Element in einer bestimmten Art und Weise für einen bestimmten Zeitraum zu benutzen. Des Weiteren können Nutzungsrechte Übertragungsrechte anzeigen, wie beispielsweise Vertriebsrechte, und sie können anderen Nutzungsrechte gewähren oder die Ableitung der Nutzungsrechte genehmigen. In dem bevorzugten Ausführungsbeispiel sind Bedingungen zu den Rechten zugeordnet, um die Benutzungsarten der Ressourcen zu definieren. Aus diesem Grund werden die Bedingungen und Rechte in dem bevorzugten Ausführungsbeispiel als ein Ganzes betrachtet. Bedingungen und Rechte können jedoch auch getrennt voneinander vorkommen.
Das bevorzugte Ausführungsbeispiel verifiziert und validiert die Bedingungen der Rechte vor, während und nach der Benutzung oder dem Verbrauch der geschützten Ressourcen. Rechte und dazugehörige Bedingungen können als ein Status repräsentiert werden, so dass der aktuelle Status und der Verlauf jedes Rechts aufgezeichnet und später verwendet werden kann. „Statusvariablen" verfolgen möglicherweise dynamische Bedingungen. Statusvariablen sind Variablen mit Werten, die den Status einer Ressource oder anderer dynamischer Bedingungen repräsentieren. Statusvariablen können verfolgt werden, und der Wert der Statusvariablen kann in einer Bedingung verwendet werden. Beispielsweise kann ein Nutzungsrecht als eine Ressource das Recht sein, sich den Inhalt anzusehen, und eine Bedingung kann sein, dass keine anderen Benutzer in dem Netzwerk eingeloggt sind, wenn das Nutzungsrecht ausgeübt wird. In diesem Beispiel wird, wenn der Wert des entsprechenden Status anzeigt, dass andere Benutzer eingeloggt sind, die Bedingung nicht mehr erfüllt, und der Inhalt kann nicht angesehen werden, oder Ansehen wird beendet.
1 illustriert die Computerarchitektur 10 des bevorzugten Ausführungsbeispiels. Die Bedingungen 80 werden im Folgenden ausführlich beschrieben und können mit der Erstellungsanwendung 70 erstellt werden, die zu dem Händler eines Artikels, zu einem Anbieter von Inhaltsdiensten (Content Service Provider), zu einem Unternehmensmanager oder zu jeglichen anderen Parteien gehört, die den Zugang zu Ressourcen, wie beispielsweise digitalem Inhalt, steuern wollen. Eine universelle Sprache, wie beispielsweise XrML^TM, kann verwendet werden, um die Bedingungen 80 zu spezifizieren. Die Bedingungen können jedoch auf jegliche Art und Weise spezifiziert werden. Ein Benutzer arbeitet in der Client-Umgebung 30, die einen Computer oder andere zu einem Benutzer zugehörige Geräte umfasst. Die Softwareanwendung 12, wie beispielsweise eine Rendering Engine (Programmmodul zur Darstellung des HTML-Codes einer Webseite) oder eine andere Anwendung, kann in der Client-Umgebung 30 installiert werden. Die Status-Verwaltungseinrichtung 40 steuert den Zugang zu einer geschützten Ressource/zu geschützten Ressourcen 100 und einer abgeleiteten Ressource/abgeleiteten Ressourcen 100a in einer Art und Weise, die im Folgenden beschrieben wird.
Die Status-Verwaltungseinrichtung 40, eine Computereinrichtung in dem bevorzugten Ausführungsbeispiel, befasst sich mit Sicherheitsaspekten hinsichtlich des Zugangs zu der Ressource 100 und zu der abgeleiteten Ressource 100a. Die Status-Verwaltungseinrichtung 40 kann insbesondere Nachrichten durch das Prüfen und das Validieren von Signaturen, wie beispielsweise einer kryptographischen Signatur, oder anderen identifizierenden Eigenschaften der Nachrichten in einer bekannten Art und Weise authentisieren. Die Status-Verwaltungseinrichtung 40 umfasst die Ressource-Verwaltungseinrichtung 42 und den Validierer für Bedingungen (condition validator) 44. Die Ressource-Verwaltungseinrchtung 42 ist für das Registrieren der Ressource, das Transformieren der Ressource und das Beenden der Ressource zuständig. „Transformation" bezieht sich auf das Ableiten der abgeleiteten Ressource 100a von der Ressource 100. Wie in 7 dargestellt, wird die Transformation durch das Ressourcen-Transformationsmodul 48 der Ressource-Verwaltungseinrichtung 42 ausgeführt. In dem Fall beispielsweise, in dem die Ressource eine verschlüsselte Datei ist, die ein Bild oder Ähnliches darstellt, könnte die abgeleitete Ressource 100a das deutliche Bild selbst und die Adresse des Speichers, in dem das Bild gespeichert ist, umfassen. Während der Registrierung der Ressource wird die Speicheradresse, unter der das Bild gespeichert ist, durch den Ressourcenspeicher 46 der Ressource-Verwaltungseinrichtung 42 aufgezeichnet, so dass jeglicher Zugang zu diesem Speicher, das heißt, abgeleitete Ressource 100a, verfolgt werden kann. Darüber hinaus können Verfolgungsmarkierungen (wie beispielsweise Wasserzeichen) in das Bild eingefügt werden, so dass es jederzeit verfolgt werden kann.
Der Validierer für Bedingungen (condition validator) 44 überprüft die festgelegten Bedingungen und verwaltet den Status der Rechte", das heißt, eine Zusammenstellung der aktuellen Werte der Statusvariablen für ein gegebenes Recht, wie im Folgenden beschrieben. Der Validierer für Bedingungen (condition validator) 44 kommuniziert, wie im Folgenden ausführlicher beschrieben, mit der Ressource-Verwaltungseinrichtung 46, um die abgeleitete Ressource 100a zu steuern. Wenn der aktuelle Status des Rechts 44b nicht mehr gültig ist, das heißt, nicht zu einem autorisierten Status der Rechte 44a korrespondiert, weist der Validierer für Bedingungen (condition validator) 44 die Ressource-Verwaltungseinrichtung 42 an, sämtliche der abgeleiteten Ressourcen 100a zu löschen (oder zu deaktivieren) oder die Anwendung 12 zu benachrichtigen, dass die Benutzung der abgeleiteten Ressourcen 100a, wie im Folgenden ausführlicher beschrieben, nicht mehr zulässig ist. Die Status-Verwaltungseinrichtung 40 umfasst des Weiteren das Rahmenwerk für den Status der Rechte 20, den Status-Controller 22 und den Statusvalidierer 24, die alle im Folgenden ausführlich beschrieben werden.
Der Zugang zu der geschützten Ressource 100 basiert auf den Bedingungen 80. Dieser Bedingungstyp wird als eine Zugangsbedingung oder „Vorbedingung" bezeichnet. Durch das Zuordnen der Bedingungen sowohl zu der Ressource 100 als auch zu dem Status der Ressource 100 ist es möglich, die Ressource 100 in verschiedenen Phasen während ihres Lebenszyklus zu schützen. Die Ressource 100 kann geschützt werden, bevor einem Benutzer der Zugang gewährt wird, und wenn der Zugang gewährt ist, kann die Ressource 100 während der tatsächlichen Benutzung der Ressource 100 und nach der Benutzung der Ressource 100 geschützt werden. Die Bedingungen 80, die dem gesamten Lebenszyklus der geschützten Ressource zugeordnet sind, können durch die Verwendung einer Grammatik einschließlich Datenstrukturen, Regelsätzen oder einer Sprache, wie beispielsweise XrML^TM, ausgedrückt werden. Das bevorzugte Ausführungsbeispiel verwendet XrML^TM als die Sprache zur Darstellung der Bedingungen.
Um die Ressource 100 zu schützen, können die Bedingungen 80 der Ressource 100 selbst oder sämtlichen anderen Ressourcen – entweder materiell oder immateriell – zugeordnet werden, einschließlich solchen Ressourcen, die jegliche ausführenden Umgebungen bilden, wie beispielsweise eine Anwendung 12 der Client-Umgebung 30, von der aus auf die geschützte Ressource 100 zugegriffen und diese verwendet werden kann.
Die Bedingungen 80 können die Identität eines Benutzers oder einer Benutzergruppe sein, denen Zugang als Prinzipal gewährt wird, und die die geschützte Ressource verwenden. Beispiele der Bedingungen 80 werden im Folgenden als in der XrML^TM-Sprache dargestellt beschrieben. Beispiel A stellt eine Bedingung dar, die zu einem Prinzipal „Edgar" zugeordnet ist, dem das Recht gewährt wird, den geschützten digitalen Inhalt „XrML Book" „anzusehen". Beispiel B drückt eine Bedingung aus, die zu einer Gruppe von Prinzipalen zugeordnet ist, das heißt, zu sämtlichen Personen, die in die Kategorie „ContentGard employee" fallen, denen das Recht gewährt wird, die geschützte digitale Arbeit „XrML Book" zu drucken.
Beispiel A:
Beispiel B:
Die Bedingungen 80 können Bedingungen für Prinzipale sein, die bestimmte Eigenschaften besitzen müssen, wie beispielsweise einen bestimmten Titel oder Rechte, wie beispielsweise eine Sicherheitsunbedenklichkeitsbescheinigung. Beispiel C stellt die Bedingung dar, dass der Prinzipal ein Managerabzeichen besitzen müssen.
Beispiel C:
Die Bedingungen 80 können Zeitintervalle für den Zugang zu einem geschützten Element sein. Das folgende Beispiel D stellt die Bedingungen dar, dass der Schlüsselinhaber „Edgar", als ein Prinzipal, sich den Inhalt „XrML Book" nicht vor dem 05/29/2002 und nicht nach dem 05/29/2003 ansehen kann.
Beispiel D:
Die Bedingungen 80 können sich auf den physischen Ort des Prinzipalen oder die Ressource beziehen, die verwendet wird, um auf den Inhalt zuzugreifen. Das folgende Beispiel E stellt die Bedingung dar, dass jede Person, die sich derzeit in den USA aufhält, den Inhalt „XrML Book" ausdrucken kann.
Beispiel E:
Die Bedingungen 80 können eine Gebühr spezifizieren, die ein Prinzipal bezahlen muss, um Zugang zu erhalten. Das folgende Beispiel F stellt die Bedingung dar, dass jedermann den Inhalt „XrML Book" nach dem Bezahlen einer Gebühr von USD 3,10 ausdrucken kann. Das folgende Beispiel G stellt die Bedingung dar, dass jedermann nach dem Bezahlen einer Gebühr von USD 3,10 für jeden Ausdruck den Inhalt „XrML Book" ausdrucken kann. Das folgende Beispiel N stellt die Bedingung dar, dass sich jedermann den Inhalt „XrML Book" nach dem Bezahlen einer Gebühr von USD 10,00 pro Stunde Zugriffszeit ansehen kann.
Beispiel F:
Beispiel G:
Beispiel H:
Das folgenden Beispiel I stellt die Bedingung dar, das jedermann den Inhalt drucken kann, die Ausübung des Rechtes zum Drucken wird jedoch von einem Verfolgungsdienst vor dem Drucken verfolgt werden.
Beispiel I:
Die Bedingungen 80 können ebenfalls Bedingungen in dem System sein, in dem die Ressource 100 verbraucht wird. Beispielsweise kann die Bedingung 80 fordern, dass das System über einen autorisierten Sicherheitsmechanismus oder weitere spezifische Hardware oder Software verfügt, oder dass nur eine bestimmte Anzahl von Benutzern eingeloggt ist.
Die Bedingungen 80 können die Speichervorrichtung oder eine andere Vorrichtung spezifizieren, in der die Ressource 100, wie beispielsweise der Inhalt, gespeichert ist. Die Bedingungen 80 können sich auf die Genehmigungsbestätigung beziehen, die der Prinzipal vor dem Benutzen der geschützten Ressourcen 100 erhalten muss. Die Bedingungen 80 können eine Benachrichtigung vor und nach dem Benutzen der Ressource 100 erforderlich machen. Die Bedingungen 80 können vorhergehende Rechte in Bezug auf die geschützte Ressource 100 oder auf andere Ressourcen spezifizieren. Die Bedingungen 80 können ebenfalls auf andere Bedingungen 80, beispielsweise wie eine Bedingung zu verifizieren ist, auferlegt werden.
Die Bedingungen 80 sind selbstverständlich nicht auf die voranstehenden Beispiele beschränkt, sie können jedoch sämtliche Beschränkungen, Verpflichtungen oder Anforderungen sein, die einem Recht für eine geschützte Ressource 100 als eine Vorbedingung, als eine zugangszeitliche Bedingung, als eine Nachbedingung oder andere Bedingungen zugeordnet sind. Und obwohl die voranstehenden Beispiele unter Verwendung von XrML^TM dargestellt werden, sind die Bedingungen nicht auf oder durch XrML^TM beschränkt, sondern können auf eine beliebige Art und Weise dargestellt werden.
4 stellt die Bedingungen 80 in Übereinstimmung mit dem bevorzugten Ausführungsbeispiel schematisch dar. Die Bedingung 80 schließt die Ressourcenbezeichnung 82 ein, die entweder implizit oder explizit ausgedrückt werden kann.
Im oben aufgeführten Beispiel A beispielsweise wird die Ressourcenbezeichnung 82 durch das Attribut „licensePartID" des Elementes „digitalWork" angegeben. Die Bedingung 80 umfasst des Weiteren die Statusvariablen 84 und eine Methodenbeschreibung (method specification) 86, welche angibt, wie die Werte der Statusvariablen 84 erhalten werden können. Die Methodenbeschreibung 86 kann eine Stelle/Stellen, an der/denen die Werte der Statusvariablen 84 gespeichert sind (wie beispielsweise einen dezentralen Status-Controller, der eine Bedingung, wie im Folgenden beschrieben, verwaltet), ein Kommunikationsprotokoll zum Kommunizieren mit dem Status-Controller, in dem die Bedingung verwaltet wird, sowie sämtliche Parameter, die benötigt werden, um den Wert zu erhalten (wie beispielsweise Dienstparameter und so weiter) umfassen. Alternativ dazu kann das Verfahren in dem System hartkodiert werden, und die Methodenbeschreibung (method specification) 86 kann weggelassen werden.
Wie oben erwähnt, repräsentieren die Statusvariablen 84 den Status der Bedingung 80. Jede Statusvariable 84 hat jederzeit einen entsprechenden Wert für einen Prinzipal, ein Recht und eine Ressource. Wie oben erwähnt, wird die Zusammenstellung der aktuellen Werte der Statusvariablen für ein gegebenes Recht in dieser Erfindung als der „Status der Rechte" bezeichnet. 5 stellt den Status der Rechte 50 des bevorzugten Ausführungsbeispiels dar, der die Bedingung 80 und die aktuellen Werte 52 für die Statusvariablen 84 der Bedingung 80 umfasst. Die Methodenbeschreibung (method specification) 56 gibt eine Methode an, die verwendet wird, um die derzeitigen Werte 52 der Statusvariablen 84 zu erhalten, möglicherweise einschließlich einer Quelle, von der der Wert erhalten wird, der digitalen Signatur eines Berechtigungsnachweises, der SitzungsID für eine Anfrage und sämtlicher anderen geeigneten Informationen. Es ist zu beachten, dass die Methodenbeschreibung (method specification) 56 als redundant mit der Methodenbeschreibung 86 angesehen werden kann, und sie kann lediglich eine Wiederholung davon sein. In einigen Fällen jedoch kann sich die Methodenbeschreibung (method specification) 56, die verwendet wird, um die Werte 52 zu erhalten, von der Methodenbeschreibung (method specification) 86 unterscheiden, die für die Verwendung in der Bedingung 80 vorgeschlagen wird.
Die Verwendung des Status der Rechte 50 zur Darstellung der Bedingung 80 für ein Recht vereinfacht den Prozess der Überprüfung der Bedingungen 80, da sämtliche für die Überprüfung der Bedingung 80 benötigten Informationen leicht zugänglich sind. Der Status der Rechte 50 wird erstellt und anschließend verwendet, wann immer die entsprechende Bedingung 80 evaluiert und verifiziert wird. Jeder Status der Rechte 50 kann sämtliche Informationen enthalten, die zum Verifizieren der Werte 52 der Statusvariablen 84 benötigt werden.
Ein authentisierter Prinzipal ist ein Benutzer, der von einem System bearbeitet wurde, das die Authentizität dieses Benutzers überprüft, wenn sich beispielsweise ein Benutzer erfolgreich mit einem Benutzernamen und einem Passwort einloggt, wird der Benutzer zu einem authentisierten Prinzipal oder nur zu einem „Prinzipal". Die Bedingung 80 für eine gegebene Reihe von Rechten wird als eine Reihe von erforderlichen Werten von Statusvariablen definiert, unter denen der Prinzipal Zugang zu der geschützte Ressource 100 erhält. Wenn ein authentisierter Prinzipal Zugang zu einer geschützten Ressource 100 erhalten möchte, ändert sich der Systemstatus von einem „ursprünglichen Status" in einen „autorisierten Status".
Wenn sich das System in einem autorisierten Status befindet, kann der Prinzipal auf die geschützte Ressource 100 für eine autorisierte Operation zugreifen. In vielen Fällen ist es nicht der authentisierte Prinzipal selbst, der tatsächlich auf die geschützte Ressource 100 zugreift. Beispielsweise kann der Zugang an einen anderen authentisierten Prinzipal, wie beispielsweise an eine „Rendering-Anwendung", einen Dienst oder Ähnliches, übertragen werden. Während auf die geschützte Ressource 100 zugegriffen und diese benutzt wird, ist es möglich, dass die Reihe von Vorbedingungen 80 zum Gewähren des anfänglichen Zugangs nicht mehr für das Autorisieren des kontinuierlichen Zugangs anwendbar ist. Des Weiteren kann die Benutzung der geschützten Ressource 100 die Ressource in eine Reihe von temporären, das heißt, abgeleiteten Ressourcen 100a transformieren, von denen die Zugangsbedingungen 80, die für die ursprünglichen Ressourcen gelten, auch nicht anwendbar sind. Um die Ressource 100 sowie deren abgeleitete Ressourcen 100a zu schützen, während auf diese zugegriffen wird, verwendet das bevorzugte Ausführungsbeispiel ein Konzept zum Autorisieren und Schützen, das als „zugangszeitliche Bedingungen" bezeichnet wird, und welches im Folgenden ausführlich beschrieben wird.
In einem herkömmlichen System befinden sich die Ressourcen in einem von zwei Status. Wie in 2 dargestellt, befindet sich das System, wenn die Ressource 100 nicht aktiviert ist, in dem ursprünglichen Status 102, bis die Vorbedingungen erfüllt sind. Zu diesem Zeitpunkt wird die Ressource 100 aktiviert, und das System geht in den autorisierten oder aktivierten Status 104 über. Um die Kontrolle über die Ressourcen zu erhöhen, definiert das bevorzugte Ausführungsbeispiel zwei zusätzliche Status zusätzlich zu dem „ursprünglichen Status" und dem „autorisierten Status". Wie in 3 dargestellt, durchläuft der Systemstatus während der Benutzung oder des Zugangs zu der geschützten Ressource 100 die Folgenden Status: ursprünglicher Status 102, autorisierter Status 104, Status der Benutzung 106 und Endstatus 108. Die Bedingungen 80 können für jeden Status definiert werden, und müssen erfüllt werden, um zu dem nächsten Status übergehen zu können oder in demselben Status fort zu fahren. Wie vorangehend in Bezug auf 1 erwähnt, können die Bedingungen 80 unter Verwendung der Erstellungsanwendung 70, die sämtliche erforderlichen Benutzerschnittstellen und Editierfähigkeiten umfasst, definiert und erstellt werden. Die Bedingungen 80, die erfüllt werden müssen, um in den autorisierten Status überzugehen, werden als „Vorbedingungen" bezeichnet. Die Bedingungen 80, die während der Benutzung der Ressource 100 erfüllt werden müssen, werden als „zugangszeitliche Bedingungen" bezeichnet, und die Be dingungen 80, die am Ende der Benutzung erforderlich sind, werden als „Nachbedingungen" bezeichnet. Der Validierer für Bedingungen (condition validator) 44 kann die erforderlichen Bedingungen für jeden Status aufrufen.
Die zugangszeitlichen Bedingungen werden von der ursprünglichen Ressource 100 an sich selbst sowie an sämtliche der abgeleiteten Ressourcen 100a übertragen, während ein authentisierter Prinzipal auf sie zugreift und sie benutzt. Wenn beispielsweise die Ressource 100 ein Dokument ist, das auf einem Bildschirm in der Client-Umgebung 30 während der autorisierten Operation „ansehen" angezeigt wird, können die abgeleiteten Ressourcen 100a den Speicher umfassen, der jeweils die Daten des Dokumentes, das Präsentationsformat des Dokumentes und die angezeigten Fenster enthält. Sämtliche der abgeleiteten Ressourcen 100a werden durch die Reihe von zugangszeitlichen Bedingungen geschützt. Mit anderen Worten bedeutet dies, dass der Prinzipal nur so lange Zugang zu den abgeleiteten Ressourcen 100a hat, wie die zugangszeitlichen Bedingungen erfüllt werden. Die zugangszeitlichen Bedingungen können auf dieselbe Art und Weise wie die anderen Bedingungen 80 definiert werden.
Bei einem weiteren Beispiel weist eine Anwendung, wie beispielsweise die Anwendung 12, einen Dienst an, der eine geschützte Ressource 100 ist. Sobald die Anforderung autorisiert ist, kann die Anwendung, die den Dienst ausführt, als eine abgeleitete Ressource betrachtet werden, und unterliegt der Reihe von zugangszeitlichen Bedingungen, während der Dienst ausgeführt wird. Die zugangszeitlichen Bedingungen definieren den autorisierten Status der Rechte 44a und werden in der im Folgenden ausführlich beschriebenen Art und Weise auf den aktuellen Status der Rechte 44b angewandt. Wenn die angeforderte Operation entweder obligatorisch oder freiwillig abgeschlossen ist, werden sämtliche durch die zugangszeitlichen Bedingungen geschützten abgeleiteten Ressourcen 100a gelöscht (oder deaktiviert), und der Systemstatus wird durch die Reihe von Nachbedingungen in den letzten Status gebracht.
Die Bedingungen 80 können sich nach oder während der Benutzung oder dem Zugang zu einer Ressource ändern oder nicht. Diejenigen Bedingungen mit einem nicht geänderten Status werden als „statuslose Bedingungen" bezeichnet, währenddessen die Bedingungen, die sich nach oder während der Benutzung der Ressource ändern, als „Statusbedingungen" bezeichnet werden. Die Vorbedingungen 80 sind normalerweise statuslose Bedingungen 80 und werden zur Steuerung des Zugangs zu dem geschützten Dokument verwendet. Die zugangszeitlichen Bedingungen und die Nachbedingungen sind normalerweise Statusbedingungen 80. Sie werden verwendet, um den Le benszyklus der geschützten Ressource 100 zu steuern. (Zum Beispiel kann nicht mehr auf die geschützte Ressource 100 zugegriffen werden, wenn eine spezifische Anzahl von Nutzern, die in einem Netzwerk eingeloggt ist, überschritten wird.) Mit diesen erweiterten Bedingungstypen 80, die verschiedenen Phasen der geschützten Ressource 100 zugeordnet sind, bietet das bevorzugte Ausführungsbeispiel einen Mechanismus zum Autorisieren der Benutzung der geschützten Ressource 100 und zum Schützen und Verfolgen der Ressource 100, während sie benutzt wird.
Wie in 3 dargestellt und unter Bezugnahme auf die Elemente von 1, durchläuft ein System in Übereinstimmung mit dem bevorzugten Ausführungsbeispiel drei Phasen. Die Phase zum Autorisieren des Zugangs 302 ist eine Phase, in der die Status-Verwaltungseinrichtung 40 einen authentisierten Prinzipal autorisiert, auf die geschützte Ressource 10 für eine autorisierte Operation zuzugreifen, und zwar durch das Überprüfen, ob die Vorbedingungen erfüllt sind. Die Phase zum Schützen der Ressource 304 ist eine Phase, in der die Status-Verwaltungseinrichtung 40 die Ressource 100 sowie die abgeleiteten Ressourcen 100a schützt, währenddessen sie benutzt werden, indem sie überprüft, ob die zugangszeitlichen Bedingungen erfüllt bleiben. Die Phase zum Beenden der Operation 306 ist eine Phase, in der die Status-Verwaltungseinrichtung 40 die Benutzung der geschützten Ressource 100 sowie der abgeleiteten Ressourcen 100a für eine gegebene Operation beendet, wenn die Nachbedingungen erfüllt werden, oder wenn anderenfalls die zugangszeitlichen Bedingungen nicht mehr erfüllt werden.
In rekursiven Situationen, in denen mehrere Zugänge für dieselbe Ressource 100 gewährt werden, kann die Nachbedingung dieselbe sein wie die Vorbedingung des nächsten Zyklus. In einem solchen Fall kann ein nicht statischer Parameter verwendet werden, um Endlosschleifensituationen zu vermeiden. Beispielsweise eine zeitabhängige Bedingung oder eine Bedingung, die von einer externen Instanz modifiziert oder auferlegt wurde, wie beispielsweise ein Eingriff durch eine Person.
Die Zugangsautorisierung gewährt einem authentisierten Prinzipal das Recht/die Rechte, auf eine geschützte Ressource 100 für eine autorisierte Operation zuzugreifen. Die Vorbedingungen werden evaluiert, das heißt, gegen den Status der Rechte durchgesetzt. Wenn die Durchsetzung erfolgreich ist, gehen die Ressource 100 und sämtliche abgeleiteten Ressourcen 100a in den autorisierten Status in Schritt 406 über, und es wird damit begonnen, die zugangszeitlichen Bedingungen durchzusetzen.
Wie voranstehend erwähnt, schützt der Ressourcenschutz durch das Durchsetzen der zugangszeitlichen Bedingungen sowohl die anfänglich geschützte Ressource 100 als auch deren abgeleiteten Ressourcen 100a. Der autorisierte Status, der aus dem Zugangsautorisierungsstatus zurückgekehrt ist, umfasst die Liste mit den zugangszeitlichen Bedingungen, die während der autorisierten Operation durchgesetzt werden sollen. In einem obligatorischen System können alle abgeleiteten Ressourcen 100a in dem Ressourcenspeicher 46 (siehe 7 und die folgende Beschreibung) der Ressource-Verwaltungseinrichtung 42 erfasst werden, wenn die Ressourcen 100a erzeugt und benutzt werden. Wenn eine zugangszeitlichen Bedingung ungültig wird, deaktiviert die Ressource-Verwaltungseinrichtung 42 den Zugang zu der geschützten Ressource 100 und zu den abgeleiteten Ressourcen 100a durch die Anwendung 12.
Durch das Beenden einer autorisierten Operation wird eine Reihe von Nachbedingungen (falls vorhanden) ausgeführt. Das Ausführen der Nachbedingungen kann den Status der Rechte ständig ändern und bewirkt die nächstfolgende Anforderung für den Zugang zu der Ressource 100. Wenn beispielsweise eine Nachbedingung die Aufhebung des Zugangs zu einer Ressource 100 ist, nachdem ein Ausübungslimit erreicht wurde, und wenn das Limit erreicht wird, wird die Ressource 100 gelöscht oder es werden einige andere Maßnahmen ergriffen, mit denen der Zugang gesperrt oder verhindert wird. Das Beenden der Operation kann das Beenden der Ressource einschließen. Die Ressource-Verwaltungseinrichtung 42 kann abgeleitete Ressourcen 100a löschen (deaktivieren), wenn die Operation beendet wird, unabhängig davon ob die Operation gezwungenermaßen beendet wird oder nicht, oder ob die Anwendung die Operation willkürlich beendet. Das Löschen (oder Deaktivieren) der abgeleiteten Ressource 100a spielt eine wichtige Rolle bei dem Vorgang zum Schutz der Ressource 100. Der Validierer für Bedingungen (condition validator) 44 legt die Benutzung der geschützten Ressource 100 fest und setzt die Reihe von Nachbedingungen durch. Das Validierer für Bedingungen (condition validator) 44 erklärt die geschützte Ressource 100 für ungültig (deaktiviert sie), wenn die Ressource 100 als Ergebnis der Änderung des Systemstatus ungültig wird.
Es kann beobachtet werden, dass sich der Status der Rechte während der Benutzung der Ressource 100 ändern kann, und aus diesem Grund besteht eine Notwendigkeit, den Status der Rechte aufrecht zu erhalten, zu aktualisieren und abzurufen. Wie voranstehend erwähnt, greift der Validierer für Bedingungen (condition validator) 44 auf den aktuellen Status der Rechte 44b zu, um die Bedingungen 80 zu validieren, die zu den Rechten zugeordnet sind. Während die Ressourcen 100 verwendet werden oder während auf sie zugegriffen wird, überprüft der Validierer für Bedingungen (condition validator) die Reihe von zugangszeitlichen Bedingungen und verwaltet den aktuellen Status der Rechte 44b. Der Validierer für Bedingungen (condition validator) 44 kommuniziert mit der Ressource-Verwaltungseinrichtung 42, um die abgeleitete Ressource 100a zu steuern. Wenn der aktuelle Status der Rechte nicht mehr gültig ist, das heißt, die zugangszeitlichen Bedingungen nicht mehr erfüllt, weist der Validierer für Bedingungen (condition validator) 44 die Ressource-Verwaltungseinrichtung 42 an, sämtliche abgeleiteten Ressourcen 100a zu löschen (zu deaktivieren) oder die Anwendung 12 darüber zu informieren, dass die Benutzung der abgeleiteten Ressourcen 100a nicht mehr zulässig ist. Die Verwendung des Status der Rechte zur Darstellung der Bedingung 80 vereinfacht den Prozess des Überprüfens der Bedingungen 80, da sämtliche Informationen, die zum Überprüfen einer spezifischen Bedingung 80 erforderlich sind, leicht zugänglich sind.
Wie in den 1 und 6 dargestellt, umfasst die Ressource-Verwaltungseinrichtung 40 des Weiteren ein Rahmenwerk für den Status der Rechte 20, das den Validierern für Bedingungen (condition validator) 44 die API (Application Programming Interface [Schnittstelle zur Anwendungsprogrammierung]) bereitstellt, und dem Status-Controller 22 sowie dem Statusvalidierer 24 eine Plugin-Infrastruktur bietet. Das Rahmenwerk 20 ist für die Kommunikation und die Koordination der Aufgaben zwischen der Vielzahl von Status-Controllern 22 und Validierern 24 zuständig.
Jeder Status-Controller 22 ist eine Komponente, die den Status verwaltet, das heißt, den Wert einer gegebenen Statusvariable verfolgt. Der grundlegende Aufbau des Status-Controllers 22 umfasst eine Softwarekomponente, die die APIs, die durch das Rahmenwerk für den Status der Rechte definiert werden, verändert, ein Protokoll zum Kommunizieren mit den permanenten Speicherungen oder den zu speichernden Diensten, und das Aktualisieren eines aktuellen Wertes sowie das Anfragen für einen aktuellen Wert der Statusvariable und den Verlauf der Statusvariable. Die Stelle des permanenten Speichers oder des Dienstes, der die Statusvariable verwaltet, ist demzufolge für das Rahmenwerk für den Status der Rechte 20 erkennbar.
Jeder Statusvalidierer 24 ist eine Komponente, die den Wert einer Statusvariable validiert. Jeder Statusvalidierer 24 umfasst eine Softwarekomponente, die die Reihe von Schnittstellen, die durch die Statusvalidierung und das Überprüfen der API 20c des Rahmenwerkes für die Rechte 20 definiert sind, implementiert. Der Statusvalidierer 24 kann genauso wie der Status-Controller 22 lokal oder dezentral arbeiten.
Wie in 6 dargestellt, umfasst das Rahmenwerk für den Status der Rechte 20b eine API zum Verändern des Status, was eine Reihe von Schnittstellen zum Initialisieren, Anfragen, Aktualisieren und Übermitteln von Werten des Status der Rechte ist. Wie voranstehend erwähnt, umfasst die Basisstruktur für die Bedingung 80 die Statusvariablen sowie ein Methode, die benötigt werden, um den aktuellen Wert der Statusvariablen zu erhalten.
Die Werte können genauso wie die Statusvariablen durch eine Grammatik wie beispielsweise eine Datenstruktur oder die XrML^TM-Sprache für Rechte dargestellt werden, die den aktuellen Wert beschreibt. Das bevorzugte Ausführungsbeispiel verwendet XrML^TM, um die Statusvariablen und deren Erweiterungen zu definieren, um den Wert der Statusvariablen zu definieren. Die Darstellung der Statusvariablen und deren Werte ist jedoch nicht auf oder durch XrML^TM beschränkt. Das folgende Beispiel zeigt, wie eine Statusvariable unter Verwendung von XrML^TM definiert werden kann.
Beispiel 5:
Das vorangehende Beispiel beschreibt die Statusvariable eines Druckrechtes, mit dem nicht mehr als 9 Kopien der Ressource gedruckt werden dürfen. Der Wert, der einer Bedingung zugeordnet ist, kann, wie in einem Beispiel eines Ausübungslimits, so einfach wie eine Zahl sein, oder er kann ein Boolescher Wert „ja" oder „nein" sein, wie in einem Beispiel, in dem eine Genehmigung erforderlich ist. Das Wert kann ebenfalls ge speichert und durch einen Dienst oder eine Komponente, wie im folgenden Beispiel K dargestellt, verwaltet werden.
Beispiel K:
Das Beispiel K stellt einen Status dar, der einem gleitenden Intervall eines Rechtes „play" (spielen) zugeordnet ist. In diesem Beispiel enthält die Statusvariable keinen aktuellen Wert, der der Bedingung zugeordnet ist. Es ist vielmehr der dezentrale Dienst (stateReference), der als Status-Controller 22 dient, der den Wert sowie dessen „Opaque-Wert" in der Darstellung der Statusvariable verwaltet.
Die API zum Verändern des Status 20b umfasst eine Anfrageschnittstelle zum Anfragen der Werte einer Statusvariable. Eine Anfrage für den Wert einer Statusvariable erfordert eine Eingabe, die die anzufragende Statusvariable und den Typ des Wertes der Antwort umfasst. Der Wert der Antwort auf die Statusanfrage kann der Statuswert, der Statusverlauf oder beides sein.
Im folgenden Beispiel L ist der Wert einer Statusvariable „exerciseLimit" einem Recht „print" (drucken) zugeordnet.
Beispiel L:
Um die Anfrage zu verarbeiten, bestimmt das Rahmenwerk für den Status der Rechte 20, welcher Status-Controller 22 für diese Anfrage zuständig ist, und lokalisiert, authentisiert und lädt anschließend diesen bestimmten Status-Controller 22 und übermittelt die Anfrage an den Status-Controller 22, der diese verarbeitet. Das Status-Controller 22 kann lokal oder dezentral sein. Wenn die Anfrage verarbeitet wurde, wird die Antwort anschließend über das Rahmenwerk für den Status der Rechte 20 zu der Anfrageeinrichtung zurück übertragen. Das folgende Beispiel M beschreibt die Antwort.
Beispiel M:
Die Anfrageantwort enthält die ursprüngliche Anfrage, den aktuellen Wert der angefragten Statusvariable, falls vorhanden, den aktuellen Status der Statusvariable oder den Statusverlauf, eine Identifikation, eine SitzungsID und eine digitale Signatur der Antwort. Die digitale Signatur kann verwendet werden, um die Richtigkeit der Antwort zu gewährleisten.
Der Status kann nur auf Basis der vorherigen Antwort der Statusanfrage aktualisiert werden, vorausgesetzt, dass die SitzungsID in der Antwort der Statusanfrage gültig ist. Die SitzungsID wird in dem bevorzugten Ausführungsbeispiel verwendet, um eine Antwort zu identifizieren, es kann jedoch eine andere Identifikation verwendet werden, um die Anfrage und die Aktualisierung anzupassen. Aus diesem Grund muss die Status-Verwaltungseinrichtung 40 den aktuellen Wert der Statusvariable anfragen, um den Wert der Statusvariable und die gültige SitzungsID zu erhalten, um die Ziel-Statusvariable zu aktualisieren. Durch das Aktualisieren des Wertes der Statusvariable wird der aktuelle Wert der Statusvariable zu einem neuen Wert geändert.
Es gibt viele Nebenbedingungen, die für das Aktualisieren des Wertes der Statusvariable gelten können. Beispielsweise müssen die Rechte, die der Statusvariable zugeordnet sind, vor der Aktualisierungsanfrage noch gültig sein. Eine andere Nebenbedingung kann sein, dass der neue Wert der Statusvariable nach dem Aktualisieren ein gültiger für die Statusvariable zulässiger Wert sein muss. Wenn beispielsweise die maximale Anzahl der Druckkopien (Statusvariable) 4 beträgt und die aktuelle Anzahl der Druckkopien 3 (aktueller Wert der Statusvariable), wird demzufolge eine Anfrage für 2 weitere Druckkopien (Wert aktualisieren) abgelehnt werden, da der Wert der Statusvariable nach dem Aktualisieren kein zulässiger Wert ist. Darüber hinaus müssen der Prinzipal oder die Anwendung, die die Anfrage zum Aktualisieren stellen, dazu autorisiert sein. Das Rahmenwerk für den Status der Rechte 20 identifiziert, authentisiert und lädt den Status-Controller 22, um eine Aktualisierungsanfrage zu verarbeiten. Das folgende Beispiel M ist ein Beispiel einer Anfrage zum Aktualisieren einer Statusvariable.
Beispiel M:
Die Übermittlung des Statuswertes gleicht der Aktualiserung des Statuswertes hinsichtlich der Statusverwaltung. Der Hauptunterschied zwischen den beiden besteht darin, auf welche Weise der Statusverlauf für die Statusvariable aufrechterhalten wird. Sobald der Status übermittelt ist, werden der aktuelle Wert der Statusvariable sowie deren Verlauf gemäß der Übermittlung aktualisiert. Wenn die Rechte, deren Status übermittelt werden, als Ergebnis der Statusübermittlung ungültig werden, wird diese Übermittlung als vollständige Übermittlung bezeichnet, anderenfalls wird die Übermittlung als unvollständige Übermittlung bezeichnet. Bei der Übermittlung eines Statuswertes können dieselben Nebenbedingungen wie bei der Aktualisierung des Statuswertes gelten. Die an der Übermittlung des Statuswertes beteiligten Elemente können vor dem Durchführen der Übermittlung autorisiert werden.
Die Status-Verwaltungseinrichtung 40 verwaltet des Weiteren eine Reihe von Statusvalidierern 24 und stellt der Anwendung eine Reihe von Schnittstellen zur Verfügung, wobei die Anwendung jede Statusvariable einzeln oder als eine Gesamtheit, die den Status der Rechte darstellt, verifiziert. Der Status der Rechte ist, wie bereits erwähnt, die Zusammenstellung der aktuellen Werte der Statusvariablen, die einem gegebenen Recht zugeordnet sind. Das Rahmenwerk für den Status der Rechte 20 wählt den entsprechenden Statusvalidierer 24 für jede der Statusvariablen aus und lädt diesen. Wenn der Statusvalidierer 24 ausgewählt und geladen ist, übermittelt das Rahmenwerk für den Status der Rechte 20 die Anfrage an den Ziel-Statusvalidierer 24 und wartet auf das Ergebnis in Form einer Antwortnachricht. Die Status-Verwaltungseinrichtung 40 kann alle Statusvalidierer 24 gleichzeitig oder nacheinander ausführen, und zwar in Abhängigkeit von der Beziehung zwischen den Statusvariablen und der Konfiguration des Systems.
Der Statusvalidierer 24 verifiziert den Wert der Statusvariable unter Verwendung einer Status-Anfrageantwort. Nach dem Empfangen der Anfrage zum Validieren einer Statusvariable, prüft das Rahmenwerk für den Status der Rechte 20 die Antwort der Statusanfrage und wählt anschließend den geeigneten Statusvalidierer 24 aus, authentisiert und lädt ihn und übermittelt die Antwort der Statusanfrage an den Statusvalidierer 24. Auf Basis einer konfigurierbaren Vorgehensweise und von Informationen, die in der Statusanfrage gespeichert sind, kann der Statusvalidierer 24 die sowohl in der Statusanfrage als auch in der Antwort gespeicherten Informationen akzeptieren oder in Frage stellen. Wenn die in der Statusanfrage und in der Antwort gespeicherten Informationen verifiziert werden, kann der Validierungsvorgang so einfach sein wie das Vergleichen des aktuellen Wertes der Statusvariable mit der Reihe von möglichen (oder zulässigen) Werten der Statusvariable. Jeder Statusvalidierer 24 kann eine Softwarekomponente umfas sen, die die Reihe von Schnittstellen, die durch das Rahmenwerk für den Status der Rechte 20 definiert werden, implementiert. Der Statusvalidierer 24 kann lokal oder dezentral arbeiten.
Das bevorzugte Ausführungsbeispiel kann verschiedene Vorrichtungen verwendet, wie beispielsweise Personalcomputer, Server, Arbeitsplatzcomputer, PDAs, Thin-Clients und Ähnliches. Beispielsweise kann die Client-Umgebung eine tragbare Vorrichtung, wie beispielsweise ein Mobiltelefon oder ein PDA, sein. Es können verschiedene Kommunikationskanäle verwendet werden. Des Weiteren können verschiedene Funktionen in eine Vorrichtung integriert werden. Die offenbarten funktionalen Vorrichtungen und Module werden aus Gründen der Übersichtlichkeit durch die Funktion unterschieden. Die verschiedenen Funktionen können jedoch kombiniert oder einzeln als Hardware- und/oder Softwaremodule und -vorrichtungen jeglicher Art verwendet werden. Die verschiedenen Funktionsmodule und -vorrichtungen haben ihren Nutzen sowohl einzeln als auch in Kombination.
Die verschiedenen Aufzeichnungen, Nachrichten, Elemente sowie Teile davon können in derselben Vorrichtung oder in verschiedenen Vorrichtungen gespeichert werden. Unterschiedliche Links, Referenzen, Spezifikationen und Ähnliches können verwendet werden, um die Elemente einander zuzuordnen. Der Zugang zu sämtlichen Ressourcen kann gesteuert werden. Es können sämtliche Mechanismen zum Verfolgen der Werte der Statusvariablen verwendet werden.
Die Erfindung wurde anhand eines bevorzugten Ausführungsbeispiels sowie anhand von Beispielen beschrieben. Es können jedoch viele Modifizierungen vorgenommen werden, ohne vom Umfang der Erfindung, wie durch die angehängten Ansprüche und rechtlichen Entsprechungen definiert, abzuweichen.

Claims

System zum Verwalten einer geschützten Ressource (100) in einem System zum Gewähren von Zugang zu der geschützten Ressource (100) gemäß Nutzungsrechten, wobei die Nutzungsrechte Statusvariablen (84) umfassen, welche einen Status einer zugehörigen geschützten Ressource (100) anzeigen, wobei das System umfasst: eine geschützte Ressource (100), welcher ein Nutzungsrecht zugeordnet ist, das eine Vielzahl von zulässigen Benutzungsarten für die geschützte Ressource (100) anzeigt, wobei ein Status des Nutzungsrechtes zumindest teilweise durch eine Statusvariable definiert ist, die zu einem der Vielzahl von zulässigen Benutzungsarten für die geschützte Ressource (100) korrespondiert; ein Ressource-Verwaltungsgerät, das mit der Ressource verbunden ist, um die Benutzung der Ressource zu steuern, indem das Nutzungsrecht durchgesetzt wird; ein Status-Controller, der eingerichtet ist, einen Wert der Statusvariable zu verfolgen; und ein Rahmenwerk für eine Schnittstelle (interface framework), das eingerichtet ist, eine Nachricht von dem Ressource-Verwaltungsgerät zu empfangen, welche sich auf die Statusvariable bezieht, und das eingerichtet ist, den Status-Controller zu laden und den Status-Controller anzuweisen, den Wert der Statusvariable gemäß der Nachricht zu verändern; wobei die Nutzungsrechte des Weiteren eine Methodenbeschreibung (method specification) (86) umfassen, welche angibt, wie Werte der Statusvariablen (84) erhalten werden können, wobei die Methodenbeschreibung eine Stelle, wo die Werte der Statusvariablen gespeichert sind oder ein Kommunikationsprotokoll zum Kommunizieren mit dem Status-Controller umfasst.
System gemäß Anspruch 1, wobei die Nachricht eine Anfrage für einen Wert ist und wobei das Rahmenwerk für eine Schnittstelle eingerichtet ist, den Status-Controller anzuweisen, einen aktuellen Wert der Statusvariable abzurufen und den Wert als eine Anfrageantwort zu übergeben.
System gemäß Anspruch 2, wobei die Anfrageantwort den aktuellen Wert, die Anfrage und einen ID-Mechanismus umfasst.
System gemäß Anspruch 3, wobei das Ressource-Verwaltungsgerät eingerichtet ist, einen gespeicherten Wert der Statusvariable mit dem aktuellen Wert zu aktualisieren.
System gemäß Anspruch 1, wobei mehrere Status-Controller vorhanden sind, welche zu einer Vielzahl von Statusvariablen korrespondiert.
System gemäß Anspruch 1, welches des Weiteren mindestens eine abgeleitete Ressource (100a) zum Ausführen des Nutzungsrechtes für die geschützte Ressource (100) umfasst, wobei die Statusvariablen zu der geschützten Ressource (100) übermittelt werden.
System gemäß Anspruch 2, welches des Weiteren einen Statusvalidierer umfasst, welcher eingerichtet ist, eine Logik auf die Anfrageantwort anzuwenden, um die Anfrageantwort zu validieren.
System gemäß Anspruch 4, wobei das Ressource-Verwaltungsgerät einen Validierer für Bedingungen (condition validator) umfasst, welcher eingerichtet ist, die Bedingungen des Nutzungsrechtes in Abhängigkeit von dem gespeicherten Wert durchzusetzen.
System gemäß einem der Ansprüche 1 bis 8, wobei die Methodenbeschreibung mindestens eines der Folgenden umfasst: die Stelle, das Kommunikationsprotokoll und einen Serviceparameter, welcher benötigt wird, um die Werte der Statusvariablen zu bekommen.
Verfahren zum Verwalten einer geschützten Ressource (100) in einem System zum Gewähren von Zugang zu der geschützten Ressource (100) gemäß von Nutzungsrechten, wobei die Nutzungsrechte eine Statusvariable umfassen, die einen Status einer zugehörigen geschützten Ressource (100) anzeigt, wobei das Verfahren umfasst: Übertragen einer Nachricht bezüglich der Statusvariable von einem Ressource-Verwaltungsgerät zu einem Rahmenwerk für eine Schnittstelle (interface framework), wobei das Ressource-Verwaltungsgerät mit der geschützten Ressource (100) verbunden ist, um die Benutzung der geschützten Ressource (100) zu steuern, indem das Nutzungsrecht, welches eine Vielzahl von zulässigen Benutzungsarten für die geschützte Ressource (100) anzeigt, durchgesetzt wird, wobei ein Status des Nutzungsrechtes zumindest teilweise durch die Statusvariable, welche zu einer der Vielzahl von zulässigen Benutzungsarten für die geschützte Ressource (100) korrespondiert, definiert ist; Laden eines Status-Controllers in das Rahmenwerk, welcher eingerichtet ist, den Wert der Statusvariable zu verfolgen; und Anweisen des Status-Controllers, einen Wert der Statusvariable gemäß der Nachricht zu verändern; wobei die Nutzungsrechte des Weiteren eine Methodenbeschreibung (method specification) (86), umfassen, welche anzeigt, wie Werte der Statusvariablen (84) erhalten werden können, wobei die Methodenbeschreibung eine Stelle, wo die Werte der Statusvariablen gespeichert sind, oder ein Kommunikationsprotokoll zum Kommunizieren mit dem Status-Controller umfasst.
Verfahren gemäß Anspruch 10, wobei die Nachricht eine Anfrage für einen Wert ist und wobei der Schritt des Anweisens ein Anweisen des Status-Controllers zum Abrufen eines aktuellen Wertes der Statusvariable und zum Übergeben des Wertes als eine Anfrageantwort umfasst.
Verfahren gemäß Anspruch 11, wobei die Anfrageantwort den aktuellen Wert, die Anfrage und einen ID-Mechanismus umfasst.
Verfahren gemäß Anspruch 12, welches des Weiteren ein Aktualisieren eines gespeicherten Wertes der Statusvariable in dem Ressource-Verwaltungsgerät gemäß des aktuellen Wertes umfasst.
Verfahren gemäß Anspruch 10, welches des Weiteren ein Ableiten mindestens einer abgeleiteten Ressource (100a) zum Ausführen des Nutzungsrechtes für die geschützte Ressource (100) und ein Übermitteln der Statusvariablen zu der geschützten Ressource (100) umfasst.
Verfahren gemäß Anspruch 10, welches des Weiteren ein Anwenden einer Logik auf die Anfrageantwort zum Validieren der Anfrageantwort umfasst.
Verfahren gemäß Anspruch 13, welches des Weiteren ein Durchsetzen von Bedingungen des Nutzungsrechtes in Abhängigkeit des gespeicherten Wertes umfasst.
Verfahren gemäß einem der Anspruche 10 bis 16, wobei die Methodenbeschreibung mindestens eines der Folgenden umfasst: die Stelle, das Kommunikationsprotokoll und einen Serviceparameter, welcher benötigt wird, um die Werte der Statusvariablen zu bekommen.