Obter uma patente de software no USPTO (o escritório americano de patentes) hoje é mais fácil do que era um ano atrás graças à decisão do Federal Circuit no caso Berkheimer v. HP inc e também graças às novas diretrizes do USPTO no caso Berkheimer. Entretanto, obter uma patente de software hoje é mais difícil do que era há cinco anos atrás e muito mais difícil do que era dez anos atrás. As leis de patente relacionadas a softwares estiveram em constante mutação ao longo da última década.
Para aumentarmos as chances de concessão de uma patente de software, e obtermos uma patente que sobreviva a quaisquer tentativas de nulidade de terceiros após a sua concessão, é de suma importância que a descrição da invenção esteja o mais completa o possível no momento do depósito do primeiro pedido de patente relacionado à invenção. Isso significa que a descrição precisa identificar a invenção por inteiro desde o primeiro protocolo no USPTO. Isso também vale para os casos de pedido de patente provisório, já que, para estabelecer uma data de prioridade o pedido de patente provisório precisa descrever a invenção com detalhes suficientes para satisfazer o artigo 35 USC 112.
Tudo isso é muito fácil de falar, mas o que isso realmente significa? Nos últimos anos nós aprendemos com uma variedade de casos quais os tipos de informação o Federal Circuit irá olhar para se persuadir de que a invenção reivindicada era realmente inventiva e não é uma ideia abstrata ou – caso constitua uma ideia abstrata em seu cerne – tenha apetrechos suficientes ao seu redor para que ela seja considerada de fato uma invenção patenteável.
Casos emblemáticos envolvendo patentes de software nos EUA
Para identificarmos adequadamente e descrevermos uma invenção relacionada a um software (também chamadas de invenções implementadas por computadores) consideramos as lições dos seguintes casos. São estes os casos que você quer que o Federal Circuit cite ao analisar o seu pedido de patente, porque, se o fizerem, suas reivindicações provavelmente serão consideradas patenteáveis. Por esse motivo, os casos a seguir são considerados boas referências para o redator de patentes.
Para obtermos uma patente de software é importante descrevermos o sistema e o processo sob uma perspectiva tecnológica. Como o juiz Chen explica no caso DDRHoldings, para que as reivindicações de uma patente de software sejam consideradas patenteáveis elas não podem “apenas citar uma prática conhecida antes do advento da internet, tendo como inovação a nova possibilidade de utilização da internet para realização da mesma prática antiga”. Para serem consideradas patenteáveis, as reivindicações de software precisam ser “intrinsecamente relacionadas à área de tecnologia da computação e devem ser capazes de contornar um problema que especificamente surgiu na área da tecnologia da computação”. Para terem uma chance real de concessão, o método de computação precisa estar associado a uma tecnologia de computação específica. Em outras palavras, o método realmente precisa ser aplicado em um sistema concreto e tangível, dito sistema e processo sendo minuciosamente bem descritos no descritivo do pedido de patente.
1 – Em Enfish LLC v Microsoft Fed Cir 2016, o Federal Circuit explicou que a Suprema Corte Americana sugeria no caso Alice Corp. v. CLS Bank International que as reivindicações que melhoram o funcionamento de um computador podem não se enquadrar no campo das ideias abstratas. O Federak Circuit se baseou nessa importante ressalva, porque de acordo com o júri, as reivindicações em Enfish basicamente estavam relacionadas a melhorias no funcionamento de computadores. Isso fez com que o júri anonimamente concluísse que “as reivindicações em discussão naquela apelação não eram direcionadas a uma ideia abstrata conforme a definição de ideia abstrata no caso Alice. Pelo contrário, elas estavam limitadas em um melhoramento específico na forma que computadores operam, incorporados em um uma tabela auto referenciável.” Portanto, é muito importante descrever a invenção como uma melhoria, com pelo menos algum tempo gasto no descritivo do pedido de patente explicando exatamente o que a invenção provê de evolução em relação ao estado da técnica.
2 – Métodos implementados por computador são desenvolvidos através de mecanismos de regras, que estabelecem: quem, o que, onde, quando, porque e como. Esses mecanismos de regras são de suma importância, tanto para o programador quanto para o redator da patente. A presença desse mecanismo de regras no descritivo do pedido de patente e nas reivindicações, foi o que salvou a patente lip sinchronization no caso McRo v. Bandai Namco Games Am., 837 F.3d 1299 (Fed. Cir. 2016). Quando abordando alguma limitação específica nesses padrões, o Federal Circuit decidiu em MCRODID não citar o caso Enfish, LLC v. Microsoft Corp. mas apontou o que segue: “ As características específicas do mecanismo de regras permitem o melhoramento realizado pela invenção”. A juíza Reyna continuou: “Como o descritivo da patente confirma, o melhoramento reivindicado pela invenção permite computadores proverem uma reprodução realista e sincronizada de movimentação labial e reprodução de expressões faciais em avatares animados que anteriormente não era possível. ”
3 – Em Thales Visionix Inc. v. U.S., 850 F.3d 1343 (Fed. Cir. 2017), o Federal Circuit enfrentou uma invenção relacionada a um sistema inercial de rastreamento, utilizado para rastreamento da movimentação de um objeto em relação a um frame. A reivindicação provê um método que elimina muitas complicações inerentes às soluções anteriores para determinação de posição e orientação de um objeto que se move em uma plataforma, com vantagens diversas reveladas em relação a técnicas anteriores. O júri entendeu que “as reivindicações se relacionavam a uma técnica nova e útil para uso de sensores para rastrear um objeto sobre uma plataforma”. Enquanto esta invenção certamente se enquadra no tipo de inovação que pode ser patenteada, as reivindicações não foram bem redigidas. Com um júri diferente, certamente seria fácil a obtenção de um resultado negativo nesse caso. O que provavelmente salvou as reivindicações foi o fato de que o descritivo do documento explicou que os sensores inerciais não utilizam uma abordagem convencional no que diz respeito à medição de alterações inerciais relativas à terra, o que permitiu o júri a seguir os ensinamentos do caso Enfish, LLC v. Microsoft Corp. Ainda assim seria preferível que os redatores nesse caso tivessem redigido reivindicações que incorporassem inovações no quadro reivindicatório do documento.
4 – É possível fundamentar o texto das reivindicações no descritivo? Absolutamente Sim! A lei diz que você não pode fundamentar o descritivo com base no texto das reivindicações, então deve haver algum lugar em que isso é permitido. É permitido no que tange à definição e detalhamento de tecnologias. O propósito do descritivo é constituir um glossário às reivindicações e facilitar a sua compreensão. Não há melhor exemplo para essa afirmação do que o caso Finjan, Inc. v. Blue Coat Systems, 879 F.3d 1299 (Fed. Cir. 2018). À primeira vista as reivindicações são muito curtas – até mesmo incompreensíveis. Mas há termos repetidos utilizados nas reivindicações que são discutidos e definidos no descritivo. No descritivo é definido um revolucionário Scanner de vírus para computador que foi idealizado por Finjan. O Juiz Dyk, escrevendo para o júri, explicou que “o método da reivindicação 1 emprega um novo tipo de arquivo que permite sistemas de segurança do computador realizarem feitos que não podiam antes”. Isto é significativo porque o Juiz Dyk, até pouco tempo atrás, parecia relutante a concordar com o patenteamento de qualquer tipo de invenção relacionada à área de software. Portanto, a lição é simples: caso o seu cliente seja um pioneiro e a inovação seja importante, tenha a certeza de que o descritivo revele isso! Obviamente não é suficiente que você diga isso; é necessário que você explique a diferença tal como no caso Enfish, LLC v. Microsoft Corp.
5 – A interface Gráfica do usuário é susceptível à proteção por design patents [N.T. equivalente ao nosso “registro de desenho industrial”], mas elas também podem ser susceptíveis à proteção por utility patents [equivalente ao nosso “patente de invenção”]. Vide Core Wireless Licensing S.A.R.L. v. LG Electronics, 880 F.3d. 1356 (2018). As reivindicações definiam uma maneira específica de revelar um agrupamento de informações ao usuário, em vez de usar métodos de interface convencionais para revelar um índice genérico em um computador. Como os sistemas melhorados revelados em Enfish, Thales, Visual Memory e Finjan, estas reivindicações citam um melhoramento específico sobre sistemas do estado da técnica. O juiz Moore explicou que a velocidade de navegação do usuário através das várias vistas e janelas pode ser melhorada porque “ela poupa o usuário de ter de navegar até o aplicativo, abrir o aplicativo, e navegar dentro do aplicativo para alcançar os dados de interesse ou realizar determinada função de interesse”. Obviamente para que seja aplicado o mesmo raciocínio dado a esse caso, o descritivo deve descrever adequadamente a melhoria da referida função nos computadores.
6 – Se o valor de uma descrição completa de toda inovação provida por uma invenção não se mostrou relevante ainda, uma decisão recente do Federal Circuit em in Ancora Technologies, Inc. v. HTC America, Inc. (Fed. Cir. 2018) deve persuadi-lo da importância dessa conduta. Embasado no caso Enfish, o juiz Taranto, junto aos juízes Dyk e Wallach, entenderam que as reivindicações em discussão definiam uma “tarefa concreta para uma função específica em componentes de computadores para melhorar sua segurança”. A patente explica que a invenção reivindicada se embasa em uma característica única e específica, não utilizada previamente na forma ora reivindicada. O juiz Taranto explicou que a corte não tinha qualquer fundamento para anular a patente. Portanto, uma lição a ser tirada desse caso é sobre a importância de uma descrição completa e clara de uma invenção, incluindo aí uma descrição minuciosa de suas características inovadoras, enquanto é dada uma atenção especial ao não enquadramento em um indeferimento por falta de atividade inventiva.
Nota de o consultor em patentes: obter uma patente de software no Brasil é muito mais difícil do que obter uma patente de software nos EUA e isso vale para antes e depois do caso Alice. Há poucas exceções do que pode ser patenteado como software por aqui. Uma das jurisprudências mais consolidadas no brasil na área de patenteamento de software é no que tange ao software embarcado. Software embarcado é aquele que existe apenas como parte integrante de uma máquina física, como o software que determina a movimentação de um robô de solda; o software que controla a movimentação das superfícies de controle em um avião; o software empregado em uma máquina da tomografia computadorizada; esses softwares são patenteáveis enquanto parte integrante da máquina, i.e. “robô de solda + software novo” ou “máquina de tomografia + software novo”, por exemplo.
Gene Quinn
Artigo original em link
Tradução de oconsultorempatentes.com
