DE102009017221A1 - Information-Rights-Management - Google Patents

Information-Rights-Management Download PDF

Info

Publication number
DE102009017221A1
DE102009017221A1 DE102009017221A DE102009017221A DE102009017221A1 DE 102009017221 A1 DE102009017221 A1 DE 102009017221A1 DE 102009017221 A DE102009017221 A DE 102009017221A DE 102009017221 A DE102009017221 A DE 102009017221A DE 102009017221 A1 DE102009017221 A1 DE 102009017221A1
Authority
DE
Germany
Prior art keywords
license
licensor
key
policy
content key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102009017221A
Other languages
English (en)
Inventor
Dmitry Redmond Starostin
Joris Redmond Claessens
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of DE102009017221A1 publication Critical patent/DE102009017221A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]

Abstract

dazu, die Nutzung von Informationen innerhalb eines Datenobjektes zu schützen. Es wird ein IRM-System geschaffen, das Zugriff auf ein Datenobjekt nach wenigstens zwei Interaktionen mit einer oder mehreren Lizenzierungsinstanz/en zulässt. In einigen Beispielen können die Lizenzierungsinstanzen jeweils eine Lizenz erteilen, die einen Teil der Informationen beinhaltet, die zum Zugreifen auf das Datenobjekt erforderlich sind. Jeder Teil der Lizenz kann einem Teil einer Nutzungsrichtlinie entsprechen. Beispielsweise kann eine erste Lizenzierungsinstanz eine Lizenz zum Zugreifen auf ein Dokument auf Basis einer Voraussetzung erteilen, und eine zweite Lizenzierungsinstanz kann eine Lizenz auf Basis einer anderen Voraussetzung erteilen. In anderen Beispielen kann eine Lizenzierungsinstanz eine zweite Lizenzierungsinstanz auffordern, eine Validierung durchzuführen, bevor sie eine Nutzungslinzenz erteilt.

Description

  • Hintergrund
  • Information-Rights-Management-Systeme, kurz IRM-Systeme, werden eingesetzt, um die Nutzung vertraulicher Dokumente abzusichern. Üblicherweise steuern diese Systeme Zugriff auf ein Datenobjekt, indem eine Richtlinie definiert wird, die angibt, welche Individuen oder Gruppen von Individuen Zugriff auf das Datenobjekt, beispielsweise ein Dokument, haben sollten, und welche Zugriffsstufe zugelassen werden sollte (beispielsweise kann ein Individuum/eine Gruppe Lesezugriff haben, während ein anderes Individuum bzw. eine andere Gruppe Schreib-/Bearbeitungszugriff auf das Dokument hat). Ein durch IRM geschütztes Dokument wird unter Verwendung eines Inhaltsschlüssels verschlüsselt, und dieser Schlüssel wiederum wird zusammen mit der Richtlinie mit einem Schlüssel eines Lizenzgeberdienstes verschlüsselt. Wenn ein Nutzer auf das Dokument zugreifen möchte, werden der verschlüsselte Inhaltsschlüssel und Richtlinien-Daten als Teil einer „Nutzungslizenz”-Anforderung zu dem Lizenzgeberdienst (normalerweise einem Remote-Server) gesendet. Der Lizenzgeber kann Nutzungslizenzen an Nutzer ausgeben, die die in der Richtlinie festgelegten Voraussetzungen erfüllen. Die Nutzungslizenz macht den Inhaltsschlüssel für den Nutzer verfügbar und beinhaltet die Gruppe von Rechten, über die dieser spezielle Nutzer gemäß der Richtlinie verfügt.
  • Bei derartigen bekannten Systemen gibt es einen einzelnen Entscheidungspunkt, d. h. den Punkt, an dem der Lizenzgeber eine Anforderung von einem Nutzer beurteilt und feststellt, ob eine Lizenz erteilt werden sollte oder nicht. Dadurch wird die Flexibilität des Systems eingeschränkt.
  • Die im Folgenden beschriebenen Ausführungsformen sollen nicht auf Implementierungen beschränkt werden, die einen beliebigen oder alle der Nachteile bekannter IRM-Systeme beheben.
  • Zusammenfassung
  • Es folgt eine vereinfachte Zusammenfassung der Offenbarung, die dem Leser ein grundlegendes Verständnis ermöglicht. Diese Zusammenfassung ist kein ausführlicher Überblick über die Offenbarung und identifiziert keine wichtigen/entscheidenden Elemente der Erfindung und umreißt auch den Schutzumfang der Erfindung nicht. Sie dient lediglich dazu, einige der offenbarten Prinzipien in vereinfachter Form darzustellen und dient als Einleitung für die später folgende ausführliche Beschreibung.
  • Information-Rights-Management (IRM)-Systeme dienen dazu, die Nutzung von Informationen innerhalb eines Datenobjektes zu schützen. Dies kann beispielsweise umfassen, dass es einem einzelnen Nutzer oder Klasse von Nutzern gestattet wird, ein Dokument zu betrachten, jedoch nicht, es zu bearbeiten oder auszudrucken. Es wird ein IRM-System geschaffen, das Zugriff auf ein Datenobjekt nach wenigstens zwei Interaktionen mit einer oder mehreren Lizenzierungsinstanz/en gestattet. In einigen Beispiele können die Lizenzierungsinstanzen jeweils eine Lizenz erteilen, die einen Teil der Informationen beinhaltet, die zum Zugriff auf das Datenobjekt erforderlich sind. Jeder Teil der Lizenz kann einem Teil einer Nutzungsrichtlinie für ein Datenobjekt entsprechen. Beispielsweise kann eine erste Lizenzierungsinstanz eine Lizenz zum Zugreifen auf ein Dokument auf Basis einer Voraussetzung (beispielsweise Mitgliedschaft in einer bestimmten Gruppe) erteilen, und eine zweite Lizenzierungsinstanz kann eine Lizenz auf Basis einer anderen Voraussetzung (beispielsweise dem Standort des Nutzers, der Zugriff anfordert) erteilen. In anderen Beispielen kann eine Lizenzierungsinstanz eine zweite Lizenzierungsinstanz auffordern, eine Validierung durchzuführen, bevor sie eine Nutzungslizenz erteilt.
  • Viele der weiteren Merkmale werden deutlicher, wenn sich ein besseres Verständnis durch Bezugnahme auf die folgende ausführliche Beschreibung im Zusammenhang mit den beigefügten Zeichnungen ergibt.
  • Beschreibung der Zeichnungen
  • Die vorliegende Beschreibung wird beim Lesen der folgenden detaillierten Darstellung im Zusammenhang mit den beigefügten Zeichnungen besser verständlich, wobei:
  • 1 ein Schema einer Vorrichtung für ein beispielhaftes bekanntes IRM-System ist;
  • 2 ein Flussdiagramm eines Verfahrens zum Erteilen einer Lizenz in einem bekannten IRM-System ist;
  • 3 ein Schema einer Vorrichtung für ein verallgemeinertes IRM-System ist;
  • 4 ein Flussdiagramm eines Verfahrens zum Erteilen einer Lizenz in dem IRM-System in 3 ist;
  • 5 ein Schema einer Vorrichtung für ein IRM-System ist;
  • 6 ein Flussdiagramm eines Verfahrens zum Erteilen einer Lizenz in dem IRM-System in 5 ist;
  • 7 ein Schema einer Vorrichtung für ein IRM-System ist;
  • 8 ein Flussdiagramm eines Verfahrens zum Erteilen einer Lizenz in dem IRM-System in 7 ist;
  • 9 ein Schema einer Vorrichtung für ein IRM-System ist;
  • 10 ein Flussdiagramm eines Verfahrens zum Erteilen einer Lizenz in dem IRM-System in 9 ist;
  • 11 ein Schema einer Vorrichtung für ein IRM-System ist;
  • 12 ein Flussdiagramm eines Verfahrens zum Ausgeben einer Lizenz in dem IRM-System in 11 ist; und
  • 13 eine beispielhafte computerbasierte Einrichtung darstellt, in der die Ausführungsformen aus 3 bis 12 implementiert werden können.
  • In den beigefügten Zeichnungen werden gleiche Bezugszeichen zur Kennzeichnung gleicher Teile verwendet.
  • Ausführliche Beschreibung
  • Die folgende mit den beigefügten Zeichnungen zusammenhängende Beschreibung ist als eine Beschreibung der vorliegenden Beispiele zu verstehen und nicht als Darstellung der einzigen Formen, in denen die vorliegenden Beispiele aufgebaut oder eingesetzt werden können. Die Beschreibung legt die Funktionen des Beispiels sowie die Abfolge von Schritten dar, mit denen das Beispiel aufgebaut und betrieben wird. Es können jedoch die gleichen oder äquivalente Funktionen und Abläufe mit anderen Beispielen umgesetzt werden.
  • Der hier verwendete Terminus „Informationsrechte-Richtlinie” bezieht sich auf eine oder mehrere Bedingung/en oder Kriterien, die erfüllt sein müssen, bevor einem Nutzer das Recht gewährt wird, eine Gruppe angegebener Vorgänge an Daten auszuführen, so beispielsweise „Lesen”, „Schreiben”, „Drucken” und „Weiterleiten”. Dies stellt einen Unter schied zu Richtlinien dar, die lediglich dazu verwendet werden können, zu steuern, ob Daten von einer Quelle bezogen werden können, ohne dass später an diese Daten ausgeführte Vorgänge gesteuert werden.
  • 1 zeigt ein bekanntes beispielhaftes Information-Rights-Management (IRM)-System, das einen IRM-Server 100, einen Identitäts-Provider 102, einen Veröffentlicher 103 und einen Empfänger 106 umfasst, die sämtlich über ein Kommunikationsnetzwerk verbunden sind. Der Veröffentlicher 103 umfasst einen IRM-Client 105 sowie eine IRM-fähige Anwendung 104, wie beispielsweise E-Mail-Anwendung, eine Textverarbeitungsanwendung oder dergleichen. Der Empfänger 106 umfasst ebenfalls einen IRM-Client 107 und eine IRM-fähige Anwendung 108, wie sie beim Veröffentlicher 103 verfügbar ist. Es kann viele weitere Empfänger und Veröffentlicher geben, auch wenn diese der Übersichtlichkeit halber in 1 nicht dargestellt sind. Der IRM-Server 100 umfasst eine Rechte-und-Richtlinien-Evaluierungseinrichtung 109, die mit einem verschlüsselten Datenobjekt verbunden sein kann, sowie eine Lizenzerzeugungseinrichtung 110, die so eingerichtet ist, dass sie eine Nutzungslizenz erzeugt, wenn ein Nutzer berechtigt ist, auf ein Datenobjekt zuzugreifen.
  • Das Flussdiagramm in 2 zeigt die Prozesse beim Herstellen eines Dokuments und beim Erteilen einer Lizenz zum Zugriff auf das Dokument für einen autorisierten Nutzer entsprechend einer dazugehörigen IRM-Richtlinie. Im Folgenden kann, wenn eine Unterscheidung zweckdienlich ist, der Nutzer als ein „Anfordernder” bezeichnet werden, wenn er eine Nutzungslizenz anfordert, und als ein „Empfänger”, wenn festgestellt worden ist, dass der Nutzer autorisiert ist, auf das Dokument zuzugreifen. Die vorliegende Offenbarung bezieht sich jedoch nicht darauf, ob ein Individuum zur Autorisierung berechtigt ist, und daher wird in den hier erläuterten Beispielen im Allgemeinen davon ausgegangen, dass der Anfordernde zur Autorisierung berechtigt ist.
  • Die hier angeführten Beispiele beziehen sich der Übersichtlichkeit halber im Allgemeinen auf die Anwendung einer IRM-Richtlinie auf Dokumente. Es versteht sich jedoch, dass eine IRM-Richtlinie für jedes beliebige Datenobjekt (beispielsweise E-Mails, Tabellenblätter, Binärdaten, technische Unterlagen, Datenbanken, Überwachungsprotokolle und dergleichen) gelten kann und die Offenbarung nicht nur auf Dokumente beschränkt ist.
  • Der Veröffentlicher 103 stellt unter Verwendung der IRM-fähigen Anwendung 104 ein Dokument her und gibt Rechte und Bedingungen für das Dokument an (Block 200). Diese Nutzungsrechte und -bedingungen bilden zusammen eine IRM-Richtlinie. Die Bedingungen können beispielsweise einschließen, dass der Empfänger 106 ein Mitglied einer angegebenen Gruppe von Nutzern sein sollte (beispielsweise ein Beschäftigter eines bestimmten Unternehmens), und die Nutzungsrechte schließen ein, dass der Empfänger das Dokument nur betrachten kann (und das Dokument nicht bearbeiten, drucken oder verteilen kann).
  • Der IRM-Client 105 und der IRM-Server 100 des Veröffentlichers stellen zusammen eine verschlüsselte Veröffentlichungslizenz her, die die angegebenen Nutzungsrechte und -bedingungen beinhaltet (Block 201). In diesem Beispiel erzeugt der IRM-Server 100 die Veröffentlichungslizenz und sendet diese zu dem IRM-Client 105. Die IRM-fähige Anwendung 104 oder der IRM-Client 105 bei dem Veröffentlicher 103 verschlüsselt das Dokument und integriert die verschlüsselte Veröffentlichungslizenz in das Dokument (Block 202). Die Veröffentlichungslizenz wird mit einem Schlüssel des IRM-Servers 100 verschlüsselt (d. h. so verschlüsselt, dass der IRM-Server 100 sie entschlüsseln kann). Ein Inhaltsschlüssel (der verwendet werden kann, um den Inhalt zu entschlüsseln) wird in die verschlüsselte Veröffentlichungslizenz eingefügt. Daher ist nur der IRM-Server 100 in der Lage, eine Nutzungslizenz zu erteilen, die den Inhaltsschlüssel beinhaltet, den der Nutzer benötigt, um die Datei zu entschlüsseln.
  • Der Veröffentlicher 103 sendet dann das verschlüsselte Dokument zusammen mit der Veröffentlichungslizenz als eine Datei zu dem Empfänger 106 (Block 203). Der Empfänger 106 öffnet die Datei unter Verwendung der IRM-fähigen Anwendung 108 und sendet eine Anforderung für eine Nutzungslizenz zu dem IRM-Server 100. Die Anforderung enthält den öffentlichen Schlüssel des Empfängers sowie die verschlüsselte Veröffentlichungslizenz, die den Inhaltsschlüssel beinhaltet. Unter Bezugnahme auf den Identitäts-Provider 102 validiert der IRM-Server 100 den Empfänger 106 als zu der angegebenen Gruppe gehörend und erzeugt und erteilt eine Nutzungslizenz für den Anfordernden, die die Nutzungsrechte und- bedingungen beinhaltet, die in der Veröffentlichungslizenz angegeben wurden (Block 204). Während dieses Prozesses entschlüsselt der IRM-Server 100 den Inhaltsschlüssel unter Verwendung seines privaten Schlüssels und fügt den Inhaltsschlüssel unter Verwendung des öffentlichen Schlüssels des Empfängers zu der Nutzungslizenz so hinzu, dass gewährleistet ist, dass nur der vorgesehene Empfänger den Schlüssel entschlüsseln und damit die geschützte Datei entschlüsseln kann. Unter Verwendung der Nutzungslizenz entschlüsselt dann die IRM-fähige Anwendung 107 oder der IRM-Client 108 des Empfängers den Inhalt des Dokumentes und setzt die Nutzungsrechte um (Block 205).
  • Bei dem oben unter Bezugnahme auf 1 und 2 beschriebenen bekannten IRM-System validiert der IRM-Server 100 selbst die Informationsrechte-Richtlinien und ist als einzige Instanz dazu in der Lage. Es gibt einen einzelnen Richtlinien-Entscheidungspunkt, d. h., der IRM-Server 100 entscheidet allein anhand aller Bedingungen innerhalb der Richtlinie, ob eine Nutzungslizenz erteilt werden sollte.
  • Dieses bekannte IRM-Modell kann mit den im Folgenden ausgeführten Formeln beschrieben werden:
  • Die Transformation eines Inhaltsschlüssels und einer Informationsrechte-Richtlinie (die zusammen eine unsignierte Lizenz bilden) kann beschrieben werden mit:
    Figure 00060001
    wobei
  • (Kc, P)
    eine unsignierte Lizenz ist,
    P
    eine Nutzungsrichtlinie ist, die Nutzungsrechte mit Bedingungen verknüpft
    P≔ Π[{Rights}, {ExpressionPDP }]
    eine Richtlinienausbildung ist, die die Informations-Zugriffsrechte mit den Bedingungen in einem Richtlinien-Ausdruck verknüpft
    [arg s]
    die Ausbildung ist, die funktionale Abhängigkeiten zwischen den Argumenten Args beschreibt
    {Rights}
    die Gruppe von Nutzungsrechten ist, die der Richtlinie unterliegen
    {ExpressionPDP}
    die Bedingungen sind, die durch einen Richtlinien-Entscheidungspunkt zu bewerten sind
    PL
    die Veröffentlichungslizenz ist
    Kc
    ein Inhaltsschlüssel (Chiffrierschlüssel) ist, der verwendet wird, um Klartext-/Daten zu verschlüsseln
    Kl
    ein Chiffrierschlüssel des Lizenzgebers (beispielsweise des IRM-Servers) ist
    Ek (...)
    eine Verschlüsselung des in Klammern stehenden Terms mit dem Schlüssel k ist.
  • Diese Transformation kann durch den IRM-Server 100 ausgeführt werden, wenn der Veröffentlicher 103 die Anforderung zu dem IRM-Server 100 sendet, oder durch den Veröffentlicher 103, wenn der öffentliche Schlüssel des IRM-Servers 100 von dem IRM-Client 105 des Veröffentlichers verwendet wird, um den Inhaltsschlüssel und die Richtlinie zu verschlüsseln.
  • Normalerweise wird die Veröffentlichungslizenz durch IRM-Server 100 oder, bei Offline-Veröffentlichung, durch den IRM-Client 105 oder im Auftrag des IRM-Servers 100 signiert, um die Integrität der Lizenz zu gewährleisten. Bei den im Folgenden erörterten Ausführungsformen wird davon ausgegangen, dass Veröffentlichungs- und Nutzungslizenz signiert sind.
  • Die Transformation der Nutzungslizenz kann beschrieben werden mit:
    Figure 00070001
    wobei
    • kr der Schlüssel eines Anfordernden ist und
      Figure 00070002
      eine Verschlüsselung des Inhaltsschlüssels KC mit kr ist
    • {O} eine Sammlung von Objekten des gleichen spezifischen Typs ist
    • {Rights} die Gruppe gewährter Nutzungsrechte nach der Evaluierung der Richtlinie ist
    • [objects] eine Gruppe von Objekten ist.
  • Sogenannte „Null-Transformationen”, d. h. eine Verschlüsselungs-/Entschlüsselungsoperation ohne Schlüssel, und Transformationen einer Richtlinie ohne Bedingungen können wie folgt definiert werden:
    für die Schlüssel-Verschlüsselung: E0 ≔ E0 (K) → K
    für die Verknüpfung von Richtlinien-Ausdrücken mit Rechten: Π0 ≔[{Rights}, null] → {Rights}
  • So können der Veröffentlicher 103, der Empfänger 106 und der IRM-Server 100 zusammen als ein „Lizenzgeber” beschrieben werden, der zwei Grundoperationen unterstützt:
    • (i) Issue(Lic) → Lic', d. h. Erteilen der Lizenz. Der Lizenzgeber transformiert die Eingabelizenz zu der Ausgabelizenz und schützt sie für den Ziel-Lizenzgeber. Beispielsweise transformiert der IRM-Server 100 die Veröffentlichungslizenz zu einer Nutzungslizenz, die für den Empfänger 106 geschützt ist. In einem anderen Beispiel transformiert der Veröffentlicher 103 die unsignierte Lizenz zu einer Veröffentlichungslizenz, die für den IRM-Server 100 geschützt ist.
  • Extract(Lic, {Rights}) → Kc, d. h. Extrahieren des Inhaltsschlüssels. Der Lizenzgeber bezieht den Inhaltsschlüssel, wenn die Richtlinie für das/die angeforderte/n Recht/e gültig ist. Beispielsweise bezieht der Empfänger 106 den Inhaltsschlüssel, wenn das angeforderte Recht in der Gruppe gewährter Rechte in der Nutzungslizenz enthalten ist.
  • Eine zusammengefasste Lizenz (d. h. sowohl eine Nutzungs- als auch eine Veröffentlichungslizenz) wird wie folgt dargestellt:
    Figure 00080001
  • Bei dieser Definition werden die Aktionen des Lizenzgebers wie folgt interpretiert: Um eine Veröffentlichungslizenz zu erteilen, erstellt der Veröffentlicher 103 die Richtlinie P und sendet die Anforderung zum Erteilen der Lizenz an den IRM-Server 100, oder der Veröffentlicher 103 erteilt die Lizenz selbst. Der IRM-Server 100 oder der Veröffentlicher 103 führt eine Erteilungsoperation an der unsignierten Eingabelizenz aus, die den Inhaltsschlüssel und die Richtlinie umfasst:
    Figure 00080002
  • Um eine Nutzungslizenz zu erteilen, sendet der Empfänger 106 eine Anforderung zum Erteilen der Nutzungslizenz an den IRM-Server 100. Der IRM-Server 100 validiert die Richtli nie für den Empfänger 106 und extrahiert dann, wenn die Richtlinie gültig ist, den Inhaltsschlüssel und erteilt die Nutzungslizenz, die die entsprechend der Richtlinie gewährten Rechte enthält. Der IRM-Server 100 erteilt die Nutzungslizenz: Issue(PL) → ULoder
    Figure 00090001
  • Der Empfänger 106 extrahiert dann den Inhaltsschlüssel aus der Nutzungslizenz, wobei dies durch den IRM-Client 107 nur dann zugelassen wird, wenn das angeforderte Recht Teil der Gruppe von Rechten ist, die in der Nutzungslizenz enthalten sind.
  • Figure 00090002
  • Einige IRM-Systeme können als CIRMS-Systeme (Context Aware Information Rights Management Systems) bezeichnet werden, wobei eine Ausführungsform dieser Systeme in der US-Patentanmeldung, Seriennummer 11/762,619 offenbart ist. Bei derartigen Systemen kommuniziert ein IRM-Server mit einer oder mehreren Richtlinien-Evaluierungseinrichtungen, die unabhängig von dem IRM-Server sind und von denen jede einen Richtlinien-Entscheidungspunkt bildet. Ergebnisse von den verschiedenen Richtlinien-Evaluierungseinrichtungen werden durch den IRM-Server kombiniert. Dadurch kann eine einzelne Gesamtgruppe von Rechten geschaffen werden (d. h. die Schnittmenge der gewährten Rechte, die von den einzelnen Richtlinien-Entscheidungspunkten zurückgeführt werden).
  • Bei bekannten CIRMS-Ausführungsformen wird eine komplexe Richtlinie definiert, die festlegt, wer welche Zugriffsrechte auf ein spezifisches Datenobjekt hat, wobei „wer” nicht nur Identitäten betrifft, sondern auch Kontext, wie beispielsweise Standort, und andere Bedingungen einschließen kann. Die Richtlinie wird durch den Veröffentlicher des Datenobjektes und/oder durch das System (einschließlich des Lizenzgeber-Dienstes) definiert. Das Datenobjekt wird mit einem Inhaltsschlüssel verschlüsselt. Eine Veröffentlichungslizenz, die die definierte komplexe Richtlinie sowie den Inhaltsschlüssel enthält, der für den Lizenzgeber-Dienst verschlüsselt ist, der die Veröffentlichungslizenz erteilt (d. h. so, dass der Lizenzge ber-Dienst Entschlüsselung durchführen kann), wird erzeugt und an die verschlüsselten Daten angehängt. Die Veröffentlichungslizenz schließt Security-Token-Anforderungen ein, die von einem zukünftigen Anfordernden einer Lizenz gelesen werden können.
  • Eine Anwendung, die versucht, einen bestimmten Vorgang an dem Datenobjekt im Auftrag eines Empfängers durchzuführen, veranlasst diesen Empfänger, Security-Token zu beziehen, die in der Veröffentlichungslizenz angegeben sind, und zwar möglicherweise von einer Vielzahl von Quellen. Die Security-Token werden zusammen mit der Veröffentlichungslizenz als Teil einer Anforderung zum Beziehen einer Nutzungslizenz zu dem Lizenzgeber-Dienst weitergeleitet. Der Lizenzgeber-Dienst sendet die Richtlinie und die empfangenen Security-Token zu dem/den Richtlinien-Entscheidungspunkt/en und leitet eine Gesamtgruppe von Rechten her, die dem Empfänger durch die einzelnen Entscheidungspunkte gewährt worden sind. Der Lizenzgeber-Dienst entschlüsselt den Inhaltsschlüssel und verschlüsselt ihn für die Anwendung/den Empfänger erneut. Der wiederverschlüsselte Inhaltsschlüssel wird zusammen mit der Gruppe gewährter Rechte in eine Nutzungslizenz mit einer begrenzten Gültigkeitszeit integriert. Die Anwendung entschlüsselt das Datenobjekt mit dem Inhaltsschlüssel und setzt die gewährten Rechte um, d. h. sie führt nur diejenigen Vorgänge der durch den Empfänger angeforderten Vorgänge durch, die entsprechend der Gruppe gewährter Rechte zulässig sind, und dies nur, solange die Nutzungslizenz nicht abgelaufen ist.
  • Bei derartigen CIRMS-Ausführungsformen beinhaltet die Veröffentlichungslizenz die zusammengesetzte Richtlinie, die durch verteilte Richtlinien-Entscheidungspunkte (die daher Richtlinien-Bewertungseinrichtungen bilden) evaluiert werden kann. Jeder Richtlinien-Entscheidungspunkt weist seine Kontext-/Identitätsanforderungen auf. Der Empfänger präsentiert dem Lizenzierungs-Server Kontext-/Identitäts-Anforderungen zusammen mit der Veröffentlichungslizenz. Der Lizenzierung-Server trifft die Entscheidung über Rechte des Empfängers auf Basis der Evaluierungsergebnisse der Richtlinien-Entscheidungspunkte.
  • Was das CIRMS-Modell angeht, so kann die Formel für die zusammengefasste Lizenz wiederum angewendet werden:
    Figure 00100001
  • Die Lizenzierungs-Gleichungsoperation kann wie folgt erweitert werden: Issue(Lic, {Tokens}) → Lic'
  • Wobei die Sammlung {Tokens} die Identitäts-/Kontext-Informationen des Anfordernden darstellt und diese Informationen in Form von Security-Token authentifiziert werden.
  • Das oben beschrieben CIRMS-Modell weist nach wie vor einen einzelnen Lizenzierungsdienst auf. Daher findet, obwohl komplexe Richtlinien als eine Zusammenfassung mehrerer Teilrichtlinien ausgedrückt werden können, die möglicherweise durch verschiedene Richtlinien-Entscheidungspunkte evaluiert werden, die Richtlinien-Evaluierung nach wie vor nur während der Verarbeitung der Anforderung zur Erteilung/Erneuerung einer Nutzungslizenz bei dem Lizenzgeber statt, der so als ein zentraler Entscheidungspunkt arbeitet (d. h. die Entscheidungen der verschiedenen Richtlinien-Entscheidungspunkte zusammenfasst und daraus eine Lizenz macht).
  • Es gibt Szenarien, wie beispielsweise die weiter unten beschriebenen Szenarien, bei denen es vorteilhaft sein kann, die Evaluierung von Teilen von Richtlinien unabhängig durchzuführen und zu erneuern, und zwar sowohl hinsichtlich Zeit als auch Ort, und wo es daher sinnvoll ist, wenn mehrere Lizenzgeber vorhanden sind, möglicherweise in einem verteilten Netzwerk.
  • Bei der Verwendung der Verfahren und Architekturen, wie sie hier offenbart werden, wird, wie weiter unten ersichtlich wird, ein Dokument mit so vielen Schlüsseln geschützt, wie Lizenzgeber vorhanden sind. Dies kann auf verschiedene Weise bewerkstelligt werden, beispielsweise, indem (I) mehrere Verschlüsselungsprozesse durchgeführt werden, wenn die Veröffentlichungslizenz erzeugt wird, (II) ein Verschlüsselungsschlüssel aus den Schlüsseln aller Lizenzgeber hergeleitet wird, (III) ein Lizenzgeber aufgefordert wird, seine Nutzungslizenz mit einer Veröffentlichungslizenz für einen zweiten Lizenzgeber zu schützen, (IV) indem ein erster Lizenzgeber aufgefordert wird, bei einem zweiten Lizenzgeber um Validierung zu bitten, oder (V) diese Verfahren kombiniert werden. Die beschriebene verteilte Anordnung von Lizenzgebern kann bei einigen Beispielen im Voraus statisch festgelegt werden. Bei anderen Beispielen kann sie während der Verarbeitung einer Lizenz dynamisch bestimmt werden.
  • Die in 3 gezeigte Architektur ist eine allgemeine beispielhafte Darstellung der Instanzen, die ein IRM-System mit einer Vielzahl von Lizenzgebern bilden, wie es hier offenbart wird. Die Architektur und die Verarbeitung, die offenbart werden, sind so, dass Interaktion mit allen Lizenzgebern, die erforderlich sind, um die in der Richtlinie erwähnten Bedingungen zu validieren, notwendig ist, um die Bedingungen zu beurteilen, unter denen Zugriff gewährt werden sollte, und um einen vollständig entschlüsselten Inhaltsschlüssel zu beziehen.
  • 3 zeigt ein beispielhaftes IRM-System, das einen Veröffentlicher 302, einen empfangenden Computer 304 und eine Vielzahl (in diesem Beispiel 3) von Lizenzgebern 306, 308, 310 umfasst. Der Veröffentlicher 302 umfasst einen IRM-Client 312 und eine IRM-fähige Anwendung 314, so beispielsweise eine Textverarbeitungsanwendung. Der Computer 304 des Empfängers umfasst ebenfalls einen IRM-Client 316 und die gleiche IRM-fähige Anwendung 318, wie sie bei dem Veröffentlicher 302 verfügbar ist. Es können erheblich mehr Empfänger und Veröffentlicher vorhanden sein, auch wenn diese der Übersichtlichkeit halber in 3 nicht dargestellt sind. Jeder Lizenzgeber 306, 308, 310 umfasst eine Rechte-und-Richtlinien-Evaluierungseinrichtung 320 sowie eine Lizenzerzeugungseinrichtung 322. In anderen Beispielen kann jeder Lizenzgeber über mehr als eine Rechte-und-Richtlinien-Evaluierungseinrichtung 320 verfügen, dies ist jedoch der Einfachheit halber in 3 nicht dargestellt. Das System umfasst des Weiteren eine Vielzahl von Identitäts-Providern 324, 326.
  • Das Flussdiagramm in 4 zeigt einen verallgemeinerten Prozess zum Erzeugen eines Dokumentes und zum Erteilen einer Lizenz zum Zugreifen auf das Dokument für einen autorisierten Nutzer gemäß einer dazugehörigen IRM-Richtlinie unter Verwendung des in 3 gezeigten IRM-Systems.
  • Der Veröffentlicher 302 erzeugt ein Dokument unter Verwendung der IRM-fähigen Anwendung 314 und gibt Nutzungsrechte und -bedingungen für das Dokument an (Block 420).
  • Der IRM-Client 314 des Veröffentlichers erzeugt zusammen mit dem Lizenzgeber 306 eine verschlüsselte Veröffentlichungslizenz, die die angegebenen Nutzungsrechte und -bedingungen beinhaltet (Block 422). Diese Bedingungen erfordern beispielsweise Validierung durch wenigstens zwei der separaten Lizenzgeber 306, 308, 310.
  • In einigen Ausführungsformen (die anders als bei der in 3 gezeigten beispielhaften Ausführungsform eingerichtet sein können) kann, wie weiter unten ausführlicher erläutert, diese Lizenz die Details eines oder mehrerer der Lizenzgeber 306, 308, 310 beinhalten. Die IRM-fähige Anmeldung 314 oder der IRM-Client 312 an dem Veröffentlicher 302 verschlüsselt das Dokument und integriert die verschlüsselte Veröffentlichungslizenz in das Dokument (Block 422). Der Inhaltsschlüssel, mit dem das Dokument verschlüsselt wird, wird mit einem Schlüssel wenigstens eines Lizenzgebers 306, 308, 310 verschlüsselt, der in der Richtlinie identifiziert wird (d. h. wird so verschlüsselt, dass der wenigstens eine Lizenzgeber 306, 308, 310 Entschlüsselung durchführen kann). Der verschlüsselte Inhaltsschlüssel wird in die verschlüsselte Veröffentlichungslizenz eingefügt.
  • Ein Empfänger ist nicht in der Lage, den Inhaltsschlüssel und damit das Dokument zu entschlüsseln, wenn er in Interaktion mit jedem der Lizenzgeber 306, 308, 310 tritt, von denen Validierungen erforderlich sind. Wie aus der folgenden Beschreibung ersichtlich wird, kann die durch einen Lizenzgeber zurückgeführte Nutzungslizenz eine Veröffentlichungslizenz umfassen, für die ein Empfänger eine Nutzungslizenz von einem weiteren Lizenzgeber 306, 308, 310 benötigt (beispielsweise benötigt der Empfänger in 3 eine Lizenz von den Lizenzgebern 310 und 308), bevor Zugriff auf den Inhalt des Dokumentes gestattet wird. Dies wird im Folgenden als eine „rekursiver” Prozess bezeichnet. Als Alternative oder zusätzlich dazu müssen, wenn die Veröffentlichungslizenz mit einem Schlüssel von mehr als einem Lizenzgeber 306, 308, 310 verschlüsselt ist, Nutzungslizenzen von allen relevanten Lizenzgebern 306, 308, 310 bezogen werden, bevor der Inhaltsschlüssel abgerufen werden kann.
  • Der Veröffentlicher 302 sendet dann das verschlüsselte Dokument zusammen mit der Veröffentlichungslizenz zu dem Empfänger 304 (Block 426). Der Empfänger 304 öffnet die Datei unter Verwendung der IRM-fähigen Anwendung 318, und eine Anforderung einer Nutzungslizenz wird zu jedem der Lizenzgeber 306, 308, 310 gesendet, die erforderlich sind, um die Lizenz zu validieren (Block 428). Jede dieser Anforderungen kann direkt von dem Empfänger 304 oder von einem oder mehreren der Lizenzgeber 306, 308, 310 gesendet werden. Die Lizenzgeber 306, 308, 310 validieren den Empfänger 304 entsprechend angegebener Kriterien (beispielsweise unter Verwendung der Identitäts-Provider 324, 326 als zu der angegebenen Gruppe gehörend) und erzeugen und erteilen eine oder mehrere Nutzungslizenz/en, die begrenzte Gültigkeitszeit haben kann/können und die die Nutzungsrechte beinhaltet/beinhalten, die im Zusammenhang mit diesem Lizenzgeber 306, 308, 310 in der Veröffentlichungslizenz angegeben wurden (Block 430). Der IRM-Client des Empfän gers 316 ruft Verschlüsselungsschlüssel, die benötigt werden, um den Inhaltsschlüssel zu entschlüsseln, mit dem das Dokument verschlüsselt ist, als Teil der Nutzungslizenzen von den Lizenzgebern 306, 308, 310 ab. Unter Verwendung des Schlüssels des Empfängers werden die Nutzungslizenzen so eingerichtet, dass nur der vorgesehene Empfänger auf die Schlüssel zugreifen kann.
  • Unter Verwendung der Nutzungslizenzen verschlüsselt dann die IRM-fähige Anwendung 318 oder der IRM-Client 316 des Empfängers den Inhalt des Dokumentes und setzt die Nutzungsrechte um (Block 432). Der IRM-Client 316 gestattet es dem Empfänger, einen spezifischen Vorgang durchzuführen, wenn das Recht, diesen Vorgang durchzuführen, durch jede der Nutzungslizenzen von den Lizenzgebern 306, 308, 310 gewährt wird.
  • Die Veröffentlichungs- und die Nutzungslizenz können als zusammengesetzte Lizenz beschrieben werden. Bei Erweiterung der oben eingeführten Gleichung kann eine zusammengefasste kombinierte Lizenz wie folgt definiert werden:
    Figure 00140001
    wobei
  • Figure 00140002
    der Inhaltsschlüssel KC ist, der unter Verwendung von Schlüssel KL des Lizenzgebers und optional unter Verwendung von Inhaltsschlüsseln
    Figure 00140003
    verschlüsselt wird, die durch Unterlizenzen geschützt werden (Lizenzen, die von anderen Lizenzgebern evaluiert werden müssen).
  • Figure 00140004
    ist die unter Verwendung von Schlüssel KL des Lizenzgebers L verschlüsselte Richtlinie
  • {Lici} ist die Gruppe von Unterlizenzen, die jeweils eine zusammengefasste zusammengesetzte Lizenz sein können, und die eine oder mehrere Unterlizenzen Licj enthalten kann.
  • Eine Beschreibung der Verarbeitung, die sich sowohl auf Veröffentlichungs- als auch auf Nutzungslizenzen bezieht und die auch sowohl für Lizenzierungsdienste als auch Empfänger als „Lizenzgeber” gültig ist, wird im Folgenden beschrieben.
  • Die Veröffentlichungs- oder Nutzungslizenzen werden wie folgt erzeugt („Erteilungsvorgang”):
    Der Lizenzgeber erteilt dem Anfordernden die abgeleitete Lizenz L', wobei L' den Inhaltsschlüssel aus der Eingabelizenz und die unter Verwendung der Eingaben hergeleitete Richtlinie beinhaltet:
    • (I) die zusammengefasste zusammengesetzte
      Figure 00150001
    • (II) eine Kennung eines Ziel-Lizenzgebers, die den Verschlüsselungsschlüssel angibt, der verwendet wird, um die abgeleitete Ausgabelizenz zu sichern, und in einigen Beispielen
    • (III) die Sammlung von Token {Tokens}, die die Identität und/oder Kontextinformationen des Empfängers darstellt.
  • Die Ausgabe der Lizenzableitung ist eine abgeleitete zusammengefasste zusammengefasste Lizenz
  • Figure 00150002
  • Diese Lizenzableitung kann dann entsprechend dem folgenden Prozess ablaufen: Wenn die verschlüsselte Richtlinie
    Figure 00150003
    nicht NULL ist, kann die Richtlinie P unter Verwendung von Schlüssel KL bezogen werden. Ansonsten, und wenn keine bedingten Lizen zen vorhanden sind, wird eine Null-Lizenz zurückgeführt. Die Richtlinie P kann als unverschlüsselte Daten in der Lizenz vorgelegt werden (dies folgt aus der oben stehenden Definition der NULL-Verschlüsselungs-Transformation und davon wird beispielsweise Gebrauch gemacht, wenn eine Veröffentlichungslizenz durch einen Veröffentlicher von einer unsignierten Lizenz ausgehend erteilt wird).
  • In einigen Ausführungsformen ist es erforderlich, die Richtlinie P anhand von Token {Token} zu validieren. Wenn das Ergebnis der Validierung die leere {Rights}Lic-Gruppe umfasst, wird die Verarbeitung unterbrochen, und eine NULL-Lizenz wird zurückgeführt. Wenn die Gruppe bedingter Lizenzen {Lici} nicht leer ist, wird eine Gruppe abgeleiteter Lizenzen {Lic'i} bezogen, indem eine Erteilungs-Operation an den entsprechenden Lizenzgeber Li für jede Gruppe Lici rekursiv durchgeführt wird. Es wird davon ausgegangen, dass ein Nutzer oder Lizenzgeber, der eine Lizenz anfordert, den Lizenzgeber, von dem er eine abgeleitete Lizenz anfordert, kennt und ihm vertraut. Es wird des Weiteren davon ausgegangen, dass diese Vertrauensbeziehung bereits existiert und beispielsweise einen gemeinsamen Schlüssel umfasst. Diese Offenbarung schließt keine expliziten Mechanismen zum dynamischen Urladen (bootstrap) dieser Vertrauensbeziehung ein, obwohl die hier beschriebenen Verfahren und Vorrichtungen in Verbindung mit einem derartigen System eingesetzt werden können.
  • Die Schlüssel
    Figure 00160001
    werden aus den erworbenen Lizenzen extrahiert, indem eine Schlüsselextrahierungs-Operation (weiter unten beschrieben) an dem aktuellen Lizenzgeber L durchgeführt wird. Der Inhaltsschlüssel KC wird unter Verwendung von Schlüsseln KL und
    Figure 00160002
    bezogen.
  • Die abgeleitete Richtlinie P' wird dann erstellt. In einigen Beispielen kann die abgeleitete Richtlinie P' die gleiche sein wie die Richtlinie P aus der eingegebenen zusammengefassten zusammengesetzten Lizenz (zum Erteilen einer Veröffentlichungslizenz von einer unsignierten Lizenz ausgehend). Die abgeleitete Richtlinie P' kann im Fall der Nutzungslizenz die Gruppe von Rechten sein (und wenn bedingte Nutzungslizenzen vorhanden sind, ist Richtlinie P' die Schnittmenge von Rechten von P und von Rechten in bedingten Unterlizenzen). Die abgeleitete Richtlinie P' wird dann mit dem Schlüssel KL, des Ziel-Lizenzgebers L' verschlüsselt.
  • Neue Unterlizenzen {Lic'i } können dann erstellt werden, indem eine Erteilungs-Operation an den entsprechenden Lizenzgebern durchgeführt wird. In einigen Beispielen ist diese Gruppe von Unterlizenzen leer. In anderen Beispielen kann die Richtlinie der Unterlizenzen unabhängig durch den aktuellen Lizenzgeber L bestimmt werden oder kann aus der aktuellen Richtlinie P hergeleitet werden (beispielsweise im Fall eines nicht evaluierten Teils der Richtlinie). Der Inhaltsschlüssel KC wird dann zu dem Schlüssel KL, des Ziel-Lizenzgebers und den Inhaltsschlüsseln
    Figure 00170001
    aus den entsprechenden Unterlizenzen {Lic'i} verschlüsselt. Die abgeleitete Lizenz Lic' wird zurückgeführt.
  • Der Lizenzgeber extrahiert den Inhaltsschlüssel aus der für diesen Lizenzgeber bestimmten Lizenz in einer „Schlüsselextrahierungs”-Operation, die wie folgt definiert werden kann:
  • Der Lizenzgeber erhält als Eingabe
    • (I) die zusammengefasste zusammengesetzte
      Figure 00170002
    • (II) die angeforderten Rechte {Rights} und in einigen Beispielen
    • (III) die Sammlung von Token {Tokens} des Anfordernden, die die Identität und/oder Kontextinformationen des Empfängers darstellt.
  • Die Ausgabe ist der Inhaltsschlüssel KC.
  • Die Verarbeitung wird wie folgt ausgeführt: Wenn die verschlüsselte Richtlinie
    Figure 00170003
    nicht NULL ist, wird die Richtlinie P unter Verwendung von Schlüssel KL bezogen, und ansonsten wird, wenn keine bedingten Lizenzen vorhanden sind, die Verarbeitung unterbrochen und ein NULL-Inhaltsschlüssel wird zurückgeführt.
  • Die Richtlinie P wird, wenn erforderlich, anhand der Token {Tokens} und der angeforderten Rechte {Rights} evaluiert. Das Ergebnis der Evaluierung umfasst {Rights} und wird entsprechend der Richtlinie gewährt. Wenn die Gruppe angeforderter Rechte {Rights} keine Teilgruppe von {Rights}Lic ist, wird die Verarbeitung unterbrochen, und ein NULL-Inhalts schlüssel wird zurückgeführt. Wenn die Gruppe bedingter Lizenzen {Lici} nicht leer ist, wird eine Gruppe abgeleiteter Lizenzen {Lic'i} erworben, indem eine Erteilungs-Operation an dem entsprechenden Lizenzgeber Li für jede Gruppe Lici rekursiv durchgeführt wird.
  • Die Schlüssel
    Figure 00180001
    werden aus den erworbenen Lizenzen extrahiert, indem die angeforderten Rechte {Rights} als Parameter weitergeleitet werden und indem eine Schlüsselextrahierungs-Operation an dem aktuellen Lizenzgeber L für jede Gruppe Lic'i durchgeführt wird. Wenn wenigstens ein Inhaltsschlüssel
    Figure 00180002
    NULL ist, wird die Verarbeitung unterbrochen, und ein NULL-Inhaltsschlüssel wird zurückgeführt.
  • Der Inhaltsschlüssel KC wird unter Verwendung von Schlüsseln KL und
    Figure 00180003
    extrahiert.
  • Die oben stehende Beschreibung erläutert nicht die Ablaufzeiten, die einer zur Veröffentlichungslizenz und einer Nutzungslizenz gehören können. In vielen Ausführungsformen hat eine Nutzungslizenz eine Gültigkeitszeit und wird für diesen Zeitraum zwischengespeichert. Während dieses Zeitraums müssen die Prozesse des Erteilens und der Schlüsselextrahierung nicht wiederholt werden. In dieser Offenbarung wird, wie weiter unten ausführlicher erläutert, die Gültigkeitszeit der bedingten Unterlizenzen rekursiv berücksichtigt. Das heißt, es sollte die kürzeste Zeit identifiziert werden. Wenn beispielsweise die Gültigkeitszeit der Unterlizenz kürzer ist als die Gültigkeitszeit der Stammlizenz, sollte der Erteilungsprozess für die Unterlizenz dementsprechend wiederholt werden, während, wenn die Gültigkeitszeit der Stammlizenz kürzer ist als die Gültigkeitszeit der Unterlizenz, der Vergabeprozess für die Stammlizenz wiederholt werden sollte (wodurch automatisch eine neue Unterlizenz entsteht).
  • Die oben vorgeschlagene logische Struktur der zusammengesetzten Lizenz und die entsprechende Verarbeitung, die oben beschrieben ist, und in jedem der beispielhaften Szenarien im Folgenden erläutert wird, kann jede beliebige verteilte Anordnung von Lizenzgebern unterstützen, indem beispielsweise zusammengesetzte Lizenzen kombiniert und/oder rekursiv geschichtet werden. Die vorliegende Offenbarung schafft daher die Grundbausteine für jede beliebige Architektur-Topologie.
  • Beispiele der spezifischen Instanzen, die in einem beliebigen IRM-System enthalten sein können, werden im Folgenden unter Bezugnahme auf drei beispielhafte Szenarien erläu tert. Der Prozess des Verschlüsseln des Dokuments ist bereits beschrieben worden, so dass er nicht für jedes Beispiel beschrieben wird.
  • In einem ersten beispielhaften Fall weiß der Veröffentlicher 302, welcher Lizenzgeber die Anforderung zum Zugriff auf das Dokument validieren wird, und die von dem Veröffentlicher erzeugte ursprüngliche Veröffentlichungslizenz kann daher kombinierte Veröffentlichungslizenzen für diese verschiedenen Lizenzgeber beinhalten. Der Inhalt wird mit einem Inhaltsschlüssel KC verschlüsselt, der dann mit einem Schlüssel eines ersten Lizenzgebers und mit einem Schlüssel eines zweiten Lizenzgebers verschlüsselt wird. Der Empfänger 304 muss eine Nutzungslizenz von beiden Lizenzgebern erwerben, da für beide Nutzungslizenzen der Inhaltsschlüssel extrahiert werden muss. In einigen Beispielen sind dies zwei (oder mehr) separate Verschlüsselungsprozesse, während es in anderen Beispielen stattdessen eine einzelne Verschlüsselung mit einem Schlüssel sein könnte, der aus den Schlüsseln der verschiedenen Lizenzgebern abgeleitet wird.
  • Unter Verwendung der oben aufgeführten Gleichung führt der Empfänger Parsing der kombinierten Veröffentlichungslizenz durch, wobei dies wie folgt definiert werden kann:
    Figure 00190001
    und PLL1 und PLL2 eine standardisierte oder jede beliebige zusammengesetzte Veröffentlichungslizenz sein kann.
  • Der Empfänger sendet die Veröffentlichungslizenz PLL1 zu dem ersten Lizenzgeber, um eine Nutzungslizenz UL1user zu erwerben:
    Figure 00190002
  • Der Empfänger sendet die Veröffentlichungslizenz PLL2 zu dem zweiten Lizenzgeber, um eine Nutzungslizenz UL2user zu erwerben:
    Figure 00190003
  • Unter Verwendung seines eigenen Schlüssels Kuser extrahiert der Empfänger die Inhaltsschlüssel
    Figure 00200001
    und
    Figure 00200002
    aus UL1user bzw. UL2user. Der Empfänger entschlüsselt dann den Inhaltsschlüssel KC unter Verwendung der Inhaltsschlüssel
    Figure 00200003
    und
    Figure 00200004
    Der Empfänger setzt die Schnittmenge der zwei Rechtegruppen um, die in beiden Nutzungslizenzen zurückgeführt werden.
  • Dieses Szenario lässt sich anhand eines Dokumentes beispielhaft darstellen, das so gesichert ist, dass es innerhalb eines bestimmten Gebietes nur betrachtet werden kann, so beispielsweise innerhalb einer eingeschränkten Zone auf dem Unternehmensgelände. Die Rechtegewährungs-Richtlinie des Dokumente beinhaltet zwei Bedingungen, d. h. erstens die Bedingung, dass der Anfordernde innerhalb eines Verzeichnisdienstes identifiziert wird, auf den der lokale Server 400 des Empfängers zugreifen kann (d. h., dass sich der Anfordernde aktuell in einer bestimmten Zulassungsliste von Individuen befindet, die Zugriff auf das Dokument haben sollten), und zweitens eine Standortbedingung, d. h., dass sich der Empfänger innerhalb der eingeschränkten Zone befindet.
  • In der im Folgenden beschriebenen Ausführungsform sind, wie in 5 dargestellt, eine Server-Lizenzerzeugungseinrichtung 402, die in dem Verzeichnisdienst des lokalen Servers 400 gespeicherte Daten verwendet, sowie eine Empfänger-Lizenzerzeugungseinrichtung 408 vorhanden, die lokal an Computer 304 des Empfängers erzeugte Daten verwendet. Interaktionen finden mit beiden dieser Lizenzerzeugungseinrichtungen 402, 408 statt, um den Versuch des Anfordernden, auf ein Dokument zuzugreifen, zu validieren. Diese Lizenzerzeugungseinrichtungen 402, 408 bilden den ersten und den zweiten Lizenzgeber, und (z. B. öffentliche) Schlüssel beider Lizenzerzeugungseinrichtungen sind dem Veröffentlicher 302 bekannt.
  • Bei diesem Beispiel werden GPS-Daten verwendet, um die Positionsdaten bereitzustellen, in anderen Beispielen können jedoch alternative Daten, so beispielsweise WLAN-Endpunktdaten, verwendet werden. Bei diesem Beispiel werden GPS-Daten durch ein tragbares GPS-Gerät 404 bereitgestellt, das mit dem Computer 304 des Empfängers verbunden ist. Das heißt, GPS-Daten werden durch eine Software-Komponente bereitgestellt, die in der Lage ist, Standortinformationen 406 zu bestimmen, die sich auf diesem tragbaren Gerät 404 befinden. In derartigen Umgebungen evaluiert die Lizenzerzeugungseinrichtung 408 des Empfängers die Standort-Bedingung und nimmt an dem Lizenzerteilungsprozess unabhängig von der Server-Erzeugungseinrichtung 402 teil. Die Lizenzerzeugungseinrichtung 408 könnte sich stattdessen an dem GPS-Gerät 404 befinden. Bei der in 5 gezeigten Anordnung wird davon ausgegangen, dass dem Empfänger dahingehend vertraut werden kann, dass er die durch das GPS-Gerät 404 bereitgestellten Daten nicht manipuliert. Bei WLAN-Endpunktdaten sollte der Lizenzgeber ein Software-Treiber sein, der sich auf dem Computer des Anfordernden befindet.
  • 6 ist ein Flussdiagramm, das die Schritte des Validierens eines Versuchs eines Anfordernden zeigt, auf ein Dokument unter Verwendung des in 5 gezeigten IRM-Systems zuzugreifen. Zunächst sendet der Veröffentlicher 302 das verschlüsselte Dokument zu dem Computer 304 des Anfordernden mit der Veröffentlichungslizenz, die den Inhaltsschlüssel beinhaltet, der zu einem Inhaltsschlüssel aus der Lizenz für die Lizenzerzeugungseinrichtung 408 und zu einem Inhaltsschlüssel aus der Lizenz für die Lizenzerzeugungseinrichtung 408 verschlüsselt ist (Block 502). Wenn der Computer 304 des Anfordernden versucht, auf den Inhalt des Dokumentes zuzugreifen, wird eine Anforderung zu dem lokalen Server 400 gesendet, und die Identität des Anfordernden wird anhand der in dem Verzeichnisdienst gespeicherten Liste validiert (Block 504). Wenn der Anfordernde (wie angenommen) in dem Verzeichnisdienst enthalten ist, erteilt die Server-Lizenzerzeugungseinrichtung 402 eine Lizenz, aus der ihr Schlüssel bestimmt werden kann und die die Nutzungsrechte und -bedingungen beinhaltet, die in der Veröffentlichungslizenz angegeben wurden (Block 506). Dann wird durch die Empfänger-Lizenzerzeugungseinrichtung eine Anforderung zum Bereitstellen von GPS-Daten zu dem GPS-Gerät 404 gesendet, und der Computer 304 des Anfordernden stellt fest, ob er sich innerhalb der eingeschränkten Zone befindet (Block 508). Wenn sich der Computer 304 des Anfordernden (wie angenommen) in der eingeschränkten Zone befindet, erteilt die Empfänger-Lizenzerzeugungseinrichtung 408 eine Nutzungslizenz, die einen Schlüssel aus der entsprechenden Veröffentlichungslizenz beinhaltet (Block 510). Mit beiden aus den Lizenzen PL1 und PL2 erzeugten Schlüsseln kann nunmehr der Inhaltsschlüssel und damit der Inhalt des Dokumentes entschlüsselt werden (Block 511), und er wird für den Empfänger verfügbar, und die Einschränkungen, die in beiden der Nutzungslizenzen angegeben sind, werden von dem Computer 304 des Empfängers umgesetzt (Block 512).
  • Es gibt, wie der Fachmann weiß, andere Möglichkeiten, den Standort eines Nutzers zu bestimmen. In bestimmten Umgebungen kann der Standort beispielsweise durch den lokalen Server bestimmt werden (in diesen Ausführungsformen wäre es möglich, dass das IRM-System nur über eine Lizenzinstanz verfügt, jedoch würde diese Instanz zwei Lizenzgeber umfassen). Systeme zum Steuern von physischem Zugriff (d. h. Systeme mit Zugangskarten) sind ein Beispiel für eine derartige Umgebung.
  • In einem zweiten Fall ist dem Veröffentlicher die Identität eines der Lizenzgeber (als der zentrale Lizenzgeber bezeichnet) bekannt, die eines anderen jedoch nicht. Daher wird der Inhaltsschlüssel zu einem Schlüssel des zentralen Lizenzgebers verschlüsselt. Wenn der zentrale Lizenzgeber die Richtlinie aus der Veröffentlichungslizenz validiert, entschlüsselt er den Inhaltsschlüssel, und er führt eine Nutzungslizenz zurück, die eine zusätzliche bedingte Veröffentlichungslizenz enthält, die wiederum einen zusätzlichen Schlüssel enthält, der zu dem Schlüssel des anderen Lizenzgebers verschlüsselt ist. Um den ursprünglichen Inhaltsschlüssel aus der Nutzungslizenz zu extrahieren, benötigt der Empfänger den zusätzlichen Inhaltsschlüssel, der über eine Interaktion mit dem anderen Lizenzgeber erworben werden muss, um eine Nutzungslizenz von dem anderen Lizenzgeber zu beziehen.
  • Bei diesem Beispiel sendet der Empfänger die Veröffentlichungslizenz PLL1 zu dem zentralen Lizenzgeber, um eine Nutzungslizenz UL1user zu erwerben. Der Inhaltsschlüssel und die Richtlinie werden für den zentralen Lizenzgeber verschlüsselt.
  • Figure 00220001
  • Der zentrale Lizenzgeber validiert die Richtlinie PL, aus PLL1 und erzeugt eine bedingte Veröffentlichungslizenz PLL2 für einen anderen Lizenzgeber L2. Ein zusätzlicher Inhaltsschlüssel
    Figure 00220002
    und eine Richtlinie PL2 werden für den anderen Lizenzgeber verschlüsselt.
  • Figure 00220003
  • Der zentrale Lizenzgeber führt eine Nutzungslizenz UL1user für den Empfänger zurück. UL1user enthält die verschlüsselte Gruppe von Rechten
    Figure 00220004
    , die auf Basis der Richtlinie in PL1 evaluiert wurde, und eine bedingte Veröffentlichungslizenz PLL2. Für die Entschlüsselung der Rechte und des Inhaltsschlüssels sind nicht nur der Schlüssel des anfordernden Nutzers, sondern auch der Schlüssel erforderlich, der für den anderen Lizenzgeber L2 verschlüsselt wurde:
    Figure 00230001
  • Der Empfänger erwirbt die Nutzungslizenz UL2user für PLL2 von dem anderen Lizenzgeber:
    Figure 00230002
  • Der Empfänger extrahiert den Inhaltsschlüssel
    Figure 00230003
    aus UL2user unter Verwendung des eigenen Schlüssels Kuser und extrahiert den Inhaltsschlüssel KC unter Verwendung seines eigenen Schlüssels Kuser und des Inhaltsschlüssels
    Figure 00230004
  • Dieses zweite Szenario kann beispielhaft anhand einer Dokumenten-Rechtegewährungsrichtlinie dargestellt werden, die zwei Bedingungen beinhaltet: d. h., erstens die Bedingung, dass der Anfordernde innerhalb eines Verzeichnisdienstes identifiziert wird, auf den der lokale Server 400 des Empfängers zugreifen kann (d. h., dass sich der Anfordernde aktuell in einer bestimmten Zulassungsliste von Individuen befindet, die Zugriff auf das Dokument haben sollten), und zweitens, dass das Dokument auf einem Drucker gedruckt werden kann, der direkt von dem Nutzer gesteuert werden kann (in diesem Beispiel innerhalb einer bestimmten Reichweite, beispielsweise 20 Meter physischer Reichweite).
  • Die Identität und der Schlüssel des Servers 400 sind dem Veröffentlicher 302 bekannt, jedoch ist an dem Punkt, an dem die IRM-Richtlinie angewendet wird, nicht bekannt, welcher Lizenzgeber die Druckeranforderung validieren wird. Daher nutzt beim Verschlüsseln des Inhaltsschlüssels der Veröffentlicher 302 einen Schlüssel des Servers 400 und integriert beispielsweise eine Anweisung für die Server-Lizenzerzeugungseinrichtung 402, eine Lizenz-Interaktion mit der entsprechenden lokalen Lizenzerzeugungseinrichtung 408 anzufordern, in die Richtlinie.
  • Ein Software-Treiber auf dem Computer 304 des Empfängers wiederum umfasst, wie in 7 gezeigt, in diesem Fall eine lokale Empfänger-Lizenzerzeugungseinrichtung 408. Der Lizenzgeber 408 des Empfängers verwendet Verzeichnisdienst-Informationen 600, um den Standort eines Druckers 602 zu bestimmen.
  • 8 ist ein Flussdiagramm, das die Schritte des Validierens eines Versuches eines Anfordernden zeigt, auf ein Dokument unter Verwendung des in 7 gezeigten IRM-Systems zuzugreifen. Zunächst sendet der Veröffentlicher 302 das verschlüsselte Dokument zu dem Computer 304 des Anfordernden (Block 702). Wenn der Computer 304 des Anfordernden versucht, auf den Inhalt eines Dokumentes zuzugreifen, wird eine Anforderung zu dem lokalen Server 400 gesendet, und die Identität des Anfordernden wird anhand der in dem Verzeichnisdienst gespeicherten Liste validiert (Block 704). Wenn (wie angenommen) der Anfordernde in dem Verzeichnisdienst enthalten ist, entschlüsselt die Server-Lizenzerzeugungseinrichtung 402 den Inhaltsschlüssel und die Richtlinie und verschlüsselt dann den Inhaltsschlüssel und die gewährten Rechte erneut mit einem zusätzlichen Schlüssel der lokalen Lizenzerzeugungseinrichtung 408 (Block 706).
  • Um das Dokument zu entschlüsseln, muss die Lizenzerzeugungseinrichtung 408 eine Anforderung zu dem Verzeichnisdienst 600 senden, um festzustellen, ob sich der Drucker 602 in einer Entfernung von 20 Metern zu dem Empfänger befindet (Block 710). Wenn sich der Drucker 602 (wie angenommen) innerhalb einer Entfernung von 20 Metern befindet, führt die Empfänger-Lizenzerzeugungseinrichtung 408 eine Nutzungslizenz mit dem zusätzlichen Schlüssel zurück (Block 712), und der IRM-Client 316 des Empfängers kann dann den Inhaltsschlüssel entschlüsseln, so dass der Empfänger auf das Dokument zugreifen kann, das den gewährten Rechten unterliegt (Block 710).
  • Als weiteres Szenario dieses zweiten beispielhaften Falls, das in 9 dargestellt ist, enthält die Dokumenten-Rechtegewährungs-Richtlinie zwei Bedingungen: d. h. erstens die Bedingung, dass der Anfordernde in einem Verzeichnungsdienst identifiziert wird, auf den der lokale Server 400 des Empfängers zugreifen kann (d. h., dass sich der Anfordernde aktuell in einer bestimmten Zulassungsliste von Individuen befindet, die Zugriff auf das Dokument haben sollten), und zweitens, dass die Anzeige des Dokumenteninhaltes nicht gestattet ist, wenn ein Projektor mit dem Computer 304 des Empfängers verbunden ist. Die Identität des Servers 400 ist dem Veröffentlicher 302 bekannt, jedoch ist die Identität (und der Schlüssel) der Instanz, die die Anforderung bezüglich Projektoren validieren wird, nicht bekannt.
  • Diese zusätzliche Bedingung gewährleistet, dass das Dokument nicht unbeabsichtigt einem breiten Publikum gezeigt werden kann. Ein Software-Treiber, der lokal auf dem Computer 304 des Empfängers installiert ist, arbeitet als eine lokale Lizenzerzeugungseinrichtung 408, die prüft, ob ein Projektionsgerät, beispielsweise ein Projektor 802, an den Computer 304 des Empfängers angeschlossen ist (wenn ein Projektionsgerät angeschlossen ist, könnten vertrauliche Informationen möglicherweise einem größeren Publikum gezeigt werden, als dies beabsichtigt ist, und nicht nur dem Empfänger).
  • Eine Lizenz wird, wie oben angemerkt, normalerweise innerhalb einer begrenzten Gültigkeitszeit, d. h. einer Lebensdauer, erteilt. Die Lebensdauer kann von der angewendeten Richtlinie abhängen. Beispielsweise kann eine Lizenz, die basierend darauf erteilt wird, dass der Empfänger Mitglied einer Verzeichnis-Sicherheitsgruppe ist, eine relativ lange Gültigkeitszeit eines ganzes Arbeitstages haben, da diese Daten relativ statisch sind. Jedoch kann es bei einer Lizenz, die basierend darauf erteilt wird, dass der Computer des Empfängers nicht mit einem Projektor 802 verbunden ist, empfehlenswert sein, für eine relativ kurze Lebensdauer zu sorgen, so beispielsweise von ein paar Minuten, da es einfach ist, einen Projektor 802 anzuschließen. Das im Folgenden unter Bezugnahme auf das Flussdiagramm in 10 beschriebene Beispiel steht für ein Verfahren, bei dem zwei Lizenzerzeugungseinrichtungen 402, 408 Richtlinien mit unterschiedlicher Lebensdauer anwenden können.
  • 10 ist ein Flussdiagramm, das die Schritte beim Validieren eines Versuchs eines Anfordernden zeigt, auf den Inhalt eines Dokumentes unter Verwendung des in 9 gezeigten IRM-Systems zuzugreifen. Zunächst sendet der Veröffentlicher 302 das verschlüsselte Dokument zu dem Computer 304 des Anfordernden (Block 902). Wenn der Computer 304 des Anfordernden versucht, auf den Inhalt des Dokumentes zuzugreifen, wird eine Anforderung zu dem lokalen Server 400 gesendet, und die Identität des Anfordernden wird anhand der in dem Verzeichnisdienst gespeicherten Liste validiert (Block 904). Wenn (wie angenommen wird) der Anfordernde in dem Verzeichnisdienst enthalten ist, entschlüsselt die Server-Lizenzerzeugungseinrichtung 402 den Inhaltsschlüssel und die Richtlinie, die die Nutzungsrechte beinhaltet, die in der Veröffentlichungslizenz angegeben wurden, und verschlüsselt den Inhaltsschlüssel und die gewährten Nutzungsrechte erneut mit einem zusätzlichen Schlüssel, der für den lokalen Lizenzgeber geschützt ist (Block 906). Dann wird eine Anforderung zu dem Gerätedienst 800 des Computers 304 des Empfängers gesendet, um festzustellen, ob ein Projektor 802 an den Computer 304 des Anfordernden angeschlossen ist (Block 908). Wenn (wie angenommen) keine angeschlossenen Peripheriegeräte aufgelistet sind oder keines der angeschlossenen Peripheriegeräte ein Projektor ist, führt die Empfänger-Lizenzerzeugungseinrichtung 408 eine Nutzungslizenz zu dem Empfänger mit einer begrenzten Lebensdauer zurück, die den zusätzlichen Schlüssel enthält (Block 910). Der Inhalt des Dokumentes wird dem Empfänger nunmehr entsprechend den in der Nutzungslizenz angegebenen Einschränkungen zur Verfügung gestellt (Block 912).
  • Nach ihrer angegebenen Lebensdauer (die in diesem Beispiel kürzer ist als die der von dem Server erteilten Nutzungslizenz) läuft die durch den lokalen Lizenzgeber 408 erteilte Lizenz aus (Block 914). Neue Versuche, auf das Dokument zuzugreifen (beispielsweise es anzuzeigen), werden unter der Kontrolle des IRM-Client 116 (Block 916) des Empfängers nicht zugelassen, bis festgestellt wird, ob der Empfänger einen Projektor an seinen Computer 304 angeschlossen hat, seit dem die Lizenz erteilt wurde.
  • Dieser Zeitraum des Aussetzens von Zugriff kann, wie für den Fachmann auf der Hand liegt, einem Nutzer verborgen bleiben. Da der Prozess, der erforderlich ist, um den Nutzer erneut zu validieren, Prüfen eines lokalen Verzeichnisses umfasst, kann dies relativ schnell (und mit relativ geringer Rechenleistung) ausgeführt werden. Es ist zu bemerken, dass Durchführen dieser Prüfung keinen Zugriff auf ein Netzwerk erfordert und daher durch keine Verbindungsprobleme, wie beispielsweise starken Netzwerkverkehr oder verloren gegangene Verbindung, verzögert wird. Die Prüfung und die Erteilung einer neuen Nutzungslizenz können daher ausgeführt werden, bevor einem Nutzer bewusst wird, dass Zugriff nicht mehr zulässig ist, beispielsweise unmittelbar nach dem Ablaufen der Nutzungslizenz.
  • Natürlich können in anderen Beispielen andere Peripheriegeräte als Projektoren bei dem Lizenzierungsprozess berücksichtigt werden (beispielsweise Lautsprecher, USB-Laufwerke usw.).
  • In einem dritten beispielhaften Fall enthält die ursprüngliche Veröffentlichungslizenz, die von dem Veröffentlicher erzeugt wurde, eine abhängige Veröffentlichungslizenz für einen delegierten Lizenzgeber. Dies bedeutet, dass ein erster Lizenzgeber eine Unterlizenz von dem delegierten zweiten Lizenzgeber erwerben muss. Der erste Lizenzgeber kann dann die Richtlinie aus der Veröffentlichungslizenz entschlüsseln, sie validieren und die Gesamt-Nutzungslizenz zu dem Empfänger zurückführen. Der Schlüssel beider Lizenzgeber ist zum Zeitpunkt der Erzeugung der Veröffentlichungslizenz bekannt.
  • Der Empfänger sendet die Veröffentlichungslizenz PLL1 zu dem ersten Lizenzgeber, um die Nutzungslizenz UL1user zu erwerben.
  • Figure 00270001
  • Der erste Lizenzgeber erwirbt die Nutzungslizenz UL2L1 für PLL2 von dem zweiten Lizenzgeber.
  • Figure 00270002
  • Erst nachdem er UL2L1 bezogen hat, ist der erste Lizenzgeber in der Lage, Richtlinie PL1 aus PLL1 zu entschlüsseln und zu validieren, und er stellt dann die Nutzungslizenz UL1user für den Empfänger zusammen und führt sie zurück. Die zu dem Empfänger zurückgeführten gewährten Rechte sind die Schnittmenge der gemäß PL1 und PL2 gewährten Rechte.
  • Figure 00270003
  • Der Empfänger extrahiert den Inhaltsschlüssel KC unter Verwendung des eigenen Schlüssels Kuser aus der Nutzungslizenz UL1user. Ein Beispiel für dieses Szenario bezieht sich auf sogenannte föderierte IRM-Server und ist schematisch in 11 dargestellt. Die Nutzungsrichtlinie erfordert zwei Validierungsstufen, bevor einem Empfänger eine Lizenz gewährt wird. Die Richtlinie legt fest, dass ein Dokument von jedem genutzt werden kann, der Organisation A bekannt ist und dem sie vertraut, um an einem angegebenen Zusammenarbeitsprojekt X mitzuarbeiten.
  • Bei diesem Szenario erzeugt (wie unter Bezugnahme auf das Flussdiagramm in 12 erläutert) Nutzer A ein Dokument mit einer Veröffentlichungslizenz von dem IRM-Server 150 der Organisation A, in der als allgemeine Richtlinie festgelegt ist, dass die Informationen in dem Dokument von jedem genutzt werden, der Organisation A bekannt ist und dem sie vertraut, um an einem angegebenen Zusammenarbeitsprojekt X mitzuarbeiten.
  • Das Dokument wird, wie oben dargelegt, auf spezielle Weise so zusammengestellt (Block 170), dass, wenn Nutzer B von Organisation B versucht, auf die Daten zuzugreifen, Nutzer B aufgefordert wird, eine Nutzungslizenz von dem IRM-Server 160 von Organisation B anzufordern (Block 172). Der IRM-Server 160 von Organisation B nutzt seinen Lizenzgeber 162, um die Beteiligung von Empfänger B an Projekt X zu validieren. Bevor jedoch der IRM-Server von Organisation B eine Nutzungslizenz für Nutzer B erzeugen kann, muss der IRM-Server von Organisation B eine Nutzungslizenz von dem IRM-Server 150 von Organisation A beziehen. Dies ermöglicht es Organisation A zu validieren, ob Organisation B vertrauenswürdig ist (Block 176). Wenn dies der Fall ist, führt der Server von Organisation A eine Nutzungslizenz einschließlich eines Schlüssels zurück, der es dem IRM-Server 160 von Organisation B ermöglicht, den Inhaltsschlüssel zu entschlüsseln und Nutzer B eine Nutzungslizenz zu erteilen (Block 178). Nutzer B kann dann entsprechend den gewährten Rechten, die in der durch den IRM-Server 160 von Organisation B erteilten Nutzungslizenz enthalten sind, auf das Dokument zugreifen.
  • Die oben beschriebenen Szenarien stellen einige Beispiele eines breiten Spektrums von Szenarien für verschiedene Anwendungszwecke und Industriezweige dar, in denen gesteuerte gemeinsame Nutzung von Informationen erforderlich ist. Wie aus dem Obenstehenden ersichtlich wird, schließt dies IRM-Systeme ein, in denen mehrere Lizenzgeber in dem System verteilt sind und die zu unterschiedlichen Zeiten gewährte Rechte neu erteilen können.
  • Obwohl mit einigen hier offenbarten Maßnahmen die Sicherheit erhöht wird, betrifft die vorliegende Offenbarung nicht speziell die Bedrohungsmodelle der hier offenbarten Systeme. Es wird davon ausgegangen, dass der Client-Anwendung und -Umgebung und letztendlich dem Nutzer dahingehend vertraut wird, dass sie die gewährten Rechte effektiv umsetzen/befolgen, wenn der Nutzer Zugriff auf die Informationen hat. Empfänger, die keinen Anspruch auf Zugriffsrechte auf die Informationen haben, werden kryptografisch daran gehindert. Natürlich können in realen Systeme andere Sicherheitsmaßnahmen im Zusammenhang mit dem hier offenbarten IRM-System ergriffen werden.
  • 13 stellt verschiedene Komponenten einer beispielhaften computerbasierten Vorrichtung 1000 dar, die in jeder beliebigen Form einer Computer- und/oder elektronischen Vorrichtung implementiert werden kann und in der Ausführungsformen eines Information-Rights-Management-Servers, eines Veröffentlichers 302, eines empfangenden Computers 304 eines Empfängers oder eines Lizenzgebers implementiert werden können.
  • Die computerbasierte Vorrichtung 1000 umfasst einen oder mehrere Eingänge 1004, die von jedem beliebigen Typ sind, mit dem Eingaben, wie beispielsweise eine Eingabe von einem Empfänger, empfangen werden, die eine Anforderung zum Erteilen einer Lizenz und dergleichen umfassen. Die Vorrichtung 1000 umfasst des Weiteren eine Kommunikationsschnittstelle 1008 zum Kommunizieren mit anderen Instanzen, wie beispielsweise Information-Rights-Management-Servern, Empfängern, Veröffentlichern und anderen Kommunikationsnetzwerk-Knoten.
  • Die computerbasierte Vorrichtung 1000 umfasst des Weiteren einen oder mehrere Prozessoren 1001, die Mikroprozessoren, Controller oder jeder beliebige andere geeignete Typ Prozessor sein kann, zum Verarbeiten durch Computer ausführbarer Befehle, mit denen die Funktion der Vorrichtung gesteuert wird, um die Funktionen eines Information-Rights-Management-Servers, eines Veröffentlichers oder eines Empfängers zu erfüllen. Plattform-Software, die ein Betriebssystem 1002 umfasst, oder jede beliebige andere geeignete Plattform-Software kann an der computerbasierten Vorrichtung vorhanden sein, um Anwendungs-Software 1005 auf der Vorrichtung 1000 ausführen zu können.
  • Die durch Computer ausführbaren Befehle können unter Verwendung beliebiger computerlesbarer Medien, wie beispielsweise Speicher 1003, bereitgestellt werden. Bei dem Speicher handelt es sich um jeden beliebigen Typ, wie beispielsweise Direktzugriffsspeicher (RAM), eine Plattenspeichervorrichtung jedes beliebigen Typs, wie beispielsweise eine magnetische oder optische Speichervorrichtung, ein Festplattenlaufwerk oder ein CD-, DVD- oder anderes Plattenlaufwerk. Auch Flash-Speicher, EPROM oder EEPROM kann verwendet werden.
  • Ein Ausgang 1007 kann ebenfalls vorhanden sein, so beispielsweise ein Audio- und/oder Videoausgang zu einem Anzeigesystem, das integral mit der computerbasierten Vorrichtung vorhanden ist oder mit ihr in Verbindung steht. Das Anzeigesystem kann eine grafische Nutzerschnittstelle oder eine andere Nutzerschnittstelle jedes beliebigen geeigneten Typs bereitstellen, obwohl dies nicht wesentlich ist.
  • Der hier verwendete Begriff „Computer” bezieht sich auf jede beliebige Vorrichtung, die Verarbeitungskapazität aufweist, so dass sie Befehle ausführen kann. Der Fachmann weiß, dass derartige Verarbeitungskapazitäten in viele verschiedene Vorrichtungen integriert sind und daher der Begriff „Computer” PC, Server, Mobiltelefone, PDA und viele andere Vorrichtungen einschließt.
  • Die hier beschriebenen Verfahren können durch Software in maschinenlesbarer Form auf einem Speichermedium ausgeführt werden. Die Software kann zur Ausführung auf einem parallelen Prozessor oder einem seriellen Prozessor geeignet sein, so dass die Verfahrensschritte in jeder beliebigen geeigneten Reihenfolge oder simultan ausgeführt werden können.
  • Damit wird berücksichtigt, dass Software eine geldwerte, separat handelbare Ware ist. Dies soll sich auch auf Software beziehen, die auf „unintelligenter” oder Standard-Hardware läuft, um die gewünschten Funktionen auszuführen. Es soll des Weiteren Software einschließen, die die Konfiguration von Hardware „beschreibt” oder definiert, so beispielsweise HDL-Software (hardware description language software), wie sie beim Design von Siliziumchips eingesetzt wird oder zum Konfigurieren universaler programmierbarer Chips, um gewünschte Funktionen zu erfüllen.
  • Der Fachmann weiß, dass Speichervorrichtungen, die zum Speichern von Programmbefehlen eingesetzt werden, über ein Netzwerk verteilt sein können. Beispielsweise kann ein Remote-Computer ein Beispiel des Prozesses speichern, das als Software beschrieben ist. Ein lokaler bzw. Terminal-Computer kann auf den Remote-Computer zugreifen und die Software teilweise oder vollständig herunterladen, um das Programm auszuführen. Als Alternative dazu kann der lokale Computer Elemente der Software nach Bedarf herunterladen oder einige Software-Befehle an dem lokalen Terminal oder an dem Remote-Computer (oder Computernetzwerk) ausführen. Der Fachmann weiß auch, dass unter Einsatz herkömmlicher Methoden, die dem Fachmann bekannt sind, die Software Befehle vollständig oder teilweise durch eine dedizierte Schaltung, wie beispielsweise einen DSP, ein programmierbares logisches Feld (programmable logic array) oder dergleichen ausgeführt werden kann.
  • Für den Fachmann ist klar, dass jeder beliebige hier aufgeführte Bereich oder Vorrichtungs-Wert erweitert oder geändert werden kann, ohne dass die beabsichtigte Wirkung verlorengeht.
  • Es versteht sich, dass sich die oben beschriebenen Vorzüge und Vorteile auf eine Ausführungsform/ein Beispiel beziehen können oder sich auf mehrere Ausführungsformen/Beispiele beziehen können. Die Ausführungsformen/Beispiele sind nicht auf diejenigen beschränkt, die eines oder alle der aufgeführten Probleme lösen, oder diejenigen, die einen oder alle der aufgeführten Vorzüge und Vorteile aufweisen. Des Weiteren versteht sich, dass, wenn auf „ein” Objekt Bezug genommen wird, sich dies auf eines oder mehrerer dieser Objekte bezieht.
  • Die Schritte der hier beschriebenen Verfahren können in jeder beliebigen geeigneten Reihenfolge oder gegebenenfalls simultan ausgeführt werden. Des Weiteren können einzelne Blöcke aus jedem beliebigen der Verfahren entfernt werden, ohne vom Geist und vom Schutzumfang des hier beschriebenen Gegenstandes abzuweichen. Aspekte beliebiger der oben beschriebenen Beispiele können mit Aspekten beliebiger der anderen beschriebenen Beispiele kombiniert werden, um weitere Beispiele auszubilden, ohne dass der beabsichtigte Effekt verlorengeht.
  • Es versteht sich, dass die obenstehende Beschreibung einer bevorzugten Ausführungsform lediglich als Beispiel dient und dass verschiedene Abwandlungen vom Fachmann vorgenommen werden können. Die obenstehende Patentbeschreibung, die Beispiele und Daten bilden eine komplette Beschreibung des Aufbaus und des Einsatzes beispielhafter Ausführungsformen der Erfindung. Obwohl verschiedene Ausführungsformen der Erfindung oben mit einer gewissen Ausführlichkeit bzw. unter Bezugnahme auf eine oder mehrere einzelne Ausführungsform/en beschrieben worden sind, kann der Fachmann verschiedene Veränderungen an den offenbarten Ausführungsformen vornehmen, ohne vom Geist oder vom Schutzumfang der vorliegenden Erfindung abzuweichen.

Claims (20)

  1. Verfahren zum Verwalten von Informationsrechten, das die folgenden Schritte umfasst: Empfangen einer Anforderung einer Veröffentlichungslizenz für ein Datenobjekt, wobei die Anforderung Einzelheiten (420) einer Informationsrechte-Richtlinie umfasst, die Bedingungen einschließen, die Validierung durch wenigstens zwei Lizenzgeber erfor dern; Verschlüsseln des Datenobjektes mit einem Inhaltsschlüssel; Erteilen einer Veröffentlichungslizenz auf Basis der Details der Informationsrechte-Richtlinie, wobei die Veröffentlichungslizenz wenigstens eines der folgenden Elemente umfasst: (I) eine Verschlüsselung des Inhaltsschlüssels unter Verwendung eines Schlüssels, der aus durch wenigstens zwei Lizenzgeber geschützten Schlüsseln hergeleitet wird, die Validierung wenigstens einer Richtlinien-Bedingung durch jeden dieser Lizenzgeber erfordert; (II) eine Verschlüsselung des Inhaltsschlüssels mit einem Schlüssel eines ersten Lizenzgebers und einer Informationsrechte-Richtlinie, aus der ein Befehl für eine Neuverschlüsselung des Inhaltsschlüssels mit einem Schlüssel wenigstens eines zweiten Lizenzgebers resultiert und die Validierung wenigstens einer Richtlinien-Bedingung wenigstens durch den zweiten Lizenzgeber erfordert; (III) eine Verschlüsselung des Inhaltsschlüssels mit einem Schlüssel eines ersten Lizenzgebers und mit wenigstens einem Schlüssel, der durch wenigstens einen weiteren Lizenzgeber geschützt ist, die Validierung wenigstens einer Richtlinien-Bedingung durch den wenigstens einen weiteren Lizenzgeber erfordert.
  2. Verfahren nach Anspruch 1, wobei die Veröffentlichungslizenz eine Verschlüsselung des Inhaltsschlüssels mit Inhaltsschlüsseln von Unter-Veröffentlichungslizenzen umfasst, die durch entsprechende Lizenzgeber zu verarbeiten sind, das Verfahren des Weiteren Empfangen einer Anforderung einer Nutzungslizenz von einem Nutzer wenigstens an dem ersten und dem zweiten Lizenzgeber umfasst, und jede Anforderung eine Veröffentlichungslizenz umfasst.
  3. Verfahren nach Anspruch 2, das des Weiteren Validieren der Anforderung einer Lizenz wenigstens an dem ersten und dem zweiten Lizenzgeber und Erteilen einer Nutzungslizenz (506, 510), die den durch diesen Lizenzgeber entschlüsselten Schlüssel umfasst, an jedem Lizenzgeber umfasst, wenn die durch ihn zu validierenden Bedingungen erfüllt sind.
  4. Verfahren nach Anspruch 3, wobei die durch den Lizenzgeber erteilte Nutzungslizenz zu einem Schlüssel des Nutzers (204) verschlüsselt wird.
  5. Verfahren nach einem der Ansprüche 2 bis 4, wobei wenigstens die durch den ersten Lizenzgeber erteilte Lizenz oder die durch den zweiten Lizenzgeber erteilte Lizenz eine Lebensdauer (910) hat und das Verfahren umfasst, dass nach Ablauf der Lebensdauer (914) weiterer Zugriff auf das Datenobjekt (916) verhindert wird.
  6. Verfahren nach einem der vorangehenden Ansprüche, wobei die Veröffentlichungslizenz eine Rechte-Richtlinie umfasst, aus der ein Befehl zum Wiederverschlüsseln des Inhaltsschlüssels mit einem Schlüssel eines zweiten der Lizenzgeber resultiert, und das Verfahren des Weiteren Empfangen einer Anforderung einer Nutzungslizenz von einem Nutzer an dem ersten Lizenzgeber, und, wenn (704, 904) die durch ihn zu validierenden Bedingungen erfüllt sind, Erteilen einer bedingten Veröffentlichungslizenz an dem ersten Lizenzgeber (706, 906), die einen Inhaltsschlüssel und eine Richtlinie umfasst, die für den zweiten Lizenzgeber verschlüsselt sind, als Teil einer Nutzungslizenz umfasst, die den Schlüssel des ersten Lizenzgebers (304, 306, 308, 310, 400, 150, 160) umfasst.
  7. Verfahren nach Anspruch 6, das des Weiteren Empfangen der bedingten Veröffentlichungslizenz an dem zweiten Lizenzgeber, und, wenn (710, 908) die durch ihn zu validierenden Bedingungen erfüllt sind, Erteilen einer Nutzungslizenz an dem zweiten Lizenzgeber (304, 306, 308, 310, 400, 150, 160) umfasst, die den durch diesen Lizenzgeber (304, 306, 308, 310, 400, 150, 160) entschlüsselten Schlüssel umfasst.
  8. Verfahren nach Anspruch 7, wobei wenigstens die durch den ersten Lizenzgeber (304, 306, 308, 310, 400, 150, 160) erteilte Lizenz oder die durch den zweiten Lizenzgeber (304, 306, 308, 310, 400, 150, 160) erteilte Lizenz eine Lebensdauer hat und das Verfahren umfasst, dass nach Ablauf der Lebensdauer weiterer Zugriff auf das Datenobjekt (916) verhindert wird.
  9. Verfahren nach Anspruch 7, wobei die durch wenigstens einen Lizenzgeber (304, 306, 308, 310, 400, 150, 160) erteilte Nutzungslizenz zu einem Schlüssel des Nutzers (204) verschlüsselt wird.
  10. Verfahren nach einem der vorangehenden Ansprüche, wobei die Veröffentlichungslizenz eine abhängige Veröffentlichungslizenz umfasst, die die Validierung einer Richtlinien-Bedingung durch Bezugnahme auf einen zweiten Lizenzgeber erfordert, und das Verfahren des Weiteren Empfangen einer Anforderung einer Nutzungslizenz von einem Nutzer an dem ersten Lizenzgeber, Veranlassen, dass der erste Lizenzgeber eine Nutzungslizenz von dem zweiten Lizenzgeber erwirbt, und, wenn die Nutzungslizenz von dem zweiten Lizenzgeber bezogen ist, Erteilen einer Nutzungslizenz an dem ersten Lizenzgeber (304, 306, 308, 310, 400, 150, 160) umfasst, die den durch diesen Lizenzgeber (304, 306, 308, 310, 400, 150, 160) entschlüsselten Schlüssel umfasst.
  11. Verfahren nach Anspruch 10, wobei die durch den ersten Lizenzgeber (304, 306, 308, 310, 400, 150, 160) erteilte Nutzungslizenz einen Inhaltsschlüssel umfasst, der zu dem Schlüssels des Nutzers (204) verschlüsselt ist.
  12. Verfahren nach Anspruch 10 oder 11, wobei wenigstens die durch den ersten Lizenzgeber (304, 306, 308, 310, 400, 150, 160) erteilte Lizenz oder die durch den zweiten Lizenzgeber (304, 306, 308, 310, 400, 150, 160) erteilte Lizenz eine Lebensdauer (910) hat und das Verfahren umfasst, dass nach Ablauf der Lebensdauer Zugriff auf das Datenobjekt (916) verhindert wird.
  13. Information-Rights-Management-Lizenzgeber (304, 306, 308, 310, 400, 150, 160), der umfasst: einen Eingang (1004), der zum Empfangen einer Anforderung einer Nutzungslizenz eingerichtet ist, wobei die Lizenz erforderlich ist, um auf den Inhalt eines Datenobjektes zuzugreifen; einen Prozessor (1001), der so eingerichtet ist, dass er die Anforderung einer Lizenz auf Basis von Informationsrechte-Richtlinien-Bedingungen validiert und eine Nutzungslizenz erzeugt, die eine mit einem Schlüssel wenigstens eines anderen Lizenzgebers (304, 306, 308, 310, 400, 150, 160) verschlüsselte Veröffentlichungslizenz umfasst; und einen Ausgang (1007), der so eingerichtet ist, dass er eine Lizenz erteilt, die den Befehl zum Anfordern einer Lizenz von wenigstens einem anderen Lizenzgeber (304, 306, 308, 310, 400, 150, 160) enthält.
  14. Information-Rights-Management-Lizenzgeber nach Anspruch 13, der eine Komponente eines IRM-Servers (400) umfasst.
  15. Information-Rights-Management-Lizenzgeber nach Anspruch 14, der eine Komponente eines Computers (304) eines Empfängers umfasst.
  16. Ein oder mehrere durch Vorrichtungen lesbare/s Medium/Medien mit durch Vorrichtungen ausführbaren Befehlen zum Erstellen einer zusammengesetzten Lizenz für ein Information-Rights-Management-System, das die folgenden Schritte umfasst: (I) Beziehen (420) eines Datenobjektes mit einer Information-Rights-Mangement-Richtlinie und einem Inhaltsschlüssel; (II) Durchführen (422) einer Verschlüsselung eines Inhaltsschlüssels für das Datenobjekt und einer Information-Rights-Managment-Richtlinie unter Verwendung des Schlüssels wenigstens einer ersten Lizenzierungsinstanz (304, 306, 308, 310, 400, 150, 160); (III) Erstellen (424) der zusammengesetzten Lizenz mit der Verschlüsselung des Inhaltsschlüssels, der Verschlüsselung der Information-Rights-Mangement-Richtlinie und einer Gruppe von Unterlizenzen, die Bedingungen enthält, die durch wenigstens eine zweite Lizenzierungsinstanz (304, 306, 308, 310, 400, 150, 160) validiert werden können.
  17. Ein oder mehrere durch Vorrichtungen lesbare/s Medium/Medien mit durch Vorrichtungen ausführbaren Befehlen zum Erstellen einer zusammengesetzten Lizenz für ein Information-Rights-Management-System nach Anspruch 16, das des Weiteren den Schritt des Durchführens einer Verschlüsselung des Inhaltsschlüssels unter Verwendung des Schlüssels einer zweiten Lizenzierungsinstanz (304, 306, 308, 310, 400, 150, 160) umfasst.
  18. Ein oder mehrere durch Vorrichtungen lesbare/s Medium/Medien mit durch Vorrichtungen ausführbaren Befehlen zum Erstellten einer zusammengesetzten Lizenz für ein Information-Rights-Management-System nach Anspruch 16 oder Anspruch 17, wobei die Gruppe von Unterlizenzen eine Null-Gruppe ist.
  19. Ein oder mehrere durch Vorrichtungen lesbare/s Medium/Medien mit durch Vorrichtungen ausführbaren Befehlen zum Erstellen einer zusammengesetzten Lizenz für ein Information-Rights-Management-System nach einem der Ansprüche 16 bis 18, wobei die zusammengesetzte Lizenz eine Nutzungslizenz ist.
  20. Ein oder mehrere durch Vorrichtungen lesbare/s Medium/Medien mit durch Vorrichtungen ausführbaren Befehlen zum Erstellen einer zusammengesetzten Lizenz für ein Information-Rights-Management-System nach einem der Ansprüche 16 bis 19, wobei die zusammengesetzte Lizenz eine Veröffentlichungslizenz ist.
DE102009017221A 2008-04-11 2009-04-09 Information-Rights-Management Withdrawn DE102009017221A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12/101,345 US20090259591A1 (en) 2008-04-11 2008-04-11 Information Rights Management
US12/101,345 2008-04-11

Publications (1)

Publication Number Publication Date
DE102009017221A1 true DE102009017221A1 (de) 2009-10-15

Family

ID=41060850

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102009017221A Withdrawn DE102009017221A1 (de) 2008-04-11 2009-04-09 Information-Rights-Management

Country Status (2)

Country Link
US (1) US20090259591A1 (de)
DE (1) DE102009017221A1 (de)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130132232A1 (en) * 2009-04-22 2013-05-23 Florian Pestoni System And Method For Digital Rights Management With Delegated Authorization For Content Access
US8763158B2 (en) * 2010-12-06 2014-06-24 Microsoft Corporation Directory service distributed product activation
KR20120070829A (ko) * 2010-12-22 2012-07-02 삼성전자주식회사 분산 네트워크 시스템에서 컨텐츠의 댓글을 공유하고 이용하는 장치 및 방법
US8528099B2 (en) 2011-01-27 2013-09-03 Oracle International Corporation Policy based management of content rights in enterprise/cross enterprise collaboration
US9165332B2 (en) 2012-01-27 2015-10-20 Microsoft Technology Licensing, Llc Application licensing using multiple forms of licensing
US20140282886A1 (en) * 2013-03-14 2014-09-18 TollShare, Inc. Content list sharing
US9697365B2 (en) * 2013-09-06 2017-07-04 Microsoft Technology Licensing, Llc World-driven access control using trusted certificates
US9424239B2 (en) 2013-09-06 2016-08-23 Microsoft Technology Licensing, Llc Managing shared state information produced by applications
US9355268B2 (en) 2013-09-06 2016-05-31 Microsoft Technology Licensing, Llc Managing access by applications to perceptual information
US9413784B2 (en) 2013-09-06 2016-08-09 Microsoft Technology Licensing, Llc World-driven access control
US9460273B2 (en) * 2014-10-29 2016-10-04 International Business Machines Corporation Automatic generation of license terms for service application marketplaces
US20160232369A1 (en) * 2015-02-11 2016-08-11 Ricoh Company, Ltd. Managing Access To Images Using Roles
US9910967B2 (en) 2015-07-27 2018-03-06 International Business Machines Corporation File origin determination
US10904101B2 (en) * 2017-06-16 2021-01-26 Cisco Technology, Inc. Shim layer for extracting and prioritizing underlying rules for modeling network intents
EP3763075A4 (de) * 2018-06-01 2021-09-29 Hewlett-Packard Development Company, L.P. Schlüsselverpackung für schlüsselverschlüsselung
CN111046350A (zh) * 2019-10-31 2020-04-21 贝壳技术有限公司 权限信息处理方法及系统

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0538464B1 (de) * 1991-05-08 1998-12-30 Digital Equipment Corporation Lizenz-verwaltungssystem
WO1993011480A1 (en) * 1991-11-27 1993-06-10 Intergraph Corporation System and method for network license administration
JP4206529B2 (ja) * 1998-09-17 2009-01-14 ソニー株式会社 コンテンツ管理方法及びコンテンツ記憶システム
US7680819B1 (en) * 1999-11-12 2010-03-16 Novell, Inc. Managing digital identity information
US7359507B2 (en) * 2000-03-10 2008-04-15 Rsa Security Inc. Server-assisted regeneration of a strong secret from a weak secret
US7010808B1 (en) * 2000-08-25 2006-03-07 Microsoft Corporation Binding digital content to a portable storage device or the like in a digital rights management (DRM) system
US7149722B1 (en) * 2000-09-28 2006-12-12 Microsoft Corporation Retail transactions involving distributed and super-distributed digital content in a digital rights management (DRM) system
US7103663B2 (en) * 2001-06-11 2006-09-05 Matsushita Electric Industrial Co., Ltd. License management server, license management system and usage restriction method
US8282475B2 (en) * 2001-06-15 2012-10-09 Igt Virtual leash for personal gaming device
US7065787B2 (en) * 2002-06-12 2006-06-20 Microsoft Corporation Publishing content in connection with digital rights management (DRM) architecture
US7523310B2 (en) * 2002-06-28 2009-04-21 Microsoft Corporation Domain-based trust models for rights management of content
US20040158731A1 (en) * 2003-02-11 2004-08-12 Microsoft Corporation Publishing digital content within a defined universe such as an organization in accordance with a digital rights management (DRM) system
WO2004092933A1 (en) * 2003-04-11 2004-10-28 Matsushita Electric Industrial Co., Ltd. Apparatus and method for flexible licensing of composite digital contents
US20070168294A1 (en) * 2003-12-25 2007-07-19 Mitsubishi Electric Corporation Digital content use right management system
US7376975B2 (en) * 2004-05-10 2008-05-20 Microsoft Corporation Enhancing digital rights management system security through policy enforcement
US7890428B2 (en) * 2005-02-04 2011-02-15 Microsoft Corporation Flexible licensing architecture for licensing digital application
US8091142B2 (en) * 2005-04-26 2012-01-03 Microsoft Corporation Supplementary trust model for software licensing/commercial digital distribution policy
KR100765750B1 (ko) * 2005-05-09 2007-10-15 삼성전자주식회사 브로드캐스트 암호화 방식에 따라 효율적으로암호화/복호화하는 방법 및 장치
US7747533B2 (en) * 2005-07-14 2010-06-29 Microsoft Corporation Digital application operating according to aggregation of plurality of licenses
US20070078773A1 (en) * 2005-08-31 2007-04-05 Arik Czerniak Posting digital media
JP2007310835A (ja) * 2006-05-22 2007-11-29 Sony Corp 管理装置、情報処理装置、管理方法および情報処理方法

Also Published As

Publication number Publication date
US20090259591A1 (en) 2009-10-15

Similar Documents

Publication Publication Date Title
DE102009017221A1 (de) Information-Rights-Management
DE602004011282T2 (de) Versenden einer Herausgeber-Benutzungslizenz off-line in einem digitalen Rechtesystem
DE602004009354T2 (de) Registrierung bzw. Unter-registrierung eines Servers für die Verwaltung digitaler Rechte in einer Architektur zur Verwaltung digitaler Rechte
DE60214632T2 (de) Multidomäne Berechtigung und Authentifizierung
DE112011100182B4 (de) Datensicherheitsvorrichtung, Rechenprogramm, Endgerät und System für Transaktionsprüfung
DE60218393T2 (de) Verbindungsloses Lizenzübertragungs- und Verteilungssystem
DE60316861T2 (de) Verfahren und Vorrichtung zur Verschlüsselung/Entschlüsselung von Daten
EP2409255B1 (de) Verfahren zur erzeugung von asymmetrischen kryptografischen schlüsselpaaren
DE102020125476A1 (de) Verfahren und vorrichtungen zum bestimmen einer herkunft für datenlieferketten
EP3452941B1 (de) Verfahren zur elektronischen dokumentation von lizenzinformationen
EP1209579A1 (de) System zur automatisierten Abwicklung von Transaktionen durch aktives Identitätsmanagement
DE112020000134T5 (de) Sicherer, mehrstufiger zugriff auf verschleierte daten für analysen
EP4016338A1 (de) Zugriffskontrolle auf in einer cloud gespeicherte daten
DE602005003631T2 (de) Ausschluss der Passwortaufdeckung bei Attributzertifikatausgabe
DE60318633T2 (de) Verwaltung digitaler rechte
DE112021002201T5 (de) Datenschutzorientierte Datensicherheit in einer Cloud-Umgebung
AT519025B1 (de) Verfahren zum Austausch von Datenfeldern von zertifizierten Dokumenten
DE112022000906T5 (de) Trennen von blockchain-daten
DE102007008948B4 (de) Verfahren und System zur Verfügungstellung digitaler Inhalte
EP2491513B1 (de) Verfahren und system zum bereitstellen von edrm-geschützten datenobjekten
DE112019003808B4 (de) Zweckspezifische Zugriffssteuerung auf Grundlage einer Datenverschlüsselung
DE60216056T2 (de) Verfahren und anordnung in einem kommunikationssystem
DE10251408A1 (de) Sicherer und vermittelter Zugriff für E-Dienste
EP2187282B1 (de) Verfahren zum Betreiben einer Anlage unter Verwendung von gegen unberechtigte Verwendung gesicherten Daten
EP2184695A1 (de) Verfahren zum Kombinieren von Daten mit einer zur Verarbeitung der Daten vorgesehenen Vorrichtung, korrespondierende Funktionalität zur Ausführung einzelner Schritte des Verfahrens und Computerprogram zur Implementierung des Verfahrens

Legal Events

Date Code Title Description
R082 Change of representative

Representative=s name: GRUENECKER, KINKELDEY, STOCKMAIR & SCHWANHAEUS, DE

R081 Change of applicant/patentee

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, REDMOND, US

Free format text: FORMER OWNER: MICROSOFT CORP. ONE MICROSOFT WAY, REDMOND, WASH., US

Effective date: 20150123

R082 Change of representative

Representative=s name: GRUENECKER PATENT- UND RECHTSANWAELTE PARTG MB, DE

Effective date: 20150123

R012 Request for examination validly filed
R120 Application withdrawn or ip right abandoned