Respuesta corta
Sí, el software puede ser patentable, pero el camino hacia una patente de software otorgada puede ser largo, frustrante y costoso. Si bien la siguiente es una versión abreviada de una respuesta más detallada sobre la elegibilidad de las reclamaciones de software, prepárese para la respuesta larga.
¿Qué hace que el software sea patentable?
- ¿Cómo presentar una solicitud de patente para un producto físico en India? ¿Cuál sería su costo?
- Cómo encontrar un buen abogado de patentes con cargos razonables en India
- La licencia obligatoria de patentes no existió hasta después de la Segunda Guerra Mundial (si alguna vez). ¿Cómo funcionaba el sistema de patentes sin él?
- ¿Qué importancia debería tener un primer ministro que no sea de software en la estrategia de patentes?
- ¿Qué puedo hacer si le cuento una idea a un amigo y él la patenta antes que yo?
Al igual que cualquier otro tipo de invención, el software debe ser novedoso y no obvio. El obstáculo adicional que deben superar las invenciones de software es el requisito de elegibilidad de patente. Una invención de software debe tener un tema elegible para ser patentable.
¿Qué es elegible para patente?
Elegible no es lo mismo que nuevo. Sin embargo, una invención más única puede aumentar la elegibilidad de la materia buscada para la protección de patente.
Comenzamos con una pregunta fundamental: ¿el reclamo está dirigido a un proceso, máquina, fabricación de composición de materia?
Si no, entonces el tema no es elegible para patente.
Dado que la respuesta a la pregunta fundamental es afirmativa para casi todas las invenciones de software, pasamos a una línea de preguntas de dos pasos establecida en el caso de Alice Corp. v. CLS Bank Int’l de la Corte Suprema de EE. UU . :
- ¿El reclamo está dirigido a una ley de la naturaleza, un fenómeno natural o una idea abstracta ?
- Si es así: ¿el reclamo recita elementos adicionales que equivalen a mucho más que una idea abstracta ?
Las invenciones de software no están dirigidas a leyes de la naturaleza o fenómenos naturales, por lo que la cuestión clave en el primer paso de este análisis de la Sección 101 es si el software constituye una idea abstracta. Si el reclamo no está dirigido a una idea abstracta, su software es elegible para patente y se puede omitir el segundo paso. Si el reclamo se dirige a una idea abstracta, debe mostrar elementos adicionales que hacen que el software sea más que una idea abstracta.
¿Qué tipos de software e invenciones informáticas no son ideas abstractas?
Enfish, LLC v. Microsoft Corporation es un caso posterior a Alice del Tribunal de Apelaciones del Circuito Federal que proporciona orientación sobre cómo una invención de computadora podría no ser una idea abstracta en primer lugar. Un factor considerado por el Tribunal fue si el reclamo cubría “una mejora en la funcionalidad de la computadora en sí misma, no en tareas económicas o de otro tipo para las cuales se usa una computadora en su capacidad ordinaria”. En Enfish, el Tribunal determinó que la invención patentada estaba “dirigida a una mejora específica en el funcionamiento de las computadoras …”.
La importancia de Enfish es que una invención no es inherentemente abstracta simplemente porque consiste en software.
¿Qué es significativamente más que una idea abstracta?
Si un examinador considera que su reclamo de software está dirigido a una idea abstracta, entonces querrá mostrar cómo el reclamo recita elementos adicionales que equivalen a mucho más que una idea abstracta. Pero, ¿qué es significativamente más?
BASCOM Global Internet Services, Inc. v. ATT Mobility, LLC arroja luz sobre este segundo paso al afirmar que se puede encontrar un “concepto inventivo en la disposición no convencional y no genérica de piezas convencionales conocidas”. La invención en la patente BASCOM se relaciona con un sistema individualmente personalizable para filtrar contenido de Internet en una ubicación de red particular. “Significativamente más” en ese caso significaba una disposición única de componentes conocidos.
Ejemplos de USPTO de invenciones de software elegibles
La USPTO ha publicado ejemplos de elegibilidad para el tema que incluye el caso BASCOM y una invención hipotética para una “autenticación de dos factores para transacciones en cajeros automáticos”.
En el hipotético ATM, la USPTO proporcionó reclamos representativos para ayudar a ilustrar los elementos adicionales que equivaldrían a algo más que una idea abstracta (tenga en cuenta que el USPTO considera cada reclamo como dirigido a una idea abstracta):
Reclamo 1
Un método para realizar una transacción segura de cajero automático con una institución financiera mediante la autenticación de la identidad de un cliente, que comprende los pasos de:
obtener información específica del cliente de una tarjeta bancaria,
comparar, por un procesador, la información específica del cliente obtenida con la información del cliente de la institución financiera para verificar la identidad del cliente, y
determinar si la transacción debe continuar cuando una coincidencia de la comparación verifica la autenticidad de la identidad del cliente.
Resultado: el reclamo 1 no es elegible .
Dado que el reclamo se dirige a un método de prevención de fraude en ATM mediante la autenticación de la identidad de un cliente, cubre una idea abstracta. Luego, la USPTO examinó las limitaciones adicionales, o elementos, en la Reclamación 1 individualmente y en combinación. Individualmente, cada elemento adicional representaba una acción convencional, como obtener información específica del cliente y comparar mediante el uso de un procesador genérico. Tomados individualmente, los elementos adicionales de la reivindicación 1 no pudieron proporcionar significativamente más.
En combinación, los elementos adicionales no lograron llegar a algo más porque la combinación “no es más que la suma de sus partes, y no proporciona nada más que la mera automatización de los pasos de verificación que los cajeros realizaban mentalmente en años pasados cuando se relacionaban con un banco cliente.”
Reclamación 2
Un método para realizar una transacción segura de cajero automático con una institución financiera mediante la autenticación de la identidad de un cliente, que comprende los pasos de:
obtener información específica del cliente de una tarjeta bancaria,
comparar, por un procesador, la información específica del cliente obtenida con la información del cliente de la institución financiera para verificar la identidad del cliente, por
generar un código aleatorio y transmitirlo a un dispositivo de comunicación móvil que esté registrado para el cliente asociado con la tarjeta bancaria,
lectura, por el cajero automático, de una imagen del dispositivo de comunicación móvil del cliente que se genera en respuesta a la recepción del código aleatorio, en el que la imagen incluye datos de código cifrado,
descifrar los datos del código de la imagen leída, y
analizar los datos del código descifrado de la imagen leída y el código generado para determinar si los datos del código descifrado de la imagen leída coinciden con los datos del código generado, y
determinar si la transacción debe continuar cuando una coincidencia del análisis verifica la autenticidad de la identidad del cliente.
Resultado: el reclamo 2 es elegible .
Similar a la reivindicación 1, la reivindicación 2 también se dirige a una idea abstracta. Tomado individualmente, la USPTO no considera que los elementos adicionales de la reivindicación 2 agreguen significativamente más.
Sin embargo, en su conjunto, la combinación de los elementos “opera de una manera no convencional y no genérica para garantizar que la identidad del cliente se verifique de manera segura que es más que el proceso de verificación convencional empleado solo por un cajero automático”. La USPTO cree que la combinación de los pasos mencionados en la reivindicación 2 “presenta una implementación específica y discreta de una idea abstracta” y que los elementos adicionales en la reivindicación 2 “son una implementación práctica de la idea abstracta de prevención de fraude que realiza la verificación de identidad en un de manera no convencional y no genérica, a pesar de que los pasos usan componentes bien conocidos … ”
Cómo presentar una solicitud de patente de software
Tenga en cuenta que los ejemplos anteriores de USPTO se refieren solo a la elegibilidad. La patentabilidad de tales reivindicaciones también dependerá de cuán nuevas sean a la vista de la técnica anterior. La conclusión de estos ejemplos de elegibilidad es redactar reclamos que, si es posible, cubran una mejora de la funcionalidad de modo que el reclamo no se dirija a una idea abstracta en primer lugar.
La reclamación también debe redactarse anticipando que un examinador de patentes los considerará como una idea abstracta. En particular, las reivindicaciones deben recitar pasos que, cuando se ven en combinación, operan de una manera no convencional y no genérica. Se puede conocer cada componente, pero la disposición se debe recitar de una manera tan única que supere ese umbral evasivo de “significativamente más”.
