MX2012009022A - Estructura de concesion de licencias de funciones genericas. - Google Patents

Abstract

Un sistema permite a los clientes disponer de dispositivos con licencias de funciones que permiten funciones específicas en los dispositivos. El sistema incluye un módulo de definición de funciones configurado para almacenar información de funciones del producto asociada con diferentes productos disponibles de una pluralidad de diferentes fabricantes. El sistema también incluye un módulo de administración de licencias de funciones configurado para generar, actualizar y revocar licencias de funciones. Todas las licencias de funciones que se generan tienen un formato común. El sistema además incluye un módulo de administración de créditos de funciones configurado para monitorear y considerar los créditos de funciones disponibles para las unidades de organización del cliente. También se proporciona en el sistema un módulo de administración de usuarios, el cual está configurado para autenticar usuarios del sistema. Una interfaz de usuario es accesible a través de una red de comunicaciones a través de la cual los usuarios autenticados pueden solicitar y recibir licencias de funciones.

Description

ESTRUCTURA DE CONCESIÓN DE LICENCIAS DE FUNCIONES GENÉRICAS CAMPO DE LA INVENCIÓN La presente invención se refiere a un sistema y método para la concesión de licencias de funciones genéricas en dispositivos .

ANTECEDENTES DE LA INVENCIÓN Mientras las tecnologías avanzan rápidamente, los fabricantes agregan un número cada vez más grande de funciones a sus productos. Ya que el cliente necesita variar a través de un amplio rango y en constante evolución, es necesario que los fabricantes implementen sistemas que puedan manejar la personalización de funciones para la configuración inicial y los cambios subsecuentes en el conjunto de funciones del producto. Por ejemplo, un fabricante de teléfonos móviles tal como Motorola, por ejemplo, puede ofrecer teléfonos móviles que sean capaces de soportar un número de funciones además de voz tales como datos, texto, servicios GPS, conectividad Wi-Fi, navegación web, de texto a voz y así sucesivamente. Los clientes directos del fabricante, quienes en el caso de teléfonos móviles son a menudo proveedores de servicios tales como Verizon y ATT, por ejemplo, podrían desear obtener teléfonos móviles con diferentes combinaciones de estas funciones con el fin de satisfacer con las necesidades diversas de los usuarios finales.

Para tratar este problema, los fabricantes han pasado a la concesión de licencias, que proporciona un mecanismo de control de funciones que permite a los clientes obtener una licencia para habilitar solamente las funciones del producto que satisfagan sus necesidades especificas. La concesión de licencias de funciones aporta muchos beneficios tanto a los fabricantes como los clientes. Por ejemplo, la concesión de licencias permite a los fabricantes tener un solo tipo de un producto que incorpora todas las funciones disponibles y se apoya en la concesión de licencias para habilitar diferentes combinaciones de funciones. Además, los clientes pueden obtener las funciones exactas para un producto que satisface sus necesidades especificas sin tener que pagar por funciones no deseadas. La concesión de licencias de funciones también permite a los fabricantes y a los clientes administrar los ascensos o descensos de categoría del producto a través de cambios de licencia, eliminando la necesidad de desplegar diferentes versiones del producto y reduciendo el tiempo de inactividad operacional.

Para conseguir estos beneficios, sin embargo, diferentes fabricantes, e incluso diferentes organizaciones dentro del mismo fabricante, han tendido a construir sus propios sistemas de concesión de licencias de funciones para dar soporte a sus propias lineas de productos. Estos sistemas a menudo están diseñados con solamente una o pocas lineas de productos similares en mente, y en consecuencia no se pueden extender fácilmente para dar soporte a otras lineas de productos. Una vez que se desarrollan tales sistemas diseñados a la medida, necesitan ser mantenidos y soportados de manera individual. Dichos esfuerzos repetidos resultan en aumento de costos en el desarrollo, despliegue y soporte de productos.

En el lado del cliente, los usuarios finales pueden tener que utilizar múltiples sistemas de concesión de licencias de funciones si tienen productos de múltiples fabricantes. Diferentes interfaces de usuario y procesos en diferentes sistemas de concesión de licencias de funciones para tareas similares pueden provocar confusión en los usuarios, lo que lleva a la necesidad de aumento en el entrenamiento del usuario y esfuerzos de soporte.

BREVE DESCRIPCIÓN DE LA INVENCIÓN De acuerdo con un aspecto de la invención, se proporciona un sistema para permitir a los clientes provisionen dispositivos con licencias de funciones que permiten funciones especificas en los dispositivos. El sistema incluye un módulo de definición de funciones configurado para almacenar información de funciones del producto asociada con diferentes productos disponibles de una pluralidad de diferentes fabricantes. Al menos dos de los diferentes productos pertenecen a diferentes lineas de productos y soportan diferentes conjuntos de funciones. El sistema también incluye un módulo de administración de licencias de funciones configurado para generar, actualizar y revocar licencias de funciones asociadas con los diferentes productos. Todas las licencias de funciones que se generan tienen un formato común. El sistema además incluye un módulo de administración de créditos de funciones configurado para monitorear y considerar los créditos de funciones disponibles para unidades de organización del cliente.

De acuerdo con otro aspecto de la invención, se proporciona un método para provisionar dispositivos con licencias de funciones que habiliten funciones especificas en los dispositivos. El método incluye autenticar un primer cliente como un usuario autenticado y recibir de un primer cliente a través de una red de comunicaciones una primera solicitud para una primera licencia de función que incluye al menos una función especifica. La primera solicitud incluye un identificador de un primer dispositivo que se va a provisionar con la licencia de función. El primer dispositivo está asociado con un primer producto en una primera línea de productos. También se autentica segundo cliente como un usuario autenticado. La primera licencia de función se genera de acuerdo con un formato predefinido. Se recibe una segunda solicitud de un segundo cliente a través de una red de comunicaciones. La segunda solicitud es para una segunda licencia de función que incluye al menos una función específica. La segunda solicitud incluye un identificador de un segundo dispositivo que se va a provisionar con la licencia de función. El segundo dispositivo está asociado con un producto en una segunda línea de productos diferente de la primera línea de productos. La segunda licencia de función se genera de acuerdo con el formato predefinido de tal manera que la primera y la segunda licencias de función tengan un formato común.

BREVE DESCRIPCIÓN DE LOS DIBUJOS La Figura 1 muestra la arquitectura lógica de una implementación de un sistema de concesión de licencias de funciones .

La Figura 2 ilustra la relación lógica entre productos, líneas de productos, funciones y reglas de funciones.

La Figura 3 muestra un ejemplo de una interfaz de usuario proporcionada por el módulo de administración de licencias de funciones.

La Figura 4 muestra una interfaz visual ilustrativa a través de la cual el usuario puede descargar en un modo de lotes las licencias solicitadas a través de la interfaz de usuario que se muestra en la Figura 3.

La Figura 5 ilustra la transición en el estatus de una licencia de una categoría (p.ej., "Activa", "Remplazada", "Revocada con Confirmación", y "Revocada sin Confirmación") a otra .

La Figura 6 muestra una tabla de permisos de un rol-entidad que se utiliza para asignar roles a los usuarios.

La Figura 7 muestra un procesador de solicitud de generación de licencia y un generador de licencia genérica, que están asociados con el módulo de administración de licencias de funciones de la Figura 1.

La Figura 8 muestra el flujo de información de órdenes de venta dentro del sistema de concesión de licencias de funciones .

La Figura 9 muestra una interfaz de usuario que presenta una orden de venta en proceso de revisión.

La Figura 10 muestra la interfaz de usuarios de la Figura 1 cuando se está haciendo un cambio en una orden de venta .

La Figura 11 muestra la manera en la que los registros de crédito de funciones están generalmente asociados con unidades de organización del cliente, las cuales están acomodadas en una estructura jerárquica configurable.

La Figura 12 es un diagrama de flujo que muestra un ejemplo de cómo un cliente puede provisionar uno o más dispositivos con licencias de funciones utilizando el sistema de concesión de licencias de funciones descrito anteriormente .

La Figura 13 muestra un ejemplo de un dispositivo del producto en el cual reside un módulo de licencia del dispositivo, el cual sirve como una interfaz a través de la cual los dispositivos de producto pueden llevar a cabo tareas relacionadas con las licencias de funciones.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN Definiciones Como se utiliza en este documento, el término Producto Genérico se refiere a un producto que utiliza el formato de licencia de funciones genéricas.

Como se utiliza en este documento, el término Producto No Genérico se refiere a un producto que no utiliza el formato de licencia de función genérica.

Como se utiliza en este documento, el término Tipo Calificador de Función se refiere a uno de tipo Booleano y tipo Entero.

El término Valor Calificador de Función se refiere a un valor Booleano que indica si una función está habilitada, o un valor de entero positivo que especifica la capacidad de una función (p.ej., el número de canales de alta definición).

El término Limitación de Valor de Función se refiere a una lista o un rango de valores calificadores de función válida .

Como se utiliza en este documento, el término Tipo de Función se refiere a un atributo temporal de una función y es uno de perpetuo, suscripción y de prueba.

El término Dependencia de Función se refiere a las dependencias entre múltiples funciones, ya sea debido a reglas de negocios o limitaciones de hardware. Por ejemplo, en un producto con funciones ?, B y C, las funciones B y C solamente se pueden habilitar si la función A está habilitada; y la función C no puede tener una cantidad de más de 8 si la función B tiene una cantidad de más de 4.

El término Crédito de Función se refiere a una cantidad disponible de una función.

Como se utiliza en este documento, el término Registro de Crédito de Función se refiere a un registro que contiene el crédito de función original establecido por una compra de función y el crédito de función restante después de se utiliza una cierta cantidad de la función. Un registro de crédito de función también contiene información referente a la unidad de organización a la que pertenece.

Como se utiliza este documento, el término Dispositivo se refiere a una unidad física de un producto. Para un producto de software, un dispositivo es una computadora que ejecuta el software.

El término ID de Dispositivo se refiere a un identificador único de un dispositivo. Si el dispositivo no tiene un ID, o su ID no se considera lo suficientemente seguro para ser utilizado para la concesión de licencias de funciones, se puede proporcionar al ID de dispositivo un módulo de expansión, tal como un token USB seguro.

El término ID Seguro del Dispositivo se refiere a un ID de dispositivo que no es fácilmente modificable o clasificable . El umbral de "fácilmente modificable o clasificable" se establece por los fabricantes de acuerdo con el valor de las funciones en un producto.

Como se utiliza en este documento, el término Almacenamiento Seguro se refiere a una memoria persistente no volátil en un dispositivo que no es fácilmente modificable. El umbral de "fácilmente modificable" se establece por los fabricantes de acuerdo con el valor de las funciones en un producto .

Como se utiliza en este documento, el término Clave Privada se refiere a la clave privada en un par asimétrico de clave criptográfica que por lo general se utiliza para generar una firma digital para una pieza de datos.

Revisión General del Sistema Para reducir el costo de desarrollo, mantenimiento y soporte de sistemas de concesión de licencias de funciones, asi como el costo de implementar mecanismos de ejecución de licencias de funciones en los productos, se puede proporcionar un sistema de concesión de licencias de funciones genéricas que soporte diferentes lineas de productos, que puede incluir lineas de productos para múltiples fabricantes y no solamente de un solo fabricante. Dicho sistema de concesión de licencias de funciones genéricas también se puede operar y soportar por un tercero. Los usuarios de dicho sistema pueden incluir usuarios asociados con los fabricantes, operadores del sistema que soporten y mantengan el sistema, y clientes que estarán utilizando las diferentes funciones de un producto para las cuales se están obteniendo las licencias. Los clientes pueden incluir, a manera de ejemplo, proveedores de servicios y/o el usuario final del cliente.

Ahora en cuanto las figuras, la Figura 1 muestra la arquitectura lógica de una implementación de un sistema de concesión de licencias funciones. En este ejemplo, tres categorías de usuarios son los usuarios 101A-101C (colectivamente, 101) . Los usuarios 101A son usuarios con licencia que son clientes representativos del sistema de concesión de licencias de funciones tales como proveedoras de servicios que obtienen productos de sus fabricantes respectivos en nombre de los usuarios finales. Alternativamente, los clientes pueden ser los mismos usuarios finales. Los usuarios 101B son usuarios del fabricante que son representativos de los fabricantes de los productos para los que se están proporcionando las licencias de funciones. Los usuarios 101C son usuarios de soporte del sistema que son usuarios internos administrativos del sistema que pertenecen a la organización anfitrión que opera y mantiene el sistema de concesión de licencias. Ciertas funciones administrativas avanzadas pueden estar limitadas al acceso LAN solamente y pueden no estar expuestas a una red pública.

Los usuarios 101 se comunican con el sistema a través de Internet 110 u otra red de área amplia basada en paquetes. En este ejemplo, los usuarios acceden e interactúan con el sistema a través de uno o más servidores web 120, que proporcionan una sola interfaz de visualización del usuario (front-end) a la cual accede una aplicación basada en el cliente tal como un navegador web convencional.

El sistema de concesión de licencias de funciones típicamente incluye una o más computadoras de servidor físico, uno o más dispositivos de almacenamiento físico y bases de datos así como diferentes motores de procesamiento. En particular, en el ejemplo que se muestra en la Figura 1, el sistema de concesión de licencias de funciones incluye uno o más componentes de servicios 130 que residen típicamente en servidores de aplicación que ejecutan una o más aplicaciones que proporcionan diferentes servicios de concesión de licencias de funciones a los clientes 101. En la Figura 1, se muestran cinco componentes o módulos lógicos de servicio: un componente de definición de función 131, un componente de administración de licencia de función 132, un componente de administración de crédito de función 133, un componente de administración de usuario 134 y un módulo de soporte de productos no genéricos 135.

El sistema de concesión de licencias de funciones también incluye módulos de seguridad de hardware (HSMs, Hardware Security Modules) 145 en los cuales las claves criptográficas que se utilizan para proteger las licencias se pueden almacenar para su uso por el sistema. El sistema de concesión de licencias de funciones también contiene una base de datos 150 de registros. Estos registros pueden pertenecer a licencias emitidas, solicitudes originales para nuevas licencias, datos de auditoria, información de política de control, información de organización, configuraciones del proyecto, relaciones de cuenta, configuraciones del producto, información del usuario, y otros tipos de registro como sea necesario. Los componentes del servicio tienen acceso a los directorios de usuario 155, que pueden ser los directorios de usuarios internos de la empresa que pertenecen a los diferentes usuarios. Los componentes del servicio también tienen acceso a sistemas de administración de orden 165, donde se mantienen las órdenes de venta para funciones de productos .

En un alto nivel, los módulos que hacen el componente de servicios 130 proporcionan las siguientes funciones y servicios. El módulo de definición de funciones 131 almacena la información de función del producto asociada con las diferentes líneas de producto de los fabricantes que son soportadas por el sistema de concesión de licencias de funciones. Este módulo está estructurado de tal forma que es lo suficientemente genérico para soportar comunes entre diferentes necesidades de concesión de licencias de funciones. Al mismo tiempo, es lo suficientemente extensible para ser capaz de acomodar cualquier peculiaridad en la especificación de funciones de ciertas lineas de productos.

El módulo de administración de licencias de funciones 132 soporta tareas de rutina de administración de licencias de funciones tales como generación de licencia, actualizaciones, ejecución y revocación. Este módulo debe ser capaz de llevar a cabo tales tareas en una manera genérica de tal forma que se pueden compartir entre diferentes lineas de productos. Además, debido a que la escala de despliegue y el programa de actualización pueden variar ampliamente a través de diferentes lineas de productos, en algunas implementaciones las tareas de administración deben soportar un modo de lotes de operación.

El módulo de administración de créditos de funciones 133 obtiene información de crédito de función de los sistemas de orden de venta del cliente, que administran órdenes de venta de funciones para los clientes respectivos. Este módulo rastrea cualquier cambio en los créditos de función de tal forma que se consideran de manera precisa durante la creación y ajuste del crédito, asi como la generación de licencia, actualización y revocación.

El módulo de administración de usuarios 134 se integra con directorios de usuarios existentes de los diferentes usuarios de tal manera que se puede acceder al sistema utilizando una interfaz simple de registro y evitando la duplicación de información del usuario. Este módulo también administra los privilegios del usuario de tal forma que se autorizan apropiadamente para llevar a cabo ciertas tareas mientras que se prohiben de llevar a cabo otra tarea.

El módulo de soporte de productos no genéricos 135 permite que los productos en las anteriores que puedan ser muy difíciles de migrar a la estructura genérica para que sin embargo se integren en el sistema de concesión de licencias de funciones. Igualmente, ciertos productos nuevos, que por diferentes razones pueden no ser capaces de utilizar el formato de licencia genérica, también se pueden soportar por el sistema de concesión de licencias de funciones.

El sistema de concesión de licencias es flexible en su soporte de productos con diferentes niveles de capacidades de computación, capacidad de modificación del ID del dispositivo y seguridad de almacenamiento, asi como para diferentes necesidades de portabilidad de licencia.

Otro módulo asociado con el sistema es un módulo de licencia del dispositivo, el cual se ubica en los dispositivos del producto. El módulo de licencia del dispositivo es responsable de todas las operaciones relacionadas con la licencia de función, tales como validación de licencia, reporte de valor de atributo de la función, generación de confirmación de revocación de licencia, etc. Se integra en el software del producto, el cual se comunica con el módulo a través de una interfaz de programación .

Módulo de definición de funciones El módulo de definición de funciones 131 almacena información de la función del producto que se utiliza para el propósito de concesión de licencias de funciones. Este módulo típicamente será utilizado por miembros del equipo del producto en nombre del fabricante (p.ej., por empleados del fabricante) . La información de funciones que se proporciona para cada línea de productos asociada con un fabricante está compuesta de los siguientes elementos: línea del producto, los productos dentro de esa línea de productos, las funciones asociadas con esa línea de productos, un conjunto de reglas de funciones y un conjunto de reglas de funciones por defecto .

La línea de productos se especifica por un nombre de línea de productos y una descripción. Cada producto en una línea de productos incluye un nombre y descripción de producto, el nombre y tipo de una clave de firma de licencia (que se almacena en un HSM) , y un señalizador precargado de ID del dispositivo (que indica si los IDs del dispositivo necesitan ser precargados en el sistema de concesión de licencias de funciones antes de que se pueda generar cualquier licencia) . Cada función incluye un ID de función como se define por un producto, un número de parte de función como se define en un sistema de órdenes de venta, un nombre y descripción de función, un tipo de calificador de función, un tipo de función, y una limitación de valor de función. Un conjunto de reglas de funciones especifica las dependencias de función dentro de un producto. Un conjunto de funciones por defecto especifica las funciones que hacen el conjunto de funciones esenciales de un producto, y sus valores calificadores de función correspondientes.

La relación entre los elementos antes mencionados de la información de la función del producto para las lineas de producto 1 y 2 se muestra en la Figura 2. En este ejemplo, los productos A y B están asociados con la linea de productos 1 y el producto C está asociado con la linea de productos 2. El conjunto de funciones para el producto A incluye las funciones 1, 2 y 3, el conjunto de funciones para el producto B incluye las funciones 3 y 4, y el conjunto de funciones para el producto C incluye la función 3. Como se muestra, un conjunto de reglas de funciones y un conjunto de funciones por defecto están asociados con cada producto.

En algunas implementaciones , puede haber reglas de asociación entre los diferentes elementos. Por ejemplo, un producto generalmente pertenecerá a una línea de productos, mientras que una función puede estar asociada con uno o más productos. Igualmente, un conjunto de reglas de funciones especifica cualquier interdependencia que pueda existir entre las funciones. Por ejemplo, una regla en el conjunto de reglas puede especificar que un producto puede incluir la función 1 solamente si el producto y la función 2. En consecuencia, todas las funciones especificadas en un conjunto de reglas asociadas con un producto deben estar disponibles para ese producto. Cada producto tendrá típicamente un conjunto de funciones por defecto y las funciones incluidas en el conjunto de funciones por defecto deben estar disponibles para ese producto.

La clave de firma de licencia antes mencionada asociada con cada producto se utiliza para firmar licencias de funciones. Los productos con capacidades criptográficas asimétricas tienen una clave de firma de licencia asimétrica y los productos sin capacidades criptográficas asimétricas tienen una clave de firma de licencia simétrica.

Módulo de administración de licencias de funciones Con el fin de soportar tareas de administración de licencias de funciones tales como generación de licencias, actualizaciones, ejecución y revocación, el módulo de administración de licencias de funciones 132 utiliza el formato para una licencia de función genérica que contiene la especificación del conjunto de funciones que será habilitado en un dispositivo en particular. Una licencia de función genérica contiene la siguiente información: versión del formato de licencia; longitud total en bytes; número de secuencia, único entre todas las licencias generadas del sistema; ID del producto utilizado en el sistema; ID del dispositivo; ID del dispositivo secundario, marca del tiempo, tiempo de generación; conteo de función; lista de descriptores de función; firma, por la clave de firma de licencia de un producto; y algoritmo de firma. El ID del dispositivo en una licencia especifica para que dispositivo que es la licencia. El ID del dispositivo secundario es opcional y se utiliza cuando se necesita enlazar una licencia a más de un ID del dispositivo. La unión de una licencia al ID del dispositivo, y opcionalmente al ID del dispositivo secundario, se protege por la firma en la licencia, de tal manera que una licencia para un dispositivo no se puede utilizar por otro dispositivo con un ID del dispositivo diferente o un ID del dispositivo secundario diferente, si lo hay .

El formato de la licencia de función genérica será aplicable entre los productos de diferentes fabricantes, excepto para productos no genéricos que ya tengan su propio formato de licencia antes de ser agregados al sistema y que no puedan adoptar fácilmente el formato de licencia genérica.

Cada descriptor de función contiene la siguiente información referente a la función con la cual está asociado: ID de función, tal como se define para un producto; tipo y valor de calificador de función; tipo de función; fecha de expiración, que se requiere si el tipo de función es suscripción o de prueba. La información especificada anteriormente está dirigida a un generador de licencia genérica para generar un archivo de licencia de función.

Otro aspecto del módulo de administración de licencias de funciones 132 se refiere a la administración de los IDs de dispositivo. Algunos procesos de negocios de los productos pueden permitir a los clientes obtener licencias para un conjunto específico de dispositivos. Dichos productos requerirían IDs de dispositivo para los cuales se podrían generar las licencias para ser importados al sistema, tan pronto como se fabrica un lote de dispositivos y se determinan sus IDs. Para satisfacer tal requerimiento, el sistema tiene una interfaz de usuario que permite a un usuario subir un lote de IDs de dispositivo en un solo archivo para un producto específico.

El módulo de administración de licencias de funciones 132 también presenta una interfaz usuario a través de la cual un usuario puede solicitar una licencia de función para un dispositivo del producto en particular. Un ejemplo de dicha interfaz 200 se muestra en la Figura 3. Después de que el usuario inicia sesión en el sistema, el usuario identifica el producto al cual pertenece el dispositivo. En el ejemplo de la Figura 3, está disponible un menú desplegable 205 del cual el usuario puede seleccionar el producto apropiado, que en este caso es un cifrado de Aegis Encryptor v2.3. Después de identificar el producto, se especifica el ID del dispositivo, típicamente seleccionando un ID del dispositivo precargado o introduciendo un ID de dispositivo. En el ejemplo de la Figura 3, se proporciona el campo 210 en el que el usuario puede introducir uno o más IDs de dispositivo. En este ejemplo, se introducen dos IDs de dispositivo, 1GGA y 1GGB. Cuando se especifica más de un ID de dispositivo, las licencias generadas para los dispositivos serán idénticas, excepto para el ID de dispositivo y firma.

Después de que el usuario ha seleccionado un producto, la interfaz de usuario 200 presenta un campo 215 que enlista las funciones que están definidas para el producto especificado y para el cual el cliente tiene crédito disponible actualmente. Este campo también permite al usuario especificar qué funciones se van a incluir en la nueva licencia y cualquier valor calificador que pueda tener. Finalmente, después de que se hayan hecho las selecciones apropiadas, el sistema genera la licencia, la cual se puede entonces descargar por el usuario. En algunos casos, la interfaz de usuarios soporta un modo de lotes de generación de licencia para cuando el usuario necesita generar licencias de funciones para un gran número de dispositivos. En este caso, el usuario generalmente especificará los dispositivos ya sea seleccionando muchos IDs de dispositivo precargados, especificando un rango continuo de IDs de dispositivo, o subiendo una lista de IDs de dispositivo. Típicamente, las nuevas licencias que se generan en un modo de lotes estarán disponibles para descargar en un solo archivo. La Figura 4 muestra una interfaz usuario ilustrativa a través de la cual el usuario puede descargar en un modo de lotes las licencias solicitadas a través de la interfaz usuario que se muestra en la Figura 3.

Otra interfaz de usuario que se hace disponible mediante el módulo de administración de licencias de funciones 132 permite a los usuarios generar una licencia de remplazo para un dispositivo para los propósitos de renovar, agregar y/o remover diferentes funciones, y/o para cambiar el valor calificador y fecha de expiración de funciones que actualmente están presentes en el dispositivo. Esta interfaz usuario puede ser similar a la que se muestra en la Figura 3, excepto que ésta presentará la información de función existente del dispositivo en su licencia de función más actual. También permitirá que se hagan modificaciones al conjunto de funciones existentes de tal manera que se pueda generar y descargar una nueva licencia. Una vez más, esta interfaz de usuario puede operar en un modo de un solo dispositivo o un modo de lote, que se puede utilizar para múltiples dispositivos que tengan el mismo conjunto actual de funciones .

El módulo de administración de licencias de funciones 132 también permite a los usuarios revocar una licencia, lo que ocurre cuando la licencia de función de un dispositivo necesita ser remplazada o removida. Con la revocación, el dispositivo genera un archivo de confirmación de revocación. Cuando un archivo de confirmación de revocación para un dispositivo se sube al sistema, se pueden reclamar los créditos de función utilizados por las funciones en la licencia revocada, si es permitido por el proceso de negocios del producto relacionado. Un archivo de confirmación de revocación puede contener la siguiente información: la versión de formato del archivo de confirmación de revocación; el ID del dispositivo y el ID del producto del dispositivo cuya licencia está siendo revocada; el número de secuencia de la licencia que está siendo revocada; una comprobación de la licencia que está siendo revocada; una marca del tiempo, que denota el tiempo de revocación; una firma y algoritmo de firma .

Se proporciona una interfaz de usuario a la cual se puede subir el archivo de confirmación de revocación desde un dispositivo al sistema por un usuario. Alternativamente, el archivo de confirmación de revocación de un dispositivo se puede subir al sistema por el mismo dispositivo a través de una interfaz automatizada del sistema, directamente o indirectamente. La información en el archivo de confirmación de revocación se utiliza para establecer correctamente el estatus de licencia actual y ajusfar créditos de funciones como sea necesario. La interfaz de usuario puede soportar un modo de lotes para subir múltiples archivos de confirmación de revocación, los cuales pueden estar empaquetados en un solo archivo.

El estatus de una licencia de función en cualquier momento cae en una de cuatro categorías: "Activa", "Remplazada", "Revocada con Confirmación", y "Revocada sin Confirmación". La transición del estatus de una licencia de una categoría a otra se ilustra en la Figura 5.

Cuando una licencia de función está recién generada, su estatus es "Activa". Cuando una licencia de función existente es remplazada por una nueva licencia con un diferente conjunto de funciones, el estatus de la licencia original se vuelve "Remplazada". Esta transición se indica en la Figura 5 por la flecha desde el estado "Activa" al estado "Remplazada". Cuando una licencia es remplazada por el usuario toma la nueva licencia y la instala en el dispositivo. Durante el proceso de instalación, se genera un archivo de revocación por el dispositivo y se sube al sistema por el usuario. En este momento, el estatus de la vieja licencia se vuelve "Revocada con Confirmación". Si el dispositivo en funcionamiento está siendo decomisado se está poniendo fuera de servicio su licencia necesita ser revocada sin generar un remplazo. Esto activa la transición de la licencia directamente desde el estado "Activa" al estado "Revocada con Confirmación". Si por el otro lado, un dispositivo es inoperable, su licencia puede ser "Revocada sin Confirmación", y por lo tanto hay una transición que se muestra en la Figura 5 de "Activa" directamente a "Revocada sin Confirmación". Finalmente, la transición que se muestra en la Figura 5 del estado de "Remplazada" al estado "Revocada sin Confirmación" se activa cuando se genera una nueva licencia pero la confirmación de revocación se pierde y por lo tanto no es recibida por el sistema.

Módulo de licencia del dispositivo Un módulo de licencia del dispositivo reside en los dispositivos del producto y sirve como una interfaz a través de la cual los dispositivos del producto pueden llevar a cabo tareas relacionadas con las licencias de funciones. La Figura 13 muestra un ejemplo de un dispositivo del producto 610 en el que se ubica un módulo de licencia del dispositivo 620. El módulo 620 tiene una interfaz 630 que está configurada como una interfaz de programación de aplicación (API, Application Programming Interface) que reside en los dispositivos del producto y se comunica con el software 640 que reside en el dispositivo 610. Las tareas que se desempeñan a través de dicha interfaz se relacionan generalmente con la ejecución de licencias y pueden incluir cargar la licencia inicial, junto con su validación, remplazo de licencia, con validación de la nueva licencia y generación de un archivo de confirmación de revocación para la licencia vieja. Tareas adicionales pueden incluir remoción de licencia, con generación de un archivo de confirmación de revocación para la licencia removida, una verificación de presencia de licencia, una consulta de los tipos de funciones y el valor calificador de función para una función especifica.

Cuando se valida una licencia de función, el dispositivo verifica un número de artículos incluyendo por ejemplo, la firma de la licencia de la función, el ID del producto en la licencia (que debe coincidir con el ID del producto propio del dispositivo) y el ID del dispositivo en la licencia (que debe coincidir con el ID del dispositivo propio del dispositivo) . El dispositivo puede también verificar que la marca de tiempo en la licencia no sea para un tiempo en el futuro (para prevenir hacer retroceder el reloj en el dispositivo) . Igualmente, cuando se remplaza una licencia de función existente, el proceso de validación puede también incluir una verificación del nuevo número de secuencia de la licencia para asegurar que es mayor que el número de secuencia de la licencia vieja.

Módulo de Administración de Usuarios Diferentes usuarios del sistema, tales como fabricantes y proveedores de servicios, pueden tener infraestructura interna que incluya directorios de usuarios empresariales para autenticar usuarios tales como empleados y similares. Estos directorios de usuarios empresariales a menudo se basan en bases de datos estándar de directorio de usuarios tales como el protocolo de acceso a bases de datos de peso ligero (LDAP, Lightweight Datábase Access Protocol) , por ejemplo.

Cuando es posible, el módulo de administración de usuarios 134 se integra con estas bases de datos de directorios de tal forma que los usuarios se pueden autenticar fácilmente.

Los usuarios que ya tienen una entrada en un directorio de usuarios se registrarán con el sistema de concesión de licencias de funciones. Durante el proceso de registro utilizando el módulo 134, el usuario selecciona el directorio de usuarios particular en el que el usuario ya tiene una entrada. El sistema verifica el registro con el directorio de usuarios y solicita a un administrador del sistema que apruebe el registro. El administrador del sistema puede ya sea rechazar o aprobar la solicitud de registro del usuario. Cuando aprueba un registro de usuario, un administrador del sistema también asigna un rol apropiado o roles al usuario. Una vez que se aprueba el registro del usuario, y se asignan privilegios de acceso apropiados al usuario, el usuario puede iniciar sesión en el sistema de concesión de licencias de funciones como un usuario autenticado. Los usuarios que todavía no tienen una entrada en un directorio de usuarios integrado necesitarán crear dicha entrada y después ir a través del proceso de registro y aprobación antes mencionado para obtener acceso al sistema de concesión de licencias de funciones .

El módulo de administración de usuarios 134 también administra y controla los roles asignados a los usuarios. Esto es, el módulo implementa un control de acceso basado en roles de tal manera que los usuarios pueden estar autorizados para llevar a cabo ciertas acciones de usuario y prohibidos de llevar a cabo otras acciones de usuario. Un rol de usuario se combina con un alcance para limitar los tipos de entidades en las que un usuario puede llevar a cabo las tareas de los roles asignados al usuario. Por ejemplo, un usuario asignado con el rol de "Administrador" y el alcance de "Compañía" puede llevar a cabo tareas administrativas en las compañías, mientras que un usuario asignado con el rol de "Administrador" y el alcance de "Sitio" puede llevar a cabo tareas administrativas en sitios. Para limitar adicionalmente en qué entidad exacta puede actuar un usuario, un usuario puede estar asignado a un conjunto específico de entidades. Por ejemplo, un usuario con el rol de "Administrador" y el alcance de "Sitio" puede estar asignado al Sitio A y Sitio B, habilitando al usuario para que lleve a cabo tareas administrativas en el Sitio A y Sitio B; mientras que otro usuario con el mismo rol y alcance puede estar asignado al Sitio C y Sitio D, habilitando al usuario para que lleve a cabo tareas administrativas en el Sitio C y Sitio D, pero no el Sitio A ni el Sitio B.

No todos los roles de usuario son significativos para cada tipo de entidad. Por ejemplo, un usuario puede estar asignado al rol de "Administrador de Productos" para un producto especifico, haciendo al usuario capaz de modificar la información de producto asociada con este producto. Este rol no es significativo para una entidad de usuario, ya que el mantenimiento de información del producto no tiene nada que ver con los clientes. Para definir cuáles roles son significativos para cuáles tipos de entidad, una tabla de permisos de rol-entidad, como se ilustra en la Figura 6, se puede mantener para prevenir que los roles que no son significativos para ciertos tipos de entidades se asignen a usos asociados con esas entidades. El módulo de administración de usuarios 134 utiliza la tabla de permisos para administrar los roles del usuario de tal manera que no se asignen los roles incorrectos.

Módulo de soporte de productos no genéricos Cada producto no genérico tiene su propio generador de licencias que implementa el mecanismo de generación de licencias privado del producto. El módulo de soporte de productos no genéricos 135 proporciona un adaptador para cada uno de estos generadores de licencias no genéricas. El adaptador convierte una solicitud de generación de licencia genérica en una solicitud que es compatible con el generador de licencias no genéricas. Un registro de productos no genéricos se mantiene en el sistema y contiene la información requerida por el adaptador del generador de licencias del producto, de tal manera que cuando se necesita generar la licencia de una función para un producto no genérico, se puede ubicar y utilizar el adaptador del generador de licencias del producto.

La Figura 7 muestra un procesador de solicitudes de generación de licencias 310 y un generador de licencias genéricas 320, que están asociados con el módulo de administración de licencias de funciones 132 de la Figura 1. Cuando se va a generar una licencia para un producto genérico o linea de productos, el procesador de solicitudes de generación de licencias 310 envía una lista de funciones solicitadas y otra información necesaria al generador de licencias genéricas 320 de tal forma que se puede generar la licencia. También se muestran en la Figura 7 los generadores de licencias no genéricas 330i, 3302, ... 330n, cada uno de los cuales se utiliza para generar una licencia para un producto no genérico o línea de productos. Se proporciona un adaptador 340i, 3402, ... 340n por cada uno de los generadores de licencias no genéricas 330i, 3302, ... 330n. Los adaptadores reciben solicitudes del procesador de solicitudes de generación de licencias 310 y, utilizando información del módulo de soporte de productos no genéricos 135, las traducen en un formato que permite a los generadores de licencias no genéricas 330?, 3302, ... 330n generar las licencias no genéricas.

Módulo de administración de créditos de funciones La autorización de un cliente a las funciones de productos se establece por medio de órdenes de compras para esas funciones. Esto es, un cliente compra funciones de productoá, a menudo presentando una orden de compra a un fabricante, y las funciones compradas se registran en una orden de venta por el fabricante. El sistema de concesión de licencias de funciones puede adquirir automáticamente la información de orden de venta pertinente en la manera descrita más adelante y asignar al cliente los créditos de funciones apropiados.

Las órdenes de venta de un fabricante por lo general se administran por medio de un sistema de órdenes de venta que se utiliza por el fabricante. El flujo de información de información de orden de venta en el sistema de concesión de licencias de funciones se ilustra en la Figura 8. La Figura 8 muestra los sistemas de orden de venta 410i, 4102, ... 410n, los cuales están asociados con un fabricante. El módulo de administración de créditos de funciones 133 incluye un recuperador de órdenes de venta 420, que periódicamente busca en los sistemas de órdenes de venta 410 nuevas órdenes de venta que contengan artículos de línea para números de parte de función que están almacenados por el módulo de definición de funciones 130. La Figura 8, el módulo de definición de funciones se representa por el almacén de definición de función 430, que almacena la información de función del producto que se utiliza para el propósito de concesión de licencias de funciones.

Cuando el recuperador de órdenes de venta 420 encuentra una nueva orden de venta para una función definida en el sistema, éste recupera una copia de la orden, que incluye el número de orden de venta, el número de artículo de línea de orden de venta, el número de parte de función y la cantidad ordenada. El recuperador de órdenes de venta 420 también copia la información del cliente relacionada con dichas órdenes, incluyendo la unidad de organización del cliente contra la cual se deben cargar los créditos de función resultantes, en un almacén de información del cliente 440. La identidad del sistema de la cual se recuperó la orden de venta se mantiene junto con la información de la orden de venta y la información del cliente recuperada de ese sistema, de tal forma que dicha información se puede remontar de nuevo a su fuente.

El recuperador de órdenes de venta 420 también transfiere la orden de venta a un almacén de órdenes de venta aceptadas 450, el cual crea un registro correspondiente de créditos de funciones que se transfiere al almacén de crédito de funciones 470. Opcionalmente, en lugar de enviar la orden de venta directamente al almacén de órdenes de venta aceptadas 450, el recuperador de órdenes de venta 420 puede transferir la orden de venta a un almacén de órdenes de venta pendientes 460, donde se mantiene hasta que se pueda revisar por un usuario que tenga conocimiento intimo del producto, productos relacionados, los clientes asociados con el producto y sus órdenes de venta. Éste paso de revisión manual puede prevenir que entren datos incorrectos al sistema de concesión de licencias de funciones. El usuario, quien realiza las órdenes de venta pendientes puede ya sea aceptar o rechazar los artículos de línea individuales en la orden de venta. Este mismo usuario puede escoger cambiar la cantidad de un artículo de línea y la unidad de organización del cliente a la que está asociado el articulo de línea. Se le puede requerir al usuario que introduzca una razón específica por cada cambio que se haga. Cuando se acerca un artículo de línea, entonces se transfiere al almacén de órdenes de venta aceptadas 450. La Figura 9 muestra una interfaz de usuario que presenta una orden de venta que está siendo revisada y la Figura 10 muestra la interfaz de usuario cuando se está haciendo un cambio.

El sistema permite que el paso de revisión manual de la orden de venta se active o desactive para un producto o linea de productos. En general, los productos o lineas de productos con un solo conjunto de funciones y a menudo órdenes de venta simples pueden no tener muchos errores en las órdenes de venta y por lo tanto pueden no requerir dicho paso de revisión de orden de venta.

Cuando la cantidad de un articulo de linea es negativa, como en un crédito o un articulo de linea de retorno, la cantidad del registro de crédito de función correspondiente en el almacén de órdenes de venta aceptadas 450 también será negativa. Tal cantidad negativa del crédito de función reduce el crédito total disponible para una función.

En algunos casos, puede haber una necesidad de ajustar un crédito de función sin una orden de venta. En algunos casos, el sistema puede permitir a usuarios autorizados hacer cambios a la cantidad disponible en un registro de crédito de función. Cuando se ajusta un crédito de función, se le puede requerir al usuario que introduzca una razón especifica por el ajuste, la cual se registra como parte de la acción de a usté .

Los registros de crédito de función generalmente están asociados con unidades de organización del cliente. Todas las unidades de organización de un cliente se mantienen en una estructura jerárquica configurable, que simula la estructura organizacional usual de una compañía, como se ilustra en la Figura 11.

La cantidad total de una función disponible para una cierta unidad de organización del cliente depende de la regla de consideración del crédito de función establecida para el cliente y el producto de la función. La regla puede permitir el cálculo de la cantidad total disponible de una función para incluir registros de crédito de función asociados con todas las unidades organizacionales del cliente o un subconjunto de las unidades de organización del cliente. Por ejemplo, la cantidad total disponible de una función puede estar asociada con cada unidad de organización individual, una unidad individual y todas las unidades de nivel alto en la jerarquía de la organización, todas las otras unidades de organización en el mismo nivel jerárquico de una unidad en particular, o todas las unidades organizacionales del mismo cliente .

Cuando se genera una nueva licencia de función, la cantidad de una función incluida se deduce de uno o más registros de créditos de función que están incluidos en el cálculo de disponibilidad de crédito. La relación entre una licencia de función y los registros de crédito de función de los cuales se dedujo la función se puede registrar para futura referencia.

Cuando se genera una licencia de función de remplazo, la cantidad aumentada de una función en la licencia vieja y la cantidad de una función incluida recientemente se deducen de la misma forma como se describió anteriormente. Sin embargo, una cantidad disminuida de una función en la licencia vieja puede no regresarse inmediatamente. Solamente cuando se recibe la confirmación de revocación de una licencia se regresa la cantidad de cada función en la licencia a los registros de crédito de función de los cuales se dedujo. Esto aplica tanto para las licencias remplazadas como las revocadas y ocurre cuando el estatus de licencia cambia de "Activa" o "Remplazada" a "Revocada con Confirmación".

Soporte para diferentes niveles de capacidad de productos y portabilidad de licencias El sistema tiene la flexibilidad de soportar productos con diferentes capacidades y diferentes requerimientos de portabilidad de licencias. En general, para que un producto soporte concesión de licencias de funciones, hay dos requerimientos de seguridad básicos: 1. Cada dispositivo necesita un ID seguro del dispositivo y único que no sea fácilmente modificable o falsificable por un usuario final. Este ID se incluye en una licencia de función para enlazarlo a un dispositivo. 2. Cada dispositivo necesita una unidad de almacenamiento seguro que se pueda utilizar por el componente de concesión de licencias de funciones en el dispositivo. "Seguro" significa que la unidad de almacenamiento no sea fácilmente modificable por un usuario final. El componente de concesión de licencias almacenará el estado de licencia en esta área de almacenamiento. El estado de licencia típicamente se refiere a la misma licencia. Sin embargo, como mínimo, el estado de licencia puede ser simplemente el número de secuencia de licencia global de la licencia que se está cargando actualmente. El almacenamiento del estado de licencia previene hacer retroceder la licencia actual a una licencia previa que puede autorizar al dispositivo a más funciones que la licencia actual.

Si un producto no satisface cualquiera o ambos de estos requerimientos, se pueden utilizar mecanismos alternativos. Dichos mecanismos incluyen dispositivos de seguridad externa que tienen un ID seguro y un almacenamiento seguro, y pueden tener una clave privada incrustada en ellos, por ejemplo, tarjetas inteligentes y tokens USB de seguridad (esto es, tokens de cifrado o crypto tokens) u otros tipos de tokens de seguridad externos. Cuando está conectado a un dispositivo que necesita una licencia de función, dicho dispositivo de seguridad externa proporciona el ID seguro necesario para enlazar la licencia de función asi como el almacenamiento seguro necesario para almacenar el estado de licencia.

Aun cuando un producto satisface ambos requerimientos de seguridad, el producto puede no tener la suficiente potencia de computación o datos necesarios (tal como una clave privada) para llevar a cabo todos los cálculos relacionados con la concesión de licencias de funciones, y por lo tanto puede todavía necesitar un dispositivo externo de seguridad para llevar a cabo esos cálculos. Además, un producto que satisface ambos requerimientos de seguridad puede requerir que sus licencias de funciones sean portables desde un dispositivo a otro. La unión de una licencia de función al ID de un dispositivo externo de seguridad puede proporcionar este tipo de portabilidad de licencia.

Para propósitos de ilustración, la siguiente discusión asumirá que se están utilizando tokens de cifrado.

Los productos se pueden clasificar en cuatro categorías de acuerdo a cuáles de los dos requerimientos satisfacen. Los cuatro casos se discutirán a continuación.

En el primer caso, el producto tiene tanto un ID seguro del dispositivo como un almacenamiento seguro. Si se utiliza un token de cifrado con un dispositivo para enlace de licencia, almacenamiento de licencia, asi como para señalización de confirmación de revocación de licencia (mediante la clave criptográfica incrustada en el token) , el sistema puede soportar escenarios de token tanto "portable" como "no portable". Un token portable tiene una licencia que se enlaza solamente al ID del token pero no al ID propio del dispositivo (como el ID del dispositivo secundario en una licencia), y permite a los usuarios finales utilizar el token en cualquier dispositivo del producto. Un token no portable tiene una licencia que está enlazada tanto al ID del token como el ID propio del dispositivo, y por lo tanto solamente se puede utilizar para el dispositivo. Si, por el otro lado, no se utiliza un token de cifrado, cada dispositivo del producto tiene una clave privada especifica del dispositivo, esta clave privada puede ser utilizada para firmar una confirmación de revocación de licencia. Esto proporciona mejor seguridad pero requiere personalización del dispositivo para cargar en el dispositivo la clave privada especifica del dispositivo y un certificado. Si no se utiliza un token de cifrado, y cada dispositivo del producto no tiene una clave privada especifica del dispositivo, entonces la confirmación de revocación de licencia se puede firmar con una clave simétrica derivada. Esto proporciona menor seguridad, pero no requiere personalización del dispositivo.

En el segundo caso, el producto tiene un ID seguro del dispositivo pero no un almacenamiento seguro. Si en este caso se utiliza un token de cifrado el archivo de licencia se puede almacenar en el token y la confirmación de revocación de licencia se firma con la clave privada en el token. Similar al primer caso, cualquiera de los escenarios "portable" o "no portable" se pueden soportar en el segundo caso. Si, por el otro lado, no se utiliza un token de cifrado, entonces como en el primer caso, se puede utilizar cualquiera de una clave privada especifica del dispositivo o una clave simétrica derivada para firmar una confirmación de revocación de licencia, pero con menor seguridad que en el primer caso donde no se utiliza un token de cifrado.

En el tercer caso, el producto tiene almacenamiento seguro pero no un ID seguro del dispositivo. Si este producto soporta personalización del dispositivo, se puede cargar un ID de dispositivo único en el almacenamiento seguro, convirtiendo este caso en el primer caso. Si la personalización del dispositivo no está disponible y se utiliza un token de cifrado, el archivo de licencia se puede almacenar en el token y el ID propio del token se puede utilizar como el ID seguro del dispositivo para enlace de licencia, en cuyo caso el token es inherentemente portable. Además, la confirmación de una revocación de licencia se puede firmar con la clave privada en el token. Por el otro lado, si no está disponible la personalización del dispositivo y no se utiliza un token de cifrado, entonces la confirmación de una revocación de licencias se puede firmar con una clave simétrica derivada.

En el cuarto caso, el producto no tiene ni un almacenamiento seguro ni un ID seguro del dispositivo. Si en este caso se utiliza un token de cifrado, el archivo de licencia se puede almacenar en el token y el ID propio del token se puede utilizar como el ID seguro del dispositivo para el enlace de licencia, en cuyo caso el token es inherentemente portable. Además, la confirmación de una revocación de licencia se puede firmar con la clave privada en el token. Si no se utiliza un token de cifrado y cada equipo del producto no tiene una clave privada especifica del dispositivo, entonces la confirmación de revocación de licencia se puede firmar con una clave simétrica derivada.

Ejemplo La Figura 12 es un diagrama de flujo que muestra un ejemplo de cómo un cliente puede provisionar uno o más dispositivos con licencias de funciones utilizando el sistema de licencia de funciones descrito anteriormente. El método comienza en el paso 505 y continúa al paso 510 donde el cliente se registra de manera remota en el sistema utilizando una interfaz de navegador web. El sistema verifica las credenciales del cliente a través de un directorio de usuarios asociado con la organización del cliente. Una vez que el cliente ha sido autenticado apropiadamente, el sistema muestra o de otra forma presenta al cliente en el paso 515 una lista de productos para los cuales este cliente tiene créditos de función disponibles. En respuesta, el cliente selecciona un producto al cual pertenece (n) el (los) dispositivo ( s) que están siendo provisionados en el paso 520. El sistema entonces muestra al usuario en el paso 525 una lista de funciones disponibles para el producto seleccionado. También puede presentarse el número de créditos de función disponibles para ese producto, y cualquier calificador de función u otros atributos que pueden estar asociados con las funciones. Después, en el paso 530, el cliente introduce uno o más IDs de dispositivo para identificar los dispositivos que serán provisionados y en el paso 535 selecciona las funciones deseadas de las funciones disponibles y especificas el valor de cualquiera de los atributos de las funciones seleccionadas. El sistema presenta al cliente un resumen de los artículos solicitados y el cliente confirma las selecciones en el paso 540. El sistema entonces genera las licencias en el paso 545 y las hace disponibles de tal manera que el cliente puede descargarlas en el paso 550, ya sea en un solo archivo o en archivos separados. Todas las licencias que se generan contienen el mismo conjunto de valores de funciones y atributos, que corresponden a los seleccionados por el cliente.

Como se utiliza en esta solicitud, se pretende que los términos "componente", "módulo", "sistema", "aparato", "interfaz", o similares se refiere generalmente a una entidad relacionada con las computadoras, ya sea hardware, una combinación de hardware y software, software, o software en ejecución. Por ejemplo, un componente puede ser, pero no está limitado a serlo, un proceso ejecutándose en un procesador, un procesador, un objeto, un ejecutable, un hilo de ejecución, un programa, y/o una computadora. A manera de ilustración, tanto una aplicación ejecutándose en un controlador como el controlador pueden ser un componente. Uno o más componentes pueden residir dentro de un proceso y/o hilo de ejecución y un componente puede estar ubicado en una computadora y/o distribuido entre dos o más computadoras.

Además, el tema que se reivindica se puede implementar como un método, aparato, o artículo de manufactura utilizando programación estándar y/o técnicas de ingeniería para producir software, firmware, hardware, o cualquier combinación de los mismos para controlar una computadora para implementar el tema que se divulga. El término "artículo de manufactura" como se utiliza en este documento se pretende que abarque un programa de computadora accesible desde cualquier dispositivo legible por computadora, portador, o medio. Por ejemplo, el medio de almacenamiento legible por computadora puede incluir, pero no está limitado a, dispositivos de almacenamiento magnético (p.ej., disco duro, disco floppy, cintas magnéticas...), discos ópticos (p.ej., disco compacto (CD, Compact Disk) , disco versátil digital (DVD, Digital Versatile disk)...), tarjetas inteligentes, y dispositivos de memoria flash (p.ej., tarjeta, barra, unidad de clave...) . Desde luego, aquellos experimentados en la materia reconocerán que se pueden hacer muchas modificaciones a esta configuración sin apartarse del alcance o espíritu del tema que se reivindica.

Claims (23)

NOVEDAD DE LA INVENCIÓN Habiendo descrito la presente invención como antecede, se considera como una novedad y, por lo tanto, se reclama como propiedad lo contenido en las siguientes: REIVINDICACIONES

1. Un sistema para habilitar a los clientes para provisionar dispositivos con licencias de funciones que habilitan funciones especificas en los dispositivos, que comprende : : un módulo de definición de funciones configurado para almacenar información de función del producto asociada con diferentes productos disponibles de una pluralidad de diferentes fabricantes, en donde al menos dos de los diferentes productos pertenecen a diferentes lineas de productos y soportan diferentes conjuntos de funciones; un módulo de administración de licencias de funciones configurado para generar, actualizar, y revocar licencias de funciones asociadas con los diferentes productos, en donde todas las licencias de funciones que se generan tienen un formato común; un módulo de administración de créditos de funciones configurado para monitorear y considerar los créditos de funciones disponibles para las unidades de organización del cliente, dichos créditos de funciones representan una cantidad de una función que está disponible para la unidad de organización del cliente respectiva; y un módulo de administración de usuarios configurado para autenticar usuarios del sistema; y una interfaz de usuario accesible a través de una red de comunicaciones por medio de la cual los usuarios autenticados pueden solicitar y recibir licencias de funciones.

2. El sistema de acuerdo con la reivindicación 1, además comprende un módulo de soporte de producto no genérico para suministrar información de funciones del producto a un generador de licencias que genera licencias de funciones que no se ajustan el formato común.

3. El sistema de acuerdo con la reivindicación 1, caracterizado porque el módulo de administración de licencias de funciones está además configurado para presentar a los usuarios autorizados a través de la interfaz de usuario una lista de IDs de dispositivos precargados de tal forma que las licencias de funciones se pueden solicitar para los dispositivos correspondientes a uno o más de los IDs de dispositivos precargados seleccionados por los usuarios autorizados .

4. El sistema de acuerdo con la reivindicación 3, caracterizado porque el módulo de administración de licencias de funciones está además configurado para generar las licencias de funciones solicitadas para los dispositivos correspondientes a dichos uno o más IDs de dispositivos precargados solamente si el módulo de administración de créditos de funciones indica que están disponibles los suficientes créditos de funciones.

5. El sistema de acuerdo con la reivindicación 1, caracterizado porque la información de funciones del producto asociada con los diferentes productos incluyen un calificador de función asociado con cada función, dicho calificador de función tiene un tipo de cualquiera de Booleano o entero, dicho calificador de función tiene cualquiera de un valor Booleano que especifica si una función está habilitada o un valor entero que especifica una capacidad de la función.

6. El sistema de acuerdo con la reivindicación 1, caracterizado porque la interfaz de usuario está configurada para recibir de los usuarios autorizados solicitudes de licencias de funciones para una pluralidad de dispositivos en un modo de lotes de- operación.

7. El sistema de acuerdo con la reivindicación 1, caracterizado porque la información de función del producto incluye un conjunto de reglas de función que especifica las dependencias de la función entre las funciones que están disponibles para un producto en particular.

8. El sistema de acuerdo con la reivindicación 1, caracterizado porque el módulo de administración de usuarios está además configurado para acceder a directorios de usuarios empresariales con el fin de facilitar la identificación de usuarios autorizados.

9. El sistema de acuerdo con la reivindicación 1, caracterizado porque el módulo de administración de usuarios está además configurado para implementar control de acceso basado en roles combinado con alcance de acceso y asignación de entidad especifica de tal manera que los usuarios autorizados están autorizados para llevar a cabo las acciones seleccionadas en entidades especificas y prohibidos de llevar a cabo otras acciones o actuar en entidades no asignadas.

10. El sistema de acuerdo con la reivindicación 1, caracterizado porque el módulo de administración de créditos de funciones incluye un recuperador de órdenes de venta para recuperar información de órdenes de venta de los fabricantes para registrar los créditos de funciones disponibles para los clientes para productos y funciones especificadas.

11. Un método para provisionar dispositivos con licencias de funciones que habilita funciones especificas en los dispositivos, que comprende: autenticar un primer cliente como un usuario autenticado; recibir de un primer cliente a través de una red de comunicaciones una primera solicitud para una primera licencia de función que incluye al menos una función especifica, dicha primera solicitud incluye un identificador de un primer dispositivo que se va a provisionar con la licencia de función, dicho primer dispositivo está asociado con un primer producto en una primera linea de productos; autenticar un segundo cliente como un usuario autenticado; y generar la primera licencia de función de acuerdo con un formato predefinido; recibir de un segundo cliente a través de una red de comunicaciones una segunda solicitud para una segunda licencia de función que incluye al menos una función especifica, dicha segunda solicitud incluye un identificador de un segundo dispositivo que se va a provisionar con la licencia de función, dicho segundo dispositivo está asociado con un producto en una segunda linea de productos diferente de la primera linea de productos; generar la segunda licencia de función de acuerdo con el formato predefinido de tal manera que la primera y la segunda licencias de función tengan un formato común.

12. El método de acuerdo con la reivindicación 11, caracterizado porque los dispositivos en la primera linea de productos están disponibles de un primer fabricante y los dispositivos en la segunda linea de productos están disponibles de un segundo fabricante diferente del primer fabricante .

13. El método de acuerdo con la reivindicación 11, además comprende recibir el primer cliente un identificador del primer producto y en respuesta presentar una interfaz usuario al primer usuario para el producto que incluye una lista de funciones disponibles para el producto, un valor calificador de función para cada función y un valor de crédito de función que especifica un número de unidades de cada función está disponible para el primer usuario.

14. El método de acuerdo con la reivindicación 11, además comprende revocar la primera licencia y remplazaría con una licencia actualizada y recibir una confirmación de revocación del primer dispositivo.

15. El método de acuerdo con la reivindicación 11, caracterizado porque autenticar el primer cliente incluye acceder a un directorio de usuarios empresarial de una organización con el cual se asocia el primer usuario.

16. El método de acuerdo con la reivindicación 12, además comprende buscar un sistema de órdenes de venta del primer y segundo fabricantes para identificar y recuperar una orden de venta con un número de parte de función asociado con una función disponible para cualquiera del primer o segundo producto y designar valores de crédito de función a un cliente quien colocó la orden de venta.

17. El método de acuerdo con la reivindicación 11, caracterizado porque los valores de crédito de función se designan de acuerdo con una regla de consideración de crédito de función predefinida para el cliente de tal manera que los valores de crédito de función están disponibles para subunidades organi zacionales seleccionadas del cliente.

18. El método de acuerdo con la reivindicación 11, además comprende: recibir de un tercer cliente una tercera solicitud de una tercera licencia de función; y en respuesta a la tercera solicitud, suministrar información de función del producto que será incluida en la tercer licencia a un generador de licencias no genéricas, en donde el generador de licencias no genéricas generar la tercer licencia de acuerdo con un formato que no se ajusta al formato predefinido.

19. El método de acuerdo con la reivindicación 11, además comprende descargar la primera licencia de función al primer dispositivo para instalación en el mismo mediante un módulo de licencias de dispositivos que valida y ejecuta la primera licencia de función.

20. El método de acuerdo con la reivindicación 11, además comprende descargar la primera licencia de función en un token de seguridad externo que tiene un ID seguro y que está configurado para almacenar la primera licencia de función y enlazar la primera licencia de función al mismo.

21. El método de acuerdo con la reivindicación 20, caracterizado porque el token de seguridad externo es un token portable en el cual la primera licencia de función se enlaza al ID seguro pero no a un ID del primer dispositivo.

22. El método de acuerdo con la reivindicación 20, caracterizado porque el token de seguridad externo es un token no portable en el cual la primera licencia de función se enlaza al ID seguro y a un ID del primer dispositivo.

23. El método de acuerdo con la reivindicación 20, caracterizado porque el token de seguridad externo incluye una clave litográfica para llevar a cabo la firma de la confirmación de revocación de licencia.