Brevet FR2905546A1 — publié le 20080307

Arrière-plan de l'invention La présente invention se rapporte au domaine général de la diffusion d'un flux d'information dans un réseau de télécommunications, ce réseau pouvant être de tout type et notamment de type "commutation de circuits" ou "commutation de paquets". L'invention concerne plus particulièrement les technologies permettant de proposer à un utilisateur des informations liées au contenu de ce flux, ainsi qu'un choix d'actions associées à ces informations, sans perturber le flux original diffusé. Les échanges ainsi établis sont mis en place dans le cadre d'un réseau de télécommunications. Dans l'état actuel de la technique, il existe des systèmes permettant à l'utilisateur d'accéder, par exemple sur un site web, à des informations sur le contenu d'un flux diffusé, en l'occurrence une émission de télévision. En particulier, lors de la diffusion d'émissions dites de télé-réalité , le site web de l'émission offre aux spectateurs l'identité du candidat éliminé en même temps ou quasiment que celle-ci est annoncée au cours de l'émission. Les spectateurs peuvent alors se connecter sur le site web et réagir en participant à un forum de discussion, de façon synchrone ou asynchrone. Cependant, si le serveur web est effectivement mis à jour lors du déroulement de l'émission de télé-réalité, il n'est pas garanti que les informations contenues dans cette page web soient visualisées par le spectateur durant la diffusion de l'émission. Il se peut ainsi, et il est même fortement probable, que lorsque le spectateur accède à ces données d'information sur l'émission et désire réagir par l'intermédiaire d'une session de discussion (session de chat ) ou un SMS, l'émission ne soit plus diffusée et éventuellement les informations plus d'actualité. Objet et résumé de l'invention Selon un premier aspect, l'invention concerne un procédé de contrôle comportant : û une étape de détection de l'occurrence d'au moins un événement lié à 35 un flux diffusé par un serveur de diffusion ; 2905546 2 ù une étape de génération de données d'information liées à l'événement ; û une étape de vérification de l'activité du flux ; û et, si le flux est actif, une étape d'envoi des données d'information vers 5 un terminal d'un utilisateur. Corrélativement, l'invention concerne un système de contrôle comportant : û des moyens de détection de l'occurrence d'au moins un événement lié à un flux diffusé par un serveur de diffusion ; 10 û des moyens de génération de données d'information liées à l'événement ; û des moyens de vérification de l'activité du flux ; et û des moyens d'envoi des données d'information vers un terminal d'un utilisateur. 15 Au sens de l'invention les événements sont de différents types. Un événement peut en particulier être constitué par une nouvelle question dans un jeu télévisé, un événement sportif particulier ou l'élimination d'un candidat dans une émission de télé-réalité, c'est-à-dire être directement lié au contenu du flux diffusé. 20 Au sens de l'invention un événement peut aussi être lié à des éléments de contrôle du flux, par exemple pour sa diffusion (démarrage de la diffusion du flux, interruption, pause,...). L'invention ne présume pas de la façon dont on détecte les événements. Cette détection peut être humaine (action d'un technicien), 25 notamment dans le cas d'un flux diffusé en direct, ou automatique (reconnaissance d'un contenu dans le flux,...). Dans ce document l'expression données d'information désigne aussi bien des éléments à caractère informatif sur le flux diffusé, tels que par exemple des renseignements sur les acteurs lorsque ce flux est un 30 film, que des choix d'actions associées au flux, tels que la possibilité pour un utilisateur de répondre aux questions posées au candidat d'un jeu télévisé. L'invention ne présume pas de la forme que peuvent prendre ces données d'information (page Web, SMS,...). Ces procédé et système de contrôle sont donc adaptés à synchroniser une communication établie avec le terminal d'un utilisateur, 2905546 3 et un flux diffusé dans le même temps par un serveur de diffusion et susceptible d'être reçu par l'utilisateur. Cette synchronisation permet de proposer à l'utilisateur des informations de types multiples et pertinentes en rapport avec le contenu 5 sémantique ou le contrôle du flux diffusé. L'étape de vérification de l'activité du flux avant envoi des données vers l'utilisateur permet de garantir que ces informations sont bien en rapport avec un flux encore diffusé. Dans un mode particulier de réalisation de l'invention, le terminal 10 de l'utilisateur qui reçoit les données d'information est distinct de l'équipement récepteur du flux diffusé. Il peut aussi s'agir du même terminal ou équipement, mais dans ce cas les données d'information sont reçues dans un canal logique distinct de celui utilisé pour la réception du flux. 15 En particulier, un ordinateur équipé d'une carte tuner pour la réception du flux diffusé et d'une carte réseau pour la réception des données d'information peut constituer un terminal ou un équipement au sens de l'invention. Dans un mode particulier de réalisation de l'invention, afin d'établir 20 un dialogue avec l'utilisateur à propos du contenu du flux diffusé, le procédé de contrôle selon l'invention comporte : ù une étape de réception d'un message de l'utilisateur ; ù une étape de vérification que le message reçu de l'utilisateur est en relation avec les données d'information déjà envoyées ; 25 ù si tel est le cas, une étape de génération de données complémentaires d'information liées au message de l'utilisateur ; ù une étape de vérification que le flux diffusé est actif ; ù et, si le flux est actif, une étape d'envoi des données complémentaires d'information vers un terminal de l'utilisateur. 30 Dans un mode particulier de réalisation, le système de contrôle selon l'invention comporte : ù des moyens de réception d'un message de l'utilisateur ; ù des moyens de vérification que le message reçu de l'utilisateur est en relation avec les données d'information déjà envoyées ; et 35 ù des moyens de génération de données d'information complémentaires liées au message de l'utilisateur. 2905546 4 Le dialogue ainsi établi entre le système de contrôle et l'utilisateur est synchronisé et cohérent avec le contenu du flux diffusé, ceci étant garanti par les étapes de vérification de la validité du message et de l'activité du flux avant l'envoi des données complémentaires. 5 L'étape de vérification de l'activité du flux permet par ailleurs d'informer les terminaux des utilisateurs en cas de problème technique par exemple à la station d'émission, i.e., si le flux n'est plus actif. Dans un mode particulier de réalisation, le procédé de contrôle selon l'invention permet de générer une requête vers un serveur applicatif 10 en réponse à un message émanant de l'utilisateur. Ce procédé comporte : ù une étape de réception d'un message de l'utilisateur ; ù une étape de vérification que le message reçu de l'utilisateur est en relation avec les données d'information déjà envoyées ; ù si tel est le cas, une étape de génération d'une requête liée au 15 message de l'utilisateur ; ù une étape de vérification que le flux diffusé est actif ; ù et, si le flux est actif, une étape d'envoi de la requête vers un serveur applicatif. Dans un mode particulier de réalisation, le système de contrôle 20 selon l'invention comporte : ù des moyens de réception d'un message de l'utilisateur ; ù des moyens de vérification que le message reçu de l'utilisateur est en relation avec les données d'information déjà envoyées ; ù des moyens de génération d'une requête liée au message de 25 l'utilisateur ; et ù des moyens d'envoi de la requête vers un serveur applicatif, apte à traiter la requête. Ces procédé et système de contrôle permettent notamment la mise en relation de l'utilisateur avec un serveur apte à rediriger cet utilisateur 30 vers un standard téléphonique par exemple. Dans un mode particulier de réalisation de l'invention, dans lequel le flux diffusé est un flux point à point, par exemple un flux diffusé sur ADSL, le système de contrôle selon l'invention dispose également de moyens de vérifier que le flux diffusé est reçu par un équipement de 35 l'utilisateur. 2905546 5 Cette vérification permet de s'assurer que les données d'information envoyées à l'utilisateur sont bien liées à un flux non seulement diffusé vers l'utilisateur mais également reçu par lui. Dans un mode de réalisation particulier cette vérification est 5 réalisée par le système de contrôle en interrogeant le serveur de diffusion. Dans le cas d'un flux point à point, le serveur de diffusion peut s'assurer que les données sont effectivement reçues grâce au protocole d'échange mis en place avec l'équipement de l'utilisateur, par exemple le protocole TCP. 10 Cette vérification peut permettre, par exemple, de diagnostiquer une mauvaise réception du flux par l'utilisateur. Dans un mode de réalisation particulier, le système de contrôle envoie dans ce cas à l'utilisateur un message d'erreur avec éventuellement des conseils de paramétrage pour améliorer la réception du flux. 15 Dans un mode particulier de réalisation, le système de contrôle comporte des moyens de détection de l'identifiant du flux reçu par l'utilisateur. De tels moyens de détection peuvent être utilisés en amont pour identifier le flux reçu par un utilisateur et mettre en oeuvre le procédé de 20 contrôle pour ce flux au bénéfice de cet utilisateur. Selon un deuxième aspect, l'invention concerne un procédé d'information comportant : û une étape de réception d'une commande représentative de l'occurrence d'un événement lié à un flux diffusé par un serveur de 25 diffusion ; û une étape de traitement de la commande comportant une ou plusieurs sous-étapes de traitement, chaque sous-étape de traitement comportant : une étape de génération de données d'information liées à une partie au moins de la commande ; 30 une étape de vérification de l'activité du flux ; et, si le flux est actif, une étape d'envoi des données d'information vers un terminal de l'utilisateur. Corrélativement, l'invention vise également un serveur d'information comportant : 2905546 6 ù des moyens de réception d'une commande représentative de l'occurrence d'un événement lié à un flux diffusé par un serveur de diffusion ; ù des moyens de génération de données d'information liées à la 5 commande reçue ; ù des moyens de vérification de l'activité du flux ; et ù des moyens d'envoi des données d'information générées vers un terminal d'un utilisateur. Dans ce document on entend par commande tout type 10 d'instruction permettant de déclencher une action du dispositif qui la reçoit. Ainsi une commande peut notamment être contenue dans un paquet de données, une trame ou un fichier informatique. Préférentiellement, les moyens d'envoi des données d'information vers un utilisateur sont aptes à envoyer les données d'information sous la 15 forme d'une page Web. Selon un mode particulier de réalisation de l'invention, les moyens de génération génèrent les données d'information en utilisant des préférences de l'utilisateur. Ceci permet notamment de sélectionner ou de filtrer les informations à envoyer à destination de l'utilisateur en fonction 20 de ses attentes. Dans un mode particulier de réalisation, le procédé d'information selon l'invention comporte : ù une étape de réception d'un message de l'utilisateur ; ù une étape de vérification que le message reçu de l'utilisateur est en 25 relation avec les données d'information déjà envoyées ; ù si tel est le cas, une étape de génération de données complémentaires d'information liées au message de l'utilisateur ; ù une étape de vérification que le flux diffusé est actif ; ù et, si le flux est actif, une étape d'envoi des données complémentaires 30 d'information vers un terminal de l'utilisateur. Corrélativement, dans un mode particulier de réalisation le serveur d'information comporte : ù des moyens de réception d'un message de l'utilisateur ; ù des moyens de vérification que le message reçu de l'utilisateur est en 35 relation avec les données d'information déjà envoyées ; 2905546 7 ù des moyens de génération de données complémentaires d'information liées au message de l'utilisateur. Dans un mode particulier de réalisation de l'invention, le procédé d'information selon l'invention permet de générer une requête vers un 5 serveur applicatif en réponse à un message de l'utilisateur. Ce procédé comporte : ù une étape de réception d'un message de l'utilisateur ; ù une étape de vérification que le message reçu de l'utilisateur est en relation avec les données d'information déjà envoyées ; 10 ù si tel est le cas, une étape de génération d'une requête liée au message de l'utilisateur ; ù une étape de vérification que le flux diffusé est actif ; ù et, si le flux est actif, une étape d'envoi de la requête vers un serveur applicatif apte à traiter la requête. 15 Corrélativement, le serveur d'information comporte, dans un mode particulier de réalisation : ù des moyens de réception d'un message de l'utilisateur ; ù des moyens de vérification que le message reçu de l'utilisateur est en relation avec les données d'information déjà envoyées ; 20 ù des moyens de génération d'une requête liée au message de l'utilisateur; et ù des moyens d'envoi de la requête vers un serveur applicatif, apte à traiter la requête. Dans un mode particulier de réalisation de l'invention, dans lequel 25 le flux diffusé est un flux point à point, par exemple un flux diffusé sur ADSL, le serveur d'information selon l'invention dispose également de moyens de vérifier que le flux diffusé est reçu par un équipement de l'utilisateur. Dans un mode de réalisation particulier cette vérification est 30 réalisée par le serveur d'information en interrogeant le serveur de diffusion. Les caractéristiques particulières et les avantages de tels serveur et procédé d'information sont identiques à ceux proposés par les système et procédé de contrôle précédemment décrits. 35 Selon un troisième aspect, l'invention concerne un procédé de gestion d'événements comportant : 2905546 8 ù une étape de détection de l'occurrence d'au moins un événement lié à un flux diffusé par un serveur de diffusion ; û une étape de génération d'une commande liée à cet événement ; - une étape de vérification de l'activité du flux ; 5 û et, si le flux est actif une étape d'envoi de la commande vers un serveur d'information. Corrélativement, l'invention vise également un serveur de gestion d'événements comportant : ù des moyens de détection de l'occurrence d'au moins un événement lié 10 à un flux diffusé par un serveur de diffusion ; û des moyens de génération d'une commande liée à l'événement ; - des moyens de vérification de l'activité du flux ; et - des moyens d'envoi de la commande vers un serveur d'information. Préférentiellement, les moyens de génération de la commande sont 15 aptes à inclure cette commande dans un fichier informatique conforme à un standard de langage à balises, préférentiellement XML. Ces procédé et serveur sont donc adaptés à détecter un événement associé à la diffusion du flux, par exemple le démarrage de la diffusion du flux ou chaque question posée à un candidat lors de la diffusion d'un jeu 20 télévisé. Une commande à destination du serveur d'information telle que mentionnée ci-dessus pourra ainsi contenir par exemple un identifiant (par exemple son nom) de la commande ainsi que le moment auquel elle doit être traitée. 25 Dans un mode particulier de réalisation de l'invention, cette commande peut être constituée d'une action à réaliser en association avec chaque couple (identifiant de la commande, moment de traitement de la commande). Dans un autre mode particulier de réalisation de l'invention, cette 30 commande peut se présenter sous la forme d'un fichier informatique, d'une trame ou d'un paquet de données contenant plusieurs couples (identifiant de la commande, moment de traitement de la commande), découlant de l'événement détecté par le serveur de gestion d'événements. Chaque couple de cette commande sera désigné par le terme de 35 commande élémentaire dans ce document. Ainsi une commande 2905546 9 désignera indifféremment une commande élémentaire ou un ensemble de commandes élémentaires. Une commande peut ainsi par exemple contenir l'ensemble de toutes les commandes élémentaires relatives à un flux diffusé en différé, 5 car parfaitement déterminées au moment de la diffusion du flux. Dans un mode particulier de réalisation de l'invention, le serveur de gestion d'événements est co-localisé avec le serveur de diffusion. Selon un mode particulier de réalisation de l'invention, le système de contrôle comporte au moins un serveur d'information et au moins un 10 serveur de gestion d'événements tels que décrits brièvement précédemment, synchronisés entre eux par l'intermédiaire d'un serveur NTP (Network Time Protocol). Cette synchronisation réseau permet au serveur d'information d'interpréter convenablement les commandes envoyées par le serveur de 15 gestion d'événements, notamment les éléments concernant les moments de traitement des commandes liées aux événements du flux diffusé. Selon une implémentation particulière de l'invention, les différentes étapes du procédé de gestion des événements et/ou du procédé d'information sont déterminées par des instructions de programmes 20 d'ordinateur. En conséquence l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre d'un procédé de gestion des événements 25 et/ou d'un procédé d'information. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée ou dans n'importe quelle autre forme 30 souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou 35 dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD 2905546 10 ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support 5 transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit 10 intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Brève description des dessins 15 D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux annexes et aux dessins qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif, et dans lesquels : û l'annexe 1 est un exemple de fichier informatique au format XML 20 pouvant être généré, lorsque le flux est diffusé en différé, par un procédé ou un serveur de gestion d'événements conformes à l'invention, dans un mode particulier de réalisation ; û l'annexe 2 est un de fichier informatique au format XML pouvant être généré, lorsque le flux est diffusé en direct, par un procédé ou un 25 serveur de gestion d'événements conformes à l'invention, dans un mode particulier de réalisation ; û la figure 1 représente un système de contrôle conforme à l'invention dans un mode particulier de réalisation ; û la figure 2 représente, sous forme d'organigramme, les principales 30 étapes d'un procédé d'information conforme à l'invention dans un mode particulier de réalisation ; et û la figure 3 représente, sous forme d'organigramme, les principales étapes d'un procédé de gestion d'événements conforme à l'invention dans un mode particulier de réalisation. 35 2905546 11 Description détaillée d'un mode de réalisation La description qui va suivre est faite dans le contexte de la diffusion d'un flux vidéo, à savoir la diffusion d'un jeu télévisé pendant lequel un candidat se voit poser une liste de questions. 5 Dans ce mode particulier de réalisation, l'invention vise à proposer à un utilisateur récepteur de ce flux, des données d'information sur le contenu de ce flux vidéo et à lui permettre de réagir sur ces données d'information. Les données d'information envoyées vers l'utilisateur sont 10 synchronisées avec le déroulement du flux et générées en relation avec des événements particuliers liés au contenu ou au contrôle du flux vidéo. Dans l'exemple décrit ici, ces données d'information seront présentées sous la forme d'une page Web. Afin de proposer ce service à l'utilisateur, il est nécessaire en amont 15 de collecter certaines données préliminaires afin de permettre ces échanges. Cela consiste notamment, pour chaque flux, à û identifier le serveur de diffusion du flux ; û identifier les événements et les commandes associées (identifiant et moment de traitement de chaque commande élémentaire) contenus dans 20 le flux susceptibles de générer un échange avec l'utilisateur et enregistrer ces événements et les commandes associées dans un fichier informatique L associé au flux. Ce fichier informatique, conforme au standard XML dans ce mode particulier de réalisation, peut être écrit directement ou rempli à partir d'une interface graphique plus ergonomique, classiquement des 25 pages d'administration web ; û associer à chaque commande élémentaire une action appropriée qui permettra d'identifier les données d'information à envoyer vers l'utilisateur en relation avec cette commande élémentaire. Dans l'exemple décrit ici, cette correspondance est contenue dans une base de données relative à 30 l'émission. Dans une variante, elle peut être incluse dans le fichier XML généré ci-dessus ; et û générer les pages ou les morceaux de pages Web qui seront affichées sur le terminal de l'utilisateur. Certaines données d'information étant générées au fil de l'émission (par exemple, dans le cas d'une émission 35 diffusée en direct où il n'existe aucune connaissance a priori de ces 2905546 12 données d'information), ces pages Web pourront être mises à jour au cours de la diffusion du flux vidéo. Cette étape préliminaire peut être effectuée indifféremment par celui qui diffuse le flux vidéo ou par un tiers. 5 Par ailleurs, dans le mode particulier de réalisation de l'invention décrit ici, les préférences de l'utilisateur sont prises en compte de manière à lui proposer des données d'information et des échanges plus pertinents par rapport à ses attentes. Ces données de personnalisation sont stockées dans un profil client 10 d'une base de données. Pour rentrer ses données de personnalisation dans le système, l'utilisateur utilise un support (par exemple un navigateur Internet) se trouvant sur le terminal lui permettant de recevoir les données d'information. 15 Dans le cas d'un navigateur Web, l'utilisateur se connecte sur un site particulier avec un mode classique de sécurité (par exemple nom d'utilisateur / mot de passe ou authentification utilisant la cryptographie) et se voit proposer plusieurs actions dont : ù choisir les chaînes de télévision sur lesquelles il souhaiterait recevoir 20 les données d'information, par exemple les chaînes auxquelles il est abonné; ù sélectionner un ou plusieurs types de données d'information et d'actions (par exemple, l'utilisateur peut enregistrer dans son profil qu'il ne souhaite pas participer aux tirages au sort) ; et 25 ù donner des informations sur ses préférences générales, de manière à filtrer les données d'informations qui lui seront envoyées. Cette liste d'actions n'est en aucun cas exhaustive. Par ailleurs, l'utilisateur peut modifier son profil client en cours d'utilisation du service. Ainsi, avant même la diffusion du flux, les informations suivantes 30 sont disponibles dans différentes bases de données : ù correspondance entre l'identifiant d'un flux donné et l'identifiant du serveur de diffusion du flux ; ù correspondance entre une commande et les actions requises pour générer les données d'information ; et 35 ù profil client. 2905546 13 Dans une variante de réalisation, les informations précédentes sont disponibles dans une unique base de données. Ces informations sont destinées à être utilisées au cours des différentes étapes des procédés constituant l'invention. 5 La figure 1 représente, dans son environnement, un système de contrôle 40 conforme à l'invention. Ce système de contrôle 40 communique : û d'une part, avec un serveur de diffusion 10, diffusant un flux F vers un équipement 60 d'un utilisateur adapté à recevoir le flux F, cet équipement 10 étant dans cet exemple un téléviseur dans le cas d'un flux vidéo F ; û d'autre part, avec un autre terminal 70 de ce même utilisateur, adapté à recevoir des flux de données d'information, cet équipement pouvant être notamment un assistant personnel PDA (Persona) Digital Assistant), un ordinateur ou un terminal mobile bi mode de type UMTS (Universal Mobile 15 Terrestrial System) / WLAN (Wireless Local Area Network). Dans l'exemple décrit ici, l'acheminement de ces deux flux d'information vers l'équipement 60 et le terminal 70 s'effectue par l'intermédiaire d'une passerelle résidentielle 50. Les deux flux sont transportés par deux canaux logiques différents. 20 Dans l'exemple décrit ici, le système de contrôle 40 comporte un serveur de gestion d'événements 20 et un serveur d'information 30, communiquant entre eux. Dans le mode particulier de réalisation décrit ici, le serveur de gestion d'événements 20 n'est pas co-localisé avec le serveur de diffusion 25 10. La correspondance entre le serveur de gestion d'événements 20 et le serveur de diffusion 10 doit être établie en amont du procédé mis en oeuvre par le système de contrôle 40 décrit dans l'invention et stockée dans une base de données 37 relative à l'émission. En variante, le serveur de gestion d'événements 20 et le serveur de 30 diffusion 10 peuvent être co-localisés. Le serveur de gestion d'événements 20 a l'architecture matérielle d'un ordinateur. Il comporte un processeur 23, une mémoire morte 21, une mémoire vive 22, des moyens de communication 24 avec le serveur de diffusion 10 ainsi que des moyens de communication 25 avec le 35 serveur d'information 30. 2905546 14 La mémoire morte 21 du serveur de gestion d'événements 20 décrit ici comporte un programme informatique adapté à exécuter les principales étapes du procédé de gestion d'événements selon l'invention, ces principales étapes étant représentées sous la forme d'un organigramme 5 sur la figure 3 décrite ultérieurement. Le serveur de gestion d'événements 20 comporte également un disque dur 26 dans lequel est stocké le fichier informatique L. Le serveur d'information 30 a l'architecture matérielle d'un ordinateur. Il comporte un processeur 33, une mémoire morte 31, une 10 mémoire vive 32, des moyens de communication 34 avec le serveur de gestion d'événements 20 et des moyens de communication 35 avec le terminal de l'utilisateur 70 ouavec un serveur applicatif (typiquement une carte réseau) non représenté sur la figure. La mémoire morte 31 du serveur d'information 30 décrit ici 15 comporte un programme informatique adapté à exécuter les principales étapes du procédé d'information selon l'invention, ces principales étapes étant représentées sous la forme d'un organigramme sur la figure 2 décrite ultérieurement. Le serveur d'information 30 dispose également d'une interface lui 20 permettant d'interroger les bases de données 36 et 37, qui contiennent respectivement, les données relatives au profil de l'utilisateur et les données relatives à l'émission, générées comme décrit précédemment. Afin de communiquer avec le serveur de gestion d'événements 20, le serveur d'information 30 s'abonne auprès du serveur de gestion 25 d'événements 20 pour recevoir les commandes relatives aux événements du flux F ou de l'émission F diffusée par le serveur de diffusion 10. Les principales étapes menant à ce processus d'abonnement sont décrites maintenant en référence à la figure 2 (étapes F10 à F24). Dans l'exemple décrit, l'utilisateur utilise un assistant personnel 30 (PDA) comme terminal 70 afin d'accéder aux informations sur l'émission diffusée F. Lorsque l'utilisateur allume son PDA 70, il lance une application nommée TV interactive , par le biais de laquelle il envoie une requête d'accès pour se connecter au serveur d'information 30 via Internet. 2905546 15 Suite à la réception de cette requête d'accès à l'étape F10, le serveur d'information 30 récupère dans une base de données 36 le profil client de l'utilisateur au cours d'une étape F12. Dans ce profil client, comme décrit précédemment, l'utilisateur a 5 défini les chaînes de télévision auxquelles il est abonné. Au cours d'une étape F14, le serveur d'information 30 interroge un serveur distant, non représenté sur la figure 1, pour connaître la liste des flux diffusés sur les chaînes auxquelles l'utilisateur est abonné. A l'étape F16, il envoie à l'utilisateur la liste des émissions qui sont reçues alors sur 10 sa télévision. L'utilisateur sélectionne une émission, associée à un identifiant unique, cet identifiant étant alors envoyé vers le serveur d'information 30. Dans un mode particulier de réalisation, dans lequel le flux diffusé est un flux point à point, par exemple un flux diffusé sur ADSL, le serveur 15 d'information 30 est adapté à détecter quel flux l'utilisateur reçoit, en interrogeant le serveur de diffusion 10. De tels moyens de détection peuvent ainsi permettre au serveur d'information 30 de déterminer l'identifiant du flux F et de s'affranchir de l'étape F16. La réception de cet identifiant au cours d'une étape F18 permet au 20 serveur d'information 30 durant une étape F20 d'interroger une base de données 37 dans laquelle se trouve la correspondance entre l'identifiant de l'émission F et l'identifiant du serveur de gestion d'événements 20 qui lui est associé. Une fois le serveur de gestion d'événements 20 identifié, le serveur 25 d'information 30 peut s'abonner auprès de celui-ci au cours d'une étape F22 afin d'accéder aux données liées aux événements de l'émission. Le serveur d'information 30 se positionne alors dans une phase d'attente F31 d'une commande C provenant du serveur de gestion d'événements 20. 30 Les principales étapes menant à la génération d'une commande C par le serveur de gestion d'événements 20 sont maintenant décrites en référence à la figure 3. Après avoir reçu la demande d'abonnement du serveur d'information 30 lors d'une étape [10, le serveur de gestion d'événements 35 20 lit le fichier informatique L localisé dans le disque dur 26 et contenant 2905546 16 la liste de l'ensemble des événements et commandes associées relatifs à l'émission au cours d'une étape [12. Suite à une étape E14 de détection d'un événement EV, qui peut être l'oeuvre d'un technicien par exemple, le serveur de gestion 5 d'événements 20 génère des informations relatives à l'événement sous la forme d'une ou de plusieurs (N) commandes élémentaires au cours d'une étape [16. Ces N commandes élémentaires peuvent être contenues dans un même fichier informatique ou une même trame ou un même paquet de données. 10 Pour une émission diffusée en différé, l'envoi de plusieurs commandes élémentaires sous la forme d'un fichier, par exemple conforme au standard XML, est approprié car la totalité du contenu du flux diffusé est connue. Les commandes élémentaires associées aux différents événements du flux diffusé peuvent alors être compilées dans un unique 15 fichier. L'événement EV déclencheur de l'envoi de ce fichier de commandes élémentaires est alors par exemple la réception, par le serveur de gestion d'événements 20, d'un signal (non représenté sur la figure 1) représentatif du début de la diffusion de l'émission. 20 L'annexe 1 donne un exemple de fichier informatique conforme au standard XML contenant la liste des N=2 commandes élémentaires associées à un jeu télévisé Qui veut gagner des sous ? diffusé en différé sur la chaîne francetv . Ces commandes élémentaires sont classées par ordre d'occurrence. Pour cette diffusion en différé, l'heure de 25 début (respectivement de fin) de diffusion du flux F est délimitée par les balises et (respectivement et ). Dans un mode particulier de réalisation de l'invention, les heures de début et de fin d'émission sont mises à jour en fonction de l'heure réelle de début de diffusion. 30 Dans le mode particulier de réalisation de l'invention décrit ici, l'événement EV reçu par le serveur de gestion d'événements correspond au début de la diffusion du jeu télévisé. Les différentes commandes élémentaires résultant de cet événement sont associées aux différentes questions posées au candidat. 35 L'utilisateur se voit ainsi poser les mêmes questions que le candidat sous 2905546 17 forme de QCM (Questions à Choix Multiples), sensiblement au moment où la question est posée au candidat pendant l'émission. Chaque commande élémentaire associée à chaque question est délimitée par les balises et . Dans chaque commande se 5 trouvent û l'identifiant de la commande (délimité par les balises et ), ici Question_xx où xx est le numéro de la question en cours ; û le moment de traitement de la commande (délimité par les balises 10 et ) ; û ainsi qu'éventuellement d'une action associée à cet événement (par exemple téléchargement d'une page Web,...). Le moment de traitement de la commande élémentaire est donnée en secondes à partir de l'heure de début de diffusion, c'est-à-dire dans 15 l'exemple décrit en annexe 1, 312 secondes après 17h50. La synchronisation entre le serveur de gestion d'événements 20, émetteur des commandes, et le serveur d'information 30, récepteur de ces commandes, doit donc être garantie afin que les commandes soient bien interprétées par le serveur d'information 30, notamment en ce qui 20 concerne les moments de traitement. Dans le mode particulier de réalisation de l'invention décrit ici, la synchronisation entre ces deux serveurs est une synchronisation de type réseau (serveur NTP 80), qui garantit que le temps défini par un des serveurs est bien compris par l'autre. 25 Alternativement l'action associée à chaque commande élémentaire peut être définie dans une base de données que le serveur d'information 30 ira interroger sur réception de la commande. Ainsi dans l'exemple décrit dans l'annexe 1, aucune action n'est associée aux différentes commandes élémentaires dans le fichier de commandes. 30 Dans le cas d'une émission diffusée en direct, les commandes sont préférentiellement envoyées progressivement, c'est-à-dire une par une, au moment opportun (décidé par un technicien mais a priori non prévisible avant le début de l'émission) sur détection de l'événement associé avec comme instruction de temps l'instruction now . 35 Dans ce cas chaque commande est constituée d'une seule commande élémentaire. 2905546 18 Un exemple de fichier XML de commandes dans le cas d'une émission diffusée en direct est présenté en annexe 2. Il contient une seule commande élémentaire et les mêmes informations que le fichier XML donné en exemple en annexe 1 pour une émission diffusée en 5 différé, à l'exception des données de temps. L'heure de démarrage de l'émission (délimitée par les balises et ) est mise à jour en fonction de l'heure réelle de début de diffusion de l'émission par le serveur de diffusion 10. L'heure de fin d'émission n'est pas précisée car généralement non 10 connue dans le cas d'une émission diffusée en direct. Avant d'envoyer le fichier de commandes élémentaires vers le serveur d'information 30, le serveur de gestion d'événements 20 est en charge de vérifier que le flux F est toujours diffusé au cours d'une étape [18. 15 Si tel est le cas, le fichier de commandes est envoyé à destination du serveur d'information 30 lors d'une étape [22. Sinon le serveur d'information 30 se voit notifier au cours d'une étape E20 l'absence de diffusion du flux F. La vérification de l'activité du flux F peut se faire de différentes 20 manières, l'une n'excluant pas l'autre : ù de manière périodique : le serveur de gestion d'événements 20 communique avec le serveur de diffusion 10 régulièrement et à des intervalles de temps rapprochés (par exemple toutes les secondes) pour connaître l'état de la diffusion du flux F ; 25 ù de manière ponctuelle : si les intervalles de temps sont suffisamment rapprochés, le serveur de gestion d'événements 20 peut stocker une variable d'état traduisant l'activité ou non du flux F et mise à jour à chaque période de la vérification. Avant l'envoi de la commande C vers le serveur d'information 30, le 30 serveur de gestion d'événements 20 contrôle l'état de cette variable. Après envoi des données vers le serveur d'information 30 au cours de l'étape [22, le serveur de gestion d'événements 20 repasse en mode d'attente de détection d'un nouvel événement à l'étape [24. Le procédé d'information est implémenté sous la forme d'un 35 programme informatique comportant trois processus (F24) : la gestion d'une commande C issue du serveur de gestion d'événements 20 au cours 2905546 19 de l'ensemble des étapes regroupées dans F30, la gestion d'une commande élémentaire reliée au flux F au cours de l'ensemble des étapes regroupées dans F40 et la gestion d'une réponse de l'utilisateur 70 au cours de l'ensemble des étapes regroupées dans F50. 5 Dans une étape F31, le serveur d'information 30 est en attente d'une commande C (fichier, trame ou paquet) envoyé par le serveur de gestion d'événements 20. Dans l'exemple décrit ici, la commande C est incluse dans un fichier informatique conforme au format XML. 10 Après réception d'un tel fichier, le serveur d'information 30 procède à une étape F32 de lecture de ce fichier et met à jour sa liste de commandes élémentaires lors d'une étape F33. Cette liste énumère les différentes commandes élémentaires contenues dans la commande C. Le serveur d'information 30 quitte alors un état d'attente F41 d'une 15 commande pour traiter séparément et successivement les différentes commandes élémentaires de la liste dans l'ordre de leurs occurrences au cours d'une étape F42. Le traitement effectué consiste à ù interpréter la commande élémentaire ; 20 ù aller chercher dans les bases de données 36 (respectivement 37) les informations relatives au profil de l'utilisateur (respectivement relatives à l'émission, c'est-à-dire les actions associées à chaque événement) ; ù aller chercher éventuellement sur d'autres serveurs, non représentés sur la figure 1, des informations supplémentaires (par exemple des 25 statistiques sur les réponses des candidats,...) ; ù faire le croisement des informations récoltées pour générer les données d'information PW qui seront envoyées à l'utilisateur. Dans l'exemple décrit ici, les données d'information PW ainsi générées sont contenues dans une page Web. Ces données d'information 30 représentent la question posée au candidat. En variante, il peut également s'agir d'un choix d'actions offert à l'utilisateur (par exemple, visite du site web du jeu, participation à un forum de discussion avec les gagnants précédents du jeu télévisé...). Avant d'envoyer les données d'information PW ainsi générées, le 35 serveur d'information effectue une étape de vérification F43 de l'activité du flux. 2905546 20 Cette étape peut se dérouler selon les deux modes suivants, proposés à titre d'exemples : û le serveur d'information 30 interroge le serveur de gestion d'événements 20 sur l'activité du flux F ; 5 û le serveur de gestion d'événements 20 envoie régulièrement et à des intervalles de temps rapprochés l'état du flux ( diffusé ou non diffusé ) au serveur d'information 30. Ceci permet la mise à jour d'une variable représentative de cet état et stockée au niveau du serveur d'information 30. Lors de la vérification F43, le serveur d'information 10 accède à cette variable et peut alors se prononcer sur l'activité du flux. Si le résultat du test F43 n'est pas positif, alors il s'ensuit une étape F44 de gestion de la non activité du flux. Il peut s'agir par exemple d'envoyer un message à l'utilisateur pour lui mentionner que ce flux n'est plus diffusé. 15 Si le résultat du test F43 est positif alors les données d'information PW sont envoyées vers le terminal 70 de l'utilisateur au cours d'une étape F45. Dans l'exemple décrit ici, les étapes F43 de vérification du flux et F45 d'envoi des données d'information PW vers le terminal 70 sont 20 réalisées pour chaque commande élémentaire séparément, suite au traitement de la commande élémentaire correspondante effectué à l'étape F42. Le serveur d'information 30 est adapté également à gérer les messages M provenant de l'utilisateur 70. Ainsi lorsqu'une commande a 25 été traitée, le serveur d'information 30 est apte à recevoir une réponse aux données d'information déjà envoyées (étape F51). Dans l'exemple décrit ici, cette réponse peut être la sélection d'une réponse parmi le choix de réponses offert à l'utilisateur dans le cadre d'un QCM. 30 Lorsqu'un message M parvient au serveur d'information 30 en provenance de l'utilisateur 70, il est nécessaire d'identifier si ce message est valide au cours d'une étape F52, c'est-à-dire, si il est bien en relation avec les données d'information déjà envoyées à l'utilisateur et cohérent avec ces données. 2905546 21 Pour cela il est nécessaire que le message M comporte un identifiant de la commande ou des données d'informations auxquelles il se rapporte. Si le message M est valide, il est alors traité par le serveur 5 d'information 30 lors d'une étape F53 et peut conduire à la génération de données complémentaires d'information DCI. Le traitement de ce message peut également conduire à la génération d'une requête vers un serveur applicatif, non représenté sur la figure 1, apte à traiter cette requête. Ainsi si le message M de l'utilisateur 10 contient une demande de mise en relation avec un standard téléphonique, le serveur d'information peut générer au cours de l'étape F53 une requête d'accès à un serveur apte à rediriger l'utilisateur vers ce standard téléphonique. L'établissement de la communication peut alors se faire selon le 15 procédé décrit dans le document RFC3725, Best Current Practices for Third Party Cali Control in the Session Initiation Protocol (vww.ietf,ors. rfc. rfc3725.txt). Si le message M n'est pas considéré comme valide, alors une étape F54 de gestion de l'erreur est mise en oeuvre. Il peut s'agir tout 20 simplement de décider de ne pas traiter le message M car pas en relation avec les données d'information déjà envoyées. Avant d'envoyer les données d'information complémentaires vers l'utilisateur ou une requête vers un serveur applicatif, une nouvelle vérification est effectuée à l'étape F55 afin de contrôler que le flux est 25 actif. Cette vérification peut se faire selon les procédés décrits précédemment. Si le flux est actif, alors les données complémentaires d'information sont envoyées à l'utilisateur lors d'une étape F56 ou la requête au serveur applicatif lors d'une étape F57. 30 Le serveur d'information passe alors de nouveau dans un mode d'attente d'une commande (F31), d'un événement (F41) ou d'un message de l'utilisateur 70 (F51). 2905546 22 ANNEXE 1 5 mlkjgkfj89875689794 francetv.emissions Qui veut gagner des 10 sous? interactive-server.domain.com recorded 15 Feb 3 2006, GMT+1 17h50:00 Feb 3 2006, GMT+1 18h20:00 20 Question_1 312 25 Question_2 1036 30 2905546 23 ANNEXE 2 mlkjgkfj89875689794 5 francetv.emissions Qui veut gagner des sous? 10 interactive-server.domain.com direct Feb 3 2006, GMT+1 17h52:00 15 Question_1 now 20 REVENDICATIONS 1. Système de contrôle (40) comportant, ù des moyens de détection (20) de l'occurrence d'au moins un événement (EV) lié à un flux (F) diffusé par un serveur de diffusion (10); ù des moyens de génération (30) de données d'information (PW) liées audit événement (EV) ; ù des moyens de vérification (20,30) de l'activité dudit flux ; et ù des moyens d'envoi (30) desdites données d'information (PW) vers un terminal (70) d'un utilisateur. 2. Système selon la revendication 1 comportant, - des moyens de réception (30) d'un message (M) dudit utilisateur ; ù des moyens de vérification (30) que ledit message (M) reçu dudit utilisateur est en relation avec les données d'information (PW) déjà envoyées ; et ù des moyens de génération (30) de données complémentaires d'information (DCI) liées audit message (M) dudit utilisateur. 3. Système selon la revendication 1 comportant, - des moyens de réception (30) d'un message (M) dudit utilisateur ; ù des moyens de vérification (30) que ledit message (M) reçu dudit utilisateur est en relation avec les données d'information (PW) déjà envoyées; ù des moyens de génération (30) d'une requête liée audit message (M) dudit utilisateur ; et ù des moyens d'envoi (30) de ladite requête vers un serveur applicatif apte à traiter ladite requête. 4. Système selon l'une quelconque des revendications 1 à 3 dans lequel ledit flux (F) est un flux point à point, comportant en outre des moyens de vérification (40,50) que ledit flux est reçu par un équipement (60) dudit utilisateur. 5. Procédé de contrôle comportant, 2905546 25 ù une étape ([14) de détection de l'occurrence d'au moins un événement (EV) lié à un flux diffusé (F) par un serveur de diffusion (10); ù une étape (F42) de génération de données d'information (PW) liées audit événement (EV) ; 5 ù une étape de vérification (F43, [18) de l'activité dudit flux (F) ; ù et, si ledit flux (F) est actif, une étape (F45) d'envoi desdites données d'information (PW) vers un terminal (70) d'un utilisateur. 6. Procédé de contrôle selon la revendication 5 comportant, 10 ù une étape (F51) de réception d'un message (M) dudit utilisateur ; ù une étape (F52) de vérification que ledit message (M) reçu dudit utilisateur est en relation avec les données d'information (PW) déjà envoyées; ù si tel est le cas, une étape (F53) de génération de données 15 complémentaires d'information (DCI) liées audit message (M) dudit utilisateur ; ù une étape de vérification (F55) que ledit flux (F) est actif ; ù et, si le flux est actif, une étape (F56) d'envoi desdites données complémentaires d'information (DCI) vers un terminal (70) dudit 20 utilisateur. 7. Procédé de contrôle selon la revendication 5 comportant, - une étape (F51) de réception d'un message (M) dudit utilisateur ; ù une étape (F52) de vérification que ledit message (M) reçu dudit 25 utilisateur est en relation avec les données d'information (PW) déjà envoyées; ù si tel est le cas, une étape (F53) de génération d'une requête liée audit message (M) dudit utilisateur ; ù une étape de vérification (F55) que ledit flux (F) est actif ; et 30 ù une étape (F57) d'envoi de ladite requête vers un serveur applicatif. 8. Serveur d'information (30) comportant, ù des moyens de réception (34) d'une commande (C) représentative de l'occurrence d'un événement (EV) lié à un flux (F) diffusé par un serveur 35 de diffusion (10) ; 2905546 26 ù des moyens de génération (33) de données d'information (PW) liées à ladite commande (C) ; ù des moyens de vérification (33) de l'activité dudit flux ; et ù des moyens d'envoi (35) desdites données d'information (PW) vers un 5 terminal (70) d'un utilisateur. 9. Serveur d'information (30) selon la revendication 8 comportant, ù des moyens de réception (35) d'un message (M) dudit utilisateur ; 10 ù des moyens de vérification (33) que ledit message (M) reçu dudit utilisateur est en relation avec les données d'information (PW) déjà envoyées ; et ù des moyens de génération (33) de données complémentaires d'information (DCI) liées audit message (M) dudit utilisateur. 15 10. Serveur d'information (30) selon la revendication 8 comportant, ù des moyens de réception (35) d'un message (M) dudit utilisateur ; ù des moyens de vérification (33) que ledit message (M) reçu dudit 20 utilisateur est en relation avec les données d'information (PW) déjà envoyées; ù des moyens de génération (33) d'une requête liée audit message (M) dudit utilisateur ; et ù des moyens d'envoi (35) de ladite requête vers un serveur applicatif 25 apte à traiter ladite requête. 11. Serveur d'information (30) selon l'une quelconque des revendications 8 à 10, caractérisé en ce que lesdits moyens de génération (33) génèrent lesdites données d'information (PW) en utilisant des 30 préférences dudit utilisateur. 12. Serveur d'information (30) selon l'une quelconque des revendications 8 à 11, caractérisé en ce que lesdits moyens d'envoi (35) desdites données d'information (PW) sont aptes à envoyer lesdites 35 données d'information (PW) sous la forme d'une page Web vers ledit terminal (70) dudit utilisateur. 2905546 27 13. Serveur selon l'une quelconque des revendications 8 à 12, dans lequel ledit flux (F) est un flux point à point, comportant en outre des moyens de vérification (33) que ledit flux est reçu par un équipement 5 (60) dudit utilisateur. 14. Procédé d'information comportant, ù une étape (F31,F41) de réception d'une commande (C) représentative de l'occurrence d'un événement (EV) lié à un flux (F) diffusé par un 10 serveur de diffusion (10) ; ù une étape (F40) de traitement de la commande comportant une ou plusieurs sous-étapes de traitement (F42), chaque sous-étape de traitement comportant : ù une étape (F42) de génération de données d'information (PW) 15 liées à une partie au moins de ladite commande (C) ; ù une étape (F43) de vérification de l'activité dudit flux ; ù et, si ledit flux est actif, une étape (F45) d'envoi desdites données d'information (PW) vers un terminal dudit utilisateur. 20 15. Procédé d'information selon la revendication 14 comportant, ù une étape (F51) de réception d'un message (M) dudit utilisateur ; ù une étape (F52) de vérification que ledit message (M) reçu dudit utilisateur est en relation avec les données d'information (PW) déjà 25 envoyées; ù si tel est le cas, une étape (F53) de génération de données complémentaires d'information (DCI) liées audit message (M) dudit utilisateur ; ù une étape de vérification (F55) que ledit flux (F) est actif ; 30 ù et, si le flux (F) est actif, une étape (F56) d'envoi desdites données complémentaires d'information (DCI) vers un terminal (70) dudit utilisateur. 35 16. Procédé d'information selon la revendication 14 comportant, 2905546 28 - une étape (F51) de réception d'un message (M) dudit utilisateur ; ù une étape (F52) de vérification que ledit message (M) reçu dudit utilisateur est en relation avec les données d'information (PW) déjà envoyées; 5 ù si tel est le cas, une étape (F53) de génération d'une requête liée audit message (M) dudit utilisateur ; ù une étape de vérification (F55) que ledit flux (F) est actif ; ù et, si le flux (F) est actif, une étape (F57) d'envoi de ladite requête vers un serveur applicatif apte à traiter ladite requête. 10 17. Programme d'ordinateur sur un support d'information, ledit programme étant susceptible d'être mis en oeuvre par un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre d'un procédé d'information selon l'une quelconque des revendications 14 à 16. 18. Support d'enregistrement lisible par un ordinateur (30) sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé d'information selon l'une quelconque des revendications 14 à 16. 20 19. Serveur de gestion d'événements (20) comportant, ù des moyens (24) de détection de l'occurrence d'au moins un événement (EV) lié à un flux (F) diffusé par un serveur de diffusion (10) ; ù des moyens (23) de génération d'une commande (C) liée audit 25 événement (EV) ; ù des moyens (23,24) de vérification de l'activité dudit flux (F) ; et ù des moyens (25) d'envoi de la commande (C) vers un serveur d'information (30). 30 20. Serveur selon la revendication 19 caractérisé en ce que lesdits moyens (23) de génération de ladite commande (C) sont aptes à inclure ladite commande (C) dans un fichier informatique conforme au standard XML. 15 35 21. Procédé de gestion d'événements comportant, 2905546 29 ù une étape ([14) de détection de l'occurrence d'au moins un événement (EV) lié à un flux diffusé (F) par un serveur de diffusion (10) ; ù une étape ([16) de génération d'une commande (C) liée audit événement (EV) ; 5 ù une étape ([18) de vérification de l'activité dudit flux (F) ; ù et, si ledit flux (F) est actif, une étape ([22) d'envoi de la commande (C) vers un serveur d'information (30). 22. Programme d'ordinateur sur un support d'information, ledit 10 programme étant susceptible d'être mis en oeuvre par un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre d'un procédé de gestion d'événements selon la revendication 21. 23. Support d'enregistrement lisible par un ordinateur sur 15 lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de gestion d'événements selon la revendication 21. 24. Système de contrôle (40), comportant au moins un serveur 20 d'information (30) selon l'une quelconque des revendications 8 à 13 et au moins un serveur de gestion d'événements (20) selon l'une quelconque des revendications 19 à 20, synchronisés entre eux par l'intermédiaire d'un serveur NTP (Network Time Protocol).