T 2042/17 (Méthode et système d'amélioration des systèmes d'encaissement/ONEY BANK) 12-10-2021
Téléchargement et informations complémentaires:
METHODE ET SYSTEME D'AMELIORATION DES SYSTEMES D'ENCAISSEMENT
Activité inventive - module de liaison (non
Activité inventive - combinaison évidente de caractéristiques connues)
Revendications (requêtes subsidiaires 6 à 8
Revendications - clarté (non)
I. La requérante conteste la décision de la division d'examen de l'Office européen de brevets rejetant la demande de brevet européen no. 13728475.8.
II. La division d'examen a estimé dans sa décision que la revendication 1 de la requête principale, dans sa version initiale, ne présente pas d'activité inventive selon l'article 56 CBE, car il n'est pas possible de formuler de problème technique à résoudre.
Dans cette décision, la division a fait référence aux documents suivants:
D1 ARTS mobile Integration White Paper,
Version 1.0, 9 août 2012
D2 Auto Port on to OPOS (OLE for POS) for those
POS application that drive peripherals using
direct I/O, IP.COM JOURNAL, 29 novembre 2011
III. La requérante demande que la décision entreprise soit annulée et qu'un brevet soit délivré sur base de la requête principale déposée avec le mémoire de recours en date du 7 Août 2017, ou de l'une des huit requêtes subsidiaires déposées en même temps.
IV. Dans sa convocation à une procédure orale, la chambre a émis son avis provisoire sur l'affaire, à savoir que la revendication 1 de toutes les requêtes n'est pas conforme à l'article 123(2) CBE, que la revendication 1 de la requête principale et des requêtes subsidiaires 1 à 5 n'implique pas d'activité inventive et que la revendication 1 des requêtes subsidiaires 6 à 8 n'est pas claire.
En application de l'article 114(1) CBE, la chambre a introduit les documents D5 (MCS Montroe Consulting Services, OPOS Background, impression des pages web, pages 1 et 2, 2009-12-31) et D6 (WO2004/114056).
V. En réponse, la requérante a indiqué qu'elle n'assisterait pas à la procédure orale. Il n'y a pas eu d'autres commentaires.
VI. Par notification en date du 14 octobre 2021, la requérante a été informée que la procédure orale était annulée et la chambre rendrait sa décision par écrit.
VII. La revendication 1 de la requête principale est formulée comme suit:
"Méthode de mise à jour d'un système d'encaissement (10) incluant un programme d'encaissement (1) configuré pour interagir avec au moins un périphérique (4) de caisse sous le contrôle d'un module de contrôle (5), ladite méthode comprenant
une étape d'inspection, par un module de liaison (7), au niveau du module de contrôle (5), des interactions entre ledit programme d'encaissement (1) et ledit au moins un périphérique (4) de caisse , une étape de simulation d'une ou plusieurs interactions dudit au moins un périphérique (4) de caisse avec ledit programme d'encaissement (1), par le module de liaison (7), en réponse à une requête ;
une étape de traitement de la au moins une interaction simulée par le module de liaison (7), ladite étape de traitement étant choisie dans le groupe incluant la reformulation d'une interaction, la modification d'une interaction, la copie d'une interaction, l'extraction de données à partir d'une interaction, la réorientation d'une interaction."
1. L'invention
1.1 L'invention concerne la mise à jour d'un système d'encaissement tout en maintenant son programme d'encaissement configuré pour interagir avec au moins un périphérique matériel de caisse tel qu'une imprimante de tickets, un afficheur client, une douchette codes-barres, le tiroir-caisse ou un lecteur de cartes bancaires, voir page 1, lignes 20 à 25.
1.2 Cependant, le terme "système d'encaissement" désigne tout système informatisé agencé pour la gestion d'un ou plusieurs points de vente (POS) de produits et de services. Un point de vente peut être, par exemple, un hôtel, un restaurant, une boulangerie, voir page 1, lignes 11 à 19. Un programme d'encaissement gère une pluralité d'opérations, par exemple l'identification et l'enregistrement des articles à encaisser, l'infor-mation client, la gestion du paiement, voir page 1, ligne 26 à page 2, ligne 7. Ils existent selon la demande, sous la forme de différents systèmes d'exploitation et selon différentes normes de communication avec les périphériques de caisse,
comme les normes OPOS, UPOS ou JavaPOS.
1.3 Avec le temps, un programme d'encaissement doit être mis à jour sur base des avancées technologiques les plus récentes, voir page 2, lignes 12 et suivantes et doit être adapté pour intégrer de nouveaux périphériques de caisse, voir page 3, lignes 8 et suivantes ou pour répondre à un changement de stratégie commerciale d'un point de vente, voir page 3, lignes 22 et suivantes. La mise à jour d'un tel programme, notamment déployé dans de nombreuses caisses, ne peut être que fastidieuse et très coûteuse.
1.4 L'invention a pour but de pouvoir améliorer (upgrade) un système d'encaissement tout en maintenant son programme d'encaissement le plus léger possible et de lui apporter plus facilement des modifications, voir page 5, lignes 6 et suivantes. La demande mentionne aussi que des objectifs de l'invention sont de réduire les coûts, page 5, lignes 6 à 17 et éviter des interruptions de vente, page 4, ligne 13 à 30, mais ces problèmes sont plutôt de nature non-technique.
1.5 La solution proposée par l'invention est un module de liaison qui permet plusieurs opérations, voir page 8, lignes 16 à 26. Ce module inspecte (scrute/sonde) au niveau du module de contrôle les interactions entre le programme d'encaissement et les périphériques de caisse, et il "simule" un périphérique dans ses interactions (réponse/requête). Le module de liaison interagit également avec une application tierce, voir page 9, lignes 15 et suivantes, qui peut être une application annexée au système d'encaissement, une borne de paiement mobile ou une application de vérification du programme d'encaissement.
Cependant, la description ne contient pas les détails techniques de ces fonctions. On apprend seulement, voir page 7, ligne 32 à page 8, ligne 2, que le module de liaison inspecte des interactions, les traite et les "simule" mais on n'aperçoit pas comment ceci est réalisé et surtout de quelles interactions il s'agit. Ces interactions semblent intervenir entre ledit programme d'encaissement et ledit au moins un périphérique de caisse et transiter par un module de contrôle qui n'est pas décrit dans la demande. On pourrait déduire du modèle OPOS qui semble être la base de l'invention, voir page 7, deuxième et troisième paragraphes, que les interactions en question correspondent à un échange d'événements et de propriétés grâce à des objets SO et CO, voir figure 1, connus du modèle OPOS. Ceci pourrait expliquer comment l'étape d'inspection peut être réalisée, mais pas nécessairement comment les étapes de traitement et de simulation sont réalisées, car la description reste très abstraite et générique, comme la division d'examen l'avait noté, voir point 1.2 de la décision entreprise.
2. La requête principale
2.1 La revendication 1 est une combinaison des revendica-tions 1 et 2 de la requête principale antérieure. Elle définit une méthode de mise à jour d'un système d'encaissement, incluant un programme d'encaissement configuré pour interagir avec au moins un périphérique de caisse, sous le contrôle d'un module de contrôle. La revendication comprend dorénavant également une étape de simulation d'une interaction.
Article 123(2) CBE
2.2 La corrélation entre l'étape de simulation et l'étape de traitement dans la revendication 1 ne trouve pas de fondement dans la demande telle que déposée.
2.3 La demande, page 6, deuxième paragraphe, divulgue une suite de deux étapes, l'inspection des interactions et ensuite le traitement d'au moins une interaction inspectée. L'étape de simulation est mentionnée dans le paragraphe suivant, voir page 6, troisième paragraphe, mais elle est indépendante des deux étapes précédentes.
2.4 Cette combinaison de caractéristiques se trouve dans la revendication 1 de toutes les requêtes, qui ne sont donc pas conformes à l'article 123(2) CBE.
Article 56 CBE
2.5 La division d'examen avait invoqué que l'infrastructure selon la revendication 1 sous forme d'un système d'encaissement, d'un périphérique et d'un module de contrôle est connue de D1 (chapitre 4.10 sur UnifiedPOS) ou de D2 ("POS"). Les deux étapes de la méthode font partie des tâches typiques et routinières de la personne du métier et ne vont pas au-delà de ce qu'elle attendrait. La nature et le contenu des interactions gérées par cette méthode sont abstraits et n'impliquent ni d'effet ni de considérations techniques.
La division d'examen avait conclu que la revendication 1 manquait d'activité inventive (Article 56 CBE) car aucun problème technique à résoudre ne pouvait être formulé.
2.6 La Chambre n'aperçoit à ce stade aucun obstacle à considérer soit D1 soit D2 comme état de la technique le plus proche. Comme il est mentionné dans la demande, page 7, ligne 20 et suivantes, la norme OPOS est un cas particulier de la norme plus générale UPOS, donc la norme OPOS représente l'état de la technique le plus proche. Le modèle OPOS est connu de D2 ou également de D5, obtenu via un lien HTTP cité dans la demande, page 7, lignes 29 à 30.
2.7 En comparant le mode de réalisation de l'invention illustré par la figure 1, sur lequel la revendication 1 semble basée, avec le modèle OPOS, voir la figure en page 2 de D5, la différence entre la revendication 1 et le modèle OPOS est constituée par le module de liaison. Ce module réalise les opérations d'inspection, de traitement et de simulation, voir page 6, deuxième et troisième paragraphe et page 8, troisième paragraphe, de la demande. Ce module de liaison, externe au système d'encaissement, effectue une supervision du bon fonctionnement du système d'encaissement, sans perturber ce dernier.
2.8 Le problème objectif peut être formulé comme étant la manière de garantir le bon fonctionnement du système d'encaissement sans le perturber dans son utilisation quotidienne.
2.9 La supervision du bon fonctionnement d'un système technique est une tâche courante dans le domaine de l'informatique. Le bon fonctionnement d'un système dépend de son programme de contrôle, comme le système d'exploitation, mais aussi généralement des autres programmes installés. Il est également connu que ces programmes sont régulièrement mis à jour et pour assurer le bon fonctionnement d'un système, des tests sont nécessaires, notamment des tests ou simulations des programmes avant leur déploiement et après leur installation dans le système final. Ceci implique normalement également une supervision du fonctionnement du système. Dans le domaine des systèmes d'encaissement, il est connu que le fonctionnement du système dépend de son programme d'encaissement ainsi que de ses interactions avec les périphériques de caisse connectés, voir page 1, lignes 20 à 25 de la demande.
2.10 Pour superviser un tel système déjà opérationnel dans un point de vente, la personne du métier dispose généralement de deux options, soit elle déconnecte le système d'encaissement de son point de vente et le teste, soit elle le laisse en place et utilise un module externe pour le tester. Dans les deux cas l'on souhaite s'assurer du bon fonctionnement du système, c'est-à-dire des interactions de ce système avec le ou les périphériques. Ce module doit être pourvu des interfaces nécessaires pour interagir avec le système d'encaissement et des fonctions nécessaires pour tester le bon fonctionnement de ce système.
2.11 La Chambre partage donc l'avis de la division d'examen selon lequel les fonctions d'inspection et de traitement, au niveau d'abstraction et générique selon lequel elles sont définies dans la demande, sont notoires pour la personne du métier, voir point 1.4 de la décision.
2.12 Le même argument s'applique selon la Chambre également à l'étape de "simulation", si l'on donne une interprétation technique à cette caractéristique, comme l'avait défendu la requérante qui avait d'ailleurs evoqué que cette étape n'est pas une tâche typique et routinière mise en oeuvre par la personne du métier mais simule une interaction entre le périphérique de caisse et le programme d'encaissement, ce qui évite une manipulation directe d'un système d'encaissement quand on vérifie automatiquement le programme d'encaissement.
2.13 Premièrement, la simulation est une opération commune qui est généralement connue dans le domaine de l'infor-matique pour tester le bon fonctionnement de systèmes. Cependant, la manière abstraite et générique de définir la simulation des interactions dans la revendication 1 (et aussi dans la demande) ne permet pas à la Chambre d'identifier une quelconque spécificité technique différente du simple concept de simulation généralement connu. La personne du métier effectuerait la simulation d'une telle façon qu'elle puisse garantir le bon fonctionnement du système, selon les interaction à tester, les périphériques connectés, etc.
2.14 Deuxièmement, D2 divulgue un outil pour tester le comportement des applications POS avec différents pilotes, voir page 2, dernier paragraphe à page 3. L'outil écoute sur un port sériel pour recevoir des données et il les interprète afin de pouvoir simuler des commandes OPOS d'un périphérique.
2.15 La Chambre estime donc que la revendication 1 ne présente pas d'activité inventive par rapport au modèle OPOS tel que connu de la demande ou de D5, en combinaison avec les connaissances notoires de la personne du métier ou avec D2.
3. Requêtes subsidiaires
3.1 La revendication 1 de la requête subsidiaire 1 est une combinaison des revendications 1 et 2 de la requête principale auxquelles est ajoutée une application tierce à laquelle est communiquée au moins une information concernant une interaction et qui transmet une requête au module de liaison - "l'application tierce".
La revendication 1 de la requête subsidiaire 2 est basée sur la revendication 1 de la requête subsidiaire 1 et y ajoute que l'application tierce est une borne de paiement mobile - "borne de paiement mobile".
La requête subsidiaire 3 correspond à la requête principale sans les revendications 1-2 et 8. Elle comprend uniquement des revendications de système.
La requête subsidiaire 4 correspond à la requête subsidiaire 1 sans les revendications 1 et 6. Elle comprend uniquement des revendications de système - "l'application tierce".
La requête subsidiaire 5 correspond à la requête subsidiaire 3 sans les revendications 1 et 5. Elle comprend uniquement des revendications de système - "borne de paiement mobile".
La revendication 1 de la requête subsidiaire 6 est une combinaison des revendications 8 et 1 de la requête principale.
La revendication 1 de la requête subsidiaire 7 est une combinaison des revendications 6 et 1 de la requête subsidiaire 1 - "l'application tierce".
La revendication 1 de la requête subsidiaire 8 est une combinaison des revendications 5 et 1 de la requête subsidiaire 2 - "borne de paiement mobile".
Article 123(2) CBE
3.2 L'introduction d'une "application tierce" à laquelle est communiquée au moins une information concernant une interaction et qui transmet une requête au module de liaison, ne trouve pas de fondement dans la demande telle que déposée, en violation de l'article 123(2) CBE. L'application tierce est divulguée en page 9, lignes 15 et suivantes. Elle peut entretenir deux interactions alternatives ("ou") avec le module de liaison, à savoir que soit le module de liaison lui fait parvenir des informations concernant des interactions, soit l'application tierce lui fait parvenir une requête, mais pas la combinaison de ces deux interactions.
Cette caractéristique se trouve dans les revendications indépendantes de toutes les requêtes subsidiaires, qui ne sont donc pas conformes à l'article 123(2) CBE.
Article 56 CBE
3.3 La caractéristique "application tierce" est à interpréter selon la page 9, lignes 15 et suivantes de la demande. Elle est définie comme "toute application offrant des fonctionnalités non prévues par le programme d'encaissement". La Chambre l'interprète donc au sens large.
Une application tierce est connue de D1. D1, section 5, décrit plusieurs exemples de l'application du modèle OPOS, notamment pour des coupons mobiles (section 5.1) et le paiement sans contact (section 5.3). L'application tierce dans ces deux exemples peut être un portefeuille électronique, une application de paiement mobile, une application de coupons etc., voir page 33 et page 47, section "Mobile" dans "Actor Definitions", "Step 1" dans "Process Definitions" et "Step 3" à "Step 7" dans "Process Definitions" en page 49. Cette application tierce selon D1 est en interaction avec le système d'encaissement.
Pour superviser le bon fonctionnement d'un système d'encaissement en interaction avec une application tierce, la personne du métier dispose de connaissances générales dans le domaine de l'informatique selon lesquelles elle doit non seulement superviser les interactions du programme d'encaissement avec le ou les périphériques mais aussi les interactions du système d'encaissement avec l'application tierce avec laquelle le système est en communication.
3.4 Les revendications 1 et 2 des requêtes subsidiaires 1 et 2 ne présentent donc pas d'activité inventive. Le même raisonnement s'applique aux revendications indépendantes des autres requêtes subsidiaires 3 à 5 qui ne présentent donc pas non plus d'activité inventive.
Article 84 CBE
3.5 La revendication 1 des requêtes subsidiaires 6 à 8 manque de clarté (Article 84 CBE) car il n'est pas clair de savoir comment un produit consistant en un programme d'ordinateur chargé sur un support mémoire peut être mis en oeuvre au sein d'une unité de traitement informatique et dan le même temps comprendre des instructions de mise en oeuvre des étapes d'inspection, de simulation et de traitement. La Chambre interprète le produit constant en un programme ordinateur en tant que programme d'une unité centrale de traitement (CPU) comprise dans chaque système informatique et donc notoire.
Par ces motifs, il est statué comme suit
Le recours est rejeté.