T 1507/17 (Niveaux de sûreté/AIRBUS) 19-09-2022

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).