Brevet FR2897961A1 — publié le 20070831

PROCEDE DE GESTION DE L'EXECUTION D'UN JEU VIDEO POUR LA DIFFUSION EN TEMPS REEL DE PUBLICITES DYNAMIQUES La présente invention concerne le domaine de la publicité dans des jeux vidéo, telle que les jeux sur ordinateur personnel ou console, et a plus particulièrement pour objet un procédé de gestion de l'exécution d'un jeu vidéo pour l'affichage de publicités dynamiques, le procédé comprenant une pluralité d'étapes successives de chargement de modules comprenant des données du jeu vidéo et des données de publicité associées à ces données de jeu. Les jeux vidéo sont considérés comme des vecteurs importants de diffusion appréciés des publicitaires. Depuis l'essor des réseaux, notamment de l'Internet, la publicité statique consistant à sceller de façon définitive des données publicitaires à un emplacement dédié dans un jeu vidéo, a laissé place à la publicité dynamique requérant une mise à jour ou une évolution des données publicitaires affichées à un emplacement déterminé du jeu. Cette évolution des données est possible grâce aux réseaux de communication permettant de véhiculer des données nouvelles. On connaît des solutions d'affichage dynamique de publicités requérant une connexion permanente d'une plateforme de jeu, notamment dans le cadre de jeux en réseau pour lesquels un serveur centralisé réalise la sélection et l'intégration de publicités dans le jeu. II apparaît clairement que ces solutions connectées en permanence requièrent des ressources non négligeables de la plateforme de jeu de l'utilisateur pouvant entraîner une baisse de qualité dans la fluidité et la restitution du jeu. La présente invention vise plus particulièrement des solutions ne nécessitant pas une connexion permanente et des ressources allouées de façon continue pour assurer cette connexion à un réseau et la réception/transmission de données. On connaît par ailleurs, par le brevet US 6 882 978 (Sony), un système permettant l'affichage dynamique de publicités dans lequel, préalablement à l'exécution du jeu, soit une publicité soit des données de paramétrages pour choisir une publicité parmi plusieurs mémorisées en dur dans le jeu est(sont) téléchargée(s). Un inconvénient de cette solution réside dans le fait que l'étape de téléchargement peut retarder l'exécution du jeu d'autant plus que le nombre de publicités dans le jeu est important. Un autre inconvénient de cette solution concerne les faibles possibilités quant aux politiques publicitaires applicables. En effet, à un emplacement défini correspond une seule publicité (soit définie par le téléchargement soit par le fichier de paramétrage). II n'est donc pas possible d'afficher à un même emplacement différentes publicités lors d'une même exécution du jeu, par exemple si l'utilisateur repasse par le même endroit dans le jeu. On connaît par ailleurs la demande de brevet PCT WO 2005 / 086969 (Massive) qui décrit également un système pour l'insertion dynamique de publicités dans un jeu vidéo. Il décrit notamment un mode off line (non connecté) pour lequel la console de jeu stocke localement les médias et les données de campagne. La plateforme de jeu comprend une bibliothèque de fonctionnalités client intégrée initialement au jeu qu'utilise l'application jeu pour effectuer les connexions et les échanges de données avec les serveurs ainsi que la détermination de paramètres de visualisation des publicités affichées pour évaluer si la publicité a été effectivement visualisée. Dans cette solution, les téléchargements de publicités et données associées peuvent être réalisés soit en tâche de fond dès que le système est connecté soit par décision de l'utilisateur. La première solution n'est pas performante puisqu'elle requiert des ressources système et donc dégrade le rendu du jeu. La deuxième solution n'est également pas souhaitable puisqu'elle distrait et dérange l'utilisateur pendant sa partie. Un autre inconvénient de la solution Massive est l'utilisation d'une architecture basée sur une bibliothèque de fonctionnalités. De ce fait, tous les traitements sont réalisés pas l'application jeu via l'utilisation des fonctionnalités de la bibliothèque. En cas de mauvaise optimisation de l'application jeu (c'est-à-dire l'intégration d'instructions de commandes d'administration _ téléchargement, sélection de la publicité _), il apparaît que les performances d'exécution du jeu peuvent être altérées, notamment pour le rendu visuel. Dans cette demande de brevet, il est également mention de déterminer les caractéristiques de présentation des publicités afin d'identifier celles qui sont réellement vues par le joueur. L'inconvénient de la solution mise en place dans cette demande de brevet est que les calculs nécessaires à cette détermination requièrent également des ressources non négligeables, surtout pour des plateformes limitées, ce qui provoque une altération du rendu du jeu. La présente invention vise à pallier les inconvénients de l'art antérieur. Plus particulièrement, l'invention a pour but de fournir un procédé permettant de télécharger dynamiquement des publicités de façon transparente pour le joueur et sans réquisitionner des ressources système lors des phases de jeu. L'invention a également pour but de réaliser des calculs de visualisation de ces publicités en minimisant l'impact sur le rendu du jeu. L'invention permet également de fournir une solution efficace pour une gestion riche et dynamique des publicités à afficher. L'invention a également pour but de fournir de tels procédés visant à l'affichage dynamique, parfois ciblé, de publicités dans les jeux vidéo non connectés. L'invention a également pour but de fournir une architecture système optimisée du point de vue des performances de l'application jeu, en permettant à cette dernière de déléguer au maximum les tâches d'administration relatives aux publicités (connexion, téléchargement, sélection de publicités selon diverses campagnes, calcul des paramètres de visualisation des publicités...). A cet effet, l'invention a tout d'abord pour objet un procédé de gestion de l'exécution d'un jeu vidéo pour l'affichage de publicités dynamiques, le procédé comprenant une pluralité d'étapes successives de chargement de modules comprenant des données du jeu vidéo et des données de publicité associées à ces données de jeu, caractérisé en ce qu'il comprend, en outre et lors d'une étape de chargement d'un module, une étape de téléchargement depuis un serveur distant desdites données de publicités associées aux données de jeu vidéo d'au moins un module ultérieur au module en cours de chargement. Par conséquent, selon l'invention, on télécharge les données de publicités pendant les intervalles de temps non dédiés à l'exécution du jeu à proprement parler. Il est à noter que grand nombre de jeux vidéo se présentent sous la forme de tableaux ou niveaux dont le passage de l'un à l'autre requiert le chargement de nouveaux modules de jeux (les données du niveau). A titre d'illustration, ces niveaux sont liés entre eux de telle sorte qu'à un niveau donné, l'on sait quels niveaux sont accessibles directement et ceux qui sont accessibles via un niveau intermédiaire. L'exemple le plus simple consiste à ce qu'un seul niveau soit accessible lorsque le niveau précédent est fini. Pour chacun de ces niveaux, la plateforme charge des données associées. On observera qu'on exploite ces instants de chargement (éventuellement les chargements préliminaires au début du jeu ou à la fin d'une partie) pour télécharger via le réseau, si une connexion est effective, des nouvelles données de publicité ou les mettre à jour. En limitant le téléchargement à ces instants de chargement, on s'assure que celui-ci n'affecte pas le jeu vidéo en exécution. Par la connaissance des niveaux suivants, il apparaît efficace de télécharger en priorité les données de publicités relatives aux niveaux qui seront accédés en premier ou immédiatement accessibles après le niveau en cours. Cependant, il peut apparaître efficace d'anticiper le téléchargement de plusieurs niveaux à l'avance. Par ailleurs, ladite étape de téléchargement de données de publicités comprend une première étape, par ledit jeu vidéo, de téléchargement de données de paramètres comprenant notamment des données d'identification de média de publicités et des paramètres d'affichage desdits média, une étape de lecture desdites données de paramètres et une pluralité d'étapes de téléchargement desdits média dont les données d'identification sont lues. Dans les données de publicités, on distingue les médias qui sont les données à afficher aux emplacements dédiés dans le jeu, moyennant si nécessaire des mises en forme adaptées (rediimensionnement, déformation, ...), et les paramètres listant ces médias, éventuellement l'emplacement du jeu auquel il est associé, et donnant des conditions de sélection et d'affichage de ce média sous forme de fichier de campagne. Ce dernier indique par exemple qu'un média n'est valide (donc sélectionnable) qu'entre deux dates. Par conséquent, préalablement au téléchargement des médias, on lit dans les données de paramètres la liste des médias qui sont actifs pour la campagne en cours (campagne valide à la date de la lecture), éventuellement pour la campagne suivante (qui commencera à l'expiration de la campagne active). Le téléchargement des médias s'applique alors uniquement à ceux identifiés comme valides, c'est-à-dire ceux dont on a besoin. Il est alors prévu une étape de sélection de données d'identification (les données valides par rapport à la campagne en cours et/ou à la campagne suivante) et les étapes de téléchargement s'appliquent aux médias associés à ces données d'identification sélectionnées. Afin de ne pas affecter le jeu vidéo, le téléchargement est interrompu lorsque le chargement des modules prend fin. II est alors possible que certains médias ne soient pas téléchargés ou alors partiellement. II convient alors de prévoir que ladite étape de téléchargement de données de publicité comprend une étape de téléchargement de média dont les données d'identification ont été lues lors de l'étape de téléchargement de données de publicités réalisée lors d'un chargement antérieur de module. Par conséquent, les médias non téléchargés sont récupérés lors du chargement de module suivant. Avec cette stratégie, il convient d'anticiper le téléchargement des données de publicité plusieurs niveaux (chargements de modules) avant. En fonctionnement, les jeux vidéo nécessitent beaucoup de ressources de la plateforme pour assurer une fluidité et un rendu optimum. Il arrive cependant que certaines parties du jeu soient moins exigeantes en ressources. Afin de tirer profit de ces instants de répit , il est prévu d'ajouter au code informatique du jeu, une instruction de téléchargement (des médias en cours ou ceux identifiés comme à télécharger). Ainsi une partie desdites étapes de téléchargement est réalisée lors de l'exécution d'une instruction spécifique de téléchargement dans l'exécution du jeu vidéo. L'étape de chargement des modules consiste à charger dans une mémoire (mémoire vive de travail généralement) de la plateforme les données nécessaires à l'exécution du niveau du jeu accédé, y compris les publicités. Néanmoins, les médias à afficher sont déterminés selon la campagne de publicités (les données d'affichage). Il est ainsi prévu que le procédé comprend, préalablement à ladite étape de chargement d'un module, une étape de sélection des données de publicité associées audit module consistant en la sélection de média en fonction de données d'affichage, média et données d'affichage étant contenus dans des données de publicité téléchargées au préalable. Il est à noter que cette sélection peut tenir compte des sélections déjà effectuées et des affichages de publicité à l'écran déjà effectués, lesquels sont enregistrés dans un fichier d'historique. En effet, des campagnes de publicité peuvent contenir des paramètres de capping (c'est-à-dire limite du nombre total d'affichages d'une publicité) ou de rotation (entre plusieurs publicités), il est donc important de connaître les antécédents des publicités pour réaliser leur sélection. Lorsque aucun média n'a été téléchargé pour un emplacement ou lorsque ledit média sélectionné n'est pas ou est partiellement téléchargé, il est prévu que des données par défaut sont sélectionnées dans une base de données de publicité par défaut accessible directement par le jeu vidéo. Cette base de données par défaut peut être téléchargée au chargement initial du jeu, peut être déjà présente dans le code informatique du jeu (par exemple sur le CD) et peut se restreindre à une simple image ou un simple son par défaut applicable à tous les emplacements. Une optimisation de l'étape de chargement des modules peut consister en ce que ladite étape de téléchargement est déclenchée par l'exécution d'une instruction présente dans le code informatique du jeu vidéo relatif à l'étape de chargement. Par conséquent, on peut prévoir d'allouer toutes les ressources de la plateforme pour une partie du chargement des modules et autoriser les étapes de téléchargement pour une partie uniquement du temps de chargement. Comme il a été indiqué précédemment, des données d'historisation peuvent être enregistrées pour permettre la sélection des médias. Ces données ou des données statistiques dérivées (après traitement si nécessaire) peuvent être envoyées à un serveur de statistiques. Pour cela, le procédé comprend, en outre périodiquement, une étape de calcul de l'affichage desdites données de publicité et de transmission à un serveur de traitement distant de données statistiques issues dudit calcul. La détermination de l'affichage ou présentation des publicités à l'utilisateur a été abordée dans le document WO 2005 / 086969 précédemment cité. Or il faut remarquer que certains calculs à réaliser peuvent être coûteux en ressources pour le jeu. Afin d'optimiser l'impact de tels calculs sur le jeu, plusieurs possibilités sont offertes à l'éditeur de jeu. La première solution la plus basique est d'appeler le processus de calcul à chaque frame et dans son intégralité. Cette solution peut fonctionner pour des jeux peu gourmands en ressources ou dont les emplacements sont peu nombreux. Si jamais les ressources disponibles sont moins importantes, deux autres solutions se présentent. Pour la première, il est prévu dans le module de calcul de diviser son traitement en plusieurs frames. Le jeu peut donc appeler le processus de calcul en lui indiquant un nombre de frames (par exemple!, si le nombre d'emplacements du niveau est de 100 et que le nombre de frames donné est de 10, uniquement 10 emplacements sont testés à chaque frame). Pour cette deuxième solution, il est prévu que le procédé substitue une étape de calcul d'une image de rendu du jeu vidéo par ladite étape de calcul de l'affichage des données de publicité. II apparaît que pour la majorité des jeux vidéo, l'absence d'une image de temps en temps (par exemple toutes les 1 /2 s) n'est pas détectée par l'utilisateur. Par conséquent, la substitution d'une image par une étape de calcul sur la présentation d'une publicité n'altère pas le rendu de l'image précédente et de l'image suivante, et donc on s'assure qu'aucun artéfact sur les objets dessinés n'est visible. Des exemples d'approches de calcul de visualisation d'une publicité par un utilisateur sont proposés dans ce document WO 2005 / 086969, par exemple la comparaison de valeurs rnétriques à des seuils prédéfinis. Il apparaît que cette stratégie est très efficace pour les jeux où le réalisme tridimensionnel est élevé. Cette méthode et les déclinaisons à venir pourront faire, par conséquent, l'objet d'une protection spécifique le cas échéant. Parfois le nombre d'emplacements de publicité à un niveau du jeu peut être important. L'analyse de chacun de ces emplacements peut être coûteuse en terme de temps. L'invention propose d'optimiser l'étape de calcul sur ces publicités en ce qu'elle consiste en une première étape d'identification d'une publicité affichée par le jeu, une étape de calcul des paramètres d'affichage de ladite publicité pour déterminer si elle est effectivement visible et une pluralité d'étapes de calcul de paramètres d'affichage de publicités qui sont associées à ladite publicité visible par la présence de zones dans le jeu. Chaque niveau de jeu est découpé en zones qui contiennent plusieurs emplacements de publicité proches géographiquement. Par conséquent, les traitements sont plus rapides puisque, au préalable, on a construit un fichier (ou une basse de données) associant à chaque emplacement de publicité les emplacements voisins susceptibles d'accueillir une publicité. Cette approche repose sur le fait qu'à un instant donné si une publicité est clans le champ de vision de l'utilisateur, alors seules les publicités voisines sont susceptibles de l'être également. La détermination qu'une publicité est effectivement visible peut être basée sur des critères d'angle de vision, d'inclinaison de la publicité par rapport au point de visualisation, à la distance entre le point de visualisation et la publicité, ou à d'autres critères similaires à ceux évoqués dans le document WO 2005 / 086969. De ce qui précède, il est possible de déterminer si une publicité est visible à un instant donné et peut donc être comptabilisée comme vue. Néanmoins, il peut être intéressant de mémoriser le nombre de visualisation ou la durée d'une visualisation. Ainsi peut être prévu d'incrémenter un compteur associé à une publicité à chaque fois que le calcul des paramètres d'affichage permet de déterminer que la publicité est visible. Ces données sont ensuite envoyées comme données statistiques. Dans un mode de réalisation, le procédé comprend une étape d'incrémentation d'un compteur de visualisation si une même publicité est visible lors de deux étapes de calcul de l'affichage consécutives. Par conséquent, on mémorise le temps d'affichage de la publicité (on peut incrémenter la durée séparant les deux étapes consécutives ou si la périodicité est fixe ou très régulière, multiplier le compteur final par la durée moyenne de la période). Dans un mode de réalisation, lesdites données de paramètres ou les données statistiques sont transmises par fichiers numériques binaires, fichiers balisés, fichiers XML. L'invention a également pour objet une plateforme informatique pour la mise en oeuvre du procédé, comprenant : - des moyens de traitement agencés pour exécuter le code informatique d'un jeu vidéo, le code informatique comprenant des instructions pour le chargement successif de modules de données comprenant des données du jeu vidéo et des données de publicité associées à ces données de jeu, - des moyens réseaux agencés pour se connecter à un serveur distant et pour télécharger, lors du chargement d'un module, des données de publicités associées aux données de jeu vidéo d'au moins un module ultérieur au module en cours de chargement. Dans un mode de réalisation, lesdits moyens de traitement sont agencés, en outre, pour calculer la visibilité publicitaire durant le calcul d'une image de rendu du jeu vidéo, et pour transmettre à un serveur de traitement distant, à l'aide desdits moyens réseau, des données statistiques issues dudit calcul. On entend ici par visibilité publicitaire les données relatives à l'affichage effectif des données de publicités, par exemple la durée de présentation de ces données dans une configuration spatiale (angle, orientation, distance) favorable par rapport à des conditions (d'angle, d'orientation, de distance) limites. En outre, la plateforme informatique peut comprendre : - un module de traitement Scheduler apte à traiter lesdites données de publicité téléchargées pour déterminer les données de publicité à afficher dans ledit jeu - un module de mesure agencé pour communiquer avec lesdits moyens de traitements du jeu et recevoir des paramètres d'affichage desdites données de publicité affichées et comparer lesdits paramètres à des valeurs seuils. Ainsi le module de mesure identifie des publicités qui sont considérées comme ayant été vues par l'utilisateur. II pourra par la suite envoyer des données statistiques sur ces visualisations . Par ailleurs, l'invention a également pour objet un système comprenant une pluralité de plateformes informatiques et comprenant, en outre : - un serveur de publicités apte à transmettre des données de paramètre auxdites plateformes et à transmettre à une plateforme, sur requêtes de celle-ci, des médias de publicités identifiés dans les requêtes, lesdites requêtes comprenant des données d'identification de données numériques de média de publicité, - un serveur de traitement statistique apte à recevoir de ladite pluralité de plateformes et enregistrer des données d'affichage de publicités, et agencé pour traiter de façon asynchrone lesdites données reçues. On décrira maintenant, à titre d'exemple non limitatif, un mode de réalisation particulier de l'invention, en référence aux dessins schématiques annexés dans lesquels : - la figure 1 est un exemple d'architecture système pour la mise en oeuvre de l'invention - la figure 2 représente l'architecture fonctionnelle de la plateforme de jeu ; - la figure 3 illustre le fonctionnement du module réseau de l'exemple de la figure 2 ; - la figure 4 est un chronogramme des échanges entre la plateforme et le serveur de diffusion des publicités ; - les figures 5 et 6 illustrent l'organisation des emplacements publicitaires à l'intérieur d'un jeu - la figure 7 représente des exemples de paramètres pour le calcul de visualisation d'une publicité ; - la figure 8 illustre le chaînage des instructions entre le jeu et les modules d'exécution de la plateforme de jeu ; - la figure 9 illustre la communication entre la plateforme et le serveur de diffusion de publicités ; - la figure 10 illustre le traitement de fichiers statistiques fournis par la plateforme de jeu des utilisateurs ; et ù la figure 11 représente un exemple d'architecture pour la génération des fichiers de publicités. L'architecture générale pour la mise en oeuvre de l'invention est illustrée par la figure 1. La plateforme de jeu 10 (console ou ordinateur personnel PC) héberge l'application jeu 12 qui est exécutée, un gestionnaire du jeu 14 également appelé ci-après MlManager pour Module InGame Manager (gestionnaire du module InGame) et communiquant avec le jeu, un module InGame 16 affecté à la gestion des données de publicités. Ces différents gestionnaires/modules sont fournis avec l'application jeu, par exemple sur le même CD. La plateforme 10 est connectée, par un réseau de communication 18 type Internet, à un serveur de diffusion 20 hébergeant des données de publicités qui seront affichées lors de l'exécution du jeu 12 et à un serveur de statistiques 22 auquel elle communiquera des informations relatives aux publicités affichées pendant le jeu et présentées au joueur. En outre, le serveur de diffusion 20 est approvisionné en données de publicités par un back-office (système d'administration) 24. On va maintenant voir plus en détail ces différents modules et leur fonctionnement en relation avec les figures 2 à 11. Module InGame 16 Ce module est principalement composé de librairies. Son fonctionnement est le suivant : lors du démarrage du jeu, le module recherche automatiquement un fichier de campagnes de publicités qui lui est dédié sur le serveur de diffusion 20 et le télécharge sur le disque dur de la console 12 ou du PC ; lors de l'affichage d'une publicité dans le jeu vidéo, le jeu cherche automatiquement le fichier à l'emplacement prédéfini sur le disque dur et l'affiche à l'écran. A la fin d'une partie, le module génère un fichier texte comportant plusieurs informations quant à l'utilisation de la console et à la diffusion de la publicité, et l'envoie vers le serveur statistiques 22. Ce module permettra également la diffusion de contenu sonore (par exemple de la musique jouée à un emplacement de publicité) et vidéo (cinéma diffusant des bandes annonces). En référence à la figure 2, ce module se sépare en trois parties fonctionnelles distinctes, elles-mêmes responsables d'une ou plusieurs tâches. La première, appelée Module Réseau InGame (MRI) 160 se charge de tous les traitements liés à la couche réseau, la deuxième, appelée Schedu/er 162, a pour fonction de gérer le calendrier des campagnes de publicité et de choisir les média à afficher en fonction de ce calendrier ; enfin, la troisième partie 164 est la partie mesure de données, qui va comptabiliser les temps de visibilité des annonces, envoyer par le MRI 160 ces informations au serveur de statistiques 22 et éventuellement stocker ces informations dans des fichiers si leur envoi est impossible (absence de connexion Internet par exemple). Le système de fichiers utilisé par le système pour l'enregistrement des données relatives aux publicités dans une mémoire non-volatile de la plateforme 10 est le suivant : - un répertoire REP contient les fichiers de configuration - un répertoire REP/defau/t contient les média utilisés par défaut lorsqu'il n'y aura pas de campagne en cours - un répertoire REP/carrent contient les fichiers de la campagne en cours à afficher - un répertoire REP/download contient les fichiers de la campagne en cours de téléchargement - un répertoire REP/report contient les fichiers d'analyse des parties Module Réseau InGame 160 Ce module a trois tâches bien définies à accomplir : - le téléchargement des campagnes, - l'intégration des annonces téléchargées, et - l'envoi des fichiers d'analyse. La structure de ce module est illustrée par la figure 3. Ces tâches vont s'articuler autour d'un client réseau intégré à ce module. Ce client a pour charge de télécharger et d'envoyer des fichiers en utilisant le protocole Http (HyperText Transfer Protocol, protocole de transfert hypertexte). Le traitement de ces tâches repose sur l'utilisation du multi-threadirig (traitement multiprocessus) : en effet, les traitements de téléchargement et d'envoi de fichier peuvent être longs et doivent pouvoir être interrompus à tout moment à la demande du jeu. A sa création, le MRI crée le processus (thread) 30 du Down/oad Manager 32 qui va lui-même tenter de mettre en place le client réseau, notamment par une tentative de connexion au serveur d'application 20. Un retour est envoyé au MRI indiquant si la connexion a pu être établie. II s'en suit le téléchargement des annonces : cette fonction s'articule entre le serveur de diffusion 20 et le MRI 160 en utilisant la cinématique suivante, illustrée par la figure 4 : (a). Le MRI indique au thread du Down/oad Manager qu'il peut commencer à télécharger (pour le fonctionnement de cette communication entre threads, voir la partie Risques technologiques ci-après) (b). Le Download_Manager envoie une requête http 34 avec en argument l'identifiant du jeu (c). Le serveur répond en indiquant l'identifiant de la dernière campagne disponible (d). Le Down/oad_Manager envoie une requête http pour récupérer le fichier campagne, s'il est plus récent que celui disponible sur le PC ou la console (e). Le Download Manager récupère le fichier (f). Le Down/oad Manager analyse le fichier campagne pour déterminer les médias à récupérer en faisant la différence avec ceux déjà récupérés en local (g). Le Down/oad Manager commence alors le téléchargement de cette liste de fichiers (h). Il vérifie la signature numérique des fichiers téléchargés pour vérifier leur provenance (i). Lorsqu'il a fini, il recommence lesétapes (f) et (g), tant que du temps de traitement lui est donné (j). Le Down/oad_Manager peut être interrompu à tout moment par le MRI, à la demande du jeu. Il faut donc conserver en mémoire la liste des médias à télécharger. La liste est réutilisée si le jeu redonne ultérieurement du temps de traitement au Down/oad_Manager. De plus, il faut pouvoir reprendre des téléchargements interrompus ; pour cela, on utilise l'entête Range du protocole HTTP permettant de spécifier la partie du fichier voulue et de ne récupérer ainsi que les parties manquantes. Le fichier de campagne est un fichier XML qui contient les informations générales de la campagne (son identifiant, sa version et d'autres paramètres), la liste des annonces avec leur identifiant et leurs dates de début/fin d'affichage. Une annonce a une durée maximum d'affichage (capping) qui correspond à un nombre de contacts. Un contact correspond à une certaine durée interrompue de visibilité de l'annonce. Lorsque les dates d'affichage d'une annonce sont dépassées, sa diffusion peut se poursuivre durant quelques jours si jamais d'autres média plus récents ne sont pas disponibles. Cette tolérance à la diffusion est paramétrée en nombre de jours dans la campagne. Les emplacements dans le jeu sont de dimensions différentes. Chaque annonce est disponible dans toutes les tailles d'emplacements possibles. Le Down/oadManager détermine les annonces à télécharger en fonction de deux critères : - leur date de début d'affichage - leur priorité de diffusion : un annonceur sera diffusé prioritairement sur un ou plusieurs types d'espaces de publicité déterminés Sont téléchargées ensuite les annonces qui correspondent au stock , ce sont des annonces d'un format non préférentiel pour l'annonceur mais qui peuvent lui permettre éventuellement d'atteindre le pourcentage de visibilité voulu. Une optimisation entre la bande passante et l'utilisation des ressources peut être prévue. Pour cela la bande passante réseau est mesurée, puis les transferts réalisés par le MRI sont limités à une valeur maximale de cette bande passante, par exemple 20%. Concernant la diffusion des annonces, le client réseau MRI n'est pas utilisé. Elle n'est pas contrôlée par un thread car son traitement est beaucoup plus rapide. Sa fonction est d'intégrer les fichiers téléchargés à la campagne en cours : (a). L'/ntegration_Manager 36 parcourt les répertoires REP/down/oad et REP/current et supprime les fichiers qui ne sont pas liés à la campagne courante (date de validité périmée). (b). L'Integration_Manager 36 vérifie l'intégrité des fichiers restants du répertoire REP/down/oad et les déplace clans le répertoire REP/current. Concernant l'envoi des fichiers d'analyse produits par le module de mesure 164, le MRI a pour mission d'envoyer au serveur de statistiques 22 les fichiers d'analyse générés lors de la prise de mesures au cours du jeu : (c). Ces données sont envoyées régulièrement par le MRI (temps entre chaque envoi défini dans la campagne), pour cela le MRI crée le thread 38 du ReportingFiles_Manager 40 (d). Le ReportingFi/es_Manager traduit en une requête Http les dernières données mesurées par le processus de calcul et envoie cette requête au serveur de statistiques 22. L'impact d'une requête par rapport à l'exécution du jeu est négligeable ; la quantité de données envoyées est faible (fichier texte la plupart du temps) (e). Le serveur reçoit, traite cette requête et signifie son traitement par un code de retour positif (f). Le processus de calcul se réinitialise et reprend les mesures à zéro (g). Les opérations (b) à (d) sont répétées tant que le jeu continue. (h). Les données qui n'ont pu être envoyées (problème de connexion Internet par exemple) sont stockées sous formes de fichiers sur le disque dur et leur envoi est effectué à la session suivante de jeu. Ils sont conservés tant que leur envoi échoue mais leur nombre est limité (ce nombre est paramétré dans le jeu) et les plus anciens sont ainsi supprimés au fur et à mesure que de nouveaux fichiers sont enregistrés. Module Scheduler 162 Ce module a pour tâche de gérer le calendrier de la campagne et de choisir les médias à afficher en fonction de ce calendrier. Cette tâche est réalisée au chargement du niveau du jeu, et avant le chargement des ressources de ce niveau, puisque ce sont ces mêmes ressources qui sont modifiées. On rappelle qu'un jeu est généralement découpé en niveaux, chacun de ces niveaux contenant un certain nombre d'emplacements de publicités statiques (panneaux...) et/ou dynamiques (publicité sur une voiture...), en référence à la figure 5. Ces informations sur le découpage du jeu sont fournies par l'éditeur du jeu et répertoriées dans un fichier XML qui est utilisé par les modules Scheduler et de mesure. Ce fichier est disponible au téléchargement sur le serveur de diffusion 20. Le calendrier donne les informations suivantes : - dates de début/fin de publication pour chaque annonce, - valeurs de rotation et de capping pour chaque annonce. Éventuellement, les mesures de visibilité déjà effectuées par le module de mesure 164 (voir ci-après) donnent des informations sur : - les valeurs courantes de rotation et capping pour chaque annonce À partir de ces informations, un algorithme est appliqué pour déterminer les données de publicités ou annonces à appliquer aux emplacements. La rotation fonctionne ainsi : si plusieurs annonces peuvent être diffusées sur le même emplacement, elles vont être affichées successivement : chacune de ces annonces est affichées un nombre de fois égal à sa rotation (si l'annonce A a une rotation de 2, B de 3, C de 1, la séquence de diffusion est deux fois A, puis trois fois B, puis une fois C, puis de nouveau deux fois A etc...). Le capping permet, quant à lui, de limiter la diffusion d'une annonce à un temps déterminé. En outre, le Scheduler tient compte du format des média. II est difficile de placer une image sur un emplacement dont la dimension diffère de façon importante de celle de l'image, sans altérer la qualité d'affichage. Ainsi, le Schedu/er place les images sur des emplacements qui leur correspondent ou qui en sont le plus proche possible. Cependant, des ajustements, redimensiionnements des annonces (images, vidéo, ...) pourront être réalisés. Module de mesure 164 Ce module est plus fortement lié au jeu que les deux autres modules 160 et 162 puisqu'il utilise le moteur du jeu pour mesurer la visibilité des annonces au cours des parties. Pour réaliser des mesures, ce module fait appel au fichier XML de découpage des niveaux présenté précédemment mais de façon plus poussée puisqu'il utilise des informations d'optimisation également présentes dans ce fichier. En effet, dans le but d'accélérer le temps de traitement de cette mesure de visibilité, il n'apparaît pas efficace de tester la visibilité des annonces une par une. En référence à la figure 6, il est donc prévu de mettre en place une optimisation consistant à associer à chaque emplacement E de publicité un identifiant de zone qui regroupe tous les emplacements proches géographiquement. Autrement dit, l'algorithme parcourt d'abord la liste des emplacements un par un, et dès que l'un d'entre eux est visible, il ne teste plus que ceux qui sont présents dans son groupe de proximité géographique. Cela permet d'éviter de tester alors des emplacements très éloignés de celui visible et donne donc un gain de temps conséquent dans la majorité des cas, même si cela n'est bien sûr valable que pour les emplacements statiques. Les emplacements dynamiques (voiture, personnage, ...) sont testés un à un. Un exemple de mesure est fourni en référence à la figure 7. Le calcul est basé sur la normale et un point situé au centre de l'emplacement publicitaire et consiste à tester si ce point est dans le champ de vision du joueur et donc affiché à l'écran. Si cela est le cas, un calcul d'angle entre le vecteur de la caméra et la normale est réalisé pour s'assurer que le panneau est bien orienté et que le message est visible (par exemple, vérifier que le joueur ne regarde pas le dos du panneau...). L'angle a correspond à l'angle de bonne visibilité sur l'emplacement. Si le joueur est en dehors de cet angle, le système considérera que l'emplacement n'est pas vu. Cette mesure se fait par un appel au moteur 3D du jeu et c'est également le jeu qui déterminera à quel moment il veut faire ces mesures (à chaque trame, toutes les n trames, toutes les n images, Régulièrement pendant les mesures (toutes les 5 minutes par exemple), ce module 164 transmet les informations calculées au MRI qui va lui-même les envoyer au serveur de statistiques 22. Ces informations sont les temps de visibilité par annonce. Si l'envoi échoue, les données sont stockées dans un fichier d'analyse. Le nombre de fichiers d'analyse à stocker est limité, afin de ne pas prendre trop de place mémoire sur la machine, les plus anciens sont donc écrasés si ce nombre maximal est atteint et qu'ils n'ont pas encore été envoyés. Ces fichiers d'analyse peuvent être cryptés après leur création pour garder confidentielles les données qu'ils contiennent. Ce module génère également un fichier XML résumant les informations générées pour l'ensemble de la campagne. Ce fichier contient les informations de rotation et de capping pour chaque annonce et sur l'ensemble des parties, ces informations sont donc mises à jour à chaque partie. Ce fichier est propre à une campagne et est donc supprimé dès lors qu'une nouvelle campagne débute. Accessoirement, le module InGame 16 permet la diffusion de contenus sonores et vidéos. Le contenu audio est utilisé de deux façons : - association d'un fichier son à un emplacement : la publicité audio est jouée dès que le joueur s'approche. Afin de ne pas occuper trop de place mémoire sur le disque dur avec ces fichiers audio, ils sont diffusés en continu (streaming). - mise en place d'une radio qui diffuse des morceaux de musique d'un annonceur La vidéo est utilisée par exemple dans un cinéma qui propose de regarder en streaming des bandes annonces ou de les télécharger. Les modules 160, 162 et 164 ne sont pas toujours actifs, notamment lors du téléchargement des publicités et du reporting (statistiques) si la connexion Internet n'est pas disponible. Ils sont toujours chargés lors de l'exécution du jeu, et attendent que la connexion à Internet soit établie ainsi que le besoin d'envoyer ou de recevoir un fichier. Gestionnaire de jeu MlManager 14 En référence à la figure 2, le MlManager est un module de gestion inter-opérant entre l'application jeu et les modules du module InGame. Ce module regroupe tous les éléments et fonctionnalités relatifs aux publicités qui vont être dépendants du jeu ou vont interagir avec le jeu. Optimiser l'intégration de ce module dans le jeu vise à minimiser ses dépendances et à faciliter ses interactions. Ce module représente le point d'entrée unique pour le jeu pour envoyer des informations notamment chronologiques (quand télécharger, quand envoyer etc....). A la réception, le MlManager redistribue ensuite ces informations aux modules MRI 160, Scheduler 162, mesure 164 concernés. Un exemple de communication est fourni en référence à la figure 8. Le jeu 12 indique au MlManager 14 par la méthode StartDownload() (il s'agit d'une fonctionnalité ou d'une fonction disponible dans le module concerné) que des ressources sont disponibles pour commencer à télécharger des annonces, le MlManager 14 va alors se charger de transférer cette information au MRI 160, qui va lui-même la transmettre au Download_Manager 32, pour procéder aux téléchargements tels que présentés précédemment. L'interaction entre le jeu 12 et le gestionnaire MlManager 14 concerne plusieurs points : la commande de téléchargements (a), la mesure de visibilité des publicités du jeu (b) et l'interaction avec le Scheduler (c). (a). La partie la plus simple de ces interactions est l'appel au module réseau. Quand le jeu le décide, c'est-à-dire qu'au préalable une instruction appropriée a été intégrée au code du jeu, il fait appel au MlManager pour commencer/arrêter les téléchargements/envois de fichiers d'annonces/d'analyses. Pour cela, il appelle la méthode StartDownload() du MlManager ou équivalente. Le seul code à ajouter au jeu concerne donc ces appels de méthode aux endroits souhaités, idéalement lors d'opérations ne requerrant pas trop de ressources pour le rendu du jeu. (b). La partie la plus riche en interactions est la partie mesure de visibilité effectuée par le module mesure 164. En pratique, le jeu fournit un pointeur sur une méthode de son moteur qui va servir à calculer la visibilité d'un emplacement. Cela limite l'échange d'informations à une seule communication puisque le module de mesure n'a ensuite qu'à parcourir les emplacements et à appeler pour chacun d'entre eux cette méthode du moteur du jeu. Étant intégrée directement au moteur du jeu, cette méthode sera d'autant plus efficace et permettra de tester la visibilité avec toutes les optimisations permises par le moteur et également avec toutes les options voulues (tests de collision ou non etc...). Par ailleurs, le jeu indique au module de mesure 164 la chronologie de la mesure. Le jeu fait appel à une première méthode StartMeasure() à laquelle il fournit l'identifiant du niveau qui va être joué afin que le module de mesure charge la liste des emplacements à tester. Il fait ensuite appel au cours de la partie à la méthode OnUpdateMeasure(), par laquelle la mesure est effectuée ; c'est l'éditeur de jeu qui décide quand faire appel à cette méthode (toutes les frames, toutes les n frames etc.) en plaçant l'instruction appropriée dans le code du jeu. Enfin, le module de mesure peut accéder au moteur du jeu afin de tester la visibilité des emplacements grâce au champ de vision de l'utilisateur. Pour cela, le jeu fournit des pointeurs de fonction que le module de mesure peut utiliser directement. (c). Quant aux interactions liées au Scheduler 162, ce dernier sélectionne les médias à afficher. Ceux-ci sont présents dans le répertoire REP/current. Le MlManager fournit au jeu des méthodes qui lui permettent d'accéder pour chaque emplacement à l'annonce qui lui correspond. Lors du chargement des modules d'un niveau du jeu par l'application jeu, le MlManager fournit les données relatives aux médias sélectionnés afin que ceux-ci soient disponibles en mémoire pour l'application jeu lors de l'exécution du nouveau niveau du jeu. Éventuellement, il pourra être prévu que ces médias ne soient pas chargés en mémoire lors de cette phase de chargement des modules du niveau mais que l'application jeu appelle lorsque cela est nécessaire le MlManager pour lui transmettre le médiia approprié à un emplacement visible. Cette solution autorise que le média à afficher ne soit pas encore téléchargé au moment du chargement du nouveau niveau de jeu et qu'il puisse être téléchargé avant qu'il soit appelé. Cependant, des ressources appropriées doivent être mise en oeuvre au moment de la détermination du média par le Scheduler suivant la requête faite par l'application jeu au MlManager. Un risque inhérent serait alors l'altération du rendu vidéo à cet instant. Serveur de diffusion 20 Le serveur de diffusion 20 est le module d'envoi des campagnes aux plateformes de jeu des joueurs. Il permet de diffuser très rapidement un volume considérable de données (images, vidéos, XML, .). En référence à la figure 9, ce module se compose d'un serveur principal 50, sur lequel sont effectuées les requêtes 52 du module InGame 16 de la plateforme 10. Le serveur répond par un XML 54, qui contient la liste des publicités à afficher, chaque publicité étant définie par un identifiant, un fichier particulier à télécharger (le média), une taille et une chaîne de caractères de contrôle (MD5 32 bits) permettant de vérifier l'intégrité du fichier (ce qui supprime le risque d'envoi de fichiers corrompus ou manipulés). L'algorithme MD5 est choisi pour des raisons de rapidité de décodage (qui doit se faire sur la plateforme de jeux). Le fichier retourné par le serveur peut dépendre de plusieurs paramètres, notamment de l'adresse IP de la plateforme 10 puisqu'au travers de celle-ci il est possible de connaître la localisation géographique de l'utilisateur et de fournir un fichier XML tenant compte de cette localisation (par exemple pour la publicité des commerçants du même quartier)...DTD: Une fois que le module InGame 16 a obtenu la liste des fichiers à télécharger par le serveur principal 50, il émet une requête 56 de téléchargement des fichiers sur le(s) serveur(s) de publicités 58 stockant les fichiers média 60, qui permet un débit très important en bande passante. Les fichiers sont ainsi téléchargés (62). Si le fichier téléchargé est conforme à la chaîne de contrôle (64), le fichier est stocké sur l'espace mémoire de la console alloué (66) et le téléchargement du fichier suivant commence (68). L'utilisation de ces deux serveurs permet de diviser la charge de travail du serveur de diffusion, notamment en offrant une infrastructure pour le serveur principal 50 qui ne gère que des fichiers légers (de petite taille). Ainsi, ce serveur est en permanence accessible pour les utilisateurs et leur fournit le fichier XML approprié. Serveur de statistiques 22 Le serveur de statistiques 22 est un module d'observation du Web, de détection des utilisateurs et de récolte d'informations. Ce module est le destinataire des fichiers textes générés par le module mesure 164 et est chargé de l'analyse statistique de ces données. Ce module est indispensable pour mesurer l'impact d'une campagne sur les joueurs. Le suivi des campagnes est implémenté dans le module InGame 16. En référence à la figure 10, lors de phases peu actives ou inactives du jeu (changement de niveau par exemple), le module envoie une requête HTTP sur le serveur principal de statistiques 70. Cette requête contient diverses informations, à titre d'exemple : - jeu utilisé - durée d'affichage de chaque publicité - temps de jeu Le transfert a lieu en HTTP par des fichiers textes au format XML (72), fichiers simples mais structurés, qui évitent un traitement spécifique en amont comme en aval, qui consommeraient des ressources inutilement. Le serveur de statistiques 22 procède en deux étapes. La réception du fichier texte s'en suit immédiatement d'un stockage (74) simple et rapide de l'information envoyée par les plateformes dans une base de données. En effet, la masse d'informations reçues peut être considérable selon le nombre de plateformes connectées et la période d'envoi de données (par exemple toutes les 5 minutes), et il est donc impératif de ne pas traiter l'information lors de son arrivée, ce qui pourrait ralentir la réception des autres fichiers texte. Les fichiers sont traités (76) par le serveur de statistiques lors des périodes de faible activité. En fonction de la charge des serveurs, il est prévu de passer ce traitement en priorité haute, pour une remontée de données la plus rapide possible, permettant ainsi une analyse temps réel des données dans la base de données. Les résultats sont disponibles sur le back-office principal 24, dès leur analyse, par exemple par transmission sécurisée SSL (Secure Sockets Layer Protocol, sécurisation de la couche socket). Cela permettra au final de vérifier le bon fonctionnement de l'installation, et de confirmer les statistiques comparées à celle de la veille ou du mois précédent quasiment en temps réel. Une redondance des serveurs peut être prévue. Back-office 24 Le back-office est le module de gestion des publicités à destination des jeux vidéo. Ce module est majoritairement formé d'une base de données, permettant à la fois la diffusion des campagnes par pays, par jeu et par joueur et la gestion des ressources réseau. En référence à la figure Il, le module permet tout d'abord de décider des campagnes, de définir les périodicités et les durées d'affichage, les formats pris en charge, les jeux concernés. Toutes ces informations sont stockées dans une ou plusieurs base(s) de données 80, inaccessible(s) depuis l'extérieur. Ensuite, une fois une campagne renseignée, une génération des fichiers publicitaires est lancée (82), ainsi que la génération des fichiers XML qui permettent de pointer vers le serveur de publicités. Enfin les fichiers sont transférés sur le serveur de publicité 58 et sur le serveur principal 50 et on notifie ces derniers des modifications apportées aux fichiers. De ce qui précède, la présente invention permet de : - générer des fichiers statistiques sur des consoles ou des PC et les rapatrier même après une extinction brutale de la machine. L'invention permet de : - stocker des informations statistiques -sauvegarder ces informations dans des emplacements mémoires prédéfinis (carte mémoire, disque dur, RAM etc....) - de les envoyer sur des serveurs même après une extinction sauvage - mettre en place une stratégie intelligente de téléchargement. Le processus de rapatriement des publicités est contrôlé par le module intégré dans le jeu et ne permet le déclenchement du téléchargement que lorsque les ressources de la machine sont suffisantes pour ne pas influer sur la fluidité du jeu (soit parce qu'il s'agit d'une phase de chargement de modules soit parce qu'une instruction appropriée a été intégrée au code informatique de l'application jeu). - développer un algorithme intelligent de diffusion publicitaire. Afin de garantir un impact aux annonceurs, le module intégré au jeu est capable de modifier automatiquement les annonceurs présents sur chaque emplacement publlicitaire d'un jeu afin d'adapter la diffusion des messages au comportement de jeu du joueur ; Ces différentes innovations se traduisent par une rupture dans le type de services offerts aux annonceurs et aux éditeurs. Jusqu'à présent, l'intégration publicitaire devait se faire en amont ce qui ne permettait ni mise à jour, ni contrôle de la diffusion. En outre, le reporting permet aux éditeurs de mieux connaître leurs joueurs et ainsi d'adapter leurs stratégies de développement. De ce fait, l'invention offre les avantages suivants : - il n'est pas nécessaire que les jeux soient jouables en ligne ou connectés en permanence pour recevoir de la publicité. Une connexion Internet épisodique ou périodique suffit ; - il n'y a pas de pop-up (fenêtre contextuelle) ou autres désagréments pour l'utilisateur, rien n'interfère avec l'exécution du jeu ; - les équipes de développement choisissent les emplacements des publicités et chaque emplacement publicitaire est personnalisé à l'environnement du jeu ; - l'intégration de la publicité dans les jeux vidéo s'effectue sans impact, la consommation de mémoire est minimale et sans ralentissement notable pour le joueur ; - le réseau atteint les joueurs sur tous les types de plateformes exploitant des jeux équipés de la présente invention. REVENDICATIONS 1. Procédé de gestion de l'exécution d'un jeu vidéo pour l'affichage de publicités dynamiques, le procédé comprenant une pluralité d'étapes successives de chargement de modules comprenant des données du jeu vidéo et des données de publicité associées à ces données de jeu, caractérisé par le fait qu'il comprend, en outre et lors d'une étape de chargement d'un module, une étape de téléchargement depuis un serveur distant desdites données de publicités associées aux données de jeu vidéo d'au moins un module ultérieur au module en cours de chargement. 2. Procédé selon la revendication 1, caractérisé par le fait que ladite étape de téléchargement de données de publicité comprend une première étape, par ledit jeu vidéo, de téléchargement de données de paramètres comprenant notamment des données d'identification de média de publicités et des paramètres d'affichage desdits média, une étape de lecture desdites données de paramètres et une pluralité d'étapes de téléchargement desdits média dont les données d'identification sont lues. 3. Procédé selon la revendication 2, caractérisé par le fait que ladite étape de téléchargement de données de publicité comprend une étape de téléchargement de média dont les données d'identification ont été lues lors de l'étape de téléchargement de données de publicités réalisée lors d'un chargement antérieur de module. 4. Procédé selon l'une quelconque des revendications 2 et 3, caractérisé par le fait qu'une partie desdites étapes de téléchargement est réalisée lors de l'exécution d'une instruction spécifique de téléchargement dans l'exécution du jeu vidéo. . Procédé selon l'une quelconque des revendications 2 à 4, caractérisé par le fait que, préalablement à ladite étape de chargement d'un module, une étape de sélection des données de publicité associées audit module consistant en la sélection de média en fonction de données d'affichage, média et données d'affichage étant contenus dans des données de publicité téléchargées au préalable. 6. Procédé selon l'une quelconque des revendications 2 à 5, caractérisé par le fait que, lorsque ledit média sélectionné n'est pas ou est partiellement téléchargé, des données par défaut sont sélectionnées dans une base de données de publicité par défaut accessible directement par le jeu vidéo. 7. Procédé selon l'une quelconque des revendications précédentes, caractérisé par le fait que ladite étape de téléchargement est déclenchée par l'exécution d'une instruction présente dans le code informatique du jeu vidéo relatif à l'étape de chargement. 8. Procédé selon l'une quelconque des revendications précédentes, caractérisé par le fait qu'il comprend, en outre et périodiquement, une étape de calcul de l'affichage desdites données de publicité et de transmission à un serveur de traitement distant de données statistiques issues dudit calcul. 9. Procédé selon la revendication précédente, caractérisé par le fait que ladite étape de calcul consiste en une première étape d'identification d'une publicité affichée par le jeu, une étape de calcul des paramètres d'affichage de ladite publicité pour déterminer si elle est effectivement visible et une pluralité d'étapes de calcul de paramètres d'affichage de publicités qui sont associées à ladite publicité visible.10. Procédé selon la revendication précédente, caractérisé par le fait qu'il comprend, en outre, une étape d'incrémentation d'un compteur de visualisation si une même publicité est visible lors de deux étapes de calcul de l'affichage consécutives. 11. Procédé selon l'une quelconque des revendications précédentes, caractérisé par le fait que lesdites données de paramètres ou les données statistiques sont transmises par fichiers numériques binaires, fichiers balisés, fichiers XML. 12. Plateforme informatique pour la mise en oeuvre du procédé selon l'une quelconque des revendications précédentes, comprenant : - des moyens de traitement du jeu agencés pour exécuter le code informatique d'un jeu vidéo, le code informatique comprenant des instructions pour le chargement successif de modules de données comprenant des données du jeu vidéo et des données de publicité associées à ces données de jeu, - des moyens réseaux agencés pour se connecter à un serveur distant et pour télécharger, lors du chargement d'un module, des données de publicités associées aux données de jeu vidéo d'au moins un module ultérieur au module en cours de chargement. 15. Plateforme informatique selon la revendication précédente, caractérisé par le fait que lesdits moyens de traitement sont agencés, en outre, pour calculer la visibilité publicitaire durant le calcul d'une image de rendu du jeu vidéo, et pour transmettre à un serveur de traitement distant, à l'aide desdits moyens réseau, des données statistiques issues dudit calcul. 16. Plateforme informatique selon la revendication 12, caractérisé par le fait qu'il comprend, en outre : - un module de traitement Scheduler apte à traiter lesdites données de publicité téléchargées pour déterminer les données de publicité à afficher dans ledit jeu- un module de mesure agencé pour communiquer avec lesdits moyens de traitements du jeu et recevoir des paramètres d'affichage desdites données de publicité affichées et comparer lesdits paramètres à des valeurs seuils. 15. Système comprenant une pluralité de plateformes informatiques selon l'une quelconque des revendications 12 à 14, caractérisé par le fait qu'il comprend, en outre : - un serveur de publicités apte à transmettre des données de paramètre auxdites plateformes et, sur requêtes d'une plateforme, lesdites requêtes comprenant des données d'identification de données numériques de média de publicité, à transmettre à la plateforme lesdits média identifiés par les requêtes, - un serveur de traitement statistique apte à recevoir de ladite pluralité de plateformes et enregistrer des données d'affichage de publicités, et agencé pour traiter de façon asynchrone lesdites données reçues