DE102005010131A1 - Verfahren zur Übertragung von digitalen Inhalten eines Inhalteanbieters an die Nutzer eines Online- Inhalteübertragungssystems - Google Patents

Verfahren zur Übertragung von digitalen Inhalten eines Inhalteanbieters an die Nutzer eines Online- Inhalteübertragungssystems Download PDF

Info

Publication number
DE102005010131A1
DE102005010131A1 DE102005010131A DE102005010131A DE102005010131A1 DE 102005010131 A1 DE102005010131 A1 DE 102005010131A1 DE 102005010131 A DE102005010131 A DE 102005010131A DE 102005010131 A DE102005010131 A DE 102005010131A DE 102005010131 A1 DE102005010131 A1 DE 102005010131A1
Authority
DE
Germany
Prior art keywords
terminal
file
upload
content
user
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
DE102005010131A
Other languages
English (en)
Inventor
Kurt Dr. Smit
Kan-Hung Wan
Matthias Dr. Runte
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.)
Arvato Mobile GmbH
Original Assignee
Arvato Mobile GmbH
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 Arvato Mobile GmbH filed Critical Arvato Mobile GmbH
Priority to DE102005010131A priority Critical patent/DE102005010131A1/de
Priority to EP05751848A priority patent/EP1854261A1/de
Priority to RU2007136164/09A priority patent/RU2007136164A/ru
Priority to BRPI0520040-7A priority patent/BRPI0520040A2/pt
Priority to PCT/EP2005/006274 priority patent/WO2006092158A1/de
Priority to US11/249,030 priority patent/US20060200736A1/en
Publication of DE102005010131A1 publication Critical patent/DE102005010131A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1059—End-user terminal functionalities specially adapted for real-time communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Beschrieben wird ein Verfahren zur Übertragung von digitalen Inhalten eines Inhalteanbieters (SR) an die Nutzer eines Inhalteübertragungssystems in einem Computer-Kommunikationsnetzwerk (N), bei dem eine Datei (D), welche einen bestimmten von einem Download-Nutzer gewünschten digitalen Inhalt enthält, zumindest teilweise von einem Terminal (T1, T2) eines Upload-Nutzers aus über das Computer-Kommunikationsnetzwerk (N) an ein Terminal (T2, T3) des Download-Nutzers übertragen wird. Dabei werden von Terminals (T1, T2) verschiedener Upload-Nutzer aus Fragmente (F) der Datei (D) an das Terminal (T2, T3) des Download-Nutzers übertragen.

Description

  • Die Erfindung betrifft ein Verfahren zur Übertrag von digitalen Inhalten eines Inhalteanbieters an die Nutzer eines Online-Inhalteübertragungssystems in einem Computer-Kommunikationsnetzwerk, bei dem eine Datei, welche einen bestimmten, von einem Download-Nutzer gewünschten Inhalt enthält, zumindest teilweise von einem Terminal eines Upload-Nutzers des Inhalteübertragungssystems über das Computer-Kommunikationsnetzwerk an ein Terminal des Download-Nutzers übertragen wird. Darüber hinaus betrifft die Erfindung ein entsprechendes Inhalteübertragungssystem zur Durchführung eines solchen Verfahrens sowie ein für dieses Verfahren geeignetes Terminal zum Herunterladen eines digitalen Inhalts eines Inhalteanbieters aus einem Computer-Kommunikationsnetzwerk.
  • In Computernetzwerken, wie z. B. im Internet, wird mittlerweile eine Vielzahl verschiedenster Inhalte angeboten. Zu solchen Inhalten zählen u. a. Spiele, Bilder, Musik, Filme, Software oder sonstige Veröffentlichungen jeglicher Art. Da durch neue Netzanschlusssysteme wie beispielsweise DSL die Bandbreiten zu den Endbenutzerverbindungen (d. h. zu deren am Netz angeschlossenen Terminals wie z. B. PCs, Laptops etc.) erheblich gesteigert werden konnten, können mittlerweile zwischen den privaten Nutzern sehr schnell und einfach auch recht große Dateien, wie z. B. komplette Musiktitel oder Videofilme, über solche Netzwerke übertragen werden. Die Netzwerke werden daher leider vielfach auch genutzt, um urheberrechtlich geschützte Inhalte illegal auszutauschen. Dadurch hat sich die Verletzung von Urheberrechten inzwischen als ein weltweites gesellschaftliches Problem etabliert.
  • Da es andererseits für die Nutzer außerordentlich bequem ist, Inhalte wie einzelne Musikstücke oder Videos auf einem heimischen Terminal empfangen zu können, gibt es auch eine zunehmende Zahl von professionellen Inhalteanbietern, die – in der Regel gegen entsprechende Bezahlung – ein legales Herunterladen von urheberrechtlich geschützten digitalen Inhalten ermöglichen. Solche Inhalteanbieter benutzen üblicherweise zentrale Inhalteübertragungssysteme, bei denen die Nutzer jeweils die gewünschten Inhalte von einem zentralen Server des Inhalteanbieters herunterladen. Eine solche zentralisierte Systemarchitektur ermöglicht eine sehr einfache Kontrolle über die transportierten Inhalte. Jedoch wird für die einzelnen Nutzer bei einem Herunterladen (im Folgenden auch in der üblichen Notation als „Download" bezeichnet) von Inhalten vom zentralen Server die zur Verfügung stehende Bandbreite immer kleiner, je mehr Nutzer parallel einen Download von diesem Server durchführen wollen. Für den Inhalteanbieter bzw. den Betreiber eines solchen Inhalteübertragungssystems (im Folgenden auch „Download-Plattform" genannt) ist es somit lediglich eine Frage der Zeit, dass er durch Aufstocken der Hardware, beispielsweise durch eine Parallelschaltung mehrerer Server, die Bandbreite wieder erhöht oder dass andernfalls die Nutzer wegen zu geringer Download-Bandbreiten verärgert werden und daher in Zukunft den Dienst nicht mehr nutzen. Dadurch sind die Betreiber solcher Download-Plattformen zu regelmäßigen Investitionen in neue Hardware verpflichtet, was letztlich bedeutet, dass durch die Umsätze relative hohe anteilige Hardwarekosten gedeckt werden müssen. Dadurch werden die Preise für das legale Herunterladen urheberrechtlich geschützter Inhalte teurer, was wiederum Nutzer dazu verleiten könnte, illegale Tauschplattformen zu nutzen. Zwar werden die Nutzer solcher illegaler Tauschplattformen mittlerweile strafrechtlich verfolgt, dies stößt aber häufig auf Probleme, da die Strafverfolgung an nationale Grenzen gebunden ist. Die Wahrscheinlichkeit einer erfolgreichen Strafverfolgung ist daher eher gering. Da solche Download-Plattformen mit illegal verbreitetem, urheberrechtlich geschütztem Inhalt meist kostenlos arbeiten, wird folglich eine Etablierung von Download-Plattformen mit ausschließlich legalen Inhalten erschwert, da hier bereits zur Deckung der an den Rechteinhaber abzuführenden Lizenzgebühren ein entsprechender Preis für die Nutzung der Inhalte zu entrichten ist.
  • Eine Möglichkeit zur Lösung dieses Dilemmas wird in der US 2004/0030651 A1 beschrieben. Bei dem dort genannten Verfahren wird durch geeignete Maßnahmen dafür gesorgt, dass die Nutzer des Systems die gewünschten digitalen Inhalte von anderen Nutzern des Systems downloaden können. Dabei müssen jedoch die Nutzer, welche die Inhalte herunterladen, eine entsprechende Zahlung leisten und ein Teil dieser Zahlung wird an den Nutzer weitergeleitet, welcher den Inhalt übertragen hat. Hierzu wird der digitale Inhalt beim Dienstanbieter zunächst vorbereitet, beispielsweise in irgendeiner Form verschlüsselt. Anschließend kann der Inhalt dann in üblicher Weise von einem zentralen Server aus durch einen ersten Nutzer heruntergeladen werden. Wenn ein weiterer Nutzer den Inhalt haben möchte, kann er diesen Inhalt wiederum vom Terminal des ersten Nutzers herunterladen. Anschließend muss er beim Dienstanbieter um Erlaubnis anfragen, den digitalen Inhalt zu nutzen. Gegen Zahlung einer Gebühr erfolgt dann eine Benutzungsauthentifizierung für den digitalen Inhalt durch den Dienstanbieter. Nach Erhalt dieser Authentifizierung kann der zweite Nutzer den heruntergeladenen digitalen Inhalt verwenden. Außerdem wird neben einer Zahlung der Lizenzgebühr an den Rechteinhaber eine Zahlung an den ersten Nutzer veranlasst, welcher den digitalen Inhalt weitergeleitet hat. Ein dritter Nutzer, der diesen Inhalt dann haben möchte, kann den Inhalt wiederum vom zweiten oder alternativ vom ersten Nutzer herunterladen. Dabei ist es möglich, dass entsprechende Zahlungen an jeden Nutzer in der Weiterleitungskette erfolgen.
  • Dieses Übertragungsverfahren bzw. dieses Inhalteübertragungssystem hat zum einen den Vorteil, dass die Übermittlung über eine dezentrale Systemstruktur, ein sogenanntes „Peer-to-Peer (P2P)-Netzwerk", erfolgt, bei dem die Inhalte von einem Nutzer an einen anderen Nutzer weitergeleitet werden. Die Inhalte sind somit innerhalb des Netzwerkes in der Regel vielfach vorhanden, so dass die Belastung beim Download eines Inhaltes über das Netzwerk verteilt wird. Eine solche Peer-to-Peer-Systemstruktur ist erheblich kostengünstiger als eine klassische zentrale Download-Plattform, da es nicht nötig ist, mit zunehmender Anzahl von Nutzern die Infrastruktur in Form von neuen Servern zu erweitern, sondern mit der Anzahl der Nutzer steigt auch gleichzeitig die Anzahl der potentiellen Uploader (d. h. der Nutzer, von denen aus Inhalte an andere Nutzer übertragen werden können). Mit wachsender Nutzeranzahl steigt somit ohne weitere Kosten automatisch die Infrastruktur.
  • Dies führt dazu, dass die Kosten für das legale Herunterladen von urheberrechtlich geschützten digitalen Inhalten erheblich reduziert werden können, so dass die Attraktivität der Nutzung von illegalen Tauschplattformen im Verhältnis zu derartigen legalen Plattformen sinkt. Ein weiterer Vorteil besteht darin, dass die Nutzer, die bereit sind, digitale Inhalte an andere zu versenden, hierfür eine Vergütung erhalten. Es ist davon auszugehen, dass die Bereitschaft der Nutzer sinkt, urheberrechtlich geschützte Inhalte illegal an andere zu versenden, wenn sie bei Nutzung einer legalen Peer-to-Peer-Plattform hierfür eine Vergütung erhalten können. Umgekehrt können auch die Downloader solcher legalen Inhalte innerhalb der Peer-to-Peer-Plattform die Inhalte auf legale Weise wieder an andere Nutzer versenden und hierfür ebenfalls eine Vergütung erhalten. Daher ist es trotz der Zahlung einer Gebühr für den Download auch für den Download-Nutzer günstiger, von einem Inhalteanbieter den digitalen Inhalt auf legale Weise zu erwerben, da er bei einer Versendung des Inhalts an andere die Kosten refinanzieren oder sogar darüber hinaus langfristig noch einen Gewinn machen kann. Für die Rechteinhaber selber hat ein solches System den Vorteil, dass hierdurch ein neuer Distributionskanal geschaffen wird, welcher die Attraktivität illegaler Tauschbörsen erheblich reduziert.
  • Ein Nachteil des vorgenannten Verfahrens besteht jedoch darin, dass bei einer Übertragung von Dateien in einem Peer-to-Peer-Netzwerk die Übertragungsrate im Verhältnis zu einem Download von einem Server relativ gering ist. In sogenannten asymmetrischen Netzwerken wie z. B. DSL-Netzen weisen nämlich die Anschlüsse der Endnutzer an das Netzwerk üblicherweise inzwischen zwar eine relativ hohe Download-Bandbreite, aber nur eine geringe Upload-Bandbreite für ein „Heraufladen" von Daten vom Terminal an das Netz auf. So hat beispielsweise ein derzeit üblicher DSL-Anschluss eine Download-Rate von 780 bit/s, wogegen die Upload-Rate nur 128 bit/s beträgt. In zukünftigen satellitengestützten Netzen ist davon auszugehen, dass die Diskrepanz zwischen Upload- und Downloadrate noch größer ist, z. B. bei 15 Mbit/s Download und nur 64 bit/s oder 128 bit/s Upload liegt. Dies liegt u. a. daran, dass in den meisten Situationen, beispielsweise beim Browsen im Internet, von den Nutzern erheblich größere Datenmengen heruntergeladen werden müssen, als dass Daten in das Netz heraufgeladen werden müssen. Bei einer Peer-to-Peer-Datenübertragung ist folglich die Upload-Bandbreite des Upload-Terminals, von dem die digitalen Inhalte aus übertragen werden, der begrenzende Faktor. Dies führt zwangsläufig dazu, dass in einem solchen Netzwerk ein Download eines digitalen Inhalts durchschnittlich erheblich länger dauert als in einem zentralen Netzwerk, bei dem die Nutzer jeweils die digitalen Inhalte von speziell dafür vorgesehenen Servern mit einer ausreichend großen Upload-Bandbreite auf ihr Terminal herunterladen.
    •
  • Es ist eine Aufgabe der vorliegenden Erfindung, ein Verfahren der eingangsgenannten Art derart weiterzuentwickeln, dass der Download beschleunigt wird und insbesondere die vorgenannten Nachteile gegenüber einem zentralen Inhalteübertragungssystem beseitigt werden.
  • Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1 und durch ein Verfahren gemäß Anspruch 18 gelöst.
  • Erfindungsgemäß werden dabei Fragmente der Datei von Terminals verschiedener Upload-Nutzer aus an das Terminal des Download-Nutzers übertragen. Das heißt, bei einem erfindungsgemäßen Verfahren zum Herunterladen eines digitalen Inhalts eines Inhalteanbieters aus einem Computer-Kommunikationsnetzwerk auf ein Terminal eines Download-Nutzers eines Inhalteübertragungssystems wird erfindungsgemäß dafür gesorgt, dass das Terminal des Download-Nutzers Fragmente der Datei von Terminals verschiedener Upload-Nutzer empfängt. Unter einem „Download-Nutzer" ist hierbei ein Nutzer zu verstehen, der eine Datei mit einem bestimmten Inhalt auf sein Terminal herunterlädt, wogegen der „Upload-Nutzer" ein Nutzer des Systems ist, der sein Terminal für diesen Download zur Verfügung stellt, d. h. für diese Transaktion Dateiteile zum Peer-to-Peer-Netzwerk hochlädt. Es ist klar, dass diese Bezeichnungen sich auf einen Dateitransfer beziehen und in anderen Situationen die Rollen wechseln können, d. h. ein Download-Nutzer zum Upload-Nutzer wird und umgekehrt.
  • Ein solches erfindungsgemäßes Verfahren verkürzt die Download-Zeit in asymmetrischen Netzwerken wie z. B. DSL ganz erheblich, da mehrere Upload-Terminals mit einer geringen Upload-Bandbreite ein Download-Terminal mit einer höheren Download-Bandbreite bedienen. Dabei können die von verschiedenen Terminals der Upload-Nutzer kommenden Fragmente der gewünschten Datei parallel vom Terminal des Download-Nutzers empfangen werden. Der Begriff „parallel" ist hierbei im Sinne des Übertragungsprotokolls zu verstehen. Dabei werden zwar – auf unterster Netzwerkebene betrachtet – die einzelnen Übertragungspakete technisch seriell übertragen. Jedoch werden die einzelnen Pakete dabei, ohne dass das Download-Terminal Einfluss auf die Reihenfolge der Pakete hat, so an das empfangende Terminal gesendet, dass die Download-Bandbreite optimal genutzt wird und die Fragmente möglichst schnell übertragen werden. Die gewünschte Datei muss dann beim Download-Nutzer nur noch aus den von den verschiedenen Terminals erhaltenen Fragmenten rekonstruiert werden. Dies stellt aber kein Problem dar, da auch bei einer klassischen Übertragung einer Datei von nur einem einzigen anderen am Netzwerk angeschlossenen Terminal die Übertragung meist paketweise erfolgt und eine entsprechende Rekonstruktion der Datei beim Empfänger erforderlich ist. Geeignete Methoden hierzu sind folglich dem Fachmann geläufig.
  • Weitere Aufgaben der Erfindung sind die Schaffung eines Inhalteübertragungssystems sowie ein geeignetes Terminal zum Herunterladen eines digitalen Inhalts, mit denen dieses Verfahren durchführbar ist.
  • Diese Aufgaben werden zum einen durch ein Inhalteübertragungssystem gemäß Anspruch 28 und zum anderen durch ein Terminal gemäß Anspruch 32 gelöst.
  • Ein erfindungsgemäßes Inhalteübertragungssystem zur Übertragung digitaler Inhalte eines Inhalteanbieters auf ein Terminal eines Download-Nutzers des Inhalteübertragungssystems in einem Computernetzwerk weist demnach eine Transferinitialisierungseinrichtung auf, welche nach Empfang einer Anfrage eines Download-Nutzers nach einem bestimmten Inhalt das Terminal des Download-Nutzers dazu veranlasst, Fragmente der Datei mit dem gewünschten Inhalt von verschiedenen ausgewählten Kandidaten-Upload-Terminals zu empfangen. Unter dem Begriff „Kandidaten-Upload-Terminals" sind hierbei die Terminals zu verstehen, auf denen zumindest Teile einer bestimmten Datei mit dem gewünschten Inhalt für die Übertragung an das Terminal des Download-Nutzers bereitstehen.
  • Auf Seiten des Download-Nutzers muss hierzu ein erfindungsgemäßes Terminal zum Herunterladen eines digitalen Inhalts eines Inhalteanbieters eines Computer-Kommunikationsnetzwerk zur Verfügung stehen, welches neben einer Netzwerkschnittstelle zum Empfang von Fragmenten der Datei von anderen am Computer-Kommunikationsnetzwerk angeschlossenen Terminals eine geeignete Transaktionssteuereinheit aufweist, welche so ausgebildet ist, dass das Terminal Fragmente der Datei von Terminals verschiedener Upload-Nutzer empfängt.
  • Bei einem solchen Terminal kann es sich um ein beliebiges Endgerät handeln, welches an das Computer-Kommunikationsnetzwerk anschließbar ist, beispielsweise einen PC, ein Laptop, einen Personal Digital Assistant (PDA), ein Mobilfunkgerät mit einer geeigneten Ausstattung oder ein Gerät, welches speziell zum Empfang und zur Verarbeitung von digitalen Inhalten vorgesehen ist, wie beispielsweise eine Set-Top-Box zur Verwendung mit einem Fernseher, ein MP3-Player oder dergleichen.
  • Üblicherweise handelt es sich bei solchen Terminals um programmierbare Geräte. Daher können beispielsweise die Transaktionssteuereinheit und die sonstigen zur Durchführung der Erfindung bzw. zur Durchführung von bestimmten Ausgestaltungen der Erfindung benötigten Komponenten in Form von Software auf dem Terminal implementiert sein. Dies hat den Vorteil, dass durch geeignete Softwareinstallationen bereits bestehende Terminals für eine erfindungsgemäße Funktion nachgerüstet werden können.
  • Die abhängigen Ansprüche enthalten jeweils besonders vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung, wobei das erfindungsgemäße Inhalteübertragungssystem und das erfindungsgemäße Terminal auch nach erfindungsgemäßen Verfahren weitergebildet sein können und umgekehrt.
  • Um immer eine möglichst schnelle Versorgung der Nutzer mit den gewünschten Inhalten sicherstellen zu können, wird bevorzugt zumindest ein Teil der Fragmente der Datei von einem speziell hierfür vorgesehenen Basis-Speicherterminal des Inhalteübertragungssystems aus an das Terminal des Download-Nutzers übertragen, wenn keine oder zu wenige Terminals von Upload-Nutzern zur Verfügung stehen, auf denen die passenden Teile der Datei zu einer Übertragung bereitstehen. Hierzu muss lediglich die Transaktionssteuereinheit des Terminals des Download-Nutzers, im Folgenden auch Download-Terminal genannt, derart ausgebildet sein, dass das Terminal entsprechend zumindest einen Teil der Fragmente der Datei von einem solchen Basis-Speicherterminal empfängt. Bei diesem Basis-Speicherterminal kann es sich beispielsweise um einen Server des Inhalteanbieters und/oder des Betreibers des Inhalteübertragungssystems handeln. Selbstverständlich können innerhalb des Inhalteübertragungssystems auch mehrere solcher Basis-Speicherterminals zur Verfügung stehen.
  • Ein solches Basis-Speicherterminal ist in der Regel zumindest dann erforderlich, wenn noch keiner der Nutzer die Datei mit dem entsprechenden Inhalt besitzt, d. h. für das erstmalige Herunterladen des Inhalts in das Peer-to-Peer-Netzwerk. Zudem ist aber gemäß diesem bevorzugten Ausführungsbeispiel auch vorgesehen, in bestimmten Situationen zumindest ein Basis-Speicherterminal parallel zu den Terminals der Upload-Nutzer einzusetzen, um die Download-Geschwindigkeit auf einem bestimmten Niveau zu halten. Beispielsweise kann bereits der zweite Nutzer, der einen bestimmten Inhalt anfordert, die Datei mit dem entsprechenden Inhalt zu einem Teil von dem ersten Nutzer und zu einem weiteren Teil vom zentralen Basis-Speicherterminal erhalten. Fordert dann ein dritter Nutzer denselben Inhalt an, so erhält er diesen z. B. von den Terminals des ersten und zweiten Nutzers und parallel Teile von einem Basis-Speicherterminal. Dieses Vorgehen wird solange fortgeführt, bis eine maximale Anzahl an Terminals von Upload-Nutzern erreicht wird. Das zentrale Basis-Speicherterminal tritt dabei immer weiter in den Hintergrund und wird somit immer weniger belastet.
  • Die Organisation, wann welches Fragment der Datei von welchem Upload-Terminal aus heruntergeladen wird, kann durch die Transaktionssteuereinheit des Terminals des Download-Nutzers erfolgen. Die maximale Anzahl der Upload-Terminals kann so gesetzt sein, dass die Gesamt-Upload-Bandbreite, die durch die verschiedenen Upload-Terminals erreicht wird, in etwa der Download-Bandbreite entspricht, die am Terminal des Download-Nutzers zur Verfügung steht. Diese maximale Anzahl der Upload-Terminals muss daher auch nicht fix sein, sondern kann in Abhängigkeit von den bei den einzelnen Upload-Terminals zur Verfügung stehenden Upload-Bandbreiten festgelegt werden. Entsprechend kann auch die Verteilung gewählt werden, wie viele Anteile der Datei von welchem der Upload-Terminals heruntergeladen werden. Unter „Upload-Terminal" sind im Übrigen nicht nur die Terminals von Upload-Usern zu verstehen, sondern auch ein zentrales Basis-Speicherterminal, auf dem die Datei zum Download bereitsteht.
  • Vorzugsweise sendet das Terminal des Download-Nutzers an mögliche Upload-Terminals, auf denen zumindest bestimmte Teile der Datei zu einem Upload bereitstehen, Anforderungssignale zur Anforderung bestimmter Fragmente der gewünschten Datei. Es werden dann die jeweils angeforderten Segmente von dem betreffenden Upload-Terminal an das Download-Terminal übermittelt.
  • Bei einem besonders bevorzugten Ausführungsbeispiel sendet das Terminal des Download-Nutzers an ein Upload-Terminal dabei einen Anforderungs signalblock, mit dem gleichzeitig mehrere Fragmente der gewünschten Datei angefordert werden. Dies beschleunigt das Übertragungsverfahren erheblich, da hierdurch der Overhead an Steuerdaten im Verhältnis zu den transportierten Nutzdaten stark reduziert werden kann. Eine solche Vorgehensweise ist daher auch in anderen Netzwerken sinnvoll, in denen eine Datei nicht parallel von mehreren Uploadern an einen Downloader übertragen wird, sondern in denen jeweils ein Downloader sich die Datei nur von einem Upload-Terminal übertragen lässt. Dieses Verfahren kann daher auch als eine eigene Erfindung zur Lösung der o. g. Aufgabe einer Beschleunigung des Downloads gesehen werden.
  • Damit das Terminal des Download-Nutzers darüber informiert ist, an welche Upload-Terminals überhaupt Anforderungssignale gesendet werden können, wird bei einem bevorzugten Ausführungsbeispiel vom Terminal des Download-Nutzers aus an eine zentrale Indexierungseinrichtung des Inhalteübertragungssystems eine Anfrage nach einem bestimmten Inhalt gesendet. Von dieser zentralen Indexierungseinrichtung wird dann eine Gruppe von Kandidaten-Upload-Terminals ermittelt, auf denen zumindest Teile der Datei – in der Regel die ganze Datei – jeweils zu einem Upload bereitstehen. Es werden dann von der zentralen Indexierungseinrichtung an das Terminal des Download-Nutzers Adressinformationen, wie z. B. die Internet-URLs oder ähnliche Netzwerkadressen der Kandidaten-Upload-Terminals, an das Download-Terminal übermittelt. Soweit das Download-Terminal diese Informationen erhalten hat, werden von diesem zumindest an einen Teil der Kandidaten-Upload-Terminals die Anforderungssignale zur Anforderung bestimmter Fragmente der Datei gesendet.
  • Bei einer besonders bevorzugten Ausführungsform weist die Transferinitialisierungseinrichtung des Inhalteübertragungssystems daher eine entsprechende Indexierungseinrichtung auf. Die zentrale Indexierungseinrichtung besitzt hierzu eine geeignete Speichereinrichtung, welche die Informationen enthält, auf welchen Terminals verschiedener Nutzer des Inhalteübertragungssystems bzw. auf welchen Basis-Speicherterminals welche Inhalte be reitgestellt sind. Außerdem weist die Indexierungseinrichtung eine Auswahleinheit auf, um nach Empfang einer Anfrage eines Nutzers nach einem bestimmten Inhalt aus diesen Terminals jeweils nach vorgegebenen Kriterien die Gruppe von Kandidaten-Upload-Terminals zu ermitteln.
  • Damit bei der zentralen Indexierungseinrichtung die notwendigen Informationen zur Verfügung stehen, erhält die Indexierungseinrichtung von einem Terminal eines Nutzers des Inhalteübertragungssystems, wenn auf diesem Terminal Dateien zu einem Upload an andere Nutzer des Inhalteübertragungssystems bereitstehen, ein Angebotssignal, das Informationen über die zur Verfügung stehenden Dateien enthält. Das heißt, mögliche Upload-Nutzer melden sich bei der Indexierungseinrichtung jeweils an. Wenn ein bestimmter Nutzer regelmäßig und/oder ständig auf seinem Terminal Dateien zum Download durch andere Nutzer bereitstellt, reicht es aus, wenn dieses Angebotssignal nur die Informationen enthält, ob sich im Angebot des jeweiligen Nutzers seit dem letzten Senden des Angebotssignals etwas geändert hat.
  • Die Auswahl der Upload-Terminals, an welche vom Download-Terminal aus ein Anforderungssignal zur Übermittlung eines Fragments ausgesandt wird, erfolgt vorzugsweise in Abhängigkeit von den einzelnen Upload-Terminals zugeordneten Prioritätswerten. Bevorzugt werden bereits von der Indexierungseinrichtung die Kandidaten-Upload-Terminals in Abhängigkeit von Prioritätswerten ausgewählt und entweder priorisiert – d. h. in einer passenden Reihenfolge – an das Download-Terminal übersandt, so dass das Download-Terminal die Anforderungssignale an die Kandidaten-Upload-Terminals in der Reihenfolge sendet, wie es die Kandidaten-Upload-Terminals von der Indexierungseinrichtung übermittelt bekommen. Ebenso können aber auch mit den Adressinformationen die zugeordneten Prioritätswerte übermittelt werden und dann vom Download-Terminal entsprechend der Prioritätswerte der Reihe nach bei den potentiellen Upload-Terminals angefragt werden. Die Prioritätswerte können den Terminals der verschiedenen Upload-Nutzer jeweils bei einer Erstregistrierung beim Inhalteanbieter oder Systembetreiber oder auch bei einer späteren Anmeldung, wenn sie sich als mögliche Uploader registrieren lassen, vergeben werden. Beispielsweise können die Prioritäten in Abhängigkeit von der Qualität der Datenverbindung, insbesondere unter Berücksichtigung der zur Verfügung gestellten Upload-Bandbreite, gewählt werden. Es können aber auch beliebige andere Kriterien zur Bestimmung der Prioritäten herangezogen werden. Des Weiteren kann die Priorität eines bestimmten Upload-Terminals auch jederzeit geändert werden, um beispielsweise dafür zu sorgen, dass die potentiellen Upload-Terminals möglichst gleichmäßig belastet werden und – sofern eine Vergütung für einen Upload an die Upload-Nutzer erfolgt – auch alle potentiellen Upload-Nutzer eine Chance haben, eine entsprechende Vergütung zu erhalten. Grundsätzlich ist aber auch jede andere beliebige Gewichtungsfunktion denkbar, die z. B. bestimmte Nutzer, beispielsweise Stammkunden, nach vorgegebenen Kriterien des Inhalteanbieters bevorzugt.
  • Vorzugsweise ist einer Datei, die einen bestimmten digitalen Inhalt, beispielsweise einen kompletten Videofilm, einen Musiktitel oder Ähnliches enthält, eine eindeutige Kennung, wie ein eindeutiger Name, eine Kennnummer oder dergleichen, zugeordnet. Besonders bevorzugt handelt es sich hierbei um eine Kennung, die gleichzeitig auch zur Sicherung und Authentifizierung der Datei dienen kann, d. h. die vom Inhalt der Datei abhängig ist. Hierzu bietet sich die Verwendung eines Hashwerts der betreffenden Datei o. Ä. an. Bei Verwendung einer solchen Kennung zur Anforderung einer Datei bzw. von Teilen der Datei kann zum einen die gewünschte Datei eindeutig identifiziert werden, wobei leichter sichergestellt werden kann, dass es sich tatsächlich um die gewünschte und bereits authentifizierte Datei handelt. Insbesondere kann auch der Download-Nutzer nach dem Erhalt einer Datei prüfen, ob die erhaltene Datei vollständig, unverändert und unverfälscht geliefert wurde. Dabei ist es egal, ob die Veränderung einer Datei bewusst durch eine gezielte Manipulation oder unbewusst, z. B. durch einen Übertragungsfehler, geschehen ist.
  • Bei einer besonders bevorzugten Ausführungsvariante wird jede Datei in eine Anzahl von definierten Segmenten zerlegt und jedem der Segmente eine eindeutige Kennung zugeordnet. Vorzugsweise enthält dann ein Anforderungssignal des Download-Terminals an einen Upload-Terminal die eindeutige Kennung des Segments der Datei, zu dem ein angefordertes Fragment gehört.
  • Die Zerlegung in einzelne Segmente hat den Vorteil, dass nicht abgewartet werden muss, bis ein Download komplett abgeschlossen ist, um eine Überprüfung der übersendeten Daten durchzuführen, sondern es reicht aus, wenn das Download-Terminal ein bestimmtes Segment vollständig erhalten hat. Es kann dann bereits das jeweilige Segment mit Hilfe der eindeutigen Kennung geprüft und festgestellt werden, ob das Segment vollständig und unverfälscht übertragen wurde oder ob ggf. weitere Maßnahmen, z. B. eine erneute Anforderung bestimmter Segmente bzw. Fragmente, erforderlich sind.
  • In einer bevorzugten Variante des Verfahrens sendet das Download-Terminal, wenn von einem ersten Upload-Terminal ein bestimmtes zu übersendendes Fragment unvollständig oder gar nicht empfangen wird, ein Anforderungssignal an ein anderes Kandidaten-Upload-Terminal, mit dem dann ein Fragment angefordert wird, das genau dem fehlerhaften oder fehlenden Teil des vom ersten Upload-Terminals zu übersenden Fragments entspricht. Das heißt, es wird – anders als bei bisher bekannten Verfahren – nicht das komplette Fragment noch einmal von einem anderen Upload-Terminal angefordert, sondern es reicht aus, wenn der Rest des Fragments, welcher noch nicht ordnungsgemäß geliefert wurde, erneut angefordert wird. Dies beschleunigt das Übertragungsverfahren erheblich, insbesondere in Peer-to-Peer-Netzwerken, in denen es durchaus vorkommen kann, dass ein Upload-Nutzer, dessen Terminal gerade zu einem Upload verwendet wird, das betreffende Terminal ausschaltet oder aus sonstigen Gründen eine Verbindung unterbrochen wird und somit eine bereits begonnene Übertragung eines Fragments nicht zu Ende geführt werden kann. Eine solche Vorgehens weise ist daher auch in anderen Netzwerken sinnvoll, in denen eine Datei nicht parallel von mehreren Uploadern an einen Downloader übertragen wird, sondern in denen jeweils ein Downloader die Datei sich nur von einem Upload-Terminal übertragen lässt. Auch in solchen Fällen ist es vorteilhaft, wenn die bereits richtig übertragenen Teile der Datei genutzt werden und das Download-Terminal lediglich die nicht gelieferten Teile von demselben oder einem anderen Uploader noch einmal anfordern muss. Dieses Verfahren kann daher ebenfalls als eine eigene Erfindung zur Lösung der o. g. Aufgabe einer Beschleunigung des Downloads gesehen werden.
  • Vorzugsweise enthält hierzu ein Anforderungssignal des Terminals des Download-Nutzers an ein Upload-Terminal nicht nur die eindeutige Kennung der Datei und/oder des Segments der Datei, zu dem ein angefordertes Fragment gehört, sondern auch einen Offsetwert, der die Position des Fragments innerhalb der Datei bzw. des Segments der Datei sowie die Länge des Fragments repräsentiert. Bei dieser Methode zum Aufbau des Anforderungssignals kann das anfragende Terminal die Fragmente genau spezifizieren, so dass es unproblematisch auch Restfragmente anfordern kann, wenn ein zunächst angefordertes Fragment nicht vollständig geliefert wurde.
  • Um sicherzustellen, dass die Datei nicht unbefugt genutzt werden kann, werden die Dateien jeweils verschlüsselt innerhalb des Inhalteübertragungssystems zur Verfügung gestellt und an die Nutzer übertragen bzw. weiter übertragen. Um die Datei dann zu nutzen, beispielsweise auf dem jeweiligen Terminal anzusehen oder anzuhören, eine Datei zu öffnen, auf einen Datenspeicher zu kopieren, insbesondere auf eine CD zu brennen, benötigt der Benutzer einen passenden „Schüssel" für diese Datei. Dabei können durch geeignete Wahl der Verschlüsselung und der Schlüssel, z. B. in Abhängigkeit von der gezahlten Gebühr, den verschiedenen Nutzern auch unterschiedliche Rechte zugestanden werden, beispielsweise ob eine Datei auf einem Terminal unbegrenzt abspielbar ist, wie viele Brennvorgänge erlaubt sind, wie oft Transfers auf andere Geräte – wie MP3-Player – erlaubt sind etc. Ebenso kann ein Schlüssel auch zeitlich begrenzt wirksam sein. Geeig nete Verschlüsselungsverfahren sind dem Fachmann bekannt. Beispielsweise können hierfür übliche DRM-Verfahren (DRM-Digital Rights Management) eingesetzt werden, wie sie u. a. von Microsoft® angeboten werden. Eine Programmierung solcher DRM-Systeme kann z. B. auf Basis der eXtensible rights Markup Language (XRML) erfolgen.
  • Vorzugsweise wird dem Download-Nutzer ein entsprechender Schlüssel zur Entschlüsselung der Datei bereits vor der Übertragung von Fragmenten der Datei übermittelt. Wenn das Download-Terminal den Schlüssel bereits vor dem Empfang von Fragmenten der Datei besitzt, ist es möglich, insbesondere bei einer – wie oben beschriebenen – segmentweisen Überprüfung der Datei, die empfangenen Teile der Datei bereits vor einer Beendigung des vollständigen Datei-Downloads zu entschlüsseln. Dies hat den Vorteil, dass die digitalen Inhalte schon während des Downloads genutzt werden können. Beispielsweise kann ein Videofilm so schon während des Herunterladens, welches aufgrund der großen Datenmenge in der Regel etwas länger dauert, vom Download-Nutzer betrachtet werden.
  • Bei einer bevorzugten Variante des Verfahrens muss sich ein Nutzer zur Verwendung des Inhalteübertragungssystems zunächst innerhalb eines Authentifizierungsverfahrens gegenüber einer Authentifizierungseinheit authentifizieren. Nach erfolgreicher Authentifizierung wird dem Nutzer eine Authentifizierungskennung zugesandt. Mit dieser Authentifizierungskennung kann sich der Nutzer dann im weiteren Verlauf des Verfahrens gegenüber anderen Funktionseinheiten des Inhalteübertragungssystems authentifizieren. Dieses Verfahren hat den Vorteil, dass eine komplette organisatorische Trennung des für den Nutzer nach außen erscheinenden Inhalteanbieters vom eigentlichen Betreiber des Inhalteübertragungssystems, im Folgenden auch kurz „Systembetreiber" genannt, möglich ist, wobei sich der Nutzer beispielsweise gegenüber einer dem Inhalteanbieter zugeordneten und unter der Kontrolle des Inhalteanbieters befindlichen Authentifizierungseinheit authentifiziert und die Authentifizierungskennung erhält. Diese Authentifizierungskennung kann dann gegenüber allen Funktionseinheiten des System betreibers verwendet werden. Der Systembetreiber braucht somit selbst keine genauere Authentifizierung des jeweiligen Nutzers durchzuführen, und es ist insbesondere nicht erforderlich, dass dem Systembetreiber die Passwörter, Benutzernamen o. Ä. des jeweiligen Nutzers bekannt werden, die dieser von seinem Inhalteanbieter erhält. Insbesondere ermöglicht dieses Verfahren, dass auch Firmen, die normalerweise in anderen Branchen, beispielsweise als Betreiber einer Gaststättenkette oder als Getränke-, Süßwaren-, Spielzeug- oder Möbelhändler tätig sind, zu Zwecken der Werbung und/oder der Kundenbindung ohne großen Aufwand auch als Inhalteanbieter für Videos, Musik, Software oder dergleichen im Internet auftreten können. D. h. sie müssen hierzu nicht selbst die notwendige Infrastruktur einrichten und warten, sondern können statt dessen die Dienste eines Betreibers eines erfindungsgemäßen Inhalteübertragungssystems in Anspruch nehmen.
  • Eine solche Authentifizierungskennung kann zeitlich oder auf eine bestimmte Sitzung des Nutzers begrenzt sein, so dass der Nutzer z. B. jedes Mal beim Neuanmelden beim System eine neue Authentifizierungskennung erhält. Grundsätzlich kann eine solche Authentifizierungskennung aber auch nur einmal bei einer Erstregistrierung des Nutzers vergeben werden.
  • Bei einem besonders bevorzugten Verfahren findet eine weitere Trennung statt, indem an den Download-Nutzer (in der Regel direkt an das Download-Terminal) nach einer Auswahl, d. h. nach einem Kauf eines vom Inhalteanbieter angebotenen digitalen Inhalts, eine Dateiempfangsberechtigungskennung und eine Schlüsselempfangsberechtigungskennung zugesandt werden. Vom Download-Nutzer kann dann die Dateiempfangsberechtigungskennung an die jeweiligen Upload-Terminals zum Erhalt von Fragmenten der gewünschten Datei gesendet werden. Die Schlüsselempfangsberechtigungskennung wird dagegen an eine Lizenzerteilungseinrichtung zum Erhalt des Schlüssels weitergeleitet. Dies hat den Vorteil, dass die Lizenzerteilungseinrichtung unabhängig von einem dem Endnutzer gegenüber in Erscheinung tretenden Inhalteanbieter und/oder vom Systembetreiber sein kann. Zwar ist es grundsätzlich möglich, dass beispielsweise der Inhalteanbieter oder der Betreiber des Inhalteübertragungssystems auch die Lizenzerteilungseinrichtung betreiben und selbst dazu befugt sind, Lizenzen für die Inhalte zu erteilen. Andererseits erlaubt eine Trennung dieser Funktionen auch, dass beispielsweise die Lizenzerteilungseinrichtung von dem eigentlichen Inhaber der Urheber- bzw. Lizenzierungsrechte der Inhalte betrieben wird und sich der Inhalteanbieter und der Systembetreiber – abgesehen von der späteren Abrechnung mit dem Rechteinhaber und der sicheren Übermittlung der Dateien – nicht mit den Lizenzen befassen müssen. Insbesondere erlaubt dies, dass sowohl der Inhalteanbieter als auch der Systembetreiber Inhalte von verschiedensten Rechteinhabern anbieten können und je nach Rechteinhaber unterschiedliche Lizenzdienste bzw. Lizenzerteilungseinrichtungen im Verfahren verwendet werden, in Abhängigkeit davon, welcher Rechteinhaber die Urheber- bzw. Lizenzierungsrechte für den jeweils gewünschten Inhalt besitzt.
  • Sofern Inhalteanbieter und Systembetreiber getrennte Organisationseinheiten sind, können mehrere getrennte Inhalteanbieter ein Inhalteübertragungssystem eines Systembetreibers nutzen. Dabei ist vorzugsweise jeder Datei mit einem von einem bestimmten Inhalteanbieter angebotenen digitalen Inhalt und/oder jedem Segment einer solchen Datei innerhalb des Inhalteübertragungssystems eine eindeutige Kennung zugeordnet, die nicht nur vom Inhalt der Datei bzw. des Segments, sondern auch vom jeweiligen Inhalteanbieter abhängt. Dies bedeutet, dass gleichartige Dateien mit demselben Inhalt innerhalb eines Inhalteübertragungssystems durchaus unterschiedliche eindeutige Kennungen aufweisen, sofern sie zu unterschiedlichen Inhalteanbietern gehören. Innerhalb der von einem bestimmten Inhalteanbieter angebotenen Inhalte ist die Kennung der Datei jedoch eindeutig. Bei einer Veränderung der Datei verändert sich auch die Kennung, so dass die Datei nach wie vor mit Hilfe der Kennung authentifiziert werden kann. Dies ist beispielsweise dann möglich, wenn als Kennung ein Hashwert nicht nur über die Datei, sondern noch zusätzlich über eine eindeutige Kennung eines Inhalteanbieters gebildet wird. Dieses bevorzugte Verfahren hat den Vorteil, dass der Inhalteanbieter dafür sorgen kann, dass nur zu dem betreffenden Inhalteanbieter gehörige Nutzer untereinander Dateien innerhalb des Peer-to-Peer-Netzwerkes versenden. Auf diese Weise kann der Inhalteanbieter sicherstellen, dass – sofern einer seiner Nutzer einen Inhalt anfordert – dieser Inhalt auch von anderen seiner Nutzer übertragen wird und, wenn eine entsprechende Vergütung gezahlt wird, diese Vergütung den eigenen Nutzern zukommt.
  • Um eine Vergütung für den Upload-Nutzer festlegen zu können, weist das Inhalteübertragungssystem vorzugsweise eine Transaktionsaktionskontrolleinrichtung auf, die – nach einer Übermittlung von Fragmenten der Datei von Upload-Terminals an das Terminal des Download-Nutzers – leistungsrelevante Daten von den Upload-Terminals und/oder vom Terminal des Download-Nutzers empfängt. Anhand dieser Daten kann dann eine Vergütung der Upload-Nutzer für die Zur-Verfügung-Stellung der jeweiligen Upload-Terminals zur Übermittlung der Daten an das Terminal des Download-Nutzers ermittelt werden. Dabei kann die Vergütung „leistungsabhängig", beispielsweise in Abhängigkeit von der Menge der übermittelten Daten, erfolgen. Zusätzlich können diese Daten auch für eine einfache Kontrolle der Transaktion verwendet werden, d. h. um festzustellen, ob beispielsweise der Download-Nutzer auch die gleiche Menge an Daten erhalten hat, wie sie von den Upload-Terminals abgesendet wurde.
  • In erster Linie ist vorgesehen, dass innerhalb des Inhalteübertragungssystems Dateien übertragen werden, die vom Inhalteanbieter und/oder vom Systembetreiber zunächst auf einem zentralen Basis-Speicherterminal bereitgestellt werden. Diese Inhalte werden entsprechend zuvor geprüft und durch Erteilung einer entsprechenden Kennung, beispielsweise des Hashwertes, gesichert und für eine Übertragung innerhalb des Systems autorisiert. Grundsätzlich ist es jedoch auch möglich, dass ein Nutzer einen von ihm selbst erstellten bzw. zusammengestellten oder auf andere Weise legal erworbenen Inhalt innerhalb des Inhalteübertragungssystems zur Verfügung stellt. Eine Datei mit dem betreffenden digitalen Inhalt kann dann zunächst durch den Inhalteanbieter und/oder durch den Netzbetreiber geprüft werden, und es wird bei positiv verlaufender Überprüfung dieser Datei ebenfalls eine Kennung zugeordnet. Dies ist natürlich nicht erforderlich, wenn es sich hierbei um eine Datei handelt, die der Nutzer innerhalb des Inhalteübertragungssystems erhalten hat. Eine solche Datei weist dann bereits eine eindeutige Kennung innerhalb des Inhalteübertragungssystems auf. Grundsätzlich ist es auch möglich, im Handel Datenträger mit bestimmten Inhalten anzubieten, welche bereits für eine Übermittlung innerhalb eines bestimmten Inhalteübertragungssystems autorisiert sind und schon eine solche Kennung tragen. Dies hat den Vorteil, dass ein Nutzer unmittelbar nach Erwerb eines solchen geprüften legalen Inhalts diesen nicht nur selber konsumieren kann, sondern auch auf einem Terminal zur Übertragung an andere Nutzer innerhalb des betreffenden Inhalteübertragungssystems zur Verfügung stellen kann und – sofern von seinem Terminal aus Uploads an andere Nutzer erfolgen – entsprechende Vergütungen erhält, mit denen er den Kauf des Inhalts refinanzieren kann.
  • Damit ein beliebiger Nutzer sich zunächst informieren kann, welche Inhalte ein bestimmter Inhalteanbieter im Angebot hat, weist das Inhalteübertragungssystem eine Angebotsübersichtseinheit an, welche entweder vom Systembetreiber dem Inhalteanbieter zur Verfügung gestellt oder von diesem selbst betrieben wird. Ein solcher „Inhalteanbietershop" kann von einem Nutzer in üblicher Weise, beispielsweise über das Internet mit einem geeigneten Browser, „besucht" werden. Der Nutzer kann sich dann die zur Verfügung stehenden Inhalte anzeigen lassen und ggf. Metadaten wie z. B. zusätzliche Informationen der Inhalte oder auch Trailer oder andere Ausschnitte aus den Inhalten für einen Test abrufen. Wie in Internetshops üblich, kann der Nutzer dann einen Inhalt auswählen und vorzugsweise auch einem virtuellen „Warenkorb" hinzufügen, um dann alle ausgewählten Inhalte zum Ende einer Sitzung nach Abwicklung der Zahlungsmodalitäten herunterzuladen.
  • Bei einer besonders bevorzugten Variante können Informationen über die von einem bestimmten Nutzer auf seinem Terminal für einen Upload an andere Nutzer des Inhalteübertragungssystems bereitgestellten Inhalte auch von einer Angebotsinformationseinheit, die sich auf dem Terminal des betreffenden Nutzers befindet, von einem Terminal eines anderen Nutzers abgerufen werden. Das heißt, der betreffende Nutzer kann selbst auf seinem Terminal eine Art „Nutzer-Shop" einrichten, den andere Nutzer des Systems genau wie den Inhalteanbietershop mit einem Browser besuchen können. Der jeweilige Nutzer kann in „seinem" Shop beispielsweise eigene Bewertungen zu den Inhalten hinzufügen und/oder Empfehlungen abgeben. Er kann dadurch andere Nutzer animieren, bestimmte Inhalte herunterzuladen. Sofern sich ein Nutzer entscheidet, einen der Inhalte herunterzuladen, wird jedoch vorzugsweise – unabhängig davon, ob der betreffende Download-Nutzer durch den Shop eines anderen Nutzers oder durch den Shop des Inhalteanbieters zum Download veranlasst wurde – ein Download in der erfindungsgemäßen Weise von mehreren Terminals anderer Nutzer des Systems durchgeführt. Sofern der Download-Nutzer durch den Besuch des Shops eines anderen Nutzers zum Download veranlasst wurde, kann dem jeweiligen Nutzer eine Vermittlungsprovision gezahlt werden, auch wenn er nicht am Upload beteiligt wird.
  • Diese Vorgehensweise verstärkt die Bindung der Nutzer an einen bestimmten Inhalteanbieter und animiert die Nutzer zu einer aktiven Teilnahme innerhalb des Inhalteübertragungssystems.
    •
  • Die Erfindung wird im Folgenden unter Hinweis auf die beigefügten Figuren anhand von Ausführungsbeispielen noch einmal näher erläutert. Es zeigen:
  • 1 eine schematische Darstellung des Ablaufs einer Übertragung eines Inhalts an einen ersten Nutzer, einen zweiten Nutzer und einen dritten Nutzer nach einer Ausführungsform der Erfindung,
  • 2 eine schematische Darstellung einer in mehrere Segmente unterteilten Datei,
  • 3 ein Prinzip-Blockschaltbild einer Struktur eines Ausführungsbeispiels des erfindungsgemäßen Inhalteübertragungssystems,
  • 4 ein Prinzip-Blockschaltbild eines Ausführungsbeispiels eines innerhalb des Verfahrens nutzbaren Terminals,
  • 5 eine detailliertere schematische Darstellung des Ablaufs eines Downloads nach einer weiteren Ausführungsform der Erfindung,
  • 6 eine schematische Darstellung einer möglichen Anmeldung eines durch einen Firewall gesicherten Terminals,
  • 7 eine schematische Darstellung eines Ablaufs eines Downloads von einem durch eine Firewall gesicherten Terminal.
  • In 1 wird in sehr vereinfachter Form ein möglicher Ablauf des erfindungsgemäßen Verfahrens zum Download auf die Terminals T1, T2, T3 der ersten drei Benutzer eines Inhalteübertragungssytems gezeigt, die eine Datei mit einem bestimmten Inhalt herunterladen möchten.
  • Voraussetzung ist zunächst, dass die betreffende Datei auf einem Basis-Speicherterminal SP, im Folgenden auch kurz „Seedpeer" SP genannt, für einen erstmaligen Download durch einen Nutzer hinterlegt ist. Hierzu wird die Datei mit dem entsprechenden Inhalt vom Systembetreiber SB vorbereitet, d. h. beispielsweise geprüft und verschlüsselt und durch eine eindeutige Kennung, z. B. einen Hashwert, gesichert und auf dem Seedpeer SP bereitgestellt.
  • Bei der Vorbereitung wird die Datei D auch in eine bestimmte Anzahl von Segmenten P0, P1, P2, P3, P4 zerlegt und diesen einzelnen Segmenten P0, P1, P2, P3, P4 werden ebenfalls eindeutige Kennwerte, z. B. Hashwerte, zugeordnet. Die Segmente P0, P1, P2, P3, P4 einer Datei D sind jeweils mit einem Index gekennzeichnet. Das erste Segment P0 erhält den Index 0. Je des dieser Segmente P0, P1, P2, P3, P4 hat einen Offset OP1, OP2, welcher den Beginn des Segments innerhalb der Datei D markiert, und eine festgelegte Länge Ip, IR. Die Struktur einer solchen zerlegten Datei D ist in 2 schematisch dargestellt, wobei jedoch von den Offsets der besseren Übersichtlichkeit wegen nur die Offsets OP1, OP2 des zweiten Segments P1 und des dritten Segments P2 eingezeichnet sind. Die dort gezeigte Datei D ist insgesamt in 5 Segmente P0, P1, P2, P3, P4 aufgeteilt, wobei alle Segmente bis auf das letzte Segment P4 die gleiche Länge IP aufweisen. Lediglich das letzte Segment P4 hat eine Länge IR, welche der Restlänge der Datei D entspricht. Die Länge eines solchen Segments kann im Prinzip frei festgelegt werden und auch von der Länge der Gesamtdatei abhängen. So ist bei einem ersten Ausführungsbeispiel vorgesehen, für Segmente von Musiktiteln eine Länge IP von 1 MB und für Segmente von Videofilmen eine Länge IP von 8 MB zu wählen.
  • Die Kennung der Datei D bzw. der einzelnen Segmente P0, P1, P2, P3, P4 ist jeweils insoweit eindeutig, dass die Kennung nicht mehr passt, wenn der Inhalt des Segments P0, P1, P2, P3, P4 bzw. der Datei D geändert wird. Auf diese Weise ist mittels der Kennung prüfbar, ob eine Datei D bzw. ein Segment P0, P1, P2, P3, P4 manipuliert oder auf sonstige Weise verändert wurde. Die Kennung ist außerdem noch vom Inhalteanbieter RS abhängig, so dass ein und dieselbe Datei bzw. ein Segment einer solchen Datei, welche von zwei verschiedenen Inhalteanbietern angeboten wird, nicht dieselbe Kennung aufweist.
  • Die Datei bzw. Teile der Datei können dann jederzeit von den Nutzern vom Seedpeer SP unter Angabe einer eindeutigen Kennung eines Segments P0, P1, P2, P3, P4 der gewünschten Datei heruntergeladen werden.
  • Dabei wird jedes dieser Segmente P0, P1, P2, P3, P4 bei einer späteren Datenanforderung von einem Download-Terminal, unabhängig davon, ob die Anforderung an einen Seedpeer oder ein Terminal eines Upload-Nutzers gesendet wird, in Fragmente F aufgeteilt. Ein Fragment F ist dabei eine Ein heit, die zusammenhängend von genau einem Upload-Terminal an genau ein Download-Terminal über das Netzwerk übertragen wird. Die Fragmente F haben ebenfalls einen Index, einen Offsetwert OF und eine Länge IF. Der Index spiegelt jedoch, anders als bei den Segmenten P0, P1, P2, P3, P4, nicht zwingend die Reihenfolge der Fragmente F innerhalb des Segments P0, P1, P2, P3, P4 wieder. Der Offsetwert OF gibt den Versatz innerhalb des Segments, d. h. den Abstand des Startpunkts des Fragments F vom Startpunkt des Segments wieder. Das erste Fragment F erhält in der Regel den Index 0. Das Offset OF und die Länge IF eines angefragten Fragments werden vom Downloader unmittelbar vor der Anforderung frei wählbar festgelegt. Die Länge eines Fragments kann beispielsweise in der Größenordnung von 256 KB liegen. Größe und Anzahl der Fragmente brauchen jedoch beim Beginn eines Dateitransfers noch nicht festzustehen. Ein Upload-Terminal, welches die Anforderung empfängt, überträgt stets genau die Daten, die das Download-Terminal nachfragt.
  • Dies hat den Vorteil, dass, wenn bei der Übermittlung eines Fragments F die Verbindung unterbrochen wird und nur ein Teil des Fragments F übertragen wird, vom Terminal T2 aus nur eine Anfrage an ein anderes Terminal gesandt werden muss, um das Restfragment FR zu erhalten. Dies ist in 2 angedeutet. Es muss beispielsweise, wenn das Fragment F bereits bis auf ein Restfragment FR übermittelt wurde, lediglich ein neues Fragment angefordert werden, welches den Offsetwert OFR und die Länge IFR des Restfragments aufweist. Es ist also nicht erforderlich, das komplette Fragment F noch einmal von einem anderen Terminal herunterzuladen, was erheblich zeitaufwendiger wäre.
  • Das Vorbereiten und Bereitstellen der Inhalte auf dem Seedpeer SP ist in 1 im Schritt 100 dargestellt. Die Einstellung der Dateien D durch den Systembetreiber SB auf dem Seedpeer SP erfolgt dabei in der Regel nach den Vorgaben des Inhalteanbieters RS.
  • Zu irgendeinem späteren Zeitpunkt meldet sich dann ein erster Benutzer über ein erstes Terminal T1 beim Inhalteanbieter RS bzw. bei einem dem Inhalteanbieter RS zugeordneten Server an, auf welchem der Inhalteanbieter RS einen Internet-Onlineshop SR betreibt (Schritt 101). Er erhält dann, nachdem er sich entsprechend authentifiziert hat, im Schritt 102 eine Authentifizierungskennung, im Folgenden auch kurz „Ticket" genannt, welches für die gesamte Sitzung gültig ist. Zur Erstellung dieses Tickets wird ein dem Inhalteanbieter RS zugeordneter Teil auf einem Server SUA des Systembetreibers SB, welcher speziell für Authentifizierungszwecke dient, erstellt. Eine mögliche Vorgehensweise bei dieser Anmeldeprozedur wird später noch detaillierter beschrieben.
  • Im Schritt 103 kann dann der erste Nutzer mittels seines Terminals T1, beispielsweise mit Hilfe eines üblichen Browsers, im Internetshop des Inhalteanbieters einen Inhalt aussuchen und zum Kauf auswählen.
  • Wenn sich der erste Nutzer für einen ersten Inhalt entschieden hat und diesen Inhalt „gekauft" hat, erfolgt im Schritt 104 die Abrechnung durch den Inhalteanbieter RS. Anschließend werden im Schritt 105 die eindeutigen Kennungen der Datei D und der zugehörigen Segmente P0, P1, P2, P3, P4 sowie eine Dateiempfangsberechtigungskennung, im Folgenden „Download-ID" genannt, und eine Schlüsselempfangsberechtigungskennung, im Folgenden „Voucher" genannt, an das Terminal T1 des ersten Nutzers gesandt.
  • Der Voucher ist zeitlich begrenzt gültig, d. h. der Benutzer muss innerhalb einer bestimmten Zeit mit dem Voucher einen Schlüssel für die Datei D abholen. Hierzu sendet der erste Nutzer von seinem Terminal T1 aus unter Angabe des Vouchers eine Schlüsselanfrage an einen Lizenzserver SL (Schritt 106) und erhält daraufhin vom Lizenzserver SL den Schlüssel auf sein Terminal T1 zugesandt (Schritt 107). In einem nächsten Schritt 108 wird vom Terminal T1 unter Versendung des Tickets und der Kennung der gewünschten Datei eine Quellenanfrage an eine zentrale Indexierungseinrichtung SI gesendet, welche hier zum Systembetreiber SB gehört und beispielsweise mit weiteren Funktionseinheiten des Systembetreibers SB auf einem Server installiert ist. Von dort werden dann im Schritt 109 Adressinformationen an das Terminal T1 zurückgesandt, die angeben, auf welchen Kandidaten-Upload-Terminals die Datei mit dem gewünschten Inhalt zur Verfügung steht. Dabei sucht die Indexierungseinrichtung SI die Kandidaten-Upload-Terminals anhand von den einzelnen Terminals zugeordneten Prioritäten gemäß einer vorgegebenen Gewichtungsfunktion aus und sendet dann die Adressinformationen in der Reihenfolge, in der das Terminal T1 anschließend bei den einzelnen Kandidaten-Upload-Terminals nach einer Übermittlung von Fragmenten F der gewünschten Datei D anfragen soll.
  • In dem in 1 oben dargestellten Beispiel handelt es sich um den ersten Download eines bestimmten Inhalts. Daher ist diese Datei bisher lediglich auf dem Seedpeer SP hinterlegt. Das Terminal T1 des ersten Nutzers erhält daher nur die Adresse des Seedpeers SP. Vom Terminal T1 des Nutzers wird dann im Schritt 110 ein Anforderungssignal an den Seedpeer SP gesandt, welcher daraufhin im Schritt 111 die gewünschten Fragmente, in diesem Fall nach und nach die komplette Datei, an das Terminal T1 übersendet.
  • Vom Seedpeer SP werden dann nach dieser Übertragung im Schritt 112 Leistungsdaten an den Systembetreiber SB übersandt, aufgrund deren im Schritt 113 der Download kontrolliert wird. Hierzu kann beispielsweise auch das Terminal T1 Leistungsdaten an den Systembetreiber SB übersenden, um die Kontrolle durch einen Vergleich der von dem Seedpeer SP übermittelten Daten und der vom Download-Terminal T1 übermittelten Daten durchzuführen. Dieser Schritt ist in 1 jedoch nicht dargestellt.
  • In der Indexierungseinheit SI ist jetzt bekannt, dass die Datei mit dem betreffenden Inhalt nicht nur auf dem Basis-Speicherterminal SP, sondern auch auf dem Terminal T1 des ersten Nutzers vorhanden ist. In den weiteren Schritten wird vorausgesetzt, dass das Terminal T1 des ersten Nutzers auch für eine weitere Übermittlung der Datei an andere Nutzer zur Verfügung steht. Sinnvollerweise erfolgte dies durch eine spezielle Registrierung, da ja nicht jeder Nutzer bereit ist, sein Terminal für Uploads zur Verfügung zu stellen und auch nicht jederzeit das Terminal am Netz angeschlossen ist. Ein mögliches Verfahren für eine solche spezielle „Uploader-Registrierung" wird später noch anhand von 5 erläutert.
  • Bei dem Beispiel gemäß 1 wird dann weiter vorausgesetzt, dass ein zweiter Nutzer, nachdem er sich im Schritt 121 mit seinem Terminal T2 bei einem Inhalteanbieter RS angemeldet und im Schritt 122 ein Ticket erhalten hat, beim Suchen eines Inhalts im Schritt 123 denselben Inhalt auswählt, wie ihn der erste Nutzer zuvor erhalten hat. Nachdem der zweite Nutzer sich für diesen Inhalt entschieden hat, erfolgt auch hier eine Abrechnung beim Inhalteanbieter im Schritt 124. Im darauffolgenden Schritt 125 erfolgt dann wieder eine Übersendung der Kennung der Datei und der Segmente, der „Download-ID" und des „Vouchers" an das Terminal T2 des zweiten Nutzers. Im Schritt 126 wird vom Terminal T2 eine Schlüsselanfrage unter Angabe des Vouchers an den Lizenzserver SL gesendet, welcher daraufhin im Schritt 127 den Schlüssel zurücksendet. Unter Angabe des Tickets des zweiten Nutzers erfolgt dann vom Terminal T2 des zweiten Nutzers im Schritt 128 eine Quellenanfrage an die zentrale Indexierungseinrichtung SI des Systembetreibers SB, welche daraufhin im Schritt 129 die Adressinformationen, auf welchen Kandidaten-Upload-Terminals die Datei mit dem betreffenden Inhalt zum Download bereitsteht, an das Terminal T2 zurücksendet. In dem dargestellten Beispiel handelt es sich hierbei zum einen um die Adresse des Terminals T1 des ersten Nutzers und die Adresse des Seedpeers SP. In den Schritten 130 und 131 sendet daher das Terminal T2 des zweiten Nutzers Anforderungssignale an die in Frage kommenden Terminals T1 und SP. Dies erfolgt unter Angabe der Download-ID, anhand derer die zum Upload zur Verfügung stehenden Terminals T1, SP die Berechtigung des Download-Terminals T2 überprüfen. Die Upload-Terminals T1, SP senden daraufhin in den Schritten 132, 133 die angefragten Fragmente der Datei an das Terminal T2 des zweiten Nutzers. Am Ende des Downloads übermitteln sowohl das Terminal T1 des ersten Nutzers als auch der Seedpeer SP in den Schrit ten 134, 135 jeweils wieder Leistungsdaten an den Systembetreiber SB, anhand deren eine Kontrolle der Transaktion durchgeführt wird (Schritt 136). Bei der Kontrolle wird auch ermittelt, wie viele Daten der erste Nutzer von seinem Terminal T1 an das Terminal T2 des zweiten Nutzers übermittelt hat und dementsprechend eine Vergütung für den ersten Nutzer für die Zur-Verfügung-Stellung seines Terminals T1 beim Download zum zweiten Nutzer berechnet.
  • Im Schritt 137 wird dementsprechend eine Vergütungsmitteilung an das Terminal T1 des ersten Nutzers gesandt. Diese Vergütung kann dem ersten Nutzer gutgeschrieben werden, so dass er beispielsweise bei späteren, eigenen Downloads die erhaltene Vergütung mit den dann zu zahlenden Beträgen verrechnen kann. Es ist aber auch möglich, dass beim Systembetreiber SB oder beim Inhalteanbieter RS Konten für die Nutzer geführt werden und dem Nutzer der Betrag auf andere Weise, beispielsweise durch eine Überweisung bei Erreichen einer Mindestsumme, ausgezahlt wird. Die Übersendung einer solchen Vergütungsmitteilung ist optional. Sie hat jedoch den Vorteil, dass ein Upload-Nutzer auf seinem Terminal jederzeit abfragen kann, welche Beträge er bisher durch seine Uploader-Tätigkeit erhalten hat. Dies ist eine zusätzliche Motivation, damit die Nutzer ihre Terminals auch für Uploads zur Verfügung stellen.
  • Vorausgesetzt, dass sowohl der erste Nutzer als auch der zweite Nutzer anschließend ihre Terminals T1, T2 für weitere Uploads zur Verfügung stellen, stehen für einen dritten Nutzer, welcher den gleichen Inhalt herunterladen möchte, nun insgesamt drei Terminals, nämlich das Terminal T1 des ersten Nutzers, das Terminal T2 des zweiten Nutzers und der Seedpeer SP zur Verfügung.
  • Dieses Szenario wird im untersten Drittel von 1 dargestellt. Auch der dritte Nutzer muss sich mit seinem Terminal T3 zunächst im Schritt 141 beim Inhalteanbieter RS anmelden und erhält im Schritt 142 ein Ticket. Im Schritt 143 kann er dann im Onlineshop SR des Inhalteanbieters RS den Inhalt auswählen. Sobald er sich für den besagten Inhalt entschieden hat, erfolgt im Schritt 144 die Abrechnung. Im Schritt 145 werden dann an das Terminal T3 des dritten Nutzers wieder die Kennungen der Datei und der Segmente, eine Download-ID und ein Voucher versandt. Im Schritt 146 wird vom Terminal T3 unter Übersendung des Vouchers eine Schlüsselanfrage an den Lizenzserver SL gesendet, woraufhin dieser im Schritt 147 den Schlüssel zurücksendet. Außerdem sendet das Terminal T3 im Schritt 148 unter Angabe des Tickets an den Systembetreiber SB bzw. die zentrale Indexierungseinrichtung SI eine Anfrage nach möglichen Upload-Terminals und erhält im Schritt 149 die Adressen des Terminals T2 des zweiten Nutzers und des Terminals T1 des ersten Nutzers.
  • In dem in 1 dargestellten Fall wird vorausgesetzt, dass es aufgrund der zur Verfügung stehenden Download- und Upload-Raten ausreicht, wenn der dritte Nutzer mit seinem Terminal T3 die Datei von zwei Upload-Terminals T1, T2 anderer Nutzer herunterlädt. In der Regel ist es jedoch so, dass erheblich mehr Upload-Terminals für einen Download einer Datei genutzt werden, beispielsweise zehn oder mehr Upload-Terminals für das Herunterladen einer Datei auf ein Download-Terminal. Zusätzlich kann mit der Übermittlung der Adressinformationen 149 auch die Adresse eines Seedpeers SP mitgesandt werden, beispielsweise für Fälle, in denen aus irgendwelchen Gründen ein Download von einem der anderen angegebenen Kandidaten-Upload-Terminals T1, T2 nicht möglich sein sollte.
  • In den Schritten 150, 151 sendet dann das Terminal T3 des dritten Nutzers an die Terminals T2, T1 des zweiten und des ersten Nutzers jeweils ein Anfragesignal, wobei wiederum die Download-ID zur Kontrolle angegeben wird. Daraufhin werden in den Schritten 152 bzw. 153 die angefragten Fragmente von den Terminals T2, T1 an das Terminal T3 des Download-Nutzers übersandt. Die Upload-Terminals T2, T1 senden dann in den Schritten 154, 155 wieder Leistungsdaten an den Systembetreiber SB, der daraufhin im Schritt 156 die Kontrolle durchführt und eine Vergütung für die Nutzer der Upload-Terminals T2, T1 berechnet. Anschließend werden in den Schritten 157, 158 entsprechende Vergütungsmitteilungen an die Terminals T2, T1 der betreffenden Nutzer versandt.
  • 3 gibt einen Überblick über die Architektur eines Ausführungsbeispiels eines erfindungsgemäßen Inhalteübertragungssystems.
  • Dabei wird angenommen, dass es sich bei dem verwendeten Netzwerk N um das Internet handelt. An das Netzwerk N sind in üblicher Weise verschiedenste Terminals T1, T2, T3, Tn verschiedener Nutzer des Systems angeschlossen. Bei diesen Terminals T1, T2, T3, Tn kann es sich um übliche PCs, Laptops oder dergleichen handeln, aber auch um andere zum Anschluss an ein entsprechendes Netzwerk N geeignete Geräte, die zum Herunterladen und/oder Verarbeiten von digitalen Inhalten dienen können, wie beispielsweise Set-Top-Boxen, MP3-Player, Mobilfunkgeräte und PDAs mit entsprechender Ausstattung etc. Erforderlich ist auf jeden Fall, dass die Terminals T1, T2, T3, Tn einen Datenspeicher DS1, DS2, DS3, DSn enthalten, auf welchem die heruntergeladenen Dateien und/oder Dateien für einen Upload hinterlegt sind. Weiterhin ist auf den Terminals T1, T2, T3, Tn zur Nutzung in dem erfindungsgemäßen Verfahren eine spezielle Software, im Folgenden „Client" genannt, installiert, welche hier jeweils als Funktionsblock C1, C2, C3, Cn dargestellt ist.
  • Die verschiedenen Komponenten eines solchen Clients C sind in 4 dargestellt. Grob schematisch ist hier auch wieder das Terminal T mit dem Datenspeicher D sowie einer Netzschnittstelle NI dargestellt, über die der Anschluss an das Internet N erfolgt. Darüber hinaus weist ein solches Terminal T selbstverständlich auch alle weiteren Komponenten auf, die derartige Terminals üblicherweise enthalten, wie z. B. bei einem normalen PC ein Motherboard, Prozessoren, Graphikkarten, Spannungsversorgung, Benutzerschnittstelle etc. All diese Komponenten sind der Übersichtlichkeit wegen hier nicht dargestellt. Sie sind dem Fachmann bekannt und brauchen daher hier nicht weiter erläutert zu werden.
  • Der hier in Form von Software auf dem Terminal implementierte Client C besteht aus mehreren Modulen.
  • Ein erstes Modul 1 ist eine Transaktionssteuereinheit 1, welche für die Koordinierung der Transaktionen beim Download und/oder Upload von Dateien nach dem erfindungsgemäßen Verfahren sorgt.
  • Weiterhin weist der Client C ein Content-Datenbank-Modul 2 auf, in dem Informationen über die zum Upload bereitstehenden Dateien hinterlegt sind. Vor der Aufnahme in diese Content-Datenbank wird jede Datei auf ihre Tauschbarkeit innerhalb des Inhalteübertragungssystems geprüft. Hierzu wird vom Client C zunächst nach der vorgegebenen Methode die Kennung der Datei, beispielsweise die Hashsumme, berechnet. Es wird dann beim Inhalteanbieter geklärt, ob dieser Hashwert bereits existiert. Wenn ja, werden zu dem bekannten Hashwert sämtliche Metadaten inklusive Informationen über die zugehörigen Tauschrechte an das lokale Content-Datenbank-Modul 2 des Clients C heruntergeladen. Für die Dateien, die vom Client C selber bereits innerhalb des Inhalteübertragungssystems nach Kauf beim gleichen Inhalteanbieter heruntergeladen wurden, kann dieser Test entfallen, da hier bereits sämtliche Tests durchgeführt wurden. Als zusätzliche Sicherheit wird aber grundsätzlich noch einmal vor einem Upload von Fragmenten an andere Nutzer das jeweilige Dateisegment, aus dem Fragmente übermittelt werden sollen, durch Vergleich mit der zugehörigen Hashsumme des Segments geprüft. Auf diese Weise wird vermieden, dass ggf. beschädigte Dateien übermittelt werden. Tritt ein Fehler auf, wird die betreffende Datei in der Content-Datenbank aus der Liste der zum Upload bereitstehenden Dateien entfernt.
  • Weiterer Bestandteil ist ein Browser 3, mit dem der Nutzer die Webseiten des Internetshops SR des Inhalteanbieters RS kontaktieren kann, damit der Benutzer im Internetshop SR Inhalte aussuchen und erwerben kann. Anstelle dieses zum Client C gehörigen Browsers 3 kann auch ein anderer auf dem Terminal T des Nutzers installierter, externer Browser genutzt werden. Even tuell benötigte Zusatzfunktionen können auch beim Installieren des Clients C, sofern dies vom Hersteller des externen Browsers zugelassen ist, in diesen externen Browser installiert werden. Der interne Browser des Clients C wird dann deaktiviert.
  • Ein weiterer Bestandteil des Clients C ist in dem dargestellten Ausführungsbeispiel eine Angebotinformationseinheit 4, im Folgenden auch „Clientshop" 4 genannt. Dieser Clientshop 4 ermöglicht es, dass der Nutzer auf seinem Terminal T selbst im Internet Inhalte über den Inhalteanbieter RS zur Verfügung stellt und beispielsweise Bewertungen oder Ähnliches über die auf seinem Terminal T zum Upload bereitstehenden Inhalte abgibt. Dieser Clientshop 4 kann von anderen Nutzern mit Hilfe deren Browser 3 unmittelbar besucht werden.
  • Weitere Bestandteile des Clients C sind eine Segmentrekonstruktionseinheit 5, in welcher die angeforderten Fragmente zu den einzelnen Segmenten wieder zusammengesetzt werden und in der die Segmente anschließend daraufhin geprüft werden, ob sie vollständig und richtig empfangen wurden.
  • Die Überprüfung erfolgt in der Weise, dass nach dem Herunterladen eines vollständigen Segments das heruntergeladene Segment mit der Segment-Hash-Summe, welche dem Download-Terminal ja bekannt ist, verglichen wird. Tritt ein Fehler auf, werden folgende Aktionen durchgeführt:
    Zunächst wird das Segment in ein Repositorium für fehlerhafte Segmente verschoben. Dort wird außerdem gespeichert, welches Upload-Terminal welche Daten zu dem Segment beigetragen hat. Anschließend wird das Segment noch einmal von einem vertrauenswürdigen zentralen Server, beispielsweise von einem Seedpeer SP, heruntergeladen. Es wird dann das vom Seedpeer SP heruntergeladene Segment mit der Segment-Hash-Summe verglichen. Passt auch dieses Segment nicht mit der Segment-Hash-Summe überein, so liegt der Fehler möglicherweise auf Seiten des Systembetreibers SB. Es erfolgen dann ein Abbruch des Downloads und eine automatische Meldung an eine Zentrale des Systembetreibers SB. Andernfalls erfolgt ein Vergleich des korrekten Segments mit dem korrupten Dateisegment. Auf Basis des Vergleichs können das oder die Upload-Terminals ermittelt werden, die die fehlerhaften Daten geliefert haben. Die fehlerhaft sendenden Upload-Terminals werden an die Zentrale des Systembetreibers gemeldet.
  • Die vollständig rekonstruierten und geprüften Segmente werden dann an eine Dateirekonstruktionseinrichtung 6 übermittelt, welche einen Gesamt-Check durchführt, indem ein Vergleich der Datei mit der Gesamt-Hash-Summe der Datei durchgeführt wird. Hier sollte an sich kein Fehler mehr auftreten, da ja mögliche Fehler bei der Prüfung der Segmente bereits hätten festgestellt werden müssen. Tritt trotzdem ein Fehler auf, wird die komplette heruntergeladene Datei gelöscht und eine Fehlermeldung an die Zentrale des Systembetreibers SB gesandt.
  • Alternativ können auch Teile der Funktionalität oder sogar die gesamte Funktionalität durch geeignete Hardware in den Terminals bereitgestellt werden. Der Client oder zumindest einige der o. g. Komponenten des Client sind dann in Form von Hardeware in einem Terminal installiert, welches z. B. speziell für das erfindungsgemäße Inhalteübertragungssystem konstruiert wurde.
  • Auf Seiten des Systembetreibers SB werden innerhalb des Inhalteübertragungssystems, wie in 3 dargestellt, verschiedenste Komponenten benötigt. Eine Komponente ist eine sogenannte Indexierungseinrichtung SI. Diese Indexierungseinrichtung SI weist einen Speicher DSI auf, in dem hinterlegt ist, welche Terminals T1, T2, T3, Tn, SP1, SP2 aktuell für einen Download bestimmter Inhalte zur Verfügung stehen. Außerdem besitzt diese Indexierungseinrichtung SI eine Auswahleinheit SU, um bestimmte dieser Terminals T1, T2, T3, Tn, SP1, SP2 als Kandidaten-Upload-Terminals aus den zur Verfügung stehenden Upload-Terminals auszuwählen, wenn eine Anfrage nach einem bestimmten Inhalt durch einen Nutzer erfolgt.
  • Weitere Bestandteile sind eine Transaktionskontrolleinrichtung TC mit einem zugehörigen Speicher DTC sowie eine Metadatenbank MD mit einem zugehörigen Speicher DSM. Die Funktionen dieser Komponenten TC, MD werden später noch erläutert.
  • Bestandteil des Systems ist außerdem ein Nutzerauthentifizierungsservice SUA, welcher dazu dient, den Nutzer bei einer Anmeldung beim System zu authentifizieren.
  • Zusätzlich wird ein Lizenzserver SL benötigt, welcher für die Verwaltung der Schlüssel zur Entschlüsselung der angebotenen Dateien zuständig ist, d. h. welcher das komplette Digital Rights Management übernimmt.
  • All diese Funktionseinheiten des Systembetreibers SB sind in der Regel auf verschiedenen am Internet N angeschlossenen Servern installiert. Grundsätzlich ist es aber auch möglich, sämtliche Funktionseinheiten in einem Server zu verwirklichen. Ebenso kann der Lizenzserver SL Teil dieses allgemeinen Servers sein, sofern der Systembetreiber SB selber das Digital Rights Management übernimmt. Der Inhalteanbieter RS ist in der Regel mit einem eigenen Server am Internet N angeschlossen und betreibt dort seinen Inhalteanbieter-Internetshop SR. Grundsätzlich ist es aber auch möglich, dass der Systembetreiber SB auf einem Server bzw. Serverbereich diese Aufgaben stellvertretend für den eigentlichen Inhalteanbieter RS übernimmt, wobei dies für die jeweiligen Nutzer nicht erkennbar ist.
  • In dem in 2 dargestellten Ausführungsbeispiel sind am Internet N außerdem noch zwei Basis-Speicherterminals (Seedpeers) SP1, SP2 angeschlossen, auf denen Inhalte zum Download durch die Nutzer zur Verfügung gestellt werden. Diese Seedpeers SP1, SP2 können dem Systembetreiber SB oder dem Inhalteanbieter RS zugeordnet sein. Grundsätzlich ist es auch möglich, dass auch diese Funktionen des Seedpeers in einem großen leis tungsfähigen Server des Systembetreibers SB integriert sind. Die Seed-Peer können aber auch von unabhängigen Dritten betrieben werden.
  • Wie die einzelnen Komponenten untereinander innerhalb eines Downloads zusammenarbeiten, wird beispielhaft anhand von 5 näher erläutert, wobei hier ein Fall dargestellt wird, bei dem ein Nutzer U mittels seines Terminals T2 einen bestimmten Inhalt von einem Terminal T1 eines anderen Nutzers, welcher bereits im Besitz dieses Inhalts ist, sowie einem Seedpeer SP herunterlädt.
  • 5 ist wegen ihrer Länge auf die Teil-Figuren 5a, 5b und 5c aufgeteilt. In 5 wird zunächst davon ausgegangen, dass sich der erste Nutzer zunächst bei dem System als möglicher Uploader zur Verfügung stellt. Hierzu wird im Schritt 501 vom Terminal T1 dieses Upload-Nutzers ein Login-Signal an die Indexierungseinrichtung SI des Systembetreibers SB gesandt. Dies erfolgt durch Übermittlung einer eindeutigen User-ID, die grundsätzlich jedem Nutzer bei der erstmaligen Registrierung beim System zugewiesen wird und die jeweils eindeutig für einen bestimmten Nutzer innerhalb des gesamten Systems ist.
  • Das erfolgreiche Login wird dann im Schritt 502 von der zentralen Indexierungseinrichtung SI quittiert. Anschließend sendet das potentielle Upload-Terminal T1 im Schritt 503 Informationen über die zum Upload zur Verfügung stehenden Dateien, wiederum unter Angabe der eindeutigen Nutzer-ID und unter Angabe der eindeutigen Kennungen der einzelnen Dateien, beispielsweise der Hashwerte.
  • Bei der Anmeldung eines zweiten Nutzers U, welcher einen Inhalt herunterladen möchte, gibt dieser zunächst über die Benutzerschnittstelle an seinem Terminal T2 in Schritt 504 Start- und Login-Befehle ein. Das Terminal T2 sendet daraufhin im Schritt 505 eine Konfigurationsanfrage an den Server bzw. den dort installierten Internetshop SR des Inhalteanbieter RS, welcher daraufhin im Schritt 506 eine Konfigurationsantwort sendet, mit der der Client C im Terminal T2 für die folgende Sitzung passend konfiguriert wird.
  • Anschließend wird vom Terminal T2 im Schritt 507 automatisch eine Login-Anfrage mit einem Benutzernamen und einem Password gesandt, welches den Nutzer U gegenüber dem Inhalteanbieter RS ausweist. Diese Anfrage geht an einen Nutzerauthentifizierungsservice SUA, der hier im Besitz und unter Kontrolle des Systembetreibers SB ist. Dieser Nutzerauthentifikationsservice SUA enthält eine Instanz, welche wiederum unter Kontrolle des Inhalteanbieters RS ist. Dort wird auf Basis des übersandten Usernamens und Password ein „Ticket" erzeugt, mit dem sich der Nutzer U bzw. dessen Terminal T2 im nachfolgenden Verlauf des Verfahrens gegenüber den weiteren Funktionseinheiten authentifiziert. Diese Instanz des Nutzerauthentifizierungsservice SUA ist so aufgebaut, dass der Systembetreiber SB keinen Zugriff auf den Usernamen und das Password des Nutzers U hat, sondern dass der Nutzername und das Password ein gemeinsames Geheimnis des Nutzers U und des Inhalteanbieters RS bleiben. Das Ticket ist für die komplette Sitzung gültig.
  • Danach wird das Terminal T2 (optional) in den Schritten 509 bis 511 auch als potenzielles Upload-Terminal bei der zentralen Indexierungseinrichtung SI angemeldet. Die Vorgehensweise ist identisch zu dem oben in den Schritten 501 bis 503 beschriebenen Verfahren, bei dem sich das Terminal T1 als potentieller Uploader zur Verfügung stellt Das heißt, es wird auch hier ein Login beim zentralen Indexierungsdienst SI durchgeführt (Schritt 509) und nach Erhalt einer Login-Bestätigung (Schritt 510) ein Angebotssignal an den zentralen Indexierungsdienst SI gesandt (Schritt 511).
  • Mit Hilfe des von dem Nutzerauthentifizierungsservice SUA erhaltenen Tickets authentifiziert sich das Terminal T2 dann im Schritt 512 noch einmal gegenüber dem Internetshop SR (im Folgenden auch „Resellershop" genannt) des Inhalteanbieters RS. Das Ticket wird in den Schritten 513, 514 vom Inhalteanbieter RS durch Übersendung an den Nutzerauthentifizierungsserver SUA und entsprechende Rückmeldung von dort überprüft.
  • Anschließend kann der Nutzer im Schritt 515 im Resellershop SR nach einem Angebot suchen und weist hierzu sein Terminal T2 dementsprechend an, welches im Schritt 516 entsprechende Signale an den Resellershop SR übermittelt. Zu den jeweiligen Inhalten, für die sich der Nutzer interessiert, können in den Schritten 517, 518 Metadaten von einer Metadatenbank MD des Systembetreibers SB abgefragt werden. Bei den Metadaten handelt es sich um Zusatzinformationen zu einem Inhalt, wie z. B. Interpreten, Komponisten, Aufnahmejahr, Darsteller, aber auch Lizenzbedingungen, Preise etc. Diese Daten sind in einem der Datenbank MD zugeordneten Speicher DSM hinterlegt (siehe 3). Diese Daten werden dann im Schritt 519 in Form eines Angebots an das Terminal T2 des Nutzers U weitergeleitet und im Schritt 520 an den Nutzer U ausgegeben. Die Schritte 515 bis 520 sollen hierbei ein übliches Browsen innerhalb des Internetshops des Inhalteanbieters darstellen, d. h. der Nutzer kann beliebig oft verschiedene Suchanfragen starten, Inhalte betrachten und erhält hierzu die Angebots- und sonstigen Metadaten.
  • Bei diesem Ausführungsbeispiel wird davon ausgegangen, dass sämtliche Metadaten, die zu einem bestimmten Inhalt zur Verfügung stehen, in der zentralen Metadatenbank MD bzw. deren Speicher DSM des Systembetreibers SB hinterlegt sind. Selbstverständlich ist es auch möglich, dass der Inhalteanbieter RS selber eine solche Metadatenbank im Resellershop SR betreibt. In diesem Fall sind die Schritte 517, 518 nicht erforderlich.
  • Im Schritt 521 entscheidet sich der Nutzer U für einen bestimmten Inhalt, woraufhin das Terminal T2 im Schritt 522 ein entsprechendes Signal an den Resellershop SR versendet. Im Resellershop SR wird der ausgewählte Inhalt dann im Schritt 523 einem Warenkorb zugewiesen. Der Nutzer U kann danach weiterhin innerhalb des Internetshop des Inhalteanbieters RS browsen und weitere Inhalte auswählen. Es werden dementsprechend die Schritte 515 bis 523 beliebig oft wiederholt. Ebenso ist es auch möglich, bereits ausgewählte Inhalte wieder aus dem Warenkorb zu löschen.
  • Wenn der Nutzer U alle gewünschten Inhalte ausgewählt hat, kann er sich im Schritt 524 zum Kauf des Warenkorbs entschließen. Er gibt dies entsprechend an seinem Terminal T2 ein, welches daraufhin in Schritt 525 ein Kaufsignal an den Resellershop SR übersendet. Der Resellershop SR veranlasst dann im Schritt 526 mit Hilfe des vom Nutzer bzw. dessen Terminal T2 übermittelten Tickets die Erstellung eines Vouchers und einer Download-ID sowie aller weiteren Daten, die der Benutzer benötigt, um die Inhalte im System herunterzuladen und anschließend zu nutzen. Der genaue Ablauf ist dabei so, dass zunächst im Schritt 526 der Resellershop SR eine Kaufanfrage mit dem Ticket des Nutzers U und den Informationen über den Warenkorb an einen Kauftransaktionsservice TS sendet, welcher Bestandteil der Transaktionskontrolleinrichtung TC des Systembetreibers SB ist. Dieser Kauftransaktionsservice TS sendet zunächst das Ticket zur Überprüfung an den Nutzerauthentifizierungsservice SUA. Nach Erhalt der Antwort in Schritt 528 sendet der Kauftransaktionsservice TS dann im Schritt 529 eine Anfrage an den Lizenzserver SL zur Erstellung eines Vouchers. Nachdem der Voucher im Schritt 530 an den Kauftransaktionsservice TS zurückgesendet wurde, übermittelt der Kauftransaktionsservice TS eine entsprechende Kaufantwort, welche den Voucher sowie die zum Download benötigten Download-IDs und die Kennungen der herunterzuladenden Dateien bzw. der einzelnen Segmente der Dateien sowie ggf. weitere Signaturen zur Überprüfung der Transaktion an den verschiedenen Instanzen enthält, an den Resellershop SR. Dieser leitet die Antwort dann im Schritt 532 an das Terminal T2 des Nutzers U weiter.
  • Das Terminal T2 sendet danach im Schritt 533 automatisch unter Angabe des Vouchers eine Anforderung an den Lizenzserver SL, einen Lizenzschlüssel zu übermitteln. Im Schritt 534 erzeugt der Lizenzserver SL dann einen Schlüssel entsprechend der vom Nutzer gekauften Lizenz und sendet diesen im Schritt 535 an das Terminal T2 des Nutzers U.
  • Im Schritt 536 fordert das Terminal T2 dann vom zentralen Indexierungsdienst die Liste der möglichen Uploader unter Angabe der Kennung der Datei an. Die zentrale Indexierungseinrichtung SI erstellt dann im Schritt 537 diese Liste der Kandidaten-Upload-Terminals. Dabei können konfigurierbare Parameter über die Auswahl der Uploader berücksichtigt werden. Hierzu erhält jeder potenzielle Uploader beim Login eine Upload-Priorität zugewiesen. Diese Priorität wird nach den Vorgaben durch den Inhalteanbieter RS errechnet.
  • Das Ergebnis dieser Auswahl wird dann im Schritt 538 an das Terminal T2 übermittelt, wobei die Prioritäten der Kandidaten-Upload-Terminals mit übermittelt werden. Anhand dieser Prioritäten werden dann vom Terminal T2 die jeweiligen Kandidaten-Upload-Terminals ausgewählt. Das heißt, das Terminal T2 sendet zunächst an das Kandidaten-Upload-Terminal mit der höchsten Priorität ein Anforderungssignal, um den Download des ersten Fragments anzufordern. Bei dem Terminal mit der zweithöchsten Priorität wird dann das zweite Fragment angefordert, bis insgesamt die maximale Verbindungsanzahl erreicht ist. Anschließend werden die weiteren Fragmente wieder der Reihe nach bei den bereits genutzten Upload-Terminals abgefragt. Existieren mehrere Kandidaten-Upload-Terminals mit gleicher Priorität, so wählt das Download-Terminal unter diesen nach dem Zufallsprinzip aus.
  • In dem in 5 dargestellten, vereinfachten Ausführungsbeispiel fordert das Terminal T2 des Nutzers U nur Fragmente vom Terminal T1 eines Upload-Users und von einem zentralen Seedpeer SP an.
  • Hierzu erfolgt zunächst im Schritt 539 eine Download-Anfrage an das Upload-Terminal T1, wobei die Kennung der gewünschten Datei und die Download-ID übermittelt werden, die das Terminal T2 beim Kauf erhalten hat. Im Schritt 540 führt das Upload-Terminal T1 zuerst eine Verifikation anhand der Download-ID durch und prüft außerdem, ob die Datei wirklich auf dem betreffenden Terminal T1 bereitsteht. In Schritt 541 wird dann eine Antwort an das anfragende Terminal T2 gesandt. Daraufhin sendet dieses Terminal im Schritt 542 eine konkrete Fragmentanfrage an das Upload-Terminal T1 und übergibt hierbei die Kennung eines Segments P0, P1, P2, P3, P4 der Datei D und einen Offsetwert OF und die Länge IF für das jeweils gewünschte Fragment F.
  • Zur Erläuterung dieser Werte wird noch einmal auf 2 und die obige Beschreibung hierzu verwiesen. Der Offsetwert OF gibt hier genau den Startpunkt eines Fragments F innerhalb eines Segments P1 der Datei D an. Die Länge IF des Fragments wird ebenfalls angegeben, so dass durch die eindeutige Kennung des Segments P1 die Offsetlänge OF und die Länge IF des Fragments eindeutig bestimmt ist. Die Länge des Fragments und den Offsetwert OF kann dabei das Terminal T2 bzw. die Transaktionssteuereinheit 1 des im Terminal T2 installierten Clients C (vergleiche 3) selbständig festlegen, je nachdem, welches Fragment F es gerade benötigt.
  • Im Schritt 543 wird schließlich das angefragte Fragment F vom Upload-Terminal T1 an das Download-Terminal T2 des Nutzers U übermittelt. Anschließend sendet das Upload-Terminal T1 im Schritt 544 einen Report an einen Transaktionsreportempfänger TR, welcher ebenfalls Bestandteil der Transaktionskontrolleinrichtung TC ist.
  • Um eine sichere und schnelle Übertragung zu gewährleisten, können bestimmte Zeitspannen gesetzt werden, in denen bei einer solchen Peer-to-Peer-Datenübermittlung die Daten übergeben werden sollten. Andernfalls wird der Versuch abgebrochen und es werden Daten von anderen Terminals angefordert. Beispielsweise kann, falls über eine Verbindung in einem bestimmten Zeitraum, z. B. in den letzten 5 Sekunden, keinerlei Daten übertragen wurden und in dem Zeitraum auch keine Verbindung zu einem Terminal aufgebaut wurde und wenn innerhalb eines weiteren bestimmten Zeitraums keine Verbindung zu einem Seedpeer des Systembetreibers bzw. Inhalteanbieters aufgebaut wurde, eine entsprechende Verbindung zu einem solchen Seedpeer aufgebaut werden, um die Datei von dort zu erhalten. Das Gleiche kann erfolgen, wenn bereits Verbindungen zu bestimmten anderen Terminals von Download-Nutzern existieren, über die aber in einem bestimmten Zeitraum, z. B. mehr als 30 Sekunden, keine Daten mehr übertragen wurden. Diese Verbindungen können dann abgebrochen werden und die Upload-Terminals können als „schlecht" markiert und die Restfragmente neu angefordert werden.
  • Ebenso kann auch, wenn eine Vielzahl weiterer Upload-Terminals zur Verfügung stehen, die jeweils langsamste Verbindung unterbrochen, das betreffende Upload-Terminal als langsam markiert und eine neue Verbindung mit einem wartenden Upload-Terminal aufgebaut werden, um den Download zu beschleunigen.
  • In den Schritten 545 bis 548 wird ein Download von Fragmenten von einem Seedpeer SP dargestellt. Da hier sicher ist, dass das Terminal SP die gewünschten Dateien enthält, kann gleichzeitig mit der Download-Anfrage im Schritt 545 auch angegeben werden, welche Fragmente das Terminal T2 erhalten möchte. Es können dann nach der Verifikation im Schritt 546 gleich die angeforderten Fragmente im nachfolgenden Schritt 547 an das Terminal T2 heruntergeladen werden. Schließlich wird auch hier im Schritt 548 ein Report an den Transaktionsreportempfänger TR übermittelt.
  • Jede Anfrage des Download-Terminals T2 an ein Upload-Terminal T1, SP kann in Form eines Anfrageblocks gleich eine Vielzahl von Fragmenten anfordern. Dieser Anfragesignalblock wird dann vom Upload-Terminal T1, SP sukzessive abgearbeitet. Dieses Verfahren reduziert den Overhead an Steuerdaten bei einem Download erheblich. Da die Möglichkeit besteht, im Rahmen eines Warenkorbs mehrere Inhalte bzw. Dateien zu kaufen, ist es bei einer bevorzugten Variante des Verfahrens auch möglich, dass bei einem Upload-Terminal gleichzeitig – beispielsweise auch innerhalb eines Anfragesignalblocks – Fragmente unterschiedlicher Dateien anzufordern, um den Download des gesamten Warenkorbs zu optimieren.
  • Es ist klar, dass das Terminal T2 auch mehrere Anfragen nacheinander bei den einzelnen Uploadern, d. h. beim Upload-Terminal T1 und beim Basis-Speicherterminal SP, anfordern kann, um so alle Fragmente der Datei zu erhalten. In diesem Fall werden die Schritte 542 und 543 bzw. die Schritte 545 und 547 beliebig oft wiederholt. Dabei kann es unter bestimmten Umständen zur Verringerung des Datenoverheads auch sinnvoll sein, wenn erst nach Beendigung des kompletten Uploads die Upload-Reports 544 bzw. 548 versandt werden.
  • Nachdem das Terminal T2 sämtliche Fragmente der Datei erhalten hat, sendet es im Schritt 549 einen Download-Report an den Transaktionsreportempfänger TR. Durch Vergleich der von den verschiedenen Terminals erhaltenen Daten kann kontrolliert werden, ob die Transaktion erfolgreich abgeschlossen wurde. Außerdem kann die Vergütung für den Uploader berechnet werden, wie dies schon im Rahmen von 1 weiter oben erläutert wurde. Die Vergütung selbst kann dann zu einem späteren Zeitpunkt erfolgen.
  • Der Nutzer U kann sich anschließend in Schritt 550 durch einen entsprechenden Befehl an seinem Terminal T2 beim Resellershop ST abmelden. Dieser sendet daraufhin im Schritt 551 ein Logoff-Signal an die Indexierungseinrichtung SI, damit dort bekannt ist, dass das Terminal T2 nicht mehr für Uploads an andere Nutzer zur Verfügung steht, sowie im Schritt 552 ein weiteres Logoff-Signal an den Nutzerauthentifizierungsservice SUA, welcher daraufhin das Ticket entwertet.
  • Ein Problem bei einem solchen Peer-to-Peer-Netzwerk besteht darin, dass eine Vielzahl von Endbenutzerterminals durch Firewalls blockiert sind und daher nicht auf einfache Weise von außen eine bidirektionale, stehende Verbindung, beispielsweise eine TCP-Verbindung, aufgebaut werden kann. Eine solche Verbindung muss immer von innen, d. h. von dem durch die Firewall gesicherten Terminal, aufgeschlossen werden. Um dieses Problem zu lösen, wird vorzugsweise bei dem erfindungsgemäßen Verfahren in einem solchen Fall, wenn auf einem der beiden Terminals, zwischen denen eine Übertragung stattfindet, eine Firewall installiert ist, die Verbindung zwischen den beiden Terminals mit Hilfe eines dritten Terminals aufgebaut, auf dem keine Firewall installiert ist.
  • In 6 ist schematisch ein möglicher Ablauf einer Anmeldung eines durch eine Firewall gesicherten Terminals TL (im Folgenden auch „Leaf" TL genannt) als potentielles Upload-Terminal bei der zentralen Indexierungseinrichtung SI dargestellt. Wenn der Nutzer U' sein Terminal TL durch einen entsprechenden Befehl im Schritt 601 zu einem Login veranlasst, sendet das Terminal TL zunächst im Schritt 602 ein Login-Signal an die zentrale Indexierungseinrichtung SI. Diese sendet dann im Schritt 603 ein Firewall-Testsignal zurück. Gleichzeitig wird in einer Zeitschleife 604 kontrolliert, ob ein entsprechendes Signal zurückkommt. Ist dies nicht der Fall, so wird davon ausgegangen, dass das Terminal TL durch eine Firewall gesichert ist, d.h. ein „Leaf" ist. Im Schritt 605 sendet die zentrale Indexierungseinrichtung dann ein Login-Antwortsignal zurück, mit dem an das zum Upload bereite Terminal TL eine Adresse eines für das betreffende Terminal TL zuständigen, nicht durch eine Firewall gesicherten weiteren Terminals TH (im Folgenden auch „Hub" TH genannt) übermittelt wird. Es wird dann im Schritt 606 eine TCP-Verbindung zwischen dem Leaf TL und dem zuständigen Hub TH aufgebaut. Der Hub TH sendet dann im Schritt 607 eine Statusnachricht an die zentrale Indexierungseinrichtung SI und eine Bestätigung an den Leaf TL. Anschließend sendet der Leaf TL im Schritt 609 ein Angebotssignal mit seiner Nutzer-ID und den zum Upload zur Verfügung stehenden Dateien an die zentrale Indexierungseinrichtung SI. Die weitere Verbindung kann dann immer über den zuständigen Hub TH erfolgen.
  • 7 stellt als ein weiteres Beispiel den Fall dar, dass von einem solchen durch eine Firewall gesicherten Upload-Leaf TL ein Fragment auf ein Download-Terminal TD heruntergeladen werden soll.
  • Da in der zentralen Indexierungseinrichtung SI bekannt ist, dass der Upload-Leaf TF über eine Firewall gesichert ist und nur über einen zugehörigen Hub TH ansprechbar ist, wird mit den Adressdaten an das Download-Terminal TD gleichzeitig die Adresse dieses zugehörigen Hub TH übermittelt. Das Download-Terminal TD kann dann im Schritt 701 zunächst ein „Push Request Signal" an das Hub-Terminal TH senden, welches ein entsprechendes Signal über die zuvor eingerichtete Verbindung im Schritt 702 an den Upload-Leaf TL sendet. Dieser kann daraufhin dann in Schritt 703 die Verbindung zum Download-Terminal TD öffnen, so dass im Schritt 704 das Download-Terminal TD in üblicher Weise ein Anfragesignal zum Download eines Fragments F an den Upload-Leaf TL senden kann und daraufhin im Schritt 705 das gewünschte Fragment erhält.
  • Auf diese Weise ist es ohne weiteres möglich, nicht nur zwischen zwei nicht Firewall-gesicherten Terminals Daten auszutauschen, sondern auch von einem durch Firewall gesicherten Terminal Dateien an ein ungesichertes Terminal herunterzuladen. Es muss lediglich dafür gesorgt werden, dass einem Leaf immer ein Hub zugeordnet ist. Sollte ein Hub ausfallen, kann durch entsprechende Aktionen der zentralen Indexierungseinrichtung SI dem Leaf jederzeit ein neuer freier Hub zugewiesen werden, wobei der Ausfall des Hubs entweder durch den Leaf selber oder auch durch ein anderes Terminal, welches den Leaf ansprechen möchte, festgestellt werden kann und eine entsprechende Nachricht an die zentrale Indexierungseinrichtung SI gesendet werden kann. Ebenso kann auch die zentrale Indexierungseinrichtung selber den Ausfall eines Hubs feststellen, beispielsweise, indem ein solcher Hub regelmäßig Statusnachrichten an die zentrale Indexierungseinrichtung SI aussendet und das Ausbleiben einer solchen Nachricht von der zentralen Indexierungseinrichtung bemerkt wird. In ähnlicher Weise kann auch beim Ausfall eines Leafs durch den zugehörigen Hub ein Signal an die zentrale Indexierungseinrichtung SI übermittelt werden.
  • Selbstverständlich ist es auch möglich, mit einem Firewall-gesicherten Terminal Dateien von einem ungesicherten Terminal herunterzuladen, da die Initiative hier ja ohnehin von dem anfragenden Terminal, in diesem Fall also von dem durch die Firewall gesicherten Download-Terminal, gestartet wird.
  • Lediglich eine Verbindung zwischen zwei durch eine Firewall gesicherten Terminals ist mit diesem Verfahren nicht möglich.
  • Es wird abschließend noch einmal darauf hingewiesen, dass die vorbeschriebenen Ausführungsformen der Erfindung besonders bevorzugte beispielhafte Ausgestaltungen darstellen. Eine Vielzahl von Ausführungsformen des erfindungsgemäßen Verfahrens und der erfindungsgemäßen Vorrichtung sind vom Gedanken der Erfindung mit erfasst, auch wenn sie in den vorstehenden Ausführungen nicht ausführlich beschrieben wurden. Insbesondere sind auch verschiedenste Kombinationen der beschriebenen Varianten möglich. Es wird außerdem der Vollständigkeit halber darauf hingewiesen, dass, sofern nicht explizit anders erwähnt, die Verwendung der unbestimmten Artikel „ein" bzw. „eine" nicht ausschließt, dass die betreffenden Merkmale auch mehrfach vorhanden sein können, und das die Begriffe „Einrichtung", „Einheit" oder „Modul" nicht zwingend bedeuten, dass die betreffenden Komponenten nicht auch aus mehreren räumlich getrennten, zusammenwirkenden Teilen bestehen können.

Claims (32)

  1. Verfahren zur Übertragung von digitalen Inhalten eines Inhalteanbieters (RS) an die Nutzer eines Inhalteübertragungssystems in einem Computer-Kommunikationsnetzwerk (N), bei dem eine Datei (D), welche einen bestimmten von einem Download-Nutzer (U) gewünschten digitalen Inhalt enthält, zumindest teilweise von einem Terminal (T1, T2) eines Upload-Nutzers aus über das Computer-Kommunikationsnetzwerk (N) an ein Terminal (T2, T3) des Download-Nutzers (U) übertragen wird, dadurch gekennzeichnet, dass von Terminals (T1, T2) verschiedener Upload-Nutzer aus Fragmente (F) der Datei (D) an das Terminal (T2, T3) des Download-Nutzers (U) übertragen werden.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass zumindest ein Teil der Fragmente (F) der Datei (D) von einem Basis-Speicherterminal (SP, SP1, SP2) aus an das Terminal des Download-Nutzers (U) übertragen werden, sofern kein oder zu wenige Terminals (T, T1, T2, T3, Tn) von Upload-Nutzern zur Verfügung stehen, auf denen zumindest passende Teile der Datei (D) zu einer Übertragung bereit stehen.
  3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass vom Terminal (T2, T3) des Download-Nutzers (U) aus an mögliche Upload-Terminals (T1, T2, SP), auf denen zumindest Teile der Datei (D) jeweils zu einem Upload bereit stehen, Anforderungssignale zur Anforderung bestimmter Fragmente (F) der gewünschten Datei (D) gesendet werden.
  4. Verfahren zur Übertragung von digitalen Inhalten eines Inhalteanbieters (RS) an die Nutzer eines Inhalteübertragungssystems in einem Compu ter-Kommunikationsnetzwerk (N), insbesondere nach einem der Ansprüche 1 bis 3, bei dem Fragmente (F) einer Datei (D), welche einen bestimmten von einem Download-Nutzer (U) gewünschten digitalen Inhalt enthält, von einem Upload-Terminal (T1, T2) aus über das Computer-Kommunikationsnetzwerk (N) an ein Terminal (T2, T3) des Download-Nutzers (U) übertragen wird, dadurch gekennzeichnet, dass das Terminal (T2, T3) des Download-Nutzers (U) an ein mögliches Upload-Terminal (T1, T2, SP) einen Anforderungssignalblock sendet, mit dem gleichzeitig mehrere Fragmente (F) der gewünschten Datei (D) angefordert werden.
  5. Verfahren nach Anspruch 3 oder 4, dadurch gekennzeichnet, dass vom Terminal (T2, T3) des Download-Nutzers (U) an eine zentrale Indexierungseinrichtung (SI) eine Anfrage nach einem bestimmten Inhalt gesandt wird, dass von der zentralen Indexierungseinrichtung (SI) eine Gruppe von Kandidaten-Upload-Terminals (T1, T2, SP) ermittelt wird, auf denen zumindest Teile der Datei (D) jeweils zu einem Upload bereit stehen, dass von der zentralen Indexierungseinrichtung (SI) an das Terminal (T2, T3) des Download-Nutzers (U) Adressinformationen betreffend die Kandidaten-Upload-Terminals (T1, T2, SP) übermittelt werden, und dass vom Terminal (T2, T3) des Download-Nutzers (U) aus zumindest an einen Teil der Kandidaten-Upload-Terminals (T1, T2, SP) Anforderungssignale zur Anforderung bestimmter Fragmente (F) der gewünschten Datei (D) gesendet werden.
  6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die zentrale Indexierungseinrichtung (SI) von einem Terminal (T) eines Nutzers des Inhalteübertragungssystems, wenn auf diesem Terminal (T) Dateien zu einem Upload an andere Nutzer des Inhalteübertragungssystem bereit stehen, ein Angebotssignal empfängt, welches Informationen über die zur Verfügung stehenden Dateien enthält.
  7. Verfahren nach einem der Ansprüche 3 bis 6, dadurch gekennzeichnet, dass eine Auswahl der Upload-Terminals (T1, T2, SP), an welche vom Terminal (T2, T3) des Download-Nutzers (U) aus ein Anforderungssignal zur Übermittlung eines Fragments (F) ausgesandt wird, in Abhängigkeit von den einzelnen Upload-Terminals (T1, T2, SP) zugeordneten Prioritätswerten erfolgt.
  8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass die Datei (D) in eine Anzahl von definierten Segmenten (P0, P1, P2, P3, P4) zerlegt wird und jedem Segment (P0, P1, P2, P3, P4) eine eindeutige Kennung zugeordnet wird.
  9. Verfahren zur Übertragung von digitalen Inhalten eines Inhalteanbieters (RS) an die Nutzer eines Inhalteübertragungssystems in einem Computer-Kommunikationsnetzwerk (N), insbesondere nach einem der Ansprüche 1 bis 8, bei dem ein Fragment (F) einer Datei (D), welche einen bestimmten von einem Download-Nutzer (U) gewünschten digitalen Inhalt enthält, von einem Upload-Terminal (T1, T2) aus über das Computer-Kommunikationsnetzwerk (N) an ein Terminal (T2, T3) des Download-Nutzers (U) übertragen wird, dadurch gekennzeichnet, dass vom Terminal (T2, T3) des Download-Nutzers (U) aus, wenn von einem ersten Upload-Terminal (T1, T2) ein zu übersendendes Fragment (F) nicht vollständig oder fehlerhaft empfangen wird, ein Anforderungssignal an ein anderes mögliches Upload-Terminal (T1, T2, SP) gesandt wird, mit dem ein Fragment (FR) angefordert wird, welches dem fehlerhaften oder fehlenden Teil des vom ersten Upload-Terminal (T1, T2) zu übersendenden Fragments (F) entspricht.
  10. Verfahren nach einem der Ansprüche 3 bis 9, dadurch gekennzeichnet, dass ein Anforderungssignal des Terminals (T2, T3) des Download-Nutzers (U) an ein Upload-Terminal (T1, T2, SP) die eindeutige Ken nung der Datei (D) und/oder des Segments (P0, P1, P2, P3, P4) der Datei, zu dem ein angefordertes Fragment (F, FR) gehört, einen Offsetwert (OF, OFR), welcher die Position des Fragments (F, FR) innerhalb der Datei (D) oder des Segments (P0, P1, P2, P3, P4) der Datei (D) repräsentiert, und die Länge (IF, IFR) des Fragments (F, FR) enthält.
  11. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass ein Nutzer (U) sich zunächst innerhalb eines Authentifizierungsverfahrens (102, 122, 142, 507, 508) gegenüber einer Authentifizierungseinheit (SUA) authentifiziert und dem Nutzer (U) nach erfolgreicher Authentifizierung eine Authentifizierungskennung zugesandt wird und sich der Nutzer (U) dann im weiteren Verlauf des Verfahrens gegenüber anderen Funktionseinheiten des Inhalteübertragungssystems durch Übersendung der Authentifizierungskennung authentifiziert.
  12. Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass die Datei (D) mit dem gewünschten Inhalt in verschlüsselter Form an das Terminal (T1, T2, T3) des Download-Nutzers (U) übertragen wird und dem Download-Nutzer (U) vor der Übertragung von Fragmenten (F) der Datei (D) ein Schlüssel zur Entschlüsselung der Datei (D) übermittelt wird.
  13. Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass an den Download-Nutzer (U) nach einer Auswahl eines vom Inhalteanbieter (RS) angebotenen digitalen Inhalts eine Dateiempfangsberechtigungskennung und eine Schlüsselempfangsberechtigungskennung zugesandt werden, und dass vom Download-Nutzer (U) die Dateiempfangsberechtigungskennung an die jeweiligen Upload-Terminals (T1, T2, SP) zum Erhalt von Fragmenten (F) der gewünschten Datei (D) und die Schlüsselempfangsberechtigungskennung an eine Lizenzerteilungseinrichtung (SL) zum Erhalt des Schlüssels weitergeleitet werden.
  14. Verfahren nach einem der Ansprüche 1 bis 13, dadurch gekennzeichnet, dass nach einer Übermittlung von Fragmenten (F) einer Datei (D) von einem Terminal (T1, T2) eines Upload-Nutzers an ein Terminal (T2, T3) eines Download-Nutzers (U) leistungsrelevante Daten vom Terminal (T1, T2) des Upload-Nutzers und/oder vom Terminal (T2, T3) des Download-Nutzers (U) an eine Transaktionskontrolleinrichtung (TC) gesandt werden und durch den Inhalteanbieter (RS) und/oder durch einen Betreiber (SB) des Inhalteübertragungssystems eine Vergütung des Upload-Nutzers für die Zur-Verfügung-Stellung seines Terminals (T1, T2) zur Übermittlung der Daten an das Terminal (T2, T3) des Download-Nutzers (U) erfolgt.
  15. Verfahren nach einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, dass ein Inhalteanbieter (RS) und der Betreiber (SB) des Inhalteübertragungssystems getrennte Organisationseinheiten sind und jeder Datei (D) mit einem von einem bestimmten Inhalteanbieter (RS) angebotenen digitalen Inhalt und/oder jedem Segment (P0, P1, P2, P3, P4) einer solchen Datei (D) innerhalb des Inhalteübertragungssystems eine eindeutige Kennung zugeordnet ist, welche vom betreffenden Inhalteanbieter (RS) und vom Inhalt der Datei (D) oder des Segments (P0, P1, P2, P3, P4) abhängt.
  16. Verfahren nach einem der Ansprüche 1 bis 15, dadurch gekennzeichnet, dass eine Datei (D) mit einen digitalen Inhalt, der von einem Nutzer des Inhalteübertragungssystems auf seinem Terminal (T, T1, T2, T3, TN) zu einem Upload an andere Nutzer des Inhalteübertragungssystems bereit gestellt werden soll, zunächst durch eine Instanz des Inhalteanbieters (RS) und/oder durch eine Instanz eines Betreibers (SB) des Inhalteübertragungssystems überprüft und der Datei (D) bei positiver Überprüfung eine Kennung zugeordnet wird.
  17. Verfahren nach einem der Ansprüche 1 bis 16, dadurch gekennzeichnet, dass Informationen über die von einen bestimmten Nutzer auf sei nem Terminal (T) zu einem Upload an andere Nutzer des Inhalteübertragungssystems bereitgestellten Inhalte von einer Angebotsinformationseinheit (4) des Terminals (T) des betreffenden Nutzers aus auf ein Terminal eines anderen Nutzers abrufbar sind.
  18. Verfahren zum Herunterladen eines digitalen Inhalts eines Inhalteanbieters (RS) aus einem Computer-Kommunikationsnetzwerk (N) auf ein Terminal (T2, T3) eines Download-Nutzers (U) eines Inhalteübertragungssystems, bei dem das Terminal (T2, T3) des Download-Nutzers (U) eine Datei (D), welche einen bestimmten, von dem betreffenden Download-Nutzer (U) gewünschten digitalen Inhalt enthält, zumindest teilweise von einem Terminal (T1, T2) eines Upload-Nutzers des Inhalteübertragungssystems aus empfängt, dadurch gekennzeichnet, dass das Terminal (T2, T3) des Download-Nutzers (U) Fragmente (F) der Datei (D) von Terminals (T1, T2) verschiedener Upload-Nutzer aus empfängt.
  19. Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass das Terminal (T2, T3) des Download-Nutzers zumindest einen Teil der Fragmente (F) der Datei (D) von einem Basis-Speicherterminal (SP, SP1, SP2) empfängt, sofern kein oder zu wenige Terminals (T, T1, T2, T3, TN) von Upload-Nutzern zur Verfügung stehen, auf denen zumindest passende Teile der Datei (D) zu einer Übertragung bereit stehen.
  20. Verfahren nach Anspruch 18 oder 19, dadurch gekennzeichnet, dass das Terminal (T2, T3) des Download-Nutzers (U) an mögliche Upload-Terminals (T1, T2, SP), auf denen zumindest Teile der Datei (D) jeweils zu einem Upload bereit stehen, Anforderungssignale zur Anforderung bestimmter Fragmente (F) der gewünschten Datei (D) sendet.
  21. Verfahren zum Herunterladen eines digitalen Inhalts eines Inhalteanbieters (RS) aus einem Computer-Kommunikationsnetzwerk (N) auf ein Terminal (T2, T3) eines Download-Nutzers (U) eines Inhalteübertragungssystems, insbesondere nach einem der Ansprüche 18 bis 20, bei dem das Terminal (T2, T3) des Download-Nutzers (U) Fragmente (F) einer Datei (D), welche einen bestimmten, von dem betreffenden Download-Nutzer (U) gewünschten digitalen Inhalt enthält, von einem Upload-Terminal (T1, T2) aus empfängt, dadurch gekennzeichnet, dass das Terminal (T2, T3) des Download-Nutzers (U) an ein mögliches Upload-Terminal (T1, T2, SP) einen Anforderungssignalblock sendet, mit dem gleichzeitig mehrere Fragmente (F) der gewünschten Datei (D) angefordert werden.
  22. Verfahren nach Anspruch 20 oder 21, dadurch gekennzeichnet, dass das Terminal (T2, T3) des Download-Nutzers (U) eine Anfrage nach einem bestimmten Inhalt an eine zentrale Indexierungseinrichtung (SI) sendet, dass das Terminal (T2, T3) des Download-Nutzers (U) von der zentralen Indexierungseinrichtung (SI) Adressinformationen betreffend mögliche Kandidaten-Upload-Terminals (T1, T2, SP) empfängt, auf denen zumindest Teile der Datei (D) jeweils zu einem Upload bereitstehen, und dass das Terminal (T2, T3) des Download-Nutzers (U) zumindest an einen Teil der Kandidaten-Upload-Terminals Anforderungssignale zur Anforderung bestimmter Segmente der gewünschten Datei sendet.
  23. Verfahren nach einem der Ansprüche 20 bis 22, dadurch gekennzeichnet, dass eine Datei (D) aus einer Anzahl von definierten Segmenten (P0, P1, P2, P3, P4) besteht und jedem Segment (P0, P1, P2, P3, P4) eine eindeutige Kennung zugeordnet ist und die Anforderungssignale des Terminals (T2, T3) des Download-Nutzers (U) an mögliche Upload-Terminals (T1, T2, SP) die Kennung des Segments (P0, P1, P2, P3, P4) enthalten, zu welchem das angeforderte Fragment (F) gehört.
  24. Verfahren, zum Herunterladen eines digitalen Inhalts eines Inhalteanbieters (RS) aus einem Computer-Kommunikationsnetzwerk (N) auf ein Terminal (T2, T3) eines Download-Nutzers (U) eines Inhalteübertragungssystems, insbesondere nach einem der Ansprüche 18 bis 23, bei dem das Terminal (T2, T3) des Download-Nutzers (U) ein Fragment (F) einer Datei (D), welche einen bestimmten, von dem betreffenden Download-Nutzer (U) gewünschten digitalen Inhalt enthält, von einem Upload-Terminal (T1, T2) aus empfängt, dadurch gekennzeichnet, dass das Terminal (T2, T3) des Download-Nutzers (U), wenn von einem ersten Upload-Terminal (T1, T2) ein zu übersendendes Fragment (F) nicht vollständig oder fehlerhaft empfangen wird, ein Anforderungssignal an ein anderes Kandidaten-Upload-Terminal (T1, T2, SP) sendet, mit dem ein Fragment (FR) angefordert wird, welches dem fehlerhaften oder fehlenden Teil des vom ersten Upload-Terminal (T1, T2) zu übersendenden Fragments (F) entspricht.
  25. Verfahren nach einem der Ansprüche 20 bis 24, dadurch gekennzeichnet, dass ein Anforderungssignal des Terminals (T2, T3) des Download-Nutzers (U) an ein Upload-Terminal (T1, T2, SP) die eindeutige Kennung der Datei (D) und/oder des Segments (P0, P1, P2, P3, P4) der Datei (D), zu dem ein angefordertes Fragment (F, FR) gehört, einen Offsetwert (OF, OFR), welcher die Position des Fragments (F, FR) innerhalb der Datei (D) bzw. des Segments (P0, P1, P2, P3, P4) der Datei (D) repräsentiert, und die Länge (IF, IFR) des Fragments (F, FR) enthält.
  26. Verfahren nach einem der Ansprüche 18 bis 25, dadurch gekennzeichnet, dass die Datei (D) mit dem gewünschten Inhalt in verschlüsselter Form an das Terminal (T2, T3) des Download-Nutzers (U) übertragen wird und das Terminal (T2, T3) des Download-Nutzers (U) vor dem Empfang von Fragmenten (F) der Datei (D) einen Schlüssel empfängt und bereits empfangene Teile der Datei (D) vor einer Beendigung des vollständigen Datei-Downloads entschlüsselt.
  27. Computerprogrammprodukt, welches direkt in einen Speicher eines programmierbaren Terminals ladbar ist, mit Programmcode-Mitteln, um alle Schritte eines Verfahrens nach einem der Ansprüche 18 bis 26 auszuführen, wenn das Programmprodukt auf dem Terminal ausgeführt wird.
  28. Inhalteübertragungssystem zur Übertragung digitaler Inhalte eines Inhalteanbieters (RS) auf ein Terminal (T2, T3) eines Download-Nutzers (U) des Inhalteübertragungssystems in einem Computer-Kommunikationsnetzwerk (N), mit einer Transferinitialisierungseinrichtung, welche nach Empfang einer Anfrage eines Download-Nutzers (U) nach einem bestimmten Inhalt das Terminal (T2, T3) des Download-Nutzers (U) dazu veranlasst, Fragmente (F) der Datei (D) mit dem gewünschten Inhalt von verschiedenen ausgewählten Kandidaten-Upload-Terminals (T1, T2, SP) zu empfangen.
  29. Inhalteübertragungssystem nach Anspruch 28, gekennzeichnet durch ein Basis-Speicherterminal (SP, SP1, SP2) zur Übertragung einer Datei (D) mit dem betreffenden digitalen Inhalt an ein Terminal (T1, T2) eines Download-Nutzers (U), sofern kein oder zu wenige Terminals von Upload-Nutzer zur Verfügung stehen, auf denen zumindest passende Teile der Datei (D) zu einer Übertragung bereit stehen.
  30. Inhalteübertragungssystem nach Anspruch 28 oder 29, dadurch gekennzeichnet, dass die Transferinitialisierungseinrichtung eine zentrale Indexierungseinrichtung (SI) umfasst, mit – einer Speichereinrichtung (DSI), welche Informationen enthält, auf welchen Terminals (T, T1, T2, T3, TN) verschiedener Nutzer des Inhalteübertragungssystems und/oder auf welchen Basis-Speicherterminals (SP, SP1, SP2) welche Inhalte zu einer Übertragung an Nutzer über das Computer-Kommunikationsnetzwerk (N) bereitgestellt sind, – und einer Auswahleinheit (SU), um nach Empfang einer Anfrage eines Download-Nutzers (U) nach einem bestimmten Inhalt aus den Terminals (T, T1, T2, T3, Tn, SP, SP1, SP2), auf denen zumindest Teile der Datei (D) jeweils zu einem Upload bereit stehen, eine Gruppe von Kandidaten-Upload-Terminals (T1, T2, SP) zu ermitteln.
  31. Inhalteübertragungssystem nach einem der Ansprüche 28 bis 30, gekennzeichnet durch eine Transaktionskontrolleinrichtung (TC), welche nach einer Übermittlung von Fragmenten der Datei von Upload-Terminals (T1, T2) an das Terminal (T2, T3) des Download-Nutzers (U) leistungsrelevante Daten von den Upload-Terminals und/oder vom Terminal (T2, T3) des Download-Nutzers (U) empfängt, um eine Vergütung der Upload-Nutzer für die Zur-Verfügung-Stellung der jeweiligen Upload-Terminals (T1, T2) zur Übermittlung der Daten an das Terminal (T2, T3) des Download-Nutzers (U) zu ermitteln.
  32. Terminal (T, T1, T2, T3, Tn) zum Herunterladen eines digitalen Inhalts eines Inhalteanbieters (RS) aus einem Computer-Kommunikationsnetzwerk (N) mit einer Netzwerkschnittstelle (NI) zum Empfang von Fragmenten (F) der Datei (D) von anderen am Computer-Kommunikationsnetzwerk (N) angeschlossenen Terminals (T, T1, T2, T3, Tn) und mit einer Transaktionssteuereinheit (1), welche so ausgebildet ist, dass das Terminal (T, T1, T2, T3, Tn) Fragmente (F) der Datei (D) von Terminals (T, T1, T2, T3, Tn) verschiedener Upload-Nutzer aus empfängt.
DE102005010131A 2005-03-02 2005-03-02 Verfahren zur Übertragung von digitalen Inhalten eines Inhalteanbieters an die Nutzer eines Online- Inhalteübertragungssystems Withdrawn DE102005010131A1 (de)

Priority Applications (6)

Application Number Priority Date Filing Date Title
DE102005010131A DE102005010131A1 (de) 2005-03-02 2005-03-02 Verfahren zur Übertragung von digitalen Inhalten eines Inhalteanbieters an die Nutzer eines Online- Inhalteübertragungssystems
EP05751848A EP1854261A1 (de) 2005-03-02 2005-06-11 Verfahren zur übertragung von digitalen inhalten eines inhalteanbieters an die nutzer eines online-inhalteübertragungssystems
RU2007136164/09A RU2007136164A (ru) 2005-03-02 2005-06-11 Способ передачи цифрового контента контент-провайдера пользователям онлайновой системы передачи контента
BRPI0520040-7A BRPI0520040A2 (pt) 2005-03-02 2005-06-11 processo para a transmissão de conteúdos digitais de um provedor de conteúdos aos usuários de um sistema de transmissão de conteúdos on-line
PCT/EP2005/006274 WO2006092158A1 (de) 2005-03-02 2005-06-11 Verfahren zur übertragung von digitalen inhalten eines inhalteanbieters an die nutzer eines online-inhalteübertragungssystems
US11/249,030 US20060200736A1 (en) 2005-03-02 2005-10-12 Method of transmitting digital content of a content supplier to the user of an online content transmission system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102005010131A DE102005010131A1 (de) 2005-03-02 2005-03-02 Verfahren zur Übertragung von digitalen Inhalten eines Inhalteanbieters an die Nutzer eines Online- Inhalteübertragungssystems

Publications (1)

Publication Number Publication Date
DE102005010131A1 true DE102005010131A1 (de) 2006-09-07

Family

ID=34970488

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102005010131A Withdrawn DE102005010131A1 (de) 2005-03-02 2005-03-02 Verfahren zur Übertragung von digitalen Inhalten eines Inhalteanbieters an die Nutzer eines Online- Inhalteübertragungssystems

Country Status (6)

Country Link
US (1) US20060200736A1 (de)
EP (1) EP1854261A1 (de)
BR (1) BRPI0520040A2 (de)
DE (1) DE102005010131A1 (de)
RU (1) RU2007136164A (de)
WO (1) WO2006092158A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1971106A2 (de) 2007-03-14 2008-09-17 Deutsche Telekom AG Verfahren zur Online-Distribution von DRM-Nutzinhalten
DE102018103077A1 (de) * 2018-02-12 2019-08-14 Rauner David Verfahren, Prozessor, nichtflüchtiger Speicher und Recheneinheit

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070157266A1 (en) * 2005-12-23 2007-07-05 United Video Properties, Inc. Interactive media guidance system having multiple devices
US7710958B2 (en) * 2006-01-20 2010-05-04 Iona Technologies Limited Method for recoverable message exchange independent of network protocols
WO2007127401A2 (en) * 2006-04-26 2007-11-08 Bittorrent, Inc. Peer-to-peer download and seed policy management
US7937362B1 (en) * 2006-04-28 2011-05-03 Roxbeam Media Network Corporation System and method for facilitating a credit system in a peer-to-peer content delivery network
DE602006017040D1 (de) * 2006-05-19 2010-11-04 Microsoft Corp Inhaltsverwaltung in Peer-to-peer Datenverteilungswolken
US9317506B2 (en) * 2006-09-22 2016-04-19 Microsoft Technology Licensing, Llc Accelerated data transfer using common prior data segments
US8131673B2 (en) * 2006-12-05 2012-03-06 International Business Machines Corporation Background file sharing in a segmented peer-to-peer file sharing network
US8775562B2 (en) * 2006-12-05 2014-07-08 International Business Machines Corporation Mapping file fragments to file information and tagging in a segmented file sharing system
US9794310B2 (en) * 2007-01-11 2017-10-17 Samsung Electronics Co., Ltd. Meta data information providing server, client apparatus, method of providing meta data information, and method of providing content
CN101637005B (zh) * 2007-01-17 2014-04-09 英特托拉斯技术公司 用于片段文件共享的方法、系统以及装置
US8280958B2 (en) * 2009-07-13 2012-10-02 International Business Machines Corporation List passing in a background file sharing network
US8204791B2 (en) * 2009-07-13 2012-06-19 International Business Machines Corporation File fragment pricing in a segmented file sharing network
JP2011097421A (ja) * 2009-10-30 2011-05-12 Panasonic Corp 通信端末装置及びコンテンツデータ受信方法
EP2447843B1 (de) * 2010-10-06 2013-07-03 Siemens Aktiengesellschaft Verfahren zur Verifizierung eines Anwendungsprogramms einer fehlersicheren Speicherprogrammierbaren Steuerung, und Speicherprogrammierbare Steuerung zur Ausführung des Verfahrens
US8880603B2 (en) 2011-06-07 2014-11-04 Interdigital Patent Holdings, Inc. Peer to peer (P2P) operation by integrating with content delivery networks (CDN)
US8719345B2 (en) * 2012-05-11 2014-05-06 Oracle International Corporation Database replication using collaborative data transfers
US8484347B1 (en) * 2012-06-19 2013-07-09 Kaspersky Lab Zao System and method for malware detection in peer-to-peer computer networks
EP2704053B1 (de) * 2012-08-27 2016-09-21 Giesecke & Devrient GmbH Verfahren und System zur Aktualisierung einer Firmware eines Sicherheitsmoduls
US9749663B1 (en) * 2014-11-23 2017-08-29 Silicondust Usa Inc. Distributed upload of television content

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6219652B1 (en) * 1998-06-01 2001-04-17 Novell, Inc. Network license authentication
US7272645B2 (en) * 2001-05-25 2007-09-18 Sbc Technology Resources, Inc. Method of improving the reliability of peer-to-peer network downloads
KR20010088742A (ko) * 2001-08-28 2001-09-28 문의선 분산처리 및 피어 대 피어 통신을 이용한 네트워크 상의정보전송 병렬화 방법
KR20040013726A (ko) * 2002-08-08 2004-02-14 케이티하이텔 주식회사 온라인 컨텐츠 분배방법 및 장치
GB0303192D0 (en) * 2003-02-12 2003-03-19 Saviso Group Ltd Methods and apparatus for traffic management in peer-to-peer networks
GB0315886D0 (en) * 2003-07-07 2003-08-13 Way Benjamin B P Anti-piracy system

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1971106A2 (de) 2007-03-14 2008-09-17 Deutsche Telekom AG Verfahren zur Online-Distribution von DRM-Nutzinhalten
DE102007013014A1 (de) 2007-03-14 2008-09-18 Deutsche Telekom Ag Verfahren zur Online-Distribution von DRM-Nutzinhalten
EP1971106A3 (de) * 2007-03-14 2008-10-29 Deutsche Telekom AG Verfahren zur Online-Distribution von DRM-Nutzinhalten
DE102018103077A1 (de) * 2018-02-12 2019-08-14 Rauner David Verfahren, Prozessor, nichtflüchtiger Speicher und Recheneinheit

Also Published As

Publication number Publication date
US20060200736A1 (en) 2006-09-07
EP1854261A1 (de) 2007-11-14
WO2006092158A1 (de) 2006-09-08
BRPI0520040A2 (pt) 2009-04-14
RU2007136164A (ru) 2009-04-20

Similar Documents

Publication Publication Date Title
DE102005010131A1 (de) Verfahren zur Übertragung von digitalen Inhalten eines Inhalteanbieters an die Nutzer eines Online- Inhalteübertragungssystems
DE60130377T2 (de) Verfahren zur steuerung des zugriffs auf digitalen inhalt und streaming-medien
DE69531439T2 (de) System zur Steuerung der Verteilung und Benutzung von Digitalwerken mit einer Gebührenmeldvorrichtung
DE69534052T2 (de) System zur Steuerung der Verteilung und Benutzung von Digitalwerken
DE69728182T2 (de) Verfahren und gerät zum entfernten netzwerkzugriffseintrag und netzwerkzugriffsbericht
DE60212920T2 (de) Verfahren und system zur verwaltung von digitalen abonnementrechten
DE69535248T2 (de) System und Verfahren zur Steuerung der Verteilung und Benutzung von Digitalwerken, das eine Nutzungsrechtsgrammatik verwendet
DE69533845T2 (de) System zur Steuerung der Verteilung und Benutzung von zusammengesetzten Digitalwerken
DE602004011282T2 (de) Versenden einer Herausgeber-Benutzungslizenz off-line in einem digitalen Rechtesystem
DE60036713T2 (de) System und verfahren für gesicherte netzwerkstransaktionen
WO2004015952A2 (de) Vorrichtung zum kopiergeschützten verteilen elektronischer dokumente
DE102006027030A1 (de) Vorrichtung und Verfahren zum geschützten Verteilen elektronischer Dokumente
DE112016003268T5 (de) Systeme, Verfahren und Medien für Mediensitzungs-Parallelitätsmanagement mit wiederkehrenden Lizenzerneuerungen
DE102004038566A1 (de) Lizenzsteuerung für Web-Anwendungen
EP1971106A2 (de) Verfahren zur Online-Distribution von DRM-Nutzinhalten
DE112021005837T5 (de) Dezentrale sendeverschlüsselung und schlüsselerzeugungseinrichtung
EP1224807A1 (de) Vorrichtung und verfahren zum kopiergeschützten verteilen elektronischer dokumente
WO2019180152A1 (de) Automatisiertes verfahren zum schutz von elektronischen daten zum zwecke der datenverarbeitung durch dritte unter einbezug transparenter und unterbrechungssicherer vergütung
DE102005062061B4 (de) Verfahren und Vorrichtung zum mobilfunknetzbasierten Zugriff auf in einem öffentlichen Datennetz bereitgestellten und eine Freigabe erfordernden Inhalten
DE102007027019A1 (de) Vorrichtung und Verfahren zur clientseitigen Freigabe elektronischer Dokumente
EP1854061A2 (de) Distributionssystem für daten eines dienstes
DE102021131731A1 (de) Internet-der-dinge-system basierend auf sicherheitsorientierung und gruppenteilung
DE19950267C2 (de) Vorrichtung und Verfahren zum kopiergeschützten Verteilen elektronischer Dokumente
EP1497762A2 (de) Verfahren zur kennzeichnung einer virtuellen ware und vorrichtung zur bereitstellung einer kennzeichnung für eine virtuelle ware
EP1959636A1 (de) Verfahren zum Austausch von Daten

Legal Events

Date Code Title Description
R005 Application deemed withdrawn due to failure to request examination

Effective date: 20120303