TERMINAL MOBILE

La présente invention concerne les terminaux de communication et plus particulièrement les terminaux mobiles, et notamment ceux conçus pour recevoir et restituer des programmes audio et/ou vidéo.

Des programmes audio et/ou vidéo peuvent être diffusés à des terminaux mobiles grâce aux standards DVB-H (Digital Video Broadcast - Handheld), DVB-SH (Digital Video Broadcast - S-Band Handheld) ou 3G (normes de téléphonie mobile de troisième génération), le standard DAB (Digital Audio Broadcasting) étant adapté à la diffusion de programmes audio. Dans un système de diffusion de programmes audio et/ou vidéo, il est souhaitable d'effectuer des mesures d'audience pour déterminer quels services sont accèdes par les utilisateurs et à quels moments. Ces mesures permettent aux fournisseurs de service d'adapter leurs programmes et leurs horaires aux attentes des utilisateurs. D'une manière plus générale, les terminaux mobiles offrent aujourd'hui de nombreux autres services, comme des services de restitution de fichiers multimédia (fichiers audio ou vidéo stockés dans la mémoire du terminal), des jeux vidéo également stockés dans la mémoire du terminal, des services de localisation par satellite, etc. Dans ce contexte, un opérateur de téléphonie mobile ou un fabricant de téléphones mobiles, par exemple, peut souhaiter obtenir des informations sur l'usage des téléphones mobiles pour déterminer notamment à quelle fréquence chaque service peut être utilisé.

Les informations d'usage de services nécessitant une connexion point à point à un réseau, comme les services de télécommunication et d'accès au réseau Internet, peuvent être facilement recueillies par l'opérateur donnant au terminal l'accès au réseau. Par contre, l'usage de services fournis uniquement par le terminal ou par l'intermédiaire de modules de réception du terminal, comme les modules de réception de signaux GPS (Global Positioning System), DVB ou DAB, ne peut pas être surveillé à distance pour collecter des informations d'usage. II est également souhaitable que l'usage d'un terminal puisse être placé sous surveillance que si l'utilisateur du terminal a donné son accord.

En outre, il est souhaitable que le destinataire des informations collectées puisse choisir quand activer et désactiver la collecte d'informations d'usage et choisir quels terminaux doivent réaliser ces opérations.

D'une manière générale, il est souhaitable de pouvoir activer ou désactiver à distance une opération sur un terminal mobile distant. Il est également souhaitable qu'une telle activation ou désactivation puisse être effectuée d'une manière sécurisée, tant du côté du terminal que du côté de l'émetteur des commandes d'activation et de désactivation. Il convient en effet de s'assurer qu'une opération sur un terminal ne puisse pas être activée par une entité non habilitée, et que seul un terminal habilité puisse être sollicité pour activer ou désactiver une opération.

Dans le cadre d'une collecte d'informations d'usage de services, il est souhaitable de pouvoir assurer que les informations collectées proviennent bien de terminaux habilités, et ne puissent pas être interceptées ou transmises à un autre destinataire que celui désigné.

Dans le cadre du standard DVB-H, il existe un service de guide de programme défini par la norme ESG (Electronic Service Guide) qui a été prévu pour fournir des fonctions nécessaires pour rechercher, découvrir et accéder à des services de programme vidéo. Le service de guide de programmes comprend une application installée dans le terminal mobile pour recevoir et traiter toutes les requêtes d'accès à un service vidéo émise par l'utilisateur, et pour fournir des informations relatives à un programme. L'application de guide de programme peut donc être modifiée pour assurer l'enregistrement des requêtes émises par l'utilisateur pour accéder aux programmes vidéo, l'enregistrement de ces requêtes permettant d'établir des statistiques de mesure d'audience de programmes.

Dans un mode de réalisation, il est prévu un procédé de déclenchement d'une opération dans un terminal mobile, comprenant une étape de réception par le terminal mobile par l'intermédiaire d'un réseau de communication, d'un message de déclenchement d'une opération. Selon un mode de réalisation, le procédé comprend des étapes consistant à, à la suite de la réception du message de déclenchement, transmettre par le terminal mobile à un serveur un identifiant relatif à une opération à déclencher sur le terminal reçu avec le message de déclenchement, si l'identifiant correspond à un identifiant autorisé, transmettre par le serveur au terminal mobile un message de réponse positif autorisant le déclenchement de l'opération, et déclencher l'opération par le terminal mobile seulement si le terminal mobile reçoit le message de réponse positif.

Selon un mode de réalisation, l'identifiant identifie une entité ayant transmis le message de déclenchement au terminal mobile.

Selon un mode de réalisation, le procédé comprend une étape de transmission par le terminal mobile d'un message de notification à une entité émettrice du message de déclenchement, indiquant que l'opération a été déclenchée.

Selon un mode de réalisation, l'opération à déclencher est l'activation d'une application dans le terminal, le procédé comprenant une étape de désactivation de l'application si un identifiant du terminal contenu dans le message de notification désigne un terminal mobile non habilité à activer l'application.

Selon un mode de réalisation, le message de déclenchement contient des informations relatives à l'opération à déclencher sous forme chiffrée, qui sont transmises par le terminal mobile au serveur, qui sont déchiffrées par le serveur et transmises sous forme déchiffrée par le serveur au terminal dans le message de réponse positif.

Selon un mode de réalisation, le serveur émet un message de réponse positif si l'opération à déclencher est autorisée pour l'entité émettrice du message de déclenchement. Selon un mode de réalisation, le message de réponse comprend des informations complémentaires relatives à l'opération à déclencher.

Selon un mode de réalisation, le procédé comprend l'établissement d'un lien de communication sécurisé entre le terminal mobile et le serveur.

Selon un mode de réalisation, l'opération à déclencher est l'activation d'une application de collecte d'informations d'usage d'une application à surveiller installée dans le terminal mobile, le message de déclenchement d'opération comprenant des informations relatives à une campagne de collecte et une adresse d'un serveur de collecte à qui des informations d'usage collectées par le terminal sont à transmettre, le procédé comprenant des étapes collecte et de mémorisation par le terminal d'informations d'usage relatives à l'application à surveiller, et de transmission par le terminal des informations d'usage collectées au serveur de collecte.

Selon un mode de réalisation, l'application à surveiller est une application de réception et de restitution de programmes audio et/ou vidéo. Selon un mode de réalisation, à la réception des informations d'usage transmises par le terminal, le serveur de collecte détermine à l'aide d'un identifiant reçu du terminal, si l'application de collecte doit être activée sur le terminal, et transmet au terminal un message déclenchement d'une opération de désactivation si l'application de collecte ne doit pas être activée sur le terminal.

Selon un mode de réalisation, le message de déclenchement d'opération est transmis au terminal sous la forme d'un message de type SMS, ou conforme au protocole OMA PUSH OTA over WSP ou au protocole OMA Push OTA over HTTP, ou encore transmis collectivement à plusieurs terminaux destinataires en association avec une liste d'identifiants des terminaux destinataires, dans des flux de données structurées ou des tables binaires.

Dans un mode de réalisation, il est également prévu un terminal mobile configuré pour recevoir un message de déclenchement d'une opération par le terminal mobile par l'intermédiaire d'un réseau de communication. Selon un mode de réalisation, le terminal est configuré pour envoyer un identifiant à un serveur en réponse à la réception du message d'activation, et activer l'opération seulement s'il reçoit du serveur un message de réponse positif autorisant le déclenchement de l'opération. Selon un mode de réalisation, l'identifiant identifie une entité ayant transmis le message de déclenchement au terminal mobile.

Selon un mode de réalisation, le terminal est configuré pour transmettre un message de notification à une entité émettrice du message de déclenchement, indiquant que l'opération a été déclenchée. Selon un mode de réalisation, le terminal est configuré pour transmettre au serveur des informations relatives à l'opération à déclencher reçues sous forme chiffrée dans le message de déclenchement, et recevoir du serveur dans le message de réponse les informations relatives à l'opération à déclencher sous forme déchiffrée. Selon un mode de réalisation, le message de réponse reçu comprend des informations complémentaires relatives à l'opération à déclencher.

Selon un mode de réalisation, le terminal est configuré pour établir avec le serveur un lien de communication sécurisé. Selon un mode de réalisation, l'opération à déclencher est l'activation d'une application de collecte d'informations d'usage d'une application à surveiller installée dans le terminal mobile, le message de déclenchement d'opération comprenant des informations relatives à une campagne de collecte et une adresse d'un serveur de collecte à qui des informations d'usage collectées par le terminal sont à transmettre, l'exécution de l'application de collecte par le terminal comprenant des étapes de collecte et de mémorisation d'informations d'usage relatives à l'application à surveiller, et de transmission des informations d'usage collectées au serveur de collecte. Selon un mode de réalisation, l'application à surveiller est une application de réception et de restitution de programmes audio et/ou vidéo.

Selon un mode de réalisation, le message de déclenchement d'opération est transmis au terminal sous la forme d'un message de type SMS, ou conforme au protocole OMA PUSH OTA over WSP ou au protocole OMA Push OTA over HTTP, ou encore transmis collectivement à plusieurs terminaux destinataires en association avec une liste d'identifiants des terminaux destinataires, dans des flux de données structurées ou des tables binaires.

Des exemples de réalisation de l'invention seront décrits dans ce qui suit, à titre non limitatif en relation avec les figures jointes parmi lesquelles :

- la figure 1 représente sous la forme de blocs un système permettant de déclencher des opérations dans des terminaux mobiles, selon un mode de réalisation, - la figure 2 représente des étapes d'un procédé de déclenchement d'une opération dans un terminal mobile, selon un mode de réalisation,

- la figure 3 représente des étapes d'un procédé de collecte d'informations d'usage d'une application sur un terminal mobile, selon un mode de réalisation. La figure 1 représente des terminaux mobiles MT configurés pour se connecter à un réseau de téléphonie mobile MNT, un ou plusieurs serveurs de d'activation CSRV et un serveur d'authentification VSRV. Les serveurs CSRV et VSRV sont configurés pour communiquer avec les terminaux mobiles MT, par exemple par l'intermédiaire du réseau MNT et le cas échéant, d'autres réseaux tels que le réseau Internet ou des réseaux de téléphonie terrestre. Les terminaux MT sont également configurés pour exécuter diverses applications et notamment des applications d'accès à des programmes audio et/ou vidéo. La figure 2 représente des étapes d'un procédé de déclenchement d'une opération dans un terminal mobile MT. Le procédé de déclenchement fait intervenir l'un des serveurs d'activation CSRV et le serveur d'authentification VSRV. Le procédé comprend des étapes S1 à S7. A la première étape S1 , le serveur d'activation CSRV transmet au terminal MT un message de déclenchement d'une opération DOP comportant un identifiant CID du serveur et des paramètres CPAR définissant l'opération à déclencher dans le terminal MT. Pour transmettre le message DOP au terminal, le serveur CSRV possède un identifiant TID du terminal MT, tel que le numéro de téléphone de ce dernier. Les paramètres CPAR comprennent des informations d'identification de l'opération à déclencher et, le cas échéant, des paramètres relatifs à cette opération. Les identifiants TID des terminaux à déclencher et les paramètres CPAR sont par exemple mémorisés dans une base de données d'opérations à déclencher TDB. L'identifiant CID du serveur CSRV peut être un numéro de téléphone d'accès à un réseau téléphonique. Le numéro de téléphone du serveur CSRV peut ainsi être soit attribué à une ligne téléphonique terrestre, soit mémorisé dans un module sécurisé d'accès à un réseau téléphonique mobile, telle qu'une carte SIM (Subscriber Identity Module). De cette manière, le serveur CSRV peut être identifié d'une manière difficilement falsifiable. A l'étape suivante S2, le terminal MT se connecte au serveur d'authentification VSRV et lui retransmet le message de déclenchement DOP reçu du serveur CSRV. A cet effet, le terminal mémorise une adresse d'accès au serveur VSRV, telle qu'une adresse L)RL (Uniform Ressource Locator). A l'étape suivante S3, le serveur VSRV vérifie que l'identifiant CID et éventuellement les informations CPAR contenus dans le message DOP reçu correspondent à des informations qu'il a préalablement mémorisées, par exemple dans une base de données d'opérations à déclencher CDB. A cet effet, le serveur VSRV mémorise tous les identifiants des serveurs CSRV autorisés à déclencher une opération sur un terminal MT, chaque identifiant de serveur autorisé étant éventuellement mémorisé en association avec des identifiants d'opérations que le serveur est autorisé à déclencher.

A l'étape S4, le serveur VSRV transmet au terminal MT un message de réponse REP indiquant si oui ou non le terminal peut déclencher l'opération selon que les informations CID, CPAR correspondent ou non à des informations préalablement mémorisées par le serveur VSRV.

Ainsi, les étapes S2 à S4 permettent au terminal d'authentifier le serveur CSRV ayant émis le message de déclenchement, et de vérifier que le déclenchement de l'opération est bien autorisé pour le serveur CSRV authentifié. A l'étape S5, le terminal MT transmet un message de notification NOT contenant son identifiant TID au serveur CSRV, pour lui indiquer si l'ordre de déclenchement de l'opération a été autorisé ou non. Aux étapes S6 et S7, le terminal MT déclenche l'opération OP, si le message REP indique que l'ordre de déclenchement peut être exécuté. Bien entendu, il peut être prévu d'envoyer le message NOT seulement si l'opération a été autorisée.

L'opération déclenchée peut être l'activation ou la désactivation d'une application telle qu'une application de collecte d'informations d'usage de services offerts par des applications installées dans le terminal MT. Les services peuvent être purement locaux, c'est-à-dire offerts par le terminal seul, comme des services de restitution de fichiers audio ou vidéo, ou encore des jeux vidéo, préalablement stockés par le terminal. Les services offerts par le terminal peuvent également être offerts par l'intermédiaire du terminal agissant en tant que récepteur pour, par exemple, recevoir des signaux de localisation géographique ou des programmes audio ou vidéo, ou télécharger des fichiers.

Le message de déclenchement d'opération DOP peut être transmis au terminal MT sous la forme d'un message de type SMS (Short Message Service), ou conforme au protocole OMA (Open Mobile Alliance) PUSH OTA (Over The Air) over WSP (Wireless Session Protocol) ou au protocole OMA Push OTA over HTTP. De plus amples informations sur ces protocoles peuvent être obtenues dans le document OMA-TS-PushOTA-V2_2- 20071002-C. Le message de déclenchement d'opération contient alors un identifiant de l'application installée dans le terminal, à qui est destiné le message, et le terminal est configuré pour acheminer chaque message reçu vers l'application identifiée dans le message.

Le message DOP peut être également transmis collectivement, c'est- à-dire par diffusion, à plusieurs terminaux MT, par exemple avec les données de guide de programme, dans des flux de données structurées appelés "sessions", qui peuvent être conformes au protocole FLUTE. De tels flux binaires sont transmis en boucle et accessibles à des adresses IP déterminées. Le message DOP est alors associé à une liste d'identifiants de terminaux destinataires du message. Le message DOP et les identifiants de terminaux destinataires peuvent également être diffusés dans des tables binaires PSI/SI (Program Spécifie information/Service Information) insérées dans une trame de transport conforme au protocole DVB ou DVB-H. Dans cette trame, les flux de données FLUTE sont multiplexes avec des flux vidéo dans des flux de transport multiplexes avec les tables binaires PSI/SI. De plus amples informations sur ces modes de transmission par diffusion peuvent être trouvées notamment dans le document ETSI 102 471 , V1.1.1 (2006-04), "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Electronic Service Guide (ESG)".

Les informations CID, CPAR figurant dans le message DOP transmis par le serveur CSRV peuvent être chiffrées, et retransmises telles quelles par le terminal MT au serveur VSRV. Dans ce cas, le serveur VSRV déchiffre les informations CID et CPAR reçues du terminal MT et les renvoie sous forme déchiffrée au terminal, afin que ce dernier puisse les exploiter et déclencher l'opération requise.

La communication établie entre le terminal mobile et le serveur de validation VSRV est sécurisée, par exemple du type HTTPS (HyperText Transport Protocol Secure), SSL (Secure Sockets Layers) ou TLS (Transport Layer Security). Ainsi, le procédé décrit précédemment permet d'assurer que les informations de déclenchement restent confidentielles et ne peuvent pas être modifiées, et qu'une opération ne peut pas être déclenchée dans un terminal par un serveur CSRV non authentifié. Dans le cas où l'opération à déclencher requiert l'émission vers un serveur d'informations collectées par le terminal, le procédé décrit précédemment permet également d'assurer que les informations collectées sont bien transmises au serveur désigné dans les paramètres de déclenchement CPAR pour recevoir ces informations. La figure 3 représente des étapes S10 à S15 exécutées par le terminal MT lors de l'exécution d'une application de collecte d'informations d'usage, déclenchée à la suite de l'exécution des étapes S1 à S5. A l'étape S10, le terminal MT collecte des informations EVTS et les inscrit dans un fichier stocké dans sa mémoire. A l'étape S11 , si le moment est venu de transmettre les informations collectées EVTS, le terminal MT les transmet à l'étape S12 vers un serveur désigné dans les paramètres de déclenchement CPAR, par exemple le serveur CSRV. La transmission des informations collectées peut être effectuée à une fréquence déterminée, par exemple journalière ou hebdomadaire, ou bien lorsque la mémoire occupée du terminal MT excède un certain seuil. A la suite de leur transmission au serveur CSRV, les informations EVTS collectées sont effacées de la mémoire du terminal.

Il est à noter que l'application de collecte peut être activée dans un terminal MT par plusieurs serveurs CSRV. Dans ce cas, plusieurs instances de l'application de collecte sont activées dans le terminal, chaque instance mémorisant les informations collectées dans un fichier respectif. Chaque fichier d'informations collectées est ensuite transmis au serveur CSRV qui a activé l'instance correspondant au fichier.

A l'étape suivante S13, le serveur CSRV vérifie à l'aide de l'identifiant TID reçu du terminal, que les informations reçues proviennent bien d'un terminal autorisé. Si les informations reçues proviennent d'un terminal autorisé à transmettre des informations d'usage de services, le serveur CSRV exécute alors l'étape S15 où il mémorise les informations reçues dans une base de données d'événements d'usage EVTS. Au contraire, si le terminal MT ayant émis des informations collectées n'est pas un terminal autorisé, le serveur CSRV ne mémorise pas les informations collectées reçues et transmet à l'étape S14 au terminal un message de déclenchement d'une opération de désactivation de la collecte d'informations d'usage. Le message de déclenchement comprend l'identifiant CID du serveur CSRV et des paramètres éventuels de désactivation notamment pour désigner l'application à désactiver.

Pour désactiver l'application désignée dans le message de déclenchement, le terminal exécute les étapes S2 à S4 permettant d'authentifier le serveur CSRV ayant requis la désactivation. Si le serveur

CSRV est authentifié par le serveur d'authentification VSRV, le terminal MT désactive l'application de collecte, sinon il poursuit l'opération de collecte à l'étape S10. Le terminal peut également transmettre au serveur CSRV un message de réponse à la désactivation de l'application de collecte, pour l'informer si l'application de collecte a été ou non désactivée. A la suite de la désactivation de l'opération de collecte, le terminal MT efface de sa mémoire les informations collectées pour l'application de collecte désactivée.

Si l'opération à déclencher concerne une application de collecte d'informations d'usage, le message de déclenchement DOP comprend une information de connexion permettant au terminal MT d'accéder au serveur

CSRV. L'information de connexion peut être une adresse URL et/ou un numéro de téléphone d'accès au serveur.

Il est à noter que si le destinataire des informations collectées est spécifié dans le message DOP, le serveur ayant émis l'ordre d'activation, n'est pas nécessairement le même que celui désigné pour recevoir les informations collectées.

Le procédé décrit précédemment permet d'assurer que les informations d'usage collectées sont transmises exclusivement au serveur référencé dans le message de déclenchement et authentifié par le serveur d'authentification VSRV.

Par exemple, un message de déclenchement DOP d'une opération de collecte d'information d'usage peut comprendre les champs spécifiés dans le tableau 1 suivant :

Tableau 1

Le contenu du message de déclenchement peut être émis sous forme chiffrée, les numéros de téléphone du serveur de collecte et du terminal pouvant être transmis également sous forme non chiffrée. Le message de déclenchement peut alors être retransmis sans être déchiffré par le terminal MT au serveur d'authentification VSRV à l'étape S2.

Le serveur VSRV peut ainsi vérifier à l'aide des champs contenant le numéro de téléphone du serveur et l'identifiant de campagne du message DOP que le serveur identifié dans le message est bien habilité à activer et recevoir les informations collectées pour la campagne identifiée dans le message.

Le message de réponse REP transmis par le serveur VSRV à l'étape S3 peut comprendre les champs spécifiés dans le tableau 2 suivant :

Tableau 2

Toutes les informations fournies dans le message REP sont non chiffrées, la sécurisation de la transmission du message étant assurée par le protocole utilisé (HTTPS) pour transmettre le message. Le terminal n'a donc pas besoin de mettre en œuvre une opération de déchiffrement du contenu du message DOP ou REP.

En cas d'échec de l'authentification du serveur CSRV (champ réponse du message de réponse à "Echec"), le message de réponse REP ne comporte qu'un champ d'erreur, mais pas de champs "URL du serveur de collecte", "Période", "Date d'envoi", "Intervalle" et "Evénements".

Il est à noter que dans l'exemple du tableau 2, les informations transmises dans le message de déclenchement DOP sont les seules strictement nécessaires à l'authentification du serveur CSRV. Si le serveur CSRV et la campagne de collecte sont authentifiés, ces informations sont complétées par le serveur VSRV avec d'autres paramètres d'activation de la campagne de collecte, tels que des paramètres spécifiant au terminal MT où et quand envoyer les informations collectées et quels événements sont à surveiller. Cette disposition est bien entendu applicable à d'autres types d'applications à activer.

Les types d'événement d'usage à surveiller et collecter (champ événements) peuvent être spécifiés à l'aide d'un ou plusieurs octets. Dans le cas de l'usage d'un service de réception de programmes audio ou vidéo, les types d'événement à surveiller et collecter peuvent être ceux résumés dans le tableau suivant :

Tableau 3

Le champ "types d'événement" spécifie sur moins d'un octet les types d'événements à collecter. Le terminal MT est configuré pour détecter chacun des événements spécifiés par ce champ et pour mémoriser dans un fichier d'informations d'usage collectées, un identifiant de chacun des événements détectés en association avec une date et une heure d'apparition de l'événement.

Les informations d'usage collectées EVTS peuvent être transmises (étape S12) à l'aide du protocole HTTP ou FTP (File Transfer Protocol) en utilisant l'adresse URL du serveur CSRV. A cet effet, le terminal MT comprend une pile HTTP et émet des requêtes HTTP POST vers l'URL du serveur de collecte CSRV reçu. En cas d'échec de la transmission avec le serveur CSRV, une ou plusieurs autres tentatives peuvent être effectuées. Si toutes les tentatives ont échouées, une nouvelle séquence de plusieurs tentatives peut être exécutée, par exemple le jour suivant. Si la transmission des informations collectées a réussi, le serveur CSRV transmet en réponse un accusé de réception positif. Le terminal efface alors de sa mémoire les informations transmises.

Un numéro de version logicielle peut être transmis dans le message de collecte pour indiquer au serveur CSRV le format du message contenant les informations d'usage collectées.

Il apparaîtra clairement à l'homme de l'art que la présente invention est susceptible de diverses variantes de réalisation et d'applications. En particulier, l'invention n'est pas limitée à un serveur d'authentification ayant accès à une liste d'identification de tous les serveurs de collecte autorisés. La liste accessible au serveur de validation peut spécifier uniquement tous les serveurs de collecte non autorisés, ou uniquement les opérations autorisées si dans le contexte visé, l'opération peut être déclenchée par n'importe quel serveur. L'invention ne s'applique pas uniquement à la collecte d'informations d'usage d'un service mis en œuvre par un terminal mobile, mais à toute autre opération mettant en œuvre une transmission d'informations par le terminal vers un serveur.