9.2. L'approche "problème-solution" dans le cas d'inventions de type mixte
Concernant le caractère technique des programmes d'ordinateur, voir également le chapitre I.A.6.5 "Inventions mises en œuvre par ordinateur".
Selon la jurisprudence des chambres de recours, les aspects purement conceptuels de la mise en œuvre et du développement de logiciels ne contribuent normalement pas à l'activité inventive (T 983/10 ; cf. par exemple T 49/99, T 1171/06 et T 354/07).
Dans l'affaire T 1173/97 (JO 1999, 609), la chambre a constaté qu'un produit "programme d'ordinateur" n'est pas exclu de la brevetabilité en application de l'art. 52(2) et (3) CBE 1973 si sa mise en œuvre sur un ordinateur produit un effet technique supplémentaire, allant au-delà des interactions physiques "normales" entre programme (logiciel) et ordinateur (matériel) (voir point 9.4 des motifs).
Dans l'affaire T 2825/19, la chambre a estimé que l'avis G 3/08 du 12 mai 2010 date: 2010-05-12, par rapport à la décision T 1173/97, recadrait l'interprétation de la technicité en matière de programmes informatiques. L'avis G 3/08 date: 2010-05-12 (points 13.5 et 13.5.1 des motifs) a explicitement rejeté l'argument selon lequel toute considération technique est suffisante pour conférer un caractère technique à l'objet revendiqué. Une telle interprétation plus restreinte du terme "technique" par rapport aux programmes informatiques représente un développement normal de l'interprétation d'une disposition juridique ouverte à interprétation (voir l'avis G 3/19), et c'est le cas pour les programmes informatiques "en tant que tels" dans les art. 52(2)c) et (3) CBE. La chambre a considéré totalement infondé l'argument du requérant selon lequel la notion de "considérations techniques supplémentaires" devait être interprétée de façon plus large afin de couvrir également les considérations visant à résoudre des problèmes se rapportant "seulement" à la programmation tels que la maintenabilité, la réutilisabilité et l'intelligibilité du code de programme ou en l'espèce, l'utilisation d'un modèle universel afin de traduite le langage naturel dans des expressions exécutables au sein d'environnements opérationnels externes. Une interprétation si large de la notion de "considérations techniques supplémentaires" semblait problématique au regard de l'obligation de garantir une certitude juridique et une prévisibilité juridictionnelle, impliquant une application uniforme du droit (voir l'avis G 3/08 date: 2010-05-12, point 7.2.3 des motifs) puisqu'on ne voyait aucun critère susceptible d'établir une frontière claire entre les aspects "techniques" et "non techniques" des programmes d'ordinateurs.
Dans l'affaire T 1370/11, la chambre a affirmé que l'amélioration de la rapidité d'un programme d'ordinateur ne constitue pas en soi une contribution technique à l'état de la technique (cf. également T 42/10). À cette fin, il faut démontrer qu'un procédé mis en œuvre par ordinateur ou un programme d'ordinateur a un effet technique "supplémentaire" et qu'il permet de résoudre un problème technique indépendamment de son temps de calcul absolu ou relatif. Ce n'est que dès lors, et que dans la mesure où l'accélération prétendue a une incidence sur un effet technique établi, qu'il est possible de faire valoir que l'accélération contribue à un effet technique et donc à l'activité inventive (T 641/00).
Dans la décision T 354/07, la chambre a constaté que les procédés conceptuels et les méta-méthodes de création de logiciels ne présentent généralement pas de caractéristiques techniques pertinentes pour la brevetabilité et ne peuvent donc pas établir l'activité inventive, à moins qu'il ne soit possible, dans un cas particulier, de prouver qu'il existe un lien causal direct avec un effet technique pertinent pour la résolution d'un problème technique. Le développement et la production de logiciels s'effectuent en plusieurs étapes, de l'analyse des besoins à la mise en œuvre du logiciel en passant par diverses phases de conception. Au cours de toutes ces étapes, il s'agit intrinsèquement d'activités intellectuelles comparables à l'activité de conception exercée par un ingénieur, même si des outils de programmation viennent les étayer et que l'objet de la conception est un système technique. Bien que la conception et la programmation de systèmes complexes notamment requièrent les compétences d'un ingénieur et l'application de connaissances techniques spécialisées, le résultat visé et obtenu directement au cours de chacune de ces phases de développement ne constitue pas pour autant la solution technique d'un problème technique, mais une spécification de conditions, un modèle de données, de processus et/ou de fonctions, ou encore un code programme. Cette évaluation s'applique à plus forte raison aux méta-méthodes qui, à un niveau encore plus abstrait, portent sur le processus de production de logiciels proprement dit. Elles donnent par exemple au développeur de logiciels des instructions sur la manière de structurer et d'organiser le processus de conception, ou sur les méthodes de modélisation à appliquer.
Dans l'affaire T 1539/09, l'invention portait sur un langage et un environnement de programmation graphique devant permettre à l'utilisateur de générer du code programme sans y consacrer trop de temps d'étude ni disposer de compétences spécialisées particulières. De l'avis de la chambre, l'effet consistant à réduire l'effort intellectuel devant être fourni par l'utilisateur lors de la programmation n'était pas de nature technique, d'autant qu'il s'agissait d'un effet globalement recherché pour tous les programmes, quelle que soit leur finalité (cf. T 741/11). La chambre a indiqué que l'acte de programmation – au sens de rédiger du code programme – constitue une activité intellectuelle, du moins dans la mesure où cet acte ne sert pas à produire un effet technique dans le cadre d'une application ou d'un environnement concrets. Le fait de définir et de produire un langage de programmation ne contribue donc pas en soi à résoudre un problème technique, même si le choix des moyens d'expression dans ce langage permet de réduire l'effort intellectuel que le programmeur doit fournir (cf. aussi T 2270/10).
Dans les affaires T 42/10 et T 1281/10, la revendication 1 définissait une méthode qui, sur la base de résultats de jeux, calculait la performance des joueurs en transmettant des messages entre les nœuds d'un graphe factoriel. La chambre devait déterminer dans quelle mesure les caractéristiques de la revendication revêtaient un caractère technique et pouvaient ainsi contribuer à l'activité inventive. Elle a renvoyé à la décision de la Cour d'appel d'Angleterre et du Pays de Galle dans l'affaire Gale's Application [1991] RPC 305. Dans la présente espèce, l'approche retenue par la chambre pour juger de la technicité d'une méthode mise en œuvre par ordinateur était de poser les mêmes questions que M. Nicholls dans l'affaire précitée. La première question était de savoir quel effet la méthode produisait dans son ensemble et si elle donnait lieu à un résultat technique global. La deuxième était de savoir si, en l'absence d'un tel résultat technique global, la méthode produisait au moins un effet technique à l'intérieur de l'ordinateur. En cas de réponse négative à ces deux questions, aucun problème n'était résolu et l'invention n'impliquait aucune activité inventive. L'avis de la chambre en ce qui concerne la technicité peut être résumé comme suit : l'objectif général consistant à préserver l'intérêt des joueurs n'est pas technique. L'objectif intermédiaire visant à évaluer et comparer les performances des joueurs ne l'est pas non plus. La présentation des performances par des calculs de probabilité et l'actualisation des valeurs relèvent de méthodes mathématiques. L'utilisation de graphes factoriels assortie de transmission de messages est du domaine des mathématiques ou de l'informatique abstraite. En conclusion, la seule caractéristique technique définie dans la revendication était le processeur (de l'ordinateur). L'objet de la revendication 1 n'impliquait donc aucune activité inventive si, pour l'homme du métier chargé de mettre en œuvre la méthode, il était évident d'utiliser un processeur d'ordinateur.
Dans l'affaire T 1630/11, la chambre a estimé qu'une méthode destinée à simuler un système multiprocesseur dans un dispositif électronique n'implique pas d'activité inventive. Le requérant avait allégué que l'invention permettait aux utilisateurs "de modéliser et simuler efficacement un système multiprocesseur". La chambre a fait observer que la majeure partie de la revendication 1 portait sur les expressions d'un environnement de programmation graphique, qui, dans l'affaire T 1539/09 (point 5 des motifs), n'avaient pas été considérées comme contribuant à l'activité inventive (cf. également T 2270/10, point 7 des motifs). La chambre a suivi sa jurisprudence antérieure, selon laquelle des modifications apportées à un langage ou un système de programmation qui permettent au programmeur de concevoir un programme plus facilement et donc, vraisemblablement, plus rapidement et avec une précision accrue, n'apportent pas de contribution technique à l'état de la technique.
Dans l'affaire T 2147/16, la chambre a estimé que la simple hypothèse qu'un algorithme soit optimisé pour l'équipement informatique et pourrait apporter une contribution technique, n'est pas suffisante. La mise en œuvre d'un algorithme dans le cadre d'une méthode pour filtrer les spams doit s'accompagner d'un effet technique supplémentaire avéré ou de considérations techniques spécifiques ; cet effet technique doit être spécifiquement et suffisamment documenté dans la divulgation de l'invention et se retrouver dans le libellé de la revendication ; l'algorithme doit avoir une finalité technique.
- T 183/21
Catchword:
The board came to the conclusion that a technical effect was achieved by the subject-matter of a claim defining a method of automatically controlling the performance of a recommender system in a communications system, the communications system including a client device associated with a user to which the recommendations were provided, on average, over substantially the whole scope of the claim (reasons, points 9.1 and 9.2, but see also point 7).
- T 1959/20
Catchword:
The implementation of non-technical requirements on a technical prior art system might require modifications which, at first glance, appear non-obvious, as there is no technical reason for them in view of the prior art alone. However, since according to the principles of "Comvik" non-technical features cannot contribute to inventive step, the non-technical requirements must be seen as a given, and the skilled person implementing them must make the necessary modifications to the prior art. (See point 17 of the reasons).
- Compilation 2023 “Abstracts of decisions”