WO2008113917A2 - Procede permettant de simuler le fonctionnement d'un dispositif ayant une architecture et un processeur determines a l'aide d'un autre dispositif connecte a un reseau informatique - Google Patents

Procede permettant de simuler le fonctionnement d'un dispositif ayant une architecture et un processeur determines a l'aide d'un autre dispositif connecte a un reseau informatique Download PDF

Info

Publication number
WO2008113917A2
WO2008113917A2 PCT/FR2008/000171 FR2008000171W WO2008113917A2 WO 2008113917 A2 WO2008113917 A2 WO 2008113917A2 FR 2008000171 W FR2008000171 W FR 2008000171W WO 2008113917 A2 WO2008113917 A2 WO 2008113917A2
Authority
WO
WIPO (PCT)
Prior art keywords
server
application
data
client
user
Prior art date
Application number
PCT/FR2008/000171
Other languages
English (en)
Other versions
WO2008113917A3 (fr
Inventor
Romain Tisserand
David Raingeard
Original Assignee
Dotemu
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Dotemu filed Critical Dotemu
Priority to EP08761871A priority Critical patent/EP2117661A2/fr
Priority to US12/526,423 priority patent/US20100256971A1/en
Publication of WO2008113917A2 publication Critical patent/WO2008113917A2/fr
Publication of WO2008113917A3 publication Critical patent/WO2008113917A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45529—Embedded in an application, e.g. JavaScript in a Web browser

Definitions

  • the present invention relates to a method for simulating the operation of a device having a determined architecture and a processor using another device connected to a computer network, such as the Internet, this other device comprising an architecture and a processor generally distinct. It applies in particular but not exclusively to a method that allows the emulation of a game console using a particular web browser from a computer or a mobile phone.
  • At least one file necessary for the operation of said emulator such as: the BIOS (s) of the machine to be emulated; and / or o the media file containing said application, which file may take the form of an image of a hard disk, a CD - ROM, a floppy disk or a cassette.
  • the BIOS (s) of the machine to be emulated such as: the BIOS (s) of the machine to be emulated; and / or o the media file containing said application, which file may take the form of an image of a hard disk, a CD - ROM, a floppy disk or a cassette.
  • the downloading on an individual terminal of these video games has the additional disadvantage of allowing the user to be able to recover on a storage device, such as a hard disk, an image of video games that are not generally free of rights.
  • the invention therefore more particularly aims to solve these problems by proposing a method for emulating the operation of hardware devices, such as video game consoles, on hardware devices generally having a distinct architecture, by means of a network browser and without the need for the user to perform any installation and tuning operation.
  • a computer terminal that includes at least one means such as a network browser to access an Internet / Intranet computer network and view the pages;
  • At least one server that notably comprises: . .
  • each client module transferable to the computer terminal, this client module comprising at least one emulation kernel which makes it possible to emulate at least one determined application; o an inference engine; at least one configurable "content file” having a specific format and which comprises all the configuration information as well as the data and resources necessary for the operation of the application determined to emulate; in this way, each "content file” includes at least one specific application; and in that it comprises carrying out the following steps:
  • the application to be emulated is executed automatically without the user needing to perform complex installation and adjustment operations.
  • the separate transmission of the emulation kernel, which is included in the client module, and the data and resources necessary for the operation of the emulated targeted application make it possible in particular to better control the use that the client user makes of this application.
  • the "content file" can be set to limit the use of said application and in particular to avoid misuse of the latter which is generally protected by the right to author.
  • only part of the information, data and resources included in the "content file” can be transferred from the server to the client-user in order to obtain a "file".
  • content file "minimal when initializing the execution of the emulated application.
  • the other data and resources necessary for the operation of said application are read dynamically from the server during the emulation of this application.
  • these other data and resources are transmitted in the form of packets to the computer terminal of the user client, and processed sequentially upon receipt, which allows in particular:
  • the initialization of the execution of the application can be performed without the need for all said packets to have been transferred from the server to the computer terminal of the user client. , this variant being thus particularly suitable when it is necessary to carry out a dynamic reading of data included on: a mass media such as a CD-ROM or a hard disk; or o on dead memories that can be of the EEPROM type;
  • the packets including the data and resources that allow the execution of this application can be volatile and be processed by the emulation kernel sequentially without requiring storage on a mass memory such as a hard disk, which allows in addition to reducing the traces of the image of said application on the computer terminal of the user client.
  • the constituent elements of said emulation core will not be stored permanently on a mass memory such as a hard disk .
  • each resource, data, configuration information included in the "content file” can be cut into blocks, and each of these blocks can be encrypted using an algorithm and a different key.
  • the inference engine may generate a specific "content file” depending on the nature of the initial request from the client-user.
  • the method according to the invention allows several clients - users to access and use the same application in a network through the implementation of a network connectivity module included on the server, this module making possible a synchronization multi - users.
  • FIG. 1 is a diagrammatic representation in the form of a flowchart of the method according to the invention with a highlighting of the exchanges between the client-user and the server.
  • Figure 2 is a schematic representation of different types of organization of the graphical data of the application to emulate.
  • FIG. 3 is a diagrammatic representation in the form of a flowchart of the structure of the device necessary for carrying out the method according to the invention.
  • said method comprises carrying out the following steps:
  • the client-user 1 equipped with a computer terminal 2 can access a web page using an Internet browser and select from a list of video games that which interests him, this selection resulting in the automatic transmission of the request of the aforementioned type to the server 3; the calculation and generation by an inference engine included in the server 3 of the parameters and elements necessary for launching the determined application (REF LOG A), these parameters being in particular but not exclusively: o the address where the server 3 a client module 4 including an emulation kernel that emulates said application (REF_LOG_A); and / or o identifiers of the software components (for example, a video game) and hardware (for example, a video game console) to be simulated, these identifiers making it possible to locate these components in a structured and indexable storage means, such as a database, included in the server 3; and / or o information concerning the client - user 1, for example his name and password which can be encrypted; and / or o data relating to the display, to sound inputs,
  • this "content file” may include:
  • disk images such as cassettes, hard disks, CD - ROMs, and / or _ _
  • media files that may take the form of read-only memory images such as EEPROM;
  • the client-user 1 can initialize the implementation of the method according to the invention by selecting a simple HTML link on a web page, this link can correspond to the choice of the application to be emulated (REF LOG A).
  • the "content file” can be divided into packets.
  • the packets necessary for the execution of this application can be transmitted "on the fly” from the server 3 to the client - user 1 unitarily , this in particular making it possible to read dynamically from the server 3 the corresponding data and resources which are necessary for the operation of said application (REF LOG A).
  • the inference engine can generate, during the second step of said method, a "content file" specific to the nature of the initial request of the client - user 1.
  • a “content file” specific to the nature of the initial request of the client - user 1.
  • the inference engine will generate a "content file” including in particular all the configuration information and the data and resources necessary for the operation of this application (REF LOG A).
  • the "content file” can be generated by a natural person and then loaded onto said server 3.
  • the server 3 comprises a "content file” for each application to be emulated ( REF_LOG_A).
  • this "content file” can be set to better control the use that the client - user 1 can make the application to emulate (REF LOG A).
  • REF LOG A the application to emulate
  • each resource, data, configuration information included in the "contents file” can be divided into blocks, and each of these blocks can be encrypted using an algorithm and a different key.
  • the graphic data of the application to be emulated (REF LOG A), which often have very different formats, are saved on the server 3 in a first specific format adapted to the original equipment to be simulated, these graphic data being included in a "content file".
  • these graphic data can advantageously be converted by decoding into a second format which is more suitable for carrying out an emulation of the aforementioned type. , these data are then stored in a buffer memory in order to avoid having to re-decode them.
  • the graphical data of the same type of data (A, B, C,%) are initially organized in columns in memory cells 5 (FIG. 2.1). which corresponds to a planar data organization and is suitable for the original hardware to simulate.
  • said cache memory may have the following specificities: • the cache memory may correspond to a buffer having a large size so as to be able to understand all the .
  • the cache memory may be of the LRU (Least Recently Used) type, which makes it possible to cache only the most used graphic data while allowing said cache not to exceed a size limit, this solution being adapted when the terminal computer 2 of the client - user 1 has little RAM and requires more processing power than in the previous case.
  • LRU Least Recently Used
  • the device necessary for carrying out the method according to the invention comprises:
  • At least one interactive and multimedia computer terminal 2 (computer, PDA, telephone, etc.) equipped with peripherals: multimedia outputs such as a screen; o input and / or human / machine interaction such as a keyboard, a mouse, a joystick, a touch screen; o transmission means with at least one Internet / Intranet site such as in particular a browser and a network connection based on a specific communication protocol independent of the network protocols that it exploits, preferably, if the connection up to client - user 1 allows it, the underlying network protocol UDP is preferred if not, the TCP protocol is used;
  • At least one server 3 of the Internet type accessible at least partially via said Internet / Intranet site comprising: at least one client module 4 transferable to the computer terminal 2, this client module 4 comprises at least one Emulation kernel for emulating at least one application determined (REF LOG A) and also means for saving and restoring a complete state of the system emulated at any time by an action of the client - user 1; an inference engine (not shown) notably comprising: calculating and generating the parameters and elements necessary for launching a given application (REF_LOG_A);
  • the device necessary for implementing the method according to the invention may also comprise:
  • this data can notably be information relating to the state of the emulated application (REF LOG A) such as screenshots, a state of the RAM memory , a state of the video memory, a state of the EEPROM memory, the best scores in the case where this application (REF LOG A) is a video game; and or
  • a network connectivity module 6 included on the server 3 allowing several clients - users 1 to access and use the same application in a network (REF LOG A), this module 6 which makes possible a multi - user synchronization is of particular interest in the case where the emulated application (REF LOG A) is constituted by a game console / video game set.
  • this multi-user synchronization of the same application can be achieved through peer-to-peer (peer-to-peer) technology, computer terminals 2 of the different clients - users 1 communicating directly with each other without resorting to such a network connectivity module 6.

Abstract

La présente invention a pour objet 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 comprend la réalisation des étapes suivantes : • l'émission par un client utilisateur (1) connecté à un réseau informatique d'une requête à destination du serveur (3), cette requête ayant pour objet l'accès à une 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 correspondant et son intégration automatique dans le navigateur réseau; l'initialisation du module client et l'émission d'une requête par le module client afin d'obtenir le transfert du serveur (3) vers le client - utilisateur (1), d'au moins une partie desdites informations, données et ressources comprises sur le 'fichier contenu' correspondant; l'initialisation d'un noyau d'émulation compris dans le module client; l'intégration desdites données ou ressources préalablement transférées dans le noyau d'émulation; l'exécution automatique de l'application déterminée (REF_LOG_A).

Description

PROCEDE PERMETTANT DE SIMULER LE FONCTIONNEMENT D'UN DISPOSITIF AYANT UNE ARCHITECTURE ET UN PROCESSEUR DETERMINES A L'AIDE D'UN AUTRE DISPOSITIF CONNECTE A UN RESEAU INFORMATIQUE
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 à 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 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.
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 l'émulateur approprié. Plus précisément, l'exécution de l'application émulée nécessite notamment de procéder aux téléchargements :
• d'un émulateur dédié (un module client) ;
• d'au moins un fichier nécessaire au fonctionnement dudit émulateur, tel que : o le ou les BIOS de la machine à émuler ; et/ou o le fichier média contenant ladite application, ce fichier pouvant prendre la forme d'une image d'un disque dur, d'un CD - ROM, d'une disquette ou d'une cassette. Or, ces opérations sont fastidieuses et nécessitent des compétences très pointues.
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 résoudre ces problèmes 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 à aucune opération d'installation et de réglage.
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 un "fichier contenu" paramétrable, ayant un format spécifique et qui comprend l'ensemble des informations de configuration ainsi que les données et ressources nécessaires au fonctionnement de l'application déterminée à émuler ; de cette façon, chaque "fichier contenu" comprend 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 à une application déterminée comprise sur ledit serveur ;
• 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 et l'émission d'une requête par le module client afin d'obtenir le transfert du serveur vers le client - utilisateur, d'au moins une partie desdites informations, données et ressources comprises sur le "fichier contenu" correspondant ;
• le transfert du serveur vers le client - utilisateur desdites informations, données et ressources comprises dans le "fichier contenu" ;
• l'initialisation d'un noyau d'émulation compris dans le module client, cette initialisation et la sélection du noyau d'émulation s'effectuant sur la base desdites informations ou données comprises dans le "fichier contenu" qui ont été transférées à l'étape précédente ; • l'intégration desdites données ou ressources préalablement transférées dans le noyau d'émulation, cette intégration s'effectuant sur la base des informations de configuration transmises ;
• l'exécution automatique de l'application déterminée.
De cette manière, l'application à émuler est exécutée automatiquement sans que l'utilisateur ait besoin de procéder à des opérations d'installation et de réglage complexes. Par ailleurs, la transmission séparée du noyau d'émulation, qui est compris dans le module client, et des données et ressources nécessaires au fonctionnement de l'application ciblée émulée permettent notamment de mieux contrôler l'utilisation que le client utilisateur fait de cette application. En effet, le "fichier contenu" peut être paramétré de manière à apporter des restrictions à l'utilisation de ladite application et d'éviter notamment une utilisation abusive de cette dernière qui fait généralement l'objet d'une protection par le droit d'auteur.
Avantageusement, selon une variante d'exécution de l'invention, dans un premier temps, seule une partie des informations, données et ressources comprises sur le "fichier contenu" peut être transférée du serveur vers le client - utilisateur afin d'obtenir un "fichier contenu" minimal lors de l'initialisation de l'exécution de l'application émulée. Par la suite, les autres données et ressources nécessaires au fonctionnement de ladite application sont lues dynamiquement à partir du serveur lors de l'émulation de cette application. Ainsi, ces autres données et ressources sont transmises sous forme de paquets vers le terminal informatique du client utilisateur, et traitées séquentiellement dès leur réception, ce qui permet notamment :
• d'adapter la transmission desdits paquets en fonction de l'état d'exécution de l'application. A titre d'exemple, si l'application est un jeu vidéo, la transmission des paquets s'effectuera en fonction du déroulement du jeu et donc des actions du joueur. De cette manière, tous les paquets de données constituant l'application à émuler ne devront pas être transmis, ce qui limite le volume des données échangées entre le serveur et le terminal informatique du client utilisateur ;
• de supprimer les temps d'attente pouvant résulter de téléchargements de fichiers particulièrement volumineux. En effet, selon cette variante d'exécution de l'invention, l'initialisation de l'exécution de l'application peut s'effectuer sans qu'il soit nécessaire que tous lesdits paquets aient été transférés du serveur au terminal informatique du client utilisateur, cette variante étant ainsi particulièrement adaptée lorsque il convient de procéder à une lecture dynamique de données comprises sur : o un média de masse tel qu'un CD - ROM ou un disque dur ; ou o sur des mémoires mortes pouvant être du type EEPROM ;
• de réduire voire de supprimer les contraintes de stockage de l'application à émuler sur le terminal informatique du client utilisateur. En effet, les paquets comprenant les données et ressources qui permettent l'exécution de cette application peuvent être volatiles et être traités par le noyau d'émulation séquentiellement sans nécessiter un stockage sur une mémoire de masse tel qu'un disque dur, ce qui permet en outre de réduire les traces de l'image de ladite application sur le terminal informatique du client utilisateur.
De manière préférentielle, afin de réduire les traces de l'image de ladite application sur le terminal informatique du client utilisateur, les éléments constitutifs dudit noyau d'émulation ne seront pas stockés de manière permanente sur une mémoire de masse telle qu'un disque dur.
De manière avantageuse, selon une autre variante d'exécution de l'invention, afin d'optimiser le contrôle de l'image de l'application à émuler, chaque ressource, donnée, information de configuration comprise dans le "fichier contenu" peut être découpée en blocs, et chacun de ces blocs peut être crypté en utilisant un algorithme et une clé différente. Selon une variante d'exécution de l'invention, le moteur d'inférence peut générer un "fichier contenu" spécifique en fonction de la nature de la requête initiale du client - utilisateur.
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 œuvre 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.
La figure 3 est une représentation schématique sous forme d'organigramme de la structure du dispositif nécessaire à la mise en œuvre 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 informatique 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 et éléments nécessaires au lancement de l'application déterminée (REF LOG A), ces paramètres pouvant être notamment mais non exclusivement : o l'adresse où figure sur le serveur 3 un module client 4 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 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 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.) ; lesdits éléments pouvant quant à eux être notamment constitués par un "fichier contenu" ayant un format spécifique qui comprend l'ensemble des informations de configuration ainsi que les données et ressources nécessaires à l'initialisation et au fonctionnement de l'application déterminée (REF LOG A) à émuler dans le navigateur Internet, ce "fichier contenu" peut comprendre :
" des fichiers médias pouvant prendre la forme "d'images disques" tels que des cassettes, des disques durs, des CD - ROM ; et/ou _ _
" des fichiers médias pouvant prendre la forme d'images de mémoire morte telle que de l'EEPROM ;
" éventuellement au moins un script pouvant être interprété par l'application client embarquée dans le navigateur Internet ;
" un état pré - sauvegardé de l'état de démarrage de l'application à simuler (REF_LOG_A) ;
• 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 ce dernier 4 afin d'obtenir le transfert du serveur 3 vers le client — utilisateur 1 d'une partie desdites informations, données et ressources comprises sur le "fichier contenu" correspondant. Ces informations qui permettent l'exécution automatique de l'application 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 ;
• la lecture par le moteur d'inférence du serveur 3 desdites informations, données et ressources comprises dans le "fichier contenu" et qui sont relatives à l'image 7 de l'application déterminée à émuler
(REF LOG A) présente sur le serveur 3 ;
• la transmission par le serveur 3 au client - utilisateur 1 d'une réponse comprenant lesdites informations, données et ressources comprises dans le "fichier contenu" ; • l'initialisation automatique du noyau d'émulation compris dans le module client 4, cette initialisation ainsi que la sélection du noyau d'émulation s'effectuant sur la base desdites informations ou données comprises dans le "fichier contenu" qui ont été transférées préalablement ;
• l'intégration desdites données ou ressources préalablement transférées dans le noyau d'émulation, cette intégration s'effectuant sur la base des informations de configuration transmises ;
• l'exécution de l'application déterminée (REF LOG A).
De cette manière et de façon avantageuse, il est possible pour un client - utilisateur 1 d'initialiser une application émulée (REF LOG A) en un seul clic de souris en faisant abstraction des problématiques de téléchargement, d'installation et de configuration du noyau d'émulation. En effet, la mise en oeuvre des étapes du procédé selon l'invention qui suivent l'étape initiale peut s'effectuer sans que le client - utilisateur 1 ait à réaliser une quelconque action de configuration.
Ainsi, le client - utilisateur 1 peut initialiser la mise en œuvre du procédé selon l'invention en sélectionnant un simple lien HTML sur une page WEB, ce lien pouvant correspondre au choix de l'application à émuler (REF LOG A).
Avantageusement, le "fichier contenu" peut être découpé en paquets. De cette façon, après l'initialisation de l'application à émuler (REF LOG A), les paquets nécessaires à l'exécution de cette application pourront être transmis "à la volée" du serveur 3 vers le client - utilisateur 1 de manière unitaire, ceci permettant notamment de lire dynamiquement à partir du serveur 3 les données et ressources correspondantes qui sont nécessaires au fonctionnement de ladite application (REF LOG A).
Par ailleurs, le moteur d'inférence peut générer, lors de la deuxième étape dudit procédé, un "fichier contenu" spécifique en fonction de la nature de la requête initiale du client - utilisateur 1. Ainsi, en fonction du choix par le client - utilisateur 1 de l'application à émuler (REF LOG A), le moteur d'inférence va générer un "fichier contenu" propre comprenant notamment l'ensemble des informations de configuration ainsi que les données et ressources nécessaires au fonctionnement de cette application (REF LOG A).
Selon une variante d'exécution de l'invention, le "fichier contenu" peut être généré par une personne physique puis être chargé sur ledit serveur 3. De cette façon, le serveur 3 comprend un "fichier contenu" pour chaque application à émuler (REF_LOG_A).
De manière avantageuse, ce "fichier contenu" peut être paramétré afin de mieux contrôler l'utilisation que le client - utilisateur 1 peut faire de l'application à émuler (REF LOG A). Ainsi, lors de la génération d'un "fichier contenu", il est possible de procéder notamment aux paramétrages : • de la date d'expiration du "fichier contenu" : ainsi, si cette date est dépassée, le "fichier contenu" n'est plus exploitable sur le serveur 3 ; et/ou
• du temps d'émulation maximum du "fichier contenu" : quand ce temps est dépassé, le client - utilisateur 1 est informé qu'il ne peut plus utiliser l'application émulée (REF LOG A) stockée dans le "fichier contenu" ; et/ou
• du nom de domaine sur lequel le "fichier contenu" est fonctionnel.
Il est également possible d'indiquer lors de la génération du "fichier contenu", les caractéristiques régionales que doit présenter le système d'exploitation présent sur le terminal informatique 2 du client - utilisateur 1 afin que l'application à émuler (REF LOG A) puisse être exécutée sur ce dit terminal informatique 2. A titre d'exemple, si le "fichier contenu" est utilisé sur un terminal informatique 2 équipé d'un système d'exploitation français alors qu'il a été indiqué que ce "fichier contenu" ne peut être utilisé que sur un terminal _
informatique 2 équipé d'un système d'exploitation américain, ledit "fichier contenu" ne peut être exécuté.
En outre, chaque ressource, donnée, information de configuration comprise dans le "fichier contenu" peut être découpée en blocs, et chacun de ces blocs peut être crypté en utilisant un algorithme et une clé différente.
Les données graphiques de l'application à émuler (REF LOG A), qui ont 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, ces données graphiques étant comprises dans un "fichier contenu". 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 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 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 (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 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.
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 3 comportant : o au moins un module client 4 transférable vers le terminal informatique 2, ce module client 4 comprend au moins un noyau d'émulation permettant d'émuler au moins une application déterminée (REF LOG A) et également un moyen de sauvegarde 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 (non représenté) procédant notamment : • au calcul et à la génération des paramètres et éléments nécessaires au lancement d'une application déterminée (REF_LOG_A) ;
• à la lecture des informations, données et ressources concernant le "fichier contenu" comprenant l'image 7 de l'application déterminée (REF LOG A) ;
• à la gestion de la transmission au module client 4 intégré dans le terminal informatique 2 du client - utilisateur 1 des paquets constituant le "fichier contenu" et donc l'application déterminée (REF LOG A) ; o au moins un "fichier contenu" paramétrable (non représenté), ayant un format spécifique et qui comprend l'ensemble des informations de configuration ainsi que les données et ressources nécessaires au fonctionnement de l'application déterminée (REF_LOG_A) à émuler.
Selon une variante d'exécution de l'invention, le dispositif nécessaire à la mise en œuvre du procédé selon l'invention peut également comporter :
• au moins un moyen de mémorisation persistante 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 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.

Claims

Revendications
1. 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 (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 ;
• 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) ; o un moteur d'inférence ; o au moins un "fichier contenu" paramétrable, ayant un format spécifique et qui comprend l'ensemble des informations de configuration ainsi que les données et ressources nécessaires au fonctionnement de l'application déterminée (REF LOG A) à émuler ; 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 à destination du serveur (3), cette requête ayant pour objet l'accès à une 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 correspondant 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 module client (4) afin d'obtenir le transfert du serveur (3) vers le client - utilisateur (1), d'au moins une partie desdites informations, données et ressources comprises sur le "fichier contenu" correspondant ; • le transfert du serveur (3) vers le client - utilisateur (1) desdites informations, données et ressources comprises dans le "fichier contenu"
• l'initialisation d'un noyau d'émulation compris dans le module client (4), cette initialisation et la sélection du noyau d'émulation s'effectuant sur la base desdites informations ou données comprises dans le "fichier contenu" qui ont été transférées à l'étape précédente ;
• l'intégration desdites données ou ressources préalablement transférées dans le noyau d'émulation, cette intégration s'effectuant sur la base des informations de configuration transmises ;
• l'exécution automatique de l'application déterminée (REF LOG A).
2. Procédé selon la revendication 1, caractérisé 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 d'un terminal informatique (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) ; • le calcul et la génération par un moteur d'inférence compris dans le serveur (3) des paramètres et éléments nécessaires au lancement de l'application déterminée (REF LOG A), ces paramètres pouvant être : o l'adresse où figure sur le serveur (3) un module client (4) comprenant notamment un noyau d'émulation qui permet d'émuler ladite application (REF LOG A) ; o des identifiants des composants logiciel et matériel à simuler, ces identifiants permettant de repérer ces composants dans un moyen de stockage structuré et indexable, tel qu'une base de donnée, compris dans le serveur (3) ; o des informations concernant le client - utilisateur 1 ; o des données relatives à l'affichage, à des entrées sonores, à des entrées utilisateur ; lesdits éléments pouvant quant à eux être notamment constitués par un "fichier contenu" ; • 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 ;
• l'initialisation du module client (4) et l'émission d'une requête par ce dernier (4) afin d'obtenir le transfert du serveur (3) vers le client — utilisateur (1) d'une partie desdites informations, données et ressources comprises sur le "fichier contenu" correspondant, ces informations qui permettent l'exécution automatique de l'application déterminée
(REF LOG A) concernant 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) desdites informations, données et ressources comprises dans le "fichier contenu" et qui sont relatives à l'image (7) de l'application déterminée à émuler (REF LOG A) présente sur le serveur (3) ;
• la transmission par le serveur (3) au client - utilisateur (1) d'une réponse comprenant lesdites informations, données et ressources comprises dans le "fichier contenu" ;
• l'initialisation automatique du noyau d'émulation compris dans le module client (4), cette initialisation ainsi que la sélection du noyau d'émulation s'effectuant sur la base desdites informations ou données comprises dans le "fichier contenu" qui ont été transférées préalablement ; • l'intégration desdites données ou ressources préalablement transférées dans le noyau d'émulation, cette intégration s'effectuant sur la base des informations de configuration transmises ;
• l'exécution de l'application déterminée (REF LOG A).
3. Procédé selon la revendication 2, caractérisé en ce que le "fichier contenu" comprend :
• des fichiers médias pouvant prendre la forme "d'images disques" tels que des cassettes, des disques durs, des CD - ROM ; • des fichiers médias pouvant prendre la forme d'images de mémoire morte telle que de l'EEPROM ;
• au moins un script pouvant être interprété par l'application client embarquée dans le navigateur Internet ;
• un état pré — sauvegardé de l'état de démarrage de l'application à simuler (REF LOG A).
4. Procédé selon l'une des revendications 2 et 3, caractérisé en ce que les paramètres nécessaires au lancement de l'application déterminée (REF_LOG_A) sont : • l'adresse où figure sur le serveur (3) un module client (4) comprenant notamment un noyau d'émulation qui permet d'émuler ladite application
(REF_LOG_A) ;
• des identifiants des composants logiciel et matériel à simuler, ces identifiants permettant de repérer ces composants dans un moyen de stockage structuré et indexable, tel qu'une base de donnée, compris dans le serveur (3) ;
• des informations concernant le client - utilisateur (1) ;
• des données relatives à l'affichage, à des entrées sonores, à des entrées utilisateur.
5. Procédé selon l'une des revendications 2 à 4, caractérisé en ce que les informations qui permettent l'exécution automatique de l'application déterminée (REF LOG A) concernant notamment la taille de chaque paquet constituant l'application (REF LOG A) ainsi que le nombre de ces paquets.
6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce que son initialisation est réalisée en sélectionnant un simple lien HTML sur une page WEB.
7. Procédé selon l'une des revendications précédentes, caractérisé en ce que le "fichier contenu" est découpé en paquets.
8. Procédé selon la revendication 7, caractérisé en ce que après l'initialisation de l'application à émuler (REF LOG A), les paquets nécessaires à l'exécution de cette application sont transmis "à la volée" du serveur (3) vers le client - utilisateur (1) de manière unitaire, ceci permettant notamment de lire dynamiquement à partir du serveur (3) les données et ressources correspondantes qui sont nécessaires au fonctionnement de ladite application (REF LOG A).
9. Procédé selon l'une des revendications 7 et 8, caractérisé en ce que dans un premier temps, seule une partie des informations, données et ressources comprises sur le "fichier contenu" est transférée du serveur (3) vers le client - utilisateur (1) afin d'obtenir un "fichier contenu" minimal lors de l'initialisation de l'exécution de l'application émulée ; par la suite, les autres données et ressources nécessaires au fonctionnement de ladite application sont lues dynamiquement à partir du serveur (3) lors de l'émulation de cette application ; ainsi, ces autres données et ressources sont transmises sous forme de paquets vers le terminal informatique (2) du client - utilisateur (1), et traitées séquentiellement.
10. Procédé selon l'une des revendications 7 à 9, caractérisé en ce que les paquets comprenant les données et ressources qui permettent l'exécution de cette application sont volatiles et sont traités par le noyau d'émulation séquentiellement sans nécessiter un stockage sur une mémoire de masse.
11. Procédé selon l'une des revendications 2 à 10, caractérisé en ce que le moteur d'inférence génère, lors de la deuxième étape dudit procédé, un "fichier contenu" spécifique en fonction de la nature de la requête initiale du client - utilisateur ( 1 ).
12. Procédé selon l'une des revendications 2 à 10, caractérisé en ce que le "fichier contenu" est généré par une personne physique puis est chargé sur ledit serveur (3).
13. Procédé selon l'une des revendications 11 et 12, caractérisé en ce que le "fichier contenu" est paramétré afin de mieux contrôler l'utilisation que le client — utilisateur (1) peut faire de l'application à émuler (REF LOG A), il est ainsi possible de procéder notamment aux paramétrages :
• de la date d'expiration du "fichier contenu" : si cette date est dépassée, le "fichier contenu" n'est plus exploitable sur le serveur (3) ; et/ou
• du temps d'émulation maximum du "fichier contenu" : quand ce temps est dépassé, le client - utilisateur (1) est informé qu'il ne peut plus utiliser l'application émulée (REF LOG A) stockée dans le "fichier contenu" ; et/ou
• du nom de domaine sur lequel le "fichier contenu" est fonctionnel.
14. Procédé selon l'une des revendications 11 à 13, caractérisé en ce que lors de la génération du "fichier contenu", il est indiqué les caractéristiques régionales que doit présenter le système d'exploitation présent sur le terminal informatique (2) du client - utilisateur (1) afin que l'application à émuler (REF LOG A) puisse être exécutée sur ce dit terminal informatique (2).
15. Procédé selon l'une des revendications précédentes, caractérisé en ce que chaque ressource, donnée, information de configuration comprise dans le "fichier contenu" est découpée en blocs, et chacun de ces blocs peut être crypté en utilisant un algorithme et une clé différente.
16. Procédé selon l'une des revendications précédentes, caractérisé en ce que les données graphiques de l'application à émuler (REF LOG A) sont sauvegardées sur le serveur (3) dans un premier format spécifique adapté au matériel d'origine à simuler, ces données graphiques étant comprises dans un "fichier contenu" ; afin de les rendre plus 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.
17. Procédé selon la revendication 16, 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.
18. Procédé selon la revendication 17, caractérisé en ce qu'en fonction du 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 en permettant audit cache de ne pas dépasser une taille limite.
19. Dispositif pour la mise en œuvre 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 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 ;
• au moins un serveur (3) du type Internet accessible au moins partiellement par l'intermédiaire dudit site Internet/Intranet, ce serveur (3) comportant : o au moins un module client (4) transférable vers le terminal informatique (2), ce module client (4) comprend au moins un noyau d'émulation permettant d'émuler au moins une application déterminée (REF_LOG_A) et également un moyen de sauvegarde 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 et éléments nécessaires au lancement d'une application déterminée (REF_L0G_A) ;
• à la lecture des informations, données et ressources concernant le "fichier contenu" comprenant l'image (7) de l'application déterminée (REF_LOG_A) ;
• à la gestion de la transmission au module client (4) intégré dans le terminal informatique (2) du client - utilisateur (1) des paquets constituant le "fichier contenu" et donc l'application déterminée (REF LOG A) ; o au moins un "fichier contenu" paramétrable, ayant un format spécifique et qui comprend l'ensemble des informations de configuration ainsi que les données et ressources nécessaires au fonctionnement de l'application déterminée (REF LOG A) à émuler.
20. Dispositif selon la revendication 19, caractérisé en ce qu'il comporte :
• au moins un moyen de mémorisation persistante 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 LOG A), ce module (6) rendant possible une synchronisation multi - utilisateurs.
21. Dispositif selon la revendication 20, 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 ipeer - 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).
PCT/FR2008/000171 2007-02-09 2008-02-11 Procede permettant de simuler le fonctionnement d'un dispositif ayant une architecture et un processeur determines a l'aide d'un autre dispositif connecte a un reseau informatique WO2008113917A2 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP08761871A EP2117661A2 (fr) 2007-02-09 2008-02-11 Procede permettant de simuler le fonctionnement d'un dispositif ayant une architecture et un processeur determines a l'aide d'un autre dispositif connecte a un reseau informatique
US12/526,423 US20100256971A1 (en) 2007-02-09 2008-02-11 Method for simulating the operation of a device having an architecture and a processor determined by means of another device connected to a computer network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0700995A FR2912523B1 (fr) 2007-02-09 2007-02-09 Procede permettant de simuler le fonctionnement d'un dispositif ayant une architecture et un processeur determines a l'aide d'un autre dispositif connecte a un reseau informatique.
FR0700995 2007-02-09

Publications (2)

Publication Number Publication Date
WO2008113917A2 true WO2008113917A2 (fr) 2008-09-25
WO2008113917A3 WO2008113917A3 (fr) 2008-11-13

Family

ID=38433003

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2008/000171 WO2008113917A2 (fr) 2007-02-09 2008-02-11 Procede permettant de simuler le fonctionnement d'un dispositif ayant une architecture et un processeur determines a l'aide d'un autre dispositif connecte a un reseau informatique

Country Status (4)

Country Link
US (1) US20100256971A1 (fr)
EP (1) EP2117661A2 (fr)
FR (1) FR2912523B1 (fr)
WO (1) WO2008113917A2 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8024469B1 (en) * 2010-03-05 2011-09-20 Brass Monkey Inc. System and method for connecting network sockets between applications
US9262420B1 (en) * 2012-04-23 2016-02-16 Google Inc. Third-party indexable text
JP2015058136A (ja) * 2013-09-18 2015-03-30 任天堂株式会社 情報処理プログラム、情報処理装置、情報処理システム、及び情報処理方法
JP2015154818A (ja) * 2014-02-20 2015-08-27 任天堂株式会社 据置型のゲーム装置、ゲーム装置、ゲームシステム、コンピュータプログラム及び速度制御方法
US10789654B1 (en) * 2015-07-27 2020-09-29 Intuit Inc. Web browsing systems for acquiring tax data during electronic tax return preparation
CN111683145B (zh) * 2020-06-08 2023-04-28 中国工商银行股份有限公司 客户端设备的配置方法、客户端设备、电子设备和介质
CN111880433A (zh) * 2020-07-02 2020-11-03 上海机电工程研究所 异地异构半实物仿真试验任务自动化实现系统及方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000065434A2 (fr) * 1999-04-27 2000-11-02 Openconnect Systems Incorporated Serveur et emulateur de terminal pour connexion continue a un systeme hote d'heritage avec interface hote directe as/400
US20010029205A1 (en) * 2000-03-30 2001-10-11 Sagahiro Taho Game program delivery system and apparatus used in same
US20020045484A1 (en) * 2000-09-18 2002-04-18 Eck Charles P. Video game distribution network
US6672963B1 (en) * 2000-09-18 2004-01-06 Nintendo Co., Ltd. Software implementation of a handheld video game hardware platform
US6711619B1 (en) * 1999-12-15 2004-03-23 Hewlett-Packard Development Company, L.P. Method, system, and apparatus for distributing and using computer-based applications over a network
WO2005117391A1 (fr) * 2004-05-20 2005-12-08 Turner Broadcasting System, Inc. (Tbs, Inc.) Systemes et procedes d'administration d'un contenu sur un reseau

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6763371B1 (en) * 1999-05-10 2004-07-13 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for collaborative communication in a communication network
US7285051B2 (en) * 2000-05-25 2007-10-23 Nintendo Co., Ltd. Game information storage medium and game system using the same
US6999912B2 (en) * 2001-03-13 2006-02-14 Microsoft Corporation Provisioning computing services via an on-line networked computing environment
US7337330B2 (en) * 2003-03-10 2008-02-26 Cyberview Technology, Inc. Universal game download system for legacy gaming machines
US20040266529A1 (en) * 2003-06-30 2004-12-30 Sony Computer Entertainment America Inc. Methods and systems for remote execution of game content and presentation on a wireless portable device
US7089594B2 (en) * 2003-07-21 2006-08-08 July Systems, Inc. Application rights management in a mobile environment
US8888600B2 (en) * 2004-08-25 2014-11-18 Igt Emulation methods and devices for a gaming machine

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000065434A2 (fr) * 1999-04-27 2000-11-02 Openconnect Systems Incorporated Serveur et emulateur de terminal pour connexion continue a un systeme hote d'heritage avec interface hote directe as/400
US6711619B1 (en) * 1999-12-15 2004-03-23 Hewlett-Packard Development Company, L.P. Method, system, and apparatus for distributing and using computer-based applications over a network
US20010029205A1 (en) * 2000-03-30 2001-10-11 Sagahiro Taho Game program delivery system and apparatus used in same
US20020045484A1 (en) * 2000-09-18 2002-04-18 Eck Charles P. Video game distribution network
US6672963B1 (en) * 2000-09-18 2004-01-06 Nintendo Co., Ltd. Software implementation of a handheld video game hardware platform
WO2005117391A1 (fr) * 2004-05-20 2005-12-08 Turner Broadcasting System, Inc. (Tbs, Inc.) Systemes et procedes d'administration d'un contenu sur un reseau

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2117661A2 *

Also Published As

Publication number Publication date
US20100256971A1 (en) 2010-10-07
FR2912523B1 (fr) 2009-07-10
WO2008113917A3 (fr) 2008-11-13
FR2912523A1 (fr) 2008-08-15
EP2117661A2 (fr) 2009-11-18

Similar Documents

Publication Publication Date Title
US11829186B2 (en) System and methods for integration of an application runtime environment into a user computing environment
CN104598257B (zh) 远程应用程序运行的方法和装置
WO2008113917A2 (fr) Procede permettant de simuler le fonctionnement d'un dispositif ayant une architecture et un processeur determines a l'aide d'un autre dispositif connecte a un reseau informatique
EP1076972A1 (fr) Systemd d'acces a un objet a l'aide d'un navigateur de type "web" cooperant avec une carte a puce
TW200834421A (en) Instant-on platform
EP3054629A1 (fr) Procédé de contrôle d'un équipement multimédia à partir d'un terminal mobile, programmes d'ordinateur, équipement multimédia et serveur correspondants
CN109165050A (zh) 程序的运行方法、装置、计算设备以及存储介质
FR2954536A1 (fr) Procede pour integrer dans un navigateur web le rendu graphique produit par une application graphique
FR2969334A1 (fr) Module materiel de securite et procede de debogage d'un tel module
FR2933510A1 (fr) Dispositif electronique portable comprenant une application portable et un module securise pouvant communiquer entre eux, et procede de communication associe
WO2010136317A1 (fr) Procédé de navigation sur le réseau internet, support d'enregistrement, serveur d'accès et poste d'utilisateur pour la mise en oeuvre de ce procédé
FR2969335A1 (fr) Module materiel de securite et procede de traitement dans un tel module
EP2633683B1 (fr) Exécution déportée d'une application logicielle au sein d'un réseau
EP2674860B1 (fr) Procédé de traitement de données par un module de navigation
EP2633440B1 (fr) Indexation et execution d'applications logicielles dans un reseau
FR2893439A1 (fr) 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
WO2004042572A2 (fr) Carte a microcircuit comportant des moyens de publication de ses objets informatiques
FR2813416A1 (fr) Procede et dispositif d'adaptation du contenu de documents sur un serveur d'informations
Vermeulen Linux sea
Shepherd Web Interface to a Game Emulation Server
WO2007010139A2 (fr) Procede et dispositif d'interaction entre des applications informatiques et un site distant
CN117539563A (zh) 一种通过虚拟应用程序处理本地文件的方法及设备
Srinivasa et al. MeghaOS: a framework for scalable, interoperable cloud based operating system
FR2942330A1 (fr) Dispositif de traitement de l'information communiquant permettant un acces rapide a un ensemble d'informations personnelles
WO2003030514A2 (fr) Procede et systeme d'acces en lignes au contenu de serveurs en reseau par un cd-rom

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08761871

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 2008761871

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 12526423

Country of ref document: US