[FR Francais] [translatable text] [howto help] [Addenda]
Google
Logic Patents > Journal > History > Journal 05 > Rocard 05-04-13
Journal 05Rocard 05-04-13Hannover 05-04-11 restart 05-02-02

Rocard publishes position on softpat directive
Commemorate Banana Union Day

The European Parliament's rapporteur Michel Rocard has published his views on the software patent directive and outlined the direction which his amendments will take. Rocard's approach seems to contain the needed ingredients for a directive that provides the needed clarifications and does what the Council claims it wants to do: exclude computer programs from patentability while allowing technical inventions (problem solutions involving controllable forces of nature) to be patented, regardless of whether their implementation runs under software control or not. Rocard proposes to replace the misleading term by "computer-implemented inventions" by "computer-controlled inventions" or "computer-aided inventions". The full report with amendments is expected soon after the debate of 21st April. JURI MEPs can submit amendments before May 6th. JURI votes on June 20th, the plenary votes on July 6th.
http://www.europarl.eu.int/meetdocs/2004_2009/documents/DT/563/563744/563744fr.pdf

Legal Affairs Committee

2005-04-13

Working Document
sur la brevetabilité des inventions contrôlées par ordinateur (2002/0047 (COD))

Rapporteur:
Michel Rocard

Le conseil des ministres a enfin adopté une position commune sur la brevetabilité des inventions mises en oeuvre par ordinateur pour permettre que se tienne le débat en deuxième lecture. Cinq états membres ont voté en faisant savoir par écrit qu'ils votaient pour débloquer la procédure, mais qu'ils souhaitaient voir le texte modifié par le Parlement. Notre désaccord du premier tour a été entendu.

Ce texte est essentiel aussi bien économiquement (quelques dizaines de milliards d'euros annuels sont en jeu) que politiquement ou philosophiquement : il s'agit du statut de la diffusion du savoir et des idées dans la société.

C'est un texte court, mais portant sur une matière extrêmement complexe. Depuis deux ans qu'il est en débat, il apparaît clairement que dans la difficulté à trouver des solutions consensuelles, les désaccords sur les définitions et les malentendus sont beaucoup plus importants que les désaccords sur le fond.

J'ai fait établir une note d'analyse du sujet précise et détaillée. Elle est longue. Au moment où je vous écris cette lettre, je ne suis pas sûr de pouvoir la faire traduire en anglais.

J'espère pourtant vous la donner à tous en français et en anglais. Mais en fait, pour le débat sans texte du 21 avril à Bruxelles, je préfère, avant de déposer officiellement mes propositions d'amendements, vous proposer de réfléchir ensemble au problème qui nous est posé, et à son traitement intellectuel.

Car dans ce texte court, nous n'avons en fait que deux problèmes sérieux, susceptibles de nourrir un conflit avec la Commission et le Conseil : celui de la délimitation de ce qui est brevetable et de ce qui ne l'est pas, et l'interopérabilité. Si le Parlement et finalement le Conseil suivent les orientations que nous leur proposons, le problème de l'interopérabilité se trouvera réglé de ce fait.

Il faut donc commencer par s'occuper de la délimitation. Quelle est la question ? Elle résulte de la contradiction entre le système légal et la tradition héritée d'une part, et les besoins de rémunération des investissements et de sécurité de la grande industrie appuyés par les dérives récentes de la brevetabilité aux Etats Unis, et dans une moindre mesure à l'office européen des brevets, d'autre part. Tous nos systèmes légaux, et surtout la Convention sur le brevet européen signée en 1973 à Munich établissent clairement que les logiciels ne sont pas brevetables (art 52.2. de la CBE). Or il existe plus de 150000 brevets de ce type aux Etats Unis, sans base légale et de l'ordre de 50000 à l'Office européen des brevets, à base juridique incertaine et inégalement valides devant nos droits nationaux.

Le développement foudroyant de l'informatique s'est étendu depuis vingt ans à toutes les branches de nos industries et de nos services. Au delà des usages professionnels, il n'y a plus un objet de consommation courante qui ne comporte de logiciels intégrés : voitures, téléphones portables, télévisions, magnétoscopes, machines à laver, commandes d'ascenseurs, etc.

Tout cela coûte cher à mettre au point. Il est normal, et souhaitable, que l'industrie puisse breveter les résultats de ses investissements pour en assurer la rémunération et les protéger de la contrefaçon et de la concurrence déloyale. La régulation des procédés physiques mis en oeuvre au sein des inventions est un très ancien problème : elle a pris d'innombrables formes, mécaniques ou pneumatiques notamment. Mettre au point de telles régulations, brevetables lorsqu'elles étaient elles-mêmes innovantes dans leur réalisation, était extrêmement coûteux.
Les remplacer par des logiciels, dont le coût de développement et de production est bien plus faible, représente une énorme économie.
Cela a poussé à leur multiplication.
Mais un logiciel est d'une autre nature.
Il est de l'ordre de l'immatériel.

En fait, un logiciel est la combinaison en une oeuvre originale d'un ou plusieurs algorithmes, c'est à dire un ensemble de formules mathématiques.
Or comme l'a dit Albert Einstein, une formule mathématique n'est pas brevetable.
Elle est de l'ordre des idées, comme un livre, ou une alliance de mots, ou un accord musical.

Depuis des millénaires, le savoir s'est construit et diffusé par la copie et l'amélioration, c'est-àdire par le libre accès aux idées.
Le fait que les savoirs modernes, du moins ceux qui ont quelque rapport avec la logique ou la quantification, puissent plus commodément être exprimés sous la forme de logiciels ne doit en aucun cas conduire à renoncer au principe du libre accès qui est le seul à garantir la capacité buissonnante qu'a l'humanité de créer constamment de nouveaux savoirs.

La compatibilité entre ces deux exigences contradictoires est recherchée depuis longtemps, et cette recherche est l'objet de la Directive en cause.
Le sens commun, comme la jurisprudence de certains offices de Brevets, tendent à dire que ce qui est brevetable, c'est l'invention, et non pas le logiciel qui peut être nécessaire à son contrôle.
Les textes de référence comme la jurisprudence de l'OEB expriment cette différence en parlant de "contribution technique", jusque là tout le monde est absolument d'accord.

Pour être brevetable en effet, une invention :

  • doit être nouvelle ;
  • doit n'être pas évidente ;
  • doit être susceptible d'application industrielle ;
  • doit avoir un caractère technique.

Le caractère technique est défini comme la capacité à donner une solution technique à un problème technique, c'est à dire appartenir à un domaine technique et avoir un effet technique.
Mais le mot de « technique » n'est pas défini, si ce n'est par "l'emploi de moyens techniques" ou pire encore par la simple nécessité de "considérations techniques".
Cette tautologie a conduit à breveter tout ce qui participait à la réalisation de l'invention, logiciel ou pas.

En outre et surtout, l'article 52.2 de la Convention de Munich stipule que les logiciels ne sont pas brevetables "en tant que tels", ce qui a conduit par dérive à l'interprétation manifestement fautive qu'il y aurait une différence entre les logiciels en tant que tels et les logiciels incorporés à une invention ou logiciels comme inventions, brefs logiciels utiles, et par là brevetables.

C'est ici que nous avons le devoir d'inno ver, que nous avons innové en première lecture, et que les cinq ou six Etats Membres qui ont fait état au Conseil de leur attente d'amélioration souhaitent que nous trouvions une solution.

La rédaction du Parlement en première lecture était peut être un peu sèche et a surpris.
Mais de très nombreux entretiens et discussions, notamment avec les représentants des industriels, ont confirmé que la voie de recherche que nous avions explorée était la bonne.

Un logiciel, formulation d'une idée, est de l'ordre de l'immatériel.
Le travail qu'il provoque à l'intérieur de l'ordinateur lui est interne et n'est pas directement communicable à qui ou quoi que ce soit.
Il faut pour que ce travail soit communicable et ait un effet qu'une pièce se mette en mouvement, qu'un signal électrique, radio ou lumineux se produise, qu'une information apparaisse sur un écran, ou que se déclenche n'importe quel effet physique.
Ce qui à l'évidence est brevetable ce sont tous les capteurs d'une part et tous les effecteurs de l'autre qui alimentent l'ordinateur en information traitable par le logiciel et qui tirent de l'information finalement produite par le logiciel dans son langage un effet physique constituant la solution technique au problème technique posé.
La distinction que nous cherchons sépare donc le monde immatériel du monde matériel ou plutôt du monde physique.

Mais chacun de ces deux mots est quelque peu insuffisant pour couvrir tout le champ nécessaire.
Matériel renvoie trop à la matière et pas à l'énergie, physique appelle implicitement une qualité palpable.

La préférence de votre rapporteur va à la rédaction suivante, qui prendrait place dans l'article de la Directive, celui qui précise les définitions;

Domaine technique désigne un domaine industriel d'application nécessitant l'utilisation de forces contrôlables de la nature pour obtenir des résultats prévisibles dans le monde physique.

Si l'on admet que même un simple signal, qu'il soit électrique, radio ou lumineux, est composé d'énergie, cette formulation englobe toutes les manières de capter l'information immatérielle produite par l'ordinateur sous la conduite du logiciel pour produire un effet perceptible et utilisable par une machine ou un homme.

Je crois cette définition englobante pour tous les besoins réels de l'industrie, sauf bien sur celui qu'ont éprouvé quelques sociétés de contrôler une chaîne de logiciels brevetés dépendant les uns des autres pour interdire l'accès de la concurrence aux activités en aval concernant l'industrie et l'invention en cause, ce qu'à l'évidence nous avons le devoir d'empêcher.

Tous les autres problèmes et donc tous les autres amendements sont des conséquences de ce choix initial.
Je suggère à mes collègues de n'en traiter qu'après que nous ayons pu nous mettre d'accord, ce qui est l'objet du débat du 21.

Afin que la directive puisse permettre le brevetage d'inventions contrôlées par ordinateur tout en empêchant la brevetabilité des logiciels, il sera nécessaire d'intervenir sur les points suivants :

  • afin de clarifier la portée de la directive, remplacement autant que possible du terme "invention mise en oeuvre par ordinateur" par le terme "invention contrôlée par ordinateur", ou encore "assistée par ordinateur", qui illustre bien mieux que le logiciel ne peut faire partie des caractéristiques techniques des revendications de brevet ;
  • définit ion claire du "domaine technique", tant positive que négative : d'une part, il devra être spécifié qu'un domaine technique est un
    domaine industriel d'application nécessitant l'utilisation de forces contrôlables de la nature pour obtenir des résultats prévisibles dans le monde physique
    , bornant ainsi la technique au monde physique ; d'autre part, il faudra spécifier que le traitement de l'information ne soit pas considéré comme un domaine technique au sens du droit des brevets et à ce que les innovations en matière de traitement de l'information ne constituent pas des inventions au sens du droit des brevets ; définit io n de façon non tautologique de la notion de contribution technique et d'activité inventive, et préciser pour cette dernière que seules les caractérist iques techniques des inventions devront être prises en compte lors de son évaluation ;
  • descript ion de la forme des revendications de façon tant positive que négative, afin que d'une part les revendications sur les inventions contrôlées par ordinateur ne puissent porter que sur des produits ou des procédés techniques, et d'autre part que les revendications de logiciels, en eux-mêmes ou sur tout support, soient interdites ;
  • pour assurer l'interopérabilité, renforcement de la confirmation des droits découlant des articles 5 et 6 de la directive 91/250, par le fait que lorsque le recours à une technique brevetée est nécessaire à la seule fin d'assurer l'interopérabilité entre deux systèmes, ce recours ne soit pas considéré comme une contrefaçon de brevet.

En fonction du débat du 21 avril, mes amendements seront mis au point et disponibles très vite après.

[ Rocard publishes position on softpat directive | Rocard publishes position on softpat directive | Hannover-Messe im Zeichen der Softwarepatente | cons050307 | http://wiki.ffii.de/Epo050330En | http://wiki.ffii.de/Spd0503En | restart 05-02-02 ]
Valid XHTML 1.0!
http://swpat.ffii.de/log/05/rocard0413/index.en.html
© 2005-04-20 (2005-04-13) Hartmut PILCH