DE60133312T2 - System und verfahren zur sicheren verteilung eines digitalen inhaltes in einem geteilten netzwerk - Google Patents

System und verfahren zur sicheren verteilung eines digitalen inhaltes in einem geteilten netzwerk Download PDF

Info

Publication number
DE60133312T2
DE60133312T2 DE60133312T DE60133312T DE60133312T2 DE 60133312 T2 DE60133312 T2 DE 60133312T2 DE 60133312 T DE60133312 T DE 60133312T DE 60133312 T DE60133312 T DE 60133312T DE 60133312 T2 DE60133312 T2 DE 60133312T2
Authority
DE
Germany
Prior art keywords
content
central authority
message
requester
respondent
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.)
Expired - Lifetime
Application number
DE60133312T
Other languages
English (en)
Other versions
DE60133312D1 (de
Inventor
Alain Durand
Christophe Laurent
Philippe Letellier
Original Assignee
Thomson Licensing SAS
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 Thomson Licensing SAS filed Critical Thomson Licensing SAS
Publication of DE60133312D1 publication Critical patent/DE60133312D1/de
Application granted granted Critical
Publication of DE60133312T2 publication Critical patent/DE60133312T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3224—Transactions dependent on location of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G06Q20/123—Shopping for digital content
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services

Description

  • Die Erfindung betrifft ein System und ein Verfahren zur Verteilung von digitalem Inhalt durch ein Zugriffsnetzwerk.
  • Allgemeiner Stand der Technik
  • Mit zunehmender Benutzung des Internets werden verteilte Zugriffsnetzwerke, in denen Benutzer digitale Inhalte zum Zugriff vorschlagen, immer beliebter. Beispiele für solche Systeme sind der Browser und das Kommunikationssystem NAPSTER (bereitgestellt von Napster Inc.), wodurch Benutzer MP3-Dateien (unter Verwendung des Kompressionsformats MP3 komprimierte Audiodateien – „MP3" steht für „Moving Pictures Experts Group Phase 1, audio layer 3") auszutauschen, oder das verteilte Informationszugriffssystem GNUTELLA (bereitgestellt von Wego.com, Inc.).
  • Ein Problem bei diesen Systemen besteht darin, daß die Inhalte gewöhnlich von bestimmten Benutzern kostenlos an andere verteilt werden. Die Verteilungsprotokolle hinter diesen Systemen berücksichtigen nicht die Rechteverwaltung von urheberrechtlich geschützten Inhalten und verlassen sich ausschließlich auf den guten Willen von Benutzern. Dies führt zu einem hohen Niveau unerlaubten Kopierens und wichtigen Verlusten für Anbieter von urheberrechtlich geschütztem Inhalt, die außerhalb dieser Zugriffsnetzwerke gelassen werden und keinerlei Einkommen für die Verteilung der von ihnen erstellten Inhalte erhalten.
  • In der Schrift US-A-6 029 141 wird ein auf dem Internet basierendes Softwaresystem und -verfahren offenbart, das es als „Teilhabern" bezeichneten Entitäten ermöglicht, für eine Kommission Produkte (z. B. Bücher) zu vermarkten, die von einer Händler-Internetsite vertrieben werden. Dieses System und Verfahren enthält jedoch keinerlei Sicherheitsmerkmale und kann Attacken von Hackern ausgesetzt sein (zum Beispiel um Kommission anstelle des „echten" Teilhabers zu erhalten).
  • Die Schrift WO-A-00/11871 offenbart ein Transaktionssystem, bei dem Heimbenutzer und Inhaltsanbieter unter der Kontrolle einer zentralen Autorität durch ein Zugriffsnetzwerk beteiligt sind.
  • Eine Aufgabe der vorliegenden Erfindung ist deshalb die Bereitstellung eines verteilten Zugriffssystems, bei dem urheberrechtlich geschützte Inhalte vor freier Verteilung geschützt sind. Eine weitere Aufgabe der Erfindung ist der Vorschlag eines sicheren Protokolls, das sichere kommerzielle Verteilung von Inhalten durch Zugriffsnetzwerke ermöglicht.
  • Kurzfassung der Erfindung
  • Die Erfindung betrifft ein System zum Verteilen eines digitalen Inhalts zu einem Anfordernden durch ein Zugriffsnetzwerk, dadurch gekennzeichnet, daß es folgendes umfaßt: eine zentrale Autorität; einen Antwortenden, der bei der zentralen Autorität registriert ist, mit Mitteln zum Verteilen einer dem Inhalt entsprechenden Datei an den Anfordernden im Austausch für einen von dem Anfordernden empfangenen Kaufbeweis. Die zentrale Autorität umfaßt folgendes: Mittel zum Herstellen einer Finanztransaktion mit dem Anfordernden zur Bezahlung durch den Anfordernden des von dem Antwortenden vorgeschlagenen Inhalts und zum Abliefern des Kaufbeweises an den Anfordernden; und ein Antwortenden-Begleichungsmittel zum Entlohnen des Antwortenden für den Kauf eines Inhalts durch einen Anfordernden.
  • Die Erfindung betrifft außerdem ein Verfahren zum Verteilen eines digitalen Inhalts durch ein Zugriffsnetzwerk unter Verwendung des oben erwähnten Systems mit Schritten, die für einen Antwortenden aus folgendem bestehen:
    • a) als Reaktion auf eine von einem Anfordernden durch das Zugriffsnetzwerk empfangenen Anforderung eines digitalen Inhalts, Senden von Inhaltskaufinformationsdaten zu dem Anfordernden; wobei die Inhaltskaufinformationsdaten eine durch eine zentrale Autorität erzeugte Kennung des Antwortenden und die zentrale Autorität identifizierende Daten enthalten;
    • b) Empfangen eines Kaufbeweises des digitalen Inhalts von dem Anfordernden, wobei der Kaufbeweis durch die zentrale Autorität geliefert wird;
    • c) Bereitstellen einer Datei für den Anfordernden, die dem digitalen Inhalt entspricht; und
    • d) Empfangen einer Entlohnung für die Verteilung des digitalen Inhalts von der zentralen Autorität.
  • Die Erfindung betrifft ferner ein Verfahren zum Verteilen eines digitalen Inhalts durch ein Zugriffsnetzwerk unter Verwendung des obenerwähnten Systems mit Schritten, die für einen Anfordernden aus folgendem bestehen:
    • i) Senden einer ersten Nachricht durch das Zugriffsnetzwerk, um einen digitalen Inhalt anzufordern;
    • j) Empfangen von Inhaltskaufinformationsdaten von einem Antwortenden, der eine dem Inhalt entsprechende Datei besitzt; wobei die Inhaltskaufinformationsdaten eine zentrale Autorität identifizierende Daten enthalten;
    • k) als Reaktion auf eine Finanztransaktion mit der zentralen Autorität, Empfangen eines Kaufbeweises des digitalen Inhalts;
    • l) Senden des Kaufbeweises zu dem Antwortenden; und
    • m) Empfangen einer dem digitalen Inhalt entsprechenden Datei.
  • Kurze Beschreibung der Zeichnungen
  • Die verschiedenen Merkmale und Vorteile der vorliegenden Erfindung und ihrer bevorzugten Ausführungsformen werden nun mit Bezug auf die beigefügten Zeichnungen beschrieben, die die vorliegende Erfindung veranschaulichen, aber ihren Schutzumfang nicht einschränken sollen. Es zeigen:
  • 1 das Prinzip eines Informationszugriffssystems.
  • 2a bis 2c ein Beispiel für Zugriffsnetzwerkarchitektur.
  • 3 das bevorzugte Protokoll zur Verteilung von digitalem Inhalt durch ein Zugriffsnetzwerk gemäß der Erfindung.
  • Beschreibung der bevorzugten Ausführungsformen
  • Die vorliegende Erfindung ist von dem zugrundeliegenden Informationszugriffssystem unabhängig, aber bestimmte von diesen Systemen benutzte Mechanismen müssen verstanden werden, bevor die ausführliche Beschreibung der Erfindung dargestellt wird.
  • 1 zeigt ein abstraktes Modell eines Informationszugriffssystems 100, in dem Hosts 101–106 durch ein Zugriffsnetzwerk 110 verbunden werden. Ein Host bedeutet sowohl einen Computer als auch eine spezifische Software, die auf diesem Computer läuft, um Nachrichten, die zur Implementierung des Zugriffsnetzwerks notwendig sind, zu erzeugen und zu bearbeiten. Bestimmte auf diesen Hosts eingeloggte Benutzer können Dateien vorschlagen, die digitale Inhalte zur gemeinsamen Nutzung mit anderen Benutzern enthalten. Zu diesen Dateien gehören Musikdateien, Videodateien, Bilddateien, Computerprogrammdateien usw.
  • Nachdem ein Benutzer, der zum Beispiel auf dem Host1 101 eingeloggt ist, eine Anforderung 120 eines spezifischen digitalen Inhalts in dem Zugriffsnetzwerk 110 gesendet hat, können alle Benutzer, die mit dem Zugriffsnetzwerk verbunden sind und dieser Anforderung entsprechende Dateien besitzen, durch Senden von Antworten 130 antworten. Diese Benutzer werden als Antwortende bezeichnet, während der Benutzer, der die Anforderung gesendet hat, ein Anfordernder ist.
  • Nach dem Empfang der Antworten kann der Anfordernde die Dateien, an denen er interessiert ist, auswählen und diese Dateien durch Herstellen einer Peer-zu-Peer-Verbindung zwischen dem Host, auf dem er eingeloggt ist, und dem Host, auf dem der Antwortende eingeloggt ist, herunterladen.
  • Jeder mit dem Zugriffsnetzwerk verbundene Benutzer kann ein Anfordernder und ein Antwortender sein.
  • In 2a bis 2c ist ein Beispiel für eine dem Informationszugriffssystem von 1 entsprechende Zugriffsnetzwerkarchitektur gezeigt. In diesem Netzwerk ist der Host1 101 mit dem Host2 102 und Host6 106 verbunden; Host2 102 ist selbst mit Host3 103, Host4 104 und Host5 105 verbunden. Jeder teilnehmende Host des Systems handelt sowohl als Client (ein Programm, das eine Anforderung sendet und auf Antwort wartet) als auch als ein Server (ein Programm, das auf eine Anforderung antwortet).
  • Jeder Host 102–106 in dem Netzwerk kann eine Nachricht zu seinen Nachbarn in dem Netzwerk senden. Jeder Host, der eine Nachricht empfängt, leitet diese Nachricht dann zu seinen Nachbarn weiter, was zu einer Ausbreitung der Nachricht in dem Netzwerk führt, bis die Nachricht abgelaufen ist oder alle Hosts des Netzwerks die Nachricht empfangen haben.
  • 2a zeigt ein solches Routing-System. In diesem Beispiel sendet der Host1 101 zuerst eine Nachricht M zu seinen Peers Host2 102 und Host6 106. Dann leitet Host2 102 diese Nachricht M zu seinen Peers 103–105 weiter. In diesem Moment haben alle Hosts in dem Netzwerk die Nachricht M empfangen.
  • 2b und 2c zeigen einen Mechanismus von Anforderung/Antwort. In 2b reicht Host1 101 eine Anforderung RQ an seine Peers 102 und 106 ein. Die Anforderung RQ wird weitergeleitet, bis alle Hosts des Netzwerks sie empfangen haben (oder bis die Anforderung abgelaufen ist). In diesem Beispiel sei angenommen, daß Host4 104 und Host6 106 in der Lage sind, der Anforderung RQ eine Antwort RS zu geben. In 2c senden diese Hosts 104 und 106 die Antwort RS, die in der Rückwärtsrichtung von RQ zu Host1 101 geroutet wird. Wenn die Anforderung RQ einer Anforderung durch einen auf Host1 eingeloggten Benutzer eines spezifischen digitalen Inhalts entspricht, kann dieser Benutzer wählen, auf welchem Host 104 oder 106, die eine Antwort RS gesendet haben, er die den digitalen Inhalt enthaltende Datei herunterlädt.
  • Das kommerzielle verteilte Zugriffssystem der Erfindung und das sichere Protokoll zur Verteilung von digitalem Inhalt in diesem System soll nun ausführlicher dargestellt werden.
  • Dieses System umfaßt klassische Handelnde eines Zugriffssystems:
    Anfordernde, die Benutzer darstellen, die Datei(en) anfordern, die digitalen Inhalt in dem Zugriffsnetzwerk enthalten; und
    Antwortende, die Benutzer darstellen, die Dateien für die gemeinsame Nutzung vorschlagen und die von Anfordernden angeforderte Dateien lokal auf ihrem Computer besitzen.
  • Wie bereits erwähnt, kann natürlich derselbe Benutzer sowohl als Anfordernder als auch als Antwortender handeln.
  • Im Gegensatz zu bekannten Zugriffssystemen des Stands der Technik bezahlen in dem System der Erfindung Anfordernde für den Inhalt, den sie erhalten möchten, und Antwortende erhalten Geld jedesmal, wenn sie einem Anfordernden einen Inhalt vorschlagen, und dieser ihn später kauft.
  • In dem Zugriffssystem der Erfindung wird deshalb eine neue Art von Handelndem hinzugefügt: die zentralen Autoritäten. Diese Entitäten sind Dritte, die für den Verkauf von Inhalten im Namen von Inhaltsanbietern verantwortlich sind. Genauer gesagt sind sie für die Entgegennahme von Bezahlungen von Anfordernden für in dem Netzwerk verkaufte Inhalte verantwortlich. Außerdem sind sie für das Weiterverteilen von Geld sowohl an den Antwortenden, der den Inhalt verteilt hat, als auch an den Inhaltsanbieter, der ihn erstellt hat, verantwortlich.
  • Jede zentrale Autorität arbeitet im Namen eines oder vorzugsweise mehrerer Inhaltsanbieter, wie zum Beispiel Musik-Hauptwirkende, Buchverleger, Softwareverleger usw. und ist für den Verkauf von durch diese bestimmten Inhaltsanbieter produzierten Inhalten verantwortlich. Es ist auch möglich, daß ein Inhaltsanbieter mit mehreren zentralen Autoritäten arbeitet, um seine Inhalte in dem Zugriffsnetzwerk zu verkaufen.
  • Die Kaufhandlung erfolgt zwischen der zentralen Autorität und einem Anfordernden, der einen interessanten Inhalt gefunden hat, der von einem Antwortenden in dem Zugriffsnetzwerk vorgeschlagen wird.
  • Der Antwortende erhält später eine Entlohnung dafür, an der Verteilung des Inhalts teilgenommen zu haben.
  • Bevor er Inhalte in dem Zugriffsnetzwerk verteilen und Geld von einer im Namen von Inhaltsanbietern handelnden zentralen Autorität erhalten kann, muß ein potentieller Antwortender jedoch bei dieser zentralen Autorität registriert sein. Wenn ein Antwortender Inhalte (urheberrechtlich geschützte Dateien) verteilen möchte, die von mehreren Inhaltsanbietern erstellt werden, die nicht dieselbe zentrale Autorität benutzen, muß der Antwortende bei allen beteiligten zentralen Autoritäten registriert sein, bevor er die Inhalte zur gemeinsamen Nutzung vorschlagen kann.
  • Der Registrationsprozeß kann auf mehrere Weisen durchgeführt werden: zum Beispiel per Email (elektronische Mail) oder eine Registrationszone auf der Website der zentralen Autorität. Am Ende des Registrationsprozesses wird dem Antwortenden durch die zentrale Autorität eine eindeutige Antwortendenkennung zugewiesen und diese Antwortendenkennung wird zu dem Antwortenden gesendet und in einer Datenbank der zentralen Autorität gespeichert.
  • Nachdem ein Antwortender bei einer zentralen Autorität registriert ist, ist er autorisiert, in dem Zugriffsnetzwerk Inhalte vorzuschlagen, die von Inhaltsanbietern erstellt wurden, in deren Namen die zentrale Autorität arbeitet.
  • 3 zeigt die an dem sicheren Protokoll der Erfindung zur Verteilung von Inhalten in einem Zugriffsnetzwerk beteiligten Handelnden und die während dieses Protokolls ausgetauschten Nachrichten.
  • Es wurden vier verschiedene Inhaltsanbieter in 3 dargestellt: ein Buchverleger 301, zwei Musik-Hauptwirkende: der Musik-Hauptwirkender 302 und der Musik-Hauptwirkende2 303 und ein Softwareverleger 304.
  • Außerdem sind vier zentrale Autoritäten in 3 dargestellt. Die zentrale Autorität1 201 arbeitet im Namen des Buchverlegers 301. Die zentrale Autorität2 202 arbeitet im Namen des Musik-Hauptwirkenden 302, während die zentrale Autorität3 für beide Musik-Hauptwirkende 302 und 303 arbeitet und die zentrale Autorität4 für den Softwareverleger 304 arbeitet. Diese Verbindungen zwischen Inhaltsanbietern und zentralen Autoritäten sind in 3 durch durchgezogene Linien dargestellt.
  • Es sollte beachtete werden, daß die Anzahl der Inhaltsanbieter und die Anzahl der zentralen Autoritäten nicht miteinander zusammenhängen und daß jeder Inhaltsanbieter mit mehreren zentralen Autoritäten arbeiten kann. Auf dieselbe Weise kann jede zentrale Autorität im Namen mehrerer Inhaltsanbieter arbeiten.
  • Tatsächlich bedeutet der Ausdruck „zentrale Autorität", der in der folgenden Beschreibung verwendet wird, sowohl die Entität selbst (die zum Beispiel ein Händler sein kann) als auch einen Computer oder Server dieser Entität, auf dem bestimmte Software läuft, um das nachfolgend beschriebene Protokoll zu implementieren.
  • Außerdem sind in 3 ein Anfordernder und ein Antwortender 300 dargestellt. Es soll angenommen werden, daß vor dem Senden der ersten Nachricht zum Suchen nach einem spezifischen Inhalt der Anfordernde 200 und der Antwortende 300 beide mit dem Zugriffsnetzwerk 110 verbunden sind. Der Verbindungsmechanismus liegt außerhalb des Schutzumfangs der vorliegenden Erfindung und verwendet das zugrundeliegende Zugriffsprotokoll.
  • Die nachfolgend verwendeten Ausdrücke „Anfordernder" und „Antwortender" bedeuten beide einerseits einen Computer und auf diesem laufende Software zur Bildung eines Hosts des Zugriffsnetzwerks als auch andererseits eine natürliche Person, die diesen Computer benutzt, um entweder in dem Zugriffsnetzwerk nach einem digitalen Inhalt zu suchen (Anfordernder) oder um seine digitale Inhalte enthaltenden Dateien zur gemeinsamen Nutzung vorzuschlagen (Antwortender). Wie bereits erwähnt, kann eine selbe natürliche Person und ein Host natürlich manchmal ein Anfordernder und manchmal ein Antwortender sein.
  • 3 zeigt die von den oben beschriebenen Handelnden ausgetauschen Nachrichten während einer Suche und eines Kaufs eines digitalen Inhalts in dem Zugriffsnetzwerk 110 genauer.
  • In der folgenden Beschreibung des Protokolls zur Verteilung von digitalem Inhalt soll angenommen werden, daß alle (geschützte digitale Inhalte enthaltende) Dateien, die von dem Anfordernden angefordert werden, von der zentralen Autorität3 203 produziert wurden, bei der der Antwortende registriert ist. Natürlich kann der Antwortende Dateien verteilen, die von mehreren zentralen Autoritäten erstellt werden. In diesem Fall muß der Antwortende bei allen diesen zentralen Autoritäten registriert sein und muß über eine Möglichkeit verfügen, die richtige zentrale Autorität gemäß der angeforderten Datei abzurufen.
  • Eine mögliche Implementierung zum Erstellen einer einen geschützten digitalen Inhalt enthaltenden Datei in dem Computer eines Antwortenden wird nachfolgend beschrieben.
  • Anhand des Beispiels der Audioinhalte soll angenommen werden, daß der Antwortende eine CD (Abkürzung für „Compact Disc") gekauft hat, die mehrere Lieder enthält, wobei diese CD von dem Musik-Hauptwirkenden2 303 produziert wird. Wenn der Antwortende diese Lieder mit potentiellen Anfordernden teilen (und Entlohnung dafür erhalten) möchte, legt er die CD zuerst in den CD- oder DVD- (Abkürzung für „Digital Versatile Disc") Player seines Computers ein. Durch die Benutzeroberfläche der auf seinem Computer laufenden Zugriffsnetzwerksoftware wählt der Anfordernde, welche Lieder er für die gemeinsame Nutzung vorschlagen möchte. Die im Namen des Musik-Hauptwirkenden2 303 arbeitende zentrale Autorität (hier die zentrale Autorität3 203) wird dann durch den Antwortenden zum Beispiel durch Eingabe der URL (Abkürzung für „Uniform Resource Locator", wdurch eine eindeutige Adresse definiert wird, die den Ort einer Datei oder anderer Resource im Internet voll spezifiziert) der Website der zentralen Autorität3 203 (zum Beispiel in dem die CD begleitenden Heftchen angegeben) in seinem Web-Browser kontaktiert.
  • Wenn sich der Antwortende bereits bei der zentralen Autorität3 203 registriert hat, gibt er dann die Lieder an, die er in dem Zugriffsnetzwerk verteilen möchte, und erhält von der zentralen Autorität3 203 die (die Lieder zum Beispiel in einem komprimierten Format enthaltenden) entsprechenden Dateien, die eine Kennung der zentralen Autorität3 203 und andere Informationen, wie zum Beispiel den Preis des Lieds, umfassen.
  • Wenn der Antwortende nicht bei der zentralen Autorität3 203 registriert ist, muß er sich zuerst wie oben erläutert bei dieser zentralen Autorität registrieren, bevor er die Dateien erhält, die den Liedern entsprechen, die er für die gemeinsame Nutzung vorschlagen möchte.
  • Die auf dem Computer des Anfordernden laufende Zugriffsnetzwerksoftware speichert dann die von der zentralen Autorität3 203 empfangenen Dateien an einer bestimmten Stelle des Speichermediums des Computers.
  • Wieder mit Bezug auf 3 empfängt ein Anfordernder 200, wenn er eine Anfrage zu dem Zugriffsnetzwerk 110 sendet (im Schritt 1 gesendete Nachricht Query), Antworten, wenn bestimmte mit dem Netzwerk verbundene Benutzer Dateien besitzen, die die Anfrage des Anfordernden erfüllen.
  • In 3 soll angenommen werden, daß der Antwortende 300 lokal eine Datei (oder bestimmte Dateien) besitzt, die die im Schritt 1 vom Anfordernden gesendete Anfrage erfüllt. Wenn die Datei (d. h. der digitale Inhalt) kostenlos verfügbar ist, wird das klassische Protokoll nach dem Stand der Technik verwendet. Wenn dagegen die Datei (d. h. der Inhalt) urheberrechtlich geschützt ist, besitzt der Antwortende lokal Informationen über den Preis der Datei. Diese Preisinformationen wurden zuvor durch die zentrale Autorität (hier die zentrale Autorität3 203) geliefert, die im Namen des Inhaltsanbieters arbeitet, der den angeforderten Inhalt produziert hat (hier der Musik-Hauptwirkende2 303).
  • Diese Preisinformationen weisen jedoch ein Ablaufdatum auf, das es der zentralen Autorität ermöglicht, den Preis der Datei mit der Zeit zu ändern. Wenn die Preisinformationen, die durch den Antwortenden gespeichert (oder genauer gesagt in dem Speichermedium des Computers des Antwortenden gespeichert) werden, abgelaufen sind, fordert der Antwortende neue Preisinformationen für die von dem Anfordernden 200 angeforderte bestimmte Datei von der zentralen Autorität3 203 an, indem er eine PriceInfoRequest-Nachricht 2 sendet.
  • Diese PriceInfoRequest-Nachricht 2, die optional ist (sie wird nicht gesendet, wenn die durch den Antwortenden gespeicherten Preisinformationen der Datei nicht abgelaufen sind) ist in 3 mit einem gestrichelten Pfeil dargestellt, genauso wie alle optionalen Nachrichten, die bei dem Protokoll der Erfindung gesendet werden können.
  • Wenn die zentrale Autorität 203 eine PriceInfoRequest-Nachricht 2 empfängt, antwortet sie mit einer PriceInfoResponse-Nachricht 3, die die neuen Preisinformationen für die angeforderte Datei enthält. Diese Nachricht weist ein Ablaufdatum auf. Es sollte zusätzlich beachtet werden, daß die von der zentralen Autorität zurückgegebenen Preisinformationen vorzugsweise von der Identität des Antwortenden abhängen. Tatsächlich können bestimmte Antwortende aktiv an der Verteilung von urheberrechtlich geschützten Dateien teilnehmen und können somit Vereinbarungen mit zentralen Autoritäten haben, Dateien zu niedrigeren Preisen zu verkaufen und/oder interessantere Preisspannen.
  • Wenn der Antwortende über nicht abgelaufene Preisinformationen der Datei verfügt, die einen in der Query-Nachricht 1 angeforderten digitalen Inhalt enthält, sendet er eine QueryHits-Nachricht 4, die Informationen enthält, die der Anfordernde benötigt, um seine Wahl zu treffen und die Datei zu kaufen. Zu diesen Informationen gehören der Dateiname, die Dateigröße, die Qualität der Datei (z. B. ein Aufzeichnungsmodus im Fall von Audiodateien, eine Version für eine Softwaredatei usw.), der Preis, der Name der zentralen Autorität (bzw. URL), bei der die Datei gekauft werden kann, das von der zentralen Autorität akzeptierte Bezahlungsprotokoll, die (durch die zentrale Autorität erzeugte und dem Antwortenden am Ende des oben beschriebenen Registrationsprozesses gebende) Antwortendenkennung.
  • Bei einer bevorzugten Implementierung läuft die Zugriffsnetzwerksoftware permanent auf dem Computer des Antwortenden, wenn der Antwortende mit dem Zugriffsnetzwerk 110 verbunden ist, und die Nachrichten QueryHits und/oder PriceInfoRequest werden automatisch durch diese Software ohne jegliche Intervention des Antwortenden (als natürliche Person) erzeugt.
  • Ein Anfordernder kann mehrere QueryHits-Nachrichten von verschiedenen mit dem Zugriffsnetzwerk verbundenen Antwortenden empfangen. Beim Empfang dieser Antworten auf seine Anfrage kann der Anfordernde seine Wahl treffen. Zum Beispiel kann der Anfordernde den besten Preis wählen, einen Kompromiß zwischen Preis und Qualität finden oder eine bevorzugte zentrale Autorität auswählen, bei der er Vorzugsvereinbarungen hat usw.
  • Während die Nachrichten Query 1 und QueryHits 4 zwischen dem Anfordernden 200 und dem Antwortenden 300 durch das Zugriffsnetzwerk 110 (unter Verwendung eines von dem zugrundeliegenden Zugriffssystem abhängigen Routing-Mechanismus) geroutet werden, schaltet es, nachdem der Anfordernde einen Antwortenden gewählt hat, auf eine Punk-zu-Punkt-Kommunikation mit dem Antwortenden um. Eine Punkt-zu-Punkt-Kommunikation (die auch als „Peer-to-Peer"-Kommunikation bekannt ist) besteht aus dem Austausch von Nachrichten zwischen zwei identifizierten Hosts des Zugriffsnetzwerks, im Gegensatz zu dem mit Bezug auf 2a und 2c erläuterten Mechanismus.
  • Alle nachfolgend beschriebenen anderen Nachrichten, die zwischen dem Anfordernden und dem Antwortenden ausgetauscht werden, sind Punkt-zu-Punkt-Nachrichten.
  • Weiterhin kann der Anfordernde wahlweise durch Senden einer AskPreview-Nachricht 5 zu dem Antwortenden eine Vorschau der Datei erbeten. Dieses Merkmal ist besonders im Fall einer urheberrechtlich geschützten Datei interessant: es kann sich im Fall einer Musikdatei um eine kurze Zeit Musik handeln, oder eine Demonstrationsversion im Fall einer Software oder einen kurzen Clip im Fall einer Videodatei usw.
  • Wenn der Anfordernde 200 um eine Vorschau bittet, antwortet der Antwortende 300 durch Senden einer Preview-Nachricht 6 und sendet dem Anfordernden eine Vorschau der angeforderten Datei.
  • Wenn sich der Anfordernde 200 entscheidet, viele Dateien zu kaufen, die urheberrechtlich geschützten Inhalt enthalten (zum Beispiel wenn die Anfrage aus der Suche nach allen Liedern eines Sängers besteht, können dieser Anfrage mehrere Dateien entsprechen), kann er wahlweise durch Senden einer InfoRequest-Nachricht 7 zu dem Antwortenden 300 um einen Vorzugspreis bitten. Nach dem Empfang dieser Nachricht fordert der Antwortende 300 im Namen des Anfordernden 200 Vorzugspreise an, indem er eine PriceInfoRequest-Nachricht 2 zu der zentralen Autorität 203 sendet, und erhält eine PriceInfoResponse-Nachricht 3 von der zentralen Autorität 203.
  • Dann sendet der Antwortende die Vorzugspreise in einer InfoResponse-Nachricht 8 zu dem Anfordernden. Wenn die zentrale Autorität keine Vorzugspreise akzeptiert hat, ist diese Nachricht leer.
  • Bei einer bevorzugten Ausführungsform werden die Nachrichten PriceInfoRequest und InfoResponse automatisch durch die auf dem Anfordernden ablaufende Software ohne jegliche „menschliche" Intervention erzeugt.
  • Wenn der Anfordernde 200 mit den von dem Antwortenden 300 erhaltenen Bedingungen zufrieden ist, kann er der in Nachrichten QueryHits 4 und wahlweise InfoResponse 8 enthaltenen Informationen den Kauf der angeforderten Datei(en) tätigen. Vorzugsweise verwendet der Kaufschritt das World Wide Web, um die existierende Bezahlungsinfrastruktur zu erhalten. Der Anfordernde 200 kontaktiert die zentrale Autorität 203 (unter Verwendung der in der QueryHits-Nachricht 4 enthaltenen URL der zentralen Autorität) und führt eine sichere Finanztransaktion 9 mit der zentralen Autorität durch. Während dieser Transaktion sendet der Anfordernde bestimmte in der QueryHits-Nachricht enthaltene Daten (wie zum Beispiel die Antwortendenkennung). Das Ergebnis dieser Transaktion 9 ist die Bezahlung der zentralen Autorität 203 für die urheberrechtlich geschützte Datei bzw. die urheberrechtlich geschützten Dateien.
  • Die zentrale Autorität kann später einerseits den Inhaltsanbieter und andererseits den Antwortenden 300 für seine Teilnahme an der Verteilung der Datei(en) bezahlen. Die Bezahlung des Antwortenden kann durch eine Gutschrift auf ein Konto des Antwortenden erfolgen, das während des Registrationsprozesses durch die zentrale Autorität geöffnet wird.
  • Am Ende der Finanztransaktion 9 liefert die zentrale Autorität 203 ein (in der PaymentTicket-Nachricht 10 gesendetes) Bezahlungsticket zu dem Anforderden 200, das beweist, daß der Anfordernde für Datei(en) bezahlt hat. Dieses Bezahlungsticktet wird in einer Nachricht FwdPaymentTicket 11 zu dem Antwortenden 300 weitergeleitet, der die gekaufte Datei bzw. gekauften Dateien verteilt hat. Beim Empfang dieser Nachricht 11 verifiziert der Antwortende 300 die Validität des Bezahlungstickets und der Antwortende antwortet, wenn die Verifizierung erfolgreich ist, indem er alle zum Herunterladen der angeforderten Datei(en) notwendigen Informationen in einer DownloadInfo-Nachricht 12 zu dem Anfordernden sendet. Dann beginnt der Anfordernde 200 die Operation Download 13 der gekauften Datei(en).
  • Angesichts der Sensitivität bestimmter Daten, die in den in dem oben beschriebenen Protokoll ausgetauschten Nachrichten enthalten sind, ist es notwendig, diese Nachrichten vor einer etwaigen möglichen Attacke während ihrer Übertragung zu schützen.
  • Es sollen nun die Sicherheitsbedürfnisse des Systems zur Verteilung von digitalem Inhalt gemäß der Erfindung, und wie sie bei der bevorzugten Ausführungsform der Erfindung erfüllt werden, weiter beschrieben werden.
  • Im Verlauf der vorliegenden Beschreibung werden die folgenden Schreibweisen und Abkürzungen verwendet:
    • ,
    bedeutet den Verkettungsoperator;
    {M}+
    bedeutet die n-malige Wiederholung der Nachricht M mit n > 0
    PBSK
    bedeutet einen öffentlichen Signaturverifikationsschlüssel;
    PRSK
    bedeutet einen privaten Signaturschlüssel;
    SK
    bedeutet einen symmetrischen Schlüssel;
    MK
    bedeutet einen symmetrischen Master-Schlüssel;
    DK
    bedeutet einen symmetrischen abgeleiteten Schlüssel;
    SSK
    bedeutet einen symmetrischen Sitzungsschlüssel;
    ESK(M)
    bedeutet die symmetrische Verschlüsselung der Nachricht M unter Verwendung des symmetrischen Schlüssels SK;
    SPRSK A(M)
    bedeutet die Signatur der Nachricht M unter Verwendung des privaten Signaturschlüssels PRSK von A;
    H(M)
    bedeutet den Hash-Wert der Nachricht M unter Verwendung der Hash-Funktion H.
  • Vorzugsweise werden die folgenden kryptographischen Algorithmen zur Implementierung des Systems und Verfahrens der Erfindung verwendet:
    • AES
    (Abkürzung für „Advanced Encryption Standard") wird zur symmetrischen Verschlüsselung verwendet. Weitere Einzelheiten über den AES-Standard finden sich in der Internet-Publikation „NIST, Advanced Encryption Standard Development Effort", bei http://csrc.nist.gov/encryption/aes", und in „DAEMEN J. und RIJMEN V., „The Rijndeal Block Cipher", AES Proposal, bei http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf".
    RSA
    (Abkürzung für „Rivest Shamir Adelman", die Namen der Verfasser dieses Algorithmus) mit „SHA-1" als Hash-Funktion wird als Signaturalgorithmus verwendet. Dieser Algorithmus wird dem Standard PKCS #1 v2.1: entsprechen, der in der folgenden Internet-Publikation beschrieben wird: „RSA Laboratories, „PKCS #1 v2.1: RSA Cryptography Standard", September 1999 (Entwurf-Status), http://www.rsalabs.com/pkcs/pkcs-1".
    SHA-1
    wird als Hash-Funktion H verwendet (Informationen über die Funktion SHA-1 finden sich in „NIST, SIPS PUB 180-1, „Secure Hash Standards", April 1995").
  • Bei der bevorzugten Implementierung der Erfindung ist die Größe der kryptographischen Schlüssel wie folgt:
    1024 Bit für Signaturschlüssel;
    128 Bit für symmetrische Schlüssel.
  • Zuerst sollte das System dem Anfordernden folgendes garantieren:
  • a) Anonymität:
  • Der Antwortende sollte die Identität des Anfordernden nicht kennen. Er sollte nicht in der Lage sein, mehrere Käufe miteinander zu verbinden, d. h. zu wissen, ob zwei verschiedene Käufe von demselben Anfordernden kommen oder nicht.
  • Um diese Anonymität sicherzustellen, wird bei einer bevorzugten Implementierung die Identität des Anfordernden hinter seiner IP-Adresse verborgen (IP ist die Abkürzung für „Internet-Protocol"). Wie in den meisten Fällen wird diese Adresse jeder Internetverbindung dynamisch zugewiesen; deshalb kann der Antwortende zwei verschiedene Anforderungen nicht in Verbindung bringen.
  • b) Sicherheit der Bezahlung:
  • Der Antwortende sollte sicher sein, daß eine Bezahlung sicher ist.
  • Dies wird durch das Bezahlungsprotokoll selbst sichergestellt, das in der Finanztransaktion 9 verwendet wird, gleichgültig worum es sich handelt, wie zum Beispiel SET (Abkürzung für „Secure Electronic Transaction", Informationen darüber in „Loeb L., „Secure Electronic Transactions: Introduction and Technical Reference", Artech House Publishers, 1998") oder SSL (Abkürzung für „Secure Socket Layer", ein wohlbekanntes im Internet verwendetes Bezahlungsprotokoll) oder ein Mikrobezahlungs-Protokoll.
  • c) Kaufbeweis:
  • Der Antwortende sollte sicher sein, daß der Kaufbeweis, den er von der zentralen Autorität erhält (d. h. das in der Nachricht 10 erhaltene Bezahlungsticket) gültig ist und es ihm immer erlaubt, die von ihm gekaufte Datei zu erhalten. Niemand anderes als er kann diesen Kaufbeweis benutzen. Zusätzlich sollte der Antwortende in der Lage sein, diesen Beweis zu verifizieren, der auch durch den Antwortenden überprüfbar sein sollte.
  • Bei einer bevorzugten Ausführungsform wird der Kaufbeweis, (d. h. das Bezahlungsticket, unter Verwendung eines privaten Signaturschlüssels PRSKCA wie später erläutert werden wird) durch die zentrale Autorität signiert, bevor er zu dem Anfordernden gesendet wird, um seine Validität zu beweisen. Dieses signierte Bezahlungsticket enthält vorzugsweise Informationen über den gekauften Inhalt und die Identität des Antwortenden (d. h. die Antwortendenkennung, die der Anfordernde in der QueryHits-Nachricht 4 erhalten hat).
  • Damit es nicht von einem Hacker, der die PaymentTicket-Nachricht 10 möglicherweise abfängt, benutzt werden kann, wird letzteres (tatsächlich das signierte Bezahlungsticket) zusätzlich durch die zentrale Autorität verschlüsselt, bevor es zu dem Anfordernden gesendet wird. Es wird unter Verwendung eines Schlüssels KPAY verschlüsselt, der bereits in dem während der Finanztransaktion 9 verwendeten Bezahlungsprotokoll verwendet (oder erzeugt) wurde und den der Anfordernde und die zentrale Autorität gemeinsam nutzen. Zum Beispiel definieren die Protokolle SET und SSL solche Schlüssel.
  • Um die Übertragung des Bezahlungstickets zwischen dem Anfordernden und dem Antwortenden in der FwdPaymentTicket-Nachricht 11 zu sichern, wird darüber hinaus ein symmetrischer Sitzungsschlüssel SSK verwendet, um einen verschlüsselten Kanal zwischen dem Anfordernden und dem Antwortenden für die Übertragung der FwdPaymentTicket-Nachricht 11 zu erzeugen. Wie dieser Schlüssel SSK durch die zentrale Autorität erzeugt und sowohl von dem Anfordernden als auch dem Antwortenden gemeinsam benutzt wird, wird nachfolgend weiter erläutert.
  • Das System sollte ferner Antwortenden folgendes garantieren:
  • a) Privatheit:
  • Niemand anderes als der relevante Antwortende kann Informationen (Preise, Reduktionen ..., die für jeden Antwortenden verschieden sein können) über mit einer zentralen Autorität getroffene komerzielle Vereinbarungen erhalten.
  • Um diese Privatheit sicherzustellen, wird bei einer bevorzugten Implementierung die PriceInfoResponse-Nachricht 3 vor ihrer Übertragung zu dem Antwortenden durch die zentrale Autorität dergestalt verschlüsselt, daß nur der richtige Antwortende sie entschlüsseln kann. Vorzugsweise wird sie unter Verwendung eines symmetrischen Verschlüsselungsschlüssels DKPR verschlüsselt, den die zentrale Autorität während des Registrationsprozesses des Antwortenden erzeugt und der von einem (nur der zentralen Autorität bekannten) Master-Schlüssel MKPR und aus der antwortenden Kennung abgeleitet wird. Dieser Schlüssel DKPE, der für jeden Antwortenden verschieden ist, wird von der zentralen Autorität am Ende des Registrationsprozesses zusammen mit der Antwortendenkennung zu dem Antwortenden gesendet. Wenn ein Antwortender versucht, die Preiskonditionen eines Konkurrenten zu erfahren, empfängt er diese verschlüsselt und kann sie nicht entschlüsseln.
  • b) Korrektheit der Preisgebung:
  • Der Antwortende sollte sicher sein, daß von einer zentralen Autorität in der PriceInfoResponse 3 empfangene Preisinformationen gültig sind und somit weiter von dieser Autorität angenommen werden.
  • Bei einer bevorzugten Ausführungsform werden die Preisinformationen durch die zentrale Autorität (unter Verwendung des privaten Signaturschlüssels PRSKCA) signiert, bevor sie in der PriceInfoResponse-Nachricht 3 zu dem Antwortenden gesendet werden. Vorzugsweise enthalten die signierten Preisinformationen bestimmte Informationen über die für die gemeinsame Nutzung vorgeschlagene Datei, den Preis, die Zeitgrenze der Preisgültigkeit, die Antwortendenkennung, bestimmte Informationen über die Qualität der Datei, die von der zentralen Autorität akzeptierten Bezahlungsarten und die URL der zentralen Autorität.
  • c) Sicherstellung der Bezahlung:
  • Niemand außer dem relevanten Antwortenden sollte Bezahlung von einer zentralen Autorität erhalten.
  • Dies wird bei der bevorzugten Implementierung durch Vorlage des Kaufbeweises (d. h. Bezahlungsticket) beim Antwortenden (in der FwdPaymentTicket-Nachricht 11) sichergestellt, da die Antwortendenkennung in diesem von der zentralen Autorität erzeugten Beweis enthalten ist.
  • d) Vertraulichkeit:
  • Die zu dem Anfordernden in der DownloadInfo-Nachricht 12 gesendeten Herunterladeinformationen und der während der Download-Operation 13 herunterzuladende Inhalt sind während ihrer Übertragung zum Anfordernden vertraulich zu halten.
    Dies wird bei der bevorzugten Ausführungsform durch die Anwesenheit eines verschlüsselten Kanals zwischen dem Antwortenden und dem Anfordernden sichergestellt, wobei dieser verschlüsselte Kanal dank eines symmetrischen Sitzungsschlüssels SSK erzeugt wird, wie nachfolgend weiter beschrieben werden wird.
  • e) Beschränkung auf den Kauf:
  • Es sollte sichergestellt werden, daß der Anfordernde nichts außer dem von ihm gekauften Inhalt von dem Antwortenden erhalten kann.
  • Bei einer bevorzugten Implementierung besitzt der Computer des Antwortenden ein permanentes Verzeichnis, in dem alle Inhalte (d. h. alle von zentralen Autoritäten empfangene Dateien, wenn der Antwortende das Recht erlangt hat, die Inhalte auf dem Zugriffsnetzwerk zu verteilen) in einer verschlüsselten Form verfügbar sind (jeder Inhalt wird mit seinem ordnungsgemäßen Schlüssel Kcontent verschlüsselt). Dann sendet der Antwortende den Entschlüsselungsschlüssel Kcontent des gekauften Inhalts (über den verschlüsselten Kanal) in der DownloadInfo-Nachricht 12 zu dem Anfordernden und der Inhalt selbst wird in seiner verschlüsselten Form (unter Verwendung des Schlüssels Kcontent) in der Download-Information 13 zu dem Anfordernden gesendet. Integrität des Inhalts läßt sich erreichen, indem man in den gesendeten verschlüsselten Inhalt den Hash-Wert des Inhalts aufnimmt.
  • Eine alternative Lösung bestünde darin, daß der Antwortende dynamisch ein Verzeichnis erzeugt, in dem die gekauften Dateien abgelegt werden. Dieses Verzeichnis würde zerstört, nachdem die Download-Operation 13 stattfindet. Der Inhalt müßte dann im Verlauf durch den Antwortenden verschlüsselt werden, um durch den verschlüsselten Kanal zu dem Anfordernden gesendet zu werden.
  • Als letztes sollte das System zentralen Autoritäten die Gültigkeit der Bezahlung (d. h. den Umstand, daß die von ihnen empfangene Bezahlung gültig ist) sicherstellen. Dies wird durch das in der Finanztransaktion 9 verwendete Bezahlungsprotokoll sichergestellt.
  • Um die beschriebenen bevorzugten Ausführungsformen zu implementieren, um Sicherheit in dem Protokoll der Erfindung sicherzustellen, müssen mehrere kryptographische Schlüssel erzeugt und von den Handelnden des Systems gemeinsam benutzt werden, wie nachfolgend beschrieben wird.
  • Zuerst besitzt jede zentrale Autorität einen privaten Signaturschlüssel PRSKCA, mit dem die Preise und die Bezahlungen zertifiziert werden. Der assoziierte öffentliche Signaturverifikationsschlüssel PBSKCA muß zertifiziert werden. Bei einer bevorzugten Lösung wird vorgeschlagen, Quer-Zertifizierung zwischen den verschiedenen zentralen Autoritäten zu verwenden, wodurch der Aufbau einer umfangreichen Infrastruktur öffentlicher Schlüssel vermieden wird. Der Anfordernde muß dann mindestens einer zentralen Autorität vertrauen.
  • Darüber hinaus besitzt jede zentrale Autorität außerdem zwei symmetrische Master-Schlüssel MKPR (zum Schutz der Übertragung der Preisinformationen in der PriceInfoResponse-Nachricht 3) und MKEC (zum Aufbau eines verschlüsselten Kanals zwischen dem Antwortenden und dem Anfordernden). Zentrale Autoritäten verteilen bei seiner Registration an jeden Antwortenden zusätzlich zu der Antwortendenkennung zwei abgeleitete Schlüssel:
    Figure 00270001
  • Wie bei den Antwortenden müssen sie bei ihrer Registration die beiden abgeleiteten Schlüssel DKPR und DKEC erhalten. Außerdem müssen sie für jeden Inhalt, den sie durch das Zugriffsnetzwerk verteilen werden, einen symmetrischen Schlüssel Kcontent erzeugen. Jeder Inhalt wird in der folgenden Form in einem spezifischen Verzeichnis des Antwortenden gespeichert:
    Figure 00270002
  • Was Anfordernde angeht, benötigen sie im voraus keinen fest zugeordneten Schlüssel. Sie verwenden jedoch einen Schlüssel KPAY, der bei dem bei der Finanztransaktion 9 verwendeten Bezahlungsprotokoll verwendet wird und/oder in es eingebaut wird. Dieser Schlüssel KPAY dient zum Verschlüsseln des zwischen der zentralen Autorität und dem Anfordernden in der Nachricht PaymentTicket 10 gesendeten Bezahlungstickets.
  • Als Letztes wird bei jedem Kauf eines Inhalts ein symmetrischer Sitzungsschlüssel SSK erzeugt. Dieser Schlüssel SSK dient dann zum Erzeugen eines verschlüsselten Kanals zwischen dem Anfordernden und dem Antwortenden. Der Schlüssel SSK wird durch die zentrale Autorität nach der Finanztransaktion 9 erzeugt (während wenn die Antwortendenkennung ihr gesendet wurde). Die zentrale Autorität erzeugt erst einen Zufallswert R. Dann berechnet sie
    Figure 00280001
    Der Schlüssel DKEC wird durch die zentrale Autorität aus dem Master-Schlüssel MKEC und der Antwortendenkennung rekonstruiert:
    Figure 00280002
  • Der Sitzungsschlüssel SSK wird zusammen mit dem Zufallswert R in der PaymentTicket-Nachricht 10 (verschlüsselt mit dem Schlüssel KPAY) zu dem Anfordernden gesendet. Dann sendet der Anfordernde den Zufallswert R zu dem Antwortenden, der mit seinem Schlüssel
    Figure 00280003
    berechnen kann. Als Letztes teilen sich der Anfordernde und der Antwortende denselben Sitzungsschlüssel SSK und können deshalb einen verschlüsselten Kanal aufbauen.
  • Im folgenden Teil der Beschreibung soll eine ausführlichere Beschreibung des internen Inhalts der in dem in 3 gezeigten Protkoll ausgetauschten Nachrichten 1-13 gegeben werden. Diese Beschreibung ist natürlich eine mögliche Implementierung und sollte nicht als Einschränkung des Schutzumfangs der Erfindung aufgefaßt werden.
  • 1. Die Query-Nachricht 1:
  • Diese Nachricht wird von einem Anfordernden gesendet, um in dem Zugriffsnetzwerk 110 nach einer spezifischen Datei bzw. spezifischen Dateien zu suchen. Zu diesem Zweck tippt der Anfordernde ein Suchkriterium, das die angeforderte Datei bzw. angeforderten Dateien beschreibt. Zum Beispiel kann ein Suchkriterium „britneyspears*.mp3" angeben, daß der Anfordernde nach allen geteilen MP3-Dateien sucht, für die der Interpret „Britney Spears" ist.
  • Das ausführliche Nachrichtenformat ist in der folgenden Tabelle 1 dargestellt:
    Felder der Nachricht Beschreibung der Felder
    Query-Nachrichtendaten (Minimale Geschwindigkeit, Suchkriterien)
    Minimale Geschwindigkeit (2 Byte) Minimale Geschwindigkeit (in Kb/Sekunde) von Hosts, die mit einer QueryHit-Nachricht auf diese Nachricht antworten sollten.
    Suchkriterien (variable Länge) Durch Null abgeschlossene Suchzeichenkette.
    Tabelle 1
  • 2. Die PriceInfoRequest-Nachricht 2:
  • Diese Nachricht wird von einem Antwortenden zu einer zentralen Autorität gesendet, um Kaufinformationen (Preis, von der zentralen Authorität akzeptierte Bezahlungsmethoden usw.) für die urheberrechtlich geschützten Dateien, die von dem Antwortenden für gemeinsame Nutzung vorgeschlagen werden, anzufordern. In der Praxis besitzt der Antwortende lokal Kaufinformationen für alle seine urheberrechtlich geschützten gemeinsam genutzten Dateien. Diese Informationen weisen jedoch ein Ablaufdatum auf und müssen deshalb regelmäßig aufgefrischt werden.
  • Diese Nachricht kann zu verschiedenen Zeiten während der Prozedur gesendet werden:
    • – Zuerst kann sie von dem Antwortenden gesendet werden, bevor er urheberrechtlich geschützte Dateien für gemeinsame Nutzung vorschlägt. In diesem Fall verwendet der Antwortende diese Nachricht, um über anfängliche Kaufinformationen zu verfügen;
    • – Zweitens kann sie gesendet werden, nachdem der Antwortende eine InfoRequest-Nachricht 7 von dem Anfordernden empfangen hat. Die InfoRequest-Nachricht 7 wird von einem Anfordernden verwendet, um in bestimmten Situationen über Vorzugspreise zu verfügen (zum Beispiel wenn der Anfordernde sich entscheidet, viele Dateien zu kaufen);
    • – Sie kann auch jedesmal dann gesendet werden, wenn ein Antwortender erkennt, daß bestimmte lokale Kaufinformationen abgelaufen sind.
  • Diese PriceInfoRequest-Nachricht 2 enthält außerdem Informationen über die Antwortendenidentität. Tatsächlich kann der Antwortende im Out-Of-Band-Verfahren mit zentralen Autoritäten seine Preisspannen und/oder den Anfordernden vorgeschlagene Vorzugspreise aushandeln. Deshalb ermöglicht es die Anwesenheit der Antwortendenidentität in dieser Nachricht der zentralen Autorität, entsprechend dem Antwortenden die richtigen Preise vorzuschlagen.
  • Das ausführliche Nachrichtenformat ist in der nachfolgenden Tabelle 2 dargestellt:
    Felder der Nachricht Beschreibung der Felder
    PriceInfoRequest-Nachrichtendaten {ResponderID, ReqPurchaseNumber, {ReqPurchaseInfo}+}
    ResponderID (32 Byte) Von der zentralen Autorität während der Antwortendenregistration erzeugte Antwortendenkennung.
    ReqPriceNumber (1 Byte) Anzahl der angeforderten Kaufinformationen.
    ReqPurchaseInfo (Filelndex, FileSize, FileName, Qualität}
    FileIndex (4 Byte) Eindeutige Kennung, die die Datei repräsentiert, für die der Antwortende Preisinformationen anfordert.
    FileSize (4 Byte) Größe (in Byte) der durch FileIndex indizierten Datei.
    FileName (variable Länge) Durch doppelte Null abgeschlossene Zeichenkette, die den Namen der durch FileIndex indizierten lokalen Datei repräsentiert.
    Qualität (variable Länge) Durch doppelte Null abgeschlossene Zeichenkette, die ein Qualitätsmaß der durch FileIndex indizierten Datei repräsentiert.
    Tabelle 2
  • Es sollte folgendes beachtet werden:
    • – Das Feld ReqPurchaseInfo erscheint ReqPurchaseNumber mal in der PriceInfoRequest-Nachricht 2 (einmal für jede Datei, für die der Antwortende Kaufinformationen benötigt);
    • – Die Menge (FileIndex, FileSize, FileName, Qualität) muß auf der Antwortendenseite und der Seite der zentralen Autorität eine selbe Datei eindeutig identifizieren. Dadurch wird sichergestellt, daß die zentrale Autorität in der Lage ist, dem Antwortenden den richtigen Preis zu geben. Für diesen Zweck kann FileIndex einen Mechanismus verwenden, der ISBN für die Buchnumerierung ähnlich ist („ISBN" ist die Abkürzung für „International Standard Book Number").
  • 3. Die PriceInfoResponse-Nachricht 3:
  • Diese Nachricht wird von der zentralen Autorität zu dem Antwortenden gesendet und enthält Kaufinformationen, die vom Antwortenden in der PriceInfoRequest-Nachricht 2 angefordert werden. Diese Kaufinformationen enthalten alle Informationen, die ein Anfordernder benötigt, um eine herunterzuladende Datei auszuwählen, nachdem er eine Anfrage gesendet und Antworten von Antwortenden erhalten hat. Alle vorgeschlagenen Kaufinformationen weisen ein Ablaufdatum auf, und nachdem der Antwortende diese Informationen erhalten hat, müssen sie vom Antwortenden bis zu diesem Datum gespeichert werden.
  • Wie bereits erwähnt, sollte diese Nachricht vertraulich sein. Die in ihr enthaltenen Daten werden deshalb mit dem symmetrischen Schlüssel DKPR verschlüsselt, bevor sie zu dem Antwortenden gesendet werden.
  • Das ausführliche Nachrichtenformat ist in der nachfolgenden Tabelle 3 dargestellt:
    Figure 00330001
    Figure 00340001
    Figure 00350001
    Figure 00360001
    Tabelle 3
  • 4. Die QueryHits-Nachricht 4:
  • Diese Nachricht wird von einem Antwortenden als Reaktion auf eine von einem Anfordernden empfangene Query-Nachricht 1 gesendet. Wenn ein Antwortender lokal Dateien besitzt, die der Anfrage des Anfordernden entsprechen, antwortet der Antwortende mit einer QueryHits-Nachricht 4. Diese Nachricht sollte alle Daten enthalten, die der Anfordernde benötigt, um seine Wahl zu treffen.
  • Diese Wahl kann auf Mehrerem basieren:
    • – Preis: der Anfordernde sollte den Preis urheberrechtlich geschützter Dateien kennen;
    • – Preis/Qualität-Kompromiss: Der Anfordernde sollte die Qualität für die vorgeschlagenen Dateien kennen. Deshalb muß das kommerzielle verteilte Zugriffssystem ein Qualitätsmaß vorschlagen;
    • – Akzeptierte Bezahlungssysteme: der Anfordernde sollte wissen, ob er in der Lage ist, die angeforderten Dateien mit den vorgeschlagenen Bezahlungsmethoden zu bezahlen;
    • – Händlername (d. h. Name der zentralen Autorität): der Anfordernde kann bei bestimmten Händlern Vorzugsbeziehungen genießen.
  • Alle diese Daten wurden ursprünglich von der zentralen Autorität erzeugt, die für den Verkauf der entsprechenden Dateien verantwortlich ist. Deshalb wird der größte Teil dieser Nachricht aus der PriceInfoResponse-Nachricht 2 extrahiert.
  • Darüber hinaus schlägt diese Nachricht ein optionales Feld vor, das die URL der persönlichen Website des Antwortenden repräsentiert, wodurch der Anfordernde persönliche Informationen über den Antwortenden erhalten kann. Dieses Feld kann nützlich sein, falls der Anfordernde erkennt, daß der Antwortende viele interessante Dateien besitzt. Indem er seine Website-Adresse angibt, gibt der Antwortende dem Anfordernden eine Möglichkeit, auf Mehrwertdienste zuzugreifen, wie zum Beispiel einen vollständigen Dateikatalog, Email-Dienst, Chat usw.
  • Das ausführliche Nachrichtenformat ist in der nachfolgenden Tabelle 4 dargestellt:
    Felder der Nachricht Beschreibung der Felder
    QueryHits-Nachrichtendaten {HitNumber, PortNumber, IPAdress, Geschwindigkeit, [ResponderURL] {SignedPurchaseInfo}+}
    HitNumber (1 Byte) Anzahl der vom Antwortenden vorgeschlagenen gemeinsam benutzten Dateien, die die Anfrage des Anfordernden erfüllen.
    PortNumber (2 Byte) Transportschicht-Portnummer, die der Anfordernde verwenden muß, wenn er sich entscheidet, diesen Antwortenden als den Dateiverkäufer zu verwenden.
    IP-Adresse (4 Byte) IP-Adresse des Antwortenden, die der Anfordernde verwenden muß, wenn er sich dafür entscheidet, diesen Antwortenden als den Dateiverkäufer zu verwenden.
    Geschwindigkeit (4 Byte) Geschwindigkeit (in Kb/Sekunde) des Antwortenden.
    ResponderURL (variable Länge) Durch doppelte Null abgeschlossene Zeichenkette, die die Adresse der persönlichen Website des Antwortenden angibt. Dieses Feld ist optional und kann vom Anfordernden verwendet werden, um persönliche Informationen des Antwortenden und andere Mehrwertdienste (Chat, Email, usw.) zu finden.
    SignedPurchaseInfo Dieses Feld enthält alle Informationen über von dem Antwortenden für gemeinsame Nutzung vorgeschlagene Dateien, die die Anfrage des Anfordernden erfüllen. Dieses Feld wurde durch die zentrale Autorität erzeugt und signiert, um die PriceInfoResponse-Nachricht 3 aufzubauen, und wird aus dieser Nachricht extrahiert.
  • Es sollte folgendes beachtet werden:
    • – Das Feld SignedPurchaseInfo erscheint HitNumber mal in der QueryHits-Nachricht 4 (einmal für jede die Anforderung des Anfordernden erfüllende Datei);
    • – Die vom Antwortenden in dieser Nachricht gegebenen Preise werden von der zentralen Autorität, die für die Inhaltsanbieter, die die entsprechenden Inhalte produziert haben, arbeitet, auferlegt. Diese Preise sind dem Antwortenden dank des PriceInfoRequest/PriceInfoResponse-Nachrichtenpaars bekannt.
  • 5. Die AskPreview-Nachricht 5:
  • Diese optionale Nachricht wird von dem Anfordernden gesendet, um eine Vorschau einer spezifischen Datei zu erbitten. Diese Nachricht wird gesendet, sobald der Anfordernde eine QueryHits-Nachricht 4 empfangen hat. Durch Auswählen einer spezifischen Datei in der Liste der Vorschläge des Antwortenden kann der Anfordernde durch Senden dieser Nachricht eine Vorschau der Datei empfangen.
  • Es sollte beachtet werden, daß diese Nachricht eine Punkt-zu-Punkt-Nachricht ist und deshalb das Zugriffsnetzwerk 110 nicht durchquert. Für diesen Zweck verwendet sie die Felder IPAddress und PortNumber, die in der QueryHits-Nachricht 4 von dem Antwortenden empfangen werden.
  • Das ausführliche Nachrichtenformat ist in der nachfolgenden Tabelle 5 dargestellt:
    Felder der Nachricht Beschreibung der Felder
    AskPreview-Nachrichtendaten {FileIndex, FileSize, FileName, Qualität}
    FileIndex (4 Byte) Eindeutige Dateikennung. Dieses Feld wird aus der QueryHits-Nachricht 4 extrahiert.
    FileSize (4 Byte) Größe (in Byte) der durch FileIndex indizierten Datei. Dieses Feld wird aus der QueryHits-Nachricht 4 extrahiert.
    FileName (variable Länge) Durch doppelte Null abgeschlossene Zeichenkette, die den Namen der durch FileIndex indizierten lokalen Datei repräsentiert. Dieses Feld wird aus der QueryHits-Nachricht 4 extrahiert.
    Qualität (variable Länge) Durch doppelte Null abgeschlossene Zeichenkette, die ein Qualitätsmaß der durch FileIndex indizierten Datei repräsentiert. Dieses Feld wird aus der QueryHits-Nachricht 4 extrahiert.
    Tabelle 5
  • 6. Die Preview-Nachricht 6:
  • Diese Nachricht wird von dem Antwortenden verwendet, um eine in der AskPreview-Nachricht 5 vom Anfordernden angeforderte Vorschau zu senden. Die gesendete Vorschau wird nicht durch die Client-Software des Anfordernden interpretiert, sondern lokal gespeichert, um später durch den entsprechenden Player wiedergegeben zu werden.
  • Das ausführliche Nachrichtenformat ist in der nachfolgenden Tabelle 6 dargestellt:
    Felder der Nachricht Beschreibung der Felder
    Preview-Nachrichtendaten {FileIndex, FileSize, FileName, BitStream}
    FileIndex (4 Byte) Eindeutige Dateikennung. Dieses Feld wird aus der AskPreview-Nachricht 5 extrahiert.
    FileSize (4 Byte) Größe (in Byte) der durch FileIndex indizierten Datei. Dieses Feld wird aus der AskPreview-Nachricht 5 extrahiert.
    FileName (variable Länge) Durch doppelte Null abgeschlossene Zeichenkette, die den Namen der durch FileIndex indizierten lokalen Datei repräsentiert. Dieses Feld wird aus der AskPreview-Nachricht 5 extrahiert
    BitStream (variable Länge) BitStream, der die durch den Anfordernden in der AskPreview-Nachricht 5 angefordete Vorschau repräsentiert.
  • 7. Die InfoRequest-Nachricht 7:
  • Diese Nachricht ist optional und wird von dem Anfordernden verwendet, um Vorzugspreise für eine Menge von aus einer zuvor empfangenen QueryHits-Nachricht 4 ausgewählten Dateien zu erhalten. Diese Nachricht wird in der Regel verwendet, wenn ein Anfordernder viele Dateien kaufen möchte, wodurch solche Vorzugspreise gerechtfertigt werden können. Beim Empfang dieser Nachricht sendet der Antwortende eine neue PriceInfoRequest-Nachricht 2 zu der zentralen Autorität, um frische Preisinformationen zu erhalten.
  • Im Gegensatz zu den Nachrichten Query und QueryHits 1 und 2 wird diese Nachricht direkt durch eine Punkt-zu-Punkt-Verbindung zu dem Antwortenden gesendet, indem die Felder IPAddress und PortNumber verwendet werden, die in der QueryHits-Nachricht 4 enthalten sind. Deshalb wird diese Nachricht nicht durch das Zugriffsnetzwerk 110 geroutet.
  • Das ausführliche Nachrichtenformat ist in der nachfolgenden Tabelle 7 dargestellt:
    Felder der Nachricht Beschreibung der Felder
    InfoRequest-Nachrichtendaten {ReqInfoNumber, {ReqFileInfo}+}
    ReqInfoNumber (1 Byte) Anzahl der vom Antwortenden vorgeschlagenen gemeinsam benutzten Dateien, für die der Anfordernde Kaufinformationen erhalten möchte.
    ReqFileInfo {FileIndex, FileSize, FileName, Qualität}
    FileIndex (4 Byte) Zum eindeutigen Identifizieren der Datei, für die der Anfordernde Kaufinformationen erfragt, verwendeter Dateiindex. Dieses Feld wird aus der QueryHits-Nachricht 4 extrahiert.
    FileSize (4 Byte) Dieses Feld wird aus der QueryHits-Nachricht 4 extrahiert. Größe (in Byte) der durch FileIndex indizierten Datei und für die der Anfordernde Kaufinformationen erfragt.
    FilenName (variable Länge) Durch doppelte Null abgeschlossene Zeichenkette, die den Namen der durch FileIndex indizierten lokalen Datei repräsentiert und für die der Anfordernde Kaufinformationen erfragt. Dieses Feld wird aus der QueryHits-Nachricht 4 extrahiert.
    Qualität (variable Länge) Durch doppelte Null abgeschlossene Zeichenkette, die ein Qualitätsmaß der Datei repräsentiert, die durch FileIndex indiziert wird und für die der Anfordernde Kaufinformationen erfragt. Dieses Feld wird aus der QueryHits-Nachricht 4 extrahiert.
  • Es sollte beachtet werden, daß das ReqFileInfo-Feld ReqInfoNumber mal in der InfoRequest-Nachricht 7 erscheint (einmal für jede Datei, für die der Anfordernde Kaufinformationen benötigt).
  • 8. Die InfoResponse-Nachricht 8:
  • Diese Nachricht enthält alle vom Anfordernden in der InfoRequest-Nachricht 7 angeforderten Kaufinformationen. Darüber hinaus schlägt diese Nachricht ein optionales Feld vor, das die URL der persönlichen Website des Antwortenden repräsentiert, wodurch der Anfordernde persönliche Informationen über den Antwortenden erhält. Dieses Feld kann nützlich sein, falls der Anfordernde erkennt, daß der Antwortende viele interessante Dateien besitzt. Indem er seine Website-Adresse angibt, gibt der Antwortende dem Anfordernden eine Möglichkeit, auf Mehrwertdienste zuzugreifen, wie etwa einen vollständigen Dateikatalog, Email-Dienst, Chat usw.
  • Wie die InfoRequest-Nachricht 7 durchquert diese Nachricht nicht das Zugriffsnetzwerk 110, sondern wird direkt zu dem Anfordernden gesendet.
  • Das ausführliche Nachrichtenformat ist in der nachfolgenden Tabelle 8 dargestellt:
    Felder der Nachricht Beschreibung der Felder
    InfoResponseNachrichtendaten {[ResponderURL], PurchaseInfoNumber, {SignedPurchaseInfo}+}
    ResponderURL (variable Länge) Wenn es vorliegt, gibt dieses Feld die Website-Adresse des Antwortenden an, bei der der Anfordernde Mehrwertdienste finden kann.
    PurchaseInfoNumber (1 Byte) Anzahl der in dieser Nachricht enthaltenen Kaufinformationen.
    SignedPurchaseInfo Dieses Feld ist dasselbe wie das in der PriceInfoResponse-Nachricht 3 erzeugte und enthält alle vom Anfordernden angeforderten Preisinformationen.
  • Es sollte folgendes beachtet werden:
    • – Das SignedPurchaseInfo-Feld erscheint PurchaseInfoNumber mal in der InfoResponse-Nachricht 8 (einmal für jede Datei, für die der Anfordernde Kaufinformationen benötigt);
    • – Theoretisch (im besten Fall) besitzt das PurchaseInfoNumber-Feld denselben Wert wie das RegInfoNumber-Feld der InfoRequest-Nachricht 7. In bestimmten Fehlfunktionsfällen (Herunterfahren der zentralen Autorität, Crash der Datenbank usw.) ist der Antwortende möglicherweise jedoch nicht in der Lage, Kaufinformationen über bestimmte Dateien zu senden. In diesem Fall hat man PurchaseInfoNumber<ReqInfoNumber;
    • – Beim dem Empfang dieser Nachricht 8 sollte der Anfordernde verifizieren, daß die empfangenen Informationen mit den von ihm angeforderten übereinstimmen. Wenn die Verifikation erfolglos bleibt, sollte der Anfordernde ein angepaßtes Verhalten an den Tag legen. Ein vernünftiges Verhalten würde darin bestehen, alle Kaufinformationen zu überspringen, die nicht übereinstimmen.
  • 9. Die Finanztransaktion 9:
  • Dieser Abschnitt deckt keine spezielle Nachricht ab, sondern eine Nachrichtensuite, die zu der Bezahlung der zentralen Autorität durch den Anfordernden für die angeforderten Dateien führt. Die Bezahlungsphase liegt außerhalb des Schutzumfangs der Erfindung und kann durch ein beliebiges Bezahlungsprotokoll (z. B. SET, SSL, Mikrobezahlung usw.) implementiert werden, das durch die zentrale Autorität unterstützt wird (d. h. diejenigen, die in den Nachrichten QueryHits und InfoResponse 4 und 8 gesendet wurden).
  • Der Bezahlungsphase sollte jedoch eine Aushandlungsphase vorausgehen, in der der Anfordernde ein Bestellformular und die von ihm aus der Liste akzeptierter Bezahlungsprotokolle ausgewählte Bezahlungsmethode vorlegt. Diese Informationen werden aus den Nachrichten InfoResponse oder QueryHits extrahiert, die der Anfordernde zuvor empfangen hat.
  • Die nachfolgende Tabelle 9 zeigt die Nachricht Aushandlung, die der Anfordernde zu der zentralen Autorität sendet:
    Felder der Nachricht Beschreibung der Felder
    Aushandlungs-Nachrichtendaten {FileNumber, ChosenPaymentMode, {SignedPurchaseInfo}+}
    FileNumber (1 Byte) Anzahl der Dateien, die der Benutzer dieser zentralen Autorität kaufen möchte.
    ChosenPaymentMode (variable Länge) Durch doppelte Null abgeschlossene Zeichenkette, die die vom Anfordernden zum Bezahlen der entsprechenden Datei gewählte Bezahlungsmethode repräsentiert. Dieses Feld muß zu dem PaymentMode-Teilfeld des SignedPurchaseInfo-Felds der QueryHits-Nachricht 4 gehören.
    SignedPurchaseInfo (variable Länge) Datensatz, der eine Datei repräsentiert, die der Anfordernde kaufen möchte. Dieser Satz wird aus der QueryHits-Nachricht 4 oder der InfoResponse-Nachricht 8 abgerufen und wurde ursprünglich von der zentralen Autorität, die der Anfordernde für den Kauf kontaktiert hat, erzeugt und signiert.
    Tabelle 9
  • Es sollte folgendes beachtet werden:
    • – Das SignedPurchaseInfo-Feld erscheint FileNumber mal in der Nachricht Aushandlung (einmal für jede Datei, die der Anfordernde kaufen möchte);
    • – Vor dem Start der Finanztransaktion verifiziert die zentrale Autorität die Gültigkeit der präsentierten Preisinformationen und der Antwortendenkennung, die in dem SignedPurchaseInfo-Feld enthalten sind. Wenn die Verifizierung erfolglos bleibt, wird die Transaktion abgebrochen.
  • 10. Die PaymentTicket-Nachricht 10:
  • Diese Nachricht wird von der zentralen Autorität an den Anfordernden abgeliefert, sobald die Finanztransaktion abgeschlossen ist.
  • Das ausführliche Nachrichtenformat ist in der nachfolgenden Tabelle 10 dargestellt:
    Figure 00490001
    Figure 00500001
    Tabelle 10
  • Es sollte beachtet werden, daß das TransactionInfo-Feld TransactionNumber mal in der PaymentTicket-Nachricht 10 erscheint (einmal für jede Datei, die der Anfordernde bezahlt hat).
  • 11. Die FwdPaymentTicket-Nachricht 11
  • Diese Nachricht wird vom Anfordernden zum Antwortenden gesendet, um zu beweisen, daß er bestimmte urheberrechtlich geschützte Dateien gekauft hat. Diese Nachricht enthält ungefähr dieselben Daten wie die PaymentTicket-Nachricht 10.
  • Das ausführliche Nachrichtenformat ist in der folgenden Tabelle 11 dargestellt:
    Felder der Nachricht Beschreibung der Felder
    FwdPaymentTicket-Nachrichtendaten (EncryptedFwdPaymentTicket}
    EncryptedFwdPaymentTicket ESSK (SignedPaymentTicket), Abfrage
    SignedPaymentTicket (variable Länge) SignedPaymentTicket-Feld, das von der zentralen Autorität als Kaufbeweis erzeugt wurde und aus der PaymentTicket-Nachricht 10 extrahiert wird.
    Abfrage (16 Byte) Durch die zentrale Autorität erzeugte Abfrage, die aus der PaymentTicket-Nachricht 10 extrahiert wird. Wird vom Antwortenden zum Berechnen des Sitzungsschlüssels SSK verwendet.
    Tabelle 11
  • 12. Die DownloadInfo-Nachricht 12:
  • Diese Nachricht wird vom Antwortenden zum Anfordernden gesendet, sobald er die FwdPaymentTicket-Nachricht 11 empfangen hat, die beweist, daß der Anfordernde bestimmte Dateien bezahlt hat. In dieser Nachricht gibt der Antwortende die URL an, bei der der Anfordernde das Herunterladen der gekauften Dateien erbitten kann. Der Zweckmäßigkeit halber wird vorgeschlagen, das HTTP-Protokoll für die Herunterladephase zu verwenden. Deshalb sollte an der in der DownloadInfo-Nachricht 12 enthaltenen URL ein HTTP-Server laufen.
  • Um die Herunterladephase vor Lauschangriffen zu sichern, werden die heruntergeladenen Dateien darüber hinaus verschlüsselt. Die DownloadInfo-Nachricht 12 enthält deshalb auch den Entschlüsselungsschlüssel, der vom Anfordernden zum Abrufen der ursprünglichen gekauften Dateien verwendet werden wird.
  • Zusätzlich verhindert dieses Merkmal, daß der Anfordernde andere Dateien als die von ihm gekauften herunterlädt.
  • Das ausführliche Nachrichtenformat ist in der nachfolgenden Tabelle 12 dargestellt:
    Felder der Nachricht Beschreibung der Felder
    DownloadInfo-Nachrichtendaten (EncryptedDownloadInfo}
    EncryptedDownloadInfo ESSK ({FileDownloadInfo}+, DownloadURL)
    FileDownloadInfo {FileName, Contentkey}
    FileName (variable Länge) Durch Null abgeschlossene Zeichenkette, die den Namen der herunterzuladenden Datei repräsentiert.
    ContentKey (16 Byte) Entschlüsselungsschlüssel der relevanten Datei (Kcontent)
    DownloadURL (variable Länge) Durch Null abgeschlossene Zeichenkette, die die URL repräsentiert, an der der Anfordernde die gekauften Dateien herunterladen kann.
  • Es sollte beachtet werden, daß beim Empfang dieser Nachricht der Anfordernde verifizieren sollte, daß die Anzahl der empfangenen heruntergeladenen Informationen der Anzahl der gekauften Dateien entspricht.
  • 13. Die Download-Operation 13:
  • Nachdem der Anfordernde die DownloadInfo-Nachricht 12 empfangen hat, kann er mit der Herunterladephase 13 beginnen.
  • Die nachfolgende Tabelle 13 zeigt das vom Anfordernden heruntergeladene Inhaltsformat. Wie zuvor betont wurde, wird dieser Inhalt verschlüsselt, wodurch Lauschangriffe verhindert werden.
  • Figure 00530001
  • Figure 00540001
    Tabelle 13
  • Es soll nun das bevorzugte Verfahren beschrieben werden, um Antwortenden ihre Entlohnung für die Verteilung von digitalem Inhalt durch das Zugriffsnetzwerk zukommen zu lassen. Jedesmal, wenn ein Inhalt, der von einem Antwortenden verteilt wurde, von einem Anfordernden gekauft wird, sollte der Antwortende tatsächlich eine entsprechende Bezahlung von der zentralen Autorität erhalten.
  • Wie bereits erwähnt, müssen alle Antwortenden, die digitale Inhalte durch das Zugriffsnetzwerk verteilen, bei mindestens einer zentralen Autorität registriert sein, um Entlohnung für diese Verteilung zu erhalten. Derselbe Antwortende kann bei mehreren zentralen Autoritäten registriert sein, wenn er urheberrechtlich geschützte Inhalte vorschlägt, die von verschiedenen Inhaltsanbietern erzeugt werden, die nicht mit derselben zentralen Autorität verknüpft sind.
  • Bei dem bevorzugten Verfahren zum Bezahlen von Antwortenden wird vorgeschlagen, für jeden Antwortenden während der Registrationsphase ein Konto zu erzeugen, wobei dieses Konto mit der Antwortendenkennung verknüpft wird. Während der Registration gibt der Antwortende der zentralen Autorität alle persönlichen Daten (Name, Adresse, Bankkontonummer usw.), die die zentrale Autorität benötigt, um Kontenclearing durchzuführen. Die zentrale Autorität, bei der der Antwortende registriert ist, führt dann regelmäßig ein Kontenclearing aus, was zu der Bezahlung des Antwortenden führt. Das Clearingverfahren sollte zwischen der zentralen Autorität und dem Antwortenden während der Registrationsphase ausgehandelt werden und liegt außerhalb des Schutzumfangs der Erfindung.
  • Während des Kaufs eines urheberrechtlich geschützten Inhalts schreibt die zentrale Autorität dem Konto des Antwortenden gut, sobald sie die Nachricht Aushandlung der Finanztransaktion 9 empfangen hat. Wie in dem obigen Abschnitt 9 skizziert wurde, enthält diese Nachricht die Antwortendenkennung, die durch die zentrale Autorität geliefert wurde. Die zentrale Autorität besitzt somit alle notwendigen Daten zum Bezahlen des Antwortenden.
  • Eine Alternativlösung würde darin bestehen, daß der Antwortende die von den Anfordernden (in FwdPaymentTicket-Nachrichten 11) empfangenen PaymentTicket-Nachrichtendaten der zentralen Autorität vorlegt, um bezahlt zu werden. Nachdem der Antwortende PaymentTicket-Nachrichtendaten empfangen hat, speichert er sie als Verkaufsbeweis. Andererseits speichern die zentralen Autoritäten alle erzeugten PaymentTicket-Nachrichten. Dann legt der Antwortende diese Nachrichten jeder zentralen Autorität vor, die die Gültigkeit der Nachricht verifizieren kann, bevor eine Online-Finanztransaktion mit dem Antwortenden durchgeführt wird.

Claims (10)

  1. System zum Verteilen eines digitalen Inhalts an einen Anfordernden (200) durch ein Zugriffsnetzwerk (110), umfassend: eine zentrale Autorität (202–204) mit Mitteln zum Herstellen einer Finanztransaktion (9) mit dem Anfordernden zur Bezahlung des Inhalts durch den Anfordernden und einem Antwortenden-Entlohnungsmittel zur Entlohnung des Antwortenden für den Kauf eines Inhalts durch den Anfordernden; einen Antwortenden (300), der bei der zentralen Autorität registriert ist, mit Mitteln zum Verteilen einer dem Inhalt entsprechenden Datei an den Anfordernden (200) unter Verwendung einer Peer-zu-Peer-Verbindung mit dem Anfordernden; dadurch gekennzeichnet, daß der Antwortende (300) dafür ausgelegt ist, die Datei im Austausch für einen von dem Anfordernden empfangenen Kaufbeweis (11) zu verteilen, und daß der Antwortende (300) ferner Mittel zum Empfangen einer vom Anfordernden (200) stammenden Anfrage (1), Mittel zum Senden einer Antwort (4), wenn der Antwortende (300) mindestens eine die Anfrage (1) erfüllende Datei besitzt, und Mittel zum Weiterleiten der Anfrage (1) zu mindestens einem anderen Antwortenden in dem Zugriffsnetzwerk (110) umfaßt; wobei die zentrale Autorität ferner Mittel zum Abliefern des Kaufbeweises (100) an den Anfordernden umfaßt.
  2. Verfahren zum Verteilen eines digitalen Inhalts durch ein Zugriffsnetzwerk (110) unter Verwendung des Systems nach Anspruch 1, dadurch gekennzeichnet, daß es Schritte umfaßt, die für einen Antwortenden (300) aus folgendem bestehen: a) Als Reaktion auf eine Anforderung (1) eines digitalen Inhalts, die von einem Anfordernden (200) durch das Zugriffsnetzwerk empfangen wird, Senden von Inhaltskaufinformationsdaten (4) zu dem Anfordernden und Weiterleiten der Anforderung (1) zu mindestens einem anderen Antwortenden in dem Zugriffsnetzwerk (110); wobei die Inhaltskaufinformationsdaten eine durch eine zentrale Autorität (201–204) erzeugte Antwortendenkennung und die zentrale Autorität identifizierende Daten enthalten; b) Empfangen eines Kaufbeweises (11) des digitalen Inhalts von dem Anfordernden (200), wobei der Kaufbeweis durch die zentrale Autorität geliefert wird; c) Bereitstellen einer Datei für den Anfordernden (200), die dem digitalen Inhalt entspricht; und d) Empfangen einer Entlohnung für die Verteilung des digitalen Inhalts von der zentralen Autorität.
  3. Verfahren nach Anspruch 2, das ferner vor Schritt a) einen Registrationsschritt umfaßt, der folgendes umfaßt: Empfangen einer Antwortendenkennung von der zentralen Autorität.
  4. Verfahren nach Anspruch 3, wobei der Registrationsschritt ferner folgendes umfaßt: Empfangen eines aus dem Master-Schlüssel (MKPR) einer ersten zentralen Autorität und aus der Antwortendenkennung abgeleiteten ersten symmetrischen Verschlüsselungsschlüssels (DKPR).
  5. Verfahren nach Anspruch 4, wobei der Registrationsschritt ferner folgendes umfaßt: Empfangen eines aus dem Master-Schlüssel (MKEC) einer zweiten zentralen Autorität und aus der Antwortendenkennung abgeleiteten zweiten symmetrischen Verschlüsselungsschlüssels (DKEC).
  6. Verfahren zum Verteilen eines digitalen Inhalts durch ein Zugriffsnetzwerk (110) unter Verwendung des Systems nach Anspruch 1, dadurch gekennzeichnet, daß es Schritte umfaßt, die für einen Anfordernden (200) aus folgendem bestehen: i) Senden einer ersten Nachricht (1) durch das Zugriffsnetzwerk, um einen digitalen Inhalt anzufordern; j) Empfangen von Inhaltskaufinformationsdaten (4) von einem Antwortenden, der eine dem Inhalt entsprechende Datei besitzt; wobei die Inhaltskaufinformationsdaten eine zentrale Autorität identifizierende Daten enthalten; k) als Reaktion auf eine Finanztransaktion (9) mit der zentralen Autorität, Empfangen eines Kaufbeweises (10) des digitalen Inhalts; l) Senden des Kaufbeweises zu dem Antwortenden (300); und m) Empfangen einer dem digitalen Inhalt entsprechenden Datei.
  7. Verfahren nach Anspruch 2 oder 6, wobei die Inhaltskaufinformationsdaten durch den Antwortenden von der zentralen Autorität empfangene Inhaltspreisdaten (3) umfassen, wobei die Inhaltspreisdaten von der zentralen Autorität für jeden Antwortenden bestimmt werden.
  8. Verfahren nach Anspruch 7, wobei die Inhaltskaufinformationsdaten ferner Preiszeitgültigkeitsdaten umfassen.
  9. Verfahren nach Anspruch 4, wobei die Inhaltskaufinformationsdaten durch den Antwortenden von der zentralen Autorität empfangene Inhaltspreisdaten (3) umfassen, wobei die Inhaltspreisdaten von der zentralen Autorität für jeden Antwortenden bestimmt werden, und wobei die Inhaltspreisdaten in einer Nachricht (3) gesendet werden, die unter Verwendung des ersten symmetrischen Verschlüsselungsschlüssels (DKPR) verschlüsselt wird.
  10. Verfahren nach Anspruch 5, wobei der Kaufbeweis in einer Nachricht (11) gesendet wird, die unter Verwendung eines symmetrischen Sitzungsschlüssels (SSK) verschlüsselt wird, wobei der symmetrische Sitzungsschlüssel (SSK) durch die zentrale Autorität aus einem Zufallswert und aus dem zweiten symmetrischen Verschlüsselungsschlüssel (DKEC) abgeleitet wird, wobei der Zufallswert im Klartext in der Nachricht (11) gesendet wird, die den verschlüsselten Kaufbeweis enthält.
DE60133312T 2000-12-29 2001-12-20 System und verfahren zur sicheren verteilung eines digitalen inhaltes in einem geteilten netzwerk Expired - Lifetime DE60133312T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP00403721A EP1220173A1 (de) 2000-12-29 2000-12-29 System und Verfahren zur sicheren Verteilung von digitalen Inhalten in einem aufgeteilten Netz
EP00403721 2000-12-29
PCT/EP2001/015107 WO2002054196A2 (en) 2000-12-29 2001-12-20 System and method for the secure distribution of digital content in a sharing network

Publications (2)

Publication Number Publication Date
DE60133312D1 DE60133312D1 (de) 2008-04-30
DE60133312T2 true DE60133312T2 (de) 2008-06-26

Family

ID=8174022

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60133312T Expired - Lifetime DE60133312T2 (de) 2000-12-29 2001-12-20 System und verfahren zur sicheren verteilung eines digitalen inhaltes in einem geteilten netzwerk

Country Status (7)

Country Link
US (1) US20040093273A1 (de)
EP (2) EP1220173A1 (de)
JP (1) JP2004517411A (de)
KR (1) KR100947045B1 (de)
AU (1) AU2002217144A1 (de)
DE (1) DE60133312T2 (de)
WO (1) WO2002054196A2 (de)

Families Citing this family (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2002358290A1 (en) * 2001-12-28 2003-07-24 Woodstock Systems, Llc Personal digital servertm (pdstm)
US7249060B2 (en) * 2002-08-12 2007-07-24 Paybyclick Corporation Systems and methods for distributing on-line content
FR2847053B1 (fr) * 2002-11-08 2005-12-30 France Telecom Procede et systeme d'echange de biens entre particuliers par l'intermediaire d'un reseau de transmission de donnees numeriques
US7370017B1 (en) * 2002-12-20 2008-05-06 Microsoft Corporation Redistribution of rights-managed content and technique for encouraging same
WO2004094980A2 (en) * 2003-04-24 2004-11-04 Koninklijke Philips Electronics N.V. Peer to peer transfer of content
JP2005011218A (ja) * 2003-06-20 2005-01-13 Matsushita Electric Ind Co Ltd コンテンツ送出装置、コンテンツ受信装置およびこれらを用いたコンテンツ配信システム
US7516482B2 (en) * 2003-07-21 2009-04-07 Microsoft Corporation Secure hierarchical namespaces in peer-to-peer networks
US7685301B2 (en) * 2003-10-20 2010-03-23 Sony Computer Entertainment America Inc. Redundancy lists in a peer-to-peer relay network
GB2409786B (en) * 2003-12-29 2006-12-13 Nokia Corp Content distribution
WO2005076147A1 (en) * 2004-02-10 2005-08-18 Ian Andrew Maxwell A content distribution system
US7627530B2 (en) * 2004-04-26 2009-12-01 Amazon Technologies, Inc. Method and system for managing access to media files
KR100662336B1 (ko) * 2004-06-21 2007-01-02 엘지전자 주식회사 컨텐츠 다운로드 방법 및 그를 수행하기 위한 시스템
KR100611740B1 (ko) * 2004-10-13 2006-08-11 한국전자통신연구원 핑거프린트 기반 불법복제 콘텐츠 추적 시스템 및 그 방법
EP1810294B1 (de) 2004-11-09 2018-11-28 Thomson Licensing Verknüpfung von inhalten auf separaten speichermedien
US7341183B2 (en) * 2004-12-29 2008-03-11 Motorola Inc. System and method for distributing media
KR100663443B1 (ko) * 2005-09-15 2007-01-02 삼성전자주식회사 서비스 보호를 위한 구조 및 개체간 연동 방법 및 장치그리고 그 시스템
US7515710B2 (en) * 2006-03-14 2009-04-07 Divx, Inc. Federated digital rights management scheme including trusted systems
GB2437558B (en) * 2006-04-19 2010-12-15 Thales Holdings Uk Plc Privacy protection system
US20080092239A1 (en) * 2006-10-11 2008-04-17 David H. Sitrick Method and system for secure distribution of selected content to be protected
US8719954B2 (en) 2006-10-11 2014-05-06 Bassilic Technologies Llc Method and system for secure distribution of selected content to be protected on an appliance-specific basis with definable permitted associated usage rights for the selected content
US8997161B2 (en) 2008-01-02 2015-03-31 Sonic Ip, Inc. Application enhancement tracks
GB0802739D0 (en) * 2008-02-15 2008-03-26 Foreman Patrick J Computer system and methods to support a Cloud Commerce community for authorised sharing of digtial content via a contolled peer-to-peer network
US8639630B2 (en) 2008-02-15 2014-01-28 Ddn Ip Holdings Limited Distribution of digital content
CN105072454B (zh) 2009-01-07 2019-04-19 索尼克Ip股份有限公司 针对在线内容的媒体指南的特定化、集中式、自动化创建
GB2469034A (en) * 2009-03-30 2010-10-06 Sony Corp Distribution system and method of distributing content files
EP2507995A4 (de) 2009-12-04 2014-07-09 Sonic Ip Inc Systeme und verfahren zum transport eines kryptographischen materials für elementare bitströme
US9235399B2 (en) * 2010-01-15 2016-01-12 Dell Products L.P. System and method for manufacturing and personalizing computing devices
US9256899B2 (en) * 2010-01-15 2016-02-09 Dell Products, L.P. System and method for separation of software purchase from fulfillment
US10387927B2 (en) * 2010-01-15 2019-08-20 Dell Products L.P. System and method for entitling digital assets
US8548919B2 (en) * 2010-01-29 2013-10-01 Dell Products L.P. System and method for self-provisioning of virtual images
US9100396B2 (en) * 2010-01-29 2015-08-04 Dell Products L.P. System and method for identifying systems and replacing components
US8429641B2 (en) * 2010-02-02 2013-04-23 Dell Products L.P. System and method for migration of digital assets
US8170783B2 (en) 2010-03-16 2012-05-01 Dell Products L.P. System and method for handling software activation in entitlement
US8707087B2 (en) 2010-05-18 2014-04-22 Dell Products L.P. Restoration of an image backup using information on other information handling systems
KR101744744B1 (ko) * 2010-12-22 2017-06-09 한국전자통신연구원 불법 콘텐츠 유통 방지 및 불법 배포자 추적 시스템 및 그 방법
US8914534B2 (en) 2011-01-05 2014-12-16 Sonic Ip, Inc. Systems and methods for adaptive bitrate streaming of media stored in matroska container files using hypertext transfer protocol
US9467708B2 (en) 2011-08-30 2016-10-11 Sonic Ip, Inc. Selection of resolutions for seamless resolution switching of multimedia content
US8964977B2 (en) 2011-09-01 2015-02-24 Sonic Ip, Inc. Systems and methods for saving encoded media streamed using adaptive bitrate streaming
US8909922B2 (en) 2011-09-01 2014-12-09 Sonic Ip, Inc. Systems and methods for playing back alternative streams of protected content protected using common cryptographic information
US8949401B2 (en) 2012-06-14 2015-02-03 Dell Products L.P. Automated digital migration
US8468139B1 (en) 2012-07-16 2013-06-18 Dell Products L.P. Acceleration of cloud-based migration/backup through pre-population
US9779219B2 (en) 2012-08-09 2017-10-03 Dell Products L.P. Method and system for late binding of option features associated with a device using at least in part license and unique ID information
US9313510B2 (en) 2012-12-31 2016-04-12 Sonic Ip, Inc. Use of objective quality measures of streamed content to reduce streaming bandwidth
US9191457B2 (en) 2012-12-31 2015-11-17 Sonic Ip, Inc. Systems, methods, and media for controlling delivery of content
US9906785B2 (en) 2013-03-15 2018-02-27 Sonic Ip, Inc. Systems, methods, and media for transcoding video data according to encoding parameters indicated by received metadata
US10397292B2 (en) 2013-03-15 2019-08-27 Divx, Llc Systems, methods, and media for delivery of content
US9247317B2 (en) 2013-05-30 2016-01-26 Sonic Ip, Inc. Content streaming with client device trick play index
US9094737B2 (en) 2013-05-30 2015-07-28 Sonic Ip, Inc. Network video streaming with trick play based on separate trick play files
US9967305B2 (en) 2013-06-28 2018-05-08 Divx, Llc Systems, methods, and media for streaming media content
US9866878B2 (en) 2014-04-05 2018-01-09 Sonic Ip, Inc. Systems and methods for encoding and playing back video at different frame rates using enhancement layers
US10498795B2 (en) 2017-02-17 2019-12-03 Divx, Llc Systems and methods for adaptive switching between multiple content delivery networks during adaptive bitrate streaming
JP6610814B2 (ja) * 2019-02-12 2019-11-27 富士通株式会社 通信方法、装置、及びプログラム

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5337357A (en) * 1993-06-17 1994-08-09 Software Security, Inc. Method of software distribution protection
US5892900A (en) * 1996-08-30 1999-04-06 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
EP0809221A3 (de) * 1996-05-23 1999-06-30 Sun Microsystems, Inc. Virtuelles Verkaufsystem und Verfahren zum Verwalten der Verteilung, der Lizenzierung und der Vermietung von elektronischen Daten
US6029141A (en) 1997-06-27 2000-02-22 Amazon.Com, Inc. Internet-based customer referral system
EP1012702A4 (de) * 1997-09-11 2004-04-21 Digital Square Inc System zur verkauf, lieferung und wartung von digitale inhalten
AU5781599A (en) * 1998-08-23 2000-03-14 Open Entertainment, Inc. Transaction system for transporting media files from content provider sources tohome entertainment devices
EP0993163A1 (de) * 1998-10-05 2000-04-12 Backweb Technologies Ltd. System und Verfahren zur verteilten Datencachespeicherung in Kundenendgeräten
US7209892B1 (en) * 1998-12-24 2007-04-24 Universal Music Group, Inc. Electronic music/media distribution system
AU4210800A (en) * 1999-04-09 2000-11-14 Liquid Audio, Inc. Secure online music distribution system
US8340994B2 (en) * 1999-05-05 2012-12-25 Virtual Creative Artists, LLC Process for creating media content based upon submissions received on an electronic multi-media exchange
WO2001041023A1 (en) * 1999-12-03 2001-06-07 Matsushita Electric Industrial Company, Limited A content distribution system and a reference server
US7158953B1 (en) * 2000-06-27 2007-01-02 Microsoft Corporation Method and system for limiting the use of user-specific software features
EP1388100A4 (de) * 2001-02-28 2007-08-08 Digonex Technologies Inc Digitale online-boerse

Also Published As

Publication number Publication date
EP1220173A1 (de) 2002-07-03
DE60133312D1 (de) 2008-04-30
EP1348151B1 (de) 2008-03-19
WO2002054196A2 (en) 2002-07-11
EP1348151A2 (de) 2003-10-01
WO2002054196A3 (en) 2002-09-19
JP2004517411A (ja) 2004-06-10
KR20030079940A (ko) 2003-10-10
US20040093273A1 (en) 2004-05-13
KR100947045B1 (ko) 2010-03-11
AU2002217144A1 (en) 2002-07-16

Similar Documents

Publication Publication Date Title
DE60133312T2 (de) System und verfahren zur sicheren verteilung eines digitalen inhaltes in einem geteilten netzwerk
US7614081B2 (en) Managing and sharing identities on a network
DE69736696T2 (de) Netzwerk-Daten-Ubertragungssystem
DE602004011282T2 (de) Versenden einer Herausgeber-Benutzungslizenz off-line in einem digitalen Rechtesystem
US7877330B2 (en) Method and system for managing access to media files
DE60315726T2 (de) Verfahren zum sicherstellen von anonymität in einer elektronischen transaktion mittels sitzungsschlüsselblöcken
DE60116903T2 (de) Gesicherte sitzungverwaltung und authentifizierung für websites
CN110770723A (zh) 使用区块链优先级信息的分散式数字内容分发系统和过程
US20060143084A1 (en) Software and method for advertisor sponsored events within a private centrally managed local or distributed network of users and an optional associated private network card for specialty marketing identification or banking
US20040199402A1 (en) Method and system for anonymous communication of information about a home
US20060106802A1 (en) Stateless methods for resource hiding and access control support based on URI encryption
DE102006027030A1 (de) Vorrichtung und Verfahren zum geschützten Verteilen elektronischer Dokumente
JP6903269B2 (ja) コンテンツ視聴管理システム
EP1477882A2 (de) Dezentrales, tokenbasiertes Accountingsystem für autonome, verteilte Systeme
US20030177064A1 (en) Advertisement distribution system
US20020087474A1 (en) Electronic commerce system, electronic commerce method and storage medium
WO2022270551A1 (ja) Ｎｆｔ情報管理システムおよびｎｆｔ情報管理プログラム
JP6809768B1 (ja) アンケートデータの管理・分析システム
KR20230061113A (ko) 블록체인 기반의 광고 및 가상 자산 관리 방법 및 블록체인 기반 전자 장치의 가상 자산 관리 방법
EP0852351A2 (de) Eingangs-, Querverweis- und Verzweigungssystem für Computer-Netzwerke
US20020019773A1 (en) Point managing method
DE60216056T2 (de) Verfahren und anordnung in einem kommunikationssystem
WO2019180152A1 (de) Automatisiertes verfahren zum schutz von elektronischen daten zum zwecke der datenverarbeitung durch dritte unter einbezug transparenter und unterbrechungssicherer vergütung
DE102007027019A1 (de) Vorrichtung und Verfahren zur clientseitigen Freigabe elektronischer Dokumente
JP4461403B2 (ja) アンケートシステム、アンケートサーバ、アンケートサーバの処理を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体

Legal Events

Date Code Title Description
8364 No opposition during term of opposition