FR 2839169 A1 20031031 FR 0205122 A 20020424 de phrases les plus gnincati par rapport la request inhale. i PROCEDE DE GESTION DE DONNEES POUR LE DEROULEMENT D'UN LOGICIEL INTERACTIF La présente invention se rapporte à un procédé de gestion de données pour le déroulement d'un logiciel interactif. El le conce rn e plus p récisément u n procédé de gestion de donnses entre au moins deux postes de communication électronique dont les utilisateurs dits challengeur et opposant sont destinés à coopérer de façon interactive pour le déroulement d'un logiciel. Une application particulière de ce procédé est le déroulement d'un logiciel de jeu interactif dont les joueurs, challengeur et opposants, peuvent communiquer électroniquement par le réseau de télophonie mobile au moyen de SMS (en anglais Short Message Service) ou par le réseau de télophonie mobile et d'lnternet au moyen de MMS (Multimedia Message Service), d'EMS (Enhanced Message Service) ou d'Emails. Un procédé de gestion de donnces de ce type est décrit dans le document de brevet WO 01/67275. Selon ce doeument, un serveur est systématiquement utilisé, équipé du logiciel de jeu et gérant toute donnée transmise entre joueurs, challengeur et opposants. La communication de ces données se fait par le réscau de télophonie mobile et d'lnternet par SMS ou Emails. La gestion des challenges se fait comme suit. D'un premier poste, le challengeur envoie au serveur son challenge. Ce challenge peut être envoyé à un opposant qui s'il l'accepte, envoie un message d'acceptation au serveur. Le logiciel peut alors se dérouler au sein du serveur qui ensuite envoie aux deux joueurs le résultat du jeu. Une telle gestion nocessite au minimum i'échange de cinq messages électroniques entre joueurs et serveur. De plus, les sessions ? de communications sont initiées soit par un des postes soit par le serveur. Ceci entrâne une complexité du mode de facturation dans le cas des sessions ouvertes par le serveur, les joueurs étant les clients. Par ailleurs, un tel procédé nocessite systématiquement un serveur de complexité relativement importante. L' invention résout ces problèmes et, pour ce faire, propose un procédé de gestion de données entre au moins deux postes de communication électronique dont les utilisateurs dits challengeur et opposant sont destinés à coopérer de façon interactive pour le déroulement d'un logiciel à instancier dit logiciel interactif caractérisé en ce que les deux postes sont équipés dudit logiciel, le challengeur envoie un premier message électronique contenant au moins une première partie du logiciel instancié et l'opposant envoie un second message électronique lié au premier et contenant une seconde partie de logiciel instancié, le logiciel se déroulant ensuite sur chaque poste. Selon un premier mode de réclisation préféré, les premier et second messages sont envoyés directement à l'autre poste. Selon ce mode de réclisation, le challengeur conna^'t I'opposant et transmet directement son défi à celui-ci. Dans ce cas, avantageusement, le premier message contient la proposition de déroulement du challengeur et le second message contient la réponse de déroulement de l'opposant et est lié audit premier message Les deux postes ayant alors toutes les informations pour le déroulement du logiciel, celui-ci peut se dérouler sur chaque poste. De préférence, lesdits postes de communication sont des postes télépho n iques mobiles et lesU its messages sont d es SMS. Selon un second mode de réclisation préféré, les premier et second message sont envoyées à un serveur. Selon ce mode de réclisation, le challengeur présente son défi sur le serveur, sa proposition pouvant être ouverte à tout opposant. Il est également ainsi possible de traiter la réponse de plusieurs opposants. Da ns ce cas, ava ntageusem ent, le premier message co ntient la proposition de déroulement du challengeur et le second message contient la réponse de déroulement de l'opposant, le serveur envoyant ladite proposition à l'opposant dans la même session de communication que le second message. Le serveur peut envoyer une adresse URL au challengeur dans la même session de communication que le premier message, cette adresse étant interrogée par le challengeur pour obtenir ladite réponse ou le serveur envoie une adresse URL au challengeur après réception du second message, cette adresse étant interrogée par le challengeur pour obtenir ladite réponse, De préférence, lesdits postes de communication sont des postes télophoniques mobiles. L'invention concerne également un poste télophonique mobile comprenant des moyens de communication électronique pour la mise en _uvre du procédé précisé ci-dessus, caractérisé en ce qu'il est équipé d'un logiciel interactif et comprend des moyens d'instanciation et de programmation de parties de logiciel et des moyens d'émission et de réception de parties de logiciel par lesUits moyens de communication. L' invention est décrite ci-après plus en détail à l' aide de figures ne représentant qu'un mode de réclisation préféré de l' invention. La figure l est une vue schématique représentant une première variante du procédé conforme à l'invention. Les figures 2 à 4 sont des vues schématiques représentant un mode multijoueurs selon cette première variante du procédé conforme à l'invention. Les figures 5 à 7 sont des vues schématiques représentant une seconde variante du procédé conforme à l'invention. Comme représenté sur la figure 1, deux postes C et O de communication électronique, qui peuvent être des postes télophoniques mobiles ou des ordinateurs, peuvent communiquer via le réssau de téléphonie mobile et/ou Internet au moyen des SMS, de MMS, d'EMS ou d'Emails. L'utilisateur du poste C est le challengeur et celui du poste O est un opposant, ces deux postes étant équipés dans leur dispositif informatique propre d'un logiciel interactif, de préférence un logiciel de jeu. A titre d'exemple, ce jeu peut être un jeu de simulation de guerre de robots. Au début du jeu, le challenger crée par programmation un robot. Par exemple, chaque robat est défini par trois caractéristiques qui sont "arme", "armure" et "mémoire". "Arme " symbolise la puissance offensive du robot, " armure " sa capacité défensive et " mémoire " sa capacité à être programmé. Chaque module de mémoire permet un code d' instruction. Des exemples d'instructions sont: avance, feu, pause... Ces instructions déterminent le comportement du robot. Les combats de robots ont lieu dans une arène qui peut être choisie parmi une série d'arènes différentes. Selon une première variante, aucun serveur n'est associé. Le challengeur conna^'t son opposant et lui envoie par son poste C un challenge ou défi par SMS, MMS, EMS ou Email, constituant un premier message P. Ce premier message P contient sa proposition de déroulement du logiciel, soit dans l'exemple de jeu décrit ci dessus, son robot programmé et l'arène associée. S'il accepte ce défi, I'opposant envoie au poste C par son poste O un second message contenant sa réponse Re à la proposition, soit son propre robat programmé et une liaison au premier message. Les deux postes ont alors toutes les données pour le déroulement du logiciel en local. Cette première variante s'applique également au jeu multijoueurs, plusieurs joueurs participant simultanément dans une même arene. Un tel jeu multijoueurs est schématisé sur les figures 2 à 4. Comme schématisé sur la figure 2, le challengeur conna^'t deux opposants et envoie à chacun d'entre eux un challenge ou déTi par SMS, MMS, EMS ou Email, constituant un premier message P. Ce premier message P contient sa proposition de déroulement du logiciel, soit dans l'exemple de jeu décrit ci-dessus, son robot programmé et l'arène associée. Ce message P contient également la liste des joueurs dans le cas d'un SMS. En effet, dans le cas d'un MMS ou d'un Email, cette liste de diffusion est systématiquement incluse dans le message. S'il accepte ce défi comme représenté sur la figure 3, le premier opposant envoie par son poste 01 un message contenant sa réponse Rel à la proposition, soit son propre robat programmé et une liaison au premier message, au poste C du challengeur et au poste 02 de l'autre opposant de la liste de diffusion. De même, s'il accepte ce défi comme représenté sur la figure 4, le second opposant envoie par son poste 02 un second message contenant sa réponse à la proposition Re2, soit son propre robot programmé et une liaison au premier message, au poste C du challengeur et au poste 01 de l'autre opposant de la liste de diffusion. Tous les postes C, 01 et 02 ont alors toutes les données pour le déroulement du logiciel en local, les trois robots et l'arène étant enregistrés sur les trois postes. Le nombre de messages initiés par joueur est donc égal au nombre de joueurs moins 1, soit un message dans le cas de deux joueurs schématisé sur la figure 1 et deux messages dans le cas de trois joueurs schématisé sur les figures 2 à 4. La figure 5 schématise une seconde variante de réclisation de l' invention. Selon cette variante, les postes communiquent via un serveur S par SMS ou Emails sur le réseau de télophonie mobile par exemple sous protocole WAP (Wireless Application Protocol) et Internet. En effet, actuellement, une telle communication à partir d'un télophone portable se fait par protocole WAP dans le réseau de télophonie mobile jusqu'à une passerelle transformant le format en format compatible avec le réseau Internet, puis par ce dernier réseau jusqu'au serveur (et inversement). Les figures 6 et 7 schématisent les échanges de messages. Un premier message 1 est envoyé par le challengeur gr&ce à un menu de jeu via le protocole WAP. Il s'agit de son défi, soit dans l'exemple de jeu décrit ci-dessus, son robot programmé associé à une arène choisie par consultation du site Internet de jeu. En échange, dans la même session de communication, le serveur renvoie au poste C un URL (en anglais Uniform Resource Locator) désignant cette ressource " arène,robat " dans le serveur ainsi qu'une estampille définie par l'arène choisie. Une estampille est ici une information temporelle associée à un événement. Elle définit la période de temps durant laquelle la proposition P ne pourra pas être modifiée par le challengeur. Un second message 2, 3 est envoyé par un opposant par les postes Oi grâce à leur menu de jeu. Il contient la réponse Ri, soit dans l'exemple de jeu décrit ci-dessus, le robot programmé par l'opposant pour combattre après consultation du site Internet de jeu. Le serveur S enregistre ce robot Ri de façon attachée à l'arène et au robat proposé P et en échange renvoie au poste Oi les données arène et robot proposé P. Le logiciel de jeu peut alors se dérouler sur le poste Oi en local. Lorsque le challengeur veut jouer, dans la période de temps o définie par l'estampille, il interroge l'URL transmise auparavant et enregistre toutes les réponses ou robots Ri qui ont choisi de combattre son robot dans l'arène en question, Le logiciel de jeu peut alors se dérouler sur le poste C en local. En variante, I'URL peut ne pas être transmise au challengeur comme précédemment dans la méme session de communication que le premier message mais lui être transmise après réception par le serveur S du second message Ri lui indiquant en même temps que les réponses ou robots Ri sont disponibles. De préférence, I'estampille est de 48 heures et pour tenir compte du temps de transmission des messages, la proposition ou robot proposé dispara^t du poste Oi de l'opposant environ 4 heures avant la fin du délai de 48 heures. Cette seconde variante s'applique également au jeu multijoueurs, plusieurs joueurs participant simultanément dans une méme arène. Dans ce cas, I'arène peut étre définie par un nombre maximal de joueurs ou par un laps de temps. Comme schématisé sur la figure 6, un premier message 1 est envoyé par le challengeur gr&ce à un menu de jeu via le protocole WAP. Il s'agit de son déti, soit dans l'exemple de jeu décrit ci-dessus, son robot programmé associé à une arène choisie par consultation du site Internet de jeu. En échange, dans la même session de communication de communication, le serveur renvoie au poste C un URL, désignant cette ressource K robot " dans le serveur ainsi qu'une estampille définie par l'arène choisie. Un message 2 est envoyé par un opposant de son poste 01 grâce à un menu de jeu via le protocole WAP. Il s'agit de la réponse R1, soit dans l'exemple de jeu décrit ci-dessus, le robot programmé par i'opposant pour combattre après consultation du site Internet de jeu. Le serveur S enregistre ce robot R1 de façon attachée à l'arène et au robot proposé P et en échange renvoie au poste 01 un URL, désignant cette ressource " robot " dans le serveur ainsi que l'estampille. Dans le cas o l'arène est définie par un laps de temps, un message 3 est envoyé par un opposant de son poste 02 grâce à un menu de jeu via le protocole WAP. Il s'agit de la réponse R2, soit dans l'exemple de jeu décrit ci-dessus, le robot programmé par l'opposant pour combattre après consultation du site Internet de jeu. Le serveur S enregistre ce robot R2 de façon attachée à l'arène et au robot proposé P et en échange renvoie au poste 02 un URL, désignant cette ressource " robot " dans le serveur ainsi que l'estampille. A la fin du laps de temps, toutes les données rattachées à l'arène sont transmises à chaque joueur grâce aux URL et tous les postes C, 01 et 02 ont alors toutes les donnses pour le déroulement du logiciel en local, les trois robots et l'arène étant enregistrés sur les trois postes. Dans le cas o l'arène est définie par un nombre maximal de joueurs, soit par exemple ici trois joueurs, un message 3 est envoyé par le dernier opposant de son poset 02 grâce à un menu de jeu via le protocole WAP. Il s'agit de la réponse R3, soit dans l'exemple de jeu décrit ci-dessus, le robot programmé par l'opposant pour combattre après consultation du site Internet de jeu. Le serveur S enregistre ce robot R3 de façon attachée à l'arène et au robot proposé P et en échange renvoie au poste 03 toutes les données déjà rattachées à I'arène, soit les robots des autres joueurs. Le logiciel de jeu peut alors se dérouler sur le poste 03 en local. Lorsque le challengeur et le premier opposant veulent jouer, dans la période de temps définie par l'estampille, ils interrogent l'URL correspondante transmise auparavant et enregistrent toutes les réponses ou robots Ri qui ont choisi de combattre dans l'arène en question. Le logiciel de jeu peut alors se dérouler sur le poste C et 01 en local. Grace à l' invention, la gestion interactive des données est réclisée au moyen d'une seule session directement ouverte par un serveur, les autres sessions étant initices par les joueurs ou clients, ce qui limite la nocessité de facturation indirecte. Bien que les modes multijoueurs ci-dessus décrits se limitent à trois joueurs, ils peuvent bien sur étre étendus à n joueurs de façon évidente, en suivant les mémes règles de transmission. REVENDICATIONS 1 - Procédé de gestion de données entre au moins deux postes de communication électronique (C, O) dont les utilisateurs dits challengeur et opposant sont destinés à coopérer de façon interactive pour le déroulement d'un logiciel à instancier dit programme interactif caractérisé en ce que les deux postes sont équipés dudit logiciel, le challengeur envoie un premier message électronique (P) contenant au moins une première partie du logiciel instancié et l'opposant envoie un second message électronique (Re, Ri) lié au premier et contenant une seconde partie du logiciel instancié, le logiciel se déroulant ensuite sur chaque poste (C, O). 2 - Procédé de gestion selon la revendication 1, caractérisé en ce que les premier et second messages (P. Re) sont envoyés directement à l'autre poste. 3 - Procédé de gestion selon la revendication 2, caractérisé en ce que le premier message (P) contient la proposition de déroulement du challengeur et le second message (Re) contient ia réponse de déroulement de l'opposant et est lié au dit premier message, - Procédé de gestion selon l'une des revendications précédentes, caractérisé en ce que lesUits postes de communication sont des postes télophoniques mobiles et lesdits messages sont des SMS. Procédé de gestion selon la revendication 1, caractérisé en ce que les premier et second message (P. Ri) sont envoyées à un serveur (S), 6Procédé de gestion selon la revendication 5, caractérisé en ce que le premier message (P) contient la proposition de déroulement du challengeur et le second message (Re) contient la réponse de déroulement de l'opposant, le serveur (S) envoyant ladite proposition (P) à l'opposant dans la même session de communication que le second message (Re). 7 - Procédé de gestion selon la revendication 6, caractérisé en ce que le serveur (S) envoie une adresse URL au challengeur dans la même session de communication que le premier message (P), cette adresse étant interrogée par le challengeur pour obtenir ladite réponse. 8 - Procédé de gestion selon la revendication 6, caractérisé en ce que le serveur (S) envoie une adresse URL au challengeur après réception du second message (Ri), cette adresse étant interrogée par le challengeur pour obtenir ladite réponse. 9 - Procédé de gestion selon l'une des revendications 5 à 8, caractérisé en ce que lesdits postes de communication sont des postes télophoniques mobiles. lO - Poste téléphonique mobile comprenant des moyens de communication électronique pour la mise en _uvre du procédé selon l'une des revendications précédentes, caractérisé en ce qu'il est équipé d'un logiciel interactif et comprend des moyens d'instanciation et de programmation de parties de logiciel et des moyens d'émission et de réception de parties de logiciel par lesUits