MXPA04001728A

MXPA04001728A - Inscripcion y sub-inscripcion de un servicio de administracion de derechos digitales dentro de una arquitectura de administracion de derechos.

Info

Publication number: MXPA04001728A
Application number: MXPA04001728A
Authority: MX
Inventors: Kostal Gregory
Original assignee: Microsoft Corp
Priority date: 2003-02-25
Filing date: 2004-02-24
Publication date: 2004-12-02
Also published as: ATE375646T1; TWI362872B; CN1531253A; US20040168061A1; PL365549A1; BRPI0400335A; IL160352A; KR101143228B1; ZA200401306B; DE602004009354T2; RU2004105509A; MY144595A; HK1067478A1; CL2004000324A1; JP4524124B2; CA2457938C; AU2004200454B2; SG135945A1; DE602004009354D1; NO20040816L

Abstract

Un sistema de administracion de derechos digitales (DRM) tiene una pluralidad de servidores DRM que llevan a cabo funciones DRM y un servidor DRM-E entrante se inscribe dentro del sistema al inscribir al servidor DRM-R de tal forma que el servidor DRM-E entrante debe estar confiado dentro del sistema. El servidor DRM-E envia una solicitud de inscripcion al servidor DRM-R que incluye una identificacion y una clave publica (PU-E). El servidor DRM-R valida la identificacion y cuando la solicitud se va a autorizar, genera un certificado de inscripcion digital con la (PU-E) para el servidor DRM-E para inscribir al servidor DRM-E dentro del sistema DRM. El ahora servidor DRM-E inscrito con el certificado de inscripcion generado tiene la capacidad de emplear el mismo para emitir documentos DRM dentro del sistema DRM.

Description

INSCRIPCIÓN Y SUB-INSCRIPCIÓN DE UN SERVIDOR DE ADMINISTRACIÓN DE DERECHOS DIGITALES DENTRO DE UNA ARQUITECTURA DE ADMINISTRACIÓN DE DERECHOS DIGITALES REFERENCIAS CRUZADAS CON SOLICITUDES RELACIONADAS Las siguientes Solicitudes de Patentes de Estados Unidos exponen materia relacionada con el tema de la presente solicitud, y se incorporan en la presente como referencia. La solicitud de Patente de Estados Unidos No. 10/185,527, presentada el 28 de junio de 2002, con el número de referencia de abogado SFT-1330, titulada "Obtener una Etiqueta de Derechos Firmados (SRL) para un Contenido digital y obtener la licencia digital correspondiente para el contenido con base en la SRL en un sistema de administración de derechos digitales ( D R ) " . La solicitud de Patente de Estados Unidos No. 10/185,278, presentada el 28 de junio de 2002, con el número de referencia de abogado MSFT-1333, titulada "Uso de una plantilla de derechos para obtener una Etiqueta de Derechos Firmados (SRL) para un Contenido digital en un sistema de administración de derechos digitales ( D R M ) " . La solicitud de Patente de Estados Unidos No. 10/185,511, presentada el 28 de junio de 2002, con el número de referencia de abogado MSFT- 343, titulada "Sistemas y Métodos para emitir licencias de uso para contenido digital y servicios". La solicitud de Patente de Estados Unidos No. , presentada el con el número de referencia de abogado SFT-1498, titulada "Publicación de contenido digital dentro de una organización de acuerdo con un sistema de administración de derechos digitales (DRM)". La solicitud de Patente de Estados Unidos No. , presentada el , con el número de referencia de abogado MSFT-1569, titulada "Publicación de contenido digital dentro de una organización de acuerdo con un sistema de administración de derechos digitales (DRM)". La solicitud de Patente de Estados Unidos No. , presentada el , con el número de referencia de abogado MSFT-1537, titulada "Emisión de una licencia de uso de publicación fuera de línea en un sistema de administración de derechos digitales (DRM)".

CAMPO DE LA INVENCIÓN La invención se relaciona con un sistema de administración de derechos digitales (DRM). Más en particular, la invención se relaciona con el empleo de un sistema DRM para publicar contenido digital en una organización, tal como una oficina o corporación o semejante, de tal modo que la reproducción y uso del contenido dentro de la organización se pueda restringir de conformidad con el uso correspondiente o con términos de licencias. Más particularmente, la presente invención se relaciona con una red de servidores DR que efectúan el sistema DRM y un método para inscribir y sub-inscribir un servidor DRM dentro de la red.

ANTECEDENTES DE LA INVENCIÓN La administración de derechos digitales y su puesta en vigor es altamente deseable con relación al contenido digital tal como audio digital, video digital, textos digitales, datos digitales, multimedia digital, etc., en donde el contenido .digital será distribuido a uno o más usuarios. El contenido digital puede ser estático, como un documento de texto, por ejemplo, o puede estar en corrientes, tal como el audio/video en corrientes de un evento en vivo. Los modos típicos de distribución incluyen dispositivos tangibles como discos magnéticos (flexibles), cintas magnéticas, discos ópticos (compactos) (CD), etc., y medios intangibles como tableros electrónicos, redes electrónicas, la Internet, etc. Luego de ser recibido por el usuario, el usuario reproduce el contenido digital con la ayuda de un dispositivo reproductor adecuado, tal como un reproductor de medios en una computadora personal o su semejante. En un escenario, el propietario del contenido o el propietario de los derechos como el autor, el publicador, el transmisor, etc, desea distribuir tal contenido digital a cada uno de los usuarios o receptores en intercambio por una cuota de licencia o alguna otra consideración. En tal caso, el contenido puede ser una canción, un grupo de canciones, una película, etc., y el propósito de la distribución es generar cuotas de licencia. El propietario del contenido, habiendo seleccionado, puede desear restringir lo que el usuario puede hacer con el contenido digital distribuido. Por ejemplo, el propietario del contenido podría restringir al usuario de copiar y re-distribuir el contenido a un segundo usuario, por lo menos en una forma que niegue al propietario del contenido de recibir la cuota por parte del segundo usuario. Además, el propietario del contenido puede desear proporcionar al usuario con la flexibilidad de comprar diferentes tipos de licencias de uso a diferentes cuotas de licencia, mientras que al mismo tiempo mantiene al usuario respetando los términos de la licencia que adquirió. Por ejemplo, el propietario del contenido puede desear permitir la distribución para que el contenido digital sea reproducido solamente un número de veces, solamente por un período determinado, en ciertos tipos de máquina, en cierto tipo de reproductor de medios o solamente por cierto tipo de usuarios. En otro escenario, un desarrollador de contenido, como un empleado o un miembro de una organización, desea distribuir el contenido digital a uno o más empleados o miembros de la organización o a otras personas fuera de la organización, pero le gustaría que otras personas no reproduzcan el contenido. Aquí, la distribución del contenido es parecida al contenido con base en la organización, que se comparte en una manera confidencial o restringida, opuesto a la distribución con base de transmisión a cambio de una cuota de licencia o alguna otra consideración.

En tal escenario, entonces el contenido puede ser la presentación de un documento, una hoja de cálculo, una base de datos, un correo electrónico, tal que se pueda intercambiar dentro de las instalaciones de la oficina y el desarrollador del contenido puede desear asegurar que el contenido no salga de la organización y no sea reproducido por personas no autorizadas, como ejemplos su competencia. Otra vez, el desarrollador del contenido desea restringir lo que el receptor hará con el contenido digital distribuido, por ejemplo, el propietario del contenido desea restringir al usuario de copiar o re-distribuir el contenido a un segundo usuario, por lo menos en una forma que exponga al contenido fuera de las personas interesadas en reproducir el contenido. Además, el desarrollador del contenido puede desear proporcionar varios receptores con diferentes niveles de derechos de reproducción. Por ejemplo, el desarrollador del contenido puede permitir que el contenido digital protegido se pueda ver pero no imprimirse con respecto a una clase de personas, y se pueda ver e imprimir por otra clase de personas. Sin embargo, en cualquier escenario, después de que ha ocurrido la distribución, el propietario/desarrollador del contenido tiene muy poco control sobre el contenido digital. Esto representa un problema en vista del hecho de que prácticamente cualquier computadora personal incluye los programas y el equipo necesarios para hacer una copia digital exacta de tal contenido digital, y para descargar la copia digital exacta en un disco óptico o magnético que se pueda escribir, o enviar a cualquier destino la copia digital exacta sobre la red, como la Internet. Por supuesto, como parte de una transacción en donde el contenido es distribuido, el propietario/desarrollador del contenido puede requerir que el usuario/receptor del contenido digital se comprometa a no distribuir el contenido digital sin autorización. Sin embargo, tal promesa se rompe con facilidad. El propietario/desarrollador del contenido puede intentar evitar la redistribución a través de varios dispositivos de seguridad, ios cuales por lo general, involucran la codificación y la decodificación. Sin embargo, existen muy pocas herramientas para evitar que un usuario determinado decodifique el contenido digital codificado, guardando en contenido digital en forma codificada y después re-distribuirlo. Por lo tanto, existe la necesidad de proporcionar una administración de derechos digitales y una arquitectura y método de aplicación que permita la reproducción controlada de formas arbitrarias del contenido digital, en donde el control sea flexible y se pueda definir por el desarrollador/propietario del contenido digital. Más específicamente, existe la necesidad de que tal arquitectura permita y facilite tal reproducción controlada, especialmente dentro de una oficina u organización, en donde los documentos van a ser compartidos entre un grupo definido de personas o clases de personas. Aun más específicamente, existe la necesidad de un método para inscribir servidores que otorgan la aprobación dentro de la arquitectura.

BREVE DESCRIPCIÓN DE LA INVENCIÓN Las necesidades antes mencionadas quedan satisfechas en parte por la presente invención en donde un sistema de administración de derechos digitales (DRM) tiene una pluralidad de servidores DRM que llevan a cabo funciones DRM y un servidor DRM-E de entrada se inscribe al sistema por un servidor DRM-R suscriptor, de tal modo que el servidor DRM-E estará confiado al sistema. En la invención, el servidor DRM-E proporciona un par de claves pública/privada (PU-E, PR-E) para identificar a tal servidor DRM-E dentro del sistema DRM, proporciona una identificación de propuesta para la misma y envía una solicitud de inscripción al servidor DRM-R que incluye la identificación de propuesta y la (PU-E). El servidor DRM-R valida la identificación de propuesta y cuando la solicitud es aprobada, genera un certificado de inscripción digital para que el servidor DRM-E se inscriba al servidor DRM-E dentro del sistema DRM. El certificado de inscripción generado está con base, por lo menos en parte en la (PU-E). El servidor DRM-R regresa el certificado de inscripción generado al servidor DRM-E solicitante y el servidor DRM-E ahora inscrito almacena el certificado de inscripción regresado en una ubicación adecuada para uso futuro. El servidor DRM-E con el certificado de inscripción tiene la capacidad de emplear el mismo para emitir documentos DRM dentro del sistema DRM.

BREVE DESCRIPCIÓN DE LOS DIBUJOS El resumen anterior, así como la siguiente descripción detallada de las modalidades de la presente invención, se comprenderán mejor cuando se lean junto con los dibujos anexos. Con el propósito de ilustrar la invención, en los dibujos se muestran las modalidades que son preferidas en la actualidad. Sin embargo, se debe entender que la invención no está limitada a los arreglos e instrumentaciones precisas mostradas. La Figura 1 es un diagrama en bloque que representa un ambiente de computación ejemplif ¡cativo en donde se puede ¡mplementar la presente invención. La Figura 2 es un diagrama en bloque que representa un ambiente de redes ejemplificativo que tiene una variedad de dispositivos de computación en donde se puede ¡mplementar la presente invención. La Figura 3 es un diagrama en bloque de funciones de una modalidad preferida de un sistema y método de conformidad con la invención, para la publicación de contenido digital. La Figura 4 es un diagrama de flujo de una modalidad preferida de un método de conformidad con la invención, para publicar el contenido digital con administración de derechos. La Figura 4A es un diagrama en bloque que muestra la estructura de una etiqueta de derechos firmados como se produce por el método de la Figura 4. La Figura 5 es un diagrama en bloque de una modalidad preferida de un sistema y método de conformidad con la invención para autorizar un contenido digital con administración de derechos.

Las Figuras 6A y 6B son diagramas de flujo de una modalidad preferida de un método de conformidad con la invención para autorizar un contenido digital con administración de derechos. La Figura 7 es un diagrama en bloque que muestra un certificado emitido por un servidor DRM para un usuario para permitir al usuario llevar a cabo una publicación fuera de línea de conformidad con una modalidad de la presente invención. La Figura 8 es un diagrama en bloque que muestra el certificado de la Figura 7 junto con una licencia de publicación que permite al usuario pubiicador reproducir el contenido publicado fuera de línea de conformidad con una modalidad de la presente invención.

La Figura 9 es un diagrama de flujo que muestra los pasos clave que el usuario lleva a cabo para obtener una licencia de publicación de la Figura 8, de conformidad con una modalidad de la presente invención. La Figura 10 es un diagrama de flujo que muestra los pasos clave que el usuario pubiicador debe llevar a cabo para emplear la licencia de publicación de la Figura 9, para así reproducir el correspondiente contenido de conformidad con una modalidad de la presente invención. La Figura 11 es un diagrama en bloque que muestra una arquitectura de aplicación de un ejemplo de un sistema con base en confianza.

La Figura 12 es un diagrama en bloque que muestra una pluralidad de servidores DRM, como los que puede haber dentro de una arquitectura de la presente invención, en donde cada servidor DRM (de entrada) se inscribe dentro de la arquitectura por otro servidor DRM (suscriptor) y le emite al primero un certificado de inscripción. La Figura 13 es un diagrama en bloque que muestra un certificado de inscripción de la Figura 12, junto con un certificado de comprobación presentado, por lo menos en algunos casos por un servidor DRM entrante a un servidor DRM suscriptor; y las Figuras 14 y 15 son diagramas de flujo que muestran los pasos clave que los servidores DRM entrante y suscriptor de la Figura 13, deben llevar a cabo para inscribir (Figura 14) o sub-inscribir al servidor DRM entrante.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN AMBIENTE DE COMPUTADORA La Figura 1 y la siguiente descripción tienen el propósito de proporcionar una breve descripción general de un ambiente de computación apropiado en donde se puede implementar la invención. Sin embargo, se debe entender que se contemplan los dispositivos manuales, portátiles así como otros dispositivos de computación para que se puedan utilizar en conexión con la presente invención. Aunque a continuación se describe una computadora de propósitos generales, es solamente un ejemplo y la presente invención requiere solamente un cliente que tenga una interoperación e interacción con un servidor de redes. De este modo, la presente invención se puede implementar en un ambiente de servicios de red, en donde los recursos del cliente están implicados, por ejemplo, un ambiente de redes en donde los servidores del dispositivo del cliente solamente funcionen como navegadora o una interfaz para la World Wide Web.

Aunque no es requerido, la invención se puede implementar a través de una interfaz de programación de aplicaciones (API) para ser usada por un desarrollados y/o incluirse en el programa navegador de la red, que será descrito en el contexto general de las instrucciones ejecutables por computadora, como módulos de programa, a ser ejecutados por una o más computadoras, como estaciones de trabajo del cliente, servidores u otros dispositivos. En general, los módulos de programa incluyen rutinas, programas, objetivos, componentes, estructuras de datos, y sus semejantes para llevar a cabo tareas particulares o para implementar tipos de datos abstractos particulares. Típicamente, la funcionalidad de los módulos de programa se puede combinar o distribuir según sea deseado en diferentes modalidades. Además, las personas experimentadas en la técnica entenderán que la invención se puede practicar con otras configuraciones de sistemas de computación. Otros sistemas, ambientes y/o configuraciones bien conocidos que son adecuados para utilizarse con la invención incluyen, pero no están limitados a computadoras personales (PC), máquinas automatizadas, computadoras servidores, dispositivos portátiles o manuales, sistemas multi-procesadores, sistemas con base en microprocesadores, electrónicos consumibles programables, PC en red, minicomputadoras, computadoras principales y sus semejantes. La invención también se puede practicar en ambientes de computación distribuidos, en donde las tareas se llevan a cabo por dispositivos de procesamiento remoto que están enlazadas a través de una red de comunicaciones o un medio de transmisión de datos. En un ambiente de computación distribuido, los módulos de programa se pueden ubicar en el medio de almacenamiento de la computadora local y en un medio remoto incluyendo dispositivos de almacenamientos de memoria. La Figura 1 ilustra un ejemplo de un ambiente 100 de un sistema de computación adecuado en donde se puede implementar la presente invención, el ambiente 100 del sistema de computación es solamente un ejemplo de un ambiente de computación adecuado y no tiene la intención de sugerir ninguna limitación al alcance de uso o funcionalidad de la invención. Tampoco, se debe interpretar que el ambiente 100 de computación tiene una dependencia o requerimiento relacionado con una combinación de componentes ilustrados en el ambiente 100 operativo ejemplificativo. Con referencia a la Figura 1, un sistema ejemplificativo para implementar la invención incluye un dispositivo de computación de propósitos generales en la forma de una computadora 110. Los componentes de la computadora 110 pueden incluir, pero no están limitados a una unidad 120 de procesamiento, una memoria 130 del sistema y una barra colectora 121 del sistema que acopla los diferentes componentes del sistema incluyendo a la memoria del sistema con la unidad 120 de procesamiento. La barra colectora 121 del sistema puede ser de cualquier tipo de estructuras de barra colectora incluyendo una barra colectora de memoria o un controlador de memoria, una barra colectora periférica, y una barra colectora local que utiliza una variedad de arquitecturas de barra colectora. A manera de ejemplo, sin limitar, tales arquitecturas incluyen la barra colectora de Arquitectura de Norma Industrial (ISA), barra colectora de Arquitectura de Micro Canal (MCA), barra colectora de ISA Mejorada, barra colectora local de la Asociación de Normas electrónicas de Video (VESA), y barra colectora de Interconexión de Componentes Periféricos (PCI) (también conocida como barra colectora Mezzanine). La computadora 110 típicamente incluye una variedad de medios legibles por computadora. El medio legible por computadora puede ser cualquier medio disponible que pueda tener acceso por medio de la computadora 110 e incluye medios volátiles y no volátiles, medios retirables y no retirables. A manera de ejemplo, sin limitar el medio legible por computadora puede comprender un medio de almacenamiento de computadora y un medio de comunicación. El medio de almacenamiento de la computadora incluye medios volátiles y no volátiles, medios retirables y no retirables implementados por cualquier método o tecnología para el almacenamiento de información como instrucciones legibles por computadora, estructuras de datos, módulos de programa y otros datos. El medio de almacenamiento de la computadora incluye, pero no se limita a RAM, ROM, EEPROM, memoria flash u otra tecnología de memorias, CDROM, discos versátiles digitales (DVD) u otro almacenamiento de disco óptico, cartuchos magnéticos, cintas magnéticas, almacenamiento de disco magnético, otros dispositivos de almacenamiento magnético, o cualquier otro medio que se pueda utilizar para almacenar la información deseada y que pueda tener acceso mediante la computadora 110. Los medios de comunicación típicamente incorporan instrucciones legibles por computadora, estructuras de datos, módulos de programa y otros datos en una señal de datos modulada como una onda portadora u otro mecanismo de transporte e incluye un medio de entrega de información. El término " señal de datos modulada" significa una señal que tiene una o más de sus características ajustadas o cambiadas de tal forma que pueda codificar la información de la señal. A manera de ejemplo, no limitante, el medio de comunicación incluye medios cableados como una red cableada o una conexión directa, y medios inalámbricos como un medio inalámbrico acústico, RF, infrarrojo, u otro medio inalámbrico. Las combinaciones de cualesquiera de los anteriores también debe estar incluida dentro del alcance de los medios legibles por computadora. La memoria 130 del sistema incluye un medio de almacenamiento de la computadora en forma de una memoria volátil o no volátil como una memoria de solamente lectura (ROM) 131, y una memoria de acceso aleatorio (RAM) 132. Un sistema de entrada/salida básico 133 (BIOS) que contiene las rutinas básicas que ayudan a la transferencia de información entre los elementos dentro de una computadora 110, como durante el inicio, se almacena en una ROM 131. La RAM 132 típicamente contiene datos y/o módulos de programa que tienen acceso inmediato y/o que se operan en la unidad 120 de procesamiento. A manera de ejemplo, sin limitar, la Figura 1 ilustra un sistema 134 operativo, los programas 135 de aplicación, otros módulos 136 de programa y datos 137 de programa. La computadora 110 también puede incluir otros medios de almacenamiento de computadora retirables/no retirables, volátiles/no volátiles. Solamente como ejemplo, la Figura 1 ilustra una unidad 141 de disco duro que lee y escribe sobre un medio magnético no-retirable, no-volátil, una unidad 151 de disco magnético que lee o escribe en un disco 152 retirable, no volátil, y una unidad 155 de disco óptico que lee y escribe en un disco 156 óptico retirable, no volátil, como un CDROM u otro medio óptico. Otros medios de almacenamiento de computadora retirables/no retirables, volátiles/no volátiles que se pueden utilizar en el ambiente operativo ejemplificativo incluyen, pero no se limitan a, cartuchos de cinta magnética, tarjetas de memoria flash, discos versátiles digitales, cintas de video digital, RAM de estado sólido, ROM de estado sólido y sus semejantes. La unidad 141 de disco duro típicamente se conecta con la barra colectora 121 del sistema a través de una interfaz de memoria no retirable como la interfaz 140, y la unidad 151 de disco magnético y la unidad 155 de disco óptico se conectan típicamente, con la barra colectora 121 del sistema mediante una interfaz de memoria retirable, como la interfaz 150. Las unidades y sus medios de almacenamiento de computadora asociados, antes descritos e ilustrados en la Figura 1, proporcionan el almacenamiento de las instrucciones legibles por computadora, estructuras de datos, módulos de programa y otros datos para la computadora 110. En la Figura 1, por ejemplo, la unidad 141 de disco duro se ilustra almacenando al sistema 144 operativo, a los programas 145 de aplicación, otros módulos 146 de programa y los datos 147 del programa. Se debe observar que estos componentes pueden ser los mismos o diferentes al sistema 134 operativo, las aplicaciones 135 de programa, otros módulos 135 de programa, y datos 137 de programa. El sistema 144 operativo, los programas 145 de aplicación, otros módulos 146 de programa y los datos 147 de programa tienen diferentes números de referencia con el fin de ilustran son diferentes copias, por lo mínimo. Un usuario puede introducir instrucciones e información dentro de la computadora 110 a través de los dispositivos de entrada como un teclado 162, un dispositivo 161 puntero, comúnmente llamado mouse, una bola seguidora o una pantalla de tacto. Otros dispositivos de entrada (no mostrados) pueden incluir un micrófono, una palanca de comandos, un cojín de juegos, un disco satelital, un escáner o su semejante. Estos y otros dispositivos de entrada con frecuencia se conectan con la unidad 120 de procesamiento a través de una interfaz 160 de entrada del usuario que se acopla con la barra colectora 121 del sistema, pero se puede conectar con otra interfaz y estructuras de barra colectora, como un puerto paralelo, un puerto de juegos o una barra colectora en serie universal (USB). Un monitor 191 u otro tipo de dispositivo de despliegue también se conecta con la barra colectora 121 del sistema a través de una interfaz, como una interfaz 190 de video. Una interfaz 182 de gráficos, como Northbridge, puede conectarse con la barra colectora 121 del sistema. Northbridge es un juego de chips que se comunican con la CPU, o la unidad de procesamiento principal 120 y adopta la responsabilidad de las comunicaciones aceleradas para un puerto de gráficos (AGP). Una o más unidades de procesamiento de gráficos (GPU) 184 se pueden comunicar con la interfaz 182 de gráficos. Con respecto a esto, las GPU 184, por lo general, incluyen un elemento de memoria en chip, como un almacenamiento de registro, y las GPU 184 se comunican con una memoria 186 de video. Sin embargo, las GPU 184 son un ejemplo de un co-procesador y de este modo varios dispositivos co-procesadores se pueden incluir en la computadora 110. Un monitor 191 u otro tipo de dispositivo de despliegue también se conecta con la barra colectora 121 del sistema a través de una interfaz, como una interfaz 190 de video, la cual a su vez, se comunica con la memoria 186 de video. Además del monitor 191, las computadoras también pueden incluir otros dispositivos periféricos de salida como bocinas 197 e impresoras 196, que estarán conectadas a través de una interfaz 195 periférica de salida. La computadora 110 puede operar en un ambiente de redes con el uso de conexiones lógicas a una o más computadoras remotas, como una computadora 180 remota. La computadora 180 remota puede ser una computadora personal, un servidor, un enrutador, una PC en red, un dispositivo adjunto o un nodo común de red, e típicamente incluye muchos o todos los elementos descritos antes con relación a la computadora 110, aunque en la Figura 1 solamente se ilustra el dispositivo 181 de almacenamiento de memoria. Las conexiones lógicas ilustradas en la Figura 1 incluyen una red de área local (LAN) 171, y una red de área amplia (WAN) 173, pero también pueden incluir otras redes. Tales ambientes de redes son comunes en oficinas, redes de computación a nivel mundial, intranets y la Internet. Cuando se utiliza en una ambiente de red LAN, la computadora 110 se conecta con la LAN 171 a través de una interfaz o adaptador 170 de red. Cuando se utiliza en un ambiente de red WAN, la computadora 110 típicamente incluye un módem 172 u otro medio para establecer las comunicaciones sobre la WAN 173, como la Internet. El módem 172 que puede ser interno o externo, puede conectarse con la barra colectora 121 del sistema a través de una interfaz 160 de entrada del usuario, u otro mecanismo adecuado. En un ambiente de red, los módulos de programa ilustrados con relación a la computadora 110, o porciones de la misma se pueden almacenar en el dispositivo de almacenamiento de memoria remota. A manera de ejemplo y sin limitar, la Figura 1 ilustra programas 185 de aplicación remota residiendo en el dispositivo 181 de memoria. Se debe apreciar que las conexiones de red mostradas son ejemplificativas y se pueden utilizar otros medios para establecer un enlace de comunicaciones entre las computadoras. Las personas experimentadas en la técnica podrán reconocer que la computadora 110 u otro dispositivo del cliente se pueden desplegar como parte de una red de computadoras. Con respecto a esto, la presente invención pertenece a cualquier sistema de computadora que tiene un número de memorias o de unidades de almacenamiento, y cualquier número de aplicaciones y procesos que se presentan en cualquier número de unidades de almacenamiento. La presente invención se puede aplicar a un ambiente con computadoras servidoras o computadoras del cliente desplegadas en un ambiente de red, con un almacenamiento remoto o local. La presente invención también se puede aplicar a un dispositivo computadora independiente, que tiene funciones de lenguajes de programación, interpretación y capacidades de ejecución. Las instalaciones de computación distribuida compartes recursos y servicios de computación mediante un intercambio directo entre los dispositivos y sistemas de computación. Estos recursos y servicios incluyen el intercambio de información, almacenamiento caché y almacenamiento de discos para archivos. La computación distribuida toma ventaja de la conectividad de la red, lo que permite a los clientes aprovechar su potencial colectivo para beneficiar a la organización completa. Con respecto a esto, una variedad de dispositivos pueden tener ciertas aplicaciones, objetivos o recursos que pueden interactuar para ¡mplementar las técnicas de autenticación de la presente invención, con el fin de tener canales gráficos confiables. La Figura 2 proporciona un diagrama esquemático de una red ejemplificativa o un ambiente de computación distribuido ejemplificativo. El ambiente de computación distribuido comprende objetivos 10A, 10b de computación, y objetos o dispositivos 110A, 110b, 110c, etc de computación. Estos objetos pueden comprender programas, métodos, almacenamientos de datos, lógicos programables, etc.. Estos objetos pueden comprender porciones de los mismos dispositivos o diferentes como PDA, televisiones, reproductores MP3, computadoras personales, etc. Cada objeto puede comunicarse con otro objeto mediante una red 14 de comunicaciones. Esta red, en sí, puede comprender otros objetos de computación y dispositivos de computación que proporcionan servicios al sistema de la Figura 2. De conformidad con un aspecto de la invención, cada objeto 10 ó 110 puede contener una aplicación que pueda solicitar las técnicas de autenticación de la presente invención para un canal de gráficos confiables. También, se debe observar que un objeto, como el 110c puede estar hospedado en cualquier otro dispositivo 10 ó 110 de computación. De este modo, aunque el ambiente físico ilustrado puede mostrar dispositivos conectados como computadoras, tal ilustración es solamente ejemplificativa y el ambiente físico puede ilustrarse o describirse con varios dispositivos digitales como PDA, televisiones, reproductores MP3, etc., objetos de programas como interfaces, objetos COM y sus semejantes. Existen una variedad de sistema, componentes y configuraciones de redes que dan soporte a los ambientes de computación distribuida. Por ejemplo, los sistemas de computación se pueden conectar juntos mediante sistemas inalámbricos o cableados, mediante redes locales o redes distribuidas ampliamente. En la actualidad, muchas redes se acoplan con la Internet, la cual proporciona la infraestructura para una computación distribuida ampliamente y abarca muchas redes diferentes. En ambientes de redes caseras, existen por lo menos cuatro medios de transporte de red diferentes, cada uno de ellos puede dar soporte a un único protocolo como una Power line, datos (tanto inalámbrico como cableado), voz (por ejemplo, teléfono), y medios de entretenimiento. La mayoría de los dispositivos de control casero como interruptores de luz y electrodomésticos pueden utilizar la línea de energía para su conectividad. Los servicios de datos pueden entrar en la casa como una transmisión (por ejemplo, ya sea DSL o módem por cable), y tiene acceso dentro de la casa con el uso de una conectividad inalámbrica (por ejemplo, HomeRF o 802.11 b) o cableada (por ejemplo, HomePNA, Cat 5 o incluso la línea de energía). El tráfico de voz puede entrar en la casa en forma cableada (por ejemplo, Cat 3) o inalámbrica (por ejemplo, teléfonos celulares) y se puede distribuir dentro de la casa con el uso de un cableado Cat 3. Los medios de entretenimiento pueden entrar en la casa con el uso de un satélite o cable y típicamente se distribuye en la casa con el uso de un cable coaxial. Las normas IEEE 1394 y DVI también están surgiendo como interconexiones digitales para grupos de dispositivos de medios. Todos estos ambientes de red y otros pueden emerger como normas de protocolo que se pueden interconectar para formar una intranet que se puede conectar con el mundo exterior por medio de la Internet. En breve, existe una gran variedad de fuentes para el almacenamiento y transmisión de datos, y en consecuencia los dispositivos de computación requerirán formas para proteger contenidos en todas las porciones del canal de procesamiento de datos. Por lo general, la "Internet" se refiere a la recolección de redes y pasarelas que utilizan el grupo TCP/IP de protocolos, que son bien conocidos en la técnica de la redes de computación. TCP/IP es el acrónimo de "Protocolo de Control de Transporte/Programa de Interfaz. La Internet se puede describir como un sistema de redes de computación remotas distribuidas en forma geográfica interconectadas por computadoras que ejecutan los protocolos de redes, lo cual permite a los usuarios interactuar y compartir información sobre las redes. Debido a la capacidad de compartir información a nivel mundial, las redes remotas como la Internet, han progresado dentro de un sistema abierto para el cual los desarrolladores pueden diseñar diferentes aplicaciones de programas para llevar a cabo operaciones y servicios especializados, esencialmente sin ninguna restricción. De este modo, la infraestructura de la red autoriza a un huésped de las topologías de la red como un cliente/servidor, punto a punto, o arquitecturas híbridas. El "cliente" es un miembro de una clase o grupo que utiliza los servicios de otra clase o grupo sin estar relacionado con el mismo. De esta forma, dentro de la computación, un cliente es un proceso, es decir, en forma burda un grupo de instrucciones o tareas, el cual solicita un servicio provisto por otro programa. El proceso del cliente utilizan el servicio solicitado sin tener que "conocer" los detalles de funcionamiento del otro programa o del servicio en sí. En una arquitectura de cliente/servicio, particularmente en un sistema en red, un cliente usualmente es una computadora que tiene accesos a los recursos compartidos de la red provistos por otra computadora, por ejemplo, un servidor. En el ejemplo de la Figura 2, las computadoras 110A, 110b etc., se pueden considerar como los clientes y la computadora 10A, 10b, etc., se puede considerar como el servidor, en donde el servidor 10A, 10b, etc., mantiene los datos que después se replican a las computadoras 110A, 110b etc., del cliente. Por lo general, un servidor es típicamente un sistema de computadora remota al cual se tiene acceso sobre una red remota como la Internet. El proceso del cliente puede estar activo en un primer sistema de computadora, y el proceso del servidor puede estar activo en un segundo sistema de computadora, los cuales se comunican entre sí a través de un medio de comunicaciones, lo cual proporciona la funcionalidad distribuida y permite que varios clientes tomen ventaja de las capacidades de recolección de información del servidor. El cliente y el servidor se comunican entre sí con el uso de las funciones provistas por un estrato de protocolo. Por ejemplo, el Protocolo de Transferencia de Hiper-texto (http) es un protocolo común que se utiliza junto con la World Wide Web (WWW). Típicamente, se utiliza una dirección de una red de computadora tal como un Localizador Universal de Recursos (URL) o una dirección de Protocolo de Internet (IP) para identificar al servidor o las computadoras del cliente entre sí. La dirección de red se puede llamar como dirección de Localizador Universal de Recursos. Por ejemplo, la comunicación puede ser provista sobre un medio de comunicaciones. En particular, el cliente y el servidor pueden acoplarse entre sí a través de las conexiones TCP/IP para una comunicación de alta capacidad. De este modo, la Figura 2 ilustra una ambiente distribuido o de red ejemplificativo, con un servidor en comunicación con las computadoras del cliente a través de una red/barra colectora, en donde se puede emplear la presente invención. Con más detalle, un número de servidores 10A, 10b, etc., están interconectados a través de una red/barra colectora 14 de comunicaciones, que puede ser una LAN, WAN, intranet, la Internet, etc., con un número de dispositivos 110A, 110b, 110c, 110d, 110e, etc., de computación remota o dispositivos del cliente, tal como una computadora portátil, una computadora manual, un electrodoméstico en red, u otro dispositivo, como una VCR, una televisión, un horno, la luz, un calentador y sus semejantes de conformidad con la presente invención. Es así como se contempla que la presente invención se puede aplicar a cualquier dispositivo de computación en conexión con el cual se desea procesar, almacenar o reproducir contenido seguro desde una fuente confiable. En un ambiente de red en donde la red/barra colectora 14 de comunicaciones es la Internet, por ejemplo, los servidores 10 pueden ser servidores Web con los cuales se comunican los clientes 110A, 110b, 110c, 110 d , 11 Oe , etc., a través de un número de protocolos conocidos como el http. Los servidores 10 también pueden funcionar como clientes 110, ya que pueden ser característicos de un ambiente de computación distribuido. Las comunicaciones pueden ser cableadas o inalámbricas, en donde sea apropiado. Los dispositivos 110 del cliente pueden comunicarse o no a través de la red/barra colectora 14 de comunicaciones, y pueden tener comunicaciones independientes asociadas con los mismos. Por ejemplo, en el caso de una TV o VCR, puede haber o no un aspecto en red para el control del mismo. Cada computadora 110 del cliente y la computadora 10 del servidor puede estar equipada con varios módulos de programa de aplicación u objetos 135 y con conexiones o accesos para varios tipos de elementos u objetos de almacenamiento, mediante los cuales se pueden almacenar archivos o se pueden descargar o enviar porciones de archivos. De este modo, la presente invención puede utilizarse en un ambiente de red de computación que tiene computadoras 110A, 110b, etc., del cliente e interactúan con una red/barra colectora14 de la computadora y computadoras 10a 10b, etc., de servidor que pueden ¡nteractuar con las computadoras 110A, 110b, etc., del cliente y otros dispositivos 111 y bases de datos 20.

Análisis de la Administración de Derechos Digitales (DRM) Como es conocido y con referencia ahora a la Figura 11, la administración de derechos digitales (DRM) y su puesta en vigor es altamente deseable en conexión con el contenido 12 digital, tal como audio digital, video digital, texto digital, datos digitales, multimedia digital, etc., en donde el contenido 12 digital va a ser distribuido a los usuario. Luego de ser recibido por el usuario, el usuario reproduce el contenido digital con la ayuda de un dispositivo reproductor adecuado como un reproductor de medios en una computadora 14 personal o su semejante. Típicamente, el propietario o desarrollador (de aquí en adelante llamado "propietario") del contenido desea distribuir el contenido 12 digital para restringir las acciones del usuario sobre el contenido 12 digital. Por ejemplo, el propietario del contenido deseará restringir al usuario de copiar o re-distribuir el contenido 12 para un segundo usuario, o deseará permitir que el contenido 12 digital sea visto solamente un número limitado de veces, solamente por un período predeterminado, en cierto tipo de máquina, solamente por cierto tipo de reproductor de medios, solamente por cierto tipo de usuarios, etc. Sin embargo, después de que ha ocurrido la distribución, el propietario del contenido tiene muy poco control sobre el contenido digital. Un sistema 10 DRM, permite la reproducción controlada para evitar formas arbitrarias del contenido 12 digital, en donde el control es flexible y se puede definir por el propietario del contenido del contenido digital. Típicamente, el contenido 12 se distribuye al usuario en forma de un paquete 13 por medio de un canal de distribución adecuado. El paquete 13 de contenido digital distribuido puede incluir el contenido 12 digital codificado con una clave de codificación/decodificación (KD), (es decir, (KD(CONTENT))), así como con otra información que identifique el contenido, la forma de adquirir una licencia para el contenido, etc. El sistema 10 DRM con base en la confianza permite al propietario del contenido 12 digital especificar reglas de licencia que deben cumplirse antes de que se permita reproducir el contenido 12 digital en el dispositivo 14 de computación del usuario. Estas reglas de licencia pueden incluir el requerimiento temporal antes mencionado y se pueden incorporar dentro de una licencia digital o un documento de uso (de aquí en adelante "licencia") 16 que el dispositivo 14 de computación del usuario (de aquí en adelante, estos términos podrán intercambiarse a menos que se indique lo contrario), debe adquirir del propietario del contenido o un agente del mismo. La licencia 16 también incluye la clave de decodificación (KD) para decodificar el contenido digital, probablemente codificado de acuerdo con una clave decodificable por el dispositivo de computación del usuario. El propietario del contenido para una porción del contenido 12 digital debe confiar que el dispositivo 14 de computación del usuario obedecerá las reglas y requerimientos especificados por el propietario del contenido en la licencia 16, es decir, que el contenido 12 digital no se podrá reproducir hasta que se cumpla con las reglas y requerimientos dentro de la licencia 16. De preferencia, el dispositivo 14 de computación del usuario está provisto con un mecanismo 18 o componente de confianza que no reproducirá el contenido 12 digital a menos que sea de conformidad con las reglas de la licencia incorporada en la licencia 16 asociada con el contenido 12 digital y adquirida por el usuario. El componente 18 de confianza típicamente tiene un evaluador 20 de licencia que determina si la licencia es válida, revisa las reglas y requerimientos de la licencia válida 16, y determina si el usuario solicitante tiene derecho para reproducir el contenido 12 digital con base en las reglas revisadas de la licencia, para reproducirlo en la manera descrita, entre otras cosas. Como se debe entender, el evaluador 20 de la licencia está relacionado con el sistema 10 DRM para llevar a cabo los deseos del propietario del contenido 12 digital de conformidad con las reglas y requerimientos de la licencia 16, y el usuario no tendrá la capacidad de alterar fácilmente el elemento de confianza con cualquier propósito. Como se debe entender, las reglas y requerimientos en la licencia 16 pueden especificar si el usuario tiene derecho para reproducir el contenido 12 digital con base en varios factores, incluyendo su identidad, su ubicación, el tipo de dispositivo de computación que utiliza, la aplicación de reproducción que solicita al sistema DRM, la fecha, la hora, etc., Además, las reglas y requerimientos de la licencia 16 pueden limitar la licencia 16 a un número de reproducciones predeterminada, y un tiempo de reproducción predeterminado, por ejemplo. Las reglas y requerimientos se pueden especificar en la licencia 16 de conformidad con un lenguaje y sintaxis adecuados. Por ejemplo, el lenguaje solamente puede especificar los atributos y valores que se deben satisfacer (DATE debe estar después de X), o puede requerir el desempeño de las funciones de conformidad con un escrito especificado (si DATE es mayor que X, ENTONCES HACER...). Después de que el evaluador 20 de licencia determina que la licencia 16 es válida y que el usuario cumple con las reglas y requerimientos de la misma, se puede reproducir el contenido 12 digital. En particular, para reproducir el contenido 12, se obtiene la clave de decodificación ( D) de la licencia 12 y se aplica al (KC(CONTENT) desde el paquete 13 de contenido para dar como resultado el contenido 12 real, y el contenido 12 real se reproduce.

Publicación del Contenido Digital La Figura 3 es un diagrama en bloque funcional de un sistema y método para publicar contenido digital. "Publicar" como se utiliza aquí, significa a un proceso que sigue una aplicación o servicio para establecer con una entidad de confianza un grupo de derechos o condiciones que la entidad debe cumplir para el contenido, así como a quién se van a emitir los derechos y condiciones. De conformidad con la invención, el proceso de publicación incluye la codificación del contenido digital y la asociación de una lista de derechos en vigor que el autor del contenido propone para los posibles usuarios del contenido. Este proceso se puede llevar a cabo en una forma que asegure prohibir el acceso a cualquiera de los derechos o al contenido a menos que sea por el propio autor del contenido. Se emplean tres entidades para publicar un contenido digital seguro: una aplicación 302 de preparación del contenido que se lleva a cabo con el cliente 300 y prepara el contenido para su publicación, una interfaz 306 de programa de aplicación (API) de administración de derechos digitales (DRM) que también reside en el dispositivo 300 del cliente y un servidor 320 DRM que se acopla en comunicación con el cliente 300 a través de una red 330 de comunicaciones como la Internet, una red local o de área amplia, o una combinación de las mismas. La aplicación 302 de preparación del contenido puede ser cualquier aplicación que produzca el contenido digital. Por ejemplo, la aplicación 302 puede ser un procesador de palabras u otro publicador que produzca archivos de texto digitales, música, video u otro contenido digital. El contenido también puede incluir contenido en corrientes, como un audio/video en corrientes de un evento en vivo o grabado. La aplicación 302 está provista con una clave criptográfica para codificar el contenido digital, lo cual forma un archivo 304 de contenido digital codificado, y el usuario proporciona los datos de derechos para estar asociado con el contenido codificado en el archivo 304 de contenido digital. Los datos de derechos incluyen la identidad de cada entidad que tiene derechos sobre el contenido digital y un grupo de derechos y condiciones para cada entidad identificada. La entidad puede ser por ejemplo, una persona, una clase de personas o un dispositivo. Los derechos pueden incluir el derecho a leer, editar, copiar, imprimir, etc., el contenido digital. Las condiciones pueden incluir requerimientos mínimos del sistema, limitaciones de fecha y horas, contadores de juegos, y sus semejantes. La API 306 del cliente pasa el contenido digital codificado y los datos de derechos al servidor 320 DRM. Con el uso de proceso que a continuación se describe, el servidor 320 DRM determina sí puede aplicar los datos de derechos y si el así el servidor 320 DRM firma los datos de derechos para formar una etiqueta de derechos firmada (SRL) 308. Sin embargo, por lo general, cualquier entidad de confianza puede firmar los datos de derechos, de preferencia, con el uso de una clave confiada al servidor 320 DRM. Por ejemplo, el cliente puede firmar los datos de derechos con el uso de una clave provista por el servidor 320 DRM. La etiqueta 308 de derechos puede incluir datos que representan la descripción de los derechos, la clave del contenido codificado, y la firma digital sobre la descripción de derechos y la clave del contenido codificado. Cuando el servidor 320 DRM firma la etiqueta de derechos, regresa la etiqueta 308 de derechos firmados al cliente a través de la API 306 del cliente, la cual almacena la etiqueta 308 de derechos firmados en el dispositivo 300 del cliente. La aplicación 302 de preparación del contenido se asocia con la etiqueta 308 de derechos firmada con el archivo 304 de contenido digital codificado, como por ejemplo con la concatenación para formar un archivo 310 de contenido administrado con derechos. Se debe notar, que la SRL 308 se puede almacenar en una ubicación conocida por separado del archivo 304 del contenido con una referencia para la SRL 308 concatenada con el archivo 304 del contenido para formar el archivo 310 de contenido. Con referencia ahora a la Figura 4, se muestra un método para publicar contenido digital administrado con derechos. En el paso 402, la aplicación 302 genera una clave del contenido (CK) que se utilizan para codificar el contenido digital. La clave del contenido (CK) típicamente es una clave simétrica, aunque se puede utilizar cualquier clave para codificar el contenido digital. Como es conocido, la clave simétrica se utiliza por un algoritmo de clave simétrica tanto para codificar como para decodificar. De conformidad con esto, la (C ) debe estar oculta cuando se comparte entre el remitente y el receptor. En el paso 404, la aplicación 302 codifica el contenido digital con la (CK) para formar el contenido 304 digital codificado (es decir, (CK(contenido)). Además, se generan los datos de derechos correspondientes a (CK(contenido)), ya sea por el publicador del contenido o por otra entidad. Se debe notar que los datos de derechos pueden ser datos de derechos acostumbrados o datos de derechos obtenidos de una plantilla predefinida. Como se describió antes, los datos de derechos pueden incluir una lista de entidades que estarán facultadas para consumir el contenido, los derechos específicos que cada una de las entidades posee con respecto al contenido y cualquier condición impuesta en estos derechos. En el paso 406, la API 306 genera una segunda clave (K2) de codificación, la cual se utilizan para codificar la clave del contenido (CK). De preferencia, la (K2) también es una clave simétrica. En el paso 408, la API 306 codifica la (CK) con la (K2) para dar como resultado (K2(CK)). En el paso 410, la API 306 descarta la (CK), con el resultado de que la (CK) solamente se puede obtener al decodificar (K2(CK). Para asegurar que la (CK(contenido) esté asegurada en un servidor 320 DRM y que todos los "requerimientos de la licencia" para el contenido se lleven a cabo en forma central, de conformidad con los datos de derechos, en el paso 412 la API 306 hace contacto con el servidorQ320 DRM y recupera la clave pública (PU-DRM) desde el mismo. En el paso 414, la API 306 codifica la (K2) con la (PU-DRM) para que resulte en (PU-DRM(K2)). De este modo, la (CK) se puede proteger con (PU-DRM para asegurar que el servidor 320 DRM sea la única entidad que tendrá acceso a la (CK), ya que se requiere decodificar la (CK(contenido)). En el paso 416, la API 306 codifica los datos de derechos (es decir, la lista de entidades autorizadas y los derechos y condiciones respectivos asociados con cada una de las entidades autorizadas en la lista) con (K2) que resulta en (K2(rightsdata) . En una modalidad alternativa, la (CK) se puede utilizar para codificar directamente los datos de derechos para dar como resultado (CK(rightsdata)) y la (PU-DRM)-se puede utilizar para codificar (CK) directamente para resultar en (PU-DRM(CK)), antes del uso de (K2) por completo. Sin embargo, con el uso de (K2) para codificar los datos de derechos y la (CK) permite que (K2) se conforme en cualquier algoritmo en particular que pueda ser factible para el servidor DRM, mientras que (CK) se puede especificar por la entidad independiente del servidor DRM y puede no ser tan factible para el mismo. En el paso 418, la aplicación 302 de protección del contenido presenta la (PU-DRM(K2)) y (K2(rightsdata) al servidor 320 DRM como la etiqueta de derechos para firmar. De manera alternativa, el cliente puede firmar los datos de derechos en la forma antes descrita. Cuando los datos de derechos se presentan al servidor para su firma, entonces en el paso 420, el servidor 320 DRM tiene acceso a los datos de derechos y verifica que pueda aplicar los derechos y las condiciones en la etiqueta de derechos presentada. Para verificar que puede aplicar los datos de derechos, el servidor 320 DRM aplica la clave privada (PR-DRM) correspondiente a (PU-DRM) para (PU-DRM(K2)) para resultar en (K2) y después aplica (K2) para (K2(rightsdata)) para resultar en los datos de derechos. El servidor 320 DRM puede revisar cualquier política para verificar que los usuarios, derechos y condiciones especificadas en los datos de derechos estén dentro de la política en vigor por el servidor 320. El servidor 320 DRM firma la etiqueta de derechos presentada originalmente que incluye (PU-DRM(K2) y (K2(rightsdata)) para resultar en la etiqueta de derechos firmados (SRL) 308, en donde la firma está con base en la clave privada del servidor 320 DRM (PR-DRM), y regresa la SRL 308 a la API 306, la cual presenta la SRL 308 regresada a la aplicación 302 del cliente. La SRL 308 es un documento firmado en forma digital, que es resistente a violaciones. Además, el SRL 308 es independiente de la clave y algoritmos usados para codificar el contenido, pero mantiene una relación 1-1 con el contenido que está protegiendo. Con referencia ahora a la Figura 4A, en una modalidad de la presente invención, e}la SRL 308 puede incluir información en el contenido que está con base en la SRL 308, incluyendo probablemente la ID del contenido, información en el servidor DRN que firma la SRL 308, incluyendo la (PU-DRM(K2)) e información de referencia como la URL para ubicar al servidor DRM en una red e información de regreso cuando el URL falla, información que describe la SRL 308; (K2(rightsdata)); (K2(CK)); y una firma digital (s(PR-DRM)) entre otras cosas. Al asegurar que la entidad de confianza firme los datos de derechos para crear una etiqueta 308 de derechos firmados, el servidor 320 DRM está seguro que emitirá licencias para el contenido de conformidad con los términos establecidos por el publicador, como se describe en los datos de derechos de la etiqueta 308 de derechos. Como se puede apreciar, es necesario que el usuario obtenga una licencia para reproducir el contenido, especialmente ya que la licencia contiene la clave del contenido (CK). Cuando el usuario desea obtener una licencia para el contenido codificado, el usuario puede presentar una solicitud de licencia incluyendo la SRL 308 para el contenido y un certificado que verifica las credenciales del usuario con el 320, u otra entidad emisora de licencias. La entidad emisora de licencia puede entonces decodificar (PU-DRM(K2)) y (K2(rightsdata) para reproducir los datos de derechos, enlistar los derechos otorgados por el autor (si existen) a la entidad solicitante de licencia y construir una licencia solamente con los derechos especificados. Como se mencionó antes, luego de que la aplicación 302 recibe la SRL 308, la aplicación 302 concatena la etiqueta 308 de derechos firmados con la (CK(Contenido)) 304 correspondiente para formar el contenido digital administrado con derechos. De manera alternativa, los datos de derechos se almacenan en una ubicación conocida, con una referencia para la ubicación provista con el contenido digital codificado. De este modo, la aplicación de reproducción que está habilitada por el DRM puede exponer la etiqueta 308 de derechos firmados a través de una porción del contenido que la aplicación de reproducción intenta reproducir. Esta exposición activa la aplicación de reproducción para iniciar la solicitud de licencia contra el servidor 320 de inscripción DRM. La aplicación 302 de publicación puede almacenar una URL con el servidor 320 de inscripción DRM, por ejemplo, en el servidor 320 de inscripción DRM puede incorporar su propia URL como una porción de metadatos dentro de la etiqueta de derechos antes de que se firme en forma digital, para que la API 306 del cliente DRM llamado por la aplicación de reproducción pueda identificar al servidor 320 de inscripción DRM correcto.

Obtención de una licencia para un contenido publicado Con referencia ahora a la Figura 5, se muestra un sistema y un método para autorizar un contenido digital administrado con derechos. "Autorización" como se define dentro de la presente, se refiere a un proceso que sigue una aplicación o servicio para solicitar y recibir una licencia que autorizará a una entidad nombrada en la licencia para consumir el contenido de conformidad con los términos especificados en la licencia. Las entradas en el proceso de autorización pueden incluir la etiqueta 308 de derechos firmados (SRL) asociada con el contenido para el cual se solicita la licencia, y el certificado de clave pública de la entidad para la cual se solicita la licencia Se debe notar que la entidad que solicita la licencia no necesariamente es la entidad para la cual se solicita la licencia. Típicamente, la licencia incluye la descripción de derechos de la SRL 308, una clave codificada que puede decodificar el contenido codificado, y una firma digital sobre la descripción de derechos y la clave codificada para aseverar la legitimidad y evitar violaciones. En forma preliminar, la API 306 del cliente envía la etiqueta 308 de derechos firmada del contenido 310 administrado con derechos al servidor 320 DRM a través de una red 330 de comunicaciones. Como se describe antes, la etiqueta 308 de derechos contiene la clave del contenido (CK) codificada de conformidad con la clave pública del servidor 320 DRM (PU-DRM) (es decir (PU-DRM(CK))). En el proceso de emisión de una licencia, el servidor 320 DRM aplica la (PR-DRM) a (PU-DRM(CK)) para obtener (CK). Entonces utiliza la clave pública (PU-ENTITY) en el certificado de clave pública que pasa en la solicitud de licencia para recodificación (CK) (es decir, PU-ENTITY(CK))) . La (PU-ENTITY(CK))) recién codificada se coloca dentro de la licencia. De este modo, la licencia se puede regresar al solicitante sin el riesgo de exponer la (CK), ya que el único portador de la clave privada (PR-ENTITY) correspondiente a (PU-ENTITY) puede recuperar la (CK) de (PU-ENTITY(CK)). La API 306 del cliente entonces utiliza la (CK) para decodificar el contenido codificado para formar un contenido 312 digital decodificado. La aplicación 302 del cliente puede entonces usar el contenido 312 digital decodificado de conformidad con los derechos provistos en la licencia.

De manera alternativa, como se establece más adelante con detalle, un cliente como un cliente publicador puede emitir una licencia de uso para poder consumir el contenido. Con referencia ahora a las Figuras 6A y 6B, se muestra un método para autorizar contenido digital administrado con derechos. En el paso 602, la entidad emisora de licencias como un servidor 320 DRM recibe una solicitud de licencia que incluye un certificado de clave pública o una identidad para cada una de las licencias solicitadas. Presumiblemente, cuando se especifica una identidad, el servidor 320 DRM puede proporcionar un certificado de clave pública correspondiente desde un directorio, una base de datos o su semejante. Cuando se solicita una licencia para un solo usuario, solamente se nombra un certificado o identidad. Cuando se solicita una licencia para una pluralidad de usuarios, se puede nombrar un certificado o identidad para cada uno de los usuarios potenciales. En el paso 604, la entidad solicitante (es decir, la entidad que hace la solicitud de licencia) se autentica, si se desea. En el paso 606, se determina si la entidad tiene permiso para solicitar una licencia, otra vez si se desea. Cuando es asi, en el paso 608, la entidad solicitante determina que el certificado de clave pública no está incluido en la solicitud de licencia, entonces la entidad solicitante utiliza la identidad especificada para llevar a cabo una consulta en un servicio de directorio o base de datos para el certificado de clave pública adecuado. Cuando es así, en el paso 610, la entidad emisora determina que el certificado está en el directorio, entonces en el paso 612, se recupera el certificado. Cuando no se puede encontrar el certificado para un usuario potencial determinado, ya sea en la solicitud o en el directorio, entonces el servidor de licencias no genera una licencia para este usuario potencial y en el paso 614 se regresa un error a la entidad solicitante. Suponiendo que el servidor 320 DRM tiene un certificado de clave pública para por lo menos un usuario potencial, entonces, en el paso 616 el servidor 320 DRM valida la confianza de cada certificado del usuario. Si no se valida, el servidor 320 DRM determina que el emisor del certificado de licencia no está en la lista de emisores de confianza, entonces la solicitud no es entregada para ese usuario, y se genera un error en el paso 614. De este modo, cualquier usuario potencial, cuyo certificado no sea emitido por un emisor de confianza no recibirá la licencia. Además, el servidor 320 DRM de preferencia, lleva a cabo una validación de firma digital en todas las entidades en la cadena del certificado que va desde los certificados de emisores de confianza hasta los certificados de claves públicas de usuarios individuales. El proceso de validar una firma digital en una cadena es un algoritmo bien conocido. Cuando el certificado de clave pública para cualquier usuario potencial no es válida, o un certificado en la cadena no se valida, el usuario potencial no es de confianza, y por lo tanto no se emitirá la licencia para ese usuario potencial. De otra forma, en el paso 618, se puede emitir la licencia. El proceso se repite en el paso 620 hasta que se han procesado todas las entidades para las cuales se solicitó la licencia. Como se muestra en la Figura 6B, el servidor 320 DRM procede a validar la etiqueta 308 de derechos firmados que es recibida en la solicitud de licencia. En una modalidad, el servidor 320 DRM tiene una copia original de cada etiqueta de derechos firmada. En ese momento de la licencia (paso 622) el servidor 320 DRM puede recuperar una copia de la etiqueta de derechos firmada. La etiqueta de derechos firmada puede estar más al día que la copia de la etiqueta de derechos enviada en la solicitud de licencia, y por lo tanto será la etiqueta de derechos empleada para producir la licencia solicitada. Si no se encuentra la etiqueta de derechos original, el servidor 320 DRM en el paso 624 determina de conformidad con una política predefinida si emitir una licencia con base en la etiqueta de derechos en la solicitud. Si la política no lo permite, la solicitud de licencia falla en el paso 626, y se regresa un error a la API 306 en el paso 628. En el paso 630, el servidor 320 DRM valida la SRL 308 y específicamente la firma digital de la misma. Cuando la SRL 308 no se valida, la solicitud de licencia falla en el paso 626 y se regresa un error a la API 306 en el paso 628. Después de que se han presentado todas las validaciones, el servidor DRM construye una licencia para cada licencia aprobada con base en la SRL 308. En el paso 632, el servidor 320 DRM genera una descripción de derechos respectiva para la licencia a ser emitida para cada usuario. Para cada usuario, el servidor 320 DRM evalúa la identidad nombrada en el certificado de clave pública del usuario contra las identidades nombradas en la descripción de derechos en la etiqueta de derechos. En el paso 636, el servidor 320 DRM obtiene la (PU-DRM(K2)) y la (K2(CK)) de la SRL 308 y aplica la (PR-DRM) para obtener la (CK). La entidad emisora entonces re-codifica la (CK) con el uso de la (PU-ENTITY) desde el certificado de clave pública del usuario para dar como resultado (PU-ENTITY(CK)). En el paso 638, el servidor 320 DRM concatena la descripción de derechos generada con la (PU-ENTITY(CK)) y firma en forma digital la estructura de datos resultante con el uso de la (PR-DRM) (es decir, S(PR-DRM)). La estructura de datos firmada es la licencia para ese usuario en particular. En el paso 640, el servidor 320 DRM determina que no existen más licencias para generar para esa solicitud en particular. Las licencias generadas son regresadas a la entidad solicitante, en el paso 642 junto con la cadena de certificados adecuada que enlaza las licencias de regreso con la autoridad de confianza.

Auto-publicación de una etiqueta 308 de derechos firmados En una modalidad de la presente invención, la SRL 308 puede ser firmada por el usuario solicitante/publicador por sí mismo. De conformidad con esto, el usuario no necesita estar en contacto con el servidor 320 DRM para obtener la SRL 308 para una porción asociada del contenido. Como resultado, la auto-publicación también se puede dar como publicación fuera de línea. En tal modalidad, el usuario publicador también tiene la capacidad de emitir por sí mismo una licencia de publicación, en especial cuando el contenido de auto-publicación esté protegido con DRM y la licencia del publicador sea requerida para permitir al usuario publicador reproducir el contenido ahora protegido. Se debe entender que el usuario publicador puede estar capacitado para emitir licencias para otros usuarios. En particular, y con referencia ahora a la Figura 7, en la modalidad, un usuario publicador fuera de línea es provisto con una publicación fuera de línea al recibir desde el servidor 320 DRM un certificado 810 de publicación fuera de línea (OLP) que incluye una clave pública (PU-OLP) y una clave privada (PR-OLP) correspondiente, codificada de conformidad con una clave pública directa o indirectamente accesible al componente 18 de confianza (Figura 11) de la (PU-ENTITY) para dar como resultado en la (PU-ENTITY(PR-CERT)). Se debe notar que (PU-ENTITY) puede, por ejemplo, ser la clave pública del componente 18 de confianza, o puede ser una clave pública del usuario a la cual se tiene acceso por medio de la clave pública del componente 18 de confianza. El certificado 810 OLP debe ser firmado por la clave privada del servidor 320 DRM (PR-DRM) para que tal servidor 320 DRM pueda verificar el certificado OLP como será descrito más adelante. Además, el certificado OLP 810 debe incluir la cadena de certificado desde (PU-DRM) hasta la autoridad de confianza que tiene el componente 18 de confianza el usuario publicador o de otro usuario para que el componente 18 de confianza pueda verificar el certificado 810 OLP y cualquier otro certificado o licencia asociados con el certificado 810 OLP, como será descrito a continuación. En breve, se debe entender que la cadena de certificados empieza con un certificado raíz firmado por la clave privada de una autoridad de confianza y que tiene la clave pública del siguiente certificado en la cadena. Cada certificado intermedio en la cadena, entonces, se firma con la clave privada correspondiente a la clave pública del certificado previo en la cadena, y tiene la clave pública del siguiente certificado en la cadena. Por último, el certificado o licencia al cual se acopla la cadena se firma con la clave privada correspondiente a la clave pública del último certificado en la cadena. De este modo, para verificar el certificado o la licencia al cual se acopla la cadena, se obtiene el reconocimiento de la clave pública correspondiente a la clave privada de la autoridad de confianza, y tal clave pública de la autoridad de confianza se emplea para verificar la firma del certificado raíz en la cadena. Suponiendo que la firma del certificado raíz se verifica, entonces se obtiene la clave pública del certificado raíz y se emplea para verificar la firma del primer certificado intermedio en la cadena. Este proceso se repite en forma seriada a través de la cadena hasta que cada firma se verifica y después se obtiene la clave pública del último certificado intermedio en la cadena y se emplea para verificar la firma del certificado o licencia al cual se acopla la cadena. Como se podrá apreciar, el certificado 810 OLP crea un enlace en la cadena de confianza entre el contenido 304 que va a ser publicado fuera de línea y el servidor 320 DRM que emitirá la licencia para el contenido 304. El certificado 810 OLP se puede crear con base en un lenguaje XML/XrML o cualquier otro lenguaje adecuado. También, se debe apreciar que el certificado 810 OLP y la cadena de certificados acoplada autoriza al usuario publicador a auto-publicar. Como también se podrá apreciar, el par de claves (PU-OLP, PR-OLP) están separadas de (PU-ENTITY, PR-ENTITY) y se emplean específicamente para la auto-publicación. Se debe notar que el par de claves (PU-OLP, PU-OLP) se pueden suministrar, en cuyo caso el certificado 810 DRM incluye solamente la clave pública del usuario (PU-ENTITY) y es firmada por la clave privada del servidor 320 DRM (PR-DRM) para que el servidor 320 DRM pueda verificar el mismo. La auto-publicación difiere de la publicación como se muestra en la Figura 4, ya que el usuario toma el lugar del servidor 320 DRM con respecto a los pasos llevados a cabo por el mismo. En forma importante, el usuario firma la etiqueta de derechos presentada, la cual incluye (PU-DRM(K2)) y (K2(rightsdata) o incluye (PU-DRM(CK)) y (C (rightsdata)) (esta última mostrada en las Figuras 7 y 8) con (PR-OLP) como se obtiene del certificado 810 DRM (es decir, S(PR-OLP)) para dar como resultado en la etiqueta de derechos firmada (SRL) 308. El cliente del componente 18 de confianza que utiliza el certificado 810 OLP típicamente verifica lo mismo con base en la cadena de certificados acoplada. Como se puede apreciar, el componente 18 de confianza del usuario obtiene la (PR-OLP) del certificado 810 OLP al obtener la (PU-ENTITY(PR-OLP) de tal certificado 810 OLP y aplica la (PR-ENTITY) al mismo. Se debe observar que el usuario publicador no puede verificar que el servidor 320 DRM ponga en vigor los derechos en una SRL 308 auto-publicada. De conformidad con esto, el servidor 320 DRM puede llevar a cabo la verificación al momento en que se solicita una licencia con base en la SRL 308 auto-publicada. Una vez que el usuario publicador auto-publica la SRL 308, el usuario concatena la SRL 308 auto-publicada y el certificado 810 OLP empleado para producir la misma en el contenido 304, y el contenido 304 con la SRL 308 y el certificado 810 OLP se distribuyen como el contenido 310 de administración de derechos a otro usuario. Después, el otro usuario solicita y obtiene una licencia para el contenido 304/310 desde el servidor 320 DRM en esencialmente la misma forma que la mostrada en las Figuras 6A y 6B. Aquí, el usuario solicitante de licencia presenta al servidor 320 DRM tanto la SRL 308 auto-publicada como el certificado 810 OLP concatenados en el contenido 304. El servidor 320 DRM entonces verifica S PR-DRM) en el certificado 810 OLP con base en la (PU-DRM) correspondiente y obtiene la (PU-OLP) del certificado 810. El servidor 320 DRM entonces verifica S (PR-OLP) en la SRL 308 con base en la (PU-CERT) obtenida y continúa como antes. Se debe notar que ya que el usuario publicador no verificó que el servidor 320 DRM puso en vigor los derechos en la SRL 308, como se estableció antes, el servidor 320 DRM por sí mismo debe llevar a cabo la verificación en ese momento. También, se debe tomar en cuenta que el servidor 320 DRM solamente necesita verificar la S(PR-DRM) en el certificado 810 OLP, ya que presumiblemente confía en sí mismo. De conformidad con ello, la cadena de certificado asociada desde el certificado 810 OLP no necesariamente se tiene que enviar al servidor 320 DRM junto con el certificado 810 OLP, a menos por supuesto, que la cadena se necesite de otra forma, como por ejemplo cuando la cadena está por lo menos con base para S(PR-DRM). Es importante que el usuario publicador debe tener la capacidad de reproducir el contenido 304/310 ahora protegido sin tener que ir al servidor 320 DRM por una licencia. Dicho de otra forma, el usuario publicador que publica el contenido 304/310 fuera de línea sin tener que ir al servidor 320 DRM con base en un certificado 810 OLP debe contar con la capacidad para emitir por sí mismo una licencia en una manera fuera de línea sin tener que ir al servidor 320 DRM, de modo que el usuario puede producir un contenido 304/310 publicado fuera de línea. De conformidad con esto, el usuario publicador puede continuar trabajando con el contenido 310 auto-publicado sin ninguna conectividad con el servidor 320 DRM. En una modalidad de la presente invención, y con referencia a la Figura 8, el usuario publicador emite por sí mismo una licencia 820 fuera de línea firmada por la (PR-OLP) y con base en la SRL 308 auto-publicada e incluye el certificado 810 OLP y la cadena de certificados del mismo. Presumiblemente, la licencia 820 del publicador otorga al usuario publicador el acceso total al contenido 310 auto-publicado, aunque también se otorgará una menor proporción de acceso. La licencia 820 del publicador puede estar escrita en un lenguaje XML/XrML u otro lenguaje, como es el caso con otras licencias DR . Como se puede apreciar, la licencia 820 del publicador incluye la clave del contenido (CK) codificada de conformidad con la (PU-ENTITY), que se puede obtener mediante el componente 18 de confianza del dispositivo 14 de computación del usuario, para formar la (PU-ENTITY(CK)). La cadena para la licencia 820 del publicador va desde la licencia 820 al certificado 810 OLP y de regreso al certificado raíz de una autoridad de confianza, probablemente mediante uno o más certificados intermedios. Debido a que el componente 18 de confianza del usuario presumiblemente puede obtener la clave pública correspondiente a la clave privada de la autoridad de confianza que se empleó para firmar el certificado raíz, el componente 18 de confianza puede por sí mismo, verificar la licencia 820 del publicador mediante la cadena de certificados de la misma y después de la verificación, puede obtener la (PU-ENTITY(CK)) de la misma, aplicar la (PR-ENTITY) a la misma para obtener la (CK) y aplicar la (CK) a la (CK(contenido) para dar como resultado el contenido 304 para propósitos de reproducción del mismo. Como resultado, el usuario publicador puede continuar trabajando con el contenido 310 fuera de línea, publicado, mientras está fuera de línea. De conformidad con lo anterior, y con referencia ahora a la Figura 9, un usuario publicador fuera de línea publica el contenido 304/310 y emite por sí mismo una licencia 820 de publicación fuera de línea para el contenido 304/310 de la siguiente forma. Primero, y como se debe apreciar, el contenido 304 se desarrolla en una forma adecuada y se codifica de conformidad con la clave del contenido (CK) (paso 901), el usuario publicador crea una etiqueta de derechos para el contenido 304 con la información adecuada [(PU-DRM(CK)) y (CK(rightsdata)) (paso 903). Después, el usuario publicador que presumiblemente, se encuentra en posesión de un certificado 810 OLP del servidor 320 DRM, obtiene tal certificado 810 OLP (paso 905) y verifica el mismo con base en la firma del mismo y la cadena de certificados que lo conducen de regreso hasta la autoridad raíz (paso 907). Se debe apreciar que la verificación se lleva a cabo en forma precisa por el componente 18 de confianza en el dispositivo 14 de computación del usuario publicador. Suponiendo que la verificación tiene éxito, entonces el usuario publicador/componente 18 de confianza (de aquí en adelante "el usuario publicador") recupera la (PU-ENTITY(PR-OLP) del certificado 810 OLP (paso 909), aplica la (PR-ENTITY) a la (PU-ENTITY(PR-OLP)) para obtener la (PR-OLP) (paso 911) y después firma la etiqueta de derechos creada con tal (PR-OLP) para crear una SRL 308 (paso 913). Después, el usuario publicador concatena la SRL 803 y el certificado 810 OLP empleados para producir la misma en el contenido 304 para formar el contenido 310 de auto-publicación (paso 915) y el contenido 310 administrado con derechos para que se pueda distribuir a otro usuario. Para que el usuario publicador continúe usando o produciendo el contenido 310, sin embargo, el usuario publicador debe emitir por sí mismo una licencia 820 de publicación fuera de línea. De este modo, el usuario publicador crea una licencia 820 de publicación al definir los datos de derechos apropiados por sí mismo y codificar los mismos de conformidad con la clave del contenido (CK) para dar como resultado en (CK(rightsdata) (paso 917). Se debe notar que los datos de derechos pueden obtenerse de la SRL 308 del contenido 310, y pueden ser un grupo por omisión de datos de derechos que otorgan al usuario publicador un acceso total o parcial al contenido 310 auto-publicado o se puede derivar de otra fuente. Además, el usuario publicador codifica la clave del contenido (CK) de conformidad con la (PU-ENTITY) para formar la (PU-ENTITY(CK)) (paso 919). Tal (CK(rightsdata)) y (PU-ENTITY(CK)) se formatean en la licencia 820 del publicador (paso 921), el certificado 810 OLP y la cadena de certificados del mismo se anexa (paso 923) y la licencia 820 del publicador se firma con base en la (PR-OLP) como se obtuvo en el paso 911 (paso 925). Se debe notar que el contenido 304 ( es decir, (CK(Contenido))), la licencia 820 de publicación y el certificado OLP en combinación, forman una cadena 830 de artículos digitales de regreso a la autoridad de confianza. Para que el usuario publicador produzca el contenido 310 publicado y con referencia ahora a la Figura 10, el usuario publicador no necesita estar en contacto con el 320, sino que obtiene la clave pública correspondiente a la clave privada de la autoridad de confianza que se empleó para firmar el certificado raíz (paso 1001), verifica el certificado raíz (paso 1003) y después verifica cada certificado intermedio en la cadena (paso 1005), por cada certificado intermedio, obtiene la clave pública del certificado anterior y emplea el mismo para verificar la firma de tal certificado. Después, la (PU-DRM) del último certificado en la cadena se emplea para verificar la firma del certificado 810 OLP (es decir, S(PR-DRM)) (paso 1007), se obtiene la (PU-OLP) del certificado 810 OLP ) (paso 1009) y la (PU-OLP) se emplea para verificar la firma de la licencia 820 del publicador (es decir, S(PR-OLP)) (paso 1010). Una vez que se verifica la licencia 820 del publicador, entonces la (CK(rightsdata) y la (PU-ENTITY(CK)) se recuperan de la misma (paso 1011), la (PR-ENTITY) se aplica a la (PR-ENTITY(CK)) para dar como resultado la (CK) (paso 1013), y se aplica (CK) a la (C (rig htsdata)) para dar como resultado en los datos de derechos (paso 1015). Ahora, se debe apreciar que los datos de derechos se revisan por el componente 18 de confianza del dispositivo 14 de computación del usuario publicador para determinar que tales datos de derechos permiten la reproducción en la manera pensada (paso 1017), el componente 18 de confianza aplica la (CK) a la (CK(contenido) del contenido 310 para dar como resultado en el contenido (1019), y tal contenido después se envía a una aplicación de reproducción apropiada para una reproducción real (paso 1021). De este modo, los pasos de la Figura 10 en efecto atraviesan la cadena 830 de artículos digitales desde la autoridad de confianza al contenido 304. Se debe notar que el componente 18 de confianza puede aplicar en forma oculta la (CK(contenido)) para dar como resultado el contenido sin primero revisar los datos de derechos y a pesar de que los datos de derechos lo permitan o no, pero se tiene confianza y se ha construido por el hecho de que se producirá el contenido solamente después de revisar los datos de derechos y de satisfacer los datos de derechos que permiten la reproducción del contenido. Otra vez, como resultado de obtener la licencia 820 del publicador, el usuario publicador puede continuar trabajando con el contenido 310 publicado, fuera de línea mientras permanece ya que el servidor 320 DRM no necesita estar en contacto.

Inscripción y sub-inscripción de servidores DRM En la arquitectura que se muestra en la Figura 3, solamente se muestra un servidor 320 DRM único. Sin embargo, y como se puede apreciar, tal arquitectura puede y probablemente incluya servidores 320 DRM. En particular y en una modalidad de la presente invención, tal arquitectura incluye una red distribuida de servidores 320 DRM. Cada uno de los servidores 320 DRM puede tener una función en particular y todos los servidores 320 DRM pueden estar organizados en cualquier forma adecuada sin apartarse del espíritu y alcance de la presente invención. Por ejemplo y con referencia ahora a la Figura 12, una organización en particular puede tener uno o más servidores 320 DRM a nivel del usuario para el propósito de firmar etiquetas de derechos para reproducir las SRL 308, emitir licencias 16, otorgar licencias del servidor 320 DRM de publicación, emitir certificados a los usuarios, emitir certificados para los dispositivos 14 de computación y sus semejantes. Cada servidor 320 DRM a nivel del usuario puede ser asignado geográficamente o puede ser asignado con base en su función o carga. De la misma forma, para contemplar varios servidores 320 DRM a nivel de usuario, una organización puede tener uno o más servidores 320 DRM de administración. Tales servidores 320 DRM con base en la organización pueden estar ubicados detrás de la red de la organización si así se desea. Además de los servidores 320 DRM con base en la organización, puede haber servidores 320 DRM de trans-organización que facilitan la organización interna de la funcionalidad del DRM. Por ejemplo, los servidores 320 DRM trans-organización pueden permitir a un par de organizaciones compartir cierto contenido 12 DRM. También, puede haber una red de servidores 320 DRM vigilantes que activan a otros servidores 320 DRM. Por ejemplo, los servidores 320 DRM vigilantes pueden vigilar y mantener a todos los otros servidores 320 DRM y proporcionar un enlace apropiado para los otros servidores 320 DRM de regreso a la raíz o autoridad de confianza que es la base para la cadena de certificados establecidos anteriormente. Tales servidores 320 DRM sin una base de organización no es posible que estén ubicados detrás de una red de la organización. En forma crítica, cada servidor 320 DRM en la arquitectura de la Figura 12 debe tener la capacidad de demostrar que es confiable. De esta manera, y como se podrá apreciar a partir de la descripción de la cadena de certificados anterior, cada servidor 320 DRM luego de entrar en la arquitectura es provisto con un certificado 1310 de inscripción, como se puede observar en la Figura 13. En forma importante y en una modalidad de la presente invención, el certificado 1310 de inscripción es proporcionado al servidor 320 DRM (de aquí en adelante servidor 320 DRM-E) por otro servidor 320 DRM de "inscripción" ya dentro de la arquitectura (de aquí en adelante llamado servidor 320 DRM-R). También, es importante mencionar que una cadena de certificados 1320 se encuentra unida al certificado 1310 de inscripción desde el servidor 320 DRM-R, la cual incluye el certificado 1310 de inscripción del 320, el certificado 1310 del servidor 320 DRM que inscribió al servidor 320 DRM-R, y así hasta el servidor 320 DRM raíz. El servidor 320 DRM raíz puede representar la raíz o la autoridad de confianza, o la cadena de certificados 1320 se puede extender más para llegar a la raíz o a la autoridad de confianza. Como se podrá apreciar, el certificado 1310 de inscripción y la cadena de certificados 1320 en combinación, forman la cadena de certificados que se unen a un certificado 810 OLP provisto por el servidor 320 DRM inscrito para un usuario publicador, como el mostrado en la Figura 8. En una modalidad de la presente invención, el certificado 1310 de inscripción provisto al servidor 320 DRM por un servidor 320 DRM-R está en una forma como un certificado con base en XrML 1.2. Como se puede apreciar, este tipo de certificado 1310 no se ofrece por ninguna tercera parte y de este modo, este tipo de certificado 1310 no representa ninguna clase de comprobación independiente por la tercera parte para el propietario del certificado 1310. En una modalidad de la presente invención, el método con el cual se inscribe un servidor 320 DRM en particular dentro de una arquitectura depende de que el servidor 320 DRM-E conozca o tenga razones para confiar en el servidor 320 DRM-E entrante. Cuando no es así, el servidor 320 DRM-E debe demostrar que el servidor 320 DRM-R es de confianza y pondrá en vigor la arquitectura DRM. Cuando es así, el servidor 320 DRM no debe demostrar que el servidor 320 DRM es de confianza, por lo menos no al mismo grado. De este modo un servidor 320 DRM no confiable/no conocido "inscribe" al servidor 320 DRM-E, mientras que el servidor 320 DRM conocido/confiable "sub-inscribe" al servidor 320 DRM-E. Típicamente, el servidor 320 DRM conoce/confía en el 3203 cuando ambos son operados para el beneficio de la misma organización, aunque el conocimiento/confianza también puede surgir de otras situaciones sin apartarse del espíritu y alcance de la presente invención. De este modo, el método con el cual se inscribe el servidor 320 DRM-E particular dentro de la arquitectura depende de si el servidor 320 DRM-R tiene su base en la organización o no tiene su base en la organización. Como resultado, un servidor 320 DRM-R sin base en la organización "inscribe" al servidor 320 DRM, mientras un servidor 320 DRM-R con base en la organización "sub-inscribe" al servidor 320 DRM-E.

Inscripción En una modalidad de la presente invención, y con referencia ahora a la Figura 14, un servidor 320 DRM no conocido/no confiable inscribe al servidor 320 DRM-E de la siguiente forma. Primero, se debe apreciar que el servidor 320 DRM-E que desea ser inscrito en el servidor 320 DRM-R no conocido/no confiable es muy probable que no sea conocido para el servidor 320 DRM-R. De conformidad con ello, en una modalidad de la presente invención, el servidor 320 DRM-E debe procurar un certificado 1330 de comprobación desde una tercera parte que desea comprobar al servidor 320 DRM-E (paso 1401). Típicamente, la tercera parte es un agente emisor de certificado independiente que es de confianza para el 320, para llevar a cabo tal comprobación, tal como por ejemplo VERISIGN Corporation de Mountain View, California. El certificado 1330 de comprobación puede estar por ejemplo, en forma de un certificado X.509. Se debe notar que el servidor 320 DRM-R que confía en la tercera parte para comprobar al servidor 320 DRM-E, puede perder la confianza del servidor 320 DRM-R con cualquier acto perjudicial para el servidor 320 DRM-E. Como se puede apreciar, es común y se puede observar en la Figura 13, el certificado 1330 de comprobación incorpora en el mismo una clave pública (PU-V) y una clave privada (PR-V) correspondiente, es firmada por la tercera parte de confianza y puede estar acompañada por la cadena de certificados que llevan a la raíz conocida para propósitos de validación. También es común, la (PR-V) dentro del certificado 1330 de comprobación está protegida en una forma accesible para el servidor 320 DRM-E comprobado que está con base en el certificado 1330 de comprobación. Por ejemplo, y como se puede observar en la Figura 13, la (PV-R) puede estar codificada de conformidad con una clave pública adecuada. Dentro de la arquitectura DRM, el servidor 320 DRM-E entrante debe contar con una identidad única. Se debe entender que la identidad DRM es separada de (PU-V, PR-V), aunque la identidad DRM también puede coincidir con tal (PU-V, PR-V) sin apartarse del espíritu y alcance de la presente invención. De conformidad con ello, para establecer tal identidad, el servidor 320 DRM-E genera u obtiene un nuevo par de clave pública/privada (PU-E, PR-E) (paso 1403). También, dentro de la arquitectura DRM, el servidor 320 DRM de inscripción debe decidir las entidades que pueden revocar la participación de la autoridad. De conformidad con ello el servidor 320 DRM-E identifica cada entidad de revocación en una lista, probablemente mediante la clave pública de la mismas (paso 1405).

El servidor 320 DRM-E debe tener la capacidad de establecer al servidor 320 DR -R de inscripción de tal forma que el servidor DRM-E sea propietario del certificado de comprobación 1330 que se obtuvo en el paso 1401. De conformidad con esto, el servidor 320 DRM-E emplea la (PR-V) del certificado 1330 de comprobación para codificar la (PU-E) para resultar en (PR-V(PU-E)) como el indicativo de propiedad, o fir5ma la (PU-E) con la (PR-V) para resultar en (PU-E) S (PR-V) como el indicativo de propiedad (paso 1407). En cualquier caso, la aplicación de (PU-V) para decodificar (PU-E) o verificar la firma establece la posesión de (PR-V) y por lo tanto el certificado 1330 de comprobación. Hasta ahora, el servidor 320 DRM-E tiene el certificado 1330 de comprobación, la (PU-E) y la (PR-E), la lista de autoridad de revocación, y la (PR-V(PU-E)) o (PU-E) S (PR-V) como el indicativo de propiedad. Para solicitar la inscripción, el servidor 320 DRM-E envía el certificado 1330 de comprobación, la (PU-E), la lista de autoridad de revocación, y la (PR-V(PU-E)) o (PU-E) S (PR-V) como el indicativo de propiedad al servidor 320 DRM-R (paso (1409), y el servidor 320 DRM-R procede a inscribir a tal servidor 320 DRM-E solicitante. Se debe notar que la solicitud o parte de la misma puede estar en forma de un certificado firmado por (PR-E). En particular, el servidor 320 DRM-R valida el certificado 1330 de comprobación con base en la firma del mismo por la tercera parte y la cadena de certificados que conducen a la raíz conocida (paso 1411). De este modo, el servidor 320 DRM-R establece que el servidor 320 DRM-E ha sido comprobado. También, el servidor 320 DRM-R verifica el indicativo de propiedad al aplicar la (PU-V) de la solicitud para decodificar (PU-E) o verificar la firma y así establecer la posesión de (PR-V) y por lo tanto el certificado 1330 de comprobación en la solicitud (paso 1410). Además y de manera importante, el servidor 320 DRM-R lleva a cabo cualquier lógica acostumbrada necesaria para decidir si aprobar la solicitud (paso 1413). Tal lógica acostumbrada puede ser una lógica adecuada sin apartarse del espíritu y alcance de la presente invención y por ejemplo, puede incluir una revisión de antecedentes del servidor 320 DRM-E y/o su operador, una determinación de si el servidor 320 DRM-E tiene un componente 18 de confianza actual y/o el sistema operativo y/o sus semejantes, una determinación de si el servidor 320 DRM-E está en una lista de revocación o lista de vigilancia y sus semejantes. Suponiendo que la lógica acostumbrada permita autoriza la solicitud, entonces en una modalidad de la presente invención, el servidor 320 DRM-R genera el certificado 1310 de inscripción para el servidor 320 DRM-E (paso 1415). En particular y como se puede observar en la Figura 13, el servidor 320 DRM-R incorpora dentro del certificado 1310 de inscripción lo siguiente: un identificador para el servidor 320 DRM-R, como una clave pública del mismo (PU-R); un identificador del servidor 320 DRM-E, como la (PU-E); indicativos identificadores del certificado 1330 de comprobación que incluyen a la tercera parte que emitió el mismo, un número de serie del certificado 1330 de comprobación y la emisión identificada dentro del certificado 1330 de comprobación; cualquier información de validez que especifique el intervalo durante el cual el certificado 1330 de comprobación es válido, como por ejemplo, el intervalo de fechas; la lista de autoridad de revocación; una firma con base en la clave privada del servidor 320 DRM-R (PR-R) correspondiente a la (PU-R); y cualquier otra información apropiada. Tal información apropiada puede incluir, pero no se limita a la fecha en que se emitió el certificado, una indicación del tipo de actividades DRM que un servidor inscrito puede llevar a cabo, por ejemplo, todas las actividades, actividades de contabilidad, firmar etiquetas de derechos, emitir licencias de contenido, y combinaciones de los mismos; y un intervalo de tiempo permitido para llevar a cabo las actividades DRM. Se debe observar que el intervalo de tiempo es diferente del intervalo de validez, ya que el tiempo actual puede estar dentro del intervalo de validez para autorizar un certificado que incluya el certificado 1310 de inscripción en la cadena de certificados. Por el contrario, el tiempo emitido para certificados para infantes debe estar dentro del intervalo de tiempo permitido por el certificado del padre para llevar a cabo actividades DRM.

Como se puede apreciar, al generar el certificado 1310 de inscripción, el servidor 320 DRM-R puede empezar generando información del certificado y después permitir que la lógica acostumbrada genere información adicional o modifique la información existente. La lógica acostumbrada puede asegurar, por ejemplo, que el servidor 320 DRM-R incluye la información adecuada o puede poner en vigor la política de inscripción de la arquitectura DRM, ya definidas. Por supuesto, la firma del certificado 1310 de inscripción se crea después de que se lleva a cabo la lógica acostumbrada. Como se podrá apreciar, el servidor 320 DRM-R une la cadena de certificados 1320 que conduce de regreso hasta la autoridad de raíz de confianza al certificado 1310 de inscripción generado, para que el certificado 1310 de inscripción generado pueda ser validado con base en tal cadena de certificados 1320. En particular, se debe notar que el indicativo de identificación del certificado 1330 de comprobación se coloca dentro del certificado 1310 de inscripción, y siempre acompañará al certificado 1310 de inscripción y actúa como un puente para el certificado 1330 de comprobación. Otra vez, de este modo el indicativo de identificación muestra que el servidor 320 DRM-R confía en la tercera parte emisora del certificado 1330 de comprobación para comprobar al servidor 320 DRM-E, el servidor 320 DRM-R puede perder la confianza en el servidor 320 DRM-E por cualquier acto en detrimento. Una vez que el servidor 320 DRM-R ha generado con éxito el certificado 1310 de inscripción con la cadena de certificados 1320 unida, el servidor 320 DRM-R regresa el mismo al servidor 320 DRM-E solicitante (paso 1417), y el ahora servidor 320 DRM-E inscrito almacena el mismo en una ubicación adecuada para un uso futuro (paso 1419). Como se mencionó antes, la (PU-E) en el certificado 1310 de inscripción y la correspondiente (PR-E) son el par de claves pública/privada que el servidor 320 DRM-E utilizará como la (PU-DRM) y (PR-DRM) cuando firme una etiqueta de derechos para reproducir una SRL 308, emita un certificado 810 OLP, o participe de otra forma dentro de la arquitectura DRM. De conformidad con esto, el d}certif icado 1310 de inscripción y la cadena de certificados 1320 en combinación forman la cadena de certificados que se unen a tal certificado 810 OLP y sus semejantes.

Sub-inscripción En una modalidad de la presente invención, y con referencia ahora a la Figura 15, un servidor 320 DRM-R conocido/confiable sub-inscribe a un servidor 320 DRM-E en la siguiente forma. Primero, se debe apreciar que el servidor 320 DRM-E desea ser sub-inscrito por el servidor 320 DRM-R conocido/confiable y aún así se le requerirá identificarse ante el servidor 320 DRM-R, siempre que el conocimiento o la confianza no sean totales. Sin embargo, tal requerimiento de identificación no surge a un nivel de ofrecimiento por una tercera parte de confianza, ya que el servidor 320 DRM-R no tiene el conocimiento/confianza del servidor 320 DRM-E. De conformidad con esto y en una modalidad de la presente invención, el servidor 320 DRM-E obtiene o es provisto con algunas credenciales 1340 (Figura 13) que se pueden reconocer y se espera sean autorizadas por el servidor 320 DRM-R, y que la identificación del servidor 320 DRM-E sea de la satisfacción del servidor 320 DRM-R (paso 1501). Ambos, servidores 320 DRM-E y DRM-R están dentro de la misma organización, las credenciales 1340 pueden ser credenciales con base en la organización, como por ejemplo, una ID de red cuando ambos servidores se encuentran en una red común, un ID de dominio cuando ambos servidores 320 DRM comparten un dominio común, o sus semejantes. Cuando ambos servidores 320 DRM-R y DRM-E no están dentro de la misma organización, las credenciales 1340 pueden ser una ID de red cuando ambos servidores 320 DRM se encuentren en una red común, una ID de dominio cuando ambos servidores 320 DRM compartan un dominio común, o sus semejantes, o pueden ser otras credenciales, como credenciales emitidas por una tercera parte y reconocidas por el servidor 320 DRM-R. Se debe notar que en esta situación, el servidor 320 DRM-R no confía en una tercera parte de confianza para comprobar al servidor 320 DRM-E, y por lo tanto, el servidor 320 DRM-R puede perder la confianza en el servidor 320 DRM-E por cualquier acto en perjuicio. Sin embargo, el servidor 320 DRM-R decide tomar el riesgo con base en el conocimiento de la confianza en el servidor 320 DRM-E de que no realizará actos perjudiciales.

Al igual que antes, dentro de la arquitectura DRM, el servidor 320 DR -E entrante debe contar con una identidad única. Se debe entender que la identidad DRM es aparte de las credenciales 1340, aunque la identidad DRM también puede coincidir con las credenciales 1340 sin apartarse del espíritu y alcance de la presente invención. De conformidad con esto, para establecer la identidad, el servidor 320 DRM-E genera u obtiene un nuevo par de claves pública/privada (PU-e, PR-E) (paso 1503). Como antes, dentro de la arquitectura DRM, el servidor 320 DRM-E sub-inscrito deberá decidir las entidades que pueden revocar participación de la autoridad en la misma. De acuerdo con esto, el servidor 320 DRM-E identifica a cada entidad de revocación en una lista, probablemente en forma de una clave pública de la misma (paso 1505). Hasta ahora, el servidor 320 DRM-E tiene las credenciales 1340 (PU-E) y la (PR-E) y la lista de autoridad de revocación. Para solicitar la sub-inscripción el servidor 320 DRM-E envía las credenciales 1340, la (PU-E), y la lista de autoridad de revocación al servidor 320 DRM-R )paso 1507) y el servidor 320 DRM-R procede a sub-inscribir a tal servidor 320 DRM-E solicitante. Como antes, se debe notar que la solicitud o parte de la misma puede estar en forma de un certificado firmado por (PR-E). En particular, el servidor 320 DRM-R valida las credenciales 13450 con base en la lógica o los recursos necesarios y disponibles para su validación (paso 1509). De este modo el servidor 320 DRM-R establece con base en las credenciales 1340 validadas que el servidor 320 DRM-E es ahora de confianza para ser autorizado y obedece a la arquitectura DRM. Además y como antes, el servidor 320 DRM-R lleva a cabo la lógica acostumbrada para decidir si autorizar o no la solicitud (paso (1511). Suponiendo que la lógica acostumbrada permita autoriza la solicitud, entonces en una modalidad de la presente invención, el servidor 320 DRM-R genera el certificado 1310 de inscripción para el servidor 320 DRM-E (paso 1513). En particular y como se puede observar en la Figura 13, el servidor 320 DRM-R incorpora dentro del certificado 1310 de inscripción lo siguiente: un identif icador para el servidor 320 DRM-R, como una clave pública del mismo (PU-R); un identif icador del servidor 320 DRM-E, como la (PU-E); las credenciales 1340 o una referencia de las mismas; cualquier información de validez que especifique el intervalo durante el cual el certificado 1330 de sub-inscripción es válido, como por ejemplo, el intervalo de fechas; la lista de autoridad de revocación; una firma con base en la clave privada del servidor 320 DRM-R (PR-R) correspondiente a la (PU-R); y cualquier otra información apropiada. Al generar el certificado 1310 de sub-inscripción, el servidor 320 DRM-R puede empezar generando información del certificado y después permitir que la lógica acostumbrada genere información adicional o modifique la información existente. Otra vez, la firma del certificado 1310 de inscripción se crea después de que se lleva a cabo la lógica acostumbrada. Como antes, el servidor 320 DRM-R une la cadena de certificados 1320 que conduce de regreso hasta la autoridad de raíz de confianza al certificado 1310 de sub-inscripción generado, para que el certificado 1310 de sub-inscripción generado pueda ser validado con base en tal cadena de certificados 1320. Se debe notar que las credenciales 1340 o las referencias de las mismas no se creen especialmente necesarias, pero pueden estar incluidas. También se debe observar que el certificado 1310 de subinscripción no contiene indicativos de identificación del certificado 1330 de comprobación, ya que el certificado de comprobación no se requiere en el escenario presente de sub-inscripción. Una vez que el servidor 320 DRM-R ha generado con éxito el certificado 1310 de sub-inscripción con la cadena de certificados 1320 unida, el servidor 320 DRM-R regresa el mismo al servidor 320 DRM-E solicitante (paso 1515), y el ahora servidor 320 DRM-E sub-inscrito almacena el mismo en una ubicación adecuada para un uso futuro (paso 1517). Como se mencionó antes, la (PU-E) en el certificado 1310 de sub-inscripción y la correspondiente (PR-E) son el par de claves pública/privada que el servidor 320 DRM-E utilizará como la (PU-DRM) y (PR-DRM) cuando firme una etiqueta de derechos para reproducir una SRL 308, emita un certificado 810 OLP, o participe de otra forma dentro de la arquitectura DRM. De conformidad con esto, el certificado 1310 de sub-inscripción y la cadena de certificados 1320 en combinación forman la cadena de certificados que se unen a tal certificado 810 OLP y sus semejantes.

Conclusión La programación necesaria para efectuar los procesos llevados a cabo en conexión con la presente invención es relativamente directa y debe ser evidente para el público de programación relevante. De conformidad con esto, la programación no se describe en la presente. Por lo tanto, se puede emplear cualquier programación adecuada para llevar a la práctica la presente invención sin apartarse del espíritu y alcance de la misma. En la presente invención, la administración de derechos digitales (DRM) y la arquitectura en vigor y el método permiten una reproducción controlada de formas arbitrarias de contenido digital, en donde el control es flexible y se puede definir por el propietario/desarrollador del contenido de tal contenido digital. La arquitectura permite y facilita una reproducción controlada, especialmente dentro de una oficina y organización o en donde los documentos serán compartidos entre varias personas. La arquitectura incluye un mecanismo para ínscribir/sub-inscribir y otorgar aprobaciones para los servidores 320 DRM dentro de la arquitectura. Se debe apreciar que se pueden llevar a cabo cambios y modificaciones en la presente invención sin apartarse de los conceptos inventivos de la misma. Por ejemplo, una licencia o etiqueta de derechos es firmada con base en los datos de derechos en la misma, los datos de derechos no necesariamente están codificados. De la misma forma, al solicitar y construir un certificado 1310 de inscripción o sub-inscripción, la lista de autoridad de revocación y otra información similar no necesariamente se emplea. Por lo tanto, se debe entender que esta invención no está limitada a las modalidades particulares descritas, más bien tiene la intención de abarcar las modificaciones que estén dentro del espíritu y alcance de la presente invención como se define por las reivindicaciones anexas.

Claims

REIVINDICACIONES

1. Un método en combinación con un sistema de administración de derechos digitales (DRM) que tiene una pluralidad de servidores DRM que llevan a cabo funciones de DRM, el método para un servidor DRM-E entrante para ser inscrito dentro del sistema por un servidor DRM-R, de tal manera que el servidor DRM-E debe tener confianza dentro del sistema y caracterizado porque comprende: un servidor DRM-E que procura un par de claves pública/privada (PU-E, PR-E) para identificar al servidor DRM-E dentro del sistema DRM; el servidor DRM-E procura un ofrecimiento de identificación del mismo; el servidor DRM-E envía una solicitud de inscripción al servidor

DRM-R, la solicitud incluye la identificación ofrecida y la (PU-E); el servidor DRM-R valida la identificación ofrecida; el servidor DRM-R, cuando la solicitud será autorizada, genera un certificado de inscripción digital para el servidor DRM-E para inscribir al servidor DRM-E dentro del sistema DRM, el certificado de inscripción generado está con base por lo menos en parte en la (PU-E); el servidor DRM-R regresa el certificado de inscripción generado al servidor DRM-E solicitante; y el ahora servidor DRM-E inscrito almacena el certificado de inscripción regresado en una ubicación adecuada para su uso futuro, el servidor DRM-E con el certificado de inscripción tiene la capacidad de emplear el mismo para emitir documentos DRM dentro del sistema DRM. 2. El método de conformidad con la reivindicación 1, caracterizado porque el servidor DRM-R no tiene bases existentes para confiar en el servidor DRM-E, el método comprende: el servidor DRM-E procura una identificación del mismo que comprende un certificado de comprobación de una parte que desea comprobar al servidor DRM-E, el certificado de comprobación incorpora en el mismo una clave pública (PU-V) y una correspondiente clave privada (PR-V); el servidor DRM-E emplea la (PU-E) y la (PR-V) para formular un indicativo de propiedad para mostrar que el servidor DRM-E es dueño del certificado de comprobación; el servidor DRM-E envía la solicitud de inscripción al servidor DRM-R, la solicitud incluye el certificado de comprobación, la (PU-E), y el indicativo de propiedad; el servidor DRM-R valida el certificado de comprobación; el servidor DRM-R verifica el indicativo de propiedad; y el servidor DRM-R, cuando la solicitud se va a aprobar, genera un certificado de inscripción digital para el servidor DRM-E para inscribir al servidor DRM-E dentro del sistema DRM, el certificado de inscripción generado está con base por lo menos en parte en el certificado de comprobación y la (PU-E).

3. El método de conformidad con la reivindicación 2, caracterizado porque comprende al servidor DRM-E que entrega el certificado de comprobación de un agente emisor de certificados independiente, el cual es conocido y tiene la confianza del servidor DRM-R para llevar a cabo tal comprobación.

4. El método de conformidad con la reivindicación 2, caracterizado porque comprende al servidor DRM-E que entrega un certificado de comprobación X.509.

5. El método de conformidad con la reivindicación 2, caracterizado porque comprende: un servidor DRM-E que entrega un certificado de comprobación firmado por la parte comprobadora y acompañado por una cadena de certificados que conducen a una raíz conocida, con el propósito de validación; y el servidor DRM-R valida el certificado de comprobación con base en la firma del mismo por la parte comprobadora y la cadena de certificados para establecer que el servidor DRM-E ha sido comprobado.

6. El método de conformidad con la reivindicación 2, caracterizado porque comprende: el servidor DRM-E lleva a cabo uno de: emplear la (PR-V) para codificar la (PU-E) para resultar en (PR-V(PU-E)) como el indicativo de propiedad, o firmar la (PU-E) con (PR-V) para resultar en (PU-E) S (PR-V) como el indicativo de propiedad; y el servidor DRM-R verifica el indicativo de propiedad al aplicar la (PU-V) de la solicitud para decodificar la (PU-E) o verificar la firma para establecer que el servidor DRM-E es dueño de (PR-V) y por lo tanto del certificado de comprobación.

7. El método de conformidad con la reivindicación 2, caracterizado porque el servidor DRM-R genera un certificado de inscripción para incluir la (PU-E) como un identificador del servidor DRM-E, indicativos de identificación para identificar al certificado de comprobación, y una firma con base en una clave privada del servidor DRM-R, por lo cual el indicativo de identificación para el certificado de comprobación en el certificado de inscripción actúa como un puente para el certificado de comprobación u muestra que el servidor DRM-R confía en la parte comprobadora para comprobar al servidor DRM-E.

8. El método de conformidad con la reivindicación 7, caracterizado porque comprende al servidor DRM-R que genera un certificado de inscripción para también incluir una clave pública del servidor DRM-R como una identificación del mismo.

9. El método de conformidad con la reivindicación 7, caracterizado porque comprende al servidor DRM-R que genera el certificado de inscripción para también incluir la información de intervalo de validez, la cual especifica el intervalo durante el cual el certificado de inscripción es válido.

10. El método de conformidad con la reivindicación 1, caracterizado porque el servidor DRM-R tiene una base existente para confiar en el servidor DRM-E, el método comprende: el servidor DRM-E ofrece una identificación del mismo que comprende credenciales que el servidor DRM-R debe reconocer y se espera que autorice; el servidor DRM-E envía una solicitud de inscripción al servidor DRM-R, la solicitud incluye las credenciales y la (PU-E); el servidor DRM-R valida las credenciales; y el servidor DRM-R, cuando va a autorizar la solicitud, genera un certificado de inscripción digital para el servidor DRM-E para inscribir ai servidor DRM-E dentro del sistema DRM, el certificado de inscripción generado está con base por lo menos en parte en las credenciales y en la (PU-E).

11. El método de conformidad con la reivindicación 10, caracterizado porque el servidor DRM-E ofrece las credenciales seleccionadas de un grupo que consiste de una ID de red o una ID de dominio, y las credenciales son emitidas por una tercera parte.

12. El método de conformidad con la reivindicación 10, caracterizado porque comprende al servidor DRM-R que genera un certificado de inscripción para incluir la (PU-E) como un identificador del servidor DRM-E, los indicativos de identificación para identificar las credenciales y una firma con base en la clave privada del servidor DRM-R.

13. El método de conformidad con la reivindicación 12, caracterizado porque el servidor DRM-R genera un certificado de inscripción para también incluir una clave pública del servidor DRM-R como un identificador del mismo.

14. El método de conformidad con la reivindicación 12, caracterizado porque el servidor DRM-R genera un certificado de inscripción para también incluir la información de intervalo de validez, la cual especifica el intervalo durante el cual el certificado de inscripción es válido.

15. El método de conformidad con la reivindicación 1, caracterizado porque el servidor DRM-R lleva a cabo la lógica acostumbrada para decidir si autorizar o no la solicitud.

16. El método de conformidad con la reivindicación 15, caracterizado porque el servidor DRM-R lleva a cabo la lógica acostumbrada seleccionada del cuerpo que consiste en llevar a cabo una revisión de antecedentes del servidor DRM-E y/o su operador, determinar si el servidor DRM-E y/o una porción del mismo es real; determinar si el servidor DRM-E está en una lista de revocación o lista de vigilancia y combinaciones de los mismos.

17. El método de conformidad con la reivindicación 1, caracterizado porque el servidor DRM-R genera un certificado de inscripción para incluir la (PU-E) como un identif icador para el servidor DRM-E, y una firma con base en la clave privada del servidor DRM-R.

18. El método de conformidad con la reivindicación 17, caracterizado porque el servidor DRM-R genera un certificado de inscripción para también incluir la clave pública del servidor DRM-R como un identif icador del mismo.

19. El método de conformidad con la reivindicación 17, caracterizado porque el servidor DRM-R genera un certificado de inscripción para también incluir la información de intervalo de validez, la cual especifica el intervalo durante el cual el certificado de inscripción es válido.

20. El método de conformidad con la reivindicación 17, caracterizado porque el servidor DRM-R genera un certificado de inscripción para también incluir el indicativo identificador para identificar la identificación ofrecida.

21. El método de conformidad con la reivindicación 1, caracterizado porque el servidor DRM-R genera un certificado de inscripción con el empleo de la lógica acostumbrada para generar por lo menos una porción de la información en el certificado de inscripción.

22. El método de conformidad con la reivindicación 1, caracterizado porque el servidor DRM-R une con el certificado de inscripción generado una cadena de certificados que conduce a la autoridad raíz de confianza para que el certificado de inscripción generado pueda validarse con base en la cadena de certificados.

23. El método de conformidad con la reivindicación 1, caracterizado porque además el servidor DRM-E identifica en una lista de autoridad de revocación a por lo menos una entidad con autoridad para revocar la inscripción del servidor DRM-E dentro del sistema DRM, el servidor DRM-E envía la solicitud de inscripción al servidor DRM-R, la solicitud incluye la identificación ofrecida, la (PU-E), y la lista de autoridad de revocación y el servidor DRM-R, cuando va a autorizar la solicitud, genera un certificado de inscripción digital para el servidor DRM-E para inscribir al servidor DRM-E dentro del sistema DRM, el certificado de inscripción generado está con base por lo menos en parte en la (PU-E) y en la lista de autoridad de revocación.

24. El método de conformidad con la reivindicación 23, caracterizado porque el servidor DRM-E identifica a cada entidad en la lista de autoridad de revocación por medio de una clave pública de la misma.

25. El método de conformidad con la reivindicación 23, caracterizado porque el servidor DRM-R genera un certificado de inscripción para incluir la (PU-E) como el identificador del servidor DRM-E, la lista de autoridad de revocación de la solicitud y una firma con base en la clave privada del servidor DRM-R.

26. El método de conformidad con la reivindicación 1, caracterizado porque el servidor DRM-R genera un certificado de inscripción XrML.

27. Un método en combinación con un sistema de administración de derechos digitales (DRM) que tiene una pluralidad de servidores DRM que llevan a cabo funciones de DRM, el método para un servidor DRM-E entrante para ser inscrito dentro del sistema por un servidor DRM-R, de tal manera que el servidor DRM-E debe tener confianza dentro del sistema y caracterizado porque comprende: un servidor DRM-E que ofrece un par de claves pública/privada (PU-E, PR-E) para identificar al servidor DRM-E dentro del sistema DRM; el servidor DRM-E procura un ofrecimiento de identificación del mismo; el servidor DRM-E envía una solicitud de inscripción al servidor DRM-R, la solicitud incluye la identificación ofrecida y la (PU-E); el servidor DRM-R valida la identificación ofrecida; cuando la solicitud será autorizada, genera un certificado de inscripción digital para el servidor DRM-E para inscribir al servidor DRM-E dentro del sistema DRM, el certificado de inscripción generado está con base por lo menos en parte en la (PU-E); regresa el certificado de inscripción generado al servidor DRM-E solicitante; y el ahora servidor DRM-E inscrito almacena el certificado de inscripción regresado en una ubicación adecuada para su uso futuro, el servidor DRM-E con el certificado de inscripción tiene la capacidad de emplear el mismo para emitir documentos DRM dentro del sistema DRM.

28. El método de conformidad con la reivindicación 27, caracterizado porque el servidor DRM-R no tiene bases existentes para confiar en el servidor DRM-E, el método comprende: el servidor DRM-E procura una identificación del mismo que comprende un certificado de comprobación de una parte que desea comprobar al servidor DRM-E, el certificado de comprobación incorpora en el mismo una clave pública (PU-V) y una correspondiente clave privada (PR-V); el servidor DRM-E emplea la (PU-E) y la (PR-V) para formular un indicativo de propiedad para mostrar que el servidor DRM-E es dueño del certificado de comprobación; el servidor DRM-E envía la solicitud de inscripción al servidor DRM-R, la solicitud incluye el certificado de comprobación, la (PU-E), y el indicativo de propiedad; el servidor DRM-R valida el certificado de comprobación; verifica el indicativo de propiedad; y, cuando la solicitud se va a aprobar, genera un certificado de inscripción digital para el servidor DRM-E para inscribir al servidor DRM-E dentro del sistema DRM, el certificado de inscripción generado está con base por lo menos en parte en el certificado de comprobación y la (PU-E).

29. El método de conformidad con la reivindicación 28, caracterizado porque el servidor DRM-E entrega el certificado de comprobación de un agente emisor de certificados independiente, el cual es conocido y tiene la confianza del servidor DRM-R para llevar a cabo tal comprobación.

30. El método de conformidad con la reivindicación 28, caracterizado porque el servidor DRM-E entrega un certificado de comprobación X.509.

31. El método de conformidad con la reivindicación 28, caracterizado porque el servidor DRM-E entrega un certificado de comprobación firmado por la parte comprobadora y acompañado por una cadena de certificados que conducen a una raíz conocida, con el propósito de validación; y el servidor DRM-R valida el certificado de comprobación con base en la firma del mismo por la parte comprobadora y la cadena de certificados para establecer que el servidor DRM-E ha sido comprobado.

32. El método de conformidad con la reivindicación 28, caracterizado porque el servidor DRM-E lleva a cabo uno de: emplear la (PR-V) para codificar la (PU-E) para resultar en (PR-V(PU-E)) como el indicativo de propiedad, o firmar la (PU-E) con (PR-V) para resultar en (PU-E) S (PR-V) como el indicativo de propiedad; y el servidor DRM-R verifica el indicativo de propiedad al aplicar la (PU-V) de la solicitud para decodificar la (PU-E) o verificar la firma para establecer que el servidor DRM-E es dueño de (PR-V) y por lo tanto del certificado de comprobación.

33. El método de conformidad con la reivindicación 28, caracterizado porque el ahora inscrito servidor DRM-E almacena el certificado de inscripción regresado para incluir la (PU-E) como un identif icador del servidor DRM-E, indicativos de identificación para identificar al certificado de comprobación, y una firma con base en una clave privada del servidor DRM-R, por lo cual el indicativo de identificación para el certificado de comprobación en el certificado de inscripción actúa como un puente para el certificado de comprobación y muestra que el servidor DRM-R confía en la parte comprobadora para comprobar al servidor DRM-E.

34. El método de conformidad con la reivindicación 33, caracterizado porque el ahora inscrito servidor DRM-E almacena el certificado de inscripción que también incluye la clave pública del servidor DRM-R como una identificación del mismo.

35. El método de conformidad con la reivindicación 33, caracterizado porque el ahora inscrito servidor DRM-E almacena el certificado de inscripción para también incluir la información de intervalo de validez, la cual especifica el intervalo durante el cual el certificado de inscripción es válido.

36. El método de conformidad con la reivindicación 27, caracterizado porque el servidor DRM-R tiene una base existente para confiar en el servidor DRM-E, el método comprende: el servidor DRM-E ofrece una identificación del mismo que comprende credenciales que el servidor DRM-R debe reconocer y se espera que autorice; el servidor DRM-E envía una solicitud de inscripción al servidor DRM-R, la solicitud incluye las credenciales y la (PU-E);el servidor DRM-R valida las credenciales; y cuando va a autorizar la solicitud, genera un certificado de inscripción digital para el servidor DRM-E para inscribir al servidor DRM-E dentro del sistema DRM, el certificado de inscripción generado está con base por lo menos en parte en las credenciales y en la (PU-E).

37. El método de conformidad con la reivindicación 36, caracterizado porque el servidor DRM-E ofrece las credenciales seleccionadas de un grupo que consiste de una ID de red o una ID de dominio, y las credenciales son emitidas por una tercera parte.

38. El método de conformidad con la reivindicación 36, caracterizado porque comprende el ahora inscrito servidor DRM-E almacena el certificado de inscripción que incluye la (PU-E) como un identificador del servidor DRM-E, los indicativos de identificación para identificar las credenciales y una firma con base en la clave privada del servidor DRM-R.

39. El método de conformidad con la reivindicación 38, caracterizado porque el ahora inscrito servidor DRM-E almacena el certificado de inscripción para también incluir una clave pública del servidor DRM-R como un identificador del mismo.

40. El método de conformidad con la reivindicación 38, caracterizado porque el ahora inscrito servidor DRM-E almacena el certificado de inscripción para también incluir la información de intervalo de validez, la cual especifica el intervalo durante el cual el certificado de inscripción es válido.

41. El método de conformidad con la reivindicación 27, caracterizado porque comprende el ahora inscrito servidor DRM-E almacena el certificado de inscripción que incluye la (PU-E) como un identificador del servidor DRM-E, y una firma con base en la clave privada del servidor DRM-R.

42. El método de conformidad con la reivindicación 41, caracterizado porque el ahora inscrito servidor DRM-E almacena el certificado de inscripción para también incluir una clave pública del servidor DRM-R como un identificador del mismo.

43. El método de conformidad con la reivindicación 38, caracterizado porque el ahora inscrito servidor DRM-E almacena el certificado de inscripción para también incluir la información de intervalo de validez, la cual especifica el intervalo durante el cual el certificado de inscripción es válido.

44. El método de conformidad con la reivindicación 41, caracterizado porque el servidor DRM-E ahora inscrito almacena el certificado de inscripción para también incluir el indicativo identificador para identificar la identificación ofrecida.

45. El método de conformidad con la reivindicación 27, caracterizado porque el ahora inscrito servidor DRM-E almacena el certificado de inscripción regresado incluye una cadena de certificados que conduce a la autoridad raíz de confianza para que el certificado de inscripción generado pueda validarse con base en la cadena de certificados.

46. El método de conformidad con la reivindicación 27, caracterizado porque además el servidor DRM-E identifica en una lista de autoridad de revocación a por lo menos una entidad con autoridad para revocar la inscripción del servidor DRM-E dentro del sistema DRM, el servidor DRM-E envía la solicitud de inscripción al servidor DRM-R, la solicitud incluye la identificación ofrecida, la (PU-E), y la lista de autoridad de revocación y el servidor DRM-R, cuando va a autorizar la solicitud, genera un certificado de inscripción digital para el servidor DRM-E para inscribir al servidor DRM-E dentro del sistema DRM, el certificado de inscripción generado está con base por lo menos en parte en la (PU-E) y en la lista de autoridad de revocación.

47. El método de conformidad con la reivindicación 46, caracterizado porque el servidor DRM-E identifica a cada entidad en la lista de autoridad de revocación por medio de una clave pública de la misma.

48. El método de conformidad con la reivindicación 46, caracterizado porque el ahora inscrito servidor DRM-E almacena el certificado de inscripción regresado para incluir la (PU-E) como el identif icador del servidor DRM-E, la lista de autoridad de revocación de la solicitud y una firma con base en la clave privada del servidor DRM-R.

49. El método de conformidad con la reivindicación 27, caracterizado porque el servidor DRM-R genera un certificado de inscripción XrML.

50. Un método en combinación con un sistema de administración de derechos digitales (DRM) que tiene una pluralidad de servidores DRM que llevan a cabo funciones de DRM, el método para un servidor DRM-E entrante para ser inscrito dentro del sistema por un servidor DRM-R, de tal manera que el servidor DRM-E debe tener confianza dentro del sistema y caracterizado porque comprende: un servidor DRM-R que recibe una solicitud de inscripción desde el servidor DRM-E que incluye un ofrecimiento de identificación y una clave pública del servidor DRM-E (PU-E) para identificar al servidor DRM-E dentro del sistema DRM; el servidor DRM-R valida la identificación ofrecida del mismo; el servidor DRM-R cuando la solicitud será autorizada, genera un certificado de inscripción digital para el servidor DRM-E para inscribir al servidor DRM-E dentro del sistema DRM, el certificado de inscripción generado está con base por lo menos en parte en la (PU-E); el servidor DRM-R regresa el certificado de inscripción generado al servidor DRM-E solicitante; y el ahora servidor DRM-E inscrito almacena el certificado de inscripción regresado en una ubicación adecuada para su uso futuro, el servidor DRM-E con el certificado de inscripción tiene la capacidad de emplear el mismo para emitir documentos DRM dentro del sistema DRM.

51. El método de conformidad con la reivindicación 50, caracterizado porque el servidor DRM-R no tiene bases existentes para confiar en el servidor DRM-E, el método comprende: el servidor DRM-R recibe una solicitud de inscripción desde el servidor DRM-E la cual incluye la (PU-E) y una identificación del mismo que comprende un certificado de comprobación de una parte que desea comprobar al servidor DRM-E, el certificado de comprobación incorpora en el mismo una clave pública (PU-V) y una correspondiente clave privada (PR-V); el servidor DRM-E emplea la (PU-E) y la (PR-V) para formular un indicativo de propiedad para mostrar que el servidor DRM-E es dueño del certificado de comprobación; la solicitud de inscripción incluye el indicativo de propiedad; el servidor DRM-R valida el certificado de comprobación; el servidor DRM-R verifica el indicativo de propiedad; y; cuando la solicitud se va a aprobar, el servidor DRM-R genera un certificado de inscripción digital para el servidor DRM-E para inscribir al servidor DRM-E dentro del sistema DRM, el certificado de inscripción generado está con base por lo menos en parte en el certificado de comprobación y la (PU-E).

52. El método de conformidad con la reivindicación 51, caracterizado porque el servidor DRM-R recibe la solicitud de inscripción del servidor DRM-E que incluye el certificado de comprobación de un agente emisor de certificados independiente, el cual es conocido y tiene la confianza del servidor DRM-R para llevar a cabo tal comprobación.

53. El método de conformidad con la reivindicación 51, caracterizado porque el servidor DRM-R recibe una solicitud de inscripción del servidor DRM-E que incluye un certificado de comprobación X.509.

54. El método de conformidad con la reivindicación 51, caracterizado porque: el servidor DRM-R recibe una solicitud de inscripción del servidor DRM-E que incluye un certificado de comprobación firmado por la parte comprobadora y acompañado por una cadena de certificados que conducen a una raíz conocida, con el propósito de validación; y el servidor DRM-R valida el certificado de comprobación con base en la firma del mismo por la parte comprobadora y la cadena de certificados para establecer que el servidor DRM-E ha sido comprobado.

55. El método de conformidad con la reivindicación 51, caracterizado porque el servidor DRM-E lleva a cabo uno de: emplear la (PR-V) para codificar la (PU-E) para resultar en (PR-V(PU-E)) como el indicativo de propiedad, o firmar la (PU-E) con (PR-V) para resultar en (PU-E) S (PR-V) como el indicativo de propiedad; el método comprende que el servidor DRM-R verifica el indicativo de propiedad al aplicar la (PU-V) de la solicitud para decodificar la (PU-E) o verificar la firma para establecer que el servidor DRM-E es dueño de (PR-V) y por lo tanto del certificado de comprobación.

56. El método de conformidad con la reivindicación 51, caracterizado porque el servidor DRM-R genera el certificado de inscripción para incluir la (PU-E) como un identificador del servidor DRM-E, indicativos de identificación para identificar al certificado de comprobación, y una firma con base en una clave privada del servidor DRM-R, por lo cual el indicativo de identificación para el certificado de comprobación en el certificado de inscripción actúa como un puente para el certificado de comprobación y muestra que el servidor DRM-R confía en la parte comprobadora para comprobar al servidor DRM-E.

57. El método de conformidad con la reivindicación 55, caracterizado porque el servidor DRM-R genera el certificado de inscripción que también incluye la clave pública del servidor DRM-R como una identificación del mismo.

58. El método de conformidad con la reivindicación 56, caracterizado porque el servidor DRM-R genera el certificado de inscripción para también incluir la información de intervalo de validez, la cual especifica el intervalo durante el cual el certificado de inscripción es válido.

59. El método de conformidad con la reivindicación 50, caracterizado porque el servidor DRM-R tiene una base existente para confiar en el servidor DRM-E, el método comprende: el servidor DRM-R recibe una solicitud de inscripción del servidor DRM-E que incluye la (PU-E9 y la identificación del mismo que comprende credenciales que el servidor DRM-R debe reconocer y se espera que autorice; el servidor DRM-R valida las credenciales; cuando va a autorizar la solicitud, el servidor DRM-R genera un certificado de inscripción digital para el servidor DRM-E para inscribir al servidor DRM-E dentro del sistema DRM, el certificado de inscripción generado está con base por lo menos en parte en las credenciales y en la (PU-E).

60. El método de conformidad con la reivindicación 59, caracterizado porque el servidor DRM-R recibe la solicitud de inscripción del servidor DRM-E que incluye las credenciales seleccionadas de un grupo que consiste de una ID de red o una ID de dominio, y las credenciales son emitidas por una tercera parte.

61. El método de conformidad con la reivindicación 59, caracterizado porque comprende el servidor DRM-R genera un certificado de inscripción que incluye la (PU-E) como un identif icador del servidor DRM-E, los indicativos de identificación para identificar las credenciales y una firma con base en la clave privada del servidor DRM-R.

62. El método de conformidad con la reivindicación 61, caracterizado porque el servidor DRM-R genera el certificado de inscripción para también incluir una clave pública del servidor DRM-R como un identificador del mismo.

63. El método de conformidad con la reivindicación 61, caracterizado porque el servidor DRM-R genera el certificado de inscripción para también incluir la información de intervalo de validez, la cual especifica el intervalo durante el cual el certificado de inscripción es válido.

64. El método de conformidad con la reivindicación 50, caracterizado porque el servidor DRM-R lleva a cabo la lógica acostumbrada para decidir si autorizar o no la solicitud.

65. El método de conformidad con la reivindicación 64, caracterizado porque el servidor DRM-R lleva a cabo la lógica acostumbrada seleccionada del cuerpo que consiste en llevar a cabo una revisión de antecedentes del servidor DRM-E y/o su operador, determinar si el servidor DRM-E y/o una porción del mismo es real; determinar si el servidor DRM-E está en una lista de revocación o lista de vigilancia y combinaciones de los mismos.

66. El método de conformidad con la reivindicación 50, caracterizado porque el servidor DRM-R genera un certificado de inscripción para incluir la (PU-E) como un identificador para el servidor DRM-E, y una firma con base en la clave privada del servidor DRM-R.

67. El método de conformidad con la reivindicación 66, caracterizado porque el servidor DRM-R genera un certificado de inscripción para también incluir la clave pública del servidor DRM-R como un identificador dei mismo.

68. El método de conformidad con la reivindicación 66, caracterizado porque el servidor DRM-R genera un certificado de inscripción para también incluir la información de intervalo de validez, la cual especifica el intervalo durante el cual el certificado de inscripción es válido.

69. El método de conformidad con la reivindicación 66, caracterizado porque el servidor DRM-R genera un certificado de inscripción para también incluir el indicativo identificador para identificar la identificación ofrecida.

70. El método de conformidad con la reivindicación 50, caracterizado porque el servidor DRM-R genera un certificado de inscripción con el empleo de la lógica acostumbrada para generar por lo menos una porción de la información en el certificado de inscripción.

71. El método de conformidad con la reivindicación 50, caracterizado porque el servidor DRM-R une con el certificado de inscripción generado una cadena de certificados que conduce a la autoridad raíz de confianza para que eí certificado de inscripción generado pueda validarse con base en la cadena de certificados.

72. El método de conformidad con la reivindicación 50, caracterizado porque el servidor DRM-R recibe una solicitud de inscripción desde un servidor DRM-E, la cual también incluye una lista de la autoridad de revocación que identifica por lo menos a una autoridad para revocar la inscripción del servidor DRM-E dentro del sistema DRM, y cuando el servidor DRM-R va a autorizar la solicitud, generar un certificado de inscripción digital para el servidor DRM-E para inscribir al servidor DRM-E dentro del sistema DRM, el certificado de inscripción generado está con base por lo menos en parte en la lista de autoridad de revocación.

73. El método de conformidad con la reivindicación 72, caracterizado porque el servidor DRM-R genera el certificado de inscripción para incluir la (PU-E) como un identif icador del servidor DRM-E, la lista de autoridad de revocación y una firma con base en una clave privada del servidor DRM-R.

74. El método de conformidad con ia reivindicación 50, caracterizado porque el servidor DRM-R genera un certificado de inscripción XrML.