DE602004009354T2

DE602004009354T2 - Registrierung bzw. Unter-registrierung eines Servers für die Verwaltung digitaler Rechte in einer Architektur zur Verwaltung digitaler Rechte

Info

Publication number: DE602004009354T2
Application number: DE602004009354T
Authority: DE
Inventors: Gregory Kirkland Kostal; Steve Seattle Bourne; Vinay Woodinville Krishnaswamy
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2003-02-25
Filing date: 2004-02-16
Publication date: 2008-01-24
Anticipated expiration: 2024-02-17
Also published as: US20040168061A1; JP4524124B2; AU2004200454A1; CO5550078A1; BRPI0400335A; TWI362872B; HK1067478A1; NZ531278A; KR20040076627A; ZA200401306B; JP2004259281A; CL2004000324A1; CN1531253B; EP1455479B1; CA2457938C; CN1531253A; DE602004009354D1; IL160352A0; US7308573B2; EP1455479A1

Description

TECHNISCHES GEBIET
Diese Erfindung bezieht sich auf ein DRM (Digital Rights Management)-System. Insbesondere bezieht sich die Erfindung auf die Verwendung eines DRM-Systems zur Veröffentlichung eines digitalen Inhaltes in einer Firma, wie etwa einem Büro oder einem Unternehmen oder dergleichen, so dass die Bereitstellung und die Nutzung des Inhaltes innerhalb der Firma gemäß entsprechenden Nutzungs- oder Lizenzbestimmungen eingeschränkt werden kann. Insbesondere bezieht sich die vorliegende Erfindung auf ein Netzwerk von DRM-Servern, die ein derartiges DRM-System in die Praxis umsetzen, sowie ein Verfahren zum Registrieren oder Teil-Registrieren eines DRM-Servers in diesem Netzwerk.
HINTERGRUND DER ERFINDUNG
Die Handhabung und Durchsetzung digitaler Rechte ist in Verbindung mit digitalem Inhalt, wie etwa digitalem Audio, digitalem Video, digitalem Text, digitalen Daten, digitalem Multimedia und dergleichen, bei dem derartiger digitaler Inhalt auf einen oder mehrere Benutzer verteilt werden soll, höchst wünschenswert. Digitaler Inhalt kann statisch sein, wie etwa ein Textdokument, oder kann gestreamt werden, wie etwa das gestreamte Audio/Video eines Live-Ereignisses. Typische Arten der Verteilung umfassen greifbare Vorrichtungen, wie etwa eine Magnetdiskette (Floppy-Diskette), ein Magnetband, eine optische Platte (CD) und dergleichen, sowie nicht greifbare Medien, wie etwa eine elektronische Anzeigetafel, ein elektronisches Netzwerk, das Internet und dergleichen. Bei Empfang durch den Benutzer, gibt der Benutzer den digitalen Inhalt mit Hilfe einer geeignete Wieder gabevorrichtung, wie etwa eines Medien-Abspielgeräts auf einem PC oder dergleichen, wieder oder "spielt" diesen "ab".
Bei einem Szenario wünscht es der Inhaber des Inhaltes oder der Inhaber der Rechte, wie etwa ein Autor, ein Herausgeber, ein Rundfunksender und dergleichen, einen derartigen digitalen Inhalt auf jeden einer Vielzahl von Benutzern oder Empfängern im Austausch mit einer Lizenzgebühr oder einer anderen Vergütung zu verteilen. Bei einem derartigen Szenario kann der Inhalt dann ein Lied, ein Album von Liedern, ein Film und dergleichen sein, wobei der Zweck der Verteilung darin besteht, die Lizenzgebühren zu erheben. Ein derartiger Inhaber des Inhaltes würde es, wenn er die Wahl hat, wahrscheinlich wünschen zu beschränken, was der Nutzer mit einem derartigen verteilten digitalen Inhalt machen kann. Beispielsweise würde es der Inhaber des Inhaltes wünschen, den Nutzer wenigstens bei einem derartigem Kopieren und derartiger Weiterverteilung eines solchen Inhaltes auf einen zweiten Nutzer einzuschränken, bei denen dem Besitzer des Inhaltes eine Lizenzgebühr vom zweiten Benutzer verweigert wird.
Darüber hinaus könnte es der Inhaber des Inhaltes wünschen, dem Nutzer die Flexibilität zu geben, unterschiedliche Typen von Nutzungslizenzen zu unterschiedlichen Lizenzgebühren zu erwerben, während er gleichzeitig für den Nutzer die Bedingungen bestimmt, welche Art von Lizenz tatsächlich erworben wird. Beispielsweise kann es der Inhaber des Inhaltes wünschen, dass der digitale Inhalt lediglich in einer begrenzten Anzahl, lediglich für eine bestimmte Gesamtzeit, nur auf einem bestimmten Gerätetyp, nur auf einem bestimmten Typ eines Medienabspielgerätes, lediglich von einem bestimmten Nutzer und dergleichen abgespielt wird.
Bei einem weiteren Szenario wünscht es ein Inhalts-Entwickler, wie etwa ein Angestellter oder ein Mitglied einer Firma, derartigen digitalen Inhalt auf einen oder mehrere andere Angestellte oder Mitglieder der Firma oder auf andere Einzelpersonen außerhalb der Firma zu verteilen, würde es jedoch wünschen, dass andere den Inhalt wiedergeben. Hier ist die Verteilung des Inhaltes stärker mit der firmenbasierten gemeinsamen Nutzung von Inhalt in einer vertraulichen und be schränkten Art und Weiser verwandt, als mit einer Verteilung auf breiter Basis im Austausch mit einer Lizenzgebühr oder einem anderen Entgelt.
Bei einem derartigen Szenario kann der Inhalt eine Dokumentpräsentation, eine Kalkulationstabelle, eine Datenbank, eine E-Mail oder dergleichen sein, wie sie innerhalb einer Büroumgebung ausgetauscht werden kann, wobei es der Inhalts-Entwickler wünschen kann, dass sichergestellt ist, dass der Inhalt in der Firmen- oder Büroumgebung verbleibt und nicht von unautorisierten Einzelpersonen, wie etwa Konkurrenten oder Gegnern, wiedergegeben wird. Wiederum wünscht es ein derartiger Entwickler des Inhaltes zu beschränken, was ein Empfänger mit einem derartigern verteilten digitalen Inhalt machen kann. Beispielsweise würde es der Inhaber des Inhaltes wünschen, den Nutzer wenigstens bei einem derartigen Kopieren und derartiger Weiterverteilung eines solchen Inhaltes auf einen zweiten Nutzer einzuschränken, bei denen der Inhalt außerhalb der Grenzen von Einzelpersonen dargestellt wird, denen die Wiedergabe des Inhaltes gestattet ist.
Darüber hinaus kann es der Entwickler des Inhaltes wünschen, unterschiedliche Empfänger mit unterschiedlichen Graden von Wiedergaberechten auszustatten. Beispielsweise kann es der Entwickler des Inhaltes wünschen, dass ein geschützter digitaler Inhalt betrachtet werden kann und im Bezug auf eine Klasse von Einzelpersonen nicht ausgedruckt werden kann, und im Bezug auf eine weitere Klasse von Einzelpersonen betrachtet und ausgedruckt werden kann.
Bei beiden Szenarien hat jedoch, nachdem die Verteilung erfolgt ist, ein derartiger Inhaber/Entwickler des Inhaltes, wenn überhaupt, nur geringe Kontrolle über den digitalen Inhalt. Dies ist insbesondere im Hinblick auf die Tatsache problematisch, dass praktisch jeder PC die Software und Hardware enthält, die erforderlich ist, um eine exakte digitale Kopie eines solchen digitalen Inhaltes zu erstellen und eine derartige exakte digitale Kopie auf eine beschreibbare magnetische oder optische Platte herunterzuladen, oder eine derartige exakte digitale Kopie über ein Netzwerk, wie etwa das Internet, zu einem beliebigen Bestimmungsort zu senden.
Als Teil einer Transaktion, bei der der Inhalt verteilt wird, kann es der Inhaber/Entwickler natürlich vom Nutzer/Empfänger des digitalen Inhaltes verlangen zu versprechen, diesen digitalen Inhalt nicht in schlechter Absicht weiter zu verteilen. Ein derartiges Versprechen wird jedoch einfach gemacht und einfach gebrochen. Ein Inhaber/Entwickler eines Inhaltes kann versuchen, eine derartige Weiterverteilung durch eine beliebige zahlreicher bekannter Sicherheitsvorrichtungen zu verhindern, die normalerweise die Verschlüsselung und Entschlüsselung beinhalten. Es gibt jedoch wahrscheinlich sehr wenig, das einen ein wenig entschlossenen Nutzer davon abhält, verschlüsselten digitalen Inhalt zu entschlüsseln, derartigen digitalen Inhalt in unverschlüsselter Form zu sichern und anschließend denselben weiter zu verteilen.
Es besteht somit Bedarf an der Bereitstellung einer Architektur zur Handhabung und Durchsetzung digitaler Rechte sowie eines Verfahrens, das die kontrollierte Wiedergabe oder das Abspielen beliebiger Arten digitalen Inhaltes zulässt, wobei eine derartige Kontrolle flexibel ist und vom Inhaber/Entwickler eines derartigen Inhaltes definiert werden kann. Insbesondere besteht Bedarf an einer Architektur, die eine derartige kontrollierte Wiedergabe insbesondere in einer Büro- oder Firmenumgebung oder dergleichen ermöglicht und gestattet, in denen Dokumente unter einer definierten Gruppe von Einzelpersonen oder Klassen von Einzelpersonen gemeinsam genutzt werden. Insbesondere besteht Bedarf an einem Verfahren zum Registrieren von berechtigungsgewährenden Servern in dieser Architektur.
Die Internet Engineering Task Force: "Internet x.509 Public Key Infrastructure: Roadmap", IETF, Internet Draft PKIX Working Group, Juli 2002 beschäftigt sich mit öffentlichen Schlüssel-Infrastrukturen und legt dar, dass Benutzer von Systemen auf der Basis von öffentlichen Schlüsseln sicher sein müssen, dass jedesmal, wenn sie auf einen öffentlichen Schlüssel zurückgreifen, das Subjekt, mit dem sie kommunizieren, den zugehörigen privaten Schlüssel hat. Dies trifft unabhängig davon zu, ob ein Verschlüsselungs- oder ein Digitalsignaturmechanismus verwendet wird. Diese Sicherheit wird durch die Verwendung von PKCs erzielt, die Datenstrukturen sind, die Werte von öffentlichen Schlüsseln an Subjekte binden. Die Bindung wird dadurch erreicht, dass eine vertrauliche CA die Identität des Subjektes verifiziert und jede PKC digital signiert. Zudem wird die Cross-Zertifizierung behandelt. Ein Cross-Zertifikat wird verwendet, um es Client- Systemen oder End-Einheiten in einer administrativen Domäne zu gestatten, sicher mit Client-Systemen oder Endbenutzern in einer weiteren administrativen Domgin zu kommunizieren. Die Verwendung eines Cross-Zertifikates, das von CA_1 bis CA_2 ausgegeben wird, gestattet es dem Benutzer Alice, der CA_1 vertraut, eine PKC zu akzeptieren, die von Bob verwendet wird und von CA_2 ausgegeben wurde.
Die Internet Engineering Task Force, Network Working Group: "Internet x.509 Public Key Infrastructure Certificate Management Protocols" IETF, Request for Comments, RFC 2510, März 1999 beschäftigt sich mit PKI-Zertifikats-Verwaltungsprotokollen. Es ist PKI-System beschrieben, das über eine Vielzahl von Computern, wie etwa CAs und End-Einheiten, verfügt. Im Bezug auf die Cross-Zertifizierung wird dargelegt, dass eine CA die Ausgabe eines Cross-Zertifikates von einer weiteren CA anfordert. Dadurch ist das Cross-Zertifikat ein Zertifikat, bei dem die Subjekt-CA und die Ausgeber-CA eindeutig sind und SubjectPublicKey-Info einen Verifizierungsschlüssel enthält, d.h. das Zertifikat wurde für das signierende Schlüsselpaar der Subjekt-CA ausgegeben. Die Cross-Zertifizierung verlangt die Verwendung derselben Syntax (CertReqMessages) wie bei normalen Zertifikations-Anfragen, mit der Einschränkung, dass das Schlüsselpaar durch die anfragende CA erzeugt worden sein muss und der private Schlüssel nicht zur antwortenden CA gesendet werden darf. Cross-Zertifikations-Antworten verwenden dieselbe Syntax (CertRepMessage) wie bei normalen Zertifikations-Antworten, mit der Einschränkung, dass kein verschlüsselter privater Schlüssel gesendet werden kann. Eine Registrierungs-Antwort-Nachricht enthält als PKIBody eine CertRepMessage-Datenstruktur, die einen Statuswert für jedes angefragte Zertifikat hat, und verfügt wahlweise über einen öffentlichen CH-Schlüssel, Fehlerinformationen, ein Subjekt-Zertifikat und einen verschlüsselten privaten Schlüssel. Weiterhin ist erwähnt, dass sämtliche End-Einheiten einen sicheren lokalen Zugriff auf bestimmte Informationen verlangen, zu einem Minimum ihren eigenen Namen und privaten Schlüssel, den Namen einer CA, die direkt von dieser Einheit gesichert ist, und den öffentlichen Schlüssel dieser CA. Implementierungen können einen sicheren lokalen Speicher für mehr als dieses Minimum, wie etwa das eigene Zertifikat der End-Einheit oder applikationsspezifische Informationen, verwenden. PKI-Verwaltungseinheiten sind ebenfalls End-Einheiten in dem Sinne, dass sie bisweilen im Subjekt-Feld eines Zertifikates oder eines Cross-Zertifikates erwähnt sind.
Gemäß Internet Engineering Task Force, Network Working Group: "Internet x.509 certificate request message formst" IETF, Request for Comments, RFC 2511, März 1999 enthält die CertReqMessage-Syntax CertReqMsg, die ihrerseits CertRequest enthält. Die CertRequest-Syntax besteht aus einer Anforderungskennung, einer Vorlage eines Zertifikatsinhaltes und einer optionalen Sequenz von Steuerinformationen. Die Vorlage enthält den Subjekt-Namen und einen einzigartigen Identifikator.
ITU-T, ISO/IEC: "The Directory: Public Key and attribute certificate frameworks", ITU-T Series X Recommendation x.509, ISO IEC 9594-8, März 2000 bezieht sich auf öffentliche Schlüssel und Zertifikate öffentlicher Schlüssel und beschreibt, dass eine Zertifizierungs-Autorität das Zertifikat eines Benutzers erzeugt, indem sie eine Sammlung von Informationen, die den ausgezeichneten Namen des Benutzers und den öffentlichen Schlüssel enthalten, wie auch einen optionalen einzigartigen Identifikator signiert, der zusätzliche Informationen über den Benutzer enthält.
In WO 00/58811 A ist ein DRM-System beschrieben. Das System arbeitet auf einer Computervorrichtung, wenn ein Benutzer verlangt, dass ein geschütztes Stück eines digitalen Inhaltes von der Computervorrichtung in spezieller Weise wiedergegeben werden soll. Das DRM-System hat einen Lizenz-Speicher, eine Lizenz-Bewertungseinrichtung und einen Statusspeicher. Der Lizenz-Speicher speichert digitale Lizenzen in der Computervorrichtung. Die Lizenz-Bewertungseinrichtung bestimmt, ob beliebige Lizenzen, die im Lizenz-Speicher gespeichert sind, dem verlangten digitalen Inhalt entsprechen und ob derartige entsprechende Lizenzen gültig sind, überprüft Lizenzregeln in jeder derartigen gültigen Lizenz und bestimmt auf der Basis derartiger überprüfter Lizenzregeln, ob eine derartige Lizenz den anfragenden Benutzer in die Lage versetzt, den angeforderten digitalen Inhalt in der gefragten Art und Weise wiederzugeben. Der Statusspeicher hält die Statusinformationen entsprechend jeder Lizenz im Lizenzspeicher, in dem die Sta tusinformationen erzeugt und von der Lizenz-Bewertungseinrichtung je nach Erfordernis aktualisiert werden.
Internet Engineering Task Force, Network Working Group: "Certificate Management Messages over CMS" IETF, Request für comments, RFC 2797, April 2000 definiert ein Zertifikats-Verwaltungsprotokoll unter Verwendung von CMS (CMC). Es sind keine speziellen Dienste weder für die Erneuerung (neue Zertifikate mit demselben Schlüssel) noch die Neu-Verschlüsselung (neue Zertifikate an neuen Schlüsseln) von Clients vorgesehen. Anstelle dessen sieht eine Erneuerungs/Neu-Verschlüsselungs-Nachricht genau so aus, wie eine beliebige Registrierungsnachricht, wobei der Identitätsnachweis durch bestehende Zertifikate von der CA zugeführt wird. Es existiert eine Bereitstellung für lokale Registrierungsautoritäten, am Protokoll teilzunehmen, indem Client-Registrierungsnachrichten genommen werden, diese in einer zweiten Schicht einer Registrierungsnachricht mit zusätzlichen Erfordernissen oder Anweisungen von der lokalen Registrierungsautorität eingehüllt werden und anschließend diese neue erweiterte Anfrage zur Zertifizierungsautorität weitergeleitet wird.
ÜBERSICHT OBER DIE ERFINDUNG
Das Ziel der vorliegenden Erfindung besteht darin, ein Verfahren zur Registrierung in einem DRM-System anzugeben, das eine verbesserte Zuverlässigkeit und/oder Sicherheit bietet.
Dieses Ziel wird mit der Erfindung erreicht, wie sie in den unabhängigen Ansprüchen definiert ist.
Ausführungsformen sind in den abhängigen Ansprüchen definiert.
Die zuvor beschriebenen Bedürfnisse werden wenigstens zum Teil durch die vorliegende Erfindung erfüllt, bei der ein DRM (Digital Rights Management)-System über eine Vielzahl von DRM-Servern verfügt, die eine DRM-Funktionalität erfüllen, wobei ein beitretender DRM-E-Server in dem System durch einen registrierenden DRM-R-Server derart registriert wird, dass dem beitretenden DRM-E-Server in dem System zu vertrauen ist. Bei der Erfindung beschafft der DRM-E-Server ein Paar aus öffentlichem/privatem Schlüssel (PU-E, PR-E) zum Identifizieren eines derartigen DRM-E-Servers innerhalb des DRM-Systems, beschafft eine anbietende Identifizierung desselben und sendet eine Registrierungsanforderung zum DRM-R-Server, die die anbietende Identifizierung und den PU-E enthält.
Der DRM-R-Server validiert die anbietende Identifizierung und erzeugt, wenn die Anfrage gewährt wird, ein digitales Registrierungs-Zertifikat für den DRM-E-Server, um einen derartigen DRM-E-Server im DRM-System zu registrieren. Der DRM-R-Server führt das erzeugte Registrierungs-Zertifikat zu dem anfordernden DRM-E-Server zurück, wobei der nunmehr registrierte DRM-E-Server das zurückgeführte Registrierungs-Zertifikat an einem geeigneten Ort für die zukünftige Verwendung speichert. Der DRM-E-Server mit dem Registrierungs-Zertifikat ist in der Lage, dieses zu verwenden, um DRM-Dokumente innerhalb des DRM-Systems auszugeben.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorangegangene Zusammenfassung, wie auch die folgende detaillierte Beschreibung der Ausführungsformen der vorliegenden Erfindung, werden besser verständlich, wenn sie in Verbindung mit den beiliegenden Zeichnungen gelesen werden. Zu Darstellungszwecken der Erfindung sind in den Zeichnungen Ausführungsformen dargestellt, die derzeit bevorzugt werden. Es versteht sich jedoch, dass die vorliegende Erfindung nicht auf die dargestellten präzisen Anordnungen und Mittel beschränkt ist.
1 ist ein Blockschaltbild, das eine beispielhafte, nicht begrenzende Berechnungsumgebung darstellt, in der die vorliegende Erfindung angewendet werden kann;
2 ist ein Blockschaltbild, das eine beispielhafte Netzwerkumgebung darstellt, die über eine Vielzahl von Berechungsvorrichtungen verfügt, in denen die vorliegende Erfindung angewendet werden kann;
3 ist ein Funktionsblockschaltbild einer bevorzugten Ausführungsform eines Systems und eines Verfahrens gemäß der Erfindung zum Veröffentlichen von digitalem Inhalt;
4 ist ein Flussdiagramm einer bevorzugten Ausführungsform eines Verfahrens gemäß der Erfindung zum Veröffentlichen von DRM-Inhalt;
4A ist ein Blockschaltbild, das den Aufbau eines signierten Rechtekennsatzes zeigt, wie er durch das Verfahren von 4 erzeugt wird;
5 ist ein Blockschaltbild einer bevorzugten Ausführungsform eines Systems und eines Verfahrens gemäß der Erfindung zum Lizenzieren von DRM-Inhalt;
6A und 6B sind Flussdiagramme einer bevorzugten Ausführungsform eines Verfahrens gemäß der Erfindung zum Lizenzieren von DRM-Inhalt;
7 ist ein Blockschaltbild, das ein Zertifikat darstellt, das von einem DRM-Server an einen Benutzer ausgegeben wird, um es dem Benutzer zu gestatten, eine Off-Line-Veröffentlichung auszuführen, gemäß einer Ausführungsform der vorliegenden Erfindung;
8 ist ein Blockdiagramm, das das Zertifikat von 7 zusammen mit einer Veröffentlicher-Lizenz zeigt, die es dem Veröffentlicher gestattet, Inhalt offline wiederzugeben, der dadurch veröffentlicht wird, gemäß einer Ausführungsform der vorliegenden Erfindung;
9 ist ein Flussdiagramm, das die Schlüssel-Schritte darstellt, die vom veröffentlichenden Benutzer ausgeführt werden, um die Veröffentlichungs-Lizenz von 8 zu erhalten, gemäß einer Ausführungsform der vorliegenden Erfindung;
10 ist ein Flussdiagramm, das die Schlüssel-Schritte zeigt, die vom veröffentlichenden Benutzer ausgeführt werden, um die erhaltene Veröffentlichungs-Lizenz von 9 zu verwenden, um den entsprechenden Inhalt wiederzugeben, gemäß einer Ausführungsform der vorliegenden Erfindung;
11 ist ein Blockschaltbild, das eine Architektur zur Durchsetzung eines Beispiels eines vertrauensbasierten Systems zeigt;
12 ist ein Blockschaltbild, das eine Vielzahl von DRM-Servern zeigt, wie sie etwa in der Architektur der vorliegenden Erfindung vorhanden sein können, wobei jeder (beitretende) DRM-Server in der Architektur durch einen weiteren (registrierenden) DRM-Server registriert oder teil-registriert wird, der an denselben ein Registrierungs-Zertifikat ausgibt;
13 ist ein Blockschaltbild, das das Registrierungs-Zertifikat von 12 zusammen mit einem Bürgschafts-Zertifikat darstellt, das wenigstens bei einigen Vorfällen von einem beitretenden DRM-Server einem registrierenden DRM-Server dargeboten wird; und
14 und 15 sind Flussdiagramme, die Schlüssel-Schritte zeigen, die von den registrierenden und beitretenden DRM-Servern von 13 und 14 ausgeführt werden, um den beitretenden DRM-Server zu registrieren (14) oder teilregistrieren.
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
COMPUTERUMGEBUNG
1 und die folgende Beschreibung zielen darauf ab, eine kurze und allgemeine Beschreibung einer geeigneten Berechungsumgebung zu geben, in der die Erfindung ausgeführt werden kann. Es versteht sich jedoch, dass in der Hand zu haltende, tragbare und andere Berechungsvorrichtungen sämtlicher Arten für die Verwendung in Verbindung mit der vorliegenden Erfindung in Erwägung gezogen werden. Wenngleich ein Computer für allgemeine Zwecke im folgenden beschrieben ist, ist dies lediglich ein Beispiel, wobei die vorliegende Erfindung lediglich einen Thin-Client erfordert, der mit dem Netzwerk-Server kompatibel ist und mit diesem interagieren kann. Somit kann die vorliegende Erfindung in einer Umgebung gehosteter Netzwerkdienste arbeiten, in denen sehr wenige oder minimale Client-Ressourcen impliziert sind, wie etwa in einer Netzwerkumgebung, in der die Client-Vorrichtung lediglich als Browser oder Schnittstelle zum World Wide Web dient.
Wenngleich dies nicht erforderlich ist, kann die Erfindung über eine Applikations-Programmierschnittstelle (API) implementiert werden, die von einem Entwickler verwendet wird und/oder in der Netzwerk-Browsersoftware enthalten ist, die im allgemeinen Zusammenhang von computerausführbaren Anweisungen beschrieben wird, wie etwa in Programmmodulen, die von einem oder mehreren Computern, wie etwa Client-Workstations, Servern oder anderen Vorrichtungen ausgeführt werden. Im allgemeinen beinhalten Programmmodule Routinen, Programme, Objekte, Komponenten, Datenstrukturen und dergleichen, die spezielle Aufgaben ausführen oder spezielle abstrakte Datentypen implementieren. Normalerweise kann die Funktionalität der Programmmodule ja nach Wunsch in unterschiedlichen Ausführungsformen kombiniert oder verteilt werden. Darüber hinaus wird der Fachmann verstehen, dass die Erfindung mit anderen Computersystem-Konfigurationen in die Praxis umgesetzt werden kann. Andere hinlänglich bekannte Berechnungssysteme, Umgebungen und/oder Konfigurationen, die sich zur Verwendung mit der Erfindung eignen können, beinhalten ohne darauf beschränkt zu sein, PCs, automatisierte Bankkassiermaschinen, Server-Computer, Hand- oder Laptop-Geräte, Multiprozessorsysteme, mikroprozessorbasierte Systeme, programmierbare Verbraucherelektronik, Netzwerk-PCs, Minicomputer, Großrechner und dergleichen. Die Erfindung kann zudem in verteilten Berechnungsumgebungen der Praxis zugeführt werden, in denen Aufgaben durch entfernte Verarbeitungsvorrichtungen ausgeführt werden, die durch ein Kommunikationsnetzwerk oder ein anderes Datenübertragungsmedium ausgeführt werden. In einer verteilten Berechnungsumgebung können sich Programmmodule sowohl auf lokalen als auch auf entfernten Computer-Speichermedien befinden, die Speicher-Speichervorrichtungen beinhalten.
1 zeigt somit ein Beispiel einer geeigneten Berechungssystem-Umgebung 100, in der die Erfindung ausgeführt werden kann, wenngleich, wie es oben erläutert wurde, die Berechungssystem-Umgebung 100 lediglich ein Beispiel einer geeigneten Berechnungsumgebung ist und nicht als Einschränkung des Geltungsbereiches der Verwendung oder Funktionalität der Erfindung verstanden werden sollte. Genauso wenig sollte die Berechungsumgebung 100 so verstanden werden, dass sie eine Abhängigkeit oder ein Erfordernis hat, die sich auf eine Komponente oder eine Kombination von Komponenten beziehen, die in der beispielhaften Betriebsumgebung 100 dargestellt sind.
Unter Bezugnahme auf 1 enthält ein beispielhaftes System zur Umsetzung der Erfindung eine Berechnungsumgebung für allgemeine Zwecke in Gestalt eines Computers 110. Bestandteile des Computers 110 können, ohne darauf be schränkt zu sein, eine Verarbeitungseinheit 120, einen Systemspeicher 130 und einen Systembus 121 enthalten, der unterschiedliche Systemkomponenten, die den Systemspeicher beinhalten, mit der Verarbeitungseinheit 120 koppelt. Der Systembus 121 kann ein beliebiger von unterschiedlichen Typen von Busaufbauten sein, die einen Speicherbus oder Speicher-Controller, einen Peripheriebus und einen lokalen Bus beinhalten, bei denen eine beliebige einer Vielfalt von Busarchitekturen Verwendung findet. Beispielsweise beinhalten derartige Architekturen, ohne darauf beschränkt zu sein, den ISA-Bus (ISA – Industry Standard Architecture), den MCA-Bus (MCA – Micro Channel Architecture), den EISA-Bus (EISA – Enhanced ISA), den lokalen VESA-Bus (VESA – Video Electronics Standards Association) und den PCI-Bus (Peripheral Component Interconnect) (auch als Mezzanine-Bus bekannt).
Der Computer 110 enthält normalerweise eine Vielfalt computerlesbarer Medien. Computerlesbare Medien können beliebige verfügbare Medien sein, auf die von einem Computer 110 zugegriffen werden kann, und beinhalten sowohl flüchtige als auch nicht flüchtige Medien, entnehmbare und nicht entnehmbare Medien. Beispielsweise können computerlesbare Medien, ohne darauf beschränkt zu sein, Computerspeichermedien und Kommunikationsmedien beinhalten. Computerspeichermedien beinhalten sowohl flüchtige als auch nicht flüchtige, entnehmbare und nicht entnehmbare Medien, die bei einem beliebigen Verfahren oder einer beliebigen Technologie zum Speichern von Informationen, wie etwa computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen oder anderen Daten, eingesetzt werden. Computerspeichermedien beinhalten, ohne darauf beschränkt zu sein, einen RAM, einen ROM, einen EEPROM, einen Flash-Speicher oder andere Speichertechnologie, eine CD-ROM, eine DVD oder anderen optischen Plattenspeicher, Magnetkassetten, ein Magnetband, einen magnetischen Plattenspeicher oder andere Magnetspeichervorrichtungen oder ein beliebiges anderes Medium, das verwendet werden kann, um die gewünschten Informationen zu speichern und auf das durch einen Computer 110 zugegriffen werden kann. Kommunikationsmedien verkörpern normalerweise computerlesbare Anweisungen, Datenstrukturen, Programmmodule oder andere Daten in einem modulierten Datensignal, wie etwa einer Trägerwelle oder einem anderen Transportmechanismus und beinhalten beliebige Informationszustellungsmedien. Der Begriff "moduliertes Datensignal" bezeichnet ein Signal, bei dem eines oder mehrere seiner Charakteristika derart eingestellt oder geändert wird/werden, dass Informationen im Signal codiert werden. Beispielsweise beinhalten Kommunikationsmedien, ohne darauf beschränkt zu sein, drahtgebundene Medien, wie etwa eine drahtgebundene Netzwerkverbindung oder eine direkt verdrahtete Verbindung, sowie drahtlose Medien, wie etwa akustische, hochfrequente, infrarote und andere drahtlose Medien. Kombinationen der oben Genannten sollten ebenfalls im Geltungsbereich von computerlesbaren Medien enthalten sein.
Der Systemspeicher 130 enthält Computerspeichermedien in Gestalt eines flüchtigen und/oder nicht flüchtigen Speichers, wie etwa eines Festspeichers (ROM) 131 und eines Direktzugriffsspeichers (RAM) 132. Ein Basis Eingangs/Ausgangssystem 133 (BIOS), das die Basisroutinen enthält, die dabei hilfreich sind, Informationen zwischen Elementen innerhalb des Computers 110, wie etwa während des Startens, auszutauschen, ist normalerweise im ROM 131 gespeichert. Der RAM 132 enthält normalerweise Daten- und/oder Programmmodule, auf die unverzüglich von der Verarbeitungseinheit 120 zugegriffen werden kann und/oder die derzeit von dieser ausgeführt werden. Beispielweise zeigt 1, ohne dabei einschränkend zu wirken, ein Betriebssystem 134, Applikationsprogramme 135, andere Programmmodule 136 und Programmdaten 137.
Der Computer 110 kann zudem andere entnehmbare/nicht entnehmbare, flüchtige/nicht flüchtige Computerspeichermedien beinhalten. Lediglich beispielhaft zeigt 1 ein Festplattenlaufwerk 141, das von einem nicht entnehmbaren, nicht flüchtigen Magnetmedium liest oder auf dieses schreibt, ein Magnetplattenlaufwerk 151, das von einer entnehmbaren, nicht flüchtige Magnetplatte liest oder auf diese schreibt, und ein optisches Plattenlaufwerk 155, das von einer entnehmbaren, nicht flüchtigen optischen Platte 156, wie etwa einer CD-ROM oder einem anderen optischen Medium liest und auf dieses schreibt. Andere entnehmbare/nicht entnehmbare, flüchtige/nicht flüchtige Computerspeichermedien, die in der beispielhaften Betriebsumgebung verwendet werden können beinhalten, ohne darauf beschränkt zu sein, Magnetbandkassetten, Flash-Speicherkarten, DVDs, digitale Videobänder, einen Festkörper-RAM, einen Festkörper-ROM und dergleichen. Das Festplattenlaufwerk 141 ist normalerweise mit dem Systembus 121 durch eine nicht entnehmbare Speicherschnittstelle, wie etwa die Schnittstelle 140 verbunden, und das Magnetplattenlaufwerk 151 sowie das optische Plattenlaufwerk 155 sind normalerweise mit dem Systembus 121 durch eine nicht entnehmbare Speicherschnittstelle, wie etwa die Schnittstelle 150 verbunden.
Die Laufwerke und ihre zugehörigen Computerspeichermedien, die oben beschrieben und in 1 dargestellt sind, stellen den Speicher für computerlesbare Anweisungen, Datenstrukturen, Programmmodule und andere Daten für den Computer 110 bereit. In 1 ist das Festplattenlaufwerk beispielsweise so dargestellt, dass es ein Betriebssystem 144, Applikationsprogramme 145, andere Programmmodule 146 und Programmdaten 147 speichert. Es wird darauf hingewiesen, dass diese Komponenten das Betriebssystem 134, die Applikationsprogramme 135, die anderen Programmmodule 136 und Programmdaten 137 sein oder sich von diesen unterscheiden können. Dem Betriebssystem 144, den Applikationsprogrammen 145, den anderen Programmmodulen 146 und den Programmdaten 147 sind hier andere Ziffern gegeben, um darzustellen, dass sie als Minimum unterschiedliche Kopien sind. Ein Benutzer kann Befehle und Informationen in den Computer 110 durch Eingabevorrichtungen, wie etwa eine Tastatur 162 und eine Zeigevorrichtung 161, die allgemein als Maus, Trackball oder Touch-Pad bezeichnet wird, eingeben. Andere Eingabevorrichtungen (nicht gezeigt) können ein Mikrofon, einen Joystick, ein Game-Pad, eine Satellitenschüssel, einen Scanner oder dergleichen beinhalten. Diese und andere Eingabevorrichtungen sind mit der Verarbeitungseinheit 120 durch eine Benutzereingabeschnittstelle 160 verbunden, die mit dem Systembus 121 gekoppelt ist, können jedoch durch andere Schnittstellen- und Busaufbauten verbunden sein, wie etwa einen Parallelanschluss, einen Spieleanschluss oder einen USB (Universal Serial Bus).
Ein Monitor 191 oder anderer Typ einer Anzeigevorrichtung ist ebenfalls mit dem Systembus 121 über eine Schnittstelle, wie etwa eine Videoschnittstelle 190 verbunden. Eine Grafikschnittstelle 182, wie etwa Northbridge, kann ebenfalls mit dem Systembus 121 verbunden sein. Northbridge ist ein Chipsatz, der mit der CPU kommuniziert, oder eine Host-Verarbeitungseinheit 120 und übernimmt die Verantwortlichkeit für AGP-Kommunikationen (AGP – Beschleunigter Grafikanschluss). Eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 184 können mit der Grafikschnittstelle 182 kommunizieren. In dieser Hinsicht enthalten die GPUs 184 im allgemeinen einen On-Chip-Speicher-Speicher, wie etwa einen Registerspeicher, wobei die GPUs 184 mit einem Videospeicher 186 kommunizieren. Die GPUs 184 sind jedoch nur ein Beispiel eines Koprozessors, weshalb eine Vielfalt von Koprozessor-Vorrichtungen im Computer 110 enthalten sein kann. Ein Monitor 191 oder ein anderer Typ einer Anzeigevorrichtung ist ebenfalls mit dem Systembus 121 über eine Schnittstelle, wie etwa eine Videoschnittstelle 190 verbunden, die ihrerseits mit dem Videospeicher 186 kommunizieren kann. Zusätzlich zum Monitor 191 können Computer zudem andere Peripherie-Ausgabegeräte, wie etwa Lautsprecher 197 und einen Drucker 196 enthalten, die durch eine Ausgangs-Peripherieschnittstelle 195 verbunden sein können.
Der Computer 110 kann in einer Netzwerkumgebung mit Hilfe logischer Verbindungen zu einem oder mehreren entfernten Computern, wie etwa dem entfernten Computer 180, arbeiten. Der entfernte Computer 180 kann ein PC, ein Server, ein Router, ein Netzwerk-PC, eine Peer-Vorrichtung oder anderer gemeinsamer Netzwerkknoten sein und enthält normalerweise viele oder zahlreiche Elemente, die oben im Bezug auf den Computer 110 beschrieben wurden, wenngleich lediglich eine Speicher-Speichervorrichtung 181 in 1 dargestellt ist. Die lokalen Verbindungen, die in 1 dargestellt sind, enthalten ein Nahbereichsnetzwerk (LAN) 171 und ein Weitbereichsnetzwerk (WAN) 173, können jedoch auch andere Netzwerke beinhalten. Derartige Netzwerkumgebungen sind in Büros, unternehmensweiten Computernetzwerken, Intranets und dem Internet allgemein üblich.
Wenn er in einer LAN-Netzwerkumgebung verwendet wird, ist der Computer 110 mit dem LAN 171 durch eine/einen Netzwerkschnittstelle oder -adpter 170 verbunden. Bei Verwendung in einer WAN-Netzwerkumgebung enthält der Computer 110 normalerweise ein Modem 172 oder eine andere Einrichtung zur Einrichtung von Kommunikationen über das WAN 173, wie etwa das Internet. Das Modem 172, das intern oder extern sein kann, kann mit dem Systembus 121 über die Benutzerschnittstelle 160 oder einen anderen geeigneten Mechanismus verbunden sein. In einer Netzwerkumgebung können Programmmodule, die im Bezug auf den Computer 110 dargestellt sind, oder Teile derselben in der entfernten Speicher-Speichervorrichtung gespeichert sein. Beispielsweise zeigt 1, ohne da bei einschränkend zu sein, entfernte Applikationsprogramme 185, die sich in der Speichervorrichtung 181 befinden. Es wird darauf hingewiesen, dass die gezeigten Netzwerkverbindungen beispielhaft sind und andere Einrichtungen zur Einrichtung einer Kommunikationsverbindung zwischen den Computern verwendet werden können.
Der Fachmann wird verstehen, dass ein Computer 110 oder eine andere Client-Vorrichtung als Teil eines Computernetzwerks eingesetzt werden kann. In dieser Beziehung bezieht sich die vorliegende Erfindung auf ein beliebiges Computersystem, das eine Anzahl von Speicher oder Speichereinheiten hat, sowie eine beliebige Zahl von Applikationen und Vorgängen, die in einer beliebigen Zahl von Speichereinheiten oder Datenträgern ausgeführt werden. Die vorliegende Erfindung kann auf eine Umgebung mit Server-Computern und Client-Computern angewendet werden, die in einer Netzwerkumgebung Verwendung finden und über entfernten oder lokalen Speicher verfügen. Die vorliegende Erfindung kann zudem auf eine eigenständige Berechungsvorrichtung angewendet werden, die über eine Programmiersprachen-Funktionalität sowie Interpretations- und Ausführungsfähigkeiten verfügt.
Verteiltes Berechnen erleichtert die gemeinsame Nutzung von Computerressourcen und Diensten durch direkten Austausch zwischen Berechungsvorrichtungen und Systemen. Diese Ressourcen und Dienste beinhalten den Austausch von Informationen, Cache-Speicher und Plattenspeicher für Dateien. Das verteilte Berechnen nutzt die Netzwerkkonnektivität, wodurch es Clients gestattet ist, ihre gemeinsame Leistung wirksam einzusetzen, um dem gesamten Unternehmen zum Vorteil zu gereichen. In dieser Hinsicht kann eine Vielfalt von Vorrichtungen über Applikationen, Objekte oder Ressourcen verfügen, die interagieren können, um Authentisierungstechniken der vorliegenden Erfindung für vertrauliche Grafikpipelines zu implizieren.
2 zeigt eine schematische Darstellung einer beispielhaften Netzwerk- oder verteilten Berechungsumgebung. Die verteilte Berechungsumgebung enthält Berechnungsobjekte 10a, 10b, etc. sowie Berechungsobjekte oder -vorrichtungen 110a, 110b, 110c, etc. Diese Objekte können Programme, Verfahren, Datenspei cher, eine programmierbare Logik und dergleichen enthalten. Die Objekte können Abschnitte derselben oder unterschiedlicher Vorrichtungen, wie etwa PDAs, Fernseher, MP3-Player, PC, etc., enthalten. Jedes Objekt kann mit einem weiteren Objekt mit Hilfe des Berechungsnetzwerkes 14 kommunizieren. Dieses Netzwerk kann an sich andere Berechungsobjekte und Berechnungsvorrichtungen enthalten, die dem System von 2 Dienste bereitstellen. In Übereinstimmung mit einem Aspekt der vorliegenden Erfindung kann jedes Objekt 10 oder 110 eine Applikation enthalten, die die Authentisierungstechniken der vorliegenden Erfindung für vertrauliche Grafikpipelines anfordern können.
Es wird zudem darauf hingewiesen, dass ein Objekt, wie etwa 110c von einer weiteren Berechnungsvorrichtung 10 oder 110 gehostet werden kann. Wenngleich die dargestellte physikalische Umgebung die angeschlossenen Vorrichtungen als Computer darstellen mag, ist eine derartige Darstellung lediglich beispielhaft und kann die physikalische Umgebung alternativ so dargestellt oder beschrieben sein, dass sie unterschiedliche digitale Vorrichtungen, wie etwa PDAs, Fernseher, MP3-Spieler etc., Software-Objekte, wie etwa Schnittstellen, COM-Objekte und dergleichen enthält.
Es gibt eine Vielfalt von Systemen, Komponenten und Netzwerkkonfigurationen, die verteilte Berechungsumgebungen unterstützen. Beispielsweise können Berechungssysteme durch eine Drahtleitung oder Drahtlossysteme, durch ein lokales Netzwerk oder weit verteilte Netzwerke verbunden sein. Derzeit sind zahlreiche der Netzwerke mit dem Internet gekoppelt, das die Infrastruktur für die weit verbreitete Berechung bereitgestellt und zahlreiche unterschiedliche Netzwerke einschließt.
Bei Heimnetzwerkumgebungen gibt es wenigstens vier verschiedene Netzwerktransportmedien, die jeweils ein einzigartiges Protokoll unterstützen können, wie etwa das Starkstromleitungs-, das Daten-(sowohl drahtlos als auch drahtgebunden), das Sprach-(z.B. Telefon) und das Unterhaltungsmedium. Die meisten Haushaltssteuervorrichtungen, wie etwa Lichtschalter und Geräte können die Starkstromleitung für die Konnektivität verwenden. Datendienste können in den Haushalt als Breitband (z.B. entweder DSL oder Kabelmodem) gelangen und sind innerhalb des Haushaltes mit Hilfe entweder der drahtlosen (z.B. HomeRF oder 802.11b) oder der drahtgebundenen (z.B. Home PNA, Cat 5, Even Power Line) Konnektivität zugänglich. Der Sprachverkehr kann in den Haushalt entweder drahtgebunden (z.B. Cat 3) oder drahtlos (z.B. Mobiltelefon) gelangen und kann innerhalb des Haushaltes mit Hilfe einer Cat-3-Verkabelung verteilt werden. Unterhaltungsmedien können in den Haushalt entweder durch Satellit oder Kabel gelangen und werden normalerweise im Haushalt mit Hilfe eine Koaxialkabels verteilt. IEEE 1394 und DVI verbreiten sich ebenfalls als digitale Zwischenverbindungen für Cluster von Mediengeräten. Sämtliche dieser Netzwerkumgebungen und andere, die als Protokollstandards entstehen können, können miteinander verbunden werden, um ein Intranet zu bilden, das mit der Außenwelt mit Hilfe des Internets verbunden werden kann. Kurz gesagt existiert eine Vielfalt unterschiedlicher Quellen für die Speicherung und Übertragung von Daten, und demzufolge erfordern mit der Weiterentwicklung Berechnungsvorrichtungen Arten des Schutzes des Inhaltes an sämtlichen Abschnitten der Datenverarbeitungsleitung.
Das "Internet" bezieht sich im allgemeinen auf die Sammlung von Netzwerken und Gateways, die die Protokollsammlung TCP/IP verwenden, die bei der Technik des Computer-Netzwerkbetriebs hinlänglich bekannt sind. TCP/IP ist eine Abkürzung für "Transport Control Protocol/Interface Program". Das Internet kann als System von geografisch verteilten, entfernten Computernetzwerken beschrieben werden, die durch Computer verbunden sind, die Netzwerkprotokolle ausführen, die es den Benutzern gestatten, Informationen über die Netzwerke auszutauschen und gemeinsam zu nutzen. Infolge einer derartigen weit verbreiteten gemeinsamen Nutzung von Informationen, haben sich entfernte Netzwerke, wie etwa das Internet, somit weitreichend allgemein zu einem offenen System entwickelt, für das Entwickler Softwareapplikationen entwickeln können, um spezielle Operationen oder Dienste im wesentlichen ohne Einschränkung auszuführen.
Somit ermöglicht die Netzwerkinfrastruktur den Host von Netzwerktopologien, wie etwa Client/Server-, Peer-to-Peer- oder Hybridarchitekturen. Der "Client" ist ein Mitglied einer Klasse oder Gruppe, die die Dienste einer weiteren Klasse oder Gruppe nutzt, auf die sie sich nicht bezieht. Somit ist bei der Berechung ein Client ein Vorgang, d.h. grob gesagt ein Satz von Anweisungen oder Aufgaben, der einen Dienst anfordert, der von einem weiteren Programm bereitgestellt wird. Der Client- Prozess nutzt den angeforderten Dienst, ohne dass er Arbeitsdetails über das andere Programm oder den Dienst an sich "wissen" muss. In einer Client-/Server-Architektur, insbesondere in einem Netzwerksystem, ist ein Client normalerweise ein Computer, der auf gemeinsam genutzte Netzwerkressourcen zurückgreift, die von einem weiteren Computer, wie etwa einem Server, bereitgestellt werden. Beim Beispiel von 2 können die Computer 110a, 110b, etc. als Clients und der Computer 10a, 10b, etc. als der Server betrachtet werden, wobei der Server 10a, 10b, etc. die Daten hält, die anschließend in den Client-Computern 110a, 110b, etc. repliziert werden.
Ein Server ist normalerweise ein entferntes Computersystem, auf das über ein entferntes Netzwerk, wie etwa das Internet, zugegriffen werden kann. Der Client-Prozess kann in einem ersten Computersystem aktiv sein, und der Server-Prozess kann in einem zweiten Computer-System aktiv sein, wobei beide miteinander über ein Kommunikationsmedium kommunizieren können, wodurch eine verteilte Funktionalität bereitgestellt ist und es mehreren Clients gestattet ist, die Informationsbündelungs-Fähigkeiten des Servers zu nutzen.
Client und Server kommunizieren miteinander mit Hilfe der Funktionalität, die von einer Protokollschicht bereitgestellt wird. Beispielsweise ist das Hypertext-Transfer-Protocol (HTTP) ein gängiges Protokoll, das in Verbindung mit dem World Wide Web verwendet wird. Normalerweise wird eine Computer-Netzwerkadresse, wie etwa ein URL (Universal Ressource Locator) oder eine IP-Adresse (IP – Internet Protokol) verwendet, um die Server- oder Client-Computer gegenseitig zu identifizieren. Die Netzwerkadresse kann als URL-Adresse bezeichnet werden. Die Kommunikation kann beispielsweise über ein Kommunikationsmedium bereitgestellt werden. Insbesondere können der Client und der Server miteinander über TCP/IP-Verbindungen für eine Kommunikation hoher Kapazität gekoppelt werden.
Somit zeigt 2 eine beispielhafte vernetzte oder verteilte Umgebung, in der ein Server mit Client-Computern über ein Netzwerk/einen Bus kommuniziert und auf die die vorliegende Erfindung angewendet werden kann. Detaillierter gesagt, ist eine Anzahl von Servern 10a, 10b, etc. über ein(en) Kommunikations-Netzwerk/- Bus in Gestalt eines LAN, WAN, Intranet, das Internet, etc., mit einer Anzahl von Client-Berechungsvorrichtungen oder entfernten Berechungsvorrichtungen 110a, 110b, 110c, 110d, 110e, etc. in Gestalt eines tragbaren Computers, eines Handgeräte-Computers, eines Thin-Clients, eines Netzwerk-Gerätes oder einer anderen Vorrichtung, wie etwa eines VCR, eines TV, eines Herdes, Licht, einer Heizung und dergleichen, gemäß der vorliegenden Erfindung miteinander verbunden. Es wird somit in Erwägung gezogen, dass die vorliegende Erfindung auf eine beliebige Berechungsvorrichtung angewendet werden kann, mit der es erwünscht ist, Quellinhalt aus einer vertraulichen Quelle zu verarbeiten, zu speichern oder wiederzugeben.
In einer Netzwerkumgebung, in der das/der Kommunikations-Netzwerk/-BUS 14 das Internet ist, können die Server 10 beispielsweise Web-Server sein, mit denen die Clients 110a, 110b, 110c, 110d, 110e, etc. über ein beliebiges einer Vielzahl bekannter Protokolle, wie etwa HTTP kommunizieren. Die Server 10 können ebenfalls als Clients 110 dienen, wie es für eine verteilte Berechungsumgebung charakteristisch sein kann. Die Kommunikationen können je nach Erfordernis drahtgebunden oder Drahtlos sein. Die Client-Vorrichtungen 110 können oder können nicht über ein/einen Kommunikations-Netzwerk/-Bus 14 kommunizieren und können unabhängige Kommunikationen ausführen, die ihnen zugeordnet sind. Für den Fall eines TV oder eines VCR kann es einen Netzwerkaspekt für dessen Steuerung geben oder nicht. Jeder Client-Computer 110 und Server-Computer 10 kann mit unterschiedlichen Applikationsprogramm-Modulen oder -Objekten 135 sowie Verbindungen ausgestattet sein, oder auf unterschiedliche Typen von Speicherelementen oder Objekten zugreifen, über die Dateien gespeichert werden können oder auf die ein Teil (Teile) von Dateien heruntergeladen oder migriert werden kann. Somit kann die vorliegende Erfindung in einer Computernetzwerk-Umgebung verwendet werden, die über Client-Computer 110a, 110b, etc., die mit einem Computer-Netzwerk-/Bus 14 interagieren und auf dieses zugreifen können, sowie Server-Computer 10a, 10b, etc. verfügt, die mit Client-Computern 110a, 110b, etc. und anderen Vorrichtungen 111 sowie Datenbanken 20 interagieren können.
DRM (Digital Rights Management – Handhabung digitaler Rechte) Übersicht
Wie es bekannt ist, und unter Bezugnahme auf 11, ist die Handhabung und Durchsetzung digitaler Rechte in Verbindung mit digitalem Inhalt 12, wie etwa digitalem Audio, digitalem Video, digitalem Text, digitaler Daten, digitalem Multimedia, etc., höchst wünschenswert, wenn derartiger digitaler Inhalt 12 auf Benutzer verteilt werden soll. Bei Empfang durch den Benutzer gibt ein derartiger Benutzer die digitalen Inhalt mit Hilfe einer geeigneten Wiedergabevorrichtung, wie etwa einem Medien-Abspielgerät auf einem PC 14 oder dergleichen wieder oder "spielt" diesen "ab".
Normalerweise wünscht es ein Inhaber oder Entwickler (im folgenden "Inhaber" genannt), der derartigen digitalen Inhalt 12 verteilt, einzuschränken, was der Benutzer mit diesem verteilten digitalen Inhalt 12 machen kann. Beispielsweise kann es der Inhalts-Inhaber wünschen, den Benutzer einzuschränken, diesen Inhalt 12 zu kopieren und an einen zweiten Benutzer weiter zu verteilen, oder er wünscht es zuzulassen, dass verteilter digitaler Inhalt 12 nur in einer begrenzten Häufigkeit, nur für eine bestimmte Gesamtzeit, lediglich auf einem bestimmten Typ von Maschine, nur auf einem bestimmten Medien-Abspielgerät, lediglich von einer bestimmten Art von Benutzer und dergleichen abgespielt wird.
Nachdem die Verteilung erfolgt ist, hat der Inhaber des Inhaltes, wenn überhaupt, sehr wenig Kontrolle über den digitalen Inhalt 12. Ein DRM-System 10 gestattet dann kontrollierte(s) Wiedergabe oder Abspielen beliebiger Arten digitalen Inhaltes 12, wobei derartige Kontrolle flexibel ist und vom Inhaber des digitalen Inhaltes definiert werden kann. Normalerweise wird der Inhalt 12 an den Benutzer in Gestalt eines Paketes 13 mit Hilfe eines geeigneten Verteilungskanals verteilt. Das verteilte Digitalinhaltspaket 13 kann den digitalen Inhalt 12 beinhalten, der mit einem symmetrischen Verschlüsselungs-/Entschlüsselungs-Schlüssel (KD) (d.h. (KD(INHALT))) verschlüsselt ist, wie auch andere Informationen beinhalten, die den Inhalt, das Erlangen der Lizenz für einen derartigen Inhalt und dergleichen definieren.
Das vertrauensbasierte DRM-System 10 gestattet einem Inhaber digitalen Inhaltes 12, Lizenzregeln festzulegen, die erfüllt sein müssen, bevor derartiger digitaler Inhalt 12 auf einer Berechungsvorrichtung 14 eines Benutzers wiedergegeben werden darf. Derartige Lizenzregeln können das zuvor erwähnte, vorübergehende Erfordernis beinhalten und können in einer digitalen Lizenz oder einem Nutzungsdokument (im folgenden "Lizenz" genannt) 16 enthalten sein, die die Berechungsvorrichtung 14 des Benutzers/der Benutzer (im folgenden sind derartige Begriffe austauschbar, solange es die Gegebenheiten nicht anders verlangen) vom Inhaber des Inhaltes oder dessen Vertreter beziehen müssen. Eine derartige Lizenz 16 enthält zudem den Entschlüsselungs-Schlüssel (KD) zum Entschlüsseln des digitalen Inhaltes, der möglicherweise gemäß einem Schlüssel verschlüsselt ist, der von der Berechungsvorrichtung des Benutzers entschlüsselt werden kann.
Der Inhalts-Inhaber eines Stückes digitalen Inhaltes 12 muss darauf vertrauen, dass die Berechungsvorrichtung 14 des Benutzers die Regeln und Anforderungen befolgt, die von diesem Inhaber des Inhaltes in der Lizenz 16 festgelegt sind, d.h. dass der digitale Inhalt 12 nicht wiedergegeben wird, solange die Regeln und Anforderungen in der Lizenz 16 nicht erfüllt sind. Vorzugsweise ist dann die Berechungsvorrichtung 14 des Benutzers mit einer/einem vertraulichen Komponente/Mechanismus 18 ausgestattet, die/der den digitalen Inhalt 12 nicht wiedergibt, es sei denn gemäß den Lizenzregeln, die in der Lizenz 16 enthalten sind, die dem digitalen Inhalt 12 zugeordnet ist und vom Benutzer bezogen wird.
Die vertrauliche Komponente 18 verfügt normalerweise über eine Lizenz-Bewertungseinrichtung 20, die bestimmt, dass die Lizenz 16 gültig ist, die Lizenzregeln und Erfordernisse in einer derartigen gültigen Lizenz 16 überprüft und auf der Basis der überprüften Lizenzregeln und Erfordernissen überprüft, ob der anfordernde Benutzer das Recht hat, unter anderem den angeforderten digitalen Inhalt in der beabsichtigten Art und Weise darzustellen. Es versteht sich, dass der Lizenz-Bewertungseinrichtung 20 im DRM-System 10 vertraut wird, die Wünsche des Inhabers des digitalen Inhaltes 12 gemäß den Regeln und Erfordernissen in der Lizenz 16 auszuführen, wobei der Benutzer nicht in der Lage sein sollte, auf einfache Art und Weise ein derartiges vertrauliches Element für einen beliebigen Zweck weder in schlechter noch anderer Absicht zu ändern.
Es versteht sich, dass die Regeln und Erfordernisse in der Lizenz 16 festlegen können, ob der Benutzer Rechte hat, den digitalen Inhalt 12 auf der Basis eines beliebigen zahlreicher Faktoren wiederzugeben, enthaltend wer der Benutzer ist, wo sich der Benutzer befindet, welche Art von Berechungsvorrichtung der Benutzer verwendet, welche Wiedergabe-Applikation das DRM-System aufruft, das Datum, die Zeit und dergleichen. Darüber hinaus können die Regeln und Erfordernisse der Lizenz 16 die Lizenz 16 beispielsweise auf eine vorbestimmte Anzahl von Abspielvorgängen oder eine vorbestimmte Abspielzeit beschränken.
Die Regeln und Erfordernisse können in der Lizenz 16 gemäß einer beliebigen geeigneten Sprache und Syntax festgelegt sein. Beispielsweise kann die Sprache einfach Attribute und Werte festlegen, die erfüllt sein müssen (z.B. DATUM muss später als X sein), oder kann die Ausführung von Funktionen gemäß einem festgelegten Skript verlangen (z.B. WENN DATUM größer als X, DANN FÜHRE AUS...).
Wenn die Lizenz-Bewertungseinrichtung 20 bestimmt, dass die Lizenz 16 gültig ist und dass der Benutzer die darin enthaltenen Regeln und Erfordernisse erfüllt, kann der digitale Inhalt 12 anschließend wiedergegeben werden. Um den Inhalt 12 wiederzugeben, erhält man den Entschlüsselungs-Schlüssel (KD) aus der Lizenz 12 und wendet diesen auf (KD(INHALT)) aus dem Inhaltspaket 13 an, was zum aktuellen Inhalt 12 führt, worauf der aktuelle Inhalt 12 tatsächlich dargestellt wird.
Veröffentlichen des digitalen Inhaltes
3 ist ein Funktionsblockdiagramm eines Systems und eines Verfahrens zum Veröffentlichen digitalen Inhaltes. "Veröffentlichen", wie der Begriff hier verwendet wird, bezieht sich auf einen Vorgang, dem eine Applikation oder ein Dienst folgt, um mit einer vertraulichen Einheit einen Satz von Rechten und Bedingungen einzurichten, den die Einheit für diesen Inhalt ausgeben kann, wie auch einzurichten, an wen diese Rechte und Bedingungen ausgegeben werden können. Gemäß der Erfindung beinhaltet der Veröffentlichungsvorgang das Verschlüsseln des digitalen Inhaltes und das Zuordnen einer Liste von beständigen, durchsetzbaren Rechten, die der Autor des Inhaltes für sämtliche mögliche Benutzer des Inhaltes beabsichtigt hatte. Dieser Vorgang kann auf sichere Weise ausgeführt werden, um einen Zugriff auf ein beliebiges der Rechte oder den Inhalt zu verhindern, solange es vom Autor des Inhaltes nicht beabsichtigt ist.
Insbesondere werden drei Einheiten verwendet, um einen sicheren digitalen Inhalt zu veröffentlichen: eine Inhaltsvorbereitungs-Applikation 302, die auf dem Client 300 ausgeführt wird und den Inhalt für die Veröffentlichung vorbereitet, eine DRM-API (API – Applikationsprogramm-Schnittstelle) 306, die sich ebenfalls auf der Client-Vorrichtung 300 befindet, und ein DRM-Server 320, der mit dem Client 300 über ein Kommunikationsnetzwerk 330, wie etwa das Internet, ein lokales Netzwerk oder ein Weitbereichsnetzwerk oder eine Kombination aus beiden kommunikativ gekoppelt ist.
Die Inhaltsvorbereitungs-Applikation 302 kann eine beliebige Applikation sein, die digitalen Inhalt erzeugt. Beispielsweise kann die Applikation 302 eine Textverarbeitung oder eine andere Veröffentlichungseinrichtung sein, die digitale Textdateien, digitale Musik, Video oder anderen derartigen Inhalt erzeugt. Der Inhalt könnte beispielsweise gestreamten Inhalt, wie etwa gestreamtes Audio/Video eines live stattfindenden oder auf Band aufgezeichneten Ereignisses beinhalten. Die Applikation 302 ist mit einem Verschlüsselungs-Schlüssel ausgestattet, um den digitalen Inhalt zu verschlüsseln, wodurch eine verschlüsselte Digitalinhaltsdatei 304 ausgebildet wird, wobei der Benutzer Rechtedaten bereitstellt, die dem verschlüsselten Inhalt in der Digitalinhaltsdatei 304 eng zugeordnet sind. Die Rechtedaten enthalten eine Identität für jede Einheit, die Rechte am digitalen Inhalt hat, sowie einen Satz von Rechten und Bedingungen für jede identifizierte Einheit.
Eine derartige Einheit kann beispielsweise ein Individuum, eine Klasse von Individuen oder eine Vorrichtung sein. Derartige Rechte können das Recht zum Lesen, Editieren, Kopieren, Drucken, etc. des digitalen Inhaltes beinhalten. Bedingungen können minimale Systemanforderungen, Datum und Zeitbegrenzungen, Abspielzahlen und dergleichen beinhalten.
Die Client-API 306 leitet den verschlüsselten digitalen Inhalt und die Rechtedaten an den DRM-Server 320 weiter. Mit Hilfe eines Vorgangs, der unten im Detail beschrieben ist, bestimmt der DRM-Server 320, ob er die Rechtedaten durchsetzen kann, und wenn dies der Fall ist, signiert der DRM-Server 320 die Rechtedaten, um einen signierten Rechtekennsatz (SRL) 308 zu erzeugen. Im allgemeinen kann jedoch eine beliebige vertrauliche Einheit die Rechtedaten vorzugsweise mit Hilfe eines Schlüssels signieren, dem durch den DRM-Server 320 vertraut wird. Beispielsweise kann ein Client die Rechtedaten mit Hilfe eines Schlüssels signieren, die ihm vom DRM-Server 320 zugeführt werden.
Der Rechtekennsatz 308 kann Daten enthalten, die die Rechtebeschreibung, den Schlüssel des verschlüsselten Inhaltes und die digitale Signatur über die Rechtebeschreibung und den Schlüssel des verschlüsselten Inhaltes repräsentieren. Wenn der DRM-Server 320 den Rechtekennsatz signiert, leitet er den signierten Rechtekennsatz 308 zurück zum Client durch die Client-API 306, die den signierten Rechtekennsatz 308 in der Client-Vorrichtung 300 speichert. Die Inhaltsvorbereitungs-Applikation 302 ordnet anschließend den signierten Rechtekennsatz 308 der verschlüsselten Digitalinhaltsdatei 304 etwa durch Dateiverknüpfung zu, um eine Datei 310 rechteverwalteten Inhalts auszubilden. Es wird jedoch darauf hingewiesen, dass der SRL 308 an einem bekannten Ort getrennt von der Inhaltsdatei 304 mit einem Verweis auf den SRL 308 gespeichert werden kann, der mit der Inhaltsdatei 304 verknüpft ist, um die Inhaltsdatei 310 zu bilden.
Wendet man sich nun 4 zu, so ist ein Verfahren zum Veröffentlichen des rechteverwalteten digitalen Inhaltes dargestellt. Bei Schritt 402 erzeugt die Applikation 302 einen Inhaltsschlüssel (CK), der verwendet wird, um den digitalen Inhalt zu verschlüsseln. Der Inhaltsschlüssel (CK) ist normalerweise ein symmetrischer Schlüssel, wenngleich ein beliebiger Schlüssel verwendet werden kann, um den digitalen Inhalt zu verschlüsseln. Wie es bekannt ist, wird ein symmetrischer Schlüssel von einem symmetrischen Schlüsselalgorithmus sowohl zum verschlüsseln als auch entschlüsseln verwendet. Demzufolge sollte der (CK) gut verborgen sein, wenn er von einem Sender und einem Empfänger gemeinsam genutzt wird.
Bei Schritt 404 verschlüsselt die Applikation 302 den digitalen Inhalt mit (CK), um verschlüsselten digitalen Inhalt 304 (d.h. (CK(Inhalt))) auszubilden. Darüber hinaus werden Rechtedaten entsprechend (CK(Inhalt)) entweder durch den Veröffentlicher des Inhaltes oder durch eine andere Einheit erzeugt. Es wird darauf hingewiesen, dass derartige Rechtedaten speziell angefertigte Rechtedaten oder Rechtedaten sein können, wie man sie aus einer vordefinierten Vorlage erhält. Wie es oben erläutert wurde, können die Rechtedaten eine Liste von Einheiten, die berechtigt sind, den Inhalt zu verbrauchen, die spezifischen Rechte, die jede der Einheiten im Bezug auf den Inhalt besitzt, und beliebige Bedingungen enthalten, die für diese Rechte bestehen.
Bei Schritt 406 erzeugt die API 306 einen zweiten Verschlüsselungs-Schlüssel (K2), der verwendet wird, um den Inhaltsschlüssel (CK) zu verschlüsseln. Vorzugsweise ist (K2) ebenfalls ein symmetrischer Schlüssel. Bei Schritt 408 verschlüsselt die API 306 (CK) mit (K2), was zu (K2(CK)) führt. Bei Schritt 410 verwirft die API 306 (CK) mit dem Ergebnis, dass (CK) nun lediglich durch Entschlüsseln von (K2(CK)) bezogen werden kann. Um sicherzustellen, dass (CK(Inhalt)) für einen zentralen DRM-Server 320 geschützt ist, und dass sämtliche "Lizenzanfragen" für den Inhalt zentral gemäß der Rechtedaten ausgeführt werden, kontaktiert die API 306 bei Schritt 412 den bereitgestellten DRM-Server 320 und fragt den öffentlichen Schlüssel (PU-DRM) davon ab. Bei Schritt 414 verschlüsselt die API 306 (K2) mit (PU-DRM), was zu (PU-DRM K2)) führt. Somit kann (CK) für (PU-DRM) geschützt werden, um sicherzustellen, dass der DRM-Server 320 die einzige Einheit ist, die in der Lage sein wird, Zugriff auf (CK) zu erlangen, wie es erforderlich ist, um (CK(Inhalt)) zu entschlüsseln. Bei Schritt 416 verschlüsselt die API 306 die Rechtedaten (d.h. die Liste autorisierter Einheiten und die entsprechenden Rechte sowie Bedingungen, die jeden autorisierten Einheiten in der Liste zugeordnet sind) mit (K2), was zu (K2(Rechtedaten)) führt.
Bei einer alternativen Ausführungsform, kann (CK) verwendet werden, um direkt die Rechtedaten zu verschlüsseln, was zu (CK(Rechtedaten)) führt, und (PU-DRM) kann verwendet werden, um direkt (CK) zu verschlüsseln, was zu (PU-DRM(CK)) führt, wodurch auf die Verwendung von (K2) vollständig verzichtet wird. Die Ver- Wendung von (K2) zur Verschlüsselung der Rechtedaten und (CK) gestattet es jedoch, dass (K2) einem beliebigen Algorithmus entspricht, der für den DRM-Server zugänglich ist, wohingegen (CK) durch eine Einheit unabhängig vom DRM-Server festgelegt werden kann und für diesen nicht in gleicher Weise zugänglich sein kann.
Bei Schritt 418 führt die Inhaltsschutz-Applikation 302 (PU-DRM(K2)) und (K2(Rechtedaten) dem DRM-Server 320 als Rechtekennsatz zum Signieren zu. Alternativ kann der Client selbst die Rechtedaten in der Weise signieren, wie es im folgenden beschrieben ist. Wenn die Rechtedaten dem Server zum Signieren zugeführt werden, dann greift bei Schritt 420 der DRM-Server 320 auf die Rechtedaten zu und verifiziert, dass er die Rechte und Bedingungen im zugeführten Rechtekennsatz durchsetzen kann. Um zu verifizieren, dass er die Rechtedaten durchsetzen kann, wendet der DRM-Server 320 den privaten Schlüssel (PR-DRM) entsprechend (PU-DRM) bis (PU-DRM(K2)) an, was zu (K2) führt, und wendet anschließend (K2) auf (K2(Rechtedaten) an, was zu einer Nullstellung der Rechtedaten führt. Der Server 320 kann anschließend beliebige Richtlinienprüfungen ausführen um zu verifizieren, dass sich die Benutzer, Rechte und Bedingungen, die in den Rechtedaten festgelegt sind, innerhalb einer Richtlinie befinden, die vom Server 320 durchgesetzt wird. Der Server 320 signiert den ursprünglich zugeführten Rechtekennsatz, der (PU-DRM(K2)) und (K2(Rechtedaten)) enthält, was zum signierten Rechtekennsatz (SRL) 308 führt, wobei die Signatur auf dem privaten Schlüssel des DRM-Servers 320 (PR-DRM) basiert, und gibt SRL 308 zurück zur API 306, die anschließend den zurückgegebenen SRL 308 der Client-Applikation 302 darbietet.
Der SRL 308 ist ein Dokument, das digital signiert ist, wodurch es fälschungssicher ist. Darüber hinaus ist der SRL 308 unabhängig vom tatsächlichen Schlüsseltyp und Algorithmus, der verwendet wird, behält jedoch die starke 1-1-Beziehung zum Inhalt bei, den er schützt. Wendet man sich nun 4A zu, kann bei einer Ausführungsform der vorliegenden Erfindung der SRL 308 Informationen über den Inhalt, der die Basis des SRL 308 ist, enthalten, der möglicherweise unter anderem beinhaltet: eine ID des Inhaltes; Informationen über den DRM-Server, der den SRL 308 signiert, einschließlich (PU-DRM(K2)) und Bezugsinfor mationen, wie etwa einen URL zum Lokalisieren des DRM-Servers in einem Netzwerk und Rückgriffsinformationen für den Fall, dass die URL fehlschlägt; Informationen, die den SRL 308 an sich beschreiben; (K2(Rechtedaten)): (K2(CK)); und eine digitale Signatur (S(PR-DRM)).
Durch Sicherstellen, dass die vertrauliche Einheit die Rechtedaten signiert, um einen signierten Rechtekennsatz 308 zu erzeugen, bestätigt der DRM-Server 320, dass er Lizenzen für den Inhalt in Übereinstimmung mit den Auflagen ausgibt, die vom Veröffentlicher festgelegt sind, wie es in den Rechtedaten des Rechtekennsatzes 308 beschrieben ist. Es wird darauf hingewiesen, dass ein Benutzer eine Lizenz erwerben muss, um den Inhalt wiederzugeben, insbesondere insoweit, als dass die Lizenz den Inhaltsschlüssel (CK) enthält. Wenn ein Benutzer eine Lizenz für den verschlüsselten Inhalt erwerben möchte, kann der Benutzer eine Lizenzanfrage darbieten, die den SRL 308 für den Inhalt und ein Zertifikat beinhaltet, dass die Berechtigungsnachweise des Benutzers für den DRM-Server 320 oder eine andere lizenzvergebende Einheit verifiziert. Die lizenzvergebende Einheit kann anschließend (PU-DRM(K2)) und (K2(Rechtedaten)) entschlüsseln, um die Rechtedaten zu erzeugen, sämtliche Rechte auflisten, die vom Autor (sofern vorhanden) der lizenzanfragenden Einheit gewährt sind, und eine Lizenz mit lediglich diesen speziellen Rechten aufbauen.
Wie es oben beschrieben wurde, verknüpft, wenn die Applikation 320 den SRL 308 empfängt, diese Applikation den signierten Rechtekennsatz 308 mit dem entsprechenden (CK(Inhalt) 304, um rechteverwalteten digitalen Inhalt auszubilden. Alternativ werden die Rechtedaten an einem bekannten Ort gespeichert, wobei ein Verweis auf diesen Ort mit dem verschlüsselten digitalen Inhalt bereitgestellt wird. Somit kann eine Wiedergabe-Applikation, die DRM-fähig ist, den signierten Rechtekennsatz 308 über das Stück des Inhaltes entdecken, den die Wiedergabe-Applikation versucht darzustellen. Diese Entdeckung löst die Wiedergabe-Applikation aus, um eine Lizenzanfrage gegenüber dem DRM-Lizenzierungsserver 320 zu initiieren. Die Veröffentlichungs-Applikation 302 kann beispielsweise einen URL zum DRM-Lizenzierungsserver 320 speichern, oder der DRM-Lizenzierungsserver 320 kann seinen eigenen URL als ein Stück von Metadaten in den Rechtekennsatz einbetten, bevor er diesen digital signiert, so dass die DRM- Client-API 306, die von der Wiedergabe-Applikation aufgerufen wird, den korrekten DRM-Lizenzierungsserver 320 identifizieren kann.
Erwerben einer Lizenz für den veröffentlichten Inhalt
Unter Bezugnahme auf 5 sind nun ein System und ein Verfahren zum Lizenzieren rechteverwalteten digitalen Inhaltes dargestellt. "Lizenzieren", wie der Begriff hier verwendet wird, bezieht sich auf einen Vorgang, dem eine Applikation oder ein Dienst folgt, um eine Lizenz anzufordern und zu empfangen, die die Einheit, die in der Lizenz erwähnt ist, in die Lage versetzt, den Inhalt gemäß den Vorgaben zu verbrauchen, die in der Lizenz festgelegt sind. Eingaben an den Lizenzvorgang können den signierten Rechtekennsatz (SRL) 308, der dem Inhalt zugeordnet ist, für den eine Lizenz angefordert wird, und das (die) Zertifikat(e) des öffentlichen Schlüssels der Einheit(en) beinhalten, für die die Lizenz angefordert wird. Es wird darauf hingewiesen, dass die Einheit, die eine Lizenz anfordert, nicht unbedingt die Einheit sein muss, für die die Lizenz angefordert wird. Normalerweise enthält eine Lizenz die Rechtebeschreibung von SRL 308, einen verschlüsselten Schlüssel, der den verschlüsselten Inhalt entschlüsseln kann, und eine digitale Signatur über die Rechtebeschreibung und den verschlüsselten Schlüssel, um die Rechtmäßigkeit sicherzustellen und eine Fälschung zu verhindern.
Zu Beginn leitet die Client-API 306 den signierten Rechtekennsatz 308 des rechteverwalteten Inhaltes 310 zum DRM-Server 320 über das Kommunikationsnetzwerk 330 weiter. Wie es oben erläutert wurde, enthält der Rechtekennsatz 308 den Inhaltsschlüssel (CK), der gemäß dem öffentlichen Schlüssel des DRM-Servers 320 (PU-DRM) (d.h. (PU-DRM(CK))) verschlüsselt ist. Beim Vorgang des Ausgebens einer Lizenz wendet anschließend der DRM-Server 320 (PR-DRM) auf (PU-DRM(CK)) an, um (CK) zu erhalten. Er verwendet anschließend den öffentlichen Schlüssel (PU-EINHEIT) im Zertifikat des öffentlichen Schlüssels, der bei der Lizenzanforderung weitergegeben wird, um (CK) (d.h. PU-EINHEIT(CK))) erneut zu verschlüsseln. Der erneut verschlüsselte (PU-EINHEIT(CK)) wird anschließend in der Lizenz plaziert. Somit kann die Lizenz zum Anrufer zurückgegeben werden, ohne dass das Risiko besteht (CK) preiszugeben, da lediglich der Inhaber des pri vaten Schlüssels (PR-EINHEIT) entsprechend (PU-EINHEIT) (CK) aus (PU-EINHEIT(CK)) wiederherstellen kann. Die Client-API 306 verwendet anschließend (CK), um den verschlüsselten Inhalt zu entschlüsseln, um entschlüsselten digitalen Inhalt 312 zu bilden. Die Client-Applikation 302 kann anschließend den entschlüsselten digitalen Inhalt 312 gemäß der Rechte verwenden, die in der Lizenz bereitgestellt sind.
Alternativ, und wie es im folgenden detaillierter beschrieben ist, kann ein Client, wie etwa der veröffentlichende Client, beispielsweise eine Nutzungslizenz an sich selbst ausgeben, um den Inhalt zu verwenden.
Wendet man sich nun 6A und 6B zu, so ist ein Verfahren zum Lizenzieren von rechteverwaltetem digitalem Inhalt dargestellt. Bei Schritt 602 empfängt eine lizenzvergebende Einheit, wie etwa ein DRM-Server 320 eine Lizenzanforderung, die entweder ein Zertifikat eines öffentlichen Schlüssels oder eine Identität für jede von einer oder mehreren angeforderten Lizenzen enthält. Wenn eine Identität festgelegt ist, kann der DRM-Server 320 ein entsprechendes Zertifikat eines öffentlichen Schlüssels aus einem Verzeichnis, einer Datenbank oder dergleichen erzeugen. Wird eine Lizenz für lediglich einen Lizenznehmer angefordert, wird lediglich ein Zertifikat oder eine Identität benannt. Wird eine Lizenz für eine Vielzahl von Lizenznehmern angefordert, kann ein Zertifikat oder eine Identität für jeden potentiellen Lizenznehmer benannt werden. Bei Schritt 604 wird die anfordernde Einheit (d.h. die Einheit, die die Lizenzanforderung durchführt) authentisiert, sofern dies erwünscht ist. Bei Schritt 606 wird bestimmt, ob es der Einheit gestattet ist, eine Lizenz anzufordern, wiederum, sofern dies gewünscht ist.
Wenn bei einem Schritt 608 die ausgebende Einheit bestimmt, dass das Zertifikat des öffentlichen Schlüssels nicht in der Lizenzanforderung enthalten ist, dann verwendet die ausgebende Einheit die festgelegte Identität, um eine Suche in einem Verzeichnisdienst oder einer Datenbank nach dem geeigneten Zertifikat des öffentlichen Schlüssels auszuführen. Wenn in einem Schritt 610 die ausgebende Einheit bestimmt, dass sich das Zertifikat im Verzeichnis befindet, dann wird in Schritt 612 das Zertifikat abgerufen. Wenn ein Zertifikat für einen gegebenen potentiellen Lizenznehmer weder bei der Anforderung noch im Verzeichnis gefunden werden kann, dann erzeugt der Lizenzserver keine Lizenz für diesen potentiellen Lizenznehmer und es wird bei Schritt 614 ein Fehler zur anfordernden Einheit zurückgesendet.
Unter der Voraussetzung, dass der DRM-Server 320 das Zertifikat des öffentlichen Schlüssels für wenigstens einen potentiellen Lizenznehmer hat, validiert in Schritt 616 dieser DRM-Server 320 das Vertrauen jedes Lizenznehmer-Zertifikates. Erfolgt keine Validierung, bestimmt der DRM-Server 320, dass der Herausgeber des Lizenznehmer-Zertifikates nicht auf der Liste zu vertrauender Herausgeber ist, worauf die Anforderung für diese Lizenz fehlschlägt und ein Fehler bei Schritt 614 erzeugt wird. Somit würde ein beliebiger potentieller Lizenznehmer, dessen Zertifikat nicht von einem zu vertrauenden Herausgeber herausgegeben wird, keine Lizenz erhalten.
Zusätzlich führt der DRM-Server 320 vorzugsweise eine Validierung der digitalen Signatur bei sämtlichen Einheiten in der Zertifikatskette aus, die von den zu vertrauenden Herausgeber-Zertifikaten zu den individuellen Lizenznehmer-Zertifikaten des öffentlichen Schlüssels reicht. Der Vorgang des Validierens der digitalen Signaturen in einer Kette ist ein hinlänglich bekannter Algorithmus. Wenn das Zertifikat des öffentlichen Schlüssels für einen gegebenen potentiellen Lizenznehmer nicht validiert, oder ein Zertifikat in der Kette nicht validiert, wird dem potentiellen Lizenznehmer nicht vertraut und somit eine Lizenz an diesen potentiellen Lizenznehmer nicht ausgegeben. Andernfalls kann bei Schritt 618 eine Lizenz ausgegeben werden. Der Vorgang wiederholt sich bei Schritt 620, bis sämtliche Einheiten verarbeitet wurden, für die eine Lizenz angefordert wurde.
Wie es in 6B gezeigt ist, schreitet der DRM-Server 320 fort, um den signierten Rechtekennsatz 308 zu validieren, der bei der Lizenzanforderung empfangen wird. Bei einer Ausführungsform verfügt der DRM-Server 320 über eine Master-Kopie jedes Rechtekennsatzes, das dadurch signiert wird. Zum Lizenzzeitpunkt kann (bei Schritt 622) der DRM-Server 320 anschließend eine Kopie des Master-Rechtekennsatzes abrufen. Der Master-Rechtekennsatz kann aktueller sein als die Kopie des Rechtekennsatzes, die in der Lizenzanforderung gesendet wird, und ist somit der Rechtekennsatz, der verwendet wird, um die angeforderte Lizenz zu erzeugen. Wird kein Master-Rechtekennsatz gefunden, bestimmt der DRM-Server 320 bei Schritt 624 gemäß der vordefinierten Richtlinie, ob eine Lizenz auf der Basis des Rechtekennsatzes in der Anforderung ausgegeben werden soll. Lässt dies die Richtlinie nicht zu, schlägt die Lizenzanforderung bei Schritt 626 fehl, und es wird ein Fehler zur API 306 bei Schritt 628 zurückgesendet.
Bei Schritt 630 validiert der DRM-Server 320 den SRL 308 und insbesondere dessen digitale Signatur. Validiert der SRL 308 nicht, schlägt die Lizenzanforderung bei Schritt 626 fehl und es wird ein Fehler zur API 306 bei Schritt 628 zurückgesendet.
Nachdem sämtliche Validierungen erfolgt sind, baut der DRM-Server eine Lizenz für jede bestätigte Lizenz auf der Basis des SRL 308 auf. Bei Schritt 632 erzeugt der DRM-Server 320 eine entsprechende Rechtebeschreibung für die Lizenz, die an jeden Lizenznehmer ausgegeben werden soll. Für jeden Lizenznehmer bewertet der DRM-Server 320 die Identität, die im Zertifikat des öffentlichen Schlüssels dieses Lizenznehmers benannt ist, gegenüber den Identitäten, die in der Rechtebeschreibung im Rechtekennsatz benannt sind. Bei Schritt 636 bezieht der DRM-Server 320 (PU-DRM(K2)) und (K2(CK)) vom SRL 308 und wendet (PR-DRM) an, um (CK) zu beziehen. Die ausgebende Einheit verschlüsselt (CK) erneut mit Hilfe von (PU-EINHEIT) aus dem Lizenznehmer-Zertifikat des öffentlichen Schlüssels, was zu (PU-EINHEIT(CK)) führt. Bei Schritt 638 verknüpft der DRM-Server 320 die erzeugte Rechtebeschreibung mit (PU-EINHEIT(CK)) und signiert digital die resultierende Datenstruktur mit Hilfe von (PR_DRM) (d.h. S (PR-DRM)). Die signierte Datenstruktur ist somit die Lizenz für diesen speziellen Lizenznehmer.
Bei Schritt 640 bestimmt der DRM-Server 320, dass es keine weiteren Lizenzen gibt, die für die spezielle Anforderung erzeugt werden sollen. Die erzeugten Lizenzen werden anschließend zur anfordernden Einheit bei Schritt 642 zusammen mit einer geeigneten Zertifikatskette zurückgesendet, die die Lizenzen wieder an eine zu vertrauende Autorität bindet.
Eigenes Veröffentlichen des signierten Rechtekennsatzes 308
Bei einer Ausführungsform der vorliegenden Erfindung kann der SRL 308 durch den anfordernden/veröffentlichenden Benutzer selbst signiert werden. Demzufolge muss ein derartiger Benutzer nicht den DRM-Server 320 kontaktieren, um einen SRL 308 für ein zugeordnetes Inhaltsstück zu beziehen. Infolge dessen kann eigenes Veröffentlichen auch als Off-Line-Veröffentlichen bezeichnet werden. Bei einer derartigen Ausführungsform sollte der Veröffentlicher auch in der Lage sein, sich selbst eine Veröffentlicher-Lizenz auszugeben, insbesondere insoweit, als dass der selbst veröffentlichte Inhalt nun DRM-geschützt ist und eine derartige Veröffentlicher-Lizenz erforderlich ist, um es dem veröffentlichenden Benutzer zu gestatten, den nun geschützten Inhalt wiederzugeben. Es versteht sich, dass ein veröffentlichender Benutzer in die Lage versetzt sein kann, Lizenzen an andere Benutzer auszugeben.
Insbesondere und unter Bezugnahme auf 7 wird bei der Ausführungsform ein offline veröffentlichender Benutzer zunächst in die Lage versetzt, offline zu veröffentlichen, indem er vom DRM-Server 320 ein Off-Line-Veröffentlichungs-(OLP-) Zertifikat 810 empfängt, das einen öffentlichen Schlüssel (PU-OLP) und einen entsprechenden privaten Schlüssel (PR-OLP) enthält, der gemäß einem öffentlichen Schlüssel verschlüsselt ist, der direkt oder indirekt zugänglich zur vertraulichen Komponente 18 (11) des Benutzers (PU-EINHEIT) ist, was zu (PU_EINHEIT(PR-CERT)) führt. Es wird darauf hingewiesen, dass (PU-EINHEIT) beispielsweise der öffentliche Schlüssel der vertraulichen Komponente 18 oder ein öffentlicher Schlüssel sein kann, der mit Hilfe des öffentlichen Schlüssels der vertraulichen Komponente 18 zugänglich ist. Das OLP-Zertifikat 810 sollte durch den privaten Schlüssel des DRM-Servers 320 (PR-DRM) so signiert sein, dass der DRM-Server 320 ein derartiges OLP-Zertifikat verifizieren kann, wie es detaillierter unten beschrieben ist.
Darüber hinaus sollte das OLP-Zertifikat 810 eine Zertifikatskette von (PU-DRM) zurück zur vertraulichen Autorität beinhalten, der durch die vertrauliche Komponente 18 des veröffentlichenden Benutzers oder eines anderen Benutzers vertraut wird, so dass eine derartige vertrauliche Komponente 18 ein derartiges OLP- Zertifikat 810 und ein beliebiges anderes Zertifikat oder eine Lizenz verifizieren kann, die einem derartigen OLP-Zertifikat 810 zugeordnet ist, wie es unten beschrieben werden wird. Kurz gesagt, und wie es verständlich sein sollte, beginnt eine Kette von Zertifikaten mit einem Ursprungszertifikat, das durch den privaten Schlüssel einer vertraulichen Autorität signiert ist und über den öffentlichen Schlüssel des nächsten Zertifikates in der Kette verfügt. Jedes Zwischenzertifikat in der Kette wird anschließend durch den privaten Schlüssel entsprechend dem öffentlichen Schlüssel des vorherigen Zertifikates in der Kette signiert und verfügt über den öffentlichen Schlüssel des nächsten Zertifikates in der Kette. Schließlich wird das Zertifikat oder die Lizenz, an die die Kette angefügt ist, durch den privaten Schlüssel entsprechend dem öffentlichen Schlüssel des letzten Zertifikates in der Kette signiert.
Um das Zertifikat oder die Lizenz zu verifizieren, an die die Kette angefügt ist, wird somit Wissen über den öffentlichen Schlüssel entsprechend dem privaten Schlüssel der vertraulichen Autorität erworben, wobei ein derartiger öffentlicher Schlüssel der vertraulichen Autorität verwendet wird, um die Signatur des Ursprungszertifikates in der Kette zu verifizieren. Vorausgesetzt, die Ursprungszertifikat-Signatur wird verifiziert, dann wird der öffentliche Schlüssel vom Ursprungszertifikat bezogen und verwendet, um die Signatur des ersten Zwischenzertifikates in der Kette zu verifizieren. Der Vorgang wiederholt sich seriell durch die Kette, bis jede Signatur derselben verifiziert ist, und anschließend wird der öffentliche Schlüssel vom letzten Zwischenzertifikat in der Kette bezogen und verwendet, um die Signatur des Zertifikates oder der Lizenz zu verifizieren, an die die Kette angefügt ist.
Es wird darauf hingewiesen, dass das OLP-Zertifikat 810 eine Verknüpfung in der Kette des Vertrauens zwischen dem Inhalt 304, der off-line veröffentlicht werden soll, und dem DRM-Server 320 herstellt, der eine Lizenz für den Inhalt 304 ausgeben wird. Das OLP-Zertifikat 810 kann auf der Basis einer XML/XrML-Sprache oder einer anderen geeigneten Sprache erzeugt werden.
Es wird ebenfalls darauf hingewiesen, dass das OLP-Zertifikat 810 und die angefügte Zertifikatskette den veröffentlichenden Benutzer autorisieren, selbst zu veröffentlichen. Es wird weiter darauf hingewiesen, dass das Schlüsselpaar (PU-OLP, PR-OLP) von (PU-EINHEIT, PR-EINHEIT) getrennt ist und insbesondere zur eigenen Veröffentlichung verwendet wird. Es wird darauf hingewiesen, dass auf das Schlüsselpaar (PU-OLP, PR-OLP) verzichtet werden kann, wobei in diesem Fall das DRM-Zertifikat 810 lediglich den öffentlichen Schlüssel des Benutzers (PU-EINHEIT) enthält und durch den privaten Schlüssel des DRM-Servers 320 (PR-DRM) signiert wird, so dass der DRM-Server 320 denselben verifizieren kann.
Die eigene Veröffentlichung unterscheidet sich von der Veröffentlichung, wie sie in 4 gezeigt ist, dadurch, dass der Benutzer im wesentlichen die Stelle des DRM-Servers 320 im Bezug auf Schritte einnimmt, die dadurch ausgeführt werden. Bezeichnenderweise signiert der Benutzer den zugeführten Rechtekennsatz, der (PU-DRM(K2)) und (K2(Rechtedaten)) enthält oder (PU-DRM(CK)) und (CK(Rechtedaten)) (wobei letztere in 7 und 8 gezeigt sind) enthält, mit (PR-OLP), wie man es aus dem DRM-Zertifikat 810 (d.h. S(PR-OLP)) erhält, was zum signierten Rechtekennsatz (SRL) 308 führt. Die vertrauliche Komponente 18, die Client bei der Verwendung des OLP-Zertifikates 810 ist, verifiziert normalerweise dasselbe auf der Basis der angefügten Zertifikatskette. Es wird darauf hingewiesen, das die vertrauliche Komponente 18 des Benutzers (PR-OLP) vom OLP-Zertifikat 810 bezieht, indem sie (PU-EINHEIT(PR-OLP)) aus einem derartigen OLP-Zertifikat 810 bezieht und (PR-EINHEIT) darauf anwendet. Es wird jedoch darauf hingewiesen, dass der veröffentlichende Benutzer nicht verifizieren kann, dass der DRM-Server 320 die Rechte in einem selbst veröffentlichten SRL 308 durchsetzen kann. Demzufolge sollte der DRM-Server 320 an sich die Verifizierung zu dem Zeitpunkt, zu dem eine Lizenz angefordert wird, auf der Basis des selbst veröffentlichten SRL 308 ausführen.
Sobald der veröffentlichende Benutzer den SRL 308 selbst veröffentlicht, bündelt der Benutzer einen derartigen selbst veröffentlichten SRL 308 und das OLP-Zertifikat 810, das verwendet wird, um denselben zu erzeugen, zum Inhalt 304, wobei dieser Inhalt 304 mit dem SRL 308 und dem DRM-Zertifikat 810 als rechteverwalteter Inhalt 310 zu einem weiteren Benutzer verteilt wird. Anschließend fordert der weitere Benutzer eine Lizenz für den Inhalt 304/310 vom DRM-Server 320 in der im wesentlichen selben Weise an, wie es in 6A und 6B gezeigt ist, und bezieht diese von ihm. Hier führt der lizenzanfordernde Benutzer dem DRM-Server 320 jedoch sowohl den selbst veröffentlichten SRL 308 als auch das OLP-Zertifikat 810 zu, die zum Inhalt 304 gebündelt sind. Der DRM-Server 320 verifiziert S (PR-DRM) im OLP-Zertifikat 810 auf der Basis des entsprechenden (PU-DRM) und bezieht (PU-OLP) vom DRM-Zertifikat 810. Der DRM-Server 320 verifiziert anschließend S (PR-OLP) im SRL 308 auf der Basis des bezogenen (PU-CERT) und fährt wie zuvor beschrieben fort. Es wird jedoch darauf hingewiesen, dass, da der veröffentlichende Benutzer nicht verifizierte, dass der DRM-Server 320 die Rechte im SRL 308 durchsetzen kann, wie es oben beschrieben wurde, der DRM-Server 320 die Verifizierung zu diesem Zeitpunkt selbst durchführen sollte.
Es wird ebenfalls darauf hingewiesen, dass der DRM-Server 320 lediglich S (PR-DRM) im OLP-Zertifikat 810 verifizieren muss, da er vermutlich sich selbst vertraut. Demzufolge muss die zugehörige Zertifikatskette vom OLP-Zertifikat 810 nicht notwendigerweise zum DRM-Server 320 zusammen mit diesem OLP-Zertifikat 810 gesendet werden, solange die Kette natürlich nicht anderweitig erforderlich ist, wie etwa wenn die Kette an sich wenigsten teilweise die Basis für S (PR-DRM) ist.
Es ist jedoch wichtig, dass der veröffentlichende Benutzer in der Lage ist, den nun geschützten Inhalt 304/310 wiederzugeben, ohne vom DRM-Server 320 eine Lizenz zu erhalten. Anders gesagt sollte ein veröffentlichender Benutzer, der, ohne zum DRM-Server 320 zu gehen, offline Inhalt 304/310 auf der Basis eines OLP-Zertifikates 810 veröffentlicht, in der Lage sein, selbst eine Lizenz off-line auszugeben, ohne zum DRM-Server 320 zu gehen, so dass der Benutzer den offline veröffentlichten Inhalt 304/310 wiedergeben kann. Demzufolge kann ein veröffentlichender Benutzer damit fortfahren, mit dem selbst veröffentlichten Inhalt 310 ohne Verbindung zu einem DRM-Server 320 zu arbeiten.
Bei einer Ausführungsform der vorliegenden Erfindung und unter Bezugnahme auf 8 gibt ein veröffentlichender Benutzer selbst eine Off-Line-Veröffentlicher-Lizenz 820 aus, die durch (PR-OLP) signiert ist und auf der selbst veröffentlichten SRL 308 basiert und das OLP-Zertifikat sowie dessen Kette enthält. Vermutlich gewährt die Veröffentlicher-Lizenz 820 dem veröffentlichenden Benutzer vollen Zugriff auf den selbst veröffentlichten Inhalt 310, wenngleich ein geringerer Umfang des Zugriffs ebenfalls gewährt werden könnte. Die Veröffentlicher-Lizenz 820 kann in einer XML/XrML-Sprache oder einer weiteren Sprache geschrieben sein, wie dies bei anderen DRM-Lizenzen der Fall ist. Es wird darauf hingewiesen, dass die Veröffentlicher-Lizenz 820 den Inhaltsschlüssel (CK) enthält, der gemäß (PU-EINHEIT) verschlüsselt ist und der von der vertraulichen Komponente 18 der Berechungsvorrichtung 14 bezogen werden kann, um (PU-EINHEIT(CK)) zu bilden.
Die Kette für die Veröffentlicher-Lizenz 820 reicht somit von einer derartigen Lizenz 820 zum OLP-Zertifikat 810 und dann zurück zu einem Ursprungszertifikat von einer vertraulichen Autorität, möglicherweise mit Hilfe eines oder mehrerer Zwischenzertifikate. Da die vertrauliche Komponente 18 des Benutzers vermutlich den öffentlichen Schlüssel entsprechend dem privaten Schlüssel der vertraulichen Autorität erlangen kann, die verwendet wurde, um das Ursprungszertifikat zu signieren, kann die vertrauliche Komponente 18 an sich die Veröffentlicher-Lizenz 820 mit Hilfe der Zertifikatskette derselben verifizieren und bei Verifizierung anschließend (PU-EINHEIT(CK)) davon beziehen, (PR-EINHEIT) darauf anwenden, um (CK) zu erhalten und (CK) auf (CK(INHALT)) anwenden, was zum Inhalt 304 zu dessen Wiedergabezwecken führt. Infolgedessen kann der veröffentlichende Benutzer damit fortfahren, mit dem Inhalt 310 zu arbeiten, der dadurch offline veröffentlicht wurde, während er offline bleibt.
In Übereinstimmung mit dem oben Erwähnten und unter Bezugnahme auf 9, veröffentlicht anschließend ein veröffentlichender Benutzer den Inhalt 304/310 und gibt selbst eine Off-Line-Veröffentlicher-Lizenz 820 für einen derartigen Inhalt 304/310 in der folgenden Art und Weise aus.
Es wird darauf hingewiesen, dass zunächst der Inhalt 304 in einer geeigneten Art und Weise entwickelt und gemäß einem Inhaltsschlüssel (CK) verschlüsselt wird (Schritt 901) und der veröffentlichende Benutzer einen Rechtekennsatz für den Inhalt 304 mit geeigneten Informationen {z.B. (PU-DRM(CK)) und (CK(Rechtedaten))} erzeugt (Schritt 903). Anschließend bezieht der veröffentlichende Benutzer, der vermutlich bereits im Besitz eines OLP-Zertifikates 810 vom DRM-Server 320 ist, ein derartiges OLP-Zertifikat 810 (Schritt 905) und verifiziert dasselbe auf der Basis der Signatur desselben und der Kette von Zertifikaten, die zurück zur Ursprungsautorität (Schritt 907) führen. Es wird darauf hingewiesen, dass eine derartige Verifizierung tatsächlich von einer vertraulichen Komponente 18 auf einer Berechungsvorrichtung 14 des veröffentlichenden Benutzers ausgeführt wird. Vorausgesetzt, die Verifizierung ist erfolgreich, dann ruft der veröffentlichende Benutzer/die vertrauliche Komponente 18 (im folgenden "der veröffentlichende Benutzer") (PU-EINHEIT(PR-OLP)) aus dem OLP-Zertifikat 810 ab (Schritt 909), wendet (PR-EINHEIT) auf (PU-EINHEIT) an, um (PR-OLP) zu beziehen (Schritt 911) und signiert anschließend den erzeugten Rechtekennsatz mit einem derartigen (PR-OLP), um einen SRL 308 zu erzeugen (Schritt 913).
Anschließend verknüpft der veröffentlichende Benutzer diesen SRL 308 und das OLP-Zertifikat 810, das verwendet wird, um diesen zu erzeugen, zum Inhalt 304, um den selbst veröffentlichten Inhalt 310 auszubilden (Schritt 915), wobei dieser rechteverwaltete Inhalt 310 somit zu einem weiteren Benutzer verteilt werden kann. Damit der veröffentlichende Benutzer damit fortfahren kann, den Inhalt 310 zu verwenden oder wiederzugeben, muss dieser veröffentlichende Benutzer selbst eine entsprechende Off-Line-Veröffentlicher-Lizenz 820 ausgeben.
Somit erzeugt der veröffentlichende Benutzer eine Veröffentlicher-Lizenz 820 durch Definieren geeigneter Rechtedaten für ihn selbst und Verschlüsseln derselben gemäß dem Inhaltsschlüssel (OK), was zu (CK(Rechtedaten)) führt (Schritt 917). Es wird darauf hingewiesen, dass diese Rechtedaten vom SRL 308 aus dem Inhalt 310 bezogen werden können, ein voreingestellter Satz von Rechtedaten sein können, die dem veröffentlichenden Benutzer einen teilweisen oder vollständigen Zugriff auf den selbst veröffentlichten Inhalt 310 gewähren, oder aus einer anderen Quelle abgeleitet werden können. Darüber hinaus verschlüsselt der veröffentlichende Benutzer den Inhaltsschlüssel (CK) gemäß (PU-EINHEIT), um (PU-EINHEIT(CK)) zu bilden (Schritt 919). (CK(Rechtedaten) und (PU-EINHEIT(CK)) werden anschließend zur Veröffentlicher-Lizenz 820 (Schritt 921) formatiert, das OLP-Zertifikat 810 und die Zertifikatskette desselben angefügt (Schritt 923) und diese Veröffentlicher-Lizenz 820 auf der Basis von (PR-OLP) signiert, wie er in Schritt 911 bezogen wurden (Schritt 925). Es wird hier darauf hingewiesen, dass der Inhalt 304 (d.h. (CK(Inhalt))), die Veröffentlicher-Lizenz 820 und das OLP-Zertifikat in Kombination eine Kette 830 digitaler Gegenstände zurück zur vertraulichen Autorität bilden.
Damit der veröffentlichende Benutzer den veröffentlichten Inhalt 310 wiedergeben kann, und unter Bezugnahme auf 10, muss dieser veröffentlichende Benutzer nicht den DRM-Server 320 kontaktieren, sondern erlangt anstelle dessen den öffentlichen Schlüssel entsprechend dem privaten Schlüssel der vertraulichen Autorität, der verwendet wurde, um das Ursprungszertifikat zu signieren (1001), verifiziert das Ursprungszertifikat (Schritt 1003) und verifiziert anschließend jedes Zwischenzertifikat in der Kette (Schritt 1005), indem er für jedes Zwischenzertifikat den öffentlichen Schlüssel vom vorherigen Zertifikat bezieht und diesen verwendet, um die Signatur eines derartigen Zertifikates zu verifizieren. Anschließend wird (PU-DRM) vom letzten Zertifikat in der Kette verwendet, um die Signatur des OLP-Zertifikates 810 (d.h. S(PR-DRM)) zu verifizieren (Schritt 1007), (PU-OLP) vom OLP-Zertifikat 810 bezogen (Schritt 1009) und dieser (PU-OLP) verwendet, um die Signatur der Veröffentlicher-Lizenz 820 (d.h. S(PR-OLP)) zu verifizieren (Schritt 1010).
Sobald die Veröffentlicher-Lizenz 820 verifiziert ist, werden (CK(Rechtedaten)) und (PU-EINHEIT(CK)) aus dieser abgerufen (Schritt 1011), (PR-EINHEIT) auf (PU-EINHEIT(CK)) angewendet, um (CK) zu ergeben (Schritt 1013), und (CK) auf (CK(Rechtedaten)) angewendet, um die Rechtedaten (Schritt 1015) zu ergeben. Es wird nun darauf hingewiesen, dass die Rechtedaten von der vertraulichen Komponente 18 der Berechungsvorrichtung 14 des veröffentlichenden Benutzers überprüft werden, um zu bestimmen, dass derartige Rechtedaten die Wiedergabe in der beabsichtigten Weise gestatten (Schritt 1017), diese vertrauliche Komponente 18 somit (CK) auf (CK(Inhalt)) aus dem Inhalt 310 anwendet, um den Inhalt zu ergeben (Schritt 1019), und dieser Inhalt anschließend zu einer geeigneten Wiedergabe-Applikation für die tatsächliche Wiedergabe weitergeleitet wird (Schritt 1021). Somit überführen die Schritte von 10 tatsächlich die Kette 830 der digitalen Gegenstände von der vertraulichen Autorität zum Inhalt 304.
Es wird darauf hingewiesen, dass die vertrauliche Komponente 18 denkbarerweise (CK) auf (CK(Inhalt)) anwenden könnte, um den Inhalt zu ergeben, ohne dass zunächst die Rechtedaten überprüft werden müssen, und unabhängig davon, was die Rechtedaten gestatten oder nicht gestatten könnten, jedoch vertraulich ist und aufgebaut wurde, um tatsächlich den Inhalt nur zu erzeugen, nachdem die Rechtedaten überprüft wurden und sich selbst bestätigt, dass die Rechtedaten die Wiedergabe dieses Inhaltes zulassen. Erneut kann als Ergebnis, dass die Veröffentlicher-Lizenz 820 vorliegt, der veröffentlichende Benutzer insoweit damit fortfahren, mit dem Inhalt 310 offline zu arbeiten, der dadurch veröffentlicht wird, während er offline bleibt, als dass der DRM-Server 320 nicht kontaktiert werden muss.
Registrieren und Teil-Registrieren von DRM-Servern.
Bei der Architektur, die in 3 gezeigt ist, ist lediglich ein DRM-Server 320 dargestellt. Es wird jedoch darauf hingewiesen, dass diese Architektur mehrere DRM-Server 320 enthalten kann und dies vermutlich auch tut. Insbesondere enthält bei einer Ausführungsform der vorliegenden Erfindung eine derartige Architektur ein verteiltes Netzwerk von DRM-Servern 320. Jeder dieser DRM-Server 320 kann eine beliebige spezielle Funktion haben, wobei sämtliche der DRM-Server 320 in einer geeigneten Art und Weise organisiert werden können, ohne vom Geltungsbereich der vorliegenden Erfindung abzuweichen.
Wendet man sich 12 zu, so kann eine spezielle Firma einen oder mehrere Benutzerebenen-DRM-Server 320 haben, um Rechtekennsätze zu signieren und damit SRLs 308 zu erzeugen, Lizenzen 16 auszugeben, Veröffentlicher-Lizenzen 820 zu gewähren, Zertifikate an Benutzer auszugeben, Zertifikate an Berechnungsvorrichtungen 14 auszugeben und dergleichen. Jeder dieser Benutzer-Ebenen-DRM-Server 320 kann beispielsweise geografisch zugewiesen sein oder kann auf der Basis von Funktion oder Last zugewiesen sein. Um mehrere Benutzerebenen-DRM-Server 320 zu beaufsichtigen, kann in ähnlicher Weise eine Firma über einen oder mehrere Verwaltungs-DRM-Server 320 verfügen. Derartige firmenbasierte DRM-Server 320 können sich hinter einer Firmen-Firewall befinden, sofern dies gewünscht ist.
Zusätzlich zu firmenbasierten DRM-Servern 320 kann es auch firmenübergreifende DRM-Server 320 geben, die die DRM-Funktionalität zwischen Firmen ermöglichen. Beispielsweise können es diese firmenübergreifenden DRM-Server 320 zwei Firmen gestatten, einen bestimmten DRM-Inhalt 12 gemeinsam zu nutzen. Zudem kann es ein Netzwerk von Beaufsichtigungs-DRM-Servern 320 geben, die sämtliche anderen DRM-Server 320 in Kraft setzen. Beispielsweise können diese Beaufsichtigungs-DRM-Server 320 sämtliche anderen DRM-Server 320 beaufsichtigen und warten und eine geeignete Verknüpfung für alle DRM-Server 320 zurück zur ursprünglichen oder vertraulichen Autorität bereitstellen, die die Basis für die Kette von Zertifikaten ist, die zuvor beschrieben wurden. Derartige nicht firmenbasierte DRM-Server 320 befinden sich wahrscheinlich nicht hinter einer Firmen-Firewall.
Es ist von Bedeutung, dass jeder DRM-Server 320 in der Architektur von 12 in der Lage sein muss zu beweisen, dass ihm zu vertrauen ist. Wie es aus der Beschreibung der obigen Kette von Zertifikaten verständlich sein sollte, wird somit jeder DRM-Server 320 bei Eintritt in die Architektur mit einem Registrierungs-Zertifikat 1310 versehen, wie es aus 13 zu erkennen ist. Bezeichnenderweise wird bei einer Ausführungsform der vorliegenden Erfindung das Registrierungs-Zertifikat 1310 dem beitretenden DRM-Server 320 (im folgenden "der DRM-E-Server 320") durch einen weiteren "registrierenden" DRM-Server 320 bereitgestellt, der bereits in der Architektur vorhanden ist (im folgenden "der DRM-R-Server 320"). Zudem ist bezeichnenderweise an das bereitgestellte Registrierungs-Zertifikat 1310 vom registrierenden DRM-R-Server 320 eine Kette von Zertifikaten 1320, die das Registrierungs-Zertifikat 1310 des registrierenden DRM-Servers 320, das Registrierungs-Zertifikat 1310 des DRM-Servers 320, der den registrierenden DRM-R-Server 320 registrierte, usw. den gesamten Weg zu einem Ursprungs-DRM-Server 320 angefügt. Dieser Ursprungs-DRM-Server 320 kann die ursprüngliche oder vertrauliche Autorität repräsentieren, oder die Kette von Zertifikaten 1320 kann sich darüber hinaus erstrecken, um die ursprüngliche oder vertrauliche Autorität zu erreichen. Es wird nun darauf hingewiesen, dass dieses Re gistrierungs-Zertifikat 1310 und die Kette von Zertifikaten 1320 in Kombination die Kette von Zertifikaten bilden, die an das OLP-Zertifikat 810 angefügt werden, das von einem registrierten oder beigetretenen DRM-E-Server 320 einem veröffentlichenden Benutzer bereitgestellt wird, wie es in 8 gezeigt ist.
Bei einer Ausführungsform der vorliegenden Erfindung wird das Registrierungs-Zertifikat 1310 einem DRM-E-Server 320 von einem DRM-R-Server 320 in Gestalt eines Zertifikates auf XrML-1.2-Basis bereitgestellt. Es wird darauf hingewiesen, dass dieser Typ eines Zertifikates 1310 nicht unabhängig von einem dritten Teilnehmer angeboten wird und somit ein derartiger Typ von Zertifikat 1310 keine Art einer unabhängigen Bürgschaft durch einen dritten Teilnehmer für den Inhaber dieses Zertifikates 1310 repräsentiert.
Bei einer Ausführungsform der vorliegenden Erfindung hängt das Verfahren, mit dem ein bestimmter DRM-E-Server 320 in der Architektur registriert wird, davon ab, ob der registrierende DRM-R-Server 320 den beitretenden DRM-E-Server 320 kennt oder Grund hat, diesem zu vertrauen. Wenn nicht, sollte der DRM-E-Server 320 aufgefordert werden, dem DRM-R-Server 320 zu beweisen, dass er vertrauenswürdig ist und die DRM-Architektur durchsetzen wird. Wenn ja, sollte der DRM-E-Server 320 wenigstens nicht im selben Umfang aufgefordert werden, dem DRM-R-Server 320 zu beweisen, dass er vertrauenswürdig ist. Somit "registriert" ein nicht vertrauender/nicht wissender DRM-Server 320 einen DRM-E-Server, während ein wissender/vertrauender DRM-R-Server 320 einen DRM-E-Server 320 "teil-registriert".
Normalerweise kennt/vertraut ein DRM-R-Server 320 einen/einem DRM-E-Server 320, wenn beide von derselben Firma oder zu deren Vorteil betrieben werden, wenngleich Wissen/Vertrauen auch aus anderen Situationen entstehen kann, ohne vom Geltungsbereich der vorliegenden Erfindung abzuweichen. Somit hängt das Verfahren, mit dem ein spezieller DRM-E-Server 320 in der Architektur registriert wird, normalerweise davon ab, ob der registrierende DRM-R-Server 320 firmenbasiert der nicht firmenbasiert ist. Infolgedessen "registriert" ein nicht firmenbasierter DRM-R-Server 320 einen DRM-E-Server 320, während ein firmenbasierter DRM-R-Server 320 einen DRM-E-Server 320 "teil-registriert".
Registrierung
Bei einer Ausführungsform der vorliegenden Erfindung, und unter Bezugnahme auf 14, registriert ein nicht wissender/nicht vertrauender DRM-R-Server 320 einen DRM-E-Server 320 in der folgenden Art und Weise.
Zunächst ist darauf hinzuweisen, dass der DRM-E-Server 320, der vom nicht wissenden/nicht vertrauenden DRM-R-Server 320 registriert werden soll, diesem DRM-R-Server 320 nicht bekannt ist. Demzufolge muss bei einer Ausführungsform der vorliegenden Erfindung der DRM-E-Server 320 ein Bürgschafts-Zertifikat 1330 von einem dritten Teilnehmer beschaffen, der für diesen DRM-E-Server 320 bürgen will (Schritt 1401). Normalerweise ist dieser dritte Teilnehmer ein unabhängiger, Zertifikate ausgebender Vermittler, dem vom DRM-R-Server 320 vertraut wird, um diese Bürgschaft auszuführen, wie etwa die VERISIGN Corporation aus Mountain View, Kalifornien. Dieses Bürgschafts-Zertifikat 1330 kann beispielsweise die Gestalt eines X.509-Zertifikates haben. Es wird darauf hingewiesen, dass beim DRM-R-Server 320, der sich auf den vertraulichen dritten Teilnehmer verlässt, für den DRM-E-Server 320 zu bürgen, die Haftung dieses DRM-R-Servers 320 für Handlungen mit schlechter Absicht durch den DRM-E-Server 320 eingeschränkt ist.
Es wird darauf hingewiesen, dass es, wie es auch in 13 zu erkennen ist, typisch ist, dass das Bürgschafts-Zertifikat 1330 einen öffentlichen Schlüssel (PU-V) und einen entsprechenden privaten Schlüssel (PR-V) enthält, vom vertraulichen dritten Teilnehmer signiert wird und von einer Kette von Zertifikaten begleitet sein kann, die zu Validierungszwecken zu einem bekannten Ursprung führt. Es ist ebenfalls typisch, dass (PR-V) im Bürgschafts-Zertifikat 1330 in einer Weise geschützt ist, die für den verbürgten DRM-E-Server 320 zugänglich ist, der die Basis des Bürgschafts-Zertifikates 1330 ist. Wie es beispielsweise in 13 zu sehen ist, kann (PR-V) gemäß einem geeigneten öffentlichen Schlüssel verschlüsselt werden.
Innerhalb der DRM-Architektur muss der beitretende DRM-E-Server 320 eine einzigartige Identität haben. Es versteht sich hier, dass die DRM-Identität wahrscheinlich von (PU-V, PR-V) getrennt ist, wenngleich die DRM-Identität ebenfalls mit diesem (PU-V, PR-V) übereinstimmen kann, ohne von Geltungsbereich der vorliegenden Erfindung abzuweichen. Um eine derartige Identität einzurichten, erzeugt oder bezieht demzufolge dieser DRM-E-Server 320 ein neues öffentliches/privates Schlüsselpaar (PU-E, PR-E) (Schritt 1403). Zudem sollte innerhalb der DRM-Architektur der registrierende DRM-E-Server 320 entscheiden, welche Einheiten ihre Autorität widerrufen können teilzunehmen. Demzufolge identifiziert dieser DRM-E-Server 320 jede derartige widerrufende Einheit in einer Liste möglicherweise mit Hilfe eines öffentlichen Schlüssels derselben (Schritt 1405).
Der DRM-E-Server 320 sollte in der Lage sein, für den registrierenden DRM-R-Server 320 einzurichten, dass dieser DRM-E-Server tatsächlich das Bürgschaftszertifikat 1330 besitzt, das bei Schritt 1401 bezogen wurde. Demzufolge verwendet der DRM-E-Server 320 entweder (PR-V) vom Bürgschafts-Zertifikat 1330, um (PU-E) zu verschlüsseln, was zu (PR-V(PU-E)) als Eigentums-Indizien führt, oder signiert (PU-E) mit (PR-V), was zu (PU-E) S (PR-V) als Eigentums-Indizien führt (Schritt 1407). In beiden Fällen richtet die Anwendung von (PU-V) für die Entschlüsselung von (PU-E) oder die Verifizierung der Signatur den Besitz von (PR-V) und somit des Bürgschafts-Zertifikates 1330 ein.
So weit verfügt der DRM-E-Server 320 über das Bürgschafts-Zertifikat 1330, (PU-E) und (PR-E), die Widerrufs-Autoritätsliste und (PR-V(PU-E) oder (PU-E) S (PR-V) als Eigentums-Indizien. Um die Registrierung anzufordern, sendet dieser DRM-E-Server 320 das Bürgschafts-Zertifikat 1330, (PU-E), die Widerrufs-Autoritätsliste und (PR-V(PU-E)) oder (PU-E) S (PR-V) als Eigentums-Indizien zum DRM-R-Server 320 (Schritt 1409), und der DRM-R-Server 320 schreitet damit fort, diesen anfordernden DRM-E-Server 320 zu registrieren. Es wird darauf hingewiesen, dass die Anorderung oder ein Teil derselben die Gestalt eines Zertifikates haben kann, das durch (PR-E) signiert ist.
Insbesondere validiert der DRM-R-Server 320 das Bürgschafts-Zertifikat 1330 auf der Basis der Signatur desselben durch den vertraulichen dritten Teilnehmer und die Kette von Zertifikaten, die zum bekannten Ursprung führen (Schritt 1411). Somit richtet der DRM-R-Server 320 ein, dass für den DRM-E-Server 320 gebürgt wurde. Zudem verifiziert der DRM-R-Server 320 die Eigentums-Indizien durch Anwenden von (PU-V) aus der Anforderung, um entweder (PU-E) zu entschlüsseln oder die Signatur zu verifizieren und somit den Besitz von (PR-V) und somit das Bürgschafts-Zertifikat 1330 in der Anforderung einzurichten (Schritt 1410). Darüber hinaus und bezeichnenderweise führt der DRM-R-Server 320 eine beliebige speziell eingerichtete Logik ein, die erforderlich ist um zu entscheiden, ob die Anforderung gewährt wird (Schritt 1413). Die speziell eingerichtete Logik kann eine beliebige geeignete Logik sein, ohne vom Geltungsbereich der vorliegenden Erfindung abzuweichen, und kann beispielsweise eine Hintergrundüberprüfung auf dem DRM-E-Server 320 und/oder dessen Operator, eine Bestimmung, ob der DRM-E-Server 320 eine momentane vertrauliche Komponente 18 und/oder Betriebssystem oder dergleichen hat, eine Bestimmung, ob sich der DRM-E-Server 320 auf einer Widerrufsliste oder anderen Beobachtungsliste befindet, oder ähnliches sein.
Vorausgesetzt, die speziell eingerichtete Logik gewährt die Anforderung, dann erzeugt bei einer Ausführungsform der vorliegenden Erfindung der DRM-R-Server 320 das Registrierungs-Zertifikat 1310 für den DRM-E-Server 320 (Schritt 1415). Insbesondere, und wie es in 13 zu sehen ist, enthält der DRM-R-Server im Registrierungs-Zertifikat 1310:

– eine Kennung des DRM-R-Servers 320, wie etwa einen öffentlichen Schlüssel desselben
– eine Kennung des DRM-E-Servers 320, wie etwa (PU-E);
– Identifizierungs-Indizien vom Bürgschafts-Zertifikat 1330, enthaltend den vertraulichen dritten Teilnehmer, der selbiges ausgegeben hat, eine Seriennummer vom Bürgschafts-Zertifikat 1330 und den Herausgeber, wie er innerhalb des Bürgschafts-Zertifikates 1330 identifiziert ist;
– beliebige Validitätsbereichs-Informationen, die einen Bereich festlegen, während dessen das Registrierungs-Zertifikat 1310 gültig ist, wie etwa einen Datenbereich;
– die Widerrufsautoritätsliste;
– eine Signatur auf der Basis eines privaten Schlüssels des DRM-R-Servers 320 (PR-R) entsprechend (PU-R);
– und beliebige andere geeignete Informationen

Diese anderen Informationen können, ohne darauf beschränkt zu sein, beinhalten: die Zeit, zu der das Zertifikat ausgegeben wurde; einen Hinweis darauf, welche Art von DRM-Aktivitäten ein registrierter Server ausführen darf, wie etwa sämtliche Aktivitäten, lediglich Abrechungsaktivitäten, lediglich das Signieren von Rechtekennsätzen, lediglich das Ausgeben von Inhaltslizenzen und Kombinationen daraus; und einen zulässigen Zeitbereich zum Ausführen von DRM-Aktivitäten. Es wird darauf hingewiesen, dass sich der zulässige Zeitbereich vom Validitätsbereich dadurch unterscheidet, dass die momentane Zeit innerhalb des Validitätsbereiches liegen muss, um ein beliebiges Zertifikat zu gewähren, dass das Registrierungs-Zertifikat 1310 in der Zertifikatskette enthält. Im Gegensatz dazu muss die ausgegebene Zeit von Nachfolger-Zertifikaten in den zulässigen Zeitbereich des Eltern-Zertifikates fallen, um DRM-Aktivitäten auszuführen.
Es wird darauf hingewiesen, dass bei der Erzeugung des Registrierungs-Zertifikates 1310 der DRM-R-Server 320 zu Beginn Zertifikats-Informationen erzeugen kann und er es anschließend der speziell eingerichteten Logik gestattet, zusätzliche Informationen zu erzeugen oder existierende Informationen zu modifizieren. Diese speziell eingerichtete Logik kann beispielsweise sicherstellen, dass der DRM-R-Server 320 geeignete Informationen enthält, oder kann vorbestimmte Richtlinien der DRM-Architektur durchsetzen. Natürlich wird die Signatur des Registrierungs-Zertifikates 1310 erzeugt, nachdem eine beliebige derartige speziell eingerichtete Logik ausgeführt wurde. Es wird ebenfalls darauf hingewiesen, dass der DRM-R-Server 320 die Kette von Zertifikaten 1320 anfügt, die zurück zur vertraulichen ursprünglichen Autorität des erzeugten Registrierungs-Zertifikates 1310 führen, so dass das erzeugte Registrierungs-Zertifikat 1310 auf der Basis einer derartigen Kette von Zertifikaten 1320 validiert werden kann.
Es wird insbesondere darauf hingewiesen, dass sich die Identifizierungs-Indizien aus dem Bürgschafts-Zertifikat 1330, wie im Registrierungs-Zertifikat 1310 plaziert, immer mit diesem Registrierungs-Zertifikat 1310 bewegen werden und sich als Brücke zum Bürgschafts-Zertifikat 1330 verhalten werden. Somit zeigen derartige Identifizierungs-Indizien erneut nach außen, dass sich der DRM-R-Server 320 auf den Drittteilnehmer-Herausgeber des Bürgschafts-Zertifikates 1330 verlässt, um für den DRM-E-Server 320 zu bürgen, wobei die Haftung dieses DRM-R-Servers 320 für Handlungen in schlechtem Sinne durch den DRM-E-Server 320 eingeschränkt ist.
Sobald der DRM-R-Server 320 erfolgreich das Bürgschafts-Zertifikat 1310 mit der angefügten Kette von Zertifikaten 1320 erzeugt hat, sendet der DRM-R-Server 320 anschließend selbiges zum anfordernden DRM-E-Server 320 zurück (Schritt 1417), wobei der nun registrierte DRM-E-Server 320 selbiges an einem geeigneten Ort für die zukünftige Verwendung speichert (Schritt 1419). Wie bereits oben erläutert wurde, sind (PU-E) im Registrierungs-Zertifikat 1310 und der entsprechende (PR-E) ein öffentliches/privates Schlüsselpaar, das der DRM-E-Server 320 als (PU-DRM) und (PR-DRM) verwenden wird, wenn er einen Rechtekennsatz signiert, um SRI 308 zu erzeugen, ein OLP-Zertifikat 810 ausgibt oder anderweitig innerhalb der DRM-Architektur partizipiert. Demzufolge bilden ein derartiges Registrierungs-Zertifikat 1310 und die Kette von Zertifikaten 1320 in Kombination die Kette von Zertifikaten, die an ein derartiges OLP-Zertifikat 810 und dergleichen angefügt sind.
Teil-Registrierung
Bei einer Ausführungsform der vorliegenden Erfindung und unter Bezugnahme auf 15 führt ein wissender/vertrauender DRM-R-Server 320 eine Teilregistrierung eines DRM-E-Servers 320 in der folgenden Art und Weise durch.
Zunächst wird darauf hingewiesen, dass vom DRM-E-Server 320, der vom wissenden/vertrauenden DRM-R-Server 320 teilregistriert werden soll, weiterhin gefordert werden sollte, sich an diesem DRM-R-Server 320 insofern selbst zu registrieren, als dass das Wissen oder das Vertrauen nicht vollständig sein könnten. Diese Identifikationsanforderung muss jedoch insoweit nicht die Ebene eines Angebotes durch einen vertraulichen dritten Teilnehmer erreichen, als dass der DRM-R-Server 320 einiges Wissen/Vertrauen des DRM-E-Servers hat. Demzufolge bezieht bei einer Ausführungsform der vorliegenden Erfindung der DRM-E-Server 320 eine bestimmte Art von Credentials 1340 oder wird mit diesen versorgt (13), die vom DRM-R-Server 320 erkannt werden können und von denen erwartet wird, dass sie von ihm gewährt werden, und die den DRM-E-Server 320 zur Befriedigung des DRM-R-Servers 320 identifizieren (Schritt 1501).
Befinden sich sowohl der DRM-R- als auch der DRM-E-Server 320 innerhalb derselben Firma, können derartige Credentials 1340 firmenbasierte Credentials sein, wie etwa eine Netzwerk-ID, wenn sich beide Server 320 in einem gemeinsamen Netzwerk befinden, eine Domain-ID, wenn sich beide Server in einer gemeinsamen Domgin befinden, und dergleichen. Befinden sich sowohl der DRM-R- als auch der DRM-E-Server 320 nicht innerhalb derselben Firma, können derartige Credentials 1340 weiterhin eine Netzwerk-ID, wenn sich beide Server 320 in einem gemeinsamen Netzwerk befinden, eine Domain-ID, wenn beide Server 320 eine gemeinsame Domgin gemeinsam nutzen, oder dergleichen sein, oder können andere Credentials sein, wie etwa Credentials, die von einem dritten Teilnehmer ausgegeben und vom DRM-R-Server 320 erkannt werden.
Es wird darauf hingewiesen, dass sich bei der vorliegenden Situation der DRM-Server 320 nicht auf einen vertraulichen dritten Teilnehmer verlässt, um für den DRM-E-Server 320 zu bürgen und daher die Haftung dieses DRM-R-Servers 320 für Handlungen mit schlechter Absicht durch den DRM-E-Server 320 nicht so weit eingeschränkt ist. Trotzdem ist der DRM-R-Server 320 bereit, ein derartiges Risiko auf der Basis des Wissens oder des Vertrauens in den DRM-E-Server 320 zu übernehmen, diese Handlungen mit schlechter Absicht tatsächlich nicht auszuführen.
Wie zuvor muss innerhalb der DRM-Architektur der beitretende DRM-E-Server 320 eine einzigartige Identität haben. Es versteht sich hier, dass die DRM-Identität wahrscheinlich von den Credentials 1340 getrennt ist, wenngleich die DRM-Identität ebenfalls mit den Credentials 1340 übereinstimmen kann, ohne vom Geltungsbereich der vorliegenden Erfindung abzuweichen. Um diese Identität einzurichten, erzeugt oder bezieht dieser DRM-E-Server 320 ein neues öffentli ches/privates Schlüsselpaar (PU-E, PR-E) (Schritt 1503). Zudem sollte wie zuvor innerhalb der DRM-Architektur der teil-registrierende DRM-E-Server 320 entscheiden, welche Einheiten ihre Autorität widerrufen können teilzunehmen. Demzufolge identifiziert dieser DRM-E-Server 320 jede widerrufende Einheit in einer Liste möglicherweise mit einem öffentlichen Schlüssel derselben (Schritt 1505).
Soweit verfügt der DRM-E-Server 320 über die Credentials 1340, (PU-E) und (PR-E) und die Widerrufsautoritätsliste. Um eine Teilregistrierung anzufordern, sendet dieser DRM-E-Server 320 anschließend die Credentials 1340, (PU-E) und die Widerrufsautoritätsliste zum DRM-Server 320 (Schritt 1507), worauf der DRM-R-Server 320 fortschreitet, um den anfordernden DRM-E-Server 320 zu teilregistrieren. Es wird darauf hingewiesen, dass wie zuvor die Anforderung oder ein Teil derselben die Gestalt eines Zertifikates haben kann, das durch (PR-E) signiert ist.
Insbesondere validiert der DRM-R-Server 320 die Credentials 1340 auf der Basis, welche Logik oder Ressourcen erforderlich und verfügbar sind, um eine derartige Validierung auszuführen (Schritt 1509). Somit richtet es der DRM-R-Server 320 auf der Basis der validierten Credentials 1340 ein, dass dem DRM-E-Server 320 zu vertrauen ist, die DRM-Architektur zu gewähren und ihr Folge zu leisten. Zusätzlich und wie zuvor führt der DRM-R-Server 320 eine beliebige speziell eingerichtete Logik aus, die erforderlich ist um zu entscheiden, ob die Anforderung gewährt werden soll (Schritt 1511).
Angenommen, die speziell eingerichtete Logik lässt ein Gewähren der Anforderung zu, dann erzeugt bei einer Ausführungsform der vorliegenden Erfindung der DRM-Server 320 ein Teil-Registrierungs-Zertifikat 1310 für den DRM-E-Server 320 (Schritt 1513). Insbesondere, und wie es in 13 zu sehen ist, enthält der DRM-R-Server 320 im Teil-Registrierungszertifikat 1310:

– eine Kennung des DRM-R-Servers 320, wie etwa einen öffentlichen Schlüssel desselben (PU-R)
– eine Kennung des DRM-E-Servers 320, wie etwa (PU-E);
– die Credentials 1340 oder einen Verweis auf diese;
– beliebige Validitätsbereichs-Informationen, die einen Bereich festlegen, während dessen des Teil-Registrierungs-Zertifikat 1310 gültig ist, wie etwa einen Datenbereich;
– die Widerrufs-Autoritätsliste;
– eine Signatur auf der Basis eines privaten Schlüssels des DRM-R-Servers 320 (PR-R) entsprechend (PU-R);
– und beliebige andere geeignete Informationen

Wie zuvor kann bei der Erzeugung des Teil-Registrierungs-Zertifikates 1310 der DRM-R-Server 320 zu Beginn Zertifikatsinformationen erzeugen und es dann der speziell eingerichteten Logik gestatten, zusätzliche Informationen zu erzeugen oder bestehende Informationen abzuändern. Wiederum wird die Signatur des Teil-Registrierungs-Zertifikates 1310 erzeugt, nachdem eine beliebige derartige speziell eingerichtete Logik ausgeführt wird. Wie zuvor fügt der DRM-R-Server 320 die Kette von Zertifikaten 1320, die zurück zur vertraulichen Ursprungsautorität führen, an das erzeugte Teil-Registrierungs-Zertifikat 1310 an, so dass das erzeugte Teil-Registrierungs-Zertifikat 1310 auf der Basis einer derartigen Kette von Zertifikaten 1320 validiert werden kann.
Es wird darauf hingewiesen, dass davon ausgegangen wird, dass die Credentials 1340 oder der Verweis auf diese nicht insbesondere notwendig sind, jedoch trotzdem aus Gründen der Vollständigkeit enthalten sein können. Zudem wird darauf hingewiesen, dass das Teil-Registrierungs-Zertifikat 1310 insoweit keine Identifizierungs-Indizien von einem bürgenden Zertifikat 1130 enthält, als dass kein Bürgschafts-Zertifikat beim vorliegenden Teil-Registrierungs-Szenario erforderlich war.
Sobald der DRM-R-Server 320 erfolgreich das Teil-Registrierungs-Zertifikat 1310 mit der angefügten Kette von Zertifikaten 1320 erzeugt hat, sendet der DRM-R-Server 320 dasselbe zum anfordernden DRM-R-Server 320 zurück (Schritt 1515), und der nun teil-registrierte DRM-E-Server 320 speichert dieses an einem geeigneten Ort für die spätere Verwendung (Schritt 1517). Wie zuvor sind (PU-E) im Teil-Registrierungs-Zertifikat 1310 und der entsprechende (PR-E) das öffentliche/private Schlüsselpaar, das der DRM-E-Server 320 als (PU-DRM) und (PR- DRM) verwendet, wenn er einen Rechtekennsatz signiert, um einen SRI 308 zu erzeugen, ein OLP-Zertifikat 810 erzeugt und anderweitig innerhalb der DRM-Architektur partizipiert. Demzufolge bilden dieses Teil-Registrierungs-Zertifikat 1310 und die Kette der Zertifikate 1320 in Kombination die Kette von Zertifikaten, die an dieses OLP-Zertifikat 810 und dergleichen angefügt wird.
Folgerung
Die Programmierung, die erforderlich ist, um die Prozesse in die Praxis umzusetzen, die in Verbindung mit der vorliegenden Erfindung ausgeführt werden, ist relativ einfach und sollte den betreffenden Programmierern verständlich sein. Demzufolge ist eine derartige Programmierung hier nicht angefügt. Jede spezielle Programmierung kann anschließend entwickelt werden, um die vorliegende Erfindung in die Praxis umzusetzen, ohne von deren Geltungsbereich abzuweichen.
Bei der vorliegenden Erfindung gestatten eine DRM- und Durchsetzungs-Architektur sowie das zugehörige Verfahren, die kontrollierte Wiedergabe oder das Abspielen beliebiger Formen digitalen Inhaltes, wobei diese Kontrolle flexibel ist und vom Inhalts-Inhaber/-Entwickler eines derartigen digitalen Inhaltes definiert werden kann. Die Architektur gestattet und vereinfacht diese kontrollierte Wiedergabe insbesondere in einer Büro- oder Firmenumgebung oder dergleichen, in der Dokumente innerhalb einer definierten Gruppe von Einzelpersonen oder Klassen von Einzelpersonen gemeinsam genutzt werden sollen. Eine derartige Architektur enthält einen Mechanismus, um bewilligungsgewährende DRM-Server 320 in der Architektur zu registrieren/teil-registrieren.
Es wird darauf hingewiesen, dass Änderungen an den oben beschriebenen Ausführungsformen vorgenommen werden können, ohne von den erfinderischen Konzepten derselben abzuweichen. Wenn beispielsweise eine Lizenz oder ein Rechtekennsatz auf der Basis von Rechtedaten signiert wird, müssen derartige Rechtedaten nicht unbedingt verschlüsselt werden. In ähnlicher Weise müssen bei der Anforderung und dem Aufbau eines Registrierungs- oder Teil-Registrierungs-Zertifikates 1310 die Widerrufs-Autoritätsliste und andere ähnliche Informationen nicht unbedingt verwendet werden. Es versteht sich somit, dass die vorliegende Erfindung nicht auf die speziellen beschriebenen Ausführungsformen beschränkt ist, sondern es beabsichtigt ist, Abänderungen abzudecken, die innerhalb des Geltungsbereiches der vorliegenden Erfindung liegen, wie er in den beigefügten Ansprüchen definiert ist.

Claims

Verfahren in Kombination mit einem DRM (Digital Rights Management) -System, das eine Vielzahl von DRM-Servern (320) aufweist, die DRM-Funktionalität erfüllen, wobei das Verfahren dazu dient, wenigstens einen beitretenden DRM-Server durch einen registrierenden DRM-Server in dem System so zu registrieren, dass dem wenigstens einen beitretenden DRM-Server in dem System zu vertrauen ist, wobei es umfasst, dass: der wenigstens eine beitretende DRM-Server ein Paar aus öffentlichem/privatem Schlüssel beschafft, das einen öffentlichen Schlüssel und einen privaten Schlüssel umfasst, um diesen beitretenden DRM-Server innerhalb des Beitritts-DRM-Systems zu identifizieren; der wenigstens eine beitretende DRM-Server eine anbietende Identifizierung (proffering identification) desselben beschafft; der wenigstens eine beitretende DRM-Server eine Registrierungsanforderung zu dem registrierenden DRM-Server sendet (1409), wobei die Anforderung die anbietende Identifizierung und den durch den wenigstens einen beitretenden DRM-Server beschafften öffentlichen Schlüssel enthält; der registrierende DRM-Server die anbietende Identifizierung validiert; der registrierende DRM-Server Custom Logic durchgeführt (1413), um zu entscheiden, ob die Anforderung gewährt wird; der registrierende DRM-Server, wenn die Anforderung gewährt wird, ein digitales Registrierungs-Zertifikat (1310) für den wenigstens einen beitretenden DRM-Server generiert, um diesen beitretenden DRM-Server in dem DRM-System zu registrieren, wobei das generierte Registrierungs-Zertifikat wenigstens teilweise auf dem durch den wenigstens einen beitretenden DRM-Server beschafften öffentlichen Schlüssel basiert und der registrierende DRM-Server das Registrierungs-Zertifikat generiert, indem er Custom Logic verwendet, um wenigstens einen Teil der Informationen im dem Registrierungs-Zertifikat zu generieren; der registrierende DRM-Server das generierte Registrierungs-Zertifikat zu dem anfordernden wenigstens einen beitretenden DRM-Server zurückführt (1417); und der nunmehr registrierte wenigstens eine beitretende DRM-Server das zurückgeführte Registrierungs-Zertifikat an einem geeigneten Ort zur zukünftigen Verwendung speichert (1419), wobei der wenigstens eine beitretende DRM-Server mit dem Registrierungs-Zertifikat in der Lage ist, dieses zur Ausgabe von DRM-Dokumenten innerhalb des DRM-Systems zu verwenden, wobei der wenigstens eine beitretende DRM-Server einen ersten beitretenden DRM-Server umfasst und das Verfahren des Weiteren umfasst, dass: der erste beitretende DRM-Server eine anbietende Identifizierung desselben beschafft, die ein Bürgschafts-Zertifikat (vouching certificate) von einer dritten Seite umfasst, die bereit ist, für diesen beitretenden DRM-Server zu bürgen, wobei in dem Bürgschafts-Zertifikat ein öffentlicher Schlüssel und ein entsprechender privater Schlüssel enthalten sind; der erste beitretende DRM-Server den durch den ersten beitretenden DRM-Server beschafften öffentlichen Schlüssel und den in dem Bürgschafts-Zertifikat enthaltenen privaten Schlüssel verwendet, um Eigentums-Indizien zu formulieren (1407) und damit zu zeigen, dass das Bürgschafts-Zertifikat Eigentum des ersten beitretenden DRM-Servers ist; der erste beitretende DRM-Server eine Registrierungs-Anforderung zu dem registrierenden DRM-Server sendet, wobei die Anforderung das Bürgschafts-Zertifikat, den durch den ersten beitretenden DRM-Server beschafften öffentlichen Schlüssel und die Eigentums-Indizien einschließt; der registrierende DRM-Server das Bürgschafts-Zertifikat validiert (1411); der registrierende DRM-Server die Eigentums-Indizien prüft (1410); und der registrierende DRM-Server, wenn die Anforderung gewährt werden soll, ein digitales Registrierungs-Zertifikat für den ersten beitretenden DRM-Server generiert, um diesen beitretenden DRM-Server in dem DRM-System zu registrieren, wobei das generierte Registrierungs-Zertifikat wenigstens teilweise und auf eine Weise auf dem Bürgschafts-Zertifikat und dem durch den ersten beitretenden DRM-Server beschafften öffentlichen Schlüssel basiert, die zeigt, dass der registrierende DRM-Server vertraut und sich darauf verlässt, dass die bürgende Seite für den ersten beitretenden Server bürgt.
Verfahren nach Anspruch 1, das umfasst, dass der erste beitretende DRM-Server das Bürgschafts-Zertifikat von einem unabhängigen Zertifikatausstellungs-Agenten beschafft, dem der registrierende DRM-Server vertraut und auf den er sich hinsichtlich der Durchführung dieser Bürgschaft verlässt.
Verfahren nach Anspruch 1 oder 2, das umfasst, dass der erste beitretende DRM-Server ein X.509-Bürgschafts-Zertifikat beschafft.
Verfahren nach einem der Ansprüche 1 bis 3, das umfasst, dass: der erste beitretende DRM-Server das Bürgschafts-Zertifikat zu Validierungszwecken beschafft, das durch die bürgende Seite signiert ist und von einer Kette von Zertifikaten begleitet wird, die zu einem bekannten Ursprung führt; und der registrierende DRM-Server das Bürgschafts-Zertifikat auf Basis der Signatur desselben durch die bürgende Seite und die Kette von Zertifikaten validiert, um festzustellen, dass für den beitretenden DRM-Server gebürgt worden ist.
Verfahren nach einem der Ansprüche 1 bis 4, das umfasst, dass: der erste beitretende DRM-Server entweder den in dem Bürgschafts-Zertifikat enthaltenen privaten Schlüssel verwendet, um den durch den ersten beitretenden DRM-Server beschafften öffentlichen Schlüssel zu verschlüsseln, so dass der verschlüsselte öffentliche Schlüssel als die Eigentums-Indizien resultiert, oder den durch den ersten beitretenden DRM-Server beschafften öffentlichen Schlüssel mit dem in dem Bürgschafts-Zertifikat enthaltenen privaten Schlüssel signiert, so dass der signierte öffentliche Schlüssel als die Eigentums-Indizien resultiert; und der registrierende DRM-Server die Eigentums-Indizien prüft, indem er den in dem Bürgschafts-Zertifikat aus der Anforderung enthaltenen öffentlichen Schlüssel verwendet, um den durch den ersten beitretenden DRM-Server beschafften öffentlichen Schlüssel zu entschlüsseln, oder die Signatur prüft, um festzustellen, dass der in dem Bürgschafts-Zertifikat enthaltene private Schlüssel und damit das Bürgschafts-Zertifikat, Eigentum des ersten beitretenden DRM-Servers ist.
Verfahren nach einem der Ansprüche 1 bis 5, das umfasst, dass der registrierende DRM-Server das Registrierungs-Zertifikat so generiert, dass es den durch den wenigstens einen beitretenden DRM-Server beschafften öffentlichen Schlüssel als eine Kennung des wenigstens einen beitretenden DRM-Servers und eine Signatur auf Basis eines privaten Schlüssels des registrierenden DRM-Servers enthält.
Verfahren nach Anspruch 6, das umfasst, dass der nunmehr registrierte wenigstens eine beitretende DRM-Server das zurückgeführte Registrierungs-Zertifikat speichert, das den durch den wenigstens einen beitretenden DRM-Server beschafften öffentlichen Schlüssel als eine Kennung des wenigstens einen beitretenden DRM-Servers und die Signatur auf Basis des privaten Schlüssels des registrierenden DRM-Servers enthält.
Verfahren nach Anspruch 6 oder 7, das umfasst, dass der registrierende DRM-Server das Registrierungs-Zertifikat so generiert, dass es des Weiteren identifizierende Indizien zum Identifizieren der anbietenden Identifizierung enthält.
Verfahren nach Anspruch 8, dass umfasst, dass der nunmehr registriere wenigstens eine beitretende DRM-Server das zurückgeführte Registrierungs-Zertifikat speichert, das des Weiteren die identifizierenden Indizien zum Identifizieren der anbietenden Identifizierung enthält.
Verfahren nach einem der Ansprüche 6 bis 9, das umfasst, dass der registrierende DRM-Server das Registrierungs-Zertifikat so erzeugt, dass es des Weiteren identifizierende Indizien zum Identifizieren des Bürgschafts-Zertifikats enthält, wobei die identifizierenden Indizien für das Bürgschafts-Zertifikat in dem Registrierungs-Zertifikat als eine Brücke zu dem Bürgschafts-Zertifikat wirken und zeigen, dass der registrierende DRM-Server der bürgenden Seite vertraut und sich auf sie zum Bürgen für den ersten beitretenden DRM-Server verlässt.
Verfahren nach Anspruch 10, das umfasst, dass der nunmehr registrierte erste beitretende DRM-Server das zurückgeführte Registrierungs-Zertifikat speichert, das des Weiteren die identifizierenden Indizien zum Identifizieren des Bürg schafts-Zertifikats enthält, wobei die identifizierenden Indizien für das Bürgschafts-Zertifikat in dem Registrierungs-Zertifikat als eine Brücke zu dem Bürgschafts-Zertifikat wirken und zeigen, dass der registrierende DRM-Server der bürgenden Seite vertraut und sich auf sie zum Bürgen für den ersten beitretenden DRM-Server verlässt.
Verfahren nach einem der Ansprüche 6 bis 11, das umfasst, dass der beitretende DRM-Server das Registrierungs-Zertifikat so generiert, dass es des Weiteren einen öffentlichen Schlüssel des registrierenden DRM-Servers als eine Kennung desselben enthält.
Verfahren nach Anspruch 12, das umfasst, dass der nunmehr registrierte wenigstens eine beitretende DRM-Server das zurückgeführte Registrierungs-Zertifikat speichert, das des Weiteren den öffentlichen Schlüssel des registrierenden DRM-Servers als eine Kennung desselben enthält.
Verfahren nach einem der Ansprüche 6 bis 13, das umfasst, dass der registrierende DRM-Server das Registrierungs-Zertifikat so generiert, dass es des Weiteren Validitätsbereichs-Informationen enthält, die einen Bereich spezifizieren, über den das Registrierungs-Zertifikat gültig ist.
Verfahren nach Anspruch 14, das umfasst, dass der nunmehr registrierte wenigstens eine beitretende DRM-Server das zurückgeführte Registrierungs-Zertifikat speichert, das des Weiteren die Gültigkeitsbereich-Informationen enthält, die den Bereich spezifizieren, über den das Registrierungs-Zertifikat gültig ist.
Verfahren nach einem der Ansprüche 1 bis 15, das des Weiteren umfasst, dass der registrierende DRM-Server an das generiert Registrierungs-Zertifikat eine Kette von Zertifikaten anhängt, die zu einer vertrauenswürdigen Ursprungs-Autorität zurückführt, so dass das generierte Registrierungs-Zertifikat auf Basis dieser Kette von Zertifikaten validiert werden kann.
Verfahren nach Anspruch 15, das umfasst, dass der nunmehr registrierte wenigstens eine beitretende DRM-Server das zurückgeführte Registrierungs-Zertifikat speichert, das die Kette von Zertifikaten enthält, die zu der vertrauenswürdigen Ursprungs-Autorität zurückführt, so dass das generierte Registrierungs-Zertifikat auf Basis dieser Kette von Zertifikaten validiert werden kann.
Verfahren nach einem der Ansprüche 1 bis 17, das umfasst, dass der registrierende DRM-Server ein XrML-Registrierungs-Zertifikat erzeugt.
Verfahren nach Anspruch 18, das umfasst, dass der nunmehr registrierte wenigstens eine beitretende DRM-Server das zurückgeführte XrML-Registrierungs-Zertifikat speichert.
Verfahren nach einem der Ansprüche 1 bis 19, wobei der wenigstens eine beitretende DRM-Server des Weiteren einen zweiten beitretenden DRM-Server umfasst und das Verfahren des Weiteren umfasst, dass: der zweite beitretende DRM-Server eine anbietende Identifizierung desselben beschafft, die Credentials umfasst, die von dem registrierenden DRM-Server erkannt werden können und erwartungsgemäß von ihm anerkannt werden; der zweite beitretende DRM-Server eine Registrierungs-Anforderung zu dem registrierenden DRM-Server sendet, wobei die Anforderung die Credentials und den durch den zweiten beitretenden DRM-Server beschafften öffentlichen Schlüssel enthält; der registrierende DRM-Server die Credentials validiert; und der registrierende DRM-Server, wenn die Anforderung gewährt werden soll, ein digitales Registrierungs-Zertifikat für den zweiten beitretenden DRM-Server generiert, um diesen beitretenden DRM-Server in dem DRM-System zu registrieren, wobei das generierte Registrierungs-Zertifikat wenigstens teilweise auf den Credentials und dem durch den zweiten beitretenden DRM-Server beschafften öffentlichen Schlüssel basiert.
Verfahren nach Anspruch 20, das umfasst, dass der zweite beitretende DRM-Server Credentials beschafft, die aus einer Gruppe ausgewählt werden, die aus einer Netzwerk-Kennung oder einer Domain-Kennung und durch eine dritte Seite ausgegebenen Credentials besteht.
Verfahren nach Anspruch 20 oder 21, das umfasst, dass der registrierende DRM-Server das Registrierungs-Zertifikat so generiert, dass es den durch den zweiten beitretenden DRM-Server beschafften öffentlichen Schlüssel als eine Kennung des zweiten beitretenden DRM-Servers, identifizierende Indizien zum Identifizie ren der Credentials und eine Signatur auf Basis eines privaten Schlüssels des registrierenden DRM-Servers enthält.
Verfahren nach Anspruch 22, das umfasst, dass der nunmehr registrierte zweite beitretende DRM-Server das zurückgeführte Registrierungs-Zertifikat speichert, das den durch den zweiten beitretenden DRM-Server beschafften öffentlichen Schlüssel als eine Kennung des zweiten beitretenden DRM-Servers, die identifizierenden Indizien zum Identifizieren der Credentials und die Signatur auf Basis des privaten Schlüssels des registrierenden DRM-Servers enthält.
Verfahren nach einem der Ansprüche 1 bis 23, das umfasst, dass der registrierende DRM-Server Custom Logic durchgeführt, um zu entscheiden, ob die Anforderung gewährt wird, die aus einer Gruppe ausgewählt wird, die aus dem Durchführen einer Hintergrundprüfung an dem wenigstens einen beitretenden DRM-Server und/oder seinem Betreiber, dem Feststellen, ob der wenigstens eine beitretende DRM-Server und/oder ein Teil desselben aktuell ist, dem Feststellen, ob der wenigstens eine beitretende DRM-Server auf einer Widerrufliste oder einer Überwachungsliste steht, und Kombinationen daraus besteht.
Verfahren nach einem der Ansprüche 1 bis 24, das des Weiteren umfasst, dass der wenigstens eine beitretende DRM-Server in einer Widerrufsautoritäts-Liste wenigstens eine Einheit mit Autorität zum Widerrufen von Registrierung dieses beitretenden DRM-Servers innerhalb des DRM-Systems identifiziert (1505), wobei dies umfasst, dass der wenigstens eine beitretende DRM-Server eine Registrierungsanforderung zu dem registrierenden DRM-Server sendet (1507), wobei die Anforderung die anbietende Identifizierung, den durch den wenigstens einen beitretenden DRM-Server beschafften öffentlichen Schlüssel und die Widerrufsautoritäten-Liste enthält, und das umfasst, dass der registrierende DRM-Server, wenn die Anforderung gewährt werden soll, ein digitales Registrierungs-Zertifikat für den wenigstens einen beitretenden DRM-Server generiert (1513), um diesen beitretenden DRM-Server in dem DRM-System zu registrieren, und das generierte Registrierungs-Zertifikat wenigstens teilweise auf dem durch den wenigstens einen beitretenden DRM-Server beschafften öffentlichen Schlüssel und der Widerrufsautoritäts-Liste basiert.
Verfahren nach Anspruch 25, das umfasst, dass der wenigstens eine DRM-Server jede Einheit in der Widerrufsautoritäts-Liste anhand eines öffentlichen Schlüssels derselben identifiziert.
Verfahren nach Anspruch 25 oder 26, das umfasst, dass der registrierende DRM-Server das Registrierungs-Zertifikat so generiert, dass es den durch den wenigstens einen beitretenden DRM-Server beschafften öffentlichen Schlüssel als eine Kennung des beitretenden DRM-Servers, die Widerrufsautoritäts-Liste aus der Anforderung und eine Signatur auf Basis eines privaten Schlüssels des registrierenden DRM-Servers enthält.
Verfahren nach Anspruch 27, das umfasst, dass der nunmehr registrierte wenigstens eine beitretende DRM-Server das zurückgeführte Registrierungs-Zertifikat speichert, das den durch den beitretenden DRM-Server beschafften öffentlichen Schlüssel als eine Kennung des beitretenden DRM-Servers, die Widerrufsautoritäts-Liste aus der Anforderung und die Signatur auf Basis des privaten Schlüssels des registrierenden DRM-Servers enthält.
Verfahren nach einem der Ansprüche 1 bis 28, das umfasst, dass der registrierende DRM-Server die Registrierungs-Anforderung von dem wenigstens einen beitretenden DRM-Server empfängt.
Verfahren nach Anspruch 29, das umfasst, dass der registrierende DRM-Server die Registrierungsanforderung von dem ersten beitretenden DRM-Server empfängt, die das Bürgschafts-Zertifikat von einem unabhängigen Zertifikatausstellungs-Agenten enthält, dem der registrierende DRM-Server vertraut und auf den er sich hinsichtlich der Durchführung dieser Bürgschaft verlässt.
Verfahren nach Anspruch 29 oder 30, das des Weiteren umfasst, dass der registrierende DRM-Server die Registrierungs-Anforderung von dem ersten DRM-Server empfängt, die ein X.509-Bürgschafts-Zertifikat enthält.
Verfahren nach einem der Ansprüche 29 bis 31, das umfasst, dass: der registrierende DRM-Server die Registrierungs-Anforderung von dem ersten beitretenden DRM-Server empfängt, die zum Zweck der Validierung das durch die bürgende Seite signierte Bürgschafts-Zertifikat enthält und von einer Kette von Zertifikationen begleitet wird, die zu einem bekannten Ursprung führt; und der registrierende DRM-Server das Bürgschafts-Zertifikat auf Basis der Signatur desselben durch die bürgende Seite und der Kette von Zertifikaten validiert, um festzustellen, dass für den ersten beitretenden DRM-Server gebürgt worden ist.
Verfahren nach einem der Ansprüche 20 bis 23, das umfasst, dass der registrierende DRM-Server die Registrierungsanforderung von dem zweiten beitretenden DRM-Server empfängt, die die Credentials enthält, die aus einer Gruppe ausgewählt werden, die aus einer Netzwerk-Kennung oder einer Domain-Kennung und durch eine dritte Seite ausgegebenen Credentials besteht.
Verfahren nach einem der Ansprüche 1 bis 33, das des Weiteren umfasst, dass der registrierende DRM-Server die Registrierungs-Anforderung von dem wenigstens einen beitretenden DRM-Server empfängt, die des Weiteren eine Widerrufsautoritäts-Liste enthält, die wenigstens eine Einheit mit Autorität zum Widerrufen von Registrierung dieses beitretenden DRM-Servers in dem DRM-System identifiziert, und das umfasst, dass der registrierende DRM-Server, wenn die Anforderung gewährt werden soll, ein digitales Registrierungs-Zertifikat für den wenigstens einen beitretenden DRM-Server generiert, um diesen beitretenden DRM-Server in dem DRM-System zu registrieren, wobei das generierte Registrierungs-Zertifikat wenigstens teilweise auf der Widerrufsautoritäts-Liste basiert.