European Case Law Identifier: | ECLI:EP:BA:2015:T230810.20151008 | ||||||||
---|---|---|---|---|---|---|---|---|---|
Date de la décision : | 08 Octobre 2015 | ||||||||
Numéro de l'affaire : | T 2308/10 | ||||||||
Numéro de la demande : | 00906418.9 | ||||||||
Classe de la CIB : | G07F 7/10 | ||||||||
Langue de la procédure : | FR | ||||||||
Distribution : | D | ||||||||
Téléchargement et informations complémentaires : |
|
||||||||
Titre de la demande : | SYSTEME EMBARQUE POSSEDANT DES MOYENS D'INTERFACE DE RESEAU, ET PROCEDE D'ACTIVATION D'APPLICATIONS LOCALISEES DANS CE SYSTEME EMBARQUE | ||||||||
Nom du demandeur : | CP8 TECHNOLOGIES | ||||||||
Nom de l'opposant : | - | ||||||||
Chambre : | 3.4.03 | ||||||||
Sommaire : | - | ||||||||
Dispositions juridiques pertinentes : | |||||||||
Mot-clé : | Modifications - extension de l'objet de la demande (non) Activité inventive - (oui) Vice substantiel de procédure - (non) Remboursement de la taxe de recours - (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 présent recours a été formé à l'encontre du rejet de la demande de brevet européen n° 00 906 418 en vertu de l'article 97(2) CBE, car "L'objet de la requête de délivrance de brevet n'est pas conforme aux exigences des Articles 123(2), 52(1) et 56 CBE".
II. Le requérant a demandé l'annulation de la décision de rejet et, comme seule requête, la délivrance d'un brevet dans la version suivante:
- Revendications 1 - 17 produites avec la lettre du 7 octobre 2015
- Description pages 1-5, 7 et 12 - 33 telles que déposées;
- Description pages 6, 10 et 11 produites avec la lettre du 16 juillet 2008 (reçues le 21 juillet 2008);
- Description pages 8 et 9 produites avec la lettre du 8 octobre 2015
- Feuilles de dessins 1/6 à 6/6 telles que déposées.
III. Référence est faite aux documents suivants:
D1: GB 2 326 010 A
D2: WO 98/19237 A1
IV. Le libellé de la revendication 1 est le suivant :
"Procédé d'activation d'au moins une application (A1 - An) localisée dans une carte à puce connectée à un terminal, dit local, muni d'un lecteur de ladite carte à puce, par l'intermédiaire d'un navigateur, caractérisé en ce qu'il comprend au moins les étapes suivantes :
1/ établissement d'une session d'échanges de données entre ledit terminal (1) et ladite carte à puce (2a) de manière à transmettre une requête HTTP pour accéder à l'une desdites applications (Ai), ladite requête étant invoquée par un utilisateur au moyen du navigateur sous forme d'une adresse URL, lors de cette étape chacune des entités (132, 232a1) d'une paire de premières entités logicielles appariées (132, 232a1) coopère l'une avec l'autre de manière à permettre l'établissement de la session d'échanges de données bidirectionnels entre ledit terminal (1) et ladite carte à puce (2a), de manière à ce que ladite carte à puce (2a) offre la fonctionnalité d'un serveur "WEB",
l'une des premières entités logicielles appariées (232a1), dite agent WEB, étant comprise dans une première pièce de logiciel spécifique (23a) implantée dans la carte à puce et formant interface avec au moins les applications (Ai-An) implantées dans la carte à puce,
l'autre des premières entités logicielles appariées (132), dite agent réseau, étant comprise dans une seconde pièce de logiciel spécifique (13) implantée dans le terminal et formant interface avec le navigateur;
2/ réception et analyse de ladite requête HTTP par l'agent WEB afin de détecter, dans la requête, une référence à un répertoire particulier et à l'application particulière (Ai) à accéder, cette référence désignant un script particulier associé à l'application à accéder (Ai) ;
3/ interprétation dudit script par une deuxième entité logiciel (ATSi) implantée dans la carte à puce, dit agent traducteur de script, ledit script étant associé à ladite application à accéder (Ai), pour traduire la requête en une suite d'ordres que l'application à accéder est en mesure de comprendre et transmission de cette suite d'ordres traduits à cette application de manière à l'activer; et
4/ élaboration par l'application activée (Ai) d'une réponse et transmission audit navigateur (10), par l'intermédiaire de ladite deuxième entité logicielle (ATSi), et via lesdites première (13) et seconde (23a) pièces de logiciel spécifiques, de la réponse à ladite requête."
V. Les arguments du requérant qui sont pertinents pour la présente décision peuvent être résumés comme suit :
En ce qui concerne la question de la conformité de la revendication 1 aux exigences de l'article 123(2) CBE, les étapes 1/ à 4/ se basent sur la demande telle que déposée comme suit:
- l'étape 1/ : page 35, lignes 1 à 6; page 34, lignes 7 à 25; page 21, lignes 5 à 8 et page 23, lignes 21 à 28;
- l'étape 2/ : page 25, lignes 8 à 17 et page 35, lignes 9 à 11;
- l'étape 3/ : page 35, lignes 7 à 13; page 7, lignes 27 à 30 et page 26, lignes 15 à 25; et
- l'étape 4/ : l'ancienne étape 3/ de la revendication 1 et page 26 lignes 26 à 29.
En ce qui concerne l'activité inventive, dans les cartes à puce connues, le dialogue entre l'application embarquée dans la carte à puce et le terminal équipé du lecteur de carte à puce doit se faire en utilisant un jeu normalisé d'ordres appelés ordres "APDU". On ne peut accéder aux applications conventionnelles que par ces commandes classiques non compatibles avec le langage HTML du monde WEB. Sinon il faudrait réécrire des applications pour ce langage, ce que l'on ne souhaite pas forcément.
L'invention propose une solution pour qu'un navigateur puisse communiquer avec une application quelconque implantée dans une carte à puce sans avoir à précharger dans le terminal un plug-in spécifique à l'application que l'on souhaite activer.
Afin d'atteindre cet objectif, l'invention propose de prévoir, respectivement dans la carte à puce et dans le terminal, un agent WEB et un agent réseau qui permettent d'établir une session d'échanges de données directionnels entre le terminal et la carte à puce pour que l'agent WEB puisse recevoir une requête d'accès à une application implantée, afin que la carte à puce offre les fonctionnalités d'un serveur WEB.
Aussi présent dans la carte à puce se trouve un agent intelligent traducteur propre à traduire la requête reçue par l'agent WEB en une suite d'ordres exécutables par l'application à accéder.
Ni le document Dl, ni le document D2, ne divulguent un moyen apte à effectuer une passerelle entre le monde carte et le monde réseau. Par conséquent, aucun de ces documents pris en combinaison ou non ne suggère à l'homme du métier un moyen pour lui permettre de faire communiquer un navigateur Web avec une application quelconque embarquée sur une carte à puce sans avoir à utiliser un terminal dédié.
Motifs de la décision
1. Le recours est recevable.
2. Modifications de la demande
2.1 La revendication 1 selon la présente requête a été réécrite, par rapport à la revendication 1 telle que déposée à l'origine, de telle façon que les "phases" qui définissent l'implantation des logiciels soient éliminées. Selon le procédé de la revendication 1 actuelle, ces logiciels sont déjà implantés dans la carte à puce et dans le terminal. La Chambre ne voit aucune raison de soulever une objection au titre de l'article 123(2) CBE à cet égard.
De l'avis de la Chambre, les caractéristiques ajoutées à la version actuelle de la revendication 1 qui n'ont pas de contreparties dans la revendication 1 déposée à l'origine, trouvent une base dans la demande telle que déposée à l'origine (voir en particulier page 22, lignes 13-27; page 23, lignes 21-28 et page 25, lignes 9 à 17).
2.2 La revendication dépendante 2 est basée sur le passage à la page 6, lignes 27 à 34. Les revendications dépendantes 3 à 17 correspondent essentiellement aux revendications 2 à 16 telles que déposées.
2.3 Le jeu de revendications modifiées ainsi que la description adaptée à ce jeu satisfont donc aux dispositions de l'article 123(2) CBE.
3. Activité inventive
3.1 Dans la décision contestée, la division d'examen a décidé de ne citer aucun document mais plutôt d'invoquer l'art antérieur tel qu'exposé dans la description de la demande.
Selon la description (page 11, lignes 9 à 12) "les figures 1A et 1B illustrent schématiquement les architectures matérielles et logiques, respectivement, d'un exemple de système d'application à base de carte à puce selon l'art connu". En décrivant ces figures, la phrase "l'état actuel de la technique" est utilisée (page 6, ligne 16), et il est noté dans la description (page 13, lignes 1 à 5) que à "l'exception de couches logicielles de protocole de communication spécifiques, référencées 13 et 23a, respectivement implantées dans le terminal 1 et la carte à puce 2a, les autres éléments [de la figure 2], matériels ou logiciels, sont communs à l'art connu". Le requérant a aussi désigné la figure 1B comme "art antérieur" dans le mémoire exposant les motifs du recours.
La chambre considère donc que les exemples illustrés aux figures 1A et 1B, ainsi qu'à la figure 2, à l'exception des éléments 13 et 23a, font partie de l'état de la technique au sens de l'article 54(2) CBE 1973, et l'objet divulgué dans ces figures (à l'exception des éléments 13 et 23a) est considéré comme représentant l'art antérieur le plus proche.
3.2 Selon cet art antérieur tel que représenté dans les figures 1A et 1B, les applications présentes sur la carte à puce 2 dialoguent avec le terminal 1 au moyen d'un jeu d'ordres, qui sont typiquement dans le format "APDU" défini par la norme ISO 7816-4 (voir page 4, ligne 30 à page 5, ligne 7).
La carte 3 ne peut communiquer directement avec les navigateurs du commerce, sauf en modifiant le code de ces derniers. Il est donc nécessaire de prévoir une pièce additionnelle de logiciel, implantée dans le terminal 1, généralement sous la forme de ce qui est appelé un "plug-in", qui est indiquée par le signe de référence 12 à la figure 1A (voir page 5, ligne 34 à page 6, ligne 15).
3.3 Le procédé selon la revendication 1 se distingue du procédé selon l'art antérieur le plus proche par au moins les caractéristiques suivantes :
- l'établissement d'une session d'échanges de données entre le terminal et ladite carte à puce de manière à transmettre une requête HTTP pour accéder à l'une des applications, la requête étant invoquée par un utilisateur au moyen du navigateur sous forme d'une adresse URL;
- la session d'échanges bidirectionnels de données entre le terminal et la carte à puce est établie de manière à ce que la carte à puce offre la fonctionnalité d'un serveur "WEB";
- l'établissement de la session d'échanges de données bidirectionnels est permis par une paire de premières entités logicielles appariées coopérant l'une avec l'autre;
- l'une des premières entités logicielles appariées (agent WEB) est comprise dans une première pièce de logiciel spécifique implantée dans la carte à puce et forme une interface avec au moins les applications implantées dans la carte à puce; et
- l'autre entité logicielle des premières entités logicielles appariées (agent réseau) est comprise dans une seconde pièce de logiciel spécifique implantée dans le terminal et forme une interface avec le navigateur;
- la traduction d'un script particulier dans la requête par une deuxième entité logiciel (agent traducteur de script) implantée dans la carte à puce, ledit script étant associé à l'application à accéder, en une suite d'ordres que l'application à accéder est en mesure de comprendre;
- la transmission de cette suite d'ordres traduits à cette application de manière à l'activer.
3.4 Le problème technique à résoudre par la présente invention peut être considéré comme étant l'amélioration du procédé permettant aux cartes à puce de communiquer avec un navigateur, et en particulier d'éviter la nécessité d'utiliser un terminal dédié ou l'implantation d'un plug-in pour chaque application.| |
Les caractéristiques mentionnées ci-dessus permettent de résoudre ce problème d'une manière qui n'est pas prévue dans les documents D1 et D2 cités dans la décision attaquée. De plus, la Chambre est d'avis que cette combinaison de caractéristiques constitue une contribution à l'état de la technique qui va au-delà de ce que l'on peut attendre de l'homme du métier utilisant ses connaissances générales.
3.5 La Chambre partage l'avis de la division d'examen, selon laquelle les modules logiciels ayant pour fonction de permettre à des modules logiciels existants d'interagir, alors que leurs interfaces ne sont pas a priori compatibles, sont connus dans l'art antérieur. Le "plug-in" de l'art antérieur le plus proche est un exemple clair d'un tel module.
Cela ne signifie pas cependant, que le procédé revendiqué, qui utilise des modules ayant une disposition différente et des fonctionnalités différentes par rapport à ceux de l'art antérieur le plus proche afin de résoudre le problème technique, ne pourrait pas impliquer d'activité inventive.
3.6 De plus, l'invention va au-delà de la simple mise en oeuvre de compétences en programmation. A partir de l'état de la technique le plus proche, la solution imposerait une modification du terminal (implantation de l'agent réseau) ainsi que de la carte à puce (implantation de l'agent WEB et de l'agent traducteur de script) et l'utilisation de ces modules pour l'établissement d'une session d'échanges de données entre le terminal et la carte selon la manière revendiquée.
3.7 La Chambre n'a aucun doute que l'homme du métier serait en mesure, après avoir lu la revendication 1 et la description, de mettre en oeuvre l'invention en exerçant ses compétences en programmation. Cependant, la question pertinente eu égard aux exigences d'activité inventive est plutôt de savoir si, pour un homme du métier, l'invention revendiquée découle d'une manière évidente de l'état de la technique.
La Chambre constate qu'il n'y a rien dans l'art antérieur présent dans la procédure qui aurait incité l'homme du métier confronté au problème technique mentionné ci-dessus à concevoir les caractéristiques cités sous point 3.6 ci-dessus.
Le procédé de la revendication 1 implique donc une activité inventive au sens de l'article 52(1) CBE et de l'article 56 CBE 1973.
4. La procédure devant la première instance
4.1 Dans le mémoire exposant les motifs du recours, le requérant s'est plaint que la procédure orale se soit tenue en l'absence du demandeur, la division d'examen ayant refusé la participation de la personne envoyée par le demandeur et habilitée à agir en son nom. Néanmoins, le requérant n'a pas formulé de requête spécifique à cet égard.
4.2 En tout cas, la Chambre estime que la division d'examen a agi correctement. La personne concernée n'était ni un mandataire agréé, ni un employé du demandeur (CP8 Technologie), mais un employé de la société Gemalto SA, qui appartient au même groupe de sociétés.
Aucune disposition n'étant prévue dans le règlement d'exécution en application de l'article 133(3), dernière phrase CBE, la CBE ne permet pas actuellement qu'une personne morale soit représentée par un employé d'une autre personne morale à laquelle elle est économiquement liée. En d'autres termes, un employé d'une société à l'intérieur d'un groupe ne peut pas représenter une autre société appartenant au même groupe (voir T 298/97, sommaire II et point 4 des motifs). La division d'examen a donc correctement conclu que les conditions de l'article 133(3) CBE n'étaient pas remplies.
La chambre accepte que cette personne ait été envoyée de bonne foi, mais cela ne constitue pas une considération pertinente. La division d'examen n'était nullement obligée d'attendre qu'un mandataire agréé domicilié à Munich soit convoqué, car cela aurait fortement retardé la procédure.
4.3 Il n'a pas été formulé de requête en remboursement de la taxe de recours en application de la règle 67 de la CBE 1973. Dans le cas d'espèce, un tel remboursement n'aurait de toute façon pas été justifié.| |
Dispositif
Par ces motifs, il est statué comme suit
1. La décision attaquée est annulée.
2. L'affaire est renvoyée à l'instance du premier degré afin de délivrer un brevet dans la version suivante:
Revendications 1 - 17 produites avec la lettre du 7 octobre 2015;
Description pages 1-5, 7 et 12 - 33 telles que déposées;
Description pages 6, 10 et 11 produites avec la lettre du 16 juillet 2008 (reçues le 21 juillet 2008);
Description pages 8 et 9 produites avec la lettre du 8 octobre 2015;
Feuilles des dessins 1/6 à 6/6 telles que déposées.