Por más de veinte años, la Oficina de Patentes y Marcas de los EE.UU. (USPTO por sus siglas en inglés), las Tribunales y la industria de software han estado luchando sobre el asunto de las patentes de software. 1

Tradicionalmente, los creadores de software prestaban poca atención a la protección de patentes para su software. Antes de 1981, la USPTO se había rehusado, rutinariamente, a emitir tales patentes. 2

Como resultado, el público en general percibía al software como no patentable. Además, el secreto industrial y la protección del copyright, más que las patentes, servían como métodos de “prueba y acierto” ampliamente reconocidos para proteger los derechos del software. 3

Com-Share, Inc. v. Computer Complex, Inc., 338 F. Supp. 1229 (E.D. Mich. 1971); aff'd 458 F.2d 1341 (6th Cir. 1972);

Computer Software Copyright Act of 1980, amending 17 U.S.C. §§ 101, 117;

Apple Computer, Inc. v. Franklin Computer Corp., 714 F.2d 1240 (3rd Cir. 1983); (programas computacionales susceptibles de protección bajo las leyes de copyright ya sea en su modalidad de fuente o de forma).

Los inventores de software, por lo tanto, se mostraban reticentes a invertir miles de dólares en una solicitud de patente que – tal vez- ni siquiera resistiría contra un desafío en la corte. En consecuencia, la industria de software creció, por muchos años, sobre la base de una cantidad significativa de tecnología no patentada.4

Sin embargo, en los últimos veinte años, la obtención de patentes de software se volvió cada vez más prominente, incentivando los debates de académicos, la barra de patentes, la USPTO, los científicos computacionales y las corporaciones de la industria del software.

II. Las bases legales y la historia de las patentes de software

La ley de patentes en EE.UU. se originó en un estatuto y descansa sobre la providencia del Congreso. Los sujetos patentables en los EE.UU. incluyen: “cualquier proceso, máquina, manufactura, redacción sobre una materia que sean nuevos o útiles, o cualquier mejoría nueva o útil que se desprenda de éstas.” 35 U.S.C. § 101. “Proceso” es definido como un proceso, arte o método, e incluye cualquier uso nuevo de un proceso, máquina, manufactura, redacción sobre una materia o material conocidos. 35 U.S.C. § 100(b).

Las cortes han interpretado la Ley de Patentes para excluir “una idea, principio o fuerza abstracta, una ley de la naturaleza o un fenómeno natural”. In re Alppat, 33 F.3rd 1526, 1552 (Fed. Cir. 1994). De 1972 a 1981, dos decisiones de la Suprema Corte forjaron el horizonte de las leyes de patente de software.5

En 1972, la Corte rechazó una patente para una fórmula que convertía señales decimales codificadas a la forma binaria, sosteniendo que un proceso debe transformar y reducir materiales a un estado o una cosa diferentes para ser patentable. Véase Gottschalk v. Benson 409 U.S. 63 (1972). La corte declaró que los programas computacionales en sí mismos no eran patentables sin la autorización del Congreso. Véase id.

Después vino Diehr, el caso que sentó precedentes para validar las patentes de software. Véase Diamond v. Diehr, 450 US 175 (1981). La Corte, entonces, permitió una demanda por un método de tratar el hule que utilizaba una computadora para fines de monitoreo, sosteniendo que, aunque por sí misma una fórmula matemática no es patentable, una demanda que contiene esta fórmula constituye materia patentable cuando se implementa a una estructura o proceso que realiza una función cubierta por la ley de patentes. Véase id. Desde Diehr, el uso de una fórmula matemática y una computadora digital programada se volvieron patentables cuando son explicadas como parte de un proceso.6

III. El alcance de las patentes de software

En las últimas dos décadas, se han otorgado patentes para proteger una diversidad de software, desde compiladoras hasta aplicaciones, y para brindar protección para el proceso o método subyacente realizado por un programa computacional. 7 Véase Atari Games Corp. V. Nintendo of America Inc., 975 F.2d 832, 839 (Fed. Cir. 1992). Una patente relacionada al software es aquélla que reclama para toda o casi toda su invención alguna característica, función o proceso encarnado en un programa computacional ejecutado en una computadora.8

El software patentado incluye software de sistemas y varios tipos de software de aplicaciones, incluyendo el software de negocios, el software interactivo de usuarios, y el software de sistema experto. 9

En general, son los aspectos funcionales del software los que han sido patentados; tales como los procesos, la edición y las funciones de control, y las técnicas de sistemas de compilación y operación.10

Dentro de la categoría de patentes de diseño, los íconos y los tipos de fuente electrónicos también están siendo patentados. 11

IV. Las patentes contra otras protecciones de software

No fue sino hasta en los últimos veinte años que las patentes comenzaron a jugar un papel cada vez más significativo en la propiedad intelectual del software. Los creadores se han valido, por mucho tiempo, en el secreto del comercio y en el copyright para proteger sus derechos. El secreto del comercio, por definición, no prohibe ningún desarrollo por parte de alguien que no está consciente del material reclamado como secreto de comercio.12

Un ingeniero computacional que creó un programa independientemente de otra compañía que posee el mismo programa, como un secreto de comercio no le debe nada a esa compañía. Las patentes, por otro lado, excluyen a cualquier persona de utilizar la invención reclamada, independientemente de su conocimiento o falta de él, acerca de la patente. Si la compañía hubiese patentado el programa en lugar de haberlo guardado como secreto de comercio, el ingeniero estaría, ahora, infringiendo la patente de la compañía.

El copyright cubre la implementación de detalles de un programa particular. 13

El alcance del copyright se extiende sólo a los detalles de expresión de un trabajo, no a las ideas.14

El copyright no cubre las características del programa o los métodos generales utilizados.15

Las patentes, por otro lado, no cubren sistemas específicos o programas individuales. En su lugar, cubren técnicas particulares que pueden ser utilizadas para construir sistemas, o las características que los sistemas pueden ofrecer.16

Una vez que la técnica o característica es patentada, otros programadores no pueden utilizarla en un sistema sin la autorización del poseedor de la patente, aunque el programador implemente la técnica de una manera distinta.17 Aún más, la creación independiente, una legítima defensa contra la infracción de copyrights, no otorga, al programador, protección alguna contra una demanda de infracción de patente.18

Las patentes, por tanto, son creaciones diferentes y más peligrosas para los creadores de software que sus compañeras en el campo de la propiedad intelectual. Toda vez que los programas computacionales usualmente utilizan muchas técnicas y ofrecen diversas características, un programa puede, fácilmente, infringir muchas patentes a la vez.

V. Argumentos comunes contra las patentes de software

Richard Stallman, en su discurso sobre las patentes de software, en el Laboratorio de Computación de la Universidad de Cambridge, resaltó algunas quejas frecuentes contra las patentes de software. 19

A. El elevado costo de la busqueda de la patentabilidad

Uno de los mayores obstáculos que representa el patentar software para la industria es la falta de información pública disponible sobre qué algoritmos o técnicas han sido ya patentadas y están, por lo tanto, prohíbidas para los programadores. Un creador de software debe primero determinar, a través de una búsqueda de susceptibilidad para patentar, qué patentes viola el programa antes de poder lanzar el producto.

Tal búsqueda, si es realizada por un abogado contratado, es extremadamente costosa en tiempo y dinero; lo cual lo pone, por lo tanto, fuera del alcance de creadores independientes de software. Aquellos que se aventuran a realizar la búsqueda de la patentabilidad encuentran una lista demasiado larga de combinaciones relacionadas, debido a que el lenguaje de las patentes es altamente especializado y extremadamente difícil de entender para cualquier ingeniero. 20

B. La poca confiabilidad de las busquedas de patentabilidad

Además de la dificultad de buscar patentes anteriores, y debido a que las solicitudes de patentes pendientes son confidenciales hasta por un periodo de dieciocho meses cuando son publicadas, un creador de software no encontrará estas solicitudes en una busca de patentibilidad. Véase 35 U.S.C. §122; 37 C.F.R 1.14(a).

Un ingeniero de software puede diseñar y lanzar un programa en este lapso y darse cuenta después de que éste infringe la patente de una invención previamente adjudicada. El resultado es que los científicos computacionales siempre tendrán que estar alertas, mientras desarrollan sus programas, por miedo a infringir cualquier patente posible y, aún así, continúan expuestos al riesgo de una demanda legal cuando haya sido emitida una solicitud de patente desconocida que cubra la misma técnica.

C. Monopolios reforzados

La búsqueda de la obtención de una patente es extremadamente costosa. Estos costos incluyen las cuotas legales pagadas a los abogados (a menos que el inventor desarrolle la experiencia necesaria para solicitar la patente por sí mismo) y las cuotas requeridas por la USPTO para obtener una patente. Las cuotas legales para solicitar una patente varían en gran medida dependiendo de la complejidad de la tecnología, la calidad del escrito y los bocetos que pueda proporcionar el inventor, la tasa del abogado de patentes y del número de cambios que el inventor realice a lo largo del proceso. Para las solicitudes de patente de complejidad moderada en las industrias de la electrónica, el software para computadoras y la biotecnología, las cuotas más comunes varían de los $5,000 a los $15,000 dólares americanos. 21

Además de las cuotas legales, todos los solicitantes deben pagar a la USPTO una cuota por solicitud que va de los US $750 a los US $1,300 dólares de Estados Unidos de América. 21

Si la patente es aprobada, el solicitante debe también pagar una cuota de emisión de, aproximadamente, $1,250 dólares de Estados Unidos de América. 22

Después de la emisión, el propietario de la patente debe pagar las cuotas de mantenimiento a los 3.5, 7.5 y 11.5 años. La omisión del pago de las cuotas de mantenimiento resultarían en la terminación de los derechos de la patente. 23

Por tanto, el costo para obtener una sola patente fluctúa, mínimo, entre los números grandes o medios de miles de dólares, 24 y aunque las pequeñas empresas (aquéllas con menos de 500 empleados totales) reciben un 50% de descuento con la USPTO, los costos son aún demasiado altos para los creadores independientes. 25 Las cuotas gastadas en el consejo legal y la consultoría de patentes desvían recursos significativos del mismo desarrollo de software. Las compañías pequeñas y los programadores individuales que no pueden costear el litigio y las búsquedas de patentes son sacados de la jugada, mientras los grandes jugadores avanzan con más poder en su exclusión de las patentes. Con más ganancias para pagar licencias exclusivas y de licencias cruzadas con otras compañías, las grandes corporaciones eventualmente transformarán el mercado y lo volverán un monopolio, eliminando, así, a los programadores jóvenes e independientes que han sido, hasta ahora, la fuente de inspiración de la industria del software.

VI. Del porque el software es diferente

Los problemas arriba planteados se refieren, principalmente, a los inconvenientes de las patentes en general. Para entender porqué las patentes de software son particularmente impropias para la industria de la programación uno debe observar las características que distinguen el desarrollo del software.

A. Los programas computacionales son bastante complejos

Los sistemas de software cuentan con un número mucho mayor de partes que los sistemas físicos. Los programas computacionales de hoy son tan complicados que contienen, literalmente, miles de algoritmos y técnicas; cada uno considerado patentable según los estándares de la USPTO. 27

Sería poco razonable esperar que cada compañía de software licenciara cada una de estas patentes; además, las patentes otorgadas por combinaciones de algoritmos y técnicas que producen una característica particular hacen aún más remota la posibilidad de crear programas no infractores.

Compárese la industria farmacéutica donde una fórmula química patentada resulta en una patente por producto. La persona que desarrolló el producto posee la patente. Una simple patente de software, por el otro lado, puede cubrir muchas ideas. 28

Debido a que los paquetes de software son muy grandes, éstos combinan muchas ideas, de las cuales algún par puede ser patentado como una combinación; por tanto, pueden existir miles de puntos de vulnerabilidad en un programa de un ingeniero, cada uno sujeto a demandas por infracción. 29

B. El desarrollo de software trabaja con objetos matematicos idealizados

Es fundamentalmente más fácil escribir un programa que diseñar un objeto físico debido a que el desarrollo de software está libre de la perversidad de la materia. 30

Un sistema de hardware debe ser diseñado utilizando componentes reales. Los sistemas físicos tienen costos, límites de operación y sensibilidad a la temperatura que varían; 31utilizan mucha energía y pueden fallar. Los modelos matemáticos pueden ser descalificados cuando el diseño es construido. 32

En contraste, los programas computacionales, aunque son inmensamente complejos, son mucho más sencillos de diseñar. Son construidos por objetos matemáticos ideales cuya conducta es definida, no moldeada por aproximaciones, por reglas abstractas. 33

Cuando una condición, revisada por una cláusula del tipo “si... entonces...” es verdadera, el comando que el programador intenta ejecutar nunca falla en la ejecución. 34

C. El desarrollo de software requiere una inversion muy baja.

Debido a que los programas computacionales son mucho más sencillos de diseñar que una contraparte de igual complejidad, sus costos de desarrollo son, también, mucho más bajos. Richard Stallman discutió en su discurso la facilidad relativa de la programación de software. Un programa de 100,000 componentes puede tener 50,000 líneas de extensión y puede ser completado, por dos programadores, en un año. Los costos de equipamiento serían de menos de US$10,000 dólares de Estados Unidos de América. Los demás costos serían los sueldos de los programadores durante dicho año. La inversión total no excedería los US $100,000 dólares de Estados Unidos de América.

Si esto es realizado de manera comercial por una gran compañía, los costos podrían duplicarse. Por otro lado, un automóvil usualmente consiste de 100,000 componentes pero requiere de un equipo de trabajo grande y de decenas de millones de dólares para su diseño. 35

Aún más, debido a que los programas de software no están confinados a una forma física, existe una tremenda simplificación y una reducción en los costos de producción y distribución. 36

En lugar de construir una fábrica para el automóvil, un programador de software puede simplemente presionar la tecla de “copiar” o quemar la información en un CD para ser duplicada. Como resultado del bajo costo para su desarrollo, los costos administrativos de lidiar con el sistema de patentes- buscar la patente, la consultoría legal y posible litigio- son tan grandes que se vuelven una carga insostenible para muchas compañías de software. 37

VII. Los problemas de las patentes de software

A pesar de las características distintivas del desarrollo de software, algunos pueden todavía argumentar que muchas otras industrias involucran inventos altamente complejos como la manufactura de aviones o las refinerías de petróleo. 38

De manera similar, muchas otras compañías cuentan con manufactureros caseros y tienen que lidiar con el sistema de patentes. Sin embargo, existen muchos problemas en el sistema de patentes que son exclusivos del desarrollo de software.

A. Revision inadecuada

Una de las quejas más grandes del proceso para patentar software es la emisión de patentes sin una revisión adecuada por parte de la USPTO. La falta de científicos computacionales que funjan como examinadores en la PTO frecuentemente da como resultado la emisión errónea de patentes en inventos obvios de software. Además, la redacción imprecisa de los reclamos por parte de los abogados y la concesión de patentes por examinadores sin experiencia hacen que las infracciones sean difíciles de determinar. 39

Adicionalmente, la PTO carece de un esquema de trabajo para clasificar las patentes de software. El sistema de búsqueda de clasificación fue diseñado para las patentes de hardware únicamente. 40 Las patentes son frecuentemente clasificadas de acuerdo a resultados finales, por ejemplo como “conversión de hierro a acero.” 41

No obstante, muchas patentes cubren algoritmos cuyo uso en un programa es completamente distinto del propósito del programa. Por ejemplo, un programa para analizar el habla humana puede infringir una patente de una componente de aceleración en el Fast Fourier Transform, tal como lo haría un programa que realice álgebra simbólica al multiplicar números grandes. 42

Es muy difícil predecir cómo puede uno encontrar la categoría apropiada para buscar dicha patente.

B. Las dificultades de la busqueda de creaciones previas.

Los examinadores de patentes frecuentemente están mal preparados para evaluar si las técnicas reclamadas en las solicitudes de patentes de software deben ser rechazadas por ser ampliamente conocidas u obvias. Muchas técnicas de software comúnmente utilizadas no se encuentran en la literatura científica. Algunas son consideradas demasiado obvias para ser publicadas; algunas son consideradas insuficientemente generales y otras son secretos a voces en la industria. 43

La vasta extensión de la literatura de las ciencias computacionales complica la búsqueda de creaciones previas. Esta literatura contempla no sólo revistas académicas o journals, sino también manuales de usuario, publicaciones de códigos fuente, y artículos populares en revistas.44

Comparado con un grupo de químicos que trabajan en una universidad importante, los cuales pueden producir veinte o treinta páginas de material publicable anualmente, un solo programador puede producir, fácilmente, cien veces más. 45

El patentar combinaciones de algoritmos y técnicas hacen la situación aún más compleja. Los creadores publican nuevos algoritmos y técnicas frecuentemente, pero casi nunca publican nuevas maneras de combinar las anteriores. 46

Cuando un examinador no puede encontrar creaciones previas debido a la imposibilidad de buscar referencias concienzudamente en la literatura, o no rechaza la solicitud por otras razones, él debe emitir la patente. El resultado de ello es una alta cantidad de patentes de software que no eran originales pero que, no obstante, fueron otorgadas.

C. Estandares laxos de obviedad.

Una solicitud de patente será rechazada si es considerada obvia- es decir, una persona de habilidades ordinarias en el oficio considerará obvio modificar lo que nos enseña una referencia a la luz de lo que nos enseña otra. Véase 35 U.S.C. § 103. La oficina de patentes interpreta la obviedad de una manera muy distinta que los programadores de cómputo. Los examinadores están acostumbrados a considerar los cambios pequeños y de incremento como meritorios de la concesión de una patente. 47

Por ejemplo, el altamente publicitado caso de Polaroid v. Kodak dependió de las diferencias en el orden y el número de capas de químicos en una película de fotografía, a lo cual la corte resolvió que se trataba de una variación obvia de las patentes previas. Véase Polaroid Corp. v. Eastman Kodak Co., 867 F.2d 1415 (Fed. Cir. 1989).

El caso es distinto en el desarrollo de software. Los científicos computacionales resuelven sus problemas rápidamente porque el medio de programación es rastreable. Los creadores de software aprenden a generalizar los principios de solución de un problema a otro. Por ejemplo, una generalización de ese tipo es que un procedimiento puede ser repetido o subdividido. 48 Este concepto, considerado obvio para los programadores, fue considerado novedoso por la Oficina de Patentes cuando otorgó una patente sobre el enrollamiento de cuerdas múltiples.49 Los bajos criterios de los exámenes de obviedad de la USPTO dan como resultado la concesión de numerosas patentes no originales y, por ende, la prohibición de su uso a otros programadores.

D. Los metodos de negocios se vuelven patentables.

Debido a las características del desarrollo de software, el potencial de abuso del sistema de patentes es mayor para el software que para otros tipos de tecnología. Por estatuto, las prácticas de negocios no son patentables. 35 U.S.C. § 101. Sin embargo, los dueños de las patentes han obtenido patentes sobre prácticas de negocios exitosamente al ejecutarlas en programas de software, los cuales sí son patentables.

La decisión Diehr, que establece que las demandas deben ser consideradas como un todo para determinar su susceptibilidad para ser patentadas, pavimentó el camino para el infame caso de State Street. La adición del software computacional ahora permite que sea patentada una práctica de negocios que, de otro modo, no lo sería. Véase State Street Bank & Trust Co. v. Signature Financial Group Inc., 149 F. 3d 1368 (Fed. Cir.1988) La corte otorgó una patente sobre fórmulas aplicadas a distintos datos de un portafolio de fondos mutuos, esencialmente haciendo patentables los métodos de negocios siempre y cuando estén implementados en programas computacionales. Véase Id.

La reciente patente de Amazon.Com denominada “one-click shopping” (compras de un solo clic) ejemplifica el efecto de la expansión de las patentes de software hacia los métodos de los negocios electrónicos. 50 En esencia, el equivalente de llamar a una compañía de órdenes por correo con un número de orden, la patente de “one click shopping” es un ejemplo de una invención negligente que conlleva a una enorme distorsión del mercado. 51

El posible resultado es que varios métodos de negocios no electrónicos (o que no utilizan la red) para ordenar mercancías serán patentados para que la competencia no pueda recibir órdenes efectivamente.

Desde abril de 2000, la oficina de patentes ha recibido más de 2,500 solicitudes de estas patentes de “software de métodos de negocios” al año. 52 Debido a que las patentes pueden ser usadas en forma defensiva, cada propietario de una página web ahora necesita investigar si algunos aspectos de su página son patentables o si violan patentes de otro sitios.

E. Los conflictos con la legislacion del copyright.

Las compañías como Lotus, Microsoft, WordPerfect y Novell alcanzaron su status de líderes mundiales en la industria de publicación de software sobre la base de la fuerza de sus productos sin depender de las patentes para asegurar su financiamiento o para mantener su posición en el mercado. 53

Para aquéllos que requieren proteger su propiedad intelectual, la industria se ha valido, por mucho tiempo, de los sistemas de copyright y del secreto insdustrial. El patentar software crea conflictos con la legislación existente sobre copyright.

Casi todos los programas, el día de hoy, están protegidos por el copyright, el cual impide que los usuarios hagan copias de un programa sin autorización. El copyright impide que uno se apropie del trabajo de otro y que lo venda como si fuera propio. Sin embargo, no impide que otros programadores utilicen algoritmos o técnicas en sus propios trabajos. 54

Una simple técnica puede ser usada de diferentes maneras para realizar distintas funciones y los programadores no estarían infringiendo, aún así, el copyright de otro.55 Al permitir la protección de patentes sobre la misma materia en cuestión, el alcance extendido de cobertura esencialmente desafía el sistema de protección del copyright ya que las compañías, eventualmente, decidirán patentar sus algoritmos.

El trato de la memoria leíble por una máquina que contiene un programa como un artículo de manufactura patentable, extiende en gran medida el rango de actividades que pueden infringir una patente y, en consecuencia, crea conflictos directos con la Ley de Copyright.56 Bajo la ley de patentes, el simple hecho de crear una copia de archivo, permitido en la Ley de Copyright § 117, puede constituir una “hechura” y por ende constituir una infracción a la patente.57

Igualmente, una copia de uso justo hecha a través de ingeniería inversa, que es legítima bajo la sección 107 de la ley de Copyright, puede también constituir una infracción a algún artículo de manufactura.58 El conflicto entre las leyes de patentes y las de copyright sólo existe en el ámbito de las patentes de software; en ningún otro lado.

F. Restriccion a la interoperabilidad

Las patentes en la industria del software también tienen el potencial de restringir la interoperabilidad. El propietario de una patente puede inhibir la interoperabilidad con los elementos de un programa que no cubre la patente.59 Un programador de computadoras que encuentra un algoritmo patentado intentará evitar la infracción de la patente por medio de escribir o encontrar otro algoritmo que no esté patentado.

Sin embrago, si el algoritmo patentado es utilizado en un formato común que no soporte el nuevo algoritmo no patentado, los usuarios no podrán utilizar la versión no patentada y este algoritmo básicamente se desperdicia.

Richard Stallman discutió su experiencia con el algoritmo de compresión LZW que también era utilizado en formatos de imagen como el formato GIF. Con el fin de evitarla infracción a la patente del LZW, el grupo de Stallman utilizó un algoritmo no patentado diferente. De cualquier modo, cuando los usuarios de GIF fueron amenazados con demandas de infracción de patente por utilizar archivos GIF, no pudieron cambiarse a la versión no patentada. Los browsers no soportaron el nuevo formato que estaba libre de patente. 60 Por tanto, el resultado de este algoritmo patentado es una restricción sobre a interoperabilidad del software.

VIII. Conclusion

Desde las tediosas y poco confiables búsquedas por la patentabilidad, hasta el peso financiero sobre las pequeñas compañías, el sistema de patentes tiene numerosas deficiencias. El software computacional, al ser un sistema complejo de ideas y de combinaciones de ideas, es particularmente sensible a los problemas de las patentes. La falta de comprensión de la Oficina de Patentes y Marcas de los EE.UU. sobre la industria del software contribuye, significativamente, a la poco satisfactoria calidad de las patentes que están siendo emitidas.

Otro factor que afecta específicamente a la patentación de software es el potencial de abuso; las compañías pueden burlar la prohibición- por estatuto- de la patentación de prácticas de negocios al implementarlas a programas computacionales. Las patentes de software no sólo debilitan el esquema de la ley de copyright, también restringen la interoperabilidad.

IX. Posibles soluciones

Por las razones expuestas, la USPTO necesita reformar su sistema de patentes de software. Deberían destinarse más recursos federales a la Oficina de Patentes y deberían reducirse los costos de la procuración de patentes. La Oficina de Patentes debería, también, aumentar sus esfuerzos para reclutar más científicos computacionales como examinadores e implementar una base de datos más fuerte y efectiva para búsquedas de patentabilidad de programas de software.

El Instituto de Patentes de Software (The Software Patent Institute) trabaja para ayudar a los programadores a identificar materiales patentados sobre creaciones previas. En cuanto a los conflictos con las leyes de copyright, los cuerpos legislativos deberían considerar la clarificación y expansión de doctrinas como el uso incorrecto de patentes, el uso experimental y el agotamiento. 61

Finalmente, uno puede impedir que otros patenten tecnología de software, sin el costo de obtener una patente, al publicar la tecnología del software. 62

El Instituto de Patentes de Software, una corporación sin fines de lucro formada para dar cursos y creaciones previas acerca de la tecnología del software, publica la información remitida en una base de datos accesible a la USPTO y al público en general. 63

Esta publicación servirá como una “revelación defensiva” e incrementará las posibilidades de que la Oficina de Patentes encuentre y considere esta información antes de otorgar una patente que puede, posteriormente, probarse inválida debido a que, realmente, no era nueva. Con los esfuerzos combinados de la Oficina de Patentes, la comunidad de programación computacional, y los ciudadanos involucrados, los problemas de patentar software pueden ser resueltos.

Notas: 1. Comentarios del American Committee For Interoperable Systems On the Proposed Examination Guidelines For Computer-implemented Inventions. American Committee for Interoperable Systems, Statement of August 18, 1995.

1. David R. Syrowik & Roland J. Cole, The Challenge of Software-Related Patents. Software Patent Institute, 1994. http://www.spi.org/primsrpa.htm
2. American Committee for Interoperable Systems, Statement of August 18, 1995.
3. Id.
4. John Hoagland, Web Patents: Owning a Piece of the Internet. Web Technology and Counseling Center. http://www.components-online.com/Software/Patents/default.htm
5. Id.
6. Id.
7. David R. Syrowik & Roland J. Cole, The Challenge of Software-Related Patents. Software Patent Institute. 1994. http://www.spi.org/primsrpa.htm
8. Id.
9. Syrowik & Cole, The Challenge of Software-Related Patents. 1994.
10. Id.
11. Against Software Patents. The League of Programming Freedom. Feb 28, 1991. http://lpf.ai.mit.edu/
12. Id.
13. Richard Stallman, Software Patents - Obstacles to Software Development. Transcript, University of Cambridge Computer Laboratory, UK. Mar 25, 2002.
14. Against Software Patents. The League of Programming Freedom. Feb 28, 1991.
15. Id.
16. Richard Stallman, Software Patents - Obstacles to Software Development. 2002.
17. Jonathan Rosenoer, Software Patents. Cyberlaw on the World Wide Web. 1994. http://www.cyberlaw.com/cylw894.html
18. Véase Richard Stallman, Software Patents - Obstacles to Software Development. 2002.
19. Véase Id.
20. D.C. Toedt III, Patent Law Frequently Asked Questions. Lawnotes: Intellectual-Property Law Facts and FAQs. http://www.lawnotes.com/patent/faq_pat.html
21. Id.
22. Id.
23. Id.
24. Id.
25. Id.
26. Simson L. Garfinkel, Richard M. Stallman & Mitchell Kapor. Why Patents are Bad for Software. Issues in Science and Technology. 1991.
27. Richard Stallman, Software Patents - Obstacles to Software Development. 2002.
28. Id.
29. Id.
30. Id.
31. Id.
32. Id.
33. Id.
34. Id.
35. Id.
36. Id.
37. Debunking Software Myths. Communications to the ACM, June, 1992. Http://www.swiss.ai.mit.edu/6805/articles/int-prop/heckel-debunking.html.
38. Véase Id.
39. Véase Id.
40. Against Software Patents. The League of Programming Freedom. Feb 28, 1991
41. Id.
42. Id.
43. Garfinkel, Stallman & Kapor. Why Patents are Bad for Software. 1991.
44. Id.
45. Against Software Patents. The League of Programming Freedom. Feb 28, 1991
46. Id.
47. Id.
48. Id.
49. John Hoagland, Web Patents: Owning a Piece of the Internet. Web Technology and Counseling Center. http://www.components-online.com/Software/Patents/default.htm
50. Id.
51. Seth Shulman, Software Patents Tangle the Web. April 2000. http://www.technologyreview.com/articles/shulman0300.asp
52. Garfinkel, Stallman & Kapor. Why Patents are Bad for Software. 1991.
53. Id.
54. Id.
55. Comments of the American Committee For Interoperable Systems On The Proposed Examination Guidelines For Computer-implemented Inventions. American Committee for Interoperable Systems, Statement of August 18, 1995.
56. Id.
57. Id.
58. Id.
59. Richard Stallman, Software Patents - Obstacles to Software Development. Transcript, University of Cambridge Computer Laboratory, UK. Mar 25, 2002.
60. American Committee for Interoperable Systems, Statement of August 18, 1995.
61. David R. Syrowik & Roland J. Cole, The Challenge of Software-Related Patents. Software Patent Institute. 1994. http://www.spi.org/primsrpa.htm
62. The Software Patent Institute. http://www.spi.org