T 1460/17 () of 2.9.2021

European Case Law Identifier: ECLI:EP:BA:2021:T146017.20210902
Date de la décision : 02 Septembre 2021
Numéro de l'affaire : T 1460/17
Numéro de la demande : 04767533.5
Classe de la CIB : G07F 19/00
Langue de la procédure : FR
Distribution : D
Téléchargement et informations
complémentaires :
Texte de la décision en FR (PDF, 401 KB)
Les documents concernant la procédure de recours sont disponibles dans le Registre
Informations bibliographiques disponibles en : FR
Versions : Unpublished
Titre de la demande : PROCEDE ET SYSTEME DE PAIEMENT ELECTRONIQUE UNIVERSEL
Nom du demandeur : ORANGE
Nom de l'opposant : -
Chambre : 3.4.03
Sommaire : -
Dispositions juridiques pertinentes :
European Patent Convention Art 123(2)
European Patent Convention 1973 Art 56
European Patent Convention 1973 Art 84
Mot-clé : Revendications - clarté
Revendications - requête principale (non)
Modifications - extension de l'objet de la demande
Modifications - requête principale (oui)
Activité inventive - requêtes subsidiaires (non)
Exergue :

-

Décisions citées :
-
Décisions dans lesquelles
la présente décision est citée :
-

Exposé des faits et conclusions

I. Le recours concerne la décision de la division d'examen par laquelle la demande de brevet européen No. 04 767 533.5 (publiée en tant que demande internationale sous le numéro WO 2006/010800 A1) a été rejetée.

Selon la décision attaquée, l'objet des revendications de la seule requête alors en instance n'impliquait aucune activité inventive (article 56 CBE).

II. Il est fait référence aux documents suivants :

D11 : US 2003/0052162 A1 ;

D12 : US 2004/0117623 A1.

III. À la fin de la procédure orale devant la chambre qui a eu lieu par visioconférence à la requête du requérant, le requérant (demandeur) a demandé l'annulation de la décision attaquée et la délivrance d'un brevet conformément à la requête principale ou à une première requête auxiliaire, telles que déposées avec le mémoire de recours, ou sur la base d'une seconde requête auxiliaire présentée avec la lettre du 29 juillet 2021.

IV. La revendication 1 de la requête principale s'énonce comme suit :

Procédé de paiement électronique entre un terminal multimédia et un système distant gestionnaire de paiements, caractérisé en ce qu'il consiste à :

- télécharger un proxy de paiement constitué d'un logiciel d'application sur ledit terminal multimédia, un code du logiciel d'application étant signé pour obtenir une signature, ledit terminal comprenant un module de sécurité comprenant des ressources cryptographiques pour vérifier ladite signature, ledit proxy de paiement étant contrôlé par ledit système distant;

- lorsque la signature est vérifiée intègre par le module de sécurité, installer ledit proxy de paiement sur le terminal multimédia ;

- transmettre au proxy de paiement un ordre de paiement, en provenance d'au moins une application multimédia hébergée par ledit terminal multimédia ;

- discriminer, au niveau dudit proxy de paiement, ledit ordre de paiement sur critère spécifique de traitement local respectivement distant de cet ordre de paiement, dans lequel le critère spécifique est fonction de la présence respectivement l'absence de la couverture réseau;

- procéder à un paiement selon un mode de paiement local de cet ordre de paiement au niveau dudit proxy de paiement sur critère spécifique de traitement local retenu de cet ordre de paiement ; sinon,

- transmettre au moins ledit ordre de paiement audit système distant, pour procéder à un paiement, selon un mode de traitement distant.

V. Les revendications dépendantes 2 et 3 de la requête principale s'énoncent comme suit :

2. Procédé de paiement électronique selon la revendication 1, caractérisé en ce que l'étape consistant à discriminer ledit ordre de paiement sur critère spécifique de traitement local respectivement distant de cet ordre de paiement est définie à partir d'une pluralité de types de paiement exécutés par ledit proxy.

3. Procédé selon la revendication 2, caractérisé en ce que ledit proxy est apte à exécuter au moins :

- le paiement de proximité ;

- le paiement interne ;

- le télépaiement.

VI. La revendication 1 de la première requête auxiliaire s'énonce comme suit (différences par rapport à la revendication 1 de la requête principale rayées/soulignées par la chambre):

Procédé de paiement électronique entre un terminal multimédia et un système distant gestionnaire de paiements, caractérisé en ce qu'il consiste à :

- télécharger un proxy de paiement constitué d'un logiciel d'application sur ledit terminal multimédia, un code du logiciel d'application étant signé pour obtenir une signature, ledit terminal comprenant un module de sécurité comprenant des ressources cryptographiques pour vérifier ladite signature, ledit proxy de paiement étant contrôlé par ledit système distant;

- lorsque la signature est vérifiée intègre par le module de sécurité, installer ledit proxy de paiement sur le terminal multimédia en coupure de façon à intercepter tout ordre de paiement émis à destination du système distant;

- transmettre au proxy de paiement un ordre de paiement, en provenance d'au moins une application multimédia hébergée par ledit terminal multimédia ;

- discriminer, au niveau dudit proxy de paiement, ledit ordre de paiement sur critère spécifique de traitement local respectivement distant de cet ordre de paiement[deleted: , dans lequel le critère spécifique est fonction de la présence respectivement l'absence de la couverture réseau] ;

- procéder à un paiement selon un mode de paiement local de cet ordre de paiement au niveau dudit proxy de paiement sur critère spécifique de traitement local retenu de cet ordre de paiement ; sinon,

- transmettre au moins ledit ordre de paiement audit système distant, pour procéder à un paiement, selon un mode de traitement distant.

VII. La revendication 1 de la seconde requête auxiliaire est identique à la revendication 1 de la requête principale. Les deux requêtes se distinguent par le fait que dans la seconde requête auxiliaire, les revendications dépendantes 2 et 3 ont été supprimées.

VIII. Le requérant a essentiellement fait valoir que le terminal selon D11 n'effectue aucun traitement local sécurisé des ordres de paiement mais seulement une transmission différée de ceux-ci. Les arguments du requérant sont traités en détail dans les motifs de la décision.

Motifs de la décision

1. Le recours est recevable.

2. L'invention revendiquée

L'invention concerne un procédé et un système de paiement électronique.

2.1 Les systèmes et procédés de paiement électronique d'accès à un service au moyen d'un terminal de téléphonie mobile sont connus dans l'état de la technique. Afin d'exécuter un ordre de paiement, un tel terminal mobile se connecte à un système distant qui gère des ressources financières de l'utilisateur (une banque par exemple).

Parmi les modes de paiement envisageables, on distingue le télépaiement, le paiement à proximité et le paiement interne. Dans un télépaiement, le terminal se connecte au système distant, qui exécute les étapes nécessaires de la transaction de paiement. Un paiement interne est effectué localement dans le terminal même, qui possède les ressources nécessaires. Dans un paiement à proximité, le terminal communique avec un autre terminal de paiement qui se trouve à proximité (par rapport à un système distant). Dans l'état de la technique, ces types de paiement différents sont traités dans des mises en oeuvre indépendantes et partielles (voir page 1, ligne 1 à page 2, ligne 20 de la demande publiée).

2.2 La demande propose une mise en oeuvre d'un procédé et d'un système de paiement électronique universel, qui puisse effectuer des paiements de tout type.

L'invention propose un terminal qui est doté des ressources pour qu'il puisse effectuer des paiements des types décrits ci-dessus, à savoir télépaiement, paiement interne et paiement à proximité. Les paiements peuvent être effectués en mode local (sans connexion au système distant) ou en mode distant (avec connexion au système distant). Le terminal comporte un logiciel (proxy de paiement), qui, quand il reçoit un ordre de paiement, effectue une série de tests pour déterminer quel mode et quel type de paiement vont être utilisés (voir page 2, lignes 21 à 31).

2.3 Selon la revendication 1 de la requête principale, un tel test (critère spécifique) peut être l'existence ou l'absence de couverture réseau. Si un réseau de communication au système distant n'est pas disponible, l'ordre de paiement est exécuté en mode local. Un autre critère peut être le type de paiement. Un paiement interne, par exemple, est toujours exécuté en mode local (voir page 8, ligne 23 à page 9, ligne 34).

3. Requête principale

3.1 Clarté et étendue de l'objet de la demande (articles 84 CBE 1973 et 123(2) CBE)

3.1.1 Selon la revendication 1 de la requête principale, le critère spécifique de traitement local ou distant de l'ordre de paiement est fonction de la présence respectivement l'absence de la couverture réseau.

3.1.2 Selon la revendication 2, qui dépend de la revendication 1, l'étape consistant à discriminer ledit ordre de paiement sur critère spécifique de traitement local respectivement distant de cet ordre de paiement est définie à partir d'une pluralité de types de paiement par ledit proxy.

La revendication 3, qui dépend de la revendication 2, définit plusieurs types de paiement.

3.1.3 Selon la revendication 1, le critère spécifique utilisé pour déterminer si un ordre de paiement va être traité comme paiement local ou distant est fonction de la présence ou de l'absence de la couverture réseau. Mais selon la revendication 2, cette discrimination est définie à partir d'une pluralité de types de paiement que le proxy pourrait exécuter.

Comme la revendication 2 comporte toutes les caractéristiques de la revendication 1, puisqu'elle en dépend (règle 43(4) CBE), on ne sait pas clairement sur quel critère spécifique le proxy de paiement décide (discrimine) de procéder à un traitement local ou distant d'un ordre de paiement reçu : ce choix est-il fonction de la présence ou de l'absence de la couverture réseau ou est-il effectué à partir d'une pluralité de types de paiement? La chambre constate donc que la revendication 2 de la requête principale manque de clarté (article 84 CBE 1973).

3.1.4 De plus, la combinaison des caractéristiques des trois revendications (1, 2 et 3) introduit des modes de réalisation de l'invention qui n'étaient pas envisagés dans la demande telle que déposée.

Si l'on considère que les critères de discrimination définis dans les revendications 1 et 2 s'accumulent, le proxy va prendre une première décision de traiter un ordre de paiement localement ou à distance selon la présence ou non de la couverture réseau. Ensuite, il va exécuter le paiement selon le type de paiement, à savoir paiement à proximité, paiement interne ou télépaiement (voir la revendication 3 de la requête principale et page 8, ligne 23 à page 9, ligne 4 de la demande publiée).

Selon cette définition, un ordre de paiement de tout type peut être traité comme paiement local ou distant en fonction de la disponibilité du réseau.

3.1.5 Or, selon la description de la demande telle que déposée, la discrimination par le proxy du type de paiement se fait avant de contrôler la disponibilité du réseau et non pas après (voir page 9, lignes 5 à 34 et figure 2b de la demande publiée).

De plus, un paiement interne (type de paiement T2) est toujours traité localement et indépendamment de la disponibilité (couverture) du réseau (voir page 8, lignes 30 à 32 et figure 2b), contrairement à la définition des revendications 1 et 2 selon laquelle, si la couverture réseau est disponible, tout ordre de paiement est traité en mode distant.

3.1.6 Le requérant n'a pas avancé d'arguments contraires pour réfuter ces constatations de la chambre.

3.1.7 Par conséquent, la chambre conclut que la requête principale ne remplit pas les exigences de l'article 123(2) CBE parce que son objet s'étend au-delà du contenu de la demande telle qu'elle a été déposée ni celles de l'article 84 CBE 1973 parce que la revendication 2 n'est pas claire.

4. Première requête auxiliaire

4.1 La revendication 1 de la première requête auxiliaire ne comporte pas la caractéristique selon laquelle le critère spécifique est fonction de la présence ou de l'absence de la couverture réseau. La chambre est convaincue que la requête répond aux exigences des articles 84 CBE 1973 et 123(2) CBE.

4.2 Activité inventive (article 56 CBE 1973)

4.2.1 Il est incontesté que le document D11 représente l'état de la technique le plus proche.

D11 décrit un terminal mobile de paiements (voir figure 1 et le paragraphe [0019]). Le terminal émet des messages de paiement ("payment messages"), lesquels sont envoyés à un service financier (une banque par exemple) distant par un programme de transmission ("transmission program" 12). Cette transmission peut se faire en deux modes différents: soit en utilisant un réseau de téléphonie mobile, soit à travers le réseau téléphonique public (voir le paragraphe [0012]). Un circuit dédié dans le terminal sélectionne le mode de transmission selon des critères prédéfinis ("selection circuit" 22, voir le paragraphe [0023]).

Le terminal détermine d'abord si une transmission immédiate du message de paiement est nécessaire ou non. Cette décision pourrait être fonction du montant du paiement, par exemple (voir le paragraphe [0025]). Dans d'autres cas, la transmission immédiate pourrait être forcée ou préférée (voir les paragraphes [0027] et [0029]). Dans le cas où la transmission immédiate n'est pas nécessaire, le message de paiement est stocké localement dans le terminal. La transaction avec l'utilisateur/débiteur (celui qui effectue le paiement) est complétée et un reçu est même imprimé (voir le paragraphe [0026]). Selon D11, l'utilisateur ne s'aperçoit pas que le message de paiement n'est pas envoyé à la banque distante. Dans ces cas, les messages de paiement stockés dans le terminal sont transmis à la banque de façon différée, à d'autres moments, par exemple pendant la nuit (voir le paragraphe [0026]).

Dans le cas où la transmission immédiate du message de paiement est considérée comme nécessaire, le terminal choisit entre les deux modes de transmission possibles (voir le paragraphe [0028]). Une façon de décider est de contrôler si la transmission à travers le réseau téléphonique public est possible. Dans ce cas, le terminal cherche à déterminer si une "base" connectée au réseau de téléphonie publique est disponible. S'il n'en trouve pas, il transmet le(s) message(s) de paiement à travers le réseau de téléphonie mobile (voir le paragraphe [0030]).

4.2.2 Le requérant a fait valoir que le terminal de paiement de D11 ne comporte pas un proxy de paiement selon les revendications (voir par exemple le dernier paragraphe de la page 2 au premier paragraphe de la page 4 du mémoire de recours).

De plus, le terminal de D11 ne prévoit pas de mettre en place un paiement local sécurisé si le critère spécifique de traitement local est rempli. Selon le requérant, le terminal de D11 stocke seulement les ordres de paiement ("payment messages") pour les envoyer au système distant à un moment ultérieur. Les ordres de paiement ne sont pas traités dans/par le terminal, par exemple aucun contrôle de solvabilité du débiteur n'est effectué. Le débiteur reçoit un reçu avec la somme à payer, mais le marchand n'est pas certain qu'il pourra recevoir l'argent car la solvabilité du débiteur n'a pas été confirmée et le paiement n'a pas été validé par le système distant (la banque). Les ordres de paiement sont traités par le système distant quand ils y sont transmis. Il ne s'agit donc pas d'un paiement local mais d'un télépaiement différé.

En revanche, dans le terminal selon l'invention revendiquée, les ordres de paiement sont traités par le terminal lui-même en cas de paiement local. On en conclut donc que le terminal possède toutes les informations nécessaires pour contrôler et valider un ordre de paiement et que, à la fin de la transaction de paiement, un marchand pourra être certain de recevoir la somme d'argent due. Même dans le cas d'une transmission ultérieure des ordres de paiement au système distant, les ordres seront déjà traités et le système distant n'aurait qu'à les enregistrer.

D11 ne divulgue donc pas un paiement local au sens de l'invention revendiquée.

4.2.3 La chambre n'est pas convaincue par ces arguments.

En ce qui concerne le proxy de paiement, la chambre considère que le terminal de D11 comprend un logiciel qui effectue les fonctions d'une application proxy comme celle selon la demande. Le proxy de paiement selon la demande est constitué d'un logiciel d'application qui permet de réaliser la fonction de serveur mandataire dans les conditions de discrimination du mode de traitement local ou distant, tel que décrit dans la description et les figures 2a et 2b (voir page 14, lignes 18 à 22 de la demande publiée). Le proxy de paiement effectue les opérations nécessaires à une transaction de paiement de la même façon que le système distant, de sorte que l'utilisateur ne s'aperçoit pas si la transaction se déroule dans le terminal ou dans le système distant.

La chambre considère que le logiciel du terminal selon D11 offre les mêmes fonctionnalités, comme expliqué ci-dessus (voir point 4.2.1).

Dans ce contexte, la chambre note que, selon la revendication 1, le proxy de paiement est contrôlé par le système distant. Or, la demande n'indique pas de quel type de contrôle il s'agit ou comment exactement le système distant contrôle le proxy de paiement installé dans le terminal.

La chambre ne voit pas comment le système distant peut contrôler le proxy de paiement installé dans le terminal, puisque le terminal n'est pas constamment connecté au système distant. Le proxy de paiement peut effectuer les démarches d'une transaction de paiement de la même façon que le système distant ou présenter à l'utilisateur un environnement virtuel identique à celui du système distant, mais la chambre ne considère pas que ceci constitue un contrôle du proxy par le système distant. Elle considère donc que le logiciel du terminal D11 est "contrôlé" par le système distant correspondant de la même façon que le proxy de la revendication 1 de la première requête auxiliaire.

4.2.4 Quand au paiement local, la chambre note tout d'abord que ni les revendications ni la demande ne contiennent de détails sur le traitement des ordres de paiement. Le requérant fait valoir que "traiter" un ordre de paiement signifie que toutes les démarches nécessaires pour effectuer une transaction de paiement sont effectuées dans/par le terminal et que, à la fin du traitement, le paiement est validé. La chambre ne peut pas accepter cette interprétation. Outre l'absence totale d'informations sur le traitement des ordres de paiement dans la demande, il semble peu probable que le terminal puisse disposer préalablement de toutes les informations nécessaires sur tous les clients (débiteurs) potentiels afin de contrôler leur solvabilité et valider tout ordre de paiement reçu. Une connexion avec le système distant est toujours nécessaire, même dans le cas d'un paiement local (voir, par exemple, les dernières lignes de la page 7, page 8, lignes 10 à 12 ou page 9, lignes 22 à 25 de la demande publiée).

D11, comme la demande, ne donne pas de détails sur le déroulement de la transaction de paiement dans le terminal. La chambre considère donc que la divulgation de D11 sur le traitement des ordres de paiement doit être interprétée de la même façon que celle de la demande. Selon D11, dans le cas d'un paiement local, la transaction de paiement est complétée dans/par le terminal et un reçu pour l'utilisateur est émis de telle façon que l'utilisateur ne s'aperçoit pas que son ordre de paiement a été traité localement et non par le système distant (voir le paragraphe [0026] de D11). L'interprétation du requérant selon laquelle l'ordre de paiement n'est pas validé et le marchand n'est pas certain de recevoir son argent ne découle pas de ce passage. Autrement dit, si on considère que la description du traitement local de l'ordre de paiement dans la demande implique une validation du paiement, on doit accepter que cela est aussi valable pour celle de D11. En l'absence de détails dans les deux cas, les divulgations correspondantes devraient être interprétées de la même façon. Pour la chambre, rien n'indique que le traitement local de l'ordre de paiement par le terminal selon D11 est différent de celui selon les revendications et la demande.

4.2.5 Le requérant a fait aussi valoir que dans le cas de l'utilisation d'un porte-monnaie virtuel, aucune connexion au système distant n'est nécessaire. Dans un porte-monnaie électronique local (c.-à-d. stocké dans le terminal), un solde est préalablement chargé et, pendant le déroulement d'une transaction de paiement local, aucune connexion au système distant n'est nécessaire. Les connexions périodiques au système distant pour recharger le solde du porte-monnaie électronique sont indépendantes du traitement des ordres de paiement (voir aussi page 24, ligne 29 à page 25, ligne 27 de la demande publiée). D11 ne fait aucune allusion à un porte-monnaie électronique et ne prévoit pas de traitement local des ordres de paiement sans aucune connexion au système distant.

4.2.6 La chambre est d'accord avec le requérant sur le fait que dans le cas d'une paiement par porte-monnaie virtuel, aucune connexion au système distant n'est nécessaire. En revanche, la chambre note qu'aucune limitation à un paiement par porte-monnaie virtuel n'est présente dans les revendications de la première requête auxiliaire. Le définition générale d'un ordre de paiement et d'un traitement local d'un ordre de paiement dans la revendication 1 de la première requête auxiliaire comprend tous le moyens de paiement décrits dans la demande et on ne peut pas limiter l'interprétation de ces termes à une variante spécifique décrite dans la demande sans aucune référence correspondante dans les revendications.

La chambre reste donc persuadée que D11 divulgue un traitement local des ordres de paiement selon la revendication 1 de la première requête auxiliaire.

4.2.7 Quant à la caractéristique selon laquelle le proxy de paiement est placé en coupure de façon à intercepter tout ordre de paiement émis à destination du système distant, la chambre considère qu'elle est aussi divulguée dans D11. Il y a lieu de comprendre que dans le terminal de D11, l'ordre de paiement ("payment message") est intercepté par le logiciel qui effectue une série de tests pour déterminer si une transmission immédiate est nécessaire et quel mode de transmission est à utiliser (voir les paragraphes [0025] à [0027]). Le logiciel en question, qui correspond au proxy de paiement comme expliqué précédemment (voir le point 4.2.3 ci-dessus) est donc placé en coupure de la même façon que le proxy de paiement selon la revendication.

4.2.8 Le procédé selon la revendication 1 de la première requête auxiliaire se distingue donc du procédé selon D11 par les caractéristiques suivantes :

- le proxy de paiement est téléchargé dans le terminal et comprend un code qui est signé pour obtenir une signature;

- le terminal comprend un module de sécurité comprenant des ressources cryptographiques pour vérifier ladite signature et si la signature vérifiée est intègre, le proxy est installé sur le terminal.

4.2.9 L'effet technique de ces caractéristiques est l'augmentation de la sécurité puisque l'utilisateur du terminal qui télécharge le logiciel du proxy de paiement peut ainsi vérifier son origine et son intégrité.

L'homme du métier serait donc confronté au problème technique consistant à se demander comment la sécurité du logiciel peut être améliorée dans le terminal de D11.

4.2.10 Le document D12 concerne la sécurité de la transmission des données dans un réseau de communication. Selon D12, une façon d'authentifier un logiciel téléchargé est d'utiliser une signature numérique. En contrôlant l'intégrité de la signature d'un code (logiciel) téléchargé, il est ainsi possible d'authentifier son origine et de vérifier s'il a été corrompu (voir paragraphe [0051]).

4.2.11 La chambre considère que l'homme du métier qui cherche à résoudre le problème technique identifié ci-dessus prendrait D12 en considération.

Le logiciel dans le terminal de D11 devrait y être installé d'une façon ou d'une autre, et le téléchargement est désormais (à la date de priorité de la demande) standard. La chambre considère que l'homme du métier, qui voudrait être sûr de l'origine et de l'intégrité du logiciel installé dans le terminal, préférerait de façon évidente un logiciel avec une signature numérique qui permettrait son authentification. Il est également évident que dans ce cas-là le terminal serait équipé de moyens (ressources) cryptographiques pour pouvoir vérifier l'intégrité de la signature.

4.2.12 Le requérant n'a pas contesté ces conclusions de la chambre.

4.2.13 Il y a donc lieu de conclure que l'objet de la revendication 1 de la première requête auxiliaire n'implique aucune activité inventive selon l'article 56 CBE 1973.

5. Seconde requête auxiliaire

5.1 Avec la suppression des revendications dépendantes 2 et 3, les objections concernant le manque de clarté et l'extension de l'objet au-delà du contenu de la demande telle qu'elle a été déposée, qui ont été levées contre la requête principale (voir point 3 ci-dessus), ont été surmontées. La chambre est donc convaincue que la seconde requête auxiliaire repond aux exigences des articles 84 CBE 1973 et 123(2) CBE.

5.2 Le requérant a basé sa défense de la seconde requête auxiliaire sur les arguments concernant la différence prétendue entre un traitement local d'un ordre paiement selon l'invention et celui selon D11. Ces arguments n'ont pas convaincu la chambre (voir points 4.2.2 et 4.2.4 à 4.2.6 ci-dessus).

5.3 De plus, le requérant a fait valoir que le terminal selon D11 cherche seulement à déterminer quel type de réseau est disponible et non pas si un réseau est disponible ou non. Si le terminal ne trouve aucun réseau, la transaction de paiement s'interrompt et une autre tentative de connexion se fait ultérieurement. Selon le procédé revendiqué, en revanche, en cas d'absence de réseau l'ordre de paiement est traité de façon locale et la transaction de paiement est toujours effectuée.

5.4 La chambre note que selon le procédé décrit dans D11, le mode distant de traitement de l'ordre de paiement peut être imposé ("enforced"). Dans ce cas, le terminal cherche à se connecter au système distant et, s'il n'y arrive pas, la transaction s'interrompt et un message d'échec est affiché (voir les paragraphes [0027] et [0028]). En revanche, si le traitement distant n'est pas imposé, D11 ne donne aucune information sur ce qui se passe si le terminal ne trouve aucun réseau (voir les paragraphes [0029] et [0030]).

La chambre note également que selon D11, le critère spécifique pour décider si le traitement d'un ordre de paiement est local ou distant peut être fonction du montant du paiement ou de la nécessité de vérifier toute opération de paiement (voir le paragraphe [0025]). Si, selon ces critères, le traitement distant est retenu, le terminal cherche à établir quel réseau de communication va être utilisé. La chambre considère que, puisqu'un traitement local avec transmission différée des ordres de paiement est déjà prévu dans le terminal, l'homme du métier arriverait de façon évidente à utiliser ce mode local de traitement des ordres de paiement aussi dans le cas où le terminal ne trouve aucun réseau de communication. D11 indique aussi qu'au sein d'une transmission différée des ordres de paiement stockés, le terminal cherche à nouveau à déterminer quel type de réseau est disponible (voir le paragraphe [0031]). La chambre juge évident que si un réseau n'est pas trouvé, le terminal va tenter de transmettre les ordres des messages ultérieurement. Ceci indique que les ordres de paiement restent stockés dans le terminal jusqu'au moment où un réseau est trouvé et où la connexion au système distant peut être établie.

5.5 La chambre conclut donc que l'objet de la revendication 1 de la seconde requête auxiliaire n'implique elle non plus aucune activité inventive.

6. Aucune des requêtes en instance ne répondant aux exigences de la CBE, le recours doit être rejeté.

Dispositif

Par ces motifs, il est statué comme suit

Le recours est rejeté.

Quick Navigation