Brevet logiciel : démontrer l’effet technique supplémentaire

Un logiciel n’est pas brevetable du seul fait qu’il est nouveau, complexe ou exécuté par un ordinateur. En France comme devant l’Office européen des brevets (OEB), les programmes d’ordinateur sont exclus lorsqu’ils sont revendiqués « en tant que tels ». L’examen de cette exclusion porte sur un point précis : le programme produit-il un effet technique supplémentaire, au-delà des interactions physiques ordinaires entre le logiciel et le matériel qui l’exécute ?

La demande doit préciser quelles caractéristiques du logiciel produisent l’effet invoqué. La fonction commerciale ou intellectuelle du programme ne permet pas, à elle seule, d’établir cette contribution technique.

L’effet supplémentaire répond à la question de l’exclusion du programme. Les critères de brevetabilité permettent ensuite d’apprécier l’invention dans son ensemble.

Pourquoi les programmes d’ordinateur sont-ils exclus « en tant que tels » ?

Une invention comportant du code peut être brevetable. L’utilité de sa fonction pour l’utilisateur ne démontre toutefois pas l’effet technique de l’exécution du programme.

D’après les directives INPI et les Directives d’examen de l’OEB, un programme peut échapper à l’exclusion lorsqu’il produit un effet technique supplémentaire. Cet effet doit aller au-delà des phénomènes ordinaires et inévitables liés à l’exécution d’un logiciel, comme le passage de courant dans les circuits, l’utilisation générique d’un processeur ou l’enregistrement de données en mémoire.

L’exécution d’une instruction par un ordinateur ne suffit donc pas. La demande doit montrer que l’exécution du programme modifie le fonctionnement technique d’un système, commande un procédé technique ou traite des données dans un but technique identifiable.

Le caractère technique et l’application industrielle répondent à des questions distinctes : la nature de la solution, d’une part, et sa possibilité de fabrication ou d’utilisation concrète, d’autre part.

Qu’est-ce qu’un effet technique supplémentaire ?

Un effet technique supplémentaire est un effet qui dépasse les interactions physiques normales entre le programme et le matériel qui l’exécute. Un gain de performance ne suffit pas à le caractériser. Sa nature technique doit ressortir des fonctions revendiquées et de leurs effets, indépendamment des désignations « logiciel industriel », « intelligence artificielle » ou « plateforme sécurisée ».

Cet effet peut notamment concerner :

• la commande d’une machine, d’un véhicule ou d’un procédé industriel ;
• l’amélioration du fonctionnement interne d’un ordinateur ou d’un réseau ;
• le traitement de signaux ou d’images en vue d’une finalité technique déterminée ;
• la sécurisation technique d’une communication ou d’un stockage ;
• la réduction d’une contrainte matérielle mesurable, telle qu’une latence, une consommation de ressources ou une occupation mémoire, lorsque cette réduction résulte des caractéristiques revendiquées ;
• la détection ou la correction d’un état technique dans un équipement.

Une baisse du temps de calcul ou de la mémoire utilisée doit être rattachée aux opérations qui la produisent et à leur rôle technique. Une mesure de performance isolée laisse ce mécanisme indéterminé.

À l’inverse, présenter des informations plus vite, appliquer une règle de tarification, établir un classement commercial ou accélérer une procédure de gestion ne démontre pas, à soi seul, un effet technique supplémentaire. L’automatisation peut être utile et innovante sur le plan économique sans constituer, pour autant, une contribution technique brevetable.

Comment identifier la contribution technique d’un logiciel ?

L’analyse porte sur le problème rencontré, les composants concernés, les opérations du programme et l’effet qui leur est attribué.

1. Décrire le problème sans utiliser la solution

Le problème rencontré avant l’invention doit être décrit sans anticiper la solution. « Un meilleur algorithme » ou « automatiser la tâche » ne précisent pas la difficulté technique : instabilité d’une commande, surcharge d’un réseau, perte de précision d’un capteur, conflit d’accès à une ressource ou consommation excessive de mémoire.

Un problème formulé en termes exclusivement commerciaux ou organisationnels ne permet pas de présumer le caractère technique de la solution. Il n’exclut pas pour autant toute possibilité de brevet.

2. Identifier les éléments techniques concernés

La description précise les composants avec lesquels le programme interagit : processeur, mémoire, capteur, actionneur, réseau, terminal, dispositif médical, chaîne de production ou autre équipement. Elle identifie aussi les données représentant un phénomène physique ou l’état d’un système technique.

La présence d’un composant matériel générique ne suffit pas : son interaction avec les opérations du programme doit être expliquée.

3. Relier chaque fonction à un effet observable

Chaque fonction essentielle doit être reliée à son résultat technique : modification d’une commande, réduction du volume transmis, correction d’une erreur de mesure ou fonctionnement du système malgré une limitation matérielle.

Le lien causal doit être explicite :

1. une caractéristique du programme exécute une opération déterminée ;
2. cette opération agit sur un élément ou un processus technique ;
3. cette action produit un effet technique identifiable.

La description doit préciser les conditions dans lesquelles ces opérations produisent l’effet invoqué. À défaut, la contribution technique reste une affirmation non expliquée.

4. Distinguer le résultat recherché des moyens qui le produisent

Dire qu’un logiciel est « plus rapide », « plus fiable » ou « plus sûr » décrit un objectif, pas nécessairement une solution technique. La demande doit expliquer les mécanismes qui permettent d’obtenir ce résultat.

Par exemple, une réduction de latence peut dépendre d’une organisation précise des échanges, d’un traitement local d’une partie des données ou d’une gestion particulière des ressources. L’analyse doit porter sur ces moyens et leur lien avec l’effet annoncé, plutôt que sur la seule promesse de rapidité.

5. Vérifier que la description permet de reproduire l’effet

La demande doit exposer l’invention de manière suffisamment claire et complète pour que l’homme du métier puisse l’exécuter sur toute la portée revendiquée, sans effort excessif ni activité inventive. Elle ne doit pas lui imposer un véritable programme de recherche. Une promesse de performance sans architecture, conditions de fonctionnement ni enchaînement opérationnel peut fragiliser le dossier.

La description doit ainsi permettre de documenter une invention reproductible.

Quels signes révèlent une simple automatisation non technique ?

Lorsqu’un programme exécute des règles intellectuelles ou administratives, l’analyse doit rechercher un effet technique supplémentaire au-delà de leur automatisation. Les indices suivants peuvent révéler l’absence d’explication de cet effet. Ils ne permettent pas de conclure à l’exclusion de tout procédé mis en œuvre par ordinateur :

• les entrées sont uniquement des choix humains ou des données commerciales ;
• la sortie est une décision de gestion, un prix, un classement ou une recommandation non technique ;
• le matériel est décrit comme un ordinateur générique sans adaptation particulière ;
• les gains allégués se limitent à la rapidité de calcul inhérente à l’informatisation ;
• aucune contrainte technique n’a orienté la conception de la solution ;
• aucune relation n’est établie entre les étapes logicielles et le fonctionnement d’un système technique.

Le secteur d’activité ne détermine pas la contribution technique. Un logiciel bancaire peut en comporter une, tandis qu’un logiciel destiné à une usine peut se limiter à une règle de gestion. L’examen porte sur les caractéristiques revendiquées et leurs effets.

Comment documenter l’effet technique avant le dépôt ?

Le dossier préparatoire réunit l’explication du mécanisme et les éléments disponibles à l’appui de l’effet annoncé.

Constituer une fiche problème-solution-effet

La fiche peut réunir les éléments suivants, sans constituer un formulaire imposé :

La fiche distingue les observations des effets encore attendus. Elle fait apparaître les points non étayés, notamment un effet sans mécanisme expliqué ou un mécanisme dont l’effet technique reste à identifier.

Conserver les éléments de preuve disponibles

Les essais comparatifs, journaux techniques, mesures de latence, profils de mémoire, simulations ou schémas doivent préciser la configuration, les conditions de fonctionnement et les opérations auxquelles l’effet est attribué. Une comparaison entre deux versions doit permettre de comprendre ce qui change : mécanisme logiciel, matériel, charge ou données d’entrée. Elle sert à étayer l’explication technique, sans tenir lieu d’analyse de brevetabilité.

Décrire des variantes cohérentes

Pour chaque variante, la description précise les opérations modifiées et celles qui maintiennent le lien avec l’effet technique. Un résultat observé dans une configuration ne peut être présumé pour toutes les autres : la description doit rester cohérente avec la portée revendiquée.

L’effet technique suffit-il à démontrer l’activité inventive ?

Non. Un effet technique supplémentaire peut permettre au programme d’échapper à l’exclusion « en tant que tel », mais il ne prouve ni la nouveauté ni l’activité inventive.

L’activité inventive pose une autre question : la solution découle-t-elle de manière évidente de l’état de la technique pour l’homme du métier ? Identifier un effet technique ne répond pas à cette question. Il reste à confronter la solution aux enseignements antérieurs, sans reconstruire le raisonnement après avoir pris connaissance de l’invention.

Les deux examens portent ainsi sur des questions distinctes :

• exclusion du programme « en tant que tel » : son exécution produit-elle un effet technique supplémentaire ?
• activité inventive : cette contribution technique aurait-elle été évidente pour l’homme du métier au regard de l’état de la technique ?

La non-évidence s’apprécie avec la méthode problème-solution.

Exemple générique d’analyse

Dans un exemple hypothétique, un programme répartit des tâches entre plusieurs unités de calcul partageant une mémoire.

Une formulation limitée à « sélectionner l’unité la moins coûteuse selon un tarif » décrit une règle économique. Le serveur qui applique ce tarif n’explique aucun effet technique supplémentaire.

Supposons maintenant que le programme relève les demandes d’accès à une zone mémoire et diffère certaines tâches lorsque leurs accès risquent de se chevaucher. L’effet à examiner serait la réduction des conflits d’accès. L’analyse porte alors sur le lien entre la détection du chevauchement, la décision de différer une tâche et le comportement de la mémoire, et non sur le seul fait de répartir des tâches.

L’examen de cette seconde hypothèse exige de préciser :

• quels paramètres décrivent l’état des ressources ;
• comment les accès concurrents sont repérés ;
• selon quelle règle une tâche est différée et pourquoi cela réduirait les conflits mémoire ;
• dans quelles conditions cet effet a été observé ou reste à vérifier.

La mention d’une « optimisation des ressources » ne décrit ni la détection des accès concurrents ni leur traitement. Ces opérations déterminent pourtant le lien avec la réduction alléguée des conflits mémoire.

Préparer l’étude de brevetabilité

L’étude repose sur la description fonctionnelle, les schémas d’architecture, les contraintes techniques, les variantes et les éléments à l’appui de l’effet obtenu. Elle traite séparément l’exclusion du programme « en tant que tel », la nouveauté et l’activité inventive.

Lorsque la contribution repose principalement sur un calcul, l’analyse concerne aussi les algorithmes et méthodes mathématiques. La rédaction de la description et des catégories de revendications est traitée dans le guide sur l’invention mise en œuvre par ordinateur.

Le mécanisme, l’effet et les questions non résolues délimitent le dossier de l’étude de brevetabilité.

Cet article présente des principes généraux et ne remplace pas une analyse de brevetabilité adaptée à l’invention, aux revendications envisagées et à l’état de la technique pertinent.