Brevet FR2851869A1 — publié le 20040903

i L'invention se situe dans le domaine des télécommunications. Plus précisément, l'invention permet de faciliter l'accès aux multiples données dynamiques (liées à une session d'utilisation) concernant tous types d'utilisateurs de services, données que peuvent être amenés à stocker des 5 fournisseurs de services et que peuvent être amenées à consulter d'autres fournisseurs de services. Par fournisseur de service, on entend aussi bien des fournisseurs de services réseau appelés aussi fournisseurs de ressources que des fournisseurs de services applicatifs. Les fournisseurs de services applicatifs sont appelés ainsi par le fait que ces éléments, 10 physiques ou fonctionnels, mettent en oeuvre un traitement de données qu'ils reçoivent pour fournir des données traitées expressément à destination d'un utilisateur final. Les fournisseurs de ressources (ou fournisseurs de services réseaux) ont, eux, une fonction de support et d'aide à la transmission et au 15 transport des données dans le réseau. Plus précisément, l'invention est connexe à un type de fournisseurs qui vient s'intercaler entre les fournisseurs habituels: ce sont des fournisseurs de services de médiation, ou fournisseurs de services génériques, qui offrent leurs services aux autres fournisseurs de services. Nous assistons actuellement à une diversification des services télécoms offerts aux consommateurs et à une multiplication des fournisseurs de services qui les fournissent. Les fournisseurs de services sont divers et aussi variés que les types de services le sont, allant des services réseaux support comme les services de collecte jusqu'aux services 25 applicatifs comme par exemple la Video on Demand, VoD. On a vu s'installer une séparation entre d'un côté les fournisseurs de service réseau et de l'autre les fournisseurs de services applicatifs accessibles à travers ces réseaux. Chaque fournisseur de service gère des informations sur ses propres 30 clients. Certaines informations ou données sont dites " statiques " et leur valeur est fixée lors de la souscription ou lors de la modification du service, d'autres sont dites " dynamiques " et n'ont de valeur, voire d'existence que lors d'une session d'utilisation du service (p.e. une adresse d'accès au réseau). Parmi ces dernières, certaines informations sont encore plus dynamiques et peuvent changer au cours d'une même session (e.g. la localisation d'un utilisateur). Or, certaines applications nécessitent de prendre en compte des informations qui relèvent parfois de services 5 différents offerts par des fournisseurs de services quelconques et multiples parfois différents de celui fournissant la dite application. On pourra citer la fourniture d'informations de localisation globale des utilisateurs (à travers potentiellement tous les réseaux d'accès de tous les opérateurs) ou la fourniture d'information de présence des utilisateurs 10 (sur potentiellement tous les réseaux d'accès). Pour ces raisons, on voit apparaître depuis peu un nouveau type de fournisseur qui viendrait s'intercaler entre les fournisseurs de services (services réseaux et/ou services applicatifs): ce sont des fournisseurs de services de médiation, ou fournisseurs de services génériques, qui offrent 15 leurs services télécoms. L'invention relève d'un souci de permettre à un fournisseur de services génériques (ou de services de médiation) de récupérer aisément et efficacement des informations dynamiques dont disposent des fournisseurs de services et de notifier les événements correspondants à d'autres 20 fournisseurs de services qui souscriraient à un tel service de médiation multi-domaines multi-fournisseurs. On parle de multi-domaine lorsque les fournisseurs de services concernés par ce service de notification n'appartiennent pas tous au même acteur commercial (par exemple, opérateur téléphonique). La mise en place de ce système apporte une plus25 value supplémentaire au fournisseur de services de médiation. Actuellement, la récupération par une application d'informations utilisateur stockées par d'autres services est proposée selon deux types de systèmes différents. Dans un premier type de système, l'application demandeuse et les 30 services possédant les informations sont offerts par le même fournisseur de services. Dans ce cas, la complexité de conception de l'application se trouve réduite de par la connaissance des différents équipements et interfaces permettant d'obtenir l'information. Dans certains cas, l'application peut même n'avoir à s'interfacer qu'avec un élément centralisateur d'informations pour tous les services du même fournisseur de services. Toutefois, la notification d'information n'est pas toujours supportée de façon directe. Dans un second type de système, l'application demandeuse est supportée par un fournisseur de services et les services possédant les informations utiles sont supportés par d'autres fournisseurs de services inconnus du premier. Dans ce cas, une solution consiste à utiliser les services d'un fournisseur de profil utilisateur, capable de centraliser les 10 informations liées à des services supportés par de multiples fournisseurs. Toutefois, les informations désirées ne sont pas forcément toutes présentes chez le fournisseur de profil et surtout il est nécessaire d'aller " chercher " l'information, il n'y a pas de service de notification associé. Les inconvénients de ces systèmes sont les suivants. Lorsque l'action se limite à ne récupérer des informations que chez un ou plusieurs fournisseurs de services donnés, elle n'a accès qu'aux informations d'un sous-ensemble des services potentiellement accessibles par un utilisateur. Lorsque l'accès aux informations de potentiellement tous les 20 fournisseurs de services est disponible via un unique fournisseur de profil utilisateur, l'application doit retrouver elle-même les informations voulues. Du fait du nombre très important de données en présence, on est contraint typiquement de mettre en oeuvre un système de polling lourd voire inadapté dans certains cas. De manière générale, l'application doit souvent faire face à une complexité de conception qui provient de la distribution des équipements a accéder et de l'hétérogénéité ou de l'absence des interfaces à supporter. L'objectif de cette invention est de permettre la réalisation d'un système de récupération d'informations disponibles chez n'importe quel 30 fournisseur de services pour les notifier à d'autres fournisseurs de services en ayant fait la demande, qui soit efficace et de mise en oeuvre aisée. Ce but est atteint selon l'invention grâce à un organe de médiation entre au moins un fournisseur de service applicatif et une pluralité de fournisseurs de services dans un réseau de télécommunications, cet organe comprenant un moyen de récupération de données concernant des utilisateurs auprès de différents fournisseurs de services, le moyen de récupération étant prévu pour acquérir des indications qualifiant un 5 utilisateur et qualifiant au moins un type de données souhaité sur cet utilisateur, de telles indications étant émises par le fournisseur de service applicatif, organe de médiation caractérisé en ce qu'il comprend un moyen apte à identifier une sélection de fournisseurs de services contenant le type de données souhaité sur l'utilisateur, le moyen de récupération étant en 10 outre prévu pour tenir compte de cette sélection de manière à n'interroger que les fournisseurs de services ainsi sélectionnés. Le résultat obtenu permet à un fournisseur de service de médiation supportant ce système d'offrir un service de notification d'informations globales à des fournisseurs de services applicatifs. Il pourra s'appuyer sur ce système pour offrir aux fournisseurs de services des services génériques simples offrant notamment une couverture complète en termes de fournisseurs de services potentiellement accédés. D'autres caractéristiques, buts et avantages de l'invention 20 apparaîtront à la lecture de la description détaillée qui va suivre, faite en référence aux figures annexées sur lesquelles: - La figure 1 est un diagramme illustrant les éléments d'un mode privilégié de réalisation de l'invention, illustrés dans leur environnement technique; - La figure 2 est un diagramme illustrant les flux échangés, dans le même mode de réalisation de l'invention. Le présent mode de réalisation concerne un serveur de médiation multidomaines multi-fournisseurs pour la notification d'événements à des fournisseurs de services télécoms, qui repose, dans cet exemple, sur un 30 ensemble comprenant un serveur de récupération et de notification 3, associé à une base de données locale 2, un serveur d'informations utilisateur sur les fournisseurs de services de l'utilisateur 4, associé à une base de données également locale 5. Cette base de données 5 inclut, pour chaque utilisateur, une association entre l'utilisateur et l'ensemble des fournisseurs de services disposant d'informations sur cet utilisateur. Ainsi, sur la figure 1, l'élément 1 représente une application (d'un 5 fournisseur de service applicatif) demandeuse d'informations externes, et l'élément 2 est une base de données locale, base de données locale au serveur de récupération et de notification 1. L'élément 3 est un serveur de récupération et de notification chez un fournisseur de services de médiation (on parle ici de rôle et non d'acteur). L'élément 4 est un serveur d'informations utilisateur sur les fournisseurs de services de l'utilisateur. L'élément 5 est une base de données locale, base de données locale au serveur d'informations utilisateur au serveur d'informations utilisateur sur les fournisseurs de services de l'utilisateurs. La base de 15 données 5 est, ici, différente de la base de données 2. L'élément 6 est une entité serveuse d'information, pour un service ou pour un ensemble de services, supportant les notifications ou non. Il est à noter qu'un tel fournisseur de service 6 peut être un fournisseur de service applicatif ou un fournisseur de service réseau 20 (également appelé fournisseur de ressource). La figure 2 représente un exemple d'interactions entre les éléments déterminants de l'invention et les éléments environnants. Dans une étape a) l'application 1 du fournisseur de service applicatif 1 souscrit (on ne décrit pas le mécanisme de souscription ici) auprès du 25 serveur de récupération et de notification 3 à un service de notifications pour un utilisateur donné et des informations données. Elle fournit notamment une identification utilisateur, la description des informations souhaitées, l'identification du fournisseur d'information utilisateur sur les fournisseurs de services de l'utilisateur. La description des informations souhaitées se fait dans un langage de description suffisamment général pour couvrir l'ensemble des types d'informations qu'une application peut souhaiter voir remonter. Le serveur de récupération et de notification n'a pas besoin d'être associé de façon unique à un serveur d'information utilisateur sur ses fournisseurs. Ce dernier doit préférentiellement supporter l'interface recommandée dans le présent mode de réalisation. Dans une étape b), le serveur de récupération et de notification 3 contacte le serveur d'informations utilisateur 4 sur les fournisseurs de services de l'utilisateur pour obtenir la liste des fournisseurs de services 6 à l'utilisateur possédant des informations souhaitées par l'application 1. Cette liste est obtenue à partir de l'association stockée par le serveur 10 d'information utilisateur 4 sur les fournisseurs de services de l'utilisateur association entre l'utilisateur et ses fournisseurs de services. L'aspect autorisation par l'utilisateur d'accès aux informations le concernant n'est pas présent dans ce mode de réalisation ici mais constitue un ajout fonctionnel avantageux parmi les fonctions de l'élément4. Le 15 protocole précis entre les deux serveurs n'est pas décrit en détail. Par exemple, b) constitue une réponse contenant la liste des fournisseurs de services à l'utilisateur correspondant à la requête. Dans cet exemple, on considère que deux fournisseurs de services à l'utilisateur, A et B, contiennent des informations demandées par 20 l'application. Dans une étape c), le serveur de récupération et de notification contacte le fournisseur de services à l'utilisateur A afin de souscrire à la récupération des informations souhaitées. Les informations souhaitées sont décrites dans un langage de description suffisamment général pour couvrir 25 l'ensemble des types d'informations que le serveur peut souhaiter voir remonter. Le protocole précis entre les deux entités n'est pas décrit en détail. Par exemple c) constitue une réponse de souscription réussie. Dans une étape d), les mêmes interactions qu'en c) prennent place dans le dispositif, mais avec le fournisseur de services à l'utilisateur B. Dans une étape e), le serveur de récupération et de notification 4 indique à l'application que la souscription s'est bien passée et qu'elle est opérationnelle. D'autres messages existent pour indiquer un refus de souscription (mauvaise autorisation, information absente,...) Dans une étape f), une information à laquelle a souscrite le serveur de récupération et de notification vient de changer. On suppose que le protocole entre le fournisseur de services à l'utilisateur A et ce dernier supporte les notifications. Le serveur 3 est donc notifié de l'événement. Dans une étape g), le serveur de récupération et de notification 3 notifie l'application 1 du fournisseur de service applicatif avec l'information qui a changé, conformément à la souscription de l'application contenue en 2 qui peut alors initier un traitement adéquat à cet événement. D'autres informations associées à l'information qui a changé peuvent aussi être 10 remontées. Par exemple si l'information notifiée est l'attachement à un réseau, on peut remonter l'identification de l'utilisateur dans ce réseau. Dans une étape h), on suppose que le protocole entre le fournisseur de services à l'utilisateur B et le serveur de récupération et de notification 3 ne supporte pas les notifications. Le serveur 3 va donc régulièrement, dans 15 cet exemple, demander si telle ou telle information a changé. On suppose que h' est une réponse négative à une demande de changement. Dans une étape i), le serveur va régulièrement demander si telle ou telle information a changé. On suppose que cette fois i) est une réponse positive à une demande de changement. Dans une étape j) le serveur de récupération et de notification notifie l'application avec l'information qui a changé, conformément à la souscription de l'application qui peut alors initier un traitement adéquat à cet événement. D'autres informations associées à l'information qui a changé peuvent aussi être remontées. Par exemple, si l'information notifiée est 25 l'attachement à un réseau, on peut remonter l'identification de l'utilisateur dans ce réseau. Le contenu fonctionnel des protocoles n'est pas détaillé dans l'exemple, mais on peut bien sr inclure d'autres fonctions comme l'arrêt de souscription de l'application, la modification de la souscription. Le serveur de récupération et de notification 3 supporte la seule interface avec les applications. Il gère les souscriptions des applications (ainsi que les modifications de souscription, les résiliations des fournisseurs de services applicatifs clients du fournisseur de service de médiation), qu'il stocke dans sa base de données locales 2. La description des informations souhaitées est faite dans un langage de description suffisamment général pour couvrir l'ensemble des types d'information qu'une application peut souhaiter voir remonter. Il notifie les applications 1 lors des événements concernant les informations souscrites. Le serveur 3 supporte une interface avec les serveurs d'informations utilisateur sur les fournisseurs de services à l'utilisateur. Cette interface lui permet notamment de récupérer les fournisseurs de services qui sont susceptibles de posséder les informations correspondantes aux 10 souscriptions des applications, avec la description de ces informations. Elle doit aussi permettre de vérifier les autorisations des applications à remonter les informations utilisateur. Le serveur s'interface avec les fournisseurs de services 6 possédant de l'information relative à un ou des utilisateurs. Il décrit les informations 15 qu'il souhaite dans un langage de description suffisamment général pour couvrir l'ensemble des types d'information. Il supporte divers types de protocoles, certains supportant la remontée de notifications, d'autres non. Lorsque les notifications ne sont pas supportées par un fournisseur de services 6, le serveur de récupération 3 met en oeuvre la procédure qu'il 20 convient pour récupérer les informations de la manière la plus efficace et la plus rapide possible. Le serveur d'informations utilisateur sur les fournisseurs de services 4' supporte une interface avec le serveur de récupération et de notification. Il stocke dans sa base de données locale les associations entre les 25 utilisateurs qu'il gère et les fournisseurs de services 6 susceptibles de contenir des informations sur ces utilisateurs. La ou les diverses manières dont ces associations peuvent être renseignées ne sont pas décrites ici. Il peut également stocker dans sa base de données locale les autorisations d'accès aux informations utilisateur. Une évolution consiste à également stocker les souscriptions du serveur de récupération et de notification 3 dans sa base de données locale 2. Il peut ainsi l'avertir lors d'une modification de la liste des fournisseurs d'informations 6 pour un utilisateur donnée, ou des informations stockées par un fournisseur donné. REVENDICATIONS 1. Organe de médiation (2, 3, 4, 5) entre au moins un fournisseur de 5 service applicatif (1) et une pluralité de fournisseurs de services (6) dans un réseau de télécommunications, cet organe (2, 3, 4, 5) comprenant un moyen de récupération (2, 3) de données concernant des utilisateurs auprès de différents fournisseurs de services (6), le moyen de récupération (2, 3) étant prévu pour acquérir des indications qualifiant un utilisateur et 10 qualifiant au moins un type de données souhaité sur cet utilisateur, de telles indications étant émises par le fournisseur de service applicatif (1), organe de médiation caractérisé en ce qu'il comprend un moyen (4, 5) apte à identifier une sélection de fournisseurs de services (6) contenant le type de données souhaité sur l'utilisateur, le moyen de récupération (2, 3) étant en 15 outre prévu pour tenir compte de cette sélection de manière à n'interroger que les fournisseurs de services (6) ainsi sélectionnés. 2. Organe de médiation (2, 3, 4, 5) selon la revendication 1, caractérisé en ce que le moyen de sélection de fournisseurs de services (4) est prévu pour identifier les fournisseurs de services (6) qui contiennent à la 20 fois le type de données souhaité, et qui à la fois agissent pour le client considéré. 3. Organe de médiation (2, 3, 4, 5) selon l'une quelconque des revendications précédentes, caractérisé en ce que le moyen de récupération (2, 3) est prévu pour effectuer, à sa propre initiative, une 25 notification des données récupérées à l'application (1). 4. Organe de médiation (2, 3, 4, 5) selon l'une quelconque des revendications précédentes, caractérisé en ce que le moyen de sélection de fournisseurs de services (4, 5) inclut notamment une base de données (5) contenant des indications relatives aux associations existant entre 30 différents fournisseurs de services (6) et différents utilisateurs, et contenant également des indications relatives aux types de données traitées par les services de ces différents fournisseurs de services (6). 5. Organe de médiation (2, 3, 4, 5) selon l'une quelconque des revendications précédentes, caractérisé en ce que le moyen de il récupération (2, 3) inclut une base de données de souscriptions (2) qui contient des indications identificatrices d'utilisateurs, associées à des indications descriptives des types de données souhaitées par l'application sur chacun des utilisateurs. 6. Organe de médiation (2, 3, 4, 5) selon l'une quelconque des revendications précédentes, caractérisé en ce que le moyen de récupération (2, 3) est prévu pour acquérir les données auprès d'un fournisseur de service sélectionné (6) en mettant en place un lien de notification entre le fournisseur de service (6) et ce moyen de récupération 10 (2, 3), lien de notification selon lequel le fournisseur de services (6) prend lui-même l'initiative de notifier les données au moyen de récupération de données (2, 3). 7. Organe de médiation (2, 3, 4, 5) selon la revendication précédente, caractérisé en ce que le lien de notification est prévu tel que le 15 fournisseur de services (6) notifie une donnée au moyen de récupération (2, 3) en réponse à une modification de ladite donnée. 8. Organe de médiation (2, 3, 4, 5) selon la revendication 6 ou la revendication 7, caractérisé en ce que le moyen de récupération (2, 3) est prévu pour aviser l'application (1) qu'un lien de récupération de données a 20 été mis en place auprès des fournisseurs de services sélectionnés (6). 9. Organe de médiation (2, 3, 4, 5) selon l'une quelconque des revendications précédentes, caractérisé en ce que le moyen de récupération (2, 3) est prévu pour supporter à la fois un lien de récupération avec un fournisseur de service (6) dans lequel le fournisseur de service (6) 25 prend lui même l'initiative de notifier le moyen de récupération (2,3) avec une donnée, et supporter à la fois un lien de récupération dans lequel le moyen de récupération (2, 3) prend lui-même l'initiative de requérir l'information auprès du fournisseur de service (6). 10. Organe de médiation (2, 3, 4, 5) selon l'une quelconque des 30 revendications précédentes, caractérisé en ce que le moyen de récupération (2, 3) met en oeuvre une gestion de souscriptions à des récupérations de données par applications et inclut des moyens autorisant une modification sur requête des types de données désignés comme souhaitées sur un utilisateur donné.