FR3047096A1

FR3047096A1 - Utilisation de donnees sociales pour des applications de telecommunications

Info

Publication number: FR3047096A1
Application number: FR1650506A
Authority: FR
Inventors: Arnaud Brun
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2016-01-22
Filing date: 2016-01-22
Publication date: 2017-07-28

Abstract

L'invention concerne le traitement de données de contacts d'un utilisateur d'un terminal de télécommunication (TER). Les données de contacts de l'utilisateur sont archivées en correspondance de données de graphe social de l'utilisateur. En particulier, le terminal (TER) met en œuvre les étapes : - Détecter un contexte courant d'utilisation du terminal (CXT), Utiliser les données du graphe social pour établir un classement des données de contacts en fonction du contexte courant (M40), et Piloter une interface homme machine pour présenter à l'utilisateur, pendant ledit contexte courant, les données de contacts selon le classement établi.

Description

Utilisation de données sociales pour des applications de télécommunications

La présente invention concerne la fourniture et l’utilisation de données sociales à des applications de télécommunications pour smartphone, selon les habitudes de communication et le contexte de l’utilisateur.

Un terminal de type téléphone intelligent (ou « smartphone » ci-après) est un téléphone mobile évolué disposant généralement des fonctions d'un assistant numérique personnel, d'un appareil photo numérique, d'un ordinateur portable, etc. Comme un ordinateur, un smartphone peut exécuter divers logiciels (appelés « applications ») grâce à un système d'exploitation spécialement conçu pour mobiles (tel que Android ou iOS par exemple). Ces applications peuvent fournir à l’utilisateur un très grand nombre de services.

Beaucoup de ces services ont une forte dimension sociale, et permettent à l’utilisateur d’interagir avec d'autres personnes. A titre d’exemple, on peut citer les services suivants : - Services de stockage et de partage de contenus multimédia, - Services de stockage et de partage de données issue d’objets connectés, - Services d’échange de messages (type « chat >>, SMS, MMS ou autres), - Services permettant notamment l’échange d’avis (sur des restaurants, des hôtels, ou autres), - Services permettant d’organiser des rendez-vous ou événements, - Services de rencontres géo-localisées.

Tous ces services (utilisables depuis un smartphone grâce à des applications dédiées) comportant une forte dimension sociale comptent parmi les services les plus utilisés et les plus populaires aujourd’hui. Les applications correspondantes apparaissent régulièrement dans les palmarès des applications les plus téléchargées par les utilisateurs de smartphones.

Lorsqu’il utilise de telles applications, l’utilisateur doit fréquemment sélectionner un ou plusieurs contacts (numéros de téléphones par exemple) ou groupes de contacts, par exemple lorsqu’il souhaite : - Déterminer le(s) destinataire(s) d’un message, d’un avis, d’un commentaire, etc. Déterminer les personnes qui pourront consulter un ensemble de contenus mis en partage, - Déterminer les personnes qui pourront avoir accès à certaines données personnelles (information de géolocalisation, etc.) - Déterminer les personnes qui sont destinataires d’une invitation pour un évènement, - Etc.

Ces sélections manuelles alourdissent l’utilisation du terminal.

La présente invention vient améliorer la situation.

Elle propose à cet effet un procédé de traitement de données de contacts d’un utilisateur d’un terminal de télécommunication, dans lequel les données de contacts de l’utilisateur sont archivées en correspondance de données de graphe social de l’utilisateur. Le procédé comporte les étapes mises en œuvre par le terminal : - Détecter un contexte courant d’utilisation du terminal, - Utiliser les données du graphe social pour établir un classement des données de contacts en fonction du contexte courant, et - Piloter une interface homme machine pour présenter à l’utilisateur, pendant ledit contexte courant, les données de contacts selon le classement établi.

Ainsi, l’invention propose d’utiliser des données de graphe social (qui peuvent être obtenues par l’opérateur, comme on le verra plus loin dans un exemple de réalisation, par recoupement avec des horodates, des durées, des fréquences, etc., de communication de l’utilisateur avec ses contacts habituels) afin de proposer, en fonction d’un contexte courant, un classement des contacts par exemple selon une catégorie la plus appropriée par rapport au contexte détecté (par exemple les contacts professionnels pendant des heures de bureau).

Dans une réalisation, les données de contacts comportent au moins des identifiants respectifs de groupes de contacts. Les groupes de contacts comportent par exemple : - des contacts professionnels de l’utilisateur, - des contacts personnels de l’utilisateur, - éventuellement des contacts de personnes relatives à un loisir commun, ou à un projet associatif, ou autres.

Bien entendu, l’utilisateur peut participer à plusieurs types de loisirs, projets, etc. On entend ainsi par « graphe social », les différents groupes auxquels peut être lié l’utilisateur avec une distinction stockée en mémoire pour chaque groupe (les données de graphe social précitées).

Dans une réalisation, la détection du contexte d’utilisation comporte les opérations : - obtenir au moins une donnée courante et une information de lancement d’une application de télécommunication utilisant les données de contacts de l’utilisateur, - en fonction du type d’application à lancer et de règles prédéterminées de pertinence de la donnée courante relativement à ladite application de télécommunication, définir un contexte courant d’utilisation du terminal.

Par exemple, pour passer un appel téléphonique pendant une heure de bureau, l’application de téléphonie peut se référer à une horodate courante, déterminer qu’il s’agit d’une heure de bureau, et proposer alors les contacts professionnels en premier lieu à l’utilisateur. En revanche, pour transmettre (même pendant une heure de bureau) un fichier personnel tel que par exemple une vidéo acquise par le terminal pendant une horodate de weekend, il est proposé en premier lieu les contacts personnels.

Ainsi par exemple, dans une réalisation, le lancement d’une application de télécommunication (téléphonie, transmission de données multimédia, messagerie, ou autre) provoque sur le terminal l’exécution desdites étapes du procédé, pour présenter à l’utilisateur les données de contacts selon le classement établi avant la sélection par l’utilisateur d’un contact pour exécuter l’application de télécommunication.

Dans une réalisation, le contexte d’utilisation du terminal est défini en fonction d’au moins une donnée courante, telle qu’une horodate courante, une géolocalisation courante, une plage d’occupation courante de l’utilisateur, ou encore un état biométrique de l’utilisateur.

Dans une réalisation, le terminal peut se connecter à un serveur distant stockant une base de données des contacts de l’utilisateur en correspondance des données de graphe social de l’utilisateur, pour récupérer les données du graphe social de l’utilisateur auprès du terminal. Par ailleurs, le terminal peut stocker localement dans l’une de ses mémoires une base de contacts, que le terminal peut mettre à jour, régulièrement ou par l’action de l’utilisateur, en se connectant au serveur précité. Dans un exemple de réalisation décrit plus loin, le serveur gère une base de contact de type dit « Telco Social Graph ».

La présente invention vise aussi un programme informatique comportant des instructions pour la mise en œuvre du procédé ci-avant, lorsque ce programme est exécuté par un processeur (tel que le processeur du terminal, portant la référence PROC sur la figure 1).

La présente invention vise aussi un terminal de télécommunication comportant un circuit de traitement pour la mise en œuvre du procédé ci-avant. En référence à la figure 1, ce circuit comporte typiquement un processeur PROC coopérant avec une mémoire de travail (une mémoire temporaire pour le traitement des données, et une mémoire permanente pour le stockage de données de programme informatique, pour le stockage de données de contact, etc.). Bien entendu, le terminal TER comporte en outre une interface de communication INT pour récupérer les données de graphe social, notamment, du serveur précité (référencé Ml sur la figure 1 et gérant la base BD2 du graphe social de l’utilisateur). L’invention peut viser aussi un tel serveur, gérant la base de données du graphe social de l’utilisateur. D'autres avantages et caractéristiques de l'invention apparaîtront à la lecture de la description d'exemples de réalisation donnés ci-après, et à l'examen des dessins annexés sur lesquels : - la figure 1 illustre un système global mettant en œuvre un terminal selon l’invention, - la figure 2 illustre un exemple de mise en œuvre du procédé ci-avant par des modules informatiques que comporte le terminal.

Dans une forme de réalisation décrite à titre d’exemple ci-après, il est utilisé un graphe social pour télécommunications de type « Telco Social Graph », comme suit.

Les données de communication (ou « call logs ») d’un opérateur de téléphonie forment typiquement l'historique des appels vocaux émis, des messages SMS et MMS envoyés. Ces données sont généralement utilisées par un système d’information d’un opérateur pour facturer ses clients et établir en particulier les factures détaillées des clients.

On peut ainsi construire à partir de ces données, une base de données de type « Telco Social Graph » (TSG), répertoriant pour un utilisateur un graphe social de contacts par exemple sous forme de différentes listes de contacts : professionnels, personnels, de loisir, etc. En pratique, ces données peuvent être répertoriées dans une base de données BD2 stockant, pour un utilisateur donné, les données de chaque contact de cet utilisateur en correspondance d’un identifiant particulier (un identifiant de type de contact, par exemple). Ainsi, chaque contact peut être classé dans une catégorie particulière, par exemple la catégorie des contacts personnels (identifiés par un premier identifiant), la catégorie des contacts professionnels (identifiés par un deuxième identifiant), la catégorie des contacts liés à un premier loisir de l’utilisateur (identifiés par un troisième identifiant), la catégorie des contacts liés à un deuxième loisir de l’utilisateur (identifiés par un quatrième identifiant), etc.

Le classement des contacts selon de telles catégories peut s’effectuer informatiquement, en fonction : - Des horodates d’appel ou d’envoi de message, - Des fréquences d’appels ou de messages, - Des durées d’appels ou un nombre de messages successifs à un même destinataire dans une même période, - Des successions fréquentes d’appels (par exemple la réception d’un appel ou d’un message d’un contact X, occasionne souvent l’émission d’un appel ou l’émission de messages vers un ou plusieurs autres contacts Y, Z).

On entend par « horodates » des moments d’une journée ou d’une semaine permettant par exemple de discriminer si l’utilisateur communique pendant des heures de travail ou en dehors, et éventuellement, selon la périodicité des communications, si ces communications sont liées à des loisirs (par exemple le samedi pour organiser un évènement régulier le dimanche matin, comme une rencontre sportive par exemple).

Ainsi, en référence à la figure 1, des moyens informatiques Ml sont capables d’extraire d’une base des données des communications BD1, des données de renseignements sur les interactions sociales entre les utilisateurs du réseau de télécommunication pour former une base de graphes sociaux BD2. Ces moyens informatiques peuvent être par exemple un serveur comprenant un circuit informatique intégrant notamment un processeur.

Cette solution permet notamment : - De déterminer le graphe social d’un utilisateur (comparable à un graphe social que peuvent établir certains réseaux sociaux par exemple), - D’identifier différentes communautés parmi l’ensemble des contacts d’un utilisateur (par exemple distinguer les contacts appartenant à la sphère personnelle de l’utilisateur des contacts appartenant à sa sphère professionnelle, etc.) D’identifier le degré de proximité/d’intimité entre deux utilisateurs, - Etc.

Les moyens informatiques Ml mettent en œuvre à cet effet des algorithmes qui extraient puis utilisent différentes informations contenues dans les journaux d’appels (call logs) et permettant de déterminer la nature et la force du lien entre deux utilisateurs. Ainsi, de façon plus exhaustive que la liste donnée ci-avant à titre d’exemple illustratif, les informations suivantes peuvent être exploitées : - Les canaux de communication utilisés : communication vocale, communication en visioconférence, messages SMS, messages MMS, - La fréquence et la durée des communications, - L’horodate des communications, - Le sens des communications (entrantes/sortantes), - La localisation des utilisateurs au moment des communications, - L’évolution dans le temps de toutes ces informations, - Etc.

Ainsi, le serveur Ml est capable de produire des données sociales telles que : - L’ensemble des contacts professionnels d’un utilisateur, - L’ensemble des contacts personnel d’un utilisateur, - Les contacts faisant parti d’une communauté particulière de l’utilisateur (par exemple pour un loisir tels les membres de l’équipe de foot dans laquelle joue l’utilisateur, ou les personnes avec lesquelles l’utilisateur a une activité dans une association, ou les membres de la famille de l’utilisateur, etc.),

Les N contacts avec lesquels l’utilisateur a eu le plus d’échanges au cours du dernier mois ou de la dernière semaine, - Etc.

Ces données sociales peuvent alors être stockées dans la base de données BD2. La mise à jour des données dans la base BD2 des informations sociales issues des call logs peut être réalisée régulièrement (une fois par jour par exemple) ou par exemple lorsque la base de données BD2 est sollicitée comme présenté plus loin en référence à la figure 2 (flèches 2 et 3).

Ainsi, un terminal TER, de type smartphone, sur lequel plusieurs applications sociales (applications permettant à l’utilisateur du smartphone d’interagir avec d'autres personnes) ont été préalablement installées, peut exécuter une application spécifique au sens de l’invention pour proposer à l’utilisateur le/les contact(s) ou groupe(s) de contact(s) pertinent(s) (ou autres données sociales pertinentes), selon le contexte de l’utilisateur (par exemple selon son activité, sa géolocalisation, etc.), lorsque l’utilisateur lance une des applications sociales précitées.

Dans forme de réalisation, on prévoit la mise en œuvre d’une telle application spécifique pour smartphone (appelée ci-après « TSG App >>) qui peut être téléchargée puis installée par l’utilisateur sur son smartphone.

Lors de l’utilisation de ces applications sociales, cette application spécifique sélectionne pour l’utilisateur un ou plusieurs contacts (identifiés par exemple par leur numéro de téléphone), par exemple : - Des contacts à qui envoyer une invitation (invitation à une réunion professionnelle, invitation à une soirée réunissant les membres de l’équipe de foot dont fait partie l’utilisateur en temps de loisir, etc.), - Des contacts avec lesquels l’utilisateur veut partager un contenu (un groupe de personnes ayant participé avec l’utilisateur à un évènement en week-end dans une géolocalisation non habituelle, avec lequel l’utilisateur souhaite partager les contenus tels que des photos prises au cours de cet évènement, etc.), - Des contacts à qui envoyer un message (par exemple l’envoi d’un message personnel pendant un week-end), - Des contacts avec lesquels partager un avis ou un commentaire (sur un hôtel, un restaurant, un film, etc.). A chaque fois que l’utilisateur souhaite sélectionner une liste de contacts pour exécuter une application sociale, l’application spécifique TSG App propose à l’utilisateur le ou les contact(s) ou groupe(s) de contact(s) pertinent(s) par exemple, selon un contexte d’utilisation du smartphone (par exemple une horodate courante, sa géolocalisation, des plages d’activités programmées par l’utilisateur sur un agenda numérique, etc., selon son activité).

On a illustré sur la figure 2 les échanges entre les applications sociales contenues dans le smartphone et la base de données BD2, via l’application TSG App. Sur la figure 2, les applications sociales sont illustrées par des modules informatiques respectifs M21, M22, M23.

Dans une première étape (flèche 1), l’une des applications sociales, représentée par le module informatique M21, communique avec l’application TSG App représentée par le module M10, pour demander la ou les donnée(s) sociale(s) dont l’application sociale M21 a besoin. Il peut s’agir par exemple de : - L’ensemble des contacts professionnels de l’utilisateur, - L’ensemble des contacts personnels de l’utilisateur, - Les contacts faisant parti d’une communauté particulière de l’utilisateur (par exemple les membres de l’équipe de foot dans laquelle joue l’utilisateur, ou les personnes avec lesquelles l’utilisateur a une activité dans une association, ou les membres de la famille de l’utilisateur, etc.), - Les N contacts avec lesquels l’utilisateur a eu le plus d’échanges au cours du dernier mois ou de la dernière semaine, - Etc.

Dans une deuxième étape (flèche 2), l’application TSG App interroge la base BD2 (via le réseau de télécommunication RES, par exemple selon le protocole HTTP) pour obtenir les données sociales nécessaires pour l’application TSG App. Au cours de l’étape illustrée par la flèche 3, l’application TSG App récupère de la base BD2 les informations du graphe social, requises. Enfin, au court de l’étape suivante (flèche 4), l’application TSG App transmet à l’application sociale M21 les informations sociales demandées.

Ainsi, l’application sociale M21 peut présenter les contacts de l’utilisateur via une interface homme/machine telle que l’écran du terminal TER, par exemple avec une première page présentant les contacts les plus pertinents en fonction du contexte (par exemple les contacts professionnels pendant des heures de bureau), puis une deuxième page présentant des contacts moins pertinents (par exemple les contacts personnels pendant les heures de bureau), puis une troisième page de contacts encore moins pertinents (avec des contacts de loisirs par exemple), etc. Chaque page peut présenter des imagettes relatives à chaque contact (par exemple une photographie et le nom et éventuellement les coordonnées du contact), avec par exemple une taille d’imagette de plus en plus petite en fonction d’une rareté d’appels ou de communications de données avec ce contact. Ainsi, pour la présentation des contacts, plusieurs critères à la fois peuvent être combinés : par exemple ici une horodate courante, avec les fréquences d’appels respectives des contacts, pour une application de téléphonie.

Par exemple, l’exécution de l’application sociale M21 peut provoquer l’ouverture du carnet de contacts de l’utilisateur ainsi paramétré pour présenter un tel classement des contacts selon le contexte d’utilisation. Sur la figure 2, le module informatique gérant le carnet de contacts est illustré à titre d’exemple par la référence M40.

Pour affiner les données sociales fournies par la base BD2 (les contacts ou les groupes de contacts pertinents à proposer à l’utilisateur), l’application TSG App est capable de prendre en considération différents éléments de contexte de l’utilisateur. A cet effet, l’application TSG App peut solliciter le module informatique M30 (flèche 5) en charge de collecter des données de contexte et de les fournir au module M10 (flèche 6) pour l’exécution de l’application TSG App. En pratique, ces données de contexte sont issues de plusieurs autres applications installées dans le smartphone (par exemple des plages d’agenda électronique, une géolocalisation courante, une horodate courante, etc.). Une liste non limitative d’exemples d’informations contextuelles occasionnant une sélection de contacts particuliers peut être: - La date et l’heure d’utilisateur de l’application sociale : par exemple, si l’application sociale est utilisée pendant un week-end ou tard le soir, l’application TSG App peut plutôt proposer à l’application sociale des contacts personnels et non professionnels, - La géolocalisation courante de l’utilisateur au moment de l’utilisation de l’application sociale : par exemple, si l’application sociale est utilisée depuis le lieu de travail de l’utilisateur, l’application TSG App peut proposer plutôt des contacts professionnels et non personnels, - La disponibilité de l’utilisateur (information récupérée dans l’agenda électronique de l’utilisateur disponible sur le smartphone par exemple) : par exemple, si l’application sociale est utilisée alors que l’utilisateur est en réunion professionnelle, l’application TSG App peut proposer plutôt des contacts professionnels et non personnels, - Un autre exemple encore tel que l’humeur de l’utilisateur (information pouvant être issue d’objets connectés fournissant à une application dédiée installée sur le smartphone des données physiologiques telles que la pression artérielle de l’utilisateur) : par exemple, si les données captées sur l’utilisateur montrent que ce dernier est stressé, l’application TSG App peut proposer plutôt les contacts avec lesquels il a l’habitude de se distraire (par exemple en fonction de la durée habituelle des appels avec des contacts personnels) afin de l’encourager à communiquer avec ceux-ci et ainsi se détendre.

Ainsi, le terminal peut comporter (outre le processeur et la mémoire de travail illustrée sur la figure 1) une horloge ou une connexion au réseau pour récupérer l’horodate en cours, pour une utilisation par le module de contexte M30. Il peut comporter en outre des connexions à des capteurs biométriques que porte l’utilisateur (non représentés sur la figure 1). L’application TSG App permet ainsi d’enrichir des applications sociales existantes avec de nouvelles fonctionnalités sociales. L’application TSG App assure alors l’interaction avec le serveur Ml gérant la base BD2 pour obtenir les données sociales nécessaires au bon fonctionnement des applications sociales, de sorte qu’il n’est pas nécessaire que chaque application sociale dialogue avec le serveur Ml. Par ailleurs, l’application TSG App est capable de prendre en considération différents éléments de contexte de l’utilisateur pour affiner les informations sociales fournies par le serveur Ml avant de les transmettre aux applications sociales lancées par l’utilisateur.

Bien entendu, la présente invention ne se limite pas à la forme de réalisation décrite ci-avant à titre d’exemple ; elle s’étend à d’autres variantes.

Ainsi par exemple, on a décrit ci-avant une connexion du terminal à la base de données du graphe social de l’utilisateur BD2 pour déterminer les groupes pertinents d’utilisateurs à suggérer en premier lieu à l’utilisateur, en fonction du contexte d’utilisation. Bien entendu, une base de contacts avec des identifiants associés à chaque groupe peut être stockée localement auprès du terminal TER (par exemple dans le module M40 de la figure 2). Cette base M40 peut être mise à jour régulièrement (ou suite à une action de l’utilisateur) avec les données de base BD2. Le terminal TER peut ainsi mettre à jour les données de graphe social en affectant à chaque contact un identifiant de type de contact (par exemple, contacts personnels: contacts A, B, C ... ; contacts professionnels: contacts E, F G ... ; contacts liés à un loisir : H, I, J ...).

Claims

REVENDICATIONS

1. Procédé de traitement de données de contacts d’un utilisateur d’un terminal de télécommunication (TER), dans lequel les données de contacts de l’utilisateur sont archivées en correspondance de données de graphe social de l’utilisateur, Caractérisé en ce que le procédé comporte les étapes mises en oeuvre par le terminal : - Détecter un contexte courant d’utilisation du terminal, - Utiliser les données du graphe social pour établir un classement des données de contacts en fonction du contexte courant, et Piloter une interface homme machine pour présenter à l’utilisateur, pendant ledit contexte courant, les données de contacts selon le classement établi.
2. Procédé selon la revendication 1, caractérisé en ce que les données de contacts comportent au moins des identifiants respectifs de groupes de contacts (PERS, PRO, LOI).
3. Procédé selon l'une des revendications précédentes, caractérisé en ce que la détection du contexte d’utilisation comporte les opérations : - obtenir au moins une donnée courante et une information de lancement d’une application de télécommunication utilisant les données de contacts de l’utilisateur, - en fonction du type d’application à lancer et de règles prédéterminées de pertinence de la donnée courante relativement à ladite application de télécommunication, définir un contexte courant d’utilisation du terminal.
4. Procédé selon l'une des revendications précédentes, caractérisé en ce que le contexte d’utilisation du terminal est défini en fonction d’au moins une donnée courante.
5. Procédé selon la revendication 4, caractérisé en ce que la donnée courante est une horodate courante.
6. Procédé selon l'une des revendications 4 et 5, caractérisé en ce que la donnée courante est une géolocalisation courante.
7. Procédé selon l'une des revendications 4 à 6, caractérisé en ce que la donnée courante est une plage d’occupation courante de l’utilisateur.
8. Procédé selon l'une des revendications 4 à 7, caractérisé en ce que la donnée courante est un état biométrique de l’utilisateur.
9. Procédé selon l'une des revendications précédentes, caractérisé en ce que le lancement d’une application de télécommunication sur le terminal provoque l’exécution desdites étapes du procédé, pour présenter à l’utilisateur les données de contacts selon le classement établi avant la sélection par l’utilisateur d’un contact pour exécuter l’application de télécommunication.
10. Procédé selon l’une des revendications précédentes, caractérisé en ce que le terminal se connecte à un serveur distant (Ml) stockant une base de données (BD2) des contacts de l’utilisateur en correspondance des données de graphe social de l’utilisateur, pour récupérer lesdites données du graphe social de l’utilisateur auprès du terminal.
11. Programme informatique caractérisé en ce qu’il comporte des instructions pour la mise en œuvre du procédé selon l’une des revendications 1 à 10, lorsque ce programme est exécuté par un processeur.
12. Terminal de télécommunication comportant un circuit de traitement pour la mise en œuvre du procédé selon l’une des revendications 1 à 10.