La présente invention concerne le choix d'un terminal appelé, optimisé pour l'établissement d'un appel.

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'un appel d'un appelant vers un appelé, dans lequel l'appelé est associé dans une base de données à une pluralité de seconds terminaux. En particulier, cette base de données répertorie, pour chacun des seconds terminaux précités, une capacité à gérer ou non différents types de flux de données reçus. Le procédé comprend alors, pour le traitement d'un appel destiné à l'appelé et issu d'un premier terminal, un tel appel impliquant la transmission d'un ou plusieurs types de flux de données à envoyer :

- retrouver dans la base de données la pluralité de seconds terminaux associés à l'appelé, - 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 appelé, et capables de gérer chacun au moins un desdits types de flux de données, 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.

Ainsi, l'appelant (ou son terminal) peut déterminer déjà si les terminaux de l'appelé peuvent supporter les flux qu'il compte envoyer, et éventuellement ensuite, choisir parmi ces terminaux ceux qui recevront effectivement les flux. Un tel procédé assure alors une compatibilité entre les différents terminaux communicants, 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. Ainsi, dans une première forme de réalisation:

- avant établissement de l'appel, le premier terminal transmet, à cette plateforme de médiation, une requête comportant au moins un identifiant de l'appelé et les types de flux de données à envoyer,

- par consultation de la base de données, la plateforme de médiation sélectionne pour chaque type de flux de données à envoyer, des seconds terminaux capables de gérer chacun au moins un de ces 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é. 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.

Dans cette deuxième forme de réalisation :

- avant établissement de l'appel, le premier terminal transmet, à la plateforme de médiation, une requête comportant au moins un identifiant de l'appelé,

- par consultation de la base de données, la plateforme de médiation détermine une liste des seconds terminaux à disposition de l'appelé, et transmet cette 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é. Dans cette réalisation, le premier terminal joue donc un rôle actif dans la mesure où il sélectionne lui-même les terminaux de l'appelé qui sont les plus appropriés aux types de flux à envoyer.

Comme indiqué précédemment, l'utilisateur du terminal appelant peut contribuer aussi à choisir les seconds terminaux qui recevront les flux.

Ainsi, dans une telle réalisation, le premier terminal peut mettre en œuvre les étapes:

- à partir de l'indication précitée des seconds terminaux sélectionnés, générer un message d'IHM (pour « interface homme machine ») sur le premier terminal, comprenant pour chaque type de flux de données à envoyer, une invitation de l'appelant, utilisateur du premier terminal, à choisir un ou plusieurs seconds terminaux parmi les seconds terminaux sélectionnés, et

- sur réponse via ΙΗΜ de l'appelant, comportant une indication du ou des seconds terminaux choisis par l'appelant, établir l'appel avec une transmission des flux de données à ces terminaux choisis.

Dans une forme de réalisation, pour ne pas gêner l'appelant avant chaque appel, le message d'IHM précité peut comporter en outre un choix supplémentaire, d'établissement d'appel pour la transmission d'un type de flux de données par défaut (par exemple un flux relatif à une communication vocale, par défaut). Ainsi, dans ΙΗΜ qui lui proposé, après composition de l'appel, l'utilisateur du terminal appelant peut choisir par défaut d'établir l'appel pour une simple communication vocale, ou au contraire choisir d'établir l'appel en transmettant en outre un autre flux, par exemple un flux vidéo en mode de visioconférence. Dans ce dernier cas, son IHM lui indique si l'appelé dispose d'un terminal adapté à cet effet et l'invite à entrer le choix d'un tel terminal.

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.

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 en particulier les terminaux testés comme étant disponibles sont sélectionnés.

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, pour le traitement d'un appel 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:

- retrouver dans la base de données la pluralité de seconds terminaux associés à l'appelé,

- déterminer, pour chaque type de flux de données à envoyer et à recevoir pour le premier terminal, un ou plusieurs terminaux parmi la pluralité des seconds terminaux de l'appelé, 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).

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 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 œuvre du procédé ci-avant, lorsque ce programme est exécuté par un processeur.

Ce processeur peut être celui d'une plateforme de médiation pour la gestion d'un appel d'un appelant vers un appelé, selon la première forme de réalisation du procédé, présentée ci-avant. A ce titre, l'invention vise aussi une telle plateforme, comportant une base de données d'appelés en correspondance de seconds terminaux à disposition de chaque appelé. 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. En particulier, la plateforme comporte en outre un circuit informatique, pour le traitement d'un appel courant destiné à un appelé et issu d'un premier terminal, ledit appel courant impliquant la transmission d'un ou plusieurs types de flux de données à envoyer, le circuit informatique étant programmé pour :

- retrouver dans la base de données la pluralité de seconds terminaux associés à l'appelé,

- 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'appelant, et capables de gérer chacun 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.

L'invention vise aussi un terminal appelant, en particulier pour la mise en œuvre du procédé selon la deuxième forme de réalisation précitée. Ce terminal comporte un circuit informatique pour la gestion d'un appel vers un appelé, le terminal appelant étant connecté à une base de données d'appelés en correspondance de seconds terminaux à disposition de chaque appelé, 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 circuit informatique de ce terminal appelant étant programmé, pour le traitement d'un appel courant destiné à un appelé et issu du terminal appelant, ledit appel courant impliquant la transmission d'un ou plusieurs types de flux de données à envoyer, pour :

- retrouver dans la base de données la pluralité de seconds terminaux associés à l'appelé,

- 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 appelé, 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 appelant, de chaque flux de données à envoyer à un desdits seconds terminaux sélectionnés.

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 : la figure 1 illustre un exemple de réalisation d'une plateforme coopérant selon l'invention avec un terminal appelant ;

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 terminal appelant 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 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.

Lorsqu'un terminal se connecte (terminal nommé « appelant » ci-après), la plateforme de médiation est en mesure de gérer chacun des terminaux connectables à l'appelant (terminaux nommés « appelés » ci-après) et de réaliser toutes les actions possibles qu'offrent ces appelés (lire un flux vidéo, ou audio, ou passer un appel de voix, ou filmer une scène, ou capter un flux audio, etc.). Par ailleurs, un utilisateur des terminaux appelés peut choisir de prendre une communication via l'un de ses terminaux, choisi par exemple en fonction de ses capacités.

La plateforme cible alors vers quel terminal ou quels terminaux un appelant peut joindre un appelé.

A cet effet, chaque utilisateur de la plateforme enregistre 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 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). En référence à la figure 1, le terminal appelant Tl se connecte, avant de passer l'appel, à 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 de l'appelé destiné à recevoir l'appel. Par exemple, les appelés dont les terminaux sont répertoriés dans la base de données DB peuvent être abonnés à un service mettant en œuvre la plateforme, afin de faciliter pour les appelants un choix approprié des terminaux recevant l'appel et les différents types de flux associés à cet appel. Ainsi, la requête REQ communiquée du terminal appelant Tl à la plateforme PF comporte un identifiant de l'appelé (tel que son 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 terminaux, ainsi que leur adresse IP par exemple, à disposition de l'appelé pour recevoir les différents flux composant l'appel. 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 terminaux T2, T2a, T2b connectés au réseau RES et disponibles pour recevoir les flux pendant l'appel. Ensuite, la plateforme renvoie au terminal appelant Tl une liste LST des terminaux disponibles pour recevoir les flux de l'appel. L'utilisateur du terminal appelant peut alors choisir via ΙΗΜ (pour « interface homme machine ») de son terminal Tl les terminaux convenant pour recevoir l'appel.

Ces étapes sont détaillées ci-après en référence à la figure 2. L'utilisateur Ul, appelant, utilise ΙΗΜ de son terminal Tl pour signifier son souhait AP de passer un appel. En fonction du type d'appel souhaité TF (appel vocal simple, ou visioconférence, ou commande d'un robot, ou autres), le terminal Tl analyse les différents types de flux à envoyer et élabore une requête REQ contenant, a minima, l'identifiant de l'appelé. 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'appelé et élabore ensuite une liste LST de ces terminaux, pour la transmettre au terminal Tl. Dans une première 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 de l'appelé (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 l'appel. Dans une variante, la plateforme PF n'effectue aucune présélection et envoie la liste de tous les terminaux de l'appelé qui sont disponibles. En revanche, le terminal Tl sélectionne dans cette liste LST les terminaux les plus appropriés en fonction du type de flux de données à envoyer. Dans l'un ou l'autre mode de réalisation, le terminal Tl est alors en mesure de présenter à l'appelant, via ΙΗΜ, une sélection SEL (flèche en traits pointillés sur la figure 2, correspondant à ce deuxième mode de réalisation) des terminaux de l'appelé capables de recevoir les flux à envoyer. Il s'affiche alors sur l'IHM du terminal Tl par exemple, un message d'indication de ces terminaux de l'appelé, afin que l'appelant puisse effectuer un choix CHX parmi ces terminaux. Le terminal Tl, recevant ce choix, peut ensuite passer l'appel APP et orienter les flux 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. Ainsi, préalablement à l'émission d'un appel depuis le terminal de l'appelant Tl, la requête REQ est envoyée vers la plateforme de médiation PF afin de retrouver pour l'appelé les terminaux enregistrés et autorisés pour recevoir l'appel. Ce choix peut s'effectuer:

en fonction de l'appelant et des flux qu'il a pu déclarer à la plateforme, et

possiblement en outre en fonction des capacités du terminal de l'appelant lui-même, s'il est capable en particulier de gérer un ou plusieurs flux particuliers.

La plateforme PF peut donc aussi effectuer un premier filtre des terminaux de l'appelé, en fonction déjà des capacités de communication du terminal de l'appelé, lui-même.

En réponse à la requête, l'utilisateur du premier terminal Tl reçoit sur un terminal de son choix (par exemple le terminal sur lequel il entend passer l'appel, par exemple son smartphone Tl) un message généré par ce terminal choisi sur son IHM et présentant les différents types de flux de l'appelant à communiquer et les différents terminaux de l'appelé supportant ces flux. Il peut alors choisir via son IHM vers quel terminal T2 il envoie l'appel. Dans le cas de plusieurs flux différents composant l'appel (audio, vidéo, etc.), il peut choisir via l'IHM vers quels terminaux T2a, T2b répartir l'appel. En outre, en fonction de l'appel qu'anticipe l'utilisateur du premier terminal, il est possible qu'un des terminaux de l'appelé ait à renvoyer un flux particulier (par exemple des flux vidéo et 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 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. Dans une première forme de réalisation, la requête de l'appelant vers la plateforme comporte à la fois l'identifiant de l'appelé et les capacités du terminal appelant en termes de flux et types de flux à communiquer. En fonction des terminaux enregistrés et disponibles pour l'appelé, la plateforme analyse les différentes combinaisons possibles et retourne un message à l'utilisateur appelant via ΙΗΜ de son terminal (terminal appelant Tl) pour que l'utilisateur appelant choisisse la répartition de son appel auprès des terminaux de l'appelé.

On a illustré sur la figure 3 une plateforme PF convenant pour cette première 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 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 de la base de données DB des terminaux d'appelés), et

- une interface de communication COM (via le réseau de communication RES, par exemple Internet) :

* avec les terminaux (Tl 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 composant appel à passer, les terminaux de appelé qui sont capables de gérer ces flux (par exemple un smartphone ou un ordinateur pour un appel de type visioconférence, un robot pour un appel comportant des commandes, etc.). Dans une variante, la requête de l'appelant ne comporte que l'identifiant de l'appelé. Les capacités du terminal de l'appelant ne sont pas nécessaires. Toutes les données sur les capacités des terminaux de l'appelé T2, T2a, T2b, sont alors transmises au terminal appelant Tl. Le terminal de l'appelant exécute alors une routine d'analyse des combinaisons possibles pour générer le message via ΙΗΜ à destination de l'utilisateur Ul pour que l'utilisateur choisisse la meilleure répartition des flux de son appel.

On a illustré sur la figure 4 un terminal appelant Tl 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 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 appelés, les flux que ces derniers sont capables de gérer), et

- 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 terminaux de l'appelé avec leur adresse IP par exemple).

En particulier, dans cette réalisation, le terminal Tl 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 l'appel à passer, les terminaux de l'appelé qui sont capables de gérer ces flux (par exemple un smartphone ou un ordinateur pour un appel de type 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. 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 de l'appelé 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, 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 de l'appelé) la capacité de ces terminaux à gérer ou non différents types de flux de données reçus, peut : être concentrée dans une base unique DB (selon la figure 3) pour la mise en œuvre 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 Tl selon la figure 4), et la base générale des terminaux en correspondance des appelés DB

(connectée ou intégrée à la plateforme PF).

Par ailleurs, l'appelé peut par exemple contrôler les données que stocke la base de données précitées. Par exemple, la base de données peut aussi gérer les autorisations d'accès à des terminaux de l'appelé, en fonction des données de l'appelant (en fonction de son IMSI par exemple). Dans une forme de réalisation, on peut prévoir par exemple qu'un appelant dans le cercle proche d'un appelé a accès à tous les terminaux de l'appelé alors qu'un appelant « inconnu » (non identifié dans ce cercle proche) n'a pas accès par défaut à tous les terminaux de l'appelé. Par exemple, ce « cercle de proches » peut être déclaré initialement (ou au gré de l'utilisation) par l'appelé à la plateforme de médiation, en fournissant leur identifiant IMSI par exemple.