Patente de Mistral sobre “llamadas a herramientas implementadas en código”

Una patente estadounidense recién concedida a la empresa francesa de IA Mistral por “llamadas a herramientas implementadas en código” está generando críticas de desarrolladores que dicen que describe un patrón básico y de larga data de LLMs que generan y ejecutan código o llamadas a herramientas estilo RPC. Los comentaristas señalan abundante arte previo de proyectos de código abierto, trabajo académico como CodeAct y plataformas comerciales, y argumentan que estas patentes de software tan amplias sirven principalmente como armas legales o fichas de negociación más que para proteger una innovación genuina. Algunos ven esto como otro ejemplo de un sistema de patentes roto, especialmente en software, mientras que otros señalan que las empresas acumulan estas patentes de forma defensiva para licencias cruzadas y disuasión, incluso cuando la aplicación contra grandes actores es poco probable.

Alcance y naturaleza de la patente

  • La patente es para “llamadas a herramientas implementadas en código” por un LLM, presentada en marzo de 2026 y ya concedida en EE. UU. (vía acelerada).
  • La reivindicación de alto nivel parece abarcar que los LLM generen y ejecuten código que realiza llamadas a herramientas, con mensajería tipo JSON/XML y comportamiento estilo RPC.
  • Las reivindicaciones dependientes enfatizan un “sandbox reanudable sin estado” que ejecuta código generado hasta operaciones no deterministas (tiempo, aleatoriedad, E/S), y luego reejecuta el código con resultados en caché.

Novedad y arte previo

  • Muchos sostienen que esto es, esencialmente, RPC/IPC o un “await” asíncrono a través de una red, un patrón bien conocido en ingeniería de software.
  • Se citan múltiples ejemplos de arte previo: Cloudflare Code Mode/MCP, Microsoft CodeAct y el artículo relacionado, “programmatic tool calling” de Anthropic/OpenAI, smolagents, proyectos de GitHub y sistemas personales anteriores a la presentación.
  • Algunos señalan flujos de trabajo estrechamente relacionados en los que excepciones o funciones indefinidas activan la generación de código por parte del LLM.
  • Otros admiten que combinar código escrito por el propio LLM con llamadas a herramientas podría ser “nuevo” en sentido legal, pero probablemente obvio para los practicantes.

Críticas a las patentes de software y a la USPTO

  • Hay un fuerte sentimiento de que la mayoría de las patentes de software, incluida esta, son triviales, excesivamente amplias y básicamente “basura de patentes”.
  • Varios comentarios describen la oficina de patentes de EE. UU. como impulsada por formularios y tasas, dejando la validez en manos de los tribunales; se reconocen las denegaciones no finales, pero se consideran un filtro insuficiente.
  • Las patentes con arte previo a menudo aun así se conceden y se usan porque es más barato llegar a un acuerdo que litigar.

Motivos y uso estratégico

  • Algunos ven esto como una medida defensiva: construir una cartera para hacer licencias cruzadas y disuadir a trolls o a actores estadounidenses más grandes.
  • Otros creen que es ofensiva: un posible garrote contra startups más pequeñas y proyectos de pesos abiertos que difícilmente puedan costear impugnaciones.
  • Preocupa que esas patentes puedan venderse más tarde a trolls de patentes.

Jurisdicción, ángulo de la UE y problemas más amplios del sistema

  • Se repite que estas patentes de software probablemente no serían patentables o serían mucho más difíciles de hacer valer en Europa, aunque se mencionan resquicios mediante “software + hardware genérico”.
  • Se cita como precedente el caso de las patentes MP3 para entidades europeas que monetizan patentes de software de EE. UU.
  • Hay un debate más amplio sobre si las patentes sirven principalmente a grandes incumbentes, frenan la innovación y deberían reemplazarse o restringirse, especialmente en software.