FR3038182A1 - Changement optimise de terminal, en cours d'appel - Google Patents

Changement optimise de terminal, en cours d'appel Download PDF

Info

Publication number
FR3038182A1
FR3038182A1 FR1563231A FR1563231A FR3038182A1 FR 3038182 A1 FR3038182 A1 FR 3038182A1 FR 1563231 A FR1563231 A FR 1563231A FR 1563231 A FR1563231 A FR 1563231A FR 3038182 A1 FR3038182 A1 FR 3038182A1
Authority
FR
France
Prior art keywords
terminals
terminal
sent
data stream
database
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.)
Withdrawn
Application number
FR1563231A
Other languages
English (en)
Inventor
Laurent Marchou
Cecile Batel
Fabrice Fauchoux
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR1563231A priority Critical patent/FR3038182A1/fr
Publication of FR3038182A1 publication Critical patent/FR3038182A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42229—Personal communication services, i.e. services related to one subscriber independent of his terminal and/or location
    • H04M3/42263—Personal communication services, i.e. services related to one subscriber independent of his terminal and/or location where the same subscriber uses different terminals, i.e. nomadism
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures
    • H04L65/1089—In-session procedures by adding media; by removing media
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures
    • H04L65/1093—In-session procedures by adding participants; by removing participants
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures
    • H04L65/1094—Inter-user-equipment sessions transfer or sharing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/401—Support for services or applications wherein the services involve a main real-time session and one or more additional parallel real-time or time sensitive sessions, e.g. white board sharing or spawning of a subconference
    • H04L65/4015—Support for services or applications wherein the services involve a main real-time session and one or more additional parallel real-time or time sensitive sessions, e.g. white board sharing or spawning of a subconference where at least one of the additional parallel sessions is real time or time sensitive, e.g. white board sharing, collaboration or spawning of a subconference
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/0024—Services and arrangements where telephone services are combined with data services
    • H04M7/0039—Services and arrangements where telephone services are combined with data services where the data service is provided by a stream of packets which are rendered in real time by the receiving terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/20—Aspects of automatic or semi-automatic exchanges related to features of supplementary services
    • H04M2203/2011—Service processing based on information specified by a party before or during a call, e.g. information, tone or routing selection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/20—Aspects of automatic or semi-automatic exchanges related to features of supplementary services
    • H04M2203/2033—Call handling or answering restrictions, e.g. specified by the calling party

Abstract

L'invention concerne la gestion d'une communication d'au moins un flux de données entre un premier terminal (T1) d'un utilisateur (U1) émetteur du flux et un second terminal d'un utilisateur récepteur du flux, pendant un appel en cours entre le premier terminal et le second terminal. En particulier, l'utilisateur récepteur est associé dans une base de données (DB) à une pluralité de seconds terminaux (T2, T2a, T2b). La base de données répertorie en outre, pour chacun des seconds terminaux, une capacité à gérer ou non différents types de flux de données reçus. Pour la transmission d'un ou plusieurs types de flux de données à envoyer par l'utilisateur émetteur (U1) : - on retrouve dans la base de données la pluralité de seconds terminaux associés au récepteur, - on détermine, pour chaque type de flux de données à envoyer, un ou plusieurs terminaux sélectionnés parmi la pluralité des seconds terminaux du récepteur, et capables de gérer chacun au moins un desdits types de flux de données à envoyer, et - on obtient auprès du premier terminal une indication des seconds terminaux sélectionnés, pour un envoi ciblé par le premier terminal, de chaque flux de données à envoyer à un desdits seconds terminaux sélectionnés.

Description

Changement optimisé de terminal, en cours d'appel La présente invention concerne le choix d'un terminal, en cours d'appel, optimisé pour poursuivre l'appel en cours avec une transmission souhaitée de flux particuliers de données.
Les utilisateurs des dispositifs de communication habituels rencontrent souvent des problèmes d'interopérabilité entre dispositifs. Leur environnement comporte une multitude d'objets connectés capables d'offrir une meilleure expérience de communication (dans le sens du ressenti au niveau de l'interface proposée à l'utilisateur). Typiquement, ces dispositifs (appelés ci-après « terminaux ») sont équipés d'écrans, de caméras, de microphones connectés, de haut- parleurs, etc., enrichissant l'interface utilisateur. Toutefois, comme ces solutions de communication sont proposées par différents terminaux et différents fournisseurs de services, il est difficile d'aménager une compatibilité offrant un service de qualité. De plus, chaque fabricant de terminal développe ses propres applications d'interface (ou APIs pour « Application Program Interface ») et les implémente dans son terminal, sans garantir une interopérabilité ultérieure. De plus en plus d'utilisateurs communiquent via des terminaux tels que des Smartphones, des ordinateurs connectés (notamment des ordinateurs portables), des caméras de sécurité, des robots, etc. Toutefois, une fois qu'un utilisateur a acheté initialement l'un de ces terminaux à un fabricant, il est enclin à acheter d'autres types de terminal à ce même fabricant pour qu'ils demeurent compatibles avec son terminal initial.
L'invention vient améliorer cette situation. Elle propose à cet effet un procédé de gestion d'une communication d'au moins un flux de données entre un premier terminal d'un utilisateur émetteur du flux et un second terminal d'un utilisateur récepteur du flux. En particulier, le procédé est mis en oeuvre pendant un appel en cours entre le premier terminal et le second terminal, précités. L'utilisateur récepteur est, au sens de l'invention, associé dans une base de données à une pluralité de seconds terminaux, et la base de données répertorie en outre, pour chacun des seconds terminaux, une capacité à gérer ou non différents types de flux de données reçus.
3038182 2 Le procédé comprend alors, pour la transmission d'un ou plusieurs types de flux de données à envoyer par l'utilisateur émetteur, les étapes : - retrouver dans la base de données la pluralité de seconds terminaux associés au récepteur, - déterminer, pour chaque type de flux de données à envoyer, un ou plusieurs terminaux 5 sélectionnés parmi la pluralité des seconds terminaux du récepteur, et capables de gérer chacun au moins un desdits types de flux de données à envoyer, et - obtenir auprès du premier terminal une indication des seconds terminaux sélectionnés, pour un envoi ciblé par le premier terminal, de chaque flux de données à envoyer à un desdits seconds terminaux sélectionnés.
10 Ainsi, l'utilisateur du premier terminal (ou son terminal) peut déterminer déjà si les seconds terminaux précités peuvent supporter les flux qu'il compte envoyer, et éventuellement ensuite, choisir parmi ces seconds terminaux ceux qui recevront effectivement les flux, et ce en cours d'appel. Un tel procédé assure alors une fluidité de la communication dès lors que la 15 compatibilité entre les différents terminaux communicants est vérifiée pour tout type de flux à envoyer. On peut prévoir alors une plateforme de médiation connectée à la base de données précitée.
20 Ainsi, dans une première forme de réalisation: - pendant un appel en cours entre le premier terminal et le deuxième terminal, le premier terminal transmet, à cette plateforme de médiation connectée à ladite base de données, une requête comportant au moins un identifiant du récepteur et les types de flux de données à envoyer, 25 - par consultation de la base de données, ladite plateforme de médiation sélectionne pour chaque type de flux de données à envoyer, lesdits seconds terminaux capables de gérer chacun au moins un desdits types de flux de données, et - la plateforme de médiation transmet cette sélection au premier terminal pour l'envoi ciblé précité.
30 Dans cette première forme de réalisation, le premier terminal joue un rôle relativement passif par rapport à une deuxième forme de réalisation, alternative, présentée ci-après.
3038182 3 Dans cette deuxième forme de réalisation : - pendant un appel en cours entre le premier terminal et le deuxième terminal, le premier terminal transmet, à la plateforme de médiation, une requête comportant au moins un identifiant du récepteur, 5 - par consultation de la base de données, ladite plateforme de médiation détermine une liste des seconds terminaux à disposition du récepteur, et transmet ladite liste au premier terminal, et - sur réception de la liste, le premier terminal sélectionne pour chaque type de flux de données à envoyer, les seconds terminaux capables de gérer chacun au moins l'un des types de flux de données, pour l'envoi ciblé précité.
10 Dans cette réalisation, le premier terminal joue donc un rôle actif dans la mesure où il sélectionne lui-même les seconds terminaux qui sont les plus appropriés aux types de flux à envoyer.
15 Comme indiqué précédemment, l'utilisateur du terminal émetteur peut contribuer aussi à choisir les seconds terminaux qui recevront les flux. Ainsi, dans une telle réalisation, le premier terminal peut mettre en oeuvre les étapes: - à partir de l'indication précitée des seconds terminaux sélectionnés, générer un message 20 d'IHM (pour « interface homme machine ») sur le premier terminal, comprenant pour chaque type de flux de données à envoyer, une invitation de l'utilisateur émetteur, à choisir un ou plusieurs seconds terminaux parmi les seconds terminaux sélectionnés, et - sur réponse via l'IHM de l'émetteur, comportant une indication du ou des seconds terminaux choisis par l'émetteur, opérer la transmission des flux de données auxdits terminaux choisis.
25 Dans la définition ci-dessus, il convient d'indiquer que l'on entend par « capacité » d'un terminal à gérer un flux, de façon large, aussi bien le fait qu'un terminal dispose des applications disponibles pour gérer ce flux, que sa disponibilité et notamment sa connexion au réseau.
30 Ainsi par exemple, dans une réalisation, les seconds terminaux précités, capables de gérer chacun au moins un desdits types de flux de données, sont testés pour déterminer leur disponibilité, et les terminaux testés comme étant disponibles sont sélectionnés.
3038182 4 Dans un mode de réalisation, la base de données répertorie en outre, pour chacun desdits seconds terminaux, une capacité à gérer ou non différents types de flux de données, à la fois reçus et à émettre. Le procédé comprend alors les étapes, pendant un appel en cours impliquant la transmission par le premier terminal d'un ou plusieurs types de flux de données à envoyer et 5 prévoyant un ou plusieurs types de flux de données à recevoir en retour, auprès du premier terminal: - retrouver dans la base de données la pluralité de seconds terminaux associés à l'utilisateur récepteur, - déterminer, pour chaque type de flux de données à envoyer et à recevoir pour le premier 10 terminal, un ou plusieurs terminaux parmi lesdits seconds terminaux, et capables de gérer chacun au moins un desdits types de flux de données en réception et en émission, et - obtenir auprès du premier terminal une indication des seconds terminaux sélectionnés, pour un envoi ciblé par le premier terminal, de chaque flux de données à envoyer à un desdits seconds terminaux sélectionnés (avec une attente de flux à recevoir en retour).
15 Ainsi, dans une telle réalisation, il est possible de sélectionner non seulement les seconds terminaux capables de gérer les flux reçus du premier terminal, mais aussi, parmi cette sélection, ceux capables de gérer en outre l'envoi de flux de données, en réponse aux flux reçus. Par exemple, une télévision connectée peut gérer des flux (vidéo et audio) en réception 20 mais, en général, n'a pas de moyen de gestion de flux à envoyer. En revanche, une tablette ou un smartphone peuvent assurer les deux fonctionnalités. L'invention vise aussi un programme informatique comportant des instructions pour la mise en oeuvre du procédé ci-avant, lorsque ce programme est exécuté par un processeur.
25 Ce processeur peut être celui d'une plateforme de médiation pour la gestion d'un changement de terminal (parmi les seconds terminaux) en cours d'appel, selon la première forme de réalisation du procédé, présentée ci-avant.
30 A ce titre, l'invention vise aussi une telle plateforme de médiation pour la gestion d'une communication d'au moins un flux de données entre un premier terminal d'un utilisateur émetteur du flux et un second terminal d'un utilisateur récepteur du flux. La plateforme comporte une base de données d'utilisateurs récepteurs en correspondance de seconds 3038182 5 terminaux à disposition de chaque récepteur. Cette base de données répertorie en outre, pour chacun desdits seconds terminaux, une capacité à gérer ou non différents types de flux de données reçus. Plus particulièrement, la plateforme comporte en outre un circuit informatique, pour la transmission d'un ou plusieurs types de flux de données à envoyer, le circuit 5 informatique étant programmé pour, pendant un appel en cours entre le premier terminal et le second terminal : - retrouver dans la base de données la pluralité de seconds terminaux associés au récepteur, - déterminer, pour chaque type de flux de données à envoyer, un ou plusieurs terminaux sélectionnés parmi la pluralité des seconds terminaux du récepteur, et capables de gérer chacun 10 au moins un desdits types de flux de données, et - envoyer au premier terminal une indication des seconds terminaux sélectionnés, pour un envoi ciblé par le premier terminal, de chaque flux de données à envoyer à un desdits seconds terminaux sélectionnés.
15 L'invention vise aussi un terminal émetteur d'au moins un flux de données destiné à être envoyé à un second terminal, à disposition d'un utilisateur récepteur. Le terminal émetteur est connecté à une base de données d'utilisateurs récepteurs en correspondance de seconds terminaux à disposition de chaque récepteur. La base de données répertorie en outre, pour chacun desdits seconds terminaux, une capacité à gérer ou non différents types de flux de 20 données reçus. En particulier, le terminal émetteur comporte un circuit informatique programmé, pour la transmission d'un ou plusieurs types de flux de données à envoyer pendant un appel en cours entre le terminal émetteur et le second terminal, pour : - retrouver dans la base de données la pluralité de seconds terminaux associés à l'utilisateur récepteur, 25 - déterminer, pour chaque type de flux de données à envoyer, un ou plusieurs terminaux sélectionnés parmi la pluralité des seconds terminaux de l'émetteur, et capables de gérer chacun au moins un desdits types de flux de données, et - obtenir une indication des seconds terminaux sélectionnés, pour un envoi ciblé par le terminal émetteur, de chaque flux de données à envoyer à un desdits seconds terminaux sélectionnés.
30 D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés sur lesquels : 3038182 6 - la figure 1 illustre un exemple de réalisation d'une plateforme coopérant selon l'invention avec un premier terminal du type précité, envoyant un flux de données particulier (par exemple un flux vidéo pendant un appel vocal en cours); 5 - la figure 2 illustre les échanges entre les différentes entités de la figure 1, dans un exemple de réalisation ; - la figure 3 représente schématiquement un exemple de réalisation d'une plateforme au sens de l'invention ; - la figure 4 représente schématiquement un exemple de réalisation d'un premier 10 terminal du type précité, au sens de l'invention. L'invention, décrite ci-après en lien avec une forme de réalisation présentée à titre d'exemple, propose une plateforme offrant une solution concentrée pour des terminaux communicants multiples, fabriqués typiquement par différents fournisseurs. L'approche de l'invention est 15 basée sur une gestion et une analyse en temps réel des flux de données transitant par la plateforme, ces flux de données utilisant en particulier un signal pilote. En référence à la figure 1, lorsque l'utilisateur d'un terminal T1 (terminal nommé « premier terminal » ci-après) souhaite envoyer un ou plusieurs flux particuliers de données (vidéo 20 pendant un simple appel vocal en cours par exemple), la plateforme de médiation PF est en mesure de présélectionner chacun des terminaux destinataires capables de gérer ces flux (terminaux nommés « seconds terminaux » ci-après), afin de réaliser toutes les actions possibles qu'offre l'ensemble de ces terminaux (lire un flux vidéo, ou audio, ou passer un appel de voix, ou filmer une scène, ou capter un flux audio, etc.).
25 La plateforme cible alors vers quel second terminal ou quels seconds terminaux (par exemple T2, T2a) le premier terminal Ti peut envoyer le ou les flux. A cet effet, chaque utilisateur des seconds terminaux précités enregistre auprès de la 30 plateforme ses différents terminaux communicants, ainsi que leurs possibilités à recevoir certains flux (flux vidéo, flux audio, flux de commandes, etc.). Ainsi par exemple, un smartphone est capable de gérer a minima un double flux vidéo et audio. Dans un autre 3038182 7 exemple, un terminal de type robot de télé-présence (par exemple « Ub-y ») est capable de gérer un flux vidéo, audio et des commandes (pour le diriger et le déplacer, typiquement). Ainsi, au cours d'un appel, si l'utilisateur du premier terminal Ti souhaite envoyer un flux 5 particulier, le premier terminal se connecte à une plateforme de médiation PF, laquelle tient à jour une base de données DB des terminaux T2, T2a, T2b (par exemple un smartphone T2, un ordinateur T2a, une chaîne Hifi connectée T2b, ou encore une télévision connectée, un robot, etc.), à disposition du destinataire de flux. Par exemple, les utilisateurs dont les terminaux sont répertoriés dans la base de données DB peuvent être abonnés à un service mettant en oeuvre la 10 plateforme, afin d'offrir à leurs correspondants un choix approprié des terminaux capables de recevoir les différents types de flux de données. Dans l'exemple représenté, la requête REQ communiquée du premier terminal Ti à la plateforme PF comporte un identifiant de l'utilisateur des seconds terminaux (tel que son 15 numéro d'abonné, le numéro IMSI typiquement) de sorte que la plateforme peut retrouver dans la base de données DB les différents seconds terminaux, ainsi que leur adresse IP par exemple, pour recevoir les différents flux issus du premier terminal. Ces terminaux T2, T2a, T2b peuvent être reliés par exemple à une passerelle commune animant un réseau local. Ainsi, par interrogation via la passerelle, la plateforme est en mesure en outre de déterminer les 20 terminaux T2, T2a, T2b connectés au réseau RES et disponibles pour recevoir les flux. Ensuite, la plateforme renvoie au premier terminal Ti une liste LST des terminaux disponibles pour recevoir les flux. L'utilisateur du premier terminal peut alors choisir via l'IHM (pour « interface homme machine ») de son terminal T1 les seconds terminaux de son correspondant convenant pour recevoir les flux qu'il souhaite envoyer.
25 Ces étapes sont détaillées ci-après en référence à la figure 2. L'utilisateur Ul utilise l'IHM de son terminal Ti pour signifier son souhait AP de d'envoyer un ou des flux particuliers pendant l'appel. En fonction des flux à envoyer TF (visioconférence, ou commande d'un robot, ou autres, à la suite d'un appel vocal simple), le terminal Ti analyse les différents types de flux à 30 envoyer et élabore une requête REQ contenant, a minima, l'identifiant de l'utilisateur récepteur. Cette requête REQ est envoyée à la plateforme PF, laquelle retrouve dans sa base de données DB les terminaux T2, T2a, T2b à disposition de l'utilisateur récepteur et élabore ensuite une liste LST de ces terminaux, pour la transmettre au terminal T1. Dans une première 3038182 8 forme de réalisation, la requête REQ présente en outre les différents types de flux à envoyer et la plateforme PF sélectionne les terminaux (T2, T2a par exemple) qui sont les plus appropriés pour recevoir ces flux. Ainsi, la liste LST comporte déjà une sélection des terminaux appropriés pour recevoir les flux.
5 Dans une variante, la plateforme PF n'effectue aucune présélection et envoie la liste de tous les seconds terminaux qui sont disponibles. En revanche, le terminal Ti sélectionne dans cette liste LST les terminaux les plus appropriés en fonction du type de flux de données à envoyer.
10 Dans l'un ou l'autre mode de réalisation, le terminal Ti est alors en mesure de présenter à l'utilisateur Ul du premier terminal Ti, via l'IHM, une sélection SEL (flèche en traits pointillés sur la figure 2, correspondant à ce deuxième mode de réalisation) des seconds terminaux capables de recevoir les flux à envoyer. Il s'affiche alors sur l'IHM du terminal Ti par exemple, un message d'indication de ces seconds terminaux sélectionnés, afin que 15 l'utilisateur Ul puisse effectuer un choix CHX parmi ces terminaux. Le terminal Ti, recevant ce choix, peut ensuite appliquer le choix de l'utilisateur Ul (flèche APP) et orienter les flux à envoyer vers les terminaux choisis en utilisant leur adresse IP. On comprendra alors que la liste LST que renvoie la plateforme peut comprendre en particulier les identifiants (par exemple les adresses IP) des terminaux capables de gérer les flux à envoyer.
20 Ainsi, pendant un appel en cours, entre le premier terminal Ti et un terminal T2 faisant partie des seconds terminaux du correspondant, l'utilisateur Ul peut souhaiter envoyer un type de flux particulier (par exemple de la vidéo) sur un terminal T2a, différent du terminal T2 en cours d'appel (par exemple pour envoyer un flux vidéo sur un écran de plus grande taille que 25 celui d'un smartphone). Il entre ce souhait via l'IHM (flèche AP) et le premier terminal Ti envoie une requête correspondante REQ vers la plateforme de médiation PF afin de retrouver pour le correspondant de l'utilisateur Ul, les terminaux enregistrés et recensés pour recevoir différents flux. Le choix de l'utilisateur Ul peut s'effectuer: 30 en fonction des flux qu'il a pu déclarer à la plateforme via son terminal, mais aussi possiblement en fonction des capacités du terminal Ti lui-même, s'il est capable en particulier de gérer ensuite un ou plusieurs flux particuliers ensuite.
3038182 9 La plateforme PF peut donc aussi effectuer un premier filtre des terminaux du correspondant récepteur des flux, en fonction déjà des capacités de communication du terminal T1 de l'émetteur, lui-même.
5 En réponse à la requête, l'utilisateur du premier terminal Ti reçoit sur un terminal de son choix (par exemple le terminal sur lequel il entend poursuivre l'appel, par exemple son smartphone Ti) un message généré par ce terminal choisi Ti sur son IHM et présentant les différents types de flux à communiquer et les différents terminaux du correspondant supportant ces flux. Il peut alors choisir via son IHM vers quel terminal ou quels terminaux T2, T2a, T2b il envoie 10 le ou les flux. Dans le cas de plusieurs flux différents à envoyer (audio, vidéo, etc.), il peut choisir via l'IHM vers quels terminaux T2a, T2b répartir l'appel en cours (par exemple le terminal T2a pour la vidéo, et le terminal T2b pour l'audio). En outre, en fonction de la suite de l'appel qu'anticipe l'utilisateur du premier terminal Ti, il est possible qu'un des seconds terminaux du correspondant ait à renvoyer un flux particulier (par exemple des flux vidéo et 15 audio, pour une tablette ou un smartphone, alors qu'une télévision connectée ou une enceinte connectée, par exemple, ne sont pas, en général, capables de renvoyer de tels flux). Dans ce cas, l'utilisateur Ul peut en outre sélectionner lui-même (en fonction des données de la plateforme de médiation) le terminal T2a (ici un ordinateur) qui convient pour renvoyer des flux attendus.
20 Dans une première forme de réalisation, la requête de l'utilisateur Ul vers la plateforme comporte à la fois l'identifiant (IMSI par exemple) du correspondant et les capacités du premier terminal Ti en termes de flux et types de flux à communiquer. En fonction des terminaux enregistrés et disponibles pour le correspondant, la plateforme analyse les 25 différentes combinaisons possibles et retourne un message à l'utilisateur Ul via l'IHM de son terminal Ti pour que l'utilisateur Ul choisisse la répartition des flux de l'appel en cours auprès des seconds terminaux. On a illustré sur la figure 3 une plateforme PF convenant pour cette première forme de 30 réalisation et comprenant typiquement un circuit qui peut par exemple être équipé de: - un processeur PROC coopérant avec une mémoire MEM (incluant par exemple une unité de mémoire de travail pour le stockage de données temporaires, ainsi qu'une unité de mémoire de stockage de données permanentes, comme par exemple les instructions d'un programme 3038182 10 d'ordinateur au sens de l'invention, et/ou directement le contenu de la base de données DB des seconds terminaux des correspondants), et - une interface de communication COM (via le réseau de communication RES, par exemple Internet) : 5 * avec les terminaux (Ti notamment) et, * dans le cas où la mémoire MEM ne stocke pas directement la base de données DB, une connexion vers une mémoire la stockant. En particulier, dans cette réalisation, la plateforme exécute une routine (le programme informatique précité) pour déterminer, en fonction des différents types de flux à envoyer, les 10 seconds terminaux du correspondant qui sont capables de gérer ces flux (par exemple un smartphone ou un ordinateur pour une visioconférence, un robot pour la transmission de flux comportant des commandes, etc.). Dans une variante, la requête de l'utilisateur Ul (via son terminal Ti) ne comporte que 15 l'identifiant du correspondant. Les capacités du terminal Ti ne sont pas nécessaires. Toutes les données sur les capacités des terminaux du correspondant T2, T2a, T2b, sont alors transmises au premier terminal Ti. Le premier terminal exécute alors une routine d'analyse des combinaisons possibles pour générer le message via l'IHM à destination de l'utilisateur Ul pour que l'utilisateur choisisse la meilleure répartition des flux de son appel en cours.
20 On a illustré sur la figure 4 un terminal T1 (du type « premier terminal » précité) convenant pour cette deuxième forme de réalisation et comprenant typiquement un circuit qui peut par exemple être équipé de: - un processeur PROC coopérant avec une mémoire MEM (incluant par exemple une unité de 25 mémoire de travail pour le stockage de données temporaires, ainsi qu'une unité de mémoire de stockage de données permanentes, comme par exemple les instructions d'un programme d'ordinateur au sens de l'invention, et/ou directement le contenu d'une base de données DB2 donnant, en fonction de modèles de terminaux de correspondants, les flux que ces derniers sont capables de gérer), et 30 - bien entendu une interface de communication COM (via le réseau de communication RES, par exemple Internet), notamment avec la plateforme PF (pour recevoir simplement la liste des seconds terminaux précités, avec leur adresse IP par exemple).
3038182 11 En particulier, dans cette réalisation, le terminal Ti exécute, avec l'appui de la base DB2, une routine (le programme informatique précité) pour déterminer, en fonction des différents types de flux composant la suite de l'appel, les terminaux du correspondant qui sont capables de gérer ces flux (par exemple un smartphone ou un ordinateur pour un appel de type 5 visioconférence, un robot pour un appel comportant des commandes, etc.). Bien entendu, la présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d'exemple ; elle s'étend à d'autres variantes.
10 Ainsi par exemple, la base de données des modèles de terminaux DB2 peut être intégrée dans la base DB que gère la plateforme PF dans le premier mode de réalisation précité. Néanmoins, dans une réalisation où la plateforme PF interroge en outre les terminaux du correspondant pour déterminer leur disponibilité (connexion au réseau notamment), la plateforme PF peut directement récupérer ces données de modèles des terminaux en réponse à cette interrogation, 15 et déterminer ainsi les terminaux capables de gérer les différents types de flux. On comprendra ainsi que la base des données répertoriant (outre les terminaux du correspondant) la capacité de ces terminaux à gérer ou non différents types de flux de données reçus, peut : 20 - être concentrée dans une base unique DB (selon la figure 3) pour la mise en oeuvre du premier mode de réalisation, ou - être distribuée entre la base DB2 des modèles de terminaux en correspondance de leur capacité à gérer les flux (connectée ou intégrée au terminal Ti selon la figure 4), et la base générale des seconds terminaux DB (connectée ou intégrée à 25 la plateforme PF). Par ailleurs, un utilisateur des seconds terminaux précités peut par exemple contrôler les données que stocke la base de données. Par exemple, la base de données peut aussi gérer des autorisations d'accès à ses terminaux, en fonction des données du correspondant (en fonction 30 de son IMSI par exemple). Dans une forme de réalisation, on peut prévoir par exemple qu'un correspondant Ul dans le cercle proche de l'utilisateur des seconds terminaux a accès à tous ces terminaux T2, T2a, T2b, alors qu'un correspondant « inconnu » (non identifié dans ce cercle proche) n'a pas accès par défaut à tous ces terminaux (seulement au smartphone T2 par 3038182 12 exemple). Par exemple, ce « cercle de proches » peut être déclaré à la plateforme de médiation, initialement (ou au gré de l'utilisation) par l'utilisateur des seconds terminaux, en fournissant leur identifiant IMSI par exemple.

Claims (9)

  1. REVENDICATIONS1. Procédé de gestion d'une communication d'au moins un flux de données entre un premier terminal d'un utilisateur émetteur du flux et un second terminal d'un utilisateur récepteur du flux, le procédé étant mis en oeuvre pendant un appel en cours entre le premier terminal et le second terminal, procédé dans lequel l'utilisateur récepteur est associé dans une base de données à une pluralité de seconds terminaux, la base de données répertoriant en outre, pour chacun desdits seconds terminaux, une capacité à gérer ou non différents types de flux de données reçus, le procédé comprenant, pour la transmission d'un ou plusieurs types de flux de données à envoyer par l'utilisateur émetteur : - retrouver dans la base de données la pluralité de seconds terminaux associés au récepteur, - déterminer, pour chaque type de flux de données à envoyer, un ou plusieurs terminaux sélectionnés parmi la pluralité des seconds terminaux du récepteur, et capables de gérer chacun au moins un desdits types de flux de données à envoyer, et - obtenir auprès du premier terminal une indication des seconds terminaux sélectionnés, pour un envoi ciblé par le premier terminal, de chaque flux de données à envoyer à un desdits seconds terminaux sélectionnés.
  2. 2. Procédé selon la revendication 1, dans lequel : - pendant un appel en cours entre le premier terminal et le deuxième terminal, le premier terminal transmet, à une plateforme de médiation connectée à ladite base de données, une requête comportant au moins un identifiant du récepteur et les types de flux de données à envoyer, - par consultation de la base de données, ladite plateforme de médiation sélectionne pour chaque type de flux de données à envoyer, lesdits seconds terminaux capables de gérer chacun au moins un desdits types de flux de données, et - la plateforme de médiation transmet ladite sélection au premier terminal pour ledit envoi ciblé.
  3. 3. Procédé selon la revendication 1, dans lequel : 3038182 14 - pendant un appel en cours entre le premier terminal et le deuxième terminal, le premier terminal transmet, à une plateforme de médiation connectée à ladite base de données, une requête comportant au moins un identifiant du récepteur, - par consultation de la base de données, ladite plateforme de médiation détermine une liste des 5 seconds terminaux à disposition du récepteur, et transmet ladite liste au premier terminal, et - sur réception de ladite liste, le premier terminal sélectionne pour chaque type de flux de données à envoyer, lesdits seconds terminaux capables de gérer chacun au moins un desdits types de flux de données, pour ledit envoi ciblé. 10
  4. 4. Procédé selon l'une des revendications précédentes, comportant en outre les étapes mises en oeuvre par le premier terminal : - à partir de ladite indication des seconds terminaux sélectionnés, générer un message d'IHM sur le premier terminal, comprenant pour chaque type de flux de données à envoyer, une invitation de l'utilisateur émetteur, à choisir un ou plusieurs seconds terminaux parmi les 15 seconds terminaux sélectionnés, et - sur réponse via l'IHM de l'émetteur, comportant une indication du ou des seconds terminaux choisis par l'émetteur, opérer la transmission des flux de données auxdits terminaux choisis.
  5. 5. Procédé selon l'une des revendications précédentes, dans lequel lesdits seconds terminaux 20 capables de gérer chacun au moins un desdits types de flux de données sont testés pour déterminer leur disponibilité, et les terminaux testés comme étant disponibles sont sélectionnés.
  6. 6. Procédé selon l'une des revendications précédentes, dans lequel la base de données 25 répertorie en outre, pour chacun desdits seconds terminaux, une capacité à gérer ou non différents types de flux de données, à la fois reçus et à émettre, le procédé comprenant, pendant un appel en cours impliquant la transmission par le premier terminal d'un ou plusieurs types de flux de données à envoyer et prévoyant un ou plusieurs types de flux de données à recevoir en retour, auprès du premier terminal: 30 - retrouver dans la base de données la pluralité de seconds terminaux associés à l'utilisateur récepteur, 3038182 15 - déterminer, pour chaque type de flux de données à envoyer et à recevoir pour le premier terminal, un ou plusieurs terminaux parmi lesdits seconds terminaux, et capables de gérer chacun au moins un desdits types de flux de données en réception et en émission, et - obtenir auprès du premier terminal une indication des seconds terminaux sélectionnés, pour 5 un envoi ciblé par le premier terminal, de chaque flux de données à envoyer à un desdits seconds terminaux sélectionnés.
  7. 7. Programme informatique caractérisé en ce qu'il comporte des instructions pour la mise en oeuvre du procédé selon l'une des revendications précédentes, lorsque ce programme est 10 exécuté par un processeur.
  8. 8. Plateforme de médiation pour la gestion d'une communication d'au moins un flux de données entre un premier terminal d'un utilisateur émetteur du flux et un second terminal d'un utilisateur récepteur du flux, 15 la plateforme comportant une base de données d'utilisateurs récepteurs en correspondance de seconds terminaux à disposition de chaque récepteur, la base de données répertoriant en outre, pour chacun desdits seconds terminaux, une capacité à gérer ou non différents types de flux de données reçus, la plateforme comportant en outre un circuit informatique, pour la transmission d'un ou 20 plusieurs types de flux de données à envoyer, le circuit informatique étant programmé pour, pendant un appel en cours entre le premier terminal et le second terminal : - retrouver dans la base de données la pluralité de seconds terminaux associés au récepteur, - déterminer, pour chaque type de flux de données à envoyer, un ou plusieurs terminaux sélectionnés parmi la pluralité des seconds terminaux du récepteur, et capables de gérer chacun 25 au moins un desdits types de flux de données, et - envoyer au premier terminal une indication des seconds terminaux sélectionnés, pour un envoi ciblé par le premier terminal, de chaque flux de données à envoyer à un desdits seconds terminaux sélectionnés. 30
  9. 9. Terminal émetteur d'au moins un flux de données destiné à être envoyé à un second terminal, à disposition d'un utilisateur récepteur, le terminal émetteur étant connecté à une base de données d'utilisateurs récepteurs en correspondance de seconds terminaux à disposition de chaque récepteur, 3038182 16 la base de données répertoriant en outre, pour chacun desdits seconds terminaux, une capacité à gérer ou non différents types de flux de données reçus, le terminal émetteur comportant un circuit informatique programmé, pour la transmission d'un ou plusieurs types de flux de données à envoyer pendant un appel en cours entre le terminal 5 émetteur et le second terminal, pour : - retrouver dans la base de données la pluralité de seconds terminaux associés à l'utilisateur récepteur, - déterminer, pour chaque type de flux de données à envoyer, un ou plusieurs terminaux sélectionnés parmi la pluralité des seconds terminaux de l'émetteur, et capables de gérer 10 chacun au moins un desdits types de flux de données, et - obtenir une indication des seconds terminaux sélectionnés, pour un envoi ciblé par le terminal émetteur, de chaque flux de données à envoyer à un desdits seconds terminaux sélectionnés.
FR1563231A 2015-12-23 2015-12-23 Changement optimise de terminal, en cours d'appel Withdrawn FR3038182A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1563231A FR3038182A1 (fr) 2015-12-23 2015-12-23 Changement optimise de terminal, en cours d'appel

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1563231A FR3038182A1 (fr) 2015-12-23 2015-12-23 Changement optimise de terminal, en cours d'appel

Publications (1)

Publication Number Publication Date
FR3038182A1 true FR3038182A1 (fr) 2016-12-30

Family

ID=55650470

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1563231A Withdrawn FR3038182A1 (fr) 2015-12-23 2015-12-23 Changement optimise de terminal, en cours d'appel

Country Status (1)

Country Link
FR (1) FR3038182A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080062253A1 (en) * 2006-09-11 2008-03-13 Gary Jaspersohn Fallback mobile communication
US20100022229A1 (en) * 2008-07-28 2010-01-28 Alcatel-Lucent Via The Electronic Patent Assignment System (Epas) Method for communicating, a related system for communicating and a related transforming part
WO2014008113A1 (fr) * 2012-07-06 2014-01-09 Cisco Technology, Inc. Traitement des appels vidéo entrants destinés à un groupe de recherche
US20140359139A1 (en) * 2013-05-31 2014-12-04 Vonage Network Llc Method and apparatus for transferring active communication session streams between devices

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080062253A1 (en) * 2006-09-11 2008-03-13 Gary Jaspersohn Fallback mobile communication
US20100022229A1 (en) * 2008-07-28 2010-01-28 Alcatel-Lucent Via The Electronic Patent Assignment System (Epas) Method for communicating, a related system for communicating and a related transforming part
WO2014008113A1 (fr) * 2012-07-06 2014-01-09 Cisco Technology, Inc. Traitement des appels vidéo entrants destinés à un groupe de recherche
US20140359139A1 (en) * 2013-05-31 2014-12-04 Vonage Network Llc Method and apparatus for transferring active communication session streams between devices

Similar Documents

Publication Publication Date Title
US7961212B2 (en) Video messaging system
EP3694146B1 (fr) Procédé de traitement de flux audiovidéo en conférence multipartite, dispositifs, système et programme correspondants
EP3087706B1 (fr) Procédé et système de communication entre navigateurs web, utilisant un environnement de communication unifiée
FR3064437A1 (fr) Procede de recommandation d'une pile de communication
EP2882161A1 (fr) Procédé et dispositf d' établissement d'une communication
US20120124137A1 (en) System, Method and Apparatus for Enhanced Processing of Communication In a Peer-To-Peer Network
EP2005710B1 (fr) Procede et systeme de gestion dynamique de transmission de flux au sein d'une pluralite de terminaux
EP3461135A1 (fr) Procédé de gestion du droit d'accès à un contenu numérique
EP2589202B1 (fr) Procédé et système de gestion de sessions de communication
FR3038182A1 (fr) Changement optimise de terminal, en cours d'appel
EP3688974B1 (fr) Procédé de gestion d'un échec d'établissement d'une communication entre un premier et un second terminal
WO2017109314A1 (fr) Choix d'un terminal appelé, optimisé pour l'établissement d'un appel
EP3472993B1 (fr) Procédé de détermination d'un ensemble de formats de codage pour établir une communication
WO2007077402A2 (fr) Procede et dispositif de gestion des communications personnelles d'au moins un utilisateur
EP2858327B1 (fr) Procédé de mise en oeuvre d'une session de communication entre une pluralité de terminaux
FR3018027A1 (fr) Procede et dispositif de decouverte des capacites de communication relatives a un utilisateur d'un terminal
WO2011124810A1 (fr) Gestion de service personnalisee dans un reseau ip
FR3060926B1 (fr) Systeme, ensemble et procede d'interphonie
FR3091099A1 (fr) Processus de déclaration de non-exploitabilité de données échangées
FR3033222A1 (fr) Procede de partage d'au moins un flux audio et/ou video lors d'un appel telephonique, terminal, procede de traitement, equipement, produits programme d'ordinateur et supports de stockage correspondants
FR2979505A1 (fr) Procede d'insertion d'un equipement intermediaire permettant le controle a distance de la qualite d'une communication
FR3000337A1 (fr) Procede de gestion des renvois d'appel dans un systeme de communication comprenant des terminaux associes a un identifiant commun
EP1989845A1 (fr) Gestion d'une communication entre un systeme de telecommunications et un serveur
FR3022725A1 (fr) Procede de gestion de la restitution de contenus numeriques
FR3044193A1 (fr) Procede et dispositif de gestion d'une communication

Legal Events

Date Code Title Description
PLSC Publication of the preliminary search report

Effective date: 20161230

ST Notification of lapse

Effective date: 20170831