DE60114888T2

DE60114888T2 - Internet-bezahlungsprozess auf rückkehrverkehrbasis

Info

Publication number: DE60114888T2
Application number: DE60114888T
Authority: DE
Inventors: Jakobus Middeljans; R. Warner TEN KATE
Original assignee: Koninklijke Philips Electronics NV
Current assignee: IPG Electronics 503 Ltd
Priority date: 2000-12-22
Filing date: 2001-12-10
Publication date: 2006-07-20
Anticipated expiration: 2021-12-11
Also published as: KR20030001366A; ATE309578T1; ES2252153T3; DE60114888D1; US7103557B2; US20020091544A1; JP2004516776A; EP1368762A2; WO2002052813A2; CN1478240A; EP1368762B1; WO2002052813A3

Description

Die vorliegende Erfindung bezieht sich auf einen Prozess und ein System zur Lieferung digitaler Arbeit über einen Kommunikationskanal, wie das Internet, wobei für den Content der genannten digitalen Arbeit, wie diese von einem Kunden empfangen wird, bezahlt werden muss. Insbesondere bezieht sie sich auf ein Übertragungsprotokoll in dem genannten System, geeignet für den genannten Prozess.
Internetverkehr weist das Kennzeichen auf, dass dies der Kundendienst mit der besten Mühe ist. Das bedeutet, dass über das Internet gesendete Datenpakete gefährdet werden, verloren zu gehen oder verzögert zu werden. Maßnahmen um dieses Problem zu lösen, werden allgemein als Qualität des Dienstes bezeichnet.
Ein System vom oben genannten Typ ist aus dem Dokument EP-0715247 bekannt. Dieses Dokument bietet eine umfassenden Beschreibung von Aufbereitungssystemen, Strukturen von digitaler Arbeit, Anhängsel von Benutzerrechten auf digitale Arbeit, Aufbewahrungsorten, Kreditdiensten, Benutzerrechten Sprache und Aufbewahrungstransaktionen, die das genannte System aufweisen kann.
Das in dem genannten Dokument beschriebene Übertragungsprotokoll soll bestimmte Fehlermoden ausschließen, wie böswillige oder unbeabsichtigte Interferenzen in dem Kommunikationskanal. Es ist eine Aufgabe, dass eine Partie zu keiner Zeit eine Verbindung unterbrechen kann als Mittel um Bezahlung zu vermeiden nach der Verwendung einer digitalen Arbeit. Eine komplette digitale Arbeit soll bevor die Zahlung dafür effektuiert wird, geliefert werden. Mit anderen Worten, die Transaktionen mit der Lieferung sind die Art der Sache.
In Bezug auf die Operation beschreibt das genannte Dokument, dass wenn es mehrere Blöcke gibt, die gesendet werden sollen, der Server wartet, bis eine Bestätigungsnachricht von dem Antragsteller (Kunden) empfangen worden ist. Wenn eine Bestätigungsnachricht empfangen wird, sendet der Server den nächsten Block zu dem Abtragsteller und wartet wieder auf eine Bestätigung. Übertragung geschieht folglich blockweise. Der Antragsteller (Kunde) wiederholt folglich denselben Zyklus von Zuständen.
Wenn keine Blöcke mehr gesendet werden sollen, führt der Server die Transaktion durch und wartet auf die Endbestätigungsnachricht. Wenn es einen Kommunikationsfehler gibt, bevor der Server die Endbestätigungsnachricht empfängt, führt er den noch die Transaktion durch, aber schließt einen Bericht über das Ereignis zu dem Vertrauensserver ein. Dieser Bericht dient zweierlei, und zwar erstens als Hilfe bei der Legitimierung von Ansprüchen durch einen Benutzer, der für den Empfang digitaler Arbeit, die nicht komplett empfangen worden ist, eine Rechnung bekommt. Es geht ein gleiches Protokoll zu dem Antragsteller (Kunden); die Kerneigenschaft ist, dass der Server und der Antragsteller eine Übertragung rückgängig machen, wenn diese unterbrochen wird, bevor alle Datenblöcke geliefert worden sind, und damit einverstanden sind, wenn alle Datenblöcke geliefert worden sind.
Die Art derartiger Transaktionen bei der Lieferung bereitet viele Probleme, wenn die betreffende digitale Arbeit groß ist oder wenn Content während einer langen Zeitperiode strömen soll. Eine derartige Situation tritt auf bei der Bezahlung von beispielsweise Audio und/oder Video oder anderem Multimediamaterial erst nach Abschluss des Empfangs des ganzen Contents auf. Ein Antragsteller (Kunde) kann die ganze digitale Arbeit erst nach Bezahlung dafür sehen (empfangen). Ein Problem bezieht sich auf die Wahrscheinlichkeit des Abbruchs der Kommunikation, die umso größer ist, je nachdem der Umfang und folglich die erforderliche Zeit zur Übertragung der digitalen Arbeit großer ist. Ein anderes Problem bezieht sich auf die Notwendigkeit eines Berichtes des Zielservers, beide von dem Server sowie von dem Antragsteller, in Bezug auf die Legitimierung der Zahlung für die digitale Arbeit. Noch ein anderes Problem bezieht sich darauf, dass der Server nicht imstande ist übertragene digitale Arbeit zu löschen, bis die Endbestätigung von dem Antragsteller empfangen worden ist, aber auch nicht imstande ist, die Datei in Bezug auf Verweidung von Datenverlust zu verwenden. Dies erfordert ein umfassendes Protokoll mit beispielsweise einer Doppel-Festlegungsphase oder einem Verschlüsselungspegel ohne wirkliche Steigerung der Verantwortlichkeit.
Es gibt noch ein anderes Problem in Bezug auf die Art der genannten Transaktionen. Dieses Problem bezieht sich auf die Echtzeit-Verarbeitungsanforderung. Da Lieferung kontinuierlicher Medien Echtzeit-Handlung erfordert (wenn Lieferung davon keine Herunterladung ist), sollen die Bezahlungen mit der Liefergeschwindigkeit erfolgen, beispielsweise 20 ms je Paket, so dass Prozesse und Funktionen in Bezug darauf nicht zu Unterbrechungen ("Schluckaufs") in der Medienpräsentation führen.
Es ist nun u. a. eine Aufgabe der vorliegenden Erfindung das Übertragungsprotokoll für die genannten Prozesse und für die genannte Prozesse geeignete Systeme zu vereinfachen.
Es ist eine andere Aufgabe der vorliegenden Erfindung, ein Übertragungsprotokoll zu schaffen, das an einem Server-Computer und einem Kunden-Computer durchführbar ist (sog. End-Gastgeber; folglich für Endgebraucherzwecke).
Es ist noch eine weitere Aufgabe der vorliegenden Erfindung ein Übertragungsprotokoll zu schaffen, das Bezahlung für alle empfangenen digitalen Pakete mit sich bringt, sogar in dem Fall einer nicht kontinuierlichen Übertragung der digitalen Arbeit.
Nach einem Aspekt der vorliegenden Erfindung wird eine Aufgabe oder werden mehrere Aufgaben durch einen Prozess zur Steuerung der Lieferung digitaler Arbeit über einen Kommunikationskanal, wie das Internet, erfüllt, wie in Anspruch 1 beschrieben.
Die Ansprüche 8 und 9 beschreiben das entsprechende System bzw. das Computerprogrammprodukt. Bevorzugte Ausführungsformen sind in den Patentansprüchen 2–7 beschrieben.
Der Grundgedanke und das erfinderische Konzept ist, dass es einen Strom von Bestätigungscodes (ACK) gibt, die aus verfügbaren Übertragungsprotokollen bekannt sind, auch der Funktion von Bezahlungsgutscheinen dienen. Zentral in diesem Konzept ist die Kopplung oder Assoziation der Bezahlung mit einer fließenden Lieferung, d.h. mit einem regelmäßigen Strom von Paketen, der eine gewisse Zeit dauert. Bezahlung erfolgt gleichzeitig mit dem Fortgang der Zeitperiode; Lieferung von Content stockt bei nicht fortschreitender Empfangsbestätigung, folglich bei nicht fortschreitender Bezahlung für den Content.
Der dazugehörige technische Fortschritt ist, dass dieser eine bestehende und deutliche Kontrollspur benutzt, dass der Kunde eine digitale Arbeit (oder einen Teil davon) empfangen hat, wie diese durch den laufenden Strom von Bestätigungscodes bekräftigt und einverleibt ist, um die Bezahlung für den Content der empfangenen Pakete zu regeln. Ein weiterer technischer Fortschritt ist, dass durch Kopplung von Bezahlung für Content an diesen bereits verfügbaren laufenden Strom von Bestätigungscodes eine Regelung der Zahlung für den gelieferten Content vereinfacht wird. Dadurch ist die Notwendigkeit, dass Schichten zu dem Übertragungsprotokoll in Bezug auf Bezahlungsgutscheine, Zusage oder Verschlüsselung hinzugefügt werden, eliminiert. Ein viel weniger striktes Übertragungspro tokoll oder ein Integritätsmechanismus dazu reicht. Ein Kunde bezahlt einfach für jedes Paket, das er selber, als in guter Ordnung empfangen, bereits bestätigt hat. Dies führt zu einer weniger redundanten und folglich schnelleren Durchführung von Bezahlungstransaktionen. Es bietet folglich eine größere Effizienz für den Server sowie für den Kunden.
Es sei bemerkt, dass der Ausdruck Übertragungs- oder Transportprotokoll auch "Streaming"- Protokolle umfasst. Streaming beschränkt sich nicht auf Übertragungs- oder Transportprotokolle; wenigstens Server- und Kundenapplikationsprozesse spielen auch eine Rolle in dieser Hinsicht.
Nach einem weiteren Aspekt der vorliegenden Erfindung wird eine oder mehrere der oben genannten Aufgaben dadurch erfüllt, dass während der Übertragung digitaler Pakete durch den Server ein Kreditrahmen verwendet wird, wie in Anspruch 3 erwähnt. Dies geht aus der Überwindung des Vorurteils hervor, dass in Bezug auf Bezahlung von Content von digitaler Arbeit, Übertragung der ganzen digitalen Arbeit beendet sein soll, bevor man imstande ist, endgültig dafür zu bezahlen. Der relatierte technische Vorteil ist, dass der Server einen Kreditbetrag bietet, der im Vergleich zu der Größe der ganzen digitalen Arbeit relativ gering ist. Dies bringt mit sich, dass der Server (oder der Content-Provider) keinen Verlust hinnehmen möchte bei Nichtzahlung für die auf Kredit gelieferten Pakete, wenn keine weiteren Bestätigungscodes von dem Kunden (Antragsteller) empfangen werden sollten. Die Größe des Kreditrahmens kann an die aktuellen Übertragungsumstände und an die Politik der Übertragung angepasst werden.
Das Konzept eines Rahmens an sich ist zur Verwendung der Strömungsgeschwindigkeit der Übertragung bekannt. Siehe beispielsweise D. P. Bertsekas und R. G. Gallager : "Data Networks", Prentice-Hall, Inc. NJ, USA, 1992, Kapitel 6.2. Das TCP-Protokoll vom Internet basiert auf Rahmensteuerung. Das heißt, der "Übertragungsrahmen" ist bekannt; das Konzept eines "Kreditrahmens" für die Bezahlung, in dem vorliegenden Beispiel in Bezug auf Streaming Content von (Teilen von) digitaler Arbeit ist neu.
Das Übertragungskontrollprotokoll (TCP) ermöglicht eine Segmentierung der zu übertragenden Daten zu IP-Paketen und eine Nummerierung der Bytes. Unter Verwendung dieser Nummern ordnet der Empfänger einer TCP-Verbindung die empfangenen Pakete neu, wenn IP diese Pakete ungeordnet geliefert hat. Weiterhin sendet er ein ACK-Paket (Bestätigung) zurück zu dem Sender für jedes empfangene Paket, von dem die vorhergehenden Pakete auch empfangen worden sind. Der TCP-Sender benutzt diese ACKs um zu ermitteln, welche Pakete zurückgesendet werden müssen um Verluste zu reparieren, und dadurch die IP-Lieferung in eine zuverlässige End-zu-End-Transport umzuwandeln. Ein Paket wird dann zurückgesendet, wenn eine Warteperiode vorbei ist, in der eine erwartete ACK nicht empfangen worden i, oder wenn das vorhergehende Paket dreimal bestätigt wurde. Die Warteperiode basiert auf einer Schätzung der "Round Trip Time" (RTT). Doppelt Bestätigungen (ACKs) geben an, dass Pakete, die auf das fehlende Paket folgen, dennoch bestätigt worden sind, was an sich wieder eine Angabe davon ist, dass es keine weitere Stauung in dem Transportkanal gibt.
Andere Alternativen um den Absender über fehlende Pakete zu informieren sind das Senden von NAKs, negativen ACKs, oder SACKs, selektiven ACKs.
TCP benutzt auch die ACKs um die Übertragungsrate zu ermitteln. Diese Rate folgt als die Anzahl Pakete unterwegs, für die eine Bestätigung erforderlich ist, dem Rahmen, gegenüber der RTT. Der Rahmen wird bei erfolgreicher Übertragung größer, während dagegen verlorene Pakete den Rahmen verringern. Auf diese Weise passt TCP die Übertragungsrate an die verfügbare Bandbreite an.
Die vorliegende Erfindung schafft ebenfalls einen Prozess zur Anwendung, wie in Anspruch 5 beschrieben.
Die vorliegende Erfindung schafft weiterhin ein Verfahren, wie in Anspruch 6 definiert.
Die vorliegende Erfindung schafft außerdem ein Computerprogramm, wie in Anspruch 9 beschrieben.
Ausführungsbeispiele der Erfindung sind in der Zeichnung dargestellt und werden im Folgenden näher beschrieben. Es zeigen:
1 einen allgemeinen Aufbau des Prozesses nach der vorliegenden Erfindung,
2 die Wirkung des Monitors nach 1,
3 die Rolle der Protokolle in dem Verkehr zwischen dem Server und dem Kunden.
Nach einer Ausführungsform der vorliegenden Erfindung gibt es nach einem Antrag von einem Kunden zu einem Server, beispielsweise während einer Sessionsanfangsphase eine Übertragungsphase zwischen den beiden in Bezug auf den Aufsatz eines Zurückkehrverkehrs von Bestätigungscodes und Bezahlungsgutscheine. Es soll eine Ver einbarung über dieselben und auch über andere technische Aspekte, wie Content-Typ, Codierungstyp, IP Adresse, Portnummern usw. erreicht werden. Ein folgender Schritt in dem Prozess nach der vorliegenden Erfindung bringt mit sich, dass eine digitale Arbeit (100) beispielsweise mit Multimedia-Content zu einer Anzahl digitaler Pakete (100₁ , ... 100_z ) in einem Server (200) gebildet wird. Die Größe eines Pakets (100_1...i...z ) ist im Vergleich zu der Größe der betreffenden digitalen Arbeit (100) gering. Im falle beispielsweise von Audio-Content ist die Größe der Pakete klein genug um einer Übertragung von 20 ms Intervallen zu entsprechen. Der Server (200) umfasst Sender-Software und/oder Hardwareelemente (210), die er benutzt zum Übertragen der Pakete (100₁ ... 100_z ) zu einem Kunden (300). Der Kunde (300) speichert (310) oder reproduziert (320) oder verarbeitet auf eine andere Weise die Pakete, die er empfängt. Er bestätigt (330) die empfangenen Pakete dadurch, dass Bestätigungscodes (ACKs) zu dem Server gesendet werden. Ein Monitor (220) in dem Server mit Empfänger-Software und/oder Hardware-Elementen (nicht dargestellt) empfängt die Bestätigungscodes (SCKs), die von dem Kunden gesendet wurden und auf Basis dieser Codes steuert er den Fortgang der Übertragung von Paketen. Dazu liefert der Monitor (220) Steuerbefehle zu dem Sender-Software und/oder Hardware (210). Es gibt Fortgang vom Streaming des genannten Contents durch den Server nur dann, wenn die von dem Kunden beantragten Bestätigungscodes, wie von dem Server spezifiziert, empfangen werden, sonst gibt es eine Unterbrechung der Streaming-Übertragung durch den Server, wenn der angefangene erfolgreiche Rückkehrverkehr der Bestätigungscodes von dem Kunden zu dem Server unterbrochen wird. Die empfangenen Bestätigungscodes werden ebenfalls in einem Bezahlungsregister (nicht dargestellt) gespeichert, das die weitere Bezahlung abwickelt. Es sei bemerkt, dass es nicht notwendig ist, dass für jedes Datenpaket, das von dem Server gesendet wurde, ein ACK Paket von dem Kunden zurückgesendet wird. Es dürfte einleuchten, dass andere Abbildungen auch dienen können.
2 zeigt eine Ausarbeitung der Steuervorgänge des Monitors (220) nach 1. 2 zeigt die Reihenfolge der aufeinander folgenden Pakete des Mediastroms. Die Pakete bis zum Paket N – 1 sind bereits übertragen worden. Eine Anzahl von T Pakete sind bereits übertragen, müssen aber noch von dem Kunden bestätigt werden, d.h. diese Pakete sind in Transit. Der Server ist derart eingestellt, dass er akzeptiert, dass zu einem bestimmten Zeitpunkt bis zu W Pakete noch nicht bestätigt sein können. Wenn W Pakete nicht rechtzeitig bestätigt worden sind, wird der Server die Übertragung unterbrechen.
Der Monitor (220) verwaltet die Anzahl übertragener Pakete und die Anzahl Pakete, die in Transit sind. Die übertragenen Pakete sind entweder als erfolgreich oder erfolglos gekennzeichnet, und zwar abhängig davon, ob wohl oder nicht ein SCK für dieses Paket empfangen worden ist. Jedes Paket ist auch mit einer Übertragungszeit und einem Übertragungstermin assoziiert. Das erste Element gibt an, wann das Paket im normalen Betrieb übertragen wird, das zweite Element bezeichnet, ob Neuübertragung nützlich ist, so dass der Kunde dennoch das Paket rechtzeitig zur Wiedergabe empfangen kann. (In Bezug auf eine Herunterladung ist dies immer der Fall). Diese Zeiten steigen nicht unbedingt im Verhältnis zu der Anzahl (Reihenfolge) der Pakete. Bei dieser Ausführungsform und nur als Beispiel sei vorausgesetzt, dass diese Zeiten proportional zu der betreffenden Paketreihenfolge zunehmen.
In einer Ausführungsform der vorliegenden Erfindung kann eine Bestätigung der empfangenen Daten absichtlich zeitbegrenzt gemacht werden. Ein Beispiel ist der Fall, wobei das Zuhören von Audiomaterial oder das Zuschauen von Videomaterial unter Vorabhör- bzw. Vorschaubedingungen gewährt wird. Bestätigung ist begrenzt und der Server unterbricht die Übertragung, wenn die Zeitgrenze überschritten wird. Während der Vorabhör- oder Vorschauperiode wird einem Kunden oder Benutzer die Möglichkeit geboten, die Transaktion zu bestätigen und, wenn nicht wie erforderlich bestätigt wird, ist keine weitere Übertragung gestattet.
Es dürfte einleuchten, dass es für den während einer Vorschau- oder Vorabhörperiode empfangenen Content eine andere Bezahlungspolitik gibt. Es dürfte auch einleuchten, dass der genannte Content in Bezug auf Bezahlungspolitik nach einer Rückstellung des Kreditrahmens anders behandelt wird.
Bei einer anderen Ausführungsform der vorliegenden Erfindung kann der Kreditrahmen zunächst groß sein. Es ist möglich, die Größe des Kreditrahmens einmal oder mehrere Male nach der Vorschau- oder Vorabhörperiode einzustellen. Eine Steigerung der Größe des Kreditrahmens würde sich auf die Anzahl ACKs beziehen, die während der Vorschau- oder Vorabhörperiode oder während jedes beliebigen Typs einer Probeperiode von dem Server nicht empfangen zu werden brauchten. Es ist ebenfalls möglich, eine Verringerung der Größe des Kreditrahmens zu erwägen und zu implementieren, wenn dies notwendig oder erwünscht ist. Weitere Aktionen seitens eines Kunden, beispielsweise Bestätigung durch den Kunden bevor die Probeperiode vorbei ist, können in einem Entscheidungsbaum oder -protokoll technisch implementiert werden. In wieder einer anderen Ausführungsform kann der Kreditrahmenmechanismus nur ausgelöst werden, nachdem eine Probeperiode beendet worden ist. Dies würde Synchronisation zu der Kundenseite des Prozesses und des Systems zum Implementieren desselben erfordern.
Benutzerbestätigung kann verschiedenartig gegeben werden. Wenn beispielsweise vom Kunden oder Benutzer aus keine Aktion unternommen wird, wird der Server einen richtigen Empfang der Datenpakete bestätigen, wenn die Datei geliefert worden ist. Dies entspricht dem Ausdruck: "keine Nachricht, gute Nachricht" (= einwandfreien Empfang). Ein zweites Beispiel ist die Erzeugung einer Aktion in Bezug auf eine einwandfreie Lieferung der Datenpakete am Ende der Aufzeichnung durch den Kunden oder den Benutzer. Die genannte Aktion könnte in Bezug auf jede beliebige aktive Bewegung in Bezug auf den Spieler sein. Es dürfte einleuchten, dass es ein Bedürfnis nach Unterdrückung zwischen allen Sorten von Klicks oder anderen von dem Benutzer durchgeführten Aktionen, da sonst keine gleichzeitige Aktionen während der Lieferung der Datenpakete durchgeführt werden könnten. Ein drittes Beispiel würde die Möglichkeit einer Taste mit sich bringen, beispielsweise "einwandfrei empfangen" am Schirm des Benutzers und/oder eine Fernsteuermöglichkeit. Alle Arten von Benutzerschnittstellen können in dieser Hinsicht angewandt werden.
3 zeigt die Rolle mehrerer Beispiele von Protokollen in dem verkehrt zwischen dem Server und dem Kunden. Es werden einige Beispiele von Protokollen gezeigt, die für die verschiedenen Austauschphasen in dem Verkehr zwischen dem Server und dem Kunden angewandt werden können. Während der Sessionsauslösungs- und Verhandlungsphase können http/TCP Protokolle angewandt werden; Verhandlung und Auslösung/Bestätigung können unter Verwendung von SDP ausgetauscht werden; während der Sessionsregelung und des Media-Content-Transportes können RTSP/TCP und RTP/UDP Protokolle angewandt werden.
In Bezug auf den Betriebszustand aus 2 aktualisiert der Monitor (220) die jeweiligen Zeiger zu den jeweiligen Rahmenbegrenzungen aus 2 entsprechend den nachfolgenden Algorithmen (diese Algorithmen sind nur als Beispiel gewählt worden):
Bei Empfang von ACK_N:

– erhöhe ACK Zeiger um Eins in die Position N
– erhöhe den Kreditrahmenzeiger um Eins in die Position N + W
– markiere die Stelle N als Erfolgreich

_N+P

– erhöhe den Kreditrahmenzeiger um Eins in die Position N + W
– markiere die Stelle N + P als Erfolgreich
– für p = 0 bis P – 1 tue:
– wenn der Neuübertragungstermin des Pakets M + p verstrichen ist:
– erhöhe den ACK Zeiger in die Position N + p (wie erwähnt, in diesem Beispiel ist eine monotone Erhöhung der Neuübertragungstermine vorausgesetzt)
– markiere die Stelle N + p als Erfolglos
– sonst (Neuübertragungstermin des Pakets N + p noch nicht beendet):
– übertrage das Paket N + p abermals (Neuübertragung kann auch von anderen Mechanismen wie eine Pause ausgelöst werden; auf gleiche Weise kann eine Neuübertragung den Empfang von mehr als nur einen ACK_N+P, P > 0 erfordern)

_N-M

– wenn die Stelle N – M als Erfolglos markiert wurde:
– markiere die Stelle N – M als Erfolgreich
– erhöhe den Kreditrahmenzeiger um Eins in die Position N + W

Pakete werden in einem regelmäßigen Schritt übertragen, d.h. der als Paket gesendete Zeiger wird um ins erhöht, das Transitfenster wird mit einem regelmäßigen Schritt geöffnet. Ein Paket wird übertragen, wenn es in dem Transit und in dem Kreditrahmen ist. Im normalen Betrieb, wie als Beispiel in 2 dargestellt, bedeutet dies, dass das Paket N + T gesendet wird, wenn die Übertragungszeit vorbeigeht. Sonst in dem Fall, dass die Übertragungszeit vergangen ist, nicht aber der Übertragungstermin vorbei ist, wird das Paket gesendet, wenn der Kreditrahmen öffnet um dieses Paket zu enthalten. Im Grunde wenn der Übertragungstermin vorbei ist, wird das Paket als Erfolglos angemerkt. In einer derartigen Situation gilt die ganze Übertragung als zerrissen.
In Bezug auf die Größe des Kreditrahmens W: die Anzahl offener ACK Codes, d.h. für die gesendeten Datenpakete, deren Empfang noch nicht von dem Kunden bestätigt worden ist, kann gesetzt werden, dass sie inkrementiert sind, wenn eine bestimmte Anzahl (zusätzlicher) ACKs empfangen worden ist oder wenn die Datenpakete eine bestimmte Zeitperiode lang gesendet und empfangen worden sind. Der Kreditrahmen kann dagegen dekrementiert werden, wenn die Übertragung nicht geschmeidig gelaufen ist.
Bezahlung entsprechend der Anzahl Erfolgreicher Zählungen. Die Wahl von T ist derart, dass Neuübertragungen verloren gegangener Pakete innerhalb des bestimmten Termins erfolgen können. Die Wahl von W ist abhängig von dem Kredit, den die Transaktion akzeptieren will. W soll klein sein, d.h. unzureichend, im Vergleich zu der gesamten Anzahl übertragener Pakete.
Unterdrückung von ACks durch den Kunden wird den Kreditrahmen W schließen. Gegebenenfalls wird die Übertragung abgebrochen. In einem fehleranfälligen Übertragungskanal werden ACKs nicht empfangen, entweder weil das Paket nicht empfangen wurde, oder weil die ACK verloren gegangen ist. Dies wird vermeiden, dass der Kreditrahmen sich öffnet. Wenn außerdem die Neuübertragungstermine zu kritisch sind, kann die Übertragung abgebrochen werden, obschon der Kunde alle Pakete, die er empfängt, bestätigt.
Verluste sind unerwünscht, und zwar wegen der zugehörigen Verzerrung, die der Kunde beim Empfang erfährt. Fensterschließung durch anhaltende Verluste kann durch eine gut bemessene Wahl von W im Vergleich zu T umgangen werden. Anhaltende Verlustraten können in der Verhandlungsphase beim Aufbau der Verbindung umgangen werden. Es wird beispielsweise vorausgesetzt, dass der Kunde und der Server sich über eine akzeptierbare Verlustrate von e% einig sind. Nebst möglicher Übertragung zusätzlicher Redundanzpakete bedeutet dies, dass der Kreditrahmenzeiger nach allen hunderte (der Reziprokwert von e%) Paketen die als Erfolglos markiert sind, um Eins inkrementiert wird (korrigiert für Pakete, die als Erfolgreich neu markiert wurden).
Maskerade durch einen Kunden kann dadurch vermieden werden, dass der Server sog. "Aufforderungen" zusammen mit den Datenpaketen zu dem Kunden sendet und dadurch, dass der Kunde Antworten darauf zusammen mit dem Rückkehrverkehrt der Bestätigungscodes zurücksendet.
Die vorliegende Erfindung betrifft auch Computerprogramme, insbesondere Computerprogramme auf oder in einem Träger, angepasst zum Praktizieren der vorliegenden Erfindung. Das Programm kann in Form von Herkunftscode, Objektcode, einer Code-Zwischenquelle und Objektcode wie in einer teilweisen kompilierten Form, oder in jeder beliebigen geeigneten Form zur Verwendung in der Implementierung der Prozesse nach der vorliegenden Erfindung. Der Träger kann jede beliebige Entität oder Anordnung sein, die imstande ist, das Programm zu tragen.
So kann beispielsweise der Träger ein Speichermedium aufweisen, wie einen ROM, beispielsweise einen CD-ROM, oder einen Halbleiter-ROM, oder aber ein magnetisches Speichermedium, beispielsweise ein Floppy oder eine Festplatte. Der "Träger kann auch ein übertragbarer Träger sein, wie ein elektrisches oder optisches Signal, das über ein elektrisches oder optisches Kabel oder durch Funk oder aber durch andere Mittel transportiert werden kann.
Wenn das Programm in einem Signal einverleibt ist, das unmittelbar von einem Kabel oder von einer anderen Anordnung oder einem anderen Mittel übertragen werden kann, kann der Träger durch ein derartiges Kabel oder durch derartige Mittel gebildet werden.
Auf alternative Weise kann der Träger eine integrierte Schaltung sein, in die das Programm eingebettet ist, wobei die integrierte Schaltung dazu vorgesehen ist, die betreffenden Prozessschritte durchzuführen oder die betreffenden Prozessschritte in dem Programm zu verwenden.
Der Prozess, das Bestandsprotokoll davon und das System und die Computerprogramme zum Implementieren desselben, wie oben beschrieben, sind allgemein anwendbar in Fällen, in denen Mikrobezahlungen ins Spiel kommen. Einige geeignete und keineswegs begrenzende Beispiele beziehen sich auf Anordnungen mit Herunterlade- oder Streaming-Möglichkeiten, die mit Kommunikationskanälen, wie dem Internet, beispielsweise einer Juke-Box, verbunden sind. Die allgemeine Neuheit und der oben beschriebene erfinderische Konzept kann auch zur Anwendung bei Fernsehen und Set-Top-Boxen angewandt werden.
Text in der Zeichnung
1

Senden
Monitor
Netzwerk
Bestätigungscodes
Content
Bezahlungsmahnung
Content herunterladen

2

Übertragen
Transitfenster
Zu übertragen
Kreditrahmen
ACK Zeiger
Paket gesendet Zeiger
Kreditrahmenzeiger

3

Antrag
AV-Spieler
Kunde

Claims

Prozess zur Steuerung der Lieferung digitaler Arbeit über einen Kommunikationskanal, wobei für den Content der digitalen Arbeit bezahlt werden muss, wobei der Prozess an einem Server-Computer (200) und an einem Kunden-Computer (300) durchführbar ist, wobei der genannte Prozess die nachfolgenden Prozessschritte umfasst: a) das Verhandeln der Konfiguration der Kommunikation zwischen dem Kunden und dem Server zum Zustimmen zu und zum Konfigurieren des Contents einer digitalen Arbeit, b) das Schaffen an dem Server und Durchführen eines regelmäßigen Stromes von Paketen (100_I...i...Z ), was einige Zeit dauert, wobei die Paketgröße gegenüber der Gesamtgröße der digitalen Arbeit gering ist, mit dem Content von dem Server zu dem Kunden unter Anwendung eines Übertragungs- oder Transportprotokolls, wodurch dem Kunden einen Antrag gestellt wird, den empfangenen Content zu bestätigen, c) das Auslösen eines Rückkehrverkehrs von wenigstens einem Bestätigungscode (ACK) durch den Kunden zu dem Server, wobei mit jedem Bestätigungscode oder mit einer Anzahl Bestätigungscodes ein Bezahlungszeichen assoziiert ist, d) das Bescheinigen durch den Server, dass jeder beantragte Bestätigungscode des Kunden von dem Server empfangen wird, e) das Fortsetzen des Stromes mit dem genannten Content durch den Server, nur dann, wenn der (die) beantragte(n) Bestätigungscode(s) des Kunden wie durch den Server spezifiziert empfangen (wird) werden, f) das Akkumulieren der mit den Bestätigungscodes assoziierten Bezahlungszeichen. Die von dem Kunden empfangen wurden in einer Betriebsart: bezahle-für-jedes-empfangene-Paket-wenn-von-dem-Kunden-bestätigt. g) Anordnung zum Ausstellen einer Rechnung an und zur Bezahlung durch den Kunden für alle empfangenen Pakete auf Basis wenigstens des genannten akkumulierten Bezahlungszeichens.
Prozess zur Steuerung der Lieferung digitaler Arbeit über einen Kommunikationskanal nach Anspruch 1, dadurch gekennzeichnet, dass in dem Schritt (c) oder in dem Schritt (e) Bestätigung durch den Kunden mit wenigstens einem Paket des nachfolgenden Stromes von dem Server zu dem Kunden assoziiert ist.
Prozess zur Steuerung der Lieferung digitaler Arbeit über einen Kommunikationskanal nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass in dem Schritt (e) Fortsetzung des Stromes mit Paketen mit Content durch den Server auftritt, wobei eine bestimmte Anzahl Pakete übertragen werden kann, während eine Anzahl Bestätigungscodes unterwegs, weniger als oder gleich einer anderen vorbestimmten Anzahl Bestätigungscodes umgeben durch das Kreditfenster noch nicht von dem Server empfangen worden sind.
Prozess zur Steuerung der Lieferung digitaler Arbeit über einen Kommunikationskanal nach Anspruch 3, dadurch gekennzeichnet, dass die Größe des genannten Kreditfensters an die Anzahl von dem Kunden empfangener Bestätigungscodes angepasst werden kann.
Prozess nach einem der Ansprüche 1–4, zur Verwendung in der Begleitung von Geschäftsvorgängen oder kommerziellen Transaktionen, die Regelung der Bezahlung auf Basis empfangenen Rückkehrverkehrs umfassend.
Prozess nach Anspruch 5 zur Anwendung in der Begleitung von Geschäftsvorgängen oder kommerziellen Transaktionen, wobei außerdem das Bezahlen abhängig ist von der Übertragungsrate und/oder von der Länge der Übertragungssession und/oder der Verlustrate der übertragenen digitalen Pakete.
Prozess zur Steuerung der Lieferung digitaler Arbeit über einen Kommunikationskanal nach Anspruch 1, dadurch gekennzeichnet, dass der Kommunikationskanal das Internet ist.
System zur Steuerung der Lieferung digitaler Arbeit zu einem Kunden (300), und zwar über einen Kommunikationskanal, wobei für den Content der genannten digitalen Arbeit bezahlt werden muss, wobei dieses System folgende Elemente umfasst: a) Mittel zum Verhandeln der Konfiguration der Kommunikation zwischen dem Kunden und dem System zum Zustimmen zu und zum Konfigurieren des Contents einer digitalen Arbeit, b) Mittel zum Schaffen an dem System und zum Durchführen eines regelmäßigen Stromes von Paketen (100_I...i...Z ), was einige Zeit dauert, wobei die Paketgröße gegenüber der Gesamtgröße der digitalen Arbeit gering ist, mit dem Content von dem Server zu dem Kunden unter Anwendung eines Übertragungs- oder Transportprotokolls, wodurch dem Kunden einen Antrag gestellt wird, den empfangenen Content zu bestätigen, c) Mittel zum Auslösen eines Rückkehrverkehrs von wenigstens einem Bestätigungscode (ACK) durch den Kunden zu dem Server, wobei mit jedem Bestätigungscode oder mit einer Anzahl Bestätigungscodes ein Bezahlungszeichen assoziiert ist, d) Mittel zum Bescheinigen durch den Server, dass jeder beantragte Bestätigungscode des Kunden von dem Server empfangen wird, e) Mittel zum Fortsetzen des Stromes mit dem genannten Content durch den Server, nur dann, wenn der (die) beantragte(n) Bestätigungscode(s) des Kunden wie durch den Server spezifiziert empfangen (wird) werden, f) Mittel zum Akkumulieren der mit den Bestätigungscodes assoziierten Bezahlungszeichen, die von dem Kunden empfangen wurden in einer Betriebsart: bezahle-für-jedes-empfangene-Paket-wenn-von-dem-Kunden-bestätigt. g) Mittel zum Ausstellen einer Rechnung an und zum Bezahlen durch den Kunden für alle empfangenen Pakete auf Basis wenigstens des genannten akkumulierten Bezahlungszeichens.
Computerprogrammprodukt zur Steuerung der Lieferung digitaler Arbeit über einen Kommunikationskanal, wobei für den Content der genannten digitalen Arbeit bezahlt werden muss, wobei der Prozess an einem Server-Computer (200) und einem Kunden-Computer (300) erledigt wird, wobei das Computerprogrammprodukt Instruktionen aufweist, die in einen Prozessor eines Server-Computers (200) und in einen Prozessor eines Kunden-Computers (300) zum Durchführen geladen werden müssen und wobei die Instruktionen Folgendes umfassen: a) einen Code zur Verhandlung der Konfiguration der Kommunikation zwischen dem Kunden und dem Server zum Zustimmen zu und zum Konfigurieren des Contents einer digitalen Arbeit, b) einen Code zum Schaffen an dem Server und zum Durchführen eines regelmäßigen Stromes von Paketen (100_I...i...Z ), was einige Zeit dauert, wobei die Paketgröße gegenüber der Gesamtgröße der digitalen Arbeit gering ist, mit dem Content von dem Server zu dem Kunden unter Anwendung eines Übertragungs- oder Transportprotokolls, wodurch dem Kunden einen Antrag gestellt wird, den empfangenen Content zu bestätigen, c) einen Code zum Auslösen eines Rückkehrverkehrs von wenigstens einem Bestätigungscode (ACK) durch den Kunden zu dem Server, wobei mit jedem Bestätigungscode oder mit einer Anzahl Bestätigungscodes ein Bezahlungszeichen assoziiert ist, d) einen Code zum Bescheinigen durch den Server, dass jeder beantragte Bestätigungscode des Kunden von dem Server empfangen wird, e) einen Code zum Fortsetzen des Stromes mit dem genannten Content durch den Server, nur dann, wenn der (die) beantragte(n) Bestätigungscode(s) des Kunden wie durch den Server spezifiziert empfangen (wird) werden, f) einen Code zum Akkumulieren der mit den Bestätigungscodes assoziierten Bezahlungszeichen, die von dem Kunden empfangen wurden in einer Betriebsart: bezahle-für-jedes-empfangene-Paket-wenn-von-dem-Kunden-bestätigt. g) einen Code zum Ausstellen einer Rechnung an und zum Bezahlen durch den Kunden für alle empfangenen Pakete auf Basis wenigstens des genannten akkumulierten Bezahlungszeichens.