FR2758927A1 - Systeme et procede pour commander des unites d'abonne de telecommunication avec des ordinateurs personnels - Google Patents

Abstract

Le système de l'invention comprend un certain nombre d'ordinateurs personnels (20), un certain nombre d'unités d'abonné de télécommunication et au moins un dispositif de commutation qui comprend un serveur de mobilité (30) comprenant des moyens de commande par un tiers (31). Les ordinateurs personnels communiquant avec le serveur de mobilité (30) par l'intermédiaire d'une interface de commande par un tiers, et chaque ordinateur personnel (20) comprend une application pour des services de téléphonie basée sur écran (23). Cette application utilise une interface de commande par un participant, pour la communication avec l'utilisateur, et chaque ordinateur personnel comprend des moyens de conversion (24) pour la conversion entre des opérations de commande par un participant et par un tiers.par.

Description

La présente invention concerne la commande de télé-

communications, par exemple d'unités d'abonnés de télécom-

munication au moyen d'un ordinateur personnel. L'invention

concerne en particulier un système pour commander des uni-

tés d'abonnés de télécommunication au moyen d'un ordinateur personnel. L'invention concerne en outre des procédés pour gérer et commander des unités de télécommunication par l'intermédiaire d'un ordinateur personnel, en connectant

des appels entrants et sortants d'une unité de télécommuni-

cation au moyen d'un ordinateur personnel. L'invention con-

cerne en particulier la technique permettant à des utilisa-

teurs de téléphones sans fil d'accéder à des applications

de téléphonie basées sur écran.

Des applications de téléphonie basées sur écran sont connues, en ellesmêmes, pour des téléphones fixes,

par exemple pour des téléphones connectés au réseau de té-

lécommunication commuté public (ou PSTN pour "Public Swit-

ched Telecommunications Network". On connaît deux types de base pour offrir à des utilisateurs d'ordinateur personnel des applications de téléphonie basées sur écran. Le premier

type concerne des applications basées sur la commande d'ap-

pel par un participant ou intervenant (demandeur ou deman-

dé). La commande par un participant est un mécanisme par

lequel un utilisateur peut manipuler son propre téléphone.

Un certain nombre d'ordinateurs personnels (clients parti-

cipants) sont alors connectés les uns aux autres par l'in-

termédiaire d'un réseau local. Chaque ordinateur personnel

de client participant est connecté à un téléphone. La con-

nexion peut être soit ce que l'on appelle une connexion

centrée sur le téléphone, auquel cas un ordinateur person-

nel est connecté au téléphone qui est connecté à son tour à

un dispositif de commutation, par exemple un autocommuta-

teur privé (ou PABX pour "private automatic branch ex-

change"), soit une connexion centrée sur l'ordinateur per-

sonnel, auquel cas un téléphone est connecté à un ordina-

teur personnel qui est connecté à son tour au dispositif de commutation, c'est-à-dire le PABX. Pour le dispositif de

commutation, ou le PABX, aussi bien pour la solution cen-

trée sur le téléphone que pour la solution centrée sur

l'ordinateur personnel, l'utilisateur apparaît être direc-

tement connecté au téléphone. Dans le type utilisant un lo- giciel de commande d'appel par un participant, l'ordinateur

personnel client comprend une application de téléphonie ba-

sée sur écran, un logiciel de commande par un participant et un pilote de port série. Des applications de téléphonie basées sur écran sont exécutées au-dessus du logiciel de

commande par un participant basé sur une interface de pro-

grammation d'applications (ou API pour "application pro-

gramming interface"), et l'ordinateur personnel communique

normalement par le port série.

Le second type concerne des applications basées sur la commande d'appel par un tiers. La commande d'appel par un tiers offre la possibilité d'accéder à n'importe quel téléphone qui est connecté au dispositif de commutation, par exemple un PABX, et d'utiliser ce téléphone. On peut dire que la commande d'appel par un tiers équivaut à la

commande par un opérateur. Un tiers, c'est-à-dire ni le de-

mandeur ni le demandé, commande l'appel. L'utilisateur a une connexion indirecte avec le dispositif de commutation ou le PABX. Cette connexion indirecte est souvent établie

par l'intermédiaire d'un serveur tiers et d'une applica-

tion. Conformément à cette solution, des ordinateurs per-

sonnels, qui sont ici à des clients tiers, sont connectés par l'intermédiaire d'un réseau local qui est également connecté à un serveur tiers qui est connecté au dispositif de commutation, par exemple le PABX, auquel les unités de

télécommunication ou les téléphones sont connectés.

Le serveur tiers remplit ici la fonction d'une pas-

serelle pour la communication entre le PABX et l'applica-

tion de téléphonie basée sur écran qui réside sur l'ordina-

teur personnel client. Un utilisateur doit entrer en commu-

nication avec le serveur tiers pour identifier le téléphone

qui est affecté à cet utilisateur. Une information concer-

nant ce téléphone/utilisateur est émise vers l'application

d'utilisateur par l'intermédiaire du serveur tiers. Le ser-

veur tiers communique à son tour avec le PABX. Le type uti-

lisant un logiciel de commande d'appel par un tiers est tel que l'ordinateur personnel client comprend l'application de téléphonie basée sur écran, le logiciel de commande par un participant, le logiciel de serveur et un pilote de réseau local, tandis que l'ordinateur personnel serveur comprend le logiciel de commande par un tiers, un pilote de réseau local et un pilote de commutateur ou un pilote de PABX. La communication entre le logiciel de serveur chez le client et le serveur tiers est souvent privative, ce qui est un inconvénient. Comme on peut le voir, les solutions connues sont très complexes et leur souplesse est limitée et restreint

la commande par l'utilisateur. En outre, un serveur supplé-

mentaire est exigé. Il ressort de la manière selon laquelle les solutions connues fonctionnent qu'en outre elles ne donnent pas à l'utilisateur une liberté suffisante dans la commande des télécommunications, des services, etc. On a donc besoin d'un système pour commander des unités d'abonnés de télécommunication par l'intermédiaire d'un ordinateur personnel, qui offre à un utilisateur un

niveau de souplesse élevé. On a également besoin d'un sys-

tème au moyen duquel une application de commande par un participant peut être utilisée pour commander une unité de télécommunication d'abonné, par exemple un téléphone sans fil. On a également besoin d'un système pour commander des télécommunications au moyen d'un ordinateur personnel qui soit simple et qui n'exige pas un équipement supplémentaire

tel que des serveurs de commande par un tiers supplémentai-

res, etc. On a besoin en particulier d'un système par lequel des

applications de téléphonie basées sur écran puissent être of-

fertes à des utilisateurs de téléphones sans fil et leur

permettent d'accéder aux services téléphoniques.

L'invention procure donc un système qui comprend un certain nombre d'ordinateurs personnels, un certain nombre

d'unités d'abonnés de télécommunication et au moins un dis-

positif de commutation ayant une fonctionnalité de commuta-

tion. Le dispositif de commutation comprend un serveur de mobilité comprenant des moyens de commande par un tiers et un certain nombre d'ordinateurs personnels sont connectés

au serveur de mobilité par l'intermédiaire d'un réseau lo-

cal, c'est-à-dire qu'ils sont connectés par un réseau local

au serveur de mobilité. La communication entre les ordina-

teurs personnels et le serveur de mobilité a lieu par l'in-

termédiaire d'une interface de commande par un tiers. Cha-

que ordinateur personnel comprend une application pour des

services de téléphonie basés sur écran, et cette applica-

tion utilise une interface de commande par un participant pour des communications d'utilisateur. Chaque ordinateur personnel comprend des moyens de conversion pour effectuer

une conversion entre l'interface de commande par un parti-

cipant et l'interface de commande par un tiers, de façon que l'utilisateur puisse utiliser l'application basée sur la commande par un participant avec des moyens de commande

par un tiers dans le serveur de mobilité.

De façon avantageuse, les interfaces de commande par un participant et par un tiers sont respectivement des interfaces standards. Le logiciel de commande par un tiers pour un certain nombre d'unités de télécommunication

d'abonnés, par exemple des téléphones sans fil, est incor-

poré dans le serveur de mobilité et le logiciel de commande

par un participant est incorporé dans chacun des ordina-

teurs personnels.

Le serveur de mobilité est un dispositif qui assure entre autres la conversion de protocole, et qui permet en

particulier à des téléphones sans fil et cellulaires d'ac-

céder à un réseau privé ou à un autocommutateur privé. Il est également possible d'établir des réseaux entiers de

serveurs de mobilité. Ceci n'est cependant pas envisagé da-

vantage ici, même si l'invention est également applicable à de tels modes de réalisation. Des serveurs de mobilité sont décrits par exemple dans les demandes de brevet WO 96/21330 et WO 96/21329, bénéficiant toutes deux de la priorité des demandes de brevet des E.U.A. 08/366 469 et 08/366 471, dé- posées le 30 décembre 1994, et incorporées ici à titre de référence. Conformément à la demande WO 96/21330, un serveur de mobilité est disposé entre un commutateur privé ou PBX (autocommutateur privé ou PABX) et au moins un commutateur de radiocommunication (ou REX pour "radio exchange") qui,

en coopération avec le PBX, simule un commutateur de radio-

communication, pour offrir ainsi la mobilité sans fil entre

un certain nombre de REX. Le serveur de mobilité est dispo-

sé entre un PBX et un certain nombre de REX en utilisant

l'interface existante entre eux.

Conformément à la demande WO 96/21329, un serveur de mobilité est connecté par une interface à un commutateur

et il connecte un système cellulaire au serveur de mobili-

té, directement ou par l'intermédiaire par exemple d'un PBX, de façon qu'un téléphone cellulaire apparaisse comme un poste intérieur du commutateur, procurant ainsi un accès

cellulaire, par exemple à un PBX.

Dans un mode de réalisation, le serveur de mobilité est connecté à un dispositif de commutation, comme par

exemple un PABX. Dans un autre mode de réalisation, le ser-

veur de mobilité lui-même comprend une fonctionnalité de

commutation. De façon avantageuse, les ordinateurs person-

nels sont connectés au serveur de mobilité par l'intermé-

diaire d'un réseau local. Pour procurer une application de téléphonie basée sur écran pour un utilisateur sans fil,

deux connexions sont exigées, l'une à l'ordinateur person-

nel et l'autre au téléphone sans fil, comme mentionné ci-

dessus. On utilise avantageusement le protocole CSTA pour

la communication entre le serveur de mobilité et l'ordina-

teur personnel. CSTA signifie "Computer Supported Communi-

cations Applications", c'est-à-dire "applications de commu-

nication mises en oeuvres par ordinateur". On utilise avan-

tageusement le protocole CSTA phase II de l'organisme ECMA ("European Computer Manufacturers Association"). En outre, dans un mode de réalisation, l'interface de commande par un participant est une interface TAPI

(marque déposée), qui signifie "Telephony Application Pro-

gramming Interface", c'est-à-dire "interface de programma-

tion d'applications de téléphonie".

De façon avantageuse, n'importe quelle application

basée sur la commande par un participant, ainsi que n'im-

porte quelle application basée sur la commande par un tiers peuvent être commandées par l'intermédiaire d'un ordinateur personnel quelconque qui est inclus dans le système, pour n'importe quelle unité d'abonné de télécommunication du système. De façon avantageuse, on a également besoin d'un

système par lequel un utilisateur puisse non seulement con-

necter et déconnecter un appel, et recevoir un appel en

utilisant une commande par ordinateur personnel, mais éga-

lement commander et gérer le profil de service d'utilisa-

teur. Ceci est permis par l'utilisation d'un système tel

que celui décrit ci-dessus, dans lequel le serveur de mobi-

lité a une architecture qui comprend ce que l'on appelle des modules de fonctions qui peuvent être introduits (et

retirés) conformément à la license ou autorisation person-

nelle de l'utilisateur. Ainsi, au moyen de la commande par ordinateur personnel, un utilisateur peut commander les services qu'il désire avoir; il est possible de définir un profil de service personnel. Ceci est cependant un mode de réalisation particulièrement avantageux qui ne dépend pas,

en lui-même, des caractéristiques inventives de l'inven-

tion, mais qui peut être utilisé en combinaison avec elles.

A partir d'un ordinateur personnel quelconque du système, un utilisateur peut avantageusement diriger des appels vers des téléphones sans fil, fixes aussi bien que

cellulaires, et recevoir des appels provenant de ces télé-

phones. D'une manière similaire, un utilisateur peut avan-

tageusement définir le profil de service, mentionné ci-

dessus, qui ne dépend pas en lui-même de la conversion en-

tre les interfaces de commande par un participant et les

interfaces de commande par un tiers.

Les moyens de conversion dans l'ordinateur person-

nel comprennent avantageusement un dispositif pour traduire

des ordres d'interface de commande d'appel par un partici-

pant en opérations d'interface de commande d'appel par un

tiers, et inversement, et des moyens de codage pour effec-

tuer le codage/décodage transformant les opérations de com-

mande d'appel par un tiers en paquets, et inversement, et un émetteur/récepteur pour émettre/recevoir des paquets sur les connexions de réseau local. L'interface de commande par un participant, par exemple l'interface TAPI, comprend avantageusement une interface de fournisseur de services de téléphonie de bas niveau, ou TSPI pour "Telephony Service Provider Interface", et des ordres de TSPI sont traduits en opérations de CSTA, la structure de traduction des moyens de conversion collectant des appels de fonction provenant de l'interface TSPI qui sont transformés en opérations de CSTA. Dans le dispositif de codage/décodage, les opérations

de CSTA sont codées en particulier par un algorithme de co-

dage faisant passer à ce que l'on appelle des paquets BER,

et inversement. Le terme BER signifie "Basic Encoding Ru-

les" (c'est-à-dire règles de codage de base), et il désigne un standard de codage pour ASN.1, c'est-à-dire "Abstract Syntax Notation One", qui est une syntaxe de transfert de

données que l'on peut par exemple utiliser. La communica-

tion du serveur de mobilité par l'émission/réception des paquets est avantageusement accomplie par l'intermédiaire

d'un émetteur/récepteur des moyens de conversion qui assem-

ble des paquets BER conformément à un protocole UDP, c'est-

à-dire "User Datagram Protocol" (protocole de datagramme d'utilisateur), qui est un protocole sans connexion pour la

communication sur un réseau local, et inversement. Le pi-

lote de serveur de mobilité (l'interface de fournisseur de

services de téléphonie) qui comprend des moyens de traduc-

tion, des moyens de codage/décodage et des moyens d'émis-

sion/réception, est responsable de l'ouverture/fermeture de session avec le serveur de mobilité, et l'application de téléphonie basée sur écran est responsable des services restants. A la place de l'UDP, on peut utiliser le protocole

TCP ("Transmission Control Protocol", c'est-à-dire proto-

cole de commande de transmission", qui est utilisé dans l'Internet). Il s'agit d'un protocole orienté connexion, contrairement à i'UDP qui est sans connexion, et il est plus "sûr", c'est-à-dire qu'il fournit une information si un ordinateur personnel a cessé de fonctionner, etc. Il

exige cependant davantage de puissance de la part du ser-

veur de mobilité. Ceci concerne cependant d'autres modes de réalisation. Il y a des avantages à utiliser i'UDP, ainsi

qu'à utiliser le TCP.

L'invention procure également un procédé pour con-

necter un appel à une unité de télécommunication qui est

connectée à un commutateur, en utilisant un ordinateur per-

sonnel comprenant une application de téléphonie basée sur

écran, pour commander un certain nombre d'unités de télé-

communication. Le procédé comprend les étapes suivantes:

- on spécialise l'ordinateur personnel pour l'unité de té-

lécommunication à partir de laquelle un appel doit être effectué, les identifications pour un certain nombre d'unités de télécommunication étant enregistrées dans des moyens d'enregistrement, par exemple de l'ordinateur personnel, ces moyens d'enregistrement étant connectés à

des moyens de commande par un tiers d'un serveur de mo-

bilité; - on signale aux moyens de commande par un tiers dans le serveur de mobilité connecté à un commutateur, ou à un serveur de mobilité lui-même, comprenant une possibilité

de commutation, qu'un ordinateur personnel est spéciali-

sé pour une unité de télécommunication donnée; - on indique à l'application de téléphonie basée sur écran dans l'ordinateur personnel l'unité de télécommunication de destination à laquelle un appel doit être connecté; - on convertit cette information de destination dans une interface de commande par un participant, en opérations d'interface de commande par un tiers, dans des moyens de conversion dans l'ordinateur personnel;

- on transmet l'information convertie aux moyens de com-

mande par un tiers; - on interprète les opérations précitées, dans les moyens de commande par un tiers dans le serveur de mobilité, et on commande, en utilisant ces opérations, la connexion de l'unité de télécommunication appelante vers l'unité

de télécommunication appelée, au moyen de la fonctionna-

lité de commutation.

Une connexion connectée peut avantageusement être déconnectée par l'intermédiaire de l'ordinateur personnel, cette opération comprenant ainsi les étapes suivantes: on fournit à l'application de téléphonie basée sur écran une

information indiquant que la connexion doit être déconnec-

tée, on transfère l'information provenant de l'application de téléphonie basée sur écran aux moyens de commande par un participant, dans l'ordinateur personnel, on convertit les ordres de commande par un participant en une opération de commande par un tiers dans les moyens de conversion de l'ordinateur personnel, et on déconnecte la connexion par l'intermédiaire des moyens de commande par un tiers. Selon une variante, un appel peut être déconnecté en décrochant,

par exemple sur le téléphone sans fil.

L'invention procure également un procédé pour con-

necter un appel entrant à au moins une première unité de

télécommunication, à partir d'une seconde unité de télécom-

munication, dans lequel la première unité de télécommunica-

tion peut comprendre un ou plusieurs téléphones parmi un téléphone sans fil, un téléphone cellulaire ou un téléphone fixe, ce procédé comprenant les étapes suivantes: - on détecte dans des moyens de commande par un tiers, dans le serveur de mobilité, un appel entrant dirigé vers la ou les premières unités de télécommunication; - on examine, par l'intermédiaire des moyens de commande

par un tiers, s'il existe pour la ou les premières uni-

tés de télécommunication un ordinateur personnel fonc-

tionnant en coopération, qui comprend des moyens de com-

mande par un participant;

- si oui, on émet vers des moyens de conversion dans l'or-

dinateur personnel, à partir des moyens de commande par

un tiers, par l'intermédiaire d'une interface de com-

mande par un tiers, une information concernant un appel qui provient de la seconde unité de télécommunication et

qui est dirigé vers la première unité de télécommunica-

tion; - on convertit l'opération de commande par un tiers en une opération de commande par un participant; - on informe l'application de téléphonie basée sur écran,

au sujet de l'appel dirigé vers la ou les premières uni-

tés de télécommunication;

- on connecte l'appel.

De façon avantageuse, un utilisateur peut également

décider, par l'intermédiaire d'un ordinateur personnel as-

socié ou spécialisé, si un appel doit être connecté au té-

léphone sans fil de l'utilisateur ou à un téléphone fixe, etc. L'invention procure également un procédé pour gérer et commander un téléphone sans fil par l'intermédiaire d'un

ordinateur personnel comprenant une application de télépho-

nie basée sur écran. L'ordinateur personnel comprend une

interface de commande par un participant. L'ordinateur per-

sonnel est connecté par un réseau local à un serveur de mo-

bilité qui soit est connecté par exemple à un autocommuta-

teur privé (ou PABX), soit comprend lui-même une fonction-

nalité de commutation, ce serveur de mobilité comprenant des moyens pour la commande par un tiers. Dans l'ordinateur

personnel, une conversion est accomplie entre des opéra-

tions de commande par un participant et des opérations de commande par un tiers, de façon qu'un utilisateur puisse

utiliser l'application basée sur la commande par un parti-

cipant, pour des moyens basés sur la commande par un tiers.

Il faut cependant noter que si le logiciel de commande par

un tiers est incorporé dans l'ordinateur personnel, la con-

version n'est évidemment pas effectuée. Un profil de ser-

vice personnel peut avantageusement être défini dans le serveur de mobilité, pour un utilisateur, à partir de la partie d'application de téléphonie basée sur écran dans

l'ordinateur personnel, à condition que l'application sup-

porte une telle fonctionnalité.

Un avantage consiste en ce que la présente inven-

tion procure respectivement un système et un procédé sou-

ples, permettant à un utilisateur de commander d'une ma-

nière simple des appels sortants aussi bien que des appels

entrants. Un autre avantage consiste en ce que des opéra-

tions de commande par un participant aussi bien que par un

tiers peuvent être accomplies à partir d'un ordinateur per-

sonnel, en utilisant des moyens de commande par un partici-

pant dans l'ordinateur personnel, et en ce que des serveurs supplémentaires ne sont pas exigés, ce qui rend le système

simple et économique et procure néanmoins un degré de sou-

plesse beaucoup plus élevé que celui de systèmes connus

jusqu'à présent.

D'autres caractéristiques et avantages de l'inven-

tion seront mieux compris à la lecture de la description

qui va suivre de modes de réalisation donnés à titre

d'exemples non limitatifs. La suite de la description se

réfère aux dessins annexés, dans lesquels: La figure 1 représente schématiquement un système conforme à l'invention,

La figure 2 illustre schématiquement deux ordina-

teurs personnels avec des téléphones sans fil spécialisés,

connectés à un serveur de mobilité comprenant une fonction-

nalité de commutation, La figure 3 illustre de manière schématique un type de logiciel pour la commande d'appel sans fil, conformément à l'invention, La figure 4 illustré schématiquement un ordinateur personnel qui est connecté par un réseau local à un serveur

de mobilité, conformément à un mode de réalisation de l'in-

vention, La figure 5 montre un autre mode de réalisation

* d'un serveur de mobilité connecté à un ordinateur person-

nel,

La figure 6 montre un serveur de mobilité compre-

nant une fonctionnalité de commutation, qui est connecté par un réseau local à un ordinateur personnel, et qui est

connecté à un commutateur de radiocommunication disposé en-

tre des première et seconde stations de base;

La figure 7 est un organigramme schématique concer-

nant la connexion d'un appel provenant d'un premier abonné et dirigé vers un second abonné, La figure 8 est un organigramme simple décrivant la manipulation d'un appel entrant, et

La figure 9 montre un exemple d'un serveur de mobi-

lité comprenant un certain nombre de modules de fonctions.

La figure 1 montre un mode de réalisation dans le-

quel un utilisateur a deux unités d'abonné de télécommuni-

cation, c'est-à-dire un téléphone sans fil 1 (PP) et un té-

léphone fixe 1' (FS). En utilisant un ordinateur personnel 2 (PC) comprenant une application de logiciel de téléphonie basée sur écran, un utilisateur peut commander le téléphone sans fil 1 ainsi que le téléphone fixe 1', par exemple pour établir des appels dirigés vers d'autres unités d'abonné de

télécommunication et pour recevoir des appels.

L'ordinateur personnel 2 est connecté à un serveur

de mobilité 3, par exemple par l'intermédiaire d'une con-

nexion de réseau local (ou LAN pour "Local Area Network") Dans le mode de réalisation qui est représenté, le serveur

de mobilité est connecté à un commutateur de radiocommuni-

cation (REX) 5 et à un commutateur 4. L'application de té-

léphonie basée sur écran peut avoir des fonctions telles que la fourniture d'une information d'annuaire

(répertoire), la possibilité de transfert entre un télé-

phone fixe, un téléphone cellulaire et un téléphone sans fil, et également, avantageusement, la gestion du profil personnel. Ceci sera cependant envisagé ultérieurement de

façon plus approfondie.

La figure 2 illustre un système conforme à un mode de réalisation dans lequel le serveur de mobilité (MOBSX) A comprend une fonctionnalité de commutation. Selon une variante, un serveur de mobilité peut être connecté à un dispositif de commutation. Deux ordinateurs personnels

clients sans fil, 2A, 2B, sont connectés au serveur de mo-

bilité 30A par l'intermédiaire du réseau local 6. Chaque

utilisateur sans fil a un téléphone sans fil lA, lB vis-à-

vis duquel les ordinateurs personnels respectifs 2A, 2B sont spécialisés. Un logiciel de commande d'appel par un tiers est incorporé dans le serveur de mobilité 30A. Une conversion entre des interfaces de commande d'appel par un participant et par un tiers est effectuée respectivement

dans les ordinateurs personnels clients 2A et 2B.

Ceci est illustré sur la figure 3 qui montre un

type de logiciel pour la commande d'appel sans fil. L'ordi-

nateur personnel client est désigné ici par la référence 20. L'ordinateur personnel 20 comprend une application de téléphonie basée sur écran SBTA 23. En outre, il comprend un logiciel de commande d'appel par un participant, 21. Un logiciel de commande par un tiers, 31, est incorporé dans le serveur de mobilité MOBS 30. Le serveur de mobilité 30 comprend en outre un logiciel de commande d'appel 34 qu'il n'est cependant pas nécessaire d'envisager davantage ici, du fait qu'il peut être un logiciel de commande d'appel classique. Des moyens de conversion 24 sont incorporés dans

l'ordinateur personnel 20 pour effectuer une conversion en-

tre des opérations/ordres de commande par un participant et

des opérations/ordres de commande par un tiers. L'ordina- teur personnel 20 et le serveur de mobilité 30 sont connec- tés par

l'intermédiaire d'un réseau local 6, et chacun

d'eux comprend un pilote de réseau local respectif 22, 32.

On utilise avantageusement des interfaces standard à la fois pour la commande d'appel par un participant et pour la commande d'appel par un tiers. Le fait qu'il soit possible

d'utiliser des interfaces standard est un avantage de l'in-

vention, qui permet de la mettre en oeuvre aisément et de façon attractive. Un autre avantage de l'invention consiste en ce qu'un ordinateur personnel serveur supplémentaire n'est pas exigé. L'utilisateur peut exécuter n'importe

quelles applications basées sur la commande par un partici-

pant dans l'ordinateur personnel client 20, et n'importe quelle application basée sur la commande d'appel par un tiers, dirigée vers l'autocommutateur privé, ou PABX, ou le serveur de mobilité qui, comme mentionné ci-dessus, peut comprendre lui-même une fonctionnalité de commutation, ou

peut être connecté à un PABX, procurant ainsi la fonction-

nalité de commutation. Il faut cependant noter que bien qu'on mentionne de façon générale un PABX, l'invention n'est évidemment pas limitée à celui-ci. Tout au contraire, le terme PABX désigne ici un commutateur en général, privé

aussi bien que public.

La figure 5 montre un serveur de mobilité (MOBS) B qui est connecté par l'intermédiaire d'une liaison Ethernet & TCP/IP 6B à un ordinateur personnel 20B. Dans un mode de réalisation avantageux, l'ordinateur personnel est par exemple un ordinateur personnel basé sur Windows 95 ou Windows 3.11 de Microsoft (marque déposée), qui communique

avec le serveur de mobilité 30B par l'intermédiaire du pro-

tocole UDP/IP que l'on décrira davantage en se référant à la figure 4. Cependant, sur la figure 5, on utilise à la

place le protocole TCP/IP (Transmission Connection Proto-

col/Internet Protocol). De façon avantageuse, comme on l'a déjà mentionné ci-dessus, le protocole entre le serveur de mobilité 30B et l'application de téléphonie basée sur écran de l'ordinateur personnel, est basé sur le système CSTA phase II (ECMA). Dans ce mode de réalisation particulier,

l'application d'ordinateur personnel supporte la fonction-

nalité de numéro personnel (PN) vers une seule configura-

tion de serveur de mobilité, c'est-à-dire le serveur de mo-

bilité 30B. Dans ce cas, des messages spécifiques corres-

pondant à un numéro personnel sont disponibles pour les

utilisateurs demandeur et demandé seulement s'ils appar-

tiennent au seul et même serveur de mobilité. Cependant,

dans d'autres modes de réalisation, on utilise une configu-

ration de serveurs de mobilité organisés en réseau.

L'application proposée par Ericsson sous l'appella-

tion "Personal Screen Call" (PSC), c'est-à-dire "appel avec gestion par écran de type personnel", est un exemple d'une application de téléphonie basée sur écran. L'application

supporte avantageusement des utilisateurs de serveur de mo-

bilité seulement, ayant un téléphone sans fil, et des uti-

lisateurs de serveur de mobilité ayant un numéro personnel.

Le serveur de mobilité comprend ici une carte de processeur avec un port de réseau local, prévu par exemple pour être

utilisé pour la gestion, et l'application d'ordinateur per-

sonnel communique avec le serveur de mobilité par l'inter-

médiaire de ce port de réseau local. (D'autres configura-

tions sont évidemment possibles.) Le protocole CSTA

(Computer Supported Telecommunications Applications) con-

cerne un exemple d'une interface de commande par un tiers pour un serveurde mobilité. Il conserve la commande d'un

numéro A ainsi que d'un numéro B (le numéro A étant le nu-

méro du demandeur et le numéro B étant le numéro du deman-

dé), comme il est bien connu dans la technique. Ceci s'op-

pose à la commande de l'ordinateur personnel par un parti-

cipant (par exemple avec l'interface TAPI) qui fait inter-

venir seulement le numéro A. La conversion entre les proto-

coles/interfaces est effectuée dans le convertisseur d'or-

dinateur personnel du pilote de serveur de mobilité. Dans

ce mode de réalisation particulier, l'application de l'or-

dinateur personnel est basée sur MS-Windows 95 ou 3.11 et l'interface "Telephony Application Programming Interface", ou TAPI, de Windows. L'application comprend l'application

TAPI et l'interface appelée "Telephony Service Provider In-

terface" (ou "interface de fournisseur de services de télé-

phonie"), que l'on appelle ci-après pilote TSPI. L'inter-

face TSPI, également appelée "Mobility Server Driver" (c'est-à- dire "pilote de serveur de mobilité"), coopère

avec le logiciel de tiers et également avec d'autres appli-

cations TAPI. Il doit cependant être clair que l'invention n'est évidemment pas limitée à l'utilisation des protocoles mentionnés ici, ceux-ci étant simplement donnés à titre

d'exemples. On peut évidemment utiliser d'autres protoco-

les, comprenant des protocoles connus dans la technique, aussi bien que d'autres protocoles, par exemple développés

dans ce but particulier (ou également dans d'autres buts).

Dans un mode de réalisation avantageux, il est pos-

sible d'avoir à la fois des fournisseurs de services du type PABX (par exemple Ericsson MD 110) et du type serveur

de mobilité (pilotes TSPI), dans la même application d'or-

dinateur personnel et de TAPI. Un utilisateur peut avoir à la fois un téléphone de bureau, un téléphone cellulaire et un téléphone sans fil ou un numéro personnel. Dans un mode de réalisation avantageux, un utilisateur peut sélectionner

l'un des fournisseurs de service, par exemple pour des ap-

pels sortants, etc., si plus d'un fournisseur de service est utilisé en alternance, et s'il y a un seul pilote,

c'est-à-dire le pilote de serveur de mobilité qui est uti-

lisé pour fournir l'accès.

L'utilisateur peut prendre un appel entrant sur l'une quelconque des unités d'abonné de télécommunication,

par exemple un téléphone sans fil ou un téléphone de bu-

reau, si un appel entrant active les deux terminaux (ou plus) en même temps. Ceci est par exemple une fonction dans

le service de numéro personnel du serveur de mobilité.

L'interface de réseau est indiquée par NW-i/f.

Un certain nombre de fonctions sont mises en oeuvre dans les applications d'ordinateur personnel, et elles sont

supportées par l'intermédiaire du serveur de mobilité. Cer-

taines d'entre elles sont par exemple la procédure d'ouver-

ture de session, la consignation d'appel, la fermeture de session, le numéro personnel (PN), les fonctions liées à un appel, l'appel de base, etc.

En retournant maintenant à la figure 4, on va dé-

crire de façon plus approfondie la réalisation d'un four-

nisseur de service de téléphonie avec commande par ordina-

teur personnel (le pilote lui-même, c'est-à-dire le pilote de serveur de mobilité 24A), pour la communication avec le

serveur de mobilité 30. Comme mentionné ci-dessus, l'ordi-

nateur personnel 20 communique avec le serveur de mobilité par l'intermédiaire du réseau local 6, en utilisant le protocole ECMA CSTA phase II. L'application de téléphonie basée sur écran est avantageusement l'application Personal Screen Call, PSC, et encore plus particulièrement, elle comprend une fonction de gestion de profil 23A. L'interface TAPI et l'interface TSPI, qui est l'interface "bas niveau"

de la TAPI, ont déjà été décrites dans ce qui précède. El-

les sont désignées ici par la référence 21A.

Le pilote 24A a pour tâche principale de traduire

des ordres de TSPI provenant de l'interface TAPI en opéra-

tions de CSTA, de les placer dans les paquets UDP (le pro-

tocole UDP "User Datagram Protocol" est un protocole sans

connexion pour la communication sur un réseau local Ether-

net), pour l'émission de ces paquets UDP vers le réseau, et inversement pour des messages entrants. Comme envisagé en relation avec la figure 5, on peut utiliser à la place le

protocole TCP. En outre, le pilote est responsable des pro-

cédures d'ouverture/fermeture de session dans les services

de numéro personnel. Les services restants sont avantageu-

sement pris en charge par l'application de TAPI. On peut dire que le pilote comprend les moyens de conversion pour la traduction TSPI-CSTA (TSP), un codeur-décodeur CSTA et un émetteur/récepteur UDP. Du fait qu'une application uti- lise l'interface TAPI par exemple pour établir un appel, plusieurs appels de fonctions provenant de l'interface TSPI

et dirigés vers le fournisseur de service seront effectués.

Du fait que tous ces appels ne peuvent pas être directement traduits en opérations CSTA, les moyens de conversion pour la traduction TSPI- CSTA prennent en charge la collecte

d'ordres et la traduction. Les moyens de conversion collec-

tent les appels de fonction provenant de la TSPI et ils les transmettent aux opérations CSTA appropriées. Ils appellent ensuite des fonctions dans le codeur-décodeur CSTA et l'émetteur UDP, pour un traitement ultérieur. L'inverse est

effectué pour des messages entrants.

Après la traduction, les opérations CSTA sont co-

dées par le codeur-décodeur CSTA en formats ROSE ASN.1 (Remote Operation Service Entity, Abstract Syntax Notation

One, qui est une syntaxe de transfert de données). L'algo-

rithme de codage qui est utilisé est dans ce mode de réali-

sation particulier l'algorithme appelé "Basic Encoding Ru-

les", qui est un standard de codage pour ASN.1, que l'on

désigne en abrégé par BER. Les paquets de sortie sont appe-

lés des paquets BER. Pour des messages entrants, le fonc-

tionnement opposé a lieu. Le codeur-décodeur est responsa-

ble seulement du codage/décodage. Il faut cependant noter que le format ASN.1 n'est évidemment pas une exigence pour

le fonctionnement de la présente invention. On peut utili-

ser n'importe quel standard approprié; on peut par exemple

utiliser des protocoles plus simples ou seulement diffé-

rents.

Le pilote 24A communique avec le serveur de mobili-

té 30 par l'émission de paquets de datagrammes sur le ré-

seau local 6, conformément au standard UDP. L'émetteur UDP

prend des paquets BER et il les place dans des paquets UDP.

Si nécessaire, ils sont divisés. L'opération opposée, fai-

sant passer de paquets UDP à des paquets BER, etc., a lieu

lorsque la communication s'effectue dans l'autre sens.

L'émetteur UDP est responsable seulement de la transmission par le réseau et de l'assemblage/désassemblage des paquets UDP. En principe, le pilote 24A doit travailler avec trois interfaces externes, c'est-à- dire l'interface TSPI

(l'interface "bas niveau" de la TAPI), l'interface de ré-

seau et une interface avec l'application de gestion de pro-

fil, si celle-ci est supportée. Le trafic de profil tra-

verse ensuite l'interface TAPI en utilisant des services

étendus, sans que l'interface TAPI ne l'interprète. Cepen-

dant, tout le trafic entre l'application et le fournisseur

de service traverse l'interface TAPI.

La procédure d'ouverture de session est donc accom-

plie par le fournisseur de service, c'est-à-dire le pilote

de serveur de mobilité de l'application d'ordinateur per-

sonnel dirigée vers le serveur de mobilité. Par cette pro-

cédure, l'application d'ordinateur personnel est identifiée et est connectée du point de vue logique au terminal sans

fil de l'utilisateur dans le serveur de mobilité. Des uti-

lisateurs qui n'ont pas un numéro personnel reçoivent un mot de passe qui est lié au numéro de téléphone sans fil, tandis que des utilisateurs qui ont un numéro personnel

utilisent le mot de passe qui est affecté au numéro person-

nel. Le serveur de mobilité indique à l'application

d'ordinateur personnel si un utilisateur a un numéro per-

sonnel ou non, comme on l'a déjà mentionné ci-dessus. L'ap-

plication de téléphonie basée sur écran émet une interroga-

tion et elle reçoit à partir du serveur de mobilité une in-

formation concernant l'état du poste intérieur, de façon à assurer la synchronisation avec l'état du téléphone sans

fil/numéro personnel à ce moment. Si par exemple l'utilisa-

teur est toujours présent au serveur de mobilité, à la suite d'une session précédente, l'utilisateur fait l'objet d'une fermeture de session, pour garantir que l'utilisateur est connecté au serveur de mobilité conformément à une

seule instance et un seul emplacement.

La fonction dite de consignation d'appel est basée

sur l'utilisateur ou l'ordinateur personnel. La consigna-

tion est connectée à l'ordinateur personnel de l'utilisa-

teur, ce qui signifie l'ordinateur personnel à l'endroit

auquel l'application est commencée. Si cet ordinateur per-

sonnel n'est pas actif, ce qui signifie que l'ordinateur personnel a cessé de fonctionner sans l'indiquer au serveur de mobilité, alors l'information de consignation d'appel n'est pas enregistrée ailleurs. Des événements liés à un

appel, comme un appel entrant dirigé vers le poste inté-

rieur, et des appels sortants, sont émis vers l'application

d'ordinateur personnel, à partir du serveur de mobilité.

Des appels sont consignés même s'ils n'aboutissent pas,

comme par exemple des appels filtrés, ou si un numéro tem-

poraire est activé. Dans ce cas, le téléphone sans fil

n'est pas alerté.

Des données d'appel entrant pour un utilisateur ayant un numéro personnel sont consignées dans le but de

savoir si l'appel a fait l'objet d'une réponse, et de con-

naître l'emplacement auquel la réponse a eu lieu. Cette in-

formation peut être utilisée pour changer le profil d'uti-

lisateur, automatiquement ou sous la dépendance de critères définis par l'utilisateur. L'information de consignation

d'appel est enregistrée localement dans l'ordinateur per-

sonnel.

Des appels entrants/sortants sont consignés confor-

mément aux principes généraux de l'application PAS (Personal Screen Call). Cependant, des appels entrants pour

les numéros personnels sont consignés différemment. Des ap-

pels filtrés, ne recevant pas de réponse, sont consignés

comme tels, tandis que des appels qui aboutissent sont con-

signés sous la dépendance de la position de réponse à laquelle ils reçoivent une réponse, ce qui signifie par

exemple qu'ils reçoivent une réponse par un téléphone cel-

lulaire, par un téléphone sans fil, etc. La fermeture de session est effectuée dans trois cas ou dans trois circonstances. Le premier est le cas o

l'application d'ordinateur personnel se termine normale-

ment. L'application d'ordinateur personnel émet alors un

message de fermeture de session vers le serveur de mobili-

té, qui libère ensuite les ressources et met fin à la ses-

sion dirigée vers l'application de PC. En outre, chaque

nouvelle ouverture de session avec le même utilisateur con-

duit à une fermeture de la session précédente, s'il en existe une, dans le serveur de mobilité. Il n'y a qu'une seule session d'application d'ordinateur personnel avec la même identification d'utilisateur. En outre, l'utilisateur fait l'objet d'une fermeture de session automatique dans le

cas o le serveur de mobilité ne reçoit pas une confirma-

tion de la part de l'application d'ordinateur personnel pendant une procédure d'appel entrant. On suppose alors que l'ordinateur personnel est hors fonction. La procédure de fermeture de session est donc exécutée automatiquement lorsque le pilote se termine. Le pilote se termine dès que la dernière application TAPI est fermée. Comme mentionné ci-dessus, la consignation d'appel est la fonction dont la responsabilité incombe à la SBTA ("Screen Based Telephony Application"). Le pilote ne participe pas à la consignation réelle, mais il émet des comptes-rendus de progression vers la SBTA. La fermeture de session est donc accomplie par

l'interface TSPI.

En ce qui concerne la fonctionnalité de numéro per-

sonnel, l'application d'ordinateur personnel est informée

de la situation de l'utilisateur en ce qui concerne un nu-

méro personnel, c'est-à-dire qu'elle sait si le demandeur

et/ou le demandé a un numéro personnel ou non.

En ce qui concerne des actions liées à l'appel, il est avantageusement possible pour un utilisateur d'utiliser

par exemple le téléphone sans fil, ou l'application d'ordi-

nateur personnel, ou les deux, pendant l'accomplissement

d'actions liées à l'appel, ce qui signifie que l'utilisa-

teur peut appuyer sur la touche de prise de ligne sur le téléphone sans fil et ensuite sélectionner un numéro à ap-

peler à partir de l'application d'ordinateur personnel.

Les services d'établissement d'appel, d'appel en-

trant et de déconnexion d'appel (que l'on appelle également

des services d'appel de base) sont interprétés par le pi-

lote et mappés à partir d'opérations TSPI et vers celles-

ci.

La procédure d'appel de base concerne l'établisse-

ment d'un appel sortant et la réception d'appels entrants

ainsi que la déconnexion d'appels.

Un utilisateur peut effectuer un appel en utilisant l'application d'ordinateur personnel. Ensuite, le téléphone

sans fil commence à sonner en premier du côté de l'utilisa-

teur demandeur, et l'utilisateur doit placer le téléphone sans fil en position décrochée avant que l'appel réel ne soit émis vers le demandé, par le serveur de mobilité. Des

appels sortants seront présentés à l'utilisateur, par l'in-

termédiaire de l'application d'ordinateur personnel, avec un nom demandé, si celui-ci est disponible dans l'annuaire

de l'ordinateur personnel, et le numéro demandé. Cette in-

formation est consignée dans la fonction de consignation d'appel, c'està-dire de façon locale dans l'ordinateur personnel. Le serveur de mobilité fournit une information de

progression d'appel étendue si le demandé a un numéro per-

sonnel. Cette information est présentée à l'utilisateur de-

mandeur par l'intermédiaire de l'application d'ordinateur personnel.

L'application d'ordinateur personnel indique un ap-

pel entrant avec le numéro du demandeur et le nom du deman-

* deur s'il existe dans l'annuaire de l'ordinateur personnel local. L'utilisateur doit alors prendre l'appel au moyen du

téléphone sans fil. Du fait qu'une communication UDP/IP en-

tre un serveur de mobilité et une application d'ordinateur personnel, par l'intermédiaire d'un réseau local, est sans connexion, le serveur de mobilité effectue un contrôle pour déterminer si l'application d'ordinateur personnel est ac-

tive ou non, par l'émission de ce que l'on appelle des mes-

sages d'interrogation. Ceci est effectué conjointement à un appel entrant. L'application d'ordinateur personnel doit alors accuser réception du message, et s'il n'y a pas de

compte-rendu au bout d'une durée donnée, le serveur de mo-

bilité rompt la connexion vers les applications d'ordina-

teur personnel et les ressources sont libérées. Ceci est également appelé une fermeture de session forcée. Un appel

entrant est consigné localement dans l'ordinateur person-

nel, même s'il n'aboutit pas.

Un appel peut en outre être déconnecté soit à par-

tir du téléphone sans fil, soit par l'intermédiaire de

l'application d'ordinateur personnel.

Un certain nombre de services supplémentaires sont

en outre avantageusement disponibles. Des services supplé-

mentaires sont avantageusement mis en oeuvre sous la forme

de services CSTA entre le serveur de mobilité et l'applica-

tion de téléphonie basée sur écran. Ces services sont con-

nus en eux-mêmes et par conséquent ils sont simplement ci-

tés ici. Certains d'entre eux concernent la mise en

garde/récupération d'appel, le transfert d'appel, la confé-

rence, le renvoi d'appel, l'achèvement d'établissement

d'appel (rappel, intrusion), la prise d'appel, etc. L'en-

semble entrant de ces services est traduit par le pilote en opérations TSPI, et dans un mode de réalisation particulier celles-ci sont spécifiques au PABX particulier, par exemple

le modèle Ericsson MD 110.

D'autres services sont également avantageusement

disponibles. Par exemple, l'application d'ordinateur per-

sonnel est capable de demander au serveur de mobilité d'émettre des tonalités de numérotation multifréquence (ou DTMF pour "Dual Tone Multi Frequency") pendant un appel,

par exemple vers un serveur de messagerie vocale ou un as-

sistant personnel. En outre, un code d'absence ou une dé-

viation de message peut avantageusement être établi à par-

tir de l'application d'ordinateur personnel. D'autres ser-

vices concernent une désactivation de déviation. L'applica-

tion d'ordinateur personnel est avantageusement capable

d'émettre des codes de compte et des codes d'autorisation.

En outre, une indication/annulation de message en attente est émise vers l'application d'ordinateur personnel, et

cette information est présentée à l'utilisateur par l'in-

termédiaire de l'application d'ordinateur personnel. Une autre fonction concerne une commande de demandeur. Il s'agit d'une fonction qui est activée si l'utilisateur ne peut pas être joint à l'une des positions de réponse qui sont activées dans un numéro personnel. Le demandeur a alors le choix d'agir sur différentes possibilités données,

telles qu'un opérateur, un assistant ou une messagerie vo-

cale. Une autre fonctionnalité qui est avantageusement

fournie par le serveur de mobilité et supportée par celui-

ci, concerne la définition d'un profil personnel pour l'utilisateur. Cependant, comme mentionné ci-dessus, cette

fonctionnalité ne dépend pas, en elle-même, de la conver-

sion de protocole elle-même. Si l'application TAPI supporte la gestion du profil personnel, les services suivants, par exemple, sont émis par l'intermédiaire du pilote vers la

partie de profil dans l'application TAPI: activa-

tion/désactivation de profils, validation/invalidation du

filtrage d'appels, fixation du temps de sonnerie, change-

ment de mot de passe pour le numéro personnel et la désac-

tivation du filtrage d'appel, type d'invite vocale. Si l'utilisateur est un abonné ayant un numéro personnel, le

pilote recevra à partir du serveur de mobilité des comptes-

rendus de progression pour des appels entrants. Le pilote communique avec la partie de gestion de profil dans la SBTA par l'intermédiaire de l'interface TAPI, en utilisant les services étendus. En particulier, tout le trafic concernant les profils passe par ici. La fonctionnalité de gestion de profil est en partie dans l'application et en partie dans le fournisseur de service. Le fournisseur de service prend en charge l'ouverture et la fermeture de session, tandis

que le reste réside dans l'application.

On va cependant envisager de façon plus détaillée

la gestion d'un profil personnel, en se référant à la fi-

gure 9.

En se référant à la figure 6, on va décrire la con-

nexion d'un appel qui est effectué par un abonné A ayant un

téléphone sans fil PP-A 1A, vers un autre abonné B utili-

sant un téléphone sans fil PP-B lB, en utilisant un ordina-

teur personnel. La figure 7 illustre un organigramme sim-

plifié concernant la connexion d'un appel d'un abonné A

vers un abonné B. De façon correspondante, la figure 8 mon-

tre un organigramme simplifié concernant la réception d'un appel. Sur la figure 6, un ordinateur personnel PC A 20C est connecté par l'intermédiaire d'un réseau local 6 à un serveur de mobilité 30C. Dans ce mode de réalisation, le serveur de mobilité (ou MOBSX) 30C comprend des moyens de

commutation 33C, ce qui signifie que la connexion est ac-

complie dans le serveur de mobilité. Selon une variante,

comme on l'a également envisagé ci-dessus, la fonctionnali-

té de commutation peut être fournie extérieurement au ser-

veur de mobilité. Comme envisagé par exemple en relation

avec la figure 3, le serveur de mobilité (ou MOBS) 30 com-

prend également un logiciel de commande par un tiers 31C et un pilote de réseau local 32C. L'ordinateur personnel 20C comprend une application de téléphonie basée sur écran, SBTA, 23C, un logiciel de commande par un participant 21C,

un convertisseur 24C (voir la figure 4 ou le pilote de ser-

veur de mobilité de la figure 5) et un pilote de réseau lo-

cal 22C. Le serveur de mobilité 30C est connecté à un com-

mutateur de radiocommunication 5 qui est connecté à des stations de base BS1 et BS2. Les téléphones PP-A et PP-B sont des téléphones sans fil 1A, lB, respectivement d'un premier utilisateur A et d'un second utilisateur B. La SBTA 23C est l'application de logiciel que l'utilisateur A uti- lise pour commander le téléphone sans fil 1A. En utilisant

la SBTA, il est possible de connecter des appels sans ap-

puyer sur des touches sur le terminal sans fil 1A. Au moyen de l'application, il est également possible de consigner

des appels entrants, etc., comme envisagé ci-dessus. Le lo-

giciel de commande par un participant 21C commande le télé-

phone sans fil pour lequel l'ordinateur personnel PC A 20C

est spécialisé. Ce logiciel est également utilisé pour con-

server dans des moyens d'enregistrement (non représentés) toute l'information concernant des appels de l'abonné A. On peut par exemple enregistrer l'information concernant des appels reçus, des appels connectés, des tentatives d'appel, etc. Les moyens de conversion 24C comprennent le logiciel pour la communication avec le logiciel de commande par un tiers 31C dans le serveur de mobilité 30C. Le logiciel de

commande par un tiers 31C commande, entre autres, la con-

nexion d'appel à partir d'un téléphone sans fil, lorsque la SBTA est utilisée. Ce logiciel est également utilisé pour la détection d'appels entrants dirigés vers l'abonné A, et il est donc connecté aux moyens de commutation 33C dans le serveur de mobilité 30C. Cependant, si la fonctionnalité de commutation n'est pas incluse dans le serveur de mobilité, le logiciel de commande par un tiers 31C est connecté aux moyens de commutation qui sont disposés à l'extérieur du

serveur de mobilité.

Le fonctionnement a été décrit de façon plus appro-

fondie en relation avec les figures 4 et 5.

On expliquera schématiquement avec l'organigramme de la figure 7 un appel provenant de l'abonné A et dirigé vers l'abonné B. On suppose que l'abonné A effectue tout

d'abord une ouverture de session sur son ordinateur person-

nel. Ceci est avantageusement effectué en indiquant à l'or- dinateur personnel qu'il doit être spécialisé pour un télé-

phone sans fil particulier. Dans un mode de réalisation avantageux, ceci peut être effectué automatiquement si l'utilisateur utilise toujours un ordinateur personnel par-

ticulier (l'ordinateur personnel appartenant à l'utilisa-

teur) pour la spécialisation pour le téléphone sans fil PB-

A. Le numéro du téléphone PB-A', ou de l'abonné A' pour un téléphone sans fil, est ensuite enregistré dans des moyens de mémoire de l'ordinateur personnel qui sont connectés au

logiciel de commande par un tiers. Ainsi, en 111, l'ordina-

teur personnel PC-A est spécialisé pour le téléphone PP-A

et le numéro est enregistré dans les moyens d'enregistre-

ment qui sont connectés au logiciel de commande par un

tiers.

Le logiciel de commande par un tiers 31C dans le

serveur de mobilité 30C reçoit, par l'intermédiaire du lo-

giciel de commande par un participant 21C, une information indiquant que l'ordinateur personnel PC-A est connecté au

téléphone sans fil PP-A, en 112. Une information est four-

nie par l'intermédiaire de l'application de téléphonie ba-

sée sur écran, 23C, pour indiquer qu'un appel doit être connecté au téléphone PP-B de l'abonné B, en 113. Dans les moyens de conversion 24C, l'opération de commande par un participant est convertie en une opération de commande par un tiers, comme décrit en relation avec la figure 4, et le

logiciel de commande par un tiers 31C reçoit ainsi une in-

formation indiquant qu'un appel doit être établi à partir du téléphone sans fil 1A de l'abonné A, vers le téléphone

sans fil lB de l'utilisateur B, en 114.

Ensuite, les opérations de commande par un tiers

sont interprétées dans le serveur de mobilité 30C, en 115.

En utilisant la fonctionnalité de commutation 33C, le logi-

ciel de commande par un tiers 31C commande la connexion de l'appel de l'abonné A vers l'abonné B ou le téléphone sans

fil lB, en 116.

Comme mentionné dans ce qui précède, la déconnexion d'un appel peut être effectuée soit par l'intermédiaire de l'application de téléphonie basée sur écran, soit par l'opération qui consiste à décrocher sur le terminal sans fil. Une information concernant l'appel déconnecté est en-

registrée dans des moyens d'enregistrement qui sont connec-

tés au logiciel de commande par un tiers.

La figure 8 montre très schématiquement la séquence

lorsqu'un appel arrive à l'abonné A. Un appel entrant diri-

gé vers l'abonné A est détecté dans le logiciel de commande par un tiers 31C, en 210. Ensuite, le logiciel de commande par un tiers 31C effectue un examen pour déterminer si un

ordinateur personnel comportant une application de télépho-

nie basée sur écran est spécialisé pour l'abonné A, en 211.

S'il n'y a pas un tel ordinateur personnel avec une SBTA spécialisée pour le téléphone PP-A, la connexion d'appel se

déroule en 211A, d'une manière classique, que l'on ne dé-

crira pas davantage ici.

Cependant, s'il est établi qu'un ordinateur person-

nel (ici l'ordinateur PC-A) avec une SBTA est spécialisé pour le téléphone PP-A, en 211, le logiciel de commande par un tiers 31C indique aux moyens de conversion 24C dans

l'ordinateur personnel PC-A, par l'intermédiaire d'une opé-

ration de commande par un tiers sur une interface de com-

mande par un tiers, qu'il y a un appel dirigé vers le télé-

phone PP-A, en 213. Dans le convertisseur 24C, une opéra-

tion de commande par un tiers est convertie en une opéra-

tion de commande par un participant, en 214. L'existence

d'un appel dirigé vers le téléphone PP-A est ensuite signa-

lée au logiciel de commande par un participant 21C, en 215.

L'appel est ensuite connecté, en 216.

Comme mentionné ci-dessus, dans un mode de réalisa-

tion, un serveur de mobilité peut supporter un certain nom-

bre de fonctions, concernant un "profil personnel" pour un utilisateur. Si la SBTA supporte de tels services, ils sont émis ici par l'intermédiaire du pilote vers une partie de profil dans l'application de commande par un participant SBTA. Le renvoi d'appel est une fonctionnalité de ce

type. Dans un mode de réalisation avantageux, un utilisa-

teur avec un numéro personnel choisit un profil qui doit

être activé, parmi un certain nombre de profils prédéfinis.

Des exemples de ceux-ci comprennent un profil "au bureau", un profil "hors du bureau", un profil de numéro temporaire et un profil d'abonné absent. Un seul de ces profils est actif à un moment donné. Les profils "au bureau" et "hors du bureau", respectivement, sont des profils "statiques" et

prédéfinis qui existent dans le serveur de mobilité. Le nu-

méro temporaire offre à l'utilisateur la possibilité d'af-

fecter un numéro de "renvoi d'appel" temporaire. Un autre

service concerne l'activation/désactivation de téléphones.

Cette fonction permet à un utilisateur d'accomplir cette action sur le jeu de téléphones qui sont disponibles dans

le profil choisi (au bureau, hors du bureau).

Une autre fonction est la fonction de filtrage d'appels. On peut l'utiliser conjointement à la fonction de renvoi d'appels, ce qui signifie que n'importe quel profil

de renvoi d'appels peut être actif en même temps que n'im-

porte quels profils de filtrage, tels que tous les appels (autorisés), des appels sélectionnés (autorisés) et aucun appel (autorisé). Si le profil d'appels sélectionnés est sélectionné, alors une liste de téléphones sélectionnés est activée. La liste peut être définie au moyen de la fonction "spécification d'appels sélectionnés", qui comprend les possibilités de changement de type d'appel (tous les appels

internes, tous les appels externes ou une liste sélection-

née), ou une fonction d'édition de liste de sélection. Il

est possible d'exercer une action prioritaire sur la fonc-

tion de filtrage d'appels, au moyen d'un mot de passe; le profil de renvoi d'appels actif sera alors appliqué. Par la fonction "changement du mot de passe affecté à un numéro personnel", l'utilisateur peut changer le mot de passe qui

est affecté à un numéro personnel. Par une autre fonction-

nalité, il est possible de changer les invites vocales de

guidage de la gestion de numéro personnel, de façon qu'el-

les soient longues ou courtes. On peut donc acti-

ver/désactiver, valider ou invalider divers profils et fonctions. Tous les événements concernant l'utilisateur sont signalés à l'application de téléphonie basée sur écran,

ceux-ci désignant les événements qui concernent des activi-

tés liées à des appels, et des changements concernant un numéro personnel. Conformément à un mode de réalisation avantageux, un certain nombre de fonctions sont mises en

oeuvre à la fois dans le serveur de mobilité et dans l'ap-

plication de téléphonie basée sur écran. Des exemples de ces fonctions comprennent l'activation/désactivation du profil de renvoi courant, qui est accomplie par le choix d'un profil dans une liste de profils prédéfinis. Une autre

fonction concerne la validation/invalidation de la fonc-

tionnalité de filtrage d'appels. Ceci est accompli par le

choix d'un profil de filtrage. En outre, la durée de sonne-

rie pour différents téléphones répondeurs peut être fixée individuellement. Un jeu de profils désirés peut donc être fixé de façon à être actif dans le serveur de mobilité, ces

profils comprenant par exemple le renvoi d'appels, le fil-

trage d'appels et la commande par le demandeur.

En outre, il existe une fonction concernant un changement dans le mot de passe qui est associé au numéro personnel/identificateur d'utilisateur. Des utilisateurs qui n'ont pas un numéro personnel reçoivent le mot de passe

qui est associé à leur numéro de téléphone sans fil.

Le mot de passe peut être changé de façon à mettre hors service la fonctionnalité de filtrage d'appels, et à changer le type d'invite vocale pour le faire passer de

"long" à "court", ou inversement.

Dans un mode de réalisation avantageux, en fonction de ce que supporte l'application de téléphonie basée sur

écran, les fonctions suivantes sont mises en oeuvre de fa-

çon locale dans la SBTA; création, entretien et suppression

de profils de renvoi d'appels, création, entretien et sup-

pression de profils de filtrage d'appels sélectionnés, et création, entretien et suppression de multiples profils de

commande par le demandeur.

Le profil d'utilisateur peut être personnalisé

d'une manière aisée et on montre une application de télé-

phonie basée sur écran qui est adaptable au profil person-

nel de l'utilisateur, ce qui signifie que seuls les servi-

ces qu'un utilisateur désire avoir sont incorporés dans son

propre "téléphone personnel".

La figure 9 illustre la mise en oeuvre des fonc-

tions d'un serveur de mobilité 30. Le serveur de mobilité comprend un certain nombre de modules de fonctions, parmi lesquels des modules de fonctions concernant une fonction A,... une fonction F sont illustrés. Sur la figure, le profil de l'utilisateur X, 35A, et celui de l'utilisateur

Y, 35B, sont illustrés. Par l'intermédiaire de l'applica-

tion de téléphonie basée sur écran, l'utilisateur peut sé-

lectionner des fonctions. Avec une application de télépho-

nie basée sur écran qui supporte une telle fonctionnalité, un utilisateur peut par exemple obtenir une automatisation

pour de nouvelles fonctions dans le serveur de mobilité 30.

Les services dépendent ainsi de l'autorisation. Si

un service est autorisé, il est activé et il est automati-

quement téléchargé du serveur de mobilité vers l'applica-

tion.

Il doit être clair que l'invention n'est pas limi-

tée aux modes de réalisation illustrés, mais peut être mo-

difiée de nombreuses manières. En particulier, l'invention n'est pas limitée à la gestion de profil de service; ceci concerne simplement un mode de réalisation particulièrement avantageux.

En outre, l'invention n'est pas limitée à l'utili-

sation de commutateurs ou de PABX particuliers, d'interfa-

ces ou de protocoles particuliers, etc., et on peut utili-

ser n'importe quels protocoles appropriés, ainsi que n'im- porte quel ordinateur personnel approprié, par exemple un Macintosh (marque déposée), et n'importe quelle application5 appropriée de téléphonie basée sur écran.

Claims (28)

REVENDICATIONS

1. Système pour commander des unités d'abonné de

télécommunication (1, 1'; 1A, lB) par l'intermédiaire d'or-

dinateurs personnels, ce système comprenant un certain nom-

bre d'ordinateurs personnels (2; 2A, 2B; 20; 20A; 20B,

C), un certain nombre d'unités d'abonné de télécommunica-

tion (1, 1'; 1A, 1B) et au moins un dispositif de commuta-

tion (3, 4; 30A; 30; 30B; 30C; 30') comprenant une fonction

de commutation, caractérisé en ce que le dispositif de com-

mutation comprend en outre un serveur de mobilité (3; 30A; ; 30B; 30C; 30') comprenant des moyens de commande par un tiers (31; 31C) auxquels un certain nombre d'ordinateurs personnels (2; 2A, 2B; 20A; 20B; 20C) sont connectés par l'intermédiaire d'un réseau local (6; 6B), les ordinateurs personnels communiquant avec le serveur de mobilité (3; A; 30; 30B; 30C; 30') par l'intermédiaire d'une interface de commande par un tiers, chaque ordinateur personnel (2; 2A; 2B; 20A; 20B, 20C) comprenant une application pour des services de téléphonie basée sur écran (23; 23A; 23C), cette application utilisant une interface de commande par un participant pour la communication avec l'utilisateur, et en ce que chaque ordinateur personnel (2; 2A; 2B; 20; 20A; B; 20C) comprend des moyens de conversion (24; 24A; 24C) pour effectuer une conversion entre l'interface de commande par un participant et l'interface de commande par un tiers, de façon qu'un utilisateur puisse utiliser des applications basées sur la commande par un participant, conjointement à

des moyens de commande par un tiers (31; 31C) dans le ser-

veur de mobilité (3; 30A; 30; 30B; 30C; 30').

2. Système selon la revendication 1, caractérisé en ce que les interfaces de commande par un participant et par

un tiers sont des interfaces standard.

3. Système selon la revendication 1 ou 2, caracté-

risé en ce que des moyens de commande par un tiers (31; 31C) comprenant un logiciel pour un certain nombre d'unités

de télécommunication d'abonné sont incorporés dans le ser-

veur de mobilité (3; 30A; 30; 30B; 30C), et en ce que des

moyens de commande par un participant (21; 21C) sont incor-

porés dans chaque ordinateur personnel respectif.

4. Système selon l'une quelconque des revendica-

tions précédentes, caractérisé en ce que le réseau local

(6;6B) est par exemple le réseau local Ethernet.

5. Système selon l'une quelconque des revendica-

tions précédentes, caractérisé par l'utilisation d'un pro-

tocole CSTA pour la communication entre le serveur de mobi-

lité (3; 30A; 30; 30B; 30C; 30') et un ordinateur personnel

(2; 2A; 2B; 20; 20A; 20B, 20C).

6. Système selon l'une quelconque des revendica-

tions précédentes, caractérisé en ce que l'interface de commande d'appel par un participant est une interface TAPI

("Telephony Application Programming Interface").

7. Système selon l'une quelconque des revendica-

tions précédentes, caractérisé en ce que n'importe quelle application basée sur la commande par un participant et n'importe quelle application basée sur la commande par un tiers, dirigées vers le commutateur (4) par l'intermédiaire du serveur de mobilité (3; 30A; 30; 30B; 30C; 30'), peuvent

être commandées à partir de n'importe lequel des ordina-

teurs personnels et pour n'importe quelle unité d'abonné de télécommunication.

8. Système selon l'une quelconque des revendica-

tions précédentes, caractérisé en ce que la fonctionnalité

de commutation est incorporée dans un commutateur (4) au-

quel le serveur de mobilité (3) est connecté.

9. Système selon la revendication 8, caractérisé en ce que le commutateur (4) est un autocommutateur privé, ou

PABX, qui est connecté à une station de base de radiocommu-

nication, comme par exemple une station DECT, par exemple par l'intermédiaire d'un commutateur de radiocommunication (5).

10. Système selon l'une quelconque des revendica-

tions 1 à 7, caractérisé en ce que le dispositif de commu-

tation comprend un serveur de mobilité (30A; 30C) avec une

fonctionnalité de commutation.

11. Système selon la revendication 10, caractérisé en ce que le dispositif de commutation, c'est-à-dire le serveur de mobilité étendue (30A; 30C) avec une fonctionna- lité de commutation, comprend un autocommutateur privé, ou PABX.

12. Système selon l'une quelconque des revendica-

tions précédentes, caractérisé en ce que le serveur de mo-

bilité (30') comprend un certain nombre de fonctions de

service qui sont mises en oeuvre dans des modules.

13. Système selon la revendication 12, caractérisé

en ce que les fonctions de service désirées qui sont four-

nies dans le serveur de mobilité (30') peuvent être défi-

nies/sélectionnées par l'utilisateur par l'intermédiaire

d'un ordinateur personnel, pour définir un profil de ser-

vice spécifique d'un utilisateur.

14. Système selon l'une quelconque des revendica-

tions précédentes, caractérisé en ce que les unités d'abon-

né de télécommunication (1; lA, lB) comprennent des télé-

phones sans fil.

15. Système selon l'une quelconque des revendica-

tions précédentes, caractérisé en ce qu'à partir de n'im-

porte quel ordinateur personnel du système, un utilisateur

peut diriger des appels entrants et sortants pour des télé-

phones sans fil, fixes ainsi que cellulaires, qui sont con-

nectés au dispositif de commutation.

16. Système selon la revendication 15, caractérisé en ce qu'un utilisateur peut définir un profil de service à

partir de n'importe quel ordinateur personnel du système.

17. Système selon l'une quelconque des revendica-

tions précédentes, caractérisé en ce que les moyens de con-

version (24; 24A; 24C) comprennent un dispositif pour tra-

duire des opérations d'interface de commande d'appel par un participant en opérations d'interface de commande d'appel

par un tiers, et inversement, des moyens de codage pour co-

der sous forme de paquets des opérations de commande d'ap-

pel par un tiers, et pour décoder les paquets en opérations de commande d'appel par un tiers, et un émetteur/récepteur

pour émettre/recevoir des paquets sur la connexion par ré-

seau local (6).

18. Système selon la revendication 17, caractérisé

en ce que l'interface de commande d'appel par un partici-

pant est une interface TAPI avec une interface de fournis-

seur de service de téléphonie de bas niveau (TSPI), et en ce que des ordres de TSPI sont traduits en opérations CSTA,

le dispositif de traduction collectant des appels de fonc-

tion provenant de l'interface TSPI, et en ce que ces appels

sont mappés vers des opérations CSTA.

19. Système selon la revendication 18, caractérisé

en ce que dans le dispositif de codage/décodage, les opéra-

tions CSTA sont codées par un algorithme de codage en pa-

quets BER, et inversement, et en ce que la communication avec le serveur de mobilité par l'émission des paquets est réalisée par l'intermédiaire de l'émetteur qui assemble des

paquets BER en paquets UDP (TCP), et inversement.

20. Système selon l'une quelconque des revendica-

tions 17 à 19, caractérisé en ce que les moyens pilotes ou de conversion, comprenant des moyens de traduction, des moyens de codage/décodage et des moyens d'émission, sont responsables de l'ouverture de session/fermeture de session

dans les services de numéro personnel, tandis que l'appli-

cation TAPI est responsable des services restants.

21. Procédé pour connecter un appel à une unité de télécommunication (lB) connectée à un commutateur

(directement ou par l'intermédiaire d'un autre commuta-

teur), en utilisant un ordinateur personnel (20C) qui com-

prend une application de téléphonie basée sur écran, pour commander un certain nombre d'unités de télécommunication,

caractérisé en ce que ce procédé comprend les étapes sui-

vantes: - on spécialise l'ordinateur personnel (20C) pour l'unité de télécommunication à partir de laquelle un appel doit être effectué, les identifications pour un certain nombre d'unités de télécommunication étant enregistrées

dans des moyens d'enregistrement, par exemple dans l'ordi-

nateur personnel (20C), ces moyens d'enregistrement étant connectés à des moyens de commande par un tiers (31C) dans le serveur de mobilité (30C); on signale à des moyens de commande par un tiers

(31C) dans le serveur de mobilité (30C) connecté à un com-

mutateur, ou comprenant lui-même une possibilité de commu-

tation, que l'ordinateur personnel (20C) est spécialisé pour une unité de télécommunication donnée (lA); - on indique à l'application de téléphonie basée sur écran (23C) dans l'ordinateur personnel (20C) l'unité

de télécommunication de destination (lB) à laquelle un ap-

pel doit être connecté; - on convertit cette information de destination concernant une interface de commande par un participant (TAPI) en opérations d'interface de commande par un tiers

(CSTA), dans des moyens de conversion (24C) dans l'ordina-

teur personnel (20C); - on émet l'information convertie vers les moyens de commande par un tiers (31C); - on interprète ces opérations dans les moyens de commande par un tiers (31C) dans le serveur de mobilité (30C); et

- en utilisant ces opérations, on commande la con-

nexion à partir de l'unité de télécommunication appelante (1A) vers l'unité de télécommunication appelée (lB), par

l'intermédiaire de la fonction de commutation (33C).

22. Procédé selon la revendication 21, caractérisé en ce que l'étape de conversion d'information comprend les étapes suivantes: - on traduit des ordres d'interface de commande par un participant en opérations d'interface de commande par un tiers; - on code en paquets les opérations de commande par un tiers; et en ce que l'étape d'émission d'information comprend les étapes suivantes: - on réarrange les paquets en un format approprié pour l'émission, par exemple le format UDP ou TCP; - on émet les paquets réarrangés sur une connexion de réseau local, vers les moyens de commande par un tiers

(31C) dans le serveur de mobilité (30C).

23. Procédé selon la revendication 21 ou 22, carac-

térisé en ce que pour la déconnexion d'un appel, il com-

prend l'étape qui consiste à faire passer à l'état décroché

l'unité de télécommunication appelante (1A).

24. Procédé selon la revendication 21, caractérisé en ce que pour la déconnexion d'une connexion, il comprend les étapes suivantes: - on fournit à l'application de téléphonie basée sur écran (23C) l'information indiquant qu'une connexion doit être déconnectée;

- on transfère cette information provenant de l'ap-

plication de téléphonie basée sur écran (23C) aux moyens de

commande par un participant (21C) dans l'ordinateur person-

nel (20C);

- on convertit l'ordre de commande par un partici-

pant en une opération de commande par un tiers dans les moyens de conversion (24C); - on déconnecte la connexion par l'intermédiaire

des moyens de commande par un tiers (31C).

25. Procédé pour connecter un appel entrant à au moins une première unité d'abonné de télécommunication (1A), à partir d'une seconde unité de télécommunication (1B), telle qu'un téléphone sans fil, un téléphone mobile cellulaire ou un téléphone fixe connecté à un commutateur

qui est connecté à un serveur de mobilité (30C) ou qui com-

prend un tel serveur, caractérisé en ce qu'il comprend les étapes suivantes: - on détecte dans des moyens de commande par un

tiers (31C) dans le serveur de mobilité (30C), un appel en-

trant dirigé vers la première unité de télécommunication (1A); - on effectue un examen, par l'intermédiaire des moyens de commande par un tiers (31C), pour déterminer si pour la première unité de télécommunication (lA),, il existe un ordinateur personnel (20C) coopérant avec cette unité, qui contient des moyens de commande par un participant

(21C);

- si oui, on émet vers des moyens de conversion (24C) dans l'ordinateur personnel, à partir des moyens de

commande par un tiers (31C), par l'intermédiaire d'une in-

terface de commande par un tiers, une information concer-

nant un appel dirigé vers la première unité de télécommuni-

cation (1A), à partir de la seconde unité de télécommunica-

tion (lB); - on convertit, dans les moyens de conversion

(24C), l'opération de commande par un tiers en une opéra-

tion de commande par un participant; - on informe l'application de téléphonie basée sur écran (23C), au sujet de l'appel dirigé vers la première unité de télécommunication (1A);

- on connecte l'appel.

26. Procédé selon la revendication 25, caractérisé en ce que la première unité de télécommunications (1A) est

un téléphone sans fil.

27. Procédé pour gérer et commander des unités de télécommunication, telles qu'un ou plusieurs téléphones parmi un téléphone sans fil, un téléphone cellulaire et un

téléphone fixe, par l'intermédiaire d'un ordinateur person-

nel (2; 2A, 2B; 20; 20A; 20B, 20C) comprenant une applica-

tion de téléphonie basée sur écran (23; 23A; 23C), et des

moyens pour la commande par un participant (21; 21C), ca-

ractérisé en ce qu'il comprend les étapes suivantes: on connecte l'ordinateur personnel (2; 2A, 2B; 20; 20A; 20B, C), par l'intermédiaire d'un réseau local (6; 6B), à un serveur de mobilité (3; 30A; 30; 30B, 30C; 30') comprenant une fonctionnalité de commutation, ou qui est connecté à un

commutateur ou un dispositif similaire ayant une fonction-

nalité de commutation, le serveur de mobilité comprenant des moyens pour la commande par un tiers (31; 31C);

- on effectue une conversion dans l'ordinateur per-

sonnel (2; 2A, 2B; 20; 20A; 20B, 20C) entre des opérations

de commande par un participant sur une interface de com-

mande par un participant, et des opérations de commande par

un tiers sur une interface de commande par un tiers, de fa-

çon qu'un utilisateur puisse utiliser l'application basée

sur la commande par un participant (23; 23A; 23C), conjoin-

tement à des moyens de commande par un tiers (31; 31C) dans

le serveur de mobilité (3; 30A; 30; 30B; 30C; 30').

28. Procédé selon la revendication 27, dans lequel le serveur de mobilité (30') comprend un certain nombre de modules comprenant des fonctions de services, caractérisé en ce qu'il comprend en outre l'étape suivante: on définit un profil de service personnel dans le serveur de mobilité

(30') pour un utilisateur, en autorisant les fonctions dé-

sirées à partir de la partie d'application de téléphonie

basée sur écran dans l'ordinateur personnel.