DE60315971T2

DE60315971T2 - Verfahren zur kontrollierten Übertragung einer Dienstleistung und Gerät um dieses Verfahren auszuführen

Info

Publication number: DE60315971T2
Application number: DE60315971T
Authority: DE
Inventors: Lieve Maria Marcella Rosemarijn Bos; Adrianus Johannes Van Ewijk
Original assignee: Alcatel Lucent SAS
Current assignee: Alcatel Lucent SAS
Priority date: 2003-08-01
Filing date: 2003-08-01
Publication date: 2008-05-21
Anticipated expiration: 2023-08-02
Also published as: EP1503560B1; US20050027791A1; US8224965B2; EP1503560A1; DE60315971D1; ATE372018T1

Description

Die vorliegende Erfindung betrifft ein Verfahren zur kontrollierten Bereitstellung eines Dienstes, wie im Oberbegriff von Anspruch 1 weiter beschrieben.
Ein ähnliches Verfahren zur kontrollierten Bereitstellung eines Dienstes ist in der Technik bereits bekannt, z.B. aus "The Open Mobile Alliance – Generic Content download over the air Specification Version 1.0 of December 19, 2002". Darin wird ein Verfahren zum abgesicherten Herunterladen beschrieben, um digitale Inhalte zu liefern, wie Unterhaltungs- und Geschäftsanwendungen. Dieses Verfahren umfasst folgende Schritte:

– Senden eines Download-Deskriptors vom Server zum Client-Terminal, wobei dieser Download-Deskriptor Informationen über den Typ und die Lage des herunterzuladenden Inhaltes enthält und optional eine Anforderung entweder für eine Bestätigung oder einen Fehlerbericht, abhängig davon, ob der Dienst erfolgreich heruntergeladen wird oder nicht,
– Durch das Client-Terminal Abruf der Anwendung vom Server,
– Durch das Client-Terminal Senden einer ersten Bestätigungs-Nachricht zum Server,
– Aktivierung des Dienstes durch den Client.

Dieses Verfahren zum kontrollierten Herunterladen hat jedoch mehrere Nachteile. Der Haupt-Nachteil ist, dass im Fall eines Netzwerkfehlers der Download-Mechanismus nach dem Stand der Technik keine Möglichkeit bietet, zu erkennen, welcher Teil des Inhaltes nicht empfangen wurde.
Eine Aufgabe der Erfindung ist es daher, ein Verfahren zur kontrollierten Bereitstellung eines Dienstes zu liefern, das die oben erwähnten Probleme löst, die bei dem Verfahren zum kontrollierten Herunterladen eines Dienstes nach dem Stand der Technik auftreten.
Gemäß der Erfindung wird dieses Ziel durch die Tatsache erreicht, dass das Verfahren die Schritte enthält, wie im kennzeichnenden Teil des ersten Anspruchs beschrieben.
Die Umsetzung des Dienstes in eine Sequenz einzelner Blöcke, so dass ein Download-Deskriptor und Bestätigungs-Nachrichten pro Block erzeugt und übertragen werden, erlaubt es somit, exakt nachzuverfolgen, welche Blöcke empfangen wurden und welche nicht, so dass das Problem des Standes der Technik geeignet gelöst wird.
Eine zusätzliche charakteristische Eigenschaft der vorliegenden Erfindung wird in Anspruch 2 beschrieben.
Diese zusätzlichen Eigenschaften verbessern das Verfahren noch weiter, um es besser für Streaming-Dienste zu machen. Ein weiterer Nachteil des Verfahrens nach dem Stand der Technik war, dass dieser Mechanismus nach dem Stand der Technik es dem Client-Terminal nicht erlaubt hat, den Dienst bereits während dessen Lieferung zu starten, was bedeutet, dass dieser Download-Mechanismus nach dem Stand der Technik für solche Streaming-Dienste nicht benutzt werden kann. Unter Streaming-Diensten werden in diesem Text alle Dienste verstanden, bei denen die Aktivierung beginnt, sobald die ersten Bits des Dienstes empfangen werden, während der Rest des Dienstes gleichzeitig noch geliefert wird. Da die Dienst-Aktivierung bereits beginnt, bevor ein kompletter Block empfangen wurde, ist eine gleichzeitige Lieferung und Aktivierung somit möglich. Durch die Tatsache, dass bei Empfang der ersten Bestätigungs-Nachricht für Block n durch den Server der Deskriptor für Block n + 2 erzeugt und gesendet wird, findet die Lieferung des Inhaltes von Block n + 1 statt, während der Client bereits auf den Abruf von Block n + 2 vorbereitet wird.
Eine weitere kennzeichnende Eigenschaft der vorliegenden Erfindung wird in Anspruch 3 beschrieben.
Dadurch, dass in den Deskriptor Informationen über Benutzerrechte aufgenommen werden, wie DRM-Information, die von einem DRM-Gerät des Client (DRMC) im Client weiter verwendet wird, so dass die Dienst-Aktivierung von dieser Information abhängt, hat der Server die volle Kontrolle über die Aktivierung oder eventuelle Blockierung des Dienstes. Weiterhin bietet dies auch Möglichkeiten für eine Rechnungsstellung auf der Grundlage der tatsächlichen Nutzung des Dienstes, wobei nur die Teile des Inhaltes berücksichtigt werden, die vom Client erfolgreich empfangen/dem Server bestätigt wurden.
Zusätzlich zur Information über Benutzerrechte können in den Download-Deskriptor auch Guthaben-Informationen aufgenommen oder an die verschiedenen Blöcke angehängt werden, wie in Anspruch 4 angegeben.
Diese Information über Benutzerrechte kann jedoch auch in die Datenblöcke des Dienstes eingefügt oder an sie angehängt werden, wie in Anspruch 5 beschrieben. In Anspruch 6 wird weiterhin beschrieben, dass der Download-Deskriptor zu einem zweiten Typ von Bestätigungs-Meldung gehören kann, der in manchen Protokollen vorhanden ist, wie z.B. in dem oben erwähnten Protokoll OMA nach dem Stand der Technik. Dies garantiert die Kompatibilität zu vorhandenen Protokollen, was die Vielseitigkeit des Verfahrens erhöht.
In Anspruch 7 wird weiterhin angegeben, dass die Blöcke verschlüsselt werden können. Die Verschlüsselungs-Schlüssel pro Block können Teil des Deskriptors sein, wie in Anspruch 8 angegeben, oder sie können gesondert vor der Übertragung des Blocks übertragen werden, wie in Anspruch 9 angegeben. Wenn bei der Übertragung keine erneute Verschlüsselung erforderlich ist und die Blöcke alle denselben Verschlüsselungs-Schlüssel benutzen, kann dieser Schlüssel auch zu Beginn in einer gesonderten Nachricht gesendet werden oder zum ersten Deskriptor gehören. Eine weitere Möglichkeit ist, dass er auf einem zuvor bekannten gemeinsamen Geheimnis von Client und Server beruht.
In Anspruch 10 wird angegeben, dass zur Aktivierung eines neuen Dienstes das Verfahren mit der Übertragung des Download- Deskriptors der ersten und zweiten Blöcke des Dienstes beginnt.
Die vorliegende Erfindung betrifft auch einen Server und einen Client, die in der Lage sind, die Schritte des oben erwähnten Verfahrens auszuführen, wie in den Ansprüchen 11 bis 26 beschrieben.
Die oben angegebenen und weitere Ziele und Eigenschaften der Erfindung werden deutlicher, und die Erfindung selbst wird am besten verstanden, wenn man auf die folgende Beschreibung einer Ausführung in Verbindung mit der begleitenden Zeichnung Bezug nimmt, wobei die Figur schematische Darstellungen einer Client- und einer Server-Einrichtung, sowie die Nachrichten, die zwischen ihnen zur Realisierung des Verfahrens der Erfindung ausgetauscht werden, darstellt.
Das Verfahren der Erfindung betrifft ein Verfahren zur abgesicherten und zuverlässigen Bereitstellung von Diensten von einem Server S zu einem Client C. Die Dienst-Daten selbst können zum Beispiel von einem Inhaltsanbieter CP an den Server S geliefert werden. Im Gegensatz zu z.B. dem OMA-Download-Mechanismus, bei dem ganze Dateien zunächst vom Server zum Client heruntergeladen werden müssen, bevor sie vom Client aktiviert werden können, wird der Server S den zu liefernden Dienst zunächst in eine Sequenz von Blöcken umsetzen. Dies wird in dem Gerät SEQ durchgeführt, das somit die gesamte Dienst-Datei, die vom Dienstanbieter bereitgestellt wird, von zum Beispiel einem Datenpuffer SDB im Server S bekommt und das diese gesamte Dienst-Datei, die durch den dicken Pfeil dargestellt wird, in eine Sequenz von Blöcken umwandelt, die durch den dicken, mit Blöcken dargestellten Pfeil schematisch dargestellt wird. Diese Blöcke werden an ein Server-Inhalts-Abfertigungs-Modul SCDM geliefert. Dieses Modul ist in der Lage, mit anderen Geräten, wie z.B. dem Client C, zu kommunizieren.
Der Server S enthält weiterhin einen Deskriptor-Generator DG, der für jeden Block oder für jede Gruppe von Blöcken, die getrennt zu übertragen ist, pro Block oder Gruppe von Blöcken einen Download-Deskriptor erzeugt. Dieser Block-Download-Deskriptor enthält für jeden zu übertragenden Block Daten, wie z.B. eine Kennung, die individuelle Größe des Blocks, den Ort, der anzeigt, von wo der Block abzurufen ist und optional eine Anforderung für entweder eine Bestätigung oder einen Fehlerbericht, abhängig davon, ob der Client den Block als mit ausreichender Qualität abgerufen ansieht, um mit dem Rest des Dienstes fortzufahren, und optional eine Anforderung nach einer erneuten Verschlüsselung, die in einem weiteren Abschnitt erläutert wird. In manchen Ausführungen, wie z.B. der in der Figur gezeigten, enthält der Block-Deskriptor auch Information über die Benutzerrechte, die mit DRMn bezeichnet wird, und die zum Beispiel aus Digital Rights Management Information bestehen kann, wie in "Open Mobile Alliance – OMA DRM architecture Specification Version 1.0 of July 2003" spezifiziert. Diese Information über die Benutzerrechte kommt von einer Server-DRM-Einrichtung, die mit DRMS bezeichnet wird, und wird in einem weiteren Abschnitt näher erläutert.
Für Streaming-Dienste beginnt das Verfahren mit der Übertragung der Deskriptoren der ersten beiden Blöcke des Dienstes. Nach der Übertragung der Deskriptoren für Block 1 und 2 durch den Server und Empfang durch den Client kann der Client damit fortfahren, dass er diese Blöcke vom Inhalts-Abfertigungs-Modul im Server abruft. Dieser Abruf kann eine erste Anforderung für die ersten beiden Datenblöcke umfassen, worauf die Lieferung dieses ersten und zweiten Datenblocks durch den Server folgt. Dies ist in der Figur nicht gezeigt; in manchen Ausführungen sendet der Server die Informationsblöcke sofort zum Client, nachdem er die Download-Deskriptoren für diese Blöcke gesendet hat. Wenn der Client entscheidet, dass der erste der beiden Datenblöcke mit ausreichender Qualität geliefert wurde, um mit dem Rest des Dienstes fortzufahren, antwortet der Client nach dem Empfang des Endes dieses ersten Blocks, vorzugsweise aber nicht notwendigerweise vor dem Ende des Abrufs des zweiten Blocks, indem er eine Bestätigungs-Nachricht eines ersten Typs erzeugt, welche den Empfang dieses ersten Blocks betrifft, und zum Server sendet. Der Server S, der diesen ersten Typ von Bestätigungs-Nachricht für Block 1 empfängt, fährt dann sofort damit fort, dass er einen Deskriptor für den nächsten Block 3 erzeugt, während dieser Server auch noch mit dem Senden der Daten für Block 2 beschäftigt sein kann.
Die Übertragung der Blöcke vom Server zum Client wird vom Server-Inhalts-Abfertigungs-Modul SCDM durchgeführt, wie in der Figur gezeigt wird.
In manchen Ausführungen kann der Server, um einen Deskriptor für Block 3 zu erzeugen, damit fortfahren, zunächst das Guthaben des Client zu überprüfen, zum Beispiel indem er diese Information von einem Guthaben-Agenten CA anfordert. Wenn dieses Guthaben noch hoch genug ist, so dass der Client noch einen nächsten Block 3 empfangen darf, erzeugt der Deskriptor-Generator DG im Server einen neuen Deskriptor für diesen nächsten Block 3. Abhängig von der Variante des betreffenden Verfahrens fragt der Deskriptor-Generator auch die Server-DRM-Einrichtung DRMS ab, um von diesem Modul die erforderliche Information über die Benutzerrechte für Block 3 zu erhalten, die anschließend in den Download-Deskriptor von Block 3 eingefügt werden.
In der in der Figur gezeigten Ausführung ist es der Deskriptor-Generator DG, der den Guthaben-Agenten zuerst abfragt und abhängig vom Ergebnis dieser Abfrage als nächstes die Server-DRM-Einrichtung DRMS abfragt. In anderen Ausführungen kann die Server-DRM-Einrichtung diesen Guthaben-Agenten CA autonom abfragen, so dass der Deskriptor-Generator nur mit der Server-DRM-Einrichtung DRMS kommuniziert. Für diese Ausführungen und für den Fall, dass die Server-DRM-Einrichtung vom Guthaben-Agenten die Information erhält, dass der Client nicht genug Guthaben hat, um diesen nächsten Block 3 zu empfangen, fügt die DRM-Einrichtung entweder diese Guthaben-Information zur vorhandenen DRM-Information hinzu, oder sendet überhaupt keine DRM-Information zum Deskriptor-Generator. Letzterer erzeugt somit einen Download-Deskriptor ohne DRM-Information, wobei wenn der Client dies erkennt, verhindert wird, dass der Client den Dienst weiter aktiviert. In anderen Ausführungen kann der Deskriptor-Generator auch verhindern, dass das SCDM weitere Blöcke sendet. In anderen Ausführungen und Varianten liefert DRM weiter Informationen über die Benutzerrechte an den Deskriptor-Generator DG, aber diese Information über die Benutzerrechte enthält dann zum Beispiel ein gesondertes Feld, dass anzeigt, dass der Benutzer nicht mehr das Recht hat, die empfangenen Datenblöcke zu aktivieren, zum Beispiel um weitere Blöcke des Spielfilms wiederzugeben.
Nach der Übertragung des Deskriptors für einen Block n, wobei dieser Deskriptor mit descn bezeichnet wird, und wobei dieser Schritt mit dem Pfeil 1 vom Server zum Client gezeigt wird, fährt der Client im Allgemeinen damit fort, den betreffenden Block n vom Server-Inhalts-Abfertigungs-Modul SCDM im Server abzurufen. Dieser Abruf-Schritt kann somit eine erste Anforderung für diesen Datenblock n enthalten (in der Figur nicht gezeigt), gefolgt durch die Lieferung des Datenblocks n, der mit blockn bezeichnet wird, durch den Server S. Letzterer wird in der Figur durch den dicken, mit Blöcken dargestellten Pfeil vom SCDM zu den Pufferspeicher-Mitteln B des Client schematisch gezeigt. Der Puffer überträgt diesen Block weiter zum Dienst-Aktivator A, der dann entscheidet, ob dieser Block n mit ausreichender Qualität geliefert wurde, um mit dem Rest des Dienstes fortzufahren. Wenn dieser Block mit ausreichender Qualität geliefert wurde, erzeugt er ein Steuersignal, das mit c11 bezeichnet wird, für das CMCM, das daraufhin reagiert, vorzugsweise vor dem Ende des möglicherweise bereits gestarteten Abrufs des nächsten Blocks n + 1 durch B, indem es eine Bestätigungs-Nachricht eines ersten Typs für diesen Block n erzeugt und sendet. Die Bestätigungs-Nachricht des ersten Typs für Block n wird mit confn bezeichnet und ihre Übertragung vom Client zum Server wird durch den dünnen Pfeil 3 dargestellt. Diese Nummer zeigt an, dass dieser Schritt den dritten in der bereits erwähnten Sequenz von Schritten betrifft.
In der Figur erzeugt die CMCM-Einrichtung des Client diesen ersten Typ von Bestätigungs-Nachricht bei Empfang eines Steuersignals c11 von den Dienst-Aktivator-Mitteln, welche den erfolgreichen Empfang von Datenblock n anzeigt. Es können jedoch auch andere Module im Client confn erzeugen. Auf ähnliche Weise ist es in der Figur das Deskriptor-Generator-Modul DG des Servers S, das diesen ersten Typ von Bestätigung confn empfängt, es können aber auch andere Kommunikations-Module des Servers dazu benutzt werden, diese Nachricht zu empfangen.
In der bereits beschriebenen Variante des Verfahrens und der zugehörigen Ausführung des Servers überprüft der Deskriptor-Generator DG bei Empfang der Bestätigungs-Nachricht confn vom Client zunächst autonom das Guthaben des Client, zum Beispiel indem er diese Information von einem Guthaben-Agenten CA anfordert. Dies wird durch Anforderungs-Signal s11 von DG nach CA und die Antwort-Nachricht s12 von CA nach DG, welche diese Guthaben-Information enthält, dargestellt. Wenn das Guthaben noch groß genug ist, einen nächsten Block n + 2 zu empfangen, fährt der Deskriptor-Generator DG damit fort, die Server DRM-Einrichtung DRMS abzufragen, um von diesem Modul die erforderliche Information über die Benutzerrechte für Block n + 2 zu erhalten, die anschließend in den Download-Deskriptor von Block n + 2 eingefügt wird. Dies wird schematisch in der Figur durch die Anforderungs-Nachricht s13 vom DG zum DRMS und die anschließende Antwort s14 vom DRMS zum DG, welche DRMn, die Information über Benutzerrechte für Block n, enthält, dargestellt. Wenn das Guthaben des Client nicht groß genug ist, fügt der Deskriptor-Generator entweder keine Information über die Benutzerrechte ein, oder fügt ein zusätzliches Feld zum Deskriptor hinzu, das angibt, dass kein Guthaben zur Verfügung steht. Möglicherweise wird auch ein Steuersignal zum SCDM gesendet, um die weitere Übertragung zu verhindern.
Es gibt noch weitere Varianten des Verfahrens, in denen die Information über die Benutzerrechte nie in den Deskriptor aufgenommen wird, und bei denen sogar die Abfrage des Guthaben-Agenten nicht durchgeführt wird. In noch anderen Varianten des Verfahrens wird die Guthaben-Information in den Deskriptor eingefügt oder zu den Daten-Dienst-Blöcken selbst hinzugefügt. Diese Ausführungen sind in der Figur nicht gezeigt.
Es bleibt aber, dass bei Empfang des ersten Typs der Bestätigungs-Nachricht für Block n der Server damit fortfährt, bereits für Block n + 2 einen Deskriptor zu erzeugen. Dieser nächste Deskriptor kann zu einem zweiten Typ der Bestätigungs-Nachricht vom Server zum Client gehören, dies ist aber nicht zwingend erforderlich.
Der Client selbst enthält ein Client-Kommunikations-Mittel CMCM und ein Daten-Empfangs-Modul oder Puffer-Mittel B. Das Client-Kommunikations-Mittel CMCM empfängt vom Server den Deskriptor oder die Nachrichten, die diesen Deskriptor enthalten, entnimmt falls nötig den Deskriptor oder die Guthaben-Information daraus und entnimmt weiterhin aus dem Deskriptor die Information bezüglich des Blocks oder der Blöcke, die folgen. Diese Information umfasst eine Block-Kennung, die Größe des betreffenden Blocks und abhängig von der Variante des Verfahrens auch Informationen über die Benutzerrechte, wie z. B. DRM-Information und möglicherweise auch eine Anzeige des Teilnehmer-Guthabens, wenn sie in der Nachricht vom Server nicht gesondert vorhanden ist. In einigen Ausführungen kann die Guthaben-Information in der Tat auch zur Information über die Benutzerrechte gehören, während sie in anderen Ausführungen als getrennte Information bereitgestellt wird.
Im Client C wird die Information über die Benutzerrechte und/oder die Guthaben-Information mit einem Signal c10 weiter zu einer Client-DRM-Einrichtung übertragen, die in der Figur mit DRMC bezeichnet ist. Für anderen Varianten der Verfahren, die durch andere Ausführungen des Client implementiert werden (nicht gezeigt), wird die DRM-Information und/oder die Guthaben-Information an die Datenblöcke selbst angehängt oder in sie aufgenommen. In diesem Fall muss diese DRM-Information und/oder Benutzer-Guthaben-Information dann aus den Datenblöcken entnommen oder von ihnen abgetrennt werden. Für diese anderen Ausführungen muss die Client-DRM-Einrichtung mit den Puffer-Mitteln B gekoppelt oder sogar in sie aufgenommen werden. In jedem Fall wird die spezielle DRM- und/oder Guthaben-Information (vorübergehend) in der Client-DRMC-Einrichtung gespeichert, die sie mit dem Signal c13 weiter an den Dienst-Aktivator A liefert.
Abhängig von den in der DRM-Information beschriebenen Benutzungs-Regeln aktiviert oder sperrt der DRM-Agent ein Dienst-Aktivierungs-Mittel A, um auf den Block des betreffenden Dienstes zu wirken. Die von der DRM-Information freigegebenen Aktionen können die Ausführung, Speicherung, Weiterleitung, usw. umfassen. Jeder Dienst-Block wird vom Server durch das Datenempfangs-Modul B im Client abgerufen. Bei einem erfolgreichen Empfang des betreffenden Blocks, dessen Überprüfung von den Dienst-Aktivierungs-Mitteln A durchgeführt wird, steuert dieses Modul über das Signal c11 das Nachrichten-Kommunikations-Modul CMCM des Client an, das daraufhin die erste Bestätigungs-Nachricht für den betreffenden Block erzeugt.
Der Deskriptor für den ersten Block enthält weiterhin Informationen bezüglich der Gesamtgröße der kompletten Streaming-Datei und weitere Details über den Dienst selbst, wie z.B. die erforderliche Plattform/Software zur Aktivierung des Dienstes, usw. Diese Details gehen jedoch über die vorliegende Erfindung hinaus und werden daher nicht näher erläutert.
Die Erfindung ist somit besonders für die kontrollierte Bereitstellung und die zugehörige Gebührenerfassung für alle Arten von Diensten geeignet, da sie es dem Server erlaubt, die Steuerung und Gebührenerfassung pro Block durchzuführen. Darüber hinaus erlaubt es die Ausführung, bei der die Deskriptoren vorher erzeugt und übertragen werden und der Dienst gestartet wird, bevor ein gesamter Block heruntergeladen wurde, dem Client, den Dienst, zum Beispiel die Wiedergabe eines Spielfilms, vom ersten heruntergeladenen Block an zu aktivieren. Diese Ausführung ist somit besonders für Streaming-Dienste geeignet. Die Gebührenerfassung findet über den Guthaben-Agenten statt, der gleichzeitig indirekt pro Block den Beginn oder das Ende der Dienst-Aktivierung auf der Seite des Client steuert, indem er es entweder zulässt, dass die Information über die Benutzerrechte eingefügt wird, oder nicht, indem er die Information über die Benutzerrechte so anpasst, dass sie diese Freigabe-Guthaben-Information enthalten oder nicht, oder indem er einfach diese Freigabe-Guthaben-Information in den Deskriptor oder in die Nachricht, die den Deskriptor enthält, einfügt. Wenn die Client-DRMC-Einrichtung die Information erkennt, dass der Client die nächsten Blöcke des Dienstes nicht mehr aktivieren darf, blockiert oder sperrt diese DRMC-Einrichtung somit den Dienst-Aktivator, der den Dienst nicht weiter aktivieren darf und zum Beispiel einen Spielfilm an einem bestimmten Zeitpunkt anhält.
Die Erfindung kann weiter verfeinert werden, indem die Blöcke zusätzlich verschlüsselt werden. Dies erfolgt im Server durch eine Server-Verschlüsselungs-Einrichtung SED. Der Verschlüsselungs-Schlüssel kann für alle Blöcke des Dienstes derselbe oder von Block zu Block unterschiedlich sein. Für Streaming-Dienste muss der Verschlüsselungs-Schlüssel für einen bestimmten Block vorzugsweise vor dem Block selbst an den Client geliefert werden, so dass der Client in die Lage versetzt wird, den Dienst sofort bei Empfang der Blöcke mit dem Inhalt zu aktivieren, wie es für Streaming-Dienste erforderlich ist. Der Verschlüsselungs-Schlüssel kann als Teil des Deskriptors für den speziellen Block, möglicherweise als Teil der DRM-Information gesendet werden, oder er kann in einer gesonderten Schlüssel-Nachricht gesendet werden. In der Figur ist die Situation gezeigt, in der die SED die Schlüssel-Information über die Nachricht s15 an den Deskriptor-Generator DG liefert, der den Schlüssel entsprechend in den Deskriptor einsetzt.
Für den Fall, dass die gesamte Streaming-Datei mit demselben Schlüssel verschlüsselt wird, kann der Schlüssel zu Beginn als eine gesonderte Anfangs-Nachricht oder im Deskriptor des ersten Blocks gesendet werden. Für den Fall, dass für eine verbesserte Sicherheit und Kontrollierbarkeit ein bestimmter Schlüssel für jeden Block vorgesehen ist, wird dieser Schlüssel nach der Guthaben-Überprüfung gesendet, somit entweder im Deskriptor oder in einer gesonderten Nachricht, aber im Fall von Streaming-Diensten vor dem Abruf des entsprechenden Blocks. Für den Fall, dass die Guthaben-Überprüfung anzeigt, dass der Client nicht genug Guthaben zur Aktivierung der nächsten Blöcke hat, kann der Server optional entscheiden, die Verschlüsselung neu durchzuführen, ohne den neuen Schlüssel zum Client zu senden. In diesem Fall muss ein Steuersignal zwischen dem Deskriptor-Generator und der Verschlüsselungs-Einrichtung SED vorgesehen werden. Hierdurch erhöht sich die Kontrollierbarkeit der vorliegenden Erfindung.
Im Client wird die Verschlüsselungs-Schlüssel-Information im Client Message Communication Module CMCM empfangen, darin entnommen und an eine Client-Entschlüsselungs-Einrichtung D gesendet, die entweder zum Dienst-Aktivierungs-Mittel A gehört oder eine gesonderte Einheit ist. In der Figur ist sie als gesonderte Einheit dargestellt, die mit den Puffer-Mitteln B gekoppelt ist. Natürlich sind andere Implementationen möglich.
Dieses Verfahren erlaubt es somit dem Client C, Blöcke zu identifizieren, die bei der Übertragung verloren gehen. Weiterhin können der Server S und der angeschlossene Inhalts-Anbieter CP unberechtigte Benutzer herauswerfen, indem sie die Kreditwürdigkeits-Information des Client im Deskriptor ändern, indem sie ihnen den falschen Schlüssel geben, oder indem sie jeden Block neu verschlüsseln und ihnen den Schlüssel nicht mehr liefern. Die Benutzer können nicht mehr betrügen, indem sie zum Beispiel nach dem Ende der Übertragung mitteilen, dass sie nur Teile der Blöcke erhalten haben, da nun eine explizite Bestätigungs-Meldung für jeden gesonderten Block erforderlich ist. Weiterhin versetzen diese Mechanismen die Server und die Inhaltsanbieter in die Lage, das Teilnehmerverhalten besser nachzuverfolgen. Der Mechanismus arbeitet auch im Fall, dass einige Blöcke leer sind, z.B. während einer Sequenz getrennter kurzer Clips mit Pausen dazwischen.
Das Verfahren kann auf jede Art von Dienst angewendet werden, entweder Streaming-Dienste oder nicht, es ist auch für progressive Lieferungs-Dienste geeignet, kann aber auch auf übliche herkömmliche Downloads angewendet werden, wobei die Dienst-Aktivierung nur nach dem kompletten Download stattfindet, und sie ist auf Multicast/Broadcast-Übertragungen zu einer großen Gruppe von Teilnehmern anwendbar. Das Verfahren ist vom Netzwerk unabhängig, d.h. ist sowohl auf Festnetze, als auch auf Mobilfunknetze anwendbar.
Eine Vereinfachung gibt es für den Fall, dass alle Blöcke dieselbe Größe haben und für den Fall, dass der Server überprüft hat, dass der Client ein ausreichendes Guthaben hat, die gesamte Dienst-Datei herunterzuladen und zu aktivieren. Die Bestätigung pro Block garantiert jedoch, dass im Auge behalten wird, welche Blöcke vom Client tatsächlich abgerufen wurden und welche nicht.
Obwohl die Prinzipien der Erfindung oben in Verbindung mit einer speziellen Vorrichtung beschrieben wurden, muss deutlich verstanden werden, dass diese Beschreibung nur als Beispiel erfolgt und nicht als Einschränkung des Umfangs der Erfindung, wie in den beigefügten Ansprüchen definiert.

Claims

Verfahren zur kontrollierten Bereitstellung eines Dienstes von einem Server (S) an einen Client (C), wobei das Verfahren folgende Schritte umfasst: – Senden eines Download-Deskriptors durch den Server (S) zum Client (C), – Auf der Basis des Download-Deskriptors Abruf des Dienstes durch den Client vom Server (S), – Senden eines ersten Typs von Bestätigungs-Nachricht durch den Client (C) zum Server (S), – Aktivierung des Dienstes durch den Client (C), dadurch gekennzeichnet, dass – der Dienst im Server (S) zunächst in eine Sequenz einzelner Blöcke umgewandelt wird, – der Download-Deskriptor (descn) und der erste Typ von Bestätigungs-Nachricht (confn) erzeugt werden und pro mindestens einem einzelnen Block der Sequenz gesendet werden, wobei die Bestätigungs-Nachricht des ersten Typs (confn) bei Empfang mindestens eines Blocks durch den Client (C) gesendet wird.
Verfahren gemäß Anspruch 1, wobei die Aktivierung von Block n beginnt, bevor der gesamte Inhalt von Block n empfangen wurde, wobei der erste Typ von Bestätigungs-Nachricht (confn) für Block n erzeugt wird, wenn Block n vollständig empfangen wurde, und wobei bei Empfang der Bestätigungs-Nachricht des ersten Typs (confn) für Block n durch den Server (S) der Download-Deskriptor (descn + 2) für Block n + 2 vom Server (S) erzeugt und gesendet wird.
Verfahren gemäß Anspruch 1 oder 2, wobei der Download-Deskriptor (descn) für einen Block (blockn) oder die Nachricht, die den Download-Deskriptor für den Block enthält, weiterhin Informationen über Benutzerrechte (DRMn) für den Block (blockn) zur Benutzung durch eine Client-DRM-Vorrichtung (DRMC) in dem Client enthält, auf deren Basis die Client-DRM-Vorrichtung (DRMC) die Aktivierung des Blocks (blockn) durch den Client (C) autorisieren kann.
Verfahren gemäß Anspruch 1, 2 oder 3, wobei bei Empfang der Bestätigungs-Nachricht des ersten Typs (confn) für den Block n durch den Server (S) der Server eine Überprüfung des Guthabens des Client durchführt, und entsprechend in den Download-Deskriptor (descn + 2) für Block n + 2 Guthaben-Informationen einfügt oder die Guthaben-Informationen zu Block n + 2 hinzufügt.
Verfahren gemäß Anspruch 3, wobei die Informationen über Benutzerrechte (DRMn) für einen Block an den Block (blockn) angefügt oder in ihn eingefügt werden.
Verfahren gemäß einem beliebigen der obigen Ansprüche 2 bis 4, wobei der Download-Deskriptor für den Block n + 2 in eine Bestätigungs-Nachricht eines zweiten Typs eingefügt wird, die von dem Server (S) erzeugt wird, wenn er den ersten Typ von Bestätigungs-Nachricht (confn) für Block n empfängt.
Verfahren gemäß einem beliebigen der obigen Ansprüche 1 bis 6, wobei die einzelnen Blöcke in dem Server (S) weiter verschlüsselt werden.
Verfahren gemäß Anspruch 7, wobei der Download-Deskriptor (descn) für einen Block (blockn) den Verschlüsselungs-Schlüssel für den Block enthält.
Verfahren gemäß Anspruch 8, wobei der Verschlüsselungs-Schlüssel für einen Block in einer gesonderten Nachricht übertragen wird.
Verfahren gemäß einem beliebigen der obigen Ansprüche 1 bis 9, wobei zur Aktivierung eines neuen Dienstes das Verfahren damit beginnt, die Download-Deskriptoren für die ersten beiden Blöcke der Sequenz des neuen Dienstes zu senden.
Server (S) zur kontrollierten Bereitstellung eines Dienstes, wobei der Server (S) einen Deskriptor-Generator (DG) zur Erzeugung und zum Senden eines Download-Deskriptors zu einem Client (C) enthält, und zum Empfang eines ersten Typs von Bestätigungs-Nachricht von dem Client (C), dadurch gekennzeichnet, dass – der Server (S) weiterhin eine Sequenzierungs-Vorrichtung (SEQ) enthält, um den Streaming-Dienst in eine Sequenz einzelner Blöcke umzuwandeln, – der Deskriptor-Generator (DG) angepasst ist, den Download-Deskriptor (descn) für mindestens einen einzelnen Block (blockn) der Sequenz zu erzeugen und zu senden und den ersten Typ von Bestätigungs-Nachricht (confn) für mindestens einen Block (blockn) der Sequenz zu empfangen.
Server gemäß Anspruch 11, wobei der Deskriptor-Generator (DG) den Download-Deskriptor (descn + 2) für Block n + 2 bei Empfang der Bestätigungs-Nachricht des ersten Typs (confn) für Block n von dem Client (C) erzeugt und sendet.
Server (S) gemäß Anspruch 11 oder 12, wobei der Deskriptor-Generator (DG) weiterhin angepasst ist, Informationen über Benutzerrechte (DRMn) bezüglich eines bestimmten Blocks (blockn) von einer Server-DRM-Vorrichtung (DRMS) des Servers (S) zu erhalten und die Informationen über Benutzerrechte (DRMn) für den bestimmten Block in den Download-Deskriptor (descn) für den bestimmten Block (blockn) oder in eine Nachricht, die den Download-Deskriptor (descn) für den bestimmten Block (blockn) enthält, einzufügen.
Server (S) gemäß Anspruch 11, 12 oder 13, wobei bei Empfang des Bestätigungs-Signals des ersten Typs (confn) für den Block n durch den Deskriptor-Generator (DG) der Deskriptor-Generator angepasst ist, eine Überprüfung des Guthabens des Client durchzuführen, und entsprechend in den Download-Deskriptor (descn + 2) für Block n + 2 Guthaben-Informationen einzufügen.
Server (S) gemäß Anspruch 13 oder 14, wobei der Server (S) Mittel zum Einfügen oder Anhängen der Informationen über Benutzerrechte (DRMn) oder der Guthaben-Informationen für einen bestimmten Block (blockn) an den bestimmten Block enthält.
Server (S) gemäß einem beliebigen der obigen Ansprüche 11 bis 15, wobei der Deskriptor-Generator (DG) angepasst ist, einen zweiten Typ von Bestätigungs-Nachricht zu erzeugen, wenn der erste Typ von Bestätigungs-Nachricht (confn) für den Block n empfangen wird, und den Download-Deskriptor (descn + 2) für den Block n + 2 in die Bestätigungs-Nachricht des zweiten Typs aufzunehmen.
Server (S) gemäß einem beliebigen der obigen Ansprüche 11 bis 16, wobei der Server eine Verschlüsselungs-Vorrichtung (SED) zur Verschlüsselung der einzelnen Blöcke der Sequenz enthält.
Server (S) gemäß Anspruch 17, wobei der Deskriptor-Generator (DG) angepasst ist, den Verschlüsselungs-Schlüssel für einen Block in den Download-Deskriptor des Blocks, in die Nachricht, die den Download-Deskriptor für den Block enthält, oder in eine gesonderte Nachricht aufzunehmen.
Server (S) gemäß einem beliebigen der obigen Ansprüche 11 bis 18, wobei der Deskriptor-Generator (DG) mit der Erzeugung und dem Senden des Download-Deskriptors für die ersten beiden Blöcke eines neuen Dienstes beginnt.
Client (C) zum Empfang und zur Ausführung eines Dienstes, wobei der Client Mittel zur Client-Kommunikation (CMCM), um einen Download-Deskriptor von einem Server (S) zu empfangen, und Puffer-Mittel (B) zum Empfang des Dienstes von dem Server (S) enthält, wobei das Client-Kommunikations-Mittel (CMCM) weiterhin angepasst ist, um auf der Basis des Download-Deskriptors den Dienst abzurufen und bei erfolgreichem Empfang des Dienstes durch das Puffer-Mittel (B) einen ersten Typ von Bestätigungs-Nachricht an den Server zu erzeugen, wobei der Client weiterhin Dienst-Aktivierungs-Mittel (A) enthält, um den Dienst zu aktivieren, dadurch gekennzeichnet, dass – das Puffer-Mittel (B) weiterhin angepasst ist, von dem Server (S) eine Sequenz einzelner Blöcke des Dienstes zu empfangen – das Client-Kommunikations-Mittel (CMCM) weiterhin angepasst ist, pro mindestens einem Block (blockn) der Sequenz einen Download-Deskriptor (descn) zu empfangen, und pro mindestens einem Block (blockn) der Sequenz den ersten Typ von Bestätigungs-Nachricht (confn) zu erzeugen und zu senden, wobei die Bestätigungs-Nachricht des ersten Typs (confn) gesendet wird, wenn mindestens ein Block von dem Buffer-Mittel (B) erfolgreich empfangen wird.
Client (C) gemäß Anspruch 20, wobei das Dienst-Aktivierungs-Mittel (A) damit beginnt, einen Block n zu aktivieren, bevor der gesamte Inhalt von Block n von dem Puffer-Mittel (B) empfangen wurde und wobei der erste Typ von Bestätigungs-Nachricht (confn) für Block n erzeugt wird, wenn Block n vollständig empfangen wurde.
Client (C) gemäß Anspruch 20 oder 21, wobei das Client-Kommunikations-Mittel (CMCM) weiterhin angepasst ist, aus dem Download-Deskriptor (descn) für den mindestens einen Block (blockn) oder aus der Nachricht, die den Download-Deskriptor für den mindestens einen Block enthält, Informationen über die Benutzerrechte (DRMn) bezüglich des mindestens einen Blocks (blockn) zu entnehmen, um sie zu einer Client-DRM-Vorrichtung (DRMC) in dem Client zu liefern, der weiterhin so angepasst ist, die Informationen über die Benutzerrechte (DRMn) zu analysieren und abhängig vom Ergebnis der Analyse das Dienst-Aktivierungs-Mittel (A) zu autorisieren, den Block (blockn) auszuführen.
Client (C) gemäß Anspruch 20, 21 oder 22, der Mittel enthält, um Informationen über die Benutzerrechte zu entnehmen, die in dem Block enthalten sind oder an den Block angehängt sind, der in dem Puffer-Mittel (B) empfangen wurde.
Client (C) gemäß einem beliebigen der obigen Ansprüche 20 bis 23, wobei das Client-Kommunikations-Mittel (CMCM) weiterhin angepasst ist, einen zweiten Typ von Bestätigungs-Nachricht von dem Server zu empfangen und daraus den Download-Deskriptor zu entnehmen.
Client (C) gemäß einem beliebigen der obigen Ansprüche 20 bis 24, der weiterhin eine Entschlüsselungs-Vorrichtung (D) enthält, die mit dem Puffer-Mittel (B) gekoppelt und angepasst ist, einzelne Blöcke aus dem Puffer-Mittel (B) zu entschlüsseln, um sie weiter zum Dienst-Aktivierungs-Mittel (A) zu senden.
Client (C) gemäß Anspruch 25, wobei das Client-Kommunikations-Mittel (CMCM) angepasst ist, einen Verschlüsselungs-Schlüssel für einen Block aus dem Download-Deskriptor für den Block zu entnehmen und den Verschlüsselungs-Schlüssel an die Verschlüsselungs-Vorrichtung (D) zu liefern.