Votre invention bourrée de logiciel devrait-elle être brevetable ? Un test.
Je suis dans le camp de ceux qui ne croient pas aux brevets logiciels, pour les nombreuses raisons développées dans ce blog. Je ne suis pas pour autant contre la “Propriété Intellectuelle”, même si je trouve le terme mal choisi, par exemple je détiens des marques (et les défends fermement).
Cela ne veut pas dire non plus que je sois contre les brevets en général. Au contraire, l’argument de la protection des inventeurs m’interpelle, particulièrement s’ils n’ont pas les ressources ou la volonté de commercialiser eux-mêmes leur invention. L’argument de l’incitation à innover semble parfois justifié. Mais mon expérience en tant que développeur et entrepreneur m’a montré que ces arguments ne s’appliquent pas au logiciel. Le logiciel est différent, mais ce n’est pas l’objet de ce billet. Parce que le logiciel est différent, les brevets ne sont pas nécessaires pour protéger l’inventeur, et n’engendrent aucune incitation à la création. Ils ne font que vous piéger dans un labyrinthe de brevets douteux qui rendent l’acte d’innovation extrêmement périlleux. Au-delà de la question des brevets, je suis basiquement dans le camp du Droit d’Innover dans le Logiciel.
Nous, du camp du Droit d’Innover dans le Logiciel, devons reconnaître une difficulté avec notre position. Nous disons qu’il y a d’un côté des inventions qui peuvent être brevetées, et que nous sommes prêts à le défendre, et qu’il y a d’un autre côté le logiciel, qui ne peut pas être breveté. Une règle est donc nécessaire pour distinguer entre ce qui devrait être brevetable et ce qui ne l’est pas. Ce test devrait être aussi simple et opérationnel que possible, et laisser aussi peu de place que possible à l’interprétation. Ceci est indispensable pour obtenir la très indispensable sécurité juridique: si le critère est obscur ou flou, nous replongerons dans le cauchemar dont nous cherchons à sortir, nous le camp du Droit d’Innover dans le Logiciel. Si vous pensez que le logiciel peut être breveté, vous n’avez pas ce problème. Etant donné que nous créons le problème de la distinction entre le logiciel, non-brevetable, et les inventions qui contiennent du logiciel, qui sont brevetables, il semble raisonnable que ce soit nous qui devions nous creuser pour proposer un test.
J’ai donc examiné plusieurs critères, et retenu un, et le voici (continuez à lire !). Je commence par quelques tests qui ont été proposés, et j’essaie d’expliquer pourquoi ils n’ont pas “pris”.
Les forces de la nature sont surtout pour les esprits forts
En 2005, au cours de la campaigne en Europe autour des “inventions implémentées par ordinateur” (Computer Implemented Inventions ou CII), le critère de l’”utilisation des forces de la nature” a été particulièrement mis en avant: pour qu’une chose soit brevetable, elle doit faire appel aux “forces de la nature”. L’idée était que, par exemple, un système de freinage anti-blocage ABS est en fait un système de contrôle-commande avec un actuateur. C’est donc une machine, en tant qu’inventeur, vous devriez pouvoir obtenir un brevet, alors qu’un simple algorithme ne devrait pas être brevetable au simple prétexte qu’il tourne sur un ordinateur.
J’ai assisté à des discussions entre des activistes et des représentants élus, les premiers essayant d’expliquer l’argument aux seconds. Ces derniers, quoi qu’étant des gens brillants, ne saisissaient pas l’idée. Pour moi, ceci indique que le test n’est pas suffisamment clair (certains activistes pensent que l’argument n’a pas été assez expliqué, et qu’ils doivent continuer, une perte de temps de mon point de vue).
L’effet technique n’est pas technique en tant que tel
Un critère présent dans la Convention Européenne des Brevets (European Patent Convention, EPC) est que, pour être qualifiée comme telle, une invention doit avoir un “effet technique”. L’idée est plus ou moins la même que celle des forces de la nature, mais, là encore, l’expression du critère n’a pas la signification attendue. Par exemple, le Bureau Européen des Brevets (European Patent Office – EPO) a parfois considéré que la modification du courant électrique dans une mémoire d’ordinateur était un effet technique suffisant. Je considère qu’il s’agit là d’une distorsion audacieuse des termes, car il est clair que n’importe quel programme d’ordinateur a un tel effet, alors que l’EPC exclue explicitement le “logiciel en tant que tel” (“software as such”), de la brevetabilité.
La règle d’or
Il faut donc un nouveau test. Voilà le mien: la règle de distinction du logiciel de Tronche.
“Si une machine déjà existante peut être programmée (sans modification du matériel) pour faire ce que fait votre invention, ce n’en est pas une, et la demande de brevet devrait être rejetée.”
En particulier, s’il est possible de programmer un ordinateur à usage général, brut de décoffrage, pour faire la même chose, clairement votre “invention” n’en est pas une, c’est du pur logiciel, et doit donc être exclue de la brevetabilité. Le brevet porte sur l’ordinateur à usage général (qu’il soit de Zuse / Eckert-Mauchly / Von Neumann), qui est tombé depuis longtemps dans le domaine public.
Si on prend le cas du freinage ABS, le premier inventeur obtiendrait clairement son brevet avec ce test: aucun ordinateur de la FNAC, quel que soit le soit le programme qu’on écrit, ne pourra ralentir votre voiture si vous n’ajoutez pas un peu de matériel.
La protection obtenue alors est particulièrement forte: personne ne peut plus prendre un frein contrôlé par ordinateur, introduire des modifications logicielles, et prétendre avoir une nouvelle invention.
Il est simple de décider d’un litige avec ce test. Si vous pensez qu’un brevet n’aurait
pas dû être attribué, il suffit de décrire comment obtenir le même effet avec une machine pré-existante.
Le test n’empêche pas non plus d’avoir un brevet pour l’implémentation en hardware d’une fonction connue, mais dans ce cas le brevet doit porter sur le design de la machine, non la fonction (elle a déjà été implémentée). Et n’oubliez pas que vous pouvez protéger le masque en tant que dessin, pas seulement par un brevet.
Pensez à appliquer la règle de Tronche la prochaine fois que vous entendrez parler de brevet logiciel, cela vous donnera une idée de vos chances de survivre à la bulle des brevets logiciels.
RSS
Your test still holds some problems — it’s good and will likely be enough for most cases. I propose instead that a different approach can be taken. It is more complex, but I don’t think you can make a good seperation between patentable and non-patentable machines without at least some complexity.
First of all you have to acknowledge that a program (software) is a machine. it is not all that different from any other machine, except that the reality it exists in is different and thus it plays by different rules.
Machines that are not software, are hardware and can not be used in hardware. Machines that are not hardware are software and can not be used without hardware.
Now, to test if a machine is patentable you simple ask if it requires hardware. If it does, then (since it’s software), it’s non-patentable. Any piece of hardware that requires another piece of hardware to do it’s thing is still patentable, because it doesn’t really require hardware to do anything — it just requires hardware to do the one (or more) right thing(s):
You should note that human minds are machines according to this context, and so anything that can be passed as software should also fit in our mind (since the mind can solve any turing problem it should hold true for any real software) — so it should be enough to be able to solve a given problem in our minds to prove that a machine is not patentable.