FR2828368A1 - Procede de transmission et de restitution d'un message multimedia pour terminal mobile - Google Patents

Abstract

L'invention concerne un procédé de transmission et de restitution d'un message multimédia (6) entre une source et un terminal mobile (1) normalisé d'un réseau (2), le message multimédia reçu par le mobile étant traité de manière normalisée par au moins un programme de restitution (12) de message du terminal afin d'être restitué sur au moins une interface utilisateur, le message multimédia étant transmis dans une enveloppe (22) de message selon un protocole normalisé. Selon l'invention, on transmet dans l'enveloppe (22) le message multimédia (6) et on associe audit message multimédia au moins une instruction propriétaire (8, 9), et dans un terminal mobile dans lequel on a préalablement incorporé une routine propriétaire (5) de détection et un programme propriétaire de traitement (16) des messages, la routine détecte la présence de l'instruction propriétaire (8), transmet l'instruction et le message au programme de traitement, ledit programme de traitement exécutant l'instruction et envoyant le message à un moment défini par l'instruction vers le programme de restitution. Le message peut être stocké en mémoire (13). Des erreurs spécifiques peuvent être introduites dans l'enveloppe et/ou le message et détectées.

Description

<Desc/Clms Page number 1>

La présente invention concerne un procédé de transmission et de restitution d'un message multimédia pour terminal mobile. Elle a des applications dans le domaine de la télécommunication avec des appareils téléphoniques portables, assistants électroniques ou ordinateurs portables.

Les procédés et dispositifs utilisés dans les télécommunications cellulaires mobiles du type GSM, GPRS ou UMTS ou autres sont bien connus et normalisés. Les fonctionnalités des terminaux mobiles sont ainsi parfaitement définies. Les messages multimédia, c'est-à-dire le contenu : applications, script, code de programmation, format de restitution, texte, texte déroulant, vignette, liens Internet, images, animation, graphisme... ou tout autre type pouvant être restitué par une application possiblement normalisée existante dans le terminal, sont transmis selon un protocole spécifique normalisé par une voie de donnée, c'est-à-dire le contenant : SMS, USSD, session de transmission de données en commutation de circuit, Push GPRS (forçage), MMS... selon le mode de transport : GSM, GPRS, EDGE, UMTS..., et sont traités par une application qui interprète le message entrant.

L'application spécifique peut, par exemple, être un navigateur ou une application de streaming vidéo (lecteur vidéo capable de gérer la lecture de séquences résident sur des serveurs distants). Le navigateur est un produit développé par un éditeur spécifique, intégré par chaque constructeur de mobile. L'application ainsi intégrée prend contrôle des interfaces d'entrées/sorties du terminal dont écran d'affichage, haut-parleur, dispositif tactile, clavier, vibreur, diodes électroluminescentes, etc. Le navigateur est donc assimilé à une application propre au terminal mobile.

D'autre part il existe des procédés permettant d'envoyer des messages directement sur les fonds des écrans, en écran de veille ou en vignette des écrans des terminaux mobiles. Ces procédés mettent en oeuvre une application traitant à la fois la réception et la restitution du message et sont généralement d'ordre propriétaires. Ils obligent donc de la part de l'émetteur une parfaite identification du terminal utilisé par la cible réceptrice du message.

De tels procédés nécessitent que l'utilisateur effectue une demande préalable à l'envoyeur ou source. De tels procédés ne sont donc pas compatibles avec un service d'envoi de messages en masse sur un réseau de télécommunication normalisé car les utilisateurs, identifiés par carte SIM par exemple, pouvant à tout instant changer de terminal, le système d'envoi de messages en masse

<Desc/Clms Page number 2>

risquerait d'envoyer ces messages propriétaires à des terminaux incompatibles qui ne pourraient traiter convenablement le message entrant.

L'invention propose un procédé alternatif de transmission et de restitution d'un message multimédia qui permet d'ouvrir le terminal mobile à de nouvelles fonctionnalités en tirant partie du navigateur ou des programmes informatiques du mobile. Elle consiste, d'une part, à intégrer de nouvelles applications d'émission de messages propriétaires sur des réseaux normalisés, et, d'autre part, d'intégrer une application propriétaire de traitement de ces messages dans les terminaux mobiles normalisés tout en tirant partie des applications existantes et normalisées du réseau et du terminal, optimisant ainsi l'impact sur le réseau ainsi que la place mémoire dans les terminaux et permettant de faire coexister une application propriétaire dans des environnements de terminaux et réseaux normalisés.

L'invention se rapporte donc à un procédé de restitution de messages sur des organes de sortie (par exemple écrans, haut-parleurs, vibreurs...) de terminaux mobiles communicants, les messages étant en provenance d'une source autorisée du réseau de télécommunication mobile. Les messages à restituer peuvent être de toute nature (utilitaire, informatif, éditorial, promotionnel, publicitaire,...) et leur format est essentiellement interactif avec l'utilisateur du terminal et peut être textuel, graphique, animé ou lié à toutes les possibilités de restitution du terminal. Le procédé utilise les applications existantes dans le terminal mobile, tel qu'un navigateur, afin de restituer ces messages sur les organes de sortie du terminal à un ou à des moments selon un contexte ou un/des événements avec une fréquence, une durée ou d'autres paramètres fournis par au moins une instruction propriétaire liée au message et exécutée par un programme propriétaire ou, en l'absence de paramètre dans l'instruction propriétaire, avec des paramètres par défaut du procédé de restitution, lesdits paramètres, fournis ou par défaut, n'étant pas prévus par les applications de restitution existantes, généralement normalisées.

L'invention concerne donc un procédé de transmission et de restitution d'un message multimédia entre une source et un terminal mobile normalisé d'un réseau de télécommunication, le mobile comportant au moins une voie de réception, le message multimédia reçu par la voie de réception étant traité par au moins un programme de restitution de message du terminal afin d'être

<Desc/Clms Page number 3>

restitué sur au moins une interface utilisateur, le message multimédia étant transmis dans une enveloppe de message selon un protocole normalisé.

Selon l'invention, on transmet dans l'enveloppe le message multimédia et on associe audit message multimédia au moins une instruction propriétaire de détection et au moins une instruction propriétaire de restitution ou mixte, et dans un terminal mobile dans lequel on a préalablement incorporé une routine propriétaire de détection et un programme propriétaire de traitement des messages, la routine détecte la présence de l'instruction propriétaire de détection ou mixte, transmet au moins l'instruction propriétaire de restitution ou mixte et le message au programme propriétaire de traitement, ledit programme propriétaire de traitement exécutant l'instruction de restitution ou mixte et mettant à disposition à un moment défini par l'instruction propriétaire de restitution ou mixte, le message au programme de restitution.

L'instruction propriétaire de détection est une instruction uniquement destinée à activer la routine de détection et l'instruction propriétaire mixte est une instruction destinée entre autre à activer la routine de détection. Cette dernière peut également activer le programme propriétaire de traitement de message comme une instruction propriétaire de restitution. Le terme moment signifie à un temps donné ou selon un contexte ou un/des événements et, éventuellement, avec une fréquence, une durée ou d'autres paramètres portés ou signifiés par l'instruction.

Dans divers modes de mise en oeuvre de l'invention dans sa généralité, les moyens suivants pouvant être combinés selon toutes les possibilités de réalisations techniques, sont employés : - le choix du/des programmes de restitution dépend de l'instruction propriétaire de restitution ou mixte, - le message multimédia est stocké dans une mémoire du programme propriétaire de traitement avant sa mise à disposition à au moins un programme de restitution, le moment de sa mise à disposition dépendant d'un ou plusieurs des moyens suivants : du contenu de l'instruction propriétaire de restitution ou mixte, d'au moins une requête, d'au moins d'un événement prédéfini, - la mémoire du programme propriétaire de traitement peut stocker plusieurs messages avant mise à disposition à au moins un programme de restitution,

<Desc/Clms Page number 4>

- la mise à disposition des messages stockés par le programme propriétaire de traitement des messages est séquentielle, - la transmission s'effectue par enveloppe SMS, USSD, MMS ( Multimedia Messaging Service ), CSD (commutation de circuits), GPRS, UMTS ou autre moyen de transmission de données, - l'enveloppe de message est du type message court SMS ou équivalent, - chaque enveloppe peut véhiculer une partie de message, - chaque enveloppe peut véhiculer plusieurs messages et au moins une instruction propriétaire est associée à chaque message multimédia, - le message contient du code normalisé (WML, HTML, xHTML, sHTML, XML, java ou équivalents) interprété par un navigateur ou d'autres applications existantes dans le terminal, - le message multimédia comporte en outre au moins une instruction courte propriétaire, - on remplace les adresses (URL) initiales contenues dans les messages par des adresses simplifiées sous forme d'instructions courtes propriétaires avant l'envoi des messages vers le terminal et les adresses URL initiales et leurs adresses simplifiées respectives sont stockées dans des tables de re-direction à la source afin de rediriger les requêtes du navigateurs de l'utilisateurs vers les adresses initiales, - les informations ou scripts fréquemment retrouvés dans les messages sont remplacés à la source par des codes spécifiques sous forme d'instructions courtes propriétaires et le terminal mobile intègre les informations ou scripts qui sont activés par lesdits codes spécifiques, - le message comportant au moins une instruction courte propriétaire est envoyé à une application propriétaire incorporée au terminal, - pour un message comportant au moins une instruction courte propriétaire, le programme propriétaire de traitement remplace ladite instruction courte par un élément multimédia avant la mise à disposition à au moins un programme de restitution, - l'élément multimédia est préalablement stocké en mémoire du terminal, - l'élément multimédia est une adresse électronique dans le cas d'une instruction courte propriétaire correspondant à une adresse simplifiée,

<Desc/Clms Page number 5>

- le programme propriétaire de traitement met à jour une partie, un ou plusieurs messages précédemment reçus et stockés en mémoire en fonction de la réception d'au moins un message et instruction (s) propriétaire (s) ultérieur (s), - la mise à jour concerne au moins une zone textuelle,

- la mise à jour concerne au moins une adresse URL, - la mise à jour concerne au moins une image ou une séquence vidéo, - la mise à jour concerne au moins une ou plusieurs instructions courtes propriétaires, - on introduit à la source dans l'enveloppe au moins une erreur détectable afin que : - d'une part dans un terminal dans lequel on a préalablement incorporé une routine de détection d'erreur d'enveloppe spécifique à l'erreur, ledit message puisse être traité par envoi au programme propriétaire de traitement des messages lorsqu'il est associé à une instruction propriétaire de détection ou mixte, (la routine de détection d'erreur d'enveloppe sert donc à détecter l'erreur dans l'enveloppe et la présence d'une instruction propriétaire de détection ou mixte) - d'autre part dans un terminal ne comportant pas ladite routine de détection d'erreur d'enveloppe adaptée, ledit message ne soit pas restitué du fait de l'erreur, - la routine de détection d'erreur d'enveloppe est disposée en sortie erreur d'un moyen standard de traitement d'enveloppe du portable, - on introduit à la source dans le message multimédia au moins une erreur détectable afin que : -d'-une-part dans-un-terminal dans-lequel-on-a-préalablement-incorporé une routine de détection d'erreur de message spécifique à l'erreur, ledit message puisse être traité par envoi au programme propriétaire de traitement des messages lorsqu'il est associé à une instruction propriétaire de détection ou mixte, (la routine de détection d'erreur de message sert à détecter l'erreur dans le message et la présence d'une instruction propriétaire de détection ou mixte) - d'autre part dans un terminal ne comportant pas ladite routine de détection d'erreur de message adaptée, ledit message ne puisse pas être restitué normalement par le programme de restitution du fait de l'erreur,

<Desc/Clms Page number 6>

- la routine de détection d'erreur de message est disposé en sortie erreur d'un moyen standard de traitement de message du portable, - le terminal comporte en outre une voie de transmission normalisée et le message comporte en outre une requête en acquittement permettant d'informer la source de la réception, du traitement et/ou stockage dudit message, l'acquittement étant stocké par le programme propriétaire de traitement des messages dans sa mémoire spécifique et étant ultérieurement renvoyé par la voie de transmission normalisée, - le message comporte en outre de la requête un script d'interaction entraînant une participation active de l'utilisateur lors de son exécution, - dans le cas d'une mise en oeuvre d'un script d'interaction avec une requête, la source est informée de la participation active de l'utilisateur, - on met en oeuvre un terminal qui comporte au moins un organe d'entrée et le script comporte une obligation d'action de l'utilisateur sur ledit organe d'entrée, - l'organe d'entrée est une touche, un clavier, un écran tactile, un microphone...

- l'acquittement après participation active de l'utilisateur est préparé et éventuellement stocké dans une mémoire d'envoi avant d'être renvoyé, - l'acquittement est renvoyé par une voie de transmission telle que spécifiés par la requête en acquittement - l'acquittement est renvoyé à un moment opportun tel que défini par la requête en acquittement, - le moment opportun peut être une donnée temporelle, une plage horaire, ou fonction d'un compte à rebours mis en route par un événement tel que l'arrivée du message-en-mémoire, lequel compte à-rebours est-de-nature-définie par-la - requête en acquittement (nombre de restitutions, temps,...), - le moment peut être défini, notamment, par un événement en provenance d'une autre application telle qu'une application d'analyse du réseau de télécommunication afin de déterminer la qualité d'émission et d'indiquer au procédé d'acquittement les moments propres à renvoyer l'acquittement, - la durée d'exécution du script est limitée dans le temps, le dépassement dudit temps limite entraînant l'arrêt du script, - on compresse le message à la source avant sa transmission et le procédé met en oeuvre un moyen de décompression du message dans le terminal mobile,

<Desc/Clms Page number 7>

- on met en oeuvre un terminal qui comporte un moyen de mise en veille permettant de le placer dans un mode à faible consommation électrique lorsqu'un utilisateur a cessé d'utiliser ledit terminal pendant un temps prédéterminé, dans ledit mode, le terminal étant réactivé périodiquement pendant un temps d'activation prédéfini à rapport cyclique réduit et les messages n'étant restitués qu'aux moments de réactivations du terminal, - on met en oeuvre un terminal qui comporte des alternances de forte et faible consommation électrique en fonction de l'activité du terminal et de l'usager, (ces alternances sont imperceptibles pour l'utilisateur mais permettent des économies substantielles de consommation électrique car les temps de faible consommation électrique, bien que de durée très courte à échelle humaine, sont extrêmement longs comparativement aux temps de forte consommation) - le moment de mise a disposition d'un message peut être retardé ou avancé de façon à ce que la mise a disposition du message soit effectuée pendant un temps de forte consommation électrique, - on met en oeuvre un terminal qui comporte un mode de veille dans lequel le terminal entre suite à une inactivité prolongée de l'utilisateur, - on entame une phase de restitutions successives de messages à un moment postérieur à la mise en veille du terminal, - on entame une phase de restitutions successives de messages dès la mise en veille, - on entame une phase de restitutions successives de messages à la fin d'un décompte de temps, - chaque phase de restitutions successives de messages est limitée dans le

temps, ~ - la phase de restitutions successives s'interrompt afin de limiter la consommation électrique à au moins une des conditions suivantes : la reprise d'activité de l'utilisateur du terminal, après une durée prédéterminée, après un nombre prédéterminé de restitutions de messages, dans une phase de restitutions successives, chacune des restitutions peut être suivie de retours au mode de veille pour une durée prédéterminée, dans le cas de restitution d'une séquence distante par le biais d'une application de restitution, la séquence distante résidant dans un serveur distant du terminal, dans un premier temps on transmet au programme propriétaire de traitement et stocke dans sa mémoire spécifique un message préalable qui

<Desc/Clms Page number 8>

contient une séquence préalable et, dans un deuxième temps, notamment sur un événement d'un organe d'entrée du terminal, le programme propriétaire de traitement met à disposition la séquence préalable à l'application de restitution du terminal mobile et fait débuter une phase de téléchargement de la séquence distante débutant par une phase d'amorçage puis sa mise à disposition à l'application de restitution du terminal mobile à la suite de la séquence préalable, - dans le cas de restitution d'une séquence totale distante par le biais d'une application de restitution, ladite séquence totale est scindée à la source en une séquence initiale et une séquence principale, la séquence principale résidant dans un serveur distant du terminal, dans un premier temps on transmet au programme propriétaire de traitement et stocke dans sa mémoire spécifique un message qui contient la séquence initiale et, dans un deuxième temps, notamment sur un événement d'un organe d'entrée du terminal, le programme propriétaire de traitement met à disposition la séquence initiale à l'application de restitution du terminal mobile et fait débuter une phase de téléchargement de la séquence principale, débutant par une phase d'amorçage puis sa mise à disposition à l'application de restitution du terminal mobile à la suite de la séquence initiale, - on calcule la taille de la séquence initiale en fonction de la qualité escomptée de transmission afin que ladite restitution du message principal apparaisse continue pour l'utilisateur, - par défaut, la taille de la séquence initiale est déterminée en fonction de la qualité de transmission la plus mauvaise du réseau, -on dispose dans le-terminal une-application d'interception, ladite-application d'interception recevant les requêtes en provenance d'un programme de restitution et à destination d'interfaces périphériques spécifiques du terminal (fonction d'appel, répertoire téléphonique, répertoire de messages SMS, composeur de numéros, historique des numéros composés...) afin que les requêtes soient filtrées et éventuellement transmises au programme propriétaire de traitement pour analyse, traitement et renvoi au programme de restitution, (le renvoi concerne aussi bien une réponse proprement dit à une requête que d'autres données et, en particulier, un ou plusieurs messages stockés dans la mémoire spécifique du programme propriétaire de traitement des messages)

<Desc/Clms Page number 9>

- on dispose dans le terminal une application d'interception, ladite application d'interception recevant les requêtes en provenance d'un programme de restitution et à destination d'interfaces périphériques spécifiques du terminal (fonction d'appel, répertoire téléphonique, répertoire de messages SMS, composeur de numéros, historique des numéros composés...) et les réponses en retour d'interfaces périphériques spécifiques du terminal vers le programme de restitution afin que les réponses des interfaces des périphériques du terminal aux requêtes illégitimes (qui n'ont pas pu être traitées par les interfaces des périphériques) soient filtrées et éventuellement transmises au programme propriétaire de traitement pour analyse, traitement et renvoi au programme de restitution.

L'invention concerne également un procédé de transmission et de restitution d'un message multimédia entre une source et un terminal mobile normalisé d'un réseau de télécommunication, le mobile comportant au moins une voie de réception, le message multimédia reçu par la voie de réception étant traité par au moins un programme de restitution de message du terminal afin d'être restitué sur au moins une interface utilisateur, le message multimédia étant transmis dans une enveloppe de message selon un protocole normalisé, dans lequel on introduit à la source dans l'enveloppe au moins une erreur détectable afin que : - d'une part dans un terminal dans lequel on a préalablement incorporé une routine de détection d'erreur d'enveloppe spécifique à l'erreur, ledit message puisse être restitué, - d'autre part dans un terminal ne comportant pas ladite routine de détection d'erreur d'enveloppe adaptée, ledit message ne soit pas restitué du fait de l'erreur.

L'invention concerne également un procédé de transmission et de restitution d'un message multimédia entre une source et un terminal mobile normalisé d'un réseau de télécommunication, le mobile comportant au moins une voie de réception, le message multimédia reçu par la voie de réception étant traité par au moins un programme de restitution de message du terminal afin d'être restitué sur au moins une interface utilisateur, le message multimédia étant transmis dans une enveloppe de message selon un protocole normalisé, dans lequel on introduit à la source dans le message multimédia au moins une erreur détectable afin que :

<Desc/Clms Page number 10>

- d'une part dans un terminal dans lequel on a préalablement incorporé une routine de détection d'erreur de message spécifique à l'erreur, ledit message puisse être restitué - d'autre part dans un terminal ne comportant pas ladite routine de détection d'erreur de message adaptée, ledit message ne puisse pas être restitué normalement par le programme de restitution du fait de l'erreur.

L'invention concerne également la combinaison de l'incorporation d'erreur dans l'enveloppe et dans le message.

L'invention concerne également un procédé de transmission et de restitution d'un message multimédia entre une source et un terminal mobile normalisé d'un réseau de télécommunication, le mobile comportant au moins une voie de réception, le message multimédia reçu par la voie de réception étant traité par au moins un programme de restitution de message du terminal afin d'être restitué sur au moins une interface utilisateur, le message multimédia étant transmis dans une enveloppe de message selon un protocole normalisé, dans lequel, dans le cas de restitution d'une séquence totale distante par le biais d'une application de restitution, ladite séquence totale est scindée à la source en une séquence initiale et une séquence principale, la séquence principale résidant dans un serveur distant du terminal, dans un premier temps on transmet au programme propriétaire de traitement et stocke dans sa mémoire spécifique un message qui contient la séquence initiale et, dans un deuxième temps, notamment sur un événement d'un organe d'entrée du terminal, le programme propriétaire de traitement met à disposition la séquence initiale à l'application de restitution du terminal mobile et fait débuter une phase de téléchargement de la séquence principale, débutant par une phase d'amorçage puis sa mise à disposition à l'application de restitution du terminal mobile à la suite de la séquence initiale. Dans des modes particuliers on calcule la taille de la séquence initiale en fonction de la qualité de transmission afin que ladite restitution du message principal apparaisse continue pour l'utilisateur et, par défaut, la taille de la séquence initiale est déterminée en fonction de la qualité de transmission la plus mauvaise du réseau.

L'invention concerne enfin un procédé de transmission et de restitution d'un message multimédia entre une source et un terminal mobile

<Desc/Clms Page number 11>

normalisé d'un réseau de télécommunication, le terminal comportant au moins une voie de réception, le message multimédia reçu par la voie de réception étant traité par au moins un programme de restitution de message du terminal afin d'être restitué sur au moins une interface utilisateur, le message multimédia étant transmis dans une enveloppe de message selon un protocole normalisé, le terminal disposant d'une application d'interception, ladite application d'interception recevant les requêtes en provenance d'un programmes de restitution et à destination d'un périphérique spécifique du terminal (fonction d'appel, répertoire téléphonique, répertoire de messages SMS, composeur de numéros, historique des numéros composés...) afin que les requêtes qui n'ont pas pu être traitées par le périphérique soient transmises à un programme propriétaire de traitement pour analyse et traitement et renvoi au programme de restitution.

D'une manière générale, le domaine de l'invention est celui de la télécommunication mobile. Elle a pour but d'offrir la possibilité à tout type de fournisseur de contenu d'envoyer un message multimédia sur un espace réservé sur les écrans de terminaux mobiles. Le procédé selon l'invention permet à l'utilisateur de demander au mobile de mémoriser ces messages dans le but de les exploiter ultérieurement : lire/visualiser le message, restituer un coupon, accéder à un site WAP/toile (WEB), jouer... L'invention permet ainsi de s'interfacer avec des fonctionnalités généralement standardisées dans les terminaux mobiles afin : - de filtrer les messages reçus par les procédés modernes de réception de messages des terminaux mobiles, - d'identifier le contenu du message afin d'extraire les messages au format propriétaire en provenance de sources autorisées, - de traiter les messages réceptionnés afin de les restituer aux applications existantes aux moments ou selon des événements ou contextes propres aux terminaux mobiles (par exemple allumage/extinction du rétro éclairage) et définis par des instructions propriétaires accompagnant le message, - d'analyser les actions des utilisateurs lors de la restitution des messages et de garder une trace de cette information, - de renvoyer à une adresse préalablement définie par une adresse Internet ou un numéro de téléphone éventuellement modifiable les informations relatives

<Desc/Clms Page number 12>

aux actions des utilisateurs et aux actions de l'application (ajout, réception, effacement, erreur), - de gérer une mémoire de messages dans le but de restituer, modifier, remplacer ou supprimer au moins un message ou une partie d'un message mémorisé à la demande de la source autorisée, - de gérer une mémoire de messages dans le but d'afficher à plusieurs reprises chaque message et de les supprimer sur demande des utilisateurs ou en fin de durée de validité du message.

L'utilisateur peut ainsi contrôler les sources émettrices du contenu et n'autoriser techniquement qu'une ou certaines sources d'envois des messages.

Par ailleurs, l'invention a un impact nul sur les infrastructures en place pour ne pas perturber le fonctionnement du réseau et des mobiles existants qui sont normalisés et, en particulier, en ce qui concerne les modes veille, les erreurs, la possibilité de commander le module de traitement propriétaire avec des requêtes, le rejet d'un SMS propriétaire avec une erreur par un mobile classique ne comportant pas de moyen de traitement d'erreur, et la validation utilisateur obligatoire pour obtenir la connexion.

De même, l'invention prend également en compte le fait qu'un téléphone mobile n'a que très peu de mémoire et que l'autonomie de la batterie est critique. Elle permet d'optimiser les ressources du téléphone en tirant partie des applications existantes, de minimiser l'impact sur l'autonomie du terminal la synchronisation de certains événements de l'application propriétaire (envoi vers l'application de restitution) aux événements inhérents au bon fonctionnement du terminal mobile tel que le réveil périodique du microprocesseur en mode réelle pour permettre au terminal de converser avec les émetteurs/récepteurs du réseau.

La possibilité de mettre en oeuvre une compression/décompression des messages permet de prendre en compte le fait que les ressources réseaux d'un opérateur en téléphonie mobile sont limitées et qu'envoyer des messages coûte cher. La réduction des coûts est également possible en minimisant la taille des messages envoyés par compression et remplacement d'adresses (URL) par des codes, en réduisant la taille des informations (programmes, données ou autres) ou scripts envoyés dans chaque message par intégration et réutilisation des informations ou scripts redondants, génériques ou usuels dans les mobiles et, enfin, de refaire apparaître plusieurs fois un message au lieu de

<Desc/Clms Page number 13>

l'envoyer à plusieurs reprises. L'intégration consiste à incorporer dans le mobile ces informations ou scripts sous une forme figée, mémoire morte, ou sous une forme modifiable, en mémoire modifiable et, par exemple la mémoire du programme propriétaire de traitement des messages.

L'invention permet également d'exploiter les interactions de chaque utilisateur avec chaque message pour cibler ses préférences. Les interactions les plus évidentes sont lorsque l'utilisateur décide de se connecter au service Internet proposé dans le message reçu. Alors qu'il n'est pas possible dans l'état actuel de la technique d'identifier l'utilisateur au niveau du serveur Internet, l'invention permet cette identification.

L'invention permet également d'acquitter la réception et/ou la restitution du message sur un organe de sortie du terminal mobile par les voies de communication du réseau de télécommunication mobile vers une destination spécifiée alors que dans l'état actuel de la technique, seul les opérateurs des réseaux de télécommunication sont aptes à récupérer ces messages d'acquittement. De même, grâce à l'invention, lors d'envois de messages avec accusé de réception, seule la source recevra le message d'acquittement de son correspondant. L'invention permet de paramétrer l'adresse de destination de l'acquittement et/ou de profiter d'une opportunité où l'utilisateur s'est connecté au réseau Internet pour envoyer le message d'acquittement sans qu'il s'en rende compte.

De plus, bien que l'acquittement est un procédé courant pour prouver la réception ou la restitution par un utilisateur, il n'est cependant pas possible de déterminer avec la technique actuelle si l'utilisateur a été exposé au message.

L'invention permet par contre de s'assurer que l'utilisateur a bien été exposé au message par acquittement de chaque interaction de l'utilisateur avec le terminal alors qu'un message est restitué sur l'un des organes de sortie.

La présente invention est exemplifiée par la description qui suit en relation avec les Figures suivantes qui représentent :
Figure 1, un schéma fonctionnel d'un terminal mobile avec mise en oeuvre de l'invention,
Figures 2 et 2bis, deux exemples de messages, . Figure 3, un premier mode de restitution d'un message,
Figure 4, un second mode de restitution d'un message,
Figure 5, une lecture de séquence totale distante.

<Desc/Clms Page number 14>

Figure 1, un réseau de télécommunication 2 mobile envoie des messages multimédia vers un terminal mobile 1 normalisé. Les éléments standards du mobile sont représentés sous forme de cadres hachurés sur cette Figure. Les messages multimédia sont classiquement transmis selon un protocole normalisé qui est ici appelé enveloppe 22 du message. L'enveloppe est normalisée et peut être, par exemple, du type SMS, USSD, MMS, CSD, GPRS, UMTS. Dans cet exemple de mise en oeuvre de l'invention Figure 1, les messages multimédia sont transmis du réseau 2 vers le terminal mobile 1 par une voie de données normalisée du type message court. Sur la Figure 1, un SMS 22 est représenté à titre d'exemple mais on envisage que le message multimédia soit transporté par plus d'un SMS en fonction de sa taille ou, qu'inversement, plusieurs messages multimédia soient transportés par un même SMS.

Les messages pouvant être traités selon l'invention sont représentés Figures 2 et 2bis. Figure 2, au moins une instruction propriétaire de détection 8 est associée à chaque message 6 véhiculé par l'enveloppe 22. Figure 2, au moins une instruction propriétaire de restitution 8'est en outre associée au message 6. Cette instruction propriétaire de restitution qui peut éventuellement être omise, est destinée à activer et fournir des paramètres à un programme propriétaire de traitement des message comme explicité ultérieurement. Figure 2bis, au moins une instruction propriétaire mixte 8"est associée à chaque message 6 véhiculé par l'enveloppe 22. Les instructions propriétaires peuvent donc être de trois types : - instruction propriétaire de détection 8 permettant à une routine de détection, 5,14, 17 Figure 1, de reconnaître un message propriétaire et l'envoi du message à un programme propriétaire, 16 Figure 1, de traitement des messages ; - instruction propriétaire de restitution 8'permettant de déterminer les conditions de traitement et restitution des messages par exécution dans un programme propriétaire 16 de traitement des messages ; - instructions propriétaires mixtes ayant les deux fonctions sus mentionnées.

Le message multimédia 6 est codé selon un langage standard par exemple, WML, HTML, xHTML, sHTML, XML, Java ou équivalents ou encore des commandes de lancement d'applications du type téléchargement de fichiers (jeux, sonneries,...). Le message peut comporter en outre dans son

<Desc/Clms Page number 15>

corps des instructions courtes 27 propriétaires dont le rôle est de remplacer des éléments multimédia dans le message et de gagner ainsi de la place. Lors de la restitution ou antérieurement dans le terminal, l'instruction courte pourra être remplacée par l'élément multimédia qui a été préalablement fourni au terminal par transmission et mémorisé ou stocké dans la mémoire 13. Dans certain cas, en particulier lorsque l'élément multimédia correspond à un script, soit l'instruction courte sera remplacée par le script soit il sera fait appel à une routine d'exécution dudit script. Ces instructions courtes sont intéressantes pour les données multimédia que l'on transmet fréquemment et qui sont en particulier de taille relativement importante.

Revenant maintenant sur la Figure 1, le mobile 1 comporte des circuits non représentés pour une voie de réception et une voie d'émission. Sur la voie de réception des moyens standards de traitement 3 de l'enveloppe et de traitement 4 du contenu de l'enveloppe, c'est à dire des messages, permettent en l'absence d'erreur, de récupérer les messages pour les transmettre à une routine de détection 5 des messages propriétaire. En cas d'erreur soit dans l'enveloppe, soit dans le message, l'enveloppe ou le message sont refusés par les moyens standards de traitement respectifs 3,4. Lorsqu'une instruction propriétaire de détection 8 ou mixte 8"est associée au message, la routine de détection 5 envoie le message vers un programme propriétaire 16 de traitement des messages auquel est associée une mémoire spécifique 13. En l'absence d'erreur et d'instruction propriétaire associée, le message est envoyé à un programme standard de traitement des messages non représenté. Le terminal comporte également un programme de restitution 12 qui est classiquement associé à une mémoire cache 11. Le programme de restitution 12 est en relation avec divers organes d'entrée/sortie 9, micro, clavier, écran tactile, écran, afficheur, diode électroluminescente, vibreur, haut parleur...

Le programme de restitution 12 peut être un navigateur qui est une application du terminal parmi d'autres pouvant exploiter un type de contenu, un message, et le restituer à l'écran ou sur une autre sortie. Dans cet exemple, le navigateur WAP est l'application principale mais d'autres application, par exemple du type FLASH ou Streaming (procédé de restitution de message distant) audio ou vidéo, peuvent être les applications restitutrices du message.

Le programme de restitution envoi des requêtes des messages dans les interfaces/périphériques 7 standard du mobile 1. Ces interfaces 7 sont, par

<Desc/Clms Page number 16>

exemple, une fonction d'appel, un répertoire téléphonique, un répertoire de messages SMS, un composeur de numéros, un historique des numéros composés... Les interfaces périphériques 7 peuvent générer des événements, par exemple mise en veille, et ces événements sont accessibles au programme propriétaire 16 de traitement des messages ou à d'autres programmes ou applications. Sur la Figure 1 ces événements sont représentés sous forme de flèches ondulées.

Dans le cas où, comme représenté en trait plein, une application d'interception 20 est disposée dans le mobile, en l'absence de filtrage par l'application d'interception 20, les requêtes sont envoyées aux interfaces standard 7 du mobile. Par contre dans le cas de la mise en oeuvre du filtrage, la requête est envoyée au programme propriétaire de traitement 16 des messages comme représenté en pointillés à partir de A et, en retour le programme propriétaire de traitement 16 traite la requête en renvoyant une réponse traitée 10 au programme de restitution 12 ou en effectuant une opération prédéfinie (les deux termes traitement et opération étant synonymes dans le contexte de l'invention) et, par exemple, la mise à disposition d'un message issu de la mémoire 13 à l'application de restitution 12.

Il est également possible d'effectuer un filtrage par l'application d'interception 20 en retour de l'interface 7 et en particulier d'intercepter les requêtes qui n'ont pas pu être traitées par l'interface pour les envoyer au programme propriétaire de traitement 16 des messages comme représenté en pointillés à partir de B et, en retour le programme propriétaire de traitement 16 traite la réponse à la requête en renvoyant une réponse traitée 10 au programme de restitution 12 et/ou en effectuant une opération prédéfinie (les deux termes traitement et opération étant synonymes dans le contexte de l'invention) et, par exemple, la mise à disposition d'un message issue de la mémoire 13 à l'application de restitution 12.

Ainsi, le filtrage par l'application d'interception 20 correspond à une analyse de la requête en A ou de la réponse à la requête en B (réponse d'incompréhension de la requête par l'interface standard) avec une activation du programme propriétaire 16 de traitement des messages. En particulier, l'application d'interception analyse la réponse à la requête en sortie de l'interface standard 7 et lorsqu'elle détecte que la requête n'a pas pu être traitée, branchement en B sur la Figure 1, elle active le programme propriétaire

<Desc/Clms Page number 17>

16 de traitement des messages. Par exemple, la requête en provenance du programme de restitution (suite à une interaction de l'utilisateur du terminal avec un des messages restitués) peut consister à demander à l'interface répertoire téléphonique qui stocke les numéros de 1 à 100, de donner le numéro correspondant à 9999. Un telle requête ne pourra normalement pas être traitée et la réponse le signalera. Ainsi, le programme propriétaire traitera cette requête illégitime 9999 , enverra une fausse bonne réponse à la requête à l'application de restitution et commandera une mise à disposition d'un message de la mémoire 13 à l'application de restitution.

Une mémoire 13 spécifique est associée au programme 16 de traitement des messages afin de pouvoir stocker les messages car leur mise à disposition au programme 12 de restitution est sous la dépendance des instructions propriétaires de restitution 8'ou mixte 8"pour le choix du moment de restitution et/ou le choix du programme de restitution 12 standard utilisé. Le portable 1 peut également comporter d'autres programmes de restitution qui sont eux propriétaires et non représentés sur la Figure 1. Ainsi, dans le cas de terminaux WAP, le navigateur WAP est activé par le programme propriétaire 16 de traitement des messages en fonction d'instructions propriétaires transmises avec les messages afin, par exemple, d'afficher en écran de veille des images ou animations interactives. Les instructions propriétaires permettent en particulier de choisir le moment de la restitution, le terme moment correspondant à un temps absolu ou relatif, à une action ou encore à un changement d'état au niveau du terminal. L'application propriétaire du terminal s'appuie sur toutes les normes et procédés utilisés dans le domaine de la téléphonie et, notamment, l'utilisation des SMS pour récupérer le contenu à restituer. Dans le cas de terminaux avec fonctionnalité de streaming aussi bien vidéo que audio, les instructions propriétaires permettent d'activer cette fonctionnalité à un moment prédéterminé et selon un mode explicité par la suite et particulièrement efficace. Les messages étant restitués sous conditions temporelles et/ou de contexte, la mémoire 13 spécifique du programme de traitement permet de conserver les messages jusqu'à envoi au (x) programme (s) 12 de restitution.

Le procédé permet notamment d'identifier et de stocker plusieurs messages WML ou HTML ou autres standardisés spécifiquement envoyés au terminal pour être traités par une application propriétaire qui les enverra, par

<Desc/Clms Page number 18>

exemple, au navigateur lors de moments d'inactivité du terminal afin qu'il les restitue sur les organes de sortie prévus à cet effet.

Dans une variante de mise en oeuvre on introduit au moins une erreur dans l'enveloppe du message et/ou dans le message proprement dit. Dans le cas d'une erreur introduite dans l'enveloppe, une routine de détection 14 en sortie erreur du moyen standard 3 de traitement de l'enveloppe, peut le transmettre au programme propriétaire de traitement 16 de messages si une instruction propriétaire de détection 8 ou mixte 8"est présente. Dans le cas d'une erreur introduite dans le message proprement dit, une routine de détection 17 en sortie erreur du moyen standard 4 de traitement du contenu, peut le transmettre au programme propriétaire de traitement 16 de messages si une instruction propriétaire de détection 8 ou mixte 8"est présente. De préférence, les messages avec leurs instructions propriétaires sont envoyés au programme propriétaire de traitement 16 des messages et, en l'absence d'instruction propriétaire de détection 8 ou mixte 8", ces enveloppes ou messages sont rejetés ou supprimés. Il est également possible de combiner les deux types d'erreurs, enveloppe et message, mais dans ce cas, la sortie de la routine de détection d'erreur d'enveloppe reverra le message sur le moyen standard 4.

L'avantage de mettre en oeuvre une ou des erreurs est d'empêcher ou limiter la restitution dans un terminal mobile normalisé qui ne posséderait pas ladles routines de détection propriétaire ad hoc d'interception de l'erreur. Ainsi, on développe une application mobile nouvelle pouvant traiter des SMS propriétaires d'une manière transparente. On a ainsi un moyen pour ne pas gêner les utilisateurs de terminaux du parc existants au cas où ils recevraient un SMS propriétaire. En effet, en l'absence d'erreur, celui-ci serait traité comme un SMS"normal"et affiché à l'écran car le SMS étant standard, tout mobile est sensé recevoir et traiter un SMS d'une manière normalisée. Par contre le SMS comportant une erreur sera rejeté par tout mobile standard. On intercale donc dans les mobiles une application d'interception propriétaire des messages entrants qui est capable de détecter cette erreur pour exploiter le message qui comporte cette erreur et donc qui est bien un leurre, le message propriétaire devant être traité. Ainsi, il y a rejet automatique d'un SMS si le terminal ne contient pas le logiciel ad hoc. On code donc chaque SMS de telle manière qu'il

<Desc/Clms Page number 19>

soit rejeté par l'application réceptrice du SMS qui détecte alors une erreur et il ne sera donc pas exploité par les terminaux non compatibles.

Le procédé de restitution de message distant (séparé de l'environnement du mobile par un réseau) par un lecteur vidéo ou audio ( streaming ) ou toute application traitant des données de taille significative par rapport à la bande passante du réseau tel que le temps de téléchargement complet des données avant leur traitement (en particulier leur restitution) serait perceptible par l'utilisateur et préjudiciable à son confort, passe généralement par une phase initiale d'amorçage de courte durée pendant laquelle aucun message (son, image, animation...) n'est restitué. Cette phase d'amorçage est due à des raisons techniques inhérents aux réseaux de télécommunications et, particulièrement, aux réseaux de télécommunication mobile. En effet, pour initier une cession de visualisation ou d'écoute à distance (streaming vidéo ou audio), le lecteur (vidéo ou audio) doit passer par des phases de connexion, d'échange d'information diverses, de recherche de l'adresse à laquelle se trouve le message distant et généralement par un téléchargement préalable d'une amorce de la séquence à visualiser. Cette phase d'amorçage est un temps d'attente et de désagrément pour l'utilisateur. Dans un dispositif classique, plus la séquence vidéo ou audio à visualiser ou écouter est courte et plus cette phase d'attente est comparativement longue. L'attente de l'utilisateur sera d'autant plus pénible.

La mise en oeuvre de l'invention dans ce domaine de téléchargement de fichiers ou de streaming (vidéo ou audio) permet de combler ce temps d'attente. Le téléchargement ou la visualisation à distance d'une séquence selon les procédé mis en oeuvres avec le programme propriétaire de traitement des messages et selon les Figures 3,4, 5 évite l'inconvénient du temps d'attente.

Le procédé selon l'invention permet de recevoir un message multimédia, de le stocker en mémoire 13 et de le mettre à disposition d'une application de restitution propre au terminal 12. Le message multimédia reçu préalablement à sa restitution est ici appelé message local 18 pour le différencier du message distant 19 que le lecteur (vidéo ou audio) téléchargera ultérieurement. Ce message local peut être une séquence (vidéo ou audio) de format compatible au lecteur (vidéo ou audio) propre au terminal. Ce message local peut être accompagné de l'adresse ou lien multimédia, du message distant 19.

<Desc/Clms Page number 20>

La mise à disposition par le programme propriétaire de traitement 16 des messages de ce message 18 à l'application de restitution 12 intervient à l'occasion d'un événement spécifique interprété par l'application de traitement des messages 16. Lorsque la restitution du message local 18 commence à To, l'application de restitution de fichier distants 12 lance au même instant sa phase de streaming à l'adresse du message distant 19 mise à disposition par l'application de traitement des messages 16. La mise à disposition peut éventuellement passer par une étape préalable d'envoi ou de copie du message local 18 vers une mémoire différente ou propre à l'application de restitution 12 appelée mémoire cache 11.

Le message distant 19 est restitué à la suite de la restitution du message local 18. Le passage de la restitution du message local 18 à la restitution du message distant 19 par l'application de restitution peut être déclenché dès que la phase d'amorçage initiale préalable à la restitution du message 19 est terminée comme sur la Figure 3. Elle peut aussi être déclenchée dès que la restitution du message local 18 est arrivée à son terme Figure 4.

Sur la Figure 5 on a représenté la séquence initiale d'une séquence totale qui est envoyée sous forme de message multimédia et est alors dans le portable comme message local 18. Le reste de la séquence totale est stocké dans un serveur distant avec une adresse et est appelé pour restitution selon le procédé décrit ci-dessus.

Ainsi, selon l'invention, on transmet dans un premier temps un message 18 qui contient la séquence initiale d'une séquence totale dont la séquence principale distante est à restituer par le biais d'une application de restitution du terminal mobile (navigateur, lecteur vidéo,...). La séquence principale 19 réside sur un serveur distant et, dans les limites des capacités des réseaux de télécommunications, sa restitution est généralement précédée d'une phase d'amorçage pouvant durer plusieurs secondes. Quant à la séquence initiale résidant localement dans une mémoire du terminal, sa restitution est instantanée mais, pour des raisons de coûts, cette séquence initiale transmise préalablement doit rester aussi courte que possible. La procédé mis en place dans le terminal permet dans un premier temps de recevoir et de stocker la séquence initiale ; dans un deuxième temps, notamment suite à un événement d'un organe d'entrée du terminal ou autre condition pouvant être fournie par une instruction propriétaire de restitution 8'ou mixte 8", le procédé permet de

<Desc/Clms Page number 21>

soumettre la séquence initiale à l'application de restitution du terminal mobile, qui permet une restitution immédiate, et de faire débuter, au même moment, la phase d'amorçage du message principal distant. Le procédé permet de faire suivre la restitution de la séquence initiale par la séquence d'amorçage de sorte que la restitution du message principal apparaisse continue pour l'utilisateur. Le procédé de l'invention permet une restitution apparaissant instantanée à l'utilisateur d'une séquence distante téléchargée par le biais d'un réseau mobile. Il permet aussi de garder une continuité entre la restitution de la séquence locale et de la séquence distante.

Le procédé permet donc d'éliminer le temps d'attente en téléchargeant au préalable la séquence initiale. L'application de streaming gère aussi le passage de l'exploitation de la séquence initiale à l'exploitation de la séquence principale d'une manière continue.

La taille de la séquence initiale est réglée en fonction de la durée maximale escomptée de la phase d'amorçage. La taille de ce fichier est calculée de telle façon que la durée de visualisation de cette séquence d'amorçage soit au moins égale à la durée d'attente de la phase d'amorçage du téléchargement de la séquence vidéo. On télécharge un message local correspondant à la séquence initiale suffisamment important permettant de visualiser une séquence suffisamment longue pour que l'application de

streaming prenne le temps dont elle a besoin pour télécharger l'amorce du message principal.

Les modalités du passage de la restitution du message local (séquence initiale) à la restitution de l'amorce téléchargée dépend de la nature du message distant (séquence principale). Une instruction propriétaire notifie le caractère prioritaire de la séquence distante (principale) sur la séquence locale (initiale) et permet à l'application de traitement des messages de mettre en oeuvre les modalités du passage de la restitution du message local à la restitution de la séquence distante immédiatement après la phase d'amorçage. Par défaut, sans cette commande prioritaire, le message local est restitué dans son intégralité avant de donner la main à l'amorce du message distant comme représenté Figure 4.

La qualité et quantité du débit sont cruciaux pour bien recevoir et/ou visualiser/écouter des fichiers, distants sur un réseau mobile. Il est donc important de ne pas polluer le débit par la réception au même moment de

<Desc/Clms Page number 22>

publicités. L'intérêt du procédé selon l'invention présentée est de restituer des messages, notamment publicitaires, à des moments où le débit demandé au réseau est critique, lesquels messages ont été envoyés et réceptionnés au préalable à un moment où le débit demandé au réseau mobile par le terminal n'est pas critique.

Dans le cas où le terminal 1 est mis en mode veille, l'alimentation électrique de ce dernier est périodiquement rétablie pendant un temps court.

En mode veille le rapport cyclique temps d'alimentation coupée sur temps d'alimentation rétablie est très élevé afin de réduire la consommation. Pendant ces périodes de rétablissement de l'alimentation, le programme propriétaire de traitement des message peut exploiter ces périodes d'activités pour mettre à disposition des messages afin de profiter de la réactivation temporaire du terminal.

Dans la généralité du procédé, la mise à disposition des messages peut être gérée par le programme de traitement 16 des messages ou peut être déclenchée suite à un ou des événements prédéfinis ou sur demande d'une application et, par exemple, une requête ou sa réponse filtrée (en A ou B). Par exemple, une application R1 ayant des temps d'attente pendant son exécution pourra demander au programme de traitement des messages la mise à disposition d'un message stocké dans la mémoire spécifique 13 à restituer par R 1 pendant ces temps d'attentes.

Les événements prédéfinis sont générés par les interfaces de périphériques (7) spécifiques (par exemple mise en veille). Les requêtes correspondent aux requêtes filtrées proprement dites (en A) ou aux réponses filtrées à ces requêtes (en B) par l'application d'interception 20.

De même, une application R1 peut proposer au programme de traitement 16 des messages un espace (auditif ou visuel) à combler par un des messages multimédia (visuel ou sonore) stockés dans la mémoire 13. Cet espace à combler n'est pas obligatoirement du format de restitution de l'application R 1 mais peut être pris en charge par une application de restitution R2 lancée en parallèle, restitution qui sera insérée à un endroit prévu à cet effet par l'application. En effet, le moyen d'affichage, par exemple, est divisé en zones d'affichage qui peuvent être accédées indépendamment les unes des autres et les divers messages, notamment en fonction des instructions propriétaires, pourront s'y afficher indépendamment. Par exemple, une application de jeu R 1

<Desc/Clms Page number 23>

peut prévoir de demander au programme de traitement des messages de lancer une application de restitution R2 (par exemple un navigateur) propre au terminal afin de restituer un message de la mémoire 13 (par exemple un message publicitaire) à afficher au même moment.

Claims (15)

REVENDICATIONS

1. Procédé de transmission et de restitution d'un message multimédia (6) entre une source et un terminal mobile (1) normalisé d'un réseau (2) de télécommunication, le mobile comportant au moins une voie de réception, le message multimédia reçu par la voie de réception étant traité par au moins un programme de restitution (12) de message du terminal afin d'être restitué sur au moins une interface utilisateur (9), le message multimédia étant transmis dans une enveloppe (22) de message selon un protocole normalisé, caractérisé en ce que l'on transmet dans l'enveloppe (22) le message multimédia (6) et on associe audit message multimédia au moins une instruction propriétaire de détection (8) et au moins une instruction propriétaire de restitution (8') ou mixte (8"), et dans un terminal mobile dans lequel on a préalablement incorporé une routine propriétaire de détection (5,14, 17) et un programme propriétaire (16) de traitement des messages, la routine (5,14, 17) détecte la présence de l'instruction propriétaire de détection (8) ou mixte (8"), transmet au moins l'instruction propriétaire de restitution (8') ou mixte (8") et le message (6) au programme propriétaire (16) de traitement, ledit programme propriétaire de traitement exécutant l'instruction de restitution (8') ou mixte (8") et mettant à disposition à un moment défini par l'instruction propriétaire de restitution (8') ou mixte (8"), le message au programme de restitution (12).

2. Procédé selon la revendication 1 caractérisé en ce que le choix du/des programmes de restitution (12) dépend de l'instruction propriétaire de restitution (8') ou mixte (8").

3. Procédé selon la revendication 1 ou 2 caractérisé en ce que le message multimédia est stocké dans une mémoire (13) du programme propriétaire (16) de traitement avant sa mise à disposition à au moins un programme de restitution, le moment de sa mise à disposition dépendant d'un ou plusieurs des moyens suivants : du contenu de l'instruction propriétaire de restitution (8') ou mixte (8"), d'au moins une requête, d'au moins un événement prédéfini.

4. Procédé selon la revendication 1,2 ou 3 caractérisé en ce que la transmission s'effectue par enveloppe (22) SMS, USSD, MMS ( Multimedia Messaging Service ), CSD (commutation de circuits), GPRS, UMTS ou autre moyen de transmission de données, chaque enveloppe pouvant véhiculer

<Desc/Clms Page number 25>

plusieurs messages et au moins une instruction propriétaire étant associée à chaque message multimédia.

5. Procédé selon la revendication 1,2, 3 ou 4 caractérisé en ce que le message contient du code normalisé (WML, HTML, xHTML, sHTML, XML, java ou équivalents) interprété par un navigateur ou d'autres applications existantes dans le terminal, et en ce que le message multimédia comporte en outre au moins une instruction courte (27) propriétaire.

6. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce que l'on introduit à la source dans l'enveloppe au moins une erreur détectable afin que : - d'une part dans un terminal dans lequel on a préalablement incorporé une routine de détection d'erreur d'enveloppe (14) spécifique à l'erreur, ledit message puisse être traité par envoi au programme propriétaire (16) de traitement des messages lorsqu'il est associé à une instruction propriétaire de détection (8) ou mixte (8"), - d'autre part dans un terminal ne comportant pas ladite routine de détection d'erreur d'enveloppe adaptée, ledit message ne soit pas restitué du fait de l'erreur.

7. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce que l'on introduit à la source dans le message multimédia (6) au moins une erreur détectable afin que : - d'une part dans un terminal dans lequel on a préalablement incorporé une routine de détection d'erreur de message (17) spécifique à l'erreur, ledit message puisse être traité par envoi au programme propriétaire de traitement des messages lorsqu'il est associé à une instruction propriétaire de détection (8) ou mixte (8"), - d'autre part dans un terminal ne comportant pas ladite routine de détection d'erreur de message adaptée, ledit message ne puisse pas être restitué normalement par le programme de restitution du fait de l'erreur.

8. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce que le terminal comporte en outre une voie de transmission normalisée et le message comporte en outre une requête en acquittement permettant d'informer la source de la réception, du traitement et/ou stockage dudit message, l'acquittement étant stocké par le programme propriétaire (16)

<Desc/Clms Page number 26>

de traitement des messages dans sa mémoire spécifique (13) et étant ultérieurement renvoyé par la voie de transmission normalisée.

9. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce que l'on compresse le message à la source avant sa transmission et le procédé met en oeuvre un moyen de décompression du message dans le terminal mobile.

10. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce que l'on met en oeuvre un terminal qui comporte un moyen de mise en veille permettant de le placer dans un mode à faible consommation électrique lorsqu'un utilisateur a cessé d'utiliser ledit terminal pendant un temps prédéterminé, dans ledit mode, le terminal étant réactivé périodiquement pendant un temps d'activation prédéfini à rapport cyclique réduit et les messages n'étant restitués qu'aux moments de réactivations du terminal.

11. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce que dans le cas de restitution d'une séquence distante par le biais d'une application de restitution, la séquence distante résidant dans un serveur distant du terminal, dans un premier temps on transmet au programme propriétaire de traitement et stocke dans sa mémoire un message préalable (18) qui contient une séquence préalable et, dans un deuxième temps, notamment sur un événement d'un organe d'entrée du terminal, le programme propriétaire (16) de traitement met à disposition la séquence préalable à l'application de restitution du terminal mobile et fait débuter une phase de téléchargement de la séquence distante (19) débutant par une phase d'amorçage puis sa mise à disposition à l'application de restitution du terminal mobile à la suite de la séquence préalable.

12. Procédé selon l'une quelconque des revendications 1 à 10 caractérisé en ce que dans le cas de restitution d'une séquence totale distante par le biais d'une application de restitution, ladite séquence totale est scindée à la source en une séquence initiale et une séquence principale, la séquence principale résidant dans un serveur distant du terminal, dans un premier temps on transmet au programme propriétaire (16) de traitement et stocke dans sa mémoire spécifique (13) un message qui contient la séquence initiale et, dans un deuxième temps, notamment sur un événement d'un organe d'entrée du terminal, le programme propriétaire de traitement met à disposition la séquence initiale à l'application de restitution du terminal mobile et fait débuter une phase

<Desc/Clms Page number 27>

de téléchargement de la séquence principale, débutant par une phase d'amorçage puis sa mise à disposition à l'application de restitution du terminal mobile à la suite de la séquence initiale.

13. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce que l'on on dispose dans le terminal une application d'interception (20), ladite application d'interception recevant les requêtes en provenance d'un programme de restitution (12) et à destination d'interfaces périphériques (7) spécifiques du terminal afin que les requêtes soient filtrées et éventuellement transmises (A) au programme propriétaire (16) de traitement pour analyse, traitement et renvoi au programme de restitution.

14. Procédé selon l'une quelconque des revendications 1 à 12 caractérisé en ce que l'on on dispose dans le terminal une application d'interception (20), ladite application d'interception recevant les requêtes en provenance d'un programme de restitution (12) et à destination d'interfaces périphériques (7) spécifiques du terminal et les réponses en retour d'interfaces périphériques spécifiques du terminal vers le programme de restitution afin que les réponses des interfaces des périphériques du terminal aux requêtes illégitimes soient filtrées et éventuellement transmises (B) au programme propriétaire (16) de traitement pour analyse, traitement et renvoi au programme de restitution.

15. Procédé de transmission et de restitution d'un message multimédia (6) entre une source et un terminal mobile (1) normalisé d'un réseau de télécommunication (2), le mobile comportant au moins une voie de réception, le message multimédia reçu par la voie de réception étant traité par au moins un programme de restitution (12) de message du terminal afin d'être restitué sur au moins une interface utilisateur, le message multimédia étant transmis dans une enveloppe (22) de message selon un protocole normalisé, caractérisé en ce que l'on dispose dans le terminal une application d'interception (20), ladite application d'interception recevant les requêtes en provenance d'un programmes de restitution (12) et à destination d'un périphérique (7) spécifique du terminal et les réponses en retour d'interfaces périphériques spécifiques du terminal vers le programme de restitution afin que les réponses des interfaces des périphériques du terminal aux requêtes illégitimes soient filtrées et éventuellement transmises (B) au programme propriétaire de traitement pour analyse, traitement et renvoi au programme de restitution.