ES2326949A1 - Procedimiento utilizado por un servidor de streaming para realizar una transmision de un fichero multimedia en una red de datos. - Google Patents

Procedimiento utilizado por un servidor de streaming para realizar una transmision de un fichero multimedia en una red de datos. Download PDF

Info

Publication number
ES2326949A1
ES2326949A1 ES200800783A ES200800783A ES2326949A1 ES 2326949 A1 ES2326949 A1 ES 2326949A1 ES 200800783 A ES200800783 A ES 200800783A ES 200800783 A ES200800783 A ES 200800783A ES 2326949 A1 ES2326949 A1 ES 2326949A1
Authority
ES
Spain
Prior art keywords
file
multimedia
server
content
advertising
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.)
Granted
Application number
ES200800783A
Other languages
English (en)
Other versions
ES2326949B1 (es
Inventor
Alvaro Fernandez Gutierrez
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.)
Clarity Systems SL
Original Assignee
Clarity Systems SL
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 Clarity Systems SL filed Critical Clarity Systems SL
Priority to ES200800783A priority Critical patent/ES2326949B1/es
Priority to US12/203,142 priority patent/US7565429B1/en
Priority to PCT/ES2009/070064 priority patent/WO2009115631A1/es
Priority to US12/431,743 priority patent/US7809790B2/en
Priority to US12/431,737 priority patent/US7962548B2/en
Priority to US12/431,553 priority patent/US8185625B2/en
Priority to US12/431,563 priority patent/US8028064B2/en
Priority to US12/431,738 priority patent/US8055781B2/en
Publication of ES2326949A1 publication Critical patent/ES2326949A1/es
Priority to US12/623,215 priority patent/US8185626B2/en
Priority to US12/623,138 priority patent/US8255527B2/en
Priority to US12/623,189 priority patent/US7966411B2/en
Priority to US12/702,168 priority patent/US7984097B2/en
Application granted granted Critical
Publication of ES2326949B1 publication Critical patent/ES2326949B1/es
Priority to US13/157,175 priority patent/US8090774B2/en
Priority to US13/250,041 priority patent/US9270764B2/en
Priority to US13/592,237 priority patent/US8676885B2/en
Priority to US14/185,261 priority patent/US9324097B2/en
Priority to US15/083,966 priority patent/US9955198B2/en
Withdrawn - After Issue 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
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • 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/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2387—Stream processing in response to a playback request from an end-user, e.g. for trick-play
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0241—Advertisements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0241—Advertisements
    • G06Q30/0272—Period of advertisement exposure
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0241—Advertisements
    • G06Q30/0277—Online advertisement
    • H04L29/06517—
    • 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/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • 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/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/53—Network services using third party service providers
    • 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/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • 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/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6581—Reference data, e.g. a movie identifier for ordering a movie or a product identifier in a home shopping application
    • 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/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
    • 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/812—Monomedia components thereof involving advertisement data

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Signal Processing (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Game Theory and Decision Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Procedimiento utilizado por un servidor de streaming para transmitir un fichero multimedia que incluye al menos una parte de contenido y una parte de publicidad, caracterizado porque dicho fichero multimedia tiene un orden de transmisión para transmitir sus diferentes partes y dicho servidor de streaming sólo envía los paquetes con la información multimedia correspondiente a un rango de reproducción de una parte del contenido si previamente dicho servidor de streaming ha transmitido todos los paquetes que transmiten todas las partes de publicidad que preceden a dicho rango de contenido en dicho orden de transmisión.

Description

Procedimiento utilizado por un servidor de streaming para realizar una transmisión de un fichero multimedia en una red de datos.
Campo de la invención
La invención pertenece al campo de la transmisión de ficheros multimedia en redes de datos.
Más concretamente, la invención se refiere a un procedimiento utilizado por un servidor de streaming para transmitir un fichero multimedia que incluye al menos una parte de contenido y una parte de publicidad caracterizado porque dicho fichero multimedia tiene un orden de transmisión en el cual al menos una parte de publicidad precede a una parte de contenido. Cuando dicho servidor de streaming recibe mediante un protocolo de streaming, como por ejemplo RTSP, un mensaje PLAY que le indica un rango de reproducción dicho servidor de streaming, sólo envía los paquetes de datos con la información multimedia correspondiente a dicho rango de reproducción si previamente dicho servidor de streaming ha transmitido todos los paquetes de datos que transmiten toda la publicidad que precede a dicho rango de reproducción.
La invención se refiere asimismo a un equipo servidor de streaming que utiliza dicho procedimiento.
Estado de la técnica
La tendencia que ofrece el mercado actualmente para reproducir contenido audiovisual con derechos de propiedad intelectual, como por ejemplo películas o música, está dirigida a desarrollar una serie de tecnologías de gestión de derechos digitales o DRM ("Digital Rights Management") de forma que los usuarios paguen por la visión de los contenidos de mayor interés sin recibir publicidad en dichos contenidos. En este principio se basan el denominado VOD ("Video On Demand"), las tiendas virtuales que venden contenido en Internet y también las televisiones IP de pago o PPP ("Pay_Per_View") en las cuales se paga para ver un determinado contenido.
Los productores y distribuidores de contenido que utilizan este principio de pago por contenido se han visto seriamente perjudicados con la creación de las de redes P2P ("Peer-to-Peer"), que permiten el intercambio de archivos con contenido de forma gratuita sin que el usuario que ve el contenido pague ningún precio. Existen actualmente numerosas redes P2P, como por ejemplo eMule, Ares Galaxy o Bittorrent, que han alcanzado un nivel de difusión muy alto. Las transmisiones P2P son sistemas que aprovechan el ancho de banda de subida que tiene cada usuario que recibe un fichero para compartir el fichero. Gracias a este ancho de banda de subida, cada usuario que recibe unos datos de un fichero envía a otros usuarios esos mismos datos. De esta forma se crea una red de usuarios que intercambian entre sí los datos constitutivos del fichero, en lugar de que cada usuario descargue íntegramente el fichero desde un sitio proveedor.
Los propietarios de los derechos de propiedad intelectual de los ficheros que se distribuyen en las redes P2P han iniciado numerosas acciones legales en diferentes países con la intención de cerrar dichas redes P2P. Para evitar el cierre de los servidores que gestionan las redes P2P por parte de la policía u otros organismos oficiales o judiciales, las redes P2P han evolucionado de dos formas: por un camino tecnológico y por un camino legal.
Desde un punto de vista tecnológico, han aparecido redes P2P "puras" en las cuales no existen servidores que puedan ser cerrados mediante una actuación judicial o policial. Estas nuevas redes usan nuevas tecnologías, como por ejemplo las tablas DHT ("Distributed Hash Tables"), que permiten a las redes funcionar sin ningún servidor, con lo cual no hay un único punto central donde la policía puede detener el funcionamiento de la red. Para detener una red P2P pura hay que paralizar todos sus nodos o gran parte de ellos, lo que dificulta en gran medida la efectividad de las acciones legales dirigidas a cerrar estas redes.
Desde el punto de vista legal, han aparecido nuevas redes P2P como BitTorrent, cuyos servidores no contienen ningún fichero con derechos de propiedad intelectual, si no que sólo contienen unos ficheros, denominados ficheros "bittorrent", con una información de los puntos de la red P2P desde los cuales se pueden descargar partes de un fichero con derechos de propiedad intelectual, y es discutible que el suministro de un simple fichero "bittorrent" sea ilegal.
La discusión sobre la legalidad de las redes P2P debe tener en cuenta, además, los usos legales de dichas redes, como la descarga de ficheros cuyos propietarios han consentido la descarga: versiones demostrativas de software, software de código abierto, contenido bajo la licencia Creative Commons y otros. Por estos motivos, la situación legal actual de las redes P2P no está muy clara y además varía en función de los países.
Frente a los sistemas de pago por contenido, que como se ha explicado se ha visto gravemente perjudicado por la reciente aparición de las tecnologías P2P, existe la televisión convencional que emite en abierto y en la cual los usuarios no tienen que pagar por ver el contenido. La televisión convencional aplica un sistema de publicidad en que el canal de televisión ofrece a los anunciantes un espacio reservado en sus emisiones para la inserción de anuncios, y el coste de cada anuncio es función de la duración del mismo y de la audiencia prevista para el momento en que será emitido. Por otra parte, las previsiones relativas al tipo de audiencia, es decir al perfil del espectador previsto, permiten ajustar el tipo de anuncio para cada canal y horario. Este mismo sistema de publicidad se utiliza actualmente en la televisión digital por cable, con la diferencia de que, al disponer de un gran número de canales temáticos, es posible prever con mayor precisión el perfil del espectador típico de cada canal.
La amplia difusión de la red Internet y la irrupción de las redes P2P no han afectado de forma significativa a este sistema de publicidad de la televisión convencional, que sigue funcionando sin padecer las caídas de ingresos que están afectando a la venta de música y películas en los formatos CD y DVD. Parece pues que existe un comportamiento social bastante extendido y aceptado que consiste en ver canales de televisión comerciales que intercalan publicidad en sus contenidos para financiar las emisiones, y que este modelo tiene mayor aceptación social por parte de los usuarios que el sistema de pago por contenido.
Presenta un gran interés aplicar al campo de las descargas por Internet los principios del sistema de publicidad de la televisión convencional, es decir que un usuario acceda a un contenido audiovisual a cambio de ver una publicidad.
Una tecnología muy extendida en internet para reproducir vídeos es la tecnología de streaming, que permite al usuario empezar a ver el contenido mientras lo descarga sin necesidad de esperar a descargar el fichero completo con todo el contenido para empezar a visionar el contenido.
Existen en la actualidad varios sistemas que permiten la inserción de publicidad en un contenido que se emite por Internet mediante streaming. Las patentes US7152091 y US7203758 describen sistemas que permiten visualizar contenido insertando publicidad. Sin embargo, en la actualidad ninguno de dichos sistemas se utiliza de forma generalizada por las limitaciones que presentan.
El protocolo de streaming estándar es el protocolo RTSP ("Real Time Streaming Protocol"), que está descrito en las especificaciones RFC 2326 editadas en línea por la IETF (H. Schulzrine et al., Internet Engineering Task Force, Network Working Group, Request for Comments 2326, abril de 1998; actualmente disponibles en la dirección Internet http://www.ietf.org/rfc/rfc2326.txt).
El funcionamiento del protocolo RTSP está muy relacionado con otros dos protocolos de la IETF (Internet Engineering Task Force): los protocolos SDP y RTP.
El protocolo SDP ("Session Descrition Protocol") está descrito en las especificaciones RFC 4566 editadas en línea por la IETF. (M. Handley et al., Request For Comments 4566, Network Working Group, julio de 2006, actualmente disponibles en la dirección de internet http://www.ietf.org/rfc/rfc4566.txt).
El protocolo RTP ("Real-time Transport Protocol") está descrito en las especificaciones RFC 3550 editadas en línea por la IETF (H. Schultzrinne et al., Request For Comment 3550, Network Working Group, julio de 2003, actualmente disponibles en la dirección de Internet http://www.ietf.org/rfc/rfc3550.txt).
Actualmente hay un nuevo borrador del protocolo RTSP denominado RTSP 2.0. Está descrito en el documento editado en línea por la IETF "Real Time Streaming Protocol 2.0 (RTSP) draft-ietf-mmusic-rfc2326bis-16.txt", H. Schulzrinne et al., MMUSIC Working Group, 19 de noviembre de 2007, actualmente disponible en la dirección de Internet http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-16.txt). Dado que este documento sólo es un borrador, en adelante nos referiremos a este documento como DRAFT16.
Otro protocolo relacionado con el RTSP es el protocolo HTTP ("Hypertext Transfer Protocol") descrito en las especificaciones RFC 2616 editadas en línea por la IETF (R. Fielding et al., Request For Comments 2616, Network Working Group, junio de 1999, actualmente disponible en la dirección de Internet http://www.w3.org/Protocols/rfc2616/ rfc2616.html.
El protocolo RTSP es un protocolo cliente-servidor basado en mensajes de texto, diseñado para facilitar la comunicación entre un cliente y un servidor de streaming de forma que el cliente controla la transmisión de streaming del servidor utilizando el protocolo RTSP como si fuera un mando a distancia del servidor. El cliente puede ser cualquier equipo que pueda reproducir un stream multimedia, como por ejemplo un ordenador, una PDA, un teléfono móvil y en general cualquier equipo que incorpore un reproductor de audio o de vídeo.
RTSP permite establecer y controlar uno o varios "streams" o flujos de datos desde el servidor de streaming hacia el reproductor multimedia. Utilizaremos el término inglés "stream" para referirnos a cada uno estos flujos de datos.
El protocolo RTSP es el protocolo que utiliza el reproductor multimedia para comunicar al servidor de streaming el contenido que desea recibir mediante mensajes RTSP. El servidor de streaming también envía al reproductor multimedia mensajes RTSP con información sobre el contenido elegido y la forma en que lo va a transmitir al reproductor multimedia.
El protocolo RTSP utiliza el termino "presentación" para referirse a un conjunto de streams que se presentan al cliente de forma conjunta y que están definidos en un fichero de presentación denominado "Presentation Description" o "Presentation Description File". Otros protocolos utilizan nombres distintos para referirse a una presentación. Por ejemplo el protocolo SDP utiliza el término "sesión" para referirse a una presentación.
Dicho fichero de presentación contiene información sobre cada stream que incluye, por ejemplo, información sobre si es un stream de audio o de vídeo, el tipo de codificación utilizado, direcciones de Internet necesarias para acceder a cada stream, etc.
El fichero de presentación puede utilizar varios formatos para describir esta información. El protocolo SDP suele ser el más utilizado, sin embargo no es necesario utilizar el protocolo SDP y el protocolo RTSP puede describir dicha información utilizando otros protocolos distintos del SDP.
Un fichero de una presentación normalmente se identifica mediante una URI ("Uniform Resource Identifier"). Por ejemplo la siguiente URI podría utilizarse para identificar el fichero de una presentación:
rtsp://media.example.com:554/twister/audiotrack
El cliente puede acceder al fichero de una presentación utilizando el protocolo RTSP u otros protocolos distintos, como por ejemplo el protocolo HTTP (Hypertext Transfer Protocol). El cliente también puede recibir el fichero que describe la presentación por correo electrónico o por cualquier otro medio.
RTSP utiliza el término "container file" para referirse a un fichero multimedia que contiene los datos de uno o varios streams y que normalmente forman una presentación cuando se reproducen conjuntamente. Por ejemplo un container file puede contener tres streams: un primer stream de vídeo de una película, un segundo stream del audio de la película en el idioma inglés y un tercer stream con el audio en el idioma castellano.
RTSP utiliza el término "RTSP session", o sesión RTSP en castellano, para definir una abstracción (por ejemplo un módulo de software ejecutándose en el servidor de streaming) que utiliza el servidor de streaming para controlar cada presentación que envía a cada usuario. Cada sesión RTSP es creada, mantenida y eliminada por el servidor. Normalmente un cliente solicita crear una sesión enviando el comando SETUP del protocolo RTSP al servidor y recibe del servidor una respuesta RTSP denominada mensaje RESPONSE con un identificador de la sesión
creada.
Las sesiones RTSP mantienen información del estado de cada presentación solicitada por cada usuario. Esto es una diferencia importante con respecto al protocolo HTTP que es un protocolo que no mantiene el estado de las peticiones del cliente.
Otra diferencia importante es que en el protocolo RTSP el servidor puede enviar mensajes RSTP con comandos al cliente además de recibirlos. La siguiente tabla 1 extraída de la RFC 2326 indica los diferentes comandos, mensajes o métodos en terminología RTSP, que pueden enviarse entre el cliente y el servidor.
\vskip1.000000\baselineskip
1 
\vskip1.000000\baselineskip
El servidor RTSP puede enviar los paquetes de datos de cada stream al cliente utilizando el protocolo RTP, pero RTSP no depende del protocolo RTP y podría utilizar otros protocolos de transporte.
Sumario de la invención
La invención tiene como finalidad principal proporcionar un sistema mejorado para transmitir publicidad mezclada con contenidos en una red de datos, como por ejemplo Internet.
Preferentemente, dichos anuncios asociados son incorporados a dicho fichero digital antes de que se realice la descarga del mismo.
Con este fin, se ha desarrollado un procedimiento utilizado en una red de datos (150) por un servidor de streaming (100) para transmitir un fichero multimedia (210) que incluye al menos una parte de contenido (212) y una parte de publicidad (211), caracterizado porque:
-
dicho fichero multimedia (210) tiene un orden de transmisión para transmitir las partes con publicidad (211) y las partes con contenido (212), y;
-
al menos una parte de publicidad (211) precede a una parte de contenido (212), y;
-
dicho servidor de streaming (100) recibe, mediante el protocolo RTSP, un primer mensaje PLAY para iniciar la transmisión de dicho fichero multimedia (210), y;
-
dicho servidor de streaming (100) inicia dicha transmisión utilizando el protocolo RTP y enviando la información del fichero multimedia en paquetes RTP, y;
-
dicho servidor de streaming (100) recibe, mediante dicho protocolo RTSP, un segundo mensaje PLAY que indica un nuevo rango de reproducción distinto del primer mensaje PLAY, y;
-
dicho servidor de streaming (100), sólo envía los paquetes RTP con la información multimedia correspondiente a dicho nuevo rango de reproducción del segundo mensaje PLAY si previamente dicho servidor de streaming ha transmitido todos los paquetes RTP que transmiten la toda la publicidad que precede a dicho rango de contenido en dicho orden de transmisión del fichero multimedia.
Preferentemente, dicho fichero multimedia (210) que incluye partes con publicidad (211) y partes con contenido (212) se genera en el propio servidor de streaming a partir de ficheros que contienen contenido y ficheros que contienen publicidad.
En una forma de realización preferida, dicho fichero que se genera en el propio servidor de streaming en un fichero virtual.
La invención contempla un procedimiento utilizado en una red de datos (150) por un servidor de streaming (100) para transmitir ficheros multimedia (210) caracterizado porque:
-
dicho servidor de streaming crea una sesión RTSP para transmitir un primer fichero multimedia, (420) y;
-
dicho servidor de streaming inicia la transmisión de dicho primer fichero multimedia (420) utilizando dicha sesión RTSP, y;
-
dicho servidor de streaming utiliza dicha sesión RTSP para transmitir un segundo fichero multimedia (440).
La invención también contempla un procedimiento utilizado en una red de datos (150) por un servidor (100) para transmitir a un equipo (102) un fichero multimedia (210) que incluye al menos una parte de contenido (212) y una parte de publicidad (211), caracterizado porque:
-
dicho fichero multimedia (210) tiene un orden normal de transmisión para transmitir las partes con publicidad (211) y las partes con contenido (212), y;
-
al menos una parte de publicidad (211) precede a una parte de contenido (212) en dicho orden normal de transmisión de dicho fichero multimedia (210), y;
-
dicho equipo (102) dispone de la capacidad de solicitar al servidor que le transmita determinadas partes de dicho fichero multimedia (210) en un orden distinto a dicho orden normal de transmisión, y;
-
dicho equipo (102) envía un mensaje a dicho servidor (100) solicitando al servidor que transmita una determinada parte (212) de dicho fichero multimedia, y;
-
dicho servidor (100), sólo envía los paquetes de datos con la información multimedia correspondiente a dicha determinada parte solicitada (212) si previamente dicho servidor ha transmitido todos los paquetes que transmiten toda la publicidad que precede a dicha determinada parte (212) en dicho orden de transmisión del fichero multimedia.
Preferentemente dicho equipo dispone de la capacidad de solicitar al servidor la transmisión de determinadas partes de dicho fichero multimedia (210) en un orden distinto a dicho orden normal de transmisión, caracterizado porque:
-
dicho equipo tiene dicha capacidad de solicitar al servidor que le transmita determinadas partes de dicho fichero multimedia (210) en un orden distinto a dicho orden normal de transmisión porque no hay ningún sistema instalado en dicho equipo (102) que impida a dicho equipo (102) enviar dicha solicitud.
Breve descripción de los dibujos
Otras ventajas y características de la invención se aprecian a partir de la siguiente descripción en la que, sin ningún carácter limitativo, se relatan unas formas preferentes de realización de la invención haciendo mención de los dibujos que se acompañan.
La Figura 1 muestra un servidor de streaming en comunicación con un equipo que dispone de un reproductor multimedia.
La Figura 2 muestra unos ficheros multimedia que tienen partes con contenido y partes con publicidad.
La Figura 3 muestra un fichero multimedia y un fichero virtual y sirve para explicar como la presente invención realiza lo que denominamos un "salto RTSP" virtual.
La Figura 4 muestra un fichero multimedia y dos ficheros virtuales que se utilizan en la presente invención para solucionar determinados problemas que aparecen en el "salto RTSP virtual".
La Figura 5 muestra una versión mejorada de fichero virtual utilizable por la presente invención.
La Figura 6 muestra otro fichero virtual que permite al reproductor multimedia realizar un salto hacia atrás.
La Figura 7 muestra otro fichero virtual que tiene un funcionamiento distinto a los anteriores.
La Figura 8 muestra un diagrama de flujo que ilustra una de las comprobaciones que realiza la presente invención.
Descripción detallada de unas formas de realización de la invención
La presente invención permite insertar publicidad en un contenido que un servidor de streaming transmite a un reproductor multimedia sin permitir que el reproductor multimedia salte la publicidad y sin instalar ningún software en el equipo del reproductor multimedia.
Un primer problema que soluciona la presente invención es evitar que el usuario se salte la publicidad de la emisión de streaming y vaya directamente a ver el contenido. Los reproductores multimedia permiten elegir la parte del contenido que quieren reproducir y esto permite a los usuarios saltarse la publicidad. Para que los anunciantes estén dispuestos a pagar un precio razonable por su publicidad es conveniente que un usuario no pueda saltarse la publicidad que le permite ver un contenido.
Un segundo problema es que el sistema que evita que el reproductor multimedia salte la publicidad necesite un módulo de hardware especial o necesite instalar un módulo de software especial en el aparato reproductor que recibe el contenido mediante streaming.
Estos sistemas, que son viables técnicamente, son inviables comercialmente por el rechazo que pueden tener los usuarios a instalar dicho módulo y por el gran número de diferentes sistemas operativos, diferentes reproductores y diferentes tipos de aparatos, como por ejemplo ordenadores, PDAs y teléfonos móviles, utilizados por los usuarios para reproducir el contenido. El protocolo de streaming RTSP es un estándar que permite a los usuarios de un reproductor multimedia moverse libremente por la parte del fichero multimedia que desea ver. Pero no existe ningún estándar para evitar que los usuarios salten la publicidad de un fichero multimedia que se emite mediante streaming.
Además dichos sistemas basados en instalar un módulo en el cliente son vulnerables porque dicho módulo puede ser manipulado para evitar mostrar la publicidad de forma similar a como los sistemas DRM son "hackeados" o inutilizados para mostrar libremente el contenido que protegen. Por lo tanto un segundo problema que debe solucionar la presente invención es que su funcionamiento no requiera descargar o instalar ningún software ni hardware especial en el aparato reproductor que recibe la publicidad y el contenido.
Un tercer problema es el tipo de protocolo de streaming utilizado. La presente invención puede utilizar el protocolo RTSP, o un protocolo de streaming propietario, como por ejemplo los protocolos MMS ("Microsoft Media Server") de Microsoft o el protocolo RTMP ("Real Time Messaging Protocol") de Adobe Systems.
Generalizar en internet el uso de un protocolo propietario es una tarea difícil ya que hay una tendencia a la estandarización de los protocolos. Sólo grandes empresas que han desarrollado un protocolo propietario que ha tenido un gran éxito comercial antes de que se desarrolle un estándar consiguen imponer sus protocolos propietarios. Y esta tarea es cada vez más difícil porque los procesos de estandarización se han acelerado en los últimos años y se han creado numerosos grupos de trabajo para estandarizar protocolos. Además de la ya mencionada IETF hay numerosos nuevos grupos de estandarización: 3GPP, 3GPP2, etc.
Un ejemplo de dicha dificultad de imponer protocolos propietarios y la tendencia a utilizar protocolos estandarizados es que la empresa Microsoft ha dejado de soportar su propio protocolo de streaming propietario MMS en la versión 11 del reproductor "Windows Media Player" y en el servidor de streaming "Windows Media Services 2008" en favor del protocolo estándar RTSP desarrollado por la IETF.
El protocolo RTMP de la empresa Adobe dispone en la actualidad de una gran difusión porque utiliza una tecnología denominada "flash" y su uso está muy extendido en navegadores de Internet utilizados por ordenadores. No sucede lo mismo con los teléfonos móviles o reproductores multimedia como el iPOD de Apple, que normalmente no soportan este protocolo de streaming propietario.
Un sistema de inserción de publicidad en contenido emitido mediante streaming puede diseñar un protocolo de streaming propietario y basar su funcionamiento en dicho protocolo de streaming propietario. Podría basar su funcionamiento en definir, por ejemplo, un nuevo comando del protocolo RTSP especialmente diseñado para insertar publicidad. Esto es técnicamente viable pero comercialmente poco viable. Por este motivo, la presente invención funciona con los protocolos de streaming existentes y ampliamente utilizados en la actualidad, que en lo sucesivo denominaremos protocolos de streaming estándar.
La presente invención evita que el reproductor multimedia salte la publicidad sin instalar ningún software ni hardware propietario en el equipo reproductor del usuario y utilizando un protocolo de streaming estándar. De esta forma, la presente invención funciona correctamente en todos los dispositivos reproductores que utilizan los protocolos de streaming estándar. Esto facilita la viabilidad de la presente invención y su uso en Internet ya que cualquier usuario podrá usar su reproductor estándar para elegir un contenido y visualizarlo a cambio de ver una publicidad, sin necesidad de instalar ningún software en su equipo.
Para solucionar estos problemas utilizando un protocolo de streaming estándar y sin necesidad de instalar ningún módulo de software especial en el equipo del reproductor multimedia, la presente invención se ejecuta en un servidor de streaming modificado que denominaremos servidor de streaming mejorado.
A continuación, sin ningún carácter limitativo, se explica el funcionamiento de dicho servidor de streaming mejorado basando la explicación en los protocolos RTSP y RTP. Pero otros protocolos, como por ejemplo el protocolo RTMP antes mencionado también pueden ser utilizados por el servidor de streaming mejorado de la presente invención.
Dichos protocolos RTSP y RTP están diseñados para que el usuario pueda ir sin restricciones a la parte de contenido que desea ver. En el apartado 3.1 del documento DRAFT16 se especifica que no se debe limitar el comportamiento de los usuarios para obligarles a ver una parte de un fichero multimedia. Sin embargo, la presente invención combina los protocolos RTSP y RTP de una forma no prevista en sus especificaciones para evitar que un reproductor multimedia pueda saltar la publicidad.
La figura 1 muestra como se comunica un reproductor multimedia 101 de un equipo 102 con un servidor de streaming mejorado 100 que utiliza los protocolos RTSP y RTP. El equipo 102 puede ser un ordenador personal, una PDA, un teléfono móvil o cualquier otro equipo que pueda disponer de un reproductor multimedia 101.
El servidor de streaming mejorado 100 dispone de un módulo RTSP 105 y un módulo RTP 106 que se ejecutan en una aplicación 109 que realiza las funciones de servidor de streaming mejorado en el servidor 100. Dichos módulo RTSP 105 y RTP 106 se encargan de las comunicaciones RTSP y RTP con el reproductor multimedia respectivamente. Ambos módulos funcionan de forma coordinada en el servidor de streaming y se comunican entre sí. Dicha comunicación entre los módulos se ha representado por la línea 107.
El servidor de streaming mejorado también dispone de una base de datos o medio de almacenamiento 108 donde almacena ficheros multimedia, por ejemplo ficheros con audio y/o vídeo. El servidor de streaming mejorado puede combinar diversos ficheros multimedia para generar nuevos ficheros multimedia. Por ejemplo puede combinar ficheros de publicidad con ficheros de contenido para generar un fichero multimedia que contenga publicidad y contenido.
En la figura 1 se muestra la comunicación RTSP entre el reproductor multimedia y el modulo RTSP 105 del servidor de streaming 100 mediante la línea 103. Mediante dicha comunicación el reproductor multimedia y el servidor de streaming intercambian mensajes en el protocolo RTSP.
La comunicación RTP se muestra mediante la línea 104 y sirve para que el servidor de streaming envíe paquetes RTP al reproductor multimedia y también para que el servidor de streaming y el reproductor multimedia intercambien unos paquetes de control en un protocolo denominado RTCP que forma parte del protocolo RTP.
Las comunicaciones representadas por las líneas 103 y 104 pueden utilizar una red de datos 150, como por ejemplo la red Internet.
Aunque en la figura 1 se muestran las dos comunicaciones RTSP y RTP mediante dos líneas, ambas comunicaciones pueden también funcionar compartiendo una misma conexión TCP/IP. Otra alternativa habitual es que el protocolo RTP utilice dos conexiones TCP/IP distintas: una primera conexión para los paquetes RTP y una segunda conexión para los paquetes RTCP. Para simplificar la figura se ha utilizado una línea para las comunicaciones RTSP y otra línea para las comunicaciones RTP y RTCP.
La figura 2 muestra un ejemplo de un fichero multimedia 210 que puede incluir uno o varios streams, por ejemplo audio y/o vídeo. En dicho fichero multimedia hay una primera parte de publicidad 211 seguida de una segunda parte con contenido 212. Un usuario puede indicar a su reproductor multimedia que salte la publicidad 211. Dicho salto se ha representado mediante la línea 213. Un fichero multimedia puede ser, por ejemplo, el "container file" de una película.
La figura 2 también muestra un ejemplo 220 de un fichero multimedia en el que hay tres partes de publicidad 221,223 y 255 y tres partes de contenido 222, 224 y 226. Igualmente, el usuario de un reproductor multimedia puede saltarse la publicidad, por ejemplo el salto indicado con la línea 227.
La figura 3 ilustra un primer modo de funcionamiento de la presente invención que evita que el reproductor multimedia salte la publicidad de una transmisión de un fichero multimedia 310 que es transmitido por el servidor de streaming mejorado. Para simplificar la explicación, la figura 3 muestra un fichero 310 que contiene unas partes con publicidad 311 y 312 antes de una única parte con contenido 313.
El fichero 310 puede ser por ejemplo, un fichero multimedia o "container file" almacenado en la base de datos 108 del servidor de streaming mejorado.
Dicho fichero multimedia 310 contiene varios streams de audio y de vídeo que no se muestran para simplificar la figura. El fichero multimedia 310 tiene un orden de transmisión para transmitir primero las partes con publicidad 311 y 312 y después la parte con contenido 313.
El servidor de streaming recibe, mediante el protocolo RTSP, un mensaje SETUP para preparar dicha transmisión multimedia. Al recibir dicho mensaje el servidor de streaming crea una sesión RTSP y envía un mensaje de respuesta al reproductor multimedia, denominado mensaje RESPONSE, que incluye toda la información necesaria para que el reproductor multimedia pueda enviar mensajes RTSP que utilicen dicha sesión RTSP recién creada.
Y a continuación recibe un primer mensaje PLAY para iniciar la transmisión del contenido del fichero 310 desde su inicio indicado con la flecha 314.
Al recibir dicho primer mensaje PLAY en el protocolo RTSP, el servidor de streaming inicia una transmisión multimedia del fichero 310 hacia el reproductor multimedia utilizando el protocolo RTP y enviando la información multimedia en paquetes RTP a través de la comunicación RTP antes explicada.
Cuando el servidor de streaming ha transmitido un primera parte del fichero 310, por ejemplo la parte 311 con publicidad, el servidor de streaming recibe, mediante el protocolo RTSP, un segundo mensaje PLAY con un nuevo rango de reproducción que le solicita que continúe reproduciendo a partir del punto indicado con la flecha 316 de la figura 3.
Esto significa que el reproductor multimedia desea saltar la parte de publicidad 312 para empezar a ver la parte de contenido 313. Un servidor de streaming normal realizaría dicho salto, representado por la línea 319 y empezaría a reproducir el contenido 313 sin emitir la publicidad 312.
Sin embargo el servidor de streaming mejorado de la presente invención realiza lo que denominaremos un "salto RTSP virtual" y continúa transmitiendo la información 312 del fichero multimedia. Para ello el servidor de streaming mejorado envía un mensaje de respuesta RTSP del tipo "RESPONSE, 200, OK" al reproductor multimedia indicándole que procesa su orden de reproducir a partir del punto 316, pero en realidad continúa transmitiendo paquetes RTP cuyo contenido se corresponde con la parte 312 y no con la parte 313.
El servidor de streaming mejorado crea un fichero virtual, representado en la figura 3 por el elemento 330, a partir del fichero 310 y del salto solicitado 319. En dicho fichero virtual la publicidad 312 y el contenido 313 se han desplazado respecto al orden normal del fichero 310. Dicho desplazamiento se indica en la figura 3 mediante las líneas discontinuas 321, 322 y 323. La partes 312 y 313 del fichero 310 se corresponden con las partes 332 y 333 respectivamente del fichero virtual 330.
El fichero virtual 330 puede ser, por ejemplo, un fichero que se crea y se almacena en una base de datos o un medio de almacenamiento del servidor de streaming. Sin embargo, esta solución requiere un tiempo de proceso en el servidor de streaming para crear el fichero virtual 330.
Para evitar este problema de tiempo de proceso, el fichero virtual 330 puede ser preferentemente un objeto, por ejemplo un componente programado en el lenguaje C++, que se ejecuta en la aplicación servidor de streaming mejorado y que lee la información del fichero 310 y la transmite a los módulos RTSP y RTP del servidor de streaming como si fuera el fichero 330 para que de esta forma no sea necesario crear el fichero 330. En este caso, el fichero 330 no es un fichero almacenado sino que es un "fichero virtual" al que se accede por medio de dicho componente que se ejecuta en el servidor de streaming mejorado.
Cuando el servidor de streaming recibe el segundo mensaje PLAY que le indica reproducir el rango a partir del punto indicado con la flecha 316, el servidor de streaming mejorado transmite dicho rango pero correspondiente al fichero virtual 330, con lo que en realidad no salta la publicidad 312 y continua transmitiendo la publicidad 332 como si no hubiera recibido el segundo mensaje PLAY que le indica saltar la publicidad.
Un aspecto importante de la presente invención es que el servidor de streaming mejorado transmite el fichero virtual 330 utilizando la misma sesión RTSP que estaba utilizando para transmitir el fichero multimedia antes del salto RTSP virtual.
De esta forma, el servidor de streaming mejorado pasa de muestrear el fichero normal 310 a muestrear el fichero virtual 330 sin modificar los parámetros de la transmisión de streaming. Por ejemplo, mantiene los valores de los campos "Pipelined-Request", "Session", y "ssrc" del protocolo RTSP, así como los relojes utilizados para calcular el valor timestamp de los paquetes RTP y el "reloj de pared" utilizado para los campos "NTP timestamp" de los paquetes de control de tipo "SR" del protocolo RTCP.
A continuación se explica como utiliza el servidor de streaming los protocolos RTSP y RTP para realizar el salto virtual explicado en la figura 3. El servidor de streaming mejorado de la presente invención se aprovecha para ello de algunas características de los protocolos RTP y RTSP que se describen a continuación.
Para realizar este "salto RTSP virtual", el servidor de streaming mejorado coordina el funcionamiento de los módulos RTSP y RTP del servidor de streaming utilizando unas cabeceras de los mensajes RTSP denominadas "Range" y "RTP-Info" que son las que permiten al reproductor multimedia saber a que parte del fichero corresponde la información de cada paquete RTP que recibe.
Para mayor claridad, se explica a continuación brevemente el significado de algunos campos que se encuentran en los paquetes RTP y que son utilizados en la presente invención. La información detallada del protocolo RTP está en las especificaciones RFC 3550 antes mencionadas.
El campo "Payload" al final del paquete RTP es el que incluye el contenido del stream. Por ejemplo puede incluir audio muestreado o vídeo muestreado.
El campo "Sequence number" o "número de secuencia" de los paquetes de datos RTP es un número entero de 16 bits que se incrementa en una unidad cada vez que se transmite un paquete RTP de un stream. Se utiliza principalmente para que el receptor de los paquetes RTP pueda identificar paquetes de datos perdidos y pueda ordenar los paquetes RTP que llegan al receptor en un orden distinto del orden con que han sido enviados.
El campo "synchronization source (SSRC) identifier" es un campo de 32 bits que sirve como identificador único de cada stream RTP que envía cada fuente de datos, en este caso, cada stream que envía el servidor de streaming. Si en una transmisión multimedia, un servidor envía varios streams, por ejemplo de audio y vídeo, cada stream tiene su propio identificador SSRC.
El campo "Timestamp" es un número entero de 32 bits que indica el instante en que se ha realizado el muestreo del primer byte de los datos de contenido del paquete RTP, es decir, cuando se ha muestreado el primer byte del Payload. Cada stream de una misma sesión RTSP que se transmite mediante paquetes RTP utiliza su propio "reloj RTP" para calcular dicho instante en que se ha realizado el muestreo de dicho primer byte. El reloj RTP de cada stream es un reloj que aumenta de forma lineal y constante. Cuando el reloj alcanza su valor máximo (los 32 bits con el valor 1) vuelve a empezar de cero. Por motivos de seguridad, el valor inicial del campo timestamp se elige de forma aleatoria. Los valores timestamp de diferentes streams de un mismo fichero multimedia que se transmite utilizando el protocolo RTP pueden aumentar a diferentes velocidades y tomar diferentes valores iniciales.
De esta forma se genera una línea de tiempo para cada stream que transmite el servidor. Por ejemplo, si un usuario está reproduciendo un contenido que tiene varios streams y para su reproducción durante 20 segundos (por ejemplo enviando un comando PAUSE en el protocolo RTSP y esperando 20 segundos para enviar un comando PLAY), los relojes RTP de cada stream que el modulo RTP del servidor de streaming utiliza para calcular el timestamp siguen avanzando de forma regular durante estos 20 segundos. Cuando el usuario vuelve a reproducir el contenido, el valor del campo timestamp del los nuevos paquetes RTP que envíe el servidor de streaming se habrá incrementado y mostrará el valor de dichos relojes en el instante en que se realiza el muestreo del primer byte del contenido de cada nuevo paquete RTP que se envía.
Este requerimiento de que el reloj utilizado para calcular el timestamp se incremente de forma regular no implica necesariamente que el orden en el cual los datos son muestreados sea el mismo orden en el que los datos son enviados. Un ejemplo es la compresión de vídeo MPEG, que transmite los frames de vídeo en un orden distinto del orden de muestreo. Por este motivo el receptor debe utilizar el campo timestamp y no el campo "Sequence number" para determinar el orden en que debe reproducir el contenido.
En los muestreos de audio normalmente se utiliza un reloj que tiene la misma velocidad de incremento que la frecuencia de muestreo. Es decir, el reloj asociado a una sesión RTP de audio se incrementa en una unidad cada vez que se muestrea el audio.
Por ejemplo, con una frecuencia de muestreo de audio de 16000 muestras por segundo (16 Khz), si cada paquete RTP contiene 20 mseg. de audio, cada paquete RTP consecutivo incrementa el campo timestamp en 320 unidades. (0,02 segundos x 16000 muestras/segundo) si no hay pausas entre paquetes consecutivos.
Los muestreos de vídeo normalmente utilizan una frecuencia de 90 kHz.
Los reproductores multimedia utilizan el campo timestamp de los paquetes RTP para calcular a qué momento de la reproducción pertenece cada parte de contenido que es enviado en cada paquete RTP. El valor timestamp de los paquetes RTP permite también al reproductor multimedia sincronizar diferentes streams de una misma sesión. Por ejemplo puede sincronizar un stream de audio con un stream de vídeo de forma que si está reproduciendo el instante 20 minutos y 10,4 segundos del vídeo también esté reproduciendo el instante 20 minutos y 10,4 segundos del audio.
La presente invención aprovecha que la continuidad del campo timestamp de los paquetes RTP implica que los servidores de streaming no pueden basarse en los datos de timestamp almacenados en los ficheros que contienen el contenido multimedia, sino que el campo timestamp de los paquetes RTP debe generarse en el servidor de streaming en tiempo real, teniendo en cuenta los comandos RTSP que envía el usuario al servidor. El campo timestamp de los paquetes RTP no se corresponde con un índice que indica una parte del fichero multimedia sino con un reloj que funciona en el servidor de streaming y que aumenta de forma lineal y constante y que no se para aunque el usuario envíe un mensaje RTSP de tipo PAUSE. Aprovechando esta característica, el servidor de streaming mejorado utiliza los protocolos RTSP y RTP para transmitir el fichero virtual 330 en lugar del fichero normal 310 cuando hay un salto de publicidad.
El servidor de streaming mejorado coordina el módulo RTSP y el módulo RTP para realizar el "salto RTSP virtual" y "engañar" al reproductor multimedia 301 enviando el fichero virtual 330 en lugar de realizar el salto 319 solicitado y enviar el contenido 313 del fichero 310. Para ello el servidor de streaming mejorado modifica la relación normal entre el Parámetro NPT ("Normal Play Time") de los mensajes RTSP y el campo timestamp de los paquetes RTP.
El reproductor multimedia no puede calcular a qué parte de un contenido se corresponde el contenido de cada paquete RTP únicamente con el campo timestamp de los paquetes RTP. Para hacer este cálculo, el reproductor multimedia necesita una referencia inicial que relacione un instante concreto en la reproducción del fichero multimedia con los valores que tienen en ese instante concreto cada uno de los relojes utilizado para generar los valores RTP timestamp de cada uno de los streams que forman el fichero multimedia. Por ejemplo, el reproductor multimedia necesita saber que el instante 3,25 segundos de la reproducción de un fichero multimedia, se corresponde con un valor RTP timestamp =12345678 del stream de audio y un valor RTP timestamp = 29567112 del stream vídeo.
Con esta información de referencia inicial el reproductor multimedia ya puede calcular a qué instante de la reproducción corresponde cada paquete RTP de audio y de vídeo que recibe en función del valor RTP timestamp de cada paquete y de dicha referencia inicial. Además esta información de referencia inicial permite al reproductor multimedia sincronizar el audio y el vídeo.
Los servidores de streaming que utilizan los protocolos RTSP y RTP, envían al reproductor multimedia esta información que relaciona un instante en la reproducción de un fichero multimedia con los valores RTP timestamp de cada stream utilizando dos cabeceras de los mensajes RTSP denominadas "Range" y "RTP-Info". Dichas cabeceras se incluyen en los mensajes RESPONSE que envían al reproductor multimedia en respuesta a los mensajes PLAY que envía el reproductor multimedia al servidor de streaming.
El campo de cabecera "Range" de un mensaje RTSP indica el rango de tiempo de reproducción y en dicho rango incluye un instante inicial que se utiliza como referencia inicial.
La cabecera Range puede codificar su información de varias formas. Una de ellas es utilizando un parámetro denominado NPT ("Normal Play Time") que indica la posición absoluta del stream relativa al inicio de la presentación. El parámetro NPT consiste en una fracción decimal. La parte izquierda de la fracción decimal pueden ser segundos ó horas, minutos y segundos. La parte derecha son fracciones de segundo. Por ejemplo "Range:npt=3,25-15" indica que se está reproduciendo una parte de contenido empezando en el instante 3,25 segundos y terminado en el instante 15 segundos de un fichero multimedia que puede contener varios streams. El parámetro NPT se explica en detalle en el apartado 3.6 de la RFC 2326.
Instintivamente, el NPT es el reloj que el usuario que utiliza el reproductor multimedia asocia con dicho contenido. El parámetro NPT ("Normal Play Time") se explica en el apartado 3.6 de la RFC 2326. Esta información, normalmente se muestra en los reproductores multimedia de forma digital. El reproductor "Media Player" de la empresa Microsoft muestra dicha información en forma de minutos y segundos en su esquina inferior derecha. Por ejemplo, puede indicar "39:50" para que el usuario sepa que está viendo el contenido correspondiente al minuto 39 y cincuenta segundos desde el inicio de una película de vídeo.
La cabecera Range también puede utilizar alternativamente otros parámetros para codificar su información, como por ejemplo el parámetro SMPTE, explicado en el apartado 3.5 de la RFC 2326, pero para mayor sencillez en la presente explicación se utilizará únicamente el parámetro NPT.
El campo de cabecera "RTP-Info" de un mensaje RTSP incluye la información relacionada con los paquetes RTP de cada stream que transmite utilizando cuatro campos denominados "url", "ssrc", "seq" y "rtptime".
El campo denominado "rtptime" de la cabecera RPT-Info es el valor del campo timestamp del paquete RTP cuyo contenido ("payload") se corresponde con el inicio del rango del fichero multimedia indicado en la cabecera Range. Esta información es la referencia inicial que necesita el reproductor multimedia para asociar cada paquete RTP de cada stream con un instante concreto del fichero multimedia.
De esta forma, gracias a la información conjunta de las cabeceras Range y RTP-Info que se incluyen en el mensaje RTSP de tipo RESPONSE que envía el servidor de streaming al reproductor multimedia en respuesta al mensaje PLAY, el reproductor multimedia puede relacionar los valores NPT y timestamp y puede determinar a qué parte del contenido del fichero 310 pertenece el contenido de cada paquete RTP.
Cuando el servidor de streaming mejorado recibe el segundo mensaje PLAY que le solicita transmitir el contenido del fichero 310 a partir del punto 316, el servidor de streaming mejorado responde con un mensaje RESPONSE que tiene un valor de la cabecera Range que indica un rango inicial en el punto 336 y con un valor de la cabecera RTP-Info que indica el valor del campo timestamp del los paquetes RTP que enviará el servidor con el contenido correspondientes a dicho rango solicitado.
El reproductor multimedia recibe el mensaje RESPONSE con dichos valores Range y RTP-Info. De esta forma el reproductor multimedia asocia el valor del parámetro NPT de la cabecera Range en el instante indicado por la flecha 336 con los valores del parámetro rtptime de cada stream y cuando el reproductor multimedia realiza el cálculo de a qué parte del fichero corresponde cada paquete RTP que recibe a continuación, el reproductor multimedia utiliza como referencia inicial dicho valor NPT correspondiente al instante de reproducción del fichero indicado con la flecha 316. De esta forma el reproductor multimedia indica al usuario que los paquetes RTP que va a recibir a continuación se corresponden con la parte de contenido 313.
Sin embargo el servidor de streaming mejorado envía los paquetes RTP que contienen la información correspondiente al fichero virtual 330 y no al fichero original 310. En el fichero virtual 330, la parte del fichero correspondiente a un rango que empieza en la flecha 336, es la parte 332 que es la misma publicidad de la parte 312 del fichero 310 que el reproductor multimedia intenta saltar. De esta forma el servidor de streaming mejorado "engaña" al reproductor multimedia y evita que salte la publicidad 312, ya que continúa enviando paquetes RTP que transmiten la parte 332 del fichero virtual que se corresponde con la publicidad 312 del fichero 310.
De esta forma, aprovechando que la continuidad del campo timestamp de los paquetes RTP implica que los servidores de streaming no pueden basarse en los datos de timestamps almacenados en los ficheros que contienen el contenido multimedia, sino que el campo timestamp de los paquetes RTP debe generarse en el servidor de streaming en tiempo real, teniendo en cuenta los comandos RTSP que envía el usuario al servidor, el servidor de streaming mejorado puede realizar el "salto RTSP virtual" y transmitir el fichero virtual 330 en lugar del fichero original 310 sin que el reproductor multimedia detecte el salto virtual.
Otra utilidad de la relación entre los valores de las cabeceras "Range" y "RTP-Info" es permitir también la sincronización inicial de los diferentes streams, de forma que el reproductor multimedia pueda establecer una relación inicial entre el parámetro NPT y los timestamp de los paquetes RTP de cada stream.
Sin embargo, en una transmisión se puede perder la sincronización entre diferentes streams, por ejemplo entre el stream de audio y el stream de vídeo.
Por este motivo, los servidores de streaming estándar también utilizan el protocolo RTCP (Real Time Control Protocol) para evitar y compensar desviaciones en la sincronización que se producen en una transmisión multimedia larga que contenga varios streams.
RTCP es un protocolo de control que forma parte del protocolo RTP y está explicado en la misma RFC 3550 que el protocolo RTP.
Para evitar desviaciones en la sincronización de diferentes streams, por ejemplo en streams de audio y vídeo, los servidores de streaming envían de forma regular al reproductor multimedia unos mensajes denominados "SR" utilizando el protocolo RTCP.
Dichos mensajes SR utilizan tres campos para mantener sincronizados diferentes streams de una misma presentación. Los campos se denominan "SSRC", "NTP timestamp" "RTP timestamp".
El campo SSRC identifica un stream de una presentación.
El campo RTP timestamp es el campo timestamp de los paquetes RTP que se ha explicado anteriormente, es decir es el valor del reloj RTP asociado a cada stream cuando el servidor de streaming inicia el muestreo de la parte de contenido que se envía en cada paquete RTP.
El campo "NTP timestamp" (No confundir NTP o "Network Time Protocol" con NPT o "Normal Play Time") es un reloj de referencia que es común a los diferentes streams que envía el servidor de streaming en una misma presentación. También se denomina "Wallclock" o "reloj de pared". Este reloj es común para los diferentes streams de una presentación y es el que permite al reproductor multimedia mantener la sincronización de los diferentes streams en trasmisiones largas.
Enviando estos tres valores en los mensajes SR, el servidor de streaming indica al reproductor multimedia, la correspondencia entre el valor del reloj de pared ("NTP timestamp" o "wallclock") y los valores "RTP timestamp" del reloj utilizado para calcular el valor RTP timestamp de los paquetes RTP de cada stream.
El valor del campo "RTP timestamp" de un mensaje SR en el protocolo RTCP de un determinado stream se corresponde con el valor del reloj RTP asociado a dicho stream en el momento indicado en el valor "NTP timestamp". De esta forma, el servidor de streaming mejorado permite también mantener la sincronización de diferentes streams en una transmisión larga.
En el servidor de streaming mejorado de la presente invención, los valores de dichos campos de los mensajes SR del protocolo RTCP y de los paquetes RTP se calculan a partir del fichero virtual 330 en lugar del fichero normal 310. Es decir, el valor del campo "RTP timestamp" de un paquete RTP de un determinado stream se corresponde con el valor del reloj RTP asociado a dicho stream en el momento del inicio del muestreo de la parte del fichero virtual 330 que se envía en dicho paquete RTP. Para ello se aprovechan de la misma característica antes explicada de que los servidores de streaming necesitan calcular los valores de los campos timestamp en tiempo real y no pueden utilizar valores almacenados en los ficheros multimedia.
Esta solución mostrada en la figura 3 tiene sin embargo dos problemas.
Un primer problema es que el área 335 del fichero virtual 330 no se corresponde con ninguna parte del fichero original 310. Esto es un problema porque el reproductor multimedia puede enviar un mensaje PLAY al servidor para que reproduzca dicha parte 335.
Un segundo problema es que el fichero virtual 330 es más largo que el fichero original 310 y la transmisión multimedia puede terminar antes de que el usuario termine de ver el contenido. Esta longitud adicional está representada por el área 334 en la figura 3. Esto es un problema porque la transmisión multimedia puede terminar antes de que el usuario termine de ver el contenido. Esto sucede, por ejemplo, si en el protocolo RTSP se utilizan determinadas cabeceras que indican la duración del fichero multimedia.
La figura 4 muestra como el servidor de streaming mejorado soluciona estos dos problemas. Para ello, el servidor de streaming mejorado crea un primer fichero virtual 420 a partir del fichero multimedia 410 que se corresponde con el fichero multimedia 310 explicado en la figura 3.
Cuando el servidor de streaming mejorado recibe los mensajes SETUP y PLAY para reproducir el contenido de un fichero multimedia 410, empieza la transmisión utilizando desde el principio un fichero virtual 420 que incluye un área de publicidad no obligatoria 426 y varios mensajes 427, 428 y 429.
La parte de publicidad no obligatoria 426 puede ser, por ejemplo, publicidad sobre nuevas películas.
Al aumentar la longitud del fichero virtual e incluir un nuevo contenido que se puede reproducir en la zona del "salto virtual" 335, se solucionan los dos problemas antes explicados.
Si un reproductor multimedia envía un segundo mensaje PLAY cuyo rango de reproducción se inicia en 426, el servidor de streaming mejorado crea un nuevo fichero virtual 440 realiza un "salto virtual" como el explicado en la figura 3. El salto RTSP virtual del fichero 420 al fichero 440 está indicado con las líneas discontinuas 431, 432, 433, 434, 435, 436 y 437. Una vez creado el fichero virtual 440, el servidor de streaming mejorado empieza a transmitir partes del nuevo fichero virtual 440 utilizando la misma sesión RTSP que estaba utilizando para enviar el fichero 420.
De esta forma, al aumentar desde el inicio el tamaño del fichero virtual que se va a transmitir 420 se evita el problema de que la transmisión termine sin reproducir el área 334 de la figura 3.
En el fichero virtual 440, el área 445 se corresponde con una parte de la publicidad no obligatoria 426. Dicha correspondencia se indica en la figura 4 con la flecha en línea discontinua 438. De esta forma si el usuario envía un tercer mensaje PLAY que inicia el rango de reproducción en el área 445, el servidor puede transmitir la publicidad no obligatoria 426, por ejemplo anuncios de películas. De esta forma se evita el otro problema explicado en la figura 3.
La figuras 5, 6 y 7 muestran variaciones de la misma invención que utilizan diferentes configuraciones de ficheros virtuales.
La figura 5 presenta una pequeña mejora sobre la figura 4 que consiste que cuando el usuario envía el segundo mensaje PLAY con inicio de reproducción en 526, el servidor de streaming crea un nuevo fichero virtual 540 que transmite en primer lugar un mensaje multimedia 547 antes de continuar transmitiendo la publicidad obligatoria 542 y el contenido 543. El mensaje multimedia puede indicar al usuario, por ejemplo, que va a ver un contenido financiado con publicidad y que no puede saltarse la publicidad. Opcionalmente el servidor de streaming puede terminar la transmisión multimedia si el reproductor multimedia vuelve a enviar otro mensaje PLAY para volver a saltarse la publicidad.
La figura 6 muestra otra forma de funcionamiento de la presente invención en la cual un reproductor multimedia que está recibiendo un fichero multimedia 620 envía un segundo mensaje PLAY con rango inicial en en el punto indicado con la flecha 626 para saltar la parte 622 con publicidad. El servidor de streaming mejorado crea un nuevo fichero virtual 640 que trasmite un mensaje multimedia 648, que por ejemplo tiene una duración de 10 segundos y avisa al usuario que debe retroceder para volver a ver la publicidad antes de 10 segundos.
Si el reproductor multimedia envía un mensaje PLAY de retroceso antes de los 10 segundos volviendo a un punto de la reproducción anterior al punto 625 que el servidor de streaming estaba transmitiendo cuando el usuario ha realizado el salto, entonces el servidor de streaming vuelve a utilizar el fichero virtual 620 y continua la transmisión de publicidad 622. En la figura 6 dicho mensaje PLAY que retrocede se indica mediante la línea 649.
Si el reproductor multimedia no envía un mensaje PLAY de retroceso antes de los diez segundos que dura el mensaje 648, entonces el servidor de streaming mejorado continúa transmitiendo el mensaje 648 y termina la transmisión del fichero multimedia.
La figura 7 muestra otro fichero virtual que al igual que la figura 6 transmite un mensaje 748 al reproductor multimedia. A diferencia de la figura 6, en la figura 7, el servidor de streaming no espera ningún mensaje PLAY de retroceso, simplemente transmite el mensaje 748 y termina la transmisión. Dicho mensaje 748 puede, por ejemplo, avisar al usuario que ha realizado un salto de la publicidad no autorizado y que va a terminar la transmisión.
Para evitar que el reproductor multimedia reproduzca el contenido sin haber reproducido antes la publicidad, la presente invención debe resolver también otro problema relacionado con el protocolo RTSP: el avance rápido.
En el protocolo RTSP el avance rápido funciona de la siguiente forma: cuando el servidor de streaming está transmitiendo a una velocidad que es el doble de la normal, los paquetes RTP sólo envían una de cada dos imágenes de vídeo al reproductor multimedia. Si la velocidad es el cuádruple de la normal el servidor envía sólo una de cada cuatro imágenes y así sucesivamente.
El protocolo RTSP utiliza una cabecera denominada "Scale" o escala que se explica en el apartado 12.34 de la RFC 2326 y cuyo funcionamiento se resume a continuación.
Un valor de 1 en la cabecera Scale indica al servidor de streaming que transmita el contenido a la velocidad normal de reproducción. Si el valor de Scale no es 1, entonces dicho valor indica el ratio respecto a la velocidad normal de reproducción. Una ratio 2 indica al servidor de streaming que transmita a una velocidad el doble de lo normal ("fast forward"). Por ejemplo en una transmisión de vídeo con un ratio 2, el servidor puede transmitir únicamente una de cada dos imágenes.
Un ratio de 0,5 indica al servidor que transmita el contenido a una velocidad que es la mitad de lo normal. Un ratio negativo indica al servidor que debe reproducir el contenido en la dirección inversa, es decir, en la dirección que va desde el final del contenido hacia el inicio del contenido.
Un reproductor multimedia que está reproduciendo un fichero multimedia, por ejemplo el contenido 420 de la figura 4, puede enviar un mensaje PLAY al servidor de streaming con una valor Scale igual a 2 para pasar rápidamente la publicidad.
El servidor de streaming mejorado de la presente invención soluciona este problema considerando que el avance rápido es equivalente a un salto en la publicidad ya que no transmite toda la publicidad (por ejemplo sólo transmite una de cada dos imágenes) y procediendo tal como se ha explicado anteriormente en las figuras 3 a 7.
Tomando como ejemplo, la figura 4, si el reproductor multimedia está reproduciendo el contenido de un fichero 420 y en el punto 425 el reproductor envía un mensaje al servidor para aumentar la velocidad de reproducción, el servidor de streaming transmite dicho contenido a la velocidad solicitada.
Cuando el contenido transmitido llega al punto 426 el reproductor multimedia vuelve a enviar otro mensaje PLAY con un rango de inicio en 426 y una velocidad de reproducción normal para ver el contenido a velocidad normal. Al recibir este segundo mensaje PLAY, el servidor de streaming detecta que no ha transmitido toda la publicidad 422 y lo trata como un salto virtual de la forma anteriormente explicada.
Para ello el servidor de streaming crea un nuevo fichero virtual 440 en el cual ha desplazado el contenido 422 a la zona 442 y vuelve a transmitir la publicidad a una velocidad normal de forma similar a la explicada anteriormente.
Otras combinaciones que utilizan mensajes como las explicadas en las figuras 5, 6 y 7 son también aplicables y permiten gestionar el avance rápido como un salto de diferentes formas utilizando diferentes ficheros virtuales que pueden incluir menajes para el usuario que utiliza el reproductor multimedia.
En una forma mejorada de la presente invención, el servidor de streaming mejorado puede elegir entre diferentes tipos de ficheros virtuales en función del tipo de reproductor multimedia 101 utilizado en el equipo 102. Para detectar el tipo de reproductor multimedia, el servidor de streaming puede utilizar la cabecera denominado "User-Agent" que indica en los mensajes RTSP el reproductor multimedia que los envía. Las especificaciones RFC 2326, en su apartado 12.41 remiten al apartado 14.42 de las especificaciones del protocolo HTTP para explicar el campo "User-Agent".
Aunque el protocolo RTSP es una especificación común, cada reproductor multimedia puede implementarlo de forma particular. Además hay partes del protocolo RTSP que la RFC 2326 considera opcionales. Adaptando su funcionamiento a cada tipo de reproductor multimedia, el servidor de streaming mejorado ofrece el mejor modo de funcionamiento para cada tipo de reproductor. Por ejemplo elegir el modo de funcionamiento de las figuras 4 a 7 en función del tipo de reproductor.
Al adaptar el modo de funcionamiento del servidor de streaming mejorado a cada tipo de reproductor multimedia, el servidor de streaming mejorado también puede detectar que el reproductor multimedia es de un tipo no autorizado que se utiliza para evitar ver publicidad o para usos no autorizados del contenido y evitarlo. Para ello el servidor de streaming mejorado 100 puede almacenar esta información sobre reproductores no autorizados en su base de datos 108.
Un ejemplo de reproductor multimedia no autorizado es una aplicación instalada en el mismo equipo 102 que el reproductor multimedia 101 y que no reproduce el fichero multimedia mientras se descarga sino que se limita a almacenar el contenido del fichero multimedia en el equipo 102 para poder reproducirlo después directamente desde el equipo 102 sin necesidad de conectar con el servidor aprovechando la caché del reproductor multimedia.
Cuando el servidor de streaming mejorado detecta un reproductor no autorizado puede, por ejemplo, enviar un mensaje RESPONSE de error al reproductor multimedia o no procesar el mensaje PLAY y no enviar el mensaje RESPONSE correspondiente o incluso enviar un mensaje RESPONSE como si hubiera procesado el mensaje PLAY pero no tenerlo en cuenta. Otras combinaciones son posibles para impedir que el reproductor multimedia reproduzca una parte de contenido sin reproducir antes su publicidad correspondiente.
También puede suceder que un usuario utilice un reproductor multimedia autorizado de una forma que evita ver la publicidad. Por ejemplo, un usuario puede utilizar un navegador de Internet que incluye un "plug in" que es un reproductor multimedia de uso común pero en lugar de reproducir un fichero multimedia, el usuario utiliza la opción "Save As" de dicho navegador para guardar el fichero multimedia sin reproducirlo mientras se descarga. En este caso el servidor de streaming mejorado puede detectar este uso no autorizado, por ejemplo analizando los mensajes de control RTCP que envía el reproductor multimedia al servidor de streaming y terminar la transmisión si detecta que el reproductor no está reproduciendo el fichero multimedia mientras lo descarga.
En una versión mejorada de la presente invención, el servidor de streaming impide que el reproductor multimedia pueda reproducir varias veces el contenido de un fichero sin volver a ver la publicidad. Para ello el servidor de streaming mejorado debe generar un nuevo fichero virtual, como el fichero virtual 420 de la figura 4, en determinadas circunstancias que se explican a continuación.
El servidor de streaming mejorado tiene en cuenta el tiempo transcurrido desde que ha transmitido la parte de contenido que un usuario desea volver a reproducir. Por ejemplo, un usuario utiliza un reproductor multimedia para ver toda la publicidad antes de ver una película que se transmite desde el servidor de streaming y durante la transmisión de la película el usuario se ausenta unos minutos sin parar la transmisión. Cuando el usuario vuelve a observar el contenido puede desear retroceder unos minutos en el contenido para ver la parte de contenido que no ha visto mientras estaba ausente y sería molesto para el usuario tener que volver a ver publicidad simplemente por haberse ausentado unos minutos.
En otro ejemplo similar, el usuario simplemente quiere volver a ver una escena de la película o volver a escuchar una parte de audio que no ha entendido y sería molesto para el usuario que el servidor de stareming insertara publicidad en estos casos.
Sin embargo si un usuario ha visto una película y desea volver a ver la película unos días o unos meses después, el servidor de streaming sí debería transmitir una nueva publicidad para que el usuario pueda ver otra vez la película. Este funcionamiento es similar a la de las televisiones convencionales, que insertan publicidad cada vez que emiten un contenido aunque sea por segunda vez, y los usuarios están acostumbrados a este funcionamiento y no deberían sentirse molestos.
Para gestionar este funcionamiento mejorado, el servidor de streaming mejorado de la presente invención utiliza las cabeceras "Cache-Control" y "Expires" en los mensajes RTSP que envía al reproductor multimedia, especialmente en el mensaje RESPONSE que envía en respuesta a un mensaje SETUP del reproductor multimedia.
La cabecera "Cache-Control" y su funcionamiento se explican en el apartado 12.8 y 13 de la RFC 2326. La cabecera "Expires" se explica en el apartado 12.19 de la RFC 2326.
La cabecera "Cache-Control" regula el funcionamiento de los diferentes dispositivos de caché que hay entre el servidor de streaming y el reproductor multimedia, incluido la propia caché del reproductor multimedia.
La cabecera "Expires" informa de cuándo caduca un contenido multimedia o un fichero de descripción de un contenido multimedia. Un dispositivo de caché no debe transmitir un contenido caducado, sino que debe contactar con el servidor de streaming para recibir un contenido actualizado.
Mediante el uso de dichas cabeceras el servidor de streaming mejorado puede funcionar de la forma anteriormente explicada y crear o no un nuevo fichero virtual con publicidad en función del tiempo transcurrido desde que transmitió un fichero multimedia.
Por ejemplo, el servidor de streaming puede utilizar el valor "must-revalidate" en la cabecera "Cache-Control" del mensaje RESPONSE que envía al reproductor multimedia en respuesta a un mensaje SETUP. Este valor de la cabecera "Cache-Control" indica a los dispositivos de cache que no deben transmitir un contenido caducado sin primero validarlo con el servidor de streaming. El contenido caduca en el momento indicado en la cabecera "Expires".
De esta forma, la presente invención utiliza la cabecera "Expires" de una forma no prevista en el protocolo RTSP ya que marca como caducado un contenido que en realidad no ha caducado con el objetivo de poder crear un nuevo fichero virtual en el servidor de streaming e insertar una nueva publicidad cuando ha transcurrido un cierto tiempo, por ejemplo 24 horas.
El usuario puede volver a reproducir una escena o un audio si lo desea sin necesidad de recibir una nueva publicidad que podría ser molesta. En cambio si el usuario vuelve a reproducir una película pasados unos días, el contenido habrá caducado en los dispositivos de caché y el reproductor multimedia solicitará una nueva transmisión al servidor de streaming mejorado que puede de esta forma crear un nuevo fichero virtual con publicidad actualizada.
La presente invención también puede utilizar las cabeceras "Cache-Control" y "Expires" de otras formas distintas para conseguir el mismo objetivo. Por ejemplo puede dar el valor "no-cache" a la cabecera "Cache-Control" que indica que la transmisión multimedia no debe almacenarse en ninguna caché. También puede utilizar un sistema de control de caché u otro dependiendo del tipo de reproductor multimedia utilizado.
La figura 8 ilustra el proceso de comprobación que utiliza el servidor de streaming mejorado para comprobar si ha transmitido la publicidad y actuar en consecuencia cuando recibe un mensaje PLAY cuyo rango inicial no coincide con el inicio del fichero multimedia.
El servidor de streaming mejorado recibe en 801 un mensaje RTSP de tipo PLAY que incluye una cabecera Range con un rango inicial y un rango final y cuyo rango inicial no se corresponde con el inicio del fichero multimedia.
El servidor de streaming realiza la comprobación en 802 de si ya ha transmitido paquetes RTP con toda la publicidad del fichero multimedia que se encuentra antes de dicho rango inicial.
Si el servidor de streaming mejorado ha emitido toda la publicidad del fichero multimedia anterior al rango inicial, entonces el servidor de streaming mejorado procesa en 803 el mensaje PLAY de forma normal y transmite el rango de contenido multimedia indicado en el mensaje PLAY. De esta forma, un usuario puede moverse libremente por las partes del fichero cuya publicidad ya ha visto. Por ejemplo, si toda la publicidad está al principio del fichero, esto permite al usuario indicar al reproductor multimedia que avance o retroceda libremente en el fichero multimedia para elegir el contenido que el usuario desea ver, ya que no tiene sentido restringir estas opciones a un usuario que ya ha visto la publicidad que financia el contenido.
En cambio si en la comprobación 802 el servidor de streaming mejorado detecta que no ha transmitido toda la publicidad del fichero multimedia anterior al rango inicial pasa al paso 804 que se encarga de gestionar un mensaje PLAY que incluye un salto de publicidad mediante un fichero virtual que puede utilizar las diferentes opciones que se han explicado anteriormente.
En 805 termina el proceso.

Claims (6)

1. Procedimiento utilizado en una red de datos (150) por un servidor de streaming (100) para transmitir un fichero multimedia (210) que incluye al menos una parte de contenido (212) y una parte de publicidad (211), caracterizado porque:
-
dicho fichero multimedia (210) tiene un orden de transmisión para transmitir las partes con publicidad (211) y las partes con contenido (212), y;
-
al menos una parte de publicidad (211) precede a una parte de contenido (212), y;
-
dicho servidor de streaming (100) recibe, mediante el protocolo RTSP, un primer mensaje PLAY para iniciar la transmisión de dicho fichero multimedia (210), y;
-
dicho servidor de streaming (100) inicia dicha transmisión utilizando el protocolo RTP y enviando la información del fichero multimedia en paquetes RTP, y;
-
dicho servidor de streaming (100) recibe, mediante dicho protocolo RTSP, un segundo mensaje PLAY que indica un nuevo rango de reproducción distinto del primer mensaje PLAY, y;
-
dicho servidor de streaming (100), sólo envía los paquetes RTP con la información multimedia correspondiente a dicho nuevo rango de reproducción del segundo mensaje PLAY si previamente dicho servidor de streaming ha transmitido todos los paquetes RTP que transmiten la toda la publicidad que precede a dicho rango de contenido en dicho orden de transmisión del fichero multimedia.
2. Procedimiento según la reivindicación 1 cuando dicho fichero multimedia (210) que incluye partes con publicidad (211) y partes con contenido (212) se genera en el propio servidor de streaming a partir de ficheros que contienen contenido y ficheros que contienen publicidad.
3. Procedimiento según la reivindicación 2 caracterizado porque dicho fichero que se genera en el propio servidor de streaming es un fichero virtual.
4. Procedimiento utilizado en una red de datos (150) por un servidor de streaming (100) para transmitir ficheros multimedia (210) caracterizado porque:
-
dicho servidor de streaming crea una sesión RTSP para transmitir un primer fichero multimedia, (420) y;
-
dicho servidor de streaming inicia la transmisión de dicho primer fichero multimedia (420) utilizando dicha sesión RTSP, y;
-
dicho servidor de streaming utiliza dicha sesión RTSP para transmitir un segundo fichero multimedia (440).
5. Procedimiento utilizado en una red de datos (150) por un servidor (100) para transmitir a un equipo (102) un fichero multimedia (210) que incluye al menos una parte de contenido (212) y una parte de publicidad (211), caracterizado porque:
-
dicho fichero multimedia (210) tiene un orden normal de transmisión para transmitir las partes con publicidad (211) y las partes con contenido (212), y;
-
al menos una parte de publicidad (211) precede a una parte de contenido (212) en dicho orden normal de transmisión de dicho fichero multimedia (210), y;
-
dicho equipo (102) dispone de la capacidad de solicitar al servidor que le transmita determinadas partes de dicho fichero multimedia (210) en un orden distinto a dicho orden normal de transmisión, y;
-
dicho equipo (102) envía un mensaje a dicho servidor (100) solicitando al servidor que transmita una determinada parte (212) de dicho fichero multimedia, y;
-
dicho servidor (100), sólo envía los paquetes de datos con la información multimedia correspondiente a dicha determinada parte solicitada (212) si previamente dicho servidor ha transmitido todos los paquetes que transmiten toda la publicidad que precede a dicha determinada parte (212) en dicho orden de transmisión del fichero multimedia.
\newpage
6. Procedimiento según la reivindicación 5 cuando dicho equipo dispone de la capacidad de solicitar al servidor la transmisión de determinadas partes de dicho fichero multimedia (210) en un orden distinto a dicho orden normal de transmisión, caracterizado porque:
-
dicho equipo tiene dicha capacidad de solicitar al servidor que le transmita determinadas partes de dicho fichero multimedia (210) en un orden distinto a dicho orden normal de transmisión porque no hay ningún sistema instalado en dicho equipo (102) que impida a dicho equipo (102) enviar dicha solicitud.
ES200800783A 2008-03-18 2008-03-18 Procedimiento utilizado por un servidor de streaming para realizar una transmision de un fichero multimedia en una red de datos. Withdrawn - After Issue ES2326949B1 (es)

Priority Applications (17)

Application Number Priority Date Filing Date Title
ES200800783A ES2326949B1 (es) 2008-03-18 2008-03-18 Procedimiento utilizado por un servidor de streaming para realizar una transmision de un fichero multimedia en una red de datos.
US12/203,142 US7565429B1 (en) 2008-03-18 2008-09-02 Methods for transmitting multimedia files and advertisements
PCT/ES2009/070064 WO2009115631A1 (es) 2008-03-18 2009-03-18 Procedimiento utilizado por un servidor de streaming para realizar una transmisión de un fichero multimedia en una red de datos
US12/431,743 US7809790B2 (en) 2008-03-18 2009-04-28 Methods for transmitting multimedia files and advertisements
US12/431,737 US7962548B2 (en) 2008-03-18 2009-04-28 Methods for transmitting multimedia files and advertisements
US12/431,553 US8185625B2 (en) 2008-03-18 2009-04-28 Methods for transmitting multimedia files and advertisements
US12/431,563 US8028064B2 (en) 2008-03-18 2009-04-28 Methods for transmitting multimedia files and advertisements
US12/431,738 US8055781B2 (en) 2008-03-18 2009-04-28 Methods for transmitting multimedia files and advertisements
US12/623,215 US8185626B2 (en) 2008-03-18 2009-11-20 Methods for transmitting multimedia files and advertisements
US12/623,138 US8255527B2 (en) 2008-03-18 2009-11-20 Methods for transmitting multimedia files and advertisements
US12/623,189 US7966411B2 (en) 2008-03-18 2009-11-20 Methods for transmitting multimedia files and advertisements
US12/702,168 US7984097B2 (en) 2008-03-18 2010-02-08 Methods for transmitting multimedia files and advertisements
US13/157,175 US8090774B2 (en) 2008-03-18 2011-06-09 Methods for transmitting multimedia files and advertisements
US13/250,041 US9270764B2 (en) 2008-03-18 2011-09-30 Methods for transmitting multimedia files and advertisements
US13/592,237 US8676885B2 (en) 2008-03-18 2012-08-22 Methods and transmitting multimedia files and advertisements
US14/185,261 US9324097B2 (en) 2008-03-18 2014-02-20 Methods and apparatus for transmitting multimedia files and advertisements
US15/083,966 US9955198B2 (en) 2008-03-18 2016-03-29 Methods and apparatus for transmitting multimedia files and advertisements

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ES200800783A ES2326949B1 (es) 2008-03-18 2008-03-18 Procedimiento utilizado por un servidor de streaming para realizar una transmision de un fichero multimedia en una red de datos.

Publications (2)

Publication Number Publication Date
ES2326949A1 true ES2326949A1 (es) 2009-10-21
ES2326949B1 ES2326949B1 (es) 2010-07-14

Family

ID=40911086

Family Applications (1)

Application Number Title Priority Date Filing Date
ES200800783A Withdrawn - After Issue ES2326949B1 (es) 2008-03-18 2008-03-18 Procedimiento utilizado por un servidor de streaming para realizar una transmision de un fichero multimedia en una red de datos.

Country Status (3)

Country Link
US (12) US7565429B1 (es)
ES (1) ES2326949B1 (es)
WO (1) WO2009115631A1 (es)

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3737462B2 (ja) * 2002-07-30 2006-01-18 ソニー・エリクソン・モバイルコミュニケーションズ株式会社 情報処理システム、情報通信端末および方法、情報処理装置および方法、記録媒体、並びにプログラム
US20080114695A1 (en) 2006-11-10 2008-05-15 Semantic Components S.L. Process for implementing a method for the on-line sale of software product use licenses through a data network, and software component which allows carrying out said process
US7984097B2 (en) 2008-03-18 2011-07-19 Media Patents, S.L. Methods for transmitting multimedia files and advertisements
ES2326949B1 (es) 2008-03-18 2010-07-14 Clarity Systems, S.L. Procedimiento utilizado por un servidor de streaming para realizar una transmision de un fichero multimedia en una red de datos.
US8325800B2 (en) 2008-05-07 2012-12-04 Microsoft Corporation Encoding streaming media as a high bit rate layer, a low bit rate layer, and one or more intermediate bit rate layers
US8379851B2 (en) 2008-05-12 2013-02-19 Microsoft Corporation Optimized client side rate control and indexed file layout for streaming media
US7860996B2 (en) 2008-05-30 2010-12-28 Microsoft Corporation Media streaming with seamless ad insertion
GB0817805D0 (en) * 2008-09-29 2008-11-05 Symbian Software Ltd Method and system for receicing and displaying unsolicitted content on a device
US8265140B2 (en) 2008-09-30 2012-09-11 Microsoft Corporation Fine-grained client-side control of scalable media delivery
KR101547554B1 (ko) * 2008-11-27 2015-08-26 삼성전자주식회사 디지털 콘텐츠 서비스 제공 방법 및 시스템
US8667552B2 (en) * 2008-12-03 2014-03-04 M/S, Amagi Technologies Private Limited Stream conditioning for seamless switching of addressable content across transport multiplex, using local stored content as pre-roll and post-roll buffers; in digital television receivers
FR2940729A1 (fr) * 2008-12-29 2010-07-02 Thomson Licensing Procede de generation de fichiers multimedia destines a etre transmis par paquets dans un reseau pair-a-pair
US9154532B2 (en) 2009-04-27 2015-10-06 Zaron Remote Llc Methods and apparatus for transmitting multimedia files in a data network
US8707182B2 (en) * 2010-01-20 2014-04-22 Verizon Patent And Licensing Inc. Methods and systems for dynamically inserting an advertisement into a playback of a recorded media content instance
US8625974B1 (en) * 2010-05-22 2014-01-07 Arris Enterprises, Inc. Obscuring advertisements during trick mode operation
CN102143133B (zh) * 2010-08-05 2013-12-18 华为技术有限公司 Http流播放方式中支持广告内容的方法、装置和系统
EP2437440A1 (en) * 2010-10-01 2012-04-04 Koninklijke Philips Electronics N.V. Device and method for delay optimization of end-to-end data packet transmissions in wireless networks
US8825846B2 (en) * 2010-12-10 2014-09-02 Max Goncharov Proactive intellectual property enforcement system
US8819168B2 (en) 2010-12-14 2014-08-26 Microsoft Corporation Link expansion service
US9172982B1 (en) * 2011-06-06 2015-10-27 Vuemix, Inc. Audio selection from a multi-video environment
US8499092B2 (en) 2011-06-23 2013-07-30 Google Inc. Validating download success
ES2418004B1 (es) * 2011-08-08 2014-06-24 Patricia FERN�NDEZ NEDEO Sistema de sonido ambiental, de reproducción independiente de archivos de audio en formato multimedia
US20130073384A1 (en) * 2011-09-21 2013-03-21 Haifeng Qiu System and method for forced delivery of advertisement over Internet media streaming
US9537920B2 (en) * 2012-05-18 2017-01-03 Google Technology Holdings LLC Enforcement of trick-play disablement in adaptive bit rate video content delivery
GB2519020B (en) * 2012-10-26 2021-02-17 Hewlett Packard Entpr Dev Lp Processing streaming data with open executors
US9275398B1 (en) * 2012-12-10 2016-03-01 A9.Com, Inc. Obtaining metrics for client-side display of content
US8832338B2 (en) * 2013-01-08 2014-09-09 Silicon Image, Inc. Mechanism for facilitating dynamic timestamp-less clock generation for transmitting media streams over shared channels
US20140282696A1 (en) * 2013-03-15 2014-09-18 Qualcomm Incorporated Advertising download verification
TWI556638B (zh) * 2013-10-22 2016-11-01 瑞軒科技股份有限公司 多媒體檔案的片頭略過方法與電子裝置
US9654475B2 (en) * 2014-01-10 2017-05-16 Futurewei Technologies, Inc. Client behavior control in adaptive streaming file
US10313213B1 (en) * 2016-11-04 2019-06-04 Google Llc Systems and methods for measuring media performance on end-user devices
US10567819B2 (en) 2017-09-07 2020-02-18 At&T Intellectual Property I, L.P. Method and system for sponsoring data on a network
CN109922318B (zh) * 2019-03-22 2020-02-07 重庆紫光华山智安科技有限公司 一种多路视频传输调度方法、装置、存储介质及电子终端
US11792472B2 (en) * 2019-09-18 2023-10-17 Wayne Fueling Systems Llc Schedule-based uninterrupted buffering and streaming

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030149975A1 (en) * 2002-02-05 2003-08-07 Charles Eldering Targeted advertising in on demand programming
US6990512B1 (en) * 2001-03-19 2006-01-24 Novell, Inc. Method and system for using live time shift technology to control a multimedia file
US20060031892A1 (en) * 2004-08-05 2006-02-09 Bitband Technologies Ltd. Prevention of advertisement skipping
WO2006086717A1 (en) * 2005-02-11 2006-08-17 Vidiator Enterprises Inc. Method of multiple file streaming service through playlist in mobile environment and system thereof
WO2006138432A2 (en) * 2005-06-17 2006-12-28 Lightningcast Llc Presenting advertising content

Family Cites Families (202)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0744641B2 (ja) 1983-06-06 1995-05-15 キヤノン株式会社 画像変倍処理装置
US4866769A (en) 1987-08-05 1989-09-12 Ibm Corporation Hardware assist for protecting PC software
US5247575A (en) * 1988-08-16 1993-09-21 Sprague Peter J Information distribution system
US4953209A (en) 1988-10-31 1990-08-28 International Business Machines Corp. Self-verifying receipt and acceptance system for electronically delivered data objects
JPH04302522A (ja) 1991-03-29 1992-10-26 Hitachi Ltd 演算回路及びこれを用いた適応フィルタ並びにエコーキャンセラ
US5999908A (en) 1992-08-06 1999-12-07 Abelow; Daniel H. Customer-based product design module
US5629980A (en) 1994-11-23 1997-05-13 Xerox Corporation System for controlling the distribution and use of digital works
US7124302B2 (en) 1995-02-13 2006-10-17 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US5671412A (en) * 1995-07-28 1997-09-23 Globetrotter Software, Incorporated License management system for software applications
US5708709A (en) * 1995-12-08 1998-01-13 Sun Microsystems, Inc. System and method for managing try-and-buy usage of application programs
US5794210A (en) 1995-12-11 1998-08-11 Cybergold, Inc. Attention brokerage
US20010011253A1 (en) * 1998-08-04 2001-08-02 Christopher D. Coley Automated system for management of licensed software
US5790664A (en) 1996-02-26 1998-08-04 Network Engineering Software, Inc. Automated system for management of licensed software
US5815665A (en) 1996-04-03 1998-09-29 Microsoft Corporation System and method for providing trusted brokering services over a distributed network
US5864620A (en) 1996-04-24 1999-01-26 Cybersource Corporation Method and system for controlling distribution of software in a multitiered distribution chain
US20030093790A1 (en) 2000-03-28 2003-05-15 Logan James D. Audio and video program recording, editing and playback systems using metadata
US5870559A (en) 1996-10-15 1999-02-09 Mercury Interactive Software system and associated methods for facilitating the analysis and management of web sites
US6144962A (en) * 1996-10-15 2000-11-07 Mercury Interactive Corporation Visualization of web sites and hierarchical data structures
US6073124A (en) * 1997-01-29 2000-06-06 Shopnow.Com Inc. Method and system for securely incorporating electronic information into an online purchasing application
US6009525A (en) 1997-08-29 1999-12-28 Preview Systems, Inc. Multi-tier electronic software distribution
US6078909A (en) 1997-11-19 2000-06-20 International Business Machines Corporation Method and apparatus for licensing computer programs using a DSA signature
DE19752792B4 (de) 1997-11-28 2004-04-15 Phoenix Contact Gmbh & Co. Kg Einrichtung zur Selbstdiagnose von im wesentlichen sporadischen Fehlern in seriellen Übertragungssystemen
JPH11161552A (ja) 1997-11-28 1999-06-18 Fujitsu Ltd 可換記憶媒体のデータ保護方法及び、これを適用した記憶装置
US6189146B1 (en) 1998-03-18 2001-02-13 Microsoft Corporation System and method for software licensing
US7171662B1 (en) 1998-03-18 2007-01-30 Microsoft Corporation System and method for software licensing
US6282653B1 (en) 1998-05-15 2001-08-28 International Business Machines Corporation Royalty collection method and system for use of copyrighted digital materials on the internet
EP1076871A1 (en) 1998-05-15 2001-02-21 Unicast Communications Corporation A technique for implementing browser-initiated network-distributed advertising and for interstitially displaying an advertisement
US6484182B1 (en) 1998-06-12 2002-11-19 International Business Machines Corporation Method and apparatus for publishing part datasheets
US6108703A (en) * 1998-07-14 2000-08-22 Massachusetts Institute Of Technology Global hosting system
US6363356B1 (en) * 1998-07-16 2002-03-26 Preview Software Referrer-based system for try/buy electronic software distribution
US6983371B1 (en) * 1998-10-22 2006-01-03 International Business Machines Corporation Super-distribution of protected digital content
US7110984B1 (en) 1998-08-13 2006-09-19 International Business Machines Corporation Updating usage conditions in lieu of download digital rights management protected content
US6226618B1 (en) 1998-08-13 2001-05-01 International Business Machines Corporation Electronic content delivery system
US6389403B1 (en) * 1998-08-13 2002-05-14 International Business Machines Corporation Method and apparatus for uniquely identifying a customer purchase in an electronic distribution system
US6871220B1 (en) * 1998-10-28 2005-03-22 Yodlee, Inc. System and method for distributed storage and retrieval of personal information
US6434535B1 (en) * 1998-11-13 2002-08-13 Iomega Corporation System for prepayment of electronic content using removable media and for prevention of unauthorized copying of same
US6981217B1 (en) 1998-12-08 2005-12-27 Inceptor, Inc. System and method of obfuscating data
EP1141811A2 (en) * 1998-12-08 2001-10-10 Mediadna, Inc. A system and method of obfuscating data
US6760916B2 (en) * 2000-01-14 2004-07-06 Parkervision, Inc. Method, system and computer program product for producing and distributing enhanced media downstreams
US6434536B1 (en) * 1998-12-23 2002-08-13 Timothy S. Geiger Methods and systems for commerce
US6247130B1 (en) 1999-01-22 2001-06-12 Bernhard Fritsch Distribution of musical products by a web site vendor over the internet
US7024393B1 (en) 1999-03-27 2006-04-04 Microsoft Corporation Structural of digital rights management (DRM) system
US7103574B1 (en) 1999-03-27 2006-09-05 Microsoft Corporation Enforcement architecture and method for digital rights management
US7051005B1 (en) * 1999-03-27 2006-05-23 Microsoft Corporation Method for obtaining a black box for performing decryption and encryption functions in a digital rights management (DRM) system
US6389432B1 (en) 1999-04-05 2002-05-14 Auspex Systems, Inc. Intelligent virtual volume access
DE69940400D1 (de) 1999-06-29 2009-03-26 Sony Deutschland Gmbh Rundfunkempfänger für Vielfach-Übertragungssystem
WO2001001286A2 (en) * 1999-06-30 2001-01-04 Accenture Llp A system, method and article of manufacture for an internet based distribution architecture
EP1067719A1 (en) * 1999-07-05 2001-01-10 Sony International (Europe) GmbH Method to verify that an identical service is transmitted on an alternative frequency to the currently received frequency
WO2001022261A2 (en) 1999-09-21 2001-03-29 Kim Peter H I Method and apparatus for delivery of targeted advertising and content based on user interaction with online queries on a wide area network
US6697944B1 (en) 1999-10-01 2004-02-24 Microsoft Corporation Digital content distribution, transmission and protection system and method, and portable device for use therewith
JP2001156044A (ja) * 1999-11-26 2001-06-08 Tokyo Electron Ltd 処理装置及び処理方法
US7213005B2 (en) 1999-12-09 2007-05-01 International Business Machines Corporation Digital content distribution using web broadcasting services
US6772340B1 (en) 2000-01-14 2004-08-03 Microsoft Corporation Digital rights management system operating on computing device and having black box tied to computing device
US6505169B1 (en) 2000-01-26 2003-01-07 At&T Corp. Method for adaptive ad insertion in streaming multimedia content
JP2001229283A (ja) 2000-02-16 2001-08-24 Internatl Business Mach Corp <Ibm> ネットワークシステム、オークションサーバ、デジタルコンテンツ配布システム及びデジタルコンテンツ配布方法
US6766064B1 (en) * 2000-03-10 2004-07-20 General Electric Company Method and apparatus for performing a contrast based dynamic range management algorithm
US7054443B1 (en) 2000-03-27 2006-05-30 Microsoft Corporation System and method for protecting digital goods using random and automatic code obfuscation
US7155415B2 (en) 2000-04-07 2006-12-26 Movielink Llc Secure digital content licensing system and method
AU2001257320A1 (en) * 2000-04-28 2001-11-12 Live365, Inc. System and method for reducing the resources required to deliver streaming media
US7076468B2 (en) 2000-04-28 2006-07-11 Hillegass James C Method and system for licensing digital works
US6452903B1 (en) * 2000-05-31 2002-09-17 Fujitsu Network Communications, Inc. Network switch supporting rate-based and credit-based flow control mechanisms on a link-by-link basis
WO2001092993A2 (en) 2000-06-02 2001-12-06 Vigilant Systems, Inc. System and method for licensing management
JP4360750B2 (ja) 2000-06-16 2009-11-11 ヤマハ株式会社 コンテンツ配信システム及び同配信システムに利用される配信サーバ。
WO2002003604A2 (en) 2000-06-29 2002-01-10 Cachestream Corporation Digital rights management
US6535871B1 (en) * 2000-07-24 2003-03-18 Pitney Bowes Inc. Method for searching a digital rights management package
JP4810752B2 (ja) 2000-08-04 2011-11-09 ソニー株式会社 データ記録媒体、データ記録方法及び装置、データ再生方法及び装置、データ送信方法及び装置、並びに、データ受信方法及び装置
JP4552294B2 (ja) 2000-08-31 2010-09-29 ソニー株式会社 コンテンツ配信システム、コンテンツ配信方法、および情報処理装置、並びにプログラム提供媒体
US7149722B1 (en) 2000-09-28 2006-12-12 Microsoft Corporation Retail transactions involving distributed and super-distributed digital content in a digital rights management (DRM) system
AU2002237748A1 (en) 2000-10-19 2002-05-21 Loudeye Technologies, Inc. System and method for selective insertion of content into streaming media
EP1548541A3 (en) 2000-10-24 2006-04-12 Seiko Epson Corporation System and method for digital content distribution
US20020091584A1 (en) * 2000-10-25 2002-07-11 Clark George Philip Electronic content distribution
US6704733B2 (en) 2000-10-25 2004-03-09 Lightning Source, Inc. Distributing electronic books over a computer network
US7069271B1 (en) * 2000-11-03 2006-06-27 Oracle International Corp. Methods and apparatus for implementing internet storefronts to provide integrated functions
US7574486B1 (en) 2000-11-06 2009-08-11 Telecommunication Systems, Inc. Web page content translator
WO2002043301A2 (en) * 2000-11-17 2002-05-30 Starguide Digital Networks, Inc. Method and apparatus for injection of ip multicast content into an atm dsl network
JP2002170046A (ja) 2000-12-01 2002-06-14 Hitachi Ltd 電子メールを利用した広告システム、方法および前記方法を実現するプログラムを格納した記録媒体
JP2002175436A (ja) 2000-12-08 2002-06-21 Nifty Corp ポータルサイト提供装置
US7206854B2 (en) * 2000-12-11 2007-04-17 General Instrument Corporation Seamless arbitrary data insertion for streaming media
JP2004240466A (ja) 2000-12-26 2004-08-26 Ccp:Kk コンテンツ・データのエンコードシステム、エンコード方法、及びエンコード方法を用いたコンテンツ登録システム
US6832349B1 (en) * 2001-01-08 2004-12-14 Cardiff Software, Inc. Remote activation of enhanced functionality features in locally created documents
US20020116517A1 (en) * 2001-01-17 2002-08-22 Hudson Michael D. Virtual program streaming multi-media system
US7142566B1 (en) * 2001-02-15 2006-11-28 Cisco Systems Canada Co. Jitterless processing of bitstreams
US7200575B2 (en) 2001-02-27 2007-04-03 Hewlett-Packard Development Company, L.P. Managing access to digital content
GB2373406A (en) 2001-03-02 2002-09-18 Nokia Mobile Phones Ltd Wireless transactions
EP1243998B1 (en) 2001-03-21 2017-04-19 Excalibur IP, LLC A technique for license management and online software license enforcement
US7065507B2 (en) 2001-03-26 2006-06-20 Microsoft Corporation Supervised license acquisition in a digital rights management system on a computing device
KR100904572B1 (ko) 2001-03-29 2009-06-25 소니 가부시끼 가이샤 정보 처리 장치
US7313596B2 (en) * 2001-04-09 2007-12-25 Nippon Telegraph & Telephone Corporation Multicast data communication method, multicast data communication system, repeater, repeating method, and medium for storing repeating programs
US7188342B2 (en) 2001-04-20 2007-03-06 Microsoft Corporation Server controlled branding of client software deployed over computer networks
US20040139204A1 (en) * 2001-04-23 2004-07-15 Siegried Ergezinger Architecture for providing services in the internet
US8818871B2 (en) * 2001-06-21 2014-08-26 Thomson Licensing Method and system for electronic purchases using an intelligent data carrier medium, electronic coupon system, and interactive TV infrastructure
US7224805B2 (en) * 2001-07-06 2007-05-29 Nokia Corporation Consumption of content
US7636792B1 (en) 2001-07-13 2009-12-22 Oracle International Corporation Methods and systems for dynamic and automatic content creation for mobile devices
JP2003044739A (ja) 2001-07-27 2003-02-14 Kinya Kuriyama コンテンツ配信方法およびコンテンツ配信プログラム
US7120429B2 (en) 2001-08-13 2006-10-10 Qualcomm Inc. System and method for licensing applications on wireless devices over a wireless network
US7110982B2 (en) * 2001-08-27 2006-09-19 Dphi Acquisitions, Inc. Secure access method and system
JP3729106B2 (ja) 2001-08-31 2005-12-21 日本電気株式会社 コンテンツ配信システム及びそれに用いるコンテンツ配信方法
US7292773B2 (en) 2001-09-04 2007-11-06 Koninklijke Philips Electronics N.V. Implementation of mandatory segments in multimedia content
US20050021467A1 (en) * 2001-09-07 2005-01-27 Robert Franzdonk Distributed digital rights network (drn), and methods to access operate and implement the same
JP2003186905A (ja) 2001-12-18 2003-07-04 Toshisato Nakamura コンテンツシステム、方法、プログラム、および記憶媒体
US7242773B2 (en) 2002-09-09 2007-07-10 Sony Corporation Multiple partial encryption using retuning
US6996544B2 (en) 2002-02-27 2006-02-07 Imagineer Software, Inc. Multiple party content distribution system and method with rights management features
JP2003256670A (ja) 2002-02-28 2003-09-12 Fujitsu Ltd ソフトウェアの分散管理型ネット販売方法及びプロテクトプログラム
KR20030075948A (ko) 2002-03-22 2003-09-26 주식회사 엔피아시스템즈 디알엠 환경에서 플래쉬 컨텐츠를 사용하기 위한 범용솔루션의 제공 방법 및 시스템
US6947981B2 (en) * 2002-03-26 2005-09-20 Hewlett-Packard Development Company, L.P. Flexible data replication mechanism
JP2003288130A (ja) 2002-03-28 2003-10-10 Imagereality Co Ltd 圧縮ソフト使用時のネットワークを用いた課金システム及びライセンス発行サイト
US20030188317A1 (en) * 2002-03-28 2003-10-02 Liew William J. Advertisement system and methods for video-on-demand services
US7007042B2 (en) 2002-03-28 2006-02-28 Hewlett-Packard Development Company, L.P. System and method for automatic site failover in a storage area network
US7136875B2 (en) 2002-09-24 2006-11-14 Google, Inc. Serving advertisements based on content
US7716161B2 (en) 2002-09-24 2010-05-11 Google, Inc, Methods and apparatus for serving relevant advertisements
US20050034171A1 (en) 2002-05-03 2005-02-10 Robert Benya Technique for delivering programming content based on a modified network personal video recorder service
JP2003331047A (ja) 2002-05-16 2003-11-21 Canon Inc 情報処理システム及び情報処理装置及び情報処理方法及びそれをコンピュータに実施させるためのプログラム及びそのプログラムをコンピュータ読み出し可能に記憶した記憶媒体
JP4143336B2 (ja) * 2002-05-31 2008-09-03 キヤノン株式会社 情報処理装置および制御方法およびプログラム
US7092615B2 (en) 2002-06-05 2006-08-15 Matsushita Electric Industrial Co., Ltd. Content reproducing apparatus for reproducing content that is stream data divided into a plurality of reply segments, and content transmitting/receiving system
US7725557B2 (en) * 2002-06-24 2010-05-25 Microsoft Corporation Client-side caching of streaming media content
WO2004003879A2 (en) 2002-06-27 2004-01-08 Piranha Media Distribution, Inc. Method and apparatus for the free licensing of digital media content
US20050144136A1 (en) * 2002-06-28 2005-06-30 Fujitsu Limited Content providing system and content reproducing apparatus
JP3864867B2 (ja) 2002-07-23 2007-01-10 ソニー株式会社 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
US7707115B2 (en) 2002-07-25 2010-04-27 Avaya Inc. Periodic software licensing system
US7249060B2 (en) 2002-08-12 2007-07-24 Paybyclick Corporation Systems and methods for distributing on-line content
KR20100039450A (ko) 2002-09-16 2010-04-15 야후! 인크. 온-라인 소프트웨어 렌털
US20040088349A1 (en) * 2002-10-30 2004-05-06 Andre Beck Method and apparatus for providing anonymity to end-users in web transactions
AU2003287279A1 (en) 2002-11-01 2004-06-07 Scott Kevin Maxwell Method and system for online software purchases
US7257628B2 (en) * 2002-11-08 2007-08-14 Cisco Technology, Inc. Methods and apparatus for performing content distribution in a content distribution network
AU2003295515A1 (en) * 2002-11-11 2004-06-03 Supracomm, Inc. Multicast videoconferencing
US20060107330A1 (en) 2003-01-02 2006-05-18 Yaacov Ben-Yaacov Method and system for tracking and managing rights for digital music
US7526545B2 (en) 2003-01-17 2009-04-28 Relevant Media Llc Content distribution system
US20040148424A1 (en) 2003-01-24 2004-07-29 Aaron Berkson Digital media distribution system with expiring advertisements
JP4343542B2 (ja) * 2003-01-30 2009-10-14 ソニー株式会社 情報処理システム、情報処理装置および情報処理方法、並びにプログラムおよび記録媒体
US20050004873A1 (en) * 2003-02-03 2005-01-06 Robin Pou Distribution and rights management of digital content
JP4007596B2 (ja) 2003-02-25 2007-11-14 インターナショナル・ビジネス・マシーンズ・コーポレーション サーバ及びプログラム
JP4482380B2 (ja) 2003-06-19 2010-06-16 パナソニック株式会社 視聴制御装置、視聴制御プログラム、セキュアモジュール
US7103351B2 (en) * 2003-06-23 2006-09-05 July Systems Inc. Policy service system and methodology
JP4518768B2 (ja) 2003-09-16 2010-08-04 ソニー株式会社 通信システム、通信方法およびクライアント機器
US20050114205A1 (en) 2003-11-21 2005-05-26 Kenneth Nelson Multi-media digital cartridge storage and playback units
WO2005064484A1 (ja) 2003-12-25 2005-07-14 Mitsubishi Denki Kabushiki Kaisha デジタルコンテンツ利用権管理システム
JP4433290B2 (ja) 2004-05-19 2010-03-17 ソニー株式会社 コンテンツ提示装置、コンテンツ提示方法及びコンテンツ提示プログラム
US7395244B1 (en) 2004-06-23 2008-07-01 Symantec Corporation Criticality classification system and method
US20050288999A1 (en) * 2004-06-28 2005-12-29 Hightech Systems Ltd. Content file downloading over a network with usage rights
US20060013557A1 (en) * 2004-07-01 2006-01-19 Thomas Poslinski Suppression of trick modes in commercial playback
US20060143135A1 (en) * 2004-11-26 2006-06-29 Tucker David M Associating licensing information with software applications
US8627354B2 (en) * 2004-12-17 2014-01-07 Martin E. Hellman Tiered subscription broadcast system
US8270901B2 (en) * 2004-12-17 2012-09-18 Martin E. Hellman Dropout-resistant media broadcasting system
JP4514134B2 (ja) 2005-01-24 2010-07-28 株式会社コナミデジタルエンタテインメント ネットワークシステム、サーバ装置、不正利用検出方法、ならびに、プログラム
US20060167812A1 (en) 2005-01-24 2006-07-27 Microsoft Corporation Communication mechanisms for multi-merchant purchasing environment for downloadable products
US20060218602A1 (en) * 2005-02-23 2006-09-28 Sherer W P Replacement of trick mode content in a video on demand system
US7676584B2 (en) 2005-05-17 2010-03-09 Kid Group Llc Method and apparatus for providing games and content
US20060277098A1 (en) 2005-06-06 2006-12-07 Chung Tze D Media playing system and method for delivering multimedia content with up-to-date and targeted marketing messages over a communication network
GB2427717A (en) 2005-06-29 2007-01-03 Nucleus Ltd Monitoring and modifying web site content data through web server
US7925973B2 (en) 2005-08-12 2011-04-12 Brightcove, Inc. Distribution of content
US20090222530A1 (en) * 2005-08-23 2009-09-03 Matsushita Electric Industrial Co., Ltd. System and Method for Service Discovery in a Computer Network Using Dynamic Proxy and Data Dissemination
US7856645B2 (en) 2005-09-01 2010-12-21 Abroadcasting Company Displaying programming and non-programming contents on user-display systems across computer networks
US20070094691A1 (en) 2005-10-24 2007-04-26 Gazdzinski Robert F Method and apparatus for on-demand content transmission and control over networks
EP1788773A1 (en) * 2005-11-18 2007-05-23 Alcatel Lucent Method and apparatuses to request delivery of a media asset and to establish a token in advance
US20070162560A1 (en) 2006-01-11 2007-07-12 Bea Systems, Inc. System and method for asynchronous request response
US20090286560A1 (en) 2006-01-13 2009-11-19 Michael John Willis System and method for mobile content generation
US20070244823A1 (en) 2006-04-13 2007-10-18 Bowe Bell + Howell Company Web-based method and system for enabling licensed products and features
US20070282714A1 (en) 2006-04-27 2007-12-06 Snocap, Inc. System, method and computer program product for providing an e-commerce interface on a web page to facilitate e-commerce involving digital assets
US7836511B2 (en) 2006-06-14 2010-11-16 Microsoft Corporation Enforcing advertisement playback for downloaded media content
US20080019516A1 (en) 2006-06-22 2008-01-24 Entriq Inc. Enforced delay of access to digital content
US20080022347A1 (en) 2006-07-05 2008-01-24 Noam Cohen TV-on-demand
EP2046993A4 (en) 2006-07-07 2010-11-17 Univ Massachusetts RNA INTERFERENCE COMPOSITIONS AND METHOD FOR TREATING MORBUS HUNTINGTON
US20080027750A1 (en) 2006-07-27 2008-01-31 Barkeloo Jason E System and method for digital rights management
US8752086B2 (en) 2006-08-09 2014-06-10 Carson Victor Conant Methods and apparatus for sending content to a media player
JP2008072655A (ja) 2006-09-15 2008-03-27 Fujitsu Ltd サービス通信制御方法、サービス中継装置およびサービス通信制御システム
US7743161B2 (en) * 2006-10-10 2010-06-22 Ortiva Wireless, Inc. Digital content buffer for adaptive streaming
CA2607698C (en) 2006-10-24 2017-06-27 Protexis Inc. Open, neutral electronic distribution system for digital content providing distribution channel support to publishers and retailers and abstract fulfillment for publishers
US20080114695A1 (en) 2006-11-10 2008-05-15 Semantic Components S.L. Process for implementing a method for the on-line sale of software product use licenses through a data network, and software component which allows carrying out said process
US20100250400A1 (en) 2006-11-10 2010-09-30 Media Patents, S.L. Apparatus and methods for the sale of software products
US8555318B2 (en) 2006-12-06 2013-10-08 Verizon Patent And Licensing Inc. Customized media on demand
US20080152316A1 (en) 2006-12-21 2008-06-26 Nortel Networks Limited Remote control of media content delivery to a digital media recorder
US20080152300A1 (en) * 2006-12-22 2008-06-26 Guideworks, Llc Systems and methods for inserting advertisements during commercial skip
US8239274B2 (en) 2007-01-11 2012-08-07 Microsoft Corporation Purchasing of individual features of a software product
US20080177630A1 (en) 2007-01-19 2008-07-24 Babak Maghfourian Method apparatus, system, media, and signals for billing a sponsor of an object link in interactive sequenced media
US20080189429A1 (en) * 2007-02-02 2008-08-07 Sony Corporation Apparatus and method for peer-to-peer streaming
WO2008098249A1 (en) * 2007-02-09 2008-08-14 Dilithium Networks Pty Ltd. Method and apparatus for the adaptation of multimedia content in telecommunications networks
US20080249872A1 (en) 2007-03-26 2008-10-09 Russell Stephen A Systems and Methods for Enabling Users to Sample and Acquire Content
US8498628B2 (en) 2007-03-27 2013-07-30 Iocast Llc Content delivery system and method
JP5133400B2 (ja) 2007-04-04 2013-01-30 メディア パテンツ エセ．エレ． 知的所有権によって保護されたデジタルファイルの、データネットワークを介したオンライン分配方法と、当該方法を実行するプログラムを含むコンピュータで読み取り可能な媒体
US9911126B2 (en) 2007-04-10 2018-03-06 Google Llc Refreshing advertisements in offline or virally distributed content
MX2009011047A (es) 2007-04-13 2010-03-30 Sezmi Corp Interfaz del visualizador para un sistema de distribucion de contenido.
US20090165041A1 (en) 2007-12-21 2009-06-25 Penberthy John S System and Method for Providing Interactive Content with Video Content
US20080288976A1 (en) * 2007-05-18 2008-11-20 Carson David V System and Method for Providing Advertisements for Video Content in a Packet Based Network
US20100046516A1 (en) 2007-06-26 2010-02-25 Media Patents, S.L. Methods and Devices for Managing Multicast Traffic
ATE542327T1 (de) 2007-06-26 2012-02-15 Media Patents Sl Vorrichtung zur verwaltung von mehrfachsendungsgruppen
US9137316B2 (en) 2007-09-26 2015-09-15 Cisco Technology, Inc. Controlling receipt of electronic advertising
EP2213042A1 (en) 2007-10-15 2010-08-04 Media Patents, S. L. Method for managing multicast traffic in a data network and network equipment using said method
US8064449B2 (en) 2007-10-15 2011-11-22 Media Patents, S.L. Methods and apparatus for managing multicast traffic
EP2215772A1 (en) 2007-10-30 2010-08-11 Media Patents, S. L. Method for managing multicast traffic between routers communicating by means of a protocol integrating the pim protocol; and router and switch involved in said method
US20110060688A1 (en) 2007-11-23 2011-03-10 Media Patents, S.L. Apparatus and methods for the distribution of digital files
WO2009065526A1 (en) 2007-11-23 2009-05-28 Media Patents S.L. A process for the on-line distribution of audiovisual contents with advertisements, advertisement management system, digital rights management system and audiovisual content player provided with said systems
WO2009095041A1 (en) 2008-02-01 2009-08-06 Soporte Multivendor S.L. Method for managing multicast traffic through a switch operating in the layer 2 of the osi model, and router and switch involved in said method
US8868464B2 (en) 2008-02-07 2014-10-21 Google Inc. Preventing unauthorized modification or skipping of viewing of advertisements within content
WO2009101488A1 (en) * 2008-02-13 2009-08-20 Nds Limited Advertisement shifting system
US9503691B2 (en) 2008-02-19 2016-11-22 Time Warner Cable Enterprises Llc Methods and apparatus for enhanced advertising and promotional delivery in a network
WO2009109684A1 (es) 2008-03-05 2009-09-11 Media Patents, S. L. Procedimiento para monitorizar o gestionar equipos conectados a una red de datos
US7984097B2 (en) 2008-03-18 2011-07-19 Media Patents, S.L. Methods for transmitting multimedia files and advertisements
ES2326949B1 (es) 2008-03-18 2010-07-14 Clarity Systems, S.L. Procedimiento utilizado por un servidor de streaming para realizar una transmision de un fichero multimedia en una red de datos.
US20090259764A1 (en) * 2008-04-11 2009-10-15 Mobitv, Inc. Intro outro merger with bit rate variation support
US8769149B2 (en) 2008-08-08 2014-07-01 Disney Enterprises, Inc. System and method for real-time location-based advertisement insertion into online content
US20100064054A1 (en) * 2008-09-09 2010-03-11 Mobitv, Inc. Remote fast forward and rewind functionality for client devices
US9154532B2 (en) 2009-04-27 2015-10-06 Zaron Remote Llc Methods and apparatus for transmitting multimedia files in a data network

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6990512B1 (en) * 2001-03-19 2006-01-24 Novell, Inc. Method and system for using live time shift technology to control a multimedia file
US20030149975A1 (en) * 2002-02-05 2003-08-07 Charles Eldering Targeted advertising in on demand programming
US20060031892A1 (en) * 2004-08-05 2006-02-09 Bitband Technologies Ltd. Prevention of advertisement skipping
WO2006086717A1 (en) * 2005-02-11 2006-08-17 Vidiator Enterprises Inc. Method of multiple file streaming service through playlist in mobile environment and system thereof
WO2006138432A2 (en) * 2005-06-17 2006-12-28 Lightningcast Llc Presenting advertising content

Also Published As

Publication number Publication date
US20100070355A1 (en) 2010-03-18
US20100082835A1 (en) 2010-04-01
US20090240830A1 (en) 2009-09-24
US8676885B2 (en) 2014-03-18
US20140172592A1 (en) 2014-06-19
US20160212453A1 (en) 2016-07-21
US9955198B2 (en) 2018-04-24
US7966411B2 (en) 2011-06-21
US7809790B2 (en) 2010-10-05
US20100076827A1 (en) 2010-03-25
US20090240786A1 (en) 2009-09-24
US20090240828A1 (en) 2009-09-24
US9324097B2 (en) 2016-04-26
US20090240827A1 (en) 2009-09-24
US7565429B1 (en) 2009-07-21
ES2326949B1 (es) 2010-07-14
WO2009115631A1 (es) 2009-09-24
US8028064B2 (en) 2011-09-27
US8185625B2 (en) 2012-05-22
US8255527B2 (en) 2012-08-28
US7962548B2 (en) 2011-06-14
US20090240768A1 (en) 2009-09-24
US8055781B2 (en) 2011-11-08
US8185626B2 (en) 2012-05-22
US20120323651A1 (en) 2012-12-20

Similar Documents

Publication Publication Date Title
ES2326949B1 (es) Procedimiento utilizado por un servidor de streaming para realizar una transmision de un fichero multimedia en una red de datos.
US8090774B2 (en) Methods for transmitting multimedia files and advertisements
Zambelli IIS smooth streaming technical overview
US9911126B2 (en) Refreshing advertisements in offline or virally distributed content
US10616297B2 (en) Content-specific identification and timing behavior in dynamic adaptive streaming over hypertext transfer protocol
US9462302B2 (en) Efficient delineation and distribution of media segments
EP3456059A1 (en) System for video playback using a server generated manifest
US8737804B2 (en) System for delayed video viewing
US20130268963A1 (en) Methods and systems for delivery of compliant video advertisements to devices from one or more platforms
KR20120114016A (ko) 사용자 컨텐츠를 외부 단말기에서 네트워크 적응적으로 스트리밍하는 방법 및 장치
TWI577186B (zh) 第二內容串流在第二裝置上描繪時間之控制方法及控制裝置
JP2010028692A (ja) コンテンツ再生装置およびコンテンツ不正再生防止方法

Legal Events

Date Code Title Description
EC2A Search report published

Date of ref document: 20091021

Kind code of ref document: A1

FG2A Definitive protection

Ref document number: 2326949B1

Country of ref document: ES

FA2A Application withdrawn

Effective date: 20110131