Brevet FR2968875A1 — publié le 20120615

Procédé et dispositifs pour informer un usager qu'il est le destinataire d'un renvoi téléphonique L'invention concerne un procédé pour informer un usager qu'il est le destinataire d'un renvoi téléphonique, et des dispositifs de communication permettant d'informer un usager qu'il est le destinataire d'un renvoi téléphonique. Un réseau de télécommunication d'entreprise offre généralement à ses usagers la possibilité de renvoyer les appels destinés initialement à un poste téléphonique vers un autre poste, soit immédiatement, soit après un certain délai en cas de non réponse. Cette fonction de renvoi est activée en programmant l'autocommutateur qui établit les communications. Cette programmation est réalisée par l'usager qui souhaite renvoyer les appels qui devraient arriver sur son poste, en utilisant le clavier de son poste téléphonique, notamment pour indiquer le numéro du poste vers lequel le renvoi doit être fait. Pour annuler le renvoi, l'usager utilise aussi le clavier de son poste, ou son ordinateur personnel. L'usager qui programme le renvoi est informé de l'activation du renvoi par une indication sonore ou/et par une indication visuelle (Voyant ou afficheur) sur son poste téléphonique ou son ordinateur personnel. Par contre, l'usager du poste vers lequel les appels vont être renvoyés ne reçoit aucune indication fournie par le réseau de télécommunication au moment de la programmation du renvoi. Certains autocommutateurs fournissent une indication de renvoi, mais c'est seulement au moment où le poste sonne parce qu'un appel est renvoyé sur lui. Cette indication est souvent trop tardive. L'usager du poste destinataire du renvoi regrette souvent de ne pas avoir été prévenu avant qu'un premier appel soit effectivement renvoyé sur son poste, pour diverses raisons : - Cet usager peut avoir activé un renvoi vers un troisième poste, alors que ce second renvoi n'est pas compatible avec le premier renvoi pour des raisons d'organisation de l'entreprise. - Cet usager peut être dans l'impossibilité de répondre réellement à un appel, par exemple parce qu'il est occupé par une réunion importante. - Cet usager aurait souhaité demandé au premier usager si un appel important était à prévoir. - Cet usager aurait pu détecter que le renvoi vers son poste était du à une erreur sur le numéro de destination du renvoi. Une première solution connue consiste en ce que le premier usager prévienne personnellement le second usager au moyen d'un coup de téléphone ou d'un courriel. Mais le premier usager risque d'oublier de faire cette démarche, ou il risque d'échouer à joindre le second usager au moment où il veut programmer le renvoi. Une seconde solution connue consiste à utiliser un serveur de présence dans le réseau de télécommunication de l'entreprise. Tout usager du réseau, ayant le statut d'observateur de l'état de présence d'un usager, peut constater (sur son ordinateur personnel) que cet usager a renvoyé les appels qui lui sont destinés vers le poste d'un autre usager explicitement indiqué par ce serveur de présence. Mais les usagers du réseau n'ont pas tous droit à ce statut d'observateur de l'état de présence d'un usager donné. L'usager du poste destinataire du renvoi n'a pas forcément ce droit. En outre, cet usager n'est pas forcément présent au moment où le renvoi est activé, il ne peut donc pas forcément constater le changement d'état de présence de l'usager qui a demandé le renvoi. Le but de l'invention est de remédier à ces inconvénients. Un premier objet de l'invention est un procédé pour informer un premier usager qu'il est le destinataire d'un renvoi des appels téléphoniques destinés initialement à un second usager, caractérisé en ce qu'il comporte les étapes consistant à : - envoyer une demande de service d'un terminal du premier usager à un serveur d'applications téléphoniques permettant notamment d'informer le premier usager qu'il est le destinataire d'un renvoi des appels téléphoniques destinés initialement à un second usager, - puis, lorsqu'est créé un renvoi des appels destinés initialement au second usager vers ce terminal du premier usager : -- envoyer à ce serveur d'applications téléphoniques un message de publication de renvoi, contenant l'identité du premier usager, l'identité du second usager, et un indicateur indiquant la création d'un renvoi, -- puis envoyer une notification de renvoi, de ce serveur d'applications téléphoniques au terminal du premier usager, cette notification contenant l'identité du second usager, et un indicateur indiquant la création d'un renvoi. Grâce à cette notification de renvoi, le terminal du premier usager peut informer ce premier usager de l'existence d'un renvoi, en affichant un indicateur indiquant la création d'un renvoi, et en affichant l'identité du second usager. Selon un mode de mise en oeuvre, particulier, ce procédé consiste en outre à : - inclure dans te message de publication une indication sur le type de 10 renvoi, - puis inclure cette indication dans la notification de renvoi, - et afficher le type de renvoi sur le terminal du premier usager. Selon un mode de mise en oeuvre particulier, ce procédé consiste en outre à : 15 - inclure dans le message de publication un texte apte à être affiché sur te terminal du premier usager, - puis inclure ce texte dans la notification de renvoi, - et à afficher ce texte sur le terminal du premier usager. Un deuxième objet de l'invention est un terminal de communication 20 permettant d'informer un usager de ce terminal qu'il est le destinataire des appels téléphoniques destinés initialement à un second usager, caractérisé en ce qu'il comporte : - des moyens pour recevoir une notification de renvoi envoyée par un serveur d'applications téléphoniques, 25 - et des moyens pour afficher une indication de renvoi et l'identité du second usager, contenues dans la notification reçue. Un mode de réalisation particulier, permettant en outre d'informer l'usager d'un autre terminal que les appels destinés initialement au premier terminal sont renvoyés vers cet autre terminal, comporte en outre des moyens pour 30 envoyer un message de publication de renvoi à un serveur d'applications téléphoniques permettant d'informer ce serveur que tes appels téléphoniques destinés initialement au premier terminal sont renvoyés vers cet autre terminal. Selon un mode de réalisation particulier, ce terminal comporte en outre des moyens pour afficher une indication de type de renvoi, contenue dans la 35 notification reçue. Selon un mode de réalisation particulier, ce terminal comporte en outre des moyens pour afficher un texte contenu dans la notification reçue. Selon un mode de réalisation particulier, ce terminal comporte en outre des moyens pour afficher un texte contenu dans la notification reçue. Selon un mode de réalisation particulier, les moyens pour envoyer un message de publication comportent des moyens pour insérer dans ce message de publication : un indicateur indiquant la création d'un renvoi, l'identité d'un usager de ce terminal, qui est le destinataire initial des appels, et l'identité d'un second usager qui est le destinataire des appels renvoyés. Un troisième objet de l'invention est un serveur d'applications téléphoniques permettant d'informer un usager qu'il est le destinataire d'un renvoi téléphonique, caractérisé en ce qu'il comporte : - des moyens pour recevoir une demande de service émise par un terminal d'un premier usager, et indiquant que ce premier usager souhaite être informé qu'il est le destinataire d'un renvoi téléphonique, - des moyens pour recevoir un message de publication de renvoi, provenant d'un terminal d'un second usager, et contenant : un indicateur indiquant la création d'un renvoi, l'identité du destinataire initial des appels, qui est le second usager, et l'identité du destinataire des appels renvoyés, qui est le premier usager ; - et des moyens pour envoyer ensuite une notification au terminal du premier usager, cette notification contenant un indicateur indiquant la création d'un renvoi, l'identité du destinataire initial des appels, qui est le second usager, et l'identité du destinataire des appels renvoyés, qui est le premier. Selon un mode de réalisation particulier, les moyens pour recevoir un message de publication de renvoi comportent des moyens pour recevoir un indicateur de type de renvoi, contenu dans ce message ; et dans lequel les moyens pour envoyer une notification au terminal du premier usager comportent en outre des moyens pour inclure un indicateur de type de renvoi dans cette notification. Selon un mode de réalisation particulier, les moyens pour recevoir un message de publication de renvoi comportent des moyens pour recevoir en outre un texte contenu dans ce message ; et dans lequel les moyens pour envoyer une notification à un terminal du premier usager comportent en outre des moyens pour inclure ce texte dans cette notification. Selon un mode de réalisation particulier, les moyens pour recevoir un message de publication de renvoi, et les moyens pour envoyer une notification, comportent une interface web. Selon un mode de réalisation particulier, lequel les moyens pour recevoir un message de publication de renvoi et les moyens pour envoyer une notification comportent une interface conforme au protocole SIP. Un quatrième objet de l'invention est un serveur d'applications caractérisé en ce qu'il comporte des moyens pour détecter l'absence d'un usager à proximité d'un terminal de cet usager, et envoyer alors, à un serveur d'applications téléphoniques, un message de publication de renvoi contenant : un indicateur commandant la création d'un renvoi, l'identité du destinataire initial des appels, qui est cet usager absent, et l'identité du destinataire des appels renvoyés, qui est un autre usager. Selon un mode de réalisation particulier, lesdits moyens pour envoyer un message de publication de renvoi comportent des moyens pour inclure dans ce message un texte destiné à être communiqué à l'autre usager qui est destinataire des appels renvoyés. L'invention sera mieux comprise et d'autres caractéristiques apparaîtront à l'aide de la description ci-dessous et des figures l'accompagnant : - La figure 1 illustre le fonctionnement d'un premier exemple de mise en oeuvre du procédé selon l'invention, comportant un serveur de communication et des terminaux utilisant, comme protocole de signalisation, le protocole d'initialisation de session, SIP. - La figure 2 illustre le fonctionnement d'un deuxième exemple de mise en oeuvre du procédé selon l'invention, comportant un serveur d'applications téléphoniques muni d'une interface web, ce serveur étant couplé à un autocommutateur classique de réseau d'entreprise. - La figure 3 illustre le fonctionnement d'un troisième exemple de mise en oeuvre du procédé selon l'invention, comportant en outre une application exécutée sur un ordinateur personnel, pour chaque utilisateur. Dans l'exemple illustré sur la figure 1, un réseau d'entreprise comporte un serveur de communication CS et des terminaux téléphoniques TA, TB, etc, utilisant le protocole Internet et le protocole d'initialisation de session, SIP. Dans cet exemple, le procédé selon l'invention est implémenté en utilisant les fonctions du protocole SIP : PUBLISH, SUBSCRIBE, NOTIFY, décrites dans le standard RFC3903. Le serveur de communication CS, et les terminaux téléphoniques TA, TB, etc, comportent chacun un processeur exécutant des logiciels, permettant notamment d'informer un usager qu'il est le destinataire d'un renvoi téléphonique, conformément au procédé selon l'invention. Par exemple, un premier usager, Alice, dispose du terminal téléphonique TA ; et un second usager Bob, dispose du terminal téléphonique TB. Dans le serveur de communication CS, un module logiciel est chargé de la signalisation SIP. Il comporte des moyens logiciels pour notifier à un usager la création puis la suppression d'un renvoi, si cet usager est abonné à ce service de notification. Dans chaque terminal téléphonique TA, TB, etc, un module logiciel appelé « agent utilisateur » (user agent, en anglais) est chargé de la signalisation SIP. Ce module comporte des moyens logiciels pour permettre à un usager utilisant ce terminal de s'abonner à ce service, et de recevoir une notification via ce terminal lorsqu'un renvoi, vers cet usager, est créé/supprimé. Etape n '1 : Bob utilise le clavier et l'écran du terminal TB pour demander à bénéficier du service de notification permettant d'informer un usager qu'il est le destinataire d'un renvoi téléphonique (Dans d'autres modes de réalisation, cette opération peut être automatique ou être effectuée lors de la configuration du terminal). L'agent utilisateur du terminal TB envoie au serveur de communication CS un message : "SUBSCRIBE sip:server@example.com SIP/2.0 To: From: Call-ID:... CSeq: 1 SUBSCRIBE Event: forward-indication Accept: application/x-forward-indication Content-Length: 0 " Ce message demande que l'usager bob@example.com soit alerté lors d'un événement appelé « forward-indication » constitué par la création d'un renvoi vers le terminal de cet usager. La norme RFC 3903 décrit le principe général de souscription, publication, notification d'événement. Elle est applicable pour tout type d'événement (il existe aujourd'hui des événements de type « presence », « registration », « mwi » ...). Le type d'événement « forward-indication » n'existe pas encore dans cette norme. Il serait à créer. Etape n°2 : Dans le serveur de communication CS, les moyens logiciels chargés de notifier les événements de création/suppression d'un renvoi à un usager destinataire de ce renvoi, envoient au terminal TB de Bob un message SIP : "NOTIFY sip:Bob@example.com SIP/2.0 To: From: Call-ID:... CSeq: 2 NOTIFY Event: forward-indication Content-Type: application/x-forward-indication Content-Length:... forwarded: EMPTY" Ce message est semblable à un message de notification de création/suppression de renvoi, sauf qu'il ne contient pas d'indication sur l'identité d'un usager qui créerait un renvoi, dans le cas où il n'y a pas encore de renvoi vers Bob. Ce message a alors seulement pour fonction d'indiquer que l'usager bob@example.com a bien été abonné au service demandé. Dans le cas où il existe déjà un renvoi vers Bob, ce message indique en outre l'existence de ce renvoi et l'identité de celui qui a créé ce renvoi. Etape n°3 : Alice utilise le clavier et l'écran du terminal TA pour créer un renvoi vers l'usager bob@example.com. Etape n°4 : L'agent utilisateur du terminal TA d'Alice envoie alors au serveur de communication CS un message SIP de publication du renvoi : "PUBLISH sip:server@example.com SIP/2.0 To: From: Call-ID:... CSeq: 333 PUBLISH Event: forward-indication Content-Type: application/x-forward-indication Content-Length:... forwarded: sip:Alcalice@example.com destination:sip:Bob@example.com condition: unconditional reason: out of office for 2 hours" qui indique qu'il existe un renvoi des appels destinés initialement à l'utilisateur alice@example.com, vers l'utilisateur bob@example.com. Il contient une indication sur le type de renvoi : « unconditionnal » signifie que le renvoi est sans condition. Il contient en outre un champ Reason pour un texte qui peut être une explication du renvoi et qui est destiné à être affichée sur le terminal TB de l'usager Bob, destinataire du renvoi. Dans cet exemple, le texte « out of office for 2 hours » signifie qu'Alice est absente de son bureau pendant deux heures (Ce texte peut-être saisi manuellement ou sélectionné dans une liste de textes pré-saisis). Etape n°5 : Dans le serveur de communication CS, les moyens logiciels chargés de notifier les événements du type création/suppression d'un renvoi à un usager destinataire de ce renvoi, envoient au terminal TB de Bob un message SIP : "NOTIFY sip:Bob@example.com SIP/2.0 To: From: Call-ID:... CSeq: 444 NOTIFY Event: forward-indication Content-Type: application/x-forward-indication Content-Length:... forwarded: sip:Alcalice@example.com destination:sip:Bob@example.com condition: unconditional reason: out of office for 2 hours" qui informe l'usager bob@example.com que les appels destinés initialement à l'utilisateur alice@example.com sont renvoyés vers l'utilisateur bob@example.com; que le renvoi est de type « sans condition » ; et il joint une explication du renvoi, destinée à être affichée sur le terminal TB : « out of office for 2 hours » signifie qu'Alice est absente de son bureau pendant deux heures. Lorsqu'Alice commande la suppression du renvoi, le module logiciel agent utilisateur » du terminal TB envoie au serveur CS un message SIP : PUBLISH From: sip: Alice@example.com Event: forward-indication Forwarded: sip: Alice@example.com Destination: sip: bob@example.com Condition: canceled Puis, dans le serveur de communication CS, les moyens logiciels chargés de notifier les événements du type création/suppression d'un renvoi à un usager destinataire de ce renvoi, envoient au terminal TB de Bob un message SIP : « NOTIFY To: sip: bob@example.com Event: forward-indication" qui informe l'usager bob@example.com qu'il n'ya plus de renvoi le prenant comme destination. La figure 2 illustre le fonctionnement d'un deuxième exemple de mise en oeuvre du procédé selon l'invention, comportant un serveur WS qui est un serveur d'applications téléphoniques muni d'une interface web. Ce serveur WS est couplé à un autocommutateur classique de réseau d'entreprise, PBX. Ce serveur WS est commun pour tous les utilisateurs de ce réseau d'entreprise, et il exécute notamment une application téléphonique fournissant un service de notification permettant d'informer un usager qu'il est le destinataire d'un renvoi téléphonique. Dans cet exemple, ce serveur WS utilise les protocoles HTTPS (Hypertext Transfer Protocol Secure) et SOAP (Simple Object Access Protocol) pour recevoir des demandes de service et pour envoyer les notifications. Chaque utilisateur a, en plus de son terminal téléphonique, TT1, TT2, etc, un ordinateur personnel PC1, PC2, etc. Dans cet exemple de réalisation, cet ordinateur personnel exécute une application téléphonique légère qui a une interface web et qui est apte à collaborer avec l'application téléphonique exécutée sur le serveur WS. Cette dernière est alors seule à comporter une pile SOAP. L'application dans chaque ordinateur d'utilisateur se réduit alors pratiquement à une interface graphique. Le serveur web WS est couplé à l'autocommutateur PBX par une liaison classique de signalisation entre ordinateur et autocommutateur (liaison dite d'Intégration Ordinateur-Téléphonie, ou Computer Telephony Integration CTI en anglais). Elle permet d'échanger des commandes et des informations sur les événements. Etape n°21 : Bob utilise son ordinateur personnel PC2 pour demander, à l'application exécutée sur le serveur WS, à bénéficier du service de notification permettant d'informer un usager qu'il est le destinataire d'un renvoi téléphonique. Pour cela, l'application exécutée sur l'ordinateur personnel PC2 envoie au serveur WS un message de type web : Subscribe (Bob's session, eventType=forwardlndication) qui donne l'identité de Bob et celle du service demandé par Bob. Etape n°24 : Alice utilise son ordinateur personnel PC1 pour créer un renvoi vers le poste de Bob. Pour cela, elle lance l'exécution de l'application téléphonique installée sur son ordinateur personnel PC1, si celle-ci n'est pas déjà lancée. Alice saisit son identifiant et son mot de passe, puis commande un renvoi, en précisant le nom du destinataire (Bob) et le type du renvoi (Renvoi sans condition). Elle tape un court texte d'explication, par exemple « out of office for 2 hours » qui signifie qu'elle s'absente du bureau pour deux heures. L'application téléphonique exécutée sur l'ordinateur personnel PC1 envoie au serveur web WS un message de type web : setforward (Alice's session, destination=Bob, condition=unconditional, reason="out of office for 2 hours") qui commande de renvoyer les appels destinés initialement à l'utilisateur Alice vers l'utilisateur Bob, et qui commande de notifier cet événement au destinataire du renvoi. Il contient une indication sur le type de renvoi : « unconditionnal » signifie que le renvoi est sans condition. Il contient en outre un champ Reason pour du texte qui peut être une explication du renvoi et qui est destiné à être affichée sur l'ordinateur PC2 de Bob. Dans cet exemple, le texte est « out of office for 2 hours >>. Etape n°25 : L'application téléphonique exécutée sur le serveur WS commande l'autocommutateur PBX pour créer le renvoi demandé. Puis l'application téléphonique exécutée sur le serveur WS envoie à l'application téléphonique exécutée sur l'ordinateur PC2 de Bob un message de notification, de type web : Event (user: Bob, Event type= forwardIndication Forwarded=Alice, Conditition=unconditional, Reason="out of office for 2 hours") qui contient l'identité de l'événement signalé (forwardlndication), l'identité du destinataire du renvoi (Bob), l'identité de la personne dont les appels sont renvoyés (Alice), le type de renvoi (Unconditional signifie sans condition), et le texte d'explication fourni par Alice. L'ordinateur PC2 de Bob affiche ces informations sous une forme facilement compréhensible et visible. Par exemple, il affiche ces informations dans une fenêtre qui s'ouvre au premier plan sur son écran. Lorsqu'Alice commande la suppression du renvoi (Actions non représentées sur les figures), au moyen de son ordinateur personnel PC1, l'application téléphonique exécutée sur cet ordinateur PC1 envoie au serveur WS un message web : cancelforward (Alice's session) qui commande d'annuler tout renvoi en cours pour Alice, et qui commande de notifier cet événement au destinataire du renvoi en cours. L'application téléphonique exécutée sur le serveur WS commande l'autocommutateur PBX pour supprimer le renvoi en cours. Puis l'application téléphonique exécutée sur le serveur WS envoie à l'application téléphonique exécutée sur l'ordinateur PC2 de Bob un message de notification, de type web : Event (user: Bob, Event type= forwardIndication Forwarded=Alice, Conditition= canceled) qui contient l'identité de l'événement signalé (forwardlndication), l'identité du destinataire du renvoi (Bob), l'identité de la personne dont les appels sont renvoyés (Alice) et le type de renvoi (canceled signifie « annulation du renvoi »). L'ordinateur PC2 de Bob affiche ces informations sous une forme facilement compréhensible et visible. Par exemple, il affiche ces informations dans une fenêtre qui s'ouvre au premier plan sur son écran. Selon une variante de réalisation, chaque ordinateur personnel PC1, PC2, etc, exécute une application téléphonique lourde qui est apte à collaborer avec l'application téléphonique exécutée sur le serveur WS. Cette application lourde comporte une pile SOAP, et une interface web. La figure 3 illustre le fonctionnement d'un troisième exemple de mise en oeuvre du procédé selon l'invention, comportant comme dans l'exemple précédent, un serveur WS' qui est un serveur d'applications téléphoniques muni d'une interface web, et qui est couplé à un autocommutateur classique pour réseau d'entreprise, PBX', par une liaison dite d'Intégration Ordinateur-Téléphonie. Ce serveur WS' est commun pour tous les utilisateurs de ce réseau d'entreprise, et il exécute notamment une application téléphonique fournissant un service de notification permettant d'informer un usager qu'il est le destinataire d'un renvoi téléphonique. Cet exemple de réalisation diffère du deuxième exemple par la présence d'un serveur d'applications AS qui permet d'automatiser la création d'un renvoi selon une logique prédéfinie. Le serveur d'applications AS est commun à tous les usagers du réseau d'entreprise. Il comporte des moyens logiciels pour détecter l'absence d'un usager à proximité du terminal téléphonique dédié à cet usager, en observant des événements signalés par l'ordinateur personnel dédié à cet usager. Dans cet exemple, les deux serveurs d'applications AS et WS' utilisent les protocoles HTTPS (Hypertext Transfer Protocol Secure) et SOAP (Simple Object Access Protocol) pour recevoir des demandes de service et pour envoyer des notifications. Chaque utilisateur a, en plus de son terminal téléphonique, TT1', TT2', etc, un ordinateur personnel PC1', PC2', etc, exécutant une application téléphonique légère qui a une interface web, et qui est apte à collaborer avec l'application téléphonique exécutée sur le serveur d'applications téléphoniques WS' muni d'une interface web. Elle est aussi apte à collaborer avec l'application exécutée sur le serveur d'applications AS. Dans cet exemple de réalisation, l'application téléphonique exécutée sur le serveur WS' est seule à comporter une pile SOAP. L'application téléphonique légère exécutée dans chaque ordinateur d'utilisateur, se réduit alors pratiquement à une interface graphique. L'application exécutée sur le serveur AS applique des règles prédéfinies pour chaque employé de l'entreprise pour commander la création/suppression d'un renvoi. Pour un employé donné, ces règles sont soit définies par cet employé, soit définies par défaut. Un exemple de règle par défaut peut consister à commander la création d'un renvoi vers le terminal de l'assistante associée respectivement à l'usager destinataire initial, chaque fois que l'agenda de cet usager indique qu'il est absent de son bureau. Puis à commander la suppression de ce renvoi lorsque l'agenda de cet usager indique qu'il est présent à son bureau. Selon une autre règle, donnée à titre d'exemple, si l'application exécutée sur le serveur d'applications AS détecte que cet usager s'absente de son bureau, en détectant qu'il a fermé une session sur son ordinateur personnel PC1', elle envoie alors, au serveur d'applications téléphoniques WS, un message contenant : un indicateur commandant la création et la notification d'un renvoi, l'identité du destinataire initial des appels, qui est l'usager absent, et l'identité du destinataire des appels renvoyés, qui est un autre usager prédéfini. Par exemple, sur la figure 3 : Etape n°31 : Bob utilise son ordinateur personnel PC2' pour demander, à l'application exécutée sur le serveur WS', à bénéficier du service de notification permettant d'informer un usager qu'il est le destinataire d'un renvoi téléphonique. Pour cela, l'application exécutée sur l'ordinateur personnel PC2' envoie au serveur WS' un message de type web : Subscribe (Bob's session, eventType=forwardlndication) qui donne l'identité de Bob et celle du service demandé par Bob. Etape n°33 : Alice éteint son ordinateur personnel PC1', ou bien ferme la session en cours sur cet ordinateur PC1'. Un module logiciel exécuté sur cet ordinateur PC1' signale cette fin de session au serveur d'applications AS. Etape n 034 : L'application exécutée sur le serveur d'applications AS en conclut qu'Alice n'est plus à proximité de son terminal téléphonique. Elle émet un message à destination du serveur d'applications téléphoniques WS'. Ce message commande la création d'un renvoi des appels destinés initialement à l'utilisateur de l'ordinateur PC1', c'est-à-dire Alice, vers un autre utilisateur prédéfini, Bob dans cet exemple. Cette application précise dans ce message le nom du destinataire (Bob) et le type du renvoi (Renvoi sans condition). Selon un mode de réalisation préféré, elle inclut dans ce message un court texte d'explication, par exemple out of office » qui signifie qu'Alice est absente du bureau. Dans cet exemple de réalisation, l'application exécutée sur le serveur AS envoie au serveur d'applications téléphonique WS' un message de type web : setforward (Application's session, forwarded=Alice destination=Bob, condition=unconditional, reason="out of office") qui commande de renvoyer les appels destinés initialement à l'utilisateur Alice vers l'utilisateur Bob. Il contient une indication sur le type de renvoi : unconditionnal » qui signifie que le renvoi est sans condition. Il contient en outre un champ Reason pour envoyer du texte qui peut être une explication du renvoi, et qui est destiné à être affiché sur l'ordinateur PC2' de Bob. Dans cet exemple, le texte « out of office » signifie qu'Alice est absente de son bureau. Etape n°36 : L'application téléphonique exécutée sur le serveur WS' commande l'autocommutateur PBX' pour créer le renvoi demandé. 10 Etape n°35 : Puis l'application téléphonique exécutée sur le serveur WS' envoie à l'application téléphonique exécutée sur l'ordinateur PC2' de Bob un message de notification, de type web : Event (user: Bob, 15 Event type= forwardlndication Forwarded=Alice, Conditition=unconditional, Reason="out of office") qui contient l'identité de l'événement signalé (forwardlndication), l'identité du 20 destinataire du renvoi (Bob), l'identité de la personne dont les appels sont renvoyés (Alice), le type de renvoi (Unconditional signifie sans condition), et le texte d'explication "out of office" fourni par le serveur d'applications AS. L'ordinateur PC2' de Bob affiche ces informations sous une forme facilement compréhensible et visible. Par exemple, il affiche ces informations dans une 25 fenêtre qui s'ouvre au premier plan sur son écran. Lorsqu'Alice remet en marche son ordinateur personnel PC1', ou ré-ouvre une session à son nom (Actions non représentées sur les figures), l'application téléphonique exécutée sur son ordinateur personnel PC1' envoie au serveur WS' un 30 message web : cancelforward (Alice's session) qui commande d'annuler tous le renvoi en cours pour Alice, et qui commande de notifier cet événement au destinataire du renvoi en cours. L'application téléphonique exécutée sur le serveur WS' commande l'autocommutateur PBX' pour créer le renvoi demandé. Puis l'application téléphonique exécutée sur le serveur WS' envoie à l'application téléphonique exécutée sur l'ordinateur PC2' de Bob un message de notification, de type web : Event (user: Bob, Event type= forwardIndication Forwarded=Alice, Conditition= canceled) qui contient l'identité de l'événement signalé (forwardlndication), l'identité du destinataire du renvoi (Bob), l'identité de la personne dont les appels sont renvoyés (Alice) et le type de renvoi (canceled signifie annulation du renvoi. L'ordinateur PC2' de Bob affiche ces informations sous une forme facilement compréhensible et visible. Par exemple, il affiche ces informations dans une fenêtre qui s'ouvre au premier plan sur son écran. Selon une variante de réalisation, le serveur d'applications téléphoniques avec interface web, WS', et l'autocommutateur classique PBX' peuvent être remplacés par un autocommutateur utilisant les protocoles Internet et SIP, comme dans le premier exemple décrit ci-dessus.20 REVENDICATIONS: 1) Procédé pour informer un premier usager qu'il est le destinataire d'un renvoi des appels téléphoniques destinés initialement à un second usager, caractérisé en ce qu'il comporte les étapes consistant à : - envoyer une demande de service (1 ; 21 ; 31) d'un terminal (TB ; PC2 ; PC2') du premier usager à un serveur d'applications téléphoniques (CS ; WS ; WS') permettant notamment d'informer le premier usager qu'il est le destinataire d'un renvoi des appels téléphoniques destinés initialement à un second usager, - puis, lorsqu'est créé un renvoi des appels destinés initialement au second usager vers ce terminal (TB ; PC2 ; PC2') du premier usager : -- envoyer (4 ; 24 ; 34) à ce serveur d'applications téléphoniques (CS ; WS ; WS') un message de publication de renvoi, contenant l'identité du premier usager, l'identité du second usager, et un indicateur indiquant la création d'un renvoi, -- puis envoyer (5 ; 25 ; 35) une notification de renvoi, de ce serveur d'applications téléphoniques (CS ; WS ; WS') au terminal (TB ; PC2 ; PC2') du premier usager, cette notification contenant l'identité du second usager, et un indicateur indiquant la création d'un renvoi. 2) Procédé selon la revendication 1, consistant en outre à : - inclure dans le message de publication (4 ; 24 ; 34) une indication sur le type de renvoi, - puis inclure cette indication dans la notification de renvoi (5 ; 25 ; 35), et afficher le type de renvoi sur le terminal (TB ; PC2 ; PC2') du premier usager. 3) Procédé selon la revendication 1, consistant en outre à : - inclure dans le message de publication (4 ; 24 ; 34) un texte apte à être affiché sur le terminal du premier usager, - puis inclure ce texte dans la notification de renvoi (5 ; 25 ; 35), - et à afficher ce texte sur le terminal (TB ; PC2 ; PC2') du premier usager. 4) Terminal de communication (TB ; PC2 ; PC2') permettant d'informer un usager de ce terminal qu'il est le destinataire des appels téléphoniques destinés initialement à un second usager, caractérisé en ce qu'il comporte : - des moyens pour recevoir (5 ; 25 ; 35) une notification de renvoi envoyée par un serveur d'applications téléphoniques (CS ; WS ; WS'), - et des moyens pour afficher une indication de renvoi et l'identité du second usager, contenues dans la notification reçue. 5) Terminal de communication (TA ; PC1 ; PC1') selon la revendication 4, permettant en outre d'informer l'usager d'un autre terminal (TB ; PC2 ; PC2') que les appels destinés initialement au premier terminal (TA ; PC1 ; PC1') sont renvoyés vers cet autre terminal (TB ; PC2 ; PC2'), caractérisé en ce qu'il comporte en outre des moyens pour envoyer (4 ; 24 ; 33-34) un message de publication de renvoi à un serveur d'applications téléphoniques (CS ; WS ;WS') permettant d'informer ce serveur que les appels téléphoniques destinés initialement au premier terminal (TA ; PC1 ; PC1') sont renvoyés vers cet autre terminal (TB ; PC2 ; PC2'). 6) Terminal de communication (TB ; PC2 ; PC2') selon la revendication 4, comportant en outre des moyens pour afficher une indication de type de renvoi, contenue dans la notification reçue. 7) Terminal de communication (TB ; PC2 ; PC2') selon la revendication 4, comportant en outre des moyens pour afficher un texte contenu dans la notification reçue. 8) Terminal de communication (TA ; PC1 ; PC1') selon la revendication 5, caractérisé en ce que les moyens pour envoyer un message de publication (4 ; 24 ; 33-34) comportent des moyens pour insérer dans ce message de publication : un indicateur indiquant la création d'un renvoi, l'identité d'un usager de ce terminal, qui est le destinataire initial des appels, et l'identité d'un second usager qui est le destinataire des appels renvoyés. 9) Serveur d'applications téléphoniques (CS ; WS ; WS') permettant d'informer un usager qu'il est le destinataire d'un renvoi téléphonique, caractérisé en ce qu'il comporte : - des moyens pour recevoir une demande de service (1 ; 21 ; 31) émise par un terminal (TB; PC2 ; PC2') d'un premier usager, et indiquant que ce premier usager souhaite être informé qu'il est le destinataire d'un renvoi téléphonique, - des moyens pour recevoir (4 ; 24 ; 33-34) un message de publication de renvoi, provenant d'un terminal (TA ; PC1 ; PC1') d'un second usager, et contenant : un indicateur indiquant la création d'un renvoi, l'identité du destinataire initial des appels, qui est le second usager, et l'identité du destinataire des appels renvoyés, qui est le premier usager ; - et des moyens pour envoyer ensuite (5 ; 25 ; 35) une notification au terminal (TB ; PC2 ; PC2') du premier usager, cette notification contenant un indicateur indiquant la création d'un renvoi, l'identité du destinataire initial des appels, qui est le second usager, et l'identité du destinataire des appels renvoyés, qui est le premier. 10) Serveur d'applications téléphoniques (CS ; WS ; WS') selon la revendication 9, dans lequel les moyens pour recevoir (4 ; 24 ; 33-34) un message de publication de renvoi comportent des moyens pour recevoir un indicateur de type de renvoi, contenu dans ce message ; et dans lequel les moyens pour envoyer (5 ; 25 ; 35) une notification au terminal (TB ; PC2 ; PC2') du premier usager comportent en outre des moyens pour inclure un indicateur de type de renvoi dans cette notification. 11) Serveur d'applications téléphoniques (CS ; WS ; WS') selon la revendication 9, dans lequel les moyens pour recevoir (4 ; 23 ; 32-33) un message de publication de renvoi comportent des moyens pour recevoir en outre un texte contenu dans ce message ; et dans lequel les moyens pour envoyer (5 ; 25 ; 35) une notification à un terminal (TB ; PC2 ; PC2') du premier usager comportent en outre des moyens pour inclure ce texte dans cette notification. 12) Serveur d'applications téléphoniques (WS) selon la revendication 9, dans lequel les moyens pour recevoir (23 ; 32-33) un message de publication de renvoi, et les moyens pour envoyer (25 ; 35) une notification, comportent une interface web. 13) Serveur d'applications téléphoniques (CS) selon la revendication 9, dans lequel les moyens pour recevoir (4) un message de publication de renvoi et les moyens pour envoyer (5) une notification comportent une interface conforme au protocole SI P. 10 13) Serveur d'applications (AS) caractérisé en ce qu'il comporte des moyens pour détecter (33) l'absence d'un usager à proximité d'un terminal (PC1') de cet usager, et envoyer alors, à un serveur d'applications téléphoniques (WS'), un 15 message de publication de renvoi contenant : un indicateur commandant la création d'un renvoi, l'identité du destinataire initial des appels, qui est cet usager absent, et l'identité du destinataire des appels renvoyés, qui est un autre usager. 14) Serveur d'applications (AS) selon la revendication 13, dans lequel 20 lesdits moyens pour envoyer un message de publication de renvoi comportent des moyens pour inclure dans ce message un texte destiné à être communiqué à l'autre usager qui est destinataire des appels renvoyés.5