Brevet FR2868177A1 — publié le 20050930

La présente invention concerne une sonde logicielle, c'est-à-dire un dispositif pouvant être embarqué dans un terminal mobile pour superviser, mesurer et analyser son utilisation. De façon générale, les sondes logicielles connues embarquées dans un terminal mobile ne permettent que la supervision d'un service particulier. Dans un domaine voisin, on connaît des méthodes reposant sur la collecte de données auprès de serveurs de communication et qui permettent d'obtenir certaines données d'utilisations des terminaux mobiles en liaison avec ces serveurs, et notamment des informations liées à la configuration de services, ou à des transactions effectuées à partir de ces terminaux. Mais ces méthodes de collecte ne permettent pas d'obtenir d'informations sur l'utilisation de l'interface homme machine du terminal mobile (navigation dans les menus, ...) ni sur l'utilisation d'applications locales (c'est à dire sans accès distant) embarquées dans le terminal mobile. La présente invention permet de résoudre les problèmes précités. A cet effet, elle vise un dispositif de supervision de l'usage d'un terminal mobile comportant un système d'exploitation et une interface homme machine gérant des fenêtres, ce dispositif étant caractérisé en ce qu'il comporte: des moyens d'identification de la fenêtre active du terminal; des moyens d'obtention et de mémorisation de l'adresse du processus gérant les messages de la fenêtre active; des moyens pour détourner ces messages vers des moyens de filtrage d'événements destinés à filtrer des événements compris dans ces messages, en fonction de règles de filtrage prédéterminées; des moyens de mémorisation d'au moins une donnée d'analyse associée aux événements filtrés; et des moyens pour rediriger les messages vers l'adresse précédemment mémorisée. Le dispositif selon l'invention permet ainsi d'obtenir des données d'analyse de l'ensemble des fonctions du terminal et des applications embarquées dans le terminal, dès lors qu'elles sont associées à des événements du processus lié à la fenêtre active du terminal. L'invention repose ainsi sur l'identification du processus gérant les messages de la fenêtre active du terminal, puis sur le détournement temporaire de ces messages vers des moyens de filtrage d'événements à superviser, pour ne mémoriser que des données que l'on souhaite ultérieurement analyser. Le dispositif de supervision fonctionne de manière transparente puisque les messages interceptés sont finalement redirigés vers leur adresse de destination normale. Préférentiellement, les moyens d'identification comportent des moyens de filtrage d'un événement système prédéterminé associé au passage de la fenêtre active en arrière plan. Cette caractéristique permet avantageusement, lorsqu'une fenêtre passe en arrière plan, de reconfigurer le filtre en fonction des règles associées à la fenêtre nouvellement active, à savoir celle qui occupe le premier plan. Préférentiellement, les moyens d'identification de la fenêtre active sont adaptés à obtenir et mémoriser le titre de la fenêtre active, ce titre constituant l'une des données d'analyse précitées. Dans un mode préféré de réalisation, les règles de filtrage sont contenues 20 dans un fichier de définition, lu au démarrage (en anglais boot ) du terminal mobile. Conformément à l'invention ces règles permettent de positionner des filtres, c'est-à-dire configurer les moyens de filtrage, pour superviser deux types d'évènements: des événements système; et/ou des événements réseau. Comme décrit ultérieurement, les événements système sont des événements permettant de suivre l'usage du terminal mobile par son utilisateur, les événements réseau étant surtout utilisés pour qualifier la qualité d'un service d'accès distant (en anglais QOS Quality Of service ). Préférentiellement, le dispositif de supervision selon l'invention est configuré de manière à superviser un événement système représentatif de 2868177 3 l'appui ou du relâchement d'une touche d'un clavier du terminal, ou de l'émission d'un caractère, et un événement réseau représentatif de la prise ou de la libération d'une ressource dans un réseau de télécommunication accessible par le terminal (WiFi, Bluetooth, GPRS, ...). Conformément à l'invention, le dispositif de supervision comporte des moyens de mémorisation d'une donnée d'analyse associée aux événements filtrés. Cette donnée d'analyse peut notamment être constituée par le type d'événement, la date et l'heure de son occurrence, ou un compteur 10 d'événements. Dans un mode préféré de réalisation, les moyens de mémorisation comportent des moyens d'édition des données d'analyse dans un journal d'activité (en anglais log file ), ces moyens d'édition ayant une priorité d'exécution basse par rapport aux autres processus, afin de ne pas perturber le fonctionnement du terminal mobile. Le dispositif de supervision selon l'invention comporte préférentiellement des moyens d'envoi de ce journal d'activité vers un serveur de collecte. Corrélativement, l'invention vise aussi un procédé de supervision de l'usage d'un terminal mobile comportant un système d'exploitation et une interface homme machine gérant des fenêtres, ce procédé étant caractérisé en ce qu'il comporte: une étape d'identification de la fenêtre active du terminal; une étape d'obtention et de mémorisation de l'adresse du processus gérant les messages de la fenêtre active; une étape de détournement des messages et de filtrage d'événements compris dans ces messages, en fonction de règles de filtrage prédéterminées; une étape de mémorisation, d'au moins une donnée d'analyse associée aux événements filtrés; et une étape de redirection des messages vers l'adresse précédemment mémorisée. L'invention vise aussi un terminal mobile comportant, sous la forme d'un programme résident, un dispositif de supervision ou des moyens de mise en oeuvre d'un procédé de supervision, tels que décrits brièvement ci-dessus. Les avantages particuliers du procédé de supervision et du terminal mobile étant identiques à ceux du dispositif mentionné précédemment, ils ne seront pas rappelés ici. D'autres aspects et avantages de la présente invention apparaîtront plus clairement à la lecture de la description de modes particuliers de réalisation qui va suivre, cette description étant donnée uniquement à titre d'exemple non limitatif et faite en référence aux annexes et aux dessins dans lesquels: l'annexe A comporte des lignes d'un fichier de définition permettant de configurer des filtres de supervision conformes à l'invention; - la figure 1 représente, sous forme d'organigramme, les principales étapes d'un procédé de supervision conforme à l'invention dans un mode préféré de réalisation; et la figure 2 représente, de façon schématique, un terminal mobile conforme à l'invention dans un mode préféré de réalisation. Le procédé et le dispositif selon l'invention décrits ici, peuvent être utilisés pour superviser l'usage d'un téléphone intelligent (en anglais smartphone ) de type Smartphone 2003 équipé du système d'exploitation Windows CE.NET. En référence aux figures 1 et 2, le procédé de supervision décrit ici comporte une première étape E10 d'initialisation au cours de laquelle on charge un programme résident dans la mémoire de travail du téléphone intelligent. Dans le mode préféré de réalisation décrit ici, ce programme résident comporte: un automate P_AUT; et une procédure P_FILTRE de filtrage d'événements. Après l'étape E10 d'initialisation, l'automate P_AUT est adapté à mettre en oeuvre une étape E20 d'identification de la fenêtre active 140 du téléphone 30 intelligent 10, à savoir la fenêtre affichée à l'écran 130 du terminal 10. A cet effet, cette étape fait tout d'abord appel à la fonction GetForegroundWindow(), définie dans le fichier Winuser.h de Windows CE, et qui retourne un pointeur p_140 sur la fenêtre active 140. Au cours de cette même étape, l'automate P_AUT filtre, pour la fenêtre active 140 ainsi obtenue, l'événement système prédéterminé WM_ACTIVATE, associé au passage de la fenêtre active 140 en arrière plan, cet événement étant défini dans le fichier Winuser.h de Windows CE. Lorsque cet événement est reçu, l'automate P_AUT récupère le pointeur p_140 sur la nouvelle fenêtre active 140 par un autre appel à la fonction 10 GetForegroundWindow comme décrit ci-dessus. Dans le mode préféré de réalisation décrit ici, on récupère et on mémorise, au cours de cette étape d'identification E20, le titre t de la fenêtre active en utilisant le filtre WM_SETTEXT défini dans le fichier Winuser.h de Windows CE. L'étape E20 d'identification de la fenêtre active est suivie par une étape E30 au cours de laquelle l'automate obtient, en faisant appel à la procédure GetWindowLong(), l'adresse add_proc du processus gérant les messages de la fenêtre active 140. A l'étape E40 suivante, l'automate P_AUT mémorise cette adresse 20 add_proc. L'étape E40 de mémorisation est suivie par une étape E50 au cours de laquelle l'automate P_AUT détourne les messages de la fenêtre active 140 vers la procédure de filtrage P_FILTRE. Cette étape de détournement est effectuée en faisant appel à la fonction SetWindowLong() définie dans le fichier Winuser.h de Windows CE. Conformément à l'invention, cette procédure de filtrage P_FILTRE, permet de mettre en oeuvre une étape E60 de filtrage des événements compris dans les messages, en fonction de règles de filtrage prédéterminées. Dans le mode de réalisation décrit ici, ces règles de filtrage sont lues à 30 partir d'un fichier de définition F_DEF, contenu dans la base des registres du terminal 10. Un exemple de fichier de définition F_DEF va maintenant être décrit en référence à l'annexe A. Dans l'exemple décrit ici, les expressions /* et *1 sont utilisées pour délimiter des commentaires. Ce fichier de définition F_DEF permet de configurer deux types de filtres: - des filtres d'événements système spécifiés dans la première section (/*Section d'événements système*/) ; et - des filtres d'événements réseau, spécifiés dans la seconde section (/*Section d'événements système*/). Plus précisément ce fichier F_DEF permet le filtrage: - des événements système touche enfoncée (/* L1 */), touche relâchée (/* L2 */), et caractère émis (/* L3 */) lors de la supervision de la fenêtre active associée à l'application mms_compose d'édition de message; et - les événements du service réseau utilisant le port de communication 9201. Dans le mode de réalisation décrit ici, le filtrage des événements système proprement dit est effectué par la procédure de filtrage P_FILTRE activée au cours de l'étape E40 de détournement déjà décrite. Dans le mode préféré de réalisation décrit ici, le filtrage des événements 20 réseau est implémenté par un service de transport SPI ( Service Provider Interface en anglais) de la procédure de filtrage P_FILTRE. De façon connue, ce service de transport SPI utilise l'interface standard de même nom définie, conformément au modèle WOSA (Windows Open Statement Architecture) dans l'architecture Winsock 2.2 ( Windows Sockets ) de Windows CE, entre l'interface de programmation Windows API (et les fonctions exportées de la bibliothèque de liens dynamiques Winsock DLL, ws2.dII) et les couches de protocoles réseaux. Ce service de transport SPI permet de faire transiter tous les appels à destination de l'API Winsock, vers une bibliothèque de liens dynamiques LSP ( Layered Service Provider en anglais) préalablement enregistrée par l'appel à la fonction DIIRegisterServer définie par Microsoft Windows CE version 2.0 et suivantes, et dont le chemin d'accès a été spécifié dans les registres à la clef HKEY_LOCAL_MACHI N E\COM\WS2\LSP. Le positionnement des filtres se fait en indiquant les numéros de port (9201 dans cet exemple) que l'on souhaite superviser, les principaux événements remontés étant les événements de connexion TCP entrante et sortante, ainsi que l'envoi ou la réception de données transitant par ce port. L'homme du métier comprendra qu'un tel filtre est positionné entre les couches de niveau 4 (transport) et 5 (session) du modèle OSI (Open Systems Interconnection). L'étape E60 de filtrage est suivie par un test E62 au cours duquel on teste si l'événement filtré est l'événement WM_ACTIVATE représentatif du passage en arrière plan de la fenêtre active 140. Si tel est le cas, le résultat de ce test est positif. Ce test est alors suivi par une étape E64 au cours de laquelle on restitue le processus normal de gestion 15 de la fenêtre 140 nouvellement en arrière plan, par appel à la fonction SetWindowLong() déjà citée. Cette étape E64 de restitution est suivie par l'étape E20 déjà décrite d'identification de la nouvelle fenêtre active. En revanche, si l'événement filtré est différent de l'événement 20 WM_ACTIVATE, le résultat du test E62 est négatif. Ce test E62 est alors suivi par une étape E70 de mémorisation de données d'analyse associées aux événements systèmes et réseaux filtrés à l'étape précédente. Dans le mode préféré de réalisation décrit ici, cette étape est mise en oeuvre par la procédure de filtrage d'événements P_FILTRE, qui édite dans un journal d'activité LOG, avec une priorité d'exécution basse part rapport aux autres processus s'exécutant dans le terminal mobile, la date, l'heure et le titre t de la fenêtre active 140 au moment de l'occurrence des événements, ainsi qu'un compteur mémorisant le nombre d'occurrence de chacun de ces événements. L'étape E70 de mémorisation est suivie par une étape E80 au cours de laquelle la procédure de filtrage envoie le journal d'activité LOG vers un serveur de collecte, pour analyse ultérieure de ces données. La présente invention permet ainsi de réaliser un véritable suivi de l'utilisation de l'interface homme machine du terminal mobile, de quantifier l'utilisation de services, de noter les chemins de navigation préférentiels, d'identifier les incohérences de navigation, de déceler les échecs lors de l'utilisation de services, et de détecter des problèmes ergonomiques au niveau de l'interface homme machine. Cette étape d'envoi E80 peut notamment être effectuée à intervalles réguliers ou sur requête distante depuis le serveur de collecte. L'étape E80 d'envoi est suivie par une étape E90 de redirection des 10 messages interceptés au cours de l'étape E50 de détournement. Cette étape consiste à réémettre chacun des messages vers l'adresse de destination add_dest mémorisée à l'étape E40 déjà décrite. Nous allons maintenant décrire, en référence à la figure 2, un téléphone intelligent 10 conforme à l'invention, ce téléphone étant de type Smartphone 15 2003. De façon connue, ce téléphone 10 comporte notamment un processeur 100, un clavier 110 avec des touches 120, un écran 130, une mémoire morte de type ROM 135, une mémoire flash 150, une mémoire vive de type RAM 160, un module de communication radio 170, ces éléments étant reliés entre eux par un système de bus 180. Le téléphone 10 comporte une interface homme machine gérant des fenêtres 140, 141. Pour simplifier, on supposera que tous les programmes mémorisés dans la mémoire morte 135 sont installés dans la mémoire vive 160 à la mise sous tension du terminal 10. Ainsi, la mémoire vive 160 comporte notamment, à l'issue de la phase E10 d'initialisation, le programme résident P_RES, dont l'automate P_AUT et la procédure de filtrage P_FILTRE ont déjà été décrits en référence à la figure 1. La mémoire vive 160 comporte également un système d'exploitation conforme à Windows CE.NET, et des pilotes 200 pour la gestion du clavier 110, de l'écran 130 et du module de communication radio 170. La mémoire vive 160 comporte également une interface de programmation API définissant les différentes procédures d'appel utilisées par les applications embarquées dans le terminal 10 et un service de transport SPI entre l'interface de programmation Windows API et les couches de protocoles réseaux non représentées ici. La mémoire vive 160 comporte également trois registres p_140, add_proc et t dans lesquels l'automate P_AUT mémorise respectivement le pointeur sur la fenêtre active 140, l'adresse add_proc du processus gérant les messages de cette fenêtre, et le titre t de cette fenêtre. Dans l'exemple décrit ici, la mémoire vive comporte également l'application mms_compose d'édition de message. Dans le mode préféré de réalisation décrit ici, la mémoire flash 150 comporte le fichier de définition F_DEF de l'annexe A, et le journal d'activité LOG. Comme décrit précédemment les messages de la fenêtre active 140 sont détournés vers la procédure de filtrage P_FILTRE. Conformément aux règles de filtrage définies dans le fichier F_DEF, la procédure de filtrage P_FILTRE filtre les événements réseau du port 9201 et les événements système d'appui ou de relâchement de la touche 120, ou d'émission d'un caractère par l'application mms_compose. Puis la procédure de filtrage P_FILTRE mémorise des données d'analyse associées à ces événements dans le journal d'activité LOG, qui peut ensuite être envoyé, par les moyens de communication radio 170, vers un serveur de collecte non représenté ici. Le processeur 100, la mémoire morte de type ROM 135, la mémoire flash 150, la mémoire vive de type RAM 160 et le module de communication radio 170 et le programme résident P_RES constituent des éléments d'un dispositif de supervision conforme à l'invention dans un mode préféré de réalisation. En effet, le programme résident P_RES constitue: des moyens adaptés, en filtrant l'événement système WM_ACTIVATE, à identifier la fenêtre active 140 du terminal 10; des moyens d'obtention et de mémorisation dans la mémoire vive 160, de l'adresse add_proc du processus gérant les messages de la fenêtre active 140; des moyens pour détourner lesdits messages vers la procédure P_FILTRE de filtrage d'événements compris dans ces messages, en fonction de règles de filtrage prédéterminées définies dans le fichier de définition F_DEF; des moyens de mémorisation et d'édition des données d'analyse associées aux événements filtrés dans le journal d'activité LOG; des moyens pour rediriger les messages vers l'adresse add_proc; et des moyens d'envoi, en coopération avec le module de communication radio 170, du journal d'activité LOG vers un serveur de collecte. L'invention peut aussi être utilisée pour superviser les événements 15 système d'un terminal de type Smartphone 2002. 11 ANNEXE A /* Section événements système */ [HKEY_CURRENT_USER1Software\M0B\APPLICATION\ W INDOWS_APP\mms_compose\CAPEDIT\MATCH_MESSAGE] "MSG1"="WM_KEYDOWN" /* L1 */ "MSG2"="WM_KEYUP" /* L2 */ "MSG3"="WM_CHAR" /* L3 */ /* Section événements réseau */ [HKEY_CURRENT_USER1Software\MOB\APPLICATION\ NETWORK_FILTER] "PORT"="9201" /* L4 */ REVENDICATIONS 1. Dispositif de supervision de l'usage d'un terminal mobile (10) comportant un système d'exploitation et une interface homme machine gérant des fenêtres (140, 141), ledit dispositif étant caractérisé en ce qu'il comporte: des moyens d'identification de la fenêtre active (140) dudit terminal; des moyens d'obtention et de mémorisation de l'adresse (add_proc) du processus gérant les messages de ladite fenêtre active (140) ; des moyens pour détourner lesdits messages vers des moyens de filtrage d'événements, destinés à filtrer des événements compris dans lesdits messages, en fonction de règles de filtrage prédéterminées; des moyens de mémorisation d'au moins une donnée d'analyse associée auxdits événements filtrés; et des moyens pour rediriger lesdits messages vers ladite adresse précédemment mémorisée (add_proc). 2. Dispositif de supervision selon la revendication 1, caractérisé en ce que lesdits moyens d'identification comportent des moyens de filtrage d'un événement système prédéterminé (WM_ACTIVATE) associé au passage de la fenêtre active (140) en arrière plan. 3. Dispositif de supervision selon la revendication 1 ou 2, caractérisé 25 en ce que lesdits moyens d'identification sont adaptés à obtenir et mémoriser le titre (t) de ladite fenêtre active, ledit titre constituant une desdites données d'analyse. 4. Dispositif de supervision selon l'une quelconque des revendications 1 à 3, caractérisé en ce que lesdites règles de filtrage sont contenues dans un 30 fichier de définition (F_DEF) et en ce qu'elles permettent de configurer lesdits 15 2868177 13 moyens de filtrage pour superviser au moins un événement système et/ou au moins un événement réseau. 5. Dispositif de supervision selon la revendication 4, caractérisé en ce que ledit événement système est représentatif de l'appui ou du relâchement d'une touche (120) d'un clavier (110) dudit terminal (10) ou de l'émission d'un caractère. 6. Dispositif de supervision selon la revendication 4 ou 5, caractérisé en ce que ledit filtre d'événement est représentatif de la prise ou de la libération d'une ressource dans un réseau de télécommunication accessible par ledit terminal (10). 7. Dispositif de supervision selon l'une quelconque des revendications 1 à 6, caractérisé en ce que lesdits moyens de mémorisation comportent-des moyens d'édition desdites données d'analyse dans un journal d'activité (LOG), lesdits moyens d'édition ayant une priorité d'exécution basse. 8. Dispositif de supervision selon la revendication 7, caractérisé en ce qu'il comporte des moyens d'envoi dudit journal d'activité (LOG) vers un serveur de collecte. 9. Procédé de supervision de l'usage d'un terminal mobile (10) comportant un système d'exploitation et une interface homme machine gérant 20 des fenêtres, ce procédé étant caractérisé en ce qu'il comporte: une étape (E20) d'identification de la fenêtre active dudit terminal; une étape d'obtention (E30) et de mémorisation (E40) de l'adresse (add_proc) du processus gérant les messages de ladite fenêtre active (140) ; une étape (E50) de détournement desdits messages et de filtrage d'événements (E60) compris dans lesdits messages, en fonction de règles de filtrage prédéterminées; une étape (E70) de mémorisation, d'au moins une donnée d'analyse associée auxdits événements filtrés; et une étape (E90) de redirection desdits messages vers ladite adresse de destination mémorisée (add_proc). 10. Procédé de supervision selon la revendication 9, caractérisé en ce que ladite étape d'identification (E20) comporte une étape de filtrage d'un événement système prédéterminé (WM_ACTIVATE) associé au passage de la fenêtre active (140) en arrière plan. 11. Procédé de supervision selon la revendication 9 ou 10, caractérisé en ce qu'il comporte en outre une étape (E20) d'obtention du titre (t) de ladite fenêtre active, ledit titre (t) constituant une desdites données d'analyse. 12. Procédé de supervision selon l'une quelconque des revendications 9 à 11, caractérisé en ce que, au cours de ladite étape (E60) de filtrage, on supervise au moins un événement système et/ou au moins un événement réseau, en fonction de règles de filtrage lues dans un fichier de définition (F_DEF). 13. Procédé de supervision selon la revendication 12, caractérisé en ce que ledit événement système est représentatif de l'appui ou du relâchement d'une touche (120) d'un clavier (110) dudit terminal (10) ou de l'émission d'un caractère. 14. Procédé de supervision selon la revendication 12 ou 13, caractérisé en ce que ledit filtre d'événement est représentatif de la prise ou de la libération d'une ressource dans un réseau de télécommunication accessible audit terminal (10). 15. Procédé de supervision selon l'une quelconque des revendications 9 à 14, caractérisé en ce que, au cours de ladite étape (E70) de mémorisation des données d'analyse, on édite, avec une priorité d'exécution basse, lesdites données d'analyse dans un journal d'activité (LOG). 16. Procédé de supervision selon l'une quelconque des revendications 9 à 15, caractérisé en ce qu'il comporte une étape d'envoi (E80) dudit journal d'activité (LOG) vers un serveur de collecte. 17. Terminal mobile caractérisé en ce qu'il comporte, sous la forme d'un programme résident (P_RES), un dispositif de supervision selon l'une quelconque des revendications 1 à 8 ou des moyens de mise en oeuvre d'un procédé de supervision selon l'une quelconque des revendications 9 à 16.