Procedimiento para proteger un software mediante "detección y coerción" contra su uso no autorizado.

Procedimiento para proteger, a partir de por lo menos una unidad virgen (60) que consta de por lo menos unos medios de memorización (15) y unos medios de procesado (16),

un software vulnerable (2v) contra su uso no autorizado, funcionando dicho software vulnerable (2v) en un sistema de procesado de datos (3), caracterizado por que consiste en:

® en una fase de protección (P):

• definir:

- por lo menos una característica de ejecución de software, susceptible de ser supervisada por lo menos en parte en una unidad (6),

- por lo menos un criterio que se debe respetar para por lo menos una característica de ejecución de software,

- unos medios de detección (17) que se deben implementar en una unidad (6) y que permiten detectar que por lo menos una característica de ejecución de software no respeta por lo menos un criterio asociado,

- y unos medios de coerción (18) que se deben implementar en una unidad (6) y que permiten informar al sistema de procesado de datos (3) y/o modificar la ejecución de un software cuando no se respeta por lo menos un criterio,

• construir unos medios operativos que permiten transformar la unidad virgen (60) en una unidad (6) que puede implementar los medios de detección (17) y los medios de coerción (18),

• crear un software protegido (2p):

- seleccionando por lo menos una característica de ejecución de software que se debe supervisar, entre las características de ejecución susceptibles de ser supervisadas,

- seleccionando por lo menos un criterio que se debe respetar para por lo menos una característica de ejecución de software seleccionada,

- seleccionando por lo menos un procesado algorítmico que, durante la ejecución del software vulnerable (2v), utiliza por lo menos un operando y permite obtener por lo menos un resultado, y para el cual se supervisará por lo menos una característica de ejecución de software seleccionada,

- seleccionando por lo menos una porción de la fuente del software vulnerable (2vs) que contiene por lo menos un procesado algorítmico seleccionado,

- produciendo la fuente del software protegido (2ps) a partir de la fuente del software vulnerable (2vs), modificando por lo menos una porción seleccionada de la fuente del software vulnerable (2vs) para obtener por lo menos una porción modificada de la fuente del software protegido (2ps), siendo tal esta modificación que:

• durante la ejecución del software protegido (2p) se ejecuta una primera parte de ejecución (2pes) en el sistema de procesado de datos (3) y se ejecuta una segunda parte de ejecución (2peu) en una unidad (6), obtenida a partir de la unidad virgen (60) después de la carga de informaciones,

• la segunda parte de ejecución (2peu) ejecuta por lo menos la funcionalidad de por lo menos un procesado algorítmico seleccionado,

• y durante la ejecución del software protegido (2p), por lo menos una característica de ejecución seleccionada se supervisa por medio de la segunda parte de ejecución (2peu), y no respetar un criterio conduce a una modificación de la ejecución del software protegido (2p),

- y produciendo:

• una primera parte objeto (2pos) del software protegido (2p), a partir de la fuente del software protegido (2ps), siendo tal esta primera parte objeto (2pos) que durante la ejecución del software protegido (2p), aparece una primera parte de ejecución (2pes) que se ejecuta en el sistema de

Procedimiento para proteger un software mediante "detección y coerción" contra su uso no autorizado.

La presente invención se refiere al campo técnico de los sistemas de procesado de datos en sentido general y se refiere, de manera más precisa, a los medios para proteger, contra su uso no autorizado, un software que funciona en dichos sistemas de procesado de datos.

El objeto de la invención se refiere, más particularmente, a los medios para proteger un software contra su uso no autorizado, a partir de una unidad de procesado y de memorización, materializándose comúnmente dicha unidad por medio de una ta~eta chip o una llave tangible en un puerto USB.

En el campo técnico mencionado anteriormente, el principal inconveniente se refiere a la utilización no autorizada de softwares por parte de usua rios que no han pagado derechos de licencia. Este uso ilicito de softwares genera un pe~uicio manifiesto para los editores de software, los distribuidores de software y/o toda persona que integra dicho software en productos. Para evitar dichas copias ilicitas, se han propuesto, en el estado de la técnica, diversas soluciones para proteger softwares.

De este modo, es conocida una solución de protección que consiste en poner en práctica un sistema material de protección, tal como un elemento fisico denominado llave de protección o MdongleM en terminologia anglosajona. Dicha llave de protección deberla garantizar la ejecución del software únicamente en presencia de la llave. Ahora bien, se debe hacer constar que dicha solución es ineficaz puesto que presenta el inconveniente de ser fácilmente eludible. Con la ayuda de herramientas especializadas, tales como desensambladores, una persona mal intencionada o pi rata puede suprimir las instrucciones de control de la llave de protección . Resulta entonces posible realizar copias ¡¡¡citas que se corresponden con versiones modificadas de los softwares que ya no tienen ninguna protección. Además, esta solución no se puede generalizar a todos los softwares, en la medida en la que resulta dificil conectar más de dos llaves de protección a un mismo sistema.

Es conocido también por medio del documento WO 99f66387 , un procedimiento de protección de un programa de ordenador, que consiste en dividir el programa en por lo menos dos partes, pública y secreta respectivamente, y en ejecutar en la parte secreta, después de la recepción de parámetros, por lo menos una parte del programa, ya continuación en retransm itir los resultados a la parte pública.

La patente US nO 5 754 646 describe un procedimiento de protección de un software, que consiste en dividirlo en dos partes de las cuales por lo menos una parte se ejecuta en una llave física. La parte que se ejecuta en la llave física se descarga a partir de una red. La conexión a la red se realiza durante el arranque del software protegido.

La solicitud de patente FR 2 634 917 describe un procedimiento de protección de un software, que consiste en grabar una parte esencial del softwa re en una memoria conectada a un microprocesador y en confina r el conjunto de memoria-microprocesador dentro de una caja de tipo inviolable que comprende medios de conexión entre dicho microprocesador y un microprocesador exterior de un sistema de utilización del software.

El objetivo de la invención pretende precisamente remed iar los inconvenientes mencionados anteriormente al proponer un procedimiento para proteger un software contra su uso no autorizado, a partir de una unidad de procesado y de memorización ad hoc, en la medida en la que la presencia de dicha unidad es necesaria para que el software sea completamente funcional.

Para lograr dicho objetivo, el objeto de la invención se refiere a un procedimiento para proteger, a partir de por lo menos una unidad virgen que consta por lo menos de medios de procesado y medios de memorización, un software vulnerable contra su utilización no autorizada, funcionando dicho software vulnerable en un sistema de procesado de datos. El procedimiento según la invención consiste en:

~ en una fase de protección:

definir:

por lo menos una caracteristica de ejecución de software, susceptible de ser supervisada por lo menos en parte en una unidad,

por lo menos un criterio a respetar para por lo menos una caracteristica de ejecución de software,

medios de detección a implementar en una unidad y que permiten detectar que por lo menos una caracteristica de ejecución de software no respeta por lo menos un criterio asociado,

y medios de coerción a implementar en una unidad y que permiten informar al sistema de procesado de datos yfo modificar la ejecución de un software cuando no se respeta por lo menos un criterio,

construir medios operativos que permiten transformar la unidad virgen en una unidad con capacidad de poner en práctica los medios de detección y los medios de coerción ,

crear un software protegido:

seleccionando por lo menos una característica de ejecución de software a supervisar, entre las características de ejecución susceptibles de ser supervisadas,

seleccionando por lo menos un criterio a respetar para por lo menos una característica de ejecución de software seleccionada,

seleccionando por lo menos un procesado algorítmico que, durante la ejecución del software vulnerable, utiliza por lo menos un operando y permite obtener por lo menos un resultado, y para el 15 cual se supervisará por lo menos una característica de ejecución de software seleccionada,

seleccionando por lo menos una porción de la fuente del software vulnerable que contiene por lo menos un procesado algorítmico seleccionado,

generando la fuente del software protegido a partir de la fuente del software vulnerable, modificando por lo menos una porción seleccionada de la fuente del software vulnerable para obtener por lo menos una porción modificada de la fuente del software protegido, siendo dicha modificación tal que:

durante la ejecución del software protegido se ejecuta una primera parte de ejecución en el

sistema de procesado de datos y se ejecuta una segunda parte de ejecución en una unidad, obtenida a partir de la unidad virgen después de la carga de informaciones,

la segunda parte de ejecución ejecuta por lo menos la funcionalidad de por lo menos un procesado algorítmico seleccionado,

y durante la ejecución del software protegido, se supervisa por medio de la segunda parte de ejecución por lo menos una característica de ejecución seleccionada yel hecho de no respetar un criterio conduce a una modificación de la ejecución del software protegido,

y generando:

una primera parte objeto del software protegido, a partir de la fuente del software protegido, siendo esta primera parte objeto tal que durante la ejecución del software protegido, aparece una primera parte de ejecución que se ejecuta en el sístema de procesado de datos y, de la cual, por lo menos una porción tiene en cuenta que se supervisa por lo menos una característica de ejecución de software seleccionada,

y una segunda parte objeto del software protegido, que contiene los medios operativos que ponen en práctica los medios de detección y los medios de coerción, siendo esta segunda parte objeto tal

que, después de la carga en la unidad virgen y durante la ejecución del software protegido, aparece la segunda parte de ejecución por medio de la cual se supervisa por lo menos una característica de ejecución de software y por medio de la cual el hecho de no respetar un criterio conduce a una modificación de la ejecución del software protegido,

y cargar la segunda parte objeto en la unidad virgen, con vistas a obtener la unidad,

~ yen una fase de utilización en el curso de la cual se ejecuta el software protegido:

en presencia de la unidad:

en la medída en la que se respeten todos los criterios que se corresponden con todas las características de ejecución supervisadas de todas las porciones modificadas del software protegido, permitir el funcionamiento nominal de estas porciones del software protegido y en consecuencia permitir el funcionamiento nominal del software protegido,

Y si por lo menos no se respeta uno de los criterios que se corresponde con una característica de ejecución supervisada de una porción del software protegido, informar al sistema de procesado de datos y/o modificar el funcionamiento de la porción del software protegido, de manera que se modifica el funcionamiento del software protegido;

y en ausencia de la unidad, a pesar de la petición de una porción de la primera parte de ejecución, de iniciar la ejecución en la unidad, de la funcionalidad... [Seguir leyendo]

1. Procedimiento para proteger, a partir de por lo menos una unidad virgen (60) que consta de por lo menos unos medios de memorización (15) y unos medios de procesado (16) , un software vulnerable (2v) contra su uso no autorizado, funcionando dicho software vulnerable (2v) en un sistema de procesado de datos (3) , caracterizado por que consiste en:

- en una fase de protección (P) :

definir:

por lo menos una característica de ejecución de software, susceptible de ser supervisada por lo menos en parte en una unidad (6) ,

por lo menos un criterio que se debe respetar para por lo menos una caracterrstica de ejecución de software,

unos medios de detección (17) que se deben implementar en una unidad (6) y que permiten detectar que por lo menos una característica de ejecución de software no respeta por lo menos un criterio asociado,

y unos medios de coerción (18) que se deben implementar en una unidad (6) y que penniten infonnar al sistema de procesado de datos (3) ylo modificar la ejecución de un software cuando no se respeta por lo menos un criterio,

construir unos medios operativos que penniten transfonnar la unidad virgen (60) en una unidad (6) que puede implementar los medios de detección (17) y los medios de coerción (18) ,

crear un software protegido (2p) :

seleccionando por lo menos una caracterlstica de ejecución de software que se debe supervisar, entre las características de ejecución susceptibles de ser supervisadas,

seleccionando por lo menos un criterio que se debe respetar para por lo menos una caracterrstica de ejecución de software seleccionada,

seleccionando por lo menos un procesado algorltmico que, durante la ejecución del software vulnerable (2v) , utiliza por lo menos un operando y permite obtener por lo menos un resultado, y para el cual se supervisará por lo menos una caracterrstica de ejecución de software seleccionada,

seleccionando por lo menos una porción de la fuente del software vulnerable (2vs) que contiene por lo menos un procesado algoritmico seleccionado,

produciendo la fuente del software protegido (2ps) a partir de la fuente del software vulnerable (2vs) , modificando por lo menos una porción seleccionada de la fuente del software vulnerable (2vs) para obtener por lo menos una porción modificada de la fuente del software protegido (2ps) , siendo tal esta modificación que:

durante la ejecución del software protegido (2p) se ejecuta una primera parte de ejecución (2pes) en el sistema de procesado de datos (3) y se ejecuta una segunda pa rte de ejecución (2peu) en una unidad (6) , obtenida a partir de la unidad virgen (60) después de la carga de infonnaciones,

la segunda parte de ejecución (2peu) ejecuta por lo menos la funcionalidad de por lo menos un procesado algorítmico seleccionado,

y durante la ejecución del software protegido (2p) , por lo menos una característica de ejecución seleccionada se supervisa por medio de la segunda parte de ejecución (2peu) , y no respetar un criterio conduce a una modificación de la ejecución del software protegido (2p) ,

y produciendo:

una primera parte objeto (2pos) del software protegido (2p) , a partir de la fuente del software protegido (2ps) , siendo tal esta primera parte objeto (2pos) que durante la ejecución del software protegido (2p) , aparece una primera parte de ejecución (2pes) que se ejecuta en el sistema de procesado de datos (3) y de la cual por lo menos una porción tiene en cuenta que se supervisa por lo menos una característica de ejecución de software seleccionada,

y una segunda parte objeto (2pou) del software protegido (2p) , que contiene los medios operativos que implementan los medios de detección (17) y los medios de coerción (18) , siendo tal esta segunda parte objeto (2pou) que, después de su carga en la unidad virgen (60) y durante la ejecución del software protegido (2p) , aparece la segunda parte de ejecución (2peu) por medio de la cual se supervisa por lo menos una caracteristica de ejecución de software, y por medio de la cual no respetar un criterio conduce a una modificación de la ejecución del software protegido (2p) ,

y cargar la segunda parte objeto (2pou) en la unidad virgen (60) , para obtener la unidad (6) ,

~ yen una fase de utilización (U) en el curso de la cual se ejecuta el software protegido (2p) :

en presencia de la unidad (6) :

en la medida en la que se respeten todos los criterios que corresponden a todas las caracteristicas de ejecución supervisadas de todas las porciones modificadas del software protegido (2p) , permitir el funcionamiento nominal de estas porciones del software protegido (2p) y en consecuencia permitir el

funcionamiento nominal del software protegido (2p) ,

y si no se respeta por lo menos uno de los criterios que corresponde a una caracteristica de ejecución supervisada de una porCión del software protegido (2p) , informar al sistema de procesado de datos (3) y/o modificar el funcionamiento de la porción del software protegido (2p) , de manera que se modifica el

funcionamiento del softwa re protegido (2p) ,

y en ausencia de la unidad (6) , a pesar de la petiCión de una porción de la primera parte de ejecución (2pes) de activar la ejecución en la unidad (6) , de la funcionalidad de un procesado algoritmico seleccionado, no poder responder correctamente a esta petición, de manera que por lo menos esta porción no se ejecuta correctamente y, en consecuencia, el software protegido (2p) no es completamente funcional.

2. Procedimiento según la reivindicación 1, para limitar la utilización de un software protegido (2p) , caracterizado por que consiste en:

~ en la fase de protección (P) : definir:

como caracteristica de ejecución de software susceptible de ser supervisada, una variable de medición del uso de una funcionalidad de un software, como criterio que se debe respetar, por lo menos un umbral asociado a cada variable de medición,

y unos medios de actualización que permiten actualizar por lo menos una variable de medición, construir los medios operativos que permiten que la unidad (6) implemente asimismo los medios de actualización, 50 y modificar el software protegido (2p) : seleccionando como caracteristica de ejecución de software que se debe supervisar, por lo menos una variable de medición del uso de una funcionalidad de un software, 55 seleccionando:

por lo menos una funcionalidad del software protegido (2p) cuyo uso es susceptible de ser supervisado gracias a una variable de medición,

por lo menos una variable de medición que sirve para cuantificar el uso de dicha funcionalidad,

por lo menos un umbral asociado a una variable de medición seleccionada correspondiente a un límite de uso de dicha funcionalidad,

y por lo menos un método de actualización de una variable de medición seleccionada en función del

uso de dicha funcionalidad ,

y modificando por lo menos una porción seleccionada de la fuente del software proteg ido (2ps) , siendo

5 esta modificación tal que, durante la ejecución del software protegido (2p) , la variable de med ición se

actualiza por med io de la segunda parte de ejecución (2peu) , en función del uso de dicha funcionalidad y

se tiene en cuenta por lo menos una superaCión de umbral,

~ yen la fase de utilización (U) , en presencia de la unidad (6) , yen el caso en el que se detecte por lo menos

10 una superación de umbral correspondiente a por lo menos un límite de uso, informar al sistema de procesado

de datos (3) y/o mod ificar el fu ncionam iento de la porción del software proteg ido (2p) , de modo que se

mod ifica el funcionam iento del software protegido (2p) .

3. Procedimiento segú n la reivindicación 2, caracterizado por que consiste en:

15

~ en la fase de protección (P) :

defin ir:

20 para por lo menos una va riable de medición, varios umbrales asociados ,

y unos medios de coerción diferentes correspondientes a cada uno de estos umbrales,

y modifi car el software protegido (2p) :

25

seleccionando en la fuente del software protegido (2ps) , por lo menos una variable de med ición

seleccionada a la cual se deben asociar varios umbrales correspondientes a los límites diferentes de

uso de la funcionalidad,

30 seleccionando por lo menos dos umbrales asociados a la variable de medición seleccionada,

y mod ificando por lo menos una porción seleccionada de la fuente del software protegido (2ps) , siendo

esta modifi cación tal que, durante la ejecución del software protegido (2p ) , se tienen en cuenta las

superaciones de los diversos umbrales, por medio de la segunda parte de ejecución (2peu) , de

35 manera d iferente ,

~ yen la fase de utilización (U) :

en presencia de la unidad (6) :

40

en el caso en el que se detecte la superación de un primer umbral, ordenar al software protegido (2p)

que no utilice más la funcional idad correspondiente,

y en el caso en el que se detecte la superación de un segundo umbral, convertir en inoperativa la

45 funcionalidad correspond iente yfo por lo menos una porción del software protegido (2p) .

4. Procedimiento segú n la reivindicación 2 o 3, caracterizado por que consiste en :

~ en la fase de protección (P) :

50

defin ir unos medios de recarga que permiten acreditar por lo menos un uso suplementa rio para por lo

menos una funcionalidad de software supervisada por una variable de medición ,

construir los medios operativos que permiten asimismo que la unidad (6) implemente los medios de

55 recarga,

y modificar el software protegido (2p) :

seleccionando en la fuente del software protegido (2ps) , por lo menos una variable de med ición

60 seleccionada que permite limitar el uso de una funcionalidad a la cual se debe poder acred itar por lo

menos un uso suplementario,

y modificando por lo menos una porCión seleccionada, siendo esta modificación tal que en una fase

denom inada de recarga, se puede acred itar por lo menos un uso suplementa rio de por lo menos una

65 funcionalidad correspond iente a una va ri able de medición seleccionada,

~ yen la fase de recarga:

reactualizar por lo menos una variable de medición seleccionada yfo por lo menos un umbral asociado, de

5 manera que se permita por lo menos un uso suplementario de la funcionalidad.

5. Procedimiento segú n la reivindicación 1, caracterizado por que consiste en:

~ en la fase de protección (P) :

10

defin ir:

como característica de ejecución de software susceptible de ser supervisada, un perfil de uso de

software,

15

y como criterio que se debe respetar, por lo menos un rasgo de ejecución de software,

y modificar el software protegido (2p) :

20 seleccionando como característica de ejecución de software que se debe supervisar por lo menos un

perfil de uso de software,

seleccionando por lo menos un rasgo de ejecución que debe ser respetado por lo menos por un perfil

de uso seleccionado,

25

y modificando por lo menos una porción seleccionada de la fuente del software protegido (2ps) , siendo

esta modificación tal que, durante la ejecución del software protegido (2p) , la segunda parte de

ejecución (2peu) respeta todos los rasgos de ejecución seleccionados,

30 ~ y en la fase de utilización (U) en presencia de la unidad (6) , y en el caso en el que se detecte que no se

respeta por lo menos un rasgo de ejecución, informar al sistema de procesado de datos (3) y/o mod ificar el

funcionamiento de la porción del software protegido (2p) , de modo que se modifique el funcionamiento del

software protegido (2p) .

35 6. Procedimiento segú n la reivindicación 5, caracterizado por que consiste en:

~ en la fase de protección (P) :

definir:

40

un juego de instrucciones cuyas instrucciones son susceptibles de ser ejecutadas en la unidad (6) ,

un juego de órdenes de instrucciones para este juego de instrucciones, siendo susceptibles estas

órdenes de instrucciones de ser ejecutadas en el sistema de procesado de datos (3) y de activar en la

45 unidad (6) la ejecución de las instrucciones,

como perfil de uso, el encadenamiento de las instrucciones,

como rasgo de ejecución, un encadenamiento deseado para la ejecución de las instrucciones,

50

como medios de detección (17) , unos medios que permiten detectar que el encadenamiento de las

instrucciones no corresponde al deseado,

y como medios de coerción (18) , unos medios que permiten informar al sistema de procesado de

55 datos (3) y/o modificar el funcionamiento de la porción de software proteg ido (2p) cuando el

encadenamiento de las instrucciones no corresponde al deseado,

constru ir los med ios operativos que permiten asimismo que la unidad (6) ejecute las instrucciones del

juego de instrucciones, siendo activada la ejecución de estas instrucciones por la ejecución en el sistema

60 de procesado de datos (3) , de las órdenes de instrucciones,

y modifi car el software protegido (2p) :

modificando por lo menos una porción seleccionada de la fuente del software protegido (2ps) , siendo

65 esta modificación tal que:

se descompone por lo menos un procesado algorítmico seleccionado, de manera que durante la ejecución del software protegido (2p) , este procesado algorítmico se ejecuta por medio de la segunda parte de ejecución (2peu) , utilizando instrucciones;

para por lo menos un procesado algorltmico seleccionado, se integran órdenes de instrucciones en la fuente del software protegido (2ps) , de manera que durante la ejecución del software protegido (2p) , cada orden de instrucción es ejecutada por la primera parte de ejecuciÓn (2pes) y la misma activa en la unidad (6) , la ejecución por medio de la segunda parte de ejecuciÓn (2peu) , de una instrucción,

se selecciona una secuenciación de las órdenes de instrucciones entre el conjunto de las secuenciaciones que permiten la ejecución del software protegido (2p) ,

y se especifica el encadenamiento que deben respetar por lo menos algunas de las instrucciones durante su ejecución en la unidad (6) ,

~ y en la fase de utilización (U) , en presencia de la unidad (6) , en el caso en el que se detecte que el encadenamiento de las instrucciones ejecutadas en la unidad (6) no corresponde al deseado, informar al sistema de procesado de datos (3) y/o modificar el funcionamiento de la porción del software protegido (2p) , de manera que se modifique el funcionamiento del software protegido (2p) .

7. Procedimiento según la reivindicación 6, caracterizado por que consiste en: ~ en la fase de protección (P) : 25 definir: como juego de instrucciones, un juego de instrucciones de las cuales por lo menos ciertas instrucciones trabajan sobre los registros y utilizan por lo menos un operando con el fin de producir un resultado,

para por lo menos una parte de las instrucciones que trabajan sobre los registros:

una parte (PF) que define la funcionalidad de la instrucción,

y una parte que define el encadenamiento deseado para la ejecución de las instrucciones y que consta de unos campos de bits que corresponden a:

o un campo de identificación de la instrucción (CII) , 40 o y para cada operando de la instrucción:

* un campo de bandera (CDk) ,

* y un campo de identificación prevista (CIPk) del operando,

para cada registro perteneciente a los medios operativos y utilizado por el juego de instrucciones, un campo de identificación generada (CIGv) en el cual se memoriza automáticamente la identificación de la última instrucción que ha producido su resultado en este registro,

como medios de detección (17) , unos medios que permiten, durante la ejecución de una instrucción, para cada operando, cuando lo impone el campo de bandera (CDk) , controlar la igualdad entre el campo de identificación generada (CIG.) correspondiente al registro utilizado por este operando, y el campo de identificación prevista (CIPk) del origen de este operando,

y como medios de coerción (18) , unos medios que permiten modificar el resultado de las instrucciones, si por lo menos una de las igualdades controladas es falsa.

8. Procedimiento según una de las reivindicaciones 1 a 7, caracterizado por que consiste en:

~en la fase de protección (P) : modificar el software protegido (2p) :

seleccionando por lo menos una variable utilizada en por lo menos un procesado algoritmico

seleccionado, que durante la ejecución del software proteg ido (2p) , define parcialmente el estado del

software proteg ido (2p) ,

5 mod ificando por lo menos una porCión seleccionada de la fuente del software protegido (2ps) , siendo

esta mod ificación tal que durante la ejecución del software protegido (2p) , por lo menos una variable

seleccionada o por lo menos una copia de va riable seleccionada reside en la unidad (6) ,

y produciendo:

la primera parte objeto (2pos) del software protegido (2p) , siendo tal esta primera parte objeto

(2pos) que durante la ejecución del software proteg ido (2p) , por lo menos una porción de la

primera parte de ejecución (2pes) tiene asimismo en cuenta que por lo menos una variable o por lo

menos una copia de variable reside en la unidad (6) ,

15

y la segunda parte objeto (2pou) del software protegido (2p) , siendo esta segunda parte objeto

(2pou) tal que, después de su carga en la unidad (6) y durante la ejecución del software protegido

(2p) , aparece la segunda parte de ejecución (2peu) por med io de la cual por lo menos una variable

seleccionada o por lo menos una copia de variable seleccionada reside asimismo en la unidad (6) ,

~y en la fase de utilización (U) :

en presencia de la unidad (6) cada vez que lo impone una porción de la primera parte de ejecución

(2pes) , utilizar una variable o una copia de variable que reside en la unidad (6) , de manera que esta

25 porción se ejecuta correctamente y, en consecuencia , el software protegido (2p) es completamente

funcional,

y en ausencia de la unidad (6) , a pesar de la petiCión de una porción de la primera parte de ejecución

(2pes) utilizar una variable o una copia de variable que reside en la unidad (6) , no poder responder

correctamente a esta petición, de manera que por lo menos esta porción no se ejecuta correctamente y,

en consecuencia, el software protegido (2p) no es completamente funcional.

9. Procedimiento según la reivindicación 6, caracterizado por que consiste en:

35 ~ en la fase de protección (P) :

defin ir:

como una orden activadora, una orden de instrucción,

como una función dependiente, una instrucción,

como una consigna, por lo menos un argumento para una orden activadora, correspondiente por lo

menos en parte a la información transmitida por el sistema de procesado de datos (3) a la unidad (6) ,

45 con el fin de activar la ejecución de la función dependiente correspond iente,

un método de renombramienlo de las consignas que permite renombrar las consignas con el fin de

obtener u nas órdenes activadoras de consignas renombradas,

y unos medios de restablecimiento (20) destinados a ser implementados en la unidad (6) en el curso

de la fase de utilización (U) , y que permiten recuperar la función dependiente que se debe ejecutar, a

partir de la consigna renombrada,

constru ir unos med ios operativos que permiten que la unidad (6) implemente asimismo los medios de

55 restablecimiento,

y modificar el software protegido (2p) :

seleccionando en la fuente del software protegido (2ps) , unas órdenes activadoras,

mod ificando por lo menos una porción seleccionada de la fuente del software proteg ido (2ps) al

renombrar las consignas de las órdenes activadoras seleccionadas, con el fin de ocultar la identidad

de las funciones dependientes correspond ientes,

65 y produciendo:

41

la plimera parte objeto (2pos) del software protegido (2p) , siendo tat esta primera parte objeto (2pos) que durante la ejecución del software protegido (2p) , se ejecutan las órdenes activadoras de consignas renombradas,

y la segunda parte objeto (2pou) del software protegido (2p) que contiene los medios operativos que implementan asimismo los medios de restablecimiento (20) , siendo tal esta segunda parte objeto (2pou) que, después de su carga en la unidad (6) y durante la ejecución del software protegido (2p) , se restablece por medio de la segunda parte de ejecución (2peu) la identidad de las funciones dependientes cuya ejecución es activada por la primera parte de ejecución (2pes) , y las funciones dependientes son ejecutadas por medio de la segunda parte de ejecución (2peu) ,

~ yen la fase de utilización (U) :

en presencia de la unidad (6) y cada vez que una orden activadora de consigna renombrada , contenida en una porción de la primera parte de ejecución (2pes) lo impone, restablecer en la unidad (6) , la identidad de la función dependiente correspondiente y ejecutar la misma, de modo que esta porción se ejecuta correctamente y que, en consecuencia, el software protegido (2p) es completamente funcional,

Y en ausencia de la unidad (6) , a pesar de la petición de una porción de la primera parte de ejecución (2pes) , de activar la ejecución de una función dependiente en la unidad (6) , no poder responder correctamente a esta petición, de modo que por lo menos esta porción no se ejecuta correctamente y, en consecuencia, el software protegido (2p) no es completamente funcional.

10. Procedimiento según la reivindicación 9, caracterizado por que consiste en:

~ en la fase de protección (P) :

definir para por lo menos una función dependiente, una familia de funciones dependientes 30 algorítmica mente equivalentes, aunque activadas por órdenes activadoras cuyas consignas renombradas son diferentes,

y modificar el software protegido (2p) :

seleccionando en la fuente del software protegido (2ps) por lo menos una orden activadora de consigna renombrada,

y modificando por lo menos una porción seleccionada de la fuente del software protegido (2ps) sustituyendo por lo menos la consigna renombrada de una orden activadora de consigna renombrada 40 seleccionada, por otra consigna renombrada, que activa una función dependiente de la misma familia.

11. Procedimiento segú n la reivindicación 10, caracterizado por que consiste en:

~ en la fase de protección (P) , definir, para por lo menos una función dependiente, una familia de funciones 45 dependientes algorítmica mente equivalentes:

concatenando un campo de ruido con la infonnación que define la parte funcional de la función dependiente que se debe ejecutar en la unidad (6) ,

o utilizando el campo de identificación de la instrucción (Gil) y los campos de identificación prevista (GIPk) de los operandos.

12. Procedimiento según la reivindicación 9, 10 u 11, caracterizado por que consiste en:

~ en la fase de protección (P) :

definir:

como método de renombramiento de las consignas, un método de cifrado para cifrar las consignas,

y como medios de restablecimiento (20) , unos medios que implementan un método de descifrado para descifrar las consignas renombradas y restablecer asi la identidad de las funciones dependientes que se deben ejecutar en la unidad (6) .

13. Procedimiento segú n una de las reivindicaciones 1 a 12, caracterizado por que consiste en:

~ en la fase de protección (P) :

modificar el software protegido (2p) :

seleccionando en la fuente del software protegido (2ps) , por lo menos un salto condicional efectuado en por lo menos un procesado algoritmico seleccionado,

modificando por lo menos una porción seleccionada de la fuente del software protegido (2ps) , siendo tal esta modificación que durante la ejecución del software protegido (2p) , se ejecuta la funcionalidad de por lo menos un salto condicional seleccionado, por medio de la segunda parte de ejecución (2peu) , en la unidad (6) ,

y produciendo:

la primera parte objeto (2pos) del software protegido (2p) , siendo tal esta primera parte objeto (2pos) que durante la ejecución del software protegido (2p) , se ejecuta la funcionalidad de por lo menos un salto condicional seleccionado en la unidad (6) ,

Y la segunda parte objeto (2pou) del software protegido (2p) , siendo tal esta segunda parte objeto (2pou) que, después de su carga en la unidad (6) y durante la ejecución del software protegido (2p) , aparece la segunda parte de ejecución (2peu) por medio de la cual se ejecuta la funcionalidad de por lo menos un salto condicional seleccionado,

~ yen la fase de utilización (U) :

en presencia de la unidad (6) y cada vez que lo impone una porción de la primera parte de ejecución (2pes) , ejecutar la funcionalidad de por lo menos un salto condicional en la unidad (6) , de modo que esta porción se ejecuta correctamente y, en consecuencia, el software protegido (2p) es completamente funcional ,

yen ausencia de la unidad (6) y a pesar de la petición de una porción de la primera parte de ejecución (2pes) de ejecutar la funcionalidad de un salto condicional en la unidad (6) , no poder responder correctamente a esta petición, de modo que por lo menos esta porción no se ejecuta correctamente y que,

en consecuencia, el software protegido (2p) no es completamente funcional.

14. Procedimiento segun la reivindicación 13, caracterizado por que consiste, en la fase de protección (P) , en modificar el software protegido (2p) :

seleccionando, en la fuente del software protegido (2ps) por lo menos una serie de saltos condicionales seleccionados,

modificando por lo menos una porción seleccionada de la fuente del software protegido (2ps) , siendo tal esta modificación que durante la ejecución del software protegido (2p) , se ejecuta la funcionalidad global de por lo 45 menos una serie seleccionada de saltos condicionales por medio de la segunda parte de ejecución (2peu) , en la unidad (6) ,

y produciendo:

la primera parte objeto (2pos) del software protegido (2p) , siendo tal esta primera parte objeto (2pos) que durante la ejecución del software protegido (2p) , se ejecuta la funcionalidad de por lo menos una serie seleccionada de saltos condicionales en la unidad (6) ,

y la segunda parte objeto (2pou) del software protegido (2p) , siendo tal esta segunda parte objeto (2pou)

que, después de su carga en la unidad (6) y durante la ejecución del software protegido (2p) , aparece la segunda parte de ejecución (2peu) por medio de la cual se ejecuta la funcionalidad global de por lo menos una serie seleccionada de saltos condicionales.

15. Procedimiento segun una de las reivindicaciones 1 a 14, caracterizado por que consiste en descomponer la fase de protección (P) en una subfase de protección aguas arriba (P1 ) , independiente del software que se debe proteger y una subfase de protección aguas abajo (P2) , dependiente del software que se debe proteger.

16. Procedimiento según la reivindicación 15, caracterizado por que consiste, durante la subfase de protección aguas arriba (P1) , en hacer intervenir un estadio de definiciones ($11) en el cual se efectúan todas las definiciones.

17. Procedimiento según la reivindicación 16, caracterizado por que consiste, después del estadio de definiciones (S11) , en hacer intervenir un estadio de construcción (S12) en el cual se construyen los medios operativos.

18. Procedimiento según la reivindicación 17, caracterizado por que consiste, después del estadio de construcción (S12) , en hacer intervenir un estadio de prepersonalización (S13) , que consiste en cargar en una unidad virgen (60) , por lo menos una parte de los medios operativos con el fin de obtener una unidad prepersonalizada (66) .

19. Procedimiento según la reivindicación 16 o 17, caracterizado por que consiste, durante la subfase de protección aguas arriba (P1) , en hacer intervenir un estadio de elaboración de herramientas (S14) en el cual se elaboran las herramientas que permiten ayudar a generar softwares protegidos o automatizar la protección de softwares.

20. Procedimiento según las reivindicaciones 15 y 18, caracterizado por que consiste en descomponer la subfase de protección aguas abajo (P2) , en:

un estadio de creación (S21) en el cual se crea el software protegido (2p) , a partir del software vulnerable (2v) ,

eventualmente, un estadio de modificación (S22) en el cual se modifica el software protegido (2p) ,

y un estadio de personalización ($23) en el cual :

la segunda parte objeto (2pou) del software protegido (2p) que contiene los medios operativos se carga en por lo menos una unidad virgen (60) con el fin de obtener por lo menos una unidad (6) ,

o una parte de la segunda parte objeto (2pou) del software protegido (2p) que contiene eventua lmente los medios operativos se carga en por lo menos una unidad prepersonalizada (66) con el fin de obtener por lo menos una unidad (6) .

21. Procedimiento según las reivindicaciones 19 y 20, caracterizado por que consiste, durante el estadio de creación (S21) y eventualmente el estadio de modificación (S22) , en utilizar por lo menos una de las herramientas de ayuda para la generación de softwares protegidos o de automatización de la protección de softwares.