FR3034275A1 - Procede et dispositif du nommage d'un terminal - Google Patents

Abstract

Procédé, mis en œuvre par un terminal (T2), pour informer un serveur (S) d'un nom (N) dudit terminal (T2) mémorisé dans une mémoire non volatile réinscriptible (MEM) dudit terminal (T2), ledit nom (N) étant configurable par un utilisateur, ce procédé comportant : - une étape (E10) d'obtention dudit nom (N) à partir de ladite mémoire (MEM); - une étape (E20) d'insertion dudit nom (N) dans un champ User Agent (UA) d'un message de signalisation SIP (M1) de sorte à enrichir le contenu dudit champ User Agent (UA); et - une étape (E30) d'envoi dudit message de signalisation SIP (M1) audit serveur (S);

Description

1 Arrière-plan de l'invention L'invention se rapporte au domaine général du nommage des terminaux dans un réseau de communications. Le contexte technique de l'invention est celui des réseaux de communications dans lesquels un utilisateur dispose de plusieurs terminaux (par exemple, téléphone intelligent, téléphone portable, tablette tactile, assistant numérique personnel (PDA), ordinateur personnel, etc.) qui partagent une même identité publique. Une telle identité publique est par exemple un numéro de téléphone, ou une adresse SIP (en anglais Session Initiation Protocol), ou autre. Ces terminaux peuvent émettre des messages selon le protocole SIP comportant un champ « User Agent » indiquant notamment le type du terminal et la version de la pile (« stack » en anglais) RCS (en anglais « Rich Communications Services »), la valeur du champ User Agent étant la même pour tous les terminaux embarquant la même version de pile RCS. Un terminal peut afficher sur une interface homme-machine, dans un journal d'appels la liste des appels destinés à l'identité publique partagée par ce terminal et pris par ce terminal ou par un autre terminal partageant la même identité publique. Le terminal affiche alors dans le journal d'appels en correspondance d'un appel pris un identifiant du terminal ayant pris un tel appel. Lors d'une communication en cours sur un terminal, ce terminal peut proposer, via l'interface homme-machine, de transférer la communication en cours vers un autre terminal de l'utilisateur. De la même façon, un terminal recevant une demande de communication peut proposer à l'utilisateur, via l'interface homme-machine, de prendre ladite communication entrante sur un autre terminal. Dans chacun de ces cas, les terminaux supportent l'utilisation de la « Globally Routable User Agent URI (GRUUs) » tels que définis dans la spécification 3GPP TS 24.229. dans le cas d'un terminal SIP, l'adresse GRUU du terminal est mise en oeuvre par le champ sip.instance du terminal.

Un tel champ sip.instance est construit à partir de l'IMEI (en anglais « International Mobile Equipment identity »), de l'UUID (en anglais « Universally Unique Identifier ») dérivé de l'IMEI, ou d'une valeur chronologique. Ce champ sip.instance est utilisé pour des fins de routage pour acheminer les messages SIP dans le réseau depuis et vers le terminal. Dans les exemples précités, les terminaux peuvent alors être identifiés sur l'interface homme-machine par un identifiant (par exemple, 358661053533102) spécifique unique dérivé du champ : sip.instance (par exemple, <urn :gsma :imei :358661053533102>) du terminal.

3034275 2 Malheureusement, un identifiant créé sur la base de la valeur d'un tel champ sip.instance n'est pas ergonomique, difficilement compréhensible et non pertinent d'un point de vue utilisateur. L'invention vise notamment à remédier à cet inconvénient de l'art antérieur.

5 Objet et résumé de l'invention Plus particulièrement, et d'une façon générale, l'invention vise une solution pour permettre à un premier terminal de recevoir un nom d'un deuxième terminal mémorisé dans une mémoire non volatile réinscriptible, en ajoutant ce nom dans la valeur d'un champ User Agent de 10 ce deuxième terminal. Comme la mémoire stockant le nom est non volatile réinscriptible, ce nom peut être créé et modifié par l'utilisateur, par exemple en utilisant une application de provisionning du deuxième terminal. Ainsi et selon un premier aspect, l'invention vise un procédé, mis en oeuvre par un terminal, pour informer un serveur d'un nom de ce terminal mémorisé dans une mémoire non 15 volatile réinscriptible du terminal et configurable par un utilisateur, ce procédé comportant : une étape d'obtention du nom à partir de la mémoire ; une étape d'insertion du nom dans un champ User Agent d'un message de signalisation SIP de sorte à enrichir le contenu du champ User Agent; et une étape d'envoi du message de signalisation SIP au serveur ; 20 Conformément à l'invention, le nom du terminal peut être configuré par un utilisateur ; cela signifie que le terminal présente une interface homme machine permettant à l'utilisateur d'écrire un nom de son choix dans la mémoire non volatile réinscriptible. Dans un autre mode de réalisation, l'utilisateur peut utiliser une application éventuellement extérieure au terminal pour envoyer au terminal un nom devant être mémorisé dans cette mémoire.

25 Ainsi et d'une façon générale, l'invention permet au terminal d'enrichir le contenu du champ User Agent par le nom éventuellement configuré par l'utilisateur de manière ergonomique et donc compréhensible d'un utilisateur. On notera que cet enrichissement permet aux terminaux embarquant une même version de pile RCS d'avoir différentes valeurs du champ User Agent.

30 Le contenu du champ User Agent enrichi sera gardé pour les messages suivants émis par ce terminal. Corrélativement, l'invention vise un terminal apte à informer un serveur d'un nom de ce terminal mémorisé dans une mémoire non volatile réinscriptible de ce terminal et configurable par un utilisateur, ce terminal comportant : 35 - un module d'obtention du nom à partir de la mémoire ; un module d'insertion du nom dans un champ User Agent d'un message de signalisation SIP de sorte à enrichir le contenu du champ User Agent; et un module d'envoi du message de signalisation SIP au serveur ; 3034275 3 Selon un deuxième aspect, l'invention vise aussi un procédé, mis en oeuvre par un serveur, pour informer un premier terminal ayant souscrit auprès d'un serveur afin de recevoir des notifications relatives à au moins un état d'un deuxième terminal ayant la même identité publique que le premier terminal, d'un nom du deuxième terminal, ce procédé comportant : 5 une étape de réception d'un message de signalisation SIP du deuxième terminal ; ce procédé comporte en outre : une étape d'obtention du contenu d'un champ User Agent à partir du message de signalisation SIP, ce contenu étant enrichi par le nom; et une étape d'envoi, au premier terminal, d'un message de notification comportant au 10 moins le nom. On notera que le serveur mettant en oeuvre ce procédé conforme au deuxième aspect de l'invention n'est pas nécessairement le serveur auprès duquel le premier terminal a souscrit. Dans ce document, le mot « état » doit être compris au sens large. Il vise notamment l'enregistrement du deuxième terminal auprès du réseau, la mise à jour du nom du deuxième 15 terminal, etc. Ainsi et d'une façon générale, l'invention permet au premier terminal de recevoir le nom du deuxième terminal, intelligible car configuré par un utilisateur. Corrélativement, l'invention vise aussi un serveur apte à informer un premier terminal ayant souscrit auprès d'un serveur afin de recevoir des notifications relatives à au moins un état d'un deuxième terminal ayant la même identité publique que le premier terminal, d'un nom du 20 deuxième terminal, ce serveur comportant : un module de réception d'un message de signalisation SIP du deuxième terminal ; ce serveur comportant en outre : un module d'obtention du contenu d'un champ User Agent du message de signalisation SIP, le contenu étant enrichi par le nom; et 25 - un module d'envoi, au premier terminal, d'un message de notification comportant le nom. Dans un mode particulier de réalisation de l'invention, ledit message de signalisation SIP est un message SIP REGISTER, ou un message SIP OPTIONS ou un message SIP INVITE. Dans le cas d'un message SIP REGISTER, l'invention permet au terminal d'envoyer le 30 nom au serveur aussitôt que possible, à savoir dès l'enregistrement du terminal auprès du réseau de communications. Dans ce cas, le serveur peut informer le premier terminal, qui a souscrit auprès du serveur à des notifications relatives à l'enregistrement du deuxième terminal, du nom du deuxième terminal chaque fois le deuxième terminal s'enregistre du réseau, sans tenir compte de la mise à 35 jour du nom du deuxième terminal. Dans le cas d'un message SIP OPTIONS ou INVITE, l'invention permet d'informer le serveur du nom dès que nécessaire, y compris après l'enregistrement du terminal. Par exemple, dans le cas où le nom du deuxième terminal est créé ou modifié après son enregistrement, il peut 3034275 4 être encore transmis au serveur lors de l'interrogation des capacités du serveur (i.e. en utilisant un message SIP OPTIONS) ou lors d'une demande d'établissement d'une session (i.e. en utilisant un message SIP INVITE). Dans ce cas, le serveur informe le premier terminal, qui a souscrit auprès du serveur à 5 des notifications relatives à la mise à jour du nom du deuxième terminal, du nom mis à jour du deuxième terminal. Par exemple, le serveur détectant la mise à jour du nom envoie au deuxième terminal d'un message pour que ce deuxième terminal réémette au serveur un message SIP REGISTER avec le nom mis à jour. La détection du serveur de la mise à jour du nom peut être effectuée par tout moyen de l'art antérieur, par exemple en comparant le nom reçu par rapport à 10 un nom mémorisé dans une mémoire du serveur pour le deuxième terminal. Le serveur mémorise ainsi le nom mis à jour à la place de l'ancien nom du deuxième terminal. Dans un mode particulier de réalisation de l'invention, le message de notification est un message SIP NOTIFY. L'invention permet ainsi au serveur d'envoyer le nom au premier terminal dès qu'il reçoit ce nom, en utilisant le mécanisme SUBSCRIBE/NOTIFY.

15 Selon un troisième aspect, l'invention vise aussi un procédé, mis en oeuvre par un premier terminal ayant souscrit auprès d'un serveur afin de recevoir des notifications relatives à au moins un état d'un deuxième terminal ayant la même identité publique que le premier terminal, pour recevoir un nom du deuxième terminal, ce procédé comportant : une étape de réception, en provenance du serveur, d'un message de notification ; 20 ce procédé comportant en outre : une étape d'obtention du nom à partir du contenu d'un champ User Agent du message de notification ; et une étape de mémorisation de ce nom en association avec un identifiant du deuxième terminal de sorte que, suite à la réception d'un message relatif à une communication concernant 25 au moins le deuxième terminal, le premier terminal présente le nom, via une interface homme- machine du premier terminal, avec une information relative à la communication concernant le deuxième terminal. La présentation du nom et de la communication peut par exemple consister à afficher ces informations sur un écran du premier terminal ou à les restituer de manière sonore.

30 Ainsi et d'une façon générale, l'invention permet au premier terminal de présenter à l'utilisateur le nom du deuxième terminal pour une communication concernant ce deuxième terminal. En réalité, si le premier terminal dispose lui-même de la pile RCS, il est apte à extraire le nom pour le présenter à l'utilisateur. Sinon, le premier terminal ne peut pas effectuer l'extraction et il présente donc le contenu du champ User Agent complet comprenant le nom.

35 A noter que si le premier terminal ne reçoit aucun nom du deuxième terminal, il est néanmoins apte à afficher, comme dans l'art antérieur, l'identifiant créé à partir de la valeur du champ sip.instance du deuxième terminal.

3034275 5 Ainsi, selon l'invention, un utilisateur du premier terminal peut facilement identifier le deuxième terminal lorsqu'une liste de terminaux ou une information relative au deuxième terminal lui est affichée. En effet, lorsque l'utilisateur dispose de plusieurs terminaux partageant une même identité publique, il est plus facile pour l'utilisateur d'identifier les terminaux à partir de noms 5 ergonomiques qu'il a choisis plutôt qu'à partir d'identifiants de routage difficiles à mémoriser pour un utilisateur. Corrélativement, l'invention vise aussi un terminal, ayant souscrit auprès d'un serveur afin de recevoir des notifications relatives à au moins un état d'un deuxième terminal ayant la même identité publique que le premier terminal, pour recevoir un nom du deuxième terminal, ce 10 premier terminal comportant : un module de réception, en provenance du serveur, d'un message de notification ; ce terminal comportant en outre : un module d'obtention du nom à partir du contenu d'un champ User Agent du message de notification; 15 - un module de mémorisation du nom en association avec un identifiant du deuxième terminal ; et une interface homme-machine pour, suite à la réception d'un message relatif à une communication concernant au moins le deuxième terminal, présenter ce nom avec une information relative à au moins une communication concernant le deuxième terminal.

20 Dans ce document, le mot « communication » doit être compris au sens large. Il vise notamment un appel, une transmission de textes, d'images, de vidéo, etc. Dans un mode particulier de réalisation de l'invention, la communication est choisie parmi : une communication entrante, une communication à transférer, une communication prise et une communication manquée.

25 L'invention permet ainsi au premier terminal d'identifier le deuxième terminal dans plusieurs scénarios, notamment: le scénario dans lequel le premier terminal reçoit une communication entrante depuis un autre terminal, une telle communication entrante pouvant être transférée au deuxième terminal, le premier terminal affiche alors à l'utilisateur un message relatif à cette communication 30 entrante pour demander si l'utilisateur veut transférer la communication entrante vers le deuxième terminal ; le scénario dans lequel le deuxième terminal reçoit une communication entrante depuis un autre terminal et pouvant être aussi prise sur le premier terminal, le premier terminal affichant à l'utilisateur un message relatif à cette communication entrante pour indiquer qu'elle est reçue sur 35 le deuxième terminal ; le scénario dans lequel une communication est dirigée vers les deux terminaux et prise sur le deuxième terminal, le premier terminal affichant alors à l'utilisateur une information relative à cette communication pour indiquer qu'elle est prise sur le deuxième terminal. Par exemple, 3034275 6 lorsqu'un appel est forké sur deux terminaux et qu'il est pris sur le deuxième terminal, le premier terminal reçoit un message SIP CANCEL qui indique la raison de l'arrêt de la sonnerie dans un champ « reason ». Ce champ peut contenir la valeur du champ User Agent enrichi ou directement le nom du deuxième terminal qui a pris l'appel ; 5 le scénario dans lequel le premier terminal est rallumé et affiche à l'utilisateur une communication manquée qui a été prise sur le deuxième terminal. Par exemple, si le premier terminal a été éteint, il peut récupérer, lors de son redémarrage, une information d'un appel manqué qui a été pris sur le deuxième terminal. Une telle information de synchronisation est obtenue par le premier terminal via un message de synchronisation envoyé vers un serveur du 10 réseau de communication stockant l'historique des messages (un tel serveur est communément nommé « Common Message Store » en anglais). Cette information de synchronisation est obtenue via le mécanisme d'IMAP (en anglais « Internet Message Access Protocol »), le contenu de cette information étant paramétrable pour y insérer soit le contenu User Agent enrichi, soit le nom du deuxième terminal.

15 Dans un mode particulier de réalisation de l'invention, le premier terminal et/ou le deuxième terminal sont des terminaux RCS. Les avantages et caractéristiques particuliers du premier terminal, du serveur et du deuxième terminal selon l'invention sont identiques à celui du procédé décrit ci-dessus et ne seront pas rappelés ici.

20 Dans un mode particulier de réalisation, les différentes étapes des procédés sont déterminées par des instructions de programmes d'ordinateur. En conséquence, l'invention vise aussi des programmes d'ordinateur sur des supports d'informations, ces programmes étant susceptibles d'être mis en oeuvre dans un ordinateur, pour la mise en oeuvre des étapes des procédés selon l'invention, tels que brièvement décrits ci-dessus.

25 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 des supports d'informations lisibles par un ordinateur, et 30 comportant des instructions des programmes d'ordinateur tels que mentionnés ci-dessus. Le support d'information peut être n'importe quel 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 une disquette (« floppy disc » en anglais), un disque 35 dur, ou une clé USB. D'autre part, le support d'information 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 3034275 7 ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet. Alternativement, le support d'information peut être constitué de circuits intégrés dans lesquels le programme est incorporé, les circuits étant adaptés pour exécuter ou pour être utilisés 5 dans l'exécution du procédé en question. Brève description des dessins 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 10 réalisation dépourvu de tout caractère limitatif. Sur les figures : - la figure 1 représente un serveur, un premier terminal et un deuxième terminal conformes à un mode particulier de réalisation de l'invention; et - la figure 2 représente, sous forme d'organigramme, les principales étapes des procédés mis en oeuvre par le serveur, le premier terminal et le deuxième terminal de la figure 1 15 dans un mode particulier de réalisation de l'invention. Description détaillée d'un mode de réalisation La figure 1 représente, dans un mode particulier de réalisation de l'invention, un serveur S, un premier terminal T1 et un deuxième terminal T2 selon l'invention.

20 Dans le mode de réalisation décrit ici, le deuxième terminal T2 comporte un processeur 20, une mémoire morte de type ROM 22 comportant un programme d'ordinateur PG2, et une mémoire non volatile réinscriptible MEM de type RAM dans laquelle est mémorisé un nom N du deuxième terminal configurable par un utilisateur. Ce nom N (ex. « mon iphone ») est par exemple saisi par un utilisateur sur une 25 interface homme-machine du terminal T2 au moment de la première utilisation du terminal T2, en utilisant une application de provisionning installée dans le terminal T2. Ce nom N peut être modifié après son enregistrement. Le programme d'ordinateur PG2 sera décrit ultérieurement en référence à la figure 2 dans un mode particulier de réalisation de l'invention. Ce programme PG2 permet notamment de 30 mettre en oeuvre les instructions correspondant aux étapes E10 à E30. Le deuxième terminal T2 comporte également un module MON pour obtenir le nom N à partir de la mémoire MEM, et un module MIN pour insérer ce nom N dans un champ User Agent UA d'un message de signalisation SIP M1 (par exemple, message SIP REGISTER, OPTIONS, INVITE) : on parle alors d'enrichissement du champ User Agent UA.

35 Le deuxième terminal T2 comporte en outre un module de communication COM adapté à communiquer avec le module COM du serveur S, et notamment à envoyer le message de signalisation SIP M1 à destination du serveur S.

3034275 8 Dans ce mode de réalisation décrit ici, le serveur S comporte un processeur 30, une mémoire morte de type ROM 32 comportant un programme d'ordinateur PG3 et une mémoire vive MEM de type RAM stockant le nom N du terminal T2. Le programme d'ordinateur PG3 sera décrit ultérieurement en référence à la figure 2 5 dans un mode particulier de réalisation de l'invention. Ce programme PG3 permet notamment de mettre en oeuvre les instructions correspondant aux étapes F10 à F30. Le serveur S comporte également un module de communication COM adapté à communiquer avec les modules COM du deuxième terminal T2 et du premier terminal T1. Le serveur S comporte aussi un module MOU pour obtenir le contenu du champ User 10 Agent UA du message de signalisation SIP Ml, ce contenu étant enrichi par le nom N du terminal T2. Conformément à l'invention, le serveur S est apte à recevoir par son module de communication COM le message de signalisation SIP M1 en provenance du deuxième terminal T2, et à envoyer en conséquence un message de notification M2, par exemple un message SIP 15 NOTIFY, comprenant le nom N à tous les terminaux, notamment le premier terminal T1, qui ont souscrit auprès du serveur S pour recevoir des notifications relatives à au moins un état du deuxième terminal T2. Dans ce mode de réalisation décrit ici, le premier terminal T1 comporte un processeur 10, une mémoire morte de type ROM 12 comportant un programme d'ordinateur PG1, et un 20 module MEM pour mémoriser le nom N en association avec un identifiant du deuxième terminal T2. Le programme d'ordinateur PG1 sera décrit ultérieurement en référence à la figure 2 dans un mode particulier de réalisation de l'invention. Ce programme PG1 permet notamment de mettre en oeuvre les instructions correspondant aux étapes G10 à G30. Le premier terminal T1 comporte également un module de communication COM 25 adapté à communiquer avec le module COM du serveur S. Conformément à l'invention, le premier terminal T1 est apte à recevoir par son module de communication COM le message de notification M2 émis par le serveur S. Le premier terminal T1 comporte en outre un module MOU pour obtenir le nom N à partir du contenu du champ User Agent UA du message de notification M2.

30 Dans le mode de réalisation décrit ici, le premier terminal T1 comporte une interface homme-machine (par exemple, un écran) adaptée pour, suite à la réception d'un message relatif à au moins une communication (par exemple, appel, texte, image, vidéo...) concernant au moins le deuxième terminal T2, afficher une information relative à cette communication concernant le deuxième terminal T2 avec le nom N.

35 Dans ce mode de réalisation, les premier et deuxième terminaux T1 et T2 sont du type RCS, et le serveur est un serveur du réseau IMS.

3034275 9 En référence à la figure 2, nous allons maintenant décrire les principales étapes des procédés mis en oeuvre par le serveur S, le premier terminal T1 et le deuxième terminal T2 illustrés à la figure 1, selon un mode particulier de réalisation de l'invention. Dans le mode de réalisation décrit ici, le premier terminal T1 a souscrit, auprès du 5 serveur S, pour recevoir des notifications relatives à au moins un état du deuxième terminal T2, ces deux terminaux partageant une même identité publique (par exemple, un même numéro de téléphone) dans le réseau. On suppose que dans l'exemple de la figure 2, lorsque le premier terminal T1 (par ex. un téléphone compatible avec la norme RCS/VoLTE) s'enregistre sur le réseau, il effectue une 10 souscription (SUBSCRIBE/NOTIFY) à un package REG du serveur S pour être informé des enregistrements de terminaux tiers. Ainsi lorsque le deuxième terminal T2 s'enregistre, le premier terminal T1 est informé par un message NOTIFY envoyé par le serveur S du réseau. Dans cet exemple, lors de son enregistrement, le deuxième terminal T2 obtient (E10) 15 le nom N à partir de sa mémoire MEM, ce nom N configurable étant par exemple « mon iphone » saisi par un utilisateur lors de la première utilisation du terminal T2 et stocké dans la mémoire MEM. Le deuxième terminal T2 insère (E20) ce nom N dans un champ User Agent UA « IM- client/OMA1.0 ABCDEFGH-RCS-client/2.5.11 » d'un message de signalisation M1 qui est, dans cet 20 exemple, un message SIP REGISTER. En conséquence, le contenu du champ UA est enrichi .par le nom « mon iphone » : IM-client/OMA1.0 ABCDEFGH-RCS-client/2.5.11 /mon iphone. Le deuxième terminal T2 envoie (E30) le message SIP REGISTER M1 comportant le champ UA enrichi par le nom N au serveur S. Ainsi, le serveur S reçoit (F10) ce message SIP REGISTER M1 en provenance du deuxième terminal T2.

25 Ce serveur S obtient (F20) alors le contenu du champ UA enrichi de ce message M1 et envoie (F30) un message de notification M2, par exemple un message SIP NOTIFY, comprenant le nom N à destination du premier terminal T1. Dans cet exemple, dans la structure XML du message M2, le serveur ajoute un entête, i.e. un paramètre du type « unknown-param » dont le contenu est identique à celui du champ User 30 Agent UA enrichi et obtenu du message Ml. Le message M2 comporte ainsi le nom N. Dans un autre mode particulier de réalisation de l'invention, le nom N du terminal T2 est mis à jour par l'utilisateur après l'enregistrement de ce terminal T2 auprès du réseau, le champ User Agent UA des messages de signalisation SIP émis par ce terminal T2 comportant ainsi ce nom mis à jour.

35 Lorsque le serveur S reçoit un message M1 du type SIP OPTIONS ou INVITE en provenance du terminal T2 et obtient le contenu du champ User Agent UA de ce message Ml, le serveur S détecte une mise à jour du nom N compris dans ce contenu par rapport à un nom du terminal T2 mémorisé dans la mémoire MEM du serveur S.

3034275 10 Le serveur S envoie alors un message au terminal T2 pour que ce terminal T2 réémette au serveur S un message SIP REGISTER avec le nom N mis à jour, afin d'utiliser le mécanisme SUBSCRIBE/NOTIFY pour informer le terminal T1 du nom N mis à jour. Dans le mode de réalisation décrit ici, le premier terminal Tl reçoit (G10) le message 5 SIP NOTIFY M2 en provenance du serveur S. Dans cet exemple, ce message M2 comporte aussi une entête SIP Instance (dont le contenu est par exemple <urn :gsma :imei :358661053533102>) du deuxième terminal pour des fins de routage. On suppose qu'une pile RCS est installée dans le premier terminal T1, permettant au 10 terminal T1 d'extraire le nom N « mon iphone » du champ UA enrichi. Le terminal T1 obtient (G20) le nom N à partir du contenu du champ User Agent UA de ce message M2, T1 étant donc apte à associer le nom N avec le contenu du champ SIP Instance. Le terminal Ti mémorise (G30) dans son module de mémorisation MEM ainsi le nom N en association avec le contenu du champ SIP Instance relatif au terminal T2. Lors de la réception 15 d'un message relatif à une communication concernant au moins le deuxième terminal T2, le premier terminal T1 peut ainsi, à partir du message reçu, extraire un identifiant du terminal T2, par exemple le champ SIP Instance et retrouver le nom N mémorisé associé à un tel identifiant. Le terminal T1 peut alors présenter le nom N du terminal T2 avec une information relative à la communication concernant le deuxième terminal T2.

20 Par exemple, une communication concernant au moins le deuxième terminal T2 est: - une communication entrante reçue par le terminal T2 et pouvant être prise par le terminal T2, ou - une communication reçue par le terminal T1 et prise par le terminal T2, ou - une communication manquée par le terminal T1 et prise par le terminal T2, ou 25 - une communication en cours sur le terminal T1 et pouvant être transférée sur le terminal T2. Par exemple, lorsque le terminal T1 reçoit un appel entrant qui peut également être pris par le terminal T2 selon l'invention et par d'autres terminaux RCS ne mettant pas oeuvre l'invention, le premier terminal T1 extrait du message de signalisation de l'appel entrant reçu une 30 liste des terminaux susceptibles de prendre l'appel reçu. Une telle liste comprenant notamment un identifiant du deuxième terminal T2, tel que le SIP Instance du deuxième terminal T2. Le terminal T1 affiche alors, sur son écran IHM, la liste des terminaux susceptibles de prendre l'appel en association avec une information indiquant que l'appel peut être pris par lesdits terminaux. Le terminal T1 affiche ainsi le nom N « mon iphone » du deuxième terminal mémorisé 35 précédemment et les identifiants (par exemple, 35866105353xxxx, etc.) non ergonomiques générés à partir des SIP Instances des autres terminaux. L'utilisateur dispose ainsi d'une information pertinente et ergonomique concernant le terminal T2 pouvant prendre l'appel.

3034275 11 Selon un autre exemple, lorsque le terminal T1 est en cours de communication et qu'il souhaite transférer la communication vers un autre terminal. Le terminal T1 reçoit un message de signalisation indiquant les terminaux vers lesquels la communication peut être transférée. Le premier terminal T1 extrait du message de signalisation reçu une liste de ces 5 terminaux. Une telle liste comprenant notamment un identifiant du deuxième terminal T2, tel que le SIP Instance du deuxième terminal T2. Le terminal T1 affiche alors, sur son écran IHM, la liste des terminaux vers lesquels la communication peut être transférée en association avec une information indiquant que la communication peut être transférée vers lesdits terminaux. Le terminal T1 affiche ainsi le nom N 10 « mon iphone » du deuxième terminal mémorisé précédemment et les identifiants (par exemple, 35866105353xxxx, etc.) non ergonomiques générés à partir des SIP Instances des autres terminaux si les autres terminaux ne mettent pas en oeuvre l'invention. Grâce au nom N, l'utilisateur identifie facilement le deuxième terminal parmi la liste des terminaux et peut transférer la communication vers le deuxième terminal sans risquer de se 15 tromper de terminal.

Claims (14)

1. REVENDICATIONS1. Procédé, mis en oeuvre par un terminal (T2), pour informer un serveur (S) d'un nom (N) dudit terminal (T2) mémorisé dans une mémoire non volatile réinscriptible (MEM) dudit terminal (T2), ledit nom (N) étant configurable par un utilisateur, ce procédé comportant : une étape (E10) d'obtention dudit nom (N) à partir de ladite mémoire (MEM); une étape (E20) d'insertion dudit nom (N) dans un champ User Agent (UA) d'un message de signalisation SIP (M1) de sorte à enrichir le contenu dudit champ User Agent (UA); et une étape (E30) d'envoi dudit message de signalisation SIP (M1) audit serveur (S).
2. 2. Procédé, mis en oeuvre par un serveur (S), pour informer un premier terminal (T1) ayant souscrit auprès d'un serveur (S) afin de recevoir des notifications relatives à au moins un état d'un deuxième terminal (T2) ayant la même identité publique que ledit premier terminal (T1), d'un nom (N) dudit deuxième terminal (T2), ce procédé comportant : - une étape (F10) de réception d'un message de signalisation SIP (M1) dudit deuxième terminal (T2); ledit procédé étant caractérisé en ce que, il comporte : une étape (F20) d'obtention du contenu d'un champ User Agent (UA) dudit message de signalisation SIP (M1), ledit contenu étant enrichi par ledit nom (N); et - une étape (F30) d'envoi, audit premier terminal (T1), d'un message de notification (M2) comportant au moins ledit nom (N).
3. 3. Procédé selon la revendication 1 ou 2, dans lequel ledit message de signalisation SIP (M1) est un message SIP REGISTER, ou un message SIP OPTIONS ou un message SIP 25 INVITE.
4. 4. Procédé selon la revendication 2 ou 3, dans lequel ledit message de notification (M2) est un message SIP NOTIFY. 30
5. 5. Procédé selon l'une quelconque des revendications 2 à 4, dans lequel ledit nom (N) est inclus dans une structure XML dudit message de notification (M2).
6. 6. Procédé, mis en oeuvre par un premier terminal (T1) ayant souscrit auprès d'un serveur (S) afin de recevoir des notifications relatives à au moins un état d'un deuxième terminal 35 (T2) ayant la même identité publique que ledit premier terminal (T1), pour recevoir un nom (N) dudit deuxième terminal (T2), ce procédé comportant : une étape (G10) de réception, en provenance dudit serveur (S), d'un message de notification (M2) ; 3034275 13 ledit procédé étant caractérisé en ce que, il comporte : une étape (G20) d'obtention dudit nom (N) à partir du contenu d'un champ User Agent (UA) dudit message de notification (M2); une étape (G30) de mémorisation dudit nom (N) en association avec un identifiant du 5 deuxième terminal de sorte que, suite à la réception d'un message relatif à une communication concernant au moins ledit deuxième terminal (T2), le premier terminal (T1) présente ledit nom (N), via une interface homme-machine (IHM) dudit premier terminal (T1), avec une information relative à ladite communication. 10
7. 7. Procédé selon la revendication 6, dans lequel ladite au moins une communication est choisie parmi : une communication entrante, une communication à transférer, une communication prise et une communication manquée.
8. 8. Terminal (1-2) apte à informer un serveur (S) d'un nom (N) dudit terminal (T2) 15 mémorisé dans une mémoire non volatile réinscriptible (MEM) dudit terminal (T2), ledit nom (N) étant configurable par à un utilisateur, ce terminal (T2) comportant : un module (MON) d'obtention dudit nom (N) à partir de ladite mémoire (MEM); un module (MIN) d'insertion dudit nom (N) dans un champ User Agent (UA) d'un message de signalisation SIP (M1) de sorte à enrichir le contenu dudit champ User Agent (UA); et 20 - un module (COM) d'envoi dudit message de signalisation SIP (M1) audit serveur (S).
9. 9. Serveur (S) apte à informer un premier terminal (T1) ayant souscrit auprès d'un serveur (S) afin de recevoir des notifications relatives à au moins un état d'un deuxième terminal (T2) ayant la même identité publique que ledit premier terminal (T1), d'un nom (N) dudit deuxième terminal (T2), ce serveur (S) comportant : un module (COM) de réception d'un message de signalisation SIP (M1) dudit deuxième terminal (T2); ledit serveur étant caractérisé en ce que, il comporte : un module (MOU) d'obtention du contenu d'un champ User Agent (UA) dudit message de signalisation SIP (M1), ledit contenu étant enrichi par ledit nom (N); et un module (COM) d'envoi, audit premier terminal (T1), d'un message de notification (M2) comportant ledit nom (N).
10. 10. Serveur selon la revendication 9, dans lequel ledit serveur (S) est un serveur du réseau IMS (IP Multimedia Subsystem).
11. 11. Terminal (T1), ayant souscrit auprès d'un serveur (S) afin de recevoir des notifications relatives à au moins un état d'un deuxième terminal (T2) ayant la même identité 3034275 14 publique que ledit terminal (T1), apte à recevoir un nom (N) dudit deuxième terminal (T2), ce terminal (Ti) comportant : un module (COM) de réception, en provenance dudit serveur (S), d'un message de notification (M2); 5 ledit terminal étant caractérisé en ce que, il comporte : - un module (MOU) d'obtention dudit nom (N) à partir du contenu d'un champ User Agent (UA) dudit message de notification (M2) un module (MEM) de mémorisation dudit nom (N) en association avec un identifiant du deuxième terminal; et 10 - une interface homme-machine (IHM) pour, suite à la réception d'un message relatif à une communication concernant au moins ledit deuxième terminal (T2), présenter ledit nom (N) avec une information relative à ladite communication.
12. 12. Terminal selon la revendication 8 ou 11, dans lequel ledit terminal (T1, T2) est 15 un terminal RCS.
13. 13. Programme d'ordinateur (PG2) comportant des instructions pour l'exécution des étapes d'un procédé selon l'une quelconque des revendications 1 ou 3, ou d'un procédé selon l'une quelconque des revendications 2 à 5 ou d'un procédé selon l'une quelconque des revendications 6 20 à 7, lorsque ledit programme est exécuté par un processeur.
14. 14. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (PG1) selon la revendication 13.