T 2179/12 (Coffres-forts dématerialisés/ALMERYS) of 18.7.2018

Exposé des faits et conclusions

I. Le recours fait suite à la décision de la division d'examen de rejeter la demande de brevet européen n° 08 826 806.5 au motif que l'objet de la revendication 1 selon les requêtes principale et subsidiaire n'était pas nouveau, contrairement aux exigences de l'article 54 CBE. Les documents suivants ont été cités pendant la procédure de première instance:

D1 = US 2004/098366 A1

D2 = US 2003/088771 A1

D3 = US 6 105 131 A

Le document suivant est introduit par la chambre de recours:

D5 = extrait de la page Internet "Understanding Windows NTFS Permissions", URL:<http://techgenix.com/understanding-windows-ntfs-permissions/>, Derek Melber, 2006-05-03, récupéré par la chambre le 6 avril 2018 (mise en page par la chambre, avec introduction de numérotation des pages)

II. La requérante (la déposante) a formé un recours contre cette décision et a acquitté la taxe correspondante. Le mémoire exposant les motifs du recours a été déposé dans le délai imparti.

III. La requérante a sollicité l'annulation de la décision attaquée et:

- au titre d'une requête principale, la délivrance d'un brevet sur la base des revendications 1 à 13 soumises en tant que requête principale avec le mémoire de recours;

- au titre de requêtes subsidiaires 1 à 3, la délivrance d'un brevet sur la base des jeux de revendications 1 à 12 intitulés respectivement "première requête auxiliaire" à "troisième requête auxiliaire", tous soumis avec le mémoire de recours;

- la tenue d'une procédure orale.

IV. Dans sa convocation à une procédure orale, la chambre a émis son appréciation provisoire de l'affaire.

V. La procédure orale s'est tenue en l'absence de la requérante, tel qu'annoncé auparavant.

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

"Procédé de gestion de coffres-forts dématérialisés, le procédé de gestion étant mis en ½uvre par un serveur de gestion de coffres-forts, formant portail d'accès auxdits coffres-forts dématérialisés et comprenant

- une étape d'authentification forte d'un premier utilisateur, possesseur d'au moins un premier coffre-fort

- une étape d'attribution, pour au moins une première partie (Cli) dudit premier coffre-fort (Cl), de droits d'accès à un deuxième utilisateur (AUi) possesseur d'au moins un deuxième coffre-fort distinct du premier coffre fort, la première partie (Cli) constituant un espace d'échange, associé aux premier et deuxième utilisateurs et accessible au deuxième utilisateur à travers une liaison sécurisée lors de la mise en ½uvre d'au moins une transaction entre les premier et deuxième utilisateurs,

- une étape de mise en ½uvre par ledit serveur d'une dite transaction entre les premier et deuxième utilisateurs, comprenant une exécution d'au moins :

une première action sur le contenu de la première partie,

et une deuxième action sur le contenu dudit deuxième coffre-fort."

VII. La revendication 1 de la première requête subsidiaire se distingue de celle de la requête principale en ce que les droits d'accès accordés au deuxième utilisateur ne sont attribués que pour l'exécution sur ladite partie d'une action autorisée dans le cadre d'un processus prédéterminé, préalablement sélectionné, correspondant à une ou plusieurs transactions.

VIII. La revendication 1 de la deuxième requête subsidiaire se distingue de celle de la première requête subsidiaire par une étape additionnelle de mise en ½uvre d'une interface utilisateur proposant une liste de transactions que l'utilisateur est autorisé à déclencher, configurée pour une sélection et un déclenchement par un utilisateur d'une transaction de ladite liste.

IX. La revendication 1 de la troisième requête subsidiaire se distingue de celle de la requête principale en ce que ladite transaction comprend une action de transfert d'une partie au moins du contenu de la première partie vers le deuxième coffre-fort ou vice versa.

X. La revendication 12 de la requête principale et la revendication 11 des requêtes subsidiaires concernent un programme d'ordinateur exécutant le procédé d'une des revendications précédentes.

XI. La revendication 13 de la requête principale et la revendication 12 des requêtes subsidiaires concernent un serveur ayant des caractéristiques correspondant aux caractéristiques de la revendication 1.

XII. La Chambre a rendu sa décision à l'issue de la procédure orale.

Motifs de la décision

1. L'invention

La présente invention concerne un procédé de gestion de coffre-fort dématérialisé, appartenant à un premier utilisateur, comprenant l'attribution pour une partie déterminée de cet espace de droits d'accès à un deuxième utilisateur, de tel sorte que ladite partie déterminée constitue un espace d'échange sécurisé entre les premier et deuxième utilisateurs. Cet espace d'échange est destiné aux échanges entre les premier et deuxième utilisateurs et accessible à travers une liaison sécurisée lors de la mise en ½uvre de transactions entre les premier et deuxième utilisateurs impliquant une exécution d'actions sur le contenu de ladite partie déterminée et du coffre-fort appartenant au deuxième utilisateur.

L'avantage par rapport à l'utilisation dans l'art antérieur d'un système de procuration est qu'il n'est pas nécessaire pour le premier utilisateur de donner accès au deuxième utilisateur à la totalité du coffre-fort.

2. Interprétation de la terminologie de la demande

La chambre juge utile d'indiquer comment elle interprète certaines expressions utilisées dans la demande.

2.1 Coffre-fort dématérialisé

Ceci est interprété comme un espace sécurisé "non matériel", par exemple un espace sécurisé dans une mémoire informatique.

2.2 Serveur de gestion de coffre-forts

Ceci est interprété comme une entité offrant accès auxdits espaces sécurisés. La chambre est d'avis que par exemple un ordinateur avec un système de fichiers comprenant un contrôle d'accès discrétionnaire à des répertoires et des fichiers tombe sous cette définition.

2.3 Authentification forte

Il n'existe pas de définition unique pour cette expression. En l'absence d'une telle définition unique, les mots "authentification" et "forte" ont leur sens usuel. En particulier, ce qui est considéré comme "fort" est subjectif, c.-à-d. une authentification est assez "forte" si elle satisfait aux exigences des utilisateurs. En pratique, toute authentification qui n'est pas triviale peut donc être considérée comme forte.

2.4 Transaction

Comme expliqué dans la description, page 25, lignes 30 à 34, le terme "transaction" est très général. Il couvre non seulement des opérations financières ou commerciales, mais également des simples envois, échanges ou partages de documents.

2.5 Action

Comme expliqué dans la description, page 3, lignes 1 à 4, le terme "action" couvre entre autres des ajouts, des modifications, des suppressions, des consultations de contenu, etc.

3. Nouveauté; Article 54 CBE

La chambre accepte le raisonnement de la requérante (mémoire de recours, page 3, avant-dernier paragraphe - page 4, avant-dernier paragraphe), selon lequel, au vu de l'introduction de l'expression "possesseur d'un deuxième coffre-fort", l'entité de confiance dans le document D1 ne peut plus être interprétée comme un deuxième utilisateur au sens de la revendication 1 de la requête principale.

La chambre juge donc que l'objet de la revendication indépendante 1 et pour la même raison des revendications indépendantes 12 et 13 de la requête principale, ainsi que l'objet des revendications indépendantes 1, 11 et 12 des requêtes subsidiaires, est nouveau; Article 54 CBE.

4. Activité inventive (Article 56 CBE) et brevetabilité (Article 52(2) CBE) - requête principale

4.1 La chambre note que la requérante a introduit un raisonnement dans son mémoire de recours (pages 6 et 7), visant à démontrer que l'objet de la revendication 1 de la requête principale est inventif par rapport au document D1. La requérante n'a cependant pas adressé l'argumentation formulée en tant qu'obiter dictum ("Remarques supplémentaires") sous le point 14 de la décision attaquée, selon laquelle l'objet de la revendication 1 manque d'activité inventive vis-à-vis des seules connaissances générales de l'homme du métier.

4.2 Ledit point 14 mentionne le système d'exploitation Windows NT et le système de fichiers NTFS comme faisant partie desdites connaissances générales. La chambre introduit le document D5 pour illustrer ce qui était connu à ce sujet avant la date de priorité de la présente demande.

4.3 La chambre juge que l'art antérieur le plus proche est constitué par le procédé notoire d'échange de données confidentielles entre deux parties.

4.4 L'homme du métier dans le domaine de la programmation qui prend connaissance de ce procédé aura le désir de l'automatiser.

4.5 Dans des systèmes automatisés, les données sont en général stockées dans des fichiers informatiques disposés dans un système de fichiers. Un des systèmes de fichiers les plus répandus à la date de priorité était le système NTFS, qui comprend un contrôle d'accès discrétionnaire par le moyen d'une liste de contrôle d'accès ("access control list" ou ACL). Référence est faite au document D5 pour une description des caractéristiques essentielles du contrôle d'accès discrétionnaire offert par le système NTFS.

Vu que les données à échanger sont confidentielles, l'homme du métier sera naturellement incliné à utiliser un système de fichiers comme NTFS offrant un tel contrôle d'accès discrétionnaire.

4.6 La chambre considère que l'ordinateur sur lequel sont stockées les fichiers gérés par ledit système de fichiers constitue le "serveur de gestion de coffres-forts".

4.7 Les données que la première partie souhaite transmettre à la deuxième partie seraient alors stockées dans un premier coffre-fort, en occurrence un répertoire sur le serveur, pour lequel la première partie est le possesseur ("owner").

4.8 La deuxième partie serait possesseur d'un deuxième coffre-fort, distinct du premier, dans lequel elle peut sauvegarder les fichiers avec les données reçues de la première partie.

4.9 Un système tel que NTFS ne donne en général accès aux fichiers ou répertoires qu'à des utilisateurs qui ont été identifiés auparavant, par exemple au moment où ils se sont enregistrés sur l'ordinateur ("login"). La chambre estime que même une identification par mot de passe peut être qualifiée comme "forte", à condition que le mot de passe ne soit pas trop "faible". Ceci étant dit, il existait déjà avant la date de priorité des systèmes d'authentification fortes dans le sens qu'ils requièrent la concaténation de plusieurs facteurs d'authentification.

4.10 L'homme du métier utilisera la possibilité offerte dans le système NTFS de donner des droits d'accès à certains utilisateurs qui ne sont pas possesseur du fichier ou répertoire concerné (voir la figure 1 dans D5). Ainsi, il serait donné au deuxième utilisateur au moins la permission de lire ("read") une partie du premier coffre-fort, contenant les fichiers avec les données que la première partie souhaite lui transmettre. On peut alors dire que cette partie constitue un "espace d'échange" associé aux premier et deuxième utilisateurs. Lors de la mise en ½uvre de la transaction entre les premier et deuxième utilisateurs, cet espace est accessible à travers la liaison sécurisée garantie par la procédure d'enregistrement sur le serveur.

4.11 La mise en ½uvre de la transaction entre les premier et deuxième utilisateurs comprendra alors l'exécution:

- d'une première action (c.-à.d. une action de lecture) sur le contenu de la première partie (dans le premier coffre-fort); et

- d'une deuxième action (c.-à.d. une action d'écriture) sur le contenu dudit deuxième coffre-fort.

4.12 L'homme du métier arriverait donc à l'objet de la revendication 1 de la requête principale sans pour cela démontrer une activité inventive. Par conséquent, la chambre juge que cette revendication, et pour les mêmes raisons les revendications 12 et 13 de la même requête, ne satisfont pas aux exigences de l'Article 56 de la CBE.

4.13 De plus, la revendication 12 concerne un "programme d'ordinateur". En l'absence d'indications contraires, la chambre estime que ce programme est un programme en tant que tel (Article 52(3) CBE) et n'est donc pas brevetable en vertu de l'Article 52(2)(c) CBE.

5. Requêtes subsidiaires

5.1 En ce qui concerne la première requête subsidiaire, la chambre estime que les droits d'accès accordés au deuxième utilisateur ne sont évidemment accordés que dans le but d'effectuer la transaction en question. Il serait donc également évident pour l'homme du métier de n'accorder ces droits que dans le cadre de processus correspondant à la transaction qui doit être effectuée.

Les considérations données ci-dessus pour la requête principale s'appliquent donc également aux revendications indépendantes de la première requête subsidiaire.

5.2 En ce qui concerne la deuxième requête subsidiaire, la chambre estime que la proposition d'une liste de transactions possibles, de laquelle l'utilisateur peut faire un choix, constitue également une étape d'automatisation triviale.

Les considérations données ci-dessus pour la requête principale s'appliquent donc également aux revendications indépendantes de la deuxième requête subsidiaire.

5.3 En ce qui concerne la troisième requête subsidiaire, la chambre a déjà argumenté pour la requête principale que la transaction comprend une action de transfert de données contenues dans des fichiers de la première partie vers le deuxième coffre-fort.

Les considérations données ci-dessus pour la requête principale s'appliquent donc également aux revendications indépendantes de la troisième requête subsidiaire.

Dispositif

Par ces motifs, il est statué comme suit

Le recours est rejeté.