FR2779593A1

FR2779593A1 - Systeme plurimedia de communication

Info

Publication number: FR2779593A1
Application number: FR9807231A
Authority: FR
Inventors: Michel Lederman; Michel Repiso
Original assignee: MIC 2
Current assignee: MIC 2
Priority date: 1998-06-09
Filing date: 1998-06-09
Publication date: 1999-12-10
Anticipated expiration: 2018-06-09
Also published as: FR2779593B1

Abstract

Système de communication destiné à offrir des services à des usagers d'une entreprise, l'accès aux services de l'entreprise étant effectué par les usagers à partir de postes de consultation reliés au système au travers d'un ou plusieurs réseaux de communication supports de différents médias de communication et permettant à ces usagers d'accéder à des ressources de ce système. Ce système comporte des moyens de pilotage des différents médias de communication pour assurer une interface entre l'usager et l'application relative au service demandé par cet usager, des moyens de traitement des informations accessibles depuis ou fournies à l'application pour adapter le format de données de ces informations applicatives aux formats de données des médias de communication utilisés par l'usager, et des moyens de gestion de l'application pour décider en fonction d'un scénario préétabli de l'exécution des différentes actions résultant du service demandé par l'usager. Les interactions entre les différentes ressources de ce système sont réalisées par l'intermédiaire d'une interface commune (API-PMU) supportant un protocole de communication unique.

Description

Domaine de l'invention La présente invention se rapporte aux domaines de

la communication d'entreprise et des réseaux de télécommunication et, plus particulièrement, elle concerne une nouvelle architecture de communication permettant la diffusion d'informations vers différents types de médias de communication (ordinateur, téléphone, télécopieur, etc.) et garantissant la continuité d'un échange, ou d'une transaction, effectué par un ou plusieurs médias

simultanément ou séquentiellement.

Art antérieur Ces dernières années, les besoins de communication se sont accrus de façon considérable notamment depuis l'apparition des messageries s5 électroniques, on peut citer par exemple la messagerie " MS-Mail "> de la société américaine Microsoft, et avec le développement des systèmes de partage coopératif d'information comme celui bâti autour du logiciel "Notes >" de la société américaine Lotus. En outre, les modes de communication et les lieux d'échange de ces communications se sont également diversifiés. En effet, un utilisateur peut avoir à sa disposition différents médias de communication, qu'il s'agisse de terminaux et de réseaux informatiques dans son entreprise, d'un téléphone à son domicile, d'un télécopieur dans un hôtel ou d'un ordinateur portable, pouvant par exemple être relié à un réseau mondial de communication comme le réseau

dit Internet, dans un moyen de transport.

Or, le besoin et la nécessité de consulter des informations les plus diverses, des messages, ou des données peuvent intervenir à tous moments et en tous lieux alors que l'utilisateur peut alors ne disposer que d'un seul média particulier de communication, par exemple un téléphone. De même, l'utilisateur peut souhaiter au cours d'un échange passer d'un média de communication (un terminal informatique) à un autre (un téléphone) sans

que la continuité de cet échange ne soit interrompue.

Objet et définition de l'invention La présente invention a pour objet de proposer une architecture spécifique intégrée de communication permettant la mise en place de services plurimédias de communication d'entreprise capables de gérer la diffusion d'information en fonction des demandes de l'usager, et d'assurer la continuité d'une transaction utilisant, successivement ou concurremment,

plusieurs types de médias de communication.

Un but de l'invention est aussi d'offrir une interface plurimédia unique au travers de laquelle les différentes applications de l'entreprise vont

pouvoir utiliser toutes les ressources de l'architecture.

Ces buts sont atteints par un système de communication destiné à offrir des services à des usagers d'une entreprise, l'accès aux services de i5 l'entreprise étant effectué par les usagers à partir de postes de consultation reliés au système au travers d'un ou plusieurs réseaux de télécommunication (réseau téléphonique commuté, Intemet, Télétel, etc.) supports de différents médias de communication et permettant à ces usagers d'accéder à des ressources du système, système caractérisé en ce qu'il comporte des moyens de pilotage des différents médias de communication pour assurer une interface entre l'usager et l'application plurimédia relative au service demandé par cet usager, des moyens de traitement des informations accessibles depuis ou fournies à l'application plurimédia pour adapter le format de données de ces informations applicatives aux formats de données des médias de communication utilisés par l'usager, et des moyens de gestion de l'application plurimédia pour décider, en fonction d'un scénario préétabli de diffusion des informations, de l'exécution des différentes actions résultant du service demandé par l'usager, les interactions entre les différentes ressources du système étant réalisées par l'intermédiaire d'une interface commune (API-PMU) supportant un protocole de communication unique. Ainsi, avec la présente invention, l'usager peut passer d'un média de communication à un autre durant la consultation du service offert par l'entreprise sans que cette consultation ne soit interrompue par ce

changement de média.

Les ressources du système comporte de préférence des moyens

d'administration pour permettre la configuration du système.

Avantageusement, ces moyens d'administration comportent des moyens de collecte d'information en vue de l'établissement de journaux de bord et

d'états statistiques.

Le système de communication selon l'invention comporte en outre une base de donnée avec au moins des données relatives aux services offerts 0o par l'entreprise et dont l'accès peut être effectué depuis l'un quelconque des

moyens de pilotage, de traitement et de gestion constituant le système.

De préférence, les moyens de pilotage, de traitement et de gestion constituant le système de communication sont reliés entre eux par l'intermédiaire d'un réseau de type TCP/IP supportant le protocole de

communication unique.

Le moyen de pilotage de média de communication peut comporter des moyens de pilotage d'une interface de télécopie pour assurer l'envoi et la réception de télécopie, ou des moyens de pilotage d'une interface vocale pour assurer l'envoi, la réception et l'enregistrement de séquences vocales, ou bien des moyens de pilotage d'une interface videotex pour assurer la présentation de pages de données videotex, ou encore des moyens de pilotage d'une interface Internet pour assurer la présentation de pages de

données interprétables par un navigateur Internet.

Le moyen de traitement comporte des moyens pour assurer une transformation des informations, à destination ou en provenance de

l'usager, d'un premier format de données relatif à l'interface unifiée " API-

PMU >> en un second format de données relatif au pilote de média considéré et distinct du premier. Ces moyens de transformation peuvent comporter un moyen de reconnaissance des séquences vocales reçues de l'usager lors de sa liaison avec le système en transformant ces séquences vocales en une suite de caractères reconnaissables par l'application relative au service concerné, ou encore un moyen de synthèse vocale dit " text-to-speech >> permettant à partir d'une suite de caractères la génération de séquences vocales à destination de l'usager. D'autres types de moyens de transformation peuvent aussi être inclus dans le système pour en enrichir ses possibilités.

Brève description des dessins

D'autres caractéristiques et avantages de la présente invention

ressortiront mieux de la description suivante, faite à titre indicatif et non

limitatif, en regard des dessins annexés, sur lesquels: - la figure I montre un synoptique fonctionnel de l'architecture de communication selon l'invention, 0o - la figure 2 illustre un premier exemple d'architecture de communication selon l'invention dans un environnement monoposte, - la figure 3 illustre un second exemple d'architecture de communication selon l'invention dans un environnement distribué, - la figure 4 montre différentes étapes élémentaires pouvant être mises en oeuvre dans l'architecture de communication selon l'invention, - la figure 5 est un organigramme simplifié qui illustre le procédé mis en oeuvre dans l'architecture de communication des figures 1 et 2, - la figure 6 est un diagramme expliquant le fonctionnement de l'architecture de communication selon l'invention dans le cadre d'une application à un service de consultation documentaire, - les figures 7a et 7b montrent un diagramme expliquant le fonctionnement de l'architecture de communication selon l'invention dans le cadre d'une application à un service d'expertise technique, - la figure 8 est un diagramme expliquant le fonctionnement de l'architecture de communication selon l'invention dans le cadre d'une application à un service après vente, et - la figure 9 est un diagramme expliquant le fonctionnement de l'architecture de communication selon l'invention dans le cadre d'une

application à un service vocal de prise de commande à distance.

Description d'un mode de réalisation préférentiel

Un synoptique fonctionnel de la nouvelle architecture de communication selon l'invention est donné à la figure 1. Cette architecture définit un système de communication organisé autour d'une interface 1 de programmation applicative unifiée appelée par les inventeurs " API-PMU " et permettant à l'une quelconque des applications de ce système l'exploitation des différentes ressources mises à sa disposition. Ces ressources consistent en des pilotes de médias de communication 2, des s moteurs de traitement 3 et des outils d'administration 4. Les pilotes de médias sont chargés d'assurer une interaction directe avec les différents médias de communication (téléphone, terminal Minitel, navigateur Internet, télécopieur, etc.) utilisés par les usagers du système sous le contrôle d'une application qui déroule le service fourni à cet usager. Les moteurs de traitement permettent le traitement de l'information en provenance ou à destination de l'usager notamment par des fonctions de reconnaissance et de synthèse vocales. Les outils d'administration permettent de gérer la configuration du système et d'établir des journaux de bord et, à partir de ces derniers, des états statistiques. En outre, un environnement graphique adapté (générateur graphique d'application), permet au concepteur d'applications de l'entreprise, le développement d'applications nouvelles (ou l'adaptation au système d'applications anciennes) en décrivant sous la forme de scénarios graphiques les services que ces applications plurimédias vont

dérouler pour l'usager.

On se réfère maintenant à la figure 2 qui montre un premier exemple de réalisation d'une architecture de communication pouvant être mise en place dans une entreprise en vue du développement d'applications plurimédias adaptées aux besoins de communication, tant internes qu'externes, de cette entreprise. Ces applications qui correspondent chacune à un service particulier que souhaite rendre l'entreprise à ses usagers (aussi bien internes que externes), comme un journal d'information interne, un service interne d'échange de documents, un service après vente ou service de prise de commande pour sa clientèle, un service de relations avec ses actionnaires, un service de renseignements aux consommateurs, un service de liaison avec ses représentants ou correspondants extérieurs, etc., doivent pouvoir interagir avec les applications, dites externes, déjà présentes dans l'entreprise (messageries internes, application de gestion, etc.) et être accessibles depuis les différents médias de communication mis à disposition

de ces usagers en interne ou à distance.

Pour réaliser cette intégration des applications externes de l'entreprise et cet accès plurimédia pour les usagers (c'est à dire un accès simultané et/ou consécutif à ces applications à partir de n'importe lequel des médias de communications et en tous lieux), l'architecture de communication selon l'invention est organisée autour d'un ensemble informatique 5 comportant à la fois des moyens matériels et des moyens logiciels, cet ensemble étant relié au travers d'un ou plusieurs réseaux d'accès informatiques ou téléphoniques (réseaux de type LAN, WAN, réseaux d'accès distant) 6, 7 à des postes de consultation 8 utilisables

o0 directement par ces usagers.

Ces réseaux d'accès aux services offerts par une application plurimédia, selon que les usagers sont internes (employés) ou externes (clients par exemple) à l'entreprise, peuvent être constitués, selon les média utilisés, par un réseau intranet ou un réseau extranet ou plus simplement par le réseau téléphonique de l'entreprise (pour les usagers internes) ou les réseaux d'opérateurs à commutation de circuits (le réseau téléphonique public commuté RTC) ou à commutation de paquets, comme le réseau spécialisé Transpac (une marque déposée de la société française France télécom) (pour les usagers externes). Un réseau numérique à intégration de services (RNIS) peut aussi bien être envisagé pour les liaisons extérieures à l'entreprise. Les postes d'usagers comportent avantageusement par exemple un terminal 40 de type Minitel (une marque déposée de la société française France Télécom), un téléphone 42, un terminal informatique 44, 48, 50 (il peut s'agir d'un ordinateur de bureau comme d'un ordinateur portable ou encore d'un assistant personnel), ou encore un télécopieur 46. Bien entendu, le terminal informatique de l'usager supporte le protocole nécessaire à sa connexion au réseau auquel il est relié. Par exemple, un protocole TCP/IP pour la liaison aux réseaux intranet ou extranet ou un protocole X25 pour la

liaison à un réseau de transmission par paquets de type Transpac.

Dans l'exemple illustré sur la figure 2, l'ensemble informatique est constitué par un unique serveur informatique 5 qui héberge l'ensemble des moyens matériels (cartes T2 pour l'interface RTC/RNIS, carte X25, carte Ethernet, etc.) et logiciels permettant la gestion simultanée de l'accès des usagers aux différents services proposés par l'entreprise. L'interaction des applications plurimédias supports de ces services avec les usagers est gérée au travers de l'interface de programmation applicative unique " API-PMU " qui permet à ces applications d'accéder aux ressources multiples mises à disposition de ces usagers au travers d'un protocole spécifique unique (appelé protocole plurimédia unifié << PPMU >"). Ce protocole est basé sur le protocole connu en soi TCP/IP et permet d'échanger des trames spécifiques

contenant des données diverses.

On a vu précédemment que ces ressources sont essentiellement de trois types: des "< pilotes de médias ", des " moteurs de traitement " et des << outils d'administration >". Les pilotes de médias sont des interfaces matérielles et logicielles destinées à la gestion d'un type de média déterminé. Ils assurent le dialogue avec l'usager et la liaison avec les applications au travers de l'interface unifiée "API-PMU " en déclinant i5 l'ensemble des fonctionnalités offertes par le service à l'usager. Dans l'exemple illustré (qui ne saurait être limitatif quant au nombre et au type possibles de pilotes ou de moteurs), le serveur informatique comporte quatre types de pilotes de média: un pilote FAX 10 qui permet de recevoir ou de créer et d'envoyer des télécopies, un pilote VOCAL 12 qui permet d'envoyer, de recevoir et d'enregistrer des séquences vocales, un pilote VIDEOTEX 14 qui permet de présenter les services et de réaliser un dialogue par Minitel et un pilote WEB 16 qui permet de présenter des pages de données interprétables par un navigateur Intemrnet (par exemple des pages HTML) et de réaliser un dialogue au travers de l'Internet. Les moteurs de traitement sont des éléments logiciels qui assurent un traitement de données (essentiellement transformation des formats de données d'un premier format commun à l'interface unifiée à un second format dépendant du pilote considéré) et qui constituent des ressources accessibles pour les applications ou, le plus souvent, pour les pilotes de médias. On distingue principalement deux types de moteurs: un moteur 18 de reconnaissance vocale permettant de reconnaître un flot de données vocales en transformant les séquences vocales reçues de l'usager en une suite de caractères reconnaissables par l'application relative au service concerné, et un moteur 20 de synthèse vocale dit " text-to-speech " permettant de générer une séquence vocale à

partir d'une suite de caractères par exemple un fichier texte de type ASCII.

Mais, bien entendu, d'autres types de moteurs peuvent être inclus dans le système pour en enrichir les possibilités, par exemple un moteur OCR pour l'analyse de données FAX. Les outils d'administration sont des outils logiciels permettant d'assurer la configuration de l'architecture 24a (définition au moyen d'une table d'allocation dynamique des ressources disponibles et utilisables), la constitution et l'exploitation de fichiers journalisés centralisés ou journaux de bord 24b (collecte de l'historique des événements affectant l'architecture et le fonctionnement du système) pour recherche, extraction et analyse ultérieures, et la gestion d'états statistiques 24c décrivant l'utilisation de cette architecture (taux d'occupation, activité des moteurs, erreurs, etc.) à partir des événements collectés. Ils constituent

également une ressource du système.

Quant à elles, les applications plurimédias comportent un module fonctionnel dénommé " gestionnaire de session " 30 agencé pour gérer (et mémoriser) les informations propres à chaque usager désirant accéder à un service offert par l'entreprise, ces usagers pouvant intervenir sur plusieurs médias en même temps ou successivement. Le déroulement du service demandé par l'usager, c'est à dire l'exécution des différentes actions devant être entreprises en fonction des demandes de cet usager, est décidé par un " interpréteur de scénario " 32 qui fait appel à des données propres à l'architecture de communication, comme des modèles ou des pages HTML ou VIDEOTEX par exemple, ou spécifiques à l'entreprise et stockées dans une base de données. Ces actions sont exécutées selon un scénario de diffusion de l'information préétabli et caractéristique du service rendu (voir supra les figures 6 à 9). Eventuellement, l'exécution de ces actions fait appel aux applications externes, existantes préalablement dans l'entreprise, par l'intermédiaire d'un "bus applicatif" 34 qui est un ensemble de modules logiciels standards ou spécifiques destinés à s'interfacer avec les applications existantes de l'entreprise et dépendant de l'environnement de

cette entreprise (système de messagerie, applications de groupware, etc. ).

Un second exemple d'une architecture de communication selon l'invention est montrée sur la figure 3. On retrouve tout naturellement les postes d'usagers 8 et les réseaux 6, 7 d'accès au système de communication

connectés à ces postes et auxquels est relié l'ensemble informatique 5.

Toutefois, dans l'exemple illustré, cet ensemble informatique se présente sous la forme d'une architecture distribuée et non plus monoposte avec plusieurs serveurs informatiques (des ensembles informatiques spécialisés) chargés chacun d'une tâche spécifique, c'est à dire de la gestion d'une ressource déterminée ou de la gestion d'une ou plusieurs applications

plurimédias particulières.

Ainsi, des serveurs 10, 12, 14, 16 sont affectés aux différents pilotes de médias de communication. Un premier serveur 10 est chargé du pilotage des données vocales, un deuxième serveur 12 du pilotage des données fax, un troisième serveur 14 du pilotage des données videotex et un quatrième

serveur 16 du pilotage des données de réseau Intemrnet (ou données Web).

Les trois premiers serveurs sont reliés au réseau téléphonique 6, le quatrième étant relié au réseau de type Internet 7. Bien entendu, cette s5 répartition des différents pilotes entre les serveurs n'est aucunement limitative et la configuration matérielle adoptée dépend avant tout des performances de communication souhaitées pour l'architecture et caractérisées notamment par le nombre total d'usagers, le nombre d'usagers simultanés par médias, le volume d'information à échanger, et la bande passante disponible. Ainsi, comme l'illustre la figure 3, les pilotes de données vocales et Web peuvent être répartis sur deux serveurs à la fois (la

connexion aux réseau d'accès devant bien sûr être adaptée en conséquence).

Des cinquième et sixième serveurs 18, 20 sont affectés aux moteurs de traitement logiciels et permettent respectivement des opérations de reconnaissance et de synthèse vocales et un septième serveur 22 assure la gestion de la base de données comportant les informations spécifiques à l'architecture ou relatives à l'entreprise. Enfin, un huitième serveur 24 est chargé de recevoir les outils d'administration pour assurer la configuration de l'architecture de communication et l'élaboration des journaux de bord pour notamment permettre ensuite une définition d'états statistiques relatifs

au fonctionnement du système de communication.

L'ensemble de ces huit serveurs est relié à un réseau privé 26 spécifique à l'architecture. Ce réseau est classiquement relié au réseau local interne de l'entreprise (non représenté) par un pont routeur qui permet le filtrage des informations et une conversion de protocole si nécessaire. On peut montrer que le recours à un réseau privé de type Ethernet à 1 00MHz permet d'envisager la connexion simultanée d'un très grand nombre d'usagers en mode WEB et d'un nombre encore plus élevé en mode videotex et permet en outre de supporter plusieurs centaines de voies de reconnaissance vocale. Les serveurs sont avantageusement constitués classiquement par des ordinateurs de type personnel ou des stations de travail, par exemple des stations munies de processeurs de type SPARC de

la société américaine Sun.

Cette architecture est en outre munie d'un terminal informatique 28 assurant l'administration des différentes applications relatives aux services proposés, c'est à dire permettant un accès aux outils d'administration précités au travers d'une interface graphique spécifique et de terminaux 36 sur lesquels tournent les différentes applications plurimédias fournissant les services proposés par l'entreprise et développées préalablement dans un

environnement graphique à l'aide d'un générateur d'applications.

Des exemples d'actions élémentaires pouvant être réalisées dans le

système de communication selon l'invention sont montrés sur la figure 4.

Les différentes interactions entre un usager et une application plurimédia fournissant un service déterminé (selon un scénario préétabli) peuvent résulter de différentes combinaisons de ces actions élémentaires. Ces actions sont effectuées au niveau soit de l'usager, soit des pilotes de médias, soit de l'application plurimédia concerné, soit des applications externes de l'entreprise (messagerie, comptabilité, etc.). Elles commencent toujours par

une première phase de connexion entre l'application plurimédia et l'usager.

Cette connexion peut résulter d'un appel entrant, d'un appel sortant ou simplement d'un envoi de données vers l'usager à partir d'une application

externe de l'entreprise.

Dans le cas d'un appel entrant, il est procédé, dans une première étape 500, à une connexion de l'usager au système. Dans l'étape suivante 502, le pilote de média concerné reçoit cet appel, le confirme à l'usager

(étape 503) et le notifie à l'application plurimédia gérant le service appelé.

L'application plurimédia reçoit communication de cet appel, dans une étape

504, et déroule alors le scénario correspondant.

Il Dans le cas d'un appel sortant, c'est l'application plurimédia qui dans le cadre d'un scénario préétabli de gestion du service déterminé demande, dans une étape 506, à générer un appel vers un usager. Le pilote génère cet appel dans une étape suivante 508. L'usager concerné reçoit l'appel et l'accepte dans une étape 510 puis confirme son acceptation au pilote de média (étape 512) qui à son tour en informe l'application plurimédia, dans une étape 514, laquelle peut alors poursuivre son scénario initial. Le dernier cas concerne l'envoi de données vers l'usager sans que io celui-ci ne soit mis en relation avec l'expéditeur de ces données. Une application externe de l'entreprise (messagerie par exemple) envoie des données à un usager (envoi d'un e. mèl), ces données transitant par l'application plurimédia du système de communication gérant ce type d'envoi (étape 516). Le pilote de média concerné analyse ces données, dans une étape 518, et les adresse à l'usager qui les reçoit alors dans une étape

suivante 520.

A l'issue de la phase de connexion, il se produit une phase d'interaction entre l'usager et le service en cause. Ainsi, dans une étape 522, l'usager va émettre une première requête qui est alors analysée par le pilote 2o de média correspondant, lequel va lancer l'action correspondante (envoi de données vers l'usager) o notifier la demande de l'usager vers l'application plurimédia gérant le service (étape 524). Selon l'action effectuée par le pilote, l'usager va, dans une étape 526, recevoir les données issues du pilote ou, dans une étape 528, l'application plurimédia va analyser la demande du pilote et, selon le scénario suivi, soit envoyer des données vers l'usager (selon le processus explicité précédemment aux étapes 516 à 520), soit

lancer une interaction avec une application externe de l'entreprise.

A cette phase d'interaction avec les médias peut succéder une phase d'interaction avec les applications externes de l'entreprise. Cette phase peut comporter une étape 530 dans laquelle l'application plurimédia de gestion du service va adresser une requête vers une application externe de l'entreprise qui, dans une étape 532, va analyser cette requête et la traiter puis renvoyer vers l'application plurimédia les données de réponse nécessaires (étape 534). Il peut s'agir aussi d'une étape 536 dans laquelle l'application plurimédia va simplement envoyer de l'information vers l'application extérieure qui va alors la traiter (étape 538) sans en attendre de réponse. Ce peut être encore cette application externe qui va envoyer, dans une étape 540, vers l'application plurimédia des informations sans requête préalable qui seront traités dans une étape 542 selon le scénario préétabli de

cette application plurimédia.

Enfin, la dernière phase consiste en une phase de déconnexion qui peut commencer par un simple constat par le pilote de média de la déconnexion de l'usager (étape 544) qui va être notifié à l'application 0o plurimédia dans une étape suivante 546. Elle peut résulter aussi d'une demande de cette application plurimédia de déconnecter l'usager (étape 548), demande qui est adressée dans une étape 550 au pilote de média concerné qui va alors adresser à son tour une confirmation de la déconnexion à l'application pour plurimédia que celle-ci exécute les derniers traitements de clôture de l'échange correspondant, dans une ultime

étape 552.

L'ensemble de ces étapes élémentaires peut être simplifié dans l'organigramme de la figure 5 qui tend à illustrer le procédé général mis en oeuvre au niveau de l'architecture de communication de l'invention. Dans une étape initiale 80, l'application plurimédia gestionnaire du service mis en place par l'entreprise est en attente d'un événement quelconque (l'établissement d'une connexion) qu'il soit en provenance des pilotes de médias, par exemple un appel entrant d'un usager, à destination d'un pilote de média, par exemple la génération d'un appel sortant, ou issu des applications externes de l'entreprise (par exemple un envoi de données vers l'usager). Dans une étape 82, le pilote de média sollicité analyse et traite l'événement puis, dans une étape suivante 84, élabore un compte-rendu. S'il s'agit d'un appel entrant d'un usager, il reçoit cet appel (étape 84) et, s'il l'accepte (par exemple si celui-ci est soumis à un numéro d'identification particulier et que ce numéro est correct), notifie (étape 86) cet appel à l'application plurimédia. S'il s'agit d'une demande de génération d'un appel sortant, il génère (étape 84) cet appel et confinrme (étape 86) à l'application plurimédia la réception de l'appel par l'usager. S'il s'agit d'une demande d'envoi de données depuis uneapplication externe, il analyse (étape 84) cette demande et envoi (étape 86) les données. Dans les deux premiers cas, l'application plurimédia décide, dans une étape 86, de la première action à mener en suivant le scénario de service préétabli (une interaction avec une application externe ou un envoi de données vers l'usager:par exemple affichage d'une page HTML (EPH) ou lecture d'un fichier sonore (LFS)) et, dans une étape 88, adresse la requête correspondante soit au pilote de média concerné pour que ce dernier l'exécute (envoi de données vers l'usager) soit à l'application externe sollicitée. Ceci est fait dans une étape 90 avec, dans le cas d'une action du pilote de média, l'aide éventuelle d'un moteur de traitement logiciel (une reconnaissance de la voix de l'usager ou la synthèse

d'un signal sonore à partir de texte peuvent en effet être nécessaire).

L'opération effectuée, et après avoir recueilli éventuellement l'interaction de l'usager dans une étape 92, l'application plurimédia est informée de la réalisation de l'action dans une étape 94, laquelle décide alors de l'action suivante à mener (selon le résultat du test 96) en retournant à l'étape 86, cette action mettant en oeuvre le précédent pilote de média, ou un autre des pilotes disponibles avec cette application (le pilote précédent pouvant rester actif pendant l'action du second), ou encore une application externe. Ainsi, il est particulièrement aisé de passer d'un média à l'autre au cours d'un même appel (ou d'une même connexion) successivement comme

concurremment sans que la liaison ne soit interrompue.

Un premier exemple d'application de l'architecture de communication selon l'invention est illustré sur la figure 6. Il se rapporte à un service de consultation documentaire qui permet à partir d'un terminal informatique et d'un téléphone à un usager de ce service d'accéder par navigation vocale à des documents stockés dans la base de données de l'entreprise. Dans une première étape 100, le serveur informatique de l'entreprise est en attente d'une connexion à l'un de ses services, la réception d'un premier appel entraînant, dans une seconde étape 102, la mise en place du scénario du service de consultation documentaire correspondant à l'appel reçu. Le scénario implique l'affichage d'une page d'accueil de type HTML sur le terminal informatique de l'usager dans une étape 104. Cette page comporte notamment un formulaire de saisie du numéro de téléphone de cet usager. La saisie de ce numéro par l'usager entraîne sa réception et sa vérification par le service dans une étape 106. En cas de saisie erronée, il est mis fin à la connexion au service (par exemple après trois essais) dans une ultime étape 108. Au contraire, une saisie correcte permet au service de composer le numéro de l'usager dans une étape 110 et, une fois la connexion téléphonique établie, de proposer par affichage sur le terminal de l'usager d'une nouvelle page HTML un choix entre différents thèmes proposés par le service sélectionné (étape 112). Eventuellement, si la connexion n'est pas possible, une nouvelle page d'accueil peut être affichée dans une étape 114 avec demande de resaisie du numéro de téléphone de l'usager ou, il peut être mis fin au service dans une étape 116. L'accès à ces thèmes est alors réalisé vocalement, le service de consultation documentaire assurant une reconnaissance vocale du choix prononcé par l'usager dans une étape suivante 118 (Il peut être demandé à l'usager de répéter son choix dans une étape 120 en cas de non reconnaissance). La reconnaissance du choix prononcé vocalement par l'usager entraîne dans une étape 122 une interaction entre l'application de consultation documentaire et la base de donnée qui lui est associée pour récupérer une liste de documents proposé par le thème choisi. Dans une étape 124, la liste de documents est affichée avec une page HTML et l'usager peut alors choisir vocalement son document dans une étape suivante 126 ou demander la fin du service dans une étape 128. Le document demandé est alors affiché sur l'écran de son terminal informatique dans une étape 130. Bien entendu, il est possible aussi que l'usager se fasse lire le document. Après lecture, l'usager peut sélectionner un autre document ou revenir à un thème non sélectionné précédemment (étape 132) ou bien encore quitter le service dans une étape

terminale 134.

On aura noté que l'architecture de communication de l'invention permet l'interaction de plusieurs médias de communication lors d'un même échange. Ainsi, avec l'invention, l'usager peut sur son terminal informatique avoir accès à différents documents sélectionnés dans la base

de données de l'entreprise par navigation vocale à son téléphone.

Les figures 7a et 7b montrent un second exemple d'application de l'invention correspondant à la mise à disposition à distance par l'entreprise

de moyens d'expertise technique.

Dans une première étape 200, le serveur informatique de l'entreprise est en attente d'une connexion à l'un de ses services, la réception d'un premier appel entraînant, dans une seconde étape 202, la mise en place du scénario du service d'expertise technique externe correspondant à l'appel reçu. Selon la nature de l'accès au service, par exemple par le téléphone ou par le WEB (mais bien évidemment un accès par Minitel est aussi envisageable), le scénario se déroulera différemment. L'application décrite maintenant concerne plus précisément une entreprise de distribution de gaz rares qui souhaite mettre à disposition de ces revendeurs agréés des moyens l0 techniques d'expertise permettant à ceux-ci de s'informer sur une éventuelle substitution de ces gaz et sur la modification d'installation qu'elle peut alors impliquer. Il est tout d'abord envisagé une connexion de l'usager au service par téléphone. Une première lecture d'un fichier sonore provoque, dans une étape 204, une demande de saisie d'un code client qui est suivi, dans une étape 206, après saisie correcte de ce code d'une proposition d'un menu

principal (ou sommaire) pour l'usager abonné, le non abonné (qui ne

possède pas de code client) étant orienté, dans une étape 208, vers des menus différents lui donnant accès seulement à certains éléments limités comme des informations générales ou des conseils pour s'abonner au service et lui permettant éventuellement d'entrer en relation avec un téléopérateur par exemple. Au contraire deux choix d'études sont proposés à l'abonné. Un premier choix pour l'identification de gaz de substitution et un

second pour une étude de son installation.

Concernant le premier de ces choix, dans une étape 210, différents fichiers sonores seront lus à l'usager en vue de dérouler des questions permettant une identification des gaz mis en oeuvre dans l'installation à étudier. Dans une étape suivante 212, un logiciel spécifique de l'entreprise traitera les données techniques ainsi recueillies et, dans une étape 214, proposera alors une liste de gaz de substitution possibles. L'usager du service fait ensuite son choix, dans une étape 216, et à l'issue de ce choix le service peut proposer l'envoi par télécopie (étape 222) d'un descriptif technique des gaz correspondants (étape 218) récupéré au niveau d'une base de données de l'entreprise (étape 220). Le service fait ensuite une proposition d'étude technique de l'installation dans l'étape 224 et selon le choix de l'usager recueilli à l'étape 226 retourne à l'étape 206, termine le service (étape 228) ou procède dans une étape 230 à cette étude technique par le déroulement de questions portant sur les caractéristiques de l'installation actuelle et du gaz de substitution retenu (par exemple puissance du moteur électrique, taille du compresseur, etc.). Ces différentes questions peuvent aussi être posées directement à l'issue de l'étape de choix

initiale 206.

L'analyse des réponses de l'usager abonné est faite par un logiciel spécifique à l'entreprise dans une étape 232 et il est proposé dans une étape suivante 234 un menu exposant les possibilités de modification à apporter à cette installation. Selon les choix effectués par l'usager (étape 236), il est donné des conseils de redimensionnement de l'installation dans une étape 238 et une proposition d'envoi des résultats de l'étude par télécopie est faite dans une étape suivante 240, ces résultats étant extraits de la base de is données de l'entreprise o ils ont été stockés précédemment (étape 242) et adressés par télécopie à l'usager dans l'étape 244. L'usager peut alors choisir (étape 246) de demander la fin du service dans une étape 248, demander l'établissement d'une relation avec un conseiller technique (étape 250) et à l'issue de celle-ci, selon le choix de l'usager (étape 252), terminer le service (étape 254) ou revenir au menu principal de l'étape 206 ou encore demander une sauvegarde du résultat de l'étude le concernant pour une consultation ultérieure, notamment au travers du média WEB (voir supra). Il lui sera alors attribué un numéro de dossier dans une étape 256 ainsi qu'un délai de conservation de ce dossier. L'usager peut ensuite au choix (étape

258) terminer le service (étape 260) ou revenir au menu principal (étp 206).

Il est envisagé maintenant le cas o l'usager effectue une connexion au service au travers du WEB. Il apparaît tout d'abord sur le terminal de l'usager, dans une étape 262, une page d'accueil HTML qui présente un formulaire d'identification et permet, dans une étape 264, de recevoir le code client et le mot de passe de l'usager. Après vérification de ces données dans une étape 266, l'usager non abonné (qui n'a pas fourni les bons code client et mot de passe) est orienté dans une nouvelle étape 268 vers une autre page HTML lui donnant accès seulement à certains éléments limités comme des informations générales ou des conseils pour s'abonner au service et lui permettant éventuellement d'entrer en relation avec un téléopérateur par exemple. Au contraire, l'usager abonné se voit offrir, dans

une étape 270, une nouvelle page HTML lui proposant par exemple 3 choix.

Selon un premier choix, il est proposé à l'usager, dans une étape 272, de répondre à des questions permettant une identification des gaz de substitution pouvant être mis en oeuvre dans l'installation à étudier en complétant une page HTML de questionnaire. Dans une étape suivante 274, un logiciel spécifique de l'entreprise traitera les données techniques ainsi recueillies et, dans une étape 276, proposera alors une liste de gaz de substitution possibles. L'usager du service fait ensuite son choix, dans une étape 278, et à l'issue de ce choix le service procède à un descriptif technique des gaz correspondants (étape 280). Selon le choix de l'usager, recueilli à l'étape 282, ce descriptif lui est envoyé par télécopie (étape 284) ou est sauvegardé en vue d'une consultation ultérieure, auquel cas un numéro de dossier et un délai de conservation de son dossier sont communiqués à l'usager dans une étape 286, avant une éventuelle fin de

service (étape 288) ou un retour à l'étape 276.

Le second choix de l'usager qui peut aussi être fait à l'issue de l'étape 270 consiste à lui demander de procéder à une étude de son installation. Le service lui visualise alors, dans une étape 290, une page HTML pour la saisie des caractéristiques de son installation actuelle et du gaz de substitution retenu lors des étapes précédentes. L'analyse de ces réponses est faite à partir des paramètres entrés (étape 292) par un logiciel spécifique à l'entreprise dans une étape 294 et il est proposé dans une étape suivante 296 une page HTML exposant les possibilités de modification à apporter à cette installation. Selon les choix effectués par l'usager (étape 298), il est donné des conseils de redimensionnement de l'installation (étape 300) et une proposition d'envoi des résultats de l'étude par télécopie est faite dans une étape 302. Mais l'usager peut aussi demander une autre étude avec un autre gaz de substitution (retour à étape 290) ou demander l'établissement d'une relation avec un conseiller technique en saisissant son numéro de téléphone dans une page HTML de saisie dans une étape 304. A l'issue de la communication effectuée dans une étape 306, l'usager peut terminer le service (étape 310) ou revenir à la page d'accueil HTML principale de l'étape 290 ou à une page HTML indiquée par le conseiller

(étape 308).

Enfin, l'usager peut aussi choisir de consulter le dossier qu'il aura préalablement fait établir par le service qui lui propose alors une page HTML de saisie de son numéro de dossier dans une étape 312. Après

vérification de ce numéro, dans une étape suivante 314, la description des

résultats de l'étude sont affichés dans une page HTML à l'étape 316 et l'usager peut demander son envoi par télécopie (étape 318), la mise en relation avec un conseiller technique (retour à l'étape 304) ou la fin du

service dans une ultime étape 320.

On aura noté que, comme avec l'exemple précédent, l'usager peut au o0 cours d'un même échange passer d'un média de communication à un autre sans que cet échange soit interrompu. Il peut ainsi alors qu'il est en consultation du service d'expertise de l'entreprise sur le WEB recevoir automatiquement une télécopie ou se mettre en relation avec un conseiller de cet entreprise et à l'issue de ces opérations poursuivre sa consultation

initiale.

Un autre exemple d'application de l'architecture de communication selon l'invention à un service après vente est illustré sur la figure 8. Dans une première étape 400, le serveur informatique de l'entreprise est en attente d'une connexion à l'un de ses services, la réception d'un premier appel entraînant, dans une seconde étape 402, la mise en place du scénario de service après vente correspondant à l'appel reçu. Selon la nature de l'accès au service, par exemple par le téléphone ou par le WEB (mais bien évidemment un accès par Minitel est aussi envisageable), le scénario se

déroulera différemment.

Dans le cadre d'un accès par téléphone, l'usager est invité par lecture des fichiers sonores du service à prononcer un choix sur une proposition de menu dans une étape 404. Par exemple, selon son choix, il est procédé dans une étape 406 à la lecture d'un fichier sonore concernant les horaires d'ouverture des bureaux, ou bien à l'enregistrement d'une réclamation dans une étape 408 puis à la fin du service dans une étape suivante 410. Si l'usager souhaite une information sur les produits, il est procédé, dans une étape 412, à la lecture d'un fichier sonore de demande de marque ou type de produit, puis après la communication de l'information relative à ce produit par lecture du fichier sonore correspondant dans une étape 414, il est demandé à l'usager dans une étape 416 s'il désire être mis en relation avec un conseiller de l'entreprise. En cas de réponse positive, ce contact est effectué dans une étape 418 puis à son issue, comme en cas de réponse

négative, le service est achevé (étapes 420 et 422).

Dans le cadre d'un accès via le WEB, le service envoi, dans une étape 424, une première page d'accueil HTML proposant un menu avec par exemple un choix entre une prise de connaissance des horaires ou une demande de réclamation ou d'informations sur un produit. Chacun de ces choix provoque l'affichage d'une nouvelle page HTML (respectivement aux étapes 426, 428, 430) et la fin du service dans une étape 432 ou l'affichage d'une page HTML sur le produit demandé dans une étape 434. A l'issue de cet affichage, l'usager peut mettre fin au service dans une étape 436 ou demander à être mis en relation avec un conseiller de l'entreprise en communiquant son numéro de téléphone à l'étape 438. Le service met alors en contact l'usager avec ce conseiller dans une étape 440. Durant cette communication, le conseiller peut faire procéder à la lecture d'informations sur un produit donné (lecture de l'étape 414) puis reprendre la communication si l'usager le désire (reprise des étapes 416 et 418). A la fin de la communication, le service retourne une page d'accueil HTML dans une étape 442, laissant à l'usager le choix d'autres demandes de renseignements complémentaires et éventuellement repassage sur le média

vocal. Une étape 444 indique ensuite la fin du service.

Comme avec les applications précédentes, on aura noté avec quelle facilité le passage d'un média de communication à l'autre (en l'espèce entre le média vocal et le média WEB) est effectué sans que ce passage

n'interrompe l'entretien de l'usager.

La figure 9 montre un autre exemple d'application de l'architecture de communication selon l'invention dans le cadre d'un service vocal de prise de commande à distance par téléphone. Dans une première étape 450, le serveur informatique de l'entreprise est en attente d'une connexion à l'un de ses services, la réception d'un premier appel entraînant, dans une seconde étape 452, la mise en place du scénario de service vocal de prise de commande à distance par téléphone correspondant à l'appel reçu. Dans une étape suivante 454, le service procède à la lecture d'un fichier sonore d'accueil demandant notamment son code d'identification à l'usager et effectue à partir de ce code une récupération des données relatives à cet usager dans une étape 456. Il peut être noté ici que le code en question peut être obtenu par reconnaissance vocale de la voix de l'usager ou par reconnaissance des codes DTMF reçus par la frappe du clavier du téléphone de l'usager. Si le code fourni est erroné, il est demandé dans une étape 458 d'effectuer une nouvelle saisie ou après trois demande non satisfaites il est procédé à une fin du service (étape 460). Si, au contraire, le code fourni est correct, un menu principal correspondant au service est, dans une étape 462, lu à l'usager qui peut alors choisir entre un accès aux promotions du

0o jour ou à une commande habituelle de produits par exemple.

Si l'usager opte pour sa commande habituelle, après une récupération de sa liste de commande par accès à la base de données de l'entreprise (étape 464), le service annonce successivement les différents produits la constituant avec la quantité habituellement commandée dans une étape 466 et prend en compte dans une étape suivante 468 la demande exprimée par l'usager. A la fin de la liste, la commande est enregistrée dans une étape 470 et il est proposé à l'usager dans une étape suivante 472 s'il souhaite recevoir immédiatement une confirmation de cette commande par télécopie. Selon le choix de l'usager effectué dans une étape 474, la télécopie de confirmation est envoyée (étape 476) et la fin de service est annoncé à l'usager (étape

478) ou il est mis directement fin au service (étape 480).

Si l'usager souhaite connaître les promotions du jour, le service, après récupération de ces promotions dans la base de données de l'entreprise (étape 482), énumère l'une après l'autre ces promotions et demande à l'usager s'il souhaite en profiter dans une étape 484. Il prend alors en compte la demande de l'usager dans une étape 486 et en fin de liste enregistre les choix de l'usager (étape 488) avant de lui demander s'il désire une confirmation immédiate de sa commande par télécopie (liaison avec

l'étape 472).

Les quelques exemples précités montrent que l'architecture de communication selon l'invention permet la mise en oeuvre d'une très large gamme d'applications plurimédias offrant des services particulièrement diversifiés. Chaque application plurimédia étant définie par un scénario déterminé auquel sont associées des données spécifiques répondant aux besoins de communication de l'entreprise et correspondant aux services qu'elle souhaite offrir aux usagers. Bien entendu, les moyens matériels mis en oeuvre dépendront essentiellement de la nature des services rendus et de la charge que l'entreprise souhaite voir supporter à son architecture et ils pourront varier d'un simple poste informatique à une architecture distribuée plus ou moins développée. De même, les moyens logiciels dépendront de ces besoins de communication et, notamment, dans le cas de l'application illustrée à la figure 8 (service après vente) qui n'offre pas d'accès par Minitel ni ne reçoit ou envoie de télécopie, il ne sera pas nécessaire de to posséder les pilotes FAX et VIDEOTEX. Dans le cadre de l'application de la figure 9 (service vocal de prise de commande), ce sont les pilotes

VIDEOTEX et WEB qui s'avèrent inutiles.

Claims

REVENDICATIONS

1. Système de communication destiné à offrir des services à des usagers d'une entreprise, l'accès aux services de l'entreprise étant effectué par les usagers à partir de postes de consultation (8) reliés au système (5) au travers d'un ou plusieurs réseaux de télécommunication (6, 7) supports de différents médias de communication et permettant à ces usagers d'accéder à des ressources de ce système, système caractérisé en ce qu'il comporte: des moyens (2; 10, 12, 14, 16) de pilotage des différents médias de o0 communication pour assurer une interface entre l'usager et une application plurimédia relative au service demandé par cet usager, des moyens (3; 18, 20) de traitement des informations accessibles depuis ou fournies à l'application plurimédia pour adapter le format de données de ces informations applicatives aux formats de données des i5 médias de communication utilisés par l'usager, et des moyens (1; 30, 32, 34, 36) de gestion de l'application plurimédia pour décider, en fonction d'un scénario préétabli de diffusion des informations, de l'exécution des différentes actions résultant du service demandé par l'usager, les interactions entre les différentes ressources de ce système étant réalisées par l'intermédiaire d'une interface commune (API-PMU)

supportant un protocole de communication unique.

2. Système de communication selon la revendication 1, caractérisé en ce que lesdites ressources comportent en outre des moyens

d'administration (4; 24; 24a) pour permettre une configuration du système.

3. Système de communication selon la revendication 2, caractérisé en ce que lesdits moyens d'administration comportent des moyens de collecte d'information (24b, 24c) en vue de l'établissement de

journaux de bord et d'états statistiques.

4. Système de communication selon le revendication 1, caractérisé en ce qu'il comporte en outre une base de donnée (22) qui comporte au moins des données relatives aux services offerts par l'entreprise et dont l'accès peut être effectué depuis l'un quelconque des

moyens de pilotage, de traitement et de gestion constituant le système.

5. Système de communication selon la revendication 1, caractérisé en ce que les moyens de pilotage, de traitement et de gestion constituant le système de communication sont reliés entre eux par l'intermédiaire d'un réseau de type TCP/IP (26) supportant le protocole de communication unique. 6. Système de communication selon la revendication 1, caractérisé en ce que ledit moyen de pilotage de média de communication comporte des moyens de pilotage (10) d'une interface de télécopie pour

assurer l'envoi et la réception de télécopie.

7. Système de communication selon la revendication 1, caractérisé en ce que ledit moyen de pilotage de média de communication comporte des moyens de pilotage (12) d'une interface vocale pour assurer

l'envoi, la réception et l'enregistrement de séquences vocales.

8. Système de communication selon la revendication 1, caractérisé en ce que ledit moyen de pilotage de média de communication comporte des moyens de pilotage (14) d'une interface videotex pour assurer

la présentation de pages de données videotex.

9. Système de communication selon la revendication 1, caractérisé en ce que ledit moyen de pilotage de média de communication comporte des moyens de pilotage (16) d'une interface Internet pour assurer la présentation de pages de données interprétables par un navigateur Internet. Système de communication selon la revendication 1, caractérisé en ce que ledit moyen de traitement comporte des moyens pour assurer une transformation des informations, à destination ou en provenance de l'usager, d'un premier format de données relatif à l'interface unifiée << API-PMU " en un second format de données relatif au pilote de média

considéré et distinct du premier.

11. Système de communication selon la revendication 10, caractérisé en ce que ledit moyen de traitement des informations comporte un moyen de reconnaissance (18) des séquences vocales reçues de l'usager lors de sa liaison avec le système en transformant ces séquences vocales en une suite de caractères reconnaissables par l'application relative au service concerné. 12. Système de communication selon la revendication 10, caractérisé en ce que ledit moyen de traitement des informations comporte un moyen de synthèse vocale dit " text-to-speech " (20) permettant à partir d'une suite de caractères la génération de séquences vocales à destination de l'usager.