Méthodes d’affaires et brevetabilité à l’OEB : l’homme du business fictif à l’épreuve de la décision T 1392/20

À l'Office européen des brevets (OEB), les inventions mises en œuvre par ordinateur, notamment celles concernant des méthodes d’affaires, sont soumises à des critères de brevetabilité stricts. L'exigence fondamentale est que l’invention revendiquée résolve un problème technique par des moyens techniques. Dès lors, cela signifie-t-il qu’une invention dans le domaine des méthodes d’affaires, dont les problèmes résolus peuvent sembler intrinsèquement non techniques, serait par nature non brevetable ?

La situation est plus nuancée. Si les schémas commerciaux eux-mêmes ne sont pas brevetables, des caractéristiques techniques non évidentes qui les mettent en œuvre peuvent l'être.

L'évolution récente la plus importante de la jurisprudence des chambres de recours de l'OEB en la matière a été la décision T 1463/11 (« CardinalCommerce »), qui a établi un cadre permettant de distinguer les exigences commerciales non techniques des caractéristiques techniques.

Pour ce faire, la décision « CardinalCommerce » introduit la notion d’un « Homme du business » fictif (également appelé « homme d’affaires » ou « entrepreneur »). L’homme du business fictif est, comme l’homme du métier connu de longue date, une abstraction  ayant pour but de fournir une approche rationnelle de l’activité inventive.

Selon la décision CardinalCommerce, l’homme du business fictif possède les caractéristiques suivantes :

• il ne possède strictement aucune connaissance technique et ne peut en aucun cas formuler la moindre demande technique. Par exemple, l’homme du business fictif ne demanderait pas l’utilisation d’internet, ou d’un certain nombre de processeurs ;
• en revanche, l’homme du business fictif peut résoudre un problème commercial, ou formuler des problèmes allant au-delà de préjugés de nature commerciale au moment du dépôt.

L’homme du business peut ainsi formuler un problème à l’homme du métier, sous la forme d’une spécification de conditions n’impliquant pas de caractéristique technique.

La question de l’évidence consiste alors à déterminer si le problème formulé par l’homme du business fictif est résolu par des caractéristiques techniques qui ne sont pas considérées comme évidentes au regard de l’état de la technique.

La Décision présentement commentée T 1392/20 du 15 juillet 2025, rendue par la Chambre de recours n° 3.5.01 de l’Office européen des brevets, concerne un recours formé contre la décision de la division d'examen rejetant la demande de brevet européen n° 15714898.2 pour défaut d'activité inventive.

L'invention concerne les paiements en ligne ([0001] de la demande publiée) et est brièvement expliquée ci-dessous :

Généralement, lors de paiements en ligne, les clients doivent fournir les données de leur carte bancaire au commerçant, ce qui présente un risque de fraude. D'une part, les clients peuvent utiliser des données de carte volées, ce qui représente un risque pour le commerçant. D'autre part, des commerçants malhonnêtes peuvent utiliser ces données à mauvais escient, ce qui représente un risque pour le client ([0003], [0004]). Pour remédier à ces problèmes, l'invention propose de configurer un dispositif utilisateur, tel qu'un smartphone, pour qu'il fonctionne comme terminal de point de vente (TPV) du commerçant.

Comme illustré sur les figures 5 et 6 ci-dessous, un utilisateur initie (2) une transaction de paiement sur le site web d'un commerçant en fournissant l'identifiant de son appareil. Le commerçant transmet (3) cet identifiant à un prestataire de services de paiement, par exemple un établissement bancaire acquéreur. Ce prestataire récupère un profil de configuration TPV spécifique au commerçant et envoie (4) la configuration TPV correspondante au dispositif utilisateur en fonction de données de routage  stockées dans un profil de dispositif utilisateur. [AH1.1][BL1.2]Le dispositif utilisateur configure une application de paiement en fonction de la configuration du point de vente reçue et lit (5) une carte de paiement à l'aide d'un lecteur de carte avant de traiter la transaction, [0051] à [0056] et [0091] à [0099].

 

La revendication 1 présentée dans la requête unique se lit comme suit :

“A remote transaction processing system including plurality of user devices, a payment service host, and a first data store, the first data store including a user device profile for each of the plurality of user devices, each user device profile including routing data for routing communications to the respective user device;

the payment service host being arranged to receive payment requests for each of a plurality of merchants for payment for a transaction initiated at their respective merchant website,

wherein, upon receiving a payment request designating a user device for a transaction with one of the merchants, the payment service host is arranged to retrieve a Point-of-Sale, PoS, configuration profile corresponding to the merchant and retrieve the user device profile from the first data store corresponding to the designated user device, the payment service host being arranged to communicate a PoS configuration dependent on the PoS configuration profile and on payment information on the transaction including the amount to the user device in dependence on the routing data,

the user device including a secure element in which a PoS terminal application is executed and a payment card reader, the user device being arranged to receive the PoS configuration for the transaction with the merchant, configure the PoS terminal application in dependence on the PoS configuration and to communicate with a payment card via the payment card reader for payment of the transaction with the PoS terminal application to thereby act as the merchant's PoS terminal on the user device for the transaction with the merchant and complete a payment transaction, whereby the payment transaction is sent back to the payment service host.”

Les différences entre la revendication 1 et l'état de la technique le plus proche (D4), sur lesquelles s'accordent le demandeur, la division d'examen et la chambre de recours, sont les suivantes :

1. Le prestataire de services de paiement reçoit une demande de paiement identifiant un dispositif utilisateur spécifique pour une transaction avec le commerçant et récupère le profil correspondant de cet appareil, incluant les données de routage nécessaires à la communication.
2. Le prestataire de services de paiement récupère le profil de configuration du TPV associé au commerçant et envoie la configuration correspondante au dispositif utilisateur en fonction des données de routage. 
3. Le dispositif de l'utilisateur configure une application de terminal de point de vente (TPV) au sein d'un élément sécurisé, en fonction de la configuration TPV reçue. Ceci lui permet de fonctionner comme le TPV du commerçant et de finaliser la transaction de paiement en communiquant directement avec le serveur du service de paiement.

La division d'examen a considéré que la revendication 1 n'était pas inventive au regard du document D4, car le profil de configuration TPV représenterait un ensemble de règles métier ou de préférences définies par le commerçant, et le déploiement de ces préférences sur le dispositif de l'utilisateur, comme dans les caractéristiques 1 à 3, constitue une simple mise en œuvre d'une exigence métier non technique sur une architecture de système de paiement généralement connue.

La chambre de recours a adopté une position différente, exprimée au point 4.5 de sa décision. Conformément à l'approche de l'arrêt CardinalCommerce, la chambre a estimé que :

• l’homme du business fictif pouvait fournir l'objectif abstrait d'éviter la transmission des données de carte au commerçant ;
• les points 1 à 3 sont techniques et définissent une solution technique pour atteindre l'objectif abstrait soumis par l’homme du business. 

Plus précisément, la Chambre a considéré que les étapes 1) à 3) impliquent la modification de l'infrastructure système existante, notamment la configuration et l'intégration du dispositif utilisateur dans le flux de paiement. De telles modifications requièrent une connaissance technique de l'architecture système et relèvent de l'expertise d'une personne qualifiée, et non de celle d'un homme du business, qui peut définir l'objectif commercial visé mais ne possède pas les compétences nécessaires pour spécifier les modifications structurelles et fonctionnelles requises pour sa mise en œuvre.

Les caractéristiques 1) à 3) étant considérées comme contribuant au caractère technique de l'invention, la Chambre a estimé qu'elles constituent un système alternatif de transaction en ligne dans lequel les données de carte de paiement de l'utilisateur ne sont pas partagées avec le commerçant. La Chambre a également estimé qu'il n'y avait aucune raison apparente, au vu des autres documents cités, hormis a posteriori, de modifier la fonctionnalité du dispositif utilisateur pour qu'il agisse comme un terminal de point de vente (TPV) effectuant directement la transaction.

La décision de rejet de la division d'examen a donc été infirmé et l’objet de la revendication 1 a été considéré comme inventif par la Chambre de Recours.

Cette décision illustre l'approche « CardinalCommerce » des Chambres de recours de l'OEB en matière d'invention mixte relative aux méthodes d’affaires. Comme dans certaines affaires précédentes, telles par exemple la décision CardinalCommerce T1463/11 elle-même, ou la décision T1749/14, une décision de la division d'examen rejetant une demande de brevet européen qui aurait prétendument porté sur un schéma commercial non brevetable a été annulée grâce à une distinction précise entre les caractéristiques relatives à la définition d'un besoin commercial et les caractéristiques techniques.

Cette décision rappelle ainsi aux déposants que les inventions relatives à des méthodes d’affaires peuvent être admises par l'OEB si elles concernent la mise en œuvre technique d'un concept commercial non suggéré par l'état de la technique.