Brevet FR2931606A1 — publié le 20091127

Système, procédé, serveur d'application et HSS pour l'autoprovisionnement d'au moins un service dans au moins un serveur d'application d'une architecture IMS La présente invention concerne le domaine des communications dans les systèmes à architecture de type IMS (� IP Multimedia Subsystem �, selon la terminologie anglo-saxonne). L'invention concerne plus particulièrement l'autoprovisionnement (� autoprovisioning �, selon la terminologie anglo- saxonne) d'un service - dans un serveur d'application au sein d'une architecture de type IMS, c'est-à-dire la fourniture et la mise à jour de données utilisateurs (provisionnement) permettant l'accès des utilisateurs aux divers services supportés par le serveur d'application dans le système de type IMS. En effet, dans les systèmes à architecture de type IMS, c'est-à- lo dire dans un réseau de type IMS (ou ses équivalents éventuels), divers services peuvent être fournis aux utilisateurs, tels que des communications ou l'accès à des contenus multimédia. Pour cela, les utilisateurs sont authentifiés d'après des données utilisateurs enregistrées auprès des fournisseurs de services. L'IMS est une architecture standardisée de 15 � Réseau de Nouvelle Génération � (NGN, pour � Next Generation Network �, selon la terminologie anglo-saxonne) qui permet de fournir des services de téléphonie et multimédias fixes et mobiles. L'IMS utilise une implémentation du protocole SIP (� Session Initiation Protocol � selon la terminologie anglo-saxonne, qui est un protocole standard ouvert de 20 télécommunications multimédia destiné à de nombreuses applications telles que la téléphonie sous IP, la visiophonie, la messagerie instantanée, la réalité virtuelle ou même les jeux vidéo) standardisée par le 3GPP (� 3rd Generation Partnership Project � selon la terminologie anglo-saxonne, qui est un projet de coopération mondiale entre organismes de standardisation 25 régionaux en télécommunications et visant à produire des spécifications techniques pour les réseàux mobiles de 3e génération). L'IMS fonctionne sur un protocole standard IP (� Internet Protocol � selon la terminologie anglo-saxonne) défini par l'IETF (� Internet Engineering Task Force �, selon la terminologie anglo-saxonne) et permet ainsi de faire converger l'Internet et le monde de la téléphonie-mobile en permettant aux utilisateurs d'accéder à divers types de services (sous IP) quelque soit le type de terminal qu'ils utilisent. Dans une architecture IMS, un serveur d'application destiné à fournir au moins un service aux utilisateurs peut comporter une base de données utilisateur pour identifier les utilisateurs accédant au(x) service(s) et enregistrer des préférences des utilisateurs ou tout type d'informations utiles pour le service. L'accès au service (du serveur d'application) est réalisé par io l'intermédiaire d'un serveur relais ou proxy (� Proxy Cali Session Control Function � selon la terminologie anglo-saxonne) qui identifie le terminal utilisateur accédant au coeur du réseau de communication (par l'identifiant du terminal, appelé IMPI, pour � IP Multimedia Private Identity � selon la terminologie anglo-saxonne). Une des fonctions de ce proxy est de transférer 15 les messages SIP du terminal de l'utilisateur vers l'élément IMS adéquat pour fournir le service, selon le type de message ou la procédure à effectuer (le I-CSCF, pour � Interrogating Cali Session Control Function � ou le SCSCF, pour � Serving Cali Session Control Function � selon la terminologie anglo-saxonne). L'accès au service (du serveur d'application) est autorisé, 20 au sein du réseau de communication que le terminal de l'utilisateur emprunte, par l'intermédiaire d'un serveur d'authentification (HSS, pour � Home Subscriber Server � selon la terminologie anglo-saxonne) comportant une base dè données interne ou externe (� Common profile Store �, selon la terminologie anglo-saxonne) d'authentification des 25 utilisateurs identifiés par des identifiants publics (IMPU, pour � IP Multimedia Public Identity � selon la terminologie anglo-saxonne). La base de données du HSS stocke également les autorisations d'accès recueillies par un système d'information pour les différents services. Ce système d'information permet de recueillir les informations relatives aux services souscrits par 30 l'utilisateur et de provisionner son compte auprès des gestionnaires du réseau de communication en enregistrant ses souscriptions dans le HSS (on parle alors de provisionnement ou de � provisioning � selon la terminologie anglo-saxonne). Même lorsqu'un serveur d'application stocke une base de données utilisateurs, le provisionnement peut ainsi se faire par l'intermédiaire du réseau de communication (et donc du HSS) au lieu de nécessiter l'implémentation d'une interface entre le système d'information et le serveur d'application (on parle alors d'autoprovisionnement ou � autoprovisioning � selon la terminologie anglo-saxonne). Le serveur d'application et le HSS dialoguent entre eux par l'intermédiaire d'une interface, dite interface Sh, en utilisant un protocole normalisé (protocole � Diameter �) et les données du serveur d'application peuvent être mises à jour automatiquement depuis le io HSS lorsqu'un abonnement de notifications est établi entre le HSS et le serveur d'application. Ainsi, les données stockées par le serveur d'application sont mises à jour automatiquement à partir des données de l'utilisateur stockées par le HSS. Cependant, cette architecture IMS fait naître un problème nouveau qui concerne la modification de l'identifiant de is l'utilisateur (IMPU). Le système d'information, qui n'appartient pas à l'architecture IMS proprement dite, permet à un utilisateur de changer son identifiant public (I'IMPU). Il est hautement avantageux que ce changement puisse être effectué en conservant toutes les données de l'utilisateur dans le HSS, or l'interface Sh entre le HSS et le serveur d'application ne permet pas 20 de changer d'IMPU en conservant les données de l'utilisateur dans la base de données du serveur d=application. En effet, la norme IMS ne prévoit aucun mécanisme pour permettre à un utilisateur de changer son IMPU tout en conservant les données enregistrées dans les bases de données. Ce problème nouveau concerne 25 donc le changement d'IMPU dans une base de données d'un serveur d'application d'une architecture IMS ou, plus particulièrement, la conservation des informations stockées en relation avec un IMPU dans une base de données d'un serveur d'application d'une architecture IMS lors de la modification d'un IMPU d'un utilisateur. 30 Dans ce contexte, il est intéressant de proposer une solution à ce problème, pour permettre à un utilisateur de changer d'IMPU tout en conservant l'ensemble des informations qu'il a enregistrées dans les serveurs d'applications, de façon à permettre un autoprovisionnement complet, même lors d'un changement d'IMPU par un utilisateur. La présente invention a pour but de supprimer au moins un des inconvénients de l'art antérieur en proposant un système d'autoprovisionnement d'au moins un service dans au moins un serveur d'application d'au moins une architecture IMS permettant, sans nécessiter d'interface spécifique de provisionnement, de provisionner les données d'au moins une base de données du serveur d'application par modification d'au moins un identifiant public d'au moins un utilisateur, tout en conservant les io données de l'utilisateur stockées dans la base de données du serveur d'application de l'architecture IMS. Ce but est atteint par un système d'autoprovisionnement d'au moins un service dans au moins un serveur d'application d'au moins une architecture IMS, l'architecture IMS comprenant au moins un serveur 15 d'authentification d'utilisateurs, dit HSS, comportant des moyens de traitement accédant à au moins une base de données stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS, ces données étant indexées selon au moins un identifiant public, dit IMPU, des utilisateurs, et au moins un serveur 20 d'application comportant des moyens de traitement agencés pour fournir au moins un service aux utilisateurs et accéder à au moins une base de données stockant au moins des données relatives aux utilisateurs autorisés à accéder audit service, indexées selon au moins un identifiant public des utilisateurs, le HSS et- le serveur d'application communiquant via des 25 notifications normalisées selon un protocole standard, caractérisé en ce que les moyens de traitement du HSS sont agencés en outre pour, d'une part, recevoir et traiter une demande de changement d'un premier identifiant public vers un second identifiant public, pour un utilisateur provisionné dans la base de données du HSS et autoprovisionné dans la base de données du 30 serveur d'application, et pour, d'autre part, inclure, dans une notification envoyée au serveur d'application, des données représentatives de la modification de l'identifiant public, les moyens de traitement du serveur d'application étant agencés en outre pour enregistrer dans la base de données des utilisateurs autorisés à accéder au service, en réponse à cette notification, le second identifiant public avec les données qui étaient indexées selon le premier identifiant public. Selon une autre particularité, les moyens de traitement du HSS sont agencés pour inclure les données de modification au niveau d'au moins un champ standard laissé libre dans la notification selon le protocole standard, et pour envoyer cette notification au serveur d'application, puis pour envoyer lo au serveur d'application une notification de suppression des données relatives au premier identifiant public, les moyens de traitement du serveur d'application étant agencés pour recevoir cette notification selon le protocole standard, pour enregistrer temporairement les données de modification incluses dans cette notification en attendant la suppression du premier 15 identifiant et pour enregistrer le second identifiant public avec les données qui étaient indexées selon le premier identifiant public, en supprimant le premier identifiant public, lors de la réception de la notification de suppression des données relatives au premier identifiant public. Selon une autre particularité, les moyens de traitement du HSS sont 20 agencés pour générer une notification spécifique de modification d'un premier identifiant public, vers un second identifiant public, et incorporer dans cette notification spécifique les données représentatives de la modification et envoyer cette notification spécifique au serveur d'application, les moyens de traitement du serveur d'application étant agencés pour enregistrer le second 25 identifiant public avec les données qui étaient indexées selon le premier identifiant public, lors de la réception de cette notification spécifique. Selon une autre particularité, les moyens de traitement du HSS, agencés pour recevoir et traiter la demande de changement d'un premier identifiant public vers un second identifiant public, sont agencés pour traiter 30 cette demande notamment en enregistrant le second identifiant public avec les données qui étaient indexées selon le premier identifiant public, dans la base de données stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS. Selon une autre particularité, les moyens de traitement du HSS sont agencés pour recevoir et traiter la demande de changement d'un premier identifiant public vers un second identifiant public en provenance d'au moins un système d'information recueillant les données relatives aux utilisateurs de l'architecture IMS et à leurs souscriptions de services. Selon une autre particularité, les moyens de traitement du HSS et du serveur d'application sont agencés pour établir un abonnement de io notifications pour la mise à jour automatique des données de la base de données du serveur d'application lors de changements des données de la base de données du HSS, les moyens de traitement du serveur d'application étant agencés pour requérir, auprès du HSS, un nouvel abonnement de notification pour le second identifiant public suite à l'enregistrement de la 15 modification lorsque le HSS ne conserve pas l'abonnement dans la base de données stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS, suite à la modification, et les moyens de traitement du HSS étant agencés pour créer ce nouvel abonnement lors de la réception de cette requête, ou pour modifier 20 l'identifiant public correspondant à l'abonnement dans les données de la base de données stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs, lorsque le HSS conserve l'abonnement suite à la modification. Un autre but de la présente invention est de supprimer au moins un 25 des inconvénients de l'art antérieur en proposant un procédé d'autoprovisionnement d,au moins un service dans au moins un serveur d'application d'au moins une architecture IMS permettant, sans nécessiter d'interface spécifique de provisionnement, de provisionner les données d'au moins une base de données du serveur d'application par modification d'au 30 moins un identifiant public d'au moins un utilisateur, tout en conservant les données de l'utilisateur stockées dans la base de données du serveur d'application de l'architecture IMS. Ce but est atteint par un procédé d'autoprovisionnement d'au moins un service dans au moins un serveur d'application d'au moins une architecture IMS, l'architecture IMS comprenant au moins un serveur d'authentification d'utilisateurs, dit HSS, comportant des moyens de traitement accédant à au moins une base de données stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS, ces données étant indexées selon au moins ro un identifiant public, dit IMPU, des utilisateurs, et au moins un serveur d'application comportant des moyens de traitement agencés pour fournir au moins un service aux utilisateurs et accéder à au moins une base de données stockant au moins des données relatives aux utilisateurs autorisés à accéder audit service,-indexées selon au moins un identifiant public des 15 utilisateurs, le HSS et le serveur d'application communiquant via des notifications normalisées selon un protocole standard, le procédé étant caractérisé en ce qu'il comporte les étapes suivantes : réception et traitement, par les moyens de traitement du HSS, d'une demande de changement d'un premier identifiant public 20 vers un second identifiant public, pour un utilisateur provisionné dans la base de données du HSS et autoprovisionné dans la base de données du serveur d'application, inclusion, par les moyens de traitement du HSS, dans une notification envoyée au serveur d'application, des données 25 représentatives de la modification de l'identifiant public, enregistrement, par les moyens de traitement du serveur d'application, dans la base de données des utilisateurs autorisés à accéder au service, en réponse à cette notification, du second identifiant public avec les données qui étaient 30 indexées selon le premier identifiant public. Selon une autre particularité, l'étape d'inclusion des données représentatives de la modification de l'identifiant public dans la notification comporte les étapes suivantes : - insertion, par les moyens de traitement du HSS, de ces données au niveau d'au moins un champ standard laissé libre dans la notification selon le protocole standard, et envoi de cette notification, réception de la notification selon le protocole standard et enregistrement temporaire, par les moyens de traitement du serveur d'application, des données de modification incluses dans la notification, en attendant la suppression du premier identifiant - création et envoi, par les moyens de traitement du HSS, d'une notification de suppression des données relatives au premier identifiant public vers le serveur d'application, - réception, par les moyens de traitement du serveur d'application, de la notification de suppression des données relatives au-premier identifiant public, permettant alors la mise en oeuvre de l'étape d'enregistrement du second identifiant 20 public et une étape de suppression du premier identifiant public Selon une autre particularité, l'étape d'inclusion des données représentatives de la modification de l'identifiant public dans la notification comporte les étapes suivantes : création, par les moyens de traitement du HSS, d'une 25 notification spécifique de modification d'un premier identifiant public, vers un second identifiant public, incorporation, dans cette notification spécifique, des données représentatives de la modification, et envoi de la notification spécifique, 30 réception de cette notification spécifique par les moyens de traitement du serveur d'application, permettant alors la mise en oeuvre de l'étape d'enregistrement du second identifiant public. 10 15 20 25 30 Selon une autre particularité, l'étape de traitement de la demande de changement d'un premier identifiant public vers un second identifiant public, par les moyens de traitement du HSS, suite à la réception de cette demande comporte une étape d'enregistrement du second identifiant public avec les données qui étaient indexées selon le premier identifiant public, dans la base de données stockant aU moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS. Selon une autre particularité, l'étape de réception de la demande de modification par les moyens de traitement du HSS est précédée d'une étape d'envoi de la demande de changement d'un premier identifiant public vers un second identifiant public-par au moins un système d'information recueillant les données relatives aux utilisateurs de l'architecture IMS et à leurs souscriptions de services. Selon une autre particularité, des étapes d'échanges entre les moyens de traitement du HSS et du serveur d'application permettent d'établir un abonnement de notifications pour la mise à jour automatique des données de la base de données du serveur d'application lors de changements des données de la base de données du HSS, le procédé comportant, suite à la modification de l'identifiant public, au moins une des étapes suivantes : requête, par les moyens de traitement du serveur d'application, auprès du HSS, d'un nouvel abonnement de notification pour le second identifiant public suite à l'enregistrement de la modification lorsque le HSS ne conserve pas l'abonnement dans la base de données stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS, et création de ce nouvel abonnement par les moyens de traitement du HSS ou - modification, par les moyens de traitement du HSS, de l'identifiant public correspondant à l'abonnement dans les données de la base de données stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs ou création d'un nouvel abonnement pour le second identifiant i0 public, à partir de l'abonnement du premier identifiant public, lorsque le HSS conserve l'abonnement dans la base de données stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS. Un autre but de la présente invention est de supprimer au moins un des inconvénients de l'art antérieur en proposant un HSS pour l'autoprovisionnement d'au moins un service dans au moins un serveur d'application d'au moins- une architecture IMS permettant, sans nécessiter io d'interface spécifique de provisionnement, de provisionner les données d'au moins une base de données du serveur d'application par modification d'au moins un identifiant public d'au moins un utilisateur, tout en conservant les données de l'utilisateur stockées dans la base de données du serveur d'application de l'architecture IMS. 15 Ce but est atteint par un serveur d'authentification d'utilisateurs, dit HSS, pour l'autoprovisionnement d'au moins un service dans au moins un serveur d'application d'au moins une architecture IMS, l'architecture IMS comprenant au moins un HSS comportant des moyens de traitement accédant à au moins une base de données stockant au moins des données 20 relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS, ces données étant indexées selon au moins un identifiant public, dit IMPU, des utilisateurs, et au moins un serveur d'application comportant des moyens de traitement agencés pour fournir au moins un service aux utilisateurs et accéder à au moins une base de 25 données stockant au moins des données relatives aux utilisateurs autorisés à accéder audit service, indexées selon au moins un identifiant public des utilisateurs, le HSS et le serveur d'application communiquant via des notifications normalisées selon un protocole standard, caractérisé en ce que les moyens de traitement du HSS sont agencés en outre pour, d'une part, 30 recevoir et traiter une demande de changement d'un premier identifiant public vers un second identifiant public, pour un utilisateur provisionné dans la base de données du HSS et autoprovisionné dans la base de données du serveur d'application, et pour, d'autre part, inclure, dans une notification envoyée au serveur d'application, des données représentatives de la modification de l'identifiant public. Un autre but de la présente invention est de supprimer au moins un des inconvénients de l'art antérieur en proposant un serveur d'application pour l'autoprovisionnement d'au moins un service dans un serveur d'application d'au moins une architecture IMS permettant, sans nécessiter d'interface spécifique de provisionnement, de provisionner les données d'au moins une base de données du serveur d'application par modification d'au moins un identifiant public d'au moins un utilisateur, tout en conservant les données de l'utilisateur stockées dans la base de données du serveur d'application de l'architecture IMS. Ce but est atteint par un serveur d'application pour l'autoprovisionnement d'au moins un service dans au moins un serveur d'application d'au moins une architecture IMS, l'architecture IMS comprenant au moins un serveur d'authentification d'utilisateurs, dit HSS, comportant des moyens de traitement accédant à au moins une base de données stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS, ces données étant indexées selon au moins un identifiant public, dit IMPU, des utilisateurs, et au moins un serveur d'application comportant des moyens de traitement agencés pour fournir au moins un service aux utilisateurs et accéder à au moins une base de données stockant au moins des données relatives aux utilisateurs autorisés à accéder audit service, indexées selon au moins un identifiant public des utilisateurs, le HSS et le serveur d'application communiquant via des notifications normalisées selon un protocole standard, caractérisé en ce que les moyens de traitement du serveur d'application sont agencés en outre pour enregistrer dans la base de données des utilisateurs autorisés à accéder au service, en réponse à une notification contenant des données représentatives d'une modification d'un premier identifiant public vers un second identifiant public, pour un utilisateur provisionné dans la base de données du HSS et autoprovisionné dans la base de données du serveur d'application, le second identifiant public avec les données qui étaient indexées selon le premier identifiant public. D'autres particularités et avantages de la présente invention apparaîtront plus clairement à la lecture de la description ci-après, faite en référence aux dessins annexés, dans lesquels la figure 1 représente un système d'autoprovisionnement selon un mode de réalisation de l'invention, la figure 2 représente un procédé d'autoprovisionnement selon un mode de réalisation de l'invention. La présente invention concerne un système et un procédé d'autoprovisionnement d'au moins un service dans au moins un serveur d'application d'au moins une architecture IMS. L'architecture IMS comprend, de façon connue en soi, au moins un serveur (1) d'authentification d'utilisateurs, dit HSS, et au moins un serveur (2) d'application et les communications et/ou la fourniture des services se font via au moins un réseau (RC) de communication. De façon connue en soi, ce réseau (RC) de communication peut comporter en fait plusieurs réseaux de types différents, tels que par exemple, un réseau de téléphonie mobile, un réseau de type Internet, un réseau de `téléphonie fixe, etc.. Le HSS (1) comporte des moyens (10) de traitement accédant à au moins une base de données (11) stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS. Le serveur (2) d'application comporte des moyens (20) de traitement agencés pour fournir au moins un service aux utilisateurs et pour accéder à au moins une base de données (21) stockant au moins des données relatives aux utilisateurs autorisés à accéder audit service, indexées selon au moins un identifiant public des utilisateurs. Les utilisateurs peuvent utiliser en fait plusieurs identifiants publics. De plus, on notera ici que l'invention peut également être appliquée pour d'autres types d'identifiants des utilisateurs (ou de leur terminal) ou de groupes d'utilisateurs. Ainsi, par exemple, l'invention est également généralisable aux "IMS Public Identity Group" et "IMS Public Service Identity", connus dans le standard IMS. Le HSS (� Home Subscriber Server �, selon la terminologie anglo-saxonne) appartient au coeur du réseau de communication supportant les divers services proposés au sein de l'architecture et permet de centraliser les données relatives aux utilisateurs et aux services auxquels ces derniers souscrivent. Le serveur d'application (ou � Application Server � selon la terminologie anglo-saxonne) est, de façon connue en soi, au moins un serveur destiné à délivrer au moins un service, par exemple de type téléphonie ou multimédia. Le HSS (1) et le serveur (2) d'application communiquant entre autres via des notifications (� Sh notification � selon la terminologie anglaise) normalisées selon un protocole standard (le protocole � Diameter � de l'interface Sh). Il doit être évident que le terme de serveur utilisé ici doit être interprété comme désignant au moins un serveur et qu'il importe peu qu'il s'agisse d'un seul serveur ou de plusieurs serveurs distribués au sein de l'architecture, l'essentiel étant que les fonctions décrites ici soient supportées par au moins un des équipements des réseaux de communication dans lesquels sont implémentées les fonctionnalités de l'architecture IMS. De même, le terme � serveur � peut s'entendre comme désignant tout dispositif muni de ressources de calcul pour le traitement de données (qu'il s'agisse par exemple d'un serveur ou simplement d'un ordinateur ou d'un équipement plus complexe). De plus, le terme � moyens de traitement � est utilisé ici pour désigner tout type d'agencement permettant de traiter des données numériques (ou même analogiques) et ce terme ne doit pas être interprété de façon limitative car il peut désigner au moins un microprocesseur ou au moins un circuit électronique utilisé pour supporter les fonctions décrites ici ou même une combinaison d'au moins un microprocesseur et d'au moins un circuit électronique. En particulier, lorsque l'on réfère ici à des moyens de traitement agencés pour réaliser une fonction décrite, il doit être évident pour l'homme de métier que l'agencement des moyens de traitement peut consister par exemple en l'exécution d'une application logicielle sur au moins un microprocesseur et/ou en au moins un circuit électronique spécifique. De plus, il doit également être évident que les dispositifs (serveurs en particulier), les moyens de traitement, les modules ou les agencements décrits ici peuvent en fait être distribués sur plusieurs dispositifs équipés de s ressources de calcul pour le traitement de données et qu'il ne doit pas être considéré que les termes utilisés ici ne désignent forcément qu'un seul dispositif, moyen, module ou agencement. Les différents modules décrits ici sont définis de manière fônctionnelle selon le type d'opération qu'ils réalisent et il doit être évident que ces modules peuvent en fait être combinés 10 ensemble dans un seul module implémenté dans les moyens de traitement d'un ou plusieurs serveurs ou distribués en modules différents sur plusieurs moyens de traitement d'un ou plusieurs serveurs et que l'invention permet diverses combinaison des moyens modules et agencement décrits ici. Les définitions fonctionnelles données ici ne doivent donc pas être limitées aux 15 modules, moyens de traitement ou agencement puisqu'il sera évident pour l'homme de métier que ces fonctionnalités peuvent être implémentées de diverses manières sans s'éloigner de l'esprit de l'invention. De même, lorsque l'on réfère ici au HSS (1) ou au serveur (2) d'application, il apparaîtra à l'homme de métier qu'un HSS peut être agencé comme décrit ici pour 20 provisionner plusieurs serveurs d'application ou même qu'un HSS peut être agencé comme décrit ici pour provisionner un autre HSS et/ou un autre serveur d'application ou qu'un serveur d'application peut être agencé comme décrit ici pour permettre le provisionnement d'un autre serveur d'application qui ne serait pas agencé comme décrit ici. Ainsi, les fonctionnalités décrites 25 ici peuvent être distribuées sur divers dispositifs (des HSS, des serveurs d'application ou même tout type de terminal) et être supportées grâce à des communications entre les dispositifs adéquats via au moins un réseau (RC) de communication. Enfin, il est évident que les bases de données décrites ici et auxquelles accèdent les serveurs, pour la mise en oeuvre des services en 30 général et de l'invention en particulier, peuvent être dans le serveur lui-même ou à distance, c'est-à-dire accessibles via au moins un réseau (RC) de communication et que ces bases de données peuvent être distribuées sur un seul ou plusieurs dispositifs de stockage de données. De plus, le terme � enregistrement � utilisé ici pour le stockage des données au niveau des serveurs désigne en général une sauvegarde de données dans les bases de données accessibles aux serveurs, et non pas l'attachement au réseau s (connu sous le nom de � register � dans la terminologie anglo-saxonne appliquée à l'IMS). Ce type de rattachement au réseau ou d'étapes standard du fonctionnement de l'IMS ne seront généralement pas détaillés ici et aucun détail ne sera donné ici en ce qui concerne l'organisation de l'architecture IMS. La présente invention est en effet destinée à être mise en oeuvre au io moins dans une architecture IMS définie selon la norme ou dans une architecture équivalente .(avec par exemple les variantes possibles décrites précédemment en référence à l'organisation et la distribution des dispositifs, moyens, modules, agencements, bases de données, etc.), notamment avec les définitions (TS 29.328 et TS 29.329) du protocole � Diameter � régissant 15 l'interface, dite Sh, entre le HSS et le serveur d'application. En effet, ce sont les définitions données dans cette norme qui font naître le problème que la présente invention se propose de résoudre, à savoir l'autoprovisionnement pour la modification de l'identifiant public d'un utilisateur (par exemple un souscripteur, un abonné ou un détenteur d'une carte prépayée) avec 20 conservation des données stockées dans les bases de données du HSS et du serveur d'application, relatives à l'utilisateur, ses préférences, ses messages ou toute information utile pour l'utilisation des services proposés par le(s) serveur(s) d'application(s) au sein de l'architecture IMS. Ainsi, on comprend que le terme � provisionnement � utilisé ici est issu de la 25 terminologie anglo-saxonne et désigne le fait de conserver dans les bases de données de divers serveurs, les informations utiles aux utilisateurs du système. Le terme �autoprovisionnement �, issu également de la terminologie anglo-saxonne désigne le fait que le réseau IMS permet de provisionner automatiquement un utilisateur dans la base de données d'un 30 serveur d'application sans interface spécifique entre le système d'information et ce serveur d'application. Pour rappel, les étapes préalables à la mise en oeuvre de l'invention sont détaillées ci-après pour expliquer la création des comptes des utilisateurs dans les bases (11, 21) de données du HSS (1) et du serveur d'application par une méthode d'autoprovisionnement, sans interface directe entre le système d'information et le serveur d'application. Par exemple, un système (3) d'information permet de recueillir les informations relatives aux utilisateurs, aux services souscrits et tout type de données utiles. Ce système (3) d'information transmet ces informations au HSS (1) qui les stocke (au moins en partie) dans sa base de données, de façon à contrôler l'accès des différents utilisateurs aux divers services. Lorsqu'un utilisateur utilise un terminal communicant pour accéder à l'un des services auquel il a souscrit, le coeur de réseau identifie son terminal (son équipement ou � User equipement �) et sa souscription grâce à l'IMPI du terminal qui est alors authentifié et enregistré, ce qui permet à l'utilisateur de se rattacher au réseau (� Register �). Cette authentification permet d'autoriser (ou refuser, le cas échéant, selon les services souscrits) l'accès de l'utilisateur au service qu'il requiert. Au premier usage du service par un IMPU, lorsque le serveur d'application reçoit une requête d'utilisation d'un service par l'IMPU (identifiant public) de l'utilisateur, le serveur d'application sait que l'utilisateur a été identifié et autorisé par le coeur de réseau. Dans des variantes légèrement en marge de l'IMS, le serveur d'application peut également consulter le HSS pour vérifier que cet IMPU est autorisé à utiliser le service, le HSS répondant alors en fournissant, via des notifications de l'interface Sh, les autorisations enregistrées. S'il souhaite conserver un compte persistant pour cet utilisateur, le serveur d'application peut créer alors un compte pour l'IMPU de l'utilisateur autorisé et fournit le service requis. Le serveur d'application peut alors requérir auprès du HSS un abonnement de notification pour être mis à jour lors de tout changement des données relatives à cet IMPU. Ensuite, lorsque l'utilisateur veut modifier un des services ou supprimer son profil, le système d'information (3) envoie une demande de modification ou de suppression au HSS (1) qui l'enregistre et envoie une notification Sh au serveur d'application qui modifie ou supprime le compte associé à l'IMPU. Dans le cadre de l'invention, ces étapes préalables permettent la mise en oeuvre de l'invention qui utilise sensiblement les mêmes éléments du système mais les adapte pour permettre la modification de l'identifiant public (IMPU) d'un utilisateur tout en conservant ses données dans le HSS et le serveur d'application. Dans les bases de données (11, 21) du HSS (1) et du serveur (2) d'application, les données sont indexées selon au moins un identifiant public, dit IMPU (� IP Multimedia Public Identity � selon la terminologie anglo-saxonne), des utilisateurs. Un identifiant public (ou IMPU), peut correspondre io à un numéro de téléphone mobile (MSISDN, pour � Mobile Station Integrated Services Digital Network � selon la terminologie anglo-saxonne) ou une adresse de courrier électronique (adresse mail) ou tout type d'URI (� Universal Resources Identifier � selon la terminologie anglo-saxonne). Un utilisateur peut vouloir changer d'identifiant public, par exemple lorsqu'il est 15 harcelé sur cet identifiant ou subit de nombreux envois de publicités (� spams � sur l'adresse mail) ou simplement parce que telle est sa volonté. Les normes définissant les standards adoptés pour l'architecture IMS ne prévoient pas d'autoprovisionnement du serveur d'application pour une telle modification de l'identifiant public. Les données des utilisateurs étant 20 stockées en relation avec cet identifiant public qui sert d'index pour les bases de données, il n'est pas permis, dans l'état actuel de la norme, de modifier l'identifiant public tout en conservant les données de l'utilisateur dans le serveur d'application, ni-dans le HSS. Le protocole utilisé pour l'interface (interface Sh) entre le HSS et le serveur d'application permet de créer un 25 nouvel ensemble de données indexées selon un nouvel identifiant public mais ne permet pas de simplement renommer cet identifiant. Ainsi, la présente invention permet de résoudre ce problème nouveau dû à l'architecture IMS et à l'interface Sh entre le HSS et le serveur d'application. Pour cela, l'invention propose que les moyens (10) de traitement du 30 HSS (1) soient agencés en outre pour, d'une part, recevoir et traiter une demande de changement d'un premier identifiant public (IMPU1) vers un second identifiant public- (IMPU2), pour un utilisateur provisionné dans le HSS (1) et autoprovisionné dans le serveur (2) d'application (c'est-à-dire enregistré auprès d'au moins une de ces 2 entités). Par exemple, ces moyens (10) de traitement du HSS (1) pourront comporter un module (101) d'autoprovisionnement, comme représenté sur la figure 1, réalisant les fonctions décrites ici pour la modification de l'identifiant public. D'autre part, les moyens (10) de traitement du HSS (1) sont également agencés (en outre) pour inclure, dans une notification envoyée au serveur (2) d'application, des données représentatives de la modification de l'identifiant public et pour envoyer cette notification au serveur (2) d'application. Ainsi, par exemple, le module (101) d'autoproyisionnement du HSS (1) pourra comporter des moyens de réception et de traitement de la demande de modification, des moyens de création de la notification et des moyens de transmission de la notification au serveur (2) d'application. En réponse à cette notification, les moyens (20) de traitement du serveur (2) d'application sont agencés en outre pour recevoir la notification et enregistrer dans sa base (21) de données (base de données des utilisateurs du service), le second identifiant public (IMPU2) avec les données qui étaient indexées selon le premier identifiant public (IMPU1). Ainsi, par exemple, les moyens (20) de traitement du serveur (2) d'application pourront comporter un module (201) d'autoprovisionnement, comme représenté sur la figure 1, coopérant avec le module (101) d'autoprovisionnement du HSS (1). Ce module (201) d'autoprovisionnement pourra comporter des moyens de réception et de traitement des notifications reçues du HSS (1) pour réaliser les opérations requises notamment pour la modification de l'identifiant public. Le terme � module � est utilisé ici pour désigner au moins un élément intégrable au sein de l'architecture IMS et il doit être évident pour l'homme de métier qu'un tel module pourra être implémenté de diverses façons, par exemple sous la forme d'une application logicielle implémentée directement dans les applications de gestion des serveurs ou selon n'importe quel agencement. Ce terme est utilisé pour décrire des fonctionnalités de la présente invention et ne doit pas être interprété de façon limitative. Le procédé d'autoprovisionnement selon l'invention, mis en oeuvre par un système d'autoprovisionnement selon l'invention, comporte les étapes suivantes (cf. Figure 2): réception (51) et traitement (52), par les moyens (10) de traitement du HSS (1), d'une demande de changement d'un premier identifiant public (IMPU1) vers un second identifiant public (IMPU2), pour un utilisateur provisionné dans la base de données du HSS (1) et autoprovisionné dans la base de données du serveur (2) d'application (enregistré auprès du HSS (1) et du serveur (2) d'application), inclusion (53), par les moyens (10) de traitement du HSS (1), dans une notification envoyée au serveur (2) d'application, des données représentatives de la modification de l'identifiant public, enregistrement (54), par les moyens (20) de traitement du serveur d'àpplication, dans la base (21) de données des utilisateurs autorisés à accéder au service, en réponse à cette notification, du second identifiant public (IMPU2) avec les données qui étaient indexées selon le premier identifiant public (IMPU1). 20 Ainsi, en cas de changement d'identifiant public par un utilisateur, une demande de modification est envoyée au coeur de réseau supportant l'architecture IMS. Par exemple, un système (3) d'information permet de recueillir les modifications requises par les utilisateurs et de les transmettre aux serveurs (1, 2) de l'architecture IMS pour traitement, comme représenté 25 sur la figure 1. Dans un mode de réalisation du système, les moyens (10) de traitement du HSS (1) sont donc agencés pour recevoir et traiter la demande de changement d'un premier identifiant public (IMPU1) vers un second identifiant public (IMPU2), en provenance d'au moins un système d'information (3) recueillant les données relatives aux utilisateurs de 30 l'architecture IMS et à leurs souscriptions de services. Dans un mode de réalisation, le procédé selon l'invention pourra démarrer par une étape 10 15 d'envoi (50) de la demande de changement d'un premier identifiant public (IMPU1) vers un second identifiant public (IMPU2) par au moins un système d'information (3) recueillant les données relatives aux utilisateurs de l'architecture IMS et à leurs souscriptions de services. Les systèmes (3) d'information sont en général en dehors de l'architecture IMS, comme représenté par les pointillés référencés (IMS) sur la figure 1, et sont développés de façon propriétaire. Ainsi, le système (3) d'information pourra, lorsqu'un utilisateur l'aura requis, être agencé pour émettre vers le HSS une demande de modification de l'identifiant public sous diverses formes (par io exemple une commande � renommer � ou � Rename � selon la terminologie anglo-saxonne). Les normes de l'IMS ne définissent pas les commandes de � provisioning �. Les moyens (10) de traitement du HSS (1) devront donc être agencés spécifiquement pour pouvoir répondre à ce type de commande. Ainsi, les moyens (10) de traitement du HSS (1) sont également agencés 15 pour traiter cette demande en enregistrant le second identifiant public (IMPU2) avec les données qui étaient indexées selon le premier identifiant public (IMPU1), dans la base (11) de données stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS. Suite à l'étape d'envoi (50) de la demande 20 par le système d'information (3) vers le HSS (1), le procédé se poursuit par une étape de réception (51) et de traitement (52) de cette demande. Cette étape de traitement (52) de la demande de changement d'un premier identifiant public (IMPU1) vers un second identifiant public (IMPU2), par les moyens (10) de traitement du HSS (1), pourra comporter une étape 25 d'enregistrement (521) du second identifiant public (IMPU2) avec les données qui étaient indexées selon le premier identifiant public (IMPU1), dans la base (11) de données stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS. Ainsi, le HSS permet d'enregistrer la modification 30 d'identifiant public tout en conservant les données qui étaient indexées selon l'identifiant public précédemment utilisé par l'utilisateur. Pour faciliter l'implémentation de cette fonction, le HSS (1) pourra intégrer une fonction � renommer � ou � rename � permettant cet enregistrement, par exemple grâce au module (101) d'autoprovisionnement. Les normes IMS pourront naturellement intégrer cette fonction à l'avenir. D'autre part, la présente invention prévoit divers modes de réalisation pour la notification de la modification d'identifiant public. Dans un mode de réalisation, les moyens (10) de traitement du HSS (1) sont agencés pour inclure (ou insérer) les données de modification au niveau d'au moins un champ standard laissé libre dans la notification selon le protocole standard. Dans ce mode de réalisation, l'interface Sh standard entre le HSS (1) et le serveur (2) d'application n'a pas à être modifiée. En effet, la norme décrit des champs standard laissés.libres, appelés � transparent data � pour permettre aux opérateurs d'annexer des données aux profils de service (qui seront transmises dans les notifications standard). L'invention propose d'utiliser ce champ libre pour y incorporer une commande de modification d'identifiant public, telle que par exemple une commande renommer (rename impul impu2). Le HSS est donc agencé pour générer une telle commande dans la "transparent data" qui sera incluse dans une notification envoyée au serveur (2) d'application qui est agencé pour extraire cette commande de la notification et garder l'information correspondante en mémoire. Ainsi, le HSS (1) envoie cette notification au serveur (2) d'application qui est alors averti qu'une modification d'identifiant public est en cours et que les données indexées selon cet identifiant devront être enregistrées sous un autre identifiant. Dans cet exemple, les moyens (20) de traitement du serveur (2) d'application sont donc agencés pour recevoir cette notification et enregistrer temporairement les données de modification incluses dans la notification en attendant la suppression du premier identifiant. Ensuite, le HSS (1) demande la suppression du premier identifiant public. Les moyens (10) de traitement du HSS (1) sont alors agencés pour envoyer au serveur (2) d'application une notification de suppression des données relatives au premier identifiant public (JMPU1). Les moyens (20) de traitement du serveur (2) d'application sont alors agencés pour recevoir la notification de suppression et pour enregistrer le second identifiant public (IMPU2) avec les données qui étaient indexées selon le premier identifiant public (IMPU1), lors de la réception de la notification de suppression des données relatives au premier identifiant public (IMPU1), puis pour supprimer le premier identifiant public et les données qui y sont assc5ciées. D'après ce mode de réalisation du système d'autoprovisionnement, l'invention prévoit un mode de réalisation du procédé dans lequel l'étape d'inclusion (53) des données représentatives de la modification de l'identifiant public dans la notification est adaptée à ces notifications standard dans l'interface Sh. Ainsi, cette étape d'inclusion (53) io comporte alors une étape d'insertion (531), par les moyens (10) de traitement du HSS (1), de ces données au niveau d'au moins un champ standard laissé libre dans le profil de service. Selon le protocole standard, ce changement du profil entraîne l'envoi de la notification au serveur (2) d'application. Ainsi, en utilisant le protocole standard, la demande de 15 modification est transmise au serveur (2) d'application. Dans le cas où le HSS ne transmettrait pas la notification automatiquement, par exemple à cause du fait que la seule modification incluse dans la notification soit celle définie dans le champ libre et que le HSS est agencé pour ne pas transmettre la notification si elle ne contient pas de modification standard, le 20 HSS pourra être agencé spécifiquement pour envoyer cette notification au serveur (2) d'application. Ensuite, une étape de réception de la notification et d'enregistrement (532) temporaire, par les moyens (20) de traitement du serveur (2) d'application, des données de modification incluses dans la notification, permet de sauvegarder le contexte de changement d'IMPU défini 25 par la demande de modification, en attendant la suppression du premier identifiant. Une fois que les moyens (10) de traitement du HSS (1) ont effectué la modification dans la base (11) de données du HSS (1) et transmis cette notification, ils mettent en oeuvre une étape de création et envoi (533) d'une notification de suppression des données relatives au premier identifiant 30 public (IMPUI) vers le serveur (2) d'application. Ensuite, une étape de réception (534), par lès moyens (20) de traitement du serveur (2) d'application, de la notification de suppression des données relatives au premier identifiant public (IMPU1), permet alors la mise en oeuvre de l'étape d'enregistrement (54) du second identifiant public (IMPU2), tout en rattachant les données de service de l'ex-identifiant public (IMPU1) au nouvel identifiant public (IMPU2) (grâce àu contexte de changement d'IMPU défini par la demande de modification), et une étape de suppression du premier identifiant public (IMPU1) dans le serveur d'application. Dans un autre mode de réalisation, l'invention propose d'améliorer la norme en y ajoutant une notification spécifique de la modification d'identifiant public. Par exemple une notification du type � renommer � ou � rename � io pourra être prévue dans la norme définissant l'interface Sh. Ainsi, une notification du type "Rename IMPUI to IMPU2" pourra être intégrée dans le système et le HSS (1) enverra ce type de notification au serveur d'application lorsqu'une modification d'identifiant public sera requise, en y incluant les données représentatives-de la modification. Dans ce mode de réalisation, les 15 moyens (10) de traitement du HSS (1) sont agencés pour générer une notification spécifique de la modification d'un premier identifiant public (IMPU1), vers un second identifiant public (IMPU2) et incorporer (inclure) dans cette notification spécifique les données représentatives de la modification. Cette notification spécifique pourra faire l'objet d'une 20 standardisation (pour entrer par exemple dans la norme 3GPP). Elle pourra éventuellement être normalisée ou standardisée dans le protocole standard (interface Sh), de façon à ce que la norme IMS permette un autoprovisionnement complet selon la présente invention. Dans ce mode de réalisation, les moyens (20) de traitement du serveur (2) d'application sont 25 agencés pour enregistrer le second identifiant public (IMPU2) avec les données qui étaient indexées selon le premier identifiant public (IMPU1), lors de la réception de cette notification spécifique. De même, dans un mode de réalisation du procédé, l'étape d'inclusion (53) des données représentatives de la modification de l'identifiant public dans la notification sera adaptée à ce 30 nouveau type de notification standardisée. Cette étape d'inclusion comporte alors une étape de création (535), par les moyens (10) de traitement du HSS (1), d'une notification spécifique de modification d'un premier identifiant public (IMPU1), vers un second identifiant public (IMPU2). Ensuite, les moyens (10) de traitement du HSS (1) mettent en oeuvre une étape d'incorporation (536), dans cette notification spécifique, des données représentatives de la modification, puis une étape d'envoi de cette notification spécifique. Enfin, une étape de réception (537) de cette notification spécifique pèr les moyens (20) de traitement du serveur (2) d'application, permet alors la mise en oeuvre de l'étape d'enregistrement (54) du second identifiant public (IMPU2). lo D'autre part, il est prévu dans la norme que les moyens de traitement (10, 20) du HSS (1) et du serveur (2) d'application soient agencés pour établir un abonnement de notifications pour la mise à jour automatique des données de la base de données (21) du serveur (2) d'application lors de changements des données de la base de données (11) du HSS (1). Selon le 15 cas, le HSS (1) pourra être agencé pour conserver dans sa base (11) de données l'information définissant l'existence d'un abonnement de notification du serveur (2) d'application, pour que ce dernier reçoive une mise à jour lors de changements des données de l'utilisateur dans la base (11) de données du HSS (1). Par exemple, le HSS (1) pourra être configuré pour enregistrer 20 cette information (initialement en relation avec le premier identifiant public) en relation avec le second identifiant public. Si le HSS (1) n'est pas agencé pour conserver cette information, l'invention prévoit que l'abonnement qui était établi pour le premier identifiant (IMPUI) soit renouvelé pour le second identifiant (IMPU2). Dans un mode de réalisation, lorsque le HSS ne 25 conserve pas l'abonnement dans sa base (11) de données stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS, suite à la modification, les moyens (20) de traitement du serveur (2) d'application sont donc agencés pour requérir, auprès du HSS (1), un nouvel abonnement de notification pour le 30 second identifiant public (IMPU2) suite à l'enregistrement de la modification. De façon connue en soi, le HSS (1) est alors agencé pour créer ce nouvel abonnement suite à la réception de cette requête d'abonnement pour le second identifiant (IMPU2). Lorsque le HSS (1) conserve l'abonnement suite à la modification, les moyens (10) de traitement du HSS (1) sont donc agencés pour modifier l'identifiant public correspondant à l'abonnement dans les données de sa base (11) de données d'autorisation de l'accès d'utilisateurs. Ainsi, le procédé peut comporter des étapes d'échanges (par exemple des échanges de notifications, ou simplement une requête depuis le serveur d 'application vers le HSS ou même une notification d'abonnement directement depuis le HSS vers le serveur d'application) entre les moyens de ro traitement (10, 20) du HSS (1) et du serveur (2) d'application permettant d'établir un abonnement de notifications pour la mise à jour automatique des données de la base de données (21) du serveur (2) d'application lors de changements des données de la base de données (11) du HSS (1). Dans un mode de réalisation, lorsque le HSS ne conserve pas l'abonnement dans la 15 base (11) de données stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS, le procédé comporte, suite à la modification de l'identifiant public, une étape de requête (55), par les moyens (20) de traitement du serveur (2) d'application, par exemple grâce au module (201) 20 d'autoprovisionnement, auprès du HSS (1), d'un nouvel abonnement de notification pour le second identifiant public (IMPU2) suite à l'enregistrement de la modification. Le HSS (1) met alors en oeuvre une étape de création de ce nouvel abonnement. Lorsque le HSS (1) conserve l'abonnement dans sa base (11) de données stockant au moins des données relatives à 25 l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS, le procédé comporte une étape de modification (56), par les moyens (10) de traitement du HSS (1), par exemple grâce au module (101) d'autoprovisionnement, de l'identifiant public correspondant à l'abonnement dans les données de la base (11) de données d'autorisation de 30 l'accès d'utilisateurs. Ainsi, selon ces diverses possibilités, toutes les données utiles pour la fourniture des services supportés par l'architecture IMS peuvent être conservées pour chacun des utilisateurs, même lors d'un changement de leur identifiant public. On comprend dont que l'invention a atteint le but qu'elle s'était fixée de permettre l'autoprovisionnement en cas de changement d'identifiant public d'un utilisateur sans perdre les données de l'utilisateur. De même, on comprend à la lecture de la présente description que l'invention pourra consister en une amélioration de la norme existante par l'ajout d'une notification spécifique de ces changements d'IMPU ou par l'utilisation des notifications actuellement définies dans la norme par l'ajout dans ces io notifications, de données relatives a ces changements d'IMPU. L'invention porte donc également sur un serveur (1) d'authentification d'utilisateurs, dit HSS, pour l'autoprovisionnement d'au moins un service dans au moins un serveur d'application d'au moins une architecture IMS. Ce HSS pourra être utilisé pour permettre l'autoprovisionnement d'un ou plusieurs serveurs (2) is d'application. Ce HSS est caractérisé en ce que ses moyens (10) de traitement sont agencés en outre pour, d'une part, recevoir et traiter une demande de changement d'un premier identifiant public (IMPU1) vers un second identifiant public (IMPU2), pour un utilisateur provisionné dans le HSS (1) et le serveur (2) d'application, et pour, d'autre part, inclure, dans une 20 notification envoyée au serveur (2) d'application, des données représentatives de la modification de l'identifiant public. De même, l'invention porte également sur un serveur (2) d'application pour l'autoprovisionnement d'au moins un service dans au moins un serveur d'application d'au moins une architecture IMS. Ce serveur d'application pourra être utilisé en 25 conjonction avec un HSS tel que décrit ici (soit qui envoie des notifications spécifiques, soit qui envoie des notifications incluant des données relatives à la modification d'IMPU) ou pour coopérer avec un HSS utilisant une fonction � renommer � tel qu'expliqué précédemment. Ce serveur d'application est caractérisé en ce que ses moyens (20) de traitement sont agencés en outre 30 pour enregistrer dans la base (21) de données des utilisateurs autorisés à accéder au service, en réponse à une notification contenant des données représentatives d'une modification d'un premier identifiant public (IMPU1) vers un second identifiant public (IMPU2), pour un utilisateur provisionné dans la base de données du HSS (1) et autoprovisionné dans la base de données du serveur (2) d'application (enregistré auprès du HSS (1) et du serveur (2) d'application), le second identifiant public (IMPU2) avec les données qui étaient indexées selon le premier identifiant public (IMPU1). II doit être évident pour les personnes versées dans l'art que la présente invention permet des modes de réalisation sous de nombreuses autres formes spécifiques sans l'éloigner du domaine d'application de lo l'invention comme revendiqué. Par conséquent, les présents modes de réalisation doivent être considérés à titre d'illustration, mais peuvent être modifiés dans le domaine défini par la portée des revendications jointes, et l'invention ne doit pas être limitée aux détails donnés ci-dessus. REVENDICATIONS. 1. Système d'autoprovisionnement d'au moins un service dans au moins un serveur d'application d'au moins une architecture IMS, l'architecture IMS comprenant au moins un serveur (1) d'authentification d'utilisateurs, dit HSS, comportant des moyens (10) de traitement accédant à au moins une base de données (Il) stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS, ces données étant indexées selon au moins un io identifiant public, dit IMPU, des utilisateurs, et au moins un serveur (2) d'application comportant des moyens (20) de traitement agencés pour fournir au moins un service aux utilisateurs et accéder à au moins une base de données (21) stockant au moins des données relatives aux utilisateurs autorisés à accéder audit service, indexées selon au moins un identifiant 15 public des utilisateurs, le HSS (1) et le serveur (2) d'application communiquant via des notifications normalisées selon un protocole standard, caractérisé en ce que les moyens (10) de traitement du HSS (1) sont agencés en outre pour, d'une part, recevoir et traiter une demande de changement d'un premier identifiant public (IMPU1) vers un second 20 identifiant public (IMPU2), pour un utilisateur provisionné dans le HSS (1) et autoprovisionné dans le serveur (2) d'application, et pour, d'autre part, inclure, dans une notification envoyée au serveur (2) d'application, des données représentatives de la modification de l'identifiant public, les moyens (20) de traitement du serveur d'application étant agencés en outre pour 25 enregistrer dans la base (21) de données des utilisateurs autorisés à accéder au service, en réponse à cette notification, le second identifiant public (IMPU2) avec les données qui étaient indexées selon le premier identifiant public (IMPU1). 2. Système selon la revendication 1, caractérisé en ce que les moyens 30 (10) de traitement du HSS (1) sont agencés pour inclure les données de modification au niveau d'au moins un champ standard laissé libre dans lanotification selon le protocole standard, et envoyer cette notification, puis pour envoyer au serveur (2) d'application une notification de suppression des données relatives au premier identifiant public (IMPU1), les moyens (20) de traitement du serveur (2) d'application étant agencés pour recevoir cette notification selon le protocole standard, pour enregistrer temporairement les données de modification incluses dans la notification en attendant la suppression du premier identifiant et pour enregistrer le second identifiant public (IMPU2) avec les données qui étaient indexées selon le premier identifiant public (IMPU1), en supprimant le premier identifiant public ro (IMPU1), lors de la réception de la notification de suppression des données relatives au premier identifiant public (IMPU1). 3. Système selon la revendication 1, caractérisé en ce que les moyens (10) de traitement du HSS (1) sont agencés pour générer une notification spécifique de modification d'un premier identifiant public (IMPU1), vers un 15 second identifiant public (IMPU2), et incorporer dans cette notification spécifique les données représentatives de la modification, et envoyer cette notification spécifique au serveur (2) d'application, les moyens (20) de traitement du serveur (2) d'application étant agencés pour enregistrer le second identifiant public (IMPU2) avec les données qui étaient indexées 20 selon le premier identifiant public (IMPU1), lors de la réception de cette notification spécifique. 4. Système selon une des revendications 1 à 3, caractérisé en ce que les moyens (10) de traitement du HSS (1), agencés pour recevoir et traiter la demande de changement d'un premier identifiant public (IMPU1) vers un 25 second identifiant public (IMPU2), sont agencés pour traiter cette demande notamment en enregistrant le second identifiant public (IMPU2) avec les données qui étaient indexées selon le premier identifiant public (IMPU1), dans la base (11) de données stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par 30 l'architecture IMS. 5. Système selon la revendication 4, caractérisé en ce que les moyens (10) de traitement du HSS (1) sont agencés pour recevoir et traiter la demande de changement d'un premier identifiant public (IMPU1) vers un second identifiant public (IMPU2) en provenance d'au moins un système d'information (3) recueillant les données relatives aux utilisateurs de l'architecture IMS et à leurs souscriptions de services. 6. Système selon une des revendications 1 à 5, caractérisé en ce que les moyens de traitement (10, 20) du HSS (1) et du serveur (2) d'application sont agencés pour établir un abonnement de notifications pour la mise à jour ro automatique des données de la base de données (21) du serveur (2) d'application lors de changements des données de la base de données (11) du HSS (1), les moyens (20) de traitement du serveur (2) d'application étant agencés pour requérir, auprès du HSS (1), un nouvel abonnement de notification pour le second identifiant public (IMPU2) suite à l'enregistrement 15 de la modification lorsque le HSS ne conserve pas l'abonnement dans la base (11) de données stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS, suite à la modification, et les moyens (10) de traitement du HSS (1) étant agencés pour créer ce nouvel abonnement lors de la réception 20 de cette requête ou pour modifier l'identifiant public correspondant à l'abonnement dans les données de la base (11) de données stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs lorsque le HSS (1) conserve l'abonnement suite à la modification. 7. Procédé d'autoprovisionnement d'au moins un service dans au 25 moins un serveur d'application d'au moins une architecture IMS, l'architecture IMS comprenant au moins un serveur (1) d'authentification d'utilisateurs, dit HSS, comportant des moyens (10) de traitement accédant à au moins une base de données (11) stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés 30 par l'architecture IMS, ces données étant indexées selon au moins un identifiant public, dit IMPU, des utilisateurs, et au moins un serveur (2)d'application comportant des moyens (20) de traitement agencés pour fournir au moins un service aux utilisateurs et accéder à au moins une base de données (21) stockant au moins des données relatives aux utilisateurs autorisés à accéder audit service, indexées selon au moins un identifiant public des utilisateurs,_ le HSS (1) et le serveur (2) d'application communiquant via des notifications normalisées selon un protocole standard, le procédé étant caractérisé en ce qu'il comporte les étapes suivantes : réception (51) et traitement (52), par les moyens (10) de traitement du HSS (1), d'une demande de changement d'un premier identifiant public (IMPU1) vers un second identifiant public (IMPU2), pour un utilisateur provisionné dans la base de données du HSS (1) et autoprovisionné dans la base de données du serveur (2) d'application, inclusion (53), par les moyens (10) de traitement du HSS (1), dans une notification envoyée au serveur (2) d'application, des données représentatives de la modification de l'identifiant public, enregistrement (54), par les moyens (20) de traitement du serveur d'application, dans la base (21) de données des utilisateurs du service, en réponse à cette notification, du second identifiant public (IMPU2) avec les données qui étaient indexées selon le premier identifiant public (IMPU1). 8. Procédé selon la revendication 7, caractérisé en ce que l'étape d'inclusion (53) des données représentatives de la modification de l'identifiant public dans la notification comporte les étapes suivantes : insertion (531), par les moyens (10) de traitement du HSS (1), de ces données au niveau d'au moins un champ standard laissé libre dans la notification selon le protocole standard, et envoi de la notification, - réception de la notification selon le protocole standard et enregistrement (532) temporaire, par les moyens (20) detraitement du serveur (2) d'application, des données de modification incluses dans la notification, en attendant la suppression du premier identifiant création et envoi (533), par les moyens (10) de traitement du HSS (1), d'une notification de suppression des données relatives au premier identifiant public (IMPU1) vers le serveur (2) d'application, réception (534), par les moyens (20) de traitement du serveur (2) d'applicàtion, de la notification de suppression des données relatives au premier identifiant public (IMPU1), permettant alors la mise en oeuvre de l'étape d'enregistrement (54) du second identifiant public (IMPU2) et une étape de suppression du premier identifiant public (IMPU1). 9. Procédé selon la revendication 7, caractérisé en ce que l'étape 15 d'inclusion (53) des données représentatives de la modification de l'identifiant public dans la notification comporte les étapes suivantes : création (535), par les moyens (10) de traitement du HSS (1), d'une notification spécifique de modification d'un premier identifiant public (IMPU1), vers un second identifiant public 20 (IMPU2), - incorporation (536), dans cette notification spécifique, des données représentatives de la modification, et envoi de la notification, réception (537) de cette notification spécifique par les moyens 25 (20) de traitement du serveur (2) d'application, permettant alors la mise en oeuvre de l'étape d'enregistrement (54) du second identifiant public (IMPU2). 10. Procédé selon une des revendications 7 à 9, caractérisé en ce que l'étape de traitement (52) de la demande de changement d'un premier 30 identifiant public (IMPU1) vers un second identifiant public (IMPU2), par les moyens (10) de traitement du HSS (1), suite à la réception (51) de cette i0 25 30demande, comporte une étape d'enregistrement (521) du second identifiant public (IMPU2) avec leS données qui étaient indexées selon le premier identifiant public (IMPU1), dans la base (11) de données stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS. 11. Procédé selon la revendication 10, caractérisé en ce que l'étape de réception (51) de la demande de modification par les moyens (10) de traitement du HSS (1) est précédée d'une étape d'envoi (50) de la demande de changement d'un premier identifiant public (IMPU1) vers un second io identifiant public (IMPU2) par au moins un système d'information (3) recueillant les données relatives aux utilisateurs de l'architecture IMS et à leurs souscriptions de services. 12. Procédé selon une des revendications 7 à 11, caractérisé en ce que des étapes d'échanges de notifications entre les moyens de traitement (10, 15 20) du HSS (1) et du serveur (2) d'application permettent d'établir un abonnement de notifications pour la mise à jour automatique des données de la base de données (21) du serveur (2) d'application lors de changements des données de la base de données (11) du HSS (1), le procédé comportant, suite à la modification de l'identifiant public, au moins une des étapes 20 suivantes : requête (55), par les moyens (20) de traitement du serveur (2) d'application, auprès du HSS (1), d'un nouvel abonnement de notification pour le second identifiant public (IMPU2) suite à l'enregistrement de la modification lorsque le HSS ne conserve pas l'abonnement dans la base (11) de données stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS, et création de l'abonnement par les moyens (10) de traitement du HSS (1) ou modification (56), par les moyens (10) de traitement du HSS (1), de l'identifiant public correspondant à l'abonnement dansles données de la base (21) de données des utilisateurs autorisés à accéder au service ou création d'un nouvel abonnement pour le second identifiant public, à partir de l'abonnement du premier identifiant public, lorsque le HSS (1) conserve l'abonnement dans la base (11) de données stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS. 13. Serveur (1) d'authentification d'utilisateurs, dit HSS, pour l'autoprovisionnement d'au moins un service dans au moins un serveur ro d'application d'au moins une architecture IMS, l'architecture IMS comprenant au moins un HSS (1) comportant des moyens (10) de traitement accédant à au moins une base de données (11) stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés par l'architecture IMS, ces données étant indexées selon au moins un is identifiant public, dit IMPU, des utilisateurs, et au moins un serveur (2) d'application comportant des moyens (20) de traitement agencés pour fournir au moins un service aux utilisateurs et accéder à au moins une base de données (21) stockant au moins des données relatives aux utilisateurs autorisés à accéder audit service, indexées selon au moins un identifiant 20 public des utilisateurs, le HSS (1) et le serveur (2) d'application communiquant via des notifications normalisées selon un protocole standard, caractérisé en ce que les moyens (10) de traitement du HSS (1) sont agencés en outre pour, d'une part, recevoir et traiter une demande de changement d'un premier identifiant public (IMPU1) vers un second 25 identifiant public (IMPU2), pour un utilisateur provisionné dans la base de données du HSS (1) et autoprovisionné dans la base de données du serveur (2) d'application, et pour, d'autre part, inclure, dans une notification envoyée au serveur (2) d'application, des données représentatives de la modification de l'identifiant public. 30 14. Serveur (2) d'application pour l'autoprovisionnement d'au moins un service dans au moins un serveur d'application d'au moins une architectureIMS, l'architecture IMS comprenant au moins un serveur (1) d'authentification d'utilisateurs, dit HSS, comportant des moyens (10) de traitement accédant à au moins une base de données (11) stockant au moins des données relatives à l'autorisation de l'accès d'utilisateurs à divers services supportés s par l'architecture IMS, ces données étant indexées selon au moins un identifiant public, dit IMPU, des utilisateurs, et au moins un serveur (2) d'application comportant des moyens (20) de traitement agencés pour fournir au moins un service aux utilisateurs et accéder à au moins une base de données (21) stockant au moins des données relatives aux utilisateurs 10 autorisés à accéder audit service, indexées selon au moins un identifiant public des utilisateurs, le HSS (1) et le serveur (2) d'application communiquant via des notifications normalisées selon un protocole standard, caractérisé en ce que les moyens (20) de traitement du serveur d'application sont agencés en outre pour enregistrer dans la base (21) de données des 15 utilisateurs autorisés à accéder au service, en réponse à une notification contenant des données représentatives d'une modification d'un premier identifiant public (IMPU1) vers un second identifiant public (IMPU2), pour un utilisateur provisionné dans la base de données du HSS (1) et autoprovisionné dans la-base de données du serveur (2) d'application, le 20 second identifiant public (IMPU2) avec les données qui étaient indexées selon le premier identifiant public (IMPU1).