Anatomía de una patente trivial

por Richard Stallman

Los programadores saben bien que muchas patentes de software cubren ideas ridículamente obvias. Pero los defensores del sistema de patentes a menudo alegan que estas ideas no son triviales, que sólo resultan obvias a posteriori. Y es sorprendentemente difícil derrotarlos en un debate. ¿Por qué es así?

Una de las razones es que cualquier idea puede parecer compleja cuando se la analiza hasta la extenuación. Otra razón de que estas ideas triviales parezcan complejas es la forma en que se describen en las propias patentes. Así, los defensores del sistema de patentes pueden señalar la descripción compleja, y decir: «¿Cómo puede ser obvio algo tan complejo?»

Lo ilustraré con un ejemplo. Esta es la primera reclamación de la patente estadounidense número 5.963.916, solicitada en octubre de 1996:

1. Un método para permitir a un usuario remoto escuchar un fragmento de un producto musical pregrabado, desde un sitio web que contiene fragmentos preseleccionados de distintos productos musicales pregrabados, usando un ordenador, un monitor de ordenador y una conexión telemática entre el ordenador del usuario remoto y el sitio web. Este método comprende los siguientes pasos:

• a) uso del ordenador del usuario remoto para establecer una conexión telemática al sitio web, el cual se compone de (i) un servidor central acoplado a una red de comunicaciones para recuperar y transmitir el fragmento preseleccionado del producto musical pregrabado a solicitud del usuario remoto, y (ii) un dispositivo de almacenamiento central para guardar fragmentos preseleccionados de una serie de diferentes productos musicales pregrabados;

• b) transmisión de datos de identificación del usuario desde el ordenador del usuario remoto hasta el servidor central, permitiendo así al servidor identificar y realizar un seguimiento de la actividad del usuario en el sitio web;

• c) elección de al menos un fragmento preseleccionado de los productos musicales pregrabados, entre los almacenados en el servidor central;

• d) recepción del fragmento preseleccionado de los productos pregrabados que se haya elegido; y

• e) escucha previa del fragmento preseleccionado de los fragmentos de productos musicales pregrabados que se ha elegido y recibido.

Sí que parece un sistema complejo, ¿verdad? ¿Hace falta ser muy listo para inventar algo así? No, pero se necesita ingenio para hacerlo parecer tan complejo. Analicemos el origen de esta complejidad:

1. Un método para permitir a un usuario remoto escuchar un fragmento de un producto musical pregrabado, desde un sitio web que contiene fragmentos preseleccionados

Aquí se expone la parte principal de la idea. Colocan selecciones de ciertas piezas musicales en un servidor, de forma que el usuario pueda escucharlas.

de distintos productos musicales pregrabados,

Aquí se pone de relieve que el servidor contiene fragmentos de más de una pieza musical.

Es un principio básico de la informática que si un ordenador puede hacer algo una vez, también puede hacerlo muchas veces, con distintos datos cada vez. En muchas patentes se alega que aplicar este principio a un caso específico constituye una «invención».

usando un ordenador, un monitor de ordenador y una conexión telemática entre el ordenador del usuario remoto y el sitio web.

Aquí se dice que están utilizando un servidor en una red.

Este método comprende los siguientes pasos:

a) uso del ordenador del usuario remoto para establecer una conexión telemática al sitio web

Aquí se dice que el usuario se conecta al servidor a través de la red (así es como se usa un servidor).

el cual se compone de (i) un servidor central acoplado a una red de comunicaciones

Aquí nos informan de que el servidor está en la red (es lo habitual en los servidores).

para recuperar y transmitir el fragmento preseleccionado del producto musical pregrabado a solicitud del usuario remoto

Aquí se repite la idea general expuesta en las dos primeras líneas.

y (ii) un dispositivo de almacenamiento central para guardar fragmentos preseleccionados de una serie de diferentes productos musicales pregrabados;

Han decidido instalar un disco duro, o algo equivalente, en su ordenador para almacenar las muestras musicales. Desde alrededor de 1980 este ha sido el método habitual para almacenar cualquier cosa en un ordenador y acceder rápidamente a ella.

Nótese cómo vuelven a enfatizar el hecho de que pueden almacenar más de una selección en ese disco. Por supuesto que cualquier sistema de ficheros le permite a uno almacenar más de un fichero.

b) transmisión de datos de identificación del usuario desde el ordenador del usuario remoto hasta el servidor central, permitiendo así al servidor identificar y realizar un seguimiento de la actividad del usuario en el sitio web;

Esto nos dice que hacen un seguimiento de quién y a qué está accediendo; algo común, aunque desagradable, en el funcionamiento de los servidores web. Creo que ya en 1996 era algo habitual.

c) elección de al menos un fragmento preseleccionado de los productos musicales pregrabados, entre los almacenados en el servidor central;

En otras palabras, el usuario hace clic con el ratón para indicar qué enlaces seguir. Eso es lo normal en los servidores web. Si hubieran encontrado otra forma de hacerlo, eso sí podría haber sido un invento.

d) recepción del fragmento preseleccionado de los productos pregrabados que se haya elegido; y

Cuando se sigue un enlace, el navegador lee el contenido enlazado. Este es el comportamiento habitual de los navegadores web.

e) escucha previa del fragmento preseleccionado de los fragmentos de productos musicales pregrabados que se ha elegido y recibido.

Aquí se dice que el navegador reproduce la música. Es lo que hacen muchos navegadores cuando se sigue un enlace a un archivo de audio.

Ahora queda claro cómo han maquillado esta reclamación para convertirla en una idea compleja: han combinado su propia idea (enunciada en dos líneas) con aspectos importantes de lo que hacen los ordenadores, las redes, los servidores y los navegadores web. Todo esto da lugar a la llamada invención por la que recibieron la patente.

Es un típico ejemplo de las patentes de software. Incluso aquellas raras patentes cuya idea no es trivial llevan el mismo tipo de complejidad añadida.

Fijémonos ahora en una reclamación posterior:

3. El método de la reclamación 1, donde el dispositivo de memoria central se compone de una pluralidad de discos compactos de sólo lectura (CD-ROM).

Lo que nos están diciendo aquí es lo siguiente: «Incluso si no creéis que la reclamación 1 es verdaderamente un invento, usar CD-ROM para almacenar datos seguro que lo es. Al informático diseñador de sistemas medio nunca se le hubiera ocurrido esto».

Veamos ahora la reclamación siguiente:

4. El método de la reclamación 1, donde el dispositivo de memoria central se compone de un conjunto de discos RAID.

Un conjunto RAID es un grupo de discos dispuestos para funcionar como un solo gran disco, con la particularidad de que incluso si un disco del conjunto fallara y dejara de funcionar, todos los datos seguirían disponibles en los demás discos del grupo. Este tipo de conjuntos de discos han estado disponibles en el mercado desde mucho antes de 1996, y son el método estándar para el almacenamiento de datos de gran disponibilidad. Pero estos brillantes inventores han patentado el uso de los conjuntos RAID de discos para este propósito particular.

Por trivial que pudiera parecer, esta patente no sería declarada legalmente inválida si fuera objeto de una demanda judicial. No sólo la Oficina de Patentes de EE. UU., sino también los tribunales tienden a aplicar criterios muy laxos a la hora de juzgar si una patente «no es obvia». Según esos criterios, esta patente podría recibir la aprobación.

Es más, los tribunales son reacios a desautorizar a la Oficina de Patentes, de manera que existe mayor probabilidad de conseguir que una patente sea denegada si se puede presentar pruebas de la existencia de una técnica anterior que la Oficina de Patentes no haya tomado en consideración. Si los tribunales se muestran dispuestos a aplicar criterios más estrictos a la hora de decidir si algo es obvio o no, es útil archivar técnicas anteriores para poder mostrárselas. Por lo tanto, las propuestas de facilitar a la Oficina de Patentes una mejor base de datos de las técnicas anteriores para «hacer que el sistema funcione mejor» podrían empeorar las cosas.

Es muy difícil lograr que el sistema de patentes funcione de manera razonable: se trata de una compleja burocracia que tiende a seguir sus imperativos estructurales, dejando a un lado lo que «se supone» que tiene que hacer. La única forma práctica de librarnos de las numerosas patentes obvias en las áreas del software y de las prácticas comerciales es deshacernos de todas las patentes en esos campos. Afortunadamente, esto no supondría pérdida alguna: en el ámbito del software, tampoco las patentes que no son obvias aportan nada. Las patentes de software no sirven más que para poner bajo amenaza a desarrolladores y usuarios.

Se supone que el propósito del sistema de patentes es promover el progreso, y aquellos que se benefician de las patentes de software pretenden que creamos sin cuestionamientos que el sistema tiene ese efecto. Pero la experiencia de los programadores indica lo contrario. Recientes análisis teóricos muestran que esto no tiene nada de paradójico (véase researchoninnovation.org/patent.pdf en web.archive.org). No hay ninguna razón para que la sociedad exponga a los desarrolladores de software y a los usuarios al peligro de las patentes de software.