T 1507/17 (Niveaux de sûreté/AIRBUS) of 19.9.2022

European Case Law Identifier: ECLI:EP:BA:2022:T150717.20220919
Date de la décision : 19 Septembre 2022
Numéro de l'affaire : T 1507/17
Numéro de la demande : 10752854.9
Classe de la CIB : G06F 9/455
G06F 21/24
H04W 12/06
Langue de la procédure : FR
Distribution : D
Téléchargement et informations
complémentaires :
Texte de la décision en FR (PDF, 319 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 : TRAITEMENT AUTOMATISÉ DE DONNÉES MULTI-USAGES, METTANT EN OEUVRE DES FONCTIONS AYANT BESOIN DE DIFFÉRENTS NIVEAUX DE SÛRETÉ OU LIMITES DE RESPONSABILITÉ
Nom du demandeur : Airbus
Nom de l'opposant : -
Chambre : 3.5.06
Sommaire : -
Dispositions juridiques pertinentes :
European Patent Convention Art 54
European Patent Convention Art 56
Mot-clé : Nouveauté - (non)
Activité inventive - (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 est dirigé contre la décision de la division d'examen, postée le 2 février 2017, de rejeter la demande no. 10752854.9 pour défaut de clarté (article 84 CBE) et de nouveauté (article 54 CBE).

II. La requérante demande l'annulation de la décision de rejet et la délivrance d'un brevet sur la base des revendications de l'une des requêtes suivantes:

- requête principale, correspondant à la demande telle que publiée, objet de la décision de rejet de la division d'examen;

- requêtes subsidiaires 1-3, déposées avec le mémoire de recours.

III. Une citation à une procédure orale a été envoyée par la chambre le 31 mai 2022.

IV. Dans sa lettre du 16 septembre 2022, le requérant a annoncé qu'il n'assisterait pas à la procédure orale sans présenter d'arguments supplémentaires.

V. La procédure orale a été annulée.

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

" 1. Composant logiciel pour ordinateur adapté au traitement automatique de données multi-usages, le composant logiciel étant caractérisé en ce qu'il met en ½uvre des fonctions ayant besoin de différents niveaux de sûreté ou limites de responsabilité et en ce qu'il comprend,

- une pluralité de machines virtuelles (215), chaque machine virtuelle étant adaptée à exécuter au moins une fonction ayant besoin d'un niveau de sûreté ou d'une limite de responsabilité prédéterminé, au moins une desdites fonctions étant adaptée selon des paramètres de la machine virtuelle dans laquelle elle est exécutée ; et,

- un hyperviseur (210) adapté à contrôler l'exécution de ladite pluralité de machines virtuelles."

VII. La revendication 1 de la requête subsidiaire 1 diffère de celle de la requête principale en ce que le deuxième paragraphe se lit (les ajouts sont soulignés ; les suppressions sont [deleted: barrées]):

" - une pluralité de machines virtuelles (215), chaque machine virtuelle étant adaptée à exécuter au moins une fonction ayant besoin d'un niveau de sûreté ou d'une limite de responsabilité prédéterminé, ladite au moins une desdites fonctions étant adaptée selon des paramètres de la machine virtuelle dans laquelle elle est exécutée ; et,"

VIII. La revendication 1 de la requête subsidiaire 2 diffère de celle de la requête principale en ce que les deux premiers paragraphes se lisent (les ajouts sont soulignés ; les suppressions sont [deleted: barrées]):

" 1. Composant logiciel pour ordinateur adapté au traitement automatique de données multi-usages, le composant logiciel étant caractérisé en ce qu'il met en ½uvre des fonctions ayant besoin de différents niveaux de sûreté ou limites de responsabilité, au moins une desdites fonctions étant une fonction de communication pour transmettre des données à un système extérieur ou à une machine virtuelle, et en ce qu'il comprend,

- une pluralité de machines virtuelles (215), chaque machine virtuelle étant adaptée à exécuter au moins [deleted: une] ladite fonction [deleted: ayant-besoin d'un niveau de sûreté ou d'une limite de responsabilité prédéterminé ]de communication, ladite [deleted: au-moins une desdites] fonctions de communication étant adaptée selon des paramètres de la machine virtuelle dans laquelle elle est exécutée ; et,"

IX. La revendication 1 de la requête subsidiaire 3 diffère de celle de la requête subsidiaire 2 en ce que le premier paragraphe se lit (les ajouts sont soulignés ; les suppressions sont [deleted: barrées]):

"" 1. [deleted: Composant logiciel pour ordinateur adapté au] Système de traitement automatique de données multi-usages, [deleted: le composant logiciel étant caractérisé en ce qu'il met] mettant en ½uvre des fonctions ayant besoin de différents niveaux de sûreté ou limites de responsabilité, au moins une desdites fonctions étant une fonction de communication pour transmettre des données à un système extérieur ou à une machine virtuelle, et [deleted: en ce qu'il comprend,] comprenant"

Motifs de la décision

1. Résumé de l'invention

1.1 La demande concerne un logiciel qui met en ½uvre différents niveaux de sûreté et des "limites de responsabilité" pour les fonctions qu'il fournit (description originale, page 15, troisième paragraphe). Le terme "fonction" n'est pas défini dans la description. Les fonctions semblent être des programmes de base appelés par les applications (page 16, deuxième paragraphe). Une fonction peut par exemple servir à la communication de données (figure 2: 300, sortie droite de "type de fonction?") ou à la mémorisation de données (sortie gauche; correspondant aux revendications 5-7 qui n'ont pas fait l'objet d'une recherche en raison de l'absence d'unité, article 82 CBE). Le logiciel comprend un hyperviseur standard (page 7, première phrase) et plusieurs machines virtuelles (figure 2: MV1-3, MVx), dont chacune regroupe les fonctions avec le même niveau de sûreté, voir page 15, lignes 9-13:

"Les étapes décrites en référence à la figure 4, appliquées aux fonctions qui doivent être hébergées dans le STAD, permettent de définir les besoins de niveau de sûreté de chaque fonction. Ces résultats, éventuellement combinés avec un critère de responsabilité, permettent de définir les fonctions regroupées dans une même machine virtuelle."

En ce qui concerne la limite de responsabilité, il est possible de définir une machine virtuelle pour chaque intervenant afin que chacun soit responsable de sa partie (lignes 13-18).

1.2 Dans les revendications, les fonctions sont décrites comme "adaptées selon des paramètres de la machine virtuelle". La description ne donne qu'un seul exemple d'un tel paramètre, à savoir le niveau de sûreté (page 10, premier paragraphe). Mais, une adaptation dans le sens où les fonctions sont modifiées (pendant la programmation ou pendant l'exécution) en fonction du niveau de sûreté de la machine virtuelle, n'est pas divulguée et serait même en contradiction avec la description, puisque celle-ci divulgue que les paramètres des machines virtuelles sont adaptés aux paramètres des fonctions, voir page 13, lignes 14-24:

"La figure 4 illustre schématiquement certaines étapes mises en oeuvre pour analyser les risques associés aux fonctions qui doivent être exécutées sur un même STAD. Ces risques permettent de définir les machines virtuelles devant être implémentées dans le STAD et la répartition de ces fonctions dans les machines virtuelles utilisées.

Cette analyse consiste notamment à déterminer les paramètres d'exécution des fonctions afin de déterminer, en particulier, les interfaces de communication pouvant être utilisées, le système d'exploitation utilisé et la provenance des données traitées. Ces paramètres permettent de caractériser les paramètres de la machine virtuelle apte à mettre en oeuvre la fonction et de définir un niveau de sûreté." (accentuation ajoutée)

Il s'agit donc de répartir les fonctions dans les machines virtuelles adaptées aux niveaux de sécurité des fonctions.

2. Clarté

2.1 D'après la décision contestée (1.1), l'expression "des fonctions ayant besoin de différents niveaux de sûreté ou limites de responsabilité" n'est pas claire, puisque elle ne décrit pas la fonction en termes de caractéristiques techniques.

2.2 La chambre estime qu'il ressort de la demande qu'une telle fonction est un programme pour un ordinateur. Donner à un programme une valeur de sûreté ou de responsabilité dans une unité de mesure définie au préalable par le programmeur, qui sera ensuite utilisée par lui-/elle-même ou par son programme, est considéré comme clair.

2.3 De même, la deuxième expression ("chaque machine virtuelle étant adaptée à exécuter au moins une fonction ayant besoin ..."), qui est contestée dans la décision (1.2) et qui contient la première expression, est donc également claire.

2.4 Il s'ensuit que les reven­dications sont claires (article 84 CBE).

3. Nouveauté de la requête principale et de la requête subsidiaire 1

3.1 Selon le mémoire de recours (page 5, deuxième paragraphe, première phrase), l'objet de la revendication 1 se distingue de celui de D1 en ce que D1 ne révèle pas qu'une même fonction peut être mise en ½uvre dans différentes machines virtuelles.

3.2 Cette caractéristique n'est toutefois pas divulguée dans la description de la demande, ni explicitement mentionnée dans la revendication. Elle semble simplement être couverte par la revendication.

3.3 Ceci est pareillement le cas dans la revendication 9 de D1 où, à l'étape e), chaque machine virtuelle sensitive a un niveau de sensibilité définissable par l'utilisateur et il n'est pas exclu que deux machines aient le même niveau.

3.4 En outre, le mémoire de recours fait valoir que dans D1, aucune fonction n'est adaptée selon des paramètres de la machine virtuelle dans laquelle elle est exécutée (page 5, deuxième paragraphe, première phrase).

3.5 Mais, comme expliqué ci-dessus (résumé de l'inven­tion, 4.2), cette soi-disant adaptation doit être interprétée dans le sens où les fonctions sont réparties dans les machines virtuelles ayant les mêmes niveaux de sécurité que les fonctions elles-mêmes.

3.6 Ceci est également divulgué dans D1 ([25]). Ainsi, dans D1, une fonction peut être implémentée dans plusieurs machines virtuelles avec le même niveau de sensibilité. D1 révèle explicitement la possibilité d'avoir plusieurs machines virtuelles avec le même niveau de sensibilité, voir [25], première phrase:

"and where each sensitive virtual-machine 4 may process information at a sensitivity level that is either the same as, or different from, that of another sensitive virtual-machine 4".

3.7 En ce qui concerne l'argument de la requérante, discuté dans la décision (2.3), selon lequel dans D1, à la différence de l'invention, "les machines virtuelles soient ici mises en ½uvre en fonction de la nature des données traitées, c'est-à-dire du niveau de sensibilité des données traitées, et non du niveau de sûreté des fonctions traitant ces données", la chambre est de l'avis suivant: les fonctions doivent garantir une sûreté qui correspond au besoin de sensibilité des données qu'elles traitent. Donc, la caractéristique revendiquée dans sa généralité est une conséquence implicite de la caractéristique divulguée dans D1.

3.8 La chambre rejoint donc la décision (2.2) dans la conclusion que l'objet de la revendication 1 de la requête principale n'est pas nouveau (article 54 CBE).

3.9 Il en va de même pour la revendication 1 de la requête subsidiaire 1, puisqu'elle ne diffère que de façon minime de la revendication 1 de la requête principale (à savoir par l'ajout du mot "ladite").

3.10 La chambre n'est pas convaincue par l'argument de la requérante dans le mémoire de recours (page 6, premier paragraphe) selon lequel la modification de la revendication 1 de la requête subsidiaire 1 permettrait de préciser sans ambiguïté qu'une même fonction est mise en ½uvre dans plusieurs machines virtuelles. Tel n'est cependant pas le cas selon la chambre: la revendication 1 de la requête subsidiaire 1 n'exprime pas qu'une fonction est mise en ½uvre dans plusieurs machines virtuelles. Elle n'exclut pas non plus cette possibilité, mais la laisse ouverte.

4. Activité inventive des requêtes subsidiaires 2 et 3

4.1 La revendication 1 de la requête subsidiaire 2 diffère de celles des requêtes précédentes en ce que la fonction est spécifiée comme étant une fonction de communication.

4.2 Aucune raison n'est donnée dans le mémoire de recours pour expliquer en quoi cette spécification serait de nature à contribuer à une l'activité inventive de l'objet de la revendication. La chambre ne voit pas non plus de raison.

4.3 La revendication 1 de la requête subsidiaire 3 correspond à la revendication 1 de la requête subsidiaire 2, mais pour un système au lieu d'un composant logiciel. Par conséquent, ce qui vient d'être dit s'applique également à la requête subsidiaire 3.

4.4 L'objet de la revendication 1 des requêtes subsidiaires 2 et 3 n'est donc pas inventif (article 56 CBE).

Dispositif

Par ces motifs, il est statué comme suit

Le recours est rejeté.

Quick Navigation