Atualmente, há muito tempo que o principal campo de batalha dos negócios mudou do software empacotado para o SaaS (Software as a Service), e muitas startups buscam expandir seus negócios por meio do modelo de assinatura. No entanto, devido às suas características técnicas, o SaaS é surpreendentemente pouco conhecido por ser “muito difícil de patentear e propenso a falhas”.
“Desenvolvemos um algoritmo revolucionário, mas não conseguimos processar a concorrência por violação de patente”
“Bastou transferir o servidor para o exterior para que a patente deixasse de ter validade”
Para evitar tais situações, é necessária uma estratégia sofisticada que defina legalmente a relação entre “servidor” e “cliente”, uma arquitetura específica do SaaS.
Em especial, com a decisão da Suprema Corte no caso Dwango contra FC2, em março de 2025 (Reiwa 7), a prática de patentes em SaaS atingiu um ponto de inflexão dramático. É extremamente arriscado apresentar um pedido de patente com base em conhecimentos desatualizados, sem ter conhecimento dessa decisão.
Neste artigo, a partir da perspectiva de um advogado especializado em TI e software, explicaremos detalhadamente o cerne da estratégia de patentes no negócio de SaaS, bem como o know-how para obter “direitos que garantam a vitória”, com base nos casos judiciais mais recentes.
As patentes tradicionais da indústria de manufatura (por exemplo, “motor” ou “cadeira”) eram completas desde que um único objeto existisse. No entanto, as invenções de “sistemas em rede”, incluindo o SaaS, só funcionam quando vários elementos fisicamente distantes interagem entre si.
O maior problema aqui é a “barreira dos múltiplos atores” prevista na Lei de Patentes.
Para que haja violação de patente, é necessário, em princípio, que “um único sujeito (concorrente)” esteja implementando “todos os requisitos descritos na reivindicação da patente”.
O que aconteceria se você, sem pensar duas vezes, patenteasse todo o sistema como um “sistema de chat composto por servidor e terminal cliente”?
・Quem gerencia o servidor é um “concorrente (fornecedor de SaaS)”.
・Quem opera o terminal cliente é o “usuário comum (cliente)”.
Nesse caso, a empresa concorrente pode argumentar: “Eu não estou operando o terminal cliente (o usuário está fazendo isso por conta própria). Como estou implementando apenas metade do sistema como um todo, não se trata de violação de patente”, e há o risco de que a violação não seja reconhecida.
Para evitar isso, é essencial uma “elaboração de reivindicações” que separe adequadamente a invenção e deixe claro quem está implementando o quê.
O mais importante nas patentes de SaaS é “de que perspectiva se destaca a invenção”. Mesmo que se trate da mesma tecnologia, é possível construir uma rede de patentes poderosa e sem brechas ao proteger os direitos de forma em camadas nas três categorias a seguir.
Trata-se do direito para atacar diretamente os fornecedores de SaaS (concorrentes). Descreve-se os componentes da invenção limitando-os exclusivamente ao “processamento realizado pelo servidor”.
・Exemplo inadequado (múltiplos sujeitos):
“Sistema no qual o usuário envia uma solicitação a partir do terminal, o servidor a recebe e processa, e exibe o resultado no terminal do usuário.”
(※ Inclui a ação do usuário de “exibir”)
・Exemplo positivo (entidade única):
“Dispositivo servidor que possui uma unidade receptora para receber solicitações do terminal, uma unidade de controle para realizar o processamento com base na referida solicitação e uma unidade transmissora para enviar dados de exibição ao referido terminal.”
Desta forma, ao unificar o sujeito como “servidor”, independentemente do que o usuário esteja fazendo, é possível questionar a violação (produção, uso etc.) no momento em que um concorrente colocar esse servidor em operação. Em patentes de SaaS, este é o direito mais básico e poderoso.
É eficaz quando há características específicas no processamento de aplicativos dedicados ou de JavaScript que opera no navegador.
Aqui, o próprio “programa” é objeto da patente.
Se você deseja excluir concorrentes que distribuem aplicativos na Apple Store ou no Google Play, apenas a “patente de servidor” torna difícil a explicação para as plataformas, o que pode atrasar a remoção. No entanto, se você possuir uma “patente de aplicativo”, poderá alegar de forma simples que o próprio aplicativo distribuído é um produto infrator, o que facilita o processo de solicitação de remoção (take-down) da loja.
Embora as reivindicações relativas ao “sistema como um todo (servidor + terminal)” costumassem ser evitadas devido ao “risco de violação por múltiplos sujeitos”, sua importância está sendo reavaliada devido a uma decisão judicial recente, que será discutida mais adiante.
Em particular, as reivindicações de sistema são extremamente eficazes quando o servidor e o cliente estão em estreita cooperação e a essência da invenção reside justamente nessa interação (protocolos e sequências de comunicação).
A questão da “instalação de servidores no exterior (transfronteiriça)” tem sido a maior preocupação no setor de SaaS há muitos anos.
Os direitos de patente no Japão seguem o “princípio da territorialidade”, ou seja, só têm validade dentro do território japonês. Por isso, havia o risco de que a “evasão de patentes” — com o argumento de que “como a região da AWS está nos Estados Unidos, os direitos de patente japoneses não se aplicam” — se tornasse uma prática comum.
O que resolveu completamente essa questão foi a decisão da Suprema Corte no “Caso Dwango vs. FC2”, proferida em 3 de março de 2025.
O Supremo Tribunal decidiu que, mesmo que o servidor esteja no exterior, se, após uma análise abrangente dos elementos a seguir, for possível avaliar que a criação do sistema “ocorreu substancialmente no território japonês”, tal ato constitui violação (produção) de direitos de patente no Japão.
Modalidade da ação de cessão, etc.: o serviço é prestado a usuários no território japonês (exibição em japonês, pagamento em ienes, etc.)?
Local onde o efeito se manifesta: se o efeito decorrente da utilização do sistema se manifesta no território japonês (se os usuários no Japão podem utilizá-lo).
Com essa decisão inovadora, a simples estratégia de “transferir o servidor para o exterior” deixou de ser válida para as empresas de SaaS.
Por outro lado, ficou estabelecido no nível da Suprema Corte que, se a patente for devidamente registrada no Japão, é possível solicitar a proibição e indenização por danos mesmo contra serviços de imitação que utilizam servidores no exterior.
Desde essa decisão, a estratégia de obter a patente especificamente como “sistema que inclui servidor e terminal” e argumentar que “como inclui usuários (terminais) no Japão, trata-se de uma implementação no país” tornou-se uma opção extremamente eficaz.
Por mais excelente que seja a patente obtida, ela não terá sentido se não for possível provar (ou se não for descoberto) que os serviços dos concorrentes estão utilizando essa patente. Isso é chamado de “detectabilidade” (Detectability).
O processamento de back-end do SaaS (algoritmos de IA e lógica de cálculo de alta velocidade) é uma caixa preta. Não é possível ver, de fora, que tipo de cálculo está sendo realizado dentro do servidor.
Por isso, quando sou responsável pelas patentes de SaaS de uma empresa cliente, sempre incluo os seguintes pontos de vista.
A reivindicação é constituída incluindo a relação de causalidade de “que tipo de saída é retornada para uma entrada específica”, e não apenas a lógica interna em si.
× Reivindicação apenas do processamento interno:
“Processo que, para os dados A, realiza o cálculo de coeficientes utilizando o algoritmo X e os armazena na memória B.”
(※Como isso é absolutamente invisível do exterior, não é possível obter provas de violação)
○ Reivindicação com foco na entrada e saída:
“Processo que, em resposta ao recebimento dos dados A do terminal, gera os dados B contendo parâmetros específicos e os reenvia ao terminal.”
Se for redigida dessa forma, basta acessar a API de um concorrente e verificar a resposta (dados JSON, etc.) para apresentar a prova, dizendo: “Veja, este parâmetro está sendo retornado. Trata-se de violação de patente”.
Uma “patente forte” não é apenas tecnicamente avançada, mas também uma “patente cuja violação é fácil de detectar”.
No negócio de SaaS, a velocidade é fundamental. É necessário realizar o pedido de patente no momento adequado, de acordo com a fase de desenvolvimento.
Este é o momento decisivo.
As patentes exigem “novidade”. Mesmo que seja uma versão beta, uma vez que o produto seja divulgado ao público, em princípio não será mais possível obter a patente (perda de novidade).
Certifique-se de concluir o pedido antes de qualquer “comunicado à imprensa” ou “lançamento da página de destino”. Nesta fase, concentre-se nos conceitos básicos de “modelo de negócios × tecnologia”, em vez de detalhes de código.
É o período em que o número de usuários aumenta e novas funcionalidades são adicionadas. Aqui, avançamos na proteção de direitos sobre UI/UX específicos que constituem “fatores de diferenciação em relação a outras empresas”, bem como sobre estruturas de dados e especificações de API.
Especialmente quando se tem em vista uma futura IPO (abertura de capital) ou fusão e aquisição (M&A), o portfólio de patentes se torna um ativo que eleva significativamente o valor de avaliação da empresa. Isso porque investidores e empresas adquirentes pagam não apenas pela tecnologia em si, mas também pelo “direito de exclusividade sobre essa tecnologia”.
As patentes no negócio de SaaS podem acabar com lacunas se não houver uma compreensão profunda dos três elementos a seguir.
Tecnologia de rede (HTTP, API, WebSocket, infraestrutura em nuvem)
Lógica jurídica atual (decisão da Suprema Corte no caso Dwango, implementação por múltiplos sujeitos, violação indireta)
Modelo de negócios (pontos de monetização, vias de entrada da concorrência)
Simplesmente “transcrever as especificações ouvidas dos engenheiros” não é suficiente para proteger uma patente de SaaS.
É essencial contar com o apoio de especialistas capazes de dialogar com os engenheiros em pé de igualdade, utilizando terminologia técnica, e de visualizar os processos invisíveis entre servidor e cliente na forma de “direitos”.
Nosso escritório oferece suporte especializado em patentes para negócios de SaaS/nuvem.
Se você está em dúvida se “o serviço da sua empresa pode ser patenteado” ou se “tem receio de que a concorrência o copie”, consulte-nos o mais rápido possível, antes que o desenvolvimento seja concluído.
A tecnologia SaaS se torna um ativo a partir do momento em que o código é escrito. Nosso trabalho é transformar esse ativo em “direito de exclusividade”.
#SaaS #Estratégia de Patentes #Patentes de Software #Patentes de Modelo de Negócio #Startup #Advogado de Patentes #Sistema Servidor-Cliente #Decisão Dwango #Transfronteiriço #API #UIUX #Prova de Violação #Estratégia de Propriedade Intelectual #Serviços em Nuvem #Pedido de Patente #Patentes de TI
Índice
AUTOR / Redator
Takefumi Sugiura
Representante e advogado especializado em propriedade intelectual do escritório EVORIX
Presta assessoria a clientes de diversos setores, como TI, manufatura, startups, moda e medicina, desde o depósito de pedidos de patentes, marcas, desenhos e direitos autorais até processos de julgamento e ações por violação. Possui profundo conhecimento em estratégias de propriedade intelectual em áreas de ponta, como IA, IoT, Web3 e FinTech. Membro de várias associações, incluindo a Ordem dos Advogados de Propriedade Intelectual do Japão, a Associação Asiática de Advogados de Propriedade Intelectual (APAA) e a Associação Japonesa de Marcas (JTA).