[Comentario de un agente de patentes] Estrategia de patentes para negocios SaaS | Cómo convertir el procesamiento de las comunicaciones entre servidor y cliente en un derecho de pr

Hoy en día, cuando el principal campo de batalla empresarial lleva ya tiempo desplazándose del software empaquetado al SaaS (Software as a Service), muchas startups aspiran a expandir su negocio mediante el modelo de suscripción. Sin embargo, debido a las características técnicas del SaaS, es un hecho sorprendentemente poco conocido que «resulta muy difícil obtener patentes y es fácil fracasar».

«A pesar de haber desarrollado un algoritmo revolucionario, no pude demandar a la competencia por infracción de patente».

«Solo por trasladar el servidor al extranjero, los derechos de patente dejaron de ser válidos».

Para evitar situaciones como estas, se requiere una estrategia sofisticada que defina legalmente la relación entre el «servidor» y el «cliente», una arquitectura propia del SaaS.

En particular, la sentencia del Tribunal Supremo del caso Dwango contra FC2, dictada en marzo de 2025 (año 7 de la era Reiwa), supuso un punto de inflexión dramático en la práctica de las patentes de SaaS. Presentar una solicitud basándose en conocimientos obsoletos, sin conocer esta sentencia, es demasiado arriesgado.

En este artículo, desde la perspectiva de un agente de patentes especializado en el sector de las tecnologías de la información y el software, explicaré en profundidad los fundamentos de la estrategia de patentes en el negocio del SaaS, así como los conocimientos prácticos para «obtener derechos que se puedan defender» basados en la jurisprudencia más reciente.

1. ¿Por qué las patentes de SaaS son diferentes de las «patentes normales»?

Las patentes tradicionales del sector manufacturero (por ejemplo, las de «motores» o «sillas») se completaban con la existencia de un solo objeto. Sin embargo, las invenciones de «sistemas en red», entre las que se incluye el SaaS, solo funcionan cuando varios elementos físicamente separados interactúan entre sí.

El mayor problema aquí es la «barrera de los múltiples actores» en la ley de patentes.

El riesgo de que los sujetos infractores estén dispersos (principio de la aplicación de todos los requisitos constitutivos)

Para que se produzca una infracción de la patente, en principio es necesario que «un único sujeto (la empresa competidora)» cumpla «todos los requisitos descritos en las reivindicaciones (claims)».

¿Qué pasaría si, sin pensarlo dos veces, patentara todo el sistema como un «sistema de chat compuesto por un servidor y terminales de cliente»?

・Quien gestiona el servidor es «la empresa competidora (proveedor de SaaS)».

・Quien maneja los terminales de cliente es «el usuario general (cliente)».

En este caso, existe el riesgo de que la empresa competidora rebata diciendo: «Yo no manejo el terminal cliente (lo hace el usuario por su cuenta). Solo estoy ejecutando la mitad del sistema completo, por lo que no se trata de una infracción de patente», y que no se considere que existe infracción.

Para evitarlo, es imprescindible un «diseño de reivindicaciones» que separe adecuadamente la invención y aclare quién lleva a cabo qué.

2. Estrategia de «tres distinciones» en la comunicación entre servidor y cliente

Lo más importante en las patentes de SaaS es «desde qué perspectiva se segmenta la invención». Aunque se trate de la misma tecnología, al proteger los derechos de forma superpuesta en las tres categorías siguientes, se puede construir una red de patentes sólida y sin escapatorias.

Estrategia ①: Reivindicaciones del lado del servidor (el bastión más importante)

Se trata de derechos destinados a atacar directamente a los proveedores de SaaS (la competencia). Se describen limitando los componentes de la invención exclusivamente a los «procesos que realiza el servidor».

・Mal ejemplo (múltiples sujetos):

«Sistema en el que el usuario envía una solicitud desde su dispositivo, el servidor la recibe y la procesa, y muestra el resultado en el dispositivo del usuario».

(※ Se incluye la acción del usuario de «mostrar»).

・Ejemplo correcto (sujeto único):

«Dispositivo servidor que cuenta con una unidad receptora que recibe solicitudes desde el terminal, una unidad de control que realiza el procesamiento en base a dichas solicitudes y una unidad transmisora que envía los datos de visualización al terminal mencionado».

De este modo, si se unifica el sujeto en «servidor», independientemente de lo que haga el usuario, se podrá alegar infracción (producción, uso, etc.) en el momento en que la competencia ponga en funcionamiento dicho servidor. En las patentes SaaS, este es el derecho más básico y poderoso.

Estrategia ②: Reivindicaciones del lado del cliente (frente a las tiendas de aplicaciones)

Es eficaz cuando se trata de aplicaciones dedicadas o cuando el procesamiento de JavaScript en el navegador presenta características distintivas.

En este caso, se registran los derechos sobre el «programa» en sí.

Si se desea excluir a los competidores que distribuyen aplicaciones en Apple Store o Google Play, con una «patente de servidor» resulta difícil explicárselo a los operadores de las plataformas, lo que puede retrasar la respuesta de retirada. Sin embargo, si se dispone de una «patente de aplicación», se puede alegar de forma sencilla que la propia aplicación distribuida es un producto infractor, lo que permite que la solicitud de retirada de la tienda se tramite sin problemas.

Estrategia ③: Reivindicaciones de sistema (contra servidores extranjeros)

Las reivindicaciones sobre el «sistema completo (servidor + terminal)», que antes solían evitarse por el «riesgo de infracción por múltiples partes», están siendo reevaluadas en cuanto a su importancia gracias a la sentencia más reciente que se menciona a continuación.

Las reivindicaciones de sistema resultan especialmente eficaces cuando el servidor y el cliente colaboran estrechamente y la esencia de la invención reside precisamente en su interacción (protocolos o secuencias de comunicación).

3. La sentencia del Tribunal Supremo en el «caso Dwango» que cambió la historia (marzo de 2025)

La mayor preocupación durante muchos años en el sector del SaaS ha sido la cuestión de la «instalación de servidores en el extranjero (transfronteriza)».

Los derechos de patente en Japón se rigen por el «principio de territorialidad», por lo que solo tienen validez dentro del territorio japonés. Por ello, existía el temor de que se generalizara la «elusión de patentes», es decir, que se argumentara que «como la región de AWS está en Estados Unidos, los derechos de patente japoneses no son aplicables».

Lo que zanjó definitivamente esta cuestión fue la sentencia del Tribunal Supremo del «caso Dwango contra FC2», dictada el 3 de marzo de 2025.

Si se considera «sustancialmente en el territorio nacional», se produce una infracción

El Tribunal Supremo dictaminó que, aunque el servidor se encuentre en el extranjero, si tras considerar de forma global los siguientes elementos se puede evaluar que la creación del sistema «se ha llevado a cabo sustancialmente en el territorio nacional», se considera una infracción de los derechos de patente japoneses (producción).

1. Naturaleza de la cesión u otros actos: ¿Se presta el servicio a usuarios dentro de Japón? (p. ej., visualización en japonés, pago en yenes japoneses, etc.).

2. Lugar donde se producen los efectos: ¿Se manifiestan los efectos del uso de dicho sistema en el territorio nacional (pueden utilizarlo los usuarios nacionales)?

Gracias a esta sentencia histórica, los operadores de SaaS ya no pueden recurrir a la simple estrategia de «trasladar los servidores al extranjero» para eludir la ley.

Por el contrario, se ha confirmado a nivel del Tribunal Supremo que, si se obtiene una patente sólida en Japón, se puede solicitar el cese de la actividad y una indemnización por daños y perjuicios incluso contra servicios de imitación que utilicen servidores en el extranjero.

Desde esta sentencia, la estrategia de obtener deliberadamente la patente como «sistema que incluye servidores y terminales» y argumentar que «dado que incluye a usuarios (terminales) dentro de Japón, se trata de una aplicación en el país» se ha convertido en una opción extremadamente eficaz.

4. ¿Cómo se demuestra el «procesamiento interno invisible»?

Por muy buena que sea una patente, no tiene sentido si no se puede demostrar (si no se descubre) que los servicios de la competencia la están utilizando. A esto se le denomina «detectabilidad» (Detectability).

El procesamiento backend del SaaS (algoritmos de IA o lógica de cálculo de alta velocidad) es una caja negra. Desde el exterior no se puede ver qué tipo de cálculos se realizan dentro del servidor.

Por ello, cuando me encargo de las patentes de SaaS de una empresa cliente, siempre incluyo los siguientes puntos de vista.

Definir los derechos en función de la entrada y salida (E/S)

Las reivindicaciones se estructuran incluyendo la relación causal de «qué salida se obtiene ante una entrada específica», en lugar de centrarse únicamente en la lógica interna.

× Reivindicación basada únicamente en el procesamiento interno:

«Proceso que consiste en calcular coeficientes utilizando el algoritmo X sobre los datos A y almacenarlos en la memoria B».

(※ Como es totalmente invisible desde el exterior, no se pueden obtener pruebas de infracción)

○ Reivindicación centrada en la entrada y salida:

«Proceso que, en respuesta a la recepción de los datos A desde un terminal, genera los datos B que contienen parámetros específicos y los reenvía al terminal».

Si se redacta de esta manera, basta con consultar la API de la competencia y comprobar la respuesta (datos JSON, etc.) para poder presentar pruebas y afirmar: «Vea, se devuelve este parámetro. Se trata de una infracción de patente».

Una «patente sólida» no solo es técnicamente avanzada, sino que también es «una patente en la que es fácil detectar la infracción».

5. Hoja de ruta de propiedad intelectual para startups SaaS

En el negocio del SaaS, la velocidad lo es todo. Es necesario presentar la solicitud de patente en el momento adecuado, en función de la fase de desarrollo.

Fase 1: Desarrollo del MVP hasta justo antes del lanzamiento (antes del PMF)

Este es el momento decisivo.

Las patentes requieren «novedad». Aunque se trate de una versión beta, una vez que se haya hecho pública, en principio ya no se podrá obtener la patente (pérdida de novedad).

Asegúrese de completar la solicitud antes de publicar el «comunicado de prensa» o la «página de destino». En esta etapa, es más importante definir el concepto básico de «modelo de negocio × tecnología» que los detalles del código.

Fase 2: Etapa de crecimiento (Series A-B)

Es el periodo en el que aumenta el número de usuarios y se añaden nuevas funciones. Aquí se procede a registrar los derechos sobre la UI/UX concreta que constituye el «factor de diferenciación frente a otras empresas», así como la estructura de datos y las especificaciones de la API.

En particular, si se tiene en cuenta una futura salida a bolsa (OPV) o una fusión o adquisición (M&A), la cartera de patentes se convierte en un activo que eleva considerablemente el valor de la empresa (valoración). Esto se debe a que los inversores y las empresas adquirentes no solo pagan por la tecnología en sí, sino también por «el derecho a tener la exclusividad de dicha tecnología».

6. Resumen: la importancia de elegir un abogado especializado en SaaS

Las patentes en el negocio del SaaS se convertirán en derechos llenos de lagunas si no se comprenden en profundidad los tres elementos siguientes:

1. Tecnología de redes (HTTP, API, WebSocket, infraestructura en la nube)

2. Lógica jurídica más reciente (sentencia del Tribunal Supremo sobre Dwango, ejecución por múltiples sujetos, infracción indirecta)

3. Modelo de negocio (puntos de monetización, vías de entrada de la competencia)

No basta con «plasmar en un texto las especificaciones que nos han facilitado los ingenieros» para proteger una patente de SaaS.

Es imprescindible contar con el apoyo de expertos que puedan conversar en pie de igualdad con los ingenieros utilizando terminología técnica y que sean capaces de visualizar los procesos invisibles entre el servidor y el cliente en forma de «derechos».

En nuestro despacho ofrecemos asistencia en materia de patentes especializada en negocios SaaS y en la nube.

Si no sabe si su servicio puede patentarse o le preocupa que la competencia lo copie, le recomendamos que nos consulte lo antes posible, antes de que finalice el desarrollo.

La tecnología SaaS se convierte en un activo desde el momento en que se escribe el código. Nuestra labor consiste en convertir ese activo en un «derecho de exclusividad».

Etiquetas

#SaaS #EstrategiaDePatentes #PatentesDeSoftware #PatentesDeModelosDeNegocio #Startups #AbogadosDePatentes #SistemasServidorCliente #SentenciaDwango #Transfronterizo #API #UIUX #PruebaDeInfracción #EstrategiaDePropiedadIntelectual #ServiciosEnLaNube #SolicitudDePatentes #PatentesDeTI

Índice

1. 1. ¿Por qué las patentes de SaaS son diferentes de las «patentes normales»?
2. 2. Estrategia de «tres distinciones» en la comunicación entre servidor y cliente
3. 3. La sentencia del Tribunal Supremo en el «caso Dwango» que cambió la historia (marzo de 2025)
4. 4. ¿Cómo se prueba el «procesamiento interno invisible»?
5. 5. Hoja de ruta de propiedad intelectual para startups de SaaS
6. 6. Resumen: la importancia de elegir un agente de la propiedad industrial especializado en SaaS