FR 2912523 A1 20080815 FR 0700995 A 20070209 10 La présente invention a pour objet un procédé permettant de simuler le fonctionnement d'un dispositif ayant une architecture et un processeur déterminés à l'aide d'un autre dispositif connecté à un réseau informatique, tel qu'Internet, cet autre dispositif comprenant une architecture et un processeur généralement distincts. Elle s'applique notamment mais non exclusivement à 15 un procédé qui permet l'émulation d'une console de jeux en utilisant notamment un navigateur Web d'un ordinateur ou d'un téléphone portable. On sait que l'augmentation de la puissance de traitement des données des processeurs a permis d'améliorer la qualité de l'émulation de dispositifs 20 matériels, tels que d'anciennes consoles de jeux, sur des ordinateurs ou des téléphones portables. Cette technologie permet ainsi de faire fonctionner sur des terminaux multimédias et interactifs récents des jeux vidéo spécifiques à des consoles de jeux à l'architecture obsolète. 25 Néanmoins, l'émulation de ces consoles et des jeux vidéo associés nécessite généralement : • le téléchargement, l'installation et la configuration préalables de l'émulateur spécifique à une console déterminée ; • le téléchargement manuelle desdits jeux vidéo et leur installation dans 30 l'émulateur approprié. 1 - 2 Or, ces opérations s'avèrent généralement longues et compliquées. En outre, le téléchargement sur un terminal individuel de ces jeux vidéo présente l'inconvénient supplémentaire de permettre à l'utilisateur de pouvoir récupérer sur un dispositif de stockage, tel qu'un disque dur, une image de jeux vidéo qui ne sont pas généralement libres de droit. L'invention a donc plus particulièrement pour but de surmonter ce problème en proposant un procédé permettant d'émuler le fonctionnement de dispositifs matériels, tels que des consoles de jeux vidéo, sur des dispositifs matériels présentant généralement une architecture distincte, au moyen d'un navigateur réseau et sans qu'il soit nécessaire pour l'utilisateur de procéder à des opérations d'installation et de réglage complexes. A cet effet, elle propose un procédé qui permet de simuler le fonctionnement des dispositifs ayant une architecture déterminée sur des dispositifs pouvant avoir une architecture distincte, caractérisé en ce qu'il fait intervenir : • un terminal informatique qui comprend au moins un moyen tel qu'un navigateur réseau permettant d'accéder à un réseau informatique Internet/Intranet et d'en visualiser les pages ; • au moins un serveur qui comporte notamment : o au moins un module client transférable vers le terminal informatique, ce module client comprenant au moins un noyau d'émulation qui permet d'émuler au moins une application déterminée ; o un moteur d'inférence ; o au moins une application déterminée ; et en ce qu'il comprend la réalisation des étapes suivantes : • l'émission par un client - utilisateur connecté à un réseau informatique, au moyen du terminal informatique, d'une requête à destination du serveur, cette requête ayant pour objet l'accès à l'application déterminée comprise sur ledit serveur ; - 3 • le transfert du serveur vers le client - utilisateur du module client correspondant et son intégration automatique dans le navigateur réseau ; • l'initialisation du module client ; • l'initialisation du noyau d'émulation compris dans le module client ; • l'exécution de l'application déterminée, les paquets la constituant étant transmis du serveur vers le client û utilisateur de manière unitaire. De cette manière, le découpage de l'image de l'application en paquets et la transmission unitaire de ceux û ci au client - utilisateur permet de réduire les traces de l'image de cette application sur un dispositif de stockage (tel qu'un disque dur) du client - utilisateur. Afin d'optimiser le contrôle de l'image de l'application, les paquets pourront être également cryptés. Avantageusement, le procédé selon l'invention permet à plusieurs clients -utilisateurs d'accéder et d'utiliser en réseau la même application grâce à la mise en oeuvre d'un module de connectivité réseau compris sur le serveur, ce module rendant possible une synchronisation multi û utilisateurs. Un mode d'exécution de l'invention sera décrit ci-après, à titre d'exemple non limitatif, avec référence aux dessins annexés dans lesquels : La figure 1 est une représentation schématique sous forme d'organigramme du procédé selon l'invention avec une mise en évidence des échanges entre le client - utilisateur et le serveur. La figure 2 est une représentation schématique de différents types d'organisation des données graphiques de l'application à émuler. - 4 La figure 3 est une représentation schématique sous forme d'organigramme de la structure du dispositif nécessaire à la mise en oeuvre du procédé selon l'invention. Dans cet exemple, ledit procédé comprend la réalisation des étapes suivantes : • l'émission par un client - utilisateur 1 connecté à un réseau informatique, au moyen d'un terminal 2 équipé d'un navigateur réseau, d'une requête à destination d'un serveur 3, cette requête ayant pour objet l'accès à une application déterminée (REF_LOG_A) comprise sur ledit serveur 3. Ainsi, à titre d'exemple, le client ù utilisateur 1 équipé d'un terminal informatique 2 peut accéder à une page Web à l'aide d'un navigateur Internet et sélectionner dans une liste de jeux vidéo celui qui l'intéresse, cette sélection se traduisant par l'émission automatique de la requête du type susdit au serveur 3 ; • le calcul et la génération par un moteur d'inférence compris dans le serveur 3 des paramètres nécessaires au lancement de l'application détermmee (REF_LOGA), ces paramètres pouvant être notamment mais non exclusivement : o l'adresse où figure sur le serveur 3 un module client 4 20 comprenant notamment un noyau d'émulation qui permet d'émuler ladite application (REF_LOG_A) ; et/ou o des identifiants des composants logiciel (par exemple, un jeu vidéo) et matériel (par exemple, une console de jeux vidéo) à simuler, ces identifiants permettant de repérer ces composants 25 dans un moyen de stockage structuré et indexable, tel qu'une base de donnée, compris dans le serveur 3 ; et/ou o des informations concernant le client - utilisateur 1 à savoir par exemple, son nom et son mot de passe qui peut être crypté ; et/ou 30 o un état pré ù sauvegardé de l'état de démarrage de l'application à simuler (REF_LOG_A) ; et/ou o des données relatives à l'affichage, à des entrées sonores, à des entrées utilisateur (ces dernières pouvant être relatives à des entrées de type clavier, souris, manette de jeu, etc.) ; • la transmission par le serveur 3 au client - utilisateur 1 desdits paramètres ; • le transfert du serveur 3 vers le client - utilisateur 1 du module client 4 et son intégration automatique dans le navigateur réseau, le module client 4 étant réalisé dans une technologie compatible avec l'exigence d'intégration dans un tel navigateur (à titre d'exemple, il peut s'agir d'une applet Java ou d'un module Flash()) ; • l'initialisation du module client 4 et l'émission d'une requête par le client - utilisateur 1 à destination du serveur 3 ayant pour objet d'obtenir des informations sur l'image 7 présente sur le serveur 3 de ladite application déterminée (REF_LOG_A). Les informations relatives à l'image 7 de l'application déterminée (REF_LOGA) concernent notamment la taille de chaque paquet constituant l'application (REF LOG A) ainsi que le nombre de ces paquets ; • la lecture par le moteur d"inférence du serveur 3 des informations concernant l'image 7 de l'application déterminée (REF_LOG_A) présente sur le serveur 3 ; • la transmission par le serveur 3 au client utilisateur 1 d'une réponse comprenant les informations concernant l'image 7 de l'application déterminée (REFLOG_A) ; • l'initialisation automatique ou manuelle du noyau d'émulation compris dans le module client 4, cette initialisation pouvant être notamment, mais non exclusivement, réalisée en sélectionnant un simple lien HTML sur une page WEB ; • l'exécution de l'application déterminée (REF_LOG_A), les paquets la constituant étant transmis "à la volée" du serveur 3 vers le client utilisateur 1 de manière unitaire, ceci permettant notamment : 2912523 -6 o de procéder à un transfert contrôlé en fonction de la demande de l'application émulée (REF_LOG_A), ce qui limite le temps d'attente initial et optimise l'utilisation de la bande passante du terminal informatique 2 du client û utilisateur 1 ; 5 o de réduire les traces de l'image 7 de cette application (REF_LOG_A) sur un dispositif de stockage du terminal informatique 2 du client û utilisateur 1. De cette manière et de façon avantageuse, il est possible pour un client û 10 utilisateur 1 d'initialiser une application émulée (REF_LOG_A) en seul clic de souris en faisant abstraction des problématiques de téléchargement, d'installation et de configuration du noyau d'émulation. Les données graphiques de l'application à émuler (REF_LOG_A), qui ont 15 souvent des formats très différents, sont sauvegardées sur le serveur 3 dans un premier format spécifique adapté au matériel d'origine à simuler. Afin de les rendre plus accessibles et d'optimiser ainsi les performances du GPU (Graphics Processing Unit û puce graphique) émulé, ces données graphiques peuvent avantageusement être transformées par décodage en un deuxième 20 format qui est plus approprié pour procéder à une émulation du type susdit, ces données étant ensuite enregistrées dans une mémoire tampon afin d'éviter de devoir procéder de nouveau à leur décodage. Ainsi, tel que cela est représenté sur la figure 2, les données graphiques d'un 25 même type de données (A, B, C, ...) sont initialement organisées en colonne dans des cellules de mémoire 5 (figure 2.1), ce qui correspond à une organisation planaire des données et convient au matériel d'origine à simuler. Si elles sont nécessaires, ces données graphiques, après transformation par décodage, sont réorganisées linéairement (un même type de données est 30 disposé en ligne) et enregistrées dans une mémoire cache (figure 2.2) afin d'optimiser le processus d'émulation. En fonction du GPU à simuler, ladite mémoire cache peut présenter les spécificités suivantes : • la mémoire cache peut correspondre à une mémoire tampon présentant une taille importante de manière à pouvoir comprendre toutes les primitives affichables, cette solution étant privilégiée lorsque le nombre de primitives graphiques est limité et lorsque la capacité mémoire du terminal informatique du client ù utilisateur 1 est suffisamment grande ; ou • la mémoire cache peut être de type LRU (Least Recently Used) ce qui permet de ne mettre en cache que les données graphiques les plus utilisées tout en permettant audit cache de ne pas dépasser une taille limite, cette solution étant adaptée lorsque le terminal informatique 2 du client ù utilisateur 1 comprend peu de mémoire vive et nécessite plus de puissance de traitement que dans le cas précédent. De manière avantageuse, le procédé selon l'invention peut être initialisé en sélectionnant un simple lien HTML sur une page WEB. Tel que cela est représenté sur la figure 3, le dispositif nécessaire à la mise en oeuvre du procédé selon l'invention comprend : • au moins un terminal informatique interactif et multimédia 2 (ordinateur, PDA, téléphone, etc.) doté de périphériques : o de sorties multimédia tels qu'un écran ; o de saisie et/ou d'interaction homme / machine tels qu'un clavier, une souris, un joystick, un écran tactile ; o de moyens de transmission avec au moins un site Internet / Intranet tels que notamment un navigateur et une connexion réseau s'appuyant sur un protocole de communication spécifique indépendant des protocoles réseaux qu'il exploite, de manière préférentielle, si la connexion jusqu'au client ù utilisateur 1 le permet, le protocole réseau sous - jacent UDP est privilégié à défaut, le protocole TCP est utilisé ; • au moins un serveur 3 du type Internet accessible au moins partiellement par l'intermédiaire dudit site Internet/Intranet, ce serveur 5 3 comportant : o au moins un module client 4 transférable vers le terminal informatique 2, ce module client 4 comprend un noyau d'émulation permettant d'émuler au moins une application déterminée (REF_LOG_A) et également un moyen de sauvegarde 10 et de restauration d'un état complet du système émulé à tout instant par une action du client û utilisateur 1 ; o un moteur d'inférence procédant notamment au calcul et à la génération des paramètres nécessaires au lancement d'une application déterminée (REF_LOG_A), à la lecture des 15 informations concernant l'image 7 de l'application déterminée (REF_LOG_A) présente sur le serveur 3, à la gestion de la transmission au module client 4 intégré dans le terminal informatique 2 du client û utilisateur 1 des paquets constituant l'application déterminée (REF_LOG_A) ; 20 o au moins une image disque 7 d'une application déterminée (REF LOG A). Selon une variante d'exécution de l'invention, le dispositif nécessaire à la mise en oeuvre du procédé selon l'invention peut également comporter : 25 • au moins un moyen de mémorisation persistant des données compris sur le serveur 3, ces données pouvant être notamment des informations relatives à l'état de l'application émulée (REF LOG A) telles que des captures écran, un état de la mémoire vive, un état de la mémoire vidéo, un état de la mémoire EEPROM, les meilleurs scores dans le cas où 30 cette application (REF_LOG_A) est un jeu vidéo ; et/ou • un module de connectivité réseau 6 compris sur le serveur 3 permettant à plusieurs clients - utilisateurs 1 d'accéder et d'utiliser en réseau la même application (REF_LOG_A), ce module 6 qui rend possible une synchronisation multi û utilisateurs présente un intérêt certain dans le cas où l'application émulée (REF_LOG_A) est constituée par un ensemble console de jeux / jeu vidéo. Avantageusement, selon une variante d'exécution de l'invention, cette synchronisation multi û utilisateurs de la même application (REF_LOG_A) peut être réalisée grâce à la technologie poste - à - poste (peer û to û peer), les terminaux informatiques 2 des différents clients û utilisateurs 1 communiquant directement les uns avec les autres sans recourir à un tel module de connectivité réseau 6. Revendications 1. Procédé qui permet de simuler le fonctionnement des dispositifs ayant une architecture déterminée sur des dispositifs pouvant avoir une 5 architecture distincte, caractérisé en ce qu'il fait intervenir : • un terminal informatique (2) qui comprend au moins un moyen tel qu'un navigateur réseau permettant d'accéder à un réseau informatique Internet/Intranet et d'en visualiser les pages ; 10 • au moins un serveur (3) qui comporte notamment : o au moins un module client (4) transférable vers le terminal informatique (2), ce module client (4) comprenant au moins un noyau d'émulation qui permet d'émuler au moins une application déterminée (REF_LOG_A) ; 15 o un moteur d'inférence ; o au moins une application déterminée (REF_LOG_A) ; et en ce qu'il comprend la réalisation des étapes suivantes : • l'émission par un client --utilisateur (1) connecté à un réseau informatique, au moyen du terminal informatique (2), d'une requête à 20 destination du serveur (3), cette requête ayant pour objet l'accès à l'application déterminée (REF_LOG_A) comprise sur ledit serveur (3) ; • le transfert du serveur (3) vers le client - utilisateur (1) du module client (4) correspondant et son intégration automatique dans le navigateur réseau ; 25 • l'initialisation du module client (4) ; • l'initialisation du noyau d'émulation compris dans le module client (4) ; • l'exécution de l'application déterminée (REF_LOG_A), les paquets la constituant étant transmis du serveur (3) vers le client ù utilisateur (1) de manière unitaire. 30-11- 2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend la réalisation des étapes suivantes : • l'émission par le client .-utilisateur (1) connecté à un réseau informatique, au moyen du terminal informatique (2), d'une requête à 5 destination du serveur (3), cette requête ayant pour objet l'accès à une application déterminée (REF'_LOG_A) comprise sur le serveur (3) ; • le calcul et la génération par le moteur d'inférence compris dans le serveur (3) des paramètres nécessaires au lancement de l'application déterminée (REF_LOG_A) ; 10 • la transmission par le serveur (3) au client - utilisateur (1) desdits paramètres dont l'adresse où figure sur le serveur (3) le module client (4) comprenant notamment un noyau d'émulation qui permet d'émuler ladite application (REF_LOG_A) ; • le transfert du serveur (3) vers le client - utilisateur (1) du module client 15 (4) et son intégration automatique dans le navigateur réseau ; • l'initialisation du module client (4) et l'émission d'une requête par le client - utilisateur (1) à destination du serveur (3) ayant pour objet d'obtenir des informations sur l'image (7) présente sur le serveur (3) de ladite application déterminée (REF_LOG_A) ; 20 • la lecture des informations concernant l'image (7) de l'application déterminée (REF_LOG_A) présente sur le serveur (3) ; • la transmission par le serveur (3) au client - utilisateur (1) d'une réponse comprenant les informations concernant l'image (7) de l'application déterminée (REF_LOG_A) ; 25 • l'initialisation du noyau d'émulation automatique ou manuelle compris dans le module client (4) ; • l'exécution de l'application déterminée (REF_LOG_A), les paquets la constituant étant transmis du serveur (3) vers le client -utilisateur (1) de manière unitaire. 30 2912523 - 12 - 3. Procédé selon la revendication 2, caractérisé en ce que les paramètres nécessaires au lancement de l'application déterminée (REF_LOG A) sont : • des identifiants des composants logiciel et matériel à simuler, ces 5 identifiants permettant de repérer ces composants dans un moyen de stockage structuré et indexable compris dans le serveur (3) ; et/ou • des informations concernant le client - utilisateur (1) ; et/ou • un état pré ù sauvegardé de l'état de démarrage de l'application à simuler (REF_LOG_A) ; et/ou 10 • des données relatives à l'affichage, à des entrées sonores, à des entrées utilisateur. 4. Procédé selon l'une des revendications 2 à 3, caractérisé en ce que les informations relatives à l'image (7) de l'application 15 déterminée (REFùLOG_A) concernent notamment la taille de chaque paquet constituant l'application (REF_LOG__A) ainsi que le nombre de ces paquets. 5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que l'initialisation du noyau d'émulation compris dans le 20 module client (4) est réalisée en sélectionnant un simple lien HTML sur une page WEB. 6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce que les paquets constituant l'application déterminée 25 (REFLOGA) sont transmis "à la volée" du serveur (3) vers le client - utilisateur (1). 7. Procédé selon l'une des revendications précédentes, caractérisé en ce que les données graphiques de l'application à émuler 30 (REF_LOGA) sont sauvegardées sur le serveur (3) dans un premier format spécifique adapté au matériel d'origine à simuler, afin de les rendre plus- 13 - accessibles et d'optimiser ainsi les performances du GPU (Graphics Processing Unit) émulé, ces données graphiques sont transformées par décodage en un deuxième format qui est plus approprié pour procéder à une émulation du type susdit, ces données étant ensuite enregistrées dans une mémoire tampon afin d'éviter de devoir procéder de nouveau à leur décodage. 8. Procédé selon la revendication 7, caractérisé en ce que les données graphique d'un même type de données (A, B, C, ...) sont initialement organisées en colonne dans des cellules de mémoire (5), ce qui correspond à une organisation planaire des données et convient au matériel d'origine à simuler, si elles sont nécessaires, ces données graphiques, après transformation par décodage, sont réorganisées linéairement et enregistrées dans une mémoire cache afin d'optimiser le processus d'émulation. 9. Procédé selon la revendication 8, caractérisé en ce qu'en fonction clu GPU à simuler, ladite mémoire cache présente les spécificités suivantes : • la mémoire cache correspond à une mémoire tampon présentant une taille importante de manière à pouvoir comprendre toutes les primitives affichables ; ou • la mémoire cache est de type LRU (Least Recently Used) ce qui permet de ne mettre en cache que les données graphiques les plus utilisées tout 25 en permettant audit cache de ne pas dépasser une taille limite. 10. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il est initialisé en sélectionnant un simple lien HTML sur une page Web. 30- 14 - 11. Dispositif pour la mise en oeuvre du procédé selon la revendication 1, caractérisé en ce qu'il comprend : • au moins un terminal informatique interactif et multimédia (2) doté de 5 périphériques : o de sorties multimédia tels qu'un écran ; o de saisie et/ou d'interaction homme / machine tels qu'un clavier, une souris, un joystick, un écran tactile ; o de moyens de transmission avec au moins un site Internet / 10 Intranet tels que notamment un navigateur et une connexion réseau s'appuyant sur un protocole de communication spécifique indépendant des protocoles réseaux qu'il exploite ; • au moins un serveur (3) du type Internet accessible au moins partiellement par l'intermédiaire dudit site Internet/Intranet, ce serveur 15 (3) comportant : o au moins un module client (4) transférable vers le terminal informatique (2), ce module client (4) comprend un noyau d'émulation permettant d'émuler au moins une application déterminée (REF_LOG_A) et également un moyen de sauvegarde 20 et de restauration d'un état complet du système émulé à tout instant par une action du client ù utilisateur (1) ; o un moteur d'inférence procédant notamment au calcul et à la génération des paramètres nécessaires au lancement d'une application déterminée (REF_LOG_A), à la lecture des 25 informations concernant l'image (7) de l'application déterminée (REF LOG A) présente sur le serveur (3), à la gestion de la transmission au module client (4) intégré dans le terminal informatique (2) du client ù utilisateur (1) des paquets constituant l'application déterminée (REF LOG A) ; 30 o au moins une image disque (7) d'une application déterminée (REF LOG A). 2912523 -15- 12. Dispositif selon la revendication 11, caractérisé en ce qu'il comporte : • au moins un moyen de mémorisation persistant des données compris sur le serveur (3), ces données pouvant être notamment des informations relatives à l'état de l'application émulée (REF_LOG_A) telles que des captures écran, un état de la mémoire vive, un état de la mémoire vidéo, un état de la mémoire EEPROM, les meilleurs scores dans le cas où cette application (REF_LOG_A) est un jeu vidéo ; et/ou • un module de connectivité réseau (6) compris sur le serveur (3) permettant à plusieurs clients - utilisateurs (1) d'accéder et d'utiliser en réseau la même application (REF_LOGA), ce module (6) rendant possible une synchronisation multi ù utilisateurs. 13. Dispositif selon la revendication 12, caractérisé en ce que la synchronisation multi ù utilisateurs de la même application (REF_LOG_A) est réalisée grâce à la technologie poste - à - poste (peer ù to ù peer), les terminaux informatiques (2) des différents clients ù utilisateurs (1) communiquant directement les uns avec les autres sans recourir à un module de connectivité réseau (6).