Analogia entre software e hardware

Um método que constitua a solução de um problema técnico, que seja implementado por programa de computador é passível de proteção por patentes, porque entende-se não se tratar do programa de computador em si (artigo 10 inciso V da LPI), ou seja, a organização do conjunto de instruções, a sucessão de rotinas e subrotinas, a sucessão temporal dos comandos, que imprimem ao código fonte a originalidade do programador. Diversas criações implementadas por programas de computador podem ser implementadas seja por um programa de computador ou por circuitos de hardware, sendo a escolha determinada por aspectos econômicos ou práticos, de modo que o conceito inventivo envolvido se mantém o mesmo nas duas implementações.

Esta analogia forte entre programa de computador e hardware foi o principal argumento para que tais criações passassem a ser incluídas como invenções e, pudessem receber, assim, a proteção por patentes. Considere por exemplo o caso de um filtro digital implementado por um programa de computador. Tal filtro possui características de resposta de freqüência capaz de filtrar sinais digitalizados, com desempenho similar a de um filtro implementado por resistores, capacitores e bobinas capaz de realizar a filtragem de um sinal analógico. Se a patenteabilidade de filtros analógicos é aceita no sistema de patentes[1] não haveria lógica para a rejeição de sua patenteabilidade de seu equivalente lógico implementado por programa de computador. Na EPO T208/84 discutiu a patenteabilidade de filtros digitais de processamento de imagens e conclui que embora reivindicações do tipo “método para filtragem digital de dados” seja considerada uma noção abstrata, não técnica[2], a forma “método para filtragem digital de dados processados por computador” já não é visto como abstrato e atende aos requisitos de patenteabilidade. No INPI as duas formas seriam passíveis de proteção por patentes.

A analogia entre hardware e software torna difícil estabelecer um critério objetivo de enquadramento de um pedido de patente como patente implementada por software.[3] Mark Lemley destaca que uma linha divisória entre o que constitui patente de sofware é sujeita a avaliações subjetivas, por exemplo, o Toyota Prius é um motor híbrido gasolina-elétrico que possui sofisticado controle eletrônico que decide quando alimentar o veículo com motor a gasolina ou bateria, e que inclui software. John Allison e Startling Hunter argumentam que a tentativa de estabelecer uma linha divisória nestes casos seria fútil e contraprodutiva porque hábeis advogados saberiam como reescrever seus pedidos numa forma que contornasse a definição, ou seja, o efeito prático seria apenas o de aumentar o custo de redação de um pedido de patente. [3.1] Uma invenção pode envolver para sua implementação um programa de computador, mas este, em si, (artigo V do Artigo 10 da LPI) não é objeto da proteção patentária da mesma forma que uma invenção pode envolver aspectos estéticos (incido IV do artigo da LPI) que igualmente são desconsiderados na análise da patenteabilidade de uma invenção. Pode-se resumir que a diretriz proposta pelo INPI está centrada fundamentalmente na identificação da solução de um problema técnico que o pedido de patente se propõe resolver, que não deve se enquadrar em nenhuma das exceções do Artigo 10 da LPI.

A concessão de patentes de processos (não químicos) e de produto definido por meios/dispositivos para realizar funções tem sido admitido pelo INPI a décadas, como por exemplo, a patente nº 28969 de 26 de abril de 1941 concedida pelo então DNPI e que tem como reivindicações “1. Processo para esmerilhar ou polir uma superfície de metal que compreende fazer girar um feltro ou almofada flexível com a superfície coberta com um tecido com abrasivo a grande velocidade em trajeto circular sobre a dita superfície [...] 8. Aparelho para esmerilhar ou polir as superfícies de lâminas de metal compreendendo um dispositivo de funcionamento contínuo para dar movimento retilíneo de vai-vem a uma lâmina num trajeto determinado [...] dispositivo de montagem do dito veio portador para permitir movê-lo em sentido vertical enquanto gira [..] dispositivo para acionar o dito eixo de transmissão [...]”.

Na área de telecomunicações esta formulação é bastante comum. Considere a patente nº 28769 de 20 de fevereiro de 1941 cuja reivindicação descreve: “Aparelho telefônico tendo um transmissor de impulsos para preparar uma ligação telefônica automática o qual é adaptado depois de transmitir um número pré-determinado de séries de impulsos a operar para tornar o transmissor de impulsos ineficaz para transmitir uma outra série de impulsos a não ser que uma moeda seja depositada [...]”. De acordo com a tecnologia da época esta implementação foi realizada em hardware, porém, esta mesma reivindicação, hoje possivelmente seria implementada em software.

Na área de mecânica, sistemas e métodos de controle de um sistema de transmissão de marchas não automatizados, descritos pelas suas funcionalidades, têm sido concedidos pelo INPI, e parece não haver muita objeção a tais concessões (PI9202937 sistema/método de controle de reengate para o sistema semi-automático de transmissão mecânica, PI9300097 método de controle de mudança de seção auxiliar de transmissão, PI9702497 método para eliminar escapamento de marcha, PI0303671 método para monitorar o comportamento de um pneumático durante a marcha, PI9700670 método para prover um conjunto de alavanca de mudança e para reduzir saídas de marcha, etc). Nesse sentido, vetar a patenteabilidade de tais métodos e sistemas quando automatizados pareceria contraditório. Pelo fato de serem automatizados tais métodos deixariam de ser vistos como métodos técnicos para solução de um problema técnico ? Aceitar esta interpretação seria ir na contramão do progresso tecnológico, ou seja, exatamente no vetor que aponta o progresso tecnológico o sistema de patentes deixaria de ser usado. Tomando-se por princípio que o sistema de patentes é um elo importante na cadeia de inovação dos países desenvolvidos tecnologicamente, e que cada vez mais o software permeia muitas invenções tecnológicas, esta interpretação restritiva tenderia a tornar o sistema de patentes à margem das inovações do mundo moderno.

Se métodos implementados em um hardware são objeto de patentes então vetar a patenteabilidade aos seus equivalentes lógicos em software, não seria lógico, pois ambos, como métodos industriais se prestam a solução do mesmo problema técnico sendo sua implementação em software ou hardware uma questão de projeto. A analogia entre hardware e software está presente nos trabalhos de pioneiros da ciência da computação como Dijkstra que em “Structured Programming” de 1972, escreve: “como programador por profissão, programas são aquilo do que eu trato nesta seção cujo verdadeiro tema é a confiabilidade dos programas. Que, apesar disso eu tenha mencionado a expressão “mecanismos” no título é porque eu considero programas como exemplos específicos de mecanismos, e desejo expressar, ao menos por uma vez, meu forte desejo de que muitas de minhas considerações relativas a software são mutatis mutandis, da mesma forma relevantes para o projeto de hardware”[4]. Greg Ahronian ao comentar um artigo de Larry Graham que trata do mito das patentes de software argumenta: “Concordo com ele que isto constitui um mito e que o software de fato deva ser patenteado ... a luz das teorias de Turing, Church e Post, das ferramentas de projeto de software e hardware e da doutrina de equivalentes, se o hardware é patenteado, então o software também deve ser”.[5] Vannevar Bush pioneiro na construção de um computador no MIT projeto o “Analisador diferencial” era composto de rodas dentadas e discos de modo a estabelecer uma analogia física das equações diferenciais.

Um outro exemplo mostra a analogia software / hardware como questão de projeto. Na década de 1990 a principal preocupação dos arquitetos de computadores era a redução dos custos de software. Essa preocupação foi atenuada principalmente pela substituição de software por hardware simplificando desta forma a tarefa dos projetistas de software ao se criar arquiteturas de hardware mais eficientes e sofisticadas. Exemplos desta época são as arquiteturas VAX com vários modos de endereçamento, suporte a vários tipos de dados e uma arquitetura altamente ortogonal. Na década de 1980 houve um retorno a arquiteturas de hardware mais simples, com o uso de uma tecnologia de compiladores (software) mais sofisticada e o desenvolvimento de processadores com conjuntos de instruções reduzidas RISC Reduced instruction set computers. Os primeiros processadores RISC foram desenvolvidos pela Universidade de Berkeley (RISC-I) e Stanford (MIPS). [6]

Com o desenvolvimento da computação o software das mercadorias finais está cada vez mais incorporado no hardware dos circuitos, o que é particularmente válido nos microprocessadores e em geral em muitos circuitos VLSI[7], ou seja, cada vez mais o software está permeando as inovações tecnológicas de diversas áreas, de modo que deixar tais áreas fora da proteção patentária seria deixar de aplicar um instrumento útil de estímulo à inovação e relegar a propriedade industrial a um papel marginal na atual era do conhecimento. Ademais há uma tendência consolidada de pelo menos trinta anos nos escritórios de patentes dos Estados Unidos (após o caso Diamond x Diehr, em 1981) e na Europa (após o caso VICOM T208/84 em 1986) a se conceder patentes de invenção implementadas por software. Uma das primeiras patentes de invenções implementadas por programa de computador nos Estados Unidos foi concedida a Erna Hoover e 1971 para um sistema de controle computadorizado que monitorava a frequência das ligações em uma central telefônica e redistribuía a taxa de completude dos telefonemas nos horários de pico para evitar sobrecargas. [8]

Segundo Denis Barbosa: “enquanto um programa de computador em si não é nunca objeto de proteção por patente (por ser expressão ... ), ele pode incorporar ou expressar ideias e, mais, pode dar a certas soluções teóricas o caráter de ação prática sobre o universo circundante, vale dizer, o requisito de utilidade industrial que exigem as Leis de patentes. São estas as chamadas patentes de software”[9]. A EPO contudo em T204/93 destaca que a exclusão dos programas de computador em si do Artigo 52(2) e (3) não se dá por serem considerados sem aplicação industrial do Artigo 52(1) mas pelo falto de não serem considerados como invenção. Portanto, na visão da EPO todos os programas dizem respeito à chamada indústria de software e atendem ao critério de aplicação industrial, muito embora apenas algumas das criações implementadas por programa de computador possam ser consideradas como invenções. [10] T953/94 deixa claro que os conceitos de “técnico” e “industrial” não podem ser considerados como sinônimos. Na tradução oficial do Artigo 52(1) o texto em alemão refere-se a aplicação industrial como gewerblich anwendbar, em que o o termo gewerblich tem a conotação de incluir as atividades ditas comerciais, ao passo que a palavra industrie de caráter mais restritiva não foi empregada.

Analogia entre hardware e software em ação: O mesmo número de conversas telefônicas 

pode ser estabelecido utilizando-se como meio de transmissão 1 tonelada de fios de cobre ou 50 quilos de fibra ótica

---

[1] Margarida Mittelbach, Patentes – Formas de proteção, INPI, cf. Comentários à Lei de Propriedade Industrial, Douglas Gabriel Domingues, Rio de Janeiro:Ed. Forense, 2009, p.38

[2] Case Law of the Boards of Appeal of the European Patent Office Sixth Edition July 2010, p. 13 http://www.epo.org/law-practice/case-law-appeals/case-law.html

[3] BESSEN, James, A generation of software patents, junho 2011, Boston Univ. School of Law, Law and Economics Research Paper No. 11-31 http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1868979; ABRANTES, Antonio; VALDMAN, Catia; Estatísticas de pedidos de patentes implementados por programa de computador no Brasil e na EPO: um estudo comparativo, Revista da ABPI, v. 18, p. 29-40, 2009
[3.1] ALLISON, John; HUNTER, Startling. On the feasibility of improving patent quality one technology at a time: the case of business methods, 21, Berkeley Technology Law Journal, p.729-736, 2006; LEMLEY, Mark. Software Patents and the Return of Functional Claiming, 2012, p. 937 http://ssrn.com/abstract=2117302 

[4] “Being a programmer by trade, programs are what I am talking about and the true subject of this section really is the reliability of programs. That, nevertheless, I have mentioned "mechanisms" in its title is because I regard programs as specific instances of mechanisms, and that I wanted to express, at least once, my strong feeling that many of my considerations concerning software are, mutatis mutandis, just as relevant for hardware design”

[5] GRAHAM, Larry. Debunking software patent myths, IEEE Software, julho/agosto de 2000. A resposta de Greg Ahronian foi publicada em sua lista PATNEWS de 15 de setembro de 2000

[6] HENESSY, John; PATTERSON, David. Arquitetura de computadores: uma abordagem quantitativa, Rio de Janeiro:Campus, 2003, p. 109, 112.

[7] Mudança técnica e transformação industrial: a teoria e uma aplicação à indústria dos semicondutores, Giovanni Dosi, São Paulo:Ed.Unicamp, 2006, p.118

[8] CHALLONER, Jack. 1001 invenções que mudaram o mundo. Rio de Janeiro:Ed. Sextante, 2010, p. 822

[9] Usucapião de patentes e outros estudos de propriedade industrial, Denis Barbosa. Rio de Janeiro:Ed. Lumen Juris, 2006, p.638

[10] Case Law of the Boards of Appeal of the European Patent Office Sixth Edition July 2010, p. 223 http://www.epo.org/law-practice/case-law-appeals/case-law.html