Brevet FR2950774A1 — publié le 20110401

Procédé de gestion de messages par un serveur, produit programme d'ordinateur, moyen de stockage et serveur correspondants. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des systèmes de messagerie. Plus précisément, l'invention concerne un service de messagerie Hypertext (ou « HTMS » pour « Hypertext Messaging Service » en anglais). Plus précisément encore, l'invention concerne une technique de gestion de messages par un serveur, permettant de gérer des échanges de messages riches entre des terminaux de communication. Par messages riches, on entend des messages comprenant des données qui appartiennent au groupe des données multimédia telles que du texte, des images, de la vidéo et de la musique. L'invention s'applique notamment, mais non exclusivement, au cas où les terminaux de communication sont des téléphones mobiles et où le serveur est un serveur web du réseau Internet. 2. ARRIÈRE-PLAN TECHNOLOGIQUE On connaît plusieurs systèmes de messagerie permettant à des individus de communiquer (d'échanger des messages) de manière asynchrone. Un premier système connu est le système de messagerie électronique. Le système de messagerie électronique permet à un individu d'envoyer un courrier électronique (ou courriel) à un autre individu, via un réseau informatique (par exemple le réseau Internet). Le système de messagerie électronique est bien connu de l'Homme du métier et n'est donc pas décrit ci-après. De plus en plus de terminaux mobiles peuvent envoyer et recevoir des courriels texte et HTML. Un courriel texte est un message contenant uniquement des caractères alphanumériques. Un courriel texte n'offre donc aucune richesse de présentation. En revanche, un courriel HTML est un message beaucoup plus riche du point de vue de la mise en forme. En effet, il est possible d'intégrer, par exemple, des images fixes ou animées dans un courriel HTML. Bien que les terminaux mobiles actuels présentent de nombreux avantages, notamment en termes de puissance d'affichage, ils n'offrent cependant pas à l'utilisateur la même qualité de présentation qu'un ordinateur personnel. En effet, il a été constaté que les présentations des courriels HTML sur les terminaux mobiles sont dégradées. Un second système connu est le service SMS (pour « Short Message Service » en anglais). Généralement, un SMS est créé à partir d'un téléphone portable, et consiste en la saisie d'un court message textuel. La simplicité de ce second système de messagerie fait qu'il fonctionne sur tout type de téléphone mobile. Le service SMS est bien connu de l'Homme du métier et n'est donc pas décrit ci-après. Un SMS n'offre aucune richesse de présentation et ne peut contenir plus de 160 caractères. L'utilisation d'un SMS pour véhiculer un message riche n'est donc pas envisageable. Avec le service SMS, si un individu A souhaite envoyer un même message à deux individus B et C, le téléphone mobile de l'individu A transmet un SMS vers le téléphone mobile de l'individu B et un SMS vers le téléphone mobile de l'individu C. Ainsi, deux SMS indépendants sont transmis. La conséquence à cela est que l'individu B ne sait pas que le message de l'individu A a été envoyé à l'individu C. Ainsi, si l'individu B décide de répondre au message de l'individu A, il transmettra un SMS qu'à l'individu A, sans pouvoir en informer naturellement l'individu C. En conséquence, le service SMS est mal adapté au cas où un individu souhaite mettre en oeuvre une conversation impliquant plusieurs individus. Un troisième système connu est le service MMS (pour « Multimedia messaging service » en anglais). Le service de messagerie multimédia MMS est assez proche du service SMS. En effet, le service MMS permet d'écrire des messages à des individus à partir de son téléphone portable. Contrairement à un SMS, un MMS est capable de véhiculer des médias tels que, par exemple, les images, la vidéo et le son. Cependant, les medias utilisables dans un MMS sont juxtaposés. En d'autres termes, ces medias peuvent être vus comme un ensemble de pièces jointes qui peuvent être obtenues par téléchargement. Un inconvénient majeur du service MMS réside donc dans le fait qu'il ne permet pas de construire des pages web riches, comme cela peut être fait avec un courriel HTML. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. Plus précisément, dans au moins un mode de réalisation de l'invention, un objectif est de fournir une technique de gestion de messages qui permette à des terminaux de communication de créer simplement et de restituer efficacement des messages riches. Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de fournir une telle technique qui soit compatible avec tous les téléphones mobiles existants ayant un accès réseau. Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de mettre en oeuvre une telle technique qui permette d'établir des conversations impliquant plusieurs individus. Au moins un mode de réalisation de l'invention a également pour objectif de fournir une telle technique qui permette d'accéder rapidement à un historique de messages échangés pour une conversation donnée. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de gestion de messages par un serveur, ledit procédé comprenant les étapes suivantes : - obtention d'un message à restituer créé à partir d'un terminal émetteur ; - transmission dudit message à restituer vers au moins un terminal destinataire, Le serveur effectue les étapes suivantes : a) enregistrement dudit message à restituer dans une ressource accessible par ledit au moins un terminal destinataire ; b) génération d'un lien d'accès à ladite ressource ; c) transmission audit au moins un terminal destinataire, selon un premier protocole de communication prédéterminé, d'un message d'avertissement contenant ledit lien d'accès ; d) sur réception d'une requête d'accès, basée sur ledit lien et provenant dudit au moins un terminal destinataire, transmission audit au moins un terminal destinataire, selon un second protocole de communication prédéterminé, de ladite ressource contenant ledit message à restituer, ledit second protocole de communication étant différent dudit premier protocole de communication. Ainsi, il est proposé de notifier à un terminal destinataire la présence d'un message à restituer, en lui transmettant une notification, appelée par la suite message d'avertissement. Le message d'avertissement est utilisé comme un moyen de transport d'un lien d'accès à une ressource contenant le message à restituer. Le serveur génère de manière dynamique et automatique un lien unique d'accès à chaque fois qu'un message à restituer est enregistré dans la ressource. Le message d'avertissement est transmis vers le terminal destinataire selon un protocole de communication adapté à la transmission de messages simples. Comme on le verra dans la suite de la description, le message d'avertissement est par exemple transmis selon le protocole SMS. Dans ce cas particulier, le message d'avertissement est un SMS. Après réception du message d'avertissement par le terminal destinataire, un utilisateur du terminal destinataire, qui souhaite prendre connaissance du message à restituer, active le lien d'accès, ce qui a pour effet que le terminal destinataire envoie une requête d'accès au serveur. Sur réception de la requête d'accès, le serveur transmet au terminal destinataire la ressource contenant le message à restituer. La ressource est transmise vers le terminal destinataire selon un protocole de communication adapté à la transmission de messages riches. Comme on le verra dans la suite de la description, la ressource est par exemple transmise selon le protocole HTTP. Dans ce cas particulier, la ressource est une page web mobile. Ainsi, la technique proposée permet de créer et de restituer des messages riches. Le terminal émetteur peut être un téléphone mobile ou un ordinateur personnel. De même, le terminal destinataire peut être un téléphone mobile ou un ordinateur personnel. Dans un mode de réalisation particulier, le serveur est un serveur web. De façon avantageuse, ledit premier protocole de communication appartient au groupe comprenant : - le protocole XMPP, permettant de transmettre un message instantané ; - le protocole SMTP, POP ou IMAP, permettant de transmettre un courrier électronique , - le protocole SMS, permettant de transmettre un message court. Ainsi, le message d'avertissement peut, par exemple, prendre la forme d'un SMS, d'un courriel texte, ou bien encore d'une notification générée par tout type de messagerie instantanée. Avantageusement, ledit second protocole de communication appartient au groupe comprenant les protocoles HTTP, HTTPS et WAP. Dans un mode de réalisation préférentiel, ledit lien d'accès est une adresse URL pour ladite ressource partagée. De manière préférentielle, ladite ressource est une page d'un site web pour les terminaux de radiocommunication. Ainsi, la ressource peut être considérée comme une capsule (page web mobile) contenant des données (conversation). Selon une caractéristique avantageuse, ladite étape de transmission audit au moins un terminal destinataire de ladite ressource comprend les étapes suivantes : - obtention d'au moins un paramètre de configuration associé audit terminal destinataire ; - modification de ladite ressource, en fonction dudit au moins un paramètre de configuration obtenu ; - transmission audit au moins un terminal destinataire, de ladite ressource modifiée. Ainsi, il est proposé de modifier le format d'affichage de la ressource en fonction des capacités de restitution du terminal destinataire. En d'autres termes, on obtient une ressource modifiée qui pourra s'afficher de manière optimale sur l'écran du terminal destinataire. On note que le contenu de la ressource n'est pas modifiée. De cette façon, on garantit un affichage optimal de la ressource contenant le message à restituer. De façon avantageuse, ladite étape d'obtention d'un message à restituer comprend les étapes suivantes : - obtention d'un formulaire de création de message, rempli par un utilisateur dudit terminal émetteur ; - création dudit message à restituer à partir dudit formulaire de création de message. Ainsi, il est proposé de créer un message à restituer à partir d'un formulaire prédéfini. Dans un premier mode de réalisation particulier, le formulaire est transmis depuis le serveur vers le terminal émetteur. Dans ce cas, le formulaire peut être une page web mobile. Dans un second mode de réalisation particulier, le formulaire est obtenu par le lancement d'une application embarquée sur le terminal émetteur. Lorsque le formulaire a été rempli et validé par l'utilisateur, les données saisies dans le formulaire sont transmises vers le serveur. Avantageusement, dans l'étape d), la ressource transmise contient en outre une fonction de réponse, qui quand elle est activée par un utilisateur dudit au moins un terminal destinataire, permet au serveur d'obtenir une réponse créée à partir dudit au moins un terminal destinataire. Sur obtention de ladite réponse, le serveur effectue une étape de transmission de ladite réponse, vers ledit terminal émetteur, l'étape de transmission de ladite réponse comprenant les étapes suivantes : enregistrement de ladite réponse dans ladite ressource ; génération d'un lien d'accès à ladite ressource ; transmission audit terminal émetteur, selon le premier protocole de communication prédéterminé, d'un message d'avertissement contenant ledit lien d'accès; h) sur réception d'une requête d'accès, basée sur ledit lien et provenant dudit terminal émetteur, transmission audit terminal émetteur, selon le second protocole de communication prédéterminé, de ladite ressource contenant ladite réponse. La messagerie de l'invention est bidirectionnelle puisqu'elle permet à un ou plusieurs terminaux destinataires de répondre à un message du terminal émetteur. La ou les réponses du ou des terminaux destinataires sont enregistrées sur la même ressource que celle contenant le message à restituer crée à partir du terminal e) f) g) 25 30 émetteur. De cette façon, il est possible d'enregistrer une conversation (échange de messages entre plusieurs individus) dans une ressource. Selon une caractéristique avantageuse, dans l'étape d), la ressource transmise contient en outre une fonction d'historique, qui quand elle est activée par un utilisateur dudit au moins un terminal destinataire, permet de requérir auprès du serveur la transmission audit au moins un terminal destinataire, selon le second protocole de communication prédéterminé, d'information(s) relative(s) à au moins un message ou une réponse échangé(e) entre le terminal émetteur et ledit audit au moins un terminal destinataire. Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur qui comprend des instructions de code de programme pour la mise en oeuvre du procédé précité (dans l'un quelconque de ses différents modes de réalisation), lorsque ledit programme est exécuté sur un ordinateur. Dans un autre mode de réalisation, l'invention concerne un moyen de stockage 15 comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé précité (dans l'un quelconque de ses différents modes de réalisation). Dans un autre mode de réalisation, il est proposé un serveur comprenant des moyens de gestion de messages et comprenant : - des moyens d'obtention d'un message à restituer créé à partir d'un terminal émetteur ; - des moyens de transmission dudit message à restituer vers au moins un terminal destinataire, Les moyens de transmission dudit message à restituer, vers au moins un terminal destinataire, comprennent : - des moyens d'enregistrement dudit message à restituer dans une ressource accessible par ledit au moins un terminal destinataire ; - des moyens de génération d'un lien d'accès à ladite ressource ; - des moyens de transmission audit au moins un terminal destinataire, selon un premier protocole de communication prédéterminé, d'un message d'avertissement contenant ledit lien d'accès ; 20 25 30 - des moyens de réception d'une requête d'accès, basée sur ledit lien et provenant dudit au moins un terminal destinataire ; - des moyens de transmission audit au moins un terminal destinataire, selon un second protocole de communication prédéterminé, de ladite ressource contenant ledit message à restituer, ledit second protocole de communication étant différent dudit premier protocole de communication. 5. LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : - la figure 1 illustre un exemple d'un système de communication dans lequel peut être mis en oeuvre le procédé de gestion de messages, selon un mode de réalisation particulier conforme à l'invention ; - la figure 2 présente un organigramme illustrant un mode de réalisation particulier du procédé de gestion de messages selon l'invention ; - la figure 3 illustre un exemple de formulaire de création de message ; - la figure 4 illustre un exemple de ressource contenant une fonction de réponse ; et - la figure 5 présente la structure simplifiée d'un mode de réalisation particulier d'un serveur HTMS selon l'invention. 6. DESCRIPTION DÉTAILLÉE La présente invention s'appuie sur la mise en oeuvre d'un serveur de service de messagerie Hypertext (ou serveur « HTMS », pour « Hypertext Messaging Service »). Le serveur HTMS de l'invention met en oeuvre un système de notification de présence 25 de messages riches à restituer, basé sur la transmission de messages simples véhiculant chacun un lien d'accès à une ressource contenant un ou plusieurs messages riches à restituer. Le serveur HTMS de l'invention met en oeuvre également un système d'adaptation de ressources permettant d'assurer que les messages riches s'affichent toujours correctement, quel que soit le terminal destinataire. 20 La figure 1 illustre un exemple d'un système de communication dans lequel peut être mis en oeuvre le procédé de gestion de messages, selon un mode de réalisation particulier conforme à l'invention. Dans cet exemple simplifié, le système comprend : - un réseau de communication 1 auquel est relié un terminal de communication 2 d'un utilisateur. Par souci de simplification de la description, on se limitera, dans toute la suite de ce document, à décrire le cas particulier où le terminal 2 est un terminal mobile comprenant un module de radiocommunication lui conférant la capacité de se connecter au réseau Internet via le réseau de communication 1. L'homme du métier étendra sans difficulté cet enseignement à un terminal fixe, par exemple, un ordinateur personnel connecté au réseau Internet via un modem ; - le réseau Internet 3 auquel est relié le serveur HTMS 4 de l'invention ; et - un réseau de communication 5 auquel est relié un terminal de communication 6 d'un autre utilisateur. Par souci de simplification de la description, on se limitera, dans toute la suite de ce document, à décrire le cas particulier où le terminal 6 est un terminal mobile comprenant un module de radiocommunication lui conférant la capacité de se connecter au réseau Internet via le réseau de communication 5. L'homme du métier étendra sans difficulté cet enseignement à un terminal fixe, par exemple, un ordinateur personnel connecté au réseau Internet via un modem. Dans la suite de la description, on se place dans le cas où le terminal mobile 2 est le terminal émetteur et le terminal mobile 6 le terminal destinataire. On présente maintenant, en relation avec la figure 2, un organigramme d'un algorithme de gestion de messages mis en oeuvre par le serveur HTMS 4, selon un mode de réalisation particulier de l'invention. Dans une étape El, le serveur HTMS 4 obtient un message à restituer créé à partir du terminal mobile 2. Pour créer un message à restituer à partir de son terminal mobile 2, l'utilisateur accède à un formulaire de création de message. Pour ce faire, dans un mode de réalisation particulier, l'utilisateur lance une application embarquée spécifique (par exemple J2ME) sur le terminal mobile 2. Dans un autre mode de réalisation particulier, l'utilisateur utilise le navigateur de son terminal mobile 2. Dans ce dernier cas, le terminal mobile 2 transmet vers le serveur HTMS 4 une requête d'obtention d'un formulaire de création de message. En réponse à cette requête, le serveur HTMS 4 transmet vers le terminal mobile 2 un formulaire de création de message, par exemple, selon le protocole http. La figure 3 illustre un exemple de formulaire 30 de création de message. Dans cet exemple, le formulaire 30 comprend un champ destinataire 301, un champ objet 302 dans lequel l'utilisateur indique un titre de conversation, et un champ message 303 dans lequel l'utilisateur saisi son message. Le champ destinataire 301 contient le ou les identifiants des destinataires du message à restituer. Dans un mode de réalisation particulier, l'utilisateur rempli le champ destinataire 301 en sélectionnant des destinataires enregistrés sur son terminal mobile 2. Dans un autre mode de réalisation particulier, l'utilisateur rempli le champ destinataire 301 en sélectionnant des destinataires enregistrés sur une base de contacts gérée par le serveur HTMS 4. La base de contacts gérée par le serveur HTMS 4 est une base de données partagée qui recense l'ensemble des personnes avec lesquelles l'utilisateur a eu au moins une conversation via le serveur HTMS 4. Par exemple, si Pierre écrit à Paul et Jacques, alors Paul trouvera Pierre et Jacques dans sa base de contacts. De même, Jacques verra Pierre et Paul. De façon avantageuse, la base de contacts permet de stocker des signatures associées aux utilisateurs. Dans une étape d'initialisation (non représentée), un utilisateur peut ouvrir un compte HTMS auprès du serveur HTMS 4, à partir d'un terminal de communication mobile ou fixe. Un compte HTMS comprend, par exemple, un nom d'utilisateur, un titre, un numéro de téléphone, une adresse électronique, une signature, et un ou plusieurs liens (par exemple, vers des téléphones et/ou des sites Internet mobile ou non). Lors de cette étape d'initialisation, l'utilisateur peut créer une signature en utilisant, par exemple, un outil de composition graphique dédié à la création de pages Internet pour les terminaux mobiles. Ainsi, lorsqu'un utilisateur créer un message à restituer, il peut insérer dans ce message sa signature. Le message à restituer est donc enrichi. Chaque utilisateur est en charge de sa propre signature. Ainsi, la base de contacts est sans cesse mise à jour. Dans l'exemple précité, si Pierre veut faire évoluer le logo (signature) de son entreprise, Paul et Jacques verront immédiatement ce nouveau logo. En d'autres termes, les contacts ne sont pas répliqués dans chacun des comptes (comme c'est le cas avec les contacts stockés sur un téléphone) mais sont stockés dans un espace partagé de la base de contacts. Ainsi, on associe un compte HTMS à chaque utilisateur du service HTMS. Chaque compte HTMS est associé à une liste de contacts. Lorsqu'un contact est présent dans deux bases distinctes, ce contact est partagé, en ce sens que les informations associées à ce contact ne sont pas répliquées dans chaque compte. On note que lorsque l'utilisateur sélectionne des destinataires enregistrés sur son terminal mobile 2, et que ces destinataires ne sont pas connus du serveur HTMS 4, le serveur HTMS 4 enregistre ces nouveaux destinataires dans sa base de contacts. Dans une étape E2, le serveur HTMS 4 enregistre le message à restituer dans une ressource accessible par le terminal mobile 6. Dans un mode de réalisation préférentiel, la ressource est une page d'un site web pour les terminaux mobiles. Dans une étape E3, le serveur HTMS 4 génère automatiquement un lien d'accès à la ressource. Dans un mode de réalisation préférentiel, le lien d'accès est une adresse URL. Dans une étape E4, le serveur HTMS 4 transmet au terminal mobile 6 un message d'avertissement contenant le lien d'accès généré à l'étape E3. Dans un mode de réalisation particulier, le message d'avertissement est un SMS. Ainsi, dans cet exemple, le serveur HTMS 4 transmet au terminal mobile 6 un SMS contenant le lien d'accès à la ressource, selon le protocole SMS. Dans un autre mode de réalisation particulier, le message d'avertissement est un courriel texte. Ainsi, dans cet exemple, le serveur HTMS 4 transmet au terminal mobile 6 un courriel texte contenant le lien d'accès à la ressource, selon le protocole SMTP. Dans un autre mode de réalisation particulier, le message d'avertissement est une notification (texte simple) générée par une système de messagerie instantanée. Ainsi, dans cet exemple, le serveur HTMS 4 transmet au terminal mobile 6 une notification contenant le lien d'accès à la ressource, selon le protocole XMPP. Dans une étape de configuration (non représentée), l'utilisateur du terminal mobile 6 sélectionne le ou les formats dans lesquels il souhaite recevoir les messages d'avertissement. Ainsi, lors de cette étape de configuration, l'utilisateur du terminal mobile 6 peut choisir de recevoir un message d'avertissement par SMS et/ou par courriel fixe et/ou par messagerie instantanée. Dans une étape E5, le serveur HTMS 4 reçoit une requête d'accès provenant du terminal mobile 6. Cette requête d'accès est générée par le terminal mobile 6 suite à l'activation, par l'utilisateur, du lien d'accès contenu dans le message d'avertissement reçu par le terminal mobile 6. Dans une étape E6, le serveur HTMS 4 obtient des paramètres de configuration associés au terminal mobile 6 (par exemple, la taille de l'écran d'affichage, le langage (ou markup) supporté, etc.). Dans un mode de réalisation particulier, le terminal mobile 6 insère dans la requête d'accès des paramètres de configuration. Ainsi, le serveur HTMS 4 extrait de la requête d'accès les paramètres de configuration. Dans un autre mode de réalisation particulier, le terminal mobile 6 insère dans la requête d'accès une donnée d'identification. Ainsi, le serveur HTMS 4 extrait de la requête d'accès la donnée d'identification et l'utilise pour rechercher dans une base de données dédiée des paramètres de configuration associés au terminal mobile 6. Dans une étape E7 le serveur HTMS 4 modifie le format d'affichage de la ressource (par exemple une page web mobile), en fonction des paramètres de configuration obtenus à l'étape E6. Dans un mode de réalisation particulier, les étapes E6 et E7 sont effectuées par un moteur de rendu (« Rendering Engine » en anglais) compris dans le serveur HTMS 4. Dans une étape E8 le serveur HTMS 4 transmet au terminal mobile 6 la ressource modifiée. Ainsi, le terminal mobile 6 reçoit une ressource modifiée qui est adaptée à ses capacités de restitution. De cette façon, la ressource contenant le message à restituer est restituée de manière optimale par le terminal mobile 6. Dans le cas où la ressource est une page web, le serveur HTMS 4 transmet au terminal mobile 6 la page web, selon le protocole HTTP. Le serveur HTMS 4 permet de mettre en oeuvre des communications bidirectionnelles. Ainsi, le terminal mobile 6 peut répondre au terminal mobile 2. Pour ce faire, l'utilisateur du terminal mobile 6 active une fonction de réponse disponible sur la ressource restituée par le terminal mobile 6. La figure 4 illustre un exemple de ressource restituée 40 contenant une fonction de réponse 401. Ainsi, en cas de réponse de la part du terminal mobile 6, le serveur HTMS 4 obtient, dans une étape E9, une réponse créée à partir du terminal mobile 6. Pour créer une réponse à partir de son terminal mobile 6, l'utilisateur active la fonction réponse 401, ce qui a pour effet d'ouvrir un champ réponse 402 (figure 4) dans la ressource (conversation). L'utilisateur rempli ensuite le champ réponse 402. Dans une étape E10, le serveur HTMS 4 enregistre la réponse dans la ressource partagée. Dans une étape E11, le serveur HTMS 4 génère automatiquement un nouveau lien d'accès à la ressource contenant la réponse. Dans une étape E12, le serveur HTMS 4 transmet au terminal mobile 2 un message d'avertissement (par exemple un SMS) contenant le lien d'accès généré à l'étape El 1. Dans une étape E13, le serveur HTMS 4 reçoit une requête d'accès provenant du terminal mobile 2. Cette requête d'accès est générée par le terminal mobile 2 suite à l'activation, par l'utilisateur, du lien d'accès contenu dans le message d'avertissement reçu par le terminal mobile 2. Ensuite, dans une étape E14 le serveur HTMS 4 transmet au terminal mobile 2 la ressource contenant la réponse du terminal mobile 6. Un utilisateur peut accéder à l'historique d'une conversation en activant une fonction d'historique (non représentée) disponible sur la ressource restituée par son terminal mobile. Ainsi, l'utilisateur peut requérir auprès du serveur HTMS 4 la transmission vers son terminal mobile des messages et des réponses échangées lors d'une conversation donnée. La figure 5 présente la structure simplifiée d'un serveur HTMS mettant en oeuvre le procédé de gestion de messages selon le mode de réalisation particulier décrit ci-dessus en relation avec la figure 2. Le serveur HTMS comprend une mémoire RAM 53, une unité de traitement 51, équipée par exemple d'un microprocesseur, et pilotée par un programme d'ordinateur stocké dans une mémoire ROM 52. A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire RAM 53 avant d'être exécutées par le processeur de l'unité de traitement 51. L'unité de traitement 51 reçoit en entrée un message à restituer 54 créer par un terminal émetteur. Le microprocesseur de l'unité de traitement 51 enregistre ce message à restituer 54 dans une ressource et génère un lien d'accès à la ressource, selon les instructions du programme 52, de manière à transmettre, vers un terminal destinataire, un message d'avertissement 55 contenant le lien d'accès à la ressource. Bien que l'invention ait été décrite ci-dessus en relation avec un nombre limité de modes de réalisation, l'homme du métier, à la lecture de la présente description, comprendra que d'autres modes de réalisation peuvent être imaginés sans sortir du cadre de la présente invention. Dans un mode de réalisation particulier, il est possible de mettre en oeuvre un mécanisme de gestion de crédits. Par exemple, pour pouvoir envoyer un message à restituer via le serveur HTMS, un utilisateur doit posséder des crédits. Ce nombre de crédits peut être illimité ou déterminé en fonction de règles de gestion prédéfinies. Par exemple, de telles règles de gestion peuvent être définies par un opérateur ou un annonceur utilisant le service HTMS. Dans un autre mode de réalisation particulier, il est possible de mettre en oeuvre un mécanisme de suivi d'état de conversation. Le serveur HTMS permet de mettre en oeuvre des conversations impliquant plusieurs individus. Ainsi, dans le cas où le serveur HTMS génère des liens d'accès du type URL, il est possible de détecter si le destinataire n'a lu aucun message, a lu ou pas le dernier message de la conversation. Une représentation de chacun de ces états peut alors se faire visuellement (couleurs spécifiques ou icônes pour chaque état). On note également que le serveur HTMS selon l'invention permet, par exemple, à une entreprise (banque, restaurant, magasin, etc.) de configurer une ressource destinée à être utilisée par un ensemble d'individus. En d'autres termes, l'entreprise peut insérer dans la ressource sa charte graphique, et plus particulièrement, son logo, son slogan, un menu personnalisé et une bannière publicitaire (cliquable). REVENDICATIONS1. Procédé de gestion de messages par un serveur, ledit procédé comprenant les étapes suivantes : obtention (El) d'un message à restituer créé à partir d'un terminal émetteur ; - transmission dudit message à restituer vers au moins un terminal destinataire, ledit procédé étant caractérisé en ce que ladite étape de transmission dudit message à restituer, vers au moins un terminal destinataire, comprend les étapes suivantes : a) enregistrement (E2) dudit message à restituer dans une ressource accessible par ledit au moins un terminal destinataire ; b) génération (E3) d'un lien d'accès à ladite ressource ; c) transmission (E4) audit au moins un terminal destinataire, selon un premier protocole de communication prédéterminé, d'un message d'avertissement contenant ledit lien d'accès ; d) sur réception d'une requête d'accès, basée sur ledit lien et provenant dudit au moins un terminal destinataire, transmission audit au moins un terminal destinataire, selon un second protocole de communication prédéterminé, de ladite ressource contenant ledit message à restituer, ledit second protocole de communication étant différent dudit premier protocole de communication. 2. Procédé selon la revendication 1, caractérisé en ce que ledit premier protocole de communication appartient au groupe comprenant : - le protocole XMPP, permettant de transmettre un message instantané ; - le protocole SMTP, POP ou IMAP, permettant de transmettre un courrier électronique ; - le protocole SMS, permettant de transmettre un message court. 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ledit second protocole de communication appartient au groupe comprenant les protocoles HTTP, HTTPS et WAP. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ledit lien d'accès est une adresse URL pour ladite ressource partagée. 5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ladite ressource est une page d'un site web pour les terminaux de radiocommunication. 6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ladite étape de transmission audit au moins un terminal destinataire de ladite ressource comprend les étapes suivantes : - obtention (E6) d'au moins un paramètre de configuration associé audit terminal destinataire ; - modification (E7) de ladite ressource, en fonction dudit au moins un paramètre de configuration obtenu ; - transmission (E8) audit au moins un terminal destinataire, de ladite ressource modifiée. 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ladite étape d'obtention d'un message à restituer comprend les étapes suivantes : - obtention d'un formulaire de création de message, rempli par un utilisateur dudit terminal émetteur ; - création dudit message à restituer à partir dudit formulaire de création de message. 8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que dans l'étape d), la ressource transmise contient en outre une fonction de réponse, qui quand elle est activée par un utilisateur dudit au moins un terminal destinataire, permet au serveur d'obtenir une réponse créée à partir dudit au moins un terminal destinataire, en ce que, sur obtention de ladite réponse, le serveur effectue une étape de transmission de ladite réponse, vers ledit terminal émetteur, et en ce que ladite étape de transmission de ladite réponse, vers ledit terminal émetteur, comprend les étapes suivantes : e) enregistrement (E l 0) de ladite réponse dans ladite ressource ; f) génération (E 11) d'un lien d'accès à ladite ressource ; g) transmission (E12) audit terminal émetteur, selon le premier protocole de communication prédéterminé, d'un message d'avertissement contenant ledit lien d'accès; h) sur réception d'une requête d'accès, basée sur ledit lien et provenant dudit terminal émetteur, transmission audit terminal émetteur, selon le second 30protocole de communication prédéterminé, de ladite ressource contenant ladite réponse. 9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que dans l'étape d), la ressource transmise contient en outre une fonction d'historique, qui quand elle est activée par un utilisateur dudit au moins un terminal destinataire, permet de requérir auprès du serveur la transmission audit au moins un terminal destinataire, selon le second protocole de communication prédéterminé, d'information(s) relative(s) à au moins un message ou une réponse échangé(e) entre le terminal émetteur et ledit audit au moins un terminal destinataire. 10. Produit programme d'ordinateur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé selon au moins une des revendications 1 à 9, lorsque ledit programme est exécuté sur un ordinateur. 11. Moyen de stockage lisible par ordinateur, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé selon au moins une des revendications 1 à 9. 12. Serveur comprenant des moyens de gestion de messages et comprenant : - des moyens d'obtention d'un message à restituer créé à partir d'un terminal émetteur ; - des moyens de transmission dudit message à restituer vers au moins un terminal destinataire, ledit serveur étant caractérisé en ce que lesdits moyens de transmission dudit message à restituer, vers au moins un terminal destinataire, comprennent : - des moyens d'enregistrement dudit message à restituer dans une ressource accessible par ledit au moins un terminal destinataire ; - des moyens de génération d'un lien d'accès à ladite ressource ; - des moyens de transmission audit au moins un terminal destinataire, selon un premier protocole de communication prédéterminé, d'un message d'avertissement contenant ledit lien d'accès ; - des moyens de réception d'une requête d'accès, basée sur ledit lien et provenant dudit au moins un terminal destinataire ; 25 30des moyens de transmission audit au moins un terminal destinataire, selon un second protocole de communication prédéterminé, de ladite ressource contenant ledit message à restituer, ledit second protocole de communication étant différent dudit premier protocole de communication.