FR3027759A1 - Methode de filtrage de messages pour fournir une fonction de type " ne pas deranger " - Google Patents

Abstract

La présente invention concerne une méthode de filtrage de messages émis par un premier terminal à destination d'un deuxième terminal, le premier terminal étant associé à un premier identifiant, les terminaux étant connectés via au moins un réseau de communication, le réseau de communication comprenant un serveur connecté à une base de données, la base de données comprenant au moins une première liste prédéfinie d'identifiants, le serveur exécutant les étapes suivantes de réception d'un premier message émis par le premier terminal à destination du deuxième terminal, d'enregistrement du premier message dans la base de données, d'émission d'un deuxième message à destination du premier terminal, le deuxième message comprenant un champ émetteur égal à un deuxième ou troisième identifiant selon l'appartenance du premier identifiant la première liste ou non.

Description

METHODE DE FILTRAGE DE MESSAGES POUR FOURNIR UNE FONCTION DE TYPE « NE PAS DERANGER » DOMAINE TECHNIQUE AUQUEL SE RAPPORTE L'INVENTION La présente invention concerne de manière générale le domaine des systèmes de communications, et plus précisément la fourniture d'un service de type « ne pas déranger ».

ARRIERE-PLAN TECHNOLOGIQUE Le développement important des terminaux mobiles tels que les téléphones portables, « smartphones », tablettes, terminaux de radiomessagerie (pagers en anglais) s'accompagne d'une intensification de leurs utilisations. Ces terminaux offrent aujourd'hui une connectivité quasi permanente à leurs utilisateurs qui peuvent être joints à tout moment. Les appels téléphoniques, messages ou notifications divers peuvent alors devenir très fréquents et certains utilisateurs peuvent être gênés, qualifiant l'usage de ces terminaux d'envahissant.

Une solution simple est bien évidemment d'éteindre ces terminaux, mais cela n'est pas toujours souhaitable car on se prive alors totalement de toute possibilité d'être joint, et ce même pour une éventuelle urgence. De même, mettre en mode « avion » (c'est-à-dire déconnecté du réseau de communication), ou en mode « silence », ces terminaux ne permet pas de conserver la possibilité d'être joint en cas d'urgence, l'utilisateur n'étant plus notifié des appels reçus. Ces méthodes sont efficaces pour ne plus être dérangé, mais elles présentent l'inconvénient de n'offrir aucune adaptabilité pour être joint en cas d'éventuelle urgence. Des méthodes ou services ont donc été développés pour limiter l'intrusion de ces terminaux, sans pour autant se priver totalement de la possibilité d'être joint en cas de besoin. Il s'agit de service de type « ne pas déranger » (ou « do not disturb » en anglais). Un service de ce type est décrit dans le brevet français FR9714784. Ce document décrit un système permettant à un opérateur téléphonique d'offrir à ses utilisateurs d'activer à leurs demandes un service de type « ne pas déranger ». Si un utilisateur active le service, alors les futurs appels à destination de cet utilisateur sont interceptés - ou filtrés - par l'opérateur, qui informe l'appelant par un message vocal que l'utilisateur ne souhaite pas être dérangé. L'appelant conserve toutefois la possibilité de passer outre le filtrage - via une séquence à taper sur les touches de son téléphone - et de voir malgré tout son appel transmis à l'utilisateur. Le système repose donc sur la seule décision de l'appelant, qui reste seul juge de l'urgence ou de l'opportunité de déranger l'utilisateur. Le brevet américain US 5,467,388 décrit un système permettant d'offrir un blocage sélectif des appels, ce qui permet d'offrir un service de type « ne pas déranger ». Le service offre à un utilisateur la possibilité de configurer une liste de contacts privilégiés (« liste blanche »). Lorsque l'utilisateur active le service « ne pas déranger'>, les appels provenant des contacts appartenant à la liste blanche sont transmis. Inversement, les autres appels sont bloqués. L'utilisateur peut aussi définir des codes d'accès. Un appelant devra alors fournir un code d'accès correct pour être mis en contact avec l'utilisateur.

L'utilisateur gagne donc un certain contrôle sur qui peut le déranger via la constitution de la liste blanche ou la possibilité de fournir des codes d'accès à certaines personnes. La demande de brevet internationale W00161978 décrit un autre système permettant d'offrir un service de type « ne pas déranger ». Dans ce système, l'utilisateur peut la aussi configurer un code d'accès, code qui sera demandé à tout appelant lorsque le service « ne pas déranger » est actif. Si l'appelant fournit le bon code, son appel sera dirigé vers l'utilisateur. Autrement, l'appel sera redirigé vers une messagerie vocale. Les solutions précédentes, reposant sur des listes blanches ou des codes d'accès présentent l'inconvénient de ne pas savoir gérer le cas d'un appel urgent provenant d'un appelant inconnu (qui ne peut donc avoir été préalablement inclus dans une liste blanche, ou à qui un code d'accès ne peut avoir été préalablement fourni). Les cas imprévisibles sont donc par défaut tous filtrés et ce alors même qu'ils peuvent parfois présenter un caractère d'urgence. Les solutions permettant de fournir un service de type « ne pas déranger » précédemment décrites sont de plus destinées à des communications de type appels vocaux et ne sont pas adaptées à des communications par messages de type messages courts (Short Message Service - SMS ou Multimedia Messaging Service - MMS par exemple). Il existe donc aujourd'hui un besoin pour une solution permettant d'offrir un service de type « ne pas déranger », solution capable de gérer le cas de messages imprévisibles.

OBJET DE L'INVENTION L'invention propose de remédier aux inconvénients précédemment discutés en proposant une méthode de filtrage de messages émis par un premier terminal, identifié par un premier identifiant, à destination d'un deuxième terminal, les terminaux étant connectés via au moins un réseau de communication, le réseau de communication comprenant un serveur connecté à une base de données, la base de données comprenant au moins une première liste prédéfinie d'identifiants, le serveur exécutant les étapes suivantes : recevoir un premier message émis par le premier terminal à destination du deuxième terminal, enregistrer le premier message dans la base de données, déterminer si le premier identifiant appartient à la première liste, et, si oui, émettre un deuxième message à destination du premier terminal, le deuxième message comprenant un champ émetteur égal à un deuxième identifiant, ou, si non, émettre un deuxième message à destination du premier terminal, le deuxième message comprenant un champ émetteur égal à un troisième identifiant. Avantageusement, il est donc possible d'intercepter et d'enregistrer un premier message à destination du deuxième terminal. L'utilisateur du deuxième terminal ne sera donc pas dérangé par la réception du premier message sur le deuxième terminal, le premier message n'étant pas reçu par le deuxième terminal mais intercepté et enregistré par le serveur. En effet, la réception d'un message sur un terminal s'accompagne souvent d'une sonnerie, vibration et/ou effet visuel sur l'écran du terminal qui peuvent être considérés comme dérangeant à certains moments par l'utilisateur d'un terminal. Le deuxième message permet d'avertir le premier terminal de l'interception du premier message, et donc de sa non délivrance au deuxième terminal. Selon l'appartenance ou non du premier identifiant - typiquement un numéro de téléphone - à la première liste, l'identifiant de l'émetteur du deuxième message sera différent. Il correspondra à un deuxième identifiant si le premier identifiant appartient à la première liste ou à un troisième identifiant sinon. Cela permet d'offrir un service différencié à l'utilisateur du premier terminal suivant que son terminal soit identifié comme appartenant à la première liste ou non. En effet, en réponse au deuxième message, si l'utilisateur du premier terminal choisit de répondre à ce deuxième message, il répondra donc par l'envoi d'un message à un identifiant qui diffèrera selon les cas. L'utilisateur du deuxième terminal peut donc, par l'utilisation de la première liste d'identifiants - c'est à dire par exemple d'une première liste de numéros de téléphone dans un contexte GSM/UMTS -, choisir une réponse différenciée pour les différents utilisateurs. Ces utilisateurs sont identifiés par leurs numéros de téléphone, en mettant par exemple les numéros correspondants aux terminaux d'utilisateurs connus ou prioritaires dans la première liste. Ces utilisateurs recevront donc un deuxième message avec comme identifiant d'émetteur le deuxième identifiant. Selon un mode de réalisation complémentaire de la présente invention, la méthode comprend les étapes ultérieures suivantes de réception d'un troisième message émis par le deuxième terminal de demande de désactivation du service de filtrage fourni par la présente méthode et d'envoi au deuxième terminal des messages enregistrés dans la base de données et qui lui sont destinés.

Avantageusement, l'utilisateur du deuxième terminal peut donc désactiver le service de filtrage de messages selon la présente demande par l'envoi d'un troisième message. Le traitement des messages émis à destination du deuxième terminal se fera alors normalement, c'est-à-dire sans interception ou enregistrement, une fois le service désactivé. Tous les messages éventuellement reçus par le serveur à destination du deuxième terminal et enregistrés dans la base de données sont alors émis à destination du deuxième terminal. Cela permet donc de temporiser la réception de message durant la période d'activité du service de filtrage, les messages enregistrés étant seulement délivrés quand l'utilisateur du deuxième terminal désactive le service, mettant fin de fait à la période de « ne pas déranger'>. Il reçoit alors tout message qui lui aurait été adressé pendant la période de « ne pas déranger » et qui aurait été intercepté et enregistré par le serveur. Selon un autre mode de réalisation complémentaire, la méthode comprend les étapes ultérieures suivantes de réception d'un quatrième message émis par le premier terminal, le champ destinataire du quatrième message comprenant un quatrième identifiant, et, si le quatrième identifiant est égal au deuxième identifiant ou bien si le quatrième identifiant est égal au troisième identifiant, alors un message enregistré est retrouvé dans la base de données et est émis à destination du deuxième terminal, ou, si non, le quatrième message est ignoré.

L'utilisateur du premier terminal, après avoir reçu en réponse à son premier message un deuxième message, peut débloquer l'envoi de son premier message par l'envoi d'un quatrième message, quatrième message qui a comme identifiant de destination l'identifiant correspondant au champ émetteur du deuxième message qu'il a reçu en retour du premier message envoyé. Le premier message est ainsi débloqué, c'est-à-dire qu'il est retrouvé dans la base de données et émis vers son destinataire, c'est-à-dire le deuxième terminal. Cette méthode permet avantageusement de fournir un service « ne pas déranger » au deuxième terminal tout en préservant la possibilité d'un cas imprévisible. En effet, tout utilisateur du premier terminal qui envoie un premier message au deuxième terminal reçoit en retour un deuxième message, qu'il soit préalablement connu ou non, ou autrement dit, qu'il soit préalablement identifié dans une première liste ou non. Cet utilisateur du premier terminal garde donc la possibilité de répondre au deuxième message - en connaissance de cause - pour débloquer la délivrance d'un premier message enregistré. L'utilisateur du premier terminal est donc averti du statut « ne pas déranger » du deuxième terminal par le deuxième message, et, selon son propre jugement sur l'opportunité de malgré tout déranger le deuxième utilisateur, peut débloquer la délivrance du premier message. La délivrance du premier message enregistré se fera par un cinquième message destiné au deuxième terminal. La possibilité reste donc ouverte de joindre un deuxième terminal malgré le statut « ne pas déranger ». Selon un mode de réalisation complémentaire, le message retrouvé est le dernier des messages enregistrés, émis par le premier terminal et à destination du deuxième terminal, la méthode comprenant une étape ultérieure de suppression de ce message retrouvé de la base de données après son émission vers le deuxième terminal. Avantageusement, le serveur envoie le dernier premier message émis par le premier terminal à avoir été enregistré en réponse à un quatrième message reçu de ce même terminal, sur un principe comparable à un fonctionnement « premier arrivé, premier sorti ». Selon un autre mode de réalisation alternatif, le deuxième message comprend une première référence permettant d'identifier le premier message enregistré dans la base de données, le quatrième message comprend une seconde référence correspondant à la première référence et le message émis vers le deuxième terminal est retrouvé dans la base de données grâce à la seconde référence. Avantageusement, cela permet à un premier utilisateur qui a envoyé plusieurs premiers messages de sélectionner le premier message à débloquer - c'est-à-dire à retrouver puis à envoyer au deuxième terminal. La sélection se fait par l'indication dans le quatrième message d'une référence, cette référence ayant été fournie dans le deuxième message. Les premiers messages enregistrés ne sont donc pas débloqués selon un mode « premier arrivé, premier sorti » mais selon une sélection par le premier utilisateur, sélection faite grâce à la première référence fournie dans le deuxième message. Selon un mode de réalisation complémentaire, la base de données comprend une deuxième liste prédéfinie d'identifiants, la méthode comprenant de plus les étapes suivantes après la réception du premier message : déterminer si le premier identifiant appartient à la deuxième liste et, si oui, transmettre le premier message au deuxième terminal sans émettre le deuxième message. Avantageusement, les premiers messages reçus d'un terminal dont l'identifiant appartient à la deuxième liste sont directement transmis au deuxième terminal, et ce alors même que le service « ne pas déranger » est actif pour ce deuxième terminal. Cela est particulièrement avantageux si les identifiants de la deuxième liste sont des identifiants particuliers tels que des identifiants correspondant à des services d'urgences (pompiers, hôpitaux, sécurité civile, ...) ou à certains identifiants préalablement identifiés par l'utilisateur du deuxième terminal, les messages provenant de ces identifiants ne devant pas être filtrés. Selon un mode de réalisation complémentaire, la base de données comprend une troisième liste prédéfinie d'identifiants, la méthode comprenant de plus les étapes suivantes après la réception du premier message : déterminer si le premier identifiant appartient à la troisième liste prédéfinie, et, si oui, enregistrer le premier message dans la base de données sans émettre le deuxième message.

Au contraire du précédent mode de réalisation, mais de manière complémentaire, ce mode de réalisation permet d'enregistrer directement - sans envoi d'un deuxième message en retour - un premier message reçu d'un terminal dont l'identifiant appartient à une troisième liste prédéfinie. La possibilité de déblocage par l'envoi d'un quatrième message n'est donc pas proposée au premier terminal. Cela est particulièrement avantageux s'agissant d'identifiants correspondants à des terminaux de type « automates » ou « serveurs d'envoi automatique de messages ». En effet, ces automates sont incapables de traiter un deuxième message, et il est donc inutile d'encombrer les réseaux de communications avec des deuxièmes messages qui leur seraient destinés. De plus, ces automates répondent souvent aux messages qui leur sont adressés par un message automatique précisant leur qualité d'automate et informant que le message ne sera pas lu ni traité car adressé à un automate. On pourrait donc se retrouver dans une situation où l'automate et le serveur rentrent dans une boucle perpétuelle d'envoi de messages réciproques. On pourrait aussi se retrouver dans une situation où la réponse automatique d'un automate à un deuxième message correspondant à un quatrième message, tout premier message envoyé par un automate serait donc automatiquement - sans étape de validation par un premier utilisateur capable d'évaluer l'urgence ou l'opportunité de déranger le deuxième utilisateur - débloqué vers le deuxième terminal. Autrement dit, tout automate court-circuiterait le service « ne pas déranger » automatiquement. Le fait de placer les identifiants correspondant à des automates dans la troisième liste permet de pallier à cela. Les messages envoyés par ces automates ne seront donc automatiquement délivrés que lorsque le deuxième utilisateur désactivera le service « ne pas déranger ». A noter que des identifiants correspondant à des automates peuvent aussi être placés dans la deuxième liste, s'agissant par exemple d'un automate correspondant à un service d'urgence.

Selon un mode de réalisation complémentaire, l'un au moins des deuxième et troisième identifiants correspond à un numéro de service à valeur ajoutée.

Avantageusement, le deuxième identifiant, le troisième identifiant, ou les deux identifiants, correspondent à des numéros de service à valeurs ajoutées, autrement appelés « numéros surtaxés ». Cela engendre un effet dissuasif car il y a alors un véritable coût à déranger le deuxième utilisateur, coût qui se matérialise par l'envoi du quatrième message à un numéro de service à valeur ajoutée. En choisissant un numéro de service à valeur ajoutée de coût plus faible pour le deuxième identifiant que pour le troisième identifiant, voire de coût nul, l'utilisateur du deuxième terminal peut favoriser les utilisateurs dont les identifiants sont compris dans la première liste prédéfinie. Au contraire, les utilisateurs de terminaux dont les identifiants ne sont pas compris dans la première liste prédéfinie peuvent se voir appliquer un coût de déblocage de leurs premiers messages fortement dissuasif en fixant un coût important pour le numéro de service à valeur ajoutée correspondant au troisième identifiant. Selon un mode de réalisation complémentaire, les messages sont de type message court. Selon un autre mode de réalisation complémentaire, un message comprend au moins un message de type court.

Avantageusement, la méthode s'applique à l'échange de messages courts de type SMS (Short Message Service) ou MMS (Multimedia Messaging Service) entre différents terminaux. Un même message SMS peut comprendre de fait plusieurs SMS du fait de la limite technique à 160 caractères (selon l'encodage) pour un unique SMS.

L'invention propose aussi un serveur mettant en oeuvre la méthode de filtrage de messages selon les différents modes de réalisation précédemment décrits. Ce serveur peut être en partie le deuxième terminal. Dit autrement, la méthode peut directement être exécutée en partie et localement par le deuxième terminal. L'interception d'un message peut se comprendre alors par sa non présentation à l'utilisateur par le deuxième terminal, ou une présentation plus discrète. Par exemple, pour un deuxième terminal comprenant un mode de présentation des messages dit « normal » et un autre dit « discret », les premiers messages seront présentés selon le mode « discret » (respectivement non présentés) quand les cinquième messages, correspondants à des premiers messages débloqués, seront présentés selon le mode « normal » (respectivement en mode « discret »).

La méthode permettant le filtrage de messages émis par un premier terminal à destination d'un deuxième terminal selon l'invention peut être mise en oeuvre sous forme d'un programme d'ordinateur, ce programme étant exécuté par exemple par un ou plusieurs processeurs d'un serveur connecté à une base de données et à au moins un réseau de communication. Par conséquent, selon un dernier aspect, la présente invention a pour objet un programme d'ordinateur comportant des instructions de programme pour la mise en oeuvre de tout ou partie des étapes de la méthode permettant le filtrage de messages émis par un premier terminal à destination d'un deuxième terminal, lorsque ce programme est exécuté par un processeur. Par ailleurs, un programme d'ordinateur selon l'invention peut utiliser n'importe quel langage de programmation, et être sous 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 souhaitable. L'invention vise aussi par conséquent un support d'enregistrement d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur selon l'invention. Un tel support d'enregistrement peut être constitué par n'importe quelle entité ou dispositif capable de stocker un tel programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une mémoire de type ROM (Read Only Memory), par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement amovible tel qu'une clef USB ou un moyen d'enregistrement magnétique, tel qu'un disque dur. D'autre part, un programme ou module logiciel selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Les avantages procurés par un programme d'ordinateur, tel que brièvement défini plus haut, sont identiques ou contribuent à ceux mentionnés plus haut en relation avec la méthode permettant le filtrage d'un message émis par un premier terminal à destination d'un deuxième terminal, et ne seront donc pas rappelés ici. DESCRIPTION DES FIGURES FIG. 1A représente un serveur permettant la mise en oeuvre de la méthode conformément à un mode de réalisation de l'invention, FIG. 1B est une représentation schématique d'un système conforme à un mode de réalisation de l'invention, FIG. 2 est un organigramme illustrant la mise en oeuvre de l'invention selon un mode de réalisation de l'invention.

DESCRIPTION DÉTAILLÉE La FIG. 1A représente un serveur permettant la mise en oeuvre de la méthode conformément à un mode de réalisation de l'invention. Le serveur 100 peut comprendre un processeur 101, un module réseau 102, un espace de stockage de données 103 et de la mémoire type RAM (Random Acess Memory) 104. Le serveur 100 correspond dans cet exemple à un équipement physique, c'est-à-dire un dispositif informatique matériel. Le processeur 101 peut comporter un ou plusieurs coeurs, ou peut correspondre à plusieurs processeurs. Le module réseau 102 fournit les moyens de connexions à au moins un réseau de communication. Le serveur 100 ayant vocation à être intégré dans un réseau de communication, la technologie utilisée par le module réseau 102 peut varier suivant la technologie employée dans le réseau de communication. Le module réseau peut par exemple comporter une prise de type « Ethernet » et offrir une connectivité IP (Internet Protocol) au serveur 100. Le module réseau 102 permet donc au serveur 100 de recevoir et d'envoyer (ou émettre) des messages via le réseau de communication. L'espace de stockage de données 103 peut correspondre à des disques durs physiques ou virtuels, accessibles localement ou via le module réseau 102. L'espace de stockage 103 permet au serveur 100 de créer, modifier, gérer des bases de données, et donc d'enregistrer des données, par exemple des messages, dans une base de données. Ces bases de données peuvent être partagées avec d'autres serveurs, c'est à dire créer, gérer ou accessibles depuis d'autres serveurs.

De façon à simplifier la description de la présente invention, la référence 103 sera utilisée ci-après comme désignant une base de données connectée au serveur 100. Cette base de données 103 peut donc être locale, c'est-à-dire comprise dans l'espace de stockage du serveur 100, ou distante, c'est-à-dire comprise dans un autre serveur ou pluralité de serveurs. Le serveur 100 peut donc enregistrer dans la base de données 103 des messages reçus via le module réseau 102. Le serveur 100 peut aussi retrouver dans la base de données 103 des messages enregistrés et émettre ces messages via le module réseau 102. Le serveur 100 peut aussi enregistrer ou retrouver dans la base de données 103 des listes d'identifiants. Le serveur 100, via le processeur 101 peut ainsi déterminer si un identifiant d'un message reçu via le module réseau 102 appartient à une liste d'identifiant. Selon les implémentations, le serveur 100 peut alternativement être implémenté en tant que machine virtuelle d'un serveur de virtualisation ou voir ses fonctions être intégrées à un autre serveur fournissant d'autres applications ou fonctions.

La FIG. 1B est une représentation schématique d'un système conforme à un mode de réalisation de l'invention. Sont représentés sur cette figure, un premier terminal 110 connecté à un réseau de communication 150 et un deuxième terminal 120 connecté à un réseau de communication 160. Le réseau de communication 160 est possiblement le même que le réseau de communication 150. Le serveur 100 est ici représenté comme compris dans le réseau de communication 160. Le serveur 100 peut aussi être un dispositif physique indépendant du réseau de communication 160 et connecté à celui-ci. Le serveur 100 peut aussi voir ses fonctions et capacités intégrés à un autre serveur fournissant déjà d'autres services pour le réseau de communication 160. Ces réseaux de communications 150 et 160 sont typiquement des réseaux de type GSM/UMTS, les terminaux 110 et 120 étant des terminaux de type téléphones mobiles, tablettes, smartphones, ... Dans ce contexte de réseaux de communications 150 et 160 de type GSM/UMTS, les identifiants associés aux terminaux 110 et 120 sont aussi appelés numéros de téléphones (ou « numéros »). Les terminaux 110 et 120 sont donc susceptibles d'établir tout type de communication comme il est connu pour des réseaux de communication GSM/UMTS. Par exemple, les terminaux 110 et 120 sont susceptibles de s'échanger des messages de type message court, aussi appelés SMS (Short Message Service). Un unique SMS ayant une taille limitée à 160 caractères (selon l'encodage), un message comportant un texte de longueur supérieure à cette limite peut donc être composé de plusieurs SMS concaténés. Dans l'implémentation de la présente invention illustrée en FIG. 1B, le serveur 100 est compris dans le réseau de communication 160. Dans un mode de réalisation alternatif, le serveur 100 peut être compris dans le réseau de communication 150 ou dans un autre réseau de communication non représenté sur cette FIG. 1B. Cela sera particulièrement le cas si le terminal 120 est en situation d'itinérance (« roaming »), c'est-à-dire qu'il n'est pas connecté à son réseau de communication habituel. Dans un mode de réalisation alternatif, toutes les fonctions - ou seulement certaines fonctions - du serveur 100 sont intégrées à un serveur fournissant d'autres services. En particulier, dans un mode de réalisation, les fonctions du serveur 100- ou seulement certaines fonctions - sont réalisées par le terminal 120. FIG. 2 est un organigramme illustrant la mise en oeuvre de l'invention selon un mode de réalisation. Cette figure décrit différents échanges de messages selon une implémentation de la méthode proposée de filtrage de messages émis par le terminal 110 à destination du terminal 120. Cette méthode de filtrage permet de fournir à l'utilisateur du terminal 120 un service de type « ne pas déranger » (appelé aussi « DND » pour « do flot disturb »). Selon le mode de réalisation illustré dans la FIG. 2, le serveur 100 est conforme au serveur 100 précédemment décrit. Par souci de simplicité de la description de la FIG. 2, les terminaux 110 et 120 ainsi que le serveur 100 seront considérés comme compris dans un même réseau de communication, par exemple de type GSM/UMTS, sans que cela ne soit en aucune façon limitant. Dans un état initial, le fonctionnement des terminaux 110 et 120 est conforme au fonctionnement classique de terminaux de type GSM. En particulier, ces terminaux peuvent s'échanger des messages courts de type SMS. Un message émis par le terminal 110 sera donc transmis par le réseau de communication et reçu par le terminal 120, qui signalera la réception de ce message en vibrant, sonnant ou affichant une notification, gênant potentiellement l'utilisateur du terminal 120. L'utilisateur du terminal 120 qui souhaite limiter ces perturbations peut donc activer un service de type « ne pas déranger », service qui sera fourni par la mise en place de la méthode de filtrage décrite dans ce document. Selon un mode de réalisation, l'utilisateur du terminal 120 souhaitant utiliser le service « ne pas déranger » peut devoir installer une application sur son terminal 120 pour utiliser le service. L'installation de l'application se fera selon le processus habituel et connu, par exemple en allant récupérer cette application sur une boutique d'application telle Play de Google, l'App Store d'Apple ou le Windows Phone Store de Windows, pour ne citer que les principales boutiques utilisées aujourd'hui. Alternativement, l'application sera préinstallée sur le terminal 120 par l'opérateur du réseau de communication ou le fabricant du terminal 120, voire directement intégrée à l'OS (Operating System) du terminal. L'utilisateur du terminal 120 pourra aussi aller récupérer l'application sur un site d'un opérateur de réseau de communication. Comme il sera détaillé plus loin, une fonction de l'application est en particulier de pouvoir activer ou désactiver le service « ne pas déranger », ladite activation ou désactivation se faisant en envoyant un message au serveur 100. Ce message peut être de tout type, en particulier SMS ou USSD (Unstructed Supplementary Service Data). De façon plus générale, les messages échangés entre le deuxième terminal 120 et le serveur 100 peuvent être de tout type, par exemple USSD ou des messages de données transmis par une technologie IP (Internet Protocol).

Selon un mode de réalisation complémentaire, l'utilisateur du terminal 120 n'a pas besoin d'installer ou d'utiliser d'application particulière et peut activer le service en communiquant avec le serveur 100 par tout type de méthode. L'utilisateur peut en effet directement envoyer des messages de type SMS ou USSD sans devoir passer par une application particulière. L'utilisateur peut aussi accéder au service, c'est-à-dire l'activer, le désactiver ou le configurer, via une interface web. Le serveur 100 peut héberger ou non le serveur web permettant la configuration du service. Selon un mode de réalisation particulier, l'installation d'une application sera obligatoire sur le terminal 120, l'application pouvant comporter des mécanismes d'authentification permettant de communiquer de façon sécurisée avec le serveur 100 fournissant le service de filtrage de messages.

Ainsi, lors d'une première étape 202, le service de filtrage de message à destination du terminal 120 est activé. Dans un mode de réalisation, l'activation du service est déclenchée par la réception d'un message 201 émis par le terminal 120. Le serveur 100 reçoit donc un message 201 émis par le deuxième terminal d'activation du service. Selon un mode de réalisation alternatif, le message 201 peut être émis par un autre équipement et comporte un identifiant du terminal 120. Le message 201 peut comporter une ou plusieurs instructions de demande d'activation du service de filtrage. Lors de l'activation du service pour le terminal 120, le serveur 100 retrouve dans la base données 103 une ou plusieurs listes prédéterminées associées au terminal 120. Ces listes comprennent des identifiants et permettent donc de personnaliser le filtrage des messages émis à destination du terminal 120 selon l'identifiant de l'émetteur des messages. Alternativement, des listes peuvent être comprises dans le message d'activation reçu. Des listes peuvent aussi être retrouvées sur un autre serveur distant, par exemple un serveur opéré par le fournisseur du service « ne pas déranger ». Une première liste d'identifiant, dite « liste verte » peut ainsi être constituée. La constitution de cette liste verte peut être faite par l'utilisateur du terminal 120 ou par l'opérateur du service « ne pas déranger ». L'intérêt de cette liste est de définir des identifiants pour lesquels la remise des messages au terminal 120 sera immédiate. En effet, si le serveur 100 détermine qu'un identifiant de l'émetteur d'un message à destination du terminal 120 appartient à la liste verte, alors ce message sera transmis directement au terminal 120 sans exécution des étapes ultérieures de la méthode de filtrage. Dit autrement, ces messages en provenance d'identifiants de la liste verte ne sont pas filtrés. Cette liste verte correspond donc à des identifiants de service d'urgence (pompiers, ...) ou à des identifiants ajoutés par l'utilisateur du terminal 120 selon ses besoins. L'utilisateur du terminal 120 garde donc la possibilité d'ajouter des identifiants pour lesquels le filtrage ne sera pas réalisé et ce même lorsque le service « ne pas déranger » est actif. La partie de la liste correspond à des identifiants de service d'urgence peut être commune à tous les utilisateurs du service « ne pas déranger ».

Une autre liste d'identifiants, dite « liste grise », peut aussi être constituée. Cette liste grise peut comprendre des identifiants type « numéros courts » ou « surtaxés », ou plus généralement des identifiants correspondants à des services. Cette première source d'identifiants pour la liste grise peut être constituée par l'opérateur du service « ne pas déranger'>, par l'utilisateur du terminal 120, ou par l'opérateur de service et l'utilisateur du terminal 120. Une deuxième source d'identifiants pour cette liste est l'utilisateur du terminal 120 qui peut ajouter des identifiants à sa convenance. Cette liste a pour vocation de déterminer des identifiants pour lesquels la méthode de filtrage sera partiellement réalisée. Comme on le verra plus loin dans cette description, les messages provenant de ces identifiants seront enregistrés par le serveur 100 dans la base de données 103 sans que ne soit émis un message 207 en retour. Ces messages ne seront délivrés que lorsque l'utilisateur du terminal 120 désactivera le service « ne pas déranger ».

La partie de la liste grise correspond à des identifiants de service type « numéros courts » ou « surtaxés » peut être commune à tous les utilisateurs du service « ne pas déranger ». Une ou plusieurs autres listes d'identifiants, dites « listes blanches », peuvent être définies. Ces listes blanches sont a priori constituées par l'utilisateur du terminal 120 et correspondent à des identifiants que l'utilisateur du terminal 120 souhaite prioriser. Un identifiant différent NUM i peut être associé à chaque liste blanche i. Toutes ces listes sont enregistrées dans la base de données 103 en association avec l'identifiant NUM 120 du terminal 120. Possiblement, tout ou partie de ces listes sont communes à un ou plusieurs utilisateurs du service « ne pas déranger ». Ainsi, à réception du message 201 d'activation du service « ne pas déranger » par le serveur 100, une ou plusieurs listes prédéterminées, par exemple de type verte, grise ou blanche, associées au terminal 120 sont obtenues de la base de données 103. La méthode de filtrage permettant la fourniture d'un service « ne pas déranger » est alors démarrée et s'appliquera aux messages à destination du terminal 120 émis ultérieurement. Cette phase d'activation du service peut comprendre une phase de modification du routage des messages à destination du terminal 120 au sein du réseau de communication 160 afin que suite à l'activation du service tous les messages à destination de ce terminal 120 transitent par le serveur 100. Alternativement, comme décrit ci-après, l'étape de détermination de l'appartenance de l'identifiant du champ émetteur (ci-après, identifiant de l'émetteur) d'un message à destination du terminal 120 à une des listes prédéfinies peut être effectuée par un autre équipement du réseau de communication 160, seuls les messages demandant un traitement particulier (enregistrement par exemple) transitant ensuite par le serveur 100. Dit autrement, la détermination de l'appartenance de l'identifiant de l'émetteur d'un message à la liste verte peut être effectuée sur un serveur autre que le serveur 100. Suite à l'étape 202, le service « ne pas déranger » est donc actif pour le terminal 120. Selon un mode de réalisation, un message 203 de confirmation de la bonne activation du service est envoyé au terminal 120.

L'étape 206 correspond à la réception par le serveur 100 d'un message 205 émis par un terminal 110 à destination du terminal 120, l'identifiant associé au terminal 110 étant NUM 110. Dans l'hypothèse où la vérification de l'appartenance de NUM 110 à la liste verte associée au terminal 120 n'a pas été effectuée précédemment par un autre serveur, il sera alors déterminé si NUM 110 appartient à la liste verte. Si c'est le cas, alors, comme vu précédemment, le message 205 sera directement transmis au terminal 120 sans émettre le deuxième message 207.

De même, s'il est déterminé que NUM 110 appartient à la liste grise associée au terminal 120, alors, comme vu précédemment, le message 205 sera enregistré dans la base de données 103 sans émettre le deuxième message 207. Ces messages émis par un terminal 110 dont l'identifiant appartient à une liste grise et enregistrés dans la base de données 103 seront envoyés au terminal 120 à la désactivation du service. Dans les autres cas, le message 205 est enregistré dans la base de données 103. Le serveur 100 détermine ensuite l'appartenance de NUM 110 à une liste prédéfinie associée au terminal 120. Si NUM 110 appartient à une liste, par exemple une liste blanche i, alors le serveur envoie un message 207 au terminal 110, le message 207 ayant pour identifiant d'émetteur le NUM i associée à la liste blanche. Dit autrement, le message 207 comprend un champ émetteur égal à l'identifiant NUM i. Si NUM 110 n'appartient pas à une liste prédéfinie d'identifiants, alors le serveur 100 envoie un message 207 au terminal 100, le message 207 ayant pour identifiant d'émetteur un identifiant NUM d. Dit autrement, le message 207 comprend un champ émetteur égal à l'identifiant NUM d. Le message 207 comprend un texte informant l'utilisateur du terminal 110 que son message 205 n'a pas été remis à son correspondant car celui-ci a activé le service « ne pas déranger'>. L'utilisateur du terminal 110 est donc informé que l'utilisateur du terminal 120 ne souhaite pas être dérangé. Toutefois, si l'utilisateur du terminal 110 souhaite malgré tout déranger l'utilisateur du terminal 120 et forcer l'envoi de son message 205 au terminal 120, la méthode de la présente invention permet cela comme détaillé ci-après. L'évaluation de l'urgence de la situation repose donc à la fois sur l'utilisateur du terminal 120 par la définition des listes prédéfinies, mais aussi sur l'utilisateur du terminal 110 qui décidera seul de l'opportunité de déranger ou non l'utilisateur du terminal 120 après réception d'un message 207. Si l'utilisateur du terminal 110 juge que son message 205 n'est pas urgent et qu'il ne souhaite donc pas déranger l'utilisateur du terminal 120, l'utilisateur du terminal 110 n'a plus d'action à effectuer. Son message 205 est enregistré dans la base de données 103 et sera envoyé automatiquement par le serveur 100 au terminal 120 lorsque le service « ne pas déranger » sera désactivé. A noter que le service « ne pas déranger » peut être désactivé à la demande par l'utilisateur du terminal 120, comme on le verra, mais aussi que le service peut se désactiver automatiquement. Par exemple, une durée maximale de fonctionnement du service « ne pas déranger » peut être définie. Cette durée peut être commune à tous les utilisateurs ou choisie par l'utilisateur du terminal 120 lors de l'activation du service, par exemple en indiquant une durée maximale de fonctionnement du service dans le message 201 d'activation du service. Si au contraire l'utilisateur du terminal 110 juge que le message 205 nécessite d'être envoyé urgemment au terminal 120, alors le terminal 110 envoie au serveur 100 un message 210. L'envoi de ce message 210 se fait en répondant au message 207 reçu par le terminal 110. Dit autrement, le message 210 est adressé à l'identifiant émetteur NUM i ou NUM d du message 207. Les messages à destination des identifiants NUM i associés aux listes blanches ou à destination de l'identifiant NUM d sont donc envoyés au serveur 100. L'étape 211 correspond à la réception par le serveur 100 d'un message 210 à destination de NUM j et en provenance de NUM 110. Dit autrement, le champ destinataire du message 210 comprend un identifiant NUM j. Le serveur détermine alors l'appartenance de NUM 110 à une liste prédéfinie, liste prédéfinie associé à un identifiant NUM k. Si NUM k et NUM j correspondent, c'est-à-dire sont égaux, alors le serveur 100 retrouve dans la base données 103 un message 212 enregistré, émis par le terminal 110 à destination du terminal 120, et envoie ce message 212 au terminal 120. Le message 212 correspond à un message 205 précédemment enregistré dans la base de données 103. Si NUM 110 n'appartient pas à une liste prédéfinie, alors le serveur 100 vérifie que NUM j correspond à NUM d, c'est-à-dire que NUM j est égal à NUM d. Si c'est le cas, alors le serveur 100 retrouve dans la base données 103 un message 212 enregistré, message émis par le terminal 110 à destination du terminal 120, et envoie ce message 212 au terminal 120. Dans le cas contraire, c'est-à-dire un identifiant NUM j ne correspondant pas à l'identifiant associé à la liste d'identifiants à laquelle appartient NUM 110, ou si NUM 110 n'appartient pas à une liste, à NUM d, alors le message 210 est ignoré par le serveur 100. Cette étape de vérification de la cohérence entre NUM j et un identifiant attendu permet d'éviter qu'un utilisateur d'une liste associé à un identifiant n'envoie un message 210 à un autre identifiant. Dit autrement, dans l'hypothèse où les identifiants NUM i et NUM d correspondent à des numéros surtaxés, cela permet d'éviter qu'un utilisateur n'envoie un message 210 à un numéro différent du numéro surtaxé qu'il devrait utiliser. Cela est possible si cet utilisateur ne répond pas au message 207 - c'est-à-dire réutilise le numéro de l'émetteur du message 207 comme destinataire - mais édite un message 210 en choisissant un destinataire lui-même. Sans cette vérification, un utilisateur d'un terminal 110 pourrait choisir le numéro surtaxé le moins surtaxé, affaiblissant l'effet de la méthode. Dans un autre mode de réalisation alternatif, l'étape de vérification de la concordance entre NUM j et respectivement NUM k ou NUM d n'est pas réalisée. En effet, dans l'hypothèse où les tarifications d'envoi de messages vers le deuxième et troisième identifiant seraient différentes, et afin d'éviter qu'un premier utilisateur n'envoie un quatrième message 210 que vers l'identifiant le moins coûteux, il est utile de vérifier que l'identifiant de destination du quatrième message 210 correspond bien à l'identifiant d'émetteur du deuxième message 207. Dit autrement, il est utile de vérifier que le premier utilisateur répond bien au deuxième message 207 en utilisant l'identifiant contenu dans le champ émetteur du deuxième message. Toutefois, en considérant que le premier utilisateur répondra au deuxième message 207, et donc que le message 210 sera bien envoyé au bon identifiant correspondant à l'émetteur du deuxième message 207, cette étape de vérification peut être ignorée. Dit autrement, selon le niveau de sécurité recherché, l'étape de vérification de la correspondance des identifiants pourra ne pas être réalisée. Dans ce cas, après réception du message 210, le serveur 100 détermine si l'identifiant NUM j est égal à un identifiant connu, c'est-à-dire un identifiant associé à une liste prédéfinie ou NUM d. Si oui, le serveur retrouve ensuite dans la base de données 103 un message enregistré et qui est destiné au deuxième terminal 120 puis émet ce message retrouvé vers le deuxième terminal 120. Si non, le message 210 est ignoré. Un message 213 peut être envoyé par le serveur 100 au terminal 110 pour confirmation de bonne réception du message 210. Alternativement, le message 213 est envoyé pour indiquer à l'utilisateur du terminal 110 qu'un message 212 a bien été envoyé au terminal 120. Selon le mode de réalisation de la méthode de la présente invention, le message 212 envoyé au terminal 120 peut être retrouvé dans la base de données 103 de différente manière. Selon une méthode, le message 212 enregistré dans la base de données 103 qui est retrouvé et envoyé au terminal 120 correspond au dernier message émis par le terminal 110 et à destination du terminal 120 à avoir été enregistré dans la base de données 103. Dit autrement, le message retrouvé est le dernier des messages enregistrés, émis par le premier terminal 100 et à destination du deuxième terminal 120. Cette méthode permet donc un « déblocage » des messages enregistrés selon le principe du « dernier arrivé, premier sorti ». Alternativement, le message 212 retrouvé et envoyé peut correspondre au contraire au premier message émis par le terminal 110 et à destination du terminal 120 à avoir été enregistré dans la base de données 103, selon le principe du « premier arrivé, premier sorti ». Selon une autre méthode alternative, le message 207 comprend une référence permettant d'identifier le message 205 enregistré dans la base de données. Le message 210 comprend cette même référence, ce qui permet au serveur de retrouver dans la base de données 103 le message 205 correspondant à cette référence. Le message 212 envoyé correspondant alors au message 205 enregistré précédemment qui a pour référence la référence comprise dans le message 210. Un message 205 reçu par le serveur 100 est donc enregistré dans la base de données 103 en association avec une référence, cette même référence étant envoyée dans le message 207 envoyé en retour. La fourniture de cette référence dans un message 210 permet de retrouver ce message enregistré dans la base de données 103 et de l'émettre vers le deuxième terminal 120. Dans l'hypothèse où plusieurs messages 205 sont envoyés par le terminal 110 à destination du terminal 120, cette méthode alternative permet donc de sélectionner lequel de ces plusieurs messages sera retrouvé et envoyé suite à la réception par le serveur 100 d'un message 210. La sélection se faisant par la fourniture dans le message 210 de la référence correspondante au message enregistré dans la base de données 103, référence reçue dans un message 207. A noter que le message 212 retrouvé dans la base de données et envoyé au terminal 120 est ensuite supprimé de la base de données 103. Selon le mode de réalisation, un message 214 est envoyé par le terminal 120 au terminal 110 pour indiquer la bonne réception du message 212. Ainsi, lorsque le service « ne pas déranger » est actif pour un terminal 120, tout message 205 émis par un terminal 110, à destination du terminal 120, et dont l'identifiant n'est pas compris dans une liste grise ou verte associée au terminal 120 sera enregistré par le serveur 100 dans une base de données 103. Le message 205 n'est donc pas délivré au terminal 120 à ce stade. Un message 207 sera émis en retour vers le terminal 110, le champ émetteur de ce message 207 sera dépendant de l'appartenance de l'identifiant du terminal 110 à une liste prédéfinie associée au terminal 120. L'utilisateur du terminal 110 a la possibilité de répondre à ce message 207 par un message 210 pour débloquer l'envoi d'un message 205 précédemment envoyé. Par débloquer, on comprendra, retrouver dans la base de données 103 un message, émis par le terminal 110 à destination du terminal 120 et précédemment enregistré dans la base de données 103 puis envoyé ce message au terminal 120. Selon le mode de réalisation, le message retrouvé est ensuite supprimé de la base de données 103. L'étape 221 correspond à la désactivation par l'utilisateur du terminal 120 du service « ne pas déranger'>. A noter que comme vu précédemment, la désactivation peut être automatique, par exemple après expiration d'un délai prédéfinie. D'autres critères d'activation ou désactivation automatique du service sont possibles. Par exemple une synchronisation avec une application de type agenda sur le deuxième terminal 120 peut activer et mettre fin au service automatiquement au début et à la fin d'une réunion.

L'activation ou désactivation du service peut aussi être déclenchée par la position d'un capteur sur le terminal 120, la position face cachée sur une table correspondant par exemple à l'activation automatique du service « ne pas déranger ». L'utilisateur du terminal 120 peut aussi définir des plages horaires d'activation du service. Un couplage avec une application de type géolocalisation peut aussi permettre d'activer ou désactiver le service automatiquement quand le terminal se trouve dans certains lieux, possiblement en y ajoutant des critères horaires. Dans ces cas, comme pour la désactivation automatique suite à l'expiration d'un délai, le serveur 100 peut automatiquement désactiver le service. Dans d'autres cas, le serveur peut nécessiter de recevoir un message 220 indiquant la désactivation du service « ne pas déranger » pour le terminal 120. Le serveur 100 reçoit donc un message 220 émis par le deuxième terminal 120 de demande de désactivation du service. Dans les deux cas, le serveur 100 retrouve tous les messages 222 enregistrés dans la base de données 103 et à destination du terminal 120 et les envoie au terminal 120. Ces messages 222 peuvent être ensuite supprimés de la base de données 103. A noter que les messages 222, comme d'ailleurs les messages 212, ont un identifiant d'émetteur correspondant à l'émetteur original du message, c'est-à-dire par exemple NUM 110 pour un message 205 initialement envoyé par le terminal 110. Suite à la désactivation du service, tout message envoyé à destination du terminal 120 lui sera remis normalement. La désactivation, à l'instar de l'activation du service, peut comprendre une étape de modification du routage des messages à destination du terminal 120. La méthode de filtrage comprend une étape 216, qui peut indifféremment être exécutée lorsque le service « ne pas déranger » est actif ou non, cette étape 216 correspondant à la mise à jour ou configuration d'une ou plusieurs listes par l'utilisateur du terminal 120. Cette mise à jour de liste prédéfinie associée au terminal 120 peut se faire par l'envoi de messages 215, comprenant par exemple des identifiants à ajouter à une liste, la liste étant identifiée par une référence préétablie. L'utilisateur du terminal 120 peut donc personnaliser et gérer les listes.

Selon un mode de réalisation, la méthode de filtrage précédemment décrite a pour particularité que les identifiants NUM i associés aux listes prédéfinies ou l'identifiant NUM d, utilisé par défaut lors de l'envoi du message 207 comme émetteur, et par conséquent utilisés comme identifiant destinataire du message 210 envoyé par le terminal 110, correspondent à des numéros surtaxés. Ainsi, après réception d'un message de type 207, en plus de la nécessité pour l'utilisateur de devoir évaluer si oui ou non il désire réellement déranger l'utilisateur du terminal 120, et si oui, de prendre le temps d'envoyer un message 210, l'utilisateur du terminal 110 devra décider s'il est prêt à payer pour cela le coût correspondant au numéro surtaxé. L'utilisateur du terminal 120 peut ainsi constituer une liste blanche de numéro correspondant à des terminaux d'utilisateurs connus, pour lesquels la surtaxe sera faible voire nulle. Inversement, pour des numéros hors de cette liste, ou appartenant à d'autres listes, la surtaxe sera plus élevée. A noter que la surtaxe associée à l'identifiant NUM d, appliquée par défaut pour un identifiant n'appartenant pas à une liste, n'est pas forcément la surtaxe la plus élevée, l'utilisateur du terminal 120 pouvant définir une liste d'utilisateur pour lesquels la surtaxe est maximale.

Selon un mode de réalisation, tout ou partie de la surtaxe collectée est reversée à l'utilisateur du service, ou à tout autre organisme ou entité, possiblement défini par l'utilisateur du service Selon un mode de réalisation de l'invention, en cas de pluralité de liste d'identifiants, un même identifiant ou numéro ne peut appartenir qu'a une unique liste. Dans un mode de réalisation alternatif, si un identifiant devait appartenir à plusieurs liste, alors une liste serait considérée par le serveur 100 comme prioritaire par rapport aux autres listes. En terme d'implémentation, cela peut signifier que la méthode de filtrage décrite peut dérouler le processus de détermination d'un identifiant à une liste de façon séquentiel s'il existe plusieurs liste, les listes prioritaires étant parcourues en premier (par exemple, d'abord la liste verte, puis les listes blanches, puis la liste grise, etc.). La séquence peut être définie par l'utilisateur du service.

Selon un mode de réalisation complémentaire, les messages 207 et 210 comprennent une indication de l'identifiant du destinataire du message 205. En effet, en cas d'envoi d'un message à plusieurs utilisateurs ayant activés le service « ne pas déranger'>, le serveur 100 peut renvoyer à l'émetteur du message 205 un message 207 différent par destinataire ayant le service activé, les différents messages 207 se distinguant par une information sur le destinataire particulier. L'utilisateur du message 205 peut alors envoyer un message 210 comprenant une référence au numéro destinataire pour ne débloquer que ce seul message à destination de ce seul destinataire. A noter que comme vu précédemment, le serveur 100 peut alors débloquer soit le premier message à avoir été enregistré dans la base de données 103, soit le dernier, soit un message identifié par une référence particulière. Alternativement, selon un autre mode de réalisation, un seul message 207 est envoyé par le serveur 100 en réponse à un message 205 adressé à une pluralité de terminaux en mode « ne pas déranger » activé. Il suffit alors d'un unique message 210 pour débloquer l'envoi du message en attente à la pluralité de terminaux destinataires.

Selon un mode de réalisation alternatif, les différentes étapes de la méthode sont réalisées en partie par le terminal 120, le service prenant la forme d'une application exécutée sur le terminal 120. Un serveur 100, connecté avec terminal 120- par exemple par une connexion de données IP - est utilisé pour exécuter quelques étapes de la méthode. Les messages 201, 203, 212, 215, 217, 220 et 222 sont des messages internes à l'application exécutée sur le terminal 120. Le terminal 120 exécutant l'application, quand le mode « ne pas déranger » est actif, peut ne pas réagir à la réception d'un message 205 afin de ne pas déranger l'utilisateur. Le message 205 est enregistré sur le terminal 120. Le terminal 120 envoie instruction au serveur 100 d'envoyer un message 207 au terminal 110 lui indiquant que le terminal 120 est en mode « ne pas déranger'>. Le message 207 comprend comme précédemment un champ émetteur correspondant à un identifiant NUM i possiblement surtaxé. En cas de réception d'un message 210 par le serveur 100, ce dernier envoie instruction au terminal 120 de débloquer le message 205 correspondant, c'est-à-dire que le message est retrouvé dans la base de données 103 du terminal et présenté de manière à donner l'illusion à l'utilisateur du terminal qu'il vient seulement d'être reçu. Selon un mode de réalisation alternatif, la méthode de filtrage de messages est appliquée à des communications vocales - ou voix et vidéo pour une communication de type vidéoconférence - entre le premier et deuxième terminal. Plus précisément, la méthode de filtrage de messages est appliquée au filtrage de messages correspondants à des demandes d'établissement de communications (par exemple voix ou vidéos) à destination du deuxième terminal (dit autrement, des appels voix ou vidéo vers le deuxième terminal 120). Dans ce cas, la FIG. 2 doit être lue comme ceci : le message 205 correspond à une demande d'établissement de communication émise par le terminal 110 et à destination du terminal 120. Il peut s'agir d'une communication de type voix, voix et vidéo, etc. - l'étape 206 correspond à l'interception par le serveur 100 de cette demande d'établissement d'une communication avec le terminal 120. Les informations correspondantes à cette demande sont enregistrées dans la base de données 103. - selon un mode de réalisation, un message vocal peut alors être diffusé par le serveur 100 vers le terminal 110, message informant par exemple l'utilisateur du terminal 110 que l'utilisateur du terminal 120 ne souhaite pas être dérangé. Le message diffusé peut être adapté selon l'appartenance de l'identifiant du terminal 110 à une liste prédéfinie ; alternativement ou de façon complémentaire, l'appel peut être redirigé - directement ou après diffusion du message vocal donc - vers la messagerie vocale de l'utilisateur du terminal 120, le message 207 correspond à un message, par exemple un SMS, qui est envoyé au terminal 110 par le serveur 100, message émis avec un champ émetteur comprenant un identifiant NUM i dépendant de l'appartenance de l'identifiant du terminal 110 à une liste prédéfinie, comme vu auparavant. Ce message informe l'utilisateur du terminal 110 du fait que l'utilisateur du terminal 120 ne souhaite pas être dérangé, mais qu'il est possible de joindre l'utilisateur du terminal 120 au numéro correspondant à l'identifiant NUM i, cet identifiant correspondant possiblement à un numéro surtaxé. si l'utilisateur du terminal 110 souhaite joindre l'utilisateur du terminal 120, il réémet un message 210 de demande d'établissement de communication (ou appel) vers l'identifiant NUM i, appel qui sera reçu par le serveur 100. Le serveur 100 mettra alors en communication le terminal 110 avec le terminal 120. Pour cela, le serveur 100 émettra lui-même un appel vers le terminal 120. l'appel sera facturé à l'utilisateur du terminal 110 selon le coût correspondant au numéro surtaxé NUM i.

Lorsque l'utilisateur du terminal 120 mettra fin au service (étape 221), les informations concernant les demandes d'établissement de communications avec le terminal 120 seront retrouvées dans la base de données 103 et envoyées au terminal 120. Dit autrement, le terminal 120 recevra à la désactivation du service « ne pas déranger » un journal des appels filtrés. Alternativement, le terminal 120 peut se voir envoyé par le serveur 100 des mises à jour - en temps réel ou différé - du journal des appels filtrés.

Claims (12)

1. REVENDICATIONS1. Une méthode de filtrage de messages émis par un premier terminal (110) à destination d'un deuxième terminal (120), le premier terminal (110) étant associé à un premier identifiant, les terminaux étant connectés via au moins un réseau de communication (160), le réseau de communication comprenant un serveur (100) connecté à une base de données (103), la base de données (103) comprenant au moins une première liste prédéfinie d'identifiants, le serveur (100) exécutant les étapes suivantes : recevoir un premier message (205) émis par le premier terminal (110) à destination du deuxième terminal (120), enregistrer le premier message (205) dans la base de données (103), - déterminer si le premier identifiant appartient à la première liste : o si oui, émettre un deuxième message (207) à destination du premier terminal (110), le deuxième message (207) comprenant un champ émetteur égal à un deuxième identifiant, o si non, émettre un deuxième message (207) à destination du premier terminal (110), le deuxième message (207) comprenant un champ émetteur égal à un troisième identifiant.
2. 2. Une méthode selon une des revendications précédentes, la méthode comprenant les étapes ultérieures suivantes : - recevoir un troisième message (220) émis par le deuxième terminal (120) de demande de désactivation du service de filtrage fourni par la présente méthode, - envoyer au deuxième terminal (120) les messages enregistrés dans la base de données (103) et qui lui sont destinés.
3. 3. Une méthode selon une des revendications précédentes, la méthode comprenant les étapes ultérieures suivantes : recevoir un quatrième message (210) émis par le premier terminal (110), le champ destinataire du quatrième message (210) comprenant un quatrième identifiant, si le quatrième identifiant est égal au deuxième identifiant, ou bien, si le quatrième identifiant est égal au troisième identifiant, alors : o retrouver dans la base de données (103) un message enregistré et qui est destiné au deuxième terminal (120), o émettre vers le deuxième terminal (120) le message (212) retrouvé, - si non, ignorer le quatrième message (210).
4. 4. Une méthode selon la revendication précédente, le message retrouvé étant le dernier des messages enregistrés, émis par le premier terminal (110) et à destination du deuxième terminal (120), la méthode comprenant une étape ultérieure de suppression de ce message retrouvé de la base de données (103) après son émission vers le deuxième terminal (120).
5. 5. Une méthode selon la revendication 3, le deuxième message (207) comprenant une première référence permettant d'identifier le premier message (205) enregistré dans la base de données (103), le quatrième message (210) comprenant une seconde référence correspondant à la première référence, le message (212) émis vers le deuxième terminal étant retrouvé dans la base de données (103) grâce à la seconde référence.
6. 6. Une méthode selon une des revendications précédentes, la base de données (103) comprenant une deuxième liste prédéfinie d'identifiants, la méthode comprenant de plus les étapes suivantes après la réception du premier message : - déterminer si le premier identifiant appartient à la deuxième liste, - si oui, transmettre le premier message au deuxième terminal (120) sans émettre le deuxième message (207).
7. 7. Une méthode selon une des revendications précédentes, la base de données (103) comprenant une troisième liste prédéfinie d'identifiants, la méthode comprenant de plus les étapes suivantes après la réception du premier message (205) : - déterminer si le premier identifiant appartient à la troisième liste prédéfinie, - si oui, enregistrer le premier message dans la base de données (103) sans émettre le deuxième message (207).
8. 8. Une méthode selon une des revendications précédentes, l'un au moins des deuxième et troisième identifiants correspondant à un numéro de service à valeur ajoutée.
9. 9. Une méthode selon une des revendications précédentes, les messages étant de type message court.
10. 10. Une méthode selon la revendication précédente, un message comprenant au moins un message de type court.
11. 11. Un serveur (100) permettant la mise en oeuvre d'une méthode filtrage de messages, le serveur (100) étant connecté à une base de données (103) et à un réseau decommunication (160), réseau de communication (160) auquel sont connectés un premier et deuxième terminal (110) et (120), le serveur (100) étant caractérisé en ce qu'il comprend des moyens pour : recevoir un premier message (205) émis par le premier terminal (110) à destination du deuxième terminal (120), enregistrer le premier message (205) dans la base de données (103), - déterminer si le premier identifiant appartient à la première liste : o si oui, émettre un deuxième message (207) à destination du premier terminal (110), le deuxième message (207) comprenant un champ émetteur égal à un deuxième identifiant, o si non, émettre un deuxième message (207) à destination du premier terminal (110), le deuxième message (207) comprenant un champ émetteur égal à un troisième identifiant.
12. 12. Programme d'ordinateur pour la mise en oeuvre des étapes de la méthode selon une des revendications 1 à 10 lorsque le programme est exécuté par un processeur d'un serveur (100) connecté à une base de données (103) et à au moins un réseau de communication (160).20