FR2851869A1 - Organe de mediation multi-domaines multi-fournisseurs pour la notification d'evenements - Google Patents
Organe de mediation multi-domaines multi-fournisseurs pour la notification d'evenements Download PDFInfo
- Publication number
- FR2851869A1 FR2851869A1 FR0302469A FR0302469A FR2851869A1 FR 2851869 A1 FR2851869 A1 FR 2851869A1 FR 0302469 A FR0302469 A FR 0302469A FR 0302469 A FR0302469 A FR 0302469A FR 2851869 A1 FR2851869 A1 FR 2851869A1
- Authority
- FR
- France
- Prior art keywords
- recovery
- data
- service providers
- user
- service provider
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000011084 recovery Methods 0.000 claims abstract description 38
- 230000004044 response Effects 0.000 claims description 5
- 230000004048 modification Effects 0.000 claims 2
- 238000012986 modification Methods 0.000 claims 2
- 238000013475 authorization Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- GNFTZDOKVXKIBK-UHFFFAOYSA-N 3-(2-methoxyethoxy)benzohydrazide Chemical compound COCCOC1=CC=CC(C(=O)NN)=C1 GNFTZDOKVXKIBK-UHFFFAOYSA-N 0.000 description 1
- FGUUSXIOTUKUDN-IBGZPJMESA-N C1(=CC=CC=C1)N1C2=C(NC([C@H](C1)NC=1OC(=NN=1)C1=CC=CC=C1)=O)C=CC=C2 Chemical compound C1(=CC=CC=C1)N1C2=C(NC([C@H](C1)NC=1OC(=NN=1)C1=CC=CC=C1)=O)C=CC=C2 FGUUSXIOTUKUDN-IBGZPJMESA-N 0.000 description 1
- YTAHJIFKAKIKAV-XNMGPUDCSA-N [(1R)-3-morpholin-4-yl-1-phenylpropyl] N-[(3S)-2-oxo-5-phenyl-1,3-dihydro-1,4-benzodiazepin-3-yl]carbamate Chemical compound O=C1[C@H](N=C(C2=C(N1)C=CC=C2)C1=CC=CC=C1)NC(O[C@H](CCN1CCOCC1)C1=CC=CC=C1)=O YTAHJIFKAKIKAV-XNMGPUDCSA-N 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000000034 method Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/30—Profiles
- H04L67/306—User profiles
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/52—Network services specially adapted for the location of the user terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/55—Push-based network services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Organe de médiation (2, 3, 4, 5) entre au moins un fournisseur de service applicatif 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 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 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.
Description
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é.
Claims (10)
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é.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0302469A FR2851869A1 (fr) | 2003-02-28 | 2003-02-28 | Organe de mediation multi-domaines multi-fournisseurs pour la notification d'evenements |
| PCT/FR2004/000434 WO2004080028A1 (fr) | 2003-02-28 | 2004-02-26 | Organe de mediation multi-domaines multi-fournisseurs pour la notification d’evenements |
| EP04714822A EP1604504A1 (fr) | 2003-02-28 | 2004-02-26 | Organe de mediation multi-domaines multi-fournisseurs pour la notification d'evenements |
| US10/547,165 US8135802B2 (en) | 2003-02-28 | 2004-02-26 | Multi-supplier, multi-domain mediating element for event notification |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0302469A FR2851869A1 (fr) | 2003-02-28 | 2003-02-28 | Organe de mediation multi-domaines multi-fournisseurs pour la notification d'evenements |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2851869A1 true FR2851869A1 (fr) | 2004-09-03 |
Family
ID=32843067
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0302469A Pending FR2851869A1 (fr) | 2003-02-28 | 2003-02-28 | Organe de mediation multi-domaines multi-fournisseurs pour la notification d'evenements |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US8135802B2 (fr) |
| EP (1) | EP1604504A1 (fr) |
| FR (1) | FR2851869A1 (fr) |
| WO (1) | WO2004080028A1 (fr) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080046721A1 (en) * | 2006-08-15 | 2008-02-21 | Thomas Zurek | Dynamic multiprovider |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2000004730A1 (fr) * | 1998-07-20 | 2000-01-27 | Signalsoft Corp. | Services fournis a abonne a site fixe |
| WO2003003694A2 (fr) * | 2001-06-26 | 2003-01-09 | Versada Networks, Inc. | Detection et transport de donnees de presence dynamique par un reseau de communication sans fil et avec fil |
| US20030040280A1 (en) * | 2001-08-24 | 2003-02-27 | Petri Koskelainen | Service mobility and recovery in communication networks |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6029171A (en) * | 1997-02-10 | 2000-02-22 | Actioneer, Inc. | Method and apparatus for group action processing between users of a collaboration system |
| US20020007411A1 (en) * | 1998-08-10 | 2002-01-17 | Shvat Shaked | Automatic network user identification |
| US6070083A (en) * | 1998-05-14 | 2000-05-30 | Nortel Networks Corporation | Mobile communication device and communication network for providing location services |
| US6230018B1 (en) * | 1998-05-14 | 2001-05-08 | Nortel Networks Limited | Devices and processing in a mobile radio communication network having calibration terminals |
| GB2338374A (en) * | 1998-06-10 | 1999-12-15 | Motorola Ltd | Locating a mobile telephone using time of arrival measurements |
| US6351757B1 (en) * | 1998-11-13 | 2002-02-26 | Creative Technology Ltd. | Method for conserving memory storage during an interpolation operation |
| EP1252563A4 (fr) * | 1999-12-23 | 2005-12-07 | M H Segan Ltd Partnership | Systeme pour visualiser un contenu a travers un reseau et procede correspondant |
| JP2001338171A (ja) * | 2000-05-29 | 2001-12-07 | Nec Corp | サービス取引仲介システムおよびサービス取引仲介方法並びに記録媒体 |
| JP2002245282A (ja) * | 2001-02-19 | 2002-08-30 | Hitachi Ltd | 情報処理サービス提供方法および情報処理資源の管理方法 |
| US7302634B2 (en) * | 2001-03-14 | 2007-11-27 | Microsoft Corporation | Schema-based services for identity-based data access |
| US20020143664A1 (en) * | 2001-04-03 | 2002-10-03 | Webb Brett M. | Network based gift reminder and purchasing system and method |
| US7529711B2 (en) * | 2001-10-31 | 2009-05-05 | Nortel Networks Limited | Method and system for providing and billing internet services |
| US20040128344A1 (en) * | 2002-12-30 | 2004-07-01 | Nokia Corporation | Content and service registration, query and subscription, and notification in networks |
-
2003
- 2003-02-28 FR FR0302469A patent/FR2851869A1/fr active Pending
-
2004
- 2004-02-26 WO PCT/FR2004/000434 patent/WO2004080028A1/fr not_active Ceased
- 2004-02-26 EP EP04714822A patent/EP1604504A1/fr not_active Withdrawn
- 2004-02-26 US US10/547,165 patent/US8135802B2/en not_active Expired - Fee Related
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2000004730A1 (fr) * | 1998-07-20 | 2000-01-27 | Signalsoft Corp. | Services fournis a abonne a site fixe |
| WO2003003694A2 (fr) * | 2001-06-26 | 2003-01-09 | Versada Networks, Inc. | Detection et transport de donnees de presence dynamique par un reseau de communication sans fil et avec fil |
| US20030040280A1 (en) * | 2001-08-24 | 2003-02-27 | Petri Koskelainen | Service mobility and recovery in communication networks |
Non-Patent Citations (1)
| Title |
|---|
| LING LIU: "Query routing in large-scale digital library systems", DATA ENGINEERING, 1999. PROCEEDINGS., 15TH INTERNATIONAL CONFERENCE ON SYDNEY, NSW, AUSTRALIA 23-26 MARCH 1999, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 23 March 1999 (1999-03-23), pages 154 - 163, XP010326186, ISBN: 0-7695-0071-4 * |
Also Published As
| Publication number | Publication date |
|---|---|
| US20060200544A1 (en) | 2006-09-07 |
| WO2004080028A1 (fr) | 2004-09-16 |
| US8135802B2 (en) | 2012-03-13 |
| EP1604504A1 (fr) | 2005-12-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2004068809A1 (fr) | Procede de presentation d’etat d’un utilisateur utilisant plusieurs equipements de communication | |
| US20110302292A1 (en) | Systems and methods for service assurance using virtualized federated presence infrastructure | |
| EP2513788A1 (fr) | Pre-chargement de contenu entre un serveur de contenu et au moins un terminal | |
| FR3014275A1 (fr) | Procede et serveur de reservation de ressources materielles de visioconference | |
| EP2612467B1 (fr) | Système de diffusion de données ciblées | |
| EP1139637A2 (fr) | Procédé et système d'octroi de privilèges par un gestionnaire d'accèss au sein d'un réseau de communication | |
| FR2851869A1 (fr) | Organe de mediation multi-domaines multi-fournisseurs pour la notification d'evenements | |
| EP1692882A1 (fr) | Procede et serveur de coordination de services de telecommunication | |
| US20080016113A1 (en) | Network access tool bar systems and methods | |
| WO2011124810A1 (fr) | Gestion de service personnalisee dans un reseau ip | |
| US20230130152A1 (en) | Identifying caller details for promotional voice communication | |
| EP2819352B1 (fr) | Dépôt et consultation de messages par des utilisateurs de réseaux sociaux | |
| EP2351328B1 (fr) | Procede et dispositif de generation d'informations descriptives de la situation d'un utilisateur | |
| FR2785121A1 (fr) | Procede pour changer periodiquement une information presentee par un terminal de communication a partir de donnees transmises par un serveur | |
| EP3110109A1 (fr) | Procédé et dispositif de mise à jour des capacités d'un objet connecté à un réseau de communications | |
| EP3465476B1 (fr) | Procédé d'invocation d'un service applicatif par un navigateur | |
| EP2038797B1 (fr) | Unite et procede de gestion d'au moins un canal dans une session d'acces a un service dans un reseau | |
| EP1494419A1 (fr) | Système de transmission de paramètres caractéristiques d'une session de communication d'un terminal vers un serveur distant | |
| Perälä et al. | Open service platform for pervasive multimedia services development | |
| FR2805625A1 (fr) | Procede et systeme d'octroi de privileges par un gestionnaire d'acces au sein d'un reseau de communication | |
| EP2311223A2 (fr) | Mise à jour de critères de recherche de contenu définis pour un fournisseur de service | |
| FR3058859A1 (fr) | Procede de delegation d'instructions a un dispositif en fonction de ses ressources | |
| FR3053190A1 (fr) | Identification d'utilisateurs dans un environnement predefini | |
| FR2970142A1 (fr) | Dispositif de terminaison de reseau adapte a la gestion d’operations et procede de mise en oeuvre. | |
| EP2464068A1 (fr) | Système de gestion globale de filtrage personnalisé basé sur un circuit d'échange d'informations sécurisé et procédé associé |