WO2017109314A1 - Choix d'un terminal appelé, optimisé pour l'établissement d'un appel - Google Patents

Choix d'un terminal appelé, optimisé pour l'établissement d'un appel Download PDF

Info

Publication number
WO2017109314A1
WO2017109314A1 PCT/FR2016/053134 FR2016053134W WO2017109314A1 WO 2017109314 A1 WO2017109314 A1 WO 2017109314A1 FR 2016053134 W FR2016053134 W FR 2016053134W WO 2017109314 A1 WO2017109314 A1 WO 2017109314A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminals
terminal
called party
call
database
Prior art date
Application number
PCT/FR2016/053134
Other languages
English (en)
Inventor
Laurent MARCHOU
Cécile Batel
Fabrice Fauchoux
Original Assignee
Orange
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 filed Critical Orange
Publication of WO2017109314A1 publication Critical patent/WO2017109314A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/04—Terminal devices adapted for relaying to or from another terminal or user
    • 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/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/006—Call diverting means
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • 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/25—Aspects of automatic or semi-automatic exchanges related to user interface aspects of the telephonic communication service
    • H04M2203/256—Aspects of automatic or semi-automatic exchanges related to user interface aspects of the telephonic communication service comprising a service specific user interface
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/16—Communication-related supplementary services, e.g. call-transfer or call-hold

Definitions

  • the present invention relates to the choice of a called terminal, optimized for the establishment of a call.
  • terminals Users of the usual communication devices often encounter interoperability problems between devices. Their environment comprises a multitude of connected objects capable of offering a better communication experience (in the sense of feeling at the level of the interface proposed to the user). Typically, these devices (hereinafter referred to as “terminals”) are equipped with screens, cameras, connected microphones, speakers, etc., enriching the user interface.
  • this database lists, for each of the aforementioned second terminals, an ability to manage or not different types of data streams received.
  • the method then comprises, for the processing of a call intended for the called party and coming from a first terminal, such a call involving the transmission of one or more types of data stream to be sent:
  • the caller (or his terminal) can already determine if the terminals of the called party can support the flows he intends to send, and optionally then choose among those terminals those who actually receive the streams. Such a method then ensures compatibility between the different communicating terminals for any type of stream to be sent.
  • the first terminal transmits, to this mediation platform, a request comprising at least one identifier of the called party and the types of data streams to be sent,
  • the mediation platform selects for each type of data stream to be sent, second terminals capable of managing each of at least one of these types of data streams, and
  • the mediation platform transmits this selection to the first terminal for the aforementioned targeted sending.
  • the first terminal plays a relatively passive role with respect to a second alternative embodiment, presented hereinafter.
  • the first terminal transmits, to the mediation platform, a request including at least one identifier of the called party,
  • the mediation platform determines a list of the second terminals available to the called party, and transmits this list to the first terminal, and when receiving the list, the first terminal selects for each type of data stream to be sent, the second terminals capable of managing each of at least one of the data flow types, for the aforementioned targeted sending.
  • the first terminal therefore plays an active role insofar as it selects the terminals of the called party that are most appropriate to the types of streams to be sent.
  • the user of the calling terminal can also contribute to choosing the second terminals that will receive the streams.
  • the first terminal can implement the steps:
  • an HMI message for "human machine interface" on the first terminal, comprising for each type of data stream to be sent, an invitation from the caller, user of the first terminal, to select one or more second terminals among the selected second terminals, and
  • the aforementioned HMI message may further include an additional call setting option for transmitting a default data flow type.
  • a default data flow type eg a flow related to a voice communication, by default.
  • the user of the calling terminal can choose by default to establish the call for a simple voice communication, or on the contrary choose to establish the call by transmitting in in addition to another stream, for example a video stream in videoconferencing mode.
  • its HMI indicates whether the called party has a suitable terminal for this purpose and invites him to enter the choice of such a terminal.
  • the aforementioned second terminals capable of managing each of at least one of said types of data stream, are tested to determine their availability, and in particular the terminals tested as available are selected.
  • the database furthermore lists, for each of said second terminals, an ability to manage or not different types of data streams, both received and transmitted.
  • the method then comprises, for processing a call involving transmission by the first terminal of one or more types of data streams to be sent and providing one or more types of data streams to be received back from the first terminal:
  • a connected television can handle streams (video and audio) in reception but, in general, has no flow management means to send.
  • a tablet or smartphone can provide both features.
  • the invention also relates to a computer program comprising instructions for implementing the above method, when this program is executed by a processor.
  • This processor may be that of a mediation platform for managing a call from a caller to a called party, according to the first embodiment of the method, presented above.
  • the invention also aims at such a platform, comprising a database of called in correspondence of second terminals available to each called party. This database furthermore lists, for each of said second terminals, an ability to manage or not different types of data streams received.
  • the platform further comprises a computer circuit, for the processing of a current call for a called and from a first terminal, said current call involving the transmission of one or more types of data stream to be sent , the computer circuit being programmed to:
  • the invention also relates to a calling terminal, in particular for implementing the method according to the second embodiment above.
  • This terminal comprises a computer circuit for managing a call to a called party, the calling terminal being connected to a call database in correspondence of second terminals available to each called party, the database furthermore listing, for each of said second terminals, an ability to manage or not different types of data streams received,
  • this calling terminal being programmed, for the processing of a current call to a called party and from the calling terminal, said current call involving the transmission of one or more types of data flow to be sent, for:
  • FIG. 1 illustrates an exemplary embodiment of a cooperating platform according to the invention with a calling terminal
  • FIG. 2 illustrates the exchanges between the different entities of FIG. 1, in one exemplary embodiment
  • FIG. 3 diagrammatically represents an exemplary embodiment of a platform within the meaning of the invention
  • FIG. 4 schematically represents an exemplary embodiment of a calling terminal in the sense of the invention.
  • the invention described hereinafter in connection with an exemplary embodiment, provides a platform providing a concentrated solution for multiple communicating terminals, typically fabricated by different providers.
  • the approach of the invention is based on a management and a real-time analysis of the data flows transiting through the platform, these data flows using in particular a pilot signal.
  • the mediation platform When a terminal connects (terminal named "caller” below), the mediation platform is able to manage each terminal connectable to the caller (terminals named “called” below) and perform all actions these called (playing a video stream, or audio, or making a voice call, or filming a scene, or capturing an audio stream, etc.). Furthermore, a user of the called terminals can choose to take a communication via one of its terminals, chosen for example according to its capabilities.
  • the platform then targets to which terminal or which terminals a caller can join a called party.
  • each user of the platform records its various communicating terminals, as well as their ability to receive certain streams (video stream, audio stream, order flow, etc.).
  • a smartphone is able to manage at least a double video and audio stream.
  • a telepresence robot terminal e.g. "Ub-y”
  • Ub-y a telepresence robot terminal
  • the calling terminal T1 connects, before placing the call, to a mediation platform PF, which maintains a database DB of the terminals T2, T2a, T2b (for example a smartphone T2 , a computer T2a, a connected Hifi channel T2b, or a connected television, a robot, etc.), available to the called party intended to receive the call.
  • a mediation platform PF which maintains a database DB of the terminals T2, T2a, T2b (for example a smartphone T2 , a computer T2a, a connected Hifi channel T2b, or a connected television, a robot, etc.), available to the called party intended to receive the call.
  • callers whose terminals are listed in the DB database can subscribe to a service implementing the platform, in order to facilitate for callers an appropriate choice of the terminals receiving the call and the different types of associated flows. to this call.
  • the communicated REQ request from the calling terminal T1 to the platform PF includes an identifier of the called party (such as its subscriber number, the IMSI number typically) so that the platform can find in the database DB the different terminals, as well as their IP address, for example, available to the called party to receive the different streams composing the call.
  • These terminals T2, T2a, T2b can be connected for example to a common gateway animating a local network.
  • the platform is also able to determine the terminals T2, T2a, T2b connected to the network RES and available to receive the streams during the call.
  • the platform returns to the calling terminal Tl an LST list of terminals available to receive the streams of the call.
  • the user of the calling terminal can then choose via ⁇ (for "human-machine interface") from its terminal T1 the terminals that are suitable for receiving the call.
  • the user Ul, calling uses ⁇ of his terminal T1 to signify his wish AP to make a call.
  • the terminal Tl analyzes the different types of flows to send and elaborates a request REQ containing, at least, the identifier of the called party.
  • This request REQ is sent to the platform PF, which finds in its database DB the terminals T2, T2a, T2b available to the called party and then develops an LST list of these terminals, to transmit it to the terminal Tl.
  • the REQ request furthermore presents the different types of streams to be sent and the platform PF selects the terminals of the called party (T2, T2a for example) which are the most appropriate to receive these flows.
  • the LST list already includes a selection of the appropriate terminals to receive the call.
  • the PF platform performs no preselection and sends a list of all the terminals of the called party that are available.
  • the terminal T1 selects from this LST list the most appropriate terminals according to the type of data stream to be sent.
  • the terminal T1 is then able to present to the caller, via ⁇ , a selection SEL (arrow in dashed lines in FIG.
  • terminals of the called party capable of receiving the streams to be sent. It then displays on the HMI terminal T1 for example, an indication message of these terminals of the called, so that the caller can make a CHX choice among these terminals.
  • the terminal T1 receiving this choice, can then pass the APP call and direct the flows to the selected terminals using their IP address.
  • the LST list that the platform returns may include in particular the identifiers (for example the IP addresses) of the terminals capable of managing the streams to be sent.
  • the request REQ is sent to the mediation platform PF in order to find for the called party terminals registered and authorized to receive the call. This choice can be made:
  • the platform PF can therefore also perform a first filter of the terminals of the called party, already based on the communication capabilities of the terminal of the called, himself.
  • the user of the first terminal Tl receives on a terminal of his choice (for example the terminal on which he intends to place the call, for example his smartphone Tl) a message generated by this selected terminal on his HMI and presenting the different types of flows of the caller to communicate and the different terminals of the called party supporting these flows. He can then choose via his HMI to which T2 terminal he sends the call. In the case of several different streams of the call (audio, video, etc.), it can choose via the HMI to which terminals T2a, T2b distribute the call.
  • the caller's request to the platform comprises both the identifier of the called party and the capabilities of the calling terminal in terms of flows and types of streams to be communicated.
  • the platform analyzes the various possible combinations and returns a message to the calling user via ⁇ of its terminal (calling terminal Tl) for the calling user to choose the distribution of his call at the terminals of the called party.
  • FIG. 3 illustrates a PF platform suitable for this first embodiment and typically comprising a circuit which may for example be equipped with:
  • a processor PROC cooperating with a memory MEM (including, for example, a working memory unit for storing temporary data, as well as a permanent data storage memory unit, such as, for example, the instructions of a program of computer within the meaning of the invention, and / or directly the contents of the DB database of called terminals), and
  • a memory MEM including, for example, a working memory unit for storing temporary data, as well as a permanent data storage memory unit, such as, for example, the instructions of a program of computer within the meaning of the invention, and / or directly the contents of the DB database of called terminals
  • a COM communication interface (via the communication network RES, for example the Internet):
  • the platform executes a routine (the aforementioned computer program) for determining, according to the different types of component streams that are to be called, the called terminals that are capable of managing these flows (for example a smartphone or a computer for a videoconference call, a robot for a call with commands, etc.).
  • the caller's request includes only the identifier of the called party. Caller terminal capabilities are not required. All data on the capabilities of the terminals of the called T2, T2a, T2b, are then transmitted to the calling terminal Tl.
  • the caller's terminal executes a routine of analysis of the possible combinations. to generate the message via ⁇ to the user Ul for the user to choose the best distribution of the streams of his call.
  • FIG. 4 illustrates a calling terminal T1 suitable for this second embodiment and typically comprising a circuit which may for example be equipped with:
  • a processor PROC cooperating with a memory MEM including, for example, a working memory unit for storing temporary data, as well as a permanent data storage memory unit, such as, for example, the instructions of a program of computer within the meaning of the invention, and / or directly the contents of a database DB2 giving, according to models of called terminals, the flows that they are able to manage
  • a memory MEM including, for example, a working memory unit for storing temporary data, as well as a permanent data storage memory unit, such as, for example, the instructions of a program of computer within the meaning of the invention, and / or directly the contents of a database DB2 giving, according to models of called terminals, the flows that they are able to manage
  • a COM communication interface via the communication network RES, for example the Internet, especially with the PF platform (to simply receive the list of terminals called with their IP address for example).
  • the terminal T1 executes, with the support of the database DB2, a routine (the aforementioned computer program) for determining, as a function of the different types of flows comprising the call to be made, the terminals of the 'called who are able to manage these flows (eg a smartphone or a computer for a videoconferencing type call, a robot for a call with commands, etc.).
  • a routine the aforementioned computer program for determining, as a function of the different types of flows comprising the call to be made, the terminals of the 'called who are able to manage these flows (eg a smartphone or a computer for a videoconferencing type call, a robot for a call with commands, etc.).
  • the present invention is not limited to the embodiments described above by way of example; it extends to other variants.
  • the DB2 terminal model database can be integrated into the DB database that the PF platform manages in the aforementioned first embodiment.
  • the platform PF further interrogates the terminals of the called party to determine their availability (network connection in particular)
  • the platform PF can directly retrieve this model data from the terminals in response to this interrogation, and thus determine terminals capable of managing different types of flows.
  • the database listing (in addition to the terminals of the called party) the capacity of these terminals to manage or not different types of data streams received, can: be concentrated in a single database DB (according to FIG. 3) for the implementation of the first embodiment, or
  • DB2 database of the terminal models in correspondence with their capacity to manage the flows (connected or integrated in the terminal T1 according to FIG. 4), and the general base of the terminals in correspondence of the called DBs
  • the called party can for example control the data stored in the aforementioned database.
  • the database can also manage the access rights to terminals of the called party, according to the data of the caller (according to his IMSI for example).
  • a caller in the circle close to a called party has access to all terminals of the called party while an "unknown" caller (not identified in this close circle) n does not have access by default to all terminals of the called party.
  • this "circle of relatives" can be declared initially (or at the option of use) by the called party to the mediation platform, providing their IMSI identifier for example.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Choix d'un terminal appelé, optimisé pour l'établissement d'un appel L'invention concerne la gestion d'un appel d'un appelant vers un appelé. En particulier, l'appelé est associé dans une base de données à une pluralité de seconds terminaux. 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 reçus. On prévoit un procédé comprenant, pour le traitement d'un appel destiné à l'appelé et issu d'un premier terminal, ledit appel impliquant la transmission d'un ou plusieurs types de flux de données à envoyer : - retrouver dans la base de données (DB) la pluralité de seconds terminaux associés à l'appelé, - déterminer, pour chaque type de flux de données à envoyer, un ou plusieurs terminaux (T2, T2a, T2b) sélectionnés 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, et - obtenir auprès du premier terminal (T1) 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

Choix d'un terminal appelé, optimisé pour l'établissement d'un appel
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.

Claims

REVENDICATIONS
1. 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,
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 le traitement d'un appel destiné à l'appelé et issu d'un premier terminal, ledit appel impliquant la transmission d'un ou plusieurs types de flux de données à envoyer :
- retrouver dans la base de données (DB) la pluralité de seconds terminaux associés à l'appelé,
- déterminer, pour chaque type de flux de données à envoyer, un ou plusieurs terminaux (T2, T2a, T2b) sélectionnés 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, et
- obtenir auprès du premier terminal (Tl) 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. Procédé selon la revendication 1 , dans lequel :
- avant établissement de l'appel, le premier terminal transmet, à une plateforme de médiation connectée à ladite base de données, 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, 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. Procédé selon la revendication 1, dans lequel :
- avant établissement de l'appel, le premier terminal transmet, à une plateforme de médiation connectée à ladite base de données, une requête comportant au moins un identifiant de appelé,
- par consultation de la base de données, ladite plateforme de médiation détermine une liste des seconds terminaux à disposition de l'appelé, 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é.
4. Procédé selon l'une des revendications précédentes, comportant en outre les étapes mises en œuvre 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'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 auxdits terminaux choisis.
5. Procédé selon la revendication 4, dans lequel le message d'IHM comporte en outre un choix supplémentaire, d'établissement d'appel pour la transmission d'un type de flux de données par défaut.
6. Procédé selon la revendication 5, dans lequel le type de flux par défaut est relatif à une communication vocale.
7. Procédé selon l'une des revendications précédentes, dans lequel lesdits seconds terminaux 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.
8. Procédé selon l'une des revendications précédentes, dans lequel 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é comprenant, 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 (DB) 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 (T2, T2a) 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 (Tl) 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.
9. Programme informatique caractérisé en ce qu'il comporte des instructions pour la mise en œuvre du procédé selon l'une des revendications précédentes, lorsque ce programme est exécuté par un processeur.
10. Plateforme de médiation pour la gestion d'un appel d'un appelant vers un appelé, la plateforme comportant 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,
la plateforme comportant 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.
11. Terminal appelant comportant 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 é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.
PCT/FR2016/053134 2015-12-23 2016-11-29 Choix d'un terminal appelé, optimisé pour l'établissement d'un appel WO2017109314A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1563229 2015-12-23
FR1563229A FR3046322A1 (fr) 2015-12-23 2015-12-23 Choix d'un terminal appele, optimise pour l'etablissement d'un appel

Publications (1)

Publication Number Publication Date
WO2017109314A1 true WO2017109314A1 (fr) 2017-06-29

Family

ID=55650468

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2016/053134 WO2017109314A1 (fr) 2015-12-23 2016-11-29 Choix d'un terminal appelé, optimisé pour l'établissement d'un appel

Country Status (2)

Country Link
FR (1) FR3046322A1 (fr)
WO (1) WO2017109314A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013093314A1 (fr) * 2011-12-23 2013-06-27 France Telecom Procede d'acces par un terminal de telecommunication a une base de donnees hebergee par une plateforme de services accessible via un reseau de telecommunications
FR3000357A1 (fr) * 2012-12-20 2014-06-27 France Telecom Procede de transfert de communication audio et/ou video depuis un premier terminal vers un deuxieme terminal

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013093314A1 (fr) * 2011-12-23 2013-06-27 France Telecom Procede d'acces par un terminal de telecommunication a une base de donnees hebergee par une plateforme de services accessible via un reseau de telecommunications
FR3000357A1 (fr) * 2012-12-20 2014-06-27 France Telecom Procede de transfert de communication audio et/ou video depuis un premier terminal vers un deuxieme terminal

Also Published As

Publication number Publication date
FR3046322A1 (fr) 2017-06-30

Similar Documents

Publication Publication Date Title
US7961212B2 (en) Video messaging system
US8588399B2 (en) Call routing method: routing to out-of-network representative having ability to speak specific language, if interpreter of network and interpreter of entity are not available to take call
US8279261B2 (en) Email based scheduling mechanism for conference calls
FR2942091A1 (fr) Communication multimedia dans un environnement virtuel
US20130226564A1 (en) Method and System for Providing an Audio Representation of a Name
FR3092718A1 (fr) Procédé de traitement de flux audiovidéo en conférence multipartite, dispositifs, système et programme correspondants
EP2882161A1 (fr) Procédé et dispositf d' établissement d'une communication
US20240171678A1 (en) Facilitating A Remote Emergency Call During A Video Conference
US20120124137A1 (en) System, Method and Apparatus for Enhanced Processing of Communication In a Peer-To-Peer Network
EP2879328A1 (fr) Procédé et serveur de réservation de ressources matérielles de conférence
EP2005710A2 (fr) Procede et systeme de gestion dynamique de transmission de flux au sein d'une pluralite de terminaux
WO2017109314A1 (fr) Choix d'un terminal appelé, optimisé pour l'établissement d'un appel
EP3461135A1 (fr) Procédé de gestion du droit d'accès à un contenu numérique
EP2783496A1 (fr) Procede de gestion de la mise en relation numerique
FR3038182A1 (fr) Changement optimise de terminal, en cours d'appel
US9264457B2 (en) Telephony application platform
EP2819352A1 (fr) Dépòt et consultation de messages par des utilisateurs de réseaux sociaux
US11539838B2 (en) Video voicemail recording system
FR3060926B1 (fr) Systeme, ensemble et procede d'interphonie
US9148508B2 (en) Systems and methods of intercepting telephony communications to provide information to communicants
US20230316533A1 (en) Virtual Background Sharing
US20230316534A1 (en) Virtual Background Partitioning
WO2017103480A1 (fr) Système et procédé de réalisation d'un tour de table lors d'une réunion à distance
FR3018027A1 (fr) Procede et dispositif de decouverte des capacites de communication relatives a un utilisateur d'un terminal
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

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16819338

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16819338

Country of ref document: EP

Kind code of ref document: A1