FR2893439A1 - Procede pour generer des images associees a un contexte 3d en temps reel, et dispositif teleinformatique permettant de realiser des operations sur une base de donnees multimedia - Google Patents

Abstract

La présente invention concerne un procédé pour générer des images associées à un contexte 3D en temps réel, et un dispositif téléinformatique permettant de réaliser des opérations sur une base de données multimédia.Le système de l'invention comporte au moins un client (70) connecté directement ou par un réseau de télécommunication à un serveur (72, 74) organisé en une partie de métadonnées (74) organisant des services et une intelligence artificielle de haut niveau et en une partie de base avec une intelligence artificielle de bas niveau et des serveurs de rendu et de diffusion.

Description

"Procédé pour générer des images associées à un contexte 3D en temps réel,

et dispositif téléinformatique permettant de réaliser des opérations sur une base de données multimédia" La présente invention concerne un procédé pour générer des images associées à un contexte 3D en temps réel, et un dispositif téléinformatique permettant de réaliser des opérations collaboratives sur une base de données multimédia. Dans l'état de la technique, il est connu de réaliser des io bases de données multimédia dans lesquelles se trouvent enregistrés à la fois des images, des sons, des fichiers musicaux, ainsi que des séquences vidéo et des scripts permettant d'exécuter en fonction de commande de l'utilisateur des séquences particulières de présentation d'un univers modélisant 15 par exemple un univers réel. C'est particulièrement le cas dans le domaine de la réalisation de jeux vidéo à trois dimensions en réalité synthétique. Dans l'état de la technique, plusieurs outils sont connus qui permettent d'assister le concepteur de tels jeux vidéo ou de 20 tels modélisateurs d'évènement dans une représentation à trois dimensions d'un espace d'action. Dans la présente invention, un espace d'action est un espace géométrique dans lequel des événement localisés mettent en oeuvre des structures qui y sont représentables. De plus, ces 25 structures peuvent évoluer dans le temps et ces évolutions peuvent dépendre de lois internes à l'univers réel ou encore d'actions d'agents extérieurs, comme un ou plusieurs joueurs. Particulièrement, parmi ces outils se trouve le générateur de représentations des éléments visuels et autres qui sont insérés 30 dans la représentation à trois dimensions de l'univers dans lequel évoluent les structures représentables sous l'action de l'utilisateur. 2 Parmi ces outils, il existe aussi des modeleurs et des générateurs d'objets animés comme des personnages ou autres objets destinés à se mouvoir ou bien de façon automatique en fonction de règles enregistrées, ou bien de façon interactive en fonction d'actions des joueurs. Les règles enregistrées d'animation des objets animés peuvent être composées à l'avance et déroulées en fonction d'évènements détectés, par exemple à l'aide de ressources d'interface avec l'utilisateur comme un clavier ou une souris, ou io en fonction d'autres évolutions des structures représentées dans l'espace réel, comme la rencontre d'un objet mobile avec un objet fixe. Ces règles d'animation des objets animés et leur exécution à l'aide de bases de données spécifiant les évolutions et is comportements sont éditées et gérées par un ou plusieurs éditeurs de règles d'animation des objets animés, par des scripts (ou séquences de règles d'animation) exécutés au niveau de l'utilisateur sur un moteur de script. Une règle d'animation peut aussi être déclenchée par la saisie d'une commande de 20 l'utilisateur interprétée sur une console informatique ou sur un clavier relié à un ordinateur, ou toute autre interface de jeux ou de manipulation de la réalité ou d'interaction avec la réalité représentée. II est aussi connu dans l'état de la technique des moyens 25 permettant à plusieurs utilisateurs d'intervenir concurremment dans un même espace, ce qui est le cas en particulier des jeux vidéo à plusieurs joueurs. Plus récemment, on a déjà proposé de telles interactions en utilisant le réseau Internet, de sorte que des joueurs placés à 30 de grandes distances les uns des autres peuvent interagir dans un même espace de jeu. Mais de tels systèmes sont extrêmement complexes et subissent plusieurs inconvénients. 3 Tout d'abord, la coopération de plusieurs utilisateurs opérant sur des plateformes différentes comme un ordinateur personnel et un téléphone mobile n'est pas actuellement possible. Particulièrement, chaque machine exécute un système s d'exploitation qui lui est propre dans lequel les ressources nécessaires à l'exécution de codes prévus pour un autre système d'exploitation ne sont pas disponibles. On a déjà proposé des couches logicielles, comme les machines virtuelles, qui permettent de distribuer, dans une large io mesure, le même code exécutable quelque soit la plateforme (ou système d'exploitation) de la machine. C'est le cas des machines virtuelles sous le langage Java. Mais, cette solution est encore incomplète pour permettre l'exécution de jeux 3D parce que notamment l'installation de la machine virtuelle prend trop 15 d'espace mémoire pour un simple téléphone mobile, ou trop de puissance de traitement pour d'autres machines. Ensuite, le nombre considérable de machines pouvant se trouver connectées sur une même application, par exemple un même jeu vidéo à 3D, pose un problème pour permettre que le 20 caractère immédiat des interactions de jeu soit perceptible de tous. Enfin, on notera que les ressources informatiques disponibles aux utilisateurs connectés au même univers représenté, comme un jeu vidéo à 3D, doivent posséder des 25 puissances extrêmement différentes. Ainsi, certaines consoles de jeux comportent des processeurs graphiques particulièrement performants tandis qu'un simple téléphone mobile dispose d'un processeur unique, de faible puissance, et très peu de mémoire pour le traitement et la visualisation des données de 30 représentation. Il en résulte que la technique actuelle ne permet pas, à des coûts raisonnables, d'associer des utilisateurs dotés de terminaux 4 aussi différents qu'une console de jeux ou qu'un téléphone mobile. L'invention a donc pour but de générer des images associées à un contexte représentatif d'une réalité ou d'un espace s déterminé, comme un espace à trois dimensions, et en temps réel. Les images associées au contexte représentatif sont alors transmises à travers un réseau de communication à tous types de navigateurs connectés au réseau. io Dans un environnement de type Internet, un tel navigateur permet à l'utilisateur de consulter des documents et d'exécuter des scripts ou programmes permettant d'émettre notamment des requêtes et de recevoir des nouveaux documents sous la forme par exemple de liens hypertextes. is Selon un aspect de l'invention, l'architecture proposée est basée sur le principe client - serveur. Une première application centrale est constituée du côté serveur pour renvoyer au client un contexte dépendant de conditions d'émissions de requêtes comme un instant dans 20 l'évolution du contexte représenté, ou sur une requête de l'utilisateur, ou de l'un parmi une pluralité d'utilisateurs. La première application du côté serveur comporte également un moyen pour générer une représentation associée à la reconnaissance du type de client qui est connecté. 25 Selon un aspect de l'invention, la technique proposée est susceptible de traiter des clients qui sont : - les ordinateurs personnels connectés à Internet quelque soit leur niveau de puissance et selon les standards de navigateur de marché ; 30 - les assistants personnels connectés à Internet ; - les téléphones mobiles comportant une ressource de connexion au réseau Internet par exemple de type WAP ou d'autres types de réseaux comme les réseaux MMS et GPRS ; et - des dispositifs connectés à un réseau de communication comme un téléviseur interactif. Selon un aspect de l'invention, cette architecture permet d'offrir la possibilité d'adapter un service informatique comme un 5 service graphique aux capacités particulières de chaque type de client. Particulièrement, dans le cadre de jeux vidéo, on appelle rendu l'aspect particulier d'une image associée à un contexte représentatif d'une réalité virtuelle, notamment les textures des io images qui sont générées à l'aide de générateurs de rendu qui exigent une très forte capacité de calcul, jamais atteinte notamment sur les téléphones mobiles et même sur un grand nombre d'ordinateurs personnels connecté à Internet. Il en résulte que grâce à l'architecture de l'invention, les is services de rendu, notamment dans le cadre des jeux vidéo, peuvent être exécutés, puis transmis sous la forme du flux d'images et d'autres données à destination des machines client. Selon un autre point de vue de l'invention, l'architecture informatique de l'invention propose, par exemple dans le domaine 20 des jeux vidéo, la création d'une console virtuelle. Elle permet en effet d'accueillir sur une machine serveur un moyen d'émulation d'un client, ledit moyen étant doté d'une capacité de calcul de génération d'images et de génération de rendus, compatible avec des exigences de qualité allant au-delà 25 des moyens de calcul du client local. En effet, le client local ne dispose pas lui-même de la capacité suffisante de calcul. Selon l'invention, le client local conserve seulement la contrainte d'avoir une capacité de représentation des 30 représentations de contexte, comme des images ou séquences d'images de jeux vidéo qui lui sont transmises sur un réseau de télécommunication, comme le réseau Internet. 6 Un éditeur d'applications permet de produire au moins une application qui exploite des contenus composés d'au moins un ensemble d'images ou de séquences d'images complété, le cas échéant, de données de contexte comme des règles d'animation d'objets animés représentés dans l'ensemble d'images ou de séquences d'images. Lorsque un utilisateur veut accéder à une représentation du contexte, il dispose alors de ressources selon l'invention pour réaliser des opérations collaboratives sur une base de données multimédia représentative du contexte. io Pour atteindre ses objets, l'invention concerne un procédé pour générer des images associées à un contexte 3D en temps réel. Selon le procédé de l'invention, il est prévu une première étape d'édition d'au moins une application de gestion, puis une seconde étape d'enregistrement de l'application de gestion, puis 15 une troisième étape d'installation et d'enregistrement d'au moins un utilisateur doté d'un client pour une application enregistrée et une quatrième étape au cours de laquelle au moins un client émet et/ou reçoit au moins une requête telle que le contexte 3D est modifié en fonction notamment des interactions de chaque 20 utilisateur "client" à l'aide des requêtes et des règles d'animation pour une application déterminée et que cette modification est transférée sur la partie de représentation d'au moins un client. Selon un autre aspect, le procédé comporte une étape de détection du type de client pour en déduire le type de données et 25 de codes à échanger entre au moins un utilisateur et au moins un éditeur de contenus. Selon un autre aspect, le procédé comporte une étape de détection de la charge de serveurs de rendus et de diffusion retournant au moins une image associée à l'exécution d'une 30 application déterminée en fonction d'une requête de représentation dudit contexte 3D à destination d'au moins un organe de représentation de contexte de sorte que l'image et ou un script d'animation soit produit par un serveur disponible. 7 Selon un autre aspect, le procédé comporte une étape pour générer des objets complexes, composant un modèle d'intelligence artificielle sous la forme d'une classe et qui est destiné à être encapsulé dans un objet graphique associé au contexte 3D particulier de l'application concernée. L'invention concerne aussi un dispositif téléinformatique permettant de réaliser des opérations sur une base de données multimédia, notamment dans le cadre de l'exécution de jeux vidéo comme des jeux vidéo 3D, et mettant en oeuvre le procédé selon io l'une des revendications précédentes, caractérisé en ce qu'il comporte : - au moins un client comportant une ressource de représentations de contexte et un moyen pour émettre une requête ; 15 - une liaison de client ; et - un serveur comportant une ressource pour détecter le type de client qui transmet au moins une requête et un serveur d'applications pour transmettre la requête du client à un éditeur de contenus de sorte qu'en réponse au moins un contexte produit 20 sur la base d'une application particulière exécutée sur ledit serveur d'applications comme une image, une séquence d'images ou un objet comme un script, est retourné vers le client pour y produire une représentation sur un organe de représentation. Selon un autre aspect, le dispositif comporte un 25 gestionnaire de charges associé à un serveur d'applications de sorte que soit déterminé un serveur de rendu (34) et un serveur de diffusion pour retourner vers au moins un client une image ou un script quelque soit l'état de charge des autres serveurs. Selon un autre aspect, le dispositif comporte un automate, 30 qui comporte : - une ressource de test du traitement de requête ; - une ressource d'analyse contextuelle de requête ; 8 - une ressource pour générer un contenu de texte contextuel. - une ressource pour générer un contenu de texte contextuel et une collection de liens vers les images contextuelles qui sont disponibles sur le serveur de diffusion associé au client qui a produit la requête initiale. Selon un autre aspect du dispositif, les données et/ou les codes ou scripts échangés entre le client et le serveur sont encapsulés dans un ou plusieurs objets de type xml , traités io par des ressources d'analyse d'objets xml (parsers) pour en déduire, depuis les bases de données gérées sur le serveur, les données et les codes ou scripts nécessaires à la modification du contexte dont une représentation est attendue. Selon un autre aspect, le dispositif comporte une is ressource de réception de requêtes http sur l'automate avec un moyen d'interrogation de bases de données maintenues sur le serveur pour récupérer les données de caractères du terminal client. Selon un autre aspect du dispositif, au moins l'une des 20 entités client , meta et base est construite sur une machine virtuelle dotées de ressources de gestion d'objets d'animations associés au contexte 3D d'une application particulière exécutée sur le serveur d'applications. L'invention concerne aussi un système permettant 25 d'exploiter le procédé avec une architecture de distribution de représentations de contextes, notamment de contextes 3D (à trois dimensions) et de jeux vidéo, basée sur une architecture client û serveur et un moyen de connexion à un protocole de réseau multi plateforme connecté à un serveur d'application adapté. 30 Le serveur d'application est lui-même connecté à au moins un générateur de représentation de contextes, comme des contextes 3D et/ou des images de jeux vidéo. 9 Le générateur comporte un moyen de génération d'images en temps réel, d'une part, et un moyen pour interagir avec le serveur d'application en tant que service objet, d'autre part. Dans un mode particulier de réalisation, les connexions entre le serveur d'application et le générateur d'images sont adaptées dans le but de répondre à des contraintes de qualité nécessaire aux diverses représentations de contexte, comme les contextes 3D de jeux vidéo. D'autres caractéristiques et avantages de la présente io invention seront mieux apparents à l'aide de la description et des figues annexées parmi lesquelles : - la figure 1 est un schéma d'architecture de l'invention ; - la figure 2 est un schéma détaillé de la progression d'un échange entre au moins un client et l'application serveur dans un is mode de réalisation de l'invention de la figure 1 ; - la figure 3 est un détail de la transmission des requêtes et des représentations de contexte selon l'invention ; - la figure 4 est un schéma expliquant la répartition des ressources informatiques dans le cadre de l'invention ; et 20 - la figure 5 est un schéma bloc d'organisation du serveur d'application dans un mode particulier de réalisation de l'invention. A la figure 1, on a représenté un mode particulier de réalisation d'un système informatique selon l'architecture de 25 l'invention. A la figure 1, la partie "serveur" 2 est connectée par l'intermédiaire d'un réseau de communication, comme le réseau Internet 3, à au moins une partie "client" 1. Le serveur 2 comporte essentiellement un portail d'accès 5 30 auquel est connecté au moins un serveur d'applications 6 connecté à un éditeur de contenus 7. L'éditeur de contenus 7 coopère avec des moyens de mise à jour. Les éléments mis à jour sont manipulés par tous moyens à 10 l'aide d'un générateur d'applications, de manipulation et de représentation de contenus 3D, comme un moteur de jeux vidéo. Le client, qui peut être constitué par un ordinateur personnel, ou encore un téléphone mobile de type GSM, comporte essentiellement une partie de traitement 9 qui est directement connectée par un moyen connu comme un modem et, le cas échéant, d'un modem routeur, au réseau Internet 3. La partie de traitement 9 du client est connectée à un organe 10 construit de manière à produire une représentation du contenu en cours de génération sur l'application du côté serveur 2. De plus, en relation avec l'organe de traitement 9 et l'organe de représentation 10, il est prévu un organe 11 permettant à l'utilisateur du poste client 1 d'échanger des requêtes avec l'éditeur de contenus 7 et d'exécuter des actions ou des interactions avec la représentation du contenu 3D présentée sur son organe de représentation 10. Dans un exemple d'utilisation, on considère qu'une application particulière a été sélectionnée sur le serveur d'application 6 et a été mise en relation avec un client 1. Le client 1 produit une requête 12 d'ouverture d'une session de jeu vidéo à destination du portail d'accès 5 au serveur 2 qui comporte un moyen pour détecter le type de client. La requête d'ouverture contient notamment une donnée identifiant le type de client. Une ressource de détection de type de client est intégrée au portail 5 qui est capable de reconnaître le système d'exploitation ainsi que le processeur utilisé dans la partie de traitement 9 du client 1. Dans un mode particulier de réalisation, la ressource de détection de type de client produit une donnée présentée en entrée d'une ressource de choix du code convenable au client parmi les codes exécutables de l'application appelée par la requête d'ouverture et les codes compilés de manière correcte pour ce type de client. 11 A cette fin, le portail 5 transfère vers le serveur d'application 6 la requête avec l'identification du type de client. Le serveur d'application se met alors, à l'aide d'une liaison interne au serveur 2, en communication avec l'éditeur de contenus 7.

En fonction de la requête et de l'état de l'éditeur de contenus 7, ainsi qu'il sera décrit plus loin, le serveur d'applications 6 peut alors retourner ou bien une requête destinée à exécuter un script ou autre code sur le client 1, ou bien un flot de données de représentation comme une ou plusieurs images représentatives du contexte 3D de l'application en cours d'exécution. Ces données, codes ou images, sont transmises par un lien 14 au portail 5, qui la conforme selon le format ou le protocole désiré, comme le protocole http et détectés dans la donnée de types de client. Les données ainsi constituées sont transmises par le lien Internet 15 de retour. Le client, par sa partie de traitement 9, décode alors les données et, en fonction des codes déjà implantés, ou bien exécute le nouveau code transmis, ou bien transfère les données de représentation, comme une image ou une séquence d'images sur l'organe de représentation 10. Selon l'invention, l'architecture informatique proposée comporte au moins une unité 8 connectée par une connexion 16 à l'éditeur de contenus 7 du côté serveur.

Cette unité de programmation 8 permet de réaliser à l'aide de moyens disponibles dans l'éditeur de contenu 7, ainsi qu'il sera décrit plus loin, des représentations d'un contexte 3D et particulièrement les éléments graphiques et d'intelligence artificielle utile à la réalisation d'un jeu vidéo particulier.

Ainsi, au moins un tel poste de programmation 8 est fourni à la disposition de chaque concepteur ou créateur d'un jeu vidéo déterminé. Dans un mode particulier de réalisation, l'unité de programmation 8 est intégré au serveur 2. 12 Dans un autre mode de réalisation, le poste de programmation 8 est lui-même un client qui est connecté par sa propre connexion Internet à l'éditeur de contenus 7. Particulièrement, dans un tel mode de réalisation, la liaison 5 entre l'unité de programmation 8 et l'éditeur de contenu 7 est une liaison sécurisée par exemple le protocole http. On va maintenant spécifier les étapes principales du procédé de l'invention. Lors d'un première étape, un producteur de contenus w composés d'au moins un ensemble d'images ou de séquences d'images complété, le cas échéant, de données de contexte comme des règles d'animation d'objets animés représentés dans l'ensemble d'images ou de séquences d'images, entre en relation avec le serveur d'applications 6 par l'intermédiaire du module 8 et 15 de l'éditeur de contenus 7. L'application est alors enregistrée, lors d'une seconde étape, dans un moyen de gestion des applications du serveur d'applications 6. En particulier, dans le cadre d'une exploitation 20 commerciale, cette seconde étape comporte une partie de transaction permettant la création d'un contrat d'hébergement entre le producteur de contenus et le gestionnaire du serveur d'applications 6. Lors d'une troisième étape, au moins un utilisateur doté 25 d'un client 1 et connecté par le lien 3 convenable s'enregistre comme utilisateur "client" d'une application déterminée du serveur d'applications 6. En particulier, dans le cadre d'une exploitation commerciale, cette troisième étape comporte une partie de 30 transaction permettant la création d'un contrat d'utilisation entre le gestionnaire du serveur d'applications 6 et l'utilisateur client sur le poste client 1. 13 Cette partie de la troisième étape est préférentiellement complétée par une mise en relation du contrat d'hébergement spécifié lors de la seconde étape, et associé à l'application choisie par l'utilisateur "client" lors de la troisième étape.

Enfin, lors d'une quatrième étape, au moins un client 1 émet et/ou reçoit au moins une requête ainsi qu'il a été décrit plus haut lors de la description de la figure 1. Il en résulte, dans cette quatrième étape, que le contexte 3D est modifié en fonction notamment des interactions de chaque utilisateur "client" à l'aide des requêtes et des règles d'animation pour une application déterminée et que cette modification est transférée sur la partie de représentation d'au moins un client. A la figure 2, on a représenté sous forme d'un schéma la progression d'un dialogue entre un client et le serveur d'application 17. Le client 1 est connecté par l'intermédiaire du réseau Web 3 à la ressource d'identification de plateforme et le signal ou message reçu est décodé et transmis à un serveur frontal 20 à l'intérieur du portail 5.

Le serveur frontal 20 sert, par une connexion 22, le message à la partie active 24 du serveur d'application. La requête transmise par le client 1 progresse alors par un lien 26 vers un gestionnaire de charges de serveur 28 qui répartit, en fonction de l'identification de la requête, cette requête par des canaux 30 vers une pluralité 32 de serveurs Web d'images et de serveurs Web de rendus. Dans le cas de la requête présentée, on a représenté une chaîne constituée d'un serveur de rendu 34 qui transfère ses données de rendu vers un serveur d'images 36.

Le serveur d'images 36 est connecté par une liaison convenable 38 à la ressource de connexion sur le Web 40 de sorte que les données d'images ou d'autres données, ainsi qu'il a été décrit plus haut, sont alors transmise par le canal Web vers le client et exploité, ainsi qu'il a été décrit plus avant. Selon un premier aspect de l'invention, le gestionnaire de serveurs 28 comporte un moyen 30 de détection de la puissance s totale de calcul demandé par les différents clients à l'ensemble des serveurs, et notamment des serveurs d'images et des serveurs de rendu, de façon à offrir la meilleure performance en équilibrant ces tâches sur les différents serveurs disponibles. Une fois la charge établie par la ressource 30 d'équilibrage 10 des charges, la ressource 30 recherche dans la liste 32 des paires de serveurs Web d'images et de rendu, comme la paire de serveurs 34, 36, les paires de serveurs qui permettent de répondre en équilibrant la charge sous une contrainte de temps de réponse déterminée, ce temps de réponse prenant aussi en 15 compte le type de plateforme et le type de connexion entre le serveur et le client, réellement demandeur. Par exemple, pour une liaison rapide comme une liaison ADSL, les temps de réponse seront demandés plus courts que pour une liaison de type RTC pour un modem analogique 20 connecté au serveur frontal 40. On voit donc que cette architecture présente deux avantages sur l'état de la technique qui sont : - permettre la détection du type du client demandeur, ou requêteur, de façon à mettre à sa disposition des codes et des 25 données de représentation de contexte adaptées à ses ressources informatiques ; et -permettre d'équilibrer la charge de calcul de manière à offrir le meilleur service possible même pour des clients dont la ressource de traitement local est faible. 30 A la figure 3, on a représenté sous une autre forme l'architecture des figures 1 et 2 pour détailler les éléments matériels ainsi que les différentes étapes du procédé de gestion et de contrôle d'un contexte 3D dans le cadre de l'invention. 15 Le client 1 est toujours connecté par l'intermédiaire d'un réseau, comme le réseau Internet 3, au serveur. Dans le mode de réalisation, on considère que le protocole de connexion utilisé est le protocole http. D'autres protocoles sont 5 bien entendu utilisables. Le client 1 produit, ainsi qu'il a déjà été décrit une requête cliente à destination d'un automate 50 installé sur le serveur, ainsi qu'il a été décrit ci-après. L'automate 50, par l'intermédiaire du serveur Web frontal, io exécute, lors d'une étape El, l'analyse de la requête cliente reçue. Une ressource 54 de test du traitement de la requête reçoit la requête, et exécute un test E2 d'arrêt si le requête n'a pas été traitée en tant que demande de représentation. Mais la réponse 15 peut contenir d'autres données, comme des donnés de script. L'étape E2 permet de produire un message d'erreur contextuel 60 qui est retourné vers le client. Ce message d'erreur permet d'indiquer au logiciel exécuté sur le client que la requête émise n'a pas été traitée. 20 Si la requête a été traitée correctement, le serveur d'application 56 est alors activé et exécute lors d'une Etape E3, l'analyse contextuelle de la requête. Cette analyse contextuelle permet par exemple de retirer de la requête les éléments qui correspondent à des instructions 25 ou à des commandes qui doivent être interprétées par un système d'intelligence artificielle, notamment pour exécuter le jeu vidéo en cours d'exécution. A cette fin, le serveur d'application 56 dialogue avec une base de données 58 associée à l'application qui a été détectée 30 lors de l'analyse de la requête de l'étape El. Cette base de données 58 permet de fournir les éléments de réponse de l'analyse contextuelle. 16 Le serveur d'application 56 exécute alors ensuite, lors d'une étape E4, le test de la nécessité de générer une ou plusieurs images contextuelles, en fonction notamment des éléments de réponse fournis par la base de données 58 d'analyse contextuelle. Ce test E4 permet de séparer du flux les requête correspondantes à de l'analyse contextuelle en mode texte, par exemple, pour activer un moteur d'intelligence artificielle demandant des images ou des séquences d'images représentatives du contexte 3D, par exemple, dansl'exécution d'un jeu vidéo. A l'issue de ce test E4, lors d'une étape E5, si on détecte dans le test E4 qu'il n'y a pas de nécessité de générer une image contextuelle, le serveur d'application 56 génère un contenu 58 de texte contextuel. Si par contre, l'étape E4, est positive, le serveur d'application 56 exécute à l'aide de la ressource d'analyse des capacités du client, un test de capacité client dans une base de données 60 lors d'une étape E6. En fonction de l'analyse des capacités des clients réalisée lors de l'étape E6, la ressource de gestion de la charge de travail sur l'ensemble des serveurs de rendu et de diffusion disponible, est alors exécutée à l'aide du gestionnaire du serveur de rendu lors d'une étape E7. Le serveur de rendu 62 correct est alors adressé de façon à exécuter, lors d'une étape E8, le rendu de l'image contextuelle qui sera générée lors d'une étape non représentée ici par le serveur d'image contextuel. Le serveur de diffusion 64 permet alors de mettre à disposition l'image sur le serveur de diffusion 64' lors d'une étape 30 E9. L'automate 50 exécute alors une étape El0 d'arrêt à l'issue de laquelle l'automate 50 génère un contenu 66 de texte contextuel et une collection de liens vers les images contextuelles 17 qui sont disponibles sur le serveur de diffusion 64' associé au client 1 qui a produit la requête initiale. L'ensemble des messages 60, 60', 60" sont transmis dans une requête http vers le client dont la ressource de traitement 5 peut alors exploiter les liens ainsi que le contenu de textes contextuels à l'aide de sa propre ressource de traitement 9 qui a été décrite à l'aide de la figure 1. A l'issue de ce traitement ou au moins à l'issue de la récupération de l'ensemble des données, le client 1 produit une io requête indiquant au serveur de diffusion 64 que l'ensemble des messages et des liens a été exploité correctement. Dans un mode préféré de réalisation les données et/ou les codes ou scripts échangés entre le client et le serveur sont encapsulés dans un ou plusieurs objets de type xml . De tels 15 objets présentent ainsi qu'il est connu une structure séquentielle et arborescente et tant le client que le serveur sont alors équipés autant que de besoin de ressources d'analyse d'objets xml (parsers) pour en déduire, depuis les bases de données gérées sur le serveur, les données et les codes ou scripts nécessaires à 20 la modification du contexte dont une représentation est attendue. Dans un mode préféré de réalisation, le serveur d'applications 6 coopère avec une ressource d'analyse des capacités du client. A cette fin, chaque client comporte une ressource pour générer des données de description des capacités 25 du client qui sont alors transmises dans la requête du client vers l'automate 50 à l'aide d'une ressource de connexion http La ressource de connexion http fournit ainsi qu'il est connu une requête http selon une méthode prédéfinie comme une méthode POST ou une méthode GET dans laquelle sont insérées 30 les données décrivant les capacités de calcul du client. La requête émise par le client et alors décodée par une ressource de décodage de requêtes http du serveur qui en déduit à l'aide d 18 `une ressource de détection de capacité de client, les données transmises en relation avec le client. Particulièrement, une telle formulation de requête http peut comporter un champ User-Agent qui indique le type de navigateur installé sur le client 1 (ressource de traitement) et par conséquent les capacités induites par les fonctionnalités du navigateur Internet. La requête http peut aussi comporter un champ x-wap-profile qui fournit un localisateur de ressource de genre url qui permet de se référer au site du constructeur du io terminal client et de récupérer un fichier de caractères au format xml et qui indique l'ensemble des caractères du terminal comme les caractéristiques et ressources de gestion de l'écran, du processeur de la mémoire et du système d'exploitation. 15 La ressource de réception de requêtes http sur l'automate 50 comporte un moyen d'interrogation de bases de données maintenues sur le serveur pour récupérer les données de caractères du terminal client. Si le terminal client est inconnu, la ressource de réception de requêtes http valide une 20 ressource de création d'un enregistrement des caractères du nouveau terminal client dans la base de données selon les méthodes indiquées ci-dessus. Dans un mode préféré de réalisation, l'automate 50 comporte une ressource d'analyse de charge (voir gestionnaire de 25 charge 28, figure 2) des serveurs de rendus et des serveurs de diffusion. Chaque serveur est doté d'un processeur (ou groupe de processeurs) et d'un espace de stockage de données qui sont déterminés et enregistrés dans une base de données du 30 gestionnaire 29 en relation avec chaque serveur. Sur cette base la ressource d'analyse de charge détermine une fonction dépendant du nombre d'utilisateurs connectés au serveur et de la bande passante de chaque lien de connexion. La ressource 19 d'analyse de charge compare alors cette focntion avec l'utilisation réelle de chaque serveur et détermine les serveurs disponibles pour chaque nouvelle connexion ou le traitement de chaque nouvelle requête. On note que l'utilisation de l'analyse de charge est effectuée au niveau du serveur d'applications dans chacun des espaces méta ou de base , ainsi qu'il sera défini plus loin. Chaque serveur de diffusion ainsi qu'il a été défini plus haut dispose d'une ressource de mise à disposition de l'image qui assure la distribution d'une image déterminée à l'adresse Internet d'un utilisateur déterminé. Image et utilisateur sont déterminé sur la base d'une requête ou d'un script d'animation, ainsi qu'il a été décrit plus haut. A cette fin, la ressource de mise à disposition d'images reçoit un identifiant du client destinataire lors de sa première connexion qui permet à la ressource de faire un lien entre une image à diffuser, un utilisateur et son adresse Internet ou autre sur le réseau de diffusion. L'identifiant reste valide pendant tout une session tant que l'utilisateur et le serveur d'applications restent connectés. À la figure 4, on a représenté un dispositif selon un autre aspect de l'invention. Le dispositif de l'invention est destiné à exécuter une application logicielle de représentations d'un contexte comme celui d'un jeu vidéo à trois dimensions. A ce propos, on remarque que l'invention ne se limite pas à une application de son concept à un jeu vidéo, mais au contraire, l'invention trouve son application pour la gestion et la distribution téléinformatique permettant de réaliser des opérations collaboratives sur une base de données multimédia. Ce sera le cas d'une application de conception assistée sur ordinateur regroupant plusieurs agents. Le contexte dans lequel agissent les agents peut aussi être un contexte réel comme celui d'un champ opératoire chirurgical, ou d'une pluralité de tels champs opératoires avec des terminaux 20 clients pouvant par exemple coopérer avec des instruments chirurgicaux dont la manipulation est contrôlée dans le temps et l'espace et des capteurs d'exploration de champ opératoire permettant de constituer un contexte 3D dans lequel un ou plusieurs chirurgiens peuvent opérer, avec le concours d'experts travaillant dans un espace virtuel représentant un état du ou des champs opératoires. Dans le concept de l'invention, chaque application logicielle conçue dans le cadre de l'invention, produit une io séquence d'images ou plus généralement de représentations d'un espace à trois dimensions 3D à destination d'au moins un organe de représentation sur un client, comme un écran d'affichage d'images d'un ordinateur. À cette fin, l'application logicielle est exécutée sur un processeur sous la forme de règles 15 préenregistrées et en détectant des événements comme des interactions entre d'une part un ou plusieurs utilisateurs comme des joueurs de jeu vidéo et d'autre part des élément de représentation, comme des personnages dans un jeu vidéo en interactions avec un environnement comme un décor fixe ou 20 mobile. Le dispositif de l'invention adapté à exécuter une telle application comporte trois parties qui sont respectivement : -- une partie dite client 70, sur laquelle se trouvent implantées des ressources d'interface avec l'application serveur qui sera décrite plus loin et des ressources gérant les interactions 25 avec l'utilisateur, comme un joueur dans le cas d'une application à un jeu vidéo ; -- une partie dite méta partie 72 sur laquelle se trouvent implantées les ressources d'exécution d'intelligence artificielle de haut niveau, des ressources de persistance et les 30 différents services permettant notamment de gérer les connexions ou communications de données entre les trois parties du dispositif de l'invention ; et 21 -- une partie dite partie de base 74 sur laquelle se trouvent implantées les ressources d'exécution d'intelligence artificielle de bas niveau, ainsi que les services de rendu d'images qui ont déjà été décrit.

Chacune des parties 70, 72 ou 74 communique avec l'une ou l'autre des autres parties ou bien par une connexion directe si les deux parties en communications font partie d'une même machine ou bien à un canal de communication comme à canal téléphonique associée à un réseau Internet dans le cas où io chaque partie du dispositif de l'invention est associée à une ou plusieurs machines interconnectées à ce réseau. Sur la partie client 70, on trouve une mémoire 82 stockant des objets statiques qui sont constitués par des fichiers de type html ou de type flash dans le cas d'un réseau is Internet web ou par des fichiers de type chtml ou de type wml dans le cas d'un réseau de téléphonie mobile GSM. On trouve aussi des objets dynamiques qui sont constitués par des objets ActiveX dans le cas d'un réseau Internet web ou par des objets Doja/MIDP dans le cas d'un réseau de téléphonie mobile GSM. 20 Ces différents objets statiques et dynamique peuvent être ou bien téléchargés lors d'une requête en provenance à de la partie de base 74 ou bien mémorisés à donneur par l'exécution d'un logiciel d'installation d'une partie de l'application. Sur la partie de base 74, on trouve une mémoire 80 25 stockant des objets statiques comme des fichiers images de différents types comme des fichiers JPEG, GIF ou PNG ainsi que des objets dynamiques constitués par ou constituant un moteur d'animation d'objets graphiques 3D. Dans un mode préféré de réalisation, la partie dite méta 30 partie 72 comporte une ressource d'analyse contextuelle dont le déroulement a été décrit notamment à l'aide de la figure 3. La ressource d'analyse contextuelle reçoit le corps de la requête provenant du client 70 par le lien 78. Ce lien peut être une 22 connexion par un réseau téléinformatique ou encore être un line natif c'est-à-dire que le client est matériellement une partie du serveur. Quand la requête contient une commande,n la ressource d'analyse contextuelle extrait de la structure de l'objet xml qui exprime la commande la scène graphique ou contexte 3D concerné et l'objet d'animation sur lequel la commande s'applique. Ces informations décodées par la ressource d'analyse contextuelle de la méta partie 72 lui permettent de déterminer un identifiant unique qui est utilisé comme une référence de io repositionnement de l'objet d'animation dans la scène graphique dans l'espace mémoire représentant le contexte 3D dans les bases de données qui mémorisent ledit contexte 3D. Dans un mode préféré de réalisation du dispositif de la figure 4, la partie client 70 comporte une ressource d'interface 15 homme - machine qui est réalisée sous la forme d'une machine virtuelle aussi simple que possible et capable de fonctionner sur tous les types de terminaux clients connectables ou associables au serveur d'applications de l'invention qui, à la figure 4 a été représenté à droite du trait mixte et comporte 20 essentiellement la partie méta partie 72 et la partie de base 74. L'interface homme -machine est créée sur le terminal client 70 sur la base d'un objet xml qui est chargé par exemple lors de la procédure d'enregistrement de l'utilisateur client (troisième étape du procédé de l'invention). Lorsque l'objet 25 xml est développé sur le navigateur ou ressource de traitement (9 ; Figure 1) du terminal client 70, il constitue une première couche de gestion des périphériques d'interaction avec l'utilisateur qui sert le terminal client. , comme un clavier, une souris, une boule de navigation, une manette à 2 ou 3 dimensions 30 de manipulation, une caméra vidéo, etc. L'interface homme-machine qui reçoit les événements de ces périphériques les retournent sous forme de requêtes de commande vers la partie meta partie 72 de sorte que le contexte 3D soit modifié en 23 réponse et une nouvelle représentation diffusée par les serveurs de diffusion vers au moins la partie de représentation (écran) (10 ; Figure 1) d'un terminal utilisateur. Préférentiellement aussi, l'interface homme machine développée sur le client 70 comporte une ressource de réponse dynamique à des requêtes ou scripts transmis par la partie méta partie 74, par exemple pour créer, dessiner ou animer des boutons ou autres zones graphiques représentées sur l'écran de représentation de contexte sur le terminal. io Dans un mode préféré de réalisation, l'entité meta partie 74 est réalisée sur le serveur d'applications sous la forme d'une machine virtuelle qui comporte une ressource de gestion d'intelligence artificielle de haut niveau. La ressource de gestion d'intelligence artificielle de haut niveau est sous le contrôle de 15 l'application logicielle enregistrée dans les bases de données du serveur d'applications. Particulièrement, en fonction des scripts d'animation édités à l'aide de l'éditeur de contenus avant l'enregistrement de l'application qui sont appelés par une requête ou une commande d'un utilisateur, la ressource de gestion 20 d'intelligence artificielle de haut niveau comporte des moyens pour rendre persistants des objets d'animation, ou des variables descriptives d'un état du contexte 3D lors de l'évolution dans le temps. La ressource de gestion d'intelligence artificielle de haut 25 niveau comporte aussi des moyens de réception d'événements d'entrée fournis par les diverses interfaces homme û machine des divers client qui lui sont connectés (au moins un). Ces événements ont déjà été décrits ci-dessus. Une fois reçu un événement d'entrée, la ressource de gestion d'intelligence 30 artificielle de haut niveau exécute le script d'animation associé au contexte 3D en cours et communiqué par l'application concernée de façon à créer des informations caractéristiques du contexte 3D et d'au moins un objet d'animation. 24 La ressource de gestion d'intelligence artificielle de haut niveau comporte aussi des moyens pour créer ou détruire les informations qu'elle possède et passer des ordres ou commandes de représentation aux serveurs de rendus (installés dans la partie 5 de base 74). La partie méta partie 72 comporte aussi des ressources de modification des interfaces homme ù machine des clients connectés pour les adapter au contexte 3D en cours, par exemple selon les modalités décrites plus haut lors de la spécification de io la ressource de réponse dynamique à des requêtes ou scripts de la partie client 70. La méta partie 72 comporte aussi des ressources pour exécuter des gestionnaires d'événements ( handlers ) associés à des méthodes appelées par d'autres scripts agissant sur au 15 moins un objet d'animation à l'aide de l'une des dites méthodes. Dans un mode préféré de réalisation, la partie de base 74 du dispositif de l'invention est aussi constituée par une machine virtuelle dotée d'une ressource pour exécuter le processus de rendu. Les scripts interprétés sont associés à des 20 librairies spécifiques à la manipulation des objets d'animation dans le contexte 3D de l'application en cours d'exécution sur le serveur d'applications 72, 74 de l'invention. Sur cette base, les scripts de la ressource pour exécuter le processus de rendu permettent de manipuler les objets graphiques, de calculer leur 25 dynamique dans le contexte 3D et d'appliquer des textures ou des effets associés aux matériaux composant les divers objets contenus dans le contexte 3D dont au moins une représentation doit être diffusée vers au moins un client, suite à au moins une requête et l'exécution d'au moins un script de manipulation. 30 Préférentiellement, la machine virtuelle de la partie de base 74 est une machine à états finis, chaque état de la machine à états finis étant appelable par une ressource de la partie meta partie 72. La machine d'états finis peut 25 fonctionner en permanence, c'est-à-dire ne pas avoir de test de fin. Selon un autre aspect de l'invention, il est prévu de générer des objets complexes, chacun de ces objets complexes s s'étendant et s'exécutant sur les trois parties client 70, meta 72 et base 74 et composant un modèle d'intelligence artificielle sous la forme d'une classe au sens de la programmation orientée objet et qui est destiné à être encapsulé dans un objet graphique associé au contexte 3D particulier de io l'application concernée. On va maintenant décrire, à l'aide de la figure 5, un mode de réalisation d'un serveur centralisé permettant de mettre en oeuvre le procédé de l'invention. Le client 94 est doté d'une connexion 96 avec le serveur d'applications 92. Cette connexion 15 permet au client 94 de présenter une requête au serveur d'applications 92. La requête produite par le client est interprétée par un moteur d'intelligence artificielle de haut niveau qui est intégré au serveur d'applications 92. Ce moteur est implémenté à l'aide d'un gestionnaire d'applications 98 qui communique avec 20 une base de données 90 associée au serveur d'applications 92 de façon à disposer d'une base de règles et d'une base de faits pour le fonctionnement du moteur d'intelligence artificielle de haut niveau.

25 Par une pluralité de liens 100, le gestionnaire d'applications 98 communique avec une pluralité de gestionnaire de services 101,102, 103,

. qui seront décrits plus à fond. La pluralité de gestionnaires de services constitue une première couche du serveur d'applications 30 Le serveur d'applications 92 comporte une seconde couche 106 dans laquelle est implémenté une ressource de répartition de charge de travail entre eux une pluralité de serveur de rendu 115 26 -- 114 par pilotage d'un module d'aiguillage 104 de requête de rendu vers un serveur de rendu disponible.. .DTD: Un module d'aiguillage 118 permet ensuite de transmettre le produit du service de rendu sélectionné dans la seconde couche 106 vers une troisième couche 107 dans laquelle est disposé une pluralité de serveurs de diffusion 120 -- 128, le module d'aiguillage 118 étant activé de manière à détecter le serveur de diffusion disponible pour l'exécution de la suite de la io requête présentée par le client 94 et de traiter le service de rendu exécuté à la seconde couche précédente. L'image ou la séquence d'images, ou encore l'objet dynamique produit par l'intelligence artificielle de haut niveau exécutée au niveau du gestionnaire d'applications 98 est alors transmis par le lien 96' en réponse au 15 client 94 de sorte que une représentation est alors modifiée sur le dispositif d'affichage ou de représentation du client 94 ainsi qu'il a déjà été décrit.

Les connexions entre les différents serveurs qui composent 20 les architectures sont des connexions permanentes. Toutes les informations relatives au fonctionnement des serveurs sont centralisées dans le gestionnaire d'applications 98. Un serveur d'applications comme le serveur 101 comporte une mémoire et un processeur ou une puissance de traitement local pour exécuter 25 une application particulière comme un jeu vidéo déterminé ou une partie un jeu vidéo. Chaque serveur d'applications comme le serveur 101 possède son propre gestionnaire de serveur et une ressource de dialogue avec le gestionnaire d'applications 98 pour l'envoi de commandes au serveur de rendu affecté par le moyen 30 d'aiguillage 104.

Chaque serveur d'applications comme le serveur 101 est assuré par le gestionnaire d'applications 98 de trouver au moins 27 un serveur de rendu disponible et au moins un serveur de diffusion 120 -- 128 dans la troisième couche.

On va maintenant décrire un mode particulier de réalisation d'un protocole d'échange entre le gestionnaire d'applications 98 et un serveur de rendu comme le serveur 110. L'application exécutée sur le serveur d'applications concerné 101 -- 103 ... est chargée automatiquement au démarrage du serveur de rendu. Chaque requête produite par l'application répond à un format io prédéterminé qui assure la standardisation des différentes applications qui peuvent être accueillies simultanément sur un même serveur 92. Dans un mode particulier de réalisation le formatage qu'une telle requête système comporte quatre champs qui sont respectivement : 15 -- le champ de taille de mémoire BufferSize ; - - le champ d'identification de l'application comme par exemple le nom du jeu exécutée IdGame ; - - le champ d'identification du serveur de diffusion destinataire de la requête IdSTRDS ; et 20 -- un corps de requête dont le contenu peut être déterminé par l'application proprement dite.

Dans un mode particulier de réalisation, le gestionnaire d'applications comporte un moyen de détection de corps de 25 requête dans chaque requête système de sorte que ce moyen de détection émet un message d'alarme indiquant une réception erronée de requête système à destination du gestionnaire d'applications 98.

30 Dans un mode particulier de réalisation, le corps de requête de chaque requête système est composé des informations suivantes : -- le nombre d'arguments de la requête ; 28 - - l'identifiant de la méthode appelée par la requête système présentée ; et - - la succession des arguments dénombrés par le nombre d'arguments de la requête indiqué ci-dessus, chaque argument pouvant présenter un type particulier et déterminé de sorte qu'il soit reconnu par les différents processeurs du serveur d'applications.

On va maintenant décrire un mode particulier de réalisation io d'un protocole d'échange entre le gestionnaire d'applications associé à une application particulière (comme le gestionnaire 101, 102 ou 103 à la figure 5) et un serveur de rendu comme le serveur 110 (figure 5). La discussion entre le gestionnaire d'applications et le serveur de rendu déterminé par le module 15 d'aiguillage correspondant est en sens unique de sorte que le gestionnaire d'applications ne recevra pas de réponse à sa requête. Dans un cas particulier, le serveur d'applications 92 comporte un interpréteur TCP qui produit un message à destination du gestionnaire d'applications qui la transmis au 20 serveur de rendu cible. Le gestionnaire d'applications produit une requête d'applications qui comporte une pluralité de champs séquentiels qui sont : -- un champ de définition de la taille mémoire BufferSize ; -- un champ d'identification de l'application comme un jeu 25 IdGame -- un champ d'identification du serveur de diffusion cible IdSTDS ; -- un champ d'identification de l'utilisateur IdUser qui permet d'identifier le producteur de l'application demandée sur le serveur 30 d'applications 92 ; -- un champ d'identification du joueur au client IdPlayer qui permet d'identifier le client 96 qui s'est connecté au serveur d'applications 92 ; 29 - - un champ d'identification du format de l'image demandée au serveur de diffusion comportant par exemple la hauteur et la largeur de l'image ainsi que la qualité de sa résolution d'image et le type de l'image ainsi que son encodage ; -- un champ déterminant une limite Limit ; - - un corps de requête Body .

Dans un mode particulier de réalisation, le gestionnaire d'applications comporte un moyen de détection de corps de io requête dans chaque requête d'applications de sorte que ce moyen de détection émet un message d'alarme indiquant une réception erronée de requête d'applications à destination du gestionnaire d'applications 101, requête associée à une application particulière comme un jeu déterminé. 15 La requête d'applications peut être simplifiée quand elle ne s'adresse pas directement à un serveur de rendu mais qu'elle sert par exemple à produire un objet à transmettre au client comme une instruction ou une règle de script produite par un moteur 20 d'intelligence artificielle de bas niveau associé au serveur de diffusion de la troisième couche 107. 25 On va maintenant décrire un mode particulier de réalisation d'un protocole d'échange entre un serveur de rendu activé par une requête client et le serveur de diffusion associé par le moyen d'aiguillage 118 sur le troisième niveau 107 du serveur d'applications 92. Dans ce mode particulier de réalisation, l'échange est en sens unique et, de même que dans le cas de l'échange précédent, le serveur de rendu ne recevra pas de 30 réponse à sa requête.

Dans ce mode particulier de réalisation, la tâche effectuée par le serveur de rendu concerné est envoyé au serveur de 30 diffusion par une encapsulation dans une requête http:// dont l'en-tête est du type : POST/recupBuffer HTTP/1/1 cette méthode POST étant suivie de l'identification de l'hôte, c'est-à-dire du serveur de diffusion concerné 120 -- 128, puis d'une indication de la taille de la tache effectivement transmise par le serveur de rendu et enfin d'une indication de l'état de la connexion qui doit être maintenue active dans l'état KEEP-Alive défini dans le protocole http. i0 La mémoire effectivement affectée à la description de la tache effectivement transmise par le serveur de rendu contient les champs suivants : - - l'identification de l'utilisateur IdUser déjà définie ci-dessus ; 15 -- l'identification du nombre des éléments dans la description de la tâche effectivement transmise par le serveur de rendu ; - - la liste des types de chaque élément utilisé dans la description de la tâche effectivement transmise par le serveur de rendu ; -- la liste détaillée des éléments utilisés dans la description de la 20 tâche effectivement transmise par le serveur de rendu ; et -- la liste des données spécifiant les éléments utilisés dans la description de la tâche effectivement transmise par le serveur de rendu. 25 On va maintenant décrire dans un mode particulier de réalisation des ressources dont doivent être dotées le gestionnaire d'applications pour effectuer le traitement d'une requête créée dans le cadre d'une application sélectionnée. Le gestionnaire d'applications comporte des moyens pour gérer 30 chaque serveur ou gestionnaire d'application particulière ainsi que chacun des serveurs de rendu qui ont été décrit ci-dessus. Le gestionnaire d'applications comporte aussi des moyens pour traiter chacune des réponses des différents serveurs et 31 notamment des serveurs de rendu et des serveurs de diffusion que l'action exécutée ait conduit à une réussite, ou à un échec d'un type quelconque déterminé.

Dans un mode particulier de réalisation, le gestionnaire d'applications comporte un moyen pour tenir un registre de l'état de service des différents serveurs et notamment des serveurs de rendu et des serveurs de diffusion disponibles ainsi que des serveurs qui sont occupés par le traitement d'une requête en lo cours ou qui sont en état de défaillance. Le registre permet de tenir la mémoire pour chaque serveur de son état de fonctionnement défini par : le type du serveur ; l'identification duserveur 15 l'adresse Internet IP et le port de la machine sur laquelle le serveur est exécuté ; son état de fonctionnement ; et dans le cas d'un serveur de rendu : le taux d'occupation de sa puissance de traitement ; 20 son nombre de connexions ; les seuils critiques et non critiques mis à jour périodiquement selon une période de temps déterminé.

Dans un mode particulier de réalisation, le gestionnaire 25 d'applications comporte aussi une ressource associée à chaque serveur d'application particulière permettant de mémoriser la liste de tous les serveurs de rendu et de tous les serveurs de diffusion utilisé ainsi que les applications chargées.

30 Dans un mode particulier de réalisation, le gestionnaire d'applications comporte aussi une ressource associée à chaque serveur de rendu permettant de mémoriser la liste de tous les 32 serveurs d'application particulière qu'il utilise et toutes les applications chargées.

Dans un mode particulier de réalisation, le gestionnaire d'applications comporte une ressource d'ajout d'un serveur de diffusion.

Dans un mode particulier de réalisation, le gestionnaire d'applications comporte une ressource de suppression d'un io serveur de diffusion.

La disposition de ces deux ressources permet d'assurer une capacité d'adaptation du serveur d'applications de l'invention au nombre de clients et d'applications qu'il peut héberger. Ainsi, le is serveur peut accueillir une seule application comme un jeu vidéo 3D et quelques dizaines de clients ou plusieurs dizaines de jeux 3D avec des milliers de clients connectés au moins temporairement. Il suffit d'augmenter ou de réduire le nombre des serveurs composants dans le serveur proprement dit. 20 On va maintenant décrire dans un mode particulier de réalisation une ressource destinée à gérer les erreurs qui peuvent survenir lors du traitement d'une requête dans le gestionnaire d'applications. Selon l'invention, on a analysé trois niveaux de 25 sévérité pour les problèmes : - - les problèmes mineurs qui constituent des erreurs ponctuelles et qui doivent être enregistrées dans un journal des erreurs ; - - les problèmes majeurs dont la solution est trouvée par l'exécution d'un script de résolution de problèmes enregistrés 30 dans le gestionnaire d'applications et qui est signalé aux administrateurs des différents serveurs du gestionnaire d'applications de l'invention ; et 33 -- les problèmes critiques nécessitant une intervention humaine parce que, notamment, aucun script de résolution de problèmes enregistré dans le gestionnaire d'applications n'est efficace. À cette fin, la ressource de gestion des erreurs du gestionnaire d'applications comporte un moteur d'exécution de scripts de résolution d'erreurs ainsi qu'une application de gestion de journal des erreurs qui mettent en oeuvre la typologie des problèmes décrits ci-dessus. i0 On va maintenant décrire dans un mode particulier de réalisation une ressource permettant à un utilisateur du gestionnaire d'application de l'invention d'interagir avec les ressources précitées. II s'agit essentiellement d'une interface graphique qui 15 comporte des commandes permettant l'ajout, la suppression, la modification d'une adresse Internet IP, la désactivation instantanée ou momentanée, des différents serveurs et gestionnaires d'application particulière et le gestionnaire d'applications de l'invention. 20 On va maintenant décrire dans un mode particulier de réalisation, une ressource du gestionnaire d'applications capables d'orchestrer le chargement et le démarrage d'une application particulière du gestionnaire d'application particulière. La 25 ressource d'orchestration d'application particulière comporte un moyen de choix des serveurs de rendu et des serveurs de diffusion associés à l'application particulière que l'on souhaite inscrire dans le gestionnaire d'applications de l'invention. Dans un mode particulier de réalisation, le moyen de choix des serveurs 30 de rendu et des serveurs de diffusion détectent de manière automatique les serveurs de rendu et les serveurs de diffusion disponibles et comporte un moyen permettant de lisser la charge 34 de travail des seconde et troisième couches du serveur représenté à la figure 5.

La ressource d'orchestration comporte ensuite un moyen de connexion à la base de données 90 (Figure 5) et de vérification de la validité de l'application particulière que l'on souhaite inscrire dans le serveur d'applications de l'invention. A ce stade de l'orchestration des applications particulières, l'application particulière en cours de chargement n'est pas encore inscrite io dans le serveur.

La ressource d'orchestration comporte ensuite un moyen de vérification de la validité des serveurs de rendu concerné par l'application particulière a chargé. En cas d'échec, le serveur de 15 rendu est supprimé de la liste des serveurs de rendu utilisé pour l'application particulière demandée. Par contre si tous les serveurs de rendu sont déclarés invalides, la ressource d'orchestration exclue l'application particulière du droit à s'inscrire dans le serveur de l'invention. 20 La ressource d'orchestration comporte ensuite un moyen pour ajouter les serveurs de diffusion associés à l'application particulière pour les serveurs de rendu qui ont été validé. En cas d'échec de l'ajout d'un serveur de diffusion, le serveur de 25 diffusion en erreur est éliminé de la liste des serveurs de diffusion affectée à l'application particulière. En cas d'échec de tous les ajouts des serveurs de diffusion associés à un serveurs de rendu, on effectue la suppression du serveur de rendu associé à l'application particulière en cours d'inscription. Dans ce cas la 30 procédure de chargement de l'application particulière est rejetée par la ressource orchestration. 35 La ressource d'orchestration comporte ensuite une ressource de détermination du répertoire de travail pour l'application particulière à charger sur une machine cible associé au serveur de l'invention.

Une fois le répertoire de travail déterminé, la ressource d'orchestration comporte un moyen de chargement application particulière qui produit à la fin du chargement dans le répertoire de travail choisi un message indiquant un échec éventuel. Dans io ce cas le moyen de chargement produit une suppression du serveur de rendu en cause dans la liste des serveurs de rendu utilisé par le gestionnaire d'application particulière qui a été ciblés dans le répertoire drive choisi pour exécuter l'application particulière. Si tous les serveurs de rendu ont été supprimés à ts l'issue duquel le chargement, la ressource d'orchestration élimine l'application particulière et son chargement est interdit.

En cas de réussite du chargement de l'application particulière, le serveur passe en écoute des connexion aux 20 différents clients sur le réseau Internet ou le réseau FM de façon à placer le serveur d'application particulière en attente d'une requête d'exécution pour un client au moins.

Claims (1)

REVENDICATIONS

1 ù Procédé pour générer des images associées à un contexte 3D en temps réel, caractérisé en ce qu'il est prévu une première étape d'édition d'au moins une application de gestion, puis une seconde étape d'enregistrement de l'application de gestion, puis une troisième étape d'installation et d'enregistrement d'au moins un utilisateur doté d'un client pour une application enregistrée et une quatrième étape au cours de laquelle au moins un client émet et/ou reçoit au moins une io requête telle que le contexte 3D est modifié en fonction notamment des interactions de chaque utilisateur "client" à l'aide des requêtes et des règles d'animation pour une application déterminée et que cette modification est transférée sur la partie de représentation d'au moins un client. 15 2 ù Procédé selon la revendication 1, caractérisé en ce que il comporte une étape de détection du type de client pour en déduire le type de données et de codes à échanger entre au moins un utilisateur et au moins un éditeur de contenus. 3 ù Procédé selon la revendication 1, caractérisé en ce 20 que il comporte une étape de détection de la charge de serveurs de rendus et de diffusion retournant au moins une image associée à l'exécution d'une application déterminée en fonction d'une requête de représentation dudit contexte 3D à destination d'au moins un organe de représentation de contexte de sorte que 25 l'image et ou un script d'animation soit produit par un serveur disponible. 4 ù Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte une étape pour générer des objets complexes, composant un modèle 30 d'intelligence artificielle sous la forme d'une classe et qui est destiné à être encapsulé dans un objet graphique associé au contexte 3D particulier de l'application concernée. 37 û Dispositif téléinformatique permettant de réaliser des opérations sur une base de données multimédia, notamment dans le cadre de l'exécution de jeux vidéo comme des jeux vidéo 3D, et mettant en oeuvre le procédé selon l'une des revendications 5 précédentes, caractérisé en ce qu'il comporte : - au moins un client (1) comportant une ressource de représentations de contexte et un moyen pour émettre une requête ; - une liaison (3) de client (1) ; et io - un serveur (2) comportant une ressource pour détecter le type de client qui transmet au moins une requête et un serveur d'applications (6) pour transmettre la requête du client à un éditeur de contenus (7) de sorte qu'en réponse au moins un contexte produit sur la base d'une application particulière is exécutée sur ledit serveur d'applications (6) comme une image, une séquence d'images ou un objet comme un script, est retourné vers le client pour y produire une représentation sur un organe de représentation (10). 6 û Dispositif selon la revendication 5, caractérisé en ce 20 qu'il comporte un gestionnaire de charges (28) associé à un serveur d'applications (24) de sorte que soit déterminé un serveur de rendu (34) et un serveur de diffusion (36) pour retourner (38, 40) vers au moins un client (1) une image ou un script quelque soit l'état de charge des autres serveurs. 25 7 û Dispositif selon l'une des revendications 5 ou 6 caractérisé en ce qu'il comporte un automate (50), qui comporte : - une ressource 54 de test du traitement de requête - une ressource d'analyse contextuelle de requête ; - une ressource pour générer un contenu 58 de texte 30 contextuel. - une ressource pour générer un contenu 66 de texte contextuel et une collection de liens vers les images contextuelles 38 qui sont disponibles sur le serveur de diffusion (64') associé au client (1) qui a produit la requête initiale. 8 ù Dispositif selon l'une quelconque des revendications 5 à 7, caractérisé en ce que les données et/ou les codes ou scripts échangés entre le client et le serveur sont encapsulés dans un ou plusieurs objets de type xml , traités par des ressources d'analyse d'objets xml (parsers) pour en déduire, depuis les bases de données gérées sur le serveur, les données et les codes ou scripts nécessaires à la modification du contexte dont une io représentation est attendue. 9 ù Dispositif selon la revendication 8, caractérisé en ce qu'il comporte une ressource de réception de requêtes http sur l'automate (50) avec un moyen d'interrogation de bases de données maintenues sur le serveur pour récupérer les données de 15 caractères du terminal client. ù Dispositif selon l'une quelconque des revendications 6 à 9, caractérisé en ce que au moins l'une des entités client , meta et base est construite sur une machine virtuelle dotées de ressources de gestion d'objets d'animations associés 20 au contexte 3D d'une application particulière exécutée sur le serveur d'applications.