FR3020538A1

FR3020538A1 - Dispositif et procede pour gerer les applications de la telephonie mobile

Info

Publication number: FR3020538A1
Application number: FR1400979A
Authority: FR
Inventors: Fabien Alcouffe; Laurent Ricard; Stephane Rousseau
Original assignee: Thales SA
Current assignee: Thales SA
Priority date: 2014-04-25
Filing date: 2014-04-25
Publication date: 2015-10-30
Anticipated expiration: 2034-04-25
Also published as: FR3020538B1

Abstract

Terminal comprenant une application téléphonie mobile comprenant des moyens (260) adaptés pour gérer l'exécution d'applications en fonction de leur priorité, caractérisé en ce qu'il comporte au moins les éléments suivants : • une interface homme machine (270), adaptée à la configuration des priorités d'applications tournant sur le terminal en fonction du besoin d'un utilisateur; • une base de données comprenant les priorités associées à des applications, • un module de détection d'évènements externes au terminal, • un module de surveillance de l'activité en cours sur le terminal, • un module de gestion des priorités (261) relié au module (263) de détection des applications et de surveillance de l'activité en cours, le module de gestion des priorités est en liaison avec le processeur du terminal (261) et avec un module de filtre des priorités.

Description

DISPOSITIF ET PROCEDE POUR GERER LES APPLICATIONS DE LA TELEPHONIE MOBILE L'invention concerne un dispositif destiné notamment à la téléphonie mobile, sur lequel peuvent fonctionner plusieurs types d'applications, telles que la messagerie, des services internet, etc., le dispositif comprenant des moyens adaptés à gérer les priorités entre une application en cours d'exécution sur le terminal et l'apparition d'un évènement externe ou interne au terminal.

Les téléphones mobiles ou, de manière plus générale, les dispositifs ayant une fonction téléphonie mobile sont des objets qui disposent de plus en plus de fonctionnalités. Aujourd'hui, les téléphones mobiles plus connus sous la dénomination « Smartphone » permettent à un utilisateur de téléphoner, de prendre des photographies, d'enregistrer et de visualiser des vidéos, de recevoir des messages sous différentes formes ou encore de se connecter aux services Internet. Pour éviter d'être interrompu lors d'une conversation téléphonique considérée par l'utilisateur comme importante ou encore en fonction d'une plage horaire dans laquelle il ne souhaite pas être dérangé, un utilisateur peut définir des règles de traitement d'appel en fonction du type de flux entrant ou de l'identifiant de l'appelant. Par exemple, la demande de brevet EP 2 203 981 décrit un terminal et un procédé qui filtrent les appels en fonction de l'appelant et d'un calendrier ,définissant des plages autorisées pour la réception d'appel. Les priorités d'appel sont définies dans une plage temporelle. Les utilisateurs d'iPhone connaissent aussi le mode « ne pas déranger » équipant leur téléphone, qui filtre les appels en fonction d'une plage horaire donnée.

Ces règles divulguées dans l'art antérieur ne prennent pas en compte les applications en cours d'exécution ou l'usage qui est fait du terminal au moment de la réception d'un appel, ou d'un autre évènement intrusif externe ou interne au terminal, tels que des SMS, des notifications d'évènements.

L'objet de l'invention concerne un dispositif comprenant au moins un terminal disposant d'une application téléphonie mobile comprenant des moyens adaptés pour gérer l'exécution d'applications en fonction de leur priorité, caractérisé en ce qu'il comporte au moins les éléments suivants : - une interface homme machine, adaptée à configurer des priorités pour des applications en fonction du besoin d'un utilisateur, - une base de données comprenant les priorités associées aux applications sélectionnées par l'utilisateur, - un module de détection d'évènements externes ou internes au terminal, - un module de surveillance de l'application en cours sur le terminal, - un module de gestion des priorités relié au module de détection d'évènements et au module contenant les priorités associées aux applications, et aussi au processeur auquel il transmet une commande pour continuer l'exécution de l'application en cours, ralentir son exécution ou l'arrêter, lorsque l'évènement est prioritaire par rapport à l'application en cours, ou bien une commande vers un module de notification d'évènement. La base de données de configuration est, par exemple, mémorisée dans le terminal.

Le dispositif peut comporter: - un premier module de présentation à l'utilisateur d'une liste des applications et des évènements disponibles ou pouvant arriver sur le terminal, - un deuxième module définissant des règles correspondantes à des préférences d'usage des applications, - un troisième module adapté à transformer les différentes « règles utilisateurs » en règles formelles, Le dispositif peut comporter en plus un moyen informatique indépendant du terminal et communiquant avec le terminal à l'aide d'un 5 moyen de communication et le moyen informatique comprend, par exemple : - un module de présentation à l'utilisateur d'une liste d'applications et d'événements respectivement disponibles ou pouvant arriver sur le terminal, - un module pour définir des règles correspondantes à des préférences 10 d'usage des applications, - un module d'analyse syntaxique pour obtenir des règles formelles, - une base de règles formelles. Le dispositif comporte, par exemple, un module adapté à injecter un fichier comportant une configuration de priorités pour différentes 15 applications. Selon une variante de réalisation, le terminal est un téléphone mobile et les applications sont choisies parmi la liste suivante : acquisition ou visualisation de vidéo, communication phonie, transfert de données, jeux, navigation internet. 20 L'invention concerne aussi un procédé de gestion d'applications fonctionnant au niveau d'un dispositif objet de l'invention caractérisé en ce qu'il comporte au moins les étapes suivantes: - une phase de configuration du terminal dans laquelle un utilisateur définit un ensemble de règles composées de couples application, 25 niveau de priorité, - une phase de gestion d'évènements où l'on compare le niveau de priorité d'une application en cours d'exécution sur le terminal et le niveau de priorité d'un évènement externe ou interne au terminal, et l'on décide : - si l'application en cours présente un niveau de priorité supérieur à celui de l'évènement, alors l'activité en cours continue d'être exécutée et on notifie l'évènement, - sinon, on suspend l'exécution de l'application ou on passe l'application en second plan et on passe l'évènement en premier plan. L'utilisateur peut définir des règles de niveau de priorité en utilisant une interface comprenant un premier module de présentation à l'utilisateur d'une liste des applications et des évènements disponibles ou pouvant arriver sur le terminal, un deuxième module pour définir des règles correspondantes à des préférences d'usage des applications. Selon un mode de mise en oeuvre du procédé, on injecte un fichier comprenant les règles de priorité à appliquer. L'évènement est, par exemple, un appel entrant et l'application en cours est choisie parmi la liste suivante : une séquence vidéo, un jeu, l'envoi d'un message et le procédé comporte les étapes suivantes : - tester si l'application en cours est prioritaire par rapport à l'appel entrant, - si l'application en cours est prioritaire, alors ne pas mettre l'appel entrant en premier plan, - si l'application en cours n'est pas prioritaire, stopper ou ralentir l'application en cours et mettre l'appel entrant au premier plan. L'évènement peut être un évènement de réception de message ou une détection de changement d'état prédéfini tel qu'un mode veille, un mode 25 avion. D'autres caractéristiques et avantages de la présente invention apparaîtront mieux à la lecture de la description qui suit d'un exemple de réalisation donné à titre illustratif et nullement limitatif, annexé des figures qui 30 représentent : - La figure 1, un schéma illustrant une interface possible pour le terminal, - La figure 2, un schéma d'un exemple de modules permettant la mise en oeuvre de la phase de gestion des évènements, - La figure 3, un diagramme décrivant les processus de gestion des priorités, - La figure 4, une variante dans laquelle, les règles de priorité sont stockées dans un dispositif externe au terminal.

La description qui suit est donnée à titre illustratif pour un téléphone mobile de type smartphone. Le téléphone mobile 100 comporte un écran pouvant être tactile 120, des boutons de navigation et de sélection 130, un clavier mécanique ou non 140, un haut-parleur 150, des interrupteurs 160 de mise en route et d'arrêt, et tous les autres éléments que l'on trouve habituellement sur un Smartphone. Sur les figures 1 et 2 on a représenté un exemple d'interface qui va permettre à l'utilisateur de définir, pour une ou plusieurs applications, un niveau de priorité. Une application correspond à une fonctionnalité d'un téléphone mobile telle que, par exemple, la fonction téléphonie, la fonction connexion à internet, la fonction appareil photo, la fonction prise de vidéo, la fonction rédaction de message SMS (abrégé anglo-saxon de Short Message Service), etc. Le niveau de priorité P. d'une application peut être exprimé en utilisant un entier compris entre 1 et N, avec N le nombre d'applications qui sont offertes au niveau d'un terminal et d'un opérateur à un utilisateur, ou encore le nombre d'applications sélectionnées par un utilisateur. Dans l'exemple de la figure 1, l'interface IHM offre à l'utilisateur: 170 : de lancer l'étape de configuration de son téléphone, 180 : d'activer ou non le procédé de gestion des priorités selon l'invention, 190: de définir la priorité de plusieurs applications, par exemple selon un ordre de priorité décroissant, de 1 à 5, dans l'exemple : 191 : l'application mail, avec priorité 1, 192: l'application appel entrant, avec priorité 2, 193: l'application navigation web, avec priorité 3, 194: les notifications autres, avec priorité 4, 195: l'application SMS, avec priorité 5. Dans cet exemple, l'application mail est prioritaire par rapport à l'application « appel entrant », l'utilisateur sera averti d'un appel entrant sans interruption de la réception du message. A niveau de priorité équivalent, le gestionnaire des priorités fait passer en priorité l'application qui a un nouvel évènement; par exemple si l'application phonie et l'application SMS ont un même niveau de priorité, alors le SMS sera affiché ou signalé si un appel est en cours. Un autre exemple est le cas où l'utilisateur utilise son terminal pour enregistrer une vidéo et ne souhaite pas être interrompu par un événement quelconque comme un appel entrant, un message, une mise à jour logicielle, une détection de spot Wifi, etc. La configuration définie par l'utilisateur sera stockée dans une mémoire interne (262 figure 2) du téléphone, par exemple, ou pourra être 20 mémorisée au niveau d'un serveur externe, par exemple dans le cas illustré à la figure 4. La figure 2 illustre un exemple de diagramme bloc correspondant à un exemple d'architecture d'un téléphone mobile. Le téléphone mobile comporte un processeur central 210, une 25 alimentation 220, un module radio 230. Le processeur communique, par un moyen connu de l'homme du métier, avec un système audio 241, une caméra 242, une mémoire à accès rapide 243, une mémoire RAM 244, un module de communication 245 de type communication radio Bluetooth, protocole de communication Wifi, un gestionnaire de fenêtre 246. Ces 30 différents éléments et modules, leurs interactions sont connus de l'homme du métier et ne seront pas détaillés.

Le processeur central 210 va communiquer avec un module 260 spécifique à l'invention, comprenant un gestionnaire de priorité 261, un module 262 contenant les priorités associées aux applications pouvant être utilisées par l'utilisateur et la configuration de priorité retenue par ce dernier, un module de surveillance d'évènements externes et d'évènements internes 263 par exemple le niveau de batterie, un rappel calendrier en local, un niveau de batterie faible, le positionnement GPS, un module de surveillance 264 de l'application en cours de fonctionnement. Le module 260 comporte aussi un premier module 271 qui assure la présentation à l'utilisateur d'une liste des applications et des évènements disponibles ou pouvant arriver sur le terminal et un deuxième module 272 qui permet à un utilisateur de spécifier un ensemble de critères permettant de définir des règles correspondantes à des préférences d'usage des applications et aussi de les identifier.

Le gestionnaire de priorité 261 comprend, par exemple, un logiciel et des instructions pour gérer les priorités des applications et agir pour faire passer une application en premier plan ou non selon son niveau de priorité. Le gestionnaire de priorité 261 reçoit une information de la part du module de surveillance des événements externes et internes 263. On appelle événement externe, respectivement interne, un événement qui n'est pas issu d'une action volontaire de l'utilisateur, par exemple un évènement flux entrant ou respectivement un évènement interne correspondant au niveau de batterie par exemple. Lorsqu'un évènement externe ou interne est détecté, cette information contient par exemple le type correspondant à l'évènement.

Le gestionnaire de priorité 261 va interroger le module de priorité 262 afin d'obtenir le niveau de priorité Pae correspondant à un évènement. Le gestionnaire de priorité 261 interroge aussi le module 262contenant les priorités associées aux applications pour obtenir le niveau de priorité Pac de l'application en cours. A partir de ces deux valeurs P - ae, P ac, le gestionnaire 30 des priorités 261 transmet, par exemple, une commande au processeur 210 pour arrêter l'exécution de l'application en cours, ralentir son exécution, lorsque l'évènement externe est prioritaire par rapport à l'application en cours, ou bien une commande vers un module de notification d'évènements 280 afin d'avertir l'utilisateur d'un évènement externe, par exemple, un appel entrant.

L'interface Homme machine 270 permet à l'utilisateur de définir les priorités au moyen du premier module 271 et du deuxième module 272. Ce deuxième module 272 permet aussi de regrouper les règles dans un-sur ensemble de règles (SR) pouvant être lui-même identifié. La saisie de règles peut se faire par le biais de l'interface graphique utilisateur ou par l'injection 10 d'un fichier selon des méthodes connues de l'homme du métier. La solution graphique permet à l'utilisateur d'ordonner, de hiérarchiser ou de numéroter des applications et des évènements les uns par rapport aux autres. Les applications disponibles peuvent être présentées sous la forme des icônes qui permettent habituellement le lancement de ces applications. L'utilisateur 15 peut alors les déplacer pour les ordonner, il est possible d'avoir plusieurs icônes au même niveau. Une autre possibilité est de présenter les applications et de demander à l'utilisateur de saisir une information (un chiffre, par exemple) représentatif de la priorité, plusieurs applications pouvant avoir la même valeur de priorité. 20 Des règles peuvent être définies pour limiter l'usage de certaines applications dans des conditions particulières. Par exemple, en fonction du seuil de la batterie certaines applications ne pourront pas être lancées, seule la fonction SMS sera accessible. Des règles peuvent être associées à des sur-ensembles (SR) de règles, par exemple des éphémérides. Pour chaque 25 ensemble de règles, il est possible de définir des règles de planification pour leur prise en compte : la date de début/fin de prise en compte, la périodicité. Des règles liées à la localisation géographique (position GPS) peuvent être définies pour que certaines règles soient prises en compte si le terminal se trouve dans une zone géographique définie. 30 Un module 273 de type analyse syntaxique assure la transformation des différentes « règles utilisateurs » en règles formelles. Ces règles formelles sont conservées dans une zone de stockage permanente du terminal ce qui assure leur conservation lors d'une coupure de l'alimentation. Dans la solution d'injection d'un fichier sans passer par l'interface graphique utilisateur, les règles formelles peuvent être décrites dans un langage de haut niveau de type XML. Le procédé selon l'invention comprend notamment deux phases qui vont être décrites ci-après : - une première phase de configuration permet à un utilisateur de définir les priorités entre les applications qu'il souhaite utiliser, ou qui sont disponibles sur le terminal de téléphonie, - une deuxième phase de gestion d'évènements au cours de laquelle le processeur du terminal va gérer l'exécution des applications en fonction de leur niveau de priorité. Lorsqu'un évènement interne ou externe arrive au niveau du terminal, par exemple un appel entrant arrive alors qu'un utilisateur est en train de regarder une vidéo, le procédé : i) identifie l'application en premier plan, dans cet exemple la vidéo, application en cours ou utilisée par l'utilisateur, ii) vérifie les règles de priorités entre cette application en cours (la vidéo dans cet exemple) et l'appel entrant, en se basant sur les règles définies durant la phase de configuration, iii) gère le nouvel évènement : iii.1 accepte l'appel entrant et passe l'application vidéo en cours en arrière-plan, lorsque l'appel entrant est prioritaire par rapport à la consultation de la vidéo, iii.2 notifie de manière non-intrusive l'utilisateur de l'évènement nouveau sans interrompre la vidéo en cours et en la laissant en premier-plan, lorsque l'application en cours est prioritaire. L'exemple donné pour un appel entrant pourrait être appliqué à un 30 autre évènement, réception de message, en fonction des priorités données par l'utilisateur. Par exemple, le procédé peut aussi être étendu à la détection d'un changement d'état (niveau batterie, détection accès Wifi ...). L'exemple a été donné pour un utilisateur en train de visualiser une vidéo, mais pourrait aussi s'appliquer pour un utilisateur en train de jouer à un jeu vidéo, de télécharger une application, de téléphoner, de lire sa messagerie, etc. La figure 3 schématise un exemple d'enchaînement d'étapes mises en oeuvre par le procédé selon l'invention dans le cas où le nouvel évènement externe est un appel entrant.

Le module de détection détecte, 310, un nouvel appel entrant et transmet l'information au module de gestion des priorités. Le module de gestion des priorités va interroger, 311, l'application en cours et lui demander son identifiant. Le module de gestion des priorités accède ensuite, 312, à la base de données des priorités pour obtenir le niveau de priorité pour l'application en cours et l'appel entrant. Si le niveau de priorité de l'application en cours est supérieur, 314, au niveau de priorité de l'appel entrant, alors le procédé va masquer l'appel entrant et/ou l'enregistrer, 315, ou encore le notifier à l'utilisateur. Dans le cas contraire, le niveau de priorité de l'application est inférieur, 316, et le gestionnaire de priorité va demander au processeur d'interrompre l'exécution de l'application en cours et présenter l'appel entrant à l'utilisateur, 317. La notification des évènements externes ou internes non prioritaires pourra être présentée au niveau de l'interface utilisateur (écran, signal sonore, visuel, vibreur ...).

La figure 4 représente une variante de mise en oeuvre pour laquelle on utilise un moyen informatique distant 400 comprenant la liste des applications disponibles sur un terminal et un ensemble de terminaux 410. L'utilisation de la solution distante permet de définir des règles et des sur ensembles de règles distribuables sur une flotte de terminal.

Le module 420 assure la présentation à l'utilisateur de la liste des applications et événements respectivement disponibles ou pouvant arriver sur le terminal. Le module 430 permet à un utilisateur de spécifier un ensemble 5 de critères permettant de définir des règles correspondants à des préférences d'usage des applications et de les identifier. Ce module permet aussi de regrouper les règles dans sur ensemble de règles (SR) pouvant être lui-même identifié. La saisie de règles peut se faire graphiquement, par un tri, hiérarchisation, ou numérotation des applications et des évènements. Des 10 règles peuvent être associées aux sur ensembles (SR) de règles, par exemple des éphémérides Le module 440 de type analyse syntaxique assure la transformation des différentes « règles utilisateurs » en règles formelles 450. Ces règles formelles sont conservées dans une zone de stockage 15 permanente du terminal ce qui assure leur conservation lors d'une coupure de l'alimentation. Les règles formelles peuvent être décrites dans un langage de haut niveau de type XML. Les contraintes sur les règles sont mémorisées en une zone 460, l'ensemble règles formelles, contraintes forment une base de règles 470. 20 Le moyen informatique distant et le terminal peuvent communiquer grâce à un moyen approprié 480 pour échanger des règles. Les échanges peuvent être bidirectionnels entre configurateur distant et terminaux et entre terminaux. Une définition de règles établies sur un terminal peut être envoyée au moyen informatique distant ou à un autre 25 terminal. Le moyen informatique distant peu diffuser les règles à un ensemble de terminaux. Les règles peuvent disposer de limitations temporelles ou géographiques. Une règle peut être active selon une éphéméride ou une zone géographique. 30 Le procédé et le système selon l'invention permettent à un utilisateur de configurer leur terminal de téléphonie en fonction des applications qu'ils jugent comme étant prioritaires. Ainsi, un utilisateur qui aura défini que les appels téléphoniques sont prioritaires par rapport à un message de type SMS, s'il est en train d'écrire un message, verra l'application « mail » passer en arrière-plan et l'application « appel » passer en premier plan. Le procédé introduit un complément d'analyse permettant de prendre en compte les règles formelles représentatives des choix utilisateurs. Ainsi, un utilisateur qui aura défini que l'application SMS est prioritaire par rapport à l'enregistrement d'une vidéo verra son message s'afficher et l'application d'enregistrement passée au second plan.

Le terminal est capable de gérer les appels entrant en fonction de l'application en premier plan.

Claims

REVENDICATIONS1 - Dispositif comprenant au moins un terminal (100) disposant d'une application téléphonie mobile comprenant des moyens (260) adaptés pour gérer l'exécution d'applications en fonction de leur priorité, caractérisé en ce qu'il comporte au moins les éléments suivants : - une interface homme machine (270), adaptée à configurer des priorités pour des applications en fonction du besoin d'un utilisateur, - une base de données (262) comprenant les priorités associées aux applications sélectionnées par l'utilisateur, - un module de détection d'évènements externes ou internes (263) au terminal, - un module de surveillance (264) d'une application en cours sur le terminal, - un module de gestion des priorités (261) relié au module de détection (263) d'évènements et au module contenant les priorités associées aux applications (262), et aussi au processeur (210) auquel le module de gestion des priorités transmet une commande pour continuer pour arrêter l'exécution de l'application en cours, ralentir son exécution, lorsque l'évènement est prioritaire par rapport à l'application en cours, ou bien une commande vers un module de notification d'évènement (280).
2 - Dispositif selon la revendication 1 caractérisé en ce que la base de 25 données de configuration (262) est mémorisée dans le terminal.
3 - Dispositif selon l'une des revendications 1 ou 2 caractérisé en ce qu'il comporte : - un premier module (271) de présentation à l'utilisateur d'une liste des 30 applications et des évènements disponibles ou pouvant arriver sur le terminal,- un deuxième module (272) adapté à définir des règles correspondantes à des préférences d'usage des applications, - un troisième module (273) adapté à transformer les différentes « règles utilisateurs » en règles formelles.
4 - Dispositif selon la revendication 1 caractérisé en ce qu'il comporte en plus un moyen informatique (400) indépendant du terminal (100) ou d'un ensemble de terminaux (410) et communiquant avec ledit terminal ou ledit ensemble de terminaux à l'aide d'un moyen de communication (480) et en ce que le moyen informatique (400) comprend : - un module (420) de présentation à l'utilisateur d'une liste d'applications et événements respectivement disponibles ou pouvant arriver sur le terminal, - un module (430) pour définir des règles correspondantes à des préférences d'usage des applications, - un module (440) d'analyse syntaxique pour obtenir des règles formelles (450), - une base de règles formelles (470).
5 - Dispositif selon la revendication 1 caractérisé en ce qu'il comporte un module adapté à injecter un fichier comportant une configuration de priorités pour différentes applications.
6 - Dispositif selon l'une des revendications 1 à 5 caractérisé en ce que le terminal est un téléphone mobile et les applications sont choisies parmi la liste suivante : acquisition ou visualisation de vidéo, communication phonie, transfert de données, jeux, navigation internet.
7 - Procédé de gestion d'applications fonctionnant au niveau d'un dispositif 30 selon l'une des revendications 1 à 6 caractérisé en ce qu'il comporte au moins les étapes suivantes :- une phase de configuration du terminal dans laquelle un utilisateur définit un ensemble de règles composées de couples application, niveau de priorité, - une phase de gestion d'évènements où l'on compare le niveau de priorité d'une application en cours d'exécution sur le terminal et le niveau de priorité d'un évènement externe ou interne au terminal, et l'on décide : - si l'application en cours présente un niveau de priorité supérieur à celui de l'évènement, alors l'activité en cours continue d'être exécutée et on notifie l'évènement, - sinon, on suspend l'exécution de l'application ou on passe l'application en second plan et on passe l'évènement en premier plan.
8 - Procédé selon la revendication 7 caractérisé en ce que l'utilisateur définit des règles de niveau de priorité en utilisant une interface comprenant un premier module (271) de présentation à l'utilisateur d'une liste des applications et des évènements disponibles ou pouvant arriver sur le terminal, un deuxième module (272) pour définir des règles correspondantes à des préférences d'usage des applications.
9 - Procédé selon la revendication 7 caractérisé en ce que l'on injecte un fichier comprenant les règles de priorité à appliquer.
10 - Procédé selon l'une des revendications 7 à 9 caractérisé en ce que l'évènement est un appel entrant et l'application en cours est choisie parmi la liste suivante : une séquence vidéo, un jeu, l'envoi d'un message et en ce qu'il comporte les étapes suivantes : - tester si l'application en cours est prioritaire par rapport à l'appel entrant, - si oui, alors ne pas mettre l'appel entrant en premier plan,- si non, stopper ou ralentir l'application en cours et mettre l'appel entrant au premier plan.
11 - Procédé selon l'une des revendications 7 à 9 caractérisé en ce que 5 l'évènement est un évènement de réception de message ou une détection de changement d'état prédéfini tel que un mode veille, un mode avion.