DE60307736T2

DE60307736T2 - Serverarchitektur für sichere Plug-ins in digitalen Rechteverwaltungsssystemen

Info

Publication number: DE60307736T2
Application number: DE60307736T
Authority: DE
Inventors: Scott C. Sammamish Cottrille; Peter David Bellevue Waxman; Vinay Woodinville Krishnaswamy; Chandramouli Sammamish Venkatesh; Attila Bothell Narin; Gregory Kirkland Kostal; Prashant Sammamish Malik; Vladimir Duvall Yarmolenko; Frank Seattle Byrum; Thomas K. Redmond Lindeman
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2002-06-28
Filing date: 2003-06-13
Publication date: 2006-12-28
Anticipated expiration: 2023-06-14
Also published as: ES2271427T3; DE60307736D1; US7631318B2; NO20032749L; NO20032749D0; JP4489382B2; JP2004062890A; NO333104B1; EP1376980B1; US20040003139A1; EP1376980A1; ATE337671T1

Description

TECHNISCHES GEBIET
Diese Erfindung betrifft digitale Rechteverwaltungssysteme. Insbesondere betrifft die Erfindung Plug-in-Architekturen für Pipelines in DRM-Systemen (digital rights management systems).
ALLGEMEINER STAND DER TECHNIK
Digitale Rechteverwaltung und -durchsetzung ist in hohem Maße wünschenswert im Zusammenhang mit digitalem Inhalt, wie beispielsweise digitalen Audiodaten, digitalen Videodaten, digitalem Text, digitalen Daten, digitalen Multimedia usw., bei denen solcher digitaler Inhalt an einen oder mehrere Benutzer verteilt werden soll. Typische Distributionsmodi umfassen konkrete Vorrichtungen, wie beispielsweise eine Magnetplatte (Floppy-Disk), ein Magnetband, eine optische (Kompakt-) Platte (CD), usw. und nicht greifbare Medien, wie beispielsweise ein elektronisches schwarzes Brett, ein elektronisches Netzwerk, das Internet usw. Nach dem Empfang durch den Benutzer gibt ein solcher Benutzer den digitalen Inhalt mit Hilfe einer geeigneten Wiedergabevorrichtung, wie beispielsweise einer Medienwiedergabe-Einrichtung auf einem Arbeitsplatzrechner oder dergleichen wieder oder spielt ihn ab.
In einem Szenario möchte ein Inhalt-Besitzer oder Rechte-Besitzer, wie beispielsweise ein Autor, ein Verleger, ein Rundfunksprecher usw. solchen digitalen Inhalt an jeden von vielen Benutzern oder Empfängern gegen eine Lizenzgebühr oder irgendein anderes Entgelt verteilen. In einem solchen Szenario kann der Inhalt dann ein Lied, eine Sammlung von Liedern, ein Film usw. sein, und der Zweck der Distribution besteht darin, Lizenzgebühren zu generieren. Ein solcher Inhalt-Besitzer würde, wenn er die Wahl hätte, wahrscheinlich wünschen, dass er einschränken kann, was der Benutzer mit einem solchen verteilten digitalen Inhalt tun kann. Zum Beispiel würde der Inhalt-Besitzer wünschen, den Benutzer in Bezug darauf einzuschränken, einen solchen Inhalt zu kopieren und an einen zweiten Benutzer erneut zu verteilen, zumindest auf eine Weise, die dem Inhalt-Besitzer eine Lizenzgebühr von einem solchen zweiten Benutzer vorenthält.
Außerdem kann der Inhalt-Besitzer dem Benutzer die Flexibilität bieten wollen, verschiedene Typen von Nutzungslizenzen zu verschiedenen Lizenzgebühren zu erwerben, wobei der Benutzer gleichzeitig an die Bedingungen des jeweiligen Lizenztyps gebunden wird, den er tatsächlich erworben hat. Zum Beispiel kann der Lizenz-Besitzer wünschen, dass verteilter digitaler Inhalt nur begrenzt oft, nur für eine gewisse Gesamtzeit, nur auf einem bestimmten Maschinentyp, nur auf einem bestimmten Medienabspielgerät, nur von einem bestimmten Typ von Benutzer usw. abgespielt werden kann.
In einem anderen Szenario möchte ein Inhalt-Entwickler, wie beispielsweise ein Mitarbeiter in einer Organisation, solchen digitalen Inhalt an einen oder mehrere Mitarbeiter in der Organisation oder andere Einzelpersonen außerhalb der Organisation verteilen, andere aber daran hindern können, den Inhalt wiederzugeben. Hier ist die Distribution des Inhalts der organisationsbasierten gemeinsamen Inhalt-Nutzung in einer vertraulichen oder eingeschränkten Weise ähnlicher als der Distribution auf breiter Basis gegen eine Lizenzgebühr oder irgendeine andere Gegenleistung. In einem solchen Szenario kann der Inhalt dann eine Dokumentpräsentation, eine Kalkulationstabelle, eine Datenbank, eine E-Mail oder dergleichen sein, wie er in einer Büro-Umgebung ausgetauscht werden kann, und der Inhalt-Entwickler kann sicherstellen wollen, dass der Inhalt innerhalb der Büro-Umgebung bleibt und nicht von unberechtigten Einzelpersonen wiedergegeben wird, wie beispielsweise von Konkurrenten oder Kontrahenten. Wiederum möchte ein solcher Inhalt-Entwickler einschränken können, was ein Empfänger mit einem solchen verteilten digitalen Inhalt tun kann. Zum Beispiel würde der Inhalt-Besitzer einschränken wollen, dass der Benutzer solchen Inhalt kopiert oder an einen zweiten Benutzer weiterverteilt, zumindest in einer Weise, die den Inhalt außerhalb eines Kreises von Personen offenlegt, denen die Wiedergabe des Inhalts gestattet sein sollte.
Des Weiteren kann der Inhalt-Entwickler verschiedene Empfänger mit unterschiedlichen Ebenen von Wiedergaberechten ausstatten wollen. Zum Beispiel kann der Inhalt-Entwickler gestatten wollen, dass geschützter digitaler Inhalt in Bezug auf eine Klasse von Personen anzeigbar und nicht druckbar ist, und in Bezug auf eine andere Klasse von Personen anzeigbar und druckbar ist.
Allerdings, und zwar in jedem Szenario, hat ein solcher Inhalt-Besitzer/-Entwickler nach erfolgter Distribution sehr wenig Kontrolle über den digitalen Inhalt, wenn überhaupt. Dies ist besonders problematisch im Hinblick auf die Tatsache, dass praktisch jeder Arbeitsplatzrechner über die erforderliche Software und Hardware verfügt, um eine exakte digitale Kopie eines solchen digitalen Inhalts zu erstellen und eine solche exakte digitale Kopie auf eine beschreibbare Magnet- oder Bildplatte herunter zu laden, oder eine solche exakte digitale Kopie über ein Netzwerk, wie beispielsweise das Internet, an jedes beliebige Ziel zu senden.
Natürlich kann der Inhalt-Besitzer/-Entwickler von dem Benutzer/Empfänger des digitalen Inhalts als Bestandteil einer Transaktion, in welcher der Inhalt verteilt wird, die Zusage verlangen, solchen digitalen Inhalt nicht in einer unwillkommenen Weise weiterzuverteilen. Ein solches Versprechen wird jedoch leicht gegeben und leicht gebrochen. Ein Inhalt-Besitzer/-Entwickler kann versuchen, eine solche weitere Distribution über irgendwelche von mehreren bekannten Sicherheitsvorrichtungen zu verhindern, die normalerweise Verschlüsselung und Entschlüsselung umfassen, siehe zum Beispiel KONSTANTAS D ET AL: "Agent-based commercial dissemination of electronic information", COMPUTER NETWORKS, ELSEVIER SCIENCE PUBLISHERS B.V. AMSTERDAM, NL, Band 32, Nr. 6, 30. Mai 2000 (30.05.2000), Seite 753–765, ISSN: 1389-1286. Allerdings gibt es wahrscheinlich sehr wenig, das einen auch nur etwas entschlossenen Benutzer daran hindert, verschlüsselten digitalen Inhalt zu entschlüsseln, solchen digitalen Inhalt in einer entschlüsselten Form zu speichern und denselben dann zu verteilen.
Aus vielen Gründen ist die DRM-Servertechnologie dynamisch. Das heißt, wenn sich die Technologie mit der Zeit weiter entwickelt, oder wenn neue Bedrohungen für die Sicherheit des digitalen Inhalts auftreten, werden normalerweise verschiedene Ansätze verwendet, um gewisse Aufgaben für die Bereitstellung von bestimmten Diensten durchzuführen. Häufig umfasst die Bereitstellung eines bestimmten DRM-Dienstes die Durchführung einer Reihe von separaten Aufgaben. Allerdings kann ein Anbieter von Zeit zu Zeit den Wunsch haben, nur eine oder einige Aufgaben auf unterschiedliche Weise auszuführen. Der Anbieter und der Benutzer würden typischerweise bevorzugen, dass das System als Ganzes so wenig wie möglich unterbrochen wird. Zusätzlich möchten Benutzer von solchen DRM-Servern wegen der Kosten und anderen Einschränkungen Systeme haben oder verlangen solche, die unterschiedlich arbeiten. Demzufolge wäre es von Vorteil, wenn Systeme und Verfahren verfügbar wären, mit denen nur ausgewählte Aufgaben innerhalb der Bereitstellung eines digitalen Rechteverwaltungsdienstes auf modulare Weise geändert werden könnten, ohne dazu das gesamte Dienst-Bereitstellungsprogramm modifizieren zu müssen.
Weil eine typische DRM-Installation des Weiteren eine Reihe von digitalen Rechteverwaltungs-Diensten, wie beispielsweise Veröffentlichung, Lizenzierung, Föderierungs-Dienste, Registrierungs-Dienste usw. bereitstellen kann, ist es wünschenswert, dass diese Dienste auf eine Weise bereitgestellt werden, die den Anbieter/Administrator der Installation in die Lage versetzen, das System so effizient wie möglich zu verwalten. Zum Beispiel kann es nicht im Interesse des Administrators sein, den Veröffentlichungs-Dienst jedes Mal aktualisieren zu müssen, wenn an der Lizenzierungskomponente eine Änderung vorgenommen wird und umgekehrt. Demzufolge wäre es von Vorteil, wenn Systeme verfügbar wären, die diese Dienste unabhängig voneinander bereitstellten. Daher besteht in dem Fachgebiet ein Bedarf an einem modularen Ansatz für die voneinander unabhängige Bereitstellung einer Vielzahl von DRM-Diensten. Solche Ansätze wären insbesondere von Vorteil, wenn sie eine Aufgliederung der Schlüssel-Geschäftslogik in Komponenten ermöglichen würden, so dass Dritte DRM-Funktionalität und Geschäftslogik der Plattform erweitern und modifizieren könnten.
KURZDARSTELLUNG DER ERFINDUNG
Gemäß den Ansprüchen 1 und 21 stellt die Erfindung sichere Server-Plug-In-Architekturen für digitale Rechteverwaltungssysteme bereit. Ein Server für digitale Rechteverwaltung gemäß der Erfindung basiert auf einer Pipeline-Architektur, in der jeder von einer Vielzahl von digitalen Rechteverwaltungs-Diensten in einer entsprechenden Pipeline durchgeführt wird, und die jeweiligen Pipelines unabhängig voneinander sind. Solche Dienste können Veröffentlichung und Lizenzierung von rechteverwaltetem digitalem Inhalt umfassen. Jede Pipeline umfasst ein Dienst-Programm, das einen Verarbeitungsrahmen zum Durchführen eines digitalen Rechteverwaltungs-Diensts und eine Vielzahl von Plug-In-Komponenten bereitstellt, von denen jede eine entsprechende Aufgabe durchführt, die mit dem digitalen Rechtverwaltungs-Dienst verknüpft ist.
Ein DRM-System-Anbieter kann die Dienst-Programme und eine Vielzahl von Plug-In-Optionen für digitale Rechteverwaltung bereitstellen, von denen jede mit einer entsprechenden Plug-In-Komponente verknüpft ist. Basierend auf den Auswahlen, die von dem Empfänger der Installation getroffen werden, können gewünschte Plug-In-Komponenten in den Verarbeitungsrahmen gemäß einem entsprechenden vordefinierten Satz von Schnittstellenregeln integriert werden.
Die Vielzahl von Plug-In-Komponenten kann eine oder mehrere Erweiterungs-Plug-In-Komponenten umfassen, die ihre jeweiligen Aufgaben basierend auf dem Auftreten von gewissen vorgeschriebenen Ereignissen durchführen. Eine Erweiterungs-Plug-In-Komponente kann angepasst werden, um die Abarbeitung des Dienst-Programms anzuhalten. Die Vielzahl von Plug-In-Komponenten kann auch eine oder mehrere asynchrone Plug-In-Komponenten umfassen, die ihre jeweiligen Aufgaben durchführen, nachdem die Haupt-Pipeline-Abarbeitung für die Anforderung abgeschlossen ist.
KURZE BESCHREIBUNG DER MEHREREN ANSICHTEN DER ZEICHNUNG
Andere Merkmale der Erfindung gehen des Weiteren aus der folgenden ausführlichen Beschreibung der Ausführungsformen der vorliegenden Erfindung im Zusammenhang mit der begleitenden Zeichnung hervor.
1 ist ein Blockschaltbild, das eine beispielhafte, nicht-einschränkende Rechenumgebung darstellt, in der die vorliegende Erfindung implementiert werden kann.
2 ist ein Blockschaltbild, das eine beispielhafte Netzwerkumgebung mit einer Reihe von Rechenvorrichtungen darstellt, in welchen die vorliegende Erfindung implementiert werden kann.
3 ist ein Funktions-Blockschaltbild einer bevorzugten Ausführungsform eines Systems und Verfahrens gemäß der Erfindung zum Veröffentlichen von digitalem Inhalt.
4 stellt ein Ablaufdiagramm einer bevorzugten Ausführungsform eines Verfahrens gemäß der Erfindung zum Veröffentlichen von rechteverwaltetem digitalem Inhalt bereit.
4A ist ein Blockschaltbild, das die Struktur einer signierten Rechte-Kennzeichnung zeigt, wie sie durch das Verfahren von 4 erzeugt wird.
5 ist ein Funktions-Blockschaltbild einer bevorzugten Ausführungsform eines Systems und Verfahrens gemäß der Erfindung zur Lizenzierung von rechteverwaltetem digitalem Inhalt.
6A und 6B stellen ein Ablaufdiagramm einer bevorzugten Ausführungsform eines Verfahrens gemäß der Erfindung zur Lizenzierung von rechteverwaltetem digitalem Inhalt bereit
7 ist ein Ablaufdiagramm, das die Schlüsselschritte zeigt, die beim erneuten Veröffentlichen einer Rechte-Kennzeichnung in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung durchgeführt werden.
8 ist ein Blockschaltbild, das ein Zertifikat zeigt, das von einem DRM-Server an einer Benutzer ausgegeben wird, um es dem Benutzer zu gestatten, eine Offline-Veröffentlichung in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung auszuführen.
9 ist ein Blockschaltbild, das eine Rechte-Vorlage zeigt, die Informationen angibt, die in eine Rechte-Kennzeichnung in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung aufgenommen werden sollen.
10 ist ein Ablaufdiagramm, das Schlüsselschritte zeigt, die beim Erstellen der Rechte-Vorlage von 9 und Erstellen der signierten Rechte-Kennzeichnung von 4A basierend auf der Rechte-Vorlage in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung ausgeführt werden.
11 veranschaulicht eine generische Pipeline-Architektur gemäß der Erfindung.
12 veranschaulicht eine bevorzugte Ausführungsform eine Veröffentlichungs-Pipeline gemäß der Erfindung.
13 veranschaulicht eine bevorzugte Ausführungsform einer Lizenzierungs-Pipeline gemäß der Erfindung.
14 stellt ein Ablaufdiagram einer bevorzugten Ausführungsform eines Verfahrens gemäß der Erfindung zum Bereitstellen einer sicheren Server-Plug-In-Architektur für digitale Rechteverwaltungssysteme bereit.
AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
Beispielhafte Rechenvorrichtung
1 und die folgende Erörterung sollen eine kurze allgemeine Beschreibung einer geeigneten Rechenumgebung bereitstellen, in welcher die Erfindung implementiert werden kann. Es sollte jedoch klar sein, dass in der Hand gehaltene, tragbare und andere Rechenvorrichtungen aller Arten für die Verwendung in Verbindung mit der vorliegenden Erfindung in Betracht gezogen werden. Zwar wird im Folgenden ein Mehrzweckrechner beschrieben, doch dient er nur als Beispiel, und die vorliegende Erfindung erfordert nur einen dünnen Client mit Netzwerk-Interoperabilität und -Zusammenwirkung. Somit kann die vorliegende Erfindung in einer Umgebung von vernetzten, hostverbundenen (hosted) Servern implementiert werden, in welche sehr wenige oder minimale Client-Ressourcen einbezogen sind, z.B. eine vernetzte Umgebung, in welcher die Client-Vorrichtung nur als ein Browser oder eine Schnittstelle für das World Wide Web dient.
Obwohl nicht erforderlich, kann die Erfindung über eine Anwenderprogrammschnittstelle (API) zur Nutzung durch einen Entwickler und/oder in die Browser-Software des Netzwerks integriert implementiert werden, die im allgemeinen Kontext von rechnerausführbaren Anweisungen, wie beispielsweise Programm-Modulen, beschrieben wird, die von einem oder mehreren Rechnern ausgeführt werden, wie zum Beispiel Client-Workstations, Servern oder anderen Vorrichtungen. Im Allgemeinen enthalten Programm-Module Routinen, Programme, Objekte, Komponenten, Datenstrukturen und derglei chen, die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Typischerweise kann die Funktionalität der Programm-Module kombiniert oder verteilt werden, wie in verschiedenen Ausführungsformen gewünscht. Des Weiteren ist dem Fachmann klar, dass die Erfindung mit anderen Computersystemkonfigurationen ausgeübt werden kann. Andere bekannte Rechensysteme, -umgebungen und/oder -konfigurationen, die zur Verwendung mit der Erfindung geeignet sind, umfassen Einzelplatzrechner (PCs), Geldausgabeautomaten, Server-Rechner, in der Hand gehaltene oder tragbare Vorrichtungen, Multiprozessorsysteme, mikroprozessorbasierte Systeme, programmierbare Verbraucherelektronik, Netzwerk-PCs, Minicomputer, Großrechner und dergleichen, sind aber nicht darauf beschränkt. Die Erfindung kann auch in verteilten Rechenumgebungen ausgeübt werden, in denen Aufgaben von entfernten Verarbeitungsvorrichtungen durchgeführt werden, die über ein Kommunikationsnetzwerk oder ein anderes Datenübertragungsmedium verbunden sind. In einer verteilten Rechenumgebung können sich Programm-Module sowohl in lokalen als auch entfernten Rechner-Speichermedien befinden, einschließlich Speichervorrichtungen.
1 veranschaulicht somit ein Beispiel einer geeigneten Rechensystemumgebung 100, in welcher die Erfindung implementiert werden kann, obwohl, wie oben verdeutlicht, die Rechensystemumgebung 100 nur ein Beispiel einer geeigneten Rechenumgebung ist und keine Einschränkung hinsichtlich des Umfangs von Verwendung oder Funktionalität der Erfindung andeuten soll. Die Rechenumgebung 100 sollte auch nicht so interpretiert werden, als würde sie irgendeine Abhängigkeit oder Anforderung in Bezug auf irgendeine Komponente oder eine Kombination von Komponenten aufweisen, die in der beispielhaften Betriebsumgebung 100 veranschaulicht sind.
Unter Bezugnahme auf 1 umfasst ein beispielhaftes System zum Implementieren der Erfindung eine Mehrzweck-Rechenvorrichtung in der Form eines Rechners 110. Komponenten des Rechners 100 können eine Verarbeitungseinheit 120, einen Systemspeicher 130 und einen Systembus 121, der verschiedene Systemkomponenten einschließlich des Systemspeichers an die Verarbeitungseinheit 120 koppelt, umfassen, sind aber nicht darauf beschränkt. Der Systembus 121 kann irgendeiner von mehreren Typen von Busstrukturen sein, einschließlich eines Speicherbusses oder einer Speichersteuereinrichtung, eines Peripheriebusses und eines Internbusses, die irgendeine von einer Reihe von Busarchitekturen verwenden. Als Beispiel, und nicht als Einschrän kung, umfassen solche Architekturen Industry Standard Architecture- (ISA) Bus, Micro Channel Architecture- (MCA) Bus, Enhanced ISA- (EISA) Bus, Video Electronics Standards Association- (VESA) Internbus und Peripheral Component Interconnect- (PCI) Bus (auch bekannt als Mezzanine-Bus).
Der Rechner 110 umfasst typischerweise eine Reihe von computerlesbaren Medien. Computerlesbare Medien können irgendwelche verfügbaren Medien sein, auf die vom Rechner 110 zugegriffen werden kann, und umfassen sowohl flüchtige als auch nichtflüchtige Medien, entfernbare und nicht entfernbare Medien. Als Beispiel, und nicht als Einschränkung, können computerlesbare Medien Computerspeichermedien und Kommunikationsmedien umfassen. Zu Computerspeichermedien gehören sowohl flüchtige als auch nicht-flüchtige, entfernbare und nicht entfernbare Medien, die in einem beliebigen Verfahren oder mit einer beliebigen Technologie zum Speichern von Informationen implementiert sind, wie beispielsweise computerlesbaren Anweisungen, Datenstrukturen, Programm-Modulen oder anderen Daten. Computerspeichermedien umfassen RAM, ROM, EEPROM, Flash-Speicher oder eine andere Speichertechnologie, CDROM, DVD (digital versatile disk) oder einen anderen Bildplattenspeicher, Magnetbandkassetten, Magnetband, Magnetplattenspeicher oder andere Magnetspeichervorrichtungen oder irgendein anderes Medium, das zum Speichern der gewünschten Informationen verwendet werden kann und auf das vom Rechner 110 zugegriffen werden kann, sind aber nicht darauf beschränkt. Kommunikationsmedien verkörpern typischerweise computerlesbare Anweisungen, Datenstrukturen, Programm-Module oder andere Daten in einem modulierten Datensignal, wie beispielsweise eine Trägerwelle oder einen anderen Transportmechanismus, und enthalten beliebige Informationsabgabemedien. Der Begriff "moduliertes Datensignal" bedeutet ein Signal, für das eine oder mehrere seiner Kennlinien eingestellt oder so geändert wurden, dass Informationen in dem Signal verschlüsselt werden. Als Beispiel, und nicht als Einschränkung, umfassen Kommunikationsmedien verkabelte Medien, wie beispielsweise ein verkabeltes Netzwerk oder eine Direktleitungsverbindung, und drahtlose Medien, wie beispielsweise akustische, HF-, Infrarot- und andere drahtlose Medien. Kombinationen von irgendwelchen der oben genannten sollten ebenfalls in den Umfang von computerlesbaren Medien aufgenommen werden.
Der Systemspeicher 130 umfasst Computerspeichermedien in der Form von flüchtigem und/oder nicht-flüchtigem Speicher, wie beispielsweise Festwertspeicher (ROM) 131 und Direktzugriffsspeicher (RAM) 132. Ein grundlegendes Eingabe/Ausgabe-System 133 (BIOS), das die fundamentalen Routinen enthält, welche die Übertragung von Informationen zwischen Elementen in dem Rechner 110 unterstützen, wie beispielsweise beim Hochfahren, ist typischerweise im ROM 131 gespeichert. Der RAM 132 enthält typischerweise Daten und/oder Programm-Module, auf die unmittelbar zugegriffen werden kann und/oder mit denen gegenwärtig von der Verarbeitungseinheit 120 gearbeitet wird. Als Beispiel, und nicht als Einschränkung, veranschaulicht 1 Betriebssystem 134, Anwendungsprogramme 135, andere Programm-Module 136 und Programmdaten 137.
Der Computer 110 kann auch andere entfernbare/nicht-entfernbare, flüchtige/nicht-flüchtige Computerspeichermedien enthalten. Nur als Beispiel veranschaulicht 1 ein Festplattenlaufwerk 141, das von nicht-entfernbaren, nicht-flüchtigen Magnetmedien liest oder diese beschreibt, ein Magnetplattenlaufwerk 151, das von einer entfernbaren, nicht-flüchtigen Magnetplatte 152 liest oder diese beschreibt, und ein Bildplattenlaufwerk 155, das von einer entfernbaren, nicht-flüchtigen Bildplatte 156, wie beispielsweise einer CDROM, oder einem anderen optischen Medium liest oder dieses beschreibt. Andere entfernbare/nicht-entfernbare, flüchtige/nicht-flüchtige Computerspeichermedien, die in der beispielhaften Betriebsumgebung verwendet werden können, umfassen Magnetbandkassetten, Flash-Speicherkarten, DVDs, Digitalvideoband, Halbleiter-RAM, Halbleiter-ROM und dergleichen, sind aber nicht darauf beschränkt. Das Festplattenlaufwerk 141 ist typischerweise über eine nicht-entfernbare Speicherschnittstelle, wie beispielsweise die Schnittstelle 140, an den Systembus 121 angeschlossen, und das Magnetplattenlaufwerk 151 und das Bildplattenlaufwerk 155 sind typischerweise über eine entfernbare Speicherschnittstelle, wie beispielsweise die Schnittstelle 150, an den Systembus 121 angeschlossen.
Die Laufwerke und ihre oben erläuterten und in 1 veranschaulichten zugehörigen Computerspeichermedien sorgen für die Speicherung von computerlesbaren Anweisungen, Datenstrukturen, Programm-Modulen und anderen Daten für den Rechner 110. In 1 wird das Festplattenlaufwerk 141 zum Beispiel so dargestellt, dass es Betriebssystem 144, Anwendungsprogramme 145, andere Programm-Module 146 und Programmdaten 147 speichert. Es ist zu beachten, dass diese Komponenten entweder dieselben oder verschieden von Betriebssystem 134, Anwendungsprogrammen 135, anderen Programm-Modulen 136 und Programmdaten 137 sein können. Betriebssystem 144, Anwendungsprogramme 145, andere Programm-Module 146 und Programmdaten 147 wurden hier mit anderen Bezugszeichen versehen, um zu veranschaulichen, dass sie zumindest unterschiedliche Kopien sind. Ein Benutzer kann Befehle und Informationen über Eingabevorrichtungen, wie beispielsweise eine Tastatur 162 und ein Zeigegerät 161, die im Allgemeinen als Maus, Rollkugel oder integriertes Berührungsfeld bezeichnet werden, in den Rechner 110 eingeben. Andere (nicht gezeigte) Eingabevorrichtungen können ein Mikrofon, einen Joystick, ein Spiele-Pad, eine Satellitenschüssel, einen Scanner oder dergleichen umfassen. Diese und andere Eingabevorrichtungen sind oft über eine Benutzer-Eingabeschnittstelle 160, die an den Systembus 121 angekoppelt ist, mit der Verarbeitungseinheit 210 verbunden, sie können aber auch über eine andere Schnittstelle und andere Busstrukturen, wie beispielsweise einen Parallel-Port, Spiele-Port oder einen Universal Serial Bus (USB), angeschlossen werden.
Ein Monitor 191 oder ein anderer Typ von Anzeigevorrichtung ist ebenfalls an den Systembus 121 über eine Schnittstelle angeschlossen, wie beispielsweise eine Videoschnittstelle 190. Ein Grafikschnittstelle 182, wie beispielsweise Northbridge, kann ebenfalls an den Systembus 121 angeschlossen sein. Northbridge ist ein Chipsatz, der mit der CPU oder Host-Verarbeitungseinheit 120 in Verbindung steht und für Datenübertragungen des Accelerated Graphics Port (AGP) zuständig ist. Eine oder mehrere Grafik-Verarbeitungseinheiten (GPUs) 184 können mit der Grafikschnittstelle 182 in Verbindung stehen. Diesbezüglich umfassen die GPUs im Allgemeinen einen auf dem Chip ausgeführten Speicher, wie beispielsweise einen Registerspeicher, und die GPUs 184 stehen mit einem Videospeicher 186 in Verbindung. Die GPUs 184 sind jedoch nur ein Beispiel für einen Koprozessor, und damit kann eine Reihe von Koprozessor-Vorrichtungen in dem Rechner 110 enthalten sein. Ein Monitor 191 oder eine anderer Typ von Anzeigevorrichtung ist ebenfalls an den Systembus 121 über eine Schnittstelle angeschlossen, wie beispielsweise eine Videoschnittstelle 190, die wiederum mit dem Videospeicher 186 in Verbindung stehen kann. Zusätzlich zum Monitor 191 können Rechner auch andere Peripherie-Ausgabevorrichtungen umfassen, wie beispielsweise Lautsprecher 197 und einen Drucker 196, die über eine Ausgabe-Peripherieschnittstelle 195 angeschlossen werden können.
Der Rechner 110 kann in einer vernetzten Umgebung unter Verwendung von logischen Verbindungen zu einem oder mehreren entfernten Rechnern arbeiten, wie beispielswei se einem entfernten Rechner 180. Der entfernte Rechner 180 kann ein Arbeitsplatzrechner, ein Server, ein Router, ein Netzwerk-PC, eine gleichberechtigte Vorrichtung oder ein anderer gemeinsamer Netzwerkknoten sein und umfasst typischerweise viele oder alle der oben in Bezug auf den Rechner 100 beschriebenen Elemente, obwohl in 1 nur eine Speichervorrichtung 181 veranschaulicht worden ist. Die in 1 dargestellten logischen Verbindungen umfassen ein lokales Netzwerk (LAN) 171 und ein Weitverkehrsnetz (WAN) 173, können aber andere Netzwerke umfassen. Solche vernetzten Umgebungen sind in Büros, unternehmensübergreifenden Computer-Netzwerken, Intranets und dem Internet allgemein üblich.
Wenn er in einer vernetzten LAN-Umgebung eingesetzt wird, ist der Rechner 110 über eine Netzwerkschnittstelle oder einen Adapater 170 an das LAN 171 angeschlossen. Wenn er in einer vernetzten WAN-Umgebung eingesetzt wird, umfasst der Rechner 110 typischerweise ein Modem 172 oder andere Mittel zum Herstellen von Datenübertragungen über das WAN 173, wie beispielsweise das Internet. Das Modem 172, das intern oder extern sein kann, kann über die Benutzer-Eingabeschnittstelle 160 oder einen anderen zweckdienlichen Mechanismus an den Systembus 121 angeschlossen werden. In einer vernetzten Umgebung können Programm-Module, die in Bezug auf den Rechner 110 dargestellt sind, oder Teile von diesen in der entfernten Speichervorrichtung gespeichert werden. Als Beispiel, und nicht als Einschränkung, veranschaulicht 1 entfernte Anwendungsprogramme 185 als auf der Speichervorrichtung 181 resident. Es ist klar, dass die gezeigten Netzwerkverbindungen beispielhaft sind und andere Einrichtungen zum Herstellen einer Datenübertragungsverbindung zwischen den Rechnern verwendet werden können.
Dem durchschnittlichen Fachmann ist klar, dass ein Rechner 110 oder eine andere Client-Vorrichtung als Teil eines Computernetzwerks verwendet werden können. Diesbezüglich betrifft die vorliegende Erfindung jedes Computersystem mit einer beliebigen Anzahl von Speichereinheiten und einer beliebigen Anzahl von Anwendungen und Prozessen, die übergreifend auf einer beliebigen Anzahl von Speichereinheiten oder Speichervolumen auftreten können. Die vorliegende Erfindung lässt sich auf eine Umgebung mit Server-Computern und Client-Computern anwenden, die in einer vernetzten Umgebung eingesetzt werden und einen entfernten oder lokalen Speicher aufweisen. Die vorliegende Erfindung kann auch auf eine eigenständige Rechenvorrichtung angewendet werden, die eine Programmiersprachen-Funktionalität sowie Interpretations- und Ausführungsfähigkeiten aufweist.
Verteiltes Rechnen erleichtert die gemeinsame Nutzung von Rechner-Ressourcen und Diensten durch direkten Austausch zwischen Rechenvorrichtungen und -systemen. Diese Ressourcen und Dienste umfassen den Austausch von Informationen, Cache-Speicherung und Plattenspeicherung für Dateien. Verteiltes Rechnen zieht Vorteil aus der Netzwerk-Konnektivität, wobei es Clients ermöglicht wird, ihre kollektive Leistung zum Wohl des gesamten Unternehmens wirksam einzusetzen. Diesbezüglich kann eine Reihe von Vorrichtungen Anwendungen, Objekte oder Ressourcen aufweisen, die zusammenwirken können, um Authentifizierungstechniken der vorliegenden Erfindung für eine bzw. mehrere verlässliche Grafik-Pipelines einzubeziehen.
2 stellt eine schematische Darstellung einer beispielhaften vernetzten oder verteilten Rechenumgebung bereit. Die verteilte Rechenumgebung umfasst Rechenobjekte 10a, 10b usw. und Rechenobjekte oder -vorrichtungen 110a, 110b, 110c usw. Diese Objekte können Programme, Verfahren, Datenspeicher, programmierbare Logik usw. umfassen. Die Objekte können Teile der gleichen oder verschiedene Vorrichtungen umfassen, wie beispielsweise PDAs, Fernsehgeräte, MP3-Spieler, Arbeitsplatzrechner usw. Jedes Objekt kann mit einem anderen Objekt über das Kommunikationsnetzwerk 14 kommunizieren. Dieses Netzwerk selbst kann andere Rechenobjekte und Rechenvorrichtungen umfassen, die für das System von 2 Dienste bereitstellen. In Übereinstimmung mit einem Aspekt der Erfindung kann jedes Objekt 10 oder 110 eine Anwendung enthalten, welche die Authentifizierungs-Techniken der vorliegenden Erfindung für eine bzw. mehrere verlässliche Grafik-Pipelines anfordern könnte.
Es lässt sich ebenso verstehen, dass ein Objekt, wie beispielsweise 110c, eine andere Rechenvorrichtung 10 oder 110 als Hostrechner aufweisen kann. Somit, obwohl die dargestellte physikalische Umgebung die verbundenen Vorrichtungen als Rechner zeigen kann, ist eine solche Darstellung nur veranschaulichend, und die physikalische Umgebung kann alternativ so dargestellt oder beschrieben werden, dass sie verschiedene digitale Vorrichtungen umfasst, wie beispielsweise PDAs, Fernsehgeräte, MP3-Spieler usw., Software-Objekte wie beispielsweise Schnittstellen, COM-Objekte und dergleichen.
Es gibt eine Reihe von Systemen, Komponenten und Netzwerk-Konfigurationen, die verteilte Rechenumgebungen unterstützen. Zum Beispiel können Rechensysteme durch drahtgebundene oder drahtlose Systeme, durch lokale Netzwerke oder weit verteilte Netzwerke verbunden sein. Derzeit sind viele der Netzwerke an das Internet gekoppelt, was die Infrastruktur für weit verteiltes Rechnen bereitstellt und viele verschiedene Netzwerke umfasst.
In Hausnetz-Umgebungen sind wenigstens vier verschiedene Netzwerk-Transportmedien vorhanden, von denen jedes ein eindeutiges Protokoll unterstützen kann, wie beispielsweise Stromleitung, Daten (sowohl drahtlos als auch drahtgebunden), Sprache (z.B. Telefon) und Unterhaltungsmedien. Die meisten Haus-Steuervorrichtungen, wie beispielsweise Lichtschalter und Haushaltsgeräte können zur Anschlussfähigkeit die Stromleitung verwenden. Datendienste können als Breitband in das Haus gelangen, (z.B. entweder DSL oder Kabelmodem), und der Zugriff auf sie kann im Haus unter Verwendung von entweder drahtloser (z. B. HomeRF oder 802.11b) oder drahtgebundener (z.B. Home-PNA, Cat 5, sogar Stromleitung) Anschlussfähigkeit erfolgen. Sprachverkehr kann entweder als drahtgebunden (z.B. Cat 3) oder drahtlos (z.B. Mobiltelefon) in das Haus gelangen und kann im Haus unter Verwendung von Cat-3-Verkabelung verteilt werden. Unterhaltungsmedien können über Satellit oder Kabel in das Haus gelangen und werden typischerweise im Haus unter Verwendung von Koaxialkabeln verteilt. IEEE 1394 und DVI treten ebenfalls als digitale Verbindungen für Gruppen von Medien-Vorrichtungen in Erscheinung. Alle diese Netzwerkumgebungen und andere, die als Protokoll-Standards in Erscheinung treten können, können miteinander verbunden werden, um ein Intranet auszubilden, das mit der Außenwelt über das Internet verbunden werden kann. Kurz, es ist eine Reihe verschiedener Quellen für die Speicherung und Übertragung von Daten vorhanden, und demzufolge erfordern sich weiterentwickelnde Rechenvorrichtungen Möglichkeiten zum Schützen von Inhalt in allen Abschnitten der Datenverarbeitungs-Pipeline.
Das Internet bezieht sich im Allgemeinen auf die Sammlung von Netzwerken und Netzübergängen, welche die TCP-/IP-Suite von Protokollen verwenden, die im Fachgebiet von Rechnervernetzungen bekannt sind. TCP/IP ist eine Abkürzung für "Transport Control Protocol/Internet Protocol". Das Internet kann als ein System von geografisch verteilten entfernten Computer-Netzwerken beschrieben werden, die über Rechner verbunden sind, die Vernetzungsprotokolle ausführen, mit denen es Benutzern gestattet wird, zu interagieren und Informationen über die Netzwerke gemeinsam zu nutzen. Wegen einer solchen weit verbreiteten gemeinsamen Informationsnutzung haben sich entfernte Netzwerke, wie beispielsweise das Internet, bisher im Allgemeinen zu einem offenen System entwickelt, für das Entwickler Software-Anwendungen konzipieren können, um spezielle Operationen oder Dienste im Wesentlichen ohne Einschränkungen durchzuführen.
Somit ermöglicht die Netzwerk-Infrastruktur eine Menge von Netzwerk-Topologien, wie zum Beispiel Client/Server-, Peer-to-Peer- oder Hybrid-Architekturen. Der "Client" ist ein Mitglied einer Klasse oder Gruppe, der die Dienste einer anderen Klasse oder Gruppe verwendet, mit welcher er in keiner Beziehung steht. Daher ist ein Client in der EDV ein Prozess, d.h. grob gesagt ein Satz von Anweisungen oder Aufgaben, der einen Dienst anfordert, der von einem anderen Programm bereitgestellt wird. Der Client-Prozess verwendet den angeforderten Dienst, ohne irgendwelche Arbeitsdetails über das andere Programm oder den Dienst selbst "kennen" zu müssen. In einer Client/Server-Architektur, insbesondere einem vernetzten System, ist ein Client normalerweise ein Rechner, der auf gemeinsam genutzte Netzwerk-Ressourcen zugreift, die von einem anderen Rechner bereitgestellt werden, z.B. einem Server. In dem Beispiel von 2 kann man sich die Rechner 110a, 110b usw. als Clients vorstellen, und die Rechner 10a, 10b usw. kann man sich als den Server vorstellen, wobei der Server 10a, 10b usw. die Daten verwaltet, die dann in den Client-Computern 110a, 110b usw. reproduziert werden.
Ein Server ist typischerweise ein entferntes Computersystem, auf das über ein entferntes Netzwerk, wie zum Beispiel das Internet, zugegriffen werden kann. Der Client-Prozess kann in einem ersten Computersystem aktiv sein, und der Server-Prozess kann in einem zweiten Computersystem aktiv sein, die miteinander über ein Kommunikationsmedium in Verbindung stehen, wodurch eine verteilte Funktionalität bereitgestellt wird und es mehreren Clients gestattet wird, die Informationssammlungs-Fähigkeiten des Servers zu nutzen.
Client und Server kommunizieren miteinander unter Verwendung der Funktionalität, die von einer Protokollschicht bereitgestellt wird. Zum Beispiel ist das Hypertext Transfer Protocol (HTTP) eine übliches Protokoll, das in Verbindung mit dem World Wide Web (WWW) verwendet wird. Typischerweise wird eine Computer-Netzwerkadresse, wie zum Beispiel eine Internetadresse (URL) oder eine Internet-Protokoll- (IP) Adresse verwendet, um die Server- oder Client-Computer gegenseitig zu identifizieren. Die Netzwerkadresse kann als eine Internetadresse (Universal Resource Locator) bezeichnet werden. Zum Beispiel kann Kommunikation über ein Kommunikationsmedium bereitgestellt werden. Insbesondere können Client und Server über TCP/IP-Verbindungen für Hochleistungskommunikationen aneinander gekoppelt werden.
Somit veranschaulicht 2 eine beispielhafte vernetzte oder verteilte Umgebung mit einem Server, der mit Client-Computern über ein Netzwerk/einen Bus in Verbindung steht, in welcher die vorliegende Erfindung eingesetzt werden kann. Im Detail ist eine Reihe von Servern 10a, 10b usw. über ein Kommunikations-Netzwerk/einen Bus 14, der ein LAN, WAN, Intranet, das Internet usw. sein kann, in Übereinstimmung mit der vorliegenden Erfindung mit einer Reihe von Client- oder entfernten Rechenvorrichtungen 110a, 110b, 110c, 110d, 110e usw. verbunden, wie beispielsweise einem tragbaren Rechner, einem in der Hand gehaltenen Rechner, einem dünnen Client, einem vernetzten Gerät oder einer anderen Vorrichtungen, wie beispielsweise Videorekorder, Fernsehgerät, Ofen, Beleuchtung, Heizung und dergleichen. Somit wird in Betracht gezogen, dass die vorliegende Erfindung auf jede beliebige Rechenvorrichtung angewendet werden kann, in Verbindung mit der es wünschenswert ist, Inhalt aus einer verlässlichen Quelle zu verarbeiten, zu speichern oder wiederzugeben.
In einer Netzwerkumgebung, in welcher das Kommunikations-Netzwerk/der Bus 14 zum Beispiel das Internet ist, können die Server 10 Web-Server sein, mit denen die Clients 110a, 110b, 110c, 110d, 110e usw. über irgendeines von einer Reihe von bekannten Protokollen kommunizieren, wie beispielsweise HTTP. Die Server 10 können auch als Clients 110 dienen, was für eine verteilte Rechenumgebung charakteristisch sein kann. Kommunikationen können drahtgebunden oder drahtlos sein, wo sachdienlich. Client-Vorrichtungen 110 können über das Kommunikations-Netzwerk/den Bus 14 kommunizieren oder nicht, und können damit verbundene unabhängige Kommunikationen aufweisen. Zum Beispiel kann in dem Fall eines Fernsehgeräts oder Videorekorders zu deren Steuerung ein Vernetzungsaspekt vorhanden sein oder nicht. Jeder Client-Computer 110 und Server-Computer 10 kann mit verschiedenen Anwendungsprogramm-Modulen oder Objekten 135 und mit Verbindungen zu oder Zugriff auf verschiedene Typen von Speicherelementen oder Objekten ausgestattet sein, über die Dateien gespeichert werden können, oder auf die ein Teil bzw. Teile von Dateien heruntergeladen oder migriert werden können. Somit kann die vorliegende Erfindung in einer Computer-Netzwerkumgebung verwendet werden, die Client-Computer 110a, 110b usw., die auf ein Computer-Netzwerk/einen Bus 14 zugreifen und mit diesen interagieren können, und Server-Computer 10a, 10b usw. die mit Client-Computern 110a, 110b usw. interagieren können, und andere Vorrichtungen 111 und Datenbanken 20 aufweist.
Digitalen Inhalt veröffentlichen
3 ist ein Funktions-Blockschaltbild einer bevorzugten Ausführungsform eines Systems und Verfahrens gemäß der Erfindung zum Veröffentlichen von digitalem Inhalt. So, wie der Begriff "Veröffentlichen" hierin verwendet wird, bezieht er sich auf einen Prozess, dem eine Anwendung oder ein Dienst folgt, um mit einer verlässlichen Entität einen Satz von Rechten und Bedingungen herzustellen, welche die Entität für den Inhalt ausgeben kann, sowie auf denjenigen, an den diese Rechte und Bedingungen ausgegeben werden können. Gemäß der Erfindung umfasst der Veröffentlichungsprozess Verschlüsseln des digitalen Inhalts und Verknüpfen einer Liste von durchsetzbaren Dauer-Rechten, die der Autor des Inhalts für alle möglichen Benutzer des Inhalts beabsichtigt hat. Dieser Prozess kann auf eine sichere Weise ausgeführt werden, um Zugriff auf die Rechte oder den Inhalt zu unterbinden, es sei denn, er ist vom Autor des Inhalts beabsichtigt.
In einer bevorzugten Ausführungsform der Erfindung können insbesondere drei Entitäten verwendet werden, um sicheren digitalen Inhalt zu veröffentlichen: eine Inhalts-Vorbereitungsanwendung 302, die auf dem Client 300 ausgeführt wird und den Inhalt zur Veröffentlichung vorbereitet, eine digitale Rechteverwaltungs- (DRM) Anwenderprogrammschnittstelle (API) 306, die ebenfalls auf der Client-Vorrichtung 300 resident ist, und ein DRM-Server 320, der kommunikativ über ein Kommunikations-Netzwerk 330 an den Client 300 gekoppelt ist. In einer bevorzugten Ausführungsform der Erfindung umfasst das Kommunikations-Netzwerk 330 das Internet, obwohl klar sein sollte, dass das Kommunikations-Netzwerk 330 jedes lokale oder Weitverkehrsnetz sein könnte, wie beispielsweise ein proprietäres Intranet.
Die Inhalts-Vorbereitungsanwendung 302 kann jede Anwendung sein, die digitalen Inhalt erzeugt. Zum Beispiel kann die Anwendung 302 ein Textverarbeitungsprogramm oder ein anderes Veröffentlichungsprogramm (publisher) sein, das digitale Textdateien, digitale Musik, Video oder anderen solchen Inhalt erzeugt. Der Inhalt könnte zum Beispiel auch Streaming-Inhalt enthalten, wie beispielsweise Streaming-Audio-/Video-Daten eines Live- oder aufgezeichneten Ereignisses. Gemäß der Erfindung fordert die Inhalts-Vorbereitungsanwendung ihren Benutzer auf, den Inhalt unter Verwendung eines Schlüssels zu verschlüsseln, den der Benutzer bereitstellt. Die Anwendung 302 verwendet den Schlüssel zum Verschlüsseln des digitalen Inhalts und bildet damit eine verschlüsselte digitale Inhaltsdatei 304. Die Client-Anwendung fordert den Benutzer auch auf, Rechte-Daten für die digitale Inhaltsdatei 304 bereitzustellen. Die Rechte-Daten enthalten eine entsprechende Identität für jede Entität, die Rechte in dem digitalen Inhalt hat. Eine solche Entität kann zum Beispiel eine Einzelperson, eine Klasse von Einzelpersonen oder eine Vorrichtung sein. Für jede solche Entität enthalten die Rechte-Daten auch eine Liste von Rechten, welche die Entität in dem Inhalt hat, und alle Bedingungen, die irgendeinem oder allen diesen Rechten zur Auflage gemacht werden können. Solche Rechte können das Recht zum Lesen, Bearbeiten, Kopieren, Drucken usw. des digitalen Inhalts umfassen. Außerdem können Rechte inklusiv oder exklusiv sein. Inklusive Rechte geben an, dass ein bestimmter Benutzer ein bestimmtes Recht in dem Inhalt hat, (z.B. der Benutzer kann den digitalen Inhalt bearbeiten). Exklusive Rechte geben an, dass ein bestimmter Benutzer alle Rechte in dem Inhalt hat, ausgenommen diejenigen, die angegeben sind, (z.B. der Benutzer kann mit den digitalen Text tun, was er möchte, außer ihn kopieren).
Gemäß einer Ausführungsform der Erfindung kann die Client-API 306 den verschlüsselten digitalen Inhalt und die Rechte-Daten an den DRM-Server 320 übergeben. Unter Verwendung eines Prozesses, der im Folgenden im Detail beschrieben wird, bestimmt der DRM-Server 320, ob er die Rechte, die der Benutzer zugewiesen hat, durchsetzen kann, und falls ja, signiert der DRM-Server 320 die Rechte-Daten, um eine signierte Rechte-Kennzeichnung (SRL) 308 zu bilden. Im Allgemeinen kann jedoch jede verlässliche Entität die Rechte-Daten signieren, vorzugsweise unter Verwendung eines Schlüssels, der für den DRM-Server 320 verlässlich ist. Zum Beispiel kann ein Client die Rech te-Daten unter Verwendung eines Schlüssels signieren, der für ihn durch den DRM-Server 320 bereitgestellt wird.
Die Rechte-Kennzeichnung 308 kann Daten enthalten, welche die Rechte-Beschreibung, den verschlüsselten Inhalts-Schlüssel und die digitale Signatur über der Rechte-Beschreibung und dem verschlüsselten Inhalts-Schlüssel darstellen. Wenn der DRM-Server die Rechte-Kennzeichnung signiert, übergibt er die signierte Rechte-Kennzeichnung 308 an den Client über die Client API 306 zurück, welche die signierte Rechte-Kennzeichnung 308 auf der Client-Vorrichtung 300 speichert. Die Inhalts-Vorbereitungsanwendung 302 verknüpft dann die signierte Rechte-Kennzeichnung 308 mit der verschlüsselten digitalen Inhaltsdatei 304. Zum Beispiel kann die SRL 308 mit der verschlüsselten digitalen Inhaltsdatei verkettet werden, um eine rechteverwaltete Inhaltsdatei 310 zu bilden. Im Allgemeinen müssen die Rechte-Daten jedoch nicht mit dem digitalen Inhalt kombiniert werden. Zum Beispiel könnten die Rechte-Daten in einem bekannten Speicherplatz gespeichert werden, und ein Verweis auf die gespeicherten Rechte-Daten könnte mit dem verschlüsselten digitalen Inhalt kombiniert werden. Der Verweis könnte eine Kennung enthalten, die angibt, wo die Rechte-Daten gespeichert sind (z.B. den Datenspeicher, der die Rechte-Daten enthält), und eine Kennung, die den bestimmten Rechte-Daten auf dem bestimmten Speicherplatz entspricht (von der die Datei z.B. identifiziert wird, welche die bestimmten Rechte-Daten von Interesse enthält). Der rechteverwaltete Inhalt 310 kann dann zu irgendjemand irgendwohin übergeben werden, und nur diejenigen Entitäten, die Rechte zum Abnehmen (consume) des Inhalts haben, können den Inhalt abnehmen, und zwar nur in Übereinstimmung mit den Rechten, die ihnen zugewiesen worden sind.
4 ist ein Ablaufdiagramm eines beispielhaften Verfahrens 400 gemäß der Erfindung zum Veröffentlichen von rechteverwaltetem digitalem Inhalt, wobei die Rechte-Kennzeichnung von einem DRM-Server signiert ist. Es sollte jedoch klar sein, dass diese Ausführungsform nur beispielhaft ist, und dass die Rechte-Kennzeichnung im Allgemeinen von jeder verlässlichen Entität signiert werden kann. Im Allgemeinen kann ein Verfahren gemäß der Erfindung zum Veröffentlichen von digitalem Inhalt umfassen: Verschlüsseln des digitalen Inhalts unter Verwendung eines Inhalts-Schlüssels (CK), Generieren einer Rechte-Beschreibung, die mit dem digitalen Inhalt verknüpft ist, Verschlüsseln des Inhalts-Schlüssels (CK) gemäß einem öffentlichen Schlüssel für einen DRM- Server (PU-DRM), damit sich (PU-DRM(CK)) ergibt, und Erstellen einer digitalen Signatur auf Basis eines privaten Schlüssels (PR-DRM), der (PU-DRM) entspricht, über die Kombination der Rechte-Beschreibung und von (PU-DRM(CK)).
In Schritt 402 generiert die Anwendung 302 einen Inhalts-Schlüssel (CK), der zum Verschlüsseln des digitalen Inhalts verwendet wird. Vorzugsweise ist der Inhalts-Schlüssel (CK) ein symmetrischer Schlüssel, obwohl im Allgemeinen jeder Schlüssel zum Verschlüsseln des digitalen Inhalts verwendet werden kann. Symmetrische Schlüssel-Algorithmen, die manchmal als "Geheimschlüssel"-Algorithmen bezeichnet werden, verwenden den gleichen Schlüssel zum Entschlüsseln einer Nachricht, den sie zum Verschlüsseln der Nachricht verwendet haben. Aus diesem Grund wird bevorzugt, dass (CK) geheim gehalten wird. Die gemeinsame Nutzung von (CK) zwischen Absender und Empfänger sollte mit großer Vorsicht erfolgen, um das unberechtigte Abfangen eines solchen (CK) zu vermeiden. Da (CK) von Verschlüsseler und Entschlüsseler gemeinsam genutzt wird, wird (CK) vorzugsweise übermittelt, bevor irgendwelche verschlüsselten Nachrichten übertragen werden.
Mehrere Generierungsalgorithmen für symmetrische Schlüssel sind im Fachgebiet bekannt. In einer bevorzugten Ausführungsform wird der Data Encryption Standard (DES) verwendet, obwohl klar sein sollte, dass jeder symmetrische Algorithmus verwendet werden könnte. Beispiele für solche Algorithmen für symmetrische Schlüssel umfassen ohne Einschränkung Triple-DES, den International Data Encryption Algorithm (IDEA), Cast, Cast-128, RC4, RC5 und SkipJack.
In Schritt 404 verschlüsselt die Anwendung 302 den digitalen Inhalt mit dem symmetrischen Inhalts-Schlüssel (CK), um verschlüsselten digitalen Inhalt 304 zu bilden, der unter Verwendung der Anmerkung (CK(content)) geschrieben werden kann. Der Autor, der die Anwendung 302 verwendet, kann auch Rechte-Daten generieren, die mit dem digitalen Inhalt verknüpft sind. Die Rechte-Daten können eine Liste von Entitäten, die berechtigt sein werden, den Inhalt abzunehmen, und die spezifischen Rechte, die jede der Entitäten in Bezug auf den Inhalt besitzt, zusammen mit allen Bedingungen enthalten, die für diese Rechte zur Auflage gemacht werden können. Solche Rechte können zum Beispiel das Ansehen des Inhalts, das Drucken des Inhalts usw. umfassen. Die Anwendung 302 stellt die Rechte-Daten für die API 306 bereit. Ein Beispiel von Rechte-Daten im XML/XrML-Format befindet sind im Anhang hierzu als Anhang 1.
In Schritt 406 generiert die API 306 einen zweiten Verschlüsselungsschlüssel (DES1), der zum Verschlüsseln des Inhalts-Schlüssels (CK) verwendet wird. Vorzugsweise ist (DES1) ebenfalls ein symmetrischer Schlüssel. In Schritt 408 verschlüsselt die API 306 (CK) mit (DES1), damit sich (DES1(CK)) ergibt. In Schritt 410 verwirft die API 306 (CK) mit dem Ergebnis, dass (CK) jetzt nur noch durch Entschlüsseln von (DES1(CK)) erhalten werden kann. Um sicherzustellen, dass (CK(content)) für einen zentralen DRM-Server 320 geschützt ist, und dass alle "Lizenzanforderungen" für den Inhalt tatsächlich zentral in Übereinstimmung mit den Rechte-Daten erfolgen, kontaktiert die API 306 in Schritt 4112 den bereitgestellten DRM-Server 320 und ruft den öffentlichen Schlüssel (PU-DRM) von diesem ab. In Schritt 414 verschlüsselt die API 306 (DES1) mit (PU-DRM), damit sich (PU-DRM(DES1)) ergibt. Somit kann (CK) für (PU-DRM) geschützt werden, um sicherzustellen, dass der DRM-Server 320 die einzige Entität ist, die in der Lage sein wird, auf (CK) Zugriff zu erhalten, wie zum Entschlüsseln von (CK(content)) erforderlich ist. In Schritt 416 verschlüsselt die API 306 die Rechte-Daten, (d.h. die Liste von berechtigten Entitäten und die entsprechenden Rechte und Bedingungen, die mit jeder berechtigten Entität in der Liste verknüpft sind), mit (DES1), damit sich (DES1(rtghtsdata)) ergibt.
In einer alternativen Ausführungsform kann (CK) verwendet werden, um die Rechte-Daten direkt zu verschlüsseln, damit sich (CK(rigsdata)) ergibt, und damit die Verwendung von (DES1) vollständig umgangen wird. Allerdings gestattet die Verwendung von (DES1) zum Verschlüsseln der Rechte-Daten, einen solchen (DES1) jedem bestimmten Algorithmus anzupassen, der an den DRM-Server angepasst werden könnte, wogegen (CK) von einer vom DRM-Server unabhängigen Entität spezifiziert werden und nicht an diesen angepasst werden könnte.
In Schritt 418 kann die Inhalts-Schutzanwendung 302 (PU-DRM(DES1)) und (DES1(rightsdata)) als Rechte-Kennzeichnung dem DRM-Server 320 zum Signieren übermitteln. Alternativ kann der Client selbst die Rechte-Daten signieren. Wenn die Rechte-Daten dem Server zum Signieren übermittelt werden, dann greift der DRM-Server 320 in Schritt 420 auf die Rechte-Daten zu und verifiziert, dass er die Rechte und Be dingungen in der übermittelten Rechte-Kennzeichnung durchsetzen kann. Zum Verifizieren, dass er die Rechte-Daten durchsetzen kann, wendet der DRM-Server 320 (PR-DRM) auf (PU-DRM(DES1)) an, damit sich (DES1) ergibt, und wendet dann (DES1) auf (DES1(rightsdata)) an, damit sich die Rechte-Daten im Klartext ergeben. Der Server 320 kann dann beliebige Richtlinienprüfungen durchführen, um zu verifizieren, dass die Benutzer, Rechte und Bedingungen, die in den Rechte-Daten spezifiziert wurden, innerhalb einer Richtlinie liegen, die von dem Server 320 durchgesetzt wird. Der Server 320 signiert die ursprünglich übermittelte Rechte-Kennzeichnung, die (PU-DRM(DES1)) und (DES1(rightsdata)) enthält, damit sich die signierte Rechte-Kennzeichnung (SRL) 308 ergibt, wobei die Signatur auf dem privaten Schlüssel des DRM-Servers 320 (PR-DRM) basiert, und gibt die SRL 308 an die API 306 zurück, die dann die zurückgegebene SRL 308 an die Client-Anwendung 302 übergibt.
Die SRL 308 ist ein digital signiertes Dokument, was es manipulationssicher macht. Des Weiteren ist die SRL 308 unabhängig vom tatsächlichen Schlüssel-Typ und dem Algorithmus, der zum Verschlüsseln des Inhalts verwendet wird, und behält die starke 1-1-Beziehung zu dem Inhalt bei, den sie schützt. Unter folgender Bezugnahme auf 4A kann die SRL 308 in einer Ausführungsform der vorliegenden Erfindung unter anderem Folgendes enthalten: Informationen über den Inhalt, der die Basis der SRL 308 ist, einschließlich vielleicht einer Kennung des Inhalts; Informationen über den DRM-Server, der die SRL 308 signiert, einschließlich (PU-DRM(DES1)) und Verweis-Informationen, wie beispielsweise eine URL zum Lokalisieren des DRM-Servers auf einem Netzwerk, und Rückverweis-Informationen, wenn die URL fehlschlägt; Informationen, welche die SRL 308 selbst beschreiben; (DES1(rightsdata)); (DES1(CK)); und S(PR-DRM). Eine Beispiel-SRL 308 in XML/XrML befindet sich im Anhang hierzu als Anhang 2.
Indem sichergestellt wird, dass eine verlässliche Entität die Rechte-Daten signiert, um eine signierte Rechte-Kennzeichnung 308 zu erstellen, bestätigt der DRM-Server, dass er Lizenzen für den Inhalt in Übereinstimmung mit den durch das Veröffentlichungsprogramm vorgegebenen Bedingungen ausgibt, wie sie in den Rechte-Daten der Rechte-Kennzeichnung 308 beschrieben sind. Wie klar sein sollte, muss ein Benutzer eine Lizenz erlangen, um den Inhalt wiederzugeben, insbesondere deswegen, weil die Lizenz den Inhalts-Schlüssel (CK) enthält. Wenn ein Benutzer eine Lizenz für einen verschlüsselten Inhalt erhalten möchte, kann der Benutzer eine Lizenzanforderung mit der SRL 308 für den Inhalt und einem Zertifikat, das die Berechtigungsnachweise des Benutzers verifiziert, an den DRM-Server 320 oder eine andere lizenzausgebende Entität übergeben. Die lizenzausgebende Entität kann dann, um die Rechte-Daten zu erzeugen, (PU-DRM(DES1) und (DES1(rightsdata)) verschlüsseln, alle Rechte (sofern vorhanden), die der lizenzanfordernden Entität von dem Autor gewährt wurden, auflisten, und eine Lizenz nur mit diesen spezifischen Rechten erstellen.
Vorzugsweise nachdem die Anwendung 302 die SRL 308 empfangen hat, verkettet eine solche Anwendung 302 die signierte Rechte-Kennzeichnung 308 mit dem entsprechenden (CK(content)) 304, um rechteverwalteten digitalen Inhalt zu bilden. Alternativ können die Rechte-Daten in einem bekannten Speicherplatz gespeichert werden, wobei ein Verweis auf den Speicherplatz mit dem verschlüsselten digitalen Inhalt bereitgestellt wird. Somit kann eine Wiedergabe-Anwendung, die DRM-aktiviert ist, die signierte Rechte-Kennzeichnung 308 über den Teil des Inhalts erfassen, den die Wiedergabe-Anwendung versucht, wiederzugeben. Diese Erfassung steuert die Wiedergabe-Anwendung an, eine Lizenzanforderung zum DRM-Lizenzierungs-Server 320 zu initiieren. Die Veröffentlichungsanwendung 302 kann zum Beispiel eine URL für den DRM-Lizenzierungs-Server 320 speichern, oder der DRM-Lizenzierungs-Server 320 kann seine eigene URL als einen Teil von Metadaten in die Rechte-Kennzeichnung einbetten, bevor er sie digital signiert, so dass die DRM-Client-API 306, die von der Wiedergabe-Anwendung aufgerufen wird, den richtigen DRM-Lizenzierungs-Server 320 identifizieren kann. Vorzugsweise wird eine eindeutige Kennung, wie beispielsweise eine global eindeutige Kennung (GUID), in die Rechte-Kennzeichnung eingesetzt, bevor sie signiert wird.
In einer bevorzugten Ausführungsform der Erfindung kann ein einfaches Objektzugriffsprotokoll (SOAP) für die Kommunikation zwischen der Inhalts-Schutzanwendung 302 oder der Wiedergabe-Anwendung und dem DRM-Server 320 verwendet werden. Des Weiteren können API-Bibliotheken, wie beispielsweise API 306, bereitgestellt werden, so dass Anwendungen, wie beispielsweise die Anwendung 302, nicht erforderlich sind, um die Client-Seite des DRM-Protokolls zu implementieren, sondern einfach lokale API-Aufrufe getätigt werden. Vorzugsweise wird XrML, eine XML-Sprache, zum Beschreiben von Rechte-Beschreibungen, Lizenzen und Rechte-Kennzeichnungen für digitalen Inhalt verwendet, obwohl klar sein sollte, dass für die Rechte-Beschreibung und andere Daten jedes geeignete Format verwendet werden kann.
Erlangen einer Lizenz für den veröffentlichten Inhalt
5 ist ein Funktions-Blockschaltbild einer bevorzugten Ausführungsform eines Systems und Verfahrens gemäß der Erfindung zum Lizenzieren von rechteverwaltetem digitalem Inhalt. So, wie der Begriff "Lizenzierung" hierin verwendet wird, bezieht er sich auf einen Prozess, dem eine Anwendung oder ein Dienst folgt, um eine Lizenz anzufordern und zu erhalten, der eine in der Lizenz benannte Entität in die Lage versetzt, den Inhalt in Übereinstimmung mit den in der Lizenz spezifizierten Bedingungen abzunehmen. Eingaben in den Lizenzierungsprozess können signierte Rechte-Kennzeichnungen (SRL) 308, die mit dem Inhalt verknüpft sind, für den eine Lizenz angefordert worden ist, und das bzw. die öffentlichen Schlüssel-Zertifikate der Entität oder Entitäten umfassen, für welche die Lizenz angefordert wird. Es ist zu beachten, dass die Entität, die eine Lizenz anfordert, nicht notwendigerweise die Entität sein muss, für welche die Lizenz angefordert wird. Typischerweise enthält eine Lizenz die Rechte-Beschreibung von der SRL 308, einen verschlüsselten Schlüssel, der den verschlüsselten Inhalt entschlüsseln kann, und eine digitale Signatur über der Rechte-Beschreibung und den verschlüsselten Schlüssel. Die digitale Signatur stellt sicher, dass die Entitäten und benannten Rechte berechtigt sind.
Eine Möglichkeit für die Anwendung 302, den rechteverwalteten Inhalt 310 abzunehmen, besteht darin, dass die Client-API 306 die signierte Rechte-Kennzeichnung 308 des rechteverwalteten Inhalts 310 über das Kommunikationsnetzwerk 330 an den DRM-Server 320 weiterleitet. Der Speicherplatz des DRM-Servers 320 lässt sich zum Beispiel in den Verweis-Informationen in der SRL 308 finden. In einer solchen Ausführungsform kann der DRM-Lizenzierungs-Server 320 über einen Prozess, der im Folgenden ausführlich beschrieben wird, die Rechte-Beschreibung in der Rechte-Kennzeichnung verwenden, um zu bestimmen, ob er eine Lizenz ausgeben kann, und falls ja, die Rechte-Beschreibung ableiten, um sie in die Lizenz zu integrieren. Wie oben beschrieben, enthält die Rechte-Kennzeichnung 308 den Inhalts-Schlüssel (CK), der gemäß dem öffentlichen Schlüssel des DRM-Servers 320 (PU-DRM), (d.h. (PU-DRM(CK))), verschlüsselt ist. In dem Prozess zur Lizenzausgabe nimmt der DRM-Server 320 eine sichere Entschlüsselung dieses Werts vor, um (CK) zu erhalten. Danach verwendet er den öffentli chen Schlüssel (PU-ENTITY) in dem öffentlichen Schlüssel-Zertifikat, das an die Lizenzanforderung übergeben worden ist, um eine erneute Verschlüsselung von (CK), (d.h. PU-ENTITY(CK))), vorzunehmen. Der erneut verschlüsselte (PU-ENTITY(CK)) ist das, was der Server 320 in die Lizenz stellt. Somit kann die Lizenz zum Anrufer zurückgegeben werden, ohne Gefahr zu laufen, (CK) preiszugeben, da der einzige Inhaber des zugehörigen privaten Schlüssels (PR-ENTITY) (CK) aus (PU-ENTITY(CK)) wiedererlangen kann. Die Client-API 306 verwendet dann (CK), um den verschlüsselten Inhalt zu entschlüsseln, um einen entschlüsselten digitalen Inhalt 312 zu bilden. Die Client-API 302 kann dann den entschlüsselten digitalen Inhalt 312 gemäß den in der Lizenz bereitgestellten Rechten verwenden.
Alternativ kann ein Client, wie zum Beispiel der veröffentlichende Client, seine eigene Lizenz ausgeben, um den Inhalt abzunehmen. In einer solchen Ausführungsform kann ein geschützter Prozess auf dem Client-Computer ausgeführt werden, der für den Client den bzw. die Schlüssel bereitstellt, die zum Entschlüsseln des digitalen Inhalts unter entsprechenden Umständen erforderlich sind.
6A und 6B stellen ein Ablaufdiagramm einer bevorzugten Ausführungsform eines Verfahrens 600 gemäß der Erfindung zum Lizenzieren von rechteverwaltetem digitalem Inhalt bereit. Gemäß der Erfindung kann eine anfordernde Entität eine Lizenzanforderung für einen oder mehrere potenzielle Lizenznehmer übermitteln. Die anfordernde Entität kann einer der potenziellen Lizenznehmer sein oder nicht. Ein potenzieller Lizenznehmer kann eine Person, eine Gruppe, eine Vorrichtung oder irgendeine andere solche Entität sein, die den Inhalt in irgendeiner Weise abnehmen kann. Das Verfahren 600 wird im Folgenden unter Bezugnahme auf eine Ausführungsform beschrieben, in der ein DRM-Prozessor die Lizenzanforderung verarbeitet, obwohl klar sein sollte, dass die Lizenzanforderungs-Verarbeitung auch auf dem Client durchgeführt und Lizenzen direkt von diesem ausgegeben werden könnten.
In Schritt 602 empfängt eine lizenzausgebende Entität, wie beispielsweise ein DRM-Server, zum Beispiel eine Lizenzanforderung. Vorzugsweise enthält eine Lizenzanforderung entweder ein Öffentliches Schlüssel-Zertifikat oder eine Identität für jeden von einem oder mehreren angeforderten Lizenznehmern. Das SOAP-Protokoll für eine bevorzugte Ausführungsform einer Lizenzanforderung lautet:
In Schritt 604 wird die anfordernde Entität, (d.h. die Entität, welche die Lizenzanforderung vornimmt), authentifiziert. Gemäß einer Ausführungsform der Erfindung kann die lizenzausgebende Entität so konfiguriert werden, dass sie eine Protokoll- (z.B. Challenge-Response) Authentifizierung verwendet, um die Identität der anfordernden Entität zu bestimmen, oder sie kann so konfiguriert werden, dass die keine Authentifizierung der anfordernen Entität erfordert, (auch bekannt als "anonyme Authentifizierung zulässig"). Wenn eine Authentifizierung erforderlich ist, kann jeder Typ von Authentifizierungssche ma verwendet werden, (z.B. das oben genannte Challenge-Response-Schema, ein Benutzerkennungs- und Passwort-Schema, wie beispielsweise MICROSOFT.NET, PASSPORT, WINDOWS-Berechtigung, x509 usw.). Vorzugsweise wird die anonyme Authentifizierung gestattet sowie die Unterstützung jedes Protokoll-Authentifizierungsschemas, das von integrierten Datensystemen unterstützt wird. Das Ergebnis des Authentifizierungsschritts ist eine Identität, wie beispielsweise eine "anonyme" Identität (zur anonymen Authentifizierung), oder zum Beispiel eine persönliche Account-Identität. Wenn die Lizenzanforderung aus irgendeinem Grund nicht authentifiziert werden kann, wird ein Fehler zurückgegeben, und es wird keine Lizenz gewährt.
In Schritt 606 wird die authentifizierte Entität berechtigt – d.h. es wird bestimmt, ob es der in Schritt 608 authentifizierten Entität gestattet ist, eine Lizenz anzufordern, (entweder für sich selbst oder für eine andere Entität). Vorzugsweise speichert die lizenzausgebende Entität eine Liste von Entitäten, denen es gestattet (oder nicht gestattet) ist, eine Lizenz anzufordern. In einer bevorzugten Ausführungsform ist eine Identität in dieser Liste von Identitäten die Identität der Entität, welche die Anforderung vornimmt, und nicht die Identität der Entität, für die eine Lizenz angefordert wird, obwohl beides der Fall sein könnte. Zum Beispiel kann es einer persönlichen Account-Identität nicht gestattet sein, eine Lizenzanforderung direkt zu tätigen, aber ein verlässlicher Server-Prozess kann eine Lizenzanforderung für eine solche Entität vornehmen.
Gemäß der Erfindung kann die Lizenzanforderung entweder ein öffentliches Schlüssel-Zertifikat oder eine Identität für jeden potenziellen Lizenznehmer aufnehmen. Wenn eine Lizenz nur für einen Lizenznehmer angefordert wird, wird nur ein Zertifikat bzw. eine Identität genannt. Wenn eine Lizenz für eine Vielzahl von Lizenznehmern angefordert wird, kann ein Zertifikat oder eine Identität für jeden potenziellen Lizenznehmer genannt werden.
Vorzugsweise weist die lizenzausgebende Entität ein öffentliches Schlüssel-Zertifikat für jeden gültigen Lizenznehmer auf. Eine Anwendung 302 möchte aber eine Lizenz für einen vorgegebenen Benutzer generieren, doch kann die Anwendung 320 unter Umständen nicht auf das öffentliche Schlüssel-Zertifikat für diesen Benutzer zugreifen. In einer solchen Situation kann die Anwendung 302 die Identität des Benutzers in der Lizenzanforderung spezifizieren, und als Ergebnis dessen kann die lizenzausgebende Entität ei ne registrierte Zertifikats-Plug-In-Komponente aufrufen, die eine Suche in einem Verzeichnisdienst durchführt und das öffentliche Schlüssel-Zertifikat des entsprechenden Benutzers zurückgibt.
Wenn in Schritt 608 die ausgebende Entität bestimmt, dass das öffentliche Schlüssel-Zertifikat nicht in der Lizenzanforderung enthalten ist, verwendet die ausgebende Entität die spezifizierte Identität zum Durchführen einer Suche in einem Verzeichnisdienst oder einer Datenbank nach dem entsprechenden öffentlichen Schlüssel-Zertifikat. Wenn in Schritt 610 die ausgebende Entität bestimmt, dass das Zertifikat sich in dem Verzeichnis befindet, wird das Verzeichnis anschließend in Schritt 612 abgerufen. In einer bevorzugten Ausführungsform wird ein Zertifikats-Plug-In verwendet, um öffentliche Schlüssel-Zertifikate aus einem Verzeichnisdienst mittels eines Verzeichniszugangsprotokolls abzurufen. Wenn ein Zertifikat für einen vorgegebenen potenziellen Lizenznehmer weder in der Anforderung noch in dem Verzeichnis gefunden werden kann, generiert der Lizenz-Server keine Lizenz für diesen potenziellen Lizenznehmer, und in Schritt 614 wird ein Fehler an die anfordernde Entität zurückgegeben.
Angenommen, die lizenzausgebende Entität weist ein öffentliches Schlüssel-Zertifikat für wenigstens einen potenziellen Lizenznehmer auf, dann validiert die ausgebende Entität in Schritt 616 die Verlässlichkeit der Lizenznehmer-Zertifikate. Vorzugsweise wird die ausgebende Entität mit einem Satz von verlässlichen Ausgeber-Zertifikaten konfiguriert, und sie bestimmt, ob der Ausgeber des Lizenznehmer-Zertifikats sich in der Liste von verlässlichen Ausgebern befindet. Wenn die ausgebende Entität in Schritt 616 bestimmt, dass der Ausgeber des Lizenznehmer-Zertifikats sich nicht in der Liste von verlässlichen Ausgebern befindet, dann schlägt die Anforderung für diesen Lizenznehmer fehl, und in Schritt 614 wird ein Fehler generiert. Somit würde jeder potenzielle Lizenznehmer, dessen Zertifikat nicht von einem verlässlichen Ausgeber ausgegeben wird, keine Lizenz erhalten.
Zusätzlich führt die ausgebende Entität vorzugsweise eine Validierung der digitalen Signatur für alle Entitäten in der Zertifikatskette durch, von den verlässlichen Ausgeber-Zertifikaten bis hin zu den einzelnen öffentlichen Schlüssel-Zertifikaten von Lizenznehmern. Der Prozess des Validierens der digitalen Signaturen in einer Kette ist ein bekannter Algorithmus. Wenn das öffentliche Schlüssel-Zertifikat für einen vorgegebenen potenziellen Lizenznehmer nicht validiert wird, oder ein Zertifikat in der Kette nicht validiert wird, ist der potenzielle Lizenznehmer nicht verlässlich, und daher wird an den potenziellen Lizenznehmer keine Lizenz ausgegeben. Andernfalls kann in Schritt 618 eine Lizenz ausgegeben werden. Der Prozess wird bei Schritt 620 wiederholt, bis alle Entitäten, für die eine Lizenz angefordert worden ist, verarbeitet worden sind.
Wie in 6B gezeigt, fährt die lizenzausgebende Entität damit fort, die signierte Rechte-Kennzeichnung 308 zu validieren, die in der Lizenzanforderung empfangen worden ist. In einer bevorzugten Ausführungsform kann die ausgebende Entität ein Rechte-Kennzeichnungs-Plug-In und eine nachgestellte Datenbank verwenden, um auf dem Server eine Vorlage jeder Rechte-Kennzeichnung, die von der ausgebenden Entität signiert worden ist, zu speichern. Die Rechte-Kennzeichnungen werden von der in ihnen bei der Veröffentlichung platzierten GUID identifiziert. Zum Lizenz-Zeitpunkt (in Schritt 622) analysiert die ausgebende Entität die Rechte-Kennzeichnung, die in die Lizenzanforderung eingegeben ist, und ruft ihre GUID ab. Dann übergibt sie diese GUID an das Rechte-Kennzeichnungs-Plug-In, das eine Abfrage der Datenbank ausgibt, um eine Kopie der Vorlagen-Rechte-Kennzeichnung abzurufen. Die Vorlagen-Rechte-Kennzeichnung könnte aktueller sein als die Kopie der Rechte-Kennzeichnung, die in der Lizenzanforderung gesendet wurde, und sie wird die Rechte-Kennzeichnung sein, die in der Anforderung in den folgenden Schritten verwendet wird. Wenn keine Rechte-Kennzeichnung in der Datenbank auf Basis der GUID gefunden wird, prüft die ausgebende Entität ihre Richtlinie in Schritt 624, um zu bestimmen, ob sie eine Lizenz auf Basis der Rechte-Kennzeichnung in der Anforderung immer noch ausgeben darf. Wenn die Richtlinie dies nicht gestattet, schlägt die Lizenzanforderung in Schritt 626 fehl, und in Schritt 628 wird ein Fehler an die API 306 zurückgegeben.
In Schritt 630 validiert die lizenzausgebende Entität die Rechte-Kennzeichnung 308. Die digitale Signatur auf der Rechte-Kennzeichnung wird validiert, und wenn die lizenzausgebende Entität nicht der Ausgeber der Rechte-Kennzeichnung, (die Entität, die sie signiert hat), ist, dann bestimmt die lizenzausgebende Entität, ob der Ausgeber der Rechte-Kennzeichnung eine andere verlässliche Entität ist, (z.B. eine Entität, mit der die lizenzausgebende Entität Schlüssel-Material gemeinsam nutzen kann). Wenn die Rechte-Kennzeichnung nicht validiert wird oder nicht von einer verlässlichen Entität ausgegeben wird, dann schlägt die Lizenzanforderung in Schritt 626 fehl, und in Schritt 628 wird ein Fehler an die API 306 zurückgegeben.
Nachdem alle Validierungen durchgeführt worden sind, übersetzt die lizenzausgebende Entität die Rechte-Kennzeichnung 308 in eine Lizenz für jeden der genehmigten Lizenznehmer. In Schritt 632 generiert die lizenzausgebende Entität eine entsprechende Rechte-Beschreibung für die Lizenz, die an jeden Lizenznehmer ausgegeben werden soll. Für jede Lizenz wertet die ausgebende Entität die Identität, die in dem öffentlichen Schlüssel-Zertifikat dieses Lizenznehmers genannt ist, im Vergleich mit den Identitäten aus, die in der Rechte-Beschreibung in der Rechte-Kennzeichnung genannt sind. Die Rechte-Beschreibung weist jedem Recht bzw. jedem Satz von Rechten einen Satz von Identitäten zu, die das Recht bzw. den Satz von Rechten in einer Lizenz ausüben können. Für jedes Recht bzw. jeden Satz von Rechten, mit denen die Identität dieses Lizenznehmers verknüpft ist, wird dieses Recht bzw. der Satz von Rechten in eine neue Datenstruktur für die Lizenz kopiert. Die sich daraus ergebende Datenstruktur ist die Rechte-Beschreibung in der Lizenz für den bestimmten Lizenznehmer. Als Bestandteil dieses Prozesses wertet die lizenzausgebende Entität alle Vorbedingungen aus, die mit jedem Recht bzw. dem Satz von Rechten in der Rechte-Beschreibung der Rechte-Kennzeichnung verknüpft sein könnten. Zum Beispiel kann mit einem Recht eine Zeit-Vorbedingung verknüpft sein, welche die lizenzausgebende Entität einschränkt, eine Lizenz nach einem spezifizierten Zeitpunkt auszugeben. In diesem Fall müsste die ausgebende Entität den aktuellen Zeitpunkt prüfen, und falls dieser nach dem in der Vorbedingung spezifizierten Zeitpunkt liegt, wäre die ausgebende Entität nicht mehr in der Lage, das Recht an den Lizenznehmer auszugeben, selbst wenn die Identität dieses Lizenznehmers mit diesem Recht verknüpft wäre.
In Schritt 636 nimmt die ausgebende Entität (PU-DRM(DES1)) und (DES1(CK)) aus der Rechte-Kennzeichnung 308 und wendet (PR-DRM) an, um (CK) zu erhalten. Dann verschlüsselt die ausgebende Entität (CK) erneut unter Verwendung von (PU-ENTITY), dem öffentlichen Schlüssel-Zertifikat des Lizenznehmers, damit sich (PU-ENTITY(CK)) ergibt. In Schritt 638 verkettet die ausgebende Entität die generierte Rechte-Beschreibung mit (PU-ENTITY(CK)) und signiert die sich daraus ergebende Datenstruktur digital unter Verwendung von (PR-DRM). Diese signierte Datenstruktur ist die Lizenz für diesen bestimmten Lizenznehmer.
Wenn die ausgebende Entität in Schritt 640 bestimmt, dass keine weiteren Lizenzen für die bestimmte Anforderung zu generieren ist, hat sie keine oder mehrere Lizenzen generiert. Die generierten Lizenzen werden in Schritt 642 an die anfordernde Entität zurückgegeben, zusammen mit der Zertifikatkette, die mit diesen Lizenzen verknüpft ist, (z.B. das eigene öffentliche Schlüssel-Zertifikat des Servers sowie das Zertifikat, das als sein Zertifikat ausgegeben worden ist, und so weiter).
Das SOAP-Protokoll für eine bevorzugte Ausführungsform einer Lizenzantwort lautet wie folgt:
In einer bevorzugten Ausführungsform eines Systems gemäß der Erfindung kann eine Vielzahl von Lizenzgeber-Schlüsseln verwendet werden. In einer solchen Ausführungsform kann der Inhalts-Schlüssel (CK), der verschlüsselt durch die Rechte-Kennzeichnung 308 und in die Lizenz weitergegeben wird, irgendwelche beliebigen Daten sein. Eine besondere nützliche Variante besteht dann, eine Vielzahl von getrennten, verschlüsselten Inhalts-Schlüsseln (CK) zu verwenden, die jeweils mit verschiedenen Rechten oder verschiedenen Principals in der Rechte-Beschreibung verknüpft sind. Zum Beispiel könnten die digitalen Versionen von Liedern in einer Sammlung von Liedern alle mit verschiedenen Schlüsseln (CK) verschlüsselt sein. Diese Schlüssel (CK) wären in der gleichen Rechte-Kennzeichnung enthalten, aber ein Principal kann das Recht haben, eines der Lieder zu spielen, (z.B. er hat eventuell nur Rechte, den einen Schlüssel in seiner Lizenz zu erhalten), während ein zweiter Principal eventuell Rechte haben könnte, alle Lieder zu spielen, (er hätte Rechte, alle Schlüssel in seiner Lizenz zu erhalten).
Vorzugsweise gestattet ein System gemäß der Erfindung das Veröffentlichen von Anwendungen/Benutzern, um Gruppen oder Klassen von Lizenznehmern in einer Rechte-Kennzeichnung 308 zu benennen. In einer solchen Ausführungsform wertet die lizenzausgebende Entität alle Gruppen/Klassen aus, die in der Rechte-Kennzeichnung benannt sind, um zu bestimmen, ob die aktuelle Lizenznehmer-Identität ein Mitglied dieser Gruppen/Klassen ist. Wenn eine Mitgliedschaft in einer benannten Gruppe/Klasse gefunden wird, könnte die ausgebende Entität die Rechte bzw. den Satz von Rechten, der mit der Gruppe/Klasse verknüpft ist, zu der Rechte-Beschreibungs-Datenstruktur hinzufügen, die für die Lizenz verwendet wird.
In einer bevorzugten Ausführungsform der Erfindung unterstützen die Veröffentlichungs- und Lizenz-Protokoll-Schnittstellen in dem DRM-Server Authentifizierung und Autorisierung der rufenden Anwendung bzw. des Benutzers, und die Administrationskonsole für den DRM-Server gestattet es einem Administrator, eine Zugangskontrollliste sowohl für die Lizenzierungs- als auch die Veröffentlichungs-Schnittstelle zu generieren. Dies ermöglicht es dem Kunden des Servers, eine Richtlinie anzuwenden, über die es Benutzern/Anwendungen gestattet wird, entweder zu veröffentlichen, Lizenzen auszugeben oder beides.
Modifizieren oder erneutes Veröffentlichen der signierten Rechte-Kennzeichnung 308
In einer Ausführungsform der vorliegenden Erfindung kann die SRL 308 "erneut veröffentlicht" werden, wenn dem Benutzer des Inhalts ausreichende Erlaubnis gewährt wurde, dies zu tun. Das heißt, der Benutzer kann, falls zulässig, Rechte-Daten in der SRL 308 ändern. Insbesondere sollte mit einer solchen Erlaubnis zum Ändern der Rechte-Daten sparsam und vernünftig umgegangen werden, vor allem insofern, als ein Benutzer mit der Erlaubnis zum Ändern der Rechte-Daten sich im Wesentlichen selbst umfangreiche Rechte in Bezug auf den verknüpften Inhalt erteilen kann. Es ist vorstellbar, dass ein solcher Benutzer sich sogar das Recht erteilen könnte, den Inhalt preiszugeben und denselben an die Außenwelt weiterzuleiten.
Hier wird die Erlaubnis zur Änderung dadurch gekennzeichnet, dass in die Rechte-Daten in der SRL 308 eine Angabe aufgenommen wird, dass ein bestimmter Benutzer bzw. eine Klasse von Benutzern tatsächlich die Rechte-Daten und die Rechte-Kennzeichnung 308 ändern oder "erneut veröffentlichen" kann. Wenn der DRM-Server 320 eine solche SRL 308 mit einer solchen Erlaubnis im Zusammenhang mit einer Anforderung einer Lizenz empfängt, nimmt der DRM-Server 320 in die angeforderte Lizenz für den Benutzer den symmetrischen Schlüssel (DES1) auf, der gemäß dem öffentlichen Schlüssel des Benutzers, (d.h. PU-ENTITY) verschlüsselt ist, damit sich (PU-ENTITY(DES1)) ergibt.
Somit, zum Bearbeiten der Rechte-Daten in der SRL 308 und unter folgender Bezugnahme auf 7, ruft der Benutzer (PU-ENTITY(DES1)) aus der Lizenz ab (Schritt 701), wendet (PR-ENTITY) an, damit sich (DES1) ergibt (Schritt 703), ruft (DES1(rightsdata)) aus der SRL 308 ab (Schritt 705) und wendet (DES1) darauf an, damit sich die Rechte-Daten ergeben (Schritt 707). Danach ändert der Benutzer die Rechte-Daten wunschgemäß (Schritt 709) und übergibt die geänderten Rechte-Daten an den DRM-Server 320 in der Weise, die in Verbindung mit 4 dargelegt wurde, um eine signierte Rechte-Kennzeichnung zu erhalten (Schritt 711). Natürlich ist die signierte Rechte-Kennzeichnung 308 hier tatsächlich eine erneut veröffentlichte SRL 308, und dementsprechend, sobald die SRL 308 empfangen wird (Schritt 713), entfernt der Benutzer die ursprüngliche SRL 308, die mit dem verknüpften Inhalt verkettet ist (Schritt 715) und verkettet dann die erneut veröffentlichte SRL 308 mit solchem Inhalt (Schritt 717).
Somit, und wie klar sein dürfte, ermöglicht es die erneute Veröffentlichung einer SRL 308 einem Benutzer, die Rechte-Daten in der SRL 308 zu aktualisieren, einschließlich Rechten, Bedingungen und Benutzern, ohne den damit verknüpften Inhalt ändern zu müssen. Insbesondere erfordert das erneute Veröffentlichen kein Verschlüsseln des damit verknüpften Inhalts mit einem neuen (CK). Das erneute Verschlüsseln erfordert des Weiteren kein Generieren einer vollständig neuen SRL, insbesondere insofern, als die ursprüngliche SRL 308 viele Elemente darin enthält, die in die neue SRL 308 kopiert werden können.
Selbst-Veröffentlichen der signierten Rechte-Kennzeichnung 308
In einer Ausführungsform der vorliegenden Erfindung kann die SRL 308 vom anfordernden Benutzer selbst signiert werden. Dementsprechend muss der Benutzer keinen Kontakt mit dem DRM-Server 320 aufnehmen, um eine SRL 308 für einen verknüpften Teil des Inhalts zu erhalten. Als Ergebnis dessen kann Selbst-Veröffentlichen auch als Offline-Veröffentlichen bezeichnet werden. In einer solchen Ausführungsform kann der Benutzer aufgefordert werden, mit einem DRM-Server 320 Kontakt aufzunehmen, um eine Lizenz auf Basis einer solchen selbst-veröffentlichten SRL 308 anzufordern. Es sollte auch klar sein, dass eine veröffentlichende Entität in die Lage versetzt werden kann, ihre eigenen Lizenzen auszugeben.
Insbesondere und unter folgender Bezugnahme auf 8 wird ein Benutzer in der Ausführungsform zunächst für Selbst-Veröffentlichung festgelegt (provisioned), indem er von einem DRM-Server 320 ein DRM-Zertifikat 810 mit einem öffentlichen Schlüssel (PU-CERT) und einem entsprechenden privaten Schlüssel (PR-CERT) empfängt, der gemäß dem öffentlichen Schlüssel des Benutzers (PU-ENTITY) verschlüsselt ist, damit sich (PU-ENTITY(PR-CERT)) ergibt. Das Zertifikat sollte durch den öffentlichen Schlüssel des DRM-Servers 320 (PR-DRM) signiert sein, so dass ein solcher DRM-Server 320 dasselbe verifizieren kann, wie im Folgenden ausführlicher erläutert. Wie klar sein dürfte, berechtigt das DRM-Zertifikat 810 den Benutzer zur Selbst-Veröffentlichung. Wie ebenfalls klar sein dürfte, ist das Schlüssel-Paar (PU-CERT, PR-CERT) von (PU-ENTITY, PR-ENTITY) getrennt und wird speziell für Selbst-Veröffentlichung verwendet.
PR-ENTITY) getrennt und wird speziell für Selbst-Veröffentlichung verwendet. Es ist zu beachten, dass auf das Schlüssel-Paar (PU-CERT, PR-CERT) verzichtet werden kann, in welchem Fall das DRM-Zertifikat 810 nur den öffentlichen Schlüssel des Benutzers (PU-ENTITY) enthält und durch den privaten Schlüssel des DRM-Servers 320 (PR-DRM) signiert ist, so dass ein solcher DRM-Server 320 dasselbe verifizieren kann.
Selbst-Veröffentlichung unterscheidet sich von Veröffentlichung, wie in 4 gezeigt, dadurch, dass der Benutzer im Wesentlichen den Platz des DRM-Servers 320 in Bezug auf Schritte einnimmt, die von diesem durchgeführt werden. Bezeichnenderweise signiert der Benutzer die übermittelte Rechte-Kennzeichnung, die (PU-DRM(DES1)) und (DES1(rightsdata)) enthält, mit (PR-CERT), wie aus dem DRM-Zertifikat 810 erhalten, (d.h. S (PR-CERT)), damit sich die signierte Rechte-Kennzeichnung (SRL) 308 ergibt. Wie klar sein sollte, erhält der Benutzer (PR-CERT) aus dem DRM-Zertifikat 810 durch Erhalten von (PU-ENTITY(PR-CERT)) aus einem solchen DRM-Zertifikat 810 und indem (PR-ENTITY) darauf angewendet wird. Es ist jedoch zu beachten, dass der Benutzer nicht verifizieren kann, dass der DRM-Server 320 die Rechte in der übermittelten Rechte-Kennzeichnung durchsetzen kann, insbesondere insofern, als der Benutzer nicht über (PR-DRM) zum Anwenden auf (PU-DRM(DES1)) verfügt. Demzufolge sollte der DRM-Server 320 selbst die Verifizierung zu dem Zeitpunkt durchführen, zu dem eine Lizenz auf Basis der selbst-veröffentlichten SRL 308 angefordert wird.
Sobald der Benutzer die SRL 308 selbst-veröffentlicht, verkettet der Benutzer eine solche selbst-veröffentlichte SRL 308 und das DRM-Zertifikat 810, das verwendet wird, um dieselbe zu erzeugen, mit dem Inhalt, und solcher Inhalt mit SRL 308 und DRM-Zertifikat 810 wird an einen anderen Benutzer verteilt. Danach fordert der andere Benutzer eine Lizenz für den Inhalt von dem DRM-Server 320 in der im Wesentlichen gleichen Weise an, wie in 6A und 6B gezeigt, und erhält sie. Hier übermittelt der lizenzanfordernde Benutzer dem DRM-Server 320 jedoch sowohl die selbst-veröffentlichte SRL 308 als auch das DRM-Zertifikat als mit dem Inhalt verkettet. Der DRM-Server 320 verifiziert dann S (PR-DRM) in dem DRM-Zertifikat 810 auf Basis des entsprechenden (PU-DRM) und erhält (PU-CERT) aus dem DRM-Zertifikat 810. Der DRM-Server 320 verifiziert dann S (PR-CERT) in der SRL 308 auf Basis des erhaltenen (PU-CERT) und fährt wie vorher fort. Es ist jedoch zu beachten, dass, da der Benutzer nicht verifiziert hat, dass der DRM-Server 320 die Rechte in der SRL 308 durchsetzen kann, wie oben dar gelegt wurde, der DRM-Server 320 selbst die Verifizierung zu diesem Zeitpunkt durchführen sollte.
Rechte-Vorlage
Wie oben dargelegt, erhält der Benutzer die Freiheit, die meisten irgendeiner Vielfalt oder Art von Rechte-Daten in einer Rechte-Kennzeichnung zu erstellen durch Definieren von Benutzern oder Klassen von Benutzern, Definieren von Rechten für jeden definierten Benutzer bzw. Klasse von Benutzern und anschließendes Definieren irgendwelcher Verwendungsbedingungen. Allerdings kann es erheblich mühselig und monoton sein, die Rechte-Daten wiederholt für mehrere Rechte-Kennzeichnungen zu definieren, insbesondere, wenn die gleichen Benutzer bzw. Klassen von Benutzern, Rechte und Bedingungen wiederholt für verschiedene Teile des Inhalts definiert werden. Eine solche Situation kann zum Beispiel in einer Unternehmens- oder Büro-Umgebung eintreten, in der ein Benutzer wiederholt verschiedene Teile von Inhalt veröffentlicht, die von einem bestimmten definierten Team von Benutzern gemeinsam genutzt werden sollen. In einer solchen Situation und in einer Ausführungsform der vorliegenden Erfindung wird dann eine Rechte-Vorlage erstellt, die der Benutzer wiederholt in Verbindung mit der Erstellung von Rechte-Kennzeichnungen verwenden kann, wobei die Rechte-Vorlage bereits einen vordefinierten Satz von Benutzern oder Klassen von Benutzern, vordefinierte Rechte für jeden definierten Benutzer bzw. Klasse von Benutzern und vordefinierte Verwendungsbedingungen enthält.
In einer Ausführungsform der vorliegenden Erfindung und unter folgender Bezugnahme auf 9 weist eine Rechte-Vorlage 900 im Wesentlichen die gleichen Rechte-Daten auf, wie sie in einer Rechte-Kennzeichnung vorhanden wären. Da (DES1) jedoch erst bekannt ist, wenn der Inhalt veröffentlicht ist, können die Rechte-Daten gemäß einem solchen (DES1) nicht verschlüsselt werden, wie dies in einer Rechte-Kennzeichnung der Fall ist. In einer Ausführungsform der vorliegenden Erfindung wird die Rechte-Vorlage 900 anschließend mit den nicht-verschlüsselten Rechte-Daten im Verlauf der Verschlüsselung der Rechte-Daten mit (DES1) in Schritt 416 von 4 zum Erzeugen von (DES1(rightsdata)) übermittelt. Natürlich werden die Rechte-Daten von der übermittelten Rechte-Vorlage 900 abgerufen, bevor sie so verschlüsselt werden.
Es kann der Fall sein, oder auch nicht, dass der DRM-Server 320 und dessen öffentlicher Schlüssel (PU-DRM) zu dem Zeitpunkt bekannt sind, zu dem die Rechte-Vorlage erstellt wird. Des Weiteren, selbst wenn sie bekannt sind, kann es sein, oder auch nicht, dass mehr als ein DRM-Server 320 vorhanden ist, von denen jeder seinen eigenen (PU-DRM) hat. Gleichwohl kann in dem Fall, in dem der DRM-Server 320 und dessen öffentlicher Schlüssel (PU-DRM) zu dem Zeitpunkt bekannt sind, zu dem die Rechte-Vorlage erstellt wird, und in dem Fall, in dem nur ein DRM-Server 320 verwendet wird, oder nur ein DRM-Server 320 in Verbindung mit der Rechte-Vorlage 900 verwendet werden soll, eine solche Rechte-Vorlage darin auch Informationen über den DRM-Server enthalten, der eine Rechte-Kennzeichnung signieren soll, die sich aus der Rechte-Vorlage 900 ergibt, einschließlich des öffentlichen Schlüssels (PU-DRM) davon. Obwohl ein solcher (PU-DRM) in der SRL 308 zum Verschlüsseln von (DES1) auftritt, damit sich (PU-DRM(DES1)) ergibt, ist wiederum klar, dass (DES1) erst bekannt ist, wenn der Inhalt veröffentlicht ist, und daher kann (PU-DRM) in der Rechte-Vorlage 900 einen solchen (DES1) nicht verschlüsseln, wie dies in einer Rechte-Kennzeichnung der Fall ist. In einer Ausführungsform der vorliegenden Erfindung wird die Rechte-Vorlage 900 dann mit dem unverschlüsselten (PU-DRM) im Verlauf der Verschlüsselung von (DES1) mit (PU-DRM) in Schritt 414 von 4 übermittelt, um (PU-DRM(DES1)) zu erzeugen. Natürlich wird (PU-DRM) aus der übermittelten Rechte-Vorlage 900 vor der Verwendung abgerufen.
Ebenfalls in dem vorgenannten Fall können andere Informationen über den DRM-Server, die in der Rechte-Vorlage enthalten sein können, Verweis-Informationen enthalten, wie beispielsweise eine URL zum Lokalisieren des DRM-Servers auf einem Netzwerk, und Rückverweis-Informationen, wenn die URL fehlschlägt. In jedem Fall kann die Rechte-Vorlage auch Informationen enthalten, welche unter anderem die Rechte-Vorlage 900 selbst beschreiben. Es ist zu beachten, dass die Rechte-Vorlage 900 auch Platz für Informationen bereitstellen kann, die für den Inhalt relevant sind, der veröffentlicht werden soll, wie beispielsweise Informationen, die in einer Rechte-Kennzeichnung erscheinen, die für den Inhalt und/oder die Verschlüsselungs-Schlüssel (CK) und (DES1) relevant ist, obwohl solcher Platz nicht notwendig ist, wenn eine Instantiierung der Rechte-Vorlage nicht tatsächlich in eine Rechte-Kennzeichnung umgewandelt wird.
Obwohl die Rechte-Vorlage 900, wie bisher offenbart, primär der Annehmlichkeit eines Benutzers dient, sollte auch klar sein, dass unter einigen Umständen ein Benutzer keine uneingeschränkte Freiheit haben sollte, Rechte-Daten in einer Rechte-Kennzeichnung zu definieren, und eine Rechte-Vorlage 900 verwendet werden kann, um den Umfang oder den Typ von Rechte-Kennzeichnungen einzuschränken, die erstellt werden können. Zum Beispiel, und insbesondere in dem Fall einer Unternehmens- oder Büro-Umgebung kann als Richtlinie vordefiniert werden, dass ein bestimmter Benutzer Inhalt immer nur für eine bestimmte Klasse von Benutzern veröffentlichen soll, oder dass der Benutzer Inhalt niemals für eine bestimmte Klasse von Benutzern veröffentlichen soll. In jedem Fall, und in einer Ausführungsform der vorliegenden Erfindung, ist eine solche Richtlinie als vordefinierte Rechte-Daten in einer oder mehreren Rechte-Vorlagen 900 eingebettet, und der Benutzer kann darauf beschränkt werden, solche Rechte-Vorlagen zum Erstellen von Rechte-Kennzeichnungen zu verwenden, wenn Inhalt veröffentlicht wird. Insbesondere kann eine Rechte-Vorlage oder eine Gruppe von Rechte-Vorlagen, die einem Benutzer zur Verfügung gestellt wird, um eine Veröffentlichungs-Richtlinie für den Benutzer zu spezifizieren, jeden bestimmten Typ von Veröffentlichungs-Richtlinie spezifizieren, ohne von dem Gedanken und Umfang der vorliegenden Erfindung abzuweichen.
Zum Spezifizieren einer Rechte-Vorlage 900 für einen eingeschränkten Benutzer oder dergleichen und unter folgender Bezugnahme auf 10 erstellt ein Administrator oder dergleichen tatsächlich die Rechte-Vorlage 900 durch Definieren der vordefinierten Rechte-Daten (Schritt 1001) und Definieren irgendwelcher anderen Daten, die notwendig und sachdienlich sein können, wie beispielsweise Informationen, die für einen bestimmten DRM-Server 320 (Schritt 1003) relevant sein können. Bezeichnenderweise muss die Rechte-Vorlage 900, um die Rechte-Vorlage für die Verwendung durch den eingeschränkten Benutzer oder dergleichen auszuführen, offiziell gemacht werden. Das heißt, die Rechte-Vorlage 900 muss als eine Rechte-Vorlage erkennbar sein, die der eingeschränkte Benutzer oder dergleichen verwenden kann. Dementsprechend wird in einer Ausführungsform der vorliegenden Erfindung die Rechte-Vorlage, wie sie durch den Administrator oder dergleichen erstellt worden ist, dem DRM-Server 320 zum Signieren übermittelt, wobei ein solches Signieren die Rechte-Vorlage offiziell macht (Schritt 1005).
Es ist zu beachten, dass der signierende DRM-Server 320 der DRM-Server 320 ist, dessen Informationen sich in der Rechte-Vorlage 900 befinden, sofern solche Informationen tatsächlich in der Rechte-Vorlage 900 vorhanden sind. Es ist auch zu beachten, dass der DRM-Server 320 die Rechte-Vorlage nur nach Durchführung aller notwendigen Prüfungen signieren kann oder sie ohne irgendwelchen Prüfungen signieren kann. Schließlich ist zu beachten, dass die Vorlagen-Signatur S (PR-DRM-T), (wobei das -T bedeutet, dass die Signatur für die ORT 900 ist), von dem DRM-Server wenigstens auf den vordefinierten Rechte-Daten in der Rechte-Vorlage 900 basieren sollte, aber auch auf anderen Informationen basieren kann, ohne von dem Gedanken und Umfang der vorliegenden Erfindung abzuweichen. Wie im Folgenden dargelegt, wird die Signatur S (PR-DRM-T) in eine Rechte-Kennzeichnung integriert und in Verbindung mit dieser verifiziert, und dementsprechend sollte, worauf auch immer die Signatur basiert, ebenfalls in die Rechte-Kennzeichnung in einer unveränderten Form integriert werden.
Nachdem der DRM-Server 320 die Rechte-Vorlage 900 signiert hat und dieselbe an den Administrator oder dergleichen zurückgegeben hat, empfängt der Administrator die signierte und jetzt offizielle Rechte-Vorlage 900 mit S (PR-DRM-T) (Schritt 1007) und leitet die offizielle Rechte-Vorlage (ORT) 900 an einen oder mehrere Benutzer zu ihrer Verwendung weiter (Schritt 1009). Dementsprechend ruft für einen Benutzer, der Inhalt auf Basis einer ORT 900 veröffentlichen soll, der Benutzer die ORT 900 ab (Schritt 1011) und erstellt eine Rechte-Kennzeichnung auf Basis der ORT 900 (Schritt 1013), indem alle notwendigen Informationen bereitgestellt werden, wie beispielsweise Informationen über den Inhalt, zweckdienliche Schlüssel-Informationen, die Rechte-Daten aus der mit (DES1) verschlüsselten ORT 900, damit sich (DES1(rightsdata)) ergibt, und andere Informationen aus der ORT 900. Bezeichnenderweise nimmt der Benutzer mit der Rechte-Kennzeichnung auch die Signatur S (PR-DRM-T) aus der ORT 900 auf.
Danach, und wie vorher, übermittelt der Benutzer die Rechte-Kennzeichnung dem DRM-Server 320 zum Signieren (Schritt 1015). Hier signiert der DRM-Server 320 die übermittelte Rechte-Kennzeichnung jedoch erst, wenn S (PR-DRM-T) verifiziert ist. Das heißt, der DRM-Server 320 setzt durch, dass der Benutzer die übermittelte Rechte-Kennzeichnung auf eine ORT 900 basieren muss, indem er es ablehnt, die übermittelte Rechte-Kennzeichnung zu signieren, wenn eine solche übermittelte Rechte-Kennzeichnung keine Signatur S (PR-DRM-T) von einer ORT 900 enthält. Insbesondere ruft der DRM-Server 320 eine solche S (PR-DRM-T) und welche Informationen auch immer, auf denen eine solche Signatur basiert, aus der übermittelten Rechte-Kennzeichnung ab und verifiziert eine solche Signatur dann auf Basis des (PU-DRM). Es ist zu beachten, dass die Rechte-Daten in der übermittelten Rechte-Kennzeichnung gemäß (DES1) verschlüsselt sind, (d.h. (DES1(rightsdata))). Dementsprechend muss der DRM-Server 320 zuerst (DES1) erhalten und (DES1(rightsdata)) damit entschlüsseln, wie oben in Verbindung mit 7 dargelegt, um in der Lage zu sein, die Signatur auf Basis der Rechte-Daten in der übermittelten Rechte-Kennzeichnung zu verifizieren.
Sobald sie verifiziert ist, signiert der DRM-Server 320 die übermittelte Rechte-Kennzeichnung mit S (PR-DR;-L), um wie vorher eine SRL 308 zu erzeugen. (wobei das -L bedeutet, dass die Signatur für die SRL 308 ist). Hier kann S (PR-DRM-L) die S (PR-DRM-T) ersetzen oder zusätzlich zu einer solchen S (PR-DRM-T) vorhanden sein. Falls zusätzlich, kann S (PR-DRM-L) teilweise auf S (PR-DRM-T) basieren. Es ist zu beachten, dass (PR-DRM) verwendet werden kann, um sowohl S (PR-DRM-T) als auch S (PR-DRM-L) zu erzeugen, oder dass verschiedene (PR-DRM)s für jede S (PR-DRM-T) und S (PR-DRM-L) verwendet werden können. Nachdem der DRM-Server 320 die Rechte-Kennzeichnung signiert und die SRL 308 an den Benutzer zurückgegeben hat, empfängt der Benutzer die SRL 308 mit S (PR-DRM-L) (Schritt 1017) und fährt damit fort, dieselbe wie vorher mit dem Inhalt zu verketten, der veröffentlicht wird.
Wenn die Signatur S (PR-DRM-T) der ORT 900 wenigstens teilweise auf den vordefinierten Rechte-Daten in der ORT 900 basiert, dann können solche Rechte-Daten, wie sie in der SRL 308 in (DES1(rightsdata)) erscheinen, weder modifiziert noch geändert werden. Andernfalls wird S (PR-DRM-T) nicht verifiziert. Allerdings können die Rechte-Daten in der ORT 900 in einer Ausführungsform der vorliegenden Erfindung innerhalb vorgeschriebener Regeln variieren, die auch in der ORT 900 enthalten sind. Zum Beispiel können die Regeln spezifizieren, dass einer von zwei Sätzen von Rechte-Daten in eine SRL 308 aufgenommen werden soll, oder sie können eine Auswahl aus einem Satz von Alternativen gestatten. Wie klar sein dürfte, können die Regeln jeder bestimmte Regel-Satz sein, der in jeder zweckdienlichen Syntax dargelegt ist, ohne vom Gedanken und Umfang der vorliegenden Erfindung abzuweichen. Hier werden die Regeln von einem entsprechenden Regel-Interpretierer für den Benutzer zu dem Zeitpunkt interpretiert, zu dem die Rechte-Kennzeichnung erstellt wird. Obwohl die Rechte-Daten variieren können, variieren die Regeln nicht gleichermaßen, und dementsprechend basiert die Vorlagen-Signatur S (PR-DRM-T) für die ORT 900 wenigstens teilweise auf den Regeln und nicht auf den Rechte-Daten selbst. Als Ergebnis dessen müssen die in der ORT 900 enthaltenen Regeln auch in der SRL 308 enthalten sein.
In einer Ausführungsform der vorliegenden Erfindung sind die vordefinierten Rechte-Daten in der ORT 900 teilweise festgelegt und unveränderlich und teilweise veränderlich und regelgesteuert, wie oben dargelegt. Hier basiert die Vorlagen-Signatur S (PR-DRM-T) für die ORT 900 wenigstens teilweise auf dem festgelegten Teil der Regeln und auf den Regeln für den veränderlichen Teil der Rechte-Daten.
Wie klar sein dürfte, kann eine ORT 900, wenn sie im Besitz eines Benutzers ist, veralten oder ablaufen. Das heißt, die ORT 900 kann durch die Rechte-Daten darin eine Richtlinie wiedergeben, die veraltet, irrelevant oder einfach nicht mehr anwendbar ist. Zum Beispiel kann es sein, dass einer oder mehrere Benutzer oder Klassen von Benutzern, die in den Rechte-Daten der ORT 900 spezifiziert sind, nicht mehr in der Richtlinien-Umgebung vorhanden sind, oder dass ein bestimmter Benutzer oder eine Klasse von Benutzern, die in den Rechte-Daten der ORT 900 spezifiziert sind, nicht mehr die gleichen Rechte innerhalb der Richtlinien-Umgebung besitzen. In einem solchen Fall kann es sein, dass der Administrator eine überarbeitete ORT 900 ausgegeben hat, der Benutzer aber immer noch eine vorherige, abgelaufene Version der ORT 900 verwendet.
In einer solchen Situation und in einer Ausführungsform der vorliegenden Erfindung behält der DRM-Server 320 nach dem Signieren einer übermittelten Rechte-Vorlage 900 zum Erstellen einer ORT 900 dann eine Kopie der ORT 900 zurück, jede ORT 900 weist eindeutige Identifizierungs-Daten auf, und jede Rechte-Kennzeichnung, die auf Basis einer ORT 900 erstellt worden ist, enthält darin die Identifizierungs-Daten einer solchen ORT 900. Dementsprechend findet der DRM-Server nach Empfang einer übermittelten Rechte-Kennzeichnung, wie beispielsweise in Verbindung mit 10, die Identifizierung-Daten der OR T900 in der Rechte-Kennzeichnung, ruft die aktuelle Kopie einer solchen ORT 900 auf Basis der gefundenen Identifizierungs-Daten ab, entfernt die Rechte-Daten aus der übermittelten Rechte-Kennzeichnung, fügt die Rechte-Daten aus der abgerufenen ORT 900 ein und signiert dann die Rechte-Kennzeichnung, die wenigstens teilweise auf den eingefügten Rechte-Daten basiert. Natürlich führt der DRM-Server auch alle Verschlüsselungs- und Entschlüsselungs-Schritte durch, die notwendig sind und in dem dargelegten Prozess anfallen, einschließlich Entschlüsseln und erneutes Verschlüsseln von (DES1(rightsdata)). Es ist zu beachten, dass, wenn der DRM-Server so ausgelegt ist, dass er die Rechte-Daten in einer übermittelten Rechte-Kennzeichnung ersetzt, eine solche Rechte-Kennzeichnung und die ORT 900, aus welcher eine solche Rechte-Kennzeichnung erstellt wird, die Rechte-Daten nicht unbedingt darin enthalten muss. Stattdessen müssen die Rechte-Daten nur auf dem DRM-Server 320 resident sein. Allerdings könnte das Aufnehmen der Rechte-Daten in die Rechte-Kennzeichnung und die ORT 900, aus der eine solche Rechte-Kennzeichnung erstellt wird, für den Benutzer wertvoll und daher in einigen Situationen von Nutzen sein.
Plug-in-Architektur für DRM-Pipelines.
Ein typischer DRM-Server und eine Dienst-Plattform gemäß der Erfindung können einen oder mehrere DRM-Dienste höherer Ebene umfassen, wie beispielsweise Lizenzierung, Veröffentlichung, Registrierung, Aktivierung, Zertifizierung, Föderierung und dergleichen. Gemäß der Erfindung können die entsprechenden Software-Systeme, die jeden dieser Dienst bereitstellen, als "Pipelines" bereitgestellt werden, die modular aufgebaut sind, so dass sie individuell in jeder Kombination installiert werden können und dann verwaltet, aktiviert oder deaktiviert, authentifiziert werden können oder ihre Authentifizierung aufgehoben werden kann usw. Jeder der DRM-Dienste kann als eine Pipeline bezeichnet werden wegen der Art, wie sie Anforderungen von Anfang bis Ende mit verschiedenen Verarbeitungsstufen während des Verlaufs verarbeiten.
Die Pipelines arbeiten zusammen, um eine umfangreiche DRM-Plattform zu bieten, und jede stellt für sich einen wichtigen DRM-Dienst bereit. Zusätzlich werden bestimmte Komponenten der DRM-Plattform, welche die Geschäftslogik einkapseln, (was für einen erfolgreichen DRM-Server und eine erfolgreiche Dienst-Implementierung wichtig sein kann), über die DRM-Suite übergreifend genutzt und sind von Dritten "steckbar". Eine solche Implementierung weist die Flexibilität auf, dass sowohl Dienst-Lösungen schnell entwickelt werden können als auch Kunden die Möglichkeit geboten werden kann, Software für ihre DRM-Bedürfnisse spezifisch zu gestalten.
Vorzugsweise werden der Microsoft Internet Information Server ("IIS") und das ASP.net-Modell für Schreibdienste verwendet. IIS ist dafür ausgelegt, Sicherheit für Unterneh mens-Intranets und das Internet zu bieten. Außerdem stellt IIS eine Implementierung des Secure Sockets Layer- (SSL) Protokolls für sichere Kommunikation und Authentifizierung mit X.509-Zertifikaten, RSA Public Key Cipher und eine umfangreiche Bandbreite von zusätzlichen Sicherheitsmerkmalen bereit. ASP.net ist ein Programmier-Rahmen, der die schnelle Entwicklung von leistungsstarken Web-Anwendungen und Diensten ermöglicht. Es ist Teil der .NET-Plattform von Microsoft und ist eine leichte, skalierbare Möglichkeit zum Aufbauen, Einsetzen und Ausführen von Web-Anwendungen, die jeden Browser bzw. jede Vorrichtung ansteuern können.
In einer bevorzugten Ausführungsform der Erfindung wird eine HTTP-Anforderung mit starrer Typenhandhabung (strong typing) an einen Web-Server gesendet, der IIS, ASP.net und einen oder mehrere DRM-Dienste ausführt. Die HTTP-Anforderung wird dann von IIS und ASP.net vorverarbeitet und zu dem entsprechenden DRM-Dienst geleitet. Sobald die Anforderung an dem DRM-Dienstcode ankommt, gelangt sie in eine der Verarbeitungs-Pipelines. Jede Pipeline wird auf der höchsten Ebene durch eine ASP.net-Datei (eine ASMX-Datei) definiert, die selbst den Eingangspunkt des Diensts und den Code, der Anforderungen an diesen Eingangspunkt bearbeitet, beschreibt. Für jede Pipeline befindet sich der DRM-Dienstcode hinter dem Eingangspunkt, und die Kombination aus der ASMX-Datei und dem Code dahinter bilden die Pipeline.
Der Code hinter dem Eingangspunkt ist modular und kann Code gemeinsam mit anderen Pipelines nutzen. Er kann umfassen: 1) anforderungsspezifischen Startcode, der die Anforderungsparameter vorverarbeitet, wobei jede erforderliche Normalisierung der Daten durchgeführt wird, und allgemeine Pipeline-Anforderungsstart-Operationen durchgeführt werden; 2) Code, der Aktionen durchführt, die für die Verarbeitung der Anforderung spezifisch sind, (und für die Pipeline spezifisch sind); 3) Code, der gemeinsam genutzte interne Komponenten aufruft, (die Pipeline-übergreifend gemeinsam genutzt werden und nur für die DRM-Plattform zugänglich sind), und gemeinsam genutzte öffentliche Komponenten, (die Pipeline-übergreifend gemeinsam genutzt werden und von Dritten steckbar sind); und 4) Anforderungs-Abschlusscode, der die Ergebnisse aufnimmt, die von der Pipeline generiert werden, und eine für die Anforderung geeignete Antwort formuliert.
Als ein Ergebnis dieser Pipeline-Auslegung können DRM-Dienste leicht in jeder Permutation eingesetzt werden. Zum Beispiel können Lizenzierungs- und Föderations-Dienste in einer bestimmten Installation installiert werden, und die Veröffentlichungs- und Informations-Dienste können deaktiviert werden. In einem anderen Beispiel kann nur die Lizenzierung oder nur Veröffentlichungs-Dienste mit der Durchsetzung strikter Authentifizierungsanforderungen an den Veröffentlichungs-Dienst installiert werden, indem sie auf die Eingangspunkt-ASMX-Datei angewendet werden. Eine solche Pipeline-Auslegung berücksichtigt auch die effiziente Einführung neuer künftiger Dienste, ohne die bestehenden DRM-Dienste zu beeinträchtigen, jedoch unter Nutzung von bestehender Infrastruktur.
Innerhalb jeder Pipeline wird eine Reihe von Pipeline-Stufen ausgeführt, von denen einige nur interne DRM-Komponenten aufrufen und einige von ihnen öffentliche, steckbare DRM-Komponenten ("Plug-Ins") aufrufen. Als ein Ergebnis dieser DRM-Plug-In-Auslegung können Dritte kundenspezifische Komponenten schreiben oder erhalten, die einen Teil des gesamten DRM-Pipeline-Prozesses durchführen. Vorzugsweise werden Maßnahmen ergriffen, um sicherzustellen, dass jeder solche Dritte ein verlässlicher Dritter ist, bevor die Plug-Ins des Dritten in den Pipeline-Rahmen integriert werden. Standardmäßige öffentliche Techniken, die vom .NET-Rahmen bereitgestellt werden, können zur Sicherstellung dessen verwendet werden, dass das Plug-In von Dritten verlässlich ist. Plug-Ins von Dritten können dynamisch installiert werden. Solche Plug-Ins von Dritten können zum Beispiel in den Konfigurationsdaten des DRM-Systems identifiziert und zur Laufzeit geladen werden. Eine solche Auslegung sorgt für einfache Verwendung und Administration des DRM-Systems.
Im Allgemeinen führt ein Plug-In eine diskrete Aufgabe durch, wie beispielsweise Abrufen einer Rechte-Kennzeichnung aus dem Speicher, Generieren eines Distributionspunkt-XML-Knotens auf Basis von Konfigurationsdaten, Durchführen von Operationen mit privaten Schlüsseln unter Verwendung von kundenspezifischer Verschlüsselungs-/Entschlüsselungs-Hardware usw. Gewisse spezialisierte Plug-Ins werden hierin als "Erweiterungen" bezeichnet. Erweiterungen werden aufgerufen, wenn allgemeine Ereignisse eintreten, wie beispielsweise, wann es Zeit ist, eine Anforderung zu genehmigen, wenn eine Lizenz generiert worden ist usw. Plug-Ins sind in der Pipeline-Verarbeitung aktiver, indem sie eine wesentliche, erforderliche Aufgabe in der Pipeline durchführen.
Erweiterungen sind passiver, indem sie auf Ereignisse reagieren und eventuell Arbeit durchführen oder möglicherweise nichts tun.
11 stellt eine generische Pipeline 1100 gemäß der Erfindung dar. Die Pipeline 1100 enthält ein Dienstprogramm 1102, das einen Verarbeitungsrahmen zum Durchführen eines digitalen Rechteverwaltungs-Diensts bereitstellt, wie beispielsweise Veröffentlichung, Lizenzierung usw. Die Pipeline 1100 enthält eine Vielzahl von Plug-In-Komponenten 1120a, 1120b. Jede Plug-In-Komponente 1120a, 1120b führt eine entsprechende Aufgabe durch, die mit dem digitalen Rechteverwaltungs-Dienst verknüpft ist. Die Typen von Aufgaben, die eine Plug-In-Komponente in einer digitalen Rechteverwaltungs-Pipeline durchführen kann, werden ausführlich durchgehend in dieser Spezifikation beschrieben. Jede der Vielzahl von Plug-In-Komponenten 1120a, 1120b ist in den Verarbeitungsrahmen 1102 gemäß einem entsprechenden vordefinierten Satz von Schnittstellen-Regeln integriert. Typischerweise werden diese Schnittstellen-Regeln zwischen dem Anbieter des Dienstprogramm-Verarbeitungsrahmens und dem Anbieter des Plug-In verhandelt, (welcher, wie oben beschrieben, die gleiche Entität sein kann oder nicht). Eine Pipeline 1100 kann auch eine oder mehrere Erweiterungen 1130 enthalten.
An einem Punkt 1140 entlang der Pipeline sind alle die Aufgaben abgeschlossen, die notwendig sind, um den Dienst durchzuführen, (z.B. die Anforderung verarbeiten). Nach dem Punkt 1140 können asynchrone Komponenten in den Verarbeitungsrahmen 1110 integriert werden. Primär können asynchrone Komponenten für Aufgaben verwendet werden, die für die Durchführung des Diensts nicht notwendig sind. Somit stellen die asynchronen Komponenten ein bandexternes Erweiterbarkeitsmodell für Aufgaben bereit, die während der Verarbeitung der Pipeline nicht durchgeführt werden müssen. Da sie verarbeitet werden, nachdem die erforderlichen Dienst-Aufgaben abgeschlossen worden sind, behindern asynchrone Komponenten die Verarbeitung einer Anforderung nicht. Vorzugsweise besitzen asynchrone Komponenten kein Vetorecht. Jede Anzahl von asynchronen Komponenten kann parallel verarbeitet werden.
Wegen dieser offenen Plattform ist es wünschenswert, Maßnahmen zum Schutz von Daten und Schnittstellen zu ergreifen. Zum Beispiel könnte es erforderlich sein, dass die Plug-Ins, die innerhalb der Umgebung der Pipeline arbeiten, verlässlich sind. Dies kann auf vielerlei Arten erfolgen. Zum Beispiel können starre Benennung und nachweisbasier te Code-Techniken mit verwalteter Sicherheit (evidence-based security managed code techniques) zwischen dem Dienstprogramm und seinen Plug-In-Komponenten verwendet werden, um die Komponente zu validieren und sicherzustellen, dass das Plug-In für das Dienst-Programm verlässlich ist, und dass das Dienst-Programm für das Plug-In verlässlich ist. Des Weiteren können Daten, die das Dienst-Programm für die Plug-Ins bereitstellt, und Daten, die das Dienst-Programm von diesen zurück akzeptiert, sorgfältig kontrolliert werden. Zum Beispiel wird in einer bevorzugten Ausführungsform den Plug-Ins ein direkter Zugang zu den Datenstrukturen des Dienst-Programms verweigert. Stattdessen werden in die Plug-Ins eingehende und von diesen ausgehende Daten repliziert.
12 stellt eine bevorzugte Ausführungsform einer Veröffentlichungs-Pipeline 1200 gemäß der Erfindung dar. Wie gezeigt, kann die Veröffentlichungs-Pipeline 1200 ein Dienst-Programm enthalten, wie beispielsweise ein Veröffentlichungs-Anforderungsprogramm, das einen Verarbeitungsrahmen zum Verarbeiten einer Anforderung bereitstellt, rechteverwalteten digitalen Inhalt zu veröffentlichen. Die Veröffentlichungs-Pipeline 1200 kann auch eine Vielzahl von Plug-In-Komponenten enthalten, von denen jede eine entsprechende Aufgabe durchführt, die mit der Verarbeitung der Veröffentlichungs-Anforderung verknüpft ist. Jede der Vielzahl von Plug-In-Komponenten ist in den Verarbeitungsrahmen gemäß einem entsprechenden vordefinierten Satz von Schnittstellen-Regeln integriert. Jede der beispielhaften Plug-In-Komponenten wird im Folgenden im Detail beschrieben.
Ein "Authentifizierungs"-Plug-In 1220a kann bereitgestellt werden, um die Identität der Entität zu bestimmen, welche die Lizenz anfordert. Somit kann der Anbieter des Authentifizierungs-Plug-In 1220a kontrollieren, ob eine Authentifizierung erforderlich ist, und falls ja, kann der Anbieter den Typ der Authentifizierung, das Authentifizierungsschema, ob eine anonyme Authentifizierung zulässig ist, und den Fehlertyp kontrollieren, der gemeldet wird, wenn die Anforderung aus irgendeinem Grund nicht authentifiziert werden kann.
Ein "Authentifizierungs"-Plug-In 1220b kann bereitgestellt werden, um die authentifizierte Identität zu genehmigen. Im Allgemeinen kann ein Authentifizierungs-Plug-In verwendet werden, um zu bestimmen, ob es einer anfordernden Entität gestattet ist, das auszu führen, was immer die anfordernde Entität angefordert hat. Zum Beispiel kann ein Authentifizierungs-Plug-In in einer Veröffentlichungs-Pipeline verwendet werden, um zu bestimmen, ob es der authentifizierten Identität gestattet ist, rechteverwalteten Inhalt unter Verwendung des DRM-Systems zu veröffentlichen. Somit kann der Anbieter des Authentifizierungs-Plug-In kontrollieren, welche Entitäten welche Aktionen anfordern können, welche Liste von Entitäten gespeichert ist, wie und wo eine solche Liste gespeichert ist, wie genehmigte Entitäten in die Liste und aus der Liste gelangen und dergleichen.
Eine "Rechte-Kennzeichnungs-Speicher"-Plug-In 1220c kann verwendet werden, um eine Haupt-Rechte-Kennzeichnung zu speichern, die in Übereinstimmung mit der Erfindung generiert worden ist. Wie vorher ausführlich beschrieben, kann eine Haupt-Rechte-Kennzeichnung mit einer Kennung verknüpft sein, wie beispielsweise einer GUID. Zum Lizenzierungs-Zeitpunkt ruft der Server eine Kopie der Haupt-Rechte-Kennzeichnung aus dem Speicher auf Basis der GUID ab. Der Anbieter eines "Rechte-Kennzeichnungs-Speicher"-Plug-In 1220c kann die Speicherstellen, an denen die Haupt-Rechte-Kennzeichnung gespeichert werden soll, und die zum Speichern der Rechte-Kennzeichnung verwendeten Speichertechniken definieren.
Ein "Privat-Schlüssel"-Plug-In 1220d kann verwendet werden, um den privaten Haupt-Schlüssel zu schützen. Somit kann der Anbieter eines Privat-Schlüssel-Plug-In 1220d den Schutzalgorithmus für den privaten Schlüssel spezifizieren, den das System verwenden wird. Eine Anzahl von Schutzalgorithmen für den privaten Schlüssel, die zur Verwendung in einem DRM-System gemäß der Erfindung geeignet sind, sind in der U.S.-Patentanmeldung Nr. (Aktenzeichen MSFT-1334) beschrieben.
Am Abschlusspunkt 1240, wie in 12 gezeigt, wird die Veröffentlichungs-Anforderung abgeschlossen, und die asynchronen Komponenten 1250 beginnen, ihre jeweiligen Aufgaben durchzuführen. Wie gezeigt, kann die Veröffentlichungs-Pipeline 1200 auch eine "Property Bag"-Komponente 1250a, eine "Protokollierungs"-Anwendung 1250b und ein Zertifikatmaschinen-Plug-In 1250c enthalten. Es sollte jedoch klar sein, dass eine Veröffentlichungs-Pipeline gemäß der Erfindung jede Anzahl von Plug-Ins enthalten kann, einschließlich jeder Anzahl von Erweiterungen oder asynchronen Komponenten.
Ein "Property Bag" 1250a ist eine Ressource, die Plug-Ins während der Ausführungszeit zur Verfügung steht und Anforderungskontext-Informationen aufweist. Der Anbieter der Property Bag kann damit kontrollieren, welche Daten in die Property Bag eingegeben werden, für wen die Property Bag verfügbar gemacht wird, und unter welchen Umständen die Property Bag verfügbar gemacht werden kann.
Eine "Protokollierungs"-Anwendung 1250b kann verwendet werden, um Daten zu archivieren, die mit der Veröffentlichungs-Anforderung in Verbindung stehen. Der Anbieter der Protokollierungs-Komponente kann damit kontrollieren, welche Daten archiviert werden, wo die Daten archiviert werden, und in welchem Format die Daten archiviert werden.
Ein "Zertifikatmaschinen"-Plug-In 1250c ist ein asynchrones Plug-In, das Zertifikate, (z.B. ein Lizenz-Zertifikat), schreibt. Die Zertifikatmaschine weiß, wie die Grammatik der verwendeten Rechte-Sprache, (z.B. XrML), zu handhaben ist. Der Anbieter des Zertifikatmaschinen-Plug-In kann damit das Format und den Inhalt der Zertifikate, die verwendete Rechte-Sprache usw. kontrollieren.
13 stellt eine bevorzugte Ausführungsform einer Lizenzierungs-Pipeline 1300 gemäß der Erfindung dar. Wie gezeigt, kann die Lizenzierungs-Pipeline 1300 ein Dienst-Programm, wie beispielsweise ein Lizenz-Anforderungsprogramm umfassen, das einen Verarbeitungsrahmen zum Verarbeiten einer Lizenzanforderung bereitstellt. Die Lizenzierungs-Pipeline 1300 kann auch eine Vielzahl von Plug-In-Komponenten enthalten, von denen jede eine entsprechende Aufgabe durchführt, die mit der Verarbeitung der Lizenzanforderung verknüpft ist. Jede der Vielzahl von Plug-In-Komponenten ist in den Verarbeitungsrahmen des Lizenzierungs-Anforderungsprogramms gemäß einem entsprechenden vordefinierten Satz von Schnittstellen-Regeln integriert. Jede der beispielhaften Plug-In-Komponenten wird im Folgenden im Detail beschrieben. Es ist zu beachten, dass in einer bevorzugten Ausführungsform eines DRM-Systems gemäß der Erfindung Plug-Ins zwischen verschiedenen Pipelines/Web-Diensten gemeinsam genutzt werden können, und dass viele der Plug-Ins, die in einer Lizenzierungs-Pipeline enthalten sein können, mit denjenigen identisch sein können, die in der oben beschriebenen Veröffentlichungs-Pipeline enthalten sind.
Ein "Authentifizierungs"-Plug-In 1320a, wie oben in Verbindung mit der Veröffentlichungs-Pipeline beschreiben, kann bereitgestellt werden, um die Identität der Entität zu bestimmen, welche die Lizenz anfordert.
Ein "Genehmigungs"-Plug-In 1320b, wie oben in Verbindung mit der Veröffentlichungs-Pipeline beschrieben, kann bereitgestellt werden, um die authentifizierte Identität zu genehmigen. In einer Lizenzierungs-Pipeline kann ein Genehmigungs-Plug-In verwendet werden, um zu bestimmen, ob es der anfordernden Entität gestattet ist, eine Lizenz anzufordern. Somit kann der Anbieter des Genehmigungs-Plug-In kontrollieren, es ob einer persönlichen Account-Identität gestattet ist, eine direkte Lizenzanforderung vorzunehmen, ob ein verlässlicher Server-Prozess eine Lizenzanforderung für eine solche Entität vornehmen kann und dergleichen.
Ein "Gruppenerweiterungs"-Plug-In 1320c kann verwendet werden, um eine individuelle Benutzerliste aus einer Gruppenkennung abzurufen. Im Allgemeinen geht man davon aus, dass sich die Mitgliedschaft in einer vordefinierten Gruppe mit der Zeit ändert. Demzufolge kann ein DRM-System gemäß der Erfindung ein Gruppen-Repository umfassen, das entsprechende Benutzerlisten für jede von einer Anzahl von Gruppen enthält. Jede Gruppe weist eine damit verknüpfte Gruppenkennung auf. Sobald daher eine Gruppenkennung während der Verarbeitung eines digitalen Rechteverwaltungs-Diensts, (z.B. Veröffentlichung), empfangen wird, kann das Gruppenerweiterungs-Plug-In aufgerufen werden, um die aktuelle Gruppenliste abzurufen, die der empfangenen Gruppenkennung entspricht.
Ein "Rechte-Kennzeichnungs-Abruf"-Plug-In 1320d kann verwendet werden, um eine Rechte-Kennzeichnung abzurufen, die einer empfangenen Kennung entspricht. Wie vorher im Detail beschrieben, analysiert der Server die Rechte-Kennzeichnung, die in der Lizenzanforderung eingegeben ist, um ihre GUID abzurufen. Dann übergibt er diese GUID an das Rechte-Kennzeichnungs-Abruf-Plug-In 1320d, welches eine Abfrage über die Datenbank ausgibt, um eine Kopie der Haupt-Rechte-Kennzeichnung abzurufen.
Ein "Zertifikat-Abruf"-Plug-In kann verwendet werden, um ein Zertifikat von einem Server abzurufen, auf welchem solche Zertifikate gespeichert sind. Zum Beispiel kann eine anfordernde Entität eine Vor-Lizenzierung für eine Anzahl von potenziellen Lizenznehmern anfordern, doch hat die anfordernde Entität nicht die Zertifikate für die potenziellen Lizenznehmer. Die Zertifikate werden jedoch benötigt, um die Lizenz auszugeben, weshalb das Zertifikat-Abruf-Plug-In verwendet werden kann, um Zertifikate von dem Server abzurufen, auf dem sie gespeichert sind.
Ein "Speicher"-Plug-In kann verwendet werden, um jeden beliebigen bereitgestellten Speicherzugang einzukapseln. Somit kann der Anbieter eines Speicher-Plug-In die Speicher spezifizieren, in denen Daten gespeichert werden können oder aus denen Daten abgerufen werden können sowie die "Sprache", welche die Pipeline benötigt, um mit dem bzw. den Datenspeichern zu kommunizieren. Zum Beispiel wäre es möglich, dass eine Pipeline auf einen bestimmten Datenspeicher über SQL zugreifen muss.
Ein "Distributionspunkt"-Plug-In 1320g kann in Verbindung mit Superdistribution der Verweis-URL verwendet werden. Das Distributionspunkt-Plug-In 1320g liest Verweis-URLs aus einem Speicherplatz aus und integriert sie auf Anfrage in XrML-Dokumente. Die Ausgabe von diesem Plug-In ist ein gut definierter XML-Teil, der die Verweis-URL definiert, mit der ein Client Kontakt aufnehmen kann, um eine DRM-Operation vorzunehmen, wie beispielsweise Lizenzierung, Rechte-Erwerb usw.
Ein "Privat-Schlüssel"-Plug-In 1320h, wie vorher in Verbindung mit der Veröffentlichungs-Pipeline beschrieben, kann zum Schutz des Haupt-Privat-Schlüssels verwendet werden.
Am Abschlusspunkt 1340, wie in 13 gezeigt, wird die Lizenzanforderungs-Verarbeitung abgeschlossen, und die asynchronen Plug-Ins 1350 beginnen, ihre jeweiligen Aufgaben durchzuführen. Wie gezeigt, kann die Lizenzierungs-Pipeline 1300 auch eine "Property Bag"-Komponente 1350a, eine "Protokollierungs"-Anwendung 1350b und ein Zertifikatmaschinen-Plug-In 1350c enthalten, wie vorher in Verbindung mit der Veröffentlichungs-Pipeline beschrieben. Es sollte jedoch klar sein, dass eine Lizenzierungs-Pipeline gemäß der Erfindung jede Anzahl von Plug-Ins enthalten kann, einschließlich jeder Anzahl von Erweiterungen oder asynchronen Komponenten.
14 stellt ein Ablaufprogramm einer bevorzugten Ausführungsform eines Verfahrens 1400 gemäß der Erfindung zum Bereitstellen einer sicheren Server-Plug-In-Architektur für digitale Rechteverwaltungssysteme bereit. In Schritt 1402 stellt der Systemanbieter ein Dienst-Programm bereit, das einen Verarbeitungsrahmen zum Durchführen eines digitalen Rechteverwaltungs-Diensts bereitstellt, wie beispielsweise Veröffentlichung, Lizenzierung usw. In einer bevorzugten Ausführungsform umfasst das Dienst-Programm Code zum Durchführen des verknüpften DRM-Diensts.
In Schritt 1404 stellt der Systemanbieter eine Vielzahl von DRM-Plug-In-Optionen bereit, von denen jede mit einer entsprechenden Plug-In-Komponente verknüpft ist, die eine entsprechende Aufgabe durchführt, die mit dem digitalen Rechteverwaltungs-Dienst verknüpft ist. Der Installierer, Käufer, Systemadministrator oder sonstige Benutzer des Systems kann dann aus der Vielzahl von Plug-In-Optionen auswählen, um diejenigen Plug-Ins auszuwählen, welche die spezifische Funktionalität bereitstellen, die der Verbraucher für diese Pipeline für diese Installation wünscht.
In Schritt 1406 empfängt der Systemanbieter die Plug-In-Auswahlen und integriert in Schritt 1408 die Plug-In-Komponenten in den Verarbeitungsrahmen, die den ausgewählten Plug-In-Optionen entsprechen. Somit kann ein Benutzer eines DRM-Systems gemäß der Erfindung das System nach den Bedürfnissen oder Wünschen des Benutzers gestalten und das System wirtschaftlich, einfach und effizient aufrüsten, indem Plug-Ins gewechselt werden.
Schlussfolgerung
Die Programmierung, die notwendig ist, um die Prozesse auszuführen, die in Verbindung mit der vorliegenden Erfindung durchgeführt werden, ist relativ unkompliziert und sollte für die relevanten Programmierer offenkundig sein. Demzufolge befindet sich eine solche Programmierung nicht im Anhang hierzu. Jede bestimmte Programmierung kann dann verwendet werden, um die vorliegende Erfindung auszuführen, ohne von ihrem Gedanken und Umfang abzuweichen.
Somit wurden sichere Server-Plug-In-Architekturen für digitale Rechteverwaltungssysteme beschrieben. Dem Fachmann wird klar sein, dass zahlreiche Änderungen und Modifizierungen an den bevorzugten Ausführungsformen der Erfindung vorgenommen werden können, und dass solche Änderungen und Modifizierungen vorgenommen werden können, ohne von dem Gedanken der Erfindung abzuweichen. Obwohl die Erfindung zum Beispiel im Detail in Verbindung mit Veröffentlichungs- und Lizenzierungs-Pipelines beschrieben worden ist, sollte klar sein, dass die Erfindung in anderen digitalen Rechteverwaltungs-Pipelines verwendet werden kann, die andere digitale Rechteverwaltungs-Dienste durchführen, wie beispielsweise Registrierung, Aktivierung, Zertifizierung, Föderierung und dergleichen. Daher sollen die Ansprüche im Anhang alle solchen äquivalenten Variationen abdecken, die in den Umfang der Erfindung fallen.
ANHANG 1 Beispiel Rechte-Daten
ANHANG 2 Beispiel Signierte Rechte-Kennzeichnung (SRL) 308

Claims

System (300) zum Bereitstellen von DRM (digital rights management)-Diensten, wobei das System (300) umfasst: ein Dienstprogramm, das einen Verarbeitungsrahmen zum Durchführen eines DRM-Dienstes (306) schafft; und eine Vielzahl von Plug-In-Komponenten, von denen jede eine jeweilige Aufgabe erfüllt, die mit dem DRM-Dienst verbunden ist, wobei jede der Vielzahl von Plug-In-Komponenten entsprechend einem jeweiligen vordefinierten Satz von Schnittstellen-Regeln in den Verarbeitungsrahmen integriert wird.
System nach Anspruch 1, wobei der DRM-Dienst eine Veröffentlichungsanforderung zum Veröffentlichen von digitalem Inhalt mit verwalteten Rechten einschließt.
System nach Anspruch 2, wobei die Vielzahl von Plug-In-Komponenten eine Plug-In-Komponente zum Speichern einer Rechte-Kennzeichnung einschließt, die eine Rechte-Beschreibung, einen verschlüsselten Inhaltsschlüssel und eine digitale Signatur sowohl der Rechte-Beschreibung als auch des verschlüsselten Inhaltsschlüssels enthält.
System nach Anspruch 2, wobei die Vielzahl von Plug-In-Komponenten eine Plug-In-Komponente zum Schützen eines privaten Schlüssels einschließt, der im Zusammenhang mit Verschlüsseln und Entschlüsseln von digitalem Inhalt mit verwalteten Rechten verwendet wird.
System nach Anspruch 2, wobei die Vielzahl von Plug-In-Komponenten eine Plug-In-Komponente zum Erzeugen eines Zertifikats enthält.
System nach Anspruch 2, wobei die Vielzahl von Plug-In-Komponenten eine Plug-In-Komponente zum Authentifizieren einer Einheit enthält, die die Veröffentlichungsanforderung unterbreitet.
System nach Anspruch 2, wobei die Vielzahl von Plug-In-Komponenten eine Plug-In-Komponente enthält, mit der festgestellt wird, ob eine Einheit, die die Veröffentlichungsanforderung unterbreitet, autorisiert ist, den digitalen Inhalt mit verwalteten Rechten entsprechend der Anforderung zu veröffentlichen.
System nach Anspruch 1, wobei der DRM-Dienst Verarbeiten einer Lizenz-Anforderung zum Lizenzieren von digitalem Inhalt mit verwalteten Rechten enthält.
System nach Anspruch 8, wobei die Vielzahl von Plug-In-Komponenten eine Plug-In-Komponente eine Gruppenerweiterungs-Plug-In-Komponente zum Abrufen einer Benutzerliste auf Basis einer Gruppen-Kennung enthält, die in der Lizenzanforderung bereitgestellt wird.
System nach Anspruch 8, wobei die Vielzahl von Plug-In-Komponenten zum Abrufen einer Rechte-Kennzeichnung enthält, die eine Rechte-Beschreibung, einen verschlüsselten Inhaltsschlüssel und eine digitale Signatur sowohl der Rechte-Beschreibung als auch des verschlüsselten Rechte-Schlüssels enthält.
System nach Anspruch 8, wobei die Vielzahl von Plug-In-Komponenten eine Plug-In-Komponente zum Abrufen eines Zertifikats enthält.
System nach Anspruch 8, wobei die Vielzahl von Plug-In-Komponenten eine Plug-In-Komponente zum Authentifizieren einer Einheit enthält, die die Lizenzanforderung unterbreitet.
System nach Anspruch 8, wobei die Vielzahl von Plug-In-Komponenten eine Plug-In-Komponente enthält, mit der festgestellt wird, ob eine Einheit, die die Linzenz-Anforderung unterbreitet, autorisiert ist, den digitalen Inhalt mit verwalteten Rechten entsprechend der Anforderung zu nutzen.
System nach Anspruch 1, wobei die Vielzahl von Plug-In-Komponenten wenigstens eine Erweiterungs-Plug-In-Komponente enthält, die ihre jeweilige Aufgabe auf Basis des Auftretens eines vorgeschriebenen Ereignisses erfüllt.
System nach Anspruch 14, wobei die Erweiterungs-Plug-In-Komponente so eingerichtet ist, dass sie Abarbeitung des Dienst-Programms anhält.
System nach Anspruch 1, wobei die Vielzahl von Plug-In-Komponenten wenigstens eine asynchrone Komponente enthält.
System nach Anspruch 1, wobei der DRM-Dienst einen Registrierungsdienst einschließt.
System nach Anspruch 1, wobei der DRM-Dienst einen Aktivierungsdienst einschließt.
System nach Anspruch 1, wobei der DRM-Dienst einen Zertifizierungsdienst einschließt.
System nach Anspruch 1, wobei der DRM-Dienst einen Föderierungs-Dienst einschließt.
Verfahren zum Bereitstellen von DRM-Diensten, wobei das Verfahren umfasst: Bereitstellen eines Dienst-Programms, das einen Verarbeitungsrahmen zum Durchführen eines DRM-Dienstes schafft; Bereitstellen einer Vielzahl von DRM-Plug-In-Optionen, wobei jede der Plug-In-Optionen mit einer jeweiligen Plug-In-Komponente verbunden ist, die eine jeweilige Aufgabe erfüllt, die mit dem DRM-Dienst verbunden ist; und Integrieren einer ausgewählten Plug-In-Komponente in den Verarbeitungsrahmen, wobei die ausgewählte Plug-In-Komponente einer ausgewählten Plug-In-Option entspricht, die aus der Vielzahl von Plug-In-Optionen ausgewählt wird.
Verfahren nach Anspruch 21, das des Weiteren umfasst: Empfangen einer Plug-In-Auswahl, die der ausgewählten Plug-In-Komponente entspricht.
Verfahren nach Anspruch 21, wobei die gewünschte Plug-In-Komponente entsprechend einem vordefinierten Satz von Schnittstellen-Regeln in den Verarbeitungsrahmen integriert wird.
Verfahren nach Anspruch 21, wobei das Dienst-Programm einen Verarbeitungsrahmen zum Durchführen eines Lizenzierungsdienstes bereitstellt.
Verfahren nach Anspruch 21, wobei das Dienst-Programm einen Verarbeitungsrahmen zum Durchführen eines Veröffentlichungsdienstes bereitstellt.
DRM-System, das umfasst: einen DRM-Server (320), der ein computerlesbares Medium enthält, auf dem durch Computer ausführbare Befehle zum Durchführen einer Vielzahl von DRM-Diensten (306) gespeichert sind, wobei jeder der Vielzahl von DRM-Diensten in einer jeweiligen Pipeline durchgeführt wird und die jeweiligen Pipelines unabhängig voneinander (1110, 1210, 1310) sind.
DRM-System nach Anspruch 26, wobei jede der Pipelines umfasst: ein Dienstprogramm, das einen Verarbeitungsrahmen zum Durchführen des zugehörigen DRM-Dienstes schafft; und eine Vielzahl von Plug-In-Komponenten, von denen jede eine jeweilige Aufgabe erfüllt, die mit dem DRM-Dienst verbunden ist.
DRM-System nach Anspruch 27, wobei jede der Vielzahl von Plug-In-Komponenten entsprechend einem jeweiligen vordefinierten Satz von Schnittstellen-Regeln in den Vearbeitungsrahmen integriert wird.