Mark Lemley
aponta que o que tem se verificado após a decisão em Bilski é que
tanto o USPTO como o Federal Circuit tem
se apoiado cada vez mais no machine or transformation test. Para
Mark Lemley o que estas decisões após Bilski
apontam é uma preocupação em não se conceder patentes para conceitos muito
amplos de modo que as Cortes tem recorrido ao enquadramento como ideias
abstratas para se atingir tal objetivo. Para Mark Lemley
discorda desta abordagem uma vez que nenhuma classe de invenções pode ser
considerada inerentemente tão abstrata que não possa ser patenteada. Bastaria
que as Cortes reduzissem o escopo das patentes a um conjunto de implementações
práticas específico, isto eliminaria o artificialismo em se delimitar uma
fronteira entre aquilo que é objeto de patente e o que não é, focando-se a
análise no que realmente importa: se a patente tal como reivindicada pode ser
avaliada como uma invenção prática, uma contribuição realizada junto ao mundo
real.[1] O
artigo de Mark Lemley foi citado na decisão da
Suprema Corte de 2012 de Mayo v.
Prometheus.
Mark Lemley destaca que o problema real com as ditas “patentes de software”
reside no fato de serem descritas em termos funcionais o que confere muitas
vezes um escopo excessivamente amplo para a patente.[2] O autor sugere que embora possam ser reivindicadas em termos de sua
funcionalidade, seu escopo deve ser limitado a implementação do algoritmo usado
para se alcançar tais funcionalidades, ou seja, seria necessário o pedido de
patente descrever as funcionalidades alcançadas em um nível menor de abstração,
ainda que sem a necessidade de apresentar o código fonte específico
efetivamente empregado. Para Mark Lemley com a decisão da Suprema Corte em Alice em junho 2014 reforça-se o
entendimento cada vez mais de que a questão não se trata entre escolher uma
reivindicação ampla descrita em termos funcionais ou seu enquadramento na seão 112(f) em que a forma means plus function é interpretada de
forma restritiva limitada à implementação no relatório descritivo mas entre o
enquadramento na seção 112(f) ou a não concessão da patente por ser ideia
abstrata por contrariar o artigo 101, ou seja, todas as implementações
funcionais que não incidem na 112(f) deveriam ser enquadradas como ideias
abstratas.[3]
Para Mark
Lemley as reivindicações que citem elementos triviais de hardware como
computador, memória, internet, monitor são reivindicações funcionais e não
reivindicações definidas de forma estrutural. No entanto, não parece haver
diferença significativa entre uma reivindicação da forma de “meios para calcular” tendo citado um
computador de uso geral no relatório descritivo com sendo tal meio, ou ao invés
disto ter escrito diretamente na reivindicação “computador para calcular”. O que Mark Lemley não considera é que,
embora de fato apenas o primeiro caso incida diretamente na seção 112(f) a
aplicação da doutrina de equivalentes nos dois casos é idêntica, para todos os
efeitos.
Para Mark
Lemley a presença de uma limitação nominal de hardware serve apenas para
ocultar o fato de que os meios efetivos para realizar as funções pleiteadas, o
programa de computador em si, não está descrito no pedido de patente. Desta
forma, as atuais patentes de software retornaram ao objetivo original das
reivindicações funcionais dos anos 1940, indevidamente amplas, na medida em que
não especificam os meios de implementação (relativo ao software) para
realização da invenção. A presença de termos como “computador”, “internet”,
“processador” satisfaz a exigência das Cortes de implementação dos ditos meios,
a ponto de não invocar a seção 112(f), quando para Mark Lemley o problema está
na indefinição quanto ao código de programa de computador usado para
implementar tais funções. Tais reivindicações deveriam continuar enquadradas na
seção 112(f) e ter seu escopo restrito as implementações de código de programa
de computador utilizadas. Algumas decisões apontam neste sentido. Em Ex parte Rodriguez[4]
o BPAI considerou como meios mais funções a referência a “sistema de
configuração de um gerador para gerar” e “construtor para construir”, “ambiente
de simulação para verificar” uma vez que estes termos, “gerador”, “construtor”,
“simular” não trazem qualquer elemento estrutural adicional as funções
descritas. Mark Lemley aponta que resta saber se o Federal Circuit irá seguir
este entendimento. Em Chi bd. Options Exch v. Intl Sec. Exch[5]
o Federal Circuit considerou como uma reivindicação do tipo meios mais funções
uma reivindicação que fazia referência a meios de memória, em que o relatório
descritivo descrevia tal meio como sendo um sistema de memória, o que pouco
acrescentava à definição estrutural de tal meio.
A solução para Mark Lemley seria aplicar de forma mais rígida as exigências
da seção 112(f) e exigir a apresentação do algoritmo usado na implementação das
funções descritas na reivindicação restringindo o escopo da patente a
implementações equivalentes das mesmas. A aplicação da doutrina de equivalentes
nestes casos, para reivindicações de meios mais funções enquadradas na seção
112(f) tende a ser mais restrita, por exemplo, não contemplando tecnologias
desenvolvidas após a concessão da patente, conforme o entendimento do Federal
Circuit em Al-Site Corp. v. VSI Int[6].
Considerando a evolução da tecnologia de software isto pode representar uma
restrição significativa as patentes de software. Para o caso de
reivindicações funcionais do tipo meios mais funções Janice Mueller aponta que
tais reivindicações tem o escopo de proteger qualquer meio que realize a mesma
função desde que sejam meios conhecidos à época da concessão da patente. Janice
Mueller cita o caso Al-Site Corp. v. VSI Int. em que a Corte entendeu que uma
estrutura equivalente ou etapa de um processo constitui infração literal se
tivesse sido disponibilizada na data de concessão da patente. Segundo a autora:
“esta regra parece correta do ponto de
vista de se preservar a precisão das reivindicações tal como definida no 35 USC
§ 112 parágrafo 2. È difícil imaginar como uma reivindicação que
literalmente abrange uma dada tecnologia ainda não existente poderia satisfazer
a exigência legal estatutária para reivindicações que particularmente
distinguem e reivindicam algo que o depositante considera como sua invenção”.[7]
Embora Mark Lemley
observe que não defende a apresentação do código fonte usado para implementação
das funções pleiteadas na reivindicação, o autor defende um nível mais alto de abstração do que o
código em si mas não tão amplo a ponto de significar meramente as funções
essenciais executadas. A solução proposta é um meio termo entre o código em si
a mera apresentação funcional desejada, embora o próprio Mark Lemley reconheça
que o nível exato de abstração seja difícil de ser submetido a uma regra geral.
De qualquer forma a proposta caminha no sentido de maior aproximação com o
código fonte o que cria dificuldades operacionais adicionais aos escritórios de
patentes que não dispõe de um banco de dados com estas informações. Ademais se
a comparação entre dois códigos não poderá ser feitas em termos das
funcionalidades alcançadas, visto que ambos apresentam funções e efeitos
técnicos similares, a aferição de atividade inventiva torna-se ainda mais
subjetiva.
O próprio
Federal Circuit tem consolidado argumentação de que a implementação de uma
funcionalidade em código fonte não é passível de proteção, pois está ao alcance
de um programador habilitado: Em Northern Telecom, Inc. v. Datapoint Corp. a
Corte entendeu que seria “relativamente
direto à luz do relatório descritivo para um programador habilitado escrever um
programa para implementar a invenção reivindicada [...] linguagem de computador
não se trata de uma conjuração de alguma arte de magia negra, é simplesmente
uma linguagem altamente estruturada [...] a conversão de um pensamento completo
(tal como expresso em inglês ou em linguagem matemática, isto é, dado as
entradas conhecidas, a saída desejada, as expressões matemáticas necessárias e
os métodos para utilizar estas expressões) em uma linguagem que uma máquina
possa entender é necessariamente uma função meramente trivial (clerical) para
um programador habilitado”.[8]
Em linguagens visuais e orientadas a objeto
o usuário não tem acesso a todo o código fonte, mas apenas de trechos dele.
Analogamente à eletrônica que não exige os valores de componentes para
descrição dos esquemáticos, mas apenas diagramas de blocos de trechos críticos
da invenção, da mesma forma as invenções relativas a programas de computador
devem ser descritas desta forma. Como a proteção da patente não diz respeito a
uma implementação de código fonte específica, mas ao conceito inventivo e à
funcionalidade descrita por aquele programa, não faria, sentido a exigência de
apresentação de código fonte. Ademais a apresentação de códigos fontes extensos,
não significa necessariamente maior clareza à
invenção, pois somente se tais códigos forem escritos de forma adequada, com
comentários, e estruturalmente organizados, poderão ser úteis para
interpretação. Ademais tais listagens, que podem envolver milhares de linhas de
código, dificilmente poderiam ser analisadas em tempo hábil pelo examinador de
patentes ou checar seu funcionamento.
A proposta de Mark Lemley desloca a análise
das patentes de um nível mais abstrato para muito próximo do código fonte. Se
começarmos a ter de encontrar um código fonte para contestar a atividade
inventiva de uma patente não consigo ver em que esta análise seja diferente do
copyright. Hoje dizemos que temos dois objetos distintos: o método (patenteável)
e o programa em si (não patenteável). Na medida em que a patente aproxima os
dois, a confusão que hoje já existe entre algumas pessoas entre método e
programa em si tende a se tornar cada vez maior.
Muitas
vezes uma invenção implementada por software
envolve um aspecto específico de um aplicativo e a execução deste item envolve
a execução do aplicativo que não estaria acessível ao examinador. Embora a
jurisprudência nos Estados Unidos em casos como Northern Telecom Inc. v. Datapoint Corp. (1990)[9]
e Fonar Corp. v. General Electric Co.
(1997)[10],
tem consolidado a tese de não necessidade de revelação do código fonte dos
programas nos pedidos de patente[11],
decisões recentes dos Tribunais norte americanos tem questionado a necessidade
da presença de códigos fontes em algumas destas patentes[12].
No caso Fonar v. General Eletric (107 F.3d 1549) de 1997 a General Eletric
alegou que a patente não possuía descrição técnica suficiente.[13]
O juiz Lourie conclui: "como regra
geral, quando o software constitui parte do best mode para realização de uma
invenção o relatório descritivo de tal best mode é satisfeitos pela revelação
das funções do software. Isto porque normalmente a escrita de tal software
encontra-se dentro das habilidades de um técnico no assunto sem que para isso
seja exigido um esforço indevido, uma vez que suas funções tenham sido
reveladas [...] Assim fluxogramas ou listagens de código fonte não são uma
exigência para que a descrição das funções do software esteja atendida".
A corte citou In re Hayes Microcomputer 982 F2d 1527 de 1992 como apoio a tese
de que a descrição da função de um software é satisfatória para descrição da
matéria mesmo sem a apresentação de diagramas ou listagens de código fonte. Em
outro julgado que tratava de método para calcular a localização de um poço,
Corte entendeu que o critério de written
description não foi atendido uma vez que o titular manteve toda a
informação relativa aos programas de computador utilizados como segredo
industrial. A Corte alegou que seria necessário ao menos a descrição da
natureza geral dos programas, não sendo necessário o programa propriamente
dito. [14]Em
Typhoon Touch Techs v. Dell Inc. o Federal Circuito conclui: “reivindicações de software na forma de meios
mais funções exigem a descrição da estrutura correspondente para implementar
tal função no relatório descritivo, mas esta estrutura não precisa ser descrita
na forma de código de software”.[15]
Dan Burk e
Mark Lemley observam que uma vez que as Cortes tem entendido ser desnecessária
a apresentação do código fonte para descrição da invenção, então, seguindo-se o
mesmo critério, dificilmente tal implementação em código fonte, considerada
trivial, satisfaça os níveis exigidos de atividade inventiva para serem
protegidos por patente[16].
Em Lockwood v. American Airlines (1997),
a Corte entendeu que a patente descrita em termos de suas funcionalidades era
abrangida por uma anterioridade, escrita de forma totalmente distinta, porém
que realizava essencialmente as mesmas funções. Com base neste raciocínio, os
autores argumentam que muitas das ditas patentes de software concedidas pelo
USPTO, poderão ser contestadas na justiça, bastando-se apresentar
anterioridades que executem as mesmas funções, ainda que com código totalmente
distintos.
Em Northern Telecom v. DataPoint a Corte
conclui que o processo de implementação de conceito de software em código fonte
é considerado óbvio para qualquer programador.[17]
Ben Klemens observa que no direito autoral criações independentes não são
consideradas infrações, portanto, não é necessário buscas de anterioridades ao
se avaliar um código fonte, basta que se prove que seu desenvolvimento foi
realizado de forma independente do código supostamente copiado. Ronald Mann ao
entrevistar diversas empresas norte-americanas desenvolvedoras de software
constata que a proteção do código fonte é considerada frágil, uma vez que na
maioria das vezes a empresa considera mais prático desenvolver um novo código
do que ter de adaptar um código conhecido ao seu sistema, o que pode implicar
na maioria das vezes um esforço de desenvolvimento proibitivo. Neste sentido a
ênfase no código fonte se mostra como irrelevante. [18]
Joseph Root destaca que ao contrário das críticas de Lemley, as Cortes
tendem a interpretar de forma restritiva as patentes. Os casos Phillips v. AWH
Corp. (Fed. Cir. 2005) (en banc) do
Federal Circuit e Markman v. Westview Instruments Inc[19]
(517 U.S. 370) da Suprema Corte em 1996 marcam uma interpretação mais restrita
das reivindicações, com base no detalhado no relatório descritivo, o que o
autor configura como uma verdadeira revolução na interpretação das
reivindicações (Disclosure Revolution).
Para o autor esta mudança de interpretação tem se consolidado e dado poucas
provas de se tratar de algo passageiro.[20]
Diante desta perspectiva Joseph Root recomenda aos inventores que escrevam um
quadro reivindicatório em que o que se deseja proteger esteja claramente descrito:
“O que o Federal Circuit busca é a
intenção do inventor – o que de fato o inventor acredita que é sua invenção ?
[...] Então, dê a eles esta intenção. Ao invés de esperar que um futuro
interpretador [o juiz] destas reivindicações adivinhe a intenção do inventor a
partir do relatório descritivo, simplesmente defina quais é esta intenção. Isto
abrevia o processo, e coloca o redator de volta no controle do pedido”.[21]
[1] LEMLEY, Mark; RISCH, Michael; SICHELMAN, Ted; WAGNER, R. Polk. Life
after Bilski. Stanford Law Review, Vol. 63, pp. 1315-1347, 2011 http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1725009
[2] LEMLEY, Mark. Software Patents and the Return of Functional Claiming,
2012, p. http://ssrn.com/abstract=2117302
[3]
http://www.ipwatchdog.com/2014/09/04/the-ramifications-of-alice-a-conversation-with-mark-lemley/id=51023/
[4] No.2008-693 (BPAI, 1
outubro 2009)
[5] 667 F.3d 1361(Fed. Cir.
2012)
[6] 174 F.3d 1308 (Fed. Cir. 1999)
[7] MUELLER, Janice. Patent Law. New York:Aspen Publishers, 2009, p.90
[8] LEMLEY, Mark. Software Patents and the Return of Functional Claiming,
2012, p. http://ssrn.com/abstract=2117302
[9] 908 F.2d 931 (Fed. Cir. 1990)
[10] 107 F.3d 1543, 1549 (Fed. Cir. 1997). Intellectual Property Rights in
Frontier Industries: software and biotechnology, Robert Hahn, Washington:AEI
Brookings, 2005, p. 83; BURK, Dan L.; LEMLEY, Mark, A. The patent crisis and
how the Courts can solve it. The University of Chicago Press, 2009, p.120
[11]
The Disclosure of Source Code in Software Patents:
Should Software Patents Be Open Source? Kenneth Canfield. 7 Colum. Sci. &
Tech. L. Rev. 6 (2006) (Published April 16, 2006)
<http://www.stlr.org/cite.cgi?volume=7&article=6>
[12]
TouchCom v. Dresser, 427 F.Sup.2d 730 E.D.Tx. 2005 e TouchCom v. Bereskin & Parr D.D.C
[13] http://en.wikipedia.org/wiki/Fonar_v._General_Electric
[14] Union Pacific Resources v. Chesapeake Energy Corp, 236, F.3d. 684,
690-92 (Fed.Cir.2001) cf. BURK, Dan L.; LEMLEY, Mark, A. The patent crisis and
how the Courts can solve it. The University of Chicago Press, 2009, p.121
[15] 659 F.3d 1376, 1384-86 (Fed. Circ. 2011) LEMLEY, Mark. Software Patents
and the Return of Functional Claiming, 2012, p. 949 http://ssrn.com/abstract=2117302
[16] Intellectual Property Rights in Frontier Industries: software and
biotechnology, Robert Hahn, Washington:AEI Brookings, 2005, p. 84
[17] 908 F.2d 931, 940-41, 15 USPQd 1321, 1328 (Fed.Cir.1990) cf. KLEMENS,
Ben. Math you can´t use, Brookings
Institution Press: Washington,2006, p.133, 137
[18] KLEMENS, Ben. Math you can´t use,
Brookings Institution Press: Washington,2006, p.141
[19] http://openjurist.org/517/us/370
[20] ROOT,.op.cit.p.xxxiv
[21] ROOT.op.cit.p.4
Nenhum comentário:
Postar um comentário