Brevet FR3102903A1 — publié le 20210507

Un terminal (TERM) : - reçoit (E10) une expression régulière en provenance d’un serveur (SERV) ; - obtient (E20) un numéro appelant d’une entité émettrice dudit appel ; et - bloque (E24) l’appel si le numéro vérifie (E22) ladite expression régulière. Les expressions régulières sont générées par le serveur (SERV) à partir d’informations représentatives des appels indésirables ou non reçus par des terminaux (TERM). Figure 5 Procédés, terminal et serveur permettant le blocage d’appels indésirables Arrière-plan de l’invention L’invention se situe dans le domaine de la téléphonie et plus particulièrement dans celui du blocage des appels indésirables. La plupart des terminaux offrent aujourd’hui une interface permettant à l’utilisateur de saisir des numéros de téléphone, le terminal étant configuré pour bloquer les appels reçus dont le numéro d’appelant correspond à ce numéro. Dans la suite de ce document : - un numéro à bloquer est appelé « numéro indésirable » ; - un numéro qui n’est pas indésirable est appelé « numéro autorisé » ; - un appel entrant (ou reçu) dont le numéro de l’appelant est un numéro indésirable est appelé « appel indésirable » ou « appel à bloquer » ; - un appel entrant qui n’est pas un appel indésirable est appelé « appel autorisé », un tel appel étant généralement soit présenté à l’utilisateur soit redirigé vers une messagerie. Il a été constaté qui dorénavant, la plupart des appels indésirables sont émis par des robots (en anglais « chatbot »), ces robots étant programmés pour émettre des appels dont le numéro d’appelant varie. Par conséquent, les méthodes de blocage d’appel connues à ce jour ne sont pas satisfaisantes. Objet et résumé de l’invention L’invention vise par conséquent un nouveau mécanisme de blocage des appels indésirables. Ainsi, et selon un premier aspect, l’invention concerne un procédé de blocage d’un appel téléphonique reçu par un terminal, ce procédé comportant : - une étape de réception d’une expression régulière en provenance d’un serveur ; - une étape d’obtention d’un numéro appelant d’une entité émettrice dudit appel ; et - une étape de blocage dudit appel si le numéro vérifie ladite expression régulière. Corrélativement, l’invention concerne un terminal comportant : - une unité de réception d’une expression régulière en provenance d’un serveur ; - une unité d’obtention d’un numéro appelant d’une entité émettrice dudit appel ; et - une unité de blocage dudit appel si le numéro vérifie (E22) ladite expression régulière. L’invention permet ainsi de bloquer un appel dont le numéro d’appelant est a priori inconnu, dès lors que celui-ci vérifie une expression régulière. De façon très avantageuse, cette expression régulière est reçue d’un serveur et ne nécessite donc aucune intervention de l’utilisateur pour la générer. Ces expressions régulières permettent en particulier de bloquer des appels émis par des entités dont le numéro appartient à une plage de numéros. Par exemple : - l’expression régulière « 01984567* » bloque tous les numéros commençant par 01974567 ; - l’expression régulière « 01.8456723 » bloque tous les numéros de 10 chiffres commençant par « 01 » et finissant par « 8456723 » ; Ces expressions régulières sont donc particulièrement adaptées pour bloquer des appels émis par des robots. On notera que le blocage à proprement parler d’un appel indésirable par le terminal peut se faire sans interroger le serveur, dans un mode dit « déconnecté ». De façon très avantageuse pour le terminal, la place requise pour stocker les expressions régulières est bien moins importante que celle requise pour stocker l’ensemble des numéros indésirables. Selon un deuxième aspect, l’invention concerne un procédé de gestion d’appels téléphoniques indésirables, ce procédé comportant : - une étape d’obtention de premières informations représentatives des appels reçus par au moins un terminal, ces premières informations comportant au moins les numéros appelant des entités émettrices desdits appels ; - une étape de réception d’au moins une deuxième information représentative d’un appel indésirable reçu par au moins un terminal, ces deuxièmes informations comportent au moins les numéros appelant des entités émettrices desdits appels ; - une étape de génération ou de mise à jour d’une expression régulière à partir desdites premières et deuxièmes informations ; et - une étape d’envoi de ladite expression régulière à au moins un terminal. Corrélativement, l’invention concerne un serveur comportant : - une unité d’obtention de premières informations représentatives des appels reçus par au moins un terminal, ces premières informations comportant au moins les numéros appelant des entités émettrices desdits appels ; - une unité de réception d’au moins une deuxième information représentative d’un appel indésirable reçu par au moins un terminal, ces deuxièmes informations comportent au moins les numéros appelant des entités émettrices desdits appels ; - une unité de génération ou de mise à jour d’une expression régulière à partir desdites premières et deuxièmes informations ; et - une étape d’envoi de ladite expression régulière à au moins un terminal. Ainsi, les expressions régulières sont générées ou mises à jour par le serveur sur la base des appels effectivement reçus par des terminaux. Un terminal donné bénéficie ainsi de la connaissance des appels indésirables par les autres terminaux. Dans un mode particulier de réalisation de l’invention : - les premières informations comportent les numéros appelant des entités émettrices desdits appels reçus; et - les deuxièmes informations comportent les numéros appelant des entités émettrices desdits appels indésirables. Dans un mode particulier de réalisation de l’invention : - les premières informations comportent le jour et la date de réception des appels reçus; et - les deuxièmes informations comportent le jour et la date de réception desdits appels indésirables reçus. Ainsi, le serveur selon l’invention peut prendre en compte le jour et l’heure de réception des appels indésirables pour générer et mettre à jour les expressions régulières. Il tire ainsi partie du fait que les robots génèrent généralement les appels indésirables certains jours de la semaine, et souvent dans des plages horaires délimitées dans lesquelles les utilisateurs sont plus susceptibles d’être présents et disponibles. Dans un mode particulier de réalisation de l’invention, l’étape de génération ou de mise à jour d’une expression régulière utilise une méthode de classification, par exemple un classifieur de Bayes. Dans un mode particulier de réalisation, le procédé de gestion d’appels téléphoniques indésirables selon l’invention comporte : - une étape de détermination, à partir desdites premières et deuxièmes informations, d’une probabilité qu’un numéro d’appelant soit un numéro autorisé ou indésirable ; et: les expressions régulières sont générées ou mises à jour à partir de ces distributions de numéros d’appelant construites sur la base desdites statistiques. Dans un mode particulier de réalisation de l’invention, la probabilité d’au moins un numéro appelant est obtenue à partir desdites probabilités déterminées pour des numéros voisins de ce numéro appelant. En effet, dans un mode particulier de réalisation décrit ultérieurement, l’invention propose de déterminer de façon statistique si un numéro d’appelant donné est un numéro autorisé ou indésirable, de déterminer sur la base de ces statistiques des distributions de numéros autorisés et/ou des distributions de numéros indésirables et de construire les expressions régulières à partir de ces distributions. Des méthodes d’apprentissage et en particulier le classifieur de Bayes permettent de déterminer ces probabilités. Dans un mode particulier de réalisation de l’invention, le procédé de gestion des appels indésirables détermine en particulier, de façon statistique si un numéro d’appelant donné est un numéro autorisé ou indésirable, même si le serveur n’a aucune connaissance d’un appel effectivement émis avec ce numéro d’appelant. Dans un mode de réalisation de l’invention, cette détermination se fait à partir des probabilités que des numéros proches ou voisins de ce numéro d’appel soient des numéros autorisés ou indésirables. Dans un mode particulier de réalisation du procédé de blocage selon l’invention, si le numéro d’appelant vérifie une expression régulière, le terminal envoie un message de notification au serveur pour l’informer de la réception d’un message indésirable, ce message comportant au moins le numéro de l’entité émettrice. Le serveur utilise ces données pour compléter les deuxièmes informations. Dans un mode particulier de réalisation, le procédé de blocage selon l’invention comporte, si le numéro ne vérifie aucune expression régulière reçue par le terminal : - une étape d’envoi d’une requête au serveur pour lui demander si l’appel doit être bloqué ; - une étape de mise en attente dudit appel jusqu’à réception d’une réponse dudit serveur ; et - une étape de blocage ou non dudit appel en fonction de ladite réponse. Dans ce mode de réalisation de l’invention, le procédé de gestion d’appels téléphoniques indésirables comporte : - une étape de réception d’une requête envoyée par un terminal, ladite requête comportant au moins un numéro d’appelant d’un appel reçu par ledit terminal ; - une étape pour déterminer une probabilité que ledit numéro d’appelant soit un numéro indésirable ou un numéro autorisé, à partir desdites premières et deuxièmes informations ; et - une étape d’envoi d’un message représentatif du résultat de ladite détermination audit terminal. Comme mentionné précédemment, cette détermination peut se faire à partir des probabilités que des numéros proches ou voisins de ce numéro d’appel soient des numéros autorisés ou indésirables. Dans un mode particulier de réalisation, les différentes étapes du procédé de blocage d’appel et/ou du procédé de gestion d’appels indésirables sont déterminées par des instructions de programmes d’ordinateurs. En conséquence, l’invention vise aussi un programme d’ordinateur sur un support d’informations, ce programme étant susceptible d’être mis en œuvre dans terminal ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de blocage d’appel tel que présenté ci-dessus. L’invention vise aussi un programme d’ordinateur sur un support d’informations, ce programme étant susceptible d’être mis en œuvre dans serveur ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de gestion d’appels indésirables tel que présenté ci-dessus. Ces programmes peuvent utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. L’invention vise aussi un support d'informations ou d’enregistrement lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, le support d'informations ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations ou d’enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : la figure 1 représente un terminal et un serveur conformes à l’invention, dans leur environnement ; la figure 2A représente un terminal conforme à un mode particulier de réalisation de l’invention ; la figure 2B est une représentation fonctionnelle d’un terminal conforme à un mode particulier de réalisation de l’invention ; la figure 3A représente un serveur conforme à un mode particulier de réalisation de l’invention ; la figure 3B est une représentation fonctionnelle d’un serveur conforme à un mode particulier de réalisation de l’invention ; la figure 4A représente sous forme d’ordinogramme une méthode de génération et de mise à jour d’expressions régulières pouvant être utilisée dans un mode particulier de réalisation de l’invention ; la figure 4B représente un tableau pouvant être utilisé dans la méthode de la figure 4A ; la figure 4C représente une opération pouvant être utilisée dans la méthode de la figure 4A ; et la figure 5 représente sous forme d’ordinogramme un procédé de blocage d’appel et un procédé de gestion des appels indésirables conforme à un mode particulier de réalisation. Description détaillée de l’invention La figure 1 représente un terminal TERM et un serveur SERV conformes à l’invention, dans leur environnement, et un équipement réseau EQT, le terminal TERM, le serveur SERV et l’équipement réseau EQT étant interconnectés par un réseau de télécommunications RT. Dans le mode de réalisation décrit ici, le terminal TERM est un terminal mobile et le réseau de télécommunications RT est un réseau de télécommunications mobile, par exemple un réseau cellulaire de type 3G, 4G ou 5G. L’équipement réseau EQT est configuré pour collecter des informations sur chacun des appels téléphoniques reçus par le terminal TERM et par d’autres terminaux non représentés sur la figure 1. Cet équipement EQT est par exemple opéré par un opérateur du réseau de télécommunications RT. Il peut par exemple collecter des informations sur chacun des appels reçus par les terminaux des abonnés auprès de cet opérateur, dont le terminal TERM. Cet équipement est par exemple un serveur de l’opérateur, ce serveur mémorisant les journaux d’appels d’au moins une partie des abonnés de l’opérateur. Ce serveur peut par exemple être un serveur du type de de ceux utilisés dans les services de type Call-Logs. Les données collectées par l’équipement réseau EQT constituent des premières données au sens de l’invention. Pour chaque appel reçu par un terminal géré par l’équipement EQT, ces premières données comportent au moins le numéro de l’appelant, et éventuellement le jour de la semaine (lundi, mardi, …) et l’heure de l’appel. Les premières données de tous les appels reçus par ces terminaux sont collectées, autrement dit les données des appels autorisés et les données des appels indésirables au sens de l’invention. Ces premières données sont mémorisées dans une base de données BDC gérée par et/ou accessible par l’équipement réseau EQT. On dira ci-après que la base de données BDC gère les terminaux pour lesquels elle mémorise ces premières données. La figure 2A représente le terminal TERM de la figure 1. Ce terminal comporte des moyens de communication COM compatibles avec le réseau de communication RT, par exemple un module 3G, 4G ou 5G. Dans le mode de réalisation décrit ici, ce terminal TERM a l’architecture d’un ordinateur. Il comporte notamment un processeur 10, une mémoire vive de type RAM 11, une mémoire morte de type ROM 12, une mémoire non volatile réinscriptible de type FLASH 13 et une interface homme-machine 14 comportant notamment des moyens d’entrée (clavier, interface tactile, microphone, module de reconnaissance vocale, …) et des moyens de sortie (écran, haut-parleur, …). La mémoire morte 12 constitue un support d’enregistrement conforme à l’invention. Elle comporte un programme d’ordinateur PGT conforme à l’invention. Le module de communication COM comporte des éléments matériels (hardware) comportant notamment un module radio, et des éléments logiciels (software) comportant notamment un système d’exploitation. Plus précisément, dans le mode de réalisation décrit ici, le système d’exploitation comporte une couche d’interface RIL (Radio Interface Layer en anglais) qui fournit une interface entre les services de téléphonie du terminal et le module radio. Cette couche d’interface RIL est notamment configurée pour pouvoir détecter un appel entrant et obtenir le numéro de l’appelant. Le module de communication COM est configuré pour permettre au terminal TERM de communiquer avec le serveur SERV via le réseau RT, par exemple au moyen d’une pile IP. La mémoire non volatile réinscriptible 13 comporte un journal LOG des appels reçus (et éventuellement émis) par le terminal TERM. Plus précisément, pour chaque appel reçu par le terminal TERM, le journal LOG comporte le numéro de l’appelant, le jour et l’heure de l’appel et une indication représentative du fait que cet appel est un appel autorisé ou indésirable. Dans le mode de réalisation décrit ici, l’interface homme-machine 14 du terminal TERM permet à un utilisateur du terminal de visualiser le journal LOG et de changer l’état autorisé/bloqué d’un numéro d’appelant. Par exemple, si l’utilisateur reçoit un appel émis par un robot, il peut ouvrir son journal LOG et décider de classer le numéro d’appelant comme « indésirable ». Inversement, si l’utilisateur considère qu’un appel reçu a été bloqué à tort, il peut ouvrir son journal LOG et décider de classer le numéro d’appelant comme « autorisé ». Dans le mode de réalisation décrit ici, le processeur 10 est configuré pour envoyer, en exécutant des instructions du programme PGT, un message au serveur SERV, de sorte à s’abonner à un service de réception d’expressions régulières générées ou mises à jour par ce serveur. Dans le mode de réalisation décrit ici, le processeur 10 est configuré pour enregistrer, en exécutant des instructions du programme PGT, des expressions régulières reçues du serveur SERV dans une base de données BDERT de la mémoire non volatile réinscriptible 13. Dans le mode de réalisation décrit ici, le terminal TERM est également configuré pour supprimer une expression régulière de la base de données BDERT lorsqu’il reçoit un message du serveur SERV indiquant qu’une expression régulière est obsolète et que celle-ci ne doit plus être utilisée. Le processeur 10 est configuré pour déterminer, en exécutant des instructions du programme PGT, si un numéro d’appelant vérifie ou non au moins une expression régulière enregistrée dans la base de données BDERT. Le processeur 10 est configuré pour bloquer, en exécutant des instructions du programme PGT, un appel entrant dès lors qu’il détermine que le numéro d’appelant de cet appel entrant vérifie au moins une expression régulière enregistrée dans la base de données BDERT. On rappelle que bloquer un appel signifie ne pas le présenter à l’utilisateur ni le rediriger vers une messagerie vocale. Dans le mode de réalisation décrit ici, le processeur 10 est configuré pour envoyer, en exécutant des instructions du programme PGT, un message de notification au serveur SERV pour lui indiquer que le terminal TERM a reçu un appel indésirable et pour indiquer dans ce message, le numéro de l’appelant, et éventuellement le jour et l’heure de cet appel. Dans un mode de réalisation, le processeur 10 est configuré pour envoyer, en exécutant des instructions du programme PGT, une requête au serveur SERV pour lui demander si un appel reçu par ce terminal doit être bloqué, alors même que le numéro d’appelant de ce message ne vérifie aucune des expressions régulières enregistrées dans la base de données BDERT. Dans ce mode de réalisation, l’appel est mis en attente jusqu’à réception d’une réponse du serveur SERV. Ainsi, les éléments décrits en référence à la figure 2A définissent, dans un mode de réalisation de l’invention, les entités fonctionnelles du terminal TERM, à savoir : - une unité ET1 de réception d’expressions régulières en provenance d’un serveur ; - une unité ET2 d’obtention d’un numéro appelant d’une entité émettrice d’un appel ; et - une unité ET3 de blocage d’un appel si ce numéro vérifie une expression régulière. La figure 2B est une représentation fonctionnelle du terminal TERM. D’autres implémentations de ces fonctions que celles de la figure 2A peuvent être envisagées, par exemple purement matérielle, par exemple sous forme de circuits intégrés. La figure 3A représente le serveur SERV de la figure 1. Ce serveur terminal comporte des moyens de communication COM compatibles avec le réseau de communication RT, par exemple un module de communication IP. Dans le mode de réalisation décrit ici, ce serveur SERV a l’architecture d’un ordinateur. Il comporte notamment un processeur 20, une mémoire vive de type RAM 21 et une mémoire morte de type ROM 22. La mémoire morte 22 constitue un support d’enregistrement conforme à l’invention. Elle comporte un programme d’ordinateur PGS conforme à l’invention. Les moyens de communication COM du serveur SERV lui permettent de communiquer avec la base de données BDC gérée par l’équipement réseau EQT. Le serveur SERV comporte des moyens logiciels pour requêter cette base de données et obtenir des informations représentatives de tous les appels reçus par les terminaux gérés par cette base de données BDC (numéros appelants, jour et heure des appels), autrement dit des premières informations au sens de l’invention. Dans le mode de réalisation décrit ici, le processeur 20 est configuré pour recevoir, en exécutant des instructions du programme PGS, des messages de terminaux qui désirent s’abonner à un service de réception d’expressions régulières générées ou mises à jour par ce serveur. Si le serveur SERV accepte cette demande d’abonnement, on dira que le serveur SERV gère ce terminal. Dans le mode de réalisation décrit ici, le processeur 20 est configuré pour recevoir, en exécutant des instructions du programme PGS, en provenance d’un terminal qu’il gère, par exemple en provenance du terminal TERM, un message de notification lui indiquant que ce terminal a reçu un appel indésirable, ce message comportant le numéro de l’appelant, et éventuellement le jour et l’heure de cet appel. Ces informations constituent des deuxièmes informations au sens de l’invention. Dans le mode de réalisation décrit ici, le serveur SERV enregistre ces deuxièmes informations dans une base de données BDCI. Dans le mode de réalisation décrit ici, le processeur 20 est configuré pour recevoir, en exécutant des instructions du programme PGS, en provenance d’un terminal qu’il gère, par exemple en provenance du terminal TERM, une requête demandant au serveur SERV si un appel reçu par ce terminal doit être bloqué, alors même que le numéro d’appelant de ce message ne vérifie aucune des expressions régulières enregistrées dans la base de données BDERT de ce terminal. Le processeur 20 est configuré pour générer ou mettre à jour, en exécutant des instructions du programme PGS, des expressions régulières à partir au moins des premières informations extraites de la base de données BDC et des deuxièmes informations mémorisées dans la base de données BDCI. Dans le mode de réalisation décrit ici, le serveur SERV enregistre ces expressions régulières dans une base de données BDERS. La génération et la mise à jour des expressions régulières par le serveur SERV sera décrite ultérieurement en référence aux figures 4A et 4B. Le serveur SERV est configuré pour envoyer à tous les terminaux qu’il gère les expressions régulières qu’il génère ou met à jour. Le serveur SERV est également configuré pour envoyer à ces terminaux, un message indiquant qu’une expression régulière est obsolète et que celle-ci ne doit plus être utilisée. Ainsi, les éléments décrits en référence à la figure 3A définissent, dans un mode de réalisation de l’invention, les entités fonctionnelles du serveur SERV, à savoir : - une unité ES1 d’obtention de premières informations représentatives des appels reçus par au moins un terminal; - une unité ES2 de réception d’au moins une deuxième information représentative d’un appel indésirable reçu par au moins un terminal ; - une unité ES3 de génération ou de mise à jour d’une expression régulière à partir desdites premières et deuxièmes informations ; et - une étape ES4 d’envoi d’expressions régulières à au moins un terminal. La figure 3B est une représentation fonctionnelle du serveur SERV. D’autres implémentations de ces fonctions que celles de la figure 3A peuvent être envisagées, par exemple purement matérielle, par exemple sous forme de circuits intégrés. La figure 4A illustre sous forme d’ordinogramme une méthode mise en œuvre par le serveur SERV pour générer ou mettre à jour les expressions régulières. Le serveur utilise pour cela : - la base de données BDC, alimentée par l’équipement réseau EQT, qui comporte les premières informations représentatives de tous les appels reçus par les terminaux gérés par le serveur SERV ; et - la base de données BDCI qui comporte les deuxièmes informations sur les appels indésirables reçus par les terminaux gérés par le serveur SERV ou considérés comme tels par les utilisateurs de ces terminaux. Dans le mode de réalisation décrit ici, le serveur SERV utilise un classifieur de Bayes pour générer ou mettre à jour ces expressions régulières. Dans le mode de réalisation décrit ici, cette méthode propose de calculer, au cours d’une étape R10, pour chaque numéro d’appelant NUM enregistré dans la base de données BDC : - une probabilité P(SPAM|NUM) que ce numéro soit indésirable ; et - une probabilité P(OK|NUM) que ce numéro soit autorisé. Avec : P(SPAM|NUM) = Count(NUM, BDCI)/Count (NUM, BDC) ; et P(OK|NUM) = [Count(NUM, BDC) - Count(NUM, BDCI)] / Count (NUM/BDC) la fonction Count(A,E) étant définie comme le nombre d’occurrences de l’élément A dans l’ensemble E. En effet, avec ces définitions : - Count(NUM, BDC) représente le nombre total d’appels ayant NUM pour numéro appelant - Count(NUM, BDCI) représente le nombre de fois où un appel dont NUM est le numéro appelant a été considéré indésirable, et par différence : - Count(NUM, BDC) - Count(NUM, BDCI) représente le nombre de fois où un appel dont NUM est le numéro appelant a été considéré autorisé. Dans le mode de réalisation décrit ici, la méthode propose de calculer, au cours d’une étape R20, pour au moins un numéro NUM non présent dans la base de données BDC les probabilités : - P(SPAM|NUM) que ce numéro NUM soit indésirable ; et - P(OK|NUM) que ce numéro NUM soit autorisé. Pour cela : 1/ on définit les N voisins NUM i * du numéro NUM, i=1..N, où : - N étant un paramètre de la méthode ; - le voisin de rang k d’un premier numéro étant un deuxième numéro dont le k ième chiffre diffère d’une unité du k ième chiffre du premier numéro, en base 10. Par exemple si on considère le numéro 0198456723, les 8 voisins de rang 10 de ce numéro sont, le rang 10 étant le rang du « 3 » dans ce numéro : 019845672 4 , 019845672 5 , 019845672 6 , 019845672 7 , 019845672 2 , 019845672 1 , 019845672 0 et 019845672 9 ; 2/ le serveur SERV cherche parmi ces N voisins NUM i * ceux qui sont présents dans la base de données BDC. On les note NUM j *, j=1..M, M inférieur ou égal à N ; 3/ le serveur SERV calcule P(SPAM| NUM j *) et P(OK| NUM j *), j=1..M en appliquant l’étape R10 déjà décrite ; 4/ on définit : P(SPAM|NUM) = P(SPAM| NUM 1 *) x ... x P(SPAM| NUM M *) ; et P(OK|NUM) = P(OK| NUM 1 *) x ... x P(OK| NUM M *). Dans un mode de réalisation optionnel de l’invention, la probabilité qu’un appel (i) d’un numéro appelant NUM reçu (ii) un jour J donné et à une heure H donnée soit autorisé ou indésirable prend en compte ce jour J et cette heure H. Le serveur pondère ainsi les probabilités calculées à l’étape R10 ou R20 par la probabilité qu’un appel reçu un jour J donné et à une heure H donnée soit autorisé ou indésirable, indépendamment du numéro de l’appelant. Ainsi, dans ce méthode de réalisation, le serveur SERV calcule en outre : - Count(J, BDC), le nombre total d’appels reçus un jour J enregistrés dans la base de données BDC ; - Count(J, BDCI), le nombre d’appels indésirables reçus un jour J et enregistrés dans la base de données BDCI ; - Count(H, BDC), le nombre total d’appels reçus autour d’une heure H, par exemple à quinze minutes prêt, et enregistrés dans la base de données BDC ; - Count(H, BDCI), le nombre d’appels indésirables reçus autour d’une heure H et enregistrés dans la base de données BDCI ; - P(SPAM|J) = Count(J, BDCI)/Count (J, BDC), la probabilité qu’un appel reçu un jour J soit indésirable ; - P(SPAM|H) = Count(H, BDCI)/Count (H, BDC), la probabilité qu’un appel reçu à une heure H soit indésirable ; - P(OK|J) = [Count(J, BDC) - Count(J, BDCI)] / Count (J/BDC), la probabilité qu’un appel reçu un jour J soit autorisé - P(OK|H) = [Count(H, BDC) - Count(H, BDCI)] / Count (H/BDC), la probabilité qu’un appel reçu à une heure H soit autorisé Et finalement, à l’étape R30 le serveur SERV calcule : P(SPAM|NUM)=P(SPAM|NUM)*P(SPAM|J)*P(SPAM|H) ; et P(OK|NUM)=P(OK|NUM)*P(OK|J) )*P(OK|H) Au cours d’une étape R40, un numéro d’appelant NUM: - est considéré indésirable si P(SPAM|NUM) > P(OK|NUM) ; et - est autorisé si P(OK|NUM) >= P(SPAM|NUM) ; les probabilités P(SPAM| NUM) et P(OK| NUM) ayant été calculées selon l’étape R10 ou l’étape R20 selon que le numéro est présent ou non dans la base de données BDC. Dans le mode de réalisation décrit ici, le serveur SERV enregistre les probabilités ainsi obtenues dans un tableau TAB représenté figure 4B. Ce tableau comporte : - une première colonne comportant tous les numéros NUM, par exemple de 10 chiffres 0000000000 à 9999999999 classés par ordre croissant ; - une deuxième colonne comportant la probabilité P(OK| NUM) que ce numéro NUM soit un numéro autorisé; et - une troisième colonne comportant la probabilité P(SPAM| NUM) que ce numéro NUM soit un numéro indésirable. Ces informations ne sont pas toutes représentées dans le tableau de la figure 4B, mais dans l’exemple décrit ici, on suppose : -qu’aucun d’appel n’a été détecté avec pour numéro d’appelant 0000000000, 0000000001, 019845671, 019845674, 019845679, 9999999998, 9999999999 ; - que les numéros 019845670, 019845672, 019845673, 019845675, 019845676, 0698456720 et 0698456721 sont des numéros d’appelant enregistrés dans la base de données BDC, dont les probabilités ont été calculées à l’étape R10 ou R30, et pour lesquels il a été déterminé qu’ils étaient indésirables (P(SPAM|NUM)>P(OK|NUM)) ; - que les numéros 019845669, 019845677, 019845678, 0698456719 et 0698456722 sont des numéros d’appelant enregistrés dans la base de données BDC, dont les probabilités ont été calculées à l’étape R10 ou R30, et pour lesquels il a été déterminé qu’ils étaient autorisés (P(OK|NUM)>P(SPAM|NUM)). Dans le mode de réalisation décrit ici, on considère en outre que les numéros 019845671 et 019845674 sont des numéros pour lesquels il a été déterminé qu’ils étaient indésirables, à partir de leurs numéros voisins 019845671, 019845672, 019845673, 019845675 et 019845676, comme décrit précédemment en référence aux étapes R20 ou R30. Au cours d’une étape R50, le serveur SERV identifie ensuite dans le tableau TAB; des plages PLi de numéros NUM indésirables. Cette étape consiste par exemple à déterminer les transitions, matérialisées par des traits gras dans le tableau TAB, pour lesquelles P(SPAM|NUM) devient supérieur ou inférieur à P(OK|NUM). Dans l’exemple de réalisation de la figure 4B, le serveur SERV identifie ainsi deux plages de numéros indésirables PL1 = [019845670, …, 019845676] et PL2 = [0698456720, 0698456721]. Au cours d’une étape R60, le serveur SERV détermine ensuite une expression régulière ERi pour chacune des plages Pli. Cette étape peut être effectuée en appliquant la fonction XOR (ou exclusif) à l’ensemble des numéros de la plage sous forme 4-bit. La figure 4C illustre le mécanisme pour la plage PL1. Le résultat de ce calcul permet au serveur de déterminer l’expression régulière. Dans l’exemple décrit : - l’expression régulière obtenue pour la plage PL1 est 01984567[0-6];et - l’expression régulière obtenue pour la plage PL2 est 069845272[0-1]. Le serveur SERV enregistre ensuite les expressions régulières ERi dans la base de données BDERS. La figure 5 représente sous forme d’ordinogramme un procédé de blocage d’appel et un procédé de gestion des appels indésirables conformes à un mode particulier de réalisation de l’invention. Dans le mode de réalisation décrit ici : - le procédé de blocage d’appel est mis en œuvre par le terminal TERM de la figure 1 lorsque son processeur 10 exécute les instructions du programme d’ordinateur PGT ; et - le procédé de gestion des appels est mis en œuvre par le serveur SERV de la figure 1 lorsque son processeur 20 exécute les instructions du programme d’ordinateur PGS. Dans le mode de réalisation décrit ici, lorsque l’utilisateur utilise son terminal TERM pour la première fois, après une première étape générale E2 d’initialisation, le terminal TERM envoie son numéro T au serveur SERV pour s’abonner au service de réception des expressions régulières générées ou mises à jour par ce serveur (étape E4). Il démarre alors trois processus qui seront décrits en détails ci-après, à savoir : - un processus T1 de réception des expressions régulières et de leur mémorisation dans la base de données BDERT de la mémoire non volatile 13 du terminal ; - un processus T2 de gestion des appels reçus par le terminal ; et - un processus T3 de contrôle de gestion du journal LOG du terminal. Dans le mode de réalisation décrit ici, le procédé de gestion des appels indésirables mis en œuvre par le serveur SERV comporte quatre processus, à savoir : - un processus S1 de gestion des abonnements ; - un processus S2 autonome de génération et de mise à jour des expressions régulières ; - un processus S3 de traitement des messages de notification ou de réhabilitation reçus des terminaux ; et - un processus S4 de traitement des requêtes reçues des terminaux. Lorsqu’un terminal TERM envoie (étape E4) son numéro T au serveur SERV pour s’abonner au service de réception d’expressions régulières, le serveur reçoit cette demande d’abonnement au cours d’une étape F2 du processus S1 de gestion des abonnements. Cette étape est suivie par une étape F4 au cours de laquelle le serveur SERV envoie au terminal TERM les expressions régulières que ce serveur mémorise dans sa base de données BDERS. Le terminal TERM reçoit ces expressions régulières au cours d’une étape E10 de son processus T1 et les mémorise dans sa base de données d’expressions régulières BDERT. Lorsque le terminal TERM reçoit un appel, l’appel est détecté par le module RIL du terminal et un test E20 du processus T2 devient positif. Au cours d’une étape E21, le module RIL du terminal TERM détecte le numéro NUM de l’appelant. Au cours d’une étape E22, le terminal TERM détermine si le numéro NUM de l’appelant vérifie au moins une des expressions régulières mémorisées dans la base de données BDERT. Si tel est le cas, le terminal TERM envoie au serveur SERV, au cours d’une étape E23, un message de notification pour l’informer de la réception d’un message indésirable ; dans le mode de réalisation décrit ici, ce message comporte le numéro de l’appelant, le jour J et l’heure H de l’appel. Puis, le terminal TERM bloque l’appel (étape E24) et enregistre l’appel dans le journal LOG (étape E25). Le blocage peut être réalisé par le module RIL. Le message de notification est reçu par le serveur SERV au cours d’une étape F30 de son processus S3 de traitement des messages de notification. Sur réception de ce message, le serveur SERV enregistre le numéro d’appelant, le jour J et l’heure H de cet appel (deuxièmes informations au sens de l’invention) dans la base de données BDCI. De retour au processus T2, si au cours de l’étape E22, le terminal TERM détermine que le numéro NUM de l’appelant ne vérifie aucune des expressions régulières mémorisées dans la base de données BDERT, il envoie, au cours d’une étape E26, une requête au serveur SERV pour lui demander si l’appel reçu à l’étape E20 doit être bloqué. Dans ce mode de réalisation, le terminal TERM met l’appel reçu est en attente jusqu’à réception d’une réponse du serveur SERV. Cette requête comporte le numéro NUM de l’appelant, et éventuellement le jour J et l’heure H de cet appel. Elle est reçue par le serveur SERV au cours d’une étape E40 du processus S4 de traitement de ces requêtes. Au cours d’une étape E42, le serveur SERV détermine, sur la base de premières informations mémorisées dans la base de données de BDC et de deuxièmes informations mémorisées dans la base de données BDCI si cet appel doit être considéré comme un appel indésirable ou non. Dans le mode de réalisation décrit ici, le serveur SERV établit cette détermination en mettant en œuvre les étapes R10 à R40 décrites précédemment à la figure 4A. Dans le mode de réalisation décrit ici, si le serveur SERV détermine au cours de l’étape E42 que l’appel doit être considéré comme indésirable, il enregistre le numéro NUM de l’appelant, le jour J et l’heure H reçus à l’étape E40 dans la base de données BDCI. Dans le mode de réalisation décrit ici, le serveur déclenche alors la génération ou le calcul de nouvelles expressions régulières et l’envoi de ces expressions régulières aux terminaux qu’il gère. Il déclenche pour cela un événement EVT de l’étape F20 décrite ultérieurement. Quel que soit le résultat du test E42 (appel indésirable ou appel autorisé), le serveur SERV envoie ce résultat au terminal TERM. Ce résultat est reçu par le terminal TERM au cours d’une étape E27. Si le serveur a considéré l’appel comme indésirable, l’appel est bloqué par le terminal (étape E24) et l’appel est enregistré comme indésirable dans le journal LOG (étape E25). Sinon l’appel mis en attente est présenté à l’utilisateur ou redirigé vers une messagerie vocale et il est enregistré comme autorisé dans le journal LOG (étape E25). L’utilisateur du terminal TERM peut consulter le journal LOG de son terminal TERM via l’interface homme-machine 13. S’il considère qu’un appel enregistré comme autorisé aurait dû être classifié indésirable, il change son état dans le journal LOG ce qui a pour effet de déclencher l’envoi, par le terminal TERM, au cours d’une étape E30 du processus T3, d’un message de notification au serveur SERV. Ce message de notification comporte le numéro d’appelant, et éventuellement le jour J et l’heure H de l’appel. Il est reçu par le serveur SERV au cours de l’étape F30 de son processus S3. Sur réception de ce message, le serveur SERV enregistre le numéro d’appelant, le jour J et l’heure H de cet appel dans la base de données BDCI. Si au contraire, l’utilisateur considère qu’un appel enregistré comme indésirable aurait dû être classifié autorisé, il change son état dans le journal LOG ce qui a pour effet de déclencher l’envoi, par le terminal TERM, au cours d’une étape E32, d’un message de réhabilitation au serveur SERV. Ce message de notification comporte le numéro d’appelant, et éventuellement le jour J et l’heure H de l’appel. Il est reçu par le serveur SERV au cours de l’étape F30 de son processus S3. Sur réception de ce message de réhabilitation, le serveur SERV vérifie si les deuxièmes données correspondant à cet appel ont été enregistrées dans la base de données BDCI, et si c’est le cas il les supprime. Il ressort de la description ci-dessus que la base de données BDCI comporte les deuxièmes informations sur les appels indésirables reçus par les terminaux TERM gérés par le serveur SERV ou considérés comme tels par les utilisateurs de ces terminaux. Par ailleurs, la base de données BDC, alimentée par l’équipement réseau EQT, comporte les premières informations représentatives de tous les appels reçus par les terminaux gérés par le serveur SERV (numéros appelants, jour et heure des appels), que ces appels soient autorisés ou indésirables. Ces premières et deuxièmes informations sont utilisées par le processus S2 pour générer et mettre à jour les expressions régulières comme décrit précédemment en référence aux figures 4A et 4B. Plus précisément, dans le mode de réalisation décrit ici, le processus S2 comporte une étape F20 de détection d’un événement qui détermine si c’est le moment de générer ou mettre à jour les expressions régulières de la base de données BDERS. Cet événement peut par exemple être détecté à intervalles réguliers ou sur réception d’un message de notification ou de réhabilitation d’un terminal ou lorsqu’il est déterminé à l’étape E42 qu’un numéro suspect s’avère être indésirable. La génération ou la mise à jour des expressions régulières s’effectue au cours d’une étape F22 en appliquant les étapes R50 et R60 décrites précédemment. Procédé de blocage d’un appel téléphonique reçu (E20) par un terminal (TERM), ce procédé comportant : - une étape (E10) de réception d’une expression régulière en provenance d’un serveur ; - une étape (E21) d’obtention d’un numéro appelant d’une entité émettrice dudit appel ; et - une étape (E24) de blocage dudit appel si le numéro vérifie (E22) ladite expression régulière. Procédé de blocage d’un appel téléphonique selon la revendication 1, ce procédé comportant, si le numéro vérifie (E22) ladite expression régulière: - une étape (E23) d’envoi d’un message de notification audit serveur (SERV) pour l’informer de la réception d’un message indésirable, ce message comportant au moins le numéro de l’entité émettrice. Procédé de blocage d’un appel téléphonique selon la revendication 1 ou 2, ce procédé comportant, si le numéro ne vérifie (E22) aucune expression régulière reçue par ledit terminal (TERM) - une étape (E26) d’envoi d’une requête audit serveur (SERV) pour lui demander si ledit appel doit être bloqué ; - une étape de mise en attente dudit appel jusqu’à réception (E27) d’une réponse dudit serveur (SERV) ; et - une étape (E24) de blocage ou non dudit appel en fonction de ladite réponse. Procédé de gestion d’appels téléphoniques indésirables, ce procédé comportant : - une étape (F22) d’obtention de premières informations représentatives des appels reçus par au moins un terminal (TERM), lesdites premières informations comportant au moins les numéros appelant des entités émettrices desdits appels ; - une étape (F30) de réception d’au moins une deuxième information représentative d’un appel indésirable reçu par au moins un terminal (TERM), lesdites deuxièmes informations comportent au moins les numéros appelant des entités émettrices desdits appels ; - une étape (F22) de génération ou de mise à jour d’une expression régulière à partir desdites premières et deuxièmes informations ; et - une étape (F4) d’envoi de ladite expression régulière à au moins un terminal. Procédé de gestion d’appels téléphoniques indésirables selon la revendication 4, ce procédé comportant : - - une étape (E40) de réception d’une requête envoyée par un terminal (TERM), ladite requête comportant au moins un numéro d’appelant d’un appel reçu par ledit terminal (TERM) - une étape (E42) pour déterminer une probabilité que ledit numéro d’appelant soit un numéro indésirable ou un numéro autorisé, à partir desdites premières et deuxièmes informations ; et - une étape (E42) d’envoi d’un message représentatif du résultat de ladite détermination audit terminal (TERM).une étape (F4) d’envoi de ladite expression régulière à au moins un terminal. Procédé de gestion d’appels téléphoniques indésirables selon la revendication 4 ou 5, caractérisé en ce que ladite étape (F22) de génération ou de mise à jour d’une expression régulière utilise une méthode de classification. Procédé de gestion d’appels téléphoniques indésirables selon la revendication 6, caractérisé en ce que ladite étape (F22) de génération ou de mise à jour d’une expression régulière utilise (R10, R20) un classifieur de Bayes. Procédé de gestion d’appels téléphoniques indésirables selon l’une quelconque des revendications 4 à 7, caractérisé en ce qu’il comporte : - une étape (R20) de détermination, à partir desdites premières et deuxièmes informations, d’une probabilité qu’un numéro d’appelant soit un numéro autorisé ou indésirable ; et en ce que : lesdites expressions régulières sont générées ou mises à jour à partir de ces distributions de numéros d’appelant construites sur la base desdites statistiques. Procédé de gestion d’appels téléphoniques indésirables selon la revendication 8, caractérisé en ce que ladite probabilité d’au moins un numéro appelant est obtenue à partir desdites probabilités déterminées pour des numéros voisins de ce numéro appelant. Terminal (TERM) comportant : - une unité (ET1) de réception d’une expression régulière en provenance d’un serveur ; - une unité (ET2) d’obtention d’un numéro appelant d’une entité émettrice dudit appel ; et - une unité (ET3) de blocage dudit appel si le numéro vérifie (E22) ladite expression régulière. Serveur (SERV) comportant : - une unité (ES1) d’obtention de premières informations représentatives des appels reçus par au moins un terminal (TERM), lesdites premières informations comportant au moins les numéros appelant des entités émettrices desdits appels ; - une unité (ES2) de réception d’au moins une deuxième information représentative d’un appel indésirable reçu par au moins un terminal (TERM), lesdites deuxièmes informations comportent au moins les numéros appelant des entités émettrices desdits appels ; - une unité (ES3) de génération ou de mise à jour d’une expression régulière à partir desdites premières et deuxièmes informations ; et - une étape (ES4) d’envoi de ladite expression régulière à au moins un terminal. Programme d’ordinateur (PGT) comportant des instructions pour l’exécution des étapes du procédé de blocage d’appel selon l’une quelconque des revendications 1 à 3 lorsque ledit programme est exécuté par un ordinateur. Programme d’ordinateur (PGS) comportant des instructions pour l’exécution des étapes du procédé de gestion des appels indésirables selon l’une quelconque des revendications 4 à 9 lorsque ledit programme est exécuté par un ordinateur.