PAR UN UTILISATEUR D'UN RESEAU IMS

La présente invention concerne les réseaux de type IP (« Internet Protocol ») qui sont aptes à mettre en œuvre des protocoles de contrôle de session évolués.

On rappelle que les réseaux IP permettent la diffusion de données conversationnelles, tels que « Voix sur IP », « Partage de Contenu », « Présence », ou « Messagerie Instantanée ». Dans ces réseaux, les services de communication peuvent identifier des ressources physiques ou virtuelles au moyen de chaînes de caractères, par exemple des « URI » (initiales des mots anglais « Uniform Resource Identifier » signifiant « Identifiant Uniforme de Ressource »). La syntaxe des URI est définie dans le document RFC 3986 de l'IETF (Internet Engineering Task Force) ; la connaissance de l'URI d'une ressource permet d'obtenir l'adresse IP d'un équipement du réseau de l'opérateur gérant cette ressource.

Ces équipements peuvent par exemple être un terminal fixe ou mobile, ou une passerelle domestique ou située dans une entreprise (« Residential Gateway » en anglais), ou encore une passerelle d'opérateur réseau (« Voice Gateway » en anglais), qui raccorde généralement un grand nombre de lignes analogiques ou RNIS, telle qu'un DSLAM-SIP (DSLAM sont les initiales des mots anglais « Digital Subscriber Line Access Multiplexer » signifiant « multiplexeur d'accès de lignes d'abonnés numériques » ; il s'agit d'un dispositif collectant le trafic de données DSL qui transite sur un certain nombre de lignes téléphoniques). Par souci de brièveté, on utilisera fréquemment ci- dessous le terme générique de « terminal d'utilisateur », ou de « terminal » tout court, pour désigner ces divers équipements. On rappelle également que les protocoles de contrôle de session évolués classiques, tels que les protocoles H.323 et SIP, utilisent des messages dits « de signalisation », qui sont des messages permettant à un terminal de demander une connexion avec un autre terminal, ou également des messages signalant qu'une ligne téléphonique est occupée, ou signalant que le téléphone appelé sonne, ou encore signalant que tel téléphone est connecté au réseau et peut être joint de telle ou telle manière. Lorsqu'un client enregistré sur un réseau utilisant un protocole de contrôle de session évolué souhaite bénéficier d'un service multimédia offert par le réseau, il émet vers le réseau un message de signalisation précisant sa requête.

Le protocole SIP (initiales des mots anglais « Session Initiation Protocol » signifiant « Protocole d'Initialisation de Session ») a été défini par l'IETF dans le document RFC 3261 . Ce protocole permet l'établissement, la modification et la terminaison de sessions multimédia dans un réseau utilisant le protocole IP. Les ressources de communication y sont identifiées par des « SIP-URI », telles que définies dans la RFC 3261 , ou par des « tel-URI », telles que définies dans la RFC 3966 ; une SIP-URI est de la forme « user@host » (par exemple, alice@domaine1 ), où la partie « host » identifie le réseau sur lequel la ressource (par exemple, l'utilisateur d'un service offert par le réseau) représentée par la partie « user » possède un compte ; une tel-URI est de la forme « tel:numéro_de_téléphone » (par exemple, tel :+336123456789).

Ce protocole SIP est utilisé notamment dans les infrastructures de type IMS (initiales des mots anglais « IP Multimedia Subsystem » signifiant « Sous-système Multimédia sur IP »). L'IMS a été défini par l'organisme de normalisation 3GPP (« 3rd Génération Partnership Project »). C'est une architecture de réseau introduite initialement pour les réseaux mobiles, puis étendue à d'autres accès, dont les accès fixes à technologie xDSL. Cette architecture permet l'établissement dynamique et le contrôle de sessions multimédia entre deux clients, ainsi que la réservation de ressources au niveau du réseau de transport des flux multimédias. Grâce à cette architecture, les opérateurs réseau peuvent commodément mettre en œuvre une politique de gestion, fournir une Qualité de Service prédéterminée, et calculer les montants à facturer aux clients. L'IMS permet actuellement d'accéder à des services de type téléphonie, visiophonie, Présence et Messagerie Instantanée, dont elle gère aussi l'interaction.

Chaque utilisateur d'un réseau IMS peut y être identifié au moyen de diverses identités, dont ΠΜΡΙ (initiales des mots anglais « IP Multimedia Private Identity » signifiant « Identité Privée pour I P Multimédia ») et l'IMPU (initiales des mots anglais « IP Multimedia PUblic identity » signifiant « Identité Publique pour I P Multimédia »).

L'IMPI est défini dans la spécification TS 23.228 du 3GPP. L'IMPI est une identité affectée de manière permanente par l'opérateur d'un réseau à une souscription auprès de cet opérateur, et est utilisé, par exemple, pour l'enregistrement, l'autorisation d'accès, l'administration des services offerts à l'utilisateur, et la facturation (on notera qu'un utilisateur peut avoir plusieurs IMPI au sein de la même souscription ; on peut ainsi associer chaque IMPI à un terminal différent). L'IMPI a la forme d'un NAI (initiales des mots anglais « Network Access Identifier » signifiant « Identifiant d'Accès Réseau »), tel que défini dans le document RFC 4282 de l'I ETF.

Un utilisateur se sert de son IMPU pour communiquer avec d'autres utilisateurs. L'IMPU se présente sous la forme d'une URI ou d'un numéro court, ou encore d'un alias quelconque. Pour un IMPI donné, il peut y avoir plusieurs IMPU (souvent, une tel-URI et une SI P-URI). Un IMPU peut être partagé avec un autre téléphone, de manière à ce que ces téléphones puissent être tous les deux joints avec la même identité (par exemple, un numéro de téléphone unique pour toute une famille d'utilisateurs). Ces identités sont configurées par l'opérateur lors de la création par un utilisateur d'un compte auprès de cet opérateur, et exploitées lors de l'enregistrement du terminal de l'utilisateur sur le réseau.

Lorsque donc un utilisateur souhaite bénéficier des services offerts par un réseau IMS, son terminal doit, sauf exceptions (cas de certains appels d'urgence), s'enregistrer sur le réseau. Pour pouvoir enregistrer les utilisateurs, les réseaux IMS comprennent un ou plusieurs serveurs, généralement appelés « S-CSCF » (initiales des mots anglais « Serving - Call Session Control Function » signifiant « Fonction de Commande de Session d'Appel Serveuse »), aptes (entre autres fonctions) à gérer la procédure d'enregistrement des dispositifs connectés au réseau.

En outre, ces réseaux comprennent un ou plusieurs serveurs, généralement appelés « l-CSCF » (initiales des mots anglais « Interrogating - Call Session Control Function » signifiant « Fonction de Commande de Session d'Appel Interrogatrice ») qui, au moment de l'enregistrement d'un terminal d'utilisateur, interrogent un serveur appelé « HSS » (initiales des mots anglais « Home Subscriber Service » signifiant « Service d'Abonné de Rattachement ») pour pouvoir sélectionner un serveur S-CSCF possédant les caractéristiques requises pour atteindre le niveau de service souscrit par cet utilisateur.

Les serveurs S-CSCF, mentionnés ci-dessus, contribuent à la mise en œuvre de ces divers services en gérant le routage de la signalisation, d'une part, entre chaque terminal d'utilisateur et les serveurs du réseau spécialisés dans la mise en œuvre de tel ou tel service souscrit par l'utilisateur, et d'autre part en direction d'autres utilisateurs gérés par le même réseau ou par un réseau qui lui est relié.

Pour pouvoir acheminer ces diverses requêtes au sein du réseau, les serveurs de type l-CSCF ou de type S-CSCF (d'ailleurs souvent combinés en un même serveur, dénoté l/S-CSCF) échangent des informations avec un ou plusieurs serveur(s) de type HSS mentionné ci- dessus. Les serveurs HSS contiennent chacun une base de données- clients, et sont donc l'équivalent dans les réseaux IP des serveurs « HLR » (initiales des mots anglais « Home Location Register » signifiant « Registre de Localisation Nominal ») utilisés dans les réseaux GSM. Chaque serveur HSS contient le profil d'un certain nombre d'utilisateurs du réseau, ce profil comprenant leur état d'enregistrement, des données d'authentification et de localisation, et les services souscrits.

Dans le processus de création d'un compte d'utilisateurs sur un réseau IMS, l'opérateur du réseau crée d'abord dans le HSS une souscription IMS (notée « IMS Subscription » dans les figures annexées), qui servira de fondement à la facturation. L'opérateur note ensuite, en référence à cette souscription, les identités privées IMPI et publiques IMPU des utilisateurs partageant cette souscription, déclare leurs profils de services et les IFC (initiales des mots anglais « initial Fiiter Criteria » signifiant Critères de Filtrage Initiaux) associés, ainsi que de nombreuses autres informations relatives aux utilisateurs.

Les figures 1 et 2, tirées de la spécification 3GPP TS 23.228, illustrent, à titre d'exemples, des données liées à des souscriptions IMS.

La figure 1 illustre les données liées à la souscription IMS d'un utilisateur ayant une unique identité privée IMPI (notée « Private User Identity ») et trois identités publiques IMPU (notées « Public User Identity 1 », « Public User Identity 2 » et « Public User Identity 3 »). Deux de ces identités publiques sont regroupées dans un 1RS (initiales des mots anglais « Implicit Registration ID Set » signifiant « Ensemble Implicite d'Enregistrement d'Identités »), qui est représenté sur la figure 1 par un rectangle en pointillé. Cette notion d'IRS permet d'utiliser une identité publique pour en enregistrer aussi implicitement une autre. Par exemple, supposons que « l'utilisateur » à enregistrer soit une IPBX, à savoir un PABX (initiales des mots anglais « Private Automatic Branch eXchange » signifiant « Autocommutateur Téléphonique Privé », qui sert principalement à relier les postes téléphoniques d'un établissement avec le réseau téléphonique public) exécutant un logiciel, au lieu d'un équipement électronique indépendant et dédié ; dans ce cas, il est commode de n'avoir à enregistrer que l'une des multiples identités publiques attachées à ΙΊΡΒΧ pour déclarer la présence sur le réseau de l'ensemble des identités : l'IRS contient l'ensemble des identités de ΙΊΡΒΧ. Il en serait de même pour l'enregistrement d'une passerelle offrant plusieurs accès.

On utilise parfois une identité publique spécifique lors de l'enregistrement d'un 1RS. Cette identité représente généralement un utilisateur tel qu'un IPBX ou une passerelle dans son ensemble, et ne peut pas être utilisée en tant que telle à des fins de routage. On parle alors de « barred identity » (mots anglais signifiant « identité non utilisable »).

La figure 2 illustre, avec les mêmes conventions que la figure 1 , les données liées à la souscription IMS -- un peu plus complexe -- d'un utilisateur possédant deux identités privées et six identités publiques regroupées dans trois 1RS ; on notera en particulier que l'identité publique « Public User Identity 3 » est commune aux deux identités privées. La figure montre également les profils de services associés à chacune des identités publiques.

Si, par exemple, l'utilisateur enregistre un terminal configuré avec l'identité privée « Private User Identity 2 » et l'identité publique « Public User Identity 5 », alors l'identité publique « Public Identity 6 » sera elle aussi (implicitement) enregistrée, car ces deux identités publiques appartiennent au même 1RS (IRS3) ; l'utilisateur sera donc joignable sur son terminal à la fois via son identité publique 5 et via son identité publique 6. Cet ensemble de données, utilisé lors de la déclaration sur le HSS, est ensuite transmis au S-CSCF en charge de l'utilisateur. Grâce à ces dispositions, le S-CSCF connaît l'ensemble des identités déclarées dans la souscription IMS, sait quelles identités sont enregistrées implicitement, et peut faire le lien entre les identités publiques et l'adresse de contact du terminal (telle que définie dans la RFC 3261 ) afin d'acheminer les appels entrants. De plus, le S-CSCF connaît l'état d'enregistrement de chaque identité publique ; selon les normes actuelles, cet état peut être « registered » (identité enregistrée), « not registered » (identité non enregistrée), ou encore « unregistered » (identité non enregistrée, mais ayant néanmoins bénéficié d'un service IMS, par exemple le traitement d'un appel destiné à cette identité publique).

Selon l'état de l'art, la déclaration dans le HSS d'une souscription IMS est statique. Autrement dit, les données de la souscription IMS ne peuvent être modifiées que par le processus de « Service Livraison » de l'opérateur (i.e. le Système d'information, inaccessible aux utilisateurs).

Or, il serait fort utile de pouvoir modifier de manière dynamique certaines données de souscription : c'est notamment le cas du contenu des 1RS. Les trois exemples suivants illustrent l'utilité d'une gestion dynamique des 1RS.

Si l'IRS représente un IPBX et la souscription IMS représente le compte de souscription d'une entreprise multi-site, alors la gestion dynamique de l'IRS permettrait de déclarer aisément un utilisateur nomade sur tel ou tel site, selon son plan de route, en retrouvant à chaque fois son profil de service à l'identique.

Si l'IRS représente une passerelle réseau telle qu'une « Voice Gateway » SIP, alors la gestion dynamique de l'IRS permettrait de déclarer certains accès comme indisponibles, ou bien à nouveau en service, au fil des évolutions de cette passerelle. Si l'IRS représente un service tel que la liste « Mes adresses professionnelles », alors la gestion dynamique de l'IRS permettrait d'ajouter ou de retirer, par exemple, un téléphone mobile ou un poste fixe privé de cette liste, selon la disponibilité de leur utilisateur.

Or il n'existe pas dans l'état de l'art de possibilité de modifier dynamiquement le contenu d'un 1RS. En particulier, il n'est pas possible de désenregistrer une identité publique dans l'IRS sans désenregistrer la totalité des identités publiques contenues dans cet 1RS.

La présente invention concerne donc un procédé de gestion d'identités publiques dans un réseau IMS, comprenant une étape au cours de laquelle un utilisateur envoie un message audit réseau IMS. Ledit procédé est remarquable en ce que ledit message contient au moins un paramètre spécifique dont la signification est de demander à un serveur S-CSCF dudit réseau IMS de modifier de manière spécifique le statut d'au moins une des identités publiques de l'utilisateur, et/ou d'envoyer à l'utilisateur une liste d'identités publiques de l'utilisateur, en fonction, pour chacune de ces identités publiques, de l'adresse de contact à laquelle cette identité publique est rattachée.

Grâce à l'invention, on peut ajouter n'importe quelle identité publique de la souscription IMS dans n'importe quel 1RS, ou transférer n'importe quelle identité publique d'une identité privée enregistrée vers n'importe quelle autre identité privée enregistrée (et donc diriger les appels de tiers vers une autre adresse de contact). On offre ainsi un maximum de flexibilité à l'utilisateur dans la gestion de sa joignabilité. Par exemple, dans le cas de la figure 2, on peut transférer dynamiquement l'IMPU « Public User Identity 1 » vers l'IRS 3 en retirant cette IMPU pour ΙΜΡΙ « Private User Identity 1 » et en l'ajoutant pour ΙΜΡΙ « Private User Identity 2 » : le résultat de cette opération est illustré sur la figure 3.

De plus, l'invention offre à l'utilisateur la possibilité de connaître le statut de l'une quelconque de ses identités publiques, compte tenu de l'adresse de contact (et donc de l'identité privée) à laquelle cette identité publique est rattachée. La notion de « statut » selon l'invention généralise la notion classique d'état d'enregistrement ; ainsi (comme illustré dans les exemples ci-dessous), le statut d'une identité publique donnée rattachée à une identité privée donnée (et donc, généralement, à une adresse de contact donnée) pourra représenter son état d'enregistrement, mais aussi, par exemple, une maintenance en cours sur cette identité publique, ou l'historique de service, et ainsi de suite. Ces informations pourront, avantageusement, être stockées dans une base de données dédiée.

C'est pourquoi l'invention propose une base de données, comprenant au moins une identité publique d'un abonné à un réseau IMS en association avec une identité privée dudit abonné. Ladite base de données est remarquable en ce qu'elle mentionne le statut de ladite identité publique, ledit statut étant :

- un paramètre (active) indiquant que cette identité publique est actuellement en service et prête à passer au statut « registered » ou « unregistered », ou

- un paramètre (created) indiquant que cette identité publique a été créée mais est actuellement hors service, ou

- un paramètre (maintenance) indiquant que cette identité publique fait actuellement l'objet d'une intervention de maintenance de la part de l'opérateur dudit réseau.

Les statuts que l'on vient de mentionner ne sont donnés qu'à titre d'exemples, et chaque opérateur de réseau pourra naturellement en définir d'autres selon ses besoins.

Selon des caractéristiques particulières, ledit serveur S-CSCF renvoie audit utilisateur, en réponse audit message, une liste d'identités publiques de l'utilisateur en fonction, pour chacune de ces identités publiques, de l'adresse de contact à laquelle cette identité publique est rattachée. Grâce à ces dispositions, l'utilisateur reçoit confirmation que sa requête a bien été prise en compte, et peut vérifier le rattachement de telle ou telle de ses identités publiques.

Selon des caractéristiques encore plus particulières, ledit serveur S-CSCF fournit également dans ladite réponse le statut de chacune des identités publiques de ladite liste.

Grâce à ces dispositions, l'utilisateur peut également vérifier le statut actuel de telle ou telle de ses identités publiques.

Selon d'autres caractéristiques particulières, suite à la modification par ledit serveur S-CSCF du statut d'au moins une des identités publiques de l'utilisateur :

- ce serveur S-CSCF émet, à destination du serveur HSS dudit réseau IMS, une commande représentative de ladite modification, et

- ledit serveur HSS prend en compte cette modification.

Grâce à ces dispositions, le serveur HSS peut enregistrer toute modification dans le profil de l'utilisateur. On rappelle à cet égard que le profil d'un utilisateur est préservé dans le HSS tant que l'utilisateur reste abonné au réseau. Ainsi, lorsque l'utilisateur se désenregistre après avoir obtenu, conformément à l'invention, une modification du statut d'au moins une de ses identités publiques, ce profil modifié est avantageusement préservé en vue d'un usage ultérieur.

Corrélativement, l'invention concerne divers dispositifs.

Elle concerne ainsi, premièrement, un serveur S-CSCF d'un réseau IMS dans un réseau IMS. Ledit serveur S-CSCF est remarquable en ce qu'il comprend des moyens pour :

- enregistrer et mettre à jour le statut de chacune des identités publiques des utilisateurs dont il a la charge, en fonction, pour chacune de ces identités publiques, de l'adresse de contact à laquelle cette identité publique est rattachée, et - suite à la réception d'un message de la part d'un de ces utilisateurs, prendre en compte au moins un paramètre spécifique contenu dans ledit message et dont la signification est de demander audit serveur S-CSCF de modifier de manière spécifique le statut d'au moins une des identités publiques de l'utilisateur, et/ou d'envoyer à l'utilisateur une liste d'identités publiques de l'utilisateur, en fonction, pour chacune de ces identités publiques, de l'adresse de contact à laquelle cette identité publique est rattachée.

Selon des caractéristiques particulières, ledit serveur S-CSCF comprend en outre des moyens pour renvoyer audit utilisateur, en réponse audit message, une liste d'identités publiques de l'utilisateur en fonction, pour chacune de ces identités publiques, de l'adresse de contact à laquelle cette identité publique est rattachée.

Selon des caractéristiques encore plus particulières, ledit serveur S-CSCF comprend en outre des moyens pour fournir également dans ladite réponse le statut de chacune des identités publiques de ladite liste.

Selon d'autres caractéristiques particulières, ledit serveur S-CSCF comprend en outre des moyens pour, suite à la modification par ce serveur S-CSCF du statut d'au moins une des identités publiques de l'utilisateur, émettre, à destination du serveur HSS dudit réseau IMS, une commande représentative de ladite modification.

L'invention concerne aussi, deuxièmement, un serveur HSS dans un réseau IMS. Ledit serveur HSS est remarquable en ce qu'il comprend des moyens pour recevoir de la part d'un serveur S-CSCF dudit réseau IMS une commande représentative d'une modification du statut d'au moins une des identités publiques d'un utilisateur abonné audit réseau IMS, et pour prendre en compte ladite modification.

L'invention concerne aussi, troisièmement, un serveur d'un réseau IMS. Ledit serveur est remarquable en qu'il comprend, ou peut accéder à, une base de données telle que décrite succinctement ci-dessus. Ce serveur peut, notamment, être avantageusement un serveur S-CSCF ou un serveur HSS.

L'invention concerne aussi, quatrièmement, un équipement apte à envoyer un message à un réseau IMS. Ledit équipement est remarquable en ce qu'il possède des moyens pour inclure dans ledit message un paramètre spécifique dont la signification est de demander à un serveur S-CSCF dudit réseau IMS de modifier de manière spécifique le statut d'au moins une des identités publiques de l'utilisateur de cet équipement, et/ou d'envoyer à l'utilisateur de cet équipement une liste d'identités publiques de cet utilisateur, en fonction, pour chacune de ces identités publiques, de l'adresse de contact à laquelle cette identité publique est rattachée.

Comme indiqué ci-dessus, cet équipement peut être aussi bien un terminal fixe ou mobile, qu'une passerelle domestique ou située dans une entreprise, ou encore qu'une passerelle d'opérateur réseau.

Les avantages offerts par ces dispositifs sont essentiellement les mêmes que ceux offerts par les procédés corrélatifs succinctement exposés ci-dessus.

Selon des dispositions particulières, on pourra réaliser l'un quelconque des dispositifs succinctement exposés ci-dessus dans le contexte d'un circuit électronique. Ce circuit électronique pourra, par exemple, être constitué par une puce à logique câblée ou comprendre un microprocesseur.

Selon d'autres dispositions particulières, on pourra réaliser l'un quelconque des dispositifs succinctement exposés ci-dessus dans le contexte d'instructions logicielles.

L'invention vise donc également un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des instructions pour l'exécution des étapes de l'un quelconque des procédés de gestion d'identités publiques succinctement exposés ci-dessus, lorsqu'il est exécuté sur un ordinateur.

Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par lesdits procédés.

D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs. La description se réfère aux figures qui l'accompagnent, dans lesquelles :

- la figure 1 , décrite ci-dessus, représente un premier exemple de données liées à une souscription IMS,

- la figure 2, décrite ci-dessus, représente un second exemple de données liées à une souscription IMS,

- la figure 3, décrite ci-dessus, représente les données résultant d'une modification dynamique par l'utilisateur des données de la figure 2, et

- la figure 4 illustre, selon un mode de réalisation de l'invention, un procédé d'enregistrement dans le HSS d'une modification dynamique d'un statut d'une identité publique d'un utilisateur.

Dans un réseau IMS, le serveur de base de données HSS est notamment interrogé :

• par la fonction l-CSCF lors de l'enregistrement d'un terminal d'utilisateur afin d'allouer un serveur l/S-CSCF au terminal ou de retrouver le serveur l/S-CSCF qui lui a été déjà alloué ;

• par la fonction S-CSCF lors de l'enregistrement initial du terminal afin de télécharger les données concernant les services souscrits, dont notamment les points de détection qui permettront au serveur l/S-CSCF de déterminer quel message de signalisation il doit acheminer vers quel serveur d'application (tel qu'un serveur de messagerie vocale, un serveur de présence ou un serveur de téléphonie) ; • par la fonction S-CSCF lors des enregistrements du terminal, afin d'informer le serveur HSS de l'installation ou de la prolongation d'un enregistrement sur le serveur l/S-CSCF ; et

• par la fonction S-CSCF, afin de récupérer les informations nécessaires à l'authentification de la signalisation émise par le terminal.

Les données liées à la souscription IMS et déclarées sur le HSS sont transmises au S-CSCF en charge de l'utilisateur grâce aux commandes Diameter SAA (Server-Assignment-Answer) ou PPR (Push- Profile-Request). La commande SAA est émise par le HSS en réponse à une commande SAR (Server-Assignment-Request) émise par le S-CSCF vers le HSS lors de l'enregistrement d'un terminal ou lors du traitement d'un appel arrivé à destination d'un abonné non enregistré. La commande PPR est émise par le HSS suite à une modification par un opérateur du profil de l'abonné (changement de l'IRS, du mot de passe, et ainsi de suite).

Comme mentionné ci-dessus, dans l'art antérieur, le contenu de la souscription IMS d'un utilisateur est statique. Les identités publiques de l'utilisateur, au moyen desquelles il sera joignable par d'autres utilisateurs du réseau, sont définies par l'opérateur, et il n'est pas possible pour un utilisateur de les modifier.

L'invention introduit la possibilité pour un utilisateur de gérer lui- même les identités au moyen desquelles il sera connu dans le réseau, en envoyant au réseau IMS un message approprié. Compte tenu des fortes contraintes inhérentes à la manipulation d'identités publiques, il est toutefois préférable que l'opérateur du réseau introduise un indicateur dans la souscription IMS de l'utilisateur pour déclarer si l'utilisateur est autorisé ou non à mettre en œuvre la gestion dynamique des identités publiques selon l'invention ; cet indicateur sera par exemple configuré dans le HSS, puis copié dans le S-CSCF. L'invention introduit également la possibilité pour un serveur S- CSCF d'associer à chaque identité publique d'un utilisateur dont il a la charge le statut de cette identité publique en fonction de l'adresse de contact à laquelle cette identité publique est rattachée (la même identité publique pouvant être rattachée à une ou plusieurs adresse(s) de contact). Le serveur S-CSCF selon l'invention a donc les moyens de mettre à jour ces statuts au fur et à mesure de leur évolution de service.

On va maintenant illustrer le fonctionnement et les avantages de l'invention dans le cadre de divers modes de réalisation, en s'appuyant sur la figure 2, déjà décrite ci-dessus, et dans laquelle, par exemple :

• « Public User Identity 1 » est <sip:IMPU1 @home. domain. com>, et

• « Public User Identity 2 » est <tel:IMPU1 >

en association avec l'adresse de contact <sip:AoC1 > ;

• « Public User Identity 5 » est <sip:IMPU4@home. domain. com>, et · « Public User Identity 6 » est <sip:IMPU5@home. domain. com> en association avec l'adresse de contact <sip:AoC2> ; et

• « Public User Identity 3 » est <sip:IMPU2@home. domain. com>, et

• « Public User Identity 4 » est <sip:IMPU3@home. domain. com> en association avec les deux adresses de contact.

Le procédé selon l'invention est déclenché par l'envoi d'un message au réseau IMS par un utilisateur de ce réseau. De manière classique, ce message contient un identifiant de l'utilisateur auprès du réseau IMS, tel que l'une des adresses de contact ou l'une des identités publiques de l'utilisateur.

Considérons par exemple l'enregistrement initial de cet utilisateur sur le réseau IMS avec l'identité publique « IMPU1 @home.domain.com » :

REGISTER sip : home . domain . corn SIP/2.0

To: <sip : IMPUlghome . domain . com>

From : <sip : IMPUIShome . domain . com> ; tag=regtagxx

Call-Id: diagxx

CSeq: 1 REGISTER Contact: <sip:AoCl>; [...] ; expires=3600

Une fois l'utilisateur enregistré, le S-CSCF prend en compte le paramètre représenté par l'adresse de contact (<sip:AoC1 >) mentionnée dans le message REGISTER en renvoyant de préférence à l'utilisateur l'ensemble de ses identités publiques connues et en service associées à cette adresse de contact, par exemple dans des en-têtes SIP « P-Associated-URI » : SIP/2.0 200 OK

To: <sip : IMPU1 @home . domain . com>

From : <sip : IMPUIShome . domain . com> ; tag=regtagxx

Call-Id: diagxx

CSeq: 1 REGISTER

Contact: <sip : AoCl> ; [...]; expires=3600

P-Associated-URI : <sip : IMPUl@home . domain . com>

P-Associated-URI : <tel:IMPUl>

P-Associated-URI : <sip : IMPU2@home . domain . com>

P-Associated-URI : <sip : IMPU3@home . domain . com>

On va décrire à présent un mode de réalisation de l'invention dans lequel on utilise la méthode SIP REGISTER pour véhiculer les informations de gestion dynamique des identités publiques. Mais on pourrait également utiliser une autre méthode SIP que la méthode REGISTER, par exemple une méthode PUBLISH, ou une nouvelle méthode spécifique dédiée. En variante, on pourrait tout aussi bien véhiculer les informations de gestion dynamique des identités publiques selon l'invention dans un « body XML ».

Si l'utilisateur souhaite, par exemple, retirer l'identité publique IMPU2 de la liste ci-dessus, il lui suffit (dans l'hypothèse où l'indicateur de gestion lui autorise ce genre de manipulation) d'envoyer le message REGISTER suivant, utilisant le paramètre « remove » :

REGISTER sip : home . domain . corn SIP/2.0

To: <sip : IMPU1 @home . domain . com>

From: <sip : IMPU1 @home . domain . com> ; tag=regtagxx

Call-Id: diagxx

CSeq: 1 REGISTER

Contact: <sip:AoCl>; [...] ; remove=<sip : IMPU2@home . domain . com> :

not_reg; expires=3600 De préférence, le S-CSCF renvoie l'ensemble des identités publiques connues et en service de l'utilisateur associées à l'adresse de contact concernée afin de confirmer la modification :

SIP/2.0 200 OK

To: <sip : IMPU1 @home . domain . com>

From : <sip : IMPUIShome . domain . com> ; tag=regtagxx

Call-Id: diagxx

CSeq: 1 REGISTER

Contact: <sip:AoCl>; [...] ; expires=3600

P-Associated-URI : <sip : IMPUl@home . domain . com>

P-Associated-URI : <tel:IMPUl>

P-Associated-URI : <sip : IMPU3@home . domain . com>

On notera que, contrairement à l'état de l'art, le S-CSCF ne renvoie pas l'identité publique <sip:IMPU2@home. domain. com>, en dépit du fait qu'elle appartient au même 1 RS (I RS2) que l'identité publique <sip:IMPU3@home. domain. com>.

On constate effectivement que le S-CSCF a bien pris en compte le paramètre « remove » en relation avec l'adresse de contact <sip:AoC1 > puisque l'identité publique IMPU2 n'apparaît plus. Dorénavant, cette identité publique ayant (voir requête ci-dessus) le statut de « non enregistrée » (paramètre « not_reg ») pour <sip:AoC1 >, les appels destinés à IMPU2 seront dirigés uniquement vers l'adresse de contact <sip:AoC2>.

Supposons maintenant que l'utilisateur souhaite rajouter l'identité IMPU2 à sa liste des identités publiques associées à l'adresse de contact <sip:AoC1 >. Il lui suffit alors (dans l'hypothèse où l'indicateur de gestion lui autorise ce genre de manipulation) d'envoyer le message REGISTER suivant, utilisant le paramètre « add » :

REGISTER sip : home . domain . corn SIP/2.0

To: <sip : IMPU1 @home . domain . com>

From: <sip : IMPU1 @home . domain . com> ; tag=regtagxx

Call-Id: diagxx

CSeq: 1 REGISTER

Contact : <sip : AoCl> ; [...] ; add=<sip : IMPU2@home . domain . com> :

active; expires=3600 De préférence, le S-CSCF renvoie l'ensemble des identités publiques connues et en service de l'utilisateur associées à l'adresse de contact concernée afin de confirmer la modification :

SIP/2.0 200 OK

To: <sip : IMPU1 @home . domain . com>

From : <sip : IMPUIShome . domain . com> ; tag=regtagxx

Call-Id: diagxx

CSeq: 1 REGISTER

Contact: <sip:AoCl>; [...] ; expires=3600

P-Associated-URI : <sip : IMPUl@home . domain . com>

P-Associated-URI : <tel:IMPUl>

P-Associated-URI : <sip : IMPU2@home . domain . com>

P-Associated-URI: <sip : IMPU3@home . domain . com>

On constate effectivement que le S-CSCF a bien pris en compte le paramètre « add » puisque l'identité publique IMPU2 figure bien dans cette liste en relation avec l'adresse de contact <sip:AoC1 > ; le statut associé est « en service » (paramètre « active ») conformément à la requête ci-dessus. Ce statut signifie que la configuration de cette identité publique IMPU2 par l'opérateur du réseau est terminée, de sorte que le réseau est prêt à traiter, en tant que premier service associé à cette identité publique, soit une connexion de l'utilisateur propriétaire de cette identité publique (passage du statut « active » au statut « registered »), soit un appel (qui sera renvoyé sur messagerie) à l'intention de cet utilisateur (passage du statut « active » au statut « unregistered »).

Supposons maintenant que l'utilisateur souhaite connaître la liste de ses identités publiques, ainsi que leur statut dans le S-CSCF. Il lui suffit alors (dans l'hypothèse où l'indicateur de gestion lui autorise ce genre de manipulation) d'envoyer le message REGISTER suivant, utilisant le paramètre « list » :

REGISTER sip : home . domain . corn SIP/2.0

To: <sip : IMPU1 @home . domain . com>

From: <sip : IMPU1 @home . domain . com> ; tag=regtagxx

Call-Id: diagxx

CSeq: 1 REGISTER

Contact: list=all; Le S-CSCF renvoie alors à l'utilisateur l'ensemble de ses identités publiques connues, ainsi que leur statut respectif, eu égard, pour chacune de ces identités publiques, à l'adresse de contact concernée :

SIP/2.0 200 OK

To: <sip : IMPU1 @home . domain . com>

From : <sip : IMPUIShome . domain . com> ; tag=regtagxx

Call-Id: diagxx

CSeq: 1 REGISTER

Contact: <sip:AoCl>; [...] ; expires=2340

P-Associated-URI : <sip : IMPUlghome . domain . com> : registered: Aocl P-Associated-URI : <tel : IMPU1> : registered: Aocl

P-Associated-URI : <sip : IMPU2@home . domain . com> : active: Aocl P-Associated-URI : <sip : IMPU3@home . domain . com> : created

Contact: <sip:AoC2>; [...] ; expires=1540

P-Associated-URI : <sip : IMPU2@home . domain . com> : active: Aoc2 P-Associated-URI : <sip : IMPU3@home . domain . com> : created

P-Associated-URI : <sip : IMPU4@home . domain . com> : not_reg

P-Associated-URI : <sip : IMPU5@home . domain . com> : maintenance

En variante, l'invention propose un nouveau paramètre, désigné ci- dessous par « pau », que le S-CSCF peut insérer dans l'en-tête « Contact » pour représenter les P-Associated-URI et leur statut respectif :

SIP/2.0 200 OK

To: <sip : IMPU1 @home . domain . com>

From : <sip : IMPUIShome . domain . com> ; tag=regtagxx

Call-Id: diagxx

CSeq: 1 REGISTER

Contact : <sip : AoCl> ; [...] ; expires=2340 ;

pau : <sip : IMPU1 @home . domain . com> : registered;

pau: <tel : IMPU1> : registered;

pau : <sip : IMPU2 @home . domain . com> : active;

pau : <sip : IMPU3 @home . domain . com> : created

Contact : <sip : AoC2> ; [...] ; expires=1540 ;

pau : <sip : IMPU2 @home . domain . com> : active;

pau : <sip : IMPU3 @home . domain . com> : created;

pau : <sip : IMPU4@home . domain . com> : not_reg;

pau : <sip : IMPU5@home . domain . com> : maintenance

On constate effectivement que le S-CSCF a bien pris en compte le paramètre « list=all » puisque les six identités publiques de l'utilisateur figurent dans cette liste. On note en particulier que l'identité IMPU3 possède le statut de « créée » (paramètre « created »), qui indique que cette identité a été créée, mais est actuellement hors service (par exemple, suite à un déménagement de l'abonné). Le statut « maintenance » de l'identité IMPU5, quant à lui, indique qu'une intervention sur cette identité est en cours ; elle est donc temporairement inutilisable par le propriétaire de cette identité publique (mais l'opérateur peut éventuellement l'utiliser pour effectuer des tests de ligne).

L'invention s'applique naturellement aussi aux « Wilcard Public

User Identifies » (mots anglais signifiant « Identités Publiques d'Utilisateur avec Joker »), lesquelles définissent simplement un ensemble, ou une gamme, d'identités publiques possibles pour une identité privée donnée. On pourra par exemple supprimer une identité publique particulière dans cet ensemble ou cette gamme.

Enfin, on notera que l'invention permet de modifier le statut d'une identité publique particulière pour l'ensemble des adresses de contact attribuées à l'utilisateur. Par exemple, si l'utilisateur souhaite mettre en service son identité IMPU3 pour ses deux adresses de contact (i.e. modifier son statut de « created » à « active »), il pourra (dans l'hypothèse où l'indicateur de gestion lui autorise ce genre de manipulation) utiliser le message suivant, qui utilise les paramètres « ail », « add » et « active » (on utilise de préférence le paramètre « ail » au lieu du paramètre « ^* » afin d'éviter la confusion avec les normes en vigueur, qui prévoient l'utilisation du symbole « ^* » pour le désenregistrement de l'ensemble des contacts) :

REGISTER sip : home . domain . corn SIP/2.0

To: <sip : IMPU1 @home . domain . com>

From: <sip : IMPU1 @home . domain . com> ; tag=regtagxx

Call-Id : diagxx

CSeq: 1 REGISTER

Contact: ail; [...] ; add=<sip : IMPU3@home . domain . com> : active;

De préférence, le S-CSCF renvoie, pour chacune des adresses de contact de l'utilisateur, l'ensemble des identités publiques connues ainsi que leur statut associé afin de confirmer la modification :

SIP/2.0 200 OK

To: <sip : IMPU1 @home . domain . com>

From : <sip : IMPUIShome . domain . com> ; tag=regtagxx

Call-Id : diagxx

CSeq: 1 REGISTER Contact : <sip : AoCl> ; [...] ; expires=2340 ;

pau : <sip : IMPU1 @home . domain . com> : registered;

pau: <tel : IMPU1> : registered;

pau : <sip : IMPU2 @home . domain . com> : active;

pau : <sip : IMPU3 @home . domain . com> : active

Contact : <sip : AoC2> ; [...] ; expires=1540 ;

pau : <sip : IMPU2 @home . domain . com> : active;

pau : <sip : IMPU3 @home . domain . com> : active;

pau : <sip : IMPU @home . domain . com> : not_reg;

pau : <sip : IMPU5@home . domain . com> : maintenance

On constate effectivement que le S-CSCF a bien pris en compte les paramètres du message REGISTER puisque l'identité publique <sip:IMPU3@home. domain. com> a été mise en service en référence aux adresses de contact <sip:AoC1 > et <sip:AoC2>. Ainsi, par exemple, si ces adresses de contact correspondent à un téléphone fixe et à un téléphone mobile de l'utilisateur, ces deux téléphones vont sonner lorsque, postérieurement à leur rafraîchissement d'enregistrement (passage de « active » à « registered »), un correspondant saisit sur son propre terminal le numéro de téléphone associé à IMPU3.

On a décrit ci-dessus divers modes de réalisation du procédé selon l'invention de gestion dynamique de ses identités publiques par un utilisateur. La prise en compte des requêtes de l'utilisateur est du ressort du S-CSCF puisque c'est ce dernier qui a en charge la gestion de l'enregistrement des utilisateurs. Cependant, l'évolution des configurations des identités publiques de l'abonné seront perdues lorsque l'utilisateur va se désenregistrer. En effet, dans l'état actuel des normes, la structure de la souscription IMS d'un abonné résultant de la succession des requêtes de modification émises par cet abonné ne peut être transmise vers le HSS. Les normes ne proposent qu'une transmission du profil de l'abonné dans le sens HSS vers S-CSCF, et non dans le sens S-CSCF vers HSS. Aussi, les modifications relatives aux opérations de gestion successives de ses identités par l'utilisateur ne pourront jamais perdurer au-delà de l'expiration d'un enregistrement. Ce constat est particulièrement pénalisant si l'utilisateur est un administrateur en charge d'un IPPBX, mais il sera également déroutant pour un utilisateur grand-public qui ne comprendra pas pourquoi la configuration qu'il avait mise en place n'a pas été sauvegardée dans le réseau.

C'est pourquoi, selon un mode de réalisation de l'invention, on introduit une nouvelle commande Diameter sur les interfaces Cx/Dx pour la sauvegarde dans le HSS des modifications de configuration décrites ci- dessus. Cette commande Diameter, que l'on appellera UPR (pour Update-Profile-Request), est émise par le S-CSCF vers le HSS suite au traitement d'une requête de modification dynamique des identités publiques par un utilisateur.

Sur réception de cette nouvelle commande Diameter, le HSS met à jour le profil de l'abonné conformément à la structure transmise dans le message UPR (structure elle-même identique à la structure utilisée dans les messages PPR et SAA mentionnés ci-dessus). Cette structure constitue une extension selon la présente invention de l'AVP (Attribute Value Pair) des commandes Diameter tel que défini dans la norme 3GPP TS 29.228. Selon cette extension, l'AVP inclut un champ « User-Data », qui est structuré selon un modèle XML des statuts d'une identité publique.

Le HSS acquitte ensuite la commande UPR par une commande que l'on appellera UPA (pour Update-Profile-Answer) indiquant le succès ou l'échec de la modification de profil.

La réception par le S-CSCF d'un UPA indiquant une modification réussie provoque l'émission d'un code de retour de succès vers l'utilisateur (par exemple, une réponse 200 OK à la requête REGISTER de modification du statut d'une identité publique). La réception par le S- CSCF d'un UPA indiquant une erreur dans le traitement de la modification du profil de l'abonné provoque l'émission d'un code de retour d'échec vers l'utilisateur (par exemple, une réponse 500 Cx « unable to comply »), afin de l'informer que sa modification n'a pas été prise en compte. Ce mécanisme d'enregistrement des modifications dans le HSS est illustré ci-dessous par un exemple, en référence à la figure 4.

A l'étape EO, la souscription IMS de l'abonné contient les informations sur le statut de chacune de ses identités publiques suite à l'enregistrement de l'abonné.

A l'étape E1 , l'abonné décide de modifier le statut de son identité publique IMPU2. Il émet pour cela via son terminal une demande de modification à destination du réseau.

A l'étape E2, le S-CSCF en charge de cet abonné informe le HSS que l'abonné a demandé à modifier le statut de l'identité publique IMPU2 pour la faire passer dans l'état « non-enregistré » (sous réserve que l'indicateur de gestion autorise l'abonné à le faire, sinon le S-CSCF renvoie directement un code d'erreur vers l'abonné sans tenter de contacter le HSS).

A l'étape E3, le HSS met à jour la souscription de l'abonné conformément aux informations reçues du S-CSCF.

A l'étape E4, le HSS informe le S-CSCF que la commande UPR a été positivement prise en compte.

Enfin, à l'étape E5, le S-CSCF en informe l'utilisateur.

La mise en œuvre de l'invention au sein, en particulier, de nœuds d'un réseau de télécommunications (notamment, les serveurs S-CSCF, les serveurs HSS et les terminaux d'utilisateur) peut être réalisée au moyen de composants logiciels et/ou matériels.

Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de nœud de réseau. C'est pourquoi, comme indiqué ci-dessus, la présente invention concerne également un système informatique. Ce système informatique comporte de manière classique une unité centrale de traitement commandant par des signaux une mémoire, ainsi qu'une unité d'entrée et une unité de sortie. De plus, ce système informatique peut être utilisé pour exécuter un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de gestion d'identités publiques selon l'invention.

En effet, l'invention vise aussi un programme d'ordinateur téléchargeable depuis un réseau de communication comprenant des instructions pour l'exécution des étapes d'un procédé de gestion d'identités publiques selon l'invention, lorsqu'il est exécuté sur un ordinateur. Ce programme d'ordinateur peut être stocké sur un support lisible par ordinateur et peut être exécutable par un microprocesseur.

Ce programme peut utiliser n'importe quel langage de programmation, et se présenter 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, inamovible, ou partiellement ou totalement amovible, lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.

Le support d'informations 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 une clé USB (« USB flash drive » en anglais) ou un disque dur.

D'autre part, le support d'informations 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 d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

En variante, le support d'informations 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é de gestion d'identités publiques selon l'invention.