ES2397911B1

ES2397911B1 - Método para la distribución de contenido en una red de distribución de contenido.

Info

Publication number: ES2397911B1
Application number: ES201130755A
Authority: ES
Inventors: Parminder Chhabra; Armando Antonio GARCÍA MENDOZA; Arcadio PANDO CAO; Pablo RODRÍGUEZ RODRÍGUEZ
Original assignee: Telefonica SA
Current assignee: Telefonica SA
Priority date: 2011-05-12
Filing date: 2011-05-12
Publication date: 2014-01-15
Anticipated expiration: 2031-05-12
Also published as: BR112013029000A2; AR086335A1; WO2012152767A1; EP2708030A1; ES2397911A1; CL2013003219A1; US20140149548A1

Abstract

Método para la distribución de contenido en una red de distribución de contenido.#Comprende usar contenedores como compartimentos lógicos para archivos de contenido, y asociar metadatos a dichos contenedores, comprendiendo dicha asociación de metadatos la asociación de dos clases de metadatos: metadatos de sistema de archivos y metadatos de distribución de contenido. Estos últimos incluyen atributos o propiedades para uso específico en un sistema CDN, y el método comprende usar dichos metadatos de distribución de contenido para gestionar la distribución de contenido en un servicio CDN.

Description

Método para la distribución de contenido en una red de distribución de contenido

Campo de la técnica

La presente invención se refiere, en general, a un método para la distribución de contenido en una red de distribución de contenido, o CDN, que comprende usar contenedores como compartimentos lógicos para archivos de contenido y asociar metadatos de sistema de archivos a dichos contenedores, y más particularmente a un método que comprende además asociar metadatos de distribución de contenido a los contenedores para gestionar la distribución de contenido a través de un servicio CDN.

Estado de la técnica anterior

A continuación se facilitan algunas definiciones que son útiles para comprender la terminología usada tanto para las divulgaciones de la técnica anterior como para la presente invención.

PoP: Un punto de presencia es una demarcación artificial o punto de interfaz entre dos entidades de comunicación. Es un punto de acceso a Internet que aloja servidores, conmutadores, encaminadores y agregadores de llamadas. Los ISP normalmente tienen múltiples PoP.

Red de distribución de contenido (CDN): Esto se refiere a un sistema de nodos (u ordenadores) que contienen copias de contenido de cliente que está almacenado y situado en diversos puntos en una red (o Internet pública). Cuando se replica contenido en diversos puntos en la red, el ancho de banda se utiliza mejor a lo largo de la red y los usuarios tienen tiempos de acceso más rápidos al contenido. De este modo, el servidor original que contiene la copia original del contenido no experimenta atascos.

Sistema de resolución de DNS de ISP: Los usuarios residenciales se conectan a un ISP. Cualquier petición para resolver una dirección se envía a un sistema de resolución de DNS mantenido por el ISP. El sistema de resolución de DNS de ISP enviará la petición de DNS a uno o más servidores DNS dentro del dominio administrativo del ISP.

URL: Uniform Resource Locator (URL, localizador uniforme de recursos) es la dirección de una página web en la world-wide web. No hay dos URL idénticos. Si son idénticos, apuntan al mismo recurso.

Redirección de URL (o HTTP): La redirección de URL también se conoce como reenvío de URL. Puede ser necesario redireccionar una página si su nombre de dominio ha cambiado, si se crean alias significativos para URL largos o que cambian frecuentemente si el usuario deletrea mal el nombre de dominio al teclearlo, si se manipula a los visitantes, etc. En este caso, un servicio de redirección típico es uno que redirecciona usuarios al contenido deseado. Un enlace de redirección puede usarse como dirección permanente para contenido que cambia frecuentemente de anfitrión (host) (casi como de DNS).

ARL (Alternate Resource Locator, localizador alternativo de recursos): ARL es en realidad un URL con datos específicos CDN incorporados. ARL es un subconjunto de URL y se usa para direccionar peticiones a servidores de contenido CDN.

Contenedor: Un contenedor es un compartimento lógico para un cliente que contiene el contenido del cliente CDN. Un contenedor o bien establece un enlace entre el URL del servidor original y el URL de la CDN o bien puede contener el propio contenido (que se carga en el contenedor en el punto de entrada). Un nodo de extremo replicará archivos desde el servidor original a archivos en el contenedor. Cada archivo en un contenedor puede correlacionarse exactamente con un archivo en el servidor original. Un contenedor tiene varios atributos asociados con él – el tiempo desde y el tiempo hasta que el contenido es válido, geobloqueo de contenido. También se utilizan mecanismos para garantizar que se transmiten automáticamente nuevas versiones del contenido en el servidor original al contenedor en los nodos de extremo y se eliminan versiones antiguas.

Un cliente puede crear tantos contenedores como desee. Un contenedor es realmente un directorio que contiene archivos de contenido. Un contenedor puede contener subdirectorios y archivos de contenido dentro de cada uno de estos subdirectorios.

Geolocalización: Es la identificación de ubicaciones geográficas reales de un dispositivo conectado a Internet. El dispositivo puede ser un ordenador, dispositivo móvil o un aparato que permita la conexión a Internet a un usuario final. Los datos de geolocalización de la dirección IP pueden incluir información tal como país, región, ciudad, código postal, latitud / longitud de un usuario.

Aplicación de función hash (hashing) consistente: Este método proporciona la funcionalidad de una tabla hash de modo que la adición o eliminación de una ranura no altera significativamente la correlación de llaves con ranuras. La aplicación de función hash consistente es un modo de distribuir peticiones entre una población grande y cambiante de servidores web. La adición o eliminación de un servidor web no altera significativamente la carga en los otros servidores.

ES 2 397 911 A1

Es muy comprensible el uso de un contenedor o un contenedor, como abstracción de una carpeta para almacenar contenido. Sin embargo, usarlos meramente como carpetas con controles de acceso es arcaico.

En Amazon, un contenedor S3 [2], [3] sirve simplemente como carpeta que contiene archivos de contenido. Un contenedor S3 se crea en exactamente una región (una región física EE.UU., UE o APAC está asociada con un contenedor). Un objeto almacenado en una región reside únicamente en esa región, pero un usuario final puede acceder al mismo desde cualquier lugar. Amazon S3 no copia ni mueve un objeto a otra región.

En Amazon S3, un contenedor creado tiene las siguientes propiedades (o metadatos) [3], [4]: nombre de contenedor, fecha de creación del contenedor, ubicación del contenedor o región en la que se creó, nombre del propietario, ID de propietario, estado de la versión, carpeta virtual total en el contenedor seleccionado, número total de archivos en el contenedor seleccionado, tamaño total del contenedor, número total de objetos.

Estas propiedades (o metadatos) son similares a las propiedades de sistema de archivos en Unix. Además, el acceso a un objeto S3 está guiado por políticas que deben definirse explícitamente a través de una lista de control de acceso (ACL, access control list). La ACL está diseñada para dar permisos de lectura, escritura a todo el mundo, usuarios autenticados y al propietario (creador) del contenedor y los objetos en el contenedor.

Amazon proporciona contenido usando Amazon Cloudfront (la versión de Amazon de la red de distribución de contenido, o CDN). Con el fin de proporcionar contenido desde un contenedor S3, el cliente CDN crea un contenedor y crea una distribución (lo que es equivalente a obtener URL para el contenido que debe proporcionarse mediante la CDN). Esta interacción es a través de API de REST y usando las credenciales del cliente CDN. La infraestructura Cloudfront copia el contenido solicitado desde el contenedor S3 a la ubicación de borde y proporciona el contenido al usuario final solicitante.

Las decisiones sobre geobloqueo y durante cuánto tiempo es válido el contenido en un contenedor para su distribución mediante Cloudfront se implementan como políticas. Un ejemplo de una petición según políticas es: denegar todas las peticiones originadas en EE.UU. Las políticas se evalúan antes de realizar la petición a un contenedor S3. Las políticas junto con las ACL controlan el acceso a objetos en Cloudfront.

La distribución de Amazon Cloudfront soporta sólo objetos HTTP o distribuciones de transmisión en flujo continuo (RTMP). Además, también se soportan variantes de RTMP (RTMPE, RTMP,T RTMPTE). Actualmente, Cloudfront no soporta transmisión en flujo continuo en tiempo real de contenido.

Tanto Amazon Cloudfront como Akamai usan la validez del contenido como parte del URL (Akamai lo denomina ARL - Akamai Resource Locator (localizador de recursos Akamai) [1] y Cloudfront genera esto cuando crea una distribución). Entonces, los contenedores son meramente carpetas con controles de acceso.

Actualmente, varias empresas, incluyendo Amazon [2] y Akamai [1], usan la noción de un contenedor como carpeta para almacenar datos. Asociando el control de acceso sobre los contenedores, permiten que se compartan los datos en un contenedor entre un grupo seleccionado de usuarios o que se haga público el contenedor.

Cuando se usa para la distribución de contenido, asociar meramente el control de acceso a nivel de contenedor es insuficiente, ya que cualquier infraestructura de distribución de contenido necesita una gran cantidad de información adicional acerca del contenedor antes de poder proporcionar contenido desde un contenedor.

En la actualidad, el estado de la técnica para asociar metadatos con contenido se basa en uno o más de los siguientes conceptos: los metadatos forman parte de la propia cadena de petición. Aunque esto es útil para resolver rápidamente los servidores que contienen el contenido (ya que todos los datos de un cliente residen en un contenedor), el número de campos de metadatos es limitado ya que el localizador de recursos (por ejemplo Akamai Resource Locator (ARL), un URL para localizar contenido CDN) sólo puede ser así de largo. Además, este esquema es inflexible si el cliente CDN quisiera asociar nuevos metadatos con el contenido o cambiar cualquiera de los metadatos (o si el administrador CDN ha de cambiar el URL para cada cambio en los metadatos). Se considera el siguiente ejemplo de una ARL 0 de ese tipo: <cdn-endhost>/<customer_id>/<meta-data>/content. En este caso, el contenido puede ser el nombre del archivo de vídeo o jpg. Los metadatos se reciben desde el servidor original en respuesta a una petición de contenido. Esto implica que debe hacerse una petición posterior para el contenido, lo que requiere otro nivel de indirección. Para Cloudfront, cada petición a un nuevo borde implica que el borde obtiene contenido del mismo contenedor S3. El contenido de un contenedor S3 reside sólo en la región en la que se crea el contenedor. El contenedor S3 en Amazon tiene metadatos similares a sistema de archivos. Se crea un archivo de configuración de metadatos por contenedor. Aunque esto es útil, no es suficientemente granular para abordar varias cuestiones. Puede ser necesario proporcionar dos archivos del mismo cliente a diferentes tasas de transmisión dependiendo del contenido (será necesario proporcionar el contenido de alta definición a una tasa de transmisión superior), el contenido procedente de un cliente puede proporcionarse a usuarios finales en ciertas áreas geográficas del mundo y no otras. Los archivos de configuración de metadatos se distribuyen a servidores de contenido CDN. Aunque ésta puede parecer una solución simple, tiene la sobrecarga de que cada servidor mantiene varios archivos de configuración y los sincroniza para garantizar su consistencia. De nuevo, estos archivos de configuración son por cliente.

ES 2 397 911 A1

El documento US7240100 da a conocer un método para asociar metadatos a un contenido dado que debe distribuirse a través de una CDN, estando ubicados dichos metadatos en un archivo de configuración de metadatos distribuido a servidores CDN, o en un archivo de configuración de metadatos por cliente. Los metadatos asociados mediante el método del documento US7240100 son sólo de tipo de sistema de archivos.

Los documentos US7647329 y US7739239 dan a conocer datos de almacenamiento como objetos dentro de contenedores, estando compuesto cada uno de dichos objetos por un archivo y opcionalmente cualquier metadato que describa ese archivo. Para almacenar un objeto según dichas patentes, debe cargarse el archivo que se desea almacenar a un contenedor. Cuando se carga un archivo, pueden fijarse permisos sobre el objeto así como cualquier metadato. Para cada contenedor, puede controlarse el acceso al contenedor (quién puede crear, borrar, enumerar objetos, etc.). Los documentos US7647329 y US7739239 sólo dan a conocer la asociación de metadatos de sistema de archivos.

Todos los esquemas anteriores son muy rígidos en cuanto a cómo tratan los metadatos. Los metadatos no son suficientemente granulares (son por cliente o por contenedor en vez de por archivo), son complejos para su tratamiento por parte de un cliente CDN y son propensos a sobrecarga por mantenimiento. Además, los metadatos asociados de dichas divulgaciones son sólo de tipo de sistema de archivos.

Descripción de la invención

Es necesario ofrecer una alternativa al estado de la técnica que cubra las lagunas encontradas en la misma, particularmente las relacionadas con la rigidez con la que se tratan los metadatos asociados a contenedores en las divulgaciones citadas anteriormente.

Para ello, la presente invención proporciona un método para la distribución de contenido en una CDN, que comprende usar contenedores como compartimentos lógicos para archivos de contenido, y asociar metadatos de sistema de archivos a dichos contenedores, comprendiendo además el método, a diferencia de las propuestas conocidas, de manera característica, asociar metadatos de distribución de contenido a dichos contenedores, incluyendo dichos metadatos de distribución de contenido atributos o propiedades de uso específico para un sistema CDN, y usar dichos metadatos de distribución de contenido para gestionar la distribución de contenido a través de un servicio CDN.

Los contenedores creados y usados según el método de la invención se denominan en la presente descripción contenedores inteligentes.

Para una realización, el método comprende generar automáticamente dichos metadatos de sistema de archivos cuando se crea un contenedor o un archivo de contenido en un contenedor.

Aunque dichos metadatos de sistema de archivos son similares a los atributos de archivo de cualquier sistema de archivos (tal como un sistema operativo), los metadatos de distribución de contenido son atributos o propiedades de uso específico para un sistema CDN, es decir son una propiedad inherente de los contenedores y, por tanto, proporcionan a tales contenedores inteligencia para su uso en una CDN.

Dependiendo de la realización, el método comprende asociar dichos metadatos de sistema de archivos y dichos metadatos de distribución de contenido con cada archivo de cada contenedor, incluyendo dichos archivos de contenido, y/o con cada contenedor.

El método comprende, preferiblemente, crear dichos contenedores inteligentes con distribución de contenido como la única aplicación.

En general, el método comprende llevar a cabo dicha distribución de contenido a través de dicha CDN, a un usuario final, usando dichos metadatos asociados para guiar dicha distribución de contenido, proporcionando así al cliente CDN, por medio de la asociación de metadatos para la distribución de contenido para un contenedor y con cada archivo en un contenedor, flexibilidad en cómo tratar los metadatos para cada archivo.

Otras realizaciones de la invención se describen en las reivindicaciones 7 a 17 adjuntas, y en una sección posterior relativa a la descripción detallada de varias realizaciones.

Para la presente invención, en la CDN del proveedor de servicio, un contenedor inteligente es un compartimento lógico para que un cliente almacene datos en una CDN.

ES 2 397 911 A1

Breve descripción de los dibujos

Las ventajas y características anteriores, y otras, se entenderán de manera más completa a partir de la siguiente descripción detallada de realizaciones, con referencia a los dibujos adjuntos, que deben considerarse de manera ilustrativa y no limitativa, en los que:

la figura 1 muestra la interacción entre un cliente CDN y la infraestructura CDN del proveedor de servicio según una realización del método de la invención. El contenedor creado por un cliente CDN se sincroniza entre el punto de entrada y el rastreador y entre el rastreador y los nodos de extremo.

Descripción detallada de varias realizaciones

En primer lugar, se facilita una breve descripción de cada componente del sistema CDN del proveedor de servicio ilustrado mediante la figura 1. La infraestructura ilustrada consiste en servidores originales, rastreadores, nodos de extremo y punto de entrada. Esto forma parte de una infraestructura CDN del proveedor de servicio usada por contenedores.

Punto de entrada (punto de publicación): Cualquier cliente CDN puede interaccionar con la infraestructura CDN únicamente a través del punto de entrada. El punto de entrada ejecuta una interfaz de servicios web con usuarios de cuentas registradas para crear / borrar y actualizar contenedores.

Un cliente tiene dos opciones para cargar contenido. El cliente puede o bien cargar archivos en el contenedor o bien dar los URL de los archivos de contenido que residen en el sitio web del cliente CDN. Una vez que la infraestructura CDN descarga el contenido, los archivos se mueven a otro directorio para su postprocesamiento. Las etapas de postprocesamiento implican comprobar la consistencia de los archivos y si hay algún error. Sólo entonces se mueve el archivo descargado al servidor original. El servidor original contiene la copia maestra de los datos.

Gestor CDN: El gestor CDN alberga la API de gestor de contenidos, la API DNS y la API de topología de red (todas las API están en este servidor). Hay una instancia del gestor CDN para toda la CDN. El gestor CDN puede residir en uno de los puntos de entrada (puntos de publicación) o en un servidor separado.

Nodo de extremo: Un nodo de extremo es la entidad que gestiona la comunicación entre usuarios finales y la infraestructura CDN. Esencialmente es un servidor HTTP personalizado.

Rastreador: El rastreador es la entidad clave que permite la inteligencia y coordinación de la infraestructura CDN.

Servidor original: Este es el (los) servidor(es) en la infraestructura CDN que contiene(n) la copia maestra de los datos. Cualquier nodo de extremo que no tenga una copia de los datos puede solicitarla del servidor original. El cliente CDN no tiene acceso al servidor original. La infraestructura CDN de Telefónica mueve los datos desde el servidor ftp al servidor original tras realizar comprobaciones de seguridad en los datos descargados.

La infraestructura CDN del proveedor de servicio usa el contenedor inteligente como una abstracción para almacenar y distribuir el contenido de un cliente CDN. En la CDN del proveedor de servicio, todos los contenedores son de tipo gestionado. El contenido para los contenedores de tipo gestionado se controla completamente mediante la CDN. Para el tipo de contenedor gestionado, la CDN del proveedor de servicio permite la creación de dos clases de contenedores (aunque el método no se limita sólo a dichas dos clases de contenedores): VoD y transmisión en flujo continuo en tiempo real. Ambos contenedores tienen asociados metadatos de tipo sistema de archivos y metadatos que controlan la distribución de contenido.

Un contenedor de VoD, por definición, es bajo demanda y puede almacenar cualquier clase de contenido (el formato del archivo puede ser de cualquier tipo). Los nodos de extremo proporcionan el contenido en el contenedor si el nodo de extremo puede proporcionar la clase de contenido especificado en los tipos de archivo en el contenedor. Así, un contenedor de VoD puede proporcionar objetos HTTP, RTSP, RTMP, MMS, etc. El contenedor de VoD también puede usar una variedad de mecanismos de distribución incluyendo RTMP, transmisión en flujo continuo suave y transmisión en flujo continuo a través de iPhone. Un contenedor de VoD no impone ninguna restricción acerca de la clase de archivo de medios o el mecanismo de distribución para el archivo.

Un contenedor de tiempo real se crea para transmitir en flujo continuo contenido en tiempo real. Un contenedor de tiempo real puede proporcionar cualquier flujo continuo de medios en tiempo real a través de cualquier mecanismo de distribución.

Los nodos de extremo CDN proporcionan el contenido solicitado por los usuarios finales. Sin embargo, el resto de la infraestructura CDN, el punto de entrada en el que se creó el contenedor inteligente y el rastreador que sincroniza los metadatos de contenedor con el punto de entrada periódicamente sólo sirven como proxy para el contenedor para la infraestructura CDN.

En la CDN del proveedor de servicio, un cliente CDN puede interaccionar con la infraestructura CDN sólo en el punto de entrada. En primer lugar se describe cómo fijar las propiedades de un contenedor; añadir contenido a un

ES 2 397 911 A1

contenedor y, finalmente, cómo asociar metadatos con archivos en un contenedor que convierten al contenedor en inteligente para su uso en la distribución de contenido en la infraestructura CDN.

Cualquier cliente CDN puede crear un contenedor en el punto de entrada. El contenedor tiene metadatos que son tanto de tipo sistema de archivos como para la distribución de contenido.

Los campos en los metadatos de sistema de archivos son: bucket_id (ID de contenedor), name (nombre), enabled (habilitado), date_created (fecha de creación) y last_modified (última modificación), last_accessed (último acceso). El resto de los parámetros están asociados con la distribución de contenido.

Los siguientes parámetros pueden asociarse con un contenedor cuando se crea un contenedor. Lo que se enumera es el nombre de cada parámetro, su tipo y también si es necesario definirlo en el momento de creación del contenedor. Algunos campos son opcionales. A algunos de los campos se les puede asignar un valor por defecto cuando se crea un contenedor.

•: nombre: bucket_id, tipo: long (largo), opcional: no. Este campo es un identificador de contenedor globalmente único. El gestor CDN asigna este valor a un contenedor. Un ID de contenedor es globalmente único.

•: nombre: name, tipo: string (cadena), opcional: no. Este campo es el nombre del objeto de contenedor. Por tanto, un cliente puede dar un nombre significativo al contenedor.

•: nombre: enabled, tipo: integer (número entero), opcional: no. Este campo indica si el contenedor está habilitado. Un valor 1 implica que el contenedor está habilitado, mientras que 0 implica que no lo está (lo que implica que el contenedor no existe).

•: nombre: date_created, tipo: long, opcional: no. Este campo indica la fecha y hora en que se creó el contenedor.

•: nombre: last_modified, tipo: long, opcional: no. Este campo se fija automáticamente. Indica la última vez que se modificaron los metadatos de contenedor.

•: nombre: last_accessed, tipo: long, opcional: no. Este campo se fija automáticamente. Este campo indica la última vez que un usuario final accedió a algún archivo en el contenedor.

•: nombre: managed, tipo: integer, opcional: no. Si un contenedor está gestionado (valor = 1), entonces el servidor original es el servidor original de la CDN. En caso contrario, el contenido debe descargarse del servidor del cliente CDN (valor de managed = 0). La dirección del servidor se encuentra en el campo sourceurl.

•: nombre: originserver, tipo: string, opcional: no. Este campo es el prefijo de URL del servidor original que forma parte de la infraestructura CDN. Se asigna por la infraestructura CDN.

•: nombre: sourceurl, tipo: string, opcional: yes. Este campo contiene el URL del servidor en el que se almacenan los archivos para este contenedor en las instalaciones del cliente. La infraestructura CDN obtiene el contenido de este URL. Este campo está vacío si el contenedor está gestionado.

•: nombre: bandwidth, tipo: integer, opcional: no. Este campo facilita la tasa de transmisión máxima a la que debe distribuirse un archivo en este contenedor a un usuario final solicitante en Kbytes/s. Si se usa un valor de cero, el archivo se proporciona a la tasa de transmisión máxima mediante los nodos de extremo.

•: nombre: live, tipo: integer, opcional: no. Este campo indica si el contenedor es para difusión en tiempo real o para VoD. Un valor 1 implica que el contenido en el contenedor es contenido en tiempo real. Por otro lado, un valor de 0 implica que el contenedor contiene contenido para VoD.

•: nombre: bucket_contint, tipo: string, opcional: yes. Este campo contiene el URL de un archivo que tiene el SHA1 de todos los archivos de contenido en el contenedor.

•: nombre: startdate, tipo: long, opcional: yes. Este campo significa el momento en el que el contenido del contenedor pasará a estar disponible (en segundos desde 1970-01-01 00:00:00 UTC).

•: nombre: enddate, tipo: long, opcional: yes. Momento en el que el contenido del contenedor no estará disponible (en segundos desde 1970-01-01 00:00:00 UTC).

•: nombre: geoloc, tipo: Array<string>, opcional: yes. Es una lista separada por comas de códigos de país en los que el contenido del contenedor es válido. Es útil para geobloquear peticiones de usuarios finales.

•: nombre: geolocinv, tipo: string, opcional: yes. Es el URL de un archivo html personalizado que debe enviarse en el caso de un fallo de geolocalización (el contenido no puede distribuirse al país / región del usuario solicitante).

•: nombre: referrer, tipo: string, opcional: yes. Es la dirección http del sitio web que dirigió al usuario final solicitante para obtener el contenido de la infraestructura CDN. Los nodos de extremo proporcionarán datos a un usuario final sólo si la petición procede del dominio del cliente CDN.

•: nombre: host, tipo: string, opcional: yes. Este campo es el nombre del anfitrión. Es útil si se ejecutan múltiples sitios web en el mismo nodo CDN.

•: nombre: qos, tipo: integer, opcional: yes. Este campo indica la QoS de los archivos en el contenedor.

•: nombre: size, tipo: string, opcional: yes. Este campo indica el tamaño del contenedor. Tiene dos posibles valores, grande y pequeño. Un motivo para distinguir el tamaño de un contenedor es que es fácil de almacenar en caché objetos pequeños.

•: nombre: deliverytype, tipo: list, opcional: no. Este campo identifica el tipo de contenido. 0: http nativo, 1: rtmp nativo, 2: rtmp, 3: transmisión en flujo continuo suave, 4: transmisión en flujo continuo a través de iPhone, 5: rtsp, 6: rtmpe, 7: rtmpt. A medida que aparecen tipos de distribución adicionales, este campo se usará para definir el tipo de distribución. Pueden definirse múltiples tipos de distribución de una vez.

•: nombre: multibitrate, tipo: boolean, opcional: yes. Este campo indica si se soportan múltiples tasas de transmisión de bits. Esto permite a la CDN distribuir contenido a usuarios finales a una tasa de transmisión de bits que coincide con la velocidad de conexión del usuario final. Esto es especialmente útil para la transmisión en flujo continuo en tiempo real en la que la CDN debe adaptarse rápidamente a condiciones de red cambiantes.

•: nombre: smil, tipo: string, opcional: yes. Este campo es útil sólo si multibitrate se fija a verdadero. Un archivo SMIL (Synchronized Multimedia Integration Language, lenguaje de integración multimedia sincronizada) [1] [4] basado en XML consiste en etiquetas que son sensibles a las mayúsculas. Todas las etiquetas SMIL requieren letras en minúscula.

ES 2 397 911 A1

a. Como ejemplo, se muestra cómo puede fijarse la CDN para distribuir flujos continuos de múltiples tasas de transmisión de bits de 100 Kbps y 350 Kbps como parte de la definición de un contenedor de tiempo real.

{

"multibitrate": true,

"smil":"<smil><head></head><body><switch><video src='rtmp://10.95.103.227:1935/liveorigin/live_multi1' system-bitrate='100000'/><video src='rtmp://10.95.103.227:1935/live-origin/live_multi2' system-bitrate='350000'/></switch></body></smil>"

}

•: nombre: preposition, tipo: unit, opcional: yes. Este campo indica el momento (tiempo Unix o Posix) en el en el que debe iniciarse el preposicionamiento del contenido.

•: nombre: prepositioncc, tipo: string, opcional: yes. Este campo es una lista separada por comas de códigos de país para el preposicionamiento del contenido. Si ignora si el campo preposition se fija a 0.

•: nombre: whitelist, tipo: string, opcional: yes. Lista separada por comas de subredes que están en la lista blanca.

•: nombre: blacklist, tipo: string, opcional: yes. Lista separada por comas de subredes que están en la lista negra.

•: nombre: seektype, tipo: string, opcional: yes. Este campo define el formato de la cadena de consulta asociada con peticiones de búsqueda de vídeo en un archivo solicitado por un usuario final.

•: nombre: autoseekinfo, tipo: boolean, opcional: yes. Este campo indica el nodo de extremo para construir tablas de búsqueda construidas previamente. Si se fija el campo, permite al nodo de extremo procesar peticiones del tipo http://endpoint/mp4file.mp4?start=210. En este caso, el usuario final desea iniciar el flujo continuo desde el punto de tiempo 3 min. y 30 s (o 210 s) desde el inicio del archivo de medios. Con tablas calculadas previamente en el nodo de extremo, el tiempo de inicio, un desfase correspondiente y cabeceras, la creación de los archivos binarios para el usuario final requiere mucho menos esfuerzo.

•: nombre: authentication, tipo: object, opcional: yes. Este campo define los diferentes tipos de autenticación que un propietario de contenido puede desear para soportar todo el contenido en el contenedor. Por tanto, cada petición de contenido se autenticará según lo solicite el propietario del contenido. Esto es flexible para incluir cualquier mecanismo de autenticación entre el propietario de contenido y los elementos de la CDN. Dependiendo del tipo de autenticación, el objeto tendrá diferentes tipos de campos.

•: nombre: orig_authentication, tipo: object, opcional: yes. Se usa para la autenticación del servidor original. Este campo es de tipo object y tiene los parámetros de username (nombre de usuario) y password (contraseña) del servidor original. Esto obliga a autenticar cada petición de contenido por parte del servidor original.

ES 2 397 911 A1

Una vez creado un contenedor, el cliente CDN puede cargar contenido en el contenedor. A continuación, se da a conocer cómo definir un contenedor de tiempo real y campos adicionales que puedan ser necesarios.

Contenedor de tiempo real:

Si el contenido en el contenedor es en tiempo real, es decir es un contenedor de transmisión en flujo continuo en tiempo real, el contenedor tiene metadatos adicionales asociados con el mismo.

•: nombre: sourceurl, tipo: string, opcional: no. Este campo es el URL de la fuente de flujo continuo que usó la CDN para obtener el flujo continuo en tiempo real. La CDN debe usar entonces esta alimentación en tiempo real para dar servicio a los usuarios finales solicitantes.

•: nombre: livesplitter, tipo: string, opcional: no. Este campo tiene la dirección IP y el número de puerto del divisor en tiempo real (IP_address:port). Esta infraestructura CDN usa el divisor en tiempo real y el segmentador en el flujo continuo en tiempo real para construir una lista de reproducción para proporcionar el flujo continuo en tiempo real.

•: nombre: segmentduration, tipo: uint, opcional: yes. Este campo representa la duración en segundos de cada segmento del flujo continuo en tiempo real. Se le asigna ya un valor por la infraestructura CDN.

•: nombre: playlistsize, tipo: uint, opcional: yes. Este campo representa el tamaño de la lista de reproducción. La duración de la lista de reproducción es el tamaño de la lista de reproducción * la duración del segmento. Este valor se fija por la CDN.

Todos los demás campos tales como whitelist, blacklist, geoloc, startdate, enddate y authentication pueden definirse igual que en un contenedor de VoD.

Un contenedor de tiempo real se trata de manera diferente a un contenedor de VoD. Un divisor en tiempo real en la infraestructura CDN obtiene el flujo continuo en tiempo real del propietario de contenido. Un segmentador en el divisor en tiempo real rompe el flujo continuo en segmentos. El divisor en tiempo real construye entonces una lista de reproducción a partir de estos segmentos y reenvía la lista de reproducción al nodo de extremo. El divisor en tiempo real actualiza periódicamente la lista de reproducción. Por tanto, el nodo de extremo infiere la lista de reproducción como contenido que llega de un servidor original en la infraestructura CDN. Este contenido se proporciona entonces a usuarios finales solicitantes.

Una vez creado un contenedor, sus metadatos pueden actualizarse / modificarse a través de una interfaz REST.

Añadir contenido a un contenedor de VoD CDN y asociar metadatos a archivos:

A continuación se proporciona una descripción detallada de la asociación de metadatos con archivos en un contenedor de VoD. Dicha descripción también es válida para otras realizaciones para las que los datos que van a distribuirse son otros diferentes de datos de vídeo. También se explica cómo un cliente CDN puede añadir archivos a un contenedor de VoD. Cada archivo en un contenedor de VoD tiene parámetros a nivel de archivo adicionales que deben definirse. A continuación, se definirán tales campos.

En el punto de entrada, una vez descargado el contenido, se crea automáticamente un archivo requests.xml. Este archivo tiene metadatos asociados con cada archivo que un cliente CDN pone en el contenedor. Un proceso de monitorización busca la existencia del archivo requests.xml para las etapas de postprocesamiento comentadas anteriormente. Un cliente CDN puede sobrescribir cualquiera de los parámetros de contenedor para un archivo llamando

ES 2 397 911 A1

a la API de archivo usando una interfaz REST (o usando una interfaz fácil de usar) en el momento de cargar un archivo

o en cualquier momento después de esto. Hay parámetros de archivo adicionales que es necesario definir.

•: nombre: reqid, tipo: long, opcional: no. Este campo es un ID de transacción globalmente único.

•: nombre: method, tipo: string, opcional: no. Este campo identifica la acción asociada con un archivo en el contenedor. Los valores permitidos para esto son add_file (añadir archivo), remove file (eliminar archivo) y update_file (actualizar archivo) para añadir, eliminar y actualizar un archivo de contenido con una nueva versión respectivamente.

•: nombre: callbackurl, tipo: string, opcional: yes. Es el URL de retorno de llamada que un cliente CDN puede proporcionar a la infraestructura CDN. Este proceso de monitorización invocará este URL con un conjunto de pares name=value en la cadena de consulta una vez procesado el bloque xml.

•: nombre: callbackmethod, tipo: string, opcional: yes. Por defecto, se invoca el método GET. Un cliente puede decidir si quiere un POST en su lugar.

•: nombre: fileName, tipo: string, opcional: no. Este campo indica el nombre del archivo.

•: nombre: fileSize, tipo: long, opcional: no. Este campo indica el tamaño del archivo.

•: nombre: fileurl, tipo: string, opcional: yes. Este campo se usa cuando el cliente CDN quiere que la infraestructura CDN descargue contenido de servidores que forman parte de la infraestructura del cliente CDN.

•: nombre: username, tipo: string, opcional: yes. Este campo se usa sólo si el cliente CDN quiere que el cliente CDN descargue contenido de servidores que forman parte de la infraestructura del cliente CDN.

•: nombre: passwd, tipo: string, opcional: yes. Este campo se usa sólo si el cliente CDN quiere que el cliente CDN descargue contenido de servidores que forman parte de la infraestructura del cliente CDN.

•: nombre: filehash, tipo: string, opcional: yes. Este campo es el SHA1 del archivo de medios de contenido. El cliente CDN proporciona este valor. Esto permite a la infraestructura CDN garantizar la integridad de un archivo tras su descarga.

Una vez que el proceso de monitorización detecta que todos los archivos a los que se hace referencia en el archivo xml están presentes (y tienen el tamaño correcto), los archivos de mueven a otro directoria para su postprocesamiento. Esta etapa implica comprobar la consistencia de los archivos y si hay algún error.

Cuando se cargan archivos en un contenedor, los siguientes campos de metadatos heredados del contenedor también deben modificarse según sea necesario: enabled, startdate, enddate, geoloc, deliverytype, bandwidth, blacklist, whitelist y authentication.

Esto permite al propietario del contenido tener un control completo sobre el área geográfica en la que se distribuye el contenido, el modo de distribución y también el ancho de banda con el que debe distribuirse el archivo. El único requisito es que el ancho de banda a nivel de contenedor debe ser mayor o igual que el ancho de banda fijado a nivel de archivo.

Además, el campo geoloc puede modificarse a nivel de archivo para garantizar que los países en los que es válido un archivo son un subconjunto de los países en los que es válido un contenedor. Por tanto, si un contenedor es válido en [es, br, us, uk], cada archivo en un contenedor de este tipo debe se válido en un subconjunto de [es, br, us, uk].

El mecanismo de interacción basado en archivos continúa tal como sigue. El archivo es una recopilación de bloques <cdnrequest> xml. Cada bloque tiene un valor para method = “add_file | remove_file | update_file”. Un usuario se registra en la cuenta FTP y carga un archivo denominado requests.xml. En primer lugar se considera el caso de que el cliente CDN carga requests.xml y el archivo de contenido. El formato del archivo requests.xml es:

<add_file>

<fileName>demo-output.flv</name>

ES 2 397 911 A1

<validfrom>2010-03-01T00:00:00</validfrom> <validuntil>2010-12-31T23:59:59</validuntil> <filehash>214a1e4eade7b9662184e24377256706dd81e859</filehash> <callbackurl>http://cdncustomer.com/callmehere</callbackurl> <callbackmethod>GET</callbackmethod>

</add_file> Una vez procesado el contenido cargado, se asigna a un URL de la CDN. En el ejemplo anterior, si el ID de contenedor del usuario era 87, el URL de contenido es http://87.t-cdn.net/87/demo-output.flv. Una vez que sucede esto, se ejecuta un retorno de llamada para el URL http://cdncustomer.com/callmehere/result?reqid=100&name=demooutput.flv&result=0. A continuación, el inventor considera el caso de que el usuario cargue mediante FTP el archivo requests.xml

solo en el contenedor. En tal caso, el archivo requests.xml se escribirá como:  <add_file>

<reqid>100</reqid> <fileName>demo-output.flv</name> <fileSize>2941018</fileSize> <enabled>true</enabled> <validfrom>2010-03-01T00:00:00</validfrom> <validuntil>2010-12-31T23:59:59</validuntil> <fileurl> http://www.cdncustomer.com/video/</fileurl> etc.

</add_file> El punto de entrada descargará entonces el archivo desde el servidor web del cliente CDN. El punto de entrada construirá el URL a partir de los parámetros fileurl y fileName. Una vez que el punto de entrada ha descargado el archivo, se procesa y se le asigna un URL CDN al igual que antes. El procesamiento del archivo (después de descargarse) genera hashes para cada archivo a nivel de bloque (1 Kbyte) de modo que puede verificarse la integridad del contenido a nivel de bloque en cualquier nodo de extremo antes de distribuir el contenido. Estos hashes (a nivel de bloque) se almacenan también en el contenedor del cliente CDN. El servidor original en la CDN tiene todos los archivos que forman parte de requests.xml. Anteriormente se han descrito dos métodos mediante los cuales un cliente puede descargar contenido a la infraestructura CDN en los que el

proveedor CDN gestiona los contenedores. Los métodos remove_file y update_file se definen tal como sigue.  <remove_file>

<reqid>101</reqid> <fileName>file1.flv</fileName> <callbackurl>http://cdncustomer.com/callmehere</ callbackurl> <callbackmethod>GET</callbackmethod>

</remove_file>

ES 2 397 911 A1

En este caso, file1.flv debe eliminarse del contenedor. Una vez que ha tenido lugar la eliminación del archivo del contenedor, se ejecuta un retorno de llamada en el nodo de extremo con el siguiente URL: http://cdncustomer.com/callmehere/result?reqid=101&name=file1.flv&result=0.

Finalmente, observando el formato del método update_file debe observarse que la versión del propio contenido no puede actualizarse. Más bien, esto es una manera de actualizar los parámetros opcionales de un archivo. Este método puede usarse si el contenido puede mostrarse en otros países, con una mayor o menor duración. Obsérvese en este ejemplo que la validez de demo-output.flv cambió de 2010-12-31 a 2011-12-31.

<update_file>

<fileName>demo-output.flv</fileName>

</update_file>

Tras procesar los archivos, el proceso de monitorización genera un archivo responses.xml en el mismo directorio.

Hay parámetros de archivo adicionales que es necesario definir. Estos parámetros son:

•: nombre: status, tipo: integer, opcional: no. Cada método en el archivo requests.xml tendrá un estado correspondiente en el archivo responses.xml. Un código de estado 0 indica éxito, mientras que un código de estado de 1 indica fallo.

•: nombre: cdnurl, tipo: integer, opcional: no. Este campo indica al cliente CDN el URL que debe usar el cliente cuando hace referencia al archivo de contenido que está ahora en la infraestructura CDN.

<name>output.flv</name>

</addfile>

El cliente CDN puede descargar el archivo responses.xml cuando está disponible. Debe observarse que el ID de respuesta es el mismo que el ID en el archivo requests.xml para indicar que el archivo responses.xml es en respuesta a requests.xml.

La figura 1 resume las interacciones entre un cliente CDN y la infraestructura CDN del proveedor de servicio. Este ejemplo tiene cuatro nodos de extremo. Un cliente CDN puede crear contenedores y modificar metadatos para el contenedor en el punto de entrada. Posteriormente, la infraestructura CDN del proveedor de servicio mantiene la consistencia propagando los cambios en un contenedor de un cliente a los nodos de extremo. La sincronización del contenedor y los metadatos entre el punto de entrada y el nodo de extremo se produce en unos pocos segundos. De manera similar, cualquier cambio en los metadatos de un archivo tras cargar un archivo se refleja en los nodos de extremo en unos pocos segundos.

Diferentes componentes de la CDN, el rastreador y el punto de entrada, proporcionan los metadatos de un contenedor y los archivos en un contenedor a un proxy. Los metadatos que guían la distribución de contenido entran en juego en los nodos de extremo. En este caso se describen las etapas mostradas en la figura 1:

•: El usuario final 1 (EU1) realiza una petición de contenido y la infraestructura CDN elige el nodo de extremo 1 como el mejor colocado para proporcionar el contenido. Por tanto, EU1 intenta conectarse directamente con el nodo de extremo 1 (EP1). De manera similar, EU2 solicita contenido de EP3.

•: El EP1 no tiene el contenido localmente. Como tampoco lo tienen los nodos de su entorno, envía una petición de contenido para el contenido solicitado al servidor original.

•: El servidor original envía el contenido solicitado a EP1 (el servidor original siempre contiene una copia maestra del contenido). Las etiquetas 2 y 3 no se muestran para EP3 puesto que tiene una copia del contenido solicitado localmente.

•: Los nodos de extremo EP1 y EP3 proporcionan contenido a EU1 y EU2 respectivamente. El contenido proporcionado se guía mediante los parámetros de metadatos del archivo solicitado y del contenedor.

ES 2 397 911 A1

Fijar QoS:

La flexibilidad del método de la invención permite fijar los parámetros a nivel de contenedor por cliente. Puede fijarse:

1.: La QoS de un cliente. Pueden fijarse diferentes niveles de QoS para diferentes clientes.

2.: La QoS para un contenedor de cliente.

3.: Fijar la QoS para archivos individuales en un contenedor.

Ubicación física del contenedor

Un cliente CDN en cualquier ubicación puede crear un contenedor de distribución de contenido. Una vez creado un contenedor y cargado contenido en el servidor original de la infraestructura CDN, los metadatos se asocian con el contenedor. Sin embargo, esto no tiene ningún significado hasta que un usuario final solicita contenido que está en la CDN de proveedor de servicio. Una vez que surge un nodo de extremo, los metadatos de contenido se transmiten mediante proxy al nodo de extremo. Cuando un nodo de extremo obtiene una petición de contenido de un usuario final, el nodo de extremo obtiene en primer lugar el contenido del servidor original (y en algunos casos, los nodos de su entorno en el mismo centro de datos). El nodo de extremo proporciona entonces la petición de contenido. El contenido proporcionado se guía mediante los metadatos del contenedor y del archivo solicitado.

Cualquier cambio en los metadatos del contenedor mediante un cliente CDN se refleja en los nodos de extremo en el plazo de unos pocos segundos.

El tamaño de contenedor como indicador de almacenamiento en caché:

El tamaño del contenedor es un parámetro muy importante a la hora de determinar cómo trata la infraestructura CDN un contenedor.

El cliente CDN puede designar un contenedor como pequeño. En este caso, el objeto de contenedor tiene un tamaño inferior a un megabyte.

Un cliente CDN también puede designar un contenedor como grande. Los contenedores grandes tienen un objeto de contenedor que tiene un tamaño superior a un megabyte.

Normalmente, los objetos de contenedor grandes se distribuyen a través de una descarga HTTP, mientras que los objetos pequeños pueden almacenarse en caché mediante la infraestructura CDN.

Seguridad:

El proceso de monitorización en el punto de entrada es responsable de mantener un archivo filelist.xml que está asociado con cada contenedor. Este archivo contiene el nombre, tamaño y SHA1 de cada archivo en el contenedor. Puesto que el rastreador se sincroniza con el punto de entrada frecuentemente, también mantiene el archivo filelist.xml para cada contenedor. Puesto que los nodos de extremo también se sincronizan con el rastreador regularmente, también tienen una copia del archivo xml.

Si un usuario final realiza una petición de contenido falso, el nodo de extremo comprueba en primer lugar si el contenido forma parte de la infraestructura CDN. En caso contrario, se termina la petición. Esto garantiza que las peticiones de contenido no afectan a los nodos de extremo que proporcionan contenido a otros usuarios finales. Esto protege la infraestructura CDN frente a tales ataques.

Esta invención garantiza la integridad de contenido tanto a nivel de bloque como de archivo.

En resumen, se ha visto cómo se asocian los metadatos con un contenedor cuando se crea un contenedor. También se ha visto cómo un contenedor de cliente gestionado puede obtener los archivos de contenido o bien mediante FTP o bien permitiendo que la infraestructura CDN descargue el contenido. Los metadatos asociados con cada archivo pueden sobrescribir los metadatos a nivel de contenedor, proporcionando al cliente CDN un control de grano fino sobre cómo deben manipularse los archivos en un contenedor.

ES 2 397 911 A1

Al proporcionar inteligencia a los contenedores, los clientes pueden usarla de una amplia variedad de maneras en la infraestructura CDN, fijación de QoS, almacenamiento en caché, seguridad, geolocalización y validez (duración de tiempo durante la que es válida el contenido) del contenido, tasa de transmisión a la que puede proporcionarse cada archivo de contenido.

Ventajas de la invención

Esta invención proporciona las siguientes ventajas:

•: Un cliente CDN puede asignar metadatos al contenedor inteligente del proveedor de servicio únicamente con el propósito de distribuir contenido.

•: Un cliente CDN puede asignar metadatos a los archivos en un contenedor o bien cargando un archivo xml que tenga valores para todos los campos de interés para el cliente o bien a través de una pantalla de visualización fácil de usar (en forma de una interfaz conveniente) para asignar metadatos a cada archivo en el contenedor.

•: El cliente CDN tiene un control completo sobre los contenedores que creó y cualquier contenido que ocupe los contenedores. Por tanto, un cliente CDN puede fijar la granularidad a nivel de archivo para controlar el acceso al contenido en un contenedor. Los parámetros a nivel de contenedor pueden sobrescribirse mediante los parámetros a nivel de archivo. Esto permite proporcionar dos archivos en el mismo contenedor a diferentes tasas de transmisión (uno puede ser un archivo HD, y por tanto es necesario proporcionarlo a una tasa de transmisión superior).

•: Cualquier cambio en los metadatos de un contenedor de cliente o archivo en el contenedor se realiza en el punto de entrada. Este cambio se transmite mediante proxy a los nodos de extremo en el plazo de unos pocos segundos. Los metadatos sólo son significativos en los nodos de extremo CDN.

1.: Una consecuencia de esto es que un cliente CDN puede hacer cambios sobre la marcha en la manera en que se distribuye el contenido. Por tanto, si un cliente quisiera distribuir contenido en España, el cliente simplemente añade “es” al campo geoloc del archivo.

2.: Un cliente CDN puede decidir cuándo está habilitado el contenido en un contenedor y cuándo está deshabilitado. Por consiguiente, el nodo de extremo proporcionará contenido sólo si el contenedor (y el archivo) está habilitado.

•: Al contenedor se le asignan parámetros que indican a un operador CDN si el contenedor contiene contenido en tiempo real o vídeo bajo demanda. Esto es esencial ya que un contenedor de tiempo real se trata de manera diferente a un contenedor de VoD.

•: Un cliente CDN puede decidir para qué área(s) geográfica(s) puede ponerse a disposición el contenido en un contenedor.

•: Un proveedor de servicio CDN puede proporcionar mecanismos que permiten ofrecer a los contenedores de cada cliente diferentes niveles de QoS.

•: Un proveedor de servicio CDN puede proporcionar mecanismos que permitan tratar de diferente manera a contenedores de dos clientes diferentes.

•: Los metadatos permiten la colocación previa de contenido de modo que se pone a disposición en los nodos de extremo de la región geográfica unas pocas horas antes de que el contenido se emita en tiempo real (la petición de los usuarios finales para tal contenido es válida).

•: El contenedor inteligente también ayuda a la CDN del proveedor de servicio a soportar una variedad de mecanismos de autenticación incluyendo un mecanismo de autenticación rápida con propietarios del contenido.

•: El contenedor contiene parámetros que indican a un operador CDN la tasa de transmisión a la que debe proporcionarse el contenido en un contenedor a un usuario final. Los parámetros a nivel de archivo indican a un operador CDN si dos archivos en el mismo contenedor deben proporcionarse a diferentes tasas de transmisión.

•: El archivo filelist.xml protege la infraestructura CDN frente a ataques contra la seguridad en los que usuarios finales solicitan contenido falso.

•: Este sistema tiene la capacidad de proporcionar la integridad del contenido a nivel de bloque y a nivel de archivo, garantizando que el nodo de extremo verifica el contenido a nivel de bloque antes de distribuirlo al usuario final.

ES 2 397 911 A1

• El tamaño de un contenedor proporciona al proveedor de servicio CDN pistas sobre si almacenar en 5 caché el contenido del contenedor o no. Esta invención proporciona un mecanismo dentro de los metadatos que permite a la infraestructura CDN del proveedor de servicio tomar decisiones inteligentes sobre distribuir el contenido desde el contenedor de un cliente. Un experto en la técnica puede introducir cambios y modificaciones en las realizaciones descritas sin apartarse del alcance de la invención tal como se define en las reivindicaciones adjuntas. 10 SIGLAS ADSL Asymmetric Digital Subscriber Line; Línea de abonado digital asimétrica CDN Content Distribution Network; Red de distribución de contenido DNS Domain Name Service; Servicio de nombres de dominio PoP Point of Presence; Punto de presencia 15 TLD Top Level Domain; Dominio de nivel superior FTP File Transfer Protocol; Protocolo de transferencia de archivos

HTTP HyperText Transfer Protocol; Protocolo de transferencia de hipertexto ARL Akamai Resource Locator; Localizador de recursos Akamai

ES 2 397 911 A1

BIBLIOGRAFÍA

5 10: [1] [2] [3] [4] [5] Akamai: http://www.akamai.com Servicios web de Amazon: http://aws.amazon.com Amazon Simple Storage Service (S3) Developer’s guide (API Version 2006-03-01), http://docs.amazonwebservices.com/AmazonS3/latest/dev/ Amazon Cloudfront. Developer’s guide (API Version 2010-11-01). Disponible http://docs.amazonwebservices.com/AmazonCloudFront/latest/DeveloperGuide/ Synchronized Multimedia Integrated Language.http://en.wikipedia.org/wiki/Synchronized_Multimedia_Integration_Language en en En

ES 2 397 911 A1

Claims

REIVINDICACIONES

1.

Método para la distribución de contenido en una red de distribución de contenido, o CDN, que comprende usar contenedores como compartimentos lógicos para contener archivos de contenido, y asociar metadatos de sistema de archivos a dichos contenedores, estando el método caracterizado porque comprende además asociar metadatos de distribución de contenido a dichos contenedores, incluyendo dichos metadatos de distribución de contenido atributos o propiedades para uso específico en un sistema CDN, y usar dichos metadatos de distribución de contenido para gestionar la distribución de contenido en un servicio CDN.
2.

Método según la reivindicación 1, que comprende generar automáticamente dichos metadatos de sistema de archivos cuando se crea un contenedor o un archivo de contenido en un contenedor.
3.

Método según la reivindicación 1 ó 2, que comprende asociar dichos metadatos de sistema de archivos y dichos metadatos de distribución de contenido con cada archivo de cada contenedor, incluyendo dichos archivos de contenido.
4.

Método según la reivindicación 1, 2 ó 3, que comprende asociar dichos metadatos de sistema de archivos y dichos metadatos de distribución de contenido con cada contenedor.
5.

Método según cualquiera de las reivindicaciones anteriores, que comprende crear dichos contenedores con distribución de contenido como la única aplicación.
6.

Método según cualquiera de las reivindicaciones anteriores, que comprende llevar a cabo dicha distribución de contenido a través de dicha red de distribución de contenido, o CDN, a un usuario final, usando dichos metadatos asociados para guiar dicha distribución de contenido.
7.

Método según la reivindicación 6, que comprende añadir y/o modificar, un cliente CDN, metadatos asociados con cada archivo y/o cada contenedor.
8.

Método según la reivindicación 7, en el que dicha modificación de los metadatos incluye sobrescribir los metadatos a nivel de contenedor con metadatos asociados con cada archivo, para proporcionar al cliente CDN un control fino para tratar archivos en cada contenedor.
9.

Método según cualquiera de las reivindicaciones 7 u 8, que comprende asignar, dicho cliente CDN, metadatos a los archivos en un contenedor o bien:

-

cargando un archivo xml que define parámetros que tienen el efecto de asignar metadatos a cada archivo en el contenedor;

o bien

-

cargar archivos de contenido en un contenedor y usar una interfaz de usuario para asociar metadatos para cada archivo cargado;

o bien

-

proporcionar el URL del servidor original en el servidor web del cliente CDN para descargar el archivo y asignar los metadatos a nivel de archivo asociados con la ayuda de una interfaz de usuario.
10.

Método según cualquiera de las reivindicaciones 6 a 9, que comprende realizar, el cliente CDN, cualquier cambio en los metadatos de un contenedor o archivo en el contenedor en el punto de entrada de dicha CDN, y transmitir mediante proxy dicho cambio a los nodos de extremo de la CDN en el plazo de unos pocos segundos, siendo significativos dichos metadatos sólo en los nodos de extremo de la CDN.
11.

Método según la reivindicación 10, que comprende realizar, el cliente CDN, dichos cambios de metadatos para cambiar la manera en la que se distribuye el contenido sobre la marcha.
12.

Método según la reivindicación 11, que comprende proporcionar, un nodo de extremo CDN, contenido asociado con un contenedor sólo si el contenedor y su archivo o archivos están habilitados para la distribución por el cliente CDN a través de metadatos correspondientes.
13.

Método según la reivindicación 10, 11 ó 12, que comprende: al recibir una petición de contenido de un usuario final, proporcionar el nodo de extremo el contenido especificado en la petición y el tipo de archivo y guiar dicha distribución de archivo mediante los metadatos de distribución de contenido de dicho contenedor.
14.

Método según cualquiera de las reivindicaciones anteriores, que comprende asociar metadatos a un contenedor que indican el tipo de contenido que contiene.
15.

Método según la reivindicación 14, en el que dicho tipo de contenido de contenedor es uno de o bien contenido de vídeo bajo demanda o bien contenido para transmisión en flujo continuo en tiempo real.

ES 2 397 911 A1
16.

Método según cualquiera de las reivindicaciones 6 a 15, que comprende asociar, dicho cliente CDN y/o un

proveedor de servicio CDN, metadatos de sistema de archivo y de distribución de contenido a contenedores y/o

a sus archivos con el fin de al menos uno de:

- decidir para qué área(s) geográfica(s) puede ponerse a disposición el contenido en dicho contenedor;

5

- proporcionar mecanismos que permitan ofrecer a los contenedores de cada cliente diferentes niveles de QoS;

- proporcionar mecanismos que permitan tratar de diferente manera contenedores de dos clientes diferentes;

- el preposicionamiento de contenido de modo que se pone a disposición en los nodos de extremo de la CDN

de una región geográfica antes de solicitar dicho contenido;

- colaborar con la CDN del proveedor de servicio para soportar al menos un mecanismo de autenticación;

10

- indicar a un operador CDN la tasa de transmisión a la que debe proporcionarse el contenido en un contenedor

a un usuario final;

-proteger la infraestructura CDN frente a ataques contra la seguridad en los que usuarios finales solicitan

contenido falso; y

15

- proporcionar integridad de contenido a nivel de bloque y a nivel de archivo, garantizando que el nodo de extremo verifica el contenido a nivel de bloque antes de distribuirlo al usuario final.
17.

Método según cualquiera de las reivindicaciones 6 a 16, que comprende decidir, dicho proveedor de servicio

CDN, dependiendo del tamaño del contenedor, si almacenar en caché o no el contenido de un contenedor.

ES 2 397 911 A1

Figura 1

OFICINA ESPAÑOLA DE PATENTES Y MARCAS

N.º solicitud: 201130755

ESPAÑA

Fecha de presentación de la solicitud: 12.05.2011

Fecha de prioridad:

INFORME SOBRE EL ESTADO DE LA TECNICA

51 Int. Cl. : Ver Hoja Adicional

DOCUMENTOS RELEVANTES

Categoría

56 Documentos citados Reivindicaciones afectadas

X

Amazon Simple Storage Service -Developer Guide", Recuperado de Internet: URL: http://awsdocs.s3.amazonaws.com/ [recuperado 19.02.2013] Secciones "Overview of Amazon S3" “Amazon S3 Concepts” “Bucket Configuration Options”. 1-17

X

US 2003110503 A1 (PERKES RONALD M) 12.06.2003, párrafos [35,43,48,58,226-230,247]; figuras 13,14. 1-17

A

WO 2008016694 A2 (JITTR NETWORKS INC et al.) 07.02.2008, todo el documento. 1-17

Categoría de los documentos citados X: de particular relevancia Y: de particular relevancia combinado con otro/s de la misma categoría A: refleja el estado de la técnica O: referido a divulgación no escrita P: publicado entre la fecha de prioridad y la de presentación de la solicitud E: documento anterior, pero publicado después de la fecha de presentación de la solicitud

El presente informe ha sido realizado • para todas las reivindicaciones • para las reivindicaciones nº:

Fecha de realización del informe 25.02.2013

Examinador J. Santaella Vallejo Página 1/4

INFORME DEL ESTADO DE LA TÉCNICA

Nº de solicitud: 201130755

CLASIFICACIÓN OBJETO DE LA SOLICITUD

H04N21/218 (2011.01) H04N21/231 (2011.01) H04N21/232 (2011.01) H04N21/8355 (2011.01) H04N21/84 (2011.01)

Documentación mínima buscada (sistema de clasificación seguido de los símbolos de clasificación)

H04N

Bases de datos electrónicas consultadas durante la búsqueda (nombre de la base de datos y, si es posible, términos de búsqueda utilizados)

INVENES, EPODOC

Informe del Estado de la Técnica Página 2/4

OPINIÓN ESCRITA

Nº de solicitud: 201130755

Fecha de Realización de la Opinión Escrita: 25.02.2013

Declaración

Novedad (Art. 6.1 LP 11/1986)

Reivindicaciones 2-17 Reivindicaciones 1 SI NO

Actividad inventiva (Art. 8.1 LP11/1986)

Reivindicaciones Reivindicaciones 1-17 SI NO

Se considera que la solicitud cumple con el requisito de aplicación industrial. Este requisito fue evaluado durante la fase de examen formal y técnico de la solicitud (Artículo 31.2 Ley 11/1986).

Base de la Opinión.-

La presente opinión se ha realizado sobre la base de la solicitud de patente tal y como se publica.

Informe del Estado de la Técnica Página 3/4

OPINIÓN ESCRITA

Nº de solicitud: 201130755

1. Documentos considerados.-

A continuación se relacionan los documentos pertenecientes al estado de la técnica tomados en consideración para la realización de esta opinión.

Documento

Número Publicación o Identificación Fecha Publicación

D01

Amazon Simple Storage Service -Developer Guide", Recuperado de Internet: URL: http://awsdocs.s3.amazonaws.com/ [recuperado 19.02. 2013] Secciones "Overview of Amazon S3" “Amazon S3 Concepts” “Bucket Configuration Options”.

D02

US 2003110503 A1 (PERKES RONALD M) 12.06.2003

D03

WO 2008016694 A2 (JITTR NETWORKS INC et al.) 07.02.2008
2. Declaración motivada según los artículos 29.6 y 29.7 del Reglamento de ejecución de la Ley 11/1986, de 20 de marzo, de Patentes sobre la novedad y la actividad inventiva; citas y explicaciones en apoyo de esta declaración

La invención reivindicada presenta un método que asocia metadatos al sistema de archivos de contenedores en una red CDN. El sistema de archivos de metadatos se genera cuando el archivo del contenedor o el contenido son creados siendo posible modificarlo. La distribución de contenido de metadatos se compone con atributos o propiedades utilizadas en el sistema de CDN utilizando los metadatos para su gestión.

El documento del estado de la técnica más próximo a la invención es D01 y divulga la guía de desarrollador para Amazon S3 (Simple Storage Service) siendo un servicio de almacenamiento web en línea ofrecido que utiliza la propia red CDN de Amazon, para ello explica cómo se utilizan los contenedores y los metada datos asociados a los archivos y los contenedores.

Para mayor claridad, y en la medida de lo posible, se emplea la misma redacción utilizada en la reivindicación 1. Las referencias entre paréntesis corresponden al D01. Las características técnicas que no se encuentran en el documento D01 se indican entre corchetes.

Reivindicación 1

Método para distribución de contenido en una red de distribución de contenido, o CDN, que comprende usar contenedores como compartimentos lógicos para contener archivos de contenido, y asociar metadatos de sistema de archivos a dichos contenedores (“Overview of Amazon S3”, página 5 y “Amazon S3 Concepts”, página 6), estando el método caracterizado porque comprende además asociar metadatos de distribución de contenido a dichos contenedores, incluyendo dichos metadatos de distribución de contenido atributos o propiedades para uso específico en un sistema CDN, y usar dichos metadatos de distribución de contenido para gestionar la distribución de contenido en un servicio CDN (“Bucket Configuration Options”, página 38).

Las características de la reivindicación primera ya son conocidas del documento D01. Por lo tanto a la luz de D01, la invención no es nueva tal como se establece en los artículos 6 y 8 de la Ley de Patentes 1986

Reivindicaciones 2-17 A la vista del documento citado D01 el resto de las reivindicaciones 2-17 son cuestiones prácticas, las cuales son conocidas previamente del documento citado para un experto en la materia o están contenidas dentro del documento D01.

Por lo tanto las reivindicaciones 2-17 son nuevas pero carecen de actividad inventiva tal como se establece en los artículos 6 y 8 de la Ley de Patentes 1986.

Informe del Estado de la Técnica Página 4/4