T 0020/03 (Remplacement d'une scène graphique/FRANCE TELECOM) of 31.1.2006

Exposé des faits et conclusions

I. La demande de brevet européen nº 98 938 735.2, publiée comme demande internationale nº WO-A-99/03280 (citée ci-après en abrégé comme "la demande") et revendiquant une priorité d'une demande française déposée en 1997, a pour objet un signal de données de modification d'une scène graphique, et des procédés et dispositifs correspondants.

II. L'invention selon les revendications indépendantes 7 et 8 dans la version originale était caractérisée en ce que des trames d'un signal de mise à jour d'une scène graphique portaient au moins une des commandes d'insertion, de modification ou de suppression d'un élément ou une commande de remplacement de la totalité de la scène graphique. Au regard de cette commande de remplacement, le rapport d'examen préliminaire international établi par l'OEB avait donné une opinion favorable quant à l'activité inventive, surtout au vu de l'état de la technique découlant du document

M. Arikawa et al. : "Dynamic LoD for QoS Management in the Next Generation VRML", INTERNATIONAL CONFERENCE ON MULTIMEDIA COMPUTING AND SYSTEMS, 17 juin 1996, pages 24-27 (cité comme document D2 ci-après).

III. Au cours de la phase d'examen européen de la demande quant au fond, les demanderesses ont déposé un nouveau jeu de revendications modifiées, les revendications indépendantes portant essentiellement sur la définition seule de la commande de remplacement.

La division d'examen a toutefois rejeté la demande par décision signifiée le 3 juillet 2002 pour manque d'activité inventive. Elle a estimé que l'homme du métier, en combinant ses connaissances techniques dans le domaine de l'affichage d'objets graphiques et des enseignements du document D2, arriverait à l'objet revendiqué sans faire preuve d'une activité inventive.

IV. Le 9 septembre 2002, les requérantes (demanderesses) ont formé un recours contre la décision de la division d'examen. La taxe de recours a été acquittée le même jour. Le mémoire exposant les motifs du recours a été déposé le 13 novembre 2002 avec plusieurs jeux de revendications, à savoir une requête principale et onze requêtes présentées à titre subsidiaire (requêtes 1 à 11). Dans une notification en date du 17 octobre 2005, la Chambre a cité le chapitre 4.7.10, "Browser Script Interface" du document

The Virtual Reality Modeling Language Specification, Version 2.0, ISO/IEC WD 14772, 4 août 1996.

V. Lors de la procédure orale, qui a eu lieu devant la Chambre le 31 janvier 2006, le mandataire des requérantes a conclu à la réformation de la décision contestée et à la délivrance d'un brevet sur la base des revendications selon la requête principale et les requêtes 1 et 2, présentées à titre subsidiaire lors de la procédure orale, et les requêtes 3 à 5, présentées à titre subsidiaire et correspondant respectivement aux requêtes 9, 10 et 11 présentées avec le mémoire exposant les motifs du recours.

La requête principale et les requêtes 1 à 5 visent diverses catégories de revendications, toutes les requêtes ayant cependant en commun qu'un procédé de mise à jour par un serveur d'une scène graphique est revendiqué. Les revendications indépendantes qui visent la protection d'un tel procédé s'énoncent comme suit (dans le texte ci-dessous des revendications, les différences essentielles entre les requêtes sont indiquées en gras) :

Requête principale :

"9. Procédé de mise à jour par un serveur d'une scène graphique destinée à être présentée sur un écran d'au moins un terminal, par transmission de trames de mise à jour dans un flux de mise à jour,

caractérisé en ce qu'il comprend les étapes suivantes :

- insertion par ledit serveur d'une commande de remplacement (63, 64) d'une scène graphique existante (61) par une nouvelle scène graphique (62) dans au moins une desdites trames de mise à jour de ladite scène ;

- transmission de ladite trame de mise à jour vers au moins un desdits terminaux, de façon à permettre en une seule commande la suppression de ladite scène courante et la mise en place de l'intégralité de ladite nouvelle scène dans le ou lesdits terminaux."

Requête 1 :

"9. Procédé de mise à jour par un serveur d'une scène graphique destinée à être présentée sur un écran d'au moins un terminal, par transmission dudit serveur vers ledit terminal de trames de mise à jour dans un flux de mise à jour,

caractérisé en ce qu'il comprend les étapes suivantes :

- insertion par ledit serveur d'une commande de remplacement (63, 64) d'une scène graphique existante (61) par une nouvelle scène graphique (62) dans au moins une desdites trames de mise à jour de ladite scène, sans attendre une requête d'un desdits terminaux ;

- transmission de ladite trame de mise à jour vers au moins un desdits terminaux, de façon à permettre en une seule commande la suppression de ladite scène courante et la mise en place de l'intégralité de ladite nouvelle scène dans le ou lesdits terminaux."

Requête 2 :

"7. Procédé de mise à jour par un serveur d'une scène graphique destinée à être présentée sur un écran d'au moins un terminal, par transmission par ledit serveur vers le ou lesdits terminaux, de trames de mise à jour dans un flux de mise à jour,

caractérisé en ce qu'il comprend les étapes suivantes :

- insertion par ledit serveur d'une commande de remplacement (63, 64) d'une scène graphique existante (61) portant soit :

- la valeur d'une nouvelle scène graphique (62), de façon à permettre en une seule commande la suppression d'une scène graphique existante (61) et la mise en place de l'intégralité de ladite nouvelle scène ; soit

- la valeur de la scène graphique courante, de façon à former un point d'accès aléatoire audit flux, pour qu'un utilisateur puisse se brancher à tout instant sur ledit flux de données de mise à jour, et visualiser la scène correspondante en cours de transmission ;

- transmission de ladite trame de mise à jour vers le ou lesdits terminaux, sans attendre une requête d'un utilisateur."

Requête 3 :

"1. Procédé de mise à jour par un serveur d'une scène graphique destinée à être présentée sur un écran d'au moins un terminal, par transmission de trames de mise à jour dans un flux de mise à jour,

caractérisé en ce qu'il comprend les étapes suivantes :

- insertion par ledit serveur d'une commande de remplacement (63, 64) d'une scène graphique existante (61) par une nouvelle scène graphique (62) dans au moins une desdites trames de mise à jour de ladite scène, sans attendre une requête d'un desdits terminaux ;

- transmission de ladite trame de mise à jour vers au moins un desdits terminaux, de façon à permettre en une seule commande la suppression de ladite scène courante et la mise en place de l'intégralité de ladite nouvelle scène dans le ou lesdits terminaux, sans requête d'un desdits terminaux."

Requête 4 :

"1. Procédé de mise à jour par un serveur d'une scène graphique destinée à être présentée sur un écran d'au moins un terminal, par transmission de trames de mise à jour dans un flux de mise à jour,

caractérisé en ce qu'il comprend les étapes suivantes :

- insertion par ledit serveur d'une commande de remplacement (63, 64) d'une scène graphique dans au moins une desdites trames de mise à jour de ladite scène, sans attendre une requête d'un desdits terminaux, ladite commande de remplacement de scène pouvant comprendre :

- la valeur d'une nouvelle scène graphique (62) dans au moins une desdites trames de mise à jour de ladite scène

- la valeur de la scène courante ;

- transmission de ladite trame de mise à jour vers au moins un desdits terminaux, de façon à permettre :

- en une seule commande la suppression de ladite scène courante et la mise en place de l'intégralité de ladite nouvelle scène dans le ou lesdits terminaux, sans requête d'un desdits terminaux, dans le cas d'une nouvelle scène graphique ;

- qu'un utilisateur puisse se brancher à tout instant sur ledit flux de données de mise à jour, et visualiser la scène correspondante en cours de transmission, dans le cas de la valeur de la scène courante."

Requête 5 :

"1. Procédé de mise à jour par un serveur d'une scène graphique destinée à être présentée sur un écran d'au moins un terminal, par transmission de trames de mise à jour dans un flux de mise à jour,

caractérisé en ce que lesdites trames de mise à jour comprennent au moins une des commandes de modification ayant une des quatre formes de base suivantes :

- insertion d'un élément de ladite scène graphique ;

- modification d'un élément de ladite scène graphique

- suppression d'un élément de ladite scène graphique ;

- remplacement (63, 64) d'une scène graphique existante (61) par une nouvelle scène graphique (62), de façon à permettre en une seule commande la suppression de ladite scène courante et la mise en place de l'intégralité de ladite nouvelle scène ;

un élément étant repéré à l'aide d'un identifiant spécifique et appartenant au groupe comprenant :

- un objet ;

- un champ d'un objet ;

une commande agissant sur une connexion entre deux champs de deux objets existants ("ROUTE"), ladite connexion étant repérée à l'aide d'un identifiant spécifique ("RouteId"),

chacune desdites commandes étant codées de la façon suivante :

- premier niveau : deux bits pour coder ladite forme de base ;

- deuxième niveau : deux bits pour coder le type d'élément concerné (sauf pour la commande de remplacement de scène) ;

- troisième niveau : paramètres de l'élément concerné."

VI. A l'appui de leurs requêtes, les requérantes ont développé les arguments suivants :

L'invention concernait la transmission et la restitution de scènes graphiques et s'appliquait à de nombreux domaines, dans lesquels la mise en oeuvre de scènes multimédia était souhaitable, tels que les jeux interactifs ou la transmission de scènes sur Internet. La base de l'invention était un langage de description de scène graphique qui permettrait d'optimiser la transmission et la restitution d'une scène graphique sur des terminaux.

Une scène graphique, dans la terminologie technique utilisée dans la demande, n'était pas une série d'images successives au sens de la télévision, mais un ensemble des noeuds organisés selon une structure arborescente, auxquels étaient associés un ou plusieurs objets, comprenant eux-mêmes un ou plusieurs champs qui précisaient différents paramètres du ou des objets.

L'invention visait une amélioration du langage de type VRML (Virtual Reality Modeling Language) et était intégrée au sein de la norme MPEG-4 (ISO/IEC 14496), qui était en cours de développement à la date de priorité. A l'époque des langages de type VRML, la transmission des scènes graphiques d'un serveur vers le terminal d'un utilisateur et ses reconstructions sur le terminal comme toutes les autres modifications des objets demandaient l'intervention de l'utilisateur. Il n'était donc pas possible par exemple d'envoyer, depuis un serveur, une page de publicité si celle-ci n'avait pas été sollicitée. L'art antérieur supposait de plus la transmission systématique d'une scène initiale, empêchant que l'utilisateur prendrait en cours la transmission d'une scène, comme cela serait possible avec une émission de télévision. Seule l'identification de ces inconvénients comme un problème à résoudre était non évidente et constituait un apport inventif à la technique.

Pour pallier à ces inconvénients, l'invention proposait une seule et unique commande qui permet de transmettre, dans le flux de mise à jour d'un serveur vers le client en "mode push", une scène complète avec l'effet de supprimer l'arborescence de noeuds actuellement affichée et de mettre en place l'intégralité de la scène nouvelle. Cette commande de remplacement complétait les langages connus de type VRML d'une manière nouvelle et inventive.

Le document D2, considéré dans la procédure d'examen comme l'art antérieur le plus proche de la présente invention, concernait un système dit DVRML, qui découlait d'un développement très spécial du langage VRML, dédié et essentiellement limité à l'application aux jeux virtuels en réseau. La diffusion de l'information graphique du serveur vers les clients était réalisée en "mode pull", uniquement en réponse aux requêtes des utilisateurs, c'est-à-dire avec une approche de l'art antérieur que l'invention s'efforçait de surmonter. Un changement de scène ne pourrait se faire que sur requête de l'utilisateur, par exemple lorsque ce dernier clique sur un objet de la scène courante, par exemple une porte, pour accéder à la nouvelle scène, par exemple la pièce située derrière la porte sur laquelle il avait cliqué.

Le document D2 n'incitait donc nullement l'homme du métier ni à formuler un problème nouveau et inventif, ni à proposer une seule commande de modification pour remplacer la scène dans sa intégralité. Au contraire, le document D2 montrait une autre solution, à savoir la suppression, modification et ajout d'objets au sein de la scène graphique d'une manière dynamique.

L'exigence d'activité inventive de l'article 56 CBE était par conséquent satisfaite. Il en était de même pour les revendications des différentes requêtes subsidiaires.

Cette appréciation de l'activité inventive ne changerait pas au cas où l'on inclurait les connaissances générales relatives aux instructions de type Clearscreen CLS, lesquelles considèrent une scène graphique comme n'étant pas une image, au sens informatique, susceptible de s'afficher sur l'écran d'un terminal, mais comme une structure arborescente. L'instruction CLS nécessiterait aussi l'utilisation successive de deux instructions, et non d'une seule commande de remplacement de scène comme proposée par l'invention. La mise en oeuvre d'une telle unique commande permettrait d'optimiser la restitution continue des scènes sur un terminal, alors que les instructions classiques d'effacement des images risqueraient d'entraîner au moins momentanément un écran noir ou tout brouillé avant que la nouvelle scène reçue du serveur serait construite.

En effet, selon la présente invention, toutes les modifications dynamiques de la scène graphique peuvent être réalisées par l'utilisation de quatre instructions seulement, à savoir l'insertion, la modification et la suppression d'un noeud et la remplacement de toute la scène. Le codage de ces instructions peut donc se faire sur seulement deux bits. En outre, l'invention permettrait d'agir sur les connexions ("ROUTES") entre objets, ce qui ne serait pas possible avec le langage VRML par exemple.

Motifs de la décision

Recevabilité

1. Le recours répond aux conditions de recevabilité énoncées aux articles 106 à 108 CBE ainsi qu'aux règles 1(1) et 64 CBE et est donc recevable.

Bien-fondé

2. Le recours n'est cependant pas fondé du fait qu'aucune des requêtes ne remplit la condition de l'activité inventive au sens de l'article 56 CBE.

3. Selon la jurisprudence des chambres de recours, il est convenu d'examiner l'activité inventive à l'aide de la méthode problème-solution qui exige l'identification de l'état de la technique pertinent, puis l'évaluation de la contribution technique apportée par l'invention du point de vue de l'homme du métier (voir "La Jurisprudence des chambres de recours de l'Office européen des brevets", 4ème édition 2001, Office européen des brevets 2002, page 116).

4. Les revendications indépendantes visant un procédé de mise à jour par un serveur définissent des éléments de l'invention revendiquée qui, au vu de l'ensemble des requêtes soumises, peuvent être résumées comme suit :

Définitions concernant l'objet de la protection

Procédé de mise à jour

par un serveur

d'une scène graphique.

Définitions concernant les scènes graphiques

La scène graphique est destinée à être présentée sur l'écran d'un ou des terminaux multimédia ;

elle est formée d'un ensemble d'objets graphiques, ou noeuds, disposés suivant une structure hiérarchique ayant une représentation d'arbre ;

les éléments de la description de scène utilisés par des moyens de construction d'image pour restituer ladite scène graphique sur l'écran du ou desdits terminaux, sont du type suivant :

- noeud, qui représente soit les primitives graphiques soit un groupe d'objets ou noeuds soit la totalité de la scène (voir également page 8 de la demande),

- champ, vectoriel ou simple, qui représente les caractéristiques d'un objet, et

- connexion, ou "ROUTE", entre deux champs de deux objets existants pour passer d'événements entre ces noeuds, la connexion étant repérée à l'aide d'un identifiant spécifique,

- certains des noeuds ayant associé un identifiant unique peuvent être référencés, et

- certains des champs peuvent être modifiés de l'extérieur, d'autres ont des valeurs fixées.

Définitions concernant le flux de mise à jour

Un flux de mise à jour d'une scène graphique émis par le serveur vers les terminaux comprend des trames de mise à jour ;

le serveur insert une commande de modification d'une scène graphique existante dans au moins une desdites trames de mise à jour, sans attendre une requête d'un desdits terminaux.

Définitions concernant les types de commandes

Chaque commande de modification peut avoir une des formes suivantes :

- insertion d'un élément de ladite scène graphique,

- modification d'un élément de ladite scène graphique,

- suppression d'un élément de ladite scène graphique,

- remplacement d'une scène graphique existante par une nouvelle scène graphique, de façon à permettre en une seule commande la suppression de ladite scène courante et la mise en place de l'intégralité de ladite nouvelle scène.

Définitions concernant le codage des commandes

Le codage des commandes étant comme suit :

- premier niveau : deux bits pour coder ladite forme de base,

- deuxième niveau : deux bits pour coder le type d'élément concerné (sauf pour la commande de remplacement de scène),

- troisième niveau : paramètres de l'élément concerné.

5. Les définitions utilisent des termes comme "scène graphique", "noeud", "champ" ou "route", qui requièrent une interprétation. Selon la demande, le terme "scène graphique" signifie un agencement d'objets graphiques, vidéo et image dans le temps et dans l'espace, en deux ou trois dimensions (v. la demande, p. 1, lignes 8 et s.).

Les "éléments" d'une scène graphique sont notamment les objets, ou noeuds, les champs d'un noeud, les valeurs d'un champ, les connexions entre deux champs (route), et la scène complète (v. la demande, p. 5, lignes 19 et s.). La structure et la signification desdites entités sont ainsi comme des constructions "nodes", "fields", "values", "routes" et "scene graphs" connues du langage VRML (cf. la demande, p. 2, lignes 1-11 et ligne 24, p. 4, lignes 13 et s. et p. 8, lignes 24-27 ; voir également la norme ISO/IEC DIS 14772-1 citée dans la demande, p. 2, ligne 2).

Il en est de même pour les identifiants des champs et des routes et pour la modificabilité de certains des champs, qui sont rendus réutilisables d'après l'art antérieur au moyen du mécanisme DEF (cf. la demande, p. 2, lignes 12 et s., ligne 19 à p. 3, ligne 3 et p. 8, ligne 24 à page 9, ligne 2).

Il convient de noter que ces mécanismes de gestion existaient déjà dans le précurseur de la version 2.0 du langage VRML, la norme VRML 1.0 à laquelle se réfère le document D2.

En outre, les termes "flux de mise à jour d'une scène graphique" et "trames de mise à jour" ne sont pas définis clairement dans la demande. Le terme "flux" se trouve unique à la page 8, lignes 5 à 9 dans les formulations "le signal, ou flux, de modification de scène de l'invention" et "un flux de données 12, au format BIFS" et à la page 14, lignes 1 à 3 dans les formulations "flux d'update" et "flux de données de modification de scène". Les trames sont compris dans le signal ou flux de mise à jour (v. la demande, p. 4, lignes 18 et s.). La figure 2 illustre la structure d'une trame dans une manière très générale : elle suggère au mieux une organisation séquentielle des données en blocs d'informations. Mais une définition expresse ne se trouve nulle part.

En l'absence d'une définition et compte tenu du fait que les revendications indépendantes ne sont pas limitées par rapport au codage de signaux ou par la définition d'une technologie multimédia (VRML, MPEG ou BIFS etc.), il faut interpréter les termes purement et simplement comme signifiant un signal structuré en blocs de données (paquets comme en IP ou Ethernet ou cellules comme en ATM, par exemple) et transmis d'un serveur (distant) pour modifier la scène graphique affichée actuellement sur l'écran d'un client.

On se peut poser des questions sur la nature technique d'une commande de remplacement définie dans le contexte d'un langage de réalité virtuelle et sur la signification technique des termes comme "seule commande" et "niveaux" (du codage des commandes). Bien qu'importantes en principe pour l'appréciation de la brevetabilité, on peut les mettre à part en l'espèce, puisqu'elles s'avèrent comme non essentielles.

6. Le document D2 constitue un point de départ approprié pour apprécier l'activité inventive dans le cadre de l'approche problème-solution. En effet, l'antériorité, comme la demande, vise l'amélioration des langages antérieurs de modélisation de type VRML et leur utilisation, entre autres, sur le réseau et dans des systèmes client-serveur (v. p. 24, chap. 1 "Introduction" et p. 26 et s., ch. 3.2 "Scheduling of DVRML Transfer and Consistency of Scenes").

L'antériorité se réfère à deux systèmes différents fonctionnant en mode client-serveur, un système distribué et un système géré par un serveur DVRML central (v. le document D2, p. 26 : "client-based and server-based DVRML systems"). Le système du serveur central est l'alternative pertinente en l'espèce et sera considéré en détail ci-après.

7. En utilisant le langage DVRML ("VRML différentiel"), le serveur central dispose d'un procédé pour mettre à jour, d'une manière dynamique et à travers un réseau, une scène graphique affichée sur des terminaux d'une pluralité de clients (v. le document D2, p. 25 et s., chap. 3.1 avec fig. 4 et p. 27, colonne de gauche, lignes 1-21, où les éléments et phases du procédé sont exposés).

8. DVRML est un élargissement et une généralisation du langage VRML de la version 1.0 (v. le document D2, p. 24, chap. 2), développé sans changer la structure et signification des éléments descriptifs du langage plus ancien. Les différences entre DVRML et VRML se trouvent surtout dans la réalisation des mécanismes pour gérer les noeuds et modifier des scènes graphiques dans le système client-serveur. Au contraire, la syntaxe et les définitions des éléments descriptifs de la norme VRML 1.0 sont valides essentiellement aussi dans le langage DVRML.

9. Il ressort du document D2, expressément de la page 27, colonne de gauche, lignes 7-9, lignes 14-16 et lignes 17-20 que le serveur central dispose des commandes d'update (l'instruction d'ajouter un nouveau avatar et de supprimer des avatars) qui sont adressées et communiquées, à travers un réseau ATM, aux clients (v. le document D2, p. 27, chap. "Concluding Remarks").

10. Un tel réseau transporte des informations sous la forme d'un flux de trames ou paquets ("cellules"), si bien que le document divulgue aussi l'insertion des commandes d'update dans un flux de mise à jour par le serveur et leur émission vers les terminaux des clients au sens de la présente demande.

11. En outre, le procédé de mise à jour se déroule évidement à l'initiative du serveur, normalement en réponse à une action d'un seul des clients et sans demander aucune impulsion des autres clients qui sont en ligne. Cela montre que le serveur exécute le procédé de mise à jour en mode de type "push", c.-à-d. sans attendre une requête des clients auxquels les commandes sont adressées, et utilise aussi, en prenant en considération la pluralité des clients, une technique de type "multicast". Par exemple, un client pourrait produire une page virtuelle de publicité qui est alors transmise, par le serveur, aux autres clients momentanément en ligne, sans que ces derniers pourraient l'en empêcher.

12. D'autre part, il découle du document D2 (v. fig. 4, par exemple) que le serveur central peut insérer, modifier et supprimer des éléments d'une scène graphique.

13. En résumé, on peut constater que l'objet de l'invention concernant le procédé tel que revendiqué se distingue de l'art antérieur uniquement par les caractéristiques suivantes :

- la mise à la disposition d'une commande de remplacement d'une scène graphique existante par une nouvelle scène graphique, de façon à permettre en une seule commande la suppression de ladite scène courante et la mise en place de l'intégralité de ladite nouvelle scène (toutes les requêtes), et

- le codage des commandes en trois niveaux, étant codés au premier niveau la forme de la commande utilisant deux bits, au deuxième niveau le type d'élément concerné utilisant deux bits, et au troisième niveau les paramètres de l'élément concerné (requête subsidiaire 5).

Il est à rappeler que les modifications figurant dans les autres requêtes subsidiaires n'ajoutent rien par rapport au document D2 parce que ce dernier divulgue déjà une interaction entre serveur et terminaux initiée par le serveur (requêtes subsidiaires 1 et 3) et permet de visualiser la scène graphique courante à un nouvel utilisateur branché (requêtes subsidiaires 2 et 4) ; v. D2, p. 27 "check-in phase".

14. Quant à l'objectif visé par la commande de remplacement, la page 16 de la demande indique clairement que "la nouveauté de l'invention réside ... dans la découverte de la nécessité d'une telle commande". Selon la demande, la commande permettrait de se brancher à tout instant sur un flux de modification de scène comme sur une chaîne de télévision et d'utiliser le signal de l'invention dans un cadre très large d'applications (les techniques "multicast" sur "internet", et notamment les services dits "push").

Cependant, le système du document D2 utilise déjà le mode "push" et une technique de type "multicast". Il dispose des commandes de suppression et d'ajout des noeuds, qui sont transmises aux clients à l'initiative du serveur dans un flux d'update, ce qui permet ainsi potentiellement de remplacer des scènes graphiques entières en combinant les deux commandes. Il suffit de les appliquer sur le noeud au niveau supérieur d'une scène DVRML.

On peut donc en conclure que le problème technique résolu par l'invention à la lumière de l'art antérieur est l'amélioration du système DVRML par la réalisation d'une commande alternative pour le remplacement d'une scène graphique entière.

15. L'homme du métier est cependant familiarisé avec le langage VRML version 2.0 (v. par exemple, la demande, p. 2, lignes 1-6), qui comprend la méthode "replaceWorld()". Cette méthode, définie en une "seule commande", a pour effet de remplacer la scène courante par la scène définie dans le noeud argument (v. la norme VRML 2.0, part 1, ch. 4.7.10 "Browser Script Interface"). L'homme du métier peut directement se rendre compte qu'une telle commande est l'amélioration recherchée et l'enrichissement approprié de la syntaxe du DVRML sans qu'il ait besoin d'exercer une activité inventive.

16. En outre, il fait partie des connaissances générales dans les domaines de l'informatique et des télécommunications que des instructions et commandes d'un système numérique soient avantageusement codées en plusieurs "niveaux", à savoir dans des groupements de bits caractérisant le type de la commande ainsi que le type et la valeur d'un ou des opérandes (v. par exemple les "opcodes" notoire dans les langages de machine). Ayant divulgué en DVRML trois opérations sur des scènes (v. le document D2, p. 26, fig. 4) et, au vu de la norme VRML 1.0, trois types de base des opérandes, noeuds, champs et événements (v. par exemple la demande, p. 2, lignes 1-11 et 22-27), il est impératif qu'on utilise, aussi dans le système DVRML, au moins deux bits respectivement pour coder le type de la commande et le type de l'opérande, ainsi qu'un nombre de bits approprié pour coder les valeurs (ou les paramètres) du ou des opérandes. Un tel codage n'implique aucune activité inventive.

17. En résumé, le procédé de mise à jour par un serveur d'une scène graphique tel que revendiqué selon les requêtes respectives ne satisfait pas aux conditions de l'activité inventive prévues aux articles 52(1) et 56 CBE.

DISPOSITIF

Par ces motifs, il est statué comme suit :

Le recours est rejeté.