ES2271427T3 - Arquitectura de servidor enchufable asegurada para sistemas de gestion de derechos digitales. - Google Patents
Arquitectura de servidor enchufable asegurada para sistemas de gestion de derechos digitales. Download PDFInfo
- Publication number
- ES2271427T3 ES2271427T3 ES03013564T ES03013564T ES2271427T3 ES 2271427 T3 ES2271427 T3 ES 2271427T3 ES 03013564 T ES03013564 T ES 03013564T ES 03013564 T ES03013564 T ES 03013564T ES 2271427 T3 ES2271427 T3 ES 2271427T3
- Authority
- ES
- Spain
- Prior art keywords
- rights
- attachable
- digital
- drm
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/126—Applying verification of the received information the source of the received data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/062—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying encryption of the keys
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Storage Device Security (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
Un sistema (300) para suministrar servicios de gestión de derechos digitales, comprendiendo el sistema (300): un programa de servicio que proporciona un entorno de procesamiento para realizar un servicio (306) de gestión de derechos digitales; y una pluralidad de componentes acoplables, cada uno de los cuales realiza una tarea respectiva asociada al servicio de gestión de derechos digitales, en el cual cada uno entre la pluralidad de componentes acoplables se integra en el entorno de procesamiento según un respectivo conjunto predefinido de reglas de interfaz.
Description
Arquitectura de servidor enchufable asegurada
para sistemas de gestión de derechos digitales.
Esta invención se refiere a sistemas de gestión
de derechos digitales. Más en particular, la invención se refiere a
arquitecturas acoplables para baterías de procesos en sistemas de
gestión de derechos digitales.
La gestión y el control de cumplimiento de los
derechos digitales son sumamente deseables en relación a contenidos
digitales tales como audio digital, vídeo digital, texto digital,
datos digitales, multimedios digitales, etc., donde tales
contenidos digitales han de distribuirse a uno o más usuarios. Los
típicos modos de distribución incluyen dispositivos tangibles tales
como un disquete magnético, una cinta magnética, un disco compacto
(CD) óptico, etc., y medios intangibles tales como una cartelera
electrónica, una red electrónica, Internet, etc. Al ser recibidos
por el usuario, dicho usuario representa o reproduce el contenido
digital con la ayuda de un dispositivo de representación adecuado,
tal como un reproductor de medios en un ordenador personal, o algo
similar.
En un posible escenario, un propietario de
contenidos, o un propietario de derechos, tal como un autor, un
editor, un difusor, etc., desea distribuir tales contenidos
digitales a cada uno entre muchos usuarios o destinatarios, a
cambio de un arancel de 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 la finalidad de la distribución
es generar los aranceles de licencia. Tal propietario de
contenidos, si se le da la opción de escoger, probablemente desearía
restringir lo que el usuario puede hacer con tales contenidos
digitales distribuidos. Por ejemplo, el propietario de contenidos
desearía restringir al usuario la posibilidad de copiar y
redistribuir tales contenidos a un segundo usuario, al menos de
forma tal que niegue al propietario de contenidos un arancel de
licencia de tal segundo usuario.
Además, el propietario de contenidos puede
desear brindar al usuario la flexibilidad de adquirir distintos
tipos de licencias de uso a distintos aranceles de licencia,
comprometiendo a la vez al usuario con los términos de cualquier
tipo de licencia que se adquiera de hecho. Por ejemplo, el
propietario de contenidos puede desear permitir que los contenidos
digitales distribuidos se reproduzcan sólo un número limitado de
veces, sólo por un cierto tiempo total de duración, sólo sobre un
cierto tipo de máquina, sólo sobre un cierto tipo de reproductor de
medios, sólo por un cierto tipo de usuario, etc.
En otro escenario posible, un desarrollador de
contenidos, tal como un empleado en una organización, desea
distribuir tales contenidos digitales a uno o más empleados en la
organización, o a otros individuos fuera de la organización, pero
desearía evitar que otros representaran los contenidos. Aquí, la
distribución de los contenidos es más afín a la compartición de
contenidos con base en una organización, de manera confidencial o
restringida, en contraposición con la distribución de base amplia, a
cambio de un arancel de licencia o de alguna otra consideración. En
tal escenario, entonces, los contenidos pueden ser una presentación
de documento, una hoja de cálculo, una base de datos, un correo
electrónico, o algo similar, tal como lo que puede intercambiarse
dentro de un entorno de oficina, y el desarrollador de contenidos
puede desear asegurarse de que los contenidos permanecen dentro del
entorno de oficina, y que no son reproducidos por individuos no
autorizados, tales como, por ejemplo, los competidores o
adversarios. Nuevamente, tal desarrollador de contenidos desea
restringir lo que un destinatario puede hacer con tales contenidos
digitales distribuidos. Por ejemplo, el propietario de los
contenidos desearía restringir al usuario en cuanto a copiar y
redistribuir tales contenidos a un segundo usuario, al menos de
manera tal que exponga los contenidos fuera del ámbito de los
individuos que deberían estar autorizados para reproducir los
contenidos.
Además, el desarrollador de contenidos puede
desear proporcionar a diversos destinatarios distintos niveles de
derechos de reproducción. Por ejemplo, el desarrollador de
contenidos puede desear permitir que los contenidos digitales
protegidos sean visibles y no imprimibles con respecto a una clase
de individuos, y visibles e imprimibles con respecto a otra clase de
individuos.
Sin embargo, y en cualquier escenario posible,
después que ha tenido lugar la distribución, tal propietario, o
desarrollador, de contenidos, tiene muy poco control, si acaso,
sobre los contenidos digitales. Esto es especialmente problemático
a la vista del hecho de que prácticamente todo ordenador personal
incluye el software y el hardware necesarios para hacer una copia
digital exacta de tales contenidos digitales, y para descargar tal
copia digital exacta a un disco grabable, magnético u óptico, o para
enviar tal copia digital exacta por una red, tal como Internet, a
cualquier destino.
Por supuesto, como parte de una transacción en
la cual se distribuyen los contenidos, el propietario o
desarrollador de contenidos puede requerir al usuario o
destinatario de los contenidos digitales que prometa no redistribuir
tales contenidos digitales de manera indebida. Sin embargo, tal
promesa es fácil de hacer y fácil de romper. Un propietario o
desarrollador de contenidos puede intentar impedir tal
redistribución por medio de cualquiera de diversos dispositivos de
seguridad conocidos, que usualmente involucran cifrado y descifrado.
Véase, por ejemplo, KONSTANTAS D ET AL:
"Agent-based commercial dissemination of
electronic information" ["Diseminación comercial basada en
agentes de información electrónica"], COMPUTER NETWORKS, ELSEVIER
SCIENCE PUBLISHERS B.V., AMSTERDAM, NL, vol. 32, nº 6, 30 de mayo
de 2000 (2000-05-30), páginas
753-765, ISSN: 1389-1286. Sin
embargo, no hay prácticamente nada que impida a un usuario
medianamente determinado el descifrar contenidos digitales cifrados,
guardando tales contenidos digitales en formato no cifrado, y
redistribuyendo luego los mismos.
Por muchas razones, la tecnología del servidor
de DRM es dinámica. Es decir, según la tecnología se desarrolla a
lo largo del tiempo, o según surgen nuevas amenazas para la
seguridad de los contenidos digitales, se tiende a emplear
distintos enfoques para realizar ciertas tareas a fin de
proporcionar servicios específicos. Frecuentemente, la provisión de
un servicio de DRM específico involucra la realización de un cierto
número de tareas distintas. Sin embargo, de tanto en tanto, un
proveedor podría desear realizar sólo una tarea, o unas pocas, de
manera distinta. El proveedor y el usuario, típicamente,
preferirían que el sistema, en su totalidad, fuese perturbado lo
menos posible. Además, debido al coste y a otras restricciones,
distintos usuarios de tales servidores de DRM desean o requieren
sistemas que se comportan de manera diferente. En consecuencia,
sería ventajoso si se dispusiera de sistemas y procedimientos por
los cuales sólo pudiesen cambiarse tareas seleccionadas dentro de
la provisión de un servicio de gestión de derechos digitales, de
manera modular, sin la necesidad de modificar todo el programa de
provisión de servicios.
Además, debido a que una típica instalación de
DRM puede proporcionar un cierto número de servicios de gestión de
derechos digitales, tales como servicios de edición, de licencias,
de federación, de suscripción, etc., es deseable que estos
servicios se suministren de manera tal que permita al proveedor o
administrador de la instalación mantener el sistema tan
eficientemente como sea posible. Por ejemplo, el administrador
podría no querer tener que actualizar el servicio de edición cada
vez que se realiza un cambio en el componente de licencias, y
viceversa. En consecuencia, sería ventajoso si se dispusiera de
sistemas para proporcionar estos servicios independientemente entre
sí. Hay una necesidad en la tecnología, por lo tanto, de un enfoque
modular para el suministro de una pluralidad de servicios de DRM
independientes entre sí. Tales enfoques serían especialmente
ventajosos si permitiesen la categorización como componentes de la
lógica comercial clave, de forma tal que los terceros pudieran
extender y modificar la funcionalidad de la DRM y la lógica
comercial de la plataforma.
Según las Reivindicaciones 1 y 21, la invención
proporciona arquitecturas seguras acoplables de servidores para
sistemas de gestión de derechos digitales. Un servidor de gestión de
derechos digitales según la invención se basa en una arquitectura
de baterías de procesos, en la cual cada uno entre una pluralidad de
servicios de gestión de derechos digitales se realiza en una
respectiva batería de procesos, y las respectivas baterías de
procesos son independientes entre sí. Tales servicios pueden incluir
contenidos digitales con gestión de derechos de edición y de
licencia. Cada batería de procesos incluye un programa de servicio
que brinda un entorno de procesamiento para llevar a cabo un
servicio de gestión de derechos digitales, y una pluralidad de
componentes acoplables, cada uno de los cuales realiza una tarea
respectiva, asociada al servicio de gestión de derechos
digitales.
Un proveedor de un sistema de DRM puede
proporcionar los programas de servicio, y una pluralidad de opciones
acoplables de gestión de derechos digitales, cada una de las cuales
está asociada a un respectivo componente acoplable. Basándose en
las selecciones efectuadas por el destinatario de la instalación,
los componentes acoplables deseados pueden integrarse en el entorno
de procesamiento según un respectivo conjunto predefinido de reglas
de interfaz.
La pluralidad de componentes acoplables puede
incluir uno o más componentes acoplables de extensión, que realizan
sus respectivas tareas basándose en la ocurrencia de ciertos sucesos
prescritos. Un componente acoplable de extensión puede adaptarse
para detener el procesamiento del programa de servicio. La
pluralidad de componentes acoplables también puede incluir uno o
más componentes acoplables asincrónicos, que realizan sus
respectivas tareas después de que se ha completado el procesamiento
de la batería principal de procesos para la acción solicitada.
Otras características de la invención son
adicionalmente evidentes a partir de la siguiente descripción
detallada de las realizaciones de la presente invención, considerada
conjuntamente con los dibujos adjuntos.
La Fig. 1 es un diagrama en bloques que
representa un ejemplo de entorno informático no limitador, en el
cual puede implementarse la presente invención.
La Fig. 2 es un diagrama en bloques que
representa un ejemplo de entorno en red, que tiene diversos
dispositivos informáticos en los cuales puede implementarse la
presente invención.
La Fig. 3 es un diagrama en bloques funcionales
de una realización preferida de un sistema y un procedimiento según
la invención, para editar contenidos digitales.
La Fig. 4 proporciona un diagrama de flujo de
una realización preferida de un procedimiento según la invención,
para contenidos digitales con gestión de derechos de edición.
La Fig. 4A es un diagrama en bloques que muestra
la estructura de una etiqueta firmada de derechos, según lo
producido por el procedimiento de la Fig. 4.
La Fig. 5 es un diagrama en bloques funcionales
de una realización preferida de un sistema y un procedimiento según
la invención, para contenidos digitales con gestión de derechos de
licencia.
Las Figs. 6A y 6B proporcionan un diagrama de
flujo de una realización preferida de un procedimiento según la
invención, para contenidos digitales con gestión de derechos de
licencia.
La Fig. 7 es un diagrama de flujo que muestra
las etapas clave llevadas a cabo al reeditar una etiqueta de
derechos según una realización de la presente invención.
La Fig. 8 es un diagrama en bloques que muestra
un certificado emitido por un servidor de DRM a un usuario, a fin
de permitir al usuario realizar la edición fuera de línea, según una
realización de la presente invención.
La Fig. 9 es un diagrama en bloques que muestra
una plantilla de derechos que especifica información a incorporar
en una etiqueta de derechos, según una realización de la presente
invención.
La Fig. 10 es un diagrama de flujo que muestra
las etapas clave llevadas a cabo al crear la plantilla de derechos
de la Fig. 9 y al crear la etiqueta firmada de derechos de la Fig.
4A, basada en la plantilla de derechos, según una realización de la
presente invención.
La Fig. 11 ilustra una arquitectura genérica de
baterías de procesos según la invención.
La Fig. 12 ilustra una realización preferida de
una batería de procesos de edición según la invención.
La Fig. 13 ilustra una realización preferida de
una batería de procesos de licencia según la invención.
La Fig. 14 proporciona un diagrama de flujo de
una realización preferida de un procedimiento según la invención,
para proporcionar una arquitectura acoplable segura de servidor para
sistemas de gestión de derechos digitales.
La Fig. 1 y la siguiente exposición están
concebidas para proporcionar una breve descripción general de un
entorno informático adecuado, en el cual pueda implementarse la
invención. Debería entenderse, sin embargo, que se contemplan
dispositivos de mano, portátiles, y otros dispositivos de toda
clase, para su empleo en relación a la presente invención. Si bien
se describe a continuación un ordenador de propósito general, esto
no es sino un ejemplo, y la presente invención sólo requiere un
cliente ligero que tenga interoperabilidad e interacción con un
servidor de red. Por ello, la presente invención puede implementarse
en un entorno de servicios alojados en red, en el cual se implica
un número muy pequeño, o mínimo, de recursos del cliente, p. ej.,
un entorno en red en el cual el dispositivo cliente funciona
simplemente como un explorador o una interfaz con la Web en
Internet.
Aunque no se requiere, la invención puede
implementarse por medio de una interfaz de programación de
aplicaciones (Application Programming Interface - API), para su
utilización por parte de un desarrollador, e/o incluirse dentro
del software de exploración de la red, que se describirá en el
contexto general de las instrucciones ejecutables por ordenador,
tales como módulos de programa, que son ejecutados por uno o más
ordenadores, tales como estaciones clientes, servidores u otros
dispositivos. Generalmente, los módulos de programa incluyen
rutinas, programas, objetos, componentes, estructuras de datos y
otros similares, que realizan tareas particulares o bien implementan
tipos particulares de datos abstractos.
Típicamente, la funcionalidad de los módulos de
programa puede combinarse o distribuirse según se desee en diversas
realizaciones. Además, aquellos versados en la técnica apreciarán
que la invención puede llevarse a la práctica con otras
configuraciones de sistemas de ordenadores. Otros sistemas
informáticos, entornos y/o configuraciones bien conocidas, que
puedan ser adecuadas para su empleo con la invención, incluyen,
pero no se limitan a, los ordenadores personales (PC), cajeros
automáticos, ordenadores servidores, dispositivos de mano o
portátiles, sistemas de multiprocesadores, sistemas basados en
microprocesadores, electrónica de consumo programable, ordenadores
personales en red, miniordenadores, ordenadores centrales, y otros
similares. La invención también puede llevarse a la práctica en
entornos informáticos distribuidos, donde las tareas son realizadas
por dispositivos de procesamiento remoto, que están enlazados a
través de una red de comunicaciones u otro medio de transmisión de
datos. En un entorno informático distribuido, los módulos de
programa pueden colocarse en medios de almacenamiento de
ordenadores, tanto locales como remotos, incluyendo dispositivos de
almacenamiento en memoria.
La Fig. 1 ilustra así un ejemplo de un entorno
100 de sistema informático adecuado, en el cual puede implementarse
la invención, aunque, como se ha aclarado anteriormente, el entorno
100 del sistema informático es sólo un ejemplo de un entorno
informático adecuado, y no está concebido para sugerir ninguna
limitación en cuanto al alcance del empleo o la funcionalidad de la
invención. Tampoco debería interpretarse que el entorno informático
100 tenga alguna dependencia o requisito vinculado con uno
cualquiera, o una combinación, de los componentes ilustrados en el
ejemplo de entorno operativo 100.
Con referencia a la Fig. 1, un ejemplo de
sistema para implementar la invención incluye un dispositivo
informático de propósito general, en la forma de un ordenador 110.
Los componentes del ordenador 110 pueden incluir, pero no se
limitan a, una unidad 120 de procesamiento, una memoria 130 del
sistema, y un bus 121 del sistema que acopla diversos componentes
del sistema, incluyendo la memoria del sistema, con la unidad 120 de
procesamiento. El bus 121 del sistema puede ser de cualquiera de
los diversos tipos de estructuras de bus, incluyendo un bus de
memoria o un controlador de memoria, un bus periférico y un bus
local que utiliza una cualquiera entre una gran variedad de
arquitecturas de bus. A modo de ejemplo, y no de limitación, tales
arquitecturas incluyen el bus ISA (Industry Standard Architecture -
Arquitectura Industrial Estándar), el bus MCA (Micro Channel
Architecture - Arquitectura de Microcanal), el bus EISA (Enhanced
ISA - ISA Mejorado), el bus local VESA (Video Electronics Standards
Association - Asociación de Estándares de Electrónica de Vídeo) y el
bus PCI (Peripheral Component Interconnect - Interconexión
Periférica de Componentes), también conocido como el bus Mezzanine
(Entresuelo).
El ordenador 110, típicamente, incluye diversos
medios legibles por ordenador. Los medios legibles por ordenador
pueden ser cualesquiera medios disponibles que puedan ser accesibles
desde el ordenador 110, e incluyen medios tanto volátiles como no
volátiles, extraíbles y no extraíbles. A modo de ejemplo, y no de
limitación, los medios legibles por ordenador pueden comprender
medios de almacenamiento en ordenador y medios de comunicación. Los
medios de almacenamiento en ordenador incluyen medios tanto
volátiles como no volátiles, extraíbles y no extraíbles,
implementados en cualquier procedimiento o tecnología para el
almacenamiento de información, tales como instrucciones legibles
por ordenador, estructuras de datos, módulos de programa u otros
datos. Los medios de almacenamiento en ordenador incluyen, pero no
se limitan a, la memoria RAM, ROM, EEPROM, flash u otra tecnología
de memoria, dispositivos CDROM, discos versátiles digitales (DVD) u
otros dispositivos de almacenamiento en disco óptico, casetes
magnéticos, cinta magnética, almacenamiento en disco magnético u
otros dispositivos de almacenamiento magnético, o cualquier otro
medio que pueda emplearse para almacenar la información deseada, y
que pueda ser accesible desde el ordenador 110. Los medios de
comunicación, típicamente, realizan instrucciones legibles por
ordenador, estructuras de datos, módulos de programa u otros datos,
en una señal modulada de datos, tal como una onda portadora u otro
mecanismo de transporte, e incluyen cualquier medio de entrega de
información. El término "señal modulada de datos" significa una
señal que tiene una o más de sus características fijadas o
cambiadas, de manera tal como para codificar información en la
señal. A modo de ejemplo, y no de limitación, los medios de
comunicación incluyen medios cableados tales como una red cableada
o una conexión de cableado directo, y medios inalámbricos tales como
medios acústicos, de RF (radiofrecuencia), infrarrojos y otros
medios inalámbricos. Las combinaciones de cualesquiera de los
anteriores también deberían incluirse dentro del ámbito de los
medios legibles por ordenador.
La memoria 130 del sistema incluye medios de
almacenamiento en ordenador, en forma de memoria volátil y/o no
volátil, tal como la memoria 131 sólo de lectura (ROM) y la memoria
132 de acceso aleatorio (RAM). Un sistema básico 133 de
entrada/salida (BIOS), que contiene las rutinas básicas que ayudan a
transferir información entre elementos dentro del ordenador 110,
tal como durante al arranque, se almacena, típicamente, en la
memoria ROM 131. La memoria RAM 132, típicamente, contiene datos
y/o módulos de programa que están inmediatamente accesibles para,
y/o están siendo operados actualmente por, la unidad 120 de
procesamiento. A modo de ejemplo, y no de limitación, la Fig. 1
ilustra el sistema operativo 134, los programas 135 de aplicación,
otros módulos 136 de programa y los datos 137 de programa.
El ordenador 110 también puede incluir otros
medios de almacenamiento en ordenador, extraíbles o no extraíbles,
volátiles o no volátiles. Sólo a modo de ejemplo, la Fig. 1 ilustra
un controlador 141 de disco rígido que lee, o graba, en medios
magnéticos no extraíbles, no volátiles; un controlador 151 de disco
magnético que lee o graba en un disco magnético 152 extraíble, no
volátil; y un controlador 155 de disco óptico que lee y graba en un
disco óptico 156 extraíble, no volátil, tal como un disco CD ROM u
otros medios ópticos. Otros medios de almacenamiento en ordenador,
extraíbles o no extraíbles, volátiles o no volátiles, que pueden
emplearse en el ejemplo de entorno operativo incluyen, pero no se
limitan a, casetes de cinta magnética, tarjetas de memoria flash,
discos versátiles digitales, cinta de vídeo digital, memoria RAM de
estado sólido, memoria ROM de estado sólido, y otros similares. El
controlador 141 de disco rígido, típicamente, está conectado con el
bus 121 del sistema a través de una interfaz de memoria no
extraíble, tal como la interfaz 140, y el controlador 151 de disco
magnético y el controlador 155 de disco óptico, típicamente, están
conectados con el bus 121
\hbox{del sistema por una interfaz de
memoria extraíble, tal como la interfaz 150.}
Los controladores y sus medios asociados de
almacenamiento en ordenador, expuestos anteriormente e ilustrados
en la Fig. 1, proporcionan almacenamiento de instrucciones legibles
por ordenador, estructuras de datos, módulos de programa y otros
datos para el ordenador 110. En la Fig. 1, por ejemplo, el
controlador 141 de disco rígido se ilustra almacenando el sistema
operativo 144, los programas 145 de aplicación, otros módulos 146
de programa y los datos 147 de programa. Observe que estos
componentes pueden bien coincidir con, o bien diferir del sistema
operativo 134, los programas 135 de aplicación, los otros módulos
136 de programa y los datos 137 de programa. El sistema operativo
144, los programas 145 de aplicación, los otros módulos 146 de
programa y los datos 147 de programa reciben aquí distintos números
para ilustrar que, como mínimo, son copias distintas. Un usuario
puede ingresar comandos e información en el ordenador 110 a través
de dispositivos de entrada, tales como un teclado 162 y un
dispositivo 161 de puntero, comúnmente denominado ratón, puntero
táctil o panel táctil. Otros dispositivos de entrada (no mostrados)
pueden incluir un micrófono, una palanca de juegos, un panel de
juegos, un plato de satélite, un escáner, u otros similares. Estos y
otros dispositivos de entrada se conectan a menudo con la unidad
120 de procesamiento a través de una interfaz 160 de entrada de
usuario, que está acoplada con el bus 121 del sistema, pero pueden
conectarse por medio de otras estructuras de interfaz y de bus,
tales como un puerto paralelo, un puerto de juegos o un bus
universal en serie (Universal Serial Bus - USB).
Un monitor 191, u otro tipo de dispositivo de
visualización, también está conectado con el bus 121 del sistema
por medio de una interfaz, tal como una interfaz 190 de vídeo. Una
interfaz gráfica 182, tal como Northbridge, también puede
conectarse con el bus 121 del sistema. Northbridge es un grupo de
chips que se comunica con la CPU (Unidad Central de Procesamiento),
o con la unidad 120 de procesamiento del anfitrión, y que asume la
responsabilidad por las comunicaciones del puerto de gráficos
acelerados (AGP). Una o más unidades 184 de procesamiento de
gráficos (GPU) pueden comunicarse con la interfaz 182 de gráficos.
En este sentido, las GPU 184 incluyen generalmente almacenamiento
de memoria en el chip, tal como almacenamiento en registros, y las
GPU 184 se comunican con una memoria 186 de vídeo. Las GPU 184, sin
embargo, no son sino un ejemplo de un coprocesador y, por ello,
puede incluirse una gran variedad de dispositivos de coprocesamiento
en el ordenador 110. Un monitor 191 u otro tipo de dispositivo de
visualización también se conecta con el bus 121 del sistema por
medio de una interfaz, tal como una interfaz 190 de vídeo, que, a su
vez, puede comunicarse con la memoria 186 de vídeo. Además del
monitor 191, los ordenadores también pueden incluir otros
dispositivos periféricos de salida, tales como los altavoces 197 y
la impresora 196, que pueden conectarse a través de una interfaz
periférica 195 de salida.
El ordenador 110 puede operar en un entorno de
red utilizando conexiones lógicas con uno o más ordenadores
remotos, tal como un ordenador remoto 180. El ordenador remoto 180
puede ser un ordenador personal, un servidor, un encaminador, un PC
en red, un dispositivo a la par u otro nodo común de red y,
típicamente, incluye muchos de, o todos, los elementos descritos
anteriormente en relación al ordenador 110, aunque sólo un
dispositivo 181 de almacenamiento en memoria ha sido ilustrado en
la Fig. 1. Las conexiones lógicas ilustradas en la Fig. 1 incluyen
una red 171 de área local (LAN) y una red 173 de área amplia (WAN),
pero también pueden incluir otras redes. Tales entornos de red son
comunes en las oficinas, las redes de ordenadores de empresa, las
redes intranet y la red Internet.
Cuando se emplea en un entorno de red LAN, el
ordenador 110 se conecta con la LAN 171 a través de una interfaz o
adaptador 170 de red. Cuando se emplea en un entorno de red WAN, el
ordenador 110, típicamente, incluye un módem 172 u otros medios para
establecer comunicaciones por la red WAN 173, tal como Internet. El
módem 172, que puede ser interno o externo, puede conectarse con el
bus 121 del sistema a través de la interfaz 160 de entrada del
usuario, u otro mecanismo adecuado. En un entorno en red, los
módulos de programa ilustrados con respecto al ordenador 110, o
bien porciones de ellos, pueden almacenarse en el dispositivo remoto
de almacenamiento en memoria. A modo de ejemplo, y no de
limitación, la Fig. 1 ilustra los programas remotos 185 de
aplicación como residentes en el dispositivo 181 de memoria. Se
apreciará que las conexiones de red mostradas son un ejemplo, y que
pueden utilizarse otros medios de establecer un enlace de
comunicaciones entre los ordenadores.
Alguien medianamente versado en la tecnología
puede apreciar que un ordenador 110, u otro dispositivo cliente,
puede desplegarse como parte de una red de ordenadores. En este
contexto, la presente invención se refiere a cualquier sistema de
ordenadores que tenga cualquier número de unidades de memoria o de
almacenamiento, y cualquier número de aplicaciones y procesos
presentes en cualquier número de unidades o volúmenes de
almacenamiento. La presente invención puede aplicarse en un entorno
con ordenadores servidores y ordenadores clientes desplegados en un
entorno de red, con almacenamiento remoto o local. La presente
invención también puede aplicarse a un dispositivo informático
autónomo, que tenga capacidades de funcionalidad de lenguajes de
programación, interpretación y ejecución.
El procesamiento distribuido facilita el
compartir recursos y servicios de ordenador, por intercambio directo
entre dispositivos y sistemas informáticos. Estos recursos y
servicios incluyen el intercambio de información, el almacenamiento
en memoria caché, y el almacenamiento en disco para ficheros. El
procesamiento distribuido aprovecha la conectividad de red,
permitiendo a los clientes equilibrar su potencia colectiva a fin de
beneficiar la empresa común. En este aspecto, diversos dispositivos
pueden tener aplicaciones, objetos o recursos que pueden
interactuar para implicar técnicas de autenticación de la presente
invención para una o más baterías de procesos gráficos fiables.
La Fig. 2 proporciona un diagrama esquemático de
un ejemplo de entorno de procesamiento en red o distribuido. El
entorno de procesamiento distribuido comprende los objetos
informáticos 10a, 10b, etc., y los objetos o dispositivos
informáticos 110a, 110b, 110c, etc. Estos objetos pueden comprender
programas, procedimientos, almacenes de datos, lógica programable,
etc. Los objetos pueden comprender porciones de los mismos, o
distintos, dispositivos, tales como agendas electrónicas,
televisores, reproductores de MP3, ordenadores personales, etc.
Cada objeto puede comunicarse con otro objeto por medio de la red 14
de comunicaciones. Esta red puede comprender en sí misma otros
objetos informáticos y dispositivos informáticos que proporcionan
servicios al sistema de la Fig. 2. Según un aspecto de la
invención, cada objeto 10 o 110 puede contener una aplicación que
podría requerir las técnicas de autenticación de la presente
invención para la batería o baterías de procesos gráficos
fiables.
También puede apreciarse que un objeto, tal como
el 110c, puede estar alojado en otro dispositivo informático 10 o
110. Así, aunque el entorno físico ilustrado puede mostrar a los
dispositivos conectados como ordenadores, tal ilustración es un
mero ejemplo, y el entorno físico, alternativamente, puede
ilustrarse o describirse como compuesto por diversos dispositivos
digitales, tales como agendas electrónicas, televisores,
reproductores de MP3, etc.; objetos de software tales como
interfaces, objetos COM y otros similares.
Existe una gran variedad de sistemas,
componentes y configuraciones de red que brindan soporte a entornos
de procesamiento distribuido. Por ejemplo, los sistemas de
procesamiento pueden conectarse entre sí por medio de sistemas de
cableado, o inalámbricos; por redes locales, o por redes de
distribución amplia. Actualmente, muchas de las redes están
acopladas a Internet, que proporciona la infraestructura para el
procesamiento ampliamente distribuido, y que abarca muchas redes
distintas.
En entornos de redes domésticas, hay al menos
cuatro medios distintos de transporte por red, cada uno de los
cuales puede brindar soporte a un protocolo único, tal como la línea
de Energía, los medios de datos (tanto inalámbricos como
cableados), los medios de voz (p. ej., el teléfono) y los medios de
entretenimiento. La mayoría de los dispositivos de control
doméstico, tales como los interruptores de luz y los
electrodomésticos, pueden utilizar la línea de energía para su
conectividad. Los Servicios de Datos pueden ingresar al hogar como
banda ancha (p. ej., bien DSL o módem de Cable) y son accesibles
dentro del hogar empleando conectividad bien inalámbrica (p. ej.,
HomeRF o 802.11b) o bien cableada (p. ej., Home PNA, Cat 5, incluso
la línea de energía). El tráfico de voz puede ingresar al hogar
bien como cableado (p. ej., Cat 3) o bien como inalámbrico (p. ej.,
teléfonos celulares), y puede distribuirse dentro del hogar
utilizando el cableado Cat 3. Los medios de entretenimiento pueden
ingresar al hogar a través de satélite o cable y, típicamente, se
distribuyen en el hogar utilizando cable coaxial. IEEE 1394 y DVI
también están surgiendo como interconexiones digitales para grupos
de dispositivos de medios. Todos estos entornos de red, y otros que
puedan surgir como estándares de protocolo, pueden interconectarse
a fin de formar una intranet que pueda conectarse con el mundo
exterior a través de Internet. En resumen, existe una gran variedad
de fuentes distintas para el almacenamiento y la transmisión de
datos y, avanzando en consecuencia, los dispositivos informáticos
requerirán formas de proteger contenidos en todas las porciones de
la batería de procesos de procesamiento de datos.
La denominación de Internet se refiere
usualmente a la colección de redes y pasarelas que utilizan el juego
TCP/IP de protocolos, que son bien conocidos en la tecnología de
las redes de ordenadores. TCP/IP es un acrónimo de "Transport
Control Protocol/Internet Protocol" ["Protocolo de Control de
Transporte/Protocolo Intrarred"]. Internet puede describirse
como un sistema de redes de ordenadores remotos geográficamente
distribuidos, interconectados por ordenadores que ejecutan
protocolos de red que permiten a los usuarios interactuar y
compartir información por las redes. Debido a tal extendida
compartición de información, las redes remotas como Internet han
evolucionado generalmente, hasta ahora, hacia un sistema abierto
para el cual los desarrolladores pueden diseñar aplicaciones de
software a fin de realizar operaciones o servicios especializados,
esencialmente sin restricciones.
De esta manera, la infraestructura de red
permite un enjambre de topologías de red, tales como arquitecturas
cliente/servidor, par a par, o híbridas. El "cliente" es un
miembro de una clase o grupo que utiliza los servicios de otra clase
o grupo con el cual no está vinculado. Así, en informática, un
cliente es un proceso, es decir, en esencia, un conjunto de
instrucciones o tareas, que solicita un servicio suministrado por
otro programa. El proceso cliente utiliza el servicio solicitado
sin tener que "conocer" ningún detalle de operación acerca del
otro programa, o bien del servicio en sí. En una arquitectura de
cliente/servidor, en particular, en un sistema en red, un cliente es
usualmente un ordenador que accede a recursos compartidos de red,
suministrados por otro ordenador, p. ej., un servidor. En el
ejemplo de la Fig. 2, los ordenadores 110a, 110b, etc., pueden
concebirse como clientes, y el ordenador 10a, 10b, etc., puede
concebirse como el servidor, donde el servidor 10a, 10b, etc.,
mantiene los datos que se reproducen luego en los ordenadores
clientes 110a, 110b, etc.
Un servidor, típicamente, es un sistema
informático remoto accesible por una red remota, tal como Internet.
El proceso cliente puede estar activo en un primer sistema
informático, y el proceso servidor puede estar activo en un segundo
sistema informático, comunicándose entre sí por un medio de
comunicaciones, proporcionando así funcionalidad distribuida
\hbox{y permitiendo que múltiples clientes aprovechen las
capacidades de recopilación de información del servidor.}
Cliente y servidor se comunican entre sí
utilizando la funcionalidad proporcionada por una capa de protocolo.
Por ejemplo, el HTTP (Hypertext Transfer Protocol - Protocolo de
Transferencia de Hipertexto) es un protocolo común que se utiliza
conjuntamente con la WWW (World Wide Web - Máxima Malla Mundial).
Típicamente, se utiliza una dirección de red de ordenador, tal como
un URL (Universal Resource Locator - Localizador Universal de
Recurso) o una dirección de IP (Internet Protocol - Protocolo de
Internet), para identificar entre sí a los ordenadores servidores o
clientes. La dirección de red puede denominarse dirección de URL.
Por ejemplo, la comunicación puede proporcionarse por un medio de
comunicaciones. En particular, el cliente y el servidor pueden
acoplarse entre sí a través de conexiones de TCP/IP para
comunicaciones de alta capacidad.
De esta manera, la Fig. 2 ilustra un ejemplo de
entorno en red o distribuido, con un servidor en comunicación con
los ordenadores clientes a través de una red/bus, en donde puede
emplearse la presente invención. En más detalle, un cierto número
de servidores 10a, 10b, etc., se interconectan por medio de una
red/bus 14 de comunicaciones, que puede ser una red LAN, WAN,
intranet, Internet, etc., con un cierto número de dispositivos
clientes o de procesamiento remoto 110a, 110b, 110c, 110d, 110e,
etc., tales como un ordenador portátil, un ordenador de mano, un
cliente ligero, un electrodoméstico conectado en red, u otro
dispositivo, tal como una grabadora de vídeo, un televisor, un
horno, una lámpara, un calentador y otros similares, según la
presente invención. Se contempla así que la presente invención
pueda aplicarse a cualquier dispositivo informático con relación al
cual es deseable procesar, almacenar o proteger el contenido de una
fuente fiable.
En un entorno de red en el cual el bus/red 14 de
comunicaciones es Internet, por ejemplo, los servidores 10 pueden
ser servidores de Web, con los cuales los clientes 110a, 110b, 110c,
110d, 110e, etc., se comunican por medio de cualquiera entre un
cierto número de protocolos conocidos, tales como HTTP. Los
servidores 10 también pueden funcionar como clientes 110, como
puede ser característico en un entorno de procesamiento distribuido.
Las comunicaciones pueden ser por cable o inalámbricas, según
corresponda. Los dispositivos clientes 110 pueden o no comunicarse
por medio de la red/bus 14 de comunicaciones, y pueden tener
comunicaciones independientes asociadas a la misma. Por ejemplo, en
el caso de un televisor o grabadora de vídeo, puede haber o no un
aspecto vinculado con la red para el control del mismo. Cada
ordenador cliente 110 y cada ordenador servidor 10 puede estar
equipado con diversos módulos de programa u objetos 135 de
aplicaciones, y con conexiones o acceso a diversos tipos de
elementos u objetos de almacenamiento, por medio de los cuales
pueden almacenarse ficheros, o a los cuales pueden descargarse o
migrarse una o más porciones de ficheros. De esta manera, la
presente invención puede utilizarse en un entorno de red de
ordenadores que tenga ordenadores clientes 110a, 110b, etc., que
pueden acceder e interactuar con una red/bus 14 de ordenadores y con
los ordenadores servidores 10a, 10b, etc., que pueden interactuar
con los ordenadores clientes 110a, 110b, etc., y con otros
dispositivos 111 y bases de datos 20.
La Fig. 3 es un diagrama en bloques funcionales
de una realización preferida de un sistema y un procedimiento según
la invención para editar contenidos digitales.
La "edición", según se emplea aquí ese
término, se refiere a un proceso que una aplicación o servicio
ejecuta para establecer, con una entidad fiable, un conjunto de
derechos y condiciones que la entidad puede emitir para esos
contenidos, así como a quién pueden emitirse esos derechos y
condiciones. Según la invención, el proceso de edición incluye el
cifrado de los contenidos digitales y la asociación de una lista de
derechos persistentes que pueden hacerse cumplir, y que el autor de
los contenidos concibió para todos los usuarios posibles de los
contenidos. Este proceso puede llevarse a cabo de manera segura a
fin de prohibir el acceso a cualquiera de los derechos o a los
contenidos, a menos que así lo determine el autor de los
contenidos.
En una realización preferida de la invención,
pueden emplearse, en particular, tres entidades para editar
contenidos digitales seguros: una aplicación 302 de preparación de
contenidos que se ejecuta en el cliente 300 y que prepara los
contenidos para su edición, una interfaz 306 de programación de
aplicaciones (API) de gestión de derechos digitales (DRM), que
también reside en el dispositivo cliente 300, y un servidor 320 de
DRM que está acoplado, en términos de comunicación, con el cliente
300 a través de una red 330 de comunicación. En una realización
preferida de la invención, la red 330 de comunicación incluye
Internet, aunque debería entenderse que la red 330 de comunicación
podría ser cualquier red de área local o amplia, tal como una
intranet de propiedad corporativa, por ejemplo.
La aplicación 302 de preparación de contenidos
puede ser cualquier aplicación que produce contenidos digitales.
Por ejemplo, la aplicación 302 puede ser un procesador de la palabra
u otro editor que produzca ficheros de texto digital, música
digital, vídeo u otros contenidos similares. Los contenidos también
podrían incluir flujos de contenidos, tales como flujos de audio o
vídeo, de un suceso en vivo o grabado, por ejemplo. Según la
invención, la aplicación de preparación de contenidos invita al
usuario de la misma a cifrar los contenidos utilizando una clave
que el usuario proporciona. La aplicación 302 utiliza la clave para
cifrar los contenidos digitales, formando de tal manera un fichero
304 de contenidos digitales cifrados. La aplicación cliente también
invita al usuario a proporcionar datos de derechos para el fichero
304 de contenidos digitales. Los datos de derechos incluyen una
identidad respectiva para cada identidad que tiene derechos en los
contenidos digitales. Tal entidad puede ser, por ejemplo, un
individuo, una clase de individuos, o un dispositivo. Para cada tal
entidad, los datos de derechos también incluyen una lista de
derechos que esa entidad tiene en los contenidos, y cualesquiera
condiciones que puedan imponerse sobre cualquiera, o sobre todos
esos derechos. Tales derechos pueden incluir el derecho de leer,
editar, copiar, imprimir, etc., los contenidos digitales. Además,
los derechos pueden ser inclusivos o exclusivos. Los derechos
inclusivos indican que un usuario especificado tiene un derecho
especificado en los contenidos (p. ej., el usuario puede editar los
contenidos digitales). Los derechos exclusivos indican que un
usuario tiene todos los derechos en los contenidos, excepto aquellos
especificados (p. ej., el usuario puede hacer cualquier cosa con los
contenidos digitales, excepto copiarlos).
Según una realización de la invención, la API
cliente 306 puede pasar los contenidos digitales cifrados y los
datos de derechos al servidor 320 de DRM. Utilizando un proceso que
se describe en detalle a continuación, el servidor 320 de DRM
determina si puede hacer cumplir los derechos que el usuario ha
asignado y, en ese caso, el servidor 320 de DRM firma los datos de
derechos a fin de formar una etiqueta firmada 308 de derechos
(SRL). En general, sin embargo, cualquier entidad fiable puede
firmar los datos de derechos, utilizando, preferiblemente, una
clave fiable para el servidor 320 de DRM. Por ejemplo, un cliente
puede firmar los datos de derechos utilizando una clave
proporcionada por el servidor 320 de DRM.
La etiqueta 308 de derechos puede incluir datos
que representan la descripción de derechos, la clave de los
contenidos cifrados y la firma digital sobre la descripción de
derechos y la clave de los contenidos cifrados. Si el servidor de
DRM está firmando la etiqueta correcta, pasa la etiqueta firmada 308
de derechos al cliente, a través de la API cliente 306, que
almacena la etiqueta firmada 308 de derechos en el dispositivo
cliente 300. La aplicación 302 de preparación de contenidos asocia
entonces la etiqueta firmada 308 de derechos al fichero 304 de
contenidos digitales cifrados. Por ejemplo, la SRL 308 puede
concatenarse con el fichero de contenidos digitales cifrados a fin
de formar un fichero 310 de contenidos con gestión de derechos. En
general, sin embargo, los datos de derechos no necesitan combinarse
con los contenidos digitales. Por ejemplo, los datos de derechos
podrían almacenarse en una ubicación conocida, y una referencia a
los datos de derechos almacenados podría combinarse con los
contenidos digitales cifrados. La referencia podría incluir un
identificador que indica dónde están almacenados los datos de
derechos (p. ej., el almacén de datos que contiene los datos de
derechos), y un identificador que corresponde a aquellos datos de
derechos específicos en esa ubicación específica de almacenamiento
(p. ej., que identifica el fichero que contiene los datos
específicos de derechos de interés). Los contenidos 310 con gestión
de derechos pueden entregarse entonces a cualquiera en cualquier
parte, y sólo aquellas entidades que tienen derechos para consumir
los contenidos pueden consumir los contenidos, y sólo de acuerdo con
los derechos que les fueron concedidos.
La Fig. 4 es un diagrama de flujo de un ejemplo
de procedimiento 400 según la invención, para contenidos digitales
con gestión de derechos de edición, en el cual la etiqueta de
derechos está firmada por un servidor de DRM. Debería entenderse,
sin embargo, que esta realización es un mero ejemplo, y que la
etiqueta de derechos puede ser firmada, en general, por cualquier
entidad fiable. Generalmente, un procedimiento según la invención
para editar contenidos digitales puede incluir: cifrar los
contenidos digitales utilizando una clave de contenidos (CK),
generar una descripción de derechos asociada con los contenidos
digitales, cifrar la clave de contenidos (CK) según una clave
pública para un servidor de DRM (PU-DRM) a fin de
obtener el resultado (PU-DRM(CK)), y crear
una firma digital basada en una clave privada
(PR-DRM) correspondiente
\hbox{a
(PU-DRM) por 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 contenidos (CK) que se emplea para cifrar los contenidos
digitales. Preferiblemente, la clave de contenidos (CK) es una clave
simétrica, aunque, en general, puede utilizarse cualquier clave
para cifrar los contenidos digitales. Los algoritmos de clave
simétrica, que a veces se denominan algoritmos de "clave
secreta", utilizan la misma clave para descifrar un mensaje que
la que utilizan para cifrar el mensaje. Por esa razón, se prefiere
que la (CK) se mantenga secreta. La compartición de (CK) entre
remitente y receptor debería hacerse muy cuidadosamente, a fin de
evitar la intercepción no autorizada de tal (CK). Debido a que la
(CK) está compartida entre el cifrador y el descifrador, la (CK) se
comunica, preferiblemente, antes de que se transmita cualquier
mensaje cifrado.
Varios algoritmos de generación de claves
simétricas son bien conocidos en la tecnología. En una realización
preferida, se emplea el DES (Data Encryption Standard - Estándar de
Cifrado de Datos), aunque debería entenderse que podría utilizarse
cualquier algoritmo simétrico. Los ejemplos de tales algoritmos de
claves simétricas incluyen, sin limitación,
Triple-DES, el IDEA (International Data Encryption
Algorithm - Algoritmo Internacional de Cifrado de Datos), Cast,
Cast-128, RC4, RC5 y SkipJack.
En la etapa 404, la aplicación 302 cifra los
contenidos digitales con la clave simétrica de contenidos (CK) a
fin de formar los contenidos digitales cifrados 304, que pueden
grabarse utilizando la notación (CK(contenidos)). El autor
que utiliza la aplicación 302 también puede generar datos de
derechos asociados a los contenidos digitales. Los datos de derechos
pueden incluir una lista de entidades que estarán autorizadas a
consumir los contenidos, y los derechos específicos que cada una de
las entidades posee con respecto a los contenidos, junto con
cualesquiera condiciones que puedan imponerse sobre esos derechos.
Tales derechos, por ejemplo, pueden incluir visualizar los
contenidos, imprimir los contenidos, etc. La aplicación 302
proporciona los datos de derechos a la API 306. Un ejemplo de datos
de derechos en formato XML/XrML se adjunta a la presente como el
Apéndice 1.
En la etapa 406, la API 306 genera una segunda
clave de cifrado (DES1), que se utiliza para cifrar la clave de
contenidos (CK). Preferiblemente, (DES1) también es una clave
simétrica. En la etapa 408, la API 306 cifra la (CK) con (DES1)
para dar como resultado (DES1(CK)). En la etapa 410, la API
306 descarta la (CK), dando como resultado que la (CK) puede
obtenerse ahora sólo descifrando (DES1(CK)). A fin de
garantizar que (CK(contenidos)) está protegida a un servidor
central 320 de DRM, y que todas las "solicitudes de licencia"
para los contenidos se hacen centralmente según los datos de
derechos, la API 306, en la etapa 412, se pone en contacto con el
servidor provisto 320 de DRM y extrae la clave pública
(PU-DRM) del mismo. En la etapa 414, la API 306
cifra (DES1) con (PU-DRM) para dar como resultado
(PU-DRM(DES1)). De esta manera, la (CK) puede
protegerse según (PU-DRM), a fin de garantizar que
el servidor 320 de DRM es la única entidad que podrá obtener acceso
a la (CK), según lo requerido para descifrar
(CK(contenido)). En la etapa 416, la API 306 cifra los datos
de derechos (es decir, la lista de entidades autorizadas y los
respectivos derechos y condiciones asociadas a cada entidad
autorizada en la lista) con (DES1) para dar como resultado
(DES1(datosdederechos)).
En una realización alternativa, la (CK) puede
emplearse a fin de cifrar directamente los datos de derechos, para
dar como resultado (CK(datosdederechos)), y renunciar
completamente por ello al empleo de (DES1). Sin embargo, el empleo
de (DES1) para cifrar los datos de derechos permite a tal (DES1)
adecuarse a cualquier algoritmo específico que pudiera ser obligado
para el servidor de DRM, mientras que la (CK) podría ser
especificada por una entidad independiente del servidor de DRM, y
podría no ser tan obligada para el mismo.
En la etapa 418, la aplicación 302 de protección
de contenidos puede despachar (PU-DRM(DES1))
y (DES1(datosdederechos)) al servidor 320 de DRM como una
etiqueta de derechos para su firma. Alternativamente, el cliente
mismo puede firmar los datos de derechos. Si los datos de derechos
están siendo despachados al servidor para su firma, entonces, en la
etapa 420, el servidor 320 de DRM accede a los datos de derechos y
verifica que puede hacer cumplir los derechos y condiciones en la
etiqueta de datos despachada. A fin de verificar que puede hacer
cumplir los datos de derechos, el servidor 320 de DRM aplica
(PR-DRM) a (PU-DRM(DES1))
para dar como resultado (DES1), y luego aplica (DES1) a
(DES1(datosdederechos)) para dar como resultado los datos de
derechos en limpio. El servidor 320 puede entonces efectuar
cualquier comprobación de criterios a fin de verificar que los
usuarios, derechos y condiciones especificados en los datos de
derechos están dentro de cualquier criterio instituido por el
servidor 320. El servidor 320 firma la etiqueta de derechos
originalmente despachada, incluyendo
(PU-DRM(DES1)) y
(DES1(datosdederechos)) para dar como resultado la etiqueta
firmada 308 de derechos (SRL), donde la firma se basa en la clave
privada del servidor 320 de DRM (PR-DRM), y devuelve
la SRL 308 a la API 306, la cual presenta entonces la SRL 308
devuelta a la aplicación cliente 302.
La SRL 308 es un documento firmado digitalmente,
lo cual lo hace resistente a la manipulación. Además, la SRL 308 es
independiente del tipo de clave y algoritmo efectivamente utilizados
para cifrar los contenidos, pero mantiene la relación fuerte de 1 a
1 con los contenidos que está protegiendo. Con referencia ahora a la
Fig. 4A, en una realización de la presente invención, la SRL 308
puede incluir información sobre los contenidos que es la base de la
SRL 308, incluyendo tal vez un identificador de los contenidos;
información sobre el servidor de DRM que firma la SRL 308,
incluyendo (PU-DRM(DES1)) e información de
referencia, tal como una URL para localizar el servidor de DRM en
una red, e información de resguardo si la URL falla; información
que describe la SRL 308 en sí misma; (DES1(datosdederechos));
(DES1(CK)); y S (PR-DRM), entre otras cosas.
Un ejemplo de SRL 308 en XML/XrML se adjunta a la presente como el
Apéndice 2.
Al garantizar que una entidad fiable firma los
datos de derechos para crear una etiqueta 308 de derechos firmada,
el servidor de DRM está afirmando que emitirá licencias para los
contenidos según los términos estipulados por el editor, según lo
descrito en los datos de derechos de la etiqueta 308 de derechos.
Como debería apreciarse, a un usuario se le requiere que obtenga
una licencia a fin de reproducir los contenidos, especialmente
puesto que la licencia contiene la clave de contenidos (CK). Cuando
un usuario quiere obtener una licencia para los contenidos
cifrados, el usuario puede presentar una solicitud de licencia que
incluya la SRL 308 para los contenidos, y un certificado que
verifica las credenciales del usuario ante el servidor 320 de DRM, o
ante otra entidad emisora de licencia. La entidad emisora de
licencia puede entonces descifrar
(PU-DRM(DES1)) y
(DES1(datosdederechos)) a fin de producir los datos de
derechos, enumerar todos los derechos concedidos por el autor (si
lo hubiera) a la entidad solicitante de licencia, y construir una
licencia con sólo esos derechos específicos.
Preferiblemente, al recibir la aplicación 302 la
SRL 308, tal aplicación 302 concatena la etiqueta 308 firmada de
derechos con el correspondiente (CK(contenidos)) 304, a fin
de formar los contenidos digitales con gestión de derechos.
Alternativamente, los datos de derechos pueden almacenarse en una
localidad conocida, con una referencia a esa localidad
proporcionada con los contenidos digitales cifrados. De esta manera,
una aplicación reproductora que esté habilitada por DRM puede
descubrir la etiqueta 308 firmada de derechos a través de la
porción de contenidos que la aplicación reproductora está intentando
reproducir. Este descubrimiento lanza a la aplicación reproductora
a iniciar una solicitud de licencia ante el servidor 320 de
licencias de DRM. La aplicación editora 302 puede almacenar un URL
del servidor 320 de licencias de DRM, por ejemplo, o bien el
servidor 320 de licencias de DRM puede insertar su propio URL como
una porción de metadatos en la etiqueta de derechos antes de
firmarla digitalmente, para que la API 306, cliente de DRM, llamada
por la aplicación reproductora, pueda identificar el servidor 320
correcto de licencias de DRM. Preferiblemente, un identificador
único, tal como un identificador globalmente único (GUID), por
ejemplo, se incluye en la etiqueta de derechos antes de ser
firmada.
En una realización preferida de la invención,
puede utilizarse el protocolo sencillo de acceso a objetos (SOAP)
para la comunicación entre la aplicación 302 de protección de
contenidos, o la aplicación reproductora, y el servidor 320 de DRM.
Además, pueden proporcionarse bibliotecas de las API, tales como la
API 306, para que a las aplicaciones, tales como la aplicación 302,
no se les requiera implementar la parte cliente del protocolo de
DRM, sino que puedan tan sólo hacer llamadas locales a las API.
Preferiblemente, se utiliza XrML, un lenguaje XML, para especificar
descripciones de derechos, licencias y etiquetas de derechos para
contenidos digitales, aunque debería entenderse que puede emplearse
cualquier formato adecuado para la descripción de derechos y de
otros datos.
La Fig. 5 es un diagrama en bloques funcionales
de una realización preferida de un sistema y un procedimiento según
la invención, para contenidos digitales con gestión de derechos de
licencia. "Licenciar", según se utiliza aquí ese término, se
refiere a un proceso que ejecuta una aplicación o un servicio a fin
de solicitar y recibir una licencia que permitirá que una entidad
nombrada en la licencia consuma los contenidos según los términos
especificados en la licencia. Los datos de entrada al proceso
licenciador pueden incluir la etiqueta firmada 308 de derechos
(SRL) asociada a los contenidos para los cuales se solicita una
licencia, y el certificado o certificados de clave pública de
la(s) entidad(es)
para la(s) cual(es) se solicita la licencia. Observe que la entidad que solicita una licencia no debe necesariamente ser la entidad para la cual se está solicitando una licencia. Típicamente, una licencia incluye la descripción de derechos de la SRL 308, una clave cifrada que puede descifrar los contenidos cifrados, y una firma digital sobre la descripción de derechos y la clave cifrada. La firma digital asegura que las entidades y derechos nombrados son
legítimos.
para la(s) cual(es) se solicita la licencia. Observe que la entidad que solicita una licencia no debe necesariamente ser la entidad para la cual se está solicitando una licencia. Típicamente, una licencia incluye la descripción de derechos de la SRL 308, una clave cifrada que puede descifrar los contenidos cifrados, y una firma digital sobre la descripción de derechos y la clave cifrada. La firma digital asegura que las entidades y derechos nombrados son
legítimos.
Una manera para que la aplicación 302 consuma
los contenidos 310 con gestión de derechos es que la API cliente
306 remita la etiqueta 308 firmada de derechos de los contenidos 310
con gestión de derechos al servidor 320 de DRM por medio de la red
330 de comunicaciones. La ubicación del servidor 320 de DRM puede
hallarse, por ejemplo, en la información de referencia en la SRL
308. En tal realización, el servidor 320 de licencias de DRM, a
través de un proceso que se describe en detalle a continuación,
puede utilizar la descripción de derechos en la etiqueta de
derechos para determinar si puede emitir una licencia y, en ese
caso, derivar la descripción de derechos a incluir con la licencia.
Como se ha descrito anteriormente, la etiqueta 308 de derechos
contiene la clave de contenidos (CK) cifrada según la clave pública
del servidor 320 de DRM (PU-DRM) (es decir,
(PU-DRM(CK))). En el proceso de emitir una
licencia, el servidor 320 de DRM descifra de forma segura este valor
a fin de obtener (CK). Entonces, utiliza la clave publica
(PU-ENTIDAD) en el certificado de clave pública que
se pasa en la solicitud de licencia para volver a cifrar (CK) (es
decir, (PU-ENTIDAD(CK))). La
(PU-ENTIDAD(CK)) recién cifrada es lo que el
servidor 320 coloca en la licencia. De esta manera, la licencia
puede devolverse al llamador sin el riesgo de exponer (CK), ya que
sólo el poseedor de la clave privada asociada
(PR-ENTIDAD) puede recuperar (CK) a partir de
(PU-ENTIDAD(CK)). La API cliente 306 utiliza
entonces (CK) para descifrar los contenidos cifrados, a fin de
formar los contenidos digitales descifrados 312. La aplicación
cliente 302 puede utilizar entonces los contenidos digitales
descifrados 312 según los derechos que se proporcionan en la
licencia.
Alternativamente, un cliente, tal como el
cliente editor, por ejemplo, puede emitir su propia licencia para
consumir los contenidos. En tal realización, puede ejecutarse un
proceso garantizado en el ordenador cliente, que brinda al cliente
la(s) clave(s) necesaria(s) para descifrar los
contenidos digitales, en circunstancias adecuadas.
Las Figs. 6A y 6B proporcionan un diagrama de
flujo de una realización preferida de un procedimiento 600 según la
invención, para licenciar contenidos digitales con gestión de
derechos. Según la invención, una entidad solicitante puede
despachar una solicitud de licencia a nombre de uno o más
licenciatarios potenciales. La entidad solicitante puede o no ser
uno de los licenciatarios potenciales. Un licenciatario potencial
puede ser una persona, un grupo, un dispositivo, o cualquier otra
entidad que pueda consumir los contenidos de cualquier manera. El
procedimiento 600 se describirá ahora con referencia a una
realización en la cual un servidor de DRM procesa la solicitud de
licencia, aunque debería entenderse que el procesamiento de la
solicitud de licencia también podría realizarse en el cliente, y
emitir el cliente directamente las licencias.
En la etapa 602, una entidad emisora de
licencias, tal como un servidor de DRM, por ejemplo, recibe una
solicitud de licencia. Preferiblemente, una solicitud de licencia
incluye bien un certificado de clave pública o bien una identidad
para cada una de la(s) licencia(s)
solicitada(s). El protocolo SOAP para una realización
preferida de una solicitud de licencia es:
\vskip1.000000\baselineskip
En la etapa 604, la entidad solicitante (es
decir, la entidad que efectúa la solicitud de licencia) es
autenticada. Según una realización de la invención, la entidad
emisora de licencia puede configurarse para utilizar autenticación
de protocolo (p. ej., interpelación-respuesta) a fin
de determinar la identidad de la entidad solicitante, o bien puede
configurarse para no requerir la autenticación de la entidad
solicitante (lo que también se conoce como "permitir
autenticación anónima"). Allí donde se requiere la autenticación,
puede utilizarse cualquier tipo de método de autenticación (p. ej.,
el método de interpelación-respuesta mencionado
anteriormente, un método de identificador de usuario y contraseña
como MICROSOFT .NET, PASSPORT, autorización de WINDOWS, x509, etc.).
Preferiblemente, se permite la autenticación anónima, así como el
brindar soporte a cualquier método de autenticación de protocolo
respaldado por sistemas integrados de información. El resultado de
la etapa de autenticación será una identidad, tal como una
identidad "anónima" (para la autenticación anónima), o bien
una identidad de cuenta personal, por ejemplo. Si la solicitud de
licencia no puede autenticarse por el motivo que sea, se devuelve un
código de error y no se concede ninguna licencia.
En la etapa 606, la entidad autenticada es
autorizada - es decir, se determina si a la entidad autenticada en
la etapa 608 se le permite solicitar una licencia (ya sea para sí
misma o en nombre de otra entidad). Preferiblemente, la entidad
emisora de licencia almacena una lista de entidades a las que se
permite (o no se permite) solicitar una licencia. En una
realización preferida, una identidad en esta lista de identidades es
la identidad de la entidad que hace la solicitud, antes que la
identidad de la entidad para la cual se está solicitando una
licencia, aunque podría ser cualquiera de las dos. Por ejemplo, a
una identidad de cuenta personal puede no permitírsele realizar
directamente una solicitud de licencia, pero un proceso servidor
fiable puede realizar una solicitud de licencia en nombre de
tal
entidad.
entidad.
Según la invención, la solicitud de licencia
puede incluir bien un certificado de clave pública o bien una
identidad para cada potencial licenciatario. Si una licencia se
solicita sólo para un licenciatario, sólo se nombra un certificado
o identidad. Si una licencia se solicita para una pluralidad de
licenciatarios, puede nombrarse un certificado o una identidad para
cada licenciatario potencial.
Preferiblemente, la entidad emisora de licencia
tiene un certificado de clave pública para cada licenciatario
válido. Sin embargo, una aplicación 302 puede querer generar una
licencia para un usuario dado, pero la aplicación 302 podría 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
emisora de licencia puede invocar un componente acoplable de
certificados registrados que realiza una búsqueda en un servicio de
directorios y que devuelve el certificado de clave pública del
usuario correcto.
Si, en la etapa 608, la entidad emisora
determina que el certificado de clave pública no está incluido en
la solicitud de licencia, entonces la entidad emisora utiliza la
identidad especificada para realizar una búsqueda, en un servicio o
base de datos de directorios, del certificado de clave pública
correspondiente. Si, en la etapa 610, la entidad emisora determina
que el certificado está en el directorio, entonces, en la etapa
612, se extrae el certificado. En una realización preferida, se
utiliza un componente acoplable de certificados para extraer
certificados de clave pública de un servicio de directorio, por
medio de un protocolo de acceso a directorios. Si no puede hallarse
un certificado para un licenciatario potencial dado, ya sea en la
solicitud o en el directorio, entonces el servidor de licencias no
genera una licencia para ese licenciatario potencial y, en la etapa
614, se devuelve un código de error a la entidad
solicitante.
solicitante.
Suponiendo que la entidad emisora de licencias
tiene un certificado de clave pública para al menos un licenciatario
potencial, entonces, en la etapa 616, la entidad emisora valida la
fiabilidad de los certificados del licenciatario. Preferiblemente,
la entidad emisora está configurada con un conjunto de certificados
de emisor fiable, y determina si el emisor del certificado del
licenciatario está en la lista de emisores fiables. Si, en la etapa
616, la entidad emisora determina que el emisor del certificado del
licenciatario no está en la lista de emisores fiables, entonces la
solicitud fracasa para ese licenciatario, y un código de error se
genera en la etapa 614. Así, ningún licenciatario potencial cuyo
certificado no esté emitido por un emisor fiable recibiría una
licencia.
Además, la entidad emisora, preferiblemente,
lleva a cabo la validación de la firma digital para todas las
entidades en la cadena de certificados que van desde los
certificados del emisor fiable hasta los certificados de clave
pública del licenciatario individual. El proceso de validar las
firmas digitales en una cadena es un algoritmo bien conocido. Si el
certificado de clave pública para un licenciatario potencial dado no
es validado, o si un certificado en la cadena no es validado, el
licenciatario potencial no es fiable y, por lo tanto, no se emite
una licencia a ese licenciatario potencial. En caso contrario, en la
etapa 618, puede emitirse una licencia. El proceso se repite en la
etapa 620 hasta que se hayan procesado todas las entidades para las
cuales se ha solicitado una
licencia.
licencia.
Según se muestra en la Fig. 6B, la entidad
emisora de licencias procede a validar la etiqueta firmada 308 de
derechos que se recibe en la solicitud de licencia. En una
realización preferida, la entidad emisora puede utilizar un
componente acoplable de etiquetas de derechos, y una base de datos
de trastienda, para almacenar en el servidor una copia maestra de
toda etiqueta de derechos firmada por la entidad emisora. Las
etiquetas de derechos se identifican por el GUID colocado en ellas
en su edición. En tiempo de emisión de licencias (en la etapa 622),
la entidad emisora analiza sintácticamente la etiqueta de derechos
ingresada en la solicitud de licencia y extrae su GUID. Luego pasa
este GUID al componente acoplable de etiquetas de derechos, el cual
emite una consulta sobre la base de datos a fin de extraer una copia
de la etiqueta maestra de derechos. La etiqueta maestra de derechos
podría estar más actualizada que la copia de la etiqueta de derechos
enviada en la solicitud de licencia, y será la etiqueta de derechos
empleada en la solicitud en las etapas que siguen. Si no se halla
ninguna etiqueta de derechos en la base de datos basándose en el
GUID, la entidad emisora verifica sus criterios, en la etapa 624,
para determinar si aún se permite emitir una licencia basada en la
etiqueta de derechos en la solicitud. Si los criterios no lo
permiten, la solicitud de licencia fracasará en la etapa 626, y un
código de error se devolverá a la API 306 en la etapa
628.
628.
En la etapa 630, la entidad emisora de licencias
valida la etiqueta 308 de derechos. Se valida la firma digital en
la etiqueta de derechos y, si la entidad emisora de licencias no es
la emisora de la etiqueta de derechos (la entidad que la firmó),
entonces la entidad emisora de licencias determina si el emisor de
la etiqueta de derechos es otra entidad fiable (p. ej., una entidad
con la cual la entidad emisora de licencias está habilitada para
compartir material de claves). Si la etiqueta de derechos no es
validada, o si no está emitida por una entidad fiable, entonces la
solicitud de licencia fracasa en la etapa 626, y un código de error
se devolverá a la API 306 en la etapa
628.
628.
Una vez que han tenido lugar todas las
validaciones, la entidad emisora de licencias traduce la etiqueta
308 de derechos a una licencia para cada uno de los licenciatarios
aprobados. En la etapa 632, la entidad emisora de licencias genera
la respectiva descripción de derechos para la licencia a emitir a
cada licenciatario. Para cada licenciatario, la entidad emisora
evalúa la identidad nombrada en el certificado de clave pública de
ese licenciatario con respecto a las identidades nombradas en la
descripción de derechos en la etiqueta de derechos. La descripción
de derechos asigna a cada derecho, o conjunto de derechos, un
conjunto de los identificadores que pueden ejercer ese derecho, o
conjunto de derechos, en una licencia. Para cada derecho, o conjunto
de derechos, con los cuales está asociada la identidad de este
licenciatario, ese derecho, o conjunto de derechos, se copia en una
nueva estructura de datos para la licencia. La estructura de datos
resultante es la descripción de derechos en la licencia para ese
licenciatario específico. Como parte de este proceso, la entidad
emisora de licencias evalúa cualquier precondición que pudiera estar
asociada a cualquier 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 temporal asociada a él, que
limita a la entidad emisora de licencias para emitir una licencia
después de un tiempo especificado. En este caso, la entidad emisora
necesitaría comprobar la hora actual y, si es posterior a la hora
especificada en la precondición, entonces la entidad emisora no
podría conceder ese derecho al licenciatario, incluso si la
identidad de ese licenciatario estuviera asociada a ese
derecho.
derecho.
En la etapa 636, la entidad emisora toma
(PU-DRM(DES1)) y (DES1(CK)) de la
etiqueta 308 de derechos y aplica (PR-DRM) para
obtener (CK). La entidad emisora vuelve entonces a cifrar (CK)
utilizando (PU-ENTIDAD), el certificado de clave
pública del licenciatario, para obtener como resultado
(PU-ENTIDAD(CK)). En la etapa 638, la entidad
emisora concatena la descripción de datos generada con
(PU-ENTIDAD(CK)), y firma digitalmente la
estructura de datos resultante, utilizando
(PR-DRM). Esta estructura de datos firmada es la
licencia para este licenciatario específico.
Cuando, en la etapa 640, la entidad emisora
determina que no hay más licencias que generar para esa solicitud
específica, habrá generado cero o más licencias. Las licencias
generadas se devuelven a la entidad solicitante, en la etapa 642,
junto con la cadena de certificados asociada a esas licencias (p.
ej., el propio certificado de clave pública del servidor, así como
el certificado que emitió su certificado, y así sucesivamente).
El protocolo SOAP para una realización preferida
de una respuesta de licencia es el siguiente:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
(Protocolo pasa a página
siguiente)
En una realización preferida de un sistema según
la invención, puede utilizarse una pluralidad de claves de
licenciante. En tal realización, la clave de contenidos (CK) que
viaja cifrada, a través de la etiqueta 308 de derechos, y hacia la
licencia, puede efectivamente ser cualquier dato arbitrario. Una
variación especialmente útil es utilizar una pluralidad de
distintas claves cifradas de contenidos (CK), asociadas,
respectivamente, a distintos derechos o distintos titulares en la
descripción de derechos. Por ejemplo, las versiones digitales de
canciones en un álbum podrían cifrarse todas con distintas claves
(CK). Estas claves (CK) se incluirían en la misma etiqueta de
derechos, pero un titular puede tener el derecho de reproducir una
de las canciones (p. ej., podría tener sólo derechos para obtener
la única clave en su licencia), mientras que un segundo titular
podría tener derechos para reproducir todas las canciones (tendría
derechos para obtener todas las claves en su licencia).
Preferiblemente, un sistema según la invención
permite a las aplicaciones o usuarios editores nombrar grupos o
clases de licenciatarios en una etiqueta 308 de derechos. En tal
realización, la entidad emisora de licencias evaluará todos los
grupos o clases nombrados en la etiqueta de derechos a fin de
determinar si la identidad del licenciatario actual es un miembro
de aquellos grupos o clases. Si se halla tal miembro en un grupo o
clase nombrada, la entidad emisora podría añadir los derechos, o
conjuntos de derechos, asociados al grupo o clase, a la estructura
de datos de descripción de derechos utilizada para la licencia.
En una realización preferida de la invención,
las interfaces del protocolo de edición y licencia en el servidor
de DRM dan soporte a la autenticación y la autorización de la
aplicación o usuario invocante, y la consola administrativa para el
servidor de DRM permite a un administrador generar una lista de
control de acceso tanto para la interfaz de licencia como para la
de edición. Esto permite al cliente del servidor aplicar criterios
en cuanto a cuáles usuarios o aplicaciones se les permite bien
editar, bien licenciar, o ambas cosas.
En una realización de la presente invención, la
SRL 308 puede ser "reeditada" si al usuario de los contenidos
se le ha concedido el permiso suficiente para hacerlo. Es decir, si
se le permite, el usuario puede alterar datos de derechos dentro de
la SRL 308. Es de hacer notar que tal permiso de alterar los datos
de derechos debería concederse muy discreta y juiciosamente,
especialmente puesto que un usuario con permiso para alterar los
datos de derechos puede, en esencia, concederse a sí mismo amplios
derechos con respecto a los contenidos asociados. Es concebible que
tal usuario podría incluso concederse a sí mismo el derecho de
exponer los contenidos y remitir los mismos al mundo entero.
Aquí, el permiso para alterar se señala
incluyendo dentro de los datos de derechos en la SRL 308 una
indicación de que un usuario específico, o una clase de usuarios,
puede, efectivamente, alterar o "reeditar" los datos de
derechos y la etiqueta 308 de derechos. Cuando el servidor 320 de
DRM recibe tal SRL 308 con tal permiso con relación a una solicitud
de una licencia, el servidor 320 de DRM incluye dentro de la
licencia solicitada para el usuario la clave simétrica (DES1)
cifrada según la clave pública del usuario (es decir,
PU-ENTIDAD) para dar como resultado
(PU-ENTIDAD(DES1)).
De esta manera, para editar los datos de
derechos dentro de la SRL 308, y volviendo ahora a la Fig. 7, el
usuario extrae (PU-ENTIDAD(DES1)) de la
licencia (etapa 701), aplica al mismo (PR-ENTIDAD)
para obtener como resultado (DES1) (etapa 703), extrae
(DES1(datosdederechos)) de la SRL 308 (etapa 705) y aplica
(DES1) al mismo para obtener como resultado los datos de derechos
(etapa 707). A continuación, el usuario altera los datos de
derechos según desee (etapa 709) y despacha los datos de derechos
alterados al servidor 320 de DRM de la manera estipulada en
relación con la Fig. 4, a fin de obtener una etiqueta firmada 308 de
derechos (etapa 711). Por supuesto, aquí, la etiqueta firmada 308
de derechos es efectivamente una SRL 308 reeditada y, en
consecuencia, una vez que la SRL 308 es recibida (etapa 713), el
usuario desgaja la SRL 308 original concatenada a los contenidos
asociados (etapa 715) y luego concatena la SRL 308 reeditada a tales
contenidos (etapa 717).
De esta manera y, como puede apreciarse, la
reedición de una SRL 308 permite a un usuario actualizar los datos
de derechos en la SRL 308, incluyendo los derechos, condiciones y
usuarios, sin tener que alterar los contenidos asociados. En
particular, la reedición no requiere volver a cifrar los contenidos
asociados con una nueva (CK). Además, la reedición no requiere
generar una nueva SRL desde cero, especialmente puesto que la SRL
308 original tiene muchos elementos en sí misma que pueden copiarse
a la nueva SRL 308.
En una realización de la presente invención, la
SRL 308 puede ser firmada por el mismo usuario solicitante. En
consecuencia, el usuario no necesita ponerse en contacto con el
servidor 320 de DRM a fin de obtener una SRL 308 para una porción
asociada de contenidos. Como resultado, la autoedición puede también
denominarse edición fuera de línea. En tal realización, puede
requerirse a un usuario que se ponga en contacto con un servidor
320 de DRM a fin de solicitar una licencia basada en tal SRL 308
autoeditada. También debería entenderse que una entidad editora
puede estar habilitada para emitir sus propias licencias.
En particular, y con referencia ahora a la Fig.
8, en la realización, un usuario se da primero de alta para
autoeditar, recibiendo desde un servidor 320 DRM un certificado 810
de DRM, que incluye una clave pública (PU-CERT) y
una clave privada correspondiente (PR-CERT), cifrada
según la clave pública del usuario (PU-ENTIDAD),
para dar como resultado
(PU-ENTIDAD(PR-CERT)). El
certificado debería estar firmado con la clave privada del servidor
320 de DRM (PR-DRM), de manera tal que el servidor
320 de DRM pueda verificar el mismo, como se expondrá en más
detalle más adelante. Como puede apreciarse, el certificado 810 de
DRM autoriza al usuario a autoeditar. Como también puede
apreciarse, el par de claves (PU-CERT,
PR-CERT) son distintas del par
(PU-ENTIDAD, PR-ENTIDAD), y se
emplean específicamente para la autoedición. Observe que el par de
claves (PU-CERT, PR-CERT) puede
dejarse de lado, en cuyo caso el certificado 810 de DRM incluye
sólo la clave pública del usuario (PU-ENTIDAD) y
está firmado con la clave privada del servidor 320 de DRM
(PR-DRM), de forma tal que el servidor 320 de DRM
pueda verificar el mismo.
La autoedición difiere de la edición, según se
muestra en la Fig. 4, en que el usuario, esencialmente, toma el
lugar del servidor 320 de DRM con respecto a las etapas llevadas a
cabo por el mismo. Significativamente, el usuario firma la etiqueta
de derechos despachada, que incluye
(PU-DRM(DES1)) y
(DES1(datosdederechos)), con (PR-CERT),
según ha sido obtenida a partir del certificado 810 de DRM (es
decir, S (PR-CERT)) para obtener como resultado la
etiqueta firmada 308 de derechos (SRL). Como debería apreciarse, el
usuario obtiene (PR-CERT) del certificado 810 de
DRM obteniendo
(PU-ENTIDAD(PR-CERT)) de tal
certificado 810 de DRM y aplicando (PR-ENTIDAD) al
mismo. Observe, sin embargo, que el usuario no puede verificar que
el servidor 320 de DRM puede hacer cumplir los derechos en la
etiqueta de derechos despachada, especialmente puesto que el usuario
no tiene un (PR-DRM) para aplicarlo a
(PU-DRM(DES1)). En consecuencia, el servidor
320 de DRM debería realizar por sí mismo la verificación en el
momento en que se solicita una licencia, basándose en la SRL 308
autoeditada.
Una vez que el usuario autoedita la SRL 308, el
usuario concatena tal SRL 308 autoeditada y el certificado 810 de
DRM, empleado para producir la misma, a los contenidos, y tales
contenidos, con la SRL 308 y el certificado 810 de DRM, se
distribuyen a otro usuario. A continuación, el otro usuario solicita
y obtiene una licencia para los contenidos, del servidor 320 de
DRM, de esencialmente la misma manera que se muestra en las Figs.
6A y 6B. Aquí, sin embargo, el usuario solicitante de licencia
despacha al servidor 320 de DRM tanto la SRL 308 autoeditada como
el certificado 810 de DRM, según están concatenados a los
contenidos. El servidor 320 de DRM verifica entonces S
(PR-DRM) en el certificado 810 de DRM basándose en
el (PU-DRM) correspondiente, y obtiene
(PU-CERT) del certificado 810 de DRM. El servidor
320 de DRM verifica entonces S (PR-CERT) en la SRL
308, basándose en el (PU-CERT) obtenido, y continúa
como antes. Observe, sin embargo, que, dado que el usuario no ha
verificado que el servidor 320 de DRM pueda hacer cumplir los
derechos en la SRL 308 y, como se ha estipulado anteriormente, el
servidor 320 de DRM debería llevar a cabo por sí mismo la
verificación en este momento.
Como se ha estipulado anteriormente, un usuario
está dotado de la libertad de crear prácticamente cualquier variedad
o especie de datos de derechos en una etiqueta de derechos,
definiendo usuarios o clases de usuarios, definiendo derechos para
cada usuario o clase de usuarios definidos, y definiendo luego
cualesquiera condiciones de empleo. Sin embargo, y
significativamente, puede ser engorroso 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
distintas porciones de los contenidos. Tal situación, por ejemplo,
puede ocurrir en un entorno corporativo o de oficina, donde un
usuario está editando repetidamente distintas porciones del
contenido, que han de compartirse con un equipo definido específico
de usuarios. En tal situación, entonces, y en una realización de la
presente invención, se crea una plantilla de derechos que el
usuario puede emplear repetidamente con respecto a la creación de
etiquetas de derechos, donde la plantilla de derechos ya incluye en
sí un conjunto predefinido de usuarios o clases de usuarios,
derechos predefinidos para cada usuario o clase de usuarios
definidos, y condiciones predefinidas de utilización.
En una realización de la presente invención, y
volviendo ahora a la Fig. 9, una plantilla 900 de derechos tiene
esencialmente los mismos datos de derechos que estarían en una
etiqueta de derechos. Sin embargo, dado que (DES1) no es conocido
hasta que se edita el contenido, los datos de derechos no pueden
cifrarse según tal (DES1), como ocurre en una etiqueta de derechos.
En una realización de la presente invención, entonces, la plantilla
900 de derechos con los datos de derechos no cifrados se despacha,
en el transcurso del cifrado de datos de derechos con (DES1) en la
etapa 416 de la Fig. 4, para producir
(DES1(datosdederechos)). Por supuesto, los datos de derechos
se extraen de la plantilla 900 de derechos despachada antes de ser
cifrados de tal manera.
Puede o no darse el caso de que el servidor 320
de DRM y la clave pública (PU-DRM) del mismo sean
conocidos en el momento en que se construye la plantilla de
derechos. Además, incluso si se conocen, puede o no darse el caso de
que haya más de un servidor 320 de DRM, cada uno de ellos con su
propio (PU-DRM). No obstante, en el caso en que el
servidor 320 de DRM y la clave pública (PU-DRM) del
mismo sean conocidos en el momento en que se construye la plantilla
de derechos, y en el caso en que sólo se emplee un servidor 320 de
DRM, o que sólo un servidor 320 de DRM ha de emplearse en relación
con la plantilla 900 de derechos, tal plantilla de derechos también
puede incluir en sí información sobre el servidor de DRM que ha de
firmar una etiqueta de derechos resultante de la plantilla 900 de
derechos, incluyendo la clave pública (PU-DRM) del
mismo. Aunque tal (PU-DRM) aparece en la SRL 308
cifrando (DES1) para dar como resultado
(PU-DRM(DES1)), ha de apreciarse nuevamente
que (DES1) no es conocido hasta que se edita el contenido y, por lo
tanto, (PU-DRM) en la plantilla 900 de derechos no
puede cifrar tal (DES1), como es el caso en una etiqueta de
derechos. En una realización de la presente invención, entonces, la
plantilla 900 de derechos con el (PU-DRM) no
cifrado, se despacha en el transcurso del cifrado de (DES1) con
(PU-DRM) en la etapa 414 de la Fig. 4 a fin de
producir (PU-DRM(DES1)). Por supuesto,
(PU-DRM) se extrae de la plantilla 900 de derechos
despachada, antes de ser empleada.
También en el caso precitado, otra información
en el servidor de DRM, que puede incluirse en la plantilla de
derechos, puede incluir también información de referencia tal como
un URL para localizar al servidor de DRM en una red, e información
de resguardo si el URL falla. En cualquier caso, la plantilla de
derechos también puede incluir información que describe la
plantilla 900 de derechos en sí misma, entre otras cosas. Observe
que la plantilla 900 de derechos también puede proporcionar espacio
para información relevante al contenido que ha de editarse, tal
como información que aparece en una etiqueta de derechos relevante
al contenido y/o las claves de cifrado (CK) y (DES1), aunque tal
espacio no es necesario si no se transforma efectivamente una
instanciación de la plantilla de derechos en una etiqueta de
derechos.
Aunque la plantilla 900 de derechos, según lo
revelado hasta aquí, está principalmente para comodidad del
usuario, también ha de apreciarse que, en algunas circunstancias, un
usuario no debería tener libertad irrestricta para definir datos de
derechos en una etiqueta de derechos, y puede utilizarse una
plantilla 900 de derechos para limitar el alcance o tipo de
etiquetas de derechos que pueden crearse. Por ejemplo, y
especialmente en el caso de un entorno corporativo o de oficina,
puede predefinirse, como norma, que un usuario específico siempre
debería editar contenidos sólo para una clase específica de
usuarios, o que el usuario nunca debería editar contenidos para una
clase específica de usuarios. En todo caso, y en una realización de
la presente invención, tal norma está realizada como datos de
derechos predefinidos en una o más plantillas 900 de derechos, y el
usuario puede estar restringido para emplear tales plantillas de
derechos a fin de crear etiquetas de derechos al editar contenidos.
Es de hacer notar que una plantilla de derechos o un grupo de
plantillas de derechos, puestos a disposición de un usuario para
especificar normas de edición para el usuario, pueden especificar
cualquier tipo específico de norma de edición sin apartarse del
espíritu y el alcance de la presente
invención
invención
Para especificar una plantilla 900 de derechos
para un usuario restringido o similar, y volviendo ahora a la Fig.
10, un administrador o similar, de hecho, construye la plantilla 900
de derechos definiendo los datos de derechos predefinidos (etapa
1001), y definiendo cualquier otro dato que pueda ser necesario y
adecuado, tal como información relevante a un servidor 320 de DRM
específico (etapa 1003). Significativamente, para llevar a cabo la
plantilla de derechos para su empleo por parte del usuario
restringido o similar, la plantilla 900 de derechos debe hacerse
oficial. Es decir, la plantilla 900 de derechos debe ser reconocible
como una plantilla de derechos que el usuario restringido o similar
puede emplear. En consecuencia, en una realización de la presente
invención, la plantilla de derechos, tal como la ha construido el
administrador o similar, se despacha al servidor 320 de DRM para
ser firmado por el mismo, donde tal firma hace oficial la plantilla
de derechos (etapa 1005).
Observe que el servidor firmante 320 de DRM es
el servidor 320 de DRM cuya información está en la plantilla 900 de
derechos, si acaso tal información está efectivamente presente en la
plantilla 900 de derechos. Observe, también, que el servidor 320 de
DRM puede firmar la plantilla 900 de derechos sólo al efectuar toda
comprobación necesaria, o bien puede firmar sin ninguna
comprobación en absoluto. Observe, finalmente, que la firma de la
plantilla S (PR-DRM-T) (donde la -T
significa que la firma es para la plantilla oficial 900 de derechos)
del servidor DRM debería basarse al menos en los datos de derechos
predefinidos en la plantilla 900 de derechos, pero también puede
basarse en otra información sin apartarse del espíritu y alcance de
la presente invención. Como se estipula más adelante, la firma S
(PR-DRM-T) se incorporará a una
etiqueta de derechos y se verificará en relación con la misma y, en
consecuencia, cualquiera que sea la base de la firma, también
debería incorporarse a la etiqueta de derechos de forma
inalterada.
Al firmar el servidor 320 de DRM la plantilla
900 de derechos y devolver la misma al administrador o figura
similar, el administrador recibe la plantilla 900 de derechos,
firmada y ahora oficial, con S
(PR-DRM-T) (etapa 1007), y remite
la plantilla oficial 900 de derechos (ORT) a uno o más usuarios para
su utilización por parte de los mismos (etapa 1009). En
consecuencia, para que un usuario edite contenidos basándose en una
ORT 900, dicho usuario extrae la ORT 900 (etapa 1011) y construye
una etiqueta de derechos basándose en la ORT 900 (etapa 1013),
proporcionando toda información necesaria, tal como información
acerca del contenido, información acerca de la clave adecuada, los
datos de derechos de la ORT 900 cifrados por (DES1), que dan como
resultado (DES1(datosdederechos)), y cualquier otra
información de la ORT 900. Significativamente, el usuario también
incluye, con la etiqueta de derechos, la firma S
(PR-DRM-T) de la ORT 900.
A continuación, y como antes, el usuario
despacha la etiqueta de derechos al servidor 320 de DRM para la
firma (etapa 1015). Aquí, sin embargo, el servidor 320 de DRM no
firmará la etiqueta de derechos despachada, a menos que se
verifique S (PR-DRM-T) en la misma.
Es decir, el servidor 320 de DRM hace cumplir que el usuario debe
basar la etiqueta de derechos despachada en una ORT 900, rehusándose
a firmar la etiqueta de derechos despachada a menos que tal
etiqueta de derechos despachada incluya una firma S
(PR-DRM-T) de una ORT 900. En
particular, el servidor 320 de DRM extrae tal S
(PR-DRM-T), y toda información sobre
la que se base tal firma, de la etiqueta de derechos despachada, y
luego verifica tal firma basándose en (PU-DRM).
Observe que los datos de derechos en la etiqueta de derechos
despachada están cifrados según (DES1) (es decir,
(DES1(datosdederechos)). En consecuencia, el servidor 320 de
DRM debe obtener primero (DES1) y descifrar
(DES1(datosdederechos)) con el mismo, según lo estipulado
anteriormente con relación a la Fig. 7, a fin de poder verificar la
firma basándose en los datos de derechos en la etiqueta de derechos
despachada.
Una vez verificada, el servidor 320 de DRM firma
la etiqueta de derechos despachada con S
(PR-DRM-L), a fin de producir una
SRL 308, igual que antes (donde la -L significa que la firma es para
la SRL 308). Aquí, S (PR-DRM-L)
puede reemplazar a S (PR-DRM-T), o
puede añadirse a tal S (PR-DRM-T).
Si se añade, S (PR-DRM-L) puede
basarse en parte en S (PR-DRM-T).
Observe que (PR-DRM) puede emplearse para producir
tanto S (PR-DRM-T) como S
(PR-DRM-L), o que pueden emplearse
distintos (PR-DRM) para uno cualquiera entre S
(PR-DRM-T) y S
(PR-DRM-L). Al firmar el servidor
320 de DRM la etiqueta de derechos y devolver la SRL 308 al usuario,
el usuario recibe la SRL 308 con S
(PR-DRM-L) (etapa 1017) y procede a
concatenar la misma al contenido que se está editando, igual que
antes.
Si la firma S
(PR-DRM-T) de la ORT 900 se basa, al
menos en parte, en los datos de derechos predefinidos en la ORT
900, entonces tales datos de derechos, según aparecen en la SRL 308
(en (DES1(datosdederechos)), no pueden sufrir modificaciones
o variaciones. En caso contrario, no se verificará la S
(PR-DRM-T). No obstante, en una
realización de la presente invención, los datos de derechos en la
ORT 900 pueden variar dentro de reglas prescritas, que también se
incluyen en la ORT 900. Por ejemplo, las reglas pueden especificar
que uno entre dos conjuntos de datos de derechos ha de incluirse en
una SRL 308, o pueden permitir una selección entre un conjunto de
alternativas. Como puede apreciarse, las reglas pueden ser reglas
específicas cualesquiera, estipuladas con cualquier sintaxis
adecuada, sin apartarse del espíritu y el alcance de la presente
invención. Aquí, las reglas son interpretadas por un intérprete de
reglas adecuado para el usuario en el momento en que se crea la
etiqueta de derechos. Aunque los datos de derechos pueden variar,
las reglas no varían de igual manera y, en consecuencia, la firma
de plantilla S (PR-DRM-T) para la
ORT 900 se basa, al menos en parte, en las reglas, y no en los
datos de derechos en sí. Como resultado de esto, las reglas
incluidas en la ORT 900 también deben incluirse en la SRL 308.
En una realización de la presente invención, los
datos de derechos predefinidos en la ORT 900 son fijos e
invariantes en parte, y son variables y gobernados por reglas en
parte, según lo estipulado anteriormente. Aquí, la firma de la
plantilla S (PR-DRM-T) para la ORT
900 se basa, al menos en parte, sobre la parte fija de las reglas, y
sobre las reglas para la parte variable de los datos de
derechos.
Como puede apreciarse, la ORT 900, en posesión
de un usuario, puede quedar caducada o desactualizada. Es decir, la
ORT 900, a través de los datos de derechos en la misma, puede
reflejar criterios que han quedado desactualizados, irrelevantes o,
simplemente, no son aplicables ya. Por ejemplo, uno o más usuarios,
o clases de usuarios, especificados en los datos de derechos de la
ORT 900, pueden no existir ya en el entorno de normas, o bien
cierto usuario, o clase de usuarios, especificados en los datos de
derechos de la ORT 900, pueden no tener ya los mismos derechos en
el entorno de normas. En tal caso, puede ser que el administrador
haya emitido una ORT 900 revisada, pero que el usuario esté usando
aún una versión previa, caducada, de la ORT 900.
En tal situación, entonces, y en una realización
de la presente invención, el servidor 320 de DRM, al firmar una
plantilla 900 de derechos despachada, a fin de crear una ORT 900,
retiene una copia de la ORT 900; cada ORT 900 tiene un indicio
identificador único, y cada etiqueta de derechos construida
basándose en una ORT 900 incluye el indicio identificador de tal
ORT 900 en la misma. En consecuencia, al recibir una etiqueta de
derechos despachada, tal como la relacionada con la Fig. 10, el
servidor 320 de DRM busca el indicio identificador de la ORT 900 en
la etiqueta de derechos, extrae la copia más reciente de tal ORT 900
basándose en el indicio identificador hallado, quita los datos de
derechos de la etiqueta de derechos despachada, inserta los datos
de derechos de la ORT 900 extraída y luego firma la etiqueta de
derechos basándose, al menos en parte, en los datos de derechos
insertados. Por supuesto, el servidor de DRM también realiza
cualesquiera etapas de cifrado y descifrado necesarias y relevantes
en el proceso según lo estipulado, incluyendo el descifrado y
recifrado de (DES1(datosdederechos)). Observe que si el
servidor de DRM está adaptado para reemplazar los datos de derechos
en una etiqueta de derechos despachada, tal etiqueta de derechos, y
la ORT 900 de la cual se ha construido tal etiqueta de derechos, no
deben necesariamente incluir los datos de derechos en las mismas.
En cambio, los datos de derechos sólo deben residir en el servidor
320 de DRM. Sin embargo, la inclusión de datos de derechos en la
etiqueta de derechos, y en la ORT 900 a partir de la cual se
construye tal etiqueta de derechos, podría ser de utilidad para el
usuario y, por lo tanto, puede ser útil en algunas situaciones.
Un típico servidor de DRM, y una plataforma de
servicio según la invención, pueden incluir uno o más servicios de
DRM de alto nivel, tales como licencias, edición, suscripción,
activación, certificación, federación y otros similares. Según la
invención, los respectivos sistemas de software que brindan cada uno
de estos servicios pueden proporcionarse como "baterías de
procesos" que están diseñadas de manera modular, a fin de que
puedan instalarse individualmente en cualquier combinación, y que
puedan luego ser gestionadas, habilitadas o inhabilitadas,
autenticadas o deslegitimadas, etc. Cada uno de los servicios de DRM
puede denominarse una batería de procesos, debido a la forma en que
procesan las solicitudes desde el principio hasta el final, con
diversas etapas de procesamiento por el camino.
Las baterías de procesos trabajan conjuntamente
a fin de presentar una plataforma rica de DRM e, individualmente,
cada una proporciona un importante servicio de DRM. Además,
componentes específicos de la plataforma de DRM, que encapsulan la
lógica comercial (lo que puede ser importante para un servidor de
DRM y para una implementación de servicios exitosos), son
compartidos en el ámbito de la gama de DRM, y son "acoplables"
por terceros. Tal implementación brinda la flexibilidad tanto para
desarrollar rápidamente soluciones de servicio como para ofrecer a
los clientes una manera de personalizar software para sus
necesidades de DRM.
Preferiblemente, se emplean el Servidor de
Información de Internet ("IIS") y el modelo ASP.net de
Microsoft para los servicios de escritura. El IIS está diseñado para
proporcionar seguridad a intranets corporativas y a Internet.
Además, el IIS proporciona una implementación del protocolo de la
Capa de Tomas Seguras (SSL). para la comunicación y autenticación
seguras con certificados X.509, Cifra de Clave Pública RSA y una
amplia gama de características adicionales de seguridad. ASP.net es
un entorno de programación que permite el desarrollo rápido de
potentes aplicaciones y servicios de Web. Es parte de la plataforma
.NET de Microsoft, y proporciona una manera fácil y escalable de
construir, desplegar y ejecutar aplicaciones de Web que pueden
orientarse hacia cualquier explorador o dispositivo.
En una realización preferida de la invención, se
envía una solicitud de HTTP de tipos fuertes a un servidor de Web
que ejecuta el IIS, ASP.net y uno o más servicios de DRM. La
solicitud de HTTP es entonces preprocesada por el IIS y por
ASP.net, y dirigida al servicio adecuado de DRM. Una vez que la
solicitud lleva al código de servicio de DRM, ingresa a una de las
baterías de procesos encargados del procesamiento. Cada batería de
procesos está definida al más alto nivel por un fichero de ASP.net
(un fichero ASMX) que describe por sí mismo el punto de entrada del
servicio y el código que se encarga de las solicitudes a ese punto
de entrada. Para cada batería de procesos, hay código de servicio
de DRM detrás del punto de entrada, y la combinación del fichero
ASMX y del código detrás de él compone la batería de procesos.
El código tras el punto de entrada es modular, y
puede compartir código con otras baterías de procesos. Puede
incluir: 1) código de inicio específico para la solicitud, que
preprocesa los parámetros de la solicitud, llevando a cabo
cualquier normalización requerida de los datos y realizando
operaciones comunes de inicio de solicitudes en baterías de
procesos; 2) código que realiza acciones específicas para el
procesamiento de la solicitud (y específicas para la batería de
procesos); 3) código que invoca componentes internos compartidos
(compartidos entre baterías de procesos y accesibles sólo a la
plataforma de DRM) y componentes públicos compartidos (compartidos
entre baterías de procesos y acoplables por terceros); y 4) código
de cierre de solicitudes, que toma los resultados generados por la
batería de procesos y formula una respuesta adecuada para la
solicitud.
Como resultado de este diseño de baterías de
procesos, los servicios de DRM pueden desplegarse fácilmente en
cualquier permutación. Por ejemplo, los servicios de Licencias y de
Federación pueden instalarse en una instalación específica, y los
servicios de Edición e Información pueden inhabilitarse. En otro
ejemplo, pueden instalarse sólo los servicios de Licencias, o sólo
los de Edición, con el cumplimiento de estrictos requisitos de
autenticación para el servicio de Edición, aplicándolos al punto de
entrada del fichero ASMX. Tal diseño de baterías de procesos también
brinda la introducción eficiente de nuevos servicios en el futuro,
tal como un servicio de Suscripción, o un servicio de Firma y
Validación de Firma, por ejemplo, sin afectar a los servicios
existentes de DRM, pero aprovechando la infraestructura
existente.
Dentro de cada batería de procesos se ejecuta un
cierto número de etapas de la batería de procesos, algunas de las
cuales invocan componentes sólo internos de DRM, y algunas de las
cuales invocan componentes públicos y acoplables ("acoples").
Como resultado de este diseño acoplable de DRM, los terceros pueden
escribir u obtener componentes personalizados que ejecutan una
parte del proceso general de la batería de procesos de DRM.
Preferiblemente, se toman medidas para garantizar que tales
terceros son fiables antes de que tales componentes acoplables de
terceros se integren en el marco de la batería de procesos. Las
técnicas estándar y públicas proporcionadas por el entorno .NET
pueden utilizarse para garantizar que el componente acoplable de
terceros es fiable. Los componentes acoplables de terceros pueden
instalarse dinámicamente. Tales componentes acoplables de terceros
pueden ser identificados, en los datos de configuración del sistema
de DRM, por ejemplo, y cargarse en tiempo de ejecución. Tal diseño
brinda facilidad de uso y de administración del sistema de DRM.
Generalmente, un componente acoplable lleva a
cabo una tarea discreta, tal como extraer una Etiqueta de Derechos
del almacenamiento, generar un nodo XML de Punto de Distribución
basado en datos de configuración, realizar operaciones de clave
privada utilizando hardware personalizado de cifrado/descifrado,
etc., Ciertos componentes acoplables especializados se denominan
aquí "extensiones". Las extensiones se invocan cuando ocurren
sucesos generales, tal como cuando es hora de autorizar una
solicitud, cuando se ha generado una licencia, etc., Los
componentes acoplables son más activos en el procesamiento de las
baterías de procesos, llevando a cabo una tarea esencial y
requerida en la batería de procesos. Las extensiones son más
pasivas, respondiendo a sucesos y, posiblemente, realizando algún
trabajo o bien no haciendo nada.
La Fig. 11 ilustra una batería genérica 1100 de
procesos según la invención. La batería 1100 de procesos incluye un
programa 1102 de servicio que proporciona un entorno de
procesamiento para llevar a cabo un servicio de gestión de derechos
digitales, tal como la edición, las licencias, etc. La batería 1100
de procesos incluye una pluralidad de componentes acoplables 1120a,
1102b. Cada componente acoplable 1120a, 1120b realiza su respectiva
tarea, asociada al servicio de gestión de derechos digitales. Los
tipos de tareas que puede realizar un componente acoplable en una
batería de procesos de gestión de derechos digitales se describen en
detalle por toda esta especificación. Cada uno de la pluralidad de
componentes acoplables 1120a, 1120b está integrado en el entorno
1102 de procesamiento según un respectivo conjunto predefinido de
reglas de interfaz. Típicamente, estas reglas de interfaz se
negocian entre el proveedor del entorno de procesamiento del
programa de servicio y el proveedor del componente acoplable (que,
como se ha descrito anteriormente, pueden o no ser la misma
entidad). Una batería 1100 de procesos también puede incluir una o
más extensiones 1130.
En algún punto 1140 a lo largo de la batería de
procesos, todas las tareas necesarias para llevar a cabo el
servicio (p. ej., procesar la solicitud) han sido completadas.
Después de ese punto 1140, los componentes asincrónicos pueden
integrarse en el entorno 1110 de procesamiento. En primera
instancia, los componentes asincrónicos pueden utilizarse para
tareas que no son necesarias para realizar el servicio. De esta
manera, los componentes asincrónicos proporcionan un modelo de
extensibilidad fuera de banda para tareas que no tienen que
llevarse a cabo durante el procesamiento de la batería de procesos.
Como son procesados después de que las tareas del servicio
requerido han sido completadas, los componentes asincrónicos no
impiden el procesamiento de una solicitud. Preferiblemente, los
componentes asincrónicos no tiene poder de veto. Cualquier número de
componentes asincrónicos puede ser procesado en paralelo.
Gracias a esta plataforma abierta, se prefiere
que se tomen medidas para proteger los datos y las interfaces. Por
ejemplo, podría requerirse que los componentes acoplables que están
trabajando dentro del entorno de la batería de procesos sean
fiables. Esto puede lograrse de diversas maneras. Por ejemplo,
pueden emplearse técnicas de nombrado fuerte y de código con
gestión de seguridad basado en evidencias, entre el programa de
servicio y sus componentes acoplables, a fin de validar el
componente y asegurarse de que el programa de servicio se fía del
componente acoplable y de que el componente acoplable se fía del
programa de servicio. Además, los datos que el programa de servicio
proporciona a los componentes acoplables, y los datos que el
programa de servicio acepta de ellos, pueden controlarse
cuidadosamente. Por ejemplo, en una realización preferida, a los
componentes acoplables se les niega el acceso directo a las
estructuras de datos del programa de servicio. En cambio, se
replican los datos que entran y salen de los componentes
acoplables.
La Fig. 12 ilustra una realización preferida de
una batería 1200 de procesos de edición según la invención. Como se
muestra, la batería 1200 de procesos de edición puede incluir un
programa de servicio, tal como un programa de solicitudes de
edición, por ejemplo, que proporciona un entorno de procesamiento a
fin de procesar una solicitud para editar contenido digital con
gestión de derechos. La batería 1200 de procesos de edición también
puede incluir una pluralidad de componentes acoplables, cada uno de
los cuales realiza su respectiva tarea asociada al procesamiento de
la solicitud de edición. Cada uno de la pluralidad de componentes
acoplables se integra en el entorno de procesamiento según su
respectivo conjunto predefinido de reglas de interfaz. Cada uno de
los ejemplos de componentes acoplables se describe ahora en
detalle.
Puede proporcionarse un componente acoplable
1120a de "autenticación" para determinar la identidad de la
entidad que solicita la licencia. De esta manera, el proveedor del
componente acoplable 1320a de autenticación puede controlar si se
requiere la autenticación y, en ese caso, el proveedor puede
controlar el tipo de autenticación, el método de autenticación, si
se permite o no la autenticación anónima, y el tipo de código de
error que se devolverá si la solicitud no puede autenticarse por
cualquier motivo.
Puede proporcionarse un componente acoplable
1220b de "autorización" para autorizar la identidad
autenticada. Generalmente, puede utilizarse un componente acoplable
de autorización para determinar si una entidad solicitante está
autorizada a hacer aquello que la entidad solicitante ha pedido. Por
ejemplo, en una batería de procesos de edición, puede utilizarse un
componente acoplable de autorización para determinar si se permite a
la identidad autenticada editar contenidos con gestión de derechos
utilizando el sistema de DRM. De esta manera, el proveedor del
componente acoplable de autorización puede controlar qué entidades
pueden solicitar qué acciones, qué lista de entidades se almacena,
cómo y dónde se almacena tal lista, cómo las entidades autorizadas
causan alta y baja de la lista, y sucesos similares.
Puede utilizarse un componente acoplable 1220c
de "almacenamiento de etiqueta de derechos" para almacenar una
etiqueta maestra de derechos generada según la invención. Como se ha
descrito en detalle anteriormente, puede asociarse una etiqueta
maestra de derechos a un identificador, tal como un GUID. En el
momento de emitir la licencia, el servidor extrae del
almacenamiento una copia de la etiqueta maestra de derechos,
basándose en el GUID. El proveedor de un componente acoplable 1220c
de almacenamiento de etiquetas de derechos puede definir las
localidades donde ha de almacenarse la etiqueta maestra de derechos,
y las técnicas de almacenamiento empleadas para almacenar la
etiqueta de derechos.
Puede utilizarse un componente acoplable 1220d
de "clave privada" para proteger la clave privada raíz. De
esta manera, el proveedor de un componente acoplable 1220d de clave
privada puede especificar el algoritmo de protección de clave
privada que utilizará el sistema. Un cierto número de algoritmos de
protección de clave privada, que son adecuados para su empleo en un
sistema de DRM según la invención, se describen en la Solicitud de
Patente Estadounidense Nº (Registro de Procurador
MSFT-1334).
En el punto 1240 de terminación, como se muestra
en la Fig. 12, el procesamiento de la solicitud de edición ha sido
completado, y los componentes asincrónicos 1250 comienzan a realizar
sus respectivas tareas. Como se muestra, la batería 1200 de
procesos de edición también puede incluir un componente 1250a de
"bolsa de propiedades", una aplicación 1250b de
"registro" y un componente acoplable 1250c, como motor de
certificados. Debería entenderse, sin embargo, que una batería de
procesos de edición según la invención puede incluir cualquier
número de componentes acoplables, incluyendo cualquier número de
extensiones o componentes asincrónicos.
Una "bolsa de propiedades" 1250a es un
recurso que está disponible para los componentes acoplables durante
el tiempo de ejecución, y que presenta información de contexto de la
solicitud. El proveedor de la bolsa de propiedades puede así
controlar qué datos se meten en la bolsa de propiedades, a quién se
deja disponible la bolsa de propiedades, y en qué circunstancias
puede dejarse disponible la bolsa de propiedades.
Puede utilizarse una aplicación 1250b de
"registro" para archivar datos relacionados con la solicitud de
edición. El proveedor del componente de registro puede así
controlar qué datos se archivan, dónde se archivan los datos y en
qué formato se archivan los datos.
Un componente acoplable 1250c, "motor de
certificados", es un componente acoplable asincrónico que escribe
certificados (p. ej., un certificado de licencia). El motor de
certificados sabe cómo abordar la gramática del lenguaje de
derechos que se está utilizando (p. ej., XrML). El proveedor del
componente acoplable del motor de certificados puede así controlar
el formato y contenido de los certificados, el lenguaje de derechos
que se está utilizando, etc.
La Fig. 13 ilustra una realización preferida de
una batería 1300 de procesos de licencias según la invención. Según
se muestra, la batería 1300 de procesos de licencias puede incluir
un programa de servicio, tal como un programa de solicitudes de
licencia, por ejemplo, que proporciona un entorno de procesamiento
para procesar una solicitud de licencia. La batería 1300 de
procesos de licencias también puede incluir una pluralidad de
componentes acoplables, cada uno de los cuales realiza su respectiva
tarea, asociada al procesamiento de la solicitud de licencia. Cada
uno de la pluralidad de componentes acoplables se integra en el
entorno de procesamiento del programa de solicitud de licencias
según su respectivo conjunto predefinido de reglas de interfaz. Cada
uno de los ejemplos de componentes acoplables se describe ahora en
detalle. Observe que, en una realización preferida de un sistema de
DRM según la invención, los componentes acoplables pueden
compartirse entre diversos servicios de batería de procesos, o de
Web, y muchos de los componentes acoplables que pueden incluirse en
una batería de procesos de licencias pueden ser idénticos a aquellos
incluidos en la batería de procesos de edición descrita
anteriormente.
Puede proporcionarse un componente acoplable
1320a de "autenticación", tal como el descrito anteriormente
con relación a la batería de procesos de edición, a fin de
determinar la identidad de la entidad que solicita la
licencia.
licencia.
Puede proporcionarse un componente acoplable
1320b de "autorización", tal como el descrito anteriormente con
relación a la batería de procesos de edición, a fin de autorizar la
identidad autenticada. En una batería de procesos de licencias,
pueden utilizarse un componente acoplable de autorización a fin de
determinar si se permite o no a la entidad solicitante solicitar
una licencia. De esta manera, el proveedor del componente acoplable
de autorización puede controlar si se permite o no a una identidad
de cuenta personal realizar directamente una solicitud de licencia,
si un proceso servidor fiable puede o no realizar una solicitud de
licencia a nombre de tal entidad, y otros
similares.
similares.
Puede utilizarse un componente acoplable 1320c
de "expansión de grupo" para extraer una lista de usuarios
individuales de un identificador de grupo. Se prevé que, en general,
la pertenencia a un grupo predefinido cambiará a lo largo del
tiempo. En consecuencia, un sistema de DRM según la invención puede
incluir un repositorio de grupos que contiene las respectivas
listas de usuarios para cada uno de un cierto número de grupos. Cada
grupo tiene un identificador de grupo asociado. Por ello, toda vez
que se recibe un identificador de grupo durante el procesamiento de
un servicio de gestión de derechos digitales (p. ej., edición),
puede llamarse al componente acoplable de expansión de grupos para
extraer la lista actual del grupo que corresponde al identificador
de grupo recibido.
Puede utilizarse un componente acoplable 1320d
de "extracción de etiqueta de derechos" para extraer una
etiqueta de derechos que corresponde a un identificador recibido.
Como se ha descrito en detalle anteriormente, el servidor analiza
sintácticamente la etiqueta de derechos ingresada en la solicitud de
licencia a fin de extraer su GUID. Luego pasa este GUID al
componente acoplable 1320d de extracción de etiquetas de derechos,
el cual emite una consulta sobre la base de datos a fin de extraer
una copia de la etiqueta maestra de derechos.
Puede utilizarse un componente acoplable de
"extracción de certificados" para extraer un certificado desde
un servidor en el cual se almacenan tales certificados. Por ejemplo,
una entidad solicitante podría estar solicitando prelicencias para
un cierto número de licenciatarios potenciales, pero la entidad
solicitante no tiene los certificados para los licenciatarios
potenciales. Sin embargo, se necesitan los certificados para emitir
la licencia, por lo que puede utilizarse el componente acoplable de
extracción de certificados para extraer los certificados del
servidor en el cual están almacenados.
Puede utilizarse un componente acoplable de
"almacenamiento" para encapsular el acceso al almacenamiento,
cualquiera que sea el proporcionado. De esta manera, el proveedor de
un componente aplicable de almacenamiento puede especificar los
almacenes en los cuales pueden almacenarse datos, o de los cuales
pueden extraerse datos, así como el "lenguaje" que la batería
de procesos necesita para comunicarse con el almacén o almacenes de
datos. Por ejemplo, una batería de procesos podría necesitar acceder
a un almacén específico de datos por medio del
SQL.
SQL.
Puede utilizarse un componente acoplable 1320g
de "punto de distribución" con relación a la superdistribución
de la URL de referencia. El componente acoplable 1320g de punto de
distribución lee los URL de referencia en una dirección de
almacenamiento, y los incorpora en documentos XrML cuando es
requerido para hacerlo. La salida de este componente acoplable es
una porción bien definida de XML que define la URL de referencia con
la que un cliente puede ponerse en contacto a fin de realizar una
operación de DRM tal como emisión de licencias, adquisición de
derechos, etc.
Puede utilizarse un componente acoplable 1320h
de "clave privada", tal como el descrito anteriormente con
relación a la batería de procesos de edición, para proteger la clave
privada raíz.
En el punto 1340 de terminación, como se muestra
en la Fig. 13, se completa el procesamiento de la solicitud de
licencia, y los componentes acoplables asincrónicos 1350 comienzan a
realizar sus respectivas tareas. Como se muestra, la batería 1300
de procesos de licencias también puede incluir un componente 1350a
de "bolsa de propiedades", una aplicación 1350b de
"registro", y un componente acoplable 1350c como motor de
certificados, tal como se ha descrito anteriormente en relación a
la batería de procesos de edición. Debería entenderse, sin embargo,
que una batería de procesos de licencias según la invención puede
incluir cualquier número de componentes acoplables, incluyendo
cualquier número de extensiones o componentes asincrónicos.
La Fig. 14 proporciona un diagrama de flujo de
una realización preferida de un procedimiento 1400 según la
invención, a fin de proporcionar una arquitectura acoplable de
servidor seguro para sistemas de gestión de derechos digitales. En
la etapa 1402, el proveedor del sistema proporciona un programa de
servicio que brinda un entorno de procesamiento para llevar a cabo
un servicio de gestión de derechos digitales, tal como la edición,
la emisión de licencias, etc. En una realización preferida, el
programa de servicio incluye código para llevar a cabo el servicio
asociado de DRM.
En la etapa 1404, el proveedor del sistema
proporciona una pluralidad de opciones acoplables de DRM, cada una
de las cuales está asociada a un respectivo componente acoplable que
lleva a cabo una respectiva tarea, asociada al servicio de gestión
de derechos digitales. El instalador, comprador, administrador del
sistema, etc., o bien otro usuario del sistema, puede entonces
seleccionar entre la pluralidad de opciones acoplables, a fin de
escoger aquellos componentes acoplables que brinden la funcionalidad
específica que el consumidor desea para esa batería de procesos,
para esa instalación.
En la etapa 1406, el proveedor del sistema
recibe las selecciones acoplables y, en la etapa 1408, integra en el
entorno de procesamiento los componentes acoplables que corresponden
a las opciones acoplables seleccionadas. De esta manera, un usuario
de un sistema de DRM según la invención puede personalizar el
sistema según las necesidades o deseos del usuario, y puede
actualizar el sistema de manera económica, fácil y eficiente,
cambiando los componentes acoplables.
La programación necesaria para efectuar los
procesos ejecutados con relación a la presente invención es
relativamente inmediata, y debería ser obvia al colectivo de
programación relevante En consecuencia, tal programación no se
adjunta a la presente. Cualquier programación específica, entonces,
puede emplearse a fin de llevar a cabo la presente invención sin
apartarse del espíritu y el alcance de la misma.
De esta manera, se han descrito arquitecturas
acoplables seguras para sistemas de gestión de derechos. Aquellos
versados en la tecnología apreciarán que pueden hacerse numerosos
cambios y modificaciones a las realizaciones preferidas de la
invención, y que tales cambios y modificaciones pueden hacerse sin
apartarse del espíritu de la invención. Por ejemplo, aunque la
invención ha sido descrita en detalle con relación a las baterías
de procesos de edición y de emisión de licencias, debería entenderse
que la invención puede emplearse en otras baterías de procesos de
gestión de derechos digitales que realizan otros servicios de
gestión de derechos digitales, tales como la suscripción, la
activación, la certificación, la federación, y otros similares. Se
pretende, por lo tanto, que las reivindicaciones adjuntas cubran
todas las variaciones equivalentes que queden dentro del ámbito de
la invención.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
(Apéndice pasa a página
siguiente)
Claims (28)
1. Un sistema (300) para suministrar servicios
de gestión de derechos digitales, comprendiendo el sistema
(300):
un programa de servicio que proporciona un
entorno de procesamiento para realizar un servicio (306) de gestión
de derechos digitales; y
una pluralidad de componentes acoplables, cada
uno de los cuales realiza una tarea respectiva asociada al servicio
de gestión de derechos digitales,
en el cual cada uno entre la pluralidad de
componentes acoplables se integra en el entorno de procesamiento
según un respectivo conjunto predefinido de reglas de interfaz.
2. El sistema de la reivindicación 1, en el cual
el servicio de gestión de derechos digitales incluye el
procesamiento de una solicitud de edición, para editar el contenido
digital con gestión de derechos.
3. El sistema de la reivindicación 2, en el cual
la pluralidad de componentes acoplables incluye un componente
acoplable para almacenar una etiqueta de derechos que incluye una
descripción de derechos, una clave cifrada de contenido y una firma
digital que abarca tanto la descripción de derechos como la clave
cifrada de contenido.
4. El sistema de la reivindicación 2, en el cual
la pluralidad de componentes acoplables incluye un componente
acoplable para proteger una clave privada que se utiliza con
relación al cifrado y descifrado del contenido digital con gestión
de derechos.
5. El sistema de la reivindicación 2, en el cual
la pluralidad de componentes acoplables incluye un componente
acoplable para generar un certificado.
6. El sistema de la reivindicación 2, en el cual
la pluralidad de componentes acoplables incluye un componente
acoplable para autenticar una entidad que despacha la solicitud de
edición.
7. El sistema de la reivindicación 2, en el cual
la pluralidad de componentes acoplables incluye un componente
acoplable para determinar si una entidad que despacha la solicitud
de edición está autorizada para editar el contenido digital con
gestión de derechos, según la solicitud.
8. El sistema de la reivindicación 1, en el cual
el servicio de gestión de derechos digitales incluye el
procesamiento de una solicitud de licencia para licenciar el
contenido digital con gestión de derechos.
9. El sistema de la reivindicación 8, en el cual
la pluralidad de componentes acoplables incluye un componente
acoplable de expansión de grupo, para extraer una lista de usuarios
basada en un identificador de grupo proporcionado en la solicitud de
licencia.
10. El sistema de la reivindicación 8, en el
cual la pluralidad de componentes acoplables incluye un componente
acoplable para extraer una etiqueta de derechos que incluye una
descripción de derechos, una clave cifrada de contenido y una firma
digital que abarca tanto la descripción de derechos como la clave
cifrada de contenido.
11. El sistema de la reivindicación 8, en el
cual la pluralidad de componentes acoplables incluye un componente
acoplable para extraer un certificado.
12. El sistema de la reivindicación 8, en el
cual la pluralidad de componentes acoplables incluye un componente
acoplable para autenticar una entidad que despacha la solicitud de
licencia.
13. El sistema de la reivindicación 8, en el
cual la pluralidad de componentes acoplables incluye un componente
acoplable para determinar si una entidad que despacha la solicitud
de licencia está autorizada para utilizar el contenido digital con
gestión de derechos según la solicitud.
14. El sistema de la reivindicación 1, en el
cual la pluralidad de componentes acoplables incluye al menos un
componente acoplable de extensión, que realiza su respectiva tarea
basándose en la ocurrencia de un suceso prescrito.
15. El sistema de la reivindicación 14, en el
cual el componente acoplable de extensión está adaptado para
detener el procesamiento del programa de servicio.
16. El sistema de la reivindicación 1, en el
cual la pluralidad de componentes acoplables incluye al menos un
componente asincrónico.
17. El sistema de la reivindicación 1, en el
cual el servicio de gestión de derechos digitales incluye un
servicio de suscripción.
18. El sistema de la reivindicación 1, en el
cual el servicio de gestión de derechos digitales incluye un
servicio de activación.
19. El sistema de la reivindicación 1, en el
cual el servicio de gestión de derechos digitales incluye un
servicio de certificación.
20. El sistema de la reivindicación 1, en el
cual el servicio de gestión de derechos digitales incluye un
servicio de federación.
21. Un procedimiento para proporcionar servicios
de gestión de derechos digitales, comprendiendo el
procedimiento:
el suministro de un programa de servicio que
proporciona un entorno de procesamiento para realizar un servicio
de gestión de derechos digitales;
el suministro de una pluralidad de opciones
acoplables de gestión de derechos digitales, en donde cada una de
las opciones acoplables está asociada a un respectivo componente
acoplable que lleva a cabo una respectiva tarea asociada al
servicio de gestión de derechos digitales; y
la integración de un componente acoplable
seleccionado en el entorno de procesamiento, en el cual un
componente acoplable seleccionado corresponde a una opción
acoplable seleccionada entre la pluralidad de opciones
acoplables;
22. El procedimiento de la reivindicación 21,
que comprende adicionalmente:
la recepción de una selección acoplable que
corresponde al componente acoplable seleccionado.
23. El procedimiento de la reivindicación 21, en
el cual el componente acoplable deseado se integra en el entorno de
procesamiento según un conjunto predefinido de reglas de
interfaz.
24. El procedimiento de la reivindicación 21, en
el cual un programa de servicio proporciona un entorno de
procesamiento para realizar un servicio de licencias.
25. El procedimiento de la reivindicación 21, en
el cual el programa de servicio proporciona un entorno de
procesamiento para realizar un servicio de edición.
26. Un sistema de gestión de derechos digitales,
que comprende:
un servidor (320) de gestión de derechos
digitales que incluye un medio legible por ordenador que tiene
almacenado en el mismo instrucciones ejecutables por ordenador,
para llevar a cabo una pluralidad de servicios (306) de gestión de
derechos digitales, en donde cada uno de la pluralidad de servicios
de gestión de derechos digitales se efectúa en una respectiva
batería de procesos, y en donde las respectivas baterías de procesos
son independientes entre sí (1110, 1210, 1310).
27. El sistema de gestión de derechos digitales
de la reivindicación 26, en el cual cada una de las baterías de
procesos comprende:
un programa de servicio que proporciona un
entorno de procesamiento para llevar a cabo el servicio asociado de
gestión de derechos digitales; y
una pluralidad de componentes acoplables, cada
uno de los cuales realiza una respectiva tarea asociada al servicio
de gestión de derechos digitales.
28. El sistema de gestión de derechos digitales
de la reivindicación 27, en el cual cada uno de la pluralidad de
componentes digitales está integrado en el entorno de procesamiento
según un respectivo conjunto predefinido de reglas de interfaz.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US185906 | 2002-06-28 | ||
| US10/185,906 US7631318B2 (en) | 2002-06-28 | 2002-06-28 | Secure server plug-in architecture for digital rights management systems |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2271427T3 true ES2271427T3 (es) | 2007-04-16 |
Family
ID=27612990
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES03013564T Expired - Lifetime ES2271427T3 (es) | 2002-06-28 | 2003-06-13 | Arquitectura de servidor enchufable asegurada para sistemas de gestion de derechos digitales. |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US7631318B2 (es) |
| EP (1) | EP1376980B1 (es) |
| JP (1) | JP4489382B2 (es) |
| AT (1) | ATE337671T1 (es) |
| DE (1) | DE60307736T2 (es) |
| ES (1) | ES2271427T3 (es) |
| NO (1) | NO333104B1 (es) |
Families Citing this family (121)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6606659B1 (en) | 2000-01-28 | 2003-08-12 | Websense, Inc. | System and method for controlling access to internet sites |
| US7493397B1 (en) * | 2001-06-06 | 2009-02-17 | Microsoft Corporation | Providing remote processing services over a distributed communications network |
| US7428725B2 (en) * | 2001-11-20 | 2008-09-23 | Microsoft Corporation | Inserting devices specific content |
| US7194464B2 (en) | 2001-12-07 | 2007-03-20 | Websense, Inc. | System and method for adapting an internet filter |
| US20030233477A1 (en) * | 2002-06-17 | 2003-12-18 | Microsoft Corporation | Extensible infrastructure for manipulating messages communicated over a distributed network |
| US7502945B2 (en) * | 2002-06-28 | 2009-03-10 | Microsoft Corporation | Using a flexible rights template to obtain a signed rights label (SRL) for digital content in a rights management system |
| US7574653B2 (en) * | 2002-10-11 | 2009-08-11 | Microsoft Corporation | Adaptive image formatting control |
| US20040122772A1 (en) * | 2002-12-18 | 2004-06-24 | International Business Machines Corporation | Method, system and program product for protecting privacy |
| US7370017B1 (en) * | 2002-12-20 | 2008-05-06 | Microsoft Corporation | Redistribution of rights-managed content and technique for encouraging same |
| JP4175118B2 (ja) * | 2003-01-14 | 2008-11-05 | ヤマハ株式会社 | コンテンツ処理装置及びプログラム |
| JP3823925B2 (ja) * | 2003-02-05 | 2006-09-20 | ソニー株式会社 | 情報処理装置、ライセンス情報記録媒体、および情報処理方法、並びにコンピュータ・プログラム |
| US7370212B2 (en) * | 2003-02-25 | 2008-05-06 | Microsoft Corporation | Issuing a publisher use license off-line in a digital rights management (DRM) system |
| US7136945B2 (en) * | 2003-03-31 | 2006-11-14 | Sony Corporation | Method and apparatus for extending protected content access with peer to peer applications |
| US7353397B1 (en) * | 2003-04-30 | 2008-04-01 | Adobe Systems Incorporated | Repurposing digitally signed information |
| EP2270622B1 (en) * | 2003-06-05 | 2016-08-24 | Intertrust Technologies Corporation | Interoperable systems and methods for peer-to-peer service orchestration |
| KR100953160B1 (ko) * | 2003-06-26 | 2010-04-20 | 삼성전자주식회사 | 네트워크 장치 및 이를 이용하는 상이한 저작권 관리방식을 갖는 네트워크 장치간의 컨텐츠 호환성 제공 방법 |
| US7237256B2 (en) | 2003-07-14 | 2007-06-26 | Sun Microsystems, Inc. | Method and system for providing an open and interoperable system |
| US7506162B1 (en) | 2003-07-14 | 2009-03-17 | Sun Microsystems, Inc. | Methods for more flexible SAML session |
| EP1557762A1 (en) * | 2003-07-25 | 2005-07-27 | Matsushita Electric Industrial Co., Ltd. | Data processing apparatus |
| KR100493904B1 (ko) * | 2003-09-18 | 2005-06-10 | 삼성전자주식회사 | 다수의 기기를 지원하는 ｄｒｍ 라이센스 방법 |
| US7801819B2 (en) | 2003-10-03 | 2010-09-21 | Sony Corporation | Rendering rights delegation system and method |
| US8103004B2 (en) * | 2003-10-03 | 2012-01-24 | Sony Corporation | Method, apparatus and system for use in distributed and parallel decryption |
| US7596782B2 (en) * | 2003-10-24 | 2009-09-29 | Microsoft Corporation | Software build extensibility |
| FR2865051B1 (fr) * | 2004-01-14 | 2006-03-03 | Stg Interactive | Procede et systeme pour l'exploitation d'un reseau informatique destine a la publication de contenu |
| US9003548B2 (en) | 2004-04-13 | 2015-04-07 | Nl Systems, Llc | Method and system for digital rights management of documents |
| US7836510B1 (en) | 2004-04-30 | 2010-11-16 | Oracle America, Inc. | Fine-grained attribute access control |
| US7565356B1 (en) | 2004-04-30 | 2009-07-21 | Sun Microsystems, Inc. | Liberty discovery service enhancements |
| US7890604B2 (en) * | 2004-05-07 | 2011-02-15 | Microsoft Corproation | Client-side callbacks to server events |
| US20050251380A1 (en) * | 2004-05-10 | 2005-11-10 | Simon Calvert | Designer regions and Interactive control designers |
| US9026578B2 (en) * | 2004-05-14 | 2015-05-05 | Microsoft Corporation | Systems and methods for persisting data between web pages |
| US8065600B2 (en) | 2004-05-14 | 2011-11-22 | Microsoft Corporation | Systems and methods for defining web content navigation |
| US7464386B2 (en) * | 2004-05-17 | 2008-12-09 | Microsoft Corporation | Data controls architecture |
| US20060020883A1 (en) * | 2004-05-28 | 2006-01-26 | Microsoft Corporation | Web page personalization |
| US7530058B2 (en) * | 2004-05-28 | 2009-05-05 | Microsoft Corporation | Non-compile pages |
| US8156448B2 (en) * | 2004-05-28 | 2012-04-10 | Microsoft Corporation | Site navigation and site navigation data source |
| GB2415065B (en) * | 2004-06-09 | 2009-01-21 | Symbian Software Ltd | A computing device having a multiple process architecture for running plug-in code modules |
| US7730012B2 (en) * | 2004-06-25 | 2010-06-01 | Apple Inc. | Methods and systems for managing data |
| US7437358B2 (en) | 2004-06-25 | 2008-10-14 | Apple Inc. | Methods and systems for managing data |
| EP1789892A2 (en) * | 2004-08-02 | 2007-05-30 | JustSystems Corporation | A document processing and management approach to adding an exclusive plugin implementing a desired functionality |
| JP4728610B2 (ja) * | 2004-08-04 | 2011-07-20 | 株式会社リコー | アクセス制御リスト添付システム、オリジナルコンテンツ作成者端末、ポリシーサーバ、オリジナルコンテンツデータ管理サーバ、プログラム及び記録媒体 |
| GB2416879B (en) | 2004-08-07 | 2007-04-04 | Surfcontrol Plc | Device resource access filtering system and method |
| JP4748762B2 (ja) * | 2004-08-24 | 2011-08-17 | キヤノン株式会社 | 署名生成方法及び情報処理装置 |
| US20060048224A1 (en) * | 2004-08-30 | 2006-03-02 | Encryptx Corporation | Method and apparatus for automatically detecting sensitive information, applying policies based on a structured taxonomy and dynamically enforcing and reporting on the protection of sensitive data through a software permission wrapper |
| GB2418108B (en) * | 2004-09-09 | 2007-06-27 | Surfcontrol Plc | System, method and apparatus for use in monitoring or controlling internet access |
| GB2418999A (en) | 2004-09-09 | 2006-04-12 | Surfcontrol Plc | Categorizing uniform resource locators |
| GB2418037B (en) * | 2004-09-09 | 2007-02-28 | Surfcontrol Plc | System, method and apparatus for use in monitoring or controlling internet access |
| JP4722052B2 (ja) * | 2004-10-15 | 2011-07-13 | ソフトバンクモバイル株式会社 | 連係動作方法及び通信端末装置 |
| US7882236B2 (en) * | 2005-02-04 | 2011-02-01 | Microsoft Corporation | Communication channel model |
| US7500097B2 (en) * | 2005-02-28 | 2009-03-03 | Microsoft Corporation | Extendable data-driven system and method for issuing certificates |
| US7509489B2 (en) * | 2005-03-11 | 2009-03-24 | Microsoft Corporation | Format-agnostic system and method for issuing certificates |
| US8438645B2 (en) | 2005-04-27 | 2013-05-07 | Microsoft Corporation | Secure clock with grace periods |
| WO2006107168A1 (en) | 2005-04-08 | 2006-10-12 | Electronics And Telecommunications Research Intitute | Tool pack structure and contents execution device |
| US8725646B2 (en) * | 2005-04-15 | 2014-05-13 | Microsoft Corporation | Output protection levels |
| US20060265758A1 (en) * | 2005-05-20 | 2006-11-23 | Microsoft Corporation | Extensible media rights |
| US8429755B2 (en) * | 2005-05-26 | 2013-04-23 | Sandisk Technologies Inc. | System and method for receiving digital content |
| GB0512744D0 (en) * | 2005-06-22 | 2005-07-27 | Blackspider Technologies | Method and system for filtering electronic messages |
| KR100728928B1 (ko) * | 2005-07-01 | 2007-06-15 | 삼성전자주식회사 | 기록매체를 통해 오프라인된 영상기기에 컨텐츠 재생권한부여방법 |
| US8239682B2 (en) | 2005-09-28 | 2012-08-07 | Nl Systems, Llc | Method and system for digital rights management of documents |
| US9626667B2 (en) * | 2005-10-18 | 2017-04-18 | Intertrust Technologies Corporation | Digital rights management engine systems and methods |
| US20070204078A1 (en) * | 2006-02-09 | 2007-08-30 | Intertrust Technologies Corporation | Digital rights management engine systems and methods |
| EA200901153A1 (ru) * | 2005-10-18 | 2010-04-30 | Интертраст Текнолоджиз Корпорейшн | Системы и способы на основе механизма управления цифровыми правами |
| US20070156601A1 (en) * | 2006-01-03 | 2007-07-05 | International Business Machines Corporation | Method and system for providing interoperability between digital rights management systems |
| KR101314751B1 (ko) * | 2006-01-26 | 2013-10-02 | 삼성전자주식회사 | 디알엠 설치 관리 방법 및 장치 |
| US8103590B2 (en) * | 2006-02-17 | 2012-01-24 | Yahoo! Inc. | Method and system for managing multiple catalogs of files on a network |
| US8020206B2 (en) | 2006-07-10 | 2011-09-13 | Websense, Inc. | System and method of analyzing web content |
| US8615800B2 (en) * | 2006-07-10 | 2013-12-24 | Websense, Inc. | System and method for analyzing web content |
| US8020149B2 (en) * | 2006-08-04 | 2011-09-13 | Apple Inc. | System and method for mitigating repeated crashes of an application resulting from supplemental code |
| US9654495B2 (en) | 2006-12-01 | 2017-05-16 | Websense, Llc | System and method of analyzing web addresses |
| GB2458094A (en) * | 2007-01-09 | 2009-09-09 | Surfcontrol On Demand Ltd | URL interception and categorization in firewalls |
| GB2445764A (en) * | 2007-01-22 | 2008-07-23 | Surfcontrol Plc | Resource access filtering system and database structure for use therewith |
| AU2008214131B2 (en) * | 2007-02-02 | 2012-06-14 | Websense, Inc. | System and method for adding context to prevent data leakage over a computer network |
| US8015174B2 (en) | 2007-02-28 | 2011-09-06 | Websense, Inc. | System and method of controlling access to the internet |
| US8276167B2 (en) * | 2007-03-21 | 2012-09-25 | International Business Machines Corporation | Distributed pluggable middleware services |
| US20080249943A1 (en) * | 2007-04-04 | 2008-10-09 | Barrs John W | Modifying A Digital Media Product |
| US8892471B2 (en) * | 2007-04-04 | 2014-11-18 | International Business Machines Corporation | Modifying a digital media product |
| US7693871B2 (en) * | 2007-04-04 | 2010-04-06 | International Business Machines Corporation | Modifying a digital media product |
| US11153656B2 (en) | 2020-01-08 | 2021-10-19 | Tailstream Technologies, Llc | Authenticated stream manipulation |
| US11991416B2 (en) | 2007-04-13 | 2024-05-21 | Tailstream Technologies, Llc | Authenticated stream manipulation |
| GB0709527D0 (en) | 2007-05-18 | 2007-06-27 | Surfcontrol Plc | Electronic messaging system, message processing apparatus and message processing method |
| US20090006624A1 (en) * | 2007-06-29 | 2009-01-01 | Microsoft Corporation | Entertainment Access Service |
| JP4990399B2 (ja) * | 2007-09-06 | 2012-08-01 | マイクロソフト コーポレーション | セッションブローカ拡張性アプリケーションプログラムインターフェース |
| US8732236B2 (en) * | 2008-12-05 | 2014-05-20 | Social Communications Company | Managing network communications between network nodes and stream transport protocol |
| US8601482B2 (en) * | 2007-11-02 | 2013-12-03 | Microsoft Corporation | Delegation metasystem for composite services |
| US10013536B2 (en) * | 2007-11-06 | 2018-07-03 | The Mathworks, Inc. | License activation and management |
| US20090157841A1 (en) * | 2007-12-14 | 2009-06-18 | Microsoft Corporation | Encapsulation of online storage providers |
| US20090171762A1 (en) * | 2008-01-02 | 2009-07-02 | Microsoft Corporation | Advertising in an Entertainment Access Service |
| US10475010B2 (en) * | 2008-01-10 | 2019-11-12 | Microsoft Technology Licensing, Llc | Federated entertainment access service |
| US9015842B2 (en) | 2008-03-19 | 2015-04-21 | Websense, Inc. | Method and system for protection against information stealing software |
| US8370948B2 (en) * | 2008-03-19 | 2013-02-05 | Websense, Inc. | System and method for analysis of electronic information dissemination events |
| US8407784B2 (en) * | 2008-03-19 | 2013-03-26 | Websense, Inc. | Method and system for protection against information stealing software |
| US9130986B2 (en) | 2008-03-19 | 2015-09-08 | Websense, Inc. | Method and system for protection against information stealing software |
| US8141129B2 (en) * | 2008-05-29 | 2012-03-20 | Microsoft Corporation | Centrally accessible policy repository |
| US8769640B2 (en) * | 2008-05-29 | 2014-07-01 | Microsoft Corporation | Remote publishing and server administration |
| US8387152B2 (en) | 2008-06-27 | 2013-02-26 | Microsoft Corporation | Attested content protection |
| CA2729158A1 (en) * | 2008-06-30 | 2010-01-07 | Websense, Inc. | System and method for dynamic and real-time categorization of webpages |
| CN106131178A (zh) * | 2008-12-05 | 2016-11-16 | 社会传播公司 | 实时内核 |
| US20100208082A1 (en) * | 2008-12-18 | 2010-08-19 | Band Crashers, Llc | Media systems and methods for providing synchronized multiple streaming camera signals of an event |
| US9069851B2 (en) | 2009-01-15 | 2015-06-30 | Social Communications Company | Client application integrating web browsing and network data stream processing for realtime communications |
| KR20100108970A (ko) * | 2009-03-31 | 2010-10-08 | 삼성전자주식회사 | 디지털 저작권 관리 컨텐츠의 보호 방법 및 장치 |
| EP2443580A1 (en) | 2009-05-26 | 2012-04-25 | Websense, Inc. | Systems and methods for efficeint detection of fingerprinted data and information |
| US20130132733A1 (en) * | 2009-05-26 | 2013-05-23 | Sunil C. Agrawal | System And Method For Digital Rights Management With System Individualization |
| JP5662439B2 (ja) * | 2009-07-17 | 2015-01-28 | アルカテル−ルーセント | 中小企業（ｓｍｅ）におけるデジタル著作権管理（ｄｒｍ）の方法および装置ならびにｄｒｍサービスを提供するための方法 |
| US9015493B2 (en) | 2010-09-16 | 2015-04-21 | Microsoft Technology Licensing, Llc | Multitenant-aware protection service |
| EP2697929A4 (en) | 2011-04-11 | 2014-09-24 | Intertrust Tech Corp | INFORMATION SECURITY SYSTEMS AND METHODS |
| US8516273B2 (en) | 2011-05-31 | 2013-08-20 | Asobe Systems Incorporated | Porting digital rights management service to multiple computing platforms |
| US8082486B1 (en) | 2011-06-09 | 2011-12-20 | Storify, Inc. | Source attribution of embedded content |
| US8769059B1 (en) * | 2012-05-23 | 2014-07-01 | Amazon Technologies, Inc. | Best practice analysis, third-party plug-ins |
| US9626710B1 (en) | 2012-05-23 | 2017-04-18 | Amazon Technologies, Inc. | Best practice analysis, optimized resource use |
| US10740765B1 (en) | 2012-05-23 | 2020-08-11 | Amazon Technologies, Inc. | Best practice analysis as a service |
| US9219648B1 (en) | 2012-05-23 | 2015-12-22 | Amazon Technologies, Inc. | Best practice analysis, automatic remediation |
| US9117054B2 (en) | 2012-12-21 | 2015-08-25 | Websense, Inc. | Method and aparatus for presence based resource management |
| US8888005B2 (en) | 2013-04-12 | 2014-11-18 | David Prokop | Uniquely identifiable drug dosage form units |
| KR101835238B1 (ko) | 2013-07-23 | 2018-03-06 | 에릭슨 에이비 | 매니패스트-기반 자격 집행을 갖는 미디어 분배 시스템 |
| IN2014CH01484A (es) | 2014-03-20 | 2015-09-25 | Infosys Ltd | |
| GB2530245A (en) * | 2014-07-15 | 2016-03-23 | Piksel Inc | Controlling delivery of encrypted media assets |
| CN105871577A (zh) | 2015-01-22 | 2016-08-17 | 阿里巴巴集团控股有限公司 | 资源权限管理方法及装置 |
| US9954832B2 (en) | 2015-04-24 | 2018-04-24 | Encryptics, Llc | System and method for enhanced data protection |
| EP3255597A1 (en) * | 2016-06-12 | 2017-12-13 | Apple Inc. | Managing secure transactions between electronic devices and service providers |
| US10645066B2 (en) * | 2016-11-19 | 2020-05-05 | Alan Earl Swahn | Rights controlled communication |
| CN112565236B (zh) * | 2020-11-30 | 2023-08-01 | 广州酷狗计算机科技有限公司 | 信息鉴权方法、装置、计算机设备及存储介质 |
| CN115408047B (zh) * | 2022-08-11 | 2023-07-25 | 北京大氪信息科技有限公司 | 一种版本发布方法、装置及电子设备 |
Family Cites Families (56)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5715403A (en) * | 1994-11-23 | 1998-02-03 | Xerox Corporation | System for controlling the distribution and use of digital works having attached usage rights where the usage rights are defined by a usage rights grammar |
| US5864620A (en) * | 1996-04-24 | 1999-01-26 | Cybersource Corporation | Method and system for controlling distribution of software in a multitiered distribution chain |
| US5764889A (en) * | 1996-09-26 | 1998-06-09 | International Business Machines Corporation | Method and apparatus for creating a security environment for a user task in a client/server system |
| US6006279A (en) * | 1997-01-21 | 1999-12-21 | Canon Information Systems, Inc. | Plug-in module host framework |
| CA2228185C (en) * | 1997-01-31 | 2007-11-06 | Certicom Corp. | Verification protocol |
| US6389535B1 (en) * | 1997-06-30 | 2002-05-14 | Microsoft Corporation | Cryptographic protection of core data secrets |
| US6122741A (en) * | 1997-09-19 | 2000-09-19 | Patterson; David M. | Distributed method of and system for maintaining application program security |
| WO1999015947A1 (en) * | 1997-09-19 | 1999-04-01 | Hyo Joon Park | Software license control system based on independent software registration server |
| US7809138B2 (en) * | 1999-03-16 | 2010-10-05 | Intertrust Technologies Corporation | Methods and apparatus for persistent control and protection of content |
| US6189146B1 (en) * | 1998-03-18 | 2001-02-13 | Microsoft Corporation | System and method for software licensing |
| US6701433B1 (en) * | 1998-03-23 | 2004-03-02 | Novell, Inc. | Method and apparatus for escrowing properties used for accessing executable modules |
| US6226618B1 (en) | 1998-08-13 | 2001-05-01 | International Business Machines Corporation | Electronic content delivery system |
| US7017188B1 (en) * | 1998-11-16 | 2006-03-21 | Softricity, Inc. | Method and apparatus for secure content delivery over broadband access networks |
| US7073063B2 (en) * | 1999-03-27 | 2006-07-04 | Microsoft Corporation | Binding a digital license to a portable device or the like in a digital rights management (DRM) system and checking out/checking in the digital license to/from the portable device or the like |
| US6973444B1 (en) * | 1999-03-27 | 2005-12-06 | Microsoft Corporation | Method for interdependently validating a digital content package and a corresponding digital license |
| US7024393B1 (en) | 1999-03-27 | 2006-04-04 | Microsoft Corporation | Structural of digital rights management (DRM) system |
| US7103574B1 (en) | 1999-03-27 | 2006-09-05 | Microsoft Corporation | Enforcement architecture and method for digital rights management |
| JP2000293587A (ja) * | 1999-04-09 | 2000-10-20 | Sony Corp | 情報処理装置および方法、管理装置および方法、並びに提供媒体 |
| US6557105B1 (en) * | 1999-04-14 | 2003-04-29 | Tut Systems, Inc. | Apparatus and method for cryptographic-based license management |
| US6560606B1 (en) * | 1999-05-04 | 2003-05-06 | Metratech | Method and apparatus for processing data with multiple processing modules and associated counters |
| US6449720B1 (en) * | 1999-05-17 | 2002-09-10 | Wave Systems Corp. | Public cryptographic control unit and system therefor |
| US6405366B1 (en) * | 1999-05-28 | 2002-06-11 | Electronic Data Systems Corporation | Multi-layered software application interface architecture |
| US6385719B1 (en) * | 1999-06-30 | 2002-05-07 | International Business Machines Corporation | Method and apparatus for synchronizing parallel pipelines in a superscalar microprocessor |
| JP2001118332A (ja) * | 1999-10-20 | 2001-04-27 | Sony Corp | データ配信システムとその方法、データ処理装置、データ使用制御装置および配信用データが記録された機械読み取り可能な記録媒体 |
| US6538656B1 (en) * | 1999-11-09 | 2003-03-25 | Broadcom Corporation | Video and graphics system with a data transport processor |
| JP3614061B2 (ja) * | 1999-12-06 | 2005-01-26 | ヤマハ株式会社 | 自動演奏装置及び自動演奏プログラムを記録したコンピュータ読取り可能な記録媒体 |
| GB2357229B (en) * | 1999-12-08 | 2004-03-17 | Hewlett Packard Co | Security protocol |
| US7213005B2 (en) * | 1999-12-09 | 2007-05-01 | International Business Machines Corporation | Digital content distribution using web broadcasting services |
| US6996720B1 (en) | 1999-12-17 | 2006-02-07 | Microsoft Corporation | System and method for accessing protected content in a rights-management architecture |
| JP2001175605A (ja) | 1999-12-17 | 2001-06-29 | Sony Corp | データ処理装置 |
| US7047411B1 (en) | 1999-12-17 | 2006-05-16 | Microsoft Corporation | Server for an electronic distribution system and method of operating same |
| JP2001175606A (ja) * | 1999-12-20 | 2001-06-29 | Sony Corp | データ処理装置、データ処理機器およびその方法 |
| US6772340B1 (en) | 2000-01-14 | 2004-08-03 | Microsoft Corporation | Digital rights management system operating on computing device and having black box tied to computing device |
| JP2001256318A (ja) * | 2000-03-14 | 2001-09-21 | Sony Corp | コンテンツ取り引きシステムおよびコンテンツ取り引き方法、並びにプログラム提供媒体 |
| US6386894B2 (en) * | 2000-04-28 | 2002-05-14 | Texas Instruments Incorporated | Versatile interconnection scheme for beverage quality and control sensors |
| US6961858B2 (en) * | 2000-06-16 | 2005-11-01 | Entriq, Inc. | Method and system to secure content for distribution via a network |
| US7017189B1 (en) | 2000-06-27 | 2006-03-21 | Microsoft Corporation | System and method for activating a rendering device in a multi-level rights-management architecture |
| US6891953B1 (en) * | 2000-06-27 | 2005-05-10 | Microsoft Corporation | Method and system for binding enhanced software features to a persona |
| US7073199B1 (en) * | 2000-08-28 | 2006-07-04 | Contentguard Holdings, Inc. | Document distribution management method and apparatus using a standard rendering engine and a method and apparatus for controlling a standard rendering engine |
| WO2002023315A2 (en) | 2000-09-12 | 2002-03-21 | Aladdin Knowledge Systems, Ltd. | System for managing rights and permitting on-line playback of digital content |
| US7343324B2 (en) | 2000-11-03 | 2008-03-11 | Contentguard Holdings Inc. | Method, system, and computer readable medium for automatically publishing content |
| JP2004521414A (ja) * | 2000-12-08 | 2004-07-15 | 松下電器産業株式会社 | 配信装置、端末装置、及びこれらで用いられるプログラム、方法。 |
| US6978376B2 (en) * | 2000-12-15 | 2005-12-20 | Authentica, Inc. | Information security architecture for encrypting documents for remote access while maintaining access control |
| CN101783807B (zh) * | 2001-01-17 | 2011-08-10 | 康坦夹德控股股份有限公司 | 使用标准演示引擎作数字权限管理的系统及方法 |
| JP4191902B2 (ja) * | 2001-02-28 | 2008-12-03 | 株式会社日立製作所 | コンテンツ配信装置 |
| AU2002339746A1 (en) * | 2001-05-18 | 2002-12-03 | Imprivata Inc. | System and method for authentication using biometrics |
| US8099364B2 (en) * | 2001-05-31 | 2012-01-17 | Contentguard Holdings, Inc. | Digital rights management of content when content is a future live event |
| US8275716B2 (en) * | 2001-05-31 | 2012-09-25 | Contentguard Holdings, Inc. | Method and system for subscription digital rights management |
| WO2002101490A2 (en) * | 2001-06-07 | 2002-12-19 | Contentguard Holdings, Inc. | Cryptographic trust zones in digital rights management |
| US20030046274A1 (en) * | 2001-08-30 | 2003-03-06 | Erickson John S. | Software media container |
| WO2003034313A2 (en) * | 2001-10-18 | 2003-04-24 | Macrovision Corporation | Systems and methods for providing digital rights management compatibility |
| US7840488B2 (en) * | 2001-11-20 | 2010-11-23 | Contentguard Holdings, Inc. | System and method for granting access to an item or permission to use an item based on configurable conditions |
| US7011214B2 (en) * | 2001-12-28 | 2006-03-14 | Dm & Bb | Private pallet-box cargo shipping system |
| US7747531B2 (en) * | 2002-02-05 | 2010-06-29 | Pace Anti-Piracy | Method and system for delivery of secure software license information |
| US7092527B2 (en) * | 2002-04-18 | 2006-08-15 | International Business Machines Corporation | Method, system and program product for managing a size of a key management block during content distribution |
| US7174021B2 (en) * | 2002-06-28 | 2007-02-06 | Microsoft Corporation | Systems and methods for providing secure server key operations |
-
2002
- 2002-06-28 US US10/185,906 patent/US7631318B2/en not_active Expired - Fee Related
-
2003
- 2003-06-13 DE DE60307736T patent/DE60307736T2/de not_active Expired - Lifetime
- 2003-06-13 AT AT03013564T patent/ATE337671T1/de not_active IP Right Cessation
- 2003-06-13 EP EP03013564A patent/EP1376980B1/en not_active Expired - Lifetime
- 2003-06-13 ES ES03013564T patent/ES2271427T3/es not_active Expired - Lifetime
- 2003-06-17 NO NO20032749A patent/NO333104B1/no not_active IP Right Cessation
- 2003-06-30 JP JP2003188926A patent/JP4489382B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| NO20032749D0 (no) | 2003-06-17 |
| ATE337671T1 (de) | 2006-09-15 |
| JP4489382B2 (ja) | 2010-06-23 |
| US20040003139A1 (en) | 2004-01-01 |
| DE60307736D1 (de) | 2006-10-05 |
| NO20032749L (no) | 2003-12-29 |
| NO333104B1 (no) | 2013-03-04 |
| DE60307736T2 (de) | 2006-12-28 |
| EP1376980B1 (en) | 2006-08-23 |
| EP1376980A1 (en) | 2004-01-02 |
| JP2004062890A (ja) | 2004-02-26 |
| US7631318B2 (en) | 2009-12-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2271427T3 (es) | Arquitectura de servidor enchufable asegurada para sistemas de gestion de derechos digitales. | |
| KR100949657B1 (ko) | 유연한 권리 템플릿을 이용하여 권리 관리 시스템에서디지털 컨텐츠에 대한 서명된 권리 라벨(ｓｒｌ)을 얻기 | |
| US7891007B2 (en) | Systems and methods for issuing usage licenses for digital content and services | |
| KR100971854B1 (ko) | 보안 서버 키 동작을 제공하기 위한 시스템 및 방법 | |
| EP0798892B1 (en) | Creation and distribution of digital documents | |
| JP4627624B2 (ja) | 組織などの限定された領域内におけるデジタル著作権管理（ｄｒｍ）システムによるデジタルコンテンツのパブリッシュ | |
| US7353402B2 (en) | Obtaining a signed rights label (SRL) for digital content and obtaining a digital license corresponding to the content based on the SRL in a digital rights management system | |
| JP4724360B2 (ja) | ディジタル権利管理システムにおいて権利テンプレートを使用してディジタルコンテンツのための署名権利ラベル（ｓｒｌ）を取得する方法 | |
| ES2635121T3 (es) | Arquitectura flexible de concesión de licencia en sistemas de gestión de derechos de contenido | |
| JP2004246902A (ja) | 組織などの限定された領域内におけるデジタル著作権管理（ｄｒｍ）システムによるデジタルコンテンツのパブリッシュ | |
| JP2006504176A (ja) | コンテンツ操作を許可する方法及び装置 |