FR3014220A1 - Procede et serveur de notification d'une carte electronique - Google Patents

Abstract

L'invention concerne un procédé de notification, par un serveur d'un réseau de télécommunications, d'une carte électronique associée à un utilisateur titulaire enregistrée auprès de ce serveur, comprenant : - une étape (E20) d'enregistrement d'un utilisateur détenteur de la carte électronique ; - une étape (E30,E40) d'obtention de données d'information relatives à l'utilisateur titulaire et de données d'information relatives à l'utilisateur détenteur ; - une étape (E50) de recherche de données d'information communes à l'utilisateur titulaire et à l'utilisateur détenteur parmi les données d'informations obtenues ; et - si au moins une donnée d'information commune est détectée, une étape de notification (E70) de la carte électronique via le réseau de télécommunications.

Description

Arrière-plan de l'invention L'invention se rapporte au domaine général des communications. Elle concerne plus particulièrement le domaine des cartes matérielles (objets physiques) ou virtuelles embarquant des informations sur leurs titulaires. Ces informations sont par exemple des données d'identification telles qu'un nom, une adresse (personnelle ou professionnelle, postale ou électronique), un numéro de téléphone, une photographie, etc. De telles cartes peuvent être notamment des cartes de visite ou des cartes professionnelles, couramment échangées entre les utilisateurs titulaires de ces cartes auxquels les données présentes sur les cartes se rapportent, et des utilisateurs dits détenteurs ou récepteurs ou encore destinataires de ces cartes auxquels les cartes ont été données par les utilisateurs titulaires. Dans l'état actuel de la technique, les informations affichées sur ces cartes qu'elles soient matérielles ou virtuelles sont statiques, c'est-à-dire immuables. Ces informations sont également passives dans le sens où la seule interaction possible avec ces informations pour un utilisateur détenteur de la carte est de les lire. Ces cartes ont par conséquent un usage relativement restreint. Les possibilités d'interactions par le biais de ces cartes entre les utilisateurs titulaires et détenteurs sont en outre limitées aujourd'hui à des échanges directs entre ces utilisateurs (ex. échanges téléphoniques ou informatiques), à l'initiative de l'utilisateur détenteur sur la base des informations affichées sur la carte. Objet et résumé de l'invention L'invention propose d'étendre l'usage des cartes matérielles ou virtuelles embarquant des données relatives à leurs titulaires en leur adjoignant de nouveaux moyens et de nouvelles fonctionnalités visant à faciliter les interactions entre les titulaires et les personnes en possession de ces cartes. Elle s'appuie à cet effet d'une part sur la carte à proprement parler, qui est dotée conformément à l'invention de moyens permettant de notifier l'utilisateur détenteur de cette carte de l'existence d'opportunités d'interaction avec le titulaire de la carte, et d'autre part sur un serveur déployé dans un réseau de télécommunications, communiquant avec la carte et apte à détecter l'existence de telles opportunités. Au sens de l'invention, on désigne par utilisateur « titulaire » de la carte, l'utilisateur auquel se réfèrent les informations affichées sur la carte, et par utilisateur « détenteur » de la carte, un utilisateur auquel l'utilisateur titulaire a donné sa carte. L'invention concerne ainsi un procédé de notification, par un serveur d'un réseau de télécommunications, d'une carte électronique associée à un utilisateur titulaire et enregistrée auprès de ce serveur, ce procédé comprenant : - une étape d'enregistrement d'un utilisateur détenteur (i.e. récepteur) de la carte électronique ; une étape d'obtention de données d'information relatives à l'utilisateur titulaire et de données d'information relatives à l'utilisateur détenteur ; une étape de recherche de données d'information communes à l'utilisateur titulaire et à l'utilisateur détenteur parmi les données d'informations obtenues ; et si au moins une donnée d'information commune est détectée, une étape de notification de la carte électronique via le réseau de télécommunications. Corrélativement, l'invention vise aussi un serveur d'un réseau de télécommunications comprenant : un module d'enregistrement, apte à enregistrer une carte électronique associée à un utilisateur titulaire et un utilisateur détenteur de cette carte électronique ; un module d'obtention de données d'information relatives à l'utilisateur titulaire et de données d'information relatives à l'utilisateur détenteur ; un module de recherche de données d'information communes à l'utilisateur titulaire et à l'utilisateur détenteur parmi les données d'informations obtenues ; et - un module de notification de la carte électronique via le réseau de télécommunications activé si au moins une donnée d'information commune est détectée par le module de recherche. L'invention concerne également une carte électronique associée à un utilisateur titulaire et enregistrée auprès d'un serveur, et comprenant : un module de communication avec le serveur, agencé pour recevoir une notification émise par le serveur lorsqu'au moins une donnée d'information commune à l'utilisateur titulaire et à un utilisateur détenteur de la carte électronique a été détectée par le serveur ; et un module d'avertissement de l'utilisateur détenteur de la carte électronique, activé sur réception de la notification. Les données d'information relatives à l'utilisateur titulaire et à l'utilisateur détenteur peuvent être de natures très diverses et provenir de sources externes à la carte électronique elle- même. Ainsi, à titre d'exemple, il peut s'agir : - de données extraites d'un profil de l'utilisateur ; - de données de localisation de l'utilisateur ; - de données représentatives d'une activité de l'utilisateur ; et/ou - de données provenant de serveurs de réseaux sociaux. Bien entendu, d'autres types de données peuvent être envisagés en variante, en complément ou en remplacement des données précitées. La recherche de données communes à l'utilisateur titulaire et à l'utilisateur détenteur de la carte permet notamment de détecter l'existence d'une ou de plusieurs opportunités d'échanges entre ces utilisateurs (ex. participation à un événement commun répertorié dans les calendriers des utilisateurs, événements de l'activité de l'utilisateur titulaire porteur d'intérêt pour l'utilisateur détenteur de la carte, etc.). Cette recherche peut consister à identifier n'importe quelles données communes parmi les données d'information recueillies par le serveur, ou en variante, des données communes répondant à un ou plusieurs critères prédéterminés. De tels critères peuvent être notamment choisis par l'utilisateur titulaire de la carte de sorte à filtrer les possibilités d'échanges signalées à l'utilisateur détenteur auquel il a donné sa carte (ex. critère sur la nature professionnelle ou personnelle des données d'information, critère concernant une localisation associée à ces données), ou peuvent dépendre de l'utilisateur détenteur de la carte, etc. Une fois détectées par le serveur suite à l'enregistrement de l'utilisateur titulaire et de l'utilisateur détenteur, les opportunités d'échanges sont signalées à la carte qui en informe à son tour son détenteur par le biais de son module d'avertissement. Dans l'exemple d'une carte électronique matérielle, ce module d'avertissement peut se présenter notamment sous la forme d'une diode électroluminescente (ou LED (Light Emitting Diode)) ou encore d'un buzzer ou encore d'un module d'avertissement sonore, activé(e) sur réception de la notification du serveur. Ainsi, l'invention propose de rendre proactive la carte échangée entre l'utilisateur titulaire et l'utilisateur détenteur. Cette carte proactive permet de créer et de maintenir de manière très simple un lien social entre ces deux personnes, de manière transparente pour eux une fois l'enregistrement de l'échange de la carte effectué auprès du serveur. En outre, l'invention offre la possibilité de préserver la confidentialité des données d'informations recueillies par le serveur sur l'utilisateur titulaire vis-à-vis de l'utilisateur détenteur de la carte. Seul le serveur a en effet besoin d'accéder aux détails de ces données d'information pour effectuer la recherche de données communes aux deux utilisateurs. En revanche, la notification transmise par le serveur à la carte peut avantageusement ne pas contenir ces données, ni contenir de détails sur l'opportunité d'échange sous-jacente à la détection par le serveur de données communes aux utilisateurs. Il convient de noter qu'avantageusement la carte selon l'invention n'a pas besoin d'être dotée de moyens complexes et coûteux. Il suffit en effet de l'équiper de moyens d'avertissement destinés à notifier le détenteur de la carte et d'un module de communication avec le serveur pour être informée de l'existence de données communes à la personne titulaire et identifiée sur la carte et au détenteur de cette carte. Dans le cas d'une carte électronique matérielle (i.e. carte physique), ce module de communication peut comprendre un module de connexion directe au réseau de télécommunications du serveur, ou en variante comprendre un module de connexion à un équipement intermédiaire relié au réseau de télécommunications du serveur via lequel la notification émise par le serveur est reçue. Le module de connexion peut intégrer par exemple un module de radio-identification (aussi connu sous l'appellation de module RFID pour Radio Frequency IDentification en anglais), ou un port USB, etc. L'équipement intermédiaire peut être notamment un lecteur ou une borne dédiée au couplage avec la carte, ou en variante, un ordinateur muni d'un port de communication compatible avec le module de connexion de la carte. Il est ainsi possible de conserver un format peu encombrant pour la carte, compatible avec les formats existants de cartes professionnelles ou de cartes de visite. Une telle carte électronique matérielle présente l'avantage d'être tangible pour les utilisateurs. L'utilisateur détenteur de la carte peut ensuite se connecter à un site web ou un portail alimenté par le serveur pour obtenir de plus amples informations sur l'opportunité d'échange ou plus généralement sur les données communes détectées par le serveur à proprement parler. L'accès à ces données peut être configuré par l'utilisateur titulaire afin de filtrer les informations communiquées à l'utilisateur détenteur. L'invention a ainsi une application privilégiée mais non limitative dans le domaine de l'Internet des objets, qui vise à associer à des objets réels des interfaces intelligentes pour se connecter et communiquer au sein de contextes d'usages variés, via des réseaux de télécommunications tels que le réseau Internet. Il convient toutefois de noter que l'invention peut également s'appliquer à une carte électronique de type virtuelle (i.e. une application), à laquelle sont conférés des moyens logiciels de communication avec le serveur et d'avertissement de l'utilisateur détenteur (ex. affichage d'un symbole approprié, émission d'un son prédéterminé, etc.).

Dans un mode particulier de réalisation de l'invention, le procédé selon l'invention comprend en outre une étape d'agrégation des données d'information obtenues relatives à l'utilisateur titulaire et des données d'information obtenues relatives à l'utilisateur détenteur dans une structure de données conçue pour représenter de façon unique des données d'information communes à l'utilisateur titulaire et à l'utilisateur détenteur tout en les associant à chacun d'entre eux. Une telle structure de données est par exemple modélisée par un graphe. Les graphes sont des outils puissants permettant de représenter aisément et de façon synthétique des données d'information, et notamment les concepts contenus dans ces données ainsi que les relations liant ces concepts entre eux. L'ensemble des concepts et des relations liant ces concepts entre eux est aussi connu sous le nom d'ontologie. Par exemple, des données d'information selon lesquelles « X est inscrit à une conférence CONF Y » peuvent être modélisées par un graphe comprenant deux noeuds associés respectivement au concept « X » et au concept « conférence CONF Y », et un arc reliant ces deux noeuds ayant pour signification « est inscrit à ». L'étape d'agrégation peut ainsi avantageusement comprendre une analyse des données d'information obtenues à partir d'une ontologie préalablement définie comprenant une pluralité de types de concepts représentant les données d'informations et de relations liant ces concepts. Cette étape d'agrégation permet de fusionner les données d'information en préservant l'unicité des concepts sous-jacents contenus dans ces données. De cette sorte, la duplication dans la structure des données agrégées des représentations des données d'information communes aux utilisateurs est évitée. La structure des données agrégées qui en résulte est ainsi avantageusement synthétique.

Ainsi, dans l'exemple d'une structure de données modélisée par un graphe, l'étape d'agrégation consiste par exemple à élaborer un graphe dont les noeuds (ou sommets) et les arcs sont déduits des données d'information du titulaire et du détenteur de la carte, chaque noeud étant associé à un concept distinct. A titre illustratif, s'ils résultent des données obtenues par le serveur que X, titulaire de la carte, est inscrit à une conférence CONF Y, et que Z, détenteur de la carte, est également inscrit à la même conférence CONF Y, le graphe construit lors de l'étape d'agrégation contient un seul noeud associé à la conférence CONF Y reliés via deux arcs distincts aux noeuds associés aux utilisateurs « X » et « Z ». Grâce à l'étape d'agrégation, la recherche d'éléments communs parmi les données d'information obtenues relatives au titulaire et au détenteur de la carte est grandement facilitée. De même, la recherche d'éléments communs spécifiques, caractérisant un type d'interaction particulier ou encore un concept particulier, peut être mise en oeuvre aisément en recherchant un fragment de la structure de données correspondant à ce type d'interaction. En outre, ce mode de réalisation permet de s'appuyer sur des langages (ou modèles) existants de description de ressources et de requête. Ainsi, notamment, l'usage du langage de description RDF (Resource Description Framework) couramment utilisé pour décrire des ressources Web et leurs métadonnées, ou d'un langage de description dérivé de RDF, et du langage de requête SPARQL (SPARQL Protocol and RDF Query Language) permettant d'interroger les modèles RDF peuvent être envisagés pour mettre en oeuvre les étapes d'obtention, le cas échéant d'agrégation, et de recherche de l'invention. Bien entendu, l'invention ne se limite pas à l'utilisation des langages précités, et d'autres langages comme le langage de requête SQL (Structured Query Language) ou encore des langages de description et de requête propriétaires peuvent être utilisés. Dans un mode particulier de réalisation de l'invention, suite à l'obtention de nouvelles données d'information relatives à l'utilisateur titulaire et/ou à l'utilisateur détenteur, les étapes de recherche et le cas échéant de notification sont réitérées en tenant compte des nouvelles données d'information obtenues. L'obtention de nouvelles données d'information peut se faire à l'initiative du serveur, ou en variante, en mode push, dès lors que de nouvelles données d'information concernant le titulaire ou le détenteur de la carte sont détectées par les sources hébergeant ces données et qu'elles en informent le serveur (par exemple suite à une souscription du serveur auprès de ces sources d'information). L'invention permet ainsi d'offrir au détenteur de la carte des informations pertinentes concernant le titulaire, mises à jour en temps réel.

Dans un mode particulier de réalisation, les différentes étapes du procédé de notification sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un serveur ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé de notification tel que décrit ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. L'invention vise également un système comprenant un serveur et une carte électronique conformes à l'invention. Cette carte électronique peut être matérielle ou virtuelle. On peut également envisager, dans d'autres modes de réalisation, que le procédé de notification, le serveur, la carte électronique et le système selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.

Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures : - la figure 1 représente, de façon schématique, un système, un serveur et une carte électronique conformes à l'invention dans un mode particulier de réalisation ; - la figure 2 illustre de façon schématique l'architecture de la carte électronique de la figure 1 ; - la figure 3 illustre, de façon schématique, l'architecture matérielle du serveur de la figure 1 ; la figure 4 représente, sous forme d'ordinogramme, les principales étapes d'un procédé de notification selon l'invention telles que mises en oeuvre par le serveur de la figure 1, dans un mode particulier de réalisation ; - les figures 5A-5E illustrent des exemples de graphes et d'une requête sur un graphe pouvant être utilisés par le serveur de la figure 1.

Description détaillée de l'invention La figure 1 représente, dans son environnement, un système 1 conforme à l'invention dans un mode particulier de réalisation.

Dans l'exemple envisagé à la figure 1, le système 1 permet de créer et de maintenir un lien social entre deux utilisateurs X et Z via l'échange d'une carte de visite électronique 2 proactive, conforme à l'invention, sur laquelle sont affichées des données d'identification relatives à l'utilisateur X (ex. le nom de l'utilisateur, son adresse personnelle ou professionnelle, etc.). La carte électronique 2 est ici une carte matérielle. L'utilisateur X est un utilisateur titulaire de la carte électronique 2 au sens de l'invention, qui a donné sa carte de visite électronique 2 à l'utilisateur Z. L'utilisateur Z est donc un utilisateur détenteur de la carte électronique 2 au sens de l'invention. Pour créer et maintenir ce lien social, le système 1 s'appuie sur la carte électronique 2 confiée par l'utilisateur X à l'utilisateur Z, et sur un serveur 3 conforme à l'invention, relié à un réseau de télécommunications 4. Le réseau de télécommunications 4 est par exemple ici le réseau public Internet. Toutefois aucune limitation n'est attachée à la nature du réseau 4 ; il peut s'agir aussi bien d'un réseau fixe ou mobile, public ou propriétaire, filaire ou sans fil, etc. Le serveur 3 est adapté, conformément à l'invention, à agréger et à corréler des données d'information relatives à l'utilisateur X et à l'utilisateur Z mises à sa disposition par différentes sources d'information 5 afin d'identifier des données communes susceptibles de créer des opportunités d'échange entre les deux utilisateurs, et à notifier la carte électronique 2 détenue par l'utilisateur Z de l'existence de telles opportunités le cas échéant. On suppose à cet effet que l'utilisateur X a souscrit au service offert par le serveur 3 et enregistré auprès de celui-ci, lors de sa souscription, la carte électronique 2 ainsi qu'éventuellement d'autres cartes électroniques à son nom, identiques à la carte électronique 2, et destinées à de futurs contacts. Chaque carte électronique est identifiée lors de cet enregistrement par un identifiant ou un code ID : ainsi, la carte électronique 2 est associée à l'utilisateur X auprès du serveur 3 et identifiée par un identifiant ID2. Aucune limitation n'est attachée aux sources d'information 5 alimentant le serveur 3 en données d'information. Ces sources d'information peuvent être maintenues par le serveur 3 ou en variante par des tiers et communiquer avec le serveur 3 par le biais d'un réseau de télécommunications tel que le réseau de télécommunications 4. En outre, les données d'information fournies par les sources 5 peuvent être de différentes natures. Il peut s'agir notamment, de façon non exhaustive : de données d'information extraites de profils utilisateurs (ex. âge, profession, intérêts professionnels et/ou personnels, employeur, compétences, etc.), maintenus par exemple par le serveur 3 ou par les opérateurs de réseaux fixes ou mobiles auprès desquels ont souscrit les utilisateurs X et Z et avec lequel le serveur 3 possède un partenariat ; de données d'information de localisation des utilisateurs X et Z, fournies par exemple au serveur 3, le cas échéant, par les opérateurs des réseaux mobiles des utilisateurs X et Z ; de données d'information représentatives d'une activité des utilisateurs X et Z, poussées vers le serveur 3 par une application de calendrier électronique utilisée par les utilisateurs X et Z (ex. en association avec leur messagerie électronique) ; de données provenant de serveurs gérant des réseaux sociaux ; etc. Le choix des sources d'information 5 peut être décidé par le serveur 3 (en d'autres mots, par l'opérateur du service offert par le serveur 3), ou en variante être configuré par l'utilisateur X en fonction de ses préférences. Il peut également être configuré par l'utilisateur X de sorte à dépendre de l'utilisateur Z (en fonction notamment des informations que l'utilisateur X souhaite rendre accessibles à l'utilisateur Z ou des opportunités qu'il souhaite avoir avec l'utilisateur Z). Dans le mode de réalisation décrit ici, le serveur 3 communique avec la carte électronique 2 par le biais d'un équipement intermédiaire 6. Dans l'exemple envisagé à la figure 1, l'équipement intermédiaire 6 est un ordinateur personnel appartenant à l'utilisateur Z, et équipé d'un module de connexion 6A avec la carte électronique 2, de moyens 6B de communication sur le réseau 4, et d'un écran 6C. Le module de connexion 6A est par exemple un port ou une prise USB (Universal Serial Bus), ou encore un module de communication sans fil courte distance utilisant par exemple la technologie RFID (Radio Frequency Identification) ou Bluetooth, etc. L'équipement intermédiaire 6 joue le rôle de relai des notifications transmises par le serveur 3 à la carte électronique 2. En variante, l'équipement intermédiaire 6 peut être un lecteur de cartes dédié comprenant des moyens 6A de connexion avec la carte électronique 2 et des moyens 6B de communication sur le réseau 4. La carte électronique 2 est équipée d'un module de connexion compatible avec le module de connexion 6A de l'équipement intermédiaire 6. La figure 2 illustre schématiquement l'architecture de la carte électronique 2 matérielle confiée par l'utilisateur X à l'utilisateur Z. Dans l'exemple illustré à la figure 2, la carte électronique 2 a le format d'une carte de visite, et comprend : - une zone d'affichage 2A des données d'identification de l'utilisateur X ; - un module d'avertissement 2B, situé sur la surface externe de la carte électronique 2, et comprenant par exemple un buzzer ou une diode électroluminescente pour signaler à l'utilisateur Z la réception d'une notification du serveur 3 ; et un module de communication 2C incluant ici le module de connexion compatible avec le module de connexion 6A de l'équipement intermédiaire 6 (prise ou port USB, module RFID ou Bluetooth, etc. en fonction de la nature du module de connexion 6A).

Dans une variante de réalisation, la carte électronique 2 est apte à communiquer directement avec le serveur 3 par le biais du réseau de télécommunications 4 sans nécessiter d'équipement intermédiaire tel que l'équipement 6. Le module de communication 2C intègre alors un module de connexion au réseau de télécommunications 4 ou à un réseau relié au réseau de télécommunications 4. Bien entendu, la carte électronique 2 peut revêtir d'autres formes que celle illustrée schématiquement à la figure 2. Elle peut en outre intégrer d'autres moyens complémentaires, comme par exemple un microprocesseur ou un circuit logique programmable, une ou plusieurs mémoires lui permettant de stocker des informations transmises notamment par le serveur 3, un écran lui permettant d'afficher des informations, etc. Dans le mode de réalisation décrit ici, le serveur 3 a l'architecture matérielle d'un ordinateur, telle qu'illustrée schématiquement à la figure 3. Il comprend notamment un processeur 3A, une mémoire morte 3B, une mémoire vive 3C, une mémoire non volatile 3D et des moyens de communication 3E sur le réseau de télécommunications 4. La mémoire morte 3B du serveur 3 constitue un support d'enregistrement lisible par le processeur 3A et sur lequel est enregistré un programme d'ordinateur conforme à l'invention, comportant des instructions pour l'exécution des étapes d'un procédé de notification conforme à l'invention, les étapes de ce procédé de notification étant décrites ultérieurement en référence à la figure 4 dans un mode particulier de réalisation.

Ce programme d'ordinateur définit de façon équivalente des modules fonctionnels (logiciels) du serveur 3, tels que notamment un module d'enregistrement de la carte électronique 2 et de l'utilisateur Z détenteur de la carte électronique 2, un module d'obtention de données d'information relatives à l'utilisateur X et à l'utilisateur Z auprès des sources d'information 5 et un module d'agrégation de ces données, un module de recherche de données communes aux utilisateurs X et Z parmi les données agrégées et un module de notification de la carte électronique 2 le cas échéant. Les modules d'obtention et de notification utilisent notamment les moyens de communication 3E sur le réseau de télécommunications 4 du serveur 3. Les fonctions de ces divers modules sont décrites plus en détail en référence aux étapes du procédé de notification illustrées à la figure 4.

Nous allons maintenant décrire, en référence à la figure 4, les principales étapes du procédé de notification selon l'invention telles que mises en oeuvre par le serveur 3 de la figure 1 dans un mode particulier de réalisation. Comme mentionné précédemment, on suppose au préalable que l'utilisateur X a souscrit au service offert par le serveur 3. Il a, lors de cette souscription, enregistré auprès du serveur 3 (i.e. du module d'enregistrement du serveur 3) la carte électronique 2 en fournissant son identifiant ID2 (étape E10), ainsi qu'éventuellement d'autres cartes électroniques identiques à la carte électronique 2 et qu'il destine à d'autres utilisateurs.

On suppose par ailleurs que l'utilisateur X donne sa carte électronique 2 à l'utilisateur Z, et que celui-ci s'enregistre auprès du module d'enregistrement du serveur 3 (étape E20). Lors de cet enregistrement, l'utilisateur Z fournit l'identifiant ID2 de la carte électronique 2 ainsi que son propre identifiant (ex. un nom et/ou un numéro de téléphone, etc.).

Suite à cet enregistrement, le serveur 3 envoie, via le réseau de télécommunications 4, une requête identifiant les utilisateurs X et Z aux sources d'informations 5, afin d'obtenir les données d'information relatives à ces utilisateurs dont disposent les sources 5. Cette requête peut prendre la forme d'une souscription auprès de tout ou partie des sources 5, afin qu'elles transmettent de leur propre initiative au serveur 3 (c'est-à-dire en mode push) les données d'informations relatives aux utilisateurs X et Z dont elles disposent dès qu'elles obtiennent ces données ou dès que celles-ci sont mises à jour. En variante, la requête du serveur 3 peut être réitérée de manière périodique ou prédéterminée afin de disposer de données d'information pertinentes et à jour provenant des sources 5 sur les utilisateurs X et Z.

Le serveur 3 obtient ainsi des sources d'information 5, via son module logiciel d'obtention, les données d'information dont ces sources disposent sur les utilisateurs X et Z (étape E30). Dans le mode de réalisation décrit ici, le serveur 3 agrège les données d'information reçues des différentes sources d'information 5 sous la forme d'un graphe G conforme au langage de description RDF. Ce langage est décrit notamment dans le document RDF - Semantic Web Standards disponible sur le site www.w3.org/RDF. De façon connue, le langage RDF décrit toute information sous la forme d'un modèle et plus précisément d'un graphe, représentant les concepts impliqués dans cette information ainsi que les relations liant ces concepts entre eux. A titre illustratif, si l'information considérée est « X est inscrit à une conférence CONF Y », les concepts impliqués dans cette information sont « X » et « conférence CONF Y », et la relation liant ces concepts est « est inscrit à ». Plus spécifiquement, afin de garantir la cohérence et la bonne interprétation des modèles, le langage RDF s'appuie sur la définition et l'utilisation d'ontologies, qui sont elles-mêmes des modèles RDF définissant des types de données ou d'objets dont les concepts contenus dans chaque information relèvent. Une ontologie, dans un contexte informatique, désigne une conceptualisation d'un domaine de connaissances. Par conceptualisation, on entend ici la définition des termes qui sont nécessaires pour exprimer le sens d'une information relevant de ce domaine et les propriétés de ces termes. Les termes incluent les types d'objet (ou classes) et les relations entre ces types d'objet. Une propriété d'une relation est par exemple sa transitivité.

Autrement dit, une ontologie désigne à la fois un choix quant à la manière de décrire un domaine, et la description formelle de ce domaine. Les ontologies sont couramment utilisées dans des domaines tels que l'intelligence artificielle, le web sémantique, le génie logiciel, etc.

Les figures 5A et 5B illustrent deux exemples de graphes conformes au langage RDF modélisant respectivement une information (ou de façon équivalente un ensemble de données d'information au sens de l'invention) stipulant que « X est inscrit à une conférence CONF Y » et une information stipulant « X est né le 20 septembre 1980 ».

Plus précisément, en référence à la figure 5A, l'information « X est inscrit à une conférence CONF Y » est modélisée, conformément au langage RDF, par un graphe comportant deux noeuds distincts N1 et N2 associés respectivement au concept « X » et au concept « CONF Y ». Les concepts « X » et « conférence CONF Y » sont associés à des types de données ou d'objets différents, à savoir un type « PERSONNE » (« X ») et un type CONFERENCE (« conférence CONF Y). Les concepts portés par les noeuds N1 et N2 sont liés par une relation Al2 de type « est inscrit à ». De façon similaire, en référence à la figure 5B, l'information « X a pour date de naissance le 20 septembre 1980 » est modélisée conformément au langage RDF par un graphe comportant deux noeuds distincts N3 et N4 associés respectivement au concept « X » et au concept « 20 septembre 1980 ». Les concepts « X » et « 20 septembre 1980 » sont associés à des types de données différents, à savoir un type PERSONNE (« X ») et un type DATE (« 20 septembre 1980 »). Les concepts portés par les noeuds N3 et N4 sont liés par une relation A34 de type « a pour date de naissance le ». L'agrégation par le serveur 3 des données d'information obtenues des sources 5 repose ainsi sur la définition préalable d'une ontologie permettant de représenter ces données d'information sous la forme d'un unique graphe G, dans lequel une donnée d'information (typiquement un concept) commune aux sources d'information 5 et aux utilisateurs considérés est représentée à l'aide d'un unique élément du graphe, à savoir d'un unique noeud de ce graphe : on évite ainsi de dupliquer les concepts sous-jacents représentés dans ce graphe.

Cette définition de l'ontologie comprend le typage des concepts contenus dans les données d'information, c'est-à-dire la définition des types ou des classes d'objets auxquels se rapportent les différentes données d'information, et des relations liant ces types ou classes d'objets. Ce typage des concepts peut être prédéfini et déterminé préalablement en fonction de la nature des informations que le serveur 3 s'attend à recevoir des sources d'information 5 ou du type de sources d'information 5 sollicitées par le serveur 3. Ainsi par exemple, il peut comprendre les types de concepts suivants : PERSONNE, DATE, LIEU, CONFERENCE, HOBBY, AMIS, etc., et les relations suivantes « est inscrit à », « a pour date de naissance », « se trouve à », « a pour hobby », « a pour ami », etc. En variante, le typage des concepts peut être déterminé de manière dynamique par le serveur 3 à partir d'une analyse (notamment sémantique) des données d'informations qu'il reçoit des sources 5. Dans une autre variante encore, ce typage peut provenir des sources d'information 5 elles-mêmes si celles-ci utilisent déjà une représentation graphique, par exemple conforme au langage RDF, pour modéliser les données d'information dont elles disposent sur les utilisateurs X et Z. Dans une autre variante encore, une combinaison des variantes précitées peut être envisagée.

Lors de l'agrégation des données d'information, le serveur 3 analyse les données d'information obtenues des sources 5 à partir de l'ontologie ainsi préalablement définie. Plus spécifiquement, il identifie chaque concept contenu dans les données d'informations, et associe à chaque concept identifié un type de concept de l'ontologie préalablement définie. Par exemple, il identifie dans l'information « X est inscrit à la conférence CONF Y », le concept « X » et le concept « conférence CONF Y », et associe au concept « X » le type « PERSONNE » et au concept « conférence CONF Y » le type « CONFERENCE ». Il détermine par ailleurs les relations liant les concepts ainsi identifiés entre eux. Puis le serveur 3 construit un unique graphe G à partir des concepts et des relations ainsi identifiés, dans lequel : chaque concept distinct est associé à un unique noeud ; chaque noeud du graphe est relié à un ou plusieurs autres noeuds du graphe en fonction des relations liant les concepts entre eux dans les données d'information reçues des sources 5. La figure 5C illustre l'agrégation conformément à l'invention des données d'information « X est inscrit à une conférence CONF Y » et « X a pour date de naissance le 20 septembre 1980 ». Dans ces données d'information, le serveur 3 identifie les concepts « X » de type « PERSONNE » (abrégé en « PERS » sur la figure), « conférence CONF Y » de type « CONFERENCE » (abrégé en « CONF » sur la figure) et « 20 septembre 1980 » de type « DATE ». Chaque concept distinct est associé à un noeud unique du graphe G, à savoir : - « X » est associé au noeud N1' qui est une instance de type « PERSONNE » (modélisé par la liaison I01' sur le graphe) ; « conférence CONF Y » (abrégé en « CONF Y » sur la figure) est associé au noeud N2' qui est une instance de type « CONFERENCE » (modélisé par la liaison 102' sur le graphe) ; et « 20 septembre 1980 » (abrégé en « 20 sept 1980 » sur la figure) est associé au noeud N3' qui est une instance de type « DATE » (modélisé par la liaison 103' sur le graphe). Le noeud N1' est relié aux deux concepts « conférence CONF Y » et « 20 septembre 1980 » via deux liaisons Al2' et A13' distinctes modélisant respectivement les relations « est inscrit à » et « a pour date de naissance le ». Selon un autre exemple, la figure 5D illustre l'agrégation conformément à l'invention des données d'information « X est inscrit à une conférence CONF Y » et « Z est inscrit à une conférence CONF Y ». Dans ces données d'information, le serveur 3 identifie les concepts « X » et « Z » de type « PERSONNE » (abrégé en « PERS » sur la figure) et « conférence CONF Y » de type « CONFERENCE » (abrégé en « CONF » sur la figure). Chaque concept distinct est associé à un noeud unique du graphe G, à savoir : « X » est associé au noeud N1' qui est une instance de type « PERSONNE » (modélisé par la liaison I01' sur le graphe) ; « conférence CONF Y » (abrégé en « CONF Y » sur la figure) est associé au noeud N2' qui est une instance de type « CONFERENCE » (modélisé par la liaison 102' sur le graphe) ; et « Z » est associé au noeud N1" qui est une instance de type « PERSONNE » (modélisé par la liaison I01" sur le graphe). Le concept « conférence CONF Y » est commun aux deux utilisateurs X et Z. Le noeud N2' est ainsi relié aux deux concepts « X » et « Z » via deux liaisons Al2' et Al2" distinctes modélisant respectivement la relation « est inscrit à ». Ainsi selon cet exemple la duplication des concepts communs est évitée. Il convient de noter en revanche que ceci ne s'applique pas ici aux relations liant les concepts entre eux (ex. deux liaisons distinctes Al2' et Al2" relient les noeuds N1' et N1" au noeud N2').Le graphe G construit par le serveur 3 est une structure de données conçue avantageusement pour représenter de manière unique les différents concepts contenus dans les données d'information reçues des sources 5. Ce graphe est en effet conçu de manière à éviter de représenter plusieurs fois dans le graphe G (autrement dit à l'aide d'éléments de représentation distincts) des données d'information communes (et notamment des concepts communs) aux utilisateurs. Ces données d'information communes sont au contraire représentées par un unique noeud relié aux utilisateurs partageant ces données. Le graphe G offre ainsi une représentation synthétique des données d'information obtenues des sources 5, et qui permet sous cette forme d'identifier aisément et rapidement les données communes aux utilisateurs X et Z. Il convient de noter que l'invention ne se limite toutefois pas à l'utilisation de graphes et d'autres structures de données agrégées peuvent être envisagées pour représenter les données d'information obtenues des sources d'information 5, comme par exemple des tuples (i.e. n-uplets) de modèles relationnels utilisés classiquement dans les bases de données... Ces structures de données alternatives sont préférentiellement conçues de manière à éviter une duplication des éléments représentant des données d'information communes aux deux utilisateurs et aux sources. Toutefois, on peut également envisager d'avoir une structure de données agrégées sous optimale dans laquelle de telles duplications existent. Suite à l'étape d'agrégation, le serveur 3 recherche dans le graphe G des données d'information communes à l'utilisateur X et à l'utilisateur Z (étape E50). Cette étape de recherche permet au serveur 3 d'identifier des opportunités d'interaction (c'est-à-dire d'échange) entre l'utilisateur X titulaire de la carte électronique 2 et l'utilisateur Z détenteur de celle-ci.

Comme mentionné précédemment, la définition d'ontologies et la construction du graphe G facilitent avantageusement cette recherche. Une opportunité d'interaction entre les utilisateurs X et Z est en effet détectée en recherchant des fragments de graphe caractéristiques de cette interaction, autrement dit caractéristiques des données communes que l'on recherche.

Ainsi, à titre d'exemple, pour détecter une inscription commune des utilisateurs X et Z à une même conférence, le serveur 3 recherche dans le graphe G la présence du sous-graphe illustré à la figure 5E, dans lequel le concept ou noeud « ?? » est une variable de type « CONFERENCE ». Une telle recherche est réalisée par le serveur 3 en appliquant une requête spécifique au graphe G et définissant le fragment de graphe recherché (i.e. caractéristique des données communes). Cette requête est exprimée, dans le mode de réalisation décrit ici, à l'aide du langage dédié SPARQL, connu en soi. Le concept représenté par la variable « ?? » peut s'identifier à n'importe quel concept du graphe pourvu que les relations qui le lient à ses noeuds voisins soient identiques à celles du fragment défini dans la requête. Ainsi, dans l'exemple illustré à la figure 5D, ce concept doit être relié aux utilisateurs X et Y par des liaisons de type « est inscrit à », et être un concept de type « CONFERENCE » (modélisée par la liaison IO sur le fragment de graphe de la figure 5D). Bien entendu cet exemple n'est donné qu'à titre illustratif, et d'autres occurrences peuvent être recherchées dans le graphe G de sorte à identifier des données d'information communes à l'utilisateur X et à l'utilisateur Z. Il convient de noter que le serveur 3 peut définir des requêtes de sorte à chercher tout type de données communes aux utilisateurs X et Z, ou au contraire, des données communes répondant à un ou plusieurs critères prédéterminés, décidés par exemple par l'utilisateur X (ex. recherche d'une présence à une même conférence tandis que ne sont pas recherchées des données relatives à des hobbys communs aux deux utilisateurs par exemple). On peut ainsi envisager que l'utilisateur X puisse définir ou limiter, lors de sa souscription ou ultérieurement, le type d'interactions qu'il souhaite être recherchées par le serveur. Par ailleurs, plusieurs requêtes portant sur des types de concepts distincts par exemple peuvent être appliquées par le serveur 3 au graphe G.

Si l'application par le serveur 3 d'une telle requête retourne un résultat positif (réponse oui à l'étape test E60), autrement dit si le fragment de graphe défini dans la requête est présent dans le graphe G, cela signifie qu'il existe dans le graphe G au moins une donnée commune aux utilisateurs X et Z conforme à ce fragment de graphe. La réponse à la requête fournit le concept commun aux utilisateurs X et Z, c'est-à-dire, dans l'exemple de la figure 5D, le concept commun de type « CONFERENCE » auquel la variable « ?? » de la requête a été identifiée, autrement dit encore, la conférence commune à laquelle sont inscrits les utilisateurs X et Z. Le serveur 3 associe ici à la ou aux donnée(s) commune(s) ainsi détectée(s) une opportunité d'interaction entre les utilisateurs X et Z. Il notifie la carte électronique 2 de l'existence de cette opportunité, ou de manière plus générale, de l'existence de données communes aux utilisateurs X et Z (étape E70). Cette notification est envoyée à la carte électronique 2 via ses moyens de communication 3E sur le réseau de télécommunications 4. Dans le mode de réalisation décrit ici, elle est transmise à la carte électronique 2 par le biais de l'équipement intermédiaire 6.

Sur réception de cette notification, la carte électronique 2 avertit l'utilisateur Z en activant son module d'avertissement 2B. Autrement dit, la carte électronique 2 s'allume si le module d'avertissement comprend une diode de type LED, ou émet une vibration si celui-ci comprend un buzzer sur réception de la notification du serveur 3.

L'utilisateur Z ainsi averti peut ensuite se connecter par exemple à un portail géré par le serveur 3 via l'équipement intermédiaire 6, pour prendre connaissance de la signification de la notification adressée par le serveur 3, et notamment accéder à de plus amples informations sur l'opportunité d'échange avec l'utilisateur X détectée par le serveur 3 (ex. nature de l'opportunité, à savoir ici présence à une conférence commune, nom de la conférence, etc.). Ces informations peuvent être visualisées par l'utilisateur Z sur l'écran 6C de l'équipement intermédiaire 6. En variante, l'utilisateur Z peut accéder à ces informations à l'aide d'un dispositif distinct de l'équipement intermédiaire 6. Dans le mode de réalisation décrit ici, la recherche de données d'information communes aux utilisateurs X et Z est réitérée à chaque fois qu'une ou plusieurs sources d'information 5 fournit au serveur 3 de nouvelles données d'informations sur l'utilisateur X et/ou sur l'utilisateur Z (étape E80, et réponse oui à l'étape E80 rebouclant sur l'étape E40), à partir du graphe G dans lequel ces nouvelles données d'informations sont intégrées. On note que lorsqu'une opportunité d'échange est détectée par le serveur 3 alors que la carte électronique 2 n'est pas connectée à l'équipement intermédiaire 6, et ne peut ainsi pas recevoir la notification du serveur 3, le serveur 3 peut stocker en mémoire cette opportunité ainsi que les infOrmations s'y rapportant émanant du graphe G et signaler l'existence de cette opportunité dès qu'elle détecte la connexion de la carte électronique 2 à l'équipement intermédiaire 6 ou dès que la carte électronique 2 s'enregistre de nouveau auprès du serveur 3. Dans le mode de réalisation décrit ici, la carte électronique 2 est une carte matérielle, autrement dit un objet physique. En variante, la carte électronique 2 peut être une carte virtuelle (i.e. une application), à laquelle sont conférés des moyens logiciels de communication avec le serveur et d'avertissement de l'utilisateur détenteur (ex. affichage d'un symbole approprié, émission d'un son prédéterminé, etc.).

Claims (15)

1. REVENDICATIONS1. Procédé de notification, par un serveur (3) d'un réseau de télécommunications, d'une carte électronique (2) associée à un utilisateur titulaire (X) et enregistrée auprès de ce serveur, ledit procédé comprenant : - une étape (E20) d'enregistrement d'un utilisateur détenteur (Z) de la carte électronique ; une étape (E30,E40) d'obtention de données d'information relatives à l'utilisateur titulaire et de données d'information relatives à l'utilisateur détenteur ; - une étape (E50) de recherche de données d'information communes à l'utilisateur titulaire et à l'utilisateur détenteur parmi les données d'informations obtenues ; et si au moins une donnée d'information commune est détectée, une étape de notification (E70) de la carte électronique via le réseau de télécommunications.
2. 2. Procédé selon la revendication 1 comprenant en outre une étape d'agrégation (E40) des données d'information obtenues relatives à l'utilisateur titulaire et des données d'information obtenues relatives à l'utilisateur détenteur dans une structure de données conçue pour représenter de façon unique les données d'information communes à l'utilisateur titulaire et à l'utilisateur détenteur tout en les associant à chacun d'entre eux.
3. 3. Procédé selon la revendication 2 dans laquelle la structure de données est modélisée par un graphe (G).
4. 4. Procédé selon la revendication 2 ou 3 dans lequel l'étape d'agrégation comprend une analyse des données d'information obtenues à partir d'une ontologie préalablement définie comprenant une pluralité de types de concepts représentant les données d'informations et de relations liant ces concepts.
5. 5. Procédé selon la revendication 3 ou 4 dans laquelle le graphe est conforme au langage de description RDF (Resource Description Framework) ou à un langage dérivé du langage 30 RDF.
6. 6. Procédé selon l'une quelconque des revendications 1 à 5 dans lequel, suite à l'obtention (E80) de nouvelles données d'information relatives à l'utilisateur titulaire et/ou à l'utilisateur détenteur, les étapes de recherche et le cas échéant de notification sont réitérées en 35 tenant compte des nouvelles données d'information obtenues.
7. 7. Procédé selon l'une quelconque des revendications 1 à 6 dans lequel les données d'information relatives à l'utilisateur titulaire et/ou à l'utilisateur détenteur sont sélectionnées parmi au moins : - des données extraites d'un profil de l'utilisateur ; - des données de localisation de l'utilisateur ; - des données représentatives d'une activité de l'utilisateur ; - des données provenant de serveurs de réseaux sociaux.
8. 8. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de notification selon l'une quelconque des revendications 1 à 7 lorsque ledit programme est exécuté par un ordinateur.
9. 9. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de notification selon l'une quelconque des revendications 1 à 7.
10. 10. Serveur (3) d'un réseau de télécommunications comprenant : un module d'enregistrement, apte à enregistrer une carte électronique (2) associée à un utilisateur titulaire (X) et un utilisateur détenteur (Z) de cette carte électronique ; un module d'obtention de données d'information relatives à l'utilisateur titulaire et de données d'information relatives à l'utilisateur détenteur ; un module de recherche de données d'information communes à l'utilisateur titulaire et à l'utilisateur détenteur parmi les données d'informations obtenues ; et un module de notification de la carte électronique via le réseau de télécommunications (4) activé si au moins une donnée d'information commune est détectée par le module de recherche.
11. 11. Carte électronique (2) associée à un utilisateur titulaire et enregistrée auprès d'un serveur comprenant : - un module de communication (2C) avec le serveur, agencé pour recevoir une notification émise par le serveur lorsqu'au moins une donnée d'information commune à l'utilisateur titulaire et à un utilisateur détenteur de la carte électronique a été détectée par le serveur ; et - un module d'avertissement (2B) de l'utilisateur détenteur de la carte électronique, activé sur réception de ladite notification.35
12. 12. Carte électronique selon la revendication 11 dans lequel le module de communication comprend un module de connexion audit réseau de télécommunications dudit serveur.
13. 13. Carte électronique selon la revendication 11 dans lequel le module de communication comprend un module de connexion à un équipement intermédiaire relié au réseau de télécommunications du serveur via lequel ladite notification du serveur est reçue.
14. 14. Système (1) comprenant : - un serveur (2) selon la revendication 10 ; et - une carte électronique (2) selon l'une quelconque des revendications 11 à 13.
15. 15. Système selon la revendication 14 dans lequel la carte électronique est une carte électronique matérielle.15