DE60038046T2

DE60038046T2 - System und Verfahren zum Zugreifen auf geschützten Inhalt in einer Architektur mit Rechteverwaltung

Info

Publication number: DE60038046T2
Application number: DE60038046T
Authority: DE
Inventors: Marko A. Redmond DEMELLO; Vinay Woodinville Krishnaswamy; John L. Redmond MANFERDELLI
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 1999-12-17
Filing date: 2000-12-13
Publication date: 2009-04-30
Anticipated expiration: 2020-12-14
Also published as: JP4694077B2; ES2616250T3; WO2001046783A2; US20050188228A1; US20050108556A1; AU4717501A; EP1242858B1; US20090293116A1; ATE386290T1; US8032943B2; WO2001046783A3; DE60038046D1; US7562395B2; US7707643B2; ES2593311T3; JP2003518282A; US6996720B1; EP1242858A2

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft im Allgemeinen die Verteilung von elektronischen Inhalten und im Besonderen Systeme und Verfahren zum Zugreifen auf geschützten Inhalt in einer Architektur mit Rechteverwaltung (rights-management architecture).
HINTERGRUND DER ERFINDUNG
Da die Verfügbarkeit und Verwendung von Computer und in der Hand tragbaren elektronischen Vorrichtungen angestiegen ist, ist es gebräuchlich geworden, dass Dokumente elektronisch gesendet und betrachtet werden können. Durch die Verbesserungen der Geschwindigkeit und Einfachheit der Datenübertragung über Infrastrukturen wie beispielsweise das Internet besteht ein gewaltiger Drang danach, erweiterte Dienste und Inhalte für diese Vorrichtungen bereitzustellen. Beispiele für Dienste und Inhalte, die bereitgestellt werden können, sind verfasste Werke wie beispielsweise Bücher oder andere Textmaterialien. Die elektronische Verteilung von Textdokumenten ist nicht nur schneller, sondern auch billiger als die herkömmliche Verteilung von Papierkopien. Dasselbe Prinzip gilt auch für nicht-textuelle Inhalte wie beispielsweise Audio- und Videodaten: die elektronische Verteilung derartiger Inhalte ist im Allgemeinen schneller und billiger als die Bereitstellung derartiger Inhalte auf herkömmlichen Medien (beispielsweise Magnetband oder optische Scheibe). Die geringen Kosten und die sofortige Verfügbarkeit der elektronischen Verteilung stehen in Kombination mit der Einfachheit des Kopierens elektronischer Inhalte im Konflikt mit der gesteuerten Verteilung auf eine Weise, die die Rechte der Eigentümer der verteilten Werke schützt.
Sobald ein elektronisches Dokument an eine Partei übertragen wurde, kann es ohne Autorisierung durch den Eigentümer der Rechte an dem elektronischen Dokument und sogar häufig ohne das Wissen des Eigentümers leicht kopiert und an andere weitergegeben werden.
Diese Art der rechtswidrigen Verteilung von Dokumenten kann den Autor oder Bereitsteller des Inhaltes um Lizenzgebühren und/oder Einkommen bringen. Ein Problem vieler vorliegender Bereitstellungsschemata besteht darin, dass sie keine Vorkehrungen zum Schutze der Besitzrechte treffen. Andere Systeme versuchen, die Besitzrechte zu schützen, sind jedoch schlecht zu bedienen und unflexibel und machen das Betrachten/Lesen der verfassten Werke (oder anderweitiges Wiedergeben der verfassten Werke in dem Fall nicht-textueller Inhalte wie beispielsweise Musik, Video und so weiter) für den Käufer schwierig.
Somit besteht unter Berücksichtigung des oben Beschriebenen ein Bedarf für ein verbessertes digitales Rechteverwaltungssystem, das das Bereitstellen elektronischer Werke für Käufer auf eine Weise ermöglicht, die die Besitzrechte schützt und dabei flexibel und leicht zu bedienen ist. Es besteht ebenfalls ein Bedarf für das System, das flexible Ebenen des Schutzes der Sicherheit bereitstellt und auf mehreren Client-Plattformen einsetzbar ist, so dass der elektronische Inhalt von seinem Käufer auf jeder Plattform betrachtet/wiedergegeben werden kann. Das digitale Rechteverwaltungssystem der vorliegenden Erfindung stellt vorteilhafterweise Lösungen für die oben genannten Probleme bereit, die die gewerblichen Schutz- und Urheberrechte von Eigentümern von Inhalten schützen und es Autoren oder anderen Eigentümern von Inhalten ermöglichen, für ihre kreativen Anstrengungen entlohnt zu werden, während gleichzeitig sichergestellt wird, dass die Käufer durch den Schutzmechanismus nicht über Gebühr belastet werden.
Das Dokument US5991399 offenbart ein Repository, das herunterladbarer, ausführbarer Code ist und einen privaten Schlüssel sowie einen symmetrischen Inhaltsverschlüsselungs-Schlüssel enthält, der mit einem öffentlichen Schlüssel verschlüsselt wurde, der dem genannten privaten Schlüssel entspricht. Das Repository überprüft die Umgebung, bevor der private Schlüssel und das anschließende Freigeben des entschlüsselten Inhaltsverschlüsselungs-Schlüssels ermöglicht werden.
Das Dokument WO 96/24092 A betrifft ein Verfahren und ein System zum Verwalten eines Datenobjektes, um vorgegebene Bedingungen für die Verwendung des Datenobjektes zu erfüllen. Zum Steuern der Verwendung des Datenobjektes wird eine Reihe von Steuerdaten für das Datenobjekt erzeugt, die diejenigen Verwendungen des Datenobjektes definiert, welche die vorgegebenen Bedingungen erfüllen. Das Datenobjekt wird mit einer Benutzerreihe von Steuerdaten verkettet, verschlüsselt und an den Benutzer übertragen. Wenn der Benutzer das Datenobjekt verwenden möchte, startet er ein Benutzerprogramm. Anschließend fordert er eine Verwendung des Datenobjektes an. Die Anforderung wird von einem Benut zerschnittstellenmodul empfangen, das ein Steuermodul über die Verwendungsanforderung in Kenntnis setzt. Das Steuermodul ruft ein Verwendungsverwaltungsmodul auf und gibt die Verwendungsanforderung weiter. Das Verwendungsverwaltungsmodul stellt fest, ob die angeforderte Verwendung gestattet ist, dazu vergleicht es die Benutzeranforderung für die Verwendung mit den zusammen mit dem Datenobjekt verpackten und verschlüsselten Steuerdaten. Wird die angeforderte Verwendung genehmigt, ruft das Benutzerverwaltungsmodul ein Entschlüsselungsmodul auf, das die Objektdaten entschlüsselt. Anschließend wird die angeforderte Verwendung ermöglicht.
Das Dokument EP-A-0 778 512 beschäftigt sich mit dem Verwalten der Verwendung eines Anwendungsprogramms, das anfangs auf einem Server gespeichert ist, der durch einen Benutzer mit einem verteilten Computersystem verbunden wird. Eine Benutzeranforderung zum Zugreifen auf ein Anwendungsprogramm wird erkannt. Es wird bestimmt, ob vorgegebene Zugriffsbedingungen erfüllt sind. Eine Version des Anwendungsprogramms wird nur dann an den Computer übertragen, der dem Benutzer zugeordnet ist, welcher die Anforderung für den Empfang und das Speichern gestellt hat, wenn die Zugriffsbedingungen erfüllt sind. Vor dem Ausführen des Programms wird überprüft, dass der Benutzer derzeit berechtigt ist, das empfangene Anwendungsprogramm auszuführen. Eine ausführbare Version des Anwendungsprogramms wird nur dann aus der übertragenen Version erzeugt, wenn die Überprüfung dies bestätigt.
Das Dokument WO 99/55055 A bezieht sich auf ein Verfahren zum elektronischen Verteilen elektronischer Daten von einem Server zu einer Kundenvorrichtung über eine Netzwerk-Infrastruktur. Das Verfahren verwendet eine einzigartige Kennzeichnung eines Medienelementes, um die elektronischen Daten nur diesem einen Medienelement zuzuordnen. Das Verfahren umfasst das Einrichten einer Verbindung zwischen der Kundenvorrichtung und dem Server über die Netzwerk-Infrastruktur, das Übertragen der einzigartigen Kennzeichnung des einen Ziel-Medienelementes an den Server, das Verschlüsseln der elektronischen Daten, die an den Kunden zu übertragen sind, das Übertragen der elektronischen Daten an die Kundenvorrichtung, wobei die elektronischen Daten in einem verschlüsselten Format vorliegen, und das Schreiben der elektronischen Daten in das eine Medienelement derart, dass auf die Informationen zum Verwenden nur von dem einen Ziel-Medienelement aus zugegriffen werden kann.
In dem Dokument EP-A-0 843 449 wird ein durch Verschlüsseln gesichertes Computersystem beschrieben. Das Computersystem umfasst einen Server, der mit Kunden über ein of fentliches Netzwerk kommuniziert und dazu eine transaktionsverschlüsselte Entschlüsselungsschlüsseltechnologie verwendet, die einer unrechtmäßigen erneuten Weitergabe geschützter Informationen wie beispielsweise digitaler Musikpartituren entgegentritt und eine Nachverfolgung (tracking) von Übertretungsaktivitäten ermöglicht. Der Server gibt auf Anforderung Zugriffssoftware und teilweise verschlüsselte Musikpartituren an Kunden weiter. Ein Kunde kann die teilweise verschlüsselten Partituren prüfen, ehe er eine Transaktion abschließt. Wenn eine Partitur ausgewählt wird, gibt der Kunde Bezahlungsinformationen ein und es wird ihm ein Kennwort zugewiesen, das für diesen Kunden und diese Transaktion spezifisch ist. Das Kennwort dient als ein Entschlüsselungsschlüssel zum Aktivieren der Verwendung der Musikpartitur durch den Kunden, der die Zugriffssoftware verwendet. Jede folgende, unrechtmäßige, erneute Weitergabe der Musikpartitur zusammen mit dem Kennwort zum Entschlüsseln kann auf Grund der den Kunden identifizierenden Informationen, die verschlüsselt in dem Kennwort enthalten sind, nachverfolgt werden.
Das Dokument US-A-5 999 622 befasst sich mit der geschützten Verteilung von digitalen Datendateien. Die Dateien werden segmentiert und jedes Segment wird getrennt verschlüsselt. Manche Segmente können unverschlüsselt bleiben, wodurch der Zugriff beschleunigt wird, da weniger Entschlüsseln erforderlich ist. Unterschiedliche Segmente können unterschiedliche Verschlüsselungsverfahren verwenden, dies erhöht den Schutz gegen unberechtigtes Entschlüsseln. Eine zusammen mit den verschlüsselten Daten gespeicherte Tabelle stellt dazu berechtigten Benutzern Daten bereit, die die verschlüsselten Segmente und die Form der genutzten Verschlüsselung identifizieren. Das Entschlüsseln erfolgt mit einer Schichtenreihe (layered set) von Betriebssystemsoftware, die zusammen mit der Tabelle arbeitet.
Das Dokument von John Linn, „Generic Security Service API", Internetentwurf, August 1992, betrifft eine Anwendungsprogrammschnittstelle für einen generischen Sicherheitsdienst (generic security service application program interface – GSS-API), der Aufrufern Sicherheitsdienste bereitstellt und eine Portabilität auf Quellenebene (source level portability) von Anwendungen auf unterschiedliche Umgebungen zulässt. Ein typischer GSS-API-Aufrufer ist selbst ein Kommunikationsprotokoll, das eine GSS-API aufruft, um seinen Austausch mit Authentifizierungsintegritäts- und/oder Vertraulichkeitsdiensten zu schützen. Die über die GSS-API verfügbaren Sicherheitsdienste können über einen Bereich zu Grunde liegender Mechanismen auf Basis kryptographischer Technologien geheimer Schlüssel und öffentlicher Schlüssel implementiert werden. Die GSS-API trennt die Operationen des Initialisierens eines Sicherheitskontextes zwischen Partnern, wobei die Authentifizierung der Partnerin stanz (peer entity authentication) aus den Operationen des Bereitstellens der Authentifizierung des Mitteilungsdatenursprunges erfolgt und der Schutz der Datenintegrität für anschließend im Zusammenhang mit dem Kontext übertragene Mitteilungen erreicht wird. Es werden vier Gruppen von GSS-API-Aufrufen bereitgestellt. Darunter dient eine Gruppe von Aufrufen auf Kontextebene dem Einrichten und Verwalten des Sicherheitskontextes zwischen den Partnern. Die Gruppe der Aufrufe pro Mitteilung wird zum Ausbilden der Verarbeitung des Mitteilungsschutzes auf einem aufgebauten Sicherheitskontext verwendet und umfasst GSS_Sign (GSS-Signieren) und GSS_Seal (GSS-Kapseln), die zum Signieren und optional zum Verschlüsseln und Kapseln (encapsulating) verwendet werden.
Zusammenfassung der Erfindung
Es ist die Aufgabe der vorliegenden Erfindung, die Vertraulichkeit von auf einer Langzeit-Speichervorrichtung gespeicherten Informationen zu schützen, wenn eine Rendering-Anwendung einen Zugriff auf diese Informationen anfordert. Die Aufgabe wird durch die in den unabhängigen Ansprüchen beanspruchte Erfindung gelöst. Ausführungsformen werden in den abhängigen Ansprüchen gegeben.
Eine Architektur für einen Client zum Wiedergeben (Rendering) von Inhalten in einem digitalen Rechteverwaltungs-(„DRM")-System wird bereitgestellt. Die Architektur umfasst eine Rendering-Anwendung (beispielsweise eine Textbetrachtungsanwendung oder „Reader"), die von dem DRM-System geschützten Inhalt wiedergibt. Die Architektur umfasst ebenfalls verschiedene Sicherheitseigenschaften, die gegen unberechtigtes Verteilen oder Verwenden des geschützten Inhaltes schützen, sowie Softwarekomponenten, die die Sicherheitseigenschaften navigieren, um es zu ermöglichen, dass Inhalt in einer geeigneten Clientumgebung wiedergegeben werden kann.
In Übereinstimmung mit der bereitgestellten Architektur kann Inhalt auf einer Vielzahl von Ebenen geschützt werden, dies umfasst: kein Schutz, quellengekapselt, individuell gekapselt (oder „eingeschrieben"), quellensigniert und voll individualisiert (oder „eigentümerexklusiv"). Inhalt der Ebene „kein Schutz" wird in einem unverschlüsselten Format verteilt. Inhalt der Ebenen „quellengekapselt" und „individuell gekapselt” wird verschlüsselt und mit einem kryptographischen Schlüssel (dem „Inhaltsschlüssel") gebündelt, der kryptographisch mit bestimmten, dem Inhalt zugeordneten Rechteverwaltungsdaten gekapselt ist, so dass der Schlüssel nicht zurückgewonnen werden kann, wenn die Rechteverwaltungsdaten geändert wurden. Die Unterscheidung zwischen „Quellen-" und „individueller" Kapselung besteht dar in, dass „individuell gekapselter" Inhalt in den Rechteverwaltungsdaten Informationen umfasst, die den rechtmäßigen Eigentümer betreffen (beispielsweise den Namen des Eigentümers, seine Kreditkartennummer, die Quittungsnummer oder die Transaktionskennzeichnung für die Erwerbstransaktion und so weiter), so dass diese Informationen aus einer Arbeitskopie des Inhaltes nicht entfernt werden können, wodurch eine Erkennung unberechtigter Vertreiber ermöglicht wird. Die spezielle Art der enthaltenen Informationen wird durch den Händler der Kopie bestimmt. „Signierter" Inhalt ist kryptographisch auf eine Weise signiert, dass die Rendering-Anwendung seine Authentizität oder die Authentizität seines Vertriebskanals überprüfen kann. „Voll individualisierter" Inhalt ist verschlüsselter Inhalt, der mit einem Entschlüsselungsschlüssel bereitgestellt wird, der nicht nur mit den Rechteverwaltungsinformationen gekapselt, sondern darüber hinaus auf eine solche Weise verschlüsselt wurde, dass bei dem Nichtvorhandensein eines „sicheren Repositorys" und eines „Aktivierungszertifikates", die nur für einen bestimmten Client oder eine Reihe von Clients ausgestellt werden, nicht darauf zugegriffen werden kann, wodurch das Verwenden eines derartigen Inhaltes auf eine endliche Anzahl von Installationen begrenzt ist. „Voll individualisierter" Inhalt umfasst ebenfalls eine Lizenz, die die Rechte spezifiziert, die ein Benutzer in Bezug auf den Inhalt ausüben kann.
In einer Ausführungsform der Erfindung wird der Client zum Lesen von Büchern oder Text verwendet, die dem Client in einer Datei bereitgestellt werden, die wie oben beschrieben geschützt ist. Vorzugsweise umfassen die Clientsoftware und Daten in Bezug auf den Schutz und die Verwendung des Inhaltes: die Rendering-Anwendung (in dem Fall, wenn der Inhalt Text ist, „Reader" (Lesevorrichtung) genannt); eine „Verwaltungs"-Komponente, die das Entkapseln von geschütztem Inhalt und bestimmte andere kryptographische Funktionen durchführt; ein Softwareobjekt, das Bereitstellern von Inhalten Informationen wie beispielsweise den Installations- und/oder „Aktivierungs"-Status der Reader-Anwendung sowie Informationen über das „Aktivierungs"-Zertifikat bereitstellt, die von den Bereitstellern benötigt werden, um „voll individualisierten" Inhalt vorzubereiten, dessen Entschlüsselbarkeit auf eine bestimmte Reihe von Readern begrenzt ist; sowie ein „Aktivierungs"-Softwareobjekt, das die Funktionen des Erhaltens eines sicheren Repositorys und eines Aktivierungszertifikates für die Installation auf dem Client durchführt. Vorzugsweise ist das Aktivierungs-Softwareobjekt als eine ACTIVEX-Steuerung ausgeführt, und das Objekt, das Inhalts-Verteilungsorten Informationen bereitstellt, ist als ein ACTIVEX- und/oder Browser-Zusatzprogramm (Plugin), das in eine oder mehrere Javascript-Funktionen eingebettet ist, ausgebildet. Des Weiteren ist es vorzuziehen, dass das Verwaltungsobjekt durch die Reader-Anwendung über eine API, die mit der Reader-Anwendung vertraut ist, bedient werden kann.
Vorzugsweise wird der Inhaltsschlüssel von voll individualisiertem Inhalt gemäß einem öffentlich/privaten Schlüsselpaar verschlüsselt, das einem bestimmten Aktivierungszertifikat zugeordnet ist, und eine Kopie des Aktivierungszertifikates kann verschiedenen Client-Vorrichtungen bereitgestellt werden, die im Besitz einer bestimmten Person (oder „Persona") sind oder von dieser genutzt werden, so dass eine Person denselben „voll individualisierten" Inhalt auf verschiedenen Vorrichtungen, die sich im Besitz dieser Person befinden, lesen kann, wogegen andere Personen, die im Besitz ähnlicher Vorrichtungen sind, denselben „voll individualisierten" Inhalt nicht lesen können, da das notwendige Aktivierungszertifikat nicht auf diese Personen ausgestellt ist, wodurch die Verbreitung von voll individualisiertem Inhalt beschränkt wird.
Andere Eigenschaften der Erfindung werden im Folgenden beschrieben.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorstehende Zusammenfassung sowie die folgende ausführliche Beschreibung werden besser ersichtlich, wenn sie im Zusammenhang mit den angehängten Zeichnungen gelesen werden. Zum Zweck des Darstellers der Erfindung stellen gleiche Referenznummern ähnliche Teile über mehrere Ansichten der Zeichnungen dar, wobei jedoch verstanden wird, dass die Erfindung nicht auf die offenbarten spezifischen Methoden und Mittel begrenzt ist. In den Zeichnungen:
ist 1 ein Blockdiagramm, das eine beispielhafte Computerumgebung darstellt, in der Aspekte der vorliegenden Erfindung implementiert werden können;
2 ist ein Blockdiagramm einer ersten Ausführungsform einer Clientarchitektur, die Aspekte eines digitalen Rechteverwaltungssystems in Übereinstimmung mit der Erfindung implementiert;
3 ist ein Blockdiagramm einer zweiten Ausführungsform einer Clientarchitektur, die Aspekte eines digitalen Rechteverwaltungssystems in Übereinstimmung mit der Erfindung implementiert;
4 ist ein beispielhaftes elektronisches Buch (eBuch)-Titel-Dateiformat;
5 ist ein Ablaufdiagramm, das einen Reader-Aktivierungsprozess darstellt; und
6 ist ein Ablaufdiagramm, das beispielhafte Prozesse des Auswählens, Erhaltens und Lesens eines eBuches mittels eines digitalen Rechteverwaltungssystems gemäß der Erfindung darstellt.
AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
Die vorliegende Erfindung ist auf ein System für die Verarbeitung und Überbringung elektronischen Inhalts ausgerichtet, wobei der Inhalt auf verschiedenen Ebenen geschützt sein kann. Es wird eine bevorzugte Ausführungsform der Erfindung beschrieben, die auf die Verarbeitung und Überbringung elektronischer Bücher abzielt, die Erfindung ist jedoch nicht auf elektronische Bücher begrenzt und kann alle digitalen Inhalte wie beispielsweise Videodaten, Audiodaten, ausführbare Software, Daten und dergleichen umfassen.
Überblick
Der Erfolg der elektronischen Buchindustrie wird es unzweifelhaft erforderlich machen, dass dem bestehenden, Bücher kaufenden Publikum eine attraktive, sichere und vertraute Erfahrung zum Erwerb aller Arten von Textmaterialien zur Verfügung gestellt wird. Diese Materialien können „freie" oder Materialien zu geringen Kosten enthalten, die wenig Kopierschutz benötigen, bis hin zu elektronischen Buchtiteln in „Premiumqualität" (hierin „eBücher"), die einen umfassenden Schutz der Rechte benötigen. Um einen reibungslosen Übergang von dem derzeit bestehenden Vertriebs- und Einzelhandelsmodell für gedruckte Bücher zu einem elektronischen Vertriebssystem zu gewährleisten, muss eine Infrastruktur bestehen, die eine hohe Ebene des Kopierschutzes für diejenigen Publikationen bietet, die dies erfordern, wogegen sie die Verteilung von Titeln unterstützen, die geringere Ebenen des Schutzes benötigen.
Die Systeme zur digitalen Rechteverwaltung (DRM) und Server für digitale Vermögenswerte (Digital Asset Server – DAS) der vorliegenden Erfindung stellen vorteilhafterweise eine derartige Infrastruktur bereit. Die vorliegende Erfindung macht den Erwerb eines eBuches wünschenswerter als das „Stehlen" (beispielsweise das Anfertigen einer unberechtigten Kopie) eines eBuches. Das nicht intrusive DRM-System minimiert das Risiko der unerlaubten Vervielfältigung und erhöht dabei die Wahrscheinlichkeit, dass jedwede unerlaubte Vervielfältigung durch einen erhöhten Verkauf/Vertrieb von Büchern in der Form von eBüchern (eBooks) ausgeglichen wird. Darüber hinaus stellt die vorliegende Erfindung Händlern ein System bereit, das schnell und zu geringen Kosten eingesetzt werden kann.
Die Hauptbenutzer des Systems sind Herausgeber und Händler, die das System verwenden und/oder einsetzen, um die Rechtmäßigkeit des vertriebenen Inhaltes sowie einen Kopierschutz sicherzustellen. Beispielhafte Benutzer des Systems können der herkömmliche Herausgeber, der „Spitzen" Herausgeber sowie der „hungrige Autor" sein. Es ist wahrscheinlich, dass der herkömmliche Herausgeber Sorge hat, dass er aufgrund von eBuch-Piraterie Einkommensverluste bei seinen Verkäufen gedruckter Bücher erleidet. Der Spitzen-Herausgeber ist über vereinzelte Vorkommnisse unerlaubter Vervielfältigung nicht notwendigerweise bekümmert und kann einschätzen, dass der Handel mit eBüchern in einem System am erfolgreichsten ist, in dem sich die Verbraucher daran gewöhnen, auf diese Weise einzukaufen. Währenddessen ist der hungrige Autor oder die hungrige Autorin, der oder die für den Verkauf seiner oder ihrer Bücher gern Geld erhalten möchte, mehr an der Zuordnung interessiert (dass beispielsweise der Name des Autors/der Autorin dauerhaft mit dem Werk verbunden wird).
Wie im Folgenden ausführlicher beschrieben wird, erfüllt das DRM-System der vorliegenden Erfindung seine Ziele, indem es Werke schützt und unterdessen ihre rechtmäßige Verwendung durch Verbraucher ermöglicht, indem verschiedene „Ebenen" des Schutzes unterstützt werden. Auf der untersten Ebene („Ebene 1") können die Inhaltsquelle und/oder der Bereitsteller (provider) über unsignierte und entkapselte (Klartext-)eBücher, die keine Lizenz enthalten, keinen Schutz wählen. Eine nächste Ebene des Schutzes („Ebene 2") ist „quellengekapselt", dies bedeutet, dass der Inhalt mit einem Schlüssel verschlüsselt und gekapselt wurde, wobei die Kapselung (seal) mit einem kryptographischen Streuwert (hash) der Metadaten des Titels des eBuches (siehe unten) erzeugt wird und der Schlüssel zum Entschlüsseln des Inhaltes notwendig ist. Eine Quellenkapselung schützt gegen Manipulationen des Inhaltes oder der zugehörigen Metadaten, nachdem der Titel gekapselt wurde, da jedwede Änderungen der Metadaten bewirken, dass der Titel unbrauchbar ist; die Quellenkapselung garantiert jedoch nicht die Authentizität der Kopie des Titels (das heißt, eine Quellenkapselung stellt keinen Mechanismus zum Unterscheiden rechtmäßiger Kopien von unberechtigten Kopien bereit). In dem Fall des „hungrigen Autors” kann der Name des Autors in den Metadaten enthalten sein, um diesen somit dauerhaft an den Inhalt zu binden, wodurch der „hungrige Autor"/die „hungrige Autorin” sein/ihr Ziel erreicht hat, dass sein/ihr Name mit dem Werk verbunden ist. Eine nächste Ebene des Schutzes („Ebene 3") ist „individuell gekapselt" (oder „eingeschrieben"). Ein „individuell gekapselter" Titel ist ein eBuch, dessen Metadaten Informationen umfassen, die sich auf den rechtmäßigen Käufer beziehen (beispielsweise der Name des Benutzers oder seine Kreditkartennummer, die Transaktions-Kennzeichnung oder die Quittungsnummer von der Kauf-Transaktion und so weiter), so dass diese Informationen kryptographisch an den Inhalt gebunden werden, wenn der Titel gekapselt wird. Diese Ebene des Schutzes hält Personen davon ab, Kopien des Titels weiterzugeben, da es leicht wäre, den Ursprung einer unberechtigten Kopie festzustellen (und jedwede Änderung an den Metadaten einschließlich der Informationen, die sich auf den Käufer beziehen, würde es unmöglich oder wenigstens unwahrscheinlich machen, dass der notwendige Entschlüsselungsschlüssel entkapselt werden könnte).
Die nächste Ebene des Schutzes („Ebene 4") ist „quellensigniert". Quellensignierte eBücher sind Titel, die durch einen „Reader” authentifiziert werden können (ein Reader (eine Lesevorrichtung) ist, wie im Folgenden eingehender diskutiert wird, eine Benutzeranwendung, die das Lesen von eBüchern auf einer Rechenvorrichtung wie beispielsweise auf einem PC, einem Notebook, einem persönlichen digitalen Assistenten (PDA), einem PocketPC oder einer zu diesem Zweck hergestellten Lesevorrichtung ermöglicht). Die Authentizität kann vorzugsweise in drei Spielarten definiert werden: „durch ein Werkzeug signiert" (tool signed), dies garantiert, dass der eBuch-Titel durch ein vertrauenswürdiges Umwandlungs- und Verschlüsselungswerkzeug erzeugt wurde; „durch den Eigentümer signiert" (owner signed), dies ist ein durch ein Werkzeug signiertes eBuch, das ebenfalls die Authentizität des Inhaltes in der Kopie garantiert (beispielsweise kann der Eigentümer der Autor oder ein anderer Urheberrechtsinhaber sein); und „durch den Bereitsteller signiert" (provider signed), dies ist ein durch ein Werkzeug signiertes eBuch, das die Authentizität seines Bereitstellers bestätigt (beispielsweise des Herausgebers oder Händlers des Inhaltes). Das „Werkzeug", der Eigentümer sowie der Bereitsteller können jeweils ihr eigenes asymmetrisches Schlüsselpaar besitzen, um die Erstellung und Gültigkeitsprüfung der digitalen Signaturen der Informationen zu erleichtern. Ein Titel kann sowohl durch den Bereitsteller signiert als auch quellensigniert sein, dies erleichtert die Authentifizierung des Vertriebskanals des Titels (beispielsweise über eine Signaturkette in der Kopie). Die stärkste Ebene des Schutzes ist „voll individualisiert" oder „eigentümerexklusiv" („Ebene 5"). „Voll individualisierte" Titel können nur durch authentifizierte Readeranwendungen geöffnet werden, die für einen bestimmten Benutzer „aktiviert” wurden, wodurch ein Titel gegen das Portieren (porting) von dem Reader (oder den Readern) einer Person auf einen Reader, der nicht für diese Person registriert wurde, geschützt ist. Damit der Reader der vorliegenden Erfindung einen auf Ebene 5 geschützten Titel öffnen kann, muss der Reader „aktiviert" werden (das heißt, die Vorrichtung, auf der sich der Reader befindet, muss im Besitz eines Aktivierungszertifikates für eine bestimmte Persona sowie eines sicheren Repositorys sein). Der Prozess der Aktivierung wird im Folgenden ausführlicher in Bezug auf 5 beschrieben.
Die Systeme der vorliegenden Erfindung definieren ebenfalls eine Architektur für das gemeinsame Nutzen von Informationen zwischen einem Reader, einem Bereitsteller des Inhaltes sowie einer Inhaltsquelle, sie definieren die Art, wie diese Informationen zum „Kapseln" der Titel auf den verschiedenen Ebenen verwendet werden und wie diese Informationen strukturiert sein müssen. Die Verfügbarkeit dieser Auswahlmöglichkeiten ermöglicht es Inhaltsquellen, genau auszuwählen, welcher Inhalt welchem Benutzer (gegebenenfalls) unter Verwendung welchen Schutzes verkauft wird. Die bestimmten Informationen können zum Signieren und/oder Kapseln von Titeln zum Verwenden durch einen Reader verwendet werden, und ein kompatibler Reader (der in dem Fall des Schutzes auf Ebene 5 ein Reader sein kann, der für eine bestimmte Persona aktiviert ist) kann den Titel entkapseln und das Lesen des eBuches ermöglichen.
Systemarchitektur
Wie in 1 dargestellt, umfasst ein beispielhaftes System zum Implementieren der Erfindung eine für alle Zwecke geeignete Rechenvorrichtung (general purpose computing device) in der Form eines herkömmlichen Personalcomputers oder Netzwerkservers 20 oder dergleichen, der eine Verarbeitungseinheit (processing unit) 21, einen Systemspeicher (system memory) 22 sowie einen Systembus (system bus) 23 einschließt, der die verschiedenen Systemkomponenten einschließlich des Systemspeichers 22 mit der Verarbeitungseinheit 21 verbindet. Der Systembus 23 kann ein beliebiger aus mehreren Arten von Busstrukturen einschließlich eines Speicherbus (memory bus) oder einer Speichersteuerung (memory controller), eines Peripheriebus (peripheral bus) sowie eines lokalen Bus (local bus) sein, die jeweils jede beliebige einer Vielfalt von Busarchitekturen nutzen. Der Systemspeicher umfasst Nur-Lese-Speicher (ROM) 24 und Direktzugriffsspeicher (RAM) 25. Ein Basisdatenaustauschsystem 26 (basic input/output system – BIOS), das die Haupthilfsprogramme (basic routines) enthält, mit denen Informationen zwischen den Elementen innerhalb des Personalcomputers 20 übertragen werden, beispielsweise während des Hochfahrens, ist im ROM 24 gespeichert. Der Personalcomputer oder Netzwerkserver 20 kann des Weiteren ein Festplattenlaufwerk 27 zum Lesen von und Schreiben auf eine Festplatte, nicht dargestellt, ein Magnetscheibenlaufwerk 28 zum Lesen von oder Schreiben auf eine wechselbare Magnetscheibe 29 sowie ein optisches Scheibenlaufwerk 30 zum Lesen von oder Schreiben auf eine wechselbare optische Scheibe 31 wie beispielsweise eine CD-ROM oder andere optische Medien enthalten. Das Festplattenlaufwerk 27, das Magnetscheibenlaufwerk 28 sowie das optische Scheibenlaufwerk 30 sind mit dem Systembus 23 über eine Schnittstelle für ein Festplattenlaufwerk 32, eine Schnittstelle für ein Magnetscheibenlaufwerk 33 beziehung sweise eine Schnittstelle für ein optisches Laufwerk 34 verbunden. Die Laufwerke und ihre zugehörigen computerlesbaren Medien stellen einen nichtflüchtigen Speicher computerlesbarer Befehle, Datenstrukturen, Programmmodule und anderer Daten für den Personalcomputer oder Netzwerkserver 20 bereit. Obwohl die im Folgenden beschriebene, beispielhafte Umgebung eine Festplatte, eine wechselbare Magnetscheibe 29 sowie eine wechselbare optische Scheibe 31 verwendet, ist für Personen mit gewöhnlicher Erfahrung auf dem Gebiet der Technik ersichtlich, dass andere Arten computerlesbarer Medien, die Daten speichern können, auf die durch einen Computer zugegriffen werden kann, wie beispielsweise Magnetkassetten, Flashspeicherkarten, digitale Videoscheiben, Bernoulli-Kassetten, Direktzugriffsspeicher (RAMs), Nur-Lese-Speicher (ROMs) und so weiter, ebenfalls in der beispielhaften Betriebsumgebung verwendet werden können.
Eine Anzahl von Programmmodulen kann auf der Festplatte, Magnetscheibe 29, optischen Scheibe 31, in dem ROM 24 oder dem RAM 25 gespeichert werden, einschließlich eines Betriebssystems 35 (beispielsweise Windows^® 2000, Windows NT^® oder Windows 95/98), eines oder mehrerer Anwendungsprogramme 36, anderer Programmmodule 37 und Programmdaten 38. Ein Benutzer kann durch Eingabevorrichtungen wie beispielsweise eine Tastatur 40 und Zeigevorrichtung 42 Befehle und Informationen in den Personalcomputer 20 eingeben. Andere Eingabevorrichtungen (nicht dargestellt) können ein Mikrofon, ein Handsteuergeber (joystick), ein Berührungsfeld für Spiele (game pad), eine Satellitenschüssel, ein Scanner oder dergleichen sein. Diese und andere Eingabevorrichtungen werden oft mit der Verarbeitungseinheit 21 über eine Schnittstelle für einen seriellen Anschluss 46 verbunden, die mit dem Systembus 23 verbunden ist, sie können jedoch auch über andere Schnittstellen wie beispielsweise einen Parallelanschluss (parallel Port), einen Handsteuergeber-Anschluss (game Port), einen universellen seriellen Bus (universal serial bus – USB) oder einen seriellen 1394-Hochgeschwindigkeitsanschluss (1394 high-speed serial Port) verbunden werden. Ein Bildschirm (Monitor) 47 oder eine andere Art der Anzeigevorrichtung ist ebenfalls über eine Schnittstelle wie beispielsweise einen Videoadapter 48 mit dem Systembus 23 verbunden. Zusätzlich zu dem Bildschirm 47 enthalten Personalcomputer typischerweise andere Peripherie-Ausgabevorrichtungen (nicht dargestellt) wie beispielsweise Lautsprecher und Drucker.
Der Personalcomputer oder Netzwerkserver 20 kann in einer Netzwerkumgebung arbeiten und logische Verbindungen zu einem oder mehreren entfernten (remote) Computern wie beispielsweise einem entfernten Computer 49 besitzen. Der entfernte Computer 49 kann ein anderer Personalcomputer, ein anderer Netzwerkserver, ein Router, ein Netzwerk-PC, eine Partner-Vorrichtung (peer device) oder ein anderer gebräuchlicher Netzwerkknoten (network node) sein und umfasst typischerweise viele oder alle Elemente, die oben in Bezug auf den Personalcomputer 20 beschrieben wurden, obwohl in 2 nur eine Speichervorrichtung (memory storage device) 50 dargestellt wird. Die in 2 dargestellten, logischen Verbindungen umfassen ein lokales Netzwerk (local area network – LAN) 51 und ein Weitverkehrsnetzwerk (wide area network – WAN) 52. Derartige Netzwerkumgebungen sind in Büros, unternehmensweiten Computernetzen, Intranets und dem Internet gängig.
Wenn der Personalcomputer oder Netzwerkserver 20 in einer LAN-Netzwerkumgebung verwendet wird, ist er mit dem LAN 51 über eine Netzwerkschnittstelle oder einen Netzwerkadapter 53 verbunden. Wenn der Personalcomputer oder Netzwerkserver 20 in einer WAN-Netzwerkumgebung verwendet wird, umfasst er typischerweise ein Modem 54 oder eine andere Einrichtung zum Einrichten einer Kommunikation über das Weitverkehrsnetz 52, wie beispielsweise das Internet. Das Modem 54 kann ein internes oder ein externes Modem und mit dem Systembus 23 über die Schnittstelle für einen seriellen Anschluss 46 verbunden sein. In einer Netzwerkumgebung können die in Bezug auf den Personalcomputer oder Netzwerkserver 20 dargestellten Programmmodule oder Teile davon in der entfernten Speichervorrichtung (remote memory storage device) 50 gespeichert sein. Es wird festgestellt, dass die dargestellten Netzwerkverbindungen beispielhaft sind und dass andere Mittel zum Einrichten einer Kommunikationsverbindung zwischen den Computern verwendet werden können.
Clientarchitektur
Nunmehr wird in Bezug auf 2 eine erste beispielhafte Clientarchitektur 90 in Übereinstimmung mit der vorliegenden Erfindung dargestellt. Die Clientarchitektur 90 kann auf dem Personalcomputer 20 aus 1 oder einer anderen geeigneten Rechenvorrichtung wie beispielsweise einen in der Hand tragbaren Kleincomputer (palm-sized computer), einen Notebookcomputer (laptop computer) oder einer geschlossenen Vorrichtung, die zum Lesen von eBuch-Titeln hergestellt wurde, implementiert sein. Die Clientarchitektur 90 umfasst einen Reader-Kommandozeileninterpreter (shell) 92 (oder „Reader 92") zum Lesen von eBuch-Titeln 10 und einen Internet-Browser 102 (beispielsweise den MICROSOFT^® INTERNET EXPLORER-Browser), um Kontakt mit den Websites von Händlern/Vertriebsunternehmen aufzunehmen. Eine kryptographische Transformation wird bereitgestellt, dies kann ein Zusatzprogramm (Plugin) für ein Informationstechnologie-Speichersystem (Information Technology Storage System – ITSS) 5.2 96 sein. Die kryptog raphische Transformation ist eine Softwarekomponente, die den Inhaltsschlüssel entkapselt und den Inhaltsstrom entschlüsselt, der aus der eBuch-Datei oder „LIT-Datei" 10 herauskommt (dargestellt in 4). Die kryptographische Transformation ist vorzugsweise als eine Erweiterung (extension) zu dem bestehenden Code für das ITSS 96, der von dem Reader 92 für LIT-Dateien 10 verwendet wird, implementiert. Diese Erweiterung wird immer dann instanziiert, wenn auf verschlüsselten Inhalt zugegriffen wird. Eine Exlibris-API (bookplate API) 94 wird bereitgestellt, die den Namen des Käufers (oder andere Informationen, die sich auf den Käufer beziehen) aus dem kryptographisch gestreuten Exlibris-Strom 14C in dem DRM-Speicherobjekt 14 jedes Titels 10 zurückgibt (beispielsweise in dem Fall individuell gekapselter Titel, die den Namen des Käufers oder andere identifizierende Informationen in ihren Metadaten enthalten). Die durch diese Funktion zurückgeführte Zeichenkette (string) kann auf dem Buch-Deckblatt 100 verwendet werden, um den rechtmäßigen Eigentümer des Titels 10 zu identifizieren; ein Beispiel, in dem die Zeichenkette der Name des Benutzers ist, wird in 2 dargestellt. Wenn der Benutzer auf dem Deckblatt auf den angezeigten Namen oder auf eine Urheberrechtsmitteilung/auf ein entsprechendes Piktogramm klickt (oder bei Geräten mit berührungsempfindlichem Bildschirm darauf tippt), kann ein Dialogfeld angezeigt werden, das deutlich auf das geschützte Urheberrecht der Publikation hinweist. Der lokale Speicher 98 ist vorzugsweise ein Verzeichnis oder Ordner, in dem eBücher gespeichert werden können. (Wie im Folgenden in Verbindung mit 4 diskutiert, ist das eBuch 10 eine Datei, die den Inhalt des Buches sowie andere Informationen enthält.) Wenn beispielsweise die Architektur 90 auf einer Vorrichtung implementiert ist, die unter einem Betriebssystem von MICROSOFT WINDOWS arbeitet, könnte der lokale Speicher 98 einfach ein Verzeichnis mit dem Namen „C:" sein. Der Browser 102 ist ein typisches Browsing-Programm (beispielsweise der Browser MICROSOFT INTERNET EXPLORER oder der Browser NETSCAPE NAVIGATOR); er wird verwendet, um Kontakt mit Einzelhandels-Websites aufzunehmen, die eBücher verkaufen, und Transaktionen mit diesen Websites aufzunehmen. In einigen Fällen kann der Reader 92 eine Eigenschaft „integrierter Buchladen" umfassen, die ohne die Verwendung einer allgemeinen Browsing-Anwendung 102 Kontakt mit Einzelhandels-Websites aufnimmt und das Einkaufen erleichtert.
Nunmehr wird in Bezug auf 3 eine zweite beispielhafte Clientarchitektur 90' dargestellt. In der zweiten Clientarchitektur stellen gleiche Referenznummern auch gleiche Elemente wie in der ersten Clientarchitektur dar, und daher werden die Beschreibungen dieser gleichen Elemente im Folgenden nicht wiederholt. Der DRM-Verwalter 80 ist eine Komponente, die für den Reader 92 eine Reihe von internen APIs zeigt, die zusätzlich zum Durchführen des Entschlüsselns von Inhalt, dem Entkapseln von Schlüsseln, dem Zurückgeben einer Ex libris-Zeichenkette (beispielsweise des Namens des Benutzers zum Anzeigen beispielsweise in dem Fall eines Titels der Ebene 3 oder der Ebene 5) und so weiter auch die Authentifizierung von Anwendungen verwalten, die einen Zugriff auf verschlüsselte LIT-Dateien anfordern. Beispielsweise kann der Code für den Reader 92 einen Schnittstellenaufruf enthalten, der Teil der API ist, wobei der Aufruf durch Computer ausführbare Befehle zum Ausführen einer der oben aufgelisteten Funktionen aufruft. Die durch Computer ausführbaren Befehle können in einem COM-Objekt und/oder in einer dynamischen Verknüpfungsbibliothek (dynamic link library – DLL) zum Verwenden durch den Reader 92 verkörpert sein. Unterschiedliche Versionen des COM-Objektes und/oder der DLL können bereitgestellt werden, um Aktualisierungen auf Technologien Rechnung zu tragen (das heißt, um es dem Reader 92 zu ermöglichen, transparent über eine gleich bleibende API mit verschiedenen unterschiedlichen DRM-Technologien zusammenzuarbeiten, von denen einige zu dem Zeitpunkt, als der Programmcode für den Reader 92 erzeugt wurde, noch nicht einmal entwickelt waren). In einem Beispiel kann der Entwickler/Administrator der Architektur 90' dem Entwickler des Readers 92 eine Spezifizierung oder Beschreibung einer Schnittstelle bereitstellen (beispielsweise eine Reihe von Verfahrensnamen/Kennsätzen für die API), und er kann dann den Benutzern der Clientarchitektur 90' eine DLL oder ein COM-Objekt (oder aufeinander folgende DLLs und COM-Objekte) bereitstellen. In einem weiteren Beispiel kann der Entwickler/Administrator der Architektur 90' dieselbe Instanz sein, die den Reader 92 bereitstellt, und er kann eine API für den DRM-Verwalter 80 definieren, um die Kommunikation mit den verschiedenen Komponenten der Architektur 90' zu erleichtern.
Das sichere Repository 82 ist eine ausführbare Datei, die während des Aktivierungsprozesses heruntergeladen wird und es dem Reader ermöglicht, voll individualisierte eBücher (LIT-Dateien) (der Ebene 5) zu öffnen. Das sichere Repository 82 ist vorzugsweise einzigartig (oder im Wesentlichen einzigartig) für jede Rechenvorrichtung, auf der die Architektur 90' implementiert ist (beispielsweise ein PC oder eine speziell angefertigte Lesevorrichtung). Das sichere Repository 82 besitzt einen privaten Schlüssel, der zum Öffnen von auf der Ebene 5 geschützten Titeln benötigt wird. Das sichere Repository 82 kann während des Aktivierungsprozesses erhalten werden (im Folgenden beschrieben). In einem Beispiel lädt die Rechenvorrichtung, auf der sich die Architektur 90' befindet, (über ein Netzwerk wie beispielsweise das Netzwerk 52) eine Hardware-Kennzeichnung auf einen „sicheren Repository-Server" (nicht dargestellt) hoch, wobei die Hardware-Kennzeichnung auf Hardware beruht, die der Rechenvorrichtung zugeordnet ist (beispielsweise durch Seriennummern oder andere Nummern, die dieser Hardware zugeordnet sind) und die Vorrichtung einzigartig identifiziert. Der „sichere Repository-Server" kann anschließend ein sicheres Repository auf die Rechenvorrichtung herunterladen, dessen Code auf der Rechenvorrichtung, auf der die Architektur 90' implementiert ist, basiert und dessen ordnungsgemäße Ausführung vorzugsweise an diese gebunden ist, wobei das sichere Repository Funktionen durchführt, die das Anwenden eines einzigartigen privaten Schlüssels, der in dem Prozess des Entkapselns des Inhaltsschlüssels verwendet wird, sowie das Entschlüsseln des Inhaltes einschließt. In einer beispielhaften Ausführungsform wird der Inhalt in einem Titel der Ebene 5 mit einem symmetrischen Schlüssel verschlüsselt, der symmetrische Schlüssel ist mit einem öffentlichen Schlüssel verschlüsselt, der in einem Aktivierungszertifikat enthalten ist, der verschlüsselte symmetrische Schlüssel ist mit dem Titel gekapselt und der private Schlüssel des Aktivierungszertifikates ist in dem Aktivierungszertifikat in einer Form enthalten, die durch den öffentlichen Schlüssel des sicheren Repositorys 82 verschlüsselt ist. In diesem Beispiel entschlüsselt das sichere Repository 82 den privaten Schlüssel des Aktivierungszertifikates und verwendet dazu den privaten Schlüssel des sicheren Repositorys 82, anschließend wird der private Schlüssel des Aktivierungszertifikates zum Entschlüsseln des symmetrischen Schlüssels verwendet. In einem Beispiel kann der Entwickler/Administrator der Architektur 90' dem Entwickler des Readers 92 eine Spezifizierung oder Beschreibung einer Schnittstelle (beispielsweise eine Reihe von Verfahrensnamen/Kennsätzen für die API) bereitstellen und er kann anschließend den Benutzern der Clientarchitektur 90' eine DLL oder ein COM-Objekt (oder aufeinanderfolgende DLLs und COM-Objekte) bereitstellen. In einem weiteren Beispiel kann der Entwickler/Administrator der Architektur 90' dieselbe Instanz sein, die den Reader 92 bereitstellt, und er kann eine API für den DRM-Verwalter 80 definieren, um die Kommunikation mit den verschiedenen Komponenten der Architektur 90' zu erleichtern.
Das sichere Repository 82 ist eine ausführbare Datei, die während des Aktivierungsprozesses heruntergeladen wird und es dem Reader ermöglicht, voll individualisierte eBücher (LIT-Dateien) (der Ebene 5) zu öffnen. Das sichere Repository 82 ist vorzugsweise einzigartig (oder im Wesentlichen einzigartig) für jede Rechenvorrichtung, auf der die Architektur 90' implementiert ist (beispielsweise ein PC oder eine speziell angefertigte Lesevorrichtung). Das sichere Repository 82 besitzt einen privaten Schlüssel, der zum Öffnen von auf der Ebene 5 geschützten Titeln benötigt wird. Das sichere Repository 82 kann während des Aktivierungsprozesses erhalten werden (im Folgenden beschrieben). In einem Beispiel lädt die Rechenvorrichtung, auf der sich die Architektur 90' befindet, (über ein Netzwerk wie beispielsweise das Netzwerk 52) eine Hardware-Kennzeichnung auf einen „sicheren Repository-Server" (nicht dargestellt) hoch, wobei die Hardware-Kennzeichnung auf Hardware beruht, die der Rechenvorrichtung zugeordnet ist (beispielsweise durch Seriennummern oder andere Nummern, die dieser Hardware zugeordnet sind) und die Vorrichtung einzigartig identifiziert. Der „sichere Repository-Server" kann anschließend ein sicheres Repository auf die Rechenvorrichtung herunterladen, dessen Code auf der Rechenvorrichtung, auf der die Architektur 90' implementiert ist, basiert und dessen ordnungsgemäße Ausführung vorzugsweise an diese gebunden ist, wobei das sichere Repository Funktionen durchführt, die das Anwenden eines einzigartigen privaten Schlüssels, der in dem Prozess des Entkapselns des Inhaltsschlüssels verwendet wird, sowie das Entschlüsseln des Inhaltes einschließt. In einer beispielhaften Ausführungsform wird der Inhalt in einem Titel der Ebene 5 mit einem symmetrischen Schlüssel verschlüsselt, der symmetrische Schlüssel ist mit einem öffentlichen Schlüssel verschlüsselt, der in einem Aktivierungszertifikat enthalten ist, der verschlüsselte symmetrische Schlüssel ist mit dem Titel gekapselt und der private Schlüssel des Aktivierungszertifikates ist in dem Aktivierungszertifikat in einer Form enthalten, die durch den öffentlichen Schlüssel des sicheren Repositorys 82 verschlüsselt ist. In diesem Beispiel entschlüsselt das sichere Repository 82 den privaten Schlüssel des Aktivierungszertifikates und verwendet dazu den privaten Schlüssel des sicheren Repositorys 82, anschließend wird der private Schlüssel des Aktivierungszertifikates zum Entschlüsseln des symmetrischen Schlüssels verwendet. Ein System und ein Verfahren zum Erzeugen eines sicheren Repositorys 82 wird in dem Dokument mit den Anwaltsaktenzeichen Nummer MSFT-0126, gleichzeitig hiermit eingereicht und ausdrücklich in seiner Gänze als Referenz inkorporiert, beschrieben.
Die Aktivierungs-ACTIVEX-Steuerung 84 ist eine Komponente, die von der Client-Rechenvorrichtung während des Aktivierungsprozesses (siehe unten) verwendet wird. Vorzugsweise wird die ACTIVEX-Steuerung 84 von einem Browser (beispielsweise einem MICROSOFT INTERNET EXPLORER-Browser) verwendet, der seinerseits auf dem Reader 92 ausgeführt (hosted) wird (obwohl die ACTIVEX-Steuerung 84 auch mit einem autonomen Browser arbeiten könnte). Die Aktivierungs-ACTIVEX-Steuerung 84 zeigt Methoden, die die Gültigkeitsprüfung von Servern (beispielsweise dem/den „Aktivierungsserver(n)"), mit denen der Reader 92 (oder die Rechenvorrichtung, auf der dieser seinen Sitz hat) verbunden ist, sowie die Berechnung der Hardware-Kennzeichnung, das Herunterladen des sicheren Repositorys 82 (und zugehöriger Aktivierungszertifikate) sowie die Authentifizierung und Installation der heruntergeladenen ausführbaren Datei bereitstellen. So kann beispielsweise der Reader 92 (oder eine andere Softwarekomponente) Befehle enthalten, um festzustellen, ob der Reader 92 aktiviert wurde, und wenn er nicht aktiviert wurde, können sie einen oder mehrere Befehle an die Aktivierungs-ACTIVEX-Steuerung 84 zum Durchführen der Aktivierung ausgeben und diese Befehle können Befehle zum Durchführen der oben genannten Handlungen enthalten.
Das Internethandelsobjekt 86 wird sowohl als ACTIVEX-Steuerung als auch als ein Zusatzprogramm für den Browser NETSCAPE NAVIGATOR^® verbreitet. Es kann über clientseitige Skriptausführung (client-side scripting) von Händlern verwendet werden, wenn voll individualisierte Kopien (das heißt, auf der Ebene 5 geschützte Kopien) verkauft werden. Dieses COM-Objekt 86 ist vorzugsweise durch clientseitige Skript-Funktionen eingebettet (wrapped), die die derzeitigen Methoden und zu Grunde liegende Unterschiede zwischen dem Zusatzprogramm und der ACTIVEX-Steuerung abstrahieren. Die von dem Internethandelsobjekt 86 bereitgestellten Schlüsselmethoden und seine zugehörige Schnittstelle sind: das Erkennen der Installation des Readers 92, das Erkennen des Aktivierungsstatus, das Starten des Readers für den Aktivierungsprozess (siehe 5), das Gewinnen der verschlüsselten PASSPORT-Kennzeichnung, mit der der Reader aktiviert wurde, sowie das Gewinnen eines (vorzugsweise verschlüsselten) Aktivierungszertifikates während des Herunterladens voll individualisierter Kopien (die auf der Ebene 5 geschützt sind). So kann beispielsweise ein Skript (beispielsweise ein Javascript) an Händler von eBüchern für die Aufnahme in die Internetseiten des Händlers verteilt werden. Das Skript kann Funktionsaufrufe zeigen, die die oben aufgelisteten Methoden implementieren, und das Skript kann Programmcode enthalten, um zu bestimmen, ob es von einem MICROSOFT INTERNET EXPLORER-Browser oder einem NETSCAPE NAVIGATOR-Browser ausgeführt wird, wobei es in dem ersten Fall die ACTIVEX-Steuerung verwendet und in dem zweiten Fall das Zusatzprogramm. Ein Händler kann in wirksamer Weise auf der Client-Rechenvorrichtung auszuführende Befehle senden, indem er das Skript sendet, das die Funktionsaufrufe zusammen mit den Skript-Befehlen definiert, die die Funktionen aufrufen. Beispielsweise kann ein Händler festzustellen wünschen, ob der Reader 92 auf der Rechenvorrichtung eines Kunden installiert ist, so dass der Händler dem Kundengerät eine Internetseite, die das Javascript enthält, das die Funktion des Erkennens enthält, ob der Reader 92 installiert ist, zusammen mit einem Befehl zum Aufrufen dieser Funktion senden kann. Die Erkennungsfunktion selbst kann Programmcode enthalten, mit dem die Erkennungsfunktion entweder der ACTIVEX-Steuerung oder des Zusatzprogramms in Abhängigkeit von der Marke des Browsers durchgeführt wird, auf dem das Skript ausgeführt wird. Auf diese Weise ist der bestimmte Browser transparent für den Händler, der eine einzige Internetseite erzeugen kann, die jedwede der oben aufgelisteten Funktionen auf jedem Browser durchführt.
Dateistruktur eines eBuches
Nunmehr wird in Bezug auf 4 eine beispielhafte eBuch-(oder „LIT"-)Dateistruktur dargestellt. Das eBuch 10 enthält Inhalt 16, der Text wie beispielsweise ein Buch (oder jedwe der elektronischer Inhalt wie beispielsweise Audiodaten, Videodaten und so weiter) ist, der mit einem Schlüssel (dem „Inhaltsschlüssel") verschlüsselt wurde, welcher seinerseits verschlüsselt und/oder gekapselt wurde. In einer bevorzugten Ausführungsform ist der Schlüssel ein symmetrischer Schlüssel 14A, der mit einem kryptographischen Streuwert von Metadaten 12 oder in dem Fall von Titeln der Ebene 5 mit dem öffentlichen Schlüssel des Aktivierungszertifikates des Benutzers gekapselt ist. Dieser Schlüssel wird entweder als gesonderter Strom in einem untergeordneten Speicherabschnitt der eBuch-Datei (Strom 14A des DRM-Speichers 14 in 4) oder in dem Fall von Titeln der Ebene 5 in der Lizenz gespeichert. (In dem Fall von Titeln der Ebene 5 enthält der Strom 14A anstelle des Speicherns des Inhaltsschlüssels als ein gesonderter Strom eine Lizenz, die ein Konstrukt ist, das die Rechte definiert, die der Benutzer beim Erwerb des Titels ausüben kann. Bei Titeln, die eine Lizenz haben, ist der Inhaltsschlüssel in der Lizenz enthalten.) Ebenfalls in dem DRM-Speicher 14 enthalten sind der Quellenstrom 146, der den Namen des Herausgebers (oder eine andere Inhaltsquelle) enthalten kann, sowie der Exlibris-Strom 14C, der für individuell gekapselte Titel (der Ebene 3 und/oder der Ebene 5) den Namen des Verbrauchers, wie von dem Händler bereitgestellt, enthält (der Name kann beispielsweise als ein Teil der kommerziellen Transaktion des Kaufens eines eBuches 10 beispielsweise aus den Kreditkarteninformationen des Verbrauchers erhalten werden). Das Verfahren des Berechnens des kryptographischen Streuwertes, der den symmetrischen Schlüssel 14C verschlüsselt und/oder kapselt (oder das Verfahren des Verwendens eines derartigen kryptographischen Streuwertes zum Kapseln des Schlüssels) ist vorzugsweise ein „Geheimnis", das nur vertrauenswürdigen Inhaltsvorbereitungswerkzeugen und vertrauenswürdigen Wiedergabenwendungen bekannt ist. Das Verwenden eines Streuwertes auf diese Weise kann Manipulationen der Metadaten 12, die in dem eBuch 10 enthalten sind, verkomplizieren oder diesen entgegentreten. Es wird angemerkt, dass jedes Verfahren zum „Kapseln" eines eBuches verwendet werden kann, solange ein derartiges Verfahren Maßnahmen zur Manipulationssicherheit für das eBuch 10 bereitstellt.
In Übereinstimmung mit der vorliegenden Erfindung können die Metadaten 12 eine Urheberrechtsmarkierung enthalten, die die dem Benutzer oder Käufer durch die Inhaltsquelle (beispielsweise den Herausgeber) gewährten Rechte beschreibt. Immer wenn eine derartige Markierung vorliegt, kann der Reader 92 einem Benutzer den in der Markierung enthaltenen Text anzeigen, beispielsweise, wenn der Benutzer in dem Fall individuell gekapselter Kopien auf den auf dem Deckblatt 100 angezeigten Namen (dargestellt in 2 und 3) oder auf die Verknüpfung des „Urheberschutzvermerkes" tippt (in dem Fall von quellengekapselten Kopien mit einer Urheberrechtsmarkierung), die ebenfalls auf dem Deckblatt 100 wiederge geben werden können. Wird die Urheberrechtsmarkierung durch die Inhaltsquelle nicht in Metadaten 12 eingefügt, sondern wurde der eBuch-Titel individuell gekapselt (Ebene 3), kann die Leseanwendung auf Basis des offenbarten Systems (beispielsweise des Readers 92) einen allgemeinen Urheberschutzvermerk anzeigen, beispielsweise die folgende Mitteilung oder eine ähnliche Mitteilung: „Kein Teil dieser elektronischen Publikation darf ohne das schriftliche Einverständnis des Herausgebers in irgendeiner Form oder durch irgendeine Einrichtung, sei es elektronisch, mechanisch, Druck, Fotokopieren, Aufzeichnung, oder durch irgendein Informationsspeicher- und -abfragesystem reproduziert, weiter verteilt oder erneut übertragen werden." Vorteilhafterweise dient der Vorgang des Anzeigens eines Urheberschutzvermerkes dazu, typische Benutzer davon abzuhalten, Kopien ihrer eBücher anzufertigen, und ein derartiger Vermerk kann an jedem Punkt während des Betrachtens eines eBuches angezeigt werden, wenn dies für vorteilhaft gehalten wird, um Benutzer daran zu erinnern, dass sie urheberrechtlich geschütztes Material betrachten.
Aktivieren eines Readers
Wie oben festgestellt, ermöglicht es die Aktivierung einem Reader-Client, voll individualisierte eBuch-Titel (das heißt, der Ebene 5) zu erwerben, herunterzuladen und zu betrachten. Da Computer, die eines der MICROSOFT WINDOWS^® Betriebssysteme (oder andere allgemeine Betriebssysteme) ausführen, im Wesentlichen offene Plattformen sind, bei denen jedermann Fehler in einem laufenden Prozess beseitigen und so genannte „Patches" (Flicken) (Softwaremodifikationsmodule) zum Kompromittieren („Hacken") der Sicherheit von jeder Anwendung erzeugen kann, ist der Bedarf, sichere Rahmenbedingungen um den Reader-Client herum aufzubauen, eine wesentliche Grundvoraussetzung zum Bereitstellen eines echten Kopierschutzes/Widerstandes. Die „Aktivierung" ist der Prozess, durch den diese Rahmenbedingungen für den Reader 92 aufgebaut werden.
Es ist vorzuziehen, dass der Aktivierungsprozess mithilfe einer „Namensraum-Autorität” (namespace authority) wie beispielsweise MICROSOFT^® PASSPORT^TM als Aktivierungsdatenbank durchgeführt wird. Das Verwenden von PASSPORT^TM lässt vorteilhafterweise das Verknüpfen des Aktivierungszertifikates des Benutzers mit seiner/ihrer Persona zu. Wie hierin verwendet, ist eine „Persona" eine einzigartige Kennzeichnung, die mit einem Benutzer verknüpft und durch einen Band-externen Prozess (out-of-band process) sicher authentifiziert werden kann; so ist beispielsweise ein Formular für die Eingabe eines Benutzernamens und eines Kennwortes auf einem Internet-Browser zum Verwenden mit einer sicheren Basisebene (SSL-Verschlüsselung – secure socket layer) eine beispielhafte Ausführungsform eines derartigen Prozesses. Eine Einzelperson kann unter Verwendung eines „Persona"-Schemas erworbene Titel auf jedem Reader lesen, der mittels derjenigen „Persona" aktiviert wurde, unter der der Titel erworben wurde. Außerdem können nach der erfolgten Aktivierung die Aktivierungsinformationen für mehrere Händler verfügbar gemacht werden, um den Bedarf für eine Server-zu-Server-Kommunikation zwischen den Händlern und der Aktivierungsautorität zu eliminieren, dabei jedoch Bedenken hinsichtlich des Datenschutzes zu lindern.
Im Folgenden wird der Prozess beschrieben, durch den ein Reader aktiviert wird. Wenn ein Benutzer eine speziell hergestellte eBuch-Lesevorrichtung erwirbt oder eine Lesesoftware für einen PC erhält (beispielsweise über eine CD-ROM 31 oder durch Herunterladen über ein Weitverkehrsnetzwerk 52 wie beispielsweise das Internet), wird der Benutzer angehalten, den Reader zu aktivieren, wenn der Reader das erste Mal gestartet wird (beispielsweise unmittelbar nach dem Einrichten (Setup) für die Notebook-/Desktopanwendung). So kann der Reader beispielsweise jedes Mal, wenn er gestartet wird, prüfen, ob er aktiviert wurde (oder ein anderes Softwareobjekt kann prüfen, ob der Reader aktiviert wurde). Wenn der Reader nicht aktiviert wurde, gibt der Reader ein Dialogfeld wieder, das den Benutzer daran erinnert, dass er oder sie nicht in der Lage sein wird, Premiumtitel zu erwerben, die eine volle Individualisierung erfordern (das heißt, auf Ebene 5 geschützte Titel). Ein Beispiel für eine solche Erinnerung ist:
Herzlichen Glückwunsch zur Installation des Microsoft^® Readers. Damit Sie mit Ihrem Reader Premiumtitel kaufen und herunterladen können, die für den Vertrieb geschützt wurden, müssen Sie den Reader online aktivieren.
Der Dialog kann Schaltflächen enthalten, die es dem Benutzer erlauben, den Reader 92 zu aktivieren (beispielsweise können in dem Dialogfeld zwei Schaltflächen angezeigt werden mit der Aufschrift „Reader jetzt aktivieren" und „Reader zu einem späteren Zeitpunkt aktivieren"). In dem Dialogfeld kann des Weiteren ein „Kontrollkästchen" enthalten sein mit einer Mitteilung wie beispielsweise „Diese Mitteilung in Zukunft nicht mehr anzeigen"; dieses Kontrollkästchen würde von dem Benutzer markiert werden, wenn er oder sie kein Interesse daran hat, Titel der Ebene 5 zu erwerben, so dass der Reader die Aktivierungsmitteilung beim Programmstart nicht mehr anzeigt. Wenn der Reader vorher aktiviert wurde, wird die PASSPORT-Kennzeichnung oder Persona-Kennzeichnung des letzten Benutzers, der den Reader aktiviert hat, ebenfalls in einem „Splash-Screen" wie beispielsweise „Aktiviert für <Persona>" angezeigt. Der Benutzer kann den Reader auch von allen Einzelhandels-Websites aus wäh rend des Einkaufens mit einem unabhängigen Browser aktivieren. In diesem Szenario können Händler wirksam ein Verfahren einsetzen, das von dem Reader-Internethandelsobjekt 86 und der zugehörigen Skripteinbettungs-API (script wrapper API) zum Wiedergeben einer Verknüpfung und/oder einer Schaltfläche gezeigt wird, die den Reader 92 als einen gesonderten Prozess startet. So kann ein Händler beispielsweise eine Skriptfunktion in eine Internetseite einfügen, die die Aktivierungseigenschaft des Readers 92 startet, welche den Benutzer dann durch die Schritte der Aktivierung leitet, ganz so, als hätte der Benutzer den Reader allein hochgefahren und die Aktivierungsfunktion gestartet. (Wie oben festgestellt, kann die Skriptfunktion den Programmstart entweder mit einer ACTIVEX-Steuerung oder mit einem Zusatzprogramm durchführen, je nachdem, auf welcher Art von Browser sie läuft.) Der Händler kann in eine Internetseite auch einen Befehl einfügen (und dazu das Internethandelsobjekt 86 und die zugehörige Skripteinbettungsvorichtung verwenden), um zunächst festzustellen, ob der Reader 92 aktiviert ist, und den Aktivierungsprozess nur dann zu starten, wenn der Reader 92 vorher noch nicht aktiviert wurde. In einem weiteren Szenario kann der Reader 92 eine Funktion „integrierter Buchladen" des Readers nutzen (beispielsweise eine Funktion, die es dem Benutzer ermöglicht, auf verschiedenen Websites einzukaufen, die eBücher verkaufen, ohne dazu einen Browser zu verwenden), und der Aktivierungsprozess könnte über die Funktion (oder einen Teil davon) des „integrierten Buchladens" des Readers 92 gestartet werden.
Unter der Annahme, dass der Benutzer sich entschieden hat, den Reader 92 zu aktivieren, kann der Aktivierungsprozess die in 5 dargestellten Schritte umfassen. Bei Schritt 150 öffnet der Reader-Client sich in den Abschnitt „integrierten Buchladen" und verbindet sich über eine sichere Basisebene (Secure Socket Layer – SSL) mit den Aktivierungsservern, wobei die Benutzer aufgefordert werden, sich mit ihren PASSPORT^TM-Referenzen anzumelden (Schritt 152). Wenn der Benutzer kein PASSPORT^TM-Konto besitzt, wird ihm/ihr eine Verknüpfung bereitgestellt, um sich entsprechend anzumelden (Schritt 154). Es ist vorzuziehen, dass der URL zu dem Aktivierungsserver in einer Aktivierungs-ACTIVEX-Steuerung 84, die eine SSL-Verbindung nutzt, fest einprogrammiert ist, so dass der Client garantieren kann, dass die Server tatsächlich die Aktivierungsserver sind.
Wenn sich der Benutzer bei PASSPORT^TM authentifiziert hat (Schritt 156), wird für den Benutzer-Alias und seine E-Mail-Adresse eine PASSPORT^TM-API angefordert (Schritt 158). Anschließend fordert der Aktivierungsserver bei Schritt 160 bis 162 an, dass der Client (über die ACTIVEX-Steuerung) eine einzigartige Hardware-Kennzeichnung hochlädt (die, wie oben aufgeführt, von Hardwarekomponenten auf der Computervorrichtung des Benutzers abgeleitet sein kann, welche im Wesentlichen die Computervorrichtung des Benutzers einzigartig identifizieren). Anschließend wird bestimmt, ob dies eine erste Aktivierung für den Reader 92 ist (Schritt 164). (Unter bestimmten Umständen können Reader mit unterschiedlichen PASSPORT-Kennzeichnungen mehr als einmal aktiviert werden; wenn der Reader 92 mit einer anderen PASSPORT-Kennzeichnung aktiviert wurde, wird ein Warnhinweis angezeigt, wie bei Schritt 166 dargestellt.)
Wenn bei Schritt 164 bestimmt wird, dass dies eine neue Aktivierung ist, wird anschließend bestimmt, ob der Benutzer in den vergangenen 90 Tagen mehr als fünf Reader aktiviert hat. Wenn dies der Fall ist, wird bei Schritt 172 eine Fehlermitteilung angezeigt, die eine Betreuungs-(Support-)Telefonnummer enthält, und der Prozess endet bei Schritt 198. Wie oben bereits festgestellt, ist die Beschränkung auf eine Aktivierung von höchstens fünf Readern in den vergangenen 90 Tagen lediglich beispielhaft. Das Beschränken der Aktivierung von Readern nach Zeit und Anzahl trägt dazu bei, die breite Verbreitung eines eBuch-Titels der Ebene 5 für das Betrachten auf Tausenden (oder Millionen) von Readern auf der ganzen Welt zu verhindern. Die Beschränkung auf „fünf Reader in neunzig Tagen" in dem Beispiel aus 5 ist jedoch lediglich beispielhaft, da andere Beschränkungen der Aktivierung verhängt werden können, ohne von dem Umfang der Erfindung abzuweichen. So kann beispielsweise die in 5 dargestellte Aktivierungsbeschränkung erweitert werden, indem zusätzliche Aktivierungen zulässig sind, nachdem ein vorgegebener Zeitraum abgelaufen ist, beispielsweise jeweils eine zusätzliche Aktivierung nach dem Ablauf eines weiteren Zeitraumes von 90 Tagen bis zu einem Grenzwert von insgesamt 10 Aktivierungen.
Wenn der Benutzer innerhalb der ersten 90 Tage nicht mehr als fünf Reader aktiviert hat (oder nicht auf andere Weise von der Aktivierung des Readers 92 ausgeschlossen ist), wird dem Benutzer eine Aktivierungsseite angezeigt (Schritt 170), die er auszufüllen hat. Wenn der Benutzer das Formular unvollständig abschickt (Erkennung bei Schritt 174), kann die Seite erneut angezeigt werden, bis der Benutzer das Formular vollständig ausfüllt. Anschließend wird bei Schritt 176 bestimmt, ob die vorliegende Aktivierung eine Wiederherstellung ist (das heißt, ein Versuch, einen Reader zu „reaktivieren", der vorher bereits aktiviert wurde, jedoch aus irgendeinem Grund unbrauchbar oder betriebsunfähig geworden ist). Wenn die vorliegende Aktivierung keine Wiederherstellung ist, wird für den Benutzer und den Reader eine neue Aufzeichnung erstellt und die Anzahl der dem Benutzer zugeordneten Reader wird inkrementiert (Schritt 180). Ein vorher erzeugtes Schlüsselpaar für das sichere Repository wird aus einer Datenbank zurückgewonnen (Schritt 182) und es werden ebenfalls Aktivierungszertifikate erzeugt (Schritt 184). (Wie oben beschrieben, kann das Aktivierungszerti fikat ein öffentlich/privates Schlüsselpaar enthalten, dessen privater Schlüssel mit dem öffentlichen Schlüssel des sicheren Repository-Schlüsselpaares verschlüsselt wurde.) Die Aktivierungsschlüssel, die Benutzerkennzeichnung sowie die Computerkennzeichnung werden bei Schritt 186 dauerhaft in einer Datenbank (nicht dargestellt) untergebracht. Vorzugsweise werden die Schlüssel des sicheren Repositorys nicht aufbewahrt, und jedes neue sichere Repository, das in Zukunft erzeugt und geliefert werden muss, besitzt ein neues Schlüsselpaar (und das mit diesem neuen sicheren Repository gelieferte Aktivierungszertifikat kann das aufbewahrte Aktivierungs-Schlüsselpaar enthalten, wobei jedoch der private Schlüssel zu dem (neuen) öffentlichen Schlüssel des (neuen) sicheren Repositorys verschlüsselt wird).
Wenn bei Schritt 176 bestimmt wird, dass diese Aktivierung eine Wiederherstellung ist, wird ein Aktivierungszertifikat erzeugt (Schritt 178), dazu wird das gespeicherte öffentlich/private Schlüsselpaar von einer vorherigen Aktivierung verwendet (das öffentlich/private Schlüsselpaar wird von der Datenbank zurückgewonnen, in der es bei Schritt 186 aufbewahrt wurde) und die Verarbeitung setzt bei Schritt 188 fort.
Bei Schritt 188 erzeugt der/erzeugen die Aktivierungsserver eine ausführbare Datei des sicheren Repositorys 82. Vorzugsweise ist die ausführbare Datei des sicheren Repositorys 82 digital signiert und basiert auf und/oder ist gebunden an eine Computer-Kennzeichnung. Der/die Aktivierungsserver erzeugt/erzeugen ebenfalls ein Aktivierungszertifikat, welches vorzugsweise über die PASSPORT^TM-Kennzeichnung an die Persona des Benutzers gebunden ist. Die ausführbare Datei des sicheren Repositorys 82 und das Aktivierungszertifikat werden anschließend auf den Client heruntergeladen (Schritte 188 und 190). Das Aktivierungszertifikat ist während des Herunterladens verschlüsselt (beispielsweise, um auf die Persona bezogene Informationen zu schützen, die in dem Zertifikat enthalten sind, das an die Persona gebunden ist). Das Aktivierungszertifikat wird während des im Folgenden in Verbindung mit 6 (das heißt, als ein Teil des Prozesses des Erwerbs eines Titels der Ebene 5) beschriebenen Kaufprozesses für das eBuch zu einem späteren Zeitpunkt auf einen „Download-" oder „Erfüllungs"-Server hochgeladen. Die PASSPORT^TM-Kennzeichnung des Benutzers ist verschlüsselt und wird in der PC-Registrierung (wenn der Reader 92 auf einer Rechenvorrichtung installiert ist, die eine Registrierung besitzt) als ein Teil dieses Herunterladevorganges zum Hochladen während kommerzieller Transaktionen gestempelt. Die PASSPORT^TM-Kennzeichnung wird getrennt von dem Aktivierungszertifikat gespeichert (selbst wenn sie in dem Aktivierungszertifikat enthalten sein kann), so dass die gespeicherte PASSPORT-Kennzeichnung mit der PASSPORT-Kennzeichnung in dem Aktivierungszertifikat während des Erwerbs eines Titels der Ebene 5 verglichen werden kann, was dazu bei trägt, einen Diebstahl des Inhaltes zu verhindern.
Bei Schritt 192 wird bestimmt, ob das Herunterladen des sicheren Repositorys 82 und des Aktivierungszertifikates erfolgreich durchgeführt wurde. Ist dies nicht der Fall, wird ein Ereignis protokolliert und es wird ein erneuter Versuch des Herunterladens unternommen (Schritte 194 und 192). Wenn das Herunterladen erfolgreich durchgeführt wurde, kann dem Benutzer bei Schritt 196 eine Seite bereitgestellt werden, die ihm/ihr zur Aktivierung seines/ihres Readers 92 „gratuliert" und ihn/sie darüber informiert, dass der Aktivierungsprozess vollständig durchgeführt wurde. In einem Beispiel kann die Seite Verknüpfungen enthalten, unter denen der Benutzer „Werbe-" oder „freie" eBücher erhalten kann. Diese Verknüpfung ändert sich abhängig von der Werbung (das heißt, der Server kann eine unterschiedliche Seite mit unterschiedlichen Verknüpfungen herunterladen, wenn sich die „Werbung" ändert). Diese Verknüpfung kann darüber hinaus ein Verfahren wirksam einsetzen, welches von der Aktivierungs-ACTIVEX-Steuerung 84 zum Zurückleiten des Benutzers auf die Bibliotheksseite des Readers gezeigt wird. Anschließend endet der Prozess bei Schritt 198.
Prozessablauf des elektronischen Handels
Nunmehr wird in Bezug auf 6 ein Überblick über den grundlegenden Prozess beschrieben, mit dem eBuch-Titel online erworben und geliefert werden. Es wird angemerkt, dass der Reader der vorliegenden Erfindung dafür eingerichtet ist, innerhalb einer Serverumgebung in Wechselwirkung zu treten und zu operieren.
Wenn eine Browsereigenschaft oder die Funktion „integrierter Buchladen" des Readers 92 verwendet wird, besucht der Benutzer eine Einzelhandels-Website und wählt ein Buch oder Bücher auf eine Weise aus, die von dem Händler implementiert wird (Schritt 200). So kann beispielsweise die Website eine Internetseite anzeigen, die verschiedene Bücher (als Verknüpfungen) anzeigt, die der Benutzer möglicherweise erwerben möchte. Der Benutzer bezahlt anschließend für die Titel (Schritt 202), beispielsweise, indem er eine Kreditkartennummer angibt (oder indem er auf eine gespeicherte Kreditkartennummer verweist, wenn der Benutzer ein Konto für diese Website besitzt; bei einer Verwendung kann die PASSPORT-Kennzeichnung des Benutzers auf eine solche Nummer oder ein solches Konto verweisen). Die Transaktion wird bei Schritt 204 mit einer Quittungsseite beendet. (Die Quittungsseite kann Informationen enthalten, die die Bestellung „bestätigen", oder dem Benutzer für seine/ihre Bestellung danken, und sie kann ebenfalls Verknüpfungen (HTTP POST-Anforderungen) zum Herunterladen jedes erworbenen Titels enthalten. Für voll individuali sierte Titel (der Ebene 5) füllt ein clientseitiges Skript über das Internethandelsobjekt 86 den Körper der POST-Anforderung mit dem Aktivierungszertifikat aus. (So wird beispielsweise das Internethandelsobjekt 86 verwendet, um das Aktivierungszertifikat für die Bereitstellung auf der Website des Händlers abzurufen.) In einem Beispiel kann das Aktivierungszertifikat der Händler-Website bereitgestellt werden, die anschließend eine HTTP-Anforderung (das heißt, eine POST-Anforderung) erzeugt, die ein verschlüsseltes Informationspaket (blob) enthält (das heißt, in dem Körper von POST). Die HTTP-Anforderung (einschließlich des verschlüsselten Informationspaketes) wird anschließend als eine Verknüpfung auf der Kunden-Website angezeigt, wobei der Kunde auf die Verknüpfung klickt, um den erworbenen Titel herunterzuladen (wie nachstehend beschrieben). In diesem Beispielszenario enthalten die HTTP-Anforderung und das verschlüsselte Informationspaket (die von dem Händler erzeugt werden, der vorzugsweise mit der Erfüllungs-Website in gemeinsamer Geheimhaltung steht) Informationen, die das bestimmte, dem Käufer bereitzustellende eBuch sowie Informationen umfassen, die der Erfüllungs-Website demonstrieren, dass das verschlüsselte Informationspaket durch einen Händler erzeugt wurde, für den die Erfüllungs-Website sich bereit erklärt hat, eBuch-Aufträge zu erfüllen. Des Weiteren fügt in dem Fall des Erwerbens von Titeln der Ebene 5 die clientseitige Software dem Körper des POST das Aktivierungszertifikat hinzu, um es zu ermöglichen, dass der symmetrische Schlüssel des eBuches zum Verwenden mit dem für die Persona des Benutzers aktivierten Reader verschlüsselt werden kann.
Beim Klicken auf irgendeine der Verknüpfungen bei Schritt 206 initiiert der Browser ein Herunterladen von einem Download- oder „Erfüllungs-" Server, der auf der Quittungsseite spezifiziert ist. Für individuell gekapselte („eingeschriebene") Kopien fügt der Download-Server den Metadaten des Titels den Namen des Verbrauchers hinzu (oder andere identifizierende Informationen, wie von der Einzelhandels-Website bestimmt, beispielsweise die Kreditkartennummer des Benutzers, eine Transaktionskennzeichnung und so weiter) und kapselt den symmetrischen Schlüssel, wozu der neue kryptographische Streuwert verwendet wird, der sich aus den neuen Metadaten ergibt, die nunmehr derartige identifizierende Informationen enthalten. (Die zum Einschließen bestimmten Informationen werden von dem Händler bestimmt und als ein Teil des verschlüsselten Informationspaketes in dem Körper des POST bereitgestellt.) Für voll individualisierte Kopien (der Ebene 5) wird zusätzlich zu dem erzeugten Exlibris eine Lizenz erzeugt und in der LIT-Datei eingebettet. Diese Lizenz enthält den symmetrischen Schlüssel, mit dem die LIT-Datei verschlüsselt wurde, die mit dem öffentlichen Schlüssel in dem Aktivierungszertifikat „gekapselt" wurde. Wenn das Herunterladen beendet ist (Schritt 208), protokolliert der Download-Server die Transaktion und auf dem Client kann der Reader 92 automatisch gestartet werden (Schritt 210). Der Titel kann zu diesem Zeitpunkt in einen lokalen Speicher/LIT-Speicher 98 oder in einen zum Speichern von eBuch-Titeln bestimmten, anderen Ordner oder ein anderes Verzeichnis verschoben werden. Beim Start des Readers 92 kann das eBuch auf der Seite des Deckblattes 100 geöffnet werden.
In Übereinstimmung mit der vorliegenden Erfindung gibt es möglicherweise aus dem Blickwinkel des Endnutzers keinen wahrnehmbaren Unterschied zwischen einem auf der Ebene 3 und einem auf der Ebene 5 geschützten Titel. Beide enthalten ein Exlibris (beispielsweise Einschließen des Namens des Benutzers auf dem Deckblatt 100). Benutzer können lediglich den Unterschied bemerken, wenn sie versuchen, ein eBuch der Ebene 5 auf eine Installation zu verschieben, auf der der Reader 92 für die Persona, die das eBuch erworben hat, nicht aktiviert wurde. In diesem Fall öffnet sich ein Titel der Ebene 5 auf einem solchen Reader 92 nicht, wogegen sich ein Titel der Ebene 3 öffnet.
Kundennutzungsszenarien in dem DRM-System
Die DRM-System Architektur wird durch mehrere Szenarien angetrieben, mit denen Verbraucher von eBüchern wahrscheinlich konfrontiert werden. Beispielhafte Szenarien werden im Folgenden erläutert. Derartige Szenarien enthalten einen Kauf eines Buches aus einem Impuls heraus, das Lesen eines Buches auf mehreren Readern 92, das Aktivieren eines Readers 92 sowie das Wiederherstellen eines verlorenen oder beschädigten Titels. Die Szenarien variieren gemäß der durch den Bereitsteller der Publikation gewählten Ebene des Kopierschutzes. Die Variationen beeinflussen den Benutzer, da sie in einigen Fällen bestimmen, was der Benutzer tun muss, um einen Titel auf einem oder mehreren Readern 92 zu erwerben und zu öffnen.
Kauf eines Buches aus einem Impuls heraus und Lesen
Wenn ein Verbraucher mit einem Internet-Browser oder einer „Buchladen"-Funktion in einer Reader-Anwendung 92 auf der Website eines Händlers surft, kann er oder sie zu kaufende Bücher auswählen (beispielsweise kann ein „Einkaufskorb" aufgebaut werden) und in Übereinstimmung mit den Regeln und/oder Vorgehensweisen der Einzelhandels-Website zur Kasse gehen. Abhängig von der Ebene des Schutzes, die dem ausgewählten Titel zugeordnet ist (und die beispielsweise durch die Einzelhandels-Website oder den Eigentümer von Inhalten festgelegt werden kann, in dessen Namen die Einzelhandels-Website das eBuch vertreibt), kann die Einzelhandels-Website Informationen anfordern, die den Kunden einzigartig identifizieren. (So kann der Händler beispielsweise, wenn der Titel auf der Ebene 3 geschützt ist, den Namen des Benutzers aus einer (vorzugsweise) vertrauenswürdigen Quelle zum Einschließen in den Metadaten abrufen, so dass ein Benutzer einen Titel nicht unter einem falschen Namen erwerben und der Entdeckung entkommen kann, wenn der Titel unrechtmäßig verteilt wird. In diesem Szenario können auch andere Informationen, mittels derer der Käufer nachverfolgt werden kann, beispielsweise die Kreditkartennummer des Benutzers, eine Transaktions-Kennzeichnung und dergleichen, für denselben Zweck verwendet werden.) Ist der Titel auf der Ebene 5 geschützt, benötigt die Einzelhandels-Website auch das Aktivierungszertifikat (das vorzugsweise durch die Verwendung des Internethandelsobjektes 86 und seiner zugehörigen Skripteinbettungsvorrichtung (script wrapper) erhalten wird), um den Inhaltsschlüssel ordnungsgemäß zu verschlüsseln. Wenn der Kunde/Browser nicht in der Lage ist, die erforderlichen Informationen zum Abschließen der Transaktion bereitzustellen, kann die Einzelhandels-Website dem Kunden die Schritte bereitstellen, die erforderlich sind (beispielsweise in der Form einer Internetseite, die die Schritte und ihre Durchführung erläutert und/oder Hyperlinks bereitstellt, denen der Kunde folgen kann). Beim Abschluss der Transaktion ist es vorzuziehen, dass der Kunde eine Quittung, um die Transaktion zu bestätigen (das heißt, eine Bestellbestätigungsseite), oder anderenfalls Fehlerinformationen erhält, die über Probleme bei der Verarbeitung seiner Transaktion in Übereinstimmung mit den Regeln und Vorschriften der Einzelhandels-Website berichten. Anschließend befolgt der Käufer Anweisungen zum Herunterladen, die in der Quittung für die von ihm/ihr erworbenen Bücher eingebettet sind, gemäß den durch die Einzelhandels-Website dargelegten Regeln und Vorschriften. (So kann die Quittung beispielsweise einen Hyperlink enthalten, der durch den Benutzer angeklickt werden kann, um das Herunterladen eines eBuches zu beginnen.) Nachdem das eBuch heruntergeladen wurde, kann es zum Lesen mit dem Reader 92 geöffnet werden.
Lesen eines Buches auf mehreren Readern
Verbraucher erwarten, dass sie in der Lage sind, Titel auf mehr als einer Leseplattform zu lesen, beispielsweise auf einem Arbeitsplatzcomputer, einem Notebook, einem Minicomputer in Handflächengröße (Palmtop) oder auf einer eBuch-Vorrichtung. Das DRM-System der vorliegenden Erfindung trägt für eine derartige Verwendung Sorge. Als ein Teil des DRM-Systems können Herausgeber, Vertriebsunternehmen und Händler Inhaber symmetrischer Schlüssel sein, die zum Verschlüsseln von eBuch-Titeln verwendet werden. Vorzugsweise wird pro Titel oder SKU/ISBN/EAN ein Schlüssel verwendet. Der symmetrische Schlüssel ist zum Öffnen des Titels erforderlich und in der Lizenz/dem DRM-Strom während des Kaufs eingebettet. Der Prozess des Verschlüsselns und späteren Einbettens des symmetrischen Schlüssels wird hierin als „Kapseln" bezeichnet. Es wird angemerkt, dass der symmetrische Schlüssel mit einem öffentlichen Schlüssel verschlüsselt werden kann, der dem Schlüsselpaar des Aktivierungszertifikates des Verbrauchers zugeordnet ist oder in dem Fall von quellen- und individuell gekapselten Kopien mit einem kryptographischen Streuwert der Metadaten verschlüsselt sein kann.
Um den verschlüsselten Titel auf mehreren Readern 92 zu lesen, muss jede Instanz des Readers 92 in der Lage sein, auf den symmetrischen Schlüssel 14A zuzugreifen, der in der Lizenz/dem DRM-Strom des Titels eingebettet ist. In dem Fall geschützter Titel, die nicht voll auf eine Person individualisiert sind (beispielsweise Titel auf den Ebenen 2, 3 oder 4), erfolgt der Zugriff auf den symmetrischen Schlüssel 14A durch Verwenden (beispielsweise Streuen (hashing)) der zu entkapselnden Metadaten des Titels und möglicherweise Entschlüsseln des symmetrischen Schlüssels 14A, dies wird vorzugsweise von dem DRM-Verwalter 80 vorgenommen. In diesem Szenario verschlüsselt der Händler/das Vertriebsunternehmen des Titels den symmetrischen Schlüssel 14A mit einem kryptographischen Streuwert, der programmatisch aus einem Streuwert der Metadaten des Titels erzeugt wird (diese können beispielsweise in dem Fall von Titeln der Ebene 3 den Namen des rechtmäßigen Eigentümers enthalten). Der Reader 92 und/oder der DRM-Verwalter 80 verwenden dann denselben Streuwert-Algorithmus zum Entkapseln des symmetrischen Schlüssels. Benutzer, die die Inhalte der Metadaten des Titels manipulieren, sind dann nicht mehr in der Lage, den eBuch-Titel zu lesen, da die Lesesoftware nicht in der Lage ist, den symmetrischen Schlüssel 14A zu entschlüsseln/entkapseln, da die neuen Metadaten einen anderen Streuwert ergeben.
In dem Fall von voll individualisierten Titeln (der Ebene 5) wird der symmetrische Schlüssel 14A mit dem öffentlichen Schlüssel des Aktivierungszertifikates des Benutzers verschlüsselt und in die Lizenz eingefügt, wobei die Lizenz vor dem Herunterladen in den DRM-Speicher 14 in Strom 14A eingefügt wird (siehe 4). Wie oben beschrieben, besitzt jeder für eine bestimmte Persona aktivierte Reader 92 ein Aktivierungszertifikat, das das der Persona zugeordnete, öffentlich/private Schlüsselpaar enthält. Somit kann ein Titel auf jedem Reader 92 gelesen werden, der für eine bestimmte Persona aktiviert wurde. Wie oben beschrieben, wird das Aktivierungszertifikat während des Aktivierungsprozesses erhalten. Die oben erwähnte „Lizenz", die im Folgenden diskutiert wird, ist ein Konstrukt, das die Rechte definiert, die der Verbraucher beim Erwerben des Inhaltes ausüben kann, und wenn sie vorliegt, enthält sie auch den Inhaltsschlüssel (das heißt, den symmetrischen Schlüssel).
Die Clientarchitektur 90' entschlüsselt den verschlüsselten symmetrischen Schlüssel, der in der Lizenz eines Titels der Ebene 5 enthalten ist, indem sie den privaten Schlüssel aus dem Aktivierungszertifikat anwendet, wobei der private Schlüssel des Aktivierungszertifikates in verschlüsselter Form gespeichert ist und erhalten wird, indem das sichere Repository 82 verwendet wird, um seinen privaten Schlüssel auf den verschlüsselten privaten Schlüssel anzuwenden, wie oben diskutiert. Neben dem Sicherstellen, dass ein Reader 92 mit den Referenzen (das heißt, mit der Persona) aktiviert wurde, für die ein Titel der Ebene 5 vorbereitet wurde, ist keine andere Maßnahme erforderlich, um es einem Benutzer zu ermöglichen, einen Titel auf mehreren Readern 92 zu lesen. Darüber hinaus findet selbst in dem Fall von Titeln der Ebene 5 die Maßnahme des Sicherstellens, dass der Reader für die korrekte Persona aktiviert wurde, unbedingt statt – das heißt, wenn der Reader 92 nicht für die Person aktiviert wurde, der ein Titel der Ebene 5 zugehörig ist, dann besitzt der Reader 92 keinen Zugriff auf das Aktivierungszertifikat (und seinen privaten Schlüssel), das es dem Reader ermöglicht, auf den symmetrischen Schlüssel 14A zuzugreifen, der zum Entschlüsseln des Inhaltsstromes 16 benötigt wird. Bei allen Titeln der Ebene 5, die für einen Reader 92 erworben wurden, ist ihr Inhaltsschlüssel in dem öffentlichen Schlüssel verschlüsselt, der in dem Aktivierungszertifikat enthalten ist, das dem Reader/der Persona zugeordnet ist. Wenn der Benutzer weitere Reader 92 installiert oder erwirbt, muss der Benutzer nur den neuen Reader mit derselben Persona aktivieren, um dasselbe Aktivierungszertifikat zu erhalten (oder genauer gesagt, ein gleichwertiges Aktivierungszertifikat mit demselben öffentlich/privaten Schlüsselpaar, dessen privater Schlüssel, wie oben diskutiert, mit dem öffentlichen Schlüssel des sicheren Repositorys verschlüsselt wurde, das sich auf der neuen Lesevorrichtung/Installation befindet).
Als eine weitere Alternative kann der symmetrische Schlüssel 14A auch von einer OpenCard erhalten werden. OpenCards enthalten jeweils einen Schlüssel oder ein Schlüsselpaar, auf das Titel gekapselt sind. Wenn der Benutzer denselben Titel auf einem unterschiedlichen Reader 92 lesen möchte, muss der Reader 92 auf einer Vorrichtung installiert sein, die einen Steckplatz (slot) für eine OpenCard besitzt. Wenn also der Benutzer die OpenCard in die Vorrichtung einsetzt, sind die Titel automatisch zum Lesen verfügbar. Somit sind keine speziellen Schritte erforderlich, wenn Benutzer OpenCard-basierte Titel auf mehreren Readern 92 lesen möchten, da der Titel tatsächlich an die Karte und nicht an ein bestimmtes Aktivierungszertifikat und/oder eine bestimmte Persona gebunden ist.
Aktualisieren oder Ersetzen des Readers
Wenn ein Benutzer seinen/ihren Reader verliert, ersetzt oder aktualisiert, ist es wichtig, dass der Benutzer in der Lage ist, vorher erworbene Titel (beispielsweise Titel der Ebene 5) auf dem neuen Reader zu lesen. Gemäß einem Aspekt der Erfindung wird der Benutzer in die Lage versetzt, vorher erworbenen Inhalt auf neuen Readern 92 zu lesen, indem dieselben Mechanismen durchgeführt werden, die es ihnen ermöglichen, auf mehreren Readern 92 zu lesen: der neue Reader 92 erwirbt das erforderliche Aktivierungszertifikat (das heißt, ein Aktivierungszertifikat mit dem Schlüsselpaar, das in vorangehenden Aktivierungszertifikaten enthalten war, die für die Persona des Benutzers ausgestellt wurden).
Das Durchsetzen eines Grenzwertes der Anzahl von Aktivierungen von Readern 92 auf die oben beschriebene Weise vereinfacht den Prozess des Aktualisierens/Ersetzens. Solange der Benutzer den jeweils geltenden Grenzwert der Aktivierungen nicht überschritten hat, kann er einen neuen/aktualisierten/Ersatz-Reader 92 genau so aktivieren, als würde ein weiterer, im Besitz dieses Benutzers befindlicher Reader aktiviert. Ein Benutzer kann eine Aktivierung eines alten Readers „unterdrücken", indem er das Aktivierungszertifikat löscht; dies erhöht jedoch nicht notwendigerweise die Anzahl verfügbarer Aktivierungen für eine bestimmte Persona, da die Aktivierungsautorität (beispielsweise der Aktivierungsserver, mit dem der Benutzer Kontakt aufnimmt, um Aktivierungszertifikate und sichere Repositorys 82 zu erhalten) nicht notwendigerweise eine Möglichkeit hat zu überprüfen, dass das Aktivierungszertifikat gelöscht wurde oder nicht auf eine rettbare Weise gesichert wurde. Daher „setzt" in einer Ausführungsform der Erfindung das Löschen des Aktivierungszertifikates die Umgebungsbeschränkung für neue Aktivierungen für eine bestimmte Persona nicht „zurück".
Wiederherstellen eines verlorenen oder beschädigten Titels
Ein Benutzer kann Titel sichern, indem er beispielsweise die eBuch-Datei 10 auf eine wechselbare Magnetscheibe 29, eine optische Scheibe 31 oder eine wechselbare, nichtflüchtige Speicherkarte kopiert. Gehen die Titel im Hauptspeicher einer bestimmten Lesevorrichtung verloren oder werden sie beschädigt, können die Titel aus dem Sicherungsspeicher wiederhergestellt werden. In dem Fall jedoch, in dem Titel aus irgendeinem Grund nicht gesichert wurden, kann es möglich sein, jeden verlorenen oder beschädigten Titel über den Händler wiederherzustellen. So kann der Benutzer beispielsweise die Quittungsseite von einem erworbenen Titel aufbewahren (das heißt, die Seite, die die Verknüpfungen zum Herunterla den enthält) und die Verknüpfung einfach „erneut besuchen", um mit einem Download-Server Verbindung aufzunehmen, um eine neue Kopie der eBuch-(„LIT")-Datei 10 zu erhalten, die den Titel verkörpert. Benutzer können ihre Quittungen lokal aufbewahren, alternativ dazu kann der Einzelhandelsladen seinen Kunden den Service anbieten, ihre Quittungen auf dem Server des Händlers aufzubewahren.
In einer bevorzugten Ausführungsform der Erfindung haben Quittungen jedoch ein Ablaufdatum/eine Ablaufzeit (beispielsweise kann das verschlüsselte Informationspaket, das der Verknüpfung zugeordnet ist, die angeklickt wird, um mit dem Download-Server Kontakt aufzunehmen, ein Ablaufdatum/eine Ablaufzeit enthalten), sodass das Anklicken einer Verknüpfung zum Herunterladen nach Ablauf eines vorgegebenen Zeitraumes nach dem Ausstellen der Verknüpfung (beispielsweise eine Stunde) bewirkt, dass der Download-Server das Herunterladen des Titels verweigert. In diesem Fall kann der Händler eine Aufzeichnung des Erwerbens besitzen und kann eine neue Kopie der Quittung/Verknüpfung zum Herunterladen bereitstellen. Zum Wiederherstellen eines verlorenen oder beschädigten eBuch-Titels muss der Benutzer mit dem Händler Kontakt aufnehmen, von dem der eBuch-Titel erworben wurde. Nachdem der Benutzer identifiziert wurde, legt die Händler-Website dem Benutzer eine Liste von Quittungen vor, aus denen der Benutzer die korrekte auswählt. Der Benutzer kann anschließend den Titel lokalisieren, den er wiederherzustellen wünscht, und auf die zum Herunterladen bereitgestellte Verknüpfung klicken. Abgesehen von restriktiven Maßnahmen seitens der Händler-Website sollte der Benutzer in der Lage sein, den verlorenen eBuch-Titel erneut herunterzuladen. Es ist im Allgemeinen nicht notwendig, dass der Händler das erneute Herunterladen von Titeln einschränkt, da der Benutzer zu jeder Zeit die Möglichkeit hatte, den Titel von einem zum anderen Computer zu kopieren (dies unterliegt selbstverständlich der Bedingung, dass Titel der Ebene 5 auf Readern nicht funktionieren, die für eine andere Persona als die Persona, die den Titel erworben hat, aktiviert wurden), somit stellt das Verhindern des erneuten Herunterladens eines Titels keinen zusätzlichen Kopierschutz bereit. Es muss jedoch beachtet werden, dass die Entscheidung, kostenlose Privilegien des „erneuten Herunterladens" bereitzustellen, allein im Ermessen des Händlers liegt, da der Händler das erneute Herunterladen als einen Dienst betrachten kann, für den er eine Gebühr zu erheben wünscht.
Unterstützung mehrerer aktivierter Reader auf demselben PC
Es ist vorzuziehen, dass der Reader für Notebook- und Arbeitsplatzcomputer so hergestellt ist, dass er die gemeinsame Verwendung eines Computers durch mehrere Benutzer unters tützt. Solange die Benutzer unterschiedliche lokale Konten auf dem PC besitzen, den sie gemeinsam nutzen, kann der Reader alle benutzerspezifischen Daten in dem geeigneten Benutzerdaten-Raum speichern, abgegrenzt durch ihre jeweiligen Profile und Registrierungswerte „aktueller Benutzer". So können beispielsweise eBuch-Dateien 10 für jeden Benutzer in einem Verzeichnis gespeichert werden, das logisch in dem Verzeichnis der obersten Ebene für dieses Benutzerprofil gespeichert ist. In dem Fall des Aktivierungsprozesses kann der Prozess sicherstellen, dass der Reader 92 aktiviert wird und dass die heruntergeladenen Komponenten (beispielsweise das sichere Repository 82 und das Aktivierungszertifikat) an den aktuellen Benutzer gebunden sind (beispielsweise den derzeit auf einem Arbeitsplatzrechner angemeldeten Benutzer, der das Betriebssystem MICROSOFT WINDOWS NT ausführt).
Sobald der Reader aktiviert ist kann er des Weiteren den PASSPORT^TM-Namen für den Benutzer anzeigen, für den er aktiviert wurde, beispielsweise auf einem Splash-Screen und einer Seite „Schnelleinstellungen" (quick settings). Auf der Seite „Schnelleinstellungen" wird der PASSPORT^TM-Name desjenigen Benutzers, der den Reader zuletzt aktiviert hat, sofort über der Aktivierungs-Verknüpfung angezeigt. Dies ermöglicht eine ordnungsgemäße Abwicklung durch das clientseitige Internethandelsobjekt 86 des Aktivierungszertifikates und ein verschlüsseltes Hochladen der PASSPORT^TM-Kennzeichnung während des Einkaufsprozesses für voll individualisierte (auf der Ebene 5 geschützte) Titel.
Der Prozess, mit dem mehrere Benutzer denselben Reader 92 auf einem beispielhaften, gemeinsam genutzten System aktivieren können, läuft wie folgt ab. Der Reader prüft während des Hochfahrens, ob er aktiviert wurde. Diese Prüfung wird durchgeführt, indem unter HKEY_CURRENT_USER\Software\Microsoft\eBuch\ nach einem Registrierungsschlüssel (RegKey) „AktivierungAbgeschlossen" (ActivationComplete) gesucht wird. Da dieser Registrierungsschlüssel in den HKCU-Zweig (HKCU branch) geschrieben wird, wird sichergestellt, dass er benutzerspezifisch und an den derzeit auf dem Computer angemeldeten Benutzernamen gebunden ist. Wenn dieser Registrierungsschlüssel nicht gefunden wird oder nicht auf 1 gesetzt ist (das heißt, es hat eine erfolgreiche Aktivierung stattgefunden), folgt der Benutzer den Schritten zum Aktivieren des Readers, wie oben diskutiert. Nachdem das Herunterladen beendet ist, fragt die Aktivierungs-ACTIVEX-Steuerung 84 bei dem Betriebssystem den Benutzernamen für den derzeit auf dem Computer angemeldeten Benutzer ab. Wird kein Benutzername zurückgegeben, wird „StandardBenutzer" (DefaultUser) als der Benutzername angenommen.
Anschließend fragt die ACTIVEX-Steuerung 84 die Registrierung ab, um herauszufinden, wo der Reader installiert wurde. Danach erstellt sie ein Verzeichnis im MS-Reader-Installationsverzeichnis mit dem Namen:.\<Benutzername>\SicheresRepository (<Benutzername>, wie durch die Betriebssystemabfrage bestimmt). Wenn das Verzeichnis erzeugt wurde, setzt die ACTIVEX-Steuerung 84 den Schlüssel HKCU\..\eBuch\SicheresRepository mit dem vollständigen Pfad zu dem entsprechenden Verzeichnis ein. In diesem Verzeichnis installiert die ACTIVEX-Steuerung 84 das sichere Repository 82 und das Aktivierungszertifikat. Anschließend führt sie das sichere Repository 82 mit dem Parameter „-install” für eine Selbstregistrierung des sicheren Repositorys 82 aus. Unter der Annahme, dass alle oben genannten Schritte erfolgreich durchgeführt wurden, stempelt die ACTIVEX-Steuerung 84 den Registrierungsschlüssel AktivierungAbgeschlossen (ActivationComplete).
Lizenzformat
Es folgt eine beispielhafte Lizenz, die für jedes Herunterladen voll individualisierter Titel verwendet wird. Die Lizenz ist ein Konstrukt, das die Rechte definiert, die der Benutzer beim Erwerb des Titels ausüben kann, zusätzlich zu der Definition der Anforderungen zum Entkapseln des symmetrischen Schlüssels zum Ausüben dieser Rechte. Beispiele für „Rechte", die in der Lizenz dargestellt werden können, umfassen Wiedergeben des Inhaltes (beispielsweise bei dem Beispiel von Textinhalt das Lesen desselben auf dem Bildschirm eines PC), Ausdrucken des Inhaltes oder Kopieren und Einfügen von Teilen des Inhaltes. Es wird angemerkt, dass das beispielhafte Lizenzformat nicht dafür vorgesehen ist, den Umfang der vorliegenden Erfindung einzuschränken, da andere Lizenzformate mit mehr oder weniger umfangreichen Informationen möglich sind.
Es ist vorzuziehen, dass die zum Darstellen einer Lizenz ausgewählte Sprache XML ist und dass das Format der Lizenz auf den Spezifikationen der erweiterten Auszeichnungssprache für Rechte (Extended Rights Markup Language – XrML) beruht. Dies ist eine gut geeignete Auszeichnungssprache zum Beschreiben von Verwendungsrechten auf eine flexible Weise. XrML stellt des Weiteren eine umfassende Interoperabilität bereit und ermöglicht es, dass jede Investition in Technologie, die für Komponenten getätigt wurde, die diese Lizenzen erzeugen und verwalten, lange Zeit wirksam eingesetzt werden kann. In einer bevorzugten Ausführungsform werden nur diejenigen Rechte gewährt, die in der Lizenz ausdrücklich genannt werden – das heißt, wenn eine Berechtigung nicht ausdrücklich gewährt wurde, wird sie verweigert. Personen mit gewöhnlicher Erfahrung auf dem Gebiet der Technik erkennen jedoch, dass auch andere Regelungen möglich sind, beispielsweise dann, wenn eine stan dardmäßige Reihe von Rechten angenommen wird, wenn von der Lizenz nicht ausdrücklich verweigert oder modifiziert.
Die Auszeichner (tags) der oberen Ebene in einem kollabierten Format sind wie folgt:
Die erste Zeile der oben stehenden XrML-Struktur definiert die Version der XML-Sprache, die zum Erzeugen der XrML-Lizenz verwendet wurde. Die zweite Zeile spezifiziert den Namen der zum Analysieren (Parsen) der XML-Datei verwendeten DTD-Datei. Der Auszeichner BODY (KÖRPER) stellt die Art der Lizenz, die Version der XrML-Spezifizierung, die verwendet wurde, als die Lizenz erzeugt wurde, sowie das Ausstellungsdatum bereit. Es ist auch der Meta-Auszeichner (meta-tag) für die gesamte Lizenz, die folgende untergeordnete Abschnitte besitzt: WORK (WERK), LICENSOR (LIZENZGEBER), LICENSEDPRINCIPALS (LIZENZIERTE AUFTRAGGEBER) und SIGNATURE (SIGNATUR). WORK enthält alle semantischen Informationen über die Lizenz, einschließlich der Verwendungsrechte. Die Inhalte dieses Bereiches (einschließlich der Auszeichner) stellen die Daten dar, die gestreut und signiert werden. LICENSOR enthält Informationen bezüglich der Instanz, die die Lizenz ausgestellt hat, üblicherweise ein Händler. LICENSEDPRINCIPALS enthält eine Reihe von Auftraggebern (principals), die authentifiziert werden müssen, wenn die in einer Lizenz spezifizierten Verwendungsrechte ausgeübt werden sollen. SIGNATURE enthält den Streuwert/Digest aus dem Auszeichner LICENSEBODY (LIZENZKÖRPER) sowie Informationen darüber, wie der Streuwert erzeugt wurde, einschließlich des verwendeten Algorithmus. Sie umfasst ebenfalls das DIGEST, das in Übereinstimmung mit dem durch den Lizenzgeber beim Ausstellen der Lizenz benannten Algorithmus verschlüsselt wurde. Die Auszeichner DIGEST und SIGNATURE stellen die Authentifizierungsinformationen bereit, die verwendet werden, um die gesamte Lizenz auf eine Weise, die manipulationssicher ist, für gültig zu erklären.
Struktur des Auszeichners BODY (Körper)
Der Hauptauszeichner eines XrML-Lizenzkonstruktes ist der Auszeichner BODY (Körper), der die folgenden Auszeichner enthält:
Lizenz-Authentizität
Das sichere Repository 82 authentifiziert eine Lizenz über die Auszeichner SIGNATUR und DIGEST. Dies ist so, dass die Clientsoftware validieren kann, dass der Inhalt, der wiedergegeben wird, aus einer vertrauenswürdigen Quelle stammt. Ein ausführlicheres Beispiel dieser Auszeichner wird im Folgenden bereitgestellt:
Es wird angemerkt, dass die vorangehenden Beispiele lediglich zum Zweck der Erläuterung bereitgestellt wurden und in keiner Weise als die vorliegende Erfindung in irgendeiner Weise begrenzend aufgefasst werden dürfen. Während die Erfindung in Bezug auf verschiedene Ausführungsformen beschrieben wurde, ist es wohlverstanden, dass die Worte, die hierin verwendet wurden, Worte der Beschreibung und Darstellung sind und nicht Worte der Beschränkungen. Obwohl des Weiteren die Erfindung hierin in Bezug auf bestimmte Einrichtungen, Materialien und Ausführungsformen beschrieben wurde, ist es nicht vorgesehen, dass die Erfindung auf die hierin offenbarten Einzelheiten beschränkt ist; stattdessen erstreckt sich die Erfindung auf alle funktional gleichwertigen Strukturen, Methoden und Verwendungen, soweit sich diese innerhalb des Umfanges der beigefügten Ansprüche befinden. Personen mit gewöhnlicher Erfahrung auf dem Gebiet der Technik können mithilfe des Nutzens aus den Lehren dieser Spezifizierung zahlreiche Modifikationen daran vornehmen und Änderungen können erfolgen, ohne von dem Umfang der Erfindung in ihren Aspekten abzuweichen.

Claims

Rechenvorrichtung (20, 49), die so eingerichtet ist, dass sie über eine Netzwerk-Infrastruktur (51, 52) kommuniziert, wobei sie umfasst: eine Langzeit-Speichervorrichtung (22, 27, 29, 31, 62, 98); eine Benutzerschnittstelle, die so eingerichtet ist, dass sie mit der Rechenvorrichtung in Wechselwirkung tritt und eine Rendering-Anwendung (92) startet (210); ein Verwaltungs-Modul (80), das eine Datenübertragung von der Rendering-Anwendung empfängt, um auf erste Informationen (10, 100) zuzugreifen, die in der Langzeit-Speichervorrichtung gespeichert sind (210); und ein Repository (82), das über die Netzwerk-Infrastruktur empfangen werden kann und eine Schnittstelle mit dem Verwaltungs-Modul erhalten kann, wobei die ersten Informationen in einem mit einem symmetrischen Schlüssel verschlüsselten Format gespeichert sind, wobei der symmetrische Schlüssel mit einem ersten öffentlichen Schlüssel verschlüsselt wird, wobei ein erster privater Schlüssel, der dem ersten öffentlichen Schlüssel entspricht, mit einem zweiten öffentlichen Schlüssel verschlüsselt wird, wobei das Repository einen zweiten privaten Schlüssel, der von dem Repository gehalten wird und dem zweiten öffentlichen Schlüssel entspricht, verwendet, um den verschlüsselten ersten privaten Schlüssel zu entschlüsseln, wobei der entschlüsselte erste private Schlüssel verwendet wird, um den verschlüsselten symmetrischen Schlüssel zu entschlüsseln, und wobei das Verwaltungs-Modul den entschlüsselten symmetrischen Schlüssel zurückführt, der die Verwendung der ersten Informationen durch die Rendering-Anwendung ermöglicht.
Rechenvorrichtung nach Anspruch 1, wobei die zweiten Informationen bezüglich eines Benutzers oder einer Transaktion durch das Verwaltungs-Modul zu der Rendering-Anwendung zur Verwendung in der Rechenvorrichtung zurückgeführt werden.
Rechenvorrichtung nach Anspruch 2, wobei die zweiten Informationen aus der Gruppe ausgewählt werden, die aus einem Namen, einer Kreditkartennummer und einer Quittungsnummer besteht.
Rechenvorrichtung nach einem der Ansprüche 1 bis 3, wobei das Verwaltungs-Modul die Rendering-Anwendung vor dem Zurückführen der ersten Daten authentifiziert.
Computerlesbares Medium (22, 27, 29, 31, 62, 98), das durch Computer ausführbare Befehle zum Durchführen von Vorgängen aufweist, die umfassen: Authentifizieren von Software (36, 36, 37, 92); und Bereitstellen wenigstens eines kryptographischen Dienstes für die Software, wobei die durch Computer ausführbaren Befehle zum Durchführen des wenigstens einen kryptographischen Dienstes durch einen Aufruf von der Software aufgerufen werden können, um auf erste Informationen zuzugreifen, die in einem mit einem symmetrischen Schlüssel verschlüsselten Format gespeichert sind, wobei der symmetrische Schlüssel mit einem ersten öffentlichen Schlüssel verschlüsselt wird, wobei ein erster privater Schlüssel, der dem ersten öffentlichen Schlüssel entspricht, mit einem zweiten öffentlichen Schlüssel verschlüsselt wird, wobei der Vorgang des Bereitstellens wenigstens eines kryptographischen Dienstes umfasst: Ausgeben eines Aufrufs an ein Repository (82), wobei das Repository über ein Netzwerk empfangen werden kann und einen von dem Repository gehaltenen zweiten privaten Schlüssel, der dem zweiten öffentlichen Schlüssel entspricht, verwendet, um den verschlüsselten ersten privaten Schlüssel zu entschlüsseln; Anwenden des entschlüsselten ersten privaten Schlüssels, um den verschlüsselten symmetrischen Schlüssel zu entschlüsseln; und Zurückführen des entschlüsselten symmetrischen Schlüssels, der die Verwendung der ersten Informationen durch die Software ermöglicht.
Computerlesbares Medium nach Anspruch 5, wobei der wenigstens eine kryptographische Dienst das Entkapseln gekapselter Daten umfasst.
Computerlesbares Medium nach Anspruch 6, wobei die gekapselten Daten den symmetrischen Schlüssel umfassen.
Computerlesbares Medium nach Anspruch 6 oder 7, wobei die gekapselten Daten zweite Informationen umfassen, die mit dem Benutzer verknüpft sind, für den Inhalt lizenziert wird.
Computerlesbares Medium nach Anspruch 8, wobei die zweiten Informationen aus der Gruppe ausgewählt werden, die aus einem Namen, einer Kreditkartennummer und einer Quittungsnummer besteht.