FR2877523A1 - Procede de gestion informatisee d'une teleconference et de serveurs de teleconferences. - Google Patents

Abstract

Dans le cadre d'une requête d'arrêt d'une téléconférence, on vérifie en utilisant un fichier (108) de règle de conférence si le participant est autorisé à clôturer la conférence. En cas d'autorisation, la conférence est clôturée.

Description

PROCEDE DE GESTION INFORMATISEE D'UNE TELECONFERENCE ET

DE SERVEURS DE TELECONFERENCES

L'invention concerne un procédé de gestion informatisée 5 d'une téléconférence ainsi que des serveurs de téléconférences.

Dans ce que l'on appelle le Work Item IMS Stage-2 Enhancements (TSG SA WD2/TSG CN WD1), un système de téléconférence multimédia pour le protocole d'Internet Multimédia Subsystem (IMS) du Universal Mobile Telecommunication System (UMTS) est actuellement spécifié dans le cadre du 3rd Generation Partnership Project (3GPP).

Ce système de téléconférence est fondé sur l'architecture et les composants de protocole de communication qui ont été décrits dans la structure (Conferencing Framework) définie pour cela par le Internet Engineering Task Force (IETF) (cf. [1]).

En plus d'un procédé de commande des droits d'accès à des ressources de téléconférence multimédia (également désignées par Floor Control) et de l'établissement de règles de conférence (également appelées Conference Policy Control), le système de téléconférence établit en outre des procédures fondées sur un Session Initiation Protocol (SIP) entre autres pour générer, gérer, aborder et quitter des téléconférences.

De plus, le système contient des procédés de transmission d'informations et d'événements (Events) spécifiques sur la téléconférence aux participants à la conférence (également désignés par Conference Notification Service). A l'intérieur du système de téléconférence, toutes sortes de média peuvent être échangés entre les participants et, pour cette raison, ce système est désigné dans la suite par Système de téléconférence multimédia.

Pour arrêter une téléconférence multimédia organisée, [1] et [2] enseignent que la conférence n'est arrêtée que lorsque le dernier participant à la conférence quitte la téléconférence.

En variante, [2] et [4] enseignent qu'une conférence n'est arrêtée que lorsque le participant, qui est l'instigateur de 5 la téléconférence multimédia quitte la conférence.

Selon [5], seul le participant qui est à l'origine de la téléconférence peut finir ou arrêter celle-ci explicitement en purgeant le Conference Policy. Dans {5], il est décrit ce que l'on appelle le Conference Policy Control Protocol (CPCP) qui donne la possibilité de définir différentes règles dans le cadre d'une telle téléconférence multimédia. Un exemple d'un fichier Conference Policy (Conference Policy Document) décrit dans [5], au format Extensible Markup Language (Format XML) est illustré dans la suite à titre d'exemple.

<?xml version="1.0" encoding="UTF-8"?> <conference xmins="ur.n:ietf:params:xml:ns:conference-policy" xm1ns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <settings> <conferenceuri>sip:myconference@example.com</conference-uri> <maxparticipant-count>10</max-participant-count> <allow-sidebars>true</allowsidebars> </settings> <info xml:lang="en-us"> <subject>What's happening tonight</subject> <display-name>Party Goer's</display-name> <free-text>John and Peter will join the conference soon</free-text> <keywords>party nightclub beer</keywords> <host-info> <uri>sip:Al.ice@example.com</uri> <uri>tel:+3581234567</uri> <e-mail>mailto:Alice@example.com</e-mail> <web-page>http://www.example.com/users/Alice</web- page> </host-info> </info> <time> <occurrence> <mixing-start-time requiredparticipant="par.ticipant">2004-1217T09:30:0005:00</mixing-start-time> <mixing-stop-time required-participant="none">2004-12-17712:30:00- 05:00</mixing-stop-time> <can-join-after>2001-12-17709:25:00-05:00</can- join- after> <must-join-before>2004-12-17712:00:00-05:00</must- join-before> <request-users required-participant="none">2001-12-17T09:30:0005:00</request-users> </occurrence> </time> <authorization-rules> <rule id="1"> <conditions> <identity> <domain>example.com</domain> </identity> </conditions> <actions> <allow-conference-state>true</allow-conferencestate> <join-handling>allow</join-handling> </actions> <transformations/> </rule> <rule id="2"> <conditions> <identity> <id>alice@example.com</id> </identity> </conditions> <actions> <allow-sidebar>true</allow-sidebar> </actions> <transformations> <is-key-participant>true</is-key-participant> </transformations> </rule> </authorization-rules.> <dialout-list> <target uri="sip:bob@example.com"/> </dialout-list> <refer-list> <target uri="sip:sarah@example.com"/> </refer-list> <security-control> <security-mechanism tls="false" s-mime="true"/> <pin>13579</pin> <password>abcdl234</password> </security-control> <floor-policy> <floor floor-control="fcp://example.com/floorabc" moderator- controlled="false"> <media-streams> <audio media-id="2"/> </media-streams> <algorithm> <fcfs/> </algorithm> <max-floor-users>l</max-floor-users> </floor> </floor-policy> <media-streams> <video media-id="1"/> 5 <audio media-id="2"/> </media-streams> </conference> Fichier de règles de conférence Exemple 1 Dans [3], il est décrit le Session Initiation Protocol (SIP).

[6] décrit ce que l'on appelle le Extensible Markup Language Configuration Access Protocol (XCAP).

En raison du manque de souplesse, décrit ci-dessus, de la clôture d'une conférence, il peut se produire des désagréments importants pour les participants à une téléconférence multimédia, par exemple une clôture non souhaitée d'une téléconférence en raison du fait que le participant instigateur de la conférence quitte la confie téléconférence bien que cela ne soit pas souhaité par les autres participants à la téléconférence et le cas échéant même de la part du participant instigateur de la conférence.

[7] décrit un système de sélection dynamique de flux de média.

En outre, le document [8] enseigne d'associer à une téléconférence dans le domaine de la téléphonie mobile une donnée d'identification de conférence permettant d'identifierde façon univoque la conférence.

[9] décrit une architecture de communication en utilisant 30 des processeurs satellites.

[10] enseigne en outre un procédé de proposition de services sans fil en réseau.

Dans [11], il est décrit un système d'assistance de proposition de service de communication qui favorise plusieurs de types différents de service pendant une session de service (Service Session), le système comportant une unité de gestion des sessions (Session Manager).

Dans [12], [13], [16] et [17], il est décrit des procédés 5 et dispositifs d'établissement automatique de circuits de conférence.

Dans [14], il est décrit un dispositif qui sert à détecter un événement prédéterminé dans un canal téléphonique d'un système de communication qui comporte plusieurs canaux téléphoniques.

Dans [15], il est décrit un procédé et un dispositif qui servent à la gestion, sur une base vocale, de l'état et de l'interaction de ce que l'on appelle un Knowledge Worker dans un environnement de centre de contact (Contact Center Environment).

Dans [18], il est exposé un procédé et un dispositif de proposition de conférences; il est prévu une interface de commande entre une fonction Annonce/Dialogue ayant une fonctionnalité de reconnaissance vocale et une fonction de gestion de conférence qui permet d'ouvrir la conférence et de la commander pendants son déroulement.

Dans [19], il est exposé un procédé et un système de mise en uvre d'un service de conférence dans un réseau de télécommunications, le réseau de télécommunications incluant un certain nombre de systèmes de communication dont un ou plusieurs comportent une ou plusieurs passerelles de conférence.

Dans [20], il est exposé un système de vidéoconférence qui comporte à chaque emplacement d'une pluralité d'emplacements plusieurs stations de participant ainsi qu'une station de contrôle; un directeur de conférence reçoit un avertissement de la station de contrôle dans le cas où une station de participant n'est plus disponible à un emplacement et dirige les participants à la conférence vers une autre station de participant disponible.

Le but de l'invention est de définir et modifier de façon simple et souple des droits ou des événements permettant 5 d'interrompre ou de clôturer une téléconférence.

Le but est atteint par un procédé de gestion informatisée d'une téléconférence au moyen d'un serveur de téléconférence qui propose au moins une téléconférence entre plusieurs participants, le serveur de téléconférence ayant accès à un fichier électronique de règles de téléconférence, le fichier de règles de téléconférence destiné à la téléconférence proposée contenant des informations permettant de déterminer les participants qui peuvent interrompre ou clôturer la téléconférence ou interrompre une partie de la téléconférence, procédé caractérisé en ce que le serveur de téléconférence reçoit de la part d'un participant à la téléconférence une requête demandant d'interrompre ou de clôturer la téléconférence ou d'interrompre une partie de la téléconférence, le serveur de téléconférence vérifie, en utilisant le fichier de règles de téléconférence, si le participant est autorisé à interrompre ou clôturer la téléconférence ou à interrompre une partie de la téléconférence, dans le cas où le participant n'est pas autorisé à interrompre ou clôturer la téléconférence ou à interrompre la partie de la téléconférence, le serveur de téléconférence poursuit la téléconférence, et dans le cas où le participant est autorisé à interrompre ou à clôturer la téléconférence ou à interrompre la partie de la téléconférence, le serveur de téléconférence interrompt ou clôture la téléconférence ou interrompt la partie de la téléconférence.

De préférence: - le fichier de règles de téléconférence peut être modifié par un ou plusieurs participants.

- le fichier de règles de téléconférence contient des informations sur les participants qui peuvent modifier le fichier de règles de téléconférence.

- le fichier de règles de téléconférence contient des informations sur les participants qui peuvent modifier dans le fichier de règles de téléconférence les informations permettant de déterminer les participants qui peuvent interrompre ou clôturer la téléconférence ou interrompre la partie de la téléconférence.

- l'information relative aux participants autorisés à interrompre ou clôturer la téléconférence ou à interrompre la partie de la téléconférence est mémorisée dans le fichier de règles de téléconférence sous la forme d'un ou plusieurs éléments de données.

- l'information relative au participant autorisé à interrompre ou clôturer la téléconférence ou interrompre la partie de la téléconférence est mémorisée dans le fichier de règles de téléconférence sous la forme d'un ou de plusieurs éléments de données d'action.

L'invention vise aussi un procédé de gestion informatisée d'une téléconférence au moyen d'un serveur de téléconférence qui propose au moins une téléconférence entre plusieurs participants, le serveur de téléconférence ayant accès à un fichier électronique de règles de téléconférence, le fichier de règles de téléconférence destiné à la téléconférence proposée contenant des informations permettant de déterminer quels événements peuvent interrompre ou clôturer la téléconférence ou interrompre une partie de la téléconférence, le serveur de téléconférence ou le serveur de règles de téléconférence vérifie, en utilisant le fichier de règles de téléconférence, la survenance de ces événements, en l'absence de survenance de ces événements, le serveur de conférence de télécommunications poursuit la téléconférence ou la partie de la téléconférence, et en cas de survenance de ces événements, le serveur de téléconférence interrompt ou clôture la téléconférence ou interrompt la partie de la téléconférence.

De préférence: - le fichier de règles de téléconférence peut être modifié par un ou plusieurs participants.

- le fichier de règles de téléconférence contient des informations sur les participants qui peuvent modifier le 10 fichier de règles de téléconférence.

- le fichier de règles de téléconférence contient des informations sur les participants qui peuvent modifier dans le fichier de règles de téléconférence les informations permettant de déterminer quels événements peuvent interrompre ou clôturer la téléconférence ou interrompre la partie de la téléconférence.

On utilise comme événements l'un des événements suivants: un ou plusieurs participants à la téléconférence, indiqués dans le fichier de règles de téléconférence, quittent 20 la téléconférence, - un instant indiqué dans le fichier de téléconférence est atteint, - la téléconférence a déjà atteint une durée maximale indiquée dans le fichier de téléconférence.

- la communication entre les participants et le serveur de téléconférence est effectuée au moins partiellement selon le Session Initiation Protocol.

- la communication entre les participants et le serveur de téléconférence est effectuée au moins partiellement selon le 30 Conference Policy Control Protocol.

- il est proposé comme téléconférence une téléconférence multimédia dans laquelle plusieurs flux de données de médias différents sont proposés aux participants.

- le serveur de téléconférence est identifié de façon univoque au moyen d'un SIP Unique Resource Identifier.

- le fichier de règles de téléconférence est mémorisé au format XML.

- on accède au fichier de règles de téléconférence selon 5 le Hypertext Transfer Protocol.

- les participants à la téléconférence transfèrent et/ou reçoivent des données selon un protocole de communication de téléphonie mobile.

- les participants à la téléconférence transfèrent et/ou 10 reçoivent des données selon un protocole de communication de téléphonie mobile 3GPP.

- les participants à la téléconférence transfèrent et/ou reçoivent des données selon un protocole de communication de téléphonie mobile UMTS.

Dans un procédé de gestion informatisée d'une téléconférence au moyen d'un serveur de téléconférences qui propose au moins une téléconférence entre plusieurs participants, une requête faite par un participant à la téléconférence est reçue par le serveur de téléconférences; il est demandé via la requête d'interrompre ou de clôturer la téléconférence ou d'interrompre une partie de la téléconférence. Le serveur de téléconférences a accès à un fichier électronique de règles de téléconférence (également désigné par Conference Policy Document). Par rapport à l'état de la technique, le fichier de règles de téléconférence contient en plus, pour la téléconférence, des informations permettant de déterminer les participants qui sont autorisés à interrompre ou clôturer la téléconférence ou à interrompre la partie de la téléconférence. Le serveur de téléconférences vérifie, après réception de la requête, en utilisant le fichier de règles de téléconférence, si le participant qui envoie la requête et donc habituellement le participant qui établit la requête est autorisé à interrompre respectivement clôturer la téléconférence ou interrompre la partie de la téléconférence. Dans le cas où le participant n'est pas autorisé à interrompre ou clôturer la téléconférence ou interrompre la partie de la téléconférence, le serveur de téléconférences poursuivra la téléconférence entre les participants et le cas échéant informera le participant sur le fait qu'il ne dispose d'aucune autorisation et donc que la requête ne sera pas satisfaite, par exemple au moyen d'un message de confirmation négative correspondant (Negative Acknowledgement, NACK) qui est transmis au participant. Dans le cas où le participant est autorisé à interrompre ou clôturer la téléconférence ou interrompre la partie de la téléconférence, le serveur de téléconférences interrompt ou arrête la téléconférence ou interrompt la partie de la téléconférence.

Selon une variante de cet aspect de l'invention, il est prévu un procédé de gestion informatisée d'une téléconférence au moyen d'un serveur de téléconférences, dans lequel le serveur de téléconférences propose au moins une téléconférence entre plusieurs participants. Le serveur de téléconférences a accès à un fichier électronique de règles de téléconférence (Conference Policy Document) qui contient, pour la téléconférence proposée, des informations permettant de déterminer quels événements permettent l'interruption ou la clôture de la téléconférence ou l'interruption d'une partie de la téléconférence. Le serveur de téléconférence vérifie la survenance d'événements en utilisant le fichier de règles de téléconférence. En l'absence d'événements, la téléconférence ou la partie de la téléconférence est poursuivie sans changement par le serveur de téléconférences. En cas de survenance d'événements indiqués dans le fichier de règles de téléconférence, le serveur de téléconférences interrompt ou arrête la téléconférence ou interrompt la partie de la téléconférence conformément à une directive en mémoire dans le fichier de règles de téléconférence.

Il faut mentionner que les procédés ci-dessus peuvent être utilisés en combinaison, c'est-à-dire que le ou les participants, autorisés à interrompre ou clôturer une téléconférence ou interrompre une partie d'une téléconférence ainsi que les événements qui peuvent entraîner une interruption ou une clôture d'une téléconférence ou une interruption d'une partie d'une téléconférence peuvent être mémorisés dans le fichier de règles de téléconférence et, sur une requête d'un participant, le serveur de téléconférences peut vérifier l'autorisation du participant dans le fichier de règles de téléconférence ou peut vérifier en continu la survenance d'un événement indiqué dans le fichier de règles de téléconférence.

Un serveur de téléconférences est destiné à proposer au moins une téléconférence entre plusieurs participants. Le serveur de téléconférences a accès à un fichier électronique de règles de téléconférence; le fichier de règles de téléconférence contient pour la téléconférence proposée des informations permettant de déterminer les participants qui sont autorisés à interrompre ou clôturer la téléconférence ou bien interrompre une partie de la téléconférence. En outre, il est prévu une unité de réception destinée à recevoir une requête d'un participant à la téléconférence demandant d'interrompre ou de clôturer la téléconférence ou d'interrompre la partie de la téléconférence. En outre, il est prévu une unité de vérification d'autorisation permettant de vérifier, en utilisant le fichier de règles de téléconférence, si le participant est autorisé à interrompre ou clôturer la téléconférence ou interrompre la partie de la téléconférence.

En outre, il est prévu une unité de clôture de téléconférence qui est destinée à interrompre ou clôturer la téléconférence ou interrompre la partie de la téléconférence dans le cas où le participant est autorisé à interrompre ou clôturer la téléconférence.

Selon un autre aspect de l'invention, un serveur de téléconférences est également destiné à proposer au moins une téléconférence entre plusieurs participants. Le serveur de téléconférences a accès à un fichier électronique de règles de téléconférence; le fichier de règles de téléconférence contient, pour la téléconférence proposée, des informations permettant de déterminer quels événements permettent d'interrompre ou de clôturer la téléconférence ou d'interrompre une partie de la téléconférence. En outre, il est prévu dans le serveur de téléconférences une unité de vérification d'événements permettant de vérifier la survenance des événements en utilisant le fichier de règles de téléconférence. En outre, il est prévu une unité de clôture de téléconférence qui est destinée à interrompre ou clôturer une téléconférence ou à interrompre la partie de la téléconférence en cas de survenance d'événements.

Dans une variante de réalisation de l'invention, il est prévu que le serveur de téléconférences comporte une unité de vérification d'autorisation, comme décrit ci-dessus, ainsi qu'une unité de vérification d'événements décrite ci-dessus. Dans ce cas, l'unité de clôture de téléconférence est destinée à interrompre ou clôturer la téléconférence ou à interrompre la partie de la téléconférence dans le cas où le participant, demandant la clôture ou l'interruption de la téléconférence, est autorisé à le faire lors d'une requête correspondante reçue ou dans le cas où il est survenu un événement, contenu dans le fichier de règles de téléconférence, qui entraîne l'interruption ou la clôture de la téléconférence ou l'interruption de la partie de la téléconférence.

Concrètement, l'invention peut être considérée à présent comme permettant, par des entrées correspondantes dans le fichier de règles de téléconférence, de prédéterminer de façon souple différentes règles relatives aux événements et aux personnes pouvant provoquer la clôture ou l'interruption d'une conférence ou l'interruption d'une partie de la téléconférence.

Cela permet de façon très simple, mais ajustable de façon quelconque dans le détail, de développer des règles de clôture ou d'interruption d'une téléconférence ou d'interruption d'une partie de la téléconférence et de les intégrer dans une architecture de téléconférence.

Concrètement, le Conference Policy, en particulier le Conference Policy Document, c'est-à-dire le fichier de règles de téléconférence, est élargi par des différentes données, selon un aspect de l'invention par une donnée relative à un ou plusieurs participants qui sont autorisés à interrompre ou clôturer une conférence ou à interrompre une partie d'une conférence ou, selon un autre aspect, par des données relatives à un ou plusieurs événements dont la survenance provoque l'interruption ou la clôture d'une conférence ou l'interruption d'une partie d'une conférence.

À cet égard, il faut mentionner que, par participant, il faut comprendre selon l'invention un appareil de télécommunications participant actuellement à la téléconférence, avantageusement un terminal de télécommunications, de façon particulièrement préférée un terminal de téléphonie mobile ainsi qu'un utilisateur d'un appareil de télécommunications qui participent à la téléconférence ou qui peut y être identifié de façon univoque, en variante un appareil de télécommunications participant actuellement à la téléconférence ou des utilisateurs de celui-ci auxquels ont été accordées les droits correspondants.

Contrairement à l'état de la technique, il est désormais possible pour la première fois de déterminer à l'intérieur d'un système de téléconférence quels événements peuvent interrompre ou clôturer une téléconférence ou interrompre une partie d'une téléconférence.

Les conformations de l'invention, décrites dans la suite, concernent aussi bien les procédés de gestion informatisée d'une téléconférence que les serveurs de téléconférences.

Les étapes opératoires respectives ou les unités décrites peuvent être réalisées, quant à leurs fonctionnalités, aussi bien sous forme matérielle, c'est-à-dire au moyen de circuits électroniques spécifiques, que sous forme logicielle, c'est-à-dire au moyen de programmes informatiques spécifiques ou sous une forme hybride quelconque, c'est-à-dire que les sous- fonctionnalités sont réalisées indifféremment en partie sous forme matérielle et en partie sous forme logicielle.

Selon une conformation de l'invention, il est prévu que le fichier de règles de téléconférence peut être modifié par un ou plusieurs participants à la téléconférence.

Il est ainsi possible, de façon très simple et très souple, d'élargir et de modifier les droits autorisant une clôture ou une interruption de la téléconférence ou des événements entraînant une clôture ou une interruption de la téléconférence ou une interruption d'une partie de la téléconférence.

Le fichier de règles de téléconférence peut contenir de préférence des informations permettant d'indiquer les participants qui sont autorisés à modifier le fichier de règles de téléconférence. Si le fichier de règles de téléconférence contient des informations sur les événements pouvant entraîner une clôture ou une interruption de la téléconférence ou une interruption d'une partie de la téléconférence, il est prévu dans une conformation de l'invention que le fichier de règles de téléconférence contienne des informations permettant d'indiquer les participants qui sont autorisés à modifier le fichier de règles de téléconférence.

En particulier, le fichier de règles de téléconférence contient de préférence des informations permettant d'indiquer les participants qui sont autorisés à modifier dans le fichier de règles de téléconférence les informations permettant de déterminer les participants qui sont autorisés à interrompre ou clôturer la téléconférence ou interrompre une partie de la téléconférence.

Concrètement, cela signifie que, en entrant dans le fichier de règles de téléconférence, on accorde de façon simple et souple le cas échéants à plusieurs participants des droits modifiables d'accorder ou de modifier des droits de clôture ou d'interruption de la téléconférence ou les droits d'interruption d'une partie de la téléconférence.

De façon correspondante, dans une autre conformation de l'invention, il est prévu que le fichier de règles de téléconférence contienne des informations sur les participants qui sont autorisés à modifier dans le fichier de règles de téléconférence les informations permettant de déterminer quels événements permettent d'interrompre ou de clôturer la téléconférence ou d'interrompre une partie de la téléconférence.

Cette conformation entraîne des avantages correspondants, comme décrit cidessus, concernant l'indication des participants autorisés à modifier les droits relatifs à la clôture ou l'interruption d'une téléconférence.

Selon une autre conformation de l'invention, l'information qui autorise des participants à interrompre ou clôturer une téléconférence ou à interrompre une partie de la téléconférence, est mémorisée dans le fichier de règles de téléconférence sous forme d'un ou plusieurs éléments de données d'autorisation, de préférence au format Extensible Markup Language Format (XML-Format).

L'information sur les participants autorisés à interrompre ou clôturer la téléconférence ou à interrompre une partie de la téléconférence peut être mémorisée dans une variante de conformation de l'invention sous la forme d'un ou plusieurs éléments de données d'action dans le fichier de règles de téléconférence. L'utilisation d'éléments de données pour la définition des participants respectifs permet de façon très claire et structurée de trouver, traiter et exploiter cette information.

Un événement contenu dans le fichier de règles de téléconférence peut être l'un des événements suivants: - un ou plusieurs participants à la téléconférence, indiqués dans le fichier de règles de téléconférence, quitte la téléconférence; - un instant indiqué dans le fichier de règlesde téléconférence est atteint et/ou - la téléconférence a déjà atteint une durée maximale indiquée dans le fichier de règles de téléconférence.

La communication entre les participants et le serveur de téléconférences est effectuée avantageusement effectuée au moins partiellement selon le Session Initiation Protocol (SIP) qui est décrit en [3].

Selon une autre conformation de l'invention, la communication entre les participants et le serveur de téléconférences est effectuée au moins partiellement selon le Conference Policy Control Protocol (CPCP) comme décrit en [5], en particulier pour établir ou modifier le Conference Policy, donc en particulier pour établir ou modifier le fichier de règles de téléconférence.

Selon une conformation de l'invention, le serveur de téléconférences propose une téléconférence multimédia dans laquelle il est proposé aux participants plusieurs flux de données multimédias différents, par exemple des flux de données audio, des flux de données vidéo, des flux de données de texte, etc. Selon cette conformation de l'invention, il est proposé une téléconférence souple quant au médium à utiliser et donc confortable pour les participants.

Le serveur de téléconférences peut être identifié avantageusement de façon univoque au moyen d'un SIP Unique Resource Identifiers (URI) ; un identificateur est associé à une conférence de préférence lors de l'ouverture d'une téléconférence et est de nouveau libérés à la clôture de la téléconférence de sorte qu'il peut être de nouveau associé à une autre téléconférence ouverte ensuite. En particulier, l'identification de conférence correspondante selon [1] est également désignée par ConferenceURI (C-URI).

Le fichier de règles de téléconférence est mémorisé de façon particulièrement préférée au format Extensible Markup Language (format XML) de façon à obtenir une représentation normalisée, simple et bon marché du fichier.

Le fichier de règles de téléconférence est de préférence lu ou écrit ou modifié selon le Hypertext Transport Protocol (HTTP), en d'autres termes on accède au fichier de règles de téléconférence de préférence au moyen de HTTP. Ceci présente l'avantage particulier que l'on peut utiliser des protocoles normalisés pour accéder à ce fichier, de sorte que l'on n'a pas besoin de modifier des systèmes existants pour accéder au fichier.

Les participants à la téléconférence transfèrent et/ou reçoivent des données de préférence par un système de téléphonie mobile, de façon particulièrement préférée par un système de téléphonie mobile 3GPP, de façon particulièrement préférée par UMTS. En d'autres termes, cela signifie que le serveur de téléconférences est de préférence destiné à la communication par un système de téléphonie mobile, de façon particulièrement préférée par un système de téléphonie mobile 3GPP et de façon particulièrement préférée par UMTS.

L'invention est particulièrement appropriée pour être utilisée dans un système de téléphonie mobile, avantageusement sous forme cellulaire. En d'autres termes, cela signifie que le serveur de téléconférences fait donc de préférence partie d'un système de téléphonie mobile, de façon particulièrement préférée d'un système de communication de téléphonie mobile 3GPP et de façon particulièrement préférée de ce que l'on appelle un IP Multimédia Core Network Subsystem (IMS) du système de communication de téléphonie mobile UMTS.

Des exemples de réalisation de l'invention sont expliqués en détail dans la suite et sont représentés dans les figures dans lesquelles: la figure 1 représente un système de téléconférence, en particulier un système de téléconférence par téléphonie mobile, selon l'exemple de réalisation préféré de l'invention; la figure 2 représente un organigramme dans lequel il est représenté la clôture d'une téléconférence selon un premier 15 exemple de réalisation de l'invention; la figure 3 représente un organigramme dans lequel il est représenté la modification de droits de clôture selon un premier exemple de réalisation de l'invention; la figure 4 représente un organigramme dans lequel il est 20 représenté la modification de droits de clôture selon un deuxième exemple de réalisation de l'invention; et la figure 5 représente un organigramme dans lequel il est représenté la clôture d'une téléconférence selon un troisième exemple de réalisation de l'invention.

La figure 1 représente un système de téléconférence multimédia par téléphonie mobile 100 selon les exemples de réalisation préférés de l'invention. Il faut mentionner que, dans une variante de conformation, il ne s'agit pas d'un système de téléconférence multimédia de téléphonie mobile. Les procédés décrits ci-dessus et dans la suite peuvent également être mis en oeuvre dans un système de téléconférence multimédia à réseau fixe, par exemple un système de téléconférence multimédia fonctionnant sur l'Internet. Dans cette variante de réalisation, au moins une partie des terminaux de télécommunications sont utilisées comme terminaux de télécommunications à réseau fixe qui sont destinés en particulier à établir une téléconférence sur l'Internet.

Le système 100 est identique pour tous les exemples de réalisation, qui sont expliqués en détail dans la suite, jusqu'aux conformations différentes du serveur concentrateur (Focus) qui est conçu à chaque fois de façon à implémenter les fonctionnalités des exemples de réalisation respectifs.

Les unités individuelles décrites dans la suite peuvent être implémentées à chaque fois dans des unités matérielles individuelles séparées, par exemple dans des terminaux informatiques ou de téléphonie mobiles autonomes ou au moins partiellement sous forme logicielle, c'est- à-dire au moyen de programmes informatiques qui sont implémentés dans des unités informatiques séparées ou communes.

Le système de communication est conformé, jusqu'aux modifications décrites ci-dessous selon les modes de réalisation de l'invention, comme décrit en [1].

Le Conferencing Framework , décrit en [1] et représenté dans la figure 1, propose aux utilisateurs, en particulier aux terminaux de téléphonie mobile 101, 102, 103, 104, différents services de téléconférence multimédia. En particulier, comme décrit en détail dans [1], un service de commande des droits d'accès à des ressources de téléconférence, également désigné par Floor Control, un service d'établissement de règles de conférence (qui sont également désignés par Conference Policy Control), ainsi que sous forme de procédures reposant sur le Session Initiation Protocol (SIP) sont des services supplémentaires destinés à ouvrir, gérer, aborder et quitter des téléconférences multimédia.

En outre, le système de communication 100, comme décrit également en [1], propose des méthodes d'avertissement des participants 101, 102, 103, 104 à une conférence, également désigné par Conference Notification Service, relatif à des informations et événements (Events) spécifiques concernant une téléconférence multimédia respective.

Le système de conférence 100 est conçu de telle sorte que des média de types quelconques peuvent être échangés entre les participants, c'est-àdire entre les terminaux de téléphonie mobile 101, 102, 103, 104. Des exemples de type de média, qui peuvent être transmis et traités dans le cadre du système de conférence 100, sont des données audio, des données vidéo, des données Instant Messaging et des données de jeux Multiplayer dans le cadre d'une conférence Gaming.

La figure 1 représente, comme décrit ci-dessus, le système de téléconférence multimédia 100 selon les exemples de réalisation de l'invention avec ses composants individuels et l'interaction entre les composants.

Le système de téléconférence multimédia 100 comporte une architecture de conférence en étoile dans laquelle tous les participants à la conférence (également désignés par User Agents), selon ces exemples de réalisation des terminaux de téléphonie mobile 101, 102, 103, 104, sont reliés au serveur de conférences 105, également désigné par concentrateur (Focus) 105, au moyen d'une liaison de signalisation SIP 106. La figure 1 ne représente cependant qu'un seul exemple de ces liaisons de signalisation SIP 106.

Une adresse de conférence unique, ladite Conference-Unique Resource Identifier (C-URI), est associée à une téléconférence par téléphonie mobile déterminée respective qui est associée à un ordinateur serveur de conférence déterminé 105, c'est-à- dire un concentrateur (Focus) déterminé, ou est réalisée sur celui-ci. Le C-URI représente et adresse la conférence respective de façon univoque. Le concentrateur (Focus) 105 a entre autres un accès direct au Conference Policy. Le fichier Conference Policy, désigné également dans la suite par fichier de règles de conférence 108, se compose d'habitude logiquement de deux sous-régions, un Membership-Policy 109 et un Media- Policy 110. Le fichier Conference-Policy peut cependant être mémorisé en étant réparti physiquement dans certaines circonstances entre plusieurs sous-fichiers. En plus de la séparation physique, on peut également effectuer une séparation logique du fichier Conference- Policy. Le fichier de règles de conférence 108 est généré exclusivement par un serveur de règles de conférence (Conference Policy Server) 111 destinés à une conférence respective, symbolisée dans la figure 1 par une flèche 112. Le concentrateur (Focus) 105 est informé du contenu et de chaque modification du fichier Conference Policy par le serveur de règles de conférence. On peut également imaginer que le concentrateur (Focus) 105 a directement accès au fichier Conference Policy.

En plus de la transformation de ces règles de conférence mémorisées dans le fichier de règles de conférence 108, le concentrateur (Focus) 105 a pour tâche de veiller à la répartition, spécifique à la conférence, des flux de données de média.

Pour effectuer la répartition des flux de données de média, le concentrateur (Focus) 105 utilise ce que l'on appelle un mélangeur (Mixer) 113, en d'autres termes, des dispositifs de mélange de flux de données qui réalisent, en utilisant les règles de média mémorisées dans le Media Policy 110, la composition individuelle et la répartition des flux de données de média entre les terminaux de téléphonie mobile 101, 102, 103, 104 participant à la conférence, qui sont symbolisés dans la figure 1 par les doubles flèches 114, 115, 116 et 117.

Dans les terminaux de téléphonie mobile 101, 102, 103, 104 sont implémentés certain nombre de procédures, de protocoles de communication et de fonctionnalités supplémentaires, pour l'établissement du service de conférence, en particulier de nouvelles procédures SIP supplémentaires ainsi que ce que l'on appelle le Binary Floor Control Protocol (BFCP), implémenté du côté du serveur dans un Floor Control Server 118, et le Conference Police Control Protocol (CPCP) ou les unités respectives qui sont en mesure de réaliser les protocoles de communication correspondants. La liaison de communication Binary Floor Control Protocol entre un premier terminal de téléphonie mobile 101 et le Floor Control Server 118 est symbolisée dans la figure 1 par une flèche 119.

Ainsi, chaque détail de ces procédures et protocoles est important pour le terminal de téléphonie mobile (terminal mobile) 101, 102, 103, 104 et donc les matériels et/ou logiciels utilisés dans le terminal.

Le Conference Policy Control Protocol (CPCP), décrit dans [5], offre la possibilité de définir différentes règles pour une téléconférence multimédia. Ainsi, par exemple, des règles de conférence générales, comme par exemple le nombre maximum de participants à la conférence, peuvent être indiquées à l'intérieur du fichier de règles de conférence (Conference Policy) au moyen du CPCP. Le fichier de règles de conférence contient en outre par exemple ce que l'on appelle une liste dial-out (éléments de données <dial-out-list>) qui indique, lors d'une activation d'une conférence, quels utilisateurs ou quels terminaux de télécommunications sont invités à cette conférence.

Le Conference Policy contient en outre des éléments de données d'autorisation permettant d'indiquer quel utilisateur 25 peut inscrire d'autres utilisateurs dans la liste dial-out (élément de données <allow-modify-dol>).

Pour déterminer qui est autorisé à traiter des éléments de données d'autorisation, il est prévu selon CPCP un élément de données d'autorisation de niveau supérieur qui réglemente l'accès à tous les autres éléments de données d'autorisation (élément de données <allowmodify-authorization-rules>).

Le fichier de règles de conférence est indiqué sous la forme d'au moins un document XML (fichier Extensible Markup Language). En raison de l'utilisation de XML pour écrire le fichier de règles de conférence 108, il est possible d'élargir de façon simple le fichier de règles de conférence, d'une façon générale de le modifier.

Pour transférer des fichiers XML, c'est-à-dire en particulier le fichier de règles de conférence 108 ou pour lire et/ou écrire des données dans le fichier de règles de conférence 108, on utilise le Hypertext Transport Protocol (HTTP).

L'écriture d'un fichier de règles de conférence 108 ou l'écriture dans un fichier de règles de conférence 108 est effectuée au moyen d'un HTTP Put Request, tandis que pour lire un fichier de règles de conférence 108 ou une partie d'un fichier de règles de conférence 108 on utilise HTTP Get Request et pour effacer tout un fichier de règles de conférence 108 ou une partie du fichier de règles de conférence 108 on utilise un HTTP Delete Request.

Le CPCP permet en outre d'adresser des éléments individuels, des attributs ou des valeurs d'attribut d'un document XML et donc du fichier de règles de conférence 108 selon cet exemple de réalisation de l'invention au moyen du HTTP Unique Resource Locator (HTTP URL).

La structure d'un fichier de règles de conférence 108 en XML est expliquée en détail dans la suite; la structure de base d'un tel fichier de règles de conférence 108 est identique à celle enseignée dans [5].

Les règles de conférence sont écrites dans le fichier de règles de conférence 108.

Le fichier de règles de conférence 108 comporte différents éléments de données, par exemple l'élément de données <info> dans lequel sont contenues des informations Freitext générales relatives à la téléconférence multimédia respective, l'élément de données <settigs> dans lequel sont indiquées entre autres l'adresse de la conférence (sousélément de données <conference-uri>) et le nombre maximum de participants à la conférence (sous-élément de données <max-participants-count>), l'élément de données <authorization-rules> qui contient les éléments de données d'autorisation individuels et en outre par exemple l'élément de données <dial-out-list> qui établit la liste des participants à inviter à la conférence respective.

Un fichier de règles de conférence 108 selon un premier exemple de réalisation de l'invention au format XML est représenté ci-dessous.

<?xml version="1.0" encoding="UTF-8"?> <conference xmlns="urn:ietf:params:xml:ns:conference-policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <settings> <conference- uri>sip:myconference@example.com</conference-uri> <max-participant-count> 10</max-participant-count> <allow-sidebars>true</allow-sidebars> </settings> <info xml:lang="en-us"> <subject>What's happening tonight</subject> <display-name>Party Goer's</display-name> <free-text>John and Peter will foin the conference soon</free-text> <keywords>party nightclub beer</keywords> <host-info> <uri>sip:Alice@example.com</uri> <uri>tel:+3581234567</uri> <e-mail> mailto:Alice@example.com</e-mail> <webpage>http://www.example.com/users/Alice</web-page> </host-info> </info> <time> <occurrence> <mixing-start-time requiredparticipant="participant">2004-1217T09:30:0005:00</mixing-start-time> <mixing-stop-time requiredparticipant="none">2004-12-17T12:30:00- 05:00</mixing-stop-time> <can-join-after>2001-12-17709:25:00-05:00</can- join-after> <must--join-before>2004-12-17T12:00:00- 05:00</must-join-before> <request-users requiredparticipant="none">2001-12-17T09:30:0005:00<. /request-users> </occurrence> </time> <authorization-rules> <rule id="1"> <conditions> <identity> <domain>example.com</domain> </identity> </conditions> <actions> <allow-conference-state>true</allow-conferencestate> <join-handling>allow</join-handling> </actions> <transformations/> </rule> <rule id="2"> <conditions> <identity> <id>alice@example.com</id> </identity> </conditions> <actions> <allow-sidebar>true</allow-sidebar> </actions> <transformations> <is-key-participant>true</is-key-participant> </transformations> </rule> <rule id="3"> <conditions> <identity> <id>alice@example.com</id> </identity> </conditions> <actions> <allow-modify-tl>true</allow-modify-tl> </actions> <transformations/> </rule> </authorization-rules> <terminate-list> <target uri="sip:alice@example.com"> <target uri="sip: eckbertowitsch@example.com"> <target uri="sip: schwagomilinski@ostfriesland.de"> </terminate-list> <dialout-list> <target uri="sip:bob@example.com"/> </dialout-list> <refer-list> <target uri="sip:sarah@example.com"/> </refer-list> <security-control> <security-mechanism tls="false" s-mime="true"/> <pin>13579</pin> <password>abcdl234</password> </security-control> <floor-policy> <floor floor-control="fcp://example.com/floorabc" 5 moderatorcontrolled="false"> <media-streams> <audio media-id="2"/> </media-streams> <algorithm> <fcfs/> </algorithm> <max-floor-users>l</max-floor-users> </floor> </floor-policy> <media-streams> <video media-id="l"/> <audio media-id="2"/> </media-streams> </conference> Fichier de règles de conférence Exemple 2 L'exemple ci- dessus correspond sensiblement à l'exemple décrit dans l'état de la technique (Fichier de règles de conférence Exemple 1) ; les modifications, apportées dans cet exemple de réalisation par rapport à l'état de la technique, représentées en caractères gras et soulignés.

Selon le premier exemple de réalisation de l'invention, il est prévu un nouvel élément de données de règles de conférence supplémentaire (nouvel élément Conference Policy) permettant d'indiquer quel participant est autorisé à clôturer la conférence en cours.

<terminate-list> <target uri="sip:alice@example.com"> <target uri="sip: eckbertowitsch@example.com"> <target uri="sip: schwagomilinski@ostfriesland.de"> </terminate-list> Dans cet exemple, les participants alice@example.com , eckbertowitsch@example.com et schwagomilinki@ostfriesland.de sont autorisés à clôturer la conférence en cours.

A cet égard, il faut mentionner que, pour chaque conférence activée en cours, il est prévu et généré un fichier de règles de conférence qui est de nouveau effacé à la clôture de la conférence respective.

En outre, un élément de données d'autorisation supplémentaires est décrit en option dans Fichier de règle de conférence Exemple 2 permettant de déterminer quel participant peut désigner de nouveaux participants comme étant autorisés à effectuer la clôture.

<rule id="3"> <conditions> <identity> <id>alice@example.com</id> </identity> </conditions> <actions> <allow-modify-tl>true</allow-modify-tl> </actions> <transformations!> <truie> Dans cet exemple, la participante alice@example.com est autorisée à modifier les autorisations de clôture, c'est-à-dire à autoriser un autre participant à clôturer une conférence ou à retirer cette autorisation à un autre participant.

L'élément de données de règles de conférence, désigné dans l'exemple 2 cidessus par terminate-list comporte donc, comme décrit ci-dessus, trois participants qui sont indiqués dans cet exemple de réalisation par leur SIP-URI respectif, sans que cela ait un. caractère général. Les trois utilisateurs sont autorisés dans cet exemple de réalisation de l'invention à clôturer la conférence ouverte. Dans cet exemple, la personne qui a ouvert la conférence, désignée ici par Alice (cf. fichier de règles de conférence exemple 2 , <target uri= sip:alice@example.com >) est également représentée dans l'élément de données <terminate-list>. Une réinterprétation du <terminate-list> permet à cette liste d'indiquer quel utilisateur est autorisé à arrêter la téléconférence multimédia.

Dans une variante de conformation de l'invention, il est cependant prévu que les personnes qui ont ouvert une conférence respective ne doivent pas s'inscrire individuellement dans la liste, c'est-à-dire dans l'élément de données <terminate-list>, mais sont généralement autorisés selon une règle qui est valide d'une façon générale, mais pas d'une façon individuelle, à clôturer la conférence respective qui a été ouverte par ces personnes.

Dans ce cas, l'élément de données <terminate-ist> décrit ici ne contiendrait que les participants (utilisateurs) qui sont autorisés, en plus de la personne qui a ouvert la conférence, à clôturer ou interrompre la conférence.

Le serveur de règles de conférence 111, qui gère le fichier de règles de conférence, comme décrit en [1], [2] et [5], vérifiera donc, après réception d'un message HTTP Delete pour la clôture de la conférence (cf. 2), si la requête provient d'un participant représenté dans l'élément de données <termiate-list>.

À cet égard, il faut mentionner que l'expression utilisateur ou participant n'est pas limité à des appareils de télécommunications participant réellement à la conférence ou à des utilisateurs des appareils de télécommunications mais englobe le cas échéant tous les participants autorisés et enregistrés dans le réseau de téléphonie mobile. Il faut en outre mentionner que l'expression utilisateur ou participant désigne aussi bien un terminal de télécommunications respectif, par exemple le terminal de téléphonie mobile 101, 102, 103, 104 ou le cas échéant l'utilisateur de l'appareil de télécommunications respectif.

Si la requête vient d'un participant représenté dans l'élément de données <terminate-list>, le serveur de règles de conférence efface alors le Conference Police Document, c'est-à-dire le fichier de règles de conférence 108 et informe l'ordinateur serveur de conférence 105, c'est-àdire le concentrateur (Focus), de la clôture de la conférence ou de l'interruption de la conférence. Dans le cas d'une clôture, le concentrateur (Focus) 105 arrête toutes les SIP-Sessions 106 (Sessions SIP) ou dialogues, liés à cette conférence, c'est-à-dire qu'il écarte de la conférence tous les participants à la conférence et libère de nouveau toutes les ressources de conférence utilisées.

Ce mode opératoire est encore représenté dans un organigramme 200 de la figure 2 et est expliqué en détail dans la suite.

Dans la figure 2, il est représenté à titre d'exemple trois terminaux de téléphonie mobile 101, 102, 103, le concentrateur (Focus) 105, le serveur de règles de conférence 111 ainsi que le fichier de règles de conférence 108. Un bloc 201 dans l'organigramme 200 indique symboliquement qu'une conférence, organisée et dirigée par le concentrateur (Focus) et le serveur de règles de conférence 111, est activée et organisée entre les terminaux de téléphonie mobile 101,102, 103.

Il est généré et mémorisé, en rapport avec la conférence, un fichier de règles de conférence 108 dans lequel sont mémorisés les droits individuels et informations supplémentaires liés à cette conférence.

Dans cet exemple de réalisation, on suppose que le deuxième terminal de téléphonie mobile 102 transmet un message de demande de clôture 202 au serveur de règles de conférence 111 puis ce dernier vérifie, en lisant en 203 et 204 les informations correspondantes dans le fichier de règles de conférence mémorisé 108, si l'utilisateur, dans ce cas le deuxième terminal de téléphonie mobile 102, est autorisé à interrompre ou clôturer la conférence.

En d'autres termes, le serveur de règles de conférence 111 vérifie si le deuxième terminal de téléphonie mobile 102 ou son utilisateur est contenu dans l'élément de données <terminate-list> dans le fichier de règles de conférence 108. Après vérification du fichier de règles de conférence 108 par le serveur de règles de conférence 111, symbolisée dans la figure 2 par un message de lecture de <terminate-list> 103 et un message d'élément de données <terminate-list> 204 contenant les éléments de données <terminate-list>, ce serveur de règles de conférence décide si le participant envoyant la requête est autorisée à clôturer ou interrompre la conférence (Etape de vérification 205).

Si ce n'est pas le cas, le serveur de règles de conférence 111 génère un message de confirmation négatif 206 qu'il transmet au deuxième terminal de téléphonie mobile 102 et donc au participant ayant demandé la clôture de la conférence.

Cependant, une fois la vérification effectuée à l'étape de vérification 205, si le participant est autorisé à clôturer ou interrompre la conférence, le serveur de règles de conférence 111 envoie alors un message de clôture de conférence ou un message de suspension de conférence 270 au concentrateur (Focus) 105 et, lors de la clôture de la conférence, il efface le fichier de règles de conférence 108 (Etape 213). Lors de l'interruption de la conférence, qui est expliquée en détail dans la suite, le fichier de règles de conférence 108 n'est cependant pas effacé.

Le concentrateur (Focus) 105 efface la conférence, à la réception du message de clôture de conférence 207 provenant du serveur de règles de conférence 111, et envoie des messages de clôture de sessions SIP correspondants 208, par exemple à chaque fois un message SIP BYE aux terminaux de téléphonie mobile 101, 102, 103 participant à la conférence. Ensuite, les ressources de conférence et les C-URI sont de nouveau libérés (Etape 209). Si la réinterprétation décrite ci-dessus est utilisée, c'est-à-dire si la conférence est suspendue, le CURI n'est pas libéré.

Après réception des messages de clôture de conférence 208, la participation à la conférence respective est également arrêtée pour chaque terminal de téléphonie mobile 101, 102, 103. La libération des ressources de conférence est représentée ici par les blocs 210, le bloc 211 et le bloc 212.

Comme représenté également dans le Fichier de règles de conférence Exemple 2 , il est prévu en option un élément de données d'autorisation supplémentaire <allow-modify-tl>.

Cet élément de données d'autorisation détermine quel utilisateur peut inscrire un autre utilisateur dans l'élément de données <terminate-list> et/ou exclure un autre utilisateur de l'élément de données <terminatelist.

Comme il ressort du Fichier de règles de conférence exemple 2 , un élément de données d'autorisation correspondant et donc une règle d'autorisation correspondante sont établis pour le participant Alice , c'est-à-dire que Alice peut autoriser d'autres utilisateurs à clôturer ou arrêter et/ou interrompre la conférence.

De même, dans ce cas, il est prévu dans une variante de conformation de l'invention qu'il n'est pas nécessaire d'inscrire la personne qui a ouvert la conférence, comme décrit ci-dessus, pour les éléments de données <allow-modify- tl> mais que d'autres utilisateurs sont inscrits dans cetteliste qui seront autorisées, en plus de la personne qui a ouvert la conférence, à inscrire d'autres utilisateurs dans le <terminate-list> et/ou à exclure d'autres utilisateurs, c'est-à-dire écarter, du <terminate-list>. La personne qui a ouvert la conférence est dans ce cas généralement autorisée à effectuer ces actions.

La figure 3 représente dans un deuxième organigramme 300 du premier exemple de réalisation de l'invention le déroulement de la modification des droits de clôture dans le fichier de règles de conférence 108.

Dans les figures, des éléments identiques ou similaires portes les mêmes références.

Lors d'une conférence active 201, on suppose que le troisième terminal de téléphonie mobile 103 génère un message de demande de modification de droit 301 et le transmet au serveur de règles de conférence 111 qui vérifie, au moyen du message de lecture 302, si l'élément de données <allow-modifytl> pour le terminal de téléphonie mobile 103 effectuant la requête est mis à la valeur true , c'est-à-dire si la demande de modification de droit peut être approuvée. En d'autres termes, on vérifie si le troisième terminal de téléphonie mobile 103 est autorisé à réaliser ou demander une modification des droits de clôture ou des droits d'interruption dans le fichier de règles de conférence 108. La lecture des informations correspondantes dans le fichier de règles de conférence 108 est représentée symboliquement au moyen du message de lecture <allowmodify-tl> 302 et du message d'élément de données <allow-modify-tl> 303.

Si le troisième terminal de téléphonie mobile 103 ou son utilisateur est autorisé à procéder à la modification demandée des droits de clôture ou des droits d'interruption dans le fichier de règles de conférence 108, les données modifiées souhaitées sont alors écrites dans l'élément de données <terminate-list>, symbolisé dans la figure 3 par un message d'écriture <terminate-list> 305 et la conférence se poursuivit.

Cependant, si la demande n'est pas justifiée, c'est-à-dire en d'autres termes si le troisième terminal de téléphonie mobile 103 ne possède pas les droits d'accès nécessaires à la modification des droits de clôture ou des droits d'interruption dans le fichier de règles de conférence 108, le serveur de règles de conférence 111 génère alors un message de confirmation négatif correspondant 306 et l'envoie au troisième terminal de téléphonie mobile 103 et la conférence se poursuit sans changement.

Selon un deuxième exemple de réalisation de l'invention, il est prévu, pour définir un nouvel élément de données de règles de conférence (Eléments Conference-Policy), de définir deux nouvelles actions à l'intérieur de l'élément <autorisation-rules>.

La première action de ce deuxième exemple de réalisation de l'invention, désignée par élément de données terminatehandling>, indique au concentrateur (Focus) 105 comment traiter une requête de clôture de la conférence. Le sous-élément de données <terminate-handling> possède dans cet exemple de réalisation de l'invention au moins deux valeurs, c'est-àdire une première valeur Allow et une deuxième valeur Confirm .

Si le serveur de règles de conférence 111 reçoit une requête de clôture de conférence, ce qui est synonyme de tentative d'effacement du fichier de règles de conférence 108, cette requête est réalisée lorsque, pour l'utilisateur correspondant qui fait la requête, l'élément de données <terminate-handling> contient la première valeur Allow . Dans ce cas, le serveur de règles de conférence 111 effacera le fichier de règles de conférence 108 et indiquera au concentrateur (Focus) 105 de arrêter la conférence, c'est-à- dire d'effectuer la clôture. Si la réinterprétation décrite ci-dessus est utilisée, la conférence n'est alors pas terminée mais est suspendue ou interrompue.

Dans ce cas, l'utilisateur en est informé du sous-élément de données <conditions de l'élément de règles dans le Fichier de règles de conférence 108 représenté à titre d'exemple par le Fichier de règles de conférence Exemple 3 .

Si l'élément de données <terminate-handling> contient la tribu Confirm , la personne qui a ouvert la conférence ou un autre utilisateur qui a le droit de clôturer la conférence, par exemple un utilisateur pour lequel l'élément de données <terminate-handling> est mis à la première valeur Allow , obtient dans cet exemple de réalisation de l'invention une autorisation correspondante de clôturer ou d'interrompu la conférence.

Dans ce cas, la conférence n'est donc arrêtée que lorsque la requête a été préalablement satisfaite par une instance autorisée. D'autres conditions peuvent également être rattachées à l'autorisation de clôture ou d'interruption de la conférence, et donc à la valeur Allow .

Il peut encore être demandé de fournir par exemple par un mot de passe et/ou un PIN (Personal Identification Number) . <rule id="3"> <conditions> <identity> <id>eckbertowitsch@example.com</id> </identity> </password>storno</password> </conditions> <actions> <allow-modify-tl>true</allow-modify-tl> <terminate-handling> allow</terminate-handling> </actions> <transformations/> </rule> <rule id="4"> <conditions> <pin>211172</pin> </conditions> <actions> <terminate-handling>allow</terminate-handling> </actions> <transformations/> </rule> Comme représenté dans l'exemple 3, il est également prévu dans cet exemple de réalisation de l'invention en option un nouvel élément de données d'autorisation <allow-modify-tl> qui comporte le même élément de données d'autorisation décrit en relation avec le premier exemple de réalisation. Cet élément de données d'autorisation détermine quel utilisateur peut fixer les attributs Allow et Confirm dans l'élément de données terminate-handling .

<allow-modify-tl>true</allow-modify-tl> Un exemple du fichier de règles de conférence 108 30 représenté dans la suite selon le deuxième exemple de réalisation de l'invention.

<?xml version="1.0" encoding="UTF-8"?> <conference xmins="urn:ietf:params:xml:ns:conference-policy" 10 15 xmins:xsi="http://www.w3.org/2001/XMLSchema-instance"> <settings> <conference- uri>sip:myconference@exarnple.com</conference-uri> <max-participant-count> 10</max-participant-count> <ailow-sidebars>true</allow-sidebars> </settings> <info xml:lang="en-us"> <subject>What's happening tonight</subject> <display-name>Party Goer's</display-name> <free-text>John and Peter will foin the conference soon</free-text> <keywords>party nightclub beer</keywords> <host-info> <uri>sip:Alice@exarnple.com</uri> <uri>tel:+3581234567</uri> <e-rnail> mailto:Alice@exarnple.com</e-rnail> <webpage>http://www.exarnple.com/users/Alice</web-page> </host-info> </info> <time> <occurrence> <mixing-start-time requiredparticipant="participant">2004-12-17T09:30:00-05:00</mixing-start-time> <mixing-stop-time required-participant="none">200412-17712:30:00-05:00</mixing-stop-time> <can-join-after>2001-12-17T09:25:00-05:00 join-after> 30 <must-joinbefore>2004-12-17712:00:00-05:00</must- join-before> <request-users required-participant="none">2001-12-17T09:30:00- 05:00</request-users> 10 15 20 </occurrence> </time> <authorization-rules> <rule id="1"> <conditions> <identity> <domain>example.com</domain> </identity> </conditions> <actions> <allow-conference-state>true</allowconference-state> <join-handling>allow</foin-handling> </actions> <transformations/> </rule> <rule id="2"> <conditions> <identity> <id>alice@example.com</id> </identity> </conditions> <actions> <allow-sidebar>true</allow-sidebar> <allow-modify-tl>true</allow-modify- tl> <terminate-handling>allow</terminate- handling> </actions> <transformations> <is-key-participant>true</is-keyparticipant> </transformations> </rule> <rule id="3"> <conditions> <identity> <id>eckbertowitsch@example.com</id> </identity> </password>storno</password> </conditions> <actions> <allow-modify-tl>true</allow-modify-tl> <terminate-handling> allow</terminate- handling> </actions> <transformations/> </rule> <rule id="4"> <conditions> <pin>211172</pin> </conditions> <actions> <terminate-handling>allow</terminate- handling> </actions> <transformations/> </rule> </authorization-rules> <dialout-list> <target uri="sip:bob@example.com"/> </dialout-list> <refer-list> <target uri="sip:sarah@example.com"/> </refer-list> <security-control> <security-mechanism tls="false" s-mime="true"/> <pin>13579</pin> <password>abcdl234</password> </security-control> <floor-policy> <floor floor-control="fcp://example.com/floorabc" moderator- controlled=="false"> <media-streams> <audio media-id="2"/> </media-streams> <algorithm> <fcfs/> </algorithm> <max-floor-users>1</max-floor-users> </floor> </floor-policy> <media-streams> <video media-id="1"/> <audio media-id="2"/> </media-streams> </conference> Fichier de règles de conférence Exemple 3 L'exemple ci- dessus correspond sensiblement à l'exemple décrit dans l'état de la technique (Fichier de règles de conférence Exemple 1) ; les modifications apportées dans cet exemple de réalisation par rapport à l'état de la technique sont représentées en caractères gras et soulignés.

La figure 4 représente dans un organigramme 400 le mode opératoire de la vérification de l'autorisation de clôture d'une conférence selon le deuxième exemple de réalisation de l'invention.

On part là encore d'une conférence, symbolisée par le bloc 201, entre les terminaux de téléphonie mobile 101, 102, 103, laquelle conférence est activée, dirigée, organisée et commandée par le concentrateur (Focus) 105 et le serveur de 10 15 règles de conférence 111.

Il est donc généré et mémorisé, en rapport avec la conférence, un fichier de règles de conférence 108 dans lequel sont mémorisés les droits individuels et informations supplémentaires liés à cette conférence.

Après réception du message de demande de clôture 202 par le troisième terminal de téléphonie mobile 103, le serveur de règles de conférence 111 vérifie tout d'abord si un Personnal Identification Number (PIN) est contenu dans le message de demande de clôture 202 (Etat de vérification 401).

Si c'est le cas, le serveur de règles de conférence 111 vérifie alors, en lisant le fichier de règles de conférence 108, des éléments de données mémorisés (symbolisés dans la figure 4 par un message de demande d'éléments de données PIN 402 et par un message d'éléments de données PIN 403), dans une deuxième étape de vérification 404, si le PIN contenu dans le message de demande de clôture 202 est identique à l'un des PIN caractérisés comme autorisés dans le fichier de règles de conférence 208.

Si c'est le cas, la conférence est alors arrêtée et le serveur de règles de conférence 111 informe le concentrateur (Focus) de la clôture de la conférence par le message de clôture de conférence 270, puis le concentrateur (Focus) 105 transmet les messages de clôture de conférence 208, décrits ci-dessus en rapport avec le premier exemple de réalisation, aux terminaux de téléphonie mobile individuels qui participent à la téléconférence. Les ressources de conférence sont également délivrées en cas de clôture (Etape 209). En outre, le fichier de règles de conférence 108 est le cas échéant effacé par le serveur de règles de conférence 111 (Bloc 213). En d'autres termes, les étapes désignées dans la figure 2 par la caractéristique A sont réalisées.

Cependant, si le message de demande de clôture 203 ne contient aucun PIN ou si le PIN contenu dans le message de demande de clôture 202 ne concorde pas avec le PIN mémorisé dans le fichier de règles de conférence 108, le serveur de règles de conférence 111 vérifie alors si une donnée d'identité d'expéditeur du message de demande de clôture 202 est contenu dans ce message (Etape de vérification 405).

Si c'est le cas, l'élément de règles pour cette donnée d'identité d'expéditeur est lu au moyen du message de demande 406 et 407 et vérifie si l'élément de règles <terminatehandling> provenant du fichier de règles de conférence 108 est mis à Allow (Etape de vérification 408).

Si ce n'est pas le cas ou si aucune donnée d'identification du participant envoyant le message de demande de clôture n'est contenue dans le message de demande de clôture 102, un message de confirmation négatif 409 est alors généré par le serveur de règle de conférence et est transmis le cas échéant à l'expéditeur du message de demande de clôture 202 pour lui faire savoir que la demande a été rejetée.

Cependant, si la donnée l'identification concorde avec une donnée d'identification dans l'élément de données <terminate- list>, on vérifie alors dans une étape suivante (Etape de vérification 410) sir le participant en question a encore besoin d'une donnée d'autorisation supplémentaire, par exemple d'un mot de passe, et si ce mot de passe est contenu dans le message de demande de clôture 202 et correspond à la donnée de mot de passe contenu dans le fichier de règles de conférence 108.

Si aucun mot de passe n'est nécessaire mais si le participant a le droit d'obtenir la clôture demandée, sans donnée d'autorisation supplémentaire, la conférence est alors 30 arrêtée de la façon décrite ci-dessus (Etape A) .

Cependant, si un mot de passe nécessaire et si ce mot de passe ne concorde pas avec le mot de passe correspondant mémorisé dans le fichier de règles de conférence 108, ce qui est vérifié dans une étape de vérification (Etape de vérification 411), le serveur de règles de conférence 111 génère de nouveau un message de confirmation négatif 409 et le transmet au participant correspondant, dans ce cas au troisième terminal de téléphonie mobile 103.

Dans tous les cas où la clôture n'a pas pu être effectuée, la conférence est poursuivie sans changement.

Cependant, si le mot de passe vérifié à l'étape de vérification 411 est correct, c'est-à-dire si le mot de passe indiqué dans le message de demande de clôture 202 correspond au mot de passe correspondant associé au participant respectif dans le fichier de règles de conférence 108, la conférence est arrêtée, là encore de la façon décrite ci-dessus (Etape A).

Dans un mode opératoire correspondant, selon le deuxième exemple de réalisation de l'invention, une modification des droits peut également être effectuée dans le fichier de règles de conférence.

L'exemple 3 ci-dessus représente le Conference Policy Document, élargi selon l'exemple de réalisation de l'invention, c'est-à-dire le fichier de règles de conférence 108 selon le troisième exemple de réalisation de l'invention.

L'élément de règles de Alice a été élargi dans ce cas. D'une façon générale, plusieurs actions peuvent être indiquées dans un élément de règles mais, pour chaque action, on définit un nouvel élément, comme décrit par exemple dans [5].

Selon cet exemple de réalisation de l'invention, la participante Alice a maintenant de nouveau le droit, au moyen de l'action <allow-modify-tl>true</allow-modify-tl>, de poser une règle et donc de la mémoriser dans le fichier de règles de conférence 108 au moyen du serveur de règles de conférence 111, dans laquelle se trouve le sous-élément de données <terminate-handling>. La participante Alice peut donc donner à un autre utilisateur le droit de clôturer la conférence.

Simultanément, la participante Alice est autorisé au moyen de <terminate-handling>allow</terminate-handling> d'arrêter la conférence, c'est-à-dire de la clôturer ou de 5 l'interrompre.

Dans cet exemple de réalisation, on attribue à l'utilisateur spécifié pr le SIP-URI eckbertowitsch@example.com (Rule ID= 3 les mêmes droits qu'au participant Alice <rule id= 3 > <conditions> <identity> <id>eckbertowitsch@example.com</id> <identity> </pas sword>storno</password> </conditions> <actions> <allow-modify-tl>true</allow-modify-tl> <terminate-handling> allow</terminatehandling> </actions> <transformations/> </rule> Cependant, cet utilisateur doit en plus s'identifier, au moyen du mot de passe storno , comme décrit par exemple ci- dessus par référence à l'organigramme 400 dans la figure 4.

Selon les règles 4 de l'Exemple 3 ci-dessus dans le fichier de règles de conférence 108 (rule ID= 4 ), tous les utilisateurs identifiés au moyen du PIN 211172 peuvent clôturer la conférence: <rule id= 4 > <conditions> <pin>211172</pin> </conditions> <actions> <terminate-handling>allow</terminate-handling> </actions> <transformations!> </rule> Dans des variantes de réalisation de l'invention, il est prévu de mettre en oeuvre les procédés décrits cidessus de 10 façon combinée.

En outre, dans d'autres aux variantes de conformation de l'invention, il est prévu de modifier les procédés décrits ci-dessus de façon à ne pas déterminer dans chaque cas qui peut clôturer la conférence.

Dans ce cas, il est prévu une subdivision supplémentaire clôture/interruption ou une réinterprétation.

Si la conférence est ce que l'on appelle une conférence limitée (Bounded Conference), il peut alors être prévu d'utiliser les éléments décrits cidessus pour déterminer qui peut interrompre (arrêter) l'événement de conférence actuel (contrairement à la clôture décrite ci-dessus).

Ceci est un perfectionnement des procédés décrits ci-dessus.

Il faut indiquer que l'on peut fondamentalement faire la distinction entre une conférence limitée (Bounded Conference) et une conférence non limitée (Unbounded Conference).

Une conférence limitée existe pour un laps de temps prédéterminé et inclut par exemple des conférences hebdomadaires. Si la fin d'une conférence limitée est atteinte, tous les participants sont écartés de la conférence et toutes les sessions SIP ou dialogues des participants, concernant cette conférence, sont terminés, comme décrit dans [5]. La conférence en soi et donc également le Conference Police, c'est-à-dire les règles de conférence, restent cependant maintenus, c'est-à-dire qu'il n'y a pas de clôture de conférence. Ce cas peut être désigné par interruption de la conférence (Arrêt).

Si on arrête, c'est-à-dire on clôture, une conférence, la 5 conférence de l'instance, c'est à dire le concentrateur (Focus) et entre autres le fichier de règles de conférence 18 est terminé respectivement effacé.

Pour chaque événement de conférence (un événement de conférence est défini par les sous-éléments de données <occurrence> qui contiennent entre autres l'heure de début et l'heure de fin de la conférence), une indication séparée de la part de participants pouvant terminer ou arrêter l'événement de conférence correspondant avant son déroulement est effectuée par une référence au sous élément de données <occurrence> de l'élément de données <temps> du fichier de règle de conférence, ou à l'intérieur de ce sous-élément.

Les éléments de données d'autorisation décrits ci-dessus selon les exemples de réalisation de l'invention sont dans ce cas dotés d'un autre index dans lequel il est spécifié de façon univoque l'événement de conférence concernant cet élément d'autorisation. Ceci est effectué par exemple au moyen d'une référence.

Selon le deuxième exemple de réalisation, par exemple de la façon suivante: <allow-modify-tl conference-event= 2 > et <terminate-handling conference-event= 2 >allow</terminatehandling>, ce qui permet d'indiquer que ces droits concerne le deuxième 30 sous-élément <occurrence>.

De cette façon, un utilisateur peut être autorisé à arrêter la conférence à l'intérieur d'un événement de conférence déterminé alors que, dans certaines circonstances, il n'a pas ce droit à l'intérieur d'un autre événement de conférence. De cette façon, il est possible de signaler ou réaliser de façon très simple l'interruption d'une partie d'une téléconférence.

Selon le premier exemple de réalisation de l'invention, il est donc prévu dans une variante de réalisation de l'invention plusieurs listes, par exemple <terminate-list conferenceevent= 2 >, dans lesquelles il est indiqué des utilisateurs qui peuvent arrêter cet élément de conférence correspondant. Dans ce cas, selon le premier exemple de réalisation, plusieurs éléments de données <terminate-list> peuvent être contenus dans le fichier de règles de conférence 108. Ces éléments de données se distinguent par l'attribut <conferenceevent>.

Dans une variante de conformation de l'invention, chaque sous-élément de données <occurrence> peut cependant contenir également un élément de données <terminate-list> propre. Dans ce cas, aucun attribut <conferenceevent> n'est une nécessaire dans l'élément de données <terminate-list> respectif.

L'élément de données d'autorisation doit cependant contenir également dans ce cas l'index décrit ci-dessus.

Dans une variante de conformation de l'invention ou en plus des conformations de l'invention décrites ci-dessus, il est prévu, le cas échéant en plus de l'indication concernant la personne pouvant clôturer ou arrêter une conférence, d'indiquer quel événement permet d'arrêter la conférence.

Ceci est souhaitable pour mettre en uvre des critères établis de clôture de conférence.

Dans [2] et [4], il est décrit de tels critères établis permettant de clôturer la conférence lorsque la personne qui a ouvert la conférence a quitté celle-ci ou lorsque le dernier participant a quitté la conférence. Ces critères établis, ou également d'autres critères, de clôture de conférence sont indiqués selon le troisième exemple de réalisation de l'invention dans le fichier de règles de conférence 108 et peuvent être modifiés en utilisant le CPCP de façon analogue aux droits de clôture, comme déjà décrit dans le premier exemple de réalisation de l'invention ou dans le deuxième exemple de réalisation de l'invention.

Pour mettre en oeuvre cet exemple de réalisation de l'invention, il est alors affecté à l'utilisateur adressé par le sous-élément de données <condition> l'attribut ou le droit indiqué dans le sous-élément de données <transformation>. Par exemple, dans le fichier de règles de conférence Exemple 1 , il est affecté à la participante Alice , qui est référencée par son SIP-URI alice@example.com , l'attribut ix-key-participant .

Pour permettre la demande formulée ci-dessus, on introduit selon cet exemple de réalisation de l'invention l'attribut supplémentaire <isessentiel-participant>. Le cas échéant, l'attribut <is-essentialparticipant> peut également être réutilisé selon l'invention et est interprété de façon appropriée selon l'invention par le serveur de règles de conférence 111.

Dans cet exemple de réalisation de l'invention, la conférence, dans la mesure où il s'agit d'une conférence non limitée, est clôturée ou une conférence limitée est arrêtée, lorsqu'un utilisateur quelconque, auquel est affecté cet attribut, quitte la conférence.

Le Fichier de règles de conférence Exemple 4 représente le Conference Policy Document donné à titre d'exemple et élargi selon le troisième exemple de réalisation, c'est-à-dire le fichier de règles de conférence 108 selon le troisième exemple de réalisation de l'invention: <?xml version="1.0" encoding="UTF-8"?> <conference xmlns="urn:ietf:params:xml:ns:conference-policy" xmins:xsi="http://www.w3.org/2001/XMLSchema-instance"> <settings> <conference- uri>sip:myconference@example.com</conference-uri> <max-participant-count> 10</max-participant-count> <allow-sidebars>true</allow-sidebars> </settings> <info xml:lang="en-us"> <subject>What's happening tonight</subject> <display-name>Party Goer's</display-name> <free-text>John and Peter will join the conference soon</free-text> <keywords>party nightclub beer</keywords> <host-info> <uri>sip:Alice@example.com</uri> <uri>tel:+3581234567</uri> <e-mail>mailto:Alice@example.com</e-mail> <webpage>http://www.example.com/users/Alice</web-page> </host-info> </info> <time> <occurrence> <mixing-start-time requiredparticipant="participant">2004-1217T09:30:0005:00</mixing-start-time> <mixing-stop-time requiredparticipant="none">2004-12-17712:30:00- 05:00</mixing-stoptime> <can-foin-after>2001-12-17709:25:00-05:00</can-join-after> <must-join-before>2004-12-17T12:00:00-05:00</must-join-before> <request-users required-participant="none">2001-12-17709:30:0005:00</request-users> </occurrence> </time> <authorization-r_ules> <rule id="l"> <conditions> <identity> <domain>example.com</domain> </identity> </conditions> <actions> <allow-conference-state>true</allowconference-state> <join-handling>allow</foin-handling> </actions> <transformations/> </rule> <rule id="2"> <conditions> <identity> <id>alice@example.com</id> </identity> </conditions> <actions> <allow-sidebar>true</allow-sidebar> </actions> <transformations> <is-key-participant>true</is-key- participant> <is-essential-participant>true</isessential-participant> </transformations> </rule> </authorization-rules> <dialout-list> <target uri="sip:bob@example.com"/> </dialout-list> <refer-list> <target uri.="sip:sarah@example.com"/> </refer-list> <security-control> <security-mechanism tls="false" s-mime="true"/> <pin>13579</pin> <password>abcdl234</password> </security-control> <floor-policy> <floor floor- control="fcp://example.com/floorabc" moderatorcontrolled=="false"> <media-streams> <audio media-id="2"/> </media-streams> <algorithm> <fcfs/> </algorithm> <max-floor-users>l</max-floor-users> </floor> </fIoor-po1icy> <media-streams> <video media-id="1"/> <audio media-id="2"/> </media-streams> </conference> Fichier de règle de conférence Exemple 4 Dans ce cas, la participante Alice est indiquée aussi bin comme <is-key-participant> que comme <is-essentialparticipant> : <transformations> 53 <is-key-participant>true</is-keyparticipant> <is-essential-participant> true</is- essential-participant> </transformations> Si la participante Alice quitte la conférence, la conférence est alors arrêtée selon cet exemple de réalisation de l'invention.

D'autre part, la conférence peut également être arrêtée selon cet exemple de réalisation de l'invention dès que cet attribut n'est pas affecté à au moins un membre actif, c'est-à-dire un participant actif à la conférence, c'est-à-dire que le dernier utilisateur, auquel cet attribut est affecté, n'a pas quitté la conférence. De cette façon, les deux critères établis mentionnés de clôture de la conférence peuvent être mis en uvre.

Une définition supplémentaire et importante d'un événement permettant de clôturer une conférence est effectuée selon un quatrième exemple de réalisation de l'invention au moyen de la définition d'un autre élément de données à l'intérieur des règles de conférence.

Cet élément de données est désigné selon cet exemple de réalisation de l'invention par <terminate-event>. Cet élément de données peut contenir selon cet exemple de réalisation de l'invention une liste d'utilisateurs qui sont indiqués par exemple au moyen de leur SIP-URI.

L'élément de données <terminate-event> peut cependant contenir également l'attribut <condition> qui peut prendre les valeurs is-key-participant et is-essential-participant (sans que cela ait un caractère général.). En outre, un instant ou une durée peut également être indiquée comme attribut <condition>. Si cet instant est atteint ou si cette durée s'est écoulée, la conférence est alors arrêtée. De même ici, on peut effectuer de nouveau une réinterprétation de sorte que la conférence n'est pas arrêtée mais suspendue.

Si un utilisateur indiqué par <terminate-event> quitte la conférence, la conférence est alors arrêtée selon cet exemple de réalisation. Selonl'exemple de réalisation indiqué dans Fichier de règle de conférence Exemple 5 , la conférence est une conférence limitée (Bounded) car le sous-élément de données <mixing-stop-time> est contenus dans le sousélément de données <occurrence> de l'élément de données <time> : <?xml version="1.0" encoding="UTF-8"?> <conference xmlns="urn:ietf:params:xml:ns:conference-policy" xmlns:xsi="http://www.w3.org/2001/XMLScherna-instance"> <settings> <conference- uri>sip:myconference@example.com</conference-uri> <max-participant-count> 10</max-participant-count> <allow-sidebars>true</allow-sidebars> </settings> <info xml:lang="en-us"> <subject>What's happening tonight</subject> <display-name>Party Goer's</display-name> <free-text>John and Peter will join the conference soon</free-text> <keywords>party nightclub beer</keywords> <host-info> <uri>sip:Alice@example.com</uri> <uri>tel:+3581234567</uri> <e-rnail> mailto:Alice@example.com</e-mail> <webpage>http://www.example.com/users/Alice</web-page> </host-info> </info <time> <occurrence> <mixing-start-time requiredparticipant="participant">2004-12-17709:30:0005:00</mixingstart-time> <mixing-stop-time requiredparticipant="none">2004-12-17712:30:00-05:00</mixingstop-time> <can-join-after>2001-12-17709:25:00-05:00</joinafter> <must-join-before>2004-12-17T12:00:00- 05:00</must-join-before> <request-users required-participant="none">2001-12-17T09:30:0005:00</request-users> </occurrence> </time> <authorization-rules> <rule id="1"> <conditions> <identity> <domain>example.com</domain> </identity> </conditions> <actions> <allow-conference-state>true</allow-conference-state> <join-handling>allow</join-handling> </actions> <transformations/> </rule> <rule id="2"> <conditions> <identity> <id>alice@example.com</id> </identity> </conditions> 30 <actions> <allow-sidebar>true</allow-sidebar> </actions> <transformations> <is-key-participant>true</is-key-participant> <is-essential-participant> true</isessential-participant> </transformations> </rule> </authorization-rules> <terminate-event condition="is-essential-participant"> <target uri="sip:bob@example.com"/> </terminate-event> <dialout-list> <target uri="sip:bob@example.com"/> </dialout-list> <refer-list> <target uri="sip:sarah@example.com"/> </refer-list> <security-control> <security-mechanism tls="false" s-mime="true"/> <pin>13579</pin> <password>abcd1234</password> </security-control> <floor-policy> <floor floor-control="fcp://example.com/floorabc" moderator- controlled="false"> <media-streams> <audio media-id="2"/> </media-streams> <a1gorithm> <fcfs/> </algorithm> <max-floor-users>1</max-floor-users> </floor> </floor-policy> <media-streams> <video media-id="1"/> <audio media- id="2"/> </media-streams> <conference> Fichier de règles de conférence Exemple 5 Selon cet exemple de réalisation de l'invention, la conférence est arrêtée dès que le participant bob , spécifié par son SIP-URI, ou l'un des participants à la conférence quitte la conférence: <terminate-event condition= is-essential-participant > <target uri= sip:bob@example.com /> </terminate-event> La valeur participant de l'attribut condition signifie que la conférence est arrêtée lorsque le dernier participant a quitter la conférence.

Le <terminate-event> peut, comme représenté dans Exemple 5 , être un élément propre dans le fichier de règles de conférence 108. Dans ce cas, il est judicieux que cet élément ne soit utilisé ou exploité que pendant le dernier événement de conférence défini dans la mesure où la conférence peut être associée à la classe des conférences limitées. Par ailleurs, la conférence serait arrêtée bien qu'il soit encore défini d'autres événements de conférence qui ne sont pas encore survenus.

Il est donc prévu dans une variante de réalisation d'introduire l'élément <terminate-event> à l'intérieur du dernier sous-élément de données <occurrence> existant. Dans ce cas, le sous-élément de données <terminateevent> ne peut être utilisé que dans le dernier événement de conférence. En outre, il est prévu d'introduire le sous-élément de données <terminateevent> à l'extérieur de chaque sous-élément de donnés <occurrence>, mais dans une variante de conformation de l'invention à l'intérieur de l'élément de données <time>.

Il est représenté dans la suite un autre exemple du fichier de règles de conférence 108 selon le quatrième exemple de réalisation de l'invention: <?xml version="1.0" encoding="UTF-8"?> <conference xmlns="urn:ietf:params:xml:ns:conference-policy" xmins:xsi="http://www.w3.org/2001/XMLSchema-instance"> <settings> <conference- uri>sip:myconference@example.com</conference-uri> <max-participant-count> 10</max-participant-count> <allow-sidebars>true</allow-sidebars> </settings> <info xml:lang="en-us"> <subject>What's happening tonight</subject> <display-name>Party Goer's</display-name> <free-text>John and Peter will foin the conference soon</free-text> <keywords>party nightclub beer</keywords> <host-info> <uri>sip:Alice@example.com</uri> <uri>tel:+3581234567</uri> <e-mail> mailto:Alice@example.com</e-mail> <webpage>http://www.example.com/users/Alice</web-page> </host-info> </info> <time> <occurrence> <mixing-start-time requiredparticipant="participant">2004-1217T09:30:0005:00</mixing-start-time> <mixing-stop-time requiredparticipant="none">2004-12-17712:30:00- 05:00</mixing-stoptime> <can-foin-after>2001-12-17709:25:00-05:00</can-join-after> <must-join-before>2004-12-17T12:00:00-05:00</must-join-before> <request-users required-participant="none">2001-12-17T09:30:0005:00</request-users> </occurrence> <terminate-time>2004-12-17712:10:00-05:00</terminatetime> </time> <authorization-rules> <rule id="1"> <conditions> <identity> <domain>example.com</domain> </identity> </conditions> <actions> <allow-conference-state>true</allowconference-state> <join-handling>allow</join-handling> </actions> <transformations/> </rule> <rule id="2"> <conditions> <identity> <id>alice@example.com</id> </identity> </conditions> <actions> <allow-sidebar>true</allow-sidebar> </actions> <transformations> <is-key-participant>true</is-keyparticipant> </transformations> </rule> </authorization-rules> <dialout-list> <target uri="sip:bob@example.com"/> </dialout-list> <refer-list> <target uri=="sip:sarah@example.com"/> </refer-list> <security-control> <security-mechanism tis="false" s-mime="true"/> <pin>13579</pin> <password>abcd1234</password> </security-control> <floor-policy> <floor floor-control="fcp://example.com/flooral: moderatorcontrolled="false"> <media-streams> <audio media-id="2"/> </media-streams> <algorithm> <fcfs/> </algorithm> <max-floor-users>1</max-floor-users> </floor> </floor-policy> <media-streams> <video media-id="1"/> <audio media-id="2"/> </media-streams> </conference> Fichier de règles de conférence Exemple 6 En plus de l'indication sur quel événement déclenchera un arrêt, il est prévu dans une variante de conformation de l'invention d'indiquer un instant où la conférence sera arrêtée. Ceci est effectuée dans cet exemple de réalisation non pas comme paramètre de l'attribut <condition> de l'élément de données <terminate-event> mais comme élément de données séparé. Si, par exemple, trois événements de conférence différents ont été définis pour une conférence, c'est-à-dire dans le fichier de règles de conférence 108 il existe trois éléments de données <occurrence>, la conférence devrait être arrêtée être manuellement selon l'état de la technique en envoyant un message HTTP Delete.

Cependant, si en se fondant sur une information déjà mémorisée dans le fichier de règles de conférence 108 selon cet exemple de réalisation de l'invention, par exemple <terminate-time>2004-12-17712:10:00-05:00</terminate-time> il est déjà indiqué auparavant que la conférence sera ensuite arrêtée, il est alors avantageux de proposer pour cela des 30 possibilité à l'intérieur des règles de conférence.

Selon cet exemple de réalisation de l'invention, on introduit pour cela un nouveau sous-élément de données <terminate-time> (voir l'exemple 6 cidessus) permettant indiquer à quel moment la conférence sera arrêtée. Selon cet exemple de réalisation de l'invention, l'événement de conférence est suspendu 12 heures et arrêté à 12h10 au moyen du paramètre prévu selon cet exemple de réalisation de l'invention. L'élément de données <terminate-time> peut dans ce cas être placé, comme représenté ici, dans l'élément de données <time>. Cependant, il peut être prévu d'autres variantes possibles. De préférence, l'élément de données <terminate-time> est fixé à un instant qui arrive dans le temps après le début du dernier événement de conférence existant.

La figure 5 est une représentation simplifiée dans un organigramme 500 de l'arrêt d'une conférence lors de la survenance d'un événement prédéterminé, comme celui contenu dans le fichier de règles de conférence 108.

Le serveur de règles de conférence 111 lit en une seule fois, en variante périodiquement à des intervalles de temps prédéterminés, ou en continu les éléments de données correspondants qui définissent les événements d'arrêt dans le fichier de règles de conférence 108, (représenté symboliquement par un message de demande de lecture 501). En ce qui concerne les événements d'arrêt lus 502, le serveur de règles de conférence 111 vérifie (étape de vérification 503) si l'événement ou les événements sont survenus.

Si c'est le cas, la conférence est arrêtée de la façon décrite ci-dessus. En variante, le concentrateur (Focus) 105 peut également effectuer la vérification d'événements décrite.

Si ce n'est pas le cas, la conférence se poursuit sans changement.

En résumé, il faut mentionner les aspects suivants de 30 l'invention: 1. Le fichier de règles de conférence est élargi de l'indication relative à quel utilisateur est autorisé à clôturer ou d'arrêter une conférence.

Pour cela, il est décrit différentes solutions: - définition d'un nouvel élément à l'intérieur du fichier de règles de conférence qui stipule quelle personne est autorisée à arrêter ou clôturer la conférence; définition d'une nouvelle règle d'autorisation pour 5 indiquer quel utilisateur peur délivrer des droits de clôture ou d'arrêt de la conférence; - définition d'une nouvelle action à l'intérieur des règles de conférence qui introduise un droit à au moins deux niveaux pour la clôture ou l'arrêt d'une conférence; et - introduction d'une nouvelle transformation ou d'une utilisation selon l'invention d'une transformation déjà existante pour accorder à un utilisateur le droit de clôturer ou d'arrêter une conférence.

2. Le fichier de règles de conférence est élargi d'une indication sur quel événement peut clôturer une conférence. Pour cela, il est décrit différentes solutions: - définition d'un nouvel élément à l'intérieur des règles de conférence dans lequel sont listés des événements. Si l'un des ces événements survient, la conférence est clôturée ou arrêtée; - il est prévu comme cas particulier une définition d'un nouvel élément à l'intérieur du fichier de règles de conférence dans lequel sont indiqués des utilisateurs. Si l'un de ces utilisateurs indiqués quitte la conférence, la conférence est alors clôturée ou arrêtée; - utilisation d'attributs à l'intérieur de cette liste.

3. Le fichier de règles de conférence est élargi de l'indication sur un instant ou sur une durée définissant l'arrêt de la conférence.

Dans ce document, il est cité les publications suivantes: [1] J. Rosenberg, A framework for conferencing with the session initiation protocol, SIP Internet-Draft, IETF SIPPING working group: Draft-IETF-SIPPING-conferencing-framework-02 juin 2004; [2] 3rd Generation Partnership Project, Technical Specification Group Core Network, Conferencing Using The IP 10 Multimedia (IM) Core Network (CN) Subsystem, Stage 3 (Release 6), 3GPP TS 24.147 V6.0.0, Septembre 2004; [3] Requests for Comments (RFC) 3261, SIP: Session Initiation Protocol; [4] A. Johnston et al., Session Initiation Protocol Call Control - Conferencing for user agents, SIPPING Working Group, Internet Draft, IETF SIPPING Working Group: Draft-IETFSIPPING-CC-Conferencing- 04 juillet 2004; [5] H. Khartabil et al., The Conference Policy Control Protocol (CPCP), XCON, Internet Draft, IETF XCON Working Group: Draft IETF-XCON-CPCP-XCAP- 01 juillet 2004; [6] J. Rosenberg, The Extensible Markup Language (XML) Configuration Access Protocol (XCAP), SIMPLE Internet Draft, IETF SIMPLE Working group: Draft-IETF-SIMPLE-XCAP- 03 juillet 2004; [7] WO 98/56177; [8] WO 03/005689 Al; [9] US 2003/0050060 Al; [10] US 2003/0224722 Al; [11] WO 99/62272 Al; [12] WO 2004/049625 Al; [13] WO 97/09815 Al; [14] EP 1 414 227 Al; [15] EP 1 465 397 Al; [16] EP 1 372 328 Al; [17] EP 0 713 319 A2; [18] DE 102 38 285 Al; [19] DE 696 31 687 T2; [20] US 2003/0174826 Al.

66 LISTE DES REFERENCES Système de téléconférence multimédia 101 Terminal de téléphonie mobile 102 Terminal de téléphonie mobile 103 Terminal de téléphonie mobile 104 Terminal de téléphonie mobile Serveur de conférence 106 Liaison de signalisation SIP 107 Liaison de signalisation SIP 108 Fichier de stratégie de conférence 109 Fichier Membership-Policy Fichier Media Policy 111 Serveur de stratégie de conférence 112 Flèche 113 Mélangeur (Mixer) 114 Double flèche Double flèche 116 Double flèche 117 Double flèche 118 Floor Control Server 119 Flèche Organigramme 201 Bloc 202 Message de demande d'arrêt 203 Message de lecture <terminate-list> 204 Message d'éléments de données <terminate-list> 205 Étape de vérification 206 Message de confirmation négatif 207 Message de clôture de conférence 208 Message de clôture de conférence 209 Libération de ressources de conférence de serveur de conférence 210 Libération de ressources de conférence de terminal de téléphonie mobile 211 Libération de ressources de conférence de terminal de téléphonie mobile 212 Libération de ressources de conférence de terminal de téléphonie mobile 213 Effacement du fichier de stratégie de conférence 300 Organigramme 301 Message de demande de modification de droits 302 Message de lecture <allow-modify-tl> 303 Message d'éléments de données <allow-modify-tl> 304 Étape de vérification 305 Message d'écriture <terminate-list> 306 Message de confirmation négatif 400 Organigramme 401 Étape de vérification 402 Message de demande d'éléments de données PIN 403 Message d'éléments de données PIN 404 Étape de vérification 405 Étape de vérification 406 Message de demande <terminate-list> 407 Message <terminate-list> 408 Étape de vérification 409 Message de confirmation négatif 410 Étape de vérification 411 Étape de vérification 500 Organigramme 501 Message de demande de lecture 502 Événement d'arrêt 503 Étape de vérification

Claims (22)

REVENDICATIONS

1. Procédé de gestion informatisée d'une téléconférence au moyen d'un serveur de téléconférence qui propose au moins une téléconférence entre plusieurs participants, le serveur de téléconférence ayant accès à un fichier électronique de règles de téléconférence, le fichier de règles de téléconférence destiné à la téléconférence proposée contenant des informations permettant de déterminer les participants qui peuvent interrompre ou clôturer la téléconférence ou interrompre une partie de la téléconférence, procédé caractérisé en ce que le serveur de téléconférence reçoit de la part d'un participant à la téléconférence une requête demandant d'interrompre ou de clôturer la téléconférence ou d'interrompre une partie de la téléconférence, le serveur de téléconférence vérifie, en utilisant le fichier de règles de téléconférence, si le participant est autorisé à interrompre ou clôturer la téléconférence ou à interrompre une partie de la téléconférence, dans le cas où le participant n'est pas autorisé à interrompre ou clôturer la téléconférence ou à interrompre la partie de la téléconférence, le serveur de téléconférence poursuit la téléconférence, et dans le cas où le participant est autorisé à interrompre ou à clôturer la téléconférence ou à interrompre la partie de la téléconférence, le serveur de téléconférence interrompt ou clôture la téléconférence ou interrompt la partie de la téléconférence.

2. Procédé selon la revendication 1, caractérisé en ce que le 30 fichier de règles de téléconférence peut être modifié par un ou plusieurs participants.

3. Procédé selon la revendication 2, caractérisé en ce que le fichier de règles de téléconférence contient des informations sur les participants qui peuvent modifier le fichier de règles de téléconférence.

4. Procédé selon la revendication 3, caractérisé en ce que le fichier de règles de téléconférence contient des informations sur les participants qui peuvent modifier dans le fichier de règles de téléconférence les informations permettant de déterminer les participants qui peuvent interrompre ou clôturer la téléconférence ou interrompre la partie de la téléconférence.

5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que l'information relative aux participants autorisés à interrompre ou clôturer la téléconférence ou à interrompre la partie de la téléconférence est mémorisée dans le fichier de règles de téléconférence sous la forme d'un ou plusieurs éléments de données.

6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce que l'information relative au participant autorisé à interrompre ou clôturer la téléconférence ou interrompre la partie de la téléconférence est mémorisée dans le fichier de règles de téléconférence sous la forme d'un ou de plusieurs éléments de données d'action.

7. Procédé de gestion informatisée d'une téléconférence au moyen d'un serveur de téléconférence qui propose au moins une téléconférence entre plusieurs participants, le serveur de téléconférence ayant accès à un fichier électronique de règles de téléconférence, le fichier de règles de téléconférence destiné à la téléconférence proposée contenant des informations permettant de déterminer quels événements peuvent interrompre ou clôturer la téléconférence ou interrompre une partie de la téléconférence, procédé caractérisé en ce que le serveur de téléconférence ou le serveur de règles de téléconférence vérifie, en utilisant le fichier de règles de téléconférence, la survenance de ces événements, en l'absence de survenance de ces événements, le serveur de conférence de télécommunications poursuit la téléconférence ou la partie de la téléconférence, et en cas de survenance de ces événements, le serveur de téléconférence interrompt ou clôture la téléconférence ou interrompt la partie de la téléconférence.

8. Procédé selon la revendication 7, caractérisé en ce que le fichier de règles de téléconférence peut être modifié par un ou plusieurs participants.

9. Procédé selon la revendication 8, caractérisé en ce que le fichier de règles de téléconférence contient des informations sur les participants qui peuvent modifier le fichier de règles de téléconférence.

10. Procédé selon la revendication 9, caractérisé en ce que le fichier de règles de téléconférence contient des informations sur les participants qui peuvent modifier dans le fichier de règles de téléconférence les informations permettant de déterminer quels événements peuvent interrompre ou clôturer la téléconférence ou interrompre la partie de la téléconférence.

11. Procédé selon l'une des revendications 6 à 10, caractérisé en ce qu'on utilise comme événements l'un des événements suivants.

* un ou plusieurs participants à la téléconférence, indiqués dans le fichier de règles de téléconférence, quittent la téléconférence, * un instant indiqué dans le fichier de téléconférence est 25 atteint, * la téléconférence a déjà atteint une durée maximale indiquée dans le fichier de téléconférence.

15. Procédé selon l'une des revendications 1 à 11, caractérisé en ce que la communication entre les participants et le serveur de téléconférence est effectuée au moins partiellement selon le Session Initiation Protocol.

16. Procédé selon l'une des revendications 1 à 12, caractérisé en ce que la communication entre les participants et le serveur de téléconférence est effectuée au moins partiellement selon le Conference Policy Control Protocol.

14. Procédé selon l'une des revendications 1 à 13, caractérisé en ce qu'il est proposé comme téléconférence une téléconférence multimédia dans laquelle plusieurs flux de données de médias différents sont proposés aux participants.

15. Procédé selon l'une des revendications 1 à 14, caractérisé en ce que le serveur de téléconférence est identifié de façon univoque au moyen d'un SIP Unique Resource Identifier.

16. Procédé selon l'une des revendications 1 à 15, caractérisé en ce que le fichier de règles de téléconférence est mémorisé au format XML.

17. Procédé selon l'une des revendications 1 à 16, caractérisé en ce qu'on accède au fichier de règles de téléconférence selon le Hypertext Transfer Protocol.

18. Procédé selon l'une des revendications 1 à 17, caractérisé en ce que les participants à la téléconférence transfèrent et/ou reçoivent des données selon un protocole de communication de téléphonie mobile.

19. Procédé selon la revendication 18, caractérisé en ce que les participants à la téléconférence transfèrent et/ou reçoivent des données selon un protocole de communication de téléphonie mobile 3GPP.

20. Procédé selon la revendication 19, caractérisé en ce que les participants à la téléconférence transfèrent et/ou reçoivent des données selon un protocole de communication de téléphonie mobile UMTS.

21. Serveur (105) de téléconférence, destiné à proposer au moins une téléconférence entre plusieurs participants, le serveur de téléconférence ayant accès à un fichier (108) électronique de règles de téléconférence, le fichier (108) de règles de téléconférence destiné à la téléconférence proposée contenant des informations permettant de déterminer les participants qui peuvent interrompre ou clôturer la téléconférence ou interrompre la partie de la téléconférence, caractérisé en ce que le serveur de téléconférence comporte: une unité de réception destinée à recevoir de la part d'un participant à la téléconférence une requête demandant 5 l'interruption ou la clôture de la téléconférence ou l'interruption de la partie de la téléconférence, une unité de vérification d'autorisation destinée à vérifier, en utilisant le fichier de règles de téléconférence, si la participant est autorisé à interrompre ou clôturer la téléconférence ou à interrompre la partie de la téléconférence, une unité d'arrêt de téléconférence qui est destinée à interrompre ou clôturer la téléconférence ou interrompre la partie de la téléconférence dans le cas où le participant est autorisé à interrompre ou clôturer la téléconférence ou interrompre la partie de la téléconférence.

22. Serveur (105) de téléconférence, destiné à proposer au moins une téléconférence entre plusieurs participants, le serveur de téléconférence ayant accès à un fichier (108) électronique de règles de téléconférence, le fichier de règles de téléconférence contenant des informations permettant de déterminer quels événements peuvent interrompre ou clôturer la téléconférence ou interrompre une partie de la téléconférence, caractérisé en ce que le serveur de téléconférence comporte.

une unité de vérification d'événements destinée à vérifier, en utilisant le fichier de règles de téléconférence, la survenance de ces événements, une unité d'arrêt de téléconférence qui est destinée à interrompre ou clôturer la téléconférence ou interrompre la partie de la téléconférence en cas de survenance de ces événements.