1
MÉTODO PARA ADMINISTRAR ACCESOS Y RECURSOS AL VERIFICAR CONDICIONES Y CONDICIONES PARA USO CON ELLO
ANTECEDENTES DE LA INVENCIÓN Una de las cuestiones más importantes que limitan la amplia distribución de trabajos digitales (esto es, documentos u otro contenido en formas legibles por computadora) , por medio de medios electrónicos y el Internet en particular, es la falta actual de una capacidad para poner en vigor los derechos de propiedad intelectual de los propietarios de contenido durante la distribución y uso de trabajos digitales. Los esfuerzos par resolver este problema se han denominado "Administración de Derechos de Propiedad Intelectual" ("IPRM" por sus siglas en inglés), "Administración de Derechos de Propiedad Digital" ( "DPRM" por sus siglas en inglés) , "Administración de Propiedad Intelectual" ("IPM" por sus siglas en inglés) , "Administración de Derechos" ("RM" por sus siglas en inglés) , y "Administración de Derechos de Autor Electrónicos" ("ECM" por sus siglas en inglés) , colectivamente referidos como "Administración de Derechos Digitales (DRM por sus siglas en inglés)" en la presente. Existen diversas cuestiones a ser consideradas al efectuar un sistema DRM. Por ejemplo, la autentificación, autorización, cuenta, pago y depuración financiera, especificación de derechos, verificación de REF: 152698 2
derechos, puesta en -vigor de los derechos y cuestiones de producción de documentos se deben atender. Las patentes de E.U.A. 5,530,235; 5,634,012; 5,715,403; 5,638,443; y 5,629,940, las descripciones de la cual se incorporan en la presente como referencia, describen sistemas DRM que atienden estas cuestiones . Por ejemplo, la patente de E.U.A. No. 5,634,012, describe un sistema para controlar la distribución de documentos digitales. Cada dispositivo resultante tiene un depositario asociado con él. Un conjunto predeterminado de etapas de transacción de uso definen un protocolo utilizado por los depositarios par poner en vigor los derechos de uso asociados con un documento. Los derechos de uso persisten con el contenido de documento. Los derechos de uso especifican diversas formas de uso de contenido tal como ver solamente, usar una vez, la distribución y similares. Las precondiciones tal como el pago de una tarifa, prueba de identidad u otras condiciones, se pueden requerir previo a permitir el acceso al contenido de conformidad con los derechos de uso. Una vez que se satisfacen las precondiciones se garantiza el acceso al contenido. El concepto de acceso condicional es bien conocido también en aplicaciones de control de acceso. Por ejemplo, se sabe otorgar acceso a los recursos de redes con la entrada de un nombre de registro y palabra clave.
3
El concepto de acceso condicional es una base para el control de acceso y los sistemas DRM. Una precondición típica, esto es una condición para otorgar acceso, define una lista de usuarios autorizados junto con un conjunto de derechos y condiciones de acceso para un recurso dado. Las precondiciones asociadas con un recurso dado se pueden definir como recursos asociados con ciertos usuarios. Esto se conoce como un control de acceso "basado en el rol" . También se pueden definir las precondiciones por reglas en un proceso conocido como control de acceso basado en reglas. Ambos tipos de precondiciones se expresan como una lista de control de acceso, que es un conjunto de recursos o reglas definidos en algún idioma o estructura de datos. El acceso condicional se implementa típicamente por la mayoría de los sistemas como un proceso de autorización en el cual a un director (por ejemplo, una persona, un sistema o un proceso) se le permite el acceso a un recurso protegido después de que se cubren y/o verifican ciertas condiciones. SUMARIO DE LA INVENCIÓN Un primer aspecto de la invención es un método para administrar el uso de recursos protegidos dentro de un sistema de recursos. El método comprende otorgar acceso a un recurso protegido por un director cuando se satisfacen las precondiciones asociadas con el recurso protegido y el director, permitiendo que el director continúe con acceso al 4
recurso protegido mientras que las condiciones durante el acceso asociadas con el recurso protegido y el director se satisfacen, y finalizar el acceso al recurso protegido por el director cuando un evento de terminación sucede . El evento de terminación puede ser la satisfacción de condiciones posteriores diferentes de las condiciones durante el acceso o una falla para continuar la satisfacción de las condiciones durante el acceso . Un segundo aspecto de la invención es un método para administrar el uso de recursos protegidos con un sistema de recursos . El método comprende la preparación de condiciones que se deben satisfacer para tener acceso a un recurso protegido, y la preparación de condiciones durante el acceso que se deben cubrir para continuar el acceso al recurso protegido. Cuando el recurso protegido es inactivo, la puesta en vigor de las precondiciones hasta que se cubren las precondiciones, y la producción de un recurso protegido activo y la puesta de vigor en condiciones durante el acceso cuando las precondiciones se han satisfecho. Un tercer aspecto de la invención es una especificación de una condición adaptada para asociar una condición con un recurso protegido, para controlar el recurso protegido dentro de un sistema para administrar recursos protegidos. La especificación comprende una designación de recursos que indican al recurso protegido que la condición asociada con 5
una variable de estado indica una situación del recurso con respecto a la condición, una especificación del método indica una forma por la cual el valor de la variable del estado se puede obtener desde un dispositivo. BREVE DESCRIPCIÓN DE LAS FIGURAS La invención se describe a través de una modalidad preferida y las figuras anexas en el cual : La Figura 1 es un diagrama de bloques de una arquitectura de computadora de la modalidad preferida; La Figura 2 es una ilustración esquemática de los estados de un modelo de control de acceso convencional ; La Figura 3 es una ilustración esquemática de los estados de la modalidad preferida; La Figura 4 es un diagrama de flujo del proceso de autorización de la modalidad preferida; La Figura 5 es una ilustración esquemática de una condición de la modalidad preferida; y La Figura 6 es una ilustración esquemática de un estado de condición de la modalidad- preferida; DESCRIPCION DETALLADA DE LA INVENCIÓN Diferentes tipos de recursos requieren diferentes tipos de condiciones y mecanismos diferentes para protegerlos de un uso autorizado. El solicitante ha extendido las precondiciones convencionales para incluir condiciones para la protección y compromiso con lo cual se obtiene un 6
mecanismo flexible para expresar y poner en vigor tales condiciones . En las condiciones de modalidad preferida, son parte del ciclo de vida completo de los recursos protegidos. Esto significa que las condiciones no se evalúan solamente previo a permitir el acceso, sino que también se evalúan durante el consumo actual del recurso. Adicionalmente, se asocian condiciones con el recurso protegido y el estado del recurso protegido. La asociación de condiciones con diversos estados de un recurso protegido, proporciona a los propietarios de contenido o proveedores de servicio una forma flexible de proteger diferentes tipos de recurso. Los recursos pueden ser contenido digital, hardware, programas de software, espacio de memoria, bienes, servicios (incluyendo servicios de red) , tiempo, tarifas, derechos de uso o una licencia. Los derechos de uso, especifican formas de uso. Por ejemplo, una forma de uso puede incluir la capacidad de utilizar un artículo en una forma especifica por un periodo especifico de tiempo. Además, los derechos de uso pueden especificar derechos de transferencia tales como los derechos de distribución y pueden permitir otorgar los derechos de uso a otros o la derivación de derechos de uso . La modalidad preferida verifica y valida condiciones previo, durante y después del uso o consumo de recursos protegidos. Las condiciones se pueden representar como un 7
estado de condición de manera que el estado actual e historia de cada condición se pueda registrar y usar posteriormente. Las "variables de estado" , rastrean condiciones potencialmente dinámicas. Las variables de estado son variables que tienen valores que representan la situación de un recurso u otras condiciones dinámicas . Las variables de estado se pueden rastrear, y el valor de las variables de estado se puede usar en una condición. Por ejemplo un derecho de uso como un recurso, puede ser el derecho a ver el contenido y una condición puede ser aquella en la que no se registran otros usuarios dentro de la red cuando se ejercita el derecho de uso. En este ejemplo, cuando el valor del estado adecuado indica que otros usuarios están registrados, la condición ya no se satisface y el contenido ya no se puede ver o se finaliza la vista. La Figura 1 ilustra la arquitectura de la computadora 10 de la modalidad preferida. Las condiciones 80 se describen en detalle a continuación y se pueden preparar con la solicitud de preparación 70 asociada con el distribuidor de un artículo, un proveedor de servicio de contenido, un gerente de empresa o cualquier otra parte que desea controlar el acceso a los recursos tales como el contenido digital . Se puede usar una gramática tal como XrML™ para especificar las condiciones 80. Sin embargo, las condiciones 80 se pueden especificar de cualquier forma. Un usuario opera dentro del 8
ambiente del cliente- 30, incluyendo una computadora u otro dispositivo asociado con el usuario. La aplicación de software 20, tal como producir una máquina u otra aplicación se puede instalar en el ambiente del cliente 30. El gerente de acceso 40 controla acceso a los recursos protegidos 100 y los recursos derivados 100a en la forma establecida a continuación. El gerente de acceso 40, un dispositivo de computadora en la modalidad preferida, atiende aspectos de seguridad de acceso a los recursos 100 y el recurso derivado 100a. En particular, el recurso de gerente 40 puede autentificar los mensajes al verificar y validar firmas, tal como una firma criptográfica u otras características de identificación de los mensajes en una forma conocida. El gerente de ¦ acceso 40 incluye dos componentes primarios, el gerente de recursos 42 y el validador de la condición 44. El gerente de recursos 42 es responsable del registro de los recursos, la transformación de los recursos y la terminación de los recursos. La "Transformación" se refiere a derivar el recurso derivado 100a del recurso 100. Por ejemplo, en el caso en donde el recurso es un archivo encriptado que representa una imagen o similar, los recursos derivados 100a pueden incluir la imagen clara misma y la dirección de la memoria que mantiene la imagen. Durante el registro de recursos la dirección de la memoria que mantiene la imagen se registra 9
por el depositario del recurso 46 del gerente de recursos 42, de manera que cualquier acceso a esa memoria, esto es, un recurso derivado 100a, se puede rastrear. Además, se pueden insertar marcas de rastreo (tal como una marca de agua) en la imagen de manera que se pueda rastrear, en cualquier momento.
El validador de condición 44 observa las condiciones establecidas y administra el estado actual del sistema. El validador de condición 44 interactúa con el gerente de recursos 46, como se describe en mayor detalle a continuación, para controlar el recurso derivado 100a. Cuando el estado del sistema actual ya no es valido, el validador de condición 44 solicita al gerente de recurso 42 que elimine (o desactive) todos los recursos derivados 100a o que notifique la aplicación 20 que el uso de los recursos derivados 100a ya no se permite como se describe en mayor detalle a continuación. El acceso al recurso protegido 100 se basa en las condiciones 80. Este tipo de condición se refiere como una condición de acceso o precondición. Sin embargo, al asociar las condiciones con el recurso y el estado de recurso, se hace posible proteger el recurso 100 en diversas etapas durante su ciclo de vida. El recurso 100 se puede proteger antes de que se le otorgue acceso a un usuario, cuando se le otorga acceso durante el uso actual del recurso y después del uso del recurso. Las condiciones 80 que se asocian con el 10
ciclo de vida completo del recurso protegido se pueden expresar por el uso de una gramática que incluye estructuras de datos, conjuntos de reglas o un idioma tal como XrML™. La modalidad preferida utiliza XrML™ como el idioma para expresar condiciones. Para proteger el recurso 100, se pueden imponer condiciones 80 en el recurso 100 mismo, o algunos otros recursos tangibles o intangibles incluyendo aquellos recursos que hagan algunos ambientes de ejecución tal como la aplicación 20 del ambiente de cliente 30, a partir de la cual se tiene acceso y se usa el recurso protegido 100. Las condiciones 80 pueden ser la identidad de un usuario o grupo de usuarios a quienes se les da acceso como principales y que utilizan el recurso protegido 100. Los ejemplos de las condiciones 80 se establecen a continuación como se expresan en el lenguaje XrML™. El ejemplo A expresa una condición asociada con el principal "Edgar" , a quien se le otorga el derecho a "ver" el contenido digital protegido "XrML Boo " . El ejemplo B expresa una condición asociada con un grupo de principales, esto es todas las personas que caen bajo la categoría "Empleado para guardar Contenido" a quienes se les otorga el derecho de imprimir el trabajo digital protegido "XrML BooK" . Ejemplo A: <licencia> 11
<inventario <licencia de trabajo digital ID Parte="Xr LBooK" /> <licencia del titularID Parte="Edgar" /> </inventario> <otorgar> <licencia del titularPartDRef="Edgar" /> <vista/> <licencia de trabajo digitalID
ParteRef="XrMLBook" /> </otorgar> </licencia> Ejemplo B: <licencia> <inventario> <licencia de trabajo digitalID Parte="XrMLBook" /> </inventario> <otorgar> <paratodos varNombre="Empleado de
ContenGuard" /> <director varRef="Empleado de ContenGuard" /> <imprimir/> <licencia de trabajo digitalID
Parte="XrMLBook"/> </otorgar> </licencia> 12
Condiciones 80 - pueden ser las condiciones en los directores que deben poseer ciertas propiedades tal como cierto titulo o derechos tal como una autorización de seguridad. Un ejemplo C expresa la condición que deben poseer los directores como distintivos del gerente. Ejemplo C: <licencia> <inventario> <licencia de trabajo digitalPartD="XrMLBook" /> <Licencia del titularPartD="Edgar" /> </inventario> <otorgar> <para todos varNombre=" cualquiera" /> <director varRef=" cualquiera" /> <posesión de propiedad/> <distintivo> <puesto>Gerente</puesto> </distintivo> <vista/> <licencia de trabajo digitalID
ParteRef="XrMLBooK"/> </otorgar> /licencia> Las condiciones 80 pueden ser condiciones con el intervalo de tiempo para tener acceso al artículo protegido.
13
El ejemplo D a continuación expresa condiciones que el poseedor de una clave "Edgar" como director puede ver el contenido en libro "XrML booK" no antes de 05/29/2002 y no despu s de 05/29/2003. Ejemplo D: <licencia> <inventario <licencia de trabajo digitalID Parte="XrMLBook" /> <licencia del titularID Parte="Edgar" /> </inventario> <otorgar> <licencia del titularID ParteRef="Edgar" /> <vista> <licencia de trabajo digitalID ParteRef="XrMLBook" > <Intervalo de validez> <no antes>2002-05-29T00 : 00 : 00</no antes> <no después de>2003-05-29T00 : 00 : 00</no después de> </Intervalo de validez> </otorgar> </licencia> Las condiciones 80 que se pueden relacionar con la ubicación física del director de recurso usado para el contenido de acceso. El ejemplo E a continuación expresa la condición que cualquiera actualmente en los Estados Unidos 14
puede imprimir el contenido de "XrML Book" . E emplo E: <licencia> <inventario> <licencia de trabajo digitalID Parte="XrMLBook" /> </inventario <otorgar> <para todos varNombre="cualquiera" /> <director verRef="cualquiera"/> <imprimir/> <licencia de trabajo digitalID Parte="XrMLBook" /> <territorio> <país>US</país> </territorio </otorgar> </licencia> Las condiciones 80 pueden especificar una cuota que el director debe pagar para tener acceso. El ejemplo F a continuación expresa la condición de que cualquiera puede imprimir el contenido "XrML book" con el pago de una cuota de $3.10. El ejemplo G a continuación expresa la condición de que cualquiera debe imprimir el contenido de "XrML book" con el pago de una cuota de $3.10 por cada impresión. El ejemplo H a continuación expresa la condición de que cualquiera puede observar el contenido de que "XrML book con el pago de una 15
cuota de $10.00 por hora de tiempo de vista. Ejemplo F: <licencia> <inventario> <licencia de trabajo digitalID Parte="XrMLBook" /
</inventario> <otorgar> <para todos varNombre="cualquiera"/> <director varRef="cualquiera" /> <imprimir> <licencia de trabajo digitalID Parte="XrMLBook" / <derechos <pago Libre> <tasa de divisas="USD">3.10</tasa> </pago Libre> <para> <aba> <institución>123456789></institución> <cuenta>987654321</cuenta> </aba> </to> </derechos> </otorgar> </licencia> Ejemplo G: 16
<licencia> <inventario> <licencia de trabajo digitalID Parte="XrMLBook" /> </inventario> <otorgar> <para todos varNombre=" cualquiera" /> <director varRef="cualquiera"/> <imprimir/> <licencia de trabajo digitalID Parte="XrMLBooK"/> <derechos> <pagoPorUso> <tasa de divisas="USA" >3.10</tasa> </pagoPorUso> </derechos> </otorgar> </licencia>
Ejemplo H: <licencia> <inventario>' <licencia de trabajo digitalPartD="XrMLBooK"/> </inventario> <otorgar> <para todos varNombre="cualquiera" /> 17
<director varRef=" cualquiera" /> <vista/> <licencia de trabajo digitallD ParteRef="XrMLBook"/> <derechos> <pago Medido <tasa de divisas="USD" >10.00</tasa> <per>PTlH</per> <fase>PT10M</fase> </pagoMedido> <para> <aba> <institución>123456789></institución> <cuenta>987654321</cuenta> </aba> </para> </derechos> </otorgar> </licencia>
El ejemplo I a continuación expresa la condición de que cualquiera pueda imprimir el contenido pero ejercitar el derecho de imprimir se rastreará por un servicio de rastreo antes de la impresión. Ej emplo I : <licencia> 18
<inventario> <licencia de trabajo digitalID Parte="XrMLBook" /> <licencia del titularlo Parte="Edgar"/> </inventario> <otorgar> <para todos varNombre="cualquiera" /> <director varRef=" cualquiera" /> <imprimir/> <licencia de trabajo digitalPartDRef="XrMLBook"/> <Reporte de rastreo> <Referencia de estado> <uddi> <Clave de servicio> <uuid> ... </uuid> </serviceKey>- </uddi> <servicio Param> </servicio Param> </Referencia de estado> </Reporte de rastreo </otorgar> </licencia> Las condiciones 80 también pueden ser condiciones en el sistema en cual se consume el recurso 100. Por ejemplo, la 19
condición 80 puede requerir que el sistema tenga un mecanismo de seguridad autorizado u otro hardware o software específico o solamente un número máximo específico de usuario se puede registrar . Las condiciones 80 pueden especificar el depositario u otro dispositivo en el cual el recurso 100 tal como el contenido reside. Las condiciones 80 se pueden relacionar al aviso de aprobación que el director debe obtener antes de usar los recursos protegidos 100. Las condiciones 80 pueden requerir notificación antes o después de usar el recurso 100. Las condiciones 80 pueden especificar los derechos previos relacionados con el recurso protegido 100 u otro recurso. Las condiciones 80 también pueden imponerse en otras condiciones 80 tal como para verificar una condición. Por supuesto las condiciones 80 no se limitan a los ejemplos anteriores sino puede ser cualquier restricción, obligación o requerimiento que esté asociado con el recurso protegido 100 como precondiciones, durante las condiciones de acceso y posteriores al acceso. También, aunque los ejemplos anteriores se expresan usando las condiciones XrML™ no se limitan a o por XrML y se pueden expresar de cualquier manera . La Fig. 5 ilustra esquemáticamente la condición 80 de conformidad con la modalidad preferida. La condición 80 incluye la designación del recurso 42 que se puede expresar 20
implícita o explícitamente. Por ejemplo, en el ejemplo A anterior, la designación del recurso 42 se indica por el atributo "Idparte de licencia" de los elementos de "Trabajo digital". La condición 80 también incluye las variables de estado 44, y la especificación del método 46 indica como se pueden obtener los valores de las variables de estado 44. La especificación del método 46 puede incluir las ubicaciones en donde los valores de las variables ed estado 44 se almacenan (tal como un servidor remoto que administra una condición) , el protocolo de comunicación para comunicar con el servidor en donde se administra la condición y algunos parámetros necesarios para obtener el valor (tales como los parámetros de servicio, etc.). Alternativamente, el método puede ser de código duro en el sistema y se puede omitir la especificación del método. Como se observa arriba, las variables de estado 44, representan la situación de la condición 80. La colección de todas las variables de estado 44 para un derecho dado se refieren en la presente como "estado de derechos" . Cada variable de estado 44 tiene un valor correspondiendo en cualquier momento en tiempo para el director, derecho y recurso. La colección de todas las variables de estado 44 de una condición 80 se refieren simplemente como un "estado de condición" en la presente. La Fig. 6 ilustra el estado de condición 50 el cual incluye la condición 80, y los valores 21
actuales 52 para las - variables de estado 44 de la condición 80. La especificación del método 56 indica el método usado para obtener los valores actuales 52 de las variables de estado 44, que incluye potencialmente una fuente de la cual se obtiene el valor, la firma digital de una credencial, el Id de sesión de la solicitud y cualesquiera otra información adecuada. Observar que la especificación del método 56 se puede considerar redundante con la especificación del método 46 y puede ser meramente una reiteración del mismo. Sin embargo en algunos casos, la especificación del método 56, usada para obtener realmente los valores 52, puede ser diferente de la especificación del método 46 que se sugiere para el uso de la condición 80. Al usar el estado de condición 50 para representar la condición 80 para un derecho, simplifica el proceso de verificar las condiciones 80 debido a que toda la información necesaria para verificar la condición 80 es fácilmente accesible. El estado de condición 50 se construye y luego se usa cuando quiera que se evalúe y verifique la condición correspondiente 80. Cada estado es condición 50 puede obtener toda la información necesaria para verificar los valores 52 de las variables de estado 44. Una colección de los estados de condición 50 para un derecho dado asociado con un principal autentificado y un recurso protegido 100 se refiere como un estado de sistema en la presente.
22
Un director aut-entificado es un usuario que ha sido procesado por un sistema que valida la autenticidad de ese usuario por ejemplo cuando un usuario exitosamente se registra con un nombre de usuario y una palabra clave, el usuario se vuelve un director autentificado o solamente un director. Al usar el concepto de estado de sistema, la condición 80 para un conjunto dado de derechos se define como un conjunto de estados requeridos del sistema bajo los cuales in director se permite tener acceso al recurso protegido 100. Cuando un director autentificado desea tener acceso a un recurso protegido 100, el estado de sistema cambia de una estado original a un estado autorizado. Una vez que el sistema está en un estado autorizado, el director luego puede tener acceso a recurso protegido 100 para una operación autorizada. En muchos casos, no es el director autentificado mismo el que realmente tiene acceso al recurso protegido 100. Por ejemplo, el acceso se puede delegar a otro director autentificado tal como una aplicación resultante, servicio, o similar. Aunque el recurso protegido 100 se tiene acceso y se consume, el conjunto de condiciones de preacceso 80 para otorgar un acceso inicial ya puede ser aplicable para autorizar un acceso continuo. También, al consumir el recurso protegido 100 se puede transformar el recurso en un conjunto temporales, esto es, derivado 100a, a partir de los cuales las condiciones de acceso 80 impuestas 23
en los recursos originales también son aplicables. Con objeto de proteger el recurso 100 y sus recursos derivados 100a aunque tenga acceso, la modalidad preferida utiliza un concepto para autorización y protección denominado "Condiciones durante el acceso" que se describe en detalle a continuación . En un sistema convencional, los recursos están en uno de dos estados. Como se ilustra en la figura 2. Cuando el recurso 100 esta inactivo el sistema esta en un estado original 102 hasta que se satisfacen en las precondiciones. En ese momento, el recurso 100 se vuelve activo y el sistema entra al estado autorizado o activo 104. Para incrementar el control sobre los recursos, la modalidad preferida define 2 estados adicionales además del estado original y el estado autorizado. Como se ilustra en la figura 3, durante el uso o acceso del recurso protegido 100, el estado del sistema cambiara a través de los siguientes estados : estados original 102, estado autorizado 104, estado de uso 106 y estado final 108. Las condiciones 80 se pueden definir para cada estado, que se debe reunir con objeto de moverse al siguiente estado o continuar dentro del mismo estado. Como se observa arriba con referencia respecto a la figura 1, se pueden definir las condiciones 80 y preparar usando la aplicación de preparación 70 incluyendo cualquier interfaz de usuario necesaria y editando las capacidades. Las condiciones 80 que necesitan 24
satisfacerse para entrar al estado autorizado se denominan precondiciones. Las condiciones 80 que necesitan cubrirse durante el uso del recurso 100 se denominan condiciones durante el acceso y las condiciones 80 que se requieren al final del uso se denominan condiciones posteriores . El validador de condición 44 puede llamar a las condiciones de requisito 80 para cada estado. Las condiciones durante el acceso son condiciones 80 que se transfieren del recurso original 100 a si mismas y cualquiera de los recursos derivados 100a, mientras se tiene acceso y se consumen por un director autentificado. Por ejemplo, si el recurso 100 es un documento que se despliega en una pantalla de una ambiente de cliente 30 durante la operación autorizada "vista" , luego los recursos derivados 100a pueden incluir la memoria que contiene los datos del documento, el formato de presentación del documento y las ventanas desplegadas respectivamente. Los recursos derivados 100a serán todos protegidos por el conjunto de condiciones durante el acceso. En otras palabras, el director tendrá solamente acceso a los recursos derivados 100a con tal de que las condiciones durante el acceso se satisfagan. Las condiciones durante el acceso se pueden definir de la misma manera que otras condiciones 80. Otro ejemplo es donde una aplicación tal como la aplicación 20 u otro usuario requiere un servicio que es un 25
recurso protegido 100-. Una vez que se autoriza la solicitud, la aplicación que ejecuta el servicio se puede considerar como un recurso derivado y se somete al conjunto de condiciones durante el acceso mientras se ejecuta el servicio. Las condiciones durante el acceso cambian continuamente el estado del sistema hasta que los recursos derivados ya no se usan o el estado de sistemas se vuelve desautorizado. Una vez que se termina la operación requerida, ya sea obligatoria o voluntaria, todos los recursos derivados 100a protegidos por condiciones durante el acceso se eliminan (o inactivan) y el estados del sistema luego se transfiere al estado final por el conjunto de condiciones posteriores al acceso . Las condiciones 80 después o durante el uso o acceso de un recurso puede o no cambiar. Esas condiciones con estados sin cambios se denominan condiciones sin estado, mientras que las condiciones que cambian después o durante el uso del recurso se denominan condiciones del estado. Las precondiciones 80 son usualmente condiciones sin estado 80 y se usan para controlar el acceso al documento protegido. Las condiciones durante el acceso y las condiciones posteriores son usualmente condiciones de estado 80. Se usan para controlar el tiempo de vida del recurso protegido 100 (por ejemplo, el recurso protegido 100 puede tener acceso una vez que sea accedido un número especifico de usuario registrados 26
en una red) . Con estos tipos expandidos de condiciones 80 asociados con etapas diferentes del recurso protegido 100, la modalidad preferida proporciona un mecanismo para autorizar el uso del recurso protegido 100 y para proteger y rastrear el recurso 100 mientras se usa. Como se usa en la figura 3 y con referencia a los elementos de la figura 1, un sistema de conformidad con la modalidad preferida avanza a través de 3 etapas. La etapa de autorización de acceso 302 es una etapa en la cual el gerente de acceso 40 autoriza a un director autentificado para tener acceso al recurso protegido 100 para una operación autorizada a través de verificar que se satisfacen las precondiciones. La etapa de protección del recurso 304 es una etapa en la cual el gerente de acceso 40 protege el recurso 100 y sus recursos derivados 100a mientras se usan para verificar que las condiciones durante el acceso permanecen satisfechas. La etapa de terminación de la operación 306 es una etapa en la cual el gerente de acceso 40 finaliza el uso del recurso protegido 100 y los recursos derivados 100a para una operación dada cuando se satisfacen las condiciones posteriores al acceso o las condiciones durante el acceso se detiene de otra manera y se satisfacen. En situaciones recurrentes, en la cual sedan accesos múltiples para el mismo recurso 100, la condición posterior puede ser igual que la precondición del siguiente ciclo. En 27
tal caso, se puede usar un parámetro no estático con objeto de evitar situaciones infinitas de circuito. Por ejemplo, una condición dependiente del tiempo o una condición modificada o impuesta por una entidad externa tal como la intervención humana . La autorización del acceso otorga a un director autentificado los derechos para tener acceso al recurso protegido 100 para una operación autorizada. La figura 4 ilustra un procedimiento de la autorización del acceso de conformidad con la modalidad preferida, que incluye recolectar el estado del sistema actual con base en la lista de condiciones 80 asociadas con el director autentificado, operación y recursos protegido 100 en la etapa 400. Cada condiciones de estado 50 se puede obtener del sistema local o del sistema remoto de un dispositivo una aplicación, un depositario, un servicio por un gerente de acceso 40. El resultado de la etapa 400 es el estado original. En la etapa 402, los valores actual 52 de cada variable de estado 44 en las precondiciones se recolecta por el gerente de acceso 40. los valores actuales 52 se pueden ensamblar en un registro, un documento XML por ejemplo. La información usada para construir el registro se puede autentificar (por ejemplo, la autentificación del director o el recurso 100) . En la etapa 404, se evalúan las precondiciones esto es, se ponen en vigor contra el registro. Por ejemplo, la información almacenada en 28
el registro que contiene un valor actual 52 para cada variable de estado 44 de las precondiciones, se puede aceptar y/o someter a diversos procesamientos tal como verificar una firma de registro o reevaluar todos los valores de precondición. Si la puesta en marcha es exitosa, el recurso 100 y cualesquiera recursos derivados 100a entran al estados autorizado en la etapa 406. Dependiendo del método usado por el validador de la condición 42 al validar el conjunto de condiciones de preacceso, el procedimiento de autorización se puede clasificar como voluntario u obligatorio. Un proceso que acepta los valores de las variables de estado 44 almacenadas en el . registro antes discutido de denomina un proceso voluntario, y un sistema que desafía esos valores se llama un proceso obligatorio. En un proceso obligatorio el recurso protegido 100 y todos sus recursos derivados 100a se desactivan tan pronto como cualquier condición 80, incluyendo las precondiciones, condiciones durante el acceso o condiciones posteriores, no se puede satisfacer. Cuando se inactivan los recursos 100 o los recursos derivados 100a (o se vuelven inválidos) la aplicación 20 ya no puede tener acceso al recurso protegido 100. En un proceso voluntario, la aplicación 20 se notifica si cualquier condición 80 no se pueden satisfacer y se vuelve válida. La aplicación 20 luego es responsable de inactivar el recurso protegido 100 y los 29
recursos derivados 100a. La decisión sobre si la inactivación se puede hacer automáticamente o con intervención humana. La etapa de puesta en vigor 404 cambiara el sistema de sus estado original aun estado autorizado (etapa 406) o aun estado rechazado (etapa 404) . En un estado autorizado, el recurso protegido 100 se libera al director requerido o su director delegado y durante las condiciones comienzan a ponerse en vigor. Observar que durante las condiciones de acceso pueden ser diferentes de las precondiciones para proporcionar un control flexible de los recursos 100. Como se observa arriba, la protección del recurso protege el recurso protegido inicial 100 y sus recursos derivados, 100a al poner en vigor el conjunto de condiciones durante el acceso. El estado autorizado retornado del estado de autorización con acceso contiene la lista de condiciones durante el acceso para ponerse en vigor durante la operación autorizada. En un sistema obligatorio, todos los recursos derivados 100a se pueden registrar con el depositario del recurso 46 del gerente del recurso 42 cuando se generan y usan los recursos derivados 100a. Si cualquier condición durante el acceso se vuelve un gerente de recurso invalido 42 desactivara el acceso al recurso protegido 100 y los recursos derivados 100a por la aplicación 20. En otros tipos de sistemas, por ejemplo un "sistema de rastreo", un objeto rastreado tal como una marca especial o 30
ID, se inserta en -un recurso derivado 100a durante el registro y transformación del recurso. Esto permite el rastreo de los recursos por el componente de protección del recurso. La marca de inserción puede estar en un formato transparente para la aplicación que procesa el recurso derivado 100a. Los sistemas de rastreo pueden ser sistemas obligatorios o voluntarios. La terminación de una operación autorizada ejecuta el conjunto de condiciones posteriores (si algunas están presentan) . La ejecución de las condiciones posteriores cambia permanentemente el estado del sistema y afecta a la siguiente solicitud para tener acceso al recurso 100. Por ejemplo, si una condición posterior es la eliminación del acceso al recurso 100 después de que se alcanzado un limite de ejercicio, cuando se alcanza el limite el recurso 100 se elimina o se toma alguna otra acción que desactiva o evita el acceso. La terminación de la operación pueden incluir la terminación de recursos. El gerente de recurso 42 puede eliminar (inactivar) los recursos derivados 100a cuando se finaliza la operación, ya sea que se obligue o no a terminar la operación, o la aplicación se determina voluntariamente la operación. La eliminación (o inactivación) del recurso derivado 100a es importante en el proceso de protección del recurso 100. El validador de condición 44 compromete el uso del recurso protegido 100 y pone en vigor el conjunto de 31
condiciones posterio-res . El validador de condición 44 invalidará (inactivará) el . recurso protegido 100 si el recurso 100 se vuelve inválido como resultado del cambio en el estado de sistema. La modalidad preferida puede utilizar diversos dispositivos tal como computadoras personales, servidores, estaciones de trabajo, PDA, clientes delgados y similares. Por ejemplo, el ambiente del cliente puede ser un dispositivo portátil tal como un teléfono móvil o PDA. Se pueden utilizar diversos canales para la comunicación. Además, se pueden integrar diversas funciones en un dispositivos. Los dispositivos y módulos funcionales descritos se segregan por función de claridad. Sin embargo, las diversas funciones se pueden combinar o segregar como módulos o dispositivos de hardware y Software de cualquier manera. Los diversos módulos o dispositivos de funciones tiene utilidad separadamente o en combinación. Los diversos registros, mensajes, elementos y porciones de los mismos se pueden almacenar en el mismo dispositivo o en dispositivos diferentes. Los diversos enlaces referencias especificaciones y similares se pueden usar para asociar los elementos. Se puede controlar el acceso a cualquier tipo de recurso. Se puede usar cualquier mecanismo para rastrear valores de las variables de estado. La invención se ha descrito a través de una modalidad y 32
ejemplos preferidos. -Sin embargo, se pueden hacer diversas modificaciones sin alejarse del alcance de la invención como se define por las reivindicaciones y equivalente legales. Se hace constar que con relación a esta fecha, el mejor método conocido por la solicitante para llevar a la práctica la citada invención, es el que resulta claro de la presente descripción de la invención.