Brevet FR2953676A1 — publié le 20110610

La présente invention concerne un procédé, un terminal et un système de communication par messages non verbaux, notamment lors d'une session de messagerie instantanée. Les communications en ligne par messagerie instantanée, largement utilisées de nos jours, sont séquentielles: un utilisateur saisit un message verbal au moyen d'un clavier puis l'envoie à un deuxième utilisateur, ce dernier reçoit le message puis répond à celui-ci par un deuxième message. Généralement, la discussion entre utilisateurs requiert que chacun réponde après l'autre. On entend ici par "verbal" ce qui se rapporte aux mots saisis par et significatifs pour les utilisateurs, notamment des messages comprenant des mots écrits. Ces échanges reflètent ainsi une conversation à vive voix entre les protagonistes, toutefois sans restituer la communication non verbale et plus intime qui accompagne généralement l'échange de mots. Il s'agit par exemple de la gestuelle ou de certaines expressions comportementales. Certaines tentatives d'amélioration de la communication non verbale ont pu être proposées, comme par exemple une codification de l'écriture verbale pour refléter certaines humeurs: l'utilisation de caractères majuscules pour exprimer la colère ou indiquer l'utilisation d'une voix très forte. Cette codification, pour qu'elle puisse être connue et mise en oeuvre de façon appropriée par les utilisateurs, ne peut cependant exprimer qu'un petit nombre d'humeurs et d'expressions comportementales. Il existe également, en marge des échanges de messages verbaux, l'envoi séquentiel de fichiers graphiques collaboratifs entre les utilisateurs. Les dessins constituent en effet un vecteur efficace d'expression et de transmission des émotions, comme le montrent au quotidien les artistes et certaines approches thérapeutiques. Chacun des utilisateurs peut ajouter sa propre contribution au fichier graphique échangé de sorte à exprimer certaines émotions. Toutefois, ces échanges sont ralentis du fait de la taille du fichier graphique à transmettre. Il peut en résulter un décalage avec une discussion parallèle par messages verbaux ou un ralentissement de celle-ci. Par ailleurs, après maints échanges, les contributions des différents utilisateurs deviennent difficiles à identifier. La présente invention vise à pallier ces différents inconvénients de l'art antérieur en proposant un nouveau mode de communication instantanée entre utilisateurs distants disposant chacun d'un terminal de communication, basé sur une simultanéité de transmission de messages non verbaux favorisant l'expression d'un grand nombre d'humeurs et d'expressions comportementales propres de chacun des utilisateurs. A cet effet, la présente invention concerne un procédé de communication par messages non verbaux entre un premier terminal et au moins un deuxième terminal, munis chacun d'un écran tactile, comprenant les étapes consistant à : - générer des données d'interaction écran représentatives d'au moins une action de contact d'un utilisateur sur l'écran tactile dudit premier terminal ; - transmettre lesdites données d'interaction écran audit au moins un deuxième terminal au travers d'un réseau de communication ; - sur chacun desdits premier et deuxième terminaux, convertir lesdites données d'interaction écran en données d'image graphique correspondant à ladite au moins une action de contact et combiner lesdites données d'image graphique avec des données d'une image graphique déjà affichée sur l'écran tactile du terminal de sorte à mettre à jour l'affichage de l'image graphique sur le terminal. Les données d'interaction écran sont sensiblement des données brutes générées par l'écran tactile lors de l'interaction de l'utilisateur, telles que des événements de toucher ("touch events") alors que les données d'image graphique qui en dérivent constituent la nouvelle contribution graphique de l'utilisateur à afficher. Cette contribution graphique résulte des actions de contact de l'utilisateur sur l'écran, qu'il s'agisse indifféremment d'un dessin de l'utilisateur sur l'écran tactile de son terminal, d'une action de pointage, d'une action de tracé, ou encore d'une action d'écriture etc. Selon l'invention, seules les données d'interaction écran, et non une image résultant du dessin de l'utilisateur, sont transmises entre les utilisateurs, ce qui réduit considérablement le volume de données transférées. Par ailleurs, en transférant uniquement les données de la nouvelle contribution, on économise le transfert des contributions antérieures. Ainsi, selon l'invention également, les données d'interaction écran reçues sont combinées, après conversion, à l'image déjà affichée reprenant d'ailleurs les contributions antérieures. Par ce mécanisme, l'invention permet également de conserver, à moindre coût (sans mémorisation dans une mémoire dédiée), les contributions antérieures. Il en résulte des échanges plus rapides, des traitements sur les terminaux plus rapides et donc une communication non verbale plus représentative des émotions et comportements instantanés. Enfin, l'utilisation du dessin apporte une infinité de façons d'exprimer 15 ses humeurs ou un comportement. La communication non verbale selon l'invention peut constituer l'échange principal d'une session de messagerie instantanée ou être une communication annexe d'une communication verbale existante de messagerie instantanée. 20 Dans un mode de réalisation, lesdites données d'interaction écran sont des événements de toucher générés par le système de contrôle de l'écran tactile en réponse à ladite au moins une action de contact sur l'écran tactile dudit premier terminal. De la sorte, les données d'interaction écran sont transmises au plus vite aux terminaux car aucun traitement particulier n'est 25 nécessaire avant transmission. On peut notamment utiliser des écrans tactiles sur étagère conforme à une norme d'interfaçage (fournissant les données d'interaction écran ù touch events), ce qui permet d'assurer une compatibilité entre les différents terminaux d'utilisateur. Dans un mode de réalisation, lesdites données d'interaction écran 30 sont transmises au cours d'une session de messagerie instantanée basée sur le protocole XMPP. Bien que le protocole XMPP soit utilisé efficacement pour la transmission de messages verbaux, les inventeurs ont observé qu'avec peu d'adaptations, ce protocole XMPP permet la transmission des données non verbales assimilables par une machine informatique à moindre coût, tout en satisfaisant la (quasi)-instantanéité des communications. En particulier, lesdites données d'interaction écran sont encodées selon un format binaire, à l'intérieur d'un élément XML d'un message XMPP. Cette disposition permet de satisfaire aux conditions de limite de débit du trafic XMPP (généralement 2 kilo-octets.s-l), malgré le volume relatif de données d'interaction. En effet, le langage XML étant très prolixe du fait de l'indication de la structure par des balises, l'utilisation d'éléments XML pour renseigner chacune des données d'interaction écran s'avère trop consommatrice de débit, en raison du grand nombre de balises XML à utiliser. Selon une caractéristique particulière, le procédé comprend une étape de mémorisation, dans une mémoire tampon, d'une pluralité de données d'interaction écran correspondant à une pluralité d'événements de toucher sur l'écran tactile avant transmission de cette pluralité de données d'interaction écran au sein d'un même message du protocole XMPP. De la sorte, on évite la transmission d'un message pour chaque événement de toucher, ce qui augmenterait le débit de données échangées, et donc le temps moyen de transmission. En particulier, ladite pluralité d'événements de toucher comprend des événements d'interaction simultanée sur un même écran tactile multi-touches. L'utilisation d'écrans tactiles multi-touches permet d'améliorer l'interaction des utilisateurs, tout en offrant une plus grande palette de combinaisons possibles de dessins susceptibles de traduire l'humeur ou le comportement de l'utilisateur les ayant provoquées. Dans un mode de réalisation de l'invention, le procédé comprend une étape consistant à générer, localement sur ledit deuxième terminal, des données d'image graphique à partir de données d'interaction écran locales résultant d'au moins une action de contact d'un utilisateur sur l'écran tactile dudit deuxième terminal; et dans lequel les données d'image graphique reçues dudit premier terminal et les données d'image graphique générées localement sur ledit deuxième terminal sont combinées de façon opposée, aux données d'image graphique déjà affichée. On entend par "de façon opposée", le fait que les données peuvent être affichées de deux façons relativement à un état de référence. C'est en particulier le cas pour des images tridimensionnelles où l'état référent est par exemple un plan dit "de repos" et les deux façons d'afficher jouent sur l'effet de relief pour créer soit un enfoncement apparent (indentation) pour une façon, soit une protubérance apparente (protrusion) pour la façon opposée. Cette disposition permet de distinguer, à moindre coût, les contributions de chacun dans le temps. En particulier, les images graphiques affichées sur lesdits premier et deuxième terminaux sont des images tridimensionnelles miroir l'une de l'autre. Ainsi, chaque utilisateur voit de la même façon sur son terminal, sa propre contribution (par enfoncement sous le doigt de l'utilisateur par exemple) et la contribution de l'utilisateur distant (par protrusion correspondant à un ou plusieurs doigts de l'autre utilisateur derrière le dessin). L'image tridimensionnelle ainsi obtenue peut s'apparenter à une membrane élastique de chaque côté de laquelle les deux utilisateurs apportent leur contribution. Une telle mise en oeuvre offre une simplicité importante pour chacun des utilisateurs, dans la mise en oeuvre de la communication non verbale et dans la compréhension des messages provenant de l'autre utilisateur. En outre, cet affichage "miroir" introduit une symétrie qui permet de conserver une utilisation identique de l'application de communication non verbale que l'utilisateur soit appelant ou appelé: notamment, sa propre contribution résulte par exemple toujours en un enfoncement localisé de l'image tridimensionnelle, et celle de l'utilisateur distant toujours en une protrusion. Dans un mode de réalisation de l'invention, une donnée d'image graphique à combiner et correspondant à au moins une coordonnée issue de l'action de contact est multipliée par un coefficient prédéfini si cette donnée d'image graphique est de signe opposé à la donnée d'image graphique ayant la même coordonnée dans l'image graphique déjà affichée. Comme décrit ci-dessus, la notion d"'opposé" se rapporte à un état (plan) de référence de l'image. Par cette disposition, la contribution d'un utilisateur (par exemple contribution positive - protrusion) est modulée en fonction de la contribution passée (qui est donc affichée) de l'autre utilisateur. A titre d'exemple, cette modulation peut résulter en une contribution plus longue de l'utilisateur pour atténuer celle de l'autre. Ainsi, un dialogue non verbal peut s'établir, de façon très interactive, entre les deux utilisateurs. Selon une caractéristique de l'invention, le procédé comprend, sur un terminal, une étape périodique de pondération des données d'image graphique correspondant à une image affichée sur l'écran tactile du terminal, ladite pondération étant agencée pour faire évoluer des données d'image graphique vers des données d'image graphique correspondant à une image de référence, notamment lorsque aucune nouvelle donnée d'interaction écran n'est reçue par le terminal ou générée localement sur le terminal. L'image de référence correspond notamment à l'état de référence évoqué précédemment. La disposition présentée ici permet d'atténuer les contributions anciennes au profit des contributions récentes, et permet donc une meilleure lecture des émotions courantes des utilisateurs. En effet, au cours d'une conversation non verbale, les émotions évoluent de telle sorte que celles-ci deviennent moins significatives (d'où leur pondération) et peuvent donc être supprimées à terme (état correspondant à l'image de référence). Dans notre exemple précédent, cela revient à ce qu'au bout d'un certain temps (notamment fixé et/ou paramétré par l'utilisateur) la "membrane élastique" redevienne plane. Dans un mode de réalisation, le procédé comprend les étapes suivantes : - générer localement des données d'interaction écran résultant d'au moins une action de contact d'un utilisateur sur l'écran tactile dudit deuxième terminal ; et - si, pendant une période prédéfinie, lesdites données d'interaction écran générées localement et les données d'interaction écran dudit premier terminal reçues par ledit deuxième terminal correspondent sensiblement à une même zone de l'image à afficher, générer une signal sensoriel au niveau dudit deuxième terminal, par exemple un son, une vibration ou un changement de couleur de l'image affichée. De la sorte, les utilisateurs sont avertis dès qu'ils ont un comportement similaire, reflétant par exemple des émotions comparables. L'utilisation d'un signal sensoriel est particulièrement simple à mettre en oeuvre dans des terminaux de type téléphone portable ou assistant personnel. Du fait de l'effet miroir évoqué précédemment entre les affichages sur les terminaux communiquant, la "même zone" peut tenir compte d'une symétrie axiale représentative de cet effet miroir. L'invention concerne également un terminal de communication par messages non verbaux comprenant : - un écran tactile apte à générer des données d'interaction écran locales représentatives d'au moins une action de contact d'un premier utilisateur sur ledit écran tactile ; - un moyen de communication apte à recevoir, d'au moins un deuxième terminal, des données d'interaction écran représentatives d'au moins une action de contact d'un deuxième utilisateur sur un écran tactile du deuxième terminal ; - un moyen de conversion pour convertir lesdites données 20 d'interaction écran générées localement et/ou reçues en données d'image graphique locales et/ou reçues ; et - un moyen de combinaison pour combiner ces données d'image graphique locales et/ou reçues avec des données d'une image graphique déjà affichée sur l'écran tactile du terminal de sorte à mettre à jour l'affichage de 25 l'image graphique sur ce terminal. Le terminal de communication présente des caractéristiques et avantages analogues au procédé de communication selon l'invention. De façon optionnelle, le terminal peut comprendre des caractéristiques se rapportant aux étapes du procédé de communication par 30 messages non verbaux exposé précédemment. En particulier, ledit moyen de communication est également apte à transmettre, au sein d'une session XMPP établie avec ledit autre terminal, les données d'interaction écran générées locales. Certains aspects relatifs au contenu des messages XML échangés lors de cette session ont été présentés précédemment. L'invention concerne également un système de communication par 5 messages non verbaux comprenant : - un serveur apte à établir une session de messagerie instantanée entre au moins un premier et au moins un deuxième terminal ; - au moins un premier et un deuxième terminal comme décrits ci-dessus aptes à s'échanger des données d'interaction écran au moyen de ladite 10 session de messagerie instantanée. Le serveur peut être du type serveur de messagerie instantanée classique qui contrôle, de façon connue en soi, l'établissement de la session entre utilisateurs et opère le routage des messages échangés. Le système de communication présente des caractéristiques et 15 avantages analogues au procédé de communication selon l'invention. De façon optionnelle, le système peut comprendre des caractéristiques se rapportant aux étapes du procédé de communication par messages non verbaux exposé précédemment. En particulier, le système est configuré de sorte que les données 20 d'interaction écran échangées entre les deux dispositifs sont codées sous forme binaire à l'intérieur d'un élément XML d'un message XMPP. L'invention concerne également un moyen de stockage d'informations comprenant des instructions pour un programme informatique adapté à mettre en oeuvre le procédé de communication conforme à l'invention 25 lorsque ce programme est chargé et exécuté par un système informatique. L'invention concerne également un programme d'ordinateur lisible par un microprocesseur, comprenant des instructions pour la mise en oeuvre du procédé de communication conforme à l'invention, lorsque ce programme est chargé et exécuté par le microprocesseur. 30 Les moyens de stockage d'information et programme d'ordinateur présentent des caractéristiques et avantages analogues aux procédés qu'ils mettent en oeuvre. D'autres particularités et avantages de l'invention apparaîtront dans la description ci-après, illustrée par les dessins ci-joints, dans lesquels : - la figure 1 représente un exemple d'interface graphique d'une application de communication non verbale selon l'invention, montrant une "membrane élastique" sur laquelle apparaissent les contributions non verbales des utilisateurs; - la figure 2 représente un système pour la mise en oeuvre de la présente invention ; - la figure 3 montre une configuration matérielle particulière d'un 10 équipement, notamment un terminal du système de la figure 2, apte à une mise en oeuvre du procédé selon l'invention; - la figure 4 représente, sous forme d'ordinogramme, des étapes relatives à l'établissement d'une session de messagerie instantanée pour la mise en oeuvre de l'invention; 15 - la figure 5 représente, sous forme d'ordinogramme, des étapes relatives à l'interaction d'un utilisateur sur l'écran tactile de son terminal, selon les enseignements de l'invention; - la figure 6 illustre un exemple de messages non verbaux échangés conformément à l'invention pour produire la contribution représentée 20 sur la figure 1; - la figure 7 représente, sous forme d'ordinogramme, des étapes relatives au traitement d'un message non verbal reçu; - la figure 8 représente, sous forme d'ordinogramme, des étapes relatives au traitement local de données d'interaction écran pour mettre à jour 25 l'affichage d'un terminal; - la figure 9 illustre l'influence du temps d'appui sur l'affichage d'une contribution utilisateur; et - la figure 10 illustre un comportement symétrique de la part de deux utilisateurs communiquant. 30 Comme présenté ci-dessus, la présente invention est relative à la communication de messages non verbaux entre utilisateurs représentant des contributions de ces utilisateurs sur une même image graphique. L'invention s'applique à une session de messagerie instantanée entre un nombre quelconque d'utilisateurs, notamment deux ou plus. Pour des raisons de concision, on limitera la suite de la description à une session entre deux utilisateurs. L'image graphique qui s'affiche pour les deux utilisateurs peut être une image bidimensionnelle ou tridimensionnelle sur laquelle chaque contribution est exprimée à l'aide de caractéristiques d'affichage distinctes, par exemple des couleurs distinctes (le noir s'opposant au blanc sur un fond gris) ou des informations de relief (chaque image tridimensionnelle étant affichée selon un plan (X,Y), l'information de relief résultant de la composante Z par rapport à un plan de référence, par exemple (X,Y,0)). Pour les besoins d'illustration de la présente invention, on se limitera à la description d'une image tridimensionnelle dont chaque contribution s'exprime par une information de relief (composante z selon l'axe Z): enfoncement (z 0) pour une contribution résultant de l'utilisateur distant. Dans ce cas, l'image affichée à l'un des utilisateurs peut être l'image miroir de celle affichée à l'autre utilisateur. On notera qu'une telle information de relief est en particulier facilement détectable par les utilisateurs. Par l'effet miroir, la contribution de chaque utilisateur apparaît de façon opposée à l'autre utilisateur. Une protrusion apparaissant à l'écran d'un utilisateur reflète un enfoncement produit par l'autre utilisateur et dont les données correspondantes sont envoyées selon les enseignements de l'invention. Par ce comportement, l'image réciproque affichée sur les terminaux des deux utilisateurs s'apparente à une membrane élastique située entre eux deux, comme représentée sur la figure 1 pour l'un des utilisateurs. Sur cette figure, la membrane élastique a une position de repos (zones planes ; z=0) de laquelle ressort le dessin réalisé par l'autre utilisateur. On remarquera que l'invention s'applique à d'autres actions de contact de l'utilisateur sur l'écran tactile que l'action de dessin, par exemple une action de pointage, de tracé ou d'écriture, etc. Sur cette image, l'utilisateur distant a dessiné sensiblement un S en ralentissant la vitesse du tracé vers la queue basse du "S" (relief plus important). L'utilisateur du terminal 10, typiquement un téléphone mobile, voit donc, sur son écran tactile 12, un "S" inversé 20 apparaissant en relief positif (protrusion) avec un trait plus épais vers la queue basse du "S" exprimant l'insistance de l'autre utilisateur lors du tracé de cette partie. L'utilisateur du terminal 10 peut également interagir sur cet écran pour communiquer de façon non verbale, en réponse à l'expression de l'autre utilisateur ou simultanément. Pour ce faire, cet utilisateur va à son tour tracer un dessin exprimant ses émotions sur l'écran tactile 12. Comme évoqué précédemment, cette contribution de l'utilisateur du terminal 10 va se combiner à l'image déjà affichée, sous forme de relief négatif (enfoncement ; z La figure 3 montre schématiquement un équipement 50 pour la mise en oeuvre de l'invention, et notamment l'un quelconque des terminaux 10;. Le système 50 comprend un bus de communication 51 auquel sont reliés une unité centrale de traitement ou "microprocesseur" 52, une mémoire vive 53, une mémoire morte 54, un dispositif d'affichage 55, un dispositif de pointage 56, une interface de communication 57 et éventuellement d'autres périphériques (lecteur de disquette ou disques, etc.). Le dispositif d'affichage 55 et le dispositif de pointage 56 sont en particulier mis en oeuvre au sein d'un même écran tactile 12. L'utilisation de cet écran tactile, pouvant être un équipement sur étagère, est contrôlée par un contrôleur d'écran qui génère des événements de toucher ("touch events") suite à l'action d'un utilisateur sur cet écran et qui produit un affichage résultant d'une image produite par une carte graphique (non représentée) interne au terminal. Par exemple, l'écran tactile peut avoir une définition de 320 x 480 pixels. De façon connue en soi, le contrôleur est capable d'identifier les interactions de l'utilisateur, c'est-à-dire notamment le début, la fin et donc la durée d'une action d'un doigt. Cette action peut être un déplacement, un appui sans déplacement, un retrait du doigt, un clic, etc. Le contrôleur génère alors un événement InputEvent pour chacune de ces interactions. En particulier, si l'écran tactile est multi-touches (plusieurs doigts pouvant agir simultanément sur l'écran), le contrôleur est capable de discriminer chacune des interactions résultant de chaque doigt et donc de générer plusieurs événements pour des interactions simultanés. On notera en outre que le contrôleur traduit généralement une zone d'appui de l'utilisateur en un point actif, par exemple le centre de cette zone, afin d'identifier chaque interaction par une seule information de positionnement. Des informations complémentaires telles que la dimension de la zone d'appui (plus grande longueur ou diamètre par exemple) peuvent être prévues. Dans cet exemple, l'information de dimension permet de distinguer un appui fort (écrasement du doigt) d'un appui léger (zone plus petite). De façon connue en soi, les événements InputEvent sont constitués d'une pluralité d'événements élémentaires InputTouchEvent correspondant chacun à l'évolution de l'interaction écran pendant chaque période d'acquisition élémentaire (par exemple 1/100s) au cours de l'événement InputEvent. Dans le mode de réalisation illustratif de l'invention, la carte graphique commandant l'affichage sur l'écran est adaptée pour gérer des images tridimensionnelles selon trois axes X, Y, Z et produire une image d'affichage selon le plan (X,Y) avec des information de relief selon l'axe Z. Diverses techniques d'affichage 3D sur écran bidimensionnel peuvent être mises en oeuvre. Comme montrée sur la figure 1, cela peut résulter de la création d'ombres donnant une impression de relief. La quantité d'ombres dépend alors de l'amplitude (valeur Izi) du relief local. En variante, un quadrillage (courbes de niveaux) peut être utilisé. La mémoire morte 54 comprend les programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention, et notamment le code source de l'application de communication non verbale. Lors de l'exécution de programmes, le code exécutable de ceux-ci est chargé en mémoire vive 53, type RAM, et exécuté par le microprocesseur 52. Cette exécution permet le dialogue avec le contrôleur de l'écran tactile 12 pour contrôler l'affichage et l'acquisition des données d'interaction sur l'écran, et permet également l'envoi ou la réception de messages XMPP tels que décrits ci-après via l'interface de communication 57. Cette dernière permet notamment la connexion au réseau 30. La mémoire RAM permet également la mise en oeuvre d'une mémoire tampon pour mémoriser les événements de toucher produits, comme évoqué par la suite. L'équipement décrit ici et, particulièrement, l'unité centrale 52, sont susceptibles de mettre en oeuvre tout ou partie des traitements décrits en lien avec les figures 1, 2 et 4 à 10, pour mettre en oeuvre les procédés objets de la présente invention et constituer les terminaux et systèmes objets de la présente invention. La figure 4 montre l'établissement d'une session de messagerie instantanée entre deux utilisateurs pour une application de communication non verbale. Pour un utilisateur A souhaitant communiquer avec un deuxième utilisateur B, le traitement débute par l'étape E100 au cours de laquelle l'utilisateur A sélectionne l'utilisateur B aux fins de demander l'établissement d'une session de messagerie instantanée. Cette sélection peut être réalisée par l'indication directe de l'adresse Jabber de l'utilisateur B au niveau d'une interface dédiée de l'application de communication non verbale lors de son lancement. L'adresse Jabber peut prendre la forme suivante: "utilisateurB@serveur.com" où "utilisateurB" est l'identifiant unique de l'utilisateur B sur le serveur "serveur.com" représentant ici le serveur Jabber 32. En variante, l'indication de l'adresse peut être réalisée par la sélection du contact "utilisateur B" dans le carnet d'adresses du terminal 101. Un menu contextuel permet alors à l'utilisateur A de lancer l'application de communication non verbale depuis le carnet d'adresses, à partir du contact au niveau duquel est renseignée l'adresse "utilisateurB@serveur.com". En variante encore, l'utilisateur A peut indiquer, dans l'interface, ou avoir renseigné, au niveau du contact de son carnet d'adresses, un identifiant unique de l'utilisateur B (par exemple un numéro de téléphone) sans qu'il s'agisse directement d'une adresse Jabber. Au terme de cette sélection, l'application de communication non verbale s'exécute sur le terminal de l'utilisateur A et affiche une image dotée d'une texture prédéfinie sans aucune contribution dessus (appelée ci-après image de référence sans relief où z=0 pour tout point affiché). Une demande d'établissement d'une session de messagerie instantanée est alors envoyée au serveur Jabber 32 (étape E102). Cette demande d'établissement contient les adresses des utilisateurs ou les identifiants uniques de ceux-ci. Dans notre exemple, les deux adresses sont "utilisateurA@serveur.com" et "utilisateurB@serveur.com" utilisant un même serveur Jabber "serveur.com". Toutefois, les adresses des utilisateurs A et B peuvent être rattachées à deux serveurs de messagerie instantanée distincts auquel cas ces deux serveurs assurent ensemble l'établissement de la session de messagerie instantanée et le routage des messages échangés comme décrits pas la suite. A l'étape E104, le serveur 32 reçoit la demande, récupère si nécessaire, à l'aide des identifiants uniques, les adresses Jabber dans le serveur 34, puis établit une session XMPP entre les deux utilisateurs A et B. L'établissement d'une session XMPP est connu en soi par l'homme de l'art. Il comprend notamment une notification à l'utilisateur B l'invitant à lancer son application de communication non verbale s'il souhaite communiquer avec l'utilisateur A et si ce n'est pas déjà le cas. Une fois la session établie, les deux utilisateurs A et B peuvent utiliser l'application lancée localement sur chacun des deux terminaux 101 et 102 pour communiquer par messages non verbaux. Les deux terminaux sont alors dans un état d'attente d'événement (El 06). Cet état d'attente consiste principalement à mettre à jour périodiquement (par exemple chaque 1/10s) l'image affichée sur chacun des terminaux pour qu'elle redevienne similaire à l'image de référence (z=0 en tout point) au bout d'un certain temps en l'absence d'interaction de la part des utilisateurs. Pour ce faire, les reliefs existants (z≠0) sur l'image affichée sur l'écran peuvent être atténués en multipliant par exemple la valeur z par un coefficient a prédéfini inférieur à 1: z - a.z. Par exemple, a=0,9. 'z' étant un entier, on applique z - sign(z).La.z], où sign(x) retourne le signe de 'x' et Li est la fonction arrondie à l'entier inférieur, afin d'assurer une convergence vers l'image de référence plane (z=0) A noter que la valeur 'z' peut être bornée, par exemple z E [-50 pixels; zmax=50 pixels] lorsque x et y (coordonnées respectivement selon l'axe X et l'axe Y) varient respectivement sur [0; 320] pixels et [0; 480] pixels. Dans cet exemple, il faut 3,7 secondes pour effacer une information de relief maximal (3,7 - -log(zmax)/log(a) x période). L'étape El 06 marque la fin du traitement de la figure 4. La figure 5 illustre les traitements réalisés au niveau de l'un quelconque des terminaux communiquant lorsque l'utilisateur de ce terminal interagit sur l'écran tactile 12 pour communiquer par message non verbal. Partant de l'état d'attente (E200) correspondant à l'étape E106 ci-dessus, un utilisateur interagit, à l'étape E202, à l'aide de son doigt, sur l'écran tactile 12 de son terminal et y dessine une forme exprimant son humeur de l'instant. Comme expliqué précédemment, le contrôleur d'écran tactile génère, de façon classique, des données brutes d'interaction au fur et à mesure du dessin. Ces données d'interaction écran sont connues sous la terminologie d'événements de toucher ou "touch events" et indiquent les coordonnées de la zone d'appui touchée par le doigt. La décomposition d'un événement d'interaction en ensemble d'événements élémentaires de toucher dépend de la fréquence d'acquisition de ces informations par le contrôleur d'écran tactile. Plus cette fréquence est élevée, meilleure est l'interactivité mais plus grande est la quantité d'événements de toucher générés à transmettre selon l'invention. Différents types d'événements sont identifiés par le contrôleur d'écran, par exemple un clic (touch click), un appui (touch down), un déplacement (touch move) ou une gestuelle prédéfinie (touch gesture). A titre illustratif, un déplacement élémentaire du point (previousX,previousY) vers le point (newX,newY) pendant une période d'acquisition est récupéré sous la forme: InputTouchEvent { uint8 newX uint8 newY uint8 previousX uint8 previousY } où les coordonnées sont codées sur des entiers de 8 bits. Une convention de valeurs peut être prédéterminée: 0 signifiant une position haute 15 ou gauche et 255 signifiant une position basse ou droite. Un appui sur un point correspond à: (previousX,previousY) = (newX,newY). Une interaction, composées d'événements de toucher élémentaires, est alors mémorisée dans l'objet suivant: 20 InputEvent { uint32 time uint32 duration uint8 numTouches InputTouchEvent touches[numTouches] 25 } où "time" indique un instant par rapport à un instant to généralement défini par le premier événement (horodaté) d'un message à transmettre comme décrit par la suite, "duration" indique la durée de l'événement d'interaction (pouvant être de quelques secondes), "numTouches" indique le nombre 30 d'événements élémentaires de toucher composant l'interaction et "touches" est un tableau reprenant les différents événements élémentaires InputTouchEvent. On rappelle que, dans le cas d'un écran tactile multi-touches, plusieurs objets InputElement peuvent se chevaucher dans le temps et être générés sensiblement simultanément. Pour permettre une interactivité forte entre les utilisateurs, les événements InputEvent peuvent être créés toutes les secondes si l'interaction correspondante de l'utilisateur dure plusieurs secondes. Les événements InputEvent d'interaction sont ensuite mémorisés dans une mémoire tampon du terminal 101 de l'utilisateur A, à l'étape E204. Tant que le nombre de données mémorisées dans la mémoire tampon n'atteint pas une valeur seuil ou qu'un délai d'attente n'a pas expiré depuis le premier événement mémorisé (test E206), on poursuit l'acquisition des événements (E202). Le délai d'attente est choisi pour garantir une communication (quasi) temps réel, par exemple le délai vaut 1/25s. Le nombre seuil d'éléments est, quant à lui, choisi pour limiter la taille des messages à envoyer, par exemple ce seuil vaut cinq événements InputEvent. Sinon (seuil atteint ou délai expiré), on procède à l'envoi des 15 données d'interaction écran mémorisées dans la mémoire tampon, à l'aide d'un message du protocole XMPP, au cours des étapes E208 à E214. La mise en mémoire tampon permet de regrouper plusieurs événements d'interaction au sein d'un même message XMPP et ainsi d'éviter de générer un trafic inutile en transmettant chacun de ces événements dans un 20 message indépendant. Bien entendu, les événements d'un même message sont de préférence suffisament simultanés pour garantir un traitement et un affichage temps réel. Le délai d'attente, par exemple 1/25 s, permet de limiter tout retard perceptible dans l'affichage. 25 A l'étape E208, les événements d'interaction mémorisés dans la mémoire tampon sont mis dans un même objet informatique nommé Strokesdata: Strokes-data { uintl6 numEvents 30 InputEvent events[numEvents] ] listant l'ensemble des événements InputEvent (numEvents étant leur nombre). Les données mémorisées dans cet objet sont essentiellement des valeurs numériques entières. A noter que l'instant to évoqué précédemment se définit par rapport à l'instant du premier événement InputEvent listé dans l'objet Strokes-data. A l'étape E210, cet objet est codé dans un format binaire, notamment chaque valeur numérique entière est codée en base 64. Les données encodées sont alors insérées, à l'étape E212, dans un message XMPP de la session de messagerie instantanée entre les utilisateurs A et B, notamment au niveau d'un élément XML ayant la balise : base64(strokes-data) Comme on le constate dans cet exemple, les données d'interaction écran (ici Strokes-data) sont transmises au sein d'un seul élément XML . Ainsi, grâce au codage binaire mis en place, on évite de démultiplier le nombre de balises utilisées dans le message pour transmettre chacun des événements InputEvent ou InputTouchEvent. Il en résulte un volume de données plus faible, satisfaisant notamment aux contraintes de débit du protocole XMPP établies à 2 kilo-octets par seconde. A l'étape E214, le message ainsi créé est transmis à l'utilisateur B via le serveur Jabber 32 pour que l'affichage de cet utilisateur soit mis à jour en tenant compte de l'interaction de l'utilisateur A, comme on le décrit par la suite en référence à la figure 7. A noter que si, à l'expiration du délai, aucune donnée d'interaction n'est présente dans la mémoire tampon, aucun message n'est créé et transmis. La figure 6 montre différents messages XMPP transmis pour former le "S" de la figure 1. On observe que les identifiants des messages successifs (stanza3, stanza4, etc.) sont incrémentés de 1 afin de permettre un traitement chronologique au niveau du terminal récepteur de ces messages, ici "utilisateurB". Les données d'interaction écran sont également traitées localement sur le terminal de l'utilisateur A, pour mettre à jour son propre affichage (étape E216 décrite ci-après en lien avec la figure 8). A noter que cette étape E216 est généralement réalisée en parallèle des étapes E210 à E214. Elle peut toutefois être mise en oeuvre ultérieurement, voire dès la production de chaque événement d'interaction InputEvent (E202) afin d'offrir une mise à jour de l'affichage plus rapide (affichage "temps réel"). Suite aux étapes E214 et E216, le terminal 101 retourne dans l'état d'attente E200. La figure 7 illustre le traitement, au niveau d'un des terminaux d'utilisateur, lors de la réception d'un message XMPP comprenant des données 10 d'interaction écran (Strokes-data codées en base 64). Partant de l'état d'attente (E300) correspondant aux étapes E106/E200 ci-dessus, le terminal 102 de l'utilisateur B reçoit un message XMPP en provenance de l'utilisateur A (étape E302). L'application de messagerie instantanée exécutée sur le terminal 15 récupère, du message reçu, les données codées dans la balise , puis les décode (étape E304). Ces données d'interaction écran Strokes-data décodées provenant de l'utilisateur A sont alors traitées localement lors de l'étape E306 similaire à l'étape E216 et décrite ci-après en lien avec la figure 8. 20 Suite à l'étape E306, le terminal 102 retourne dans l'état d'attente E300. On décrit maintenant le traitement local, sur l'un quelconque des terminaux, des données d'interaction écran Strokes-data lors des étapes E216 et E306, en référence à la figure 8. 25 On rappelle ici que la contribution traitée lors de l'étape E216 est une contribution locale générant un relief d'affichage négatif (enfoncement ; z 0), A l'étape E400, les données d'interaction écran Strokes-data ou 30 InputEvent sont converties localement en données d'image graphique. Dans l'exemple illustratif, les données d'interaction écran sont converties en points (x,y,z) pour l'affichage où (x,y) correspond à un pixel d'affichage (là où a appuyé l'utilisateur) et 'z' correspond à l'information de relief fonction de la façon dont l'appui a été réalisé. De la sorte, l'image affichée sur l'écran "s'enfonce" sous le doigt de l'utilisateur et "émerge" sur l'écran de l'autre utilisateur. A noter que, du fait de l'affichage miroir de l'image entre les deux terminaux, une symétrie des pixels doit être opérée par rapport à l'axe A (voir figure 10) pour la contribution de l'utilisateur distant (étape E306): (x,y) - (320- x, y). Cette conversion traite séparément chaque interaction et donc la zone d'appui correspondante. On connaît, des données d'interaction écran générées pour chaque événement de toucher, le point actif et son éventuel déplacement, noté D, fourni par le vecteur (newX-previousX, newY-previousY). A partir de ce vecteur, il est aisé de déterminer la vitesse de déplacement élémentaire V=D/période d'acquisition. Cette vitesse ainsi que les coordonnées du point actif sont également traduite dans le référentiel d'affichage par une simple règle de trois (X,Y détectés sont compris entre 0 et 255, alors que x,y affichés dépendent du nombre de pixels selon chaque dimension de l'écran d'affichage). Ainsi pour chaque zone d'appui, la conversion E400 consiste à déterminer le profil de 'z' sur cette zone et éventuellement le long de son déplacement. Comme rappelé ci-dessus, le signe de 'z' est fonction de la nature de la contribution (locale ou distante). L'amplitude de cette valeur, bornée par ailleurs, est fonction de la durée d'appui ("duration" de l'lnputEvent correspondant) lors d'un appui maintenu (touch down) et/ou de la vitesse V de déplacement pour un événement de type déplacement (touch move). Comme illustré sur la figure 9, plus l'appui est long ou la vitesse de déplacement faible, plus l'amplitude Izi de 'z' est grande afin d'afficher un enfoncement important. Sur cette figure, on a représenté le rendu (vue en section) en l'absence d'appui (Ao), d'un appui de 0,5s (A0,5), d'un appui de 2s (A2) et d'un appui de 4s (A4). Au-delà de 4s, la profondeur IZI=Zmax de l'enfoncement (ou de la protrusion le cas échéant) n'augmente plus. Un comportement similaire peut être prévu en fonction de la vitesse V Pour offrir un affichage confortable pour les utilisateurs, on applique une fonction cosinus sur la largeur de la zone d'appui pour représenter un enfoncement/protrusion courbe. Comme illustré sur la figure 9, un maximum de 'z' est obtenu au centre de la ligne dessinée (le déplacement du point actif) et 'z' diminue progressivement (selon la fonction cosinus) pour être nulle aux bords de la zone. La largeur de zone peut être préfixée, déterminée à partir des données d'interaction écran (diamètre ou plus grande longueur de la zone) voire être fonction de la durée d'appui ou vitesse de déplacement (largeur d'autant plus faible que la vitesse est grande ou l'appui court). Le profil cosinus est en particulier appliqué dans le sens de la largeur de la zone, perpendiculaire au déplacement D. A l'issue de l'étape E400, on dispose ainsi d'une pluralité de points (x,y,z) constituant un tracé de la contribution de l'utilisateur. On rappelle que z 0 pour une contribution à distance (protrusion). A l'étape E402, on combine ces données d'affichage (x,y,z) déduites des données d'interaction écran Strokes-data, avec les données d'affichage correspondant à l'image actuellement à l'écran. On dispose déjà en mémoire, par exemple de la carte graphique, des valeurs 'z' pour chacun des pixels (x,y) d'affichage. On note ces valeurs zactuel. On réalise alors une passe sur l'ensemble des pixels à afficher en additionnant, pour chaque pixel, la valeur zactuel avec la valeur z calculée à l'étape E400. Grâce à la convention de signe adoptée, les contributions d'un utilisateur viennent s'additionner dans le temps, et les contributions des deux utilisateurs se soustraient. En particulier, on pondère la valeur z calculée à l'étape E400 lorsque zactuel est de signe opposé à z calculée (correspondant à une contribution inverse de ce qui est affiché): zactuel - zactuel + (3.z lorsque Zactuel•z Notamment 0 On rappelle par ailleurs que périodiquement zactuei f a.zactuei. Cette mise à jour peut notamment être appliquée lors de l'étape E402. Une fois que tous les pixels ont été traités, la nouvelle image calculée est affichée (étape E404) sur l'écran avec la texture prédéfinie. On note que les étapes E216 et E306 sont généralement simultanées (ou proches, moyennant le temps de transmission du message XMPP), de telle sorte que le traitement de la figure 8 provoque une mise à jour simultanée de l'affichage sur les deux terminaux, pour afficher toute nouvelle contribution (avec effet miroir d'un terminal à l'autre). Bien entendu, si des données d'interaction écran locales et des données d'interaction écran reçues sont générées en même temps, leur traitement par un même terminal lors des étapes E216 et E306 est réalisé simultanément. C'est pourquoi, lors de l'étape E402 de combinaison des contributions de chaque utilisateur, il peut être prévu de comparer les deux contributions aux fins d'identifier si une même zone est activée par les deux utilisateurs en même temps (en tenant compte de l'horodatage to des données d'interaction). La notion de "même zone" tient également compte de l'inversion de l'image entre les deux utilisateurs. Dans notre exemple et comme illustré par la figure 10, une "même zone" correspond à une zone ZA pour l'un des utilisateurs et la zone symétrique ZB par rapport à l'axe vertical central A pour l'autre utilisateur. En outre, une même zone est activée si les deux utilisateurs maintiennent simultanément, pendant au moins une durée prédéfinie (par exemple 0,5 seconde), un appui sur des zones dont les centres sont distants de moins d'une distance seuil (par exemple 25 pixels) compte tenu de la symétrie évoquée précédemment. Dans le cas où une "même zone" active est détectée, le terminal 10 est mis en vibration pour indiquer un comportement similaire entre les deux utilisateurs. En variante à la vibration, un son peut être émis ou un changement de couleur ou texture de l'image peut être opéré. Par ailleurs, d'autres conditions d'activation de la "même zone" peuvent être introduites, par exemple le fait que l'image doit être complètement plane (donc sans enfoncement ni protrusion) pendant ladite durée prédéfinie. Dans un mode de réalisation de l'invention, on prévoit des moyens d'effacement des contributions sur l'image affichée. Cet effacement consiste principalement en un aplanissement de l'image vers l'image de référence correspondant à la "membrane élastique" au repos. Il peut être mis en oeuvre en soufflant dans le microphone du terminal type téléphone mobile, de sorte à atténuer les effets de relief et donc les contributions. Pour ce faire, l'application de communication non verbale comprend un module d'écoute du microphone et compare l'intensité du signal généré par le microphone avec des valeurs seuil afin d'obtenir, au-delà d'une première valeur seuil de déclenchement, des coefficients de multiplication (inférieurs à 1) par lesquels on multiplie périodiquement l'image affichée (l'amplitude de chaque point). Ainsi, plus on souffle fort, plus le coefficient utilisé peut être faible de sorte à aplanir au plus vite l'image. Ce mécanisme permet d'effacer et réinitialiser l'image affichée sur les deux terminaux, plus rapidement qu'en attendant l'atténuation du relief dans le temps (voir étape E106). Cet effacement peut s'accompagner d'un changement de couleur ou de texture de l'image affichée, par exemple vers des couleurs dites "froides" telles que le bleu ou le blanc. Dans un mode de réalisation, des informations externes peuvent être utilisées pour modifier l'affichage. A titre d'exemple, la couleur ou la texture d'affichage de l'image peut varier en fonction de l'heure du jour présente dans chacun des terminaux: couleurs "froides" la nuit, couleurs "chaudes" au coucher et lever du soleil et couleurs intermédiaires en milieu de journée. Cela permet de tenir compte et de restituer l'environnement dans lequel l'utilisateur évolue lors des interactions. Une amélioration de la communication non verbale est ainsi obtenue. Egalement, chaque terminal peut disposer de moyens de localisation et d'un accès à un service de météorologie de sorte à déterminer la météo locale. Les couleurs d'affichage du fond de l'image peuvent encore être modifiées en fonction de cette information de météo locale, enrichissant l'interaction dans les échanges entre utilisateurs. Bien que décrit en lien avec un réseau 30 de type téléphonie mobile, l'invention peut s'appliquer à d'autres types de réseau et de terminaux 10 adaptés, par exemple à un réseau informatique et des terminaux informatiques. Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas, notamment en ce qui concerne les divers équipements évoqués. Notamment, la session de messagerie instantanée établie lors du traitement de la figure 4 peut être également utilisée pour transmettre des messages verbaux en plus des messages non verbaux selon l'invention comme expliqué ci-après. Cela est possible est incluant, dans les messages XMPP, des balises de texte classiques, par exemple , en plus des balises . Par ailleurs, pour réaliser une communication selon l'invention entre un plus grand nombre d'utilisateurs, les messages XMPP comprenant les données d'interaction écran sont dupliqués pour chacun des multiples autres utilisateurs et transmis vers ceux-ci par le(s) serveur(s) Jabber. La contribution de chaque utilisateur peut être affichée sous forme de couleur ou par déformation (enfoncement par exemple) d'une forme ayant un état de repos (par exemple un cube régulier) selon une direction dédiée à l'utilisateur. A titre d'exemple, un polyèdre à N faces permet de faire interagir, entre eux, N utilisateurs, chacun ayant "sa" face sur laquelle il crée des enfoncements susceptibles d'interagir avec les enfoncements des autres utilisateurs. Des fonctions de navigation 3D autour du polyèdre permettent de visualiser plus clairement les contributions de chacun. REVENDICATIONS1. Procédé de communication par messages non verbaux entre un premier terminal (101) et au moins un deuxième terminal (102) munis chacun d'un écran tactile (12), comprenant les étapes consistant à : - générer (E202, E208) des données d'interaction écran (Strokesdata, InputEvent, InputTouchEvent) représentatives d'au moins une action de contact d'un utilisateur sur l'écran tactile dudit premier terminal (101) ; - transmettre (E214) lesdites données d'interaction écran audit au moins un deuxième terminal (102) au travers d'un réseau de communication (30); - sur chacun desdits premier et deuxième terminaux (101, 102), convertir (E400) lesdites données d'interaction écran (Strokes-data, InputEvent, InputTouchEvent) en données d'image graphique (z) correspondant à ladite au moins une action de contact et combiner (E402) lesdites données d'image graphique (z) avec des données d'une image graphique déjà affichée (zactuei) sur l'écran tactile du terminal de sorte à mettre à jour (E216, E306, E404) l'affichage de l'image graphique sur le terminal. 2. Procédé selon la revendication 1, dans lequel lesdites données d'interaction écran sont des événements de toucher générés par le système de contrôle de l'écran tactile en réponse à ladite au moins une action de contact sur l'écran tactile (12) dudit premier terminal (101). 3. Procédé selon la revendication 1, dans lequel lesdites données d'interaction écran sont transmises au cours d'une session de messagerie instantanée basée sur le protocole XMPP. 4. Procédé selon la revendication 3, dans lequel lesdites données d'interaction écran sont encodées selon un format binaire (base64), à l'intérieur d'un élément XML ( ) d'un message XMPP (stanza3, stanza4). 5. Procédé selon la revendication 3 ou 4, comprenant une étape de mémorisation (E204), dans une mémoire tampon (53), d'une pluralité de données d'interaction écran correspondant à une pluralité d'événements de toucher sur l'écran tactile (12) avant transmission (E214) de cette pluralité de données d'interaction écran au sein d'un même message du protocole XMPP. 6. Procédé selon la revendication 5, dans lequel ladite pluralité d'événements de toucher comprend des événements d'interaction simultanée (InputEvent) sur un même écran tactile multi-touches. 7. Procédé selon la revendication 1, comprenant une étape consistant à générer (E202, E210), localement sur ledit deuxième terminal (102), des données d'image graphique à partir de données d'interaction écran locales (Strokes-data, InputEvent, InputTouchEvent) résultant d'au moins une action de contact d'un utilisateur sur l'écran tactile (12) dudit deuxième terminal (102); et dans lequel les données d'image graphique reçues dudit premier terminal (101) et les données d'image graphique générées localement sur ledit deuxième terminal (102) sont combinées de façon opposée (z>0, z 8. Procédé selon la revendication 7, dans lequel les images graphiques affichées (20) sur lesdits premier et deuxième terminaux sont des images tridimensionnelles miroir l'une de l'autre. 9. Procédé selon la revendication 1, dans lequel une donnée d'image graphique (z) à combiner et correspondant à au moins une coordonnée (x, y) issue de ladite action de contact est multipliée par un coefficient prédéfini (R) si cette donnée d'image graphique (z) est de signe opposé à la donnée d'image graphique (zactuei) ayant la même coordonnée dans l'image graphique déjà affichée. 10. Procédé selon la revendication 1, comprenant, les étapes suivantes : - générer (E202, E210) localement des données d'interaction écran (Strokes-data, InputEvent, InputTouchEvent) résultant d'au moins une action de contact d'un utilisateur sur l'écran tactile (12) dudit deuxième terminal (102) ; - si, pendant une période prédéfinie, lesdites données d'interaction écran générées localement et les données d'interaction écran dudit premier terminal (101) reçues par ledit deuxième terminal correspondent sensiblement à une même zone (ZA, ZB) de l'image à afficher, générer un signal sensoriel au niveau dudit deuxième terminal. 11. Terminal (101) de communication par messages non verbaux comprenant : - un écran tactile (12) apte à générer des données d'interaction écran locales (Strokes-data, InputEvent, InputTouchEvent) représentatives d'au moins une action de contact d'un premier utilisateur ; - un moyen de communication (57) apte à recevoir, d'au moins un deuxième terminal (102), des données d'interaction écran (Strokes-data, InputEvent, InputTouchEvent) représentatives d'au moins une action de contact d'un deuxième utilisateur sur un écran tactile dudit deuxième terminal ; - un moyen de conversion pour convertir (E400) lesdites données d'interaction écran générées localement et/ou reçues en données d'image graphique locales et/ou reçues (z) ; et - un moyen de combinaison pour combiner (E402) ces données d'image graphique locales et/ou reçues avec des données d'une image graphique déjà affichée sur l'écran tactile du terminal de sorte à mettre à jour (E216, E306, E404) l'affichage de l'image graphique sur ce terminal. 12. Terminal selon la revendication précédente, dans lequel ledit moyen de communication est également apte à transmettre, au sein d'une session XMPP établie avec ledit autre terminal, les données d'interaction écran générées locales. 13. Système de communication par messages non verbaux comprenant : - un serveur apte à établir une session de messagerie instantanée entre un premier (101) et un au moins deuxième (102) terminal ; - au moins un premier et un deuxième terminal selon l'une des revendications 11 ou 12, aptes à s'échanger des données d'interaction écran (Strokes-data, InputEvent, InputTouchEvent) au moyen de ladite session de messagerie instantanée. 14. Système selon la revendication précédente, le système étant configuré de sorte que les données d'interaction écran échangées entre les deux dispositifs sont codées sous forme binaire (base64) à l'intérieur d'un élément XML ( ) d'un message XMPP. 15. Produit programme d'ordinateur lisible par un microprocesseur, comprenant des instructions pour la mise en oeuvre du procédé de communication conforme à l'une des revendications 1 à 10, lorsque ce programme est chargé et exécuté par le microprocesseur.