Considere um pedido de patente que trate de método de criptografia implementado por software que reivindica meios porém no relatório descritivo refere-se aos ditos meios com trechos do código fonte identificando claramente serem tais meios implementados preferencialmente por software. Não é muito comum ter trechos de código fonte no pedido, mesmo que não o mostrasse vários são os casos em que o método pode ser implementado por software.
Em primeiro lugar há que se dizer que a implementação em software descrita no relatório é preferencial o que não impede de também ser implementado o mesmo conceito da reivindicação em hardware, por exemplo, em criptografia por hardware[1]. Sediada em Campinas a Kryptus em conjunto com a Unicamp anunciou no segundo semestre de 2012 o lançamento do Cripto-Processador Seguro (CPS) - primeiro processador criptográfico de uso geral disponível comercialmente. O dispositivo implementa um “Firewall em Hardware” contra invasões de seus periféricos além de possuir mecanismo inovador anti-malware e anti-rootkit com patente depositada junto ao INPI[2]
BID - Kryptus lança primeiro Cripto-Processador Seguro nacional de uso geral Foto - Kryptus
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).[3]
Podemos discriminar dois objetos distintos o método solução técnica e a implementação específica do software dito software em si. Se um outro programador escreve um código Y distinto do apresentado no pedido de patente, usando outras instruções a ponto de uma pessoa não identificar o código como cópia, então ela terá proteção de direito de autor para este código em si. Se o titular da patente quiser usar este código Y terá de pagar direitos ao seu autor. Os direitos sobre o programa em si estão preservados.
É o mesmo caso do desenho D de uma xícara. O desenho industrial e a patente da xícara protegem objetos distintos. Se o titular da patente da xícara quiser usar o desenho D terá de pagar direitos ao autor do desenho na xícara, mesmo este desenho D estando dentro do escopo de sua patente da xícara. Outro exemplo: tenho uma patente de método para fabricar um bolo, popular receita de bolo. Se eu escrevo um livro descrevendo com minhas palavras este método eu tenho direito de autor deste texto, mas se eu quiser fabricar o bolo terei de pagar direitos ao titular da patente. Dois objetos distintos protegidos por mecanismos distintos: patentes e direito de autor respectivamente.
O que não podemos é conceder patente para este código ou como uma reivindicação do programa de computador caracterizado pelas instruções XYZ porque isto é protegido por direito de autor, ou pior ainda programa de computador caracterizado pelas funções, pois neste caso estaríamos privando os futuros programadores de terem proteção por direito de autor de suas criações.
[1] http://computadorcomputador.
[3] HENESSY, John; PATTERSON, David. Arquitetura de computadores: uma abordagem quantitativa, Rio de Janeiro:Campus, 2003, p. 109, 112
Nenhum comentário:
Postar um comentário