DE112016003268T5

DE112016003268T5 - Systeme, Verfahren und Medien für Mediensitzungs-Parallelitätsmanagement mit wiederkehrenden Lizenzerneuerungen

Info

Publication number: DE112016003268T5
Application number: DE112016003268.4T
Authority: DE
Inventors: David Kimball Dorwin; Thomas William Inskip; Mark David Scott
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2015-07-20
Filing date: 2016-07-19
Publication date: 2018-04-12
Also published as: KR20180008716A; DE112016003268T8; US20230045822A1; US10552587B2; US20200184040A1; US11604856B2; JP6790169B2; WO2017015289A1; JP6522801B2; JP2018521407A; JP2019194854A; US20190180004A1; US12072958B2; KR102030645B1; US20170024548A1; US10198561B2

Abstract

Der offenbarte Gegenstand bezieht sich auf Systeme, Verfahren und Medien für Mediensitzungs-Parallelitätsmanagement mit wiederkehrender Lizenzerneuerung. Insbesondere bezieht sich der offenbarte Gegenstand auf die Verwendung wiederkehrender Lizenzerneuerungen für die Erkennung paralleler Wiedergabe und die Durchsetzung von Parallelitätslimits bei Videolieferdiensten und das Verwalten von Serverressourcen für den Umgang mit solchen wiederkehrenden Lizenzerneuerungen.

Description

Querverweis auf verwandte Anwendungen
Diese Anwendung beansprucht den Schutz des U.S.-Patents mit der Anwendungsnr. 15/213.624 , eingereicht am 19. Juli 2016, des vorläufigen U.S.-Patents mit der Anwendungsnr. 62/199.211 , eingereicht am 30. Juli 2015, und des vorläufigen U.S.-Patents mit der Anwendungsnr. 62/194.804 , eingereicht am 20. Juli 2015, von denen jedes hiermit in seiner Gesamtheit als Referenz verkörpert ist.
Technisches Gebiet
Der offenbarte Gegenstand bezieht sich auf Systeme, Verfahren und Medien für das Mediensitzungs-Parallelitätsmanagement mit wiederkehrender Lizenzerneuerung. Insbesondere bezieht sich der offenbarte Gegenstand auf die Verwendung wiederkehrender Lizenzerneuerungen für die Erkennung paralleler Wiedergabe und die Durchsetzung von Parallelitätslimits bei Videolieferdiensten und das Verwalten von Serverressourcen für den Umgang mit solchen wiederkehrenden Lizenzerneuerungen.
Allgemeiner Stand der Technik
Filme, Musik und andere Formen von Medieninhalten werden Computergeräten über das Internet von einer Vielzahl von Inhalteanbietern bereitgestellt. Aus verschiedenen Gründen werden einige dieser Inhalte geschützt, wozu eine Lizenz benötigt wird, die zumindest einige Rechte der Verwendung, des Abspielens und Kopierens und/oder des Vertriebs der verknüpften Medieninhalte identifiziert. Weitere Schutzvorkehrungen können verschiedene Levels oder Typen von Verschlüsselungsschutz beinhalten, die eines Schlüssels bedürfen, um die Medieninhalte zu entschlüsseln.
Außerdem kann ein Limit auf die Anzahl von parallelen Streaming-Verbindungen gesetzt werden, die einem bestimmten Benutzer gestattet wird aufzubauen. Das heißt, die Anzahl Geräte, die jeweils mit demselben Benutzerkonto authentifiziert sind, auf denen Medieninhalte simultan gestreamt und angesehen werden können, kann limitiert werden (z. B. auf insgesamt zwei Verbindungen pro Benutzerkonto, drei Verbindungen pro Benutzerkonto über vier Geräte hinweg etc). Um ein solches Limit durchzusetzen kann, wenn ein Benutzer eine neue Streaming-Verbindung anfragt, die Anzahl der mit diesem Benutzer verknüpften, parallel aufgebauten Streaming-Verbindungen festgestellt werden und, wenn diese Anzahl die Zahl maximal erlaubter paralleler Streaming-Verbindungen überschreitet, die Anfrage für eine neue Streaming-Verbindung zurückgewiesen werden. Die Verwaltung der Durchsetzung von Richtlinien, einschließlich dieses Limits, ist eine schwierige Aufgabe.
Verschiedene Ansätze versuchen das Problem der Durchsetzung des Parallellimits anzugehen, indem erfordert wird, dass ein mit dem bestimmten Benutzer verknüpftes Benutzergerät eine Nachricht an einen Server sendet, sobald der bestimmte Benutzer das Ansehen eines Werks mit Medieninhalten beendet. Jedoch können solche Ansätze die Client-Implementierung und die Gerätearchitektur behindern und können dauerhaften Speicherplatz auf dem Endgerät erfordern. Das heißt, diese Ansätze verlagern die Abhängigkeit auf Parallel-Limitdurchsetzung auf jedes einzelne Endgerät. Hinzu kommt, dass diese Ansätze allgemein als unzuverlässig betrachtet werden, weil das Endgerät die Wiedergabe in einer „ungeordneten“ Weise durch Gerätefehler (Absturz), Stromausfall, Netzwerkausfall etc. beenden kann.
Entsprechend ist es wünschenswert, neue Systeme, Verfahren und Medien für das Mediensitzungs-Parallelitätsmanagement mit wiederkehrenden Lizenzerneuerungen bereitzustellen.
Kurzdarstellung
In Übereinstimmung mit einigen Implementierungen des offenbarten Gegenstandes werden Mechanismen für das Mediensitzungs-Parallelitätsmanagement bereitgestellt.
In Übereinstimmung mit einigen Implementierungen wird ein System für die Parallelitätserkennung und -durchsetzung bereitgestellt, welches sich aus wenigstens einem Server zusammensetzt, der konfiguriert wurde, um: eine Anfrage für eine einem Medieninhaltegegenstand, der auf einem Medienwiedergabegerät dargestellt werden soll, zugehörige Medieninhaltelizenz zu empfangen, wobei die Anfrage für die Medieninhaltelizenz mit einem Benutzerkonto verknüpft ist; als Antwort auf die Medieninhaltelizenz-Anfrage auf das Medienwiedergabegerät einen oder mehrere mit dem Medieninhaltegegenstand verknüpfte Schlüssel sowie eine Lizenz, die sich aus einer Richtlinie einschließlich einer zeitlich begrenzten Lizenzdauer und einem Erneuerungsanfrageintervall zusammensetzt, zu übertragen; zu einem Zeitpunkt innerhalb des Erneuerungsanfragenintervalls eine zu dem Medieninhaltegegenstand, der auf dem Medienwiedergabegerät dargestellt wird, zugehörige Anfrage für eine Lizenzerneuerung zu empfangen; festzustellen, ob die Lizenzerneuerung für den Medieninhaltegegenstand entsprechend der Mediensitzungsparallelität über eine Vielzahl von mit dem Benutzerkonto verknüpften Medienwiedergabegeräten erfolgen soll, wobei die Feststellung das Abfragen eines Datensatzes von Lizenzerneuerungen umfasst, die während einer gegebenen Zeitspanne für das Benutzerkonto erteilt wurden; und die Lizenzerneuerungen auf das Medienwiedergabegerät entsprechend des mit dem Benutzerkonto verknüpften Lizenzerneuerungsdatensatzes zu übertragen.
In einigen Implementierungen wird der wenigstens eine Server weitergehend konfiguriert, um wenigstens einen Teil der begrenzten Lizenzdauer und des Erneuerungsanfrageintervalls zu modifizieren. In einigen Implementierungen wird die Modifizierung als Reaktion auf die Überprüfung des Datensatzes von Lizenzen hin durchgeführt, die während einer gegebenen Zeitspanne für das Benutzerkonto erteilt wurden und auf die Feststellung hin, dass der Datensatz von Lizenzerneuerungen die Unterdrückung von Lizenzerneuerungsanfragen durch die Vielzahl von mit dem Benutzerkonto verknüpften Medienwiedergabegeräten anzeigt. In einigen Implementierungen wird die Modifizierung als Reaktion auf das Feststellen eines Serverausfalls hin durchgeführt.
In einigen Implementierungen hat, als Reaktion auf die Feststellung, dass ein oder mehrere Schlüssel in der Lizenz widerrufen werden sollen, die mit der Lizenzierungserneuerung verknüpfte, begrenzte Lizenzdauer eine Dauer gleich Null oder andere Mittel und Wege, um den Wegfall der Medienrechte durchsetzen.
In einigen Implementierungen wird der wenigstens eine Server weitergehend konfiguriert, um die Lizenz der begrenzten Lizenzdauer für den Medieninhaltegegenstand auf das Medienwiedergabegerät automatisch zu übertragen, während parallel der Wegfall einer zuvor erteilten Lizenz innerhalb des Datensatzes angezeigt wird.
In einigen Implementierungen wird der wenigstens eine Server weitergehend konfiguriert, um: den Datensatz auf während der gegebenen Zeitspanne für das Benutzerkonto erneuert erteilter Lizenzen zu überprüfen; einen anzuwendenden Durchsetzungsweg aus einer Vielzahl von Durchsetzungsmöglichkeiten für das Benutzerkonto zu bestimmen; und den bestimmten Durchsetzungsweg bei Erteilung der Lizenzerneuerung anzuwenden, wobei wenigstens ein Teil der begrenzen Lizenzdauer und des Erneuerungsanfrageintervalls angepasst wird.
In einigen Implementierungen wird der wenigstens eine Server weitergehend konfiguriert, um an eine auf dem Medienwiedergabegerät ausgeführte Medienwiedergabeanwendung eine Vielzahl von Lizenzierungsservern für die Handhabung der Lizenzerneuerungsanfrage zu übertragen, wobei die Medienwiedergabeanwendung die Anfrage der Lizenzerneuerung an einen ersten Lizenzierungsserver der Vielzahl von Lizenzierungsservern überträgt und, auf die Feststellung hin, dass der erste Lizenzierungsserver nicht erreichbar ist, und vor dem Auslaufen der Lizenz, eine Anfrage an einen zweiten Lizenzierungsserver der Vielzahl von Lizenzierungsservern überträgt, bis dass die Lizenzierungserneuerung für die Medieninhaltelizenz empfangen wurde.
In einigen Implementierungen wird der wenigstens eine Server weitergehend konfiguriert, um:
durch das Zählen der Anzahl mit dem Benutzerkonto während der gegebenen Zeitspanne verknüpfter Lizenzerneuerungen festzustellen, ob die Lizenzerneuerung erteilt werden soll; und die Lizenzerneuerung entsprechend der Zählung auf das Medienwiedergabegerät zu übertragen.
In einigen Implementierungen wird der wenigstens eine Server weitergehend konfiguriert um festzustellen, ob ein Notfallerneuerungsmodus aktiv werden soll, der die Lizenzerneuerung automatisch als Reaktion darauf erteilt, dass auf den Datensatz mit Lizenzerneuerungen nicht zugegriffen werden kann. In einigen Implementierungen wird der Notfallerneuerungsmodus aufgrund von Ressourceninformationen aktiv, die mit dem einen oder den mehreren Servern verknüpft sind, welche eine initiale Lizenzierungsanfrage oder eine Erneuerungsanfrage bedienen. In einigen Implementierungen beinhaltet die Lizenzerneuerung eine zweite Lizenzdauer, die größer ist als die erste Lizenzdauer. In einigen Implementierungen wird der Notfallerneuerungsmodus aktiv als Reaktion darauf, dass eine Anzahl an Kommunikationsausfällen mit dem Server größer ist als ein Grenzwert, wobei der Hardwareprozessor weitergehend konfiguriert wird, um die Lizenzerneuerung an einen anderen Server zu übertragen, welcher eine initiale Lizenzierungsanfrage oder eine Erneuerungsanfrage bedient. In einigen Implementierungen umfasst das System des Weiteren das Feststellen, ob ein Nur-Erneuerungsmodus aktiv wird, der die Lizenzerneuerung als Reaktion auf die Erkenntnis erteilt, dass ein Server, der dahingehend konfiguriert wurde, eine initiale Lizenzierungsanfrage zu bedienen, nicht erreichbar ist.
In Übereinstimmung mit einigen Implementierungen wird ein System für die Parallelitätserkennung und -durchsetzung bereitgestellt, das aus wenigstens einem Server besteht, der einen Hardwareprozessor beinhaltet, welcher konfiguriert wurde, um: eine Anfrage von einem Medienwiedergabegerät verknüpft mit einem Benutzerkonto für eine Initiallizenz korrespondierend zu einem Medieninhaltegegenstand zu empfangen; das Benutzerkonto in einen Erkennungsmodus zu versetzen, der eine initiale Lizenzdauer und ein initiales Lizenzerneuerungsintervall für die Initiallizenz festlegt; die Initiallizenz an das Medienwiedergabegerät zu übertragen, wobei die Initiallizenz die initiale Lizenzdauer und das initiale Lizenzerneuerungsintervall hat; festzustellen, ob das Benutzerkonto mit verdächtigem Verhalten assoziiert wird, welches auf die Unterdrückung von Erneuerungsanfragen schließen lässt; das Benutzerkonto in einen strengeren Durchsetzungsmodus zu versetzen, welcher eine Erneuerungs-Lizenzdauer festlegt, die kürzer als die initiale Lizenzdauer oder ein Lizenz-Erneuerungsintervall, das kürzer als das anfängliche Lizenz-Erneuerungsinterval ist; und eine Lizenzerneuerung an das Medienwiedergabegerät zu übertragen, wobei die Lizenzerneuerung wenigstens eines von Erneuerungslizenzdauer und Lizenzerneuerungsintervall hat.
In einigen Implementierungen ist die initiale Lizenzdauer länger als eine Inhaltedauer des Medieninhaltegegenstands. In einigen Implementierungen sind wenigstens eine initiale Lizenzdauer und die Erneuerungslizenzdauer kürzer als die Inhaltedauer des Medieninhaltegegenstands. In einigen Implementierungen handelt es sich bei der Erneuerungslizenzdauer um eine vorbestimmte Zeitspanne, welche weniger als so lang wie die Inhaltedauer des Medieninhaltegegenstands. In einigen Implementierungen ist das Lizenzerneuerungsintervall kürzer als das initiale Erneuerungsintervall.
In einigen Implementierungen umfasst das Feststellen, ob ein Benutzerkonto mit verdächtigem Verhalten assoziiert wird, weitergehend das Erkennen, dass das Benutzerkonto eine Vielzahl von Lizenzanfragen über eine Vielzahl von mit dem Benutzerkonto verknüpften Medienwiedergabegeräten hinweg generiert.
In einigen Implementierungen umfasst das Feststellen, ob ein Benutzerkonto mit verdächtigem Verhalten assoziiert wird, weitergehend das Erkennen, dass das Benutzerkonto keine Lizenzerneuerungsanfragen innerhalb einer bestimmten Zeitspanne generiert.
In einigen Implementierungen umfasst das Feststellen, ob ein Benutzerkonto mit verdächtigem Verhalten assoziiert wird, weitergehend das Erkennen, dass das Benutzerkonto eine Vielzahl von Lizenzanfragen für denselben Medieninhaltegegenstand auf demselben Medienwiedergabegerät generiert.
In einigen Implementierungen umfasst das Feststellen, ob ein Benutzerkonto mit verdächtigem Verhalten assoziiert wird, weitergehend das Erkennen einer verdächtigen Erneuerungsanfrage, wobei eine mit der verdächtigen Erneuerungsanfrage verknüpfte Zeitspanne näher der initialen Lizenzdauer als dem initialen Erneuerungsintervall liegt.
In einigen Implementierungen umfasst das System des Weiteren als Reaktion auf den Ablauf einer bestimmten Zeitspanne das Versetzen des Benutzerkontos in einen Durchsetzungsmodus, der weniger restriktiv als ein strengerer Durchsetzungsmodus ist.
Kurzbeschreibung der Zeichnungen
Verschiedene Aufgaben, Merkmale und Vorteile des offenbarten Gegenstandes können vollständiger unter Bezugnahme auf die folgende ausführliche Beschreibung des offenbarten Gegenstandes erfasst werden, wenn sie in Zusammenhang mit den folgenden Zeichnungen betrachtet werden, in denen gleiche Bezugszeichen gleiche Elemente identifizieren.
1 zeigt ein anschauliches Beispiel eines Datenstroms einschließlich der Anfragen und Antworten zwischen einem Medienwiedergabegerät und einem oder mehreren Lizenzservern in Übereinstimmung mit einigen Implementierungen des offenbarten Gegenstandes.
2 zeigt ein anschauliches Beispiel eines Prozesses für Mediensitzungs-Parallelitätsmanagement mit wiederkehrenden Lizenzerneuerungen in Übereinstimmung mit einigen Implementierungen des offenbarten Gegenstandes.
3 zeigt ein anschauliches Beispiel eines Prozesses für die Anwendung eines von mehreren Durchsetzungsmodi in einem Benutzerkonto auf Grundlage von Informationen über das Benutzerkontoverhalten in Übereinstimmung mit einigen Implementierungen des offenbarten Gegenstandes.
4 zeigt ein Beispiel eines verallgemeinerten schematischen Diagramms eines Systems auf dem die Mechanismen für Mediensitzungs-Parallelitätsmanagement mit wiederkehrenden Lizenzerneuerungen, wie hier beschrieben, in Übereinstimmung mit einigen Implementierungen implementiert werden können.
5 zeigt eine beispielhafte Hardware, die verwendet werden kann, um eine oder mehrere Rechengeräte und Server, die in 4 dargestellt sind, in Übereinstimmung mit einigen Implementierungen des offenbarten Gegenstandes zu implementieren.
Ausführliche Beschreibung
In Übereinstimmung mit diversen Implementierungen werden Mechanismen (welche Systeme, Verfahren und Medien beinhalten) für das Mediensitzungs-Parallelitätsmanagement mit wiederkehrenden Lizenzerneuerungen bereitgestellt.
Allgemein gesprochen können Inhalteverteilungssysteme einen Inhalteserver, eine Medienwiedergabeanwendung, ausgeführt auf einem Rechengerät, und ein Kommunikationsnetzwerk, welches den Inhalteserver mit der Medienwiedergabeanwendung verbindet, ausgeführt auf dem Rechengerät, beinhalten. Der Inhalteserver kann konfiguriert werden, um Medieninhaltegegenstände zu speichern, welche vom Inhalteserver auf die Medienwiedergabeanwendung, ausgeführt auf dem Rechengerät, heruntergeladen werden können. Zum Beispiel kann, als Reaktion auf den Empfang einer Benutzeranfrage, die einen Titel auswählt oder irgendeine andere geeignete Information, welche einen Medieninhaltegegenstand identifiziert, die Medienwiedergabeanwendung, ausgeführt auf dem Rechengerät, konfiguriert werden, eine Mediendatei korrespondierend zu einem Medieninhaltegegenstand, welcher fortlaufende Inhaltsdaten, Audiodaten, Videodaten etc. beinhalten kann, herunterzuladen und wiederzugeben. Eine solche Wiedergabe kann das Dekodieren und das Rendern von Audio- und Videodaten in ein Audio- und ein Videosignal beinhalten. In einigen Implementierungen überträgt und streamt der Server fortlaufend die Mediendatei(en) an die Medienwiedergabeanwendung. Entsprechend kann die Medienwiedergabeanwendung, ausgeführt auf dem Rechengerät, einen Teil des Medieninhaltegegenstands unter Verwendung der Mediendatei(en) darstellen, während eine oder mehrere zusätzliche Mediendateien des Medieninhaltegegenstands erlangt werden.
In manchen Situationen kann ein Limit für die Anzahl von parallelen Streaming-Verbindungen festgelegt werden, die einem bestimmten Benutzerkonto gestattet wird aufzubauen. Zum Beispiel kann ein Inhalteanbieter für ein bestimmtes Konto und/oder einen bestimmten Gerätetyp eine Beschränkung auf die maximale Anzahl paralleler Streaming-Verbindungen festlegen, die für dieses Konto oder dieses Gerät aufgebaut werden kann. Die Durchsetzung des Limits auf die Anzahl paralleler Streaming-Verbindungen kann hierbei durch einen belieben geeigneten Server durchgeführt werden, wie etwa einen Digitale-Rechte-Management(DRM)-Server. Wenn ein Benutzer eines bestimmten Benutzerkontos eine neue Streaming-Verbindung anfragt, kann eine Medienlizenz zusätzlich zum Medieninhalt benötigt werden. Der DRM-Server kann festlegen, ob er die Medienlizenz dem Gerät ausstellt, das eine neue Streaming-Verbindung anfragt, zumindest teilweise indem er die Anzahl gegenwärtig aktiver oder aufgebauter, mit dem Benutzerkonto verknüpfter Streaming-Verbindungen erkennt und indem, wenn diese Anzahl die Maximalzahl erlaubter paralleler Streaming-Verbindungen überschreitet, die Anfrage für die neue Streaming-Verbindung zurückgewiesen wird. Es ist festzuhalten, dass die Versagung einer solchen Lizenz den Medieninhalt unabspielbar werden lässt oder dass auf andere Weise die Wiedergabe des Medieninhalte unterbunden wird.
Ebenso festzuhalten ist, dass in manchen Situationen eine vorherige Streaming-Verbindung, die durch den Benutzer eines Benutzerkontos aufgebaut wurde, durch die Medienwiedergabeanwendung beendet wird, aber die Benachrichtigung vom Beendigungsereignis am Lizenzserver nicht empfangen wird. Dies kann zum Ergebnis haben, dass unrichtige oder veraltete Zustandsinformationen auf dem mit dem Benutzerkonto verknüpften DRM-Server gespeichert werden, was die Betrachtungserfahrung des mit dem Benutzerkonto verbundenen Benutzer beeinträchtigen kann. Zum Beispiel kann es vorkommen, dass es einem Benutzer eines Benutzerkontos, der eine bestimmte Streaming-Verbindung legitimerweise beendet hat, nicht gestattet wird, eine beliebige neue Streaming-Verbindung aufzubauen, wenn der DRM-Server nicht weiß, dass die bestimmte Streaming-Verbindung beendet wurde. Es Benutzern nicht zu erlauben, neue Streaming-Verbindungen aufzubauen, wenn diese Benutzer sich in Übereinstimmung mit den Beschränkungen verhalten, die für parallele Streaming-Verbindungen gelten, kann die Benutzererfahrung ruinieren und ist daher nicht wünschenswert in einem Inhaltebereitstellungssystem.
Der DRM-Server kann, als Reaktion auf das Empfangen einer Medienlizenzanfrage von einem DRM-Clientdienst, mit einer Lizenz von beschränkter Dauer antworten. Zum Beispiel kann die Lizenz eine beschränkte Dauer in der Größenordnung von einigen Minuten (z. B. 5 Minuten) haben und kann mit einer Richtlinie verknüpft sein, welche Lizenzerneuerungen gestattet. Es sollte festgehalten werden, dass die Lizenz aus schlüsselsystemspezifischen Zustandsinformationen bestehen kann, die einen oder mehrere Schlüssel beinhalten können, welche mit einer Schlüsselkennung und jeder anderen geeigneten Information die Schlüsselverwendung betreffend verknüpft sein können. Es sollte außerdem festgehalten werden, dass der eine oder die mehreren in der Lizenz beinhalteten Schlüssel möglicherweise nicht für die Entschlüsselung von Medieninhalten (z. B. ein oder mehrere Blöcke Mediendaten) verwendet werden können, wenn die Lizenz abgelaufen ist.
Vor dem Lizenzablauf auf dem DRM-Clientgerät kann das DRM-Clientgerät eine Lizenzerneuerungsanfrage in Überstimmung mit der Lizenzerneuerungsrichtlinie senden. Zum Beispiel kann die Lizenzerneuerungsrichtlinie ein Erneuerungsanfrageintervall (oder die Zeit zwischen Lizenzerneuerungsanfragen) und eine Lizenzdauer angeben. Es sollte festgehalten werden, dass die Lizenzerneuerungsrichtlinie dynamisch auf Grundlage jedes geeigneten Parameters angepasst werden kann (z. B. pro Konto, pro Gerät, pro Medieninhaltetitel etc.), dort wo die Anpassungen verlängerte Lizenzperioden in Zeiten von Serverüberlastung oder Datenzentrumsausfällen, verlängerte Lizenzperioden für Benutzerkonten, die erachtet werden ein bestimmtes Verhaltensmuster an den Tag zu legen, häufigere Erneuerungsanfragenintervalle für Benutzerkonten, die erachtet werden ein bestimmtes Verhaltensmuster an den Tag zu legen etc., beinhalten können. Es sollte außerdem festgehalten werden, dass die Lizenzerneuerungsanfrage wiederholt werden kann, falls eine Lizenzerneuerung nicht innerhalb einer bestimmten Timeout-Periode empfangen werden kann.
Als Reaktion auf das Empfangen einer Lizenzerneuerungsanfrage vom DRM-Clientgerät kann der DRM-Server bestimmen, ob die Lizenz für eine weitere Lizenzerneuerungsperiode verlängert werden kann oder ob die Schlüsselverwendungsrechte entzogen werden soll. Die Lizenzerneuerung kann zum Beispiel allgemein leichter als die Initiallizenzierung sein, da sie Richtliniendaten beinhaltet, welche anzeigen, ob die Verwendung der Medienschlüssel verlängert oder entzogen werden soll (z. B. während eine Lizenz einen oder mehrere Medienschlüssel beinhalten kann). Es sollte festgehalten werden, dass die Nichtfortsetzung oder der Entzug der Verwendung von Medienschlüsseln durchgeführt werden kann, zum Beispiel durch eine Lizenzerneuerung mit Dauer Null oder ein anderes Mittel um die Nichtfortsetzung von Medienrechten durchzusetzen.
Entsprechend kann das DRM-Clientgerät konfiguriert werden, als Reaktion auf das Empfangen einer Lizenzerneuerung die Lizenz um die in der Lizenzerneuerung vorgeschriebene Dauer zu verlängern oder den Zugriff auf die Medienschlüssel zu entziehen, wodurch die Wiedergabe des Medieninhaltegegenstands beendet wird.
Mit Bezug auf das Erkennen paralleler Streaming-Verbindungen kann der DRM-Server feststellen, wie viele DRM-Clientgeräte auf einen bestimmten Medieninhaltegegenstand (oder allgemein den Mediendienst) zugreifen, indem die Anzahl von Lizenzerneuerungsanfragen gezählt wird, die in der letzten Erneuerungsperiode für ein Benutzerkonto und/oder einen Medieninhaltegegenstand empfangen wurden. Es sollte festgehalten werden, dass, falls der DRM-Server innerhalb der letzten Erneuerungsperiode keine Anfrage von der DRM-Clientinstanz empfangen hat, der DRM-Server annehmen kann, dass das DRM-Clientgerät den Medieninhaltegegenstand nicht weiter abspielt. Zum Beispiel kann es sein, dass der Benutzer des DRM-Clientgeräts die Wiedergabe des Medieninhaltegegenstands eingestellt hat. Als weiteres Beispiel können die Schlüsselverwendungsrechte entzogen oder wegen Lizenzablaufs eingestellt worden sein.
In einigen Implementierungen kann der DRM-Server oder jeder andere geeignete, Lizenzerneuerungsanfragen bedienende Server eine Warteschlange von Lizenzerneuerungsanfragen verwalten, in welcher alte Einträge in der Warteschlange nach einer Zeit äquivalent zur Lizenzdauer ablaufen können. Der DRM-Server kann festlegen, ob eine Initiallizenz als Reaktion auf eine neue initiale Lizenzanfrage erteilt werden soll, indem die Warteschlange (z. B. eine Lizenzerneuerungs-Serverschleife) geprüft wird, um parallel laufende Wiedergabesitzungen zu bestimmen. Alternativ kann der DRM-Server konfiguriert werden, um zu jeder Zeit neue Anfragen zu bedienen, während gleichzeitig der DRM-Server oder jeder andere geeignete Erneuerungsserver veranlasst wird, Lizenzrechte für die älteste Sitzung das nächste Mal zu entziehen, wenn eine Lizenzerneuerungsanfrage für die Sitzung empfangen wird. Dies hat den Vorteil beispielsweise immer die jüngste Benutzeranfrage zu gestatten, anstatt eine neue Anfrage abzulehnen weil andere laufende Wiedergabesitzungen vermutet werden.
In einigen Implementierungen kann der DRM-Server, zusätzlich oder stattdessen, konfiguriert werden, einen Nur-Erkennungsmodus zu aktivieren, in welchem Lizenzserver, welche die initialen Lizenzanfragen bearbeiten, und Lizenzerneuerungsserver, welche die Lizenzerneuerungsanfragen bearbeiten, die empfangenen Anfragen bedienen und in einem Datensatz loggen können.
Diese hier beschriebenen Mechanismen können in einer Vielzahl von Anwendungen verwendet werden. Zum Beispiel können diese Mechanismen verwendet werden, um verdächtiges Benutzerverhalten zu erkennen und einzudämmen, ohne sich auf Medienbereitstellungsdienste gegenüber Benutzern auszuwirken oder sie zu beeinträchtigen, die kein solches verdächtiges Verhalten an den Tag legen. Als weiteres Beispiel können diese Mechanismen über verschiedene Typen und Clients hinweg skaliert werden, da sie unabhängig von der Clientarchitektur sind, möglicherweise keinen Speicher (z. B. JavaScript-Speicherplatz) auf Clientgeräten benötigen und implementiert werden können, um in einem privatem Browsing-Modus zu operieren. In einem spezielleren Beispiel behindern diese Mechanismen die Implementierung von Clientgeräten oder einer Clientgerät-Architektur möglicherweise dort nicht, wo ein Clientgerät, welches Lizenzen anfragen und handhaben kann, die Verwendung wiederkehrender Lizenzerneuerungen unterstützen kann. Als noch ein weiteres Beispiel können diese Mechanismen Flexibilität während der Eskalation oder Deeskalation von Bedrohungen bereitstellen. In einem weitergehenden Beispiel können diese Mechanismen verwendet werden, um eine einzelne Implementierung bereitzustellen, welche Betrug erkennt und Parallelitätslimits durchsetzt.
In einem spezielleren Beispiel kann das Fehlen von vor dem Auslauf der Lizenz empfangener Lizenzerneuerungsanfragen als ein Anzeichen dafür verwendet werden, dass der Medieninhalt momentan nicht weiter abgespielt wird. Deswegen ist es möglich, dass solche Anzeichen nicht durch Geräteabstürze, das Schließen des Deckels auf einem Laptop-Computergerät etc. verloren gehen.
Diese und weitere Eigenschaften des Mediensitzungs-Parallelitätsmanagements mit wiederkehrenden Lizenzerneuerungen werden weitergehend in Verbindung mit 1–5 beschrieben.
Unter Bezugnahme auf 1 wird ein anschauliches Beispiel eines Flussdiagramms 100 für die Implementierung wiederkehrender Erneuerungen zwischen einem Medienwiedergabegerät und einem oder mehreren DRM oder Lizenzservern in Übereinstimmung mit einigen Implementierungen des offenbarten Gegenstandes gezeigt. Zum Beispiel kann ein Medienwiedergabegerät Anfragen für Lizenzen und Lizenzerneuerungen an einen DRM-Server übertragen, wobei der DRM-Server die Feststellung handhabt, ob Lizenzen und Lizenzerneuerungen erteilt werden. Es sollte festgehalten werden, dass, obwohl 1 einen DRM-Lizenzserver zeigt, jede beliebige Anzahl an DRM-Lizenzservern verwendet werden kann. Zum Beispiel kann ein Medienwiedergabegerät Anfragen über Lizenzen an einen Lizenzserver übertragen und Lizenzerneuerungen bei einem oder mehreren Lizenzerneuerungsserver anfragen. In einem weiteren Beispiel kann ein Server, etwa ein Webserver, Anfragen über Lizenzen oder Lizenzerneuerungen handhaben und bestimmen, welcher Lizenzserver eine Lizenzanfrage und welcher Lizenzerneuerungsserver eine Lizenzerneuerungsanfrage handhaben sollte. In noch einem weiteren Beispiel kann der DRM-Client konfiguriert werden, als Reaktion auf das Nicht-Empfangen einer Antwort auf eine Lizenzanfrage oder auf eine Lizenzerneuerungsanfrage innerhalb eines bestimmten Zeitraums (z. B. ein zuvor bestimmter Timeout), eine weitere Lizenzanfrage oder Lizenzerneuerungsanfrage an einen weiteren DRM-Lizenzserver zu übertragen.
Wie hier nachstehend beschrieben, sollte festgehalten werden, dass jede Lizenzerneuerung verwendet werden kann, um anzuzeigen, dass die Verbindung für das Streamen eines bestimmten Medieninhaltegegenstands aktiv bleibt. Dies kann verwendet werden, um z. B. die Anzahl aktiver Streaming-Verbindungen festzustellen und die festgestellte Anzahl aktiver Streaming-Verbindungen bei der Feststellung, ob eine weitere Lizenz oder Lizenzerneuerung erteilt werden soll, mit einem Parallelitätslimit zu vergleichen.
In einigen Implementierungen kann der Prozess 100 bei 110 durch das Empfangen einer Anfrage über eine Medieninhaltelizenz beginnen, die zu einem Medieninhaltegegenstand für die Darstellung auf einem Medienwiedergabegerät gehört. Zum Beispiel kann ein DRM-Client, als Reaktion auf das Empfangen einer Anfrage über einen Medieninhaltegegenstand von einem Inhalteserver (z. B., einen Medieninhaltegegenstand zu streamen), verschlüsselte Mediendaten empfangen, die bei Entschlüsselung mit einer Medienlizenz, welche einen oder mehrere Schlüssel enthält, den Medieninhaltegegenstand auf dem DRM-Client wiedergeben. Die Anfrage über eine Medieninhaltelizenz kann z. B. mit dem Medieninhaltegegenstand verknüpfte Metadaten beinhalten, wie etwa eine Überschriftsinformation, eine Videoformatinformation, eine Auflösungs- oder Bitrate, ein Bildseitenverhältnis, Längeninformationen, Audioformatinformationen, Untertitelinformationen etc. Als weiteres Beispiel kann die Anfrage über eine Medieninhaltelizenz Benutzeranmeldeinformationen, wie etwa einen Benutzernamen und ein mit dem Benutzerkonto verknüpftes Passwort und Geräteinformationen, wie etwa eine Gerätekennung, Gerätetypinformationen, Verbindungsinformationen etc., enthalten.
In einigen Implementierungen kann der DRM-Lizenzserver bestimmen, ob die Lizenzanfrage vom DRM-Clientgerät bedient werden soll. Zum Beispiel kann der DRM-Lizenzserver eine Anzahl an mit einem Benutzerkonto verknüpfter paralleler Streaming-Verbindungen von einer beliebigen Anzahl von DRM-Clientgeräten erkennen, indem die Anzahl an Lizenzerneuerungsanfragen, die in der letzten Erneuerungsperiode empfangen wurden, gezählt werden. In Fortsetzung dieses Beispiels kann der DRM-Lizenzserver, falls er innerhalb der letzten Erneuerungsperiode keine Erneuerungsanfrage von einer DRM-Clientinstanz empfangen hat, derartige Informationen als einen Hinweis darauf verwenden, dass das DRM-Clientgerät den Medieninhaltegegenstand nicht mehr abspielt – z. B. kann es sein, dass das DRM-Clientgerät die Wiedergabe des Medieninhaltegegenstands eingestellt hat, dass die Schlüsselverwendungsrechte entzogen oder wegen Lizenzablaufs eingestellt wurden etc.
In einigen Implementierungen kann der DRM-Lizenzserver die Anzahl an parallelen Streaming-Verbindungen erkennen, indem er eine Warteschlange von Lizenzerneuerungsanfragen verwaltet, in welcher die alten Einträge in der Warteschlange nach einer Zeit äquivalent zur Lizenzdauer ablaufen können. Entsprechend kann der DRM-Lizenzserver festlegen, ob eine Initiallizenz als Reaktion auf eine neue initiale Lizenzanfrage erteilt werden soll, indem die Warteschlange (z. B. eine Lizenzerneuerungs-Serverschleife) geprüft wird, um parallel laufende Wiedergabesitzungen zu bestimmen.
Es sollte festgehalten werden, dass jede beliebige geeignete Information erlangt werden kann, die den DRM-Lizenzserver dabei unterstützt, festzustellen, wie er auf eine neue initiale Lizenzanfrage von einem Benutzergerät reagiert, das mit einem bestimmten Benutzerkonto authentifiziert wurde. Zum Beispiel können derartige Informationen, in Implementierungen, die einen DRM-Lizenzserver, der Lizenzanfragen handhabt, und einen oder mehrere Lizenzerneuerungsserver, die Lizenzerneuerungsanfragen handhaben und eine Lizenzerneuerungs-Warteschlange verwalten, die Anzahl aktiver Sitzungen, die Anzahl an Lizenzerneuerungsanfragen, die Anzahl an Lizenzerneuerungen, mit den Lizenzerneuerungsanfragen verknüpfte Zeitinformationen, Lizenzinformationen, eine geeignete Antwort unter Beachtung der maximal zu erlaubenden Anzahl paralleler Sitzungen, der Anzahl für das Benutzerkonto noch verfügbarer paralleler Sitzungen etc. beinhalten.
Alternativ kann der DRM-Lizenzserver dahingehend konfiguriert werden, zu jeder Zeit neue Anfragen zu bedienen, während gleichzeitig der DRM-Lizenzserver oder jeder andere geeignete Erneuerungsserver veranlasst wird, Lizenzrechte für die älteste Sitzung das nächste Mal zu entziehen, dass eine Lizenzerneuerungsanfrage für die Sitzung empfangen wird. Dies kann von Vorteil sein, zum Beispiel um immer die jüngste Benutzeranfrage zu gestatten, anstatt eine neue Anfrage deswegen zu versagen, weil von Wiedergabesitzungen vermutet wird, dass sie noch anzudauern.
Rückweisend Bezug nehmend auf 1, kann ein DRM-Lizenzserver in einigen Implementierungen, bei 120, als Antwort auf eine von einem DRM-Clientgerät empfangene Anfrage nach einer Medienlizenz eine Antwort übertragen, welche eine Lizenz mit begrenzter Dauer beinhaltet. Zum Beispiel kann der DRM-Lizenzserver unter Verwendung der Metadaten oder anderer durch die Anfrage vom DRM-Clientgerät übertragener Informationen, einen oder mehrere mit den zu verschlüsselnden Mediendaten verknüpfte Schlüssel lokalisieren und erlangen und diesen einen oder die mehreren Schlüssel in die Lizenz mit begrenzter Dauer einschließen. In einem spezielleren Beispiel kann die vom DRM-Lizenzserver erteilte Lizenz aus schlüsselsystemspezifischen Zustandsinformationen bestehen, die einen oder mehrere Schlüssel beinhalten können, welche jeweils mit einer Schlüsselkennung und jeder anderen geeigneten Information die Schlüsselverwendung betreffend verknüpft sein können.
Es sollte festgehalten werden, dass die Dauer solch einer Lizenz zum Beispiel eine gegebene Anzahl an Minuten sein kann (z. B. drei Minuten, fünf Minuten etc). Zum Beispiel kann die Lizenzdauer äquivalent zur Länge oder zur gesamten Abspieldauer des Medieninhaltegegenstands festgelegt werden. In einem weiteren Beispiel kann die Dauer der Lizenz äquivalent zur Dauer des Medieninhaltegegenstands und einem zusätzlichen Zeitraum für Benutzerinteraktionen, wie etwa dem Pausieren der Wiedergabe des Medieninhaltegegenstands (z. B. Inhaltedauer plus X Minuten), sein. In noch einem weiteren Beispiel kann für die Dauer der Lizenz eine kurze Zeitspanne im Vergleich mit der gesamten Wiedergabelänge des Medieninhaltegegenstands (z. B. fünf Minuten Lizenzdauer für einen Medieninhaltegegenstand mit einer gesamten Wiedergabedauer von dreißig Minuten) bestimmt werden. Es sollte außerdem festgehalten werden, dass solch eine Lizenz in einigen Implementierungen mit einer Richtlinie, die eine bestimmte Lizenzspanne bestimmt und Lizenzerneuerungen zulässt, konfiguriert werden kann, wobei, vor Ablauf der Lizenz, das DRM-Clientgerät eine Lizenzerneuerungsanfrage abschicken kann, um die Medienlizenz zu erhalten und die Wiedergabe des Medieninhaltegegenstands fortzusetzen. Wenn die Lizenz abgelaufen ist, kann es sein, dass der eine oder die mehreren in der Lizenz beinhalteten Schlüssel nicht für die Entschlüsselung von Medieninhalten (z. B. ein oder mehrere Blöcke Mediendaten) verwendet werden können.
In einigen Implementierungen können die vom DRM-Lizenzserver oder dem Lizenzerneuerungsserver (z. B. eines geeigneten Servers, der ein Konto mit Lizenzerneuerungen verwaltet) erteilten Lizenzen auf Grundlage jedes geeigneten Parameters konfiguriert werden. Zum Beispiel kann ein Inhalteanbieter beliebige geeignete Parameter bereitstellen, welche dynamisch die Lizenzspanne einer Lizenz für ein bestimmtes Benutzerkonto für ein bestimmtes Gerät, für einen Teil eines bestimmten Medieninhalts etc. anpassen. Solche Parameter können, als Reaktion auf eine Feststellung einer Server-Überlastung oder einen Hinweis darauf, Anpassungen der Lizenzspanne veranlassen (z. B. das Verlängern der Lizenzspanne um die Verwendung von Serverressourcen zu erleichtern), Datenzentrumsausfälle (z. B. das Verlängern der Lizenzspanne als Reaktion auf das Feststellen eines Datenzentrumsausfalls), eines Benutzerkontos, das erachtet wird, sich anständig zu benehmen oder ein gutes Ansehen hat (z. B. das Verlängern der Lizenzspanne für ein bestimmtes Benutzerkonto, für das keine oder wenige Instanzen erkannten verdächtigen Verhaltens existieren), eines Benutzerkontos, für welches verdächtiges Verhalten erkannt wurde (z. B. das Verringern der Lizenzspanne und/oder das Anwenden einer unterschiedlichen Lizenzrichtlinie, welche die Anzahl paralleler Sitzungen auf Grundlage von Benutzerverhalten verringert oder dynamisch verändert), Konfliktlösung (z. B. das automatische Gestatten einer Initiallizenz oder einer Lizenzerneuerung für ein Benutzerkonto, das erachtet wird, sich anständig zu verhalten, als Reaktion darauf, dass der Server anzeigt, dass eine abnormale Situation existiert), Medientypen (z. B. erhalten längere Filme kürzere Lizenzperioden gegenüber kürzeren Audioausschnitten) etc.
In manchen Implementierungen kann das Lizenzerneuerungsintervall zusätzlich oder alternativ zum Gestatten der Lizenzdaueranpassung ebenfalls auf Grundlage eines beliebigen geeigneten Parameters modifiziert werden. Zum Beispiel kann der Erneuerungsanfrageintervall, als Reaktion auf einen Parameter, der das allgemeine Verhalten eines Benutzerkontos oder eines Benutzergeräts (z. B. anständig insofern, dass keine Instanzen erkannten verdächtigen Verhaltens vorhanden sind, schlechtes Verhalten insofern, dass eine Anzahl Erkennungen verdächtigen Verhaltens größer als ein Grenzwert vorhanden sind, uneindeutiges Verhalten insofern, dass zu einem Benutzerkonto oder einem Benutzergerät weniger Verhaltensinformationen vorhanden sind, als die bestimmte Zeitspanne ist etc.), das Erneuerungsanfrageintervall auf Grundlage von Verhaltensparametern anpassen. In einem spezielleren Beispiel kann ein Server eine Lizenz mit einem Erneuerungsanfrageintervall mit einer Standard-Zeitspanne (z. B. eine längere Erneuerungstoleranzspanne von fünf Minuten bei Vergleich mit einer kürzeren, restriktiveren Erneuerungstoleranzspanne von zwei Minuten) erteilen und feststellen, ob das Erneuerungsanfrageintervall für folgende Lizenzanfragen als Reaktion auf mit dem Benutzerkonto oder dem Benutzergerät verknüpften Verhaltensinformationen verkürzt werden sollte. In diesem Beispiel kann eine Lizenzerneuerungsanfrage, während eine initiale Lizenzanfrage eine weniger restriktive Lizenz mit einem längeren Erneuerungsanfrageintervall wie etwa jede sechs Minuten erhalten kann, als Antwort auf das Erkennen verdächtigen Verhaltens (z. B. einer Anzahl von Lizenzanfragen innerhalb einer bestimmten Zeitspanne, welche größer ist, als ein bestimmter Grenzwert) eine restriktivere Lizenzerneuerung mit einem kürzeren Erneuerungsanfrageintervall haben, wie etwa jede zwei Minuten. Dies kann verwendet werden, zum Beispiel, als Reaktion auf das Feststellen, dass ein Benutzerkonto eine Vielzahl von neuen Lizenzanfragen hat, während andere Lizenzen gültig sind, was ein Hinweis darauf sein kann, dass ein Benutzer des bestimmten Benutzerkontos sein Konto missbraucht, indem parallel viele Stücke Medieninhalte gestreamt werden und Erneuerungsanfragen geblockt werden oder er legitimerweise durch verschiedener Stücke Medieninhalte geht, bis er Medieninhalte findet, welche der Benutzer ein Interesse zu konsumieren hat.
Es sollte festgehalten werden, dass jeder geeignete Ansatz verwendet werden kann, um das Erneuerungsanfrageintervall zu bestimmen. Zum Beispiel kann der Server einen Hinweis das Verhalten betreffend mit jedem Benutzerkonto oder jedem Benutzergerät verknüpfen, wobei jeder das Verhalten betreffende Hinweis mit einer bestimmten Lizenzdauer und/oder einem bestimmten Erneuerungsanfrageintervall verknüpft werden kann. Als Reaktion auf das Empfangen eines das Verhalten betreffenden Indikators kann der DRM-Lizenzserver eine geeignete Lizenz als Antwort auf die empfangene Lizenzanfrage oder die Lizenzerneuerungsanfrage übertragen.
In einigen Implementierungen kann die Lizenz, in Fällen, in denen Lizenzerneuerungen für eine erteilte Lizenz zulässig sind, Informationen bezüglich eines oder mehrerer Server für die Handhabung von Lizenzerneuerungsanfragen beinhalten (z. B. URLs für einen oder mehrere Lizenzerneuerungsserver). In einigen Implementierungen können solche Informationen eine geordnete Liste von URLs eines oder mehrerer Lizenzerneuerungsserver beinhalten – z. B. einer URL für einen ersten Lizenzerneuerungsserver und, wenn innerhalb einer gegebenen Timeout-Zeitspanne keine Antwort empfangen wird, einer URL für einen zweiten Lizenzerneuerungsserver usw. Alternativ können, in einigen Implementierungen, solche Informationen eine URL eines ersten Lizenzerneuerungsservers und eines oder mehrerer Ersatz-URLs von Erneuerungsservern beinhalten, sollte der erste Lizenzerneuerungsserver innerhalb einer bestimmten Zeitspanne unerreichbar sein.
In einigen Implementierungen kann der DRM-Client, bei 130, bestimmen, ob eine Lizenzerneuerung für die gegenwärtig erteile Lizenz benötigt wird. Zum Beispiel kann der DRM-Client, als Reaktion auf das Empfangen einer erteilten Lizenz bei 120, festlegen, dass die Lizenzspanne gleich einer bestimmten Zeitspanne (z. B. fünf Minuten) ist und dass Lizenzerneuerungen für die erteilte Lizenz in einem bestimmten Lizenzerneuerungs-Anfrageintervall zulässig sind. Als Reaktion auf das Feststellen einer Lizenzspanne kann der DRM-Client eine bestimmte Zeitspanne festlegen, in welcher eine Lizenzerneuerung erlangt werden soll, wie etwa zwei Minuten vor dem Auslauf der gegenwärtig erteilten Lizenz (oder einen Zeitpunkt deutlich vor dem Ablauf der gegenwärtig erteilten Lizenz).
In einem spezielleren Beispiel kann der DRM-Client feststellen, dass die mit der erteilten Lizenz verknüpfte Richtlinie eine Lizenzdauer und ein Erneuerungsanfrageintervall (oder die Zeit zwischen Lizenzerneuerungsanfragen) anzeigt. Zum Beispiel kann die Richtlinie, sollte der Benutzer die Fortsetzung der Wiedergabe des Medieninhaltegegenstands durch Verlängerung der gegenwärtig erteilten Lizenz wünschen, den DRM-Client instruieren, dass sich ein bestimmtes Lizenzerneuerungs-Zeitfenster zu einer bestimmten Zeit öffnet – z. B. Lizenzerneuerungsanfragen können vom DRM-Server innerhalb eines Erneuerungszeitfensters empfangen werden, welches sich wenigstens eine Minute vor Ablauf der gegenwärtig erteilten Lizenz öffnet. Es sollte festgehalten werden, dass die Lizenzerneuerungsrichtlinie durch den DRM-Lizenzserver dynamisch auf Grundlage jedes geeigneten Parameters angepasst werden kann (z. B. pro Konto, pro Gerät, pro Medieninhaltetitel etc.), dort wo die Anpassungen verlängerte Lizenzperioden in Zeiten von Serverüberlastung oder Datenzentrumsausfällen, verlängerte Lizenzperioden für Benutzerkonten, die erachtet werden ein bestimmtes Verhaltensmuster an den Tag zu legen, häufigere Erneuerungsanfragenintervalle für Benutzerkonten, die erachtet werden, ein bestimmtes Verhaltensmuster an den Tag zu legen etc., beinhalten können.
In einigen Implementierungen kann das DRM-Clientgerät, als Reaktion auf das Feststellen, dass eine Lizenzerneuerung benötigt wird, um die Wiedergabe des Medieninhaltegegenstands vor dem Ablauf der gegenwärtig erteilten Lizenz fortzusetzen, bei 140 eine Lizenzerneuerungsanfrage übertragen. Die Lizenzerneuerungsanfrage kann jede geeignete Information beinhalten, etwa eine mit der gegenwärtig erteilten Lizenz verknüpfte Lizenzkennung, eine mit der gegenwärtig aktiven Streaming-Verbindung verknüpfte Sitzungskennung, eine Zeitmenge bis Ablauf der gegenwärtig erteilten Lizenz oder jede andere geeignete Information vom DRM-Clientgerät, die vom DRM-Lizenzserver benötigt wird, um eine Lizenzerneuerung zu erteilen. In einigen Implementierungen kann die durch den DRM-Lizenzserver erteilte Lizenz Instruktionen beinhalten, welche Informationen benötigt werden, um eine Lizenzerneuerung für die gegenwärtig erteilte Lizenz zu erteilen (z. B. Benutzerkontoinformationen, Lizenzinformationen, Geräteinformationen, Zeitinformationen oder jede geeignete Kombination daraus).
In einigen Implementierungen kann das DRM-Clientgerät, falls eine Antwort auf die Lizenzerneuerungsanfrage nicht empfangen wurde, die Lizenzerneuerungsanfrage eine beliebige geeignete Anzahl Male wiederholen, um eine gültige Lizenzerneuerung nach einem konfigurierten Timeout zu erlangen. Zum Beispiel kann eine Antwort auf eine Lizenzerneuerungsanfrage möglicherweise aufgrund eines Ausfalls eines bestimmten Lizenzerneuerungsservers nicht empfangen werden. In einem spezielleren Beispiel kann das DRM-Clientgerät, als Reaktion auf das Übertragen einer Lizenzerneuerungsanfrage an einen Lizenzerneuerungsserver an einer ersten URL, eine nachfolgende Lizenzerneuerungsanfrage an einen anderen Lizenzerneuerungsserver an einer Ersatz-URL übertragen. Die Übertragung der Lizenzerneuerungsanfragen kann fortgesetzt an einen Lizenzerneuerungsserver an Ersatz-URLs übertragen werden, bis dass eine Lizenzerneuerung erlangt wurde.
Bei 150 kann der DRM-Lizenzserver als Reaktion auf das Empfangen einer Lizenzerneuerungsanfrage vom DRM-Clientgerät bestimmen, ob er eine Lizenzerneuerung erteilt. Zum Beispiel kann der DRM-Lizenzserver bestimmen, ob die Lizenz für eine weitere Lizenzerneuerungsperiode verlängert wird oder die Schlüsselverwendungsrechte entzogen werden. Es sollte festgehalten werden, dass das Bestimmen der Erteilung einer Lizenzerneuerung das Festlegen einer Lizenzerneuerungsdauer (z. B. weitere drei Minuten, weitere fünf Minuten etc.) beinhalten kann, um die Verwendung von Medienschlüsseln fortzusetzen, was die Wiedergabe des Medieninhaltegegenstands erlaubt. Es sollte außerdem festgehalten werden, dass die Nichtfortsetzung oder der Entzug der Verwendung von Medienschlüsseln in der Lizenz z. B. durch das Übertragen einer Lizenzerneuerung mit Länge Null oder anderweitig durch das Erteilen einer Instruktion durchgeführt werden kann, welche die Schlüsselverwendungsrechte entzieht.
In einigen Implementierungen kann der DRM-Lizenzserver, wie oben beschrieben, eine Anzahl an mit einem Benutzerkonto verknüpfter paralleler Streaming-Verbindungen von einer beliebigen Anzahl von DRM-Clientgeräten erkennen, indem die Anzahl an Lizenzerneuerungsanfragen, die in der letzten Erneuerungsperiode empfangen wurden, gezählt werden. In Fortsetzung dieses Beispiels kann der DRM-Lizenzserver, falls er innerhalb der letzten Erneuerungsperiode keine Erneuerungsanfrage von einer DRM-Clientinstanz empfangen hat, derartige Informationen als einen Hinweis darauf verwenden, dass das DRM-Clientgerät den Medieninhaltegegenstand nicht mehr abspielt – z. B. kann es sein, dass das DRM-Clientgerät die Wiedergabe des Medieninhaltegegenstands eingestellt hat, dass die Schlüsselverwendungsrechte entzogen oder wegen Lizenzablaufs eingestellt wurden etc.
In einigen Implementierungen kann der DRM-Lizenzserver die Anzahl an parallelen Streaming-Verbindungen erkennen, indem er eine Warteschlange von Lizenzerneuerungsanfragen verwaltet, in welcher die alten Einträge in der Warteschlange nach einer Zeit äquivalent zur Lizenzdauer ablaufen können. Entsprechend kann der DRM-Lizenzserver festlegen, ob eine Initiallizenz als Reaktion auf eine neue initiale Lizenzanfrage erteilt werden soll, indem die Warteschlange (z. B. eine Lizenzerneuerungs-Serverschleife) geprüft wird, um parallel laufende Wiedergabesitzungen festzustellen.
Es sollte festgehalten werden, dass in Implementierungen, in denen einer oder mehrere Lizenzerneuerungsserver Lizenzerneuerungsanfragen handhaben, der Lizenzserver eine Lizenzerneuerungs-Warteschlange anfragen kann und Informationen feststellen kann, die verwendet werden können, um Lizenzerneuerungsanfragen zu handhaben, wie etwa die Anzahl aktiver Sitzungen, die Anzahl an Lizenzerneuerungsanfragen, die Anzahl an Lizenzerneuerungen, mit den Lizenzerneuerungsanfragen verknüpfte Zeitinformationen, Lizenzinformationen, eine geeignete Antwort unter Beachtung der maximal zu erlaubenden Anzahl paralleler Sitzungen, der Anzahl für das Benutzerkonto noch verfügbarer paralleler Sitzungen etc.
Alternativ kann der DRM-Lizenzserver in einigen Implementierungen einen Nur-Erkennungsmodus implementieren, der veranlasst, dass die initiale Lizenzanfrage und/oder Lizenzerneuerungsanfragen automatisch bedient werden und ein Protokoll über die Anfragen sowie verknüpfte Lizenzen und Lizenzerneuerungen führt. Dies kann zum Beispiel in Zeiten von Serverüberlastung, Datenzentrumsausfällen etc. implementiert werden.
Für einige Implementierungen sollte festgehalten werden, dass der DRM-Server konfiguriert werden kann, um zu jeder Zeit neue Anfragen zu bedienen, während gleichzeitig der DRM-Server oder jeder andere geeignete Erneuerungsserver veranlasst wird, Lizenzrechte für die älteste Sitzung das nächste Mal zu entziehen, wenn eine Lizenzerneuerungsanfrage für die Sitzung empfangen wird. Als Reaktion auf das Feststellen, dass eine Lizenzerneuerungsanfrage mit einer älteren Sitzung in der Warteschlange korrespondiert, welche für die Beendigung bestimmt war, kann der DRM-Lizenzserver auf die Lizenzerneuerungsanfrage mit einer Lizenzerneuerung mit Dauer Null oder einem anderen Mittel reagieren, um die Nichtfortsetzung von Medienrechten durchzusetzen. Dies kann von Vorteil sein, zum Beispiel um immer die jüngste Benutzeranfrage zu gestatten, anstatt eine neue Anfrage deswegen zu versagen, weil von Wiedergabesitzungen vermutet wird, dass sie noch anzudauern.
Bei 160 kann die Lizenzerneuerungsnachricht mit bestimmten Erneuerungsparametern vom DRM-Lizenzserver an das DRM-Clientgerät übertragen werden. Das DRM-Clientgerät kann, bei 170, bestimmen, ob die Wiedergabe des Medieninhaltegegenstands auf Grundlage der empfangenen Lizenzerneuerungsnachricht gestattet wird. Zum Beispiel kann das DRM-Clientgerät, wie oben beschrieben, auf Grundlage des Empfangens einer Lizenzerneuerungsnachricht die Erneuerungsparameter aus der empfangenen Lizenzerneuerungsnachricht auslesen und bestimmen, dass eine Verlängerung der Lizenz für eine bestimmte Dauer zulässig ist (z. B. eine weitere kurze Zeitspanne, welche gleich der Lizenzdauer der Initiallizenz ist, eine kurze Zeitspanne, die kürzer als die mit der Initiallizenz verknüpften Lizenzdauer etc). Die Wiedergabe des Medienwiedergabegegenstand mit der erneuerten Lizenz kann bei 180 fortgesetzt werden. Das DRM-Clientgerät kann zu 130 zurückkehren, wo zu einem späteren Zeitpunkt bestimmt werden kann, ob eine Lizenzerneuerung benötigt wird, um die Wiedergabe des Medieninhaltegegenstands fortzusetzen. Zum Beispiel kann das DRM-Clientgerät, vor Ablauf der erneuerten Lizenz (z. B. wenn ein Lizenzerneuerungs-Zeitfenster geöffnet wurde), feststellen, ob eine Lizenzerneuerung benötigt wird, um die Wiedergabe des Medieninhaltegegenstands fortzusetzen.
In einem weiteren Beispiel kann dem DRM-Clientgerät, wie oben beschrieben, als Reaktion auf das Empfangen der Lizenzerneuerungsnachricht, das Auslesen der Erneuerungsparameter aus der empfangenen Lizenzerneuerungsnachricht und das Feststellen, dass eine Lizenzerneuerung mit Dauer Null erteilt wurde (oder ein anderes Mittel, um die Nichtfortsetzung von Medienrechten durchzusetzen), der Zugriff auf die Schlüssel entzogen werden, was die Wiedergabe von Medieninhalten bei 190 beendet.
In einigen Implementierungen können unterschiedliche Durchsetzungsmodi in Verbindung mit dem offenbarten Gegenstand angewandt werden. In einem anschaulichen Beispiel, in welchem Lizenzspannen und Erneuerungsanfrageintervalle dynamisch durch den DRM-Lizenzserver angepasst werden können, kann der DRM-Lizenzserver solche Anpassungen vornehmen, um einen von einer Vielzahl von Durchsetzungsmodi zu implementieren.
Bezug nehmend auf 2 kann der DRM-Lizenzserver den Prozess 200 bei 210 durch das Empfangen einer Anfrage von einem Benutzergerät starten, das mit Anmeldedaten authentifiziert wurde, die mit einem Benutzerkonto korrespondieren. Zum Beispiel kann eine Anfrage eine Anfrage über eine Initiallizenz als Reaktion auf das Auswählen eines Medieninhaltegegenstands für die Wiedergabe sein.
Bei 220 kann der DRM-Lizenzserver eine Antwort auf die Anfrage in Übereinstimmung mit einem Durchsetzungsmodus mit bestimmten Lizenzparametern übertragen. Zum Beispiel kann der DRM-Lizenzserver jedes DRM-Clientgerät in einem initialen Nur-Erkennungsmodus starten lassen. In Fortsetzung dieses Beispiels kann der DRM-Lizenzserver, im initialen Nur-Erkennungsmodus, das Erneuerungsanfrageintervall auf fünf Minuten (oder jedes andere geeignete Anfrageintervall) festlegen und die Lizenzdauer auf eine Zeitspanne äquivalent zur Inhaltedauer des Medieninhaltegegenstand plus X Minuten (z. B. Inhaltedauer + x Minuten für Unterbrechungsinstruktionen, welche während der Wiedergabe des Medieninhaltegegenstands empfangen werden können etc.) festlegen. Es sollte festgehalten werden, dass jedes geeignete initiale Erneuerungsanfrageintervall und/oder die Lizenzdauer in diesem Nur-Erkennungs-Durchsetzungsmodus bereitgestellt werden kann.
In einigen Implementierungen kann der DRM-Lizenzserver bei 230 fortsetzen, indem er auf Verhaltensinformationen des Benutzerkontos zugreift und diese überprüft. Zum Beispiel kann der Prozess 200, als Reaktion auf das Empfangen einer Lizenzanfrage oder einer Lizenzerneuerungsanfrage von einem Benutzergerät, das mit Anmeldedaten authentifiziert wurde, die mit einem Benutzerkonto korrespondieren und in Verbindung mit dem DRM-Lizenzserver bestimmen, ob die Anfrage bedient werden soll, auf einen mit dem Benutzerkonto verknüpften Lizenzdatensatz zugreifen und feststellen, ob die Information im Benutzerkontodatensatz verdächtiges Verhalten anzeigt. Verdächtiges Verhalten kann, zum Beispiel, Informationen umfassen, welche die mögliche oder wahrscheinliche Unterdrückung von Erneuerungsanfragen durch ein oder mehrere mit dem Benutzerkonto verknüpfte Geräte anzeigen. In einem spezielleren Beispiel kann die DRM-Lizenz, als Reaktion auf das Erkennen anhand der Informationen im Benutzerkontodatensatz, dass das Benutzerkonto mehr als eine bestimmte Anzahl an neuen Lizenzanfragen über eine Vielzahl von Geräten hinweg generiert und keine neuen Erneuerungsanfragen innerhalb einer bestimmten Zeitspanne generiert, solche Verhaltensinformationen über das Benutzerkonto als einen Anhaltspunkt verwenden, dass Erneuerungsanfragen durch die mit dem Benutzerkonto verknüpften Geräte unterdrückt werden und entsprechend die Lizenz oder die Lizenzerneuerungsparameter anpassen.
In einigen Implementierungen kann der DRM-Lizenzserver, bei 240, die Lizenz oder die Lizenzerneuerungsparameter anpassen. Zum Beispiel kann der DRM-Lizenzserver, als Reaktion auf das Erkennen der möglichen Unterdrückung von Erneuerungsanfragen (oder jedes anderen geeigneten Verhaltens in Verbindung mit dem Benutzerkonto) veranlassen, dass das Benutzerkonto in einen unterschiedlichen Durchsetzungsmodus mit angepassten Lizenzparametern versetzt wird. Allgemein gesprochen kann es sich dabei um einen strikteren Durchsetzungsmodus handeln, welcher beispielsweise eine kürzere Lizenzdauer und/oder ein häufiger auftretendes Erneuerungsanfrageintervall beinhaltet.
Wie in 2 gezeigt, kann die DRM-Lizenz, während der DRM-Lizenzserver weiterhin Anfragen von einem oder mehreren mit dem Benutzerkonto verknüpften Geräten empfängt, zu 230 zurückkehren und die Überprüfung von Verhaltensinformationen zu einem Benutzerkonto fortsetzen. Als solches kann der DRM-Lizenzserver, als Reaktion auf das Fortsetzen der Erkennung der möglichen Unterdrückung von Erneuerungsanfragen (oder jedes anderen verdächtigen Verhaltens in Verbindung mit dem Benutzerkonto), es veranlassen, dass das Benutzerkonto in noch einen weiteren Durchsetzungsmodus mit angepassten Lizenzparametern versetzt wird – z. B. in einen strikteren Durchsetzungsmodus mit einer weiter angepassten Lizenzdauer und/oder einem weiter angepassten Erneuerungsanfrageintervall.
In einigen Implementierungen kann der DRM-Lizenzserver, bei 250, feststellen, ob der gegenwärtige Durchsetzungsmodus auf Grundlage von Verhaltensinformationen über das Benutzerkonto angepasst werden soll. Zum Beispiel kann der DRM-Lizenzserver, in Reaktion auf das Feststellen einer geringeren Wahrscheinlichkeit, dass die mit dem Benutzerkonto verknüpften Geräte Erneuerungsanfragen unterdrücken oder verdächtiges Verhalten an den Tag legen, den Durchsetzungsmodus modifizieren oder anderweitig die Lizenzparameter anpassen, welche mit Anfragen von mit dem Benutzerkonto verknüpften Geräten verknüpft sind. In einem spezielleren Beispiel kann der DRM-Lizenzserver eine Vielzahl von Levels der Durchsetzung und, in Reaktion auf Benutzerkonto-Verhaltensinformationen, auch feststellen, ob das Durchsetzungslevel verschärft oder gelockert werden soll (z. B. von einem Nur-Erkennung-Durchsetzungsmodus in einen strikteren Durchsetzungsmodus). In einem weiteren spezielleren Beispiel kann der DRM-Lizenzserver, als Reaktion auf das Erkennen, dass eine bestimmte Zeitspanne vergangen ist, das Durchsetzungslevel in einen weniger strikten Durchsetzungsmodus lockern. In noch einem weiteren spezielleren Beispiel kann der DRM-Lizenzserver, als Reaktion auf das Erkennen, dass eine bestimmte Zeitspanne vergangen ist und dass die mit dem Benutzerkonto verknüpften Geräte weiterhin verdächtiges Verhalten an den Tag legen, Lizenzen oder Lizenzerneuerungen mit der Dauer Null erteilen, wodurch die Verwendung der Medienschlüssel eingestellt oder entzogen wird.
Ein anschauliches Beispiel einer Vielzahl von anwendbaren Durchsetzungsmodi wird in 3 gezeigt.
Wie gezeigt, kann der DRM-Lizenzserver in Anwendung eines Nur-Erkennungsmodus mit einem bestimmten Erneuerungsintervall und einer bestimmten Lizenzdauer bei 310 beginnen. Zum Beispiel kann der DRM-Lizenzserver, wie oben in Verbindung mit 2 beschrieben, jedes DRM-Clientgerät in einem initialen Nur-Erkennungsmodus starten lassen. In Fortsetzung dieses Beispiels kann der DRM-Lizenzserver, im initialen Nur-Erkennungsmodus, das Erneuerungsanfrageintervall auf fünf Minuten (oder jedes andere geeignete Anfrageintervall) festlegen und die Lizenzdauer auf eine Zeitspanne äquivalent zur Inhaltedauer des Medieninhaltegegenstand plus X Minuten (z. B. Inhaltedauer + x Minuten für Unterbrechungsinstruktionen, welche während der Wiedergabe des Medieninhaltegegenstands empfangen werden können etc.) festlegen. Es sollte festgehalten werden, dass jedes geeignete initiale Erneuerungsanfrageintervall und/oder die Lizenzdauer in diesem Nur-Erkennungs-Durchsetzungsmodus bereitgestellt werden kann.
Während des Nur-Erkennungsmodus kann der DRM-Lizenzserver fortgesetzt Anfragen von mit einem Benutzerkonto verknüpften Benutzergeräten empfangen und es kann, als Reaktion auf das Erkennen der möglichen Unterdrückung von Erneuerungsanfragen (oder jedes anderen verdächtigen Verhaltens in Verbindung mit dem Benutzerkonto), indem bei 320 ein Lizenzdatensatz abgefragt wird und mit dem Benutzerkonto verknüpfte Verhaltensinformationen überprüft werden, bei 330 ein lockerer Durchsetzungsmodus mit angepasstem Erneuerungsintervall und/oder Lizenzdauerparametern angewandt werden. Zum Beispiel kann der DRM-Lizenzserver, als Reaktion auf das Überprüfen von Verhaltensinformationen über ein Benutzerkonto und das Erkennen, dass ein Benutzerkonto mehr als eine bestimmte Anzahl an neuen Lizenzanfragen (z. B. über eine Vielzahl von Geräten hinweg) und keine Erneuerungsanfragen innerhalb einer bestimmten Zeitspanne generiert, solche Verhaltensinformationen über ein Benutzerkonto als ein Anzeichen dafür verwenden, dass Erneuerungsanfragen gegenwärtig unterdrückt werden und veranlassen, dass das Benutzerkonto in einen lockeren Durchsetzungsmodus versetzt wird.
Im lockeren Durchsetzungsmodus kann der DRM-Lizenzserver das Eneuerungsanfrageintervall und/oder die Lizenzdauer anpassen. In Fortsetzung des oben genannten Beispiels kann der DRM-Lizenzserver das Erneuerungsanfrageintervall bei fünf Minuten (oder jedes anderen geeigneten Anfrageintervalls) belassen und die Lizenzdauer auf eine Menge gleich der Hälfte der Inhaltedauer festlegen (Inhaltedauer 2). Es sollte festgehalten werden, dass das Festlegen der Lizenzdauer äquivalent zur Hälfte der Inhaltedauer des Medieninhaltegegenstands lediglich veranschaulichend gemeint ist und dass jede beliebige Lizenzdauer festgelegt werden kann, welche kürzer als die Inhaltedauer des Medieninhaltegegenstands und/oder kürzer als die Lizenzdauer im Nur-Erkennungs-Modus ist. Als Reaktion auf das Unterdrücken von Erneuerungsanfragen durch den Benutzer eines Benutzerkontos wird ein solches Benutzerkonto nicht in der Lage sein, ein Stück Medieninhalte in seiner Gesamtheit zu konsumieren.
Während des lockeren Durchsetzungsmodus kann der DRM-Lizenzserver fortgesetzt Anfragen von mit einem Benutzerkonto verknüpften Benutzergeräten empfangen und es kann, als Reaktion auf das Erkennen der möglichen Unterdrückung von Erneuerungsanfragen (oder jedes anderen verdächtigen Verhaltens in Verbindung mit dem Benutzerkonto), indem bei 340 ein Lizenzdatensatz abgefragt wird und mit dem Benutzerkonto verknüpfte Verhaltensinformationen überprüft werden. Zum Beispiel kann der DRM-Lizenzserver, als Reaktion auf das Empfangen von Lizenzanfragen oder Lizenzerneuerungsanfragen von mit dem Benutzerkonto verknüpften Geräten, diese Gelegenheit nutzen, außerdem die Verhaltensinformationen über das Benutzerkonto auf Grundlage des Lizenzdatensatzes zu überprüfen.
Unter Rückbezugnahme auf 3 kann, als Reaktion auf das Feststellen, dass Informationen über das Benutzerkontoverhalten weiterhin indizieren, dass die mit dem Benutzerkonto verknüpften Geräte recht wahrscheinlich auf verdächtiges Verhalten schließen kann, ein strikter Durchsetzungsmodus mit weiter angepasstem Erneuerungsintervall oder weiter angepassten Lizenzdauerparametern angewandt werden. Zum Beispiel kann der DRM-Lizenzserver den strikten Durchsetzungsmodus als Reaktion auf das Feststellen, dass eine bestimmte Zeitspanne abgelaufen ist und die mit dem Benutzerkonto verknüpften Geräte Verhalten an den Tag legen, welches indiziert, dass die Geräte möglicherweise Lizenzerneuerungsanfragen unterdrücken. In einem weiteren Beispiel kann der DRM-Lizenzserver, als Reaktion auf das Erkennen bestimmter im Lizenzdatensatz aufgezeichneter Ereignisse, wie etwa den Empfang von zwei oder mehr neuen Lizenzanfragen für denselben Medieninhaltegegenstand auf demselben Gerät oder dem Empfang von einer verdächtigen Lizenzerneuerungsanfrage, den strikten Durchsetzungsmodus anwenden.
In einem spezielleren Beispiel kann der DRM-Lizenzserver, als Reaktion auf das Erkennen, dass ein Benutzerkonto konsistent zwei oder mehr neue Lizenzanfragen für denselben Medieninhalt auf demselben Gerät generiert, oder als Reaktion auf das Empfangen einer verdächtigen Erneuerungsanfrage vom Gerät (z. B. wenn sich der Zeitpunkt seit der letzten Erneuerungsanfrage nahe der Lizenzdauer anstatt dem Erneuerungsintervall von fünf Minuten befindet), solche Informationen vom Lizenzdatensatz als einen Hinweis darauf verwenden, dass gegenwärtig Erneuerungsanfragen unterdrückt werden und dass ein Neuladen nach der Hälfte des Inhalts durchgeführt wird (wenn die Lizenz abläuft). Es sollte festgehalten werden, dass in den lockeren Durchsetzungsmodus versetzte Benutzerkonten nur geringfügig mehr durch Serverausfälle beeinträchtigt werden können, da nur ein ausgedehnter Ausfall die Wiedergabe von Medieninhaltegegenständen stoppen kann. Es sollte außerdem festgehalten werden, dass wenn das verdächtige Verhalten fortgesetzt wird, das Benutzerkonto in einen strikteren Durchsetzungsmodus oder jeden anderen geeigneten Modus versetzt werden kann, der restriktiver ist.
Im strikten Durchsetzungsmodus kann der DRM-Lizenzserver das Eneuerungsanfrageintervall und/oder die Lizenzdauerparameter weiter anpassen. In Fortsetzung des oben angesprochenen Beispiels kann der DRM-Lizenzserver die Erneuerungszeit auf drei Minuten (oder jedes andere geeignete Anfrageintervall) festlegen und die Lizenzdauer auf fünf Minuten (oder jede andere geeignete Dauer) festlegen. Entsprechend kann ein Benutzer eines Benutzerkontos mehr als fünf Minuten Medieninhalt am Stück ansehen, wenn Erneuerungsanfragen unterdrückt werden. Es sollte festgehalten werden, dass Benutzerkonten im strikten Durchsetzungsmodus nur durch Serverausfälle von mehr als einigen Minuten (z. B. zwei Minuten) beeinträchtigt werden können.
Für einige Implementierungen sollte außerdem festgehalten werden, dass nach dem Ablauf einer bestimmten Zeitspanne (z. B. eine Woche, zwei Wochen etc.), der DRM-Lizenzserver bei 360 das Benutzerkonto in einen lockereren Modus versetzen kann, wie etwa, oben beschrieben, den lockeren Durchsetzungsmodus oder den Nur-Erkennungsmodus.
Es sollte festgehalten werden, dass die Benutzererfahrung für in einen lockereren Durchsetzungsmodus versetzte Benutzerkonten möglicherweise nicht beeinträchtigt wird und dass die Beeinträchtigung von Serverressourcen möglicherweise nicht beeinflusst wird, da die meisten Benutzer allgemein in Kategorien fallen, die mit einem lockeren Durchsetzungsmodus verknüpft sind. Es sollte außerdem festgehalten werden, dass sich das versetzt werden in einen restriktiveren Modus auf die nicht missbrauchenden Benutzer und ihre Nutzererfahrung möglicherweise nur im Falle eines Erneuerungsserverausfalls negativ auswirkt, aber selbst bei einem solchen Ausfall, den Benutzern ausreichend lange Toleranzzeiten gegeben werden können und verdächtige Benutzer einen alternativen Server erreichen können.
4 zeigt ein Beispiel 400 eines verallgemeinerten schematischen Diagramms eines Systems, auf dem die Mechanismen des Mediensitzungs-Parallelitätsmanagements mit wiederkehrenden Lizenzerneuerungen, wie sie hier beschrieben werden, in Übereinstimmung mit manchen Implementierungen implementiert werden kann. Wie veranschaulicht, kann das System 400 eines oder mehrere Benutzergeräte 410 beinhalten. Benutzergeräte 410 können lokal zueinander oder entfernt voneinander sein. Benutzergeräte 410 können durch eine oder mehrere Kommunikationsverbindungen 408 mit Kommunikationsnetzwerk 406 verbunden sein, das über eine Kommunikationsverbindung 404 mit einem Server, etwa dem Digitalrechtemanagement(DRM)-Lizenzierungsserver 402 verbunden sein kann.
System 400 kann einen oder mehrere Server 402 beinhalten. Server 402 kann jeder geeignete Server zum Bereitstellen von Zugriff auf die hier beschriebenen Mechanismen für das Mediensitzungs-Übereinstimmungsmanagement mit wiederkehrenden Lizenzerneuerungen sein, wie beispielsweise ein Prozessor, ein Computer, ein Datenverarbeitungsgerät oder jede geeignete Kombination solcher Geräte. In einigen Implementierungen kann DRM-Lizenzserver 402, welcher die Lizenzanfragen und Lizenzerneuerungsanfragen handhabt, auf eine beliebige geeignete Anzahl an Servern aufgeteilt werden. Zum Beispiel können, wie oben beschrieben und in 4 gezeigt, die Mechanismen für das Erteilen einer Initiallizenz und das Erteilen von Lizenzerneuerungen auf mehrere Backend-Komponenten und mehrere Frontend-Komponenten und/oder Schnittstellen aufgeteilt werden. In einem spezielleren Beispiel kann ein DRM-Lizenzserver 402 bereitgestellt werden, welcher die Initiallizenzanfragen von einem oder mehreren Benutzergeräten 410 handhabt, welche mit einem oder mehreren Medienschlüsseln antworten können; und ein oder mehrere Lizenzerneuerungsserver 420 können bereitgestellt werden, welche Lizenzerneuerungsanfragen handhaben, welche mit Richtliniendaten antworten können, die eine Ausweitung oder einen Entzug der Verwendung der Medienschlüssel anzeigen können. In diesem Beispiel kann das Vorhandensein einer Vielzahl von Servergeräten 402 und 410 das Reagieren auf Lizenzerneuerungsanfragen veranlassen, beispielsweise schneller zu sein als das Reagieren auf initiale Lizenzanfragen, was die Wiedererlangung von Medienschlüsseln und die Einbindung von Medienschlüssen in die Lizenz beinhalten kann. Dies kann es dem einen oder den mehreren Lizenzerneuerungsservern 420, welche Lizenzerneuerungen handhaben, auch erlauben vom Schlüsselserver oder Schlüsselspeichergerät, wie auch von der Benutzerkontodatenbank, gelöst zu agieren. Wie hier weiter unten beschrieben wird, kann diese weiter dem System 400 gestatten, eine Vielzahl von Servern zu beinhalten, die Lizenzerneuerungen handhaben (z. B. Serverzuverlässigkeit und -redundanz bereitzustellen).
In einigen Implementierungen kann eine Vielzahl von Lizenzservern 402 und 420 an verschiedenen Orten implementiert werden, um Zuverlässigkeit und/oder die Geschwindigkeit, mit welcher der Server mit den Benutzergeräten 410 kommunizieren (z. B. Mitteilung von Lizenzen oder Lizenzerneuerungen) kann, zu erhöhen.
In einigen Implementierungen kann noch ein weiterer Server (oder ein Satz Server) einen Datensatz mit Lizenzen und Lizenzerneuerungen für das Anzeigen der Anzahl paralleler Sitzungen pflegen.
Obwohl einige Implementierungen von Lizenzerneuerungen es benötigen können, dass Server 402 und 420 und Benutzergeräte 410 über geteiltes Wissen bezüglich der für die Authentifizierung von Nachrichten verwendeten Sitzungsschlüssel verfügen, können die hier beschriebenen Mechanismen implementiert werden, um solche Schlüssel zu berechnen, sodass sowohl der die initiale Lizenzanfrage bedienende Server 402 und der die Lizenzerneuerungsanfragen bedienende Server 420 dieselben Sitzungsschlüssel erlangen und authentifizieren und Nachrichten signieren kann, ohne irgendwelche Informationen untereinander austauschen zu müssen. Entsprechend kann, wenn der Lizenzserver 402 nicht in der Lage dazu ist, auf die für das Bedienen einer initialen Lizenzanfrage benötigten Infrastruktur zuzugreifen, der Lizenzerneuerungsserver 420 das Bedienen von Lizenzerneuerungsanfragen fortsetzen. Zusätzlich können die Lizenzserver 402 und/oder 420 konfiguriert werden, Lizenzen in einem Notfallmodus immer zu verlängern, so etwa wenn die Backend-Infrastruktur nicht verfügbar ist, was es ihnen unmöglich macht, die Parallelität zu überprüfen.
In solchen Implementierungen kann es nicht zur Unterbrechung existierender Medienwiedergabesitzungen kommen, wenn die Lizenzserver funktionieren und erreichbar sind (z. B. sogar wenn der ursprüngliche DRM-Server 402 nicht erreichbar ist). Entsprechend kann die Widerstandsfähigkeit durch das Hinzufügen von Lizenzserverredundanz erhöht werden und können Medienwiedergabeanwendungen eine Vielzahl von URLs für die Handhabung von Lizenzerneuerungsnachrichten oder -anfragen beinhalten. Dies kann es, zum Beispiel, Medienwiedergabeanwendungen gestatten, widerstandsfähiger gegenüber Serverunterbrechungen und -ausfällen zu sein.
In einigen Implementierungen kann das System 400 implementiert werden, die Widerstandsfähigkeit weiter zu erhöhen, indem Lizenzerneuerungsserver 420 über mehrere Standorte und Infrastrukturen hinweg aufgebaut werden. Dies kann, zum Beispiel, die Wahrscheinlichkeit erhöhen, dass Lizenzerneuerungsanfragen im Falle des Ereignisses gehandhabt werden, dass ein zentraler Server oder ein Datenzentrum unverfügbar wird.
Es sollte festgehalten werden, dass Lizenzerneuerungen allgemein über eine geringere Größe als Initiallizenzen verfügen, da Lizenzerneuerungen Richtliniendaten enthalten, die darauf hindeuten, ob die Verwendung der Medienschlüssel (und nicht die Medienschlüssel selbst) verlängert oder entzogen werden soll. Deshalb kann das Bedienen von Lizenzerneuerungsanfragen weniger Ressourcen benötigen, als das von Initiallizenzanfragen. Lizenzerneuerungsserver 420 kann dann vom Schlüsselserver/-speicher abgelöst sein, wie auch beispielsweise die Hauptdatenbank für Benutzerkonten. Entsprechend kann der Lizenzerneuerungsserver 420 sich von dem Server oder den Servern 402 unterscheiden, welche die initiale Lizenzanfrage bedienen. Dies kann, zum Beispiel, die Zuverlässigkeit auf dem Gesamtsystem 400 erhöhen.
In einigen Implementierungen des offenbarten Gegenstandes kann das hier beschriebene, die Parallelität durchsetzende System 400 implementiert werden, um die Zuverlässigkeit des die Parallelität durchsetzenden Systems unter Verwendung von dezentraler Redundanz zu erhöhen. Derartige Implementierungen können für Benutzer von Benutzerkonten relevant sein, welche in den oben genannten strikten Durchsetzungsmodus versetzt werden (z. B. da in einen Nur-Erkennungs- oder einen lockeren Durchsetzungsmodus versetzt werden, durch Serverausfälle nicht negativ beeinflusst werden können).
In einigen Implementierungen werden, wenn der initiale Lizenzanfragen bedienende Lizenzserver 402 unerreichbar wird, initiale Lizenzanfragen von der auf den Benutzergeräten 410 ausgeführte Medienwiedergabeanwendung fehlschlagen (z. B. 503 oder andere Fehlermeldungen). Zum Beispiel kann die Medienwiedergabeanwendung einen HTTP-Antwortcode empfangen, der anzeigt, dass der Lizenzserver 402 nicht in der Lage dazu war, eine Antwort auf die Lizenzanfrage bereitzustellen. Als Reaktion auf das Erkennen des Netzwerk- und/oder Serverausfalls bei einer Lizenzanfragenachricht kann die auf dem Clientgerät ausgeführte Medienwiedergabeanwendung eine Anfrage bezüglich der Lizenz unter Verwendung der URL für einen Ersatz-Lizenzserver 402 (z. B. der nächsten URL auf einer Liste von Lizenzservern) übertragen. Wie oben bemerkt kann die Medienwiedergabeanwendung auf eine Liste mit einer beliebigen geeigneten Anzahl von Ersatz-URLs für die Lizenzserver 402 zugreifen, einschließlich beispielsweise unterschiedlicher Cluster oder Datenzentren im Land, in einem anderen Land, auf einem anderen Kontinent etc. Die Medienwiedergabeanwendung kann die Übertragung von Lizenzanfragen an einen oder mehrere Ersatz-Lizenzserver 402 fortsetzen bis eine Lizenz empfangen wurde. Zum Beispiel kann die Medienwiedergabeanwendung versuchen, einen bestimmten Lizenzserver 402 eine bestimmte Anzahl Male zu erreichen, bevor zu den nächsten Lizenzservern 402 fortgeschritten wird. In einem weiteren Beispiel kann die Medienwiedergabeanwendung versuchen, einen Lizenzserver 402 an einem bestimmten Standort eine bestimmte Anzahl Male zu erreichen, bevor sie zu einem Lizenzserver 402 an einem anderen Standort fortschreitet (z. B. wenn ein Datenzentrum an der US-amerikanischen Westküste nicht erreichbar ist, zu versuchen, die Lizenzserver 402 an einem Standort an der Ostküste zu erreichen). Es sollte festgehalten werden, dass in einigen Implementierungen die Medienwiedergabeanwendung diese wiederholten Anfragen durchführen kann, bis dass ein Lizenzserver 402 verfügbar wird und eine Lizenz empfangen wurde.
In einigen Implementierungen werden, wenn der Lizenzerneuerungsanfragen bedienende Lizenzserver 420 unerreichbar wird, Lizenzerneuerungsanfragen von der auf den Benutzergeräten 410 ausgeführten Medienwiedergabeanwendung fehlschlagen (z. B. 503 oder andere Fehlermeldungen). Zum Beispiel kann die Medienwiedergabeanwendung einen HTTP-Antwortcode empfangen, der anzeigt, dass der Lizenzerneuerungsserver 420 nicht in der Lage dazu war, eine Antwort auf die Lizenzerneuerungsanfrage bereitzustellen. Als Reaktion auf das Erkennen des Netzwerk und/oder Serverausfalls während einer Lizenzerneuerungs-Anfragenachricht kann die auf dem Clientgerät ausgeführte Medienwiedergabeanwendung eine Anfrage bezüglich einer Lizenzerneuerung unter Verwendung der URL für einen Ersatz-Lizenzerneuerungsserver 420 (z. B. die nächste URL auf einer Liste von Lizenzerneuerungsservern) übertragen. Wie oben bemerkt kann die Medienwiedergabeanwendung auf eine Liste mit einer beliebigen geeigneten Anzahl von Ersatz-URLs für die Lizenzerneuerungsserver 420 zugreifen, einschließlich beispielsweise unterschiedlicher Cluster oder Datenzentren im Land, in einem anderen Land, auf einem anderen Kontinent etc. Die Medienwiedergabeanwendung kann die Übertragung von Lizenzerneuerungsanfragen an einen oder mehrere Ersatz-Lizenzerneuerungsserver 402 fortsetzen, bis eine Lizenz empfangen wurde. Zum Beispiel kann die Medienwiedergabeanwendung versuchen, einen bestimmten Lizenzerneuerungsserver 420 eine bestimmte Anzahl Male zu erreichen, bevor sie zum nächsten Lizenzerneuerungsserver 420 fortschreitet. In einem weiteren Beispiel kann die Medienwiedergabeanwendung versuchen, einen Lizenzerneuerungsserver 420 an einem bestimmten Standort eine bestimmte Anzahl Male zu erreichen, bevor sie zu einem Lizenzerneuerungsserver 420 an einem anderen Standort fortschreitet (z. B. wenn ein Datenzentrum an der US-amerikanischen Westküste nicht erreichbar ist, zu versuchen, die Lizenzerneuerungsserver 420 an einem Standort an der Ostküste zu erreichen). Es sollte festgehalten werden, dass in einigen Implementierungen die Medienwiedergabeanwendung diese Versuche, eine Lizenzerneuerung von einem Lizenzerneuerungsserver 420 zu empfangen, durchführen kann, während die Lizenzdauer der gegenwärtig aktiven Lizenz nicht abgelaufen ist.
In einigen Implementierungen kann der Lizenzserver 402 das Bedienen initialer Lizenzanfragen beginnen, indem er auf die Benutzerdatenbank und den Inhaltsschlüsselspeicher zugreift, um die Lizenzanfrage zu erfüllen. Es sollte festgehalten werden, dass falls das Lizenzserverbackend unverfügbar ist, der Server die Lizenzanfrage zurückweist (z. B. wird eine 500, 503 oder eine andere Fehlernachricht empfangen). Der Lizenzserver 402 kann dann den Datensatz mit Lizenzanfragen oder parallele Verwendung überprüfen (z. B. Datensatz 422 auf dem Lizenzerneuerungsserver 420 oder jedem anderen geeigneten Server). Ebenso sollte festgehalten werden, dass wenn die Parallelitätsinfrastruktur unverfügbar ist, der Server auswählen kann, ob er die Anfrage bedient oder eine Fehlermitteilung sendet (z. B. wird eine 500, 503 oder eine andere Fehlernachricht empfangen). Auf Grundlage der Parallelitätsinformation kann der Lizenzserver 402 die Lizenzanfrage zurückweisen oder bedienen. Alternativ kann der Lizenzserver 402, wie oben beschrieben, konfiguriert werden, neue Lizenzanfragen immer zu bedienen, während ältere Lizenzen für die Nichtfortsetzung markiert werden.
In einigen Implementierungen kann der Lizenzerneuerungsserver 420 beginnen, Lizenzerneuerungsanfragen zu bedienen, indem er einen Datensatz mit Erneuerungsanfragen oder gleichzeitiger Benutzung prüft, wie etwa Lizenzdatensatz 422 auf dem Lizenzerneuerungsserver 420. Wenn die Sitzung für die Nichtfortsetzung markiert ist, kann der Lizenzserver 420 Lizenzerneuerungsanfragen versagen oder eine Antwort senden, dass die Wiedergabe eingestellt werden sollte. Anderweitig kann der Lizenzerneuerungsserver 420 eine Lizenzerneuerung erteilen.
In einigen Implementierungen kann der Lizenzserver 402 oder 420, falls er nicht in der Lage dazu ist, auf den Datensatz mit Erneuerungsanfragen oder paralleler Verwendung oder jeder anderen geeigneten Information, die verwendet wird, um zu bestimmen, ob eine Lizenzerneuerung erteilt werden soll (z. B. Datensatz 422), bestimmen, ob in einen Notfallerneuerungsmodus eingetreten werden soll. Zum Beispiel kann der Lizenzserver 402 oder 420, in Reaktion darauf, dass die Anzahl fehlgeschlagener Versuche, auf einen Datensatz an einer Backend-Serverkomponente zuzugreifen, größer ist als ein gegebener Grenzwert, bestimmen, dass der Server in einen Notfallerneuerungsmodus eintritt, in dem eine solche Erkennung protokolliert werden kann, Warnungen ausgelöst werden können etc. Im Notfallerneuerungsmodus kann der Lizenzserver 420 automatisch alle gültigen Lizenzen erneuern. In einigen Implementierungen des Notfallerneuerungsmodus kann die Lizenzdauer und/oder das Erneuerungsanfrageintervall erhöht werden (z. B. um den Server von Erneuerungsnachrichten während eines Serverausfalls oder einer Serverüberlastung zu befreien).
Rückbezug nehmend auf 4 können andere Server im System 400 beinhaltet sein. Zum Beispiel kann das Inhaltsbereitstellungsserver 430 Anfragen empfangen, einen Medieninhaltegegenstand darzustellen und den Medieininhaltsgegenstand bereitstellen (z. B. in einer verschlüsselten Form, welche Schlüssel von DRM-Lizenzserver 402 oder jedem anderen geeigneten Server benötigt, um die Mediendaten zu entschlüsseln). In einem anderen Beispiel kann der Inhaltsbereitstellungsserver 430 Metadaten oder andere mit dem Medieninhalt korrespondierende Informationen bereitstellen, die auf dem Benutzergerät 410 dargestellt werden.
Allgemein können Benutzergeräte 410 beliebige Computergeräte beinhalten, die in der Lage dazu sind, Nachrichten über ein Netzwerk zu empfangen oder zu senden, auf Inhalt zuzugreifen und/oder ihn abzuspielen, wie etwa Netzwerk 406 oder dergleichen. des Weiteren können Benutzgeräte 410 beliebige Computergeräte beinhalten, die in der Lage dazu sind, sich mit anderen Computergeräten zu verbinden und Informationen zu empfangen, wie etwa ein Laptop-Computer, ein Smartphone, ein Tablet-Computer und dergleichen. Jedoch sind Computergeräte nicht darauf zu beschränken und können ebenso andere Geräte wie etwa Mobiltelefone, Pager mit Anzeige, Radiofrequenz(„RF“)-Geräte, Infrarot(„IR“)-Geräte, Persönliche Digitale Assistenten („PDAs“), Handgerät-Computer, Tragbare Computer, integrierte Geräte, welche eines oder mehrere der vorstehenden Geräte vereinen und dergleichen umfassen. Als solche bewegen sich Benutzergeräte 410 typischerweise in einem weiten Rahmen in Bezug auf Anwendungsmöglichkeiten und Eigenschaften.
In einigen Implementierungen kann ein internetfähiges Benutzergerät 410 eine Browseranwendung beinhalten, die konfiguriert wurde, Webseiten, web-basierte Nachrichten und dergleichen zu empfangen und zu versenden. Die Browseranwendung kann konfiguriert werden, Graphiken, Text, Multimedia, Medieninhalt und dergleichen in Anwendung nahezu jedes internetbasierten und/oder netzwerkbasierten Protokolls zu empfangen und darzustellen, einschließlich aber nicht beschränkt auf kabellose Anwendungsprotokollnachrichten („WAP“), Hypertext Transfer Protocol („HTTP“), oder dergleichen. In einer Implementierung wird die Browseranwendung in die Lage versetzt, Handheld Device Markup Language („HDML“), Wireless Markup Language („WML“), WMLScript, JavaScript, Standard Generalized Markup Language („SGML“), HyperText Markup Audio Language („HTML“), extensible Markup Language („XML“) und dergleichen anzuwenden, um Nachrichten darzustellen und zu versenden. In einer Implementierung kann ein Benutzer eines Clientbenutzergeräts die Browseranwendung einsetzen, um verschiedene Aktivitäten über ein Netzwerk (online) durchzuführen. Allerdings kann auch eine andere Anwendung verwendet werden, um verschiedene Onlineaktivitäten durchzuführen.
Benutzergeräte 410 können auch mindestens eine andere Clientanwendung beinhalten, welche konfiguriert wurde, Inhalte zwischen anderen Computergeräten zu empfangen und/oder zu senden. Die Clientanwendung kann eine Fähigkeit beinhalten, Inhalte zu senden und/oder zu empfangen oder dergleichen. Die Clientanwendung kann weiter Informationen zur Selbstidentifizierung bereitstellen, einschließlich eines Typs, einer Fähigkeit, eines Namens und dergleichen. In einer Implementierung können sich die Benutzergeräte 410 selbst als Teil einer Geräteklasse identifizieren. In einer anderen Implementierung können sich die Benutzergeräte 410 eindeutig über eine Vielfalt von Mechanismen identifizieren, einschließlich einer Rufnummer, einer mobilen Identifikationsnummer („MIN“), einer elektronischen Seriennummer („ESN“), einer Internetprotokoll(IP)-Adresse, einer Netzwerkadresse oder einer anderen mobilen Gerätekennung. Die Informationen können außerdem auf ein Inhaltsformat verweisen, welche dem mobilen Gerät anzuwenden ermöglicht wurde. Solche Informationen können in einem Netzwerkpaket oder dergleichen bereitgestellt werden, das zwischen anderen Clientgeräten oder anderen Computergeräten versendet wurde. Außerdem sollte ohne weiteres verstanden werden, dass Geräte und/oder Komponenten innerhalb eines Geräts, das mit einem Clientgerät kommuniziert, sich selbst ebenso unter Verwendung eines beliebigen einer Vielzahl von Mechanismen identifizieren können, einschließlich der von dem Clientgerät verwendeten.
Benutzergeräte 410 können weiter konfiguriert werden, eine Clientanwendung zu beinhalten, welche es einem Benutzer ermöglicht, sich in ein Benutzerkonto einzuloggen, das möglicherweise durch andere Computergeräte verwaltet wird. Derlei Benutzerkonten können, als nicht einschränkendes Beispiel, konfiguriert werden, es dem Benutzer zu ermöglichen, eine oder mehrere Online-Aktivitäten zu verwalten, einschließlich, als nicht einschränkendes Beispiel, Suchaktivitäten, soziale Netzwerkaktivitäten, das Besuchen verschiedener Websites, mit anderen Benutzern zu kommunizieren oder dergleichen mehr. In einer Implementierung kann das Clientgerät des Benutzers Inhalte empfangen, die für die Wiedergabe am Clientgerät auf das Clientgerät gestreamt werden. Jedoch kann die Teilnahme an Online-Aktivitäten ebenso ohne das Einloggen in das Benutzerkonto durchgeführt werden.
In einigen Implementierungen kann jedes der Benutzergeräte 410 und der Server 402, 420 und 430 ein beliebiges Universalgerät wie beispielsweise ein Computer oder ein für spezifische Aufgaben vorgesehenes Gerät, wie ein Client, ein Server etc. sein. Jedes dieser allgemeinen oder für spezifische Aufgaben vorgesehenen Geräte kann beliebige geeignete Komponenten, wie einen Hardwareprozessor (der ein Mikroprozessor, ein digitaler Signalprozessor, eine Steuerung usw. sein kann), Speicher, Kommunikationsoberflächen, Anzeigesteuerungen, Eingabegeräte etc. beinhalten. Zum Beispiel kann Benutzergerät 410 implementiert werden als ein Smartphone mit einer Kamera, einem Tablet-Computer mit einer Kamera, einem tragbaren Computer mit einer Kamera, einem Kameragerät mit einer Schnittstelle zu einem Smartphone (z. B. einem Kamera-Dongle für ein Smartphone), einer Digitalkamera (z. B. einer Schnappschusskamera, einer DSLR-Kamera, einem digitalen Camcorder etc.), einem analogen Camcorder, einem PC, einem Laptop-Computer, einem Smartphone, einem Tablet-Computer, einer Spielekonsole, einem digitalen Medienreceiver, einer Set-Top-Box, einem intelligenten Fernseher, einem Server etc).
Das Kommunikationsnetzwerk 406 kann jedes beliebige Computernetzwerk oder eine Kombination solcher Netzwerke, einschließlich des Internets, eines Intranets, eines Großraumnetzwerks (WAN), eines lokalen Netzwerks (LAN), eines drahtlosen Netzwerks, eines WLAN-Netzwerks, eines DSL-Netzwerks, eines Frame-Relay-Netzwerks, eines asynchronen Transfermodus(ATM)-Netzwerks, eines virtuellen privaten Netzwerks (VPN) sein. Die Kommunikationsverbindungen 404, 408, 425 und 435 können beliebige Kommunikationsverbindungen sein, die geeignet sind, Daten unter den Benutzergeräten 410 und den Servern 402, 420 und 430, wie beispielsweise Netzwerkanbindungen, Wählverbindungen, drahtlose Verbindungen, drahtgebundene Verbindungen, beliebige andere geeignete Kommunikationsverbindungen oder jede geeignete Kombination aus diesen Verbindungen. Benutzergeräte 410 können auch verwendet werden, um einem Zuschauer Videos vom Inhaltebereitstellungsserver 430 oder von jeder anderen beliebigen geeigneten Quelle darzustellen (z. B. einer Festplatte, einem Cloudspeicher, einem Flash-Speicher etc). Benutzergeräte 410 und Server 402, 420 und 430 können sich an jedem beliebigen geeigneten Standort befinden:
5 zeigt ein Beispiel 500 von Hardware, die verwendet werden kann, um Server 402 (oder Server 420 oder 430) und eines der in 4 dargestellten Benutzergeräte 410 in Übereinstimmung mit einigen Ausführungsformen des offenbarten Gegenstandes zu implementieren. Unter Bezugnahme auf 5 kann das Benutzergerät 410 einen Hardwareprozessor 512, eine Anzeige 514, ein Eingabegerät 516 und einen Speicher 518 umfassen, die miteinander verbunden werden können. In einigen Implementierungen kann der Speicher 518 ein Speichergerät (wie beispielsweise ein nichtflüchtiges, computerlesbares Medium) zum Speichern eines Computerprogramms zum Steuern des Hardwareprozessors 512 beinhalten.
Hardwareprozessor 512 kann das Computerprogramm verwenden, um auf Anzeige 514 Inhalte und/oder eine Schnittstelle darzustellen, welche es einem Benutzer unter anderem erlaubt, zu veranlassen, dass ein Video von Server 430 abgerufen wird, mit der Medienwiedergabeanwendung zu interagieren, mit den hier beschriebenen Mechanismen für das Ressourcenmanagement mit wiederkehrenden Lizenzerneuerungen zu interagieren, die auf einem Gerät ausgeführt werden, wie etwa DRM-Lizenzserver 402 oder Lizenzerneuerungsserver 420 und Daten über die Kommunikationsverbindung 408 zu senden und zu empfangen. Es sollte auch angemerkt werden, dass Daten, die durch Kommunikationsverbindung 408 oder irgendwelche anderen Kommunikationsverbindungen empfangen werden, von jeder geeigneten Quelle empfangen werden können. In einigen Implementierungen kann Hardwareprozessor 512 Daten über Kommunikationsverbindung 408 oder andere Kommunikationsverbindungen beliebiger Art übertragen, zum Beispiel unter Verwendung eines Senders, eines Empfängers, eines Sendeempfängers, eines Transceivers und/oder eines anderen geeigneten Kommunikationsgeräts beliebiger Art. Bei Anzeige 514 kann es sich um einen Flachbildschirm, einen Kathodenstrahl-Röhrenbildschirm, einen Projektor, einen Touchscreen, einen oder mehrere Lautsprecher und/oder beliebige andere geeignete Anzeige- und/oder Präsentationsgeräte handeln. Das Eingabegerät 516 kann eine Computertastatur, eine Computermaus, ein Mikrofon, ein Touchpad, eine Spracherkennungsschaltung, ein Touchscreen und/oder jedes andere geeignete Eingabegerät sein. Server 402 (oder Server 420 oder 430) kann einen Hardwareprozessor 522, eine Anzeige 524, ein Eingabegerät 526 und einen Speicher 528 beinhalten, die miteinander verbunden sein können. In einigen Implementierungen kann der Speicher 228 ein Speichergerät zum Speichern von Daten beinhalten, die über die Kommunikationsverbindung 104 oder durch andere Verbindungen empfangen werden. Das Speichergerät kann ferner ein Serverprogramm zum Steuern des Hardwareprozessors 222 beinhalten.
Hardwareprozessor 522 kann das Serverprogramm verwenden, um mit den Benutzergeräten 412 zu kommunizieren. Es sollte auch festgehalten werden, dass Daten, die durch Kommunikationsverbindung 404 oder irgendwelche anderen Kommunikationsverbindungen empfangen werden, von jeder geeigneten Quelle empfangen werden können. In einigen Implementierungen kann Hardwareprozessor 522 Daten über Kommunikationsverbindung 404 oder andere Kommunikationsverbindungen beliebiger Art übertragen, zum Beispiel unter Verwendung eines Senders, eines Empfängers, eines Sendeempfängers, eines Transceivers und/oder eines anderen geeigneten Kommunikationsgeräts beliebiger Art. In einigen Implementierungen kann Hardwareprozessor 522 durch einen oder mehrere Benutzer übertragene Befehle und/oder Werte empfangen. Anzeige 524 kann ein Flachbildschirm, ein Kathodenstrahl-Röhrenbildschirm, ein Projektor, ein Touchscreen, ein oder mehrere Lautsprecher und/oder beliebige andere geeignete Anzeige- und/oder Präsentationsgeräte sein. Das Eingabegerät 526 kann eine Computertastatur, eine Computermaus, ein Mikrofon, ein Touchpad, eine Spracherkennungsschaltung, ein Touchscreen und/oder jedes andere geeignete Eingabegerät sein.
In einer bestimmten Implementierung können die hier beschriebenen Mechanismen eine serverseitige Software, eine serverseitige Hardware, eine clientseitige Software, eine clientseitige Hardware oder eine jede geeignete Kombination davon beinhalten. Zum Beispiel kann die Medienwiedergabeanwendung ein in einer Programmiersprache geschriebenes Computerprogramm umfassen, die von Server 402 erkannt wird, welcher die Bearbeitungsanwendung ausführt (z. B. ein in einer Programmiersprache wie etwa Java, C, Objective-C, C++, C#, JavaScript, Visual Basic oder jedem anderen geeigneten Ansatz geschriebenes Programm). Als weiteres Beispiel können diese Mechanismen eine oder mehrere Webseiten oder Webseitenabschnitte umfassen (z. B. über jede geeignete Codierung wie Hyper Text Markup Language („HTML“), Dynamic Hyper Text Markup Language („DHTML“), Extensible Markup Language („XML“), JavaServer Pages („JSP“), Active Server Pages („ASP“), Cold Fusion oder andere geeignete Ansätze).
Entsprechend werden Systeme, Verfahren und Medien für Mediensitzungs-Parallelitätsmangement mit wiederkehrenden Lizenzerneuerungen bereitgestellt.
In einigen Implementierungen können geeignete computerlesbare Medien jeder Art zum Speichern von Befehlen verwendet werden, um die Funktionen und/oder Prozesse hierin auszuführen. In einigen Implementierungen können beispielsweise computerlesbare Medien flüchtig oder nichtflüchtig sein. nichtflüchtige computerlesbare Medien können beispielsweise Medien wie magnetische Medien (wie Festplatten, Disketten usw.), optische Medien (wie Compact Disc, Digital Video Discs, Blu-ray-Disks usw.), Halbleitermedien (wie Flash-Speicher, elektrisch programmierbarer Festwertspeicher (EPROM), elektrisch löschbarer und programmierbarer Festwertspeicher (EEPROM) usw.), irgendwelche geeigneten Medien, die nichtflüchtig oder frei von einem Anschein von Dauerhaftigkeit während der Übertragung sind, und/oder irgendwelche geeigneten physisch greifbaren Medien beinhalten. Als ein weiteres Beispiel können flüchtige computerlesbare Medien Signale auf Netzwerken, in Drähten, Leitern, Lichtwellenleitern, Schaltungen, geeigneten Medien, die flüchtig und während der Übertragung frei von einem Anschein von Dauerhaftigkeit sind, und/oder geeignete immaterielle Medien beinhalten.
Es sollte festgehalten werden, dass die oben beschrieben Prozessschritte in jeder Reihenfolge oder Sequenz ausgeführt werden können, und nicht auf die Reihenfolge und Sequenz beschränkt sind, die in den Figuren gezeigt und beschrieben werden. Darüber hinaus können einige der obigen Schritte im Wesentlichen und ggf. gleichzeitig oder parallel ausgeführt oder durchgeführt werden, um Latenz- und Verarbeitungszeiten zu reduzieren.
Es sollte auch angemerkt werden, dass der Begriff Mechanismus, wie er hier verwendet wird, Hardware, Software, Firmware oder jede geeignete Kombination davon beinhalten kann.
Obgleich die Erfindung in den vorhergehenden veranschaulichenden Implementierungen beschrieben und veranschaulicht wurde, versteht es sich, dass die vorliegende Offenbarung nur exemplarisch ausgeführt wurde, und dass zahlreiche Änderungen in den Details der Implementierung der Erfindung erfolgen können, ohne vom Sinn und Umfang der Erfindung abzuweichen, der lediglich durch die folgenden Ansprüche begrenzt ist. Merkmale der offenbarten Implementierungen können auf verschiedene Arten kombiniert und neu angeordnet werden.

Claims

System für Parallelitätserkennung und -durchsetzung, das System umfassend: wenigstens einen Server, der konfiguriert wird, um: eine Anfrage nach einer Medieninhaltelizenz zu empfangen, zugehörig zu einem auf dem Medienwiedergabegerät darzustellenden Medieninhaltegegenstand, wobei die Anfrage nach der Medieninhaltelizenz mit einem Benutzerkonto verknüpft ist; als Reaktion auf die Anfrage nach einer Medieninhaltelizenz, eine oder mehrere mit dem Medieninhaltegegenstand verknüpfte Schlüssel und eine Lizenz umfassend eine Richtlinie einschließlich einer begrenzten Lizenzdauer und eines Erneuerungsanfrageintervalls an das Medienwiedergabegerät zu übertragen; zu einem Zeitpunkt innerhalb des Erneuerungsanfrageintervalls, einer Anfrage nach einer Lizenzerneuerung zugehörig zum auf dem Medienwiedergabegerät dargestellten Medieninhaltegegenstand zu empfangen; festzustellen, ob eine Lizenzerneuerung für den Medieninhaltegegenstand auf Grundlage von Mediensitzungsparallelität über eine Vielzahl von mit dem Benuterkonto verknüpften Medienwiedergabegeräten hinweg erteilt werden soll, wobei die Feststellung das Abfragen eines Datensatzes mit während einer gegeben Zeitspanne für das Benutzerkonto erteilten Lizenzerneuerungen beinhaltet; und die Lizenzerneuerung an das Medienwiedergabegerät auf Grundlage des Datensatzes an mit dem Benutzerkonto verknüpfter Lizenzerneuerungen zu übertragen.
System nach Anspruch 1, wobei der wenigstens eine Server weiter konfiguriert wird, um wenigstens einen Teil der begrenzten Lizenzdauer und des Erneuerungsanfrageintervalls zu modifizieren.
System nach Anspruch 2, wobei die Modifizierung als Reaktion auf die Überprüfung des Datensatzes von Lizenzen hin durchgeführt wird, die während einer gegebenen Zeitspanne für das Benutzerkonto erteilt wurden und auf die Feststellung hin, dass der Datensatz von Lizenzerneuerungen die Unterdrückung von Lizenzerneuerungsanfragen durch die Vielzahl von mit dem Benutzerkonto verknüpften Medienwiedergabegeräten anzeigt.
System von Anspruch 2, wobei die Modifizierung als Reaktion auf das Erkennen eines Serverausfalls durchgeführt wird.
System nach Anspruch 1, wobei, als Reaktion auf die Feststellung, dass ein oder mehrere Schlüssel in der Lizenz widerrufen werden sollen, die mit der Lizenzierungserneuerung verknüpfte begrenzte Lizenzdauer eine Dauer von Null oder andere Mittel und Wege hat, um den Wegfall der Medienrechte durchsetzen.
System nach Anspruch 1, wobei der wenigstens eine Server weiter konfiguriert wird, um die Lizenz der begrenzten Lizenzdauer für den Medieninhaltegegenstand auf das Medienwiedergabegerät automatisch zu übertragen, während parallel der Wegfall einer zuvor erteilten Lizenz innerhalb des Datensatzes angezeigt wird.
System nach Anspruch 1, wobei der wenigstens eine Server weiter konfiguriert ist, um: den Datensatz an während der gegebenen Zeitspanne erteilten Lizenzerneuerungen für das Benutzerkonto zu überprüfen; einen Durchsetzungsmodus aus einer Vielzahl von auf das Benutzerkonto anzuwendenden Durchsetzungsmodi zu bestimmen; und den bestimmten Durchsetzungsmodus bei Erteilung der Lizenzerneuerung anzuwenden, wobei wenigstens eine der begrenzten Lizenzspannen und das Erneuerungsanfrageintervall angepasst werden.
System von Anspruch 1, wobei der wenigstens eine Server weiter konfiguriert ist, um an eine auf dem Medienwiedergabegerät ausgeführte Medienwiedergabeanwendung eine Vielzahl von Lizenzierungsservern für die Handhabung der Lizenzerneuerungsanfrage zu übertragen, wobei die Medienwiedergabeanwendung die Anfrage der Lizenzerneuerung an einen ersten Lizenzierungsserver der Vielzahl von Lizenzierungsservern überträgt und, auf die Feststellung hin, dass der erste Lizenzierungsserver nicht erreichbar ist, und vor dem Auslaufen der Lizenz, eine Anfrage an einen zweiten Lizenzierungsserver der Vielzahl von Lizenzierungsservern überträgt, bis dass die Lizenzierungserneuerung für die Medieninhaltelizenz empfangen wurde.
System nach Anspruch 1, wobei der wenigstens eine Server weiter konfiguriert ist, um: durch das Zählen der Anzahl mit dem Benutzerkonto während der gegebenen Zeitspanne verknüpfter Lizenzerneuerungen festzustellen, ob die Lizenzerneuerung erteilt werden soll; und die Lizenzerneuerung entsprechend der Zählung auf das Medienwiedergabegerät zu übertragen.
System von Anspruch 1, wobei der wenigstens eine Server weiter konfiguriert ist, um festzustellen, ob ein Notfallerneuerungsmodus aktiv werden soll, der die Lizenzerneuerung automatisch als Reaktion darauf erteilt, dass auf den Datensatz mit Lizenzerneuerungen nicht zugegriffen werden kann.
Ein Verfahren für Parallelitätserkennung und -durchsetzung, das Verfahren umfassend: das Empfangen, unter Verwendung wenigstens eines Servers einschließlich eines Hardware-Prozessors, einer Anfrage um eine Medieninhaltelizenz zugehörig zu einem Medieninhaltegegenstand darzustellen auf dem Medienwiedergabegerät, wobei die Anfrage um die Medieninhaltelizenz mit einem Benutzerkonto verknüpft ist; als Reaktion auf die Anfrage um eine Medieninhaltelizenz, das Übertragen eines oder mehrerer mit dem Medieninhaltegegenstand verknüpfter Schlüssel an das Medienwiedergabegerät und einer Lizenz umfassend einer Richtlinie einschließlich eine begrenzten Lizenzdauer und eines Erneuerungsanfrageintervalls; das Empfangen, zu einem Zeitpunkt innerhalb des Erneuerungsanfrageintervalls, einer Anfrage nach einer Lizenzerneuerung zugehörig zum auf dem Medienwiedergabegerät dargestellten Medieninhaltegegenstand; das Feststellen, ob eine Lizenzerneuerung für den Medieninhaltegegenstand erteilt werden soll auf Grundlage von Mediensitzungsparallelität über eine Vielzahl von mit dem Benuterkonto verknüpften Medienwiedergabegeräten hinweg, wobei die Feststellung das Abfragen eines Datensatzes mit während einer gegeben Zeitspanne für das Benutzerkonto erteilten Lizenzerneuerungen beinhaltet; und das Übertragen der Lizenzerneuerung an das Medienwiedergabegerät auf Grundlage des Datensatzes mit dem Benutzerkonto verknüpfter Lizenzerneuerungen.
Verfahren nach Anspruch 11; weiter umfassend das Modifizieren wenigstens einer der begrenzten Lizenzspannen und des Erneuerungsanfrageintervalls.
Verfahren nach Anspruch 12, wobei die Modifizierung als Reaktion auf die Überprüfung des Datensatzes von Lizenzen hin durchgeführt wird, die während einer gegebenen Zeitspanne für das Benutzerkonto erteilt wurden und auf die Feststellung hin, dass der Datensatz von Lizenzerneuerungen die Unterdrückung von Lizenzerneuerungsanfragen durch die Vielzahl von mit dem Benutzerkonto verknüpften Medienwiedergabegeräten anzeigt.
Verfahren nach Anspruch 12, wobei die Modifizierung als Reaktion auf das Feststellen eines Serverausfalls durchgeführt wird.
Verfahren nach Anspruch 11, wobei, als Reaktion auf das Feststellen, dass ein oder mehrere Schlüssel in der Lizenz widerrufen werden sollen, die mit der Lizenzierungserneuerung verknüpfte begrenzte Lizenzdauer gleich Null ist.
System von Anspruch 11, weiter umfassend das automatische Übertragen der Lizenz mit begrenzter Lizenzdauer für den Medieninhaltegegenstand auf das Medienwiedergabegerät, während parallel der Wegfall einer zuvor erteilten Lizenz innerhalb des Datensatzes angezeigt wird.
Verfahren nach Anspruch 11, weiter umfassend: das Überprüfen des Datensatzes mit Lizenzerneuerungen, die während einer gegebenen Zeitspanne für das Benutzerkonto erteilt wurden; das Feststellen eines Durchsetzungsmodus aus einer Vielzahl von auf das Benutzerkonto anzuwendender Durchsetzungsmodi; und das Anwenden des festgestellten Durchsetzungsmodus bei Erteilung der Lizenzerneuerung, wobei wenigstens eine der begrenzten Lizenzspannen und das Erneuerungsanfrageintervall angepasst wird.
Verfahren nach Anspruch 11, weiter umfassend das Übertragen, an eine auf dem Medienwiedergabegerät ausgeführte Medienwiedergabeanwendung einer Vielzahl von Lizenzierungsservern für die Handhabung der Lizenzerneuerungsanfrage, wobei die Medienwiedergabeanwendung die Anfrage der Lizenzerneuerung an einen ersten Lizenzierungsserver der Vielzahl von Lizenzierungsservern überträgt und, auf die Feststellung hin, dass der erste Lizenzierungsserver nicht erreichbar ist, und vor dem Auslaufen der Lizenz, eine Anfrage an einen zweiten Lizenzierungsserver der Vielzahl von Lizenzierungsservern überträgt, bis dass die Lizenzierungserneuerung für die Medieninhaltelizenz empfangen wurde.
Verfahren nach Anspruch 11, weiter umfassend: das Feststellen, ob die Lizenzerneuerung erteilt werden soll, durch das Zählen der Anzahl mit dem Benutzerkonto verknüpfter Lizenzerneuerungen während einer gegebenen Zeitspanne; und das Übertragen der Lizenzerneuerung auf das Medienwiedergabegerät entsprechend der Zählung.
Verfahren nach Anspruch 11, weiter umfassend das Feststellen, ob ein Notfallerneuerungsmodus aktiv werden soll, der die Lizenzerneuerung automatisch als Reaktion darauf erteilt, dass auf den Datensatz mit Lizenzerneuerungen nicht zugegriffen werden kann.
Nichtflüchtiges, computerlesbares Medium, das computerausführbare Befehle enthält, die bei Ausführung durch einen Prozessor den Prozessor veranlassen, ein Verfahren zum Präsentieren einer Werbeanzeige auszuführen, wobei das Verfahren umfasst: das Empfangen einer Anfrage nach einer Medieninhaltelizenz zugehörig zu einem Medieninhaltegegenstand darzustellen auf dem Medienwiedergabegerät, wobei die Anfrage um die Medieninhaltelizenz mit einem Benutzerkonto verknüpft ist; als Reaktion auf die Anfrage nach einer Medieninhaltelizenz, das Übertragen eines oder mehrerer mit dem Medieninhaltegegenstand verknüpfter Schlüssel an das Medienwiedergabegerät und einer Lizenz umfassend einer Richtlinie einschließlich einer begrenzten Lizenzdauer und eines Erneuerungsanfrageintervalls; das Empfangen, zu einem Zeitpunkt innerhalb des Erneuerungsanfrageintervalls, einer Anfrage nach einer Lizenzerneuerung zugehörig zum auf dem Medienwiedergabegerät dargestellten Medieninhaltegegenstand; das Feststellen, ob eine Lizenzerneuerung für den Medieninhaltegegenstand erteilt werden soll auf Grundlage von Mediensitzungsparallelität über eine Vielzahl von mit dem Benuterkonto verknüpften Medienwiedergabegeräten hinweg, wobei die Feststellung das Abfragen eines Datensatzes mit während einer gegeben Zeitspanne für das Benutzerkonto erteilten Lizenzerneuerungen beinhaltet; und das Übertragen der Lizenzerneuerung an das Medienwiedergabegerät auf Grundlage des Datensatzes mit dem Benutzerkonto verknüpfter Lizenzerneuerungen.