ES2682243T3 - Sistema multidifusión de distribución de contenidos multimedia - Google Patents

Sistema multidifusión de distribución de contenidos multimedia Download PDF

Info

Publication number
ES2682243T3
ES2682243T3 ES12167801.5T ES12167801T ES2682243T3 ES 2682243 T3 ES2682243 T3 ES 2682243T3 ES 12167801 T ES12167801 T ES 12167801T ES 2682243 T3 ES2682243 T3 ES 2682243T3
Authority
ES
Spain
Prior art keywords
dvr
content
multicast
server
dvrs
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES12167801.5T
Other languages
English (en)
Inventor
James Barton
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Adeia Media Solutions Inc
Original Assignee
Tivo Solutions Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tivo Solutions Inc filed Critical Tivo Solutions Inc
Application granted granted Critical
Publication of ES2682243T3 publication Critical patent/ES2682243T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1854—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with non-centralised forwarding system, e.g. chaincast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1877—Measures taken prior to transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25866—Management of end-user data
    • H04N21/25875—Management of end-user data involving end-user authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25866—Management of end-user data
    • H04N21/25891—Management of end-user data being end-user preferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/26613—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel for generating or managing keys in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/4147—PVR [Personal Video Recorder]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4363—Adapting the video stream to a specific local network, e.g. a Bluetooth® network
    • H04N21/43632—Adapting the video stream to a specific local network, e.g. a Bluetooth® network involving a wired protocol, e.g. IEEE 1394
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/482—End-user interface for program selection
    • H04N21/4821—End-user interface for program selection using a grid, e.g. sorted out by channel and broadcast time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6405—Multicasting

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Graphics (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Television Signal Processing For Recording (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Un procedimiento para un sistema multidifusión de distribución de contenidos multimedia que comprende: recibir (2902) un horario de transmisión desde un servidor de contenidos (2701) en un videograbador digital (DVR) (2703); donde el horario de transmisión indica (2901) horas de transmisión para flujos de datos; crear un enlace entre el servidor de contenidos (2701) y el DVR (2703) donde el DVR (2703) se registra (2903, 2904) en el servidor de contenidos (2701) para un flujo de datos específico; y recibir (2905, 3005) el flujo de datos específico en el DVR (2703) desde el servidor de contenidos (2701) a un horario programado; donde el DVR (2703) es designado (3002) como DVR túnel de multidifusión (2703) por otros DVR (2704, 2705, 2706) conectados a una red local común; y donde el DVR túnel de multidifusión (2703) reemite (3006) el flujo de datos específico recibido a otros DVR (2704, 2705, 2706) conectados a la red local común.

Description

5
10
15
20
25
30
35
40
45
50
55
60
DESCRIPCIÓN
Sistema multidifusión de distribución de contenidos multimedia Campo de la invención
La invención se refiere a distribuir contenido multimedia a través de una red a una pluralidad de grabadores digitales. Antecedentes
Con la aparición de los videograbadores (VCR, por su sigla en inglés), los telespectadores pueden grabar eventos de programas de TV que se emiten en determinada franja horaria y reproducir el contenido del programa grabado más tarde. Durante la grabación, un VCR transforma las señales eléctricas del contenido de un programa en señales magnéticas y almacena las señales magnéticas en cinta magnética. Durante la reproducción, el VCR transforma señales magnéticas en señales eléctricas y un televisor conectado muestra el contenido del programa de las señales en su pantalla.
Con el desarrollo de la tecnología digital, los VCR están siendo rápidamente sustituidos por videograbadores digitales (DVR, por su sigla en inglés). Como un VCR, la funcionalidad de un DVR es grabar eventos de programas emitidos para reproducirlos posteriormente. Durante la grabación, un DVR transforma las señales eléctricas de contenido de programa emitido en información digital, tales como flujos de datos MPEG y almacena la información digital en un dispositivo de memoria o directamente almacena señales de TV pre-digitalizadas en el dispositivo de memoria. Al reproducir, el DVR convierte la información digital otra vez en señales de visualización digitales o analógicas. Un televisor o monitor conectado muestra el contenido del programa de las señales en su pantalla.
Un DVR tradicional es un sistema de propósito único dedicado a grabar contenido de programas de TV emitidos. No tiene capacidad para recibir contenido multimedia de ninguna otra forma que no sea mediante conexiones terrestres, por cable o satelitales. Lo que se busca es ofrecer un DVR con capacidad para recibir contenido multimedia mediante una conexión de red tal como Internet, proporcionándole al DVR una fuente adicional de contenido. El contenido no tiene que ser recibido o visualizado en tiempo real, como sucede con el contenido de programas de TV emitidos. Asimismo, dicho sistema proporcionaría un procedimiento para emitir de manera eficaz contenido multimedia a múltiples DVR a través de la red sin sobrecargar un servidor de contenidos.
La publicación internacional WO 01/45407 A1 describe un sistema para controlar la grabación de programas de televisión utilizando una guía de programas de televisión, que se proporciona como una página web y se utiliza para seleccionar programas que se van a grabar y señales de control en tiempo real transmitidas desde un servidor de multidifusión IP De acuerdo con el contenido de las señales de control en tiempo real, se crean señales infrarrojas que controlan la grabación del programa seleccionado recibidas en un videograbador externo.
Resumen
La invención está definida por las reivindicaciones independientes, teniendo debidamente en cuenta cualquier elemento que sea equivalente a un elemento especificado en las reivindicaciones. Las reivindicaciones dependientes se refieren a características opcionales de algunas realizaciones de la invención.
Breve descripción de los dibujos
La presente invención se ilustra a título de ejemplo, y no con carácter restrictivo, en las figuras de los dibujos adjuntos y en las cuales los números de referencia iguales se refieren a elementos similares y en las cuales:
La figura 1 es un diagrama de bloques que ilustra un sistema de comunicación para acceso remoto a un servicio de televisión personal centralizado;
la figura 2 es un diagrama de flujo de datos que muestra los procesos de funcionamiento del sistema ilustrado en la figura 1;
la figura 3 es un diagrama de tablas que ilustra las estructuras de una base de datos de usuarios y una base de datos de eventos ilustradas en la figura 2;
la figura 4 es un gráfico de flujo que muestra un proceso utilizado por un servidor web de un servicio de televisión personal para obtener instrucciones de programación remota de un usuario;
la figura 5 es una representación gráfica de una interfaz gráfica de usuario para selección de programas;
la figura 6 es una captura de pantalla de una página web Programación Actual que aparece en un navegador web o
pantalla de televisión de un usuario;
la figura 7 es un diagrama de bloques que ilustra las interacciones entre el centro de servicios de televisión personal,
5
10
15
20
25
30
35
40
45
50
55
60
el DVR y el servidor de contenidos externo por Internet;
la figura 8 es una captura de pantalla de una barra de reproducción que indica que el contenido se está descargando más rápido que la velocidad de reproducción;
la figura 9 es un diagrama que ilustra un certificado digital que contiene información de DVR;
la figura 10 es un diagrama de bloques que ilustra un servidor multimedia en una red local conectada a varios DVR dentro de un hogar;
la figura 11 es un diagrama de bloques que ilustra un intercambio de comunicación entre dos DVR para crear una conexión cifrada segura;
la figura 12 es un diagrama que ilustra un certificado digital que contiene información de DVR y de servidor de contenidos;
la figura 13 es un diagrama de bloques que ilustra un servidor que graba información de acceso a DVR a efectos de facturación;
la figura 14 es un diagrama de bloques que ilustra un redirector de nombre de dominio que redirecciona una petición de DVR a un servidor de terceros;
la figura 15 es un diagrama de bloques que ilustra un DVR que se está utilizando como canalización de cifrado para un servidor de contenidos de terceros;
la figura 16 es una captura de pantalla de una pantalla de Reproducción Actual que muestra un servidor multimedia accesible;
la figura 17 es una captura de pantalla de una pantalla de contenido que muestra contenido accesible para un servidor multimedia;
la figura 18 es una captura de pantalla de una pantalla de opciones de transferencia para contenido de un servidor multimedia;
la figura 19 es una captura de pantalla de una pantalla de estado de programa que muestra un programa transfiriéndose desde un servidor multimedia;
la figura 20 es una captura de pantalla de una pantalla de música que muestra música accesible de un servidor multimedia;
la figura 21 es una captura de pantalla de una pantalla de fotos que muestra fotos accesibles de un servidor multimedia;
la figura 22 es un diagrama de bloques que ilustra un servidor multimedia en una red local conectada a un DVR dentro de un hogar y el servidor multimedia tiene acceso a Internet;
la figura 23 es un diagrama de bloques que ilustra un servidor multimedia en una red local conectada a un DVR dentro de un hogar y el servidor multimedia y el DVR tienen acceso a Internet; la figura 24 es un diagrama de bloques que ilustra una conexión a Internet multidifusión;
la figura 25 es un diagrama de bloques que ilustra una pluralidad de DVR en una red local dentro de un hogar y los DVR tienen acceso a Internet y recursos de multidifusión;
la figura 26 es un diagrama de bloques que ilustra una pluralidad de DVR conectados a Internet y suscritos a grupos multidifusión para recibir transmisiones multidifusión de un servidor de contenidos;
la figura 27 es un diagrama de bloques que ilustra una conexión multidifusión virtual que utiliza un DVR túnel de multidifusión conectado a una pluralidad de DVR en una red local;
la figura 28 es un diagrama de bloques que ilustra un servidor de centro de emisión multidifusión que transmite flujos de datos a una pluralidad de DVR por Internet;
la figura 29 es un diagrama de flujo que ilustra un sistema para distribuir contenido a varios DVR utilizando multidifusión; y
la figura 30 es un diagrama de flujo que ilustra un sistema para crear una red de multidifusión virtual entre un servidor de contenidos y un DVR.
Descripción detallada
Se describen un procedimiento y un aparato para un sistema multidifusión de distribución de contenidos multimedia. En la siguiente descripción, con fines explicativos, se indican numerosos detalles específicos para proporcionar una comprensión exhaustiva de la presente invención. Sin embargo, quedará claro que la presente invención puede ponerse en práctica sin estos detalles específicos. En otros casos, se muestran estructuras y dispositivos conocidos en forma de diagrama de bloques para evitar la ocultación innecesaria de la presente invención.
En la siguiente descripción, en las referencias a los dibujos, los números iguales se refieren a partes iguales en las diferentes vistas.
A. SISTEMA PARA ACCESO REMOTO A UN SERVICIO DE TELEVISIÓN PERSONAL
En lo que respecta a la figura 1, se muestra un sistema de comunicación para acceso remoto a un servicio de televisión personal, designado, en términos generales, con el número (100). De acuerdo con un enfoque, un videograbador digital (DVR) (110) instalado en un entorno doméstico se comunica con un centro de servicios de
5
10
15
20
25
30
35
40
45
50
55
60
televisión personal (de aquí en adelante denominado centro de servicios) (130), que proporciona datos de guía de programas, recursos gráficos (tales como fuentes, fotos, etc.), información de servicio y otras formas de datos que permiten que el DVR (110) funcione independientemente del centro de servicios (130) para satisfacer los intereses de los espectadores. La funcionalidad de un DVR se representa en la patente de EE. UU. N° 6.233.389, y en las solicitudes de patente N° 09/827.029, 09/935.426, 10/081.776, 10/418.646, y 11/051.347, todas las cuales son propiedad del Solicitante y se incorporan a la presente memoria como referencia. El sistema de comunicación utiliza una arquitectura de distribución segura para transferir datos entre el DVR (110) y el centro de servicios (130) de forma que tanto los datos del servicio como la privacidad del usuario estén protegidos. El DVR (110) recibe señales emitidas de una antena (115) o recibe señales de televisión de un sistema de televisión por cable.
En una realización de la invención, el DVR (110) por lo general comprende: una pluralidad de componentes que son necesarios para digitalizar una señal de televisión analógica y convertirla en un flujo de datos digitales; una pluralidad de componentes diseñados para grabar segmentos de dicho flujo de datos; una pluralidad de instalaciones de almacenamiento diseñadas para retener segmentos de dicho flujo de datos; una pluralidad de componentes diseñados para recuperar segmentos de dicho flujo de datos, convertir dicho flujo de datos en una señal analógica y luego modular la señal en una portadora de RF, a través de la cual la señal se entrega a un televisor estándar (120); y una interfaz (125), a través de la cual el DVR (110) se comunica con una red (140).
El DVR (110) contiene un procesador criptográfico seguro local que contiene una clave privada no alterable. La funcionalidad segura del DVR (110) se describe adicionalmente en la patente de EE. UU. N° 6.385.739 que pertenece al Solicitante y que se incorpora a la presente memoria como referencia.
El DVR (110) se puede conectar directamente con el centro de servicios (130) utilizando su módem telefónico interno para marcar a un banco de módems de llamadas entrantes (145). En primer lugar, la llamada entrante se encamina al centro de servicios (130) para la verificación de la identificación. Tras la verificación, la llamada entrante queda autorizada. El banco de módems privado (145) responde la llamada y el DVR (110) obtiene acceso a las bases de datos del centro de servicios (130).
Como alternativa, el DVR (110) puede estar conectado indirectamente al centro de servicios (130) mediante la red (140). La interfaz (125) entre el DVR (110) y la red (140) puede ser el módem telefónico interno del DVR (110) o una interfaz de red dedicada tal como un módem de cable. La red informática (140) puede ser una red privada o Internet. El DVR (110) inicia una conexión con la red informática (140) llamando a un número telefónico de acceso local para un proveedor de servicio de Internet (ISP, por su sigla en inglés). El ISP dirige la solicitud de conexión de red al proveedor de servicios (130) para la verificación de la identificación. Tras la verificación, la conexión de red queda autorizada y el DVR (110) obtiene acceso a las bases de datos del centro de servicios (130).
El centro de servicios (130) recibe información sobre horarios de programas (150) de fuentes externas. La información sobre horarios de programas (150) forma la base de una guía de programas que los telespectadores pueden utilizar para seleccionar programas de televisión que van a grabar. El centro de servicios (130) se comunica con la red informática (140) mediante una interfaz (135).
Los telespectadores pueden utilizar un ordenador remoto (155) o asistentes digitales personales (160) para acceder a la base de datos de programas del centro de servicios (130) de forma remota estableciendo un canal de comunicación con el centro de servicios (130) mediante la red informática (140).
En lo que respecta a la figura 2, el centro de servicios (130) incluye un servidor web (200), que recoge, organiza y proporciona información sobre horarios de programas; una base de datos de programas (210), que almacena información sobre horarios de programas; una base de datos de usuarios (220), que almacena información sobre usuarios y videograbadores digitales; una base de datos de eventos (230), que almacena un listado de eventos para cada usuario y un proceso de envío (240), que cruza la base de datos de usuarios y recupera el listado de eventos de la base de datos de eventos. También puede incluir una interfaz de red por la cual se comunican el servidor web y el videograbador digital.
En una realización, el DVR (110) incluye un microservidor (250), que controla la comunicación entre el DVR (110) y el centro de servicios (130); una guía de almacenamiento de programas local (260), que graba la guía de programas proporcionada por el centro de servicios (130) y se actualiza cada vez que el DVR (110) accede al centro de servicios (130); una cola de eventos (270), que es una estructura de datos utilizada para iniciar sesiones de grabación que capturan programas de televisión seleccionados; un generador de números pseudoaleatorios (PRNG, por su sigla en inglés) (280), que genera una clave de autorización para acceso remoto; así como también una interfaz de red (125), que conecta el DVR (110) con la red informática (140). La cola de eventos (270) se acopla a un dispositivo de grabación incorporado al DVR (110).
5
10
15
20
25
30
35
40
45
50
55
60
Tanto el ordenador remoto (155) como los asistentes digitales personales (PDA, por su sigla en inglés) (160) comprenden un navegador web (290), que puede ser un navegador web genérico que permite al usuario ver páginas web.
La figura 3 es un diagrama de tablas que ilustra las estructuras de una base de datos de usuarios (220) y una base de datos de eventos (230). La base de datos de usuarios (220) incluye una pluralidad de registros de usuarios (300). Cada registro de usuario (300) comprende una pluralidad de campos, entre los cuales se encuentran una identificación de usuario (310), una clave criptográfica (320), una identificación de DVR (330) y un puntero de listado de eventos (340). El campo de identificación de usuario (310) se utiliza como una clave en la base de datos de usuarios (220). El campo de clave criptográfica (320) se utiliza para almacenar la clave de autorización recibida de un usuario que está intentando programar su DVR (110) de forma remota. La identificación de DVR (330) se utiliza para almacenar la dirección de red y los detalles de conexión que se precisan para establecer un canal de comunicación con el DVR (110).
En la base de datos de usuarios (220), se mantienen listados de eventos (350) separados para cada usuario. Los listados de eventos (350) se almacenan en la base de datos de eventos (230). Cada listado de eventos (350) incluye una pluralidad de registros de eventos (360). Cada registro de eventos incluye una pluralidad de campos entre los cuales se encuentran un campo de hora (370), un campo de canal (380) y un campo de duración (390). El campo de hora (370) se utiliza para indicar una hora de inicio para grabar y comprende la fecha y hora del evento de programa. El campo de canal (380) especifica qué canal debería grabar el DVR. El campo de duración (390) se utiliza para especificar cuánto tiempo el DVR debería grabar el contenido para ese evento de programa. Un registro de evento también puede contener un identificador de un registro (u objeto) en la base de datos de guías de programas. El DVR recupera información necesaria de la base de datos de guías de programas.
B. PROCESO PARA ACCESO REMOTO A SERVICIO DE TELEVISIÓN PERSONAL
La figura 2 junto con la figura 1 muestra diversos procesos que permiten, de manera colectiva, la funcionalidad de las técnicas descritas en la presente memoria.
El centro de servicios (130) recibe información sobre horarios de programas (150) de fuentes externas de manera periódica. Una vez que llega la información sobre horarios de programas (150), la base de datos de programas (210) se actualiza en consecuencia.
El DVR (110) actualiza su guía de programas local (260) de manera periódica leyendo una página web de un servidor web (200) o mediante conexión por cable, satelital o telefónica. En respuesta a una petición del DVR (110), el servidor web (200) primero consulta la base de datos de programas (210) para obtener información de programas actualizada y luego crea, de manera dinámica, una página web que contiene información sobre horarios de programas actualizada.
Hay dos tipos de acceso remoto disponibles: directo e indirecto. El telespectador puede programar indirectamente el DVR (110) utilizando un navegador web (290) ya sea en un ordenador remoto (155) o en un asistente digital personal (160). En esta situación, el navegador web (290) se utiliza para acceder a un sitio web especial hospedado por el servidor web (200). El servidor web (200) muestra a un telespectador una guía de programas utilizando una interfaz gráfica de usuario como se muestra en la figura 5. El telespectador selecciona programas de televisión por título de programa y franja horaria para indicar qué programas debería grabar el DVR (110).
El centro de servicios (130) ejecuta un proceso de envío (240) de manera periódica. El proceso de envío (240) atraviesa la base de datos de usuarios (220). Cada vez que el proceso de envío (240) se encuentra con un usuario que ha especificado eventos de programa, el proceso de envío (240) recupera el listado de eventos (350) de la base de datos de eventos (230). A continuación, el proceso de envío (240) establece un canal de comunicación con el microservidor (250) que reside en el DVR (110). Este canal de comunicación está diseñado para permitir que el proceso de envío (240) recupere una página web de envío de eventos especial del microservidor (250). El microservidor (250) muestra la página web de envío de eventos al proceso de envío (240). A continuación, el proceso de envío (240) completa la página web de envío de eventos y la devuelve al microservidor (250).
El microservidor (250) también puede hacer que el proceso de envío (240) inicie la transferencia de eventos sondeando el proceso de envío (240) para encontrar eventos.
El microservidor (250) utiliza instrucciones de eventos encontradas en la página web de envío de eventos para actualizar la cola de eventos (270) incorporada en el DVR (110). La cola de eventos (270) es una estructura de datos utilizada por el DVR (110) para iniciar sesiones de grabación que capturan eventos de programas de televisión.
5
10
15
20
25
30
35
40
45
50
55
60
Para autenticar una transacción, el servidor web (200) incluye uno o más códigos de autorización para el usuario afiliados con el DVR (110) que se ha de programar. El DVR (110) compara el código de autorización contra una copia privada guardada en la memoria no volátil del DVR. Los códigos de autorización están sujetos a limitación temporal y se puede configurar para que caduquen según manden los requisitos del sistema de seguridad.
Para utilizar la funcionalidad de acceso remoto directo, un usuario primero debe obtener una clave de autorización del DVR (110), que se genera mediante el generador de números pseudoaleatorios (PRNG) 280. El usuario se comunica directamente con el DVR (110) mediante su televisión en la ubicación del DVR. El DVR (110) muestra la clave de autorización al usuario. El usuario luego accede al DVR (110) a través de Internet utilizando su ordenador (155) o su PDA (160). El usuario muestra la clave de autorización y programa el DVR (110) mediante una interfaz gráfica de usuario que es gestionada por el microservidor (250). Asimismo, una vez que el usuario accede en modo directo, el usuario puede descargar un programa al DVR (110).
C. PROCESO PARA OBTENER INSTRUCCIONES DE PROGRAMACIÓN REMOTA
La figura 4 es un gráfico de flujo que muestra un proceso utilizado por el servidor web (200) y el microservidor (250) para obtener órdenes de programación remota de un usuario. Ambos se muestran en paralelo, pero en el uso normal son procesos separados. El proceso comprende las siguientes etapas:
Etapa 400: El servidor web (200) o microservidor (250) muestra un formulario de petición de autorización en la primera página web al usuario que accede a un sitio web especial gestionado por el servidor web (200) o el microservidor (250);
Etapa 410: El servidor web (200) recibe una contraseña de autorización ingresada por el usuario; el microservidor (250) recibe una clave de autorización del usuario;
Etapa 420: El servidor web (200) valida la contraseña de autorización utilizando la base de datos de usuarios (220); el microservidor (250) valida la clave de autorización con la clave que tiene almacenada.
Etapa 430: Una vez que el servidor web (200) validó la contraseña de autorización en la base de datos de usuarios (220), escribe una cookie en la memoria no volátil del ordenador remoto (155) o asistente digital personal (160); una vez que el microservidor (250) validó la clave de autorización, escribe una cookie en la memoria no volátil del ordenador remoto (155) o asistente digital personal (160);
Etapa 440: El servidor web (200) o microservidor (250) muestra una guía de programas al usuario después de que el usuario es identificado y autenticado;
Etapa 450: El servidor web (200) recibe las selecciones del usuario y crea un listado de eventos (350) específico para el usuario. El listado de eventos (350) se almacena en la base de datos de eventos (230). El microservidor (200) recibe las selecciones del usuario y las ubica en la cola de eventos (270).
En la etapa 440, el servidor web (200) o microservidor (250) sigue un script incorporado en el primer sitio web mostrado al usuario y busca una cookie válida en el ordenador remoto (155) o el asistente digital personal (160). Una vez que se descubre una cookie válida, las etapas 400 a 430 se excluyen del flujo de proceso.
D. INTERFAZ GRÁFICA DE USUARIO PARA SELECCIÓN DE PROGRAMAS
La figura 5 es una representación gráfica de una interfaz gráfica de usuario (IGU) (500) ejemplar para selección de programas. La IGU (500) se utiliza en el panel frontal del DVR y se incorpora en las páginas web mostradas a usuarios remotos por el servidor web (200). Cuando se implementa directamente en el DVR (110), la IGU (500) es manipulada directamente por el proceso de control incorporado en el DVR (110). Cuando la IGU (500) se muestra a los usuarios remotos mediante una red informática, se realiza como una página web de servidor activo. La figura 6 es una captura de pantalla de la página web Programación Actual que aparece en un navegador web de un usuario.
La IGU (500) comprende una tabla (505) que contiene una pluralidad de columnas (510) y una pluralidad de filas (515). Las columnas (510) corresponden a los días de la semana (y una fecha de calendario específica). Las filas (515) corresponden a las horas de un día determinado. Las columnas (510) y las filas (515) de la tabla (505) en realidad están compuestas por controles de selección de datos donde la leyenda del control se configura para indicar el título de un programa de televisión que está programado en la franja horaria según la posición de dicho control en la tabla (505). La IGU también comprende un mecanismo para desplazar hacia arriba (520) y desplazar hacia abajo (525), un mecanismo para adelantar (530) y retroceder (535); un mecanismo para seleccionar un programa de televisión específico; un mecanismo para crear un listado de eventos de programas (350) que contiene
5
10
15
20
25
30
35
40
45
50
55
60
programas de televisión seleccionados y un mecanismo para editar dicho listado de eventos (350). Asimismo, también puede incluir un mecanismo para ordenar una descarga, un mecanismo para indicar que la descarga está en proceso y un mecanismo para cancelar la descarga que está en proceso.
La posición del control corresponde al día y hora del evento de programa de televisión. El usuario puede alternar los controles de selección que se muestran en la IGU (500). Cuando la IGU (500) vuelve al servidor web (200), los identificadores de los controles seleccionados se utilizan en conjunto con la guía de programas (260) para crear un listado de eventos (350) para el usuario. A continuación, el listado de eventos (350) se almacena en la base de datos de eventos (230) en el caso de programación remota. Para programación local del DVR (110), el listado de eventos (350) se almacena directamente en la cola de eventos (270) que controla la secuencia de grabación de DVR.
E. ACCESO A INTERNET A VIDEOGRABADOR DIGITAL
La figura 7 es un diagrama de bloques de un esquema general (700) que ilustra las interacciones entre el centro de servicios (130), el DVR (110) y el servidor de contenidos externo (720) en Internet, donde un estilo particular del acceso a Internet está integrado en el DVR (110) para permitirle capturar ciertos tipos de contenido con una conexión a Internet (140) y darles acceso para visualización en la página Reproducción Actual como se muestra en la figura 6. Con el fin de ilustrar un ejemplo claro, la figura 7 y la descripción de la presente memoria se refieren a elementos y protocolos específicos que se pueden utilizar en una implementación, tales como Internet, Linux, DHCP, etc. No obstante, se pueden utilizar otros elementos o protocolos funcionalmente similares en implementaciones alternativas. Por ejemplo, la descarga puede ocurrir mediante una red pública, privada o dedicada, en vez de mediante Internet. Se pueden utilizar otros sistemas operativos y protocolos de direccionamiento dinámicos.
En una página Reproducción Actual, un listado del nombre de contenido, es decir, el título del programa de televisión, indica que dicho contenido se está capturando en la IGU (500) y un icono de grabación, o alguna variante de este, indica que la descarga está en proceso. El espectador puede elegir el contenido (es decir, el programa de televisión), y reproducirlo en cualquier momento.
La descarga puede ocurrir a cualquier velocidad. Por lo tanto, la interfaz (125) de la figura 1 no depende de ninguna manera de la velocidad de la descarga. La figura 8 es una captura de pantalla de la página web que muestra una barra de reproducción (801) que, aumentando la región verde (802) para que coincida, indica que el contenido se está descargando más rápido que la velocidad de reproducción (803). Se pueden utilizar otros mecanismos distintos de dicha barra de reproducción (801) para indicar que el contenido se está descargando más rápido que la velocidad de reproducción. En cualquier caso, el espectador puede utilizar todas las acciones trick-play (reproducción no estándar) con cualquier cantidad de contenido que se haya descargado hasta ese momento.
El hecho de que el contenido se descargara de Internet es transparente para el espectador, excepto en el contexto de mostrar información de programas, donde se puede indicar que el contenido procede de Internet de varias maneras.
Los punteros hacia contenido descargado se almacenan en una base de datos de contenido local (740) en el disco duro del DVR (110) de forma análoga a cómo se almacenan los programas emitidos, de modo que todas las formas de búsqueda y presentación muestren esos programas de manera adecuada y permitan su manipulación.
En contextos enfocados al canal o a la red, los programas descargables se muestran de manera análoga a la programación emitida. Estos contextos pueden tener que modificarse de modo que la «alineación» de canal o red se muestre de manera razonable, puesto que el tiempo y la ubicación son irrelevantes para dichos programas.
La cantidad de contenidos disponibles en el contexto de Reproducción Actual como se muestra en la figura 6 puede hacer que la navegación sea engorrosa. Si bien no se requiere para la implementación inicial, este contexto se puede modificar para hacer que la navegación sea más simple en muchos casos.
La entidad que proporciona contenido de algunos servidores se puede ver como una red de televisión. Cada nombre de servidor único indica un canal. En la presente memoria, un «servidor» es solo un nombre en la red; podría estar asignado a cualquier servidor físico en cualquier parte del mundo.
Una vez que se contacta el servidor de contenidos (720), el DVR (110) solicita el contenido multimedia según la identificación de programa otorgada. Esta es asignada por el servidor web (200) en un fragmento particular de contenido, que luego se envía en sentido descendente por la conexión. Ya sea el servidor de contenidos o el DVR pueden acelerar la velocidad de descarga.
Si el espectador solicita múltiples descargas, el DVR (110) puede elegir distintas formas de obtener el contenido;
7
5
10
15
20
25
30
35
40
45
50
55
60
puede iniciar conexiones múltiples con una limitación máxima, o peticiones en cola, o ambas.
En un enfoque, los elementos de la figura 7 abordan la seguridad del DVR (110). Abrir un puerto de red podría producir una gran cantidad de posibles infracciones de seguridad, que giran en torno a la seguridad de contenido con derecho de autor y protección de datos personales de un cliente.
En una realización, se utiliza soporte de cortafuegos Linux estándar para gestionar esta protección bloqueando automáticamente el acceso a todos excepto a unos pocos puertos conocidos (tales como web (HTTP) o detección) en ambas direcciones de comunicación. Los puertos conocidos son utilizados por la aplicación informática del DVR para contactar con el servidor de contenidos externo (720) para descargar contenido multimedia.
En el DVR (110) se proporciona un elemento de software de cliente de direccionamiento dinámico, tal como el cliente DHCP Linux. Al arrancar el DVR, si se detecta una interfaz de red, entonces el cliente DHCP utiliza el puerto conocido para obtener una dirección de red para el DVR de una fuente de direcciones dinámicas. Por ejemplo, el cliente dHcP de DVR (110) utiliza el protocolo DHCP para sondear un servidor DHCP externo (750). Si no se encuentra ningún servidor, las redes se desactivarán. Por lo demás, el DVR (110) inicializará sus parámetros de red de la respuesta de DHCP.
Un problema que presenta dicho soporte de cortafuegos Linux es que se le requiere al servidor DHCP externo (750) que configure la información de acceso a Internet. Se conoce que existen muchos procedimientos para leer datos o redireccionar el flujo de datos en una conexión a Internet entre dos dispositivos. Una posibilidad es la creación de alias, que consiste en que un servidor DHCP malintencionado configura información de acceso a Internet de tal forma que permite que un host malintencionado entre y ataque el DVR utilizando una dirección alias de servidor.
Para vencer ataques de este tipo, en una realización toda la comunicación con el servidor de contenidos (720) se autentica y se cifra. El servidor de contenidos (720) tiene acceso a la clave pública del DVR (110), y el DVR tiene una copia de la clave pública del servidor de contenidos (720). El DVR (110) tiene información de contenidos de metadatos acerca del servidor de contenidos (720) descargada por el centro de servicios (130). El DVR (110) almacena los metadatos en su base de datos (740) y confía en los datos de la base de datos (740) para funcionar. Utilizando un intercambio de certificados, el DVR (110) y el servidor de contenidos (720) generan una clave de sesión de uso único, y todas las demás comunicaciones se cifran utilizando la clave de sesión. En una realización, el algoritmo de Blowfish se utiliza para comunicación de sesión cifrada. La clave pública del servidor de contenidos (720) se distribuye desde el centro de servicios (130), que también ha proporcionado referencias de guía de programas apropiadas al servidor de contenidos (720).
El centro de servicios (130) acepta descripciones del servidor de contenidos (720). En una realización, dichas descripciones consisten en distintas URL de servidor, descripciones de contenido, identificaciones de contenido, descripciones de «canal», descripciones de «red», etc. Estos datos se importan en una base de datos de descripción de servidor de contenidos (CSD, por su sigla en inglés) (710). También se proporciona un conjunto de claves públicas para acceder al servidor de contenidos (720).
Para que el servidor de contenidos (720) acepte una conexión del DVR (110), debe tener acceso a la clave pública para un DVR particular. Esta distribución de claves se puede llevar a cabo sobre la marcha o con un enfoque de distribución de claves pre-compartidas. En la distribución de claves sobre la marcha, el servidor de contenidos (720) establece una conexión autenticada con el centro de servicios (130), proporciona un número de serie de DVR, y solicita al centro de servicios (130) que proporcione la clave pública asociada. Con un número de serie de DVR, el centro de servicios (130) devuelve una clave pública asociada. El servidor de contenidos (720) puede copiar en caché esta clave pública. Cada clave tiene una fecha de caducidad que indica cuándo el servidor de contenidos (720) debe eliminar la clave. El centro de servicios (130) puede mantener un registro de todas las claves públicas distribuidas, por ejemplo, con el fin de auditar la distribución de claves.
El centro de servicios (130) puede negarse a proporcionar la clave pública de un DVR inactivo. De manera adicional, el servidor de contenidos (720) puede responder a peticiones de invalidación de clave desde el centro de servicios (130), por ejemplo, si un DVR particular se vuelve inactivo.
Un grabador multimedia (730) es un subsistema de la aplicación informática de servicio de TV personal del DVR (110). El grabador multimedia (730) permite la grabación y reproducción simultáneas del contenido de descarga. El contenido grabado se almacena en la base de datos de contenidos (740) del DVR (110). El grabador multimedia (730) no se iniciará si no hay una conexión de red permanente disponible. En una implementación, el grabador multimedia (730) comprende varios subprocesos diferentes.
(1) Subproceso de cola de grabación: Este subproceso gestiona una cola de peticiones de descarga de red e
8
5
10
15
20
25
30
35
40
45
50
55
60
implementa la política de descarga. Inicialmente, esta puede ser una cola FIFO (primero en entrar, primero en salir) simple mantenida en la base de datos. Un objeto de política de cola de grabación se mantiene una vez que se implementa la política de descarga.
(2) Subproceso de grabación con captura: Este subproceso es responsable de gestionar una conexión con el servidor de contenidos (720). El subproceso de grabación con captura contacta con el servidor, implementa el protocolo de autenticación, solicita el contenido deseado y gestiona la descarga del contenido.
Como una variación de esta estrategia, un objeto de programa dentro de la aplicación de servicio de TV personal o grabador multimedia (730) puede indicar múltiples servidores que han de ser sondeados para capturar los contenidos multimedia. Los servidores se sondean en orden mediante el subproceso de grabación con captura; el primero en aceptar una petición de descarga es el que se utiliza. Esto proporciona peticiones de contenidos equilibradoras de carga en una pluralidad de servidores de contenidos organizados en una granja de servidores o centro de datos.
El subproceso de grabación con captura almacena o controla periódicamente su estado en una base de datos en el DVR (110) Dicho control permite reiniciar una descarga después de un corte de suministro eléctrico o error de sistema en el mismo punto en el contenido multimedia en el cual se estaba produciendo la descarga cuando ocurrieron el corte o el error. El subproceso de grabación con captura también gestiona el estado de objetos de base de datos que se utilizan para mostrar y navegar los contenidos que se están descargando. Por ejemplo, el subproceso de grabación con captura gestiona el estado del objeto de grabación para mostrarlo correctamente en el contexto de Reproducción Actual como se ilustra en la figura 6. Puede haber uno o más de dichos subprocesos activos en cualquier punto en el tiempo.
F. INTERACCIONES ENTRE LOS DVR
En un enfoque, se proporciona un mecanismo para transferir elementos multimedia y de base de datos entre dos DVR. En lo que respecta a la figura 7, se muestra un ejemplo de una transferencia utilizando una cantidad menor de almacenamiento en disco como se proporciona en un DVR portátil (760), por ejemplo. Como ejemplo, antes de irse de vacaciones, un usuario puede transferir contenido multimedia deseado y los datos de servicios asociados invisibles al DVR portátil (760) y llevar consigo el DVR portátil (760) de modo que pueda usar el contenido multimedia cuando lo desee. Otro ejemplo de una transferencia se muestra utilizando dos DVR, DVR (110) y DVR (770), que trabajan en conjunto de modo que dos flujos multimedia se reproduzcan con sincronización precisa para conseguir un funcionamiento idéntico.
Existen varias maneras de conectar dos DVR. En una realización, la salida del DVR (110) de origen se acopla con la entrada del DVR de destino (770). Si bien este procedimiento es funcional, este procedimiento no puede transferir información de metadatos acerca del flujo multimedia, que es esencial para la satisfacción del espectador al gestionar y utilizar el flujo multimedia.
El flujo multimedia almacenado en el DVR (110) consiste en los propios contenidos multimedia y un objeto de base de datos que proporciona información descriptiva sobre los contenidos multimedia. Si se utiliza un procedimiento de transferencia de datos, tal como una red (p. ej., IEEE 802.3) o una conexión directa (p. ej., IEEE 1394), entonces se pueden transferir tanto los contenidos multimedia como la información descriptiva, de modo que se conserve la integridad de la experiencia del espectador.
A los propietarios de contenidos les preocupa el potencial robo de sus contenidos. Un enfoque adicional cifra la transferencia de datos entre los DVR (110) y (770). Esto se puede llevar a cabo de varias maneras estándar y personalizadas. Por ejemplo, se puede utilizar el protocolo de conexión segura Diffie-Hellman para generar una clave de uso único que luego se utiliza para cifrar la transferencia.
Si se desea permitir que la transferencia solo se lleve a cabo a determinados DVR especificados, se puede utilizar un sistema de seguridad integrado. Cada DVR conoce la clave pública del otro, ya sea mediante claves precompartidas como por intercambio dinámico de claves. Cuando se inicia la transferencia, los DVR intercambian certificados firmados que se cifran según la clave pública del otro DVR. Si ambos DVR pueden descifrar y verificar la firma del otro, entonces cada DVR ha autenticado la identidad del otro y puede proceder a establecer una clave de sesión de uso único que luego se utiliza para cifrar los datos durante la transferencia.
La distribución de claves en tal caso se puede manejar mediante el centro de servicios (130). Un espectador puede contactar con el centro de servicios (130), y solicitar que dos DVR (110) y (770) que él tiene sean autorizados para transferir datos entre sí. El centro de servicios (130) envía un objeto de autorización que contiene la clave pública de cada DVR al otro DVR mediante un mecanismo de descarga apropiado. El centro de servicios (130) lleva un registro de esta operación para una auditoría posterior, que incluye información de identificación para cada DVR. Por
5
10
15
20
25
30
35
40
45
50
55
60
ejemplo, si se venciera el sistema de seguridad en un DVR y quedara expuesta la clave pública del otro, es posible modificar otros DVR de modo que aparezcan autorizados para el DVR de origen (110). Cada DVR lleva un registro de las transferencias. Este registro se carga en el centro de servicios (130). Posteriormente, esta información se podría procesar para buscar violaciones de protección contra copia, copias a DVR no autorizados, etc.
Si la transferencia se interrumpe, el DVR de destino (770) marca el flujo multimedia como «parcial» en el objeto descriptivo. A continuación se puede reiniciar la transferencia. Puesto que el diseño del sistema de base de datos garantiza que el flujo multimedia puede ser identificado de manera inequívoca en el DVR de destino (770), se encuentra el flujo parcial y la transferencia se inicia desde su extremo, evitando de este modo la re-transferencia de datos multimedia que ya se han almacenado. Una vez que el flujo multimedia completo se almacena, el objeto descriptivo se actualiza para mostrar un flujo multimedia completo.
La transferencia de datos digitales entre los DVR puede llevarse a cabo a cualquier velocidad que sea apropiada. Por ejemplo, puede suceder que la red entre los DVR sea lenta, en cuyo caso la duración de la transferencia será mayor que la duración de la reproducción del contenido. Como alternativa, la red puede ser rápida, en cuyo caso se podrían transferir múltiples flujos multimedia en mucho menos tiempo que el que lleva reproducir un ítem de contenido. El espectador en el DVR de destino puede empezar a ver el flujo multimedia tan pronto como los primeros fragmentos estén disponibles, a la vez que se produce la descarga continua del flujo en paralelo.
No se requiere que el DVR de origen o destino sean un DVR digital completo. Por ejemplo, los flujos multimedia almacenados en un servidor en una cabecera de televisión por cable pueden transferirse de manera fiable al DVR de destino (770). Como alternativa, el flujo multimedia almacenado en el DVR de origen (110) se puede transferir a un servidor de cabecera.
Por ejemplo, un PC puede utilizar una llave USB que contiene el procesador criptográfico del DVR. El PC establece un mecanismo seguro para transferir contenido desde y hacia el PC. El PC parecería un DVR para los otros DVR, porque utilizaría la llave USB para autenticar y generar claves de cifrado. A continuación el contenido puede almacenarse en el PC en forma cifrada. El contenido puede enviarse por correo electrónico a otros PC o DVR. Los otros PC deben tener una llave USB para cifrar el contenido. Los certificados que se pasan del centro de servicios (130) al PC se almacenan en NVRAM en la llave USB de modo que el certificado se mueva con la llave y no se almacene en el disco duro del PC.
Determinadas arquitecturas de distribución multimedia, tales como sistemas satelitales digitales, emiten la mayor parte del contenido multimedia en estado cifrado. Utilizando una instalación de descifrado local basada en una tarjeta inteligente, el contenido multimedia se descifra solo si se visualiza, protegiendo de este modo el contenido contra robo. Es posible para el DVR guardar estos flujos multimedia cifrados en el disco e iniciar el descifrado tras la reproducción. Este procedimiento se puede utilizar para transferir flujos multimedia entre dos DVR. Para poder cumplir correctamente con determinado conjunto de normas de protección de contenido asociadas al flujo multimedia (tales como reproducción única, caducidad al cabo de un día, etc.) el DVR mantiene con el objeto de base de datos que describe el flujo multimedia la información de protección contra copia asociada con el flujo multimedia (incluyendo si el flujo se almacena cifrado).
Las normas de protección de contenido asociadas al flujo multimedia también se pueden transferir al DVR de destino (770). Por ejemplo, el DVR (110) puede haber almacenado una película del servidor de contenidos (720) que no se descifrará hasta que se vea. Si el espectador desea hacer que ese flujo multimedia se transfiera, se copia a la región multimedia del dVr de destino (770) y el objeto descriptivo también se transfiere. En este enfoque, la información original en el flujo multimedia se duplica fielmente en el DVR de destino (770).
La tarjeta inteligente se podría retirar del DVR de origen (110) e instalar en el DVR de destino (770). Cuando el contenido multimedia se visualiza, al espectador se le cobra en consecuencia y se siguen todas las normas de protección. El contenido multimedia original y la información descriptiva podrían, o no podrían, eliminarse. Por ejemplo, en un esquema de «visión única», los originales se destruyen, mientras que en un esquema de «pago por visión», no.
Utilizando las mismas técnicas que se describen más arriba, se puede establecer una conexión segura, o autenticada y segura, entre dos o más DVR utilizando una red o conexión de módem. Establecer dicha conexión permite que se lleven a cabo interacciones de control. Algunos ejemplos de interacciones de control que se pueden proporcionar en diversas realizaciones son:
(1) Reproducción sincronizada. Un espectador puede controlar funciones trick-play en un flujo multimedia particular. Cada evento clave también se pasa al DVR de destino (770), que lleva a cabo la misma acción de manera automática. Por ejemplo, un presentador puede hacer una presentación en vivo utilizando el DVR de origen (110)
5
10
15
20
25
30
35
40
45
50
55
60
como dispositivo de reproducción multimedia y un público en una ubicación remota puede ver la misma presentación hecha de la misma manera al mismo tiempo. Como alternativa, dos espectadores que se comunican mediante otros medios, tales como teléfono, pueden interactuar, mientras uno u otro controla la reproducción en ambos DVR del mismo programa. Este enfoque alternativo permite un debate preciso del programa de interés. Este medio de comunicación puede ser un programa de chat simple superpuesto en la pantalla en el cual los participantes tipean comentarios. Dicho enfoque se puede utilizar para presentaciones corporativas así como con fines de entretenimiento.
(2) Paso de enlaces. Un espectador del DVR de origen (110) puede indicar que un programa particular estará enlazado con el DVR de destino (770). En respuesta, el DVR de origen (110) envía un mensaje al DVR de destino (770) para que el DVR de destino programe la grabación del programa enlazado. Como alternativa, el programa también se puede desenlazar. Un mensaje para enlazar o desenlazar puede contener solo la identificación del programa, asumiendo que tanto el DVR (110) como el DVR (770) están funcionando. Si el DVR de destino (770) no está funcionando, entonces el mensaje para enlazar puede contener metadatos adicionales.
(3) Efectos de sonido o gráficos. Cuando el espectador realiza una acción, tal como pulsar una secuencia de teclas en particular, el DVR de origen (110) puede reproducir un sonido o mostrar un gráfico. El DVR de origen (110) también puede pasar el evento al DVR de destino (770) que reproduce el mismo sonido o gráfico, o un sonido o gráfico diferente asociado al DVR de destino (770) con la acción que se llevó a cabo. Por ejemplo, de esta forma, un niño puede añadir sonidos a un programa, que se pueden replicar para un amigo en un DVR de destino (770) remoto. Dicha comunicación puede ser multi-modo.
En otro enfoque, los DVR también pueden transferir otros tipos de datos. Por ejemplo, un DVR (110) doméstico de gran tamaño y un DVR portátil (760) más pequeño. Los datos tales como software, elementos gráficos, datos de guías de programas, etc. se pueden transferir entre los dos DVR. Por ejemplo, el DVR portátil (760) se puede actualizar o se pueden sincronizar sus datos mediante el DVR doméstico (110) cada vez que se conectan los dos DVR. La actualización puede incluir transferir e instalar una actualización de software, sincronizar información de programas, sincronizar horarios de grabación, etc. La sincronización se produce como en un PDA donde el DVR portátil (760) puede decirle al DVR doméstico (110) que elimine un programa porque el usuario ya lo ha visto. El DVR portátil (760) transfiere cualquier información operativa al DVR doméstico (110) cada vez que dos DVR se conectan y el DVR doméstico (110) a continuación envía la información operativa al centro de servicios (130) cada vez que el DVR doméstico (110) accede al centro de servicios (130).
La actualización se puede llevar a cabo de forma automática. En dicho caso, cuando dos DVR se conectan, se lleva a cabo un conjunto de acciones preconfiguradas, tales como actualizar guías de programas o software y entonces los flujos multimedia también se pueden transferir. Si el DVR de destino (760) es una unidad portátil de menor tamaño, entonces no cabrían todos los flujos multimedia. En este caso, el espectador puede elegir de forma explícita qué flujos multimedia transferir. De manera alternativa, las aplicaciones informáticas en el DVR de origen pueden utilizar información de preferencia para seleccionar un subconjunto de los datos multimedia disponibles de más interés para el usuario y transferir solo estos flujos. En otra alternativa, los flujos multimedia se transfieren de más reciente a más antiguo, deteniéndose cuando ya no haya más espacio o de más antiguo a más reciente. Un pase de temporada (donde todas las visualizaciones de un programa en un canal se graben) puede incluir un marcador del DVR de «siempre transferir» o «nunca transferir». Otros criterios pueden ser si el programa se seleccionó o escogió de forma explícita según las preferencias del espectador. Cualquier información de programa almacenada en el objeto descriptivo para el contenido puede utilizarse en los criterios de selección, tales como longitud, actores, calificación, etc. Los criterios pueden desencadenar acciones tales como «siempre transferir».
G. ESQUEMA DE SEGURIDAD DE RED
Como se indicó anteriormente, un enfoque en la presente memoria proporciona una transferencia de datos cifrados segura entre los DVR (110), (760), (770) o un servidor de contenidos (720) y un DVR (110), (760), (770). El enfoque permite a los usuarios grabar un programa en un DVR (110) y luego ver el programa en otro DVR (770).
El sistema de transferencia de datos cifrados descrito en la presente memoria dificulta mucho la transferencia de vídeos de un DVR a cualquier sistema incompatible o a un sistema fuera de la ubicación del primer DVR. Por consiguiente, los usuarios pueden ejercer derechos de Uso Justo respecto de las grabaciones que se han realizado, pero el enfoque dificulta a los usuarios «piratear» vídeos o enviar contenido premium a sus amigos infringiendo los principios de Uso Justo.
Diversas realizaciones de los enfoques de la presente memoria pueden incluir los siguientes aspectos:
• Las grabaciones están cifradas. Muchas grabaciones se cifran cuando se graban en un principio. Aquellas grabaciones que no están cifradas se pueden cifrar antes de transferirse de un DVR a otro. Esto le dificulta a cualquiera «olfatear» los datos de grabación mientras viajan a través de una red doméstica y hacer una copia de los
5
10
15
20
25
30
35
40
45
50
55
60
datos.
• Cuando una grabación cifrada se transfiere de un DVR a otro, el sistema receptor no puede utilizar la grabación a menos que el sistema emisor también transfiera la clave de cifrado/descifrado asociada a esa grabación.
• Un DVR puede detectar otros sistemas desde los cuales podría transferir grabaciones mediante un mecanismo de emisión de IP u otro protocolo de detección de red. En dichos protocolos de detección, los paquetes de detección normalmente no abandonan la subred de IP local. En el entorno doméstico, una subred de IP local comprende una LAN de un entorno doméstico. De manera adicional o alternativa, si existe la preocupación de que un usuario intentará compartir grabaciones con otros usuarios, entonces la aplicación informática del DVR no proporciona ningún mecanismo que permitiera al propietario del sistema tipear o de otro modo especificar manualmente la dirección IP de un sistema ubicado en otro sitio en Internet.
• Un DVR únicamente puede enviar una clave de cifrado de grabación a otro DVR si el sistema receptor está «autorizado» para ver dicha grabación. Por ejemplo, en este contexto, «autorizado» puede significar que el DVR de destino está en la misma casa o está registrado por el propietario como autorizado. La transferencia de claves se lleva a cabo utilizando un sistema sólido de clave pública/privada en el cual cada clave transferida es inteligible únicamente para el sistema al cual se envió.
• La autorización se lleva a cabo mediante un certificado digital, que incluye los sistemas específicos que se sabe pertenecen a una casa o a un único usuario. El certificado incluye las claves públicas de los sistemas y está «firmado» por el proveedor de servicios. Cada sistema verifica la firma en el certificado que está usando y también verifica su propia identidad contra la que contiene el certificado, antes de transferir cualquier dato o claves a cualquier otro sistema.
El sistema de certificados puede estar basado en el sistema de clave pública/privada ElGamal y en el cifrado por bloques simétricos de Blowfish, que incluye una auto-verificación que bloquearía ataques tales como «cambiar un número de serie de un sistema» o «copiar un certificado a un sistema diferente» o «alterar un certificado».
Haciendo referencia a las figuras 7 y 9, un usuario se registra en el centro de servicios (130) para crear un registro de los DVR entre los cuales quiere compartir contenidos. Usando cualquier interfaz de usuario apropiada, el usuario introduce los números de serie de los DVR que desea incluir, que el centro de servicios (130) verifica mediante su base de datos, o el centro de servicios (130) encuentra los números de serie que el usuario ha registrado anteriormente. El centro de servicios (130) también puede restringir el usuario a solo los DVR de los cuales es propietario registrado mostrando únicamente esos DVR para ser seleccionados. El usuario puede asociar un nombre a cada unidad, p. ej., DVR de salón, de dormitorio, etc. para permitir al usuario identificar fácilmente una unidad. El usuario selecciona las unidades con las cuales quiere compartir o transferir datos multimedia.
El centro de servicios (130) crea un certificado digital (901) que identifica las unidades del usuario que ha seleccionado. El certificado (901) incluye el número de serie de cada unidad (903), (905) y la clave pública correspondiente (904), (905). El nombre que el usuario le ha asignado a cada unidad también tiene referencias cruzadas, como se indica con el nombre (902) en el certificado (901). El certificado puede contener cualquier cantidad de unidades que el usuario identifica, incluyendo PC con llaves USB como se describe más arriba.
Para garantizar que el certificado (901) no existe indefinidamente, se incluye una fecha de caducidad (907) en el certificado (901). Se utiliza una firma digital (908) para que las unidades que reciben el certificado puedan verificar que el certificado en realidad se originó en el centro de servicios (130).
El centro de servicios (130) envía el certificado a cada DVR (110), (770) incluido en el certificado (901) por la red (140) (que puede comprender Internet, una LAN, u otra red pública o privada), línea telefónica, o conexión satelital. El certificado (901) puede cifrarse utilizando la clave pública de cada DVR de destino (110), (760), (770). Un DVR portátil (760) puede conectar con el centro de servicios (130) mediante una conexión de red o línea telefónica para recibir su certificado. Como alternativa, el DVR portátil (760) puede recibir su certificado de un DVR (110) con el cual se conecta.
Cada DVR (110), (760), (770) verifica el certificado descifrando el certificado y verificando la firma digital (908) en el certificado (901). Una vez que el DVR ha verificado que la firma digital (908) procede del centro de servicios (130), el DVR encuentra las ubicaciones de red de todos los pares que están incluidos en el certificado (901), utilizando un protocolo de detección de pares, tal como Rendezvous de Apple Computer Inc. de Cupertino, California.
Una vez que el DVR (110) ha detectado un par (770) en la red, establece una conexión cifrada con el par (770) utilizando la clave pública del par del certificado (901). La conexión cifrada puede estar «débilmente» cifrada en el sentido de que es una función de dos claves públicas, una de cada par. Cada par envía un mensaje utilizando la clave pública del otro. Una unidad se designa como servidor de contenidos, en este ejemplo, el servidor de contenidos (720) es proporcionado por el proveedor de servicios y está en una ubicación remota.
5
10
15
20
25
30
35
40
45
50
55
60
El servidor de contenidos (720) crea una conexión cifrada de forma más segura con el DVR (110) creando una clave de conexión segura aleatoria y cifra la clave segura utilizando la clave pública del DVR. A continuación, el servidor de contenidos (720) envía la clave cifrada segura al DVR (110). El DVR (110) descifra la clave segura. En un enfoque, el descifrado puede utilizar elementos de descifrado de hardware. En ese momento los dos sistemas comparten una clave segura.
El usuario puede solicitar enviar determinado contenido grabado al DVR (110). Cuando el servidor de contenidos (720) envía una grabación cifrada previamente al DVR (110), carga una clave de grabación que se utilizó para cifrar la grabación desde su base de datos y cifra la clave de grabación utilizando la clave segura. El servidor de contenidos (720) envía la clave de grabación cifrada al DVR (110).
El DVR (110) descifra la clave de grabación utilizando la clave segura que comparte con el servidor de contenidos (720) y almacena la clave de grabación. El servidor de contenidos (720) envía el contenido grabado que ha almacenado localmente al DVR (110). El contenido grabado ya se ha cifrado cuando se fue almacenado originalmente y de manera local por el servidor de contenidos (720). El servidor de contenidos (720) envía el contenido grabado sin descifrar el contenido.
El DVR (110) escribe el contenido grabado directamente en su dispositivo de almacenamiento sin decodificarlo. Cuando el DVR reproduce el contenido grabado, decodifica el contenido sobre la marcha. El enfoque descrito en la presente memoria mantiene la integridad del contenido grabado puesto que el contenido está en un estado cifrado durante la transmisión y se almacena cifrado en el DVR, evitando de este modo cualquier copia no autorizada del contenido.
Si el servidor de contenidos (720) envía una grabación no cifrada al DVR (110), crea una clave de grabación aleatoria que se utilizará para cifrar la grabación y cifra la clave de grabación utilizando la clave segura. El servidor de contenidos (720) envía la clave de grabación cifrada al DVR (110).
El DVR (110) descifra la clave de grabación utilizando la clave segura que comparte con el servidor de contenidos (720) y almacena la clave de grabación. El servidor de contenidos (720) envía el contenido grabado que ha almacenado localmente al DVR (110). El contenido grabado no fue cifrado cuando se fue almacenado originalmente y de manera local por el servidor de contenidos (720). El servidor de contenidos (720) envía el contenido grabado, cifrando el contenido mientras envía el contenido.
El DVR (110) escribe el contenido grabado directamente en su dispositivo de almacenamiento sin decodificarlo. Cuando el DVR reproduce el contenido grabado, decodifica el contenido sobre la marcha. El enfoque todavía mantiene la integridad del contenido grabado puesto que el contenido está en un estado cifrado durante la transmisión y se almacena cifrado en el DVR, evitando de este modo cualquier copia no autorizada del contenido.
La figura 10 muestra un servidor multimedia (1002) en una configuración de DVR en red local en una casa (1001). En el ejemplo de la figura 10, el DVR (1003) está ubicado en el dormitorio 1, el DVR (1004) está ubicado en el dormitorio 2, y el DVR (1005) está ubicado en la sala de entretenimiento. El servidor multimedia (1002) está en el salón. El usuario envía información indicándole al centro de servicios (1006) que los DVR (1003), (1004), (1005) y el servidor multimedia (1002) están autorizados para compartir contenido y asocia cada unidad según la habitación donde se encuentre. El centro de servicios (1006) crea un certificado (901) que contiene el del servidor multimedia (1002) y el número de serie y clave pública de cada uno de los DVR (1003), (1004), (1005), junto con una fecha de caducidad y la firma digital del centro de servicios.
El servidor multimedia (1002) puede ser un PC, DVR u otro tipo de servidor de contenidos. El usuario designa el servidor multimedia (1002) como fuente principal de contenido multimedia en la red local.
El centro de servicios (1006) envía el certificado al servidor multimedia (1002) y a los DVR (1003), (1004), (1005) mediante Internet (1007). El servidor multimedia (1002) y los DVR (1003), (1004), (1005) utilizan la información del certificado para detectar a sus pares. Los DVR (1103), (1004), (1005) descubren que el servidor multimedia (1002) es el único sistema que está proporcionando contenido. Una vez que el servidor multimedia (1002) ha establecido una conexión débilmente cifrada con cada DVR (1003), (1004), (1005), crea una clave de conexión segura aleatoria para cada DVR (1003), (1004), (1005). El servidor multimedia (1002) cifra cada clave segura utilizando la clave pública particular del DvR y envía la clave cifrada segura a cada dVr (1003), (1004), (1005). El DVR utiliza su procesador criptográfico local para descifrar la clave segura. El servidor multimedia (1002) en ese momento comparte una clave segura con cada DVR (1003), (1004), (1005).
Haciendo referencia a las figuras 16-21, cada DVR tiene acceso a los contenidos del servidor multimedia. Con referencia, en primer lugar, a la figura 16, el usuario va a la pantalla de Reproducción Actual (1601) (que es similar
5
10
15
20
25
30
35
40
45
50
55
60
en formato y contenido a la pantalla de Reproducción Actual de la figura 6) y ve todos los servidores multimedia a los cuales el usuario puede acceder. Por ejemplo, una etiqueta (1602) de servidor multimedia indica que el usuario puede acceder al DVR denominado «Dormitorio». El usuario selecciona el servidor deseado utilizando la etiqueta (1602) y aparece una pantalla de contenido (1701) (figura 17) que muestra los contenidos que el servidor multimedia tiene disponibles. El usuario puede solicitar que cierto contenido grabado (música, fotos, vídeos, etc.) sean enviados a un DVR (1003) particular mediante la pantalla de contenido (1701). El usuario puede hacer esto de forma remota como se describe más arriba, o mediante el propio DVR (1003). El usuario selecciona las opciones para transferir el contenido seleccionado utilizando una pantalla de opciones de transferencia (1801) (figura 18). El usuario puede seleccionar desde dónde comenzar la transferencia utilizando una opción «Comenzar desde» (1802). Por ejemplo, la transferencia puede empezar desde el comienzo del programa, desde donde el usuario pausó la reproducción por última vez, o a determinada hora en el programa. El usuario puede ver y transferir contenido de música y contenido de fotos de la misma manera, como se indica con la captura de pantalla (2001) de la figura 20 y la captura de pantalla (2101) de la figura 21.
Tal y como se describe anteriormente con referencia a la figura 10, el servidor multimedia (1002) puede enviar una grabación previamente cifrada al DVR (1003). El servidor multimedia (1002) carga una clave de grabación que se utilizó para cifrar la grabación desde su base de datos y cifra la clave de grabación utilizando la clave segura. Como opción, el servidor multimedia (1002) puede cifrar la clave de grabación para almacenarla en su base de datos utilizando una clave de cifrado local. Normalmente no es deseable almacenar ninguna de las claves de cifrado en archivo de texto, por lo que se prefiere un cifrado simple con una clave local. Envía la clave de grabación cifrada al DVR (1003).
El DVR (1003) descifra la clave de grabación utilizando la clave segura que comparte con el servidor multimedia (1002) y almacena la clave de grabación. El DVR (1003) puede, como opción, cifrar la clave de grabación utilizando una clave local antes del almacenamiento. El servidor multimedia (1002) envía el contenido grabado que ha almacenado localmente al DVR (1003). El contenido grabado ya se ha cifrado cuando se fue almacenado originalmente y de manera local por el servidor multimedia (1002). El servidor multimedia (1002) envía el contenido grabado sin descifrar el contenido.
El DVR (1003) escribe el contenido grabado directamente en su dispositivo de almacenamiento sin decodificarlo. Cuando el DVR (1003) reproduce el contenido grabado, decodifica el contenido sobre la marcha utilizando la clave de grabación. En lo que respecta a la figura 19, el usuario puede seleccionar la pantalla de información de programas (1901) para ver si el programa todavía se está transfiriendo. El usuario puede reproducir el programa seleccionando la opción de «Reproducir» (1902) mientras la transferencia está en proceso (como se describe más arriba) o detener la transferencia utilizando la opción de «Detener transferencia» (1903).
Si el servidor multimedia (1002) envía una grabación no cifrada al DVR (1003), crea una clave de grabación aleatoria que se utilizará para cifrar la grabación y cifra la clave de grabación utilizando la clave segura. El servidor multimedia (1002) envía la clave de grabación cifrada al DVR (1003).
El DVR (1003) descifra la clave de grabación utilizando la clave segura que comparte con el servidor multimedia (1002) y almacena la clave de grabación. El DVR (1003) puede, como opción, cifrar la clave de grabación utilizando una clave local antes del almacenamiento. El servidor multimedia (1002) envía el contenido grabado que ha almacenado localmente al DVR (1003). El contenido grabado no fue cifrado cuando se fue almacenado originalmente y de manera local por el servidor multimedia (1002). El servidor multimedia (1002) envía el contenido grabado, cifrando el contenido mientras envía el contenido.
El DVR (1003) escribe el contenido grabado directamente en su dispositivo de almacenamiento sin decodificarlo. Cuando el DVR (1003) reproduce el contenido grabado, decodifica el contenido sobre la marcha utilizando la clave de grabación.
Obsérvese que si los derechos de autor del contenido constituyen un motivo de preocupación, el DVR (1003) no necesita almacenar el contenido en su dispositivo de almacenamiento. Simplemente reproduce o muestra el contenido de inmediato. Si el contenido se cifra, el DVR (1003) descifra el contenido sobre la marcha.
El enfoque descrito más arriba funciona igualmente bien en una red local como lo hace por Internet.
H. MANTENER COHERENCIA DE CERTIFICADOS
Con referencia, nuevamente, a la figura 11, la creación de una clave segura lleva muchos ciclos de CPU. En un enfoque, al DVR (1101) se le puede requerir que cree y almacene una pluralidad de claves seguras para uso futuro en el momento que se designa como servidor multimedia. Asimismo, el DVR receptor requiere muchos ciclos de
5
10
15
20
25
30
35
40
45
50
55
60
CPU para descifrar la clave segura cuando se recibe. Esto ralentiza de manera significativa el funcionamiento general del DVR. Las técnicas de la presente memoria le ahorran al DVR (1101) la carga adicional de crear una nueva clave segura cada vez que el DVR (1102) se vuelve a encender o se reinicia. También le ahorra al DVR (1102) la carga de descifrar la clave segura después de que se vuelve a encender o se reinicia.
El DVR (1101) originalmente crea una clave de conexión segura, la almacena en su memoria caché local (1103) y cifra la clave utilizando la clave pública del otro DVR (1102). El DVR (1101) envía la clave cifrada segura al DVR (1102). El DVR (1102) descifra la clave segura y almacena la clave en su memoria caché local (1104) junto con la clave cifrada segura y el número de serie de máquina del DVR (1101).
Si el DVR (1102) se vuelve a encender o se reinicia, no sabe cuál es su estado en la red. Puede haber estado inactivo durante unos breves segundos o se puede haber trasplantado de otra red. El DVR (1102) solicita la clave segura del DVR (1101) designado como servidor multimedia. El DVR (1101) envía la clave segura que ha almacenado en su memoria caché local (1103), o si el DVR (1102) no ha tenido una conexión segura establecida con el DVR (1101), crea una nueva clave segura. La clave segura se cifra utilizando la clave pública del DVR (1102) y se envía al DVR (1102).
Cuando el DVR (1102) recibe la clave cifrada segura, verifica la memoria caché local (1104) buscando una entrada desde el DVR (1101) y, si detecta una, realiza una comparación bit a bit con la clave cifrada en la memoria caché local (1104). Si las dos claves son iguales, entonces el DVR (1102) utiliza la clave descifrada previamente, almacenada en la memoria caché local (1104). De lo contrario, el DVR (1102) descifra la clave recién enviada y almacena la clave cifrada, clave descifrada y número de serie de máquina del DVR (1101) en una nueva entrada en la memoria caché local (1104). De esta forma se evita la larga etapa de descifrado a menos que sea estrictamente necesaria.
I. DESCARGA DE DATOS MULTIMEDIA DE INTERNET
Para facilitar la descarga de datos multimedia de Internet de un servidor a un DVR, la figura 12 muestra una modificación del certificado digital representado en la figura 9. Asimismo, de nuevo con referencia a la figura 7, el centro de servicios (130) crea el certificado (901) que se distribuye a los DVR (110), (770). Los DVR (110), (770) reconocerán una entrada de servicio utilizando un número de serie especialmente prefijado en el campo de número de serie del servicio (903), por ejemplo: FFFxxxxxxxxxxxx, donde "xxxxxxxxxxxx" se utiliza para proporcionar información adicional, tal como números de versiones, proveedor de servicios, etc. El nombre de pantalla (902) se configura como indicativo del servicio, tal como "Vídeos especiales". En vez de una clave pública directa, el campo de clave (1204), (1206) se rellena con un nombre de dominio completamente calificado del punto de acceso para el servidor.
El certificado (901) puede contener una mezcla de información de servidor de servicios e información sobre unidad par. La fecha de caducidad (907) y firma digital (908) permanecen iguales.
Por lo tanto, el centro de servicios (130) puede colocar información en los campos de todos, o un grupo de, los certificados para nombrar los servidores iguales o diferentes, etc.
Un DVR (110) reconoce el número de serie de servicio en el certificado y envía un sonido metálico al servidor utilizando el nombre de dominio en el campo de clave, por ejemplo, el campo de clave (1204), para ver si es alcanzable. Cuando se conecta un nuevo DVR, el servidor busca la clave pública del DVR y la utiliza para generar cualquier otra clave necesaria. El DVR no necesita tener una clave para el servidor; el servidor genera la clave segura para la sesión y cifra la clave segura con la clave pública del DVR. Luego pasa la clave cifrada segura al DVR.
Una vez que se establece la comunicación el DVR (110) puede consultar contenido al servidor.
El servidor sintetiza los metadatos apropiados para describir lo que tiene disponible y lo envía al DVR (110). Desde que los metadatos se sintetizan, se pueden crear de manera excepcional por DVR. Por ejemplo, un propietario de DVR puede suscribirse a distintos tipos de servicio, tales como historia, drama, comedia, etc.
Como alternativa, el servidor puede ordenar al DVR (110) que envíe su vector de preferencia al servidor, que el servidor utiliza para sintetizar los metadatos apropiados. El vector de preferencia del DVR contiene los hábitos de visualización del usuario, p. ej., lo que el usuario ha indicado que le gusta y no le gusta, lo que ha grabado consecuentemente utilizando opciones tales como suscripción de abono de temporada. El servidor no almacena la información de vector de preferencia; simplemente descarta la información después de utilizarla. Esto mantiene la privacidad del usuario y garantiza que las preferencias siempre se guarden en el DVR (110).
5
10
15
20
25
30
35
40
45
50
55
60
La interfaz estándar de transferencia de vídeos, música y fotos se utiliza como se describe más arriba. La figura 16 muestra una pantalla de Reproducción Actual (1601) donde se muestra contenido disponible del propio DVR y de otros servidores y DVR accesibles (1602). Una entrada para contenido desde un servicio tiene su nombre asociado del certificado incluido. De la misma manera, el contenido de otro DVR se incluye utilizando el nombre (1602) que el usuario ha asociado a él, si es que existe. De esta manera, el usuario conoce la fuente del contenido. La figura 17 muestra la pantalla de contenido (1701) que enseña el nombre de la fuente de contenido (1702). Las figuras 20 y 21 muestran una pantalla de contenido musical (2001) y una pantalla de contenido fotográfico (2101).
En lo que respecta a la figura 13, los DVR que están interesados en descargar contenido de un servidor (1301), envían un ping al servidor (1301). El servidor (1301) controla el servicio de ping, respondiendo a peticiones de DVR a medida que entran. Esto permite al servidor (1301) mantener un registro (1302) de todos los DVR que están «suscritos» para descargar vídeos. El registro (1302) luego puede auditarse para garantizar, por ejemplo, que no hay clones de DVR que están accediendo al vídeo descargable desde otra dirección IP. El registro (1302) también se puede utilizar a efectos de facturación, para rastrear el tiempo que un usuario tiene su DVR (1303) suscrito para descargar vídeos.
Cuando el usuario selecciona una entrada de un servidor (1301) para transferir a un DVR (1303), el DVR (1303) contacta con el servidor (1301) y solicita el objeto multimedia apropiado. En este punto, el servidor (1301) puede registrar (1302) que el programa está siendo descargado, lo cual también puede incluir una entrada en un sistema de facturación, etc.
Los registros pueden ser consultados en el sitio web del centro de servicios por un usuario (1304) de modo que pueda fácilmente revisar su factura.
En lo que respecta a la figura 14, se puede utilizar un redirector de nombre de dominio (1402) que redirige una conexión desde un DVR (1401) a un grupo de servidores de terceros (1403), (1404), (1405). El redireccionamiento se puede producir según la carga, el prefijo de nombre de dominio utilizado, etc. Esto permite que el centro de servicios redireccione una petición a un servidor de otra compañía. El redireccionamiento puede contemplar una tarifa o un porcentaje de ingresos en diversas realizaciones.
Un redirector de nombre de dominio (1402) puede residir en cada servidor de terceros (1403), (1404), (1405), por lo que una petición de un DVR (1401) puede ser redireccionada por el propio servidor de terceros. El DVR (1401) solicita una conexión con el servidor de terceros (1403). El servidor de terceros (1403) «delega» sus responsabilidades al servidor de terceros (1404) redireccionando la petición del DVR (1401) al servidor de terceros (1404). A continuación, el DVR (1401) contacta con el servidor de terceros (1404) para sus solicitudes de contenido. Esto le permite a un servidor de terceros juzgar por sí mismo si está sobrecargado o no puede manejar una petición por algún motivo.
J. UTILIZAR UN DVR COMO CANALIZACIÓN DE CIFRADO
En lo que respecta a la figura 15, el contenido que se ha de proporcionar al DVR (1503), (1504), (1505) puede ser producido inicialmente por un servidor de contenidos (1501), tal como un servidor de contenidos de terceros. El servidor de contenidos (1501) no tiene acceso a ninguna información acerca de las técnicas o arquitectura de cifrado del DVR. Para codificar y cifrar el contenido se utiliza un DVR (1502). El DVR (1502) tiene un motor de red rápido y funciona como una «canalización de cifrado». Los datos se envían desde el servidor de contenidos (1501) hasta el DVR (1502). El DVR (1502) codifica (si es preciso) y cifra los datos mientras escribe los datos en su dispositivo de almacenamiento local. A continuación, el DVR (1502) lee los datos del dispositivo de almacenamiento local sin descifrarlos, y envía los datos por la red hasta un DVR destino seleccionado entre los DVR (1503), (1504), (1505).
Otro enfoque le ofrece al servidor de contenidos de terceros una transmisión segura de su contenido. Los datos se envían desde el servidor de contenidos (1501) hasta el DVR (1502) utilizando la técnica de cifrado del servidor de contenidos. El DVR (1502) descifra los datos utilizando la técnica de descifrado del servidor de contenidos. A continuación, el DVR (1502) codifica (si es preciso) y cifra (utilizando la técnica de cifrado del DVR) los datos mientras escribe los datos en su dispositivo de almacenamiento local. A continuación, el DVR (1502) lee los datos del dispositivo de almacenamiento local sin descifrarlos, y envía los datos por la red hasta un DVR destino seleccionado entre los DVR (1503), (1504), (1505).
Esto garantiza que el proveedor de contenidos de terceros no tiene acceso a ninguna información sensible acerca del procesador criptográfico, técnicas de cifrado o esquemas de direccionamiento del DVR. Además reduce el tiempo de comercialización y el coste de incorporar proveedores de terceros en la red de servidores de contenidos.
5
10
15
20
25
30
35
40
45
50
55
60
K. ACCEDER A CONTENIDO VIA CORREO ELECTRONICO
Como se describió anteriormente, el servidor multimedia en cualquiera de las realizaciones precedentes puede ser un PC, DVR o cualquier otro mecanismo que pueda proporcionar contenido. Los enfoques descritos en la presente memoria permiten a los DVR, como clientes del servidor multimedia, acceder a contenido multimedia tal como contenido musical, de vídeo y fotográfico almacenado en servidores multimedia. No obstante, puesto que los DVR y los servidores multimedia puede tener acceso a Internet, el contenido no necesita originarse o estar físicamente alojado en cualquier servidor multimedia determinado.
En consecuencia, el contenido puede ofrecerse a los usuarios de DVR haciendo que un servidor procese un fichero especial que contenga:
• Contenido real (en forma de ficheros JPEG, MP3 o MPEG, por ejemplo).
• Ajustes de configuración de DVR, por ejemplo, registrando horarios, modificaciones de base de datos, preferencias de contenido, etc.
• «Enlaces» a otro servidor o al contenido almacenado en otro servidor, ubicado potencialmente en cualquier lugar de Internet.
Dichos ficheros se pueden ofrecer a usuarios de DVR mediante correo electrónico o descarga de Internet. A continuación se describen dos situaciones de ejemplo que demuestran cómo se puede enviar contenido mediante correo electrónico a un DVR.
Haciendo referencia a las figuras 22 y 23, se muestra la configuración de un DVR doméstico típico (2201). Se ha de suponer que solo el servidor multimedia (2202) tiene acceso a Internet (2205). Un autor de correo electrónico (2204) crea un fichero de contenido con software de autor. El fichero, por ejemplo, contiene los datos binarios reales para distintas imágenes en formato JPEG (puede contener cualquier tipo de contenido). El fichero de contenido se envía por correo electrónico como un adjunto a un usuario que accede al correo electrónico desde el mismo ordenador que ejecuta el servidor multimedia (2202). Se pueden utilizar mecanismos de comunicación de mensajes que no sean correo electrónico en realizaciones alternativas.
El usuario lee el correo electrónico y, si está interesado en el contenido, el usuario selecciona el fichero de contenido adjunto, invocando al servidor multimedia (2202) para que procese el fichero de contenido. El servidor multimedia
(2202) añade información sobre las imágenes a una base de datos interna desde la cual posteriormente se puede generar información del contenedor (metadatos) y datos JPEG.
El usuario va a su DVR (2203) y accede a la función «Música y Fotos» a través de su televisor, haciendo que el DVR
(2203) solicite información del contenedor del servidor multimedia (2202). Entre los otros contenedores de contenido disponible mostrados en la pantalla de contenido fotográfico (figura 21), el usuario puede en ese momento acceder a uno con imágenes del fichero de contenido. Cuando el usuario emite la orden de visualizar una de las imágenes, el DVR (2203) realiza una petición al servidor multimedia (2202), que consulta a su base de datos interna para proporcionar los datos JPEG adecuados y pasar los datos al DVR (2203). El DVR (2203) muestra la imagen al usuario y no almacena la imagen en su dispositivo de almacenamiento local. El usuario puede usar funciones trick- play en los múltiples ficheros de fotos tales como adelantar, pausar, retroceder, reproducir (presentación), etc.
En la figura 23, se muestra la configuración de un DVR doméstico (2301) donde tanto el DVR (2303) como el servidor multimedia (2302) tienen acceso a Internet (2305). Un autor (2304) crea un fichero de contenido con software de autor. El fichero enlaza con uno o más ficheros de contenido, tales como ficheros de música MP3, alojados en el servidor de contenidos (2306) y proporcionados vía HTTP. El fichero de contenido se envía por correo electrónico como un adjunto a un usuario que (idealmente) accede al correo electrónico desde el mismo ordenador que ejecuta el servidor multimedia (2302).
El usuario lee el correo electrónico y, si está interesado en el contenido, el usuario selecciona el fichero de contenido adjunto, invocando al servidor multimedia (2302) para que procese el fichero de contenido. El servidor multimedia (2302) añade información sobre los ficheros de contenido a una base de datos interna desde la cual posteriormente se puede generar información del contenedor.
El cliente va a su DVR (2303) y accede a la función «Música y Fotos», haciendo que el DVR (2203) solicite información del contenedor del servidor multimedia (2302). Entre los otros contenedores de contenido disponible mostrados en la pantalla de contenido musical (2001) (figura 20), el usuario puede en ese momento acceder a uno con música proporcionada por el servidor de contenidos (2306). Cuando el usuario emite la orden para reproducir uno de los ficheros de música, el DVR (2303) accede al servidor de contenidos (2306) directamente por Internet (2305) para recuperar los datos apropiados. El usuario puede utilizar funciones trick-play en los ficheros de música
5
10
15
20
25
30
35
40
45
50
55
60
tales como adelantar, pausar, retroceder, reproducir, etc. El progreso de reproducción de la música se muestra al usuario mediante un televisor conectado utilizando una barra de reproducción mostrada en la figura 8. El DVR (2303) no almacena la música en su dispositivo de almacenamiento para proteger los derechos de autor.
Como se indica más arriba, los dos ejemplos precedentes se pueden utilizar para cualquier tipo de contenido que un DVR pueda utilizar o mostrar. Si se recibe información de configuración, el DVR (2303) almacenará la información de configuración en su dispositivo de almacenamiento local y utilizará la información de configuración para configurarse a sí mismo. Si se recibe vídeo, el DVR (2303) puede almacenar el contenido de vídeo en su dispositivo de almacenamiento local para que el usuario lo reproduzca más tarde. El usuario puede usar funciones trick-play en el contenido de vídeo tales como adelantar, pausar, retroceder, reproducir, reproducir en cámara lenta, pasos de fotograma, etc.
Los usuarios de DVR podrían utilizar el enfoque para compartir contenido entre sí por correo electrónico. Por ejemplo, un usuario podría enviar a otro usuario un fichero de contenido con enlaces a fotos personales alojadas en el PC del primer cliente.
Además, el enfoque de la presente memoria puede resultar útil para que proveedores de terceros comercialicen contenido a usuarios de DVR vía correo electrónico. Por ejemplo, una etiqueta de registro podría promover un nuevo álbum enviando un fichero de contenido con enlaces a ficheros MP3 que contienen canciones de muestra.
Los socios de terceros pueden utilizar el enfoque de la presente memoria para entregar productos a usuarios de DVR por correo electrónico. Por ejemplo, un laboratorio de revelado de fotos podría enviar por correo electrónico un fichero de contenido con fotos digitalizadas compradas online por un usuario de DVR.
L. DISTRIBUIR CONTENIDO UTILIZANDO MULTIDIFUSIÓN IP
Hacer que los DVR contacten directamente con un servidor de contenidos para obtener contenidos ofrece la ventaja de permitir que un DVR obtenga contenidos bajo demanda. Una desventaja es que el servidor de contenidos se puede sobrecargar con peticiones de contenidos de una gran cantidad de DVR. El servidor de contenidos constituye entonces el cuello de botella del sistema. Una solución sería añadir más servidores de contenidos de modo que la carga de peticiones se pueda distribuir entre un mayor grupo de servidores de contenidos. No obstante, esa solución no prospera puesto que la cantidad de DVR aumenta mucho. La red de servidores de contenidos se vuelve más difícil y costosa de mantener a medida que la red crece para alcanzar el número de DVR.
En realidad, hay una gran cantidad de contenido que no se necesita obtener mediante el DVR de forma inmediata, por ejemplo, actualizaciones de software, anuncios, grabaciones multimedia difusas, etc. Los DVR pueden esperar a que dicho contenido salga de los servidores de contenidos hacia los DVR. Un DVR simplemente tiene que esperar a que se envíe una transmisión programada y escuchar en la red que el contenido esperado se transmite mediante el servidor de contenidos. Un protocolo de comunicaciones que tiene la capacidad para realizar este tipo de sincronización entre servidores y clientes es la multidifusión IP.
La multidifusión IP es un enfoque que ahorra ancho de banda y que reduce el tráfico entregando simultáneamente un flujo único de información a una gran cantidad de clientes. La multidifusión IP suele utilizarse en aplicaciones tales como: videoconferencias, comunicaciones corporativas, y distribución de software, cotización de acciones, y noticias.
La multidifusión IP entrega tráfico de contenido de servidor a múltiples clientes sin añadir carga adicional en los servidores o clientes a la vez que utiliza el menor ancho de banda de red de cualquier tecnología rival. Las aplicaciones de gran ancho de banda, tales como vídeo MPEG, pueden requerir una gran porción del ancho de banda de red disponible para un único flujo. En estas aplicaciones, la forma más eficaz de enviar el contenido a más de un receptor simultáneamente es utilizar multidifusión IP. La multidifusión IP requiere que los enrutadores, conmutadores, cortafuegos, otros equipos de red, y dispositivos conectados que participan en la multidifusión tengan conocimiento de la multidifusión (según se describe en los requisitos RFC 1458, que se incorporan a la presente como referencia).
La figura 24 muestra una red (2402) que tiene componentes de red compatibles con multidifusión interconectados. Una red (2402), tal como Internet, una intranet, etc. está compuesta por enrutadores interconectados (2403-2408). Los enrutadores (2403-2408) enrutan paquetes de información entre dispositivos conectados tales como una fuente (2401) y dispositivos host (2409-2411). La multidifusión IP es distinta de la emisión porque, en la emisión, una fuente envía un paquete que se distribuye a y es recibido por todos los host de la red. En cambio, los datos de una fuente se entregan a distintos receptores interesados utilizando multidifusión IP. Esto significa que una fuente (2401) puede enviar un mensaje de multidifusión IP mediante la red (2402) a un número arbitrario de receptores. Los paquetes de
5
10
15
20
25
30
35
40
45
50
55
60
multidifusión IP se replican en la red (2402) mediante enrutadores (2403-2408).
Un grupo arbitrario de receptores expresa interés en recibir un flujo de datos en particular. El grupo de receptores no tiene ningún límite físico o geográfico, por lo que los host (2409-2411) se pueden ubicar en cualquier lugar de Internet. Cualquier host que esté interesado en recibir datos que fluyen a un grupo particular se une al grupo utilizando el Protocolo de Gestión de Grupos de Internet (IGMP, por su sigla en inglés). El protocolo IGMP se describe con mayor detalle en los requisitos RFC 2236, que se incorporan a la presente como referencia. Un host debe ser miembro del grupo para recibir el flujo de datos. El protocolo IGMP se utiliza para registrar de manera dinámica hosts individuales en un grupo de multidifusión en una LAN particular. Un host (2409-2411) identifica miembros del grupo enviando mensajes de IGMP a su enrutador local. Los enrutadores (2403-2408) escuchan mensajes IGMP y envían de forma periódica consultas para detectar qué grupos están activos o inactivos en una subred particular.
M. APLICAR CONTENIDO DE MULTIDIFUSIÓN A MÚLTIPLES DVR
A medida que la popularidad de los DVR aumenta, más hogares tendrán múltiples DVR. En lo que respecta a la figura 25, los DVR (2502), (2503), (2504), (2505) están instalados en un único entorno doméstico. El usuario conecta los DVR (2502), (2503), (2504), (2505) a una red local. Los DVR (2502), (2503), (2504), (2505) pasan por una fase de detección de forma periódica para determinar qué DVR están conectados a la red local. Los DVR (2502), (2503), (2504), (2505) detectan la presencia de unos y otros mediante un protocolo de emisión que permite que cada DVR encuentre otros DVR dentro de la red local. La red doméstica local (2508) se conecta a Internet (2507) mediante una conexión módem (2509), por ejemplo, un módem DSL, por cable o satelital. Los DVR (2502), (2503), (2504), (2505) acceden a la red doméstica local (2508) mediante conexiones de Ethernet, inalámbricas y/o USB, por ejemplo.
Una realización del DVR de la invención tiene cuatro fuentes para contenido multimedia (como se describe más arriba): 1) Teledifusión (es decir, cable, satelital, terrestre, etc.); 2) servidores multimedia; 3) otros DVR; y 4) servidores de contenidos. Los DVR (2502), (2503), (2504), (2505) tienen capacidad para solicitar contenido de los servidores de contenidos tales como el servidor de contenidos (2506) a través de Internet (2507).
El contenido tal como programas de TV, películas, música, fotografías, anuncios, descargas de software, información de guía de programas, y cualquier contenido que se pueda representar como información digital puede ser solicitado por los DVR (2502), (2503), (2504), (2505), y proporcionarse al servidor de contenidos (2506). Con cada DVR que contacte un servidor de contenidos, se puede crear un cuello de botella en dos posibles puntos en el trayecto de conexión. El primer cuello de botella puede estar en la conexión de Internet del entorno doméstico (2509). Con cada DVR que haga peticiones al servidor de contenidos (2506) el tráfico para peticiones al servidor de contenidos (2506) y contenido del servidor de contenidos (2506) aumenta al punto de exceder la capacidad de ancho de banda de la conexión. Este tipo de cuello de botella afecta a todos los dispositivos conectados a la red doméstica local (2508) porque el acceso a Internet sufre de manera significativa.
El segundo cuello de botella puede ser el propio servidor de contenidos (2506). El servidor de contenidos (2506) debe atender a las peticiones de contenido de una gran cantidad de DVR, lo que significa que el servidor de contenidos (2506) debe enviar contenido a cada DVR que hace una petición. Las peticiones de contenido pueden ser redundantes, forzando al servidor de contenidos (2506) a mantener simultáneamente múltiples flujos del mismo contenido. El cuello de botella ralentiza el tiempo de respuesta y flujo de contenidos del servidor de contenidos para todos los DVR que realizan peticiones.
Utilizando multidifusión IP, cada DVR puede suscribirse a un grupo particular que esté asociado a un flujo de contenidos que el DVR esté interesado en recibir. Un servidor de contenidos (2506) puede ser el multidifusor para un grupo o conjunto de grupos. Un DVR puede suscribirse a y darse de baja de grupos cuando lo desee de la misma manera en la que se cambia de canal en un sintonizador de TV.
Los DVR necesitan una forma para programar sus suscripciones a grupos. El servidor de contenidos (2506) puede generar un programa de horarios de transmisión y descripción de contenidos para cada grupo al cual proporciona contenido. Un DVR puede obtener el programa durante una breve conexión al servidor de contenidos (2506) donde se puede proporcionar un programa diario de flujos de datos multidifusión. De este programa, ya sea automáticamente o como resultado de una petición de usuario, un DVR puede acumular en cola una o más «recepciones», es decir, horas a las cuales el DVR se unirá a un grupo de multidifusión y capturará el flujo de datos multidifusión.
En una realización de la invención, ya sea automáticamente o cuando lo ordene el usuario, un DVR puede contactar con el servidor de contenidos (2506) para consultar el horario de multidifusión para un flujo de datos en particular relacionado con un contenido específico. Una vez informado del horario de transmisión programado, el DVR puede
5
10
15
20
25
30
35
40
45
50
55
60
programar nuevamente una recepción de este flujo.
En lo que respecta a la figura 26, un servidor de contenidos (2506) crea un programa de horarios de transmisión para flujos de datos y asigna los flujos a grupos de los cuales es responsable (2901). Los DVR (2601-2609) consultan el servidor de contenidos (2506) para obtener el programa a través de la red (2507) y reciben el programa (2902) o el servidor de contenidos (2506) envía el programa a los DVR (2601-2609). El programa contiene descripciones de contenido de cada flujo de datos para determinada franja horaria junto con los horarios de transmisión de cada descripción de contenido en particular.
El servidor de contenidos (2506) recupera contenido de una zona de almacenamiento de contenido (2610) y transmite el contenido por Internet según el programa publicado mediante una transmisión multidifusión designada para un grupo de multidifusión en particular.
Cada DVR determina el contenido en el cual está interesado. El DVR encuentra el horario programado para transmisión del contenido y programa un horario de grabación en su programa de grabación (2903). Cuando el programa de grabación indica que el DVR debe iniciar una grabación del grupo, el DVR se une al grupo (como se describe más arriba) que figura en la lista de la grabación (2904). El DVR recibe el flujo multidifusión para el grupo y almacena el flujo en su dispositivo de almacenamiento local para que lo use el DVR o para que el usuario (2905) lo visualice.
Como alternativa, cada DVR puede suscribirse a un grupo de multidifusión siempre presente en el cual el servidor de contenidos (2506) publica información acerca de transmisiones según están programadas, permitiendo que el DVR o el usuario tomen decisiones en tiempo real en cuanto a si capturar el flujo o no. Por ejemplo, se puede producir un «evento de última hora» (tal como un bombardeo), y las imágenes se pueden transmitir en un flujo multidifusión de noticias de forma inmediata. El DVR puede capturar las imágenes automáticamente según una configuración o preferencia de usuario o el DVR puede informar al usuario de forma inmediata mediante una visualización en pantalla del evento e indicarle que las imágenes están disponibles. En el último caso, el usuario le ordena al DVR que reciba el flujo multidifusión. El DVR se suscribe inmediatamente al grupo y recibe el flujo de datos. El DVR decodifica el flujo de datos del formato en el cual se transmita y lo convierte al formato original del DVR. A continuación el flujo se le muestra al usuario.
La red (2507) puede ser cualquier red tal como Internet, intranet, red satelital, etc. Cuando se utiliza una red híbrida, p. ej., enlace descendente de satélite y canal posterior de banda ancha o por línea conmutada, el sistema funciona de la misma manera. Los flujos de multidifusión se emiten en el enlace descendente de satélite y las peticiones de DVR viajan a través del canal posterior.
Una petición de DVR de un flujo de datos en particular desde un servidor de contenidos puede no resultar en la programación inmediata de su transmisión. En cambio, la petición se puede grabar junto con peticiones de otros DVR. Utilizando estas peticiones guardadas, ya sea de forma automática o manual, un servidor de contenidos puede programar la transmisión de un flujo de datos en cualquier horario según cualquier conjunto útil de parámetros.
Por ejemplo, un flujo de datos muy solicitado se puede programar para transmitirse en un futuro próximo, mientras que la transmisión de un flujo rara vez solicitado se puede retrasar hasta que el coste de ancho de banda disminuya. Como alternativa, un flujo de datos se puede programar antes o después según importancia, relación con eventos actuales, o debido al pago de importes superiores por parte del autor del flujo al servicio de proveedores de contenidos.
No se requiere que los flujos de datos se envíen o lleguen a velocidades de emisión de datos multimedia en tiempo real. El DVR puede almacenar en búfer la transmisión entera en su unidad de disco o memoria local antes de poner el contenido a disposición del usuario.
El DVR se puede suscribir a múltiples grupos y puede recibir múltiples flujos de multidifusión en paralelo. Los flujos pueden ser de distinto ancho de banda y diferir en el contenido. Esto permite que el DVR haga el mejor uso de su ancho de banda y que satisfaga varias necesidades a la vez.
Utilizando distintas técnicas, es posible codificar la transmisión de datos de tal modo que se pueda tolerar una cantidad moderada de paquetes perdidos. El balance es un aumento en el tamaño de la transmisión (para redundancia), pero esa situación es tolerable en una situación de tiempo no real. En el peor de los casos, si el DVR no puede recibir de manera satisfactoria la transmisión completa, puede esperar a la siguiente transmisión de ese flujo de datos y reintentar la captura del flujo.
N. CREAR UNA RED DE MULTIDIFUSIÓN VIRTUAL
5
10
15
20
25
30
35
40
45
50
55
60
En el caso de que la multidifusión IP tenga demasiadas restricciones en el equipo de red, se puede implementar un sistema de multidifusión virtual utilizando varios DVR en red. Haciendo referencia a las figuras 27 y 30, se muestra un sistema de multidifusión virtual que utiliza tunelización multidifusión de DVR. Mediante la emisión, los DVR (27032706) se detectan unos a otros (3001) y designan qué DVR será el «túnel de multidifusión» (3002). En este ejemplo, el DVR (2703) se designa como el túnel de multidifusión. Las conexiones entre los DVR (2703-2706) mostradas en la figura 27 reflejan un enrutamiento de datos conceptual y no las conexiones eléctricas físicas reales en la red local.
El DVR (2703) «ganador» se conecta con el Centro de emisión (2701) y se registra para recibir cualquier flujo multidifusión de interés (3003) por la red (2702). Los otros DVR (2704-2706) de la red se registran en el DVR ganador (2703) para transmisiones multidifusión específicas. El Centro de emisión (2701) transmite un flujo de datos multidifusión (3004) por Internet (2702) al DVR ganador (2703). El DVR ganador (2703) recibe los paquetes de flujos de datos multidifusión (3005) y reemite los paquetes por la red local a los otros DVR (2704-2706) que se han registrado para el flujo de datos específico (3006). El DVR ganador (2803) se ha transformado en un dVr túnel de multidifusión, llevando de este modo los flujos multidifusión a la red local de manera eficaz.
Como alternativa, el DVR ganador (2703) puede simplemente reemitir los paquetes por la red local a los otros DVR (2704-2706) y permitir que los otros DVR decidan si conservan, ignoran o descartan los paquetes.
Si bien en la figura 27 se muestra un conjunto de varios DVR, una realización de la invención cubre fácilmente múltiples conjuntos de DVR y Centros de emisión. Como se indica más arriba, un DVR puede recibir múltiples flujos multidifusión que varían en ancho de banda y difieren en contenido. El DVR puede registrarse para múltiples transmisiones multidifusión con múltiples Centros de emisión así como con un único Centro de emisión.
Un flujo multidifusión puede encapsular otro u otros flujos multidifusión. Esto significa que un DVR que se elige como túnel de multidifusión puede desempaquetar el uno o más flujos multidifusión y enviarlo o enviarlos a otros túneles de multidifusión o emitir los flujos de manera local. Además, el o los flujos multidifusión encapsulados pueden contener uno o más flujos multidifusión hasta una capacidad lógica.
El Centro de emisión (2701) necesita aumentar de tamaño para manejar varios millones de DVR activos. Para admitir esto, el protocolo utilizado para iniciar el túnel de multidifusión admite delegación, es decir, un servidor de Centro de emisión que responde puede redireccionar el DVR túnel de multidifusión local a otro servidor de Centro de emisión. Esto permite un equilibrio de carga entre los servidores de Centro de emisión y además permite asignar un servidor de Centro de emisión a los DVR que estén cerca geográficamente del servidor de Centro de emisión, permitiendo que se establezca una comunicación más eficaz (descrita con mayor detalle más adelante).
A los DVR se les proporciona un servidor de Centro de emisión local estimado para que contacten en un principio una vez que se resuelva la designación. Esta información se proporciona a un DVR cuando está en el proceso de configuración de inicio en el momento en que el usuario enciende la unidad por primera vez después de comprarla o cuando el usuario inicia el proceso de configuración manualmente. El DVR contacta con el proveedor de servicios del DVR durante el inicio para obtener la última versión del software y determinar otros parámetros de configuración, tales como información de facturación, si el DVR está autorizado para funcionar con un determinado nivel de funciones, etc.
La población de servidores de Centro de emisión puede estar en una ubicación (o en una granja de servidores) o estos pueden estar distribuidos geográficamente e interconectados con una red multidifusión cerrada. Por lo tanto, el flujo de paquetes único de la emisión se abrirá en abanico entre los servidores. Los servidores envían los paquetes por la conexión a los DVR túnel de multidifusión y los DVR túnel de multidifusión reemiten los paquetes a DVR locales.
La delegación de un DVR túnel de multidifusión a un servidor de Centro de emisión particular puede estar basada en la carga del servidor o la ubicación de la red del DVR túnel de multidifusión. La topología de las conexiones de red de diversos DVR puede ser grabada por los servidores de Centro de emisión. Puesto que cada DVR multidifusión se registra en el servidor de Centro de emisión, los servidores crean una topología de red de DVR conectados. La topología puede ser de colaboración, en la cual un servidor central tabula los datos de topología de todos los servidores de Centro de emisión y redistribuye un mapa de topología a todos los servidores de Centro de emisión. A partir de esta topología es posible inferir qué conexiones están «cerca» entre sí en cuanto a saltos de red (que pueden medirse utilizando valores de protocolo de puerta de enlace de frontera (BGP, por su sigla en inglés) o de tiempo de vida (TTL, por su sigla en inglés)) o geográficamente cerca. Con estos datos, es posible para un servidor delegar un DVR túnel de multidifusión a un servidor de Centro de emisión de conexión cercano. Esto puede dar como resultado un uso de ancho de banda mucho mejor y una respuesta mejorada.
5
10
15
20
25
30
35
40
45
50
55
60
Durante el proceso de configuración del túnel, el DVR túnel de multidifusión de conexión puede proporcionar su dirección IP «real» al servidor de Centro de emisión, permitiendo que la topología de los DVR se perfeccione lo suficiente como para «ver» detrás del cortafuegos. Esto permite que la delegación de un túnel sea mucho más focalizada, produciendo de este modo mayor eficacia en la red de emisión en general.
Si un DVR túnel de multidifusión (2703) dejara de funcionar en una red por algún motivo, el protocolo de conexión del sistema ofrece una forma mediante la cual otros DVR (2704-2706) en esa red detectan que el DVR túnel ha fallado, p. ej. enviando o recibiendo pings de manera ocasional desde y hacia el DVR túnel para verificar si sigue funcionando. El primer DVR que detecta que el DVR túnel (2703) está inactivo forzará otra designación. Entonces se designará un nuevo DVR túnel y el nuevo DVR túnel reinicia la tunelización con el servicio mediante el servidor de Centro de emisión.
El servicio de multidifusión proporciona niveles adicionales de fiabilidad mediante transmisiones múltiples de datos importantes en horarios programados. Para garantizar el funcionamiento seguro de la red Mbone, un DVR túnel de multidifusión de conexión puede autenticarse a sí mismo con el servidor de Centro de emisión, utilizando políticas de autenticación descritas más arriba. Durante la delegación, el servidor de Centro de emisión proporcionará un nonce cifrado (una etiqueta de tiempo, valor cifrado, etc.) al DVR.
El nonce se transmite al DVR destino de la delegación, y dicho DVR destino verificará que el nonce es válido (p. ej., el nonce se puede descifrar correctamente con una clave pública del servicio del DVR, el nonce no es «antiguo», etc.). Una vez que se validan, los paquetes multidifusión se pueden retransmitir al DVR túnel.
Se pueden adoptar dos enfoques en cuanto a seguridad dentro de una subred. El primer enfoque es requerir que todos los receptores de multidifusión de una subred compartan un certificado de seguridad del proveedor de servicios del dVr. El segundo enfoque es permitir que cualquier DVR se suscriba a la multidifusión, y asumir que las transmisiones sensibles son cifradas por el servicio. El segundo enfoque normalmente funciona mejor porque disminuye la carga administrativa y de apoyo sin sacrificar seguridad.
La red virtual Mbone de la realización puede ser una forma eficaz para ofrecer la mayor parte de los beneficios de una red global habilitada para multidifusión sin implementar dicha red en realidad. Utilizando la topología de conexiones de túnel, el Centro de emisión puede equilibrar las cargas de manera eficaz para garantizar que ninguna red sufra sobrecargas.
O. EMISOR DE MULTIDIFUSIÓN
El papel del multidifusor funciona, en muchos aspectos, como un emisor multicanal (p. ej., operador de sistema por cable o satelital). En lo que respecta a la figura 28, con suficientes flujos de datos de interés, el emisor de multidifusión (2801) proporciona una multidifusión de flujos de datos «siempre activa» (2803) en Internet (2802). Si los flujos de datos (2803) fueran todos programas de TV, entonces el flujo siempre activo sería análogo a una emisión de red de televisión, con la salvedad de que la velocidad de transmisión no necesita coincidir con la velocidad de datos en tiempo real de los programas de TV. La velocidad de transmisión puede aumentar o disminuir según sea necesario para satisfacer la demanda o para reducir costes.
Los DVR (2804-2807) escuchan flujos de datos multidifusión específicos (2803) en horarios específicos de la misma manera en que se sintoniza un canal de difusión de TV. El contenido de los flujos de datos se almacena en el almacenamiento local del DVR y se ensambla a media que se recibe el flujo. Según la velocidad de transmisión de los flujos de datos multidifusión (2803) (es decir, la velocidad de transmisión es igual a o superior a las velocidades de visualización normales), el DVR puede mostrar el flujo de datos al usuario a medida que recibe el flujo de datos.
El tiempo de respuesta para los flujos de datos se podría mejorar mediante multidifusión de diversos flujos en paralelo, de manera similar a cómo una cabecera de televisión por cable emite múltiples canales. Estos flujos múltiples también pueden representar distintos tipos de flujos de datos. Por ejemplo, un flujo multidifusión podría ser programado de manera periódica con flujos de datos de interés, como una secuencia periódica de programas de noticias o deportes. Otro flujo multidifusión podría ser utilizado para satisfacer peticiones de DVR o usuarios para flujos de datos particulares. Incluso otro podría llevar datos auxiliares, tales como metadatos acerca de qué flujos de datos están disponibles para multidifusión.
El multidifusor también es un agregador de contenido. A través de relaciones contractuales, diversos propietarios de contenido pueden dar acceso a flujos de datos de interés. Se cobra una tarifa a cada propietario de contenido para transmitir dicho contenido. Se puede cobrar una tarifa adicional según la cantidad de descargas. Asimismo, puesto que el DVR puede rastrear lo que un usuario ve, la tarifa se puede basar en la cantidad de veces que un usuario ve el contenido. Toda esta información se recoge en un servidor de facturación central donde el proveedor de servicios
puede calcular las tarifas para cada propietario de contenido y facturar a los propietarios de contenido.
Antes del horario de transmisión programado, el multidifusor podría descargar una copia de un programa en la memoria caché local, transmitir el programa en el horario programado y luego destruir la copia. Como alternativa, el 5 multidifusor podría proporcionar servicios tales como transmitir los datos varias veces para garantizar que todos los DVR posibles reciben los datos.
Utilizando la información cargada de la población de DVR, el multidifusor puede sintonizar o alterar aspectos de los servicios que proporciona. Un programa de TV muy visto podría hacer que el multidifusor dé acceso a otros 10 episodios o que transmita ciertos episodios antes. Los DVR que tienen problemas para recibir los multidifusores pueden indicar esta información al multidifusor, de modo que el multidifusor pudiera trabajar con Proveedores de Acceso a Internet para corregir los problemas de red.
Como un emisor multicanal, el multidifusor normalmente ofrece seguridad en cuanto a contenido y al servicio 15 multidifusión real. Utilizando un mecanismo tal como el esquema de seguridad descrito más arriba, es posible autenticar los DVR para el servicio y viceversa, activar el servicio de control y cifrar contenido correctamente mientras pasa por Internet. Por ejemplo, durante la conexión diaria al servicio multidifusor, las claves de cifrado del día siguiente para cada canal multidifundido de contenido podrían descargarse en un DVR y almacenarse de manera segura, pero únicamente después de la autenticación del DVR y de una determinación de su nivel de 20 servicio.

Claims (10)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    REIVINDICACIONES
    1. Un procedimiento para un sistema multidifusión de distribución de contenidos multimedia que comprende:
    recibir (2902) un horario de transmisión desde un servidor de contenidos (2701) en un videograbador digital (DVR) (2703);
    donde el horario de transmisión indica (2901) horas de transmisión para flujos de datos;
    crear un enlace entre el servidor de contenidos (2701) y el DVR (2703) donde el DVR (2703) se registra (2903, 2904) en el servidor de contenidos (2701) para un flujo de datos específico; y
    recibir (2905, 3005) el flujo de datos específico en el DVR (2703) desde el servidor de contenidos (2701) a un horario programado;
    donde el DVR (2703) es designado (3002) como DVR túnel de multidifusión (2703) por otros DVR (2704, 2705, 2706) conectados a una red local común; y
    donde el DVR túnel de multidifusión (2703) reemite (3006) el flujo de datos específico recibido a otros DVR (2704, 2705, 2706) conectados a la red local común.
  2. 2. Un procedimiento según se describe en la reivindicación 1, donde la velocidad de transmisión del flujo de datos recibido difiere de una velocidad de transmisión requerida para consumo en tiempo real del contenido del flujo de datos recibido.
  3. 3. Un procedimiento según se describe en la reivindicación 1 o la reivindicación 2, donde el enlace creado es un enlace de multidifusión.
  4. 4. Un procedimiento según se describe en la reivindicación 3, donde el flujo de datos específico recibido es un flujo multidifusión que encapsula una pluralidad de flujos multidifusión y, donde reemitir el flujo de datos específico comprende desempaquetar los flujos multidifusión encapsulados y reemitir los flujos multidifusión desempaquetados.
  5. 5. Un procedimiento según se describe en la reivindicación 1 donde los DVR (2704, 2705, 2706) conectados a la red local común se registran en el DVR túnel de multidifusión (2703) para especificar qué flujos de datos quiere recibir (2704, 2705, 2706) el DVRdel DVR túnel de multidifusión (2703).
  6. 6. Un procedimiento según se describe en la reivindicación 5 donde el DVR túnel de multidifusión (2703) transmite el flujo de datos específico recibido a los DVR (2704, 2705, 2706) registrados para recibir el flujo de datos específico.
  7. 7. Un procedimiento según se describe en la reivindicación 1, donde la etapa de recibir el horario de transmisión solicita el horario de transmisión multidifusión del servidor de contenidos (2701).
  8. 8. Un procedimiento según se describe en la reivindicación 1, donde la etapa de recibir el horario de transmisión recibe el horario de transmisión multidifusión enviado desde el servidor de contenidos (2701).
  9. 9. Un procedimiento según se describe en la reivindicación 1, que además comprende:
    cobrarle a un propietario de contenido una tarifa según las velocidades de transmisión de contenido en flujos de datos y/o eventos de visualización de contenido.
  10. 10. Un aparato para un sistema multidifusión de distribución de contenidos multimedia que comprende:
    un módulo para recibir (2902) un horario de transmisión desde un servidor de contenidos (2701) en un videograbador digital (DVR) (2703);
    donde el horario de transmisión indica (2901) horas de transmisión para flujos de datos;
    un módulo para crear un enlace entre el servidor de contenidos (2701) y el DVR (2703) donde el DVR (2703) se registra (2903, 2904) en el servidor de contenidos (2703) para un flujo de datos específico; y
    un módulo para recibir (2905, 3005) el flujo de datos específico en el DVR (2703) desde el servidor de contenidos
    24
    (2701) a un horario programado;
    donde el aparato está adaptado para implementar el procedimiento de cualquiera de las reivindicaciones 1-9.
    5 11. Un medio legible por ordenador que lleva una o más secuencias de instrucciones para un sistema
    multidifusión de distribución de contenidos multimedia, donde la ejecución de una o más secuencias de instrucciones por uno o más procesadores hace que el procesador o procesadores lleve a cabo las etapas del procedimiento de cualquiera de las reivindicaciones 1-9.
ES12167801.5T 2004-04-12 2005-04-12 Sistema multidifusión de distribución de contenidos multimedia Active ES2682243T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US56155804P 2004-04-12 2004-04-12
US561558P 2004-04-12

Publications (1)

Publication Number Publication Date
ES2682243T3 true ES2682243T3 (es) 2018-09-19

Family

ID=35150631

Family Applications (1)

Application Number Title Priority Date Filing Date
ES12167801.5T Active ES2682243T3 (es) 2004-04-12 2005-04-12 Sistema multidifusión de distribución de contenidos multimedia

Country Status (7)

Country Link
EP (2) EP2490369B1 (es)
JP (2) JP5367262B2 (es)
CN (1) CN101427316B (es)
AU (1) AU2005234498B2 (es)
ES (1) ES2682243T3 (es)
HK (1) HK1130361A1 (es)
WO (1) WO2005101411A2 (es)

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8171520B2 (en) 2000-03-02 2012-05-01 Tivo Inc. Method of sharing personal media using a digital recorder
US8261315B2 (en) 2000-03-02 2012-09-04 Tivo Inc. Multicasting multimedia content distribution system
US7181010B2 (en) 2002-05-24 2007-02-20 Scientific-Atlanta, Inc. Apparatus for entitling remote client devices
US7602913B2 (en) 2004-08-18 2009-10-13 Scientific - Atlanta, Inc. Retrieval and transfer of encrypted hard drive content from DVR set-top box utilizing second DVR set-top box
US7630499B2 (en) 2004-08-18 2009-12-08 Scientific-Atlanta, Inc. Retrieval and transfer of encrypted hard drive content from DVR set-top boxes
US7602914B2 (en) 2004-08-18 2009-10-13 Scientific-Atlanta, Inc. Utilization of encrypted hard drive content by one DVR set-top box when recorded by another
US8286218B2 (en) 2006-06-08 2012-10-09 Ajp Enterprises, Llc Systems and methods of customized television programming over the internet
US9277295B2 (en) 2006-06-16 2016-03-01 Cisco Technology, Inc. Securing media content using interchangeable encryption key
US9137480B2 (en) 2006-06-30 2015-09-15 Cisco Technology, Inc. Secure escrow and recovery of media device content keys
US7978720B2 (en) 2006-06-30 2011-07-12 Russ Samuel H Digital media device having media content transfer capability
US8880529B2 (en) 2007-05-15 2014-11-04 Tivo Inc. Hierarchical tags with community-based ratings
US9288548B1 (en) 2007-05-15 2016-03-15 Tivo Inc. Multimedia content search system
US8954042B2 (en) * 2008-05-19 2015-02-10 Qualcomm Incorporated System, method, and apparatus for increasing a likelihood of advertisement display
US8984572B2 (en) * 2009-07-24 2015-03-17 Koninklijke Philips N.V. Method and system for transmitting channels to at least one digital video recorder
US20110070820A1 (en) 2009-09-23 2011-03-24 Qualcomm Incorporated System and apparatus for power-efficiently delivering personalized contents in a broadcast network
US8239890B2 (en) 2009-11-03 2012-08-07 Echostar Technologies Llc Systems and methods for authorizing access to content for a television receiver
US8863192B2 (en) * 2010-01-07 2014-10-14 Qualcomm Incorporated Adaptive monitoring method for update detection in a mobile broadcast network
CN101873459A (zh) * 2010-03-15 2010-10-27 杭州海康威视数字技术股份有限公司 基于级联网络的dvr操作方法、系统及dvr设备
WO2012018300A2 (en) * 2010-08-03 2012-02-09 Poc Sweden Ab Synchronized playback of media files
GB2489672A (en) * 2011-03-28 2012-10-10 Sony Corp Authentication certificate distribution to set top boxes
JP5915107B2 (ja) * 2011-11-15 2016-05-11 株式会社バッファロー 通信方法、通信機器、ストレージ機器、及び制御プログラム
US9510055B2 (en) * 2013-01-23 2016-11-29 Sonos, Inc. System and method for a media experience social interface
WO2015038831A1 (en) * 2013-09-12 2015-03-19 Arris Enterprises, Inc. Persistent household keys for in-home media content distribution
US9979702B2 (en) 2013-09-12 2018-05-22 Arris Enterprises Llc Persistent household keys for in-home media content distribution
US9847975B2 (en) 2013-09-13 2017-12-19 Arris Enterprises Llc Method of provisioning persistent household keys for in-home media content distribution
US20150220498A1 (en) 2014-02-05 2015-08-06 Sonos, Inc. Remote Creation of a Playback Queue for a Future Event
US9679054B2 (en) 2014-03-05 2017-06-13 Sonos, Inc. Webpage media playback
US20150356084A1 (en) 2014-06-05 2015-12-10 Sonos, Inc. Social Queue
US9874997B2 (en) 2014-08-08 2018-01-23 Sonos, Inc. Social playback queues
WO2016049342A1 (en) 2014-09-24 2016-03-31 Sonos, Inc. Social media connection recommendations based on playback information
US9667679B2 (en) 2014-09-24 2017-05-30 Sonos, Inc. Indicating an association between a social-media account and a media playback system
JP2018195039A (ja) * 2017-05-17 2018-12-06 コニカミノルタ株式会社 データ通信システム及びデータ処理装置

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5134705A (en) 1988-10-21 1992-07-28 Unisys Corporation System and method for concurrency simulation
JPH11110401A (ja) * 1997-09-30 1999-04-23 Nippon Telegr & Teleph Corp <Ntt> 放送型配信フィルタリング方法及びシステム及び放送型配信フィルタリングプログラムを格納した記憶媒体
US6351467B1 (en) * 1997-10-27 2002-02-26 Hughes Electronics Corporation System and method for multicasting multimedia content
US6233389B1 (en) 1998-07-30 2001-05-15 Tivo, Inc. Multimedia time warping system
WO2000059214A1 (en) * 1999-03-30 2000-10-05 Tivo, Inc. Multimedia schedule presentation system
US6385739B1 (en) 1999-07-19 2002-05-07 Tivo Inc. Self-test electronic assembly and test system
AUPQ469399A0 (en) * 1999-12-17 2000-01-20 Right Hemisphere Pty Limited Video recorder scheduling
WO2001099370A2 (en) * 2000-06-20 2001-12-27 Nds Limited Unicast/multicast architecture
JP4225681B2 (ja) * 2000-12-06 2009-02-18 富士通株式会社 仮想閉域網構築方法及び装置並びに中継装置
KR20020023100A (ko) * 2001-05-28 2002-03-28 박현제 가상 멀티캐스트 네트워크 구축을 위한 시스템
JP2002369094A (ja) * 2001-06-12 2002-12-20 Matsushita Electric Ind Co Ltd 番組情報取得システム、および取得方法
JP2003087766A (ja) * 2001-09-12 2003-03-20 Pioneer Electronic Corp 加入者端末への視聴情報提供装置
JP3796459B2 (ja) * 2001-11-30 2006-07-12 パナソニック コミュニケーションズ株式会社 情報配信システム及び番組表サーバ並びに配信データ選択表サーバ
US20030158958A1 (en) * 2002-02-20 2003-08-21 Koninklijke Philips Electronics N.V. Distributed storage network architecture using user devices
JP4443833B2 (ja) * 2002-02-27 2010-03-31 パナソニック株式会社 情報再生方法、送信装置および受信装置
JP2003259334A (ja) * 2002-03-05 2003-09-12 Tcj Kk 映像音声番組配信システム
JP3652670B2 (ja) * 2002-05-08 2005-05-25 株式会社エヌ・ティ・ティ・データ マルチキャスト映像配信システム及び同システムにおけるリクエスト受付処理プログラム
JP3708905B2 (ja) * 2002-05-31 2005-10-19 株式会社東芝 放送受信機、放送受信システム及び情報配信方法
JP2004078424A (ja) * 2002-08-13 2004-03-11 Nippon Telegr & Teleph Corp <Ntt> コンテンツ配信システム、コンテンツ配信方法、ホームゲートウェイ及び認証・課金ゲートウェイ
US20040090970A1 (en) * 2002-11-11 2004-05-13 Sanchez Cheryl A. Distribution of data flows to local loop subscribers by an access multiplexer
JP4594923B2 (ja) * 2003-01-16 2010-12-08 ソニー ヨーロッパ リミテッド ビデオ／オーディオネットワーク
US8177602B1 (en) 2007-07-17 2012-05-15 Seka Kaytes Apparatus and method for enhancing a woman's cleavage with floating brassiere cups

Also Published As

Publication number Publication date
EP1738366A4 (en) 2011-11-16
JP2012165397A (ja) 2012-08-30
WO2005101411A2 (en) 2005-10-27
JP5697623B2 (ja) 2015-04-08
CN101427316A (zh) 2009-05-06
EP2490369A3 (en) 2015-10-14
WO2005101411A3 (en) 2009-04-09
AU2005234498A1 (en) 2005-10-27
JP2007536678A (ja) 2007-12-13
CN101427316B (zh) 2013-02-06
EP2490369A2 (en) 2012-08-22
EP1738366A2 (en) 2007-01-03
AU2005234498B2 (en) 2011-08-25
EP2490369B1 (en) 2018-07-18
JP5367262B2 (ja) 2013-12-11
HK1130361A1 (en) 2009-12-24

Similar Documents

Publication Publication Date Title
ES2682243T3 (es) Sistema multidifusión de distribución de contenidos multimedia
US8261315B2 (en) Multicasting multimedia content distribution system
US20190124410A1 (en) Method of sharing personal media using a digital recorder
US9854289B2 (en) Secure multimedia transfer system
JP6290755B2 (ja) ２つのディジタル・メディア装置間でデータを転送する方法
US9203816B2 (en) Controlling access to copies of media content by a client device
EP2180706B1 (en) Method of sharing personal media using a digital recorder