ES2711873T3 - Sistema de DMR mejorado - Google Patents

Abstract

Un método de gestión de derechos digitales, en el que acceso a una pieza de contenido se concede de acuerdo con una licencia propiedad de un propietario de licencia a un cliente que es un miembro de un dominio, conforme a una etapa de verificación satisfactoria de que existe una relación de pertenencia entre el cliente y el dominio como se refleja en una primera variable de estado mantenida tanto por el cliente como por un controlador del dominio, requiriéndose la presencia de una primera variable de estado válida para verificar satisfactoriamente que la relación de pertenencia existe, y que existe una relación de asociación entre el propietario de licencia y el dominio como se refleja en una segunda variable de estado mantenida tanto por el controlador del dominio como por un controlador de propietario de licencia asociado con el propietario de licencia, requiriéndose la presencia de una segunda variable de estado válida para verificar satisfactoriamente que la relación de asociación existe, comprendiendo el método revocar la relación de pertenencia ejecutando un protocolo en línea entre el controlador del dominio y el cliente después de la que ambos eliminan la primera variable de estado, y revocar la relación de asociación ejecutando un protocolo en línea entre el controlador de propietario de licencia y el controlador del dominio después de la cual el controlador del dominio elimina la segunda variable de estado y después de la cual la administración de estado relacionada con el dominio se propaga al cliente de modo que la segunda variable de estado se elimina por el cliente.

Description

DESCRIPCION

Sistema de DMR mejorado

Introduccion

En anos recientes, el numero de sistemas de proteccion de contenido disponibles ha crecido rapidamente. Algunos de estos sistemas unicamente protegen el contenido contra copia no autorizada, mientras otras restringen la capacidad del usuario para acceder al contenido. Estos sistemas se denominan a continuacion como sistemas de Gestion de Derechos Digitales (DRM).

Los consumidores quieren disfrutar del contenido sin molestias y con tan pocas limitaciones como sea posible. Quieren conectar sus dispositivos para habilitar todo tipo de diferentes aplicaciones y acceso facil a cualquier tipo de contenido. Tambien quieren ser capaces de compartir/transferir contenido en su entorno domestico sin limitaciones. Dominios autorizados

El concepto de Dominios Autorizados (AD) intenta encontrar una solucion para servir tanto a los intereses de los propietarios del contenido (que quieren proteccion de su propiedad intelectual) y los consumidores de contenido (que quieren uso sin restricciones del contenido). El principio basico es tener un entorno de red controlado en el que el contenido puede usarse con relativa libertad siempre que no cruce el lfmite del dominio autorizado. Tfpicamente, dominios autorizados se centran alrededor del entorno domestico, tambien denominado como redes domesticas. Por supuesto, tambien son posibles otros contextos. Un usuario podna por ejemplo coger un dispositivo portatil para audio y/o video con una cantidad limitada de contenido con el en un viaje, y usar el mismo en su habitacion de hotel para acceder o descargar contenido adicional almacenado en su sistema de audio y/o video personal en casa. Incluso aunque el dispositivo portatil esta fuera la red domestica, es una parte del dominio autorizado del usuario. De esta manera, un Dominio Autorizado (AD) es un sistema que permite acceso a contenido mediante dispositivos en el dominio, pero no por ningun otro.

Dominios autorizados necesitan abordar cuestiones tal como identificacion de dominio autorizado, registro de dispositivo, verificacion de dispositivo, registro de derechos, verificacion de derechos, registro de contenido, verificacion de contenido, asf como gestion de dominio. Para una introduccion mas extensiva del uso de un dominio autorizado, etc., vease S.A.F.A. van den Heuvel, W. Jonker, F.L.A.J. Kamperman, P.J. Lenoir, "Secure Content Management in Authorised Dominios", Philips Research, Los Pafses Bajos, publicacion de conferencia de IBC 2002, paginas 467-474, celebrada el 12-16 de septiembre de 2002 o Paul Koster, Frank Kamperman, Peter Lenoir y Koen Vrielink, "Identity based DRM: Personal Entertainment Domain", Conferencia sobre Comunicaciones y Seguridad Multimedia (CMS) 2005, LNCS 3677, pp. 42-54, Salzburgo, Austria, 19-21 de septiembre de 2005.

Algunas formas de dominio autorizado

Existen diversas propuestas que implementan el concepto de dominios autorizados hasta cierto punto. En asf llamados DA basados en dispositivo, el dominio se forma mediante un conjunto espedfico de dispositivos de hardware o aplicaciones de software (denominados colectivamente como clientes en lo sucesivo) y contenido. Un gestor de dominio o controlador, que puede ser uno o mas de los clientes, una tarjeta inteligente u otro dispositivo, controla que clientes pueden unirse al dominio. Unicamente se permite que el conjunto espedfico de clientes en el dominio (los miembros) haga uso del contenido de que dominio, por ejemplo para abrir, copiar, reproducir o exportar el mismo. Ejemplos de tales DA basados en dispositivo se proporcionan en la solicitud de patente internacional WO 03/098931, solicitud de patente internacional w O 2005/088896 y solicitud de patente internacional WO 04/027588. Un tipo de DA basado en dispositivo permite que un conjunto de clientes vinculado a un dominio acceda a contenido vinculado a ese dominio. Esta doble vinculacion garantiza que todos los miembros pueden acceder al contenido. Esta estructura se establece a menudo implementando las vinculaciones a traves de una clave secreta compartida. Esta clave se elige por el gestor de dominio y distribuye a todos los miembros. Cuando contenido se vincula al dominio, la licencia se enlaza criptograficamente al dominio por medio de encriptacion con la clave compartida. Como alternativa el contenido puede vincularse directamente a un cliente y los clientes permanecen vinculados al AD.

Otro tipo de AD es el asf llamado AD basado en persona, en el que el dominio se basa en personas en lugar de dispositivos. Un ejemplo de un sistema de este tipo se describe en la solicitud de patente internacional WO 04/038568 en la que contenido se acopla a personas, que a continuacion se agrupan en un dominio.

Un asf llamado sistema de DRM basado en Dominio Autorizado Hfbrido relaciona contenido a un grupo que puede contener dispositivos y personas. Este grupo habitualmente se limita a un nucleo familiar, de tal forma que: 1. puede verse contenido en cualquiera de los miembros que pertenecen al nucleo familiar (por ejemplo TV en salon, TV en habitacion, PC)

2. puede verse contenido por cualquiera de los usuarios que pertenecen al nucleo familiar despues de que ellos mismos se han autenticado en cualquier cliente (tal como una television en una habitacion de hotel). Tal autenticacion normalmente implica un dispositivo de autenticacion de usuario tal como una tarjeta inteligente.

Ejemplos de sistemas de AD hforidos pueden encontrarse en la solicitud de patente internacional WO 2005/010879 y en la solicitud de patente internacional WO 2005/093544.

Hablando en general, un AD comprende un grupo de clientes. Un cliente hablando en general es una entidad funcional que puede adquirir y analizar licencias y enlaces para el proposito de conseguir acceso a una instancia de contenido basandose en los derechos expresados en esas licencias y enlaces. Habitualmente un cliente se incorpora como una o mas aplicaciones de software y/o componentes de hardware. Por ejemplo, un cliente puede proporcionarse como una aplicacion de software en un dispositivo tal como un telefono movil o reproductor de musica portatil. Un cliente normalmente comprende un procesador para realizar las operaciones necesarias y esta equipado con una memoria para almacenar contenido y/o instrucciones a ejecutar por el procesador. Clientes que se comprenden en el AD se denominan como Clientes Miembro o solo Miembros para abreviar.

Contenido se hace disponible a los Clientes Miembro mediante uno o mas Propietarios de Licencia (LO). Un propietario de licencia hablando en general es una entidad que es representativa de un usuario en un entorno de dominio. Un usuario es un individuo que interactua con el sistema. Pueden concederse derechos a un usuario para una instancia de contenido. Una concesion de licencia de este tipo puede representarse en el sistema proporcionando una licencia que enlaza (una instancia espedfica de) contenido al propietario de licencia. Un propietario de licencia puede implementarse proporcionando informacion en una estructura de datos, registro en una base de datos u objeto de software. La relacion con el usuario no se define explfcitamente en el sistema, pero por ejemplo puede realizarse por el usuario que tiene un dispositivo que contiene esa informacion.

Una licencia contiene permisos y restricciones que son espedficas para el artfculo de contenido implicado. Observese que puede haber muchas, por ejemplo 15.000, licencias en una configuracion de dominio y que la emision y comunicacion de las mismas a clientes puede tomar una cantidad significativa de recursos.

Un cliente que pretende acceder una pieza de contenido debe ser autorizado para hacerlo. Para determinar si un cliente esta autorizado, debe probarse que:

• Un propietario de licencia "posee" el derecho para acceder a una pieza de contenido, y

• Ese propietario de licencia se asocia con un dominio, y

• El cliente es un miembro de ese dominio.

En otras palabras, los propietarios de licencia debenan tener el derecho de acceder a ese contenido y debenan asociarse con el dominio. La capacidad para acceder a contenido por un cliente implica que toda la cadena de autorizacion Cliente ^ Dominio ^ Propietario de licencia ^ Contenido esta en su lugar y que cada relacion es valida. Cambios hechos en una configuracion establecida de relaciones puede requerir que se invaliden las relaciones para preservar la consistencia. En un sistema particionado, todas las entidades en la cadena pueden desplegarse en diferentes anfitriones que no necesitan estar conectados entre sf en todo momento.

La Figura 1 ilustra esquematicamente una cadena de autorizacion de este tipo desde el cliente hasta el contenido en la que cada relacion puede tener una multiplicidad mayor de 1 en cada direccion, como se indica mediante el sfmbolo '*'. Las relaciones entre las entidades Cliente, Dominio, Propietario de Licencia y Contenido en una configuracion de dominio puede expresarse en y calificarse mediante una certificacion, en ocasiones tambien denominado como un certificado (digital). Pueden usarse las siguientes certificaciones:

• El derecho que un propietario de licencia espedfico tiene sobre una pieza de contenido se expresa en una licencia que hace referencia al propietario de licencia asf como la pieza de contenido implicada. Una licencia se realiza habitualmente como un objeto firmado digitalmente que comprende la informacion pertinente en un formato legible por maquina. Una licencia de este tipo tambien incluye los permisos espedficos y reglas de restriccion expresadas en codigo de control ejecutable, almacenadas en un asf llamado objeto de control en la licencia, para evaluarse en el momento que se desea el acceso al contenido (observese que permisos y restricciones tambien podnan representarse mediante un lenguaje de derechos formal como por ejemplo XrML). Un permiso, en un modelo de concesion positiva como usamos en este documento, es un derecho individual, por ejemplo "Reproducir" o "Copiar", que puede limitarse mediante una o mas restricciones, por ejemplo "unicamente 10 veces" o "no antes de 20:00 pm" o "unicamente en sabado". Una restriccion usada en combinacion con un permiso proporciona una condicion que limita el uso de un permiso. Cada permiso puede tener diferentes restricciones. Observese que cada licencia tiene su propio conjunto de permisos y restricciones para esos permisos (en un control). El proveedor de servicio de contenido original define los permisos, ampliados posiblemente con un numero de restricciones, en una licencia. El usuario del sistema, un consumidor, podna desear anadir adicionalmente restricciones de limitacion a la licencia para su uso en "su" dominio. El proveedor de servicio de contenido original no establece por ejemplo restricciones de control parental, sino que el propietario de licencia que publica su contenido adquirido en un dominio puede querer hacerlo. Como un ejemplo un propietario de licencia define un numero de artfculos de contenido que no debenan estar accesibles antes de 22:00 pm, o que los artfculos de contenido no son accesibles sin alguna autenticacion apropiada del usuario que opera un cliente. Esto conduce a diferentes areas de control: una para el proveedor de servicios y una para el propietario de licencia (usuario) con caractensticas ligeramente diferentes. Es improbable que los ajustes del proveedor de servicios cambien; la licencia se revocara en su totalidad cuando se necesite, resultando en un requisito de revocacion de licencias. Un propietario de licencia (usuario) por otra parte podna querer cambiar sus restricciones anteriormente definidas, resultando en un requisito para poder propagar cambios de la licencia en el sistema.

• La relacion de asociacion entre un propietario de licencia y un dominio se expresa en un enlace dirigido - llamado LinkLO - desde el dominio al propietario de licencia. Un enlace de este tipo puede contener reglas de restriccion expresadas en codigo de control ejecutable, almacenadas en un asf llamado objeto de control en el enlace, cualificando la validez del enlace, que debe evaluarse en el momento que se vaya a usar el enlace. Un enlace de este tipo se crea preferentemente usando un objeto firmado digitalmente en el que se identifican el dominio y el propietario de licencia.

• La relacion de pertenencia entre un cliente y un dominio se expresa en un enlace dirigido - llamando LinkC -desde el cliente al dominio. Un enlace de este tipo puede contener reglas de restriccion expresadas en codigo de control ejecutable, almacenadas en un asf llamado objeto de control en el enlace, que califica la validez del enlace, que debe evaluarse en el momento que se vaya a usar el enlace. Un enlace de este tipo se crea preferentemente usando un objeto firmado digitalmente en el que se identifican el cliente y el dominio.

Pueden anadirse atributos a licencias asf como a enlaces para soportar evaluacion de validez y para propositos de transporte de informacion.

Cada cliente que es un miembro de un dominio puede acceder a (una copia de) el contenido y las certificaciones que comprenden la configuracion de dominio en un cierto momento de tiempo, por ejemplo descargando tal contenido y certificaciones segun se necesiten, aunque algunos o todos estos datos tambien pueden difundirse o distribuirse de otra manera.

Cuando un cliente pretende acceder una pieza de contenido, evaluara la licencia para ese contenido, comprobando permisos y restricciones definidos en esa licencia. Para este fin se proporciona al cliente con un modulo de evaluacion de licencia que puede realizarse como un chip seguro y/o componente de software, por ejemplo en una tarjeta inteligente.

En cada licencia existe la restriccion de que, usando los diferentes enlaces disponibles para el cliente, debe estar presente una ruta valida (cadena de enlaces) desde el cliente de evaluacion al propietario de licencia. Durante esta evaluacion de ruta, tambien debe evaluarse cualquier restriccion, siendo una condicion que limita la validez del enlace, presente en los enlaces que componen la ruta. Como resultado, una pieza de contenido puede accederse unicamente cuando se encuentra una ruta de certificaciones entre el cliente de evaluacion y la pieza de contenido mientras que todas las condiciones en cada certificacion se cumplen. Si se encuentra esta ruta, el modulo de evaluacion de licencia habilitara que un modulo de acceso a contenido acceda al contenido de la manera solicitada. Posteriormente el contenido puede presentarse, copiarse y/o distribuirse de acuerdo con las Reglas de Uso.

Este sistema funciona bien para la concesion de derechos a clientes basandose en la configuracion de dominio. Cambiando o en su totalidad eliminando derechos concedidos anteriormente para clientes en una configuracion establecida de relaciones requiere que relaciones y sus certificaciones asociadas se invaliden para preservar consistencia en el sistema. Las entidades en la cadena pueden desplegarse en diferentes dispositivos que no necesitan estar conectados entre sf en todo momento. No puede simplemente "decirle" a un cliente no conectado que una certificacion ya no es valida. Otro problema con una certificacion es que incluso cuando se borrase en un cliente, otra copia de la certificacion podna (re) aparecer en ese cliente desde otro anfitrion en el sistema o desde un sistema auxiliar. Esto proporciona una abertura para que usuarios maliciosos ganen acceso a contenido en un cliente para el que no tienen derecho.

Dado el hecho de que no es viable la revocacion de certificaciones en el sistema borrando todas las instancias (copias) de las certificaciones a revocar, se necesitan otras formas de revocacion para poder reducir los derechos que tiene un cliente para contenido.

Sumario de la invencion

La invencion se establece en el conjunto adjunto de las reivindicaciones.

En breve, en un sistema tal como se describe anteriormente, se concede acceso a una pieza de contenido de acuerdo con una licencia propiedad de un propietario de licencia a un cliente que es un miembro de un dominio. Esto requiere verificacion satisfactoria de que existe una relacion de pertenencia entre el cliente y el dominio como se refleja en una primera variable de estado mantenida tanto por el cliente como por un controlador del dominio, y que existe una relacion de asociacion entre el propietario de licencia y el dominio como se refleja en una segunda variable de estado mantenida tanto por el controlador del dominio como por un controlador de propietario de licencia asociado con el propietario de licencia.

Estas dos etapas de verificacion prueban la pertenencia del cliente al dominio, y asociacion del propietario de licencia, y por lo tanto tambien sus licencias, con el dominio. Como resultado puede concederse el acceso al contenido. La relacion entre dos partes se expresa preferentemente en una certificacion en la que las dos partes se identifican. La existencia de una certificacion de este tipo, habitualmente firmada digitalmente por una parte de confianza, se usa a continuacion en la verificacion de la relacion.

Deshabilitando la posibilidad de acceder, en un dominio de este tipo, a una pieza espedfica de contenido puede disponerse con una restriccion en la licencia o comunicando la validez de la licencia a un cliente. Deshabilitar la posibilidad de acceder, en un dominio de este tipo, a cualquier contenido de un propietario de licencia espedfico puede disponerse con una restriccion en el dominio^Enlace de Propietario de Licencia (LinkLO) o comunicando la validez del enlace hacia el cliente. Para deshabilitar que un unico cliente acceda a cualquier contenido de dominio puede realizarse una operacion similar para el dispositivo^Enlace de Dominio (LinkC).

Es beneficioso para el sistema cuando es posible transportar certificaciones a un cliente proporcionando nueva informacion acerca de la configuracion de dominio que puede usarse instantaneamente para acceso a contenido sin la necesidad de protocolos en lmea entre partes. Una aplicacion se expresa, cuando un nuevo propietario de licencia se asocia con el dominio, en un LinkLO, y publica contenido en el dominio, expresado en licencias, transporte de estas certificaciones junto con el contenido a un cliente no conectado usando algun medio habilita que el cliente acceda al contenido sin necesidad de conectarse a otra parte.

Otra aplicacion incluso mas deseable es cuando un propietario de licencia asociado existente adquiere contenido y lo publica en el dominio; la licencia puede transportarse junto con el contenido a un cliente no conectado usando algun medio que habilita que el cliente acceda al contenido sin necesidad de conectarse a otra parte.

Una restriccion comunmente usada para certificaciones en una situacion de este tipo es la definicion de un periodo de validez; despues del periodo de validez la certificacion se deshabilita por sf misma. En caso de periodos de validez en enlaces, un cliente que no ha estado en contacto con los emisores de enlaces en el sistema, para refrescar sus enlaces, con el tiempo no sera capaz de acceder nunca mas al contenido. Un periodo de validez en una licencia resultara en tiempo, cuando no se emita de nuevo, en una finalizacion de la posibilidad de acceder a una pieza espedfica de contenido en un cliente.

Inconvenientes asociados con periodos de validez en certificaciones son:

1. Certificaciones deben actualizarse regularmente para confirmar de nuevo la validez que requieren emisores en lmea, generando trafico de red y requiriendo generacion y firma de certificaciones actualizadas;

2. No todas las certificaciones en un cliente expiraran en un cliente al mismo tiempo proporcionando una experiencia de usuario no deseada especialmente cuando las licencias expiran en momentos diferentes;

3. Para preservar consistencia en un sistema, deben introducirse tiempos de espera para que algunas operaciones se aseguren de que ha transcurrido el periodo de validez de certificaciones emitidas;

4. Clientes no seran capaces de acceder a contenido cuando no se conecten durante un largo periodo (> periodo de validez) mientras nada ha cambiado en la configuracion de dominio.

Uno de los problemas con lo anterior es como revocar o deshabilitar de forma fiable un enlace y por lo tanto una relacion. Borrar una certificacion revoca la relacion, pero si una certificacion puede copiarse y distribuirse, entonces una persona con intenciones maliciosas puede simplemente copiar la certificacion de antemano y restaurarla despues de que se ha borrado. Almacenar y gestionar certificaciones en memoria segura es una opcion pero la memoria segura es cara, especialmente cuando se trata con un gran numero de certificaciones.

Es un objeto de la invencion proporcionar un medio mas eficiente de revocar la relacion de pertenencia y la relacion de asociacion.

Esto se consigue mediante un metodo que comprende:

revocar la relacion de pertenencia ejecutando un protocolo en lmea entre el controlador del dominio y el cliente despues de la que ambos eliminan la primera variable de estado, y

revocar la relacion de asociacion ejecutando un protocolo en lmea entre el controlador de propietario de licencia y el controlador del dominio despues de la cual el controlador del dominio elimina la segunda variable de estado y despues de la cual la administracion de estado relacionada con el dominio se propaga al cliente de modo que la segunda variable de estado se elimina por el cliente.

Hablando en general, la invencion resuelve este problema teniendo que las partes identificadas en el enlace mantengan estado con respecto a sus relaciones, de modo que simplemente pueden eliminar la variable de estado para revocar el enlace. El cliente es por ejemplo un dispositivo configurado para acceder y reproducir contenido, y necesita ser un miembro de un dominio para ser capaz de acceder a contenido de dominio. El dominio se gestiona por un controlador de dominio, que habitualmente es un dispositivo central en una red domestica (aunque muchas otras configuraciones por supuesto tambien son posibles).

El propietario de licencia es una entidad representativa del usuario cuyo contenido esta disponible para dispositivos en 'su' dominio. Esto requiere una relacion de asociacion entre el propietario de licencia y el dominio. El lado del propietario de licencia de la asociacion se controla por un dispositivo controlador, que podna realizarse por ejemplo como una tarjeta inteligente propiedad del usuario o como un servidor proporcionado por una tercera parte por ejemplo a traves de la Internet.

El controlador del dominio y el cliente mantienen respectivas variables de estado con respecto a la pertenencia del cliente en el dominio. Se requiere la presencia de una variable de estado valida para verificar satisfactoriamente que existe la relacion de pertenencia. Cuando ambas entidades borran estas variables de estado (despues de acordar hacerlo en un protocolo en lmea), la relacion ya no puede verificarse.

Lo mismo es cierto para la relacion de asociacion, aunque en este punto el controlador de dominio tambien necesita propagar la administracion de estado relacionada con el dominio al cliente, de modo que el cliente puede actualizar su administracion de estado y eliminar la variable de estado que refleja la relacion de asociacion.

En una realizacion la verificacion de la relacion de asociacion y la relacion de pertenencia comprende evaluar un periodo de validez de la relacion en cuestion segun se expresa mediante la informacion de estado y verificar satisfactoriamente la asociacion en cuestion unicamente si el periodo de validez no ha expirado. Es ventajoso tener expiracion de validez basada en tiempo. Expresando esto usando la informacion de estado, el periodo de validez puede comprobarse facilmente.

En una realizacion adicional el controlador de dominio y el cliente mantienen una tercera variable de estado para proteger el estado de la licencia. Esto usa ventajosamente el mecanismo de la invencion tambien para las licencias y no unicamente para las relaciones de pertenencia y asociacion. Esta realizacion permite la invalidacion de licencias eliminando la tercera variable de estado. Esto evita la restauracion de licencias expiradas o de otra manera invalidadas mediante la restauracion de una copia ya que la variable de estado no puede manipularse de esta manera. Ahora tampoco existe la necesidad de restringir la copia de licencias, ya que se aceptaran unicamente por una parte que tiene una tercera variable de estado valida.

Preferentemente en esta realizacion el controlador del propietario de licencia crea la tercera variable de estado y propaga la tercera variable de estado al controlador de dominio que propaga la tercera variable de estado al cliente. Esto ventajosamente requiere que unicamente se habilite al controlador de propietario de licencia para crear la tercera variable de estado, ya que los otros simplemente pueden recibir la misma (directa o indirectamente) desde este controlador. Ya que el controlador del propietario de licencia se implementa preferentemente como un modulo seguro, por ejemplo una tarjeta inteligente, de todos modos, no necesitan tomarse medidas especiales para proteger la creacion de las variables de estado.

La invencion puede encontrar aplicacion en areas tales como sistemas de Dominio Autorizado para dispositivos de IT y CE, sistemas de proteccion de contenido en entornos con dispositivos posiblemente desconectados y sistemas de comunidad con comparticion de recursos para dispositivos de consumo.

Descripcion detallada de las realizaciones preferidas

La Figura 2 esquematicamente ilustra un sistema ilustrativo 100 que comprende dispositivos 101-105 y personas 130, 131 que forman un dominio autorizado (AD). El sistema 100, que tiene por objetivo representar una red domestica digital tfpica, incluye un numero de dispositivos, por ejemplo un receptor de radio, un sintonizador/decodificador, un reproductor de CD, un par de altavoces, una television, un VCR, un grabador digital, un telefono movil, una pletina de casete, un ordenador personal, un asistente digital personal, una unidad de visualizacion portatil y asf sucesivamente. Estos dispositivos se interconectan a traves de la red 110 para permitir que un dispositivo, por ejemplo la television, controle otro, por ejemplo el VCR. Un dispositivo, tal como por ejemplo el sintonizador/decodificador o un decodificador de salon (STB), es normalmente el dispositivo central, proporcionando control central sobre los otros.

Contenido, que habitualmente comprende cosas como musica, canciones, pelfculas, programas de TV, fotograffas, juegos, libros y similares, pero que tambien puede incluir servicios interactivos, se recibe a traves de una pasarela residencial o decodificador de salon 101. Contenido tambien podna entrar en la casa a traves de otras fuentes, tal como medios de almacenamiento como discos o usando dispositivos portatiles. La fuente podna ser una conexion a una red de cable de banda ancha, una conexion de internet, un enlace descendente por satelite y asf sucesivamente. El contenido puede a continuacion transferirse a traves de la red 110 a un destino para presentacion. Un destino puede ser, por ejemplo, el visualizador de television 102, el dispositivo de visualizacion portatil 103, el telefono movil 104 y/o el dispositivo de reproduccion de audio 105.

La forma exacta en la que un artoulo de contenido se presenta depende del tipo de dispositivo y el tipo de contenido. Por ejemplo, en un receptor de radio, la presentacion comprende la generacion senales de audio y alimentacion de la mismas a altavoces. Para un receptor de television, la presentacion generalmente comprende la generacion de senales de audio y video y alimentacion de las mismas a una pantalla de visualizacion y altavoces. Para otros tipos de contenido debe tomarse una accion apropiada similar. La presentacion tambien puede incluir operaciones tal como descifrar o desaleatorizar una senal recibida, sincronizar audio y senales de video y asf sucesivamente.

El decodificador de salon 101, o cualquier otro dispositivo en el sistema 100, puede comprender un medio de almacenamiento S1 tal como un disco duro adecuadamente grande, que permita la grabacion y posterior reproduccion del contenido recibido. El medio de almacenamiento S1 podna ser un Grabador Digital Personal (PDR) de alguna clase, por ejemplo un grabador DVD+RW, al que se conecta el decodificador de salon 101. Contenido tambien puede entrar en el sistema 100 almacenado en una portadora 120 tal como un Disco Compacto (CD) o Disco Versatil Digital (DVD).

El dispositivo de visualizacion portatil 103 y el telefono movil 104 se conectan inalambricamente a la red 110 usando un punto de acceso inalambrico 111, por ejemplo usando Bluetooth o IEEE 802.11b/g. Los otros dispositivos se conectan usando una conexion por cable convencional. Para permitir que los dispositivos 101-105 interaction, estan disponibles varias normas de interoperabilidad, que permite que diferentes dispositivos intercambien mensajes e informacion y para controlarse entre s i Una norma bien conocida es Enchufar y Usar Universal (http://www.upnp.org).

En un escenario ilustrativo, al menos uno de los usuarios 130, 131 se vincula al dominio autorizado ademas de uno o mas de los dispositivos 101-105. Opcionalmente un numero de artfculos de contenido (no mostrado) tambien pueden vincularse al dominio autorizado. Esta vinculacion de usuarios y/o contenido puede hacerse de la manera divulgada en la solicitud de patente internacional WO 04/038568 (expediente del mandatario PHNL021063), de la manera divulgada en la solicitud de patente internacional WO 2005/010879 (expediente del mandatario PHNL030926), o de la manera descrita en la solicitud de patente internacional con numero de serie IB2005/050910 (expediente del mandatario PHNL040315).

A menudo es importante garantizar que los dispositivos 101-105 en la red domestica no hagan copias no autorizadas del contenido. Para hacer esto, es necesario un marco de seguridad, habitualmente denominado como un sistema de Gestion de Derechos Digitales (DRM). Una forma de proteger contenido en forma de datos digitales es garantizar que unicamente se transferira contenido entre los dispositivos 101-105 si

• el dispositivo receptor se ha autenticado como que es un dispositivo compatible, y

• el usuario del contenido tiene el derecho para transferir (mover y/o copiar) ese contenido a otro dispositivo. Si se permite la transferencia de contenido, esto se realizara habitualmente de una forma cifrada para asegurarse que el contenido no puede capturarse ilegalmente en un formato util del canal de transporte, tal como un bus entre una unidad de CD-ROM y un ordenador personal (anfitrion).

Autenticacion de miembro de AD

Sistemas de proteccion de contenido, especialmente los establecidos como alguna forma de dominio autorizado, normalmente implican comunicacion protegida entre miembros basandose en algun secreto, unicamente conocido para dispositivos que se probaron y certificaron para tener implementaciones seguras. Conocimiento del secreto se prueba usando un protocolo de autenticacion. Comunmente estos protocolos emplean criptograffa de clave publica, que usan un par de dos claves diferentes. El secreto a probar es entonces la clave secreta (en ocasiones llamada clave privada) del par, mientras la clave publica puede usarse para verificar los resultados de la prueba.

Para garantizar la correccion de la clave publica y para comprobar si el par de claves es un par legftimo de un dispositivo certificado, la clave publica se acompana por un certificado, que se firma digitalmente por una Autoridad de Certificacion (CA), la organizacion que gestiona la distribucion de pares de clave publica/privada para todos los dispositivos. Todo el mundo conoce la clave publica de la CA y puede usar la misma para verificar la firma de la CA en el certificado. En una implementacion simple la clave publica de la CA se codifica en la implementacion del dispositivo.

Para habilitar lo anterior cada cliente mantiene un numero de claves secretas. Estas claves y el flujo de control usando estas claves debenan protegerse bien, para conocimiento de estas claves o manipulacion del flujo de control permitina que piratas informaticos burlen el sistemas de proteccion de contenido.

El flujo de control determina si debena concederse acceso a una pieza de contenido a un Cliente Miembro. El resultado del flujo de control es una decision de si puede accederse o no a contenido. Por supuesto tal acceso debena estar de acuerdo con la licencia aplicable para el contenido, esa Licencia pertenece al propietario de licencia. Informacion para esa decision consiste en la presencia de las relaciones entre las entidades de sistema.

Evaluar el flujo de control a continuacion implica verificar que existe una relacion de pertenencia entre el cliente y el dominio y que existe una relacion de asociacion entre el propietario de licencia y el dominio. Esta verificacion implica la evaluacion de certificaciones llamadas enlaces asf como la verificacion de variables de estado que reflejan la validez de estas certificaciones.

El cliente, por ejemplo cualquiera de los dispositivos 102-105, y el controlador de dominio, por ejemplo el decodificador de salon 101, mantienen ambos una primera variable de estado que refleja la relacion de pertenencia del cliente al dominio. De manera similar, el controlador de dominio y un controlador de propietario de licencia asociado con el propietario de licencia mantienen ambos una segunda variable de estado que refleja la relacion de asociacion entre el propietario de licencia y el dominio. El controlador de propietario de licencia es por ejemplo una tarjeta inteligente propiedad del usuario representada por el propietario de licencia.

En algunas realizaciones el controlador de dominio y el cliente mantienen una tercera variable de estado que protege el estado de la licencia. En tales realizaciones el controlador de propietario de licencia crea esta tercera variable de estado y propaga la misma al controlador de dominio que propaga la tercera variable de estado al cliente.

Un controlador de dominio gestiona y sirve multiples (cero, uno o mas) dominios. Un dominio sin embargo unicamente puede gestionarse por un unico controlador de dominio. Este controlador es responsable de emitir certificaciones con respecto a pertenencia relaciones de Clientes a los dominios que gestiona. El controlador puede ubicarse en una plataforma embebida asf como abierta. La autorizacion para crear, eliminar y controlar la composicion de un dominio puede estar sujeta a ciertas reglas o restricciones impuestas por una polftica de dominio. Un controlador de propietario de licencia gestiona y sirve multiples (cero, uno o mas) propietarios de licencia. Un propietario de licencia sin embargo unicamente puede gestionarse por un unico controlador de propietario de licencia. Este controlador es responsable de emitir certificaciones con respecto a relaciones de asociacion entre el dominio y propietarios de licencia y de distribuir estos enlaces y variables de estado relacionadas a controladores de dominio. El controlador puede ubicarse en una plataforma embebida asf como abierta. Un controlador de propietario de licencia puede concederse autorizacion para asociar y desasociar propietarios de licencia con/de dominios, adquirir licencias, importar contenido en el AD, compartir contenido adquirido o importado con un dominio o un cliente individual. Esta autorizacion puede estar sujeta a ciertas reglas o restricciones impuestas por una polftica de dominio.

Observese que las diversas entidades, tal como cliente, controlador de dominio y controlador de propietario de licencia pueden implementarse como hardware y/o modulos de software en un unico dispositivo. El decodificador de salon 101 por ejemplo se ha descrito anteriormente como un controlador de dominio, pero por supuesto tambien puede operar como un cliente cuando necesita acceder cierto contenido.

Exactamente donde se implementa cada entidad depende del modelo de negocio deseado que este sistema tecnico tiene que soportar, asf como consideraciones de seguridad, restricciones tecnicas con respecto a los dispositivos disponibles y asf sucesivamente. En una sencilla realizacion los clientes se realizan en dispositivos de usuario final tal como telefonos moviles o reproductores de musica portatiles, y el controlador de dominio y controlador de propietario de licencia se despliegan en un servidor central disponible a traves de la Internet. Esto proporciona al operador de este servidor con el mayor control sobre dominios y distribucion de contenido.

En otra realizacion el controlador de dominio y el controlador de propietario de licencia se realizan ambos en un dispositivo (central) en la casa, por ejemplo el decodificador de salon 101. Opcionalmente los dos controladores pueden realizarse como dos dispositivos separados. Los otros dispositivos 102-105 en la casa operan como clientes. En este escenario el contenido, una vez adquirido, esta bajo el control del usuario, por supuesto dentro de los lfmites establecidos por la licencia y cualquier restriccion impuesta por los enlaces en el a D.

En otra realizacion mas el controlador de propietario de licencia se proporciona en un primer servidor de Internet y el controlador de dominio se realiza en un dispositivo (central) en la casa. Lo inverso tambien es posible. El controlador de propietario de licencia puede realizarse en una tarjeta inteligente, aunque dependiendo de la funcionalidad requerida esto no siempre es practico. Una tarjeta inteligente tambien puede usarse para autorizar o identificar a un usuario de modo que se usa el propietario de licencia apropiado.

Los mecanismos en los que se basa la invencion se elaboraran en la seccion 1 ya que se aplicaran en diferentes combinaciones. Que combinacion de mecanismos a usar depende de la estimacion que un disenador de sistema haga para equilibrar la complejidad, recursos computacionales, capacidad de almacenamiento (segura) y requisitos de disponibilidad para el sistema.

Las realizaciones descritas en la seccion 2 no son exhaustivas; otras combinaciones de los mecanismos presentados tambien seran beneficiosas.

1. MECANISMOS USADOS EN ESTA INVENCION

1.1 Estado individual para relacion

Mediante entidades en la cadena de autorizacion se mantiene una administracion segura de estado de relaciones. Valores de estado se intercambian entre partes (entidades) en protocolos en lmea seguros. Esta administracion determina si la relacion existe o no y opcionalmente la definicion de relacion se amplfa con un numero de version para soportar deteccion de cambio. Las certificaciones (Licencias y Enlaces) tambien expresan las mismas relaciones. La informacion de estado gestionada de forma segura puede usarse ahora para determinar la existencia de una relacion y con eso la validez de cualquier certificacion para la misma relacion. Cuando este mecanismo se usa para proteger la validez de una certificacion, el codigo de control en la certificacion se ampliara con una comprobacion de si la relacion, la certificacion que reivindica representar, se administra como que existe y es valida en la administracion de estado de la entidad de evaluacion (habitualmente un cliente). Cualquier otra condicion, como un periodo de validez, establecido en una certificacion aun se evaluara. Todas las condiciones que incluyen la comprobacion de estado deben cumplirse antes de que se acepte la certificacion como valida. La eliminacion de la relacion en la administracion de estados de las diferentes entidades puede revocar ahora una relacion en el sistema. La forma mas simple de estado es unicamente la administracion de la propia relacion o relaciones de la entidad con vecinos en la cadena. Ambas partes (entidades) juntas pueden decidir en un protocolo en lmea romper su relacion, que se refleja instantaneamente en ambas de sus administraciones invalidando toda certificacion para esa relacion para ambas partes implicadas. Se informara mas tarde a otras partes (entidades) en la cadena de este cambio de estado y aun consideraran la certificacion como valida. Pueden indicarse periodos de validez en la informacion de estado para forzar la proliferacion de informacion de estado actualizada. El mecanismo de estado puede usarse para revocacion. La creacion de una nueva relacion implicara la generacion de una certificacion asf como la creacion de una variable de estado que debe comunicarse usando protocolos en lmea seguros. Una certificacion puede transportarse de cualquier forma adecuada.

El caso mas trivial para el mecanismo de estado individual es la relacion de pertenencia de un cliente con un dominio en el que el cliente es una parte en el protocolo de revocacion y es tambien el evaluador de las certificaciones. Cuando el cliente y el dominio acuerdan en un protocolo en lmea romper su relacion, esto se refleja en la administracion de estado del cliente. El cliente descalificara de forma inmediata cualquier certificacion para la relacion y ya no es accesible ningun contenido relacionado con dominio en el cliente. En el caso mas general, en el que el evaluador (cliente) no participa en el protocolo cuando una relacion se rompe, existe el problema de latencia de la comunicacion del cambio de estado al evaluador.

1.2 Periodos de validez para enlace

El codigo de control en el enlace verificara que el periodo de validez de los enlaces no ha expirado. Cuando ha expirado, el enlace se considera como no valido. Se instara a las partes que usan enlaces, ademas de un mecanismo de estado adicional opcional, para determinar si una relacion en la cadena existe que contacten con otras partes en la cadena para recibir una renovacion del enlace con un periodo de validez ampliado y opcionalmente recibir actualizaciones de informacion de estado.

1.3 Proliferacion de enlaces de dominio fijados a licencias a clientes no conectados

Cuando la validez de un enlace en un dominio no se protege por estado individual para la relacion, el enlace (certificacion) por sf mismo puede proporcionar evidencia de validez. Tales enlaces, cada uno describiendo una parte de la configuracion de dominio, pueden fijarse a licencias cuando se emiten. Es beneficioso para el sistema cuando esta potencialmente nueva informacion acerca de la configuracion de dominio llega a un cliente y puede usarse instantaneamente para acceso a contenido sin la necesidad de protocolos en lmea entre partes. Este mecanismo por ejemplo puede usarse para fijar el LinkLO para un propietario de licencia a las licencias emitidas por ese propietario de licencia.

Cuando el cliente ya tiene el enlace o una version mas nueva del enlace, la informacion no se usa. En un paquete un cliente puede recibir la licencia para una pieza de contenido y el enlace del propietario de licencia emisor con el dominio. Este paquete de licencia puede acompanar al propio contenido en algun medio que habilita que el cliente acceda al contenido sin la necesidad de conectarse a ninguna otra parte en el sistema. Cuando ninguno de los enlaces en la configuracion de dominio se protege por estado individual para la relacion, todos los enlaces pueden fijarse a una licencia proporcionando todo el conjunto de certificaciones necesarias para acceder al contenido relacionado.

Este mecanismo no operara cuando se usa el mecanismo 1.1 - "Estado individual para relacion" para el enlace, pero puede funcionar junto con los mecanismos 1.4-"Numero de configuracion para relaciones por estado" y 1.5 -"Numero de configuracion para relaciones por enlaces".

1.4 Numero de configuracion para relaciones por estado

En el mecanismo de estado 1.1 - Estado individual para relacion, un valor de estado representa una unica relacion. Un numero de configuracion representa una coleccion expKcita de relaciones que se tratan equitativamente con respecto a revocacion. Unicamente cuando una relacion se elimina de la coleccion el numero de configuracion se incrementa indicando que no todas las relaciones anteriormente parte de la coleccion son aun validas. La adicion de una nueva relacion a la coleccion no aumentara el numero porque unicamente estamos interesados en revocacion. Las certificaciones de las relaciones implicadas se atribuyen con el valor real del numero de configuracion en el momento que se emiten y se anade una condicion en su codigo de control indicando que el valor del numero de configuracion de la certificacion es igual a o mayor que el valor del numero de configuracion en la administracion de estado de la entidad de evaluacion (habitualmente cliente). Cuando no se cumple esta condicion, la relacion se considera como no valida.

Este mecanismo no requiere actualizaciones de estado en el sistema cuando se anade una nueva relacion; la comunicacion de certificaciones unicamente bastara para introducir de forma efectiva nuevas relaciones. Un inconveniente de este mecanismo es que cuando unicamente tiene que revocarse una relacion, todas las demas relaciones en la coleccion deben confirmarse de nuevo mediante una renovacion de sus certificaciones con el nuevo numero de configuracion incrementado como atributo. Proliferacion de informacion de estado cambiada es similar como en el mecanismo de estado para relaciones individuales.

Este mecanismo puede usarse en cascada para los diferentes niveles de relaciones en la cadena de autorizacion, opcionalmente en combinacion con el mecanismo 1.5 - Mecanismo de "Numero de configuracion para relaciones por enlaces".

1.5 Numero de configuracion para relaciones por enlaces

La definicion del numero de configuracion y reglas para anadir y eliminar relaciones a y desde la coleccion implfcita son las mismas que las descritas para el mecanismo 1.4 - "Numero de configuracion para relaciones por estado". Las diferencias estan en la proliferacion del numero de configuracion real en la cadena hacia la entidad de cliente y en la forma que se prueban las certificaciones de las relaciones implicadas para validez. Las certificaciones de las relaciones implicadas se atribuyen con el valor real del numero de configuracion en el momento que se emiten, pero la condicion para la comprobacion de validez no se anade a su control. El valor real del numero de configuracion se anade como un atributo al enlace que es el siguiente en la lmea de la cadena de autorizacion en la direccion hacia el cliente.

La condicion para comprobar el numero de configuracion atribuido a la certificacion de las relaciones implicadas contra el valor real del numero de configuracion se anade al codigo de control del enlace. Este enlace alcanzara a los clientes en su momento, impuesto por el periodo de validez establecido para el enlace. Durante la evaluacion de un cliente de la ruta al propietario de licencia se dirige a una licencia, el enlace se evaluara y el valor de numero de configuracion en el enlace se comparara con el de la certificacion de la relacion implicada (habitualmente la licencia). El numero de la certificacion debe ser igual a o mayor que el valor del numero en el enlace. Observese que este mecanismo no sufre de la incapacidad de introducir relaciones en los clientes mediante certificaciones sin que el cliente se conecte, porque no hay ninguna operacion de estado implicada.

Este mecanismo puede usarse en cascada para los diferentes niveles de relaciones en la cadena de autorizacion, opcionalmente en combinacion con el mecanismo 1.4 - Mecanismo de "Numero de configuracion para relaciones por estado".

1.6 Numero de version para relacion por estado

Algunas relaciones, habitualmente la relaciones entre contenido y propietario de licencia no necesitan unicamente revocarse en su totalidad, sino que necesitan adaptarse. Este es el caso, por ejemplo cuando para una licencia existente deben cambiarse las restricciones definidas para usuario. Para soportar control de version (revocacion de versiones previas) se introduce un numero de version. Este numero de version que se incrementa cuando tiene lugar un cambio esencial en la relacion.

El valor actual del numero de version debe comunicarse a clientes para comprobar la condicion de version. Atribuir el estado para la relacion con el valor real del numero de version hace esto y esta combinacion se transportara al cliente de evaluacion a traves de la cadena de entidades usando protocolos seguros en lmea como ya se ha descrito para los otros mecanismos de estado.

La certificacion de la relacion implicada se atribuye con el valor real del numero de version en el momento que se emite y en su codigo de control se anade una condicion indicando que el valor del numero de version de la certificacion es igual a o mayor que el valor del numero de version de la relacion en la administracion de estado de la entidad de evaluacion (habitualmente cliente).

Un prerrequisito para este mecanismo es el uso del mecanismo 1.1 - Mecanismo de "Estado individual para relacion" para la relacion controlada por version .

1.7 Numero de version para relacion por enlaces

La definicion del numero de version y reglas para cambiar relaciones son las mismas que las descritas para el mecanismo 1.6 - "Numero de version para relacion por estado". Las diferencias estan en la proliferacion del numero de version real en la cadena hacia la entidad de cliente y en la forma que se prueban las certificaciones de las relaciones implicadas para validez.

La certificacion de la relacion implicada se atribuye con el valor real del numero de version en el momento que se emite, pero la condicion para la comprobacion de validez no se anade a su control. El valor real del numero de version y la identificacion de la relacion implicada se anaden como un atributo al enlace que es el siguiente en la lmea de la cadena de autorizacion en la direccion hacia el cliente. Observese que este enlace contendra potencialmente una lista completa de combinaciones de relacion-numero de version - una para cada relacion un nivel superior en la cadena de autorizacion.

La condicion para comprobar el numero de version atribuido a la certificacion de las relaciones implicadas contra el valor real del numero de version se anade al codigo de control del enlace. Este enlace alcanzara a los clientes en su momento, impuesto por el periodo de validez establecido para el enlace. Durante la evaluacion de un cliente de la ruta al propietario de licencia se dirige a una licencia, el enlace se evaluara y el valor de numero de version para la relacion bajo evaluacion en el enlace se comparara con el de la certificacion de la relacion implicada (habitualmente la licencia). Observese que este mecanismo no sufre de la incapacidad de introducir relaciones en los clientes mediante certificaciones sin que el cliente se conecte, porque no hay ninguna operacion de estado implicada.

1.8 Enlazamiento de licencia paralelo para separacion de areas de control

En el concepto basico debe probarse una ruta valida al propietario de licencia y los permisos y restricciones en la licencia, dirigidos al propietario de licencia, deben cumplirse. Restriccion definida por usuario adicional debe, en este concepto, anadirse al control en la licencia. Usando enlazamiento de licencia paralelo estas restricciones definidas por usuario se separan del conjunto de restricciones en el control de la licencia. La licencia que se dirige a un propietario de licencia se vincula explfcitamente con un "nuevo" enlace LinkLic desde el propietario de licencia a la licencia cuando se adquiere la licencia. Observese que el LinkLic no necesita ocuparse de la multiplicidad de la relacion de contenido - licencia, como debe hacer una licencia.

La comprobacion en la licencia sera ahora que debe estar presente una ruta valida (cadena de enlaces) desde el cliente de evaluacion a la licencia. Cuando por razones de seguridad el propietario de licencia espedfico que esta presente en la ruta a la licencia debe comprobarse, tambien puede anadirse la comprobacion original para una ruta valida desde el cliente de evaluacion al propietario de licencia. Las restricciones definidas para usuario se anaden ahora al codigo de control en el LinkLic en lugar del control de la licencia. Como resultado el control de una licencia no necesita cambiarse cuando un usuario quiere anadir o cambiar restricciones definidas por usuario que separan las areas de control y resuelven los problemas de seguridad que surgen cuando todas las restricciones se combinan en un unico control.

Revocacion de la relacion contenido - propietario de licencia puede hacerse con uno o una combinacion de los mecanismos de revocacion disponibles. Observese que existen ahora 2 certificaciones (Licencia y LinkLic) para la unica relacion. Ambas de estas certificaciones paralelas deben estar disponibles y ser validas para ser capaces de acceder a contenido en un cliente. Cuando se deshabilita una de las certificaciones, la relacion se revoca. Control de version, habitualmente requerido para restricciones definidas por usuario, pueden ahora aplicarse selectivamente al LinkLic que contiene las restricciones definidas para usuario.

1.9 Enlazamiento de licencia en serie para separacion de areas de control

En el concepto basico debe probarse una ruta valida al propietario de licencia y los permisos y restricciones en la licencia, dirigidos al propietario de licencia, deben cumplirse. Restriccion definida por usuario adicional debe anadirse, en este concepto, al control en la licencia. Usando enlazamiento de licencia en serie estas restricciones definidas por usuario se separan del conjunto de restricciones en el control de la licencia. La licencia ya no se dirige a un propietario de licencia; unicamente solo hace referencia al artfculo o artfculos de contenido y contiene los permisos y restricciones segun se establecen por el proveedor de servicio de contenido original. La licencia ya no representa la relacion completa entre el contenido y el propietario de licencia. La relacion con el propietario de licencia se establece y representa mediante un "nuevo" enlace LinkLic desde el propietario de licencia a la licencia cuando al propietario de licencia se concede acceso al contenido. Observese que el LinkLic no necesita ocuparse de la multiplicidad de la relacion de contenido - licencia; esto aun se hace por la licencia. La comprobacion en la licencia sera ahora que debe estar presente una ruta valida (cadena de enlaces) desde el cliente de evaluacion a la licencia. Las restricciones definidas para usuario se anaden ahora al codigo de control en el LinkLic en lugar del control de la licencia. Como resultado el control de una licencia no necesita cambiarse cuando un usuario quiere anadir o cambiar restricciones definidas por usuario que separan las areas de control y resuelven los problemas de seguridad que surgen cuando todas las restricciones se combinan en un unico control.

Revocacion de la relacion contenido - propietario de licencia puede hacerse con uno o una combinacion de los mecanismos de revocacion disponibles que actuan en la certificacion de LinkLic.

Observese que existen ahora 2 certificaciones (Licencia y LinkLic) requeridas para la unica relacion en las que la licencia trata la parte de contenido de la relacion y el LinkLic trata la parte de propietario de licencia de la relacion. Ambas de estas certificaciones en serie deben estar disponibles y ser validas para ser capaces de acceder a contenido en un cliente. Cuando se deshabilita una de las certificaciones, la relacion se revoca. Control de version, habitualmente requerido para restricciones definidas por usuario, puede ahora aplicarse selectivamente al LinkLic que contiene las restricciones definidas para usuario.

En soluciones previas, contenido se dirigio a un propietario de licencia en una licencia, para ser mas espedficos en el codigo de control de la licencia con la comprobacion que el propietario de licencia debe ser alcanzable a traves de una ruta de enlaces. En una solucion con este mecanismo, el acoplamiento de propietario de licencia se hace en el LinkLic. La concesion de derechos de acceso a un propietario de licencia espedfico no se embebe en la licencia. Cuando los derechos tienen que moverse a otro propietario de licencia entonces el control en la licencia no necesita cambiarse; el nuevo propietario de licencia puede reutilizarlo. El nuevo propietario de licencia tiene que establecer un nuevo LinkLic que hace referencia a sf mismo en cooperacion con el antiguo propietario de licencia que tiene que revocar la relacion existente (LinkLic).

1.10 Redefinicion de licencia para separacion de areas de control

Con los mecanismos 1.8 - Enlazamiento de licencia paralelo para separacion de areas de control y 1.9 -Enlazamiento de licencia en serie para separacion de areas de control se describen metodos para separar areas de control usando los elementos existentes licencia y enlace. Una alternativa para este enfoque es la definicion de un nuevo elemento que combina el comportamiento descrito de la licencia y LinkLic. Ya que la licencia y LinkLic siempre aparecen en combinacion, este nuevo elemento puede ser una sustitucion para la combinacion de otros dos. Esta alternativa tambien puede representarse como una redefinicion del elemento de licencia que soporta dos controles internamente con dos diferentes areas de control; una para contener los permisos y restricciones segun se establecen por el proveedor de servicio de contenido original y una para las restricciones que pueden anadirse por un usuario. En este caso se usara la comprobacion original de que una ruta valida de enlaces al propietario de licencia debe existir. Esta alternativa incluye ambos mecanismos porque el paralelo asf como el patron en serie pueden sustituirse por un unico nuevo elemento.

2. REALIZACIONES PREFERIDAS

Las realizaciones presentadas usan los siguientes puntos de inicio:

• No tener periodos de validez en licencias individuales;

• Se requiere uso de enlaces;

• Puede proporcionarse certificacion a clientes desde cualquier fuente, pero habitualmente un propietario de licencia proporcionara las licencias y el dominio proporciona los enlaces de dominio LinkC y LinkLO;

• Estado de validez de certificaciones se transporta en protocolos en lmea entre partes estrictamente de acuerdo a la cadena de autorizacion.

• Uso de periodos de validez en los enlaces, en los que el periodo de validez para LinkLO se supone que es, pero no necesariamente es, mayor que para LinkC.

Observese que los mecanismos tambien pueden usarse en otras configuraciones de dominio que la presentada en este punto; habitualmente en todas las configuraciones con mas de 2 entidades distribuidas con una cadena de dependencias.

Los mecanismos tambien pueden usarse en las realizaciones que no usan las elecciones anteriormente mencionadas. Por ejemplo: •

• Soluciones con un periodo de validez definido para licencias que se publican en el dominio son bastante facil de definir dados los mecanismos proporcionados pero sufren mucho de los inconvenientes analizados anteriormente en el sumario de la invencion. Sin embargo, en situaciones en las que el numero de licencias es bajo o en las que los recursos no estan limitados, periodos de validez aplicados para licencias pueden ser beneficiosos;

• Cuando se protegen relaciones por estado individual, pueden eliminarse enlaces en su totalidad o al menos reducidos en funcionalidad moviendo algunos o todos los atributos de enlaces, como se usan en las soluciones presentadas, en la administracion de estados de las entidades;

• Cuando el propietario de licencia en lugar del dominio emite el LinkLO, algunas de las soluciones en las que informacion se anade a un LinkLO deben adaptarse ligeramente para habilitar el flujo de informacion a la entidad que emite el enlace.

Las realizaciones presentadas se ilustran en las Figuras usando las siguientes convenciones de notaciones:

• Las entidades en la cadena de autorizacion se indican mediante un drculo y pueden atribuirse con multiples variables de estado anidadas (identificadores, numeros de configuracion, periodos de validez) indicadas mediante ovalos. Estos atributos se gestionan de forma segura por las entidades;

• Las lmeas continuas entre las entidades en la cadena de autorizacion representan las relaciones entre las mismas; las otras lmeas continuas indican asociaciones de atributos;

• Las lmeas discontinuas indican la representacion de certificacion de las relaciones;

• Multiplicidad para atributos se indica con un '*', mientras la multiplicidad para las relaciones no se indica en las figuras;

• Certificaciones que representan una relacion se indican mediante un rectangulo y puede atribuirse con multiples variables (de estado) (identificadores, numeros de configuracion, periodos de validez) indicadas mediante ovalos. Estos atributos se acoplan de forma segura a las certificaciones.

• Una licencia puede atribuirse con enlaces (acoplando LinkC y LinkLO a una licencia). Estos atributos de enlace son informativos y no necesitan acoplarse de formas segura a las certificaciones.

• Estos enlaces acoplados (copias) transportan la misma informacion (atributos) que los enlaces emitidos que representan las correspondientes relaciones. Los atributos sin embargo no se muestran en las figuras.

• Certificaciones (copias) que estan/deben estar presentes, pero no necesariamente deben gestionarse de forma segura, en los anfitriones de las entidades no se indican en las figuras.

• Las ClientId, DomainId, LicenseOwnerld y Licenseld se usan como variables de estado para hacer referencia a su correspondiente entidad pero en las figuras no se muestran como un atributo de esas entidades.

2.1 Sin aplicacion por periodos de validez

Esta realizacion se ilustra en la Figura 3. Los mecanismos aplicados son:

Un propietario de licencia tiene un licenseConfigNr que se incrementa cuando cualquiera de las licencias dirigidas a ese propietario de licencia se cambia o se elimina indicando un cambio para una de las licencias.

Este licenseConfigNr debe comunicarse en un protocolo al dominio que gestiona de forma segura el licenseConfigNr mas reciente para cada propietario de licencia asociado. El dominio gestiona un domainConfigNr que se incrementa cuando cualquiera de las relaciones en la configuracion de dominio cambia. Estos cambios son: un incremento del licenseConfigNr de cualquiera de los propietarios de licencia asociados con el dominio, un cambio o eliminacion de cualquiera de la asociaciones de propietarios de licencia con el dominio y un cambio o eliminacion de cualquiera de las pertenencias de Clientes con el dominio.

El valor actual del domainConfigNr se asocia con el LinkC y el LinkLO mediante el dominio y a licencias recien publicadas en un dominio por el propietario de licencia, por ejemplo grabando este valor en el objeto firmado que representa el LinkC y LinkLO.

El domainConfigNr debe comunicarse primero en un protocolo al propietario de licencia que gestiona de forma segura el domainConfigNr mas reciente para cada dominio asociado para ser capaz de emitir una nueva licencia con un domainConfigNr actualizado.

Despues de un incremento del licenseConfigNr en el propietario de licencia el propietario de licencia necesita esperar para que comunicacion con el dominio reciba el domainConfigNr mas reciente, junto con los enlaces mas recientes del dominio, antes de que puedan emitirse nuevas licencias.

T odos los LinkLO y todos los LinkC, como se conocen por el propietario de licencia, se fijan a una licencia cuando se publican en un dominio. El propietario de licencia recibe estos enlaces en un protocolo con el dominio.

Los enlaces de un dominio pueden alcanzar ahora un cliente mediante comunicacion directa entre el dominio y el cliente o a traves de una licencia adquirida por el cliente. Un cliente gestiona por dominio es un miembro de una variable de estado para el domainConfigNr mas reciente conocido por el cliente. Este domainConfigNr indica validez para enlaces y licencias. Cuando una de estas certificaciones transporta un domainConfigNr como atributo que tiene un valor inferior que el gestionado de forma segura por el cliente la certificacion se considera como no valido y debe renovarse cuando sea posible. Esta comprobacion se realiza mediante codigo en el control de los enlaces durante la evaluacion de ruta, requiriendo que los valores del domainConfigNr en la licencia bajo evaluacion y el domainConfigNr en el enlace bajo evaluacion no deben ser inferiores que los gestionados por el cliente.

El cliente adaptara su domainConfigNr, unicamente incrementando el mismo, cuando se encuentra un valor mas alto en un enlace enviado por el dominio o en una licencia. Todas las relaciones pueden revocarse en el sistema mediante el mecanismo de domainConfigNr, pero no hay aplicacion para que clientes contacten con un dominio o interpreten una nueva licencia. El unico incentivo para que un cliente acepte esta informacion de revocacion cuando desea acceder a contenido para el que se emite una licencia despues de que la revocacion ha tenido lugar en el sistema.

Un propietario de licencia atribuye una licencia con el domainConfigNr conocido en la administracion del propietario de licencia. No existe sin embargo ningun incentivo para que un propietario de licencia contacte con un dominio para recibir nueva informacion de dominio de configuracion excepto para el caso donde el licenseConfigNr se aumento y se requiere comunicacion antes de que se permita que se liberen las licencias. Como resultado el informacion de configuracion de dominio fijada a la nueva licencia publicada (LinkLO, LinkC y el domainConfigNr) puede retrasarse detras de la situacion actual en la configuracion de dominio as conocido por el dominio. Esto puede evitarse requiriendo comunicacion del propietario de licencia con un dominio cada vez antes de que una licencia se publique en un dominio para asegurarse que se tiene la informacion de configuracion de dominio mas reciente.

Esta solucion no implementa la revocacion de certificaciones inmediata en un cliente, sino en su momento, cuando contenido de dominio llega, un cliente cumplira.

Caractensticas de la solucion:

2.2 Sin estado en Cliente

Esta realizacion se ilustra en la Figura 4. Los mecanismos aplicados son:

Un propietario de licencia tiene un licenseConfigNr que se incrementa cuando cualquiera de las licencias dirigidas a ese propietario de licencia se cambia o se elimina indicando un cambio para una de las licencias. Cuando un propietario de licencia publica una licencia en un dominio, el propietario de licencia atribuye la licencia con el valor actual del licenseConfigNr. El valor actual del licenseConfigNr tambien se atribuye al LinkLO. Este licenseConfigNr debena comunicarse primero en un protocolo al dominio que gestiona de forma segura el licenseConfigNr mas reciente para cada propietario de licencia asociado para ser capaz de emitir una nueva LinkLO con un licenseConfigNr actualizado. El control en el LinkLO realizara, durante la evaluacion de ruta, la comprobacion del licenseConfigNr atribuido a la licencia con el atribuido al LinkLO.

El LinkLO y todos los LinkC, como se conocen por el propietario de licencia, se fijan a una licencia cuando se publican en un dominio. El propietario de licencia recibe estos enlaces en un protocolo con el dominio. Ya que la distribucion de enlaces fijados a una licencia es una alternativa opcional ademas de la distribucion normal desde el dominio a los clientes, es opcional si despues de un incremento del licenseConfigNr en el propietario de licencia el propietario de licencia necesita esperar para que comunicacion con el dominio reciba el LinkLO con el licenseConfigNr actualizado. LinkC fijados a licencias publicadas pueden retrasarse detras de la situacion actual en la configuracion de dominio as conocido por el dominio.

Observese que cuando el LinkLO no se emite por un dominio, sino por un propietario de licencia, el propietario de licencia no necesita comunicar el licenseConfigNr al dominio y el dominio no necesita administrar el licenseConfigNr. En ese caso el propietario de licencia emite el LinkLO con el licenseConfigNr actual directamente.

Los periodos de validez obligan a clientes y propietarios de licencia en el LinkLO y LinkC a comunicar regularmente la reconfirmacion de sus relaciones con el dominio y para recibir informacion de configuracion de dominio actualizada. Estos periodos de validez se indican en la figura como LO-validityperiod y C-validityperiod, respectivamente.

Caractensticas de la solucion:

2.3 Estado individual para LinkC

Esta realizacion se ilustra en la Figura 5. Los mecanismos aplicados son:

Observese que existe estado local entre propietario de licencia y dominio, pero esto no resulta en un estado individual administrado por un cliente. La relacion de asociacion pueden revocarse en un protocolo en lmea entre el dominio y el propietario de licencia en el que ambos acuerdan finalizar la asociacion y cada uno eliminar la variable de estado relacionada de su administracion.

El licenseConfigNr se usa para proteger el estado de todas las licencias de un propietario de licencia y el periodo de validez en LinkLO protege la validez de LinkLO como se describe con la solucion 2.2 Sin estado en Cliente.

Unicamente LinkLO, como se conoce por el propietario de licencia, se fija a una licencia cuando se publica en un dominio. El propietario de licencia recibe este enlace en un protocolo con el dominio. Ya que la distribucion del LinkLO fijado a una licencia es una alternativa opcional ademas de la distribucion normal desde el dominio a los clientes, es opcional si despues de un incremento del licenseConfigNr en el propietario de licencia el propietario de licencia necesita esperar para que comunicacion con el dominio reciba el LinkLO con el licenseConfigNr actualizado. Ya que la relacion de pertenencia, en comparacion con la solucion 2.2 Sin estado en Cliente, se protege ahora por una variable de estado individual en el cliente, no tiene sentido anadir un LinkC a una licencia, porque el cliente que adquiere la licencia no puede usar el LinkC por sf mismo para establecer pertenencia; esto puede hacerse unicamente con un protocolo en lmea.

La relacion de pertenencia entre un cliente y un dominio se determina mediante el mecanismo de estado individual. Puede establecerse la pertenencia unicamente usando un protocolo entre las 2 partes y ambos administran este hecho en una variable de estado (DomainId para el cliente). El LinkC se emite con un periodo de validez. El LinkC es valido ahora unicamente cuando el periodo de validez no ha expirado y la variable de estado DomainId relacionada con la pertenencia LinkC en el cliente esta aun presente. Esto se comprueba en el codigo del control del LinkC cuando se evalua el LinkC buscando una ruta al propietario de licencia como se requiere en la licencia en evaluacion. La relacion de pertenencia puede revocarse en un protocolo en lmea entre el dominio y el cliente en el que ambos acuerdan finalizar la pertenencia y cada uno eliminar la variable de estado relacionada de su administracion. Como consecuencia el LinkC se deshabilita en el cliente porque ya no existe ninguna variable de estado relacionada.

El LinkLO se emite con un periodo de validez. El LinkLO es valido ahora unicamente cuando el periodo de validez no ha expirado y la variable de estado DomainId relacionada con la pertenencia en el cliente esta aun presente. Esto se comprueba en el codigo del control del LinkLO cuando se evalua el LinkLO buscando una ruta al propietario de licencia. El control en el LinkLO realizara, durante la evaluacion de ruta, la comprobacion del licenseConfigNr atribuido a la licencia con el atribuido al LinkLO.

Observese que el DomainId de enlaces de dominio podna obtenerse a partir de su administracion de direccion implfcita, pero la solucion mas robusta es atribuir cada Link para un dominio con el DomainId. Sin embargo esto no se ilustra en la figura.

Caractensticas de la solucion:

2.4 Estado individual para LinkC y Dominio estado para LinkLO

Esta realizacion se ilustra en la Figura 6. Los mecanismos aplicados son:

Observese que existe estado local entre propietario de licencia y dominio, pero esto no resulta en un estado individual administrado por un cliente; unicamente en el estado de domainConfigNr combinado. La relacion de asociacion pueden revocarse en un protocolo en lmea entre el dominio y el propietario de licencia en el que ambos acuerdan finalizar la asociacion y cada uno eliminar la variable de estado relacionada de su administracion.

Un propietario de licencia tiene un licenseConfigNr que se incrementa cuando cualquiera de las licencias dirigidas a ese propietario de licencia se cambia o se elimina indicando un cambio para una de las licencias. Cuando un propietario de licencia publica una licencia en un dominio, el propietario de licencia atribuye la licencia con el valor actual del licenseConfigNr. El valor actual del licenseConfigNr tambien se atribuye al LinkLO. Ya que suponemos que el dominio emite LinkLO, este licenseConfigNr debe comunicarse primero en un protocolo al dominio que gestiona de forma segura el licenseConfigNr mas reciente para cada propietario de licencia asociado para ser capaz de emitir una nueva LinkLO con un licenseConfigNr actualizado. El control en el LinkLO realizara, durante la evaluacion de ruta, la comprobacion del licenseConfigNr atribuido a la licencia con el atribuido al LinkLO.

El LinkLO, como se conocen por el propietario de licencia, se fija a una licencia cuando se publican en un dominio. El propietario de licencia recibe este enlace en un protocolo con el dominio. Ya que la distribucion de LinkLO fijado a una licencia es una alternativa opcional ademas de la distribucion normal desde el dominio a los clientes, es opcional si despues de un incremento del licenseConfigNr en el propietario de licencia el propietario de licencia necesita esperar para que comunicacion con el dominio reciba el LinkLO con el licenseConfigNr actualizado.

La relacion de pertenencia entre un cliente y un dominio se determina mediante el mecanismo de estado individual. Puede establecerse la pertenencia unicamente usando un protocolo entre las 2 partes y ambos administran este hecho en una variable de estado (DomainId para el cliente). El LinkC se emite con un periodo de validez. El LinkC es valido ahora unicamente cuando el periodo de validez no ha expirado y la variable de estado DomainId relacionada con la pertenencia LinkC en el cliente esta aun presente. Esto se comprueba en el codigo del control del LinkC cuando se evalua el LinkC buscando una ruta al propietario de licencia como se requiere en la licencia en evaluacion.

La relacion de pertenencia puede revocarse en un protocolo en lmea entre el dominio y el cliente en el que ambos acuerdan finalizar la pertenencia y cada uno eliminar la variable de estado relacionada de su administracion. Como consecuencia el LinkC se deshabilita en el cliente porque ya no existe ninguna variable de estado relacionada. El dominio gestiona un domainConfigNr que se incrementa cuando cualquiera de las relaciones en la configuracion de dominio cambia. Estos cambios son: un incremento del licenseConfigNr de cualquiera de los propietarios de licencia asociados con el dominio, un cambio o eliminacion de cualquiera de la asociaciones de propietarios de licencia con el dominio y un cambio o eliminacion de cualquiera de las pertenencias de Clientes con el dominio. El dominio atribuye el valor actual del domainConfigNr al LinkC y el LinkLO.

Los enlaces de un dominio pueden alcanzar a un cliente mediante comunicacion directa entre el dominio y el cliente y un LinkLO puede alcanzar a un cliente a traves de una licencia adquirida por el cliente. Un cliente gestiona por dominio es un miembro de una variable de estado para el domainConfigNr mas reciente conocido por el cliente. Este domainConfigNr indica validez para enlaces. Cuando uno de los enlaces transporta un domainConfigNr como atributo que tiene un valor inferior que el gestionado de forma segura por el cliente el enlace se considera como no valido y debe renovarse cuando sea posible. Esta comprobacion se realiza mediante codigo en el control de los enlaces durante la evaluacion de ruta, requiriendo que el valor del domainConfigNr en el enlace bajo evaluacion no debe ser inferior que el gestionado por el cliente.

Clientes gestionan una variable de estado de domainConfigNr para cada dominio del que son miembros. Esta variable de estado se actualiza en un protocolo en lmea entre el cliente y el dominio.

Enlaces en un cliente son ahora unicamente validos cuando su periodo de validez no ha expirado y la variable de estado DomainId relacionada con la pertenencia LinkC en el cliente esta aun presente y su valor de domainConfigNr no es menor que el de la administracion de estado de cliente. Esto se comprueba en el codigo del control de los enlaces cuando se evaluan los enlaces buscando una ruta al propietario de licencia como se requiere en la licencia en evaluacion. El control en el LinkLO tambien realizara la comprobacion del licenseConfigNr atribuido a la licencia con el atribuido al LinkLO.

Observese que ahora existe una doble administracion de estado para LinkC: una con el estado individual (DomainId en cliente) y otra a traves del domainConfigNr. Una configuracion alternativa puede ser un LinkC sin el domainConfigNr como un atributo y sin probar el LinkC contra el domainConfigNr en la administracion de estado del cliente. El comportamiento es similar, pero el LinkC no necesita emitirse con cada cambio del domainConfigNr. Observese que el DomainId de enlaces de dominio podna obtenerse a partir de su administracion de direccion implfcita, pero la solucion mas robusta es atribuir cada Link para un dominio con el DomainId. Sin embargo esto no se ilustra en la figura.

Los periodos de validez obligan a clientes y propietarios de licencia en el LinkLO y LinkC a comunicar regularmente la reconfirmacion de sus relaciones con el dominio y para recibir informacion de configuracion de dominio actualizada. Estos periodos de validez se indican en la figura como LO-validityperiod y C-validityperiod, respectivamente.

Caractensticas de la solucion:

2.5 Estado individual para LinkC y LinkLO

Esta realizacion se ilustra en la Figura 7. Los mecanismos aplicados son:

Un propietario de licencia tiene un licenseConfigNr que se incrementa cuando cualquiera de las licencias dirigidas a ese propietario de licencia se cambia o se elimina indicando un cambio para una de las licencias. Cuando un propietario de licencia publica una licencia en un dominio, el propietario de licencia atribuye la licencia con el valor actual del licenseConfigNr.

El valor actual del licenseConfigNr se comunica en un protocolo al dominio que gestiona de forma segura el licenseConfigNr mas reciente para cada propietario de licencia asociado.

La relacion de asociacion entre un propietario de licencia y un dominio se determina mediante el mecanismo de estado individual. Una relacion de asociacion puede establecerse unicamente usando un protocolo entre las 2 partes y ambos administran este hecho en una variable de estado (DomainId para el propietario de licencia y LicenseOwnerld para el dominio). La relacion de asociacion pueden revocarse en un protocolo en lmea entre el dominio y el propietario de licencia en el que ambos acuerdan finalizar la asociacion y cada uno eliminar las variables de estado relacionadas de su administracion. La administracion de estado de un dominio se propaga a clientes cuando estan o cuando entran en contacto entre sf.

La relacion de pertenencia entre un cliente y un dominio se determina mediante el mecanismo de estado individual. Puede establecerse la pertenencia unicamente usando un protocolo entre las 2 partes y ambos administran este hecho en una variable de estado (DomainId para el cliente y Clientld para el dominio).

Para cada dominio un cliente que es miembro del mismo mantendra una copia de la administracion de estado del dominio con respecto a los propietarios de licencia asociados con el dominio. La relacion de pertenencia puede revocarse en un protocolo en lmea entre el dominio y el cliente en el que ambos acuerdan finalizar la pertenencia y cada uno eliminar las variables de estado relacionadas de su administracion.

Los enlaces de un dominio pueden alcanzar a un cliente mediante comunicacion directa entre el dominio y el cliente. Enlaces en un cliente son ahora unicamente validos cuando su periodo de validez no ha expirado y la variable de estado DomainId relacionada con la pertenencia en la administracion de estado de cliente esta aun presente. Esto se comprueba en el codigo del control de los enlaces cuando se evaluan los enlaces buscando una ruta al propietario de licencia como se requiere en la licencia en evaluacion. El codigo de control del LinkLO realizara las comprobaciones adicionales de que el licenseOwnerld para el LinkLO esta aun registrado como asociado en la administracion de estado del cliente y que el valor de licenseConfigNr de la licencia bajo evaluacion es igual a o mayor que el de la administracion de estado del cliente.

Observese que el DomainId de enlaces de dominio podna obtenerse a partir de su administracion de direccion implfcita, pero la solucion mas robusta es atribuir cada Link para un dominio con el DomainId. Lo mismo es valido para anadir un LicenseOwnerId explfcito al LinkLO. Sin embargo esto no se ilustra en la figura.

Los periodos de validez obligan a clientes y propietarios de licencia en el LinkLO y LinkC a comunicar regularmente la reconfirmacion de sus relaciones con el dominio y para recibir informacion de configuracion de dominio actualizada. Estos periodos de validez se indican en la figura como LO-validityperiod y C-validityperiod, respectivamente.

Ya que la relacion de asociacion (LinkLO), en comparacion con la solucion 2.4 Estado individual para LinkC y Dominio estado para LinkLO, se protege ahora por una variable de estado individual en el cliente, no tiene sentido anadir un LinkLO a una licencia, porque el cliente que adquiere la licencia no puede usar el LinkLO por sf mismo para establecer evidencia de la asociacion; esto puede hacerse unicamente con un protocolo en lmea.

Observese que un despliegue alternativo para esta solucion puede ser la transferencia de los atributos de periodo de validez (y los otros atributos no mostrados) de los enlaces a la administracion de estado. Esto significa que la verificacion de una pertenencia o relacion de asociacion comprende evaluar un periodo de validez de la relacion en cuestion segun se expresa mediante la informacion de estado y verificar satisfactoriamente la asociacion en cuestion unicamente si el periodo de validez no ha expirado.

Caractensticas de la solucion:

2.6 Estado individual para LinkC, LinkLO y Licencia

Esta realizacion se ilustra en la Figura 8. Los mecanismos aplicados son:

Esta solucion difiere de la solucion 2.5 - Estado individual para LinkC y LinkLO en el hecho de que no se usa un mecanismo de licenseConfigNr para proteger el estado de todas las licencias dirigidas a un propietario de licencia sino que todas las licencias consiguen cada una una variable de estado individual en la administracion de estado del dominio y clientes. Ahora cada certificacion en el cliente necesita una correspondiente variable de estado en la administracion de estado del cliente para considerarse como valida en una evaluacion de licencia.

Los enlaces de un dominio pueden alcanzar a un cliente mediante comunicacion directa entre el dominio y el cliente. Los enlaces en un cliente son ahora unicamente validos cuando su periodo de validez no ha expirado Y la variable de estado DomainId relacionada con la pertenencia en la administracion de estado de cliente esta aun presente. Esto se comprueba en el codigo del control de los enlaces cuando se evaluan los enlaces buscando una ruta al propietario de licencia como se requiere en la licencia en evaluacion. El codigo de control del LinkLO realizara las comprobaciones adicionales de que el licenseOwnerld para el LinkLO esta aun registrado como asociado en la administracion de estado del cliente y que el Licenseld de la licencia bajo evaluacion esta aun registrado en la administracion de estado del cliente. Observese que esta ultima comprobacion para Licenseld puede asignarse tambien en el codigo de control de la propia licencia. En el ultimo caso esto tiene como consecuencia que tiene que anadirse una comprobacion espedfica de sistema de solucion al control firmado por el proveedor de contenido original o licencia publicada se cambia y firma por el propietario de licencia.

Observese que el Licenseld de una licencia debe estar disponible en la licencia. Sin embargo esto no se ilustra en la figura, como es el caso con el otro identificador de las entidades.

Una alternativa para gestionar variables de estado (en memoria segura) de entidades y comunicar las mismas en una base individual a otras entidades para actualizar sus estructuras de estado internas es la definicion de certificaciones firmadas y versionadas que contienen estructuras enteras que definen el estado. Estas certificaciones pueden distribuirse libremente entre entidades, igual que las otras certificaciones y unicamente necesita gestionarse de forma segura por las entidades una unica variable de estado para la version de una certificacion de este tipo.

Como un ejemplo en esta solucion, un dominio puede emitir una certificacion con una lista de todos los LicenseOwnerld asociados con el dominio junto con todos los Licenseld por LicenseOwnerld de Licencias dirigidas al correspondiente propietario de licencia y publicadas en el dominio. Un cliente gestiona el numero de version de una lista blanca de este tipo que contiene los identificadores de las licencias que son validos de acuerdo con la administracion de estado de forma segura. La certificacion, que puede ser de gran tamano, no necesita almacenarse de forma segura y no necesita comunicarse al cliente mediante un protocolo seguro en lmea.

El comportamiento para un mecanismo de este tipo con respecto a la administracion de estado de la variable de version ya se describe en la solucion 2.1 - Sin aplicacion por periodos de validez para el domainConfigNr. A h la tecnica se usa para un conjunto de enlaces; en este punto puede usarse para un conjunto de variables de estado en cualquier estructura. La tecnica no se describe como un mecanismo separado para la invencion, sino que puede aplicarse por supuesto en combinacion tambien con la mayona de otras soluciones.

Observese que un despliegue alternativo para esta solucion puede ser la transferencia de los atributos de periodo de validez (y los otros atributos no mostrados) de los enlaces a la administracion de estado. Esto significa que la verificacion de una pertenencia o relacion de asociacion, asf como la validez de una licencia, comprende evaluar un periodo de validez de la relacion en cuestion segun se expresa mediante la informacion de estado y verificar satisfactoriamente la asociacion en cuestion unicamente si el periodo de validez no ha expirado.

Caractensticas de la solucion:

2.7 Estado individual para todas las relaciones con control de version en licencias

Esta realizacion se ilustra en la Figura 9. Los mecanismos aplicados son:

Esta solucion difiere de la solucion 2.6 - Estado individual para LinkC, LinkLO y Licencia en el soporte de versiones de licencias en estado. Un propietario de licencia tiene ahora un LicControlVersionNr para cada licencia que se dirige a el mismo en su estado administracion. Una licencia publicada en el dominio por un propietario de licencia se atribuye con el valor real del LicControlVersionNr y el LicControlVersionNr se comunica al dominio o dominios y desde ah a los clientes a incorporarse en sus administraciones de estado.

Un propietario de licencia incremental su LicControlVersionNr cuando se hace un cambio esencial a una licencia. Versiones previas de la licencia publicada en un dominio terminaran inservibles (en su momento) porque transportan un numero de version mas antiguo que el registrado en la administracion de estado de los clientes.

La comprobacion para la presencia del Licenseld de la licencia bajo evaluacion en la administracion de estado del cliente como elemento del licenseOwnerld como elemento del Domainld se amplfa con la comprobacion de que el valor del LicControlVersionNr registrado para el licenseOwnerld no es mayor que el valor del LicControlVersionNr atribuido a la licencia.

De nuevo es opcional asignar esta comprobacion en el codigo de control del LinkLO o en el codigo de control de la propia licencia.

Observese que un despliegue alternativo para esta solucion puede ser la transferencia de los atributos de periodo de validez (y los otros atributos no mostrados) de los enlaces a la administracion de estado.

Caractensticas de la solucion:

2.8 Enlazamiento de licencia paralelo

Esta realizacion se ilustra en la Figura 10. Los mecanismos aplicados son:

Esta solucion demuestra el uso del mecanismo de enlazamiento de licencia paralelo ademas de la configuracion como se describe en la solucion 2.7 - Estado individual para todas las relaciones con control de version en licencias. Vease la descripcion de el mecanismo paralelo como una referencia para esta solucion. El LinkLic es un enlace desde el propietario de licencia a la licencia que se dirige al propietario de licencia. Se usa ahora un LicControlVersionNr para control de version en estado para el LinkLic, cuyo control es mas probable que cambie que la licencia con el control del proveedor de contenido original. Cuando tambien se requiere para el versionado de licencia puede usarse un numero de version adicional proximo a y que opera independiente del LicControlVersionNr.

Algunas caractensticas como con la solucion 2.7 - Estado individual para todas las relaciones con control de version en licencias con ventaja adicional de areas de control separadas en las que las restricciones definidas para usuario pueden cambiarse sin cambiar la licencia.

2.9 Enlazamiento de licencia en serie

Esta realizacion se ilustra en la Figura 11. Los mecanismos aplicados son:

Esta solucion demuestra el uso del mecanismo de enlazamiento de licencia en serie ademas de la configuracion como se describe en la solucion 2.7 - Estado individual para todas las relaciones con control de version en licencias. Vease la descripcion de el mecanismo en serie como una referencia para esta solucion. El LinkLic es un enlace desde el propietario de licencia a la licencia que no se dirige al propietario de licencia. El LinkLic hace el acoplamiento de contenido a un propietario de licencia haciendo este enlace un elemento esencial en el proceso de adquisicion y movimiento de contenido. Se usa ahora un LicControlVersionNr para control de version en estado para el LinkLic, cuyo control es mas probable que cambie que la licencia con el control del proveedor de contenido original. Cuando tambien se requiere para el versionado de licencia puede usarse un numero de version adicional proximo a y que opera independiente del LicControlVersionNr.

Caractensticas de la solucion:

Algunas caractensticas como con la solucion 2.7 - Estado individual para todas las relaciones con control de version en licencias con ventajas adicionales:

• Areas de control separadas en las que las restricciones definidas para usuario pueden cambiarse sin cambiar la licencia;

• No se necesita redireccion en control de licencia firmada por el proveedor de contenido original.

Mejoras adicionales

Pueden anadirse restricciones definidas por usuario de acuerdo con el metodo divulgado en la solicitud de patente internacional WO 05/111760 (expediente del mandatario PHNL040536).

En algunas realizaciones anteriores, la cancelacion de asociacion de un propietario de licencia de un dominio requiere que clientes esperen durante un cierto periodo, normalmente el resto del LO-validityperiod actual, antes de que los clientes ya no puedan acceder a ningun contenido de dominio del propietario de licencia con asociacion cancelada. Este periodo actua a continuacion como un periodo de gracia durante el cual el contenido de dominio desde ese dominio es aun accesible. Despues de este periodo de gracia la asociacion de dominio se cancela.

Un sistema puede implementar un numero maximo de asociaciones de dominio que pueden existir simultaneamente (dominios activos). Normalmente esto se hana con un contador que se aumenta cuando se crea un dominio y disminuye si se cancela una asociacion de dominio. Si este contador iguala al maximo, y el usuario cancela la asociacion de un propietario de licencia de uno de sus dominios, no se permitira la creacion de una nueva asociacion de dominio hasta la finalizacion del periodo de gracia, porque unicamente en ese momento se disminuye el contador. Esto es molesto para los usuarios, ya que esperan ser capaces de crear una nueva asociacion de dominio directamente despues del acto de cancelacion de asociacion de un propietario de licencia de un dominio existente.

Para mejorar lo anterior, el sistema debena implementar un contador separado para el numero de dominios en el periodo de gracia (contador de dominio antiguo). Directamente despues de que se cancela la asociacion del propietario de licencia del dominio, el contador de dominio activo se disminuye por uno. Esto permite la creacion de una nueva asociacion de dominio de forma inmediata.

Ademas de disminuir el contador de dominio activo, se aumenta el contador de dominio antiguo. Despues de la expiracion del periodo de gracia, se disminuye el contador de dominio antiguo. De esta forma los dominios activos y los dominios en sus periodos de gracia se rastrean de forma separada.

Si el contador de dominio activo ha alcanzado su maximo, pueden no crearse nuevas asociaciones de dominio. Porque el contador de dominio activo se disminuye ahora tan pronto como el usuario cancela la asociacion de un propietario de licencia de un dominio, se reduce la molestia anteriormente mencionada.

Un usuario puede aun no ser capaz de crear una nueva asociacion de dominio directamente despues de la cancelacion de asociacion de un propietario de licencia. Esto sucedera si el contador de dominio antiguo ha alcanzado su maximo, y tambien el contador de dominio activo ha alcanzado su maximo. Esto sin embargo es una situacion mucho mas extrema: el usuario tendna que tener no unicamente el numero maximo de dominios activos, sino tambien el numero maximo de dominios aun en sus periodos de gracia.

Eligiendo con cuidado ambas maximas, esta posibilidad puede reducirse significativamente.

Notas finales

En lo anterior, la expresion "min(A, B)" debena interpretarse como el menor de A y B, y la expresion "max(A, B)" debena interpretarse como el mayor de A y B.

En este documento, se usan las siguientes definiciones:

Se ha de observar que las realizaciones anteriormente mencionadas ilustran en lugar de limitar la invencion, y que los expertos en la materia seran capaces de disenar muchas realizaciones alternativas sin alejarse del alcance de las reivindicaciones adjuntas.

A lo largo de las figuras, mismos numeros de referencia indican caractensticas similares o correspondientes. Algunas de las caractensticas indicadas en los dibujos se implementan habitualmente en software, y como tal representan entidades de software, tal como modulos de software u objetos.

En las reivindicaciones, cualquier signo de referencia situado entre parentesis no debe interpretarse como que limita la reivindicacion. Las palabras "que comprende" no excluye la presencia de elementos o etapas distintas de las listadas en una reivindicacion. La palabra "un" o "una" precediendo a un elemento no excluye la presencia de una pluralidad de tales elementos. La invencion puede implementarse por medio de hardware que comprende varios elementos distintos y por medio de un ordenador programado adecuado.

En las reivindicaciones de dispositivo o sistema que enumeran varios medios, algunos o todos de estos medios pueden incorporarse mediante un mismo artfculo de hardware. El mero hecho de que ciertas medidas se citan en reivindicaciones dependientes mutuamente diferentes no indica que una combinacion de estas medidas no puede usarse con ventaja.

Claims (10)

REIVINDICACIONES

1. Un metodo de gestion de derechos digitales, en el que acceso a una pieza de contenido se concede de acuerdo con una licencia propiedad de un propietario de licencia a un cliente que es un miembro de un dominio, conforme a una etapa de verificacion satisfactoria de que existe una relacion de pertenencia entre el cliente y el dominio como se refleja en una primera variable de estado mantenida tanto por el cliente como por un controlador del dominio, requiriendose la presencia de una primera variable de estado valida para verificar satisfactoriamente que la relacion de pertenencia existe,

y que existe una relacion de asociacion entre el propietario de licencia y el dominio como se refleja en una segunda variable de estado mantenida tanto por el controlador del dominio como por un controlador de propietario de licencia asociado con el propietario de licencia, requiriendose la presencia de una segunda variable de estado valida para verificar satisfactoriamente que la relacion de asociacion existe,

comprendiendo el metodo

revocar la relacion de pertenencia ejecutando un protocolo en lmea entre el controlador del dominio y el cliente despues de la que ambos eliminan la primera variable de estado, y

revocar la relacion de asociacion ejecutando un protocolo en lmea entre el controlador de propietario de licencia y el controlador del dominio despues de la cual el controlador del dominio elimina la segunda variable de estado y despues de la cual la administracion de estado relacionada con el dominio se propaga al cliente de modo que la segunda variable de estado se elimina por el cliente.

2. El metodo de la reivindicacion 1, en el que la verificacion de la relacion de asociacion y la relacion de pertenencia comprende evaluar un periodo de validez de la relacion en cuestion segun se expressa mediante la informacion de estado y verificar satisfactoriamente la asociacion en cuestion unicamente si el periodo de validez no ha expirado.

3. El metodo de la reivindicacion 1, en el que adicionalmente el controlador de dominio y el cliente mantienen una tercera variable de estado para proteger el estado de la licencia.

4. El metodo de la reivindicacion 3, en el que la tercera variable de estado contiene una representacion de un identificador para la licencia.

5. El metodo de la reivindicacion 3, en el que el controlador del propietario de licencia crea la tercera variable de estado y propaga la tercera variable de estado al controlador de dominio quien propaga la tercera variable de estado al cliente.

6. El metodo de la reivindicacion 1, en el que la relacion de asociacion entre el propietario de licencia y el dominio se expresa en una certificacion en la que se identifican el propietario de licencia y el dominio.

7. El metodo de la reivindicacion 1 o 4, en el que la relacion de pertenencia entre el cliente y el dominio se expresa en una certificacion en la que se identifican el cliente y el dominio.

8. El metodo de la reivindicacion 4 y/o 5, en el que la certificacion transporta una identificacion de su periodo de validez.

9. El metodo de la reivindicacion 1, en el que el cliente tiene una administracion de estado y en el que el controlador de dominio propaga la administracion de estado relacionada con el dominio al cliente, de modo que el cliente puede actualizar su administracion de estado y eliminar la variable de estado que refleja la relacion de asociacion.

10. Un sistema para gestion de derechos digitales, configurado para conceder acceso a una pieza de contenido de acuerdo con una licencia propiedad de un propietario de licencia a un cliente que es un miembro de un dominio, conforme a verificacion satisfactoria de que existe una relacion de pertenencia entre el cliente y el dominio como se refleja en una primera variable de estado y

que existe una relacion de asociacion entre el propietario de licencia y el dominio como se refleja en una segunda variable de estado, requiriendose la presencia de una primera variable de estado valida para verificar satisfactoriamente que la relacion de pertenencia existe, requiriendose la presencia de una segunda variable de estado valida para verificar satisfactoriamente que la relacion de asociacion existe,

configurandose el cliente y un controlador del dominio para mantener ambos la primera variable de estado, y configurandose para revocar la relacion de pertenencia ejecutando un protocolo en lmea entre los mismos despues de la que ambos eliminan la primera variable de estado,

configurandose el controlador del dominio y un controlador de propietario de licencia asociado con el propietario de licencia para mantener ambos la segunda variable de estado, y configurandose para revocar la relacion de asociacion ejecutando un protocolo en lmea entre los mismos despues de la que ambos eliminan la segunda variable de estado, configurandose el controlador del dominio adicionalmente para propagar la administracion de estado relacionada con el dominio al cliente para provocar que el cliente elimine la segunda variable de estado.