MXPA04001293A - Conteniendo digital de publicacion dentro de un universo definido tal como una organizacion de acuerdo con un sistema de administracion digital de derechos (drm). - Google Patents

Abstract

Un concedente recibe una solicitud del solicitante, donde la solicitud requiere datos de derechos asociados con contenido digital, y en donde los datos de derechos lista por lo menos un identificador y un conjunto de derechos asociados con el mismo. El concedente selecciona el identificador y el conjunto de derechos asociados con el mismo, en donde los derechos se espera que se establezcan en un sentido digital correspondiente, y tambien selecciona basandose en el identificador y conjunto alternativo de derechos. El conjunto alternativo de derechos es substituido para el conjunto de derechos de los datos de derechos, y la licencia se expide al solicitante con el conjunto alternativo de derechos, mediante el cual el conjunto alternativo de derechos en los conjuntos de licencia expedidos establece terminos y condiciones que el solicitante debe agregar junto con la ejecucion del contenido correspondiente.

Description

CONTENIDO DIGITAL DE PUBLICACION DENTRO DE UN UNIVERSO DEFINIDO TAL COMO UNA ORGANIZACION DE ACUERDO CON UN SISTEMA DE ADMINISTRACION DIGITAL DE DERECHOS (DRIVn REFERENCIA CRUZADA A LAS SOLICITUDES RELACIONADAS Las siguientes Solicitudes de patente de E.U.A. describen la materia objeto que se refiere a la materia objeto de la presente solicitud, y se incorporan en la presente para referencia en su totalidad : La Solicitud de Patente de E.U.A. No. , presentada concurrentemente con la presente solicitud bajo el número de expediente del apoderado SFT-1498 y titulada "Publisfiing Digital Contení Within a Defined Universe Such As an Organizaron in Accordance wiíh a Digital Rights Management (DRM) System" (Contenido Digital de Publicación Con un Universo Definido Tal Como una Organización de Acuerdo con un Sistema de Administración Digital de Derechos) ; La Solicitud de Patente de E.U.A. No. 10/185,527, presentada el 06/28/02 bajo el número de expediente del apoderado MSFT-1330 y titulada "Obtaining a Signed Rights Label (SRL) for Digital Contení and Obtaining a Digital License Corresponding to the Coníení Based on íhe SR in a Digital Rights Management System" (Obtención de una Etiqueta de Derechos Otorgados (SRL) para Contenido Digital y Obtención de una Licencia Digital que Corresponde al Contenido Basándose en SR en un Sistema de Administración Digital de Derechos); La Solicitud de Patente de E.U.A. No. 10/185,278, presentada el 06/28/02 bajo el número de expediente del apoderado MSFT-1333 y titulada "Using a Rights Témplate to Obtain a Signed Rights Label (SRL) for Digital Contení in a Digital Rights Management System" (Utilización de una Plantilla de Derechos para Obtener una Etiqueta de Derechos Otorgados (SRL) para Contenido Digital en un Sistema de Administración Digital de Derechos) ; y La Solicitud de Patente de E.U.A. No. 10/185,511, presentada el 06/28/02 bajo el número de expediente del apoderado MSFT-1343 y titulada "Systems And Methods For Issuing Usage Licenses For Digital Content And Services" (sistema s y Métodos para Expedir Licencias de Uso para Contenido Digital y Servicios).

CAMPO TECNICO Esta invención se refiere a un sistema de administración digital de derechos (DRM). Más particularmente, la invención se refiere a emplear un sistema de DRM para publicar contenido digital en un universo definido tal como una organización, una oficina, una corporación o similar de manera que la ejecución y uso del contenido dentro del universo pueda restringirse de acuerdo con los términos de uso o licencia correspondientes.

ANTECEDENTES DE LA INVENCION La administración digital de derechos y ejecuciones altamente deseable junto con el contenido digital tal como audio digital, video digital, texto digital, datos digitales, multimedia digital, etc., donde el contenido digital va a distribuirse a uno o más usuarios. El contenido digital puede ser estático, tal como un documento de texto, por ejemplo, o puede ser propagado, tal como el audio/video propagado de un evento en vivo. Modos típicos de distribución incluyen dispositivos tangibles tal como un disco magnético (flexible), una cinta magnética, un disco óptico (CD (compactos)), etc., y medios tangibles tal como un tablero electrónico de noticias, una red electrónica, la Internet, etc. Al ser recibido por el usuario, tal usuario ejecuta o 'reproduce' el contenido digital con la ayuda de un dispositivo de ejecución apropiado tal como un reproductor de medios en una computadora personal o similar. En un escenario, un dueño de contenido, o dueño de derechos tal como un autor, publicista, un difusor, etc., pide distribuir el contenido digital a cada uno de muchos usuarios o receptores a cambio de una comisión por licencia o alguna otra consideración. En tal escenario, entonces, el contenido puede ser una canción, un álbum de canciones, una película, etc., y el propósito de la distribución es generar las comisiones por licencia. El dueño de contenido, dada la opción, probablemente desearía restringir lo que el usuario puede hacer con el contenido digital distribuido. Por ejemplo, el dueño de contenido quisiera evitar que el usuario copiara y re-distribuyera el contenido a un segundo usuario, por lo menos en una forma que niegue al dueño del contenido una comisión por licencia del segundo usuario. Además, el dueño de contenido puede pedir proporcionar al usuario con la flexibilidad de comprar diferentes tipos de licencias de uso a diferentes comisiones por licencia, mientras al mismo tiempo mantenga al usuario en los términos de cualquier tipo de licencia que de hecho se compra. Por ejemplo, el dueño de contenido puede pedir permitir que el contenido digital distribuido se reproduzca solamente un número limitado de veces, sólo durante un cierto tiempo to.tal, sólo un cierto tipo de máquina, sólo en un cierto tipo de reproductor de medios, sólo por un cierto tipo de usuario, etc. En otro escenario, un desarrollador de contenido, tal como un empleado o miembro de una organización, pide distribuir el contenido digital a uno u otros más empleados o miembros en la organización o a los otros individuos fuera de la organización, pero quisiera evitar que los otros ejecutaran el contenido. Aquí, la distribución del contenido es más semejante al contenido basado en organización que se comparte en una forma confidencial o restringida, como opuesto a la distribución a base difundida a cambio de una comisión por licencia o alguna otra consideración. En tal escenario, entonces, el contenido puede ser una presentación de documentos, hoja de cálculo, base de datos, correo electrónico, o similares, tal como puede intercambiarse dentro de un establecimiento de oficinas, y el desarroilador de contenido puede pedir asegurar que el contenido permanezca dentro de la organización o establecimiento de oficinas y no se ejecute por ningún individuo no autorizado, tal como por ejemplo, competidores o adversarios. Nuevamente, el desarroilador de contenido pide restringir lo que un receptor puede hacer con el contenido digital distribuido. Por ejemplo, el dueño de contenido quisiera evitar que el usuario copiara y redistribuyera el contenido a un segundo usuario, por lo menos en una forma que exponga el contenido fuera de los límites de individuos que se les permita ejecutar el contenido . Además, el desarroilador de contenido puede pedir proporcionar a varios receptores con diferentes niveles de derechos de ejecución. Por ejemplo, el desarroilador de contenido puede pedir permitir que el contenido digital protegido se pueda ver y no se pueda imprimir con respecto a una clase de individuo, y se pueda ver o imprimir con respecto a otra clase de individuo. Sin embargo, y en cualquier escenario, después de que ha ocurrido la distribución, el dueño/desarrollador de contenido tiene muy poco sino es que nada de control sobre el contenido digital. Esto es especialmente problemático en vista del hecho de que prácticamente cada computadora personal incluye el software y hardware necesario para hacer una copia digital exacta del contenido digital, y para descargar la copia digital exacta a un disco magnético u óptico que se puede describir, o para enviar la copia digital exacta en una red tal como la Internet a cualquier destino. Desde luego, como parte de una transacción donde el contenido se distribuye, el dueño/desarrollador de contenido puede requerir que el usuario/receptor del contenido digital prometa no redistribuir el contenido digital en una forma mal recibida. Sin embargo, una promesa fácilmente se hace y fácilmente se rompe. Un dueño/desarrollador de contenido puede intentar evitar la redistribución a través de cualquiera de los dispositivos de seguridad conocidos, implicando normalmente encriptación y descifrado. Sin embargo, probablemente existe muy poco que evite en un usuario medianamente determinado descifre contenido digital encriptado, guarde contenido digital en una forma no encriptada, y después lo re-distribuya. Existe una necesidad, entonces, para proporcionar una administración digital de derechos (DRM) y arquitectura y método de ejecución que permita la ejecución controlada o reproducción de formas arbitrarias de contenido digital en donde el control es flexible y definible por el dueño/desarrollador de contenido del contenido digital. Más específicamente, existe una necesidad de una arquitectura que permita y facilite la ejecución controlada, especialmente en una oficina o ambiente de organización o similar donde los documentos serán compartidos entre un grupo definido de individuos o clases de individuos.

COMPENDIO DE LA INVENCION Las necesidades antes mencionadas se satisfacen por lo menos en parte por la presente invención en la cual un concedente emite una licencia digital a un solicitante para permitir que el solicitante ejecute el contenido digital correspondiente. En la invención, el concedente recibe una solicitud del solicitante donde la solicitud incluye datos de derechos asociados con el contenido, y donde los datos de derechos listan por lo menos un identificador y un juego de derechos asociados con el mismo. El concedente selecciona el identificador y el juego de derechos asociados con el mismo, donde se espera que los derechos se establezcan en la licencia expedida, y también selecciona basándose en el identificador un juego alternativo de derechos. El juego alternativo de derechos son sustituidos por el juego de derechos de los datos de derechos, y se emite la licencia al solicitante con el juego alternativo de derechos, mediante el cual el juego alternativo de derechos en la licencia expedida establece los términos y condiciones que el solicitante debe adherir junto con la ejecución del contenido correspondiente.

BREVE DESCRIPCION DE LOS DIBUJOS El compendio anterior, así como la siguiente descripción detallada de las modalidades de la presente invención, se entenderán mejor cuando se lean junto con los dibujos anexos. Para el propósito de ilustrar la invención, se muestra en los dibujos modalidades que pueden preferirse actualmente. Como debe entenderse, sin embargo, la invención no se limita a las disposiciones precisas e instrumentalidades mostradas. En los dibujos: La Figura 1 es un diagrama de bloque que representa un ambiente de cómputo no limitante ejemplar en el cual la presente invención puede implementarse; La Figura 2 es un diagrama de bloque que representa un ambiente de red ejemplar que tiene una variedad de dispositivos de cómputo en los cuales la presente invención puede implementarse; La Figura 3 es un diagrama de bloque funcional de una modalidad de un sistema y método de acuerdo con la invención para publicar contenido digital; La Figura 4 es un diagrama de flujo de una modalidad de un método de acuerdo con la invención para publicar contenido digital manejado por los derechos; La Figura 4A es un diagrama de bloque que muestra la estructura de una etiqueta de derechos firmada como producida por ei método de la Figura 4; La Figura 5 es un diagrama de bloque de una modalidad de un sistema y método de acuerdo con la invención para autorizar contenido digital manejado por derechos; Las Figuras 6A y 6B son diagramas de flujo de una modalidad de un método de acuerdo con la invención para autorizar contenido digital manejado por derechos; La Figura 7 es un diagrama de flujo que muestra las etapas claves realizadas para re-publicar una etiqueta de derechos de acuerdo con una modalidad de la presente invención; La Figura 8 es un diagrama de bloque que muestra un certificado expedido por un servidor de DR a un usuario para permitir que el usuario realice la publicación fuera de línea de acuerdo con una modalidad de la presente invención; La Figura 9 es un diagrama de bloque que muestra una plantilla de derechos que especifica la información que debe incorporarse en una etiqueta de derechos de acuerdo con una modalidad de la presente invención; La Figura 10 es un diagrama de flujo que muestra las etapas claves realizadas para crear la plantilla de derechos de la Figura 9 y para crear la etiqueta de derechos firmada de la Figura 4A basándose en la plantilla de derechos de acuerdo con una modalidad de la presente invención; La Figura 11 es un diagrama de bloque que muestra una arquitectura de ejecución de un ejemplo de un sistema basado en fideicomiso. La Figura 12 es un diagrama de bloque que muestra un concedente que procesa una solicitud para una licencia de acuerdo con una modalidad de la presente invención; La Figura 13 es un diagrama de flujo que muestra las etapas realizadas por el concedente de la Figura 12 junto con un directorio de cuándo se expide una licencia; y La Figura 14 es un diagrama de flujo que muestra las etapas realizadas por el concedente de la Figura 12 cuando se introduce la política en una licencia que va a expedirse.

DESCRIPCION DETALLADA DE LA INVENCION AMBIENTE DE COMPUTO La Figura 1 y la siguiente discusión se pretenden para proporcionar una breve descripción general de un ambiente de cómputo adecuado en el cual puede implementarse la invención. Se debe entender, sin embargo, que los dispositivos de cómputo portátiles, transportables y otros de todos los tipos se contemplan para su uso junto con la presente invención. Mientras una computadora de propósito general se describe en lo siguiente, sin embargo esto es un ejemplo, y la presente invención requiere sólo un cliente fino que tenga interoperabilidad e interacción de servidor de red. De este modo, la presente invención puede implementarse en un ambiente de servicios alojados en red en los cuales muy = pocos recursos o mínimos de clientes son implicados, por ejemplo, un ambiente en red en el cual el dispositivo de cliente sirve solamente como un navegador o interfase para la Gran Red Mundial. Aunque no se requiere, la invención puede implementarse mediante una interfase de programa de aplicación (API), para su uso por un desarrollador, y/o incluirse dentro del software de navegación de red que se describirá en el contexto general de instrucciones que se pueden ejecutar por la computadora, tal como módulos de programa, que son ejecutados por una o más computadoras, tal como estaciones de trabajo de cliente, servidores u otros dispositivos. Generalmente, los módulos de programa incluyen rutinas, programas, objetos, componentes, estructuras de datos y similares que realizan tareas particulares o implementan tipos de datos de resumen particular. Típicamente, la funcionalidad de los módulos del programa pueden combinarse o distribuirse como se desee en varias modalidades. Además, aquellos con experiencia en la técnica apreciarán que la invención puede practicarse con otras configuraciones de sistema de computadora. Otros sistemas de cómputo bien conocidos, ambientes y/o configuraciones que pueden ser adecuadas para su uso con la invención incluyen, pero no se limitan a, computadoras personales (las PC), máquinas registradoras automáticas, computadoras de servidor, dispositivos portátiles o laptop, sistemas multi-procesadores, sistemas a base de microprocesadores, electrónicas del consumidor programables, las PC de red, minicomputadoras, computadoras de procesador central, y similares. La invención también puede practicarse en ambientes de cómputo distribuidos donde se realizan tareas mediante dispositivos de procesamiento remotos que son enlazados a través de una red de comunicaciones u otro medio de transmisión de datos. En un ambiente de cómputo distribuido, los módulos de programa pueden localizarse en medios de almacenaje de computadora local y remoto que incluye el dispositivo de almacenaje de memoria. La Figura 1 de este modo ilustra un ejemplo de un ambiente 100 del sistema de cómputo adecuado en el cual la invención puede impiementarse, aunque como es claro en lo anterior, el ambiente 100 de sistema de cómputo solamente es un ejemplo de un ambiente de cómputo adecuado y no se pretende sugerir ninguna limitación al alcance del uso o funcionalidad de la invención. Ni el ambiente 100 de cómputo debe interpretarse como teniendo alguna dependencia o requerimiento con relación a cualquiera de o una combinación de componentes ¡lustrados en el ambiente 100 de operación ejemplar. Con referencia a la Figura 1, un sistema ejemplar para implementar la invención incluye un dispositivo de cómputo de propósito general en la forma de una computadora 110. Los componentes de la computadora 110 pueden incluir, pero no se limitan a, una unidad 120 de procesamiento, una memoria 130 de sistema, y una barra colectora 121 de sistema que acopla varios componentes del sistema incluyendo la memoria del sistema a la unidad 120 de procesamiento. La barra colectora 121 de sistema puede ser cualquiera de varios tipos de estructuras de barra colectora que incluyen una barra colectora de memoria o controlador de memoria, una barra colectora periférico, y una barra colectora local que utiliza cualquiera de una variedad de arquitecturas de barra colectora. Por medio del ejemplo, y no de limitación, las arquitecturas incluyen barra colectora de Arquitectura Estándar Industrial (ISA), barra colectora de Arquitectura de Micro Canal (MCA), barra colectora de ISA Mejorada (EISA), barra colectora local de Asociación de Estándares Electrónicos de Vídeo (VESA), y barra colectora de Interconexión de Componente Periférico (PCI) (también conocido como barra colectora Mezzanine). La computadora 110 típicamente incluye una variedad de medios que se pueden leer por computadora. Los medios que se pueden leer por computadora pueden ser cualquier medio disponible que pueda accesarse por la computadora 110 e incluye medios volátiles y no volátiles, medios removibies y no removibles. Por medio del ejemplo, y no de limitación, los medios que se pueden leer por computadora pueden comprender medio de almacenaje para computadora y medios de comunicación. El medio de almacenaje para computadora incluye medios volátil y no volátil, removible y no removible implementados en cualquier método o tecnología para almacenaje de información tal como instrucciones que se pueden leer por computadora, estructuras de datos, módulos de programa u otros datos. El medio de almacenaje para computadora incluye, pero no se limita a, RAM, ROM, EEPROM, memoria flash u otra tecnología de memoria, CDROM, discos versátiles digitales (DVD), u otro almacenaje de disco óptico, cassettes magnéticos, cinta magnética, almacenaje de disco magnético u otros dispositivos de almacenaje magnéticos, o cualquier otro medio que puede utilizarse para almacenar la información deseada y que pueda accesarse por la computadora 110. El medio de comunicación típicamente representa las instrucciones que se pueden leer por computadora, estructuras de datos, módulos de programa u otros datos en una señal de datos modulada tal como una onda portadora u otro mecanismo de transporte e incluye cualquier medio de suministro de información. El término "señal de datos modulada" quiere decir una señal que tiene una o más de sus características establecidas o cambiadas de tal forma para codificar información en la señal. Por medio del ejemplo y no de limitación, el medio de comunicación incluye medios cableados tal como una red cableada o conexión de cable directo, y medios inalámbricos tal como medios acústicos, de RF infrarrojos u otros inalámbricos. Combinaciones de cualquiera de los anteriores también deben incluirse dentro del alcance del medio que se puede leer por computadora. La memoria 130 del sistema incluye el medio de almacenaje de computadora en forma de una memoria volátil y/o no volátil tal como una memoria 131 de sólo lectura (ROM) y memoria 132 de acceso aleatorio (RAM). Un sistema 133 de entrada/salida básico (BIOS), que contiene las rutinas básicas que ayudan a transferir información entre elementos dentro de la computadora 110, tal como durante el arranque, típicamente se almacena en ROM 131. La RAM 132 típicamente contiene datos y/o módulos de programas que son accesibles inmediatamente y/o que se operan actualmente o por la unidad 120 de procesamiento. Por medio del ejemplo, y no de limitación, la FIGURA 1 ilustra el sistema 134 de operación, los programas 135 de aplicación, otros módulos 136 de programas, y los datos 137 de programas. La computadora 110 también puede incluir otros medios de almacenaje para computadora removible/no removibles, volátiles/no volátiles. Por medio del ejemplo solamente, la Figura 1 ilustra una unidad 141 de disco duro que lee o escribe en medio magnético no removible, no volátil, una unidad 151 de disco magnético que lee o escribe en un disco 152 magnético o removible, no volátil, y una unidad 155 de disco óptico que lee o escribe en un disco 156 óptico removible, no volátil, tal como un CD ROM u otro medio óptico. Otros medios de almacenaje para computadora removibles/no removibles, volátiles/no volátiles que pueden utilizarse en el ambiente de operación ejemplar incluyen, pero no se limitan a cassettes de cinta magnética, tarjetas de memoria flash, discos versátiles digitales, cinta de video digital, RAM de estado sólido, ROM de estado sólido, y similares. La unidad 141 de disco duro típicamente se conecta al barra colectora 121 de sistema a través de una interfase de memoria no removible tal como la interfase 140, y la unidad 151 de disco magnético y la unidad 155 de disco óptico se conectan típicamente al barra colectora 121 de sistema mediante una interfase de memoria removible, tal como la interfase 150. Las unidades y sus medios de almacenaje para computadora asociados discutidos en lo anterior e ilustrados en la Figura 1 proporcionan el almacenaje de instrucciones que se pueden leer por computadora, estructuras de datos, módulos de programas y otros datos para la computadora 110. En la Figura 1, por ejemplo, la unidad 141 de disco duro se ilustra como el sistema 144 de operación de almacenaje, programas 145 de aplicación, otros módulos 146 de programas, y los datos 147 de programas. Nótese que estos componentes pueden ser ya sea los mismos o diferentes del sistema 134 de operación, programas 135 de aplicación, u otros módulos 136 de programas, y los datos 137 de programas. El sistema 144 de operación, los programas 145 de aplicación, otros módulos 146 de programas, y ios datos 147 de programas se les da diferentes números aquí para ilustrar que, al mínimo, son diferentes copias. Un usuario puede ingresar comandos e información en la computadora 110 a través de dispositivos de entrada tal como un teclado 162 y un dispositivo 161 señalador, comúnmente referido como ratón, bola de rastreo o cojín digital. Otros dispositivos de entrada (no mostrados) pueden incluir un micrófono, joystick, teclado de juegos, disco satelital, explorador o similares. Estos y otros dispositivos de entrada con frecuencia se conectan a la unidad 120 de procesamiento a través de la interfase 160 de entrada de usuario que es acoplada al barra colectora 121 de sistema, pero puede conectarse mediante otra interfase y estructuras de barra colectora tal como un puerto paralelo, puerto de juegos o una barra colectora en serie universal (USB). Un monitor 191 u otro tipo de dispositivo de presentación también se conecta a la barra colectora 121 de sistema mediante una interfase, tal como una interfase 190 de video. Una interfase 182 de gráficos, tal como Northbridge, también puede conectarse a la barra colectora 121 de sistema. Northbridge es un chip que se comunica con la CPU, o la unidad 120 de procesamiento principal, y asume la responsabilidad de las comunicaciones del puerto de gráficos acelerado (AGP). Una o más unidades 184 de procesamiento de gráficos (las GPU) pueden comunicarse con la interfase 182 de gráficos. En este respecto, las GPU 184 generalmente incluyen almacenaje de memoria sobre chip, tal como un almacén de registros y las GPUs 184 se comunican con una memoria 186 de video. Las GPUs 184, sin embargo, son sólo un ejemplo de un coprocesador y de este modo de una variedad de dispositivos de co-procesamiento que pueden incluirse en la computadora 110. Un monitor 191 u otro tipo de dispositivo de presentación también se conecta a la barra colectora 121 de sistema mediante una interfase, tal como la interfase 190 de video, que a su vez puede comunicarse con la memoria 186 de video. Además del monitor 191, las computadoras también pueden incluir otros dispositivos de salida periféricos tales como altavoces 197 e impresoras 196, que pueden conectarse a través de la interfase 195 periférica de salida. La computadora 110 puede operar en un ambiente de red utilizando conexiones lógicas a una o más computadoras remotas, tal como una computadora 180 remota. La computadora 180 remota puede ser una computadora personal, un servidor, un enrutador, una PC de red, un dispositivo homólogo u otro nodo de red común, y típicamente incluye mucho o todos los elementos descritos en lo anterior con relación a la computadora 110, aunque solamente el dispositivo 181 de almacenaje de memoria se ha ilustrado en al Figura 1. Las conexiones lógicas' representadas en la Figura 1 incluyen una red de área local 171 (LAN) y una red de área extensa 173 (WAN) pero también puede incluir otras redes. Los ambientes de red son comunes en oficinas, redes de computadora de empresas, intranet y la Internet. Cuando se utiliza en un ambiente de red de LAN la computadora 110 se conecta a la LAN 171 a través de una interfase o adaptador 170 de red. Cuando se utiliza en un ambiente de red de WAN, la computadora 110 típicamente incluye un módem 172 u otro medio para establecer comunicaciones sobre la WAN 173, tal como la Internet. El módem 172, el cual puede ser interno o externo, puede conectarse a la barra colectora 121 de sistema mediante la interfase 160 de entrada de usuario u otro mecanismo apropiado. En un ambiente de red, los módulos de programa representados con relación a la computadora 110 o porciones de los mismos pueden almacenarse en el dispositivo de almacenaje de memoria remoto. Por medio del ejemplo, y no de limitación, la FIGURA 1 ilustra programa 185 de aplicación remotos como residiendo en el dispositivo 181 de memoria. Se apreciará que las conexiones de red mostradas son ejemplares y otros medios para establecer un enlace de comunicación entre las computadoras pueden utilizarse. Alguien con experiencia en la técnica puede apreciar que una computadora 110 u otro dispositivo de cliente puede desplegarse como parte de una red de computadoras. En este respecto, la presente invención pertenece a cualquier sistema computarizado que tenga cualquier número de unidades de memoria de almacenaje, y cualquier número de aplicaciones y procesos que ocurran a través de cualquier número de unidades de almacenaje o volúmenes. La presente invención puede aplicarse a un ambiente con computadoras de servidor y computadoras de clientes desplegadas en un ambiente de red, que tengan almacenaje remoto o local. La presente invención puede también aplicarse a un dispositivo de cómputo autónomo que tenga funcionalidad de lenguaje de programación, interpretación y capacidades de ejecución. El cómputo distribuido facilita la participación de recursos de computadora y servicios mediante un intercambio directo entre dispositivos y sistemas de cómputo. Estos recursos y servicios incluyen intercambio de información, almacenaje de antememoria y almacenaje en disco para archivos. El cómputo distribuido toma ventaja de la conectividad de red, permitiendo que los clientes apalanquen su potencia colectiva para beneficiarse de toda la empresa. En este respecto, una variedad de dispositivos puede tener aplicaciones, objetos o recursos que pueden interactuar para implicar las técnicas de autenticación de la presente invención para conducto o conductos de gráficos de confianza. La Figura 2 proporciona un diagrama esquemático de un ambiente de cómputo o en red o distribuido ejemplar. El ambiente de cómputo distribuido comprende objetos 10a, 10b, de cómputo, etc., y objetos o dispositivos 110a, 110b, 110c de cómputo, etc. Estos objetos pueden comprender programas, métodos, almacenes de datos, lógica programable, etc. Los objetos pueden comprender porciones de los mismos dispositivos o diferentes tales como PDA, televisiones, reproductores de MP3, televisiones, computadoras personales, etc. Cada objeto puede comunicarse con otro objeto por medio de la red 14 de comunicación. Esta red por sí misma puede comprender otros objetos de cómputo y dispositivos de cómputo que proporcionen servicios al sistema de la Figura 2. De acuerdo 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 conducto o conductos de gráficos de confianza. También puede apreciarse que un objeto, tal como 110c, puede alojarse en otros dispositivos 10 ó 110 de cómputo. De este modo, aunque el ambiente físico representado puede mostrar los dispositivos conectados como computadoras, la ilustración solamente es ejemplar y ei ambiente físico puede representarse alternativamente o describirse comprendiendo varios dispositivos digitales tales como PDA, televisiones, reproductores de MP3, etc.; objetos de software tales como interfaces, objetos de COM y similares. Existe una variedad de sistemas, componentes y configuraciones de red que soportan ambientes de cómputo distribuidos. Por ejemplo, los sistemas de computo pueden conectarse juntos mediante sistemas de cableado o inalámbricos, mediante redes locales o redes distribuidas ampliamente. Actualmente, muchas de las redes son acopladas al Internet, que proporcionan la infraestructura para el cómputo ampliamente distribuido y abarcan muchas redes diferentes. En ambientes de red domésticos, existen por lo menos cuatro medios de transporte de red disparejos que pueden soportar cada uno un protocolo único tal como la línea de energía, datos, ambos (inalámbricos y cableados), voz (por ejemplo, teléfono) y medios de entretenimiento. La mayor parte de los dispositivos de control domésticos tales como interruptores de luz y aparatos pueden utilizar la línea de energía para la conectividad . Los servicios de datos pueden ingresar a la casa como banda ancha (por ejemplo, ya sea módem de DSL o Cable) y son accesibles dentro de la casa utilizando conectividad inalámbrica (por ejemplo, HomeRF o 802.11b) o cableada (por ejemplo, Home PNA, Cat 5, incluso la línea de energía). El tráfico de voz puede entrar a la casa ya sea como cableado (por ejemplo, Cat 3) o inalámbrico (por ejemplo, teléfonos celulares) y puede distribuirse dentro de la casa utilizando el cableado Cat 3. Los medios de entretenimiento pueden entrar a la casa ya sea a través de! satélite o cable y se distribuyen típicamente en la casa utilizando cable coaxial. IEEE 1394 y DVI también están surgiendo como interconexiones digitales para cúmulos de dispositivos de medios. Todos éstos ambientes de red y otros que pueden surgir como estándares de protocolo pueden interconectarse para formar una intranet que pueda conectarse al mundo externo por medio de la Internet. En breve, una variedad de recursos disparejos existe para el almacenaje y transmisión de datos, y consecuentemente, yendo hacia delante, los dispositivos de cómputo requerirían formas para proteger el contenido en todas las porciones del conducto de procesamiento de datos. La 'Internet' comúnmente se refiere a la colección de redes y pasarela que utilizan la suite TCP/IP de protocolos que se conocen bien en la técnica de red computarizada. TCP/IP es un acrónimo para "Protocolo de Control del Transporte/Programa de interfaz". La Internet puede describirse como un sistema de redes de cómputo remotas geográficamente distribuidas interconectadas por computadoras que ejecutan protocolos de red que permiten que los usuarios interactúen y compartan información sobre las redes. Debido a la participación de información ampliamente difundida, las redes remotas tales como la Internet han evolucionado generalmente en un sistema abierto para el cual los desarrolladores pueden diseñar aplicaciones de software para realizar operaciones o servicios especializados, esencialmente sin restricción. De este modo, la infraestructura de red habilita un ordenador principal de topologías de red tal como cliente/servidor, homólogo a homólogo, o arquitecturas híbridas. El "cliente" es un miembro de una clase o grupo que utiliza los servicios de otra clase o grupo al cual no se relaciona. De este modo, en cómputo, un cliente es un proceso, es decir, aproximadamente un conjunto de instrucciones o tareas, que solicita un servicio proporcionado por otro programa. El proceso de cliente utiliza el servicio requerido sin tener que "saber" ningún detalle de trabajo sobre el otro programa o servicio mismo. En una arquitectura de cliente/servidor, particularmente un sistema de red, un cliente normalmente es una computadora que tiene acceso a recursos de red compartidos proporcionados por otra computadora, por ejemplo un servidor. En el ejemplo de la Figura 2, las computadoras 110a, 110b, etc., pueden pensarse como clientes y la computadora 10a, 10b, etc., pueden pensarse como el servidor donde el servidor 10a, 10b, etc., mantiene los datos que entonces son duplicados en las computadoras 110a, 110b, etc., de cliente. Un servidor típicamente es un sistema de computadora remoto accesible sobre una red remota tal como la Internet. El proceso de cliente puede ser activo en un primer sistema de computadora, y el proceso de servidor puede ser activo en un segundo sistema de computadora, comunicándose entre sí sobre un medio de comunicación, de este modo proporcionando la funcionalidad distribuida y permitiendo que múltiples clientes tomen ventaja de las capacidades que reúnen la información del servidor. El cliente y el servidor se comunican entre sí utilizando la funcionalidad proporcionada por una capa de protocolo. Por ejemplo, el Protocolo de Transferencia de Hipertexto (HTTP) es un protocolo común que se utiliza junto con la Red Mundial (WWW). Típicamente, una dirección de red de computadora tal como un Localizador de Recurso Universal (URL) o una dirección de Protocolo de Internet (IP) se utiliza para identificar las computadoras de servidor o cliente entre sí. La dirección de red puede referirse como una dirección de Localizador de Recurso Universal. Por ejemplo, la comunicación puede proporcionarse sobre un medio de comunicación. En particular, el cliente y el servidor pueden acoplarse entre sí mediante conexiones de TCP/IP para comunicación de alta capacidad. De este modo, la Figura 2 ilustra un ambiente de red o distribuido ejemplar, con un servidor en comunicación con las computadoras de cliente mediante una red/barra colectora, en la cual la presente invención puede emplearse. En mayor detalle, un número de servidores 10a, 10b, etc., se interconecta mediante una red/barra colectora 14 de comunicación, la cual puede ser una LAN, WAN, intranet, la Internet, etc., con un número de dispositivos 110a, 110b, 110c, 110d, 110e, etc., de cómputo de cliente o remotos, tal como una computadora portátil, una computadora transportable, cliente fino, aparato de red, u otro dispositivo tal como una VCR, TV, horno, lámpara, calentador y similar de acuerdo con la presente invención. De este modo se contempla que la presente invención puede aplicarse a cualquier dispositivo de cómputo junto con el cual es deseable procesar, almacenar o ejecutar contenido seguro a partir de una fuente de confianza. En un ambiente de red en el cual la red/barra colectora 14 de comunicación es la Internet, por ejemplo, los servidores 10 pueden ser servidores de Web con los cuales los clientes 110a, 110b, 110c, 11 O d , 11 O e , etc., se comunican mediante cualquiera de un número de protocolos conocidos tal como HTTP. Los servidores 10 también pueden servir como clientes 110, como puede ser característica de un ambiente de cómputo distribuido. Las comunicaciones pueden ser cableadas o inalámbricas, donde sea apropiado. Los dispositivos 110 de cliente pueden comunicarse o no mediante la red/barra colectora 14 de comunicación, y pueden tener comunicaciones independientes asociadas con el mismo. Por ejemplo, en el caso de una TV o VCR, puede existir un aspecto de red o no para el control del mismo. Cada computadora 110 de cliente y computadora 10 de servidor pueden equiparse con varios módulos de programas de aplicación u objetos 135 y con conexiones o acceso a varios tipos de elementos de almacenaje u objetos, a través de los cuales pueden almacenarse archivos a los cuales pueden descargarse o migrarse porción o porciones de archivos. De este modo, la presente invención puede utilizarse en un ambiente de red de computadora que tiene computadoras 110a, 110b, etc., de cliente, que pueden tener acceso e interactuar con una red/barra colectora 14 de computadora y las computadoras 10a, 10b, etc., del servidor que pueden interactuar con computadoras 110a, 110b, etc., de cliente y otros dispositivos 111 y bases de datos 20.

Apreciación Global de la Administración Digital de Derechos (DR ) Como se conoce, y con referencia ahora a la Figura 11, la administración digital de derechos (DRM) y ejecución es altamente deseable junto con el contenido 12 digital tal como audio digital, video digital, texto digital, datos digitales, multimedia digital, etc.; donde el contenido 12 digital va a distribuirse a usuarios. Al ser recibido por el usuario, el usuario ejecuta o 'reproduce' el contenido digital con la ayuda de un dispositivo de ejecución apropiado tal como un reproductor de medios en una computadora 14 personal o similar. Típicamente, un dueño o desarrollador de contenido (de aquí en adelante 'dueño') que distribuye el contenido 12 digital pide restringir lo que el usuario puede hacer con el contenido 12 digital distribuido. Por ejemplo, el dueño de contenido puede pedir evitar que el usuario copie y re-distribuya el contenido 12 a un segundo usuario, o puede pedir permitir que el contenido 12 digital distribuido se reproduzca solamente un número limitado de veces, solamente para un cierto tiempo total, solamente en un cierto tipo de máquina, solamente en un cierto tipo de reproductor de medios, solamente mediante un cierto tipo de usuario, etc. Sin embargo, después de que ha ocurrido la distribución, el dueño de contenido tiene un poco si no es que ningún control sobre el contenido 12 digital. Un sistema 10 de DRM, entonces, permite la ejecución o reproducción controlada de formas arbitrarias del contenido 12 digital, donde el control flexible y definible por el dueño de contenido del contenido digital. Típicamente, el contenido 12 se distribuye al usuario en forma de un paquete 13 por medio de cualquier canal de distribución apropiado. El paquete 13 de contenido digital como distribuido puede incluir el contenido 12 digital encriptado con una clave de encriptación/descifrado simétrica (KD), (es decir, (KD(CONTENIDO))), así como otra información que identifica el contenido, cómo adquirir una licencia para el contenido, etc. El sistema 10 de DRM a base de confianza permite que un dueño de contenido 12 digital especifique las normas de licencia que deben satisfacerse antes de que el contenido 12 digital se permita ejecutar en un dispositivo 14 de cómputo del usuario. Las normas de licencia pueden incluir el requerimiento temporal antes mencionado, y pueden representarse dentro de una licencia digital o documento de uso (de aquí en adelante 'Licencia') 16 que el usuario/dispositivo 14 de cómputo del usuario (de aquí en adelante, los términos se pueden intercambiar a menos de que las circunstancias lo requieran de otra forma) deben obtener a partir del dueño de contenido o un agente del mismo. La licencia 16 también incluye la clave de descifrado (KD) para descifrar el contenido digital, tal vez encriptado de acuerdo con una clave que se puede descifrar por el dispositivo de cómputo del usuario. El dueño de contenido para una pieza del contenido 12 digital debe confiar de que el dispositivo 14 de cómputo del usuario cumplirá con las normas y requerimientos especificados por el dueño de contenido en la licencia 16, es decir, que el contenido 12 digital no se ejecutará a menos que las normas y requerimientos dentro de la licencia 16 se satisfagan. Preferiblemente, entonces, el dispositivo 14 de cómputo del usuario se proporciona con un componente o mecanismo 18 de confianza que no ejecutará el contenido 12 digital excepto de acuerdo con las normas de licencia representadas en la licencia 16 asociada con el contenido 12 digital, y obtenida por el usuario. El componente 18 de confianza típicamente tiene un evaluador 20 de licencia que determina si ia licencia 16 es válida, revisa las normas de licencia y los requerimientos en la licencia 16 válida, y determina basándose en las normas de licencia revisadas y requerimientos si el usuario solicitante tiene el derecho de ejecutar el contenido 12 digital requerido en la forma buscada, entre otras cosas. Como debe entenderse, el evaluador 20 de licencia tiene confianza en el sistema 10 de DRM para llevar a cabo los deseos del dueño del contenido 12 digital de acuerdo con las normas y requerimientos en la licencia 16, y el usuario no deberá ser capaz de alterar fácilmente el elemento de confianza para ningún propósito, nefario o de otra manera. Como debe entenderse, las normas y requerimientos en la licencia 16 pueden especificar si el usuario tiene derecho de ejecutar el contenido 12 digital basándose en cualquiera de los diverso factores, incluyendo quién es el usuario, donde se localiza el usuario, qué tipo de dispositivo de cómputo está utilizando el usuario, qué aplicación de ejecución está llamando al sistema de DRM, la fecha, la hora, etc. Además, las normas y requerimientos de la licencia 16 pueden limitar la licencia 16 a un número predeterminado de reproducciones, o tiempo de reproducción predeterminado, por ejemplo. Las normas o requerimientos pueden especificarse en al licencia 16 de acuerdo con cualquier lenguaje y sintaxis apropiado. Por ejemplo el lenguaje puede simplificar los atributos específicos y valores que deben satisfacerse (por ejemplo, la FECHA debe ser posterior a X), o puede requerir el rendimiento de funciones de acuerdo con una escritura especificada (por ejemplo, SI la FECHA es mayor que X, DESPUES HACER...). Con la determinación del evaluador 20 de licencia de que la licencia 16 es válida y que el usuario satisface las normas y requerimientos en la misma, el contenido 12 digital entonces puede ejecutarse. En particular, para ejecutar el contenido 12, la clave de descifrado (KD) se obtiene de la licencia 12 y se aplica a (KD(CONTENIDO)) del paquete 13 de contenido para resultar en el contenido 12 actual, y el contenido 12 actual entonces se ejecuta de hecho.

Publicación de Contenido Digital La Figura 3 es un diagrama de bloque funcional de una modalidad de un sistema y método de acuerdo con la invención para publicar contenido digital. "Publicación", como se utiliza ese término en la presente, se refiere a un proceso que una aplicación o servicio sigue para establecer con una entidad de confianza, un conjunto de derechos y condiciones que la entidad puede emitir para ese contenido, así como a quiénes pueden emitirse esos derechos y condiciones. De acuerdo con la invención, el proceso de comunicación incluye encriptar el contenido digital y asociar una lista de derechos de ejecución persistentes que el autor del contenido pretendido para todos los usuarios posibles del contenido. Este proceso puede llevarse a cabo en una forma segura para prohibir el acceso a cualquiera de los derechos o al contenido a menos que se pretenda por el autor del contenido. En una modalidad de la invención, tres entidades en particular pueden emplearse para publicar contenido digital seguro: una aplicación 302 de preparación de contenido que se ejecuta en el cliente 300 y prepara el contenido para publicación, un administrador digital de derechos (DRM), una interfase 306 de programa de aplicaciones (API) que también reside en el dispositivo 300 de cliente, y un servidor 320 de DRM que se acopla comunicativamente al cliente 300 mediante una red 330 de comunicación. En una modalidad de la invención, la red 330 de comunicación incluye la Internet, aunque debe entenderse que la red 330 de comunicación puede ser cualquier red de área local o extensa, tal como una intranet de propiedad, por ejemplo. La aplicación 302 de preparación de contenido puede ser cualquier aplicación que produzca contenido digital. Por ejemplo, la aplicación 302 puede ser un procesador de palabras u otro publicista que produzca archivos de texto digitales, música digital, video, u otro contenido. El contenido también puede incluir contenido propagado, tal como audio/video propagado de un evento en vivo o grabado, o ejemplo. De acuerdo con la invención, la aplicación de preparación de contenido invita al usuario de la misma a encriptar el contenido utilizando una clave que el usuario proporciona, la aplicación 302 utiliza la clave para encriptar el contenido digital, de este modo formando un archivo 304 de contenido digital encriptado. La aplicación del cliente también invita al usuario a proporcionar datos de derechos para el archivo 304 de contendió digital. Los datos de derechos incluyen una identidad respectiva para cada entidad que tiene derechos en el contenido digital. La entidad puede ser por ejemplo, un individuo, una clase de individuos, o un dispositivo. Para cada entidad, los datos de derechos también incluyen una lista de derechos que la entidad tiene en el contenido, y cualquier condición que puede imponerse en cualquiera o todos esos derechos. Los derechos pueden incluir el derecho de leer, editar, copiar, imprimir, etc., el contenido digital. Adicionalmente, los derechos pueden ser inclusivos o exclusivos. Los derechos inclusivos indican que un usuario específico tiene un derecho específico en el contenido (por ejemplo, el usuario puede editar el contenido digital). Los derechos exclusivos indican que un usuario específico tiene todos los derechos en el contenido excepto aquellos especificados (por ejemplo, el usuario no puede hacer nada con el contenido digital excepto copiarlo). De acuerdo con una modalidad de la invención, la API 306 de cliente puede pasar el contenido digital encriptado y los datos de derechos al servidor 320 de DRM. Utilizando un proceso que se describe en detalle en lo siguiente, el servidor 320 de DRM determina si puede ejecutar los derechos que el usuario ha asignado y, si es así, el servidor 320 de DRM firma los datos de derechos para formar una etiqueta de derechos firmada (SRL) 308. En general, sin embargo, cualquier entidad de confianza puede firmar los datos de derechos, de preferencia utilizando una clave de confianza por el servidor 320 de DRM. Por ejemplo, un cliente puede firmar los datos de derechos utilizando una clave proporcionada al mismo mediante el servidor 320 de DRM. La etiqueta 308 de derechos pueden incluir datos que representan la descripción de los derechos, la clave de contenido encriptada, y la signatura digital sobre la descripción de derechos y la clave de contenido encriptada. Si el servidor de DRM firma la etiqueta de derechos, pasa la etiqueta 308 de derechos firmada nuevamente al cliente a través de la API 306 de cliente, la cual almacena la etiqueta 308 de derechos firmada en el dispositivo 300 de cliente. La aplicación 302 de preparación de contenido entonces asocia la etiqueta 308 de derechos firmada con el archivo 304 de contenido digital encriptado. Por ejemplo, la SRL 308 puede concatenarse con el archivo de contenido digital encriptado para formar un archivo 310 de contenido manejado por los derechos. En general, sin embargo, los datos de derechos no necesitan combinarse con el contenido digital. Por ejemplo, los datos de derechos pueden almacenarse en una ubicación conocida, y una referencia a los datos de derechos almacenados puede combinarse con el contenido digital encriptado. La referencia puede incluir un identif icador que indica dónde se almacenan los datos de derechos (por ejemplo, el almacén de datos que contiene los datos de derecho), y un identif icador que corresponde a estos datos de derechos particulares en esa ubicación de almacenaje particular (por ejemplo, que identifica el archivo que contiene los datos de derechos particulares de interés. El contenido 310 manejado por los derechos entonces puede suministrarse a cualquiera en cualquier lugar, y solamente aquellas entidades que tienen derechos de consumir el contenido pueden consumir el contenido, y solamente de acuerdo con los derechos que se asignaron. La Figura 4 es un diagrama de flujo de un método 400 ejemplar de acuerdo con la invención para publicar contenido digital manejado por derechos, en donde la etiqueta de derechos es firmada por un servidor de DRM. Se debe entender, sin embargo, que esta modalidad solamente es ejemplar, y que la etiqueta de derechos puede firmarse, en general, mediante cualquier entidad de confianza. Generalmente, un método de acuerdo con la invención para publicar contenido digital puede incluir: encriptar el contenido digital utilizando una clave de contenido (CK), generar una descripción de derechos asociada con el contenido digital, encriptar la clave de contenido (CK) de acuerdo con una clave pública para un servidor de DRM (PU-DRM) para resultar en (PU-DR (CK)), y crear una signatura digital basada en una clave privada (PR-DRM) que corresponde a (PU-DRM) sobre la combinación de la descripción de derechos y (PU-DRM(CK)). En la etapa 402, la aplicación 302 genera una clave de contenido (CK) que se utiliza para encriptar el contenido digital. De preferencia, la clave de contenido (CK) es una clave simétrica, aunque, en general, cualquier clave puede utilizarse para encriptar el contenido digital. Los algoritmos de clave simétrica que algunas veces son referidos como algoritmos de "clave secreta", utilizan la misma clave para descifrar un mensaje como lo hacen para encriptar el mensaje. Por esa razón, se prefiere que (CK) pueda mantenerse en secreto. La participación (CK) entre el emisor y el receptor debe hacerse muy cuidadosamente para evitar la intercepción no autorizada de (CK). Debido a que (CK) es compartida entre el encriptador y el descifrador, (CK) se comunica de preferencia antes de que se transmita cualquier mensaje encriptado. Varios algoritmos de generación de clave simétrica se conocen bien en la técnica. En una modalidad, el Estándar de Encriptación de Datos (DES) se emplea, aunque debe entenderse que cualquier algoritmo simétrico puede utilizarse. Ejemplos de algoritmos de claves simétricas incluyen, sin limitación, AES, Triple-DES, el Algoritmo de Encriptación de Datos Internacional (IDEA), Cast, Cast-128, RC4, RC5, y SkipJack. En la etapa 404, la aplicación 302 encripta el contenido digital con la clave de contenido simétrica (CK) para formar el contenido 304 digital encriptado, que puede escribirse utilizando la anotación (CK(contenido)). El autor que utiliza la aplicación 302 también puede generar datos de derechos asociados con el contenido digital. Los datos de derechos pueden incluir una lista de entidades que serán tituladas para consumir el contenido, y los derechos específicos que cada una de las entidades posee con respecto al contenido, junto con cualquier condición que puede imponerse sobre esos derechos. Los derechos pueden incluir por ejemplo, ver el contenido, imprimir el contenido, etc. La aplicación 302 proporciona los datos de derechos a la API 306. Un ejemplo de datos de derechos en el formato XML/XrML se une a los mismos como Apéndice 1. En la etapa 406, la API 306 genera una segunda clave de encriptación (DES1) que se utiliza para encriptar la clave de contenido (CK). Preferiblemente, (DES1) también es una clave simétrica. En la etapa 408, la API 306 encripta (CK) con (DES1) para resultar en (DES1(CK)). En la etapa 410, la API 306 descarta (CK), con el resultado siendo que (CK) puede ahora obtenerse sólo por el descifrado (DES1(CK)). Para asegurar que (CK(contenido)) se proteja en un servidor 320 de DRM central y que todas las "solicitudes de licencia" del contenido se hagan centralmente de acuerdo con los datos de derechos, la API 306, en la etapa 412, hace contacto con el servidor 320 DRM proporcionado y recupera la clave pública del mismo (PU-DRM). En la etapa 414, la API 306 encripta (DES1) con (PU-DRM) para resultar en (PU-DRM(DES )).

De este modo, (CK) puede protegerse en (PU-DRM)) para asegurar que el servidor 320 de DRM es la única entidad que será capaz de tener acceso a (CK), como se requiere para descifrar (CK(contenido)). En la etapa 416, la API 306 encripta los datos de derechos (es decir, la lista de entidades autorizadas y los derechos respectivos y condiciones asociados con cada una de las entidades autorizadas en la lista) con (DES1) para resultar en (DES1(datos de derechos)). En una modalidad alternativa, (CK) puede utilizarse para encriptar directamente ios datos de derechos para resultar en (CK(datos de derechos)), y (PU-DRM) puede utilizarse para encriptar directamente (CK) para resultar en (PU-DRM(CK)), procediendo por consiguiente el uso de (DES1) completamente. Sin embargo, utilizar (DES1) para encriptar los datos de derechos y (CK) permite que (DES1) se conforme a cualquier algoritmo particular que pueda ser fácil para el servidor de DRM, mientras (CK) puede ser específico por una entidad independiente del servidor de DRM y puede ser no tan fácil para el mismo. En la etapa 418, la aplicación 302 de protección de contenido puede exponer (PU-DRM(DES )) y (DES1(datos de derechos)) al servidor 320 de DRM como una etiqueta de derechos para firmar. Alternativamente, el cliente mismo puede firmar los datos de derechos. Si los datos de derechos están siendo presentados al servidor para firmar, entonces, en la etapa 420, el servidor 320 de DRM tiene acceso a los datos de derechos y verifica que pueda ejecutar los derechos y condiciones en la etiqueta de derechos presentada. Para verificar que puede ejecutar los datos de derechos, el servidor 320 de DRM aplica (PR-DRM) a (PU-DRM(DES1 )) para resultar en (DES1), y después aplica (DES 1 ) a (DES1(datos de derechos)) para resultar en los datos de derechos en el espacio en blanco. El servidor 320 entonces puede hacer cualquier verificación de política para verificar que los usuarios, derechos, y condiciones especificadas en los datos de derechos están dentro de cualquier política ejecutada por el servidor 320. El servidor 320 firma la etiqueta de derechos originalmente presentada incluyendo (PU-DRM(DES1 )) y (DES1(datos de derechos)) para resultar en la etiqueta de derechos formada (SRL) 308, donde se basa la signatura en la clave privada del servidor 320 de DRM (PR-DRM), y regresa nuevamente la SRL 308 a la API 306, la cual entonces presenta la SRL 308 regresada a la aplicación 302 de cliente. La SRL 308 es un documento digitalmente firmado, que la hace resistente a manipulación. Adicionalmente, la SRL 308 es independiente del tipo de clave actual y el algoritmo utilizado para encriptar el contenido pero mantiene la relación 1-1 fuerte con el contenido que se protege. Con referencia a la Figura 4A, en una modalidad de la presente invención, la SRL 308 puede incluir información en el contenido que es la base de la SRL 308, incluyendo tal vez una ID del contenido; información sobre el servidor de DRM que firma la SRL 308, incluyendo (PU-DRM(DES 1 )) y la información de referencia tal como una URL para localizar el servidor de DRM en una red y la información del y retroceder si la URL falla; la información que describe la SRL 308 misma; (DES1(datos de derechos)): (DES1(CK)); y S (PR-DRM), entre otras cosas. Una muestra SRL 308 en XML/XrML se une a la misma como el Apéndice 2. Al asegurar que una entidad de confianza firma los datos de derechos para crear una etiqueta 308 de derechos firmada, el servidor de DRM está afirmando que emitirá licencias para el contenido de acuerdo con los términos establecidos por el publicista como se describe en los datos de derechos de la etiqueta 308 de derechos. Como puede apreciarse, un usuario se requiere que obtenga una licencia para ejecutar el contenido, especialmente siempre y cuando la licencia contenga la clave de contenido (CK). Cuando un usuario desea obtener una licencia para el contenido encriptado, el usuario puede presentar una solicitud de licencia incluyendo la SRL 308 para el contenido y un certificado que verifique las credenciales del usuario en el servidor 320 de DRM u otra entidad que emita la licencia. La entidad que emite la licencia entonces puede descifrar (PU-DRM(DES1 )) y (DES1(datos de derechos)) para producir los datos de derechos, listar todos los derechos concedidos por el autor (si los hay) a la entidad que solicita la licencia, y construir una licencia con sólo aquellos derechos específicos. De preferencia, con la aplicación 302 que recibe la SRL 308, la aplicación 302 concatena la etiqueta 308 de derechos firmada con el (CK(contenido)) 304 correspondiente para formar el contenido digital manejado por los derechos. Alternativamente, los datos de derechos pueden almacenarse en una ubicación conocida, con una referencia a esa ubicación proporcionada con el contenido digital encriptado. De este modo, una aplicación de ejecución que es habilitada por DRM puede descubrir la etiqueta 308 de derechos firmada mediante la pieza de contenido de la aplicación de ejecución está intentando ejecutar. Este descubrimiento dispara la aplicación de ejecución para iniciar una solicitud de licencia contra el servidor 320 de concesión de DRM. La aplicación 302 de publicación puede almacenar una URL en el servidor 320 de concesión de DRM, por ejemplo, o el servidor 320 de concesión de DRM puede embeber su propia URL como una pieza de metadatos en la etiqueta de derechos antes de firmarla digitalmente, de manera que la API 306 de cliente de DRM llamada por la aplicación de ejecución puede identificar el servidor 320 de concesión de DRM correcto. Preferiblemente, un identificador único, tal como un identificador globalmente único (GUID), por ejemplo, se ingresa en la etiqueta de derechos antes de que se firme. En una modalidad de la invención, el protocolo de acceso de objeto simple (SOAP) puede utilizarse para la comunicación entre la aplicación 302 de protección de contenido o la aplicación de ejecución y el servidor 320 de DRM. Adicionalmente, las bibliotecas de API, tal como API 306, pueden proporcionarse de manera que las aplicaciones tal como la aplicación 302 no se requieren para implementar el lado del cliente del protocolo de DRM, pero más bien pueda solo hacer llamadas de API locales. Preferiblemente, XrML, un lenguaje de XML, se utiliza para describir las descripciones de derechos, licencias, y etiquetas de derechos para contenido digital, aunque debe entenderse que cualquier formato adecuado puede ser usos para ia descripción de derechos y otro datos.

Obtención de una Licencia para el Contenido Publicado La Figura 5 es un diagrama de bloque funcional de una modalidad de un sistema y método de acuerdo con la invención para conceder contenido digital manejado por derechos. La "concesión", como el término que se utiliza en la presente se refiere a un proceso que una aplicación o servicio sigue para solicitar y recibir una licencia que habilitará una entidad nombrada en la licencia para consumir el contenido de acuerdo con los términos especificados en la licencia. Las entradas al proceso de concesión puede incluir la etiqueta de derechos firmada (SRL) 308 asociado con el contenido por el cual está siendo requerida la licencia, y el certificado o certificados de clave pública de la entidad o entidades por las cuales está siendo solicitada la licencia. Nótese que la entidad que solicita una licencia no necesita ser necesariamente la entidad para la cual está siendo requerida la licencia. Típicamente, una licencia incluye la descripción de derechos de la SRL 308 y la clave encriptada que puede descifrar el contenido encriptado y una signatura digital sobre la descripción de derechos y la clave encriptada. La signatura digital afirma que las entidades y derechos nombrados son legítimos. Una forma para la aplicación 302 para consumir el contenido 310 manejado por derechos es para la API 306 de cliente para enviar la etiquete 308 de derechos firmada del contenido 310 manejado por los derechos al servidor 320 de DRM mediante la red 330 de comunicación. La ubicación del servidor 320 de DRM puede encontrarse, por ejemplo, en la información de referencia en la SRL 308. En la modalidad, el servidor 320 de concesión de DRM, mediante un proceso que se describe en detalle en lo siguiente, puede utilizar la descripción de derechos en la etiqueta de derechos para determinar si puede expedir una licencia y, si es así, para derivar la descripción de derechos para incluirse con la licencia. Como se describe en lo anterior, la etiqueta 308 de derechos contiene la clave de contenido (CK) encriptada de acuerdo con la clave pública del servidor 320 de DRM (PU-DRM) (es decir, (PU-DRM(CK))). En el proceso para emitir una licencia, el servidor 320 de DRM descifra en forma segura este valor para obtener (CK). Entonces, utiliza la clave pública (PU-ENTIDAD) en el certificado de clave pública que se pasa en la solicitud de licencia para reencriptar (CK) (es decir, (PU-ENTIDAD(CK))). La (PU-ENTIDAD(CK)) recién encriptada es lo que el servidor 320 coloca en la licencia. De este modo, la licencia puede regresarse al llamador sin riesgo de exponer (CK), puesto que sólo el portador de la clave privada asociada (PR-ENTIDAD) puede recuperar (CK) de (PU-ENTIDAD(CK)). La API 306 de cliente entonces utiliza (CK) para descifrar el contenido encriptado para formar el contenido 312 digital descifrado. La aplicación 302 de cliente entonces puede utilizar el contenido 312 digital descifrado de acuerdo con los derechos que se proporcionan en la licencia. Alternativamente, un cliente, tal como el cliente de publicidad, por ejemplo, puede emitir su propia licencia para consumir el contenido. En tal modalidad, un proceso seguro puede ser ejecutar en la computadora de cliente que proporciona el cliente con la clave o claves necesarias para descifrar el contenido digital bajo circunstancias apropiadas. Las Figuras 6A y 6B proporcionan un diagrama de flujo de una modalidad de un método 600 de acuerdo con la invención para conceder el contenido digital manejado por derechos. De acuerdo con la invención, una entidad solicitante puede presentar una solicitud de licencia a nombre de uno o más de concesionarios potenciales. La entidad solicitante puede o no puede ser uno de los concesionarios potenciales. Un concesionario potencial puede ser una persona, un grupo, un dispositivo, o cualquier otra entidad que pueda consumir el contenido en alguna forma. El método 600 ahora se describirá con referencia a una modalidad en donde un servidor de DRM procesa la solicitud de licencia, aunque debe entenderse que un procedimiento de la solicitud de licencia también puede realizarse sobre, y las licencias emitidas directamente por, el cliente. En la etapa 602, una entidad emisora de licencia, tal como un servidor de DRM, por ejemplo, recibe una solicitud de licencia. Preferiblemente, una solicitud de licencia incluye un certificado de clave pública o una identidad para cada uno o más de los cesionarios solicitados. En la etapa 604, la entidad solicitante (es decir, la entidad que hace la solicitud de licencia) se autentica. De acuerdo con una modalidad de la invención, la entidad emisora de licencia puede configurarse para utilizar el protocolo (por ejemplo, reto-respuesta) autentif icación para determinar la identidad de la entidad solicitante, o puede configurarse para no requerir autentificación de la entidad solicitante (también conocido como "permitir autenticación anónima"). Donde se requiere la autentificación, cualquier tipo de esquema de autentificación puede utilizarse (por ejemplo, el esquema de reto-respuesta antes mencionado, un esquema de ID y contraseña de usuario, tal como MICROSOFT.NET, PASSAPORT, autorización de WINDOWS, x509, etc.). Preferiblemente, se permite la autentificación anónima, así como soportar cualquier esquema de autentificación de protocolo soportado por los sistemas de información integrados. El resultado de la etapa de autentificación será una identidad, tal como una identidad "anónima" (para la autentificación anónima), o una identidad de cuenta personal, por ejemplo. Si el solicitante de licencia no puede ser autentificado por ninguna razón, se regresa un error y no se concede ninguna licencia. En la etapa 606, la entidad autenticada es autorizada - es decir, se determina si la entidad autentificada en la etapa 608 se permite solicitar una licencia (ya sea por sí misma o a nombre de otra entidad). Preferiblemente, la entidad que emite la licencia almacena una lista de entidades que son permitidas (o no permitidas) para solicitar una licencia. En una modalidad, una identidad en esta lista de identidades es la identidad de la entidad que hace la solicitud, en lugar de la identidad de la entidad para quien se requiere la licencia, aunque puede ser cualquiera. Por ejemplo, una identidad de cuenta personal no puede permitirse hacer directamente una solicitud de licencia, pero un proceso de servidor de confianza puede hacer una solicitud de licencia a nombre de tal entidad. De acuerdo con la invención, la solicitud de licencia puede incluir ya sea un certificado de clave pública o una identidad para cada concesionario potencial. Si se solicita una licencia para sólo un concesionario, solamente un certificado o identidad se nombra. Si se requiere una licencia para una pluralidad de cesionarios, un certificado o una identidad puede nombrarse para cada concesionario potencial. Preferiblemente, la entidad que emite la licencia tiene un certificado de clave pública para cada concesionario válido. Sin embargo, una aplicación 302 puede necesitar generar una licencia para un usuario dado, pero la aplicación 302 puede no tener acceso al certificado de clave pública para ese usuario. En tal situación, la aplicación 302 puede especificar la identidad del usuario en la solicitud de licencia y, como resultado, la entidad de emisión de licencia puede invocar un módulo de enchufe de certificado registrado que realiza una consulta en un servicio de directorio y regresa el certificado de clave pública de usuario apropiado. Si, en la etapa 608, la entidad de emisión determina que el certificado de clave pública no se incluye en la solicitud de licencia, entonces, la entidad de emisión utiliza la identidad específica para realizar una consulta en un servicio de directorio o base de datos para el certificado de clave pública apropiado. Si, en la etapa 610, la entidad de emisión determina que el certificado está en el directorio, entonces, en la etapa 612, se recupera el certificado. En una modalidad, un módulo de ampliación de certificado se utiliza para recuperar los certificados de clave pública de un servicio de directorio por medio de un protocolo de acceso de directorio. Si un certificado no puede encontrarse para un concesionario potencial dado, ya sea en el solicitante o en el directorio, entonces el servidor de licencia no genera una licencia para ese concesionario potencial, y, en la etapa 614, se regresa un error a la entidad solicitante. Asumiendo la entidad de emisión de licencia que tiene un certificado de clave pública para por lo menos un concesionario potencial, entonces en la etapa 616, la entidad de emisión valida la confianza de los certificados de licencia. Preferiblemente, la entidad de emisión se configura con un conjunto de certificados de usuarios certificados de confianza, y se determina si el usuario de certificado de licencias está en la lista de emisores de confianza. Si, en la etapa 616, la entidad de emisión determina que el usuario del certificado de licencias no está en la lista de emisores de confianza, entonces la solicitud falla para esa licencia, y se genera un error en la etapa 614. De este modo, cualquier concesionario potencial cuyo certificado no sea expedido por un emisor de confianza no puede recibir una licencia. Adicionalmente, la entidad de emisión de preferencia realiza la validación de signatura digital en todas las entidades en la cadena de certificación que va desde los certificados del emisor de confianza hasta los certificados de clave pública de concesionario individual. El proceso para validar las signaturas digitales en una cadena es un algoritmo bien conocido. Si el certificado de clave pública para un concesionario potencial dado no es válido, o un certificado en la cadena no es válido, el concesionario potencial no es de confianza, y una licencia, por lo tanto, no es expedida a ese concesionario potencial. De otra manera, en la etapa 618, una licencia puede expedirse. El proceso se repite en la etapa 620 hasta que todas las entidades para las cuales una licencia se ha requerido, se han procesado. Como se muestra en la Figura 6B, la entidad que emite la licencia procede a validar la etiqueta 308 de derechos firmada que es recibida en la solicitud de licencia. En una modalidad, la entidad de emisión puede utilizar un módulo de ampliación de etiqueta de derechos, y una base de datos principal para almacenar en el servidor una copia maestra de cada etiqueta de derechos formada por la entidad de emisión. Las etiquetas de derechos son identificadas por el GUID colocado en las mismas en publicación. Al momento de la licencia (en la etapa 622), la entidad de emisión analiza la entrada de etiqueta de derechos en la solicitud de licencia y recupera su GUID. Entonces, pasa este GUID al módulo de ampliación de etiqueta de derechos, que emite una pregunta contra la base de datos para recuperar una copia de la etiqueta de derechos maestra. La etiqueta de derechos maestra puede ser más hasta la fecha que la copia de la etiqueta de derechos enviada en la solicitud de licencia, y será la etiqueta de derechos utilizada en la solicitud en las etapas siguientes. Si ninguna etiqueta de derechos se encuentra en la base de datos basándose en el GUID, la entidad de emisión verifica su política, en la etapa 624, para determinar si aún se permite expedir una licencia b.asándose en la etiqueta de derechos en la solicitud. Si la política no permite esto, la solicitud de licencia fallará en la etapa 626, y un error se regresará a la API 306 en la etapa 628. En la etapa 630, la entidad de emisión de licencia valida la etiqueta 308 de derechos. La signatura digital sobre la etiqueta de derechos es validada y, si la entidad de emisión de licencia no es el emisor de la etiqueta de derechos (la entidad que la firma), entonces la entidad de emisión de licencia determina si el emisor de la etiqueta de derechos es otra entidad de confianza (por ejemplo, una entidad con la cual la entidad de emisión de licencia es habilitada para compartir el material clave). Si la etiqueta de derechos no es válida, o no es emitida por una entidad de confianza, entonces la solicitud de licencia falla en la etapa 626, y un error se regresará a la API 306 en la etapa 628. Después de que han ocurrido todas las validaciones, la entidad que expide la licencia traduce la etiqueta 308 de derechos en una licencia para cada uno de los concesionarios aprobados. En la etapa 632, la entidad de emisión de licencia genera una descripción de derechos respectiva para la licencia que va a expedirse a cada concesionario. Para cada concesionario, la entidad de emisión evalúa la identidad nombrada en el certificado de clave pública de ese concesionario contra las identidades nombradas en la descripción de derechos en la etiqueta de derechos. La descripción de derechos asigna a cada derecho o un conjunto de derechos, un conjunto de identidades que pueden ejercer ese derecho o conjunto de derechos en una licencia. Para cada derecho o conjunto de derechos a los cuales se asocia esta identidad del concesionario, ese derecho o conjunto de derechos es copiado en una nueva estructura de datos para la licencia. La estructura de datos resultante es la descripción de derechos en la licencia para el concesionario particular. Como parte de este proceso, la entidad de emisión de licencia evalúa cualquier precondición que pueda asociarse con cualquiera de los derechos o conjuntos de derechos en la descripción de derechos de la etiqueta de derechos. Por ejemplo, un derecho puede tener una precondición de tiempo asociada con éste que limite la entidad de emisión de licencia de expedir una licencia después de un tiempo específico. En este caso, la entidad de emisión puede necesitar verificar el tiempo actual, y si se pasa el tiempo específico en la precondición, entonces la entidad de emisión no puede ser capaz de emitir ese derecho al concesionario aún si la identidad del concesionario se asociara con ese derecho. En la etapa 636, la entidad de emisión toma (PU-DRM(DES1 )) y (D ES 1 (CK)) de la etiqueta 308 de derechos y aplica (PR-DR ) para obtener (CK). La entidad de emisión entonces re-encripta (CK) utilizando (PU-ENTIDAD) el certificado de clave pública del concesionario para resultar en (PU-ENTIDAD(CK)). En la etapa 638, la entidad de emisión concatena la descripción de derechos generada con (PU-ENTIDAD(CK)) y firma digitalmente la estructura de datos resultantes utilizando (PR-DRM). Esta estructura de datos firmada es la licencia para este concesionario particular. Cuando, en la etapa 640, la entidad de emisión determina que no existen más licencias para generar para la solicitud particular, habrá generado cero o más licencias. Las licencias generadas se regresan a la entidad solicitante, en la etapa 642, junto con la cadena de certificados asociada con esas licencias (por ejemplo, el certificado de clave pública, propio del servidor así como el certificado que expidió su certificado, etc.).

En una modalidad de un sistema de acuerdo con la invención, una pluralidad de claves del concedente pueden utilizarse. En tal modalidad, la clave de contenido (CK) que va encriptada a través de la etiqueta 308 de derechos y dentro de la licencia puede realmente ser cualesquiera datos arbitrarios. Una variación útil particular es utilizar una pluralidad de claves de contenido, separadas, encriptadas, (CK) asociadas, respectivamente, con diferentes derechos o diferentes capitales en la descripción de derechos. Por ejemplo, la versión digital de canciones en un álbum puede encriptarse toda con diferentes claves (CK). Estas claves (CK) pueden incluirse en la misma etiqueta de derechos, pero una principal puede tener el derecho de reproducir una de las canciones (por ejemplo, solamente puede tener derechos para conseguir una clave en su licencia), mientras un segundo principal puede tener derechos para reproducir todas las canciones (puede tener derechos para conseguir todas las claves en su licencia). Preferiblemente, un sistema de acuerdo con la invención permite que las aplicaciones de publicidad/usuarios nombren grupos o clases de concesionarios en una etiqueta 308 de derechos. En una modalidad, la entidad de emisión de licencia evaluará cualquier grupo/clase nombrada en la etiqueta de derechos para determinar si la identidad de concesionario actual es un miembro de esas clases de grupos. Si !a membresía en un grupo nombrado/clases se encuentra, la entidad de emisión puede agregar los derechos o conjunto de derechos asociados con el grupo/clase a la estructura de datos de descripción de derechos utilizada para la licencia. En una modalidad de la invención, las interfaces de publicidad y protocolo de licencia en el servidor de DRM soportan la autentif icación y autorización de la aplicación llamante o usuario, y la consola administrativa para el servidor de DRM permite que un administrador genere una lista de control de acceso para las interfaces de licencia y publicidad. Esto permite que el cliente del servidor aplique la política sobre la cual se permite que usuarios/aplicaciones publiquen, concedan, o ambos.

Modificación o Republicación de la Etiqueta 308 de Derechos Firmada En una modalidad de la presente invención, la SRL 308 puede "republicarse" si el usuario del contenido se le ha concedido suficiente permiso para hacerlo así. Es decir, si se le permite, el usuario puede alterar los datos de derechos dentro de la SRL 308. Notablemente, el permiso para alterar los datos de derechos debe concederse económicamente y en forma juiciosa, especialmente ya que un usuario con permiso para alterar los datos de derechos puede conceder esencialmente así mismo los amplios derechos con respecto al contenido asociado. Concebiblemente, el usuario puede aún concederse a sí mismo el derecho de exponer el contenido y enviarlo al mundo. Aquí, el permiso para alterar es indicado al incluir dentro de los datos de derechos en la SRL 308 una indicación de que un usuario particular o clase de usuarios puede de hecho alterar o 'republicar' los datos de derechos y la etiqueta 308 de derechos. Cuando el servidor 320 de DRM recibe una SRL 308 con el permiso junto con una solicitud de una licencia, el servidor 320 de DRM incluye dentro de la licencia requerida por el usuario la clave simétrica (DES1) encriptada de acuerdo con la clave pública del usuario (es decir, PU-ENTIDAD) para resultar en (PU-ENTIDAD(DES1 )). De este modo, para editar los datos de derechos dentro de la SRL 308, y regresando ahora a la Figura 7, el usuario recupera (PU-ENTI DAD(DES 1 )) de la licencia (etapa 701), aplica (PR-ENTIDAD) ai mismo para resultar en (DES1) (etapa 703), recupera (DES1 (datos de derechos)) de la SRL 308 (etapa 705), y aplica (DES1) al mismo para resultar en los datos de derechos (etapa 707). Después de esto, el usuario altera los datos de derechos como se desee (etapa 709), y presenta los datos de derechos alterados al servidor 320 de DRM en la forma establecida junto con la FIGURA 4 para obtener una etiqueta 308 de derechos firmada (etapa 711). Desde luego, aquí, la etiqueta 308 de derechos firmada realmente es una SRL 308 republicada, y por consiguiente una vez que la SRL 308 se recibe (etapa 713), el usuario descompone la SRL 308 original concatenada en el contenido asociado (etapa 715) y después concatena la SRL 308 republicada en tal contenido (etapa 717). De este modo, y como puede apreciarse, la republicación de una SRL 308 permite que un usuario actualice los datos de derechos en la SRL 308, incluyendo los derechos, condiciones, y usuarios, sin tener que alterar el contenido asociado. En particular, la republicación no requiere re-encriptar el contenido asociado con una nueva (CK). También, la republicación no requiere generar una nueva SRL de lo que queda, especialmente ya que la SRL 308 original tiene muchos puntos en la misma que pueden copiarse en la nueva SRL 308.

Auto-Publicación de la Etiqueta 308 de Derechos Firmada En una modalidad de la presente invención, la SRL 308 puede firmarse por el usuario solicitante mismo. Por consiguiente el usuario no necesita hacer contacto con el servidor 320 de DRM para obtener una SRL 308 para una pieza asociada de contenido. Como resultado, la auto-publicación también puede referirse como publicación fuera de línea. En tal modalidad, se le puede requerir a un usuario que haga contacto con un servidor 320 de DRM para solicitar una licencia basándose en una SRL 308 auto-publicada. También se debe entender que una entidad de publicación puede permitirse expedir sus propias licencias. En particular, y con referencia a la Figura 8, en la modalidad, un usuario primero se provee para auto-publicar mediante la recepción de un servidor 320 de DRM un certificado 810 de DRM incluyendo una clave pública (PU-CERT) y una clave privada correspondiente (PR-CERT) encriptada de acuerdo con la clave pública del usuario (PU-ENTI DAD) para resultar en (PU- E TIDAD(PR-CERT)). El certificado debe firmarse por la clave privada del servidor 320 de DRM (PR-DRM) de manera que el servidor 320 de DRM pueda verificarla, como se discutirá en mayor detalle en lo siguiente. Como puede apreciarse, el certificado 810 de DRM autoriza al usuario a auto-publicar. Como también puede apreciarse, el par de claves (PU-CERT, PR-CERT) se separan de (PU-ENTIDAD, PR-ENTIDAD), y se emplean especialmente para auto-publicidad. Nótese que el par de claves (PU-CERT, PR-CERT) pueden dispersarse con, en cuyo caso el certificado 810 de DRM incluye solamente la clave pública del usuario (PU-ENTIDAD) y se firma por la clave privada del servidor 320 de DRM (PR-DRM) de manera que el servidor 320 de DRM puede verificarla. La auto-publicación difiere de la publicación como se muestra en la FIGURA 4 en el cual el usuario esencialmente toma el lugar del servidor 320 de DRM con respecto a las etapas realizadas por consiguiente. Significativamente, el usuario firma la etiqueta de derechos presentada incluyendo (PU-DRM(DES 1 )) y (DES1(datos de derechos)) con (PR-CERT) como obtenida del certificado 810 de DRM (es decir, S(PR-CERT)) para resultar en la etiqueta 308 de derechos firmada (SRL). Como debe apreciarse, ei usuario obtiene (PR-CERT) del certificado 810 de DRM al obtener (PU-ENTIDAD(PR-CERT)) del certificado 810 de DRM y al aplicar el mismo (PR-ENTIDAD). Nótese que, sin embargo, aunque el usuario no puede verificar que el servidor 320 de DRM puede ejecutar los derechos en la etiqueta de derechos presentada, especialmente ya que el usuario no tiene que aplicar (PR-DRM) a (PU-DRM(DES1 )). Por consiguiente, el servidor 320 de DRM por sí mismo debe realizar la verificación al momento de que se solicita una licencia basándose en la SRL 308 auto-publicada. Una vez que el usuario auto-publica la SRL 308, el usuario concatena la SRL 308 auto-publicada y el certificado 810 de DRM empleado para producir la misma en el contenido, y el contenido con SRL 308 y el certificado 810 de DRM se distribuyen a otro usuario. Después de esto, el otro usuario solicita y obtiene una licencia para el contenido del servidor 320 de DRM en sustancialmente la misma forma como se muestra en las FIGURAS 6A y 6B. Aquí, aunque el usuario que solicita la licencia presenta al servidor 320 de DRM la SRL 308 auto-publicada y el certificado 810 de DRM como concatenado en el contenido. El servidor 320 de DRM entonces verifica S (PR-DRM) en el certificado 810 de DRM basándose en (PU-DRM) correspondiente, y obtiene (PU-CERT) del certificado 810 de DRM. El servidor 320 de DRM entonces verifica S (PR-CERT) en la SRL 308 basada en el (PU-CERT) obtenido, y continúa como en lo anterior. Nótese que, puesto que el usuario no verificó que el servidor 320 de DRM puede ejecutar los derechos en la SRL 308, y como se estableció en lo anterior, el servidor 320 de DRM por sí mismo debe realizar la verificación en este momento.

Plantilla de Derechos Como se establece en lo anterior, un usuario sé proporciona con la libertad de crear en su mayor parte cualquier variedad o clase de datos de derechos en una etiqueta de d.erechos ai definir usuarios o clases de usuarios, define derechos para cada usuario definido o ciase de usuarios, y después definir cualquier condiciones de uso., Sin embargo, y significativamente, puede ser embarazoso y repetitivo definir repetidamente los datos de derechos para múltiples etiquetas de derechos, especialmente cuando los mismos usuarios o clases de usuarios derechos y condiciones se definen repetidamente para diferentes piezas de contenido. Tal situación puede ocurrir por ejemplo en un ambiente corporativo o de oficinas, donde un usuario está publicando repetidamente diferentes piezas de contenido que van a compartirse con un equipo particular definido de usuarios. En tal situación, entonces, y en una modalidad de la presente invención, una plantilla de derechos se crea para que el usuario pueda emplear repetidamente junto con crear etiquetas de derechos, donde la etiqueta de derechos ya incluye en la misma un conjunto predefinido de usuarios o clases de usuarios, derechos predefinidos para cada usuario definido o clases de usuario y condiciones de uso predefinidas. En una modalidad de la presente invención, y regresando ahora a la Figura 9, una plantilla 900 de derechos tiene sustancialmente los mismos datos de derechos como puede ser en una etiqueta de derechos, sin embargo, puesto que (DES1) no se conoce hasta que se publique el contenido, los datos de derechos no pueden encriptarse con (DES1), como es el caso en una etiqueta de derechos. En una modalidad de la presente invención, entonces, la plantilla 900 de derechos con los datos de derechos no encriptados se presenta en el transcurso de la encriptación de los datos de derechos con (DES1) en la etapa 416 de la Figura 4 para producir (DES1(datos de derechos)). Desde luego, los datos de derechos se recuperan de la plantilla 900 de derechos presentada antes de que se encripten así. Puede o no puede ser el caso de que el servidor 320 de DRM y la clave pública (PU-DRM) del mismo se conozcan al momento de que se construye la plantilla de derechos. Además, aún si se conoce, puede o no ser el caso de que existan más de uno de los servidores 320 de DRM, cada uno teniendo su propio (PU-DRM). No obstante, en el caso dónde el servidor 320 de DRM y la clave pública (PU-DRM) del mismo se conocen al momento de que se construye la plantilla de derechos y en el caso donde solamente un servidor 320 de DRN se emplea, o sólo un servidor 320 de DRM va a emplearse con la plantilla 900 de derechos, la plantilla de derechos también puede incluir en la misma información sobre el servidor de DRM que es para firmar una etiqueta de derechos que resulta de la plantilla 900 de derechos, incluyendo la clave pública (PU-DRM) de la misma. Aunque (PU-DRM) aparece en la SRL 308 como encriptado (DES1) para resultar en (PU-DRM(DES1 )), nuevamente se apreciará que (DES1) no se conoce hasta que se publica el contenido, y por lo tanto (PU-DRM) en la plantilla 900 de derechos no puede encriptar (DES1), como es el caso en una etiqueta de derechos. En una modalidad de la presente invención, entonces, la plantilla 900 de derechos con la (PU-DRM) no encriptada se presenta en el transcurso de la encriptacion (DES1) con (PU-DRM) en la etapa 414 de la FIGURA 4 para producir (PU-DRM(DES1 )). Desde luego, (PU-DRM) se recupera de la plantilla 900 de derechos antes de que se emplee. También en el caso antes mencionado, otra información sobre le servidor de DRM que puede incluirse en la plantilla de derechos también puede incluir la información de referencia tal como una URL para localizar el servidor de DRM en una red, e información de socorro si la URL falla. En cualquier caso, la plantilla de derechos también puede incluir información que describe la plantilla 900 de derechos misma, entre otras cosas. Nótese que la plantilla 900 de derechos también puede proporcionar espacio para información relevante al contenido que va a publicarse, tal como la información que aparece en una etiqueta de derechos relevante al contenido y/o las claves (CK) y (DES1), aunque el espacio no es necesario si un instante de la plantilla de derechos no se transforma realmente en una etiqueta de derechos. Aunque la plantilla 900 de derechos como se describe hasta ahora de este modo principalmente es para conveniencia de un usuario, también se apreciará y en algunas circunstancias, un usuario no debe tener libertad restringida para definir los datos de derechos en una etiqueta de derechos, y una plantilla 900 de derechos puede utilizarse para limitar el alcance o tipo de etiquetas de derechos que puede crearse. Por ejemplo, y especialmente en el caso de un ambiente corporativo de oficinas, puede pre-definirse como política que un usuario particular debe publicar siempre el contenido en una clase particular de usuarios solamente, o que el usuario no deba publicar jamás el contenido en una clase particular de usuario. En cualquier caso, y en una modalidad de la presente invención, la política se representa como datos de derechos predefinidos en una o más plantillas 900 de derechos, y el usuario puede restringirse, ampliar las plantillas de derechos para crear etiquetas de derechos cuando se publica el contenido. Notablemente, una plantilla 900 de derechos o un grupo de plantillas 900 de derechos hecha disponible para un usuario para especificar la política de publicación para que el usuario pueda especificar cualquier tipo particular de política de publicidad sin apartarse del espíritu y alcance de la presente invención. Para especificar una plantilla 900 de derechos para un usuario restringido o similar, y regresando ahora a la Figura 10, un administrador o similar de hecho construye la plantilla 900 de derechos al definir los datos de derechos predefinidos (etapa 1001), y definiendo cualquier otro dato que pueda ser necesario y apropiado, tal como la información relevante a un servidor 320 de DRM particular (etapa 1003). Significativamente, para efectuar la plantilla de derechos para su uso por el usuario restringido o similar, la plantilla 900 de derechos debe hacerse oficial. Es decir, la plantilla 900 de derechos debe poderse reconocer como una plantilla de derechos que el usuario restringido o similar puede emplear. Por consiguiente, en una modalidad de la presente invención, la plantilla de derechos como se construye por el administrador similar se presenta al servidor 320 de DRM para firmar por consiguiente, donde la firma hace oficial la plantilla de derechos (etapa 1005). Nótese que el servidor 320 de DRM de firma es el servidor 320 de DRM cuya información está en la plantilla 900 de derechos, si de hecho la información está presente en la plantilla 900 de derechos. Nótese, también, que el servidor 320 de DRM puede firmar la plantilla 900 de derechos sólo al hacer cualquier verificación necesaria, o puede firmar sin ninguna verificación en absoluto. Nótese, finalmente, que la signatura de plantilla S (PR-DRM-T) (donde la T significa que la signatura es para la ORT900) del servidor 320 de DRM debe basarse por lo menos en los datos de derechos pre-definidos en la plantilla 900 de derechos, también debe basarse en otra información sin apartarse del espíritu y alcance de la presente invención. Como se establece en lo siguiente, la signatura S (PR-DRM-T) se incorporará en una etiqueta de derechos y se verificará junto con la misma, y por consiguiente siempre que la signatura se base, también debe incorporarse en la etiqueta de derechos en una forma no alterada. Con el servidor 320 de DRM firmando la plantilla 900 de derechos y regresando lo mismo al administrador o similar, el administrador recibe la plantilla 900 de derechos firmada y ahora oficial con S (PR-DRM-T) (etapa 1007) y envía la plantilla 900 de derechos oficial (ORT) a uno o más usuarios para su uso por consiguiente (etapa 1009). Por consiguiente, para que un usuario publique el contenido basándose en una ORT 900, el usuario recupera la ORT900 (etapa 1011), y construye una etiqueta de derechos basándose en la ORT900 (etapa 1013) al proporcionar cualquier información necesaria, tal como la información sobre el contenido, información de clave apropiada, los datos de derechos de la ORT 900 encriptada por (DES1) para resultar en (DES1 (datos de derechos)), y cualquier otra información de la ORT900. Significativamente, el usuario también incluye con la etiqueta de derechos la signatura S (PR-DRM-T) de la ORT900. Después de esto, y como antes, el usuario presenta la etiqueta de derechos al servidor 320 de DRM para firmarse (etapa 1015). Aquí, aunque, el servidor 320 de DRM no firmara la etiqueta de derechos presentada a menos que S (PR-DRM-T) se verifique en la misma. Es decir, el servidor 320 de DRM ejecuta que el usuario debe basar la etiqueta de derechos presentada en una ORT900 al no querer firmar la etiqueta de derechos presentada a menos que la etiqueta de derechos presentada incluya una signatura S (PR-DRM-T) de una ORT900. En particular, el servidor 320 de DRM recupera la S (PR-DRM-T) y cualquier información tal como la signatura se basa en la etiqueta de derechos presentada y después verifica la signatura basada en (PU-DRM). Nótese que los datos de derechos en la etiqueta de derechos presentada se encripta (DES1) (es decir, (DES1 (datos de derechos)). De acuerdo con el servidor 320 de DRM debe primero obtener (DES1) y descifra (DES1 (datos de derechos)) con el mismo, como se establece en lo anterior junto con la Figura 7, para poder ser capaz de verificar la signatura basada en los datos de derechos en la etiqueta de derechos presentada. Una vez que se verifica, el servidor 320 de DRM firma la etiqueta de derechos presentada con S (PR-DRM-L) para producir una SRL 308, como en lo anterior (donde la L significa que la signatura es para la SRL 308). Aquí, S (PR-DRM-L) puede reemplazar S (PR-DRM-T), o puede ser además de S (PR-DRM-T). Si además, S (PR-DRM-L) puede basarse en parte en S (PR-DRM-T). Nótese que (PR-DRM) puede emplearse para producir S (PR-DRM-T) y S (PR-DRM-L), o que diferentes (PR-DRM) pueden emplearse para cada uno de S (PR-DRM-T) y S (PR-DRM-L). Con el servidor 320 de DRM firmando la etiqueta de derechos y regresando la SRL 308 al usuario, el usuario recibe la SRL 308 con S (PR-DRM-L) (etapa 1017) y procede a concatenar la misma en el contenido que se publica como en lo anterior. Si la signatura S (PR-DRM-T) de la ORT 900 se basa por lo menos en parte a los datos de derechos pre-definidos en la ORT 900, entonces los datos de derechos como aparece en la SRL 308 (en DES 1 (datos de derechos)) no puede modificarse o variarse. De otra manera, S (PR-DRM-T) no se verificará. No obstante, en una modalidad de la presente invención, los datos de derechos en la ORT 900 pueden variar dentro de las normas prescritas que también se incluyen con la ORT 900. Por ejemplo, las normas pueden especificar uno de dos conjuntos de datos de derechos para incluirse en una SRL 308, o puede permitir una selección de entre un conjunto de alternativas. Como puede apreciarse, las normas pueden ser cualquier conjunto de normas particular establecido en cualquier sintaxis apropiada sin apartarse del espíritu y alcance de la presente invención. Aquí, las normas se interpretan por un intérprete de normas apropiadas para el usuario al momento de que se crea la etiqueta de derechos. Aunque los datos de derechos pueden variar, las normas no varía de igual manera, y por consiguiente la signatura de plantilla S (PR-DRM-T) para la ORT 900 se basa por lo menos en parte en las normas y no en los datos de derechos mismos. Como resultado, las normas incluidas con la ORT 900 también deben incluirse con la SRL 308. En una modalidad de la presente invención, los datos de derechos pre-definidos en la ORT 900 se fijan y son invariables en parte y son variables en normas en parte, como se establece en lo anterior. Aquí, la signatura de plantilla S (PR-DRM-T) para la ORT 900 se basa por lo menos en parte en la parte fija de las normas y en las normas para la parte variable de los datos de derechos. Como puede apreciarse, una ORT 900 poseído por un usuario puede fecharse o caducarse. Es decir, la ORT 900 a través de los datos de derechos en la misma puede reflejar la política que se ha quedado fuera de fecha y relevante, simplemente ya no aplica más. Por ejemplo, uno o más usuarios o clases de usuarios especificados en los datos de derechos de la ORT 900 ya no pueden existir dentro del ambiente de política, o un usuario particular o clases de usuarios específicos en los datos de derechos de la ORT 900 ya no pueden tener los mismos derechos dentro del ambiente de política. En tal caso, puede ser que el administrador haya expedido una ORT 900 revisada pero que el usuario aún está utilizando una versión previa, antigua de la ORT 900. En tal situación, entonces, y en una modalidad de la presente invención, el servidor 320 de DRM con la firmas de una plantilla 900 de derechos presentada para crear una ORT 900 retiene una copia de la ORT 900, cada ORT 900 tiene un indicio de identificación único, y cada etiqueta de derechos construida basado en una ORT 900 incluye el indicio de identificación de la ORT 900 en la misma. Por consiguiente, con la recepción de una etiqueta de derechos presentada tal como junto con la Figura 10, el servidor 320 de DRM encuentra el indicio de identificación de la ORT 900 en la etiqueta de derechos, recupera la copia que está más a la fecha de la ORT 900 basándose en el indicio de identificación encontrado, remueve los datos de derechos de la etiqueta de derechos presentada, e inserta los datos de derechos de la ORT 900 recuperada, y después firma la etiqueta de derechos basándose por lo menos en parte en los datos de derechos insertados. Desde luego, el servidor de DRM también realiza cualquier etapa de encriptación y descifrado necesaria y titular en el proceso establecido, que incluye descifrar y re-encriptar (DES1 (datos de derechos)). Nótese que si el servidor de DRM se adapta para reemplazar los datos de derechos en una etiqueta de derechos presentada, la etiqueta de derechos y la ORT 900 de la cual la etiqueta de derechos se construye no necesariamente, incluye los datos de derechos en la misma. De hecho, los datos de derechos sólo necesitan ser residentes en el servidor 320 de DRM. Sin embargo, incluyendo los datos de derechos con la etiqueta de derechos y la ORT 900 de la cual la etiqueta de derechos se construye, puede ser útil para el usuario y por lo tanto puede ser útil en algunas situaciones.

Concesión Por Medio de un Directorio Cuado se expide una licencia para contenido protegido, la entidad de emisión de licencia (de aquí en adelante 'concedente') consulta la SRL 308 enviada desde el contenido para determinar cuáles usuarios/grupos/cúmulos/divisiones/plataformas/etc. (de aquí en adelante 'entidades') se proporcionarán con derechos, y el certificado enviado para identificar el solicitante de licencia. Basándose en lo mismo, el concedente determina cuáles derechos de aquellos listados en la SRL 308 van a expedirse al solicitante, Conceptualmente, el concedente inspecciona las entidades listadas en la SRL 308 y compara las entidades con el solicitante. De este modo, si la SRL 308 especifica que un grupo particular es para recibir una licencia y el solicitante es un miembro de tal grupo, el solicitante se le concede una licencia con derechos como se establece para el grupo en la SRL 308. De igual manera, si la SRL 308 especifica que un usuario particular recibirá una licencia y el solicitante es el usuario, el solicitante se le concede una licencia con derechos como se establece para el usuario en la SRL 308. Como puede apreciarse, una SRL 308 particular puede listar varias entidades y derechos para la misma, y un solicitante particular puede concedérsele una licencia basándose, en ser un miembro de una o más entidades. En una modalidad de la presente invención, y como se ve en la Figura 12, el solicitante se identifica en el certificado 1202 enviado por medio de un identificador 1204, donde ei identificador 1204 por ejemplo puede ser un alias a través del cual el solicitante se identifica en un directorio 1206 de organización. Correspondientemente, la SRL 308 lista en la misma cada entidad titulada con derechos en la misma de acuerdo con un identificador 1204. De este modo, y como parte del procesamiento de una solicitud para una licencia 1208, el concedente 1210 obtiene el identificador 1204 del solicitante del certificado 1202 y compara el identificador 1204 obtenido con todos los ¡dentificadores 1204 como se listan en la SRL 308 enviada. Si se encuentra una correlación, el concedente 1210 emite una licencia 1208 al solicitante con ios derechos especificados en la SRL 308 para el identificador 1204 del solicitante. Además, con la disponibilidad del directorio 1206, el -concedente 1210 también puede determinar si el solicitante es un miembro de cualquier otra entidad listada en la SRL 308, presumiendo que el directorio 1206 contiene la información de referencia cruzada apropiada que puede reflejar el estado de membresía del solicitante en cada tercera entidad. Típicamente, un directorio 1206 lista cada solicitante, no sólo el identificador 1204 del mismo sino también el identificador 1208 de cada grupo/cúmulos/división/plataforma/otra entidad/etc. , que el solicitante es un miembro. Nótese que el directorio 1206 puede incluir identif icadores 1208 tales como una dirección de correo, una dirección de correo alternativa, una ID, una ID alternativa, una membresía de grupo, un identificador histórico y/o similar. Con el certificado 1202 recibido del solicitante con el identificador 1204 del mismo y con los datos de derechos de la SRL 308 recibidos del solicitante, entonces, y refiriéndose ahora a la Figura 13, el concedente 1210 emite una licencia 1208 al solicitante en la siguiente forma. Preliminarmente, el concedente 1210 obtiene el identificador 1204 del solicitante del certificado 1202 recibido (etapa 1301) y localiza al identificador 1204 obtenido en el directorio 1206 (etapa 1303). Después de esto, el concedente 1210 localiza basándose en el identificador 1204 localizado en el directorio 1206, el identificador 1204 de cada entidad del cual el identificador 1204 del solicitante es un miembro (etapa 1305). De este modo, para cada uno del identificador 1204 del solicitante localizado y todos los identlficadores 1204 de identidad localizados, el concedente 1210 compara el identificador 1204 con todos los identlficadores 1204 como se lista en la SRL 308 enviada (etapa 1307). Nuevamente, si se encuentra una correlación, el concedente 1210 expide una licencia 1208 al solicitante con los derechos específicos en la SRL 308 para el identif icador 1204 concordante (etapa 1309a). Nótese que puesto que múltiples identif icadores 1204 se comparan con la SRL 308, puede ser el caso que múltiples identif icadores 1204 de correlación se encuentra en la SRL 308. Si es así, el concedente 1210 selecciona uno apropiado de los identificadores 1204 de correlación en la SLR 308 y expide una licencia 1208 al solicitante con los derechos específicos en la SRL 308 para el identif icador 1204 de correlación seleccionado (etapa 1309b). Por ejemplo, el solicitante puede seleccionar el identif icador 1204 de correlación que lleva la mayor parte de los derechos al solicitante (etapa 1309b-1). Nótese que el concedente puede ser capaz de determinar cuál identificador 1204 de correlación lleva la mayor parte de derechos, o puede tener que confiar en sólo cierta clase de indicios 1212 de prioridad en la SRL 308. En el último caso, cada identificador 1204 de correlación (de usuario) en la SRL 308 tienen un indicio 1212 de prioridad correspondiente, y un indicio 1212 más alto por ejemplo indica un mayor alcance de derechos concedidos. De este modo, si el concedente 1210 encuentra múltiples identificadores 1204 de correlación en la SRL 308, el concedente 1210 selecciona los identificadores 1204 de correlación que tienen el indicio 1212 de prioridad más alto (etapa 1309b-2).

Nótese que con referencia al directorio 1206 para generar identificadores 1204 adicionales relevantes al solicitante, el concedente 1210 incrementa la probabilidad de que se encontrará una correlación aún en la situación donde, por ejemplo, la dirección de correo o la ID del solicitante haya cambiado desde que se creo al SRL 308. En general, el directorio 1206 proporciona un mapa de un identificador 1204 del solicitante u otros identificadores 1204 posibles del solicitante, mediante los cuales todos los identificadores 1204 entonces pueden emplearse en un intento por encontrar una correlación en un identificador 1204 en la SRL 308.

Concesión a un Grupo En una modalidad de la presente invención, el certificado 1202 enviado como presentado por un solicitante puede representar un grupo o cúmulo o alguna otra colección de individuos (de aquí en adelante 'grupo') donde el grupo se representa apropiadamente dentro del directorio 1206. El grupo puede incluir un grupo habilitado por correo tal como una lista de distribución o un alias de correo, o un grupo de seguridad tal como puede definirse junto con un sistema de operación de red o similar. Por consiguiente, el concedente 1210 con la recepción del certificado 1212 de 'grupo' enviado procede sustancialmente como antes. Nótese, que debido a que el certificado 1202 enviado representa un grupo particular, puede ser que la licencia 1208 presentada del concedente 1210 es para el grupo identificado en el certificado 1202 y no el solicitante específicamente. Alternativamente, el concedente 1210 puede determinar a partir del directorio 1206 que el solicitante es parte del grupo identificada en el certificado 1202 y si la licencia 1210 presentada es para el solicitante. En el primer caso, la licencia 1208 expedida puede incluir la clave de contenido encriptada de acuerdo con una clave pública del grupo, y el solicitante de este modo necesita obtener la clave privada correspondiente del grupo. Por consiguiente, el solicitante puede tener de acuerdo con, los solicitante pueden tener un certificado de membresía de grupo con la clave privada, talvez encriptada de acuerdo con una clave pública del solicitante y que se puede descifrar de acuerdo con una clave privada correspondiente del solicitante. En el último caso, para incluir la clave de contenido encriptada de acuerdo con una clave pública del solicitante en la licencia 1208 expedida, el concedente 1210 puede recibir adicionalmente un certificado del solicitante con la clave pública. Alternativamente, el concedente" 1210 puede tener un certificado en el archivo (véase etapas 608-612 de las Figuras 6A y 6B, por ejemplo) y el uso de la clave pública en el mismo con la determinación del directorio 1206 de que el solicitante es parte del grupo identificada en el certificado 1202 de grupo enviado. Notablemente, especificar los derechos en una SRL 308 y expedir la licencia 1208 de acuerdo con un grupo, efectúa la administración digital de derechos en una empresa o establecimiento de organización. Por ejemplo, un documento o correo electrónico puede ser protegido por DR de manera que todos los miembros de un departamento dado tienen derechos para leer el documento o correo electrónico. Asumiendo que un grupo (por ejemplo, alias de correo electrónico) para un departamento existe en el directorio 1206 de la organización, el cual con mayor frecuencia es el caso, el autor del documento o correo electrónico puede conceder derechos basándose en el grupo en lugar de los individuos. Como puede apreciarse, ventajas para la concesión de derechos de grupo incluyen facilidad de uso para el autor en especificar clases de individuos que tienen derechos. Además, al especificar derechos de acuerdo con un grupo, los derechos especificados no se vuelven 'añejos' ya que nuevos individuos se unen al grupo e individuos antiguos dejan el grupo. De hecho, todos los miembros actuales del grupo son capaces de ejercer los derechos, siempre y cuando la membresía del grupo se mantenga hasta la fecha en el directorio 1206 de organización.

Introducir la Política Durante la Concesión En una modalidad de la presente invención, y como se observa en lo anterior junto con la ORT 900 de la Figura 9, el servidor de DRM/concedente 1210 pueden adaptarse para modificar o reemplazar los datos de derechos de una SRL 308 presentada cuando se expide una licencia 1208 basándose en la SRL 308. En particular, varias situaciones surgen donde los datos de derechos en una SRL 308 presentada se ignora explícitamente, y el concedente 1210 de hecho sustituye o 'introduce' una política alternativa cuando crea una licencia 1208 basándose en la SRL 308. Nótese que aunque varias situaciones particulares se describen en la presente donde el concedente 1210 introduce política en una licencia 1208, el concedente 1210 también puede introducir política en una licencia 1208 en cualquier otro tipo de situación sin apartarse del espíritu y alcance de la presente invención. En una primera situación, y regresando ahora a la Figura 14, el concedente 1208 mantiene una lista 1214 (Figura 12) de entidades especiales (usuarios, grupos, etc.) que son titulados para derechos especiales. Por ejemplo, las entidades especiales pueden comprender ciertos individuos de más alto nivel en una organización, ciertos individuos de supervisión, ciertos individuos que deben ser capaces de ejecutar todo el contenido y grupos de los individuos antes mencionados, entre otras cosas. La lista 1214 puede representarse de hecho dentro del directorio 1206 de organización como información de identificación en la lista de directorio para cada entidad especial, o más simple al crear uno o más grupos de tales entidades especiales. De este modo, las entidades especiales pueden ejecutar el contenido aún si la SRL 308 de otra manera puede prohibir la ejecución para la misma. Con una entidad que presenta una SRL 308 como parte de una petición para una licencia 1208, entonces, y con referencia ahora a la Figura 14, el concedente 1210 verifica el directorio 1206 en una forma apropiada para determinar si la entidad de presentación pude caracterizarse como una entidad especial (etapa 1401), y si es así, el concedente 1210 crea una licencia 1208 para la entidad especial con los derechos especiales que difieren de los datos de derechos presentes en la SRL 308 presentada (etapa 1403). Nótese que los derechos especiales pueden ser cualquier derecho sin apartarse del espíritu y alcance de la presente invención. Por ejemplo, los derechos especiales pueden ser que todas las entidades especiales puedan tener acceso completamente y ejecutar el contenido correspondiente, que todas las entidades especiales de un grupo particular puedan tener acceso completamente y ejecutar el contenido, que una entidad especial particular reciba derechos mejorados tal como una cuenta de reproducción más alta o un periodo más largo antes de que expire la licencia 1208, etc. Nótese que si los derechos especiales son particulares para un individuo o grupo, los derechos pueden especificarse en una entrada de directorio para el individuo o grupo en el directorio 1206, la entrada de directorio puede tener una referencia apropiada en una ubicación donde los derechos especiales se localizan, el concedente 1210 puede encontrar los derechos especiales en una base de datos basándose en un identificador 1204 del individuo o grupo, o similar. En una segunda situación, y regresando ahora a la Figura 15, el concedente 1208 mantiene una lista 1216 (Figura 12) de las entidades restringidas (usuarios, grupos, etc.) a quienes se evitarán o negarán los derechos. Por ejemplo, las entidades restringidas pueden comprender individuos que hayan dejado la organización, individuos en la organización que no deben tener normalmente ningún derecho a cualquier contenido, como mantenimiento y personal del edificio, individuos que tienen solamente estados limitados dentro de la organización, tal como contratistas y empleados temporales, y grupos de individuos antes mencionados, entre otras cosas. Como la lista 1214 'especial' antes mencionada, la lista 1216 restringida también puede representarse dentro del directorio 1206 de organización como información de identificación en la lista de directorio para cada entidad restringida, o simplemente al crear uno o más grupos de entidades restringidas. De este modo, las entidades restringidas se restringen a partir de la ejecución del contenido, aún si la SRL 308 de otra manera pueda permitir la ejecución. Con una entidad que presenta una SRL 308 como parte de una petición para una licencia 1208, entonces, y aún con referencia a la Figura 14, el concedente 1210 verifica el directorio 1206 en una forma apropiada para determinar si la entidad de presentación puede caracterizarse como una entidad restringida (etapa 1405), y si es así, el concedente 1210 crea una licencia 1208 para la entidad restringida con los derechos restringidos que difieren de los datos de derechos presentes en la SRL 308 presentada (etapa 1407). Nótese que los derechos restringidos pueden ser cualquier derecho sin apartarse del espíritu y alcance de la presente invención. Por ejemplo, los derechos restringidos que pueden ser las entidades restringidas, no puedan tener acceso y ejecutar el contenido correspondiente en alguna forma, que todas las entidades restringidas de un grupo particular pueda tener acceso y ejecutar sólo el contenido en una forma efímera, que una entidad restringida particular pueda incluir sólo una copia individual de una pieza de contenido, etc. Además, los derechos restringidos pueden ser que una entidad restringida no concederá ninguna licencia en absoluto. Como con los derechos especiales, si los derechos restringidos son particulares para un individuo o grupo, los derechos pueden especificarse en una entrada de directorio para el individuo o grupo en el directorio 1206, la entrada de directorio puede tener una referencia apropiada a una ubicación donde los derechos restringidos se localizan, el concedente 1210 puede encontrar los derechos restringidos en una base de datos basada en un identif icador 1204 del grupo o individuo, o similar. En una tercera situación, el concedente 1208 puede introducir política en una licencia 1208 para especificar los requerimientos mínimos del sistema que son necesarios en el dispositivo 14 de cómputo (Figura 11) que es ejecutar el contenido correspondiente (etapa 1409). Los requerimientos del sistema mínimo típicamente se refieren a confiabilidad y seguridad del dispositivo 14 de cómputo, aunque los requerimientos también pueden relacionarse a cualquier otra materia sin apartarse del espíritu y alcance de la presente invención.

Un ejemplo primario de confiabilidad y seguridad que puede tener que ver con el cedente 1210 si el componente 18 de confianza del dispositivo 14 de cómputo o una porción de seguridad del mismo es actual. Como puede apreciarse, la divisa puede representarse por un número de versión, una fecha de construcción o similar, y refleja una edad para el componente 18 de confianza o porción del mismo. También, como puede apreciarse, el componente 18 de confianza o porción del mismo es más vulnerable a un ataque de seguridad por una entidad de corrupta como el componente 18 de confianza o porción del mismo. Por consiguiente, un concedente 1210 puede decidir que un componente 18 de confianza o porción del mismo que está más allá de una cierta edad no debe ser de confianza, y puede introducir política en una licencia 1208 expedida por consiguiente que requiere que el componente 18 de confianza no confiable o porción del mismo se actualiza antes de permitir que el contenido correspondiente se ejecute. Otro ejemplo de confiabilidad y seguridad que puede tener que ver con el concedente 1210 es la aplicación que presentará el contenido debe de hecho ser de confianza. Como puede apreciarse, puede ser el caso de que una aplicación puede ser de confianza para ejecutar el contenido dentro de los enlaces de la licencia 1208 por ejemplo, no permitir que el contenido se guarde en una forma no protegida, mientras otra aplicación no puede ser de confianza de otra manera. Por consiguiente, un concedente 1210 puede decidir que sólo ciertas aplicaciones pueden emplearse para conceder el contenido correspondiente y puede inyectar política en una licencia 1208 expedida por consiguiente que requiere que solamente la aplicación pueda emplearse para ejecutar el contenido. Desde luego, otras situaciones de ingreso de política son abundantes. Generalmente, la inyección de política puede realizarse para agregar derechos adicionales o remover derechos de los datos de derechos en una SRL 308, talvez basándose en el solicitante (etapa 1411); y de igual manera para agregar condiciones o remover condiciones de los datos de derechos, nuevamente talvez basándose en el solicitante (etapa 1413).

Conclusión La programación necesaria para efectuar el proceso realizado junto con la presente invención es relativamente directa y debe ser aparente para el público de programación relevante. Por consiguiente, la programación no se une al mismo. Cualquier programación particular, entonces puede emplearse para efectuar la presente invención sin apartarse del espíritu y alcance de la misma. Se debe apreciar que cambios pueden hacerse a las modalidades descritas en lo anterior sin apartarse de los conceptos inventivos de la misma. Notablemente, aunque la presente invención se describe en términos de un universo definido tal como una organización, la presente invención también puede emplearse dentro de un universo definido tal como un subconjunto de una organización o que abarca múltiples organizaciones, todas sin apartarse del espíritu y alcance de la presente invención. Debe entenderse, por lo tanto, que esta invención no se limita a las modalidades particulares descritas, pero se pretende cubrir modificaciones dentro del espíritu y alcance de la presente invención como se define por las reivindicaciones anexas.

Claims (18)

REIVINDICACIONES

1. Un método para que un concedente expida una licencia digital a un solicitante para permitir que el solicitante ejecute el contenido digital correspondiente, el método comprende: recibir una solicitud del solicitante, la solicitud incluye datos de derechos asociados con el contenido, los datos de derechos que listan por lo menos un identif icador y un conjunto de derechos asociados con el mismo; seleccionar el identificador y el conjunto de derechos asociados con el mismo, en donde se espera que los derechos se establezcan en la licencia expedida; seleccionar basándose en el identificador un conjunto alternativo de derechos; substituir el conjunto alternativo de derechos del conjunto de derechos de los datos de derechos; expedir la licencia al solicitante con el conjunto alternativo de derechos, mediante el cual el conjunto alternativo de derechos en los conjuntos de licencia expedida establece términos y condiciones que el solicitante debe agregar a una condición por la ejecución del contenido correspondiente.

2. El método de acuerdo con la reivindicación 1, en donde ei concedente tiene acceso a un directorio que incluye una lista para el identificador, la lista hace referencia al conjunto alternativo de datos de derechos, y en donde seleccionar el conjunto alternativo de datos de derechos comprende localizar el ¡dentificador en el directorio y localizar el conjunto alternativo de derechos basándose en la referencia al mismo y la lista para el ¡dentificador en el directorio.

3. El método de acuerdo con la reivindicación 1, el cual comprende determinar basándose en el ¡dentificador que el solicitante es un solicitante especial y seleccionar basándose en el mismo, un conjunto alternativo de derechos que proporciona mayores derechos que el conjunto de derechos de los datos de derechos.

4. El método de acuerdo con la reivindicación 3, el cual comprende seleccionar un conjunto alternativo de derechos que permite que el solicitante especial tenga acceso completamente y ejecute el contenido correspondiente.

5. El método de acuerdo con la reivindicación 3, el cual comprende determinar basándose en el ¡dentificador que el solicitante es un solicitante restringido y seleccionar basándose en el mismo un conjunto alternativo de derechos que proporcione derechos menores que el conjunto de derechos de los datos de derechos.

6. El método de acuerdo con la reivindicación 5, el cual comprende seleccionar un conjunto alternativo de derechos que no permite que el solicitante restringido tenga acceso y ejecute el contenido correspondiente.

7. El método de acuerdo con la reivindicación 1, el cual comprende seleccionar basándose en el identificador un conjunto alternativo de derechos que impone requerimientos del sistema mínimos con relación a un dispositivo computarizado sobre el cual el contenido correspondiente va a ejecutarse.

8. El método de acuerdo con al reivindicación 1, el cual comprende seleccionar basándose en el identificador un conjunto alternativo de derechos que agregan derechos al conjunto de derechos de los datos de derechos.

9. El método de acuerdo con la reivindicación 1, el cual comprende seleccionar basándose en el identificador un conjunto alternativo de derechos que resta derechos del conjunto de derechos de los datos de derechos.

10. Un medio legible por computadora que tiene almacenado en el mismo instrucciones ejecutables por computadora para realizar un método para que un concedente expida una licencia digital a un solicitante para permitir que el solicitante solicite el contenido digital correspondiente, el método comprende: recibir una solicitud del solicitante, la solicitud incluye datos de derechos asociados con el contenido, los datos de derechos listan por lo menos un identificador y un conjunto de derechos asociado con el mismo; seleccionar el identificador y el conjunto de derechos asociados con el mismo, siempre y cuando los derechos se esperen para que se establezcan en la licencia expedida; seleccionar basándose en el identificador, un conjunto alternativo de derechos; sustituir el conjunto alternativo de derechos para el conjunto de derechos de los datos de derechos; expedir la licencia al solicitante con el conjunto alternativo de derechos, mediante el cual el conjunto alternativo de derechos en la licencia expedida establece términos y condiciones para que el solicitante agregue junto con la ejecución del contenido correspondiente.

11. El medio de acuerdo con la reivindicación 10, en donde el concedente tiene acceso a un directorio que incluye una lista para el identificador, la lista hace referencia al conjunto alternativo de datos de derechos, y en donde el seleccionar el conjunto alternativo de datos de derechos comprende localizar el identificador en el directorio y localizar el conjunto alternativo de derechos basándose en la referencia al mismo de la lista para el identificador en el directorio.

12. El medio de acuerdo con la reivindicación 10, en donde el método comprende determinar basándose en el identificador que el solicitante es un solicitante especial y que se selecciona basándose en un conjunto alternativo de derechos que proporciona derechos mayores que los conjuntos de derechos de los datos de derechos.

13. El medio de acuerdo con la reivindicación 12, en donde el método comprende seleccionar un conjunto alternativo de derechos que permite que el solicitante especial tenga acceso completamente y ejecute el contenido correspondiente.

14. El medio de acuerdo con la reivindicación 10, en donde el método comprende determinar basándose en el identif icador que el solicitante es un solicitante restringido y seleccionar la base en el mismo un conjunto alternativo de derechos que proporcionan derechos menores que el conjunto de derechos de los datos de derechos .

15. El medio de acuerdo con la reivindicación 14, en donde el método comprende seleccionar un conjunto alternativo de derechos que no permita que el solicitante restringido tenga acceso y ejecute el contenido correspondiente.

16. El medio de acuerdo con al reivindicación 10, en donde el método comprende seleccionar basándose en el identificador un conjunto alternativo de derechos que imponga requerimientos mínimos del sistema con relación a un dispositivo de cómputo con el contenido correspondiente que se ejecuta.

17. El medio de acuerdo con al reivindicación 10, en donde el método comprende seleccionar basándose en el identificador un conjunto alternativo de derechos que agrega derechos al conjunto de derechos de los derechos de datos.

18. El medio de acuerdo con al reivindicación 10, en donde el método comprende seleccionar basándose en el identificador un conjunto alternativo de derechos que resta derechos del conjunto de derechos de los datos de derechos.