Brevet FR2978004A1 — publié le 20130118

La présente invention concerne la gestion des appels dans les téléphones et plus particulièrement un procédé et un dispositif de contrôle d'appels, notamment dans les téléphones mobiles. L'identification des appels entrants dans un téléphone permet à son utilisateur de répondre à un appel ou non selon l'identité de l'appelant et selon le contexte de l'appel. Par exemple, un utilisateur peut décider de ne pas prendre l'appel d'un membre de sa famille lorsqu'il est en réunion mais de prendre les appels de ses collègues. Réciproquement, en soirée, cet utilisateur peut décider de prendre les appels des membres de sa famille mais de rejeter les appels de ses collègues. A ces fins, lorsqu'un appel entrant est détecté, le téléphone appelé identifie et affiche le numéro de téléphone de l'appelant, sauf si ce dernier souhaite masquer son identité, ou son nom si une base de données du téléphone associe le nom au numéro de téléphone appelant. Certains téléphones sont d'ailleurs pourvus de filtres permettant de filtrer les appels entrants et/ou sortants de telle sorte que tous les appels non reçus depuis ou émis vers des interlocuteurs identifiés dans une base de données mémorisée dans le téléphone soient rejetés. Un tel exemple de réalisation est notamment décrit dans la demande de brevet WO 2009/098289. Par ailleurs, les téléphones comprennent généralement une mémoire dans laquelle sont mémorisées toutes les identités des interlocuteurs appelants et appelés. Une application logicielle permet d'accéder à ces identifiants qui peuvent être affichés sous forme d'un journal. Typiquement, le journal d'un téléphone comprend une liste d'identifiants d'appels sans réponse, une liste d'identifiants d'appels reçus et une liste d'identifiants d'appels émis. En outre, certains téléphones affichent automatiquement la liste des identifiants des appelants lorsqu'aucune action n'a été prise en réponse aux appels entrants correspondants. Ainsi, lorsqu'un utilisateur active son téléphone, une liste, généralement appelée « appels en absence », s'affiche automatiquement pour donner les numéros de téléphone ou les noms des personnes ayant cherché à joindre l'utilisateur du téléphone. Cet utilisateur peut alors rappeler ces personnes. Selon certaines études, une proportion importante d'utilisateurs rappelle les numéros présentés dans la liste des « appels en absence » sans chercher au préalable l'identité des personnes ayant appelé. Profitant de ce phénomène de rappel « à l'aveugle », certaines personnes mal intentionnées ont récemment développé une escroquerie connue sous le nom de « ping ce». Celle-ci consiste à appeler, depuis un serveur et avec un numéro fortement surtaxé, un grand nombre de numéros et à raccrocher avant que l'utilisateur ou son répondeur ne réponde de façon à ne pas payer le coût de la communication. Un nombre important d'utilisateurs ainsi appelés rappellent le numéro les ayant appelés, fortement surtaxé, en utilisant la fonction de rappel du téléphone. Ces utilisateurs tombent alors sur une messagerie vocale et payent le prix surtaxé de la communication. II existe donc un besoin pour contrôler les appels sortants de téléphones, émis en réponse à des appels entrants. L'invention permet de résoudre au moins un des problèmes exposés 20 précédemment. L'invention a ainsi pour objet un procédé de contrôle d'appels sortants en réponse à des appels entrants, le procédé étant mis en oeuvre dans un téléphone comprenant des moyens de mémorisation d'identifiants de dispositifs pouvant être appelés par ledit téléphone, des moyens d'obtention 25 d'un identifiant d'un dispositif appelant ledit téléphone, des moyens d'obtention d'un identifiant d'un dispositif appelé par ledit téléphone et des moyens pour rejeter un appel sortant, ce procédé comprenant les étapes suivantes, - lorsqu'un appel entrant est détecté, o obtention d'un identifiant d'un dispositif duquel est reçu ledit appel 30 entrant, appelé identifiant reçu ; o évaluation d'au moins une caractéristique dudit appel entrant, ladite au moins une caractéristique étant distincte dudit identifiant reçu ; et, o si ladite au moins une caractéristique évaluée est conforme à au moins une condition prédéterminée, sélection et mémorisation dudit identifiant obtenu dans une liste d'identifiants suspects lorsqu'un appel sortant est détecté, o obtention d'un identifiant d'un dispositif appelé visé par ledit appel sortant, appelé identifiant émis ; o comparaison dudit identifiant émis avec au moins un identifiant de ladite liste d'identifiants suspects pour déterminer si ledit identifiant émis est présent dans ladite liste ; et, o en réponse à la dite étape de comparaison, si ledit identifiant émis est présent dans ladite liste, demande de validation dudit appel sortant. Le procédé selon l'invention permet ainsi de déterminer automatiquement des identifiants devant être considérés comme suspects afin, par exemple, d'éviter à un utilisateur d'être surtaxé lorsqu'il rappelle un dispositif ayant cherché à établir une communication, selon des caractéristiques liées à cette tentative d'établissement d'une communication. Selon un mode de réalisation particulier, ladite étape d'évaluation d'au moins une caractéristique dudit appel entrant comprend une étape de lancement d'une fonction de décompte. Ainsi, un identifiant d'un appelant peut être considéré comme suspect en fonction de la durée de signalisation d'un appel en provenance de cet appelant, avant qu'il ne soit mis fin à cet appel (sans qu'il n'y soit répondu). De façon avantageuse, ledit identifiant reçu ne peut être sélectionné et mémorisé que si la valeur décomptée atteint une valeur prédéterminée. Ainsi, un identifiant d'un appelant est ici considéré comme suspect si l'appelant met fin à l'appel, avant qu'il y soit répondu, dans un délai inférieur à un délai prédéterminé. Le procédé comprend en outre, de préférence, une étape d'arrêt de ladite fonction de décompte, ladite étape d'arrêt étant déclenchée lorsqu'il est mis fin audit appel entrant, pour déterminer si un identifiant doit être considéré comme suspect ou non. Selon un mode de réalisation particulier, ledit identifiant reçu ne peut être sélectionné et mémorisé que si ledit identifiant reçu n'appartient pas à une liste d'identifiants autorisés. Ainsi, un identifiant dûment autorisé ne peut être considéré comme suspect. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape d'affichage d'un message de demande de validation dudit appel sortant pour signaler un identifiant suspect et une étape de réception d'une commande de validation, ledit appel sortant étant émis en réponse à ladite commande de validation, afin qu'un appel ne soit émis qu'après que l'utilisateur ait effectivement été prévenu des risques encourus. Alternativement, le procédé comprend en outre une étape d'affichage d'un message de demande de validation dudit appel sortant pour signaler un identifiant suspect et une seconde étape de détection d'un second appel sortant, ledit appel sortant étant appelé premier appel sortant, ledit second appel sortant étant émis si l'identifiant d'un dispositif appelé visé par ledit second appel sortant est similaire à l'identifiant d'un dispositif appelé visé par ledit premier appel sortant, afin qu'un appel ne soit émis qu'après que l'utilisateur ait effectivement été prévenu des risques encourus. L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté dans un microcontrôleur ou un microprocesseur ainsi qu'une carte de type SIM comprenant des moyens de stockage, lesdits moyens de stockage comprenant un tel programme d'ordinateur et des moyens de calcul adaptés à mettre en oeuvre ce programme d'ordinateur. Selon un mode de réalisation particulier, lesdits moyens de stockage de la carte de type SIM mémorisent ladite liste d'identifiants suspects. Les avantages procurés par ce programme d'ordinateur et cette carte de type SIM sont similaires à ceux évoqués précédemment. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, 5 au regard des dessins annexés dans lesquels : - La figure 1 représente schématiquement un téléphone comprenant une carte d'identification de type SIM permettant la mise en oeuvre de l'invention ; - la figure 2 illustre certaines étapes d'un exemple d'algorithme mis 10 en oeuvre dans un téléphone mobile pour contrôler les appels sortants d'un téléphone conformément à l'invention, suite à la réception d'un appel entrant ; - la figure 3 illustre un exemple d'algorithme pour identifier des dispositifs appelants considérés comme suspects, pour lesquels les appels sortants doivent être abandonnés s'ils ne sont pas validés ; et, 15 - les figures 4 et 5 illustrent certaines étapes d'un premier et d'un second exemples d'algorithme de validation d'appels lorsqu'un appel sortant est identifié comme suspect. De façon générale, l'invention permet de contrôler les appels sortants dans un téléphone en comparant l'identifiant du dispositif appelé avec 20 une liste d'identifiants préalablement mémorisés de telle sorte que les appels sortants dont l'identifiant du dispositif appelé figure dans la liste soient rejetés s'ils ne sont pas validés. La liste des identifiants comprend des identifiants de dispositifs desquels des appels ont été reçus complétée, le cas échéant, d'identifiants reçus d'opérateurs ou de tiers. 25 La liste d'identifiants contient ainsi des identifiants de dispositifs susceptibles d'être appelés et pour lesquels les appels sortants doivent être abandonnés s'ils ne sont pas validés. Ces identifiants sont, par exemple, les numéros de téléphone des dispositifs appelés. La liste des identifiants peut en outre être gérée de façon locale en 30 ajoutant des identifiants reçus dans des appels entrants ou dans des messages textes reçus. L'utilisateur peut également entrer ou supprimer manuellement des identifiants. Selon un mode de réalisation particulier, l'invention est mise en oeuvre dans un téléphone mobile de type GSM (sigle de Global System for Mobile communications en terminologie anglo-saxonne), de type UMTS (sigle d'Universal Mobile Telecommunications System en terminologie anglo- saxonne) ou de type CDMA (sigle de Code Division Multiple Access en terminologie anglo-saxonne), par exemple dans une carte à microcircuits d'identification auprès d'un réseau de téléphonie mobile ou une carte de souscription à un réseau de téléphonie mobile (carte d'abonnement ou carte prépayée) telle qu'une carte de type SIM (acronyme de Subscriber Identity Module en terminologie anglo-saxonne) ou une carte de type UICC (acronyme d'Universal lntegrated Circuit Card en terminologie anglo-saxonne). Une telle carte, appelée carte de type SIM dans la suite de la description, contient généralement un microcontrôleur et de la mémoire, typiquement de la mémoire de type ROM (sigle de Read Only Memory en terminologie anglo-saxonne) ou EEPROM (sigle de Electrically-Erasable Programmable Read-Only Memory en terminologie anglo-saxonne). Elle est utilisée pour stocker des informations propres à l'abonné et à l'opérateur d'un réseau mobile. Elle permet également de stocker des applications de l'utilisateur, de son opérateur ou dans certains cas de tierces parties. La figure 1 illustre un exemple d'architecture d'un téléphone mobile comprenant une carte de type SIM, adapté à mettre en oeuvre l'invention. Comme illustré, le téléphone mobile 100 comprend un module 105 de téléphonie mobile, avantageusement relié à un haut-parleur 110 et à un microphone 115. Le téléphone mobile 100 comprend également une unité centrale de traitement 120, aussi appelée CPU (sigle de Central Processing Unit en terminologie anglo-saxonne), une mémoire 125 et, de préférence, un écran 130 et une interface utilisateur 135 tel qu'un clavier ou un dispositif tactile pouvant notamment être intégré à l'écran 130. L'interface utilisateur 135 permet notamment de saisir des chiffres d'un numéro de téléphone à composer, de sélectionner un identifiant d'un interlocuteur préalablement mémorisé afin d'émettre un appel à destination de celui-ci et plus généralement de naviguer dans des menus du système d'exploitation et des applications mis en oeuvre dans le téléphone mobile 100. Le téléphone mobile 100 comprend aussi un lecteur de carte 140. L'unité centrale de traitement 120 est connectée au module de téléphonie 105, à la mémoire 125, à l'écran 130, à l'interface utilisateur 135 et au lecteur de carte 140 pour mettre en oeuvre les fonctions généralement proposées par les téléphones mobiles. Une carte de type SIM 145 est ici connectée au lecteur de carte 140 du téléphone mobile 100. La carte de type SIM 145 comprend un microcontrôleur 150 ainsi qu'une mémoire 155, par exemple une mémoire de type ROM et/ou de type EEPROM. Le microcontrôleur 150 et la mémoire 155 sont typiquement reliés entre eux et au lecteur de carte dans lequel la carte de type SIM est insérée. Selon un mode de réalisation particulier, la mémoire 155 de la carte de type SIM est utilisée pour mémoriser l'application mettant en oeuvre l'invention ainsi que la liste des identifiants correspondant à des dispositifs pour lesquels les appels sortants doivent être abandonnés s'ils ne sont pas validés par l'utilisateur. Alternativement, l'application mettant en oeuvre l'invention est mise en oeuvre dans la carte de type SIM 145 tandis que la liste des identifiants est mémorisée dans la mémoire 125 du téléphone mobile 100. Alternativement encore, l'application mettant en oeuvre l'invention est mise en oeuvre dans l'unité centrale de traitement 120 du téléphone mobile 100 tandis que la liste des identifiants est mémorisée dans la mémoire 125 du téléphone mobile 100 ou dans la mémoire 155 de la carte de type SIM 145. La figure 2 illustre certaines étapes d'un exemple d'algorithme mis en oeuvre dans un téléphone mobile pour contrôler les appels sortants d'un téléphone conformément à l'invention. Une première étape (étape 200) a ici pour objet de sélectionner et mémoriser un ou plusieurs identifiants, par exemple des numéros de téléphones, correspondant à des dispositifs à destination desquels les appels sortants doivent être validés. Ces identifiants sont ici mémorisés dans une base de données 205 stockée dans une mémoire du téléphone mobile ou dans une mémoire d'une carte, par exemple une carte de type SIM, insérée dans le téléphone mobile. Ils représentent des identifiants de dispositifs suspects, c'est-à-dire de dispositifs susceptibles d'entraîner des coûts ou des nuisances masqués à l'utilisateur du téléphone mobile. Comme décrit en référence à la figure 3, l'étape 200 est ici réalisée au moins partiellement de façon automatique, transparente pour l'utilisateur, selon des caractéristiques d'appels reçus. Cependant, la liste d'identifiants peut être complétée par des identifiants reçus de tiers, par exemple, sur commande du tiers fournissant une liste d'identifiants, sur commande de l'utilisateur du téléphone mobile, par exemple suite à la réception d'un message l'information de l'existence d'une telle liste ou de l'existence d'une mise à jour de cette liste, ou de façon périodique, par exemple toutes les semaines ou tous les mois. Une liste initiale d'identifiants peut également être chargée dans la carte de type SIM utilisée lors de la personnalisation de la carte. Une étape suivante (étape 210), optionnelle, permet à l'utilisateur du téléphone mobile de gérer la liste d'identifiants mémorisée dans la base de données 205 pour, notamment, ajouter ou supprimer des identifiants. Lors de la détection d'un appel sortant (étape 215), l'identifiant du dispositif appelé est obtenu (étape 220). L'obtention de cet identifiant peut notamment être réalisée à l'aide de fonctions existantes dans le téléphone mobile comme décrit ci-dessous. L'identifiant du dispositif appelé est alors comparé (étape 225) à la liste des identifiants préalablement reçus et mémorisés dans la base de données 205. Cette comparaison de l'identifiant du dispositif appelé avec des identifiants de la liste d'identifiants peut être complétée, le cas échéant, par une comparaison de l'identifiant du dispositif appelé avec une ou plusieurs règles prédéfinies pour déterminer si l'identifiant du dispositif appelé vérifie ou non l'une de ces règles, c'est-à-dire pour déterminer si l'identifiant est compris dans un groupe d'identifiants suspects définis par une de ces règles. Un test (étape 230) est ensuite effectué pour déterminer si l'identifiant du dispositif appelé figure dans la liste des identifiants préalablement mémorisés (ou s'il appartient à un groupe d'identifiants suspects). Dans l'affirmative, une demande de validation est émise (étape 235) pour permettre à l'utilisateur de confirmer l'appel en dépit de la présence de l'identifiant du dispositif appelé dans la liste des identifiants préalablement mémorisés. Un test est alors effectué pour déterminer si l'utilisateur confirme ou non l'appel sortant (étape 240). Des exemples de mises en oeuvre de ces étapes de demande de validation d'appels sortants sont décrits en référence aux figures 3 et 4 décrites ci-dessous. Il est observé ici que les étapes de validation 235 et 240 peuvent ne pas être mises en oeuvre, notamment lorsque le paramétrage du dispositif utilisé est tel qu'il est interdit de composer un numéro identifié comme suspect et/ou frauduleux. Il est également possible d'associer une information de sévérité aux numéros suspects, allant de numéros fournis par un operateur (numéro avéré payant) aux numéros considérés comme suspects par l'algorithme décrit ici mais ne rentrant pas dans un schéma de numéros surtaxés. Une telle information de sévérité permet alors d'adapter le texte du message et/ou bloquer un appel sans demander d'autorisation à l'utilisateur. Si l'appel sortant n'est pas validé, c'est-à-dire si l'utilisateur du téléphone mobile ne confirme pas son intention d'appeler le dispositif identifié, l'appel sortant est abandonné (étape 245). Un message peut être affiché pour avertir l'utilisateur de l'abandon de l'appel sortant. Au contraire, si l'appel sortant est validé par l'utilisateur (étape 240) ou si l'identifiant du dispositif appelé ne figure pas dans la liste des identifiants mémorisés (étape 230), l'appel sortant est traité de façon classique (étape 250). Typiquement, dans ce cas, le numéro de téléphone correspondant à l'identifiant est composé. Comme suggéré par les flèches en trait pointillé, l'algorithme illustré sur la figure 2 est répété pour traiter de nouveaux appels entrants, recevoir des listes d'identifiants considérés comme suspects, des mises à jour de telles listes et traiter tous les appels sortants. La figure 3 illustre un exemple d'algorithme pour identifier des dispositifs appelants considérés comme suspects, c'est-à-dire déterminer des identifiants de dispositifs susceptibles d'être appelés et pour lesquels les appels sortants doivent être abandonnés s'ils ne sont pas validés. Une première étape (étape 300) a pour objet la détection d'appels entrants. Dès qu'un appel entrant est détecté, une fonction de décompte, aussi appelée timer en terminologie anglo-saxonne, est lancée (étape 305). Une telle fonction consiste en un compte à rebours à partir d'une valeur prédéterminée, le compte à rebours étant typiquement indexé sur une horloge du dispositif dans lequel est mise en oeuvre la fonction. L'identifiant de l'appelant, par exemple un numéro de téléphone, est alors obtenu (étape 310). Selon un mode de réalisation particulier, cet identifiant est affiché. Dans une étape suivante, un test est effectué pour déterminé s'il est répondu à l'appel entrant (étape 315). Dans l'affirmative, il est mis fin au procédé, l'identifiant du dispositif appelant étant typiquement mémorisé en mémoire dans une liste d'appels reçus. Dans la négative (parallèlement ou précédemment), un test est effectué pour déterminer s'il a été mis fin à l'appel en cours (étape 320), c'est-à-dire si l'appelant à mis fin à l'appel en cours ou si une opération s'est déclenchée, par exemple la redirection de l'appel vers une messagerie ou vers un autre dispositif (transfert d'appel). S'il n'a pas été mis fin à l'appel en cours (par l'appelant, l'appelé ou de façon automatique), les étapes 315 et 320 sont répétées. Si, au contraire, il a été mis fin à l'appel en cours (par l'appelant, l'appelé ou de façon automatique), un nouveau test est effectué pour déterminer si le décompte a été atteint (étape 325), c'est-à-dire, typiquement, si la valeur du compteur utilisé, décrémentée périodiquement de un a atteint la valeur zéro. Dans l'affirmative, il est mis fin au procédé, l'identifiant du dispositif appelant étant typiquement mémorisé en mémoire dans une liste dite des appels en absence. Si, au contraire, le décompte n'a pas été atteint, un autre test est effectué pour déterminer si l'identifiant de l'appelant est connu de l'appelé (étape 330), c'est-à-dire, par exemple, s'il figure dans un répertoire de l'appelé (aussi appelé ADN, sigle d'Abbreviated Dialing Number, ou phonebook en terminologie anglo-saxonne). Si l'identifiant de l'appelant est connu de l'appelé, il est mis fin au procédé, l'identifiant du dispositif appelant étant typiquement mémorisé en mémoire dans une liste dite des appels en absence. Si, au contraire, l'identifiant de l'appelant n'est pas connu de l'appelé, cet identifiant est sélectionné et mémorisé dans le dispositif de l'appelé en tant qu'identifiant suspect (étape 335), c'est-à-dire en tant qu'identifiant d'un dispositif qui ne peut être appelé qu'après confirmation expresse de l'utilisateur. De façon optionnelle, un message d'alerte est présenté à l'utilisateur (étape 340), par exemple sous forme de message textuel sur l'écran du téléphone. La figure 4 illustre certaines étapes d'un premier exemple d'algorithme de validation d'appels lorsqu'un appel sortant est identifié comme suspect. L'algorithme illustré ici est, par exemple, appelé suite à l'étape 230 représentée sur la figure 2 lorsque l'identifiant du dispositif appelé appartient à la liste des identifiants mémorisés dans la base de données 205. Une première étape (étape 400) vise à afficher un message d'avertissement à destination de l'utilisateur, l'invitant à confirmer son choix concernant l'appel sortant. Un tel message est, par exemple, le message « Attention, le numéro appelé peut engendrer des frais de communication importants. Voulez-vous confirmer cet appel ? ». Ce message est typiquement affiché sur l'écran 130 du téléphone 100 illustré sur la figure 1. En réponse, l'utilisateur utilise l'interface homme-machine à sa disposition, par exemple un clavier ou une interface tactile, pour confirmer l'appel sortant ou l'annuler. La touche de validation correspond par exemple à la touche « OK» du téléphone tandis que la touche annuler correspond à la touche « raccrocher». Il peut également s'agir de touche contextuelle. Si l'utilisateur valide (étape 405) l'appel sortant, ce dernier est émis (étape 410), c'est-à-dire que le numéro de téléphone correspondant à l'identifiant est composé. Dans le cas contraire, si l'utilisateur annule l'appel sortant, celui-ci est abandonné (étape 415). Un message peut être affiché pour avertir l'utilisateur de l'abandon de l'appel sortant. De façon avantageuse, un compte à rebours est mis en oeuvre pour éviter une manipulation erronée. Ainsi, lorsque le message de validation est affiché (étape 400), un compteur est déclenché après avoir été réinitialisé (étape 420). Un test est effectué pour comparer la valeur de ce compteur avec une valeur prédéterminée (étape 425). Dès que la valeur du compteur est égale à la valeur prédéterminée, c'est-à-dire dès que le temps prédéterminé est écoulé, l'appel sortant est abandonné (étape 415). Ainsi, si l'utilisateur n'a pas confirmé l'appel sortant dans un temps donné, cet appel est abandonné. Il est observé ici que si, conformément à l'algorithme représenté sur la figure 4, le délai prédéterminé est initialisé lors de l'affichage du message de validation, il peut également être initialisé à la détection de l'appel sortant à l'origine de l'algorithme de validation ou à tout autre instant lié à cet appel sortant. La figure 5 illustre certaines étapes d'un second exemple d'algorithme de validation d'appels lorsqu'un appel sortant est identifié comme suspect. L'algorithme illustré ici est, par exemple, appelé suite à l'étape 230 représentée sur la figure 2 lorsque l'identifiant du dispositif appelé appartient à la liste des identifiants mémorisés dans la base de données 205. Il peut notamment être utilisé lorsque le téléphone mettant en oeuvre l'invention ne permet pas de valider un appel sortant, c'est-à-dire ne permet que d'abandonner, le cas échéant, un appel sortant. Une première étape (étape 500) consiste à afficher un message d'avertissement à l'utilisateur l'invitant à renouveler l'appel sortant s'il le confirme. Un tel message est, par exemple, le message « Attention, le numéro appelé peut engendrer des frais de communication importants. Si vous souhaitez confirmer cet appel, veuillez le renouveler dans un délai de 20 secondes ». Ce message est typiquement affiché sur l'écran 130 du téléphone 100 illustré sur la figure 1. Le numéro de téléphone appelé ou l'identifiant du dispositif appelé est mémorisé de façon temporaire (étape 505), par exemple dans une variable appelée identifiant temporaire. Si une donnée était mémorisée dans cette variable, elle est remplacée par la valeur de l'identifiant associé à l'appel sortant. L'appel sortant est ici abandonné. L'utilisateur doit renouveler son appel dans un délai imparti s'il veut le confirmer. Suite au message d'invitation à répéter l'appel sortant (étape 500) et à l'abandon de celui-ci, l'appel sortant suivant est détecté (étape 510) et le numéro de téléphone appelé ou l'identifiant du dispositif appelé est obtenu (étape 515). Il est observé ici que les étapes 510 et 515 sont similaires aux étapes 215 et 220 décrites précédemment. L'identifiant associé à l'appel sortant est ensuite comparé avec celui mémorisé précédemment (étape 520), mémorisé ici dans la variable identifiant temporaire. Si l'identifiant associé à l'appel sortant est identique à celui préalablement mémorisé, l'appel sortant est traité de façon standard (étape 525). Typiquement, le numéro de téléphone correspondant à l'identifiant est composé. Si, au contraire, l'identifiant associé à l'appel sortant n'est pas identique à celui préalablement mémorisé, des étapes similaires à celles décrites en référence aux étapes 230 à 250 sont exécutées pour déterminer si l'appel sortant doit être traité ou faire l'objet d'une confirmation de l'utilisateur conformément aux étapes décrites précédemment (étapes 500 à 525). De façon avantageuse, un compte à rebours est mis en oeuvre pour éviter une manipulation erronée. Ainsi, lorsque le message invitant l'utilisateur à renouveler son appel est affiché (étape 500), un compteur est déclenché après avoir été réinitialisé (étape 530). Un test est effectué pour comparer la valeur de ce compteur avec une valeur prédéterminée (étape 535). Dès que la valeur du compteur est égale à la valeur prédéterminée, c'est-à-dire dès que le temps prédéterminé est écoulé, l'algorithme décrit en référence à la figure 5 prend fin. Ainsi, si l'utilisateur n'a pas confirmé l'appel sortant dans un temps donné, cet appel ne peut plus faire l'objet d'une confirmation par le renouvellement de l'appel, le renouvellement de l'appel devant alors être confirmé pour être traité. En d'autres termes, si l'utilisateur n'a pas renouvelé son appel dans le délai imparti, l'appel est considéré comme abandonné. Il est observé ici que si, conformément à l'algorithme représenté sur la figure 5, le délai prédéterminé est initialisé lors de l'affichage du message invitant l'utilisateur à répéter son appel, il peut également être initialisé à la détection de l'appel sortant à l'origine de l'algorithme de validation ou à tout autre instant lié à cet appel sortant. L'invention peut être mise en oeuvre sous la forme d'une applet Java Card (Java Card est une marque), c'est-à-dire d'une application utilisant les fonctionnalités d'une machine virtuelle Java (Java est une marque), dans une carte de type SIM. Cette applet est mémorisée en mémoire, par exemple en mémoire ROM ou EEPROM de la carte de type SIM. Il est observé ici que la technologie Java Card offre un environnement d'exécution sécurisé pour des applications exécutées sur des cartes à microcircuits comprenant des ressources limitées. Des applets Java Card peuvent être installées lors de la fabrication des cartes à microcircuits dans lesquelles elles sont exécutées ou ultérieurement. De façon avantageuse, l'applet Java Card est basée sur des mécanismes de la boîte à outil connue sous le nom de SIM Application Toolkit (SAT). Cette dernière consiste en un ensemble de commandes préprogrammées dans la carte de type SIM qui définissent la façon dont la carte interagit avec l'extérieur et permet d'initier des commandes indépendamment du téléphone mobile et du réseau. Elle autorise ainsi des échanges interactifs entre une application, un utilisateur et un accès réseau. Par ailleurs, l'applet Java Card mise en oeuvre pour contrôler les appels sortants utilise ici le mécanisme appelé CALL CONTROL du SAT (selon la norme GSM) selon lequel une table de service mémorisée dans la mémoire de la carte de type SIM, par exemple contenue dans le fichier EF SST conformément à la norme GSM, indique quelles sont les fonctionnalités activées dans la carte de type SIM. Si ce fichier indique que le CALL CONTROL est activé, le téléphone soumet systématiquement à la carte de type SIM chaque numéro appelé dès qu'un appel est initié par l'utilisateur. Ceci est réalisé par une commande de type APDU (sigle d'Application Protocol Data Unit en terminologie anglo-saxonne) connue sous le nom d'ENVELOPE (CALL CONTROL), la commande ENVELOPE permettant d'envoyer des données à la carte. II est rappelé ici qu'APDU est défini dans la norme ISO/IEC 7816 pour permettre la communication entre une carte à microcircuits et un lecteur d'une telle carte. Les messages APDU, dont la structure est définie dans la norme ISO/IEC 7816, peuvent être des commandes ou des réponses, les commandes étant émises par le lecteur et les réponses étant émises par les cartes à microcircuits. Par ailleurs, l'applet mettant en oeuvre l'invention est ici déclarée comme étant déclenchée par l'événement ENVELOPE (CALL CONTROL). Ainsi, une applet étant, selon la technologie Java Card, déclarée comme étant déclenchée par un événement, l'applet mettant en oeuvre l'invention reçoit tous les numéros que l'utilisateur tente d'appeler ainsi que les numéros des dispositifs tentant d'appeler le téléphone en question. Utilisant le mécanisme CALL CONTROL, la carte de type SIM répond à la commande APDU ENVELOPE en indiquant qu'elle accepte l'appel, qu'elle refuse l'appel ou en indiquant un autre numéro à utiliser pour l'appel. Selon un mode de réalisation particulier, l'applet mettant en oeuvre l'invention contient les données d'exclusion, c'est-à-dire les identifiants des dispositifs appelés pour lesquels les appels sortants doivent être abandonnés. Ces données d'exclusion sont, par exemple, les numéros de téléphone des dispositifs appelés. Ces données d'exclusion peuvent également être mémorisées, en totalité ou en partie, dans une mémoire de la carte de type SIM associée à l'applet mettant en oeuvre l'invention et lues par cette applet lors de son exécution ou dans une mémoire du téléphone accessible par cette applet. Au moins certaines des données d'exclusion sont déterminées lors de la réception d'appels entrants comme décrit en référence à la figure 3, d'autres pouvant être obtenues, par exemple, via le réseau de téléphonie mobile en utilisant un mécanisme connu sous le nom de DATA DOWNLOAD TO SIM selon la norme GSM. Selon un mode de réalisation particulier, lorsqu'un appel entrant est reçu par un téléphone mobile mettant en oeuvre l'invention, un événement de type MT cal/ est transmis par le téléphone mobile à la carte de type SIM utilisée pour le lui indiquer. En réponse à la réception de cet événement, la carte de type SIM adresse alors au téléphone mobile une commande d'activation d'une fonction de décompte en spécifiant la valeur initiale de décompte, représentant une durée, par exemple deux ou trois secondes. Cette fonction est ici la fonction START TIMER, associée à la commande TIMER MANGEMENT, dans laquelle il est possible de spécifier une durée. La fonction de décompte déclenchée par la carte de type SIM est ainsi une fonction de décompte du téléphone mobile. Lorsqu'il est mis fin à l'appel, à l'initiative de l'appelant, de l'appelé ou autre, un événement de type cal/ disconnected est transmis par le téléphone mobile à la carte de type SIM utilisée pour le lui indiquer. De même, lorsque l'appel entrant est accepté par l'appelé, un événement de type cal/ connected est transmis par le téléphone mobile à la carte de type SIM utilisée pour le lui indiquer. De façon similaire, un événement de type timer expiration est transmis par le téléphone mobile à la carte de type SIM utilisée lorsque la durée visée par la fonction de décompte expire. Les événements type MT cati, cal/ disconnected, cal/ connected et timer expiration sont transmis dans les commandes ENVELOPE(MT call), ENVELOPE(call disconnected), ENVELOPE(call connected), ENVELOPE(timer expiration), respectivement. Ces commandes permettent ainsi à l'applet Java Card utilisée de mettre en oeuvre un algorithme tel que celui décrit en référence à la figure 3 pour mémoriser des identifiants devant être considérés comme suspects. En effet, conformément à cet algorithme, un identifiant d'un appelant est considéré comme suspect par la carte de type SIM si un événement de type cal/ disconnected est reçu avant un événement de type timer expiration lié au même appel entrant et si l'identifiant de l'appelant n'appartient pas à un répertoire autorisé de l'appelé (ADN ou phonebook). II est observé ici que, selon l'implémentation choisie, déterminer qu'un identifiant doit être considéré comme suspect peut être réalisé lors de la réception d'un événement de type cal/ disconnected ou d'un événement de type timer expiration. Par ailleurs, la réception d'un événement de type cal/ connected peut être utilisée pour supprimer un identifiant d'appelant qui serait considéré comme suspect afin qu'il ne soit plus considéré comme tel. Lorsque l'utilisateur d'un téléphone mobile interagit avec l'interface homme-machine de ce dernier via, par exemple, un écran tactile ou un clavier, pour initier un appel téléphonique vers un dispositif téléphonique, l'applet mettant en oeuvre l'invention reçoit un identifiant du dispositif appelé, par exemple un numéro de téléphone. Ce numéro est reçu du téléphone mobile, plus précisément du lecteur de carte de type SIM, dans une commande ENVELOPE (CALL CONTROL). L'applet vérifie alors si le numéro reçu doit être filtré ou non en fonction du numéro et des données d'exclusion, c'est-à-dire si l'appel sortant doit être abandonné ou non. Si le numéro ne doit pas être filtré, l'applet mettant en oeuvre l'invention répond à la commande APDU ENVELOPE (CALL CONTROL), dans un message de réponse APDU, en indiquant qu'elle accepte l'appel. Si, au contraire, le numéro doit être filtré, l'applet mettant en oeuvre l'invention répond à la commande APDU ENVELOPE (CALL CONTROL) en indiquant au téléphone que l'appel doit être abandonné. Elle commande alors la saisie d'une confirmation par l'utilisateur, via l'interface homme-machine du téléphone, par exemple en envoyant au téléphone une commande SAT GET INPUT affichant par exemple un message « Attention, cet appel peut être fortement surtaxé, veuillez confirmer » et obtenant la réponse de l'utilisateur. Si l'utilisateur confirme l'appel, l'applet envoie une commande SAT SET UP CALL au téléphone mobile déclenchant l'appel vers le numéro par le téléphone. Dans le cas contraire, l'appel est rejeté. En variante, pour les téléphones ne supportant pas la commande SAT SET UP CALL, l'applet envoie une commande DISPLAY TEXT pour afficher le message « Attention, cet appel peut être fortement surtaxé, vous avez 20 secondes pour rappeler ce numéro ». Si dans les vingt secondes suivant l'affichage du message, l'applet reçoit à nouveau la commande ENVELOPE (CALL CONTROL) avec le même numéro, l'applet répond au téléphone en indiquant qu'elle accepte l'appel bien qu'il s'agisse d'un numéro devant être filtré. Il est observé ici que si certains téléphones mobiles ne supportent pas la commande SET UP CALL, la plupart des téléphones mobiles supportent la commande DISPLAY TEXT ou GET INPUT. A la mise sous tension de la carte et du téléphone, l'applet peut être informée si le téléphone supporte la commande SET UP CALL de façon à déterminer si cette variante doit être mise en oeuvre ou non. Naturellement, pour satisfaire des besoins spécifiques, une personne 10 compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente. REVENDICATIONS1. Procédé de contrôle d'appels sortants en réponse à des appels entrants, le procédé étant mis en oeuvre dans un téléphone comprenant des moyens de mémorisation d'identifiants de dispositifs pouvant être appelés par ledit téléphone, des moyens d'obtention d'un identifiant d'un dispositif appelant ledit téléphone, des moyens d'obtention d'un identifiant d'un dispositif appelé par ledit téléphone et des moyens pour rejeter un appel sortant, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - lorsqu'un appel entrant est détecté (300), o obtention (310) d'un identifiant d'un dispositif duquel est reçu ledit appel entrant, appelé identifiant reçu o évaluation (305) d'au moins une caractéristique dudit appel entrant, ladite au moins une caractéristique étant distincte dudit identifiant reçu ; et, o si ladite au moins une caractéristique évaluée est conforme à au moins une condition prédéterminée (325, 330), sélection et 20 mémorisation (335) dudit identifiant obtenu dans une liste d'identifiants suspects ; - lorsqu'un appel sortant est détecté (215), o obtention (220) d'un identifiant d'un dispositif appelé visé par ledit appel sortant, appelé identifiant émis 25 o comparaison (225) dudit identifiant émis avec au moins un identifiant de ladite liste d'identifiants suspects pour déterminer si ledit identifiant émis est présent dans ladite liste ; et, o en réponse à la dite étape de comparaison, si ledit identifiant émis est présent dans ladite liste (230), demande de validation (235) 30 dudit appel sortant. 2. Procédé selon la revendication 1 selon lequel ladite étape d'évaluation d'au moins une caractéristique dudit appel entrant comprend une étape de lancement d'une fonction de décompte. 3. Procédé selon la revendication 2 selon lequel ledit identifiant reçu ne peut être sélectionné et mémorisé que si la valeur décomptée atteint une valeur prédéterminée. 4. Procédé selon la revendication 2 ou la revendication 3 comprenant en outre une étape d'arrêt de ladite fonction de décompte, ladite étape d'arrêt étant déclenchée lorsqu'il est mis fin audit appel entrant. 5. Procédé selon l'une quelconque des revendications 1 à 4 selon lequel ledit identifiant reçu ne peut être sélectionné et mémorisé que si ledit identifiant reçu n'appartient pas à une liste d'identifiants autorisés. 6. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape d'affichage (400, 500) d'un message de demande de validation dudit appel sortant et une étape de réception (240) d'une commande de validation, ledit appel sortant étant émis en réponse à ladite commande de validation. 7. Procédé selon l'une quelconque des revendications 1 à 5 comprenant en outre une étape d'affichage (400, 500) d'un message de demande de validation dudit appel sortant et une seconde étape de détection (510) d'un second appel sortant, ledit appel sortant étant appelé premier appel sortant, ledit second appel sortant étant émis (525) si l'identifiant d'un dispositif appelé visé par ledit second appel sortant est similaire à l'identifiant d'un dispositif appelé visé par ledit premier appel sortant (520). 8. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes lorsque ledit programme est exécuté dans un microcontrôleur ou un microprocesseur. 9. Carte de type SIM comprenant des moyens de stockage, lesdits moyens de stockage comprenant le programme d'ordinateur selon la revendication précédente et des moyens de calcul adaptés à mettre en oeuvre ledit programme d'ordinateur. 10. Carte de type SIM selon la revendication précédente selon laquelle lesdits moyens de stockage mémorisent ladite liste d'identifiants suspects.